Auftragsdaten aus SD
Optionaler Umfang: der Auftrag hinter der Forderung — und die Bestellnummer, nach der der Kunde sucht.
Die Brücke steht auf der Postenzeile selbst: SalesDocument, SalesDocumentItem und BillingDocument sind Eigenschaften des offenen Postens. Ein Umweg über den Belegfluss entfällt, und damit ist der Auftragsumfang zwei zusätzliche Lesevorgänge und kein zweites Projekt.
Was geliefert wird
| Bilendo | SAP | Warum |
|---|---|---|
| Custom Field „Auftrag“ | SalesDocument (am Posten) | Die Nummer, unter der intern gesucht wird. |
| Custom Field „Bestellnummer“ | A_SalesOrder.PurchaseOrderByCustomer | Die Nummer, nach der die Buchhaltung des KUNDEN sucht — der häufigste Grund, warum eine Rechnung „nicht bekannt“ ist. |
| Custom Field „Auftragsdatum“ | A_SalesOrder.SalesOrderDate / CustomerPurchaseOrderDate | Der zeitliche Bezug einer Reklamation. |
external_sales_unit | A_SalesOrder.SalesOrganization | Verkaufsorganisation. |
| Custom Field „Positionstext“ | A_SalesOrderItem.SalesOrderItemText / Material | Was geliefert wurde. |
| Custom Field je Partnerrolle | A_SalesOrderHeaderPartner | Auftraggeber, Warenempfänger, Rechnungsempfänger und Regulierer können vier Adressen sein. |
| Custom Field „Rechnungsart“ | A_BillingDocument.BillingDocumentType | Rechnung, Gutschrift, Storno. |
Wie gelesen wird
Nachrangig und nur zu bekannten Nummern: erst die Posten, dann in Gruppen die Aufträge und Rechnungen, die sie nennen. Ein Auftrag, den kein offener Posten nennt, wird nie geholt.
Nicht jede Forderung hat einen Auftrag: manuelle FI-Buchungen, Gutschriften und Zinsbelastungen tragen keine SD-Nummer. Der Umfang ist für diesen Teil leer — das ist kein Fehler.
Das Rechnungs-PDF ist eine eigene Entscheidung: der Fakturabeleg-Service kann es liefern, aber damit wird aus einem Attribut ein Dateitransfer, mit Volumen, Ablageort und Aufbewahrungsfrist.