Lager, Stücklisten, Idents
Zuletzt geändert: 18.07.2026 16:46

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 #

MethodePfadScopeZweck
GET/api/v1/warehouse/groupsstock:readLagergruppen (Standorte, Standard = 1)
GET/api/v1/warehouse/locationsstock:readPhysische Lagerorte (?warehouseGroupId= filtert über die Gruppen-Matrix)
GET/api/v1/articles/{id}/stock/locationsstock:readBestand je Ort + Reservierungen + Summen (cnf_ArLagerBestand)
GET/api/v1/articles/{id}/stock/movementsstock:readLagerbewegungen (?limit=, Default 50)
POST/api/v1/articles/{id}/stock/actions/set-quantitystock:writeBestand per Differenzbuchung setzen
POST/api/v1/warehouse/bookingsstock:writeLagerbeleg buchen (movement/transfer)
GET/api/v1/articles/{id}/identsstock:readVerfügbare Seriennummern/Chargen
GET/api/v1/idents/{id}/historystock:readRückverfolgung einer SN/Charge
GET/api/v1/articles/{id}/parts-listarticles:readStückliste mit Positionen
POST/api/v1/articles/{id}/parts-list/itemsarticles:writeKomponente anfügen (cn_JbAdd)
DELETE/api/v1/articles/{id}/parts-listarticles:writeStückliste löschen (cn_JbDrop)
POST/api/v1/articles/{id}/parts-list/actions/recalcarticles:writePreise/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).

$h = @{ Authorization = "Bearer $key" }
Invoke-RestMethod 'http://localhost:8100/api/v1/articles/4/stock/actions/set-quantity' -Method Post `
    -Body '{"quantity":25,"comment":"Inventur Regal 7"}' -ContentType 'application/json' -Headers $h
# -> { "documentId": 3, "changed": true, "quantity": 25.0 }
curl.exe -X POST -H "Authorization: Bearer %KEY%" -H "Content-Type: application/json" -d "{\"quantity\":25,\"comment\":\"Inventur Regal 7\"}" "http://localhost:8100/api/v1/articles/4/stock/actions/set-quantity"

Buchungen #

POST /warehouse/bookings legt einen Lagerbeleg an und bucht ihn (cn_LL_New/cn_LLWB_New + NewItem + PostNew + Buchen):

{ "type": "movement", "warehouseGroupId": 1, "comment": "Zugang Retoure",
  "items": [ { "articleId": 4, "quantity": 3 } ] }

{ "type": "transfer", "fromLocationId": 1000, "toLocationId": 500,
  "comment": "Umlagerung", "items": [ { "articleId": 4, "quantity": 2 } ] }

movement = Warenbewegung (WB, Menge mit Vorzeichen: + Zugang, − Abgang; Ziel-Ort default = Warenlager der Gruppe), transfer = Umlagerung (UB, fromLocationId/toLocationId Pflicht). Identpflichtige Artikel liefern derzeit den Fehler der Buchungsengine - die SN-Erfassung beim Buchen folgt in einer Ausbaustufe.

Seriennummern und Chargen #

SN und Charge sind ein Modell (kind: serial | batch) - eine Charge ist eine Ident mit Menge (z.B. Fliesen aus einem Brand). Ob ein Artikel identpflichtig ist, sagt identRequirement (none/serial/batch) in der Antwort von GET /articles/{id}/idents; die Liste enthält nur Idents mit Bestand (je Lagerort, mit Restmenge und Ablaufdatum) - genau das, was ein Client vor dem Verkauf anfordert. GET /idents/{id}/history liefert die komplette Rückverfolgung (Eingang, Umbuchungen, Verkauf mit Belegbezug refType/refId).

Stücklisten (Jumbo) #

type der Liste: set (nicht auflösend, bucht beim Lieferschein die Komponenten kumuliert), exploding (wird im Beleg in Positionen aufgelöst), optional, variant/variantWithMain (erzeugt Kopie-Artikel) und production. Kopf-Summenpreise sind trigger-gepflegt und read-only; Positionen zeigen den verfügbaren Bestand je Komponente. Beleg-Explosion (jbAufloesen beim Positions-POST) und Produktions- Buchungen folgen als Ausbaustufen.

Produktion, Inventur, Buchen mit SN-Erfassung #

Produktion: POST /articles/{id}/parts-list/actions/produce mit { "quantity": 1 } fertigt über cn_JbProd (Zugang Kopfartikel, Abgang Komponenten), negative Menge zerlegt. serialNumber für identpflichtige Köpfe.

Beleg-Explosion: Positions-POST auf Angebote/Aufträge versteht explodeBom (true/false) - bei auflösenden Stücklisten entstehen Komponenten-Positionen statt der Kopfposition; fehlt die Angabe bei einer optionalen Stückliste, antwortet die API mit 422.

Inventur (stock:write): POST /warehouse/inventories { locationId, name } eröffnet (Bestand wird eingefroren), GET /warehouse/inventories listet mit Status, Aktionen take-over-stock (Buchbestand als Zählmenge, { comment }), complete (bucht die Differenzen) und cancel. Einzelzählungen je Artikel folgen in einer Ausbaustufe - bis dahin deckt set-quantity den Einzelfall ab.

Belegfluss und Buchen (documents:book bzw. documents:write): POST /sales-orders/{id}/actions/book bucht den Auftrag (cn_AfBuchen, reserviert die Mengen - Voraussetzung im EULANDA-Belegfluss), POST /sales-orders/{id}/delivery-notes erzeugt daraus den Lieferschein (cn_TraAfLf_SingleAF, ohne sofortige Buchung), POST /delivery-notes/{id}/actions/book bucht ihn (cn_LfBuchen). Enthält der Beleg SN-/chargenpflichtige Positionen, antwortet die API mit 409 STOCK_DETAILS_REQUIRED; danach liefert GET /delivery-notes/{id}/stock-details die offenen Positionen samt verfügbarer Idents, POST .../stock-details ordnet zu (assignments für vorhandene, newIdents für neue Nummern), dann erneut buchen. Die verkaufte SN ist anschließend über GET /idents/{id}/history bis zum Kundenkonto rückverfolgbar.

Fehler #

StatusCodeBedeutung
404NOT_FOUNDArtikel/Ident/Stückliste existiert nicht
422VALIDATION_FIELD_INVALID / VALIDATION_LOOKUP_INVALIDUngültige Body-Werte bzw. unbekannte Artikel
500INTERNAL_ERRORFehler der Buchungsengine (z.B. SN-Erfassung erforderlich)