Nachrichtenhandbuch

AC03 V2.1

 

Version 1.1

 

 

 

DAKOSY-Logo_ohneUnterzeile_140x21

 

 

 

 

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

 

 

Änderungsdienst

 

DAKOSY

Datenkommunikationssystem AG

Mattentwiete 2

20457 Hamburg

 

 

 

 

 

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 gleich behandelt. 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 Information 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

·         TransportOrder.xsd

·         AC03CoreDataTypes.xsd

·         MessageEnvelope.xsd

 

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

 

·         StatusInformation.xsd

·         AC03CoreDataTypes.xsd

·         MessageEnvelope.xsd

 

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

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 den 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

19000

Disponiert

Transport

30000

Depot Ausgang

Transport

32000

Beginn Laden Versand

Transport

32500

Laden Versand

Transport

32900

Ende Laden Versand

Transport

33000

Übernahme aus AGL

Transport

39000

Verladen

Transport

40000

Schienenausgang

Transport

45000

Transport

Transport

49000

Schieneneingang

Transport

50000

Entladen

Transport

52000

Beginn Ausladen Empfang

Transport

52500

Ausladen Empfang

Transport

52900

Ende Ausladen Empfang

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

 

·         Invoice.xsd

·         AC03CoreDataTypes.xsd

·         MessageEnvelope.xsd

 

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

 

·         Response.xsd

·         AC03CoreDataTypes.xsd

·         MessageEnvelope.xsd

 

Beispiel Nachricht

·         positive Quittung

·         negative Quittung

 

2.5.     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

Auftragserteilung mit Stornierung

Auftragserteilung mit Fakturierung

 

3.2.     DAKOSY spezifische Szenarien

Auftragserteilung mit ZODIAK GE

Auftragserteilung (Ver-/Entladeauftrag) mit TransPORT Rail (TPR)

Auftraggeber

Ver- / Entladeauftrag Binnenschiff

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:

 

Normalfall

Beispiel positive Quittung

 

Verlorene Nachricht

Verlorene Quittung

 

Syntaktisch oder inhaltlich fehlerhafte Nachricht

 

Beispiel negative Quittung

 

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>
  <Messages>
    <Message>
       <TransportOrder>

 

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>
  <Messages>
    <Message>
      <TransportOrder>
        <ModeOfTransport>

x

 

Erweiterung um den Wert 'Barge' für Transporte per Binnenschiff / Leichter

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <Dispatch>

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>
  <Messages>
    <Message>
      <TransportOrder>
        <Dispatch>

         <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>
  <Messages>
    <Message>
      <TransportOrder>
        <Discharge>

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>
  <Messages>
    <Message>
      <TransportOrder>
        < Discharge >

         <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>
  <Messages>
    <Message>
      <TransportOrder>
        <FeederShip>

         <Voyage>

 

x

Das Datenelement beinhaltet die Reisenummer (z.B. bei Transporten per Binnenschiff)

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <FeederShip>

         <CallSign>

 

x

Das Datenelement beinhaltet das Callsign (z.B. bei Transporten per Binnenschiff)

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <FeederShip>

         <ShipNumber>

 

x

Das Datenelement beinhaltet die Schiffsnummer (z.B. bei Transporten per Binnenschiff)

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <FeederShip>

         <CarrierCode>

 

x

Code des Reeders

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <FeederShip>

         <CarrierName>

 

x

Name des Reeders

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <AddressData>

x

 

Ergänzung des Adressrolle 'AssociateTransportCompany' (=Beteiligte Niederlassung bei Leistungserbringung) für das Attribut 'role' des Datenelements

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <AddressData>

         <Code>

x

 

Verlängerung der Feldlänge für den Code auf 10 Bytes.

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <CustomerNumber>

         <FurtherReferenceSigns>

 

x

Zusätzliche (flexible) Struktur zur Kommunikation von Kundenummern, Kontraktnummern, etc.

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <Container>

            <Damage>

 

x

Struktur zur Kommunikation von Beschädigungen am Container

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <OceanVoyage>
            <Port>

x

 

Das Datenelement ist jetzt optional

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <OceanVoyage>
            <CarrierCode>

x

 

Das Datenelement ist jetzt optional

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <OceanVoyage>
            <CarrierName>

 

x

Name des Reeders

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <Temperature>
            <NonOperatingReefer>

 

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>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <Customs>
            <NumberOfPackages>

 

