Umlagerungsauftrag - gleiche Lagerorte (von/nach) verwend.?

Hallo zusammen,

ich würde gerne eine Leihverwaltung über Umlagerungsaufträge und der Verwendung eines Transit-Lager abbilden.
vereinfacht:
* Artikel wird verliehen: Buchung eines Umlagerungsausgangs auf TRANSIT
* Artikel kommt zurück: Buchung des Umlagerungseingangs zur Entlastung des TRANSIT Lagers und Abschluss des Umlagerungsauftrags

Dazu müsste man natürlich einige Anpassungen vornehmen, und vor allem erlauben, dass "Umlag.-von Code" und "Umlag.-nach Code" mit gleichen Lagerorten belegt werden dürfen. Was mich nun etwas stutzig macht, ist, dass genau dieser Check ("Lagerort muss unterschiedlich sein") an so vielen Stellen im Standard-Code eingebaut ist (T5740, C5704, C5705, C5708), dass man es fast als Warnung deuten muss, hier irgendeine Änderung vorzunehmen. z.B. in C5708 OnRun():

Code:

IF ("Transfer-from Code" <> '') AND
   ("Transfer-from Code" = "Transfer-to Code")
THEN
  ERROR
    (Text001,
    "No.",FIELDCAPTION("Transfer-from Code"),FIELDCAPTION("Transfer-to Code"));

Im Gegensatz zu den Umlagerungsaufträgen gibt es allerdings bei Verwendung des Umlagerungs Buch.-Blattes hier keine Einschränkung: Man kann problemlos Buchungen mit gleichem Inhalt in Feld "Lagerortcode" und "neuer Lagerortcode" vornehmen!

Könnt ihr euch vorstellen, warum dies in den Umlagerungsaufträgen so restriktiv gehandhabt bzw. sorgfältigst geprüft wird?
Seht ihr irgendwelche größeren Probleme/Risiken, wenn man diese Checks auskommentiert?

Bin um jeden Tip dankbar.

Danke und viele Grüße!

Hallo zusammen,

kurzes Update dazu:
Ich habe jetzt mal einige Tests mit Umlagerungsaufträgen und gleichen Lagerorten durchgeführt, die Buchungen laufen m.E. alle korrekt ab! Auch Lagerregulierung, Postenausgleich scheint ordentlich zu funktionieren, ich konnte keinerlei Probleme feststellen.

=> Ich denke, man kann so eine Änderung tatsächlich gefahrlos einbauen.

Was meint ihr? Falls ihr dazu noch Tipps, Hinweise habt oder Gefahren seht, freu mich über Feedback.

Danke und viele Grüße!

Eigentlich ist von Navision der Lagerort Transit nicht als Dauer-Lagerort vorgesehen, sondern nur als Buchungslagerort, um Bewegungen von Artikel nahtlos verfolgen zu können.
Ich würde über die Verwendung eines Extra-Lagerorte nachdenken, auf dem Bestände dann auch länger liegen können. Außerdem ist, meiner Meinung nach, die Verfolgung der Buchung so einfacher.

Hallo Raimond,

danke für deine Antwort.
Die Nachverfolgbarkeit der Buchungen / Leihvorgänge bei Verwendung eines eigenen Lagerorts für verliehene Artikel ist ja gerade das Problem:

Wenn Artikel zurückgegeben werden würde man einen neuen Umlagerungsauftrag erstellen und buchen. NAV gleicht dann immer den ältesten offenen Posten aus, d.h. wenn viele gleiche Artikel an viele verschiedene Kunden verliehen sind und zu verschiedenen Zeiten zurückgegeben werden, hat man schnell ein Problem die noch ausstehenden Leihungen zu finden.

Mit dem TRANSIT-Ansatz hingegen erkennt man alle offenen Leihungen (und den dazugehörigen Kunden) einfach daran, dass der Umlagerungsauftrag noch offen/vorhanden ist. Sind alle Umlagerungen verbucht, wurde alles zurückgegeben.

Viele Grüße!

Dazu müsste man natürlich einige Anpassungen vornehmen, und vor allem erlauben, dass "Umlag.-von Code" und "Umlag.-nach Code" mit gleichen Lagerorten belegt werden dürfen.
Seht ihr irgendwelche größeren Probleme/Risiken, wenn man diese Checks auskommentiert?

