Order-to-Cash (Gesamtflow)

Transaktionen: SAL15 Angebote, SAL16 Aufträge, SAL17 Lieferscheine, SAL18 Rechnungen
Zentrale API: /api/salesHead (SalesHeadApiController)
Domänen: SalesHead, SalesItem, Customer, SendPacks

Business-Zweck

Der Order-to-Cash (O2C)-Prozess beschreibt den vollständigen Weg vom Kundeninteresse bis zur bezahlten Rechnung in reybex. Für Partner ist dieser Flow der Integrations-Leitfaden: Welche Stammdaten zuerst, welche Belegarten in welcher Reihenfolge, welche APIs pro Phase und welche Querschnittstellen zu BAS, INV, SMP, PUR, FIN und OMP relevant sind.

Diese Seite ist die Master-Dokumentation für SAL – Detailseiten zu einzelnen Belegarten verlinken vertiefende Inhalte.

Gesamtarchitektur – Belegkette mit Modulen

Status-Codes – Übersicht

Partner-Integrationen müssen mehrere parallele Statusfelder unterscheiden – auf Kopf- und Positionsebene.

SalesHead – Kopfstatus

Feld	Werte	Bedeutung	Partner-Relevanz
`connectorStatus`	`0` offen, `1` geschlossen	Connector-/Shop-Polling abgeschlossen	`GET /connector` liefert nur `0`; nach Rückmeldung `saveForConnector` → `1`
`sendStatus`	`0` offen, `2` versendet	Versandfortschritt Kopf	Mit `isSend` und `SendPacks` kombinieren
`status`	mandantenspezifisch, oft `2` = geschlossen	Beleg-/Positionsabschluss	Filter in `getOpenOrders`, `showForConnector`
`blockedDelivery`	Boolean	Liefersperre	Beleg erscheint in `blockedSalesHeads` bei Folgedokumenten
`orderStatus`	OrderStatus-Typ	Connector-Workflow (in Bearbeitung / abgeschlossen)	Wird bei `saveForConnector` gesetzt

SalesItem – Positionsstatus

Feld	Werte	Bedeutung
`deliveryStatus`	`0` offen, `1` teilweise geliefert, `2` geschlossen	Lieferfortschritt je Position
`invoiceStatus`	`0` offen, `1` teilweise, `2` geschlossen	Fakturierungsfortschritt
`deliveredQuantity`	Decimal	Bereits gelieferte Menge
`invoicedQuantity`	Decimal	Bereits fakturierte Menge
`openQuantity`	Decimal	Noch offene Menge

Abfrage-Endpoints für Status

Endpoint	Liefert
`GET /api/salesHead/status/{id}`	Bearbeitungsstatus inkl. Positionsdetails
`GET /api/salesHead/isSend/{id}`	Versand abgeschlossen (`sendStatus=2`, `isSend`, aktive Packs)
`GET /api/salesHead/getOpenOrders`	Offene Aufträge für Fulfillment
`GET /api/salesHead/connector`	Offene Connector-Aufträge (`connectorStatus=0`)

Phase 1 – Stammdaten (Customer, Material, Preise)

Ohne konsistente Stammdaten scheitern Importe still oder mit BusinessExceptions.

1.1 Kunde (Debitor)

Schritt	Aktion	API / Transaktion
1	Kunde anlegen oder per Adress-Matching finden	`POST /api/customer/` (SAL01)
2	Liefer-/Rechnungsadressen pflegen	`POST /api/customer/saveAddress`
3	Kontaktperson für Belegversand	SAL04 / Contact Person API
4	CRM-Interessent → Kunde	`GET /api/customer/convertProspectToCustomer/{id}`

Beispiel – Kunde minimal anlegen:

json

{
  "name": "Muster GmbH",
  "street": "Industriestraße 12",
  "zipcode": "80331",
  "city": "München",
  "country": { "id": 1 },
  "email": "einkauf@muster.de",
  "currency": { "id": 1 },
  "paymcond": { "id": 100001 },
  "salesPriceListHead": { "id": 200001 }
}

→ Details: Kunden & Kontakte, Customer API, CRM Modulübersicht

1.2 Artikel (Material)

