Osiris Schnittstelle

Stand: V7 ab 2.24.5.0

Das vorliegende Dokument beschreibt den Aufbau der Kommunikationswege zwischen BPS und Osiris sowie die Daten welche ausgetauscht werden. BPS übernimmt im Zusammenspiel mit Osiris zwei verschiedene Rollen:

• Einerseits als übergeordnetes System welches Stammdaten und Bestellungen (SAP, NB) an Osiris übergibt, und die entsprechenden Pickmengen von Osiris wieder zurück erhält.
• Anderseits aber auch als Subsystem von Osiris für die manuelle Kommissionierung. Osiris gibt manuelle Aufträge an BPS und erhält entsprechende Pickdaten von BPS wieder zurück.

Die Übermittlungen für beide Rollen werden über die gleichen Kommunikationskanäle abgewickelt und sind deshalb in diesem Dokument zusammengefasst.

Für die Kommunikation wurde das TCP/IP Protokoll gewählt. Vorteile der Kommunikation über TCP/IP:

• Unabhängig von dritten Hard- oder Softwareherstellern da es die reinen Standards benützt.
• Auf jedem Betriebssystem verfügbar, daher auch von dieser Seite keine Einschränkungen sollte eines der beiden System später migriert werden.
• Ereignisbasierte Programmierung möglich, d.h. Polling (aktives Warten auf eintreffende Anfragen) ist nirgends notwendig. Die Systemressourcen werden damit geringstmöglich belastet, und es gibt auch keine Kadenz bedingten Verzögerungen die beim Polling unvermeidlich wären.

Die Datenpakete welche über TCP/IP ausgetauscht werden sind in XML formatiert.

• Damit können strukturierte Daten übermittelt werden (z.B. Auftragskopf und Detaildaten in einem Paket, oder eine ganze Anzahl von Aufträgen in einem einzigen Telegramm). Das dient nicht nur dem schnelleren Datenaustausch sondern verbessert auch die Lesbarkeit für Diagnosezwecke.
• Feldgrössen können problemlos verändert werden falls nötig.
• Neue Attribute und Felder können ggf. einseitig erst beim Absender eingeführt werden und werden beim Empfänger einfach ignoriert bis er diese auch braucht resp. implementiert hat.

XML gehört mittlerweile wie TCP/IP zu den weitverbreitetsten Standards. Zur Verarbeitung oder Generierung von XML stehen mittlerweile Library-Funktionen in jedem gängigen Programmiersystem zur Verfügung. Es wird folgendes vereinbart:

• Die XML Dokumente verwenden den Zeichensatz UTF-8.
• Ein DTD wird nicht verwendet.
• Das Wurzelelement ist immer <bpsosiris>
• Jedes Dokument wird mit den ASCII Zeichen STX und ETX eingefasst um die Verarbeitung zu vereinfachen.

Die Farben dienen in den XML Dokumenten dient lediglich der besseren Lesbarkeit und sind nicht Bestandteil des XML Dokuments. Die Punkte … symbolisieren weitere mögliche Elemente (Listen):

STX<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
  ...
</bpsosiris>ETX

Zeilenumbrüche, Leerzeichen oder Tabs (Whitespace) für Einrückungen zwischen den Elementen dienen der besseren Lesbarkeit und können im übermittelten Dokument ggf. weggelassen werden. Für die allfällige Analyse ist es jedoch komfortabler wenn diese vorhanden sind.

Innerhalb von Texten werden die folgenden Zeichen jeweils durch die für XML vordefinierten Entitäten ersetzt:

Es gelten die allgemein die Regeln von XML 1.0, d.h. in Texten sind vom Sonderzeichenbereich U+0000 bis U+001F lediglich die Sonderzeichen CR, LF und TAB erlaubt (je nach Kontext der Daten natürlich).

Binäre Daten würden ggf. in Base64 codiert. Derzeit sind solche (wie z.B. Bilder) jedoch nicht vorgesehen.

