Beiträge von Marcus

Sorry, das ist einfach nur Käse.

WENN das Dein Standpunkt ist, wieso forderst Du dann unseren Chefentwickler nicht auf, UMGEHEND folgendes zu entfernen:
1. Offene Warenkörbe durchbuchen
2. Die Editfunktion zum Ändern der Adresse sowohl im Kundenkonto als auch in der Bestellung

Und die Benutzung mit phpmyadmin oder ähnlichen Tools, mit denen man in der Datenbank Kundenadressen ändern kann, gehört ebenfalls sofort verboten.

Ob ich nun eine Bestellung über "offene Warenkörbe" durchbuche oder mit einem Masterpasswort mich in das Frontend einlogge und es dort durchbuche, das Ergebnis ist das gleiche: eine durchgebuchte Bestellung.
Nach Deiner Argementation macht sich also ein Shopbetreiber schon strafbar, wenn er versehentlich die falsche offene Bestellung über "offene Warenkörbe" durchbucht.
Ob ich Adreßdaten in der Datenbank ändere, im Adminbereich oder im Kundenkonto, das Ergebnis ist auch hier das Gleiche: eine geänderte Adresse.

Zitat

weil ja oft benutzt man ähnliche oder gleiches password auch irgendwo anders!)

Ja, und genau DAS ist der Grund, warum ich meine Mitarbeiter NICHT nach ihrem Passwort frage. Du wiedersprichst Dir selbst.

Da hast Du gründlich etwas mißverstanden.

1. Zum "rechtlichen": Ob ich mich (wie früher) mich in ein Kundenkonto einlogge um die Bestellung durchzubuchen oder nun unter "Offene Warenkörbe" dies tue, macht keinen Unterschied. Wenn das "rechtlich" bedenklich wäre, müßte die Durchbuchfunktion unter "Offene Warenkörbe" entfernt werden. Und in der Praxis: Wenn der Kunde eh nicht zahlt, wieso sollte ich eine offene Bestellung durchbuchen ?

2. Um auszutesten, ob der Mitarbeiter nur wirklich das darf, wozu ich ihn freigeschaltet habe, bräuchte ich sein Passwort.....

3. Ob ich mich nun mit meinem Passwort als Hauptadmin nur in meinen Account oder in alle Accounts einloggen kann, spielt bezüglich "hacken" des somit zum Masterpasswort mutierten Passwort keine Rolle.
Bei 99% aller XTC-basierten Shops ist die Absendemailadresse gleich der Anmeldemailadresse des Shopbetreibers. Wenn ich also hacken will und könnte, einfach bei einem XTC-Shop Bestellung aufgeben, dann hab ich zumindest schonmal den Loginnamen. Und dann kann man munter Passwörter ausprobieren, um in den Shop zu kommen.....

Haben schon ein paar Kunden reklamiert, das mit Chrome im Bestellvorgang nicht auf Paypal weitergeleitet wird.
Zum Glück haben die sich telefonisch gemeldet, sonst sind solche Kunden leider verloren.
Als die dann IE bzw. Firefox verwendet haben, wie wir empfohlen haben, ging es.
Keine Ahnung, ob das Problem nun am Ende der Tastatur sitzt.....;)
oder ob es bei Chrome wirklich ein Problem gibt bzw. ob es benutzerspezifischen Einstellungen liegt.

Schon seit ewigen Zeiten ist die MwSt-Berechnung fehlerhaft und keiner von XTC noch der diversen Forks hat sich in all den Jahren darum gekümmert.
Dabei ist das Thema ganz einfach:
Ob ein deutscher Unternehmer MwSt verlangen muß oder nicht, liegt am Land, in das versendet wird.
Grob vereinfacht:
Versand in EU -Länder: MwSt muß berechnet werden
Versand in Nicht-Eu Länder (für Finanzamt sogenanntes Drittland): MwSt muß NICHT berechnet werden, Nettoverkauf (für den Versand ist dann ein Zollformular bei einer Prüfung durch unser liebes Finanzamt erforderlich als Nachweis)

Um natürlich eine richtige Berechnung durchzuführen, verweise ich auf meine Bugmeldung mit der Aktualisierung der Länderliste.
http://plussupport.commerce-seo.de/showthread.php?t=1200
Wenn Stammdaten nicht stimmen, kann die Software natürlich nicht richtig rechnen, da baut eins auf dem anderen auf.

