dok:osiris

Osiris Automat

Die Schnittstelle zum Osiris Automaten ist in BPS ab Version 2.24 enthalten. Die Kommunikation erfolgt auf Seite BPS durch einen Windows Dienst (Service). Dieser Service wird typischerweise auf einem dedizierten Windows Server ausgeführt. Das kann z.B. der bestehende Scheduler-Server sein, oder zu Testzwecken z.B. eine extra virtuelle Maschine (VM) mit Windows.

Es muss nicht zwingend eine Windows Server Ausgabe sein, ein normales Windows 10 genügt. Da lediglich eine abgehende und eine ankommende TCP/IP Verbindung zu/von dem entsprechenden Server auf Seite des Osiris Automat benötigt wird, hält sich der Ressourcenbedarf die Last in Grenzen. Die einzelnen BPS Clients kommunizieren via Datenbank mit dem Service und schreiben ihre Anforderungen dort in eine Warteschlange (t_osr_queue). Es gibt auf den Clients Prozesse die auf die Ausführung warten und dem Benützer den Fortschritt anzeigen (z.B. senden der Pickaufträge). Diese erhalten das Feedback des Services ebenfalls über ihren Datensatz in der Warteschlange wo der Service den Fortschritt sowie allenfalls Fehler meldet.

Es gibt jedoch auch andere Prozesse auf den Clients bei denen die Verarbeitung und Übermittlung der Daten nicht abgewartet wird. Ein Beispiel ist die Packlinie welche Gebinde an Osiris meldet. Sie schreibt lediglich den Auftrag in die Warteschlange und wartet dann nicht ab was weiter damit geschieht sondern ist sofort bereit für die Registrierung des nächsten Gebindes. Ein anderes Beispiel ist der Abruf der Bestände vom Automaten. Es wird lediglich die Anforderung an Osiris geschickt, und diese schickt dann (mehr oder weniger) umgehend die Bestände, ohne dass der Client die ganze Zeit warten muss.

Nach der Installation der Version 2.24.* sind einige Einstellungen bereits vorkonfiguriert, und müssen lediglich noch angepasst werden. Andere Sachen müssen noch manuell vorbereitet werden, z.B. anlegen der Zonen und Lagerplätze etc. Die Namen der Zonen und Lagerplätze ist grundsätzlich frei wählbar, hier in der Doku werden Namen vorgeschlagen welche später im Dokument auch wieder referenziert werden. Wenn sie andere Namen als vorgeschlagen verwenden, so müssen sie beim Lesen dieser Doku natürlich gedanklich überall ersetzen.

Legen Sie für den Osiris Automaten einen Benutzer an:


Dieser Benutzer benötigt keine Berechtigungen, er wird einzig für die Ausführung des OSR Services verwendet.

Es werden drei neue Zonen benötigt:

Für den Automaten legt man die Zone «Osiris» an und stellt die Kommissionierungsart auf «Automat Typ Osiris» ein:


Es müssen hier keine Partner explizit definiert werden, der Haken «Nur definierte Partner» bleibt also aus. Die an Osiris übermittelten Partner werden vielmehr über Partnerklassen in den Einstellungen definiert wie später beschrieben.

Für die manuelle Kommissionierung erzeugt man die Zone «Lager OG» und stellt die Kommissionierungsart auf «Ab Lager» ein:


Auch hier bleibt der Haken «Nur definierte Partner» aus, Osiris bestimmt über die manuellen Aufträge welche Partner hier kommissioniert werden.

Für die automatische Splittung der Aufträge nach MIFA und Osiris wird schliesslich noch die Übergangs-Zone «Automaten» benötigt. Eine effektive Kommissionierung findet hier nicht statt, deshalb kann die Kommissionierung undefiniert gelassen werden.

Die Aufträge für beide Automaten werden via Pickmatrix zunächst in dieser Zone generiert, und später durch ein Script automatisch auf die Zonen «MIFA» und «Osiris» gesplittet:


Es werden die nachfolgenden zwei neuen Lagerplätze benötigt. Wichtig ist, dass beide Lagerplätze auf der obersten Ebene liegen, und dass es nur je einen solchen Platz für die beiden Zonen gibt.

Für die Bestände im Osiris Automaten (ohne jene der manuellen Zone) erzeugt man den Lagerplatz «Osiris» mit der Zone «Osiris»:


