Das Verarbeiten von EDI Nachrichten ist ein mehrstufiger Prozess. Bei eingehenden Nachrichten reicht der Prozess von der physischen Vereinnahmung der Daten durch einen externen Konverter bis in die Echtdateien; bei ausgehenden Daten besteht der Prozess in umgekehrter Reihenfolge aus der Übermittlung der Daten in eine Schnittstellendatei bis hin zur physischen Versendung der Daten an den EDI-Partner (Kunde oder Lieferant).
Im Folgenden wird eine einfache Darstellung des Prozesses erläutert. Die Darstellung ist als konkretes Beispiel mit Aufträgen als eingehende Nachrichtenart versehen und ausgehend mit Bestellungen. Die grün dargestellten Bereiche gehören nicht zu oxaion, sondern werden von externen Anbietern durchgeführt.

Bei diesem Ablauf können Fehler entstehen, die ganz unterschiedliche Ursachen haben. Derzeit werden die Fehler aus dem Konvertierungsprozess in Spoolfiles geschrieben, Fehler bei der Übertragung aus und in die Echtdateien werden in die Mailbox geschrieben. Daher ist es notwendig, regelm��ßig Spools und die Mailbox nach Fehlern zu durchsuchen. Die verschiedenen Programme reagieren im Fehlerfall unterschiedlich. Umsetzprogramme drucken genau dann eine Fehlerliste, wenn ein Fehler aufgetreten ist. Übernahme bzw. Übergabeprogramme von bzw. nach dem Modul Verkauf legen Fehlermeldungen in der Mailbox ab und drucken sie vor Beendigung des Programms auch aus. Übernahme bzw. Übergabeprogramme von bzw. nach dem Modul Einkauf drucken immer Übergabeprotokoll und Fehlerliste.
Im Folgenden werden die programmtechnischen Abläufe beschrieben, die beim Senden bzw. Empfangen einer Nachricht ablaufen.

Übernahmeprogramme

Die Übernahmeprogramme dienen dazu eingehende Daten so zu codieren, dass oxaion die Daten aus dem Fremdsystem versteht. Durch sie werden bei ausgehenden Daten die Inhousedateien gefüllt. Bei eingehenden Daten werden die Schnittstellen gefüllt. Bei der Beschreibung der einzelnen Nachrichtenarten werden die Namen der Inhousedateien angeführt.

Allgemeine Prinzipien

In den allgemeinen Prinzipien werden die Grundsätze erläutert, die für alle Nachrichtenarten gelten.

Ablaufsteuerung

Die Ablaufsteuerung ist individuell auf die Bedürfnisse der Firma anzupassen. Alle Umsetzprogramme laufen firmenübergreifend. Es ist zu beachten, dass sie die jeweiligen Inhousedateien exklusiv benutzen.
Im einfachsten Fall ist denkbar, dass ein CL-Programm geschrieben wird, welches externen Konverter, Umsetzprogramm und Übernahme der Schnittstelle in die Anwendung in der richtigen Reihenfolge aufruft. Dieses Programm wird dann ein oder mehrmals am Tag aufgerufen. Es ist auch denkbar, die oxaion Umsetzprogramme in die Ablaufsteuerung der externen Konvertersoftware einzubinden.

Netzadresse, Datenaustauschreferenz

Jeder EDI-Partner besitzt eine physische Netzadresse. Diese Adresse ist mit dem Programm KI10100R (EDI-Netzadressen) anzulegen. Außerdem ist dort die Netzadresse der oxaion Mandanten anzulegen.
Die Netzadresse wird intern nur zum Ermitteln/Aktualisieren der Datenaustauschreferenz verwendet. Bei eingehenden Nachrichten erfolgt keine Prüfung der Datenaustauschreferenz. Das ist auch nicht möglich, weil die Nachrichten nach Nachrichtentyp sortiert in verschiedenen Schnittstellen stehen und auch zu unterschiedlichen Zeiten abgearbeitet werden können. Eine fortlaufende Reihenfolge der Datenaustauschreferenz ist somit nicht zu garantieren. Sie kann nur von der externen Konverter-Software geprüft werden. In der oxaion Netzdatei wird lediglich die h��chste verarbeitete Datenaustauschreferenz zu Informationszwecken gespeichert. Für ausgehende Nachrichten wird die Datenaustauschreferenz für jedes neue B-Segment pro Netzadresse fortlaufend vergeben.

Allgemeine Umsetzdatei

Bei der Umsetzung von EDI-Feldinhalten in oxaion Feldinhalte wurde versucht, soweit wie möglich bereits in oxaion gespeicherte Informationen zu verwenden, um den Pflegeaufwand gering zu halten. So werden zum Beispiel die amtliche Länderkennung aus dem Länderstamm, GLN aus Firmenstamm und Adressstamm und die GTIN aus dem Artikelstamm verwendet.
Sind die für die Umsetzung erforderlichen Daten nicht bereits in oxaion hinterlegt, erfolgt die Umsetzung über die allgemeine Umsetzdatei. Diese wird mit dem Programm KI10400R (EDI-Umsetzdatei verwalten) gepflegt. Der Schlüssel besteht aus Standard, Subset, Konvertierungsgruppe, Nachrichtentyp, Satzart, Referenzfeld und Codeliste. Um den Pflegeaufwand gering zu halten, ist es nicht nötig, alle Umsetzungen für jede mögliche Schlüsselkombination zu hinterlegen. Es ist zum Beispiel möglich, die Umsetzung für ein Referenzfeld global für den gesamten Standard zu hinterlegen. In diesem Fall werden die restlichen Schlüsselfelder leer gelassen.
Bei der Umsetzung ist eine Suchfolge vom speziellen zum allgemeinen definiert:
1.Standard, Subset, Konvertierungsgruppe, Nachricht, Satzart, Referenzfeld, Codeliste
2.Standard, Subset, Nachricht, Satzart, Referenzfeld, Codeliste
3.Standard, Nachricht, Satzart, Referenzfeld, Codeliste
4.bis 6. wie 1. bis 3., aber ohne Satzart
7.bis 9. wie 1. bis 3., aber ohne Nachricht und Satzart
(Der Schlüssel bleibt immer der gleiche; wenn hier ein Feld weggelassen wurde, bedeutet dies, dass dieses Feld leer gesetzt wird.)
Über einen Parameter in der Tabelle FRDRFF (Referenzfeld zur EDI-Umsetzung) kann für jedes Referenzfeld gesteuert werden, welche dieser 9 Zugriffe ausgeführt werden sollen.
Bei folgenden Referenzfeldern greift die hier beschriebene Zugriffslogik nicht. Hier erfolgt jeweils nur ein Zugriff mit Standard und Subset:
ADCDCodeliste Adressnummer
ADFIUmsetzung Adressnummer - Firmennummer
ADNUUmsetzung Adressnummer - Kunden-/Lieferantennummer
CDIDCodeliste Artikelnummer
TIDOArtikelnummer

In der Tabelle FRDRFF (Referenzfeld zur EDI-Umsetzung) sind alle Referenzfelder hinterlegt, für die eine Umsetzung mit der allgemeinen Umsetzdatei erfolgen kann. Eine Änderung der Referenzfeldnamen ist nicht zulässig. Hinzuerfassen von Referenzfeldern ist nur in Verbindung mit Programmänderungen sinnvoll.
Für jede Schlüsselkombination können beliebig viele Umsetzpaare angelegt werden. Diese bestehen aus EDI oxaion Wertepaaren, die gleichzeitig durch eine Richtungsangabe gekennzeichnet sind. Als Richtung sind I (für eingehende Nachrichten), O (für ausgehende Nachrichten) und B (für beide Richtungen) möglich.

Beispiel:
Standard EDIFACT, Subset EANCOM, Eingehender ORDER, der Kunde gehört keiner speziellen Konvertierungsgruppe an, auf Positionsebene ist die Mengeneinheit ST umzusetzen. Der komplette Schlüssel für den Zugriff sieht wie folgt aus:

Zunächst wird mit diesem Schlüssel versucht, ob es einen Satz mit Umsetzrichtung 'I' oder 'B' gibt, dessen EDI-Feld gleich 'ST' ist. Gelingt dies nicht, wird der Schlüssel gemäß der oben beschriebenen Zugriffsfolge verallgemeinert. Dabei wird der 2., 5. und 8. Zugriff nicht ausgeführt, weil das Weglassen der Konvertierungsgruppe nichts neues bringt (sie ist ja im speziellen Fall schon leer).
Wird ein gültiges Wertepaar gefunden, so wird der Inhalt des Feldes 'Verschlüsselung in oxaion' als Mengeneinheit in oxaion verwendet. Wird bei keinem Zugriff ein gültiges Wertepaar gefunden, so wird eine entsprechende Fehlermeldung ausgegeben.

Mandanten und Kunden/Lieferanten bei eingehenden Nachrichten ermitteln

Der Mandant (Firmennummer in oxaion)wird aus den übermittelten Adressfeldern ermittelt. Dabei wird entweder die Übermittlung eines Lieferanten (ORDERS, ORDCHG; Adressqualifier SU) oder eines Kunden (ORDRSP, DESADV, INVOIC; Adressqualifier BY) erwartet. In welchem der vier möglichen Adressfelder diese Informationen stehen, ist nicht relevant.
Ebenso wird die Nummer des Partners (Kundennummer bei ORDERS, ORDCHG; Adressqualifier BY bzw. Lieferantennummer ORDRSP, DESADV, INVOIC; Adressqualifier SU) aus den übermittelten Adressfeldern ermittelt.
Die Umsetzung der Adressnummer hängt von der übergebenen Codeliste ab. Zuerst wird geprüft, ob für die übergebene Adressnummer und Codeliste in der Umsetzdatei eine Umsetzung hinterlegt ist. Die entsprechenden Referenzfelder für diese Umsetzung sind ADFI (EDI-Adressnummer in oxaion Firmennummer) und ADNU (EDI-Adressnummer in oxaion Kunden-/Lieferantennummer). Wenn keine Umsetzung gefunden wird und durch die Codeliste angezeigt wurde, dass es sich um eine GLN handelt (EANCOM Codeliste 14), so wird mit der übermittelten GLN auf den Firmenstamm bzw. den Adressstamm zugegriffen.

