Jump to content

Wuschel

Members
  • Posts

    737
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Wuschel

  1. https://www.prestashop.com/forums/topic/912867-tax-incl-on-invoice-please/ https://www.prestashop.com/forums/applications/core/interface/file/attachment.php?id=205835
  2. Ich vermute mal, dass PrestaShop zur Laufzeit seine Informationen für den Speicherort der Bilder zunächst aus den Variablen holen will, die in der image.inc.php im Rootverzeichnis stehen. Das würde die Fehlermeldung erklären. Sie müssten in der ps_configuration zu finden sein. Ob man da jetzt so einfach eine externe URL reinschreiben kann, weiß ich nicht.
  3. Das sind Inlands-Briefe mit PRIO(rity), die sich im Modul für alle Briefformate einstellen lassen. Das geht aber nur mit diesem Modul, nicht mit dem alten Brief-Modul Deutsche Post von Silbersaiten, das ansonsten immer noch funktioniert. Und die Warenpost International gibt es ja sowieso mit und ohne Tracking. Hast Du denn im Modul auch die aktuelle Preisliste abgerufen? Das solltest Du regelmäßig tun. Denn nur dann wird die Auswahlliste auch korrekt gefüllt. Wir haben aktuell die Version 1.02 von Silbersaiten im Einsatz, die funktioniert tadellos im Briefbereich. Mit dem DHL-Bereich habe ich keine Erfahrung, aber den scheinst Du ja auch nicht zu nutzen.
  4. Die Frage ist nur: Wie lange noch? Bei eigenem Server dürfte es ihnen egal sein, aber bei Shared Servern haben die Provider halt ein Problem, wenn sie etliche PHP-Versionen zulassen. Das gilt vor allem für kleinere Provider. Aber ich kann @Petruschkaverstehen. Es kann ein Heidenaufwand sein, dauernd upzudaten, vor allem wenn man mehrere Shops hat, die auf der Basis von PrestaShop laufen. Denn wenn irgendwo der schöne Satz "Never change a running system" gilt, dann wohl ganz sicher bei Prestashop. Das wissen wir doch alle zu Genüge. Wären hier die Updates so unproblematisch wie bei Typo3 oder Wordpress, dann würde sich doch niemand - so wie ich in den letzten Tagen - die Mühe machen, einen 1.5er Shop an PHP 7.4 und dann gleich noch an PHP 8.0.5 anzupassen. Auch da war es letzlich einfacher so, als auf die vielen im Laufe der Jahre zuprogrammierten Erweiterungen zu verzichten. Deshalb war in diesem Fall auch ein Umzug auf 1.6 oder thirty bees nie ein Thema. (Letzteres läuft übrigens ohne Probleme unter PHP 7.4, versagt aber bei PHP 8.0.)
  5. Na ja, das sind schon so einige! Aber du wirst dir bei 1.6 und erst recht bei 1.7 einen Wolf suchen, bist du alle Stellen gefunden hast, die du ändern musst. Das ist ja sogar bei 1.5 noch einfacher. Tja, und dann dräut noch PHP 8.0 ... EDIT: Bin vorhin noch mal alles durchgegangen. Bei Prestashop 1.5 und 1.6 sind es etliche Klassen und Controller, von Modulen ganz zu schweigen, wo man Änderungen machen sollte, damit dieses Versionen zufriedenstellend unter PHP 7.4 laufen. Na ja, das tun sie dann aber auch, während es bei PS 1.7 immer noch nicht klappt. 😂 Es gibt übrigens genügend gute Hoster, die den Wechsel keineswegs erzwingen. EDIT: Im Shared Hosting kann es allerdings, wie ich feststellen musste, manchmal auch sehr schnell gehen mit dem Abschalten früherer PHP-Versionen, bei Managed Servern ist da mehr freie Entscheidung drin.
  6. Grundsätzlich: Ich fand ja schon immer, wer 1.7 einsetzt, ist selbst schuld. 😊 Meine Einstellung dürfte hier im Forum bekannt sein, und daran hat sich nichts geändert. Aber das soll jetzt keine reine Polemik werden. Doch auf jeden Fall wird jeder erfahrene User eines ganz sicher unterschreiben können: Bei Prestashop niemals mit dem neuesten Release einsteigen! Das galt schon für alle früheren Versionen, ganz bestimmt aber für 1.7. Das Backend von 1.6 ist ja schon nicht mehr das schnellste gewesen, aber bei bei 1.7 haben es die Programmierer geschafft, in Sachen Performanceverlust noch eine Schippe draufzulegen. So, und nun zur eigentlichen Problemstellung: Ich halte es nicht für zielführend, Fixes wie den von Nemo, die für 1.6 geschrieben wurden, in 1.7 einsetzen zu wollen. Prestashop 1.7 ist eine komplette Neuentwicklung mit einer z.T. völlig anderen Softwarearchitektur. So was geht meistens schief. Ein großer Unterschied zur Version 1.6 ist hier, dass nicht alle Variantendaten in der Seite enthalten sind, daher wird bei jedem Switchen ein Ajax-Aufruf durchgeführt. Dieser Ajax-Aufruf enthält viele Informationen, nicht nur die Bilder und Beschreibungen, sondern auch Bestandsinformationen, Preisnachlässe speziell für die Variante, etc. Kurz gesagt, das betrifft alle Informationen, die sich auf den Artikel/die Variante auswirken könnten. Deshalb geht das System bei vielen Varianten pro Artikel leicht in die Knie. Das Problem wurde schon länger beklagt, darum wurde ab 1.7.7.4 ein Fix eingebunden (der eigentlicht schon für 1.7.5.1 geplant war), um das Updaten eines Artikels zu beschleunigen, das wegen der Ajax-Anfrage alles ausbremste. https://github.com/PrestaShop/PrestaShop/commit/f56d5d730c075ae2aa3c3500c6eb02dc29be20f7 Anscheinend hat das nicht geklappt oder neue Probleme geschaffen, oder irgendein Modul funkt dazwischen. Was weiß ich! Da heißt es dann entweder, abzuwarten oder ein darauf spezialisiertes IT-Unternehmen dafür zu bezahlen, die Probleme zu beseitigen. Prestashop funktionierte noch nie out-of-the-box und eignete sich auch nie für unbedarfte Anwender.
  7. Sicher, aber nicht unter PHP 7.4. Deshalb rate ich @Petruschka auch dazu, einfach den Hoster zu wechseln. Alles andere bringt nichts.
  8. Vergiss es! An meiner Feststellung vor über einem Jahr (s. weiter oben) hat sich nichts geändert. Die Abfrage funktionierte auch mit früheren Prestashop-Versionen nicht.
  9. Es reicht, das Modul User Profile Advanced zu deinstallieren. Dann ist der Fehler weg.
  10. Eigentlich eine Frontend-Übersetzung. Aber das ist ja bekanntermaßen in 1.7 unter 182 verschiednene Übersetzungsdateien trotzdem nicht leicht zu finden. Ich habe mir das vorhin mal in den Übersetzungen auf CROWDIN angesehen. Eigentlich müsste an diese Stelle die Variable "Checkout" ("KAUFEN") stehen [../app/Resources/translations/de-DE/ShopThemeActions.de-DE.xlf]. Stattdessen steht im Template aber eine neue Variable: "Place order". Da es diese Variable aktuell bei Crowdin gar nicht gibt, kann sie aktuell auch nicht übersetzt werden. Die Kommunikation zwischen Programmierern von Prestashop und Verantwortlichen für die Übersetzung hat noch nie doll geklappt. Deshalb zeigt auch die Demo-Version von 1.7 auf Prestashop.com für die deutsche Sprache den englischen Ausdruck an. Im Französischen hieße es dann "passer commande". Nur im Deutschen funktioniert es nicht mit "Bestellung". weil das nicht zulässig ist. Bist du sicher, dass du die Übersetzung nicht selbst "verbrochen" hast? Falls nicht, such in Übersetzungen mal nach "Place order". Oder "Checkout". Oder "order with an obligation to play". Ein ähnliches Problem gibt es ja bei "tax incl.", was an entscheidender Stelle - auch bei dir - nicht korrekt mit "inkl. MwSt", sondern falsch mit "Bruttopreis" übersetzt wird. Auch muss es nicht "ohne Versandkosten", sondern "zzgl. Versandkosten" heißen. Auch hier ist die Variable falsch übersetzt worden. Warum das die deutschen Übersetzer immer noch nicht gemerkt haben, ist mir ein Rätsel. Denn diese Fehler gibt es jetzt schon sehr lange.
  11. Vielleicht solltest du erstmal richtig lesen, dann gründlich nachdenken und auch mal überlegen, was du mit solchen Pöbeleien erreichen möchtest bzw. wirst. Ich habe eine Empfehlung für das für DHL entwickelte Modul mit großem Leistungsumfang ausgesprochen, das im Gegensatz zu deinem seit Jahren auf dem Markt ist und gerade erst wieder upgedated wurde: https://www.dhl.com/global-en/home/digital-partners-integrations/e-commerce-platforms/prestashop.html Und erfreulicherweise mittlerweile auch nichts mehr kostet! Der große Vorteil ist, dass es zugleich auch die Warenpost International und auch alle übrigen Tarife der Deutschen Post gleich mit abdeckt. Denn das ebenfalls von Slbersaiten stammende Module Deutsche Post enthält ab 1.1.2021 keine Tarife mehr, die ein Tracking abdecken. Deshalb wurde es in erweiterter Funktion hier integriert. Das neue Modul dhldp empfiehlt sich also auch für diejenigen unter den Shop-Betreibern, die eher selten Pakete versenden, dafür um so mehr kleinere Warensendungen. Mit einem Modul kann man jetzt die Warenpost International und die neue Warenpost National abdecken. Wer DHL Express mit Trackingverfolgung benötigt, kann auf das seit 2017 erhältliche, ebenfalls kostenlose offizielle Modul von DHL (erhältlich für 1.6 und 1.7) zurückgreifen, das man hier bekommt: https://www.dhl.com/global-en/home/digital-partners-integrations/e-commerce-platforms/prestashop.html https://addons.prestashop.com/en/delivery-tracking/27734-dhl-express-official.html#overview Zu letzterem kann ich aber nichts sagen, da ich es nicht ausprobiert habe.
  12. 😀 Gut gebrüllt, Löwe! Mit so einer wortreichen Verteidigung hatte ich jetzt gar nicht gerechnet. Es war eigentlich nur eine Anregung für User, die vielleicht nicht nur Eigenwerbung von Webdesignern lesen möchten. (Ich habe übrigens nie einen Hobby-Shop gehabt.) Also, nun mal Tacheles: Die kleinen Schwächen von Silbersaiten kenne ich selbst, deshalb musste ich beim Modul auch nochmal Hand anlegen. Aber, wie du schon richtig sagst, für einen Profi ist das nicht mal 30 Minuten Arbeitszeit. Bei PrestaShop Addons hat das aber offenbar nie einer gemerkt, denn Funktionsfehler wurden bei Addons noch nie abgeprüft. Beim "strengen Validierungsprozess" zählen ganz andere Kriterien. Das wird ja schon seit Jahren von Entwickler bemängelt. Den Entwickler-Account bei DHL kann jeder Gimpel kriegen; die Doku auch. Ich hab auch einen. Wer glaubt, dass PrestaShop ohne "Bastelarbeit" zufriedenstellend läuft, irrt sich gewaltig. Davon leben doch schließlich Leute wie du, oder etwa nicht? Nur: Mindestens 80 % aller PrestaShops spielen eben nicht in der Shop-"Profiliga". Schau dich doch mal in diesem Forum um, das seine Glanzzeiten leider längst hinter sich gelassen hat. Die meisten User sind weder an Bezahl-Modulen von Silbersaiten noch von Saxtec interessiert, weil das ihr Budget auf Dauer übersteigen würde. Du kannst gern hochnäsig auf solche "Hobbyshops" herabblicken. Aber, von profitablen Ausnahmen abgesehen, ist das nun mal die Realität bei Presta oder tb. Aber laut lachen musste ich wirklich, als ich das las: Man möchte dir ja gern deine Erfolgsgeschichte glauben, würdest du nicht immer gleich so dick auftragen. 😂 Vor 12 Jahren war PrestaShop noch nicht mal den Kinderschuhen entwachsen. Die allererste Version 0.9 erschien überhaupt erst vor knapp 13 Jahren. nämlich im Februar 2008. Da war PrestaShop aber noch auf Jahre kein Thema, vor allem nicht außerhalb eines kleinen Studentenkreises in Paris um Igor Schlumberger und Bruno Levêque. Selbst die Version 1.4 aus dem Jahre 2011 war aufgrund mangelnder Anpassung an bundesdeutsches Recht und wegen einer grauenhaften deutschen Übersetzung kaum einsetzbar und nur was für Insider. Die Situation änderte sich erst so nach und nach ab 1.5, unter anderem durch eine komplette Neuübersetzung und die deutschen Anpassungen, die zunächst separat, später gemeinsam von der von dir geschmähten Firma Silbersaiten und @Gurkcitys Onlineshop Module - allesamt die Vorgänger des heutigen AEUC. Das war so ungefähr die Zeit, wo du dich erstmals im Prestashop-Forum angemeldet hast, ohne dich in diesen Jahren an der fruchtbaren Diskussion mit irgendwelchen Beiträgen zu beteiligen. Ein Jörg B. von einer Firma Saxtec tauchte da weder als Entwickler noch als Gesprächspartner irgendwo auf - schon gar nicht als jemand, der irgendetwas beizutragen hatte. Ganz im Gegenteil: Bis 2017 erlebte man @Jörg Saxtec, wenn überhaupt, nur als Fragensteller, der wie so mancher Webdesigner sich von Profis im Forum Antworten erhoffte, die er dann vielleicht seinen Kunden als Fachwissen verkaufen konnte. Das kann doch jeder in deiner Foren-Historie nachlesen. ... was du so von dir gibst.
  13. Aber hoffentlich nicht von diesem Modul abgekupfert: https://www.silbersaiten.de/de/prestashop-module/344-dhl-business-portal-connector-deutsche-post.html Das deckt nicht nur DHL, sondern auch gleich die DP mit ab, wird von der Post und DHL empfohlen und läuft unter 1.5 (mit kleinen Anpassungen) bis 1.7. Und das auch noch gratis!
  14. Nein, da ist absolut nichts unübersichtlich. Für das Rechnungsformular in 1.7 gilt genau das Gleiche wie in 1.6: das CSS ist in der Datei invoice.style-tab.tpl gesammelt, die als eine Art Pseudu-CSS-Datei fungiert. Alles noch genau so wie oben von eleazar beschrieben.
  15. Ich glaube, du musst nach den Änderungen suchen, die dein Entwickler gemacht hat. Vielleicht hat er Overrides angelegt. AEUC macht es nämlich richtig.
  16. 😅 Mal abgesehen davon, dass das ein Abmahnungsgrund wäre, da du ja die Höhe der Versandkosten nicht beliebig neu berechnen kannst - ich würde einen so unfähigen Entwickler in die Wüste schicken. So eine Unsinn habe ich ja schon lange nicht mehr gehört.
  17. Die Versandkosten sind und bleiben fix, Nettobetrag und Bruttobetrag. Das, was sich ändert, sind nur die Anteile am MwSt--Betrag, die sich aber immer so addieren (sollten), dass der Bruttobetrag der Versandkosten gleich bleibt. So verhält es ich jedenfalls in 1.6 mit AEUC. Ob das bei 1.7 auch klappt, weiß ich nicht. Die Frage, die du dir allenfalls stellen könntest, wenn das bei dir nicht so ist, wäre wohl: Was läuft in meinem Shop schief?
  18. Da hilft kein Reset, weil wahrscheinlich der Hook an der fraglichen Stelle fehlt und das Modul erst wieder eingehängt werden muss. Schau mal hier: https://www.prestashop.com/forums/topic/938625-visitors-online-not-working-prestashop-1744/?do=findComment&comment=3278136
  19. I wouldn't agree that hints from 2011 or anything linked to Prestashop releases < 1.7.0 would be helpful. Prestashop 1.7 stores the translation items for (in this case German) mails in /app/Resources/translations/de-DE/EmailsBody.de-DE.xlf /app/Resources/translations/de-DE/EmailsSubject.de-DE.xlf Or hopefully most of them, because in 1.7 you cannot always be sure. Those of you who run a version < 1.7 and have some skills in German find everything they need to find translations in a topic moved from this forum to here. But in any case I'd suggest to first use the translation section in your shop's back office.
  20. Ich vermute mal, @Whiley meint damit, dass sich deine Buchhaltung/Steuerberatung nicht mit der geltenden Rechtslage seit dem Amthilferichtlinie-Umsetzungsgesetz vom 30.6.2013 auskennt. Es wäre ratsam, wenn sich die Steuerberatung mit § 14 Abs. 4 Satz 1 Nr. 10 UStG n.F. vertraut machen würde und die entsprechenden Ausführungsbestimmungen beachtet. Der Begriff „Gutschrift“ ist seit dieser amtlichen Präzisierung ausschließlich für Abrechnungen durch den Leistungsempfänger reserviert. Schreibt nicht der Leistende eine Rechnung, sondern rechnet der Leistungsempfänger gegenüber dem Leistenden ab, muss diese vom Leistungsempfänger oder einen ihm beauftragten Dritten ausgestellte Abrechnung die Angabe „Gutschrift“ enthalten. Denn die Nennung des Wortes „Gutschrift“ ist erforderlich, wenn der Leistungsempfänger die Vorsteuerabzugsberechtigung nicht gefährden will. Ob das jetzt wie im amtlichen Sprachgebrauch Rückvergütung genannt wird oder anders, bleibt dir überlassen. Um sicher zu stellen, dass mit dem Rückerstattungsbeleg keine "Gutschrift" gemeint ist, muss einfach nur eine andere Bezeichnung verwendet werden. Möglich wäre auch Berichtigung, Stornorechnung oder Erstattungsbeleg.
  21. Zwei Ideen: 1) Du aktivierst mal den Debug-Modus, um herauszufinden, was hinter dem Fehler 500 (weiße Seite) steckt. 2) Ich vermute, die PHP-Version deines Servers inst nicht mit deiner Prestashop-Version kompatibel.
  22. Rundungsfehler sind aber trotzdem bei solchen Datenbankoperationen nicht auszuschließen, denn der SQL-Befehl ROUND() beherrscht nur das mathematische Runden, während die Prestashop-Funktion ps_round wenigstens versucht, das kaufmännische Runden nachzubilden. Deckungsgleich sind beide Verfahren jedenfalls nicht. Wer sowieso nicht centgenau rechnen will, sondern lieber den Betrag in ganzen Euros ausweist, dem hilft CEIL(tabname.`price`)
  23. Allmählich übersteigt das dann aber die Fähigkeiten des durchschnittlichen Anwenders, @Whiley.Das Problem sind auch nicht die neu eingestellten Artikel - da kann man den Bruttopreis ja von vornherein harmonisieren, sondern die bereits zuvor mit 19 oder 7 Prozent erfassten. Allein um die geht es, und da hat @Claudiocool schon den richtigen Weg aufgezeigt:
  24. Nein, so ist das nicht in Presta. Der Bruttopreis ist an dieser Stelle überhaupt nicht hinterlegt. Der Shop speichert den Nettopreis mit 6 Stellen hinterm Komma, und ein Javaskript sorgt im Back Office für diese Umrechnung on the spot. Zugleich wird sichergestellt, dass der errechnete oder eingegebene Bruttopreis nach dem Speichern mit nur maximal 2 Nachkommastellen dargestellt wird, ganz egal, wieviel du eingibst. Solche Javaskripte gibt es an vielen Stellen im Back Office. (Eines davon ist beispielsweise für den seit etlichen Jahren bestehenden Fehler verantwortlich, dass eine unit_price_ratio für die Grundpreisberechnung nie als 1.000000 abspeichert wird, sondern einen Wert kleiner Null bekommt, wodurch es immer mal wieder zu Differenzen um einen Cent beim Brutto-Grundpreis kommt.) Was Paypal anbelangt, so hängt das eher vom eingesetzten Modul ab, ob es zu Rundungsdifferenzen kommt oder nicht, und weniger vom Steuersatz. Zumindest, wenn man bei der Umstellung alles richtig gemacht und keine überflüssigen Datenbankoperationen durchgeführt hat.
  25. 😁 sei mir nicht böse, aber kann es sein, dass du vielleicht auch nicht verstehst, warum es mit Gurkcitys SQL-Statements nicht klappen kann, das, was er will, zu realisieren? Bei Prestashop kommt am Ende immer ein Bruttopreis mit 2 Nachkommastellen raus, da im Core entsprechend gekürzt wird.
×
×
  • Create New...

Important Information

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