DRMasterChief

Will there be a solution in next time for the original thirtybees reCaptcha module ? I dont like to use any other.

No nothing like this. The last change in modules was to deinstall "Google Analytics API v3.0.1" - but this does not matter for the reCaptcha. I have installed the API again and tried the reCaptcha without success. But today, the error in BO is: Confirmation: Captcha rejected. The secret key could be wrong. Please, make it work again :)

Hello, Google says the following since the error appears: Wir haben festgestellt, dass auf deiner Website reCAPTCHA-Lösungen nicht überprüft werden. Für reCAPTCHA ist jedoch eine Prüfung erforderlich. Weitere Informationen findest du auf unserer Entwicklerwebsite. https://developers.google.com/recaptcha/docs/verify#api-request So the problem is the API request from thirtybees !? Maybe in combination with this https://forum.thirtybees.com/topic/1922/have-you-changed-the-web-service-api-back-in-tb-version-1-0-4/2 ????

I have the same issue since upgrading to 1.0.5: Recaptcha does not work (unknown) even though the same credentials used to work fine in 1.0.4. Reset, uninstall then fresh reinstall, nothing works...... ...the same here in my 1.0.5 contactform - very bad :( I was that lucky to find a Captcha that works and now these bad news..... (we use it only in contactform)

Hello, Stats module will increase the database in tbguest und tbconnections and it is possible that these will have a hundreds of thousands after a while. Should make no problem or slow down the site, but this depends strongly on your hosting plan and hardware. Site without Stats modula can increase speed for 1-2 seconds. Maybe you will read this: https://gist.github.com/julienbourdeau/cca88e986a75e19488c2397f1386a3dc https://www.prestashop.com/forums/topic/266421-500000-rows-on-ps_guest-sounds-too-big/ But i dont know if Google Stats does also - we dont use this.

We dont need this module - but a big thank you for it ! Great community stuff and a big step forward in this VAT thing.

Cool :) so solved. I also did not know why these tickboxes are so hidden, and they are also twice (in your menu screenshot above and in this section again...). Maybe these tickboxes override the settings in the menu above and a programmer should have a look at this to fix it or to bring some light to us ?! @traumflug ?

Hi again, i have found the solution, theme developer told me (very friendly, thank you): change in shopping-cart-advanced.tpl noDeleteButton=1 to noDeleteButton=0 and cannotModify=1 to cannotModify=0 Now the customer can change the quantity also in OPC. I think this is theme based and no bug in TB, but maybe someone find it useful here too.

Hi, could it be regarding an extra required field in customer - at the lower part - Define additional mandatory fields for this area : ....Please mark the fields that should be displayed as mandatory fields..... newsletter and/or optin just my idea ??

please see https://forum.thirtybees.com/topic/1870/say-hello-to-release-1-0-5

There is no PR at Github :) 1.0.3 > 1.0.5 already done without problems! Thank you for your hint above. Stats Module not installed at the moment, will see if i need this.

Hello, afaik Paypal wants a state for a lot of countries. Many customers do not give that and I do not need it for shipping. I know that sometimes there comes the following error from Paypal when a customer try to order (mostly from Asia): PayPal response:TIMESTAMP -> xxx ERRORCODE0 -> xxxSHORTMESSAGE0 -> Shipping Address State EmptyLLONGMESSAGE0 -> The field Shipping Address State is required xxxCODE0 -> Error In the meantime, i have seen that PayPal wants to have an additional data field with 'state' in some countries (e.g. Mexico or Thailand), which causes the error above. Is this problem also known for thirtybees ? If yes, there should be an workaround which fills 'addressstate' with country code. So this is not empty and the problem is gone. I think it should be in /expresschecout/process.php thank you for your ideas about this!

https://www.paypal-notice.com/de/ with more informations also in German

ok thank you. Can you say that 1.0.5 is a "stable" version? We will go live with our shop in the next time.... and if we do not need any stats, we just don't install the 'Stats Module' ?

ahh ok, but can i do an update from 1.0.3 to 1.0.5 (without step 1.0.4) ? ...think not regarding the database upgrade, i have read now... sorry

can i do the upgrade to 1.0.5 when i am using 1.0.3 automatically by the updater and where to find them ? thank you

My theme has all the xxx-advanced.tpl as the community-theme-default has. Only this one is missing in my theme: order-advanced.tpl-eleazar (and this file contains nothing)

Hello, first i have to say that i do NOT use the standard theme. Now i am playing around with some .tpl and modify for GDPR and also decide to use the normal checkout or OPC - the OPC looks very ok and could be much better for us, but not sure at the moment.... ....not sure regarding this: when i activate the OPC, the customer can not change the quantity or delete an item in the shopping cart at the end of the checkout. Is this correct from shopsystem (tb 1.0.3) or is this a bug caused by my theme? Also there is NO shopping cart, when you click on shopping cart you come directly to the OPC site. If this is the normal thing, it is not very useful. Customer has to go back to the item and change quantity if necessary and also to delete an item is very unpleasent. I already was searching for an demoshop with OPC to try it , but cant find one. thank you

Wir schaffen es immer wieder Dinge auf den Weg zu bringen um sie dann kurze Zeit später zu verschlimmbessern, statt vorher mal genau drüber nachzudenken. Wo gehen denn die Millionen € an externe Berater genau hin? grrrrr :)

Jup, wie ich schon geschrieben hatte ....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. .... Es gibt viele Beiträge von PS zu dem Thema verschiedene Steuersätze, wobei eben die meisten User "falsch denken" oder einen anderen Ansatz haben warum es nicht passt (Versandkosten einstellen ist für viele ja so ein Problem). Keiner hatte aber eine Idee wegen dem AEUC-Eingriff warum das sein könnte oder wofür es gebraucht wird und eine Lösung ist eben nicht vorhanden. @Traumflug denkst du daß da jemals noch jemand dran rumbastelt ?

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....