Jump to content

Gurkcity

Global Moderators
  • Posts

    372
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Gurkcity

  1. zur VAT Nummer: ich glaube das stellst Du bei den Ländern als Bestandteil der Adresse ein international > Länder & Gebiete > Länder > Land bearbeiten und sollte dann auf der Rechnung erscheinen. Zur Übersetzung: Schau mal im classic Theme unter Shop > PDF
  2. Hallo Dirk, ok, schicke mir sehr gerne die Override per PN zu. Zum Thema Mailtemplates habe ich intern einen Auftrag angelegt. Wir werden das näher untersuchen. Wenn jemand das schon heraus gefunden hat, gerne eine Info hier oder auch per PN an mich. Viele Grüße Chris
  3. Hallo Dirk, kannst Du zu 1) kurz einen Screenshot schicken und einen Link zuschicken, wo die Override gezeigt wird? zu 2) Ist irgendwo schon ein Ansatz bekannt, was die Ursache sein könnte, dass die zusätzlichen E-Mail-Inhalte i.d.R. nicht installiert werden? Viele Grüße Chris
  4. Sehr guter Einwand. Habe mir hierzu auch schon Gedanken gemacht und wir haben uns dazu entschlossen, das Modul zu forken (so wie von PrestaShop vorgeschlagen) und werden für uns und unsere Kunden die Weiterentwicklung voran treiben. Es darf sich gerne jeder daran beteiligen https://github.com/gurkcity/ps_legalcompliance Wenn ihr noch weitere Ideen hierzu habt, lasst es mich einfach wissen. In unserem Shop bieten wir sowieso schon seit längerem die original Version 3.0.2 zum Download an, da viele Shopbetreiber das Modul im Addons Store gar nicht mehr finden können. Wir werden zukünftig darauf hinweisen, dass es sich um einen Fork handelt, wenn wir das als weiter entwickelte Version anbieten. Unter dem öffentlichen Repository auf Github kann sich dann sowieso jeder ein Bild von der Weiterentwicklung machen. Viele Grüße Chris
  5. Ich würde mal frech behaupten, dass der eingesetzte Elementor mit den angehängten CMS-Seitenschnipseln in den jeweiligen E-Mails (konfigurierbar über das Modul Rechtssicherheit) nicht kompatibel ist, sondern nur über das Front Office schick aussieht. Hintergrundinfo zu den E-Mail Themes: Bei der Shopinstallation entscheidest Du Dich für ein E-Mail-Theme. Wenn die generiert werden, werden die vorhandenen Mailvorlagen überschrieben. Es gibt hierbei nur modern und classic. Diese Themes haben bis auf den Namen classic nichts mit den Designvorlagen classic, warehouse und warehouse child zu tun. E-Mails werden entweder direkt im root ("im Programm" - kein Template gewählt) oder im installierten Template hinterlegt. Du kannst Dir die per FTP ansehen, z.B. im Ordner /mails/de/ (im root) oder /themes/warehouse(ggf. child)/mails/de/ (in Deinem Template, falls warehouse_child aktiv ist). Das de steht logischerweise für die deutschen Mails. Darin findest Du jeweils eine html und eine txt Variante der Mailvorlage. Die html Vorlagen kannst Du Dir natürlich lokal herunter laden und in einem HTML-Editor weiter überarbeiten, z.B. die order_conf.html. Du musst also nicht das Modul Rechtssicherheit nehmen (es vereinfacht die Sache nur ein wenig), sondern Du kannst das auch alles manuell ergänzen, wie Du es in der E-Mail angezeigt haben möchtest. Ich kann mir gut vorstellen, dass der Elementor sein eigenes Scripting hat und dann sehr viele Codes in den E-Mails anzeigt, die dann sichtbar werden und unschön beim Kunden ankommen. Benutzt Du denn als Standard das clasic oder das modern Mail-Theme? Ansonsten einfach mal auf das andere wechseln, vielleicht gefällt Dir das schon besser. Wenn Du fit in HTML bist, kannst Du auch gerne mal ausprobieren, ein eigenes Theme aufzubauen. Die beiden Mail-Themes findest Du als Vorlage unter /mails/themes/modern/ bzw. /mails/themes/classic/
  6. Es handelt sich hierbei nicht um den Standard PrestaShop Bestellvorgang. Entweder liegt es am verwendeten Template oder Checkout Modul. Ich tippe auf das Modul. Daher schlage ich vor, entweder in den Moduleinstellungen zu suchen oder den Modulentwickler zu kontaktieren. Viele Grüße Chris
  7. Guten Morgen runimo, einen guten Ansatzpunkt findest Du direkt in Deiner Datenbank, da dort die Nettopreise Deiner Produkte "ungerundet" stehen. Wenn Du ausgehend hiervon mal ein paar Beispiel-Bruttopreise mit dem aktuell gültigen Steuersatz berechnest, wirst Du vermutlich erkennen, dass diese nicht glatt mit 2 Dezimalstellen sind, sondern auch hier "ungerundet" vom PrestaShop "erzeugt" werden. Damit diese wieder "geglättet" werden, könnten Dir diese SQL-Statements helfen: Ich hoffe, es hilft Dir weiter. Viel Erfolg beim Hin- und Herrunden 😀
  8. Die Ergänzung dieser Klasse im Template könnte schon helfen: Viele Grüße Chris Gurk
  9. Hallo Whiley, vollkommen korrekt. Danke nochmal für das Aufgreifen des Beispiels und die Idee mit den zusätzlichen Tabellen. Ich habe einfach ein Backup lokal von allen Shops vom 30.06.2020 vorliegen. Damit lässt sich das am 01.01.2021 nochmal abgleichen. Mal eine andere Frage, vielleicht hat das der eine oder andere bereits untersucht: die Schwierigkeiten tauchen insbesondere bei PayPal auf. @Wuschel hat das bereits angedeutet, dass das vom eingesetzten Modul abhängt. Das klassische PayPal Modul (z.B. bei einem älteren Shop die Version 3.11.1, technischer Name 'paypal') berechnet den Warenkorb neu. Ich denke, dass das auch bei den neueren Modulen so ist. Hat das Problem dadurch auch etwas mit den im Shop eingestellten Rundungsregeln zu tun? Viele Grüße Chris
  10. Irgendwie reden wir aneinander vorbei. Du gehst davon aus, dass 6.931034 in der DB stehen. Tut es aber nicht, es steht 6.932773 nach der Umstellung, genauso wie vor der Umstellung in der DB. An den Nettopreisen hat sich ja nichts geändert. Die sind lediglich "krumm", da der Bruttopreis "gerade" eingegeben wurde. Und durch die Umstellung sind jetzt beide Preise "krumm". Und Endkunde und PayPal möchten "gerade" Preise. Also korrigiere ich 16% VK wieder "gerade" wodurch neuer Nettopreis anders "krumm" wird (6.931034 neu).
  11. Ich habe Pete78 zitiert und da steht das bereits. Bitte mal genau lesen. Meine SQL-Statements gehen davon aus, dass die Mwst bereits umgestellt wurde und die Bruttopreise nicht beibehalten wurden.
  12. korrekt, der reduction_type muss auf 'amount' stehen. Bei percentage macht das natürlich keinen Sinn.
  13. Du gehst von einer falschen Ausgangslage aus. Richtig wäre VK 8,25€ mit inkl. 19% MwSt. macht Nettopreis in Presta DB 6,932773 Dann am 01.07. Steuersenkung von 19 auf 16%, wir gehen davon aus, dass die Steuersenkung an den Endverbraucher weiter gegeben wird. Daraus ergibt sich ein VK von 8,04€ inkl. 16% MwSt. Dies aber gerundet, denn von diesem Nettopreis kommen wir auf 8,0420168 € als Brutto inkl. 6 Nachkommastellen, also ziemlich unrund aus B2C Sicht. Natürlich sieht der Endverbraucher nur die 2 Stellen hinter dem Komma. Jetzt kommen die obigen Formeln ins Spiel. Die Steuerumstellung ist passé, die Preise sind mehr oder weniger ungerade. PayPal macht Probleme, da das Modul alles nochmal versucht selbst zusammenzuwursteln und mit dem Presta Warenkorb vergleicht. Die obigen Formeln rechnen den Nettopreis um in den Bruttopreis, rechnen mit 16% Steueraufschlag, runden auf 2 Stellen und schreiben daraus den neuen Nettopreis in die DB. Das ist gebau das gleiche, wie wenn Du im BO den Bruttopreis mit zwei Stellen gerundet ins Feld eintippst, im Hintergrund wird Netto mit 6 Nachkommastellen errechnet und in die DB geschrieben. Aus 8,04€ Brutto inkl. 16% MwSt. wird dann 6,931034 in die DB geschrieben. Ich habe es getestet und es passt für uns auch soweit.
  14. Danke für den Vorschlag. Einer unserer Kunden ist ebenfalls in dieses Dilemma gekommen, da durch die MwSt. Umstellung die Bruttopreise nicht mehr "glatt" waren, was diese aber für einen B2C Shop mit Bruttopreisen sein sollten. Wir haben das noch auf die Varianten und den ermäßigten Steuersatz erweitert. Und wer weitere ermäßigte Steuersätze oder mit anderen IDs oder Tabellenpräfixen arbeitet, muss das entsprechend noch anpassen. -- Rundungsdifferenzen nachträglich korrigieren -- Regelsteuer (16%) -- Produkte UPDATE `ps_product` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1; UPDATE `ps_product_shop` SET `price` = ROUND(1.16*`price`,2)/1.16 where `id_tax_rules_group` = 1; -- Produktvarianten UPDATE `ps_product_attribute` AS pa INNER JOIN `ps_product` AS p ON (p.`id_product` = pa.`id_product`) SET pa.`price` = ROUND(1.16*pa.`price`,2)/1.16 WHERE p.`id_tax_rules_group` IN (1); UPDATE `ps_product_attribute_shop` AS pa INNER JOIN `ps_product_shop` AS ps ON (ps.`id_product` = pa.`id_product` AND ps.`id_shop` = pa.`id_shop`) SET pa.`price` = ROUND(1.16*pa.`price`,2)/1.16 WHERE ps.`id_tax_rules_group` IN (1); -- Sonderpreise UPDATE `ps_specific_price` AS sp INNER JOIN `p_product_shop` AS ps ON (ps.`id_product` = sp.`id_product` AND ps.`id_shop` = sp.`id_shop`) SET sp.`reduction` = ROUND(1.16*sp.`reduction`,2)/1.16 WHERE ps.`id_tax_rules_group` IN (1) AND sp.`reduction_type` = 'amount' AND sp.`reduction` > 0 AND sp.`reduction_tax` = 0; -- Foodstuff / Reduced Rate o.ä. (5%) -- Produkte UPDATE `ps_product` SET `price` = ROUND(1.05*`price`,2)/1.05 where `id_tax_rules_group` = 2; UPDATE `ps_product_shop` SET `price` = ROUND(1.05*`price`,2)/1.05 where `id_tax_rules_group` = 2; -- Produktvarianten UPDATE `ps_product_attribute` AS pa INNER JOIN `ps_product` AS p ON (p.`id_product` = pa.`id_product`) SET pa.`price` = ROUND(1.05*pa.`price`,2)/1.05 WHERE p.`id_tax_rules_group` IN (2); UPDATE `ps_product_attribute_shop` AS pa INNER JOIN `ps_product_shop` AS ps ON (ps.`id_product` = pa.`id_product` AND ps.`id_shop` = pa.`id_shop`) SET pa.`price` = ROUND(1.05*pa.`price`,2)/1.05 WHERE ps.`id_tax_rules_group` IN (2); -- Sonderpreise UPDATE `ps_specific_price` AS sp INNER JOIN `p_product_shop` AS ps ON (ps.`id_product` = sp.`id_product` AND ps.`id_shop` = sp.`id_shop`) SET sp.`reduction` = ROUND(1.05*sp.`reduction`,2)/1.05 WHERE ps.`id_tax_rules_group` IN (2) AND sp.`reduction_type` = 'amount' AND sp.`reduction` > 0 AND sp.`reduction_tax` = 0; Bin gerne offen für Verbesserungsvorschläge 😉
  15. Da müßtest du wenigstens mal deine Prestashop-Version verraten, hast du die dafür richtige Modulversion verwendet? Vielleicht auch deine PHP-Version. Was den Error 500 angeht, aktiviere Error Reporting für eine (hoffentlich) aussagekräftige Fehlermeldung. Ich habe mit dem Kunden direkt Kontakt aufgenommen. Danke Whiley, für den schnellen Support 😉
  16. Ja, wenn das so benutzt wird, würde ich sinnigerweise auch die Bezeichnungen abändern. Wir haben das bei den Shopbetreibern, die wir manuell umgestellt haben, direkt in der Datenbank Tabelle ps_tax_lang geändert
  17. Poste doch mal Deine SQL-Statements. Vielleicht hast Du etwas vergessen. Hast Du vielleicht Caching Module im Einsatz? zum 500er Fehler: schau mal in die Error-Logs des Servers. Ansonsten schalte mal den Debug Modus im Shop an (Erw Einstellungen > Leistung) und schicke den Request nochmal ab.
  18. Schau doch mal bei einem Produkt, das mit 19% erfasst wurde, wie die Steuerregel heißt. Diese wählst Du dann in dem Modul aus (so vermute ich es zumindest, ohne das Modul zu kennen). Viele Grüße Chris
  19. Vollkommen korrekt, da habe ich mich geirrt. Habe das eben getestet (in einiger 1.7er Versionen von 1.7.2.4 bis 1.7.6.5). Die Versandkosten werden als Netto bei den Versanddienstleistern in die Eingabemasken eingetragen. Diese werden mit der Steuerumstellung auch reduziert. Wer also den gleichen Versandkostenbetrag beibehalten möchte, muss hier nochmal eingreifen und den Wert um den Steuermultiplikator (1,19/1,16) erhöhen.
  20. Die neueste Version 1.1.0 ist auch kompatibel mit 1.7.2.4. Habe es eben selbst nochmal getestet. Jörg hat sogar eine Version, die mit 1.6 kompatibel ist.
  21. Das Rechtssicherheitsmodul setzt voraus, dass die Bruttopreise bei den Versanddienstleistern angegeben werden. Wer also das Modul "Rechtssicherheit" im Einsatz hat, sollte nach der Umstellung keine Probleme haben. Aus dem Bruttobetrag wird für die Bestellung/ Rechnung der Steuerbetrag errechnet. Egal ob mit Anhebung der Nettopreise (bei Beibehaltung der Bruttopreise) oder anders herum. Wer also auch hier bei den Versandkosten den Steuervorteil an den Endverbraucher weiter geben möchte, kann das bei den Versanddienstleistern im Nachgang der Steuerumstellung machen. Viele Grüße Chris
  22. Vielleicht sollten wir uns in Zukunft abstimmen, denn wir haben letzte Woche auch ein neues Modul entwickelt und in unserem Shop veröffentlicht, mit dem sich die Steuersätze auf Knopfdruck ändern lassen. 😉 Ich finde es aber auch gar nicht so schlecht, wenn der Shopbetreiber die Wahl hat, per Datenbankadministration die Umstellung durchzuführen (falls die Bruttopreise beibehalten werden sollen, ansonsten ist ein direkter Datenbankeingriff gar nicht notwendig) oder ein Modul nutzt und mit wenigen Klicks die Änderungen durchführen kann. Ein Modul hat den Vorteil, es gibt Support und es ist einfach in der Bedienung. Wir wünschen allen morgen Abend eine erfolgreiche Umstellung! 🙏 Viele Grüße Chris
  23. Wie angekündigt, haben wir nochmal die Steuer-Änderungsthematik zu den Grundpreisen recherchiert: Grundpreise für einfache Einzelprodukte sind unproblematisch, da hier das Verhältnis (unit_price_ratio) gespeichert ist. Das ist das Verhältnis des NettoProduktpreis zum Netto-Grundpreis. Also einfach nur ein Faktor, der durch die Mehrwertsteuerumstellung nicht betroffen ist. Bei Artikel mit Varianten, die Einfluss auf den Grundpreis haben verhält es sich ein wenig anders, da hier das Feld "Auswirkung auf den Preis pro Einheit" als absoluter Wert in der Datenbank steht. Das Feld "unit_price_impact" muss also auch mit dem Faktor der Umstellung multipliziert werden (am 01.07. => *1.19/1.16). Es ist also kein Raten notwendig, um die korrekten Preise zu bekommen. Und ehrlich gesagt, finde ich diese Berechnung viel charmanter und einfacher, als es noch bei 1.5 war. Es gibt hierbei noch weitere Felder zu beachten, z.B. in der product_attribute(_shop) Tabelle das Feld "price". Das ist die Nettopreis-Auswirkung auf den Produktpreis des Hauptproduktes. Auch dieser muss mit dem Faktor der Umstellung multipliziert werden (am 01.07. => *1.19/1.16). Viele Grüße Chris
  24. Hallo Whiley, danke für die Ausführungen und das Zusammentragen der Infos. Wir haben uns das mit den specific_prices Tabellen näher angesehen. Das ist nicht ganz so einfach und sollte unterscheiden werden. Für den Fall, dass hier Produkte mit hinterlegten id_product stehen, kann das richtig sein. In der Regel steht aber im Feld 'price' ein -1.000000 Wert und erst dann wird abhängig von reduction_tax und reduction_type der Wert im Feld reduction berücksichtigt. Anderenfalls ist der Wert > 0 und wird als Fixwert behandelt. Betrifft übrigens Sonderpreise von Produkten, wie auch die Katalog-Preisregeln. 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? Vielleicht habe ich auch einen Denkfehler...Ich werde das bis zum Wochenende mal testen und hier nochmal Feedback geben. Viele Grüße Chris
  25. Bei diesem Dateinamen wird mir ganz schwindelig: ModulesProductcommentsProductcomments_reviews.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.de-DE.xlf 😵 Bist Du sicher, dass es diese Datei überhaupt gibt? Versuche mal das original-Template /themes/classic/ wiederherzustellen. Und danach nutze die Übersetzungsfunktion von PrestaShop. Vielleicht beschreibst Du nochmal genau, welchen Teil Du übersetzen möchtest. Viele Grüße Chris
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More