MwSt / USt / Steuern sind falsch im Warenkorb

[pattys]

Hallo,

 

ich bin gerade dabei mir den Prestashop (Version 1.5.4.1) aufzubauen.

 

Nachdem ich nun Kategorien und Artikel importiert und soweit alles eingestellt habe, teste ich nun manche Sachen durch.

 

Jetzt ist mir ein gravierender Fehler aufgefallen bei der Berechnung der enthaltenden USt im Warenkorb.

 

(Siehe auch Screenshot)

 

Kurz erklärt:

 

Artikel, Stabilo point 88, hat einen Einzelpreis netto von 0,35€ was im Shop einen Einzelpreis brutto von 0,42€ ergibt. Die Versandkosten betragen netto 5€, was brutto 5,95€ sind.

 

Im Beispiel wurden 100 Stifte in den Warenkorb gelegt.

 

Der Endpreis ist demnach mit 47,95€ korrekt.

ABER der im Warenkorb genannte Nettopreis, sowie die genannten enthaltenen USt nicht korrekt.

 

Bei einem Endpreis von 47,95€, müsste der Gesamtnettobetrag 40,29€ betragen und die USt dann sollten dann einen Betrag von 7,66€ ergeben.

 

Der Gesamtnettobetrag wird im Warenkorb aber von den tatsächlichen Nettopreisen berechnet, in dem Fall 0,35€ x 100 = 35€ zzgl. 5€ netto Versandkosten = die im Warenkorb angezeigten 40€.

 

Allerdings betragen aber 40€ zzgl. 19% USt (7,60€) = 47,60€ und nicht 47,95€

 

Demnach wird aktuell im Warenkorb offensichtlich von dem Gesamtendbetrag 47,95€ einfach die tatsächlichen 40€ netto abgezogen und die Differenzsumme von 7,95€ einfach als enthaltene USt ausgegeben.

 

Das ist nicht korrekt. Weiß da jemand eine Lösung?

 

Ich kann mir garnicht vorstellen, dass dies noch nie jemandem aufgefallen sein soll.

 

Ich freue mich über antworten, denn ich möchte nicht wegen so einem blöden Fehler jetzt auf den Prestashop verzichten müssen. Aber so wie die Berechnung dort jetzt läuft, geht es garnicht.

Vielen Dank.

 

Gruß pattys

[eleazar]

Hallo pattys,

 

ganz einfach. Der Fehler ist deshalb wohl niemandem aufgefallen, weil er nur durch deine eigenen Rundungsfehler zustandegekommen ist. Würdest du nämlich, wie das jede Tabellenkalkulation macht, mit mehr als zwei Stellen hinter dem Komma rechen, dann wäre es dir vermutlich auch aufgefallen.

 

Denn nach deiner Rückrechnung sind nicht nur 47,95 / 119 * 100 = 40,29, auch dein eigener Produktpreis würde nicht ganz stimmen, denn 42,00 / 119 * 100 = 35,29 und nicht glatt 35,- !

Das sind pro Artikel natürlich nur 0,0035 € Differenz an MwSt., mal 100 allerdings exakt die vermissten 0,35 €.

 

PrestaShop rechnet richtig, während du mit geringfügig aufgerundeten Bruttopreisen rechnest. Dagegen ist ja gar nichts einzuwenden, aber mit deiner obigen Rechnung zäumst du leider das Pferd von hinten auf.

 

Buchhalterisch ist PrestaShop auf der sicheren Seite, du ... /* hüstel */ ... eher nicht.

 

Viele Grüße

eleazar

[pattys]

Hallo eleazar,

 

erstmal vielen Dank für die Antwort.

 

Der Haken ist ja, dass nicht ICH irgendwas runde und damit rechne, sondern der Shop.

 

Ich hoffe Du hast Dir meinen Screenshot angeschaut, da ist es eigentlich eindeutig zu sehen, dass die Zahlen nicht passen.

 

Ich würde gerne mit mehr als 2 Stellen hinter dem Komma rechnen, wie bei einer Tabellenkalkulation, aber der Shop macht es nicht. Kann ich denn das irgendwo im BO einstellen, dass er mit mehr Stellen hinter dem Komma rechnet?

 

Entweder müsste er nur von dem gerundeten Bruttopreis ausgehen und dann später aus dem Endpreis die USt ziehen und den entsprechend richtigen USt-Betrag nennen, in dem Fall 0,42€ * 100 = 42€ (Artikelpreis) + 5,95€ Versandkosten = Endpreis 47,95€ (wären dann 40,29€ netto + 7,66 USt).

 

