Country specific forwarding expenses #4
Comments
|
Ich denke, da sollte der Shop auf jeden Fall erweitert werden. Aber diese Einstellungen sollten so einfach wie möglich gehalten werden (sonst artet die Konfiguration des Shops aus, und er ist nicht mehr der einfache Shop), und möglichst international gehalten werden (bei der Staffelung von (2) kann der Shop nur noch in EU-Ländern laufen). |
Das verstehe ich nicht. Eben nicht nur EU. |
|
@XHalbert Du hast oben geschrieben:
Das passt aber nicht für Staaten außerhalb Europas. Falls nicht zu komplex, würde ich die Staffelung benutzerdefinierbar machen. |
|
Staaten außerhalb Europa sind "Welt". So wird es in etwa bei allen Paketdiensten gehandhabt, manchmal ist "Welt" noch weiter unteilt. |
|
Benutzerdefinierbar ist gut.
|
|
Vor vielen vielen Jahren (es ist noch gar nicht so lange her), habe ich das mal so gemacht: |
|
Schöner Shop... |
Das kommt halt drauf an wo der Shop betrieben wird. Läuft er z.B. in den USA, dann ist USA vermutlich Inland/national, und Europa gehört im Zweifel zu Welt. Wie gesagt, falls die Komplexität nicht zu sehr ansteigt, dann sollte der Shop idealerweise möglichst international genutzt werden können. Ansonsten müsste man halt dokumentieren, dass er nur für bestimmte Regionen ausgelegt ist. |
Na ja, deswegen schreibe ich das ja hier. Es ist rechtlich abgesegnet. Außerdem steht noch bei Schritt 1 und Schritt 3 immer darunter "zzgl. Versandkosten" (als Link zu den Versandkosten). |
|
PS: Mit diesem issue würde ich gern eine bessere Lösung anstoßen als die, die ich bisher habe. Notfalls würde ich weiter mit "meinem" Code leben können, und viele andere wohl auch. Aber das ist halt leider nicht gewichtsabhängig und nicht im backend |
|
Hm, ja hier muss unbedingt was passieren. Was ist z.B. wenn ein Klingone etwas bestellt; da dürfte die Auslieferung teuer werden – und wenn man nicht liefert, kommt der vielleicht vorbei und es gibt was auf die Mütze. ;) Na gut, Klingonen sind vielleicht etwas unwahrscheinlich, aber was mit einem Australier oder US-Amerikaner – und ja, ich habe mir gerade was in die U.S.A bestellt – mit den Originaleinstellungen von Ein weiteres Problem: man kann keine Obergrenze für das Versandgewicht angeben. Das erscheint mir auch nicht unproblematisch. |
During the order process, the address of the customer is requested, and all supported countries are offered via a select element. However, this input is not validated on the server, so orders to arbitrary countries could be made. See also #4 (comment).
|
Obergrenze ist für mich kein Problem. Wenn jemand so viel bestellt, pack ich halt zwei Pakete als wären es zwei separate Bestellungen |
Aber dann zahlst du doch doppelte Versandgebühren?! Mir geht es dabei nicht darum, dass man das Paket nicht mehr transportieren kann, sondern darum, dass man doch nicht einfach sagen kann "ab 10 kg kostet es fix 5,– €, egal ob es nun 10 kg sind oder 10 Tonnen" (und ja, mir ist bewusst, dass die Versandgebühren in der Praxis nicht nur vom Gewicht abhängen – 10 kg Daunen kosten wohl mehr als 10 kg Blei, und bei 10 kg Gold ist alles wieder anders, so dass man da Kompromisse machen muss). |
das scheint mir auch kein reales Problem zu sein. Wenn jemand seine Adresse eingibt, und die aber in einem Land ist, das nicht in der Länder-Auswahlliste steht, dann ist die Adresse schlicht falsch (weil das "Deutschland" o.a. kriegt er ja nicht weg) und ich brauche nicht zu liefern |
bei mir ist ab 50,- € versandkostenfrei. Ich kann bis 31,5 kg in einem Paket verschicken. Wenn ich zwei Pakete brauche, ist der Bestellwert vllt. über 200,- €, da kann man schon doppelte Versandkosten von finanzieren. |
Hier mal eine gefakte Bestellungbestätigung (mit einer Version vor dem Fix): Das Problem ist einfach, dass man sich auf clientseitige Validierung niemals verlassen kann. Aber das ist mittlerweile ohnehin behoben.
Okay, sehe ich ein. Zumindest für ein einfaches Shopsystem muss man eben Kompromisse eingehen. :) Bleibt also nur noch das eigentliche Thema dieses Tickets, nämlich länderspezifische Versandkostenstaffelungen. Finde ich nach wie vor sinnvoll; mal schauen wie es zeitlich passt. |
hä, wie hast du denn USA reingekriegt? |
|
Hm, Gedacht ist der Shop ja als "kleiner" und "simpler". Und Martin schreibt ja auch auf wellrad.de:
|
äh nein eigentlich nicht - weil auf die nationalen Versandkosten ein fester Betrag aufaddiert wird, anstatt für verschiedene Länder eine andere Versandstaffel zu verwenden.
warum denn? XH-Shop ist jetzt schon eine tolle Sache, lohnt sich doch weiterzumachen. Man kann ihn klein und simpel nennen - ich nenn ihn klein und fein. Aber na klar, es gibt immer was zu verbessern. Nur dieses Länderding finde ich essentiell. Wenigstens eine Länderzone (EU) würde ich mir schon dringend wünschen. Also ein XH_EU-Shop. Bei einer weiteren Zone (Schweiz, England etc.) käme ja noch hinzu, dass keine MWSt. berechnet werden darf, die zahlt der Empfänger dann bei seinem Zoll, und das geht wahrscheinlich wirklich zu weit. Schweiz bediene ich derzeit nicht, würde ich aber gerne - und die würden wie ich sehe gern meine Sachen kaufen, was ich aber ausschließe. Vllt werde ich mal einen separaten Schweizshop bauen.
von mir aus kein Problem. Ich würde die Änderungen sowieso für mich einfügen wenn XH-Shop keine bessere Lösung hat. |
ist aber eine stupide Arbeit, wenn eh nur ein Notbehelf rauskommt. |
Ich habe einfach in der Browserkonsole die bereits gewählte
Wenn du hier wirklich fix EU meinst, dann bin ich dagegen. Zum einen muss dann das System wissen, welche Länder zur EU gehören, und das ändert sich ja von Zeit zu Zeit. Außerdem gibt es nicht EU-Staaten, bei denen die Dinge aber doch wieder liegen, etc. Spezielle Versandkostenstaffelung für einzelne Länder, oder für eine (oder mehrere?) vom Benutzer zu definierende Gruppe von Ländern fände ich aber schon sinnvoll. |
nein meinte ich nicht |
|
Im Hinblick auf #30 frage ich mich, ob die Versandkostenstaffelung nicht programmiertechnisch vereinfacht werden sollte. Zunächst mal nur eine Idee als Alternative zur jetzigen Lösung: alles als eine Konfig-Option, etwa in der Form: Ist zwar ein bisschen kryptisch, spart aber jede Menge Formularbehandlungscode, und macht die Eingabe letztlich schneller, wenn z.B. viel mehr gestaffelt werden soll. Und für weitere Länder könnte man dann die einzeilige Konfigoption zu einer Textarea machen, in etwa: Dann wären auch Gruppierungen (wie z.B. EU) nicht mehr so wichtig, weil man die Angaben ja recht zügig per Copy&Paste auch für eine größere Anzahl von Ländern machen kann. Man könnte auch Leerzeichen erlauben, um es etwas übersichtlicher zu halten: Und damit die Länderliste selbst ebenfalls im Backend bearbeitet werden kann, könnte man diese doch in die Sprachdateien verfrachten, in etwa in folgendem Format: Die Länderkürzel sind letztlich beliebig und dienten nur der Zuordnung zur Versandkostenstaffelung. |
|
Ich denke, dass das ein Super-Idee ist. |
Auf Fehler müsste geprüft, und diese auch gemeldet werden. Und wenn ich es noch mal überdenke, dann kann das auch beim Speichern der Konfiguration gemacht werden (na ja, genauer gesagt beim Laden, aber direkt nach dem Speichern wird sie ja wieder geladen). Ich arbeite mal was bezüglich der AGB-Seite aus. |
ja
wenn irgendwo (z.B. direkt oberhalb dieses Textfeldes) erklärt ist, wofür "1=" , "3=" , "6=" stehen soll geht denn auch (in kg.):
das in Sprachdatei, und config sprachunabhängig? PS: DHL erlaubt folgende Ländercode-Listen: |
Genau, es geht um die Einheit. Dieses Format ist eine recht direkte Übertragung des bisherigen Formulars; beispielsweise bedeutet Da das für die Konfiguration gedacht ist, könnte eine kurze Info als Hilfetext (?) angegeben werden; ausführlichere Hilfe, wenn nötig, dann halt im Handbuch (aka. Hilfedatei).
Ja, genau.
Das könnte man dann noch ergänzen. Auf jeden Fall denke ich, dass wir die Sprachcodes nicht näher definieren müssen; da kann jeder nutzen was ihm am sinnvollsten erscheint. Hier geht es nur um die Zuordnung (Land → Versandkostenstaffelung), und dann halt die Übergabe.
Das an sich ist kein Problem, aber ich denke inzwischen es ist am besten hier gleich Nägel mit Köpfen zu machen, und eine Systemprüfung einzuführen. Dazu mache ich dann bei Gelegenheit ein eigenes Ticket auf. |
|
Kurze Zwischenfrage für mein Verständnis:
Gut.
Das wird definitiv nötig. Und es wird wahrscheinlich eher ein Handbuch. |
Ja, allerdings dachte ich nur die Ländernamen anzuzeigen (wie bisher). Letztlich ist diese Liste als Ersatz für
Zumindest ein bisschen sollte das Changelog helfen.
Es ist denkbar, das was jetzt in |
Hier wäre zu überlegen, ob in Step 1 prinzipiell keine angezeigt werden sollen, oder wählbar. |
Das ist doch rechtlich nicht haltbar. Wenn falsche Versandkosten ausgewiesen werden, dann nutzt ein Absatz in den AGB, der das rechtfertigt nichts. Du hast doch selbst vorher geschrieben, dass "Inlandsversandkosten" oder "vorläufige Versandkosten" schon im 1. Schritt nicht ausgewiesen werden dürfen. Da wäre es doch viel schlimmer, wenn im 3. Schritt und der Bestätigungsmail falsche Versandkosten als "Versandkosten" ausgewiesen werden. So wie ich es sehe, integrieren wir entweder die abweichende Lieferadresse als individuelle Felder in Version 1, oder wir verschieben die länderabhängigen Versandkosten auf Version 2. Und ja, mir ist klar, dass man eine einfach in den Anmerkungen angegebene abweichende Lieferadresse nicht akzeptieren muss (zumindest wenn man ihn nicht darauf hinweist, dass er dort eine abweichende Lieferadresse angeben kann), aber dann hätte der Kunde vielleicht erst gar nicht bestellt[1] – ich finde das zumindest bedenklich. [1] Ja, hätte er mal die AGB lesen sollen, aber wer macht das schon? |
Erst für die nächste Version, o.k. Aber es auf Dauer so lassen zu wollen, finde ich kurzsichtig. Eine abweichende Lieferadresse innerhalb des Landes kommt wirklich oft vor und müsste meines Erachtens in jedem Fall automatisch erfassbar sein. Ein Shop, der das nicht automatisch verarbeiten kann, kommt wahrscheinlich nur für einen kleinen Nutzerkreis in Frage. Vielleicht käme für den Moment behelfsmäßig in Betracht, bei den Kontaktdaten die Lieferadresse zu erfragen, und unter Anmerkungen bei Bedarf eine abweichende Rechnungs- oder Wohnadresse. Das ist zwar nicht üblich, wäre aber rechtlich o.k. Versandkosten erst in Schritt 3 explizit zu nennen, in Schritt 1 aber nur den Link zu der Versand-Infoseite habe ich schon öfter gesehen und müsste rechtlich zumindest in Deutschland durchgehen.
klar warum nicht - du wirst deine Gründe haben |
Siehe #15 (comment) |
|
Nun gut – Butter bei die Fische. Ganz unabhängig davon, ob nun eine abweichende Lieferadresse explizit abgefragt wird oder nicht, würde ich vorschlagen, dass diese für Version 1 immer im Land der Rechnungsadresse liegen muss, sprich: das Land der Rechnungsadresse kann für die länderspezifische Versandkostenstaffelung verwendet werden. Wenn ihr diese (ggf. zu dokumentierende) Einschränkung nicht akzeptabel findet, dann bitte beschweren! Ansonsten implementiere ich in den nächsten Tagen die vorgeschlagene länderspezifische Versandkostenstaffelung basierend auf dem Land der Rechnungsadresse. |
denke da kann man nicht meckern Jedoch würde ich eine Änderung der Sprachdatei vorschlagen. Bei den Kontaktdaten Lieferadresse und bei Bedarf unter Anmerkungen eine abweichende Rechnungsadresse. |
|
Mir geistert seit ein paar Tagen die "Ausfuhrumsatzsteuer" im Kopf herum. Wäre es daher vielleicht sinnvoll, den Umsatzsteuersatz schon jetzt bei den Ländern festzulegen? Ich kann mir vorstellen, dass es noch ein weiter Weg ist, bis der Shop diese vat-Werte auch tatsächlich verwenden kann. Denn immerhin müssten die Endpreise, die ja incl. vat sind, sich auch ändern. Wahrscheinlich in Step 3 ? |
Frank schrieb, dass das nicht rechtens sei.
Siehe #51. Das Thema würde ich für Version 1 ganz außen vor lassen, und nicht einmal schon bedingt vorbereiten. |
We do no longer show the actual forwarding expenses in the first step of the checkout, mainly to be able to implement #4. We inform the client of this fact and also about the VAT, however.
cmb69
changed the title
|
@XHalbert Bitte testen! |
|
Zur endgültigen Beurteilung warte ich mal lieber Alberts Urteil ab - auch wenn es mir gut und passend aussieht. Was aber genial und userfriendly ist: monospace für die Eingabe. |
Anders hätten wir das so auch nicht machen können. :) |
|
Bin begeistert, wunderbar. Was mir grad aufgefallen ist: "Forwarding expenses up to" 50,00 € |
lässt sich das vllt. "nur national" machen? (und wäre das sinnvoll?) |
|
@XHalbert Beim "keine Versandkosten ab einem bestimmten Warenwert" ist ja der Hintergrund, dass man ab einem bestimmten Warenwert die Versandkosten praktisch ignorieren kann, und umgekehrt dem Käufer einen Anreiz bietet mehr zu bestellen. Ab wann man die Versandkosten ignorieren kann, hängt aber wiederum von den maximalen Versandkosten ab. Da diese nun länderspezifisch sind, wäre es sinnvoll, auch Die Frage ist halt wie: entweder bei |
Das wäre schön simpel. |
|
mit scheint, richtiger wäre, wenn bei Ausland-forwarding_expenses_up_to immer automatisch die maximalen Ausland-Versandkosten auf den eingestellten up-to-Wert addiert werden und die max. nationalen Versandkosten abgezogen. Ob einige Anwender eine "DE=10;CH=20"-Lösung vorziehen würden? Vielleicht sind bei einigen Ländern die Zoll- und Versandformalitäten aufwändiger zu bearbeiten als bei anderen Ländern, und da wäre der Shopbetreiber vielleicht nicht so "großzügig" gestimmt, und fänd diese Lösung flexibler... weiß nicht, ob das jetzt übertrieben ist. Ich könnte mir auch vorstellen "forwarding_expenses_up_to: DE=50;Ausland=70" Auf jeden Fall wäre im Warenkorb der |
|
stimmt, schön simpel wär eigentlich nur "DE=10;CH=20 " |
Auch eine interessante Variante.
Ah, guter Punkt! Vielleicht sollten wir diese Sache doch zurückstellen? Ich denke für Version 2.0 müssen wir uns bezüglich der Länderauswahl sowieso was einfallen lassen (#51). |
wenn du Ausfuhrumsatzsteuer meinst... Nebenbei, ich war jetzt in einem Shop, da kam die Länderauswahl schon im Warenkorb, etwa: |
Na ja, das wäre doch ein ziemlicher Kompromiß, und für den allgemeinen Fall müsste auch noch etwas mehr nachgebessert werden, und die Zeit ist einfach zu knapp. Vielleicht tut's fürs erste auch eine Individualanpassung. Füge zwischen diesen beiden Zeilen doch noch folgende ein:
Ja, so etwas in der Art meinte ich. |
|
ah danke für die "einfache Hilfe" |
Beim Eintragen der Kundenadresse gibt es das Feld "Land", editierbar in lang/countries_de.txt
Versandkosten sind Bestandteil des Vertrags, den der Shopbetreiber mit dem Kunden eingeht, nachdem eine Bestellbestätigung verschickt wurde. Außerdem muss rechtlich der konkrete Betrag vor "jetzt kaufen" verbindlich angezeigt werden. "Höhere Versandkosten erfragen" ist nicht zulässig.
Es gibt ein Addon, bei dem jedem Land ein Geldbetrag zugeordnet werden kann,
z.B. "Österreich~15.10", editierbar in lang/countries_de.txt,
Dieser Betrag wird "im nächsten Schritt" zu den nationalen Versandkosten hinzu addiert.
Leider ist dieser Betrag bisher nicht abhängig von Versandsettings im backend, wird also auch berechnet bei "Versand frei", und ist auch nicht gewichtabhängig.
Setzt der Shopbetreiber den Betrag niedrig an, z.B. für 5kg, so zahlt er bei schweren Paketen drauf, während hohe Zuschläge die Kunden abschrecken.
The text was updated successfully, but these errors were encountered: