[gnucash-de] Steuerrelevanz

[Christian Stimming]

Am Mittwoch, 19. September 2007 23:42 schrieb Rolf Leggewie:
> >> unabhängig aktuell verfügbarer GUI-Optionen; Ist es möglich ein Konto im
> >> doppelten Sinne als steuerlich relevant zu markieren?  Die meisten
> >> Umsatzkonten beispielsweise sind ja sowohl für Einkommens- wie auch
> >> Umsatzsteuer relevant.  Für den Augenblick fummele ich notfalls gerne
> >> auch im XML-Code rum.
>
> |  <gnc:account version="2.0.0">
> |    <act:name>Abziehbare Vorsteuern Inland</act:name>
> |    <act:type>ASSET</act:type>
> |    <act:description>UstVa Zl. 55, Kz. 66</act:description>
> |    <act:slots>
> |      <slot>
> |        <slot:key>tax-related</slot:key>
> |        <slot:value type="integer">1</slot:value>
> |      </slot>
> |      <slot>
> |        <slot:key>tax-US</slot:key>
> |        <slot:value type="frame">
> |          <slot>
> |            <slot:key>code</slot:key>
> |            <slot:value type="string">K66</slot:value>
> |          </slot>
> |        </slot:value>
> |      </slot>
> |    </act:slots>
>
> Ist das eventuell schon als relevant für Einkommens- und Umsatzsteuer
> markiert?  EK-Steuer über <slot:key>tax-related</slot:key> und
> Umsatzsteuer über <slot:key>tax-US</slot:key>.  Wie generiere ich dann
> einen Report, mit dem ich was für die Einkommenssteuer anfangen kann?

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

PS: Ggf. ist die Erklärung oben wohl schon ein Fall für's Wiki :-)