[gnucash-de] (bessere) Zukunft der GnuCash Formulare, war: Neues GitHub Repository: Rechnungen mit Latex
Christoph Holtermann
c.holtermann at gmx.de
Do Nov 13 06:08:23 EST 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 :-)
> 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.
>
> 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
>
> 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.
> 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".
>
> 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?
>
> Hast du den Ehrgeiz, ALLES über die Gnucash-Oberfläche abzuwickeln, einschließlich eines Formular-Editors? (Stichwort: gescannte Unterschrift, Anpassung der Optik, etc.)
>
> 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.
>
> 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?
Das ist eine Frage des Templates und des Aufrufs von LaTeX und sollte laut den Internetquellen möglich sein, z.B. mit pdfx.
>
> 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.
Ausschlaggebender ist wie in meiner Vormail gesagt die Frage der Abhängigkeit von Python. Wenn man nur dieses Extraprojekt
betrachtet ist sowohl LaTeX als auch Openoffice möglich. LaTeX gefällt mir persönlich einfach besser, aber ich finde es reizvoll,
wenn auch der Weg über Openofice offen steht.
>
> 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.
> In diesem Sinne hoffe ich auf eine fruchtbare Diskussion.
>
> 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
- --
- --- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlRkkScACgkQTdnPBIKwYgtenwCfXVzIEoG9mG9MIiikPp76sxNF
XzIAoIsC3KwecPqYl1cAnKdVbzn6LnaF
=iITO
-----END PGP SIGNATURE-----
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.gnucash.org/pipermail/gnucash-de/attachments/20141113/7e0e855d/attachment-0001.html>
Mehr Informationen über die Mailingliste gnucash-de