puh, das haut einen ja glatt um... so viele Meldungen. Da hab ich ja noch ganz schön zu tun... 🙂 Besten Dank erst mal an die fleißigen Tester! Das sind alles Dinge, die mir selber nicht (mehr) aufgefallen sind.

@3xhossa: (Menüpunkt "Extras - Dokumente neu organisieren" )
Den Menüpunkt gab's ja früher auch schon. Der sorgt im Prinzip dafür, daß die vorhandenen Dokumente anhand der neuen Formateinstellung in eine neue Verzeichnisstruktur verschoben werden. Der Pfad zum (alten) Arbeitsverzeichnis ist in den Dokumenten direkt gespeichert (in der Datenbank), wird also bei der Migration so auch mit übernommen. Wenn man das jetzt durch die Reorganisation jagt werden natürlich die (physisch im alten Verzeichnis befindlichen) Dateien an die durch die Einstellung definierte Position verschoben. Das ist natürlich gerade beim Wechsel zwischen Version 1.x und 2.x etwas unschön, da es einem die Dokumente aus der 1.x wegputzt. Ansonsten ist das Verhalten aber tatsächlich so gewollt, da es ja eben eine "Re-"Organisation ist.

(der fehlende Zeilenumbruch im Artikelfeld)
Das schaue ich mir nochmal an. Gerade im Umfeld der Dokumentengenerierung habe ich einiges umgebaut, da kann es durchaus sein, daß ich nicht alles erwischt habe. Z. B. auch die Sache mit der überflüssigen Rabattzeile, das habe ich schlicht übersehen. Geht es jetzt eigentlich um den Zeilenumbruch im Adressfeld oder im Artikelfeld? Hier ist irgendwie von beidem die Rede.

Und ja - es können jetzt beliebig viele Artikeltabellen definiert werden. Und das mit der unterschiedlichen Formatierung in einer Tabellenzelle habe ich (endlich) auch hinbekommen.

Die Neuorganisation ist nach wie vor ein wichtiges Feature und sollte so beibehalten werden. Doch beim Upgrade ist es auch wünschenswert, wie du schon schriebst, dass die alte Installation bzw die Dokumentenablage intakt bleibt. Hier wäre ein Kopieren der Dokumente vielleicht ein gangbarer Mittelweg.
Aber:
Andererseits bedeutet ein Upgrade auch, dass der Benutzer sich vorher bereits ein Backup seiner Datenstruktur angelegt haben sollte. Darauf wird er bei der Installation hingewiesen und es sollte auch seinem gesunden Menschenverstand entsprechen. So gesehen würde ein Hinweis auf die Folgen der Reorganisation vielleicht ausreichen. Du könntest einen zusätzlichen Dialog öffnen, der klar darauf hinweist, dass auch die Dokumente aus der alten Installation betroffen sein werden. Wenn der Benutzer das abnickt, hast du freie Bahn die alte Struktur zu eliminieren.
Eine dritte, etwas halbgare Lösung wäre, nur die Dokumente des aktuellen Jahres aus der alten Installation zu bearbeiten. Hintergrund dafür wäre, dass vergangene Jahre, die bereits abgeschlossen sind (ggf auch durch externe Prozesse wie Übergabe der Unterlagen an Steuerberater etc) gar nicht mehr angefasst werden sollten. Allerdings könnte dieser Weg zu einiger Verwirrung führen. Schließlich gibt es auch Betriebe, deren Geschäftsjahr nicht mit dem Kalenderjahr identisch ist.

Das mit den Zeilenumbrüchen ist wahrscheinlich etwas durcheinander geraten. Es scheint da zwei voneinander unabhängige Probleme zu geben:

1. Der Umbruch im Artikelfeld, der durch die Adressdefinition innerhalb des Platzhalters erzeugt werden sollte. Ich verwende ebenfalls <DOCUMENT.ADDRESS>, welcher bisher die Adresse auf mehrere Zeilen aufgeteilt hatte.

2. Das optionale Argument "%NL", das an einen Platzhalter angehängt werden kann, scheint nicht ausgewertet zu werden. Unabhängig davon ob es in der Artikeltabelle oder in einem Fließtext verwendet wird. Hier habe ich folgende Konstrukte getestet:
innerhalb der Artikeltabelle und
im Fließtext des Dokuments.
Das Einfügen eines Textes dagegen funktioniert:
. An der grundsätzlichen Auswertung des PRE-Operators scheitert es also nicht.

