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