Fehlende Konfigurationsmöglichkeiten für Preis-Eingabe und/oder Ausgabe

[Monique Hahnefeld]

Hallo,

mit Isotope 2 wurden ja nun schon viel Konfigurationsmöglichkeiten mehr gegeben als in Version 1.
Jedoch wenn man sich bei den deutschen Shopbetreibern umhört,
bekommt man immer noch das Feedback das hier und da was fehlt.

Stichworte wie Rechtssicherheit, Nettopreise, B2B fallen oft.

Für das Programmierteam stellt sich oft das Problem das hier jeder etwas anderes sagt und braucht. Vermutlich hat das damit zutun das eben so viele verschiedene Anforderungen möglich sind.

Um dieses Thema einmal zu einen konkreten Vorschlag hinzuführen wäre es wichtig soviel wie möglich Erfahrungen zu haben.

Bitte stellt doch hier eure Fall-Beispiele rein und beschreibt welche Konfiguration, Funktion oder Ausgabe fehlte. Seid dabei bitte so konkret und detailliert wie möglich.

Vielleicht kann euch jemand hier dann auch erklären, ob es derzeit vielleicht doch möglich ist mit Hausmitteln zu lösen. Ansonsten würde es in die zukünftige Gestaltung des Isotope-Preissystems mit einfließen.

Danke schonmal!!!

[zonky]

hier mein Anfang...

https://docs.google.com/document/d/1...it?usp=sharing

Achtung! bin noch nicht fertig!!

Gruss

edit: ich habe den Link entfernt, da mir die aktuelle "Level-Strategie" von Isotope noch nicht ganz klar ist...
edit: wieder eingestellt

[about:blank]

Kann mich zonky in den bis jetzt aufgeführten Punkten nur anschließen.

[Monique Hahnefeld]

Danke schonmal an Zonky, für deine Mühe

Ich würde alle Antworten auf diesen Tread sammeln und in ca. 4 Wochen auswerten,
um den 17 August etwa.

Bin gespannt auf weitere Ansprüche oder Ansagen...

[zonky]

Danke schonmal an Zonky, für deine Mühe

bin gespannt ob

a) weitere Beiträge/Gedanken kommen
b) "jemand" gewillt ist sich dem anzunehmen und umzusetzen

;-)

[zonky]

btw: hat jemand "Open Source E-Commerce Leitfaden" von Leroy Füllgraf ??

[Claudia.Rathert]

Nach zonkys Steilvorlage (sehr beeindruckend!) traue ich mich fast schon gar nicht, einen Punkt einfach so ohne weitere Ausführung zu bringen, der obendrein nur zum Teil mit der Preiskonfiguration zu tun hat, aber anscheinend viele Isotope-User umtreibt:

Bundles

Grüßle
Claudia

[Monique Hahnefeld]

Hi Claudia,

es soll ja kein Fachbericht sein, aber wenigstens so beschrieben das man es versteht, wenn man es noch nicht gehört hat

@zonky, ja ich bin auch gespannt, aber auf zuversichtliche Art und Weise ...

[zonky]

@Claudia,

bei Magento gibt es per se Bundles - habe das Thema auch im Blick...

z.B. variable und fixe Bundles z.B. "PC-Bundle" bestehend aus variablen Komponenten der CPU, MB, Speicher, HDD/SSD usw. (die verändert werden können) gegenüber einem simplen Pfand (fix) der nicht geändert werden kann.

Das Bundle muss (n.m.M) als "pseudo" Artikel den Shop durchlaufen, da man in dem Warenkorb nicht die CPU eines Rechners irgendwo in der Liste haben will bzw. das Pfand auf dem Kassenbon auch gleich unter den Flaschen steht...

Fragen über Fragen...

Aber - das Thema sollte erst mal grundlegend die Behandlung der Preise beinhalten - als Basis von allen Berechnungen im Shop - und dann kommen die "Sahnehäubchen"...

... dann wird sich schnell die Frage stellen, ob Isotope sich im Wettbewerb zu Oxid, Magento, Shopware, Presa, xt:C usw. sieht - aktuell sehe ich (für mich) Isotope bei Projekten mit mind. 70% CMS-Anforderungen und höchstens 30% Shop-Gedöns

Aber auch bei den 30% ist mir die aktuelle Preisbehandlung (schmerzlich) auf die Füße gefallen - wenn man mit Isotope im Gegenzug Seiten machen kann, für die ich mir in Oxid oder xt:C usw. die "Finger gebrochen" hätte ;-)

Gruss

[Toflar]