x

Neues Datenelement zur Kommunikation der Anzahl der in der Zolldeklaration enthaltenen Packstücke

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <WagonTrainPostion>

 

x

Neues Datenelement zur Kommunikation der Position des Bahnwagens in der Reihung.

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <DangerousGoods>
            <Packaging>

              <Group>

x

 

Das Datenelement ist jetzt optional

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <LoadingBarge>

 

x

Neue Datenstruktur zur Identifikation des Binnenschiffs / Leichters, auf dem der Container transportiert wird und der Ladeposition des Containers.

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <LoadingTruck>

 

x

Neue Datenstruktur zur Identifikation des LKWs oder Chassis, auf dem der Container transportiert wird und der Ladeposition des Containers.

<Document>
  <Messages>
    <Message>
      <TransportOrder>
        <TransportContainer>
          <Usage>

 

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>
  <Messages>
    <Message>
      <TransportOrder>
        <TemplateReference>

 

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>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>
          <LocationCode>

x

 

Verlängerung der Feldlänge für den Code auf 10 Bytes.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Supplement>

 

x

Generisches Datenelement zur Kommunikation zusätzlicher Informationen in der Statusinformation.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <ISOCode>

 

x

Neues Datenelement zur Kommunikation des Container-ISO-Codes mit einer Statusinformation.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <WagonLoadingPosition>

 

x

Neues Datenelement zur Kommunikation der Ladeposition des Containers auf einem Bahnwagen.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <WagonTrainPosition>

 

x

Neues Datenelement zur Kommunikation der Position des Bahnwagens in der Reihung mit einer Statusmeldung.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <OceanCarrier>

x

 

Verlängerung der Feldlänge für den Code auf 10 Bytes.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <Damage>

 

x

Struktur zur Kommunikation von Beschädigungen am Container im Rahmen einer Statusmeldung.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <
LoadingBarge>

 

x

Neue Datenstruktur zur Identifikation des Binnenschiffs / Leichters, auf dem der Container transportiert wird und der Ladeposition des Containers.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <
LoadingTruck>

 

x

Neue Datenstruktur zur Identifikation des LKWs oder Chassis, auf dem der Container transportiert wird und der Ladeposition des Containers.

<Document>
  <Messages>
    <Message>
      <Status>
        <StatusInformation>

          <Container>
            <
Supplement>

 

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>
  <Messages>
    <Message>
      <Invoice>
        <AddressData>

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>
  <Messages>
    <Message>
      <Invoice>
        <Addressdata>

          <Code>

x

 

Verlängerung der Feldlänge für den Code auf 10 Bytes.

<Document>
  <Messages>
    <Message>
      <Invoice>
        <PaymentTarget>

 

x

Neues Datenelement Zahlungsziel

<Document>
  <Messages>
    <Message>
      <Invoice>
        <TermsAndConditions>

 

x

Neues Datenelement AGB

<Document>
  <Messages>
    <Message>
      <Invoice>
        <ExtensionForPayment>

 

x

Neues Datenelement Stundungsverfahren

<Document>
  <Messages>
    <Message>
      <Invoice>
        <DirectDebit>

 

x

Neues Datenelement Lastschriftverfahren Kto.

<Document>
  <Messages>
    <Message>
      <Invoice>
        <DiscountConditions>

 

x

Neues Datenelement Entgeltminderung

Document>
  <Messages>
    <Message>
      <Invoice>
        <Item>

          <Identification>

            <Reference>

x

 

Aufhebung der Begrenzung auf eine Referenz. Die Anzahl der Referenzen ist jetzt unbegrenzt.

Document>
  <Messages>
    <Message>
      <Invoice>
        <Item>

          <LineItem>

            <TaxDescription>

 

x

Neues Datenelement für Erläuterungen zum Steuersatz

Document>
  <Messages>
    <Message>
      <Invoice>
        <Item>

          <LineItem>

            <Quantity>

 

x

Neue Struktur zur Kommunikation von Mengenangaben in Bezug zu Teilleistungen.

Document>
  <Messages>
    <Message>
      <Invoice>
        <Item>

          <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.

 



[i] Business to Motorways of the Seas (B2MoS), Teilprojekt Status Initiative 12, gefördert von der Europäischen Union / Transeuropäisches Verkehrsnetz (TEN-V)