Ermittlung der Adressnummer bei ausgehenden Nachrichten

Im EDI-Wertesegment kann für jeden Kunden eine Adresscodeliste hinterlegt werden. Mit dieser Codeliste werden für ausgehende Nachrichten sämtliche Adressnummern ausgegeben. Die Umsetzung erfolgt über die allgemeine Umsetzdatei (Referenzfelder ADFI und ADNU). Entspricht die Adresscodeliste der GLN (14 bei EANCOM oder umsetzbar in 14 bei anderem Subset), so wird nach erfolglosem Zugriff auf die Umsetzdatei die GLN aus dem Firmenstamm bzw. Adressstamm verwendet.

 

Kennwortprüfung und Nachrichtenaustauschreferenz bei eingehenden Nachrichten

Nachdem Firma und Kunde/Lieferant ermittelt wurden, wird das Kennwort überprüft. Im EDI-Wertesegment können pro Partner ein Kennwort für eingehende und ein Kennwort für ausgehende Nachrichten hinterlegt werden. Das Kennwort für ausgehende Nachrichten wird bei ausgehenden Nachrichten mit übermittelt. Bei eingehenden Nachrichten wird das vom Partner übermittelte Kennwort gegen das hier hinterlegte Kennwort für eingehende Nachrichten geprüft. Stimmen diese nicht überein, wird eine weitere Verarbeitung der Nachricht abgelehnt.
Im EDI Kommunikationsstandard kann eingestellt werden, ob pro Nachricht die übermittelte Nachrichtenaustauschreferenz überprüft wird. Ist dies der Fall muss sie numerisch sein. Sie soll gewährleisten, dass eine lückenlose Verarbeitung aller gesendeten Nachrichten erfolgt ist. Die letzte übermittelte Nachrichtenaustauschreferenz ist pro Partner und Nachricht in den EDI-Kommunikationsdaten hinterlegt. Ist die übermittelte Nachrichtenaustauschreferenz nicht genau um '1' größer als die im EDI-Kommunikationsstandard hinterlegte letzte übermittelte Nachrichtenaustauschreferenz, so erfolgt keine weitere Verarbeitung der Nachricht.

Ermittlung der Artikelnummer bei eingehenden Nachrichten

Bei eingehenden Nachrichten können maximal vier verschiedene Informationen über den Artikel empfangen werden. Die Art der Information ist an der Codeliste ersichtlich. In EANCOM sind folgende Codelisten fest definiert (wird ein anderes Subset verwendet, müssen die Codelisten zunächst auf die hier beschriebenen EANCOM-Codelisten umgesetzt werden):

Zusätzlich können die Partner untereinander eigene Codelisten vereinbaren, die dann in der Umsetzdatei zu hinterlegen sind.
Im EDI-Wertesegment wird zu jedem Partner hinterlegt, über welche Codelisten die Kommunikation erfolgen soll. So kann zum Beispiel festgelegt werden, dass die Kommunikation nur über GTIN erfolgt. In diesem Fall würde in den übermittelten Informationen lediglich nach der Codeliste für die GTIN gesucht.
 

Artikelnummer für ausgehende Nachrichten

Im EDI-Wertesegment können für jeden Partner bis zu vier Codelisten hinterlegt werden, mit denen Artikelinformationen gesendet werden sollen. Zusätzlich zu den bereits oben beschriebenen EANCOM-Codelisten wurden die Sonderwerte *U und *P eingeführt. Dabei steht *U für unsere Artikelnummer (wird bei ORDER, ORDCHG in SA, bei den anderen Nachrichten in BP umgesetzt) und *P für die Artikelnummer der Partners (BP bei ORDER, ORDCHG und SA bei den anderen Nachrichten).

Fehlerbehandlung und Sicherungsdateien

Zu jeder Inhouse-Datei existiert eine Sicherungsdatei. Diese enthält neben dem kompletten Originalsatz der zugehörigen Inhouse-Datei die Felder Fehlercode, Erstellungsdatum/-zeit und für die KOERXP und KOCHXP noch einen eindeutigen Satzzähler.
Die Sicherungsdateien haben den gleichen Namen wie die Inhouse-Datei, auf der 5. Stelle wurde 'G' durch 'X' und 'P' durch 'Y' ersetzt.

Beispiel:
ORDERS
eingehend: Inhouse-Datei: KOERGP Sicherungsdatei: KOERXP
ausgehend: Inhouse-Datei: KOERPP Sicherungsdatei: KOERYP
Bei eingehenden Nachrichten wird ein verarbeiteter Satz grundsätzlich aus der Inhouse-Datei gelöscht und in die Sicherungsdatei übertragen. Tritt ein Fehler auf, wird dieser Satz in der Sicherungsdatei mit einem entsprechenden Fehlercode versehen. Außerdem wird bei auftretenden Fehlern im Umsetzprogramm eine Fehlerliste erzeugt.
Wird in einem Segment ein Fehler festgestellt (Feld kann nicht umgesetzt werden, Kennwort stimmt nicht, falsche Nachrichtenreferenz) wird dieses Segment nicht weiter verarbeitet. Alle darunterliegenden Segmente werden nicht verarbeitet, es wird beim nächsten Segment der gleichen oder einer höheren Ebene aufgesetzt.

Beispiel:
Fehler im H-Segment: Alle folgenden A-, D- und P-Segmente werden nicht verarbeitet (sondern lediglich in die Sicherungsdatei übertragen), die weitere Verarbeitung setzt beim nächsten H- oder B-Segment fort.
Bei ausgehenden Nachrichten werden Sicherungsdatei und Inhouse-Datei parallel gefüllt. Wenn die Inhouse-Datei von der externen Konverter-Software nach Verarbeitung gelöscht wird, steht die Sicherungsdatei weiter zu Dokumentationszwecken zur Verfügung.
Mit dem Programm KI50110R können Nachrichten aus der Sicherungsdatei wieder in die Inhouse Schnittstelle zurückgeholt werden.

KI21100R (Umsetzen ausgehender ORDERS/ORDCHG)

oxaion Schnittstelle:EOERKP, EOERPP
Inhouse-Datei: KOERPP, KOCHPPSicherungsdatei: KOERYP, KOCHYP

KI21200R (Umsetzen ausgehender ORDRSP)

oxaion Schnittstelle:VORSKP, VORSPP
Inhouse-Datei: KORSPP
Sicherungsdatei: KORSYP

KI21300R (Umsetzen ausgehender DESADV)

oxaion Schnittstelle:VDADKP, VDADPP
Inhouse-Datei: KDADPP
Sicherungsdatei: KDADYP

KI21400R (Umsetzen ausgehender INVOIC)

oxaion Schnittstelle:VIOIKP, VIOIPP
Inhouse-Datei: KIOIPP
Sicherungsdatei: KIOIYP

KI21500R (Umsetzen ausgehender INVOR)

oxaion Schnittstelle:VIORKP, VIORPP
Inhouse-Datei: KIORPP
Sicherungsdatei: KIORY

KI21600R (Umsetzen ausgehender PRICAT)

oxaion Schnittstelle:UPCKPP, UPCPPP, UPCRPP
Inhouse-Datei: KPRCPP
Sicherungsdatei: KPRCYP

KI22100R (Umsetzen eingehender ORDERS/ORDCHG)

oxaion Schnittstelle:VOERKP, VOERPP
Inhouse-Datei: KOERGP, KOCHGP
Sicherungsdatei: KOERXP, KOCHXP

KI22200R (Umsetzen eingehender ORDRSP)

oxaion Schnittstelle:EORSKP, EORSPP
Inhouse-Datei: KORSGP
Sicherungsdatei: KORSXP

KI22300R (Umsetzen eingehender DESADV)

oxaion Schnittstelle:EDADKP, EDADPP
Inhouse-Datei: KDADGP
Sicherungsdatei: KDADXP

KI22400R (Umsetzen eingehender INVOIC)

oxaion Schnittstelle:EIOIKP, EIOIPP
Inhouse-Datei: KIOIGP
Sicherungsdatei: KIOIXP

KI22600R (Umsetzen eingehender PRICAT)

oxaion Schnittstelle:UPCKGP, UPCPGP, UPCRGP
Inhouse-Datei: KPRCGP
Sicherungsdatei: KPRCXP

KI22700R (Umsetzen eingehender INVRPT)

oxaion Schnittstelle:VIRPKP, VIRPPP
Inhouse-Datei: KIRPGP
Sicherungsdatei: KIRPXP

Nachrichten Bestellung (ORDERS), Bestelländerung (ORDCHG) und Bestellantwort (ORDRSP)

