dok:osirisinterface

Action disabled: revisions

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

Das STX und ETX werden in den nachfolgenden Beispielen nicht jedes Mal explizit geschrieben.

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:

Zeichen Unicode (dezimal) Entität Bemerkung
" U+0022 (34) &quot; Doppeltes Anführungszeichen
& U+0026 (38) &amp; Ampersand
' U+0027 (39) &apos; Einfaches Anführungszeichen
< U+003C (60) &lt; Kleiner als Zeichen
> U+003E (62) &gt; Grösser als Zeichen

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.

Datentypen

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:

Zahl(8) Ganze Zahl maximal 8 Ziffern, allfälliges Minuszeichen vorangestellt.
Beispiele: 1, 345678, -234
Zahl(11,3) Festkommawert mit maximal 11 Ziffern, davon 8 Vorkomma- und 3 Nachkommastellen. In der Textdarstellung kommen der allfällige Dezimalpunkt sowie das Vorzeichen dazu.
Nachkommastellen können weggelassen werden, wenn nur Nullen folgen.
Beispiele: 12345.568, 1.25, -111
Text(35) Text mit maximal 35 Zeichen. Wenn nichts anderes angegeben ist, sind alles lesbare Zeichen.
Sind Sonderzeichen wie z.B. Zeilenumbruch per CR möglich, so wird dies explizit angegeben.
Hinweis SSCC und GRAI

SSCC und GRAI werden in dieser Schnittstelle jeweils im EPC-Format übermittelt. Diese Formate sind unabhängig von der physischen Codierung 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.

Statusabfrage

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.

Artikelstamm

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.

Request von BPS
<?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.

Feld Bezeichnung Typ(Grösse) Maske/Format
op Operation Text(15) „updarticles“, „allarticles“
key Eindeutiger Schlüssel in BPS Zahl(15) >= 0
collection Sortiment Text(35)
id ID Text(35) dddd.ddd.ddd.dd
name Bezeichnung Text(35)
cu CU Name/Bezeichnung Text(10)
cu_tu Anzahl CU in einer TU Zahl(8) ganze Zahl >= 1
kg_cu Nettogewicht einer CU Zahl(11,3) >= 0.000
class Artikelklasse\\Nur oberste Ebene Text(35)
locked Artikel ist gesperrt Text(3) „yes“, „no“
packed Attribut „Abgepackt“ Text(3) „yes“, „no“
dry Attribut „Trocken“ Text(3) „yes“, „no“
wet Attribut „Nass“ Text(3) „yes“, „no“
dirty Attribut „Schmutzig“ Text(3) „yes“, „no“
hdlspeed Handling-Geschwindigkeit
-2 sehr langsam (minimal)
-1 langsam
0 normal
1 schnell
2 sehr schnell (maximal)
Zahl(1) -2 bis 2
location Haupt-Lagerplatz in der Zone für manuelle Osiris-Kommissionierung.
(Optionales Element, nur wenn Platz zugeordnet)
Zahl(4) >= 0
scancodes Liste der Scancodes
unit Einheit Text(2) „CU“, „TU“, „LU“
type Typ: Derzeit nur EAN8 und EAN13 im Einsatz.
Vollständige Liste siehe Scanning
Text(10) „EAN8“, „EAN13“
value Scancode Text(4000)
Response von Osiris

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Partnerstamm

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).

Request von BPS
<?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.

Feld Bezeichnung Typ(Grösse) Maske/Format
op Operation Text(15) „updpartners“, „allpartners“
key Eindeutiger Schlüssel in BPS Zahl(15) >= 0
id Partner-ID Zahl(10) Filialen 7-stellig
Debitoren 10-stellig
gln GLN (alt ILN) des Partners Zahl(13)
name Name des Partners Text(35)
class Partnerklasse
(Nur oberste Ebene)
Text(35)
address1 Postleitzahl und Ort Text(50)
address2 Strasse und Nr.
Erste Zeile aus BPS Adresse
Text(50)
labelline1 Etikettentext erste Zeile Text(50)
labelline2 Etikettentext zweite Zeile Text(50)
embarkpoint Verladeplatz / Tor Text(35)
Response von Osiris

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Gebinde aus Packerei

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.

