Leistungen
Bestellungen, Zahlungen, Bestände und Verkaufsprozesse, die sich an der tatsächlichen Auftragsabwicklung orientieren.
Kunden sehen Katalog, Warenkorb und Checkout. Das Unternehmen muss Bestellung, Zahlung, Bestand, Lager, Rechnung, Versand, CRM, Kommunikation, Rückgaben und Erstattungen koordinieren. Ein guter eCommerce-Workflow weist jedem Teil klare Verantwortung zu und macht Ausnahmen sichtbar.
GiSoft gestaltet und modernisiert diese Workflows ohne anzunehmen, dass jeder Shop dieselben Zustände, Integrationen oder dieselbe Architektur braucht. Der Ablauf soll zum Verkauf physischer Produkte, digitaler Leistungen, Abonnements oder B2B-Bestellungen passen.
Es muss klar sein, wann eine Bestellung entsteht, wann Bestand reserviert wird, wer sie freigeben darf, wann eine Rechnung entsteht und was Stornierung oder Erstattung bedeuten. Der Bestellstatus gehört in die Geschäftslogik auf dem Server, nicht in eine Browseransicht.
In vielen Unternehmen verbindet eine beim Checkout erzeugte interne Bestellnummer Zahlung, Reservierung, ERP, Rechnung, Versand und Support. Das erleichtert oft die Wiederherstellung, doch die richtige Reihenfolge hängt vom Produkt und Verkaufsprozess ab.
Die Rückkehr von einer Zahlungsseite ist keine endgültige Bestätigung. Der Kunde kann den Browser schließen, die Weiterleitung kann scheitern oder die Zahlung kann noch ausstehen. Die Anwendung sollte die geprüfte serverseitige Bestätigung des Anbieters oder ein anderes vereinbartes Abrechnungssignal verwenden und erst dann den eigenen geschäftlichen Zahlungsstatus aktualisieren.
Autorisierung, Einzug und Bestätigung sind unterschiedliche Konzepte. Ein Anbieter reserviert eventuell zuerst den Betrag, ein anderer meldet die abgeschlossene Zahlung später per Webhook. Der Bestellworkflow sollte die für den Shop nötige Bedeutung abbilden: Zahlung ausstehend, autorisiert, bezahlt, abgelehnt, storniert, erstattet oder klärungsbedürftig.
Verfügbarkeit, Reservierung und Bestandsminderung sind nicht dasselbe. Verfügbarkeit beantwortet, ob ein Artikel derzeit angeboten werden kann. Eine Reservierung ordnet Einheiten unter definierten Bedingungen vorübergehend einer Bestellung zu. Die Bestandsminderung hält die endgültige oder auf die Erfüllung bezogene Lagerbewegung fest. ERP oder WMS kann das führende System sein, aber der Shop braucht klare Regeln, was er anzeigen darf und wann eine Reservierung verfällt oder freigegeben wird.
Stellen wir uns einen älteren Symfony-Shop vor, der mit Katalog, Warenkorb, Checkout, Bestellungen und E-Mails begann. Später kamen Zahlungsanbieter, ERP- und WMS-Synchronisierung, eine Kurier-API, Rechnungserstellung und CRM-Aktualisierungen hinzu. Ruft der Checkout-Controller alle externen Systeme direkt auf, kann ein langsamer Anbieter Kunden ausbremsen und ein Teilfehler ist schwer zu erklären.
Eine kontrollierte Verbesserung bewahrt die bestehenden Bestellregeln und stellt einen Anwendungsworkflow zwischen Checkout und externe Dienste. Adapter für Zahlung, ERP, Lager, Rechnung und Benachrichtigungen behandeln dann ihre jeweiligen Grenzen. Dafür muss nicht der gesamte Shop neu geschrieben werden; der Einstieg kann dort erfolgen, wo das betriebliche Risiko am größten ist.
Ein HTTP-Erfolg oder der Empfang eines Webhooks bedeutet nicht zwingend, dass der ganze Geschäftsprozess beendet ist. Auch ein Timeout beweist nicht, dass eine externe Operation gescheitert ist: ERP, Zahlungsanbieter oder Rechnungsdienst können die Anfrage ausgeführt haben, bevor die Antwort verloren ging.
Den lokalen Versuch festhalten, einen stabilen Geschäfts- oder Anfragebezeichner nutzen, wenn das externe System ihn unterstützt, und unklare Fälle mit dem führenden System abgleichen. Idempotenz bedeutet, dass eine wiederholte Operation keinen zusätzlichen beabsichtigten Geschäftseffekt haben soll. Sie hängt vom Anwendungsentwurf und gegebenenfalls von Anbieterunterstützung oder einer gemeinsamen Kennung ab; eine Kennung allein ist keine Garantie.
Wiederholungen sollten vorübergehende Fehler behandeln und begrenzt sein. Ungültige Daten oder eine fehlende Geschäftsentscheidung brauchen Korrektur oder manuelle Prüfung. Hintergrundjobs eignen sich für ERP-Aktualisierung, Rechnungserstellung, Bestandssynchronisierung und Benachrichtigungen, weil der Checkout nicht auf jeden Folgeschritt warten sollte.
Stornierung, Erstattung und Rückgabe sind unterschiedliche Geschäftsereignisse. Eine Stornierung kann vor dem Versand eine Reservierung freigeben; eine Erstattung kann nach der Abrechnung erfolgen; eine Rückgabe kann eine Lagerentscheidung und Buchungskorrektur erfordern. Die Regeln müssen klar sein, ebenso Freigaberechte und das System, das den Endzustand führt.
Ein Datenbank-Rollback dreht keine abgeschlossene Zahlung, gesendete E-Mail oder ERP-Aktion zurück. Wiederherstellung kann Abgleich, Kompensationsaktion, sichere Wiederholung oder manuelle Bearbeitung bedeuten. Monitoring sollte zu lange wartende Bestellungen, fehlgeschlagene Jobs, Zahlungsabweichungen, Bestandskonflikte und prüfbedürftige Fälle zeigen.
Administrative Änderungen brauchen Autorisierung; Kunden- und Finanzdaten müssen geschützt, Zahlungswebhooks geprüft und Anbieterzugangsdaten aus Code und unnötigen Logs herausgehalten werden. Kritische Wege sollten getestet werden: Bestellung genau einmal anlegen, wiederholte Benachrichtigungen, Reservierung und Freigabe, Rechnungserstellung und Wiederherstellung nach Fehlern.
GiSoft beginnt beim bestehenden Bestellprozess, bestimmt führende Systeme und Risikopunkte und verbessert dann die wichtigsten Grenzen. Der passende Entwurf hängt vom Verkaufsmodell, der Bestandspolitik und den verbundenen Systemen ab. Ziel ist ein Ablauf, den das Team versteht und wiederherstellen kann, nicht die Zusage perfekten Verhaltens aller externen Dienste.
