Buchfuehrung: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Zeile 43: Zeile 43:
* '''1000''' Kasse
* '''1000''' Kasse
* '''1200''' Hauptkonto für Zahlungen aus dem Lastschriftverfahren
* '''1200''' Hauptkonto für Zahlungen aus dem Lastschriftverfahren
* '''1590''' durchlaufender Posten (Buchung ohne ER/AR Bedeutung)
* '''1590''' durchlaufender Posten (Buchungen ohne ER/AR Bedeutung)
* '''8200''' Erlöse (Verzweigungskonto, hier ist oftmals Schema=Beleg eingetragen!) auf diesem Konto sollte nicht direkt gebucht werden!
* '''8200''' Erlöse (Verzweigungskonto, hier ist oftmals Schema=Beleg eingetragen!) auf diesem Konto sollte nicht direkt gebucht werden!
* '''8450''' Erlöse aus freiem Verkauf, also Artikeln/Dienstleistungen ohne Sortimentszuordnung
* '''8450''' Erlöse aus freiem Verkauf, also Artikeln/Dienstleistungen ohne Sortimentszuordnung
* '''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
* '''1780''' laufende Abbuchungen des Finanzamtes aufgrund der jeweiligen Umsatzsteuer-Voranmeldungen
* '''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
* '''1790''' Dezember-Betrag der Umsatzsteuer-Voranmeldung, dieser wird in der Regel im Januar des Folgejahres gebucht

Version vom 13. März 2013, 15:33 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 inerhalb 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:

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:

  • 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
  • 1200 Hauptkonto für Zahlungen aus dem Lastschriftverfahren
  • 1590 durchlaufender Posten (Buchungen ohne ER/AR Bedeutung)
  • 8200 Erlöse (Verzweigungskonto, hier ist oftmals Schema=Beleg eingetragen!) auf diesem Konto sollte nicht direkt gebucht werden!
  • 8450 Erlöse aus freiem Verkauf, also Artikeln/Dienstleistungen ohne Sortimentszuordnung
  • 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
  • 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.

Das verwendete Buchungs-Schema ist auch ableitbar aus den Parametern des Deckblattes, es muss nicht 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)

Standard-Schema

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.


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[";" AusbuchungsKonto]

  • 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 Ausbuhcungskonto angegeben, so wird 1590 verwendet.

Schema=Folge

BETRAG=

Es wird nicht nur in ein Gegenkonto gebucht, sondern in die im Script angegebenen. Der im jeweiligen Deckblatt definierte Satz wird hier benutzt. Der "SATZ=" Eintrag ist im Deckblatt deshalb zwingend erforderlich.

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=

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.

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, solange der initiale Buchungssatz nicht fixiert wurde.

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

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.

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!