Entwicklung von Online-Shop - Was ist unbedingt zu beachten?

[seb]

Einen wunderschönen Sonntagmittag allezusammen!

Ich bin zur Zeit dabei, meinen ersten Online-Shop zu schreiben. Da ich keine bösen Überraschungen erleben bzw. im Nachhinein nochmal das halbe System umschreiben möchte, wollte ich fragen, auf was man bei der Realisierung eines Shopsystems unbedingt achten sollte.

Die Frage betrifft besonders den Bestellvorgang sowie Verwaltung und Verarbeitung der Bestellungen als komplexeste und gleichzeitig wichtigste Komponenten des Systems.

Fehlkonzeptionen, Sicherheitslücken und Bedienungsabläufe, die den Benutzer irritieren bzw. zu unerwünschten Eingaben führen könnten, will ich auf jeden Fall vermeiden.

Beispiel:

Mir field vor ein paar Tagen erst ein, dass der Preis eines Artikels zu einem beliebigen Zeitpunkt auch nach einer Preisänderung noch abrufbar sein muss, um eine Bestellung auch sicher mit den zum Aufgabezeitpunkt gültigen Preisen abzurechnen.
Falls nämlich zufällig genau zwischen Aufgabe und Bearbeitung einer Bestellung der Preis eines in dieser Bestellung enthaltenen Artikels geändert wird, muss die Bestellung trotzdem noch mit dem alten Preis abgerechnet werden.

D.h. man darf den Preis eines Artikels nicht als einzelnen Wert speichern und bei einer Preisänderung einfach überschreiben, sondern muss den gesamten Preisverlauf oder zumindest immer den jeweils vorherigen Preis in der Datenbank behalten.

Was ich suche, sind weitere Fallstricke dieser Art. Vielleicht habt ihr dazu ja was für mich.

Gruß, Seb

[paul123]

Mir field vor ein paar Tagen erst ein, dass der Preis eines Artikels zu einem beliebigen Zeitpunkt auch nach einer Preisänderung noch abrufbar sein muss, um eine Bestellung auch sicher mit den zum Aufgabezeitpunkt gültigen Preisen abzurechnen.
...

...ähm, was sollte das (nach meiner Ansicht) mit einem Shop zu tun haben? Das ist doch eindeutig WAWI? Und sowas wirst du doch nicht in dem Shop reinpacken?

- bzgl. Bestellvorgang (markieren der gelesenen AGB...) kannst du vielleicht einfach z.B. xt-commerce mal die Demo durchprobieren, da sind soweit eigentlich alle relevanten Sachen drin.

[seb]

ähm, was sollte das (nach meiner Ansicht) mit einem Shop zu tun haben? Das ist doch eindeutig WAWI? Und sowas wirst du doch nicht in dem Shop reinpacken?

Ich versteh nicht, was das nicht mit dem Shop zu tun haben soll?

Ich weiß nicht, was Warenwirtschaft bedeutet und wo die Grenze zum reinen Shop-Betrieb liegt. Die Sache wird zunächst mal ganz einfach werden und nur die wichtigsten Funktionen enthalten, allerdings soll das Programm natürlich fertige Rechnungen bzw. zumindest Ansichten der Bestellung ausspucken können, auf denen die Preise der Artikel zum Bestellungszeitpunkt stehen (unbeeinflusst davon, ob einer oder mehrere der betroffenen Artikel in der Zwischenzeit teurer oder billiger gemacht wurde).


Andere Shops hab ich mir schon angeschaut, soweit ist alles klar. Ich dachte bloß, dass vielleicht noch jemand einen "Geheimtipp" zu irgendeinem Aspekt hat.

[dares]

Wir basteln da schon seit über einem Jahr an einem System rum und das Ding wird immer grösser. Man findet irgendwo kein Ende, weil immer neue Ideen neue Versionen folgern.
Ich seh aber dein Problem nicht. Wenn eine Bestellung aufgegeben wird nimmst du die Artikelstammdaten als Vorlage und schreibst da in eine Bestelldb. Dann hast du auch deinen Preis bei der Bestellung und es interessiert dich sonst was, ob der im Nachhinein geändert wurde.

