Blog

Blog-Eintrag

Nachdem nun einige Wochen Sendepause war aufgrund anderweitiger Verpflichtungen möchte ich mich heute wieder mit Neuigkeiten zurückmelden. Eine der am meisten gewünschten Funktionen in Fakturama war die Abholung von Bestellungen mit unterschiedlichen Status. Das Problem hierbei ist, daß die Status aus dem Webshop den Status im Fakturama irgendwie zugeordnet werden müssen. Die Alternative, nur noch Status des Webshops auch innerhalb von Fakturama zu verwenden habe ich erst mal beiseite gelegt, da hier tiefergreifende Einschnitte zu machen wären und ich ja ursprünglich das Gesamt-Feeling des Programmes nicht grundlegend ändern wollte. Deswegen habe ich hier einen Zuordnungsdialog eingebaut, mit dessen Hilfe man die Status des Webshops auf die Status in Fakturama abbilden kann. Das sieht dann so aus:

Ein neuer Button im Einstellungsdialog für die Webshop-Anbindung öffnet einen neuen Dialog, in dem man die Status des Webshops abholen kann. Anschließend kann man sie per Drag & Drop den Status aus Fakturama zuordnen. Damit "weiß" Fakturama dann, welcher Status wie zu behandeln ist. Beim Abholen der Webhop-Daten muß/kann dann der Status mit angegeben werden, der abgeholt werden soll (das ist aber nocht nicht fertig!). moped und ich sind da an einer Lösung dran.

Ansonsten sind die Dialog-Masken soweit fertig, endlich auch die dickste, der Dokumenteneditor. Sicher wird es dort noch Fehler geben, weil der einfach zu groß ist und zu viele Funktionen beinhaltet. Ein kleiner Eindruck:

Umgesetzt wurde hier auch ein weiterer Wunsch: Ein Klick auf den Beschreibungstext öffnet jetzt ein kleines Fenster, in dem der text dann bequem eingetragen werden kann. Da wir hier mit NatTable arbeiten ließ sich das aber relativ leicht umsetzen (Zwinkern). Ein weiterer Vorteil des Einsatzes von NatTable ist die Möglichkeit, Zeilen verschieben zu können. Dazu packt man die Zeile mit der Maus an der Positionsnummer und kann sie dann nach oben oder unten verschieben. Dafür funktioniert momentan das Verschieben per Kontextmenü noch nicht (traurig) Das bedarf noch einiger Recherchearbeit, deswegen wird das erstmal hintenangestellt. Als nächstes geht es an die Import- und Export-Funktionen.

Die aktuellen Alpha-Versionen findet ihr in Kürze auf SourceForge im entsprechenden Verzeichnis.

Heute habe ich testweise mal die Alpha-Version auf dem Mac installiert. Hier gab es mehrere Überraschungen:

  • der Workaround (Anpassung der ini-Datei) entfällt
  • beim Zusammenbauen der Anwendung müssen keine Anpassungen mehr vorgenommen werden (betrifft nur den Build der Anwendung)
  • in der Datei Info.plist steht der Schalter showlocation - der muß dort raus, sonst klappt es mit dem Starten der Anwendung nicht
  • die ausführbare Datei in der Fakturama.app hat noch keine execute-Rechte (geht sehr leicht mit chmod zu korrigieren). Das liegt aber wahrscheinlich daran, daß ich auf einem Windows-System baue und hier die Rechte einfach nicht gesetzt werden können
  • der initiale Start der Anwendung verlief selbst mit den Standard-Einstellungen erstaunlich flüssig, obwohl ich das ganze in einer VM betreibe. Unter Windows hat das wesentlich länger gedauert
  • der Doppelklick auf ein Element in der Übersichtsliste funktioniert scheinbar nicht mehr. Das muß ich noch weiter untersuchen.

Hier noch ein kurzer bildlicher Eindruck:

Nach einer etwas längeren Pause gibt es mal wieder ein kleines Update. Inzwischen habe ich alle Editoren und Übersichtsfenster so weit, daß sie in einem einigermaßen vorzeigbaren Zustand sind. Es funktioniert noch nicht alles, aber das meiste (Zwinkern) Die Alpha-Versionen sind wieder auf Sourceforge zu haben. Die ganzen Übersetzungen habe ich ebenfalls aus der Version 1.6.8 nachgezogen.

Ein kleiner Hinweis noch in Sachen Performance: Mit der Standard-Einstellung (Fakturama mit in-memory-hsql-Datenbank) startet Fakturama extrem langsam. Woran das liegt weiß ich inzwischen, ich kann es aber nicht beheben (liegt direkt bei HSQL). In der Zwischenzeit gibt es mehrere Möglichkeiten: Entweder ihr wartet (Lächeln), oder ihr startet HSQL als Server oder nehmt eine andere Datenbank (z. B. MySQL).

