Edit History

17 hours ago, Whiley said:

20 hours ago, Gurkcity said:

Sehe ich es richtig, dass die Grundpreise gar nicht berücksichtigt werden müssen, da in der product Tabelle nur das unit_price_ratio gespeichert wird?

Hallo Chris,

das sehe ich genauso!

Das sehe ich aber gar nicht so! Denn um überhaupt einen Grundpreis speichern zu können, ist zwingend eine Eingabe im Feld Verkaufspreis brutto des Artikels erforderlich.

So weit, so gut.

Hat man aber Varianten, so muss eine unit_price_ratio erzeugt werden, indem man bei den Varianten eine Erhöhung oder Ermäßigung des Preises um einen bestimmten Betrag erfasst, da man den Preis selber nicht erfassen kann.

Bleibt der Variantenpreis immer gleich, gilt das auch für den Grundpreis. Er wird korrekt ausgegeben.

Falls nicht, hat man ein Problem, denn da das Entwicklerteam eigentlich nie so recht verstanden zu haben scheint, dass es einen Unterschied zwischen Stückpreis und Grundpreis gibt (im Englischen heißt beides unit price), wandert der Grundpreis dann mit. In 1.5 war es noch relativ einfach. Hatte man den den Variantenpreis vermindert oder erhöht, so reichte es aus, im Feld Auswirkung auf den Stückpreis (müsste eigentlich Grundpreis heißen!) umgekehrt den Bruttobetrag als Erhöhung bzw. Verminderung einzugeben, um den Grundpreis konstant ausgeben zu lassen.

Ab 1.6 geht das aber leider nicht mehr. Die Resultate sind zwar numerisch abweichend, aber auf den korrekten Grundpreis kommt man trotzdem nie, außer mit einigen wirklich um die Ecke gedachten Überlegungen. Denn hier wurden in der Berechnung gleich mehrere Fehler eingebaut.  

Also ganz so einfach scheint die Sache doch nicht zu sein.

Das gleiche Fehlverhalten beim Grundpreis findet man übrigens auch bei thirty bees, obwohl sich einer der Entwickler noch Dienstag im dortigen Forum über diesen Topic hier mokiert hat: https://forum.thirtybees.com/topic/4197-mehrwertsteuer-umstellung/?do=findComment&comment=36241

Vielleicht sollte sich @Traumflug mal besser auf die Fehlersuche begeben ... 

On 6/24/2020 at 11:03 PM, Tecc said:

Kann meine eigene Frage beantworten. Falls noch jemand sucht, die Staffelpreise / reduzierten Preise stehen in der Tabelle:

ps_specific_price

 Das SQL Statement sollte dann dem Beispiel der vorangegangenen folgend so aussehen:

UPDATE `ps_specific_price` SET `price`=`price`*1.19/1.16;

Dazu hat @Gurkcity ja schon die richtigen Einwände vorgebracht. Das Ganze würde in einem Fiasko enden, weil hier gar kein Preis gespeichert ist.

16 hours ago, Whiley said:

19 hours ago, Gurkcity said:

Sehe ich es richtig, dass die Grundpreise gar nicht berücksichtigt werden müssen, da in der product Tabelle nur das unit_price_ratio gespeichert wird?

Hallo Chris,

das sehe ich genauso!

Das sehe ich aber gar nicht so! Denn um überhaupt einen Grundpreis speichern zu können, ist zwingend eine Eingabe im Feld Verkaufspreis brutto des Artikels erforderlich.

So weit, so gut.

Hat man aber Varianten, so muss eine unit_price_ratio erzeugt werden, indem man bei den Varianten eine Erhöhung oder Ermäßigung des Preises um einen bestimmten Betrag erfasst, da man den Preis selber nicht erfassen kann.

Bleibt der Variantenpreis immer gleich, gilt das auch für den Grundpreis. Er wird korrekt ausgegeben.