Diese drei Nachrichten werden zusammen beschrieben, da sie alle die Bestellung/den Auftrag betreffen und untereinander synchronisiert sein müssen.
Der einfachste Fall besteht darin, dass nur die Nachricht ORDERS zwischen Kunde und Lieferant ausgetauscht wird. Dazu sind die Nachrichten ORDERS eingehend bzw. ausgehend im KI10300R (EDI-Kommunikationsstandard verwalten) für den Partner zu aktivieren.
Falls nur ORDERS ausgetauscht werden, müssen nachträgliche Änderungen telefonisch abgesprochen werden und jeweils manuell in der Bestellung beim Kunden und im Auftrag beim Lieferanten nachgezogen werden. Nur so ist zu gewährleisten, dass auf beiden Seiten von gleichen Bestellangaben ausgegangen wird.
Bedeutsam ist die nachträgliche Abstimmung immer dann, wenn aufgrund von Fehlern bei der Verbuchung des Auftrages auf der Lieferantenseite Positionen nicht oder nicht vollständig in den Auftrag übernommen wurden. Fehler können z.B. in der mangelnden Verfügbarkeit des gewünschten Artikels oder in einer nicht erfolgreich abgeschlossen Preisprüfung bestehen. Aus diesem Grunde wird empfohlen, falls ORDCHG und ORDRSP nicht ausgetauscht werden, die Preisprüfung auszuschalten. Dazu ist folgendermaßen vorzugehen:
(KI10200R erste Lasche: Max. Preisdifferenz = 0) und die Auswahl '2' (alles auf verfügbares Datum ändern) für das Verhalten bei Nichtverfügbarkeit vorgeben (KI10200R (EDI-Wertesegmente) zweite Lasche).
Voraussetzung bei der ausschließlichen Verwendung des ORDERS im Auftrags-/Bestellbereich ist, dass die Änderung der EDI-relevanten Felder in Bestellung (zweite Lasche in KI10200R (EDI-Wertesegmente), Parameter 1 in VRLE32 (Vorlauftabelle für EDI im Einkauf)) und Auftrag (dritte Lasche in KI10200R (EDI-Wertesegmente)) erlaubt ist.
Der Verzicht auf ORDCHG und ORDRSP vermeidet Synchronisationsprobleme für Sender und Empfänger, ist aber nur dann praktikabel, wenn qualitativ einwandfreie Daten ausgetauscht werden und eine hohe Lieferbereitschaft beim Lieferanten gegeben ist.
Wenn zusätzlich der ORDRSP ausgetauscht wird, sind weitere Einstellungen erforderlich. Zunächst sind im Programm KI10300R (EDI-Kommunikationsstandard verwalten) die Nachrichten ORDRSP eingehend bzw. ausgehend für den Partner zu aktivieren. Im Modul Einkauf ist festzulegen, ob ein ORDRSP erforderlich sein soll, bevor die Bestellung weiterverarbeitet werden kann (KI10200R zweite Lasche).
Im Modul Verkauf muss dem System mitgeteilt werden, ob in jedem Fall bei Eingang eines Auftrages eine Bestätigung in Form eines ORDRSP zu senden ist, oder nur im Fehlerfall (KI10200R (EDI-Wertesegmente) dritte Lasche). Dieser Parameter kann durch den Kunden durch Übermittlung einer abweichenden Bestätigungsart übersteuert werden.
Aus dem Modul Verkauf heraus können zwei Arten von ORDRSP gesendet werden. Zum einen werden automatisch ORDRSP generiert, wenn beim Verbuchen des ORDERS Fehler auftreten oder maschinelle Änderungen am Auftrag durchgeführt werden. Zum andern werden ORDRSP versendet, wenn bei einem EDI-Auftrag manuell EDI-relevante oder EDI-übertragene Felder geändert werden. Diese Option kann durch Eingabe einer maximalen Bearbeitungszeit für ORDRSP ausgehend (KI10300R (EDI-Kommunikationsstandard verwalten)) in Absprache mit dem EDI-Partner begrenzt werden.
Bei Verwendung von ORDERS, ORDRSP und ORDCHG muss die größte Sorgfalt auf die Synchronisation der verschiedenen Nachrichten gelegt werden. Es ist hier durch die Konfiguration Sorge zu tragen, dass die Nachrichten in der richtigen Reihenfolge verarbeitet werden.
Ein ORDCHG wird im Modul Einkauf in zwei Fällen ausgelöst. Einmal wird automatisch ein ORDCHG generiert, wenn ein eingehender ORDRSP nicht akzeptiert wird. Zum anderen wird nach manueller Veränderung von EDI-relevanten Feldern in der Bestellung ein ORDCHG an den Lieferanten geschickt.

ORDERS ausgehend

Da ausgehende EDI-Nachrichten vom Typ ORDER (Übertragung von Bestellungen) und ORDCHG (Übertragung von Bestelländerungen) über das gleiche Übertragungsprogramm generiert werden, wird in diesem Kapitel der prinzipielle Generierungsablauf für beide Nachrichtentypen beschrieben.
Im nachfolgenden Kapitel 'ORDCHG ausgehend' wird dann nur noch auf die Besonderheiten dieses Nachrichtentyps eingegangen.
Abhängig von der Einstellung des Parameters 'Ausgabe an EDI-Schnittstelle' der Vorlauftabelle VRLE32 (Vorlauftabelle für EDI im Einkauf) können die oxaion Schnittstellendateien EOERKP und EOERPP für die ausgehenden Nachrichtentypen ORDERS und ORDCHG entweder nur durch eine explizite Übertragungsanforderung (Aufrufprogramm EK20900R (Bestellungen an EDI-Schnittstelle übergeben); Übertragungsprogramm EK20901R (EDI-Schnittstelle füllen)) oder zusätzlich über den Belegdruck im Modul Einkauf (Aufrufprogramm EK20200R (Belege Einkauf drucken)) aus den Bestellangaben (Bestellkopfdatei EKOPFP und der Bestellpositionen-Datei EPSDAP) gefüllt werden.
Die Übertragung der Bestelldaten wird grundsätzlich in einem Übernahmeprotokoll und einem Fehlerprotokoll dokumentiert.
Über das Umsetzprogramm KI21100R (eingehende Bestellungen in VKS-Aufträge übernehmen) werden die ausgehenden Daten der oxaion Schnittstellendateien EOERKP und EOERPP dann in die zugehörigen Inhouse-Dateien übernommen. Damit wird der weitere EDI-Transfer eingeleitet. Eine erfolgreich umgesetzte Ausgangsnachricht wird automatisch aus diesen Schnittstellendateien entfernt.
Soll eine Übertragung der für den EDI-Versand vorgesehenen Bestellungen bzw. Bestelländerungen über den Belegdruck erfolgen, so ist über die Leitdatenangaben des Aufrufprogramms EK20200R (Belege Einkauf drucken) zunächst eine Selektion der Bestellungen vorzunehmen und nachfolgend in der Formularauswahlmaske (Programm US56100R (Allgemeines Formulardruck- und Auswahlprogramm)) die Übertragung per EDI durch die Druckauswahl für das 7. Formular explizit anzufordern (Aufruf von Übertragungsprogramm EK20901R (EDI-Schnittstelle füllen)).
Unabhängig von dieser Möglichkeit kann das Übertragungsprogramm EK20901R (EDI-Schnittstelle füllen) explizit über das Leitdatenprogramm EK20900R (Bestellungen an EDI-Schnittstelle übergeben) aufgerufen werden.

Mit diesem Programmaufruf können die Bestellungen belegnummern-, Sachbearbeiter- oder lieferantenbezogen für den EDI-Transfer selektiert werden.
Mit dem Übergabekennzeichen (Prüfung gegen Tabelle FRD020 (Druckauswahl für EDI)) wird festgelegt, welche ausgehenden Nachrichtentypen bei einem Übernahmelauf zu berücksichtigen sind. Es sind folgende Beschränkungen möglich:

1. Nur Nachrichten vom Typ ORDER an die oxaion Schnittstelle ausgeben
2. Nur Nachrichten vom Typ ORDCHG an die oxaion Schnittstelle ausgeben
3. Nachrichten vom Typ ORDER und ORDCHG an die oxaion Schnittstelle ausgeben
   Ob eine Bestellung bzw. eine Bestellposition beim Übertragungslauf für den ausgehenden EDI-Transfer vom Typ ORDER bzw. ORDCHG zu berücksichtigen ist, hängt von der Ausprägung spezieller Steuerungsparameter ab, die innerhalb der Bestellverwaltung gesetzt und bestellkopf- und bestellpositionenbezogen abgespeichert werden.
   So wird beim Erfassen bzw. Ändern einer Bestellung (Sammelkennzeichen 'E') über die Kommunikationsstammdaten geprüft, ob der angegebene Lieferant überhaupt am EDI-Transfer für ausgehende Nachrichten vom Typ ORDERS bzw. ORDCHG teilnimmt; aufgrund dieser Prüfung wird das Steuerungsfeld 'EDI-Transfer J/N' in der Bestellkopfdatei bzw. in der Bestellpositionendatei bedient.
   Nur wenn dieses Dateifeld mit der Ausprägung  belegt ist, steht eine Bestellung bzw. Bestellposition für den EDI-Transfer zur Verfügung.
   Bei erfolgreicher Übertragung der Bestellung wird dieses Steuerungsfeld auf Kopf- und Positionsebene wieder auf  zurückgesetzt; zusätzlich werden Datum und Uhrzeit der Übertragung abgespeichert.
   Innerhalb der Bestellverwaltung (EK20100R (Bestellungen)) kann über das verwaltbare Feld 'EDI-Transfer-Sperrkennzeichen' (Bestellkopf, dritte Lasche) eine Bestellung auch manuell vom EDI-Transfer (temporär) ausgeschlossen werden.
   Solange Ausgangsnachrichten vom Typ ORDER bzw. ORDCHG noch nicht aus den oxaion Schnittstellendateien EOERKP und EOERPP in die zugehörigen Inhouse-Dateien umgesetzt worden sind, werden bei Bestelländerungen keine neuen Ausgangsnachrichten generiert, sondern die betreffenden Schnittstellendatensätze aktualisiert.
   Jedoch kann in der Kennwortverwaltung über den Parameter 'Änderungsberechtigung Einkauf' (Programm MN10610R (Verwalten Kennwort-Datei)MN10610, Lasche Einkauf) die Berechtigung zur Änderung von bereits EDI-transferierten Bestellungen benutzerbezogen eingeschränkt werden.
   Weiterhin kann über die EDI-Kommunikationsstandardverwaltung pro Nachrichtentyp eine maximale Bearbeitungsdauer (in Stunden) angegeben werden (erste Lasche; Programm KI10311R (EDI-Kommunikations-Standard Positionen verwalten)), innerhalb der EDI-relevante Daten in einer Bestellung noch geändert werden dürfen.
   Innerhalb der EDI-Adresssegmentverwaltung (KI10200R (Verwalten EDI-Wertesegment)) wird über den Parameter 'Rabattpositionen' (zweite Lasche) pro Kommunikationspartner festgelegt, ob bei der Generierung von Ausgangsnachrichten vom Typ ORDER bzw. ORDCHG die in einer Bestellung gegebenenfalls erfassten Zu-/Abschläge als eigene Unterposition zu übertragen sind, oder ob der Transfer prinzipiell nur auf Hauptpositionsebene erfolgt und Zu-/Abschläge somit nur kumuliert über den Nettopreis und Nettowert der Bestellposition ausgewiesen werden.
   Bei einem Übertragungslauf (Programm EK20901R (EDI-Schnittstelle füllen)) wird grundsätzlich ein Fehlerprotokoll sowie ein Übernahmeprotokoll erstellt. Im Fehlerprotokoll sind die abgewiesenen Bestellungen bzw. Bestellpositionen aufgelistet, die vor dem nächsten Übertragungslauf überarbeitet werden sollten. Im Übernahmeprotokoll werden die in die Schnittstelle übertragenen Bestellungen mit den für den EDI-Transfer relevanten Bestellangaben aufgeführt.
   Über den Druckaufruf des' (Programms EK20950R (EDI-Bestellungen drucken)) kann weiterhin eine Liste erstellt werden, in der die für eine Übertragung per EDI anstehenden Bestellungen aufgeführt sind.
   
   Dateinamen:
   Inhousedatei KOERPP
   Archivdatei: KOERYP
   Schnittstellendateien:EOERKP
   EOERPP

