Nachrichtenhandbuch
AC03 V2.1
Version 1.3
DAKOSY Datenkommunikationssystem AG
Mattentwiete 2
20457 Hamburg
Tel. 040 / 37003 - 0
Fax. 040 / 37007 – 370
Änderungsnachweis:
|
Version |
Betr. Abschnitte |
Grund |
Name |
Datum |
|
0.1 |
Alle |
Erstellung |
S. Buse |
18.11.2015 |
|
1.0 |
Alle |
Review |
K. Zeissig |
26.11.2015 |
|
1.1 |
Alle |
Umzug der XSDs auf xsd.daskoy.de und Aktualisierung der Nachrichtenbeispiele |
S. Buse |
01.06.2018 |
|
1.2 |
2.1 |
· Erweiterung der Werte des Elements <TransportOrder><Usage> um den Wert 'Inland' für Binnenverkehre · Wert '0' zulassen für <GoodsItem><Packaging><NumberUnits> und <GoodsItem><Allocation><NumberItems> (Beipack-Positionen summarische Zollanmeldung> |
S. Buse |
06.02.2020 |
|
1.3 |
2.1 |
·
Attribut 'key' des Elements <Supplement> auf 35
Stellen erweitert · Wert GGED (Gemeinsames Gesundheitseingangsdokument) für Zollregistriernummern ergänzt |
S.Buse |
30.04.2020 |
Änderungsdienst
DAKOSY
Datenkommunikationssystem AG
Mattentwiete 2
20457 Hamburg
- Telefon: + 49 40 37003 – 0
- Fax: + 49 40 37003 – 370
- E-Mail: info@dakosy.de
Verwendete
Werkzeuge
Dieses Dokument wurde mit dem Textverarbeitungsprogramm MS Word 2010 erstellt.
Mitgeltende
Dokumente
Im EDI - Handbuch "Allgemeiner Teil" sind die Grundsätze beschrieben, die für jeden Datenaustausch, der über DAKOSY erfolgt, gültig sind. Die dort niedergelegten Definitionen, die beschriebenen Mitwirkungspflichten des Kunden sowie die Grundlagen des Kommunikationsablaufes gelten auch für die im vorliegenden Handbuch beschriebene Schnittstelle.
1. Vorbemerkung
Die Transaktion AC03 v2.1 stellt eine Weiterentwicklung, bzw. Konsolidierung der Version 2.0 der Transaktion dar. Der primäre Fokus liegt dabei auf der verbesserten Unterstützung von Transporten mit den Verkehrsträgern Binnenschiff und Truck. Dies bezieht sich neben dem eigentlichen Transport, auch auf die Beauftragung der Be- und Entladung. AC03 v2.1 ist damit in der Lage in Bezug auf die EDI-Kommunikation die Anforderungen aus dem Projekt Business to Motorways of the Seas (B2MoS)[i] abzudecken.
Die aktuelle Version der Transaktion umfasst auch Erweiterungen für multimodale Transporte und für den Verkehrsträger Bahn.
Gegenüber der Version 2.0 enthält die Version 2.1 zusätzliche Datenelemente und lockert Restriktionen bestimmter bereits vorhandener Datenelemente oder Strukturen. Sie ist damit vollständig abwärts kompatibel, d.h. alle AC03 v2.0 Nachrichten können gegen die XSDs der Version 2.1 validiert werden.
In den folgenden Kapiteln werden die verschiedenen Nachrichtenelemente einzeln dargestellt. Eine Dokumentation der Änderungen von Version 2.0 zu Version 2.1 der Transaktion finden Sie in Kapitel 4.4 Änderungen AC03 v2.0 / AC03 v2.1.
2. Nachrichtenelemente
2.1. Vormeldung / Transportauftrag / Verlade-Ist / Ver- oder Entladeauftrag
Vormeldungen, Transportaufträge und Verlade-Ist Meldungen werden bei der Kommunikation strukturell gleichbehandelt. Sie unterscheiden sich in der praktischen Verwendung in ihrer Bedeutung und im Umfang der jeweils kommunizierten Daten. Der konkrete Typ der Nachricht wird über das Attribut 'type' im XML-Element 'TransportOrder' festgelegt. Aktuell sind dies die Typen:
TH = Transportauftrag
RH = Verlade-Ist
NH = Buchungsanfrage
LO = Verladeauftrag
DO = Entladeauftrag
Zusammen mit der Spezifikation des Verkehrsträgers (Element 'ModeOfTransport') für den Hauptlauf können multimodale oder Verkehrsträger spezifische Transportaufträge, Verlade- oder Entladeaufträge, etc. mit Hilfe von AC03 kommuniziert werden. AC03 unterstützt in der Version 2.1 die folgenden Verkehrsträger:
Rail = Bahn
Feeder = Schiff
Truck = LKW
Barge = Binnenschiff / Leichter
Die nachfolgende Grafik stellt die Struktur der Vormeldung,
Transportauftrags und Verlade-Ist Meldung dar und ist mit einer
detaillierten Beschreibung der einzelnen Nachrichtenelemente verlinkt:
Die Nachrichtenelemente Transport Order, Address Data, Transport Container und Dangerous Goods beschreiben respektive die inhaltlichen Elemente des Auftragskopfs, der Adressdaten, des Containers und der Gefahrgutinformationen.
Die Nachrichtenelemente Goods Item und Goods Item Allocation ermöglichen die Kommunikation von Warenpositionen und deren Zuordnung zu Containern.
Die Zolldaten werden mit Hilfe des Nachrichtenelements Customs übermittelt. Für die Kommunikation mit ZODIAK (ATLAS Anmeldung) benötigte zusätzliche Datenelemente werden in dem dedizierten Nachrichtenelement Customs Information ZODIAK kommuniziert.
2.1.1. XSD-Schema und Beispiele
Beispiel Nachrichten
· Transportauftrag Bahn – multimodaler Transportauftrag mit Vor- und Nachlauf, Hauptlauf per Bahn, Container mit Gefahrgut und einer Warenposition
· Transportauftrag Truck – 'einfacher' Transportauftrag ohne Zwischenstopps mit einem Container
· Verladeauftrag Binnenschiff – Verladeauftrag an den Kaibetrieb für die Verladung von drei Containern auf zwei verschiedene Leichter
2.2. Statusmeldungen
Die Statusmeldungen dienen zur Kommunikation verschiedener Inhalte. Mit ihnen werden Statusinformationen (im engeren Sinne), Fehlermeldungen oder Rückweisungen, Buchungsbestätigungen und Löschungen übermittelt.
Die nachfolgende Grafik stellt die Struktur der Statusmeldungen dar und ist mit einer detaillierten Beschreibung der einzelnen Nachrichtenelemente verlinkt:
2.2.1. XSD-Schema und Beispiele
Beispiel Nachrichten
· Statusinformation – Statusinformation auf Auftragsebene zu einem Transportauftrag per Bahn
· Statusinformation – Statusinformation auf Containerebene mit Status 'Verladen' zu einem Verladeauftrag für einen Transport per Binnenschiff
· Rückweisung – Rückweisung eines Transportauftrags
· Löschung – Löschung eines Transportauftrags
· Buchungsbestätigung – Buchungsbestätigung eines Transportauftrags
2.2.2. Codes Nachrichtenelement StatusInformation
Die verschiedenen Codelisten unterliegen einer kontinuierlichen Weiterentwicklung aufgrund der Anforderungen des operativen Betriebs. Für aktuelle Listen der in den Statusmeldungen verwendeten Codes wenden Sie sich bitte an DAKOSY.
Element ReferenceQualifier
Die folgende Tabelle stellt einen Auszug der Wertemenge für das Element ReferenceQualifier dar:
|
ReferenceQualifier |
|
|
Code |
Bedeutung |
|
HABISTANR |
TPR Referenz (=HABIS TA-Nummer) |
|
REFTOCOMP |
Referenz des Auftrags beim Dienstleister / EVU |
|
HANUMBER |
HABIS Zoll HA-Nummer |
|
ATLASNUMBER |
ATLAS Registriernummer |
|
TRAIN |
Zugnummer |
|
TRUCK |
LKW-Kennzeichen |
|
REFTOCONS |
Auftragsreferenz des Auftraggebers (Kundenreferenz) |
Element StatusQualifier
Die Tabelle stellt einen Auszug der abgestimmten Inhalte für das Element StatusQualifier dar:
|
StatusQualifier |
|
|
Code |
Bedeutung |
|
Dienstleister |
Statuswert bezieht sich auf den Status des Auftrags beim Dienstleister |
|
Transport |
Statuswert bezieht auf den Status des Auftrags / der Ladeeinheit entlang der Transportstrecke, bzw. in Bezug zum Transport |
|
Customs |
Statuswert bezieht sich auf die Zollabwicklung |
Element StatusTimeQualifier
Folgende Werte können im Element StatusTimeQualifier verwendet werden:
|
StatusTimeQualifier |
|
|
Code |
Bedeutung |
|
OCCURRANCE |
Zeitpunkt zu dem der Status, bzw. das dem Status zugrunde liegenden Ereignis eingetreten ist |
|
REPORTING |
Zeitpunkt zu dem der Status, bzw. das dem Status zugrunde liegenden Ereignis gemeldet worden ist |
|
TARGET |
Zeitpunkt zu dem der Status, bzw. das dem Status zugrunde liegenden Ereignis eintreten sollte |
Element StatusCode
Die Tabelle stellt einen Auszug der abgestimmten Statuscodes dar:
|
StatusCode |
||
|
StatusQualifier |
Code |
Bedeutung |
|
Dienstleister |
15000 |
Auftrag erhalten |
|
Dienstleister |
20000 |
Auftrag neg. geprüft |
|
Dienstleister |
30000 |
Auftrag pos. geprüft |
|
Dienstleister |
32000 |
Auftrag bearbeitet |
|
Dienstleister |
80000 |
Auftrag abgeschlossen |
|
Dienstleister |
90000 |
Auftrag storniert |
|
Transport |
15000 |
Bereit |
|
Transport |
16000 |
Dispo-Soll |
|
Transport |
19000 |
Disponiert |
|
Transport |
30000 |
Depot Ausgang |
|
Transport |
32000 |
Beginn Laden Versand /
Abholung begonnen |
|
Transport |
32500 |
Laden Versand / Abholung
bei Abholadresse |
|
Transport |
32900 |
Ende Laden Versand
/Abholung abgeschlossen |
|
Transport |
33000 |
Übernahme aus AGL |
|
Transport |
39000 |
Verladen |
|
Transport |
40000 |
Schienenausgang / Zug
abgefahren |
|
Transport |
45000 |
Transport |
|
Transport |
49000 |
Schieneneingang / Zug
angekommen |
|
Transport |
50000 |
Entladen |
|
Transport |
52000 |
Beginn Ausladen Empfang /
Zustellung begonnen |
|
Transport |
52500 |
Ausladen Empfang /
Zustellung bei Zustelladresse |
|
Transport |
52900 |
Ende Ausladen Empfang /
Zustellung abgeschlossen |
|
Transport |
53000 |
Übergabe an AGL |
|
Transport |
80000 |
Transportende |
2.3. Fakturadaten
Die nachfolgende Grafik stellt die Struktur der Fakturadaten dar und ist mit einer detaillierten Beschreibung der einzelnen Nachrichtenelemente verlinkt:
2.3.1. XSD-Schema und Beispiele
Beispiel Nachricht
· Fakturadaten – Invoice-Nachricht mit mehreren Rechnungspositionen, Mengenangaben und Angaben zur Transportrelation
2.4. Quittung
Jede kommunizierte Nachricht – außer der Quittung selber - wird quittiert. Dies geschieht mit Hilfe einer technischen Quittung.
Die nachfolgende Grafik stellt die Struktur der Quittung dar und ist mit einer detaillierten Beschreibung der einzelnen Nachrichtenelemente verlinkt:
Entscheidend für die Bedeutung der Quittung ist das Attribut ‚type‘ des Elements ‚Response‘:
|
Type |
Bedeutung |
|
Response |
Wird zur positiven Quittierung einer Nachricht verwendet – ein erläuternder Text ist nicht notwendig |
|
Error |
Negative Quittung / Fehler beim Parsen der Nachricht – der Fehlertext kann im Element 'Free Text' übermittelt werden |
Bei einer positiven Quittung wird im Element ‚Code‘ der Wert ‚00000‘ erwartet. Bei negativen Quittungen kann ein entsprechender Fehlercode kommuniziert werden.
2.4.1. XSD-Schema und Beispiele
Beispiel Nachricht
2.5. Zugmeldung
Die nachfolgende Grafik stellt die Struktur der Zugmeldung dar und ist mit einer detaillierten Beschreibung der einzelnen Nachrichtenelemente verlinkt:
2.5.1. XSD-Schema und Beispiele
Beispiel Nachrichten
· Ausgangszugreihung – Zugreihung bei Abfahrt aus dem Versandbahnhof
2.6. Allgemeine Element Definitionen / eingebundene XSDs
Die verschiedenen AC03 Nachrichtenelemente nutzen für gemeinsam verwendete Elemente zentrale Definitionen (Core Datentypen) und eine einheitliche Definition für die Elemente zur Adressierung der Nachrichten (Message Envelope) in Form von eingebundenen XSDs.
3. Fachlicher Nachrichtenaustausch
Die hier dargestellten Szenarien stellen beispielhaft den Nachrichtenaustausch aus fachlicher Sicht dar. Die technischen Aspekte des Nachrichtenaustauschs werden in Kapitel 4 Technischer Nachrichtenaustausch erörtert.
3.1. Allgemeine Szenarien
Auftragserteilung mit
Änderung
- Übermittlung des Auftrags (in der fachlichen Version 1)
- Annahme des Auftrags
- Änderung des Auftrags durch den Auftraggeber (fachliche Version > 1, bei mehreren Änderungen Version aufsteigend)
- Rückmeldung von Statusinformationen und der Verlade-Ist Meldung
Auftragserteilung mit
Stornierung
- Übermittlung des Auftrags
- Annahme des Auftrags durch den Auftragnehmer
- Stornierung des Auftrags durch den Auftraggeber und anschließende Löschung des Auftrags durch den Auftragnehmer
Auftragserteilung mit
Fakturierung
- Übermittlung des Auftrags
- Annahme des Auftrags durch den Auftragnehmer
- Rückmeldung von Statusinformationen und der Verlade-Ist Meldung
- Rückmeldung von Fakturadaten an den Auftraggeber
3.2. DAKOSY spezifische Szenarien
Auftragserteilung mit
ZODIAK GE
- Szenario für Aufträge mit ATLAS-Anmeldung
- Übermittlung einer Transport Order (Auftrag) mit Nachrichtenelementen Goods Item und Customs Information ZODIAK
- Weiterleitung der Daten an ZODIAK GE und nach entsprechender Verarbeitung an ATLAS
- Rückmeldung von Statusinformationen aus ATLAS und ZODIAK GE (z.B. Zollregistriernummern)
- Weitere Verarbeitung des Auftrags (mit ergänzten Zolldaten) in UNIKAT GE
Auftragserteilung (Ver-/Entladeauftrag) mit TransPORT
Rail (TPR)
- Szenario für Bahnauftrage ab/nach Hamburg
- Übermittlung einer Transport Order (Auftrag) mit Hamburger Versand- oder Bestimmungsbahnhof
- Kommunikation eines Ver- / Entladeauftrags an TransPORT Rail (Transaktion TD04 Transportorder)
Auftraggeber
Ver- / Entladeauftrag Binnenschiff
- Szenario für den Austausch von Informationen zur Be- und Entladung von Binnenschiffen mit dem betroffenen Kaibetrieb
- Übermittlung der Transport Order (Auftrag) mit 'ModeOfTransport = Barge' und 'type = LO' für eine Beladung und 'type = DO' für eine Entladung
- Kommunikation des entsprechenden Ver- oder Entladeauftrags an den Kaibetrieb (z.B. per EDIFACT Nachrichten COPRAR und COARRI)
4. Technischer Nachrichtenaustausch
4.1. Nachrichtenversionen
Die
Version der verwendeten Nachrichtenelemente wird über das Attribut 'version' des Elements 'Transaktion' in jeder Nachricht
festgelegt. Für alle in diesem Dokument beschriebenen Nachrichtenelemente ist
dies die Version '2.1'. Zum Beispiel für eine Quittungsnachricht sieht das
Element 'Transaktion' wie folgt aus:
<Transaction code="AC03"
type="Response" version="2.1">
Aus technischer Sicht gibt es keinen Zwang nur Nachrichtenelemente einer Version zu kommunizieren. Es ist zum Beispiel möglich auf eine TransportOrder der Nachrichtenversion '02' mit einer Quittung oder Statusmeldung der Version '2.1' zu antworten (oder umgekehrt). In der Praxis sollte jedoch ein einheitliches Nachrichtenszenario verwendet werden.
Die verwendete Version der einzelnen Nachrichtenelemente wird bilateral zwischen den Kommunikationspartnern vereinbart.
4.2. Quittierung
Die Quittungsmeldung wird als Antwort auf jede Nachricht gesendet. Quittungsmeldungen selber werden nicht quittiert.
Die Quittungsmeldung erfüllt folgende Aufgaben:
- Bestätigung der korrekten Verarbeitung bzw. Ablehnung aufgrund einer fehlerhaften Syntax (Prüfung gegen XML-Schema)
- Erkennung von Nachrichtenverlust / -doppelung zusätzlich zur Sicherung auf der technischen Ebene.
Normalfall
- Nachricht
syntaktisch korrekt.
- Der
Absender erhält für jede Nachricht eine Quittungsmeldung mit dem Wert
'Response' im Attribut 'type' des Elements Response und dem 'Code 00000'.
Verlorene Nachricht
- der Absender erhält keine Quittungsmeldung
- erneute Übermittlung der Nachricht
(kann mit gleicher Nachrichtenreferenz erfolgen).
- Hierfür sind beim Absender
entsprechende Timeout und Retry-Verfahren zu
implementieren.
Verlorene Quittung
- Der Absender erhält keine Quittungsmeldung – die Nachricht muss erneut gesendet werden.
- Der Empfänger ignoriert die doppelte Nachricht (Voraussetzung: gleiche Nachrichtenreferenz) und sendet erneut eine Quittungsmeldung mit der Information 'Nachricht doppelt empfangen'.
Syntaktisch oder
inhaltlich fehlerhafte Nachricht
- die Nachricht lässt sich nicht gegen das Nachrichtenschema validieren
- die Nachricht enthält inhaltliche Fehler
- Übermittlung der korrigierten Nachricht mit einer neuen Nachrichtenreferenz und gleicher fachlicher Version.
4.3. Protokolle
Bevorzugtes Protokoll für den Austausch von AC03 XML-Nachrichten ist FTP / SFTP. Das konkrete Verfahren ist jeweils zwischen den Kommunikationspartnern bilateral abzustimmen.
4.4. Änderungen AC03 v2.0 / AC03 v2.1
Alle mit AC03 v2.1 vorgenommenen Änderungen sind abwärtskompatibel zu Version 2.0 der Transaktion. Alle Änderungen an bestehenden Datenelementen wandeln entweder Pflichtelemente in optionale Teile der Nachricht um oder erweitern den Datentyp – verlängern zum Beispiel einen auf 4 Bytes beschränkten Code auf 10 Bytes.
4.4.1.
TransportOrder
Die folgende Tabelle enthält eine detaillierte Auflistung der Änderungen, die das Nachrichtenelement TransportOrder betreffen.
|
XML-Element |
geändertes Element |
neues Element |
Beschreibung |
|
<Document> |
x |
|
Erweiterung der Auftragstypen für das Attribut 'type' um die Werte · LO = Verladeauftrag · DO = Entladeauftrag Die beiden neuen Auftragstypen sind primär für die Kommunikation von Ver- und Entladeaufträgen für den Verkehrsträger Binnenschiff eingeführt worden. Sie können aber natürlich auch in Kombination mit anderen Verkehrsträgern verwendet werden. |
|
<Document> |
x |
|
Erweiterung um den Wert 'Barge' für Transporte per Binnenschiff / Leichter |
|
<Document> |
x |
|
Struktur ist jetzt optional; Bei multimodalen Aufträgen (Bahn) ist die Nutzung der Struktur Dispatch (und der Struktur Discharge) fachlich verpflichtend, um den Versandbahnhof (Empfangsbahnhof) zu spezifizieren. Bei Verladeaufträgen ist die Nutzung der Struktur Dispatch zur Kommunikation des Verladeterminals (Element Location) fachlich verpflichtend. |
|
<Document> <Location> <Code> |
x |
|
Ergänzung des Werts 'SMDG' für das Attribut 'type' des Ladestellencodes. Die SMDG-Ladestellencodes sind primär für die Verwendung im Zusammenhang mit Transporten per Binnenschiff / Leichter gedacht. Verlängerung der Feldlänge für den Code auf 10 Bytes. |
|
<Document> |
x |
|
Struktur ist jetzt optional; Bei multimodalen Aufträgen (Bahn) ist die Nutzung der Struktur Discharge (und der Struktur Dispatch) fachlich verpflichtend, um den Empfangsbahnhof (Versandbahnhof) zu spezifizieren. Bei Entladeaufträgen ist die Nutzung der Struktur Discharge zur Kommunikation des Entladeterminals (Element Location) fachlich verpflichtend. |
|
<Document> <Location> <Code> |
x |
|
Ergänzung des Werts 'SMDG' für das Attribut 'type' des Ladestellencodes. Die SMDG-Ladestellencodes sind primär für die Verwendung im Zusammenhang mit Transporten per Binnenschiff / Leichter gedacht. Verlängerung der Feldlänge für den Code auf 10 Bytes. |
|
<Document> <Voyage> |
|
x |
Das Datenelement beinhaltet die Reisenummer (z.B. bei Transporten per Binnenschiff) |
|
<Document> <CallSign> |
|
x |
Das Datenelement beinhaltet das Callsign (z.B. bei Transporten per Binnenschiff) |
|
<Document> <ShipNumber> |
|
x |
Das Datenelement beinhaltet die Schiffsnummer (z.B. bei Transporten per Binnenschiff) |
|
<Document> <CarrierCode> |
|
x |
Code des Reeders |
|
<Document> <CarrierName> |
|
x |
Name des Reeders |
|
<Document> |
x |
|
Ergänzung des Adressrolle 'AssociateTransportCompany' (=Beteiligte Niederlassung bei Leistungserbringung) für das Attribut 'role' des Datenelements |
|
<Document> <Code> |
x |
|
Verlängerung der Feldlänge für den Code auf 10 Bytes. |
|
<Document> <FurtherReferenceSigns> |
|
x |
Zusätzliche (flexible) Struktur zur Kommunikation von Kundenummern, Kontraktnummern, etc. |
|
<Document> <Damage> |
|
x |
Struktur zur Kommunikation von Beschädigungen am Container |
|
<Document> |
x |
|
Das Datenelement ist jetzt optional |
|
<Document> |
x |
|
Das Datenelement ist jetzt optional |
|
<Document> |
|
x |
Name des Reeders |
|
<Document> |
|
x |
Neues Datenelement zur Kennzeichnung eines Reefers, der als konventioneller Container verwendet wird, d.h. es findet, keine Temperaturregelung statt, bzw. muss keine Temperaturregelung stattfinden. |
|
<Document> |
|
x |
Neues Datenelement zur Kommunikation der Anzahl der in der Zolldeklaration enthaltenen Packstücke |
|
<Document> |
|
x |
Neues Datenelement zur Kommunikation der Position des Bahnwagens in der Reihung. |
|
<Document> <Group> |
x |
|
Das Datenelement ist jetzt optional |
|
<Document> |
|
x |
Neue Datenstruktur zur Identifikation des Binnenschiffs / Leichters, auf dem der Container transportiert wird und der Ladeposition des Containers. |
|
<Document> |
|
x |
Neue Datenstruktur zur Identifikation des LKWs oder Chassis, auf dem der Container transportiert wird und der Ladeposition des Containers. |
|
<Document> |
|
x |
Neue Datenstruktur zur Identifikation der Verwendung auf Containerebene. Mögliche Werte sind: · Import · Export · Relocation · DepotIn · DepotOut Das Datenelement wird primär im Zusammenhang mit der Abstimmung von Abholungen oder Anlieferungen per LKW bei einen Terminal / Depot verwendet. |
|
<Document> |
|
x |
Neues Element zur Kommunikation der Referenz der Kopiervorlage / Vorblendereferenz, die beim Empfang des Auftrags zur Vervollständigung der Daten verwendet werden soll. |
4.4.2. Statusmeldung
Die folgende Tabelle enthält eine detaillierte Auflistung der Änderungen, die das Nachrichtenelement StatusInformation betreffen.
|
XML-Element |
geändertes Element |
neues Element |
Beschreibung |
|
<Document> |
x |
|
Verlängerung der Feldlänge für den Code auf 10 Bytes. |
|
<Document> <Supplement> |
|
x |
Generisches Datenelement zur Kommunikation zusätzlicher Informationen in der Statusinformation. |
|
<Document>
<Container> |
|
x |
Neues Datenelement zur Kommunikation des Container-ISO-Codes mit einer Statusinformation. |
|
<Document> <Container> |
|
x |
Neues Datenelement zur Kommunikation der Ladeposition des Containers auf einem Bahnwagen. |
|
<Document> <Container> |
|
x |
Neues Datenelement zur Kommunikation der Position des Bahnwagens in der Reihung mit einer Statusmeldung. |
|
<Document> <Container> |
x |
|
Verlängerung der Feldlänge für den Code auf 10 Bytes. |
|
<Document> <Container> |
|
x |
Struktur zur Kommunikation von Beschädigungen am Container im Rahmen einer Statusmeldung. |
|
<Document> <Container> |
|
x |
Neue Datenstruktur zur Identifikation des Binnenschiffs / Leichters, auf dem der Container transportiert wird und der Ladeposition des Containers. |
|
<Document> <Container> |
|
x |
Neue Datenstruktur zur Identifikation des LKWs oder Chassis, auf dem der Container transportiert wird und der Ladeposition des Containers. |
|
<Document> <Container> |
|
x |
Generisches Datenelement zur Kommunikation zusätzlicher Informationen auf Containerebene in der Statusinformation. |
4.4.3. Fakturadaten
Die folgende Tabelle enthält eine detaillierte Auflistung der Änderungen, die das Nachrichtenelement InvoiceData betreffen.
|
XML-Element |
geändertes Element |
neues Element |
Beschreibung |
|
<Document> |
x |
|
Ergänzung des Adressrolle 'AssociateTransportCompany' (=Beteiligte Niederlassung bei Leistungserbringung) für das Attribut 'role' des Datenelements. Aufhebung der Begrenzung auf maximal 3 Adressen. Die Anzahl der Adressen ist jetzt unbegrenzt. |
|
<Document> <Code> |
x |
|
Verlängerung der Feldlänge für den Code auf 10 Bytes. |
|
<Document> |
|
x |
Neues
Datenelement Zahlungsziel |
|
<Document> |
|
x |
Neues
Datenelement AGB |
|
<Document> |
|
x |
Neues
Datenelement Stundungsverfahren |
|
<Document> |
|
x |
Neues
Datenelement Lastschriftverfahren Kto. |
|
<Document> |
|
x |
Neues
Datenelement Entgeltminderung |
|
Document> <Identification> <Reference> |
x |
|
Aufhebung der Begrenzung auf eine Referenz. Die Anzahl der Referenzen ist jetzt unbegrenzt. |
|
Document> <LineItem> <TaxDescription> |
|
x |
Neues Datenelement für Erläuterungen zum Steuersatz |
|
Document> <LineItem> <Quantity> |
|
x |
Neue Struktur zur Kommunikation von Mengenangaben in Bezug zu Teilleistungen. |
|
Document> <Transport> |
|
x |
Neue Struktur zur Angabe der Transportrelation incl. Abhol-, Zustelladressen und Transportdatum |
4.4.4. Quittung
Die Quittung ist gegenüber AC03 v2.0 unverändert in die aktuelle Version der Transaktion übernommen worden. Um einen vollständigen und einheitlichen Nachrichtensatz im AC03 v2.1 zu haben, hat die Quittung ebenfalls die Version 2.1 bekommen.