<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hallo Marcus,<br>
<br>
zu unseren Überlegungen. John Ralls wies mich in der developer Liste
darauf hin,<br>
daß keine Abhängigkeit des Hauptprogramms von Python Erweiterungen
von den<br>
Entwicklern intendiert ist. Also ist in dem Sinne alles, was
externes Programm ist<br>
unproblematisch. Eine Integration in das GUI würde diese Grenze
überschreiten.<br>
Das intendiere ich eigentlich auch nicht. Ich fände das nett, bin
aber mit der Komman-<br>
dozeile aktuell völlig zufrieden - ob mein Knopf im oder neben dem
GnuCash GUI ist,<br>
ist mir dann auch ein stückweit egal, solange ich die volle
Kontrolle über den <br>
Prozess habe.<br>
<br>
Ich habe mir heute eine XML Datei angesehen und per Hand geändert.<br>
<a class="moz-txt-link-freetext" href="https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=36628">https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=36628</a><br>
beschreibt den Prozess. <br>
<br>
Wenn ich ein XML Template nehme, könnte ich den Jinja-code direkt in
der<br>
XML-Datei in openoffice schreiben. Dann muß man das Dokument
unzippen,<br>
die entsprechende Datei mit gncinvoice_jinja.py bearbeiten und das
Dokument<br>
wieder zippen.<br>
<br>
Jetzt bräuchte man im Grunde nur ein schönes freies ODT
Rechnungs-Template,<br>
das entsprechend modifiziert werden kann.<br>
<br>
Wobei die eigentliche Tabelle, die im ODT noch Kommandoelemente
enthält,<br>
etwas komplizierter sein könnte.<br>
<br>
herzlichen Gruß,<br>
<br>
Christoph<br>
<br>
Am 13.11.2014 um 00:43 schrieb Christoph Holtermann:<br>
<span style="white-space: pre;">></span><br>
<blockquote type="cite">Hallo Marcus,<br>
<br>
Am 12.11.2014 um 23:50 schrieb Marcus Wellnitz:<br>
<br>
> Hallo Christoph und alle Anderen,<br>
<br>
> (die spannenden Teile dieser Email kommen am Schluss!)<br>
<br>
> 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 :-)<br>
Der Vorteil ist die Flexibilität. Man hat ein beliebiges Template,
sei es LaTeX, XML, CSV, HTML, was immer. Darin bringt man<br>
dann Marker, Anweisungen unter, welche Informationen wo eingefügt
werden sollen. Das kommt typischerweise bei Webseiten vor,<br>
wo ein statischer HTML-Rahmen mit dynamischem content aufgefüllt
wird. Hier ist es z.B.<br>
<br>
\setkomavar{invoice}{<br>
{{ invoice.GetID() }}<br>
}%% Rechnungsnummer<br>
<br>
oder etwas komplexer<br>
<br>
\setkomavar{fromaddress}{ {{
company.GetAddress().replace("\n","\\\\") }} }<br>
<br>
der Teil {{ invoice.GetID() }} und {{
company.GetAddress().replace("\n","\\\\") }} ist jinja2-code. Vom
Skript wird dem Template ein<br>
oder mehrere Objekte übergeben, mit denen dann das Template
ausgefüllt wird. Es lassen sich auch Formatierungsanweisungen<br>
im Template unterbringen.<br>
<br>
Ich finde das zudem recht elegant.<br>
<br>
> 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.<br>
<br>
Ich habe schon etwas länger hin und wieder an GnuCash gearbeitet.
Insbesondere der Zugriff auf die Daten durch Python war<br>
mir wichtig.<br>
<br>
> 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<br>
> * 23:58:19 CRIT <GLib> g_date_time_format: assertion
'datetime != NULL' failed<br>
> * 23:58:19 CRIT <GLib> g_date_time_unref: assertion
'datetime != NULL' failed<br>
<br>
Ist das der im GnuCash-Executable beinhaltete Teil ?<br>
<br>
> bei der Anmeldung an der Datenbank geworfen wird und die
Anwendung core-dumped.<br>
> Ganz so tief bin ich nun noch nicht in die untiefen
herabgegangen, hat aber sicherlich etwas mit kürzlich
eingespielten Updates zu tun :-(<br>
> Veränderungen an meinem Code jedenfalls sind nicht die
Ursache.<br>
<br>
> 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.<br>
Lesender Zugriff sollte in Bezug auf Datenverluste sicher sein.
Allerdings habe ich bemerkt, daß die Aktualisierung der Daten<br>
wie auch immer getriggert werden muß. Ich habe eine Rechnung im
GUI verändert und im parallel laufenden python trat die<br>
Änderung erst nach beenden und neu starten in Erscheinung. Mir
fiel das gerade ein Mal auf, man müsste das weiter beobachten.<br>
<br>
GnuCash hat als standalone Applikation angefangen mit XML Backend,
dann kam das SQL-Backend dazu und erst daraus entstand<br>
die Begehrlichkeit mit mehreren Leuten gleichzeitig zugreifen zu
können. Ich weiß nicht, ob oder eher wann das ein Ziel ist.<br>
> Der Übergabeparameter ist in diesem Fall nur die
Rechnungsnummer. Alle anderen Daten werden dann aus der Datenbank
ausgelesen.<br>
> 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".<br>
Genau.<br>
<br>
> 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?<br>
In jedem Fall werden die python-bindings von gnucash eingebunden,
mit denen ein Zugriff auf die Daten erfolgt. Dann lese<br>
ich die Daten des invoice aus.<br>
in latex_invoices formatiere ich die so, daß eine Datei erzeugt
wird (data.lco), die Variablen/Kommandodefinitionen enthält, also<br>
in etwa<br>
\newkomavar{date_due}<br>
\setkomavar{date_due}{01.01.1970}<br>
<br>
Hier bleibt die Datei Invoice.tex immer erhalten, nur die
eingebundene data.lco wird jeweils neu geschrieben. Die
Formatierungs-<br>
informationen liegen im script latex_invoices.<br>
<br>
Mit jinja habe ich wie oben beschrieben ein Template, das
eingelesen wird. Dann wird erst die Ausgabedatei Invoice.tex
erzeugt,<br>
die dann wieder in LaTeX gegeben werden kann.<br>
<br>
Ich rufe das Skript jeweils in der Shell auf. Der Aufruf jetzt war
dann<br>
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<br>
<br>
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<br>
sollte ja im besten Falle erhalten bleiben, um Dokumentenstatus zu
haben.<br>
<br>
Ich habe auch die Dokumentation zu meinen Erweiterungen
geschrieben. Hauptsächlich in Doxygen. Das kann ich zwar offline
bei mir<br>
ansehen, wenn es online sein soll, muß erst mein commit akzeptiert
werden. Du kannst Dir sonst auch<br>
<a class="moz-txt-link-freetext" href="https://github.com/c-holtermann/gnucash/blob/master/src/optional/python-bindings/example_scripts/invoice_export_doxygen.txt">https://github.com/c-holtermann/gnucash/blob/master/src/optional/python-bindings/example_scripts/invoice_export_doxygen.txt</a><br>
als Sourcecode ansehen.<br>
<br>
Ich habe auch ein Beispieltemplate für eine Latexrechnung
eingefügt, die ohne das rechnung.sty auskommt, das mir auch<br>
nicht so gut gefiel wegen der unklaren Lizenzierung. Deshalbt
hatte ich es auch nicht in das example_script Verzeichnis getan<br>
und mit GnuCash zusammen liefern lassen.<br>
<br>
> Hast du den Ehrgeiz, ALLES über die Gnucash-Oberfläche
abzuwickeln, einschließlich eines Formular-Editors? (Stichwort:
gescannte Unterschrift, Anpassung der Optik, etc.)<br>
Eher nicht. Ich habe wenig bis keine Erfahrung mit
GUI-Programmierung. Schritte in die Richtung würden lange dauern,
wenn ich<br>
sie auch unternehmen werde. Die Shell ist mir sowieso sehr lieb.
Und das interessante an Templates ist, daß der Nutzer total frei<br>
ist, in welche Art von Datei und mit welcher Formatierung er die
Daten einfügen möchte.<br>
<br>
> Lass uns auf jeden Fall zusammenarbeiten bzw. uns
austauschen, damit ein wirklicher Mehrwert (sprich: Addon) für
GnuCash dabei herauskommt.<br>
> Hast Du Dir das Wiki einmal genauer angeschaut? Speziell die
Links zu den PDF/A-1a (Mustang/ZUGFeRD) Dokumenten?<br>
> <a class="moz-txt-link-freetext" href="https://github.com/mwellnitz/gnucash-latex/wiki">https://github.com/mwellnitz/gnucash-latex/wiki</a><br>
<br>
> Dort habe ich unter "Gute Aussichten" und "Links" einige
Zukunftsperspekptiven aufgezeigt.<br>
<br>
Bisher noch nicht.<br>
<br>
> 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?<br>
<br>
Absolut. Ein interessantes Ziel.<br>
> 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.<br>
Ich vermute, daß eine O/L-XML-Datei sich genauso als Template
einsetzen liesse. Das wäre recht spannend auszuprobieren,<br>
ich würde gerne eine paar interessante Templates zu der neuen
Version des Rechnungsimports dazugeben.<br>
<br>
> 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.<br>
Bei mir ist es aktuell eher ein Urlaubsprojekt ( aktuell Dänemark
;-). Und sonst ist meine Zeit ähnlich begrenzt.<br>
> In diesem Sinne hoffe ich auf eine fruchtbare Diskussion.<br>
Ganz meinerseits !<br>
<br>
> Liebe Grüße aus dem spätsommerlichen Haifa<br>
<br>
> Marcus<br>
herzlichen Gruß,<br>
<br>
Christoph<br>
<br>
> Am 12.11.2014 um 22:16 schrieb Christoph Holtermann:<br>
<br>
> > Hallo,<br>
<br>
> > ich habe auch gerade in diesen Tagen an LaTeX Rechnungen<br>
> > weitergearbeitet und werde mir gerne Ihre Erweiterungen
ansehen !<br>
> > Ich arbeite gerade daran, die Companydaten direkt aus
GnuCash<br>
> > einzulesen und habe ein Templatingsystem auf jinja2
eingesetzt.<br>
> > Der letzte Stand ist gerade<br>
> > <a class="moz-txt-link-freetext" href="https://github.com/c-holtermann/gnucash/tree/python-kvp">https://github.com/c-holtermann/gnucash/tree/python-kvp</a><br>
<br>
> > es freut mich, daß ich nicht der Einzige bin, der LaTeX
für<br>
> > Rechnungen nutzen will !<br>
<br>
> > herzlichen Gruß,<br>
<br>
> > Christoph Holtermann<br>
<br>
> [...]<br>
<br>
<br>
<br>
> _______________________________________________<br>
> gnucash-de mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:gnucash-de@gnucash.org">gnucash-de@gnucash.org</a><br>
> <a class="moz-txt-link-freetext" href="https://lists.gnucash.org/mailman/listinfo/gnucash-de">https://lists.gnucash.org/mailman/listinfo/gnucash-de</a><br>
<br>
</blockquote>
<span style="white-space: pre;">><br>
><br>
><br>
> _______________________________________________<br>
> gnucash-de mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:gnucash-de@gnucash.org">gnucash-de@gnucash.org</a><br>
> <a class="moz-txt-link-freetext" href="https://lists.gnucash.org/mailman/listinfo/gnucash-de">https://lists.gnucash.org/mailman/listinfo/gnucash-de</a></span><br>
<br>
-- <br>
--- Nachricht gesendet von C. Holtermann ---<br>
- -<br>
- Verschlüsselte Nachrichten können über -<br>
- den öffentlichen Schlüssel auf folgendem -<br>
- Keyserver an mich gesendet werden: -<br>
<a class="moz-txt-link-freetext" href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B">http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4DD9CF0482B0620B</a><br>
<br>
</body>
</html>