Buchfuehrung: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(135 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
<i>Die doppelte Buchhaltung hat interessante Grundsätze, denen die Praxis jedoch schnell und regelmäßig entgegengewirkt. Der EDV-Ansatz der 1980er Jahre ist hier überholt: Das Resultat war ein wildes Hin- und Herverbuchen garniert mit Stornodatensätzen. OrgaMon setzt hier auf Buchungsintelligenz, die schon im Konto-Deckblatt definiert ist. Jede Buchung in ein Konto durchläuft dann die individuelle Qualitätssicherung dieses Kontos. Die Logik wird durchgängig und ohne Ausnahme angewendet und ist transparent anpassbar. Durch eine möglichst späte "Fixierung" der Buchungssätze, die jedoch immer inerhalb der Forderungen der Wirtschaftsprüfer liegt, wird maximale Flexibilität und Fehlerfreiheit des Endergebnisses erreicht.</i><br>
<i>Die doppelte Buchhaltung hat interessante Grundsätze, denen die Praxis jedoch schnell und regelmäßig entgegengewirkt. Der EDV-Ansatz der 1980er Jahre war, die Buchführung nur formal auf die EDV abzubilden. Wildes Hin- und Her-buchen, sinnfreie Gegenkonten, negatives Buchen im Soll und andere Auswüchse waren die Folge. Dem Buchhalter war künstlerische Freiheit gewährt, die nicht selten genutzt wurde.<br><br>
OrgaMon bildet ganze Geschäftsvorfälle ab, deren Folge sind eine ganze Anzahl von Buchungen ggf. auf eine Vielzahl definierter Konten. Die einzelnen Buchungen sind jedoch direkt mit diesem Geschäftsvorgang verbunden, so dass der Zusammenhang erhalten bleibt. Änderungen am Geschäftsvorfall ziehen Änderungen an Gesamtbuchungsbild nach sich.<br><br>
OrgaMon setzt hier auf Buchungsintelligenz, die schon im Konto-Deckblatt definiert ist. Jede Buchung in ein Konto durchläuft dann die individuelle Qualitätssicherung dieses Kontos. Die Logik wird durchgängig und ohne Ausnahme angewendet und ist transparent anpassbar. Durch eine möglichst späte "Fixierung" der Buchungssätze, die jedoch immer innerhalb der Forderungen der Wirtschaftsprüfer liegt, wird maximale Flexibilität und Fehlerfreiheit des Endergebnisses erreicht. Stornobuchungen werden vermieden und die Transparenz und Verständlichkeit der Buchführung erhöht</i><br><br>


== Verwandte Themen ==
== Verwandte Themen ==
Zeile 6: Zeile 8:
[[Steuersaetze|Steuersätze]]<br>
[[Steuersaetze|Steuersätze]]<br>
[[Forderungsausgleich]]<br>
[[Forderungsausgleich]]<br>
[[Kasse]]<br>


== Einleitung ==
== Einleitung ==
Zeile 19: Zeile 22:


Buchung = "Initialer Buchungssatz" & "Buchungs Schema"
Buchung = "Initialer Buchungssatz" & "Buchungs Schema"
== Begriffe ==
* '''Konto''': ein Buch mit einer Nummer als Namen, z.B. 8400.
* '''Konto-Bewegung''': ist ein einzelner Buchungs-Vorgang in einem Buch. Der Betrag der gebucht wird erhöht oder vermindert den Saldo des KOntos.
* '''Saldo''': Ergebnis der Summierung aller Konto-Bewegungen. Dabei sind Haben buchungen positiv und Soll-Buchungen negativ.
* '''initialer Buchungssatz''': Die eingentliche Grund-Eingabe des Geschäftsvorganges, sie ist Auslöser für alle weitere Buchungen. Im Mittelalter gab es das Hauptbuch genannt die Kladde. Hier trug der Vorsteher an seinem Pult ALLE Buchungen zunächst ein. Aus dem Kontext oder durch Hinweise ergab sich dann, dass so eine einzelne Eintragungszeile in weitere Bücher übertragen werden musste (Konzept der doppelten Buchführung). Diese Aufgabe erfüllten nun geringer qualifizierte Schreiber, da es sich mehr oder minder um Abschriften aus der Kladde handelte.
* '''Folgebuchungssatz''': wurde durch einen initialen Buchungssatz ausgelöst. Durch ein Regelwerk sowie Angaben im initialen Buchungssatz sind diese Folgesätze automatisch entstanden.
* '''Konto-Deckblatt''': Jedes Zielkonto hat ein Deckblatt im dem Buchungsregeln definiert weren können. z.B. ein Vorzeichenwechsel, wird also ein Folgesatz in dieses Konto-Buch geschrieben
* '''Schema''':
* '''Stempel''':
* '''ungebucht''': Ein initialer Buchungssatz, der eine Gegenkonto trägt aber kein Buchungsdatum, diese Buchungen werden durchgestrichen dargestellt


== Kontenrahmen ==
== Kontenrahmen ==


Der SK03-Kontenrahmen ist als eine Ansammlung von Konto-Deckblättern definiert. Die Deckblätter definieren die Standards beim Buchen auf dieses Konto. Bender wird die Regeln entsprechend anwenden.
Als Startpunkt für ihre individuellen Anpassungen liegen den OrgaMon die Kontenrahmen SKR03 und SKR04 vor. Nach der Festlegung auf einen dieser Grundgerüste können auch im laufenden Betrieb neue Konten definiert werden. Ein Kontenrahmen ist als eine Ansammlung von Konto-Deckblättern definiert. Die Deckblätter definieren die Standards beim Buchen auf dieses Konto. Bender wird die Regeln entsprechend anwenden. Besonderen Konten werden vielfach im OrgaMon direkt angesprochen:<br>
<br>
 
=== Konten, auf die automatisch gebucht wird ===
 
* '''SATZ1''' voller Satz: Vorsteuer (die negativen Beträge) / Umsatzsteuer (die positiven Beträge)
* '''SATZ2''' verminderter Satz: Vorsteuer (negativer Betrag) / Umsatzsteuer (positiver Betrag)
* '''SATZ3''' andere Sätze (z.B. aus Vorjahr)
* '''1000''' Kasse
* '''1010''' Kartenzahlung
* '''1200''' Hauptkonto für Zahlungen aus dem Lastschriftverfahren
* '''1260''' SEPA-Mandate der Kunden zur einmaligen Anwendung, speziell passend zu einer Forderung
* '''1400''' Ausgangsrechnungen. Auch Forderungskonto.
* '''1590''' durchlaufender Posten (Buchungen ohne ER/AR Bedeutung)
* '''1710''' Anzahlungen, solange Forderungen nicht vollständig bezahlt sind landen Buchungen auf diesem Konto, erst bei der vollständigen Zahlung erfolgt der Forderungsausgleich über 8200
 
=== Erlöskonten ===
 
* '''8200''' Erlöse (reines Verteilerkonto, hier ist oftmals Schema=Beleg eingetragen!) auf diesem Konto sollte nicht direkt gebucht werden!
** '''84xx''' Jedem Sortiment kann ein eigenes Erlöskonto zugeordnet werden
** '''8400''' Erlöse (z.B. aus Programmierarbeiten)
** '''8405''' Erlöse (z.B. aus Server-Vermietung)
* '''8450''' Erlöse aus freiem Verkauf, also Artikeln/Dienstleistungen ohne Sortimentszuordnung
 
=== Umsatzsteuerzahlungen ===
 
* '''1780''' laufende Abbuchungen des Finanzamtes aufgrund der jeweiligen Umsatzsteuer-Voranmeldungen
* '''1790''' Dezember-Betrag der Umsatzsteuer-Voranmeldung, dieser wird in der Regel im Januar des Folgejahres gebucht
* '''1791''' Differenz-Abbuchung des Finanzamtes aufgrund der Umsatzsteuererklärung (=Differenzbetrag aus "Erklärung" - "Summe der Voranmeldungen")


== Initialer Buchungsatz ==
== Initialer Buchungsatz ==
Zeile 28: Zeile 71:
Eine Quelle (Konto) initiert eine Betragsbuchung mit gewissen Parametern in Richtung Ziel. Auf dem Weg zum Ziel können mehrere Folgesätze enstehen. Mussfelder dieses Buchungssatzes sind:  
Eine Quelle (Konto) initiert eine Betragsbuchung mit gewissen Parametern in Richtung Ziel. Auf dem Weg zum Ziel können mehrere Folgesätze enstehen. Mussfelder dieses Buchungssatzes sind:  


* Quellkonto  
'''Betrag<br>
* Betrag
von '''Quellkonto'''<br>
* Zielkonto
nach '''Zielkonto'''<br>


dazu kommen noch Umfeldparameter die dem Buchungsmotor als Grundlage für weitere Entscheidungen dienen.
dazu kommen noch Umfeldparameter die dem Buchungsmotor als Grundlage für weitere Entscheidungen dienen.


* Standardbuchung oder Stornobuchung oder ein anderes Schema
'''Skript'''<br>
* Mwst Anteil 7%
* MwSt Anteil 19%
* Ausländer JA/NEIN
* Zahlungsart
* Person um die es geht usw.
* Vorgang


Der verwendete Buchungs-Schema ist ableitbar aus den Parametern des Initialen Buchungssatzes. Das Schema gibt Hinweise darüber mit welchem Motor der "initiale Satz" weiter verarbeitet werden soll. Schemen sind nicht nur Konto - Individuell sondern Kategorie - Individuell, das bedeutet eine Buchung von "Forderungen" nach "Bankkonto X" erfordert ein Schema "Forderungen->Bankkonto X" welches der Buchungsmotor nachlädt und auswertet.
* <code>SATZ=1[";"<MwSt-Betrag>[";"<Skonto>]]</code> der angegebene Mehrwertsteuer-Betrag wird in voller Höhe auf das Konto SATZ1 verbucht. Ist kein direkter Geldbetrag angegeben wird der MwSt Anteil berechnet. Wurde bei einer Eingangsrechnung Skonto gewährt und ausgeschöpft, so muss der auf der Rechnung ausgewiesene MwSt-Betrag angegeben werden, danach ";" und der Skontierungs-Prozentsatz (i.d.R. 1,2 oder 3%)<br>
* <code>BETRAG=Betrag[";"<Konto>]</code> Damit kann gesteuert werden, dass nur ein Teilbetrag des gesamten Betrages auf ein Gegenkonto gebucht wird. Das Zielkonto (normalerweise im Gegenkonto angegeben) kann überschrieben werden.<br>
* <code>STEMPEL=</code> Prefix-Bezeichnung des zu verwendeten Stempels. z.B. <b>ER</b> oder <b>AR</b>. Die Angabe von <b>NEIN</b> verhindert die Verwendung eines Stempels<br>
* <code>VORZEICHENWECHSEL=JA</code> Bewirkt, dass beim Übergang auf das Gegenkonto das Vorzeichen des Betrages gewechselt wird.<br>
* <code>BELEG=<BelegRID>[";"<Teillieferung>[";"<Betrag>]]</code> bewirkt dass mehrere Belege durch eine Zahlung ausgeglichen oder Angezahlt werden.
* <code>BAR=NEIN</code> verhindert, dass dieses Konto im Kassen-Dialog "Bar" angezeigt wird.
* <code>POSNO=<POSNO></code> setzt die Positionsnummer auf den angegebenen Wert
* <code>VORGANG=<VORGANG-TEXT></code> setzt den Vorgang-Text auf den angegebenen Wert überschreibt also die Vorgabe der Bank
* <code>EREIGNIS=<EreignisRID></code> setzt den EREIGNIS_R der Folgesätze auf den angegebenen Wert
* <code>Sortierung=SQL</code>überschreibt die Sortierung der Buchungssätze bei der Anzeige dieses Kontos
** default: Sortierung=DATUM,POSNO
** Deckblatt-Default: Sortierung=NAME
** Anzahlungen-Default: Sortierung=BELEG_R,TEILLIEFERUNG,DATUM,POSNO
** 1200-Default: Sortierung=EREIGNIS_R,POSNO,RID
** 1010-Default: Sortierung=EREIGNIS_R nulls last,DATUM,RID
 
Das verwendete Buchungs-Schema ist auch ableitbar aus den Parametern des Deckblattes, es muss nicht alles im initialen Buchungssatzes angegeben werden. Das Schema gibt Hinweise darüber mit welchem Motor der "initiale Satz" weiter verarbeitet werden soll. Schemen sind nicht nur Konto - Individuell sondern Kategorie - Individuell, das bedeutet eine Buchung von "Forderungen" nach "Bankkonto X" erfordert ein Schema "Forderungen->Bankkonto X" welches der Buchungsmotor nachlädt und auswertet.


== Schema der Buchung ==
== Schema der Buchung ==
Zeile 48: Zeile 101:
Ein Schema ist ein vorgefertigtes Regelwerk, welches den initialen Buchungssatz interpretiert, und alle Folge-Buchungssätze daraus entwickelt. Auch werden ggf. Ergänzungen am initialen Buchungssatz durchgeführt (z.B. Stempel oder das Buchungsdatum)<br>
Ein Schema ist ein vorgefertigtes Regelwerk, welches den initialen Buchungssatz interpretiert, und alle Folge-Buchungssätze daraus entwickelt. Auch werden ggf. Ergänzungen am initialen Buchungssatz durchgeführt (z.B. Stempel oder das Buchungsdatum)<br>


'''Schema=Beleg'''
=== Schema=Standard ===
 
dies ist das Standard-Schema, und muss nicht extra angegeben werden.
 
Schemen können auch Budgets berücksichtigen und je nach Ausschöfpung oder Überbeanspruchung sich anders verhalten, oder auch Buchungen ablehnen. Einfache Motoren erzeugen aus einer Initial-Buchung EINEN Folgesatz im Zielkonto. Komplexere Motoren wie z.B. in "Vorsteuer" oder "Budgets" können weitere Buchungen durchführen.
 
==== Beispiel ====
 
* Ein Betriebsmittel soll abgeschrieben werden, deshalb soll nur der MwSt-Anteil sofort verbucht werden, der Netto-Betrag soll auf 1590 gebucht werden (1590 bei GEGENKONTO eingeben). Der Rechnungsbetrag war -5052,90 €. Somit wird der Netto-Anteil auf 1590 gebucht, aber dennoch ein SATZ1 Anteil auf die Vorsteuer.
 
SATZ=1


* BELEG_R enthält hier die Belegnummer die Verbucht werden soll.
=== Schema=Beleg ===
* STEMPEL enthält die Nummer der TEILLIEFERUNG die verbucht werden soll.


'''[Schema=Standard]'''
==== BELEG= ====
 
<code>
BELEG=BELEG_R[";"TEILLIEFERUNG[";"Betrag]]<br>
BELEG=BELEG_R[";"TEILLIEFERUNG[";"Betrag]]<br>
BELEG=BELEG_R[";*"[";"Betrag]]<br>
...<br>
</code>
 
* Wird <TEILLIEFERUNG> wegelassen, so wird von der TEILLIEFERUNG 0 ausgegangen
* Wird bei <TEILLIEFERUNG> ein "*" (Stern) angegeben wird der GEsamtbetrag einfach auf alle Teillieferungen verteilt, dies ersetzt einfach die Mühe den aktuellen BEtrag in mehrere BELEG= Zeilen aufzuteilen. Der Gesamtbetrag muss dann aber auch 100% passen.
* Wird <Betrag> weggelassen, so wird der Gesamtbetrag des initialen Buchungssatzes als Zahlbetrag benutzt
 
==== BETRAG= ====
 
<code>
BETRAG=DerBetragDerVerwendetWerdenSoll[";" Gegenkonto]<br>
</code>
 
* Beim Forderungsausgleich muss man nicht 100 % des Betrages zum Ausgleich verwenden, mit <code>BETRAG=</code> kann angegeben werden, dass nur dieser Teil für den Forderungsausgleich verwendet werden soll. Den Restbetrag bucht der OrgaMon auf das angegebene Ausbuchungskonto
* Ist kein Gegenkonto angegeben, so wird 1590 verwendet.
 
=== Schema=Folge ===
 
==== BETRAG= ====
 
* Es wird nicht nur in ein einzelnes Gegenkonto gebucht, sondern auf alle im Skript angegebenen Konto der Gesamtbetrag verteilt. Der im jeweiligen Deckblatt definierte Satz wird hier benutzt. Der "SATZ=" Eintrag ist im Deckblatt deshalb zwingend erforderlich.
* Beim Betrag muss (in der Regel "-", da oft eine Ausgabe verbucht wird) der Bruttobetrag (d.h. die Summe incl. der MwSt.) eingetragen werden
 
<code>
BETRAG=BruttoBetrag[";" Ziel-Konto[";" {Skript"|"}]]
</code>
 
==== Beispiel ====
 
<code>
Schema=Folge<br>
BETRAG=-15;1590<br>
BETRAG=-6;3200;SATZ=0<br>
BETRAG=-12;3200<br>
</code>
 
* Bucht -15,00 Euro auf 1590
* Bucht -6,00 Euro auf 3200 überschreibt dabei den im Deckblatt definierten Satz auf den Wert "0"
* Bucht -12,00 Euro auf 3200, diesmal mit dem im Deckblatt angegebenen Satz
 
==== SATZ= ====
 
=== Schema=Saldieren ===
 
 
  Einzelbuchung "1"        156,72 €
  Einzelbuchung "2"        17,43 €
  Einzelbuchung "3"        149,97 €
  Einzelbuchung "4"        34,50 €
  Einzelbuchung "5"        60,09 €
  Einzelbuchung "6"        81,35 €
  Hauptbuchung            -500,06 €
                        ===========
  Saldo                      0,00 €
 
* OrgaMon hilft mit diesem Schema einen Aspekt der Buchführung zur erreichen: Sich gegenseitig ausgleichende Buchungen. Das bedeutet die Summe der Beträge sollte 0,00 € sein
* Es wird versucht, zur Hauptbuchung "unsaldierte" Einzelbuchungen zu finden, so dass bei Addition aller Beträge ein Saldo von 0 entsteht
* in der entstandenen Buchungs-Gruppe trägt jeder Datensatz den selben EREIGNIS_R, die Ereignis-Art ist "ZahlungEC" = 40
* da der Hauptbuchungssatz (z.B. BSCARD) in der Regel auf einem Girokonto entsteht hat dieser bereits einen anderen EREIGNIS_R (aus dem HBCI-Kontenabruf)
* Für die Gruppen-Identifizierung wird jedoch im SKRIPT ein EREIGNIS=nnn eingetragen
* gelingt es nicht den Saldo "0" zuerreichen, bleibt der Hauptbuchungssatz <s>ungebucht</s> und es muss manuell nachgeholfen werden
* Aus dem Hauptbuchungssatz wird versucht die Anzahl der Einzelbuchungen aus dem Text/Verwendungszweck zu ermitteln (z.B. "ANZAHL 6")
* OrgaMon geht so vor, dass nach Buchungsmoment sortiert die unsaldierten und bisher ungruppierten Beträge aufaddiert werden, bis 0 erreicht ist
 
==== Anwendung EC-Cash ====
 
* Einzelbuchungen: EC-Cash-Zahlungsvorgänge werden gebucht als vollständiger Zahlungsausgleich einer Teillieferung eines Beleges in "Z" (nicht im Forderungsausgleich!). Der EC-Cash Betrag muss dabei genau dem Betrag des Beleges entsprechen, gibt es Abweichungen muss "Trinkgeld" oder "Forderungsverlust" auf dem bestehenden Beleg nachgebucht werden (Es ensteht ev. eine weitere Teillieferung) Die Teillieferungen werden zusammen bezahlt.
** Bei der Zahlung kreuzt man an "EC Kartenzahlung"
** So entstehen Einzelbuchungen auf dem Konto 1010
* Hauptbuchung: Irgendwann kommt eine Sammelbuchung des Zahlungs-Dienstleisters als Gutschrift auf dem Girokonto
** diese muss auf 1010 im Gegenkonto gebucht werden.
** Durch Worte z.B. "BSCARD" kann hier auch Autobuchen zur Vereinfachung benutzt werden
** Im Verwendungszweck/Text sollte "ANZAHL nnn" angegeben werden, damit OrgaMon einen Hinweis auf die Anzahl der Einzelbuchungen verwenden kann
** Damit OrgaMon Einzelbuchungen zuordnen kann muss immer die älteste BSCARD Buchung zuerst verbucht werden.
** Es wird versucht den Saldo von 0,00 sicherzustellen. Kommt es zu Problemen wird eine Fehlermeldung ausgegeben
 
 
* OrgaMon geht so vor dass er die ältesten und bisher nicht gruppierten Einzelbuchungen einsammelt und versucht dem aktuellen BSCARD zuzuordnen, stimmt der Saldo und die Anzahl wird der Vorgang beendet
* lässt man eine BSCARD Buchung aus und bucht zuerst die spätere BSCARD Buchung wird die Zuordnung niemals gelingen
 
==== 1010 Deckblatt ====
 
<b>Skript</b>
 
STEMPEL=NEIN
VORZEICHENWECHSEL=JA
Schema=Saldieren
Sortierung=EREIGNIS_R nulls last, DATUM, RID
 
<b>Text</b>
 
[BSCARD]
SKRIPT=
  COLOR=#00FF66
 
==== 1010 Probleme ====
 
* Um 1010-Problematiken zu lösen hat man einige Möglichkeiten, wechseln Sie in die Ansicht Konto 1010
* Steht man auf einem Buchungsblock, der "0" werden soll (egal ob BSCARD Buchungssatz oder die einzelnen Gegenbuchungen) kann man mit der Symbolknopf <code>S</code> die Saldierung auf die aktuelle Gruppe anwenden, <code><b><span style="color:#ff1111">S</span></b></code> wird rot (aktiv) ausgegeben die Summe oberhalb von "Haben" sollte "0" sein
* Einzelbuchungen die fälschlicherweise in einer Gruppe sind nimmt aus der Gruppe indem man den EREIGNIS_R rauslöscht, damit ist es wieder eine freie/zukünftig wieder zuordenbare Einzelbuchung
* Einzelbuchungen die nicht automatisch zugeordnet werden konnten, teilt man der Gruppe zu, indem man manuell einen Eintrag in EREIGNIS_R macht, und zwar den EREIGNIS_R der "Wunschgruppe". Notieren Sie sich vorher den passenden EREIGNIS_R der Gruppe
* Wurde etwas "nicht OrgaMon bezogenes" per EC-Cash eingezogen erstellt man einen neuen Datensatz (Symbolknopf "+" in der Anzeige eines anderen einzelnen Datensatz). Nur 4 Eintragungen müssen hier gemacht werden:
** in "Konto" <code>1010</code>,
** in "Text" <code>Stornobuchung</code> oder eine andere Begründung in Textform
** in "Betrag" den Betrag so geschickt berechnet dass der Saldo nun stimmt.
** in EREIGNIS_R den passenden Wert für diese Gruppe


dies ist das Standard-Schema, und muss nicht extra angegeben werden.


Schemen können auch Budgets berücksichtigen und je nach Ausschöfpung oder Überbeanspruchung sich anders verhalten, oder auch Buchungen ablehnen. Einfache Motoren erzeugen aus einer Initial-Buchung EINEN Folgesatz im Zielkonto. Komplexere Motoren wie z.B. in "Vorsteuer" oder "Budgets" können weitere Buchungen durchführen.
* Es kann Situationen geben, in denen man die komplette Gruppe auflösen will, man geht auf eine beliebige Einzelbuchung öffnet diese und drückt Symbolknopf <code><s>S</s></code> (durchgestrichenes S)
* Der Hauptdatensatz behält hier den alten EREIGNIS= da dieser im SKRIPT eingetragen ist und nicht im Feld EREIGNIS_R (dort steht der EREIGNIS_R des HBCI-Kontenabrufes)
** Da der EREIGNIS= für die Sortierung der Datensätze verwendet wird, ist es sinnvoll bei Auflösung von ganzen Gruppen auch diese Zeile im Hauptdatensatz zu löschen, damit wird OrgaMon gezwungen wiederum einen neuen EREIGNIS_R für diese Gruppe zu erzeugen


'''Buchungs Log'''
== Buchungs Log ==


Probleme auf dem Buchungsweg werden im Log aufgezeichnet - Im kritischen Fehlerfall wird das Log angezeigt.
Probleme auf dem Buchungsweg werden im Log aufgezeichnet - Im kritischen Fehlerfall wird das Log angezeigt.
Zeile 65: Zeile 239:
'''Erfolgreiche Verbuchung'''
'''Erfolgreiche Verbuchung'''


War Bender erfolgreich, so trägt er ein "OK" in den initialen Buchungssatz ein.
War Bender erfolgreich, so trägt er ein "OK" in den initialen Buchungssatz ein indem er in "GEBUCHT" den aktuellen Moment einträgt
 
== PDF-Dokumente ==
 
* Eingangs- und Ausgangsrechnungen können als PDF-Belege gespeichert werden. So ist eine beleglose Buchführung möglich. Dabei hilft der OrgaMon mit dem PDF-Symbol ("alle PDF Zuordnungen prüfen") dabei fehlende Belege aufzuspüren und zuzuordnen.
* Bei der Anzeige eines Buchungssatzes können alle dazugehörende PDF-Dokumente eingesehen werden.
* Bei der Übergabe von Daten an den Steuerberater mit der Funktion "Zahlung-Verwaltung-CSV-Schnittstelle-Start" werden alle PDF-Belege zusammen mit dem Buchungsjounal in ein Verzeichnis gepackt.
 
=== Dateinamenskonvention ===
 
Der Dateinamen setzt sich zusammen aus
 
"Stempel-Name" "-" "Stempel-Nummer" "-" "beliebiger bisheriger Name" ".pdf"
 
Beispiel
#
# typische PDF Rechnung der Telekom
#
ER-2716-2017_09rechnung_4726186958_sign.pdf
 
 
 
=== Pfadkonvention ===
 
im Buchungssatz kann PERSON_R eingetragen werden. Im Dokument-Verzeichnis der Person (.\Rechnungen\~PERSON_R~) werden die Dokumente gespeichert. Die Funktion "PDF-Symbol" trägt die PERSON_R beim Buchen automatisch nach, sollte sich das Dokument bereits im "richtigen" Personen-Dokument-Verzeichnis befinden. So können Dokumente auf Verzeichnisebene korrekt verteilt werden ohne auch noch PERSON_R eintragen zu müssen.
 
=== Kontrolle ===
 
* die Kontrollfunktion führt folgende Aktionen aus
** bereits korrekt auffindbare PDF in den Unterverzeichnissen erhalten die BUCH.PERSON_R automatisch nachgetragen
** Finden sich PDF in falschen Verzeichnissen wird gewarnt, unabhängig davon ob bereits eine Doublette im richtigen Verzeichnis ist
** Wird das PDF nicht gefunden wird gewarnt


== Folge-Buchungsatz ==
== Folge-Buchungsatz ==


Dies sind Buchungen, die von einem Motor erzeugt wurden. Diese sind per Definition nicht veränderbar. Stimmen hier Dinge nicht ist am Schema oder am Motor oder am Initialen Buchungssatz etwas zu verändern. Ein erneutes initiieren der Buchung ist jederzeit möglich.
Dies sind Buchungen, die von der Bender-Logik erzeugt wurden. Diese sind per Definition nicht manuell veränderbar, sondern deren Inhalt ergibt sich zwingend aus dem Hauptbuchungssatz (Initialier Buchungssatz). Stimmen hier Dinge nicht, ist am Schema oder an der Bender-Logik oder am initialen Buchungssatz etwas zu verändern. Ein erneutes initiieren der Buchung ist jederzeit möglich, solange der initiale Buchungssatz nicht fixiert wurde. Dabei werden alle Folgebuchungssätze des einen initialen Buchungssatzes gelöscht und NEU erstellt.
 
=== Endsatz ===


== Finden der Buchungsregeln ==
Dies ist eine Folge-Buchung, aus der selbst wiederum keine Folgebuchungen entstehen.


Vor einem Buchungsvorgang wird versucht eine Buchungsregel für diesen Buchungstyp die passende Regel zu suchen. Hat man bei der Buchung ein Ziel-konto angegeben so finden sich Regeln für diese Buchung im Konto-Deckblatt des Ziel-Kontos.
=== Zwischensatz ===


== OrgaMon Ereignis kann Auslöser sein ==
Dies ist eine Folge-Buchung, aus der weitere Folgebuchungen oder Endsätze entstehen können:


Gewisse Ereignisse im OrgaMon, z.B. "es entsteht durch einen Verkauf eine Forderung", oder "Kontobewegung auf einem externen, mit HBCI geführten Konto" erzeugen einen "Initialen Buchungssatz" dieser enthält folgende Informationen. Um ein Ereignis Buch verändernd zu gestalten muss man die Ereignistabelle um einen entsprechenden Prototyp erweitern. Entsteht wieder ein Ereignis mit vorhandenem Prototyp, wird ein -> Initialer Buchungssatz erzeugt.
* Beispiel: Eine letzte Teilzahlung geht auf das Teilzahlungskonto (Konto->1710). Sie ist genau so hoch, dass nun die Summe aller Teilzahlungen die Forderungssumme ergeben. Dies nimmt Bender zum Anlass eine Gegenbuchung durchzuführen (-Betrag->8200), dies ist ein Folgesatz - der aber weitere Buchungen zur Folge hat, als wäre es ein "initialier Buchungssatz".


== Aufbau der Tabelle BUCH ==
== Finden der Buchungsregeln ==


RID : eindeutiger ID dieser Buchung
Vor einem Buchungsvorgang wird versucht eine Buchungsregel für diesen Buchungstyp die passende Regel zu suchen. Hat man bei der Buchung ein Ziel-konto angegeben so finden sich Regeln für diese Buchung im Konto-Deckblatt des Ziel-Kontos.
FIXIERT: Y/N ist eine Änderung möglich
 
MANDANT_R: Buchungscontext (->PERSON_R)
== Suche von Buchungssätzen ==
MOMENT: (date+time) Buchungsdatum
BEARBEITER_R: der Buchende (leer bei folgeDatensätzen)
MASTER_R: RID der Initial Buchung, Ist dieses Feld <> eigener RID ist dies ein Folgesatz
          Bei einer Änderung am MASTER werden alle Folgesätze gelöscht, und neu gebucht.
          Änderungen an Folgesätzen sind eigentlich nicht möglich.
KONTO : (Quelle) alphanumerisches Feld, 15 Stellen
KONTO_NAME : (Quelle) 64 Buchstaben
IBAN : (Quelle) 35 Buchstaben
VORGANG: Gibt Zusatzinformationen wie die Buchung zustande kam. Art der Buchung
          Rückschlüsse auf die Quelle ist so auch möglich.
GEGENKONTO: (Ziel) alphanumerisches Feld, 15 Stellen
 
//
SCRIPT: (Text-Feld) Buchungsinfos wie Aufteilung in MwST Sätze usw.
TEXT: (Text-Feld) Überweisungstext
BEMERKUNG: (Text-Feld) weitere Hinweise zu dieser Buchung
STEMPEL_NO: (integer) fortlaufende Stempelnummer f?egstempel
STEMPEL_R: (Referenz) Prefix des Stempels "AR" oder "ER" z.B.
DATUM: [date+tme] Belegdatum
WERTSTELLUNG: [date+time] (Valuta) Zinzrelevanz z.B. bei Budgetkonten oder Girokonten.
VERFUEGBAR: [date+time] Wann das Geld verwendbar ist, dieses Datum unterschlagen deutsche Banken im Moment.
 
BETRAG_S: [double] Betrag der Soll Seite (+/-)
BETRAG_H: [double] Betrag der Haben Seite (+/-)
PERSON_R: (Referenz) Bezugnahme zu einer Person.
BELEG_R: (Referenz) Bezugnahme zu einem Beleg.
EREIGNIS_R: (Referenz) Bezugnahme zu einem Ereignis.
// Periode, auf die sich die Buchung bezieht
// z.B. Lohn: Abrechnungs Beschäftigungszeitraum, z.B. 01.01.07-31.01.07
GELTUNG_VON: [date+time]
GELTUNG_BIS: [date+time]
GELTUNG: [varchar]
  Geltungsbereiche für die Buchhaltung. (Idee aus OrgaMon-Hausverwaltung
      übernommen:).
      'D' : Dieser Tag, bezogen auf "DATUM"
      'M' : Dieser Monat, bezogen auf "DATUM"
      'Q' : Dieses Quartal, bezogen auf "DATUM"
      'J' : Dieses Jahr, bezogen auf "DATUM"
// Stempel
STEMPEL_R : Referenz auf einen OrgaMon Stempel
STEMPEL_NO : Eine Stempel-Nummer aus HBCI oder anderes Fremdsystem (Primanota)
STEMPEL_DOKUMENT : Ein aus dem Stempel mit RID=STEMPEL_R erzeugte Beleg-Buchungs-Nummer
"Bender" ist ein Buchungsroboter, der entweder im Hintergrund eine Buchungsregel abarbeitet,
oder mit Hilfe von konfigurierbaren Eingabe-Dialogen Buchungsgrundlagen sammelt, um im
Anschluss eine umfassende Buchung durchzuführen. Durch ein Satz von Assistenten hilft
Bender beim Auffinden von Belegen, Personen und Artikeln.
Einzelne Felder haben auswahl-Hilfslisten, die kontextgerecht vorbelegt werden. z.B.
offene Forderungen aus Belegen des Kunden "x". Oder offene Forderungen aus Belegen
mit der Planungszahlungsart "Kreditkarte".
+BENDER (BuchungsRegelwerk, Buchungsmotor, Buchungsvorlage)
Bezeichnung
  "VK ohne Umsatzsteuer"
  "VK Schulen"  "VK Händler Ausland"
  "VK mit USTID
  "VK ohne USTID
  "VK gewerblich"
  "BZ Kreditkarte"
  VK = Verkaufsvorgang
  BZ = Bezahlvorgang
Zahlungsart - Lastschrift
Standard-Zahlungsart -Überweisung


== Eingaben in der Kladde ==
* B<BetragInCent> also B10000. sucht den Betrag 100,00 Euro (man beachte den Punkt am Ende)
* K<Name> also K1590 sucht das Konto 1590
* G<Name> also G8200 sucht das Gegenkonto 8200
* BELEG<Nummer> also BELEG54002 sucht alle Buchungen im Zusammenhang mit diesem Konto
* E<Nummer> sucht alle Buchungen im Zusammenhang mit dem Ereignis <Nummer>


'''Skript'''
== Automatische Buchung (AutoBuchen) ==


* <code>SATZ=1[";" <Betrag>]</code> der Gesamtbetrag wird der MWST-Satz vom SATZ1 verbucht. Ist ein direkter Geldbetrag angegeben wird nicht gerechnet, sondern der angegebene Betrag wird direkt so in den entsprechenden SATZ gebucht.<br>
* Auf dem Deckblatt eines Kontos kann im Feld <code>Text</code> definiert werden, im welchem Fall automatisch auf dieses Konto gebucht werden darf
* Eine automatische Buchung wird dann ausgeführt sobald ein Buchungssatz gewisse Suchbegriffe enthält
* Der Suchbegriff wird in eckigen Klammern dargestellt


* <code>BETRAG=</code> Es wird nicht der Gesamtbetrag verbucht, sondern nur ein Teil.<br>
[Müller B67500.]
SKRIPT=
  Schema=Folge
  BETRAG=
+BETRAG=465;8210
+BETRAG=210;4970
  COLOR=#00FF66
BAUSTELLE_R=6


* <code>STEMPEL=</code> Prefix-Bezeichnung des zu verwendeten Stempels.<br>
* In diesem Beispiel würde bei einem Buchungssatz bei dem "Müller" enthalten ist, und der Buchungsbetrag=675,00 € beträge automatisch folgende Schritte durchgeführt
** Gegenkonto auf die Kontonummer des Deckblattes
** Im Eingabefeld "SKRIPT" werden die folgenden Änderungen gemacht
*** <code>Schema=Folge</code> wird erzwungen
*** Alle <code>BETRAG=</code> werden gelöscht
*** <code>BETRAG=465;8210</code> wird hinzugefügt
*** <code>BETRAG=210;4970</code> wird hinzugefügt
*** <code>COLOR=#00FF66</code> wird erzwungen
** BAUSTELLE_R wird auf #6 gesetzt


== Buchung eines Zahlungsausgleiches ==
== Buchung eines Zahlungsausgleiches ==
Zeile 199: Zeile 359:
* der Pauschalbucher bucht alle Einkünfte nach 8400
* der Pauschalbucher bucht alle Einkünfte nach 8400
* der Sortimentbucher erzwingt die Kontonummern-Eingabe bei jedem Sortiment, damit alle Artikel korrekt verbucht werden können. Hierbeit ist eine sehr individuelle Splittung der Eingangskonten möglich, die eine betriebswirtschaftliche Auswertung informativer macht.
* der Sortimentbucher erzwingt die Kontonummern-Eingabe bei jedem Sortiment, damit alle Artikel korrekt verbucht werden können. Hierbeit ist eine sehr individuelle Splittung der Eingangskonten möglich, die eine betriebswirtschaftliche Auswertung informativer macht.
=== Rundungsproblem im Sortimentbucher ===
# Berechnet man die 19% Umssatzsteueranteil an einem Preis, so kommt nicht immer ein exakter Steuer-Anteil raus, sondern eine Kommazahl, die man jedoch unten in der Rechnung runden muss. Beispiel:
## Brutto-Preis ist 4,99 Euro,
## das sind 4,19 + 0,7961 MwSt, sprich 0,80 Cent MwSt
# Der OrgaMon rundet (pro mwSt-Satz) bei Rechnungen genau 1 mal
# Die Buchhaltung rundet je Konto 1 mal
Beispiel
8400 Leistungen 19%
8401 Medikamente 19%
also rundet er "2x" was natürlich eine Differenz zur Methode "1x runden" ergibt.
Lösung: der Gesetzgeber kennt diese Problematik und sagt: Egal was ein Nachrechnen mit welcher Methode auch immer ergäbe (Es gibt ja auch verschiedene Rundungsverfahren (kaufmännische, mathematische)) gibt und einfach die MwSt, die auf der Rechnungs ausgewiesen ist!!
-> Das bedeutet für uns:
Die Summe der 2 "SATZ1" Buchungen in 8400 und 8401 muss ganz genau den auf der Rechnung ausgewiesen Betrag ergeben, es gibt keine Grund dafür, dass hier wie es klassische EDV-Buchhaltungs-Systeme machen ein Rundungsdifferenzkonto oder ähnliche Scherze einzuführen:
# der Korrektur-Betrag muss in ganzen Cent berechnet werden
# beginnend mit dem Wertmäßig höchstem MwSt-Betrag muss begonnen werden, und eine "1" Cent Korrektur muss erfolgen
# dann der nächst kleinere Betrag, bis der Korrektur-Betrag=0 ist.
== Transaktionen ==
=== BI1 ===
Im aktuellen Skript wird
BELEG=<BELEG_R>;<TEILLIEFERUNG>;<BETRAG>
nachgetragen.
== Saldo ==
* Die Kontostands- oder Salden-berechnung bei Giro-Konten erfolgt über Abschlussbuchungen
* dies sind Buchungen mit dem Vorgang <code>ABSCHLUSS (805)</code> oder <code>ENTGELTABSCHLUSS (809)</code> oder <code>ZINSEN/ENTG. (805)</code>
* wird dieser Vorgang erkannt, steht ABSCHLUSS (grau hinterlegt) in der Umsatzliste
** nur in diesem Fall ist es sinnvoll in der Buchung einen Abschluss-Betrag einzutragen
* im Buchungstext wurde früher ein Abschlussbetrag mitgeliefert, ich glaube seit der CAMT Umsatzabfrage wird dieser Wert nicht mehr übertragen
* mit dem Abschlussbetrag ist es möglich einen korrekten Kontostand zu berechnen
* Man kann nun aber einen Wert manuell eintragen, und somit einen falschen Saldo zu korrigieren
** suche mit dem Suchbegriff "ABSCHLUSS." die letzte Abschlussbuchung (vorher eventuell das Refresh-Symbol links vom Suchbegriff drücken)
** Öffne die unterste Buchung mit dem Wort "ABSCHLUSS"
** gebe hier rechts neben dem Betrag im Eingabefeld Abschluss eine "0" ein
** mache einen normalen Umsatz-Abruf im Reiter "HBCI-Umsatzabfrage" damit Du auf dem neuesten Stand bist
** hake nun <code>[v] nur Saldenabruf</code> an, dann nochmals "Umsatzabruf starten"
** berechne den Wert "Saldo laut aktueller Abfrage" <b>MINUS</b> "Saldo laut Buch" und überschreibe damit die eingegebene "0" von eben
<b>Der Saldo (Kontostand) des Girokonts muss jetzt stimmen!</b>
== Tipps ==
=== Zusammenlegen von Teilzahlungen ===
* Im "Z" die Spalte TL ändern (zb. von 2 auf 1)
* Im Versand-LKZ die Spalte TL ändern (zb. von 2 auf 1)
* In GELIEFERT die zusammenlegung noch machen, mit folgendem OLAP
update geliefert set
  POSNO = 1
where
  (beleg_R=55571) and
  (POSNO=2)
(immer diese Beiden Änderungen zusammen machen)
=== Anpassen des Betrages "GELIEFERT" ===
das ist meiner Meinung nach unmöglich!

Aktuelle Version vom 4. November 2024, 14:06 Uhr

Die doppelte Buchhaltung hat interessante Grundsätze, denen die Praxis jedoch schnell und regelmäßig entgegengewirkt. Der EDV-Ansatz der 1980er Jahre war, die Buchführung nur formal auf die EDV abzubilden. Wildes Hin- und Her-buchen, sinnfreie Gegenkonten, negatives Buchen im Soll und andere Auswüchse waren die Folge. Dem Buchhalter war künstlerische Freiheit gewährt, die nicht selten genutzt wurde.

OrgaMon bildet ganze Geschäftsvorfälle ab, deren Folge sind eine ganze Anzahl von Buchungen ggf. auf eine Vielzahl definierter Konten. Die einzelnen Buchungen sind jedoch direkt mit diesem Geschäftsvorgang verbunden, so dass der Zusammenhang erhalten bleibt. Änderungen am Geschäftsvorfall ziehen Änderungen an Gesamtbuchungsbild nach sich.

OrgaMon setzt hier auf Buchungsintelligenz, die schon im Konto-Deckblatt definiert ist. Jede Buchung in ein Konto durchläuft dann die individuelle Qualitätssicherung dieses Kontos. Die Logik wird durchgängig und ohne Ausnahme angewendet und ist transparent anpassbar. Durch eine möglichst späte "Fixierung" der Buchungssätze, die jedoch immer innerhalb der Forderungen der Wirtschaftsprüfer liegt, wird maximale Flexibilität und Fehlerfreiheit des Endergebnisses erreicht. Stornobuchungen werden vermieden und die Transparenz und Verständlichkeit der Buchführung erhöht


Verwandte Themen

Umsatzsteuervoranmeldung
Steuersätze
Forderungsausgleich
Kasse

Einleitung

Die moderne EDV gestützte Buchführung besteht aus mehreren Grundverfahren:

  • Buchungserfassung und Änderung zu jedem Zeitpunkt solange nicht "fixiert" wird.
  • Zugriff auf Kontenrahmen (Gerüst) und Konten Schemen (Logik).
  • Anhand der Schemen werden Aufgaben parametrisierbar erfüllt (z.B. Schema Beleg(BELEG_R,TEILLIEFERUNG) ).
  • Anstossen und Anzeigen von Salden und Auswertungen zu jedem Zeitpunkt. Möglicherweise schon im Moment der Erfassung.
  • Anfangsbestände aus fixierten Zeiträumen sind übernehmbar oder fliessender Übergang von Buchungsperioden.
  • Modellrechnung (ab 2006), also Buchungseinträge, die vom Modell für Zukunft "eingebucht" werden. So lassen sich Entwicklungen vorhersagen, die sich im Moment abzeichen aber noch nicht direkt sichtbar sind. Ertragswarnungen können somit frühzeitig ausgegeben werden.

Buchung = "Initialer Buchungssatz" & "Buchungs Schema"

Begriffe

  • Konto: ein Buch mit einer Nummer als Namen, z.B. 8400.
  • Konto-Bewegung: ist ein einzelner Buchungs-Vorgang in einem Buch. Der Betrag der gebucht wird erhöht oder vermindert den Saldo des KOntos.
  • Saldo: Ergebnis der Summierung aller Konto-Bewegungen. Dabei sind Haben buchungen positiv und Soll-Buchungen negativ.
  • initialer Buchungssatz: Die eingentliche Grund-Eingabe des Geschäftsvorganges, sie ist Auslöser für alle weitere Buchungen. Im Mittelalter gab es das Hauptbuch genannt die Kladde. Hier trug der Vorsteher an seinem Pult ALLE Buchungen zunächst ein. Aus dem Kontext oder durch Hinweise ergab sich dann, dass so eine einzelne Eintragungszeile in weitere Bücher übertragen werden musste (Konzept der doppelten Buchführung). Diese Aufgabe erfüllten nun geringer qualifizierte Schreiber, da es sich mehr oder minder um Abschriften aus der Kladde handelte.
  • Folgebuchungssatz: wurde durch einen initialen Buchungssatz ausgelöst. Durch ein Regelwerk sowie Angaben im initialen Buchungssatz sind diese Folgesätze automatisch entstanden.
  • Konto-Deckblatt: Jedes Zielkonto hat ein Deckblatt im dem Buchungsregeln definiert weren können. z.B. ein Vorzeichenwechsel, wird also ein Folgesatz in dieses Konto-Buch geschrieben
  • Schema:
  • Stempel:
  • ungebucht: Ein initialer Buchungssatz, der eine Gegenkonto trägt aber kein Buchungsdatum, diese Buchungen werden durchgestrichen dargestellt

Kontenrahmen

Als Startpunkt für ihre individuellen Anpassungen liegen den OrgaMon die Kontenrahmen SKR03 und SKR04 vor. Nach der Festlegung auf einen dieser Grundgerüste können auch im laufenden Betrieb neue Konten definiert werden. Ein Kontenrahmen ist als eine Ansammlung von Konto-Deckblättern definiert. Die Deckblätter definieren die Standards beim Buchen auf dieses Konto. Bender wird die Regeln entsprechend anwenden. Besonderen Konten werden vielfach im OrgaMon direkt angesprochen:

Konten, auf die automatisch gebucht wird

  • SATZ1 voller Satz: Vorsteuer (die negativen Beträge) / Umsatzsteuer (die positiven Beträge)
  • SATZ2 verminderter Satz: Vorsteuer (negativer Betrag) / Umsatzsteuer (positiver Betrag)
  • SATZ3 andere Sätze (z.B. aus Vorjahr)
  • 1000 Kasse
  • 1010 Kartenzahlung
  • 1200 Hauptkonto für Zahlungen aus dem Lastschriftverfahren
  • 1260 SEPA-Mandate der Kunden zur einmaligen Anwendung, speziell passend zu einer Forderung
  • 1400 Ausgangsrechnungen. Auch Forderungskonto.
  • 1590 durchlaufender Posten (Buchungen ohne ER/AR Bedeutung)
  • 1710 Anzahlungen, solange Forderungen nicht vollständig bezahlt sind landen Buchungen auf diesem Konto, erst bei der vollständigen Zahlung erfolgt der Forderungsausgleich über 8200

Erlöskonten

  • 8200 Erlöse (reines Verteilerkonto, hier ist oftmals Schema=Beleg eingetragen!) auf diesem Konto sollte nicht direkt gebucht werden!
    • 84xx Jedem Sortiment kann ein eigenes Erlöskonto zugeordnet werden
    • 8400 Erlöse (z.B. aus Programmierarbeiten)
    • 8405 Erlöse (z.B. aus Server-Vermietung)
  • 8450 Erlöse aus freiem Verkauf, also Artikeln/Dienstleistungen ohne Sortimentszuordnung

Umsatzsteuerzahlungen

  • 1780 laufende Abbuchungen des Finanzamtes aufgrund der jeweiligen Umsatzsteuer-Voranmeldungen
  • 1790 Dezember-Betrag der Umsatzsteuer-Voranmeldung, dieser wird in der Regel im Januar des Folgejahres gebucht
  • 1791 Differenz-Abbuchung des Finanzamtes aufgrund der Umsatzsteuererklärung (=Differenzbetrag aus "Erklärung" - "Summe der Voranmeldungen")

Initialer Buchungsatz

Eine Quelle (Konto) initiert eine Betragsbuchung mit gewissen Parametern in Richtung Ziel. Auf dem Weg zum Ziel können mehrere Folgesätze enstehen. Mussfelder dieses Buchungssatzes sind:

Betrag
von Quellkonto
nach Zielkonto

dazu kommen noch Umfeldparameter die dem Buchungsmotor als Grundlage für weitere Entscheidungen dienen.

Skript

  • SATZ=1[";"<MwSt-Betrag>[";"<Skonto>]] der angegebene Mehrwertsteuer-Betrag wird in voller Höhe auf das Konto SATZ1 verbucht. Ist kein direkter Geldbetrag angegeben wird der MwSt Anteil berechnet. Wurde bei einer Eingangsrechnung Skonto gewährt und ausgeschöpft, so muss der auf der Rechnung ausgewiesene MwSt-Betrag angegeben werden, danach ";" und der Skontierungs-Prozentsatz (i.d.R. 1,2 oder 3%)
  • BETRAG=Betrag[";"<Konto>] Damit kann gesteuert werden, dass nur ein Teilbetrag des gesamten Betrages auf ein Gegenkonto gebucht wird. Das Zielkonto (normalerweise im Gegenkonto angegeben) kann überschrieben werden.
  • STEMPEL= Prefix-Bezeichnung des zu verwendeten Stempels. z.B. ER oder AR. Die Angabe von NEIN verhindert die Verwendung eines Stempels
  • VORZEICHENWECHSEL=JA Bewirkt, dass beim Übergang auf das Gegenkonto das Vorzeichen des Betrages gewechselt wird.
  • BELEG=<BelegRID>[";"<Teillieferung>[";"<Betrag>]] bewirkt dass mehrere Belege durch eine Zahlung ausgeglichen oder Angezahlt werden.
  • BAR=NEIN verhindert, dass dieses Konto im Kassen-Dialog "Bar" angezeigt wird.
  • POSNO=<POSNO> setzt die Positionsnummer auf den angegebenen Wert
  • VORGANG=<VORGANG-TEXT> setzt den Vorgang-Text auf den angegebenen Wert überschreibt also die Vorgabe der Bank
  • EREIGNIS=<EreignisRID> setzt den EREIGNIS_R der Folgesätze auf den angegebenen Wert
  • Sortierung=SQLüberschreibt die Sortierung der Buchungssätze bei der Anzeige dieses Kontos
    • default: Sortierung=DATUM,POSNO
    • Deckblatt-Default: Sortierung=NAME
    • Anzahlungen-Default: Sortierung=BELEG_R,TEILLIEFERUNG,DATUM,POSNO
    • 1200-Default: Sortierung=EREIGNIS_R,POSNO,RID
    • 1010-Default: Sortierung=EREIGNIS_R nulls last,DATUM,RID

Das verwendete Buchungs-Schema ist auch ableitbar aus den Parametern des Deckblattes, es muss nicht alles im initialen Buchungssatzes angegeben werden. Das Schema gibt Hinweise darüber mit welchem Motor der "initiale Satz" weiter verarbeitet werden soll. Schemen sind nicht nur Konto - Individuell sondern Kategorie - Individuell, das bedeutet eine Buchung von "Forderungen" nach "Bankkonto X" erfordert ein Schema "Forderungen->Bankkonto X" welches der Buchungsmotor nachlädt und auswertet.

Schema der Buchung

Ein Schema ist ein vorgefertigtes Regelwerk, welches den initialen Buchungssatz interpretiert, und alle Folge-Buchungssätze daraus entwickelt. Auch werden ggf. Ergänzungen am initialen Buchungssatz durchgeführt (z.B. Stempel oder das Buchungsdatum)

Schema=Standard

dies ist das Standard-Schema, und muss nicht extra angegeben werden.

Schemen können auch Budgets berücksichtigen und je nach Ausschöfpung oder Überbeanspruchung sich anders verhalten, oder auch Buchungen ablehnen. Einfache Motoren erzeugen aus einer Initial-Buchung EINEN Folgesatz im Zielkonto. Komplexere Motoren wie z.B. in "Vorsteuer" oder "Budgets" können weitere Buchungen durchführen.

Beispiel

  • Ein Betriebsmittel soll abgeschrieben werden, deshalb soll nur der MwSt-Anteil sofort verbucht werden, der Netto-Betrag soll auf 1590 gebucht werden (1590 bei GEGENKONTO eingeben). Der Rechnungsbetrag war -5052,90 €. Somit wird der Netto-Anteil auf 1590 gebucht, aber dennoch ein SATZ1 Anteil auf die Vorsteuer.
SATZ=1

Schema=Beleg

BELEG=

BELEG=BELEG_R[";"TEILLIEFERUNG[";"Betrag]]
BELEG=BELEG_R[";"TEILLIEFERUNG[";"Betrag]]
BELEG=BELEG_R[";*"[";"Betrag]]
...

  • Wird <TEILLIEFERUNG> wegelassen, so wird von der TEILLIEFERUNG 0 ausgegangen
  • Wird bei <TEILLIEFERUNG> ein "*" (Stern) angegeben wird der GEsamtbetrag einfach auf alle Teillieferungen verteilt, dies ersetzt einfach die Mühe den aktuellen BEtrag in mehrere BELEG= Zeilen aufzuteilen. Der Gesamtbetrag muss dann aber auch 100% passen.
  • Wird <Betrag> weggelassen, so wird der Gesamtbetrag des initialen Buchungssatzes als Zahlbetrag benutzt

BETRAG=

BETRAG=DerBetragDerVerwendetWerdenSoll[";" Gegenkonto]

  • Beim Forderungsausgleich muss man nicht 100 % des Betrages zum Ausgleich verwenden, mit BETRAG= kann angegeben werden, dass nur dieser Teil für den Forderungsausgleich verwendet werden soll. Den Restbetrag bucht der OrgaMon auf das angegebene Ausbuchungskonto
  • Ist kein Gegenkonto angegeben, so wird 1590 verwendet.

Schema=Folge

BETRAG=

  • Es wird nicht nur in ein einzelnes Gegenkonto gebucht, sondern auf alle im Skript angegebenen Konto der Gesamtbetrag verteilt. Der im jeweiligen Deckblatt definierte Satz wird hier benutzt. Der "SATZ=" Eintrag ist im Deckblatt deshalb zwingend erforderlich.
  • Beim Betrag muss (in der Regel "-", da oft eine Ausgabe verbucht wird) der Bruttobetrag (d.h. die Summe incl. der MwSt.) eingetragen werden

BETRAG=BruttoBetrag[";" Ziel-Konto[";" {Skript"|"}]]

Beispiel

Schema=Folge
BETRAG=-15;1590
BETRAG=-6;3200;SATZ=0
BETRAG=-12;3200

  • Bucht -15,00 Euro auf 1590
  • Bucht -6,00 Euro auf 3200 überschreibt dabei den im Deckblatt definierten Satz auf den Wert "0"
  • Bucht -12,00 Euro auf 3200, diesmal mit dem im Deckblatt angegebenen Satz

SATZ=

Schema=Saldieren

 Einzelbuchung "1"        156,72 €
 Einzelbuchung "2"         17,43 €
 Einzelbuchung "3"        149,97 €
 Einzelbuchung "4"         34,50 €
 Einzelbuchung "5"         60,09 €
 Einzelbuchung "6"         81,35 €
 Hauptbuchung            -500,06 €
                       ===========
 Saldo                      0,00 € 
  • OrgaMon hilft mit diesem Schema einen Aspekt der Buchführung zur erreichen: Sich gegenseitig ausgleichende Buchungen. Das bedeutet die Summe der Beträge sollte 0,00 € sein
  • Es wird versucht, zur Hauptbuchung "unsaldierte" Einzelbuchungen zu finden, so dass bei Addition aller Beträge ein Saldo von 0 entsteht
  • in der entstandenen Buchungs-Gruppe trägt jeder Datensatz den selben EREIGNIS_R, die Ereignis-Art ist "ZahlungEC" = 40
  • da der Hauptbuchungssatz (z.B. BSCARD) in der Regel auf einem Girokonto entsteht hat dieser bereits einen anderen EREIGNIS_R (aus dem HBCI-Kontenabruf)
  • Für die Gruppen-Identifizierung wird jedoch im SKRIPT ein EREIGNIS=nnn eingetragen
  • gelingt es nicht den Saldo "0" zuerreichen, bleibt der Hauptbuchungssatz ungebucht und es muss manuell nachgeholfen werden
  • Aus dem Hauptbuchungssatz wird versucht die Anzahl der Einzelbuchungen aus dem Text/Verwendungszweck zu ermitteln (z.B. "ANZAHL 6")
  • OrgaMon geht so vor, dass nach Buchungsmoment sortiert die unsaldierten und bisher ungruppierten Beträge aufaddiert werden, bis 0 erreicht ist

Anwendung EC-Cash

  • Einzelbuchungen: EC-Cash-Zahlungsvorgänge werden gebucht als vollständiger Zahlungsausgleich einer Teillieferung eines Beleges in "Z" (nicht im Forderungsausgleich!). Der EC-Cash Betrag muss dabei genau dem Betrag des Beleges entsprechen, gibt es Abweichungen muss "Trinkgeld" oder "Forderungsverlust" auf dem bestehenden Beleg nachgebucht werden (Es ensteht ev. eine weitere Teillieferung) Die Teillieferungen werden zusammen bezahlt.
    • Bei der Zahlung kreuzt man an "EC Kartenzahlung"
    • So entstehen Einzelbuchungen auf dem Konto 1010
  • Hauptbuchung: Irgendwann kommt eine Sammelbuchung des Zahlungs-Dienstleisters als Gutschrift auf dem Girokonto
    • diese muss auf 1010 im Gegenkonto gebucht werden.
    • Durch Worte z.B. "BSCARD" kann hier auch Autobuchen zur Vereinfachung benutzt werden
    • Im Verwendungszweck/Text sollte "ANZAHL nnn" angegeben werden, damit OrgaMon einen Hinweis auf die Anzahl der Einzelbuchungen verwenden kann
    • Damit OrgaMon Einzelbuchungen zuordnen kann muss immer die älteste BSCARD Buchung zuerst verbucht werden.
    • Es wird versucht den Saldo von 0,00 sicherzustellen. Kommt es zu Problemen wird eine Fehlermeldung ausgegeben


  • OrgaMon geht so vor dass er die ältesten und bisher nicht gruppierten Einzelbuchungen einsammelt und versucht dem aktuellen BSCARD zuzuordnen, stimmt der Saldo und die Anzahl wird der Vorgang beendet
  • lässt man eine BSCARD Buchung aus und bucht zuerst die spätere BSCARD Buchung wird die Zuordnung niemals gelingen

1010 Deckblatt

Skript

STEMPEL=NEIN
VORZEICHENWECHSEL=JA
Schema=Saldieren
Sortierung=EREIGNIS_R nulls last, DATUM, RID

Text

[BSCARD]
SKRIPT=
 COLOR=#00FF66

1010 Probleme

  • Um 1010-Problematiken zu lösen hat man einige Möglichkeiten, wechseln Sie in die Ansicht Konto 1010
  • Steht man auf einem Buchungsblock, der "0" werden soll (egal ob BSCARD Buchungssatz oder die einzelnen Gegenbuchungen) kann man mit der Symbolknopf S die Saldierung auf die aktuelle Gruppe anwenden, S wird rot (aktiv) ausgegeben die Summe oberhalb von "Haben" sollte "0" sein
  • Einzelbuchungen die fälschlicherweise in einer Gruppe sind nimmt aus der Gruppe indem man den EREIGNIS_R rauslöscht, damit ist es wieder eine freie/zukünftig wieder zuordenbare Einzelbuchung
  • Einzelbuchungen die nicht automatisch zugeordnet werden konnten, teilt man der Gruppe zu, indem man manuell einen Eintrag in EREIGNIS_R macht, und zwar den EREIGNIS_R der "Wunschgruppe". Notieren Sie sich vorher den passenden EREIGNIS_R der Gruppe
  • Wurde etwas "nicht OrgaMon bezogenes" per EC-Cash eingezogen erstellt man einen neuen Datensatz (Symbolknopf "+" in der Anzeige eines anderen einzelnen Datensatz). Nur 4 Eintragungen müssen hier gemacht werden:
    • in "Konto" 1010,
    • in "Text" Stornobuchung oder eine andere Begründung in Textform
    • in "Betrag" den Betrag so geschickt berechnet dass der Saldo nun stimmt.
    • in EREIGNIS_R den passenden Wert für diese Gruppe


  • Es kann Situationen geben, in denen man die komplette Gruppe auflösen will, man geht auf eine beliebige Einzelbuchung öffnet diese und drückt Symbolknopf S (durchgestrichenes S)
  • Der Hauptdatensatz behält hier den alten EREIGNIS= da dieser im SKRIPT eingetragen ist und nicht im Feld EREIGNIS_R (dort steht der EREIGNIS_R des HBCI-Kontenabrufes)
    • Da der EREIGNIS= für die Sortierung der Datensätze verwendet wird, ist es sinnvoll bei Auflösung von ganzen Gruppen auch diese Zeile im Hauptdatensatz zu löschen, damit wird OrgaMon gezwungen wiederum einen neuen EREIGNIS_R für diese Gruppe zu erzeugen

Buchungs Log

Probleme auf dem Buchungsweg werden im Log aufgezeichnet - Im kritischen Fehlerfall wird das Log angezeigt.

Erfolgreiche Verbuchung

War Bender erfolgreich, so trägt er ein "OK" in den initialen Buchungssatz ein indem er in "GEBUCHT" den aktuellen Moment einträgt

PDF-Dokumente

  • Eingangs- und Ausgangsrechnungen können als PDF-Belege gespeichert werden. So ist eine beleglose Buchführung möglich. Dabei hilft der OrgaMon mit dem PDF-Symbol ("alle PDF Zuordnungen prüfen") dabei fehlende Belege aufzuspüren und zuzuordnen.
  • Bei der Anzeige eines Buchungssatzes können alle dazugehörende PDF-Dokumente eingesehen werden.
  • Bei der Übergabe von Daten an den Steuerberater mit der Funktion "Zahlung-Verwaltung-CSV-Schnittstelle-Start" werden alle PDF-Belege zusammen mit dem Buchungsjounal in ein Verzeichnis gepackt.

Dateinamenskonvention

Der Dateinamen setzt sich zusammen aus

"Stempel-Name" "-" "Stempel-Nummer" "-" "beliebiger bisheriger Name" ".pdf"

Beispiel

#
# typische PDF Rechnung der Telekom
#

ER-2716-2017_09rechnung_4726186958_sign.pdf


Pfadkonvention

im Buchungssatz kann PERSON_R eingetragen werden. Im Dokument-Verzeichnis der Person (.\Rechnungen\~PERSON_R~) werden die Dokumente gespeichert. Die Funktion "PDF-Symbol" trägt die PERSON_R beim Buchen automatisch nach, sollte sich das Dokument bereits im "richtigen" Personen-Dokument-Verzeichnis befinden. So können Dokumente auf Verzeichnisebene korrekt verteilt werden ohne auch noch PERSON_R eintragen zu müssen.

Kontrolle

  • die Kontrollfunktion führt folgende Aktionen aus
    • bereits korrekt auffindbare PDF in den Unterverzeichnissen erhalten die BUCH.PERSON_R automatisch nachgetragen
    • Finden sich PDF in falschen Verzeichnissen wird gewarnt, unabhängig davon ob bereits eine Doublette im richtigen Verzeichnis ist
    • Wird das PDF nicht gefunden wird gewarnt

Folge-Buchungsatz

Dies sind Buchungen, die von der Bender-Logik erzeugt wurden. Diese sind per Definition nicht manuell veränderbar, sondern deren Inhalt ergibt sich zwingend aus dem Hauptbuchungssatz (Initialier Buchungssatz). Stimmen hier Dinge nicht, ist am Schema oder an der Bender-Logik oder am initialen Buchungssatz etwas zu verändern. Ein erneutes initiieren der Buchung ist jederzeit möglich, solange der initiale Buchungssatz nicht fixiert wurde. Dabei werden alle Folgebuchungssätze des einen initialen Buchungssatzes gelöscht und NEU erstellt.

Endsatz

Dies ist eine Folge-Buchung, aus der selbst wiederum keine Folgebuchungen entstehen.

Zwischensatz

Dies ist eine Folge-Buchung, aus der weitere Folgebuchungen oder Endsätze entstehen können:

  • Beispiel: Eine letzte Teilzahlung geht auf das Teilzahlungskonto (Konto->1710). Sie ist genau so hoch, dass nun die Summe aller Teilzahlungen die Forderungssumme ergeben. Dies nimmt Bender zum Anlass eine Gegenbuchung durchzuführen (-Betrag->8200), dies ist ein Folgesatz - der aber weitere Buchungen zur Folge hat, als wäre es ein "initialier Buchungssatz".

Finden der Buchungsregeln

Vor einem Buchungsvorgang wird versucht eine Buchungsregel für diesen Buchungstyp die passende Regel zu suchen. Hat man bei der Buchung ein Ziel-konto angegeben so finden sich Regeln für diese Buchung im Konto-Deckblatt des Ziel-Kontos.

Suche von Buchungssätzen

  • B<BetragInCent> also B10000. sucht den Betrag 100,00 Euro (man beachte den Punkt am Ende)
  • K<Name> also K1590 sucht das Konto 1590
  • G<Name> also G8200 sucht das Gegenkonto 8200
  • BELEG<Nummer> also BELEG54002 sucht alle Buchungen im Zusammenhang mit diesem Konto
  • E<Nummer> sucht alle Buchungen im Zusammenhang mit dem Ereignis <Nummer>

Automatische Buchung (AutoBuchen)

  • Auf dem Deckblatt eines Kontos kann im Feld Text definiert werden, im welchem Fall automatisch auf dieses Konto gebucht werden darf
  • Eine automatische Buchung wird dann ausgeführt sobald ein Buchungssatz gewisse Suchbegriffe enthält
  • Der Suchbegriff wird in eckigen Klammern dargestellt
[Müller B67500.]
SKRIPT=
 Schema=Folge
 BETRAG=
+BETRAG=465;8210
+BETRAG=210;4970
 COLOR=#00FF66
BAUSTELLE_R=6
  • In diesem Beispiel würde bei einem Buchungssatz bei dem "Müller" enthalten ist, und der Buchungsbetrag=675,00 € beträge automatisch folgende Schritte durchgeführt
    • Gegenkonto auf die Kontonummer des Deckblattes
    • Im Eingabefeld "SKRIPT" werden die folgenden Änderungen gemacht
      • Schema=Folge wird erzwungen
      • Alle BETRAG= werden gelöscht
      • BETRAG=465;8210 wird hinzugefügt
      • BETRAG=210;4970 wird hinzugefügt
      • COLOR=#00FF66 wird erzwungen
    • BAUSTELLE_R wird auf #6 gesetzt

Buchung eines Zahlungsausgleiches

schön, dass Geld herein kommt. Doch dieser scheinbar belanglose Moment ist die grosse Stunde aller Buchhalter:

  • Es gibt Umsatzsteuer Anteile die wir dem Kunden abverlangt haben, die gehören nicht uns, sondern dem Staat
    • Es gibt Umsatzsteuer-Anteile in verschiedenen Sätzen (19%, 7%, 0%)
  • Es gibt Einnahmen, die auf verschiedene Konten verteilt werden
    • So wollen wir Dienstleistungen auf 8400 Buchen
    • daneben aber Erlöse aus dem Verkauf unserer Äpfel und Birnen auf 8401
  • Es gibt die Gesamt-Einnahme, die auf ein Kassenkonto gebucht werden muss, Barzahlung des Kunden vorausgesetzt

Hier ein Buchungsbeispiel:

initialer Buchungssatz:

"Z"ahlung eines Beleges nach Konto "1000", Folgende Buchungen

Initialer Buchungssatz:

1000 (Kasse)->*
BELEG=9283-00

-> Rest wird vom OrgaMon erledigt

Folgebuchungssätze sind dann aufgesplittet in die einzelnen Teilbuchungen, je nach dem welche Konten in den Sortimenten angegeben sind, zu denen die gelieferten Artikel gehören.

8401->, Betrag, ggf. "SATZ1" Buchungen
8402->, Betrag, ggf. "SATZ2" Buchungen
8403->, Betrag, ggf. "SATZ1"

"Pauschal Bucher" vs "Sortiment Bucher"

  • der Pauschalbucher bucht alle Einkünfte nach 8400
  • der Sortimentbucher erzwingt die Kontonummern-Eingabe bei jedem Sortiment, damit alle Artikel korrekt verbucht werden können. Hierbeit ist eine sehr individuelle Splittung der Eingangskonten möglich, die eine betriebswirtschaftliche Auswertung informativer macht.

Rundungsproblem im Sortimentbucher

  1. Berechnet man die 19% Umssatzsteueranteil an einem Preis, so kommt nicht immer ein exakter Steuer-Anteil raus, sondern eine Kommazahl, die man jedoch unten in der Rechnung runden muss. Beispiel:
    1. Brutto-Preis ist 4,99 Euro,
    2. das sind 4,19 + 0,7961 MwSt, sprich 0,80 Cent MwSt
  1. Der OrgaMon rundet (pro mwSt-Satz) bei Rechnungen genau 1 mal
  2. Die Buchhaltung rundet je Konto 1 mal

Beispiel 8400 Leistungen 19% 8401 Medikamente 19%

also rundet er "2x" was natürlich eine Differenz zur Methode "1x runden" ergibt.

Lösung: der Gesetzgeber kennt diese Problematik und sagt: Egal was ein Nachrechnen mit welcher Methode auch immer ergäbe (Es gibt ja auch verschiedene Rundungsverfahren (kaufmännische, mathematische)) gibt und einfach die MwSt, die auf der Rechnungs ausgewiesen ist!!

-> Das bedeutet für uns:

Die Summe der 2 "SATZ1" Buchungen in 8400 und 8401 muss ganz genau den auf der Rechnung ausgewiesen Betrag ergeben, es gibt keine Grund dafür, dass hier wie es klassische EDV-Buchhaltungs-Systeme machen ein Rundungsdifferenzkonto oder ähnliche Scherze einzuführen:

  1. der Korrektur-Betrag muss in ganzen Cent berechnet werden
  2. beginnend mit dem Wertmäßig höchstem MwSt-Betrag muss begonnen werden, und eine "1" Cent Korrektur muss erfolgen
  3. dann der nächst kleinere Betrag, bis der Korrektur-Betrag=0 ist.


Transaktionen

BI1

Im aktuellen Skript wird

BELEG=<BELEG_R>;<TEILLIEFERUNG>;<BETRAG>

nachgetragen.

Saldo

  • Die Kontostands- oder Salden-berechnung bei Giro-Konten erfolgt über Abschlussbuchungen
  • dies sind Buchungen mit dem Vorgang ABSCHLUSS (805) oder ENTGELTABSCHLUSS (809) oder ZINSEN/ENTG. (805)
  • wird dieser Vorgang erkannt, steht ABSCHLUSS (grau hinterlegt) in der Umsatzliste
    • nur in diesem Fall ist es sinnvoll in der Buchung einen Abschluss-Betrag einzutragen
  • im Buchungstext wurde früher ein Abschlussbetrag mitgeliefert, ich glaube seit der CAMT Umsatzabfrage wird dieser Wert nicht mehr übertragen
  • mit dem Abschlussbetrag ist es möglich einen korrekten Kontostand zu berechnen
  • Man kann nun aber einen Wert manuell eintragen, und somit einen falschen Saldo zu korrigieren
    • suche mit dem Suchbegriff "ABSCHLUSS." die letzte Abschlussbuchung (vorher eventuell das Refresh-Symbol links vom Suchbegriff drücken)
    • Öffne die unterste Buchung mit dem Wort "ABSCHLUSS"
    • gebe hier rechts neben dem Betrag im Eingabefeld Abschluss eine "0" ein
    • mache einen normalen Umsatz-Abruf im Reiter "HBCI-Umsatzabfrage" damit Du auf dem neuesten Stand bist
    • hake nun [v] nur Saldenabruf an, dann nochmals "Umsatzabruf starten"
    • berechne den Wert "Saldo laut aktueller Abfrage" MINUS "Saldo laut Buch" und überschreibe damit die eingegebene "0" von eben

Der Saldo (Kontostand) des Girokonts muss jetzt stimmen!

Tipps

Zusammenlegen von Teilzahlungen

  • Im "Z" die Spalte TL ändern (zb. von 2 auf 1)
  • Im Versand-LKZ die Spalte TL ändern (zb. von 2 auf 1)
  • In GELIEFERT die zusammenlegung noch machen, mit folgendem OLAP
update geliefert set 
 POSNO = 1
where
 (beleg_R=55571) and
 (POSNO=2) 

(immer diese Beiden Änderungen zusammen machen)

Anpassen des Betrages "GELIEFERT"

das ist meiner Meinung nach unmöglich!