Jump to content

PatStevens

Members
  • Posts

    106
  • Joined

  • Last visited

Posts posted by PatStevens

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

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

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

  4. Hallo zusammen,

    wenn ich versuche das Modul pscookiebanner zu aktualisieren, bekomme ich folgenden Fehler angezeigt:

    Quote

    app.ERROR: Ausnahmefehler im Modul pscookiebanner bei upgrade: Error sent by Addons. You may need to be logged.

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

    image.png.bf5d11f7e1708c84c60ea63c1abb9055.png

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

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

    Quote

    Could you please check the setting in the "Payment"-"Preferences" - "Currency restrictions".
    If you have the "Shop default currency" selected for PayPal, please change it to "Customer currency". It should fix the issue. Could you confirm please?

     

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

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

     

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

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

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

  12. 3 hours ago, Dampfer-Hardware said:

    Also in den Logs steht nichts...
    Weder auf dem Server noch im Backend.

    Gelöscht im Developer-Tool habe ich auch schon.

    Folgender Screen kommt bei mir wenn ich auf Bestellungen klicke.
    Bei einem Bekannten läuft alles wie es soll über Chrome wenn er sich ins BO einloggt. Komplett ohne Fehlermeldungen.

     

     

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

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

  14. Hallo zusammen,

    ich finde eine bestimmte Übersetzung nicht, bin da etwas überfragt.

    Wenn man einen Artikel als "Sale" kennzeichnet..

    image.png.790aa015ce1046f38a7e9464f8897343.png

    ...dann sollte dieser in der Artikelansicht entsprechend gekennzeichnet sein.

    Die Translation dafür im Deutschen lauten "Sonderpreis!".

    image.png.44db61863a0add90f48d268dee3223f9.png

    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:

    1. Ü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).
       
    2. Übersetzung hinzufügen im Prestashop-Admin
      Aber wie... Habe die Translation nicht gefunden.

    Für Hilfe bin ich dankbar :)

  15. 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 "/"?

    image.png.efca1b86ce3506aa85bc427e5300d00f.png

     

    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.

     

  16. 1 minute ago, rictools said:

    Ich frage mich auch gerade, ob PHP 5 für aktuelle Prestashop-Versionen nicht vielleicht zu alt ist, wenn problemlos möglich würde ich auf PHP 7.2 umstellen.

    Was passiert denn, wenn du unabhängig vom Update eine Sicherung der Datenbank erstellst?

    ..dachte ich auch zuerst.
    Offiziell ist das aber okay, siehe

    https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/

×
×
  • Create New...

Important Information

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