Neu Mehrere Adressen pro Kunde (Kunde-, Liefer- und Rechnungsadresse)?

[gutberle]

@macler: Du hast recht, ich kann das von Dir beschriebene Verhalten voll bestätigen und natürlich ist das so nicht korrekt und ja, es ist sogar schlimm, es ist aber leider nicht neu. - Das Verhalten war schon in der 0.99923 genau so.

Ein Blick in die Datenbank zeigt aber leider auch, dass das systemimmanent ist. Jeder Lieferschein referenziert nämlich für seine Lieferadresse den zugrunde liegenden Auftrag und der wiederum hat die Lieferadresse nicht im Datensatz stehen, sondern referenziert "seine" (einzige) Lieferadresse in tlieferadresse und ebenso auch "seine" (einzige) Rechnungsadresse in trechnungsadresse. Es gibt in der Datenbank also gar nicht drei Lieferungen mit drei unterschiedlichen Lieferadressen, sondern es gibt drei Auslieferungsvorgänge eines (1) Auftrags. Das der nacheinander mehrmals abgeändert wurde, wird in der Datenbank überhaupt nicht abgebildet (oder zumnindest nicht in den Lieferdaten).

Das gleiche Problemverhalten gilt also auch für eine 3-malige Änderung der Rechnungsadresse in Deinem Beispiel, was vielleicht nicht so viel Sinn macht, wie bei Lieferadressen, aber das Prinzip ist das Gleiche: Es wird nach jeder Änderung immer die AKTUELL eingetragene Adresse verwendet, weil die Datenbank zur Zeit einfach nicht mehr hergibt.

P.S. Das heißt natürlich nicht, dass ich mich nicht auch über eine Behebung dieses unerwünschten Verhaltens freuen würde...

 

[Xantiva]

Hi,
erst mal freut es mich zu hören, dass Ihr Euch der Sache annehmen werdet!

Da wir überwiegend "B2C" machen, gebe ich Euch recht - reicht in 80% der Fälle sogar eine Adresse. Dann fängt es mit Kunden an, die an eine zweite Adresse (Liefer- oder Rechnungsadresse) angeben. Ob nun die Zustellung in der Firma, oder man hat für XYZ bestellt, bzw. - als wir noch über DHL versendet haben - die Lieferung soll an eine Packstation gehen.

Dann kommen aber gerade in unserem Bereich oftmals die "lukrativen" Kunden, die die drei Adressen immer ausreizen:

Privatperson X ist sowieso schon Kunde (= Kundenadresse). Für das Ferienlager in Pusemukel (= Lieferadresse) bestellt er noch Bastelartikel, die dann die Gemeinde Hintertupfingen (=Rechnungsadresse) bezahlt. Der Kunde bestellt also sowohl nur an seine "Kundenadresse", wenn er privat bestellt, wie auch mit unterschiedlichen Liefer- und Rechnungsadressen. Man kann auch Privatperson durch Lehrer(in), Kindergärtner(in), usw. ersetzen.

Dann bestellen Firmen: Angestellter/Einkäufer X (=Kundenadresse) fordert ggf. sogar erst mal ein Angebot an. Dann wird u. U. in ein anderes Werk geliefert (= Lieferadresse) und die Rechnungsadresse lautet sowieso noch mal anders.

Insbesondere Firmen freuen sich oft darüber, dass Sie bei uns eben keine Probleme mit den unterschiedlichen Adressen haben (in unserem bisherigen Shop/ Wawi-System).

Dazu gehört dann aber auch, dass der Kunde im Shop seine "Adressen" verwalten kann. Ich nehme noch mal die Lehrerin, die sowohl privat bestellt und auch für die Schule. Die will nicht dauern die Adressen neu tippen müssen.

Den "Bug", den macler und gutberle beschreiben habe ich beim testen noch nicht entdeckt. Aber es ist in der Tat sehr ungewöhnlich, dass bei einem Lieferschein in der Datenbank nicht die Adresse Bestandteil des Datensatzes ist. Kenne ich so von keinem System.

 

[mitlaser]

Mein Wunsch/Vorschlag wäre ja die große Lösung : (optionales kostenpflichtiges) Einbinden vom Combit AddressManager an die JTL-Wawi..Bearbeitung aller Kundendaten dann über den AM.
Besser kann man meiner Meinung nach CRM nicht lösen und JTL wäre diese Bastellösungen los..
Hab aber keine Ahnung, ob das als Plugin funktionieren würde, oder eine andere Lösung möglich ist..

 

