Doppelte Buchführung und BandM booking
Markus Lepper (2008/2011)



1          Einführung
1.1          Geschichtliche Wurzeln der Doppelten Buchführung
1.2          Zweck und Anwendung der Doppelten Buchführung
1.3          Heutige Situation, GoB und Elektronische Datenverarbeitung
1.4          Eigenheiten von BandM booking. Notwendige Externe Programme
2          Prinzipien und Grundbegriffe der Doppelten Buchführung
3          Doppelte Buchführung und BandM booking --- ein Tutorial
3.1          Der Arbeitszyklus mit BandM booking
3.2          Die beteiligten Dateien
3.3          Unser Beispiel sandsack GmbH: Eingabedaten
3.3.1          Errichtung des Unternehmens, Konfigurationsdatei
3.3.2          Formate der Textdateien und deren Definition
3.3.3          Format der config-Datei und der Datentyp-Definitionen
3.3.4          Kommentare in Daten
3.3.5          Kontenplan
3.3.6          Format der Buchungssätze, eröffnende Buchungen
3.3.7          Vergabe der Buchungsnummern und Konsistenzprüfungen
3.3.8          T-Konten-Blätter
3.3.9          Erste Kosten
3.3.10          Geleistete Vorsteuer
3.3.11          Erträge
3.3.12          Angestellte
3.3.13          Reisen und Speisen
3.3.14          Rechnungsabgrenzung
3.3.15          Steuern und Abschläge
3.3.16          Investitionen, Inventar und (Sonder-)Abschreibungen
3.3.17          Dateisicherung, Radierungsverbot und Korrekturbuchungen
3.3.18          Gewinnausschüttungen
3.4          Fortsetzung Beispiel: Jahresabschluss und Bilanz
3.4.1          Automatisch generierte Afa-Buchungen
3.4.2          Umbuchung Erfolgskonten auf Eigenkapital
3.4.3          Generierung der Bilanz-Druckvorlage
3.4.4          Generierung der Eröffnungsbuchungen
3.5          Fortsetzung Beispiel: Beginn des nächsten Jahres
3.5.1          Weitere Buchungsbeispiele
4          Technische Aspekte von BandM booking
4.1          Starten des Programmes
4.2          Bedienung der Programmes
4.3          Herunterladen von Quellen, Beispiel und Dokumentation
4.4          Übersetzen der Quellen, Make-Targets für die Beispiele
4.5          Aufbau des Programmes
4.6          Mögliche weitere Ausbaustufen
         Wichtige projekt-interne Links
         Bibliographie

^Inh 1 Einführung

Dagegen kann einem guten Wirte nichts angenehmer sein, als sich alle Tage die Summe seines wachsenden Glücks zu ziehen.
Selbst ein Unfall [...] erschreckt ihn nicht; denn er weiß sogleich, was für erworbene Vorteile er auf die andere Waagschale zu legen hat.
(Goethe, Wilhelm Meisters Lehrjahre)

Die sogenannte "Doppelte Buchführung" ist eine der wichtigsten Erfindungen der Geschichte.
Sie zu verwenden heißt, jedesmal aufs Neue den Triumph des Geistes über das Material zu vollziehen, sie zu benutzen ist für jeden aufgeschlossenen Kopf stets größtes Vergnügen. (Naja, vielleicht nicht gerade, wenn man den eigenen Ruin bilanziert, aber formal befriedigend selbst noch dann !-)

Unsere Implementierung davon heißt BandM booking. Diese ist geeignet für kleinste Unternehmen, wie private Vermögensverwaltung oder kleine Forschungseinrichtungen, mit nicht mehr als zwei- bis dreihundert Buchungen pro Geschäftsjahr. Für diese allerdings ist sie vollkommen angemessen.

Dieser Text ist gemeint sowohl als praktische und einfache Einführung in die Doppelte Buchführung an sich, für Nicht-Fachleute, wie auch als Einführung in die Bedienung unseres Programmes.

Beides erfolgt in Form eines Tutorials.

Dem vorgeschaltet sind zunächst die folgenden Abschnitte über die historische und aktuelle Position der Doppelten Buchführung und über die Anforderungen an sie.

In Kapitel 2 ("Prinzipien und Grundbegriffe der Doppelten Buchführung ") folgt ein Schnelldurchgang durch die Begriffe und grundlegenden Definitionen und Verfahren, ganz ohne jede Erläuterung und Beispiele, zum Zwecke größtmöglicher Kompaktheit.

Diese werden allerdings ausführlich nachgeliefert in Kapitel 3 ("Doppelte Buchführung und BandM booking --- ein Tutorial "), dem erwähnten Tutorial, anhand eines durchlaufenden Beispiels. Die Quelltexte zu diesem Beispiel finden sich in examples/sandsackGmbH.
Dieses Tutorial wird ergänzt durch die ausführliche Programmdokumentation, allerdings in Englischer Sprache.

^Inh 1.1 Geschichtliche Wurzeln der Doppelten Buchführung

Die frühesten Dokumente einer "Buchführung" kennen wir aus dem vierten Jahrtausend v.u.Z aus Babylonien und von den Sumerern.

Das Grundprinzip der "Doppelten Buchführung" entwickelte sich allerdings sehr viel später, im frühen Mittelalter im nördlichen Italien. "Die älteste auf uns gekommene Anwendung der Doppelten Buchführung findet sich 1340 in Genua" ([penndorf] , zitiert nach [buchench] ).

Die erste gedruckte und bis heute bekannteste Darstellung ist dann die von Luca Pacioli 1494. (nach [buchench] ).

Dieses (wie alles Geniale höchst einfache !-) Grundprinzip besteht darin, dass (a) das Bild des Unternehmens (das "Modell") aus zwei Hälften besteht: Die eine Seite stellt dar die Verwendung aller beteiligten Mittel, genannt Aktiv-Seite, die andere ihre Herkunft, genannt Passiv-Seite, und dass (b) fast jede Buchung, die einem Geschäftsvorfall entspricht, beide Seiten in gleicher Höhe verändert. Genaueres dazu unten in Kapitel 2 ("Prinzipien und Grundbegriffe der Doppelten Buchführung ").

Im Laufe der Jahrhunderte erlebte die Buchführung einen Prozess fortschreitender Reglementierung und Standardisierung, besonders in den industriellen Boom-Jahren des neunzehnten Jahrhunderts. Da entstanden auch papier-basierte, halb-automatisierte Verfahren mit Durchschreib-Blättern, Kopier-Stiften, übereinanderlegbaren Kontenblättern etc., -- heutzutage sehr putzig anmutenden Beweise menschlichen Einfallsreichtums.

Im letzten halben Jahrhundert hat dann die elektronische Datenverarbeitung die Herrschaft über die Buchführung angetreten. Trotz der zu allen Zeiten anzutreffenden Anwendung modernster technischer Mittel ist dennoch das Grundprinzip der "Doppelten Buchführung" seit dem Hochmittelalter unverändert geblieben!

Welch erhebendes Zeichen der schlechthinnigen Angemessenheit der Methode!

^Inh 1.2 Zweck und Anwendung der Doppelten Buchführung

Die allerallgemeinste Zweckbestimmung jedweder Buchführung ist, allen an einem Unternehmen Beteiligten ein zweckmäßiges Bild von dessen momentaner Lage zu liefern und die verschiedenartigsten dort herrschenden Rechtsverhältnisse und -vorgänge darzustellen und beweiskräftig zu belegen.

Offensichtlicherweise haben die verschiedenen "an einem Unternehmen Beteiligten" durchaus unterschiedliche Interessen, Befugnisse, Vorkenntnisse, Fähigkeiten und Absichten bezüglich diesen Informationen. Was für sie "zweckmäßig" ist, und ob sich die Informationen auf die Vergangenheit, Gegenwart oder (abgeschätzte) Zukunft des Unternehmens beziehen, kann also sehr stark abweichen.
Man bedenke nur, dass Eigentümer, Kapitalgeber, Geschäftsführer, Kunden, Käufer, Lieferanten, Dienstleister und Angestellte derart "Beteiligte" sind, nicht zuletzt auch der Fiskus!

Dementsprechend haben sich verschiedenartigsten Unterformen von "Buchführung im weitesten Sinne" herausgebildet.

Unser Programm BandM booking bezieht sich dabei auf die Finanzbuchhaltung, und somit auf die Doppelte Buchführung als deren elaboriertestes (und teilweise auch vom Gesetzgeber anzuwenden gefordertes!) Instrument.

Die Aufgaben der Finanzbuchhaltung bestehen darin, einerseits der Geschäftsführung stets ein jeweils möglichst aktuelles Bild von der Verbindlichkeiten und Mitteln des Unternehmens zu liefern und so diese zu befähigen, ihr Handeln an der rechtlichen Wirklichkeit auszurichten.
Andererseits ist am Ende einer Rechnungsperiode den Gewinn/Verlust zu ermitteln und die entsprechenden steuerlichen Anmeldungen und Ausschüttungen an die Eigentümer zu begründen.

Besonders zu unterscheiden ist somit die "Finanzbuchhaltung im engeren Sinne" von der (innerbetrieblichen) Kostenrechnung. Diese erfasst i.A. ähnliche Vorgänge wie die Finanzbuchhaltung, aber normalerweise in einer deutlich feineren Auflösung, und ihr Ziel ist die Bewertung einzelnder Produktions- und Verwaltungsvorgänge bzgl. Aufwand, Ertrag und Effektivität. Kostenrechnung ist Bestandteil des unternehmerischen "controlling" (was das englische Wort für Steuerung, Lenkung ist, und nicht etwa dem deutschen "Kontrolle" entspricht !-) und legt ihren Schwerpunkt auf innerbetriebliche Abläufe und Ressourcen-Flüsse (Stichworte: Kostenstellen, Beitragsdeckungsrechnung). Ihre konkrete Ausgestaltung ist oft Gegenstand "ideologischer" Grabenkämpfe, und die Wahl einer Methode häufig reine Glaubens-Sache.
Hingegen betrachtet und modelliert die reine Finanzbuchhaltung die Aussen-Beziehungen des Unternehmens, seine Verbindlichkeiten, Forderungen, Erträge, Aufwände und sein Vermögen.

^Inh 1.3 Heutige Situation, GoB und Elektronische Datenverarbeitung

Ab der Mitte des neunzehnten Jahrhundets entstanden detailliertere gesetzliche Vorgaben, und "übliche Verfahrensweisen" in den Buchhaltungsabteilugen der entstehenden Industrieunternehmungen bildeten sich heraus.

Diese werden mittlerweile unter dem Schlagwort "Grundlagen ordnungsgemäßer Buchführung" zusammengefasst, kurz GoB.

Heutzutage geschieht Buchführung fast ausschliesslich mit Mitteln der "elektronischen Datenverarbeitung". Dabei müssen die entsprechend erweiterten Regeln zur Anwendung kommen, die "Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme", kurz GoBS.

Sowohl GoB als auch GoBS sind sehr generisch formuliert. Sie stellen bestimmte Forderungen auf, die als solche sehr konkret sind, wie Lesbarkeit, Nachvollziehbarkeit, Belege, Zeitnähe, keine Radierung, "Wahrheit und Klarheit", etc. Die Wahl der Mittel zu deren Erfüllung hingegen lassen sie weitgehend offen.

Die GoB sind das, was man in der Informatik "Folklore" nennt. Eine allerallgemeinste Anforderung an Buchführung findet sich zwar in HGB §238. Die einzelnen Regeln aber haben sich in der Praxis herausgebildet sind oft formuliert und beschrieben, aber nirgendwo kodifiziert.

Hingegen liegen die GoBS als konkrete Verwaltungsvorschrift vor [gobs] , in der einzelne Forderungen genau definiert und spezifiziert werden. Allerdings ist auch hier die Wahl der Mittel zu deren Umsetzung bewußt offengehalten worden.

^Inh 1.4 Eigenheiten von BandM booking. Notwendige Externe Programme

BandM booking ist eine computerbasierte Implementierung der Doppelten Buchführung im Sinne oben beschriebener Zweckbestimmung.
BandM booking wendet sich als Lösung an extrem kleine Unternehmungen, die dennoch eine vollständige und übersichtliche Buchführung betreiben wollen oder müssen. So war es z.B. sehr gut geeignet für ein von den Autoren betriebenes Forschungsprojekt, und eignet sich auch für private Vermögensverwaltungsgesellschaften, etc.

Bei einer solch kleinen Anwendung wird ein paralleles controlling system oft wenig zweckmäßig sein. BandM booking integriert deshalb durchaus Elemente einer sehr einfachen Art von Kostenrechung, indem Konten grundsätzlich in Unter-Konten aufgelöst werden müssen. Dies erlaubt, ja erzwingt eine feinere Zuordnung von Aufwand und Ertrag zu einzelnen Projekten, Produkten oder Personen.

Die wichtigste Besonderheit unserer Lösung ist die, dass alle Daten in Klartext erfasst und gespeichert werden. Im Gegensatz zu Systemen die größere Datenmengen verarbeiten müssen, deshalb Datenbanken wie "RDBMS"-se benutzen (= "Relational Data Base Management Systems" = "Relationale Datenbanksysteme") und die Daten in binär verschlüsselter Form ablegen, sind bei BandM booking sämtliche Dateien und Datensätze vom Menschen jederzeit unmittelbar lesbar.

Die Software erzeugt keine Datensätze, sondern dies tut der Benutzer mit einem beliebigen Texteditor seiner Wahl. Die Software hat vielmehr die Aufgabe der (1) Konsistenzprüfung dieser Daten und (2) deren Auswertung. Letztere unterteilt sich in (2a) die laufende Visualisierung von Kontenständen und Kontenverläufen, und (2b) Erstellung der zum Jahresabschluss nötigen Tabellen, Datensätze und Druckvorlagen.

Die Sicherung der Daten, die Protokollierung aller Änderungen und die Überwachung des Radierungsverbotes wird nicht von BandM booking selbst überwacht. Da es sich beim Format aller Dateien um Klartext handelt, wird diese einem externen Versionskontrollsystem überlassen. Ein solches sind z.B. RCS, CVS, codesafe, subversion, etc. Diese System sind teils standardisiert, öffentlich spezifiziert, in der public domain und open source, und bieten somit eine verläßliche und nachvollziehbare Gewährleistung genannter, gesetzlich geforderter Eigenschaften.
Dies gilt besonders, wenn die Daten auf einen von einem verlässlichen Anbieter betriebenen Server ausgelagert sind, der regelmäßige Sicherungskopien und damit Protokollierungen durchführt.


Im übernächsten Kapitel 3 ("Doppelte Buchführung und BandM booking --- ein Tutorial ") werden wir die Textformate für Kontenplan und Journal vorstellen, mit Beispielen für unterschiedliche Buchungen. Insbesondere beschreibt Abschnitt 3.1 ("Der Arbeitszyklus mit BandM booking") die Arbeit mit dem Programm im Allgemeinen, und Abschnitt 4.1 ("Starten des Programmes") und folgend die Bedienung im Besonderen.

In Kapitel 4 ("Technische Aspekte von BandM booking ") folgen die technischen Aspekte unserer Implementierung.

Davor aber, wie angekündigt, zunächst eine par force-Zusammenfassung der Prinzipien und Grundbegriffe der Doppelten Buchführung im Allgemeinen.

^Inh 2 Prinzipien und Grundbegriffe der Doppelten Buchführung

Vorbemerkung zur folgenden Darstellung
Wir werden in diesem Abschnitt sämtliche der wichtigen Grundbegriffe der Doppelten Buchführung kurz definieren, aber dabei bewußt auif jegliches verdeutlichende Beispiel verzichten. Dadurch hoffen wir eine möglichst knappe Darstellung zu treffen, die von allen Lesern, bei denen Buchführung nicht zum täglichen Geschäft gehört, (wie z.B. der Autor selbst !-) später als "Spickzettel" und zur Wiederauffrischung verwendet werden kann.
Danach, im folgenden Kapitel, werden wir anhand unserer eigenen Implementierung zu jedem dieser Begriffe hinreichend Beispiele bringen, und auch das Zusammenspiel des gesamten Getriebes demonstrieren. Der Leser, die Leserin möge sich nicht grämen, sondern munter überlesen, was zunächst nicht verständlich ist, und ggfls. von späteren Abschnitten hierhin zurückkehren.

Das Grundprinzip der Doppelten Buchführung ist das der Bilanz.

Eine Bilanz ist dabei nicht etwa das, was der Volksmund so bezeichnet, und gerne als Metapher auch für Liebes- und Lebensdinge benutzt, ungefähr: "eine Tabelle, die erst am Ende eines Geschäftjahres zwecks Rechenschaftslegung erstellt wird", sondern vielmehr ein permanent aktualisiertes (!) Modell eines Unternehmens, speziell das seiner Sach- und Geldmittel.

Eine Bilanz ist eine Sammlung von einzelnen Posten, welchen jedem zu jedem Zeitpunkt ein konkreter Geldbetrag entspricht. Jeder Posten findet sich dabei unveränderlich auf einer von zwei Seiten der Bilanz:

Die Posten der rechten Seite der Bilanz, die Passiva, repräsentieren dabei die Mittelherkunft. Als typisches Beispiel und Merkhilfe steht da alles durch das Unternehmen geliehene Geld, also von Eigentümern und Kapitalgebern eingezahltes.

Die Posten der linken Seite der Bilanz, die Aktiva, bedeuten die Mittelverwendung, resp. die "momentane Materialisierung" der Mittel. Als typisches Beispiel und Merkhilfe steht da alles verliehene Geld, also das Eigentum des Unternehmens, das gerade "auf dem Girokonto liegt", oder auch in der Portokasse als Briefmarke. Aber auch Grundstücke und Maschinen, für deren Anschaffung ja Mittel aufgewendet worden waren, und die jetzt zum Vermögen des Unternehmens gehören.

Die Summe aller Beträge ist auf beiden Seiten einer Bilanz stets identlisch.

((
Der metaphorische Gebrauch des Wortes "Bilanz" erfolgt häufig in Zusammenhängen, die der Sache selbst widersprechen. So hört man in weniger qualifizierten Nachrichtensendungen immer wieder "das Unternehmen legte eine positive Bilanz vor", oder "präsentierte eine ausgeglichene Bilanz". Beides ist Unsinn! Eine Bilanz ist immer "ausgeglichen" im Sinne vorstehenden Satzes, und was dabei "positiv" bedeuten soll, ist uns leider völlig unklar.
))

Die einzelnen Posten einer Bilanz werden repräsentiert als Konten. Man sagt auch: "Die Bilanz wird aufgelöst in Konten".
Oder umgekehrt formuliert: die Bilanz ist genau identisch mit der Übereinander-Stellung, Überlagerung und Addition aller einzelnen Konten.

Jedes Konto hat eine linke Seite, genannt Soll, und eine rechte Seite, genannt Haben.

((
Diese Wortwahl ist nur historisch zu verstehen: bezogen auf einen Debitor bedeutet die linke Seite, was dieser bezahlen soll, die rechte, was dieser bereits bezahlt hat. Sich diese Herleitung zu merken ist allerdings keinesfalls nützlich, da bei anderen Arten von Konten die Bedeutung von "Soll" und "Haben" völlig anders sein kann. Man denke sich am zweckmäßigsten diese Begriffe lediglich als technische Synonyme für "linke und rechte Seite". Diese wiederum decken sich mit den Seiten der Bilanz, den Aktiv- und Passiv-Posten, also dem verliehenen und dem geliehenen Geld.
))

Jedes Konto, das einem Aktivposten entspricht, repräsentiert diesen auf seiner linken, Soll-Seite.

Jedes Konto, das einem Passivposten entspricht, repräsentiert diesen auf seiner rechten, Haben-Seite.

Diese "Auflösung der Bilanz in Einzelkonten" muß man sich, um sowohl das Grundprinzip als auch die verschiedenen Anwendungsfälle richtig zu verstehen und einfach einordnen zu können, ständig vergegenwärtigen, etwa wie folgt:

   Aktiva                               Passiva
   (Mittelverwendung)                   (Mittelherkunft)
  =============================++=============================
                               ||
    S    Bankkonto     H       ||   S   Stammkapital  H
    -----------+--------       ||   ---------+---------
    XXXXX      |               ||            |  XXXXXXX
                               ||
    S    Maschinen     H       ||   S   Eigenkapital  H
    -----------+--------       ||   ---------+---------
    XXXXX      |               ||            |  XXXXXXX
                               ||
    S    Grundbesitz   H       ||   S Verbindlichktn. H
    -----------+--------       ||   ---------+---------
    XXXXX      |               ||            |  XXXXXXX
                               ||
    S    Forderungen   H       ||   S   Kredite       H
    -----------+--------       ||   ---------+---------
    XXXXX      |               ||            |  XXXXXXX
                               ||
    etc.                       ||   etc.

((
Wenn man (in einem reinen Gedankenexperiment!) alle diese Konten übereinanderlegte und aufaddierte, erhielte man ein Konto, dessen Soll-Seite der Summe aller Aktiva und dessen Haben-Seite der Summe aller Passiva entspricht, und beide Summen sind identisch.
))

Jede Geschäftstätigkeit wird repräsentiert als eine Buchung.

Die lückenlose Folge aller Buchungen eines Geschäftsjahres, geordnet nach dem Zeitpunkt ihres Getätigtwerdens, bilden das Journal des Unternehmens.
Die lückenlose Folge aller Buchungen eines Geschäftsjahres, an denen ein bestimmtes Konto beteiligt ist, geordnet nach dem Zeitpunkt ihres Getätigtwerdens, bilden dessen Kontenblatt.

Eine Buchung ist eine Bewegung von Geldbeträgen zwischen mindestens zwei verschiedenen Konten. Dabei wird auf mindestens einem Konto ein Geldbetrag im Soll gebucht, und auf mindestens einem anderen (!) Konto ein Geldbetrag im Haben. Die Summe der Beträge, die im Soll gebucht werden und die im Haben gebucht werden, ist bei jeder Buchung identisch.

Die Sprechweise für eine Buchung zwischen zwei Konten hat die Form
"Soll-Konto an Haben-Konto".
Dabei ist das Wort "an" nur der syntaktische Trenner zwischen der Nennung beider Konten. Insbesondere bedeutet es keinerlei Mittelfluß von links nach rechts. Dieser kann in beide Richtungen stattfinden, je nach Art der beteligten Konten!

Es können mehr als zwei Konten an einer Buchung beteiligt sein (Splitbuchung), wobei jedes Konto maximal einmal auftreten darf, gebucht entweder im Soll oder im Haben. Die Summe aller Beträge je Buchung im Soll und im Haben ist, wie gesagt, identisch, unabhängig von der Anzahl der beteiligten Konten.

Neben der Nennung der beteiligten Konten trägt jede Buchung

  1. eine Buchungsnummer, die sie identifiziert,
  2. ein Kalenderdatum, an dem sie ausgeführt wurde,
  3. einen Buchungstext, der den Geschaftsvorgang beschreibt, der ihr in der Realität entspricht,
  4. Verweise auf die zu diesem Vorgang notwendigerweise existierenden Belege.

