Ist nicht bekannt und wurde auch im Forum noch nicht angesprochen.

Hallo zusammen,

gestern habe ich endlich den Versuch gestartet, GnuCash mit Fakturama zu verbinden, um den Import der Rechnungen zu automatisieren.
Die Rechnungen sollten detailliert importiert werden, d. h. jede Rechnung sollte so wie sie ausgedruckt wurde, importiert werden. Jede Position, jede Notiz, Rabat, komplette Adresse (automatische/manuelle) usw.
Dies möchte ich so haben, um die Daten für eine (fast) fertige Steuererklärung auf einem Report bekommen zu können, indem ich meine Einnahmen und Barauslagen aufgeteilt nach Kostenstellen bzw. Konten buche.

Diese sind die Schritte, die ich geschafft habe ;( :

1. Ich habe zuerst diese Anweisungen genauest durchgelesen:
https://lists.gnucash.org/docs/C/gnucash-guide/busnss-imp-bills-invoices.html
(Ich glaube, die Anweisungen sind sehr verständlich und einfach.)

2. Ich habe eine CALC-Datei vorbereitet, mit den Feldern die GnuCash erwartet, um anschließend die CVS-Datei zu erstellen.
Die Datei schaut so aus:

Leere Datei
id;date_opened;owner_id;billingid;notes;date;desc;action;account;quantity;price;disc_type;disc_how;discount;taxable;taxincluded;tax_table;date_posted;due_date;account_posted;memo_posted;accu_splits
;;;;;;;;;;;;;;;;;;;;;

Ausgangsrechnungen
20221;16/12/2018;1001;Order 3378;Discount as agreed;4/12/2018;Accounting part 1, 2;ea;Income:Other Income;1;769.95;%;=;10;X;N;A1;16/12/2018;16/01/2019;Assets:Accounts Receivable;Posted by import;X
;;;;;;;;;;;;;;;;;;;;;

Eingangsrechnungen
1204;15/12/2018;2001;PO 210220;Special delivery;16/12/2018;Pride and Prejudice;pc;Expenses:Books;1;30.00;;;;X;;A1;17/12/2018;17/1/2019;Liabilities:Accounts Payable;;X
1204;15/12/2018;2001;PO 210220;Special delivery;16/12/2018;Electronic principles;pc;Expenses:Books;1;50.00;;;;X;;A1;17/12/2018;17/1/2019;Liabilities:Accounts Payable;;X
1205;15/12/2018;2044;PO 21099;;16/12/2018;Ultimate Guide;pc;Expenses:Books;1;10.01;;;;;;;;;;;
1205;15/12/2018;2044;PO 21099;;16/12/2018;Dinner & drinks;pc;Expenses:Dining;1;10.01;;;;;;;;;;;
1205;15/12/2018;2044;PO 21099;;16/12/2018;UG course;pc;Expenses:Education;1;10.01;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;

3. Dann habe ich die Verbindung von Fakturama.2.1.1.Beta-linux mit der aktuellen (aktualisierten) Datenbank eingerichtet.

4. Ich habe mal die Tabellen angesehen, um zu sehen, welche ich einsetzen sollte.
Meiner Meinung nach sollten es diese 2 Tabellen sein:
a). FKT_DOCUMENTRECEIVER
(Beinhaltet die Adresse der ausgedruckten Rechnung, auch wenn sie manuell eingegeben wurde.)
b). FKT_DOCUMENTITEM
(Was meint Ihr? Reichen diese 2 Tabellen bzw. sind sie die richtigen?)

