DRMasterChief

Hallo, ja darüber wurde wohl schon öfter gestritten... habe gestern nach noch viele Beiträge aus PS gelesen. Es geht mir nicht drum daß weniger Geld reinkommt, die steuerrechtlichen Dinge sind mir schon klar (ggf. unglücklich von mir oben geschrieben). Das mit aktivem AEUC das Verhalten ist rührt daher, daß die letzte Einstellung des Steuersatzes der Versandkosten in der Datenbank gespeichert bleibt (ist das bei TB auch so?). Es ergibt sich aber ein extremes Problem damit (vielleicht vor allem für Deutschland, aber auch für andere Länder dürfte das problematisch sein und zumindest für den Kunden ist es sehr merkwürdig), denn.... wie soll mit diesem Shopverhalten denn eine korrekte Angabe über die zu erwartenden Versandkosten dem Kunden gegenüber vermittel werden? Wir müssen ja die Versandkosten angeben auf einer separaten Seite, auch für andere Länder. Nun kann man diese dann höchstens mit einer Angabe wie "die maximalen Versandkosten betragen...." machen. Ob das wasserdicht und gegen Abmahnungen sicher ist weiss ich nicht. Zumindest nervt es mich als Shopbetreiber daß der Kunde mit jedem Artikel den er mehr im Warenkorb hat einen anderen Versandkostenbetrag angezeigt bekommt. Logisch und sicher wäre es, wenn die fix eingegebenen Versandkosten (z.B. 5 EUR als DHL Paket) immer bestehen bleiben würden im BO für den Kunden. Intern kann die Splittung ja gemacht werden je nach Artikeln. Wir erstellen mit TB oder PS keine Rechnungen, dafür haben wir ein anderes Programm offline, wo es genau so gemacht werden könnte und daher für micht jetzt nicht das Problem schlechthin ist - ich finds dennoch nicht richtig. Desweiteren ist auch diese Splittung fraglich, denn die Versandkosten als Nebenleistung erfahren den gleichen Wert wie die (höhere) Hauptleistung. Die Hauptleistung kann hierfür entweder der Höhe nach der Menge oder dem Wert genommen werden. Es muss also nicht immer zwingend einfach nach dem Betrag geguckt und gesplittet werden. Macht TB die Splittung eigentlich direkt für jeden Artikel einzeln oder wird (wie in den neueren PS-Versionen) nach dem höheren Gesamt geguckt und daraufhin die Steuer für die Versandkosten berechnet? Und was passiert wenn ich die Versandkosten nach Gewicht berechne? Das hätten wir nämlich irgendwann mal so vor.

Hallo, da wir bald live gehen möchten und unsere Artikel einpflegen, ist mir nun leider folgendes Dilemma aufgefallen: mit aktivem AEUC-Modul und Artikeln mit unterschiedlichen Steuersätzen 7% und 19% ist die Anzeige/Berechnung der MwSt. falsch. Ich habe verschiedenes versucht im Modul, z.B. anteilige Berechnung der Steuersätze usw. Das AEUC-Modul schaltet ja die Auswahl der anzuwendenden Steuer in den Versandarten aus (das Dropdown-Menü ist dann einfach nicht mehr vorhanden). Somit kann ich mit aktivem AEUC keine Steuer mehr auswählen für die Versandart. Gebe ich die also nun brutto oder netto ein, wird die Berechnung dennoch falsch im Warenkorb, da nur die zuletzt eingestelle Steuer für die Versandart irgendwie beachtet wird (in meinem Fall also 19%) Liegen dann aber nur Artikel mit 7% im Warenkorb, wird der Nettowert der Versandart genommen und somit werden die Versandkosten günstiger für den Kunden - das ist natürlich schlecht für uns, da dann pro Paket 60 Cent zu wenig vom Kunden bezahlt werden. Noch toller wirds, wenn Artikel beider Steuersätze im Warenkorb enthalten sind, denn dann werden die Versandkosten mit einem Betrag irgendwo dazwischen berechnet bis maximal zum eingegeben Versandkostenbetrag der jeweiligen Versandart. Habt ihr Ideen dazu oder eine Lösung? ....denn nach wie vor bin ich der Meinung daß es doch nicht sein kann das wir immer noch kein wirklich funktionierendes AEUC-Modul haben (vom dem Cacheproblem mal abgesehen, ich denke damit leben die meisten halt einfach durch deaktivieren des Caches). Aber solche Berechnungen müssten halt funktionieren. vielen Dank

I think it is becaus of PHP 7.2 you should use only to PHP 7.1 (not over), this should fix the warnings. Some warnings of PHP are without any further problems, but maybe it is better to use only 7.1