In den Tabellen der Telegrammspezifikation wird jeweils der Typ und die maximale Grösse der Daten in der Spalte Typ(Grösse) angegeben. Im XML Dokument wird natürlich alles als Text übertragen:

SSCC und GRAI werden in dieser Schnittstelle jeweils im EPC-Format übermittelt. Dieses Format ist unterschiedlich zu den physischen Codierungen z.B. in RFID oder Barcode.

Die Konvertierung von und zu den Codierungen in Barcodes oder RFID ist verlustfrei möglich. Die Prüfziffer lässt sich bei Bedarf im Modulo 10 Verfahren berechnen.

Auszug aus M-EPCIS Implementation Guide:

Fallweise geht die Kommunikation von BPS oder von Osiris aus. Für diese beiden Varianten werden zwei separate Kanäle geschaffen:

• [BPS>Osiris] BPS als Client, Osiris als Server
  Der Kanal wird durch einen TCP/IP Server auf Seite von Osiris gebildet.
  BPS meldet sich als Client an, initiiert die Kommunikation und bekommt Antworten resp. Quittungen von Osiris auf diesem Kanal zurückgeschickt.
• [Osiris>BPS] Osiris als Client, BPS als Server
  Dieser Kanal wird durch einen TCP/IP Server auf Seite von BPS gebildet. Osiris meldet sich als Client an, initiiert die Kommunikation und bekommt Antworten resp. Quittungen von BPS auf diesem Kanal zurückgeschickt.

Für die beiden Kanäle gilt:

• Es wird nur eine Verbindung aufgebaut, d.h. es wird nur eine Client-Verbindung vom Server bedient.
• Die Verbindung wird im Normalbetrieb offen gelassen. Der Client kann regelmässige Statusanfragen (Keep-Alive) durchführen.
  Verbindungsabbruch z.B. wegen Softwarefehler oder Ausfall von Hardware/Netzwerk/Spannungsversorgung können natürlich nicht ausgeschlossen werden.
• Die Portnummer auf welcher der Server die Verbindung bereitstellt muss konfigurierbar sein. Der Server muss Verbindungen sowohl über IPv4 als auch IPv6 entgegennehmen können um Migros diesbezüglich nicht einzuschränken.

Der Client sendet jeweils einen Request als Anforderung und erhält vom Server nach dessen formaler und semantischer Prüfung ein Response-Dokument als Quittung zurück.

Antwortet der Server nicht innerhalb einer konfigurierbaren Zeit, antwortet er mit einer Fehlermeldung oder sendet ungültige Dateien zurück, so protokolliert der Client den Vorfall (Log).

Nach Timeout, Empfang ungültiger Daten und Fehlern kann die TCP/IP Verbindung vom Client geschlossen und nach einer konfigurierbaren Zeit wieder geöffnet werden um den Vorgang erneut zu versuchen (Recovery).

Bei Empfang einer gültigen Quittung (egal ob OK-Bestätigung oder Fehlermeldung) ist der Roundtrip hingegen abgeschlossen. Die Verbindung bleibt also offen und der Vorgang wird nicht wiederholt.

BPS Anmerkung: Der Umfang des Logs ist konfigurierbar (z.B. kein Log, nur Fehler, alles). Die Meldungen können zusätzlich als Alarmierung per E-Mail versandt werden; der Umfang der Alarmierung ist ebenfalls und separat vom Log konfigurierbar.

Osiris Anmerkung: Die Konfiguration des Logs und einer allfälligen Alarmierung wird in der Dokumentation von Knapp spezifiziert.

Die für die verschiedenen Funktionen benötigten Datenpakete werden hier beschrieben.

Als Kontrolle nach Verbindungsaufbau sowie regelmässig wenn keine anderen Kommunikationen stattfinden sendet der Client eine Statusabfrage:

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="12345" ts="18.10.2020 10:53:03" op="getstatus" />
</bpsosiris>

