Footnote: Switched to new version 3.5.4

Good morning to every one who’s in trouble with Adempiere documentation! Hope you will find some more clues right here…

Hadn’t time to work on my blog for a longer time because we upgraded our implemenation to the newer version 3.5.4 and that was IN FACT the right decission!!! The new features are really impressive and since we have had made use of professionell support provided by CATURA AG from Passau (Germany) we took the race without any problems at all.

So since December I’m now working on implementations and adaptations for our company on the new version 3.5.4.

Since I will spend now some time on vacation I think I’ll have some spare time to bring up some suggestions and HowTo(s) to work easier with adempiere.

Unterschied zwischen normalen Aufträgen und POS-Aufträgen

Haben Sie sich jemals gefragt, was der Unterschied zwischen normalen Aufträgen und POS-Aufträgen ist?

Die “normalen Aufträge” (Sales Order) können unterscheiden zwischen dem physischen Liefern der Ware und der Rechnungslegung. Dem zufolge können Lieferschein und Rechnung sowohl unterschiedliche Datum als auch unterschiedliche Positionen haben. Diese Dokumente werden einzeln erzeugt.

Anders beim “POS-Auftrag” (POS-Order): Hier wird davon ausgegangen, dass Lieferschein und Rechnung zu 100% dem Auftrag entsprechen. Dieser kann zwar ein aderes Datum haben, jedoch werden am Buchungstag sowohl Lieferscheindatum als auch Rechnungsdatum auf diesen Tag gesetzt. Hinzu kommen, dass eben Lieferschein und Rechnung die selben Positionen zum gleichen Preis wie im Auftrag enthalten.

Falls Sie also Lieferschein und Rechnung direkt mit dem Auftrag erzeugen wollen, so sollten Sie über die Verwendung von “POS-Aufträgen” nachdenken. Beachten Sie jedoch bitte, dass in der normalen Einstellung die Nummernkreise von “Sales Order” und “POS-Order” abweichen. Dieses Verhalten kann jedoch unter “Belegnummerkreise” geändert werden.

Difference between POS-Order and “normal” orders

Ever thought about POS-Orders? They have some really big advantage!

Using normal orders you’ll have to seperate build your delivery notes and invoice documents. Since these documents might be use to separate the delivery and the invoice procedure they might have even different posting dates.

Since POS orders are used to create sales documents with one single action they will have all the same date and all positions enterd at the order itself. So all you’ll have to do is to call the invoice document and print it out after you entered the order and posted it.

Please be aware that in normal configurations your POS orders have other document numbers that the normal ones. But this habbit can be changed within document sequence numbers.

Debugging des Servers

Für einzelne Porgrammteile – oder Prozesse – ist es notwendig, den Server in den Debugging-Modus zu versetzen, als Beispiel sei hier der Buchungsprozess genannt, der ja auf dem Server selbst abläuft.

Es gibt hier zwei Möglichkeiten, den Server zu debuggen:
a) über Shared Memory – auf dem Server selbst oder
b) über “Remote Socket Debugging” – die Methode, die ich hier aufführen möchte

Das Remote Socket Debugging geschieht serverseitig über eine Einstellung im JBOSS, clientseitig wird ECLIPSE so gestartet, dass es auf den Prozess wartet.

1) Einstellungen am Server

Im Adempiere-Verzeichnis finden Sie das Unterverzeichnis “jboss/bin” und hier die Datei “run.conf”. In dieser Datei sind die unteren zwei Einträge für Debugging-Einstellungen zuständig.:

# Sample JPDA settings for remote socket debuging
# JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y"

# Sample JPDA settings for shared memory debugging
#JAVA_OPTS="$JAVA_OPTS -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_shmem,server=y,suspend=n,address=jboss"

Der obere Eintrag enthält die notwendigen Daten für das Debugging über Socket, als Port ist hier 8787 angegeben.
WICHTIG: Wenn Sie auf dem Server eine Firewall laufen haben, müssen Sie diesen Port vor dem Debugging freigeben!!!
Geben Sie diesen frei, indem Sie das Kommentarzeichen “#” entfernen.
Starten Sie danach den Serverprozess neu über “RUN_Server2.sh” im Verzeichnis “utils” (aus dem Adempiere Stammverzeichnis).
Wenn Sie alles richtig eingestellt haben, dann wird der Aufruf gestoppt bei der Zeile: “Listening for transport …”
Damit ist der Server für das Debugging bereit.

2) Einstellungen ECLIPSE:

Rufen Sie zuerst den Sourcecode des betreffenden Moduls auf, in meinem Beispiel “org.compiere.acct.Doc_InOut.java” und setzten dort die Breakspoints, also die Punkte, an denen der Debugger anhalten soll.
Danach ruft man die Debug-Konfigurationen auf. Im Punkt “Remote Java Application” gibt man unter “Connect” zuerst das Projekt an, dann den Socket-Typ “Socket Attach” und unter “Connection Properties” die Adresse des Servers (IP oder auflösbarer Name) und den Socket (hier 8787) an.
Mit dem Button “Debug” wird das Debugging gestartet. Falls Sie in einem anderen Fenster die Anzeige des Servers laufen haben, bekommen Sie jetzt die restlichen Startmeldungen des Servers angezeigt, in ECLIPSE wählen Sie die Debugging-Anzeige aus (“Window” – “Open Perspective” – “Debug”). Dort sind die Symbole “Suspend” (Pause) und “Disconnect” (Verbindung trennen) aktiv.

