(who can help translating?) Die PapierrechnungWir wollen hier versuchen, eine alltägliche Papierrechnung im EDIFACT-Format abzubilden.
Fahrradhandel Pedal, Wagingerstr. 5, 81549 München
Huber GmbH
Obstgasse 2
81549 München
München, 02.08.99
Rechnung: 9908001 Ihre Bestellung Nr. O0010001 vom 15.07.99
Pos Artikel Beschreibung Anzahl Einzelpreis Gesamt
1 4711.001 Fahrrad, Damen- 1 750,00 750,00
2 4711.002 Luftpumpe, Stand- 1 19,90 19,90
3 4711.003 Ersatzventil 3 2,50 7,50
------------
Gesamtsumme netto 777,40
Umsatzsteuer 16% 124,38
========
zu zahlender Betrag 901,78
Alle Beträge verstehen sich in DEM
StoffsammlungWelche Daten befinden sich auf dem Rechnungsformular, die mittels EDIFACT übertragen werden sollen bzw. müssen? Diese Stoffsammlung hilft, die entsprechenden Daten dann in die EDIFACT-Segmente zu füllen.
*) So haben die beiden das ausgemacht. EDIFACT RahmenbedingungenHier stellen wir kurz die EDIFACT bezogenen Rahmenbedinungen fest:
Umsetzen in EDIFACTZum besseren Verständnis der folgenden Absätze empfiehlt es sich, sich die Nachrichtenstruktur der INVOIC-Nachricht zurechtzulegen. Zunächst definieren wir den Satz von Trennzeichen, den wir in der Übertragung verwenden wollen. UNA:+,? ' |||||| |||||+---> Segmentendezeichen ||||+----> reserviert, bleibt leer |||+-----> Release-Zeichen ||+------> Zeichen für's Dezimalkomma |+-------> Datenelement-Trennzeichen +--------> Composite-Element-Trennzeichen Die Nachricht wird in den virtuellen Briefumschlag gesteckt, der allerdings zum Befüllen erst einmal geöffnet werden muss. Hierzu ist das UNB-Segment zu verwenden. S001 SYNTAX IDENTIFIER 0001 Syntax identifier UNOA 0002 Syntax version number 2 S002 INTERCHANGE SENDER 0004 Sender id FHPEDAL S003 RECIPIENT 0010 Recipient id HUBERGMBH S004 Date/Time of preparation 0017 Date 990802 (Tagesdatum) 0019 Time 1557 (um kurz vor vier) 0020 Interchange control referenz 9908021557 - Interne Nummer, die Pedal dieser Übertragung verpasst Daraus läßt sich das UNB-Segment jetzt zusammensetzen: UNB+UNOA:2+FHPEDAL+HUBERGMBH+990802:1557+9908021557' Man beachte, dass die derzeitige Version der ISO9735 hier immernoch ein Jahrtausendproblem (S004:0017) hat. Ab Syntax level 4 (hier 2) wird dieses Feld allerdings 8-stellig zu füllen sein. So, nun gehts los - der Briefumschlag ist offen, jetzt stecke man die Nachricht hinein. Die Nachricht INVOICZunächst muss man definieren, dass es sich hier um eine Rechnung handeln wird, und dass deren Aufbau gemäß dem o.g. UN-Standard D93A ist. UNH+INVOIC0001+INVOIC:D:93A:UN'
+--------------------------> Interne Nummer dieser Rechnung
(ist aber nicht die
Rechnungsnummer)
Die Rechnungsnummer geben wir im nun folgenden BGM-Segment an. BGM+380+9908001+9'
| | +-----> 9=Original (also kein Duplikat/Kopie)
| +----------> Die Rechnungsnummer
+----------------> 380=Rechnung (zum wiederholten Male;
381=Gutschrift)
Das Rechnungsdatum kommt im folgenden DTM-Segment: DTM+3:19990802:102'
| | +-----> Format CCYYMMDD
| +-----------> Rechnungsdatum
+-----------------> Spezifiziert das Datum als Rechnungsdatum
Für die im Standard nachfolgenden Segmente haben wir keine Daten, und wir können sie auch weglassen, da der Standard (C)onditional für diese Segmente ausweist. Erst bei der Segmentgruppe 1 (RFF-DTM) machen wir wieder halt, weil hier die referenzierte Bestellnummer eingetragen werden kann: RFF+ON:O0010001'
| +-----------> Bestellnummer
+-----------------> ON=Order number - also die Bestellnummer
Zu dieser Segmentgruppe gehört auch das DTM-Segment, in das das Datum der Bestellung eingetragen wird: DTM+4:19990715:102'
| +-----------> Bestelldatum
+-----------------> Spezifiziert das Datum als Bestelldatum
Nun folgen in der Segmentgruppe 2 (NAD-LOC-FII) die Adressangaben. Zwei solcher Angaben haben wir, die des Senders und die des Empfängers. Also erzeuge man zweimal die Segmentgruppe 2 wobei hier in diesem Beispiel die Folgesegmente/-segmentgruppen (3-5) unterschlagen werden (weil keine Daten). NAD+SE++Fahrradhandel Pedal++Wagingerstr. 5+München++81549'
+-----------------> Spezifiziert Verkäufers Adresse
und NAD+BY++Huber GmbH++Obstgasse 2+München++81549'
+-----------------> Spezifiziert des Käufers Adresse
So, mittlerweile haben wir so ziemlich alles in den Kopf gepackt, was in den Kopf zu packen wäre. Jetzt können wir mit den Rechnungspositionen beginnen - dazu ist es nötig (und erlaubt), alles bis zur Segmentgruppe 22 (LIN...) zu überspringen. Für die drei Rechnungspositionen werden also drei Wiederholungen der Segmentgruppe 22 nötig. Für die folgenden Segmente werde ich die ausführliche Dokumentation etwas zurücknehmen, da ich denke, das die Segmente selbsterklärend sind: LIN+1++4711.001'
IMD+F++:::Fahrrad, Damen'
QTY+47:1:PCE'
| | +-----------> Maßeinheit: Stück
| +--------------> Anzahl 1
+-----------------> Spezifiziert die in Rechnung gestellte
Anzahl (Quantity)
MOA+66:750'
| +-------------> Betrag (Rechnungs-)Position
+-----------------> Spezifiziert den Betrag als Summe dieser
(Rechnungs-)Position
PRI+AAA:750'
| +------------> (Netto-)Preis
+----------------> Spezifiziert Preis als Einzelpreis
LIN+2++4711.002'
IMD+F++:::Luftpumpe, Stand-'
QTY+47:1:PCE'
MOA+66:19,9'
PRI+AAA:19,9'
LIN+3++4711.003'
IMD+F++:::Ersatzventil'
QTY+47:3:PCE'
MOA+66:7,5'
PRI+AAA:2,5'
Damit sind die Detailangaben (sprich Rechnungspositionen) definiert, man kann also jetzt zur Definition der Summensektion übergehen. Dazu wird das Segment UNS verwendet. UNS+S'
+-----------> Markiert den Übergang zur (S)ummensektion
Die Segmentgruppe 45 (MOA-SG46) stellt Segmente zur Verfügung, in die Beträge bezüglich der gesamten Rechnung gefüllt werden können. Diese Segmentgruppe nutzt man also um die Rechnungsendbeträge abzubilden. Zunächst definieren wir den Netto-Gesamtbetrag: MOA+79:777,4'
| +-------------> Gesamtsumme der (Rechnungs-)Positionen
+-----------------> Spezifiziert den Betrag als Summe der
(Rechnungs-)Position
Der Steuerbetrag: MOA+124:124,38'
| +------------> Steuerbetrag
+----------------> Spezifiziert den Betrag als Steuerbetrag
Und zum Schluß kommt dann noch die Gesamtsumme, der zu zahlende Betrag: MOA+128:901,78'
| +------------> Gesamtbetrag
+----------------> Spezifiziert den Betrag als den
Gesamtbetrag
Was jetzt noch fehlt, ist der Steuerprozentsatz, mit dem die einzelnen Nettobeträge besteuert worden sind. Hierfür wird die unmittelbar folgende Segmentgruppe 47 (TAX-MOA) verwendet: TAX+7+VAT+++:::16+S'
| | | +--> definiert den Prozentsatz als
| | | Standardprozentsatz
| | +----> der Prozentsatz
| +-------------> Umsatzsteuer (Value Added Tax)
+----------------> gesetzlich zu erhebende Steuer
Damit ist alles gesagt, was bezüglich der Rechnung zu sagen war. Schließen wir also die Nachricht ab. Hierzu ist das Segment UNT zu verwenden. Dieses Segment dient als interne Kontrollinstanz: UNT+28+INVOIC0001'
| +------------> Interne Nachrichtennummer. Muß mit der
| Nummer im UNH-Segment übereinstimmen
+----------------> Anzahl der Segmente in der Nachricht -
einschließlich dem UNH- und diesem
UNT-Segment
Als allerletzter Schritt ist nun noch der Briefumschlag zuzumachen. Hierfür generiert man das UNZ-Segment: UNZ+1+9908021557'
| +------------> Interne Übertragungsnummer.
| Muß mit der Nummer im UNB-Segment
| übereinstimmen
+----------------> Anzahl der Nachrichten in dieser
Übertragung
Unkommentierte Version der EDIFACT-ÜbertragungLäßt man nun die Kommentare bei dem einzelnen Segmenten weg, erhält man die Übertragung als reine EDIFACT-Übertragung: UNA:+,? ' UNB+UNOA:2+FHPEDAL+HUBERGMBH+990802:1557+9908021557' UNH+INVOIC0001+INVOIC:D:93A:UN' BGM+380+9908001+9' DTM+3:19990802:102' RFF+ON:O0010001' DTM+4:19999715:102' NAD+SE++Fahrradhandel Pedal++Wagingerstr. 5+München++81549' NAD+BY++Huber GmbH++Obstgasse 2+München++81549' LIN+1++4711.001' IMD+F++:::Fahrrad, Damen' QTY+47:1:PCE' MOA+66:750' PRI+AAA:750' LIN+2++4711.002' IMD+F++:::Luftpumpe, Stand-' QTY+47:1:PCE' MOA+66:19,9' PRI+AAA:19,9' LIN+3++4711.003' IMD+F++:::Ersatzventil' QTY+47:3:PCE' MOA+66:7,5' PRI+AAA:2,5' UNS+S' MOA+79:777,4' MOA+124:124,38' MOA+128:901,78' TAX+7+VAT+++:::16+S' UNT+28+INVOIC0001' UNZ+1+9908021557' Es gibt keinerlei Aussagen darüber, ob die Segmente jeweils in einer Zeile stehen sollen oder wie lang eine EDIFACT-Zeile maximal lang sein könnte. EDIFACT ist ein Streamformat in dem die Zeilenendezeichen (CR und LF) sowie überflüssige Leerzeichen ignoriert wird. Demzufolge können wir ohne eine Standardverletzung zu begehen die Übertragung auf 50 Zeichen pro Zeile limitieren und die Segmente fortlaufend aneinanderhängen: UNA:+,? 'UNB+UNOA:2+FHPEDAL+HUBERGMBH+990802:1557+ 9908021557'UNH+INVOIC0001+INVOIC:D:93A:UN'BGM+380+ 9908001+9'DTM+3:19990802:102'RFF+ON:O0010001'DTM+4 :19999715:102'NAD+SE++Fahrradhandel Pedal++Waginge rstr. 5+München++81549'NAD+BY++Huber GmbH++Obstgas se 2+München++81549'LIN+1++4711.001'IMD+F++:::Fahr rad, Damen'QTY+47:1:PCE'MOA+66:750'PRI+AAA:750'LIN +2++4711.002'IMD+F++:::Luftpumpe, Stand-'QTY+47:1: PCE'MOA+66:19,9'PRI+AAA:19,9'LIN+3++4711.003'IMD+F ++:::Ersatzventil'QTY+47:3:PCE'MOA+66:7,5'PRI+AAA: 2,5'UNS+S'MOA+79:777,4'MOA+124:124,38'MOA+128:901, 78'TAX+7+VAT+++:::16+S'UNT+28+INVOIC0001'UNZ+1+990 8021557' Fehler in der NachrichtWährungsangabenEs fehlen in der Nachricht sämtliche Währungsangaben. Gemäß UN/EDIFACT-Standard ist dies auch korrekt, weil im Falle der Abwesenheit von Währungsangaben die jeweilige Landeshauptwährung anzunehmen ist. Somit wäre das Fehlen der Währungen eigentlich kein Fehler. Dies ist jedoch mehr als zweideutig, sodass hier dringend die Angabe der Währungen empfohlen sei. Dies kann jeweils in den MOA-Segmenten geschehen - oder wie in dieser Message in einem allgemeinen CUX-Segment (Segmentgruppe 7 CUX-DTM). BankverbindungHerr Huber weiß anhand der Nachricht nicht, wohin er den geforderten Betrag überweisen soll. Man füge also zu Beginn der Nachricht (also im Kopfteil) ein FII-Segment ein, in dem die Bankverbindung der Pedaler angegeben ist. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EDIFACTORY |
||
|
|
|
