De/Projekte

From GnuCash
Jump to: navigation, search

Zurück zur Hauptseite

Auf dieser Seite sollen die Anforderungen für künftige Verbesserungen zusammengetragen werden.

Insbesondere müssen noch die Projekte von linuxwiki.de/GnuCash/WeiterEntwicklung 3. Gewünschte neue Features und http://linuxwiki.de/GnuCash/EuerGc übertragen werden.

Erledigte Projekte sollten dann nach De/Archiv verschoben werden.

Allgemein

GUI (Benutzeroberfläche, Ergonomie)

Vorschläge wie die Ergonomie verbessert werden könnte, um ein flüssigeres Arbeiten zu ermöglichen.

  1. Nach schließen des Reiter "Suchergebnisse" -> zurück in Ursprungskonto (GnuCash 2.5.6)
    • Ausgangssituation:
      • Mehrere Konten "offen", d.h. oben sind mehrere Reiter zu sehen
      • Befindet man sich nun in einem Konto (Reiter) auf einem Datensatz und betätigt Ctrl+F, dann wird hinter dem letzten Reiter der neue Reiter "Suchergebnisse" geöffnet.
      • Dort holt man sich nun die gewünschten Informationen und schließt "Suchergebnisse"
    • Ergebnis:
      • man befindet sich plötzlich im allerletzten Reiter (Konto)
      • Man muss nun wieder den Reiter suchen aus dem man ursprünglich kam
    • Besser wäre...
      • ...es würde wieder der Reiter (Konto) aktiv, aus dem man kam.

Geschäftlich

Dieser Abschnitt beschreibt die Situation in Deutschland und darf gern um Abschnitte für andere Länder ergänzt werden.

GOB - Grundsätze ordnungsmäßiger Buchführung

Sobald ein Unternehmen gewisse Grenzwerte überschreitet, unterliegt es der Buchführungspflicht. Spätestens dann sind die Grundsätze ordnungsmäßiger Buchführung zu beachten. Als allgemeine Einführung empfiehlt sich, wie immer, der Artikel in der Wikipedia. DV-technisch sind weitere Papiere des deutschen Bundesfinanzministeriums von Interesse:

GoBD

Seit 1.1.2015 gelten die Grund­sät­ze zur ord­nungs­mä­ßi­gen Füh­rung und Auf­be­wah­rung von Bü­chern, Auf­zeich­nun­gen und Un­ter­la­gen in elek­tro­ni­scher Form so­wie zum Da­ten­zu­griff (GoBD) - Stand 28.11.2019, sowie die Ergänzenden Informationen zur Datenträgerüberlassung - Stand 28.11.2019. Technische Informationen zu den Datenformaten alias "Beschreibungsstandard" sind hier zu finden.

Jahresabschluss

Seit ungefähr GnuCash 2.2.5 gibt es eine Funktion "Closing Books", welche alle Aufwands- und Ertragskonten in ein Eigenkapitalkonto saldieren - eine einfache Möglichkeit, Aufwand und Ertrag zu Beginn eines Geschäftsjahres wieder auf 0 zu setzen, ohne die historischen Daten zu verlieren.

Hier müsste nochmal jemand prüfen, inwieweit die den geschäftlichen Anforderungen genügt.

Kommentar:

Für das Jahr 2023 habe ich diese Funktion erfolgreich genutzt um eine Bilanzen zu erstellen.

Aus besonderen Umständen war es notwendig, auch zur Mitte des Jahres eine Zwischenbilanz zu erstellen. Zusätzlich mussten auch für verschiedene Teilbereiche separate Bilanzen erstellt werden.

So musste diese Funktion auch mehrfach für den gleichen Zeitraum durchgeführt werden, nachdem immer wieder Korrekturbuchungen durchgeführt werden mussten.

Dies konnte ohne jegiche Probleme erfolgen.

Kontenrahmen

Für Definition und theoretischen Hintergrund siehe De/Referenz#Kontenrahmen.

Die folgenden Kontenrahmen werden zur Zeit mehr oder weniger aktiv aktuell gehalten:

  • Der SKR04 wird von einigen Aktiven der Gemeinschaft gepflegt. Insbesondere finden da auch Experimente zur UStVA statt. Zur aktuellen Diskussion geht es hier.
  • Der „Kontenrahmen für die Wohnungswirtschaft“ ist auf dem Stand von 2004 seit Februar 2008 in den Versionen ab 2.2.9 enthalten. -- CHF (Diskussion) 18:41, 15 April 2018 (UTC)
    • Eine Aktualisierung auf den Stand von 2012 ist fertig und wird demnächst in Gnucash 3.x verfügbar sein.
  • Der SKR49 der Datev für Vereine und gemeinnützige Organisationen ist bereits sehr vollständig und somit gut einsetzbar und wird gerade von mir aktualisiert. -- CHF (talk) 18:02, 14 April 2018 (UTC)

Will man einen vorhandenen überarbeiten oder einen neuen bauen, solle man Account_Hierarchy_Template (englisch) lesen und ggf. ergänzen.

UStVA

Gesetzliche Vorgaben

Die Umsatzsteuer-Voranmeldung (UStVA) hat inzwischen ausschließlich Online zu erfolgen.

Dies ist ohne zusätzliche Software möglich.

Benutzerwünsche

Ich schlage folgende Änderungen vor: (Prio)
(A) SKR04, SKR04 mit 19%
(A) Openoffice als Reporting Engine
(B) Buchungsautomat für Belege (MwST, Trinkgeld, 30/70 Regel)
... sonnst ist das Programm klasse. Ich nutze es grade in meiner kleinen GmbH.

Technische Details

Christian Stimming am 22.09.2007:
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: https://code.gnucash.org/docs/MAINT/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 :-)

Anmerkung: Irgendwo wurde mal auf Taxbird/libgeier verwiesen. Dessen Nachfolger ist seit 2012 Geierlein.

Ein Benutzer, zwei Steuernummern

Eine unterschiedliche Steuernummer gibt es immer schon dann, wenn das zuständige Finanzamt für die Betriebsstätte nicht dasselbe wie für den Wohnsitz ist.

aus: https://lists.gnucash.org/pipermail/gnucash-de/2018-November/010496.html

PEPPOL: Pan-europäisches, elektronisch unterstütztes Beschaffungswesen

Vom Pan-European Public Procurement OnLine wäre zunächst das Rechnungswesen interessant. Es könnte zu einer Vereinheitlichung der Rechnungen beitragen. Offizielle Seite: https://peppol.org/

Zurück zur Hauptseite Zurück zur Bedienung
Retrieved from "https://code.gnucash.org/wiki/index.php?title=De/Projekte&oldid=22255"