Das Konzept der Abschlussarbeiten

Mit dem Programmkomplex der Abschlussarbeiten stellt oxaion die Möglichkeit zur Verfügung, unterschiedliche Programme zu einem Paket zusammenzufassen und gebündelt zur Ausführung zu bringen. In der Regel handelt es sich dabei um Programme, die

  • in regelmäßigen Abständen laufen sollten
  • hohe Systemanforderungen stellen
  • oxaion Objekte exklusiv beanspruchen.

Im Allgemeinen wird die Ausführung des Abschlusses daher in einen Zeitraum gelegt werden, in dem der Rechner weniger belastet ist, also z.B. in die Nachtzeit oder in das Wochenende.
Üblicherweise unterscheidet man zwischen einem Tages-, einem Wochen- und einem Monatsabschluss. Es steht dem Anwender jedoch frei, beliebige Abschlüsse zu definieren und zu einem beliebigen Zeitpunkt zur Ausführung zu bringen. So kann z.B. an jedem Wochentag ein anderer Abschluss laufen.
Um einen Abschluss zur Ausführung zu bringen, sind folgende Tätigkeiten erforderlich:

Die zur Programmausführung notwendigen Leitdaten werden in einer Datei gespeichert und zum Zeitpunkt der Ausführung dem Programm zur Verfügung gestellt.

Periodische Arbeiten in der Disposition

In der Disposition gibt es Aufgaben, die in verschiedenen Abständen immer wieder durchzuführen sind.
Bei den täglichen Aufgaben handelt es sich um die

  • Unterdeckungsprüfung für dynamisch gesteuerte Artikel (Block-Netchange)
  • Unterdeckungsprüfung für verbrauchsgesteuerte Artikel (Bestellpunktprüfung).

Diese Aufgaben sollten in den Tagesabschluss integriert werden, damit die Disposition möglichst aktuell ist. Die Unterdeckungsprüfung für dynamisch gesteuerte Artikel ist nicht nötig, wenn alle dynamisch gesteuerten Artikel dem fallbezogenen Netchange unterliegen.
Bei den wöchentlichen Aufgaben handelt es sich um

  • das Verdichten rückständiger Dispo-Daten in der Dispo-Datei
  • den Neuaufbau der Dispo-Datei (als Block-Neuaufbau).

Beim Verdichten rückständiger Dispo-Daten wird der Tatsache Rechnung getragen, dass mit dem Verstreichen von Tagen die tagesgenau in der Dispo-Datei bereit gehaltenen Daten in die Vergangenheit geraten. Durch den Verdichtungslauf werden alle in der Vergangenheit liegenden Informationen unter dem speziellen Datum 00.00.00 zusammengefasst.
Das Datum, ab dem Angebote und Nachfragen in der Dispo-Datei wieder unter einem richtigen Tagesdatum abgelegt werden, wird von dem Verdichtungsprogramm im Firmenstamm (Maske "Disposition") abgelegt ("Erstes Datum in der Dispo-Datei", hier auch "Aufsetzdatum" genannt). Es wird auch in der Nettoübersicht angezeigt. Das erste Datum kann auf verschiedene Weisen bestimmt werden:

  • Nächster Arbeitstag (Dieses ist für den Fall gedacht, dass der Verdichtungslauf nach einem Arbeitstag durchgeführt wird. Läuft das Verdichtungsprogramm also an einem Freitagabend, liefert der darauf folgende Montag das Datum.)
  • Vorgegebenes Datum
  • Relative Vorgabe via Sonderwerte (z.B. "Heute" minus x Arbeitstage).

Steht ein geplanter Zu- oder Abgang zur Verbuchung in der Disposition mit einem Datum an, das vor dem Aufsetzdatum liegt, wird er unter dem Datum 00.00.00 verbucht.
Der Neuaufbau der Dispo-Datei bietet die Möglichkeit, diese Daten unmittelbar aus den Quellen auf der Basis der aktuellen Dispositionsparameter neu aufzubauen. Der Weg ist dabei der, dass die ganze Dispo-Datei für den ausgewählten Artikelbereich zunächst geleert wird und dann alle offenen Vorgänge aus den angeschlossenen Modulen Einkauf, Produktion, Vertrieb, Lager, Service, Projekte und Disposition wieder eingebucht werden.
Ein Neuaufbau der Dispo-Datei für einen Artikel ist immer dann nötig, wenn gewisse dispositive Steuerparameter geändert werden, z.B.:

  • Parameter 02, VRLD14 (Abzug Sicherheits- bzw. Meldebestand)
  • Änderungen des durch diesen Parameter festgelegten Bestandes durch automatische Aktualisierung (s.u.)
  • Dispositionsart

