Rechnung bekommt immer die Lieferadresse des Kunden

[bibi@…]

Es wird immer eine (die erste?) Lieferadresse des Kunden bei der manuellen Lieferadresse eingetragen, falls es Lieferadressen beim Kunden gibt und keine davon ausgewählt wird.

1. Fall: Beim Kunden sind schon Lieferadressen hinterlegt. Dann wird beim Erstellen einer Rechnung die erste Lieferadresse in der Auswahlbox ausgewählt und die Daten werden als manuelle Lieferadresse eingetragen (zu prüfen mit dem Knopf "Lieferadresse" unten). Das bleibt auch so, wenn ich nach Auswahl des Kunden die Selection wieder auf leer setze.

2. Fall: Lege ich eine Rechnung für einen Kunden an, bei dem keine Lieferadresse hinterlegt ist, ist alles ok. Lege ich aber nachträglich Lieferadressen in den Kundenstammdaten an, und öffne danach die Rechnung erneut, so ist zwar die Auswahlbox noch leer, aber bei die manuellen Lieferadresse ist mit Daten einer (oder der ersten) Lieferadresse gefüllt.

Das erste Verhalten ist so gewollt. Das zweite nicht.

Fall 2 (imo Fehler) in der aktuellen Demo reproduzierbar.

Mhm. Beim ersten Fall finde ich das Verhalten aber zumindest ungücklich. Die erste Lieferadresse wird automatisch ausgewählt. Will ich aber jetzt keine abweichende Lieferadresse haben, so muss ich die Auswahl auf leer setzen _und_ den Knopf Lieferadresse drücken und dort alle Felder per Hand leer machen. Zudem wird dieser leere Datensatz dann in der DB gespeichert.

Ich bin im Zuge des Länderdropdowns auch auf die Problematik mit Lieferadressen gestoßen. Eine Sache, die ich sehr schlecht gelöst finde, ist, dass bei neu erstellten Lieferadressen keine shipto_id (in Aufträgen etc.) gespeichert wird! Es wird nämlich, wenn keine shipto_id vorhanden ist, in der Tabelle shipto nach der trans_id gesucht. Diese doppelte Verknüpfung ist sehr verwirrend (für Entwickler), zumal sie sehr leicht zu beheben wäre, indem man einfach immer eine shipto_id speichert!

Weiterhin ist auch zu überlegen, ob man vielleicht Adressen in eine neue Tabelle auslagern sollte. Dann könnte man nämlich, auch wenn Liefer- und Rechnungsadresse gleich sind, das Feld shipto_id IMMER speichern und so einen NOT NULL Constraint in der Datenbank setzen.

...indem man einfach immer eine shipto_id speichert!

Und damit würde jede Lieferadresse, die du einmalig in einem Beleg manuell eingibst, in den Stammdaten landen und diese riesig verschmutzen. Abgelehnt. Es ist schon Absicht, dass die in den Belegen abgeänderten Lieferadressen eben gerade nicht in den Stammdaten (und damit ab sofort in jedem anderen Beleg auch) auftauchen.

Es ist durchaus sinnvoll, die Adressenspeicherung umzustellen, nur alles andere als trivial. Und wenn du's ändern willst, dann bitte richtig und nicht so wie du dir's bisher vorgestellt hast, weil das die Sache für den User nicht verbessert, sondern verschlimmert.

Eine "richtige" Adressspeicherung sähe so aus:

• Es gibt eine Tabelle mit Adressen. In dieser wird ein Typus gespeichert, grob gesehen: "Stammdaten" oder "Einzeladresse". Nur die vom Typ "Stammdaten" werden in den Kunden-/Lieferantenstammdaten aufgeführt.
• In den Stammdaten: Die Rechungsadresse und der separate Tab "Lieferadresse" werden zugunsten einer allgemeinen Adressverwaltung beim Kunden/Lieferanten aufgegeben. Die Funktionsweise soll so sein, dass beliebig viele Adressen eingetragen werden können. Zusätzlich kann man eine Adresse als Rechnungsadresse flaggen und eine als "Hauptlieferadresse". Letztere ist optional.
• Belege sollen sich so verhalten, dass beim Neuanlegen eines Beleges die Hauptlieferadresse ausgewählt ist. Es werden aber alle beim Kunden/Lieferanten hinterlegten Adressen als Lieferadresse angeboten.
• Belege, Teil 2: Legt der User dann eine individuelle Adresse an, so wird diese zwar auch in besagter Tabelle gespeichert, aber vom Typ "Einzeladresse" und ist damit weiterhin nur in diesem einen Beleg gültig. Die Auswahlbox der Lieferadresse sollte dann auch keinen leeren Eintrag enthalten, sondern einen leichter verständlichen Begriff wie "manuelle Eingabe".
• Belege, Teil 3: Bei der manuellen Eingabe einer Lieferadresse darf nichts vorbelegt sein. Statt dessen muss es eine Auswahl der bei den Stammdaten hinterlegten Adressen geben, die dann auf Knopfdruck die ausgewählte Adresse in die Eingabefelder kopiert.

