Zurück zur GnuCash Wiki Hauptseite

---

Inhalt

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.

• Wie bearbeite ich einen bestimmten Vorgang besonders effizient? Bankabgleich, Monats- oder Jahresabschluß, ...

• Welche Gesetzesänderungen oder -auslegungen haben meinen Umgang mit GnuCash verändert?

• Welche Änderungen am Verhalten des Programms sind mir nach dem letzten Update aufgefallen?

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

• prüfen ob es Änderungen gibt. Falls ja mit

cd ~/translatio/gnucash
svn up

• herunterladen. Alle

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

• Eventuell könnten sich in Einzelfällen sogar Irrtümmer schon in die englische Implementierung eingeschlichen haben, die leider nicht einfach durch Bearbeiten der Übersetzung behoben werden können. Konkretes bitte noch einfügen.

  CS: Für die Änderungen im Englischen müsste mal jemand ein patch an gnucash-patches schicken. Ich selber hab z.Zt. nicht mal dafür die Zeit/den Nerv. Änderungen im Englischen geben auch deswegen mehr Ärger, weil dann ja jeder Übersetzer seine Übersetzung überarbeiten muß -- daher schrecke ich davor etwas zurück.

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.

• CG: Versteh ich das richtig? Also doch keine Fehler im Englischen gesichtet? JL: Die Quelltexte sind in Ordnung, nur im GUI heißt es falsch "General Ledger" statt richtig "Journal".

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)

• CS: Für die Intutiven Überschriften bin ich noch nicht ganz überzeugt, ob jeder neue Benutzer die generelle Spaltenüberschrift "Mehrung", "Minderung" so besonders toll findet... die Worte sind ja eher ungebräuchlich in der Umgangssprache. MG: Ich finde auch das die Worte nicht passen, mit Abhebung und Lastschrift kann jeder etwas Anfangen da sie doch normale Umgangssprache sind.

• CG: Welche bekannten Begriffe man auch nimmt, das jede Buchung eine Einzahlung und eine Lastschrift hat, oder im Aufwandkonto lauter Gutschriften stehen ist einem Neulling bestimmt nicht einfach so klar. So zu vereinfachen trifft die Sache leider nicht, und ist zudem auch noch die meiste Zeit falsch. So scheinbar bekannte Wörter verführten zu einer "false friend" Vorstellung die dem Verständnis des Buchführungsprinzips sehr hinderlich sein kann. Der ganze Zikus mit aktiv/passiv, soll/haben dient doch eigentlich nur dazu die Subtraktion bzw. negative Zahlen zu umgehen und so Mehrungen und Minderungen anders abzubilden.

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

• https://lists.gnucash.org/pipermail/gnucash-de/2004-December/002267.html

• https://lists.gnucash.org/pipermail/gnucash-de/2004-December/002305.html

• https://lists.gnucash.org/pipermail/gnucash-de/2005-January/002580.html für andere Linux-Software

• https://lists.gnucash.org/pipermail/gnucash-de/2005-January/002473.html Wer das testen will, muß bei configure zusätzlich --enable-local-specific-tax einschalten und LANG=de_DE wählen, und zwar einfach mit dem gnucash-1.8.11. Sodann bitte eine Rückmeldung auf der Mailingliste. -- ChristianStimming 2005-04-11 09:43:51

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