... dann wird sich schnell die Frage stellen, ob Isotope sich im Wettbewerb zu Oxid, Magento, Shopware, Presa, xt:C usw. sieht

Da kann ich Antwort geben: Nein
Die Hauptziele und deshalb auch die Vorteile von Isotope sind die nahtlose Integration in Contao, Mehrsprachigkeit und Flexibilität.
Wer einen reinen Shop aufbauen will und sich im Enterprise-Business bewegt (Stichwörter: TDD, Caches à la Varnish, Load Balancing, ESI, ElasticSearch etc.), gehört nicht zu unserer Zielgruppe (und wie ich finde, auch nur bedingt in die von Contao).

[zonky]

Die Hauptziele und deshalb auch die Vorteile von Isotope sind die nahtlose Integration in Contao, Mehrsprachigkeit und Flexibilität.

... aber wer kennt das nicht: "Ein jeder Wunsch, wenn er erfüllt, kriegt augenblicklich Junge." Wilhelm Busch

;-))

[Monique Hahnefeld]

Bitte beim Thema bleiben. Danke!!

[zonky]

... ich glaube, von meiner Seite bin ich erstmal durch...

https://docs.google.com/document/d/1...it?usp=sharing

[Monique Hahnefeld]

Danke, ich habe mir die Datei schonmal gesichert

[zonky]

Hallo Monique,

ich glaube, Deine Erwartung/Wunsch waren mehr "Gastbeiträge"... was machen wir nun mit den "Überlegungen"?

[Paradroid]

Ein Tag vor Deadline - phew!

Ich lege gerade ein Produkt an, das mit unterschiedlichen *zusätzlichen* Optionen ausgestattet werden kann. Es sind drei Optionen, und im Moment muss ich drei Attribute dafür erstellen, diese alle im Produkttypen in den Variantenattributen anwählen, und mir danach alle Varianten generieren lassen.

In meinem Fall ist das so gerade noch vertretbar, denn es entstehen nur 2 hoch 3 = 8 Varianten. Was aber, wenn es noch mehr sind? Zweierpotenzen wachsen sehr schnell :-)

Mein Wunsch wäre also, Zusatzoptionen zu einem Produkt als Checkbox mit einem eigenen Preisfeld zu versehen: Ich kaufe z.B. ein Mainboard und setze das Häkchen "Jumper nach Kundenwunsch vorkonfigurieren". Im BE möchte ich dann nur den Preis für diese Dienstleistung festlegen, und der soll auf den Endpreis addiert werden, wenn der Kunde das Häkchen setzt.

Auch ein Workaround wie "Dienstleistung als separates Produkt definieren" erscheint etwas holprig, denn der geneigte Witzbold könnte die Option allein bestellen und ein Shop-Betreiber steht dann z.B. in der Pflicht, für den Kunden zusätzliche Löcher zu bohren, hat aber kein Material, in das gebohrt werden soll.

Ich hoffe dass klar wird, was mir als Attribut fehlt? Falls nein, erkläre ich das gern nochmal an einem anderen Beispiel.

Jens

[zonky]

@Paranoid: ich glaube: "total falsche Baustelle"!!

guck mal bei anderen Threads oder mach einen Neuen auf

... oder ich habs nicht kapiert!

[zonky]

@Monique: wie gehts weiter? was ist der Plan?

[Monique Hahnefeld]

Ich werde hier mal einen Cut machen und alle Wünsche und Anmerkungen auswerten. Dafür brauche ich ein wenig Zeit. Poste dann hier...

[zonky]

o.k. - aber was willst Du dann damit machen?

... hast Du einen "heißen Draht" zu den "Isotoplern"?

[Monique Hahnefeld]

Ich mach mir selber die Mühe und prüfe was mit Bordmitteln zu lösen ist und was nicht. Für den Rest überlege ich mir einen Lösungsansatz und schlage es den Programmierern vor. Weißt du nicht das im Isotope-Team bin?

[zonky]

Weißt du nicht das im Isotope-Team bin?

upps - verpasst.. super!

Ich mach mir selber die Mühe und prüfe was mit Bordmitteln zu lösen ist und was nicht. Für den Rest überlege ich mir einen Lösungsansatz und schlage es den Programmierern vor.

... meine Unterstützung ist dir sicher. "Möge die Macht mit Dir sein!" ;-)

[Monique Hahnefeld]

@Zonky Merci )))

So Kaffee aufgesetzt. Nachschicht kann beginnen ...

[Monique Hahnefeld]