5. Dann habe ich eine Abfrage starten wollen.
Leider, jedesmal, wenn ich eine Tabelle hinzufügen will, stürzt Base ab.
Ich habe für eine Lösung überall gesucht. Ich habe es mit LO 6.4 und mit LO 7.0.3 probiert. Mit der Datenbank der Stable-Version und mit der Beta-Version, jedesmal stürzt Base ab.
Ich weiß nicht, wo ich die Log-Datei für den Absturz finden kann. Ich habe Base sogar Base aus einem Terminal gestartet. Weiser bin ich nicht geworden ;(
Ich habe auch, erfolglos, nach eine Lösung gegoogelt.

Wer kann hier bitte weiterhelfen, ich wäre für jede Hilfe sehr dankbar.

Zum Schluss möchte ich mal Fragen, hat jemand von Euch diese Methode schon im Einsatz? Oder habt Ihr vielleicht eine andere Lösung erfolgreich im Einsatz?
Wenn Ja, würdet Ihr vielleicht die entsprechende Base-Datei /Lösung zur Verfügung stellen?

Schöne grüße
Konstantin

PS
GnuCash Version: 3.8
Build ID: 3.8b+(2019-12-29)
Finance::Quote: 1.49

@Miracolitag
Hallo Steffen,
@rheydenr
Hallo Ralf,

heute habe ich mal das Ganze auf Windows 7 mit LibreOffice 7.0 getestet und das Ergebnis war gleich.

Habt Ihr vielleicht ein Tipp für mich?

Schöne Grüße
Konstantin

Moin, die beiden Tabellen reichen nicht aus. Du brauchst noch die FKT_DOCUMENT, in der stehen die ganzen Infos zur aktuellen Rechnung. Die FKT_DOCUMENTITEM enthält praktisch alle Einzelposten der Rechnung (mit Verweis auf die FKT_DOCUMENT).

Allerdings gibt es im Fakturama gar keine Eingangsrechnungen. Was hast Du denn für eine Abfrage an die Datenbank geschickt? Bist Du nach den Infos im Handbuch vorgegangen?

@rheydenr
Hallo Ralf,
danke für die schnelle Antwort.
1. Ob ich die zwei erwähnten Tabellen oder die FKT_DOCUMENT dazunehmen sollte, ist zurzeit unerheblich.
2. Ich bin genau nach den Anweisungen des Handbuchs vorgegangen. JDBC Treiberklasse wurde geladen, getestet und alles OK. Verbindung mit der Datenbank hergestellt und erfolgreich getestet.
3. Datenbank gespeichert, Tabellen öffnen ist auch kein Problem.
ABER
4. Wenn ich in der linken Spalte auf Abfragen klicke und "Abfrage in der Entwurfsansicht erstellen" wähle,
dann öffnet sich zwar die Entwurfsansicht aber wenn ich irgendeine Tabelle wähle und auf hinzufügen klicke, dann stürzt Base sofort ab.

Mein Verdacht ist, dass es an der JDBC Treiberklasse oder der Fakturama Database liegt, da ich wie oben beschrieben schon Alles mögliche ausprobiert habe.

Hast Du vielleicht das Gleiche schon mal gehabt?

Nein, ich hab das mal ausprobiert, da lief es ganz gut. Allerdings arbeite ich normalerweise nicht mit der Methode, sondern mit einem "richtigen" DB-Tool. Ich probier das gleich nochmal aus.

Als ich vor 2-3 Jahre eine Abfrage gemacht habe, nach den Anweisungen des Handbuchs, hat es auf Anhieb geklappt.
Seither habe ich keine neue Abfrage gemacht, erst vorgestern wieder. Leider immer erfolglos.
Welchen "richtigen" DB-Tool benutzt Du denn? Gibt es ihn auch für Linux?

Ich glaube, es gibt tatsächlich aktuell ein Problem mit LibreOffice. Keine Ahnung, was da los ist. Ich hab die Screenshots ja auch damit gemacht... Ich verwende den DbVisualizer (www.dbis.com), den müßte es auch für Linux geben.

OK, herzlichen Dank für Deine Zeit und Mühe Ralf.
Ich melde mich wieder wenn ich etwas Neues zu Melden habe.

@rheydenr
Hallo Ralf,

ich habe mehrere DB-Editoren getestet und mich schließlich für „SQLeo Visual Query Builder“ ( http://sqleo.sourceforge.net) entschieden.
SQLeo ist Open-Source, Java und der „Visual Query Builder“ ist dem Base-Editor sehr ähnlich.
Die Treiber-Installation und die Datenbankverbindung sind auch sehr einfach und auch eine Exportfunktion ist dabei.
SQLeo ist also ausreichend für mich und ich kann ihn nur weiterempfehlen.

Ich habe eine Query für den Export der Rechnungen (samt Einzelpositionen) und den Import dieser in GnuCash gemacht, und die Query dann als CSV-Datei exportiert.

Für die Query habe ich diese Tabellen und Felder genommen:
1. FKT_DOCUMENTRECEIVER: CUSTOMERNUMBER
2. FKT_DOCUMENT: CUSTOMERREF, DOCUMENTDATE, ITEMSREBATE, MESSAGE, NAME
3. FKT_DOCUMENTITEM: DATEADDED, ITEMNUMBER, NAME, POSNR, PRICE, QUANTITY, QUANTITYUNIT, FK_VAT

Als ich die CSV-Datei öffnete, musste ich feststellen, dass:
1. CUSTOMERNUMBER war manchmal leer. Dies passiert offensichtlich, wenn ich ein Kunde aus dem Adressbuch auswähle aber dann seine Adresse modifiziere. z.B.:
KD0001: Firma Verkaufalles und ich ergänze dies mit „z.Hd. Frau Muster“ als zweite Zeile im Adressenfenster.
So etwas sollte NICHT passieren.
Ich hoffe, Du bist der gleichen Meinung Ralf, und hoffentlich kannst Du dieses Verhalten von Fakturama ändern.

2. Etwas Ähnliches passiert mit (Produkt-) NAME. Sobald ich die Produktbeschreibung ändere, wird in der Datenbank nur das Wort „Name“ registriert.

3. Felder die Zahlen beinhalten, z.B. PRICE und QUANTITY, schauen so aus: 806.67E0, 24241.
a). Dezimaltrennzeichen ist ein Punkt und nicht Komma.
b). Zahlen mit bis zu 3 Ziffern vor dem Trennzeichen enden auf „E0“
c). Zahlen mit Tausendertrennzeichen wie: 24.241,00 oder 8.546,00 schauen so aus: 24241, 8546 und OHNE „E0“ am Ende.
Dieser Unterschied zwingt mich leider, alle Eintragungen manuell zu prüfen und zu ändern.

