REST-API on Handbuch

API-Landkarte

Sat, 18 Jul 2026 21:03:31 +0200

API-Landkarte #

Alle Endpunkte der REST-API auf einer Seite: erst die Prozesse als kompakte Ablauf-Diagramme, dann die Referenz - gruppiert nach der Art der Daten (Konstanten, Stammdaten, Bewegungsdaten, Transfer und Aktionen, Auswertungen). Über das Untermenü rechts springt man direkt in jede Gruppe. Pfade sind ohne das Präfix /api/v1 notiert.

Prozesse im Überblick #

Verkaufs-Belegfluss #

Angebot .......... POST /quotes (+ /items)
 │ Angebot → Auftrag:
 │ POST /quotes/{id}/actions/convert-to-order
 v
Auftrag .......... POST /sales-orders (+ /items)
 │ buchen (reserviert): POST .../actions/book
 │ wieder öffnen: POST .../actions/reopen
 v
Lieferschein ..... POST /sales-orders/{id}/delivery-notes
 │ Teillieferung über items im Body
 │ SN/Chargen: GET+POST .../stock-details (nach 409)
 │ buchen (Lager ab): POST .../actions/book
 v
Rechnung ......... POST /delivery-notes/{id}/invoices
 │ Sammelrechnung: POST /invoices/from-delivery-notes
 │
 ├─ PDF ........ GET /invoices/{id}/pdf
 ├─ Zahlung .... POST /invoices/{id}/payments
 ├─ Gutschrift . POST /invoices/{id}/actions/credit
 └─ Storno ..... POST /invoices/{id}/actions/cancel (löscht!)

PDF und Formulare (/reports, /{id}/pdf) gibt es genauso für Angebote, Aufträge und Lieferscheine. Die drei Gutschriftsfälle steuert mode (newOrder, reopenDeliveryNotes, reopenOrder).

Verwaltung (Admin-UI)

Sat, 18 Jul 2026 15:19:07 +0200

Admin-Oberfläche #

Für die Verwaltung der API-Clients gibt es ein lokales WebView2-Fenster im Look and Feel der übrigen EULANDA-Plugins (EulandaXtrack/EulandaXcel): linke Sidebar, mehrsprachig (de/en), Toast-Meldungen, Hell/Dunkel-Theme.

Show-XrestAdmin -Udl 'C:\Eulanda\Mandant.udl'

Das Fenster braucht Windows PowerShell 5.1 (powershell.exe) - die WebView2-Wrapper von EulandaXtools sind .NET-Framework. Unter pwsh 7 bricht der Aufruf mit einem klaren Hinweis ab; dort die Clients per CLI verwalten (siehe unten). Das Fenster läuft lokal mit den DB-Rechten des Benutzers und braucht keinen API-Key - die Aktionen gehen direkt auf die Datenbank.

Installation und Betrieb

Sat, 18 Jul 2026 15:19:07 +0200

Installation und Betrieb #

Der API-Server läuft auf http.sys (System.Net.HttpListener) - ohne IIS genauso wie neben einem IIS: http.sys routet Requests nach Hostname (SNI), beide teilen sich denselben Port 443, und die Zertifikate kommen aus dem Windows-Speicher (auch die von IIS bzw. Win-ACME installierten).

Schnellstart (nur LAN, ohne Einrichtung) #

Import-Module EulandaXrest
Invoke-XrestMigration -ConnStr '...Admin-Verbindung...' # einmalig, braucht DDL-Rechte
Start-XrestServer -Udl 'C:\Eulanda\Mandant.udl' # bindet nur http://localhost:8100/

Betrieb mit Hostname und HTTPS (auch neben IIS) #

Einmalige Einrichtung in einer Administrator-Konsole - der Befehl sucht das Zertifikat für den Hostnamen selbst im Speicher LocalMachine\My:

Adressen

Sat, 18 Jul 2026 21:14:09 +0200

Ressource: addresses #