"Wie bei anderen Online-Shops sollte es aber möglich sein, die Preise als Bruttopreise eingeben zu können, um z.B. marketingrelevante Preise wie xx,99€ oder “Brutto-Preis nicht höher als beim Wettbewerb” schnell und einfach eingeben zu können.

Aus der Forderung ergibt sich eine von den Shopkonfigurationen unabhängige bzw. übergeordnete Konfigurationsmöglichkeit für die Preiseingabe..."

-> und eine rekursive Rechnung wäre für die Bruttovariante nötig, welche wiederum das Ungenauigkeitsproblem hat, welches wir mit dem Nettopreis vermeiden wollen – Oder etwa nicht?

Wenn ja gibt es eine mathematische Möglichkeit, diese Ungenauigkeiten zu verhindern??

Nachtrag
Achso, 4 Nachkommastellen sind die Standardvorgabe für die Mindestgenauigkeit?

Die Ungenauigkeiten können ja sehr abweichen, je nachdem welche Zusatzfunktionen noch vorhanden sind (z.B. Staffelpreise, Versandarten nach Gewicht u.ä.)

Nachtrag2
" Gegebenfalls ergeben sich juristische Probleme aufgrund der Preisabgabenverordnung und der Gefahr einer Abmahnung im Bereich des Wettbewerbsrechtes."
-> Inwiefern schränkt es Mitbewerber ein, wenn Ungenauigkeiten bestehen? Das ist doch eine interne Kalkulation eines jeden Unternehmens.

Nächste Frage ?
"Der Shop-Betreiber sollte sich bewusst sein, das bei einer Eingabe der Preise in Brutto aufgrund der Rundung zum Netto-Preis und der anschließenden Rückrechnung zum Brutto-Preis Differenzen entstehen können."
Warum dieses hin und hergerechne? Wo wäre das zwingend notwendig? Am besten wäre es doch wenn zum Produktpreis je Netto UND Brutto in der Datenbank festgehalten werden. Alle weiteren Rechnungen sind doch temporär. Zudem ist es ja möglich in der Datenbank viele Nachkommastellen zu speichern und in der Ausgabe je beim Endwert dann die Rundung vorzunehmen. Oder versteh ich da was falsch ?
Man müsste dann natürlich eine oder mehrere Abhängigkeiten festlegen ab wann diese Datenbankwerte aktualisiert werden und welcher Wert der Hauptwert ist.

Zum Einkaufspreis als Zusatzfunktion
"In verschiedenen Shopsystemen gibt es die Möglichkeit neben dem (Netto-)Preis auch den Einkaufspreis mit anzugeben. Mit diesem Wert können Auswertungen um eine Gewinnabschätzung erweitert werden."
-> Das würde ich anderen Programmen überlassen. Mit den Grundfunktionen haben wir schon genug zu bewältigen. Alles andere kann man ja irgendwann als Erweiterung anbieten wenn der Grundaufbau da ist.

Anzeige der Preise
Hier finde ich deine Ansätze zwar gut jedoch nach meinem empfinden zu detailliert. Es gibt soviele verschiedene Anforderungen gerade an die Ausgabe im Template.
Ich denke das die Berechnung im Hintergrund erfolgen muss und am besten alle wichtigen Zwischensummen während der Berechnung als Variablen zur Verfügung stehen sollten. Die Mitgliedergruppe und Konfiguration sollte dann natürlich, wenn das nicht sogar schon so ist, auch zur Verfügung stehen.

Genauigkeit
"Die maximale Anzahl der Dezimalstellen darf die Genauigkeit der Datenbankeinträge aber nicht überschreiten."
-> Sollten wir da nicht auch drauf achten das Server nicht verheizt wird, wenn die Rechnungen mit so langen Zahlen erfolgen müssen. Ich weiß ja nicht von wievielen Nachkommastellen du sprichst wenn diese nicht mehr in einem Datenbankfeld gespeichert werden können

Ab- oder Aufrunden

Da wir uns im Bereich des Kaufmännischen befinden wüsste ich nicht warum das "normales/kaufm. Runden" nicht als standard gelten sollte. GIbts da einen Grund warum man andere Varianten braucht? Man muss es ja nicht verkomplizieren...

Informationen zu Preisangabe wie es der Gesetzgeber voraussetzt
"Für einen rechtssicheren Online-Shop - insbesondere bei B2C - ist es in verschiedenen Ländern (z.B. Deutschland) notwendig, bei den Preisangaben weitere Informationen einzubinden. Dazu gehören z.B. die Angabe “inkl. MwSt”, “inkl. gesetzlicher MwSt”, “exkl. MwSt”, “Alle Preise sind umsatzsteuerfrei gemäß Umsatzsteuergesetz, § 19” und “zzgl. Versandkosten”. Bei einem Shop der explizit auf B2B ausgerichtet ist, sind die Vorgaben in der Regel weniger umfangreich..."

