Zurück zur GnuCash Wiki Hauptseite


1. GnuCash braucht Unterstützung!

"Meine Arbeitszeit erlaubt es nicht, daß ich weitere Features einbaue -- die Features, die jetzt existieren, sollen ordentlich und fehlerfrei laufen, und damit bin ich genug beschäftigt. Jede neuen Features muß jemand anderes machen." "Wenn jemand sich am programmieren versuchen will, würde ich ihn jederzeit nach Kräften unterstützen." so Christian Stimming, dem wir hier alle verdanken, daß wir mit GnuCash nun überhaupt OpenHBCI Datenaustausch mit der Bank betreiben können.

1.1. Jeder kann mitmachen

Wer weder über Englisch- noch Programmierkenntnisse verfügt, kann z. B. helfen, diese Seiten zu verbessern. Wohl jeder GnuCash-Benutzer hat so seine kleinen Tricks, die leider noch in keiner Dokumentation stehen.

Nahezu jeder einzelne Satz, den ich hier einbringe, kann anderen stundenlange Suche ersparen und umgekehrt. Also bring Deine Erfahrung hier ein!

1.2. Can you read this?

Prima, die deutsche Übersetzung ist nämlich seit Jahren verwaist. Falls Du noch ca. 30 MB Platz auf der Platte hast, kannst Du folgendes machen:

cd
mkdir -p translatio/gnucash
cd translatio/gnucash
svn co http://svn.gnucash.org/repo/gnucash-docs/trunk

und mit dem Übersetzen loslegen. Eventuell muß das Paket Subversion/SVN noch installiert werden.

Das Ergebnis dann einschicken. Details finden sich hier unter Dokumentationsentwicklung.

Falls man 'ne Weile nichts gemacht hat, mit

cd ~/translatio/gnucash
svn info

cd ~/translatio/gnucash
svn up

2. Deutsche Übersetzung

CS: Bitte beim de.po darauf achten, daß patches sich immer auf das aktuelle CVS vom gnucash-1-8-branch des Moduls gnucash beziehen, wogegen gnucash-docs patches sich bitte immer auf das aktuelle CVS vom HEAD branch (d.h. der normale) vom Modul gnucash-docs beziehen.

Eine Änderung in den Worten gab es von Version 1.8.7 auf 1.8.8. Bisher: Geschäftsvorfall (engl. transaction), jetzt: Buchungssatz (und manchmal Buchung); bisher: Buchung (engl. split), jetzt: Buchungsteil. Wenn jemand noch Fehler entdeckt, bitte sofort Mail an ChristianStimming. Ebenso muß noch gnucash-docs angepasst werden; auch hier bitte mail an ChristianStimming. -- ChristianStimming 2003-11-14 22:29:15

2.1. Irrtümer im Englischen

JL: CS schreibt: "Im GnuCash-Kontext ist Journal halt in dermaßen anderer Bedeutung in Benutzung". Das kann ich nicht nachvollziehen. Journal wird im Quellcode nur bei REG_STYLE_JOURNAL, CURSOR_SINGLE_JOURNAL und CURSOR_DOUBLE_JOURNAL (register/ledger-core/split-register.h) verwendet, im englischsprachigen GUI nur als "Transaction Journal" (src/gnome/glade/register.glade.h). Bei allen vier Bezeichnungen dreht es sich um die vollständige=mehrzeilige=mehrteilige Buchungsdarstellung, also genau das, was bei der Papierbuchführung das Journal ist.

2.2. Langfristige Änderungen in der Übersetzung

Da der vorige Abschnitt die Diskussion für bald bevorstehende Änderungen zum Abschluß bringen soll, stehen hier noch Vorschläge, die erstmal noch keinen ausreichenden Konsens (oder Gesamt-Vorschlag) finden.

Intuitive Überschriften: Lieber allgemein Mehrungen und Minderungen anstatt spezifisches wie Abhebung, Lastschrift, Rabatt o.ä. was nur manchmal stimmt.

Aktiv -> Mehrung links (im Soll)
Passiv -> Mehrung rechts (im Haben)

Aufwendungen -> Mehrung links (im Soll)
Erträge -> Mehrung rechts (im Haben)

3. Gewünschte neue Features

3.1. Zum Diskutieren

Folgendes ist auf der e-mail Liste erwähnt worden und soll hier gerne weiter diskutiert werden. Als Anregungen wurden schon einige Dinge vorgeschlagen (hier ohne bestimmte Reihenfolge):

3.1.1. ELSTER

Eine Anbindung an ELSTER realisieren. Ein entsprechendes SDK bekommt man nach Anmeldung.

Siehe dazu

3.1.1.1. Anlauf 2007