Kunden- und Interessenten-Adressen der EULANDA-Tabelle Adresse. Die Neuanlage läuft serverseitig über die EULANDA-Prozedur cn_AdNew und übernimmt damit die Vorlagen-Adresse .MUSTER (Anrede, Vorbelegungen, Merkmale), bevor die übergebenen Felder gesetzt werden.

Endpunkte #

Methode	Pfad	Scope	Zweck
GET	`/api/v1/addresses`	`addresses:read`	Liste mit Paging, Filtern, `changedSince`, `categoryAnd/Or/Not`
GET	`/api/v1/addresses/categories`	`addresses:read`	Merkmalbaum für den Merkmal-Filter, siehe Merkmale
GET	`/api/v1/addresses/{id}/categories`	`addresses:read`	Merkmale einer Adresse
GET	`/api/v1/addresses/{id}/service-articles`	`service-articles:read`	Geräte des Kunden, siehe Serviceartikel
PUT/PATCH	`/api/v1/addresses/{id}/categories`	`addresses:write`	Merkmal-Zuordnung ersetzen bzw. ändern
GET	`/api/v1/addresses/ids`	`addresses:read`	Schlüsselliste für den Lösch-Abgleich
GET	`/api/v1/addresses/{id}`	`addresses:read`	Einzelne Adresse über die Id
GET	`/api/v1/addresses/by-match/{match}`	`addresses:read`	Einzelne Adresse über den Matchcode
POST	`/api/v1/addresses`	`addresses:write`	Adresse anlegen (`cn_AdNew` + Felder)
PATCH	`/api/v1/addresses/{id}`	`addresses:write`	Felder ändern (partiell)
DELETE	`/api/v1/addresses/{id}`	`addresses:write`	Löschen, nur wenn unbenutzt (`cnf_AdCanDelete`)

Belege werden nie über DELETE entfernt; bei Adressen ist DELETE erlaubt, solange keine Belege oder Bewegungsdaten auf die Adresse verweisen - sonst antwortet die API mit 409 ADDRESS_IN_USE. Die Vorlage .MUSTER ist geschützt (409 ADDRESS_TEMPLATE_PROTECTED).

Artikel

Sat, 18 Jul 2026 15:54:55 +0200

Ressource: articles #

Artikelstamm der EULANDA-Tabelle Artikel. Die Anlage läuft über die EULANDA-Prozedur cn_ArNew (übernimmt den Vorlagen-Artikel .MUSTER samt Preisen und Merkmalen, falls vorhanden). Preisfindung und Bestände sind read-only und kommen aus den EULANDA-Funktionen - die API rechnet nie selbst. Bilder und DMS-Dateien des Artikels: siehe Bilder und DMS-Dateien.

Endpunkte #

Methode	Pfad	Scope	Zweck
GET	`/api/v1/articles`	`articles:read`	Liste (Paging, Filter, `q`, `changedSince`, `fields`, `categoryAnd/Or/Not`)
GET	`/api/v1/articles/categories`	`articles:read`	Merkmalbaum für den Merkmal-Filter, siehe Merkmale
GET	`/api/v1/articles/{id}/categories`	`articles:read`	Merkmale eines Artikels
PUT/PATCH	`/api/v1/articles/{id}/categories`	`articles:write`	Merkmal-Zuordnung ersetzen bzw. ändern
GET	`/api/v1/articles/{id}/service-articles`	`service-articles:read`	Geräte-Instanzen des Artikels, siehe Serviceartikel
GET	`/api/v1/articles/ids`	`articles:read`	Schlüsselliste für den Lösch-Abgleich
GET	`/api/v1/articles/{id}`	`articles:read`	Einzelner Artikel über die Id
GET	`/api/v1/articles/by-number/{number}`	`articles:read`	Einzelner Artikel über die Artikelnummer
POST	`/api/v1/articles`	`articles:write`	Anlegen (`cn_ArNew` + Felder)
PATCH	`/api/v1/articles/{id}`	`articles:write`	Felder ändern (partiell)
DELETE	`/api/v1/articles/{id}`	`articles:write`	Löschen, nur wenn unbenutzt (`cnf_ArCanDelete`)
GET	`/api/v1/articles/{id}/price`	`articles:read`	Preisfindung (`cn_Preis_GetVk`)
GET	`/api/v1/articles/{id}/stock`	`articles:read`	Bestände (`cnf_BestandVerfuegbarGesamt`, `cnf_ArLagerBestand`)