Voraussetzung	Modul	Hinweis
Verkaufbares Material	BAS02	`matCode`, EAN, ME, USt
Lagerführung	BAS02 + INV	`warehouse` in Position für Reservierung
Varianten/Attribute	BAS02	`variantCode`, `attributeCode` in SalesItem

→ Artikelstamm BAS02, Artikel Import Wizard

1.3 Preise

Preisfindung erfolgt in dieser Priorität (vereinfacht):

Kundensonderpreis (SAL06)
Kunden-/Artikelgruppen-Zuschlag (SAL07)
VK-Preisliste des Kunden bzw. Standardliste (SAL09)
Material-VK-Preis (BAS02)

Preis vor Auftrag prüfen:

bash

curl -X POST "$BASE_URL/api/salesHead/getSalesPrice" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "customerId": 1000001,
    "materialId": 2000001,
    "quantity": 5,
    "docDate": "2026-09-10"
  }'

→ Preise & Konditionen

Phase 2 – Angebot (optional, SAL15)

Angebote sind optional im O2C, aber üblich bei B2B mit Freigabe vor Auftrag.

Angebot → Auftrag (UI/API):

json

POST /api/salesHead/createProposalFromSalesHead
{
  "salesHeads": [1234567890123456]
}

→ Angebote

Phase 3 – Auftrag anlegen (SAL16)

Varianten

Variante	Endpoint	Einsatz
Standard-API	`POST /api/salesHead/`	Einzelauftrag, volle Kontrolle
Connector-Bulk	`POST /api/salesHead/connector` (Import) + Polling	Shop-Systeme
CSV/Import	`POST /api/salesHead/importFromCSV`	Batch aus Datei
Marktplatz OMP	OMP-Job / Marktplace-Konfiguration	Amazon, eBay etc.

Beispiel – Auftrag mit Positionen

json

{
  "docType": { "id": 300001 },
  "customer": { "id": 1000001 },
  "orderDate": "2026-09-10",
  "orderDescription": "Shop-Bestellung #SHOP-998877",
  "marktplaceOrderId": "SHOP-998877",
  "paymcond": { "id": 100001 },
  "currency": { "id": 1 },
  "items": [
    {
      "itemNumber": 1,
      "material": { "matCode": "ART-10001" },
      "quantity": 2,
      "price": 49.90,
      "vatKey": { "id": 1 },
      "warehouse": { "id": 500001 },
      "deliveryDate": "2026-09-15"
    },
    {
      "itemNumber": 2,
      "material": { "matCode": "ART-20002" },
      "quantity": 1,
      "price": 19.90,
      "vatKey": { "id": 1 }
    }
  ]
}

Response (Auszug):

json

{
  "id": 1234567890123456,
  "docNumber": "AU-2026-00456",
  "totalAmount": 119.70,
  "connectorStatus": 0,
  "items": [
    { "id": 9876543210, "itemNumber": 1, "deliveryStatus": 0, "openQuantity": 2 }
  ]
}

Idempotenz über `marktplaceOrderId`

Bei erneutem Import mit gleicher externer Order-ID soll kein Duplikat entstehen. Partner prüfen vor Anlage:

GET /api/salesHead/salesOrders mit Filter auf marktplaceOrderId
oder interne Duplicate-Logik im Connector-Flow

→ Aufträge, Shop-Import & Connector

Phase 4 – Reservierung & Bestand (INV)

Nach Auftragsspeicherung reserviert reybex Bestand auf StockList, sofern Material lagergeführt ist.

Bestand abfragen

bash

curl -G "$BASE_URL/api/salesHead/getStockData" \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "materialId=2000001" \
  --data-urlencode "warehouseId=500001"

Typische Response-Felder:

Feld	Bedeutung
`availableQuantity`	Verfügbar (ATP)
`reservedQuantity`	Bereits reserviert
`stockQuantity`	Physischer Bestand

Positions-Validierung

json

POST /api/salesItem/validateAvailableStock
{
  "salesItemIds": [9876543210, 9876543211]
}

Bei Unterdeckung: Beschaffung über PUR (POST /api/salesItem/createPurchaseRequest) oder Teillieferung via splitSales.

→ INV Modulübersicht, Bestandsliste

Phase 5 – Kommissionierung, Packen, Versand (INV06 / SMP)

Versanddaten aktualisieren

json