Ein Neuaufbau der Dispo-Datei für einen Artikel ist anzuraten, aber nicht unbedingt nötig bei Änderungen bzgl.

  • Wiederbeschaffungszeit
  • Bestellpolitikschlüssel
  • Standardlieferant

Durch die Größen Wiederbeschaffungszeit und Bestellpolitikschlüssel werden die verschiedenen Zeiträume wie Solleindeckungs- bzw. maximaler Eindeckungszeitraum beeinflusst und damit die Vergabe gewisser Unterdeckungskennzeichen, die bei der Nettoübersicht bzgl. der dispositiven Selektionsmöglichkeiten abgefragt werden.
Bezüglich des Standardlieferanten stellt sich die Frage, ob mit seiner Änderung die Bestellvorschläge, die gegebenenfalls von der Disposition noch auf den alten Standardlieferanten erstellt worden sind, im Rahmen des Erlaubten gelöscht und auf den neuen, aktuellen Standardlieferanten neu erstellt werden sollen.
Wurden Änderungen an den Dispositionsparameter vorgenommen, ist es deshalb nicht gleich nötig, einen Neuaufbau der gesamten Dispo-Datei zu fahren. In Tabelle FRD815 sind standardmäßig alle Dispositionsparameter aufgeführt, die einen Neuaufbau erforderlich machen. Ist nun bei einem Artikel ein Dispositionsparameter geändert worden und ist dieser in der Tabelle FRD815 mit der Aktion "NA" (Parameter 02) hinterlegt, so ist auch gleich der fallbezogene Dispo-Neuaufbau initiiert worden, so dass hieraus kein weiterer Handlungsbedarf besteht.
Tabelle FRD815 hilft allerdings nicht in dem Fall, dass Änderungen nicht direkt am Dispositionsparameter selbst, sondern an den bei ihm hinterlegten Steuerungsparametern vorgenommen worden sind (zum Beispiel steht das Wiederbeschaffungszeitkennzeichen "05" nicht mehr für fünf Arbeitstage, sondern nun für 25 Arbeitstage (5 Wochen)). In solchen Fällen hilft nur ein kompletter Neuaufbau der Dispositionsdatei.
Ein kompletter Neuaufbau im Wochenrhythmus ist in jedem Fall anzuraten, um stets eine aktuelle Dispo-Datei zu haben.
Bei einem Neuaufbau werden alte Vorschläge gelöscht:

  • prinzipiell alle Bestellvorschläge mit den Module "Disposition" und "Produktion"
  • prinzipiell alle Fertigungsvorschläge mit dem Modul "Disposition".
    Ein Bestell- beziehungsweise ein Fertigungsvorschlag wird aber nicht gelöscht, wenn er
    • aus einem Kanban-Vorgang heraus erstellt wurde (Behälternummer ist angegeben)
      oder
    • freigegeben ist (Freigabekennzeichen beziehungsweise Kennzeichen "Freigabe FeVo" in Ausprägung "1" oder "2") und freigegebene BeVos beziehungsweise FeVos laut VRLD15 erhalten bleiben sollen
      oder
    • Neuaufbau-fixiert ist (Kennzeichen "fixiert" in Ausprägung "2").
  • Transfervorschläge bleiben erhalten.


Bei den monatlichen Aufgaben handelt es sich um:

  • die systemgestützte Aktualisierung von durchschnittlichem Wochenverbrauch, Sicherheits-, Meldebestand beziehungsweise Wiederbeschaffungszeit.

Die automatische Aktualisierung macht dann einen Neuaufbau der Dispo-Datei notwendig, wenn der Parameter 02 der VRLD14 vorsieht, die Angebots- und Nachfragesituation gegen den Sicherheits- beziehungsweise Meldebestand zu prüfen und eben dieser durch den Aktualisierungslauf bei dynamisch gesteuerten Artikeln verändert wurde.
 

Besonderheiten bei der Ausführung von Dispositionsprogrammen im Abschluss
(Kritische Phase)