Request von BPS
<?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.

Feld Bezeichnung Typ(Grösse) Maske/Format
grai GRAI Code des Behälters Text(26) 26 Zeichen formatiert
ts Zeitstempel der Registrierung Text(19) 19 Zeichen formatiert
packline Nummer der Packlinie Zahl(8) bei GMLU max. 2-stellig
article Key des Artikels Zahl(15) >= 0
articleid Artikel-ID (informativ) Text(35) siehe Artikelstamm
cu_tu Anzahl CU im Gebinde Zahl(8) >= 1
kg_cu (Durchschnitts-)Gewicht einer CU Zahl(11,3) >= 0.000
wet Artikel ist nass Text(3) „yes“, „no“
specialarticle Spezialartikel Text(3) „yes“, „no“
Response von Osiris

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Kundenbestellungen

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.

Request von BPS
<?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>

Feld Bezeichnung Typ(Grösse) Maske/Format
ordertrip Auftragstour
key Schlüssel der Auftragstour in BPS Zahl(15) >= 0
date Auslieferdatum Text(10) TT.MM.JJJJ
id Kurzbezeichnung der Tour Text(35)
orderrow Partnerbestellung
key Schlüssel der Bestellung in BPS Zahl(15) >= 0
origin Quelle der Bestellung
(„SAP“ oder leer wenn von BPS)
Text(35)
id ID der Bestellung
(Von Quellsystem, kann auch leer sein)
Text(35)
partner Schlüssel des Partners in BPS Zahl(15) >= 0
orderitem Bestellposition
key Schlüssel der Bestellposition in BPS Zahl(15) >= 0
id ID der Bestellposition
(Von Quellsystem, kann auch leer sein)
Text(35)
article Schlüssel des Artikels in BPS Zahl(15) >= 0
articleid Artikel-ID (informativ) Text(35) siehe Artikelstamm
tus Sollmenge in Anzahl TU
(1 TU = 1 Behälter im Agrar)
Zahl(8) >= 1
Response von Osiris

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Abruf der Bestände

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.

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

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Rückmeldung manueller Pickaufträge

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>
Feld Bezeichnung Typ(Grösse) Maske/Format
job Pickauftrag
id Auftrags-ID oder Nummer von Osiris
(Auftrags-Referenz in Osiris)
Text(35)
pal Paletteninfo
sscc Der SSCC der Palette Text(18) 9999999.9999999999
ssccby Erzeuger der SSCC\ (In BPS erzeugt, oder gescannte Osiris SSCC) Text(6) „BPS“, „OSIRIS“
ts Zeitpunkt des Palettenabschlusses Text(19) TT.MM.JJJJ HH.MM.SS
user BPS Schlüssel des Rüsters der die Palette abgeschlossen hat Zahl(15) >= 0
pick Pickinfo
id Positions-ID oder Nummer von Osiris
(Positions-Referenz in Osiris)
Text(35)
ts Zeitpunkt des Picks auf die Palette Text(19) TT.MM.JJJJ HH.MM.SS
user BPS Schlüssel des Rüsters der den Pick auf die Palette augeführt hat Zahl(15) >= 0
cu_tu Anzahl CU pro TU Zahl(8) >= 1
kg_cu Gewicht einer CU Zahl(8.3) >= 0.000
tus Gepickte Menge als Anzahl TU Zahl(8) >= 0
Response von Osiris

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Meldung Unterlieferung

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.

Request von BPS
<?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>

