Automatisierte Rückmeldungen zu Lieferavisen. Prozessbeschreibung und allgemeine Hinweise

Transkript

1 VDA Automatisierte Rückmeldungen zu Lieferavisen 4937 Prozessbeschreibung und allgemeine Hinweise Mit der vorliegenden VDA Empfehlung werden folgende Zielsetzungen verbunden: Die Empfehlung soll die Grundlage für die Standardisierung von Rückmeldungen zur Lieferavisierung sein. Version 1.0 vom März 2009 Herausgeber: Verband der Automobilindustrie Copyright Westendstraße 61 Nachdruck und jede sonstige Form Postfach der Vervielfältigung ist nur mit Frankfurt Angabe der Quelle gestattet. Telefon 069/ Telefax 069/ Internet:

2 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 2 von 11 Haftungsausschluss Die VDA-Empfehlungen sind Empfehlungen, die jedermann frei zur Anwendung stehen. Wer sie anwendet, hat für die richtige Anwendung im konkreten Fall Sorge zu tragen. Sie berücksichtigen den zum Zeitpunkt der jeweiligen Ausgabe herrschenden Stand der Technik. Durch das Anwenden der VDA-Empfehlungen entzieht sich niemand der Verantwortung für sein eigenes Handeln. Jeder handelt insoweit auf eigene Gefahr. Eine Haftung des VDA und derjenigen, die an den VDA-Empfehlungen beteiligt sind, ist ausgeschlossen. Jeder wird gebeten, wenn er bei der Anwendung der VDA-Empfehlungen auf Unrichtigkeiten oder die Möglichkeit einer unrichtigen Auslegung stößt, dies dem VDA umgehend mitzuteilen, damit etwaige Mängel beseitigt werden können.

3 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 3 von 11 I. BEGRIFFSBESTIMMUNG ZIELSETZUNG LIEFERAVIS Beschreibung / Definition Problemfälle / Schwachpunkte vorhandener Verfahren Lösung: automatisierte Rückmeldungen ABLAUF Ablauf / Schaubild: ANFORDERUNGEN / EDV-VORAUSSETZUNGEN Beschreibung der internen Verarbeitungsprozesse bei den Partnern Fehlerkategorien und Reporting VAN SONSTIGES... 11

4 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 4 von 11 I. Begriffsbestimmung EDI - ERP-System - Electronic Data Interchange Enterprise Resource Planning Softwaresystem, um in einem Unternehmen vorhandene Ressourcen (Kapital, Betriebsmittel, Personal) möglichst effizient einzuplanen 1 Zielsetzung Mit der vorliegenden VDA Empfehlung werden folgende Zielsetzungen verbunden: Die Empfehlung soll die Grundlage für die Standardisierung von automatischen Rückmeldungen zu Lieferavisen bilden In der Empfehlung sind die Guidelines der Nachrichten beschrieben, die für diesen Prozess genutzt werden sollen 2 Lieferavis 2.1 Beschreibung / Definition Voraussetzung für diese Empfehlung sind Lieferavise, die ausschließlich per Electronic Data Interchange (EDI) übertragen werden. Ein Lieferavis ist ein angekündigter Lager- bzw. Warenzugang. Das Lieferavis wird vom Lieferanten an den Empfänger der Ware gesendet, bevor die Ware geliefert wird. Häufig werden Lieferavise in Supply Chains verwendet, in welchen es für den Empfänger der Ware von großer Wichtigkeit ist, über den rechtzeitigen oder auch verspäteten Zugang der Ware informiert zu werden, um ggf. Vorkehrungen treffen zu können. In einer weiteren wichtigen Funktion bildet das elektronische Lieferavis die Grundlage für den automatisierten Wareneingangsprozess. Fehlerfreie Lieferavise sind für den Liefer- und Vereinnahmungsprozess eine Grundvoraussetzung. Daher ist eine schnelle Reaktion und Korrektur im Fehlerfall dringend erforderlich.

