Latest revision as of 15:54, 28 September 2020

Zurück zur Hauptseite

Einnahme und Überschuss Rechnung

Einführung

Auf dieser Seite werde ich versuchen, meine (hoffentlich ultimativ erfolgreichen) Schritte zu dokumentieren, um mit Gnucash meine geschäftlichen Bücher zu führen. Ich möchte mit einem Bericht aus Gnucash heraus meine Einnahmenüberschußrechnung (EÜR) und die Umsatzsteuervoranmeldung erzeugen. Ich verwende gnucash unter ubuntu.

Derzeit (2.4.x) ist GnuCash noch für Sollversteuerung ausgelegt. Zur aktuellen Entwicklung für Ist-Verteuerung siehe Cash Based Accounting bzw. Bug #95700: accrual and cash sales tax (VAT/GST) reporting in business invoices.

Ergänzung Febr. 2011: weil EÜR vom Zufluss-Abfluss-Prinzip ausgeht ist es nicht möglich, bei Rechnungen das Rechnungsdatum als Buchungsdatum zu verwenden, sondern das Datum der Geldtransaktion. Konten für Forderungen bzw. Verbindlichkeiten sind damit eigentlich hinfällig, aber das Problem ist, dass gnucash Rechnungen nur bucht, wenn es ein Gegenkonto von der Art Forderungen bzw. Verbindlichkeiten gibt. Alternative: gänzlich ohne Rechnungsmodul arbeiten. Die saubere Lösung ist hier http://www.rechnungswesenforum.de/umstellung-auf-opos-buchung-8331.html beschrieben, und zwar ausgehend von OPos (Offene Postenrechnung). Das einzige, was geändert werden muss: die Konten 1400 bzw. 1600 (SKR03) müssen als Aufwand respektive Erlös gebucht werden. Das Gleiche gilt für Umsatzsteuerkonten (Hint: verwende eine Unterkategorie bei Aufwendungen: "Ausgaben nur bei EÜR" und sinngemäß bei den Erlösen, damit die SKR-Nummern der umdefinierten Konten nicht verwaist vorkommen, weil sie dann eben in die neuen Unterkategorien gesammelt werden. Jede bestehende Buchführung kann somit einfach von EÜR auf Bilanzierung umgestellt werden und umgekehrt. Natürlich gibt es so noch keine amtliche EÜR-Vordrucke, aber die sind lt. Münsteraner Richterspruch ohnehin nicht mehr vorgeschrieben.

Vorstehendes ist (auch bei Win-version-2.4.2) leider noch nicht realisierbar, denn sobald die Konten 1400 und 1600 nicht mehr als Kapitalkonto deklariert werden, entfällt die Möglichkeit als Kontoart "offene ...." und damit die Möglichkeit, eine Rechnung ein Gegenkonto zuzuweisen... Es gibt aber folgendes Workaround gemäß Obigem, indem die Konten temporär eine anderes Typ zugewiesen bekommen:

Gnucash für EÜR-Rechnung SKR03 umkonfigurieren:

Alle umzuändernde Konten in nachfolgend angegebenen Platzhalterkonten unterbringen: (Reihenfolge nach Kontenplan, Platzhalterkonten mit EÜR ggf. erstellen)

Aktiva => Finanzkonten 1 =>
- 1400 Forderungen.... (jetzt Typ "offene Forderungen")
  umändern nach Erlöse u. Erträge 2/8 => Einnahmen nur bei EÜR, Typ "Erträge"
- 1571 Abziehbare Vorst. 7%. ... (jetzt Typ "Aktiva")
- 1575 Abziehbare Vorst. 19%. ... (jetzt Typ "Aktiva")
  umändern nach Aufwendungen 2/4 => Ausgaben nur bei EÜR, Typ "Aufwendungen"

Passiva => Umsatzsteuer =>
- 1771 Umsatzsteuer 7% ... (jetzt Typ "Fremdkapital")
- 1775 Umsatzsteuer 19% ... (jetzt Typ "Fremdkapital")
  umändern nach Erlöse u. Erträge 2/8 => Einnahmen nur bei EÜR, Typ "Erträge"
- 1780 Umsatzsteuer Vorausz. ... (jetzt Typ "Fremdkapital")
  umändern nach Aufwendungen 2/4 => Ausgaben nur bei EÜR, Typ "Aufwendungen"
Passiva => Verbindlichkeiten =>
- 1600 Verbindlichk. ... (jetzt Typ "Fremdkapital")
  umändern nach Aufwendungen 2/4 => Ausgaben nur bei EÜR, Typ "Aufwendungen"

Hinweis: Erst Kopie der Datei machen, und damit die obigen Änderungen einpflegen. Mit dieser Kopie die Berichte erstellen. Immerhin wird es nicht möglich sein, so Rechnungen zu erstellen (wg. 1400/1600).