• Wäre schön wenn man z.B den erhaltenen Verwendungszweck ergänzen könnte oder die Buchung gleich splitten könnte.
• Übrigens wenn eine eigene HBCI-Buchung beim nächsten import "nur" Abgeglichen wird werden die HBCI Daten gar nicht aufgenommen. Evtl. könnte der generic-importer beim "Abgleichen" die zusätzlichen Informationen anhängen, und das Datum auf des Ausführungs/Wertstellungsdatum (VALUEDATE) setzen, damit es einheitlich ist. (analog anderen Programmen)
• Die Suche nach passenden Buchungszuordnungen sollte auch die vorbereiteten Terminierten Buchungen (scheduled transaction templates) einbeziehen, so können dann z.B die komplizierte aufgesplittete Gehaltsbuchung oder Einzugsermächtigungen gleich gut vorgeschlagen werden, und dann in den STX als erledigt markiert werden.

  CS: Das ist der "generic importer", also nicht HBCI-spezifisch (sondern auch für OFX). Der genannte Wunsch ist leider sehr schwer umzusetzen (eine GtkCTable kann keine beliebigen Widgets als Zellen haben -- oder so ähnlich war das Problem). Enhancement in bugzilla "Generic importer: edit transactions in importing window". Das ändert sich grundlegend, wenn der gnome2-Port aktuell wird, wenn CVS-HEAD auf gnome2 umgestellt wird, kann man das angehen. Vorher lohnt nicht.

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:

• Buchungen die in GnuCash stehen und z.B. als wartender "Online Auftrag" markiert sind lesen,

• Empfänger, Konto, BLZ sowie Ausführungsdatum und Betrag aus den GnuCash Datenfeldern auslesen und

• an hbci-exporter (bzw. an ein anderes Schnittstellenmodul (Datenträger, Webinterface, IPI oder Scheckprinter, etc)) übergeben können.

• Sowie anschließend den Status der Buchung in GnuCash entspechend auf in Arbeit oder Ausgeführt setzen.

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

• Empfängername
• Empfängerkonto
• Empfängerbank

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)

• CS: Meine Meinung aus der Antwort hier gilt (leider) weiterhin, Kurzfassung: Ich halte das in diesem Kontext für nicht gut, da es die eindeutige Datenzuordnung in diesem vital wichtigen Bereich ziemlich verwischt. Ich werd's also wohl kaum implementieren. Wenn es jemand sonst versuchen will -- einfach mal patches schreiben und an gnucash-patches schicken.

  • CG: Schade, das Dir die Idee immer noch so misfaellt. Leider faellt mir aber keine bessere Alternative ein. Einfueren neuer Gnucash Datenfelder bringt auch nur eine pseudosicherheit und es muessten noch immer alle anderen module hbci/ofx/swift/whatever aware programmiert werden um sie nutzbar zu machen. Der Bedarf an einer export-funktionalitaet scheint aber wirklich da zu sein, (z.B. gnucash-de Frage zu Lastschriften aus dem SQL-Backend) und wird auch wohl andere Bankschnittstellen betreffen. Daher hatte ich gedacht ein generic-exporter framework waere gut. Leider hat auf gnucash-devel auch niemand ein Kommentar abgegeben. Bei dem posting ist aus RFC desnachts dummerweise auchnoch RFE geworden. Naja nun steht aber eh kein PC mehr zur Verfuegung und auch nur selten eine Internet Bude.

---

Nun die von Exporter "geschluckten" dann integrierte Feature Wünsche:

• Sammlung von HBCI-Aufträgen in einer Job-Liste

• um sie später gemeinsam [in einem Rutsch kuzzeitig dafür Online gehen, und mit einer Pin-Abfrage] ausführen zu können. RS: Die Job-Liste könnte dabei generell alle ausgeführten und noch auszuführenden Transaktionen beinhalten. Eine noch nicht ausgeführte Transaktion hätte dann eben einen anderen Status, als eine bereits ausgeführte Transaktion.

  CS: Das Sammeln von Aufträgen und Abschicken in einem Rutsch ist in OpenHBCI schon längst eingebaut. Es fehlt lediglich das GUI in GnuCash. Geschätzter Aufwand ca. 8-12 Stunden. Etwas tricksig ist die Frage, wie und wann zu einem HBCI-Job dann tatsächlich die GnuCash-Buchungen erstellt werden sollen (beim Auftrag-Sammeln? Beim Abschicken? Nach erfolgreichem Abschicken?). Da hatte ich auch keine einfache Antwort. RS: Vielleicht ließen sich dann die erledigten Jobs durch einfaches editieren wieder zu neuen Jobs umformulieren (Um z. B. fast gleiche oder gleiche Überweisungen/Lastschriften mehrmals durchfünren zu können) CS: Nein, das halte ich für keine so gute Idee. Besser einfach so Buchungs-Vorlagen programmieren, wie oben erwähnt.

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)

• Terminüberweisungen

• Die schon vorab an die Bank gesendet werden und erst zum angegebenen Zeitpunkt ausgeführt werden.

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

• Generierung von sich ständig wiederholenden Überweisungen/Lastschriften

• (z. B. Miete).

• CS: Die Verwaltung von Daueraufträgen ist in HBCI und OpenHBCI längst integriert -- GnuCash muß nur ein GUI dafür bieten. Die Speicherung von Daueraufträgen in GnuCash ist aber etwas unklar. Die Terminierten Buchungen haben zum einen genug eigene Probleme und zum anderen sind ein stand-alone Feature, wo der HBCI-Code keine zusätzlichen Datenfelder mit einbauen darf/kann. Also besser einfach nur eine GUI für die Dauerauftrags-Verwaltung bauen und sonst keine weitere Integration erwarten.

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)

• Adressbuch für Zahlungs- und Lastschriftempfänger

• Vielleicht liesse sich ja ja das bereits in GNUCash enthaltene Adressbuch unter "Geschäft --> Kunden" für diesen Zweck etwas aufbohren. Oder ist das generell für etwas anderes gedacht?

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

3.1.6. Online Kursabruf Installation unter Windows vereinfachen

• dazu Link zu ActivePerl auf der Homepageseite von GnuCash

• Bei der Installation mittels "C:\Program Files\gnucash\bin\install-fq-mods.bat" kommt erst einmal die Meldung, dass Perl nicht gefunden werden konnte - eine Erklärung, wie und wo man das Verzeichnis c:\Perl einträgt, so dass Perl gefunden werden kann, wäre notwendig.

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

• Wenn man ein Unterkonto unter "Investmentfonds" für einen Fond anlegt, gibt es darin dann u.a. die Felder "Anteile", "Preis", "Kauf"; zur Übersetzung statt "Kauf" würde wohl besser "Wert" oder "Wert des Postens" passen

• Was ich jedoch vermisse: Ich habe Fonds, die sind in YEN oder US-$ notiert. Ich bräuchte daher Eingabefelder für den "Devisenkurs" zum Buchungszeitpunkt und ein Eingabefeld des "Fondspreises in der jeweiliger Landeswährung" (GnuCash sollte dann aus diesen beiden Feldern automatisch den "Preis in €" berechnen).

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

• Da ich des Englischen nicht so mächtig bin, hoffe ich, dass ich hier den Bug schildern darf:
• Wenn man ein Unterkonto unter "Investmentfonds" für einen Fond anlegt, gibt es darin dann u.a. die Felder "Anteile", "Preis", "Kauf"

• Nun habe ich dort z. B. eingegeben: Anteile: 7,737; Preis: 13,378091 und mit <tab> das ganze "abgeschlossen" bis eine neue Zeile generiert wird ("Kauf" wird automatisch berechnet). Was aber mit dem Erscheinen der neuen Zeile geschieht: GnuCash macht aus dem "Preis" automatisch 13,3786. Ändere ich das manuell wieder auf 13,378091 werde ich zwar gefragt, dass das Feld "Preis" geändert wurde und ob ich "Anteile", "Preis" oder "Kauf" neu berechnen lassen möchte. Wähle ich "Kauf", dann springt aber das "Preis"-Feld wieder auf 13,3786.

---

3.1.9. Noch unbestätigte Vorschläge

• Ausdruck von Überweisungen/Lastschriften vor der Ausführung Damit man die Finanziellen Transaktionen etwas besser dokumentiert hat, als es bisher der Fall ist. (Papiermäßig) Frage: Ist das wirklich gewünscht oder nötig? CS: Der Ausdruck dessen, was man in das Formular eingegeben hat, ist kein Problem. Nur interessiert das doch wohl kein Schwein. Interessanter wäre, irgendeine Rückmeldung von der Bank auch dazuzudrucken. Da ist aber leider in OpenHBCI immer noch gelegentlich unklar, wo und wie man die tatsächlich richtige Rückmeldung kriegt. Also erstmal OpenHBCI weiter studieren. Mittlerweile unterstützt OpenHBCI "getsatus" doch anscheinend gibt es keine Bank die Dataten tatsächlich bereitstellt.

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"