Der Vorlagen-Artikel .MUSTER ist geschützt (409 ARTICLE_TEMPLATE_PROTECTED); eine übergebene articleNumber wird über cnf_ArUniqueArtNummer eindeutig gemacht.

Kontakte

Sat, 18 Jul 2026 15:19:07 +0200

Ressource: contacts (Ansprechpartner einer Adresse) #

Kontakte sind eine Unter-Ressource der Adresse (EULANDA-Tabelle Kontakt, verknüpft über AdresseId). Sie nutzen die Adress-Scopes: Lesen mit addresses:read, Schreiben mit addresses:write.

Endpunkte #

Methode	Pfad	Zweck
GET	`/api/v1/addresses/{addressId}/contacts`	Liste (limit/offset, `q`, `changedSince`, `fields`)
GET	`/api/v1/addresses/{addressId}/contacts/{id}`	Einzelner Kontakt
POST	`/api/v1/addresses/{addressId}/contacts`	Anlegen (Pflichtfeld `lastName`)
PATCH	`/api/v1/addresses/{addressId}/contacts/{id}`	Felder ändern (partiell)
DELETE	`/api/v1/addresses/{addressId}/contacts/{id}`	Löschen

Kontakte sind nur innerhalb ihrer Adresse erreichbar - ein Kontakt einer anderen Adresse liefert 404.

Angebote und Aufträge

Sat, 18 Jul 2026 17:11:33 +0200

Ressourcen: quotes und sales-orders #

Angebote (Angebot) und Aufträge (Auftrag) mit Positionen. Alles Wertbildende läuft über die EULANDA-SQL-API: Kopf-Anlage über cn_AnCre bzw. cn_CreAf (vergibt die Belegnummer aus dem Nummernkreis), Positionen über cn_CreAnp bzw. cn_CreAfp (macht Preisfindung, Steuer und Summen), Wandlung über cn_TraAnAf_Typ. Summen, Steuern und Status sind read-only. Buchen und Storno bleiben bewusst dem ERP-Anwender vorbehalten (eigene Scopes documents:book/documents:cancel folgen später).

Endpunkte #

Für beide Belegarten identisch (/api/v1/quotes/... bzw. /api/v1/sales-orders/...):

Mitarbeiter

Sat, 18 Jul 2026 15:19:07 +0200

Ressource: employees (read-only) #

Mitarbeiter sind in EULANDA freigeschaltete Adressen: Im ERP wird eine Adresse als Mitarbeiter markiert (Prozedur cn_AdSetMitarbeiter), dadurch landet ihre Adresse.ID in der Filter-Tabelle Mitarbeiter - dort liegen auch Personalnummer und Loginname. Die Ressource zeigt genau diese freigeschalteten Adressen; alle anderen Adressen sind über /employees nicht sichtbar.

Die Ressource ist bewusst read-only - Freischaltung und Personalpflege bleiben im ERP. Abzugrenzen: Vertreter (Repräsentanten, die Provisionen auf Umsätze erhalten und auch Externe sein können) sind ein eigenes Konzept und kommen bei Bedarf als eigene Ressource.

Bilder

Sat, 18 Jul 2026 15:19:07 +0200

Ressource: image (Bilder in der Datenbank) #

Adressen und Artikel tragen ihr Bild direkt in der EULANDA-Datenbank (Spalten Bild, BildVorschau, BildRevision). Die API liest und schreibt diese Blobs; bei jedem Schreiben wird BildRevision erhöht, damit EULANDA-Clients ihre Caches invalidieren.