POST /api/salesHead/updateShipping
{
  "salesHeadId": 1234567890123456,
  "shipping": { "id": 600001 },
  "carrier": { "id": 700001 }
}

Versand validieren vor Lieferschein

bash

curl -G "$BASE_URL/api/salesHead/validateShipment" \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "salesHeadId=1234567890123456"

→ Kommissionierung INV06, Aufträge – Versand

Phase 6 – Lieferschein (SAL17)

Lieferscheine dokumentieren die Warenentnahme und reduzieren offene Liefermengen.

Folgedokument Auftrag → Lieferschein

json

POST /api/salesHead/referencingDocuments
{
  "salesHeadIds": [1234567890123456],
  "docType1": { "id": 300002 },
  "isDocument1Created": true,
  "isDocument2Created": false,
  "closeRefDocAsManuel": false
}

docType1 muss isDelnote=true sein und in SalesHeadDocRule vom Auftrags-DocType erlaubt.

Teillieferung – nur bestimmte Positionen:

json

{
  "salesHeadIds": [1234567890123456],
  "docType1": { "id": 300002 },
  "isDocument1Created": true,
  "isDocument2Created": false,
  "salesItemsToCopy": [
    { "salesItemId": 9876543210, "quantity": 1 }
  ]
}

Nach Erzeugung: deliveryStatus der Quellpositionen steigt; bei Vollieferung → 2.

→ Lieferscheine, SalesHead – Folgedokumente

Phase 7 – Rechnung (SAL18)

Pfad A: Auftrag → Rechnung (direkt)

json

POST /api/salesHead/referencingDocuments
{
  "salesHeadIds": [1234567890123456],
  "docType1": { "id": 300003 },
  "isDocument1Created": true,
  "isDocument2Created": false
}

Pfad B: Auftrag → Lieferschein → Rechnung (Standard B2B)

Zweistufig – siehe Phase 6, dann:

json

POST /api/salesHead/referencingDocuments
{
  "salesHeadIds": [1111222233334444],
  "docType1": { "id": 300003 },
  "isDocument1Created": true,
  "isDocument2Created": false
}

(1111222233334444 = Lieferschein-ID)

Pfad C: Sammelrechnung aus Lieferscheinen

bash

curl -G "$BASE_URL/api/salesHead/createInvoicesFromDelNotes" \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "salesHeadIds=1111222233334444,1111222233334445"

Connector-Kombi (LS + RE + Tracking in einem Schritt)

json

POST /api/salesHead/connector
{
  "salesHeads": [
    {
      "id": 1234567890123456,
      "referencingDocuments": {
        "deliveryNoteDocTypeName": "Lieferschein Standard",
        "invoiceDocTypeName": "Rechnung Standard",
        "sendPackDocTypeName": "Lieferschein Standard",
        "trackingNumber": "00340434161234567890",
        "carrierName": "DHL Paket"
      }
    }
  ]
}

→ Rechnungen, Auftrag → Rechnung

Phase 8 – FiBu-Übergabe (SAL11 / FIN)

Nicht übergebene Rechnungen listen

bash

curl -G "$BASE_URL/api/salesHead/listAllNonTransferedInvoices" \
  -H "Authorization: Bearer $TOKEN"

Batch-Übergabe

json

POST /api/salesHead/transferInvoicesToFinance
{
  "salesHeadIds": [2222333344445555, 2222333344445556],
  "transferDate": "2026-09-10"
}

Response:

json

{
  "success": true,
  "transferred": [
    { "salesHeadId": 2222333344445555, "finHeadId": 8888999900001111, "docNumber": "RE-2026-00123" }
  ],
  "errors": []
}

→ Rechnungslauf & FiBu, FIN Modulübersicht

Phase 9 – E-Rechnung (SAL13)

bash

curl -G "$BASE_URL/api/salesHead/getXInvoiceXml/2222333344445555" \
  -H "Authorization: Bearer $TOKEN"

Liefert XRechnung-/ZUGFeRD-kompatibles XML für Übergabe an Peppol, E-Mail-Gateway oder Archiv.

→ E-Rechnung

Teillieferung – splitSales

Wenn nicht alle Positionen gleichzeitig versendet werden können:

json

POST /api/salesHead/splitSales
{
  "salesHeadId": 1234567890123456,
  "items": [
    { "salesItemId": 9876543210, "quantity": 1 },
    { "salesItemId": 9876543211, "quantity": 1 }
  ]
}

