<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE-----<br>
    Hash: SHA1<br>
    <br>
    Hallo Marcus,<br>
    <br>
    Am 12.11.2014 um 23:50 schrieb Marcus Wellnitz:<br>
    <span style="white-space: pre;">><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 :-)</span><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>
    <span style="white-space: pre;">> 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.</span><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>
    <span style="white-space: pre;">><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>
      ></span><br>
    Ist das der im GnuCash-Executable beinhaltete Teil ?<br>
    <br>
    <span style="white-space: pre;">> 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.</span><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>
    <span style="white-space: pre;">> 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".</span><br>
    Genau.<br>
    <span style="white-space: pre;">><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?</span><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>
    <span style="white-space: pre;">><br>
      > Hast du den Ehrgeiz, ALLES über die Gnucash-Oberfläche
      abzuwickeln, einschließlich eines Formular-Editors? (Stichwort:
      gescannte Unterschrift, Anpassung der Optik, etc.)</span><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>
    <span style="white-space: pre;">><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>
      ></span><br>
    Bisher noch nicht.<br>
    <br>
    <span style="white-space: pre;">> 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>
      ></span><br>
    Absolut. Ein interessantes Ziel.<br>
    <span style="white-space: pre;">> 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.</span><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>
    <span style="white-space: pre;">><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.</span><br>
    Bei mir ist es aktuell eher ein Urlaubsprojekt ( aktuell Dänemark
    ;-). Und sonst ist meine Zeit ähnlich begrenzt.<br>
    <span style="white-space: pre;">> In diesem Sinne hoffe ich auf
      eine fruchtbare Diskussion.</span><br>
    Ganz meinerseits !<br>
    <span style="white-space: pre;">><br>
      > Liebe Grüße aus dem spätsommerlichen Haifa<br>
      ><br>
      > Marcus</span><br>
    herzlichen Gruß,<br>
    <br>
    Christoph<br>
    <span style="white-space: pre;">><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></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>
    -----BEGIN PGP SIGNATURE-----<br>
    Version: GnuPG v2.0.22 (GNU/Linux)<br>
    <br>
    iEYEARECAAYFAlRj8JkACgkQTdnPBIKwYgtaUwCdFAv10cUQ5ukjagZcGPx1IaFy<br>
    uuMAnim6oLQjP1Xsts61cZpz+0XOkNra<br>
    =p3nA<br>
    -----END PGP SIGNATURE-----<br>
    <br>
  </body>
</html>