[maik.schwefer]

Also, Kunde hat eine Rechnungsadresse und 3 Lieferadressen.
Auftrag anlegen mit 10 T-Shirts. Lieferadresse ist die 1. Adresse in Müchen z.B. und erhält über "Ausliefern" 3 T-Shirts
Auftrag nochmals aufrufen und 2. Adresse in Hamburg auswählen, diese erhält 4 T-Shirts
Auftrag nochmals aufrufen und 3. Adresse in Bochum auswählen, diese erhält 3 T-Shirts, jetzt ist der Auftrag komplett ausgeliefert.
In "Versand" stehen unter "Versendet" 3 LS, jeweils mit der Bochumer Lieferadresse. Die beiden vorheigen Adressen, München und Hamburg wurden überschrieben.
Es ist nicht mehr nachzuvollziehen, welche Lieferadresse welche T-Shirts bekommen hat.

Erstmal vorab: Das mehrere Rechungsadressen erlaubt werden ist mir klar, es geht jetzt um das Beispiel (bzw. wie ihr es nennt "Bug") mit mehreren Lieferadresse pro Auftrag von macler.

Achso, ihr habt dann 3 Lieferscheine an verschiedene Adressen? Der Lieferschein hat keine eigene Adresse, sondern geht immer an die Adresse des Auftrags. In dem Fall müsste man den Auftrag in 3 Aufträge aufsplitten, was meiner Meinung nach auch OK wäre, weil es ja 3 verschiedene Lieferadressen sind. Oder seht ihr an dieser Stelle wirklich änderungsbedarf?

Auch im B2B bestellt man wenn man die Ware an 3 verschiedene eigene Lager bestellen will doch mit 3 verschiedenen BEstellungen, oder vertue ich mich?

 

[Xantiva]

Ich würde es schon "Bug" nennen, wenn beim Erstellen eines weiteren Lieferscheins für einen Auftrag die Daten des ersten Lieferscheins überschrieben werden. Ich habe es nicht ausprobiert, aber passiert das bei Rechnungen vielleicht genauso (Wenn bei Euch die Adressen nur im Auftrag gehalten werden)? Das wäre dann fatal für die nächste Betriebsprüfung.

Wenn Euer Konzept vorsieht, es immer nur 1:1 Beziehungen zwischen Auftrag, Lieferschein und Rechnung geben darf, dann müsste Ihr zwingend verhindern, dass man erzeugte Dokumente nachträglich verändern kann.

Auch im B2B bestellt man wenn man die Ware an 3 verschiedene eigene Lager bestellen will doch mit 3 verschiedenen BEstellungen, oder vertue ich mich?

Ich kann auch einen Auftrag haben, mit 3 Positionen des identischen Artikels, aber anderen gewünschten Lieferadressen und wiederum einer gemeinsamen Rechnungsadresse. Oder als anderes Beispiel: Kunde bestellt größere Menge, ich kann kurzfristig nur einen Teil liefern. Der Rest wird dann an eine andere Adresse nachgeliefert. Und entweder gibt es dann eine Sammelrechnung, oder zwei Teilrechnungen?

Ja, ein Auftrag sollte einen Verweis auf die bei der Bestellung gewünschte Liefer- und Rechnungsadresse beinhalten, aber die tatsächlichen Daten sollten immer beim jeweiligen Datensatz von Lieferschein oder Rechnung hinterlegt.

 

[maik.schwefer]

Hallo,

wir müssen bei unserer Betrachtung hier erstmal Lieferschein und Rechnung trennen. Rechnung ist bei uns aktuell genauso wie Lieferschein noch 1:1 zum Auftrag, dies wird aber aktuell geändert, so dass es Sammelrechnungen und mehrere Rechnungen für einen Auftrag gibt. Daher lass uns bitte hier auf den Lieferschein beschränken, weil wir da noch keine Änderungen planen.

Mir ist schon klar was du wünscht, die Frage ist ob der Fall so häufig vorkommt und ob man dann nicht einfach den Auftrag je Lieferadresse in mehrere Aufträge aufsplitten kann. Wir könnten in Zukunft einbauen, dass ein Hinweis erscheint, falls zu einem Auftrag schon ein Lieferschein erstellt wurde und nachgehen die Lieferadresse geändert werden soll. (Jedoch kommt dies ja sehr häufig vor, wenn man das Versandetikett aufgrund fehlender/falscher Angaben in der Adresse korrigieren muss).