Hmm klar, erstmal blöd und überraschend oder beides, aber mal ehrlich: du weißt doch selbst am besten welche Daten du von Kunden im Shop speicherst. Das wären wohl die personenbezogene Daten, die Bestellungen, ggf. Zahlungsarten und was wann wohin übermittelt wurde (Infos vom Paypal-Auszug). Wenn du noch separat im Büro was speicherst das gleiche (ggf. benutzt ihr eine Wawi oder ähnliches). Zuletzt nochmal mehr oder wenigen die gleichen Daten wenns an einen Steuerberater geht (natürlich ohne Bestellungen/Artikel etc.). Behelfsweise kannst du sowas doch per einfachem copy&paste machen, in ein leeres Blatt rein, als CSV oder PDF speichern und fertig ists. Dazu hast du max. 4 Wochen Zeit. Ob oder wie die Module sowas machen und in welchem Umfang weiss ich nicht, und das wäre dann ja auch noch nicht abschliessend, denn wenn eben noch Wawi und Steuerberater etc. hinzukommen musst du ggf. darüber auch informieren (das kann das Modul ja nicht wissen).

Hi @toplakd , yes i am following your ideas and solution. I also have done some simple changes by CMS and/or html, my opinion is that we do not need checkboxes for most (all) of the GDPR things and it is possible to use the standard tools from tb to configure this. Sometimes a more flexible solution will be fine, so a module can do most of the work for us. But let's see what the next days will bring....

Hello, the first GDPR panic should be over and as far as i can see, many shopowner are over-doing requirements a bit. tb should have an focus on: Conclude it's not really necesarry to have checkboxes for consent on contact form and creating account. As we have discussed before a simple message with link to the pricacy policy is enough. The GDPR module should contain an option to just put messages for this instead of check-boxes. So everyone is free to choose from checkbox or just the simple message. Thanks so far, can't wait to see this module :)

Aaaaalso: Einwilligung per Haken oder sonstwie ist meistens eher blöd, da diese vom Kunden widerrufen werden kann wie er grad lustig ist. Wenn WIR eine Einwilligung einholen und der Kunde sie gibt, kann er die Einwilligung widerrufen, ob das dann technisch funktioniert und "wo überall" ist unser Problem, und vor allem muss es dann wasserdicht sein (was ja scheinbar technisch gar nicht machbar ist und rechtlich erstmal sowieso nicht) - also machen wir uns doch da gar kein Problem uns sehen wir uns das mal an: Art. 6 – EU-DSGVO – Rechtmäßigkeit der Verarbeitung Finaler Text Rechtmäßigkeit der Verarbeitung 1. Die Verarbeitung ist nur rechtmäßig, wenn mindestens eine der nachstehenden Bedingungen erfüllt ist: a) Die betroffene Person hat ihre Einwilligung........ vergessen wirs.... weiter dann, und jetzt kommts: b) die Verarbeitung ist für die Erfüllung eines Vertrags, dessen Vertragspartei die betroffene Person ist, oder zur Durchführung vorvertraglicher Maßnahmen erforderlich, die auf Antrag der betroffenen Person erfolgen; .... somit: Wenn der Kunde bestellt, dann erfolgt das ja auf Antrag der betroffenen Person (das ist der Kunde ja selbst). Es ist also genau b) gegeben und als rechtliche Voraussetzung zutreffend. Somit müssen "nur" noch andere Punkte der DSGVO beachtet werden (Datenportabilität, Recht auf Vergessen etc.), aber das kann der Kunde ja ggf. sowieso selbst machen im Konto, ggf. per Modul das es schon gibt oder das noch kommt. Meiner Meinung nach wäre im Shop nur eine saubere "Konto löschen" -Funktion notwendig. Die Datenportabilität muss nicht automatisiert erfolgen, d.h. der Kunde kann auch einfach eine mail schreiben und der Händler lässt ihm innerhalb von 4 Wochen eine CSV-Datei zukommen (wird wohl das geeignetste Format sein). Der Händler MUSS auch keine Gastbestellungen zulassen (oder er muss sie ja nicht so nennen....), sofern er mindestens einen anderen Bestellweg ermöglicht (per email oder Telefon...). Daß die Bezeichnung der Gastbestellung dann ggf. blöd ist und im Hintergrund dennoch ein Konto angelegt wird ist halt im Shopsystem so und technisch nicht anders machbar. Die Art der Bestellung könnt ihr ja umbenennen (statt Gastkonto). Intern kann man diese Kunden dann, also die "Gastkunden", nach 6 Monaten löschen. Mir ist es derzeit wirklich zu heiß und zu blöd irgendwelche Anmeldeformulare mit Haken oder sonstwelchen Texten zu versehen, die sich 1. nur als kompliziert zu programmieren/implementieren herausstellen, 2. den Kunden vom Checkout abbringen, da viel zu viel klickerei 3. rechtlich die ganze Sache unsicherer machen als nötig und gerade deswegen abgemahnt werden (!) Es ist wie mit der USt. , wer (falsch) ausweist, muss diese auch abführen ans Finanzamt. Also schauen wir doch und wenn wir per Art. 6 schon die Möglichkeit haben - hey, ruhen wir uns darauf aus ! Es wäre nun schön wenn ein Entwickler oder sonstwie Nahestehender diese Thematik auch an die Programmierer von tb weiterleiten würde, denn ich hoffe nicht daß wir dann ein riesen aufgeblasenes DSGVO-Modul bekommen indem die Hälfte eigentlich unnötig ist. Das könnte ja passieren, da sich in anderen Ländern nicht ganz so viel drum gekümmert wird und man dann gerne versucht alles zu erschlagen was man meint mit so einem Modul erschlagen zu können. Zumindest müsste vieles dann ein-/ausschaltbar sein, um auf die unterschiedlichen Shops dann auch wirklich zu passen. Ganz viele nutzen keine Tracking-dinge, Analyzing usw, und ich möchte daher keinen Pflichtbanner haben der auf Cookies hinweist die es in unserem Shop dann gar nicht gibt oder geben wird. Das gleiche gilt natürlich auch für Haken usw. die man aus o.g. Gründen gar nicht setzen muss.... usw. Ende, fertig