Beim Abgleich der Bestände mit Osiris werden die internen Bestände des Automaten alle in diesen einen Sammelplatz gespeichert.

Für die Bestände der manuellen Osiris-Kommissionierung wird der Lagerplatz «OG» und der Zone «Lager OG» angelegt:


Beim Abgleich der Bestände mit Osiris werden unterhalb dieses Lagerplatzes automatisch weitere Plätze für die manuelle Osiris-Kommissionierung angelegt und die Bestände der Artikel dort eingetragen. Es entstehen unterhalb dieses Hauptplatzes dann die einzelnen Plätze z.B. als «OG/0001», «OG/0002» etc.

SSCC Prefix

Der SSCC Prefix ist ab 2.24.0.0 unter Central System Settings/EPCIS/SsccPrefix gespeichert. Der GS1 Global Company Prefix von GMLU ist 7-stellig und lautet 7617005 (bitte kontrollieren).


Der Prefix für die einzelnen Systeme sollte durch weitere Stellen eingeschränkt werden, sodass jeder mögliche Erzeuger von SSCC einen eigenen Nummernkreis hat. Im Beispiel ist es eine Ziffer (3) die das BPS System Agrar identifiziert.

Alleine von BPS existieren aber bereits 5 Systeme, dazu kommen die Automaten MIFA und Osiris und zukünftig vielleicht noch weitere System.

Es ist deshalb ratsam als Reserve weitere Ziffern zu fixieren und den SSCC Prefix z.B. auf 7617005.30 einzustellen, womit bereits 100 verschiedene Erzeuger von SSCC innerhalb der GMLU je einen eigenen Nummernkreis haben könnten. Es bleiben dann immer noch 8 Stellen als Seriennummer für jedes einzelne System, was mehr als ausreichend sein dürfte.

Der Mode «MIFA» wird ab 2.24 übrigens nicht mehr benötigt, kann aber so gelassen werden. Er war bisher erforderlich damit in den Pickdaten ein SSCC erzeugt wurde. Ab 2.24 ist die Erzeugung des SSCC in den Pickdaten aber ohnehin Standard, auch ohne dass ein EPCIS Mode eingestellt wäre.

Zentrale Automateneinstellungen

Die zentralen Automateneinstellungen werden systemweit verwendet, also sowohl von den Clients als auch vom Dienst. Sie sind unter Central System Settings/Robots/Osiris gespeichert:


Bei «IncludeArticleIds» werden die Artikelnummern festgelegt welche an Osiris zu melden sind. Es ist eine mit Komma separierte Liste von Mustern gemäss SQL LIKE Syntax ('_' = einzelnes beliebiges Zeichen, '%' = beliebige Anzahl Zeichen). Im Beispiel werden also alle Artikel gesendet die mit 1, 26 oder 27 beginnen.

Bei «IncludePartnerClasses» wird die oberste Ebene der Partnerklassen festgelegt die an Osiris zu melden sind. Mit «Filiale» sind also auch alle Partner mit den Klassen «Filiale/Allgemein», «Filiale/Schwerware» etc. selektiert. Auch diese Einstellung ist eine mit Komma separierte Liste. «ManualPickingZone» ist selbsterklärend. Geben Sie hier den Namen der Zone ein die für die manuelle Kommissionierung im Unterauftrag von Osiris vorgesehen ist.

«ManualLocationSize» legt fest wie viele Ziffern die Lagerplätze haben sollen welche beim Bestandsabgleich mit Osiris für die Lagerplätze der manuellen Pickzone erzeugt werden. Bei der Einstellung 4 würden die Lagerplätze also wie folgt angelegt:


Soll die Anzahl Stellen später geändert werden, ist es sinnvoll die bestehenden Lagerplätze unterhalb OG zu löschen und erneut einen Bestandsabgleich durchzuführen damit die Plätze frisch angelegt werden.

Unter Central System Settings/Robots/Osiris/ArticleAttribs findet sich das Mapping der Artikelattribute:


Links beim Schlüssel ist der Wert den das Programm sucht, ändern sie diesen bitte nicht.

Rechts beim Wert sind die Namen der Artikelattribute die sie zu diesem Zweck verwenden wollen. Falls bei Ihnen die Attribute eine Nummer vorangestellt haben, sieht das dann z.B. so aus:

«91 Schmutzig»
«92 Trocken»
etc.

Natürlich müssen diese Artikelattribute angelegt werden falls sie noch nicht existieren, und sie müssen den betreffenden Artikeln zugewiesen werden. Die Info ist für den Osiris Automaten wichtig (Gebinde- und Tablar-Behandlung, erlaubte Lagerplätze, Transportwege, Palettenbau etc.).

Dienst Einstellungen

Die Einstellungen für den Dienst (Service) sind unter Local Installation Settings/OSR-Service zu finden:


Die wichtigsten Einstellungen sind:

  • «User»: ID des Benutzers «Osiris».
  • «PIN»: PIN des Benutzers «Osiris».
  • «Connection»: Name der BPS Verbindung zum Agrar-System.
    Für die Ausführung von osrservice.exe als Windows Dienst muss diese Verbindung ebenfalls in den lokalen Installationseinstellungen gespeichert sein, sonst findet das Programm die Verbindung nicht!
  • «BpsPort»: Portnummer auf welcher der Service auf Eingehende Verbindungen von Osiris hört.
  • «OsirisAddress»: IP oder Hostname der Osiris Gegenstation die auf Verbindungen von BPS hört. Zur Simulation gibt man «localhost» ein wenn der BPS Osiris Simulator auf dem aktuellen PC ausgeführt wird.
  • «OsirisPort»: Portnummer auf welcher die Osiris Gegenstation die auf Verbindungen von BPS hört.
  • «LogFile»: Name der Logdatei. Die Logdatei wird im BPS Logverzeichnis gespeichert wenn nicht der ganze Pfad angegeben wird.
  • «LogToFile»: Mit Komma separierte Liste der Themen die in in der Logdatei zu speichern sind:
    errors = Fehler
    warnings = Warnungen
    info = Informationen
    xml = XML Telegramme
    debug = Debug Infos für Fehlersuche
    all = Alles obige ausser debug
  • «LogToEvents»: Was in den Windows Events zu speichern ist wenn osrservice.exe als Windows Service ausgeführt wird. Einstellung analog zu «LogToFile».
  • Die übrigen Parameter sind Zeiteinstellungen und werden in Sekunden angegeben. Als Grundeinstellung übernehmen sie die Beispiel-Einstellungen.

Die vollständige Liste aller möglichen Einstellungen finden sie in den Einstellungen

Der Osiris Dienst wird bei der Installation von BPS 2.24 eingerichtet wenn entweder der Setup Typ «Komplett», oder aber «Benutzerdefiniert » mit dem Feature «Osiris Kommunikationsdienst» angewählt wird:


Das Feature «Osiris Automatenschnittstelle» ist übrigens die Client-Komponente welche im Gegensatz zum Dienst auf alle BPS Clients des Agrar gehört.

Bei Setup Typ «Komplett» finden sie den Osiris Kommunikationsdienst zwischen den anderen BPS Dienstprogrammen:


Er ist (wie alle BPS Dienste) standardmässig auf manuellen Start eingestellt. Später einmal, wenn alles stabil läuft kann der Dienst auf automatischen Start umgestellt werden. Bis dahin werden wir das Programm allerdings nicht als Dienst starten, sondern über die Kommandozeile.

Der Grund ist einfach. Wenn das Programm als Dienst läuft sieht man nicht sofort ob alles funktioniert, sondern muss erst in der Windows Ereignisanzeige oder in der Logdatei nachschauen.

Beim Start des Programms osrservice.exe über die Kommandozeile sieht man hingegen sofort und live was passiert, und ob es irgendwo ein Problem gibt.

Öffnen sie die BPS Kommandozeile über das Startmenü.


Starten sie dann das Programm mit dem Befehl osrservice –e:


Dass schon mal eine Fehlermeldung kommt ist normal. Der Dienst versucht sich gleich mit Osiris zu verbinden, was aber noch nicht klappt da keine Gegenstation auf Empfang ist.

