Buchfuehrung: Unterschied zwischen den Versionen
Root (Diskussion | Beiträge) |
|||
(170 dazwischenliegende Versionen von 3 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. OrgaMon | <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 == | |||
[[Umsatzsteuervoranmeldung]]<br> | |||
[[Steuersaetze|Steuersätze]]<br> | |||
[[Forderungsausgleich]]<br> | |||
[[Kasse]]<br> | |||
== Einleitung == | |||
Die moderne EDV gestützte Buchführung besteht aus mehreren Grundverfahren: | Die moderne EDV gestützte Buchführung besteht aus mehreren Grundverfahren: | ||
* Buchungserfassung und Änderung zu jedem Zeitpunkt solange nicht "fixiert" wird. | * Buchungserfassung und Änderung zu jedem Zeitpunkt solange nicht "fixiert" wird. | ||
* Zugriff auf Kontenrahmen und Konten Schemen. | * 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. | * 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. | * Anfangsbestände aus fixierten Zeiträumen sind übernehmbar oder fliessender Übergang von Buchungsperioden. | ||
Zeile 10: | 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 == | |||
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 15: | 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: | ||
* | '''Betrag<br> | ||
* Betrag | von '''Quellkonto'''<br> | ||
* Zielkonto | nach '''Zielkonto'''<br> | ||
dazu kommen noch Umfeldparameter die dem Buchungsmotor als Grundlage für weitere Entscheidungen dienen. | |||
'''Skript'''<br> | |||
* <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 == | |||
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=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= ==== | |||
<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 | |||
* 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 == | ||
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 <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 | |||
[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 | |||
*** <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 == | |||
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)->*<br> | |||
BELEG=9283-00<br> | |||
-> 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<br> | |||
8402->, Betrag, ggf. "SATZ2" Buchungen<br> | |||
8403->, Betrag, ggf. "SATZ1"<br> | |||
== "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. | |||
== 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 StempelsVORZEICHENWECHSEL=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 WertVORGANG=<VORGANG-TEXT>
setzt den Vorgang-Text auf den angegebenen Wert überschreibt also die Vorgabe der BankEREIGNIS=<EreignisRID>
setzt den EREIGNIS_R der Folgesätze auf den angegebenen WertSortierung=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
ungebuchtund 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
- in "Konto"
- 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
(durchgestrichenes S)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ügtBETRAG=210;4970
wird hinzugefügtCOLOR=#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
- 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
ABSCHLUSS (805)
oderENTGELTABSCHLUSS (809)
oderZINSEN/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!