EULANDA-Konvention (aus den Bestandsdaten): Hauptbild max. 650 px Kantenlänge, Vorschaubild max. 320 px, Format JPEG. Die API nimmt nur JPEG an (422 IMAGE_FORMAT_INVALID sonst), skaliert zu große Bilder automatisch herunter und erzeugt beim Setzen des Hauptbilds das Vorschaubild gleich mit.

Lieferanten

Sat, 18 Jul 2026 15:19:07 +0200

Ressourcen: suppliers und supplier-articles #

Lieferanten sind in EULANDA freigeschaltete Adressen: Die Prozedur cn_KrCre legt zur Adresse den Kreditor-Satz mit den Einkaufskonditionen an (und erzeugt dabei das Lieferanten-Lagerkonto), cn_KrDel nimmt die Freischaltung zurück. Die Lieferantenartikel (KrArtikel) ordnen EULANDA-Artikel dem Lieferanten zu - mit dessen Artikelnummer und Einkaufspreis.

Hinweis Vertraulichkeit: Die suppliers-Scopes sind die Einkaufs-Scopes - suppliers:read sieht Einkaufspreise. Shop- oder Sync-Clients bekommen diesen Scope nicht.

Endpunkte #

Methode	Pfad	Scope	Zweck
GET	`/api/v1/suppliers`	`suppliers:read`	Liste inkl. `addressMatch`/`addressName`
GET	`/api/v1/suppliers/{id}`	`suppliers:read`	Einzelner Lieferant
POST	`/api/v1/suppliers`	`suppliers:write`	Adresse als Lieferant freischalten (`cn_KrCre`)
PATCH	`/api/v1/suppliers/{id}`	`suppliers:write`	Einkaufskonditionen ändern
DELETE	`/api/v1/suppliers/{id}`	`suppliers:write`	Freischaltung zurücknehmen (`cn_KrDel`; 409 bei Lieferantenartikeln)
GET	`/api/v1/suppliers/{supplierId}/articles`	`suppliers:read`	Lieferantenartikel
POST	`/api/v1/suppliers/{supplierId}/articles`	`suppliers:write`	Artikel zuordnen
PATCH	`/api/v1/suppliers/{supplierId}/articles/{id}`	`suppliers:write`	Konditionen/EK ändern
DELETE	`/api/v1/suppliers/{supplierId}/articles/{id}`	`suppliers:write`	Zuordnung entfernen

DMS-Dateien des Lieferanten: /api/v1/suppliers/{id}/files (Scopes dms:*, Ordner LIEFERANTEN\<Match>).

SQL-Registry

Sat, 18 Jul 2026 15:19:07 +0200

Ressource: registry #

Zugriff auf die EULANDA-SQL-Registry - ausschließlich über die cn_Reg*-Prozeduren der SQL-API (nie die Tabelle direkt), Subtrees über den Performance-Pfad cn_RegBulkRead.

Härtung: Die Registry ist mächtig, deshalb gilt zusätzlich zu den Scopes je API-Client eine Pfad-Präfix-Allowlist (Set-XrestApiClient -RegistryReadPrefix/-RegistryWritePrefix): Lesen braucht einen passenden Präfix, Schreiben einen Schreib-Präfix - ohne Treffer 403 REGISTRY_PATH_FORBIDDEN. Verschlüsselte Werte (*.crypt) liefert oder schreibt die API grundsätzlich nicht (403 REGISTRY_CRYPT_FORBIDDEN); in Subtree-Antworten fehlen sie.

Merkmale (categories)

Sat, 18 Jul 2026 15:19:07 +0200

Merkmale (API: categories) #

Der EULANDA-Merkmalbaum ist die zentrale Filter-Struktur der Stammdaten: Datensätze werden Baumknoten zugeordnet (Mehrfachzuordnung möglich) und darüber gefiltert. Die API führt diese Struktur unter dem Namen categories - der branchenübliche Begriff für einen hierarchischen Kategoriebaum mit Mehrfachzuordnung. Abgrenzung: productGroup (Warengruppe) ist ein einwertiges Feld am Artikel, categories ist der mehrwertige Baum.

