GRK_Sendung

Back to OL1_b2bShipment_(ERP-LP)

Status

DRAFT - under construction

Business Object

This is part of OL1_b2bShipment_(ERP-LP)

Name Type Content Values Mandatory
GRK_ERP_Sendung_ID A50 Eindeutiger gemeinsamer Identifikator der Großkunden-Sendung. Vergeben vom ERP. x
LV_Tag N3 XXX. Arbeitstag des Kalenderjahres
LV_Scheibe N1
spaetester_Uebergabezeitpunkt Date Spätester Übergabe-Zeitpunkt an den Carrier bzw. das HUB. Format: DD.MM.JJJJ HH:MM:SS

Bei Umfuhren wird uns KEIN SPÜZ übergeben. Wir sollen aus dem SPEZ bei einer Umfuhr ein SPÜZ berechnen. Die Rechenregel liegt noch nicht vor. Sie kommt noch von NEON (Christian Heide)		 x
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

Bei Umfuhren soll neben dem SPEZ an einer Umfuhr zusätzlich ein FRÜZ übergeben werden können. Alex Treommer hat bei Team Leviathan nachgefragt:
Laut deren Aussage ist es so, dass für die NEON-Läger beschlossen wurde einen zeitlichen Rahmen für die Erfüllung der Umfuhren mitzugeben. ILOWA würde als ein FRÜZ und ein SPEZ bekommen und wäre selbst dafür verantwortlich die Umfuhren innerhalb dieses Zeitraumes abzuarbeiten.
Prioritaet_Auslieferung N1 Auslieferungs- bzw. Abwicklungs-Priorität. Ausprägungen 1-9.
1=höchste Priorität, 9=niedrigste Priorität		 x
spaetester_Einlagerungszeitpkt Date Das Feld ist nur für Umfuhren relevant. Es sagt aus, wann die Umfuhr spätestens im Ziel-Lager eingelagert sein muss.
Lager_Knz_ID N2 Das Feld ist Redundant. Wir wissen aus der Instanz in welchem Quell-Warehouse wir uns befinden. Wird aber von Ideefix noch geschickt.
Kundenfirma_Knz_ID N2 Kundenfirma
Kontonummer N8 Kontonummer
Auftragsnummer A36 verwendet bei Filial-Belieferung als Filial-Nummer
Für NEON gibt es scheinbar die Anforderung, dass die Auftragsnummer von K.Motion benötigt wird. Sie soll in der Warenbewegung mitgegeben werden.		 x
Grosskundennummer N2 Die Grosskundennummer kennzeichnet den konkreten Großkunden.
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.

Ist hier am b2bShipment neu, wird aber für Replenishment benötigt.
Pflicht, wenn b2bShipmentType = 6 “Replenishment (via STARC)”		 ERP = F2X:
Richtung N3 200-299: Sonderrichtungen
Wird für NEON-Betrieben nicht mitgegeben. Weder für GRK noch für Umfuhr. Wird in NEON wohl im WMS / LVS vergeben.

Für das Mandaten-Geschäft in HDL sollen Mandaten-reine Richtungen vom Logistikpuffer selbst vergeben werden. Für die Sortierung der Sendungen auf Richtungen gilt:
Dem WA-Sorter im Südhafen werden Sendungsidentnummern + die Richtungsnummern avisiert.
Der WA-Sorter kann damit - beim Scan einer Sendungsidentnummer - dennoch anhand der Richtungsnummer (auf verschiedene Tore) sortieren. Die möglicherweise in der Sendungsidentnummer eingebettet Richtung wird nicht berücksichtigt.
In der Hamburger Str. im HAB werden HG-Sendungen ausschließlich über die im Barcode eingebetteten Richtungen sortiert.
GRK_Sendung_Typ_Knz_ID N1 1 = Sendung mit Reservelager
2 = Kommissionierlagersendung
3 = Listenkommissionierung
4 = Umfuhr (in ein anderes Lager)
5 = Großkunde
6 = Replenishment (via STARC)		 x
Auslagerung_Typ_Id N1 Steuert, ob für Großkunden Ganz-Kolli UND Kommissionier-Lager-Sendungen, nur Ganz-Kollo oder nur Kommissionier-Lager-Sendungen verwedendet werden sollen.
Zwingend nötig für b2bShipmentType = 5 = Großkunde		 1 = Ganz LE aus RL und Kommisinier-Lager erlaubt
2 = Nur Kommissionier-Lager-Sendungen zulässig
3 = Nur GANZ LE zuzlässig
4 = Nur Ganz LE mit Überlieferung
Ziel_Lager_Id N2 4 = Haldensleben (Hamburger Str.)
40 = Haldensleben Südhafen
Haendler_Erp_Identifier A30 Ein Identifier, der aussagt aus welchem System diese Sendung abgegegebn wurde. Mögliche Ausprägungen sind “B2B_DEEP_SEA_CORMORANT” und “B2B_CORE”.
Wir übergeben das Feld an K.Motion, damit K.Motion es in der Warenbewegung an BuBe mitgeben kann.
Groesstes_zulaessig_Packmittel A2 Transportiert ggf. das grötße zulässige Packmittel

