3.9.1 Lieferschein auslagern über Standardlagerplatz wirft Fehler

Question

Moin nochmal,

beim weiteren Testen ist mir noch Folgendes untergekommen:
Beim Versuch, einen Lieferschein über den Standardlagerplatz ohne Prüfung der Lagermenge auszulagern, wird der Fehler

Can't call method "parts_id" on an undefined value at /usr/local/src/lx-office-erp/SL/Controller/DeliveryOrder.pm line 1260.

geworfen. Ich habe den gesamten Workflow über Angebot, Auftragseingang¹, Auftragsbestätigung, Anzahlungsrechnung, Lieferschein verwendet, falls das von Belang ist.

Der Fehler ist in der Steigmann-Werft-Demo reproduzierbar.

Hab dann mal ein wenig nachgeforscht und gefunden, dass ins Array @transfer_requests bereits eine dereferenzierte parts_id gepusht wird. Da ich nicht wusste, wofür das nochmal gut sein kann, habe ich zusätzlich das ganze Item mit dazu gepusht (anstatt einfach die Zeile 1260 entsprechend zu ändern), damit der Vergleich in Zeile 1260 nicht fehlschlägt.

push @transfer_requests, {
  'delivery_order_item'    => $item,
  'delivery_order_item_id' => $item->id,
  'warehouse_id'           => $part->warehouse_id || $default_warehouse_id,

Damit hat das zwar soweit funktioniert, das Auslagern läuft aber dahinter in eine Endlosschleife (ich bekomme einen Timeout-Fehler von mod_fcgi).

Das schaue ich mir dann nach dem Aufstehen nochmal an, vielleicht schaut ja auch mal jemand anders darüber. ;-)

Grüße,

Hannes

Comments

Zwischenstand:

Hab das noch etwas weiter verfolgt, der Timeout tritt offenbar in der Sub save auf, welche in action_transfer_stock aufgerufen wird.

Mit anderen Worten:
Die Sub action_transfer_stock_default läuft mit den beiden kleinen Änderungen durch, am Ende wird von dort die Sub action_transfer_stock aufgerufen, welche bis self->save; kommt, dort tritt dann der Timeout auf.

Schau ich später weiter, muss noch ein wenig arbeiten.

Viele Grüße,

Hannes

---

In der Kaffeepause noch ein wenig weiter geschaut:

In self->save wird die Methode save von SL::Model::Record aufgerufen, und in selbiger komme ich bis

$record->save(cascade => 1);

$record ist ein SL::DB::DeliveryOrder-Objekt, es hängt also nach meinem laienhaften Verständnis beim Zugriff auf die Datenbank.

Die einzige save-Methode, die ich unterhalb SL::DB finde, ist in SL::DB::Object. da steht nach meinem Verständnis nicht viel drin außer einem Pre- und eine Post-Hook und eben dem Save in die DB, das ganze in einer Transaction gekapselt.

Wie man das debuggen könnte, weiß ich nicht, da bin ich zu doof. ;-)

Falls mir hier einer unter die Arme greifen möchte, bitte gern.
Die verwendete Datenbank ist eine Kopie meiner Live-Datenbank, die mit 3.8.0 problemlos funktioniert, wie gesagt mit extensiver Nutzung des Standard-Auslagerns ins Negative.

Für Tipps aller Art bin ich dankbar, es fängt langsam an, Spaß zu machen. :-D

Grüße,

Hannes

---

Ok,

wenn man das dbix-log4perl-Debug anschaltet, sieht man die Endlosschleife halt auch. Kaum macht man es richtig, geht es plötzlich. :-D

Beim Auslagern wird erst