Hier kann man sich mit Contao-Mitteln behelfen, auch über die Labels der Steuerklassen lässt sich da was machen.
Wenn hier jemand eine Out-Of-The-Box-Lösung möchte könnte man ja eine Erweiterung schreiben. Maybe Christian De La Haye...
Ich habe hier auch schonmal sowas begonnen für Isotope2: https://github.com/MoniqueHahnefeld/isotope_legal
Steht aber derzeit auf der Warteliste aus Zeitmangel.

Das Styling, ob PopUp, links, rechts oben kann alles über Templateanpassung und normales CSS wie auch JS gesteuert werden.

Weitere Berechnungsfunktionen neben Netto-Brutton
http://www.muenster-webdesign.net/bl...umme-subtotal/
-> super, sowas meinte ich mit wichtigen Variablen
Vermutlich müsste sowas für Isotope individuell defeiniert werden.

@zonky Ich denke das es gut wäre wenn wir mal eine Tabelle für eine Übersicht machen würden.
Diese Tabelle sollte die Reihenfolge der Rechnungsschritte beinhalten, sowie die optionalen Parameter und Variablen.
Als kurze Liste fällt mir spontan ein:
Allgemein

• Netto
• Staffelpreise
• Preis nach Gewicht
• Preis nach benutzerdefinierten Optionen (Attributte/ Varianten)
• Brutto
• Rabatt/ Gutschein
• Währung
  

Im Warenkorb

• Kosten des Versandes
• Kosten der Zahlungsart
• Skonto

Sonderbetrachtung bei der Preisauszeichnung und -berechnung
-> sowas gehört unbedingt in die Tabelle, Fall A/B/C

Hast du da vielleicht Lust dazu Zonky?

B2B/B2C
"Zusätzlich zu der individuellen Konfiguration der Preisanzeige in einer Shopkonfiguration, gibt es unterschiedliche Ansprüche und Berechnungsverfahren ob ein Shop für Endkunden"
-> Sowas kann man einstellen und anpassen mit Wissen über Isotope und Contao. Sowas als Out-Of-The-Box wäre sicherlich in einer Erweiterung gut aufgehoben.


Kennt sich hier wer aus???

Differenzbesteuerung..??
Pfandgebühr (Batterien)?


Danke nochmal Zonky, du hast da eine sehr tolle Basis geliefert !!!!

[zonky]

mach ich - werde auch mal wieder älter ;-)

... morgen sicher

[zonky]

"Wie bei anderen Online-Shops sollte es aber möglich sein, die Preise als Bruttopreise eingeben zu können, um z.B. marketingrelevante Preise wie xx,99€ oder “Brutto-Preis nicht höher als beim Wettbewerb” schnell und einfach eingeben zu können.

Aus der Forderung ergibt sich eine von den Shopkonfigurationen unabhängige bzw. übergeordnete Konfigurationsmöglichkeit für die Preiseingabe..."

-> und eine rekursive Rechnung wäre für die Bruttovariante nötig, welche wiederum das Ungenauigkeitsproblem hat, welches wir mit dem Nettopreis vermeiden wollen – Oder etwa nicht?

Wenn ja gibt es eine mathematische Möglichkeit, diese Ungenauigkeiten zu verhindern??

=> verstehe ich nicht - insb. was meinst Du hier mit "rekursive Rechnung"?

Nachtrag
Achso, 4 Nachkommastellen sind die Standardvorgabe für die Mindestgenauigkeit?

Die Ungenauigkeiten können ja sehr abweichen, je nachdem welche Zusatzfunktionen noch vorhanden sind (z.B. Staffelpreise, Versandarten nach Gewicht u.ä.)

=> die Genauigkeit kann bei vielen Shops bei der Konfig. eingestellt werden bzw. ist per se auf 4 eingestellt

Nachtrag2
" Gegebenfalls ergeben sich juristische Probleme aufgrund der Preisabgabenverordnung und der Gefahr einer Abmahnung im Bereich des Wettbewerbsrechtes."
-> Inwiefern schränkt es Mitbewerber ein, wenn Ungenauigkeiten bestehen? Das ist doch eine interne Kalkulation eines jeden Unternehmens.