ORDERS eingehend

ORDERS und ORDCHG werden von den gleichen Programmen mit einem Aufruf übernommen. Mit dem Programm KI22100R (eingehende Bestellungen in VKS-Aufträge übernehmen) werden die Daten von der Inhouse-Datei in die oxaion Schnittstelle übernommen. Abhängig vom ersten Parameter der Vorlauftabelle VRLV25 (EDI-Vorlauf Verkauf) kann von diesem Programm direkt die Übertragung in die oxaion Auftragsdatei VK21901R (Verbuchen VKS-EDI Schnittstelle Aufträge) aufgerufen werden.
Zur manuellen Übertragung stehen zwei Methoden zur Auswahl. Entweder durch das Übernahmeprogramm VK21900R (Aufrufprogramm VK21920R) oder über die Auftragsschnittstelle/ Auftragsschnellerfassung.
Andernfalls kann dieses Programm mit dem Aufrufprogramm VK21900R (Aufrufprogramm VK21920R) aufgerufen werden.

Mit diesem Programm ist es möglich, alle ORDERS/ORDCHG für eine Firma zu übernehmen (keine Eingabe), oder dies für einen bestimmten Kunden oder einen bestimmten Auftrag zu tun.
Bei der zweiten Möglichkeit über die Auftragsschnellerfassung werden die Aufträge einzeln verbucht.


Dabei können die Aufträge drei verschiedene Status annehmen:
N:Nicht verbucht
F: Fehler bei der Verbuchung, nicht verbucht
J: Verbucht.
Bei einer fehlerhaften Verbuchung kann der Auftrag erneut freigegeben werden. Allerdings sollte vorher der Fehler korrigiert werden. Die Verbuchung erfolgt über die Transaktion Auftrag verbuchen.


Treten bei der Übernahme Fehler auf, werden entsprechende Mailboxnachrichten erzeugt. Am Ende wird das Mailboxdruckprogramm aufgerufen, die erzeugten Fehlermeldungen werden gedruckt.

Eine sinnvolle Selektion auf der Mailbox ist auf das zentrale Sendeprogramm VK21901R (Abrufaufträge auflisten) zu selektieren.
Für die Übertragung des ORDERS in die Auftragsdatei von oxaion darf der Auftrag noch nicht existieren. Mit dem Verbuchungsprogramm VK21901R (Verbuchen VKS-EDI Schnittstelle Aufträge) werden die Daten auf Plausibilität untersucht. Es werden dabei nahezu die gleichen Prüfungen wie in der Auftragspositionsverwaltung durchgeführt. Es gibt jedoch Besonderheiten.
So wird in der Verfügbarkeitsprüfung auf mangelnde Verfügbarkeit flexibel reagiert, entsprechend des in den Stammdaten (KI10200R (VKS-Bestellantworten (ORDRSP) in INHOUSE-D. übern.), dritte Lasche) für den Partner hinterlegten Verfahrens.

1. Wenn die gewünschten Mengen nur teilweise oder gar nicht verfügbar sind, wird die gesamte Position abgelehnt.
2. Das Lieferdatum für die gesamte Position wird auf den Termin geändert, an dem frühestens die Gesamtmenge geliefert werden kann.
3. Wenn eine Teilmenge zu dem gewünschten Termin lieferbar ist, wird nur diese Teilmenge akzeptiert; die Restmenge wird abgelehnt.

Es wird, unabhängig davon, ob Preise und Konditionen vom Partner gesendet worden sind, die oxaion eigene Preis- und Konditionenfindung durchgeführt. Die so ermittelten Preise und Konditionen werden auch für den oxaion Auftrag verwendet. Die übermittelten Preise und Konditionen werden lediglich zur Preisprüfung verwendet, falls diese für den Partner eingeschaltet ist.
Bei der Preisprüfung wird der Nettowert der oxaion Position (resultierend aus selbst ermitteltem Preis und den oxaion Konditionen) mit dem übermittelten oder errechneten (bestimmt aus übermittelten Bruttowert und Konditionen) Nettowert verglichen. Ist die prozentuale Differenz zwischen beiden Nettowerten größer als der in den Stammdaten (KI10200R (Verwalten EDI-Wertesegment), erste Lasche) für den Partner angegebene Wert, wird die Position abgelehnt.
Mit der Angabe von 0% als maximaler Preisdifferenz in den Stammdaten für den Partner wird die Preisprüfung ausgeschaltet.
Es können zwei Sonderfälle auftreten. Zum einen könnte der Partner keinen Preis gesendet haben. In diesem Fall wird der von oxaion ermittelte Nettopreis bedingungslos akzeptiert, es wird jedoch an den Partner (falls vorgesehen) ein ORDRSP mit dem ermittelten Preis geschickt.
Wenn oxaion keinen Wert ermitteln konnte, dieser jedoch vom Partner gesendet wurde, so wird letzterer für die Auftragsposition verwendet. In diesem Fall wird jedoch eine Meldung in die Mailbox gestellt.
Wenn alle Positionen eines ORDERS aus den unterschiedlichsten Gründen abgelehnt werden, wird auch der zugehörige Auftragskopf nicht in oxaion angelegt.
Gleichfalls wird ein Auftrag dann nicht angelegt, wenn der Mindestauftragswert laut Kundenstamm oder Kennwort des Sachbearbeiters nicht erreicht wird.
Führt die Kreditprüfung zu einem negativen Ergebnis, wird der Auftrag zunächst akzeptiert. Er wird jedoch in den Sperrstatus '97' gestellt, als wäre er von Hand erfasst.
Falls durch das Kennzeichen 'Komplettlieferung' im Kundenstamm für den Partner Komplettlieferung gefordert wird, werden alle Auftragspositionen auf das späteste Lieferdatum im Auftrag umterminiert.
Wenn durch die Vorlauftabelle VRLV25 (EDI-Vorlauf Verkauf) gefordert, wird zum Abschluss des Verbuchungslaufes automatisch ein Protokoll aller EDI-Aufträge gedruckt, die bisher zwar verbucht aber noch nicht auf dem Protokoll aufgelistet worden sind. Dieses Druckprogramm (VK21960R) kann auch separat aufgerufen werden.
Dateinamen:
Inhousedatei KOERGP
Archivdatei: KOERXP
Schnittstellendateien:VOERKP
VOERPP

ORDCHG ausgehend

Die Vorgehensweise zur Generierung von Ausgangsnachrichten vom Typ ORDCHG (Übertragung von Bestelländerungen) über das Übertragungsprogramm EK20901R (EDI-Schnittstelle füllen) wurde bereits im Kapitel 'ORDERS ausgehend' beschrieben. In diesem Kapitel soll daher nur noch auf die Besonderheiten dieses Nachrichtentyps eingegangen werden.
Einkaufseitig können Ausgangsnachrichten vom Typ ORDCHG ausgelöst werden, falls entweder in einer bereits transferierten Bestellung nachträglich EDI-relevante Bestellangaben geändert werden oder falls eine eingehende Bestellbestätigung (Nachrichtentyp ORDRSP) trotz Abweichungen zur ursprünglich transferierten Bestellung akzeptiert wird.
Über die Kommunikationsstammdaten wird festgelegt, ob mit einem Lieferanten überhaupt Nachrichten vom Typ ORDCHG ausgetauscht werden.
Sofern nur über ORDER-Nachrichten kommuniziert wird, sollte dafür Sorge getragen werden, dass Bestellungen nach dem EDI-Transfer nicht mehr geändert werden können bzw. dass Bestelländerungen dem Lieferanten auf anderem Wege mitgeteilt werden.
Die Möglichkeit zur Änderung von EDI-transferierten Bestellungen kann auf unterschiedliche Weise eingeschränkt werden.

