[gnucash-de] (bessere) Zukunft der GnuCash Formulare, war: Neues GitHub Repository: Rechnungen mit Latex

Do Nov 13 05:52:09 EST 2014

Hallo Marcus,

zu unseren Überlegungen. John Ralls wies mich in der developer Liste darauf hin,
daß keine Abhängigkeit des Hauptprogramms von Python Erweiterungen von den
Entwicklern intendiert ist. Also ist in dem Sinne alles, was externes Programm ist
unproblematisch. Eine Integration in das GUI würde diese Grenze überschreiten.
Das intendiere ich eigentlich auch nicht. Ich fände das nett, bin aber mit der Komman-
dozeile aktuell völlig zufrieden - ob mein Knopf im oder neben dem GnuCash GUI ist,
ist mir dann auch ein stückweit egal, solange ich die volle Kontrolle über den
Prozess habe.

Ich habe mir heute eine XML Datei angesehen und per Hand geändert.
https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=36628
beschreibt den Prozess.

Wenn ich ein XML Template nehme, könnte ich den Jinja-code direkt in der
XML-Datei in openoffice schreiben. Dann muß man das Dokument unzippen,
die entsprechende Datei mit gncinvoice_jinja.py bearbeiten und das Dokument
wieder zippen.

Jetzt bräuchte man im Grunde nur ein schönes freies ODT Rechnungs-Template,
das entsprechend modifiziert werden kann.

Wobei die eigentliche Tabelle, die im ODT noch Kommandoelemente enthält,
etwas komplizierter sein könnte.

herzlichen Gruß,

Christoph