=> jain - Problem ist dann vorhanden, wenn wir bei den Einzelpreisen z.B. 1,99€ angegeben haben 10 Stück kaufen und dann (warum auch immer) eine Summe von 20,01€ auf der Rechnung haben - bei Summe 19,85€ ist das sicher weniger das Problem

Nächste Frage ?
"Der Shop-Betreiber sollte sich bewusst sein, das bei einer Eingabe der Preise in Brutto aufgrund der Rundung zum Netto-Preis und der anschließenden Rückrechnung zum Brutto-Preis Differenzen entstehen können."
Warum dieses hin und hergerechne? Wo wäre das zwingend notwendig? Am besten wäre es doch wenn zum Produktpreis je Netto UND Brutto in der Datenbank festgehalten werden. Alle weiteren Rechnungen sind doch temporär. Zudem ist es ja möglich in der Datenbank viele Nachkommastellen zu speichern und in der Ausgabe je beim Endwert dann die Rundung vorzunehmen. Oder versteh ich da was falsch ?
Man müsste dann natürlich eine oder mehrere Abhängigkeiten festlegen ab wann diese Datenbankwerte aktualisiert werden und welcher Wert der Hauptwert ist.

=> sorry aber Netto + Brutto in DB geht (aus meiner Sicht) gar nicht! erstens bringt die Brutto-Spalte keinen Informationsgewinn (Thema Normalisierung) und zweiten muss Brutto nicht für alle gleich sein

Zum Einkaufspreis als Zusatzfunktion
"In verschiedenen Shopsystemen gibt es die Möglichkeit neben dem (Netto-)Preis auch den Einkaufspreis mit anzugeben. Mit diesem Wert können Auswertungen um eine Gewinnabschätzung erweitert werden."
-> Das würde ich anderen Programmen überlassen. Mit den Grundfunktionen haben wir schon genug zu bewältigen. Alles andere kann man ja irgendwann als Erweiterung anbieten wenn der Grundaufbau da ist.

=> o.k. ist "nice to have"...

Anzeige der Preise
Hier finde ich deine Ansätze zwar gut jedoch nach meinem empfinden zu detailliert. Es gibt soviele verschiedene Anforderungen gerade an die Ausgabe im Template.
Ich denke das die Berechnung im Hintergrund erfolgen muss und am besten alle wichtigen Zwischensummen während der Berechnung als Variablen zur Verfügung stehen sollten. Die Mitgliedergruppe und Konfiguration sollte dann natürlich, wenn das nicht sogar schon so ist, auch zur Verfügung stehen.

=> korrekt - das war nicht immer so - siehe https://github.com/isotope/core/issues/561

Genauigkeit
"Die maximale Anzahl der Dezimalstellen darf die Genauigkeit der Datenbankeinträge aber nicht überschreiten."
-> Sollten wir da nicht auch drauf achten das Server nicht verheizt wird, wenn die Rechnungen mit so langen Zahlen erfolgen müssen. Ich weiß ja nicht von wie vielen Nachkommastellen du sprichst wenn diese nicht mehr in einem Datenbankfeld gespeichert werden können

=> irrelevant - die DB rechnet nix, die speichert nur... gemeint ist lediglich, dass dass die Zahlen beim Einspeichern nicht abgeschnitten werden

Ab- oder Aufrunden

Da wir uns im Bereich des Kaufmännischen befinden wüsste ich nicht warum das "normales/kaufm. Runden" nicht als standard gelten sollte. GIbts da einen Grund warum man andere Varianten braucht? Man muss es ja nicht verkomplizieren...

=> ein triftigen Grund für DE sehe ich nicht - keine Ahnung wie das in anderen Ländern läuft... ich glaube in CH gibt es irgendwas mit 0,01 SFR...

Informationen zu Preisangabe wie es der Gesetzgeber voraussetzt
"Für einen rechtssicheren Online-Shop - insbesondere bei B2C - ist es in verschiedenen Ländern (z.B. Deutschland) notwendig, bei den Preisangaben weitere Informationen einzubinden. Dazu gehören z.B. die Angabe “inkl. MwSt”, “inkl. gesetzlicher MwSt”, “exkl. MwSt”, “Alle Preise sind umsatzsteuerfrei gemäß Umsatzsteuergesetz, § 19” und “zzgl. Versandkosten”. Bei einem Shop der explizit auf B2B ausgerichtet ist, sind die Vorgaben in der Regel weniger umfangreich..."

