Allgemeines

Der wesentliche Aspekt der dynamisch gesteuerten Artikel liegt darin, dass die gesamte Angebots- und Nachfragesituation zeitpunktbezogen betrachtet wird und auf jede konkrete Nachfrage eingegangen wird, indem versucht wird, diese in adäquater Weise zu decken. Das heißt zum einen, dass jeder Nachfrage möglichst zeitnah ein entsprechendes vorläufiges Angebot, also ein Bestell-, ein Fertigungs- bzw. ein Transfervorschlag, gegenübergestellt wird, zum anderen aber auch, dass verschiedene Nachfragen innerhalb gewisser Zeiträume zu einer Gesamtnachfrage zusammengefasst werden können, für die ein entsprechendes vorläufiges Angebot erstellt wird (Losgrößenbildung).

Unter den dynamischen Dispositionsarten lassen sich im Hinblick auf den Anstoß zu Beschaffungsvorschlägen zwei Gruppen unterscheiden:
Die erste Gruppe umfasst die "diskreten" Dispositionsarten:

  • die diskret einzelgeplante Disposition (DEP)
  • die hart plangesteuerte Disposition

Die zweite Gruppe umfasst die "kontinuierlichen" Dispositionsarten:

  • die bedarfsgesteuerte Disposition
  • die bedingt plangesteuerte Disposition.

Bei der ersten Gruppe der diskreten Dispositionsarten werden die Nachfragen direkt in entsprechende Beschaffungsvorschläge umgesetzt, die dann auch den konkreten Nachfrager als Direktverursacher eingetragen bekommen. Der Vorschlag ist damit dazu bestimmt, die Nachfrage genau dieses Nachfragers und keines anderen zu befriedigen. 

Bei der zweiten Gruppe der kontinuierlichen Dispositionsarten erfolgt der Anstoß für die Erstellung eventuell notwendiger Beschaffungsvorschläge erst mit Lauf des Programms Unterdeckungsprüfung für dynamisch gesteuerte Artikel (Netchange) (DI53030), wodurch die Zusammenfassung mehrerer Nachfragen zu vernünftigen Losgrößen ermöglicht wird; einen unmittelbaren Bezug zu einem konkreten Nachfrager gibt es hier in der Regel nicht.

Grundlage der Unterdeckungsprüfung ist, dass die Disposition die Angebots- und Nachfragesituation eines jeden dynamisch gesteuerten Artikels tagesgenau im Zugriff hat. Diese Informationen werden im Zuge der Verbuchung entsprechender Bewegungen (Bestellungen, Wareneingänge, Kundenaufträge, Lieferscheinerstellung usw.) über die zentrale Verbuchungsschnittstelle an das Modul Disposition weitergegeben und dort entsprechend aktuell in einer eigenen Datei ("Dispo-Datei") vorgehalten. Dies erfolgt separat für jede angesprochene Lagergruppe. 

Die Dispo-Datei enthält alle Informationen zur Angebots- und Nachfragesituation, insbesondere auch den aktuell zugrunde gelegten Dispositionsbestand. Dieser gibt den für die Disposition dieser dynamisch gesteuerten Artikel maßgeblichen Lagerbestand wieder. Er ergibt sich immer auf der Basis des Dispositionsbestandes, kann aber über den Dispositionsschlüssel (Parameter 14 der FRD482) bzw. Parameter 02 der Vorlauftabelle VRLD14 entweder um den Sicherheitsbestand oder den Meldebestand reduziert werden. Eine solche Berücksichtigung bewirkt, dass der Unterdeckungsprüfungslauf schon dann Beschaffungsvorschläge macht, wenn z.B. der Sicherheitsbestand angegriffen werden müsste, um Nachfragen zu befriedigen. Der Sicherheitsbestand (in diesem Fall) erfüllt die Funktion der eisernen Reserve.

Beispiel: 
Parameter 02, VRLD14, steht auf '"Sicherheitsbestand",
FRD482 steht auf "schau auf VRLD14"
Artikel 4711, Lagergruppe WERK-01:
Dispositionsbestand: 100 Stück
Sicherheitsbestand: 15 Stück
→Aktuell zugrunde gelegter Dispositionsbestand: 85 Stück.

Über Parameter 02 der VRLD14 wird diese Steuerung des aktuell zugrunde gelegten Dispositionsbestandes für alle Artikel gleich festgelegt. Eine Verfeinerung kann diese globale Vorgabe erfahren, indem über den für den konkreten Fall geltenden Dispositionsschlüssel (Parameter 14 der FRD482) Abweichendes hinterlegt wird. Hier gilt analog zum Default-Wert die Devise, dass das Spezielle das Allgemeine dominiert: Ist über die FRD482 eine konkrete Vorgabe getroffen, gilt diese; andernfalls gilt, was Parameter 02 der VRLD14 bestimmt.


Die Unterdeckungsprüfung (Netchange)

Die Angebots- und Nachfragesituation jedes dynamisch gesteuerten Artikels wird bei jeder Bewegung, die über die zentrale Verbuchungsschnittstelle verbucht wird, aktuell in der Dispo-Datei nachgezogen. Dabei werden auch Kennzeichen gesetzt, die insbesondere auch Unterdeckungen kenntlich machen. In diesem Sinne erfolgt eine Überprüfung der Angebots- und Nachfragesituation immer sofort. 

Die Erstellung von Beschaffungsvorschlägen hingegen muss außerhalb der Fälle, bei denen eingehende Nachfragen direkt in ein entsprechendes vorläufiges Angebot umgesetzt werden (Einzelplanungen, Streckengeschäfte), mit dem Programm Unterdeckungsprüfung für dynamisch gesteuerte Artikel (Netchange) (DI53030) angestoßen werden. Dieses macht sich die aktuell gesetzten Unterdeckungskennzeichen zunutze und behandelt nur Fälle, bei denen Unterdeckungssituationen vorhanden sind. Dieses Vorgehen verhindert unnötige Aktivitäten des Programms und beeinflusst damit positiv das Laufzeitverhalten.
Der Anstoß zu der Unterdeckungsprüfung kann auf drei Weisen erfolgen:


Initiierungen des Unterdeckungslaufs

Fallbezogener Netchange, manuell aus der Nettoübersicht heraus

In der Nettoübersicht kann über die Funktion "Netchange durchführen" (Umschalt-F7) dafür gesorgt werden, dass der Netchange für den konkreten Fall des Artikels und gegebenenfalls der Lagergruppe ausgeführt wird. Die Ausführung erfolgt nicht direkt (interaktiv), sondern wird als Auftrag an einen Asynchronjob (xxx_PERM) übertragen, der den Netchange im Hintergrund durchführt. Durch die Funktion "Aktualisieren" (F5) können die Daten wieder aktuell eingelesen werden. 
Die Durchführung des fallbezogenen Netchanges erfolgt ohne jede Beeinträchtigung des laufenden Betriebs; es wird weder irgendein Asynchronjob temporär beendet noch ein Anwender in seiner Arbeit behindert.
Wenn für den in der Nettoübersicht stehenden Fall gerade der Netchange läuft, gibt es eine entsprechende Hinweismeldung.

Aufruf Netchange für viele Artikel anstoßen, manuell

Eine Erweiterung des gerade beschriebenen fallbezogenen Netchanges ergibt sich durch das Programm Dispo-Neuaufbau/Netchange anstoßen (DI53060). Mit Hilfe eines Aufrufes kann der fallbezogene Netchange gleich für eine ganze Reihe von Artikeln initiiert werden. Zusätzlich zu der üblichen Standard-Artikelauswahl stehen weitere Selektionskriterien bereit. Da von dem zugehörigen Durchführungsprogamm nur sukzessive entsprechende Aufträge an den Asynchronjob (xxx_PERM( abgesetzt werden, gilt das oben Gesagte auch für diesen Vorgang. Insbesondere werden die Anwender nicht in ihrer Arbeit behindert. 
Die Durchführung des Programms wird von einem Protokoll begleitet, das neben den Leitdaten auch die Anzahl der erzeugten Aufträge und eventuell aufgetretene Fehler enthält.

Fallbezogener Netchange, automatisch bei Bedarf (permanente Planung)

Durch Buchungsvorgänge kann (und wird) sich die Angebots- und Nachfragesituation schnell verändern. Eine eben noch ausgeglichene Verfügbarkeitssituation, die eventuell mit Hilfe von Beschaffungsvorschlägen aus dem letzten Netchange-Lauf heraus geschaffen worden ist, kann plötzlich wieder in Schieflage geraten sein: sei es, dass ein Beschaffungsvorschlag überflüssig geworden ist, weil eine Nachfrage weggebrochen ist; sei es, dass zusätzliche Nachfragen neue oder im Umfang größere Beschaffungsmaßnahmen erforderlich machen.
Über den Dispositionsschlüssel (Parameter 10 der FRD482) kann dafür gesorgt werden, dass für Artikel mit eben dieser Dispositionsart von dem Dispo-Buchungsprogramm automatisch eine Netchange-Anforderung abgesetzt wird, wenn es relevante Änderungen in dem Angebots- und Nachfragegefüge gegeben hat. Die Netchange-Anforderung versteht sich hierbei wiederum als Auftrag an den schon im vorigen Abschnitt erwähnten Asynchronjob, der den Netchange im Hintergrund durchführt. 
Da der Netchange relativ rechenintensiv ist, könnte es bei einem hohen Buchungsaufkommen zu Beeinträchtigungen des Laufzeitverhaltens kommen. In diesem Fall sollte diese Funktion auf die "wichtigen" Artikel beschränkt werden, also solche, bei denen ein unmittelbarer Abgleich von Angebot und Nachfrage unerlässlich ist. Dazu sind gegebenenfalls die Dispositionsschlüssel zu duplizieren und entsprechend bei den Artikeln einzustellen.

Block-Netchange nach dem Dispositionsstufenverfahren, manuell

Unabhängig von der Anwendung der fallbezogenen Netchange-Läufe kann der Netchange en-bloc für das gesamte dynamisch gesteuerte Artikelspektrum zur Ausführung gebracht werden. Üblicherweise ist diese Art der Durchführung den Abschlussarbeiten vorbehalten. 
Der Block-Netchange kann mit einem Aufruf für alle Firmen einer Firmengruppe durchgeführt werden. Dieses ist insbesondere dann relevant, wenn mit firmenübergreifenden Geschäftsprozessen gearbeitet wird, da hierbei Nachfragen, die im Zuge des Programmlaufes firmenübergreifend entstehen können, auch schon gleich in die Rechnung einbezogen werden.
Der Block-Netchange arbeitet nach dem Dispositionsstufenverfahren. Dieses sorgt durch die Einhaltung einer gewissen Reihenfolge, in der die Artikel (bzw. Artikel/Lagergruppe) abgearbeitet werden, dafür, dass jeder Artikel bzw. jedes Paar Artikel/Lagergruppe nur ein einziges Mal behandelt werden muss. 
Diese Problematik ist nur im Zusammenhang mit der Produktion gegeben, wenn aus dem Netchange-Lauf heraus Fertigungsvorschläge gemacht werden, die in Planaufträge umgesetzt werden und dadurch neue vorläufige Nachfragen in Form von vorläufigen Reservierungen aus Planfertigungsaufträgen in die Disposition bringen. Wäre der Netchange schon für so eine Komponente durchgeführt worden, müsste dieser Artikel noch einmal behandelt werden, da sich dessen Nachfragesituation zwischenzeitlich verändert hat.
Dieses Reihenfolgeproblem wird mit Hilfe der Dispositionsstufe gelöst. Die Dispositionsstufe ist die tiefste Fertigungsstufe, auf der ein Artikel bei Betrachtung aller Stücklisten vorkommt; sie kann durch ein Programm des Moduls Produktion ermittelt werden. Die Komponenten, aus denen sich nach der entsprechenden Stückliste ein Artikel (eine Baugruppe) zusammensetzt, haben eine höhere Dispositionsstufe als die Baugruppe.
Beispiel:


Unter der Prämisse, dass es nicht noch andere Stücklisten gibt, in denen diese Artikel vorkommen, ergeben sich folgende Dispositionsstufen:

  • Endprodukt      0
  • Baugruppe-1    1
  • Baugruppe-2    2
  • Kaufartikel-1         3
  • Kaufartikel-2         3

Das Dispositionsstufenverfahren sieht nun vor, dass zunächst die Artikel mit der niedrigsten Dispositionsstufe behandelt werden, dann die Artikel mit der nächst höheren Dispositionsstufe usw.

Die Fälle innerhalb einer Dispositionsstufe werden in der Reihenfolge Artikel und innerhalb eines Artikels nach Lagergruppe in alphabetischer Reihenfolge abgearbeitet. 

Durch vorläufige Transferaufträge (Beschaffungsart "interner Werksbezug"), entstehen auch vorläufige Nachfragen für den behandelten Artikel auf einer anderen Lagergruppe, auf der der Artikel eventuell schon geprüft worden ist. Diese Fälle werden von dem Block-Netchange separat abgehandelt.

Durch firmenübergreifende Geschäftsprozesse können während des Netchanges im Zuge von neu erstellten Fertigungsaufträgen und den hieraus resultierenden Planaufträgen auch vorläufige Nachfragen in anderen Firmen erzeugt werden. Damit diese auch schon gleich in der Unterdeckungsrechnung Berücksichtigung finden können, muss der Netchange für die auf diese Weise miteinander verbundenen Firmen quasi parallel erfolgen, genauer gesagt: muss eine Dispositionsstufe in allen diesen Firmen erst abgearbeitet sein, bevor es mit der nächsten Dispositionsstufe weitergehen darf. Zu realisieren ist das dadurch, dass die miteinander verbundenen Firmen in einer Firmengruppe (FRD146) zusammengefasst sind und der Netchange gleich für diese Firmengruppe aufgerufen wird. Damit dieses Vorgehen vollständig zum Ziel führt, ist es natürlich notwendig, dass die Dispositionsstufen über die miteinander verbundenen Firmen konsistent hinterlegt sind. Dieses ist aber dadurch gewährleistet, dass die Dispositionsstufenermittlung von sich aus schon firmenübergreifend in der Weise vorgeht, dass es alle Firmen, die eine gemeinsame Artikelstammfirma haben, einheitlich behandelt. 

Der Block-Netchange muss nicht für das gesamte Artikelspektrum aufgerufen werden, sondern kann auch auf die Artikel beschränkt werden, die einem vorgegebenen Dispositionsstufenbereich "von-bis" angehören. Auf diese Art könnte der Netchange für das gesamte Artikelspektrum auf verschiedene Zeitfenster verteilt werden.


Bedarfsmengenermittlung

Wenn ein Artikel (ggf. auf einer Lagergruppe) im Netchange-Lauf behandelt wird, hat er im Allgemeinen zu irgendeinem Zeitpunkt mindestens eine oder aber auch mehrere Unterdeckungen. Aus diesen Unterdeckungen über die Zeitachse hinweg ergeben sich Bedarfssituationen, die durch entsprechende Beschaffungsvorschläge kompensiert werden. Genauer ermittelt der Netchange-Lauf diese Bedarfssituationen in Abhängigkeit des internen Losgrößenschlüssels, also Parameter 02 der Tabelle FRD485, in der nachfolgend beschriebenen Weise.

Bedarfsmengenermittlung im periodisierten MEZ

Für die Bedarfsmengenermittlung im periodisierten maximalen Eindeckungszeitraum (MEZ) muss der interne Losgrößenschlüssel (Parameter 02 der Tabelle FRD485) mit "2" oder "3" belegt sein. Hierbei werden alle Unterdeckungen innerhalb des maximalen Eindeckungszeitraums berücksichtigt.

Ausgehend von dem Tag der Unterdeckungsprüfung wird die Zeitachse in Perioden aufgeteilt, deren Länge sich aus dem zugehörigen Losgrößenschlüssel ergibt. Dann werden die Perioden nacheinander in der Weise betrachtet, dass zum Ende einer jeden Periode das kumulierte Angebot mit der kumulierten Nachfrage verglichen wird. Stellt sich hierbei eine Unterdeckung heraus, wird die Unterdeckung in eben dieser Höhe als Bedarf festgestellt. Diese Bedarfsmenge wird dann unter Berücksichtigung weiterer Steuerparameter des Losgrößenschlüssels und von Höchst-, Mindest- und Sprungmengenangaben in einen oder mehrere Beschaffungsvorschläge umgesetzt. Das daraus resultierende vorläufige Angebot wird sofort in die laufende Rechnung der nächsten Perioden einbezogen. 

Das sukzessive Prüfen der Perioden bricht dann ab, wenn die nächste zu prüfende Periode außerhalb des maximalen Eindeckungszeitraumes liegt; ab hier werden Vorschläge auch dann nicht mehr erstellt, wenn Unterdeckungen vorliegen.

Die Länge der Perioden wird über den Losgrößenschlüssel gesteuert, der im Artikelstamm (bzw. im Lagergruppenstamm) hinterlegt ist. Hierbei gilt, dass in einem konkreten Fall die ersten Perioden (fast) alle die gleiche Länge, ab einem gewissen Zeitpunkt alle nachfolgenden Perioden wiederum alle eine gleiche Länge haben. Genauer:

  • Die allererste Periode kann eine eigene Länge haben, nämlich mit der des Solleindeckungszeitraums übereinstimmen. Dem liegt die Idee zugrunde, dass sich bei einem langen Solleindeckungszeitraum und einer kleinen Periodenlänge gemäß Losgrößenschlüssel unter Umständen viele Vorschläge ergeben könnten, die sich auf Grund des langen Solleindeckungszeitraums (= Brutto-Wiederbeschaffungszeit plus Sicherheitszeit) ohnehin erst zu einem späteren Zeitpunkt realisieren ließen. Einzustellen ist diese Steuerung bzgl. der ersten Periode über den Parameter 04 der Tabelle FRD485. Unabhängig davon, ob Parameter 04 für die erste Periode eine eigene Länge vorsieht, ist es so, dass die erste Periode zusätzlich zu den vorgegebenen Tagen noch aus dem aktuellen Tag und allen schon in der Vergangenheit liegenden Tagen besteht.
  • Die nachfolgenden Perioden haben prinzipiell alle eine Länge, die durch Parameter 03 bzw. Parameter 05 – 07 der FRD485bestimmt ist. Diese Aussage gilt, bis durch Parameter 12 ein Zeitpunkt definiert ist, ab dem die Periodenlänge dann so viele Arbeitstage umfasst, wie in Parameter 11 hinterlegt ist. Diese zweite Periodenlänge gilt dann für alle restlichen Perioden. Eine zweite Periodenlänge muss es nicht geben. Dazu ist dann nur Parameter 11 oder Parameter 12 mit dem speziellen Wert Null anzugeben. Hintergrund hierfür ist die Idee einer differenzierteren Planung, nach der der gegenwartsnahe Zeitraum feiner, der fernere Zeitraum gröber gerastert sein kann. Größere Perioden bedeuten auch, dass die Anzahl der Beschaffungsvorschläge geringer wird, was insbesondere bei Fertigungsvorschlägen für Artikel mit einer breiten und tiefen Fertigungsstruktur zu einer Entlastung des System führen kann.

Auf Grund von größeren Wiederbeschaffungszeiten oder kurzfristigen Nachfragen kann es passieren, dass erkannte Unterdeckungen nicht termingerecht ausgeglichen werden können, sondern nur zu einem möglichst frühen Termin. Die Bedarfsmengenermittlung trägt diesem Umstand Rechnung und prüft, ob solche nicht früher zu terminierenden Beschaffungsmaßnahmen schon vorhanden sind, um nicht immer weitere Vorschläge für dieselbe Unterdeckung zu erstellen. Solche "verschobenen Angebote" sind in der Ausnahmedatei unter dem internen Ausnahmegrund "2" protokolliert. Verschobene Angebote lassen sich in dem Programm Nettoübersicht anzeigen (DI33020) bei der Anzeige der Verursacher auf der Detailmaske erkennen: Bei einer Angebotssituation wird zusätzlich zu dem eigentlichen Dispo-Datum ("Wann soll die Ware zur Verfügung stehen?") der Termin angezeigt, für den das Angebot eigentlich bestimmt war (Dispo-Datum intern). 

Bei Bestellvorschlägen und Bestellungen wird dieses Datumsfeld auch als "Bedarfsdatum" und bei Fertigungsaufträgen als "Bedarfsdatum Dispo" zur Verwaltung angeboten. Insbesondere bei manuellen Terminverschiebungen ist es wichtig, ob dieses Bedarfsdatum Dispo ebenfalls mitverschoben werden soll oder nicht. Wird das Angebot in die fernere Zukunft verschoben, aber das Bedarfsdatum nicht ebenfalls, unterbleibt (unter sonst gleichen Bedingungen) eine neue Vorschlagserstellung, weil das Angebot weiterhin Dispo-intern auf dem alten (frühen) Termin liegt. Wandert hingegen das Bedarfsdatum ebenfalls mit in die fernere Zukunft, gerät der Artikel tatsächlich in die Unterdeckung, was zu einem Beschaffungsvorschlag führen würde. Rein äußerlich würden sich beide Situationen in der Nettoübersicht nicht unterscheiden. Beide Male würde es eine längere Periode der Unterdeckung geben; aber nur im zweiten Fall würde die Unterdeckungsprüfung versuchen, diese Unterdeckung durch einen entsprechenden Beschaffungsvorschlag auszugleichen. Welcher Fall vorliegt, lässt sich der Detailmaske der Nettoübersicht entnehmen: Zusätzlich zu dem eigentlichen Dispo-Datum wird auch das interne Dispo-Datum angezeigt.

Ein zweiter Fall liegt dann vor, wenn es zum Ende einer Periode keine Unterdeckung gibt, aber innerhalb der Periode temporär doch eine Unterdeckung bestanden hat. Dies kann dann eintreten, wenn innerhalb einer Periode zunächst eine (größere) Nachfrage und später dann ein entsprechend großes Angebot vorliegt. Solche Fälle werden in der Ausnahmedatei unter dem internen Ausnahmegrund "1" protokolliert.

Bedarfsmengenermittlung nach verbrauchsabhängiger Losgröße

Für die Bedarfsmengenermittlung auf der Basis der verbrauchsabhängigen Losgröße muss der interne Losgrößenschlüssel (Parameter 02 der Tabelle FRD485) mit "5"belegt sein. Hierbei wird in dem Falle einer Unterdeckung, die wie im vorigen Abschnitt ("Bedarfsmengenermittlung im periodisierten MEZ") ermittelt wird, der Bedarf in der Weise bestimmt, dass er auf der Basis der durchschnittlichen Wochenverbrauchs für einen gewissen Zeitraum ausreicht.

Dieser Losgrößenschlüssel unterstützt die Vorgabe, dass ein Vorschlag nur dann erstellt werden soll, wenn dieses nötig ist. Aber wenn er denn schon erstellt werden muss, soll er wenigstens gleich in "ausreichender" Höhe ausfallen, gemessen an dem durchschnittlichen Wochenverbrauch und einem vorgegebenen Zeithorizont. In gewisser Weise ist diese Losgrößenformel eine Flexibilisierung der Mindestmenge, die eben nur absolut, nicht aber in Abhängigkeit des Verbrauches zu haben ist.

Die Bedarfsmenge ermittelt sich nach der folgenden Formel:



Der Zeithorizont versteht sich hierbei in Tagen und wird in Abhängigkeit der ABC-Klassifizierung aus den Parametern des Losgrößenschlüssels ermittelt: A-Artikel: Parameter 05, B-Artikel: Parameter 06, C- bzw. andere Artikel: Parameter 07. Sind Parameter 05 bzw. 06 nicht gepflegt, wird der Wert aus Parameter 07 als Defaultwert herangezogen. 

Unabhängig von dem nach der Formel ermittelten Wert fällt der so ermittelte Bedarf stets mindestens in Höhe der Unterdeckung aus.
Die im vorigen Abschnitt aufgeführten Ausnahmegründe werden auch hier entsprechend protokolliert und stehen damit für die genannten Auswertungszwecke zur Verfügung.

Bedarfsmengenermittlung nach wirtschaftlicher Losgröße

Für die Bedarfsmengenermittlung auf der Basis von Wirtschaftlichkeitsbetrachtungen muss der interne Losgrößenschlüssel (Parameter 02 der Tabelle FRD485) mit "4" belegt sein. Hierbei werden so viele sich nacheinander einstellende Bedarfssituationen zusammengefasst, dass sich in Abhängigkeit von Beschaffungs- und Lagerkosten ein Minimum ergibt.

Die hierfür benötigten Vorgaben zu dem Preisfeld, das für die Bewertung herangezogen werden soll, zu dem Prozentsatz für die Kapitalbindungskosten, und die einmaligen, losgrößenunabhängigen Beschaffungskosten (Bestellkosten bzw. Rüstkosten) werden den Parametern 10, 08 und 09 des jeweiligen Losgrößenschlüssels entnommen.

Die Verfahrensweise ist die folgende: Nacheinander wird zu jedem Tag, für den es einen Eintrag in der Dispo-Datei gibt, das kumulierte Angebot mit der kumulierten Nachfrage verglichen. Stellt sich hierbei eine Unterdeckung heraus, wird die Unterdeckung zunächst einmal gedanklich durch ein vorläufiges Angebot ausgeglichen, bis sich die nächste Unterdeckung auftut. Nun gibt es zwei Möglichkeiten: Jede Unterdeckung wird für sich mit einem Beschaffungsvorschlag versehen oder es wird für beide Unterdeckungen zusammen ein Beschaffungsvorschlag zu dem Zeitpunkt der ersten Unterdeckung erstellt. Im ersten Fall gibt es durch die Beschaffungsmaßnahmen keine Kapitalbindung im Lager, aber dafür fallen zweimal die Beschaffungskosten an. Im zweiten Fall wird Kapital gebunden, dafür fallen aber nur einmal Beschaffungskosten an. Offenbar lohnt es sich dann, verschiedene Unterdeckungen zusammenzufassen, solange die Kapitalkosten unter den Beschaffungskosten liegen. 

Für die Bestimmung der Kapitalkosten wird die Überdeckungsmenge mit Hilfe des vorgegebenen Preisfeldes bewertet. Aus diesem Lagerwert ergeben sich dann die Kapitalkosten durch Anwendung des Prozentsatzes unter Berücksichtigung der Dauer, für die die Ware im Lager liegt. 
Beispiel:
Beschaffungskosten: 190 € pro 1 Stück
Zinssatz: 10 % (pro Jahr)
Vorgegebener Durchschnittspreis: 100 € pro 1 Stück 

Nettoübersicht: 
Dispositionsbestand: 100 Stück (= akt. verfügbar), keine Angebote, Nachfragen: alle 30 Tage 100 Stück

Daraus ergibt sich:

  1. Unterdeckung heute in 30 Tagen: 100 Stück
  2. Unterdeckung heute in 60 Tagen: 100 Stück
  3. Unterdeckung heute in 90 Tagen: 100 Stück usw.

Vergleich:

    • Zwei Beschaffungsvorschläge à 100 Stück verursachen Kosten in Höhe von 380 €.
    • Ein Beschaffungsvorschlag über 200 Stück verursacht Kosten in Höhe von einmal 190 € und den Kapitalkosten von 82,19 € (= 100 * 100 * 0,1 * 30/365), in Summe also 272,19 €.

Ergebnis:
Zusammenfassung beider Unterdeckungsmengen ist günstiger. Aber gegebenenfalls ist auch noch die nächste Unterdeckungsmenge hinzuzufügen:

Vergleich:

    • Der o.a. Beschaffungsvorschlag über 200 Stück und ein weiterer für die 3. Unterdeckung über 100 Stück verursachen Kosten in Höhe von 462,19 € (= 190 + 272,19).
    • Ein gemeinsamer Beschaffungsvorschlag über 300 Stück kostet 436,58 € (= 190 + (200 * 100 * 0,1 * 30/365) + (100 * 100 * 0,1 * 30/365)).

Ergebnis:
Zusammenfassung beider Unterdeckungsmengen ist günstiger. Aber gegebenenfalls ist auch noch die nächste Unterdeckungsmenge hinzuzufügen:

Vergleich:

    • Der o.a. Beschaffungsvorschlag über 300 Stück und ein weiterer für die 4. Unterdeckung über 100 Stück verursachen Kosten in Höhe von 626,58 € (= 190 + 436,58).
    • Ein gemeinsamer Beschaffungsvorschlag über 400 Stück kostet 683,15 € (= 190 + (300 * 100 * 0,1 * 30/365) + (200 * 100 * 0,1 * 30/365) + (100 * 100 * 0,1 * 30/365)).

Ergebnis:
Es lohnt sich nicht, die letzte Unterdeckungsmenge noch in den Beschaffungsvorschlag aufzunehmen, da die zusätzlich damit verbundenen Kapitalkosten die Bestellkosten übersteigen. Von dem Zeitpunkt der vierten Unterdeckung aus geht es dann in gleicher Weise weiter. 

Die so ermittelte Bedarfsmenge wird dann unter Berücksichtigung weiterer Steuerparameter des Losgrößenschlüssels und von Höchst-, Mindest- und Sprungmengenangaben in einen oder mehrere Beschaffungsvorschläge umgesetzt. Das daraus resultierende vorläufige Angebot wird sofort in die laufende Rechnung der nachfolgenden Termine einbezogen. 

Beispiel (fortgesetzt):
Höchstmenge: 280 Stück
Mindestmenge:50 Stück
Sprungmenge: 10 Stück

Ergebnis:
Aus der Bedarfsmenge in Höhe von 300 Stück resultiert ein Beschaffungsvorschlag in Höhe von 280 Stück und ein weiterer über 50 Stück (eigentlich gäbe es nur noch einen Restbedarf von 20 Stück, der aber wegen der Mindestmengenvorgabe auf 50 Stück angehoben wurde; die Sprungmenge spielt hier keine Rolle).  

Das sukzessive Prüfen auf Unterdeckungen bricht dann ab, wenn der nächste zu prüfende Unterdeckungstermin außerhalb des maximalen Eindeckungszeitraumes liegt; ab hier werden Vorschläge auch dann nicht mehr erstellt, wenn Unterdeckungen vorliegen.


Unterbleibende Bedarfsmengenermittlung

Über den internen Losgrößenschlüssel "Z" ist es möglich, die Bedarfsmengenermittlung und damit die Vorschlagserstellung im Rahmen der Unterdeckungsprüfung für dynamisch gesteuerte Artikel zu unterdrücken. Dies kann zum einen dann sinnvoll sein, wenn ein Artikel im Prinzip manuell beschafft werden soll, die Angebots- und Nachfragesituation aber trotzdem in der Dispo-Datei aktuell gehalten werden soll, um sich auf einen Blick aktuell informieren zu können. 
Eine andere Möglichkeit zur Verwendung ergibt sich bei diskret einzelgeplanten oder hart plangesteuerten Artikeln, wenn sichergestellt werden soll, dass mit Vorschlägen ausschließlich aus direkten Nachfragen bzw. aus Planbedarfssituationen reagiert werden soll (vgl. die Abschnitte zu den entsprechenden Dispositionsarten).


Terminierung von Vorschlägen

Die Umsetzung von Bedarfsmengen in Vorschlagsmengen erfolgt bei allen Dispositionsarten in gleicher Weise und wird daher später in einem allgemeinen Abschnitt behandelt. Die Terminierung hingegen hängt von der Dispositionsart, aber auch von dem Losgrößenschlüssel ab. 
Unter Terminierung wird die Festlegung der folgenden Daten verstanden:

Bestellvorschlag

Fertigungsvorschlag

Transfervorschlag

Dispositionsdatum

Endtermin AV

Dispositionsdatum

Lieferdatum/Lieferwoche


Lieferdatum

Bestellvorschlagsdatum




Ausgangspunkt für die Terminierung eines Vorschlags ist in jedem Fall das Bedarfsdatum; also der Termin, zu dem eine Unterdeckung beziehungsweise eine einzelgeplante Nachfrage durch einen Beschaffungsvorschlag auszugleichen ist. Das Bedarfsdatum ergibt sich zunächst einmal aus dem Datum, zu dem in der Not leidenden Periode die Unterdeckung das erste Mal auftritt, beziehungsweise aus dem vorgegebenen Termin der einzelgeplanten Nachfrage.

Eine besondere Einstellungsmöglichkeit ergibt sich über Parameter 09 der Tabelle VRLD15, wenn dieses Bedarfsdatum in den Solleindeckungszeitraum fällt. Denn dieses bedeutet, dass die zu ergreifende Beschaffungsmaßnahme ohnehin nicht rechtzeitig zum Wareneingang führen wird, so dass nun erst einmal noch nachgeschaut werden kann, ob zum Ende des Solleindeckungszeitraums überhaupt noch eine Unterdeckung vorliegt. Nur dann, wenn auch zum Ende der Solleindeckungszeit noch eine Unterdeckung vorliegt, bleibt das ursprüngliche Bedarfsdatum bestehen; ist dies hingegen nicht der Fall, wird es auf das Datum der ersten Unterdeckung nach Ende der Solleindeckungszeitraum hoch gesetzt, das notwendigerweise innerhalb der betrachteten Periode liegen muss.

Sollte der Termin in der Vergangenheit liegen, wird er auf das Datum des Netchange-Laufes hoch gesetzt. 

Bei Fertigungsvorschlägen sind mit Angabe des Endtermins AV die Terminangaben im Rahmen der Disposition erschöpft. Die eigentliche Terminierung wird im Modul Produktion durchgeführt. Dies erfolgt im Netchange-Lauf dann, wenn (bei Block-Netchange nach dem Dispositionsstufenverfahren: nach Abarbeitung aller Artikel einer Dispositionsstufe) zunächst das Programm zur Übernahme der Fertigungsvorschläge in Planfertigungsaufträge und dann das Programm zu deren Einplanung durchgeführt wird, das letztlich die Komponenten- und Kapazitätenreservierungen erzeugt und die eigentliche Terminierung durchführt. Hierbei wird zunächst, von dem aus der Disposition vorgegebenen Endtermin AV ausgehend, auf der Grundlage von Arbeitsplan bzw. im Artikelstamm hinterlegten Rüst-, Stück- und Übergangszeiten eine Rückwärtsterminierung versucht, um zu einem errechneten Startdatum zu kommen. Fällt das errechnete Startdatum in die Vergangenheit, wird von dem aktuellen Tagesdatum ab vorwärts terminiert; auf diese Weise ergibt sich ein errechneter Endtermin AV, das nach dem Endtermin AV liegt und der Planauftrag wird damit zu einem "verschobenen" Angebot. Der errechnete Endtermin AV fungiert als Dispositionsdatum, unter dem das Angebot in der Nettoübersicht zu sehen ist. Der ursprüngliche Bedarfstermin (im Modul Produktion "Bedarfsdatum Dispo-") erscheint bei der Detailanzeige der Verursacher als internes Dispositionsdatum "Dispo-Datum (int)". Zeiten für nachgelagerte Tätigkeiten (Einlagerung, Qualitätskontrolle u.a.), die benötigt werden, bevor die Fertigungsmenge zum Ausgleich der Unterdeckung zur Verfügung steht, müssen folglich in den Arbeitsplan (zum Beispiel entsprechend lange Liegezeit als letzter Arbeitsgang) eingefügt werden; der hierfür vorgesehene Solleindeckungszuschlag hat hier keine Bedeutung.

Bei Bestellvorschlägen wird das Bestellvorschlagsdatum direkt im Zuge einer Rückwärtsterminierung ermittelt: ausgehend von dem vorgegebenen Bedarfstermin (Dispositionsdatum) wird zunächst der Solleindeckungszuschlag zurückgerechnet, um auf den Liefertermin zu kommen. Sind im Lieferantenartikelstamm und im Lieferantenstamm keine Korrekturtage für den Dispotermin hinterlegt, ist dieser Liefertermin auch derjenige, der dem Lieferanten gegenüber zu nennen ist. Andernfalls werden diese Korrekturtage ebenfalls noch abgezogen, so dass der Lieferant einen noch früheren Termin als Liefertermin genannt bekommt (weil er "normalerweise immer" um diese Anzahl von Tagen zu spät liefert). Von dem Lieferdatum ausgehend wird dann noch die Netto-Wiederbeschaffungszeit (ebenfalls über die Kalenderdatei, d.h. unter Berücksichtigung von arbeitsfreien Tagen) zurückgerechnet, um auf das Bestellvorschlagsdatum zu kommen. Fällt dieses in die Vergangenheit, wird entsprechend vorwärts gerechnet. In diesem Fall wird das aktuelle Tagesdatum zum Bestellvorschlagsdatum, das aktuelle Tagesdatum plus Netto-Wiederbeschaffungszeit zum Lieferdatum und das aktuelle Tagesdatum plus Korrekturtage aus dem Lieferanten(artikel)stamm plus Brutto-Wiederbeschaffungszeit zum Dispositionsdatum entsprechend hochgerechnet. Das Dispositionsdatum ist der Termin, zu dem das Angebot in der Nettoübersicht sichtbar ist. Ferner wird dieser Fall in der Ausnahmedatei unter dem Ausnahmegrund "2" protokolliert. Wenn nur mit einer Lieferwoche, aber nicht mit konkreten Lieferterminen gearbeitet wird, kann über Parameter 20 der VRLD15 bewirkt werden, dass nur die Lieferwoche, aber nicht auch der Liefertermin in den Bestellvorschlag eingestellt wird.

In der Terminierung der Bestellvorschläge können auch Betriebsferien der Lieferanten eingebracht werden. Dazu müssen diese natürlich erst einmal in das System eingepflegt werden, was mit dem Programm Lieferantenbetriebsferien verwalten (EK10401) erledigt werden kann. Die Berücksichtigung von Lieferantenbetriebsferien wirkt sich dann so aus, dass sich die Zeiträume zwischen Dispositionsdatum, Lieferdatum und Bestellvorschlagsdatum um die Tage der Betriebsferien verlängern. 

Die Transfervorschläge sind aus Sicht der Disposition besondere Beschaffungsmaßnahmen, stellen sie doch auf der einen Seite (Lagergruppe) ein vorläufiges Angebot und auf der anderen Seite eine vorläufige Nachfrage dar. Das Bedarfsdatum auf der Not leidenden Lagergruppe wird zum Lieferdatum des Transfervorschlags. Durch Rückwärtsterminierung mit der Brutto-Wiederbeschaffungszeit, die sich nach der Defaultwert aus den Stammdaten für die Not leidende Lagergruppe ergibt, wird das Verladedatum bestimmt, das das Dispositionsdatum auf der anderen Lagergruppe bildet, von der aus umgelagert werden soll. Diese Brutto-Wiederbeschaffungszeit muss so angesetzt werden, dass sie zum einen die benötigten Zeiten für die Umlagerung, zum anderen auch die benötigten Zeiten für die nachgelagerten Tätigkeiten (s.o.) umfasst. Gerät das so ermittelte Datum in die Vergangenheit, wird entsprechend vorwärtsterminiert. Sollen Nachfrage und Angebot genau auf dasselbe Datum fallen (Brutto-Wiederbeschaffungszeit gleich Null Tage, weil die beiden Lagergruppen relativ nah beieinander liegen und eine Umlagerung "schnell gemacht" ist), kann dieses durch Angabe eines Bestellpolitikschlüssels mit Soll-Eindeckungszuschlag von Null Tagen und eines Wiederbeschaffungskennzeichens auf Lagergruppenebene erfolgen, bei dem ebenfalls Null Tage als Wiederbeschaffungszeit hinterlegt sind.


Behandlung von alten Vorschlägen

Bei Vorschlägen, die in einem früheren Netchange-Lauf erstellt worden sind, erfolgte dies auf der Basis des zu dem entsprechenden Zeitpunkt aktuellen Datenbestandes. Wenn diese nicht in echte Beschaffungsmaßnahmen überführt wurden, befinden sie sich in der Disposition immer noch als vorläufige Angebote. Da die Datenlage sich inzwischen geändert haben wird, kann es sinnvoll sein, die alten Vorschläge vor der eigentlichen Unterdeckungsprüfung zu löschen. 
Über die Parameter 06 und 07 der Vorlauftabelle VRLD15 kann getrennt für Bestell- und Fertigungsvorschläge gesteuert werden, in welcher Weise alte, löschbare Vorschläge gelöscht werden sollen. Dabei kann aus fünf Löschstufen gewählt werden:

  1. ‚"0" Es wird kein Vorschlag gelöscht.
  2. "1" Jeder Vorschlag wird gelöscht, zu dem in der Dispo-Datei zum gleichen Tag keine Nachfrage vorliegt.
  3. "2" Nur wenn zu dem spätesten Termin, für den in der Dispo-Datei noch ein Angebot oder eine Nachfrage existiert, das kumulierte Angebot größer ist als die kumulierte Nachfrage, werden Vorschläge gelöscht; dann aber alle.
  4. "3" Wenn zu dem spätesten Termin, für den in der Dispo-Datei noch ein Angebot oder eine Nachfrage existiert, das kumulierte Angebot größer ist als die kumulierte Nachfrage, werden alle Vorschläge gelöscht. Wenn dies nicht der Fall ist, werden nur diejenigen Vorschläge gelöscht, zu denen in der Dispo-Datei zum gleichen Tag keine Nachfrage vorliegt.
  5. "4" Es werden alle Vorschläge gelöscht.


Damit ein Vorschlag tatsächlich gelöscht wird, muss er weitere Bedingungen erfüllen, nämlich:

  • das Anwendungsgebiet "Disposition" oder "Lager" haben, d.h. durch die Unterdeckungsprüfung für dynamisch gesteuerte oder verbrauchsgesteuerte Artikel erstellt worden sein und
  • nicht fixiert sein
  • auf einen Lagerort lauten, dessen zugehörige Lagergruppe nicht aus der Disposition herausgenommen ist (Programm Lagergruppen verwalten (US16500), Parameter "Disponieren Ja/Nein").

Dadurch, dass nicht nur Vorschläge des Anwendungsgebietes "Disposition" sondern auch die mit "Lager" gelöscht werden, bleiben beim Wechsel des Dispositionsverfahrens von "verbrauchsgesteuert" auf "dynamisch gesteuert" keine alten Vorschläge stehen.

Um bestimmte Vorschläge auf jeden Fall vor dem Löschen zu bewahren, ohne deswegen global die Löschstufe "0" vergeben zu müssen, reicht es, diese über die Bestell- bzw. Fertigungsvorschlagsverwaltung zu fixieren. Dies ist besonders dann zu empfehlen, wenn der Vorschlag schon überarbeitet worden ist. Das Löschen von Bestellvorschlägen erfolgt unabhängig von dem Freigabekennzeichen; freigegebene Fertigungsvorschläge hingegen bleiben erhalten, sie werden nicht gelöscht.

Für das Laufzeitverhalten interessant ist, dass Bestell- beziehungsweise Fertigungsvorschläge erst gar nicht gelöscht werden, wenn sie denn gleich wieder im Prinzip identisch erstellt werden würden. Im Prinzip identische Erstellung liegt vor, wenn folgende Daten gleich sind: Anwendungsgebiet, Lagerort, internes Dispo-Datum, externes Dispo-Datum, Menge und im BeVo-Falle: Lieferant.

Transfervorschläge werden im Netchange generell gelöscht, sofern der Buchungsschlüssel, mit dem sie ursprünglich gebucht wurden und der im Transfervorschlagskopf hinterlegt ist, noch mit dem in Parameter 02 der VRLD28 hinterlegten Buchungsschlüssel übereinstimmt.
Das Löschen alter Vorschläge erfolgt vor dem eigentlichen Netchange-Lauf. Dieser basiert dann natürlich auf dem entsprechend angepassten Datenbestand, d.h. die durch das Löschen von Vorschlägen verschwundenen vorläufigen Angebote, aber auch die verschwundenen vorläufigen Nachfragen, die aus zurückgenommenen Planfertigungsaufträgen resultieren, werden berücksichtigt; die Unterdeckungskennzeichen in der Dispo-Datei sind der veränderten Situation wieder angepasst.


Ablaufplan des Netchange-Laufs

Der Block-Netchange-Lauf in seinem ganzen Umfang setzt sich aus den folgenden Komponenten zusammen:

  1. Buchungssperre für die aktuelle Firma beziehungsweise für alle Firmen der Firmengruppe setzen. Dazu gehört auch wegen Intercompany-Prozesse gegebenenfalls das Setzen der Buchungssperre für weitere Firmen: und zwar geht es dabei um solche Firmen, die in den angelegten Lagerorten der obigen Firmen als bezogene Firma hinterlegt sind. Dieses Lagerort-spezifische Setzen einer Buchungssperre für eine Firma kann dadurch umgangen werden, dass die Firma in der Vorlauftabelle VRLU57 hinterlegt wird. Dieses sollte allerdings nur im Ausnahmefall (z.B. für Testfirmen) angewendet werden.
    Zusätzlich dazu werden unter Umständen auch bestimmte Asynchronjobs beendet (im Abschluss über die Abschlussart via Parameter 04 der FRDPRD, bei Aufruf aus dem Menü via Parameter 22 der VRLD15 gesteuert).
  2. In der Reihenfolge aufsteigender Dispositionsstufen für jede Dispositionsstufe (bei Firmengruppenangabe: innerhalb einer Dispositionsstufe für alle Firmen):
    1. Verbuchen derjenigen Angebote und Nachfragen in der Disposition, die aus den Aktivitäten des Netchange-Laufes der vorherigen Dispositionsstufe hervorgegangen und noch nicht verbucht sind
    2. Umwandeln Fertigungsvorschläge in Planfertigungsaufträge
    3. Einplanung dieser Planfertigungsaufträge
    4. Verbuchen derjenigen Angebote und Nachfragen in der Disposition, die hieraus entstanden sind
    5. Löschen alter Vorschläge gemäß VRLD15
    6. Verbuchen derjenigen Angebote und Nachfragen in der Disposition, die hieraus entstanden sind
    7. Unterdeckungsprüfung für alle Artikel dieser Dispositionsstufe mit Vorschlagserstellung für die Not leidenden Artikel
    8. Umwandeln Fertigungsvorschläge in Planfertigungsaufträge
    9. Einplanung dieser Planfertigungsaufträge
    10. Verbuchen derjenigen Angebote und Nachfragen in der Disposition, die hieraus entstanden sind
    11. Wenn im Zuge der Unterdeckungsprüfung Transfervorschläge erstellt wurden und damit neue Nachfragen auf derselben Dispositionsstufe in einer anderen Lagergruppe entstanden sind, wird für die betroffenen Paare (Artikel, Lagergruppe) sinngemäß bei 2e. weiter gemacht.

  3. Gegebenenfalls werden die gerade erstellten Transfervorschläge in Transferaufträge übernommen (vgl. Parameter 01 der VRLD35).
  4. Buchungssperre(n) wieder aufheben, gegebenenfalls werden die Asynchronjobs wieder hochgefahren.

Die Punkte 1 und 4 sorgen dafür, dass die Daten in der Dispo-Datei für die eine Firma beziehungsweise alle Firmen der Firmengruppe in Ruhe bleiben, solange der Netchange am Laufen ist. Das erfolgt in der Weise, dass alle Anwender, die sich noch in einer Belegverwaltung aufhalten sollten, über das System eine Aufforderung erhalten, ihr Tun zu beenden. Erst dann, wenn alle Anwender alle relevanten Programme verlassen haben, beginnt der Netchange-Lauf. Relevant in diesem Sinne sind alle Programme, die Buchungsstoff absetzen, der prinzipiell die Dispo-Daten verändert, also z.B. die Programme zur Bestellverwaltung, Fertigungsauftragsverwaltung oder Verkaufsauftragsverwaltung. In dieser Zeit kann kein Anwender mehr ein derartiges Programm aufrufen; er wird wiederum vom System davon unterrichtet, wenn die Sperre aufgehoben ist.

Das hier kurz beschriebene Sperrkonzept ersetzt das bisherige Ausschließen der Anwender in der betroffenen Firma und das unabdingbare Herunterfahren diverser Asynchronjobs, das auch dafür sorgte, dass die Daten in der Dispo-Datei in Ruhe blieben, aber gleichzeitig auch die Firmen in ihrem Tun behinderte, die an dem Netchange-Lauf gar nicht beteiligt waren. Wenn der Block-Netchange im Rahmen der Abschlussarbeiten läuft, sei der Vollständigkeit halber erwähnt, dass es letztlich eine Frage der Einstellung der Abschlussart (FRDPRD), ob zu Beginn der Abschlussarbeiten die diversen Asynchronjobs beendet und zum Schluss wieder gestartet werden sollen.
Der Ablauf eines fallbezogenen Netchanges ist ähnlich, nur dass hier keine Buchungssperren gesetzt werden. Stattdessen werden während des Netchange-Laufes abgesetzte Buchungssätze für diesen konkreten Fall temporär zurückgestellt (‚geparkt') und erst mit dessen Beendigung wieder zur Verbuchung freigegeben.

  • Keine Stichwörter