RFE:
Ralf, würdest Du bitte, sofern dies technisch möglich ist und sofern auch mehrere andere Fakturama-User dies wünschen, die Export-Funktionalität von Fakturama um eine CSV-Datei für GnuCash erweitern? Die Datei sollte Rechnungen samt Einzelpositionen beinhalten und beim Exportieren sollte man den Zeitraum bzw. „von bis Rechnung“ bestimmen können.

Ich habe EUR-JES und alle andere verfügbare Open-Source Buchhaltungssoftware getestet und mich für GnuCash entschieden und dies, weil GnuCash mit allen möglichen Kontenrahmen herkommt, sowohl für Österreich aber auch Deutschland usw., und besitzt auch ausreichende Banking-Funktionalität.

Schöne Grüße
Konstantin

Veröffentlicht von: @konstantin

1. CUSTOMERNUMBER war manchmal leer. Dies passiert offensichtlich, wenn ich ein Kunde aus dem Adressbuch auswähle aber dann seine Adresse modifiziere. z.B.:
KD0001: Firma Verkaufalles und ich ergänze dies mit „z.Hd. Frau Muster“ als zweite Zeile im Adressenfenster.
So etwas sollte NICHT passieren.
Ich hoffe, Du bist der gleichen Meinung Ralf, und hoffentlich kannst Du dieses Verhalten von Fakturama ändern.

Moin,

das Verhalten werde ich nicht ändern, weil ich es extra so eingebaut habe 🙂 Wenn man einen Kunden ändern möchte kann man das direkt in den Kundenstammdaten machen. Ansonsten ist es nicht mehr derselbe Kunde und deswegen kann er auch nicht mehr unter dieser Kundennummer firmieren. Bei den Produkten muß ich nochmal nachsehen, da sollte das Verhalten ähnlich sein.

Veröffentlicht von: @konstantin

3. Felder die Zahlen beinhalten, z.B. PRICE und QUANTITY, schauen so aus: 806.67E0, 24241.
a). Dezimaltrennzeichen ist ein Punkt und nicht Komma.
b). Zahlen mit bis zu 3 Ziffern vor dem Trennzeichen enden auf „E0“
c). Zahlen mit Tausendertrennzeichen wie: 24.241,00 oder 8.546,00 schauen so aus: 24241, 8546 und OHNE „E0“ am Ende.
Dieser Unterschied zwingt mich leider, alle Eintragungen manuell zu prüfen und zu ändern.

 

Dass müßte ich nochmal prüfen, aber mir ist das noch nie aufgefallen. Andererseits - wenn man mit derartig großen Beträgen hantiert sollte man vielleicht mal über ein kommerzielles Produkt nachdenken... 🙂

Veröffentlicht von: @konstantin

Ralf, würdest Du bitte, sofern dies technisch möglich ist und sofern auch mehrere andere Fakturama-User dies wünschen, die Export-Funktionalität von Fakturama um eine CSV-Datei für GnuCash erweitern?

Kannst Du das als Feature-Wunsch mit in den Bugtracker schreiben? Bislang wollte das noch keiner haben.

Übrigens ist CUSTOMERREF nicht der Fremdschlüssel auf die Kundentabelle, sondern die Kundenreferenz. Der Fremdschlüssel heißt FK_CONTACT.

Hallo Ralf, ich erlaube mir Dich zu widersprechen:

„das Verhalten werde ich nicht ändern, weil ich es extra so eingebaut habe ? Wenn man einen Kunden ändern möchte kann man das direkt in den Kundenstammdaten machen. Ansonsten ist es nicht mehr derselbe Kunde und deswegen kann er auch nicht mehr unter dieser Kundennummer firmieren. Bei den Produkten muß ich nochmal nachsehen, da sollte das Verhalten ähnlich sein.“

Kunde: KD00011

LG Innsbruck

Maximilianstraße 4
6020 Innsbruck

Aber das Landesgericht hat dutzende Abteilungen/Kanzleien (bei Firmen ist oft ähnlich), wenn ich also folgendes schreibe:

LG Innsbruck
Gerichtsabteilung 4

Maximilianstraße 4
6020 Innsbruck

dann sollte m.E. dies nicht als Kundenänderung angesehen werden.
Gleichermaßen, wenn ein Produkt „XY“ um z.B. „Farbe Blau“ ergänzt wird, handelt es sich nicht unbedingt um eine Produktänderung, insbesondere nicht, wenn ich mein Lager ohne Farbdifferenzierung führe.

„Dass müsste ich nochmal prüfen, aber mir ist das noch nie aufgefallen. Andererseits - wenn man mit derartig großen Beträgen hantiert sollte man vielleicht mal über ein kommerzielles Produkt nachdenken... ?“

Bei Zahlen wie 24241, 86956 oder sogar 152784 handelt es sich leider nicht um Geldbeträge, schön wäre es.
Es handelt sich um Schriftzeichen eines Übersetzungsauftrags.

Moin,

tut mir leid, wenn das gerade etwas schroff rüberkam 🙂 Ich werde drüber nachdenken. Es gibt ja dazu auch schon einen Feature-Wunsch.