Im Rahmen des Abschlusslaufes wird in der Datei UMATBP firmenspezifisch eine Teildatei "DISPOxxx" (mit xxx = Firma) erzeugt. Programme, die zwischen der Erstellung (Anhängen) und dem Löschen (Abhängen) dieser Teildatei Sätze in UMATBP ausgeben oder verarbeiten, greifen auf diese Teildatei zu. Für die Programme Neuaufbau der Dispositionsdatei (DI53010) und Unterdeckungsprüfung dynamisch gesteuerter Artikel (DI53030) ist das zwingend erforderlich. Andere Programme, z.B. die Fertigungsauftragseinplanung (PW51002C) können sich diesen Ablauf ebenfalls zunutze machen. Nach der erfolgreichen Ausführung ist die Teildatei wieder zu entfernen.

Im Rahmen des Abschlusslaufes ausschließlich die Datei "DISPOxxx" (mit xxx = Firma) verwendet.


Durch diese Vorgehensweise wird zum einen die Größe der Datei UMATBP reduziert. Zum anderen ist dadurch die Verbuchung eines Vorgangs nur einmal (nämlich auf Grund der erstmaligen Verarbeitung) in der Datei enthalten

Grundsätzlich sind zurückgestellte Sätze ein Problem, um das sich dringend gekümmert werden sollte, weil sie für nicht durchgeführte Buchungen stehen und damit für eine Diskrepanz zwischen dem Modul Disposition und dem Modul sorgen, aus dem die Buchungsanforderung stammt. Die Zurückstellung von Buchungssätzen wird stets in der Mailbox mit einer Fehlernachricht zwischen U000600 und U000699 protokolliert. Die möglichen Gründe für die Zurückstellung sind vielfältig, und so ist die Lösung des ihnen zugrunde liegenden Problems. Einfach ist zum Beispiel das temporäre Problem, dass für das Belegdatum keine offene Periode gefunden werden kann: Über Programm Perioden verwalten (US10800) kann die Periode für das Modul "Lager" geöffnet werden und die wieder freigegebenen Buchungsanforderungen werden verbucht werden. Andere Gründe für zurückgestellte Sätze sind (mittlerweile) ungültige Werte für Feldinhalte, weil irgendwelche Tabellen oder Stammdateien "bereinigt" wurden. Hier ist von Fall zu Fall zu prüfen, was zu tun ist.
Für den reibungslosen Ablauf ist es erforderlich, das Anhängen und Abhängen der Teildatei DISPOxxx sowie die Verarbeitungsprogramme in der richtigen Reihenfolge im Abschluss auszuführen:


PhaseBeschreibung
  1. DI53007 Beginn der kritischen Phase

Die kritische Phase meint eine Zeitspanne, in der Programme laufen, die eine in Ruhe befindliche Datenbasis verlangen. Mit diesem Programm wird eine Sperre gesetzt, die den Aufruf von Programmen für die im Abschluss befindliche und abhängige Firmen verhindert, die die relevante Datenbasis verändern könnten. Gleichzeitig wird an die mit solchen Programmen noch arbeitenden Anwender eine Durchbruchnachricht geschickt, in der sie aufgefordert werden, das Programm zu verlassen. Die weitere Verarbeitung des Abschlusses wird solange unterbrochen, bis die durch einen Anwender verursachte Sperre aufgehoben ist. Ferner bewirkt diese Sperre, dass Buchungsanforderungen (UMATBP-Sätze) für die gesperrten Firmen von dem Asynchronjob zunächst einmal überlesen, also nicht verarbeitet werden.

Mit den abhängigen Firmen sind solche Firmen gemeint, die im Abschluss der einen Firma ebenfalls behandelt werden. Solche Konstellationen können im Neuaufbau der Dispo-Datei und im Netchange dadurch auftreten, dass in deren Leitdaten der Aufruf gleich für eine ganze Firmengruppe angefordert wurde. Da mit Angabe einer Firmengruppe während der kritischen Phase gleich alle betroffenen Firmen gewissen Beeinträchtigungen unterworfen sind, sollte eine Firmengruppe nur dann vorgegeben sein, wenn es sachlich auch begründet ist. Dieses ist dann gegeben, wenn die eine Firma mit einer oder mehreren anderen Firmen durch Intercompany-Prozesse miteinander verbunden ist. Insbesondere für den Netchange ist dieses wichtig, damit Nachfragen, die in der einen Firma für eine andere entstehen, dort auch noch Berücksichtigung finden.