Wie wird euch den folgendes mitgeteilt: 1 Auftrag mit 3x Artikel A an 3 unterschiedliche Lieferadressen? Vermutlich nur im B2B per Mail/Telefon? Warum macht ihr da nicht drei Aufräge raus?

Ich will nur rausfinden, wir relevant dieser Fall ist, dass wir dafür die ganze Lieferscheinlogik ändern. Wir würden nämlich nur ungern die Lieferadresse in den Lieferschein ziehen.

Was sagen die anderen? Sind diese Fälle relevant?

 

[Xantiva]

Hallo Maik,

Wir könnten in Zukunft einbauen, dass ein Hinweis erscheint, falls zu einem Auftrag schon ein Lieferschein erstellt wurde und nachgehen die Lieferadresse geändert werden soll. (Jedoch kommt dies ja sehr häufig vor, wenn man das Versandetikett aufgrund fehlender/falscher Angaben in der Adresse korrigieren muss).

was passiert denn dann?
a) ursprüngliche Adresse war fehlerhaft und sollte korrigiert werden
b) es ist eine Lieferung an eine andere Adresse und die Adresse des ersten Lieferscheins darf nicht geändert werden

• Option a) ist einfach, es bleibt bei dem Verhalten der Anwendung wie sie ist.
• Wie wollt Ihr dann bei Option b) reagieren? Ist es möglich, dann einen Split des bestehenden Auftrags anzubieten? "Lieber Wawi-User, um eine andere Lieferadresse zu speichern muss der Auftrag aufgespalten werden ..." Dann wird ein weiterer Auftrag mit der Restmenge angelegt und der erste Auftrag um diese Restmenge reduziert und als geliefert eingetragen. Möglichst mit einem "Querverweis", dass man später noch mal nachvollziehen kann, was da passiert ist. (Was passiert, wenn das ein Online-Shop-Auftrag war?)

Wenn ich Dich richtg verstehe müsste dann die Lieferscheinlogik nicht geändert werden, oder? Und mit den kommenden Änderungen zur den Rechnungen, könnte man dann eine Sammelrechnung über alle Lieferscheine / Aufträge erstellen.

 

[gutberle]

@Xantiva+maik.schwefer: Ich möchte gerne klarstellen, dass ich das NICHT für einen Bug halte und auch nichts dergleichen geschrieben habe. Es ist so wie es ist "by design" und KEIN Fehler, das zeigt die Datenbank ganz klar. Ob das so bis zum bitteren Ende gedacht war und vielleicht doch Änderungsbedarf entsteht, ist eine andere Frage...

Die Beispiele, die Xantiva anführt, warum/wann man mehrere Lieferungen an unterschiedliche Adressen machen müsste, kann ich bestätigen. Insbesondere das Szenario "Nachlieferung an andere Adresse" kommt ziemlich häufig vor und ist auch nicht auf B2B beschränkt.

Dass dabei die Nachvollziehbarkeit der Lieferadressen flöten geht, ist definitiv nicht OK, aber hey, hier wird ja auch die Lieferadresse IM AUFTRAG geändert. Das mag wie ein "Weg zum Ziel" klingen, aber mal ehrlich, findet ihr das ok? - Müsste die Lösung nicht lauten, dass die Lieferadresse bei Bedarf direkt im Auslieferdialog angepasst werden kann?

Da aber auch das nur zielführend wäre, wenn dann diese und eben auch jede nicht geänderte Lieferadresse pro Lieferung gemeinsam mit dem Lieferschein gespeichert würde, wäre das direkte Editieren bei der Auslieferung zwar immer noch die bessere Lösung, als im Auftrag rumzuschmieren, aber es würde eben auch immer noch einen deutlichen Änderungsaufwand für JTL bedeuten.

Der richtigere und von der Businesslogik her korrektere Weg ist in der Tat die von Maik Schwefer vorgeschlagene Teillieferung mit Übernahme der Restmenge in einen neuen Auftrag. Das birgt aber (zumindest aktuell) noch zwei Probleme:

- Die meisten meiner B2B Kunden schreiben mir explizit vor, dass sie KEINE Teilrechnungen akzeptieren, beim Auftragssplit entstehen aber logisch unabhängige Aufträge und es wird immer eine Rechnung für jede Teillieferung erstellt.
- Versuche ich aber nach Durchfürung meiner Teillieferungen mit Auftragssplit, die Teilaufträge wieder zusammenzufassen, um eine Gesamtrechnung zu erzeugen, dann beklagt sich die Wawi darüber, dass die Adressen nicht übereinstimmen würden. Zuerst habe ich mich gewundert, warum sie das sowohl für die Rechnungsadressen der Teilaufträge, wie auch für dieLieferadressen moniert, dann wurde mir aber klar, dass die Wawi ja EINEN neuen Auftrag daraus machen will und der hat ... nur eine mögliche Liefer- und Rechnungsadresse ... - Back to start, keine Lösung!

@maik.schwefer: Wenn Ihr es also mit dem Refactoring der Rechnungsadresslogik möglich macht, dass ich über die Split-Aufträge von mehreren Teillieferungen, die an unterschiedliche Adressen gingen, EINE Sammelrechnung an die Rechnungsadresse des ursprünglichen Hauptauftrags erzeugen kann, dann IST das die Lösung, zumindest für mich. - Andere Stimmen?

 

[Schoko-Laden]

Hallo,

wir müssen bei unserer Betrachtung hier erstmal Lieferschein und Rechnung trennen. Rechnung ist bei uns aktuell genauso wie Lieferschein noch 1:1 zum Auftrag, dies wird aber aktuell geändert, so dass es Sammelrechnungen und mehrere Rechnungen für einen Auftrag gibt. Daher lass uns bitte hier auf den Lieferschein beschränken, weil wir da noch keine Änderungen planen.

Mir ist schon klar was du wünscht, die Frage ist ob der Fall so häufig vorkommt und ob man dann nicht einfach den Auftrag je Lieferadresse in mehrere Aufträge aufsplitten kann. Wir könnten in Zukunft einbauen, dass ein Hinweis erscheint, falls zu einem Auftrag schon ein Lieferschein erstellt wurde und nachgehen die Lieferadresse geändert werden soll. (Jedoch kommt dies ja sehr häufig vor, wenn man das Versandetikett aufgrund fehlender/falscher Angaben in der Adresse korrigieren muss).

Wie wird euch den folgendes mitgeteilt: 1 Auftrag mit 3x Artikel A an 3 unterschiedliche Lieferadressen? Vermutlich nur im B2B per Mail/Telefon? Warum macht ihr da nicht drei Aufräge raus?

Ich will nur rausfinden, wir relevant dieser Fall ist, dass wir dafür die ganze Lieferscheinlogik ändern. Wir würden nämlich nur ungern die Lieferadresse in den Lieferschein ziehen.

Was sagen die anderen? Sind diese Fälle relevant?

Ich halte das für Relevant.
Wir verkaufen zum Beispiel an einen Konzern der mit Kostenstellen, Einkaufserlaubnis und was nicht noch alles arbeitet. Wir bekommen dann eine Bestellung über Menge X die aufgeteilt werden soll an Lieferadresse A,B, und C. Wir dürfen aber nur eine Rechnung senden, weil nur diese eine Rechnung von der Kostenstelle zugelassen wurde. Dabei ist es egal ob ich mit 3 Rechnungen den gleichen Betrag bereche. Über Logik müssen wir an der Stelle dazu nicht sprechen... der Fakt ist, dass es uns nur erlaubt ist eine Rechnung zu stellen.
Deswegen wäre es toll, einen Auftrag mit mehreren Lieferadressen ausliefern zu können und die verschiedenen Lieferscheine dann zusammengefasst auf der einen Rechnung ausgeben zu können.

 

[deliman]

Genau richtig beschrieben. Noch ein Praxisbeispiel: große gesetzliche Krankenkasse (hier die Zentrale) fragt ein Projekt an, wo z.B. Plakate für deren Kundenmarketing an die einzelnen Geschäftsstellen in mehreren Bundesländern und ggfl. angrenzendes Ausland versendet werden soll. Man erstellt für die Zentrale ein Angebot und wandelt dann in einen Auftrag. Die Ware wird dann auf 100 Lieferadressen in unterschiedlicher Stückelung aufgeteilt. Für die Zentrale ist klar, 1 Auftrag = 1 Rechnung und nicht 100 Rechnungen für jede belieferte Geschäftsstelle einzeln, was letztlich nur den Buchungsaufwand exorbitant vergrößern würde, mehr Geld bekommt man ja dadurch auch nicht vom Kunden.