Nachher prüfen, ob alles bei den beiden "nur bei EÜR"-Konten drin ist.

Weitere Anmerkungen

Wissenswertes zu OPos: Leitfaden zum Thema: Wechsel der Gewinnermittlungsart (pdf), Kapitel 4.

Die von gnucash zur Verfügung gestellten Business-Funktionen scheinen sehr stark auf amerikanische Gepflogenheiten zugeschnitten zu sein und sind daher wohl nicht 1:1 auf eine deutsche Unternehmung anwendbar, wobei aktuellere Versionen durchaus besser anzuwenden sind.

Neukompilation Gnucash

Die notwendigen Funktionen scheinen noch nicht ausreichend getestet zu sein und sind daher standardmäßig deaktiviert (siehe aber auch discussion page, Abschnitt LOCALE_SPECIFIC_TAX?). Die Windows-binaries haben dieses Feature bereits aktiviert, unter Linux/Unix muß in der Regel Gnucash aus den Quellen neu kompiliert werden. Das ist hier im wiki eigentlich recht vernünftig, wenn auch etwas unübersichtlich beschrieben. Wichtig ist, beim Aufruf von configure "--enable-locale-specific-tax" zusätzlich mit anzugeben. Durch einen weiteren Switch "--prefix=$HOME/unstable/gnucash" wird auch sicher gestellt, daß gnucash das Hauptsystem in Ruhe läßt und alle Dateien im Heimatverzeichnis des Benutzers ablegt, wo diese dann zum Testen bereit stehen. (Niemals als Benutzer root die Kompilierung durchführen!) (Febr. 2011: Dieser Abschnitt ist noch immer aktuell --Cstim 09:54, 16 February 2011 (UTC))

Noch ein weiterer Switch sorgt schließlich dafür, daß auch die Schnittstelle zu Python sowie Erweiterungen für HBCI mit erstellt werden. Am Ende sieht mein Aufruf im Quellverzeichnis von gnucash so aus:

svn up
./autogen.sh
make clean
rm -Rf $HOME/bin/gnucash-unstable
./configure --prefix=$HOME/bin/gnucash-unstable --enable-locale-specific-tax --enable-aqbanking --enable-python-bindings --enable-dbi
nice make
make install

Aufruf

Nach einem LC_ALL=de_DE.UTF8 ~/bin/gnucash-unstable/bin/gnucash (mein Systemstandard ist sonst en_US.UTF8) stehen dann tatsächlich einige spezifische Funktionen für den deutschen Raum zur Verfügung. Bei meinen früheren Tests war dies noch nicht der Fall.

Kontenrahmen

Ich verwende den SKR04-Kontenrahmen, der mit gnucash ausgeliefert wird.

gnucash personalisieren (Verwendung in .de)

• Datei -> Eigenschaften und dort die relevanten Informationen ausfüllen. Diese werden von verschiedenen Berichten verwendet.
• optional bei Bearbeiten -> Einstellungen -> Voreinstellungen Kontobuch Haken setzen bei "only display leaf accounts"
• Anpassen der Informationen unter dem Menü "Geschäft"
  • Kunden anlegen. Mindestens ein Kunde sollte eingegeben werden, im Zweifelsfalle Barverkauf.
  • Steuertabelle (...)

Steuersachen

Verknüpfung Konto zu Steuer

• Aufrufen des Menüs "Bearbeiten - Steuerrelevante Optionen"
• Folgende Konten müssen als steuerlich relevant markiert und mit dem Bericht zur Umsatzsteuervoranmledung verknüpft werden.
  • A -> B (dummy)
• Aufrufen des Menüs "Berichte - Steuer-Bericht & Elster-Export"

An dieser Stelle bin ich nun auf einige Schwierigkeiten gestoßen, die aber vermutlich leicht und schnell behoben werden können.

Bem.: Die Informationen zu den Feldern des USt-Voranmeldungsformulars werden in den Dateien txf-de_DE.scm und txf-help-de_DE.scm abgelegt. Sie können selbständig durch Editieren der Dateien angepasst werden, sofern dies nicht in der aktuellen Version von GnuCash erfolgt sein sollte. Dabei ist unbedingt darauf zu achten, dass die Anpassungen simultan in beiden Dateien durchgeführt werden. Eine Kompilation ist nicht nötig- --Jannick 17:27, 12 July 2008 (EDT)

Wer Änderungen vornimmt sollte dies bitte auch im bugtracker melden, damit diese in die offiziellen Releases mit einfließen können. --Rolf 13:53, 15 July 2008 (EDT)

UStVa (händische Buchung, nicht empfehlenswert)

Just a note to self from IRC:
(23:47:26) fell: Rolf: genau, die Salden von 38xxx in USTVA eintragen und auf 3840, am Jahresende 3840 -> 3841->3845. Analog 14xx, 4xxx und 5xxx
38xx: zu zahlende Umsatzsteuer
14xx: abziehbare Vorsteuer
4xxx: (betriebliche) Erträge
5xxx: Materialaufwand

