Das Application Dictionary (AD) ist ein zentrales Verzeichnis in der Datenbank, in dem so gut wie jede Eigenschaft und Verhaltensweise des Programms eingestellt werden kann. Hier sind alle Tabellen, Fenster, Menüs, Prozesse, Berichte, und überhaupt alles eingerichtet und können angepasst werden. Aus dieser Tatsache heraus ergibt sich die schier unglaubliche Flexibilität von iDempiere.

Das AD kann vom Systemadministrator (Benutzer System oder SuperUser) im System-Mandanten konfiguriert werden. Dort gibt es einen eigenes Untermenü mit Fenstern zur Bearbeitung der AD-Tabellen. Übrigens sind auch diese Fenster selber im AD konfiguriert. DAs AD wird also komplett durchgängig benutzt.

Die Anpasssung von iDempiere an eine bestimmte Branche oder ein bestimmtes Unternehmen findet zu 95% im Application Dictionary statt. Nur in einigen Fällen ist es dann nötig, noch 5% an eigentlichem Programmcode hinzuzufügen. Die meisten Eigenschaften kann man sich in der Datenbank "zusammenklicken".

Links

Einträge im Application Dictionary

Die hier folgenden Punkte sind erst einmal nur der Anfang einer Liste und bei weitem nicht vollständig!!! Ich möchte diese hier erst einmal eine Weile wachsen lassen. Später kann man aus den Unterkapiteln besser eigene Unterartikel machen, die dann auch in den entsprechenden Fensterbeschreibungen eingebunden werden sollten.

Dieser Artikel ist von Thomas Bayen. Meine Artikel sind grundsätzlich nie "fertig", sondern immer eine Einladung, sie zu verbessern. Ich lade jeden gerne jederzeit ein, Verbesserungen hier direkt einzupflegen. Wer möchte, kann mich auch gerne kontaktieren.

Entity-Typ

Jedes eigenständige Objekt im AD (jede "Entity") hat einen bestimmten Entity-Typ. Dieser Typ ist eigentlich für nichts besonderes da, ausser um ggf. wiederzuerkennen, wer eine Entity erzeugt hat. Das kann extrem hilfreich sein, wenn man nach längerer Konfiguration in einer Instanz nicht mehr weiss, was man nun selbstgemacht hat und was vorher schon da war. Die vorgegebenen Objekte haben den Entity-Typ "Dictionary" und die neu erstellten den Typ "User-Maintained".

Wer möchte, kann auch einen eigenen Typ definieren und seine neu erstellten Objekte jeweils zuordnen. So kann man u.U. Objekte unterschiedlicher Funktionsmodule aufteilen etc.

Die einzige praktische Anwendung von Entity-Typen (über die reine Information hinaus), die mir begegnet ist, gibt es im Packout-Modul (siehe 2pack), wo man angeben kann, das alle Objekte eines bestimmten Typs in ein Paket geschrieben werden. So kann man ein Funktionsmodul paketieren, um sie in einer anderen iDempiere-Instanz einzuladen.

Tabelle und Spalte

Tabelle

Spalte

Das Feld Primärschlüssel kennzeichnet das ID-Feld der Tabelle. In der Tabelle BLA_Schubidu ist das zumeist ein Feld mit dem Namen BLA_Schubidu_ID. Dieses Feld enthält den eindeutigen Datenbank-Schlüssel des Datensatzes. Dieser ist ein interner Schlüssel, der dem Benutzer nicht mitgeteilt wird. Er sollte in der Definition von Feldern (in einem Register) als erstes stehen, wird aber normalerweise nicht mit angezeigt. Man sollte sich übrigens tunlichst an die "_ID"-Konvention halten, da diese an verschiedenen Stellen des Programms benutzt wird. (Wer eine Tabelle hat, die einen natürlichen Schlüssel besitzt und diesen Partout benutzen will, um die Datensätze zu verknüpfen, benutzt dazu eine Referenz (genauer: eine Tabellenreferenz).

Es gibt ein Feld Kennzeichner (engl. "Identifier", in alten Übersetzungen auch "Schlüssel"). Wird der Datensatz irgendwo anders durch eine Referenz benutzt, so wird an dieser Stelle ein Text ausgegeben, der den Datensatz repräsentiert. Ist im Feld "Kennzeichner" ein Haken gesetzt, wird dieses Feld an dieser Stelle mit ausgegeben. Sind mehrere Felder als "Kennzeichner" markiert, so werden diese hintereinandergesetzt und durch "_" getrennt. Die Reihenfolge ergibt sich durch das folgende Feld (engl. "Sequence", dtsch. "Reihenfolge" oder älter auch "Nummernkreis").

Das Feld ReadOnlyLogic bzw. alle Logik-Felder bedarf eigentlich einer eigenen Erklärungsseite. Hier kann man ein Feld schreibschützen abhängig von einer oder mehreren Bedingungen. Es gibt eine Online-Hilfe hierzu. Wer wirklich wissen will, wie das geht, sollte in den Sourcecode der Klasse org.compiere.util.Evaluator schauen. Über die Online-Hilfe hinaus gibt es noch den Tip, das "NULL"-Werte von *_ID-Feldern als "0" geschreiben werden, also so: "@C_BPartner_ID@=0", um auf ein leeres Geschäftspartner-Feld zu prüfen.

Referenzen

Referenzen dienen dazu, einen Schlüssel auf einen bestimmten Wert oder einen Datensatz zu beschreiben. Im Prinzip läuft es darauf hinaus, das ein Referenzfeld immer eine Auswahlbox anzeigt (oder ein Suchfeld wie für Geschäftspartner). Es gibt drei Typen von Referenzen.

Listenreferenz

Hier wird im Fenster "Referenzen" eine Liste von Werten eingegeben, die in Feldern später ausgesucht werden können. Diese Felder erhalten als Rererenztyp "Liste". Jedes Feld kann einen Codewert erhalten, der dann im entsprechenden Datensatz eingefügt wird. So kann z.B. ein "G" im Datensatz-Feld (das dann ein Stringfeld ist) für "gute Kunden" stehen, ein "M" für "mittlere Kunden", etc.

Tabellenreferenz

Die Referenz verweist auf eine bestehende iDempiere-Tabelle. Der Referenztyp ist "Tabelle" oder auch "Suche" (das beeinflusst dann, ob das Bildschirmelement zur Auswahl eine Auswahlbox oder ein Suchfeld ist). Damit ist dieser Referenz-Typ vom Grundsatz her das gleiche, als wenn ein Datenfeld den Typ "Tabelle direkt" hat, aber man kann hier weitere Einschränkungen durch eine SQL-WHERE und ORDER Klausel eingeben.

Angaben in diesen beiden Feldern müssen übrigens voll qualifiziert sein, also den Tabellennamen enthalten. Wer also eine Artikelliste nach Namen sortiert benutzen will, schreibt in ORDER: "M_Product.Name".

Wertereferenz

TODO...