In der neuen version habe ich auch die Trennung von Debitoren und Kreditoren vollzogen. Das wirkt sich aber noch nicht auf Bestellungen oder ähnliche Dokumente aus, es dient nur der Vorbereitung. Außerdem habe ich bei den Produkten ein neues Feld "GTIN" eingeführt, das ist im Prinzip das Pendant zur EAN. Im Produkt-Editor habe ich auch die Bild-Auswahl geringfügig geändert.

Eine kleine interne Neuerung: Die Bilder werden nicht mehr im Verzeichnis /pic/ gespeichert, sondern direkt in der Datenbank. ich weiß, daß das Vor- und Nachteile hat, die Vorteile überwiegen aber derzeit in meinen Augen. Insbesondere ist damit die Voraussetzung geschaffen, mehrere Bilder pro Produkt zu speichern. Außerdem läßt sich das intern leichter handhaben. Und es gab auch in der Vergangenheit einige Irritationen bei den Bildern, falls man mal was aktualisieren wollte. Sollte sich das Konzept als nicht praktikabel erweisen kann man dort auch über einen Rückbau nachdenken.

Und nun - Test frei!

Heute habe ich mich einmal intensiv mit der Lauffähigkeit der Version 2.0 auf dem Mac beschäftigt. Zumindest in der Entwicklungsumgebung habe ich es hinbekommen:

D.h., der Browser funktioniert, das Menü ist ganz brauchbar (bis auf den ersten Menüpunkt, den muß ich mir nochmal ansehen) und die neuen Widgets (aus dem Nebula-Projekt) funktionieren auch (CDateTime funktioniert sogar besser als unter Windows...). Auch Nattable (das neue Element für die Darstellung von Tabellen) ist unter MacOS einsetzbar.

Einige Kuriositäten hatte ich beim Starten (oder Nicht-Starten) diverser OSGi-Bundles für die Datenbank. Da sind einige Bundles nicht hochgefahren, obwohl sie eigentlich gebrauch wurden. Unter Windows hat das noch geklappt. Die Folge war, daß kein EntityManager gefunden werden konnte und die Anwendung sich verabschiedet hat. Das simple "Autostart" der entsprechenden Bundles (JPA, Persistence, Gemini) hat es dann wieder repariert.

Währungen

In den bisherigen Fakturama-Versionen konnte man in den Einstellungen das entsprechende Währungsymbol eintragen. Das hatte den Vorteil, daß man relativ einfach die Währungen wechseln konnte, allerdings konnte man auch die entsprechende landestypische Formatierung nicht beeinflussen.

In Fakturama 2 haben wir deshalb eine kleine Änderung eingebaut. Nun kann man das Währungszeichen nicht mehr direkt eingeben, sondern muß das Land auswählen, zu dem die Währung "gehört". Als Hilfestellung wurde ein kleines Beispielfeld eingeführt, das die Darstellung mit den aktuellen Parametern zeigt:

Das hat den Hintergrund, daß die Darstellung von Währungen landestypisch teilweise stark voneinander abweicht. Gibt man also nun das Währungsland an, wird die Währung immer gemäß den aktuell dort geltenden Formatierungsrichtlinien dargestellt. Darüberhinaus kann man noch angeben, ob die landessprachliche Abkürzung für die Währung verwendet wird oder das international gebräuchliche Symbol. Des weiteren kann man (wie bisher auch schon) die Tausender-Trennzeichen darstellen (oder auch nicht).

(Warnung) Diese Einstellung muß auch nach einer erfolgreichen Migration geprüft werden, da beispielsweise bei der Angabe "€" nicht bestimmt werden kann, ob das dazugehörige Land Italien, Deutschland oder Frankreich oder ein anderes Euro-Land ist. Alle drei Länder haben aber unterschiedliche Formatierungsvorschriften. Der Hinweis darauf steht auch in der Migrations-Logdatei.

Für die Schweiz gibt es noch eine Besonderheit. Wählt man eine der drei Schweizer Landeseinstellungen aus (deutsch / italienisch / französisch), dann wird die Checkbox "Bar-Rundung" aktiv. Diese bewirkt, daß Beträge auf volle 0.05 Rappen gerundet werden. Man kann diese Funktion allerdings auch abschalten.

Technisch gesehen hat sich hier im Hintergrund sehr viel getan. Die vorhandenen Code-Teile wurden fast vollständig gegen neue ausgetauscht oder ganz weggelassen. Dies war möglich, weil wir jetzt auf die neue JavaMoney-Bibliothek setzen. Das ist eine Erweiterung für Java (JSR354), die es aber (leider) noch nicht in das offizielle JDK geschafft hat. Der Vorteil dieser Bibliothek ist, daß man sich beispielsweise um Rundungen nicht mehr großartig kümmern muß. Auch Formatierungen von Währungsbeträgen sind damit um ein Vielfaches einfacher geworden. Und man hat natürlich auch die Gewißheit, auf eine ausgereifte Bibliothek zu setzen. Die Funktionen der Bibliothek reichen sogar bis zur Umrechnung von Währungen mit Hilfe aktueller Kursinformationen der EZB. Das ist aber definitiv nicht in der neuen Fakturama-Version drin (Zwinkern)

