[MWI31M-VIADAT]

[MWI31M-VIADAT]

Diese Sektion wird vom infra-Verbucher (Menü 31M) ausgewertet, wenn in der Sektion [MWI31M] über den Eintrag "Interface.MWI31M-VIADT =. . ." eine Schnittstelle mit Verweis auf diese Sektion hinterlegt ist.

Im infra-Standard wird hier die Viad@t-Lagerschnittstelle konfiguriert, siehe Schnittstellendokumentation VIADAT.DOC.

Dort sind auch alle programmspezifischen Einstellungen zu der Schnittstelle beschrieben, während nachfolgend "nur" die für den technischen Ablauf notwendigen Einstellungen beschrieben sind.

In den Sektionen [MDE], [HAENEL] und [MWI31M-HYDRA] sind weitere Schnittstellenkonfigurationen des infra-Verbuchers am Beispiel der Schnittstelle zur mobilen Datenerfassung (infra.mobile), zur Lagersoftware HAENEL und BDE Hydra beschrieben.

Type = VIADAT; (Default: SQL)

Dieser Eintrag bestimmt den Typ der Schnittstelle. Abhängig vom Schnittstellentyp werden die weiteren Einstellungen ausgewertet. Manche Einstellungen stehen nur für einen bestimmten Schnittstellentyp zur Verfügung. Folgende Schnittstellentypen werden unterstützt:

VIADAT	Die Schnittstellendaten werden aus einer SQL-Datenbank gelesen. Im Unterschied zur „normalen“ SQL-Schnittstelle müssen diese aber nicht in einer bestimmten Tabelle mit vorgegebenem Aufbau verfügbar sein. Der Ablauf beim Verarbeiten der Daten ist unter "Funktionsweise der VIADAT-Schnittstelle" beschrieben (s.u.).
FIXED	Die Daten der Schnittstelle werden aus einer Datei mit fester Satzlänge und festen Feldpositionen gelesen. Der Ablauf beim Verarbeiten der Schnittstellendateien ist unter "Funktionsweise der FIXED-Schnittstelle" beschrieben.
CSV	Die Daten der Schnittstelle werden aus einer (oder mehreren) Datei(en) gelesen. CSV steht für Comma-separated Value und bedeutet, dass in der Datei die einzelnen zu importierenden Felder durch Kommata getrennt sind und je Zeile ein Datensatz erwartet wird. Der Ablauf beim Verarbeiten der Schnittstellendateien ist unter "Funktionsweise der CSV-Schnittstelle" beschrieben.
SQL	Die Daten der Schnittstellen werden aus der Tabelle einer SQL-Datenbank gelesen. Ein Beispiel für eine Verbucher-Schnittstelle über eine SQL-Tabelle ist die Schnittstelle zur mobilen Datenerfassung (infra.mobile), die in der Sektion [MDE] beschrieben ist.

Funktionsweise der VIADAT-Schnittstelle

Für die durch eine Schnittstelle vom Typ VIADAT zu verarbeitenden Buchungsdaten wird mit dem Eintrag „Select“ eine Abfrage definiert, die genau einen den eigentlichen Buchungssätzen übergeordneten Verwaltungssatz liefert. Diesem Verwaltungssatz können ein oder mehrere Buchungssätze zugeordnet sein. Dabei können basierend auf einem durch die Abfrage bereitgestellten Gruppenfeld (SubSelectField) die zugeordneten Buchungssätze und ihre spezifischen Datenfelder durch jeweils eigene untergeordnete Abfragen (siehe Eintrag „SubSelect“) aus der Datenbank gelesen werden. Alle Felder, die durch die jeweilige Abfrage geliefert werden, kommen vollständig im jeweils aufzurufenden infra-Buchungsprogramm an. Dabei ist zu beachten, dass die hinterlegte SQL-Abfrage alle von den in Frage kommenden Buchungsprogrammen benötigten Felder im korrekten Format zur Verfügung stellt. Ggf. müssen Daten durch die Abfrage konvertiert oder aufbereitet werden. Die Zuordnung der aufzurufenden infra- Buchungsprogramme erfolgt wie bei allen anderen Schnittstellentypen über PostingCodes. Die PostingCodes sind aber in diesem Fall nicht fest vorgegeben, sondern können abhängig von ein oder mehreren Feldern aus der SQL-Abfrage über „MapPostingCodeFields“ und „MapPostingCodeValues“ zugeordnet werden.

