[Gelöst] Fehler bei Kommissionierungen seit Version 19

Hallo zusammen,

wir haben seit dem Update auf die neueste Version folgenden (Standard-)Fehler festgestellt:

Die Erstellung einer Kommissionierung ist fehlerhaft, wenn unterschiedliche Einheiten eine Rolle spielen und der Artikel auf unterschiedlichen Lagerplätzen liegt.

Beispiel:
Ein Artikel wurde in Stück eingelagert und liegt auf 2 verschiedenen Lagerplätzen.
Nun wird dieser Artikel in VE verkauft (1 VE = 16 Stück).

Die Kommissionierung, die erstellt wird, sieht nun so aus wie im Anhang.

Zeile 1: Entnehme 49 Stück von einem Lagerplatz (OK)
Zeile 2: Packe 3,0625 VE auf den WA-Platz (OK)
Zeile 3: Entnehme 4,9375 Stück vom anderen Lagerplatz (falsch! Es müssen 79 Stück sein)
Zeile 4: Packe 4,9375 VE auf den WA-Platz (OK)

Diese Kommissionierung kann so nicht registriert werden! Man hat auch manuell keine Möglichkeit die Daten vernünftig zu ändern.
Microsoft war an den Einheiten dran (Rundung der Mengen in Basiseinheit)…daher liegt die Vermutung sehr nahe, dass es sich um einen neuen Standard-Fehler handelt.
Das stellt bei uns grade ein riesen Problem dar und daher würde mich eure Meinung dazu brennend interessieren.

Unser „workaround“ dafür sieht nämlich wie folgt aus: Wir sorgen durch temporäre Umbuchungen dafür, dass die benötigte Menge komplett auf einem Lagerplatz liegt (so dass die Kommissionierung sich nur von einem Lagerplatz bedient). Das ist natürlich auf Dauer nicht machbar ☹

Habt ihr Ideen/Meinungen/Anregungen dazu?

Vielen Dank schon mal!

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

Zuletzt geändert von AGM82 am 18. November 2021 09:26, insgesamt 1-mal geändert.

Hallo,

da läuft irgendetwas völlig falsch, wenn das tatsächlich 3,0625 VE sind, die er auf dem Lagerplatz verwalten soll.

Das System sollte grundsätzlich nur mit ganzen Einheiten arbeiten, d.h. es sollte immer eine ganze VE aus einem Hauptlager(platz) in ein(en) Kommissionierlager(platz) als Stück aufgelöst werden. (oder man lagert nur als Stück ein, aber das ist von der eigenen Organisation und Artikelstruktur abhängig)
Und erst und nur von dort werden Stück kommissioniert. Wird eine VE benötigt, dann kann die aus einem Lagerplatz entnommen werden, der VEs enthält.

Alles andere führt zu Chaos, auch in NAV oder älteren BC Versionen. Wenn das dann trotzdem funktioniert hat, kann das auch Zufall gewesen sein, weil zufällig keine Rundungsfehler auftraten.

Gruß Fiddi

Hallo,

wir lagern immer in der kleinsten zu bewegenden Einheit ein.
BC (und auch NAV) können nämlich (fast) problemlos in größere Einheiten umrechnen.
Somit hatten wir bisher bei unseren Kommissionierungen (wo nur in größere Einheiten umgerechnet werden muss) auch nie Probleme.

Die Umrechnung in kleinere Einheiten findet bei uns in der Einlagerung statt (Funktionalitäten des "Gebindeanbruchs" kommen da zum tragen).
Aber das ist auch gar nicht das Thema. :)

Bei meinem Beispiel werden 49 Stück entnommen und 3,0625 VE auf den WA-Platz gepackt (da stimmt noch alles 49/16=3,0625).
Falsch wird es nur in der dritten Zeile! Dort sollen dann auf einmal 4,9375 Stück anstatt 79 Stück entnommen werden.

VG

Hallo,

dann solltest du bitte auch Stück in den WA packen und nicht VEs. Dann wird das ganz ein wenig übersichtlicher.

Woher kommen die VEs denn dann? Stammen die aus dem Auftrag, weil da jemand VEs bestellt hat?

Nichts desto trotz scheint da natürlich die falsche Einheit drin zu stehen, obwohl hinten die richtige Menge (Basis) drin steht, was mich eigentlich noch mehr wundert.

Welche Einheit ist denn für den Lagerplatzinhalt für den Artikel auf dem Lagerplatz BLK-??? definiert.

Gruß Fiddi

Hallo,

ja, der Kunde bestellt VEs (weil der Preis für eine VE günstiger ist).
Daher müssen auch VEs in den Warenausgang.

Der Lagerplatzinhalt ist in Stück angegeben (weil wir ja in Stück einlagern).
Was dich wundert ist genau das, was mich auch wundert :)

