pattys

Nunja, die Sache mit der falschen Berechnung der MwSt im Warenkorb, blieb ja offensichtlich auch lange Zeit unentdeckt, zumindest bei einem Großteil und vielen ist es bis heute sicherlich noch nicht aufgefallen. Ja, Cache´s, Chronik, Cookies alles entsprechend gelöscht, hab auch extra, um da ganz sicher zu sein, auch mit anderen Browsern probiert und sogar auch an einem anderen PC :-). Ich bin gerade auf noch nem weiteren Webspace von mir, da hab ich noch ne ältere Version vom Prestashop drauf, die 1.5.2.0 und wollte da nun testen. Die Passage für den Grundpreis in der .tpl habe ich bereits mit der für die Version 1.5.4.1 verglichen und sie sind identisch. Allerdings habe ich in der alten Version 1.5.2.0 kaum Artikel drin, werde dort jetzt weitere Testartikel anlegen und dort überall die 10€ netto als Grundpreis eintragen. Bisher ist es bei 3 Artikeln drin und dort ist es jeweils im Shop dann korrekt angezeigt, mal sehen wenn ich weitere anlege ob es so bleibt, nur ändert das leider nichts an der Tatsache, dass es in meinem aktuellen Shop 1.5.4.1 nicht immer korrekt ist. Ich habe nur keine Ahnung was das Ganze verursachen könnte, irgendwas muss ja dafür verantwortlich sein, sonst wäre das Ergebnis ja richtig.

Hi, nein, dies war es leider nicht. Da ich mir jetzt auch unsicher war, ob ich diesen Code nun in der product.tpl (Produktseite) oder der product-list.tpl (Produktliste) mit der entsprechenden Passage ersetzen sollte, habe ich es einfach mit beiden .tpl nacheinander ausprobiert. Wenn ich es in der product.tpl ersetze habe ich im Ergebnis nichtmal mehr ein Layout von der Seite, also es richtet irgendwie Chaos an und in der prduct-list.tpl richtet es zwar kein Chaos an, es steht dann da lediglich "unit price x.xx pro 100g" und immernoch der falsche Preis. Dass dies der Haken war "weil hier nur mit zwei Stellen hinter dem Komma gerechnet wird." kann ich mir nicht vorstellen, deshalb hatte ich einen schönen glatten Nettopreis genommen. Denn 10€ netto sind 11,90€ brutto, da gäbe es keine Rundungsfehler, weil garnix gerundet werden muss. Du glaubst nicht, was mich das in solchen Situationen ärgert, dass ich nicht selbst programmieren kann. Ich werde mir das alles mal genauer anschauen und gucken ob ich es hinbekomme, die Variablen korrekt zuzuordnen und mir ggfl. selbst was zu basteln, so wie ich mir mit der MwSt-Berechnung für den Warenkorb bei Mehrfachbestellung von einem Artikel auch schon mit einer unsauberen Lösung weitergeholfen habe. Schade finde ich, dass sich noch keine anderen Anwender gemeldet haben, es wird doch sicherlich häufiger vorkommen, dass jemand einen Grundpreis angeben muss und wenn es nur die Aussage wäre "Bei mir ist alles in Ordnung, hab die Preise überprüft". Schönen Gruß pattys

Nabend, es ist natürlich korrekt, dass die Grundpreisangabe nicht "von Haus aus" auch in der Produktliste zu sehen ist. Die Info, wie die Darstellung des Grundpreises auch auf der Produktliste sichtbar ist, habe ich von dort http://www.prestashop.com/forums/topic/196102-fixgrundpreis-base-price-ps-14x-ps-15x/ Im Prinzip wurde also nur in der product-list.tpl eine Zeile hinzugefügt. Aber von "Haus aus" ist die Grundpreisangabe auf der Produktseite zu sehen und dort ist die Grundpreisangabe genauso falsch, wie auch in der Produktliste zu sehen ist. Ich habe vorhin auch, um sicher zu gehen, die Original .tpl Dateien vom Prestashop 1.5.4.1 benutzt, sodaß ich also in der Produktliste KEINE Darstellung mehr hatte und somit nur noch auf der Produktseite den Grundpreis sehen konnte und es war trotzdem genauso falsch. Mir ist im Zusammenhang mit dem Grundpreis auch noch was weiteres aufgefallen, was ich allerdings erstmal noch nicht erwähnen wollte, damit nicht wieder zuviele Probleme aufeinmal hier stehen. Erstmal möchte ich gerne hinter des Rätsels Lösung für die falsche Darstellung kommen, die eben nicht immer passiert. Gruß pattys

Hallo eleazar, das angesprochene Problem bei Mehrfachkauf eines Produktes und den "Rundungsfehlern" hatten wir vor ein paar Monaten schonmal "besprochen" und um dieses geht es jetzt aber NICHT. Es geht um die Grundpreisangabe, welche nach PAngV bei manchen Artikeln gesetzlich vorgeschrieben ist. Um nicht alles nochmal zu schreiben, füge ich einfach mal einen Screenshot bei, der hoffentlich selbsterklärend ist :-) Damit es leichter nachvollziehbar ist, habe ich einen fiktiven Grundpreis (netto) von 10,00 € / 100g genommen. Auf evtl. Antworten bin ich gespannt. LG pattys

