Beiträge von Marcus

Trotz Konfiguration, dass das Geburtsdatum angegeben werden muß (Pflichtfeld), kann man das Feld leerlassen, um ein Konto zu erstellen. Wird bei der Prüfung völlig ignoriert (Pflichtfeld)
Wenn man mehrere Pflichtfelder nicht ausfüllt, wird zwar oben im roten Block angezeigt, das das Geburtsdatum im Format dd/mm/yyy angegeben werden muß, wenn man dann allerdings alle Pflichtfelder außer dem Geburtsdatum eingibt, funktioniert die Anmeldung trotzdem ohne Fehlerhinweis.

Desweiteren ist es auch möglich, ein Geburtsdatum in der Zukunft anzugeben wie 01.01.2014.
Hier sollte schon eine Gültigkeitsprüfung vorgenommen werden.
Bei Angabe in der Konfiguration von FSK18 sollte hier auch gleich eine Prüfung auf 18 erfolgen.

Eine Erfasserin hat nur Rechte auf die Produkte.
Sie kann auch nicht auf Bestellungen, das funktioniert.
Allerdings kann sie auf der Adminhome-Seite die Anzeige der letzten 20 Bestellungen sehen.
Die Anzeige dieser letzten 20 Bestellungen sollte mit dem Zugriffsbereich orders verknüpft werden.

Bei Zeitüberschreitung beim Login landet man nicht auf der Startseite, sondern auf der Seite http://www.seite.de/account.php
Wenn man sich nun hier einloggt, dauert der erneute Login unverhältnismäßig lange.
Es geht flotter, wenn man auf Home klickt und sich dann anmeldet.
Der Login über account.php sollte mal dringend optimiert werden.

Ob der Kunde das Bundesland eingeben soll oder nicht kann man ja unter Konfiguration -> Kunden Details festlegen.

Wenn man das Bundesland aktiviert, wird bei der Kontoanmeldung die Eingabe eines Bundesland verlangt.
Das Feld Bundesland ist somit auch im Admin unter Kunden verfügbar, wenn man die Kundenadresse bearbeitet.

Schöne Spielerei, aber immer noch ein Bug aus alten XTC-Zeiten. Das Feld Bundesland wird nämlich auch in die Tabelle orders übertragen. Möchte man die Adressen ändern erscheint das Feld Bundesland jedoch nicht und kann somit auch nicht bearbeitet werden.

Folge: Kunde hat bestellt und Niedersachsen in seiner Hauptadresse angegeben. Bei allen 3 Adressen stand nun:
50000 Hannover
Germany
Das Bundesland Niedersachsen taucht nirgends auf.

Kunde rief dann an, wir sollen es doch bitte direkt an eine Adresse in Spanien schicken. Also in der Versandadresse manuell die spanische Adresse eingegeben und das Land auf Spanien umgestellt.
Nun erscheint in der Versandadresse
ZAMORA, Castilla Y León
49021 - Niedersachsen, Spain

Kann man also nur direkt in der Tabelle orders rauslöschen.

Folgende Verbesserungen sollten vorgenommen werden:
1. Anzeige des Bundesland in Bestellung (delivery_state, billing_state)
2. Anzeige und Editierbarkeit des Bundesland in Bestellung->Adressänderung (customers_state, delivery_state, billing_state)
3. Punkt 1 und 2 gesteuert über die Einstellung in der Konfiguration Kunden Details Bundesland (analog Kundenadresse)

Gesucht wird ein Allrounder aus der Commerce-Seo-Community zur Wartung, Betreuung und Weiterentwicklung diverser Shop-Portale (derzeit 3 Shops, 2-3 weitere in Planung)

Aufgaben:

•Templateentwicklung
•Datenbankwartung
•Update der Releases / Shopwartung
•Entwicklung neuer Schnittstellen und Shopmodule

Anforderungen:
•Excellente Kenntnisse von XTC oder Commerce-SEO, vor allem der internen Prozesse und Abläufe
•PHP, HTML, Java, MySQL, Excel

Nice to have:
•TYPO3, Forensoftware, Wikipedia, Warenwirtschaftsprogramme

Das "Projekt" besteht aus 2 Teilen:

•Eine grössere Anzahl an individuellen grösseren und kleineren Programmmodulen erstellen bzw. Standardmodule anpassen und implementieren.
•Wartung und Betreuung des Shops und der Datenbanken, Einspielen der Releases, Bugfixing etc.

Eine Verfügbarkeit vor Ort ist nicht notwendig, jedoch ist uns eine schnelle telefonische Erreichbarkeit und Reaktionszeit besonders wichtig.