ODER

 

Es darf erstmal nicht gerundet werden.

 

Wenn ich von dem Nettopreis hochrechne wäre der Endpreis ja nicht 47,95€, sondern eigentlich 100x 0,35€ = 35€ (Artikelpreis netto) + 5€ Versandkosten (netto) = 40€ , die der Shop schon korrekt anzeigt wie im Screenshot, aber die dort angegebenen UST i. H. v. 7,95€ stimmen dann im Warenkorb nicht, es müssten dann eigentlich 7,60€ USt sein und der Endpreis demnach dann 47,60€.

 

Der Shop errechnet aber den Endpreis aufgrund des gerundeteten Bruttopreises 47,95€, abzüglich des tatsächlich hinterlegten Nettopreises 40€ und hat dann als Ergebnis eine USt von 7,95€, welche eben nicht korrekt ist.

 

Fakt ist, dass so wie es aktuell im Warenkorb (Screenshot, siehe 1. Posting) steht, ist es nicht richtig.

 

Im Prinzip spielt es auch keine große Rolle, ob der Enpreis nun 47,95€ oder 47,60€ beträgt, aber die vorherigen Zahlen, die zu dem Betrag geführt haben, sollten schon stimmig sein.

 

Ich habe gerade auch mal ausprobiert den Nettopreis mit mehr als 2 Stellen hinterm Komma einzugeben, (was ich allerdings nicht gerne machen wollen würde), aber nach dem Speichern wird die Zahl dann ohnehin wieder auf 2 Stellen nach dem Komma gekürzt.

 

Wie bekomme ich es also hin, dass im Warenkorb alles stimmig ist zahlenmäßig?

 

Schönen Gruß

pattys

[eleazar]

Hi pattys,

 

da irrst du dich! Du kannst bei jedem Produktpreis mehr als 2 Stellen hinter dem Komma angeben.

Ich vermute mal, du hast den Nettopreis mit 0.35 € erfasst. Dann zeigt dir der Shop 0.42 € als VK an. Intern verhält es sich aber anders, weil immer mit mehr als zwei Stellen gerechnet wird.

 

Es ist übrigens gar nicht erforderlich, den Nettopreis mit mehreren Stellen hinter dem Komma zu erfassen. Das nimmt dir PrestaShop sowieso ab.

Versuch es deshalb mal alternativ mit der Eingabe des Bruttopreises. Die Auswirkungen auf den Nettopreis siehst du noch bei der Eingabe. Bei Eingabe von 0.42 € brutto wird dir nämlich als Nettopreis korrekt 0.352941 € angezeigt.

 

Und das muss auch so sein, sonst würdest du ja lauter Rundungsfehler erzeugen.

 

Viele Grüße

eleazar

[pattys]

Hallo eleazar,

 

ja, das ist korrekt, ich habe alle meine Preise als Nettopreise importiert, da ja im BO auch zur Info steht, dass eben entweder der Verkaufspreis mit oder ohne MwSt angegeben werden kann. Da ich normal mit Nettopreisen arbeite, hab ich die Nettopreise gewählt.

 

Wenn mein Shop intern mit mehr als 2 Kommastellen rechnen würde, dann wäre ja das Ergebnis im Warenkorb korrekt, aber wie man ja auf dem Screenshot erkennen kann, ist es das leider nicht.

 

Ich bin jetzt aber mal dem gefolgt, was Du geschrieben hast und habe einfach die 0,42€ beim Bruttopreis eingetragen und tatsache steht dann im Nettofeld automatisch die 0,352941€. Sobald ich dann auf "Speichern" klicke, wird der Nettopreis automatisch wieder auf 2 Kommastellen gekürzt, also auf 0,35€. Dennoch habe ich danach erneut den Artikel 100x in den Warenkorb gelegt, um zu sehen, ob nun alles korrekt angezeigt wird, wird es aber nochimmer nicht.

 