Die GoB verlangen, dass die Buchungen, die äußeren Geschäftsereignissen oder inneren Entscheidungen entsprechen, zeitnah und zeitrichtig vorzunehmen sind.

Insbesondere sind Rechnungsstellungen als Rechtsakt zu würdigen, der einen Rechtsanspruch auf Leistung erhebt, und mit ihrem Datum als vermögenswirksam zu buchen, unabhängig von tatsächlichen Zahlungsvorgängen, Lieferungen oder gar Streitigkeiten.

Weil zwischen Rechnungsstellung und Begleichen der Rechnung ein gewisser zeitlicher Abstand besteht, werden diese beiden Vorgänge meistens als zwei getrennte Buchungen modelliert. Zu diesem Zwecke gibt es spezielle Konten:

Ein Debitor-Konto repräsentiert einen Kunden, der eine Rechnung erhalten hat aber noch nicht bezahlt, der also dem Unternehmen Geld schuldet. Da der Anspruch des Unternehmens "Geld wert ist", ist dies eine "Verwendung" der Mittel des Unternehmens, nämlich es dem Kunden zu leihen, und ein Debitor-Konto ist ein Aktiv-Konto. (Der geschuldete Betrag wird im Soll gebucht.)

Ein Kreditor-Konto repräsentiert einen Lieferanten, der eine Rechnung gestellt hat, die vom Unternehmen noch nicht bezahlt wurde, dem also das Unternehmen seinerseits Geld schuldet. In dieser Situation ist der Lieferant "Mittel-Herkunft", da das Unternehmen es sich bei diesem geliehen hat, und ein Kreditor-Konto ist ein Passiv-Konto. (Der geschuldete Betrag wird im Haben gebucht.)

Ein Aktiv-Konto repräsentiert eine bestimmte Mittelverwendung (i.e. ein Teilposten der linken Seite der Bilanz). Sein Bestand wird vermehrt durch eine Buchung im Soll (d.h. auf seiner linken Seite) und vermindert durch eine Buchung im Haben (d.h auf seiner rechten Seite).

Ein Passiv-Konto repräsentiert eine bestimmte Mittelherkunft (i.e. ein Teilposten der rechten Seite der Bilanz). Sein Bestand wird vermehrt durch eine Buchung im Haben (d.h. auf seiner rechten Seite) und vermindert durch eine Buchung im Soll (d.h auf seiner linken Seite).

      (ein Aktivkonto)               (ein Passivkonto) 	          
    S                        H     S                        H       
    -----------+--------------     ------------+------------- 
    Vermehrung | Verminderung      Verminderung|   Vermehrung
               |	                       |               

Es gibt folglich vier verschiedene Arten von Buchungen, was ihre Auswirkungen auf die Bilanzsumme angeht:

  1. Bilanzverlängerung Aktivkonto im Soll, Passivkonto im Haben.
    "Aktivkonto an Passivkonto"
    Die Gesamtbilanzsumme erhöht sich.
    Bsp: Das Unternehmen leiht sich Geld: Die Barkasse (Aktivkonto) und die Verbindlichkeit (Passivkonto) nehmen zu.
  2. Bilanzverkürzung Aktivkonto im Haben, Passivkonto im Soll.
    "Passivkonto an Aktivkonto"
    Die Gesamtbilanzsumme vermindert sich.
    Bsp: Das Unternehmen zahlt den Kredit wieder zurück.
  3. Aktiv-Aktiv-Tausch Zwei Aktivkonten, eins im Soll, eins im Haben.
    "Aktivkonto an Aktivkonto"
    Die Gesamtbilanzsumme bleibt unverändert.
    Bsp: Das Unternehmen kauft eine Maschine gegen Bargeld.
  4. Passiv-Passiv-Tausch Zwei Passivkonten, eins im Soll, eins im Haben.
    "Passivkonto an Passivkonto"
    Die Gesamtbilanzsumme bleibt unverändert.
    Bsp: Ein Gläubiger erklärt sich bereit, ein Darlehen in einen Anteil umzuwandeln.

Die Summe der Beträge aller Buchungen im Haben, minus der Summe der Beträge aller Buchungen im Soll ist der momentane Kontostand, der Saldo des Kontos. Dies ist der Wert, der momentan dem Bilanzposten entspricht, den dieses Konto repräsentiert. Im weiteren Sinne ist dies ein "laufender Wert", ein "momentaner Kontostand".

Überwiegt die Summe der Buchungen im Soll, so spricht man von einem Sollsaldo.
Überwiegt die Summe der Buchungen im Haben, so spricht man von einem Habensaldo.
(In unserer Implementierung, wie in vielen anderen computerbasierten Buchungsprogrammen, wird ein Soll-Saldo durch eine positive Zahl ausgedrückt, und ein Haben-Saldo durch eine negative.)

Im engeren Sinne werden die Worte "Saldo" und "Saldieren" aber auch im Zusammenhang mit dem Abschließen des Kontos im Verlaufe der Jahresabschlussesrechnung verwendet, also für den letzten Stand des Kontos innerhalb eines Geschäftsperiode, und dessen Ermittelung. (Dies ist auch Vorbild für die umgangssprächliche Metapher.)

Zwecks genauerer Steuerung oder besserem Überblick kann ein Konto in Unterkonten zerlegt werden. Die Buchungen finden dann auf einem der Unterkonten statt. Beim Eingang in die Bilanz werden alle Unterkonten und alle ihre Buchungen jedoch zusammengefasst und als ein einziges Konto behandelt. (Dies ist beliebig oft möglich, da der Vorgang der Kontenzerlegung "mathematisch kompositional" ist!)

Die Aktivposten (und die sie darstellenden Aktivkonten) repräsentieren die momentanen Vermögenswerte des Unternehmens, also die dem Unternehmen zukommenden Eigentumsrechte.

Die Passivposten (und die sie darstellenden Passivkonten) repräsentieren die momentanen Herkunft der Mittel, also vice versa die Eigentumsrechte am Unternehmen.

Einzige Ausnahme ist der Passivposten Eigenkapital. Er gibt an, wieviel vom Unternehmen "ihm selbst gehört".
Eigenkapital darf nicht mit Stammkapital verwechselt werden, was die Geldmenge ist, die zur Gründung des Unternehmens von den beteiligten Gesellschaftern bereitgestellt wurde.
In gewisser Weise ist Eigenkapital sogar ein Gegenteil zu Stammkapital.

Eine Aufwendung ist das Verlassen von Mitteln (Sachmitteln oder Geldmitteln) aus dem Eigentum des Unternehmens aufgrund eines Geschäftsvorganges.

Eine Ertrag ist das Hineinkommen von Mitteln (Sachmitteln oder Geldmitteln) in das Eigentum des Unternehmens aufgrund eines Geschäftsvorganges.

Beide Arten von Vorgängen werden als Abnahme resp. Zunahme des Passivpostens Eigenkapital verbucht.

Das dem Posten Eigenkapital entsprechende Konto wird dementsprechend in verschiedene Unterkonten aufgelöst, die die verschiedenen Arten von Aufwendung und Ertrag repräsentieren.

Grundsätzlich ist einzig die Erhöhung oder Verminderung des Bilanzpostens "Eigenkapital" nach Deutschem Steuerrecht Gundlage der Besteuerung.

Die Zusammenhänge werden klar, wenn man sie sich wiederum geometrisch verbildlicht:

   Aktiva                               Passiva
   (Mittelverwendung)                   (Mittelherkunft)
  =============================++=============================
                               ||
                               ||   S   Stammkapital  H
                               ||   ---------+---------
                               ||            |  XXXXXXX
                               ||
                               ||   S   Eigenkapital  H
                               ||   ---------+---------
                               ||            |  XXXXXXX
                                /                      \
                               /                        \
                              /                          \
                             /                            \
                            / Unterkonten:                 \

                              S (Aufwandskonto)    H
                                (=Verminderung des Eigenkap.)
                              -----------+----------
                              Aufwand    | 
                              Aufwand    | 
                                         | Korrekturbuchung
                              etc....    

                              S (Ertragsskonto)    H
                                (=Vermehrung des Eigenkap.)
                              -----------+----------
                                         | Ertrag
                                         | Ertrag
                              Korrektur  | 
                                           etc....    

Als grundlegend verschieden zu behandelnde Kontenklassen gibt es folglich vier ungefähr gleichstarke Gruppen:

  1. Aktivkonten
  2. Passivkonten
  3. Aufwandskonten
  4. Ertragskonten

Aktiv- und Passiv-Konten werden als Bestandskonten zusammengefaßt.
Aufwands- und Ertragskonten, die Unterkonten des Eigenkapitals, werden als Erfolgskonten zusammengefaßt.

Bestandskonten werden auf beiden Seiten bebucht, reflektierend die entsprechenden Zu- und Abnahmen.

Im Gegensatz dazu werden Erfolgskonten im Normalfall stets nur auf einer Seite bebucht: Aufwandskonten im Soll, Ertragskonten im Haben.
Ausnahmen sind Korrekturbuchungen, die naturgemäß auf der je anderen Seite stehen.

Der GoB "Klarheit" verlangt nämlich, dass der Buchungsvorgang ein irreversibler Akt ist. Fehler, die dabei gemacht werden, dürfen nicht durch Verändern des Datenbestandes nachträglich beseitigt werden, sondern erfodern eine explizite Korrekturbuchung mit dem entsprechenden Buchungstext.

Die Anschaffung eines Betriebsmittels ist zunächst ein reiner Aktiv-Aktiv-Tausch. (Wenn dieser "auf Kredit" geschieht, ist der Effekt zwar eine Bilanzverlängerung, aber die Kreditaufnahme kann man für die folgenden Überlegungen ja auch als unabhängigen, vorangehenden Geschäftsvorfall abspalten)

Diese Anschaffung ist also noch kein Aufwand.
Ein Aufwand entsteht aber durch den Verschleiss des Betriebsmittels. Dieser wird dargestellt als Abschreibung für Abnutzung, kurz AfA. Für Abschreibungen gibt es spezielle Aufwandskonten, und beim Jahresabschluss werden die Abschreibungen modelliert durch Buchungen "Abschreibungskonto an Maschinenbestand". Dies bedeutet eine Bilanz-Verkürzung, mindert also das Betriebsvermögen (hier: Anlagevermöge) und damit den Gewinn.

Im Falle von Havarien etc. sind auch Sonderabschreibungen möglich.

Für die Aufteilung der Bilanz in Konten gibt es Standardisierungen. genannt Kontenrahmen. Diese sind als Vorschläge zu betrachten. Sie werden jährlich weiterentwickelt. Sie müssen für ein konkretes Unternehmen mindestens durch "Ausdünnen" angepasst werden.

Der Grundsatz der "buchhaltérischen Klarheit" gebietet allerdings, sich an einem solchen Standardmodell soweit als sinnvollerweise möglich zu orientieren, damit Leser mit professionellem Vorverständnis auf möglichst wenig Ungewohntes stoßen.

In Deutschland sind dies der vom BDI herausgegebenen "Industriekontenrahmen"; und die von der Firma DATEV entwickelten "Standardkontenrahmen", darunter besonders der SKR-03 und der SKR-04.

Die Abfolge der Konten in SKR-03 ist an industriellen Produktionsprozessen orientiert. Er beinhaltet Elemente, die Kostenrechnung und Controlling unterstützen sollen.
Die Konten in SKR-04 sind hingegen gruppiert nach Kontenart.
Unsere Beispiele folgen dem SKR-04.

Jede Geschäftstätigkeit ist durch gesetzliche Vorschriften gegliedert in Perioden, an deren Ende Berichte an berechtigte Stellen abzuliefern sind, insbesondere eine Steuererklärung an das Finanzamt.

Zu diesem Zweck wird am Ende des Geschäftsjahres (oder auch Wirtschaftsjahr oder auch Geschäftsperiode genannt) ein Jahresabschluss erstellt.

Ein Geschäftsjahr ist i.A. identlich mit dem Kalenderjahr, es sei denn man beantragt und erhält genehmigt ein sog. abweichendes Wirtschaftsjahr.

Zum Zwecke dieses Abschlusses werden zunächst die Abschreibungen für Abnutzung (AfA) gebucht, welche das Sachvermögen (repräsentiert durch Aktivkonten) vermindert durch Buchungen auf spezielle Aufwandskonten, die die AfA repräsentieren.

Dann werden die Salden von Bestands- und Erfolgskonten ermittelt und nach bestimmten Bilanzierungsregeln zum Zwecke des Ausdruckens zusammengefasst.
Zuletzt werden die Salden der Erfolgskonten (Aufwand und Ertrag) zum Eigenkapital umgebucht, und dessen Veränderung gegenüber dem Vorjahr als Basis der Versteuerung ermittelt.
(Dabei sind allerdings bestimmte Hinzurechnungen vorzunehmen: Bestimmte Aufwendungen, die im handelsrechtlichen Sinne den Gewinn durchaus schmälern, wie z.B. Anteile an Arbeitsessen, Säumnisgebühren, Abschläge auf Steuern, sind nämlich "nicht absetzbar" und müssen zur Ermittlung des steuerlichen Gewinnes wieder dazuaddiert werden. Dazu dient in BandM booking die spezielle Kontenklasse "kn").

Zum Zwecke des Jahresabschlusses ist vorher schon darauf zu achten, dass Aufwendungen und Erträge, die zwar in dieser Geschäftsperiode gebucht werden, sich aber anteilig erst in der folgenden auswirken, nicht zur Gänze dem jeweiligen Aufwands- und Ertragskonto zugerechnet werden, sondern in entsprechendem Anteil einem Rechnungsabgrenzungskonto.

Ein Aktives Rechnungsabgrenzungskonto repräsentiert Beträge, die im nächsten Geschäftsjahr als Aufwand verbucht werden, in diesem Geschäftsjahr aber einen Vermögenswert darstellen, nämlich ein bereits bezahltes Anrecht auf eine in Zukunft durch Dritte zu erbringende Leistung. Als Vermögenswert gleichen sie somit steuerlich den in der Kasse fehlenden Geldbetrag aus.

Ein Passives Rechnungsabgrenzungskonto repräsentiert Beträge, die im nächsten Jahr als Erträge verbucht werden, aber jetzt noch durch Verbindlichkeiten ausgeglichen werden, nämlich durch die in Zukunft an einen Dritten zu erbringende Leistung, die dieser schon bezahlt hat. Als Verbindlichkeit gleichen sie somit steuerlich den in der Kasse bereits enthaltenen Geldbetrag aus.

Zum Zwecke des Rechenschaftsberichtes werden nach all diesen "aufräumenden" Buchungen mehrere Zusammenfassungen erstellt:

  1. Die Bilanz im engeren Sinne, welche den Zustand der Aktiva und Passiva am Ende des Geschäftsjahres darstellt,
  2. die Gewinn- und Verlustrechnung, welche die Aufwände und Erträge auflistet, die sich auf die Höhe des Eigenkapitals auswirken,
  3. und das Inventar, in dem alle Anlage-Aktiva aufgelistet werden unter Angabe ihres Buchwertes, also ihres damaligen Anschaffungspreises abzüglich der im Laufe der Zeit vorgenommenen Abschreibungen (Afa und/oder Sonderabschreibung)

Damit sind Journal und Konten dieses Geschäftsjahres geschlossen. Die Salden der Bestandskonten werden für das folgende Geschäftsjahr benutzt zur Bestimmung der Eröffnungsbuchungen, die dann die ersten Buchungen eines neuen Journals für ein neues Geschäftsjahr sind.

^Inh 3 Doppelte Buchführung und BandM booking --- ein Tutorial

^Inh 3.1 Der Arbeitszyklus mit BandM booking

Die grundlegendsten Eigenschaften von BandM booking wurden oben in Abschnitt 1.4 ("Eigenheiten von BandM booking. Notwendige Externe Programme ") aufgelistet. Wie dort erwähnt ist es ein Buchhaltungssystem geeignet für kleine Unternehmungen mit relativ wenigen Buchungen, und vollkommen textbasiert.
Die Rahmendaten des Unternehmens, der Kontenplan und alle Buchungen einer Periode werden als formatierter Klartext in entsprechende Dateien geschrieben.
Ergebnis- und Übertragsdateien, die das Programm im Rahmen des Jahresabschlusses generiert, sind ebenfalls formatierter Klartext.
Alle Dateien sind ohne spezielle Software jederzeit gut lesbar.

Die BandM booking Software hat zur Zeit die Aufgabe der

  1. Konsistenzprüfung,
  2. analytischen Auswertung,
  3. graphischen Darstellung,
  4. Jahresabschlusserstellung.

Jede beteiligte Datei ist gegeben als XML-Datei, die einer bestimmten Syntax folgt, die als Dokument-Typ-Definition wohl definiert und dokumentiert ist. Das konkrete Format jeder XML-Datei ist das einer d2d-Datei, da diese einfacher lesbar und schreibbar ist [metatools_d2d].

Die Art und Weise dieser Typ-Deklaration und die für BandM booking definierten Typen werden genauer erklärt in Abschnitt 3.3.2 ("Formate der Textdateien und deren Definition")

Dies sind die am Ablauf des Programmes BandM booking beteiligten Dateien (die hinterlegten Links führen jeweils zu den Daten des Beispiels, relativ zum Platz der Datei die Sie gerade lesen):

  1. Rahmendaten, unverändert über die Lebensdauer des Unternehmens, in der einen(1) Datei namens config.
  2. Kontenplan, einmal(1) je Unternehmen, monoton wachsend falls erforderlich. In unserem Beispiel heißt die Datei kontenplan.
  3. Journal: Je Rechnungsperiode/Geschäftsjahr genau eine(1) Textdatei, welche die Folge der Buchungssätze enthält. (im Beispiel also journal_09_10, journal_10_11, etc., im allgemeinen "journal_<>", falls Wirtschafts- und Kalenderjahr identisch sind, oder "journal_<>_<>" falls zwei Kalenderjahre an einem Wirtschaftsjahr beteiligt sind.)
  4. Auswertungsregeln zur Erstellung des Jahrsabschlusses. Diese sind zwar neu definierbar für jedes neue Wirtschaftsjahr, werden aber sonst vom letzten Jahr übernommen. Sie sind auch in der Datei "config" enthalten, die also ebenfalls monoton wachsen kann.

Beim Start des BandM booking Programmes muss ein Arbeits-Verzeichnis angegeben werden, das alle benötigten Dateien enthalten muss, sowie die Jahreszahl des Geschäftsjahres, die es zu bearbeiten gilt. Programmstart und diese Angaben können entweder über eine Kommandozeile oder über eine graphische Benutzeroberfläche geschehen, s.u. Abschnitt 4.2 ("Bedienung der Programmes ").

Die Applikation liest daraufhin die Rahmendaten, den Kontenplan und die Eröffnungsbuchungen und das Journal des entsprechenden Jahres ein und überprüft alle Daten auf Konsistenz.

Danach wird (falls gewünscht) eine graphische Benutzeroberfläche, auch genannt GUI, gestartet, die es erlaubt, Konten und Journal anzusehen und zu durchsuchen, und/oder es wird der Jahresabschluss generiert. Letzteres ist nur möglich, falls die Konsistenzprüfung erfolgreich war.

Die Arbeit mit BandM booking gestaltet sich normalerweise so:

  1. Der momentane Stand des jüngsten Journales (d.i. des Journales des aktuellen Geschäftsjahres) wird von der Applikation geladen, dabei wird dieses auf Konsistenz überprüft (was immer gelingen sollte, s.u.!-),
  2. Der Text der Journaldatei wird mit neuen Buchungen erweitert. Dabei wird das GUI benutzt, um Kontenplan, Kontenstände, alte Buchungen etc. auszuwerten. (Alle Information kann parallel aber auch aus den Quelltexten [Journaldatei, Kontenplan] entnommen werden, oft aber nicht so bequem!)
  3. Das Erstellen einer neuen Buchung beinhaltet insbesondere das Vergeben der Buchungsnummer, das Benennen der Art des Papier-Beleges im Journal, das Stempeln des Papier-Beleges mit dem Buchungsdatum und der Buchungsnummer und das Abheften des Beleges. (Man sieht, BandM booking eignet sich für kleine Unternehmungen !-)
  4. In kurzen Abständen wird das Programm neu gestartet, um die erweiterte Journaldatei zu laden und so die neu eingetragenen Buchungen überprüfen zu lassen.
  5. Falls dabei Inkonsistenzen entdeckt werden (z.B. nicht lückenlos wachsende Buchungsnummern, fallende Kalenderdaten, falsche Kombination von Konten und Beträgen) müssen diese sofort in der Textdatei korrigiert werden.
  6. Erst wenn die Erweiterungen fehlerfrei durchlaufen (und selbstverständlich auch inhaltlich korrekt erscheinen!-) wird ein standardisiertes externes Versionskontrollprogramm wie RCS, CVS, codesafe, subversion, etc. aufgerufen, mit diesem ein "commit" durchgeführt, und die erweiterte fehlerfreie Journaldatei auf ein externes Speichermedium gesichert und gleichzeitig alle Änderungen dokumentiert. Erst durch dieses "commit" wird im gesetzlichen Sinne gebucht.

Dieser Zyklus mag zunächst umständlich erscheinen. Das Grundprinzip der textuellen Repräsentation aller Daten hat allerdings den Vorteil, dass nichts von der Software "im Geheimen" durchgeführt wird, dass sämtliche beteiligten Daten offen zutageliegen und keinem Programm vertraut werden muss, welches binäre Daten in lesbare Darstellung umwandelt.

Der Zyklus der Bearbeitung selber könnten in einer späteren Implementierung selbstverständlich "in das Programm hinein" verlagert werden, sodass die Editierung des Journals in einem integrierten Editor erfolgt, und die Konsistenzüberprüfung sofort, für jede einzelne Buchung, und die Eingabe mittels weiterer Eingabehilfen, Assistenten, Bildschirmmasken, etc., s.a. Abschnitt 4.6 ("Mögliche weitere Ausbaustufen ").

Eine Notwendigkeit dafür hat sich in unserer eigenen Arbeit bisher nicht ergeben! Der Vorteil des momentanen Ansatzes besteht darin, dass der Anwender ihren/seinen Lieblingseditor benutzen kann, oder auch mit wenig Programmierarbeit Buchungen auf überprüfbare Weise automatisch generieren.

Der geschilderte Arbeitszyklus beruht darauf, dass nur eine einzige Person berechtigt ist, die Journaldatei zu erweitern und Buchungen vorzunehmen. Wenn mehr als eine Person berechtigt sein soll zu buchen, dann müssen die Auschluss-, Synchronisierungs- und Protokollierungsmechanismen des verwendeten Versionskontrollsystem dafür benutzt werden.

