Erstellt vor 8 Jahren

Geschlossen vor 7 Jahren

#426 closed Fehler (invalid)

Lagerverwaltung und Process_Assembly

Erstellt von: info@… Verantwortlicher: p.reetz@…
Priorität: normal Meilenstein:
Komponente: kivitendo ERP Version: 2.4.3
Schweregrad: kritisch Stichworte: Verkauf
Beobachter:

Beschreibung

Zunchst ein Bug in der Lagerverwaltung von LX-Office 2.2.2:

Wenn man ein Erzeugnis verkauft, welches wieder aus Erzeugnissen besteht, so
wird dieses im Lagerbestand nicht verringert. Dieses Verhalten ist eigentlich
für Erzeugnisse vorgesehen, die nur aus Dienstleistungen bestehen (siehe
Kommentar in IS.pm nahe dem untenstehenden Patch). Der Fehler kommt daher, dass
in LX-Office sowohl Dienstleistungen als auch Erzeugnisse eine leere
inventory_accno_id haben und nur darauf getestet wird. In SQL-Legder wurde
dieser Fehler mit dem untenstehenden Patch beseitigt. Jetzt wird auch noch auf
assembly=true getestet.

Das Feature "sub process_assembly", welches sich iterativ selbst aufruft, ist
äußerst problematisch. Beim Buchen einer Rechnung kann das Durchlaufen der
Schleifen mehrere Minuten dauern. Bei komplizierten Erezeugnissen (wir haben
solche mit mehreren Untererzeugnisebenen und über 1000 Einzelteilen (Waren)),
bricht der Prozess sogar ab, ohne eine Buchung korrekt durchzuführen. Ich
tendiere dazu, dieses Feature bei mir auszukommentieren. Mit ihm werden die
"Assembly-Items", die von einer Rechnung betroffen sind als "allocated" markiert
in die Invoice-Tabelle eingetragen. Wozu dies gut sein soll, ist mir nicht recht
klar. Wo werden die mit "assembly_item=true" gesetzten Elemente aus der Tabelle
invoice verwendet?

Viele Grüße,
Joachim Zach

--- IS.pm.orig 2006-11-13 16:10:17.000000000 +0100
+++ IS.pm 2006-11-13 16:05:16.000000000 +0100
@@ -520,20 +520,23 @@

if ($form->{"assembly_$i"}) {

# do not update if assembly consists of all services

  • $query = qq|SELECT sum(p.inventory_accno_id)
  • FROM parts p

+ $query = qq|SELECT sum(p.inventory_accno_id), p.assembly
+ FROM parts p

JOIN assembly a ON (a.parts_id = p.id)

  • WHERE a.id = $form->{"id_$i"}|;

+ WHERE a.id = $form->{"id_$i"}
+ GROUP BY p.assembly|;

$sth = $dbh->prepare($query);

$sth->execute
$form->dberror($query);
  • if ($sth->fetchrow_array) {

+ my ($inv, $assembly) = $sth->fetchrow_array;
+ $sth->finish;
+

+ if ($inv
$assembly) {

$form->update_balance($dbh, "parts", "onhand",

qq|id = $form->{"id_$i"}|,
$form->{"qty_$i"} * -1)

unless $form->{shipped};

  • }
  • $sth->finish;

+ }

# record assembly item as allocated
&process_assembly($dbh, $form, $form->{"id_$i"}, $form->{"qty_$i"});

Änderungshistorie (4)

comment:1 Geändert vor 8 Jahren durch info@…

  • Version von 2.3.9 nach 2.2.2 geändert

comment:2 Geändert vor 8 Jahren durch info@…

  • op_sys auf Alle gesetzt

Sollte sich jemand doch einmal mit diesem Bug beschäftigen, weise ich darauf
hin, dass die Patches von mir bis zur Version 2.4.3 weitergepflegt wurden. Man
findet sie im User Forum.

comment:3 Geändert vor 7 Jahren durch info@…

  • Version von 2.2.2 nach 2.4.3 geändert

comment:4 Geändert vor 7 Jahren durch m.bunkus@…

  • Lösung auf invalid gesetzt
  • Status von new nach closed geändert

Mit der neuen Lagerverwaltung hat sich dieser Bug erledigt, weil onhand
automatisch aus den Lagerbewegungen berechnet wird. Der Code, der hier gepatcht
wird, ist in der 2.6.0 nicht mehr enthalten.

Momentan ist zwar das Einlagern von Erzeugnissen noch nicht implementiert, aber
das ist ein anderer Bug.

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.