Plugins im ErpXe-Umfeld
Zuletzt geändert: 19.04.2026 04:52

Plugins im ErpXe-Umfeld #

ErpXe ist die Warenwirtschafts-Anwendung, die auf der EULANDA-Datenbank aufsetzt (der Endanwender-Client). Sie hat ein Plugin-System, über das Funktionalität nachgerüstet wird, ohne am Kern zu schrauben – Xfacture (elektronische Rechnungen), DATEV-Export, Shopify-Sync, Dachser-Versand und viele weitere Module laufen auf diesem Weg.

Lange Zeit waren Plugins ausschließlich in VBScript geschrieben. Seit ErpXe 2026.4 kommt ein neues Plugin-Framework dazu: PowerShell-Plugins, die direkt gehostet und vollautomatisch installiert werden können.

Warum das wichtig ist. PowerShell-Plugins können direkt alle 400+ Funktionen aus EulandaXtools nutzen – kein COM-Wrapper, keine VBS-Zwischenschicht. Installation, Update und Deinstallation laufen über ein einheitliches Paket-Format und benötigen keine manuellen Schritte beim Kunden.

Die drei Plugin-Arten auf einen Blick #

flowchart TD Tools[Build-Kette
EulandaPlugin-Modul
Export-PluginResources · Invoke-PluginBuild]:::anlegen Tools -->|baut| V1["eulanda.xml
VBS-Plugin – Legacy"]:::teilstorno V1 --> V2[VBS-Dateien] V1 --> V3[SQL-Objekte] V1 --> V4[Registry-Einträge] V2 ~~~ V3 V3 ~~~ V4 Tools -->|baut| P1["eulanda.xml
PowerShell-Plugin – ab 2026.4"]:::buchen P1 --> P2[PS-Module/Funktionen] P1 --> P3[SQL-Objekte] P1 --> P4[Registry-Einträge] P2 ~~~ P3 P3 ~~~ P4 V1 --> ErpXe{ErpXe 2026.4}:::umwandlung P1 --> ErpXe V1 ~~~ P1 classDef anlegen fill:#2e86c1,color:#fff,stroke:#1a5276 classDef buchen fill:#27ae60,color:#fff,stroke:#196f3d classDef umwandlung fill:#8e44ad,color:#fff,stroke:#5b2c6f classDef teilstorno fill:#e67e22,color:#fff,stroke:#af601a

Struktur eines Plugins #

Beim Installieren verteilt ErpXe die Teile automatisch: SQL-Objekte in die Datenbank, Registry-Einträge in den passenden Subtree, Code-Dateien an den vorgesehenen Ort auf der Festplatte oder in ein Modulverzeichnis.

Verschlüsselte Registry-Werte. Manche Plugin-Einträge enden auf .crypt und werden beim Build verschlüsselt (LockBox-Format). Das übernimmt das Nachbarmodul EulandaCrypt, das separat installiert werden muss.

Wer baut die Plugins? #

Die Build-Kette lebt nicht in EulandaXtools, sondern im eigenständigen Schwestermodul EulandaPlugin. EulandaXtools liefert nur ein paar Hilfsfunktionen (Read-IniFile, Get-FileEncoding, Test-AdoConnection), die EulandaPlugin per RequiredModule einbindet.

Funktion (in EulandaPlugin)Zweck
Export-PluginResourcesSQL-Objekte + Registry-Einträge aus einem Mandanten exportieren
Export-PluginFromSqlNur SQL-Objekte eines Plugins als .sql-Dateien
Export-PluginFromSqlRegistryNur Registry-Einträge als cnreg-Dateien
Invoke-PluginBuildAus lokalen Dateien + INI die fertige eulanda.xml bauen
ConvertFrom-EulandaPluginXmlRückweg: aus eulanda.xml die Einzeldateien rekonstruieren
Get-InstalledPluginsInstallierte Plugins aus cnModules auflisten

EulandaPlugin wird nur auf Entwickler- und Build-Rechnern installiert – nicht beim Endkunden.

Was bleibt in EulandaXtools? #

In EulandaXtools gibt es genau eine plugin-bezogene Funktion:

Export-PluginBlob #

Liest den fertigen Plugin-Binär-Blob (Installer.bin) aus der SQL-Registry unter \SYSTEM_NC\FILES\<PluginName> und schreibt ihn als ZIP-Datei. Das ist der Rückweg “installiertes Plugin aus der DB zurückholen”, kein Build-Schritt.

$conn = Get-ConnByUdl -Udl $udl
try {
  Export-PluginBlob -Conn $conn `
    -PluginName 'esol.DMS' `
    -OutputPath '.\' `
    -FileName 'esol.DMS.zip'
}
finally {
  $conn.Close()
}
Export-PluginBlob extrahiert ein fertiges Paket, erzeugt aber kein neues. Für den Build aus Quelltext (SQL-Objekte + Registry + Code) ist EulandaPlugin zuständig, nicht EulandaXtools.

Typischer Workflow für ein eigenes PowerShell-Plugin #

Ab 2026.4 sieht der Ablauf so aus:

  1. Eigenes PowerShell-Modul schreiben, das die Fach-Logik enthält. EulandaXtools als RequiredModule in der .psd1 setzen.
  2. SQL-Objekte (Stored Procs / Views) und Registry-Einträge (Konfiguration) in einem Test-Mandanten einrichten und testen.
  3. Mit Export-PluginResources (aus EulandaPlugin) die Ressourcen aus dem Test-Mandanten exportieren.
  4. Mit Invoke-PluginBuild eine eulanda.xml aus Code + SQL + Registry + INI-Konfiguration bauen.
  5. Die eulanda.xml im ErpXe-Plugin-Manager installieren – ErpXe verteilt alle Teile automatisch in die Datenbank und auf die Festplatte.

Für Details zur eulanda.xml-Struktur, zum [EULANDA-VC]-Block, zur Verschlüsselung einzelner Registry-Einträge und zum Rückweg aus bestehender XML: siehe Dokumentation im Schwesterrepository C:\Git\Products\EulandaPlugin\.

Bestehende Plugin-Beispiele #

PluginZweckAnbindung an EulandaXtools
XfactureElektronische Rechnungen (Peppol, ZUGFeRD, XRechnung)nutzt Export-InvoiceXml, ConvertTo-ZugferdPdf, b2brouter-Cmdlets
DATEV-ExportMonatliche Rechnungsübergabe an den Steuerberaternutzt Export-DatevInvoice, Send-InvoiceToDatev
Shopify-SyncBi-direktionaler Artikel-, Bestell- und Kontakt-Syncnutzt 35+ Shopify-Cmdlets aus EulandaXtools
GobdZ3GoBD-konforme Z3-Datenträgerüberlassungnutzt Export-GobdZ3
esol.DMSDokumentenmanagementwird von Get-DmsFolder*-Wrappern angesprochen

Alle oben genannten Plugins sind historisch VBS-basiert. Neue Plugins werden ab ErpXe 2026.4 direkt als PowerShell-Plugins realisiert, die VBS-Modellwelt wird bei Gelegenheit migriert.