gruß, d.

[paul123]

Ich versteh nicht, was das nicht mit dem Shop zu tun haben soll?
Ich weiß nicht, was Warenwirtschaft bedeutet und wo die Grenze zum reinen Shop-Betrieb liegt. Die Sache wird zunächst mal ganz einfach werden und nur die wichtigsten Funktionen enthalten, allerdings soll das Programm natürlich fertige Rechnungen bzw. zumindest Ansichten der Bestellung ausspucken können, auf denen die Preise der Artikel zum Bestellungszeitpunkt stehen (unbeeinflusst davon, ob einer oder mehrere der betroffenen Artikel in der Zwischenzeit teurer oder billiger gemacht wurde).

...hm, wie dares schon sagt, das ufert dann mal aus.
Das mit den Preisen/nachvollziehen, was wie wo auf die vergangenheit bezogen, mußt du es ja sowieso fürn staat aufheben. Und da ist eine WAWI gut und richtig.
Ok, ist eine Frage des Umfanges der Artikel. Aber richtig mit Historie und allem pibapo... ich kenn da nur vom Lesen intershop.

Andererseits, das mit den Preisen verstehe ich jetzt so nicht ganz - die im shop notierten Preise sind doch dein "Angebotspreis"; will heißen, du kannst doch für Kunden jeweils einen Sonderpreis machen? Daher ist die Historie als Sinn in einem Shop für mich nicht erkennbar. (Es sei denn, du machst darüber eben auch die WAWI). Aber vielleicht verpeil ich das auch etwas...

[Thomas]

mal ganz unabhängig von der Preishistorie, da sehe ich auch kein Problem ...

ich finde, ein Shop muss

1) userfreundlich sein
2) userfreundlich sein
3) userfreundlich sein



alles andere ist nachrangig.

Mich schrecken immer diese Shops ab, wo ich mich spätestens nach dem zweiten Klick schon als Kunde "registrieren" muss, um überhaupt noch weiter zu kommen.
Ich "registriere" mich nicht bei Microsoft und erst recht nicht bei irgendeinem Tante-Emma-online-Shop ...

oder wo ich erst die wichtigen "Klauseln" wie Versandkosten, Mindestbestellwert, Fracht-frei-Grenze u.ä. suchen muss, fühle ich mich auch nicht wohl.

Bestellvorgang: so einfach wie möglich natürlich, nur das notwendige Minimum an Daten vom user abfragen, deutliche und "zielgenaue" Fehlermeldungen, falls fehlende oder falsche Formulareingaben auftauchen (also nicht "Ein Fehler ist aufgetreten, bitte überprüfen Sie Ihre eingaben" sondern dann genau z.B. "Tragen Sie bitte noch Ihre email-Adresse ein")

Bei Kreditkartenzahlungsmöglichkeit ist natürlich verschlüsselter Webspace Plicht.

wg. Preisänderungen: Warum ist das so wichtig? Kannst doch einfach deine Preislisten archivieren. Bestellvorgänge/Rechnungen werden ja wahrscheinlich sowieso direkt auf dem server in Echtzeit verarbeitet. Diese musst du alleine für's liebe FA schon 10 Jahre aufbewahren, also ausdrucken und abheften trotz aller Technik

[seb]

Ich seh aber dein Problem nicht. Wenn eine Bestellung aufgegeben wird nimmst du die Artikelstammdaten als Vorlage und schreibst da in eine Bestelldb. Dann hast du auch deinen Preis bei der Bestellung und es interessiert dich sonst was, ob der im Nachhinein geändert wurde.

Das ist richtig und wäre die zweite Möglichkeit, das Problem zu lösen. Ging mir auch schon durch den Kopf, aber den anderen Weg finde ich theoretisch eleganter, weil die Preise so nicht redundant (einmal im Artikel und zusätzlich in jeder Bestellung) gespeichert werden müssen.

Die sicherste Lösung wäre natürlich, beides zu machen ("doppelt hält besser"). Dann ließe sich eine Bestellung z.B. auch dann noch bearbeiten, wenn assoziierte Artikeldaten - aus welchem Grund auch immer - gelöscht wurden. Wahrscheinlich werd ichs so bauen.