5 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 5 von Problemfälle / Schwachpunkte vorhandener Verfahren Fehler werden heute in unterschiedlichster Art und Weise kommuniziert, allerdings führen die etablierten Verfahren (Fax, Mail, Telefon, Portallösungen) zu Problemen: - in der Regel nicht automatisiert auswertbar (Workflow in ERP-Systemen) - Fehler werden vom Verursacher falsch interpretiert und zu spät bearbeitet, da sie häufig nur technisch beschrieben werden. - Information landet nicht beim richtigen Ansprechpartner / Verantwortlichen - Es sind sehr viele unterschiedliche Stellen im Prozess beteiligt (VAN /Interconnect/Fachabteilungen /EDL/Streckenlieferungen) -> Intransparenz - Die technische Empfangsbestätigung (EERP) gibt keine Info über die Weiterverarbeitung beim Empfänger der Lieferavise - Kein Kontrollmechanismus über die Verarbeitungsschritte beim Empfänger der Lieferavise (aus Lieferantensicht) - Die Unterscheidung technische / inhaltliche Fehler (Kategorisierung) nicht ausgeprägt - Erhöhter Aufwand bei Fehlerklärung Lieferant: Was ist geschehen? Wer ist verantwortlich? Wer korrigiert? - Erstellen einer Fehlerstatistik sehr aufwendig -> Verbesserung durch Kategorisierung und Automation - Es gibt keinen definierten Standard, der in Europa genutzt wird 2.3 Lösung: automatisierte Rückmeldungen - Automatisierbarkeit der IT- und organisatorischen Abläufe - Implementierungsmöglichkeit von Workflow-Funktionalitäten durch Kategorisierung, dadurch optimierte Verantwortungszuweisung / Verbesserung der Transparenz - Identifizierungsmöglichkeit der Fehler - Schnellere Erkennung und -Fehlerbehebung - Standardisierte Fehlermeldung und kategorisierung innerhalb der Branche - Transparenz über alle Schritte des Verarbeitungsprozesses beim Partner durch Standardnachrichten statt rein technischer Empfangsbestätigung (EERP) optimiertes Monitoring - Reduzierung von Fehlervorgängen - Reduzierung der Klärungsaufwände - Ersatz individuell erstellter Dokumente ( s, Fax, Anruf) durch standardisierte Nachrichten

6 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 6 von 11 3 Ablauf Mit Versand der Ware generiert der Lieferant ein Lieferavis und überträgt es an den Kunden. Das Lieferavis wird beim Kunden empfangen. In der Regel geschieht dies innerhalb eines Vorsystems (EDI-System). Hier werden zunächst formale und strukturelle Prüfungen durchgeführt. Der Kunde übermittelt dem Lieferanten eine Empfangsbestätigung und das Ergebnis dieser 1. Prüfungsstufe (EDIFACT CONTRL). Erhält der Lieferant innerhalb eines bilateral abgestimmten Zeitraums keine Rückmeldung oder werden Fehler mitgeteilt, dann startet er die Abarbeitung eines Workflows zur Problembehebung. In Abstimmung mit dem Kunden kann das korrigierte Lieferavis erneut versendet werden. Wenn auf der Kundenseite sämtliche formale und strukturelle Prüfungen durchlaufen wurden (ohne Ablehnung der Nachricht), dann erfolgt die inhaltliche Prüfung der Daten (2. Prüfungsstufe). Der Kunde übermittelt dem Lieferanten das Ergebnis dieser Prüfungen (EDIFACT APERAK). Der Versand dieser Nachricht ist optional, wenn keine Fehler aufgetreten sind. Werden dem Lieferanten Fehler mitgeteilt, dann startet er die Abarbeitung eines Workflows zur Problembehebung. In Abstimmung mit dem Kunden kann das korrigierte Lieferavis erneut versendet werden. Trifft die Ware beim Kunden ein, dann prüft dieser zunächst, ob ein dazu passendes Lieferavis vorliegt. Danach wird geprüft, ob die Informationen aus dem Lieferavis mit denen der Anlieferung übereinstimmen. Die Ergebnisse dieser 3. und 4. Prüfungsstufen können dem Lieferanten mit der Nachricht EDIFACT RECADV mitgeteilt werden. Diese Nachricht ist optional. Die Partner sollten den Einsatz bilateral vereinbaren. Werden dem Lieferanten Fehler aus diesen Prüfungsschritten mitgeteilt, dann startet er einen Workflow zur Problembehebung in enger Abstimmung mit dem Kunden. Der Versand eines korrigierten Lieferavises erscheint hier wenig sinnvoll.

