[gelöst] Performance Buchung Umlagerungsauftrag

Hallo liebe Community,
Wir haben z.T. recht große Umlagerungsaufträge zwischen unseren Lagern.
Diese umfassen u.U. auch 700 Zeilen. Eine Buchung dauert da bis zu 20 - 30 Minuten.

Ich vermute den reinen Buchungsprozess kann man nicht "optimieren". Welche Optimierungsmöglichkeiten wären noch möglich, um zu vermeiden, dass der zuständige Mitarbeiter 20 Minuten auf sein NAV Start und die Meldung "Anwendung reagiert nicht" bekommt?

Grüße,
Thomas

Zuletzt geändert von ThomasM am 24. September 2015 16:18, insgesamt 1-mal geändert.

Hallo,

da müsste man sich mal genauer anschauen, was da so in der DB abgeht.

Wird bei euch automatische Lagerregulierung verwendet?
Habt Ihr mit Seriennummern oder Chargen zu tun?
Bringt es etwas (weiß gerade nicht ob das wirklich geht), wenn ihr in den Zeilen schon den Artikelposten auswählt, gegen den sich die Umlagerung ausgleicht?

Gruß Fiddi

Ist in der Lagerreinrichtung über das Feld "Automatische Lagerregulierung" diese eingeschaltet worden? Ausgeschaltet wäre diese bei "Nie" in diesem Feld.

Danke für das Feedback.
Wir verwenden nicht die automatische Regulierung:

LagerEinrichtung.JPG

bei uns läuft Nachts ein Job in der Aufgabenwarteschlange, welcher diese Regulierungen bucht.
Chargen-/Seriennummern fallen bei uns nicht an.

Wie kann ich das auf DB Ebene untersuchen? Reicht der Aktivitäsmonitor in einem ersten Versuch aus um sich die "aktuell Wertvollen Abfragen" anzeigen zu lassen?

Aber mal ganz grundsätzlich gefragt: Ist der Zeit, bis ein Umlagerungsauftrag mit ~ 500 Zeilen gebucht wird im "normalen" Rahmen oder doch zu lang?

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Wir verwenden nicht die automatische Regulierung:
bei uns läuft Nachts ein Job in der Aufgabenwarteschlange, welcher diese Regulierungen bucht.

Die automatische Lagerbuchung ist aber eingeschaltet (und das auch noch mit zusätzlichen Soll-Kosten-Buchungen). Das kostet zwar nicht so viel Zeit wie automatische Regulierung, aber die könnte man auch nachts über Report 1002 durchführen, falls nicht tagsüber die Zahlen sofort in der Fibu benötigt werden. Die sind ohnehin so am selben Tag nur begrenzt aussagekräftig, eben weil vorher nicht reguliert wurde. Das produziert tagsüber schon Sachposten mit den unregulierten Werten, und die Nachtregulierung mit den Korrekturen dann nochmals. Wenn man nachts also Report 795 und erst danach 1002 ausführt, hat man in der Fibu morgens immer die aufgelaufenen Bewegungen zum Vortag sauber abgebildet, und tagsüber etwas kürzere Buchungszeiten (und etwas weniger dabei produzierte Sachposten).

Besten Dank für den Hinweis Kowa!
Was genau macht der Bericht 1002, was der Bericht 795 nicht macht? Ich kann hier im Bericht 795 doch auch hinterlegen, dass er die Regulierungen bereits in die Sachposten buchen soll. Ist das dann nicht redundant?

Die automatische Lagerbuchung ist aber eingeschaltet (und das auch noch mit zusätzlichen Soll-Kosten-Buchungen). Das kostet zwar nicht so viel Zeit wie automatische Regulierung, aber die könnte man auch nachts über Report 1002 durchführen, falls nicht tagsüber die Zahlen sofort in der Fibu benötigt werden. Die sind ohnehin so am selben Tag nur begrenzt aussagekräftig, eben weil vorher nicht reguliert wurde. Das produziert tagsüber schon Sachposten mit den unregulierten Werten, und die Nachtregulierung mit den Korrekturen dann nochmals. Wenn man nachts also Report 795 und erst danach 1002 ausführt, hat man in der Fibu morgens immer die aufgelaufenen Bewegungen zum Vortag sauber abgebildet, und tagsüber etwas kürzere Buchungszeiten (und etwas weniger dabei produzierte Sachposten).

Das bedeutet, es wäre grundsätzlich ratsam, da wir sowieso eine Nachtregulierung haben, tagsüber keine Sachposten zu erzeugen und die automatische Lagerbuchung zu deaktivieren und statt dessen Nachts zuerst den Bericht 795 und im Anschluss den Bericht 1002 laufen zu lassen?

Ist das dann nicht redundant?

Nein, um das etwas komfortabler zu machen, ist in Report 795 nachträglich das Feld mit dem Haken "Auf Sachkonten buchen" dazu gekommen, das aber wiederum aus der Einstellung der Lagereinrichtung vorsorgt wird. Das Feld ist auch nur dann verwendbar, wenn es dort eingeschaltet ist, damit man die Fibubuchung vor dem Ausführen optional abschalten kann.

Code:

OnOpenPage()
InvtSetup.GET;
PostToGL := InvtSetup."Automatic Cost Posting";
PostEnable := PostToGL;

Wenn die automatische Lagerbuchung abgeschaltet ist, wird der Report 795 nur noch die Wertposten regulieren.

Beim optionalen Abschalten kommt diese Meldung (inklusive einer Übersetzungspanne ) . Mit "die allgemeinen" sind "die Sachposten" gemeint (bzw. "die Fibuposten" in CH).

LedgerEntryReport1002.png

Der Report 1002 sollte auch grundsätzlich zumindest einmal im Monat immer zusätzlich zu Sicherheit laufen, damit wirklich alles eventuell noch auf Sachkonten ungebuchte erwischt wird.
Das gilt immer, egal was man sonst eingestellt hat. Die Haken in der Einrichtung stellen ja immer nur den aktuellen Zustand dar, der zwischendurch durchaus auch mal anders gewesen sein kann.
Für den Report gab es auch einige Bugfixes in den Cumulative Updates der letzten Zeit.

Das bedeutet, es wäre grundsätzlich ratsam, da wir sowieso eine Nachtregulierung haben, tagsüber keine Sachposten zu erzeugen und die automatische Lagerbuchung zu deaktivieren und statt dessen Nachts zuerst den Bericht 795 und im Anschluss den Bericht 1002 laufen zu lassen?

So ist es .

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Besten Dank.

Dann nehme ich das mal so mit und schließe den Thread.