Das Thema klappte bis zum Update auch ganz wunderbar...erst jetzt gibt es diesen Fehler :(

VG

Hallo,

da kommen wir jetzt zu dem Thema, was ich oben angeschnitten habe, der Organisation des Lagers.
Wenn du in VEs und Stück verkaufen willst, dann solltest du auch dein Lager so organisieren.
D.h. dein Lager sollte dann auch VE und Stück enthalten. Dann sollte es damit keinen Ärger mehr geben, weil er nur VEs oder Stück in der Kommissionierung hätte, bzw. Umlagerungen für den Anbruch durchführen würde/könnte.
Auch wenn ich verstehe, dass das Aufwand bedeutet, wenn der Kunde 20 statt 16 oder 32 Stück bestellt.

Denn spätestens wenn deine VEs 3,6,9 oder irgendetwas vielfaches von 3 enthalten kommt es zu Rundungsdifferenzen, die dir beim Lagerbestand auf die Füße fallen.

Gruß Fiddi

Hey,

danke für die Antworten.

Für alle unserer 1000e Artikel doppelte Lagerplätze anzulegen und diese in verschiedenen Einheiten einzulagern ist natürlich keine Option!
Zumal wir bei der Einlagerung noch gar nicht wissen, ob und wie viele der Artikel irgendwann mal in VEs gekauft werden.

Die Funktionalität der Einheitenumrechnung in BC ist ja vorhanden und hatte bisher auch super funktioniert.
Eine Um-Organisierung meines Lagers deshalb durchzuführen ist ... (wie bereits gesagt) keine Option.

Mit der Anmerkung zu den Rundungsdifferenzen gebe ich dir recht.
ABER: Das ist ja eine der neuen Verbesserungen, die das Update mit sich bringen soll. Man kann ja jetzt eine Rundungspräzision an der Basiseinheit einstellen.
Damit sollte das eigentlich kein Problem mehr darstellen.

VG

Hallo,

ABER: Das ist ja eine der neuen Verbesserungen, die das Update mit sich bringen soll. Man kann ja jetzt eine Rundungspräzision an der Basiseinheit einstellen.

Nicht wirklich, denn wenn du die Rundungspräzision von VE auf 18 Stellen einstellst, bleibt bei vielfachen von drei immer noch ein Rest bei der Umrechnung.
Das ganze würde nur funktionieren, wenn du die Rundung bei der Umrechung individuell einstellen könntest, also von Stück nach VE mit 18 Stellen nach dem Komma, aber in die andre Richtung mit 0 Stellen, das ist aber genauso Aufwändig wie die Reorganisation deines Lagers.

Und außerdem möchtest du VEs ja eigentlich auch mit 0 Nachkommastellen verwenden.

Also ich würde das Ganze mal als Bug verstehen, aber ihr versucht in BC anders zu arbeiten als Ihr es im realen Leben (ohne ERP) tun würdet. Da würdet Ihr dem Kunden der VEs bestellt auch VEs liefern. Und so solltet Ihr euch auch organisieren.
Das reale Leben im ERP auszublenden oder durch noch so geniale Tricks zu verbiegen, weil man keine Lust hat einen Aufwand zu treiben, der aus dem realen Leben folgt, führt in der Regel dazu das keiner wirklich mit dem System sauber arbeiten kann.

Gruß Fiddi

Guten Morgen,

danke nochmal für deine Antworten.
Ein Ticket für diesen neuen Fehler wird bei Microsoft eröffnet.
Schauen wir mal wie lange die Behebung dauert.

VG

Nachtrag: Microsoft wird diesen Fehler in der Version 19.1 beheben.

LG

Update 19.1 ist ja aus November (wurde am 19.11.2021 veröffentlicht), du meinst vermutlich 19.2

Ich habe folgende Mail von Microsoft bekommen und habe das anscheinend falsch interpretiert.
On prem wird im Januar (19.3) gefixt.
Cloud-Variante könnte das Hotfix bereits bekommen haben (so verstehe ich das).
Da wir kommende Woche erst auf 19.1 updaten, dachte ich, dass das Hotfix dabei wäre.
Alles nicht so einfach ... ;)

The fix will include in on-prem version BC 19.3 // January update
The Saas (on-line) environments will have the Saas (on-line) fix soon.
The Saas (on-line) fix rollout process already started.
It take a few days in general.
You could check Base Application version via Extension management.
If you see this version 19.0.29894.33329 or higher than the Saas (on-line) fix already installed. // 19.0 branch
19.1.31886.33239 // 19.1 branch
19.2.32968.33243 // 19.2 branch

Das ist der eine unbestreitbare Vorteil von SaaS - Fehlerbereinigungen bekommt man dort schneller. (Allerdings bekommt man auch Fehler schneller eingebaut... )

Das ist der eine unbestreitbare Vorteil von SaaS - Fehlerbereinigungen bekommt man dort schneller.

Nicht immer, SaaS braucht nach einem Updaterelease meist ein paar Tage, bis es auf alle Tenants global verteilt ist. Wenn man also eine OnPrem-Version nach dem Erscheinen schnell installiert, hat man zumindest kurz mal die Nase vorn (und darf das ggf. jeden Monat wiederholen…). Der obige Bug dagegen wurde wohl als so dringend eingestuft, dass der Hotfix für SaaS eine beschleunigte Behandlung erfährt, wohingegen für OnPrem 19.2 schon "Redaktionsschluss" war.

Das "kuriose" ist, dass die Korrektur des Fehlers anscheinend zwischen unseren Minor-Updates stattfand.
Ich habe das Problem an MS nach unserem Update auf die 19.0 gemeldet (Mitte November).
Das Update auf die 19.1 erfolgt bei uns erst kommende Woche.
Trotzdem habe ich die Korrektur jetzt schon in meinen Systemen. Vielleicht bekommen die "Fehler-meldenden" BC-Nutzer ihre Korrekturen mal schnell zwischendurch?!

Vielleicht bekommen die "Fehler-meldenden" BC-Nutzer ihre Korrekturen mal schnell zwischendurch?!

Nicht nur die, bei SaaS werden Hotfixes auch in alte bzw. aktuelle Versionen reingeschoben.
Aktuell gibt es da sogar die größte Divergenz bislang, vermutlich wegen der vielen Gesetzesänderungen weltweit, die ab 2022 gelten. 19.2 für SaaS kommt allerdings erst im Laufe des Januar, während es für OnPrem heute released wurde. Details hier (für MS-Partner ):
https://www.yammer.com/dynamicsnavdev/# ... 6338167808