Nun sollten aber die Lieferungen auch in der Rechnung abgebildet werden um die Sache nachvollziehbar zu gestalten. Das geht definitiv nicht, da ja immer nur die Lieferadresse vom letzten erstellten Lieferschein ausgegeben wird und die anderen 99 fallen somit unter den Tisch! dazu hatte ich auch schon mal einen Thread aufgemacht. Oder man muss mal an den bereits erstellten Lieferscheinen etwas ändern oder DPD meldet, das die Straße nicht stimmt... Wenn man dann einen ganzen Stapel Etiketten gedruckt hat, empfehle ich den JTL Mitarbeitern mal, in ihrer eigenen Wawi den richtigen Versandvorgang rauszusuchen, wenn dann plötzlich überall die selbe Adresse in der Übersicht steht, nur um dann im Auftrag z.B. die schreibweise der Straße zu ändern und das Etikett noch einmal zu drucken (OK man kann anhand der Lieferscheinnummer suchen...). Trotzdem: Anwenderfreundlich und Logisch sieht anders aus! Der Aufwand, aus diesem einen Auftrag dann 100 zu machen ist viel zu hoch und aus Anwendersicht nicht nachvollziehbar. Hier wurden ja nun genug Beispiele genannt, wo man sich eine andere, bessere Lösung wünscht und wie die aussehen kann/muss.

Wir hatten das vorher direkt über unseren alten Onlineshop gemacht, der da eine Auftragsabwicklung mit im Backend hatte und da ging sowas problemlos. Ich denke auch eine Büroware, die wir mal vor ein paar Jahren im Einsatz hatten, kann sowas abbilden. Also so unwichtig ist diese Funktion und die unterschiedlich händelbaren Adressen + entsprechend nutzbare Emailadresse (1x Auftragsbestätigung an Ansprechpartnder x, Versandbestätigung an das Logistiklager y und Rechnung an die Finanzbuchhaltung z) nicht, was mir auch die Beteiligung an entsprechenden Threads zeigt nicht, als das JTL sich da Blind und Taub stellen sollte.

 

[Marc Völker]

Hallo,

ich hab mir das auch gerade mal aufmerksam durch gelesen, und bin da ganz ehrlich auch ein bisschen verwundert, wie man einen Auftrag mit X Lieferadressen machen soll. Das hier was passieren muss steht ausser Frage, aber das löst dann eben eine Sammelrechnung, und die hat Maik ja schon angekündigt.
Nur wie willst du das ganze nachhalten in einem Auftrag? Was soll an welche Adresse gehen?

Nehmen wir mal den Prozess auseinander, ein Vertriebler legt den Auftrag an, und bestätigt dem Kunden 3 x Produkt 1 an Lieferadresse a und 2 x Produkt 1 an Lieferadresse B, wie soll er das nun in einem Auftrag raus stellen? Damit es im Lager auch klappt, ohne das der Vertriebler dann ins Lager gehen darf, und die Lieferscheine von Hand zu erstellen, damit alles so ausgeliefert wird wie du es möchtest?! Kannst du nicht. Oder es wird so Komplex zu bedienen.
Warum den hier nicht die Nahelegende Lösung, für jede Adresse einen Auftrag?!.

Was ich nun sehen würde was man machen müsste.
1. Es müsste möglich sein einen Auftrag zu splitten. Direkt vom Vertrieb aus, um z.B. zu sagen Ware X an Adresse y.
2. Die beziehung zwischen Rechnung und Auftrag muss n:m sein. Theoretisch sogar zwischen Angebot und Auftrag Oder Auftrag zu Auftrag (Komplett Auftrag zu Gesplitteten Aufträgen, wobei der Komplette dann natürlich als Erledigt gelten muss.)
Damit sind dann Sowohl Sammelrechnungen als auch Teilrechnungen ohne Probleme möglich.
3. Nachlieferung an 3te Adresse, Sehe ich auch eher als Fall, der über ein Restware in neuen Auftrag übernehmen Funktion realisiert werden sollte.

 

[Jörg Westmeier]

Eigentlich ist die Lösung ganz einfach.

1. Anlegen der Rechnungsadresse als Kunde

2. Anlegen der Lieferadressen der obrigen Rechnungsadresse als Kunde

