Adempiere #
Adempiere ist ein freies WarenWirtschaftssystem (ERP) unter Linux.
ThomasBayen arbeitet damit am FreiBier Projekt
.
Wo steht Adempire (auch im Vergleich zu anderen Lösungen) #
Im allgemeinen wird Adempire (zusammen mit OpenERP) als das leistungsfähigste der "echten" Open Source ERP-Systeme genannt. (Ausgenommen hiervon sind Produkte, die zwar open source sind nur von einer einzigen Firma entwickelt werden.) Eine Übersicht über Möglichkeiten unter Linux gibt es auf der Seite WarenWirtschaft.
Es gibt einen deutschen Verein, der sich um Adempire kümmert. Auf dessen Webseite gibt es im Prinzip aber auch nur Links zu den englischen Community-Sites. Andererseits vermittelt die Mitgliederliste des Vereins das Gefühl, das es deutsche Firmen gibt, die Adempiere ernsthaft einsetzen. Eine Referenzliste fehlt aber leider.
technische Grundlagen #
Es basiert auf einem JBoss Application Server (in Java) und bietet einen Java Client sowie alternativ einen Webclient mit gleicher Funktionalität. Darüberhinaus gibt es verschiedene Erweiterungen, z.B. für POS oder Produktionsplanung, die zumeist auch Java- oder Webclients bieten.
Demo / deutsche Installation #
Eine Live-Demo gibt es unter http://www.testadempiere.com/webui/. Diese ist allerdings nur in Englisch und Spanisch.
Um ein Gefühl für das Programm zu bekommen, wollte ich mir eine Demo ansehen. Leider gibt es auf den Community-Seiten nirgendwo eine eingedeutschte Version. Also habe ich den harten Weg gewählt. Dazu bin ich in folgenden Schritten vorgegangen:
Überblick verschaffen #
Zuerst habe ich mir auf http://www.adempiere.com einen Überblick verschafft. Um das Programm zu testen, sind dort drei Möglichkeiten genannt: Eine Online-Demo (siehe oben), ein fertiges Image und eine komplett manuelle Installation. Für den Anfang habe ich mich für den Zweiten Weg entschieden.
AVA-Installation #
Das bedeutet, ich habe die AVA-Installation (Adempiere Virtual Appliance) gewählt. Hier lädt man ein virtuelles System herunter, das man dann mit VirtualBox ausführen kann. Diese VM liegt im "OVF"-Format vor, so das man sie mit unterschiedlichen Virtualisierungs-Programmen ausführen kann. (sprich: man kann sich VMWare oder VirtualBox aussuchen). Leider benutzt der Erzeuger dieser Dateien wohl VMWare und testet den Start mit VirtualBox nicht. Deshalb gibt es auf o.g. Wikiseite einen Absatz "In case the ovf file does not work". Dank Wiki hat dort jemand reingeschrieben, wie man das Festplattenimage auch ohne die vorgefertigte OVF-Datei zum Laufen bekommt.
Hilfreich ist auch das Dokument "AVA.pdf", das man aus dem Wiki-Artikel heraus laden kann.
Ein weiteres Problem war, das das Festplatten-Image der AVA aus mehreren Dateien besteht und die Verknüpfungen zwischen diesen irgendwie so waren, das man keinen anderen Pfad verwenden darf. Ich weiss nicht, ob man das anpassen kann, habe das Problem aber anders gelöst: Ich habe einfach den Namen der virtuellen Maschine in VirtualBox gleich dem Original gewählt und dann das Festplatten-Image von Hand in das Verzeichnis der Virtualbox-Images kopiert. Dann hat er diese Festplatte schließlich auch akzeptiert.
Nachdem die AVA-Installation lief, habe ich wie im Wiki beschrieben die Netzwerk-Konfiguration des virtuellen Systems angepasst. Leider kam der Adempiere-Server allerdings nicht damit klar, das das Interface jetzt eine andere Adresse hatte. Runterfahren des Servers ging auch nicht, so das ich die ganze virtuelle Maschine nochmal rebootet habe. Danach konnte ich (nach Eintrag des DNS in meine "/etc/hosts", wie in der Anleitung beschrieben) direkt auf http://adempierehost.com:8080 zugreifen und alles war gut.
Die Version des AVA zur Zeit (13.11.2011) ist übrigens die 3.5.3a vom 21.12.2008. Ein Upgrade per ava_agent, wie in der Dokumentation angegeben, ging in Ermangelung ebendieses ava_agent-Binaries nicht.
deutsches Sprachpaket #
Die AVA-Installation war zuerst mal nur englisch. Deshalb bin ich der Anleitung auf http://www.adempiere.com/Sprachpaket_Deutsch gefolgt und habe das deutsche Sprachpaket installiert. Die Datei, die ich dazu aus dem heruntergeladen habe, habe ich über http://www.adempiere.com/German_Language_Pack gefunden. Das dürfte (soweit ich das verstanden habe) die Übersetzungen der aktuellen Version (z.Zt. 3.7.0) beinhalten. Ich habe sie dennoch installiert und das Ergebnis sah weitgehend gut aus.
aktuelle Installation #
Um ehrlich zu sein, hat die Installation einer aktuellen Version aus dem Sourcecode in Eclipse auch nicht viel länger gedauert. Dafür habe ich jetzt eine Version 3.7.0, die sich wirklich an einigen Punkten geändert hat. Im Grunde bin ich dazu den Anweisungen auf http://www.adempiere.com/Create_your_ADempiere_development_environment mit dem Unterschied, das das Projekt inzwischen von Subversion auf Mercurial umgestiegen ist und man den Sourcecode also so erhält, wie auf http://www.adempiere.com/Mercurial_Test_Environment beschrieben.
Leider muss man immer noch von Hand die deutschen Sprachdateien installieren. Allerdings sind sie im Eclipse-Projekt im Verzeichnis "data" direkt enthalten, so das man wenigsten keine Angst hat ,das die Versionen nicht zusammenpassen...
Nachtrag: debianbasierter Quickinstall von ADempiere 3.6.1 in deutsch #
Quelle: http://kenai.com/projects/adempiere361/downloads/download/Adempiere_GlobalQSS_20111114_postgres.deb
Info : http://globalqss.com/wiki/index.php/ADempiere_Debian_Installer
Bei Installation des Debianpaketes beschränkt sich die deutsche Installation unter Linux Mint 9.0 Isadora auf drei Schritte (erprobt von MarkusMonderkamp):
1. PostgreSQL installieren mit
sudo aptitude install postgresql-common
Einrichten, z.B. mit Info von http://sqlrelay.sourceforge.net/sqlrelay/gettingstarted/postgresql.html:
sudo passwd postgres
psql -c "ALTER USER postgres WITH PASSWORD 'newpassword'" -d postgres
2. Java SDK installieren:
sudo aptitude install sun-java-jdk
3. lokal heruntergeladenes Debianpaket von Adempiere installieren:
sudo dpkg -i Adempiere_GlobalQSS_20111114_postgres.deb
Einrichten - alles bestätigen und 2 verschiedene Passworte merken:
xhost + && sudo /etc/init.d/adempiere configure
Voilá, ADempiere sollte zur Verfügung stehen, z.B. für den Gardenworld-Admin per Webstart!
Installationsherausforderung unter Kubuntu 11.10 #
Stand Dezember 2011 (ThomasThiessen)
Adempiere benötigt unter anderem zwei relevante Abhängikeiten:
PostgreSQL Version 8.4. Bei Kubuntu wird üblicherweise Version 9.1 installiert.
Die PostgreSQL Version 8.4 wird in den Paketquellen angeboten um sollte entsprechend ausgewählt werden.
Statt SUN Java wird in den Paketquellen nur noch OpenJDK angeboten. Hier folgen zwei Links zu Information:
http://wiki.ubuntuusers.de/Java/Installation
http://wiki.ubuntuusers.de/Java/Installation/Manuell
Aufgrund einer Anleitung von ThomasBayen ist es möglich ADempiere dennoch zu installieren.
Wenn alle anderen Abhängigkeiten des adempiere-Pakets installiert sind, insbesondere postgresql-8.4, solltes mit folgendem Befehl dpkg dazu bewogen werden, die Abhängigkeiten dieses Pakets nicht zum Abbruch führen zu lassen. Die entstehenden Warnungen sollten dennoch gelesen werden, damit keine anderen Abhängigkeiten vergessen werden.
sudo dpkg -i --ignore-depends=Adempiere_GlobalQSS_20111114_postgres Adempiere_GlobalQSS_20111114_postgres.deb
Falls das nicht klappt, kann mit folgendem Befehl die Abhängigkeitsauflösung komplett abschalten werden:
sudo dpkg -i --force-depends Adempiere_GlobalQSS_20111114_postgres.deb
Die ADempiere-Skripte bestehen wohl auf der Datei
/usr/lib/jvm/java-6-sun/bin/jarsigner
, die auch genau so heissen muss.
Möglichkeit 1
Zunächst stellen wir fest welches Java installiert ist:
aptitude search java6
Bei dem Ergebnis ist es wichtig, das ein JDK (Development Kit) und nicht nur ein JRE (Runtime Environment) installiert ist. Das JDK ist eine Obermenge vom JRE und enthält zusätzliche Dinge wie z.B. einen Befehl, um JAR-Bibliotheken zu signieren (jarsigner).
Dann erhellt der Befehl
dpkg -S jarsigner
die Frage, ob Du eine Datei "jarsigner" installiert ist, mit welchem Paket und wohin. Nun könnte es sein, das eine ebensolche über das openjdk installiert ist. Dann hast Du vielleichgt eine Datei, die so ähnlich heisst:
/usr/lib/jvm/java-6-openjdk/bin/jarsigner
Es könnte sein, dass sich die Datei im folgenden Verzeichnis befindet:
/etc/alternatives/jarsigner
Da aber bei meiner Suche bereits original SUN java installiert ist, kann nicht mit Sicherheit gesagt werden ob diese Datei von OpenJDK oder SUN Java stammt.
Nun wechseln wir in das Verzeichnis /usr/lib/jvm. Dort stehen laut
Debian-Konvention alle installierten Java-JREs. Hier kann ein Softlink mit dem Namen java-6-sun erzeugt werden. Das ist zwar
ein bisschen gepfuscht, aber da sich dahinter ja so gut wie der gleiche
Inhalt verbirgt (weil das OpenJDK ja sozusagen der Nachfolger des Sun Java ist), könnte es gut sein, das das gutgeht.
Möglichkeit 2
Diese Möglichkeit wurde nicht ausprobiert und ist mit gewissen Risiken verbunden. Das entsprechende Paket kann von Debian heruntergeladen werden: (http://packages.debian.org/squeeze/sun-java6-jdk)
Diese Paket wird anschließend von Hand (mit dpkg -i ...) installiet.
Es kann passieren, dass Abhängigkeiten nicht aufgelöst werden können. Da muss
man überlegen, ob man die entsprechenden Pakete auch noch herunterlädt
(was schnell ein Rattenschwanz werden kann) oder es bleiben lässt. Da
Java eigentlich immer sehr eigenständig war, könnte das klappen.
Möglichkeit 3
Die folgende Möglichkeit habe ich angewendet. Risiken und Nebenwirkungen sid bisher noch nicht aufgetreten. Bei der Nächsten Programmaktualiserung bzw. Programminstallation werden wir sehen was passiert.......
In die Paketquellen wird die alte Kubuntu Paketquelle zusätzlich eingetragen:
http://archive.canonical.com/ubuntu natty partner
Damit sind alle Abhängigkeiten erfüllt und die Installation kann erfolgreich durchgeführt werden.
Die Konfiguration bricht bei Kubuntu 11.10 bei Punkt drei der Schnellinstallation ab:
xhost + && sudo /etc/init.d/adempiere configure
Hier sollte der folgende Tipp beachtet werden:
http://sourceforge.net/apps/mediawiki/freibier/index.php?title=Install_ADempiere_361
export -n DISPLAY /etc/init.d/adempiere configure
/opt/Adempiere/RUN_Adempiere.sh fürhrt zur Fehlermeldung
Adempiere Client /opt/Adempiere/ Exception in thread "main" java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it. at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:173) at java.awt.Window.<init>(Window.java:476) at java.awt.Frame.<init>(Frame.java:419) at org.compiere.util.Splash.<init>(Splash.java:96) at org.compiere.util.Splash.getSplash(Splash.java:82) at org.compiere.util.Splash.getSplash(Splash.java:71) at org.compiere.Adempiere.main(Adempiere.java:590)
Die Lösung wird in einem Forum beschrieben:
http://forum.ubuntuusers.de/topic/dsm-client-auf-ubuntu-8.04-server%3A-xserver-ei/#post-1474632
Auf dem Zielrechner wird in der Datei „/etc/ssh/sshd_config“ der Eintrag „X11UseLocalhost yes“ auf "X11UseLocalhost no" gesetzt.
Zusätzlich wird in der Datei „/etc/ssh/ssh_config“ im Bereich: Host * folgender Eintrag geändert: ForwardX11 yes
und der ssh-Daemon neu gestartet.
Der Start des Programms über: "KMenü - Nicht zuzuordnen - ADempiere Swing Client"
wird evtl. nicht ausgeführt.
Das Programm startet, und beendet sich nach kurzer Zeit wieder von selbst.
Daher sollte das Programm über die Konsole gestartet werden:
/opt/Adempiere/RUN_Adempiere.sh
Bei einem Konsolenstart werden die Fehlermeldungen angezeigt.
Folgende Fehlermeldung ist häufig vertreten:
Adempiere Client JAVA_HOME is not set. You may not be able to start Adempiere Set JAVA_HOME to the directory of your local JDK. ADEMPIERE_HOME is not set You may not be able to start Adempiere Set ADEMPIERE_HOME to the directory of Adempiere. Exception in thread "main" java.lang.NoClassDefFoundError: org/compiere/Adempiere Caused by: java.lang.ClassNotFoundException: org.compiere.Adempiere at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) Could not find the main class: org.compiere.Adempiere. Program will exit.
In diesem Fall fehlen die Umgebungsvariablen: JAVA_HOME und ADEMPIERE_HOME
Die Umgebungsvariablen werden von Hand gesetzt:
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk export ADEMPIERE_HOME=/opt/Adempiere/
und das Programm nochmals gestartet
/opt/Adempiere/RUN_Adempiere.sh
Baukasten-Prinzip #
Man kann ADempiere auf zwei Weisen betrachten: Zum einen ist es ein fertiges ERP-System, zum anderen ist es ein ERP-Baukasten. Es erlaubt, recht einfach neue Tabellen in der Datenbank anzulegen, dafür dann automatisiert eine CRUD GUI zu erzeugen und so ganz schnell verknüpfte Daten zu verwalten. Dazu werden Tabellen, Spalten, Fenster, Eingabefelder, etc. im sogenannten "Application Dictionary" eingetragen (das geschieht einfach per GUI als System-User). Wer dann hierzu über die reinen Daten noch "Business Logic" einfügen will, kann das dann in Java machen. Natürlich kann man seine eigenen Klassen dann mit dem vorhandenen verknüpfen, indem man die bestehenden Tabellen z.B. um Referenzen auf neue, eigene Objekttypen erweitert.
eigenes Modell #
Mit Hilfe des Application Dictionary kann man nun bereits eines Großteil eines Datenmodells abbilden. Dennoch fehlt manchmal die eigene Business-Logik. Um diese zu implementieren, kann man eine eigene Modell-Klasse implementieren. Wer einer vorhandenen Klasse Eigenschaften hinzufügen will, kann das mit einer Implementation des ModelValidator Interfaces machen. So kann man alle Events eines Objektes abfangen ohne den Original-Quellcode anrühren zu müssen.
Die eigenen Anpassungen können so am Ende in einem hübschen eigenen JAR-File stehen und überstehen so auch ein Upgrade der ADempiere-Basis.
Um ein echtes eigenes Projekt zu erzeugen, ist es eine gute Idee, einige Hinweise zu beachten. Mir hat http://www.adempiere.com/Create_your_ADempiere_customization_environment dabei geholfen.
Skript-Programmierung #
Die Unterstützung von Skripten scheint relativ neu implementiert zu sein und daher nicht so recht dokumentiert. Im Grunde geht es darum, das man sogenannte "Callouts", das sind externe Funktionen in einer Skriptsprache direkt in der GUI schreiben kann. Ein Einstieg ist z.B. hier http://www.adempiere.com/Script_Process Ich habe auch ein wenig damit herumgespielt. Dabei hat es an einigen Stellen gehakt, die ich hier erklären möchte: Zuerst erstellt man eine "Rule" (Regel). Da steht das Skript drin. Diese Regel kann man jetzt einer Datenbank-Spalte zuordnen. Dort muss man "@script:" gefolgt von dem Namen der Regel eintragen. Dieser beginnt z.B. mit "groovy:". Nun kann man das Groovy-Skript ausführen. Es sollte am Ende die Variable "result" auf einen leeren String setzen. (NULL ergibt auf jeden Fall einen Fehler, was mit einem anderen Rückgabewert geschieht, habe ich noch nicht ausprobiert). Also könnte ein erstes Skript z.B. so aussehen:
A_Tab.setValue('description', 'Hello, World!');
result=""
Es gibt es diese Callout-Schnittstelle bei der Änderung jedes Feldes. Außerdem kann man Regeln als Befehle über das Menü aufrufen (probiere ich später aus). Natürlich kann man auch ein Skript ausführen, das beim Laden, Speichern, löschen eines Datensatzes o.ä. ausgeführt wird. Hierzu implementiert man einen ModelValidator als Skript http://www.adempiere.com/Script_ModelValidator
Datenbank-Konventionen #
Einige Dinge stehen in keiner Dokumentation nicht drin, weil ja sowieso jeder von Anfang an weiss, das "man das so macht"... Hier ein paar dieser Konventionen und Links dazu:
- Tabellennamen müssen immer ein Prefix haben. Wenn man eigene Tabellen erzeugt, sollte das Prefix drei Zeichen haben (Prefixe mit ein oder zwei Zeichen werden bei der Benennung eines Modes abgeschnitten und sind dan u.U. nicht mehr eindeutig). Das Prefix sollte immer aus Großbuchstaben bestehen. Siehe http://www.adempiere.com/Table_Prefix
- Schlüsselfelder enden immer auf "_ID". Auch Fremdschlüssel!
- Boolean-Felder sind immer vom Typ "character(1)" und enthalten entweder "Y" oder "N". Ich habe keinen Hinweis finden können, das "boolean"-Felder benutzt werden können und den Versuch schnell abgebrochen, weil es nicht ging. Das ist wohl eine Oracle-Hinterlassenschaft. Man kann sich dran gewöhnen... Wer es"sauberer haben möchte", kann sich ja passende Constraints schreiben oder vielleicht einen enumerated type dazu basteln.
- unter http://www.adempiere.com/ManPageW_TableandColumn ganz unten unter "Contributions" steht eine Liste der verwendeten Postgres-Datentypen für die unterschiedlichen Feldtypen.
Referenzen/Fremdschlüssel #
Eine Referenz von einer Tabelle zu einer anderen (also ein Fremdschlüssel) sollte immer auf "_ID" enden. Die referenzierte Tabelle sollte Identity-Felder (auf deutsch "Schlüssel", nicht "Schlüssel-Spalte", das ist der Primärschlüssel) und Suchfelder haben. Dadurch wird die Tabelle durchsuchbar und man vermeidet seltsame Fehlermeldungen beim Ändern von Datenfeldern.
Eine Referenz auf eine Tabelle LUG_Mitglieder heisst am besten LUG_Mitglieder_ID. Dann funktioniert alles von alleine. Als Referenz-Typ wird automatisch "Table direct" ausgewählt. Ist der Name anders (ist z.B. nötig, wenn man mehrere Felder des gleichen Typs hat), so muss man den Typ "Table" wählen und im Application Directory ein "Referenz"-Objekt dazu anlegen. Dieses ist vom Typ Tabellenreferenz, wo man dann eingibt, wie die Referenz funktionieren soll.
Eine Referenz hat immer den Datentyp "numeric(10)".
Bilder in der Datenbank #
Wie fange ich das an...: "Die Geschichte von Bildern in Datenbanken ist eine Geschichte voller Mißverständnisse...". :-) Nun ja - ich persönlich bin ja der Meinung, das es im 21. Jahrhundert, d.h. bei heutigen Festplattengrößen und Datenbank-Systemen kein Problem ist, Bilder in der Datenbank abzulegen. Angesichts der Tatsache, das man dann alle Informationen zu einem Objekt inklusive seiner Bilder an einem Platz zusammen hat, ein gemeinsames Backup hat, eine einzige Technologie zum Zugriff und zur Speicherung benutzt und die Bilder immer synchron zum Rest der Daten sind, ist das meines Erachtens nach sogar die bevorzugte Art, Bilder, die inZusammenhang mit Daten stehen, zu speichern!!! Manche Leute meinen hingegen, man würde damit die arme Datenbank völlig überlasten und das ginge nun mal gar nicht und Binärdaten gehören gefälligst ins Filesystem. Die speichern dann nur einen Filenamen oder eine URL in der Datenbank ab und halten das Ganze irgendwie anders synchron. Wie man dann mit mehreren Usern auf das gleiche Filesystem zugreift, ist hier ein anderes Thema. Nun gut - es gibt für beide Vorgehensweisen Argumente. Leider wurden die von den Adempiere-Entwicklern nicht erhört. :-( Dazu kommt, das der Programmierer der Oberfläche wieder was ganz anderes gemeint hat als der Programmierer der Report Engine...
Eine hübsche Erklärung aller Feldtypen in ADempiere (auch bzgl. Images und Binärdaten) ist übrigens auf http://www.adempiere.com/index.php?title=Entering_Data_-_Fields_and_Buttons zu finden.
Also los:
Der "ADempiere"-Weg, um Bilder abzuspeichern ist, das diese in die Datenbank kommen (Juhu!). Allerdings muss man dazu eine spezielle Tabelle benutzen. Diese Tabelle ist immer "AD_Image" Das ist einerseits u.U. sinnvoll, weil man diese auf einen eigenen Tablespace legen kann und die Datensätze dann natürlich kleiner und handlicher werden. Andererseits hätte ich auch hier gerne die Wahl gehabt. Auf jeden Fall ist ein Bild in diesem Fall immer eine Referenz auf diese Tabelle. Da wir oben gelernt haben, wie Referenzen aussehen, kann das Datenfeld also in etwa so aussehen:
Bild_ID numeric(10)
Nun stellt man im Appication Directory im Fenster "Tabellen & Felder" im Feld die Einstellung "Referenz" auf "Image". Das reicht eigentlich schon.
Merkwürdigkeiten #
Benutze ich nun allerdings die Funktion "Spalte synchronisieren", die eigentlich die Spaltendefinition in der Datenbank anpassen sollte, wird diese auf den Typ varchar(2000000000) gesetzt. Erstens schreibt ADempiere später beim Editieren dennoch nur eine zehnstellige ID da hinein und zweitens ist der richtige Datentyp für Bilder ja wohl immer noch "bytea"! Vielleicht ist das eine Oracle-Hinterlassenschaft, die noch nicht aufgeräumt ist?!?
Druck #
Jetzt sollte man nicht meinen, das man Bilder nun in einem Bericht drucken kann. Das geht nämlich natürlich nicht. Berichte werden im Fenster "Druck-Format" eingerichtet. Dort kann man als Format-Typ "Bild" angeben, was sich erstmal gut anhört. Ich habe es bisher nicht geschafft, ein Bild auszugeben... Es gibt verschiedene Möglichkeiten:
- Man kann dort eine Bild-URL angeben, was wohl bedeutet, das dort immer das gleiche Bild ausgegeben wird.
- Man kann "Image Field" ankreuzen. Führt man das aus, beschwert sich das Programm im Log mit einem "File not Found". Es versucht offensichtlich, den Feldinhalt als URL zu betrachten und die Datei aus dem Filesystem zu laden. Hierzu benötigt man wohl kein Image-Feld, sondern ein FileName-Feld. Dieses wird dann aber natürlich nicht inder GUI ausgegeben und ist nur lokal auf einem Filesystem zugänglich.
- Man kann "Image Attached" ankreuzen. Hatte ich vergessen zu erwähnen, das man in ADempiere jedem Datensatz ein oder mehrere Attachments anfügen kann? - Erstens kann man diese jedoch in der GUI normalerweise nicht mit sehen und nur umständlicher pflegen und zweitens steht da nirgendwo, was passiert, wenn man mehrere Attachments hat. - Ich habe es erstmal nicht probiert.
Erzeugen von Views #
Wenn man eine bestimmte Ansicht von Daten haben will, z.B. für einen Report, kann man das nicht innerhalb von ADempiere machen. Man erzeugt auf Datenbankebene ein View. Es scheint Konvention zu sein, das dessen Name auf "_V" endet. Dann bindet man dieses ebenso wie eine normale Tabelle ein und erzeugt seinen gewünschten Report. Dabei muss man natürlich darauf achten, das man die Felder alle neu konfigurieren muss. Es gibt bei den "Tabellen" eine Kopierfunktion, die das erleichtern dürfte. Noch wichtig ist, das man den Primärschlüssel, der ja bekanntlich "PPP_Blabla_ID" heisst, nicht in das View aufnehmen muss (kann man doch, dann erzeugt sich das View leichter mit "*", aber man sollte kein Feld dafür in Adempiere erzeugen). Dafür sollte man dann im View eine Spalte "PPP_Blabla_V_ID" stehen, die als Primärschlüssel dient. Beispiel:
CREATE VIEW BAY_Artikel_V AS SELECT BAY_Artikel.*, BAY_Artikel.BAY_Artikel_ID AS BAY_Artikel_V_ID, AD_Image.binarydata FROM BAY_Artikel LEFT OUTER JOIN AD_Image ON BAY_Artikel.Bild_ID=AD_Image.AD_Image_ID
lose Enden #
Folgende Dinge sollten noch weitergehend untersucht werden:
- Auf http://www.adempiere.com/ADempiere_Deutsch_Integration gibt es Doku zu einigen deutschen Integrationen, die über die reine Übersetzung der GUI hinausgehen. Ich weiss nun nicht, ob die in der aktuellen Version schon enthalten sind oder ob man das mit einpflegen muss oder was das genau ist.
- Die Firma Metas scheint in der deutschen Umsetzung recht aktiv zu sein. Es gibt dort ein Wiki mit einem rudimentären Handbuch in deutsch: http://adempiere.metas.de/mediawiki/index.php/ADempiere_Handbuch
- Eine Sammlung von deutschsprachigen Artikeln gibt es unter http://www.adempiere.com/De_DE/start
- http://www.adempiere.com/ManPageX_InitialClientSetup - Erster Schritt, um einen eigenen Mandanten einzurichten
- http://en.wikiversity.org/w/index.php?title=Special%3ASearch&search=adempiere - Es gibt viele technische Artikel auf http://wikiversity.org
- Siehe auch den ADempiereVortragVonRed1