Geklärt durch J.Röttgermann:
Es gibt KEINEN Bedarf für eine Einschränkung für ein “größtes Zuläassiges Packmittel” an einem B2B-Shipment in NEON.

Das Feld ist deprecated, seit dem wir mit dem Mandaten-Geschäft die Liste der “B2B_Packmittel” neu ergänzt haben.
Lieferscheindatum Date wird beim Bilden der (Endkunden)-Sendungen für das Kommisiionierlager auf Sendung.Rechnungsdatum gemapped

Wollen wir aus Deep Sea nicht mehr haben. LP schreibt da “heute” rein.
BP_Nachschubweg_Kuerzel A3 Kürzel für die unterschiedlichen Nachschubwege Bonprix

Hinzugekommen mit CR_082
Belegnummer N6 PL Bestandsbetriebe Großkunde:
Belegnummer auf dem Grosskundenetikett, welches auf dem Versandkarton seitlich aufgeklebt wird.

PL NEON Umfuhr (WRS & IWA):
Soll in die Warenbewegung (zusätzlich zur b2bOrderId) transportiert werden. Wird gebraucht für Einlagerung im Ziellager.
Umfuhr_Typ A6 (die Otto-Kollegen nennen das Feld aktuell noch “OrderType”, sie beschäftigen sich aktuell aber auch ausschließlich mit Umfuhren)
Muss gesetzt sein, wenn GRK_Sendung_Typ = 4 (Umfuhr)		 UMF = “Bestands-Umfuhr normal”
WRS_WE = “Umfuhr–für-WRS-aus WE”,
WRS_L = “Umfuhr-für-WRS von Lieferant”
IWA_WE = “Umfuhr für IWA aus Wareneingang / Warenprüfung”
IWA_M = “Umfuhr für IWA für Muster”
GKD = Umfuhr für Großkunden-Auftrag
Umfuhr_Cluster_Typ A1 Die NEON-Kollegen nenne das auch “Bedarfsklasse” A = schnell drehender Artikel - direkt ins KS einlagern
B = langsam drehender Artikel - kann ins Reservelager
WE_Position_Id A36 Identifier eine WE-Position in K.Motion - identifiziert einen konkreten WE.

Es sollen Umfuhren für Artikel eines gesamten Wareneingangs möglich sein. Darum soll ein Identifier für einen Wareneingang übergeben werden können.

Identifiziert eine Wareneingangs-Position
ERP_Lieferant_Id A36 technischer Identifier für einen konkreten Lieferanten. Vergeben vom ERP.
Ist in Mola bekannt und wird an LSAS übergeben.
In Mola wird wohl aktuell die LKZ verwendet.

–> steht leider seitens Deep Sea Teams nicht rechtzeitig für den Umfuhr MVP bereit. Darum jetzt nicht dabei. Kommt in einer späteren Ausbaustufe. Darum zunächst als “conceptual” gekennzeichet.
Logistik_Lieferant_Id A36 technischer Identifier für einen konkreten Lieferanten. Von LSAS vergeben. Ist eindeutig im gesamten logistischen Netzwerk..
Ist in Mola bekannt und wird an LSAS übergeben.
Aus der ERP_Lieferant_Id und der ERP_Id können wir den Datensatz im Lieferanten-Stamm ermitteln und damit auch die Logistik_Lieferant_Id.

–> steht Leider seitens Deep Sea Teams nicht rechtzeitig für den Umfuhr MVP bereit. Darum jetzt nicht dabei. Kommt in einer späteren Ausbaustufe. Darum zunächst als “conceptual” gekennzeichet.
LKZ_Nummer N7 LKZ = Lieferanten-Kennziffer. Ist der fachliche Identifier eines Lieferanten.
Soll für den Umfuhr MVP verwendet werden, da die Lösung mit den technischen Identifiern der Lieferanten nicht rechtzeitig bereitsteht.
Ziellokation N9 Lascana betrachtet jeden Partner,  jedes Lager und jede Filiale als Lokation
Filialnummer A20 Filialnummer
Frankatur A5 Regelung zur Übernahme der Transportkosten und des Transportrisikos
Inco_Bedingungen A15 Internationale Handelsklauseln
Lieferart A400 Lieferart (DHL, Palette, DHL Internationale, Palette, Selbstabholer)
Replenishment_Typ A30 Der Replenishment-Typ als named Enum PREVENTIVE = Präventiv (Auftragsbezogen-Präventiv) (ehemals A)
MANUAL = Manuell (Manuell-Präventiv) (ehemals B)
FORECAST = Forecast (Forecast-Prio) (ehemals C)
RETRIEVAL = Abruf (Abruf-Prio) (ehemals D)

Relations

Table
GRK_Adresse
B2B_Artikelattribut_Kopf
B2B_Packmittel
B2B_Artikelattribut_Lokation
GRK_Position
B2B_Avise_Kontakt
Last updated: Sun, 03 Aug 2025 01:45:38 UTC