OmniSeller:VerfuegbarerLagerbestand: Unterschied zwischen den Versionen

Aktuelle Version vom 25. August 2026, 07:10 Uhr

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

@@ Zeile 1: / Zeile 1: @@
-<div class="mw-parser-output"><div class="mw-parser-output"><div class="mw-parser-output">
+{{#invoke:Infobox|ShowInfoBoxOmniSeller}}
-'''<span style="font-family:">Inhaltsverzeichnis</span>'''
-<span style="font-family:">Auswahl der Lagerlogik pro Portal</span>
+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.
-<span style="font-family:">Optionen zur Lagerbestandsermittlung</span>
+== Einstellungen je Portal ==
-<span style="font-family:">Lagerbestandsermittlung bei Stücklisten</span>
+Die Lagerlogik wird im [[OmniSeller:WebportalManager|Webportal-Manager]] gepflegt, Reiter '''Erweitert''', Bereich '''Bestand'''. Jedes Portal hat eigene Werte, mit einer Ausnahme (siehe Wiederbeschaffungszeit).
-<span style="font-family:">Lagerbestandsermittlung bei Dropshipping und virtueller Lagerbestand</span>
+{| border="1" cellpadding="4" cellspacing="0" style="width: 900px;"
+|-
+! style="width: 300px;" | 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''' <br>(Reiter Erweitert, Bereich Tabs)
+| Blendet das Register '''Verfügbarkeit''' in der Artikelansicht ein oder aus.
+|}
-&nbsp;
+[[File:Bestand-1.png]]
+== 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.
-&nbsp;
+=== MitEK ===
-'''<span style="font-family:">Auswahl der Lagerlogik pro Portal</span>'''
+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.
-&nbsp;
+Sinnvoll, wenn bereits bestellte, aber noch nicht eingetroffene Ware verkauft werden soll.
-<span style="font-family:">Der OmniSeller verfügt über eine intelligente Lagerbestandsberechnung und -betrachtung.</span>
+=== OhneEK ===
-<span style="font-family:">Sie können unter „/Webportal-Management/Erweiterte Einstellungen/Bestand“ die Lagerlogik je Portal einstellen.</span>
+Wie MitEK, aber '''ohne''' die offenen Bestellpositionen im Einkauf. Nur die offenen Verkaufspositionen werden vom physikalischen Bestand abgezogen.
-<span style="font-family:">Wichtig ist, es muss die Option „Lagerlogik benutzen“ aktiviert sein, sodass die eingestellte Lagerlogik in Kraft tritt.</span>
+Ist am Portal nichts eingestellt, rechnen die Dienste mit dieser Variante.
-&nbsp;
+=== Physikalisch ===
-[[File:Bestand-1.png]]
+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.
-'''<span style="font-family:">Optionen zur Lagerbestandsermittlung</span>'''
+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.
-&nbsp;
+== Stücklisten ==
-<span style="font-family:">Nachfolgend sehen Sie die Erklärungen, was die unterschiedlichen Lagerlogik-Optionen bewirken, die Sie unter „Lagerlogik-Typ“ festlegen können.</span>
+In der Sage 100 gibt es mehrere Stücklistentypen. Für die Bestandsermittlung sind zwei davon relevant:
-&nbsp;
+* '''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 <u>keinen</u> eigenen Bestand. Der verfügbare Bestand wird aus den zugeordneten Elementen hochgerechnet.
-*'''<span style="font-family:">MitEK</span>'''
+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.
-&nbsp;
+Weitere Punkte:
-<span style="font-family:">Es wird der tagesgenaue verfügbare Bestand aus dem Sage 100 ERP System ermittelt und übergeben. Dies erfolgt in 3 Schritten:</span>
+* 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.
-#<span style="font-family:">Der physikalische Lagerbestand aller Lagerorte und -plätze ohne „Sperrlager“ Kennzeichen wird summiert</span>
+Die zugeordneten Artikel und ihre Bestände lassen sich im Register '''Verfügbarkeit''' einsehen.
-#<span style="font-family:">die offenen Auftragspositionen im Verkauf, mit einem ins Kriterium passenden Liefertermin, werden subtrahiert (beauftragt aber nicht geliefert & Vorgang nicht Erfüllt).</span>
-<span style="font-family:">Kriterium: Liefertermin der Position <= aktueller Tag (heute) + Wiederbeschaffungszeit in Tagen (Sage 100 Artikelstamm)</span>
+[[File:Bestand-2.jpg]]
-<ol start="3">
-<li><span style="font-family:">die offenen Bestellpositionen im Einkauf, mit einem ins Kriterium passenden Liefertermin, werden addiert (bestellt aber nicht geliefert & Vorgang nicht Erfüllt).</span></li>
-</ol>
-<span style="font-family:">Kriterium: Liefertermin der Position <= aktueller Tag (heute)</span>
+== Dropshipping und virtueller Lagerbestand ==
-&nbsp;
+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.
-*'''<span style="font-family:">OhneEK</span>'''
+Zwei Punkte, die dabei regelmäßig für Rückfragen sorgen:
-&nbsp;
+* 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.
-<span style="font-family:">Es wird der tagesgenaue verfügbare Bestand aus dem Sage 100 ERP System ermittelt und übergeben. Dies erfolgt hier in 2 Schritten und absolut identisch mit der Option „MitEK“ nur ohne den dritten Schritt.</span>
+Nicht verwechseln: Das ERP-Benutzerfeld <code>USER_OmniVStock</code>, 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.
-<span style="font-family:">D.h. die offenen Bestellpositionen im Einkauf werden nicht berücksichtigt.</span>
+Die Vorbelegung dieser Felder lässt sich zentral pflegen, siehe [[OmniSeller:Standardwerte Verfügbarkeit|Standardwerte für Verfügbarkeitsfelder]].
-&nbsp;
+[[File:Bestand-3.png]]
-&nbsp;
+== Eigene Lagerlogik je Portal ==
-*'''<span style="font-family:">Physikalisch</span>'''
+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.
-<span style="font-family:">Es wird der physikalische Lagerbestand aus dem Sage 100 ERP System ermittelt und übergeben. Der physikalische Lagerbestand aller Lagerorte und -plätze ohne „Sperrlager“ Kennzeichen wird hierbei summiert.</span>
+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.
-<span style="font-family:">Besonderheit hier ist, dass die Lagerbestandsberechnung die offenen Auftragspositionen (beauftragt aber nicht geliefert) mit der Einstellung „Physikalisch“ ebenfalls nicht berücksichtigt.</span>
+Auf demselben Weg lässt sich eine zweite Abfrage für das '''Lieferdatum''' hinterlegen.
-<span style="font-family:">Dies ist für produzierende Unternehmen gedacht, die immer die Ware auf Vorrat produzieren.</span>
+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.
-&nbsp;
+== Anzeige im PIM ==
-'''<span style="font-family:">Lagerbestandsermittlung bei Stücklisten</span>'''
+=== Register Verfügbarkeit ===
-&nbsp;
+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.
-<span style="font-family:">In der Sage 100 gibt es verschiedene Stücklistentypen. U.a. die „Handelsstückliste“ (Bundle) und die „Produktionsstückliste“ (interne Fertigung).</span>
+=== Lagerbestands-Historie ===
-<span style="font-family:">Artikel vom Typ „Produktionsstückliste“ verfügen über einen eigenen Bestand und die Lagerbestandsermittlung für Standard-Artikel greift.</span>
+Ü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:
-<span style="font-family:">Artikel vom Typ „Handelsstückliste“ verfügen über <u>keinen</u> eigenen Bestand und die Lagerbestandsermittlung erfolgt unter Berücksichtigung aller zugeordneten Stücklistenelemente vom Typ „Artikel“ (s. Screenshot).</span>
+* verfügbarer Lagerbestand nach der OmniSeller-Logik
+* virtueller Lagerbestand (Dropshipping)
+* portalabhängiger Bestand aus einer eigenen SQL-Abfrage
-<span style="font-family:">Die zugeordneten Artikel und die jeweils verfügbaren Bestände der Stücklistenelemente können im OmniSeller im Register „Verfügbarkeit“ dargestellt werden.</span>
+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.
-<span style="font-family:">Innerhalb der zugeordneten Artikel gibt der Artikel mit dem kleinsten Lagerbestand den verfügbaren Bestand vor.</span>
+=== Spalte Lagerbestand in der Hauptansicht ===
-&nbsp;
+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.
-[[File:Bestand-2.jpg]]
+== Was am Ende im Portal ankommt ==
-&nbsp;
+Vor der Übergabe wird der berechnete Bestand noch aufbereitet:
-'''<span style="font-family:">Lagerbestandsermittlung bei Dropshipping und virtueller Lagerbestand</span>'''
+* '''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.
-&nbsp;
+Wann eine Bestandsänderung überhaupt einen Upload auslöst, beschreibt [[OmniSeller:OmniSellerUpload ChangeTracking|Change Tracking des Upload-Service]].
-<span style="font-family:">In manchen Situationen wird die eingestellte Lagerlogik produktabhängig ausgehebelt.</span>
+== Wenn der Bestand nicht stimmt ==
-&nbsp;
+* '''Anderes Portal betrachtet:''' Die Einstellungen gelten je Portal. Im PIM wird immer der Bestand des aktuell gewählten Portals angezeigt.
-<ol style="list-style-type:lower-alpha">
+* '''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.
-<li><span style="font-family:">Im Produkt ist das „Dropshipping“ aktiviert (es wird immer dieser Wert als Bestand übergeben)</span></li>
+* '''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.
-<li><span style="font-family:">Im Produkt ist ein „virtueller Lagerbestand“ aktiviert (es wird dieser Wert als Bestand übergeben, wenn kein echter Lagerbestand verfügbar ist)</span></li>
+* '''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.
-</ol>
+* '''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.
-&nbsp;
+Die tagesgenaue Bestandsermittlung setzt eine Sage 100 Datenbank voraus. Ohne angebundenes ERP stehen die dafür nötigen Datenbankfunktionen nicht zur Verfügung.
-[[File:Bestand-3.png]]
+== Verwandte Artikel ==
-&nbsp;
+* [[OmniSeller:WebportalManager|Webportal-Manager]]
-</div> </div> </div>
+* [[OmniSeller:Standardwerte Verfügbarkeit|Standardwerte für Verfügbarkeitsfelder]]
+* [[OmniSeller:OmniSellerUpload ChangeTracking|Change Tracking des Upload-Service]]
+* [[OmniSeller:ERP Variantenartikel einrichten|ERP Variantenartikel einrichten]]

Admin (Diskussion | Beiträge)