Prozesse in der Beschaffung von heute sind bereits zu einem hohen Maße automatisiert, was durch die Verwendung von elektronischem Datenaustausch (EDI) erreicht wird. Im folgenden Beitrag untersuchen wir ein klassisches Beschaffungsszenario, wie man es beispielsweise im Handel vorfindet. Wir zeigen dabei auf, welche EDIFACT und ANSI ASC X12-Dokumentformate verwendet werden können und wie die dazugehörigen SAP IDoc-Formate heißen.
EDI-Prozesse im Bereich der Beschaffung
Ohne die Verwendung von automatisierter Datenübertragung geht in vielen Beschaffungsprozessen heute gar nichts mehr. Die hohe Bestellfrequenz und die hohe Varianten- und Produktvielfalt machen eine manuelle Bestellung, z.B. auf Basis von Papier oder Fax, unmöglich. Stattdessen werden Daten zwischen Kunde und Lieferant mit Hilfe von strukturierten Dokumentformaten ausgetauscht – direkt von System zu System, ohne menschliche Interaktion.
Durch diesen elektronischen Datenaustausch (EDI) werden eng verzahnte Lieferketten und eine automatisierte Beschaffung erst ermöglicht. Je nach Industrie und Anwendungsfeld kommen dabei unterschiedliche Prozessvarianten zum Einsatz. So hat sich beispielsweise in der Automobilindustrie das Konzept von Lieferplänen in Verbindung mit Lieferabrufen, Feinabrufen usw. durchgesetzt. Diese Prozessvariante haben wir bereits in einem früheren Beitrag genauer beleuchtet.
Im heutigen Beitrag wollen wir auf einen klassischen Beschaffungsprozess eingehen, wie man ihn beispielsweise im Handel vorfindet. Im ersten Teil stellen wir den Dokumentenfluss entlang der Beschaffungskette vor. Im zweiten Teil gehen wir die passenden EDIFACT und ANSI ASC X12-Dokumentformate ein und zeigen auf, welche IDoc-Typen für den Import- und Export dieser Daten in und aus einem SAP ERP-System verwendet werden können.
Überblick über die verwendeten EDI-Dokumenttypen in der Beschaffung
Die folgende Abbildung zeigt einen typischen Dokumentenfluss zwischen einem Lieferanten und einem Käufer.
EDI-Prozesse im Bereich der Beschaffung
Der Lieferant übermittelt Daten über sein aktuelles Produktsortiment in Form von Preiskatalog-Daten (PRICAT) an den Kunden. In einem PRICAT werden die Artikelstammdaten wie GTINs, Preise, Maßeinheiten usw. in einem strukturierten Format für den Käufer bereitgestellt. Der Käufer kann diese Daten in die Stammdaten seines ERP-Systems (z.B. SAP) übernehmen.
Auf Basis der erhaltenen Artikelstammdaten des Lieferanten kann der Käufer eine Bestellung (ORDERS) an den Lieferanten übermitteln. Eine Bestellung beinhaltet dabei kodierte Angaben über den Käufer und Verkäufer, die gewünschte Lieferadresse, Details über die Produkte usw. Unter kodiert versteht man dabei, dass keine natürlichsprachlichen Bezeichnungen wie Erdbeerjoghurt, 250ml verwendet werden, sondern eindeutige Identifier. Für Produkte werden dabei üblicherweise Global Trade Identification Numbers (GTIN) verwendet, für die verwendeten Geschäftspartner, Adressen usw. so genannte Global Location Numbers (GLN).
Nachdem eine Bestellung vom Käufer an den Lieferanten übermittelt worden ist, kann diese anhand einer Bestelländerung (ORDCHG) geändert werden. Damit können beispielsweise Korrekturen an der bestellten Menge, an der Anlieferadresse, am gewünschten Lieferdatum usw. kommuniziert werden.
Der Lieferant kann die erhaltene Bestellung bzw. die erhaltene Bestelländerung mit einer Bestellantwort (ORDRSP) bestätigen, teilweise bestätigen, mit Änderungen bestätigen oder ablehnen. Welche Varianten genau zulässig sind, wird üblicherweise bei der Prozessumsetzung festgelegt.
Bevor der Lieferant die Waren an den Käufer versendet, wird eine Lieferavis-Nachricht (DESADV) versendet. Mit Hilfe des Lieferavis übermittelt der Lieferant die Details über die bevorstehende Lieferung an den Käufer. Diese Details umfassen beispielsweise Brutto- und Nettogewichte, die Anzahl der Paletten, Palettenidentifikationsnummern wie Nummer der Versandeinheit (NVE), Details zum Transportmittel, wie das Kennzeichen des LKWs usw. Mit Hilfe dieser Informationen kann der Käufer seine eigene Eingangslogistik entsprechend planen und Ressourcen zur Verfügung stellen — z.B. Tiefkühlkapazitäten im Cross-Docking-Lager im Falle von Tiefkühlwaren. Des Weiteren kann der Käufer die Vollständigkeit der angelieferten Waren verifizieren, indem die an den Paletten angebrachten NVE-Nummern gescannt werden und mit den Informationen im vorher erhaltenen Lieferavis bzw. in der dazugehörigen Bestellung verglichen werden.
Nachdem die Waren beim Kunden vereinnahmt wurden, kann der Käufer eine Warenempfangsbestätigung (RECADV) an den Lieferanten übermitteln. Mit Hilfe der RECADV-Nachricht wird dem Lieferanten die Anzahl an vereinnahmten Paletten/Waren kommuniziert. Die in der RECADV-Nachricht bestätigte Menge muss nicht notwendigerweise mit der im Lieferavis oder in der Bestellung enthaltenen Menge übereinstimmen. Gründe für eine Abweichung können zum Beispiel eine Überlieferung oder Unterlieferung durch den Lieferanten sein, welche der Käufer aber trotzdem akzeptiert. Weitere Gründe für eine Abweichung können Warenverlust während des Transports sein oder eine mangelnde Produktqualität, weshalb der Käufer die Annahme verweigert. Im Lebensmittelbereich kommt dies beispielsweise bei gekühlter Ware vor, wenn diese eine gewisse Maximaltemperatur überschreitet – z.B. bei frischer Milch.
Am EDI-Ende des Prozesses der Beschaffung übermittelt der Lieferant eine Rechnung (INVOIC) an den Käufer, in welcher die in Rechnung gestellten Produkte, Zu- und Abschläge, Rabatte, mögliche Skonti usw. kommuniziert werden.
Nicht alle hier genannten Dokumenttypen müssen notwendigerweise in jedem Geschäftsszenario zur Anwendung kommen. Im deutschen Handel findet man beispielsweise vorwiegend die Dokumenttypen Bestellung, Lieferavis und Rechnung. Bestelländerungen, Bestellantworten sowie Warenempfangsbestätigungen gewinnen aber immer mehr an Bedeutung und werden von den großen Handelsketten bereits schrittweise eingeführt.
In der Bekleidungsindustrie haben aufgrund der hohen Änderungsrate im Produktsortiment (Frühlingskollektion, Sommerkollektion, etc.) Preiskataloge eine wichtige Bedeutung. Des Weiteren findet man in der Bekleidungsindustrie auch oft Vendor Managed Inventory (VMI) Konzepte, bei welchen der Lieferant selbst für den ausreichenden Lagerstand auf Seiten des Käufers zuständig ist. VMI erfordert weitere Dokumenttypen wie Inventory Reports (INVRPT) und Sales Reports (SLSRPT), auf die wir in einem zukünftigen Artikel eingehen werden.
Mapping auf IDoc-Typen
EDI-Nachrichtentypen im Bereich der Beschaffung
Die verwendeten IDoc-Typen können je nach verwendeter SAP-Konfiguration auch unterschiedlich sein — z.B. wenn Z-Typen zur Anwendung kommen.
Zusammenfassung
EDI-Standards wie EDIFACT oder ANSI ASC X12 sind die Basis für moderne Beschaffungsprozesse. Zur korrekten Verarbeitung der verschiedenen Dokumenttypen in einem SAP ERP-System kommen IDocs zur Anwendung.
Durch die Vielzahl an verschiedenen EDI-Standards, EDI-Standardversionen sowie industrie- und unternehmens-spezifischen Formaten ist für die Übersetzung EDI auf IDoc und umgekehrt ein EDI-Konverter notwendig. EDI-Konverter können als lokale Lösung betrieben werden oder als Managed Service von einem EDI-Dienstleister bezogen werden.
Noch Fragen?
Sie haben noch Fragen zum Thema IDoc oder zum Thema elektronischer Datenaustausch mit einem SAP ERP? Zögern Sie nicht und nehmen Sie mit uns Kontakt auf oder benutzen Sie unseren Chat — wir helfen Ihnen gerne weiter!
SAP ERP und SAP S/4HANA sind die Marken oder eingetragenen Marken der SAP SE oder ihrer verbundenen Unternehmen in Deutschland und mehreren anderen Ländern.
