Mit diesem Formular können Sie fehlende, unklare oder fehlerhafte Inhalte in der Dokumentation melden und Verbesserungsvorschläge machen. Ihr Feedback hilft uns, die Qualität und Vollständigkeit kontinuierlich zu verbessern.
Berechnung von Verfügbarkeitsposten
Dieses Kapitel bietet einen tiefen Einblick in die Berechnung der Verfügbarkeitsposten und zeigt dabei auch Implementierungsdetails auf.
Alle hier beschriebenen Vorgänge spielen sich in der codeunit 5022209 "GOB Calc Availability by Order" in der Methode CalcAvailabilityByOrder() ab.
Grundsätzlicher Ablauf
Als Einstieg in das Thema bietet sich zunächst die Behandlung des Basisfalls, mit Berücksichtigung von Warenausgängen sowie Reservierungen und unterschiedlichen Einrichtungen an. Fälle, die über den Basisfall hinaus gehen, müssen programmatisch in der Regel als Sonderfall behandelt werden und werden auch hier in einem eigenen Kapitel behandelt.
Ablauf Verfügbarkeitsberechnung
Datensammlung
In diesem Schritt werden alle relevanten Beleg- und Postentabellen gelesen und in Verfügbarkeitsposten umgewandelt.
Involvierte Methoden
Bei der Datensammlung wird zwischen eingehenden und ausgehenden Verfügbarkeitsposten unterschieden. Die Datensammlung kann nach Artikelnummer, Variantencode und Lagerort gefiltert werden. Bei Artikeln mit Stückliste (sowohl Fertigung, als auch Montage), werden die Stücklistenartikel zum Filter hinzugefügt. Falls es sich bei einem Artikel um eine Komponente eines anderen Artikels handelt, so werden auch der Hauptartikel und alle anderen Komponenten des Hauptartikels zum Filter hinzugefügt. Um zu große Filter zu verhindern, stützt sich die Erweiterung des Filters hierbei auf aktive Montage-/Fertigungsaufträge statt auf die Stücklisten, damit nur die relevanten Hauptartikel und Komponenten berücksichtigt werden.
Hinweis
Bei der Ergänzung des Filters um Stücklistenartikel werden keine Varianten berücksichtigt. Es ist also nicht nötig, die Datensammlung mit einer Filterung auf einen Artikel mit einer Stückliste und einem zusätzlichen Variantencodefilter aufzurufen.
Die ausgehenden Verfügbarkeitsposten werden wiederrum weiter nach Zuteilungsprioritäten aufgeteilt. Das bedeutet, dass wenn eine Belegzeile zum Beispiel eine reservierte Teilmenge enthält, für diese Belegzeile zwei Verfügbarkeitsposten erstellt werden - einer für die reservierte Teilmenge, die mit erhöhter Priorität zugewiesen wird, und einer für die restliche Menge, die mit normaler Priorität zugewiesen wird.
Dazu werden in den Methoden CalcQuantityBaseRequested(), CalcQtyReservedBaseRequested() und CalcWhseQtyBaseRequested() die jeweiligen Mengen ermittelt und ein entsprechender Verfügbarkeitsposten eingefügt, sobald eine dieser Mengen größer Null ist. Im Falle des Liefervorschlags werden die Verfügbarkeitsposten zu reservierten Mengen noch zusätzlich nach Reservierung gegen Lagerbestand und Reservierung gegen Zugänge aufgeteilt.
Überblick berücksichtigte Belegarten in Enum Availability Data Type
| Eingehend | Ausgehend |
|---|---|
| Inventory | |
| PurchaseOrder | SalesOrder |
| TransferInbound | TransferOutbound |
| SalesReturnOrder | PurchaseReturnOrder |
| AssemblyOutput | AssemblyConsumption |
| ProductionOutput | ProductionConsumption |
| SalesCreditMemo | PurchaseCreditMemo |
| PurchaseInvoice | SalesInvoice |
| ServiceOrder | |
| ServiceInvoice |
Erstellung der Verfügbarkeitsklassen
Aus den eingehenden Verfügbarkeitsposten werden nun die Verfügbarkeitsklassen generiert.
Involvierte Methoden
In einer Schleife werden sämtliche eingehenden Verfügbarkeitsposten, sortiert nach dem Wareneingangsdatum durchlaufen und sukzessive als Verfügbarkeitsklassen angelegt bzw. zu bereits bestehenden Verfügbarkeitsklassen hinzugefügt. Die Verfügbarkeitsklassen werden durch einen eindeutigen Identifier identifiziert, der sich aus LagerortCode + Artikelnr. + Variantencode zusammensetzt. Ein Verfügbarkeitsklassenidentifier könnte also z. B. HAUPT4711BLAU lauten.
Aus jedem eingehenden Verfügbarkeitsposten wird ein Verfügbarkeitsdatenpunkt erstellt oder ein bestehender ergänzt, falls schon ein Verfügbarkeitsdatenpunkt mit demselben Datum existiert. Bei einem existierenden Datenpunkt wird einfach die Menge des Verfügbarkeitspostens zu der Menge des Verfügbarkeitsdatenpunktes hinzuaddiert, anderenfalls wird ein neuer Verfügbarkeitsdatenpunkt mit der aktuellen kumulierten Menge plus der Menge des Verfügbarkeitspostens erstellt. Die kumulierte Menge wird während des Schleifendurchlaufes für jede Verfügbarkeitsklasse vorgehalten.
Bei diesem Vorgang ist die vorherige aufsteigende Sortierung der eingehenden Verfügbarkeitsposten nach dem Wareneingangsdatum von elementarer Wichtigkeit, da nur so sichergestellt werden kann, dass die kumulierte Menge im zeitlichen Verlauf der Verfügbarkeitsdatenpunkte korrekt ist.
Sortierung und Zuteilungspriorität
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5059468 "GOB Availability Library" |
SetAvailabilityEntrySortingFromSetup() |
codeunit 5059468 "GOB Availability Library" |
GetAllocationPriority() |
Vor der Mengenzuteilung werden die ausgehenden Verfügbarkeitsposten nach ihrer Zuteilungspriorität und nach bestimmten einrichtbaren Kriterien sortiert. Es ist möglich, die Sortierung per Programmcode frei zu überschreiben - ein entsprechender Event Publisher steht zur Verfügung. Die Zuteilungspriorität sollte dabei jedoch immer Vorrang haben und die Sortierung nach anderen Kriterien sollte jeweils nur pro Zuteilungspriorität stattfinden.
Auch die Zuteilungsprioritäten können per Programmcode überschrieben werden.
Die Sortierung stellt sicher, dass die Mengenzuteilung gemäß der Priorität abläuft. So müssen zum Beispiel in der Regel Reservierungen vor normalen Bedarfen berücksichtigt werden. Über die Sortierung nach anderen Kriterien wird es möglich zum Beispiel bestimmte Belegarten zu bevorzugen oder die Bedarfe entsprechend ihres Erstellungsdatums zu decken, sodass Bedarfe nach FIFO (nicht zu verwechseln mit der Lagerabgangsmethode!) abgewickelt werden, unabhängig vom Bedarfsdatum.
Übersicht Zuteilungsprioritäten
| Name | Zahlenwert |
|---|---|
| WhseShipment | 100 |
| Reservation | 200 |
| Normal | 300 |
| ShipmentDateProjection | 9000 |
Die Zuteilungsprioritäten werden zur Unterscheidung der zuzuweisenden Mengen verwendet und legen die Reihenfolge bei der Zuteilung fest. Es gilt: Je kleiner der ganzzahlige Wert, desto höher die Priorität.
Suche nach Verfügbarkeitsdatenpunkt
Nachdem die Verfügbarkeitsklassen erstellt und die ausgehenden Verfügbarkeitsposten sortiert wurden, kann mit der Zuteilung von verfügbaren Mengen zu den ausgehenden Verfügbarkeitsposten begonnen werden. Diese Schritte in der Funktion AssignAvailableQuantities() stellen die eigentliche Verfügbarkeitsberechnung dar.
Dazu muss zunächst ein passender Verfügbarkeitsdatenpunkt, entsprechend des Bedarfsdatums des Verfügbarkeitspostens, ermittelt werden.
Es werden alle ausgehenden Verfügbarkeitsposten gemäß ihrer Sortierung sequenziell in einer Schleife abgearbeitet.
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5022209 "GOB Calc Availability by Order" |
AssignAvailableQuantities() |
codeunit 5022209 "GOB Calc Availability by Order" |
BinarySearchNearestDataPoint() |
Auch hier spielt die Sortierung der eingehenden Verfügbarkeitsposten vor der Erstellung der Verfügbarkeitsklassen eine entscheidende Rolle. Durch die Sortierung sind die Verfügbarkeitsdatenpunkte pro Verfügbarkeitsklasse automatisch auch zeitlich sortiert, was die Suche nach einem passenden Verfügbarkeitsdatenpunkt erheblich effizienter macht.
Bei der Suche nach einem passenden Verfügbarkeitsdatenpunkt gibt es drei Szenarien:
- Das gesuchte Datum ist als Verfügbarkeitsdatenpunkt vorhanden
- Das gesuchte Datum liegt zwischen zwei Verfügbarkeitsdatenpunkten
- Der durch die Verfügbarkeitsposten aufgespannte Datumsraum enthält das gesuchte Datum nicht, z. B liegt das Datum ganz am Anfang oder Ende der Liste der Verfügbarkeitsdatenpunkte
Das erste Szenario ist schnell und effizient erledigt, da es sich bei der zugrundeliegenden Datenstruktur, in der die Verfügbarkeitsdatenpunkte gespeichert werden, um ein Dictionary handelt und das Datum als Key dient. In diesem Fall kann also direkt mit Get() auf die Menge im Verfügbarkeitsdatenpunkt zugegriffen werden.
In den anderen beiden Szenarien muss der passende Verfügbarkeitsdatenpunkt tatsächlich gesucht werden. Dazu bietet sich die Binäre Suche, da der Algorithmus schnell und effizient auf einer sortierten Datenmenge arbeitet.
In der Verfügbarkeitsberechnung wird eine leicht abgewandelte Version verwendet, die immer den linken Nachbarn des nächstmöglichen Einfügepunktes unter Berücksichtigung der Sortierung ausgibt. In den Randfällen, also im dritten Szenario, wird entsprechend der erste oder der letzte Verfügbarkeitsdatenpunkt im Dictionary ausgegeben.
Beispiel: Einfügepunkte (rot), gefundener Verfügbarkeitsdatenpunkt (schwarz)
Der "Linke Nachbar des nächstmöglichen Einfügepunktes unter Berücksichtigung der Sortierung" (Abk. Linker Nachbar Nächstmöglicher Einfügepunkt LINNEP) erfüllt folgende Bedingungen:
- Die Menge im LINNEP entspricht der zum Bedarfsdatum verfügbaren Menge
- Alle Verfügbarkeitsdatenpunkte rechts vom LINNEP sind zeitlich zu spät, um den Bedarf zu decken
- In Szenario 3 ist LINNEP immer
0Doder entspricht dem letzten Datum in der Liste - Beim Einfügen des Bedarfsdatums rechts vom LINNEP, bliebe die Sortierung erhalten
Mengenzuteilung
Durch das Ermitteln des passenden Verfügbarkeitsdatenpunktes ergibt sich auch automatisch die verfügbare Menge zum Bedarfsdatum und somit die Verfügbarkeit des Verfügbarkeitspostens.
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5022209 "GOB Calc Availability by Order" |
AllocateRequestedQtyBase() |
Die Bedarfsmenge wird mit der verfügbaren Menge des Verfügbarkeitsdatenpunktes abgeglichen und daraus die Verfügbarkeit ermittelt. Die Verfügbarkeit kann drei Zustände annehmen:
| Status | Bedingung |
|---|---|
| Verfügbar | Verfügbare Menge >= Bedarfsmenge |
| Teilweise verfügbar | 0 < Verfügbare Menge < Bedarfsmenge |
| Nicht verfügbar | Verfügbare Menge = 0 |
Ein Verfügbarkeitsposten ist verfügbar, wenn die Menge im Verfügbarkeitsdatenpunkt groß genug ist, um die Bedarfsmenge zu decken. Ansonsten ist der Verfügbarkeitsposten teilweise verfügbar (Menge reicht nicht ganz aus) oder nicht verfügbar (Menge ist kleiner/gleich Null).
Falls der Verfügbarkeitsposten nur teilweise verfügbar oder nicht verfügbar ist, müssen noch zukünftige Zugänge blockiert werden, weil alle nachfolgenden Verfügbarkeitsposten eine geringere Priorität als der aktuelle Verfügbarkeitsposten haben und der aktuelle Verfügbarkeitsposten entsprechend vorrangig bedient werden muss. Um dies zu erreichen, wird die Liste von Verfügbarkeitsdatenpunkten einfach weiter nach rechts (also in Richtung Zukunft) durchlaufen und solange Mengen zugeteilt, bis der Bedarf gedeckt oder das Ende der Liste erreicht ist. Zukünftige Zugänge werden also zuerst dazu verwendet, um höher priorisierte/vorangegangene Bedarfe zu decken, bevor diese für die nachfolgenden Bedarfe zur Verfügung stehen.
Ermittlung frühestmögliches Verfügbarkeitsdatum
Als Nebeneffekt lässt sich eine Aussage über das frühestmögliche Verfügbarkeitsdatum treffen. Hier geht es darum, dass die Verfügbarkeitsdatenpunkte um die zugeteilten Mengen verringert werden.
Sobald die Bedarfsmenge gedeckt wurde, entspricht das frühestmögliche Verfügbarkeitsdatum, unter Berücksichtigung der aktuell geplanten Zugänge, dem Datum des zuletzt ausgewählten Verfügbarkeitsdatenpunktes. Falls das Ende der Liste der Verfügbarkeitsdatenpunkte erreicht wird, kann der Bedarf nicht gedeckt werden und es müssten neue Zugänge (z. B. Bestellungen) veranlasst werden. In diesem Fall wird das frühestmögliche Verfügbarkeitsdatum mit 0D festgelegt.
Aktualisierung von Verfügbarkeitsdatenpunkten
Nach der Mengenzuteilung müssen die Verfügbarkeitsdatenpunkte um die zugeteilten Mengen verringert werden. Dazu werden die vom LINNEP oberen (rechts) und die unteren (links) gelegenen Verfügbarkeitsdatenpunkte separat behandelt. Die zugeteilte Menge umfasst immer auch die Mengen, die zum Bedarfsdatum nicht verfügbar sind (ausgehend vom Bedarfsdatum in der Zukunft liegend), aber im Rahmen der Mengenzuteilung blockiert wurden.
Involvierte Methoden
Obere Verfügbarkeitsdatenpunkte
Die Aktualisierung der oberen Verfügbarkeitsdatenpunkte ist trivial. Technisch werden die Verfügbarkeitsdatenpunkte einfach ausgehend vom LINNEP nach oben (rechts) bis zum Ende durchlaufen und dabei jeweils die zugeteilte Bedarfsmenge von der Menge des Verfügbarkeitsdatenpunktes abgezogen. Fachlich ist dieses Vorgehen auch leicht nachzuvollziehen: Da es sich um kumulierte Mengen handelt und unten (links) die Menge verringert wird, müssen auch alle darüber liegenden Mengen um dieselbe Menge verringert werden.
Beispiel: Aktualisierung obere VDP
Im Beispiel wird zwischen VDP 01.02.20 und VDP 01.03.20 eine Bedarfsmenge von 17 zugeteilt. Dies führt dazu, dass die Bedarfsmenge 17 direkt von VDP 01.02.20 abgezogen wird und als Übertrag auch von den oberen Verfügbarkeitsdatenpunkten VDP 01.03.20 und VDP 01.04.20 abgezogen wird.
Untere Verfügbarkeitsdatenpunkte
Die Aktualisierung der unteren Verfügbarkeitsdatenpunkte gestaltet sich etwas komplexer. Auch hier werden wieder ausgehend vom LINNEP die Verfügbarkeitsdatenpunkte nach unten (links) in Richtung Anfang durchlaufen.
Dabei wird die zugeteilte Bedarfsmenge bei jedem Verfügbarkeitsdatenpunkt um die Differenz zwischen der Menge des aktuellen Verfügbarkeitsdatenpunktes und der Menge seines linken Nachbarn verringert. Der Durchlauf stoppt, sobald die zugeteilte Bedarfsmenge auf Null sinkt oder der Anfang erreicht ist.
Fachlich bedeutet dies, dass die Bedarfsmenge immer zuerst aus dem Zugang zwischen zwei Verfügbarkeitsdatenpunkten bedient wird. Wenn diese Menge nicht ausreicht, wird der chronologisch vorherige Zugang herangezogen. Dies wird so oft wiederholt, bis die Bedarfsmenge vollständig bedient ist oder sämtliche Zugänge, sowie der Lagerbestand (VDP 0D) aufgebraucht sind.
Beispiel: Aktualisierung untere VDP
Hier wieder das Beispiel von oben, diesmal jedoch in die andere Richtung. Die Bedarfsmenge von 17 wird mit dem Zugang zwischen VDP 05.01.20 und VDP 01.02.20 verglichen - es bleibt eine Differenz von 7, die von VDP 05.01.20 abgezogen wird. Die Differenzmenge von 7 wird wiederrum mit dem Zugang zwischen VDP 0D und VDP 05.01.20 verglichen und die Differenz von VDP 0D abgezogen.
Unten noch einmal das gesamte Beispiel mit der Aktualisierung aller Verfügbarkeitsdatenpunkte.
Beispiel: Aktualisierung VDP
Man könnte zu der Überlegung gelangen, dass es ausreichen könnte, die Mengenzuteilung einfach immer bei VDP 0D zu beginnen und dann nur die Aktualisierung der oberen Verfügbarkeitsdatenpunkte durchzuführen. Dies wäre jedoch nur möglich, wenn die Mengenzuteilung in chronologischer Reihenfolge stattfinden würde. Dies ist jedoch nicht der Fall. Sowohl die Aufteilung nach Zuteilungsprioritäten, als auch die Möglichkeit einer beliebigen Sortierung verhindern, dass in jedem Fall eine chronologische Sortierung gegeben sein kann.
Ein weiterer Grund ist, dass in der beschriebenen Überlegung, die Zugänge zwischen den Verfügbarkeitsdatenpunkten nicht zuerst aufgebraucht werden würden, sondern zunächst der Lagerbestand aufgebraucht werden würde. Dies würde dazu führen, dass der Lagerbestand, der gewissermaßen als Joker dient, da er datumsunabhängig zugeteilt werden kann, diese Funktion nicht mehr erfüllen könnte. Somit wäre eine optimale Zuteilung der verfügbaren Mengen zu den Bedarfsmengen unmöglich.
Hinweis
Die Mengenzuteilung ist vollkommen unabhängig davon, wie die einzelnen Belege später im Lager bedient werden. Zum Zeitpunkt des Warenausganges liegt ein Zugang aus der Verfügbarkeitsberechnung schon als Lagerbestand vor und es spielt keine Rolle mehr, aus welchem Zugang dieser Lagerbestand stammt.
Aggregation von Verfügbarkeitsposten
Nach Abschluss der Berechnung werden die relevanten Verfügbarkeitsposten in einen Ergebnisdatensatz übertragen. Dabei findet eine Aggregation der Verfügbarkeitsposten statt, die bei der Datensammlung nach Zuteilungsprioritäten aufgeteilt wurden. Der Ergebnisdatensatz wird später hauptsächlich in der Darstellung für den Anwender und für die Weiterverarbeitung in anderen Modulen verwendet.
Involvierte Methoden
Zunächst werden die zu aggregierenden Verfügbarkeitsposten in einer Schleife durchlaufen. Außerdem wird hier nach der Record ID der dazugehörigen Belegzeile sortiert, sodass die Verfügbarkeitsposten für die einzelnen Zuteilungsprioritäten immer gruppiert pro Belegzeile vorkommen. Zur Aggregation werden einfach die Bedarfsmengen und die berechneten verfügbaren Mengen aufsummiert und in einem einzelnen Verfügbarkeitsposten zusammengefasst. Außerdem wird das späteste frühestmögliche Verfügbarkeitsdatum der Verfügbarkeitsposten für eine Belegzeile als frühestmögliches Verfügbarkeitsdatum für den aggregierten Verfügbarkeitsposten übernommen.
In einer zweiten Schleife werden die Verfügbarkeitsposten, die nicht aggregiert werden müssen, ebenfalls in den Ergebnisdatensatz übertragen.
In beiden Schleifen wird beim Einfügen des Ergebnisverfügbarkeitspostens neben dem Verfügbarkeitsstatus (s. Tabelle Mengenzuteilung) der Belegzeile, auch die Verfügbarkeit des jeweiligen Belegkopfes abgespeichert. Der Verfügbarkeitsstatus der Belegzeile setzt sich aus den Verfügbarkeiten der einzelnen Verfügbarkeitsposten zusammen, während sich der Verfügbarkeitsstatus des Belegkopfes analog aus dem Verfügbarkeitsstatus seiner Belegzeilen zusammensetzt. Für die Verfügbarkeit eines Belegkopfes gelten folgende Bedingungen:
| Status | Bedingung |
|---|---|
| Verfügbar | Alle Zeilen verfügbar |
| Teilweise verfügbar | min. 1 Zeile nicht verfügbar oder teilw. verfügbar |
| Nicht verfügbar | Alle Zeilen nicht verfügbar |
Für die Belegzeilen gelten dieselben Bedingungen, nur dass hier die Verfügbarkeitsposten zu der Belegzeile berücksichtigt werden.
Hinweis
Die Verfügbarkeitsinformationen werden auch in den Arbeitsdatensatz TempGOBAvailabilityEntryOutbound zurückgeschrieben.
Erstellung Belegköpfe
Als abschließender Schritt werden die Belegköpfe als Verfügbarkeitsposten angelegt, nachdem sämtliche Berechnungen abgeschlossen sind und die Verfügbarkeiten feststehen.
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5022209 "GOB Calc Availability by Order" |
CreateHeaderEntries() |
codeunit 5022209 "GOB Calc Availability by Order" |
InsertHeaderRecord() |
Die Verfügbarkeitsinformation für die Belegköpfe aus dem vorherigen Schritt wird in einem Dictionary of [RecordID,Integer] vorgehalten, wobei es sich bei der RecordID um die des Belegkopfes handelt und der Integer-Wert den Verfügbarkeitsstatus kodiert.
Die Belegköpfe können nun erstellt werden, indem für jede RecordID die Belegköpfe aus der Datenbank gelesen und als Verfügbarkeitsposten mit dem entsprechenden Verfügbarkeitsstatus eingefügt werden.
Ausnahmen und Sonderbehandlungen
Es gibt Sonderfälle, für die ein spezielles Handling erforderlich ist oder die völlig separat von der Kernlogik der Verfügbarkeitsberechnung ablaufen müssen.
Liefervorschlag
Im Liefervorschlag dürfen nur Belegzeilen berücksichtigt werden, die vollständig durch physischen Lagerbestand bedient werden können.
Datensammlung
Schon während der Datensammlung werden keine Verfügbarkeitsposten für eingehende Belegzeilen erstellt. Es werden ausschließlich Verfügbarkeitsposten für Artikelposten erstellt. Außerdem findet zusätzlich eine Aufteilung von ausgehenden Belegzeilen statt, die sowohl gegen Lagerbestand, als auch eingehende Belegzeilen reserviert sind. Die Aufteilung funktioniert analog zu der Aufteilung nach den Zuteilungsprioritäten und die entstehenden Verfügbarkeitsposten werden ebenfalls im Anschluss an die Berechnung aggregiert.
Suche nach Verfügbarkeitsdatenpunkt
In der Funktion AssignAvailableQuantities() werden die Verfügbarkeitsposten, die nicht gegen Lagerbestand reserviert sind, komplett von der Berechnung ausgeschlossen, da diese Bedarfe für den Liefervorschlag keine Rolle spielen, die Bedarfsmengen aber sonst dennoch zugeteilt werden würden.
Auftragsmontage
Die Verfügbarkeit von Auftragszeilen mit Auftragsmontage hängt direkt von der Verfügbarkeit der einzelnen Komponenten ab. Dies kann nicht in einem einzelnen Schritt berechnet werden, daher ist die Berechnung der Auftragsmontage zweistufig.
Die Berechnung der Auftragsmontage findet nach der Funktion AssignAvailableQuantities() statt. Zu diesem Zeitpunkt sind also bereits alle "normalen" Verfügbarkeiten berechnet worden.
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5022209 "GOB Calc Availability by Order" |
CalculateAssembly() |
table 5021680 "GOB Availability Entry" |
IsSupplyForSalesOrder() |
In jedem Verfügbarkeitsposten wird festgehalten, ob und welche Menge er zur Auftragsmontage enthält. Diese Mengen werden bei der normalen Verfügbarkeitsberechnung ignoriert und erst in diesem gesonderten Schritt zugeteilt. Die benötigten Komponenten, also die Verfügbarkeitsposten zu den Montageauftragszeilen, wurden zu diesem Zeitpunkt schon berechnet. Es kann jetzt eine Aussage über die Verfügbarkeit, der zu den Montageauftragszeilen gehörenden Auftragszeilen, getroffen werden. Dazu werden zu jeder Auftragszeile die Verfügbarkeitsposten ihrer Komponenten gesammelt und hinsichtlich ihrer Verfügbarkeit geprüft. Hier gelten wieder dieselben Bedingungen für den Verfügbarkeitsstatus, wie bei den Belegköpfen oder bei der Aggregation. Im Anschluss werden, wie bei der normalen Berechnung, die Verfügbarkeiten in die Posten übernommen und die Kopfverfügbarkeiten aktualisiert.
Die Voraussetzung für eine korrekte Erkennung als Auftragsmontage ist, dass der Montageauftrag standardkonform über table 904 "Assemble-to-Order Link" mit einem Verkaufsauftrag verknüpft ist und eine Reservierung der Auftragszeile gegen den Montageauftrag besteht.
Hinweis
Montageauftragszeilen, die nicht mit einem Verkaufsauftrag verknüpft sind, werden immer als bedarfsdeckend betrachtet, da bei fest geplanten/freigegebenen Montageauftragszeilen davon auszugehen ist, dass eine Planung stattgefunden hat und der Montageauftrag fristgerecht erfüllt werden kann. Mengen, die mit einem Verkaufsauftrag verknüpft sind, werden bereits im Schritt "Erstellung der Verfügbarkeitsklassen" ignoriert, damit sie nicht für andere Belege herangezogen werden können. Dies gilt analog für Fertigungsaufträge.
Fertigung
Auch Fertigungsaufträge müssen gesondert behandelt und müssen, ähnlich wie Montageaufträge, in zwei Schritten berechnet werden. Die Besonderheit gegenüber den Montageaufträgen ist hier, dass ein Fertigungsauftrag auch zum Teil seinen eigenen Bedarf decken kann. Es ist zum Beispiel möglich mehrstufige Fertigungsaufträge zu erstellen, in denen auf den unteren Ebenen Komponenten für die oberen Ebenen gefertigt werden.
Involvierte Methoden
Nach der Berechnung werden außerdem die Verfügbarkeitsposten für Fertigungsauftragszeilen in den Ergebnisdatensatz übertragen, obwohl es sich eigentlich um eingehende Verfügbarkeitsposten handelt. Das liegt daran, dass eine Fertigungsauftragszeile sowohl bedarfsdeckend ist, als auch selbst eine Verfügbarkeit haben kann, die dem Anwender angezeigt werden soll.
Auftragsfertigung
Die Verfügbarkeitsberechnung für die Auftragsfertigung verläuft analog zur Verfügbarkeitsberechnung derAuftragsmontage.
Als Bedingung für die Erkennung als Auftragsfertigung gilt hier, dass eine 1:1 Reservierung zwischen einer Fertigungsauftragszeile mit "Planning Level Code" = 0 und einer Verkaufsauftragszeile besteht. Die 1:1 Reservierung bedeutet, dass die gesamte Menge in der Verkaufsauftragszeile gegen die Fertigungsauftragszeile reserviert werden muss. Reservierte Teilmengen werden nicht berücksichtigt.
Mehrstufige Fertigung
Auch die Verfügbarkeitsberechnung für mehrstufige Fertigungsaufträge verläuft zunächst analog zur Verfügbarkeitsberechnung für Auftragsmontage.
Dadurch, dass vor der Berechnung gemäß dem "Planning Level Code" sortiert wird, ist sichergestellt, dass zuerst die Fertigungsauftragszeilen berechnet werden, die sowohl von anderen Zeilen aus dem Fertigungsauftrag abhängen, sowie auch als Bedarfsdecker für andere Zeilen aus dem Fertigungsauftrag dienen. Somit findet die Berechnung ausgehend von der untersten Ebene nach oben statt und jede Ebene kann mit ihrer berechneten Verfügbarkeit in die Berechnung der nächsten Ebene einfließen. Die Komponentenzeilen, die nicht von anderen Zeilen und nicht durch andere Fertigungsauftragszeilen bedient werden, wurden zu diesem Zeitpunkt bereits über die normale Verfügbarkeitsberechnung berechnet.
Sollte bei dieser Berechnung festgestellt werden, dass eine Fertigungsauftragszeile nicht vollständig verfügbar ist, so wird für die Restmenge eine modifizierte Beschaffungszusage durchgeführt. Dies ist notwendig, um für jede Zeile ein frühestmögliches Warenausgangsdatum zu ermitteln und dabei auch die Fertigungsdauer zu berücksichtigen. Die Modifikation an der Beschaffungszusage besteht darin, dass die nicht abgerufenen Komponenten, sowie der Hauptartikel selbst aus der Berechnung ausgeschlossen werden, da sonst die Bedarfe und Bedarfsdecker in der Beschaffungszusage nicht korrekt berücksichtigt werden würden. Somit erhält jede Zeile ein frühestmögliches Warenausgangsdatum, was insbesondere für die Verzögerungsprotokollierung und die Aktualisierung eines eventuell vorhandenen Verkaufsauftrages wichtig ist.
Hinweis
Bei der Beschaffungszusage für Fertigungsaufträge an dieser Stelle wird die Kapazität der Fertigungsressourcen ignoriert! Das berechnete Datum ist also immer unabhängig von der Fertigungsplanung zu betrachten. Außerdem findet die Priorisierung der Belegarten aus der Verfügbarkeitseinrichtung hier keine Anwendung, da die Beschaffungszusage dieses Konzept nicht kennt.
Maske: Fertigungsauftrag Verfügbarkeit
In dieser Maske gibt es zusätzlich noch die Möglichkeit, eingehende Warenbegwegungen bei der Berechnung zu ignorieren. Die Berechnung wird dann, ähnlich wie beim Liefervorschlag, nur gegen den existierenden Lagerbestand vorgenommen. Dadurch ergibt sich ein Überblick über die Fertigungsaufträge, die zum jetzigen Zeitpunkt ausgeführt werden könnten.
Direkt-/Speziallieferung
Direkt- und Speziallieferungen dürfen nicht zusammen mit anderen Belegen berechnet werden, da hier eine 1:1 Zuordnung besteht und die Verknüpfung mit dem Einkaufsbeleg eine besondere Rolle für die Verfügbarkeit spielt.
Datensammlung
Artikelposten, die zu einem bereits gelieferten Einkaufsbeleg zu einem Direkt-/Spezialauftrag gehören, werden nicht als eingehende Verfügbarkeitsposten berücksichtigt und fließen somit nicht in die Berechnung ein. Das überprüfte Kriterium ist der Einkaufscode des Artikelpostens.
Suche nach Verfügbarkeitsdatenpunkt
In der Funktion AssignAvailableQuantities() werden die Verfügbarkeitsposten, die vom Verkaufsbeleg stammen, komplett von der Berechnung ausgeschlossen. Ihre Berechnung findet später in einer separaten Funktion statt.
Kriterium für die Identifizierung von Direkt-/Spezialpositionen sind die entsprechenden Boolean-Felder in der Verkaufszeile.
Verfügbarkeit
Direkt-/Spezialpositionen durchlaufen keine Verfügbarkeitsberechnung im eigentlichen Sinne, sondern die Verfügbarkeit hängt von anderen Kriterien ab. Zunächst wird versucht, ausgehend vom Direkt-/Spezialauftrag, über die standardmäßig vorhandenen Felder die dazugehörige Direkt-/Spezialbestellung zu ermitteln. Falls dies nicht möglich ist, wird zusätzlich auch nach einer gebuchten Einkaufslieferung zur gesuchten Direkt-/Spezialbestellung gesucht. Für die Verfügbarkeit der Direkt-/Spezialbestellung gilt nun Folgendes:
| Status | Bedingung |
|---|---|
| Verfügbar | Bestellung/Lieferung gefunden; gelieferte Menge >= Bedarfsmenge |
| Teilweise verfügbar | Bestellung/Lieferung gefunden; Menge irrelevant |
| Nicht verfügbar | Keine Bestellung/Lieferung gefunden |
Für das frühestmögliche Verfügbarkeitsdatum gilt das erwartete Wareneingangsdatum aus der Bestellzeile. Falls keine Bestellzeile vorhanden ist, entspricht das frühestmögliche Verfügbarkeitsdatum 0D.