Replying to m.bunkus@…:

...indem man einfach immer eine shipto_id speichert!

Und damit würde jede Lieferadresse, die du einmalig in einem Beleg manuell eingibst, in den Stammdaten landen und diese riesig verschmutzen. Abgelehnt. Es ist schon Absicht, dass die in den Belegen abgeänderten Lieferadressen eben gerade nicht in den Stammdaten (und damit ab sofort in jedem anderen Beleg auch) auftauchen.

Nein, eben nicht! Sie würden nur in der Tabelle shipto landen (also da, wo sie jetzt ohnehin schon gespeichert werden). In den Stammdaten tauchen nur Adressen auf mit Eintrag 'CT' in der Spalte module.

Was die Adressspeicherung betrifft, stimme ich dir zu.

Verhalten beim 2. Punkt:

Beachte: Nach dem ändern der Lieferadresse noch auf Buchen klicken! Ansonsten wird die Lieferadresse nicht gespeichert (was einerseits blöd, andererseits vielleicht auch gut ist). Wenn man das tut wird die Lieferadresse jedenfalls wie gewünscht gespeichert.

Der Grund, warum bei Punkt 2 die Lieferanschrift des Kunden ausgewählt wird, wenn man die Rechnung erneut öffnet, ist das Verhalten von kivitendo unter Punkt 1 ;) -- was vielleicht wie oben erwähnt u.U. auch nicht ganz glücklich ist.

Für die Adressverwaltung habe ich ein eigenes Ticket erstellt (siehe #2418).

Sorry - wieso ist der invalid?

Punkt 2 ist behoben.

In b1a26a678081cf61feea3b1f8b1ed91786bdcff4/erp:

Lieferadresse beim Laden von VK-Rechnungen nicht überschreiben, ...

... mit Lieferadresse aus Kundenstammdaten.

Betrifft #2345.

In b6213d3539ccd179cd1f21b9afc54b8de8970774/erp:

Einkauf/Verkauf?: Lieferadressenfelder nie aus Stammdaten vorbelegen

Das neue Verhalten ist wie folgt:

• Weder die shipto_id (die Drop-Down-Box in den Belegmasken) noch die individuellen shipto*-Felder werden weder beim Neuanlegen eines Beleges noch bei Wechsel des Kunden aus den Datenbanken belegt.

• Beim Ausdruck werden die shipto*-Felder nicht mehr aus der Mandantenkonfiguration vorbelegt, wenn keine Lieferadresse gesetzt ist.

• Beim Ausdruck werden die shipto*-Felder mit den Daten aus den Kundenstammdaten belegt, wenn die shipto_id (die Drop-Down-Box in den Belegmasken) gesetzt ist.

Die ursprüngliche Intention war, möglichst viele Fälle abzudecken. Ganz
ursprünglich war es nämlich in den Druckvorlagen gar nicht möglich,
Kontrollstrukturen zu benutzen und damit die Ausgabe konditional zu
steuern. Es konnte also rein in den Druckvorlagen nicht unterschieden
werden zwischen »der Benutzer hat keine Lieferadresse eingegeben« und
»der Benutzer hat eine eingegeben oder ausgewählt«.

Daher wurde die ganze Logik immer im Perl-Code abgehandelt.

Das macht aber erhebliche Probleme für den Benutzer, für den es absolut
intransparent ist, wann welche Lieferadresse wie vorbelegt wird. Hinzu
kommt, dass in den Belegmasken nicht ersichtlich ist, dass eine
individuelle Lieferadresse eingetragen wurde.

Hinzu kommt, dass die Druckvorlagen inzwischen verschiedene Mechanismen
zur Verfügung haben, um Fallunterscheidungen zu treffen (z.B. die
kivitendo-Mechanismen $(if shipto…)$ oder die LaTeX-eigenen
\IfThenElse?{\equal{$(shipto…)$}{…}}}…). Leider war es mit dem vorherigen
Code für die Druckvorlagen nicht mehr möglich festzustellen, ob der
Benutzer nun eine Lieferadresse eingegeben hat oder nicht.

Die neue Situation ist recht einfach:

Steht in »shiptoname« oder »shiptostreet« ein nicht leerer Wert, so ist
eine Lieferadresse vorhanden, ansonsten nicht.

Für die »nicht«-Fall kann dann jede Vorlage selber entscheiden, was zu
tun ist. Für Vorlagen im Verkaufsbereich sinnvollerweise gar keine
Lieferadresse ausgeben (oder einfach die Lieferadresse aus den
Kundenrechnungsdaten), für Vorlagen im Einkaufsbereich ebenfalls keine
Lieferadresse oder die Adresse aus der Mandantenkonfiguration.

Behebt #2345, #2400.