<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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 :-)<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>
> 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>
> 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>
> 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>
><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>
><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>
><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>
> 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?</span><br>
Das ist eine Frage des Templates und des Aufrufs von LaTeX und
sollte laut den Internetquellen möglich sein, z.B. mit pdfx.<br>
<span style="white-space: pre;">><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.</span><br>
Ausschlaggebender ist wie in meiner Vormail gesagt die Frage der
Abhängigkeit von Python. Wenn man nur dieses Extraprojekt<br>
betrachtet ist sowohl LaTeX als auch Openoffice möglich. LaTeX
gefällt mir persönlich einfach besser, aber ich finde es reizvoll,<br>
wenn auch der Weg über Openofice offen steht.<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.<br>
> In diesem Sinne hoffe ich auf eine fruchtbare Diskussion.<br>
><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>
iEYEARECAAYFAlRkkScACgkQTdnPBIKwYgtenwCfXVzIEoG9mG9MIiikPp76sxNF<br>
XzIAoIsC3KwecPqYl1cAnKdVbzn6LnaF<br>
=iITO<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>