Object.pm:794 Rose::DB::Object::update - prepare(1.216): 'UPDATE delivery_order_items SET ...
Object.pm:818 Rose::DB::Object::update - $execute(1.216) (UPDATE delivery_order_items SET ...
Object.pm:818 Rose::DB::Object::update - affected(1.216): 1
Object.pm:761 Rose::DB::Object::update - $STORE(1) = ['RaiseError',1];
Generic.pm:6080 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',0];
Generic.pm:6081 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',1];
Manager.pm:3217 Rose::DB::Object::Manager::delete_objects - $STORE(1) = ['RaiseError',1];

ausgeführt, was nach meinem Dafürhalten gut aussieht, weil offenbar ein Datensatz betroffen war (affected: 1).
Danach beginnt die Endlosschleife:

Manager.pm:3221 Rose::DB::Object::Manager::delete_objects - prepare(1.217): 'DELETE FROM delivery_order_items_stock WHERE delivery_order_item_id = ?'
Manager.pm:3238 Rose::DB::Object::Manager::delete_objects - execute(1.217) (DELETE FROM delivery_order_items_stock WHERE delivery_order_item_id = ?): 16573
Manager.pm:3238 Rose::DB::Object::Manager::delete_objects - affected(1.217): '0E0'
Manager.pm:3241 Rose::DB::Object::Manager::delete_objects - $STORE(1) = ['RaiseError',1];
Generic.pm:6080 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',0];
Generic.pm:6081 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',1];
Object.pm:757 Rose::DB::Object::update - $STORE(1) = ['RaiseError',1];
Object.pm:761 Rose::DB::Object::update - $STORE(1) = ['RaiseError',1];
Generic.pm:6080 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',0];
Generic.pm:6081 Rose::DB::Object::MakeMethods::Generic::__check_and_merge - $STORE(1) = ['PrintError',1];
Manager.pm:3217 Rose::DB::Object::Manager::delete_objects - $STORE(1) = ['RaiseError',1];

Das wird ca. 40s lang wiederholt, dem Zähler nach zu urteilen ca. 9000x

So, jetzt wirklich schönes WE allerseits. ;-)

/Hannes

EDIT: Timestamps und Severity aus den Logs gelöscht, weil jedenfalls bei mir hier die Scrollbalken nicht erscheinen und man darum das Ende der Zeilen nicht sehen kann.

---

Moin again,

hier an der Stelle stehe ich wirklich erst mal auf dem Schlauch.

$record->save mit dem cascade-Parameter soll - wenn ich die Dokumentation richtig lese - alle verbundenen Datenbankoperationen ebenfalls mit ausführen. An welcher Stelle aus einem UPDATE dann aber ein DELETE wird, und warum die Transaktion in eine Endlosschleife läuft und zurückgerollt wird, erschließt sich mir nicht.

Ich kann das bis vor den Beginn der Transaktion verfolgen, weiter komme ich nicht.
Ob das also eine Endloschleife ist, oder ob mein Datenbestand diese lang andauernde Aktion auslöst, weil irgend etwas "korrigiert" wird, kann ich so nicht nachvollziehen.

Any hints?

Danke und VG,

Hannes

Answer 1

Hallo Hannes,

ich habe mir den Fehler angeschaut und habe hin behoben.

Der Fix ist aktuell noch auf einem separaten Zweig. Dieser kommt in den Hauptzweig, sobald er die Qualitätskontrolle durchlaufen hat.

Link zum Fix

Du hattest das Problem richtig erkannt, nur dein Lösungsansatz hat, wie du auch selber festgestellt hast, zu einer Dauerschleife geführt. Denn die Objektstruktur würde dann wie folgt aussehen:

Lieferschein → Lieferschienposition → Lagerbewegung┐
                          ↑                        |
                          └────────────────────────┘

Durch cascade wird dann immer "weitere" Objekte gefunden (es wird nicht geschaut, ob ein Objekt schon abgearbeitet wurde). Delete wird aufgerufen, um die Lagerbewegungen der Position neu zu schreiben, indem alle alten gelöscht werden und die aktuellen geschrieben werden. Ich hoffe ich konnte dir beim Verständnis bisschen weiter helfen.

Viele Grüße,
Tamino Steinert

Comments

Hallo Tamino,

vielen Dank für Deine Antwort.

Das mit dem Zirkelbezug in der Objektstruktur muss ich noch einmal bei Tageslicht überdenken, um es zu verstehen. Bisher ist es mir nicht klar, das liegt aber wahrscheinlich daran, dass ich noch halbblind in der Struktur herumtappe und keine rechte Vorstellung vom Gesamtbild habe.