Ich habe hier mal einen Absatz eröffnet, um die Wünsche an das Steuermodul zusammenzutragen und hoffe auf gute, eifrige Zusammenarbeit. -- FrankEllenberger 2007-04-22 03:13:34

3.1.1.1.1. UStVA
  1. Zeiträume

Je nach Tätigkeit und Umsatz ist Umsatz- bzw. Mehrwertsteuer monatlich, quartalsweise, jährlich oder garnicht zu erklären und/oder abzuführen.

  1. Betroffene Konten
    • Steuerfreie und -pflichtige Umsätze (Bemessungsgrundlage): Erträge->...

    • Steuerpflichtige Umsätze (Steuer): Passiva->Verbindlichkeiten

    • Vorsteuer: Aktiva->Forderungen

    • Die den Vorsteuern zugehörigen Aufwendungen werden im Formular nicht abgefragt. Je nach Art der Kontoführung sind die Konten aber im Monatsabschluß zu berücksichtigen. (Abschluß nach laufendes Jahr oder Vorjahr)
  2. Formularfelder die keine Konten sind

Abweichungen der elektronischen Übermittlung bitte ergänzen

  1. Steuernummer: Datei->Eigenschaften->Steuern->Steuernummer

  2. Finanzamt: hmm, könnte man als Lieferant mit der Nummer 0 einführen - der Staat liefert ja schließlich Teile der Infrastruktur.
  3. Unternehmer: Datei->Eigenschaften->Geschäft->Firmenname & Firmenanschrift

  4. Voranmeldungszeitraum: Kreuz in jjmm bei monatlicher, jj4q bei vierteljährlicher Abgabe
  5. Kz 10: 1 bei Berichtigung
  6. Kz 29: 1 bei Verrechnung
  7. Kz 26: 1 bei einmaligem Widerruf der Einzugsermächtigung
  8. Zl 78: Angaben zum Steuerberater
  9. Zl 85: Unterschrift <=> elektronische Signatur

  10. sowie mehrere(?) Übertragszeilen: 43->45

3.1.1.1.2. EÜR

Nach meiner Einschätzung sollte es möglich sein, wenn die UStVA klappt, auch die weiteren Steuerformulare zu erfaßen und einzubauen. Dabei denke ich naheliegenderweise als nächstes an die Einnahme-Überschuß-Rechnung (EÜR).

Wer schreibt hier schon mal die Kennzahlen und Bezeichnungen hin?

Ich (RolfLeggewie) übernehme mal diesen Teil Einnahmeüberschußrechnung. Allerdings ist mir diese Seite viel zu unübersichtlich und ich mache unter GnuCash/EuerGc eine neue auf.

3.1.1.1.3. weitere Formulare

Welche weiteren Formulare/Anlagen fallen euch ein?

a) Lohnsteuer Anmeldung b) Lohnsteuerbescheid Bemerkung wir haben eine Steuernummer für MwSt und eine für Lohnsteuer!.... Ja das Finanzamt kann das einfach so beschließen! D.h. Man müsste hier Flexibilität wahren.

3.1.2. HBCI Terminüberweisungen

Das Ausführungsdatum bei "Einzelüberweisung" einstellbar machen (braucht openhbci2)

3.1.3. Zuordnung HBCI Buchungsdaten - Gnucash Felder

Die Strings die in die Gnucash Felder eingetragen werden individuell konfigurierbar zu machen weil die Banken und Wünsche sehr unterschiedlich sind, z.B etwa:

 Beschreibung="$OTHERNAME; $DESC5$DESC6"
 Bemerkung="$DESC1 $DESC2 $DESC3"
 Buchungstext-HBCI-Konto=" $DESC4"
 Buchungstext-Gegenkonto=""
 Aktion="$TEXT"
 Datum="$VALUEDATE"

3.1.4. Importer: Vorschläge und Bearbeiten von Buchungen

3.1.5. generic-exporter

(Englische Übersetzung bitte auf GnuCash/DevelTexts pflegen.)

Alle folgenden Features könnten wahrscheinlich auf einem Schlag (allerdings einem etwas kräftigerem) erledigt werden indem man eine allgemeine Schreibweise für Kontoverbindugen definiert und komplementär zum Importer einen Exporter implementieren würde. Damit wäre es endlich möglich die anderen Features von GnuCash auch für HBCI Nutzer verwendbar zu machen. Zur Zeit können für HBCI nur speziell progrmierte HBCI-Einzel-GUI add-ons Verwendung finden, die für jede Aktion aufgerufen werden müßen. Diese speziellen HBCI-GUIs könnten mit einem Exporter auch weiterhin für die Erstellung von einzelnen "Online Buchungsaufträgen" genutzt werden, zusätzlich aber auch alle anderen Methoden.

Im Einzelnen müsste der generic-exporter:

Realisierungsideen:

Also der Exporter sucht nach Buchungen die er zur Bankschnittstelle übergeben soll. Das sind die jenigen in dessen

  1. Aktionsfeld ein Geschäftsvorfall steht das er interprtieren kann z.B. "Überweisung" oder "Lastschrift"
  2. Status noch "zu senden" ist.

Dazu müsste natürlich evtl. der Wertebereich des Statusfeldes in GnuCash erweitert werden. Zusätzlich bräuchte man wohl noch mindestens einen zusätzlichen Status s="senden online" oder so, zu den vorhandenen n="noch nicht bestätigt" und b="bestätigt".

Die gefundenen Buchungen müssen nun interpretiert werden.

Ein Problem stellt sicher der Unterschied der Datenfelder zwischen GnuCash und der Bankschnittstelle dar.


CS: Man vergleiche HBCI::Transaction mit den dokumentierten Zugriffs-Funktionen in gnucash's transaction.h.

Unabhängig ob HBCI, Datenträgeraustausch, oder Webinterface, müssen der Bank Transaktionendaten übergeben werden die in GnuCash nicht explizit vorhanden sind:

Unkritisch sind Datum, Betrag, Währung und Kontoinhaber.

Doch

sind fraglich denn GnuCash kennt nur Beschreibung und Buchungstext

Die erste Idee die einzelnen Nummern mittels parser auf plausibilitätsbasis aus dem Textstring zu "suchen" wurde verworfen.

Das angebrachteste scheint es zu sein ein eindeutiges Format für die Bankverbindung festzulegen. Hierbei kann gleich von den neuen interationalen Banken Standards gebrauch gemacht werden. (IBAN, BIC, IPI)

Den aktuellen Formatvorschlag für eine eindeutige Speicherung einer Bankverbindung im Beschreibungs- oder Buchungstextfeld zeigt folgendes Beispiel:

Abschlag   "Kundennr. 08/15"   <Stadtwerke@DE00 5555 5555 1234 5678 90>

Text der nicht in eckigen Klammern steht ist Verwendungszweck, es sei denn der Verwendungsweck wird explizit in Hochkammatas angegeben.
Vor dem @ steht der Emfängername, dahinter die Internationale Bank Account Number (IBAN)