1. Leihgeräte sind nach HGB eigentlich keine Artikel (Umlaufvermögen) sondern Anlagen (Anlagevermögen).
Begründung: UV verbleibt nicht länger als 1 Jahr in der Bilanz und kann daher nicht planmässig abgeschrieben werden. AV dagegen schon.

2. Daher müsste man IMHO soetwas für Fixed Asset und einem eigenen Zusatzmodul abbilden.

3. Ich verstehe nicht wo dein Problem mit Umlagerungsaufträge (Logistikfunktionalität) liegt?
IIRC erfordern UA schon immer 3 Lagerorte, um korrekt zu funktionieren, daher sind die Routen immer vorher einzurichten.

4. Was spricht dagegen das mit dem Umlagerungsbuchblatt zu machen?
4.1 Verleihen: Leihgerät geht vom firmeneigenen Lagerort A zum kundeneigenen Konsilager T zum Datum D.
Zurückgeben zum Datum D + LM: vom T zum A.
Warum müssen es die gleichen Lagerorte sein?

Hallo,

es geht in dem konkreten Fall nicht um Geräte im Sinn von Maschinen oder so, sondern um "normale" Gebrauchsartikel die man an ausgewählte Kunden (z.B. Presse) zum Testen eine gewisse Zeit verleihen kann.

4. Was spricht dagegen das mit dem Umlagerungsbuchblatt zu machen?
4.1 Verleihen: Leihgerät geht vom firmeneigenen Lagerort A zum kundeneigenen Konsilager T zum Datum D.
Zurückgeben zum Datum D + LM: vom T zum A.
Warum müssen es die gleichen Lagerorte sein?

Hm..., du meinst, ich soll für jeden Kunden an den ich etwas verleihen möchte einen eigenen Lagerort anlegen und darauf dann die Umlagerungen durchführen?!? Ja, das könnte gehen, aber ich hab dann halt u.U. hundert Lagerorte zu verwalten.

Danke für den Tipp!!!

Oder einfach einen Lagerplatz (Bin) direkt in der Zeile (ohne Pick/Putaway oder so was).

Lagerplätze und Ressourcen sind meine Lieblingsfunktionalitäten, sie sind so flexibel du kannst damit alles abbilden. Ein Lagerplatz kann ZB ein LKW sein (um Liefer-Rundfahrten zu organisieren), ein Mitarbeiter, eine Maschine, ein Schritt der Verarbeitung, ein Konsi-Kunde, alles.

Oder einfach einen Lagerplatz (Bin) direkt in der Zeile (ohne Pick/Putaway oder so was).

Lagerplätze und Ressourcen sind meine Lieblingsfunktionalitäten, sie sind so flexibel du kannst damit alles abbilden.

Hm, IIRC muss man bei Benützung von Lagerplätzen bei der Jahresinventur das Logistikinventurbuchblatt verwenden?
Seine Handhabung ist AFAIK deutlich komplexer als das normale Inventurbuchblatt bzw. die Inventuraufträge. (Kowa weiss da sicherlich mehr).
Daher halte ich es für etwas bedenklich, wenn ein Logistikspezialist alleine diese Entscheidung fällt, ohne mit dem Warenwirtschaftswerteflussspezialist (was für ein Wort) zu sprechen.

Ein wichtiger Hinweis dazu, unabhängig von der rechtlichen Seite: Die Lagerregulierung verfolgt Artikel vom Zugang bis zum Abgang rekursiv. Heißt, bei einer neuen Bewegung wird letztendlich der gleiche Funktionsblock rekursiv immer wieder aufgerufen und die Bewegung verfolgt, bis ein tatsächlicher Abgang vom Lager gebucht wird. Das dient dazu, auf zirkuläre Buchungen zu prüfen (beispielsweise Istmeldung -> Umlagerung -> Umlagerung -> Verbrauch im selben FA).

Liegen nun dutzende und später vllt. hunderte Umlagerungen hin und zurück ohne einen regulären Abgang vom Lager vor, so ist es möglich/wahrscheinlich, dass durch die rekursiven Aufrufe ein Stack-Overflow auftritt. Ist mir schon einmal, bei genau so einer Lösung, untergekommen.