Einzelteil
Status
DRAFT - under construction
Business Object
This is part of OL2_Sendung_(ERP-LP)
| Name | Type | Content | Values | Mandatory |
|---|---|---|---|---|
| ERP_Einzelteil_ID | A50 | Eindeutiger gemeinsamer Identifikator des Einzelteils. Vergeben vom ERP. Für KR1 = EAL_ERP_Einzelteil_ID |
x | |
| Retourenschluessel | N12 | Retourenschluessel Der Retourenschlüssel wir in den Bestands-GL un -PL Betrieben benötigt. In den NEON-Betrieben aber explizit nicht. Dort wird ein konkreter Artikel nicht mehr mit Retourenschlüssel, sondern mit BU_ID identtifiziert. Die BU_ID wirde dann , analog der LKZ-Rückmeldung, vom LVS über LP an das ERP zurückgemeldet. |
||
| RetSchl_Rechnungsdruck_Knz_ID | N1 | Für eine Sendung mit mehreren Einzelteilen muss für den Rechnungsdruck festgelegt werden, welcher Retourenschlüssel auf die Rechung gedruckt werden soll. Hintergrund: pro Sendung wird nur eine Rechnung erzeugt. Es muss also pro Sendung genau ein Retourenschlüssel mit 1=drucken markiert sein. |
||
| Identcode_DLW_Schluessel | N8 | Erster Teil des Schlüssels für Durchlaufware. Dieses Feld enthält den NOA-Nonwhcommkey. Dieser ist eine 8-stellige fortlaufende Nummer, welche für Nichtlagerwarenaufträge vergeben wird. Zusammen mit dem ‘Identcode_DLW_Einspeichertag’ bildet er die sog. ‘Eingabenummer’, einen eindeutigen Identifier für einen Durchlaufwarenauftrag. In ADD wird dieser als ID_DLW in der Form gespeichert und zudem in die HES-Avise geschrieben. ADD übergibt für DL-Sendungen, wenn diese in Rechnung gehen, den Identifier an COBRA, welcher diesen in der Form <EINSP.TAG+500> verwendet, um die Ware zuzuordnen. |
||
| Identcode_DLW_Einspeichertag | N3 | Zweiter Teil des Schlüssels für Durchlaufware. Dieses Feld soll den Einspeicherungstag enthalten. | ||
| ERP_Product_Id | A36 | ERP_Product_Id: technischer Identfier für einen Artikel (bzw. einer Artikel-Groesse). Vergeben vom ERP und damit auch je ERP eindeutig. Damit kann der Artikel (zusammen mit der ERP_ID) im Artikelstamm identifiziert bzw. gefunden werden) Soll perspektivisch die Nutz-Attribute ( - Artikelnummer, - Groesse, - Bestandsfiirma, - Saison, - Bezeichnung, - Farbe usw.) hier in der Position obsolet machen |
||
| Haendler_Einzelteil_Identifier | A255 | Doku ERP-Seite: “Eine Referenz auf eine Position eines Kundenauftrages des Händlers.” Bei uns ist das eine Referenz des Händlers auf ein Einzelteil. Deep Sea wird vermutlich die SalesOrderPositionItemId (SOPI) hier übergeben. Was uns CORE übergibt, wissen wir nicht. Es ist fachlich auch nicht relevant. Wir übergeben das Feld an K.Motion, damit K.Motion es in der Warenbewegung an BuBe mitgeben kann. Muss rein fachlich zusammen mit Sendung.Haendler_Erp_Identifier eigentlich eindeutig sein. Da es das nach einer Lagerdifferenz oder Storno durch ERP und erneuter Übergabe duch das ERP aber im Zweifel nicht ist, validieren wir das nicht. Wir müssten sonst den Sendung_Status und Einzelteil_Status mit berücksichtigen. Und selbst wenn wir das täten, bin ich unsicher, ob das Konstrukt trägt. Darum stellen wir keine Eindeutigkeit sicher. |
Relations
| Table |
|---|
| LagerOrt_Info |
| Packstueck |
Last updated: Fri, 25 Apr 2025 01:44:50 UTC