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.
Warenausgangsdatumsprojektion
Das Ziel der Warenausgangsdatumsprojektion ist es, eine realistische Aussage über das frühestmögliche Warenausgangsdatum von Belegen zu treffen. Dabei wird die unitop Verfügbarkeitsberechnung mit der Beschaffungszusage aus dem Business Central Standard kombiniert.
Konzept
Die Warenausgangsdatumsprojektion ist als automatischer Prozess konzipiert und funktioniert so auch am besten. Eine komplett manuelle Ausführung ist allerdings auch möglich.
Bei der Warenausgangsdatumsprojektion für eine neue Belegzeile wird zunächst eine Verfügbarkeitsberechnung durchgeführt. Dabei wird die Belegzeile mit der niedrigsten Zuteilungspriorität behandelt, also quasi "hintenan gestellt". Dadurch wird sichergestellt, dass durch die neue Belegzeile die Warenausgangsdaten von anderen Belegzeilen, für die bereits eine Warenausgangsdatumsprojektion durchgeführt wurde, nicht beeinflusst wird.
Belegzeilen, für die bereits eine Warenausgangsdatumsprojektion durchgeführt wurde, werden nicht mit verringerter Zuteilungspriorität behandelt, sondern fließen ganz normal in die Berechnung ein. In diesem Fall verändert sich das Warenausgangsdatum nur, wenn sich allgemein etwas an der Verfügbarkeit geändert hat.
Falls die unitop Verfügbarkeitsberechnung keine Aussage zum frühestmöglichen Warenausgangsdatum liefert oder sich das zurückgelieferte Datum außerhalb des Wiederbeschaffungszeitraumes befindet, wird zusätzlich die Beschaffungszusage durchgeführt. In diesem Fall entspricht das frühestmögliche Warenausgangsdatum dem Lieferdatum von Ware, die noch am selben Tag bestellt werden würde.
Die Warenausgangsdatumsprojektion wird auch zur Verzögerungsprotokollierung und in leicht abgewandelter Form, zur Detektion von Reservierungskonflikten, verwendet.
Ablauf Warenausgangsdatumsprojektion
Voraussetzungen
Als Grundvoraussetzung muss eine Einrichtung für das Business Central Modul Beschaffungszusage vorhanden sein. Außerdem ist es erforderlich, dass in der Belegzeile ein Lagerort, der eine Verfügbarkeitseinrichtung zugewiesen hat, eingetragen ist. Für die automatische Warenausgangsdatumsprojektion bei der Dateneingabe, muss diese darüber hinaus in der Erweitertes Artikelmanagement Einrichtung aktiviert sein. Dort findet sich auch eine Action zur Erstellung eines Aufgabenwarteschlangenpostens, um eine periodische Aktualisierung der Warenausgangsdaten zu ermöglichen.
Ein Feld Warenausgangsdatumsber. Status gibt über den Status der Warenausgangsdatumsprojektion Auskunft.
| Status | Bedeutung |
|---|---|
| Initial | Keine Berechnung hat stattgefunden |
| Berechnet | Das WA-Datum wurde berechnet |
| Manuell | Das WA-Datum wurde manuell vom Anwender überschrieben |
| Verzögert | Das WA-Datum kann nicht gehalten werden |
Hinweis
Die Warenausgangsdatumsprojektion und die davon abhängigen Funktionen sind momentan ausschließlich für Verkaufsaufträge implementiert. (siehe auch Erweiterbarkeit)
Manuelle Ausführung
Sobald die oben beschriebenen Einrichtungen für Beschaffungszusage und Verfügbarkeitseinrichtung vorhanden sind kann die Warenausgangsdatumsprojektion, aus einem Beleg heraus, gestartet werden. Dazu gibt es die Möglichkeit, die Warenausgangsdatumsprojektion über eine Action ("Neuberechnung Warenausgangsdatum") für eine einzelne Belegzeile oder aber für den gesamten Beleg auszuführen.
Automatismen
Zusätzlich zur manuellen Ausführung gibt es verschiedene automatisierte Möglichkeiten zur Ausführung der Warenausgangsdatumsprojektion.
Periodische Ausführung
Wenn ein Aufgabenwarteschlangenposten zur Aktualisierung der Warenausgangsdaten eingerichtet wurde, so werden fortlaufend die Warenausgangsdaten für alle Lagerorte mit entsprechender Verfügbarkeitseinrichtung aktualisiert. Dazu muss in der Verfügbarkeitseinrichtung die automatische Neuberechnung aktiviert sein. Die periodische Aktualisierung ist besonders dann sinnvoll, wenn auch die Verzögerungsprotokollierung aktiv ist.
Hinweis
Über den periodischen Job in der Aufgabenwarteschlange, werden immer alle relevanten Belege aktualisiert, während die Aktualisierung bei der Dateneingabe oder durch Actions immer nur einen einzelnen Beleg betrifft. Im letzteren Fall kann es also vorkommen, dass die nicht aktualisierten Belege zu einem früheren Datum verfügbar wären, aber dennoch ihr aktuelles Warenausgangsdatum beibehalten.
Dateneingabe
Die Warenausgangsdatumsprojektion kann bei bestimmten Feldvalidierungen automatisch ausgelöst werden. Auf diesem Weg, der ausgelösten Neuberechnungen des Warenausgangsdatums, werden immer mit verringerter Zuteilungspriorität, also wie neu angelegte Belegzeilen, behandelt. Dies ist erforderlich, da die Datenänderung (z. B. Änderung der Menge) sonst Auswirkungen auf andere, bereits mit der Warenausgangsdatumsprojektion geplante, Belegzeilen haben könnte.
Diese Einschränkung verhindert, dass (z. B. durch Erhöhung der Menge) Verzögerungen in anderen Belegen entstehen können, also das berechnete Warenausgangsdatum einer Belegzeile nicht mehr eingehalten werden kann. Es kann jedoch vorkommen, dass (z. B. durch Verringerung der Menge) das frühestmögliche Warenausgangsdatum in einem anderen Beleg (theoretisch) nach vorne verschoben werden könnte, aber das neue frühestmögliche Warenausgangsdatum erst bei einer Neuberechnung der Belegzeile berücksichtigt wird.
Folgende Feldvalidierungen bzw. Aktionen lösen die Warenausgangsdatumsprojektion aus:
- Lagerort
- Variantencode
- Menge
- Einkaufscode
- Menge für Auftragsmontage
- Lieferanweisung
- Kopieren von Belegzeilen
Erweiterbarkeit
Die Erweiterung der Warenausgangsdatumsprojektion ist möglich, aber gegebenenfalls mit redundantem Code verbunden.
Relevante Methoden
Die Warenausgangsdatumsprojektion und ihre abhängigen Anwendungen Detektion von Reservierungskonflikten und Verzögerungsprotokollierung wurden auf Grundlage von Verkaufsaufträgen spezifiziert und umgesetzt. Die Kernfunktionalitäten sind jedoch generisch umgesetzt und die Warenausgangsdatumsprojektion könnte mit etwas Aufwand für weitere Belegarten analog zu den Verkaufsaufträgen implementiert werden. Die Implementierung würde sich hier hauptsächlich in der Verwendung einer anderen Record-Variablen unterscheiden.
Im Falle der Verzögerungsprotokollierung hat eine eingehendere Vorbereitung auf die Erweiterung um weitere Belegarten stattgefunden. Die Erweiterung ist hier mit minimalen Eingriffen möglich.
Detaillierter Ablauf
Im Folgenden wird der Ablauf der Warenausgangsdatumsprojektion detailliert behandelt und auch auf Sonderfälle und Einschränkungen eingegangen. Hierbei wird die Berechnung für eine einzelne Belegzeile zugrunde gelegt. Für andere Einstiegspunkte läuft die Berechnung weitestgehend analog ab. Unterschiede sind rein struktureller Natur.
Datensammlung
Der Erste Schritt ist die Datensammlung.
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5022209 "GOB Calc Availability by Order" |
Preprocessing() |
Zur Datensammlung wird dieselbe Methode verwendet, wie bei der Datensammlung für die Verfügbarkeitsberechnung. Unterschiede finden sich in der Filterung, da die Warenausgangsdatumsprojektion ausgehend von einem Beleg, einer Belegzeile oder per Aufgabenwarteschlange, aufgerufen wird.
| Aufruf | Filterung |
|---|---|
| Beleg | Filter auf alle Lagerorte, Artikel und Varianten die in den Zeilen vorkommen |
| Belegzeile | Filter auf Lagerort, Artikel, Variante |
| Aufgabenwarteschlange | Filter auf alle Lagerorte mit automatischer Neuberechnung |
Anpassung Eingabedaten
Als Nächstes wird der in der Datensammlung ermittelte Datensatz modifiziert.
Involvierte Methoden
Es werden zunächst alle gesammelten ausgehenden Verfügbarkeitsposten zu der zu berechnenden Belegzeile gelöscht. Danach werden die Verfügbarkeitsposten modifiziert wieder eingefügt. Ziel ist es, die Zuteilungspriorität von neu angelegten Belegzeilen zu verringern damit diese erst nach den bereits berechneten Belegzeilen berücksichtigt werden. Die Verringerung der Zuteilungspriorität findet nur statt, wenn das Feld Warenausgangsdatumsber. Status der Belegzeile den Status "Initial" hat. Ansonsten wird die normale Zuteilungspriorität der Belegart verwendet.
Als zweite wichtige Modifikation sei die Änderung des Bedarfsdatum zu erwähnen. Bei einer normalen Verfügbarkeitsberechnung entspricht das Bedarfsdatum immer dem Warenausgangsdatum in der Belegzeile. Da bei der Warenausgangsdatumsprojektion aber das frühestmögliche Warenausgangsdatum ab dem jetzigen Zeitpunkt berechnet werden soll, wird das Bedarfsdatum für Belegzeilen mit dem Warenausgangsdatumsber. Status "Initial" auf das Arbeitsdatum gesetzt.
Außerdem werden sämtliche ausgehende Verfügbarkeitsposten für andere Belege gelöscht, sofern diese den Warenausgangsdatumsber. Status "Initial" haben. Da für diese Belegzeilen noch keine Warenausgangsdatumsprojektion durchgeführt wurde, könnten ihre Bedarfe mit den Belegzeilen in der aktuellen Berechnung kollidieren und somit das Ergebnis verfälschen. Zeilen mit dem Warenausgangsdatumsber. Status "Initial" werden also nachrangig behandelt, weil sie als ungeplant anzusehen sind.
Die auf diesem Wege neu eingefügten Verfügbarkeitsposten entsprechen, abgesehen von den Modifikationen, ganz normalen Verfügbarkeitsposten, wie sie auch bei der Datensammlung für die Verfügbarkeitsberechnung angelegt werden.
Verfügbarkeitsberechnung
Die Verfügbarkeitsberechnung wird ohne weitere Anpassungen durchgeführt.
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5022209 "GOB Calc Availability by Order" |
CalcAvailabilityByOrder() |
Die Verfügbarkeitsposten für die Belegköpfe werden ausgelassen, da diese nicht benötigt werden. Für den weiteren Verlauf der Warenausgangsdatumsprojektion ist hier das frühestmögliche Verfügbarkeitsdatum als Ergebnis aus der Verfügbarkeitsberechnung relevant.
Beschaffungszusage
Falls das frühestmögliche Warenausgangsdatum außerhalb des Wiederbeschaffungszeitraumes liegt, wird im Nachgang die Beschaffungszusage ausgeführt.
Involvierte Methoden
| Objekt | Methode |
|---|---|
codeunit 5234592 "GOB Shipment Date Projection" |
ProcessCalculationResult() |
codeunit 5234592 "GOB Shipment Date Projection" |
GetReplenishmentLeadTimePeriod() |
codeunit 5404 "Lead-Time Management" |
PurchaseLeadTime() |
codeunit 5404 "Lead-Time Management" |
SafetyLeadTime() |
codeunit 5234592 "GOB Shipment Date Projection" |
GetWhseInBoundHandlingTime() |
codeunit 5404 "Lead-Time Management" |
PlannedEndingDate() |
codeunit 5234592 "GOB Shipment Date Projection" |
CalculateCTPDecision() |
codeunit 5234592 "GOB Shipment Date Projection" |
CalcCTP() |
codeunit 5234592 "GOB Shipment Date Projection" |
CalcCTPForATO() |
Wiederbeschaffungszeitraum
Der Wiederbeschaffungszeitraum eines Artikels ist definiert, als die Zeit, die von Bestellung eines Artikel bis zu seiner Verfügbarkeit im Lager vergeht.
Für die Warenausgangsdatumsprojektion ist die Wiederbeschaffungszeit definiert als: Wiederbeschaffungszeit := Beschaffungszeit + Eingehende Lagerdurchlaufzeit + Sicherheitszuschlag Beschaffungszeit.
Der Wiederbeschaffungszeitraum ergibt sich dann als [Startdatum..Enddatum] = [Arbeitsdatum..Arbeitsdatum + Wiederbeschaffungszeit]. Bei der Berechnung des Enddatums wird der Kalender des jeweiligen Lagerortes und des Artikellieferanten berücksichtigt.
Hinweis
Bei der Formel zur Wiederbeschaffungszeit werden Begrifflichkeiten aus Business Central verwendet. Mit Beschaffungszeit ist die Zeit von Bestellaufgabe beim Kreditor bis Wareneingang am Lager gemeint.
Berechnung der Beschaffungszusage
Unter folgenden Bedingungen wird eine Beschaffungszusage durchgeführt:
- frühestmögliches Warenausgangsdatum =
0D: Verfügbarkeitsberechnung konnte keine Aussage über das frühestmögliche Warenausgangsdatum treffen - frühestmögliches Warenausgangsdatum < Arbeitsdatum: Lieferung hätte schon gebucht werden müssen
- frühestmögliches Warenausgangsdatum > Arbeitsdatum + Wiederbeschaffungszeit: eine neue Bestellung wäre schneller als der geplante Zugang
- Die Belegzeile ist nicht vollständig gegen einen Zugang reserviert. Ansonsten gälte frühestmögliches Warenausgangsdatum = Wareneingangsdatum des Zugangs
Zusätzlich werden in der Funktion CalcCTP() nur nicht reservierte Mengen berücksichtigt. Reservierte Bedarfsmengen werden als zum Bedarfsdatum verfügbar und das Bedarfsdatum somit als einhaltbar betrachtet. Diese Einschränkung würde 4. bereits beinhalten, aber da die Funktion auch innerhalb der Funktion CalcCTPForATO() aufgerufen wird, ist die redundante Einschränkung notwendig.
Für Auftragsmontagepositionen wird die Beschaffungszusage für alle Komponenten im verknüpften Montageauftrag durchgeführt. Für die Komponenten findet keine Prüfung des Beschaffungszeitraumes statt, sondern es wird lediglich überprüft, ob die Verfügbarkeitsberechnung ein frühestmögliches Warenausgangsdatum ermitteln konnte. Wenn dies der Fall ist, wird keine Beschaffungszusage durchgeführt. Das frühestmögliches Warenausgangsdatum der Belegzeile entspricht dem spätesten ermittelten Warenausgangsdatum der Komponenten (analog zur Verfügbarkeitsberechnung für Montageaufträge). Für Lagermontage und Fertigungsaufträge wird keine Beschaffungszusage durchgeführt, da hierbei angenommen wird, dass eine feste Planung stattgefunden hat und das Fertigstellungsdatum eingehalten wird.
Die Beschaffungszusage wurde dahingehend erweitert, dass auch Belege, die in der Standard-Beschaffungszusage nicht berücksichtigt werden, aber dennoch zu einer Warenbewegung führen könnten (Rechnungen, Gutschriften), in der Berechnung herangezogen werden. Dies gilt natürlich nur für Rechnungen und Gutschriften, die nicht mit einem Auftrag oder einer Reklamation verknüpft sind.
Aktualisierung des Beleges
Im letzten Schritt muss das Ergebnis in den Beleg übernommen werden.
Involvierte Methoden
Hinweis
Da die Warenausgangsdatumsprojektion nur für Verkaufsaufträge implementiert wurden und die Aktualisierung des Beleges im Allgemeinen belegspezifisch ablaufen muss, behandeln die folgenden Ausführungen ausschließlich Verkaufsaufträge.
Belegzeile
Falls weder die Verfügbarkeitsberechnung, noch die Beschaffungszusage ein frühestmögliches Warenausgangsdatum ermitteln können, behält die Verkaufsauftragszeile ihr aktuelles Warenausgangsdatum und das Feld Warenausgangsdatumsber. Status bleibt in dem Status "Initial".
Sollte auch das aktuelle Warenausgangsdatum 0D sein, so wird das Warenausgangsdatum mit dem Arbeitsdatum vorbelegt. Bei den manuellen Einstiegspunkten und bei der Dateneingabe erhält der Anwender eine Mitteilung (kein Laufzeitfehler).
Bei einer erfolgreichen Berechnung des frühestmöglichen Warenausgangsdatums, wird dieses Datum als Warenausgangsdatum in die Verkaufsauftragszeile übernommen, falls das Datum von dem alten Warenausgangsdatum abweicht. Dabei findet eine Validierung statt. Das Feld Warenausgangsdatumsber. Status wird auf "Berechnet" gesetzt.
Belegkopf
Das Warenausgangsdatum im Verkaufsauftragskopf wird nach der Aktualisierung der Zeilen abhängig von der Versandanweisung aktualisiert.
| Versandanweisung | Auswirkung |
|---|---|
| Komplettlieferung | WA-Datum = max. WA-Datum aus Zeilen; WA-Datum wird auch in alle Zeilen übernommen |
| Teillieferung | WA-Datum = min. WA-Datum aus Zeilen |
Falls im Verkaufskopf ein zugesagtes Lieferdatum angegeben ist, findet auch hier eine Aktualisierung statt. Liegt das zugesagte Lieferdatum vor dem maximalen Warenausgangsdatum der Zeilen, also wenn das zugesagte Lieferdatum nicht für alle Zeilen eingehalten werden kann, wird nach einer Benutzerabfrage das maximale Warenausgangsdatum als neues zugesagtes Lieferdatum für den Kopf übernommen. Bei Komplettlieferung wird das Datum auch hier in alle Zeilen übernommen. Sollte das zugesagte Lieferdatum nach dem minimalen Warenausgangsdatum der Zeilen liegen, also wenn ein früheres Lieferdatum möglich wäre, erfolgt eine Benutzerabfrage. Abhängig von der Eingabe des Anwenders, wird entweder das eingetragene zugesagte Lieferdatum oder aber das frühere Lieferdatum für alle Zeilen übernommen. Die Übernahme des früheren Lieferdatums in alle Zeilen gilt nicht bei der Versandanweisung "Teillieferung".
| Bedingung | Auswirkung | ||
|---|---|---|---|
| A | zug. Lieferdatum < max. WA-Datum aus Zeilen | Confirm: zug. Lieferdatum := max. WA-Datum aus Zeilen; zug. Lieferdatum wird bei Komplettlieferung auch in alle Zeilen übernommen | |
| B | zug. Lieferdatum > min. WA-Datum aus Zeilen | Benutzerabfrage: Übernahme zug. Lieferdatum | min. WA-Datum in alle Zeilen1 |
1abhängig v. Versandanweisung
Ausnahmen bei Ausführung über Aufgabenwarteschlange
Die Besonderheit bei der Ausführung über die Aufgabenwarteschlange ist, dass in diesem Fall die Warenausgangsdaten für alle relevanten Belege neu berechnet und in die Belege zurückgeschrieben werden. Daher gibt es bei der Aktualisierung der Belege einige Ausnahmen und Einschränkungen.
| Bedingung | Auswirkung |
|---|---|
Ergebnis nach Verfügbarkeitsberechnung + Beschaffungszusage = 0D |
keine Aktualisierung der Belege; auch keine Verzögerungsprotokollierung |
| Punkt A aus obiger Tabelle | Übernahme max. WA-Datum aus Zeilen ohne Confirm in alle Zeilen |
| Punkt B aus obiger Tabelle | Option 1 ist der Standardwert und wird automatisch gewählt |
| Alle Belege (außer Verkaufsauftrag, Lagermontage und Fertigungsauftrag) | Berechnetes Datum wird mit Validierung in Belegzeile übernommen |
Hinweis
Bei Lagermontageaufträgen und Fertigungsaufträgen findet keine Aktualisierung des Fertigstellungsdatums statt, da diese Belege als fest geplant angesehen werden müssen und ihr Fertigstellungsdatum somit fix ist. Dadurch kann es vorkommen, dass bei der Sortiermethode "Warenausg.-Datum; Belegart; Belegnr." z. B. Verkaufsaufträge nach hinten verlagert werden, wenn gleichzeitig Fertigungs-/Montagekomponenten zum Verkauf angeboten werden. Da sich das Warenausgangsdatum im Verkaufsauftrag nach hinten verschieben kann, im Montage-/Fertigungsauftrag jedoch nicht, würde die Verschiebung dazu führen, dass bei der nächsten Berechnung der Montage-/Fertigungsauftrag vor dem Verkaufsauftrag bedient werden würde, obwohl dieser ursprünglich zuerst hätte bedient werden müssen. Die Sortiermethode "Erstellungszeitpunkt (belegunabhängig)" ist von dieser Einschränkung nicht betroffen. Abhilfe kann z. B. durch die Verwendung von dedizierten Montage-/Fertigungslagerplätzen oder die geschickte Verwendung von Reservierungen oder Warenausgängen geschaffen werden.
Verzögerungsprotokollierung
Aus der Warenausgangsdatumsprojektion lässt sich zusätzlich ableiten, ob eine Verzögerung vorhanden ist. Dazu muss einfach nur das neu berechnete Warenausgangsdatum mit dem ursprünglichen Warenausgangsdatum in der Belegzeile verglichen werden.
Involvierte Methoden
Erstellung von Verzögerungsposten
Verzögerungsposten können an zwei Stellen erzeugt werden: Bei der Warenausgangsdatumsprojektion über die Aufgabenwarteschlange oder bei der Änderung des Wareneingangsdatums in einer Bestellung. Beide Varianten benötigen eine entsprechende Verfügbarkeitseinrichtung. Die zweite Option muss zusätzlich aktiviert werden. Technisch werden beide Varianten über denselben Code realisiert. Ein Verzögerungsposten wird angelegt wenn alle diese Bedingungen erfüllt sind:
- berechnetes Warenausgangsdatum <>
0D(also Warenausgangsdatumsprojektion erfolgreich) - berechnetes Warenausgangsdatum > ursprüngliches Warenausgangsdatum
- ursprüngliches Warenausgangsdatum - berechnetes Warenausgangsdatum > Verzögerungstoleranz
Das ursprüngliche Warenausgangsdatum entspricht dem Warenausgangsdatum der Belegzeile vor der Warenausgangsdatumsprojektion und wird ebenfalls im Verzögerungsposten gespeichert. Falls bereits ein Verzögerungsposten für die Belegzeile existiert, so wird stattdessen das ursprüngliche Warenausgangsdatum aus dem Verzögerungsposten genommen. Verzögerungen können also auch akkumuliert werden. Mit dem Einfügen des Verzögerungspostens wird das Feld Warenausgangsdatumsber. Status auf "Verzögert" gesetzt.
Der Einstieg in die Prüfungslogik ist die Funktion UpdateShipmentDates(). Wird diese ohne den Parameter HideConfirmation aufgerufen, was der Fall ist, wenn die Prüfung auf Verzögerungen bei der Änderung des Wareneingangsdatums in einer Bestellung ausgelöst wird, wird abhängig von der Einrichtung, eine Confirm-Abfrage gestartet, mit der Benutzer die Aktualisierung des Warenausgangsdatums und auch die Erstellung des Verzögerungspostens unterbrechen können.
Löschen von Verzögerungsposten
Verzögerungen können manuell "erledigt" werden. Dies könnte zum Beispiel eine Benachrichtigung des Kunden und die Akzeptanz des verzögerten Warenausgangsdatums als neues Warenausgangsdatum sein. Technisch gesehen werden die Verzögerungsposten dazu einfach gelöscht und das Feld Warenausgangsdatumsber. Status der Belegzeile wird auf "Berechnet" gesetzt, da es sich bei dem Warenausgangsdatum um einen berechneten Wert handelt und nun keine Verzögerung mehr vorliegt. Darüber hinaus ist eine automatische Löschung in folgenden Fällen vorgesehen:
- Warenausgangsdatumsber. Status ändert sich von "Verzögert" auf einen anderen Wert
- Löschen der zugehörigen Belegzeile
- Neuerstellung der Belegzeile
Detektion von Reservierungskonflikten
Die Detektion von Reservierungskonflikten verwendet eine ähnliche Vorgehensweise wie die Warenausgangsdatumsprojektion. Ein Reservierungskonflikt liegt vor, wenn sich durch eine neue Reservierung für eine Belegzeile das Warenausgangsdatum anderer Belegzeilen ändert. Die Grundidee ist, dass die Verfügbarkeitsberechnung zweimal durchgeführt wird - einmal mit und einmal ohne die neue Reservierung. Danach wird überprüft, ob sich Warenausgangsdaten verschoben haben.
Involvierte Methoden
Zunächst wird eine ganz normale Verfügbarkeitsberechnung durchgeführt und das Ergebnis temporär gespeichert. Danach werden, wie im Schritt Anpassung Eingabedaten, die Rohdaten für die Verfügbarkeitsberechnung gesammelt und anschließend angepasst. Bei der Anpassung der Eingabedaten wird jedoch die Zuteilungspriorität erhöht statt verringert. Folgende Schritte werden durchgeführt:
- Löschen aller Verfügbarkeitsposten zur Belegzeile
- Einfügen eines Verfügbarkeitspostens für die Reservierungsmenge
- Einfügen eines Verfügbarkeitspostens für die evtl. verbliebene normale Bedarfsmenge
- Einfügen eines Verfügbarkeitspostens für evtl. vorhandene Bedarfsmengen im Warenausgang
Die Verfügbarkeitsposten werden analog zur Datensammlung für die Verfügbarkeitsberechnung eingefügt und haben dieselben Eigenschaften hinsichtlich ihrer Zuteilungspriorität.
Es folgt die zweite Verfügbarkeitsberechnung. Zusammen mit dem oben gespeicherten Ergebnis bestehen zwei Sätze von Verfügbarkeitsposten, die miteinander verglichen werden können. Für jeden Verfügbarkeitsposten für den Satz ohne Reservierung wird das errechnete frühestmögliche Warenausgangsdatum mit dem korrespondieren Verfügbarkeitsposten aus dem Satz mit Reservierung abgeglichen. Ein Reservierungskonflikt liegt vor wenn:
- frühestmögliches Warenausgangsdatum mit Reservierung > frühestmögliches Warenausgangsdatum ohne Reservierung
- frühestmögliches Warenausgangsdatum mit Reservierung =
0Dund frühestmögliches Warenausgangsdatum ohne Reservierung <>0D
Sollte ein Reservierungskonflikt gefunden werden, so wird entsprechend der Einrichtung der Anwender informiert.