Die Beträge haben sich im Warenkorb kein Stück geändert, dort wird nochimmer 40€ Gesamtnetto und 7,95€ (falsche) GesamtUSt angezeigt :-(.

 

Wie im 1. Posting erwähnt, ich benutze die Version 1.5.4.1, benutze das "default theme", den "One-Page-Checkout" und habe auch eingestellt, dass Gastbestellungen möglich sind. Den B2B-Modus habe ich nicht aktiviert (weiß auch nicht was sich nach dessen Aktivierung ändern sollte).

 

Ich weiß ja nicht ob Du den Shop selbst im Einsatz hast und ob es die gleiche Version ist, nur irgendwo muss der Hund doch begraben sein, dass es bei mir nicht korrekt angezeigt wird.

 

Auch habe ich die im Forum genannten Änderungen vorgenommen, bzgl. einiger deutschen rechtlichen Anpassungen.

Wie eben z. B. für die Buttonlösung das "1ButtonFix_PS1_5_4_v03a", sowie auch dies "versand_neben_kaufen_-fancybox_-PS-15_ver01.zip".

 

Könnte darin der Übeltäter versteckt sein?

 

Es ist echt zum Verzweifeln :-(, jetzt kam ich schon soweit, habe den Import der Kategorien und der knapp 1800 Artikel hinbekommen und dann stoße ich zufällig auf diesen Fehler. Eigentlich wollte ich nur austesten ob die Mengenrabatte, die ich bei manchen Artikeln einsetzen wollte, korrekt berechnet werden und wie das aussieht. Inzwischen hatte ich das mit den Mengenrabatten wieder rausgenommen, wegen der Preisdiskrepanzen und naja, stellte dann dieses Problem fest.

 

Gruß nach Marl (wie ich gesehen habe) aus Recklinghausen :-)

pattys

[eleazar]

Hi pattys,

 

das was du siehst, und das, was intern abläuft, sind wirklich zweierlei. Du legst einen falschen Nettopreis zugrunde, weil du die Rundungsfehler ignorierst. Bei 0,42 ist dein Nettopreis nicht 0,35, sondern vielmehr 0,352941176470588. Dein Shop rechnet richtig - probier es einfach mal mit Excel aus und du wirst auf das gleiche Ergebnis komme.

 

Es ist ein simpler Denkfehler - und der spielt sich wirklich in nur deinem Kopf ab, glaub mir.

 

Gruß nach Recklinghausen

eleazar

[Lockesoft]

ömm *räusper*

 

andersrum rechnet der Shop auch nicht besser. der Fehler beginnt wie pattys das schon richtig beschreiben hat beim ersten errechneten Bruttopreis. Wenn man, das habe ich eben noch ausprobiert, wie beschrieben 0,35 bei Netto angibt, ist Brutto nicht 0,42 sondern 0,4165. Angezeigt und genommen wird dann aber doch die 0,42.....

Mit dem Wert wird dann munter weiter gerechnet und bei 100 Stück macht der Fehler schon 0,35 aus.

 

Es scheint, als würde am Ende vom vorher errechneten Bruttopreis einfach der eingegebene Netto abgezogen und das Ergebnis dann zur Steuersumme erklärt.

 

Ich seh das durchaus als einen Bug an und nicht als Denkfehler. :-)

 

LG Klaus / Lockesoft

Edited July 1, 2013 by Lockesoft (see edit history)

[pattys]

Hi eleazar,

sorry, ich habe das Gefühl, dass wir beide zwei komplett andere Sprachen sprechen, naja wohl eher schreiben *g.

Es geht nicht um ein Rundungsproblem an sich, der ENDpreis im Warenkorb ist ja im Prinzip korrekt und in Ordnung, aber der Gesamtpreis OHNE MwSt und die genannten MwSt sind nicht korrekt im Warenkorb, trotz der Eingabe als Bruttopreis von 0,42€ im BO.

Ich habe die Zahlen in Excel eingegeben, womit ich auch die Rechnung später erstellen würde für eine solche Bestellung.

Hier mal ein Screenshot bei Eingabe in Excel und nocheinmal ein Screenshot aus meinem Warenkorb, beides im Vergleich.
Das in Excel ist korrekt, das im Warenkorb nicht.

 

Also als Käufer in einem Onlineshop würde ich nicht schlecht gucken, wenn mir der Warenkorb verklickern will, dass die enthaltene MwSt von 19%, bei einem Betrag von 47,95€, 7,95€ betragen soll.

Schönen Gruß und gute Nacht
pattys

Edited July 28, 2015 by pattys (see edit history)

[Luca01]

Hallo,

ich habe das auch mal mit gleichen Bemessungsgrundlagen bei unterschiedlichen Stückzahlen vom System durchrechnen lassen und erhalte verschiedene Mehrwertsteuerbeträge. Darum halte ich die Berechnungsart auch für einen Bug. Leider kann ich nichts produktives dazu beitragen. Das Thema ist eben sehr komplex. Pattys rechnet nicht mit einem Betrag von 0,352941176470588 sondern mit 0,35. Da gibt es also kein Rundungsproblem. Das System rundet. Wie schreibt man so eine komplexe Materie nur qualifiziert und verständlich in den Bugtracker?