Ergebnis: neuer Auftrag mit ausgelagerten Positionen; Original behält Restmengen. Anschließend getrennt kommissionieren und Lieferscheine erzeugen.

→ Aufträge – Teillieferung

Fehlerquellen-Matrix

Phase	Symptom	Typische Ursache	Maßnahme
1	Kunde nicht gefunden	Falsche `customerNo` / fehlender Import	SAL01 anlegen, Adress-Matching
1	Preis = 0	Keine Preisliste / kein Materialpreis	SAL09/SAL06 prüfen, `getSalesPrice`
3	Duplikat-Auftrag	`marktplaceOrderId` nicht geprüft	Vor POST suchen, Idempotenz-Key
3	BusinessException Material	`matCode` unbekannt	BAS02 Import
4	Reservierung fehlgeschlagen	Kein Bestand / falsches Lager	INV Bestand, `getStockData`
5	validateShipment Fehler	Pick unvollständig	INV06 Status prüfen
6	blockedSalesHeads	`blockedDelivery=true`	Sperre aufheben SAL16
6	salesHeadDocRule.not.found	DocType-Kette nicht konfiguriert	SalesHeadDocRule pflegen
7	Teilfakturierung	`invoiceStatus` / offene Mengen	`salesItemsToCopy` nutzen
8	FiBu-Fehler	Rechnung bereits übergeben	`listAllNonTransferedInvoices`
9	E-Rechnung leer	Pflichtfelder Kunde/USt	SAL13 Konfiguration, Kundenstamm

Partner-Szenarien (nummeriert)

Szenario 1 – Standard-Shop B2C (Connector)

Kunde + Artikel + Preise synchronisieren (Phase 1)
GET /api/salesHead/connector – offene Aufträge holen (connectorStatus=0)
Fulfillment im WMS; Tracking erfassen
POST /api/salesHead/connector mit referencingDocuments oder sendPacks
Optional FiBu + E-Rechnung

→ Shop-Import & Connector

Szenario 2 – B2B mit Lieferscheinpflicht

Auftrag per API (Phase 3)
Kommissionierung INV06 (Phase 5)
Lieferschein referencingDocuments (Phase 6)
Rechnung aus Lieferschein (Phase 7B)
FiBu-Übergabe (Phase 8)

Szenario 3 – Direktrechnung ohne LS

Auftrag anlegen
referencingDocuments mit Rechnungs-DocType (Phase 7A)
FiBu + E-Rechnung

→ Auftrag → Rechnung

Szenario 4 – Marktplatz OMP vs. Connector

Kanal	Mechanismus	Doku
OMP	Marktplace-Job, `MarktplaceOrderTransfer`	OMP-Modul
Connector	REST Polling `GET/POST /connector`	Shop-Import

Szenario 5 – Retoure im O2C

Retoure bricht den Forward-Flow; Rückfluss über SAL20.

→ Retouren, Return Head API

Voraussetzungen (Checkliste)

[ ] Mandant, OAuth/API-Token (Authentifizierung)
[ ] DocTypes + SalesHeadDocRule für Offer→Order→DelNote→Invoice
[ ] Nummernkreise je DocType
[ ] Kunden (SAL01), Material (BAS02), VK-Preise (SAL09)
[ ] Lager + Reservierungslogik (INV)
[ ] Versandarten / Carrier (SMP/BAS)
[ ] FiBu-Schnittstelle konfiguriert (FIN)
[ ] E-Rechnungs-Profil (SAL13)

Auswirkungen im ERP

Phase	Domänen-Impact
Auftrag	StockList-Reservierung, ggf. MRP (`materialIdsForMrp`)
Lieferschein	Bestandsabgang INV, `deliveryStatus` Positionen
Rechnung	Forderung, `invoiceStatus`, Umsatz
FiBu	`FinHead`, DATEV-Export
E-Rechnung	XML-Archiv, Versandstatus `isInvoiceSend`
Retoure	Gutschrift, Bestandszugang

Weiterlesen

Thema	Link
Modulübersicht + Integrations-Playbook	SAL Übersicht
Shop/Connector Detail	Shop-Import & Connector
Domänen & Status	Kern-Domänen
API Gesamt	—
Folgedokumente	—
Stammdaten	BAS
Lager	INV
Einkauf Drop-Ship	PUR
FiBu	FIN