Im Erfolgsfall antwortet der Server:

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <response id="12345" ts="18.10.2020 10:50:04" status="ok" />
</bpsosiris>

Im Fehlerfall zum Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <response id="12345" ts="18.10.2020 10:50:04" status="error">
        <code>1000</code>
        <message>Unbekannte Anfrage-Operation</message>
    </response>
</bpsosiris>

Bei Request wie bei Response sind die Attribute id und ts immer vorhanden:

• id : Eine vom Client generierte Nummer die typischerweise fortlaufend vergeben wird. Der Server wiederholt die Id in seinem Response. Zweck ist, dass der Client erkennen kann ob sich die Antwort tatsächlich auf seine aktuelle Anfrage bezieht, und nicht etwa auf eine frühere weil die Kommunikation irgendwie aus dem Takt geraten ist.
• ts : Ein Zeitstempel (Timestamp) der Zeit wann das XML Dokument vom Absender generiert wurde. Er dient hauptsächlich zur Analyse der Antwortzeiten falls es Probleme gibt.

Beim Request ist das Attribut op immer vorhanden. Es definiert welche Funktion die Anforderung hat.

Wenn auf BPS eines der im Artikelstamm übermittelten Datenfelder ändert, ein neuer Artikel angelegt wird oder ein Artikel gelöscht wird, so werden die entsprechenden Artikel automatisch als Updates an Osiris geschickt. Gesperrte Artikel werden ebenfalls gesendet damit diese nach erneuter Freigabe nicht erneut auf Osiris bearbeitet werden müssen.

Wie der Artikel auf BPS geändert wurde spielt keine Rolle (manuell oder per SAP Schnittstelle).

Der komplette Artikelstamm kann auch durch Osiris angefordert werden z.B. zwecks «Initial Load» (Siehe Abruf Artikelstamm). Der von BPS gesendete ganze Stamm enthält in diesem Falle keine Löschungen.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="23456" ts="18.10.2020 11:01:25" op="updarticles">
        <articles>
            <article key="11223344">
                <collection>GMLU</collection>
                <id>2642.003.021.00</id>
                <name>*BANANEN I         AB H.</name>
                <cu>KG</cu>
                <cu_tu>14</cu_tu>
                <kg_cu>1.000</kg_cu>
                <class>MIFA Früchte/Gemüse</class>
                <locked>no</locked>
                <packed>yes</packed>
                <dry>yes</dry>
                <wet>no</wet>
                <dirty>no</dirty>
                <hdlspeed>-1</hdlspeed>
                <location>172</location>
                <scancodes>
                    <code unit="CU" type="EAN13" value="2123442000006" /> 
                    <code unit="CU" type="EAN13" value="7617027544979" /> 
                    ...
                </scancodes>
            </article>
            <article key="234234" />
            ...
        </articles>
    </request>
</bpsosiris>

Beim ersten Artikel mit Key 11223344 und Inhalt handelt es sich um eine Mutation oder einen neuen Artikel. Es werden immer alle Datenfelder geschickt, nicht nur die geänderten.

Beim zweiten Artikel mit Key 234234 und ohne Inhalt handelt es sich um eine Löschung.

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Wenn auf BPS eines der im Partnerstamm übermittelten Datenfelder ändert, ein neuer Partner angelegt wird oder ein Partner gelöscht wird, so werden die entsprechenden Partner automatisch als Updates an Osiris geschickt.

Wie der Partner auf BPS geändert wurde spielt keine Rolle (manuell oder per SAP Schnittstelle).

Der komplette Partnerstamm kann auch durch Osiris angefordert (Siehe Abruf Partnerstamm). Der von BPS gesendete Stamm hat enthält in diesem Falle keine Löschungen.