Hier kann man sich mit Contao-Mitteln behelfen, auch über die Labels der Steuerklassen lässt sich da was machen.
Wenn hier jemand eine Out-Of-The-Box-Lösung möchte könnte man ja eine Erweiterung schreiben. Maybe Christian De La Haye...
Ich habe hier auch schonmal sowas begonnen für Isotope2: https://github.com/MoniqueHahnefeld/isotope_legal
Steht aber derzeit auf der Warteliste aus Zeitmangel.

Das Styling, ob PopUp, links, rechts oben kann alles über Templateanpassung und normales CSS wie auch JS gesteuert werden.

=> tja - leider nicht "nice to have" für einen rechtssicheren Shop sondern "it´s necessary"

Weitere Berechnungsfunktionen neben Netto-Brutton
http://www.muenster-webdesign.net/bl...umme-subtotal/
-> super, sowas meinte ich mit wichtigen Variablen
Vermutlich müsste sowas für Isotope individuell defeiniert werden.

=> vermutlich ;-)

@zonky Ich denke das es gut wäre wenn wir mal eine Tabelle für eine Übersicht machen würden.
Diese Tabelle sollte die Reihenfolge der Rechnungsschritte beinhalten, sowie die optionalen Parameter und Variablen.
Als kurze Liste fällt mir spontan ein:
Allgemein

• Netto
• Staffelpreise
• Preis nach Gewicht
• Preis nach benutzerdefinierten Optionen (Attributte/ Varianten)
• Brutto
• Rabatt/ Gutschein
• Währung
  

Im Warenkorb

• Kosten des Versandes
• Kosten der Zahlungsart
• Skonto

Sonderbetrachtung bei der Preisauszeichnung und -berechnung
-> sowas gehört unbedingt in die Tabelle, Fall A/B/C

Hast du da vielleicht Lust dazu Zonky?

=> ich guck mal...

B2B/B2C
"Zusätzlich zu der individuellen Konfiguration der Preisanzeige in einer Shopkonfiguration, gibt es unterschiedliche Ansprüche und Berechnungsverfahren ob ein Shop für Endkunden"
-> Sowas kann man einstellen und anpassen mit Wissen über Isotope und Contao. Sowas als Out-Of-The-Box wäre sicherlich in einer Erweiterung gut aufgehoben.

=> wäre zumindest wünschenswert, wenn man es "einfach" einrichten kann....

[Monique Hahnefeld]

Hi Zonky,

"=> jain - Problem ist dann vorhanden, wenn wir bei den Einzelpreisen z.B. 1,99€ angegeben haben 10 Stück kaufen und dann (warum auch immer) eine Summe von 20,01€ auf der Rechnung haben - bei Summe 19,85€ ist das sicher weniger das Problem"

Tut mir leid, aber ich sehe hier immer noch keine Begründung für eine Verletzung des Wettbewerbsgesetztes. Man kann ja Staffelpreise einstellen.

Alles in Allem sehe ich auch die Angaben von Infotexten, worin nach deutschen Gesetzt informiert werden muss, nicht als Aufgabe von Isotope.
Das geht durch individuelle Anpassung des Shops durch einen Webworker zu lösen. Außerdem kann man das auch auf verschiedene Arten und mit verschiedenen Implementierungsvariationen, ja nach Designvorgaben lösen.

Meiner Meinung nach macht es Sinn hier erstmal das Problem mit den Nettopreisen zu lösen. Dann haben wir doch schon eine große Hürde genommen oder nicht?
Wie schaut es aus. Bekommst du das hin mit der Tabelle? Wenn ja bis wann ungefähr?? Sonst würde ich mich darum kümmern, weiß allerdings auch nicht wann ich dazu komme...

[zonky]

Hi Zonky,

"=> jain - Problem ist dann vorhanden, wenn wir bei den Einzelpreisen z.B. 1,99€ angegeben haben 10 Stück kaufen und dann (warum auch immer) eine Summe von 20,01€ auf der Rechnung haben - bei Summe 19,85€ ist das sicher weniger das Problem"

Tut mir leid, aber ich sehe hier immer noch keine Begründung für eine Verletzung des Wettbewerbsgesetztes. Man kann ja Staffelpreise einstellen.

=> bin kein Jurist... würde aber mal behaupten, die Preiskalkulation muss nachvollziehbar bzw. transparent sein - ich meinte damit lediglich, dass keine "plötzlichen" Preisabweichungen auftauchen dürf(t)en

