OmniSeller:VerfuegbarerLagerbestand
 OmniSeller Logo 2020 | |
| App-Name | OmniSeller |
|---|---|
| Hersteller | HTK GmbH & Co. KG |
| Webseite | http://www.omniseller.de |
| Systemvoraussetzungen | |
Der OmniSeller übergibt an Shops und Marktplätze nicht einfach den Bestandswert aus dem ERP, sondern ermittelt je Artikel und je Portal einen verfügbaren Bestand. Diese Seite beschreibt, welche Einstellungen dabei greifen, wie der Wert zustande kommt und wo man ihn im PIM nachvollziehen kann.
Einstellungen je Portal
Die Lagerlogik wird im Webportal-Manager gepflegt, Reiter Erweitert, Bereich Bestand. Jedes Portal hat eigene Werte, mit einer Ausnahme (siehe Wiederbeschaffungszeit).
| Einstellung | Bedeutung |
|---|---|
| Lagerlogik benutzen | Schaltet die Berechnung ein. Ohne diesen Haken zeigt und überträgt der OmniSeller den verfügbaren Bestand aus dem ERP-Artikelstamm, ohne Stücklisten-Hochrechnung. |
| Lagerlogik-Typ | MitEK, OhneEK oder Physikalisch. Bestimmt, was in die Rechnung einfließt. |
| Wiederbeschaffungszeit der Artikel berücksichtigen | Legt fest, wie weit in die Zukunft offene Positionen mitgerechnet werden. |
| Bestandsrunden | Schneidet bei den Zwischenwerten der Stücklistenberechnung die Nachkommastellen ab. |
| Negative Bestände erlauben | Ohne diesen Haken wird ein rechnerisch negativer Bestand als 0 übergeben. |
| Lagerbestand in Hauptansicht auflisten | Blendet die Bestandsspalte in der Hauptansicht ein. |
| Tab Verfügbarer Bestand sichtbar (Reiter Erweitert, Bereich Tabs) |
Blendet das Register Verfügbarkeit in der Artikelansicht ein oder aus. |
Die drei Lagerlogik-Typen
Grundlage ist immer der physikalische Bestand: die Summe aller Lagerplatzbestände des Artikels, umgerechnet auf die Lagermengeneinheit. Lagerorte mit dem Kennzeichen Sperrlager bleiben dabei außen vor.
MitEK
Physikalischer Bestand plus die offenen Dispositionspositionen aus Verkauf und Einkauf, deren Liefertermin im Betrachtungsfenster liegt. Offene Aufträge reduzieren den Wert, offene Bestellungen erhöhen ihn.
Sinnvoll, wenn bereits bestellte, aber noch nicht eingetroffene Ware verkauft werden soll.
OhneEK
Wie MitEK, aber ohne die offenen Bestellpositionen im Einkauf. Nur die offenen Verkaufspositionen werden vom physikalischen Bestand abgezogen.
Ist am Portal nichts eingestellt, rechnen die Dienste mit dieser Variante.
Physikalisch
Nur der physikalische Bestand. Weder offene Aufträge noch offene Bestellungen werden berücksichtigt. Gedacht für Unternehmen, die auf Vorrat produzieren und deren Lagerbestand die Verfügbarkeit unmittelbar abbildet.
Betrachtungsfenster und Wiederbeschaffungszeit
Bei MitEK und OhneEK zählt eine offene Position nur mit, wenn ihr Liefertermin nicht weiter in der Zukunft liegt als:
heute + Wiederbeschaffungszeit des Artikels (Sage 100 Artikelstamm)
Die Wiederbeschaffungszeit wird dabei nur angesetzt, wenn Wiederbeschaffungszeit der Artikel berücksichtigen aktiv ist. Ist der Haken nicht gesetzt, gilt schlicht "Liefertermin bis heute", und alle in der Zukunft terminierten Aufträge und Bestellungen fallen aus der Rechnung.
Wichtig: Dieser Haken steht zwar in den Einstellungen eines Portals, wird aber systemweit gespeichert. Eine Änderung wirkt sofort für alle Portale.
Der typische Effekt bei einer Umstellung: Wird der Haken entfernt, springt der angezeigte Bestand in Richtung des physikalischen Bestands, weil die künftigen Aufträge nicht mehr abgezogen werden.
Stücklisten
In der Sage 100 gibt es mehrere Stücklistentypen. Für die Bestandsermittlung sind zwei davon relevant:
- Produktionsstückliste (interne Fertigung): Der Artikel führt einen eigenen Bestand, es greift die normale Ermittlung wie bei jedem anderen Artikel.
- Handelsstückliste (Bundle): Der Artikel hat keinen eigenen Bestand. Der verfügbare Bestand wird aus den zugeordneten Elementen hochgerechnet.
Bei einer Handelsstückliste ermittelt der OmniSeller für jedes lagergeführte Element, wie oft dessen Bestand die im Bundle enthaltene Menge abdeckt (Bestand geteilt durch Menge pro Bundle). Der kleinste dieser Werte ist der verfügbare Bestand des Bundles: Das knappste Element gibt die Verfügbarkeit vor.
Weitere Punkte:
- Bundles innerhalb von Bundles werden Ebene für Ebene aufgelöst.
- Elemente ohne Lagerführung, etwa Leistungspositionen, bleiben unberücksichtigt.
- Findet sich kein lagergeführtes Element mit Bestand, ist der verfügbare Bestand 0.
Die zugeordneten Artikel und ihre Bestände lassen sich im Register Verfügbarkeit einsehen.
Dropshipping und virtueller Lagerbestand
Ist am Artikel für ein Portal Dropshipping Artikel (virtueller Lagerbestand) gesetzt, wird die gesamte Berechnung übersprungen. Übergeben wird dann der hinterlegte virtuelle Lagerbestand, unabhängig davon, ob im eigenen Lager Ware liegt. Über Virtueller Lagerbestand separat bei Varianten lässt sich der Wert je Variante pflegen statt einmal für den ganzen Artikel.
Zwei Punkte, die dabei regelmäßig für Rückfragen sorgen:
- Die Einstellung ist portalbezogen. Derselbe Artikel kann in einem Portal mit virtuellem Bestand laufen und in einem anderen mit dem echten.
- Artikel mit virtuellem Bestand werden vom schnellen Bestandsabgleich ausgenommen. Ihr Wert geht ausschließlich über den regulären Produktupload an das Portal.
Nicht verwechseln: Das ERP-Benutzerfeld USER_OmniVStock, in der Hauptansicht als Spalte Virtueller Bestand sichtbar, ist etwas anderes. Es wird lediglich als Feld an das Portal übergeben und dort ausgewertet; in die Bestandsberechnung des OmniSeller greift es nicht ein.
Die Vorbelegung dieser Felder lässt sich zentral pflegen, siehe Standardwerte für Verfügbarkeitsfelder.
Eigene Lagerlogik je Portal
Reicht die eingebaute Logik nicht aus, kann je Portal eine eigene SQL-Abfrage hinterlegt werden, die den Bestand liefert. Der Dialog liegt im Ribbon unter System in der Gruppe Grundeinstellungen und heißt Eigene Lagerlogik definieren. Er ist nur sichtbar, wenn die Funktion für die Installation freigeschaltet ist.
Im Dialog wird die Logik für das aktuell gewählte Portal aktiviert und die Abfrage eingetragen. Sie muss genau einen Wert zurückgeben; verwendet wird die erste Spalte der ersten Zeile. Als Parameter stehen Mandant, Artikelnummer und Ausprägungs-ID zur Verfügung.
Auf demselben Weg lässt sich eine zweite Abfrage für das Lieferdatum hinterlegen.
Eine so hinterlegte Abfrage hat Vorrang vor der Standardberechnung. Weil sie kundenspezifisch ist, sollte sie nur zusammen mit dem Consulting-Partner eingerichtet und geändert werden.
Anzeige im PIM
Register Verfügbarkeit
Zu jedem markierten Artikel zeigt das Register Verfügbarkeit den berechneten Bestand, jeweils für das gerade gewählte Portal: Artikelnummer, Ausprägungs-ID, Matchcode, Bezeichnungen, Artikeltyp und den verfügbaren Lagerbestand. Bei Stücklisten kommen die einzelnen Elemente mit Lagerführung und Bestand dazu.
Lagerbestands-Historie
Über das Kontextmenü im Register Verfügbarkeit öffnet Lagerverfügbarkeit (historisch) für den ausgewählten Artikel auflisten den Bestandsverlauf. Dargestellt werden bis zu drei Kurven:
- verfügbarer Lagerbestand nach der OmniSeller-Logik
- virtueller Lagerbestand (Dropshipping)
- portalabhängiger Bestand aus einer eigenen SQL-Abfrage
Die Daten stammen aus den Verlaufstabellen, die die Dienste bei jeder Bestandsberechnung mitschreiben. Das ist der schnellste Weg, um zu klären, ab wann sich ein Bestand verändert hat.
Spalte Lagerbestand in der Hauptansicht
Die Spalte Lagerbestand in der Hauptansicht ist ein Übersichtswert für das schnelle Filtern und Sortieren. Maßgeblich für das, was tatsächlich an ein Portal geht, ist das Register Verfügbarkeit. Bei Stücklisten, Dropshipping-Artikeln und eigener Portal-Lagerlogik können beide Werte auseinanderlaufen.
Was am Ende im Portal ankommt
Vor der Übergabe wird der berechnete Bestand noch aufbereitet:
- Umrechnung auf die Verkaufseinheit: Der Wert wird durch den Verkaufs-Umrechnungsfaktor geteilt. Wird ein Artikel im 6er-Gebinde verkauft, werden aus 30 Stück Lagerbestand 5 verkaufbare Einheiten.
- Nachkommastellen werden abgeschnitten, nicht gerundet. Aus 4,9 wird 4.
- Negative Werte werden zu 0, solange Negative Bestände erlauben nicht gesetzt ist.
Wann eine Bestandsänderung überhaupt einen Upload auslöst, beschreibt Change Tracking des Upload-Service.
Wenn der Bestand nicht stimmt
- Anderes Portal betrachtet: Die Einstellungen gelten je Portal. Im PIM wird immer der Bestand des aktuell gewählten Portals angezeigt.
- Angezeigt wird der reine Lagerbestand: Entweder steht der Lagerlogik-Typ auf Physikalisch, oder die Wiederbeschaffungszeit wird nicht berücksichtigt, sodass künftige Aufträge und Bestellungen herausfallen.
- Bestand ist 0, obwohl Ware da ist: Die Ware liegt auf einem Lagerort mit Sperrlager-Kennzeichen. Bei Bundles genügt ein Element ohne Bestand oder ohne Lagerführung.
- Bestand ändert sich nie: Am Artikel ist für dieses Portal Dropshipping mit virtuellem Bestand gesetzt, oder eine eigene SQL-Lagerlogik liefert einen festen Wert.
- Wert im Shop weicht vom PIM ab: Verkaufs-Umrechnungsfaktor und abgeschnittene Nachkommastellen prüfen. Manche Shops rechnen zusätzlich selbst, etwa mit Reservierungen im Warenkorb.
- Haken für die Wiederbeschaffungszeit zeigt keine Wirkung: In älteren Installationen kann eine Variante der zugehörigen Datenbankfunktion liegen, die die Wiederbeschaffungszeit unabhängig vom Haken immer ansetzt. Das sollte der Consulting-Partner prüfen.
Die tagesgenaue Bestandsermittlung setzt eine Sage 100 Datenbank voraus. Ohne angebundenes ERP stehen die dafür nötigen Datenbankfunktionen nicht zur Verfügung.