Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: Falsche Endpreise nach Rabatt - Attribute Price Updater vs Warenkorb

    Timm

    • Fördermitglied
    • Beiträge: 6.345
    Hat er schon. Ticket #1460

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:
    In dem Zusammenhang habe ich jetzt festgestellt, dass die Preise bei der Umrechnung von Nettopreise in Bruttopreise und umgekehrt ebenfalls falsch berechnet werden.

    Dieses stellt zu den bereits benannten Problemen ein weiteres großes Problem dar. Nicht nur, dass man gegenüber Kunden in Erklärungsnot gelangt und von vorneherein nicht vertrauenswürdig wirkt. Dazu muss dann jede Bestellung auch noch mit den Preisen des eigenen Warenwirtschaftssystems manuell abgeglichen werden, bevor man eine Rechnung schreibt bzw. an den Kunden raussenden lässt. Schickt man dazu auch noch eine Rechnung mit falschen Preisen an den Kunden raus, weil man den Fehler übersehen hat, hat dieses neben den vorbenannten Problemen auch rechtliche Konsequenzen, dieses ausschließlich zum Nachteil des Händlers.

    Wie ich festgestellt habe, sind diese eklatanten Fehler in den letzten Jahren hier immer wieder angesprochen und besprochen worden. Beseitigt wurden diese Fehler aber nicht. Da frage ich mich natürlich, warum nicht????

    Tomcraft@, auch ich bin euch dankbar für das, was Ihr leistet und ich kann mir auch denken, dass Du bestimmt arg beschäftigt bist, aber ein wenig mehr, als deine Antwort auf dieses nun wirklich nicht unerhebliche Problem, hätte ich mir schon gewünscht.

    Zu den Fehlern:
    1. Die Umrechnung von Nettopreise auf Bruttopreise und umgekehrt stimmt nicht!
    2. Die Berechnung der Endpreise nach Rabatt stimmen nicht!

    Zu 2. haben wir bereits einen ersten Lösungsansatz von modulfux erhalten. Vielen Dank dafür.

    Änderungen in der includes/classes/shopping_cart.php

    Suche:
    $products_data['final_price'] = $products_data['price'] * $this->contents[$products_id]['qty'];

    Ersetze mit:
    $products_data['final_price'] = round($products_data['price'], 2) * $this->contents[$products_id]['qty'];

    Sobald unser Programmierer aus dem Urlaub zurück ist, werden wir das Ganze noch einmal näher prüfen. Auf den nachfolgenden Screenshots seht ihr die Lösungsansätze mit einer Beschreibung und die Ergebnisse der fehlerhaft berechneten Endpreise.

    Im Demoshop geprüft: Artikel: https://www.dima-tech.de/Diamanttrennscheiben/HKS-Titan-UNI-Turbo::24.html

    Vielleicht hat ja jemand noch eine andere eine Idee dazu?

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:
    Ich gehe derzeit davon aus, dass bei der Umrechnung die Preise der Attribute auf 2 Stellen gerundet werden und das dadurch die Berechnung nicht stimmt.

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:
    und hier noch der Vergleich der Umrechnung von Netto in Brutto und Brutto in Netto nach der neuen Berechnung in der Gegenüberstellung.

    Wenn bei der Berechnung in den Attributen immer mit 4 Nachkommastellen gerechnet wird und nur der finale Stückpreis auf 2 Stellen gerundet wird, gibt es keine Abweichungen bei den Stückpreisen. Jedenfalls nach meinen Berechnungen.

    Kawabiker

    • Fördermitglied
    • Beiträge: 353
    • Geschlecht:
    Um das Ganze nachzustellen habe ich mal in einem Testshop folgenden Artikel angelegt:

    Eingabe: Brutto Admin, 25% Rabatt
    Grundpreis: 27,5961 (Anzeige 27.60)
    Attributaufpreis: 131,1261 (Anzeige 131,13)

    Wenn man das aus Kundensicht im Artikel sieht dann steht dort ohne ein Attribut:

    Unser bisheriger Preis 27,60 EUR
    Jetzt nur 20,70 EUR
    Sie sparen 25% / 6,90 EUR

    Stimmt.

    Nun kommt das Attribut dazu:

    Unser bisheriger Preis 158,73 EUR
    Jetzt nur 119,05 EUR
    Sie sparen: 25.00 % / 39,68 EUR

    Artikelpreis 20,70
    Attributpreis 98,35

    Stimmt.

    Nun lege ich 10 Stck. in den Warenkorb.
    Da lese ich nun
    Einzelpreis: 119,05
    Summe: 1.190,48

    Wenn ich 100 Stck. daraus mache sehe ich einen Gesamtpreis von 11.904,75

    Mit der vorgeschlagenen Änderung

    Code: PHP  [Auswählen]
    $products_data['final_price'] = round($products_data['price'], 2) * $this->contents[$products_id]['qty'];

    würde die Preisanzeige zumindest im Warenkorb für den Kunden wieder stimmen.

     ;-)

    Kawabiker

    • Fördermitglied
    • Beiträge: 353
    • Geschlecht:
    Nachtrag

    hab das nochmal nachgestellt mit einem Nettokunden:

    Die gleiche Zusammenstellung mit der Rundungs-Änderung ergibt im Warenkorb:

    Einzelpreis netto: 100,04
    Summe netto: 10.004,00

    Summe brutto: 11.904,76

    Im Vergleich zum Bruttokunden habe ich somit eine Preisabweichung von 1 ct bei 100 Stck.

    Die Rundungsänderung im Warenkorb zieht sich durch bis zum Checkout...

     :-)

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:
    OK, ich gebe zu, von den Tabellen bekommt man Augenkrebs. Deshalb hier eine andere nachgestellte nachvollziehbare Darstellung des Problems der fehlerhaften Umrechnung der Preise im Shop. Ausführlich, da dieses Problem nicht mit zwei Sätzen behandelt werden kann.

    Der Artikel mit dem Durchmesser 350 mm ist mit Nettopreisen folgendermaßen angelegt:

    Nettopreise im Admin:
    Grundpreis: 23,19 EUR
    Aufpreis: 110,19 EUR
    ergibt einen Netto-Stückpreis = 133,38 EUR

    mit jedem Warenwirtschaftssystem errechnet sich daraus ein folgender Bruttopreis:
    zzgl. Umsatzsteuer: 25,3422 = 25,34 EUR
    ergibt einen Brutto-Stückpreis = 158,72 EUR

    -----

    zu:

    Nun kommt das Attribut dazu:

    Unser bisheriger Preis 158,73 EUR
    Jetzt nur 119,05 EUR
    Sie sparen: 25.00 % / 39,68 EUR

    Artikelpreis 20,70
    Attributpreis 98,35

    Stimmt.

    ------

    Die vorbenannten Bruttopreise scheinen auf den ersten Blick zu stimmen, dieses ist aber nicht der Fall. Der richtige Preis für den Artikel beträgt 158,72 EUR und nicht 158,73 EUR, der Preis nach Rabatt beträgt 109,04 EUR und nicht 109,05 EUR und der richtige Attributpreis bzw. Aufpreis in dem Drop-Down Menü bei der Artikelansicht beträgt 98,34 EUR und nicht 98,35 EUR.

    Wie komme ich nun zu dem richtigen Ergebnis:
    Insoweit bei der Umrechnung im Hintergrund die Zahlenwerte bei den Zwischenwerten auf 2 Stellen gerundet werden, wird die exakte Berechnung verfälscht. Das ist auch logisch nachvollziehbar. Ich habe dieses in mehreren Konstellationen nachgestellt. Um auf das richtige Ergebnis zu kommen, habe ich dann schließlich ohne Auslass sämtliche Parameter mit 4 Nachkommastellen berechnet. Erst, als dieses erfolgt ist und ich den finalen Stückpreis am Ende auf 2 Stellen gerundet habe, stimmte der Preis bei der Umrechnung. Dieses bei der Umrechnung von Netto auf Brutto und umgekehrt von Brutto auf Netto. Dadurch gibt es keine Abweichungen mehr.

    1. Beispiel zur ermittelten Berechnung von Netto auf Brutto für richtige Ergebnisse:

    a)
    Grundpreis-Netto: 23,1900 EUR
    Umsatzsteuer für den Netto-Grundpreis: 4,4061 EUR
    ergibt einen Grundpreis-Brutto: 27,5961 EUR

    b)
    Aufpreis-Netto: 110,1900 EUR
    Umsatzsteuer für den Netto-Aufpreis: 20,9361 EUR
    ergibt einen Brutto-Aufpreis: 131,1261 EUR

    c)
    der umgerechnete Brutto-Grundpreis beträgt 27,5961 EUR
    der umgerechnete Brutto-Aufpreis beträgt 131,1261 EUR
    ergibt einen Brutto-Stückpreis = 158,7222 EUR

    ergibt gerundet auf 2 Nachkommastellen den richtigen finalen Brutto-Stückpreis von 158,72 EUR

    Insoweit durchweg immer mit 4 Nachkommastellen berechnet wird, gibt es keinen Abweichungen mehr bei den Umrechnungen. Von Netto auf Brutto und umgekehrt.

    2. Beispiel für die richtige Berechnung und Anzeige des Aufpreises im Drop-Down Menü bei der Artikelansicht.

    2.1 Preise pro Stück ohne Rabatt
    Der richtige finale Brutto-Stückpreis beträgt 27,60 EUR.
    Der richtige finale Brutto-Stückpreis beträgt 158,72 EUR.
    Der richtige finale Brutto-Aufpreis pro Stück beträgt somit 131,12 EUR.

    2.2 Preise pro Stück abzüglich 25 % Rabatt
    a) Brutto-Stückpreis 27,60 EUR - 25% Rabatt = 6,90 EUR
    ergibt einen finalen Brutto-Stückpreis 20,70 EUR

    b) Artikel aus dem Drop-Down Menü
    Brutto-Stückpreis 158,72 EUR - 25% Rabatt = 39,68 EUR
    ergibt einen finalen Brutto-Stückpreis 119,04 EUR

    Der richtige Brutto-Aufpreis pro Stück in dem Drop-Down Menü beträgt somit 98,34 EUR.

    Das heranziehen der Aufpreise in das Drop-Down Menü muss am Ende der Kette der Berechnungen erfolgen und nicht aus den zwischendrin ermittelten Preisberechnungen bei den Attributen, dann stimmt auch dort das Ergebnis.

    Am Rande erwähnt, haben wir die Anzeige der Aufpreise in dem Drop-Down Menü deaktiviert, weil das unser Meinung nach die Kunden nur verwirrt und überfordert. Kunden wollen nicht umständlich rechnen.

    - Mit der vorgeschlagenen Änderung für die richtige Berechnung der Gesamtpreise im Warenkorb scheint das Thema gelöst, wir haben das nachgestellt. Was dieses anbelangt, stimmen sämtliche Preisangaben im Checkout.

    - Die richtige Umrechnung der Preise in den Attributen steht noch aus und müsste im Zusammenhang der vorbenannten Berechnung nach einem Lösungsansatz noch final zusammen geprüft werden.

    Kann uns jemand sagen, wo die Einstellungen im Shopsystem vorgenommen werden müssen? Vielleicht mit mit einem Lösungsansatz? Bitte helft uns damit, alleine schaffen wir das nicht.

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:

    Zu den Fehlern:
    1. Die Umrechnung von Nettopreise auf Bruttopreise und umgekehrt stimmt nicht!
    2. Die Berechnung der Endpreise nach Rabatt stimmen nicht!

    Zu 2. haben wir bereits einen ersten Lösungsansatz von modulfux erhalten. Vielen Dank dafür.

    Änderungen in der includes/classes/shopping_cart.php

    Suche:
    $products_data['final_price'] = $products_data['price'] * $this->contents[$products_id]['qty'];

    Ersetze mit:
    $products_data['final_price'] = round($products_data['price'], 2) * $this->contents[$products_id]['qty'];

    Nachträglich haben wir jetzt aber festgestellt, dass mit der alleinigen Änderung der Rundung der finalen Stückpreise auf 2 Nachkommastellen am Ende der Berechnung die Preise doch nicht stimmen. Das Problem der fehlerhaften Programmierung der Berechnungen liegt viel tiefer.

    Der Artikel mit dem Durchmesser 350 mm ist mit Nettopreisen folgendermaßen angelegt:

    Nettopreise im Admin:
    Grundpreis: 23,19 EUR
    Aufpreis: 110,19 EUR
    ergibt einen Netto-Stückpreis = 133,38 EUR

    mit jedem Warenwirtschaftssystem errechnet sich daraus ein folgender Bruttopreis:
    zzgl. Umsatzsteuer: 25,3422 = 25,34 EUR
    ergibt einen Brutto-Stückpreis = 158,72 EUR

    -----

    zu:

    Nun kommt das Attribut dazu:

    Unser bisheriger Preis 158,73 EUR
    Jetzt nur 119,05 EUR
    Sie sparen: 25.00 % / 39,68 EUR

    Artikelpreis 20,70
    Attributpreis 98,35

    Stimmt.

    ------

    Die vorbenannten Bruttopreise scheinen auf den ersten Blick zu stimmen, dieses ist aber nicht der Fall. Der richtige Preis für den Artikel beträgt 158,72 EUR und nicht 158,73 EUR, der Preis nach Rabatt beträgt 109,04 EUR und nicht 109,05 EUR und der richtige Attributpreis bzw. Aufpreis in dem Drop-Down Menü bei der Artikelansicht beträgt 98,34 EUR und nicht 98,35 EUR.

    Wie komme ich nun zu dem richtigen Ergebnis:
    Insoweit bei der Umrechnung im Hintergrund die Zahlenwerte bei den Zwischenwerten auf 2 Stellen gerundet werden, wird die exakte Berechnung verfälscht. Das ist auch logisch nachvollziehbar. Ich habe dieses in mehreren Konstellationen nachgestellt. Um auf das richtige Ergebnis zu kommen, habe ich dann schließlich ohne Auslass sämtliche Parameter mit 4 Nachkommastellen berechnet. Erst, als dieses erfolgt ist und ich den finalen Stückpreis am Ende auf 2 Stellen gerundet habe, stimmte der Preis bei der Umrechnung. Dieses bei der Umrechnung von Netto auf Brutto und umgekehrt von Brutto auf Netto. Dadurch gibt es keine Abweichungen mehr.

    1. Beispiel zur ermittelten Berechnung von Netto auf Brutto für richtige Ergebnisse:

    a)
    Grundpreis-Netto: 23,1900 EUR
    Umsatzsteuer für den Netto-Grundpreis: 4,4061 EUR
    ergibt einen Grundpreis-Brutto: 27,5961 EUR

    b)
    Aufpreis-Netto: 110,1900 EUR
    Umsatzsteuer für den Netto-Aufpreis: 20,9361 EUR
    ergibt einen Brutto-Aufpreis: 131,1261 EUR

    c)
    der umgerechnete Brutto-Grundpreis beträgt 27,5961 EUR
    der umgerechnete Brutto-Aufpreis beträgt 131,1261 EUR
    ergibt einen Brutto-Stückpreis = 158,7222 EUR

    ergibt gerundet auf 2 Nachkommastellen den richtigen finalen Brutto-Stückpreis von 158,72 EUR

    Insoweit durchweg immer mit 4 Nachkommastellen berechnet wird, gibt es keinen Abweichungen mehr bei den Umrechnungen. Von Netto auf Brutto und umgekehrt.

    Vermutung zu der falschen Berechnung:

    Stückpreis:

    a)
    Grundpreis-Netto: 23,1900 EUR
    Umsatzsteuer für den Netto-Grundpreis: 4,4061 EUR
    ergibt einen Grundpreis-Brutto: 27,5961 EUR

    b)
    Aufpreis-Netto: 110,1900 EUR
    Umsatzsteuer für den Netto-Aufpreis: 20,9361 EUR
    ergibt einen Brutto-Aufpreis: 131,1261 EUR (Attributpreis)
    ergibt einen falschen Brutto-Aufpreis: 131,13 EUR (Attributpreis, gerundet auf 2 Stellen)

    c)
    der umgerechnete Brutto-Grundpreis beträgt 27,60 EUR
    der umgerechnete Brutto-Aufpreis beträgt 131,13 EUR (Attributpreis, gerundet auf 2 Stellen)
    ergibt einen falschen Brutto-Stückpreis = 158,73 EUR

    Der Attributpreis mit 25% Rabatt beträgt 98,34 EUR und nicht 98,35 EUR. Das System rechnet vermutlich folgendermaßen:

    Brutto-Aufpreis: 131,13 EUR (Attributpreis, gerundet auf 2 Stellen)
    abzüglich 25% Rabatt: 32,7825 EUR
    ergibt einen Brutto-Aufpreis: 98,3475 EUR (Attributpreis)
    ergibt einen falschen Brutto-Aufpreis: 98,35 EUR (Attributpreis, gerundet auf 2 Stellen)

    Insoweit Werte (einschließlich der Attributpreise) zwischendurch auf 2 Stellen gerundet werden, kann eine Be- und Umrechnung von Preisen logischer Weise nicht funktionieren. Das ist mathematisch auch nachvollziehbar. Eine Be- und Umrechnung erfolgt erst dann richtig, wenn alle Parameter durchweg auf mindestens 4 Nachkommastellen gerundet werden und erst am Ende final auf 2 Nachkommastellen gerundet wird.

    - die Priorität für die Beseitigung dieser eklatanten und fatalen Fehler im Shopsystem, ist gelinde ausdrückt, mehr als hoch.
    - die Umrechnung von Nettopreisen auf Bruttopreisen und umgekehrt stimmen grundsätzlich nicht!!!
    - die Berechnung der Endpreise nach Rabatt stimmen grundsätzlich nicht!!!

    Von den Entwicklern ist trotz angelegten Tickets und nachträglichen weiteren Hinweis bis jetzt keine Mitteilung erfolgt, ob diese Fehler nun korrigiert werden oder nicht. Dieses auch hinsichtlich einer Prüfung möglicher weiterer fehlerhaften Berechnungen in dem Zusammenhang mit den anderen Funktionen des Shopsystems, den Preisberechnungen des Shopsystems (z. B. Staffelspreise) und Modulen (z. B. Attribute-Price-Updater).

    Eine Antwort ist wünschenswert und wird erwartet. Danke.

    Ceciro

    • Fördermitglied
    • Beiträge: 449
    • Geschlecht:
    Was passiert denn, wenn im Backend unter Adminbereich Optionen/Brutto/Netto Dezimalstellen "2" eingetragen wird?

    Gruß Cicero

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:
    4 Dezimalstellen sind für eine exakte Be- und Umrechnung von netto in brutto und umgekehrt pflicht. Alles andere führt zu falschen Ergebnissen. Ist mit einem einfachen handelsüblichen Taschenrechner nachvollziehbar.

    DieterW

    • Mitglied
    • Beiträge: 140
    Vollkommen richtig, es wird an den falschen Stellen gerundet ....

    Meiner Meinung nach darf der Shop NUR DANN runden, wenn ein Preis angezeigt wird. Alles andere sollte mindestens 8 Stellen hinter dem Komma haben, damit auch der den Preis richtig angezeigt bekommt, der vier Stellen hinter dem Komma im Frontend anzeigen lässt.

    noRiddle (revilonetz)

    • Experte
    • Beiträge: 13.750
    • Geschlecht:
    ... der vier Stellen hinter dem Komma im Frontend anzeigen lässt.

    Also die Kirche sollte hier mal im Dorf bleiben. Solange 100ct = 1 EUR (oder 100 "andere_währung_klein" = 1 "andere_währung_groß") soll eine Anzeige auf 4 Stellen hinter dem Komma im Frontend zu was genau dienen ?

    Gruß,
    noRiddle

    *NACHTRAG*
    Ich muß mich in letzter Zeit immer häufiger fragen warum bei jeder grundsätzlich berechtigten Sache immer Argumentatoren dazukommen müssen die alles zerwürfeln und absurd machen wollen...

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:
    Dem kann ich nur beipflichten. 4 Stellen hinter dem Komma im Frontend sind Unsinn.

    Leider habe ich von den Entwicklern keine Antwort darauf erhalten, wann und ob die Fehler überhaupt korrigiert werden. Dieses trotz nochmaliger Nachfrage. In dem Forum habe ich zu dem Thema, wenn auch nicht so detailliert dargelegt, ähnliche Beiträge aus der Vergangenheit gesehen und festgestellt, dass schon damals diesbezüglich nichts unternommen worden ist.

    Es ist für mich in keiner Weise nachvollziehbar, dass auch nach mehreren Wochen einfach keine Rückmeldung kommt und man mit der Angelegenheit im dunklen gelassen wird. Eine richtige Berechnung von Preisen ist doch wohl vor allen anderen Dingen eine Mindestvoraussetzung für eine Shopsoftware.

    Hiermit bitte ich die Entwickler nun nochmals höflich, zum dritten mal, um Mitteilung, ob nun eine Prüfung und Beseitigung der fehlerhaften Preisberechnungen erfolgt oder nicht, bzw. wann mit einer Korrektur zu rechnen ist, damit man sich darauf einrichten kann!!! So kann es jedenfalls unter keinen Umständen bleiben.

    Insoweit diesbezüglich keine Interesse, keine Zeit etc. an der Behebung der Fehler besteht, bitte ich auch dazu um Mitteilung.

    Ich werde dann meinen Programmierer mit der Angelegenheit beauftragen um nicht dauerhaft in Erklärungsnot und den darüber hinaus möglichen rechtlichen Konsequenzen wegen der falschen Preisangaben gegenüber meinen Kunden stehen zu müssen.

    Als ob das so schwer ist, diesbezüglich einen Zweizeiler hier reinzusetzen. - völliges Unverständnis -

    Gruß
    Norbert

    Timm

    • Fördermitglied
    • Beiträge: 6.345
    Ich kann deinen Unmut nachvollziehen und finde die Kommunikation durch das Team in letzter Zeit oftmals auch nicht ausreichend. Auch das das Forum nicht mehr wirklich betreut wird. Das führt zu solchen Auswüchsen wie "shorty", was erst Wochen später festgestellt wird, oder der mehrfach gemeldete Fehler zum aktuellen responsive modified template, wo die Datei Smarty.class.php veraltet war und man dadurch nicht installieren konnte, wenn man den Fehler nicht selbst bemerkt hat.

    Und Preise sollten immer stimmen.

    Aber!

    Das Problem tritt scheinbar "nur" mit Attributen, Rabatt und einer Vervielfachung der Stückzahl auf. Insofern wird es nicht die Masse an Shopbesitzern betreffen.

    Und man sollte bedenken, dass jeder der hier anwesenden Programmierer und vor allem die Teammitglieder genug zu tun gehabt werden in der letzten Zeit auf Grund der DSGVO. Und Geld verdienen muss jeder hier.

    Wenn man aber sieht, was in den letzten zwei Wochen im Bugtracker los ist und gefixed wurde, dann ist das schon enorm und hab ich so noch nicht gesehen und der Fokus rückt wieder von den Bezahlkunden hin zur Shopsoftware.

    Dazu hat Tomcraft seinen ersten Kommentar in Ticket 1460 vor 4 Tagen revidiert hin zu "Kann das nachvollziehen". Zumal ist die Priorität auf hoch. Ich würde also davon ausgehen, dass das Ticket demnächst gelöst wird.

    Und am Ende sollten wir immer bedenken, dass es sich um eine kostenlose Software handelt, die keinen Anspruch auf gänzliche Funktion gibt und vor allem keinen Anspruch auf Bearbeitung selbstgestellter Tickets beinhaltet. Theoretisch könntest du das auch beim Team in Auftrag geben, wenn es dir so wichtig ist und du eh jemanden damit beauftragen würdest und die Lösung dann allen zu Gute kommt.

    Gruß Timm

    norbert72

    • Neu im Forum
    • Beiträge: 34
    • Geschlecht:
    Und Preise sollten immer stimmen.

    Aber!

    Das Problem tritt scheinbar "nur" mit Attributen, Rabatt und einer Vervielfachung der Stückzahl auf. Insofern wird es nicht die Masse an Shopbesitzern betreffen.

    Das ist nicht richtig und bereits ausführlich dargelegt. Bitte den ganzen Beitrag richtig lesen! Das Problem betrifft ausnahmlos alle Nutzer der Shopsoftware.

    1. Die Berechnungen von Netto auf Brutto und umgekehrt stimmen auch ohne Attribute grundsätzlich nicht.

    2. Dieses betrifft in dem Zusammenhang alle weiteren Berechnungen bei den Attributen, den Rabatten und dem finalen Gesamtpreis.

    Ich kann deinen Unmut nachvollziehen und finde die Kommunikation durch das Team in letzter Zeit oftmals auch nicht ausreichend. Auch das das Forum nicht mehr wirklich betreut wird. Das führt zu solchen Auswüchsen wie "shorty", was erst Wochen später festgestellt wird, oder der mehrfach gemeldete Fehler zum aktuellen responsive modified template, wo die Datei Smarty.class.php veraltet war und man dadurch nicht installieren konnte, wenn man den Fehler nicht selbst bemerkt hat.

    In meinem Unternehmen, das hinsichtlich der Produkte und Abläufe etc. ebenfalls mit einen hohen Anzahl von Fragestellungen betroffen ist, gibt es das Problem nicht. Dieses lies sich mit einigen Maßnahmen im Interesse der Nutzer und zur Entlastung der Entwickler beseitigen.

    Ich kann die Entwickler in der Hinsicht verstehen, dass sie nicht auf alles reagieren, weil oftmals unnötige Fragen gestellt werden, die beispielsweise mit dem Handbuch schon beantwortet sind oder ähnliches. Die daraus offensichtlich entstandene Resignation und Ignoranz führt aber nicht zu einem für alle Beteiligten positiven Ergebnis, sondern schafft nur Unfrieden auf beiden Seiten.

    Falls das gewollt ist und eine Bereitschaft zur Vereinfachung und Verbesserung der Kommunikation besteht, hätte ich da ein paar Vorschläge. Dafür sind allerdings einige Maßnahmen notwendig.

    Und am Ende sollten wir immer bedenken, dass es sich um eine kostenlose Software handelt, die keinen Anspruch auf gänzliche Funktion gibt und vor allem keinen Anspruch auf Bearbeitung selbstgestellter Tickets beinhaltet.

    Es ist für mich schon fast müßig darauf einzugehen. Tue dieses nur, um das hier richtig zu stellen:

    Das die Software kostenlos ist, braucht man hier nicht zu thematisieren. Der Hinweis ist überflüssig. Es gibt mittlerweile genügend kostenlose Software auf den Markt, die man sich kostenpflichtig erweitern oder anpassen lassen kann. Bei Modified ist das auch nicht anders, wenn man nicht gerade Programierer ist, und solches in Anspruch nehmen möchte.

    Halbherzigkeiten sind weder im Privatleben noch im Geschäftsleben gefragt. Mit allem was man tut, entfaltet man eine Auswirkung die sich positiv oder negativ auswirken kann. Insoweit sollte man sich gut überlegen was man tut. Wenn man der Allgemeinheit etwas offeriert, steht man auch in der Pflicht und Verantwortung gegenüber der Allgemeinheit. Insbesondere dann, wenn man etwas der Allgemeinheit offeriert, wo die Existenz des einen oder anderen dran hängt. Das ist nun mal so und auch dazu gibt es keine zwei Meinungen.

    Jeder der eine angepriesene Shopsoftware nutzt, hat nach dem vorbenannten selbstverständlich einen Anspruch darauf und sollte sich im Mindesten darauf verlassen können, dass das grundlegendste der als funktionsfähig angepriesenen Software, hier die Berechnungen der Preise, auch stimmen. Punkt.

    Insoweit eine Software mit einem bekannten Fehler dieser Art, welcher nun gravierend ist, weiterhin als funktionsfähige Software der Allgemeinheit angepriesen wird, richtet man für die Allgemeinheit, hier die Nutzer der Software, unter Umständen einen nicht abzusehenden Schaden an. Einem Nutzer ist es auch in keiner Weise zuzumuten, eine als funktionstüchtig angepriesene Software zuvor umfassend auf fehlerhafte Programierungen zu prüfen.

    Preist man etwas an, welches nicht der Wirklichkeit entspricht, steht man in der Pflicht ob man will oder nicht. Kurz um: Man kann eben nicht tun und lassen was man will, auch dann nicht, wenn man etwas kostenlos anbietet. Ein lapidarer untergeordneter kleiner Hinweis, das man keinen Anspruch auf Vollständigkeit und gänzliche Funktion erhebt genügt hierbei eben nicht. Dieses schon gar nicht, wenn mehr als überdeutlich herausragend gegenüber dem kleinen untergeordneten Hinweis nach wie vor der Eindruck erweckt wird, dass es sich um eine funktionsfähige Software handelt.

    Der Hinweis darauf, das Team mit der Behebung der gesamten fehlerhaften Berechnungen innerhalb der Shopsoftware, einschließlich der damit im Weiteren möglichen in dem Zusammenhang betroffenen Module zu beauftragen und der Allgemeinheit damit etwas gutes zu tun, ist darüber hinaus schon ziemlich vermessen.

    So langsam frage ich mich, wo ich hier gelandet bin!! no Riddle hat vollkommen Recht, das hier vieles von machen Kommentatoren in Absurde geführt wird.

    Was ich hier erwarte, ist eine konkrete Antwort auf konkrete Frage. Mehr wurde in dem Beitrag von mir nicht gestellt. Mein Unmut über die mangelnde Reaktion habe ich geäußert, damit hat es sich dann aber auch.

    Weiteren Kommentar zu dem vorbenannten, außer zu dem eigentlichem Thema, wird es von mir nicht geben.

    Schönes Wochenende

    Gruß
    Norbert
    2 Antworten
    3322 Aufrufe
    16. November 2012, 12:26:25 von jannemann
    296 Antworten
    131046 Aufrufe
    19. August 2021, 19:45:04 von zack
    1 Antworten
    2683 Aufrufe
    16. Januar 2014, 17:51:09 von web28