Es werden nur Filialen und Debitoren übermittelt (Partnerklassen einstellbar).

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="75367" ts="26.10.2020 09:01:25" op="updpartners">
        <partners>
            <partner key="13561">
                <id>0074700</id>
                <gln>7617005047003</gln>
                <name>*MMM Surseepark</name>
                <class>Filiale</class>
                <address1>6200 Sursee</address1>
                <address2>Bahnhofstrasse 28</address2>
                <labelline1>MMM Surseepark</labelline1>
                <labelline2>Sursee</labelline2>
                <embarkpoint>11</embarkpoint>
            </partner>
            <partner key="9234" />
            ...
        </partners>
    </request>
</bpsosiris>

Beim ersten Partner mit Key 13561 und Inhalt handelt es sich um eine Mutation oder einen neuen Partner. Es werden immer alle Datenfelder geschickt, nicht nur die geänderten.

Beim zweiten Partner mit Key 9234 und ohne Inhalt handelt es sich um eine Löschung.

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Ab 2.24.5.0: +specialarticle

Sobald ein Behälter aus der Packerei auf die Transportstrecke zum Osiris geschoben wird (durch Lichtschranke getriggert), wird dieses in BPS zur Übermittlung freigegeben.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="345678" ts="26.10.2020 07:35:25" op="packedbins">
        <bin grai="7613264.00307.100005002037"
             ts="26.10.2020 07:35:25">
            <packline>2</packline>
            <article>11223344</article>
            <articleid>2642.003.021.00</articleid>
            <cu_tu>14</cu_tu>
            <kg_cu>1.000</kg_cu>
            <wet>no</wet>
            <specialarticle>yes</specialarticle>
        </bin>
    </request>
</bpsosiris>

Jedes Gebinde wird in einem eigenen Telegramm übermittelt.

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

In BPS werden alle Kundenbestellungen zunächst in der Kommissionier-Zone „Osiris“ erzeugt. Die Bestellungen werden nach Aktivierung der Tour und nach Abarbeitung der Splitt-Mengen (Artikelreine LU Kommissionierung) durch einen Mitarbeiter zur Übermittlung an das Osiris System freigegeben.

Die an Osiris übermittelten Bestellungen werden auf BPS für die Bearbeitung gesperrt, d.h. allfällige spätere Kürzungen müssen auf dem Osiris System vorgenommen werden.

Die maximale Anzahl Partneraufträge in einem Telegramm ist einstellbar (Vorgabe ist 1).

Neue Bestellungen die später hinzukommen (in BPS erfasst oder von SAP) werden automatisch sofort an Osiris übermittelt.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="122" ts="26.10.2020 11:01:25" op="addorders">
        <orders>
            <ordertrip key="1291">
                <date>27.10.2020</date>
                <id>HL</id>
                <orderrow key="757434">
                    <origin>SAP</origin>
                    <id>2802502</id>
                    <partner>13561</partner>
                    <orderitems>
                        <orderitem key="86565675">
                            <id>10</id>
                            <article>11223344</article>
                            <articleid>2642.003.021.00</articleid>
                            <tus>3</tus>
                        </orderitem>  
                        <orderitem key="86565677">
                            <id>20</id>
                            <article>467899</article>
                            <articleid>2612.010.004.00</articleid>
                            <tus>2</tus>
                        </orderitem>
                        ...         
                    </orderitems>
                </orderrow>
                ...
            </ordertrip>
        </orders>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

BPS sendet den Befehl für zur Übermittlung der Bestände. Der Vorgang wird nach Kommissionierende und manuell durch einen Benutzer ausgelöst.

Osiris bestätigt mit einer einfachen Quittung wie vorgängig bei Statusabfrage beschrieben.

Anschliessend sendet Osiris die aktuellen Bestände gemäss Meldung der Bestände.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="23456" ts="18.10.2020 10:53:03" op="getstocks" />
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Sobald eine Palette aus einem von Osiris an BPS delegierten Pickauftrag abgeschlossen wird, werden die entsprechenden Pickmengen an Osiris zurückgemeldet.

