Die POS Inbound Outbound Processing Engine (PIPE)  ist der Hauptprozess des POS DTA Moduls, gewachsen aus POS DM. Ausgelegt für sehr große Datenmengen, nimmt die PIPE Transaktionsdaten entgegen, prüft gegen Stammdaten und reichert ggf. die Daten an.

Für eine gegenüberstellung des klassichen POSDM zu POSDTA klicken Sie hier.

Transaktionsdaten werden durch POSDTA i.A. geprüft auf

  • doppelte Transaktionsnummern & Lücken in der Bonnummerierung,
  • ausgeglichene Abverkaufs- und Zahlungsmittelsummen,
  • abgleich von Bondaten und Kassensummen,
  • Kreditkartendaten

Anschließend werden Transaktionsdaten aggregiert (z.B. Abverkäufe an unbekannte Kunden) und die Umsysteme (ERP, BW, F&R, …) versorgt.

1. PIPE-Eingang: Inbounddispatcher

Transaktionsdaten können von den Kassen auf verschiedenen Wegen & Formaten geliefert werden (RFC, IDoc, CSV, XML, …)
Diese werden durch den BAPI /POSDW/BAPI_POSTR_CREATE entgegengenommen, formatiert und letztlich in der POS Inbound Queue abgelegt.

In der Inbound-Queue (Transaktionscode: /POSDW/QMON, Tabelle: /POSDW/TIBQ) können die neuen Kassentransaktionen verarbeitet werden. Dies geschieht gewöhnlich durch einen Job.
Bei der Eingangsverarbeitung werden die sog. Eingangsaufgaben verarbeitet. Diese sind im Customizing definiert. Hierzu kann bereits eine erste Stammdatenprüfung gehören. Zusätzlich werden alle Aufgaben ausgelöst, die im Customizing für die “Sofortverarbeitung” gekennzeichnet sind.
Nach erfolgreicher oder fehlerhafter Verarbeitung landen die Transaktionen in den TLOG-Tabellen (/POSDW/TLOGF, TLOG_EXT, TLOGX). Diese Tabellen können in POS DTA direkt angezeigt und durchsucht werden, dies war in POS DM nicht möglich.

 

2. PIPE-Verarbeitung: PIPE-Dispatcher

Nach Abschluss der Eingangsverarbeitung können Transaktionen in der POS-Workbench überwacht und weiter verarbeitet werden.

 

Auch der Verarbeitungsschritt “PIPE-Dispatcher” wird gewöhnlich über regelmäßige Jobs implementiert. Es ist allerdings möglich, im Customizing der Aufgaben zwischen “Sammelverarbeitung” und “manueller Verarbeitung” zu unterscheiden. Aufgaben mit manueller Verarbeitung können nur manuell in der POS-Workbench getriggert werden.

 

3. PIPE-Ausgang: Outbounddispatcher

Im letzten Schritt werden Ausgangsaufgaben für Aggregate ausgeführt. Beispiel: Aggregate werden geschlossen und ans ERP geschickt.

Man unterscheidet hier Ein- und Zwei-Schritt-Verarbeitung:

Ein-Schritt-Verarbeitung:

Aggregation und Datenversand an Umsysteme geschieht “on-the-fly”, die Aggregate werden nicht lokal am System gespeichert.

Zwei-Schritt-Verarbeitung:

Aggregate werden am CAR-System in der Tabelle /POSDW/ODIS abgelegt und anschließend an Umsysteme versandt. Meist wird die Zwei-Schritt-Verarbeitung verwendet.

Fazit: Wie schon im POSDM bildet die PIPE das Herzstück des POSDTA mit vielen Anpassungsmöglichkeiten durch Customizing und BADis, die in einem weiteren Beitrag näher beleuchtet werden.