Weitere Ersetzungen habe ich noch nicht ausprobiert. Ich habe im Hinterkopf dass es bereits in V1 Probleme bei anderen Ersetzungen gab, da muss ich mich heute mal ranmachen.

Soll ich zu den einzelnen Problemen Tickets aufmachen oder reicht es dir hier im Forum?

(tu) für die Platzhalterfeature

Hallo 3xhossa,
die idee mit dem Warnhinweis finde ich sehr gut. Das werde ich so umsetzen. Ich hab mir das jetzt alles rausgeschrieben, das geht so ohne Ticket.

@hjg2000

- Wo sind die Gutschriften geblieben? Die vermisse ich jetzt.

Das war einer der Punkte, den ich schon sehr lange vor mir herschiebe. Die "Gutschrift" in diesem Sinne gibt es so nicht (da hat hier ein langjähriger Fakturama-User schon mal ausführlich was dazugeschrieben). Das Ding heißt jetzt "Rechnungskorrektur" und muß auch so bezeichnet werden. Etwas anderes ist die "inverse Rechnung" oder "Rechnung im Gutschriftverfahren", aber das habe ich hier nicht implementiert.

- Es gibt evtl. Sinn, bei den Kunden neben der USt-Id-Nr. auch noch die UsSt.-Nr.
eintragen zu können

Das Attribut kannte ich noch nicht. Aber wenn Du wahlweise USt.-Id oder UsSt.-Nr. hast kannst Du das doch auch in dasselbe Feld schreiben, auf der Rechnung wird es ja vermutlich auch an derselben Stelle stehen.

Die Startzeit habe ich schon wesentlich verkürzen können. Hier ist die Bremse die Datenbank. Wenn Du das ganze auf MySQL installierst geht's auch schneller. Ich wollte aber nicht jedem User die Installation einer Datenbank zumuten.

Hallo,

erst einmal vielen Dank für die fleissige Entwicklung!
Der Alt Daten Import hat sehr gut funktioniert.

Meine Einsatzumgebung:
Windows 10 PC mit Synology NAS Mysql / MariaDB

Jetzt zu dem Problemen:
1. die bereits beschriebene Spaltenproblematik in den Tabellen,
führt teilweise dazu das nicht mehr mit einzelnen Masken gearbeitet werden kann.

2. Wird immer der Zahlungsbedingungstext für 'Bezahlt' in den <PAYMENT.TEXT> gedruckt.
obwohl der Haken in der Rechnung nicht gesetzt ist.

3. Das bereits erwähnte öffnen des Dokumentes mit Libre Office zwecks Nachbearbeitung.

4. Es scheinen die Import Funktionen für Kunden und Artikel noch nicht wieder zu funktionieren.
Mann kann die CSV Datei auswählen aber es passiert nichts.

Das war es fürs erste.

Viele Grüße aus Haltern am See
Axel Berse

Hallo Axel,
danke für die Rückmeldung. Der Import sollte eigentlich funktionieren, das hatte ich auch getestet. Kannst Du mal bitte ins Logfile schauen, ob da irgendwas Interessantes drinsteht?

rheydenr schrieb:
-------------------------------------------------------

Hier hat mir Dein Logfile weitergeholfen:

java.io.IOException: Cannot run program
""/usr/lib/libreoffice/program/soffice" -headless
-convert-to pdf:writer_pdf_Export --outdir
"/home/irgendwas/PDF/2017/Rechnungen"
"/home/irgendwas/ODT/2017/Rechnungen/RE000520_irge
ndwer.ODT"": error=2, Datei oder Verzeichnis nicht
gefunden

Stimmen die Pfade? Hast Du mal geprüft, ob die
ODT-Datei wirklich dort liegt? Liegt vielleicht
LibreOffice woanders?

Hallo zusammen,
habe hier (Ubuntu 16.04) das gleiche Problem mit dem Speichern der PDF Dateien.
Die Pfade sind in Ordnung, die .ODT ist auch vorhanden und die Rechte der Ordner sind ebenfals so wie sie sein müssen.
Nach einigen Versuchen in der Konsole, mit dem Befehl der im Log erscheint, stellte sich heraus, dass die Konvertierung funktioniert wenn man die äußeren "" weg lässt.
Des weiteren meckert LibreOffice 5 an, dass die Option "-convert-to" veraltet ist und man solle doch "--convert-to" verwenden.

Ist es möglich die äußeren "" in einer Config zu entfernen oder ist das im Code enthalten?

Grüße
Danny

!SESSION 2017-04-09 09:32:45.138 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_111
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Command-line arguments: -os win32 -ws win32 -arch x86_64