Remote Debugging unter ECLIPSE

Rufen Sie jetzt von einer “normalen” Session aus den Programmpunkt auf, den Sie debuggen wollen, z.B. verbuchen eines Wareneinganges, und der Debugger hält am nächsten Breakpoint an:

Remote Debugging: angehalten am Breakpoint

Ab hier können Sie ganz normal den Prozess debuggen.

Update auf neue Version

Einen habe ich noch:

Update der Adempiere-Version auf eine neue (Sub-)Version, hier im Beispiel von 3.40s nach 3.45:

Als Benutzer haben Sie natürlich bereits eine bestehende Version der Datenbank.

Wenn Sie jetzt ohne Migration den neuen Client benutzen, erhalten Sie eine Fehlermeldung, dass die Datenbankversion nicht stimmt. Daher müssen Sie eine Migration der Datenbank durchführen:

1) Adempiere beenden: Im Adempiere-Verzeichnis “utils/RUN_Server2Stop.sh” aufrufen.

2) Datensicherung: Im (alten) Adempiere-Verzeichnis “utils/RUN_DBExport.sh” ausführen! (Falls etwas schief geht!)

3) Migration: Im Quellpaket zur neuen Version findet man das Verzeichnis “migration”. Dort wählt man die jeweiligen Unterverzeichnise aus, von der Version, mit der man gerade arbeitet bis zu “trunk”. In meinem Fall sind das “340s-342s” und “342s-trunk” aus. Falls man POSTGRES hat, findet man jeweils ein weiteres Unterverzeichnis “postgres”. Dann werden dort alle  sql-Dateien geöffnet (z.B. Editor oder pgAdmin). Am Anfang jedes Textes folgende Zeile einfügen:

SET search_path = adempiere, pg_catalog;

Den geänderten Text auf der Datenbank ausführen lassen (pgAdmin = F5). Nach jedem Lauf prüfen, ob es eine Fehlermeldung gibt. Bei einigen Umstellungen kann es Warnhinweise geben – das ist nicht ungewöhnlich. Aber es sollten keine Fehlermeldungen auftreten!!!

4) Adempiere wieder starten: Im Adempiere-Verzeichnis “utils/RUN_Server2.sh” (evt. mit ” &”) starten.

Fehler beim Verbuchen – Buchungsprozessor nicht gefunden

Beim Verbuchen einer Rechnung trat am nächsten Tag ein Fehler auf: (sinngemäss) “Buchungsprozessor nicht gefunden“

Ursache: Auf dem Server war der Adempiere-Prozess nicht gestartet! (Hatte sich abends verabschiedet, weil interaktiv gestartet und Session beendet wurde)

“Vorsicht”: Der Adempiere-Client startet auch OHNE laufenden Adempiere-Prozess, da er hauptsächlich direkt auf der Datenbank arbeitet. Dass der Prozess selbst nicht läuft merkt man erst, wenn einige “höhere Funktionalitäten” benötigt werden.

Abhilfe: Starten des Adempiere Prozesses über “./RUN_Server2.sh &” im utils-Verzeichnis. Das “&” sorgt dafür, dass der Prozess im Hintergrund läuft. Wenn man sich z.B. über eine SSH-Session einloggt, würder der Prozess beim normalen Start beendet werden, wenn die Session abstürzt oder beendet wird.
Gestoppt wird das Ganze dann über “./RUN_Server2Stop.sh” im utils-Verzeichnis.

Kurzanleitung: Datenbank wieder aufspielen

(War leider eine Zeitlang sehr beschäftigt und hatte keine Zeit, neue Information zu liefern)

Hier eine Kurzanleitung für alle, die unter POSTGRES eine Datensicherung wieder aufspielen wollen:

1) Stoppen des Adempiere-Prozesses: Falls nicht schon vorher geschehen, ins Verzeichnis [Adempiere]/utils wechseln und “./RUN_Server2Stop.sh” aufrufen.

2) Löschen des alten Schematas: Mit pgAdmin die Datenbank Adempiere aufrufen, dort die Schematas aufrufen und das Schema Adempiere kaskadiert löschen (dauert bei mir nur einige Sekunden).

3) Datensicherung bereitstellen: Auf dem Adempiere-Server im Unterverzeichnis [Adempiere]/data die gewünschte Datensicherung heraussuchen. Wenn diese als JAR vorliegt mit “jar -xf [Dateiname].jar” entpacken (Achtung: Das Entpacken dauer bei mir etwa 2:10 min bei 2.1GB unkomprimierter dmp-Datei).

4) Rücksicherung: Ins Verzeichnis [Adempiere]/utils wechseln und dort die Rücksicherungsroutine aufrufen: “./RUN_DBRestore.sh”

5) Die Rücksicherung bestätigen und warten, bis das Programm beendet ist (2.1GB unkomprimiert dauern bei mir 2:40 min.). Zum Schluss den Adempiere-Prozess wieder starten mit “./RUN_Server2.sh” aus dem Verzeichnis [Adempiere]/utils

Nur zur Erläuterung: [Adempiere] bezieht sich auf das Installationsverzeichnis der Adempiere-Version, die verwendet wird.