Order-to-Cash (Gesamtflow) ​

Business-Zweck ​

Gesamtarchitektur – Belegkette mit Modulen ​

Status-Codes – Übersicht ​

SalesHead – Kopfstatus ​

SalesItem – Positionsstatus ​

Abfrage-Endpoints für Status ​

Phase 1 – Stammdaten (Customer, Material, Preise) ​

1.1 Kunde (Debitor) ​

1.2 Artikel (Material) ​

1.3 Preise ​

Phase 2 – Angebot (optional, SAL15) ​

Phase 3 – Auftrag anlegen (SAL16) ​

Varianten ​

Beispiel – Auftrag mit Positionen ​

Idempotenz über marktplaceOrderId ​

Phase 4 – Reservierung & Bestand (INV) ​

Bestand abfragen ​

Positions-Validierung ​

Phase 5 – Kommissionierung, Packen, Versand (INV06 / SMP) ​

Versanddaten aktualisieren ​

Versand validieren vor Lieferschein ​

Phase 6 – Lieferschein (SAL17) ​

Folgedokument Auftrag → Lieferschein ​

Phase 7 – Rechnung (SAL18) ​

Pfad A: Auftrag → Rechnung (direkt) ​

Pfad B: Auftrag → Lieferschein → Rechnung (Standard B2B) ​

Pfad C: Sammelrechnung aus Lieferscheinen ​

Connector-Kombi (LS + RE + Tracking in einem Schritt) ​

Phase 8 – FiBu-Übergabe (SAL11 / FIN) ​

Nicht übergebene Rechnungen listen ​

Batch-Übergabe ​

Phase 9 – E-Rechnung (SAL13) ​

Teillieferung – splitSales ​

Fehlerquellen-Matrix ​

Partner-Szenarien (nummeriert) ​

Szenario 1 – Standard-Shop B2C (Connector) ​

Szenario 2 – B2B mit Lieferscheinpflicht ​

Szenario 3 – Direktrechnung ohne LS ​

Szenario 4 – Marktplatz OMP vs. Connector ​

Szenario 5 – Retoure im O2C ​

Voraussetzungen (Checkliste) ​

Auswirkungen im ERP ​

Weiterlesen ​

Order-to-Cash (Gesamtflow)

Business-Zweck

Gesamtarchitektur – Belegkette mit Modulen

Status-Codes – Übersicht

SalesHead – Kopfstatus

SalesItem – Positionsstatus

Abfrage-Endpoints für Status

Phase 1 – Stammdaten (Customer, Material, Preise)

1.1 Kunde (Debitor)

1.2 Artikel (Material)

1.3 Preise

Phase 2 – Angebot (optional, SAL15)

Phase 3 – Auftrag anlegen (SAL16)

Varianten

Beispiel – Auftrag mit Positionen

Idempotenz über `marktplaceOrderId`

Phase 4 – Reservierung & Bestand (INV)

Bestand abfragen

Positions-Validierung

Phase 5 – Kommissionierung, Packen, Versand (INV06 / SMP)

Versanddaten aktualisieren

Versand validieren vor Lieferschein

Phase 6 – Lieferschein (SAL17)

Folgedokument Auftrag → Lieferschein

Phase 7 – Rechnung (SAL18)

Pfad A: Auftrag → Rechnung (direkt)

Pfad B: Auftrag → Lieferschein → Rechnung (Standard B2B)

Pfad C: Sammelrechnung aus Lieferscheinen

Connector-Kombi (LS + RE + Tracking in einem Schritt)

Phase 8 – FiBu-Übergabe (SAL11 / FIN)

Nicht übergebene Rechnungen listen

Batch-Übergabe

Phase 9 – E-Rechnung (SAL13)

Teillieferung – splitSales

Fehlerquellen-Matrix

Partner-Szenarien (nummeriert)

Szenario 1 – Standard-Shop B2C (Connector)

Szenario 2 – B2B mit Lieferscheinpflicht

Szenario 3 – Direktrechnung ohne LS

Szenario 4 – Marktplatz OMP vs. Connector

Szenario 5 – Retoure im O2C

Voraussetzungen (Checkliste)

Auswirkungen im ERP

Weiterlesen