Problem:
Irgend ein schlauer XTC Entwickler hat die Berechnung am Land des Kunden im Kundenkonto festgelegt, anstatt an dem Land der Versandadresse. Ich hab das immer wieder erfolglos reklamiert.
Bedeutet: Wenn ich eine Mailbestellung eines Amerikaners mit meinem deutschen Adminaccount durchbuche, wird MwSt berechnet, da ja in meinem Account als Land Deutschland hinterlegt ist......
Das bekommt man auch nicht mehr weg. Wenn man die Bestellung bearbeitet und "Bestellung neu berechnen" klickt, ist die MwSt wieder da.
Der Fix muß also nicht nur im Frontend im Shop korrigiert werden, sondern auch im Backend in der Bestellung bei Recalculate

Schön wäre zusätzlich ein kleines Tool, mit dem man in Stapelverarbeitung alle Bestellungen im Shop korrigieren kann, sobald dieses Problem gefixt ist, um den historischen Datenbestand zu korrigieren.

Geldspartip zum Vatertag:
Wenn jemand einen teuren Artikel kaufen möchte, dann einen Shop mit internationalem Versand besuchen der XTC oder einen Fork einsetzt, einfach neues Kundenkonto anmelden und Adresse in einem Nicht-EU Land eingeben (z.B. USA) und eine abweichende Versandadresse nach Deutschland.
Dann spart man sich die MwSt, und in 99% merkt das der Shopbetreiber noch nicht mal bei automatisierten Prozessen...;)

WENN man den Magnalister nutzt, schon
Wie das dort aussieht, weiß ich somit nicht.

Aber nur ein Hinweis, woher die Bestellung kommt, ist zu wenig. Eine richtige externe Bestellnummer nach der man im Shop auch suchen kann würde mehr bringen.

Im alten XTC gab es ja sowas wie "offene Warenkörbe ansehen" oder "Bestellung durchbuchen" gar nicht.
Kunden hatten überwiesen und nicht durchgebucht oder abgebrochen.
Wir haben dann in den Code ein Masterpassword eingefügt. So konnte man also mit der Mailadresse und dem Masterpassword sich als Kunde anmelden und nachsehen konnte, was er im Warenkorb hat bzw. die Bestellung somit für den Kunden durchbuchen.
Sowas gibt es zum Glück nicht mehr.

ABER: So ein Masterpassword vermisse ich z.B. um zu prüfen, ob neu angelegte Mitarbeiter auch wirklich nur das dürfen, was ich eingestellt habe. Mit dem Masterpassword (am einfachsten das gleiche wie der Shoperstelle Kunde 1) und der Mailadresse des neuen Mitarbeiters könnte man sich dann einloggen und die freigegebenen Funktionen prüfen.

Also von billiger.de würde ich die Finger lassen, habe da extrem schlechte Erfahrungen gemacht. Sobald man da Kunde ist, wird sich nicht mehr gekümmert. Und wenn man kündigen will, werden einem nur Steine in den Weg gelegt.
Und die Conversion Rate ist unter aller Sau, da wird nur Deine Kohle verbrannt, sonst nichts.

Das Exportmodul für Preisroboter mit einer veralteten Struktur führt dazu, daß die übermittelten Artikel teilweise gar nicht mehr eingelesen werden.
Ist noch die alte Version V1.

Bitte mal an die V2 anpassen.
Struktur dazu ist hier zu finden:
http://www.preisroboter.de/preisroboter_i…bieterinfos.jsp

Nachdem es ja mittlerweile sogar in Tabelle products die Eingabe der Herstellerartikelnummer zusätzlich zur eigenen Artikelnummer eingegeben werden kann (falls abweichend), sollte man dies bei der Bestellnummer ebenfalls zur Verfügung stellen.

Fast kein Shopbetreiber, der nicht über irgendwelche externen Plattformen wie Amazon, Ebay, Yatego, Rakuten etc. verkauft.
Problem ist bei Rückfragen immer, das der Kunde sich auf die Bestellnummer dieses Portals bezieht. Ohne unsere Excelliste mit den Spalten "Bestellnummer externes Portal" und "Bestellnummer Shop" wären wir da manchmal aufgeschmissen.

