Buchfuehrung: Unterschied zwischen den Versionen
Root (Diskussion | Beiträge) |
|||
Zeile 68: | Zeile 68: | ||
* BELEG_R enthält hier die Belegnummer die Verbucht werden soll. | * BELEG_R enthält hier die Belegnummer die Verbucht werden soll. | ||
* STEMPEL enthält die Nummer der TEILLIEFERUNG die verbucht werden soll. | * STEMPEL enthält die Nummer der TEILLIEFERUNG die verbucht werden soll. | ||
alternativ: | |||
<code> | |||
BETRAG=Betrag;BELEG_R;TEILLIEFERUNG<br> | |||
BETRAG=Betrag;BELEG_R;TEILLIEFERUNG<br> | |||
...<br> | |||
</code> | |||
'''Schema=Folge''' | '''Schema=Folge''' |
Version vom 12. Dezember 2007, 12:49 Uhr
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.
Verwandte Themen
Umsatzsteuervoranmeldung
Steuersätze
Forderungsausgleich
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
- initialer Buchungssatz: Ihre Buchungseingabe, Auslöser für weitere Buchungen
- Folgebuchungssatz:
- Konto-Deckblatt:
- Schema:
- Stempel:
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. 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
- 1590 durchlaufender Posten
- 8200 Erlöse (Verzweigungskonto, hier ist oftmals Schema=Beleg eingetragen!)
- 1200 Hauptkonto für Zahlungen aus dem Lastschriftverfahren
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:
- Quellkonto
- Betrag
- Zielkonto
dazu kommen noch Umfeldparameter die dem Buchungsmotor als Grundlage für weitere Entscheidungen dienen.
- Standardbuchung oder Stornobuchung oder ein anderes Schema
- 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.
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=Beleg
- BELEG_R enthält hier die Belegnummer die Verbucht werden soll.
- STEMPEL enthält die Nummer der TEILLIEFERUNG die verbucht werden soll.
alternativ:
BETRAG=Betrag;BELEG_R;TEILLIEFERUNG
BETRAG=Betrag;BELEG_R;TEILLIEFERUNG
...
Schema=Folge
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
[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.
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.
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.
OrgaMon Ereignis kann Auslöser sein
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.
Aufbau der Tabelle BUCH
RID : eindeutiger ID dieser Buchung FIXIERT: Y/N ist eine Änderung möglich MANDANT_R: Buchungscontext (->PERSON_R) 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
Skript
SATZ=1[";" <Betrag>]
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.
BETRAG=
Es wird nicht der Gesamtbetrag verbucht, sondern nur ein Teil.[";"<Konto> es wird auf dieses Konto gebucht!]
STEMPEL=
Prefix-Bezeichnung des zu verwendeten Stempels.
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
- 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.