• CS: prinzipiell ok, aber ich bin nicht so sicher, ob das Änderungen im Programmcode benötigt. CG: denke schon, dürfte demnach aber auch im englischen debit/credit modus z.Zt. verkehrt sein.

• Ein Patch wurde Eingereicht und wartet nun auf Anwendung. 04-01-19

• Speichern von Überweisungs-Vorlagen (Man bräuchte eine Art von Empfängerverwaltung (Name,Kto,BLZ) um nicht jedesmal eine neue Einzelüberweisung ausfüllen zu müssen.)

  • CS: Man bräuchte eine zusätzliche GUI, um die Vorlagen zu verwalten, und dann halt einen zusätzlichen Auswahlknopf im Überweisungsfenster. Geschätzter Arbeitsaufwand 6-8 Stunden, also eigentlich echt nicht viel -- sofern man sich ein bißchen mit C und GTK auskennt. GUI-Design geht ratz-fatz in Glade. CS: erledigt im aktuellen CVS und wird in 1.8.5 drin sein. Mehr dazu hier. Editieren von existierenden Vorlagen sowie Löschen geht z.Zt. leider noch nicht.

• Liste mit Bankleitzahlen und Bank-Bezeichnungen: Wäre schön, wenn beim ausfüllen einer Überweisung, gleich nach der Eingabe der Bankleitzahl die Bezeichnung der Bank erscheinen würde, damit man sieht, ob man die richtige BLZ eingegeben hat. CS: erledigt im aktuellen CVS und wird in 1.8.5 drin sein. Benötigt KtoBlzCheck und kann auch gleich die Plausibilität der Kontonummern mit überprüfen.

---

• Übersetzung

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:

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

• Eventuell könnten sich in Einzelfällen sogar Irrtümmer schon in die englische Implementierung eingeschlichen haben, die leider nicht einfach durch Bearbeiten der Übersetzung behoben werden können. Konkretes bitte noch einfügen.

  JL: Warum soll man einen Fehler im Englischen nicht zumindest im deutschsprachigen GUI korrigieren? Die deutschen Nutzer wollen nicht eine wörtliche Übersetzung des falschen Englisch-GUIs, sondern eine korrekte Beschriftung. CG: Die Englischen auch. JL: Stimmt, aber warum sollen die deutschen warten, bis es im englischen geändert worden ist? CS: Für die Änderungen im Englischen müsste mal jemand ein patch an gnucash-patches schicken. Ich selber hab z.Zt. nicht mal dafür die Zeit/den Nerv. Änderungen im Englischen geben auch deswegen mehr Ärger, weil dann ja jeder Übersetzer seine Übersetzung überarbeiten muß -- daher schrecke ich davor etwas zurück.

Kontobuch: Ansicht -> Stil