Feld Bezeichnung Typ(Grösse) Maske/Format
job Pickauftrag
id Auftrags-ID oder Nummer von Osiris
(Auftrags-Referenz in Osiris)
Text(35)
pick Pickinfo
ts Zeitpunkt der Reduktion Text(19) TT.MM.JJJJ HH.MM.SS
user BPS Schlüssel des Rüsters der die Reduktion vorgenommen hat Zahl(15) >= 0
tus Neue Sollmenge nach der Reduktion Zahl(8) >= 0
Response von Osiris

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Abruf Artikelstamm

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.

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

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Abruf Partnerstamm

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.

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

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Meldung der Bestände

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.
Request von Osiris
<?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.

Feld Bezeichnung Typ(Grösse) Maske/Format
location Lagerplatz-ID in der manuellen Zone.
Artikel welche im Artikelstamm von BPS keine Lagerplatz-ID zugeordnet haben
werden auf Sammelplatz 9999 gemeldet.
Zahl(4) >= 0
article Key des Artikels Zahl(15) ganze Zahl >= 0
articleid Artikel-ID (informativ) Text(35) siehe Artikelstamm
cu_tu Anzahl CU pro TU Zahl(8) >= 1
kg_cu Gewicht einer CU Zahl(11.3) >= 0.000
indate Datum des Eingangs in Osiris Text(10) TT.MM.JJJJ
tus Anzahl TU (= Gebinde) Zahl(8) >= 0
Response von BPS

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Pickaufträge zur manuellen Kommissionierung in BPS

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).

Request von Osiris
<?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>
Feld Bezeichnung Typ(Grösse) Maske/Format
job Pickauftrag
id Auftrags-ID oder Nummer von Osiris
(Wird als Referenz mit den Pickmengen zurückgemeldet)
Text(35)
ordertrip Schlüssel der zugehörigen Tour in BPS Zahl(15) >= 0
partner Schlüssel des Partners in BPS Zahl(15) >= 0
jobitem Pickposition
id Positions-ID oder Nummer von Osiris
(Wird als Referenz mit den Pickmengen zurückgemeldet)
Text(35)
article Schlüssel des Artikels in BPS Zahl(15) >= 0
articleid Artikel-ID (informativ) Text(35) siehe Artikelstamm
tus Sollmenge in Anzahl TU
(1 TU = 1 Behälter im Agrar)
Zahl(8) >= 1
Response von BPS

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Meldung Sollmengenänderung

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).

Request von Osiris
<?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>
Feld Bezeichnung Typ(Grösse) Maske/Format
key Schlüssel der Auftragsposition in BPS Zahl(15) >= 0
tus Neue Sollmenge in Anzahl TU
(absoluter Wert)
Zahl(8) >= 0
Response von BPS

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Kürzung von manuellen Pickaufträgen

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.

Request von Osiris
<?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>
Feld Bezeichnung Typ(Grösse) Maske/Format
job Pickauftrag
id Auftrags-ID oder Nummer von Osiris Text(35)
jobitem Pickposition
id Positions-ID oder Nummer von Osiris Text(35)
tus Neue Sollmenge in Anzahl TU
(1 TU = 1 Behälter im Agrar)
Zahl(8) >= 0
Response von BPS

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Palette ausgeschleust

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.

Request von Osiris
<?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>
Feld Bezeichnung Typ(Grösse) Maske/Format
sscc Der SSCC der Palette Text(18) 9999999.9999999999
partner Schlüssel der Partners in BPS Zahl(15) >= 0
ordertrip Schlüssel der Auftragstour in BPS Zahl(15) >= 0
Response von BPS

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Rückmeldung Bestellungen

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).

Request von Osiris
<?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>
Feld Bezeichnung Typ(Grösse) Maske/Format
pal Paletten-Information
sscc Der SSCC der Palette Text(18) 9999999.9999999999
ts Zeitpunkt des Palettenabschlusses Text(19) TT.MM.JJJJ HH.MM.SS
user Schlüssel des Rüsters auf BPS\\Nur bei manuell kommissionierter Palette Zahl(15) >= 0
pick Daten eines Picks
orderitem Schlüssel der Bestellposition in BPS Zahl(15) >= 0
ts Zeitpunkt des Picks auf die Palette Text(19) TT.MM.JJJJ HH.MM.SS
user Schlüssel des Rüsters auf BPS
Nur bei manuell kommissionierter Palette
Zahl(15) >= 0
cu_tu Anzahl CU pro TU Zahl(8) >= 1
kg_cu Gewicht einer CU Zahl(11,3) >= 0.000
tus Gepickte Menge als Anzahl TU Zahl(8) >= 0
Response von BPS

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Meldung Ende Tourenkommissionierung

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.

