projekt kivitendo

Dann müsste man aber die prinzipielle Verknüpfung Rechnung1 -> Auftrag2 diskutiert werden.
Die record_links für items ahmen hier einfach das Verhalten von record_links für records nach.
Also, die eigentliche Beleg-Verknüpfung.

Das croak in io.pl ist erstmal sinnvoll das es anschlägt, weil ansonsten keine klare Zuordnung
mehr in der Tabelle wäre.

Der Commit beschreibt ja die Beweggründe recht sinnvoll.

Etwas schlecht ist allerdings aktuell nur, dass die Prüfung nicht schon beim Speichern anschlägt, d.h. wir haben doppelt verknüpfte items in der Tabelle.

Wobei die Verknüpfung eigentlich klar sind, wenn man die auflistet:

LS1 -> Rechnung1
 delivery_order_items |     129 | invoice              |  6327 | 2016-03-17 13:18:36.172996 | 288
 delivery_order_items |     130 | invoice              |  6328 | 2016-03-17 13:18:36.172996 | 289
 delivery_orders      |   30749 | ar                   | 16676 | 2016-03-17 13:18:36.172996 | 290

Rechnung1 -> Auftrag1
 invoice              |    6325 | orderitems           |  1132 | 2016-03-17 13:20:21.690774 | 291
 invoice              |    6326 | orderitems           |  1133 | 2016-03-17 13:20:21.690774 | 292
 ar                   |   16675 | oe                   | 30754 | 2016-03-17 13:20:21.690774 | 293

Auftrag1 -> LS2
 orderitems           |    1132 | delivery_order_items |   131 | 2016-03-17 13:20:40.591207 | 294
 orderitems           |    1133 | delivery_order_items |   132 | 2016-03-17 13:20:40.591207 | 295
 oe                   |   30754 | delivery_orders      | 30756 | 2016-03-17 13:20:40.591207 | 296

LS2 -> Rechnung2
 delivery_order_items |     131 | invoice              |  6329 | 2016-03-17 13:20:53.48733  | 297
 delivery_order_items |     132 | invoice              |  6330 | 2016-03-17 13:20:53.48733  | 298
 delivery_orders      |   30756 | ar                   | 16677 | 2016-03-17 13:20:53.48733  | 299

Vom Datenmodell ist alles sauber und diese Codezeile ist nicht schlecht, kann aber noch verbessert werden:
:

          my @linked_deliveryorderitems = grep { $_->isa("SL::DB::DeliveryOrderItem") && $_->record->type eq 'sales_delivery_order' } @{$linkeditems};
          if ( scalar @linked_deliveryorderitems ) {
            croak "an invoice item may only be linked back to 1 sales delivery item, something is wrong\n" unless scalar @linked_deliveryorderitems == 1;
# zumindestens für den obigen Fall sind die eindeutig. Die Meldung müsste passieren, wenn Lieferscheine noch manuell hinzugefügt werden und man 
# nicht mehr eine eindeutige Zuordnung erkennen kann. ->

Somit würde ich die Fehlermeldung,bpsw. bei diesem Datenbestand erwarten:

LS2 -> Rechnung2
delivery_order_items | 131 | invoice | 6329 | 2016-03-17 13:20:53.48733 | 297
delivery_order_items | 132 | invoice | 6330 | 2016-03-17 13:20:53.48733 | 298
delivery_order_items | 134 | invoice | 6330 | 2016-03-17 13:20:53.48733 | 298
delivery_orders | 30756 | ar | 16677 | 2016-03-17 13:20:53.48733 | 299

Hmm.
Der Primary Key id ist schrott, dass geht aber leider nicht anders, da alles n:n verknüpft sein kann.

Wie sinnvoll der Workflow -> Verkaufs-Rechnung -> Verkaufs-Auftrag ist, kann ich nicht
entscheiden, in diesem Fall führt die Fehlermeldung allerdings zu einem falschen Verdacht, da alle Verknüpfungen, für mich,
eindeutig und klar aussehen.

Es ist eindeutig, dass Rechnung2->item1 mit 131 verknüpft ist und nicht mit weiteren Positionen.

Sonst schau doch mal bei Deinem Fall in den Datenbestand.

Danke

Mirko ist das eben auch passiert bei einem einfachen Auftrag → Lieferschein → Rechnung. Damit ist die Rechnung jetzt nicht mehr ausdruckbar.

Da das komplett euer Code ist: bitte kümmert ihr euch halbwegs zeitnah um einen Fix. Danke.

Ich würde den Commit 77350196300e930a dann komplett reverten und ferner auch die Verknüpfung von Verkaufs-Auftrag nach Verkaufs-Angebot entfernen, da ja hier auch ein neuer Workflow beginnt.

Damit reicht der revert nicht ganz, da noch weiterer Code der für die Rückverlinkung von Auftrag nach Angebot geschrieben wurde entfernt werden müsste.