Unterstützt für articles und addresses (weitere Ressourcen folgen).

Endpunkte #

Methode	Pfad	Scope	Zweck
GET	`/api/v1/articles/categories`	`articles:read`	Merkmalbaum der Artikel
GET	`/api/v1/addresses/categories`	`addresses:read`	Merkmalbaum der Adressen
GET	`/api/v1/articles/{id}/categories`	`articles:read`	Merkmale eines Artikels
GET	`/api/v1/addresses/{id}/categories`	`addresses:read`	Merkmale einer Adresse
PUT	`/api/v1/{entity}/{id}/categories`	`<entity>:write`	Zuordnung komplett ersetzen
PATCH	`/api/v1/{entity}/{id}/categories`	`<entity>:write`	Zuordnung ändern (add/remove)
POST	`/api/v1/{entity}/categories`	`categories:manage`	Knoten anlegen
PATCH	`/api/v1/{entity}/categories/{nodeId}`	`categories:manage`	Knoten umbenennen/verschieben
DELETE	`/api/v1/{entity}/categories/{nodeId}`	`categories:manage`	Knoten löschen (`?force=true` für Äste)

Der Baum kommt als verschachtelte Struktur; ?lang= (bzw. Accept-Language) steuert die Sprache des rootLabel:

Serviceartikel (Geräte)

Sat, 18 Jul 2026 15:54:55 +0200

Ressource: service-articles #

Serviceartikel sind die EULANDA-Geräteverwaltung: ein konkretes Gerät beim Kunden (z.B. eine Drehbank), verknüpft mit dem Stamm-Artikel, dem Kunden, der Standort-Adresse, Seriennummer, Prüf-/Wartungs-/ Garantie-Terminen, eigenem Merkmalbaum, Bild und DMS-Ordner. Über die ServiceArtikelId-Verweise in allen Belegtabellen liefert die API die komplette Gerätehistorie - die Basis für Field-Service-Szenarien (Geräteübersicht je Kunde, Reparaturhistorie, Serviceauftrag direkt am Gerät).

Das Modul existiert ab EULANDA-Schema 6.7. Fehlt die Tabelle in einer älteren Datenbank, liefern alle Endpunkte 501 SERVICE_ARTICLES_UNAVAILABLE.

DMS-Dateien

Sat, 18 Jul 2026 15:19:07 +0200

Ressource: files (DMS) #

Zugriff auf die Dokumente des EULANDA-DMS je Datensatz. Der physische Ordner wird serverseitig über die EulandaXtools-Kette aufgelöst (Get-DmsFolderAddress, Get-DmsFolderInvoice, …); Clients sehen nur relative Pfade. Existiert das DMS-Plugin (esol.DMS) in der Installation nicht, antworten alle Routen mit 409 DMS_NOT_AVAILABLE - geprüft wird das über den Registry-Key des Plugins.

Endpunkte #

Dieselben vier Routen gibt es je Entität unter deren Ressourcen-Pfad:

Ressource	Basis-Pfad	EULANDA-Objekt
Adressen	`/api/v1/addresses/{id}/files`	Adresse
Artikel	`/api/v1/articles/{id}/files`	Artikel
Angebote	`/api/v1/quotes/{id}/files`	Angebot
Aufträge	`/api/v1/sales-orders/{id}/files`	Auftrag
Lieferscheine	`/api/v1/delivery-notes/{id}/files`	Lieferschein
Rechnungen	`/api/v1/invoices/{id}/files`	Rechnung

{id} ist jeweils die interne Id des Datensatzes.

Lager, Stücklisten, Idents

Sat, 18 Jul 2026 16:46:53 +0200

Lager, Stücklisten (Jumbo), Seriennummern/Chargen #