Unseren Hauptshop gibt es seit 8 Jahren.
Besonderen Wert legen wir auf eine langfristige Zusammenarbeit.
Dies ist kein Fulltime-Job, aber ein Job für alle Studenten oder Freelancer.

Ihr wißt ja selbst: Es gibt immer was zu tun

Keine Ahnung, ob das die richtige Kategorie ist, habe keine andere gefunden.
Wollte zu meinen gemeldeten Bugs einen Screenshot zur besseren Anschauung anfügen und hochladen.
Habe das jetzt mehrfach an verschiedenen Rechnern mit unterschiedlichen Browsern und verschiedenen Bildformaten (gif, png, jpg, bmp) versucht, ich bekomme immer die Fehlermeldung:
500 [IOErrorEvent type=“ioError“ bubbles=false cancelable=false eventPhase=2 text=“Error #2038“]

Beispiel: Schweizer ruft an und bestellt telefonisch Ware. Man loggt sich als Admin ein, legt die Ware in den Korb, geht an die Kasse und bucht durch. Dann mit Edit auf die Bestellung und die Kundendaten eingeklopft.
Also überschreibt man die Kundenadresse, die Versandadresse und die Rechnungsadresse.

Für die Berechnung der UMSATZSTEUER ist die VERSANDADRESSE entscheidend, nur leider ist auch dieser Fehler noch in allen Forks enthalten als altes XTC Relikt. Hier wird über die Costumer-ID das Land des Kundenkontos abgefragt, und wenn das Land ein EU Land ist (weil der Admin numal für D angemeldet ist), wird halt MwSt berechnet.......
Das ist falsch, zur Berechnung muß das Land der Versandadresse herangezogen werden.

Weiteres Beispiel: Wenn eine Kundin aus Schweden (EU) eine Bestellung im Shop tätigt, die Rechnung an ihre (zweite) Anschrift in Dänemark (auch EU) haben möchte, aber sie eine Freundin aus Norwegen (Nicht-EU) damit beschenken möchte, dann ist die Lieferung IMMER OHNE Umsatzsteuer, da die Ware die EU verläßt. Das Programm berechnet aber MwSt.

Klar kann man sich nun damit behelfen, den MwSt-Satz bei allen Produkten der Bestellung auf 0 zu setzen, dann wird aber immer noch die MwSt für das Porto berechnet wegen dem Feld Steuersatz im Versandmodul (den Fehler habe ich schon beschrieben).
Ist aber umständlich und nicht sonderlich hilfreich, hier dann auch noch mit Taschenrechner nachzurechnen und die Nettopreise einzutragen.

Ja, schließe mich da survival74 an. Kann ja wohl nicht sein, daß nun jeder Betreiber in Modulen rumpfriemelt, um einen ganz offensichtlicher Fehler zu beheben.
Das wäre sogar abmahnfähig, da klarer Verstoß gegen die Preisangabenverordnung !

Steuerrechtlich ist der Sachverhalt folgender:
Für Waren mit 19% Steuersatz muß auch für das Porto 19% berechnet werden.
Bei Waren mit vermindertem Steuersatz 7% (Lebensmittel, Bücher) darf das Porto auch mit 7% berechnewt werden.
Bei gemischten Lieferungen (40 Euro Bücher zu 7%, 60 Euro andere Waren zu 19%) muß dann aufgeteilt werden, also in diesem Fall 40% der Versandkosten mit 7% und 60% mit 19%.

Dies ist für Shopbesitzer bares Geld, da weniger an Umsatzsteuer abgeführt werden muß. Der Fehler existiert seit vielen Jahren und ich habe das bereits 2004 immer wieder bei XTC moniert. Nun existiert der Fehler in vielen Fork weiter.

Für Shopbesitzer, die AUSSCHLIEßLICH Waren mit 19% oder 7% verkaufen, gibt es keinen Fehler. Für alle, die sowohl als auch verkaufen, geht schlicht Geld verloren durch zu hohe Umsatzsteuerberechnung. Wer also 19% im Versandmodul eingestellt hat, aber regelmäßig auch Waren zu 7% verkauft, zahlt einfach zu viel an Umsatzsteuer.
Sind bei mir einige hundert Euro im Jahr.

Der Grundfehler liegt im ursprünglichen fehlerhaften Design, daß bei den Versandmodulen ein STEUERSATZ hinterlegt werden kann. Das ist absoluter Käse. Also weg mit der Einstellung des Steuersatzes in den Versandmodulen, das muß errechnet werden wie beschrieben anhand der prozentualen Werte der einzelnen Artikel auf den Gesamtbestellwert (ohne Versandkosten).

Schonmal vorab danke für eine möglichst schnelle Umsetzung für das nächste Release.