Andererseits, das mit den Preisen verstehe ich jetzt so nicht ganz - die im shop notierten Preise sind doch dein "Angebotspreis"; will heißen, du kannst doch für Kunden jeweils einen Sonderpreis machen? Daher ist die Historie als Sinn in einem Shop für mich nicht erkennbar. (Es sei denn, du machst darüber eben auch die WAWI). Aber vielleicht verpeil ich das auch etwas...

Hm...für mich ist das irgendwie ganz logisch . Ich würds nochmal mit anderen Worten erklären, wenn ich wüsste, wie... Aber dares scheint es ja auch verstanden zu haben...

Eigentlich ging es mir ja auch überhaupt nicht darum. Das war ein Beispiel für ein gelöstes Problem, und wir diskutieren hier darüber, als hätte ich deswegen den Thread aufgemacht .

Ich glaub ich bastel einfach mal weiter und lass euch das Teil am Ende auf Herz und Nieren testen.

Mich schrecken immer diese Shops ab, wo ich mich spätestens nach dem zweiten Klick schon als Kunde "registrieren" muss, um überhaupt noch weiter zu kommen.
...

Bestellvorgang: so einfach wie möglich natürlich, nur das notwendige Minimum an Daten vom user abfragen, deutliche und "zielgenaue" Fehlermeldungen, falls fehlende oder falsche Formulareingaben auftauchen (also nicht "Ein Fehler ist aufgetreten, bitte überprüfen Sie Ihre eingaben" sondern dann genau z.B. "Tragen Sie bitte noch Ihre email-Adresse ein")

An das alles ist gedacht. Bestellen wird auch ohne vorherige Registrierung möglich sein, und der Bestellvorgang ist m.E. auch schon recht benutzerfreundlich.

wg. Preisänderungen: Warum ist das so wichtig? Kannst doch einfach deine Preislisten archivieren. Bestellvorgänge/Rechnungen werden ja wahrscheinlich sowieso direkt auf dem server in Echtzeit verarbeitet. Diese musst du alleine für's liebe FA schon 10 Jahre aufbewahren, also ausdrucken und abheften trotz aller Technik

Ich selbst werden den Shop wahrscheinlich nie nutzen. Er entsteht für einen Autoteilehändler (und möglicherweise zukünftige Interessenten). Von daher betrifft mich das alles garnicht, aber dieser Mensch möchte halt, dass der Shop möglichst automatisch korrekte Rechnungen erstellt - daher das ganze Prozedere.

[dares]

Diese musst du alleine für's liebe FA schon 10 Jahre aufbewahren, also ausdrucken und abheften trotz aller Technik

.. nicht, wenn er sich worms-medien leistet, dann kann er sich das drucken sparen (ca 1000000000000 Drucke und du hast die kosten raus)

[Thomas]

bei meinem Shop (von Stuck gecodet) werden die Rechnungen direkt bei Bestellung vom php-shopscript als pdf erzeugt. Dieses pdf bekomme ich dann als mail und kann es archivieren.

Preis der Ware, Versandkosten, Skontoberechnungen usw. erfolgen einfach immer genau nach den momentanen Einträgen in der db - wenn diese also "gepflegt" ist - und nur das ist online sichtbar - stimmen automatisch auch die Rechnungen.

[dares]

mein (zugegeben etwas sinnloser) Beitrag bezog sich auf die Speicherung von Daten. Entweder man druckt sie aus oder speichert sie auf Worms.

[mike]

@preise: Ich stimme Dares in diesem Punkt zu. Eine volle Kopie ALLER Daten, die für den Geschäftsfall notwendig waren gehören gespeichert - auch wenn diese dann redundant vorliegen. Damit ist es einfach z.b. einen Rechnungsnachdruck zu versenden ohne irgendwo Gefahr zu laufen plötzlich eine Rechnung mit aktuellen Preisen zu versenden, die mit der alten Rechnung nicht mehr übereinstimmen.
Eine Preishistorie finde ich in diesem Bezug oversized.

Ansonsten hat es Thomas eigentlich ganz gut auf den Punkt gebracht.

[fettmme]