Der Abschluss eines Wirtschaftsjahres wird von der Applikation vorgenommen, wenn ihr das mit einem Kommandozeilenparameter abverlangt wird, oder wenn die entsprechende Menüfunktion im GUI aufgerufen wird. Dann wird die Druckvorlage für die Bilanz erstellt wird, und eine Datei mit Eröffnungsbuchungen für das folgende Wirtschaftsjahr; Genaueres s.u. Abschnitt 3.4 ("Fortsetzung Beispiel: Jahresabschluss und Bilanz "). Diese Eröffnungsbuchungen werden immer vor dem aktuellen Journal eingelesen.

^Inh 3.2 Die beteiligten Dateien

Bei Programmstart muss, wie gesagt, ein Datei-Verzeichnis angegeben werden, in welchem alle beteiligten Dateien liegen.
Der Namen der Datei mit den Rahmendaten ist dabei fest auf config festgelegt.
Diese enthält dann die Namen der anderen beteiligten Dateien, und weitere Rahmendaten, wie die Dauer der Geschäftsperiode, den Namen des Unternehmens und Verweise auf graphische Hilfsdaten für die Gestaltung des Jahresabschlusses, etc.

Genaueres zu den Feldern dieser Datei s.u. im Rahmen unseres Beispieles, beginnend bei Abschnitt 3.3.1 ("Errichtung des Unternehmens, Konfigurationsdatei ").

Folgende Graphik zeigt alle beteiligten Dateien, wie sie gefunden werden durch dünne Pfeile und die wichtigsten der Datenflüsse durch dicke Pfeile.

Bild der Dateien

Der Kontenplan definiert alle in Buchungen möglichen Konten-Nummern, und definiert diese mit einer Klartext-Bezeichnung, einer Kontenklasse,etc., s.u. Abschnitt 3.3.5 ("Kontenplan"). Er wird für die Dauer einer Unternehmung von Jahr zu Jahr höchstens monoton erweitert, niemals ausgedünnt oder existierende Einträge verändert.

Während es nur eine(1) config Datei und eine(1) Kontenplan-Datei gibt, gibt es hingegen für jedes Geschäftsjahr jeweils eine(1) eigene "Journal"-Datei und je eine(1) Vorlage für die Bilanz. Dieses sind dann aber auch sämtliche Dateien, die vom Benutzer ausgefüllt werden müssen; alle weiteren Dateien werden mit dem Jahresabschluss automatisch generiert.

Die Namen der Journal-Dateien werden aus der Jahreszahl des Geschäftsjahres abgeleitet, wie definiert durch ein "string format template" in der config-Datei. Dessen Format ist das aus "printf" in C oder Java bekannte. In unserem Beispiel lautet dieses Template, und die daraus abgeleiteten Dateinamen ...

    #filetemplate_ledger journal_%02d_%02d

    --> bewirkt die Datei-Namen -->

    journal_06_07
    journal_07_08
     etc.

Diese Journal-Dateien enthalten alle Buchungen einer Geschäftsperiode/eines Wirtschaftsjahres in zeitlich richtiger Reihenfolge, ebenfalls als d2d-codierter Klartext. Jeder Buchungssatz folgt (wie alle Bestandteile aller Dateien) einer bestimmten Syntax. Diese bildet die laut den gesetzlichen Vorschriften und den GoBS (Abschnitt 1.3 ("Heutige Situation, GoB und Elektronische Datenverarbeitung")) benötigten Angabe auf entsprechende Felder des Eintrages ab (z.B. Kalenderdatum, Buchungsnummer, beteiligte Konten). Die lokale Konsistenz (z.B. Kontenklassen im Soll und Haben) und die globale Konsistenz (z.B. lückenlos ansteigende Buchungsnummern) werden beim Laden des Journals überprüft.

Die Formate all dieser Dateien und der einzelnen Einträge werden im Folgenden Text anhand des Beispiels genau beschrieben, siehe Abschnitt 3.3.3 ("Format der config-Datei und der Datentyp-Definitionen "), Abschnitt 3.3.5 ("Kontenplan"), Abschnitt 3.3.6 ("Format der Buchungssätze, eröffnende Buchungen"), Abschnitt 3.4.3 ("Generierung der Bilanz-Druckvorlage "). Allgemeines zu ihrer Verwendung und zur Definitionsmethode steht in Abschnitt 3.3.2 ("Formate der Textdateien und deren Definition").

Der Name der Druckdatei des Jahresabschlusses und der dafür notwendigen Formatvorlage wird auf gleiche Weise wie für die Journaldateien berechnet. Zur Zeit hat beides das Format eines LaTeX-Dokumentes und ist genauer beschrieben in Abschnitt 3.4 ("Fortsetzung Beispiel: Jahresabschluss und Bilanz ").

^Inh 3.3 Unser Beispiel sandsack GmbH: Eingabedaten

Zur Verdeutlichung und zur Dokumentation wichtiger Details in den Formaten der beteiligten Dateien präsentieren wir in den folgenden Abschnitten ein größeres Beispiel. Die vollständigen und lauffähigen Dateien finden sich in

  1. ../../examples/sandsackGmbH/config
  2. ../../examples/sandsackGmbH/kontenplan
  3. ../../examples/sandsackGmbH/journal_09_10
  4. ../../examples/sandsackGmbH/journal_10_11

Diese Links führen zu Kopien dieser Dateien relativ zu dieser Datei hier, sei sie online oder lokal installiert. Diese Dateien werden auch benutzt wenn das Beispiel durchgeführt wir, wie u.a. in Abschnitt 4.2 ("Bedienung der Programmes "), Abschnitt 4.3 ("Herunterladen von Quellen, Beispiel und Dokumentation") und Abschnitt 4.4 ("Übersetzen der Quellen, Make-Targets für die Beispiele") beschrieben.

Hat man in dessen Kontext einen Jahresabschluss durchgeführt, dann kommen weitere, automatisch generierte, aber ebenfalls gut lesbare Dateien hinzu.

Dieser Abschnitt beschreibt die grundlegenden Rahmendaten, und dann verschiedenartige Buchungsvorgänge, wie sie in BandM booking realisiert werden, anhand der entsprechenden Ausschnitte aus diesen Dateien. Der nächste Abschnitt beschäftigt sich dann mit dem automatischem Jahresabschluss.

^Inh 3.3.1 Errichtung des Unternehmens, Konfigurationsdatei

In unserem Beispiel entscheiden sich die Herren Dipl.-Ing. Willi Pick und Prof. Dr. Otto Gotowohl, zur Mitte des Jahre 2009 die "Sandsack GmbH" zu gründen.
Da dies eine kleine feine Firma wird, mit wenigen Buchungen pro Jahr, scheint ihnen BandM booking die geeignete software für ihre Buchführung.

Als allererstes muss ein frisches Verzeichnis auf der Platte eingerichtet werden, und darin eine Datei namens config.

Der Name der config Datei ist festgelegt, damit das Programm leicht den Einsprungpunkt findet. Eine Hauptaufgabe dieser Datei ist allerdings, wie oben beschrieben, die Namen der weiteren Dateien festzulegen, bzw. die Schemata, wie diese aus den Jahreszahlen abgeleitet werden. Die so benannten Dateien müssen sich im selben Verzeichnis wie die Datei config befinden.

Darüber hinaus werden bestimmt die Firma, das erste Geschäftsjahr, der erste Monat jeden Geschäftsjahres und wenige andere konstant bleibende Stammdaten hier angegeben.

Der Aufbau der config-Beispieldatei wird in den nächsten Abschnitten genauer erklärt; eine ausführlich kommentierte Fassung, die einzelnen Einträge in ihrer Bedeutung beschreibend, sähe aus wie folgt:

#d2d 2.0 text using eu_bandm_booking  : configuration
// diese erste Zeile bestimmt den Dokumenttyp, 
// also das Format aller folgenden Einträge


// Monat mit dem das Geschäftsjahr beginnt, hier der Julei
  #first_month 7

// Kalenderjahr, in welchem das allererste Geschäftsjahr beginnt (=2009)
  #first_year  09 

// Firma des Unternehmens
  #company_name Sandsack GmbH, Berlin

// Fast alle Einträge erlauben, einen(1) Kommentareintrag dranzuhängen,
//   der zu Dokumentation und Erklärung benutzt werden kann.
//   Dies ist also der Kommentar zum "configuration" Element, das gerade
//   gefüllt wird.
  #comment 
  Dies ist der  Haupt-Konfigurationseintrag für fas Beispiel "Sandsack GmbH, Berlin"
  im Rahmen der Benutzerdokumentation für BandM booking. 
  Der Name der enthaltenden Datei ist festgelegt auf "config", 
  und die meisten seiner Unterelemente geben die Namen (oder
  Namens-Schemata) für alle anderen Dateien.

// Name der Datei, die den Kontenplan enthält
  #filename_accountplan kontenplan

// Schema für den Namen der Datei mit den Eröffnungs-Saldi
//  "%02d" wird durch die Endziffern der beiden beteiligten Kalenderjahre
//  ersetzt, also z.B.   "eroeffnungsSaldi_11_12"
  #filetemplate_opening eroeffnungsSaldi_%02d_%02d

// Schema für den Namen der Datei mit den Buchungs-Daten, Ersetzung genauso!
  #filetemplate_ledger journal_%02d_%02d

// Schema für den Namen der Datei in dem die software die Bilanz ablegt
  #filetemplate_report bilanz_%02d_%02d.tex

// Schema für den Namen der Datei mit der Text-Vorlage für die Bilanz
  #filetemplate_report_template bilanz_vorlage_%02d_%02d.tex


  #birilis 
    #businessYear 09/10
      // Die ab dem Jahr 09/10 gueltigen GRUPPIERUNGEN für die Zusammenfassung
      //   der Saldi der Konten in Bilanz und Geschäftsbericht
      //   (genauere Beschreibung später)
      #group#from 4120 #upTo 4400 #text Erlöse aus Lieferungen und Leistungen
      #group#from 7100 #upTo 7100 #text Zinserträge
      // -------- SCHNIPP --------------------------

#eof

^Inh 3.3.2 Formate der Textdateien und deren Definition

Die oben stehende config-Datei ist ein erstes und typisches Beispiel für das angewandte Datenformat. Es handelt sich um d2d, eine schreib- und lesbare Darstellung von XML-Strukturen, siehe [metatools_d2d].

XML zerlegt als mark-up-Format einen Eingabetext in Segmente, genannt "Elemente", die durch sog. "Tags" begrenzt werden und deren Inhalt einer bestimmten Syntax folgen muss, was die enthaltenenen Texte und/oder weiteren Elemente angeht.

BandM booking benutzt die Element-Struktur von XML, um sämtliche Eingabedaten zu realisieren. Es benutzt die d2d Schreibweise, um deren Ein- und Ausgabe menschenfreundlich zu gestalten.

Im originären XML werden die Tags dargestellt durch sperrige Zeichenkombinationen wie

    <tag>inhalt</tag>

Im d2d-Format hingegen wird der Start-Tag, der den Beginn des Textsegmentes anzeigt, nur durch das Hashmark-Zeichen eingeleitet. Der End-Tag kann meist weggelassen werden.
Mit demselben Mechanismus werden auch sog. Attributwerte eingegeben, die im originalen XML noch fingerverdrehender zu schreiben sind:

XML: 
      <tag attr="attribute value"/>
D2D:
     #tag #attr attribute value

Abgesehen davon aber ist das d2d-Format "nichts anderes" als ein XML-Format, es gibt eine einfache wohldefinierte Übersetzungsregel, und damit sind alle Standard-Werkzeuge, -Verfahren, -Regeln und -Spezifikationen der XML-Welt (fast unmittelbar) auf d2d-Texte anwendbar.

Dass alle beteiligten Dateien aus Klartext bestehen, der mit jedem beliebigen Editor erstellt, jederzeit ohne spezielle Software gelesen und, dank dem d2d Format, vom Menschen auch bequem gelesen und geschrieben oder gar diktiert werden kann, bewirkt eine hohe Flexibilität und Nachvollziehbarkeit aller Vorgänge im und mit dem Buchungssystem. Dies sind wesentliche Merkmale unserer Philosophie. Im Sinne des politisch-emanzipatorischen Grundgedankens sind die Dokumenttyp-Definition, also die Regeln, welche Mark-Up-Elemente an welchen Stellen auftauchen dürfen, welchen Inhalt sie haben dürfen, etc., für alle diese Klartext-Einträge ebenfalls einfach lesbar.

Sie befinden sich in in der d2d-Definitionsdatei eu_bandm_booking.dd2.

Man würdige bitte, dass diese kleine Textdatei auf knapp einhundert(100) Zeilen die gesamte Eingabesyntax (und große Teile der internen Datenstrukturen) des Gesamtsystems definiert, und das in eine (relativ) klaren Schreibweise, die auch dem Nicht-Informatiker erklärbar sein sollte, siehe die detaillierteren Darstellungen im folgenden. Kompakter und übersichtlicher gehts kaum.

Dazu kommen dann allerdings mehr Zeilen Dokumentationstext (kann in verschiedenen Sprachen hinzugefügt werden). Dieser geht in die navigierbare und graphisch aufbereitete Dokumentations-Version dieser Definitionsdatei ein. Diese findet sich in d2d_documentation_eu_bandm_booking_dynamic_user_de/index.html, im folgenden kurz "generierte Dokumentation" genannt. Hier kann man durch Anklicken herumspringen und sich über enthaltene und enthaltende Elementnamen und Grammatikstrukturen interaktiv informieren.

Eine mehr technische Format-Definition, entsprechend dem XML Standard, ist das DTD Format, [xml] . Eine solche wird automatisch aus der d2d-Definitionsdatei abgeleitet. (Z.B. zur Generierung der Datenstrukturen des tdom-Modelles, s.u. Abschnitt 4.5 ("Aufbau des Programmes").)

Eine DTD ist viel weniger gut lesbar, enthält aber genau dieselben Definitionen und braucht deshalb nur von einem Programmierer zur Kenntnis genommen werden, der die BandM booking Daten selbst weiterverarbeiten will. Sie findet sich bei eu_bandm_booking.dtd Eine gerenderte Version, mit graphischer Übersicht, Anklickbaren links und farblicher Differenzierung findet sich in ./eu_bandm_booking_rendered_dtd.html

Dieser Text behandelt im folgenden nicht das DTD- sondern das dd2-Definitionsformat und erklärt dessen wichtigsten Grundzüge anhand der Formate der behandelten Dateien.

^Inh 3.3.3 Format der config-Datei und der Datentyp-Definitionen

Der Beginn der d2d-Definitions-Datei eu_bandm_booking.dd2 beschreibt das Format der config-Datei wie folgt:

// eu_bandm_booking.dd2 / .dtd
//   format definitions for eu.bandm.bmp.book2  
//    book keeping program in the d2d 2.0 version 

module eu_bandm_booking 

  // -------- SCHNIPP --------------------------

  public tags configuration
     = (filename_accountplan & company_name & first_month & first_year
         & filetemplate_ledger 
         & filetemplate_opening & filetemplate_autoDeprecation
	 & filetemplate_report & filetemplate_report_template
         & comment?
	),
       birilis+

  tags filename_accountplan, company_name, first_month, first_year, 
       filetemplate_ledger, 
       filetemplate_opening, filetemplate_autoDeprecation, 
       filetemplate_report, filetemplate_report_template
	 = #chars 

  tags comment = #chars 

  tags birilis = ...

Hinter dem Schlüsselwort "tags" steht das Tag, dessen Inhalt definiert wird. Hinter dem folgenden Gleichheitszeichen ein sog. "regulärer Ausdruck", der die Folge der Elemente definiert, die Inhalt des Elementes sein können, das durch das Tag begonnen wird.

Betrachtet man die Folge dieser Elemente, dann kann man obigen Definitionstext so lesen:

  1. Jeder configuration-Eintrag besteht zunächst aus den Unter-Einträgen filename_accountplan, first_month, company_name, etc., wie in der ersten Klammer aufgeführt.
  2. Diese Einträge sind allesamt obligatorisch.
  3. Nur comment ist optional, was durch das angehängte Fragezeichen "?" festgelegt wird.
  4. Die Reihenfolge all dieser Einträge ist allerdings beliebig, was durch ihre Verknüpfung mit dem Permutationsoperator "&" festgelegt wird.
  5. Danach (wegen der Verknüpfung mit dem Sequenz-Operator ",") muss eine Folge von einer oder mehreren birilis-Einträgen folgen. Folgen, die mindestens ein Element beinhalten, werden durch angehängtes "+" beschrieben.

Die erstgenannten Einträge ihrerseits sind definiert als "#chars", was bedeutet: Einfache Buchstabenfolgen ohne weitere innere Struktur. (Die birilis-Elemente werden erst später erklärt, in Abschnitt 3.4.3 ("Generierung der Bilanz-Druckvorlage ").)

Sowohl die Schlüsselworte dieses Format-Definitions-Formates "dd2", als auch die Schlüsselworte der BandM booking Dateien sind abgeleitet aus dem "Computer-Englisch". Die Bedien-Oberfläche des Programmes hingegen ist potentiell multi-lingual, wenn auch zZt. nur Deutsch unterstützt wird. Eine multi-linguale Definition der Schlüsselworte auf der Ebene der Datenkodierung wäre hingegen sehr aufwendig, und würde auch den Entwurfszielen von Transparenz und Nachvollziehbarkeit eher entgegenwirken.
Wir bitten also dieses Sprachengemisch als wohlbegründet zu akzeptieren.

^Inh 3.3.4 Kommentare in Daten

Wichtig für die Intention der Klarheit und Nachvollziehbarkeit sind die zwei verschiedenen Arten von Kommentaren.

Die aus verschiedenen Programmiersprachen bekannten Formen "//.." bis Zeilenende, und "/*...*/", auch über mehrere Zeilen, begrenzen Kommentare die nur im Quelltext zu sehen sind, nicht in der späteren Datenstruktur.

Hingegen haben viele Datendefinitionen explizit Felder mit Kommentar-Rolle, wie "comment" in fast allen größeren Objektdefinitionen von BandM booking, so dem Kontenplan als ganzem, jedem einzelnen Konto, bei jeder Buchung, etc.

Diese Kommentare sind Daten mit Kommentarfunktion und erscheinen evtl. auch in der verarbeitenden Software. Der Benutzer sollte reichlich Gebrauch besonders von letzteren machen, um wichtige außergewöhnliche Sachverhalte und Verwendungszusammenhänge deutlich mitzuteilen! (Wenn auch die comment-Einträge in den Beispielen etwas gesucht erscheinen sollten !-) Korrekturbuchungen verlangen sogar einen comment-Eintrag, um als gültig durch die Konsistenzkontrolle zu gehen.

Um zu sehen welche Einträge dezidierte Kommentar-Komponenten haben, suche man nach der Zeichenfolge "comment" in der Datenformatdefinitionsdatei eu_bandm_booking.dd2 oder siehe die Verweis-Liste im entsprechenden Eintrag der generierten Dokumentation oder auch die Verwendungs-Graphik am Beginn der generierten Dokumentation !

^Inh 3.3.5 Kontenplan

Der Kontenplan definiert alle in Buchungen möglichen Konten-Nummern, und definiert diese mit einer Klartext-Bezeichnung und einer Kontenklasse. Diese sind

  1. a = Aktiv-Konto
  2. p = Passiv-Konto
  3. k = Aufwands-Konto (von "K" wie "Kosten")
  4. kn = Aufwands-Konto, aber steuerlich *N*icht absetzbar
  5. e = Ertrags-Konto
  6. en = Ertrags-Konto, aber steuerfrei (z.B. Subventionen und Lottogewinne !-)
  7. (v = Übertrags-Konto, nur zum internen Gebrauch des Programmes, siehe unten Abschnitt 3.4.4 ("Generierung der Eröffnungsbuchungen"))

Darüber hinaus muss jedes Konto in Unterkonten aufgelöst werden, die wiederum nummeriert sind und eine Textbezeichnung tragen.
Diese Unter-Kontierung ist in unserem Ansatz deshalb zwingend vorgeschrieben, weil damit für die kleineren Unternehmungen, für die er ja gedacht ist, ein Element von "controlling" eingeführt wird. Dies ist zwar äusserst primitiv, wird aber in vielen Fällen bereits ausreichen, wenn z.B. "Reisekosten" nach Projekten oder aber nach Konferenzen oder aber nach Gesellschaftern weiter aufgeschlüsselt werden, etc.

(Zum Zwecke einer eindeutigen Sprachregelung reden wir im folgenden nur selten von "Konten", sondern entweder von "Kontengruppen" oder von "Unterkonten". Dabei entsprechen unsere Kontengruppen dem Namen und der Nummer nach dem, was z.B. der SKR-04 unter "Konto" versteht.)

Der Kontenplan wird für die Dauer eines Unternehmens beibehalten. Er wird höchstens monoton erweitert, niemals ausgedünnt oder existierende Einträge verändert, so daß auch die in den Buchungen vergangener Perioden auftretenden Konten immer noch im Kontenplan auffindbar sind.

Der Kontenplan und die ersten Buchungen müssen nun den Gründungsakt, das Stammkapital, die Einrichtung des Bankkontos, das Einzahlen des halben Anteils und das Schulden der restlichen Hälfte modellieren.

Zunächst zu den benötigten Konten. Orientiert am Kontenrahmen "DATEV SKR04" werden diese in der Kontenplan-Datei namens "kontenplan" definiert:

// Kontenplan der Sandsack GmbH

#d2d 2.0 text using eu_bandm_booking  : accountplan 

#comment 
Dies ist der Kontenplan aus dem Beispiel "Sandsack GmbH, Berlin" für
BandM booking. 

#frameName skr04 
// = dies ist die Bezeichnung des Standard-Kontenrahmens, an dem wir uns
// hier orientieren

// -------- SCHNIPP --------------------------
// HIER FEHLEN noch die Angaben der Konto-Nummer für einige Standard-Funktionen.
//   Diese sind hier weggelassen, weil sie erst weiter unten
//   beschrieben werden. Wegen dieser Lücke ist aber dieses Textbeispiel,
//   so wie es hier steht, nicht parsierbar.
//   Funktionsfähig ist hingegen die Datei "kontenplan" in den Beispiel-Daten.

#accountGroup    1  #title ausstehende Einlagen
                    #class a
     #account 1     #title Pick
     #account 2     #title Gotowohl


#accountGroup 1800  #title Bankkonten
                    #class a
     #account 1     #title Dresdner Stollenbank Girokonto 1234567890
     #account 2     #title Dresdner Stollenbank Festgeldkonto 0987654321

#accountGroup 2000  #title Stammkapital
                    #class p
     #account 1     #title gesamt 



#eof

Die Syntax für diese Definitionen ist, wie alle anderen, enthalten in d2d-Definitions-Datei "eu_bandm_booking.dd2" .

  chars digit = '0' .. '9'
  chars num  = @digit~+ 

  // -------- SCHNIPP --------------------------

  tags accountPlan  = (frameName & 
                       // SCHNIPP noch mehr Angaben nötig/möglich, s.u.
                      ), accountGroup*

  tags frameName = #chars
  tags accountGroup = #implict num, (title & class & comment?), account*
  tags account      = #implict num, (title & comment?)
  chars num = digit+
  tags title, comment = #chars
  enum class = a, p, e, en, k, kn, v