Viele Grüße

ps: Im Übrigen rechnet schon die 1.4 Version falsch.

Edited July 2, 2013 by Luca01 (see edit history)

[eleazar]

Danke für eure Hartnäckigkeit und Geduld mit einem Ignoramus wie mir.

 

Den Denkfehler hatte in diesem Fall wirklich ich begangen.

Denn ich habe das Ganze zwar ausprobiert, auch mit wesentlich teureren Produkten, die aber immer nur einzeln geordert wurden. In diesem Fall stimmt die MwSt. auf den Cent genau.

 

Der Fehler tritt nämlich nur unter einer Bedingung auf: Es muss einen Multiplikator geben. Nur wenn ein Artikel mehrfach geordert wird, rechnet PrestaShop falsch. Das liegt an der Berechnungsweise der cart.php. Dort heißt es in Zeile 581 (Version 1.4.9: Zeile 417) bei der Steuerberechnung:

 

$row['total_wt'] = Tools::ps_round($row['price'] * (float)$row['cart_quantity'] * (1 + (float)$tax_rate / 100), 2);

 

Also: Artikel * Anzahl * Steuersatz

 

Es müsste aber heißen: Artikel * Steuersatz, aufgerundet auf 2 Stellen, und dann erst * Anzahl!

 

 

Mit dieser Änderung in der cart.php sollte die Rechnung korrekt ausgegeben werden.

 

$row['total_wt'] = Tools::ps_round($row['price'] * (1 + (float)$tax_rate / 100), 2) * (float)$row['cart_quantity'];

 

-----------------------------------------------------------------------------------------------------------------------------------

 

Die MwSt-Berechnung für den Warenkorb müsste ab Zeile 1406 (Version 1.4.9: Zeile 936-938) wie folgt geändert werden. Statt

 

$total_price = ($total_price - $total_ecotax) * (1 + $product_tax_rate / 100);
$total_ecotax = $total_ecotax * (1 + $product_eco_tax_rate / 100);
$total_price = Tools::ps_round($total_price + $total_ecotax, 2);

 

sollte es heißen:

 

$total_price = Tools::ps_round(($price - $product['ecotax'])  * (1 + $product_tax_rate / 100),2);
$total_price = $total_price * (int)$product['cart_quantity'];

 

Letzteres habe ich aber nicht ausprobiert, sondern lediglich den Tipp eines Users im amerikanischen Forum übernommen, der hier ein Override für PrestaShop 1.5.2 gepostet hat, das allerdings in dieser Form für 1.5.4.1 nicht funktioniert:

http://www.prestasho...ost__p__1167343

 

Gruß

eleazar

Edited July 2, 2013 by eleazar (see edit history)

[pattys]

Hallo nochmal,

 

@eleazar

Ist es korrekt, dass sich diese cart.php , in der die genannten Änderungen vorgenommen werden sollen, in dem Ordner classes befindet?

 

Dort finde ich nämlich nur diese cart.php , die auch den entsprechenden Inhalt hat, alle anderen cart.php die ich gefunden habe, enthalten nur sehr wenige Zeilen an Inhalt.

 

Muss bevor der Code in der Datei ausgetauscht wird, im BO erst noch etwas eingestellt / umgestellt werden oder kann die .php einfach geändert und erneut hochgeladen werden?

 

@Lockesoft, Luca01

Wurden von Euch die hier genannten Code-Schnipsel schon ausgetauscht und ergaben das gewünschte Resultat?

 

Schonmal Danke für die Antworten.

 

Gruß

pattys

[eleazar]

Hallo pattys,

 

ja, es ist die classes/cart.php - und zwar nur die!

 

Was die zweite Änderung anbelangt - die scheint zumindest bei mir nichts zu bewirken. Allerdings könnte es auch sein, dass dafür ein anderes Override verantwortlich ist - das kann ich im Moment nicht klären.

 

Viele Grüße

eleazar

[Luca01]

Hallo pattys, hallo eleazar,

ich habe die beiden Hacks eingepflegt. Das Ergebnis war nicht so, wie es sein sollte. Ich habe auch Dein Beispiel, pattys, noch mal von zwei Seiten mit einer Tabellenkalkulation gerechnet. Also einmal mit 0,35 € netto glatt als Ausgangswert und einmal mit 0,42 € brutto glatt als Ausgangswert. Die zwei Ergebnisse aus der Tabellenkalkulation habe ich angehängt.