Das Gegenprogramm wird zunächst durch das Osiris Simulationsprogramm im nächsten Kapitel gebildet. Wenn dann soweit alles einwandfrei läuft und der «richtige» Osiris Server bereit steht, kann man die Verbindung dorthin umstellen. (Allfällige Firewalls bei Verbindung ausserhalb des aktuellen PC's nicht vergessen).

Das Programm osrservice.exe kann mit Ctrl-C beendet werden. (Ev. muss man dann noch die Enter-Taste drücken damit der Prompt wieder erscheint.)

Das Osiris Simulationsprogramm ist Teil der Entwicklungsumgebung von IBK. Als solches ist es nicht auf Perfektion sondern nur auf Zweckmässigkeit getrimmt.

Als Simulation kann es das Verhalten des echten Osiris nicht vollständig richtig abbilden, speziell das Timing und die möglichen Fehlersituationen und Meldungen werden abweichen. Es kann aber nützlich sein für eine kundenseitige Test- und Schulungsumgebung.

Das Programm speichert die aktuellen Artikel, Partner, Gebinde und Aufträge sowie gewisse Einstellungen in einer eigenen SQLite Datenbank. Die DB ist in der Datei simosr.db im BPS Datenverzeichnis zu finden.

Wenn eine ganz neue Simulations-Session von Null auf begonnen werden soll, oder falls es ein technisches Problem mit dem Simulationsprogramm gibt, kann man diese Datei einfach löschen. Beim Start des Simulationsprogramms wird automatisch eine neue DB erzeugt falls sie nicht mehr vorhanden ist.


Das Register «Serverkanal» stellt den Serverkanal von Osiris dar, an dem sich der BPS Service als Client anmeldet. Die Funktionen:

  • Zahnrad: Ruft das Einstellungsfenster für den Server auf (siehe weiter unten)
  • Grüner Punkt: Startet den Server. Beim Start wird das alte Log gelöscht.
  • Rotes Viereck: Stoppt den Server
  • Antwort: Stellt ein wie der Server auf Anfragen von BPS antwortet:
    • Keine Antwort: reagiert gar nicht auf Anfragen.
    • OK: Antwortet schnellstmöglich mit OK.
    • Fehler: Antwortet schnellstmöglich mit Fehler.
    • Verzögert OK: Wartet die eingestellte Verzögerungszeit ab und antwortet dann mit OK.
    • Verzögerter Fehler: Wartet die eingestellte Verzögerungszeit ab und antwortet dann mit Fehler.

Einstellungen

Die Einstellungen welche über das «Zahnrad» Symbol erreicht werden sehen wie folgt aus:


  • Bei Log Modus und den Haken für XML-Telegramme und Verarbeitete Daten kann man einstellen was und in welchem Format geloggt wird.
  • Die Port Nummer definiert wo der Server auf eingehende Verbindungen vom BPS Service wartet.
  • Die einstellbare Verzögerung gibt an, wie lange gewartet wird bevor eine verzögerte Antwort auf eine BPS Anfrage erfolgt.
  • Mit XML Format stellt man ein um wie viele Leerzeichen (positive Zahl) oder Tabulatoren (negative Zahl) jede XML Ebene einzurücken ist.


Das Register stellt den Osiris-Client dar, der sich beim Serverkanal des BPS Service anmeldet. Die Funktionen:

  • Zahnrad: Ruft das Einstellungsfenster für den Client auf (siehe weiter unten)
  • Grüner Punkt: Startet den Client. Beim Start wird das alte Log gelöscht.
  • Rotes Viereck: Stoppt den Client

Einstellungen

Die Einstellungen welche über das «Zahnrad» Symbol erreicht werden sehen wie folgt aus:


  • Bei Log Modus und den Haken für XML-Telegramme und Verarbeitete Daten kann man einstellen was und in welchem Format geloggt wird.
  • Der SSCC-Prefix definiert den ersten Teil des SSCC der vom Osiris-Simulator generierten SSCC für gepickte Aufträge.
  • Die SSCC-Nummer ist die laufende Seriennummer mit welcher der SSCC ergänzt wird. Sie wird automatisch bei jeden neu erzeugten SSCC erhöht.
  • Client Anforderungs-ID ist die fortlaufende Nummer in den gesendeten Anforderungen an BPS. Wird mit jedem neuen Telegramm automatisch erhöht.
  • Client XML Format definiert um wie viele Leerzeichen (positive Zahl) oder Tabulatoren (negative Zahl) jede XML Ebene im Log einzurücken ist.
  • Adresse oder IP: Hostname oder IP Nummer wo der BPS Service läuft. Beim Testen auf der gleichen Maschine ist es „localhost“.
  • Port-Nummer: Port auf welchem der BPS Service auf Verbindungen wartet.
  • Verbindungs-Timeout: Wie lange gewartet wird bis der BPS Service eine Verbindungsanforderung annimmt.
  • Abfrageintervall: Wie lange gewartet wird bevor nach neuen Befehlen in der Warteschlange geschaut wird (auch Poll-Zeit genannt)
  • Fehlererholungszeit: Nach einem Fehler wird vor einem erneuten Versuch so lange gewartet um Telegramme die vielleicht noch unterwegs sind abzuwarten.
  • Statusabfrageintervall: Zeit nach der eine Statusabfrage wieder gesendet wird (auch Keep-Alive Abfrage genannt)
  • Antwort Timeout: Wie lange auf eine Antwort vom BPS Service gewartet wird bevor man aufgibt.


In diesem Register werden die Artikel angezeigt die von BPS empfangen wurden.

Artikel kommen entweder automatisch (per Trigger gesteuert) wenn ein für Osiris relevantes Feld in einem Artikel mutiert wurde, oder auf Anforderung von Osiris alle Artikel zu senden.

Funktionen:

  • Rot/grüner Lade-Button: Alle Artikel von BPS anfordern. Die Anforderung wird über den Client-Kanal an den BPS Service geschickt welcher die Anforderung quittiert. Danach sendet BPS seinerseits alle Artikel auf dem Serverkanal.
  • Blauer Lade-Button: Artikelliste aktualisieren. Eigentlich unnötig da die Liste automatisch aktualisiert wird wenn etwas ändert.
  • Spalten anpassen: Geschieht normal ebenfalls automatsch wenn etwas an den Artikeln ändert.
  • Radiergummi: Löscht die vorhandene Artikelliste.


In diesem Register werden die Partner angezeigt die von BPS empfangen wurden.

Partner kommen entweder automatisch (per Trigger gesteuert) wenn ein für Osiris relevantes Feld in einem Partner mutiert wurde, oder auf Anforderung von Osiris alle Partner zu senden.

Funktionen:

  • Rot/grüner Lade-Button: Alle Partner von BPS anfordern. Die Anforderung wird über den Client-Kanal an den BPS Service geschickt welcher die Anforderung quittiert. Danach sendet BPS seinerseits alle Partner auf dem Serverkanal.
  • Blauer Lade-Button: Partnerliste aktualisieren. Eigentlich unnötig da die Liste automatisch aktualisiert wird wenn etwas ändert.
  • Spalten anpassen: Geschieht normal ebenfalls automatsch wenn etwas an den Partnern ändert.
  • Radiergummi: Löscht die vorhandene Partnerliste.


Hier werden die Gebinde aufgelistet welche im Packlinienprogramm bei Zielzone Osiris registriert werden.

Die Funktionen sind:

  • Blauer Lade-Button: Gebindeliste aktualisieren. Eigentlich unnötig da die Liste automatisch aktualisiert wird wenn etwas ändert.
  • Spalten anpassen: Geschieht normal ebenfalls automatisch wenn etwas an den Gebinden ändert.
  • Radiergummi: Löscht die vorhandene Gebindeliste.


In diesem Register werden die Aufträge aufgelistet welche von BPS geschickt wurden.

Die Funktionen oben in der Toolbar sind:

  • Blauer Lade-Button: Auftragsliste aktualisieren. Eigentlich unnötig da die Liste automatisch aktualisiert wird wenn etwas ändert.
  • Spalten anpassen: Geschieht normal ebenfalls automatisch wenn etwas an den Gebinden ändert.
  • Radiergummi: Löscht die vorhandenen Aufträge.

Wenn man links auf eine Tour klickt werden in dem Mitte die (Partner-)Aufträge in dieser Tour angezeigt. Wenn man in der mittleren Spalte einen Auftrag anklickt, werden rechts die entsprechenden Positionen im Auftrag angezeigt.

Per Kontextmenü können gewisse Funktionen auf den Positionen und den Touren ausgelöst werden:

Kontextmenü Auftragspositionen

Ein oder mehrere Positionen werden selektiert und das Kontextmenü aufgerufen:


  • TUS inkrementieren/dekrementieren/= 0 setzen:
    Ändert die Sollmengen der selektierten Positionen und meldet die Sollmengenänderung über den Clientkanal an BPS.
  • Erfassen als TUS/TUS-1/TUS+1/als 0:

Simuliert die Registrierung der entsprechenden Mengen in den selektierten Positionen, und sendet alle über den Clientkanals als eine Palette an BPS. Positionen können mehrfach zurückgemeldet werden indem sie z.B. erst mit TUS-1 erfasst werden und danach in einem weiteren Durchgang als TUS oder TUS+1. Jeder solche Erfassungsschritt wird dann als neue Palette an BPS gemeldet.

  • Als manuellen Kommissionierauftrag senden:
    Die selektierten Positionen werden per Clientkanal als manueller Kommissionierauftrag von Osiris an BPS geschickt.
    Dieser Auftrag kann dann in BPS mit der ab Lager Kommissionierung in der Zone «Lager OG» abgearbeitet werden. Beim Abschluss einer Palette werden die Pickmengen über den Serverkanal an das Simulationsprogramm zurückgemeldet.
    Das Simulationsprogramm schickt dann seinerseits diese Palette umgehend per Clientkanal wieder als Registrierung der Originalpositionen an BPS zurück.
  • Picks rücksetzen: Die Pickmengen der selektierten Positionen löschen.

Kontextmenü Touren

Das Kontextmenü hat nur eine Funktion:


Über den Clientkanal sendet die Simulation eine Tourenende-Meldung an BPS. Falls soweit alles I.O. ist, werden daraufhin die allfällig vorhandenen manuellen Aufträge von Osiris aus der Auftragstour gelöscht und die Auftragstour kann ggf. abgeschlossen werden.

Die Anforderung wird von BPS allerdings abgelehnt falls noch angefangene Paletten von manuellen Osiris-Aufträgen vorhanden sind, oder noch nicht alle Pickmengen davon an Osiris zurückgemeldet und von Osiris quittiert wurden.

Nach der Aktivierung einer Auftragstour geht man in das Automatenregister. Zunächst ist der Status dort bei der Osiris Zone auf «nicht geladen» und man sieht die Anzahl Positionen.


Per Menü «Automat» oder über das Kontextmenü ruft man die Funktion «Aufträge senden» auf. Daraufhin werden die Aufträge gesendet.


Nach erfolgreicher Übermittlung sind dann keine unsynchronisierte Positionen mehr vorhanden:


Wenn neue unsynchronisierte Positionen entstehen (je nach Einstellung im nächsten Kapitel) kann «Aufträge senden» wiederholt werden.

Automatsches Nachsenden neuer Positionen

Wenn neue Positionen für Osiris erzeugt werden sollen diese eventuell automatisch übermittelt werden, wenn der Automatenstatus bereits auf «Gesendet» ist.

Das kann pro Tour separat mit dem Auswahlfeld «Automaten Aktualisierungen» eingestellt werden:


  • «Alle automatisch»: Alle neu erstellten Positionen werden automatisch an Automaten gesendet.
  • «Interne Aufträge automatisch»: Nur Aufträge wo das Quellsystem im Partnerauftrag leer ist (z.B. per Bestellaufnahme erfasste) werden automatisch gesendet. Aufträge bei denen ein Quellsystem im Partnerauftrag vorhanden ist (z.B. per Schnittstelle eingelesene) werden nicht automatisch gesendet.
  • «Manuell»: Neue Aufträge nie automatisch an den Automaten senden.

Die Einstellung «Automaten Arbeitsweise» ist für Osiris nicht relevant, sie war nur für TAKO Automaten.

Der Bestandsabgleich mit dem Osiris Automaten (besser gesagt Bestandsabruf, da Osiris Bestände nur sendet nicht aber empfängt) kann an 3 verschiedenen Stellen ausgelöst werden:

  1. In den Auftragstouren
  2. Bei den Lagerplätzen
  3. Im Artikelstamm


Die Funktion ist dabei immer dieselbe. Die Anforderung wird per Kanal BPS>Osiris an Osiris gesendet, und Osiris sendet daraufhin per Kanal Osiris>BPS alle Bestände zurück.

BPS wartet nicht auf die Bestände, man kann also nach Absetzung der Abfrageanforderung sofort weiterarbeiten und braucht nicht zu warten bis Osiris die Bestände zusammengestellt und geschickt hat.

BPS löscht beim Empfang der Bestände die alten Osiris Bestände (interne Automatenbestände wie auch Bestände des Lagers OG) und übernimmt die neuen Bestände.

Die Packaufträge können neu nach Zielzonen getrennt werden. Die Details dazu sind im BPS Änderungsprotokoll nachzulesen: Neue Zielzonen-Optionen bei Packaufträgen

Auftragsauswahl

Die Aufteilung nach Zielzonen ist natürlich auch im Packprogramm vorhanden, und wie man im folgenden Beispiel sieht, könnten für den gleichen Artikel bis zu 3 verschieden Packaufträge vorhanden sein:


Hintergrund ist, dass die gleichen Artikel teilweise auf dem alten MIFA Automaten, und teilweise auf dem neuen Osiris Automaten kommissioniert werden. Gebinde die von der Packlinie über die Transportstrecke geschickt werden sollen nun natürlich in der richtigen Menge und am richtigen Ort ankommen.

Der Mitarbeiter an der Packlinie hat allerdings die Möglichkeit die Zielzone zu übersteuern. Das kann z.B. notwendig sein wenn die Transportstrecke blockiert ist, und man die Gebinde deshalb an der Packlinie stapeln will. Trotzdem benötigt man auch dann die Aufteilung, man muss ja auch dann wissen wieviel Gebinde pro Zielzone zu stapeln sind und wohin sie anschliessend gebracht werden sollen.

Auftragseinstellungen


Neu ist in den Auftragseinstellungen der Schalter «Artikel ist nass». Er gibt bei der Übermittlung der Gebinde an Osiris die Info weiter dass der aktuell gepackte Artikel nass ist (obwohl er normalerweise vielleicht nicht nass ist).

Bei den anderen Zielzonen hat der Schalter keine Funktion und muss nicht speziell beachtet werden.

Abpackung

Die Abpackung für die Zielzone Osiris unterscheidet sich von den anderen Zielzonen. Wie hier zu sehen ist, ist der Button «Erfassen» gesperrt, und auch eine allfällige externe Taste die über die Signale angeschlossen ist hat bei Zielzone Osiris keine Funktion:


Die Registrierung eines Gebindes erfolgt ausschliesslich durch Scannen des GRAI Codes am Gebinde. Bei der Packlinie ist dazu ein Scanner am Warteplatz für die Einschleusung auf die Sammelstrecke der Automaten installiert.

Nur wenn ein gültiger GRAI gescannt wird, wird das Gebinde registriert. Es wird an Osiris übermittelt, und gleichzeitig wird das Signal «Transport Ausgang» gepulst, welches an der Steuerung der Sammelstrecke anzuschliessen ist.

Zum Signal sind Details im BPS Änderungsprotokoll zu finden: Erweiterung ICP CON I-7188E Schnittstelle

Das Signal «Transport Ausgang» wird übrigens ausschliesslich beim Packen für Zielzone Osiris verwendet, bei allen anderen Zielzonen ist es deaktiviert sobald es eine Osiris Zone im System hat.

Zur Simulation des Scannen eines GRAI kann man das Scanner-Simulationsprogramm von BPS verwenden:


Im Beispiel oben sind einige GS1-128 mit GRAI eingetragen, wie sie auch auf den Tags der Migros Gebinde im Barcode vorhanden sind. Es ist ein Mechanismus eingebaut, damit der gleiche GRAI innerhalb 24 Stunden nur einmal verwendet werden kann.


Selbstverständlich könnte das bei Bedarf auch in den Einstellungen geändert werden, der Default-Wert 24 Stunden ist aber sicher Praxisgerecht.

Aus Benutzersicht unterscheidet sich die Kommissionierung ab Lager nicht von anderen Lagerzonen.


In Hintergrund werden einfach bei Abschluss einer LU die Pickdaten an Osiris zurückübermittelt.

Eine generelle Verbesserung betrifft alle Zonen, nicht nur Osiris: Wenn es eine angefangene passende Palette (LU) gibt welche verwaist ist, wird diese automatisch beim Aufruf des Auftrags vorgeschlagen:


Bisher musste der Rüster gezielt diese Funktion aufrufen, und oftmals wusste er wohl gar nicht dass es noch eine angefangene LU gibt. Damit sollte es etwas seltener vorkommen, dass verwaiste LU bis zum Kommissionierende übersehen werden.

  • dok/osiris.txt
  • Zuletzt geändert: 21.04.2021 23:05
  • von ibk