Project

General

Profile

Fehler #130

individuelle Lieferadresse bei wiederkehrenden Rechnungen

Added by Bernd Bleßmann over 5 years ago. Updated over 5 years ago.

Status:
Neu
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
02/12/2016
Due date:
% Done:

0%

Estimated time:

Description

In f46afb13bacfe1d838cb4a7a5b5b58e8145ff4b1 wird der Bug (trac #2296) angegangen, um individuelle (manuelle/ custom) Lieferadressen zu behandeln.
Hier wird allerdings aus einer ausgewählten Kunden-Lieferadresse im Auftrag (shipto_id in order gesetzt) eine individuelle Lieferadresse für die Rechnung gemacht (Eintrag in shipto mit module=AR).
Aber die shipto_id aus dem Auftrag wird auch übernommen (durch new_from) bzw. dann nicht entfernt. Individuelle Lieferadressen werden nicht berücksichtigt.

Meiner Meinung nach könnte anhängender Patch helfen:
- er lässt die shipto_id aus dem Auftrag, wenn gesetzt
- er legt eine neue indiv. Shipto an, wenn im Auftrag keine shipto_id gesetzt war und eine indiv. shipto gefunden wurde
- er belegt die shipto-Variablen in prepare_for_printing auch, wenn eine indiv. Adresse gefunden wird

Evtl. wäre es sinnvoll, das Belegen der shipto-Variablen in flatten_to_form zu machen?

Und vielleicht auch in SL::DB::Invoice->new_from ein shipto-Objekt mit zurückzugeben (wenn indiv. Shipto vorhanden), wie bei SL::DB::DeliveryOrder->new_from.

Hat jemand Kommentare/Ideen/Anregungen dazu?


Files

periodic_invoice_custom_shipto.diff (2.33 KB) periodic_invoice_custom_shipto.diff Bernd Bleßmann, 02/12/2016 01:43 PM

History

#1

Updated by Bernd Bleßmann over 5 years ago

Bernd Bleßmann schrieb:

Und vielleicht auch in SL::DB::Invoice->new_from ein shipto-Objekt mit zurückzugeben (wenn indiv. Shipto vorhanden), wie bei SL::DB::DeliveryOrder->new_from.

Da das z.B. auch MassInvoiceCreatePrint betrifft, sollte SL::DB::Invoice->new_from das custom_sipto zurückliefern, welches dann auch in den convert_to-Routinen berücksichtigt werden sollte.

#2

Updated by Moritz Bunkus over 5 years ago

Ich habe gerade erst die Behandlung individueller Lieferadressen deutlich gefixt und dabei f46afb13bacfe1d838cb4a7a5b5b58e8145ff4b1 in 2a51537014d67c1f97a37b18548506f3e15549b5 revertet, weil der Fix f46a… an der falschen Stelle angesetzt hat. Hintergrund war, benutzerdefinierte Variablen bei Lieferadressen zu ermöglichen, wobei mir diverse Bugs in den Lieferadressen aufgefallen sind.

Mindestens die folgenden Commits sind hier relevant für individuelle Lieferadressen:

0eb9010 * SL::DB::Invoice->new_from: individuelle Lieferadressen richtig behandeln
492c85c * DeliveryOrder->new_from: kein $custom_shipto-Objekt zurückgeben
3f0ed51 * Shipto: Methode zum Clonen in SL::DB::Shipto und nicht in DeliveryOrder->new_from

Damit sollte dein Patch überflüssig sein, Bernd; außerdem hätte auch er das Problem an der falschen Stelle behoben – nämlich im Hintergrundjob (falsch) und nicht in den Rose-Klassen (da gehört der Fix hin, damit eben nicht nur Hintergrundjobs profitieren sondern jegliche Funktion, die Objekt 1 in Objekt 2 wandelt).

Also available in: Atom PDF