Die IBANs die jetzt von den Banken eingeführt werden bilden sich übrigens aus der herkömlichen Bankleitzahl und Kontonummer. (näheres: http://www.iban.de )
Hier z.B.:
Empfänger: Hans Mustermann
BLZ: 555 555 55
Kto.: 1234567890

Kontonummer und BLZ lassen sich über KtoBLZcheck auf plausibilität checken.

Prinzipiell können die Bestandteile "Verwendungzweck", <Empfänger@...> und sonstiger Text für den export an beliebiger Stelle im Buchungstext oder im Beschreibungsfeld stehen. Für den *Importer* wurde jedoch der Wunsch geäußert die Positionen für <Other-name@BANK 5555 5555 1234 5678 90> und "Info" in den Optionen konfigurierbar zu machen (Die Buchungsart kann in das Aktionsfeld).

Analog zum Importer könnte der generic exporter vor der Übergabe der Daten diese nochmal in einer GUI anzeigen, die vieleicht dem internationalem Überweisungsformular Standard (IPI) nachempfunden ist. (siehe: http://www.iban.de/iban_ipi.html Ein ipi-print-exporter wäre auch denkbar)


Mit Exporter: Die "Jobs" stünden im Kontobuch mit entsprechendem Status. Dort können sie bei Bedarf selbstverständlich auch editiert/kopiert werden. (Z.B.könnte man sie Duplizieren und den Status neu setzen)

Mit Exporter: hbci-exporter könnte "zukünftige Buchungen" entsprechend and OpenHBCI übergeben.

Mit Exporter: Könnten Onlineüberweisungen sofort lokal über Terminierte Buchungen erzeugt werden. Evtl. ließen sich auch Terminierte Buchungen als Daueraufträge exportieren (one notwendige neue GUI) so das sie zukünftig bei der Bank gespeichert sind und so automatisch ausgeführt, und über den Importer wieder eingelesen werden (die einzelnen Buchungen). (Als in den blauen Himmel geschriebenes Nonplusulta würde ein kleines Häkchen in der Terminieren Buchung reichen: [x] automatisch von der Bank ausführen lassen)

Mit Exporter: Wäre das Quick-fill Feature für Online Geschäftsfälle nutzbar.

3.1.6. Online Kursabruf Installation unter Windows vereinfachen

3.1.7. Eingabefelder für Devisenkurs und Landeswährung bei Investmentfonds/Aktien

3.1.8. Bug: "Preis"-Feld bei Fonds wird einfach verändert (Version 2.2.4 Windows)


3.1.9. Noch unbestätigte Vorschläge

FIXME: Das war mit 1.8.0. Ist folgendes immer noch der Fall? - (BUG:) Wenn während des importierens ein neues konto erstellt wird (als gegenkonto) dann ist danach im Auswahlfenster für das Gegenkonto die neue Kontobaumansicht (mit neuem kto.) unter der alten zu sehen (doppelt).

CS: Ok, richtiger Bug: "Generic Importer: Create new account displays account tree twice" oder so. Ab damit ins bugzilla, und denk bitte daran, die Fehlerbeschreibung so ausführlich wie möglich zu machen.

3.2. Vorgehensweise Allgemein

CS: Vorgehensweise für Feature-Wünsche generell: Am besten wäre für jeden einzelen Wunsch/Bug ein einzelner Eintrag in Bugzilla, http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash Einträge bitte alle auf englisch. Feature-WÜnsche als Severity: Enhancement kennzeichnen. Wenn es um HBCI-Spezifische Dinge geht, im Summary-Eintrag sowas wie "HBCI: blablabla" schreiben, damit die anderen Programmierer wissen, was gemeint ist.

Patches an: gnucash-patches schicken.

4. Schon erledigte Verbesserungen

im Re-We Modus im "Buchen..." Dialog: Seiten wechseln links nach rechts und Überschriften "per Soll" "an Haben" anstatt "Herkunftskonto" und "Buchen nach"


Damit der vorige Abschnitt nicht unendlich lang wird, werden diejenigen Diskussionen, die bereits zu einem Abschluß gefunden haben, hierher verschoben.

Alle Ergebnisse in diesem Abschnitt sind im gnucash-1-8-branch CVS und werden in 1.8.8 drin sein.

CS: Okay, so lasst uns das angehen. Hier die Zusammenfassung; euer Ok bitte einfügen:

Englisch

Erklärung

bisher Deutsch (in 1.8.7)

Zukünftig Deutsch

Status

transaction

Geschäftsvorfall

Buchungssatz (bei Bedarf: Buchung)

Konsens

split

Teil einer transaction

Buchung

Buchungsteil

Konsens

General Ledger

Alle Buchungssätze aller Konten in einem einzigen Journal

Hauptbuch

Journal

Konsens

Menu View -> Style

Menüpunkt, wie viele Buchungsteile eines Buchungssatzes angezeigt werden

Ansicht -> Stil

Ansicht -> Buchung oder Ansicht -> Buchungen

JL, CS, CG: Buchung

vollständig oder mehrteilig/mehrzeilig

CG, JL, CS: vollständig; AF: mehrteilig/mehrzeilig

einteilig oder einzeilig

JL: einteilig; AF, CS, CG: einzeilig

Nun die Diskussion. Aus der Mailingliste ließen sich folgende Verbesserungsvorschläge "herausziehen" (Kommentare von CS sind von ChristianStimming, JL von Julian Ladisch, AF von Andreas Fahle):

Irrtümer im Englischen

Kontobuch: Ansicht -> Stil

-Kontobuchmenü:

Ansicht -> Buchungen (plural):
o Vollständige Buchungsätze
o Aktive Buchung vollständig
o Beschreibungszeilen
--------------
x Bemerkungen anzeigen [an/aus Knopf]

Knopf "Vollst. Buchungssatz"

CG: ACK, geht schon in Ordnung. Allerings ist es halt so, dass die meisten, wie du auch selbst schreibst, erst noch eine extra Erklärung brauchen um das als logisch zu verstehen. Wie auch bei Dokumentationen scheinen mir oft die kleinen "logischmachenden" Worte oder Bemerkungen (Voraussetzungen) weggelassen zu werden um es "einfacher" zu machen, mit dem Effekt Verwirrung für Neueinsteiger zu stiften. Alte Hasen lesen das sowieso nicht mehr. (Oft werde zwar alle Optionen beschrieben, es wird aber nicht gesagt was in "the big picture" man beispielsweise damit anstellen kann.)

o Vollständig
o Aktive vollständig
o Einzeilig
--------------
x Bemerkung anzeigen

transaction -> Buchungssatz Von Buchungssatz sprechen anstatt vom zugrundeliegendem Geschäfts(vor)fall. (Der Geschäftsfall "Einkauf von Aktenordnern auf Ziel", ist nicht gleich der buchhalterische Aufzeichnung "Per Büromaterialaufwand an Kreditor")

split: "Buchungszeile", "Buchungseintrag" oder "Buchungsteil"

"Journal" anstatt z.Zt. Hauptbuch (Grundbuch wäre zwar auch Richtig könnte aber missverständlich sein.)



GnuCash/WeiterEntwicklung (zuletzt geändert am 2008-12-04 00:15:20 durch Lb229)