Prestashop liefert bei beiden Varianten nur ein Ergebnis nämlich:

Ich weiß auch nicht, wo die MwSt. berechnet wird. Hast Du noch eine Idee eleazar? Woher kommen die Werte im Warenkorb. In der Datenbank ist alles richtigerweise netto. Die MwSt und auch der Bruttobetrag wird also berechnet. Nur wo?

Viele Grüße

 

ps: Es wäre für mich auch schön zu wissen wie Prestashop auf das Ergebnis kommt. Egal ob ich mit glattem Brutto- oder Nettowert rechne. Es kommt immer das gleiche Ergebnis raus, obwohl die Nettowerte natürlich unterschiedlich sind.

Edited July 3, 2013 by Luca01 (see edit history)

[Lockesoft]

So direkt gefragt....

 

Ja ich hatte das ausprobiert, aber ohne korrektes Ergebnis, da scheint seit 1.5.2 noch mehr geändert zu sein.

[Luca01]

Hallo,

kann das Problem jemand verständlich in den Bugtracker eintragen?

Viele Grüße

Edited July 4, 2013 by Luca01 (see edit history)

[eleazar]

Hast Du noch eine Idee eleazar? Woher kommen die Werte im Warenkorb. In der Datenbank ist alles richtigerweise netto. Die MwSt und auch der Bruttobetrag wird also berechnet. Nur wo?

 

Berechnet werden sie schon in der classes/cart.php. Aber der Fehler kann durchaus auch in einer Rechenmethode in der hier aufgerufenen tools.php liegen. Oder es ist die Wahl der Methode in der classes/tax/taxCalculator.php.

Sucht euch was aus.

 

Interessant für Deutschland is auf jeden Fall noch der folgende Vorschlag:

http://www.prestashop.com/forums/index.php?/topic/203809-solved-tax-calculation-15/page__view__findpost__p__1018760

 

Ob die Meldung in Github viel bringt, wage ich allerdings zu bezweifeln. Die bisherige Behandlung von Fehlern bei der Steuerberechnung lässt nicht unbedingt Begeisterungsstürme aufkommen.

 

Andererseits ist das Problem ja nun wirklich nicht so gravierend, denn Endkunden interessieren sich in erster Linie dafür, ob unterm Strich alles stimmt. Wer rechnet da schon die MwSt nach? Das Finanzamt wiederum interessiert sich bei Betriebsprüfungen für fortlaufende Rechnungsnummer - und dass selbst bekannte Buchführungsprogramme wie etwa Lexware z.T. haarsträubende Rundungsfehler produzieren, die das oben Festgestellte locker in den Schatten stellen, hat sich selbst beim Finanzamt rumgesprochen.

 

Also ist es im Regelfall eine zwar ärgerliche, aber noch tolierierbare Abweichung - deren Ursprüngen aber natürlich nachgegangen werden muss.

Edited July 4, 2013 by eleazar (see edit history)

[Lockesoft]

Hallo Zusammen,

 

Hallo,

kann das Problem jemand verständlich in den Bugtracker eintragen?

Viele Grüße

 

Das scheint schon jemand getan zu haben:

http://forge.prestas...owse/PSCFV-7864

wenn auch in einer anderen Sprache, aber es sieht sehr nach "unserem" Bug aus. Also bräuchten nur noch ein paar Leute ein "me too" dazu.zuschreiben... :-)

 

LG Klaus / Lockesoft

 

Nachtrag:

habe mein "Me too" eben dazu geschrieben.

Edited July 11, 2013 by Lockesoft (see edit history)

[pattys]

Hallo,

 

im Bugtracker hatte ich mich auch bereits ein wenig umgeschaut, allerdings habe ich da nicht so ganz durchgeblickt.

 

Muss man sich für den Bugtracker extra registrieren oder kommt man da irgendwie auch mit der Registrierung von diesem Prestashopforum rein?

 

Gruß

pattys

[Lockesoft]

Ich meine das wäre eine extra Registrierung gewesen. Ist aber in meinem Fall schon eine kleine Weile her. Der beginnende Altersheimer lässt da grüßen :-)

 

LG Klaus / Lockesoft

[pattys]

Wie ich sehe, habt Ihr alle ebenfalls Eintragungen im Bugtracker vorgenommen.

 

Wie geht es jetzt erfahrungsgemäß weiter?

 