Können die gelieferten Daten keinem PostingCode zugeordnet werden, erfolgt ein Fehlereintrag im Protokoll. Im übergeordneten Verwaltungssatz wird dann ein frei definierbarer Fehlercode (UnknownPostingCodeError) im Feld „errorcode“ abgestellt.

Grundsätzlich wird bei einer fehlerhaft verarbeiteten Buchung die weitere Verarbeitung der zu einem Verwaltungssatz gehörigen Buchungssätze abgebrochen und der Fehlercode „99“ im Feld „errorcode“ abgestellt. Bei Erfolg wird „60“ im Feld „errorcode“ zurückgegeben.

Ansonsten entsprechen alle Angaben der „normalen“ SQL-Schnittstelle (Type=SQL).

Angaben zur VIADAT-Schnittstelle

Zusätzlich zu den Schnittstellenangaben beim Typ „SQL“, siehe Sektion [MDE], gelten für den Schnittstellentyp „VIADAT“ folgende Einstellungen:

Select = Abfrage für den Verwaltungssatz

Die Abfrage muss genau eine Zeile liefern und bildet die Basis für die durch „SubSelect“ gelieferten Buchungssätze. Es muss eine Spalte mit dem Namen „errorcode“ zurückgegeben werden.

Alle anderen Spalten sind lediglich für den weiteren Zugriff auf die Buchungssätze von Bedeutung.

Beispiel

Select="SELECT TOP 1 * FROM idoc WHERE idoctypid=16 AND state=10 AND errorcode=0 AND source=1 AND destination=20 ORDER BY lineid"

SubSelectField = Spaltenname

Der hier angegebene Spaltenname muss einer durch die Abfrage „Select“ gelieferten Spalte entsprechen. Der Inhalt dieser Spalte definiert eine Gruppe von Buchungen, auf die mit einer weiteren Abfrage laut „SubSelect.xyz“ zugegriffen wird. Damit lassen sich Buchungsarten, die sich in ihrem Aufbau oder ihrer Herkunft (z.B. unterschiedliche SQL-Tabellen) unterscheiden auf eigene Unterabfragen verteilen.

Beispiel

SubSelectField=idoctypid

SubSelect.xyz = Abfrage für die Buchungen zu einem Verwaltungssatz

Die Abfrage liefert die einzelnen Buchungssätze, die zum per „Select“-Eintrag gelesenen Verwaltungssatz gehören. Der Schlüssel „xyz“ für diesen INI-Eintrag muss dabei dem Inhalt der Spalte „SubSelectField“ aus dem Verwaltungssatz entsprechen. Ist im Verwaltungssatz in der bei „SubSelectField“ hinterlegten Spalte ein Wert enthalten, für den kein „SubSelect…“-Eintrag definiert ist, wird der Verwaltungssatz mit dem Fehler „UnknownPostingCodeError“ (siehe unten) abgewiesen.

Zur Ermittlung der zu einem Verwaltungssatz gehörenden Buchungssätze kann innerhalb der „SubSelect“-SQL-Abfrage mittels Platzhalter der Form „%Spaltenname%“ auf die Inhalte der Spalten des Verwaltungssatzes zugegriffen werden (siehe „%lineid%“ im Beispiel).

Die Abfrage darf ein oder mehrere Zeilen zurückgeben. Nur wenn alle Zeilen fehlerfrei abgearbeitet wurden, wird das Feld „errorcode“ im Verwaltungssatz auf „60“ (=in Ordnung) gesetzt.

Jede zurückgegebene Zeile wird komplett an das jeweilige Buchungsprogramm übergeben. Die Spalten müssen durch die SQL-Abfrage ggf. so aufbereitet werden, dass das Buchungsprogramm damit arbeiten kann. Die Namen und Inhalte der einzelnen Spalten sind dabei durch das jeweilige Buchungsprogramm vorgegeben. Da sich Spaltennamen und deren Bedeutung je nach Buchungsprogramm unterscheiden können, besteht die Möglichkeit zu den einzelnen Buchungsarten „Aliases“ (also abweichende Spaltennamen) und mit „SetValues“ zusätzliche fixe Inhalte zu definieren, die dann nur an das jeweilige Buchungsprogramm übergeben werden.

Die Zuordnung der aufzurufenden Buchungsprogramme erfolgt wie bei den anderen Schnittstellentypen über „PostingCodes“.

Allerdings können die PostingCodes bei Viadat flexibel anhand der Inhalte ein oder mehrere Spalten der Buchungssätze zugeordnet werden (siehe „MapPostingCodeFields“ und „MapPostingCodeValues“).

Beispiel

SubSelect.16="SELECT *, CAST(corderln/10000 AS int) AS usstring1, RIGHT(CAST(corderln As varchar(10)),4) AS usstring2, ABS(cqtrans) AS bookquantity FROM h2trans WHERE idocid=%lineid%"

Dieser „SubSelect“ wird dann ausgeführt, wenn in der Spalte „idoctypid“ (siehe „SubSelectField“) des Verwaltungssatzes (siehe „Select“) der Wert „16“ enthalten ist. Die Verbindung zum Verwaltungssatz wird über die Spalte „lineid“ des Verwaltungssatzes in der Where-Clause hergestellt.

FieldNameErrorcode = Feldname; (Default: errorcode)

Hier kann der Feldname der VIADAT-Tabelle für den Errorcode eingetragen werden.

Ist kein Eintrag vorhanden wird der Feldname errorcode verwendet.

FieldNameState = Feldname; (Default: state)

Hier kann der Feldname der VIADAT-Tabelle für den Status eingetragen werden.

Ist kein Eintrag vorhanden wird der Feldname state verwendet.

MapPostingCodeFields.xyz = Spaltenname1, Spaltenname2,…

Hier werden die Spaltennamen der Buchungssätze (siehe Abfrage „SubSelect“) angegeben, anhand derer die Abbildung auf den infra-PostingCode und damit das aufzurufende Buchungsprogramm bestimmt wird. Der Schlüssel „xyz“ für diesen INI-Eintrag muss dabei dem Inhalt der Spalte „SubSelectField“ aus dem Verwaltungssatz entsprechen.

Die Zuordnung eines PostingCodes erfolgt dann mit den „MapPostinCodeValues“-Einträgen.

Beispiel

MapPostingCodeFields.16=ctransty,corderty

Die Inhalte der Spalten „ctransty“ und „corderty“ bestimmen den zu verwendenden PostingCode.

Abhängig von den Inhalten der bei „MapPostingCodeFields“ angegebenen Spalten wird hier der zu verwendende infra-PostingCode oder je nach Anwendungsfall eine Aufzählung von auszulösenden infra-PostingCodes angegeben.

Dabei muss für jede bei „MapPostingCodeFields“ angegebene Spalte ein Wert angegeben werden.

MapPostingCodeValues.xyz.Wert1.Wert2… = PostingCode[,PostingCode2,PostingCode3]

Abhängig von den Inhalten der bei „MapPostingCodeFields“ angegebenen Spalten wird hier der zu verwendende infra PostingCode oder je nach Anwendungsfall eine Aufzählung von auszulösenden infra-PostingCodes angegeben.

Dabei muss für jede bei „MapPostingCodeFields“ angegebene Spalte ein Wert angegeben werden.

Für Feldinhalt „Blank“ wird „Nichts“ angegeben, d.h. die Punkte des Schlüssels folgen unmittelbar aufeinander oder beim Wert für die letzte Spalte unmittelbar vor dem Gleichheitszeichen (siehe Beispiel).

Die einzelnen PostingCodes werden mittels „PostingCode“-Angaben wie bei der „normalen“ SQL-Schnittstelle definiert.

Zusätzlich besteht die Möglichkeit, je PostingCode „Aliases“ (also abweichende Spaltennamen) und mit „SetValues“ zusätzliche fixe Inhalte zu definieren, die dann nur an das jeweilige Buchungsprogramm übergeben werden.

Beispiel

