Auslagerung aus Lager schlaegt fehl obwohl genuegend Einheiten vorhanden sind

[roman.karuschka@…]

"Fehler!

In Lagerplatz 'Gelb16' ist nicht genug von 'Artikel A' vorhanden, um 12 Stk. 0,75kg zu entnehmen."

Es handelt sich im vorliegenden Fall um einen Lagerplatz im System, der 800 Einheiten des benannten Artikels enthaelt. Der Fehler ist auf jeden Fall neu :-)

Geschieht bei manueller Auslagerung, "verschickt", inkl eingegebenem Infotext.
(So von Kd berichtet)
Lt Lagerist dort auch bei Auslagerung aus Lieferschein.

Kommt lt Kunden nur bei einigen, wenigen Artikeln vor, die im Dezember eingelagert wurden.
(Versuche da noch mehr Infos zu zu besorgen, bin gerade unterwegs, evtl kommt ja schon jemand auf 'ne moegliche Fehlerquelle)

(und man teilte mir eben auch mit, dass bei der Kette Auftrag -> Lieferschein -> Rechnung das Auftragsdatum nicht mehr mit in die Rechnung uebernommen wird)

Auf die Schnelle geprueft:
Lagerbestand anzeigen

Lager Lagerplatz Artikelnummer Artikelbeschreibung Chargennummer Menge
Lager 1 Gelb16 15015-08 Artikel A 804 Stk. 0,75kg

Deine Einheit ist "Stk. 0,75kg"?

Ist ein wenig anstrengend dann zu sehen, was daran was ist.

Ich erinnere mich dunkel sowas schonmal gesehen zu haben und es nicht reproduzieren zu können.

Wenn Du Deine Kundendaten nicht rausgeben kannst, kannst Du das evtl mal bisecten?

Unter der Annahme, dass der Bug irgendwann seit der letzten stable reingekommen ist, einfach in einer Entwicklungsumgebung eingeben:

# git bisect start
# git bisect good release-2.6.1
# git bisect bad HEAD

Dann gibt er Dir ne Revision dazwischen und fragt Dich ob der Bug da auch besteht. Dann immer "git bisect good" oder "git bisect bad" antworten, und am Ende sagt er Dir welcher Commit den Fehler eingebaut hat.

Danach ein git bisect reset, und alles ist wieder auf dem alten Stand. (bis auf Datenbankänderungen natürlich)

so, dann probiere ich das mal durch, hier mal erste Erkenntnisse...

gerade als erstes (weil auf 'nem anderen Server noch installiert) den Artikel entnommen, lasse ich mir das dann aber wieder ueber die aktuelle Unstable anzeigen kriege ich dort zu sehen:

Gelb16 15015-08 IrgendeinArtikelname? IrgendeineEAN 804 IrgendeineEinheit?. 0,75x
Gelb16 15015-08 2008 IrgendeinArtikelname? IrgendeineEAN -1 IrgendeineEinheit?. 0,75x

Er zieht also nicht von der Menge ab sondern vermerkt als waere es ein anderer Artikel einen negativen Wert in der unstable. In der 2.6.0 sieht alles normal aus (sprich 803 Einheiten werden angezeigt, keine Fehler- oder Warnmeldungen)

In der Tat eine nette Funktion, werde ich mir merken..

and the winner (after half an hour of testing) is...:

[0e01f2fec9238a260279c6a80320bd152f8a9301] Einheit 'mal' auf 'Stck' geändert bei den Exportern der Shops.
omega:~/lxok/lx-office-erp# git bisect good
096f9e3e06dc378bcc2f97df58c74cec02b9f7ff is first bad commit
commit 096f9e3e06dc378bcc2f97df58c74cec02b9f7ff
Author: Bernd Blessmann <bibi@…>
Date: Sat Mar 6 01:16:11 2010 +0100

Funktionalität für Mindesthaltbarkeitsdatum hinzugefügt.

:040000 040000 a8b11a056bd2f54fe5b39973c8229fde0a738451 5232b71d56a64288ef20c36f0ddf66a27f7a7280 M SL
:040000 040000 2d53de5b643adeb722df6f662c0563bbcd8336e1 2e9604c3bd93054db02d1c549c5df38fafe95943 M bin
:040000 040000 5a7be3152f51bd6f4a699621a5d88aa50c77e604 dc84aa68b7dda1eb82fe2a541c117e230bf96bfc M doc
:040000 040000 9cbcb80e6388eac3936664e051663e3c155d4f27 86c70e7a501480ffe7e4d98ba54a1184607d91eb M sql
:040000 040000 d4bc8064bf26d9c906e1f721cb698388093efaf9 6e2866c7695b7364d92f00af437ddcfd51948e5b M templates
omega:~/lxok/lx-office-erp#

---

Warum damit dann einige, wenige der neu eingelagerten und erst kuerzlich angelegten Artikel zerbrechen ist jetzt die gute Frage, bis zu diesem Punkt hier ist auf jeden Fall alles ok gewesen. Ich kann nur vermuten, dass unter bestimmten Umstaenden das Mindesthaltbarkeitsfeld nicht im Soll-Zustand landet, wenn es nicht genutzt wird.

Und nun..?
Die besagten Artikel wurden im Dezember angelegt, lange nach dem Commit.

Und noch zwei Info-Bits..
Das Feature "Best Before" war in der fraglichen LXO-Installation schonmal aktiv, nicht ganz sicher bin ich mir, ob das auch zum Anlagezeitpunkt als die besagten Artikel eingestellt wurden der Fall war. Zum Zeitpunkt des auftretenden Fehlers war die Funktion jedoch mit Sicherheit in der config abgeschaltet (durch ein Update auf die aktuelle unstable haben wir die config neu geschrieben).
Jetzt wurde die Funktion nochmals aktiviert, in den Datenfeldern steht ein Mindesthaltbarkeitsdatum "02.12.2015", es ist also belegt.

Genau diese eingelagerte Menge mit belegtem MHD-Feld verursacht jedoch das Problem, und das Problem verschwindet, wenn man die MHD-Funktion wieder deaktiviert.

Der Auslagerungsmechanismus macht also etwas, was er nicht soll, wenn das MHD-Feld belegt ist, ohne dass die MHD-Funktion an ist.

Korrektur, das Problem verschwindet wenn man die Funktion wieder aktiviert, nicht deaktivert.

So, hab ich mir angesehen.

Ich könnte das so umbauen, dass die Lagerroutinen das bestbefore Feld komplett ignorieren, wenn das Feature ausgeschaltet, ist, bin mir aber sicher, dass das nicht sinnvoll ist.

Wenn jemand das Feature erst anschaltet, etwas mit MHD einlagert, dann das Feature wieder ausschaltet, dann etwas auslagert, was eigentlich abgelaufen sein sollte, und dann das Feature wieder einschaltet, sind auf einmal negative Lagerbeträge vorhanden.

Down that road lies madness.

In eurem speziellen Fall würde ich vorschlagen das bestbefore Datum im Lager zu grillen, so dass es konsequent leer ist. [1]

Ansonsten müsste dokumentiert werden, dass das bestbefore Feature nicht im laufenden Betrieb robust zu wechseln ist. Sobald die Configpatches nach 2.6.2 kommen wäre das ein Flag was besser in der Datenbank selber aufgehoben ist, als in der globalen Konfig, und was beim Anlegen einmalig vergeben wird, ähnlich wie Encoding, oder (von Holger vorgeschlagen) EÜR/Bilanz.

Ich setze den Bug in der Priorität herunter.

[1]: UPDATE inventory SET bestbefore = NULL;

Bessere Warnung in der Konfiguration in 22b3fe7.

Wirklich fixen kann man das nicht, dafür sind die Anwendungsfälle zu divers. Die einzige Möglichkeit wäre, das in die InstanceConf? zu packen, und beim eiditieren automatisch zu löschen und zu warnen.

Das wird aber nicht in 2.7.0 passieren.

close -> later.