Jump to content

PatStevens

Members
  • Posts

    106
  • Joined

  • Last visited

Everything posted by PatStevens

  1. Hat es jemand anders mit der version 1.7.x gelöst ooder macht es anders? Heelp
  2. Ok, ich muss wohl detaillierter beschreiben, was gemeint ist. Es geht gar nicht so sehr um die Anzeige der USt. Unter oben genannten Steuerregeln soll die USt. ja gar nicht erst anfallen, ist mein Verständnis. Somit sollte der Shop auch so konfiguriert sein, dass die USt. unter diesen Bedingungen (Händler in nicht EU-Land / Händler in EU-Land, hat aber USt. ID, siehe oben) gar nicht erst erhoben wird. Lässt sich das mit Bordmitteln überhaupt bewerkstelligen?
  3. Hallo Community, habe ein kleines Problem. Wir verkaufen in unserem Shop an Endkunden (B2C) und auch an Händler (B2B). (Den B2B Modus haben wir nicht aktiviert.) Wir haben B2B Kunden in die "Händler" Gruppe zugeordnet, da bekommen sie andere Preise. Jedoch gelten ja bestimmte Steuerregeln, soweit ich weiss: Drittländer (nicht EU Länder) zahlen keine USt. EU Länder auch nicht, wenn der Händler eine USt-ID hat. EU Länder schon, wenn sie keine Ust-ID haben. Auf unseren Rechnungen wird immer die USt angezeigt, was unschön ist. Wie kann man das konfigurieren? Prestashop 1.7.7.* ist unsere Version.
  4. okay... bin ein wenig weiter.. Hatte es nicht mehr im Addons Marketplace gefunden, habe aber im Code die Exception gefunden. Dort mal mehr mitgeloggt. Modul ID ist 27274. Nachgeschaut, es heißt nun also "Cookie-Banner + CMS Modul", okay.. Es wird beim Update versucht das Modul zu laden, was mit einem HTTP 400 beantwortet wird. Man braucht Zugangsdaten? Nun schliesst sich der Kreis.. Es ist ein Kaufmodul.. Und der Shop ist nicht mit dem Addons Marketplace verbunden.. Diese Nichtssagende Fehlermeldung , die man bekommt, finde ich aber wenig hilfreich... Jemand der öfter als ich mal in Presta was macht wäre da sicher schnell drauf gekommen.. Vielleicht einfach das Wörtchen "in" an die Meldung anhängen? "You may need to be logged in".
  5. Hallo zusammen, wenn ich versuche das Modul pscookiebanner zu aktualisieren, bekomme ich folgenden Fehler angezeigt: Ich habe versucht mehr über diesen Fehler herauszubekommen. Im Debug Modus bekomme ich nicht mehr informationen, und in den log-Dateien auf dem Server (/var/log/dev.log und prod.log) steht auch nur genau diese nichtssagende Meldung. Wie kann ich mehr herausfinden bzw. wo schauen, um auf die ursache zu kommen? Ach so.. Ich habe schon versucht das Modul zu resetten und dann zu updaten - mit selben Resultat. Dies ist das Modul..
  6. so habe ich es nun auch gemacht. shop mit allen daten lokal installiert, per 1-click update auf 1.7.7.7 aktualisiert und dann die module aktualisiert - alles bestens
  7. Hallo zusammen, bin noch auf 1.7.6.8, und habe gerade wenig Zeit zum Updaten auf 1.7.7.3 (vermutlich müsste ich mein (eigenes) Theme ebenfalls aktualisieren) und auf SMTP umstellen, testen etc. Kurzum, habe gerade nicht die Zeit dafür (erst in einem Monat). Zur Frage: Einige Module müssten auch aktualisiert werden. In den Release Notes sehe ich immer, dass Bugs gefixt wurden, um das Modul mit 1.7.7 kompatibel zu machen etc. Da stellt sich mir die Frage, ob ich die Module gefahrlos aktualisieren kann, so lange ich noch auf Prestashop 1.7.6.8 bin. Kann man so pauschal nicht sagen, kommt immer aufs Modul an, oder? Wie handhabt Prestashop das denn bei eigenen Modulen? PS: ..und würdet ihr zuerst die Module updaten oder zuerst die Shopversion?
  8. Moin, hab die Nachricht gerade erst gesehen. Vermutlich ist das Thema nicht mehr aktuell. Habe den Modulordner einfach kopiert und in den config*.xml Dateien die Anpassungen gemacht. Und in der Haupt-Modul php. Das war ziemlich straight-forward.. Wie hast du das Problem nun gelöst?
  9. Nachtrag: Hatte mich damals durch den Code gewühlt und die Fehlerursache für meinen Fall dort gefunden: Bei den Steuersätzen wird die Währungsumrechnung auf mit schon umgerechneten Werten gemacht. Das passiert, wenn man mehrere Währungen im Shop hat, und bestellen will mit einer anderen Währung (die nicht Standard-Währung) Ich habe das dokumentiert und an den Modulentwickler gegeben: https://github.com/202-ecommerce/paypal/issues/75 Die bringen die nächsten Tage nen Fix mit Version 5.3.1 raus. Für die Zwischenzeit konnte ich das Problem umschiffen, indem ich dies tat:
  10. Okay, ich bin einen Schritt weiter.. Ich kann sehen, dass das PayPal-Modul versucht die Bestelldaten an PayPal zu geben, wohl Zwecks Vor-Autorisierung: https://api.paypal.com/v2/checkout/orders? ..was jedoch mit einem HTTP 422 Fehler quittiert wird. Desweiteren konnte ich feststellen, dass das Problem nur auftritt, wenn ich eine andere Währung wähle als EUR (unsere Standardwährung). In den Bestelldaten, die an PayPal gesendet werden, gibt es diesen Teil: "purchase_units": [ { "amount": { "currency_code": "EUR", "value": "54.90", "breakdown": { "item_total": { "currency_code": "EUR", "value": "47.33" }, "shipping": { "currency_code": "EUR", "value": "0.00" }, "tax_total": { "currency_code": "EUR", "value": "6.34" }, "discount": { "currency_code": "EUR", "value": "0.00" } } }, da die Summe von Steuern und Artikelpreisen nicht der Gesamtsumme entspricht, denke ich, dass PayPal ablehnt. So konnte ich es auch an anderen Stellen lesen.. Nur warum zum Geier ist der Steuersatz bei anderen Währungen so anders?
  11. Wie es scheint, gibt es immer noch keine Abhilfe seitens des Modulentwicklers. Haben nun auch das Problem, seit einigen Tagen, gefühlt erst, seit wir auf Prestashop 17.6.8 aktualisiert haben. Die Einstellung bezüglich Rundung ändert nichts, und ist bei uns eh schon so gesetzt. Das Schöne ist, es gibt nur für einige Kunden diese Probleme, scheinbar für Kunden, aus bestimmten Ländern. Konnte den Fehler erst nachstellen, indem ich eine Kopie des Shop lokal installiert habe und mit einem dieser Kunden versucht habe auszuchecken. Bekommen ebenfalls diese schöne Javascript Fehlermeldung: bottom-10b833154.js:2020 Uncaught ReferenceError: modePPP is not defined at HTMLDocument.<anonymous> (bottom-10b833154.js:2020) at u (bottom-10b833154.js:39) at Object.fireWith [as resolveWith] (bottom-10b833154.js:39) at Function.ready (bottom-10b833154.js:39) at HTMLDocument.H (bottom-10b833154.js:39) Werde morgen mal versuchen, die API Accounts zu löschen und neu anzulegen.
  12. Hallo zusammen, in dem Shop, den ich betreue können auch Händler kaufen, auch aus dem Ausland. Es sollaber nur für deutsche Händler die MwSt. ausgewiesen werden auf den Rechnungen, auf den Rechnugnen ausländischer Kunden nicht, weil diese wohl auch nicht anfällt. Frage 1.) Habt ihr das irgendwie hinbekommen? Nach einer Recherche gibt es wohl weitere Einstellungsmöglichkeiten, wenn man den B2B Modus aktiviert. Ich habe aber keine Doku dazu gefunden, was dieser Modus bedeutet, bzw. welche Änderungen dadurch im Shop gemacht werden. Frage 2.) Weiß da jemand mehr, bzw. gibt es Doku dazu von prestashop? Cheers, Pat
  13. Das hab ich auch genommen. Aufpassen musst du hinterher bei den migrierten Passworten, siehe: ..denn sonst können sich deine bestehenden User nicht mehr einloggen. Passwort vergessen Funktion geht dann zwar, aber die "alten" Passworte werden nicht erkannt, so lange du das nicht anpasst.
  14. hatte auch ähnliche probleme, das update von 1.6 auf 1.7 durchzuführen. es gab offizielle anleitungen, mit migrationsscripten, die für mich nicht funktionierten. ich hab das update letztlich dann so durchgefüht, dass ich auf einem virtuellen host (dev.meinshop.de) einen sauberen, 1.7 shop neu installiert habe. diesen dann eingerichtet, module, theme etc. (das alte theme wirst du nicht nutzen können. hab selbst eines gebaut, auf basis des classic themes, weil mein kunde doch sehr spezifische wünsche hatte..) anschließend ein migrations-modul gekauft (gibt mehrere, will keine werbung machen, falls du wissen möchtest welches, gern per PM) und die daten (artikel, kunden, bestellungen, etc) migriert. klar gibt/gab es hierbei auch ein paar kinderkrankheiten, das war aber machbar. der shop läuft wie am schnürchen und ich bin sehr froh mit der 1.7. auch bin ich froh, schon die ausgereifte 1.7er version nutzen zu können. die ersten waren wohl recht fehlerbehaftet. hoffe, du hast vorher ein backup gemacht, welches du inzwischen wieder einspielen konntest..
  15. Ganz so ist es bei mir nicht. Bin dort hin gegangen, wie du es beschrieben hast: ..leider steht dort etwas anderes drin. Benutzt im Template wird immer noch "SONDERPREIS!". (Cache habe ich gelöscht, jo) benutze ein selbst erstelltes Template, welches auf dem classic-Template basiert.
  16. Theoretisch könnte jemand, der deinen Session Cookie klaut, damit von einem anderen Rechner in dein Backoffice (zumindest, so lange die Session gültig ist), wenn ich es richtig verstanden habe. Jetzt ginge es daran, herauszufinden warum die IP-Adressen nicht übereinstimmen. Nutzt du ein CDN auf dem neuen Server o.Ä.? Das wäre ja theoretisch eine Erklärung
  17. ..und beim Serverumzug habt ihr ja nicht den alten Cache mit umgezogen, oder? Cache im Prestashop hast du ja sicher schon gelöscht
  18. Hilft es, diese Option einmal auszuschalten? (IP-Adresse des Cookies überprüfen).. Ist unter Erweiterte Einstellungen / Verwaltung.
  19. Die POSTs (sind normale) schlagen wahrscheinlich fehl, weil du da schon keine Session mehr hast (nicht mehr eingloggt bist). Ist aus der Ferne schwer nachzuvollziehen Kannst du mal in einem Inkognito Fenster dich einloggen? Da dürften ja deine Browser Plugins nicht mitlaufen, wenn du das nicht explizit erlaubt hast..
  20. Wenn du eingeloggt bist, bevor du auf Bestellungen klickst, lösche mal die Einträge in dem Chrome-Developer-Tool. (das ist dieses kleine Verbotsschild-Symbol, links neben den Häkchen). Dann klicke auf irgendeinen Link (Bestellungen z.B.), der erste, dann aufgezeichnete Request ist evntl. interessant. Der wird wohl in einem 30* Redirect enden. Wenn du auf diesen klickst kannst du mal schauen, was da mitgesendet wurde, z.B. die Cookies (Hast du vllt. ein Plugin, welches die blockiert am laufen?) In den Fehlerlogs steht nichts? (Im backend und auf dem Server)
  21. Hallo zusammen, ich finde eine bestimmte Übersetzung nicht, bin da etwas überfragt. Wenn man einen Artikel als "Sale" kennzeichnet.. ...dann sollte dieser in der Artikelansicht entsprechend gekennzeichnet sein. Die Translation dafür im Deutschen lauten "Sonderpreis!". würde das gern ändern in "Sale". Leider konnte ich es im Backoffice weden in den Backoffice- noch in den Theme- oder Sonstigen Übersetzugnen finden. Ich konnte feststellen, dass die Übersetzung hier definiert ist: app/Resources/translations/de-DE/ShopThemeCatalog.de-DE.xlf <trans-unit id="700e90e940e7f1fb938b0fda5137f38b" approved="yes"> <source>On sale!</source> <target state="final">Sonderpreis!</target> <note>Line: 444</note> </trans-unit> Wenn ich das in diesen Files ändere, wird es beim nächsten Update überschrieben. Sehe zwei Wege, von denen ich bei beiden nicht weiß wie: Übersetzung via Template Ich nutze ein eigenes Template. Darin gibt es durchaus einen Translations Folder. Darin könnte ich durchaus eine Kopie von ShopThemeCatalog.de-DE.xlf ablegen. Allerdings würde ich dann alle Translations aus der Datei überschreiben (und keine Updates mehr mitbekommen). Übersetzung hinzufügen im Prestashop-Admin Aber wie... Habe die Translation nicht gefunden. Für Hilfe bin ich dankbar
  22. Versuche mal im "Netzwerk" Tab der Chrome Developer Tools nachzuvollziehen was passiert, wenn du wieder zum Login weitergeleitet wirst. Gibt es z.B. einen Redirect auf "/"? Unter Umständen macht Chrome alles richtig, und im Firefox ist ein 301-Redirect gespeichert, wodurch du fälschicherweise drinbleibst Dabei würde ich die beiden unterstrichenen Häckchen setzen. Disable Cache stellt sicher, dass nichts aus dem Browsercache genutzt wird, und Preserve Log, stellt sicher, dass die Requests unten nicht gelöscht werden bei einem neuen Pageview.
  23. ..dachte ich auch zuerst. Offiziell ist das aber okay, siehe https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/
  24. Die ps_connections kann recht groß werden mit der Zeit. Anscheinend wird das Zeug darin eh nur für Statistiken benötigt, siehe..
×
×
  • Create New...

Important Information

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