Das liest sich wie folgt:
Jeder "accountPlan" besteht aus genau einem "frameName", gefolgt von beliebig vielen "accountGroup" Elementen. (Es kann auch eine leere Folge von diesen sein, erkennbar an dem angehängten "*")
Ein "frameName" ist einfach eine beliebige Folge von Buchstaben ( "#chars"), der den Standard-Kontenrahmen bezeichnet, an dem der folgende Kontenplan vorgibt sich zu orientieren.

Eine "accountGroup" vergibt eine Gruppennummer, einen Titel und eine Kontenklasse. Ein Kommentar "comment" ist optional, und alle Bestandteile können in beliebiger Reihenfolge auftreten, --- bis auf die "num", die Nummer der Kontogruppe, die am Anfang steht. Deren "tag" (eigentlich "#num") ist als "implizit" deklariert, braucht also nicht, ja, darf also garnicht auftreten.

Dann folgen pro "accountGroup" beliebig viele "account"-Eintrage. Ein solcher steht für ein "Unter-Konto", und ist ähnlich aufgebaut: Er braucht ebenfalls Nummer und Bezeichung und kann einen Kommentar bekommen. Eine Kontenklasse braucht und kann hier nicht angegeben werden, da diese ja mit dem Ober-Konto, der accountGroup, schon verbindlich festgelegt ist.

"comment" ist bereits oben, für "config" definiert, und wird hier weiterverwendet..
"title" ist ebenfalls definiert als beliebige, nicht weiter spezifizierte Texte (Buchstabenfolgen).
Der Inhalt von "num" muss hingegen eine nichtleere Folge von Dezimalziffern sein, und der von "class" einer der Alternativen des angegebenen Enumerationstyps.

Die Angaben "num", "title" und "class" müssen in den jeweiligen Einträgen erscheinen. Hingegen ist "comment" beidemal optional, erkennbar wieder an dem angehängten Fragezeichen "?". Bis auf "num", das ja eh implizit am Anfang steht, können alle Bestandteile in beliebiger Reihenfolge erscheinen, weil sie im Definitionstext durch den Permutations-Operator "&" verbunden sind.

Die Konsistenzkontrolle beim Laden des Kontenplanes überprüft u.a., dass die Nummern für Kontengruppen nur einmal vergeben werden, ebenso die Nummern für Unterkonten je Kontengruppe.

Wie erwähnt darf ein Kontenplan immer nur monoton wachsend verändert werden. Dass dem so ist kann von BandM booking selber nicht überprüft werden, sondern obliegt der Protokollierung durch das für die Textdateien eingesetzte Versionskontrollsystem, s.o. Abschnitt 1.4 ("Eigenheiten von BandM booking. Notwendige Externe Programme ").

Man beachte dass zur Zeit alle Konten in Euro geführt werden müssen, s.a. Abschnitt 4.6 ("Mögliche weitere Ausbaustufen ").

^Inh 3.3.6 Format der Buchungssätze, eröffnende Buchungen

Nun können wir das Journal für das erste Geschäftsjahr beginnen, mit folgenden ersten Buchungen:

// Journal der Sandsack GmbH, ab Juli 2009 

#d2d 2.0 text using eu_bandm_booking : ledger 

#businessYear 09/10

#move 1
#date 01.07.2009  #text Stammeinlage Gotowohl, ausstehend
                  #voucher Gründungsprotokoll 
                  #from 1/2 #eur 12500.00 #to 2000/1 #rest 

#move 2
#date 01.07.2009  #text Stammeinlage Pick, ausstehend
                  #voucher Gründungsprotokoll 
                  #from 1/1 #eur 12500.00 #to 2000/1 #rest 

#move 3
#date 01.07.2009  #text Überweisung halbe Einlage Pick
                  #voucher Kontoauszug
                  #from 1800/1 #eur 6250.00 #to 1/1 #rest 

#move 4
#date 03.07.2009  #text Überweisung halbe Einlage Gotowohl
                  #voucher Kontoauszug
                  #comment Fängt ja GUT AN!! Die Bank von Herrn Gotowohl 
                           war leider etwas langsamer!
                  #from 1800/1 #eur 6250.00 #to 1/2 #rest 

#move 5
#date 03.07.2009  #text Anlage auf Festgeldkonto 
                  #voucher Kontoauszug
                  #from 1800/2 #eur 11000.00 #to 1800/1 #rest 

#eof

Die Syntaxdefinition für Buchungen ist, wie alle anderen, enthalten in d2d-Definitions-Datei "eu_bandm_booking.dd2" und lautet:

  tags ledger = businessYear, move*

  chars businessYear = digit~digit~("/"~digit~digit)?

  tags move = #implict num, (date & text & voucher & (CORR|REV)? & comment? ),
              from+, to+, (refAsset|newAsset)?

  chars date =  [day @num]~"."~[month @num]~"."~[year @num]
  tags text, voucher = #chars
  chars CORR, REV = @num

  tags from,to = #implicit accountCode, (eur|rest)
  chars accountCode = [framework @num]~"/"~[sub @num]
  chars eur = @num ~("."~digit~digit)?
  tags rest = #empty

Ein "ledger" gibt als erstes die Geschäftsperiode an, auf die es sich bezieht, dann eine Folge von "move"-Einträge, das sind die Buchungen.

Jedes "move" hat zunächst eine Nummer. Die Syntax für "num" ist, genau wie die für "comment", bereits oben definiert, da die Definitionen für "config", "accountplan" und "ledger" sich all diese Definitionen teilen. Das "tag" dieser Nummer (eigentlich "#num") ist wieder "implizit", d.h es taucht garnicht auf, sondern die Buchungsnummer folgt sofort auf das tag "#move" , welches die Buchung als ganze einleitet.

Dann müssen folgen "date", das Buchungsdatum (im angegebenen numerischen Format), "text", der Buchungstext, und "voucher", ein Verweis auf einen Beleg. Die letzten beiden sind wiedermal beliebige Texte. Ein "comment" kann hinzugefügt werden. Ein optionales "CORR"- oder "REV"-Element verweist qua Buchungsnummer auf eine ältere Buchung und bezeichnet die vorliegende Buchung als deren Korrekturbuchung.
(Bei einer Korrekturbuchung ist ein "comment"-Element zwingend notwendig, damit das Journal die Konsistenzkontrolle besteht. Diese Abhängigkeit kann aber nicht mehr sinnvollerweise durch eine Syntax-Definition ausgedrückt werden, s.u. Abschnitt 3.3.17 ("Dateisicherung, Radierungsverbot und Korrekturbuchungen ")).

Dann folgen als "from"-Element/e ein oder mehrere an der Buchung beteiligten Soll-Konten, und als "to"-Element/e die Haben-Konten.

Jedes dieser Elemente gibt zunächst das Konto an (Nummer der Kontogruppe, Schrägstrich, Nummer des Unterkontos, ohne Leerzeichen dawzischen!), und dann den beteligten Betrag.
Der Betrag muss einen Zahlenwert streng größer als Null haben. Er muss mit einem Dezimal-Punkt und zwei Nachkommastellen geschrieben werden. Ein Dezimalkomma oder eine andere Zahl von Nachkommastellen werden hingegen als Syntaxfehler zurückgewiesen.
Ein solcher Betrag kann derzeit nur in EURO angegeben werden.

Statt des Betrages kann an einer(1) Stelle auch das leere Element "#rest" stehen: Dies bewirkt, dass hier die Summe der Gegenseite minus der expliziten Beträge der eigenen Seite automatisch eingesetzt wird. Dies geht nur wenn diese Differenz positiv ist, ansonsten geschieht eine Fehlermeldung.
Ist kein "rest" Element vorhanden, dann müssen die Summen aller Beträge aus den "from" und den "to" Elementen gleich sein.
All diese Bedingungen sind Gegenstand der Konsistenzprüfung.

(Die abschliessend möglichen Syntaxbestandteile "newAsset" und "refAsset" werden weiter unten erklärt, im Zusammenhang mit Abschreibungen.)

Zurück zu unserem Beispiel:
Die Buchungen "1" und "2" sind typische "Eröffnungs-Buchungen" und gleichzeitig "Bilanz-Verlängerungen". Sie modellieren den Vertrag zum Unternehmen.
Nach ihrer Durchführung haben sich ein Aktiv- und ein Passiv-Konto mit einigem Bestand, einem Saldo ungleich Null, gefüllt.

Das wiederspiegelt die rechtliche Realität: Mit dem Vertrag zum Unternehmen schulden beide Gründer diesem ihren Anteil. Das Unternehmen hat ihnen diesen bis zur Begleichung ersteinmal "geliehen". Dies ist eine Mittel-Verwendung durch das Unternehmen, und repräsentiert sich durch das Aktiv-Konto.

Andererseits aber gehört das Unternehmen den Gründern, und das Stammkapital haben diese zur Verfügung gestellt, womit das Unternehmen ihr Eigentum ist. Dies wird repräsentiert durch das entsprechende Passiv-Konto.

Zwar ist die Situation hier noch symmetrisch und ausgeglichen, die Modellierung mittels Konten also trivial und scheint über-kompliziert, das wird aber im veiteren Verlauf des Unternehmens (hoffentlich !-) nicht so bleiben!

^Inh 3.3.7 Vergabe der Buchungsnummern und Konsistenzprüfungen

Die Buchungsnummern müssen für BandM booking jahresübergreifend eindeutig (also jede Nummer nur einmalig), aufsteigend und lückenlos vergeben werden.

Die Applikation BandM booking bearbeitet zwar (wie alle ähnlichen marktüblichen Programme) in jeder Instantiierung der Applikation jeweils nur ein(1) einziges, vorher angegebenens Geschäftsjahr (s.u., Abschnitt 4.2 ("Bedienung der Programmes ")).

Innerhalb eines Geschäftsjahres müssen die vom Benutzer explizit eingegebenen Buchungen mit lückenlos ansteigenden Nummern versehen werden. Ein Verstoß dagegen wird als Fehler behandelt und die Verarbeitung der Daten abgelehnt.

Gleichermaßen wird überprüft dass die Kalenderdaten der Buchungen (1) monoton ansteigen und (2) innerhalb des Geschäftsjahres liegen.

Beim Jahresabschluss erzeugt das Programm Abschlussbuchungen, deren Nummern automatisch und lückenlos an die explizit eingetragenen Buchungen anschliessen.

Da für das nächste Jahr ebenfalls automatisch Eröffnungsbuchungen erzeugt werden, und es bei eventuellen Änderungen der Abschluss-Regeln da noch Veränderungen stattfinden, man aber vor dem Jahresabschluss oft schon weiterbuchen will, empfiehlt es sich, mit den Nummern der auf die Eröffnungsbuchungen folgenden expliziten Buchungen auf den Anfang einer neuen Tausender-Gruppe o.ä. zu springen. Dieser Punkt ist der einzige, wo eine Lücke in den Buchungsnummern nur zu einer Warnung und nicht zu einem Fehler führt.

^Inh 3.3.8 T-Konten-Blätter

In der typischen historischen papier-basierten Form der Doppelten Buchführung waren zentral neben dem Journal, welches alle Buchungen in ihrer zeitlichen Reihenfolge beinhaltet, die sogenannten "Kontenblätter", welche alle Buchungen aufführen, an denen ein bestimmtes Konto beteiligt ist. Diese wurden klassischerweise als sogenannte "T-Konten" formatiert, welche Bezeichnung sich durch die Graphik der Trennlinie zwischen Soll- und Haben-Seite, in Verbindung mit der Titelzeile ergibt.

Unsere Software BandM booking erzeugt eine ähnliche Darstellung zwecks Informierung des Benutzers über den aktuellen Zustand eines gegebenen Kontos.

Betrachten wir die nach den ersten zwei Buchungen sich ergebenden T-Konten-Blätter, unter Berücksichtigung der oben gewählten Auflösung nach Unterkonten:

   2000/1 Stammkapital/gesamt  (p) Haben-Saldo = 25000
                 -----------+------------
   1  01.07.2009            |     12500.00 (1/1) Stammeinlage Gotowohl, ausstehend
   2  01.07.2009            |     12500.00 (1/2) Stammeinlage Pick, ausstehend
                            |
// |  |           |              |         |     |
// |  |           |              |         |     Buchungstext
// |  |           |              |         Gegenkonto/-konten
// |  |           |              Betragsauswirkung im Haben
// |  |           Buchungsauswirkung im Soll
// |  Datum der Buchung
// Buchungsnummer                                


  1/1 ausstehende Einlagen/Gotowohl (a) Soll-Saldo = 12500.00
                 -----------+------------
   1  01.07.2009   12500.00 |              (2000/1) Stammeinlage Gotowohl, ausstehend

  1/2 ausstehende Einlagen/Pick (a) Soll-Saldo = 12500.00
                 -----------+------------
   2  01.07.2009   12500.00 |              (2000/1) Stammeinlage Gotowohl, ausstehend

Der Gesetzgeber geht erstmal davon aus, dass alle Menschen und Institutionen auch brav ihre Schulden bezahlen!
Folglich ist es für die Bilanz völlig egal, ob das Geld dem Herrn Pick geliehen wird oder der Bank. Das sind beides erlaubte Arten der "Mittelverwendung", und die Mittel sind ja in beiden Fällen weiterhin im Eigentum des Unternehmens. Zur Zeit schuldet der Herr Pick seinen gesamten Geschäftsanteil der GmbH.
Nach der Buchung "3" hat er die Hälfte davon auf deren Bankkonto überwiesen, und nun schulden die Bank und er jeweils die Hälfte. Die Kontenblätter sehen aus wie folgt:

  1/2 ausstehende Einlagen/Pick (a) Soll-Saldo = 6250
                 -----------+------------
   2  01.07.2009   12500.00 |              (2000/1) Stammeinlage Pick, ausstehend
   3  01.07.2009            |      6250.00 (1800/1) Überweisung halbe Einlage Pick


  1800/1 Dresdner Stollenbank Girokonto (a) Soll-Saldo = 6250
                 -----------+------------
   3  01.07.2009    6250.00 |              (1/2)    Überweisung halbe Einlage Pick

Dies ist ein "Aktiv-Aktiv-Tausch", der an der Bilanzsumme und der wirtschaftlichen Situation des Modelles aber auch garnix ändert! Herr Pick hätte seinen Anteil auch in Form von Briefmarken in die Portokasse geben können, das wäre zwar unpraktisch, aber hätte denselben bilanziellen Effekt, nämlich garkeinen.

Die Sprechweise für das Verhältnis der an "Buchung 3" beteiligten Konten heißt "Bankkonto an ausstehende Einlagen".
Man kann hieran sehr schön sehen, dass dieses Wort "an" hier nur ein syntaktischer Trenner ist, ohne direkte semantische Implikation (so ähnlich wie "Fahrgäste Richtung Ruhleben bitte umsteigen auf Hallesches Tor!"). Der Mittelfluß geht ja hier umgekehrt, "von" Herrn Pick "an" das Bankkonto!

^Inh 3.3.9 Erste Kosten

Sofort aber entstehen erste Kosten! So läßt der Notar es sich nicht nehmen, umgehend eine Rechnung für die Errichtung des Unternehmens zu stellen. Noch ehe die Eintragung beim Registergericht "durch" ist, und noch ehe wir Geld vom Girokonto abheben können! Ausserdem halten IHK, die Bank, das Gericht selbst, etc. die Hand auf!

Aber da wir Rechnungen in den wenigsten Fällen mit Rechnungsdatum bezahlen können (zumindest ist meist der Postweg dazwischen!) brauchen wir neben dem eigentlichen Aufwands-Konto eh noch die Kreditoren-Konten!

Der entsprechend erweiterte Kontenplan sieht so aus, wobei sich nun deutlich die Vorteile unserer Unterkonten zeigen:

// Kontenplan der Sandsack GmbH

#d2d 2.0 text using eu_bandm_booking : accountplan 
#frameName skr04 

// alles wie oben bleibt!

#accountGroup 1406  #title Abziehbare Vorsteuer
                    #class a
     #account 1 #title  Vorsteuer 19%
     #account 2 #title  Vorsteuer  7%


#accountGroup 3300  #title Verbindlichkeiten aus Lieferungen und Leistungen 
                    #class p

     #account 1 #title Notariat L.E.Gant
     #account 2 #title IHK-Industrie und Handelskammer
     #account 3 #title Registergericht 


#accountGroup 6825  #title Rechts- und Beratungskosten
                    #class k
     #account 1 #title Gründungskosten

#accountGroup 6855  #title Sonstige Kosten des Geldverkehrs
                    #class k
     #account 1 #title Dresdner Stollenbank Kontoführungsgebühren für Girokonto 1800/1

#eof

Die erwähnten Kosten äussern sich in Buchungen wie folgt:

// -------- SCHNIPP --------------------------

#move 6
#date 03.07.2009  #text Notariatskosten Errichtung und Eintragung
                  #voucher fremde Rechnung Nr 2009001734
                  #from 6825/1    #eur 464.30 
                  #from 1406/1    #eur  88.22
                                                #to 3300/1 #rest

#move 7
#date 07.07.2009  #text IHK Kosten des Eintrags
                  #voucher fremde Rechnung Nr 743 598 983 886
                  #comment Darauf ist KEINE Mehrwertsteuer!
                  #from 6825/1    #eur 15.00   #to 3300/2   #rest

#move 8
#date 10.07.2009  #text Registergericht, Kosten des Eintrages und der Kopien
                  #voucher telefonnotiz, ueberweisung
                  #comment Rechnung nie eingetroffen, telefonisch geklärt!
                           Mit Frau REDLICH, 9.7.2009.
                           Angeblich KEINE MWSt!
                  #from 6825/1    #eur 170.00   #to 3300/3   #rest

// -------- SCHNIPP --------------------------

Die Konten(oder besser: "Kontengruppen") "6825" und "6855" sind unsere ersten Aufwandskonten, mit der Klasse "k" als Kennzeichen für "K"osten..

Konzeptionell ist ein Aufwandskonto als solches nichts anderes als ein Unterkonto des Eigenkapitalkontos, wie oben beschrieben.
Das Eigenkapital als Passiv-Posten steht in der Bilanz, auf der obersten Ebene, ja auf der rechten Seite, im Haben.
Alle Aufwendungen werden deshalb logischerweise auf der linken Seite, im Soll, gebucht, weil sie ja das Eigenkapital vermindern.

Die Konten der Gruppe "3300" sind Kreditoren-Konten, also Lieferanten, denen wird noch die Bezahlung schuldig sind.
Dies sind Passiv-Konten, denn ihr Saldo (der immer ein Haben-Saldo ist) bedeutet eine Mittel-Herkunft: Die Kreditoren haben uns Geld geliehen, weil wir ihre Rechnung (für erhaltene Leistungen) noch nicht bezahlt haben.

Diese Rechnung wird also verbucht mit ihrem eigenen Datum mit einem Buchungssatz "Aufwandskonto an Kreditorenkonto", wie in den Buchungen in vorangehendem Auszug.

Rein bilanztechnisch sind das alles nur Passiv-Passiv-Täusche: Statt Eigenkapital steckt nun geliehenes Geld (geschuldetes) im Besitz des Unternehmens. Steuerlich jedoch ist das relevant, da ja gerade die Entwicklung des Eigenkapitals besteuert wird, das hier ja gesunken ist.

Erst später, wenn die Rechnungen bezahlt werden, verschwinden die Schulden beim Kreditor, dafür vermindert sich aber der Aktiv-Posten unseres Bankkontos. Die Buchungssätze heißen dann "Kreditor an Bankkonto". Das Passiv-Konto "Kreditor" erhält wieder den Saldo gleich Null, wird im Soll gebucht, das Bankkonto wird im Haben gebucht, und als Aktiv-Konto (dessen Aktiv-Posten ja links, im Soll, steht!) vermindert es seinen Bestand. Dies ist dann eine tatsächliche Bilanz-Verkürzung.

// -------- SCHNIPP --------------------------

#move 9
#date 17.07.2009  #text Begleichung Rechnung Notar (Buchung 5)
                  #voucher Kontoauszug
                  #from 3300/1 #eur 552.52  #to 1800/1 #rest 

#move 10
#date 17.07.2009  #text Begleichung Rechnung IHK  (Buchung 6)
                  #voucher Kontoauszug
                  #from 3300/2 #eur 15.00   #to 1800/1 #rest 

#move 11
#date 17.07.2009  #text Begleichung Rechnung Registergericht (Buchung 7)
                  #voucher Kontoauszug
                  #from 3300/3 #eur 1170.00  #to 1800/1 #rest 


// -------- SCHNIPP --------------------------

Als Beispiel für ein Kreditoren-Kontenblatt betrachen wird die IHK:

  6825/1 Rechts- und Beratungskosten / Gründungskosten (k) Saldo = 649.30
                 ------------+------------
  6  03.07.2009       464.30 |             (3300/1) Notariatskosten Erricht..
  7  07.07.2009        15.00 |             (3300/2) IHK Kosten des Eintrags
  8  10.07.2009       170.00 |             (3300/3) Registergericht, Kosten de


  3300/2 Verbindlichkeiten aus Lieferungen und Leistungen/IHK (p) Saldo = 0 
                 ------------+------------
  7  07.07.2009              |   15.00     (6825/1) IHK Kosten des Eintrags
 10  17.07.2009        15.00 |             (1800/1) Begleichung Rechnung IHK (Bu 6)


  1800/1 Dresdner Stollenbank Girokonto (a) Saldo = 932.48 
                 ------------+------------
  3  01.07.2009      6250.00 |             (1/2) Überweisung halbe Einlage Pick
  4  03.07.2009      6250.00 |             (1/1) Überweisung halbe Einlage Gotowohl
  5  03.07.2009              | 11000.00    (1800/2) Anlage auf Festgeldkonto
  9  17.07.2009              |   552.52    (3300/1) Begleichung Rechnung Notar (Bu 5)
 10  17.07.2009              |    15.00    (3300/2) Begleichung Rechnung IHK (Bu 6)

Wir erkennen, dass im Endeffekt eine Buchung wie "Aufwandskonto 6825/1 an Bankkonto 1800/1" herauskommt. Diese musste aber in zwei Schritte zerlegt werden, weil wir ja in der Tat dem Lieferanten für einige Zeit, nämlich seit der Rechnungsstellung, die Bezahlung schuldig waren.

Im praktischen Gebrauch der Software können wir immer wenn ein neuer Kreditor dazukommt im Kontenplan ein neues Unterkonto der Gruppe 3300 anlegen, da der Kontenplan ja problemlos erweiterbar ist.