Am 13.11.2014 um 00:43 schrieb Christoph Holtermann:
>
> Hallo Marcus,
>
> Am 12.11.2014 um 23:50 schrieb Marcus Wellnitz:
>
> > Hallo Christoph und alle Anderen,
>
> > (die spannenden Teile dieser Email kommen am Schluss!)
>
> > gerade habe ich mir die Homepage von jinja2 einmal angeschaut. Den Vorteil kann ich im Moment nicht so ganz sehen aber ist auch egal, hauptsache es kommt dabei etwas heraus, was ansehnlich aussieht :-)
> Der Vorteil ist die Flexibilität. Man hat ein beliebiges Template, sei es LaTeX, XML, CSV, HTML, was immer. Darin bringt man
> dann Marker, Anweisungen unter, welche Informationen wo eingefügt werden sollen. Das kommt typischerweise bei Webseiten vor,
> wo ein statischer HTML-Rahmen mit dynamischem content aufgefüllt wird. Hier ist es z.B.
>
> \setkomavar{invoice}{
>         {{ invoice.GetID() }}
> }%% Rechnungsnummer
>
> oder etwas komplexer
>
> \setkomavar{fromaddress}{ {{ company.GetAddress().replace("\n","\\\\") }} }
>
> der Teil {{ invoice.GetID() }} und {{ company.GetAddress().replace("\n","\\\\") }} ist jinja2-code. Vom Skript wird dem Template ein
> oder mehrere Objekte übergeben, mit denen dann das Template ausgefüllt wird. Es lassen sich auch Formatierungsanweisungen
> im Template unterbringen.
>
> Ich finde das zudem recht elegant.
>
> > Wie ich gesehen habe, hast Du einen kompletten Branch von gnucash gemacht: Respekt, da habe ich mich bisher nicht heran gewagt, wollte eher einen ersten Schuss haben, der schnell läuft und der dann ausbaufähig wird.
>
> Ich habe schon etwas länger hin und wieder an GnuCash gearbeitet. Insbesondere der Zugriff auf die Daten durch Python war
> mir wichtig.
>
> > Die Python-Implementierung scheint auch nicht so ganz stable zu sein. Der code ist schon sehr alt und hatte lt. Quellcode-Doku eher prototypischen Charakter. Aktuell habe ich das Problem, dass die Fehlermeldung
> > * 23:58:19  CRIT <GLib> g_date_time_format: assertion 'datetime != NULL' failed
> > * 23:58:19  CRIT <GLib> g_date_time_unref: assertion 'datetime != NULL' failed
>
> Ist das der im GnuCash-Executable beinhaltete Teil ?
>
> > bei der Anmeldung an der Datenbank geworfen wird und die Anwendung core-dumped.
> > Ganz so tief bin ich nun noch nicht in die untiefen herabgegangen, hat aber sicherlich etwas mit kürzlich eingespielten Updates zu tun :-(
> > Veränderungen an meinem Code jedenfalls sind nicht die Ursache.
>
> > Die Python-Implementierung meldet sich quasi direkt an der Datenbank an, was lt. Doku nicht ganz unkritisch ist, wenn 2 Instanzen gleichzeitig auf die Datenbank zugreifen. Ich verstehe zwar nicht warum (schlampige Implementierung?) aber gehe davon aus, dass ein lesender Zugriff keine Probleme verursacht.
> Lesender Zugriff sollte in Bezug auf Datenverluste sicher sein. Allerdings habe ich bemerkt, daß die Aktualisierung der Daten
> wie auch immer getriggert werden muß. Ich habe eine Rechnung im GUI verändert und im parallel laufenden python trat die
> Änderung erst nach beenden und neu starten in Erscheinung. Mir fiel das gerade ein Mal auf, man müsste das weiter beobachten.
>
> GnuCash hat als standalone Applikation angefangen mit XML Backend, dann kam das SQL-Backend dazu und erst daraus entstand
> die Begehrlichkeit mit mehreren Leuten gleichzeitig zugreifen zu können. Ich weiß nicht, ob oder eher wann das ein Ziel ist.
> > Der Übergabeparameter ist in diesem Fall nur die Rechnungsnummer. Alle anderen Daten werden dann aus der Datenbank ausgelesen.
> > Schön wäre in diesem Zusammenhang natürlich ein Flag "Rechnung erzeugt" oder so oder ggf. sogar das Einbinden eines Aufruf-Links "Rechnung ansehen".
> Genau.
>
> > Wie funktioniert das mit Deiner Implementierung? Wird die direkt aus Gnucash angetriggert und alle Daten quasi als Parameter übergeben? Oder erzeugst Du in Gnucash kompletten Latex-Code, der in eine Datei geschrieben wird und direkt aufgerufen/ausgeführt?
> In jedem Fall werden die python-bindings von gnucash eingebunden, mit denen ein Zugriff auf die Daten erfolgt. Dann lese
> ich die Daten des invoice aus.
> in latex_invoices formatiere ich die so, daß eine Datei erzeugt wird (data.lco), die Variablen/Kommandodefinitionen enthält, also
> in etwa
> \newkomavar{date_due}
> \setkomavar{date_due}{01.01.1970}
>
> Hier bleibt die Datei Invoice.tex immer erhalten, nur die eingebundene data.lco wird jeweils neu geschrieben. Die Formatierungs-
> informationen liegen im script latex_invoices.
>
> Mit jinja habe ich wie oben beschrieben ein Template, das eingelesen wird. Dann wird erst die Ausgabedatei Invoice.tex erzeugt,
> die dann wieder in LaTeX gegeben werden kann.
>
> Ich rufe das Skript jeweils in der Shell auf. Der Aufruf jetzt war dann
> python gncinvoice_jinja.py -t Invoice_2.tex.tmpl -o Invoice_2.tex -I "000029" mysql://christoph:kaffee@localhost/gnucash && latex --output-format=pdf --output-format=pdf Invoice_2.tex
>
> Das wiederum liesse sich ja innerhalb von GnuCash mit einem Knöpfchen vermutlich verhältnismässig einfach triggern. Und die erzeugte Datei könnte dann (in etwas weiterer Perspektive) als KVP an eine Buchung gespeichert werden. Denn die einmal erzeugte Datei
> sollte ja im besten Falle erhalten bleiben, um Dokumentenstatus zu haben.
>
> Ich habe auch die Dokumentation zu meinen Erweiterungen geschrieben. Hauptsächlich in Doxygen. Das kann ich zwar offline bei mir
> ansehen, wenn es online sein soll, muß erst mein commit akzeptiert werden. Du kannst Dir sonst auch
> https://github.com/c-holtermann/gnucash/blob/master/src/optional/python-bindings/example_scripts/invoice_export_doxygen.txt
> als Sourcecode ansehen.
>
> Ich habe auch ein Beispieltemplate für eine Latexrechnung eingefügt, die ohne das rechnung.sty auskommt, das mir auch
> nicht so gut gefiel wegen der unklaren Lizenzierung. Deshalbt hatte ich es auch nicht in das example_script Verzeichnis getan
> und mit GnuCash zusammen liefern lassen.
>
> > Hast du den Ehrgeiz, ALLES über die Gnucash-Oberfläche abzuwickeln, einschließlich eines Formular-Editors? (Stichwort: gescannte Unterschrift, Anpassung der Optik, etc.)
> Eher nicht. Ich habe wenig bis keine Erfahrung mit GUI-Programmierung. Schritte in die Richtung würden lange dauern, wenn ich
> sie auch unternehmen werde. Die Shell ist mir sowieso sehr lieb. Und das interessante an Templates ist, daß der Nutzer total frei
> ist, in welche Art von Datei und mit welcher Formatierung er die Daten einfügen möchte.
>
> > Lass uns auf jeden Fall zusammenarbeiten bzw. uns austauschen, damit ein wirklicher Mehrwert (sprich: Addon) für GnuCash dabei herauskommt.
> > Hast Du Dir das Wiki einmal genauer angeschaut? Speziell die Links zu den PDF/A-1a (Mustang/ZUGFeRD) Dokumenten?
> > https://github.com/mwellnitz/gnucash-latex/wiki
>
> > Dort habe ich unter "Gute Aussichten" und "Links" einige Zukunftsperspekptiven aufgezeigt.
>
> Bisher noch nicht.
>
> > Die Erzeugung von Dokumenten, die der (deutschen Version der) vollständigen elektronischen Aufbewahrung genügen wäre sicherlich ein bahnbrechendes Argument _für_ Gnucash und würde die Software deutlich aufwerten, oder?
>
> Absolut. Ein interessantes Ziel.
> > LaTeX habe ich im Übrigen nicht gewählt, weil es das "einzig wahre" Tool für mich ist, sondern einfach weil sich damit schnell sehr gute Ergebnisse erzielen lassen und es schon eine Basisimplementierung von den GnuCash-Machern gab. Für die Zukunft würde ich mich auch nicht darauf festlegen, zumal es (mein derzeitiger Kenntnisstand) kein PDF/A-1a-Support für LaTeX gibt. Hier ist ggf. ein Umstieg auf OpenOffice/LibreOffice sinnvoller. Allerdings sind hier meine Kenntnisse zur Autogenerierung von Dokumenten nur rudimentär (machbar ist es!). Ich weiß nur, dass O/L-Office für alle Zielplatformen verfügbar ist und somit eine Dependency von GnuCash zu diesen Systemen verschmerzbar ist.
> Ich vermute, daß eine O/L-XML-Datei sich genauso als Template einsetzen liesse. Das wäre recht spannend auszuprobieren,
> ich würde gerne eine paar interessante Templates zu der neuen Version des Rechnungsimports dazugeben.
>
> > Meine Zeit, die ich in dieses Projekt stecken kann ist leider endlich (max. ein paar Stunden/Woche) und ich möchte, dass es nicht vergebens ist.
> Bei mir ist es aktuell eher ein Urlaubsprojekt ( aktuell Dänemark ;-). Und sonst ist meine Zeit ähnlich begrenzt.
> > In diesem Sinne hoffe ich auf eine fruchtbare Diskussion.
> Ganz meinerseits !
>
> > Liebe Grüße aus dem spätsommerlichen Haifa
>
> > Marcus
> herzlichen Gruß,
>
> Christoph
>
> > Am 12.11.2014 um 22:16 schrieb Christoph Holtermann:
>
> > > Hallo,
>
> > > ich habe auch gerade in diesen Tagen an LaTeX Rechnungen
> > > weitergearbeitet und werde mir gerne Ihre Erweiterungen ansehen !
> > > Ich arbeite gerade daran, die Companydaten direkt aus GnuCash
> > > einzulesen und habe ein Templatingsystem auf jinja2 eingesetzt.
> > > Der letzte Stand ist gerade
> > > https://github.com/c-holtermann/gnucash/tree/python-kvp
>
> > > es freut mich, daß ich nicht der Einzige bin, der LaTeX für
> > > Rechnungen nutzen will !
>
> > > herzlichen Gruß,
>
> > > Christoph Holtermann
>
> > [...]
>
>
>
> > _______________________________________________
> > gnucash-de mailing list
> > gnucash-de at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-de
>
>
>
>
> _______________________________________________
> gnucash-de mailing list
> gnucash-de at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-de

-- 
--- Nachricht gesendet von C. Holtermann ---
-                                          -
-  Verschlüsselte Nachrichten können über  -
- den öffentlichen Schlüssel auf folgendem -
- Keyserver an mich gesendet werden:       -
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20141113/350ab45f/attachment.html>