Bestand wird in EULANDA nie gesetzt, nur gebucht - die Konten- und Journaltabellen sind DB-seitig gegen direkte Änderungen gesperrt. Die API bildet das ab: Lesen ist frei, Schreiben läuft ausschließlich über die EULANDA-Belegkette.

Endpunkte #

Methode	Pfad	Scope	Zweck
GET	`/api/v1/warehouse/groups`	`stock:read`	Lagergruppen (Standorte, Standard = 1)
GET	`/api/v1/warehouse/locations`	`stock:read`	Physische Lagerorte (`?warehouseGroupId=` filtert über die Gruppen-Matrix)
GET	`/api/v1/articles/{id}/stock/locations`	`stock:read`	Bestand je Ort + Reservierungen + Summen (`cnf_ArLagerBestand`)
GET	`/api/v1/articles/{id}/stock/movements`	`stock:read`	Lagerbewegungen (`?limit=`, Default 50)
POST	`/api/v1/articles/{id}/stock/actions/set-quantity`	`stock:write`	Bestand per Differenzbuchung setzen
POST	`/api/v1/warehouse/bookings`	`stock:write`	Lagerbeleg buchen (movement/transfer)
GET	`/api/v1/articles/{id}/idents`	`stock:read`	Verfügbare Seriennummern/Chargen
GET	`/api/v1/idents/{id}/history`	`stock:read`	Rückverfolgung einer SN/Charge
GET	`/api/v1/articles/{id}/parts-list`	`articles:read`	Stückliste mit Positionen
POST	`/api/v1/articles/{id}/parts-list/items`	`articles:write`	Komponente anfügen (`cn_JbAdd`)
DELETE	`/api/v1/articles/{id}/parts-list`	`articles:write`	Stückliste löschen (`cn_JbDrop`)
POST	`/api/v1/articles/{id}/parts-list/actions/recalc`	`articles:write`	Preise/Gewicht durchrechnen (`cn_JbRecalc`)

Bestand setzen = Differenz buchen #

set-quantity nutzt die EULANDA-SP cn_LL_SetBestandAbsolut: sie liest den Ist-Bestand der Lagergruppe und bucht nur die Differenz als Warenbewegungs-Beleg mit Kommentar - eine saubere, stornierbare Buchung statt eines Overwrites. Ist der Bestand schon korrekt, entsteht kein Beleg (changed: false).

Einkauf (Bestellungen)

Sat, 18 Jul 2026 18:04:08 +0200

Ressource: purchase-orders #

Bestellungen an Lieferanten (KrAuftrag), Scopes purchase-orders:read/write (Einkaufspreise inklusive). Status: 0 Erfassen, nach actions/book 3 bestellt, nach vollständigem Wareneingang >= 20 abgeschlossen.

Methode	Pfad	Zweck
GET	`/api/v1/purchase-orders` (+`/{id}`, `/by-number/{no}`, `/{id}/items`)	Lesen mit Paging/Filtern/`changedSince`
POST	`/api/v1/purchase-orders`	Anlegen `{ supplierId, orderedBy? }` (`cn_KfNewAndSave`)
POST	`/api/v1/purchase-orders/{id}/items`	Position `{ articleId, quantity, autoAddSupplierArticle? }` (`cn_KfAddUpdateAr` - addiert bei vorhandenem Artikel)
PATCH	`/api/v1/purchase-orders/{id}/items/{itemId}`	Menge ändern (`cn_KfpUpdateMenge`)
POST	`/api/v1/purchase-orders/{id}/actions/book` bzw. `cancel-booking`	Buchen/Storno (`cn_KfBuchen`/`cn_KfStornoBuchung`)
POST	`/api/v1/purchase-orders/{id}/goods-receipts`	Wareneingang erzeugen (`cn_LLWE_NewFromKf`; ohne `warehouseGroupId` gilt die Lagergruppe der Bestellung)
POST	`/api/v1/warehouse/documents/{id}/actions/book`	Lagerbeleg (z.B. den Wareneingang) buchen - ziffert die Bestellung ab
GET	`/api/v1/sales-orders/{id}/purchase-proposal`	Bestellvorschlag je Auftragsposition (Bedarf, bestellt, Vorschlag, Hauptlieferant)
POST	`/api/v1/sales-orders/{id}/purchase-orders`	Bestellung aus Auftrag: `{ supplierId, supplierMode: all/mainSupplier/existing, items? }` (`cn_TraAfToKf_FromXml`, Quell-Mapping in `KrAuftragQuelle`)