MapPostingCodeValues.16.20.AR=183

MapPostingCodeValues.16.14.=194

MapPostingCodeValues.16.30.AK=901,904

Enthält ein Buchungssatz die Werte „20“ und „AR“ in den Spalten „ctransty“ und „corderty“ (siehe „MapPostingCodeFields“) wird der PostingCode „183“ verwendet. Bei den Werten „14“ und „ “ der PostingCode „194“.

Mit „30“ und „AK“ wird erst PostingCode 901 und anschließend (bei fehlerfreier Ausführung) PostingCode 904 ausgelöst.

PostingCode.Code.Aliases = (Spaltenname1,Ersatzname1),(Spaltenname2,Ersatzname2),…

Je PostingCode „Code“ können beliebig viele Aliase angegeben werden, d.h. Spaltennamen aus der SQL-Abfrage (siehe „SubSelect“) werden durch einen anderen Namen ersetzt.

Das ist dann notwendig, wenn ein Spaltenname abhängig vom aufzurufenden Buchungsprogramm unterschiedliche Bedeutungen haben kann oder als Ersatz für die „as“-Angaben in der SQL-Abfrage um die vom Buchungsprogramm erwarteten Spaltennamen zur Verfügung zu stellen.

Beispiel

PostingCode.183.Aliases=(corderid,orderno),(cpartid,itemno)

Bei Buchungscode „183“ werden die Felder „corderid“ und „cpartid“ umbenannt bevor sie an das Buchungsprogramm übergeben werden.

PostingCode.Code.SetValues = (Spaltenname1,Wert1),(Spaltenname2,Wert2),…

Je PostingCode „Code“ können beliebig viele zusätzliche feste Werte angegeben werden, d.h. Spaltennamen aus der SQL-Abfrage (siehe „SubSelect“) werden mit einem festen Wert überschrieben oder zusätzliche Spalten werden ergänzt.

Als Werte können auch infra-Makros angegeben werden, um z.B. auf INI-Einträge zuzugreifen.

Wichtig: Manche Buchungsprogramme erwarten eine Spalte „PostingCode“ in den übergebenen Daten – zum Beispiel dann, wenn unterschiedliche Buchungsarten vom gleichen Buchungsprogramm abgearbeitet werden können. Da diese Spalte bei dieser Form der Schnittstelle in der Regel nicht Bestandteil der SQL-Tabelle ist, muss sie per „SetValues“ zusätzlich erzeugt werden.

Beispiel

PostingCode.183.SetValues=(postingcode,183),(fromstoreid,INI(VIADAT,Lager))

Bei Buchungscode „183“ wird das Feld „postingcode“ mit Wert „183“ ergänzt und das Feld „fromstoreid“ mit einem fixen Wert aus der INI-Datei überschrieben, bevor die Daten an das Buchungsprogramm übergeben werden.

PostingCode.Code.Conditions = (Bedingung1),(Bedingung2),…

Über den „Conditions“-Eintrag können Bedingungen hinterlegt werden, unter denen ein PostingCode ausgelöst werden soll.

So kann eine Buchungsaktion beispielsweise nur bei der Übergabe bestimmter Daten ausgeführt werden.

Besonders beim Auslösen mehrerer aufeinander folgender PostingCodes laut Angabe bei „MapPostingCodeValues“ kann es Sinn machen, einzelne PostingCodes abhängig von Feldinhalten „auszuknipsen“.

Als Bedingung können Vergleiche zwischen Datenfeldern der ausgelesenen SQL-Tabelle („@Feldname“), Konstanten oder infra-Makros angegeben werden.

Folgende Vergleichsoperationen sind möglich:

== gleich

!= ungleich

>= größer/gleich)

<= kleiner/gleich

> größer

< kleiner.

Bei der Angabe mehrerer durch Kommata getrennter Bedingungen müssen alle Einzelbedingungen erfüllt sein (UND-Verknüpfung), um den betreffenden PostingCode auszulösen.

Beispiel

PostingCode.904.Conditions=@cprtname!=""

Der Buchungscode „904“ wird nur ausgeführt, wenn im SQL-Feld „cprtname“ etwas (ungleich leerer Text) eingetragen ist.