Whiley

"Neues Product" wird über das "creation-date" gesteuert, wenn du dich mit Datenbanken auskennst, kannst du das Datum von Hand auf ein älteres verändern. Hier wird eine einfache sql-Afrage dafür erklärt: https://github.com/PrestaShop/PrestaShop/issues/18823 Es gibt aber auch Module zum einstellen des Datums, abhängig von deiner Shopversion frei oder als Kaufmodul, z.B. hier: https://addons.prestashop.com/en/additional-information-product-tab/46213-product-date.html Grüsse Whiley

Hallo GrinGEO, wir arbeiten bei vielen Shops mit einem bashscript (cronjob getriggert) sichern aber immer die gesamte Datenbank mit mysqldump, gzip zum komprimieren und lftp zum übertragen. Aber über mysqldump könntest du natürlich auch einzelne Tabellen sichern: mysqldump db_name table_name | gzip > table_name.sql.gz oder wenn du die where-Bedingung einsetzt auch nur Teile einer einzelnen Tabelle: mysqldump --where='where_condition', -w 'where_condition' Erklärungen dazu: https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html Aber es gäbe daneben auch fertige Lösungen: https://sqlbak.com/mysql Grüsse Whiley

Eigenartige Kunden? Aber auch das ist kein Problem, dann werden sie einfach wie Endkunden behandelt (löschen der Umsatzsteuer-ID) und alles stimmt.

Aber das ist ja genau die B2B- Anwendung wie sie in Prestashop automatisch richtig gemacht wird. Wenn du in deinem italienischen Shop an einen italienischen Händler verkaufst muß die MwSt verlangt werden, wenn du aber das gleiche Produkt an einen Händler in Deutschland schickst brauchst du keine MwSt zu verlangen - und genau so macht es der Shop. Grüsse Whiley

Als workaround denkbar wäre auch, daß du die betroffenen Länder mehrfach anlegst also Deutschland und Deutsch-Land (wobei Deutschland das schlechte Beispiel ist, hier gibt es definitiv keine individualisierte Umsatzsteuer) und du dort den MwSt-Satz variierst. Aber ich bin einfach neugierig, für welches Land willst du das denn tatsächlich einsetzen? Grüsse Whiley

Hallo Massimo333, ohne daß du selbst codest kommst du da nicht weiter. Aber wozu sollte das gut sein. Wie auch in den anderssprachigen Foren in denen du die gleiche Frage gestellt hast bereits darauf hingewiesen wurde, gibt es den Fall individualisierter Mehrwertsteuersätze pro Kunde nirgends. In deinem Beispiel im ersten Post klingt das ja so als wolltest du tatsächlich zwischen keiner Umsatzsteuer und einer Umsatzsteuer unterscheiden. Diese Unterscheidung liesse dann für gewebliche und nichtgewerbliche Endverbraucher schließen, und diese Unterscheidung kannst du ja einstellen (Eingabe einer gültigen USt.-Identnummer etc). Grüsse Whiley

Der Shop macht das so richtig! Wenn du entgegen den Steuerregeln trotzdem 19% mehr für den Versand ins (nicht EU-)Ausland berechnen willst, mußt du halt von vorn herein auf den Netto Versandkostenbetrag 19% draufrechnen. Was ist denn die Hintergrundüberlegung deiner "etwas eigenartigen" Frage?

You need a .htaccess file at your old domain domaninA.com.br with the content: RewriteEngine On RewriteCond %{REQUEST_URI} (.*) RewriteRule ^(.*)$ https://domainB.com.br/$1 [L,R=301] Of course, you have only success If the new domain matches exactly the old one and if the rewrite-mod is activated at your server. Whiley

Verwende einfach 2 unterschieddliche Nummernkreise, einen Für ebay und einen für den Shop. Du mußt ja lediglich darauf achten daß es eine Rechnungskennzeichnung nicht doppelt gibt. Also z.B. EB4711 (für ebay) und FA4711 (für den Shop. Wenn du es perfektionieren wolltest, integrierst du ein Warenwirtschaftssystem und schreibst alle Rechnungen darüber. Und bei all deinen Überlegungen zur Rechnungserstellung überprüfe doch mal ob Shop und ebay überhaupt die gesetztlichen Anforderungen, die notwendig wären (Inhalt, Unveränderbarkeit, Aufbewahrungspflicht etc), erfüllen! Grüsse Whiley

Redirect /research?controller=search&s=brand https://www.domainname.com/5_c-brand?

Es könnte schon Performance-Probleme geben (abhängig vom Server) aber es gibt noch jede Menge anderer Weiterleitungsmöglichkeiten (PHP-script oder Module). Das Thema gabs ja schon öfters, z.B. hier: Grüsse Whiley

Ja oder eben den FORK (TB), der das Modul von vorneherein integriert hat. Ich denke, da es ja eine immer gleichbleibende Änderung der url ist (wegschneiden der id) müßte das doch automatisierbar sein (Excel). Grüsse Whiley

Hallo, Ursache für das sich ergebende Problem ist ja, daß du (noch) die IDs in den Artikel-Links mitführtst. Das solltest du jetzt, wo du sowieso Änderungen vornimmst, als erstes korrigieren um diese Probleme in Zukunft zu vermeiden (für deinen 1.6.1er Shop gibts ein kostenloses Modul auf Github oder du wechselst zum Fork). Die sauberste Lösung wäre dann eine Weiterleitungstabelle (.htaccess / 301 / alte url auf neue url) anzulegen, macht zwar ein bischen Arbeit, aber du hast gute Chancen SEO-Einbußen zu vermeiden und vor allen Dingen gehen dir auch deine externen Backlinks nicht verloren. Grüße Whiley

Der Europäische Gerichtshof hat mit diesem Urteil tatsächlich die Tür geöffnet für Schadenersatzforderungen bei Datenschutz-Verstößen, dann wenn ein immaterieller Schaden (man hat sich erheblich geärgert etc) nachgewiesen wird. Deutsche Gerichte hatten soetwas bisher immer abgelehnt! Der Titel dieses thread "Kein Schadensersatz bei Datenschutzverstoß" ist in der Tat irreführend!

Das mit dem Bundesland hat nichts mit dem Problem zu tun, generell ist es aber sicher sinnvoll die Abfrage danach herauszunehmen. Welche Steuerregel hast du beim Artikel hinterlegt? Falls DE Standard (19%) überprüfe zunächst ob bei dieser Steuerregel Italien ebenfalls mit 19% erfasst ist. BO-->Lokalisierung --> Steuerregel --> DE Standard (19%) --> bearbeiten Grüsse Whiley