Je nach Situation und Auftragsmenge können aus einem Auftrag mehrere Paletten entstehen. Ebenso ist es möglich, dass die Pickmenge einer Position auf zwei (oder mehr) Paletten verteilt ist.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="6845" ts="27.10.2020 11:35:22" op="manpicks">
        <picks>
            <job id="1234567">
                <pal sscc="7617005.3000000488"
                     ssccby="BPS"
                     ts="26.10.2020 12:32:23" 
                     user="32">
                    <pick id="10" ts="26.10.2020 12:12:25" user="58">
                        <cu_tu>14</cu_tu>
                        <kg_cu>1.000</kg_cu>
                        <tus>3</tus>
                    </pick>
                    <pick id="20" ts="26.10.2020 12:18:35" user="58">
                        <cu_tu>4</cu_tu>
                        <kg_cu>2.500</kg_cu>
                        <tus>1</tus>
                    </pick>
                    ...
                </pal>
                ...
            </job>
            ...
        </picks>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Ab 2.24.5.0

Wenn in BPS die Sollmenge eines manuellen Pickauftrags für Osiris reduziert wird, so wird das mit diesem Telegramm an Osiris gemeldet.

Die Reduktion der Sollmenge kommt zu Stande indem in der Kommissionierung ab Lager in der Funktion «Korrektur» oder «Artikelreine LU» eine kleinere Menge eingegeben und mit «Komplett» bestätigt wird.

Die Meldung der Unterlieferung erfolgt vor der Rückmeldung der Pickaufträge (falls überhaupt noch Pickmengen entstehen, andernfalls wird nur die Unterlieferung gemeldet).

Überlieferung muss hingegen nicht extra gemeldet werden, das erfährt Osiris durch die Rückmeldung manueller Pickaufträge.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="6845" ts="26.04.2021 11:09:25" op="shortpicks">
        <shortpicks>
            <job id="1234567">
                <pick id="10" ts="26.10.2020 12:12:25" user="1258">
                   <tus>2</tus>
                </pick>
                <pick id="20" ts="26.10.2020 12:18:35" user="121314">
                    <tus>0</tus>
                </pick>
                ...
            </job>
            ...
        </shortpicks>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Osiris sendet den Befehl für zur Übermittlung des ganzen Artikelstamms (z.B. als Initial Load).

BPS bestätigt mit einer einfachen Quittung wie vorgängig bei Statusabfrage beschrieben.

Anschliessend sendet BPS den ganzen Artikelstamm gemäss Artikelstamm.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="67565" ts="27.10.2020 08:47:31" op="getarticles" />
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Osiris sendet den Befehl für zur Übermittlung des ganzen Partnerstamms (z.B. als Initial Load).

BPS bestätigt mit einer einfachen Quittung wie vorgängig bei Statusabfrage beschrieben.

Anschliessend sendet BPS alle Partner gemäss Partnerstamm.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="120" ts="27.10.2020 08:54:31" op="getpartners" />
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Osiris sendet die aktuellen Bestände als Reaktion auf den Abruf der Bestände von BPS.

Die Bestände innerhalb der Osiris Anlage (OSR) inklusive allfälliger Überbestände werden pro Artikel kumuliert nach Los (CU/TU, KG/CU, Eingangsdatum) gemeldet.

Die Bestände in der Zone für die manuelle Kommissionierung werden pro Lagerplatz und Artikel, und ebenfalls kumuliert nach Los gemeldet.

In BPS werden die Bestände wie folgt verarbeitet:

• Ohne «location»: Alle alten Bestände auf dem Sammel-Lagerplatz der Osiris Zone werden zu Beginn der Verarbeitung des Telegramms gelöscht, und dann auf Grund der Datensätze neu erzeugt.
• Mit «location»: Alle alten Bestände in der Zone für die manuelle Osiris-Kommissionierung werden zu Beginn der Verarbeitung des Telegramms mengenmässig genullt, bleiben ansonst aber bestehen. Die im Telegramm gemeldeten Bestände eines Artikels werden kumuliert auf dem ersten Lagerplatz gespeichert. Allfällige weitere Bestände jedes Artikels werden gelöscht, sodass nur ein Bestand pro Artikel bleibt.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="23456" ts="18.10.2020 10:53:25" op="allstocks">
        <stocklist>
            <lot>
                <article>11223344</article>
                <articleid>2642.003.021.00</articleid>
                <cu_tu>14</cu_tu>
                <kg_cu>1.000</kg_cu>
                <indate>17.10.2020</indate>
                <tus>31</tus>
            </lot>
            <lot location="123">
                <article>467899</article>
                <articleid>2612.010.004.00</articleid>
                <cu_tu>4</cu_tu>
                <kg_cu>2.500</kg_cu>
                <indate>18.10.2020</indate>
                <tus>12</tus>
            </lot>
            ...
        </stocklist>
    </request>
<bpsosiris>

Das erste Los (ohne location) ist die kumulierte Menge innerhalb OSR inklusive allfälliger Überbestände. Beim zweiten Los mit location handelt es sich um die Menge auf dem Lagerplatz 123 in der Zone für die manuelle Kommissionierung.

Es kann auch eine leere Liste <stocklist /> zurückgemeldet werden wenn die ganze Anlage inklusive manueller Zone leer ist.

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Aufträge die manuell zu kommissionieren sind delegiert Osiris an BPS. Diese Aufträge haben für BPS keinen direkten Bezug zu den Kundenbestellungen die von SAP kommen oder auf BPS erfasst werden. Sie werden jedoch in derselben Tour abgehandelt.

BPS generiert daraus neue Aufträge für die Zone zur Kommissionierung ab Lager. Als Quelle wird «Osiris» eingetragen und als ID des Partnerauftrags und der Positionen die entsprechenden Referenzen von Osiris.

Nach dem Abschluss einer Palette meldet BPS die Pickmengen an Osiris zurück.

Diese Aufträge werden bei Meldung des Endes der Tourenkommissionierung automatisch in BPS wieder gelöscht damit sie nicht versehentlich an SAP übermittelt werden und damit sie nicht in den Statistiken eingeschlossen werden (siehe Meldung Ende Tourenkommissionierung).

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="678" ts="26.10.2020 10:35:25" op="manpickjobs">
        <jobs>
            <job id="1234567">
                <ordertrip>1291</ordertrip>
                <partner>13561</partner>
                <jobitems>
                    <jobitem id="10">
                        <article>11223344</article>
                        <articleid>2642.003.021.00</articleid>
                        <tus>3</tus>
                    </jobitem>  
                    <jobitem id="20">
                        <article>467899</article>
                        <articleid>2612.010.004.00</articleid>
                        <tus>20</tus>
                    </jobitem>  
                    ...         
                </jobitems>
            </job>
            ...
        </jobs>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Wenn Sollmengen von Kundenbestellungen auf Osiris durch die Kürzungsfunktion verändert werden, so werden diese auch an BPS gemeldet damit auch dort die aktuellen Sollmengen angezeigt werden.

Gemeldet wird die neue totale Sollmenge als absoluter Wert (also nicht die Veränderung als Delta).

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="681" ts="27.10.2020 10:35:25" op="qtychanges">
        <orderitems>
            <orderitem key="86565675" tus="1" />
            <orderitem key="86565677" tus="0" />
            ...
        </orderitems>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Ab 2.24.5.0

Wenn durch Kürzung auf Seite Osiris die Sollmengen von manuellen Pickaufträgen reduziert werden die bereits an BPS gesendet wurden, so werden die neuen Sollmengen auch an BPS gemeldet.