• Über den Tabellenparameter 'Änderung Bestellung erlaubt' in der Vorlauftabelle des Moduls Einkauf VRLE32 kann benutzer- und lieferantenunabhängig gesteuert werden, ob die Änderung von 'EDI-relevanten' Bestellangaben für eine bereits per EDI übertragene Bestellung zulässig ist. Welche Bestellkopf- bzw. Bestellpositionenangaben als 'EDI-relevant' gelten, ist über die beiden Datenstrukturen EKDSKERLF (Bestellkopffelder) und EKDSPERLF (Bestellpositionenfelder) festgelegt.
• In der EDI-Adresssegmentverwaltung (KI10200R (Verwalten EDI-Wertesegment)) wird über den Parameter 'EDI-relevante Felder ändern' (zweite Lasche, Einkaufsspezifische Daten) pro Lieferant festgelegt, ob in einer EDI-transferierten Bestellung nachträglich 'EDI-relevante' Bestellangaben geändert werden dürfen.
• In der EDI-Adresssegmentverwaltung (KI10200R (Verwalten EDI-Wertesegment)) kann über den Parameter 'ORDERSP im Modul EKS notwendig' (zweite Lasche) angegeben werden, dass eine Bestellung erst weiterverarbeitet bzw. geändert werden kann, falls der Lieferant die Bestellung bestätigt hat.
• In der Kennwortverwaltung kann über den Parameter 'Änderungsberechtigung Einkauf' (Programm MN10610R (Verwalten Kennwort-Datei), Lasche Einkauf) die Berechtigung zur Änderung von EDI-transferierten Bestellungen benutzerbezogen eingeschränkt werden.
• Über die EDI-Kommunikationsstandardverwaltung (Programm KI10300R (EDI-Kommunikationsstandard verwalten)) kann weiterhin für den Nachrichtentyp ORDCHG eine maximale Bearbeitungsdauer (in Stunden) angegeben werden (erste Lasche; Programm KI10311R (EDI-Kommunikations-Standard Positionen verwalten)), innerhalb der Änderungen von EDI-relevanten Daten in einer Bestellung noch zulässig sind.

ORDCHG eingehend

Hier werden die gleichen Prüfungen wie bei der Verbuchung des ORDERS durchgeführt. Zusätzlich müssen aber noch weitere Bedingungen erfüllt sein.
So dürfen für den betreffenden Auftrag keine Übertragungen eines ORDRSP anstehen, in diesem Fall würde die Verbuchung des ORDCHG so lange zurückgestellt werden, bis die betreffenden ORDRSP gesendet worden sind.
Eine weitere Bedingung für die Verarbeitung des ORDCHG ist, dass auf den betreffenden Auftrag noch keine Lieferungen oder Kommissionierungen erfolgt sind. Natürlich darf auch die im EDI-Kommunikationsstandard festgelegte maximale Zeitspanne zwischen ORDERS und ORDCHG noch nicht verstrichen sein. Dies wird jedoch schon im vorgeschalteten Programm KI22100R (eingehende Bestellungen in VKS-Aufträge übernehmen) geprüft.
Dagegen ist das Vorhandensein des dem ORDCHG zugrundeliegenden Auftrages in oxaion für die Verbuchung des ORDCHG nicht unbedingt erforderlich. Wenn der ORDCHG die nötigen Daten für die Anlage des Auftrages enthält, wird der zugehörige Auftrag in diesem Fall neu angelegt.
Bevor die ORDCHG-Sätze verbucht werden, wird automatisch (wenn in der Vorlauftabelle VRLV25 (EDI-Vorlauf Verkauf) eingestellt) ein Protokoll über die bevorstehenden Änderungen gedruckt. Das Protokoll kann auch separat, solange der ORDCHG noch nicht verbucht ist, gedruckt werden. Dazu ist das Programm VK21950R (Abweichungen zwischen ORDCHG und Auftrag drucken) zu verwenden.

Entsprechend der obigen Aufrufmaske des Programms VK21950R (Abweichungen zwischen ORDCHG und Auftrag drucken) kann ein Abgleich auftrags- bzw. kundenbezogen durchgeführt werden. Werden keine Angaben vorgenommen, werden alle in den oxaion Schnittstellen VOERKP/VOERPP befindlichen ORDCHG für eine Abweichungsuntersuchung herangezogen.

ORDRSP ausgehend