Beim Testen Deines Patches bin ich wieder auf den Syntaxfehler gestoßen, der bei Dir aber offenbar nicht auftritt. Warum wird bei mir die falsche Verwendung eines Hash-Slices angemosert und bei Dir nicht? Liegt das eventuell an meiner Perl-Version?

This is perl 5, version 26, subversion 1 (v5.26.1) built for x86_64-linux-thread-multi

Nachdem ich das testhalber wieder geändert habe, funktioniert Dein Patch hier bei mir insoweit, dass das Auslagern stattfindet.

Allerdings wird die Lagerbestandsmenge, welche unter jeder Lieferscheinposition steht, nicht direkt geupdatet, sondern erst, nachdem man das Dokument noch einmal neu geladen hat.

Und der Lieferschein ist zwar komplett ausgelagert, man kann ihn aber nicht schließen, weil der entsprechende Menüpunkt inaktiv ist mit dem Hinweis "Der Lieferschein wurde bereits geliefert". Bis 3.8.0 gab es da "Als geschlossen markieren", wobei ich mir allerdings nicht sicher bin, ob es den Anwendungsfall "Lieferschein wurde vollständig geliefert, wird aber nicht durch Erstellen einer Rechnung geschlossen" überhaupt benötigt. Kann sein, dass das so ok ist.

VG,

Hannes

---

Hallo Hannes,
das eine könnte durchaus an der Perlversion liegen.
Das zweite mit "Lieferschein als geschlossen markieren" ist in einem anderem Pullrequest.
https://github.com/kivitendo/kivitendo-erp/pull/359.

Beste Grüße
Werner kivitendodienstleister

Unterstütze kivitendo mit einer Basis-Subcription
kivitendo im fedivers

---

Hallo Werner,

ich habe jetzt mal die Perldoc durchgesucht, und in der Tat ist eine Änderung hinsichtlich einer neuen Fehlermeldung für 5.20 aufgeführt.
Ab 5.28 kann man delete offenbar auch Hashslices übergeben, was ja im Grunde passen würde, auch wenn der Slice im vorliegenden Fall nur ein Element hätte.

Kann es sein, dass eure Demo bzw. Entwicklerversionen mit Perl < 5.20 bzw. ≥ 5.28 laufen? Das würde den Fehler bei mir erklären.

Trotzdem wäre es meiner unmaßgeblichen Ansicht nach möglicherweise sinnvoll, hier die "alte" Syntax zu verwenden, weil wahrscheinlich nicht jede Installation auf Perl 5.28++ läuft.

VG,

Hannes

---

Hallo Hannes,

perl Version < 5.28 ? Welche Distribution / Installation verwendest du?

Ich nutze Debian und da ist ab buster schon Version 5.28++

Paket perl   
    buster (oldoldstable) (perl):
    5.28.1-6+deb10u1
aktuell   
    bookworm (stable) (perl):
    5.36.0-7+deb12u1:

P.S.:

Leider schaffe ich es dieses Jahr nicht zum Anwendertreffen
Ist halt von Dresden aus auch etwas weit.

Bin bei der Dresdner Linux-User-Gruppe lug-dd@mailman.schlittermann.de
Wir treffen uns jeden 2. und 4. Mittwoch im Monat um 20:00 im GAG 18
(Fritz-Löffler-Str. 16)

---

Hallo Gerd,

Welche Distribution / Installation verwendest du?

Ach, das ist irgend so ein vor einiger Zeit aufgesetzter Server mit Opensuse 15.3. Hätte bei Tumbleweed bleiben sollen... ;)
Die LX-Office/Kivitendo-Installation schleppe ich schon seit ca. 15 Jahren mit mir herum.

Jetzt über die Feiertage steht es eh an, den Server endlich mal neu aufzusetzen und dabei vlt gleich einiges mehr zu "containerisieren".

Leider schaffe ich es dieses Jahr nicht zum Anwendertreffen
Ist halt von Dresden aus auch etwas weit.

Ach, auch aus Dresden?
Ich hatte auch drüber nachgedacht, es aber aus terminlichen Gründen verworfen, zum Treffen zu fahren.

VG,

Hannes