Request von Osiris
<?xml version="1.0" encoding="UTF-8"?>
<bpsosiris>
    <request id="683" ts="27.10.2020 12:59:11" op="tripfinished" ordertrip="1291" />
</bpsosiris>
Feld Bezeichnung Typ(Grösse) Maske/Format
ordertrip Schlüssel der Auftragstour in BPS Zahl(15) >= 0
Response von BPS

Einfache Quittung wie vorgängig bei Statusabfrage beschrieben.

Anforderungen von Osiris, Antworten von BPS.

Code Anforderung(en) Meldung Fehlerfall, Kommentar
0 Alle Keine Meldung vorhanden Erfolg, OK
100 Alle Eine andere Verbindung ist bereits aktiv, verwenden sie jene. Osiris Client ist mehr als einmal angemeldet
Entfällt ab BPS 2.24.4.0, siehe Tracker Issue 844
101 Alle Die Operation in der Anforderung ist unbekannt oder noch nicht implementiert. Ungültiger Wert in op 1)
102 Alle Fehler bei der Verarbeitung der XML Struktur. Syntax Fehler oder unerwartete Elemente gefunden 1)
103 Alle Der bezeichnete Datensatz ist ungültig, oder zwingend erforderliche Daten fehlen. Osiris Telegramm/Daten unvollständig/ungültig. Weitere Info zum betroffenen Datensatz in der Fehlermeldung 1)
104 Alle Interner Fehler bei der Verarbeitung der Anforderung. Die Anforderung von Osiris wäre OK, aber es gab einen internen Fehler 2)
105 Meldung Ende Tourenkommissionierung Es gibt angefangene manuelle Aufträge von Osiris bei denen die LU noch nicht abgeschlossen ist. Kommissionierung noch im Gang, oder Benutzer hat die LU nicht abgeschlossen 3)
106 Meldung Ende Tourenkommissionierung Es gibt manuelle Kommissionierdaten für Osiris die noch nicht übermittelt wurden, oder noch nicht von Osiris bestätigt wurden. Kommissionierung abgeschlossen, aber Übermittlung noch im Gang oder Response von Osiris noch ausstehend 4)
1)
  • IT kontaktieren um Problem auf Seite Osiris zu beheben.
  • Falls IT es nicht selber beheben kann, Knapp kontaktieren.
  • Nach Fehlerbehebung die Übermittlung auf Seite Osiris erneut auslösen.
2)
  • IT kontaktieren um Problem auf Seite BPS zu beheben.
  • Falls IT es nicht selber beheben kann, IBK kontaktieren.
  • Nach Fehlerbehebung die Übermittlung auf Seite Osiris erneut auslösen.
3)
  • Warten bis die Kommissionierung der manuellen Osiris-Pickaufträge abgeschlossen ist.
  • In den Auftragstouren die Tour selektieren und Funktion «Nicht abgeschlossene LU» verwenden um entsprechende LU zu sehen, und ggf. auch abzuschliessen.
  • Nachdem keine angefangene LU mehr vorhanden sind, warten bis alle Pickdaten manueller Aufträge via Osiris bis BPS zurückübermittelt sind. Kontrolle in den Auftragstouren.
  • Die Meldung «Ende Tourenkommissionierung» von Osiris aus erneut senden. Falls das nicht möglich ist, in den Auftragstouren die Tour anwählen, auf Register «Automaten» wechseln, Rechtsklick auf Osiris-Zeile, dann «Aufträge abschliessen».
