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

Worauf möchtest du denn hinaus? Falls dein italienischer Kunde gewerblicher Abnehmer ist (USt-ID ist eingetragen) zahlt er richtigerweise 0% MwSt. Falls dein italienischer Kunde Endverbrauer ist und du im Jahr mehr als 10000 Euro mit eu-Kunden Umsatz machst mußt du die italienische MwSt (22%) berechnen, falls du weniger als den Schwellenwert Umsatz machst mußt du die deutsche MwSt (19%) berechnen. Für alle diese Möglichkeiten gibt es Module bzw Einstellmöglichkeiten im BO. Welcher Fall trifft zu? Grüsse Whiley

Leider nein. Wenn die Stornorechnung (früher Gutschrift) fälschlicherweise über 7 Euro statt 7000 Euro erstellt wurde gibt es nur die Möglichkeit - vorausgesetzt du kennst dich ein wenig mit mysql aus - das direkt in der Datenbank zu korrigieren. Aber Vorsicht, vorher Sicherung machen, du findest die Stornorechnungsbeträge (Brutto und Netto/alle abändern) in den Tabellen ps_order_slip und ps_order_slip_detail. Grüsse Whiley

Die Entscheidung des ESDA stammt zwar aus dem Jahr 2022 wurde aber erst vor wenigen Tagen veröffentlicht; es ist also zu erwarten, daß es auch noch Anpassungen auf den diversen Rechtsseiten geben wird. Mag korrekt sein, AGB-Häkchen ist aber überflüssig (BGB) und hemmt den Bestellablauf (Abbrüche). Ein Hinweis auf die AGB dürfte langen: https://www.prigge-recht.de/onlineshops-formulierung-fuer-den-hinweis-auf-die-agb/ Entscheident ist aber, daß das ohnehin sinnfreie Kontrollkästchen bei den Hinweisen auf die Datenschutzerklärung nicht sein darf.

Bei der Checkbox für die AGBs ist wohl klar ist, daß man sie nicht braucht, in einigen Rechtsforen findet man aber Hinweise, daß man sie prinzipiell verwenden könne. Anders bei der Checkbox für die Bestätigung für die Datenschutzhinweise, diese ist völlig sinnfrei und nun eben auch - wenn ich die Ausführungen des EDSA richtig verstehe - nicht rechtskonform. Der EDSA führt das ja sehr ausfürlich aus!

Alle die sich noch immer beim Checkout die Datenschutzhinweise akzeptieren lassen bzw eine Zustimmung zu diesen verlangen sollten sich das jetzt veröffentlichte Urteil des EDSA durchlesen: https://edpb.europa.eu/system/files/2023-01/edpb_bindingdecision_202205_ie_sa_whatsapp_en.pdf Einen Kommentar dazu gibt es hier: https://www.delegedata.de/2023/03/edsa-zustimmung-zu-datenschutzhinweisen-als-verstoss-gegen-grundsatz-von-treu-und-glauben-art-5-abs-1-a-dsgvo/ Grüsse Whiley

Die fonts werden i.a. in den css Dateien über @import nachgeladen. Du solltest dir also alle css-Dateien anschauen. bei Leo sehen die potentiellen Nachlader z.B. so aus: .../themes/leo_tea/modules/appagebuilder/views/css/fonts-cuttom2-1.css Grüsse Whiley