Wann kann man wohl mit einer Lösung des Problems rechnen oder kann es sein, dass das Problem dennoch nicht behoben wird?

 

LG pattys

[eleazar]

Hi,

 

im Moment scheint sich das Prestateam noch zu sperren, obwohl inzwischen nicht nur im Bugtracker, sondern auch im englischen und im französischen Forum die Steuerberechnung zunehmend zum Reizthema wird.

 

Im vergangenen Monat hat eine versierte Userin hier im französischen Forum eine Reihe von Fehlerbereinigungen vorgenommen, hat dann aber schließlich doch entnervt für's erste aufgesteckt: "J'abandonne!" - Ich gebe auf!

 

Es scheint wirklich, als ob schon der Ansatz der Berechnungsmethode falsch durchdacht ist und zwangsläufig zu Fehlern führt. Vertrakterweise nur nicht immer, sondern nur bei Bestellungen, die größere Stückzahlen von einzelnen Artikeln enthalten!

 

Ich habe die Änderungen von emily_d zu zwei Overides verarbeitet und mich dann gestern mal drangesetzt, wenigstens die Rechnung richtig rechnen zu lassen.

 

Dazu musste ich mir erst mit einem kleinen Trick den als Variable nicht verfügbaren MwSt-Satz für jeden Artikel verschaffen, der jetzt auch in der Weiterentwicklung meines Rechnungsformulars beim Einzelposten angezeigt wird.

 

Ich hab dafür den Rabatt wegfallen lassen - bzw. auf Kommentar gesetzt - um Platz zu schaffen. Wer ihn also braucht und nicht gleich die ganze Tabelle ändern will, der sollte der Einfachheit halber dafür den Netto-EP wegfallen lassen, weil der durch die Angabe des MwSt-Satzes in jeder Zeile ohnehin obsolet geworden ist.

 

In der invoice.tpl stimmen jetzt die Nettosumme sowie der MwSt-Gesamtbetrag centgenau, auch wenn Artikel in größerer Stückzahl geordert werden. Hier mal ein Beispiel:

 

 

 

Dagegen gibt es nach wie vor in manchen Fällenb Abweichungen bei den Steuerdetails, denn die zu ändern, ist wesentlich komplizierter. Ich denke mal, damit müssen wir im Moment einfach leben. Sie werfen ja auch nur dann abweichende Werte aus, wenn größere Mengen ein und desselben Artikels bestellt werden. Und bei kleineren Stückzahlen bemerkt man es kaum.

 

In meinem Rechnungsformular werden eigenen Summen- und MwSt.-Berechnungen vorgenommen - ich habe die Originalberechnungen der Einfachheit halber ausgeblendet. Für nähere Erklärungen fehlt mir momentan die Zeit - wer mag, kann ja einfach mal in die invoice-tpl reinschauen. Falls Interesse besteht, kann ich das ja nachholen.

 

Ich habe bei dieser Gelegenheit auch gleich die überflüssigen 3 Stellen hinter dem Komma bei den Steuerdetails entfernt und am Ende der Rechnung eine Dankesformel eingefügt, die bei Kauf auf Rechnung automatisch ein Zahlungsziel auswirft (voreingestellt sind 8 Tage nach Rechnungsdatum).

Für letztere Lösung Dank an Luca01 .

 

Hier ein Downloadlink mit dem geänderten Rechnungsformular und den Overrides:

 

 

Gruß

eleazar

Edited July 12, 2013 by eleazar (see edit history)

[duude]

Hallo,

 

sorry das ich den Thread nach über einem Jahr noch einmal aufwärme. Gibt es inzwischen eine Lösung für die Version 1.5.6? Wenn nicht würde ich gern den Workaround von eleazar im letzten Post testen, finde dort aber weder das Beispiel noch den Link zum download. 

Hat jemand eine Idee?

 

vg

duude

[eleazar]

Hallo,

 

sorry das ich den Thread nach über einem Jahr noch einmal aufwärme. Gibt es inzwischen eine Lösung für die Version 1.5.6? Wenn nicht würde ich gern den Workaround von eleazar im letzten Post testen, finde dort aber weder das Beispiel noch den Link zum download. 

Hat jemand eine Idee?

 

vg

duude

 

Ja, das war aber nur ein Workaround für das Rechnungsformular. Ich habe vorhin eine Lösung gepostet:

http://www.prestashop.com/forums/topic/357357-korrekte-mwst-berechnung-f%C3%BCr-16-und-15/

 

Probiert sie einfach mal aus.