Damit wird den Rüstern erspart bei allen Positionen eine Korrektur vorzunehmen wenn ohnehin bereits klar ist dass zu wenig oder keine Ware zur Verfügung steht. Es ermöglicht ggf. auch die allfällig zur Verfügung stehende reduzierte Menge anders auf die Aufträge zu verteilen.

Gemeldet wird die neue totale Sollmenge als absoluter Wert (also nicht die Veränderung als Delta).

Erhöhungen der Sollmenge werden nicht mit diesem Telegramm gemeldet, dafür wäre ggf. ein neuer Pickauftrag zu senden.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="681" ts="27.10.2020 10:35:25" op="manqtychanges">
        <jobs>
            <job id="1234567">
                <jobitems>
                    <jobitem id="10">
                        <tus>2</tus>
                    </jobitem>  
                    <jobitem id="20">
                        <tus>0</tus>
                    </jobitem>  
                    ...         
                </jobitems>
            </job>
            ...
        </jobs>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Ab 2.24.5.0

Sobald eine Palette im Automaten fertig ist und ausgeschleust wird, wird die Information über SSCC und zugehörigen Partner mit diesem Telegramm an BPS geschickt.

Diese Vorabinformation ist erforderlich da der Abschluss und die Rückmeldung der Bestellungen zeitlich erst erst später nach Scannen der Palette am Lift erfolgt. Die Info wird jedoch schon vorher benötigt, falls der Rüster im OG noch weitere Positionen manuell auf die Palette hinzu kommissioniert bevor sie zum Lift geht.

Die Meldung erfolgt für alle ausgeschleusten Paletten, unabhängig vom Füllgrad und davon ob der Rüster danach tatsächlich noch hinzu kommissioniert.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="1024" ts="23.06.2021 16:33:22" op="paldischarged" sscc="7617005.3000000488">
        <partner>13561</partner>
        <ordertrip>1291</ordertrip>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Sobald eine Palette aus einer von BPS an Osiris geschickten Kundenbestellung abgeschlossen wird, werden die entsprechenden Pickmengen an BPS zurückgemeldet.

Wurde die Palette manuell kommissioniert, wird zudem der Key des Benutzers mitgemeldet (für Rüststatistik).

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="682" ts="27.10.2020 10:55:22" op="orderpicks">
        <picks>
            <pal sscc="7617005.3000000488" ts="26.10.2020 12:32:23" user="32">
                <pick orderitem="86565675" ts="26.10.2020 12:12:25" user="58">
                    <cu_tu>14</cu_tu>
                    <kg_cu>1.000</kg_cu>
                    <tus>3</tus>
                </pick>
                <pick orderitem="86565677" ts="26.10.2020 12:18:35" user="58">
                    <cu_tu>4</cu_tu>
                    <kg_cu>2.500</kg_cu>
                    <tus>1</tus>
                </pick>
                ...
            </pal>
            ...
        </picks>
    </request>
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Wenn eine Auftragstour in Osiris komplett kommissioniert ist und nachdem alle Pickdaten erfolgreich an BPS übermittelt wurden, wird das Ende der Kommissionierung einer Tour an BPS gemeldet.

BPS löscht die Osiris-Aufträge zur manuellen Kommissionierung, setzt den Status der Automaten-Kommissionierung auf abgeschlossen und gibt die Bearbeitung der Bestellpositionen wieder frei.

<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="683" ts="27.10.2020 12:59:11" op="tripfinished" ordertrip="1291" />
</bpsosiris>

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Anforderungen von Osiris, Antworten von BPS.

Anforderungen von BPS, Antworten von Osiris.

¹⁾ Der Fehlertext wird auf die maximal zulässige Textlänge gekürzt
²⁾ Der Feldname wird in rechteckigen Klammern angegeben, z.B. [CU Name]
³⁾ Der fehlerhafte Feldinhalt wird in rechteckigen Klammern angegeben