Migration der Altdaten

Da die erste Aktion für die Umstellung höchstwahrscheinlich die Migration der Daten sein wird hier mal dazu noch einige Hinweise. Startet man die Anwendung das erste Mal, wird angeboten, die alten Daten in die neue Anwendung zu übernehmen. Dazu müssen zunächst einige Parameter abgefragt werden:

Arbeitsverzeichnis: Angabe des neuen Arbeitsverzeichnisses.

Arbeitsverzeichnis (alt): Angabe des bisherigen Arbeitsverzeichnisses. Werden darin Daten gefunden, so wird dies mit der folgenden Meldung angezeigt:

Quittiert man diesen Dialog mit "Ja", werden die alten Daten und Dateien übernommen.

verwende Standardeinstellungen: damit werden die Standard-Datenbank-Einstellungen verwendet (HSQL-Datenbank im Arbeitsverzeichnis entsprechend der bisherigen Lösung). Klickt man die Checkbox an, so ändert sich der Dialog und man kann die Zugangsdaten sowie den Typ einer anderen Datenbank angeben:

Angeboten werden derzeit HSQL, Derby und MySQL. Weitere Datenbank-Systeme sind noch geplant. Bei der Derby-Datenbank wird unterschieden zwischen in-memory und dateibasiert. Deshalb gibt es dort auch mehrere Einträge dazu. Ändert man das Datenbank-System, so wird auch gleich die JDBC-URL angepaßt (Vorlage zum Eingeben der Daten). Nachdem noch Nutzername und Passwort für die Datenbank eingegeben wurden, erscheint der Hinweis auf den Neustart der Anwendung. Bevor die Anwendung jedoch neu gestartet wird, wird sie zunächst ganz kurz "normal" gestartet. Dies dient lediglich dazu, die Einstellungen zu hinterlegen und die Datenbank zu initialisieren.

Nach dem erneuten Start beginnt Fakturama, die alten Daten zu übernehmen. Dies kann je nach vorhandenem Datenbestand länger dauern, da die neuen Datenstrukturen anders sind als die bisherigen. Der Fortschritt wird in einer entsprechenden Hinweisbox angezeigt:

 

(Warnung)   Im (neuen) Arbeitsverzeichnis wird parallel zum "normalen" Logfile noch eine besondere Migrations-Logdatei geschrieben. In dieser werden alle Migrationsschritte festgehalten sowie auch die Hinweise auf eventuell aufgetretene Fehler. Es ist also wichtig, sich diese Datei (migInfo.log) einmal näher anzusehen. Insbesondere beim Konvertieren des Währungssymbols und der damit einhergehenden Bestimmung der entsprechenden Locale-Einstellung ist das wichtig, da diese nicht immer zweifelsfrei bestimmt werden kann.

Nachdem alle Daten konvertiert wurden erscheint das Hauptfenster der Anwendung:

 

Da es doch im Forum immer wieder zu Fragen hinsichtlich der Umstellung zur Version 2 gabe möchte ich an dieser Stelle in unregelmäßigen Abständen über den Fortschritt des Projektes berichten. Da dies hier der erste Artikel in diesem Blog und zu diesem Thema ist, wird er auch etwas ausführlicher.

Ziele der Umstellung

Die Umstellung auf Fakturama 2 hat folgende Ziele:

  • Ablösung der alten Eclipse-Plattform. Vorteile hierbei sind
    • die bessere Unterstützung der angebotenen Plattformen (Windows/Linux/MacOS)
    • die Möglichkeit der einfacheren Strukturierung des Programmcodes (Stichwort E4-Modell)
    • Möglichkeit der Verwendung der aktuellen Java-Version
    • Verwendung von vorhandenen Programmierbibliotheken (statt Eigenentwicklung)
  • Beibehaltung aller vorhandenen Daten
  • hoher Wiedererkennungswert durch Beibehaltung des Maskenlayouts
  • Beibehaltung der vorhandenen Funktionalität
  • Einbau von Tastaturkürzeln
  • Verwendung der neuen Java 8-Features für die Vereinfachung des Quellcodes
  • Erstellung von Tests
  • Ablösung der Kopplung zu LibreOffice/OpenOffice (die Vorlagen werden weiterhin mit diesen Programmen erstellt, beim Drucken benötigt man sie aber nicht mehr). Die Vorteile liegen hier auf der Hand.
  • Verwendung alternativer Datenbanksysteme (aktuell werden MySQL, Derby und HSQL unterstützt, weitere DB-Systeme sollten aber kein Problem sein)
  • Verwendung eines O/R-Mappers zur einfacheren Erzeugung von JDBC-Abfragen (aktuell wird EclipseLink verwendet)
  • Verwaltung der Datenbankstruktur in einem Modell (dazu wurde ein EMF-Modell verwendet, aus dem mit Hilfe von Texo DB-Klassen generiert werden können).
  • gleichzeitiger Zugriff mehrerer Nutzer auf das Programm (auch über das Netzwerk), wobei in der 2.0 noch keine volle Benutzerkontensteuerung eingebaut sein wird (jeder darf alles, aber das wird auch entsprechend registriert). Geplant ist hier eine rechtebasierte Benutzerkontensteuerung (Admin, User usw.)
  • einfacheres Bauen der Installationspakete
  • flexibleres Reagieren auf Änderungswünsche / Einbau von Sonderwünschen