kla.tv hat mir zumindest den gewittrigen Tag versüßt, ernstnehmen kann man das aber nicht.... der restliche Inhalt der Seite sagt ja schon viel aus. Aber gerne kann sich jeder eine Meinung bilden. Besser wäre es aber hier im Forum auf sachlicher, technischer Ebene zu bleiben. Ich wollte nur mal eine "Warnung" an andere User aussenden, die 15 Minuten könnt ihr besser nutzen, z.B. einen Tee kochen. Bezgl. thirtybees DSGVO-Modul scheint es noch nichts neues zu geben. Es gibt aber einige andere Ansätze eine Lösung herbeizuführen, siehe 3-4 Beiträge weiter oben. Auch das Module von M4 ist wohl vom Umfang her das beste und nicht sehr teuer.

Hi, pls. see also https://forum.thirtybees.com/topic/1768/invalid-mail-name-newsletter_conf-every-time-trying-to-remove-powered-by-prestashop-and-save-in-translations/11 Download the files from /mails/language and / or from /yourTemplate/mails or use them from your shop-installation which already exists on your computer. then modify the files as you like then upload them into the same folder (make a backup of the original files or rename them…) for FTP upload you can use software like WinSCP or FileZilla to modify the html files you can use e.g. this: https://html5-editor.net/ You do not have to upload these files to a module, only into the correct folder /mails/ and or /yourTemplate/mails done! and: you have to change it in ALL /mails/ folders (in root and also in your template folder etc…, the best way is to rename them and check which one is sent, this depends on TB and on the theme, see also this here: https://forum.thirtybees.com/topic/1609/welche-mailvorlagen-verwendet-tb/5 its in German and i have got the same problem a time ago). You have to copy the lang.php in each folder, too (if it does not exist regarding a translation into another language). Hope you can find some hint there.

ok i understand ;) but i am interested in speed and maybe also in GDPR, we also have no live shop at the moment, but will change to TB this year. thank you

show us , please :) everyone likes to see it here https://forum.thirtybees.com/category/29/feedback-on-my-store

Yes, you are right, it´s great here at the TB place :) Maybe you can go the way to migrate with an software like e.g. https://www.jtl-software.de/JTL-Wawi-Download (it is only in German, but maybe you can find some useful things or you know someone who can help you you with German software).

This one sould be the best at the moment (have not tested it yet), but a lot of people told me.... The developer will check if it is compatible with TB and maybe we can get it in the TB-store in a few hours !! :) https://www.presta-addons.com/en/prestashop-modules/31-m4-gdpr-compliance-toolkit.html