Hallo, vorgestern stellte ich beim Bearbeiten in meinem Prestashop ein seltsames Verhalten in Verbindung mit der Grundpreisangabe fest. Ich baue den Shop noch auf, er ist noch nicht öffentlich verfügbar. Ich nutze die Prestashop Version 1.5.4.1 und zum Testen habe ich auch auf einem anderen Webspace die Version 1.5.6.1, also sollte es nicht an der Version selbst liegen, da der Fehler bei beiden Versionen identisch ist. Der Fehler äußert sich wie folgt: Im Backoffice ist bei 4 verschiedenen Artikeln der gleiche Grundpreis hinterlegt, der ja netto eingegeben wird. Z. B. 10,00 € / 100g direkt daneben steht im Backoffice dann 11,90€ / 100g (Bei der Steuerregel mit 19%) Soweit ist alles korrekt. Wie gesagt, dies steht bei allen 4 Artikeln. Nun sollte eigentlich das Ergebnis bei jedem der 4 Artikel im Frontoffice ebenfalls gleich sein, nämlich 11,90€ / 100g. Das ist es aber nicht, im Gegenteil, im Shop (FO) bekomme ich sogar 4 verschiedene Grundpreise als Ausgabe wie folgt: 12,00 € / 100g 11,90 € / 100g 11,93 € / 100g 11,87 € / 100g Hat das Problem noch jemand und weiß zufällig, woran das liegt? Manchmal stimmt der angegebene Grundpreis und manchmal nicht! Schonmal Danke für eine Antwort Gruß pattys

Hi wzr1one, in my Shop (Version 1.5.4.1) the old "number" GAHHJFG has not changed. Only new orders get the new number, after install.

Aha ok. Sorry, aber heißt das jetzt, dass auch das Override daran nichts ändert, mir also in der Mail für mich auch keine ordentliche Bestellnummer rauswirft? Wenn dies nämlich so ist, dass auch dies in der Mail für mich nichts ändert, dann kann ich mir das sparen, das Override auszuprobieren, weil es dann scheinbar keinen Unterschied macht, ob ich das Modrefchange nutze oder das Override.

In der Mail für den Kunden funktioniert ja das Modrefchange, nur in der Mail, die ich mir als Verkäufer vom Prestashop zusenden lasse (mailalerts.php), dort funktioniert es nicht. Dem holländischen Kollegen hab ich es ja gepostet, eben dort wo Du mir geschrieben hast, ich solle doch im deutschen Forum gucken :-). Ich denke, ich werde mir dann das Override nochmal genauer anschauen und dann ggfl. das Modrefchange wieder rauswerfen. Mein Gedanke war nur, dass ich gerne nach Möglichkeit so wenig wie möglich an den ganzen Dateien selbst was verändern möchte. Meine Liste mit Änderungen, die ich bisher so vorgenommen habe, ist jetzt schon recht heftig, wie ich finde und es ist nicht gerade einfach sich zu merken welche Datei denn jetzt für was zuständig ist, vor allem, wenn man nicht die Zeit hat, sich täglich damit zu beschäftigen und sich fast jedesmal erstmal wieder "neu reindenken" muss. Und ich glaube meine nächste größere Hürde die ich noch mit dem Shop nehmen muss, ist die Funktion ein Teilupdate für meine Artikel durchzuführen, z. B. nur Preise aktualisieren oder nur Mengen. Ich habe nämlich die Befürchtung, dass ich da noch auf einige Probleme stoßen werde. ...... Ich will aber diesen Shop, ich will, ich will, ich will *tschakka* :-D

Hallo, @eleazar .... Du sagtest ja im englischsprachigem Forum ich solle hier mal reinschauen, aber hier geht es doch um das olle Paypal. Gesehen hatte ich die Beiträge hier schon, aber da ich dieses Modul verwende (modrefchange), was von dem aus dem englischsprachigem Forum wohl ist, dachte ich mir, ich frage dann auch dort nach. Im Prinzip möchte ich eben die geänderte Bestellnummer (Buchstabensalat in "bessere Nr.") einfach auch nur in der E-Mail erhalten, die für mich als Verkäufer bestimmt ist. Aufgefallen ist mir allerdings noch, dass die ID-Nr. der Bestellung auch noch im Shop auftaucht (Version 1.5.4.1) und zwar wohl nur dann, wenn eine Gastbestellung gemacht wird, nämlich dann auf der Bestätigungsseite. Das ist so bestimmt auch nicht gedacht. Schönen Gruß pattys

Hello, I use this module, too. Thank you for this. But I still have a question: What must I do, to become also the order-id in the new_order-Mail, which I become, when a customer makes an order? I think there must be an modification in mailalerts.php, but I dont know the exact variable. I have tested the following: The original variable in mailalerts.php was: '{order_name}' => sprintf('%06d', $order->id), this I changed in : '{order_name}' => $order->getUniqReference(), Then the order-id is the same order-id (with the big letters) before I used your module. I hope you can understand what I mean :-) Best regards from Germany PS: I use Prestashop 1.5.4.1

Hallo birobiro, im Backoffice läßt sich das einstellen bei Voreinstellung -> Produkte bei "Anzahl der Tage, in denen das Produkt als "NEU" angesehen wird" Ich hoffe dies war damit gemeint. Schönen Gruß pattys

Hi, no, the same error with the tax is also in the prestashop version 1.5.4.1. It was probable the same error always in previous versions of prestashop, but maybe it's just not noticed. I want to use the prestashop too, but not with this bad error with the tax calculation. In the german forum i opened a topic and the users there, have also incorporated in the bug tracker. Here the link to the posting in the bug tracker: http://forge.prestashop.com/browse/PSCFV-7864 Maybe you can also write there a comment. So the programmers see, that it is a problem for ALL prestashop users. Sorry, for my terrible english and good night :-)

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

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

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

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

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

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

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