4)
  • Warten bis alle manuelle Pickdaten von BPS an Osiris übermittelt, und dann auch von Osiris an BPS übermittelt wurden (Kontrolle in den Auftragstouren).
  • Die Meldung «Ende Tourenkommissionierung» von Osiris aus erneut senden. Falls das nicht möglich ist, in den Auftragstouren die Tour anwählen, auf Register «Automaten» wechseln, Rechtsklick auf Osiris-Zeile, dann «Aufträge abschliessen».

Anforderungen von BPS, Antworten von Osiris.

Code Anforderung(en) Meldung 1) Fehlerfall, Kommentar
0 Alle Keine Meldung vorhanden Erfolg, OK
1 Alle Formatfehler in Meldung Fehler in Meldungsformat, z.B. fehlender XML-Abschluss-Tag
2 Alle Unbekannte Operation Unbekannte Operation in Meldung von BPS2
3 Alle Ungültige Request-ID Ungültige Request-ID in Meldung von BPS2
4 Alle Ungültiger Zeitstempel Ungültiger Timestamp in Meldung von BPS2
5 Alle Ungültiger Text in [Feldname] 2) Ungültiger Inhalt in einem Textfeld
6 Alle Ungültige Zahl in [Feldname] 2) Ungültiger Inhalt in einem numerischen Feld
7 Alle Ungültiges Datum/TS in [Feldname] 2) Ungültiger Inhalt in einem Datums-oder Timestamp-Feld
8 Alle Ungültiger Merker (ja/nein) in [Feldname] 2) Ungültiger Inhalt in einem Merker-Feld
50 Artikelstamm
Gebinde aus Packerei
Kundenbestellungen
Formatfehler in Artikelnummer [Feldinhalt] 3) Ungültiges Format in Artikelnummer
51 Gebinde aus Packerei Formatfehler in GRAI [Feldinhalt] 3) Ungültiges Format in Feld GRAI Code des Behälters
52 Rückmeldung manueller Pickaufträge Formatfehler in SSCC [Feldinhalt] 3) Ungültiges Format in Feld SSCC der Palette
100 Artikelstamm
Gebinde aus Packerei
Rückmeldung manueller Pickaufträge
Ungültiger CU_TU Wert [Feldinhalt] 3) Ungültiger Wert in Feld cu_tu
101 Artikelstamm
Gebinde aus Packerei
Rückmeldung manueller Pickaufträge
Ungültiger KG_CU Wert [Feldinhalt] 3) Ungültiger Wert in Feld kg_cu
102 Artikelstamm Ungültiger hdlspeed Wert [Feldinhalt] 3) Ungültiger Wert in Feld Handling-Geschwindigkeit
103 Artikelstamm Ungültiger unit Wert [Feldinhalt] 3) Ungültiger Wert in Feld Einheit
104 Artikelstamm Ungültiger type Wert [Feldinhalt] 3) Ungültiger Wert in Feld Typ
105 Gebinde aus Packerei Unerlaubter Gebindetyp [extrahierter Feldinhalt] 3) Unerlaubter oder unbekannter Gebinde-Typ aus GRAI-Code extrahiert
106 Kundenbestellungen Unbekannte Filiale [Feldinhalt] 3) Unbekannte Filiale in Auftragsposition
107 Kundenbestellungen
Rückmeldung manueller Pickaufträge
Ungültiger TUS Wert [Feldinhalt] 3) Ungültiger Wert in Feld Sollmenge
108 Rückmeldung manueller Pickaufträge Ungültiger Job-ID Wert [Feldinhalt] 3) Unbekannte Auftrags-ID in Pickrückmeldung

1) Der Fehlertext wird auf die maximal zulässige Textlänge gekürzt
2) Der Feldname wird in rechteckigen Klammern angegeben, z.B. [CU Name]
3) Der fehlerhafte Feldinhalt wird in rechteckigen Klammern angegeben

  • dok/osirisinterface.txt
  • Zuletzt geändert: 05.11.2021 07:27
  • von ibk