• ändern in Kontobuch: Ansicht ->Buchungseinträge CS: hm, ich hab befürchtet, daß der Überstzungs-String "style" schon mehrfach belegt sein könnte, was bedeuten würde, daß man an dieser bestimmten Stelle keine abweichende Übersetzung nehmen kann, aber dem ist nicht so. Man kann die Änderung hier also tatsächlich machen. Vorschläge für den bisherigen Menüpunkt Ansicht-Stil: JL(1):

  • Mehrzeilig
  • Auto-mehrzeilig
  • Einzeilig
  • Bemerkung

  CG: Meine alten Vorschläge hab ich mal weggenommen und nun auch die anderen Beiträge mit einbezogen. Hier mal meine Erfahrung: Wenn ich anderen Leuten beim eingewöhnen in GnuCash helfe, hat es sich allerdings wiederholt gezeigt das Ihnen Ihnen nicht auf anhieb klar ist was genau "zum Teufel" mit Stil gemeint ist, und erst recht nicht was so ein Auto-Dings macht. Ja und was für Information steht denn nun in einer Zeile oder in mehreren Zeilen drinn? Selbstverstendlich kann man da plump RTFM zitieren. Ich erkläre das Menü dann so, das dort die Ansicht für die Buchungen im Kontobuch eingestellt wird. Man kann sich vollständige Buchungsätze anzeigen lassen, Nur die aktive Buchung vollständig anzeigen lassen oder nur jeweils eine Beschreibungszeile zeigen lassen. Sowie zusätzlich wählen ob Bemerkungen angezeigt werden. Dann wird das meist gleich viel besser verstanden, und wenn die Begriffe noch nicht klar sein sollten ist auch schnell ein Anknüpfungpunkt gefunden. IMHO ist es viel besser die korrekten Begriffe auch in der Software zu verwenden als sie nur in den Manuals als "Hintergrundtheorie" zu praxisfern zu halten. Damit wäre es nach meinen Überlegungen und mit JL(2) am eindeutigsten so:

-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"