Falls nicht, hat man ein Problem, denn da das Entwicklerteam eigentlich nie so recht verstanden zu haben scheint, dass es einen Unterschied zwischen Stückpreis und Grundpreis gibt (im Englischen heißt beides unit price), wandert der Grundpreis dann mit. In 1.5 war es noch relativ einfach. Hatte man den den Variantenpreis vermindert oder erhöht, so reichte es aus, im Feld Auswirkung auf den Stückpreis (müsste eigentlich Grundpreis heißen!) umgekehrt den Bruttobetrag als Erhöhung bzw. Verminderung einzugeben, um den Grundpreis konstant ausgeben zu lassen.

Ab 1.6 geht das aber leider nicht mehr. Die Resultate sind zwar numerisch abweichend, aber auf den korrekten Grundpreis kommt man trotzdem nie, außer mit einigen wirklich um die Ecke gedachten Überlegungen. Denn hier wurden in der Berechnung gleich mehrere Fehler eingebaut.  

Also ganz so einfach scheint die Sache doch nicht zu sein.

On 6/24/2020 at 11:03 PM, Tecc said:

Kann meine eigene Frage beantworten. Falls noch jemand sucht, die Staffelpreise / reduzierten Preise stehen in der Tabelle:

ps_specific_price

 Das SQL Statement sollte dann dem Beispiel der vorangegangenen folgend so aussehen:

UPDATE `ps_specific_price` SET `price`=`price`*1.19/1.16;

Dazu hat @Gurkcity ja schon die richtigen Einwände vorgebracht. Das Ganze würde in einem Fiasko enden, weil hier gar kein Preis gespeichert ist.

16 hours ago, Whiley said:

19 hours ago, Gurkcity said:

Sehe ich es richtig, dass die Grundpreise gar nicht berücksichtigt werden müssen, da in der product Tabelle nur das unit_price_ratio gespeichert wird?

Hallo Chris,

das sehe ich genauso!

Das sehe ich aber gar nicht so! Denn um überhaupt einen Grundpreis speichern zu können, ist zwingend eine Eingabe im Feld Verkaufspreis brutto des Artikels erforderlich.

So weit, so gut.

Hat man aber Varianten, so muss eine unit_price_ratio erzeugt werden, in ´dem man bei den Varianten eine Erhöhung oder Ermäßigung des Preises um einen bestimmten Betrag erfasst, da man den Preis selber nicht erfassen kann.

Bleibt der Variantenpreis immer gleich, gilt das auch für den Grundpreis. Er wird korrekt ausgegeben.

Falls nicht, hat man ein Problem, denn da das Entwicklerteam eigentlich nie so recht verstanden zu haben scheint, dass es einen Unterschied zwischen Stückpreis und Grundpreis gibt (im Englischen heißt beides unit price), wandert der Grundpreis dann mit. In 1.5 war es noch relativ einfach. Hatte man den den Variantenpreis vermindert oder erhöht, so reichte es aus, im Feld Auswirkung auf den Stückpreis (müsste eigentlich Grundpreis heißen!) umgekehrt den Bruttobetrag als Erhöhung bzw. Verminderung einzugeben, um den Grundpreis konstant ausgeben zu lassen.

Ab 1.6 geht das aber leider nicht mehr. Die Resultate sind zwar numerisch abweichend, aber auf den korrekten Grundpreis kommt man trotzdem nie, außer mit einigen wirklich um die Ecke gedachten Überlegungen. Denn hier wurden in der Berechnung gleich mehrere Fehler eingebaut.  

Also ganz so einfach scheint die Sache doch nicht zu sein.

On 6/24/2020 at 11:03 PM, Tecc said:

Kann meine eigene Frage beantworten. Falls noch jemand sucht, die Staffelpreise / reduzierten Preise stehen in der Tabelle:

ps_specific_price

 Das SQL Statement sollte dann dem Beispiel der vorangegangenen folgend so aussehen:

UPDATE `ps_specific_price` SET `price`=`price`*1.19/1.16;

Dazu hat @Gurkcity ja schon die richtigen Einwände vorgebracht. Das Ganze würde in einem Fiasko enden, weil hier gar kein Preis gespeichert ist.