Nun muss ich nur noch in der Lage sein, dem Programm mit zu teilen, das die Lieferadresse wirklich eine Lieferadresse ist und kein eigenständiger buchhalterischer Kunde. Unser altes SAP Programm hat das so gelöst, das wir für die Lieferadresse die Möglichkeit hatten, eine Rechnungsadresse an zu geben. So bald für die Lieferadresse unseres Rechnungskunden Ware raus ging und eine Rechnung fakturiert wurde, ging diese automatisch auf das Konto der Rechnungsadresse und im Text stand über der Ware im Rechnungsformular die Lieferadresse mit Lieferscheinnummer. In der Historie der Lieferadresse wurde lediglich der Lieferschein angegeben, bei JTL wäre es dann der Auftrag. So konnte man auch unter der Lieferadresse sehen, was alles gelaufen war.

LG
Jörg

 

[Marc Völker]

Die meisten Systeme arbeiten hier auch was anders, sodass man im Grunde Kontakte hat, dass sind dann echt nur die Adressen, und es gibt Entitäten, welche einen Kunden / Lieferant darstellen, welche verknüpft werden, dazwischen gibt es dann auch beziehungen, damit ist das ganze kein problem. Den rest den du hier schreibst lies sich auch in JTL realisieren. Wird sicherlich auch mit dem CRM möglich werden, falls noch nicht im ersten Realease in den folgenden

 

[ChrisTS]

Ok, da hast Du die Latte schon sehr hoch gehängt.

Dann versuche ich es mal mit einer Art Mindestanforderung (aus meiner Sicht):

Für jeden Kunden sollte es min. drei Arten von Adressen geben:

1. Kundenadresse (Wichtig für den Kontakt zum Kunden selber!)
2. Lieferadresse
   
3. Rechnungsadresse

Sofern nur eine (Kunden-)Adresse vorliegt, wird die auch als Liefer- und Rechnungsadresse verwendet. Im Shop wird dem Kunden dann zunächst die Kundenadresse vorgeschlagen (die er bei der Registrierung angegeben hat). Dann kann er im Bestellvorgang abweichende Liefer- und Rechnungsadressen angeben. Komfortabel für den Kunden wäre es, diese Adressen auch in einem Art "persönlichen Adressbuch" verwalten zu können.

Essentiell ist aber noch ein weiteres Feld: "Referenznummer des Kunden"
Gerade bei Bestellungen von größeren Organisationen ist die eigene Bestellnummer des Kunden ein sehr wichtiges Merkmal, das auf keiner Rechnung bzw. auf keinem Lieferschein fehlen darf. Sonst gibt es nur Verzögerungen - sowohl bei einem zentralen Wareneingang, wie auch bei der Rechnungsanerkennung.
(Oder habe ich das Feld bei JTL nur noch nicht entdeckt?)

Ciao,
Mike

Genau so brauchen wir es auch
@maik.schwefer wann ist der Umbau der Kundendaten abgeschlossen? 1.3 evtl schon?

 

[deliman]

Wichtig ist halt, das man am Ende in der Sammelrechnung jeden Liefervorgang nachvollziehbar mit aufgelistet bekommt.

Gesendet von meinem ALE-L21 mit Tapatalk

 

[raymond-de]

Der Beitrag ist schon alt: hoffentlich können mir die Fragen trotzdem noch beantwortet werden.

Klappt es nun in JTL 1.5 oder 1.6 beispielsweise min. 200 Adressen an einem Kunden zu erstellen (sehr große Kunden oder z.B. Städte mit sehr vielen Adressen). Umfeld: hauptsächlich B2B.

Zusatzanforderung: an jede Adresse muss die Lieferung und Rechnung erfolgen können. Deswegen verstehe ich die Einstellung bei der Erstellung einer Adresse am Kunden nicht wo man schon wählen muss was es ist.

Eine Kundennummer (generiert) an die Unteradressen wäre auch noch sinnvoll, um schneller den Adressdatensatz zu selektieren bzw. bei Rückfragen des Kunden. Gerade bei sehr großen Kunden (vielen Adressen) wäre das sinnvoll.

Und: Die Adressen müssen verschoben werden können, also zu einem anderen Kunden.

 

[PBS-Profis]

Genau diese Funktionalität fehlt uns auch und somit können wir JTL letztlich nicht einsetzen.
M.E. wäre es beim aktuellen Stand der Kundenstammdaten nur noch ein geringer Programmieraufwand, Liefer- und Rechnungsadresse aus den Kundenanschriften frei kombinierbar zu machen und dann mit einer Kostenstelle des Kunden zu benennen….