10. Juni 2009 15:33
Diesen allgemeinen Ablauf zu den sehr komplizierten Kalkulationen der Datumsfelder in den Bestellungen habe ich mir vor einiger Zeit mal formuliert:
Das Bestelldatum wird nur bei der Erstanlage vom Kopf in die Zeilen kopiert. Jede nachträgliche Änderung im Kopf hätte eine erneute Preisfindung für die gesamte Bestellung zu Folge, wenn dieser Feldwert validiert werden würde.
Die Felder
Zugesagtes, Gewünschtes, Erwartetes WE-Datum werden ebenfalls in die Zeilen übertragen, wenn in dem Datumsfeld eine Änderung stattfindet. Das zeigen die Zeilen allerdings erst an wenn der Cursor dort steht. Allerdings sind alle diese Felder voneinander abhängig und verändern auch die Werte der anderen Felder.
Gewünschtes und
Zugesagtes WE-Datum werden üblicherweise von Hand eingegeben,
Geplantes WE-Datum (nur in der Zeile vorhanden) und
Erwartetes WE-Datum errechnet.
Eine Validierung der Nr. in der Zeile holt sich
Gewünschtes WE-Datum und
Zugesagtes WE-Datum, das Bestelldatum und die eingehende Lagerdurchlaufzeit aus dem Belegkopf.
Außerdem werden die Funktionen "UpdateDates" und "UpdateLeadTimeFields" in der Einkaufszeile ausgeführt.
"UpdateDates" validiert erst, wenn gefüllt, erneut das Feld
Zugesagtes WE-Datum. Dadurch wird das
Geplante WE-Datum gleich dem Wert von
Zugesagtes WE-Datum gesetzt.
Wenn das
Gewünschte WE-Datum gesetzt ist, wird dieses ebenfalls erneut validert. Diese Validierung führt immer zu einer Neuberechnung des Bestelldatums in der Zeile, weil dann anhand der Regel
Geplantes WE-Datum = Bestelldatum + Beschaffungszeit Bestelldatum = Geplantes WE-Datum - Beschaffungszeit gerechnet wird.
Die Beschaffungszeit muss ein in älteren Versionen eine einfache Datumsformel sein, eine Formel wie z.B. 2W+3T führt sonst zu Fehlberechnungen. Dafür gibt es ggf. ein Hotfix, falls eine derartige Datumsformel verwendet werden soll.
Die Beschaffungszeiten sind hinterlegbar
- in der Tabelle Artikel/Lieferanten Katalog,
- auf der Lagerhaltungsdaten-/Artikelkarte
- oder beim Kreditor
(Priorität in dieser Reihenfolge).
Eventuell vorhandene Betriebskalender (mit Feiertagen,Betriebsferien) werden dabei ggf. berücksichtigt, außerdem ggf. Zustellertransportartenzeiten in der Tabelle 5790 "Zusteller Transportart" sowie deren Betriebskalender.
Für das
Erwartete WE-Datum wird dann ausgehend vom
Geplanten WE- Datum (ge
plantes: das ist der Anliefertermin an der Laderampe (Eselsbrücke: die LKW-
Plane wird geöffnet)) weitergerechnet mit den Feldwerten aus "Eingehende Lagerdurchlaufzeit" (hinterlegt im Lagerort (ggf. auch mit Betriebskalender) oder, wenn dort nicht vorhanden, der Lagereinrichtung) plus "Sicherh. Zuschlag Beschaff. Zt." (auf der Lagerhaltungsdaten- oder Artikelkarte, wird meist nur bei Produktionsartikeln verwendet).
Es erfolgt also erst eine Rückwärtsrechnung und dann eine Vorwärtsrechnung, um das
Erwartete WE-Datum zu erhalten, wenn das
Gewünschte WE-Datum geändert wird.
Erwartetes WE-Datum = Geplantes WE-Datum + Eingeh. Lagerdurchlaufzeit + Sicherh. Zuschlag Beschaff. Zt. Um das Bestelldatum für eine bestimmte Bestellung zu errechnen, die zu einem bestimmten Tag eingehen soll, setzt NAV das
geplante gleich dem
gewünschten und nimmt die
Rückwärtskalkulation vor.
Um das
Erwartete WE-Datum für eine Bestellung mit
Gewünschtem WE-Datum zu erhalten, setzt NAV ebenfalls das
geplante gleich dem
gewünschten und nimmt die
Vorwärtskalkulation vor.
Die Prioritäten der Felder für die Kalkulationen
- Zugesagtes WE-Datum, wenn dieses nicht gefüllt dann
- Gewünschtes WE-Datum, wenn dieses nicht gefüllt dann
- Erwartetes WE-Datum, wenn dieses nicht gefüllt dann
- Bestelldatum