Datenmigration

Beim ersten Start der Anwendung werden zunächst einige Einstellungen abgefragt, die das Programm benötigt. Will man seine vorhandenen Daten in die neue Anwendung übernehmen, muß man hier das Altverzeichnis angeben. Das neue Arbeitsverzeichnis sollte sich vom alten unterscheiden, damit die beiden Versionen sauber getrennt sind und es bei einem evtl. Rollback keine Komplikationen gibt. Standardmäßig wird (wie bisher) die HSQL-Datenbank verwendet. Man kann aber auch eine MySQL- oder Derby-Datenbank als neue Verbindung angeben, wenn man das Häkchen bei "use Connection" entfernt. In die Eingabefelder müssen die entsprechenden Verbindungsdaten eingetragen werden.

nach der Betätigung von OK werden die Daten konvertiert. Das wird in einem Fortschrittsdialog angezeigt und kann je nach Datenvolumen etwas länger dauern.

Bildschirmmasken

Wenn keine Daten migriert werden sollen, dann werden Standardwerte für die Bezahlart und die Steuer in die Datenbank geschrieben und die Hauptmaske öffnet sich.

(tbd)

fertiggestellte Bereiche

  • Navigationsleiste links
  • Haupt-Menü
  • Steuersatz-Liste und -Editor
  • Zahlungsarten-Liste und -Editor
  • Kontaktliste und -Editor
  • Webshop-Import (99%, da sind noch Restarbeiten zu machen, die aber erst erledigt werden können, wenn der Produkteditor fertig ist) funktioniert dank der bereits geänderten Connectoren.
  • Dokumenten-Liste (aktuell wird der Dokumenten-Editor gebaut)
  • Datenbank-Modell (als EMF-Modell)
  • Bauen der kompletten Anwendung mit einem Klick (per Maven/Tycho). Hierbei wird bis zum fertigen Installationsmodul gebaut. Das eigentliche (herunterladbare) Installationspaket für die einzelnen Plattformen wird per install4j gebaut.

Neuerungen

  • Verwendung von formatierten Eingabefeldern für Zahlen (Prozent / Nummern) und Währungsbeträge (damit können dann auch nur Nummern in die Felder eingetragen werden und keine Texte)
  • Verwendung der JavaMoney-Bibliothek zum Rechnen mit Währungen und Geldbeträgen; damit wurde auch eine Änderung im Einstellungs-Dialog notwendig. Jetzt muß das Währungsland eingetragen werden (nicht bloß die Währung selber).Das hat den Hintergrund, daß auch die Formatierung der Währung mit daranhängt (wo steht das Währungszeichen, welches Tausendertrennzeichen nehme ich usw.)
  • Ablösung der Listentabellen durch NatTable. Dies bringt zahlreiche Vorteile:
    • mächtige und flexible Listendarstellung
    • automatische Reaktion auf Änderungen in den zugrundeliegenden Werten (mit Hilfe von GlazedLists)
    • diverse Features werden von Haus aus mitgeliefert (Export der Tabelle in Excel, Anordnung der Spalten, Speichern des Layouts, Sortierung und Filterung usw.)
  • Bankleitzahl und Kontonummer können im Kontaktformular nicht mehr eingegeben werden und sind durch IBAN/BIC ersetzt worden

offene Fragen

  1. Zur Zeit wir der Fortschrittsbalken im Splash-Screen beim Start der Anwendung nicht angezeigt. Dazu gibt es aktuell noch keine Lösung.
  2. Die Update-Funktion geht derzeit noch nicht, da sich an der darunterliegenden Technik etwas geändert hat.
  3. Der About-Dialog muß komplett neu erstellt werden, da er noch auf Eclipse 3 basiert.
  4. Der Start dauert aufgrund der Datenbank-Initialisierung noch verhältnismäßig lange. Hier muß ggf. noch etwas unternommen werden.