• Der Knopf "Mehrteilig" zeigt den aktuelle Buchungseintrag (egal wieviel_zeilig_) wenn gedrückt Vollständig an. CS: Also eine Knopfbeschriftung muß nicht nur zutreffend sein, sondern auch kurz genug. Wäre der Vorschlag hier also, die Beschriftung "Vollständig" zu nehmen? Die Knopfbeschriftung sollte das gleiche Wort sein wie der entsprechende Menüpunkt (Konsistenz!), wie oben diskutiert. JL(2): Mit "Vollständig" kann ich mich auch anfreunden, dann müsste das Menü allerdings Ansicht->Buchung und nicht Ansicht->Buchungseinträge heißen. Die Einträge wären dann:

  • Vollständig
  • Aktive vollständig
  • Einzeilig
  • Bemerkung

  AF: Ich bin gegen "Vollständig", weil es m.E. unpräzise ist (vollständig=alle Buchungszeilen/alle Spalten/alle Datensätze?) und außerdem der Begriff der "Vollständigkeit" im buchhalterischen Sinne bereits belegt ist. Lieber "Mehrteilig" oder "Mehrzeilig" - letzteres macht IMHO besser deutlich, dass es sich um einen Darstellungsstil und nicht um einen Buchungstyp handelt. Insofern Zustimmung zum ersten Vorschlag von JL. CG: Der Button steht eindeutig bei den Funktionen die einzelne Buchungen betreffen. (Gut: Sicherlich könnte ein GUI-Design-Team die Intuitivität auch noch etwas verbessern.) Ist jedoch "Mehr" von Irgendwas eindeutiger als Vollständig? Der Button blendet alle vorhandenen Informationen zu einer Buchung ein, inkl. dem "Vollständigem Buchungssatz". Oder gibt es da noch eine weitere Verwendung der "Vollständigkeit" in der Buchhaltung? JL: CGs "Ansicht->Buchungen" im Plural ist schlechter als "Ansicht->Buchung" im Singular, da es nicht darum geht, welche Buchungen (Plural) man auswählt, sondern wie jede einzelne Buchung (Singular) dargestellt werden soll.

  • CG: Selbstverständlich würde ich soetwas nicht sagen - nach meinem Verständnis stellt man in dem Menü ein, in welcher Ansicht man alle seine Buchungen im Kontobuch sehen möchte. Deiner Argumentation kann ich leider nicht folgen, es sind immer alle Buchungen gemeint. Würde im letzten Teilsatz "_eine_ einzelne Buchung" stehen wäre es wirklich singular, aber die Einzige Funktion die sich in diesem Zusammenhang nur auf eine Buchung auswirkt ist der "Vollständig"-Schnellanzeige-Button auf das sich das Menü aber nicht bezieht.

  JL: AFs Bedenken wegen "Vollständig" kann ich wie CG nicht nachvollziehen. Aus dem Menüpunkt "Buchung" klappt eine Liste aus, von der man "Vollständig" auswählt. Das ist offensichtlich eine vollständige Buchung, also mit allen Buchungsteilen. Der Grundsatz "Vollständigkeit" der ordnungsgemäßen Buchführung besagt, dass alle Geschäftsvorfälle auch gebucht werden müssen. Damit kann "Buchung->Vollständig" nicht verwechselt werden, weil die anderen Auswahlmöglichkeiten "einzeilig" usw. lauten, und nicht "Fehlende Geschäftsvorfälle". JL: Nachdem wird uns geeinigt haben, Split mit Buchungsteil zu übersetzten, sollten wir statt einzeilig/mehrzeilig lieber einteilig/mehrteilig verwenden. Wenn man die Bemerkung anschaltet und auf einteilig stellt, hat man zwei Zeilen: Eine mit der Bemerkung, eine mit dem einen Buchungsteil, was mit "einzeilig" nicht so richtig zusammenpasst. Ich hatte bei meinem ursprünglichen Beitrag in gnucash-de nur die alte Übersetzung, nicht die neuere mit "...teilig" in Version 1.8 gesehen und bin nach dieser intensiven Diskussion von meiner anderslautenden Meinung damals abgerückt. CG: Das wäre gut, wenn auch ein Buchungsteil und eine Bemerkungszeile angezeigt würde, tatsächlich ist es aber die Beschreibungszeile, und eine Bemerkungszeile. Der Buchungsatz (inkl. Buchungstexte) scheint mir nur Vollständig oder gar nicht angezeigt zu werden (wenn ja dann eingerückt). Deswegen schlug ich für den nicht Vollständigen Fall auch "(nur) Beschreibungszeilen" für die "Ansicht" von "Buchungen" vor. JL: Beim Stil "Vereinfachtes Hauptbuch" werden die Beschreibung und das Gegenkonto in einer Zeile kombiniert. Das ist sehr praktisch für ein Haushaltsbuch, im Konto "Kleidung" kann ich dann sehen, ob die Kleidung bar oder mit Karte vom Girokonto bezahlt wurde. Das funktioniert jedoch nur, wenn jede Buchung nur aus zwei Buchungsteilen besteht, es also nur ein Gegenkonto gibt. Erwirbt man in einem Einkauf per Karte sowohl Lebensmittel als auch Kleidung, sind drei GnuCash-Konten betroffen: Girokonto, Kleidung und Lebensmittel. Da erscheint beim "vereinfachten Hauptbuch" dann "- mehrteilige Buchung -", bearbeiten kann man das nur, wenn man auf auto-mehrteilig oder Journal umschaltet. Wer umsatzsteuerpflichtiger Unternehmer ist, hat bei fast jeder Buchung die Umsatzsteuer mit dabei, sodass man das vereinfachte Hauptbuch nicht gebrauchen kann. CS: Die Argumentation von CG bzgl. der Notwendigkeit einer Änderung hier finde ich überzeugend. Allerdings würde ich das Menü auch lieber im Singular schreiben, denn IMHO bezieht sich die Änderung dort eben auf die Ansicht einer einzelnen Buchung -- von denen ich naturgemäß im Kontobuch natürlich ne ganze Liste hab. Außerdem finde ich "Einzeilig" (bisher "Vereinfachtes Hauptbuch") nun am besten, denn wie JL im vorigen Absatz schreibt, werden da Beschreibung und Gegenkonto in einer Zeile kombiniert.

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.)

• Mein aktueller Favorit ist nun exakt JL(2): Das Menü heißt "Ansicht -> Buchung", der Knopf heißt "Vollständig", das Untermenü hat die Einträge

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"