Mein Wunsch: in Orders ein Feld "externe Bestellnummer", in die man die Bestellnummer von Amazon etc. eingeben kann.
Nach dieser Nummer sollte man dann natürlich über die Suchfunktion auch suchen können.

Noch schicker wäre es, zusätzlich ein Feld "Herkunft" (oder wie immer man das Kind auch nennen will) zu haben, in das man reinschreibt, ob die Bestellung aus Amazon, Ebay etc. kommt.
Und wenn ich jetzt ein bischen "spinnen" darf: Wenn man dann in der Umsatzstatistik nach diesem Feld auch noch Statistiken erstellen könnte, um zu sehen, was z.B. innerhalb eines Monats aus Amazon, Ebay und dem eigenen Shop an Umsatz etc. gekommen ist.

Wirklich eine gute Idee, ein Feld Hersteller-Artikelnummer zusätzlich zur eigenen Artikelnummer zur Verfügung zu stellen.
Leider kann man weder im Shop noch im Adminbereich nach dieser Nummer suchen.
Also zumindest im Adminbereich wäre die Einbindung dieses Feldes in die Suche überlegenswert.

Gleiches gilt für das Feld EAN.

In der Orderübersicht admin/orders.php gibt es ein Pop-down Menü mit dem man z.B. auf Seite 20 oder 25 springen können soll.
Dies funktioniert leider nicht, man bleibt imer auf der Seite, auf der man gerade ist.
Wenn man also die Bestellnummer nicht mehr weiß, kann man sich also nur seitenweise mühsam durch die Historie blättern.
Ist ein genereller Fehler, getestet unter IE 8 und Firefox.
War auch schon in Version 2.1. fehlerhaft.

Im Shop steht nur: Sie sind sicher, Ihre Software befindet sich auf dem aktuellen Stand.
In einer Stunde oder so wird es vermutlich wieder funktionieren, tritt nur sporadisch auf.
Skripte etc. laufen keine.

Wollte gerade einen Artikel ändern und in wieder auf aktiv setzen, da kam folgende Meldung:

SQL Fehler [256] (1064) You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND pd.language_id = l.languages_id' at line 12

Query: SELECT pd.products_id, pd.language_id, pd.products_name, pd.products_url_alias, l.code FROM products_description pd, languages l WHERE pd.products_id= AND pd.language_id = l.languages_id

Beim Aufruf der Datei /admin/categories.php , PHP 5.2.17 (Linux)

Die Abfrage wurde abgebrochen, kontaktieren Sie den Administrator...

Vielen Dank für den Einbau des schon lange gewünschten Feldes Eikaufspreis.
Jedoch 2 Hinweise:

1. Einkaufspreise der Hersteller sind eigentlich (fast ?) immer NETTO. (Von den fast 30 Herstellern, mit denen wir zusammenarbeiten, gibt es nur Nettopreislisten). Einen Nettopreis Brutto umzurechnen für die Eingabe macht keinen Sinn. Und das die Eingabe eines Nettopreises Brutto behandelt wird und nochmals falsch Netto angezeigt wird, macht auch keinen Sinn (netto vom netto?).
Also weg mit der Nettoumrechnung, das Feld sollte wie eingegeben abgespeichert werden in der Tabelle.

2. Schreibfehler. Da steht Einkauspreis.
Also entweder EinKAUFSpreis oder als Huldigung an den Entwickler EinKAUSCHpreis.
Alles andere macht ebenfalls keinen Sinn.

Merke: Die Welt ist kompliziert genug. Kann mir mal einer plausibel erklären, wieso ich bei der Drogeriekette NETTO die Preise Brutto bezahlen muß ? Das ist doch irreführend ! :p

Den Fehler mit einem ähnlichen SQL-Error hatte ich auch vor ca. 1 Woche. Wollte dann hier ein Posting einstellen, 5 Minuten später ging es dann wieder ohne irgendwelches zutun.

Die Ländertabelle countries wurde seit mindestens 2004 nicht mehr aktualisiert und gehört mal auf den neuesten Stand gebracht.

