Sendung
Status
DRAFT - under construction
Business Object
This is part of Inbound_Sendung
| Name | Type | Content | Values | Mandatory |
|---|---|---|---|---|
| ERP_Sendung_ID | A50 | Eindeutiger gemeinsamer Identifikator der Sendung. Vergeben vom ERP. Bei DeepSea steckt die WFFO (WarehouseFulfillmentOrder) dahinter (1:n Beziehung zur erpShipmentId) | x | |
| LV_Tag | N3 | XXX. Arbeitstag des Kalenderjahres | x | |
| LV_Scheibe | N1 | 1-Taglauf 5-Nachtlauf |
x | |
| spaetester_Uebergabezeitpunkt | Date | Spätester Übergabe-Zeitpunkt an den Carrier bzw. das HUB. Format: DD.MM.JJJJ HH:MM:SS | ||
| fruehester_Uebergabezeitpunkt | Date | Frühester Übergabe-Zeitpunkt an den Carrier bzw. das Hub. Format: DD.MM.JJJJ HH:MM:SS. Wird z.B. benötigt für Artikel mit frühestem Erscheinungsdatum wie Computerspiele | ||
| Prioritaet_Auslieferung | N1 | Auslieferungs- bzw. Abwicklungs-Priorität. Erlaubte Werte: 1-9. 1=höchste Priorität, 9=niedrigste Priorität |
||
| Kundenfirma_Knz_ID | N2 | Kundenfirma Deprecated seit 31.05.2024. Wird durch “Auftraggeber” bzw. “outboundOrderOwner” abgelöst, bei vermutlich sehr langer Migrations-Phase. |
-3 = BONPRIX_UT -2 = LASCANA_UT -1 = OTTO_UT 1 = Otto 6 = Schwab 10 = Heine 20 = BonPrix 38 = Sonderabwicklung 39 = Endauslagerung 44 = Baur 51 = Collins 68 = Unigro 71 = Lascana 90 = FGH |
x |
| Kundenart | N2 | Kundenart Keine Validierung von “bekannten” Kundenarten. Referenzen von Kundenarten, die zur Steuerung verwendet werden, sind vorhanden. Deprecated seit mindestens 31.05.2024. (Das Feld war schon vorher als Deprecated markiert.) Wird durch “Auftraggeber” bzw. “outboundOrderOwner” abgelöst, bei vermutlich sehr langer Migrations-Phase. |
x | |
| Auftraggeber | A50 | Dieses Feld ist Ergebnis von ARC-126 “verschiedene Mandaten identifizieren können”. An einer Sendung muss es zukünftig möglich sein, unterschiedliche “F2X-Partner” bzw. “F2X-Mandaten” unterscheiden zu können. Benötigt wird die Information in Flash, damit dort bekannt ist, an welchen konkreten F2X-Mandaten dort abzurechnen ist. Die Lösung hier soll sich Analog der ReSy-Lösung verhalten. In ReSy hängt am ROC (ReturnOrderContract) der “returnOrderOwner”. Wir etablieren hier für Outbound eine identische Lösung. Die möglichen Ausprägungen übernehmen wir von ReSy. Diese Lösung soll das Konstrukt aus den Feldern “Kundenfirma_Knz_ID” + “Kundenart” perspektivisch ablösen. Es wird aber sicher eine recht lange Migrations-Zeit nötig sein. |
ERP = F2X: | x |
| Rechnungsnummer | N10 | Rechnungsnummer Die Rechnungsnummer wird aktuell auf 7 Stellen abgeschnitten und eine Warnung ausgegeben, wenn sie abgeschnitten wurde. Mit Commit wird sie für Auftragspuffer_KR2 nicht mehr abgeschnitten. |
||
| Lieferscheinnummer | A9 | Lieferscheinnummer (Stellen 1-9 des Retourenschlüssels) |
||
| Liefernummer | N10 | transportiert die SAP-Liefernummer (eingeführt mit IBIZA 3.0) eindeutiger Identifier für BP-Sendungen, welcher teilweise auf Lieferscheinen angedruckt wird und zentrale Bedeutung für die Kundenkommunikation hat (entspricht für BP aktuell der ERP_Sendung_ID, dort wird jedoch eine 1=Endkundensendung, bzw. 2=Großkundensendung vorangestellt) |
x | |
| Bestelldatum_Extern | Date | Bestelldatum, eingeführt für BP - Kundenfirma ‘Zalando’ (Andruck auf Lieferscheine für Zalando-Sendungen) | ||
| Kontonummer | N12 | Kontonummer Für L2C ist die Kontonummer pro Kundenfirma und Kundenart. z.B. Heine Deutschland hat die Kontonummer 80001007, SiehAn Deutschland 80001007 aber beide gehören der Kundenfirma HEINE DEUTSCHLAND |
x | |
| Kontonummer_Extern | A25 | Wir haben im Konzern mehrere Stellen, an denen wir Sendungen NICHT von dem ERP bekommen, dass auch die Rechnung (oder den Inhalt anderer Dokumente) erzeugt hat. Für CORE L2C Mandaten bekommen wir im Feld “Kontonummer” nur eine “Stellvertreter-Kontonummer” von CORE. Die echte Kontonummer aus dem ERP, dem Fakturiert wurde (z.B. ein Movex für Lascana) bekommen wir hier im Feld Kontonummer_Extern. Bei Bonprix gibt es vergleichbare Sachverhalte. Unser Schnittstellenpartner, das Bonprix SAP ERP, ist nicht das eigentliche ERP, dass eine Rechnung o.Ä. erzeugt hat. Das war möglicherweise eines der verschiedenen Bonprix SRD Systeme. In dem Fall bekommen wir heir die echte Kontonummer des Endkunden, die er in SRD hat. |
||
| Auftragsnummer | A20 | CORE/L2C: externe Auftragsnummer - zu befüllen in Haldensleben für Kundenfirma Lascana - zu befüllen für Unigro (Belgien) mit der “Reference_ID” - für HVS und HES (exerne Auftragsnummer für Avise) IDEEFIX: eine Zalando-spezifische Bestellnummer |
||
| Unterkonto | N2 | Unterkonto wurde mit Einführung von CORE abgeschafft |
x | |
| Kontonummer_Baur | A11 | alphanummerische Kontonummer bei Baur | ||
| Rechnungsdatum | Date | Rechnungsdatum TT.MM.JJJJ Ist aktuell nicht nur auf Rechnung oder Lieferschein pflicht, sondern wird auch auf dezentrale Versandaufkleber gedruckt und auch in der Carrier-Avise für HES (durch ADD) zwingend benötigt. |
x | |
| Lieferbedingung_Knz_ID | N2 | Informationen wird für alle HVS-Sendungen auf das Feld Versender_HVS.JN_Eil_Zustellung gemappt. Für HES-Sendungen erfolgt ein Mapping auf das Feld VersenderHES.HES_Service_Knz_Id. |
0 = Normalservice 1 = Eilservice normal 2 = Eilservice Vormittag 3 = Eilservice Nachmittag 4 = Feierabend 5 = Wunschtermin (nicht kostenpflichtig) 6 = Wunschtermin (kostenpflichtig) - normal 7 = Wunschtermin (kostenpflichtig) - 10-13 Uhr 8 = Wunschtermin (kostenpflichtig) - 12-15 Uhr 9 = Wunschtermin (kostenpflichtig) - 14-17 Uhr 10 = Wunschtermin (kostenpflichtig) - 18-21 Uhr 11 = Sonnabend 12 = Sonnabend Vormittag 13 = Sonnabend Nachmittag 14 = 24 Stunden 15 = 48 Stunden 16 = 72 Stunden nicht taggleich 17 = 72 Stunden taggleich 19 = Eilservice Großstücke, Express 2-3 Tage 20 = Next Day Service (nur Ohrdruf) 21 = Normalservice - beschleunigte Zustellung |
x |
| Wunschtermin | Date | TT.MM.JJJJ Wird für HES-Sendungen auf das gleichnamige Feld am VersenderHES Knoten gemappt. |
||
| Zahlungsart_Knz_ID | N2 | 0 = Rechnung 1 = Nachnahme 2 = Barkauf 3 = Kreditkarte 4 = Jelmoli J-Card 5 = Bankeinzug 13 = Bankkarte Ideal OVNL oder Cofidis-Card 14 = GiroPay 15 = PayPal 16 = ClickandBuy 17 = Sofortberweisung 19 = Vorkasse 29 = Yapital 30 = Paydirekt 31 = Kreditkarte Online 32 = PayU (nur Bonprix SRD Polen) |
||
| Ratenzahlung_Knz_ID | N1 | 0=keine Ratenzahlung 1=Ratenzahlung (wird z.B. in Holand für Bar- und Kreditkauf benötigt) |
||
| Nachnahmebetrag | N9 | Nachnahmebetrag, welcher für Nachnahmesendungen auf den Paketaufkleber gedruckt wird | ||
| Nachnahmegebuehr | N9 | für Avisen in ADD | ||
| Rechnungs_Knz_ID | A1 | Teilt mit, welche Dokumente (Rechnung/Lieferschein/nichts) für die Sendung gedruckt werden müssen. | R = Rechnung L = Lieferschein X = Sendung ohne Rechnung/Lieferschein D = Sendung digitaler Packplatz |
x |
| Lieferscheintyp_Knz_ID | N1 | Legt den Lieferscheintyp (mit oder ohne Handelsteil) fest und hängt eng mit der Rechnungs_Knz_ID zusammen (siehe Kommentar Pflichtfeld/Validierung). Obwohl es für Sendungen, welche auf digitalen Packplätzen abgewickelt werden sollen (Rechnungs_Knz_ID = ‘D’), keine (gedruckte) Rechnung oder Lieferschein benötigt, muss dennoch eine Lieferscheintyp_Knz_ID gesetzt sein. Dies ist dadurch bedingt, dass im Lagerstandort ggf. nicht genügend digitale Packplätze für die Abwicklung zur Verfügung stehen und die Sendung dann auf einen “alten”/analogen Packplatz umgesteuert werden muss. Dort benötigt der Druck dann die Information, welcher Lieferscheintyp gedruckt werden soll. |
1 = Lieferschein ohne Handelsteil 2 = Lieferschein mit Handelsteil |
|
| Zahlschein_Knz_ID | N1 | 0 = es ist kein Zahlschein zu drucken 1 = es ist ein Zahlschein zu drucken, Zahlscheindaten in Zahlschein_DE, … |
||
| Sendungssplit_Knz_ID | N1 | 0 = kein Sendungssplit 1 = Sendungssplit |
x | |
| Teillieferung_Knz_ID | N1 | Text auf Rechnung “Bei Teillieferungen berechnen wir Versandkosten nur einmal” |
0 = keine Teillieferung 1 = Teillieferung |
x |
| Neukunden_Knz_ID | N1 | 0 = nichts 1 = Profi 2 = Neukunde 3 = Premium 4 = Agentur |
||
| Sammelbesteller_Knz_ID | N1 | 0 = kein Sammelbestellerauftrag 1 = Sammelbestellerauftrag |
x | |
| Personal_Knz_ID | N1 | 0 = keine Personalbestellung 1 = Personalbestellung |
x | |
| Sprach_Knz_ID | A2 | de = Deutsch fr = Französisch |
x | |
| Steuernummer | A15 | Steuernummer | ||
| Umsatzsteuernummer | A24 | Umsatzsteuernummer | ||
| VIP_Punktestand | N6 | Druck auf Österreich Rechnungen | ||
| KB_Telefonnummer | A20 | Telefonnummer der Kundenbetreuung inkl. Vorwahl | x | |
| Manuelle_Rechnung_Knz_ID | N1 | Kennzeichen für Art der manuellen Rechnung KA431 - KA435 |
0 = keine manuelle Rechnung 1 = Nachbelastung durch den Betrieb(Satzart 431) 2 = Berichtigung einer Gutschrift (Satzart 432) 3 = Sonder-Rechnung, manuell (Satzart 433) 4 = Verkäufe der Niederlassungen (Satzart 434) 5 = Nachbelastung, nicht bestand- und umsatzwirksam (Satzart 435) |
x |
| Retourenbarcode_Druck_Knz_ID | N1 | 0 = Retourenschlüsselbarcode nicht in Artikelzeilen drucken 1 = Retourenschlüsselbarcode in Artikelzeilen drucken |
||
| BriefrechnungTyp_Knz_Id | N1 | 0 = normaler Versand 1 = VAL_Nachnahme 2 = Verteilung im Haus (Hauspost) Bei Ausprägung 2 = Hauspost muss RDNetto korrekt gesetzt werden:RGB:AVIH()(175) |
x | |
| intern_letzte_Stelle_Knz_ID | A1 | RD-Netto:RGB:AILS(93) Standard=’ ' |
x | |
| Modus_Fehlerbearbeitung_Knz_ID | N1 | Steuert den Modus der Fehlerbearbeitung während einer Lagerdifferenz im Abwicklungsprozess. Das Feld muss zwingend gesetzt sein, wenn die Instanz des Logistikpuffers am Lagerdifferenzprozess teilnehmen soll (siehe Spalte Validierung). |
3: = Vollstorno 4: = Online-Rechnungskorrektur 6: = Lieferschein-Erzeugung_SRD |
x |
| Lagerdifferenz_Modus_Id | N1 | Steuert den Modus der Fehlerbearbeitung bei Auftreten einer Lagerdifferenz im Abwicklungsprozess. Das Feld wird in Richtung LVS (Konkret K.Motion in Ilowa) benutzt. Bildet für das LVS den Modus der Bearbeitung der Lagerdifferenz fachlich ab. Dabei werden technische knifflige Details wie “Online-Rechungskorrektur” mit CORE vs. “Lokale Lieferschein-Korrektur” für Deep Sea (fachlich) harmonisiert. -> Wir mappen für Core und DeepSea das Feld “Modus_Fehlerbearbeitung_Knz_Id” auf “Lieferdifferenz_Modus_Id” |
1 = Teilauslieferung 2 = Vollstorno |
x |
| Modus_Verzoegerung_Knz_ID | N1 | Steuert das Verhalten bei Verzögerung (SPUEZ nicht erreichbar): Idee aus NEON. Das WMS möchte vom ERP wissen, was es tun soll, wenn eine Sendung nicht rechtzeitig zum SPÜZ an den Carrier übergeben werden kann. Szenario: Kunde bestellt eine 5 AK Sendungen. 4 der 5 AK können korrekt kommissioniert werden. Das 5. Einzelteil kann am Lagerplatz/ Lagerort nicht aufgefunden werden. Es müsste (in unserem fiktiven Bsp.) aus einem weit entfernten Reserve-Lager nachgeschoben und anschließend nach-kommissioniert werden. Das würde zu einer Verspätung der Sendung führen. Lösungs-Strategien: 1. Wir warten einfach auf die Komplettierung der Sendung und liefern sie verzögert aus. 2. Wir können das Teil, das zur Verzögerung führt, aus der Sendung herausnehmen und den Rest der Sendung pünktlich ausliefern. Im Moment liefert uns kein ERP (weder CORE noch Cormorant) dieses Kennzeichen. Wir (LP) setzen hier ein Default für K.Motion. Sobald uns eines der ERPs uns dieses Kennzeichen übergibt, verwenden wir es natürlich. |
1 = Auslieferung mit Verspätung 2 = Teilstorno des verzögernden Fehlteils und termingerechte Auslieferung |
x |
| Retouren_Sendung_Knz_ID | N1 | Kennzeichen für die Teilnahme der Sendung am Retourenprozess. |
0 = keine Teilnahme am Retourenprozess 1 = Teilnahme am Retourenprozess |
x |
| Abwicklungsweg_Knz_ID | N2 | Früher haben die ERPs die Abwicklungsweg vorgegebenn. Mit der Abruflogik im LP ermitteln ist diese Information obsolet. Aktuell wird noch von L2C der Abwicklungsweg übergeben - nur ignorieren innerhalb des Imports ignoriert. Daher ist das Feld noch ein offizielles SST-Feld. | 2 = Sorter 3 = KLEX (‘Kleine Expedition’) 7 = SOKO (Normal) 8 = KASO |
x |
| BP_NL_Bestellnummer | A17 | Bestellnummer BP-NL | ||
| BP_SRD_PL_Retourenbarcode | N11 | Wird nur benutzt für Märkte der Bonprix Polen Gruppe (Polen, Tschechien, Slowakei, Ungarn, Rumänien, Ukraine). Zitat: Dieser Barcode wird benutzt um während der zukünftigen Retouren Erfassung spezielle Funktionalitäten, die in ROM nicht möglich sind, abzuwickeln. Nach der üblichen Retouren Erfassung in ROM werden diese Informationen zusätzlich in unserem SRD-System erfasst indem der SRD-Barcode gescannt wird und die jeweilige Kundenrechnungs-Nr. identifiziert/gematched wird. Das wird dann unser eigenes SRD-Programm realisieren. |
||
| Brief_Druckrechenzentrum_ID | N2 | 1 = Hamburg 2 = Ordruff (Heine Export) 3 = Graz (AT) |
x | |
| Grosskundensendung_Knz_ID | N1 | 0 = keine Großkunden-Sendung 1 = Großkunden-Sendung |
x | |
| Grosskundennummer | N2 | Die Grosskundennummer kennzeichnet den konkreten Großkunden. | ||
| Frankreich_Dom_Tom_Knz_ID | N1 | Das Feld befindet sich nicht mehr am Versender_FR_Collissimo, da es auch für Briefrechnungen benötigt wird und wir dort keine Versender-Knoten bekommen. |
0 = kein Übersee -> Colissimo profil 1 = ist Übersee-Liefergebiet -> Colissimo direct outre Mer |
|
| Lager_KNZ_ID | N2 | Lager, in welchem die Sendung bearbeitet wird: |
0 = Lager NLW 1 = Löhne 2 = Ohrdruf 3 = Bramfeld 4 = Haldensleben 7 = Tilburg (Holland) 8 = Hanau/Langenselboldt 13 = Witt 14 = Graz/Salzburg 23 = Altenkunstadt Hf 25 = Altenkunstadt Db 40 = Haldensleben Südhafen 43 = Fiktiv für Aor 47 = Sonnefeld 48 = Langenselbold 1MH 54 = Mosina 55 = Ansbach 57 = Marl 58 = Erfurt |
x |
| Bestelldatum | Date | Für HES-Avise | x | |
| KB_Nummer | N2 | Für HES-Avise | x | |
| Abwicklungstyp_Knz_ID | N1 | 1 = Lagerabwicklung 2 = DLW 3 = DDB 4 = VAL 5 = Retoure(Rückholung/Umtausch) 6 = DDB Polen (als Backlog-Ticket) 7 = DOSS (Distributed One Stop Shopping) |
x | |
| NLW_Rechnungsdruck_Knz_ID | N1 | Alle NLW-HES-Sendungen werden in der Schnittstelle übertragen, da Sie an HES zu avisieren sind. Das Kennzeichen dient der Differenzierung, ob für diese Sendungen auch ein Rechnungsdruck im Lager (nur Löhne) erfolgen soll. Bei NLW_Rechnungsdruck_Knz_ID=1 erfolgt der Druck der Rechnungen im Lager Löhne, die Aufteilung auf die verschiedenen Hermes-Richtungen und der Transport in die Depots. Im Deport wird die Rechnung der Ware (VAL,DDB) zugeordnet. |
0 = kein Rechnungsdruck 1 = Rechnungsdruck |
|
| Verbund_Knz_ID | N1 | mehrere Sendungen in ADD-Betrieben (Lager_Knz_ID 1,2,8) gehören zusammen und im Lager wird dafür eine Steuerungsmöglichkeit benötigt Kennzeichenermittlung: Sendung in Lager 1 (Löhne) hat eine Partnersendung in Lager 2 (Ohrdruf) oder 8 (Hanau) aus dem gleichen Kundenauftrag -> VerbundKnzId=1 für Sendung in Lager 1 Sendung in Lager 2 (Ohrdruf) hat eine Partnersendung in Lager 1 (Löhne) oder 8 (Hanau) aus dem gleichen Kundenauftrag -> VerbundKnzId=1 für Sendung in Lager 2 Sendung in Lager 8 (Hanau) hat eine Partnersendung in Lager 1 (Löhne) oder 2 (Ohrdruf) aus dem gleichen Kundenauftrag -> VerbundKnzId=1 für Sendung in Lager 8 |
0 = keine Verbund-Sendung 1 = Verbund-Sendung |
x |
| Buchfuehrende_Einheit | N2 | Für Hermes-Avise ADD (analog DAT9, SA100, W25S3 - ABEP) |
||
| Bank_Kontonummer_Kunde | A35 | Nummer Bankkonto Kunde. Das wird wohl in Polen zu kontrollzwecken immer noch einmal aufgedruckt | ||
| Zahlungsplan_Text | A328 | Enthält den Zahlungsplan-Text bzw. den so geannten Prosa-Zahlungsplan, der links unten auf der Rechnung angedruckt wird. Bisher wurden vom ERP mehrere Steuerungs-Parameter vom ERP übergeben und im Logistikpuffer im Package Zahlungsplan_Tools in einer IF-THEN-ELSE-Wüste der jeweils richtige Zahlungsplan-Text zu-gesteuert. Wenn dieses Feld gefüllt ist, darf es keine Zahlungsplan-Knoten geben. Im Logistikpuffer wird dieser Text “geschnitten” und in 4 Zeilen, je 82 Zeichen an den Rechnungsdruck weiter gegeben. |
||
| Zahlungsziel_Einerate | Date | Enthält das Zahlungsziel für eine Sendung ohne Ratenzahlung. Wird im Fall von keiner (bwz. nur einer) Raten atomar vom Rechnungdruck benötigt. Wir aktuell nur von Bonprix verwendet. |
||
| ??? | A12 | x | ||
| Zoll_Knz_Id | N1 | Angefordert Seitens NEON. In den Bestandsbetrieben gibt es das nicht. Darüber soll im Betrieb gesteuert werden, ob bevorzugt verzollte oder unverzollte Ware für die Sendung verwendet werden soll. Wenn die Sendung nach Deutschland bzw. ins EU-Inland versendet wird: Dann soll präferiert verzolle Ware verwendet werden (ID=0) Das ist auch der Default für Deep Sea. |
0 = präferiert verzollte Ware (wenn nicht verfügbar, unverzollt) 1 = präferiert unverzollte Ware (wenn nicht verfügbar, verzollt) |
x |
| Zoll_Klient_Id | A22 | Enthält die Zoll-Client ID. Das ist der Identifier, mit dem eine Firma beim Zoll registriert ist. Diese geben wir in Ilowa an K.Motion weiter. Dort wird sie benötigt, damit man sie an das Heine Zoll-System weiter-geben kann. Wird in K.Motion benötigt, damit die Info von dort zum Heine Zoll-System übertragen werden kann. |
||
| Haendler_Sendung_Referenz | A36 | Feld für SOI (SalesOrderId) welches in der HES_Avise für L2C DS gebraucht wird. | ||
| Haendler_Erp_Identifier | A30 | Ein Identifier, der aussagt aus welchem System diese Sendung abgegegebn wurde. Mögliche Ausprägungen sind “DEEP_SEA_CORMORANT” und “CORE”. Wir übergeben das Feld an K.Motion, damit K.Motion es in der Warenbewegung an BuBe mitgeben kann. |
x | |
| Druck_Retourenlabel_Knz_ID | N1 | Identifiziert, ob ein Retourenlabel gedruckt werden soll oder nicht. Wird im Rahmen der Einführung des Digitalen Retourenportals (BP) benöigt. | 0 = nicht drucken 1 = drucken |
x |
| Nur_Ganzkollo_Verwenden_Knz | Boolean | Hierüber kann gesteuert werden, dass für eine Sendung ausschließlich Ganz-Kollo verwendet werden sollen. Damit würde NICHT der Standard-Przess für B2C Sendungen gelten: (Nachschub, Picken, in Endkunden-Kartons oder - Tüten verpacken) |
||
| Liefer_Modell | A30 | Liefermodell, welches der Kategorisierung des Abwicklungswegs in der Logistik dient. Anhand des DeliveryModel werden unterschiedliche Prozesse und Services getriggert. | 1 = WAREHOUSE_PARCEL_SHIPMENT - 1MH 2 = WAREHOUSE_FREIGHT - 2MH |
Relations
Last updated: Fri, 25 Apr 2025 01:44:49 UTC