• CS: Also mit transaction=Buchungssatz und split=Buchungseintrag kann ich mich prinzipiell anfreunden. Das würde aber zusätzlich heißen, daß das Wort "Buchung" für gar nichts mehr verwendet wird? Ist das beabsichtigt? CG: Ist gut so, da "Buchung" ja allgemein für verschiedenste Sachen gebraucht wird. Persönlich würde ich "Buchungszeile" bevorzugen (analog Mehr*zeilig*). Auch liese sich Buchungseintrag als darstellungs (und zeilen) neutrale Bezeichnung verwenden. Kann man sicher in der Docu gebrauchen, da es schließlich so viele Darstellungsarten gibt. (Auch im nächsten Punkt verwendet). JL: Buchung und Buchungssatz haben annähernd die gleiche Bedeutung und können beide für transaction verwendet werden. Bei Buchungssatz schwingt mit, dass mehrere Konten betroffen sind, bei Buchung geht es mehr darum, dass überhaupt gebucht wird. Buchungszeile ist insofern mehrdeutig, da auch für den Buchungstext eine Zeile im Journal verwendet wird. Buchungsteil hat gegenüber Buchungseintrag den Vorteil, dass man schon am Wort sieht, dass eine Buchung aus mehreren Buchungsteilen besteht - einem Teil pro Konto.

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

• CS: Hm. Im Kontobuch gibt es den Ansichts-Stil "Amerikanisches Journal". Ist also nun das Kontobuch ein Journal oder ist es keins? Da ist mir das Wort "Journal" für das Grundbuch doch etwas zu kurz -- vielleicht mit irgendeinem Zusatz? Grund-Journal ist aber ja leider Quatsch. CG: Mit dem Vorschlag "Ansicht ->Stile" zu überarbeiten ist Journal jetzt eindeutig. JL: "Amerikanisches Journal" ist die falsche Übersetzung von "transaction journal". Gemeint ist eine Darstellung wie im Journal, dass also der komplette Buchungssatz angezeigt wird. Das Journal ist das, was man mit Werkzeuge->Hauptbuch aufruft, korrekt wäre die Bezeichnung Werkzeuge->Journal; dieser Menüpunkt hat auch im Englischen schon eine falsche Bezeichnung. CS: Kann man nicht auch "Grundbuch" sagen? Im GnuCash-Kontext ist Journal halt in dermaßen anderer Bedeutung in Benutzung (und wird bei den englischen Benutzern ja noch lange bleiben), daß ich da ungern eine kollidierende Bedeutung in der deutschen Übersetzung einführen würde. Da würde ich also lieber auf "Grundbuch" übergehen. Wenn die Benutzer davon dann irritiert sind, sollen sie zumindest in der Doku nachgucken können, daß es hier nicht um eingetragenen Grundbesitz geht, aber das kann man denen IMHO zumuten. CG: Also nach dem man sich mit Buchhaltung beschäfigt hat ist es einem warscheinlich egal, schließlich sind auch beide Begriffe in gebrauch. Grundbuch passt vieleich besser zu Hauptbuch (rein phonetisch ;-), und Journal ist vielleicht am Anfang eingängiger. Ich habe aber eine klare Präferenz in bezug auf die Kollisionsproblematik. Wenn da im englischen mal was nicht ganz richtig bennannt ist, hat das sicher keiner absichtlich gemacht, und wenn das jetzt jemand genauer weis wäre es sicher besser das zur Sprache zu bringen. Ich glaub es ist doch sicher schneller und besserder einen falschen englischen String zu ändern als nach Ausswegen in der Übersetzung zu suchen. Bitte JL, du scheinst da genaueres gefunden zu haben, schreib doch noch mal an gnucash-user. 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. Deshalb passt Journal besonders gut zu den Bezeichnungen in den Quelltexten, Grundbuch wäre eine unnötige Abweichung (und ist meiner Erfahrung nach im Deutschen ungebräuchlicher). CG: Versteh ich das richtig? Also doch keine Fehler im Englischen gesichtet? JL: Die Quelltexte sind in Ordnung, nur im GUI heißt es falsch "General Ledger" statt richtig "Journal".

---

• Zurück zur GnuCash Wiki Hauptseite

---

• English translation of generic-exporter concept has moved to GnuCash/DevelTexts