7 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 7 von Ablauf / Schaubild:

8 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 8 von 11 Zu den verwendeten Symbolen: Aktivität An diesem Punkt findet die beschriebene Aktivität statt. Eine rötliche Aktivität behandelt eine Fehlermeldung, eine gelbliche Aktivität eine Warnung. Start des Aktivitätsflusses. Ende des Aktivitätsflusses. Ende eines Teilflusses. Merge / Decision: Bei einem Mergeknoten kommen mehrere Flüsse zusammen (mehrere Eingangspfeile, ein Ausgangspfeil), bei einem Decisionknoten wird der weitere Weg des Flusses durch die Bedingungen der ausgehenden Pfeile bestimmt (ein Eingangspfeil, mehrere Ausgangspfeile). Fork / Join: Der Fork teilt einen Fluss in mehrere Teilflüsse. Die folgenden parallel liegenden Aktivitätsflüsse können parallel oder in beliebiger Reihenfolge ausgeführt werden. Sie können durch einen Join wieder vereinigt werden. Ein Fork hat einen Eingangspfeil und mehrere Ausgangspfeile, ein Join hat mehrere Eingangspfeile und einen Ausgangspfeil. Diese beiden gezeigten Symbole sind nur horizontale und vertikale Darstellungen, semantisch aber äquivalent. Die Pfeile beschreiben die Flussrichtung und stellen den Zusammenhang zwischen den Aktivitäten her. Hier entspricht die Pfeilrichtung auch dem zeitlichen Ablauf: Aktivitäten vor dem Pfeil finden vor Aktivitäten nach dem Pfeil statt (Ausnahme: Kreise). [Bedingung] Bedingungen stehen an Pfeilen nach Decision-Elementen. Ist die Bedingung an einem Pfeil erfüllt, geht der Aktivitätsfluss in diese Richtung weiter. An den Stellen, an denen keine Fehlermeldungen für die einzelnen Nachrichten erstellt werden, werden die Fork-Elemente verwendet, um eine Parallelität der darauf folgenden Aktivitätsflüsse zu verdeutlichen.

9 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 9 von 11 4 Anforderungen / EDV-Voraussetzungen Die Vereinbarungen zum Kommunikationsprozess, insbesondere zur Verfahrensweise bei auftretenden Fehlern sollten in einer Logistikvereinbarung hinterlegt werden 4.1 Beschreibung der internen Verarbeitungsprozesse bei den Partnern Grundsätzlich sind Vorklärungen der technischen Gegebenheiten mit dem Partner notwendig, um einen reibungslosen Ablauf zu gewährleisten und Fehlinterpretationen auszuschließen. Hier spielen besonders Informationen der technischen Infrastruktur eine Rolle (Anzahl Vorsysteme, Einbindung des EDI-Systems, nachgelagerte Systeme), da diese Rückschlüsse zur optimierten Fehlerbehebung liefern können. - Welche Prüfungen finden im Zusammenhang mit CONTRL statt? - Gibt es inhaltliche Prüfung über Code-Tabellen für die Control-Nachricht? - Diagramm mit Infrastruktur? - Welche Meldungen entstehen wann und wo? - Gibt es ein zentrales EDI-System mit wieviel angebundenen Ländern? 4.2 Fehlerkategorien und Reporting Für das Monitoring müssen bilateral pro Partnerbeziehung Zeitgrenzen vereinbart werden, um entsprechende Eskalationsszenarien aufbauen zu können. Fehlermeldungen sollen den in den Nachrichtendefinitionen beschriebenen Kategorien zugeordnet sein. Dieses ermöglicht die schnelle Weiterleitung an eine verantwortliche Stelle. Die Nachrichten enthalten Informationen, aus denen der Status des Lieferavis klar erkennbar ist: Akzeptiert (kein Fehler) Akzeptiert mit Fehler(n) - Warnung Nicht akzeptiert Nachricht wurde abgewiesen Automatisierte Rückmeldungen sollen in folgenden Schritten erfolgen.