!ENTRY org.eclipse.equinox.ds 1 0 2017-04-09 09:32:57.561
!MESSAGE Could not bind a reference of component org.eclipse.gemini.ext.di.emf. The reference is: Reference[name = EntityManagerFactory, interface = javax.persistence.EntityManagerFactory, policy = dynamic, cardinality = 0..n, target = null, bind = bindEntityManagerFactory, unbind = unbindEntityManagerFactory]

!ENTRY org.eclipse.equinox.ds 1 0 2017-04-09 09:32:57.561
!MESSAGE Could not bind a reference of component org.eclipse.gemini.ext.di.emf. The reference is: Reference[name = EntityManagerFactoryBuilder, interface = org.osgi.service.jpa.EntityManagerFactoryBuilder, policy = dynamic, cardinality = 0..n, target = null, bind = bindEntityManagerFactoryBuilder, unbind = unbindEntityManagerFactoryBuilder]

!ENTRY org.eclipse.equinox.ds 1 0 2017-04-09 09:32:57.561
!MESSAGE Could not bind a reference of component org.eclipse.gemini.ext.di.em. The reference is: Reference[name = EntityManagerFactory, interface = javax.persistence.EntityManagerFactory, policy = dynamic, cardinality = 0..n, target = null, bind = bindEntityManagerFactory, unbind = unbindEntityManagerFactory]

!ENTRY org.eclipse.equinox.ds 1 0 2017-04-09 09:32:57.561
!MESSAGE Could not bind a reference of component org.eclipse.gemini.ext.di.em. The reference is: Reference[name = EntityManagerFactoryBuilder, interface = org.osgi.service.jpa.EntityManagerFactoryBuilder, policy = dynamic, cardinality = 0..n, target = null, bind = bindEntityManagerFactoryBuilder, unbind = unbindEntityManagerFactoryBuilder]

!ENTRY org.eclipse.e4.ui.workbench 1 0 2017-04-09 09:33:23.828
!MESSAGE create ItemAccountType list part

!ENTRY org.eclipse.e4.ui.workbench 1 0 2017-04-09 09:33:33.281
!MESSAGE create Document list part

4. Es scheinen die Import Funktionen für Kunden und Artikel noch nicht wieder zu funktionieren.
Mann kann die CSV Datei auswählen aber es passiert nichts.

Das deutet meist auf einen (versteckten) Syntaxfehler in der Importdatei. Versuche mal diese:

http://vorlagen.fakturama.info/category/import/

Hallo Ralf,

lässt sich schon abschätzen, wann die Version für MAC kommt ??

grnOOm schrieb:
-------------------------------------------------------
> Hallo Ralf,
>
> lässt sich schon abschätzen, wann die Version
> für MAC kommt ??

Würde mich auch mal interessieren.

Moin,
ich hab das gerade mal testweise auf'm Mac gebaut, allerdings habe ich hier ein Problem mit dem Einstellungsdialog, der wird nämlich nicht angezeigt. Das muß ich erst mal reparieren, sonst nützt es einem ja nichts. Außerdem habe ich bei der Gelegenheit festgestellt, daß das Speichern von Kategorien manchmal nicht geht (bei Steuersätzen funktioniert es, aber nicht bei Versandarten).

Hallo,
nachdem ich verzweifelt versucht hatte, in der Version 1.6.9c die Browser-Schnittstelle unter Ubuntu 16.04 zum laufen zu bringen (an den Paketdiensten ist es letztendlich gescheitert), habe ich mir die Version 2RC installiert, Paketdienste scheinen nun zu funktionieren,
leider funktioniert der Import aus meinem WEB-Shop (Modified v2) nicht mehr, hier das Log (der Shop ist fürs testen lokal auf dem Rechner installiert):

eclipse.buildId=unknown
java.version=1.8.0_121
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Command-line arguments: -os linux -ws gtk -arch x86_64

Fehler beim Öffnen von:
localhost/admin/fakturama_connector.php
Message: unerwartetes Element (URI:"", lokal:"webshopexport". Erwartete Elemente sind ,,
Trace: com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:726)

Liege ich richtig, dass fakturama_connector.php nur zur "alten" Version passt?

Hallo magic_werner,

stimmt, der Webshop Connector passt nicht mehr.
Es wurden Funktionen erweitert und dazu wurden Abfragen angepasst.
Eine Vorversion gab es mal, aber ich glaube, an der Importfunktion wurde noch etwas geändert.

Gruß
moped