you have to change it in ALL /mails/ folders (in root and also in your template folder etc....., the best way is to rename them and check which one is sent, this depends on TB and on the theme, see also this here: https://forum.thirtybees.com/topic/1609/welche-mailvorlagen-verwendet-tb/5 its in German and i have got the same problem a time ago). You have to copy the lang.php in each folder, too (if it does not exist regarding a translation into another language).

This is an "old" bug in Presta, too. I dont know what the problem is, but i know the solution, please find above. It should be very easy to do it this way and it will work. Are you using version 1.0.3? Do you have access to your files by FTP? Do you have the correct folder settings (permissions)? What is the error (does not work is not very helpful)?

Download the files from /mails/language and / or from /yourTemplate/mails or use them from your shop-installation which already exists on your computer. then modify the files as you like then upload them into the same folder (make a backup of the original files or rename them....) for FTP upload you can use software like WinSCP or FileZilla to modify the html files you can use e.g. this: https://html5-editor.net/ You do not have to upload these files to a module, only into the correct folder /mails/ and or /yourTemplate/mails done!

this means you can not upload the files by FTP ?

Hi, a better way is to modify the mail template offline (not to use the online translation in BO). Download it to your computer and modify them is very easy and safe, then upload the new version. This could be helpful to modify html: https://html5-editor.net/

Yes i have activate this in BO, but i am not sure if this works. Even it is active in BO, these files are not included in the robots.txt in root folder (and other robots.txt are not noted by search engines). So my idea was to manually include them.

Now is use this and it works in TB: so the solution is to add this to the source: ?content_only=1

@SLiCK_303 maybe you can help me with this: i need to integrate CMS-content into the contact-form.tpl , let's say i have created an CMS content called "privacy2" and i want to integrate this in the form (no checkbox or other things are needed, only integrate the content -plain text- from privacy2 into the contact-form.tpl The content just should appear in a box with similar size than the "message box", and should be scrollable, as it would be about 2 pages full with thext (informations regarding GDPR....). I tried this with: but this loads not only the content of CMS, it loads the whole site into the iframe. I only need the content from the "CMS ID 6" in the iframe. How to do this? thank you

Maybe you know that in Germany the lawyers or consumer advocates can write warnings and penalties to online mercants. They often use scripts for the search with search-engines or do his manually with a piece of text to find such information as ToS, data protection and so on. We want to prevent us of that and do not let those pages be indexed by search-engines.

Hello, as far as i understand, the standard for robots.txt does not know the use of asterisk * I would like to include some links for my own in the robots.txt , as i dont want to let crawlers see our privacy policy, Terms and Conditions, shipping and something like that.... The links are as follows for English and German language, e.g. myABCDEdomain.com/en/info/Terms-Conditions myABCDEdomain.com/de/info/allgemeine-geschaeftsbedingungen so i think i have to include it like this: ``` Files Disallow: /en/info/Terms-Conditions Disallow: /de/info/allgemeine-geschaeftsbedingungen ``` Is this correct? Does this directive means that the url (file) starting with /en/ is prohibited from browsing? To exclude the whole directory, it would be like this: Disallow: /de/info thank you

Hallo, es ist uns in DE ja vorgeschrieben die “wesentlichen Produktmerkmale” auf der letzten Seite des Bestellvorgangs anzuzeigen (daher also im Warenkorb da es im Shopsystem ja nur so geht). Wesentliche Produktmerkmale sind aber oftmals ja nicht nur Inhalt, Farbe, Größe (die ggf. durch Varianten/Eigenschaften ausgewählt werden) - daher meinte ich das mit der Rechtssicherheit so :) und das fehlt halt definitiv in PS und auch in TB. Es ist generell mal zu überlegen: angenommen ich verkaufe Sonnenschirme die einen fixen Durchmesser, Höhe, Stoffbespannung etc. haben, also Variante kann der Kunde aber nur die Farbe auswählen. Nun würde es wohl nicht genügen, daß im Warenkorb steht: "Sonnenschirm" Farbe gelb, sondern es müsste nach unserem Recht vielmehr definierter angezeigt werden im Warenkorb: "Sonnenschirm" Durchmesser , Höhe , Stoff , Farbe gelb, Bei uns ist es so, daß wir die Kurzbeschreibung für die lateinische Bezeichnung unserer Produkten verwenden, angenommen wir verkaufen Wellensittiche, dann steht da also der wissenschaftliche Name als Kurzbezeichnung Melopsittacus undulatus. Und daher können wir die wesentlichen Eigenschaften nicht in die Kurzbezeichnung packen, desweiteren würde es ziemlich doof aussehen (nicht nur in unserem Theme) und ist das Feld "Kurzbeschreibung" mMn auch nicht dafür gedacht. Ich hoffe ich konnte es einigermasse verständlich beschreiben. Wie schon geschrieben, das Modul AEUC hat damit nichts zu tun, ich würde das gerne einfach hart reincoden in die shopping-cart-product-line.tpl

Hallo, naja, die Kurzbeschreibung ist drin sowie Eigenschaften z.B. 'Inhalt: 500ml' mit dem oben genannten Code. Ich hätte aber gerne noch die ersten xx Zeichen der Produktbeschreibung im Warenkorb angezeigt (aus dem Tab der meistens Mehr Info heisst, ggf. mit truncate oder ähnlichem abgekürzt), denn das würde die Rechtssicherheit stark erhöhen. Ohne grossartige Formatierung, einfach als Fliesstext unterhalb vom Produktnamen. Ich denke das müsste noch irgendwie vorher definiert werden, oder welche Idee hättest du dazu? Ggf. habe ich es bisher auch nicht korrekt versucht, denn das war ein bischen try-and-error mit den Untersuchungen aus dem Browser heraus. Hättest du da Codeschnipsel zum probieren?