Kasse (POS)

Sat, 18 Jul 2026 19:22:40 +0200

Kasse #

Die Kasse ist voll fernsteuerbar: Lesen über MASTER_KasseBeleg/ MASTER_KasseBelegZeile (Scope cash:read), Schreiben über die originalen Delphi-SP-Ketten (cn_Cash*, Scope cash:write) - exakt dieselben Abläufe wie in der EULANDA-Kasse und in EulandaXpos. Die API implementiert keine eigene Kassenlogik: Preisfindung, Pfand-/ Extra-Artikel, Lagerbuchung, Festschreibung und TSE-Protokollierung macht die Datenbank.

Das Kassenmodell in drei Sätzen #

Pro Kasse gibt es genau einen offenen Bon (Lazy-Modell): POST /receipts liefert den offenen Bon zurück (reused: true), statt einen zweiten zu eröffnen. Ein kassierter Bon ist festgeschrieben - danach hilft nur ein Storno-Bon, kein Ändern (409 CASH_RECEIPT_COMPLETED). Am Tagesende gehört genau ein Z-Abschluss (actions/close), am Tagesanfang typischerweise eine Kasseneinlage (actions/deposit, Wechselgeld).

Statistik

Sat, 18 Jul 2026 17:45:46 +0200

Statistik #

Scope statistics:read. Grundlage sind die EULANDA-Pivot-Views in Stammwährung - PIVOT_Umsatz vereint Rechnungen und Kasse.

Methode	Pfad	Zweck
GET	`/api/v1/statistics/revenue`	Umsatz-Cube: `?groupBy=` month, quarter, year, customer, country, zip, salesRep, weekday, hour, article, productGroup; `?from=/?to=` (Datum), `?source=` invoices/cash. Je Gruppe `revenue`, `profit`, `receipts`
GET	`/api/v1/statistics/kpi`	Kennzahlen-Kacheln: Umsatz/Ertrag je Jahr, Vorjahr, Monat, Vormonat - getrennt für Rechnungen und Kasse
GET	`/api/v1/statistics/product-groups`	Warengruppen-Monatsstatistik (`cnf_StatWG`): Anteile, Vorjahresvergleich, kumulierte Werte; `?fromYear=/?toYear=`

Lookups (Konstanten)

Sat, 18 Jul 2026 17:45:46 +0200

Lookups #

Scope lookups:read. GET /api/v1/lookups listet die Kataloge, GET /api/v1/lookups/{name} liefert { value, label } aus den EULANDA-LOOK-Views: units, product-groups, customer-groups, discount-groups, countries, payment-methods, currencies, shipping-methods, vat-groups, languages, manufacturers, warehouse-types, cash-receipt-types. Die Werte sind die gültigen Schlüssel für Felder wie unit, productGroup oder country.

Zahlungen & Offene Posten

Sat, 18 Jul 2026 20:37:52 +0200

Zahlungen und Offene Posten #

Zahlungseingänge leben in der Tabelle RechnungZe. Die API schreibt dort direkt - das ist der offizielle EULANDA-Weg: Datenbank-Trigger pflegen den bezahlten Betrag (paidAmount) und den Saldo (balance) der Rechnung automatisch. Beide Felder stehen auch im Feld-Glossar der Rechnung.

Vorzeichen-Konvention (wichtig): Beträge werden 1:1 wie in der Datenbank geführt - ein Zahlungseingang ist negativ. Der Vertrag ist damit glasklar:

grossTotal + Summe aller payment.amounts = 0 bedeutet: bezahlt, der offene Posten verschwindet aus /open-items.