customerNumber warum wurde das aus der Billingadresse entfernt ????

Seit der Version 5 … ist das Feld customerNumber von aus der

Tabelle s_user_billingaddress  in die Tabelle s_user  gewandert (ersatzlos)

Was für eine unnütze und unsinnige Vorgehensweise !

Ein Shopuser ist ein Shopuser und ein Bestellkunde ist ein Bestellkunde, das sind doch 2 verschieden paar Stiefel

und jeder der beiden kann oder muss eine eigene customerNumber haben, der Shopuser nur wenn er auch was bestellt, der Kunde immer wenn für eine Rechnungsanschrifft bestellt wurde.

Deswegen heisst ja die Tabelle auch billing_adress und zur Rechnungsanschrift gehört auch die Kundennummer und nicht anderst wohin.

Wie sonst sollte der Fall gelöst werden mit verschiedenen Rechnungsanschriften und verschiedenen Kundennummern ?

Alles weiteren Vorgehensweisen hängen nicht am Shopuser sondern an der Rechnungsanschrift und an der Lieferanschrift

Rechnung im Inland - Lieferung im Inland

Rechnung im Ausland Lieferung im Inland

Rechnung iim Ausland Lieferung ins Ausland

Rechnung imm Ausland Lieferung ins Inland

Es hat das mit dem Shopuser zu tun ?

Für mich heisst Customer übersetzt imme noch Kunde und nicht Shopuser, und das ist derjenige der die Rechnung erhält und nicht derjenige (z.B., Shopuser) der die Bestellung physikalisch macht.

Wer kommt denn auf solche Ideen und vor allem weshalb ?

Ich mach seit 30 Jahren Softwareentwicklung und, vorallem Softwaredesign. Deshalb wäre es toll, zu erfahren was der Grund war für diese Änderung.

Grüße aus Andalusien

 

Es gibt hier kein “Richtig” oder “Falsch”. Bei mir in der Arbeit betreuen wir sehr viele Shops. Dort wird überall pro Kunde eine Kundennummer gepflegt (oder dies ganz der WaWi überlassen). Egal welche (Liefer-/Rechnungs-) Adresse er verwendet. Wenn du dies anders benötigst ist das aber gar kein Problem. Es gibt nämlich Freitextfelder für s_user und s_user_address. Daher kannst du dort einfach eine zweite Kundennummer abspeichern.

Für mich ergibt das neue Modell viel mehr Sinn, da sonst dieselbe Kundennummer bei jeder Adresse redundant abgespeichert wird. Wird die Nummer einmal geändert, müsste man das bei jeder Adresse auch tun. Redundanz ist hier schlecht. Shopware hat zuvor auch nie pro Adresse eine Kundennummer generiert, sondern nur pro Kunde. Das Verhalten, wie du es beschreibst, war so in Shopware noch nie der Fall. 

Viele Grüße

Hallo,

 

Die Redundanz der Datenspeicherung bei einer Rechnung hat durchaus seinen Sinn, denn bei einer Änderung der Kundennummer würde logischerweise auch die Kundennummer für bereits bestehenden Rechnungen gelten, was garnicht zulässig ist, denn ein nachträglicher Ausdruck hätte dann eine andere Kundennummer wie das Original.

 

 

Es ist auch richtig dass pro Kunde eine Kundennummer gepflegt werden soll, da hast Du nicht richtig verstanden was ich geschrieben habe, ich wiederhols nochmal:

Mit der Gleichsetzung von Shopuser  und Kundennummer findet eine Verknüpfung statt die nicht sinnvoll ist, weil ein Shopuser für mehrere “Kunden” Bestellungen generieren können sollte.

Wir haben z.B. 3 Firmen und legen doch nicht in jedem Shop wo wir einkaufen 3 verschiedene Shopuser an sondern 3 verschiedene Rechnungsanschriften ebenso wie verschiedene Lieferanschriften.

Da brauchts auch keine 2 Kudnennummern pro User sondern je ein Kundennummer pro Rechnungsanschrift (s-billingadress)

Und das geht jetzt bei Shopware nicht mehr weil es keine Kundennummer pro Rechnung mehr gibt !!! So einfach ist das.

Ob das richtig ode falsch ist, ist auch nicht relevant, mit Sicherheit ist es aber nicht sinnvoll, und völlig unnötig gewesen.

Und wie gesagt, sofern es sich um Rechnungen handelt darf die Kundennummer nachträglich nicht geändert werden, somit ergibt sich fast zwingend eine redundante Speicherung um das Original jederzeit mit den Originaldaten wiederherstellen zu können (gilt übrigends auch für Währungsfaktoren und Mehrwertsteuersätze, die bei der Berechnung herangezogen werden, diese müssen ebenfalls in der Rechnung redundant hinterlegt werden falls nochmal eine Berechnungsroutine notwendig wird, damit diese mit den alten Bestandsdaten durchgeführt werden kann. Das ist deutlich einfacher als alle diese Werte mit Zeitfenstern zu speichern um nachträglich darauf zurückgreifen zu können. Das ist zwar trotzdem zu empfehlen, aber was ist wenn die Steuersätze von einem User geändert wurden ??  Das alles ist nicht irgendwelchen Programmierern, Opimierungsgedanken, oder sonst wem geschuldet, sondern dem deutschen Fiskus der das so verlangt. Übrigends auch in Spanien so.

Ein frohes und erfolgreiches Neues Jahr für alle Forummitglieder und vor allem für das Team von Shopware

Uli

 

Mit der Gleichsetzung von Shopuser  und Kundennummer findet eine Verknüpfung statt die nicht sinnvoll ist, weil ein Shopuser für mehrere “Kunden” Bestellungen generieren können sollte.

Nur weil das bei dir so ist, darfst du hier nicht auf die Allgemeinheit schließen. Ich sehe es genau anders. Ein Shopuser ist gleichzeitg auch ein Kunde. So ist das bei allen Shops, die ich kenne. Wenn es bei dir anders ist => Freitextfeld. 

Wir haben z.B. 3 Firmen und legen doch nicht in jedem Shop wo wir einkaufen 3 verschiedene Shopuser an sondern 3 verschiedene Rechnungsanschriften ebenso wie verschiedene Lieferanschriften.

Wenn du das so machst, ist das ja i.O. Du musst ja nur ein Freitextfeld anlegen und dort die Nummer separat pflegen. Das machen eben (so ist es mir jedenfalls bekannt) nicht viele Shopbetreiber so.

Ob das richtig ode falsch ist, ist auch nicht relevant, mit Sicherheit ist es aber nicht sinnvoll, und völlig unnötig gewesen.

Ich finde das absolut nötig, da bei jedem Shop den ich kenne Shopuser = Kunde gilt. 

Und wie gesagt, sofern es sich um Rechnungen handelt darf die Kundennummer nachträglich nicht geändert werden, somit ergibt sich fast zwingend eine redundante Speicherung um das Original jederzeit mit den Originaldaten wiederherstellen zu können (gilt übrigends auch für Währungsfaktoren und Mehrwertsteuersätze, die bei der Berechnung herangezogen werden, diese müssen ebenfalls in der Rechnung redundant hinterlegt werden falls nochmal eine Berechnungsroutine notwendig wird, damit diese mit den alten Bestandsdaten durchgeführt werden kann.

Bei Bestellungen wird die Kundennummer ja weiterhin zusätzlich in s_order_billingaddress gespeichert. Konsitenz ist also ebenfalls gewährleistet.

 

Fazit: Eine Lösung mit Freitextfeldern habe ich dir bereits genannt. Eine Änderung am Core wird mit Sicherheit nicht vorgenommen.

Viele Grüße und einen guten Rutsch :slight_smile: