Nachdem die Basis des Bestellprozesses steht, Bestellungen verschiedene Status haben können und auch das Notification Center 2 integriert ist, beschäftigt mich noch ein fast philosophisches Problem: bestellt oder nichtbestellt, das ist hier die Frage.
Gemäss der Button-Lösung heisst der letzte Schritt im Bestellprozess ja meist Kostenpflichtig bestellen. Nach Klick dieses Buttons werden Käufer:innen zum Zahlungsanbieter weitergeleitet. In Isotope war es bisher so, dass Bestellungen nur dann gespeichert wurden, wenn diese Zahlung auch erfolgreich war, obwohl im Prinzip bereits einem rechtlich bindender Kaufvertrag zugestimmt wurde. Bei Zahlungsabbruch wurde die Bestellung verworfen, es war selber für Shop-Betreiber:innen nicht nachvollziehbar, welche Bestellungen nicht abgeschlossen wurden.
Aktuell überlege ich mir, ob das so bleiben soll, oder wie eine Alternative aussehen würde. Für das (neue) System wäre es einfacher, wenn eine Bestellung einfach da ist, sobald man den Button klickt (bzw. eben dann, wenn sie per PHP erstellt wird). Es würde ausserdem die Möglichkeit schaffen, nicht-abgeschlossene Bestellungen bei den Kunden nachzufassen und vermutlich einiges noch zu verkaufen. Ob manuell oder irgendwann automatisiert, ist dann eine andere Frage.
Allerdings gibt es auch einige potenzielle Probleme: wenn viele Kund:innen den Zahlungsprozess abbrechen, ergibt das viele Leichen im Backend. Meist vermutlich unnötiger Mehraufwand für Betreiber:innen, insbesondere von kleinen Shops. Auch eine Bestellungs-Mail (an den/die Betreiber:in) bedeutet dann ja nicht automatisch, dass ein Produkt versendet werden kann. Das war bisher auch so, wenn man z.B. Vorkasse anbot, aber nur mit Kreditkarten halt eben nicht. Würde man die Mail erst bei Bezahlung senden, erfährt man wiederum nicht mehr, was alles bestellt wurde.
Ein weiteres Problem ist die Bestellnummer in Isotope. Einige werden wissen, dass man im Backend die Datenbank-ID und die Bestellnummer sieht. Vor allem, weil die Bestellnummer erst bei Zahlungsabschluss generiert wird – und somit an Drittsysteme (z.B. PayPal) nicht als Referenznummer übermittelt werden kann. Dort braucht es die Datenbank-ID, was schon eher unschön ist. Wäre die Nummer bereits vor dem Zahlungsabschluss vorhanden, könnte diese überall genutzt werden. Aber es führt dazu, dass die fortlaufende Nummerierung für nicht-bezahlte (und ggf. später stornierte) Bestellungen generiert wird. Falls die Buchhaltung eine fortlaufende Belegnummerierung verlangt, müsste man alle fehlgeschlagenen Bestellungen auch ein- und ausbuchen.
Eine mögliche Lösung wäre, eine Bestellnummer für die Bestellung und z.B. eine Rechnungsnummer für eine Rechnung zu generieren. Letzteres natürlich erst bei Bezahlung. Das wäre eigentlich richtig – aber Isotope kennt bisher keine Belege zu einer Bestellung oder dergleichen. Ein Konzept, welches man erst entwickeln und umsetzen müsste.
Was denkst du darüber? Teile es mir gerne in einem Kommentar mit.
Moin Andy,
Ich bin dafür, Bestellnummer und Rechnungsnummer zu separieren, also Bestellungen (und -nummern) auch ohne Zahlung zu generieren.
Ich gehe sogar soweit zu behaupten, dass der Mehraufwand für Shopbetreiber:innen bisher größer gewesen ist, wenn eine Person bestellen wollte, aber den Prozess nicht abschließen konnte.
Bei einer unvollständigen Bestellung kann auch nochmal nachgefasst werden, was aktuell ja nicht möglich ist.
Was das Thema Rechnungsabwicklung betrifft, da könntest du eine Umfrage starten, wer das tatsächlich nutzt/benötigt. Shopbetreiber sind ja gerne auch auf mehreren Kanälen unterwegs (Ebay, Amazon) und müssen dadurch eh ein eigene Buchhaltungssoftware haben.
Ich finde es gut, wenn zwischen Bestellung und Bezahlung unterschieden wird. Dank unterschiedlicher Stati (bestellt sowie „ bestellt und bezahlt“ bekommen Shopbetreiber und Kunden unterschiedliche Mails. Isotope würde dann bei Abbruch des Bezahlvorgangs in den Status „ bestellt“ springen.
Das Problem mit Stornos wäre gelöst, wenn es 2 Tabellen wären. Bestellungen und „bezahlte Bestellungen“. Die Bestellung wechselt bei Bezahlung in die andere Tabelle. Da hat man dann einwandfrei fortlaufende Nummern, das Stornoproblem ist ja momentan sowieso oft, bei Kauf auf Rechnung… Dann könnte man mit einem Cron-Job regelmäßig die Bestelltabelle leeren - alles was älter als 4 Wochen ist und noch nicht bezahlt, kommt in den Orkus.
Ich würde Bestellung und Bezahlung auch voneinander trennen.
Eine Bestellung sollte in dem Moment entstehen, in dem der Kunde den kostenpflichtigen Bestellschritt auslöst. Die Bezahlung ist danach ein eigener Statuswechsel.
Das hätte aus meiner Sicht mehrere Vorteile:
Abgebrochene Zahlungen sind überhaupt sichtbar und nachvollziehbar.
Die Bestellnummer könnte direkt sauber an PSPs und Drittsysteme übergeben werden.
Nachfassen bei abgebrochenen Checkouts wäre grundsätzlich möglich.
Für die Buchhaltung würde ich die laufende Nummer der Bestellung aber nicht mit einer Rechnungs- oder Belegnummer gleichsetzen. Die Rechnungsnummer sollte erst bei erfolgreicher Zahlung bzw. Rechnungserstellung entstehen.
Praktisch würde ich daher vorschlagen:
Bestellung sofort anlegen
Status z. B. „neu / Zahlung ausstehend / bezahlt / abgebrochen / storniert“
Bestellnummer sofort vergeben
Rechnungsnummer erst bei Zahlung oder beim Erzeugen eines Belegs
By the way, wann ist mit der neuen Release für 5.7 zu rechnen, du hast doch bestimmt ein Ziel in Sicht.
Ich wäre auch dafür die Bestellung unmittelbar zu speichern als "nicht bezahlt". Sobald die Zahlung durch den Zahlungsanbieter abgeschlossen wurde, kann der Status geändert und die Rechnungsnummer erzeugt werden.
Wir haben aktuell immer wieder vereinzelnd das Problem, dass Zahlungen ausgeführt werden, aber die Rückweiterleitung zum Shop nicht klappt. Das nachzuvollziehen, zu dokumentieren, die Zahlung dem Kunden zu erstatten oder die Bestellung manuell einzupflegen ist ein sehr großer Aufwand.
Ich stelle mir nur folgende Frage:
Wenn ein Gast-Kunde eine Bestellung abschickt und den Zahlungsvorgang abbricht, weil er vielleicht doch eine andere Zahlungsart wählen will, dann ist ja sein Warenkorb leer und die Bestellung bereits im System. Wie käme dann ein Gast an seine noch zu bezahlende Bestellung?
Das ist genau eines der Probleme. Man müsste die Zahlungsart einer „fertigen“ Bestellung ändern (können), was ja wiederum Einfluss auf das Total haben kann.
Wäre ebenfalls dafür, dass die Bestellung direkt angelegt wird. Es kommt immer wieder vor, dass Kunden nach der Onlinezahlung den Browser sofort schließen und Isotope dadurch keine Rückmeldung über die erfolgreiche Zahlung erhält und die Bestellung im Nirvana verschwindet.
Wird der Zahlungsvorgang hingegen aktiv vom Kunden abgebrochen (z. B. um die Zahlungsart zu ändern oder den Kauf vollständig zu canceln), sollte die Bestellung entsprechend wieder gelöscht werden.
Ich freue mich auf die neue Version und stelle mich gerne als Betatester zur Verfügung.
Die meisten Firmen die ich kenne haben eine separate Buchhaltungs- oder gar ERP im Betrieb. Insofern wäre auch für mich die Trennung von Bestellung, Zahlung und Rechnung logisch. So kann ich als Betreiber entscheiden ab wann ich das System "verlasse" und die weiteren Arbeitsschritte in einem anderen System abwickle oder das Ganze bis zum Ende komplett in Isotope automatisiert abwickle.
Selbst wenn es viele Kaufabbrüche geben sollte - für mich sind das keine "Leichen" sondern wertvolle Daten mit deren Hilfe ich ggf. ein Nachbearbeiten ermögliche, und sei es nur das ich sehe das es Probleme oder Trends zu einem Zahlungsanbieter gibt.
EINSCHUB: Bildverwaltung in Isotope
Bisher hat Isotope ja seine ganz eigene Bildverwaltung auf Artikelebene mit vielen, für mich willkürlich angelegten Ordner im der Dateiebene, was nach meiner Erfahrung die effiziente Pflege der Bilddaten erheblich verkompliziert da ich meist nur über die Isotope Benutzeroberfläche die Bildaten aktualisieren kann. Es wäre super wenn man das auf die in Contao integrierte Datei und Bildverwaltung umstellen könnte. Die Redakteure die ich bisher damit geschult habe finden die Pflege an zwei Orten sehr unpraktisch, da es in der Regel auch noch Content im CMS Bereich gibt und im ungünstigen Fall ein Bild zwei mal im System abgelegt werden muss (Shop, News. Newsletter, Blog).
Ich schließe mich der bisherigen Meinung der Trennung von bestellt und bezahlt an.
Dieses Vorgehen erscheint mir transparent und logisch und der Benefit des nachfassen Könnens wäre super.
Danke für Deine Arbeit Andy!