Nochmal ein paar Gedanken von mir:
Der Shop sollte ...
- ein Template System verwenden
- ohne Javascript auskommen
- eine effektive Suche haben (vielleicht auch mit Lautwert)
- Schlagwörter zu jedem Artikel verwalten können (wg. Rechtschreibfehlern, usw ...)
- modular aufgebaut sein. So könnte man vielleicht ein anderes Wawi System einbinden.
- die Verfügbarkeit eines Artikels anzeigen können,.

[seb]

So schaut die Sache derzeit aus:

http://www.rotblind.de/kunden/veltuning

Die optische Gestaltung spielt zunächst mal keine Rolle, ebenso ist klar, dass noch einige Features fehlen und das, was es schon gibt, noch ausgearbeitet werden muss.

Ich würde allerdings gerne wissen, wass ihr von der Umsetzung von

1. der Warenkorbansicht und
2. des Bestellformulars

haltet (nochmal: Nicht optisch, es geht erstmal nur um Funktionalität und Benutzerfreundlichkeit) . Kundenaccounts gibts auch noch nicht, es ist erstmal nur "Instant-Order" möglich.

Achja, ihr könnt Kram bestellen, so viel ihr wollt. Ich bitte darum . Ist kostenlos, wird aber leider auch nicht geliefert .

[Terry]

Hallo seb,

hab den Shop gerade mal ein wenig getestet. Vom Aufbau her gefällt er mir, auch dass Du kein "Tabellenfachwerk" fürs Layout benutzt.

Ob ich es gut finde, dass die Bestellung immer oben angezeigt wird, weiß ich nicht.
Einerseits ist damit der Inhalt des Warenkorbs immer gut sichtbar - andererseits verschwinden dann die Artikel sehr nach unten, was bei kleinem Monitor oder langer Bestellliste auch sehr störend sein kann. Vielleicht wäre es doch besser, den gefüllten Warenkorb woanders unterzubringen und anklickbar zu lassen.

Echte Kritik hab ich bei der Dateneingabe:
Telefon ist Pflichtfeld, aber nicht fett markiert im Gegensatz zu den anderen Angaben. Ich war also davon ausgegangen, dass ich keine Telefonnummer angeben muß. Dann kam als Fehlermeldung nur "Fehler, fehler, fehler" - da hätte ich lieber eine Angabe, was genau denn nun falsch ist (von der Formulierung mal ganz abgesehen. ). Ich war mir dann unsicher, ob ich die Straße anders angeben muß (eben Straße/Nr2 wie angegeben) - aber das wars auch nicht. Hat drei Anläufe gebraucht, ehe ich kapiert hatte, dass Telefon Pflicht ist.

Soweit auf die Schnelle, hoffe, es hilft Dir.

[seb]

Ob ich es gut finde, dass die Bestellung immer oben angezeigt wird, weiß ich nicht.
Einerseits ist damit der Inhalt des Warenkorbs immer gut sichtbar - andererseits verschwinden dann die Artikel sehr nach unten, was bei kleinem Monitor oder langer Bestellliste auch sehr störend sein kann. Vielleicht wäre es doch besser, den gefüllten Warenkorb woanders unterzubringen und anklickbar zu lassen.

Der Einkaufswagen soll normalerweise unsichtbar sein und per Klick auf die schmale Zeile ganz oben ein- und ausgeblendet werden (natürlich mit Fallback -falls kein JS da ist, wird er immer angezeigt). Hat das bei dir nicht funktioniert?

Dann kam als Fehlermeldung nur "Fehler, fehler, fehler"

Das wird natürlich noch geändert und

- da hätte ich lieber eine Angabe, was genau denn nun falsch ist

Gibt es normalerweise. Dass die Meldungen bei deinem Test nicht angezeigt wurden, ist ein Bug, der auftritt, weil das System online auf PHP 4 läuft, ich lokal aber auf PHP 5 entwickle. PHP 4 braucht eine einzige Zeile extra, die ich aber bei für die Entwicklung auskommentiere, da sie unter PHP 5 (genau umgekehrt) nicht da sein darf , und ich vergess immer, nach dem Upload diese Zeile wieder zu aktivieren.