Generelle Voraussetzung für das Senden eines ORDRSP ist, dass der Partner am ORDRSP teilnimmt.
Wie bereits im vorangegangenen Abschnitt beschrieben, wird die Nachricht ORDRSP bei der Übernahme eines ORDERS/ORDCHG in oxaion automatisch generiert, wenn beim Verbuchen des ORDERS Fehler auftreten, bei der Übernahme maschinelle Änderungen an dem Auftrag durchgeführt wurden oder der Partner generell einen ORDRSP als Reaktion auf einen ORDERS/ORDCHG verlangt (KI10200R (Verwalten EDI-Wertesegment), dritte Lasche). Zum andern werden ORDRSP versendet, wenn bei einem EDI-Auftrag manuell EDI-relevante oder EDI-übertragene Felder geändert werden.
Letzteres geschieht, indem der Auftrag bei Änderung EDI-relevanter oder EDI-übertragener Felder ein Kennzeichen bekommt (KOEDJN='J'). Im Folgenden heißen solche Aufträge 'zu Transfer anstehende Aufträge'. In Maske 16 der Auftragsverwaltung kann ein zum Transfer anstehender Auftrag vorübergehend für den EDI-Transfer gesperrt werden. Dazu wird das entsprechende Sperrkennzeichen (KOEKZS) auf 'J' gesetzt. Die ORDRSP werden mit dem Programm VK21910R (oxaion Schnittstelle füllen (ORDRSP) erzeugt.

Grundsätzlich überträgt das Programm nur EDI-generierte Aufträge (KOEDGN='J'), die weder gesperrt sind (KOSTAT='') noch für den EDI-Transfer gesperrt sind (KOEKZS='N'). Steht ein Auftrag zum Transfer an, ist aber für den Transfer gesperrt, wird eine Mailboxnachricht ausgegeben. Abhängig von den Aufrufparametern werden ORDRSP für folgende Aufträge übertragen:

• Keine Eingabe oder Eingabe eines Sachbearbeiters: Alle zum Transfer anstehenden Aufträge (des Sachbearbeiters)
• Eingabe einer Auftragsnummer
• Übertragung des Auftrages, wenn er die zuvor genannten Voraussetzungen erfüllt, auch wenn er nicht zum Transfer ansteht.

Nach der Ausgabe eines ORDRSP wird das Kennzeichen KOEDJN mit 'N' belegt, der entsprechende Auftrag steht nicht mehr zum Transfer an.
Um Synchronisationsprobleme zu vermeiden, darf zu jedem Auftrag nur ein ORDRSP in der oxaion Schnittstelle VORSKP und VORSPP stehen. Soll zu einem Auftrag, zu dem bereits ein ORDRSP in der oxaion Schnittstelle steht, ein neuer ORDRSP übertragen werden, so wird eine Fehlermeldung in die Mailbox ausgegeben. Der ORDRSP kann erst ausgegeben werden, wenn der vorhergehende ORDRSP von Umsetzprogramm KI21200R (VKS-Bestellantworten (ORDRSP) in INHOUSE-D. übern.) verarbeitet worden ist.

Dateinamen:
Inhousedatei KORSPP
Archivdatei: KORSYP
Schnittstellendateien:EORSKP
EORSPP

ORDRSP eingehend

Die vom Lieferanten per EDI versendeten Bestellantworten sind als Nachrichten vom Typ ORDRSP eingegangen und werden über das Umsetzprogramm KI22200R (eingehende Bestellbestätigungen(ORDRSP) übernehmen) aus der INHOUSE-Datei KORSGP in die oxaion Schnittstellendateien EORSKP und EORSPP übertragen.
Über das im nachfolgenden Kapitel beschriebene Schnittstellenverwaltungsprogramm EK20920R (Einstieg Bestellantwortkopfdaten verwalten) können die eingegangenen Bestellantwortendaten vor einer Übernahme in die zugehörigen Bestellungen nochmals angezeigt, kontrolliert und ggfs. von der Übernahme manuell ausgeschlossen werden.
Nach der Kontrolle der Bestellantwortdaten wird über das Programm EK20910R ('Bestellantworten (ORDRSP) übernehmen)) die Verarbeitung und Übernahme der freigegebenen Bestellantworten ausgelöst.
Der Übernahmelauf für die Bestellantworten kann entweder im Prüfmodus oder im Aktualisierungsmodus aufgerufen werden.
Die Modus-Auswahl stellt auch die einzigen Selektionsmöglichkeiten in der Leitdatenmaske dar.
Unabhängig vom ausgewählten Modus wird der Übernahmelauf über ein Fehlerprotokoll und ein Übertragungsprotokoll dokumentiert.
Im Prüfmodus werden die zur Übernahme freigegebenen Bestellantwortdaten gegen die zugehörigen Bestelldaten anhand der im Kommunikationsstamm hinterlegten Steuerungsparameter lediglich abgeglichen.
In einem Fehlerprotokoll werden Unstimmigkeiten festgehalten, die eine Bestellantwortübernahme bei einem Echtlauf verhindern würden. Insbesondere wird ein Hinweis ausgegeben, falls eine Bestellposition bzw. eine komplette Bestellung bei einem nachfolgenden Aktualisierungslauf gelöscht werden würde, da die zugehörige Bestellantwort anzeigt, dass der Lieferant die Bestellung / Bestellposition nicht akzeptiert hat.
Im Übertragungsprotokoll werden die Bestellantwortdaten ausgewiesen, die bei einem Echtlauf in die zugehörige Bestellung übertragen werden.
Aufgrund dieser Protokolle können die Bestellantworten in der Eingangsschnittstelle nochmals überarbeitet werden (z.B. Sperren/Löschen bestimmter Bestellantworten).
Im Aktualisierungsmodus werden für die freigegebenen Bestellantwortdaten folgende Aktionen durchgeführt:

• Sofern im EDI-Kommunikationsstandard (Programm KI10300R) für einen Lieferanten kein EDI-Transfer für eingehende ORDRSP-Nachrichten aktiviert ist, werden die zugehörigen Bestellantworten in der oxaion Schnittstelle gesperrt und mit einer Fehlermeldung gekennzeichnet.
• Hat gemäß den Angaben in der Bestellantwort ein Lieferant eine Bestellung nicht akzeptiert, wird die komplette Bestellung gelöscht.
• Hat gemäß den Angaben in der Bestellantwort ein Lieferant einzelne Bestellpositionen nicht akzeptiert, werden diese Bestellpositionen ggfs. gelöscht.
• Sofern eine Bestellposition nicht als EDI-transferiert bzw. inzwischen als erledigt gekennzeichnet ist, wird die zugehörige Bestellantwort in der oxaion Schnittstelle gesperrt und mit einer Fehlermeldung versehen.
• Vergleich der Bestellangaben mit den Angaben in der eingegangenen Bestellantwort. Hierbei werden die Angaben zur Artikelnummer, Bestellmenge, Bestellmengeneinheit, Bruttopreis, Preismengeneinheit, Lieferwoche, Lieferdatum, Zahlungsbedingungen, abweichender Lieferanschrift und abweichender Rechnungsanschrift auf Übereinstimmung geprüft. Die Nettopreisangaben können innerhalb der im EDI-Adresssegment hinterlegbaren maximalen Preisabweichung (erste Lasche, Programm KI10200R (Verwalten EDI-Wertesegment)) variieren.
• Bei aufgetretenen Abweichungen hängt eine Übernahme der Bestellantwortdaten von der Einstellung des Parameters 'Bestätigung mit Abweichung verbuchen' in der Vorlauftabelle VRLE32 ab.
• Wird eine Bestellantwort ohne/mit Abweichung akzeptiert, so werden in der zugehörigen Bestellung auf Kopfebene folgende Felder aus den Bestellantwortdaten aktualisiert: Bestätigungsdatum, Bestätigungsnummer, Angebotsdatum, Liefertermin, Lieferbedingung, Versandart, Verpackungsart und Zahlungsbedingung.
• Auf Positionsebene werden folgende Felder aus den Bestellantwortdaten aktualisiert: Bestätigungsdatum, Bestätigungsnummer, Lieferwoche, Lieferdatum, Versandart und Verpackungsart.
• Mengenänderungen werden abhängig von Parameter 10 der Vorlauftabelle VRLE32 (Vorlauftab. für EDI im Einkauf) übernommen.
• Falls für eine Bestellung eine Übernahme abweichender Bestellantwortdaten erfolgte, wird diese Bestellung zur Kennzeichnung für die weitere Verarbeitung gesperrt. Die Sperre kann innerhalb der Bestellverwaltung wieder aufgehoben werden.
• Übernommene Bestellantwortdaten werden abhängig von der Einstellung des Parameters 'Schnittstelle löschen' in der Vorlauftabelle VRLE32 (Vorlauftab. für EDI im Einkauf) entweder aus der oxaion Schnittstelle entfernt oder mit einem Konvertierungskennzeichen als übernommen markiert. Bisher werden Abweichungen in den nachfolgenden positionsbezogenen Bestellantwortdaten nicht automatisch in die Bestellpositionen übertragen: Artikelnummer, Bestellmengeneinheit, Bruttopreis, Nettopreis, Preismengeneinheit, abweichende Lieferanschrift und abweichende Rechnungsanschrift.
  Aus diesem Grund empfiehlt es sich, die oxaion Schnittstellendaten nicht automatisch nach der Übertragung zu löschen, um die Abweichungen ggfs. manuell in die jeweilige Bestellung übertragen zu können.
  Dateinamen:
  Inhousedatei KORSGP
  Archivdatei: KORSXP
  Schnittstellendateien:VORSKP
  VORSPP
   

ORDRSP Schnittstellenverwaltung

Das Programm EK20920R (Bestellantwortdaten verwalten) dient dazu, die eingehenden Bestellantworten der Lieferanten zu überwachen. Vor einer Übernahme der Bestellantworten kann somit kontrolliert werden, ob der Lieferant die Bestellangaben der ursprünglich versendeten Bestellung mit/ohne Abweichungen bestätigt, oder ob die Bestellung evtl. nicht akzeptiert wird.

Die Bestellantwortdaten sind als Nachrichten vom Typ ORDRSP eingegangen und in den oxaion Schnittstellendateien EORSKP und EORSPP kopf- und positionsbezogen abgespeichert.
Über den Tabellenparameter 'Schnittstelle Bestellantwortdaten verwaltbar' der Vorlauftabelle VRLE32 (Vorlauftab. für EDI im Einkauf) kann gesteuert werden, ob ein Aufruf des Schnittstellenverwaltungsprogramms EK20920R zur Kontrolle und Verwaltung der Bestellantwortdaten überhaupt zulässig ist.
In einem Explorer werden alle Bestellantworten aufgelistet. Sind Positionen vorhanden, können diese durch Aufklappen des entsprechenden Symbols angezeigt werden.
Bestellantworten können freigegeben, gesperrt, angezeigt, gelöscht und verwaltet werden.
Abhängig vom Tabellenparameter 'Schnittstelle löschen' der Vorlauftabelle VRLE32 (Vorlauftab. für EDI im Einkauf) werden die übernommenen bzw. verarbeiteten Bestellantwortdaten beim Übernahmelauf in den oxaion Schnittstellendateien EORSKP und EORSPP entweder entfernt oder lediglich mit einem Konvertierungskennzeichen markiert.

Nachricht Lieferavis (DESADV)

Um die Nachricht DESADV mittels EDIFACT und dem hier beschriebenen Modul zu versenden oder zu empfangen, ist es zunächst notwendig, dass der betreffende Kunde für die ausgehende Nachricht bzw. der betreffende Lieferant für die eingehende Nachricht zugelassen ist.
Dazu ist für die entsprechende Personenkontonummer mittels des Programms KI10300R (EDI-Kommunikationsstandard verwalten) je ein Satz für die ausgehende und für die eingehende Nachricht DESADV zu erfassen. Dabei ist der Parameter 'Nachricht aktiv' mit  zu belegen. Soll der Partner temporär für die Übertragung des DESADV gesperrt werden, genügt es, diesen Parameter auf zu stellen.

DESADV ausgehend

Nachfolgende Programme sind für das Senden des Lieferavis verantwortlich:

• VK23900R (DESADV Aufruf : Füllen oxaion-Schnittstellendatei)
• VK23901R (Füllen EDI Schnittstelle Lieferschein (DESADV))
• KI21300R (av. Wareneingänge (ausgehend) (DESADV) in INHOUSE)

Werden mit einem Partner DESADV ausgetauscht (entsprechender Satz im Kommunikationsstandard), so wird für jeden erzeugten Lieferschein ein DESADV versendet, d.h. die Kennzeichen 'EDI-generiert' (EDGN) und 'zum Transfer anstehend' (EDJN) werden bei Erstellung eines neuen Lieferscheins auf 'J' gesetzt.
Der DESADV kann abhängig von dem entsprechenden Vorlaufparameter in der Tabelle VRLV25 (EDI-Vorlauf Verkauf) entweder beim Lieferscheindruck oder beim Rechnungsdruck erstellt werden. Dabei wird der DESADV jeweils nur beim Originaldruck ausgegeben.
Wird ein bereits gedruckter Lieferschein noch einmal geändert und nochmals im Original gedruckt, so wird beim Entfernen des Druckkennzeichens auch das Kennzeichen 'zum Transfer anstehend' wieder auf 'J' gesetzt. Beim wiederholten Originaldruck wird der DESADV erneut ausgegeben. Befand sich der alte DESADV noch in der oxaion Schnittstelle, so wird er gelöscht und durch den neuen ersetzt.
Die Lieferscheindatei enthält auch ein Sperrkennzeichen für den EDI-Transfer (EKZS). Dieses Kennzeichen wird vom Programm VK23901R (Füllen EDI Schnittstelle Lieferschein (DESADV)) abgefragt (gesperrte Sätze werden nicht übertragen), es ist aber im Standard nicht möglich, einen Lieferschein für die EDI-Übertragung zu sperren. Diese Funktionalität sollte eigentlich auch nicht benötigt werden, da Lieferscheine im Gegensatz zu ORDRSP nicht asynchron, sondern beim Lieferscheinoriginaldruck versendet werden. Sollte sie dennoch benötigt werden, lässt sie sich einfach einfügen.
Wird eine separate Übertragung in die Schnittstellendateien gewünscht, so steht dem Nutzer das Programm VK23900R (DESADV Aufruf : Füllen oxaion-Schnittstellendatei) zur Verfügung:

Durch die Angabe einer Lieferscheinnummer bzw. einer Rechnungsnummer gibt der Nutzer an, für welchen Beleg eine Lieferscheinankündigung erfolgen soll. Mit diesem Programm kann ein bereits versendeter DESADV erneut erzeugt werden, ohne den Lieferschein erneut im Original zu drucken.
Dateinamen:
Inhousedatei KDADPP
Archivdatei: KDADYP
Schnittstellendateien:VDADKP
VDADPP

DESADV eingehend

Die vom Lieferanten per EDI versendeten Lieferankündigungen (Avisierungen) sind als Nachrichten vom Typ DESADV eingegangen und werden über das Umsetzprogramm KI22300R aus der Inhouse-Datei KDADGP in die oxaion Schnittstellendateien EDADKP und EDADPP übertragen.
Über das im nachfolgenden Kapitel beschriebene Schnittstellenverwaltungsprogramm EK22910R (Einstieg Avisierte Wareneingänge verwalten) können die eingegangenen Lieferavisierungsdaten vor einer Übernahme in das eigene System nochmals angezeigt, kontrolliert und ggfs. von der Übernahme manuell ausgeschlossen werden.
Nach der Datenkontrolle wird über das Programm 'Avisierte Wareneingänge (DESADV) übernehmen' (Programmaufruf EK22900R (Avisierte Wareneingänge in oxaion übertragen)) die Verarbeitung und Übernahme der freigegebenen Lieferankündigungen ausgelöst.
Der Übernahmelauf für die avisierten Wareneingänge kann entweder im Prüfmodus oder im Aktualisierungsmodus aufgerufen werden.
Die Modusauswahl stellt auch die einzigen Selektionsmöglichkeiten in der Leitdatenmaske dar.
Unabhängig vom ausgewählten Modus wird der Übernahmelauf über ein Fehlerprotokoll und ein Übertragungsprotokoll dokumentiert.
Im Prüfmodus werden die zur Übernahme freigegebenen Bestellantwortdaten gegen die zugehörigen Bestelldaten anhand der im Kommunikationsstamm hinterlegten Steuerungsparameter lediglich abgeglichen.
In einem Fehlerprotokoll werden Unstimmigkeiten festgehalten, die eine Generierung der avisierten Wareneingänge bei einem Echtlauf verhindern würden.
Im Übertragungsprotokoll werden die Lieferankündigungen ausgewiesen, für die bei einem Echtlauf avisierte Wareneingänge im System erzeugt würden.
Aufgrund dieser Protokolle können die Lieferankündigungsdaten in der Eingangsschnittstelle nochmals überarbeitet werden (z.B. Sperren bestimmter Lieferankündigungen).
Im Aktualisierungsmodus werden für die freigegebenen Lieferankündigungen folgende Aktionen durchgeführt:

• Sofern im EDI-Kommunikationsstandard (Programm KI10300R (EDI-Kommunikationsstandard verwalten)) für einen Lieferanten kein EDI-Transfer für eingehende ORDRSP-Nachrichten aktiviert ist, werden die zugehörigen Lieferankündigungen in der oxaion Schnittstelle gesperrt und mit einer Fehlermeldung gekennzeichnet.
• Ist die zu einer Lieferankündigung gehörende Bestellung nicht vorhanden oder mit einem Sperrkennzeichen versehen, so wird die Lieferankündigung in der oxaion Schnittstelle ebenfalls gesperrt und mit einer Fehlermeldung gekennzeichnet.
• Überprüfung der Lieferavisierungsangaben und Vergleich mit den Bestellangaben nach festgelegten Prüfkriterien.
• Generierung des avisierten Wareneingangs, sofern keine Abweichungen aufgetreten sind.
• Verbuchung der generierten Wareneingangspositionen im System (Fortschreiben avisierter Bestand).
• Positionsbezogene Lieferavisierungen, bei denen die zugehörige Bestellposition als teilgeliefert bzw. als erledigt gekennzeichnet ist, werden in der oxaion Schnittstelle für die Übernahme gesperrt und mit einer Fehlermeldung versehen.
• Übernommene Lieferavisierungsdaten werden, abhängig von der Einstellung des Parameters 'Schnittstelle löschen', in der Vorlauftabelle VRLE32 (Vorlauftab. für EDI im Einkauf) entweder aus der oxaion Schnittstelle entfernt oder mit einem Konvertierungskennzeichen als übernommen markiert.Nach erfolgter Lieferung muss der Wareneingang manuell in das System eingegeben werden, indem auf den ursprünglich generierten avisierten Wareneingang referenziert wird. Die Positionsangaben sind mit der tatsächlichen Lieferung abzugleichen und ggfs. zu korrigieren.
  Dateinamen:
  Inhousedatei KDADGP
  Archivdatei: KDADXP
  Schnittstellendateien:EDADKP
  EDADPP
   

DESADV Schnittstellenverwaltung

Das Programm EK22910R (Avisierte Wareneingänge verwalten) dient dazu, die über EDI eingehenden Lieferavisierungen der Lieferanten zu überwachen. Vor einer Übernahme der Lieferavisierungen in das System können somit die Avisierungsdaten kontrolliert und ggfs. für den Übernahmelauf gesperrt werden.

Die Lieferavisierungsdaten sind als Nachrichten vom Typ DESADV eingegangen und in den oxaion Schnittstellendateien EDADKP und EDADPP kopf- und positionsbezogen abgespeichert.
Über den Tabellenparameter 'Schnittstelle Wareneingang verwaltbar' der Vorlauftabelle VRLE32 (Vorlauftab. für EDI im Einkauf) kann gesteuert werden, ob ein Aufruf des Schnittstellenverwaltungsprogramm EK22910R zur Kontrolle und Verwaltung der Lieferavisierungsdaten überhaupt zulässig ist.
In der Selektionsmaske lassen sich die zu kontrollierenden Daten über Angaben zur Lieferantennummer, Wareneingangsnummer oder Bestellnummer eingrenzen.
Zur Überwachung steht eine Übersichtsmaske zur Verfügung, in der die Avisierungsdaten positionsgenau aufgelistet sind.
Folgende Aktionen sind aus der Auflistung der Daten heraus möglich:

• Kopfbezogene Verwaltung eines Freigabekennzeichens, über das die Übernahme der Lieferavisierungsdaten in das System gesperrt bzw. freigegeben werden kann. Eine Änderung des Freigabekennzeichens wird automatisch in die zugehörigen Positionsdaten durchgeschrieben.
• Detailanzeige der Positionsdaten (Artikelnummer, Avisierungsmenge, ggfs. Chargendaten)
• Informationsanzeige über evtl. aufgetretene Konvertierungsfehler sowie über den Konvertierungsstatus (Bestellantwort wurde bereits in die zugehörige Bestellung konvertiert).

Abhängig vom Tabellenparameter 'Schnittstelle löschen' der Vorlauftabelle VRLE32 (Vorlauftab. für EDI im Einkauf) werden die übernommenen bzw. verarbeiteten Lieferavisierungsdaten beim Übernahmelauf in den oxaion Schnittstellendateien EDADKP und EDADPP entweder entfernt oder lediglich mit einem Konvertierungskennzeichen als übernommen markiert.

Nachricht Rechnung (INVOIC)

Um die Nachricht INVOIC mittels EDIFACT und dem hier beschriebenen Modul zu versenden oder zu empfangen, ist es zunächst notwendig, dass der betreffende Kunde für die ausgehende Nachricht bzw. der betreffende Lieferant für die eingehende Nachricht zugelassen ist. Dazu ist für die entsprechende Personenkontonummer mit dem Programm KI10300R (EDI-Kommunikationsstandard verwalten' je ein Satz für die ausgehende oder für die eingehende Nachricht INVOIC zu erfassen. Dabei ist der Parameter 'Nachricht aktiv' mit  zu belegen. Soll der Partner temporär für die Übertragung des INVOIC gesperrt werden, genügt es, diesen Parameter auf zu drehen.

INVOIC ausgehend

Nachfolgende Programme sind für die Behandlung des Nachrichtentyps INVOIC innerhalb des EDI-Kommunikations-Moduls verantwortlich:

• VK24900R (INVOIC Aufruf : Füllen oxaion-Schnittstellendatei)
• VK24901R (Übernahme Rechnungen in EDI)
• KI21400R (Ausg. Einzelrechnungen (INVOICE) in INHOUSE-Datei)

Werden mit einem Partner INVOIC ausgetauscht (entsprechender Satz im Kommunikationsstandard), so wird für jede erzeugte Rechnung ein INVOIC versendet, d.h. die Kennzeichen 'EDI-generiert' (EDGN) und 'zum Transfer anstehend' (EDJN) werden bei Erstellung einer neuen Rechnung auf 'J' gesetzt.
Der INVOIC kann, abhängig von dem entsprechenden Vorlaufparameter in Tabelle VRLV25 (EDI-Vorlauf Verkauf), entweder bei der Rechnungserstellung oder bei der Rechnungsübergabe in die Finanzbuchhaltung erstellt werden.
Wird eine bereits bestehende und per EDI übertragene Rechnung neu erstellt, wird sie per EDI nicht erneut übertragen. Es ist aber möglich, sie mit dem Programm VK24900R (INVOIC Aufruf : Füllen oxaion-Schnittstellendatei) erneut zu übertragen.

Durch die Angabe einer Rechnungsnummer gibt der Benutzer an, für welchen Beleg eine Übertragung der Rechnungsdaten erfolgen soll. Die Rechnung wird in die Schnittstellendateien übertragen, sofern sie EDI-generiert ist und der Partner am EDI teilnimmt, unabhängig davon, ob sie bereits übertragen wurde oder nicht.
Dateinamen:
Inhousedatei KIOIPP
Archivdatei: KIOIYP
Schnittstellendateien:VIOIKP
VIOIPP

INVOIC eingehend

Eine Übernahme eingegangener Nachrichten des Nachrichtentyps INVOIC aus der Schnittstelle in den oxaion Datenbestand erfolgt mittels der Programme EK23900R (Rechnungen in oxaion übertragen) und EK23901R (Übernahme Rechnungen in oxaion).
Die per EDI übertragenen Daten aus der Schnittstelle werden zunächst nach festgelegten Prüfkriterien auf ihre Korrektheit überprüft. In Abhängigkeit vom Ergebnis der durchgeführten Prüfungen werden dann anhand der eingegangenen Daten oxaion interne Rechnungen erstellt.

Dabei sind abweisende und nicht abweisende Prüfbedingungen zu unterscheiden. Im ersten Fall erstellt das Übernahmeprogramm bei einem Fehler keine Eingangsrechnung. Handelt es sich hingegen um eine nicht abweisende Prüfung, so wird die Rechnung trotzdem erstellt. Die generierte Rechnung erhält dann eine Kennzeichnung und ist damit für die Übergabe an die Finanzbuchhaltung gesperrt. Sie muss manuell bearbeitet und gegebenenfalls korrigiert werden und kann erst übergeben werden, nachdem sie zuvor explizit entsperrt wurde.
In bestimmten Fällen kann ein festgestellter Fehler unter Heranziehung interner Daten bereits vom Programm korrigiert werden. Auch dann erhält die Rechnung das Sperrkennzeichen und sollte unbedingt sorgfältig überprüft werden, bevor sie für die Übergabe an die Finanzbuchhaltung freigegeben wird. Anhand der Prüfprotokolle können alle diese Fälle jederzeit nachvollzogen werden. Erstellte Eingangsrechnungen, zu denen auf dem Fehlerprotokoll Fehler oder Hinweise ausgewiesen werden, sind also generell nachzubearbeiten und anschließend zu entsperren.
Das Übernahmeprogramm kann sowohl im Prüf- als auch im Echtlaufmodus ausgeführt werden. In beiden Fällen erfolgen die vorgesehenen Prüfungen, und es werden drei verschiedene Protokolle zum Ergebnis der Prüfungen ausgegeben:

• Fehlerhafte Eingangsrechnungen
• Protokoll der fehlerhaften Eingangsrechnungen
• Übernahmeprotokoll der Eingangsrechnungen

Eine tatsächliche Übernahme der auf dem Übernahmeprotokoll ausgewiesenen Eingangsrechnungen findet allerdings nur dann statt, wenn das Programm als Echtlauf durchgeführt wird.
Die Steuerung erfolgt anhand eines Prüflaufkennzeichens auf der Einstiegsmaske des Übergabeprogramms EK23900R (Rechnungen in oxaion übertragen). Dieses Kennzeichen legt fest, ob die eingegangenen Rechnungsdaten lediglich geprüft (Prüflauf = ) oder geprüft und verarbeitet (Prüflauf = ) werden sollen.
Darüber hinaus kann bei einem Echtlauf in Abhängigkeit von der Einstellung der Vorlauftabellen VRLU24 (US54130R Asynchrone Rechn.übg.) und VRLE16 (EK23020R Rechngsendedtn. verw.) auch eine asynchrone Verbuchung der übernommenen Rechnungen ausgelöst werden.
Wenn der Parameter 01 des Satzes mit dem Argument 'EKS' der Tabelle VRLU24 (US54130R Asynchrone Rechn.übg.) eine asynchrone Rechnungsübergabe vorsieht und der Parameter 03 der Vorlauftabelle VRLE16 (EK23020R Rechngsendedtn. verw.)dem Anwender eine Steuerungsmöglichkeit zugesteht, so enthält die Eingangsmaske ein weiteres Steuerfeld. Dieses legt fest, ob die übernommenen Eingangsrechnungen asynchron verbucht werden sollen, wobei die Vorbelegung des Feldes dabei wiederum, abhängig von der Einstellung des betreffenden Parameters, mit oder mit erfolgt.
Bei einer vorgesehenen asynchronen Verbuchung werden die erstellten Eingangsrechnungen sofort asynchron an die Finanzbuchhaltung übergeben. Andernfalls muss zur Übergabe ein besonderes Übergabeprogramm aufgerufen werden.

Prüfprotokolle
Übernahmeprotokoll
Das Übernahmeprotokoll der Eingangsrechnungen listet alle aufgrund der Prüfkriterien für eine erfolgreiche Übernahme vorgesehenen Eingangsrechnungen auf. Dieses Protokoll enthält auch die fehlerhaften Eingangsrechnungen, welche infolge nicht abweisender Prüfkriterien zur Erstellung anstehen oder erstellt wurden.
Fehlerprotokoll
Das Fehlerprotokoll ist eine Auflistung der fehlerhaften Eingangsrechnungen zusammen mit der zugeordneten Fehlermeldung. Diese erfolgt getrennt nach Fehlern auf Kopf- und/oder auf Positionsebene. Die Protokollsätze beziehen sich auf nicht erstellte Eingangsrechnungen, sofern die zugehörige Rechnung auf dem Übernahmeprotokoll nicht erscheint. Ansonsten handelt es sich um erstellte, aber nicht korrekte Eingangsrechnungen, welche eine Nachbearbeitung erfordern. Falls aufgrund nicht abweisender Prüfungen die erstellte Rechnung Differenzen zu den Schnittstellendaten aufweist, ist dies an entsprechenden Hinweismeldungen erkennbar.
Fehlerhafte Eingangsrechnungen
Dokumentieren die Daten der EDI-Schnittstelle. Anhand dieser Informationen kann einerseits eine trotz Fehlern übernommene Rechnung nachträglich korrigiert und mit den übermittelten Daten abgeglichen werden. Andererseits besteht damit auch die Möglichkeit, dann, wenn infolge der festgestellten Fehler maschinell keine Rechnung erstellt werden konnte, auf dem Wege der normalen Rechnungsprüfung - unter Einbezug der Schnittstellendaten - manuell eine Eingangsrechnung zu erfassen.
Dateinamen:
Inhousedatei KIOIGP
Archivdatei: KIOIXP
Schnittstellendateien:EIOIKP
EIOIPP

INVOIC - Schnittstellenverwaltung

Das Programm EK23910R (Rechnungseingänge verwalten) dient dazu, Datensätze aus den oxaion Schnittstellen EIOIKP/EIOIPP für den Nachrichtentyp INVOIC zu verwalten. In der Selektionsmaske können die zu bearbeitenden Daten schon über Lieferantennummer, Rechnungsnummer, Wareneingangsnummer, Bestellnummer und Rechnungsnummer des Lieferanten eingegrenzt werden.
Folgende Aktionen sind aus der Auflistung der Daten heraus möglich:

• Kopfdaten ändern
• Positionsdaten anzeigen. Das Ändern bezieht sich nur auf das Freigabekennzeichen. Dabei wird die Änderung in den Kopfdaten in die zugehörigen Positionsdaten durchgeschrieben.
  
   

Nachricht Artikelstammdaten (PRICAT/DATANORM)

Mit den Nachrichten PRICAT und DATANORM können Artikelstammdaten, sowie Preisinformationen ausgetauscht werden.

PRICAT/DATANORM ausgehend

Nachfolgende Programme sind für die Behandlung des Nachrichtentyps PRICAT/DATANORM innerhalb des EDI-Kommunikations-Moduls verantwortlich:

• US18350R (Preise/Kataloge an EDI-Schnittstelle übergeben)
• US18351R (Erst.PRICAT Inhouse UPCKPP,UPCPPP,UPCRPP(Batch))
• KI21600R PRICAT (Übernahme PRICAT Inhouse aus KIS-Schnittstelle)
• KI21611R DATANORM (Erstellen DATANORM Datei aus KIS-Schnittstelle)

Mit dem Programm US18350R (Preise/Kataloge an EDI-Schnittstelle übergeben) kann für einen Partner ausgewählt werden, welche Artikel per EDI übertragen werden sollen. Dabei kann man entweder eine Preisliste oder eine Artikelgruppe oder einen Produktkatalog übertragen.
Wenn eine Preisliste ausgewählt wird, dann werden die Preise aus dieser Preisliste übertragen, ggf. läuft eine Konditionenfindung (wenn es sich nicht um Nettopreise handelt). Wird dagegen ein Katalog oder eine Artikelgruppe ausgewählt, so läuft für diesen Kunden eine ganz normale Preisfindung. Der hierbei gefundene Preis wird dann übertragen.

Ob die Nachricht PRICAT oder DATANORM ausgegeben wird, ist im KI10200R (Verwalten EDI-Wertesegment) auf der Lasche Verkaufsspezifische Werte unter dem Parameter Schnittstelle hinterlegt. Die dort hinterlegte Schnittstelle wird bei Abruf in diesem Programm angezeigt. Die Eingabefelder Beschreibung und Copyright sind nur für die Schnittstelle DATANORM relevant.

PRICAT / DATANORM eingehend

Das Programm KI22600R (Übernahme eingehender PRCAT) übernimmt eingehende PRICAT aus der Inhousedatei in die oxaion Schnittstelle.
Das Programm KI22610R (Abruf DATANORM Schnittstelle eingehend)/ KI22611R (Übernahme eingehender DATANORM) übernimmt eingehende DATANORM aus der Inhousedatei in die oxaion Schnittstelle.
Die so bereitgestellten Daten können mit dem Programm US18400R (Verwalten eingehende Preis und Katalogdaten) verwaltet werden.

Im Explorer können Kopfdaten, Positionen und Zu-/Abschläge angezeigt und verwaltet werden. Nachrichten können freigegeben und schließlich nach oxaion übernommen werden. Ist ein Artikelstammsatz nicht vorhanden, so wird er bei der Übernahme angelegt. Dazu ist es wichtig, dass eine Artikelgruppe vorgegeben ist, aus der die nicht angegebenen Artikelstammfelder gefüllt werden.
Preise werden in die angegebene Preisliste übertragen. Sollten in dieser Preisliste bereits Preise für diesen Artikel vorhanden sein, dann wird die Gültigkeit dieser Preise bis zum Gültigkeitsdatum der neuen Preise begrenzt und die neuen Preise sind ab diesem Datum gültig.
Rabatte werden aufgrund der komplexen Rabattfindung in oxaion nicht übertragen, sondern die Nettopreise werden als Nettopreise übertragen.
 

Nachricht Lagerbestand (InvRpt)

Mit der Nachricht InvRpt werden dem Lieferanten Lagerbestandsinformationen übermittelt, aus denen dann bei Bedarf Aufträge generiert werden

InvRpt eingehend

Das Programm KI22700R (Eingehende InvRpt-Nachrichten übernehmen) übernimmt Lagerbestandsinformationen. Außerdem enthalten die Positionssätze Informationen über neue Bestellmengen.
Die so bereitgestellten Daten können mit dem Programm VK21930R (Verwalten eingehende InvRpt Daten) verwaltet werden.