Die Tabelle gehört zudem um ein Feld "Umsatzsteuerpflichtig" mit den Werten Ja und Nein erweitert. Sobald dieses Feld existiert, werde ich die Informationen zu jedem Land/Insel zur Verfügung stellen, denn gerade die ehemaligen Kolonien einiger EU-Länder (Frankreich, England, Spanien, Holland etc.) haben sehr unterschiedliche Handhabungen bei der Berechnung von Umsatzsteuer, je nach Status innerhalb der EU.
Dann kann man die MwSt-Berechnung dann auch auf eine vernünftige Basis stellen und die falsche alte Berechnung umstellen auf ein neues Verfahren.

1. Flaggen ändern
Die Flaggen gibt es ja erst seit Commerce-Seo, in XTC gab es die nicht. Die Flagge von Libyen hat sich geändert, die neue sieht so aus:
http://commons.wikimedia.org/wiki/File:Flag_of_Libya.svg

2. Länder entfernen
Folgende Länder können entfernt werden, weil es die nicht mehr gibt

[TABLE='width: 500']

[tr][td]

countries_id

[/td][td]

countries_name

[/td][td]

countries_iso_code_2

[/td][td]

countries_iso_code_3

[/td][td]

Kommentar

[/td][/tr][tr][td]

[TABLE='width: 60']

[tr]

[TD='width: 80, bgcolor: transparent, align: right']151

[/tr][/td][tr][/tr]

[/TABLE]
[/TD]

[td]

[TABLE='width: 285']

[tr][td]

Netherlands Antilles

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

AN

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

ANT

[/td][/tr]

[/TABLE]

[/td][td]

Diverse Nachfolgestaaten

[/td][/tr][tr][td]

[TABLE='width: 60']

[tr]

[TD='width: 80, bgcolor: transparent, align: right']61

[/tr][/td][tr][/tr]

[/TABLE]
[/TD]

[td]

[TABLE='width: 285']

[tr][td]

East Timor

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

TP

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

TMP

[/td][/tr]

[/TABLE]

[/td][td]

Heißt jetzt Timor-Leste

[/td][/tr][tr][td]

[TABLE='width: 60']

[tr]

[TD='width: 80, bgcolor: transparent, align: right']236

[/tr][/td][tr][/tr]

[/TABLE]
[/TD]

[td]

[TABLE='width: 285']

[tr][td]

Yugoslavia

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

YU

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

YUG

[/td][/tr]

[/TABLE]

[/td][td]

Diverse Nachfolgestaaten

[/td][/tr][tr][td]

[TABLE='width: 60']

[tr]

[TD='width: 80, bgcolor: transparent, align: right']237

[/tr][/td][tr][/tr]

[/TABLE]
[/TD]

[td]

[TABLE='width: 285']

[tr][td]

Zaire

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

ZR

[/td][/tr]

[/TABLE]

[/td][td]

[TABLE='width: 135']

[tr][td]

ZAR

[/td][/tr]

[/TABLE]

[/td][td]

Heißt jetzt Demokratische Republik Kongo

[/td][/tr]

[/TABLE]

3. Neue Länder

Die nachfolgenden Länder bitte neu mit aufnehmen. Das Adreßformat bei allen Neuen auf 1 setzen. Die Adreßformate gehören auch mal dringend überarbeitet, kommt als eines der nächsten Postings von mir.
[TABLE='width: 500']

[tr][td]

countries_name

[/td][td]

countries_iso_code_2

[/td][td]

countries_iso_code_3

[/td][td]

Flagge

[/td][/tr][tr][td]

Ascension Island

[/td][td]

AC

[/td][td]

ASC

[/td][td]

http://de.wikipedia.org/w/index.php?ti…aint_Helena.svg

[/td][/tr][tr][td]

Åland Islands

[/td][td]

AX

[/td][td]

ALA

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_%C3%85land.svg

[/td][/tr][tr][td]

Saint Barthélemy

[/td][td]

BL

[/td][td]

BLM

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_France.svg

[/td][/tr][tr][td]

Bonaire, Sint Eustatius and Saba

[/td][td]

BQ

[/td][td]

BES

[/td][td]

Keine

[/td][/tr][tr][td]

Congo, The democratic Republic of the

[/td][td]

CD

[/td][td]