Alles in Allem sehe ich auch die Angaben von Infotexten, worin nach deutschen Gesetzt informiert werden muss, nicht als Aufgabe von Isotope.
Das geht durch individuelle Anpassung des Shops durch einen Webworker zu lösen. Außerdem kann man das auch auf verschiedene Arten und mit verschiedenen Implementierungsvariationen, ja nach Designvorgaben lösen.

=> viele Sachen lassen sich sicher über individuelle Designs steuern, sofern die "Rohdaten" im Template zur Verfügung stehen - z.B. die Preise

Meiner Meinung nach macht es Sinn hier erstmal das Problem mit den Nettopreisen zu lösen. Dann haben wir doch schon eine große Hürde genommen oder nicht?
Wie schaut es aus. Bekommst du das hin mit der Tabelle? Wenn ja bis wann ungefähr?? Sonst würde ich mich darum kümmern, weiß allerdings auch nicht wann ich dazu komme...

=> meine "größten Sorgenkinder" sind die Netto-Brutto-Kalkulationen und die falschen Berechnungen über die Preisregeln
=> diese Woche wird sicher nix mehr - nächste Woche sind Ferien => also kann das für KW 44 "einschreiben"...

[Monique Hahnefeld]

"=> bin kein Jurist... würde aber mal behaupten, die Preiskalkulation muss nachvollziehbar bzw. transparent sein - ich meinte damit lediglich, dass keine "plötzlichen" Preisabweichungen auftauchen dürf(t)en"

Wie auch sollten Preisabweichungen auftauchen, wenn einfach der Produktpreis Multipliziert wird? Im Handel ist es zudem auch üblich Staffelpreise anzubieten. Was soll daran nicht Transparent sein, wenn 10 Stück 1 Euro günstiger sind?

"=> viele Sachen lassen sich sicher über individuelle Designs steuern, sofern die "Rohdaten" im Template zur Verfügung stehen - z.B. die Preise"
-> Ja daran arbeiten wir ja gerade

"=> meine "größten Sorgenkinder" sind die Netto-Brutto-Kalkulationen und die falschen Berechnungen über die Preisregeln"
-> Ja da meinte ich ja auch, dann sind wir uns ja einig. Ich finde das mit den Nettopreisen vor allem auch sinnvoll um eine nettopreisbasierte API für ergänzende Programme zur Verfügung zu stellen.

KW44, ok dann trag ich mir das mal ein und arbeite eine Übersicht des bestehenden Berechnungssystems aus. Dann können wir das mit der Tabelle gegenüber stellen.

[zonky]

Wie auch sollten Preisabweichungen auftauchen, wenn einfach der Produktpreis Multipliziert wird?

=> da liegt z.B. "der Hase im Pfeffer": was ist der Produktpreis? Brutto? Netto?

man kann z.B. vom angegebenen einzelnen Brutto-Preis den Netto-Preis berechnen auf zwei Stellen runden und mit Anzahl multiplizieren...

anbei eine kleine Tabelle mit Berechnungsbeispiel.

mwst.zip

[Monique Hahnefeld]

Hi Zonky,

deswegen wollte ich eine detaillierte Tabelle aufstellen. Sonst fangen wir hier über einzelne Bausteine an hin und her zu reden ohne Berücksichtigung der Abhängigkeiten.
Wenn wir die Tabelle haben und mit dem jetzigen System abgleichen kommen wir da sicher weiter ?

[zonky]

Hallo Monique,

ich habe über die Preisberechnung nochmal in Ruhe nachgedacht... m.E. kann man keine allumfassende Tabelle aufstellen, sondern muss die Preisberechnung so modular wie nur irgend möglich gestalten.

Der folgende Text ist auch im Google-Doc

~~~~~~~~~~~~~~~~~~~~~~~

Ablauf der Preisberechnung
siehe https://community.contao.org/de/show...l=1#post342668

Im einfachsten Sinne berechnet sich der Gesamtpreis als Summer der Einzelpreise. Hinzu kommen diverse Zuschläge oder Abzüge wie Versandkosten oder Rabatte. Je nach Land sind entsprechende spezifische Regeln für die MwSt zu beachten wie z.B. die MwSt für Verpackung und Versand, die prozentual nach den MwSt-ern der Einzelprodukte aufgeteilt werden muss.

Am flexibelsten wäre die Möglichkeit, sich entsprechende “Preisberechnungs-Ketten” anlegen zu können inkl. “Weichen” für unterschiedliche Kundengruppen (z.B. B2C, B2B, EU-B2B). Ein Beispiel für solche “Ketten” oder Abläufe sind in https://www-304.ibm.com/connections/...3-7344c9a56ae8 zu finden - s.a. https://github.com/isotope/core/issues/877 .