Das Sperrkonzept ersetzt die frühere restriktive Vorgehensweise, während des Abschlusses die Anmeldung in der im Abschluss befindlichen Firma zu verweigern und die Asynchronjobs herunterzufahren, so dass in anderen Firmen zwar die Anwendung als solche zur Verfügung stand, aber nichts asynchron verbucht beziehungsweise verarbeitet werden konnte. Das Herunterfahren der Asynchronjobs allein reicht nicht aus, um die benötigte Datenruhe zu gewährleisten; der Aufbau der kritischen Phase ist in jedem Fall unverzichtbar, um in ihr die entsprechenden Programme laufen zu lassen.

Es werden Beleg verarbeitende Programme für den Anwender gesperrt.

Das sind z.B. die Verwaltung von Fertigungsaufträgen, Bestellungen, Verkaufsaufträge, Lagerbuchungen etc.

Rückmeldeaktivitäten von Fertigungsaufträgen werden während der kritischen Phase nicht sofort verarbeitet, sondern in der Datei PWBDEP zwischengespeichert und erst nach dem Ende der kritischen Phase verarbeitet. Das bedeutet auch, dass gewisse Plausibilitätsprüfungen nicht online im Dialog durchgeführt werden können. Dies sind z. B. die Einhaltung der Reihenfolge von Rückmeldungen (AE Auftragsende vor AS Auftragsstart). 

2. DI53020R Rückständige Dispo-Daten verdichten

Wenn das Programm überhaupt im Abschluss eingebunden sein soll, dann wäre hier die richtige Stelle, weil die Verdichtung rückständiger Dispo-Daten unter dem Datum 00.00.00 bei gleichzeitiger Bebuchung der Dispo-Datei zu temporär inkonsistenten Daten in der Nettoübersicht führen könnte; da unter Umständen Planbedarfe ausgebucht werden, die im Artikelkonto protokolliert werden sollen. Wenn die Asynchronjobs aktiv sind, die Verbuchungen vornehmen, werden sie zum Schluss des Programms kurz "durchgestartet", das heißt sie werden heruntergefahren und gleich wieder hochgefahren, damit das gerade veränderte "erste Datum in der Dispo-Datei" aktuell bei der Bebuchung der Dispo-Datei Anwendung findet.

3. Anwendungsprogramme

Hier sind die gewünschten Anwendungsprogramme einzufügen (z.B. Neuaufbau der Dispositionsdatei (DI53010) oder Unterdeckungsprüfung für dynamisch gesteuerte Artikel (DI53030))

4. DI53023R Ende der kritischen PhaseDie Abschlusssperre wird wieder aufgehoben und die Anwender, die vorher die Durchbruchnachricht erhalten hatten, ihr Programm zu verlassen, beziehungsweise die Anwender, denen die Belegverarbeitung auf Grund einer Funktionssperre verweigert worden war, erhalten nun wieder eine Nachricht, in der ihnen mitgeteilt wird, dass sie weitermachen können.


Anmerkungen zu einigen abschlussrelevanten Programmen:

  • Bestellpunktprüfung für verbrauchsgesteuerte Artikel (DI53040)
    Standardmäßig wird die verbrauchsgesteuerte Disposition für "einfache" Artikel verwendet. Wenn sie selbst nicht fremdbezogen beschafft werden, sind ihre Produktionstiefen eher flach und bestehen wiederum aus verbrauchsgesteuerten Artikeln. In dieser Verwendungsweise ist das Programm gut im Anschluss an die kritische Phase angesiedelt. Hängen jedoch an den Stücklisten auch dynamisch gesteuerte Artikel, würden deren vorläufigen Nachfragen aus den Komponentenreservierungen erst nach dem Netchange-Lauf in die Dispo-Datei geraten. Jetzt hängt es davon ab, ob der Dispositionsschlüssel dieser Artikel den fallbezogenen Netchange vorsieht: Wenn ja, wird nach Einbuchung der Nachfrage im Unterdeckungsfalle der fallbezogene Netchange angestoßen und die Unterdeckungssituation durch Beschaffungsvorschläge ausgeglichen. Wenn nein, bleibt eine Unterdeckungssituation bis zum nächsten Netchange-Lauf unbeachtet.
    Daher wird standardmäßig empfohlen, die Bestellpunktprüfung vor dem Beginn der kritischen Phase laufen zu lassen.
  • Dispositionsgrundlagen mit/ohne Aktualisierung drucken (DI11050)
    Wenn das Programm überhaupt mit Aktualisierung im Abschluss integriert sein soll, ist es sowohl vor die Unterdeckungsprüfung für verbrauchsgesteuerte Artikel (Bestellpunktprüfung) als auch vor den Neuaufbau der Dispo-Datei und damit vor die Unterdeckungsprüfung für dynamisch gesteuerte Artikel (Block-Netchange) zu stellen, damit geänderte Sicherheits- und Meldebestände auch gleich ihren aktuellen Niederschlag in der Disposition finden. 

Eine Einbindung von Programmen in die kritische Phase sollte nur dann erfolgen, wenn diese notwendig ist, da die kritische Phase wegen der mit ihr einhergehenden Einschränkungen möglichst kurz gehalten werden sollte.


Maßnahmen bei nicht ordnungsgemäßem Ablauf des Abschlusses

In der Regel wird ein Abschlusslauf unbeaufsichtigt ausgeführt. Die Ergebnisse können erst am nächsten Arbeitstag kontrolliert werden. Grundsätzlich können zwei Arten von Störungen auftreten, verursacht entweder durch eine fehlerhafte Datenkonstellation oder durch fehlerhafte Verarbeitung:

  • Durch die Datenkonstellation verursachte Fehler
    In diesem Fall werden entsprechende Meldungen an die Mailbox ausgegeben. Der Fehler ist anhand der Mailbox-Informationen zu korrigieren. Beim nächsten Netchange bzw. beim nächsten Neuaufbau wird dann die Dispo-Datei aktualisiert.
  • Durch fehlerhafte Verarbeitung verursachte Störungen
    In diese Kategorie gehören Programmabbrüche, nicht ausgeführte Programme auf Grund von Sperren o.ä., Systemausfälle usw. In der Regel werden Programmabbrüche durch den Abschlussjob kontrolliert. Es wird dann ebenfalls eine Meldung in die Mailbox ausgegeben und je nach Einstellung (Parameter "Wichtig ja/nein" im Abschluss-Verwaltungsprogramm (US51071)) die Verarbeitung mit dem nächsten Programm fortgesetzt oder der Abschlussjob beendet.
    Als erste Maßnahme sollte die Ursache des Abbruchs anhand von Mailboxeinträgen, Jobprotokollen und Speicherauszügen geprüft und entsprechende Maßnahmen eingeleitet werden. Der Datenzustand ist stark davon abhängig, an welcher Stelle im Abschlusslauf der Abbruch erfolgt ist. Unter anderem können folgende Zustände eingetreten sein:
  • die Dispo-Datei ist unstimmig, d.h. es sind keine stimmigen Daten bezüglich der Verfügbarkeit von dynamisch gesteuerten Artikeln vorhanden
  • die Einplanung von Bestellvorschlägen, Fertigungsvorschlägen und Fertigungsaufträgen ist unstimmig, Ressourcen fehlen oder wurden nicht gelöscht, die Termine sind unstimmig
  • eine Reihe von Bestellvorschlägen oder Fertigungsaufträgen sind noch nicht verbucht bzw. noch nicht eingeplant. Beim Starten der Asynchronverarbeitung kann das dazu führen, dass die i5 stark durch die Asynchronjobs beansprucht wird, die den aufgestauten Buchungsstoff verarbeiten. Diese Belastung kann verringert werden, indem die Priorität der betreffenden Asynchronjobs geändert wird.

Werden bestimmte Daten dringend benötigt, können die entsprechenden Programme vom Menü aus aufgerufen und ggf. über das Aufrufprogramm die zu verarbeitenden Daten eingeschränkt werden. Insbesondere ist hier auch das Programm "Dispo-Neuaufbau/ Netchange anstoßen" (DI53060) zu nennen, mit dem mit einem Mal gleich viele Artikel in den fallbezogenen Neuaufbau beziehungsweise fallbezogenen Netchange geschickt werden können, ohne dass der Tagesbetrieb behindert wird. 

Ein weiteres Problem tritt auf, wenn der Abschluss zwar reibungslos abläuft, die Verarbeitung jedoch zu lange dauert. Während der Abschluss aktiv ist, kann in der betreffenden Firma nur eingeschränkt gearbeitet werden. Ist der Abschluss zu Beginn der Arbeitszeit noch aktiv, kann mit dem Programm Abschlussfortschritt anzeigen (US51032) überprüft werden, wie weit der Abschluss fortgeschritten ist. Auf Grund dieser Information ist zu entscheiden, ob der Abschluss zu beenden ist (das kann mit demselben Programm geschehen). In diesem Fall können etwaige noch benötigte, aber nicht mehr zur Ausführung gekommene Programme aus dem Menü heraus aufgerufen werden.

  • Keine Stichwörter