10 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 10 von 11 EDIFACT CONTRL Die Nachricht beinhaltet die Ergebnisse formaler und struktureller Prüfungen (Ggfs. inhaltliche Prüfungen durch Tabellen (Werkscodes, etc.) (Routinginformationen, Feldlängen, Codes, Struktur, technische Parameter) und wird als Empfangsbestätigung genutzt. Die Prüfungen erfolgen meist im vorgelagerten Empfangssystem (EDI-System). Die Nachricht EDIFACT CONTRL muss in jedem Fall versendet werden, da hierdurch der Prozess optimal überwacht werden kann. Sollte die Nachricht innerhalb eines zwischen den Partnern vereinbarten Zeitraums nicht eintreffen, veranlasst der Lieferant eine Prüfung und nimmt mit dem Partner zur Problembehebung Kontakt auf. Eine CONTRL-Nachricht beinhaltet die Prüfergebnisse für eine Übertragungsdatei. Jede empfangene Übertragungsdatei muss mit einer eigenen CONTRL-Nachricht beantwortet werden. Im Fehlerfall kann das korrigierte Lieferavis in Absprache mit dem Partner erneut versendet werden.die Nachricht CONTRL ist als Antwort auf EDIFACT-Nachrichten konzipiert. Sie kann analog auch für andere in der Industrie gebräuchliche Nachrichtenarten verwendet werden. Die nationalen Organisationen können bei Bedarf eigene Codelisten definieren, um solche "Nicht-EDIFACT"-Nachrichten zu unterstützen. Im Focus dieser Dokumentation steht die Beantwortung von Lieferavisen (DESADV). Die Nachricht kann aber analog auch für weitere Geschäftsprozesse z.b. die Rechnungsstellung (INVOIC) genutzt werden. EDIFACT APERAK Die Nachricht beinhaltet die Ergebnisse inhaltlicher, anwendungsbezogener Prüfungen (nachgelagerte Systeme). Sie muss im Fehlerfall und bei Warnungen versendet werden. Wenn kein Fehler festgestellt wurde, ist die Nachricht optional. Auch hier kann im Fehlerfall das korrigierte Lieferavis in Absprache mit dem Partner erneut versendet werden. Für jede fehlerhafte Nachricht in einer Übertragungsdatei wird eine eigene APERAK versendet. Die Nachricht APERAK ist als Antwort auf EDIFACT-Nachrichten konzipiert. Sie kann analog auch für andere in der Industrie gebräuchliche Nachrichtenarten verwendet werden. Die nationalen Organisationen können bei Bedarf eigene Codelisten definieren, um solche "Nicht-EDIFACT"-Nachrichten zu unterstützen. Im Focus dieser Dokumentation steht die Beantwortung von Lieferavisen (DESADV). Die Nachricht kann aber analog auch für weitere Geschäftsprozesse z.b. die Rechnungsstellung (INVOIC) genutzt werden. EDIFACT RECADV Die Nachricht beinhaltet die Ergebnisse der Vergleichsprüfung zwischen avisiertem und physischem Wareneingang. Die Nachricht EDIFACT RECADV ist grundsätzlich nur optional. Im Fehlerfall muss eine bilaterale Reklamationsabwicklung erfolgen.

11 VDA-Empfehlung 4937 Version 1.0, März 2009 Seite 11 von 11 5 VAN - Der VAN ist für die Weiterleitung der Nachrichten verantwortlich. Er ist nicht verantwortlich für syntaktische und/oder inhaltliche Prüfungen - Tritt ein Fehler bei der Weiterleitung auf, dann wird vom VAN eine zeitnahe Information erwartet. In diesem Fall ist mit dem VAN ein Verfahren zur Fehlererkennung abzustimmen. - Diese Art der Fehlerbehandlung liegt ausserhalb des Scopes dieses Projekts. 6 Sonstiges - WebEDI ist nicht Gegenstand dieser Empfehlung - Die Nachricht EDIFACT CONTRL kann jederzeit auch für andere Geschäftsprozesse eingesetzt werden. - Die hier beschriebenen EDIFACT-Rückmeldungen sind grundsätzlich auch anwendbar, wenn das Lieferavis in einem anderen Format als EDIFACT versendet wurde (z.b. VDA). - EDL / Streckenabwicklung wurden nicht betrachtet, können jedoch mit den beschriebenen Prozessen ebenfalls abgewickelt werden.