In manchen Fällen kann allerdings auch eine direkte Verbuchung stattfinden. Die "Dresdner Stollenbank" als Lieferant der finanztechnischen Dienstleistung "Girokonto" verlangt eine solche eh, da sie ihre Bezahlung ohne zu fragen direkt vom Bestand eben dieses Girokontos abzieht. Dem entspricht die folgende Buchung 12, vom direkten Typ, ohne zwischengeschaltetes Kreditorenkonto, direkt "Aufwandskonto an Bankkonto".

Die erwähnten Kosten äussern sich in Buchungen wie folgt:

// -------- SCHNIPP --------------------------
#move 12
#date 31.07.2009  #text Kontogebühren Girokonto 1800/1
                  #voucher kontoauszug
                  #from 6855/1  #eur 4.30    #to 1800/1    #rest

// -------- SCHNIPP --------------------------

^Inh 3.3.10 Geleistete Vorsteuer

Eine weitere, sehr wichtige Variante zeigt Buchung 6. In der Rechnung des Notariats ist nämlich, im Gegensatz zu IHK, Registergericht, u.s.w. Umsatzsteuer enthalten.

Buchung 6 ist also unsere erste Splitbuchung. Den Rechnungsbetrag schulden wir weiterhin dem Kreditor, also ändert sich nichts an der Haben-Seite der Buchung.

Links jedoch ist nur der Netto-Betrag, ohne die Umsatzsteuer, als Aufwand auf dem Aufwandskonto zu buchen.

Der als Mehrwertsteuer angegebenen Anteil wird hingegen auf das Konto "1406", geleistete Vorsteuer, gebucht. Dies ist ein Aktiv-Konto, denn das Geld das wir gezahlt haben, haben wir dem Finanzamt geliehen (Hört, hört !-)

Nach Abgabe der Umsatzsteuervoranmeldung bekommen wird das auch in der Tat in kürzester Zeit zurück! Das ist dann ein Aktiv-Aktiv-Tausch, denn statt dem Finanzamt schuldet uns danach die Bank das Geld. Diese Erstattung ist meist nur aus dem Auszug des Bankkontos zu ersehen, weil das Finanzamt oft keine eigenen Bescheide verschickt, und der Buchungssatz und die Kontenblätter heißen dann ...

// -------- SCHNIPP --------------------------

#move 13
#date 02.08.2009  #text Erstattung Vorsteuer durch FA
                  #voucher Kontoauszug
                  #from 1800/1  #rest  #to  1406/1    #eur  88.22

// -------- SCHNIPP --------------------------

  1406/1 Abziehbare Vorsteuer/19%  (a) Saldo = 0 
                 ------------+------------
  5 03.07.2009         88.22 |            (3300/1) Notariatskosten Errichtung u...
 13 02.08.2009               |      88.22 (1800/1) Erstattung Vorsteuer durch FA


  1800/1 Dresdner Stollenbank Girokonto (a) Soll-Saldo = ....
                 ------------+------------
                            ...
 13 02.08.2009         88.22 |            (1406/1) Erstattung Vorsteuer durch FA

^Inh 3.3.11 Erträge

Glücklicherweise hat die GmbH aber bald schon einen Auftrag, und kann für Beratungsdienste im Bereich "Propaganda und Staatssicherheit" ein fettes Honorar einfordern.
Natürlich ebenfalls mit Mehrwertsteuer.
Da der Kunde, genau wie das Unternehmen selbst, schon rein technisch nicht sofort zahlen kann, wird er als Debitor modelliert, und der Ertrag mit Rechnungsstellung auf ein Ertragskonto verbucht.

Zunächst die benötigten Konten:

// Kontenplan der Sandsack GmbH
// -------- SCHNIPP --------------------------

#accountGroup 1200  #title Forderungen aus Lieferungen und Leistungen 
                    #class a
     #account 1 #title Wasserfall GmbH 
     #account 2 #title Heidewind AG

#accountGroup 3806  #title geschuldete USt
                    #class p
     #account 1 #title USt 19%


#accountGroup 4400  #title Erlöse aus steuerpfltg. Leistungen
                    #class e
     #account 1 #title Projekt Wasserfall GmbH, Beratung Umweltschutz, Sommer 09

// -------- SCHNIPP --------------------------

Der Ablauf ist genau spiegelsymmetrisch zum Fall des Aufwandes:

// -------- SCHNIPP --------------------------

#move 14
#date 08.08.2009  #text Projekt Wasserfall/Umweltberatung/Erste Tranche
                  #voucher Eigene Re 09080801 
                  #from 1200/1    #rest    #to 4400/1  #eur 12000.00
                                           #to 3806/1  #eur  2280.00 

#move 15
#date 18.08.2009  #text Bezahlung durch Wasserfall, Re 09080801 
                  #voucher Kontoauszug
                  #from 1800/1    #rest    #to 1200/1  #eur 14280.00

#move 16
#date 19.08.2009  #text USt an Finanzamt 
                  #voucher Kotoauszug
                  #from 3806/1  #eur  2280.00 #to 1800/1    #rest 

// -------- SCHNIPP --------------------------

Buchung 14 modelliert die Rechnungsstellung an den Kunden: Dieser hat ein Debitorenkonto (1200/1). Dieses ist ein Aktiv-Konto, denn wir haben ihm ja unser Geld geliehen.
Die Buchung geht von diesem Debitoren-Konto "an" das Ertragskonto 4400/1 und an Konto 3806/1. Letzteres heißt "geschuldete Umsatzsteuer / 19 %", es ist ein Passiv-Konto, denn die Umsatz-Steuer, die der Kunde an uns bezahlt (/bezahlen soll/bezahlen wird), haben wir nur vom Finanzamt geliehen und schulden diesem. Beides zusammen verursacht eine Bilanzverlängerung.

Dann überweist der Kunde den Rechnungsbetrag. Dem entspricht Buchung 15, "Bank an Debitor", nach der der Kunde uns nichts mehr schuldet, dafür die Bank entsprechend mehr. Dies ist lediglich ein Aktiv-Aktiv-Tausch.

Kurz danach (nicht etwa früher, weil wir ja geschickterweise "Ist-Besteuerung" beantragt haben!) können wir dem Finanzamt die geschuldete USt überweisen, worauf das Passiv-Konto 3806/1 wieder "leer" ist, aber das Bankkonto auch entsprechend schrumpft. Dies ist also eine (leichte) Bilanzverkürzung.

^Inh 3.3.12 Angestellte

Angestellte sind kompliziert! Sie verursachen nicht nur Kosten, sondern auch viel Verbuchungsaufwand.

Die Sandsack GmbH stellte einmal für ein paar Stunden eine Hilfskraft zum Einräumen ihrer Akten und Anschluss und Konfigurierung ihrer Büromaschinen ein. Die Abrechnung erfolgte als "geringfügige Tätigkeit ohne Steuerkarte" und Steuern und Versicherungen wurden mit der "Bundesknappschaft" abgerechnet.

(Das Verfahren kann sich aber jedes halbe Jahr wieder ändern, also können die folgenden Konten und Buchungen nur als gröbste Orientierung dienen. Man frage allemal beim Arbeitsamt nach, sonst steht man als Unternehmer schon halb im Gefängnis!)

// Kontenplan der Sandsack GmbH
// -------- SCHNIPP --------------------------

#accountGroup 6000  #title Löhne und Gehälter
                    #class k
     #account 1 #title Herr Martin Schlepper 

#accountGroup 6040  #title Lohnsteuer/vom Unternehmen getragen
                    #class k
     #account 1 #title für gerinfügig Beschäftigte

#accountGroup 6110  #title Gesetzliche Soziale Aufwendungen 
                    #class k
     #account 1 #title KV gerinfügig Beschäftigte
     #account 2 #title RV gerinfügig Beschäftigte
     #account 3 #title Umlage U1 
     #account 4 #title Umlage U2
     #account 5 #title Umlage Insolvenz

#accountGroup 6650  #title Reisekosten Angestellter
                    #class k
     #account 1 #title Herr Martin Schlepper

// -------- SCHNIPP --------------------------

#move 17
#date 30.08.2009  #text Sozialabgaben Hr. Martin Schlepper / September 
                  #voucher Berechnung durch Internet-Seite Bundesknappschaft
                  #from 6110/1   #eur  23.40 
                  #from 6110/2   #eur  27.00
                  #from 6110/3   #eur   1.08
                  #from 6110/4   #eur   0.13
                  #from 6110/5   #eur   0.18 
                  #from 6040/1   #eur   3.60  #to 1800/1 #rest

#move 18
#date 30.08.2009  #text Gehalt geringfügige Besch. M. Schlepper / September
                  #voucher kontoauszug
                  #from 6000/1  #eur 180.00   #to 1800/1    #rest

#move 19
#date 30.08.2009  #text fahrtkostenzuschuss Hr. Schlepper / September 
                  #voucher Quittung
                  #from 6650/1 #eur 20.00      #to 1800/1  #rest

^Inh 3.3.13 Reisen und Speisen

Wenn wir schonmal bei Reisekosten sind: Die hat natürlich auch der Unternehmer.

Das sind einmal die Fahrtkosten und Übernachtungskosten, in der tatsächlichen Höhe. (Die dabei gezahlte Mehrwertsteuer ist wie bei allen anderen Ausgaben als Vorsteuer erstattungsfähig.)

Daneben kann an den Reisenden der Verpflegungs-Mehraufwand nach Bundesreisekostengesetz ausgezahlt werden.

Das alles läßt sich darstellen wie folgt:

// Kontenplan der Sandsack GmbH
// -------- SCHNIPP --------------------------

#accountGroup 6673  #title Reisekosten Unternehmer Fahrtkosten 
                    #class k
     #account 1 #title Dipl.-Ing. Pick, Deutsche Bahn
     #account 2 #title Dipl.-Ing. Pick, Lufthansa
     #account 3 #title Dipl.-Ing. Pick, Taxi
     #account 4 #title Dipl.-Ing. Pick, ÖPNV

#accountGroup 6674  #title Reisekosten Unternehmer Verpflegungsmehraufwand
                    #class k
     #account 1 #title Prof. Dr. Gotowohl
     #account 2 #title Dipl.-Ing. Pick, 

#accountGroup 6680  #title Reisekosten Unternehmer Übernachtungen
                    #class k
     #account 1 #title Prof. Dr. Gotowohl
     #account 2 #title Dipl.-Ing. Pick, 

// -------- SCHNIPP --------------------------

#move 20
#date 24.09.2009  #text Reise Herr Pick, Bahnfahrt München nach Fürth
                  #voucher fremde Rechnung 09078858998949XX3433XX789884577884XX78745
                  #from 6673/1    #eur 39.50
                  #from 1406/1    #eur  7.50   #to 1800/1 #rest

// -------- SCHNIPP --------------------------
//  hier haben wir aus Darstellungsgründen die Buchungen der übrigen 
//     Transportkosten weggelassen. Diese werden ähnlich wie Buchung 19 aussehen.
// -------- SCHNIPP --------------------------

#move 21
#date 25.09.2009  #text Reise Herr Pick, Hotel "Nebelkrähe" in Fürth
                  #voucher fremde Rechnung Re 0089 7546
                  #from 6680/2    #eur 54.62
                  #from 1406/1    #eur 10.38   #to 1800/1 #rest
// damals galt noch nicht die FDP-Sondersteuervergünstigung!


// -------- SCHNIPP --------------------------

#move 22
#date 27.09.2009  #text Reise Herr Pick, Verpflegungsmehraufwand für Gesamtdauer
                  #voucher Eigenbeleg
#comment
Der Verpflegungsmehraufwand lt. Bundesreisekostengesetz beträgt
Fr 23.10   12 EUR 
Sa 24.10   24 EUR 
So 25.10   24 EUR 
Mo 26.10   24 EUR 
Di 27.10   12 EUR 
-------------------
Summe      96 EUR
#/comment
                  #from 6674/2    #eur  96.00    #to 1800/1  #rest


Bei Geschäftsessen ist der Netto-Betrag aufzuteilen: Rein wirtschaftlich gilt der gesamte Aufwand als Betriebsausgabe, das Geld ist ja danach auch weck!
Steuerlich aber sind nur siebzig Prozent als eine solche anrechenbar. Die restlichen dreißig Prozent gehen in die sog. "Hinzurechnung" ein. Dabei werden ganz am Ende, nach Ermittlung von "wirtschaftlichem" Gewinn oder Verlust, bestimmte Beträge, die steuerlich halt nicht als Ausgaben anerkannt werden, zwecks Ermittlung der Besteuerungsgrundlage wieder dazugerechnet. So also auch die dreißig Prozent der Restaurationskosten, die also von Beginn an auf einem anderen Konto verbucht werden. Dessen Kontengruppe hat die Klasse "kn", wird also wirtschaftlich als "Kosten"-Konto geführt, ist aber *N*icht absetzbar.

Andererseits können aber auch (wenige!-) Arten von Einnahmen mit negativem Vorzeichen hinzugerechnet werden, z.B. staatliche Subventionen, Lottegewinne, etc. Für diese gibt es entsprechend die Konten-Klasse "en".

Die gezahlte Mehrwertsteuer ist davon unabhängig zur Gänze als Vorsteuer zu behandeln und erstattungsfähig, wie bei allen anderen Ausgaben.

Wenn ein sehr kleines Unternehmen über keine eigene Bar-Kasse verfügt, kann ein Unternehmer für derartige Bagatellbeträge einspringen. Danach schuldet das Unternehmen ihm die Erstattung.

Das alles läßt sich darstellen wie folgt:

// Kontenplan der Sandsack GmbH

#accountGroup 3340  #title Verbindlichkeiten gegenüber Gesellschaftern
                    #class p
     #account 1 #title Prof. Dr. Gotowohl
     #account 2 #title Dipl.-Ing. Pick


#accountGroup 6640  #title Bewirtungskosten abzugsfähig
                    #class k
     #account 1 #title Prof. Dr. Gotowohl
     #account 2 #title Dipl.-Ing. Pick

#accountGroup 6643  #title Aufmerksamkeiten
                    #class k
     #account 1 #title Prof. Dr. Gotowohl
     #account 2 #title Dipl.-Ing. Pick

#accountGroup 6644  #title Bewirtungskosten NICHT abzugsfähig
                    #class kn
     #account 1 #title Prof. Dr. Gotowohl
     #account 2 #title Dipl.-Ing. Pick


#move 23
#date 25.09.2009  #text Herr Pick, Geschäftsessen mit Herrn Dr. Zunder und Gattin
                  #voucher fremde Rechnung
                  #from 6640/2    #eur 65.67
                  #from 6644/2    #eur 28.14
                  #from 1406/1    #eur 16.19   #to 3340/2 #rest

#move 24
#date 25.09.2009  #text Rose vom fliegendem Händler für Gattin Dr. Zunder
                  #voucher Eigenbeleg
                  #from 6643/2    #eur  5.00   #to 3340/2 #rest


Derartig ausgelegte Betriebsausgaben sollte man sich aber zeitnah wieder erstatten lassen! Es ist immer gut, verschiedene Kassen getrennt zu halten. Sobald daheim, wird Herr Dipl.-Ing. Pick sich das Geld zurücküberweisen. Dem entspricht folgende Buchung:

#move 25
#date 30.09.2009  #text Erstattung der ausgelegten Betriebsausgaben Pick (Bu 22,23)
                  #voucher Eigenbeleg
                  #from 3340/2 #euro 115.00  #to 1800/1 #rest 

Obwohl uns selber sowas nie widerfuhr, soll es ja Leute geben die zu diesem unserem Staate gute Beziehungen haben, und einige Millionen an Subventionen kassieren. Wir können sowas nicht, aber unser Herr Pick hat gute Verbindungen, und kassiert einen kleinen Zuschuss aus einem Bundes-Programm. (Dies allerdings nur, um das Verhalten der "en"-Kontenklasse bei Jahresabschluss demonstrieren zu können!-)

#accountGroup 4975  #title Subventionen 
                    #class en
     #account 1 #title Gründungszuschuss
#comment Großzügige steuerfreie Zuwendung aus dem Programm "Aufbau Voraus!"

// -------- SCHNIPP --------------------------

#move 26
#date 30.09.2009  #text Zuschuss aus dem Gründungsprogramm "Aufbau Voraus".
#comment Wegen der guten Kontakte von Herrn Pick zum Ministerium.
                  #voucher Förderbescheid vom 13.08
                  #from 1800/1  #eur 7500.00  #to 4975/1 #rest 

^Inh 3.3.14 Rechnungsabgrenzung

Die Gesellschafter beschliessen im August 09, zum ersten Oktober eine Rechtsschutz-Versicherung abzuschliessen. Die Jahresprämie wird ab nun immer zu diesem Jahrestag fällig. Allerdings bedeutet die Gesamtsumme mitnichten zur Gänze einen Aufwand für das aktuelle Wirtschaftsjahr. Dies sind vielmehr nur 9/12 davon, die also auf das entsprechende Aufwandskonto gebucht werden.

Die restlichen 3/12 sind zwar jetzt schon bezahlt, bedeuten aber einer Aufwand erst für das folgende Rechnungsjahr (ab 1. Juli nächsten Jahres). In diesem Jahr werden sie bilanz-technisch (und steuerlich!) ausgeglichen durch das Recht auf die zukünftige Leistung, die die sandsack GmbH bei dem Versicherer für das Anfangsintervall des folgende Wirtschaftsjahres hat. Deshalb werden sie wie auf ein "aktives Rechnungsabgrenzungskonto" ("ARA-Konto") verbucht, wie oben im allgemeinen Teil bereits beschrieben.

Die relevanten Ausschnitte aus dem Kontenplan lauten ...

#accountGroup 1900  #title Aktive Rechnungsabgrenzung
                    #class a
     #account 1     #title Aralag-Rechtsschutz
     #account 2     #title diverse Versicherungen
     #account 3     #title diverse Jahresgebühren

//... 

// dies ist das (temporaere) Kreditorenkonto:
#accountGroup 3300  #title Verbindlichkeiten aus Lieferungen und Leistungen 
                    #class p
     //...
     #account 9 #title aralag-Rechtschutz
     //...

//...

// dies ist ein echtes Aufwandskonto:
#accountGroup 6400  #title Versicherungen
                    #class k
     #account 1 #title Aralag-Rechtsschutz
     #account 2 #title Auslands Reise Versicherung


Die entsprechenden Buchungen in diesem Jahr sind ...

#move 27
#date 01.10.2009  #text rechtsschutzversicherung Aralag Schein 1234567
                  #voucher fremde Rechnung
                  #from 6400/1   #eur 375.00
                  #from 1900/1   #eur 125.00    #to 3300/9  #eur 500.00

#move 28
#date 05.10.2009  #text Bezahlung Re Aralag (Buchung 25)
                  #voucher kontoauszug
                  #from 3300/9   #eur 500.00    #to 1800/1    #rest

Eine der allerersten Buchungen zu Beginn des nächsten Geschäftsjahres wird sein, dieses "Guthaben bei der Versicherung" umzubuchen in einen Aufwand. Denn die Prämie ist ja komplett gezahlt worden und musste vertraglich bezahlt werden. In Geschäftsjahr 2009 war aber ein Drittel davon eine Art "Guthaben" bei der Versicherung und kann erst ab Beginn 2010 als "Aufwand" betrachtet werden:

//...

#move 1001
#date 01.07.2010  #text ARA Auflösung Rechtsschutzversicherung
                  #voucher siehe Buchung 27 a.d. Vorjahr
                  #from 6400/1   #rest   #to  1900/1   #eur 125.00  

Man beachte dass derartige Buchungen in der jetzigen Ausbaustufe von BandM booking explizit und händisch durchgeführt werden müssen, obwohl sich eine Automatisierung einfach vorstellen läßt.


Umgekehrt verläuft die passive Rechnungsabgrenzung (PRA): Wenn wir Geld einnehmen für eine Leistung, die (teilweise) erst im nächsten Wirtschaftsjahr erbracht wird, so ist der entsprechende Anteil der Einnahmen "vom Kunden geliehen". Der eingenommene Betrag wird durch unsere Verpflichtung zur Leistung neutralisiert, die auf dem Passiv-Konto "Passive Rechnungsabgrenzung" als geliehener Betrag verbucht wird, und erst im nächsten Wirtschaftsjahr als Ertrag verbucht.

Nehmen wir an o.e. Kunde war zufrieden, erteilt einen neuen Auftrag und zahlt (um die folgende Darstellung einfacher zu machen) komplett im voraus, dann stellen sich die entsprechenden Konten und Buchungen (unter Auslassung der eingentlichen Bezahlvorgänge) dar wie folgt:

#accountGroup 3900  #title Passive Rechnungsabgrenzung
                    #class p
     //...
     #account 3     #title Beratungsaufträge von Wasserfall Energie
     //...

// -------- SCHNIPP --------------------------

#move 29
#date 16.10.2009  #text Beratung Wasservall GmbH für das Jahr 2010
                  #voucher unsere Rechnung
                  #from 1200/1  #rest  // Debitorenkonto=Forderung
                                     #to 3806/1 #eur  3800.00    // USt
                                     #to 4400/1 #eur 10000.00    // Ertrag
                                     #to 3900/3 #eur 10000.00    // PRA

Gleich mit Beginn des nächsten Geschäftsjahres kann dann der Ertrag als solcher verbucht werden, genau umgekehrt wie mit der "aktiven" RA. Man beachte: Das Passiv-Konto "PRA" ist ein Passiv-Konto neben dem Eigenkapital. Das hat den Effekt, dass die zweite Hälfte des eingenommenen Geldes im obigen Beispiel im Jahren 2009 noch nicht als Ertrag, als "erwirtschaftet" gilt, sondern als "geliehen", und also auch nicht als Ertrag, als "Wachstum des Eigenkapitals" vesteuert werden muss! Das muss erst im nächsten Jahr geschehen, wenn der zweite Teilbetrag dann wirklich "verdient" ist und als Ertrag verbucht wird.

// -------- SCHNIPP --------------------------

#move 1002
#date 5.10.2010  #text PRA Auflösung -- Abnahme Restauftrag Wasserfall
                  #voucher siehe Buchung 28 a.d. Vorjahr
                  #from 3900/3   #eur 10000.00   #to  4400/1 #rest

^Inh 3.3.15 Steuern und Abschläge

Wenn ein Geschäft gut läuft verlangt das Finanzamt Abschläge auf die zu erwartenden Steuern. Diese zu zahlen ist en Aktiv-Aktiv-Tausch, denn die gezahlten Abschläge sind Guthaben beim Finanzamt. Sie ändern erstmal nichts am Vermögen des Unternehmens, geben dem Fiskus nur die Sicherheit, dass er auchnochwas abkriegt.

Erst wenn tatsächlich Steuern beschieden werden, werden diese dann in ihrer beschiedenen Höhe als Kosten gebucht und evtl. mit diesen Vorauszahlungen verrechnet.

Man beachte dass normalerweise diese Kosten ihrerseits nicht absetzbar sind, also auf ein "kn"-Konto gebucht werden müssen.

(
Die Steuergesetzgebung ändert sich aber von Zeit zu Zeit. Es gab z.B. Situationen, wo die geleistete Gewerbesteuer zur Ermittlung des Gewinnes für die Körperschaftssteuer abgezogen werden durfte. Das kann BandM booking in der derzeigen Form nicht! Es werden halt ALLE Kosten (Konten der Klasse k und kn) abgezogen, und die Saldi der Konten der Klasse kn zeitweilig wieder aufaddiert, zur Ermittlung der Besteuerungsgrundlabe. Die zu jener Variante notwendige Zwei-Schrittigkeit müsste nachimplementiert werden, wenn's mal wieder Gesetz wird.
)

Sehr Ähnliches wie für o.e. Abschläge gilt für die "Zinsabschlagssteuer" oder "Quellensteuer" o.ä., die von einer BANK direkt ans Finanzamt als Abschlag auf die zu erwartenden Kapitalertragssteuer abgeführt wird, siehe weiter unten.

Im Falle der Sandsack GmbH sehen Kontenplan und Buchungssätze aus wie folgt:

#accountGroup 3030  #title Gewerbesteuer-Rückstellung
                    #class a
     #account 1 #title Gezahlt als Abschlag ans FA 
     #account 2 #title Auf eigenem Konto

#accountGroup 3040  #title Körperschaftssteuer-Rückstellung
                    #class a
     #account 1 #title Gezahlt als Abschlag ans FA 
     #account 2 #title Auf eigenem Konto

#accountGroup 3050  #title gezahlte Zinsabschlagssteuer (ohne SOLZ)
                    #class a
     #account 1     #title abgeführt von Dresdner Stollenbank

#accountGroup 3051  #title gezahlter Solidaritätszuschlag auf Zinsabschlagssteuer
                    #class a
     #account 1     #title abgeführt von Dresdner Stollenbank


//...

#accountGroup 7600  #title Körperschaftssteuer
                    #class kn
     #account 1 #title Gezahlte KSt

#accountGroup 7608  #title Solidaritätszuschlag
                    #class kn
     #account 1 #title Gezahlter SolZ (aus KSt)

#accountGroup 7610  #title Gewerbesteuer 
                    #class kn
     #account 1 #title Gezahlte Gewerbesteuer

// -------- SCHNIPP --------------------------

#move 30
#date 05.11.2009  #text Vorauszahlung Steuern gem. Schätzung
                  #voucher Bescheid vom FA Berlin-Charlottenburg / Bankauszug
                  #from 3030/1 #eur 2000.00 
                  #from 3040/1 #eur 2000.00  #to 1800/1 #rest

// -------- SCHNIPP --------------------------

/* ==============
IRGENDWANN IM (ÜBER-)NÄCHSTEN JAHR werden dann die Vorauszahlungen/Aktiva
mit den dann tatsächlich fälligen Zahlungen der Steuern verrechnet:
Das wird dann ungefähr so aussehen:

#move 2028
#date 23.09.2011  #text Begleichung Körperschaftssteuer
                  #voucher Bescheid vom 12.8.11 FA Berlin-Charlottenburg / Bankauszug
                  #from 7600/1 #eur 2133.00 #to 3040/2 #eur 2000.00  
                                            #to 1800/1 #rest

#move 2029
#date 23.08.2011  #text Begleichung Gewerbesteuer
                  #voucher Bescheid vom 12.8.11 FA Berlin-Charlottenburg / Bankauszug
                  #from 7610/1 #eur 2208.72 #to 3030/2 #eur 2000.00  
                                            #to 1800/1 #rest
=============== */

^Inh 3.3.16 Investitionen, Inventar und (Sonder-)Abschreibungen

Wenn sog. "geringwertige Wirtschaftsgüter" angeschafft werden, dann können die Kosten direkt und vollständig als Aufwendungen abgesetzt werden (Direktabschreibung):

#accountGroup 6260  #title Sofortabschreibung geringwertiger Wirtschaftsgüter
                    #class k
     #account 1 #title Büromaschinen
     #account 2 #title Montagematerial und Zubehör
     #account 3 #title Software-Lizenzen
     #account 4 #title Fachliteratur 
     #account 5 #title Werbematerial
     #account 6 #title Multi Media Equipment



// -------- SCHNIPP --------------------------

#move 31
#date 06.11.2009  #text Einhundert Anspitzautomaten
                  #voucher Fremde Rechnung 
                  #from 6260/1 #eur 400.00  
                  #from 1406/1 #eur  76.00   #to 1800/1 #rest

Man beachte, dass die genauen Regeln, was wie abschreibbar ist, sich jedes Jahr ändern können und genauestens befolgt werden sollten.

Da Aufwendungen das Geldvermögen und das Eigenkapital vermindern, ist eine geringwertige Anschaffung und die damit verbundene Sofort-Abschreibung eine Bilanzverkürzung.

Wertvollere Güter müssen anders behandelt werden:
Ihre Anschaffung ist eine "Investition".
Ihre Existenz muss im "Inventar" belegt werden.
Der Kauf-Vorgang ist ein reiner Aktiv-Aktiv-Tausch: Geldvermögen wird durch gleichwertiges Anlagevermögen ersetzt.
Eine "Aufwendung" entsteht ausschließlich durch die Abnutzung der Anlage, "Abschreibung für Abnutzung", "AfA").

In BandM booking wird diese repräsentiert durch automatisch generierte Abschreibungs-Buchungen im Rahmen des Jahresabschlusses. Deren technischen Aspekte werden erklärt in Abschnitt 3.4.1 ("Automatisch generierte Afa-Buchungen "). Um deren Generierung zu ermöglichen enhält die Kontenplan-Datei einige zusätzliche Angaben.

Die Gesamtheit der benötigten Einträge in die veschiedenen Dateien sieht so aus:

// Einträge im Kontenplan, bis jetzt noch nicht besprochen, 
//  zum Zwecke der AfA-Verbuchung

#d2d 2.0 text using eu_bandm_booking  : accountPlan

//...
#depreciation_min 6200
#depreciation_max 6299
//...


// -------- SCHNIPP --------------------------

// dies sind "Anlage-Konten" für Wertgegenstände die als "Aktiva" gehalten werden:

#accountGroup 400 #title  aktivierte Büromaschinen
	        #class a
     #account 1 #title  Büro Dr. Pick
     #account 2 #title  Büro Dr. Gotowohl

#accountGroup 401 #title  aktiviertes multi-media Equipment
	        #class a
     #account 1 #title  Büro Dr. Pick
     #account 2 #title  Büro Dr. Gotowohl

#accountGroup 419 #title  aktivierte Büromöbel
	        #class a
     #account 1 #title  Büro Dr. Pick
     #account 2 #title  Büro Dr. Gotowohl


// ...

// Dies ist ein Aufwandskonto für die 
//    bei Jahresabschluss automatisch generierten Afa-Buchungen:

#accountGroup 6220  #title AfA für aktivierte Anschaffungen KT400, KT401 und KT419
                    #class k
     #account 1 #title  Pick 
     #account 2 #title  Gotowohl


// -------- SCHNIPP --------------------------

#move 32
#date 08.11.2009  #text Erwerb Laptop und Zubehör Dr. Gotowohl
                  #voucher fremde Rechnung
                  #from 400/2     #eur 580.00
                  #from 1406/1    #eur 114.00  #to 1800/1 #rest

// Die folgenden Zeilen des Buchungssatzes sind nur bei Erwerb von 
// Anlagevermögen möglich und nötig:
                  #newAsset LapTop Siemens-Fujitsu AMILO PA3515
                            #prodcom_code 26.20.11.00  #deprec_mode lin36

#move 33
#date 09.11.2009  #text Erwerb Laptop und Zubehör Pick
                  #voucher fremde Rechnung
                  #from 400/1     #eur 600.00
                  #from 1406/1    #eur 114.00  #to 1800/1 #rest
                  #newAsset LapTop Dell DX 2177 Special Edition
                            #prodcom_code 26.20.11.00  #deprec_mode lin36


// -------- SCHNIPP --------------------------
// Das Format dieser zusätzlichen Buchungs-Felder 
//    ist definiert in eu_bandm_booking.dd2 wie folgt:


  tags move = #implicit num, (date & text &  voucher /*...*/ & comment?),
                     from+, to+, (refAsset|newAsset)?
  tags refAsset, OLDLABEL = #chars
  tags newAsset = #implicit title, (OLDLABEL? & prodcom_code? 
                                   & deprec_mode)

// -------- SCHNIPP --------------------------
// In der KONTENPLAN-DATEI muss am Anfang jedes KUERZEL für ein 
//   Abschreibungsverfahren auf eine Java-Klassen abgebildet werden, 
//   die dieses implementiert:

#depreciation lin48    #codeAt de.sandsack.booking.special_49_lin_deprec

#depreciation lin36    #codeAt lin36
// reads as                    eu.bandm.book2.base.Depreciation_lin36

Um den Erwerb eines Anlage-Gegenstandes ("asset") richtig zu verbuchen, sind nun einige Angaben mehr nötig als in allen bisherigen Beispielen:

  1. Am Ende des Buchungssatzes für den Erwerb muss ein "newAsset"-Element angehängt werden. Dieses gibt als erstes, ohne weitere Textmarkierung (vgl. die Deklaration als "#implicit title") eine menschenlesbare eindeutige Bezeichnung für die Art des erworbenen Dinges. Unter dieser wird es im (menschenlesbaren) ausgedruckten Inventarverzeichnis erscheinen.
  2. Die technische Identifikation eines jeden Anlage-Gegenstandes aber geschieht durch eine Kombination "Geschäftsjahr-Minuszeichen-Buchungsnummer" dieser "Erwerbs-Buchung", im Beispiel oben also "09/10-33". Deshalb muss jedes erworbene Asset eine eigene solche Erwerbs-Buchung haben.
  3. Dann kann eine "prodcom"-Nummer kommen, die die Art des Gegenstandes gemäß der "Prodcom-Liste" angibt [prodcom] . (Man kann in diesem Feld aber auch Codes aus leicht abweichende Klassifikationssysteme eintragen, z.B. "combined Nomeclature", "Taric" o.ä., der name "ProdCom" steht dann eher fürs Prinzip, man sollte aber explizit auf solche Abweichungen hinweisen. Man kann auch ganz auf dieses Feld verzichten.)
  4. (Das "OLDLABEL"-Element wird vom Programm nur intern benutzt, bei der Generierung der Eröffnungsbuchungen, s.u.)
  5. Es muss ein Code für das anzuwendende Abschreibungs-Verfahren durch ein "deprec_mode"-Element angegeben werden. Es können verschiedene Abschreibungs-Verfahren implementiert sein. So steht "lin36" für die lineare Abschreibung auf sechsunddreißig Monate. Ein unbekannter Code führt zu einem Fehler.

Die Generierung der Buchungen für die Abschreibung wird von der Software automatisch mit dem Jahresabschluss erledigt. Zu diesem Zweck sind folgende zusätzlichen Angaben nötig:

  1. Im Kontenplan wird mittels der Elemente "depreciation_min" und "depreciation_max" der Bereich von Kontengruppen angegeben, die als Aufwandskonten die AfA-Buchungen aufnehmen.
  2. In den Titelzeilen dieser Kontengruppen wird durch die irgendwo enthaltenen Texte (ein oder mehrere) der Form "KT<nnn>" auf die aktiven Anlage-Kontengruppen verwiesen, für die hier die AfA-Buchungen gesammelt werden.
  3. Im Kontenplan werden die Kürzel für die Abschreibungen bestimmten Java-Klassen zugeordnet, die nachher diese Abschreibung berechnen. Mehr dazu in Abschnitt 3.4.1 ("Automatisch generierte Afa-Buchungen ").

Die so definierte Zuordnung zwischen Anlage- und Abschreibungskonten muss von den Anlage-Kontengruppen her gesehen eine "totale Abbildung" sein, d.h. jeder Anlage-Kontengruppe muss genau eine(1) Afa-Kosten-Kontengruppe zugeordnet sein. Also müssen alle in einer Titelzeile einess Afa-Kontos mit "KT<..>" benannten Anlage-Kontengruppen auch existieren. Andernfalls wird beim Laden des Kontenplanes ein Fehler erkannt und die weitere Bearbeitung verweigert.
Die Beziehung für die späteren Buchungen wird dabei etabliert zwischen den Unterkonten gleicher Nummer aus Aktivkonto-Gruppe und Afa-Konto-Gruppe, so dass für alle Unterkonten aller referierten Anlagekonto-Gruppen hier ein Unterkonto existieren muss. Sonst wird ebenfalls ein Fehler erkannt.

In unserem Beispiel geschieht die Untergliederung von Aktiv- und Abschreibungskonten nach den Personen, die die Assets nutzen. Damit kann man grob nachhalten, dass es zwischen diesen in ihrem gemeinsamen Unternehmen "halbwegs gerecht" zugeht. Man könnte aber auch die Unterkonten nach "Arten" der Investitionen organisieren, um darüber einen Überblick zu erhalten.

Man sieht, die von BandM booking erlaubten mittel zur "Kostenkontrolle" sind sehr eingeschränkt, -- in einem größeren System hätte man wahrscheinlich gerne beide Dimensionen irgendwie dargestellt. Das kann unser Primitiv-System natürlich nicht, und da muss man sich entscheiden, wie man seine beschränkten Strukturierungsmöglichkeiten einsetzen will. In Zusammenhang mit derartigen Entscheidungen ist besonders zu beachten, dass der Kontenplan während der gesamten Lebensdauer des Unternehmens nur mononton erweitert werden darf.

Zurück zur Abschreibung:
Neben den automatisch generierten Buchungen, die hier vorbereitet sind, und weiter unten genauer besprochen werden, kann der Benutzer allerdings jederzeit Sonderabschreibungen formulieren. Durch buchen "zuständiges Afa-Aufwands-Konto an Anlagevermögen" (oder auch "spezialisiertes Sonderabschreibungskonto an Anlagevermögen", wie im folgenden Beispiel) kann z.B. eine manuell berechnete Abschreibung bei eingetretener Havarie, etc., vorgenommen werden. Der betroffene Anlage-Gegenstand wird dabei durch das "refAsset"-Element bezeichnet, mit dem technischen Identifikator des Gegenstandes (wie erwähnt, zusammengesetzt aus Jahreszahl und Buchungsnummer des Erwerbs). Die Generierung der automatischen Afa-Buchung beim Jahresabschluss wird für diesen Anlage-Gegenstand dadurch unterdrückt.

#move 34
#date 10.11.2009  #text Totalschaden Laptop
                  #voucher Eigenbeleg
                  #comment Fräulein Schmidt ist eine Tasse Kaffee mit Zucker
über die Tastatur des Laptop gefallen. Irreparabel.
                  #from 6221/1   #eur 579.00  #to 400/2 #rest
                      #refAsset 09/10-32

In der graphischen Benutzeroberfläche werden auf der Seite "Inventar" alle Anlagengegestände dargestellt, mit Bezeichnung, Code-Kürzel, Buchwert, etc.
Ausserdem werden alle relevanten Buchungen auf dem Anlage-Unterkonto dargestellt und saldiert.
Ein "asset" wird auf dieser Seite also behandelt wie ein "Unter-Unter-Konto", was wieder einmal die "mathematische Kompositionalität" dieses genialen Verfahrens eindrucksvoll aufzeigt.

^Inh 3.3.17 Dateisicherung, Radierungsverbot und Korrekturbuchungen

Die "GoB" verlangen, dass in Aufzeichnungen niemals korrigiert wird, sondern alle Fehler explizit und nachlesbar korrigiert werden.

BandM booking basiert auf einfachen Text-Dateien, die selbstverständlich jederzeit verändert werden können. Um dies zu verhindern, oder zumindest zu protokollieren, müssen externe Revisionskontrollprogramme herangezogen werden, wie oben erwähnt, Abschnitt 1.4 ("Eigenheiten von BandM booking. Notwendige Externe Programme ").

Da nachträgliche Änderungen erfolgter Buchungen verboten sind, müssen zusätzliche Mittel bereitgestellt werden, um notwendige Korrekturen als neue, explizite Buchungssätze in das System einzubringen.

Dabei unterscheiden wir

  1. Rückbuchungen, auch genannt Stornierungen oder Teilstornierungen. Diese dienen der tatsächlichen Rück-Abwicklung von Geschäftsvorfällen, haben also eine Entsprechung in der rechtlichen Realität.
  2. Korrekturbuchungen. Diese dienen der Berichtigung eines fehlerhaften Buchungssatzes, wie er entstehen kann durch Zahlendreher, falsche Kontozuordnung, etc. Sie beziehen sich also auf Vorgänge nur innerhalb der Buchführung selber.

Bei beiden wird mit deren Buchungsnummer auf die originale Buchung zurückverwiesen, bei ersteren über das Element "REV", bei zweiten über das Element "CORR".

In beiden Fällen muss ein "comment"-Element angegeben werden, in welchem der Grund der Korrekturbuchung hinreichend genau erläutert wird. Die Verwendung des "#rest"-Elementes ist nicht erlaubt, hier sollen keine weiteren Irrtümer und Schreibfehler möglich sein.

Bei einer Korrekturbuchung können ausnahmsweise die Erfolgskonten "auf der falschen Seite" bebucht werden. Ertragskonten können normalerweise nur im Haben, Aufwandskonten nur im Soll bebucht werden. Bei einer Korrektur hingegen sind Mischungen von "richtigen" und "verdrehten" Bebuchungen von Konten durchaus möglich und sinnvoll.

Bei einer "CORR"-Buchung müssen sämtliche Konten der Originalbuchung explizit aufgeführt werden, auch auch nur diese dürfen in der Korrekturbuchung auftreten. Es gilt als Fehler, wenn dagegen verstoßen wird. Dies hat zur Voraussetzung, dass in einer solchen Korrekturbuchung auch der Wert "null" "0.0 EUR" bei einem Konto stehen darf.

Wenn die Referenz-Buchung in einem vorangehenden Geschäftsjahr lag, kann dies alles aber nicht überprüft werden, und dies wird als Warnung angezeigt.

Wenn es sich um eine "REV" Buchung handelt, führt eine Verletzung derselben Bedingung nur zu einer Warnung. Häufige Fälle sind, wenn ein Gegenstand mit Überweisung bezahlt wurde, sich dann aber als fehlerhaft herausstellt, zurückgegeben wird, und der Kaufpreis bar erstattet, oder umgekehrt. Dann ist der Geschäftsvorgang korrekt revidiert, aber die beteiligten Konten sind nicht vollständig dieselben.

Für beides ein Beispiel:
Zuerstmal seien die hundert Anspitzmaschinen defekt und werden gegen Kaufpreiserstattung zurückgegeben. Da Herr Pick persönlich da vorbeifährt und auf den Tisch haut, bekommt er das Geld tatsächlich bar ausgezahlt, was impliziert, dass die beteiligten Konten nicht alle dieselben sind wie in der Bezugsbuchung. Nichtsdestotrotz handelt es sich um eine Revision, und Erfolgskonten dürfen auf der "ungewöhnlichen" Seite bebucht werden:

#accountGroup 1330  #title Forderung gegen Gesellschafter, 
                    #class a
     #account 1 #title  Pick
     #account 2 #title  Gotowohl

#move 35
#date 15.11.2009  #text Rückgabe der Anspitzmaschinen
                  #voucher Eigenbeleg
                  #REV 31
                  #comment Die Geräte stellten sich als
völlig unbrauchbar heraus. Herr Pick brachte sie in den Laden und
kassierte den Kaufpreis in bar.
                  #from 1330/1 #eur 476.00 #to 6260/1 #eur 400.00  
                                           #to 1406/1 #eur  76.00   

Man sollte in solchen Fällen immer eine ausführliche Schilderung in das "comment"-Feld eintragen, wie eine Akten-Notiz. In der graphischen Benutzeroberfläche sieht man den Kommentar als "tooltip", wenn man in der "Buchungen"-Tabelle, der "journal"-Tabelle, auf dem Buchungstext bleibt.

Bei der Buchung der beiden Laptops ist irrtümlicherweise der Mehrwertsteuerbetrag des zweiten auch für den ersten eingesetzt worden (da sind wohl auf dem Schreibtisch die Quittungen verrutscht!-)
Das muss natürlich, entsprechend dem niedrigeren Kaufpreis, 110.20 EUR sein, nicht 114.00 EUR. Es handelt sich hier auch um eine Buchung auf der "falschen Seite" des Kontos, aber nicht um einen revidierenden Geschäftsvorfall, sondern nur um eine Korrektur des Buchungsvorganges. Dem Bankkonto müssen drei Euro achtzig wieder zugeschlagen werden, und von der geleisteten, anrechenbaren Vorsteuer abgezogen werden, damit unsere Buchhaltung wieder der Realität (dem tatsächlich getätigten Zahlungsvorgang) entspricht:

#move 36
#date 15.11.2009  #text Falscher MWSt-Betrag für Laptop Gotowohl
                  #voucher Eigenbeleg
                  #CORR 32
                  #comment 
Der MWSt-Betrag für den Laptop mit dem Nettopreis 580 beträgt 110.20.
Damals wurde irrtümlicherweise 114.00 gebucht, wie bei dem anderen,
zeitnah angeschafften Gerät. Gezahlt wurde aber nur der niedrigere und
korrekte Brutto-Betrag.
                  #from  400/2  #eur 0.0  
                  #from 1800/1  #eur 3.80 #to 1406/1 #eur  3.80   

^Inh 3.3.18 Gewinnausschüttungen

Nachdem soviel Geld eingenommen wurde, können natürlich auch Gewinne ausgeschüttet werden:

Dabei werden die Forderungen der Gesellschaft gegen Hrn. Pick gleich mitverrechnet.

(Man sieht auch sehr schön, dass die Sprech-Formel "Konto AN Konto" eine reine Konvention ist: "Gewinnausschüttung AN Bankkonto" bedeutet einen Mittelfluss von rechts nach links!)

#accountGroup 7394  #title Abgeführte Gewinne an Gesellschafter
                    #class k
     #account 1     #title Pick
     #account 2     #title Gotowohl

// -------- SCHNIPP --------------------------

#move 37
#date 10.12.2009  #text Ausschüttung Gewinn Pick
                  #voucher Gesellschafterbeschluss vom 1.11.2009, Kontoauszug
	          #comment verrechnet mit den Forderungen gg. Hern Pick
wegen Bar-Erstattung Buchung 35
                  #from 7394/1 #eur 4000.00  #to 1800/1 #rest
                                             #to 1330/1 #eur 476.00


#move 38
#date 10.12.2009  #text Ausschüttung Gewinn Gotowohl
                  #voucher Gesellschafterbeschluss vom 1.11.2009, Kontoauszug
                  #from 7394/2 #eur 4000.00  #to 1800/1 #rest



^Inh 3.4 Fortsetzung Beispiel: Jahresabschluss und Bilanz

Das Programm BandM booking kann in verschiedenen Kombinationen von Modi betrieben werden, s. Abschnitt 4.2 ("Bedienung der Programmes "). Allemal aber werden die Konfigurationsdatei, der Kontenplan, und die Eröffnungsbuchungen und das Journal des angegebenen Geschäftsjahre eingelesen und verarbeitet, d.h. auf Konsistenz und formale Korrektheit geprüft..

Im "interaktiven" Modus kann man sich danach in einer Graphischen Benuzterschnittstelle (="GUI") das Journal, die Einzelkonten, das Inventar etc. ansehen. (Später sollen weitere Visualisierungen und Auswertungen dazukommen.)

Im "Abschluss"-Modus wird der Jahresabschluss durchgeführt. Dafür werden

  1. Afa-Buchungen automatisch durchgeführt,
  2. Erfolgskonten (Aufwand und Ertrag) auf das Eigenkapitalkonto umgebucht
  3. eine Bilanz-Druckvorlage erstellt,
  4. und die Eröffnungsbuchungen des nächsten Geschäftsjahre generiert.

Beide Modi sind auch kombinierbar, so daß man in der interaktiven Graphik am Schluss der Journal-Liste die automatisch generierten Abschlussbuchungen auch sehen kann.

Für die verschiedenen automatisch generierten Buchungen enthält die Kontenplan-Datei folgende zusätzlichen Elemente:

#d2d 2.0 text using eu_bandm_booking  : accountPlan

// Einträge im Kontenplan, bis jetzt noch nicht besprochen, 
//  zum Zwecke des Jahresabschlusses

// Stammkapital findet sich in dem einzigen Konto (!) dieser Kontengruppe
#founding 2000

// Eigenkapital findet sich in dem einzigen Konto (!) dieser Kontengruppe
#equity  2010

// Das universelle Übertragskonto ist das einzige Konto (!) dieser Kontengruppe
#carry   9900 

Diese Nummern identifizieren die Ober-Konten für das Gründungskapital, das Eigenkapital und das universelle Übertragskonto für die Abschluss- und Eröffnungsbuchungen. Es wird jeweils das "Unter-Konto Nummer Eins" aus diesem Ober-Konto benutzt. Diese müssen auch im Kontenplan so deklariert werden, wie jedes andere Konto.

^Inh 3.4.1 Automatisch generierte Afa-Buchungen

Zur Generierung der automatischen AfA-Buchungen ist oben in Abschnitt 3.3.16 ("Investitionen, Inventar und (Sonder-)Abschreibungen ") bereits gesagt worden, dass (1) ein Abschreibungsverfahren beim Erwerb des Anlagegegenstandes angegeben werden muss, und dass (2) dieses Kürzel in der Kontenplan-Datei einer Java-Klasse zugeordnet werden muss. Wenn diese Klassenangabe kein Punkt-Zeichen "." enthält, wird der Inhalt der Konstanten OWNCODE_PREFIX davorgehängt, nämlich "eu.bandm.book2.base.Depreciation_", und die ausführende Klasse folglich unter den mitgelieferten Standard-Abschreibungen gefunden.
(Zur Zeit sind da nur "lin36" und "lin60" unterstützt.)
Es kann aber jede eigenen Implementierung hier eingehängt werden, wenn sie der Interface-Spezifikation Depreciation.java entspricht und im "-classpath" des Java-Interpreters gefunden wird.

Es sei nachgetragen, dass der Buchungstext der automatisch generierten Buchung lautet
Auto-Afa Gesamtzeit 11/lin36 für Anlagegegenstand <menschenlesbare Bezeichung>

Dabei bedeutet die Zahl hinter "Gesamtzeit" die Monate, die in diesem Geschäftsjahr berücksichtigt werden konnen, und das Kürzel dahinter das Abschreibungsverfahren.

Diese Buchungen erscheinen in der interaktiven Oberfläche genau dann, wenn die Option "--closeYear" und die Option "--interactive" beide angewählt sind.

Bei Erstellen des Abschlusses werden die generierten Buchungen zusätzlich in eine Datei geschrieben, die sich aus der Dateinamen-Vorlage im Element "filetemplate_autoDeprecation" in der Konfigurations-Datei ergibt, wie immer durch Einsetzen des Geschäftsjahres.

Dort haben sie dann ein Aussehen wie eine explizite Abschreibungs-Buchung. Die früheste derartige Datei in unserem Beispiel heisst "afa_automatisch_09_10" und sieht ungefähr aus wie folgt:

// Datei mit automatisch generierten Abschreibungs-Buchungen
/* created on 2013-06-14_09h50m46
by program bandm_booking (=eu.bandm.book2.base.Main), version 1.2.0
command line = 
bandm_booking (=eu.bandm.book2.base.Main) -Y 09_10 --directory . --closeYear true 
*/

#move 40
#date 30.06.2010 #text Auto-Afa Gesamtzeit 8/lin36 für Anlagegegenstand LapTop Dell DX 21
      #voucher Automatische Buchung/Kein Beleg
      #from 6220/1  #eur 133.33  #to 400/1 #rest 
      #refAsset 09/10-33

#eof

Diese Datei hat aber lediglich Dokumentationsfunktion. Auf der technischen Ebenen, zum Eröffnen des nächsten Jahres, gehen diese neuen Abschreibungen in die Summe aller Abschreibungen ein, wie sie in die Eröffnungsbuchungen eingetragen werden, und die die Funktionsfähigkeit des Programmes für das Folgejahr ermöglichen, siehe unten Abschnitt 3.4.4 ("Generierung der Eröffnungsbuchungen").

^Inh 3.4.2 Umbuchung Erfolgskonten auf Eigenkapital

Alle Erfolgskonten sind konzeptionell Unterkonten des Eigenkapitals, weil sie dieses vermindern oder vermehren.
Die beiden Arten von Buchungen heißen
"Ertragskonto an Eigenkapital",
wodurch Erträge das Eigenkapital erhöhen, und
"Eigenkapital an Aufwandskonto",
wodurch Aufwände das Eigenkapital vermindern.

Im Rahmen des Jahresabschlusses werden vor Erstellung der Bilanz werden für alle Erfolgskonten derartige automatischen Umbuchungen generiert. Der generierte Buchungstext heißt immer
Automatischer Abschluss Erfolgskonten/Eigenkap. JJ/JJ

Auch diese Buchungen sind in der graphischen Benutzeroberfläche sichtbar wenn die Modi für Abschluss und Interaktiv beide angewählt sind.

^Inh 3.4.3 Generierung der Bilanz-Druckvorlage

Für die Generierung der Bilanz-Druckvorlage nimmt das Programm die Gruppierungsregeln aus der config-Datei, die in dem jüngsten aller Unterelement des Elementes "birili" enthalten sind, die älter als das Geschäftsjahr ist. (Also werden diese Gruppierungsregeln so lange beibehalten, bis für ein Geschäftsjahr neue definiert werden.)

Diese sehen aus wie

#d2d 2.0 text using eu_bandm_booking  : configuration

  //...
  #birilis 
    #businessYear 08/09
      #group#from 4120 #upTo 4400 #text Erlöse aus Lieferungen und Leistungen
      #group#from 7100 #upTo 7100 #text Zinserträge
      #group#from 4975 #upTo 4975 #text Subventionen
      #group#from 6000 #upTo 6199 #text Personalkosten (Gehalt, SozBeiträge)
      #group#from 6220 #upTo 6299 #text Abschreibungen
      #group#from 6300 #upTo 6399 #text Fremde Leistungen
      #group#from 6400 #upTo 6429 #text Versicherungen
      //  etc.

Jede solche Auswertungsregel gibt zwei Kontengruppen-Nummern von-bis (beide einschliesslich) an, und den Text der der Summe der Salden vorangestellt werden soll. Alle Kontengruppen einer solchen Gruppierung müssen vom selben Typ sein ("a", "p", "k", "kn", "e" oder "en"), und alle Kontengruppen müssen in genau einer der Gruppierungen enthalten sein.

Bei Erstellung der Druckvorlage werden diese Gruppierungen verwendet, alle enthaltenden Konten werden aufaddiert und diese Summe hinter dem Beschreibungstext ausgedruckt.

Dabei erfolgt die Sortierung wie in dem "birilis"-Element, allerdings nach Klassen getrennt, nämlich nach folgenden Publikationsschema:

  1. Bilanz: Aktiva,
    erst birilis-Gruppen, dann Summe
  2. Bilanz: Passiva
    erst birilis-Gruppen, dann Summe
  3. Erfolgsermittlung
  4. Inventar
  5. Geschäftsbericht: Erlöse
    erst birilis-Gruppen, dann Summe
  6. Geschäftsbericht: Aufwendungen
    erst birilis-Gruppen, dann Summe

Wenn die Druckvorlage mittels LaTeX erstellt wird, muss je Jahr ein LaTeX-Template vorgegeben werden. Dieses wird zeilenweise verarbeitet. Sobald die Zeichenfolge ">>>>tex_print_a" am Zeilenanfang auftritt, werden da die Macro-Aufrufe für alle "a"-Konten, also "Aktiva" eingesetzt, genauso mit "p", "e" und "k" (wobei "en" und "kn" jeweils mitgemeint sind)
Am Anfang muss ">>>>tex_declarations" eingefügt werden, welches allgemeine Macros wie Kalenderdaten etc. definiert, und an gewünschter Stelle die Gewinnermittlung mittels ">>>>tex_guv".

Die Druckvorlage in unserem Beispiel ist die Datei sandsack_bilanz_vorlage_09_10.tex. Ihr Aufbau ist ungefähr:

\documentclass[12pt]{article}
%% --- SCHNIPP 

\input{common_bilanz} 

\begin{document}
>>>>tex_declarations
\xTitle{\xBusinessYear}{\xToday}

\tableofcontents{}

\section{Bilanz}
\begin{tabular}{lp{0.450\textwidth}rrrr}
\multicolumn{6}{l}{\small(folgend SKR04)}\\
&&&&&\\
\underline{AKTIVA:}&&&&&\\
&&&&&\\
>>>>tex_print_a
&&&&&\\
\underline{PASSIVA:}&&&&&\\
&&&&&\\
>>>>tex_print_p
\end{tabular}

\section{Wirtschaftlicher und steuerlicher Gewinn/Verlust}
\begin{tabular}{lp{0.450\textwidth}rrrr}
>>>>tex_guv
\end{tabular}
\clearpage{}

\section{Inventar}
>>>>tex_inventar 
\clearpage{}

\section{Geschäftsbericht}
\begin{tabular}{lp{0.45\textwidth}rrrr}
\multicolumn{6}{l}{\small(folgend SKR04)}\\
&&&&&\\
\underline{ERLÖSE:}&&&&&\\
&&&&&\\
>>>>tex_print_e
&&&&&\\
\multicolumn{2}{l}{\underline{AUFWENDUNGEN:}}&&&&\\
&&&&&\\
>>>>tex_print_k
\end{tabular}

\end{document}

Man beachte dass die Aufrufe von ">>>>tex_print_a" etc. in eine entsprechende Tabellenumgebung eingepasst werden müssen.

Hat man mit den Beispieldaten den Jahresabschluss durchgeführt, wie beschrieben in Abschnitt 4.2 ("Bedienung der Programmes "), dann liegt die LaTeX-Datei vor als Datei sandsackGmbH/bilanz_09_10.tex! Ein Blick in diese klärt die Zusammenhänge zwischen automatischen Einfügungen und "table"-Kontext.

Die Template-Datei nimmt nur über ebenfalls generierte TeX-Definitionen Bezug auf das Wirtschaftsjahr und die Kalenderdaten. Sie kann also für mehrere Jahre verwendet werden, indem sie einfach kopiert wird. Sie kann aber auch angepasst werden.

Sie inkludiert die Datei common_bilanz.tex, welche die Unternehmens-Rahmen-Daten (Steuernummer, Registereintrag, Adresse) in LaTeX-graphisch aufgearbeiteter Form enthält.

Hat man den Jahresabschluss in unserem Beispiel durchgeführt und die entstehende ".tex"-Datei mit pdflatex übersetzt, dann erhält man die Druck-Datei bilanz_09_10.pdf. Diese sieht ungefähr aus wie ...

-----------------------------------------------------------------
Geschäftsbericht der Sandsack GmbH, Berlin
-----------------------------------------------------------------

+-----------------+---------------------------------------------+
| Registereitrag  | HRB 012 345    ...                          |
+-----------------+---------------------------------------------+
| Steuernummer    | 47 / 11 / 08-15 ..                          |
+-----------------+---------------------------------------------+
| Geschäftsjahr   | 01.07.2009 bis 30.06.2010                   |
+----------------------------------------------------------------

BILANZ (folgend SKR04)

  Aktiva 

    0001-0001   Ausstehende Einlagen            12,500.00 EUR
    0400-0699   Aktivierte Produktionsmittel       467.67 EUR
    // -- etc., alle Kontengruppierung vom "a" Typ mit ihrem Text
    // am Schluss die Summe aller

                                                             58,039.70 EUR

  Passiva

    2000-2000   Stammkapital                    25,000,00 EUR
    2010-2010   Eigenkapital                    11,714.75 EUR
    // -- etc., alle Kontengruppierung vom "p" Typ mit ihrem Text
    // am Schluss die Summe aller


                                                             58,039.70 EUR

-----------------------------------------------------------------

  Wirtschaftlicher und steuerlicher Gewinn/Verlust


    2010        Eigenkapital am Ende dieses Jahres     19,239.70 EUR
    2010        Eigenkapital am Beginn dieses Jahres        0.00 EUR
                Wirtschaftlicher Gewinn                          19,239.70 EUR

    korrigiert um ...
    4975        Subventionen                            -7,500.00 EUR
    6644        Bewirtungskosten NICHT abzugsfähig          28.14 EUR
                Wirtschaftlicher Gewinn                          11,767.84 EUR


-----------------------------------------------------------------

INVENTAR

  09/10-33  LapTop Siemens-Fujitsu AMILO PA3515
            Kaufdatum 08.11.2009 Kaufpreis  580.00 EUR
            gehalten in Konto 400/2, Abschreibung: linear auf 36 Monate
            Restwert 1.00 EUR 

  09/10-34  LapTop Dell DX 21777 Special Edition
            Kaufdatum 09.11.2009 Kaufpreis  600.00 EUR
            gehalten in Konto 400/1, Abschreibung: linear auf 36 Monate
            Restwert 466.67 EUR 

-----------------------------------------------------------------

Geschäftsbericht

   Erlöse

    4120-4400   Erlöse aus Lieferungen und Leist.      22,000.00 EUR
    4975        Subventionen                            7,500.00 EUR
    // -- etc., alle Kontengruppierung vom "e" Typ mit ihrem Text
    // am Schluss die Summe aller
                                                                 29,524.95 EUR


   Aufwendungen 

    6000-6199   Personalkosten                      235.39 EUR 
    6220-6299   Abschreibungen                      712.33 EUR 
    // -- etc., alle Kontengruppierung "k"/"kn"
                                                                 10,285.25 EUR


-----------------------------------------------------------------
  1. Zunächst werden die Salden aller "a"-Konten nach Gruppierungen zusammengefasst und aufaddiert. Ergibt sich für eine Gruppierung eine Summe grüßer Null(0), dann wird diese gedruckt, eingeleitet durch die Angabe der Kontogruppen-Nummern "von bis" und den Text der Gruppierung.
  2. Dann wird die Summe aller dieser Gruppen gedruckt.
  3. Dann werden die "p"-Konten genauso behandelt, aber ihre Salden werden invertiert, also "positiv" gemacht. Es werden die Endstände aller Konten ausgedruckt, d.h. auf das Eigenkapitalkonto sind alle Erfolgskonten bereits umgebucht worden, wie oben als "automatische Abschlussbuchung" beschrieben.
  4. Wenn die Gesamtsummen von "a" und "p"-Konten nicht übereinstimmen, wird mit einer Fehlermeldung die Bearbeitung abgebrochen.
  5. Zur Ermittlung von "wirtschaftlichem und steuerlichem Gewinn/Verlust" wird das Eigenkapital zu Beginn des Jahres abgezogen vom Eigenkapital am Ende des Jahres, nach dem alle Erfolgskonten damit verrechnet wurden.
    Dies ergibt den wirtschaftlichen Erfolg. Ein negatives Vorzeichen bedeutet "Verlust", und die Texte im Ausdruck werden entsprechend dem Vorzeichen gewählt.
  6. Danach wird die Summe aller "kn"-Konten wieder dazuaddiert. Das sind die sogenannten "Hinzurechnungen", also Kosten, die steuerlich nicht abgesetzt werden dürfen. Deshalb ergibt sich meist ein "steuerliches" Ergebnis das höher liegt als das "wirtschaftliche".
    Es werden aber genauso die Salden der "en"-Konten abgezogen, für steuerfreie Einnahmen/Erträge. (Dies ist aber viel seltener !-)
  7. Dann kommt das Inventar, das listet für jeden Anlage-Gegenstand den Maschinen-code, den menschenlesbaren Bezeichner, Kaufdatum, Kaufpreis, Bestandskonto, Abschreibungsart und Restwert zum Zeitpunkt der BIlanzierung.
  8. Dann erfolgt ein "Geschäftsbericht", bei dem zuerst die "e/en"-Konten und dann die "k/kn"-Konten aufgelistet und addiert werden, genau wie zu Beginn die Bestandskonten. (Hier werden natürlich die Salden genommen, bevor die Konten auf das Eigenkapitalkonto umgebucht wurden, denn danach sind sie ja alle gleich null(0) !-)

^Inh 3.4.4 Generierung der Eröffnungsbuchungen

Die Erfolgskonten werden, wie oben erwähnt, im "Eigenkapitalkonto absorbiert", so daß sie am Jahresende und am Beginn des nächsten Geschäftsjahres den Saldo "Null(0)" haben.

Hingegen müssen die Bestandskonten mit ihrem Endstand in den Anfangsstand des Folgejahres eins-zu-eins übernommen werden.

Zu diesem Zweck wird eine Eröffnungs-Saldi-Datei für das nächste Jahr generiert. Der Name dieser Datei wird generiert aus der Vorlage, angegeben in der Konfigurationsdatei, durch das Einsetzen der Jahresangabe des zu eröffnenden Folgejahres, siehe oben Abschnitt 3.2 ("Die beteiligten Dateien").

Diese Datei enthält automatisch generierte Buchungen, die den Anfangszustand der Bestandskonten herstellen, der dem Endzustand im Jahre zuvor entspricht. Die Nummern dieser automatischen Buchungen schliessen an die der letzten generierten automatischen Buchungen des Vorjahres an.

(Wie bereits oben erwähnt sollten die expliziten Buchungseinträge durch den Benutzer von Jahr zu Jahr einen Tausendersprung o.ä. machen, damit die Lesbarkeit erhöht wird, und Konflikte zu den Eröffnungsbuchungen vermieden werden.)

Da Aktiv- und Passivkonten sich zum Betrag Null(0) addieren, geschieht dieser Übertrag durch Buchungen der Gestalt
"Aktivkonto an Übertragskonto",
und
"Übertragskonto an Passivkonto".

Im Kontenplan muss eine einzige Kontengruppe mit dem Typ "v" und einem Titel wie "Übertragskonto" eingerichtet werden. Deren Nummer ist im "carry"-Element anzugeben, und sie muss ein einziges Konto mit der Nummer eins(1) enthalten. Dieses Konto darf NUR von der Software intern benutzt werden, niemals explizit bebucht.
Nach Verarbeitung aller Eröffnungsbuchungen hat dieses Konto wieder den Saldo "Null(0)".

Bei Aktivkonten(-Gruppen), die Anlagevermögen entsprechen, wird nicht nur eine einzige Eröffnungsbuchung hergestellt, sondern ZWEI(2) je Anlage-Gegenstand:

Die erste ist eine wörtliche Kopie der ersten Anschaffungs-Buchung. Gleich bleiben Buchungstext, "newAsset/implicit title", also die menschenlesbare Bezeichnung, das alte Datum, der prodcom-Code, und der "deprec_mode".
Zusätzlich enthält das nur vom Programm selbst verwendete Element "OLDLABEL" den Text des ursprünglich generierten Bezeichners, z.B. "09/10-33". Dieser bezeichnet ja eindeutig den Anlage-Gegenstand, und soll sich nicht ändern, wenn hier eine neue, Pseudo-Anschaffungs-Buchung erstellt wird.
Man beachte dass das DATUM der Anschaffungs-Buchung auch beibehalten wird. Somit liegt hier der einzige Fall vor, wo Buchungen in nicht kalendarisch streng ansteigender Folge akzeptiert werden.

Die zweite Buchung ist eine explizite Abschreibungs-Buchung, die die Summe aller bisher erfolgten Abschreibungen (manuell oder automatisch) darstellt, aber statt auf ein Afa-Konto schlicht auf das Übertragskonto zurückbucht. So wird durch die erstes Buchung der ursprüngliche Anschaffungswert, der Anschaffungszeitpunkt, die beiden Bezeichner, etc., codiert, hingegen durch die zweite Buchung der Restwert.

Für unser Beispiel sind die ersten Eröffnungsbuchungen in der Datei "eroeffnungsSaldi_10_11". Diese sieht ungefähr so aus:

/* created on 2013-06-14_09h54m58
by program bandm_booking (=eu.bandm.book2.base.Main), version 1.2.0
command line = 
bandm_booking (=eu.bandm.book2.base.Main) -Y 09_10 --directory . --closeYear true 
*/
#d2d 2.0 text using eu_bandm_booking  : ledger
  #businessYear 10/11

// Saldenvorträge aus dem letzten Geschäftsjahr 09/10

#move 65
#date 01.07.2010 #text Übertrags-Buchung für Aktivkonto ausstehende Einlagen/Pick
      #voucher Automatische Buchung/Kein Beleg
      #from 1/1  #eur 6250.00  #to 9900/1 #rest 

#move 66
#date 01.07.2010 #text Übertrags-Buchung für Aktivkonto ausstehende Einlagen/Gotowohl
      #voucher Automatische Buchung/Kein Beleg
      #from 1/2  #eur 6250.00  #to 9900/1 #rest 

#move 67
#date 01.07.2010 #text Übertrags-Buchung für Aktivkonto Forderungen aus Lieferungen und L
      #voucher Automatische Buchung/Kein Beleg
      #from 1200/1  #eur 23800.00  #to 9900/1 #rest 


// -------- SCHNIPP --------------------------

#move 81
#date 08.11.2009 #text Erwerb Laptop und Zubehör Dr. Gotowohl
      #voucher Beleg bei Erwerbs-Buchung 32
      #from 400/2  #eur 580.00  #to 9900/1 #rest 
      #newAsset LapTop Siemens-Fujitsu AMILO PA3515
      #OLDLABEL  09/10-32 #deprec_mode lin36
      #prodcom_code 26.20.11.00

#move 82
#date 01.07.2010 #text (=SUMME der bisherigen Abschreibungen)
      #voucher Automatisch berechnete Summe der Abschreibungen
      #from 9900/1  #eur 579.00  #to 400/2 #rest 
      #refAsset 09/10-32