COD

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag…f_the_Congo.svg

[/td][/tr][tr][td]

Curaçao

[/td][td]

DW

[/td][td]

CUW

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_Cura%C3%A7ao.svg

[/td][/tr][tr][td]

Diego Garcia

[/td][td]

DG

[/td][td]

DGA

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag…n_Territory.svg

[/td][/tr][tr][td]

Ceuta, Melilla

[/td][td]

EA

[/td][td][/td][td]

http://commons.wikimedia.org/wiki/File:Flag_Ceuta.svg
http://commons.wikimedia.org/wiki/File:Flag_of_Melilla.svg

[/td][/tr][tr][td]

Guernsey

[/td][td]

GG

[/td][td]

GGY

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_Guernsey.svg

[/td][/tr][tr][td]

Canary Islands

[/td][td]

IC

[/td][td][/td][td]

http://commons.wikimedia.org/wiki/File:Flag…ary_Islands.svg

[/td][/tr][tr][td]

Isle of Man

[/td][td]

IM

[/td][td]

IMN

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag…Isle_of_Man.svg

[/td][/tr][tr][td]

Jersey

[/td][td]

JE

[/td][td]

JEY

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_Jersey.svg

[/td][/tr][tr][td]

Montenegro

[/td][td]

ME

[/td][td]

MNE

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_Montenegro.svg

[/td][/tr][tr][td]

Saint Martin (French Part)

[/td][td]

MF

[/td][td]

MAF

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_France.svg

[/td][/tr][tr][td]

Palestinian Territory, Occupied

[/td][td]

PS

[/td][td]

PSE

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_Palestine.svg

[/td][/tr][tr][td]

Serbia

[/td][td]

RS

[/td][td]

SRB

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_Serbia.svg

[/td][/tr][tr][td]

South Sudan

[/td][td]

SS

[/td][td]

SSD

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_South_Sudan.svg

[/td][/tr][tr][td]

Sint Maarten (Dutch Part)

[/td][td]

SX

[/td][td]

SXM

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_Sint_Maarten.svg

[/td][/tr][tr][td]

Tristan da Cunha

[/td][td]

TA

[/td][td]

TAA

[/td][td]

http://de.wikipedia.org/w/index.php?ti…aint_Helena.svg

[/td][/tr][tr][td]

Timor-Leste

[/td][td]

TL

[/td][td]

TLS

[/td][td]

http://commons.wikimedia.org/wiki/File:Flag_of_East_Timor.svg

[/td][/tr]

[/TABLE]

Es ist KEIN Bug.
Die angebliche "Lösung" von Dennis ist nur eine Empfehlung, wie man tricksen kann, aber es wird das Problem nicht langfristig lösen und es wird immer wieder auftauchen.
Wenn Du einen Taschenrechner benutzt hättest, dann hättest Du festgestellt, daß für das Porto keine Mehrwertsteuer berechnet wird.
Weil im entsprechenden Versandmodul das Porto nicht auf "Standardsatz" gestellt ist.

Aber ich erwarte wohl zuviel von Jemanden, der sich großkotzig als Admin und Support bezeichnet, aber 10 Rechtschreibfehler in 3 Sätzen unterbringt.

Das ist KEIN Bug, denn das Problem sitzt immer am Ende der Tastatur.
Also Taschenrechner zur Hand nehmen, und mal die MwSt. für JEDE Position einzeln aus Deinem Screenshot 1 nachrechnen, dann kommst selber drauf, wo der Fehler ist.

Das sagt mir die Startseite des Adminbereichs:
Version: commerce:SEO 2.2.1.0 Plus
Es konnte nicht genau ermittelt werden, welche Version Sie verwenden! Sollten Sie bereits ein Update eingespielt haben, installieren Sie bitte im Admin noch unter Module > Installation / Update den Fix. Hierbei wird auch Ihre Datenbank aktualisiert.
Bitte wenden Sie sich im Zweifel an den Support.

Ich warte hier immer noch auf das Finale Ergebnis des Updates, zumal seitdem auch ein SQL-Fehler bei der Tabelle products auftaucht.

Dann bitte gleich mal für Release 2.4 fixen
Danke
Ich prüf das dann nochmal, ob's auch wirklich funzt.