UStVa und EkSt

aus der Mailing-Liste

<quote cstimming> Hier ist, was mir im Moment einfällt:

Der <slot:key>tax-related</slot:key> mit dem integer value 1 beziehungsweise 0, wenn der Slot nicht existiert, entspricht genau der checkbox "tax-related"/"steuerrelevant" im "Konto bearbeiten"-Dialog; nicht mehr und nicht weniger. Abgefragt wird dieses Datenfeld in allen taxtxf.scm-Funktionen; Konten, die hier keine Eins haben, werden dann in den Berichten gar nicht weiter berücksichtigt.

Überhaupt werden die Daten in diesen slots von den Funktionen aus Account.c namens xaccAccountGetTaxRelated und folgende gesetzt; von Scheme aus sind jene Funktionen unter dem gleichen Namen erreichbar, siehe deren Benutzung z.B. in ./src/report/locale-specific/us/taxtxf.scm Zeile 183. Die "KVP Slots" werden erklärt hier: http://svn.gnucash.org/docs/HEAD/group__KVP.html , also in den doxygen-Kommentaren im source.

Der US tax sourcecode benutzt also bisher den slot "tax-US/code"; wenn du für den deutschen sourcecode noch weitere Datenfelder benötigst, kannst du die problemlos als weitere kvp-slots hinzufügen. Du kannst denen dann Werte zuweisen, indem du im SKR04-template dies einfach hinzuschreibst; der Zugriff geht dann so, dass du in Account.h und Account.c Funktionen hinzufügst, die sich an den existierenden orientieren (ich würde mich dann später darum kümmern, wo die Funktionen endgültig platziert werden), und dann sind diese Datenfelder auch von Scheme aus erreichbar.

Von der GUI aus erreichbar sind diese Datenfelder natürlich nicht, solange man nicht manuell einen neuen Dialog (um-)gebaut hat, wo für jedes Datenfeld auch ein Eingabefeld existiert so wie momentan in ./src/gnome/dialog-tax-info.c ; aber das halte ich für größeren Aufwand und das wäre erst der übernächste Schritt.

Jetzt zu deiner eigentlichen Frage: Momentan speichert ein Konto nur eine einzelne Nummer, die in taxtxf-de_DE.scm eben als Formularfeld in der UstVA interpretiert wird. Für die Einkommensteuer müsste ein Konto dann eine weitere Nummer haben, die das Formularfeld für die Einkommensteuer ist, richtig? Dann benötigst du genau die obige Erklärung für KVP-Slots, denn dann müsstest du also ein Datenfeld bzw. einen KVP-Slot für die UstVA haben und ein weiteres, neues, für die Einkommensteuer und so weiter.

In Gnucash ist das mit den KVP-Slots alles *möglich*; es wird aber halt doch etwas mehr Aufwand. Mein Ansatz vor zwei Jahren ergab sich aus der Frage, in wieweit man die deutsche UstVA machen kann, *ohne* dabei neue Datenfelder anzulegen, sondern stattdessen ausschließlich die sowieso vorhandenen Strukturen zu nutzen. Ich würde empfehlen, bei diesem Ansatz zu bleiben und deutsche Steuererklärungs-Funktionen in mehreren Schritten zu implementieren: Zuerst also nur eine einzige Erklärung zu unterstützen (mittels der eh vorhandenen Datenfelder), und wenn das tatsächlich funktioniert und auch die Nachfrage da ist, dann (aber erst dann) in einem weiteren Schritt auch mittels zusätzlicher Datenfelder auch weitere Erklärungen zu unterstützen.

Aber wenn du lieber mehrere Sachen gemeinsam implementieren möchtest, werd ich dich nicht davon abhalten. "You have been warned"  :-)

Gruß

Christian </quote>

externe Tools

Die folgenden Werkzeuge erscheinen mir für die geschäftliche Nutzung interessant

• Python Bindings
• anpassbare Rechungensvorlagen von Roman Bertle
• Speichern der gnucash-Daten im SQL-Backend und Reporting über SQL (z.B. Openoffice.org Base). Gnucash ist so vermurkst, dies erscheint mir im Moment die einzige echte Möglichkeit, gnucash in .de professionell zu nutzen)

Was fehlt

• Allgemein
• UStVa-Report zeigt nicht alle Werte an
• SKR04 fitmachen: Zuschlüsselungen UStVa (50% done) und EkSt (0%), Überprüfen durch Dritte (10%)
• Prozess, um SKR-Updates einzuspielen
• Umsatzsteuerautomatik (in gnucash, Hintergründe)

Autor

RolfLeggewie --Rolf 19:34, 11 July 2008 (EDT)

Dies ist ein Wiki, Änderungen willkommen!