Hat man mit den Beispieldaten den Jahresabschluss durchgeführt, wie beschrieben in Abschnitt 4.2 ("Bedienung der Programmes "), dann liegt dort die entsprechende Datei eroeffnungsSaldi_10_11!

^Inh 3.5 Fortsetzung Beispiel: Beginn des nächsten Jahres

Erst wenn ein Jahresabschluss des Jahres zuvor gemacht worden ist, kann das Programm die Buchungen des nächsten Jahres verarbeiten.
Genauer: Wenn das zu verarbeitende Jahr das erste Geschäftsjahr überhaupt ist, wie es aus dem Eintrag first_year in der Datei
config deklariert ist, dann darf keine Datei mit Eröffnungsbuchungen vorliegen.
Wenn hingegen das Jahr ein späteres ist, dann muss eine solche vorhanden sein.
Der Name dieser Datei ergibt sich, wie erwähnt, durch Einsetzen der Jahreszahl(en) in den Wert von filenametemplate_opening aus der Datei config.

Im unserem Beispiel kann die zweite Journal-Datei (10/11) dann geöffnet und überprüft werden, wenn das erste Jahr (09/10) abgeschlossen worden ist und deshalb die Datei mit den Eröffnungsbuchungen bandm_booking/examples/sandsackGmbH/eroeffnungsSaldi_10_11 vorliegt.

Wie o.e. ist der Beginn des neuen Journals die einzige Stelle, wo eine Lücke in der Reihenfolge der Buchungen erlaubt ist. Wir empfehlen auf eine neue Hunderter- oder Tausender-Gruppe zu springen. Es kann ja immer vorkommen, dass man (natürlich nur solange man nichts veröffentlicht oder angemeldet hat) noch Korrekturbuchungen wegen beim Abschluss entdeckter Fehler nachtragen will, obwohl die Geschäftstätigkeit des neuen Jahres bereits begonnen hat. Diese Korrekturbuchungen sind immer besser im selben Journal wie die Bezugsbuchung, weil dann die automatische Konsistenzkontrolle gewährleistet ist, siehe Abschnitt 3.3.17 ("Dateisicherung, Radierungsverbot und Korrekturbuchungen ").

^Inh 3.5.1 Weitere Buchungsbeispiele

Im letzten Jahr haben wir jeden Buchungs-Typ möglichst nur einmal aufgeführt, so dass das gesamte Journal selbstverständlich kein realistisches Bild bietet!
So würden z.B. noch mehrfach Festgeld-Zinsen ausgezahlt (oder auch fällig) und viel öfter anrechenbare Vorsteuer erstattet werden.

Man sieht aber sehr schön, wenn man sich die Datei ../../examples/sandsackGmbH/eroeffnungsSaldi_10_11ansieht, oder das Programm für das Jahr 10/11 mit dem Befehl "make demo_interactive_10_11" startet, wie die Bestandskonten über den Jahreswechsel übertragen werden.

Im diesem zweiten Jahr nun sind einige Buchungstypen zum ersten Mal möglich. Wir geben hier nur eine kurze Charakterisierung. Die Details finden sich im Quelltext des zweiten Journals.

  1. Auflösung der aktiven Rechnungsabgrenzung sofort.
  2. Auflösung der passiven Rechnungsabgrenzung bei Abnahme der Leistung durch den Kunden.
  3. Zahlung von Steuern für das vergangene Jahr, unter Verrechnung mit den verschiedenen Abschlagszahlungen.
  4. Endgültige Abschreibung des Schrott-Lap-Tops, er verschwindet nach "make demo_bilanz_10_11" aus dem Inventar.

Dieses zweite Journal ist bewusst sehr rudimentär gehalten. Ein Jahresabschluss ist mittels "make demo_bilanz_10_11" oder "make demo_bi_10_11" nichtsdestotrotz möglich, und recht instruktiv.

Leser und Leserin seien aufgefordert, diese zweite Journal-Datei zur Übung beliebig fortzuschreiben. Eine Rekonstruktion der originalen Beispieltexte ist über das "Hilfe-Menü" (wenn on-line) möglich.

^Inh 4 Technische Aspekte von BandM booking

^Inh 4.1 Starten des Programmes

Die Programm BandM booking ist als Java-Applikation realisiert.

Die einfachste Art, es zu starten, geht über "Java Web Start". Dafür gibt es diese "jnlp"-Datei.

Sie kann aufgerufen werden, indem ein solches Link einem entsprechend konfigurierten Browser einfach angeklickt wird, oder durch einen expliziten Kommandozeilenbefehl

  javaws http://bandm.eu/metatools/download/bandm_booking.jnlp

Allemal startet die Jnlp-Datei diese "jar"-Datei.

Sie kann auch heruntergeladen und direkt von einer Kommandozeile aus gestartet werden:

  java -jar bandm_booking.jar  <KOMMANDOZEILENPARAMETER, s.u.>

Wenn man sich die Quellen herunterlädt und das Compilationssystem ans Laufen bringt (s.u. Abschnitt 4.3 ("Herunterladen von Quellen, Beispiel und Dokumentation")), dann kann selbstverständlich auch das Compilat (die erzeugten class-Dateien) ausgeführt werden. Zum Compilieren und Ausführen muss aber Zugriff auf die benötigten meta-tools-Laufzeit-Klassen bestehen (die meta-tools-Compiletime-Werkzeuge werden nicht benötigt, da deren Ausgaben in der Quelltextdistribution enthalten sind.)
Zu diesem Zweck kann o.e. jar-file verwendet werden.

^Inh 4.2 Bedienung der Programmes

Die Applikation kann mit Kommandozeilenparametern oder durch ein GUI kontrolliert werden.

Die Kommandozeilen-Parameter sind...

( Definition in Datei ../../src/eu/bandm/book2/base/options.xml )

-C --closeYear
  Ob das Programm einen Jahresabschluss erstellen soll.
-D --directory
  Angabe der Verzeichnisses in dem ALLE Dateien zu finden sind. Besonders eine Konfigurationsdatei mit dem Namen ''config'', die dann auf weitere Dateinamen verweist.
-i --interactive
  Ob das Programm das interaktive Betrachten der Daten (qua GUI) starten soll.
-v --version
  Zeige Versionsnummer an
-Y --businessYear
  Wenn das Geschäftsjahr dem Kalenderjahr entspricht, dann die letzten beiden Ziffern der Jahreszahl. Sonst diese Ziffern von beiden Kalenderjahren, in denen das Geschäftsjahr liegt, verbunden mit einem Zeichen, also wie ''08/09'' oder wie ''10-11''.

Wird die Option "--closeYear" gesetzt, dann wird ein Jahresabschluss mit allen Dateien generiert, siehe Abschnitt 3.4 ("Fortsetzung Beispiel: Jahresabschluss und Bilanz ").

Werden gar keine Kommandozeilen-Parameter angegeben, oder der Parameter --interactive, dann wird das GUI gestartet, ggfls. nach dem Jahresabschluss oder nachdem das Beispiel geladen wurde.

Wird also nur das --businessYear und das --directory angegeben (ohne GUI-Start und Jahresabschluss), so wird nur der Konsistenztest durchgeführt.

Wenn das GUI läuft und die Konsistenzprüfung erfolgreich war, kann auch aus dem "Datei"-Menu der Jahresabschluss durchgeführt werden. Daürberhinaus kann GUI zur Zeit nur gelesen werden. Es ist mit Karteireitern organisiert und hat folgende Seiten:

  1. Der Kontenplan mit allen Kontengruppen und Unterkonten, Nummern, Titeln und aktuellen Salden.
    Soll-Saldi sind positiv, Haben-Saldi negativ.
    Die Kontenklasse sind hier und anderwo durch Hintergrundfarben gekennzeichnet:
    aktiv weiß
    passiv grau
    aufwand rot
    ertrag grün

    Kommentare erscheinen nur als tool-tips, wenn der Mauszeiger auf dem Kontentitel ruht.
  2. Buchungen in zeitlicher Reihenfolge, mit Nummer, Kalenderdatum, Text und allen beteiligten Konten und Summen. Die Hintergrundfarben für letzter sind wie oben.
    Automatische Buchungen (Eröffnungs- und Abschlussbuchungen) erscheinen ausgegraut.
    Der Kommentar der Buchung erscheint als Tooltip auf ihrer ersten Zeile.
    Korrekturbuchungen zeigen in auffälligem Vordergrund-Rot die Nummer der Originalbuchung.
  3. Unter "Konto" finden sich die T-Konten-Blätter. Zuerst muss man eine Kontengruppe auswählen, dann das Unterkonto. Die Spalten sind: Buchungsnummer, Datum, Betrag, andere Beteiligte Konten (Gegen- oder Split-Konten) im Soll, im Haben, Buchungstext.
    Als Tooltip auf den Nummern der Gegenkonten erscheint deren vollständige Bezeichnung.
    ((Die Kommentare der Buchungen fehlen.))
  4. Das Inventar zeigt alle Assets (siehe Abschnitt 3.3.16 ("Investitionen, Inventar und (Sonder-)Abschreibungen ")) mit ihrem generierten Id, der Beschreibung, den beteiligten Konten (Aktiv- und Afa-Konto), dem momentanen Buchwert, etc.
    Dazu die Anschaffungsbuchung, und die akkumlierten Abschreibungen, wie sie als Eröffnungsbuchung in das aktuelle Geschäftsjahr einging.
    ((Die Kommentare der Anschaffungsbuchungen etc. fehlen.))
  5. Dann die Liste aller Meldungen, also Logs, Errors und Warnings, wie vom Programm generiert.
  6. Dann die Optionen, mit denen das Programm gestartet wurde.
    Falls die Journal-Koordinaten leer sind, also noch kein Journal geladen wurde, können die entsprechenden Felder ausgefüllt werden, und mit dem "Ladeknopf" der Ladeprozess gestartet.
    Hingegen wenn ein Journal geladen ist, so können die Optionen nicht mehr verändert werden, aber es kann mit einem anderen Knopf eine neue Instanz des Programmes angefordert werden, mit einer leeren Options-Maske, über die dann ein weiteres Journal (derselben oder einer anderen Unternehmung!) geladen werden kann.

^Inh 4.3 Herunterladen von Quellen, Beispiel und Dokumentation

Programmquellen, oben beschriebenes Beispiel und die Dokumentationstexte können aus dem "Hilfe"-Menü des Programmes heruntergeladen werden.

Der Benutzer wird aufgefordert, die Stelle im Dateisystem anzugeben, wo diese abgelegt werden sollen. Falls das Programm unter Java Web Start läuft, dann kann es sich diese Stelle merken. Wird es darauf später ohne jeden Kommandozeilen-Parameter wieder gestartet, dann beginnt es gleich das Laden des Beispiels.

Ansonsten kann das Beispiel wie jeder andere, möglicherweise daraus abgeleitete, Datensatz mit GUI oder Kommandozeilen-Parameter geladen werden, wie soeben beschrieben.

^Inh 4.4 Übersetzen der Quellen, Make-Targets für die Beispiele

Um die Quellen zu übersetzen braucht man

  1. einen Java Compiler
  2. ein Gnu-Make
  3. eine Bash-Umgebung

Sei $(DOXS) das Verzeichnis, in welches Dokumentation, Quellen und Beispiel kopiert wurden. Dann muss als nächtes in $(DOXS)/etc eine Datei "config.mk" erzeugt werden, indem die Datei "config.mk.template" kopiert und entsprechend editiert wird.
(Die ANTLR bibliothek ist nicht notwendig, weil die Ausgaben der compile-time metatools inkludiert sind, weil diese eh in vielen Fällen nicht vollständig zugreifbar sein werden.)

Um die Laufzeit-Klassen, die meta-tools benötigt, zu inkludieren, kann das jar-File der Distribution benutzt werden, s.o. Abschnitt 4.1 ("Starten des Programmes").

Die Makefiles definieren die notwenigen Maketargets.

Insbesondere können dann auch die Beispieldateien geladen und behandelt werden über die Kommandozeilen-Eingaben

  make demo_interactive_09_10
   // --> startet GUI mit dem Journal Sandsack GmbH 09/10
  make demo_bilanz_09_10
   // --> erzeugt den Jahresabschluss für Sandsack GmbH 09/10

^Inh 4.5 Aufbau des Programmes

Der Programmtext ist Teil der Distribution, wie sie nach obiger Beschreibung heruntergeladen werden kann. Er ist hinreichend genau dokumentiert, was auch in die hier parallel liegende API-Dokumentation einfließt.

Die internen Programmbezeichner sind allemal am "Computer-Englisch" orientiert. Dies gilt auch für die XML-Tags, also die Elementbezeichner, die der Benutzer in die verschiedenen Dateien eintragen muss.

Die Sprache der Interaktion durch die graphische Oberfläche und die der Fehlermeldungen ist prinzipiell wählbar, da überall konsequent das Modul <metatools>/muli verwendet wird. Unterstützt wird allerdings zur Zeit nur Deutsch.

Alle Konten müssen zur Zeit in EURO geführt werden. Es ist durchaus geplant, die Währung global, oder sogar je Kontengruppe, wählbar zu machen, aber dies ist noch nicht implementiert.

Die Daten des Programmes liegen als d2d-encodierte XML Dateien vor. Sie werden vom d2d Interpreter in sog. "SAX"-Ereignisströme übersetzt und diese in ein tdom-Modell.

Wichtige, aber nicht alle, Angaben werden aus diesem extrahiert und in ein umod-Modell übersetzt, z.B. die numerischen Daten aller Buchungs-Sätze, da diese dann einfacher sortierbar und zugänglich sind. Insbesondere werden alle Geldbeträge als "Big Decimals" realisiert, was Rundungsfehler vermeiden hilft.

Die Definition des umod Modelles findet sich in ../../src/eu/bandm/book2/book/Book.umod.

Auf all diesen Daten werden weitere Konsistenzüberprüfung durchgeführt. Deren Ergebnisse werden sowohl auf dem Terminal als auch im "GUI" ausgegeben. Wenn schwerwiegende Verletzungen der Konsistenzbedingungen aufgetreten sind, wird die weitere Verarbeitung der Daten verweigert.

  +------------+           \
  | config     |            \
  | +------------+           \           
  | | Kontenplan |            \          +--------+           +--------+
  | | +------------+     d2d   |   SAX   | TDOM   |  Reducer  | umod   |
  | | | Eröffnung  |     decode| ======> | Modelle|   .visit()| Modell |
  | | | +------------+         /         |        | --------> |        |
  | | | | Journal_<> |        /		 +--------+           +--------+
  +-| | |            |       /            \____________  ____________/      
    +-| |            |      /                          \/ 
      +-|            |                       +--------------+ 
        +------------+                       | weitere      |
                                             |Konsistenz-Prfg.
					     +--------------+
          			            /    \	          erweiterbare
         			           /      \		    Klassen-Bib:
          			 +--------+       +--------+      +---------+ 
     		        	 |interakt.       | Bilanz | <=== |+---------+  
     			         | Graphik|       |Druckvorl.     ||+---------+
         			 |        |       |        |      +|| Afa-    |
        			 +--------+       +--------+       +| Methode |
                                                   +--------+       +---------+
                                                   |Eröffnng|
                                                   | Folgejhr
                                                   +--------+

Die wichtigsten Objektklassen des umod-Modelles und ihre Beziehungen stellen sich dar wie folgt:

                   +------------------------+ 
                   | Book                   |	
                   +------------------------+
                   |_num_|   |_id_| |_num_|____________
                  /             \                      \
                 v 1             \                      v 1
  +-------------+                 \       		+-------------+ 
  |AccountGroup |		   v 1 		        | Move        |
  +-------------+              +------------+	        +-------------+
  |cls:(a|p|e|k|kn)	       | Asset      |---------> |date:calendar|
  |num:int      | 1 activeAcc  +------------* bookings +|num:int      |
  |title:string | <----------  |titel,code, |           |text:string  |
  |             | <----------  |deprec_mode |          	|CORR:OPT int |
  +-------------+ 0..1 deprAcc |prodCom:string          +-------------+
          |1	 	       |            |              1|       |1	 
          |	 	       +------------+          left |       | right 
          |+	 		                           +|       |+	 
  +-------------+		                        +-------------+
  |  Account    |		                        |  BPart      |
  +-------------+ *                                   1 +-------------+
  |num:int      | <------------------------------------ |amount:EUR   |
  |title:string |		                        |isLeft:bool  |
  +-------------+                                       +-------------+

Aus diesen Daten werden, ja nach angewähltem Modus, dann die Bildschirm-Darstellung abgeleitet, basierend auf JFC/Swing.

Im anderen Modus wird, wie oben erwähnt, die Bilanz-Druckvorlage erstellt.
Dies ist zur Zeit ein LaTeX Quelltext Dokument.
Der Name der neu zu generierenden Datei wird aus dem Datei-Namen-Template abgeleitet, welches im "filetemplate_report"-Element abgeleitet ist, indem dort die Jahreszahl des Geschäftsjahres eingesetzt wird, resp. beide Jahreszahlen im Falle des "abweichenden Wirtschaftsjahres".

^Inh 4.6 Mögliche weitere Ausbaustufen

Viele Einzelheiten kann man sich als wünschenswert vorstellen. Die die uns eingefallen sind, für die wir aber weder Lust noch Kapazität haben, seien hier ohne weitere Wertung oder Ordnung aufgelistet.

  1. Die Internationalisierung könnte vorangetrieben werden, ins besondere über die Kommandozeile anwählbar.
  2. Die Internationalisierung der graphischen Benutzeroberfläche (GUI) sollte dynamisch sein, d.h. zur Laufzeit umschaltbar.
  3. Es können mehr als eine Währung unterstützt werden. Im Kontenplan muss dann je Kontengruppe eine solche festgelegt werden, und evtl. eine Default-Währung. Spezielle Arten von Buchungen würden die Konvertierung von Geldwerten repräsentieren.
  4. Das GUI sollte mehr Navigierungsmöglichkeiten zwischen Konten und Journal erlauben.
  5. Das GUI sollte Suchfunktionen (in Buchungstext, Kommentar, etc) bieten.
  6. Im GUI kann ein Fenster für ein Konto "abgetrennt" werden, und neben dem Hauptfenster festgehalten. Im Hauptfenster wächst dann ein neues, umschaltbares Konten-Fenster nach.
  7. Die Fenster für ein Kontenblatt können die "Tee-Linien-Struktur" deutlicher ausprägen, durch dicke graue Trennlinien, etc.
  8. Im Journal aller Buchungen können dicke graue Trennlinien die Gruppen der Eröffnungsbuchungen, der manuellen, der automatischen Abschreibungen und der Abschluss-Buchungen trennen.
  9. Graphische Darstellung für den Saldo-Verlauf von Bestands- und Erfolgskonten über die Zeit.
  10. Simulieren vergangener Zeitpunkte, also Darstellung der Kontenstände an (/Berücksichtigung der Buchungen bis zu) einem bestimmten Datum.
  11. Alle Unterkonten einer Kontengruppe können vereinigt, wie ein einziges Konto aufgelistet oder dargestellt werden.
  12. Die Kontenfenster können Pfeile "nach links", "nach rechts" zum Navigieren in den Kontengruppen und den Unterkonten enthalten.
  13. Der Quelltext des Journals könnte dargestellt werden. Das sogar "gerendert", also mit anklickbaren Links, so wie in unserem "Dtd-Renderer". Das könnte sogar die momentaten Tabellen-Darstellung des Journals ersetzen, jedenfalls lustig ergänzen.
  14. Das Generieren des Druckvorlage Bilanz kann über eine XML-Zwischenschicht geschehen. Das würde evtl. mehr Konfigurationsfreiheit erlauben.
  15. Die Druckvorlage Bilanz könnte ohne LaTeX direkt in Pdf generiert werden.

^Inh Wichtige projekt-interne Links

Hier nochmal zum schnellen Anklicken die wichtigsten projekt-internen Links.

  1. http://bandm.eu/metatools/download/bandm_booking.jnlp Java Web Start Jnlp-Datei zum Starten der Applikation
  2. http://bandm.eu/metatools/download/bandm_booking.jar Das Jar file mit dem lauffähigen Code des Programmes
  3. ../api/index.html Die API-Dokumentation relativ zu dieser Datei hier.
  4. ../../src/eu/bandm/book2/xml/eu_bandm_booking.dd2 Definitionsdatei aller beteiligten d2d/xml Formate
  5. d2d_documentation_eu_bandm_booking_dynamic_user_de/index.html Automatisch generierte Dokumentation aller beteiligten d2d/xml Formate
  6. ../../src/eu/bandm/book2/xml/eu_bandm_booking.dtd Definitionen im DTD-Format, abgeleitet von .d2d
  7. ./eu_bandm_booking_rendered_dtd.html Dasselbe, aber gerendert und navigierbar.
  8. http://bandm.eu/metatools/docs/usage/d2d.html Die d2d-Dokumentation im Netz.
  9. http://bandm.eu/booking/index.html Die Dokumentation von BandM booking im Netz.
  10. http://bandm.eu/booking/doc/api/index.html Die API-Dokumentation von BandM booking.im Netz.
  11. http://bandm.eu/metatools/docs/usage/getit.html Die metatools-download-Seite.

^Inh Bibliographie

[buchench]
Reto Sutter
Geschichte der doppelten Buchhaltung
buchen.ch, theWeb, 2011
http://www.buchen.ch/Geschichte_der_doppelten_Buchhaltung.pdf
[metatools_d2d]
Markus Lepper und Baltasar Trancon
BandM meta_tools users' documentation : d2d --- XML made useful for authors
theWeb, 2008--2012
http://bandm.eu/metatools/docs/usage/d2d.html
[gobs]
Bundesministerium für Finanzen
Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS)
Bundesministerium der Finanzen, Berlin, 1995
http://www.bundesfinanzministerium.de/nn_314/DE/BMF__Startseite/Service/Downloads/Abt__IV/BMF__Schreiben/015,templateId=raw,property=publicationFile.pdf
[penndorf]
Balduin Penndof
Die italienische Buchhaltung im 14. und 15. Jahrhundert und Paciolis Leben und Werk
in: [pacioli]pg.1-82,

[pacioli]
Luca Pacioli
Abhandlung über die Buchhaltung, 1494
Stuttgart, 1997

[prodcom]
Prodcom List
European Commission, Eurostat, Luxembourg, 2010
http://epp.eurostat.ec.europa.eu/portal/page/portal/prodcom/introduction
[skr04]
Datev
Art. 11175 Kontenrahmen DATEV SKR 04 / 2012
Nürnberg, 2012
http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=61919
[xml]
Extensible Markup Language (XML) 1.0 (Fifth Edition)
W3C Recommendation 26 November 2008
W3c Consortium, Cambridge, MA, Sophia-Antipolis, Tokyo, 2008
http://www.w3.org/TR/2008/REC-xml-20081126/




made    2015-03-25_18h10   by    lepper   on    linux-q699.site          Valid XHTML 1.0 Transitional Valid CSS 2.1
produced with eu.bandm.metatools.d2d    and    XSLT