Fehlende Konfigurationsmöglichkeiten für Preis-Eingabe und/oder Ausgabe
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!!!
Danke schonmal aber da gibts bestimmt noch mehr :)
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...
Ein bisschen als ein Wort sollte es schon sein ;)
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 ...
Es geht hier nur um das Preissystem
Bitte beim Thema bleiben. Danke!! :D
Diskussionsgrundlage von 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?? :eek:
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 :D
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 :) !!!!
... Ein Problem nach dem Anderen :)
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...
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Zitat von
Monique Hahnefeld
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.
Anhang 14584
Vielleicht dann in Isotope 3
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
Zum Einkaufspreis als Zusatzfunktion
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?