In den Ablauf können auf Wunsch des Händlers oder Vorgabe des WaWi verschiedene Module für Rabatte, Preisstaffelungen oder abhängige Preise einfließen. Diese flexible Umsetzung in einer Programmierung stellt eine besondere Herausforderung dar - mit einer starren Berechnungsvorschrift wird man hier nicht weit kommen.

Folgend einige Stichpunkte und Beispiele:

• wie schon o.g. muss es - für einen deutschen Shop - die Möglichkeit geben alle Preise erst in Netto aufzuführen und zum Schluss die MwSt auszuweisen (B2B) oder alle Preise inkl. MwSt und zum Schluss die enthaltene MwSt auszugeben
• der Produktpreis kann sich an Stückzahl, Volumen oder Masse berechnen
• der Produktpreis kann ein Staffelpreis sein
• die Produktpreise können Staffelpreise/Rabatt aufgrund einer Produktgruppe haben
• der Produktpreis kann sich aus Einzel-Produktelementen zusammen setzen (“Pizza-Kauf”)
• auf einzelne Produkte kann es einen Gutschein geben
• Rabatt wie “kauf 3 bezahl 2”
• Gutscheine auf Produktgruppen
• Versandkosten nach Gewicht/Volumen/Preis, nach Zeit (Express)
• Versandkosten MwSt-Aufteilung prozentual nach Produkttypen
• Gutschein inkl. Versandkosten vs. exklusive Versandkosten
• Gutschein inkl. Zahlungsart-Kosten vs. exklusive Zahlungsart-Kosten
• Ausweisung eines Preises eines Teilelements (Pfand)
• ...

~~~~~~~~~~~~~~~~~~~~~~~

Gruss

[Monique Hahnefeld]

Hi Zonky,

ich habe mich bei IBM angemeldet, sehe allerdings unter dem Link nur ein jpg was zum download steht ???
Danke für die Liste ich werde mich die Tage mal an eine Case MindMap setzen... Wir müssen das irgendwie abstrahiert bekommen mit allen Möglichkeiten dargestellt...

LG

[zonky]

Hi Zonky,

ich habe mich bei IBM angemeldet, sehe allerdings unter dem Link nur ein jpg was zum download steht ???

=> korrekt... downloaden & ansehen ;-)

[Monique Hahnefeld]

Nachdem wir jetzt etwas Klarheit in die Angelegenheit gebracht haben, was man bräuchte bzw. will, habe ich mir mal ein modulares Konzept skizziert. Leider harmonisiert das so garnicht mit der aktuellen Preisfunktion von Isotope. Die derzeitige Preisfunktion ist etwas ungünstig verflechtet und aufgeteilt.

Da ich den Isotope Programmierern den hohen Aufwand nicht aufbürden möchte, die Preisfunktion zu entwirren und zu modularisieren, werde ich das mal vorbereiten. Ich bin zuversichtlich und hoffnungsvoll das es dann übernommen werden kann.

Es bleibt spannend

[Monique Hahnefeld]

Es gibt jetzt Klarheit darüber.
Eine direkte Integration der besagten neu konzipierten Funktion würde Probleme mit der Rückwärtskompatibilität verursachen.
Diese Systemverbesserung wäre ein Ziel für die nächste Major-Release, also Isotope 3.

Natürlich kann aber bis es soweit ist die jetzige Funktion auch individuell durch Programmierung erweitert/angepasst werden. Der Aufwand ist nur größer.

So wie es mir mein Budget und meine Zeit erlaubt werde ich schonmal eine Extension entwickeln, welche die neue Preisfunktion integriert. Die Erweiterung kann dann bei Neuinstallationen verwendet werden (wo es nicht auf die Rückwärtskompatibilität ankommt).

Übrigens könnt Ihr das Projekt Isotope mit einer Circle-Mitgliedschaft unterstützen. Es ist wahnsinnig viel Aufwand diese Erweiterung zu pflegen
https://isotopeecommerce.org/de/circle.html

[Practer]

Hallo, wir nutzen auch Isotope als Shoplösung für unser Projekt. Wir haben schon angefangen dies zu realisieren und kommen gut voran. Grundsätzlich denke ich das man den Einkaufspreis evtl. als Attribut zum Produkt hinzufügen kann? Und dann halt über Auswertung und Satistik das Attribut auslesen um dadurch den Roherlös zu bekommen. In jedem Fall wäre das für mich eine sehr wichtige Funktion. Weiß jemand ob es dafür schon Lösungen gibt?