Zum Inhalt springen

Konzepte: Bestellungen

In der tebio Plattform ist eine Bestellung (Order) der Ausgangspunkt für viele Folgeprozesse. Sie fungiert als technischer und fachlicher Auslöser für Folgeprozesse.

Erst durch den erfolgreichen Abschluss einer Bestellung werden im Hintergrund Subscriptions erzeugt, Shop-Produkte oder Hardware an Logistikprozesse übergeben und die ersten Rechnungszyklen angestoßen.

Ein häufiges Missverständnis ist die Vermischung von Bestellung und Subscription. Die Plattform trennt diese beiden Konzepte strikt:

  • Die Bestellung (Order) ist ein zeitlich begrenztes, einmaliges Ereignis. Sie dokumentiert den Bestellvorgang: Welcher Kunde hat wann, zu welchen Konditionen, welche Produkte bestellt? Hinweis: Bei einer Bestellung des Kunden über die Hosted Pages bzw. bei Nutzung des Service CreateNewSubscriptionOrder kann im Zuge einer Bestellung auch direkt ein neuer Kunde erzeugt werden, falls dieser noch nicht existiert.
  • Die Subscription ist die laufende Vertragsbeziehung, die aus der Bestellung hervorgeht.

Beispielhafte Einordnung: Die Bestellung dokumentiert den Abschluss. Die Subscription bildet anschließend den laufenden Zustand ab. Änderungen (z. B. eine Preisanpassung oder Kündigung) wirken sich auf das laufende “Abonnement” aus, nicht auf die historische Bestellung.

2. Architektur: Synchroner und asynchroner Bestellprozess

Abschnitt betitelt „2. Architektur: Synchroner und asynchroner Bestellprozess“

Wenn eine neue Bestellung ausgelöst wird, teilt die tebio Plattform den Vorgang architektonisch in zwei Phasen auf, um stabile Verarbeitung und gute Antwortzeiten zu gewährleisten:

  1. Synchroner Teil: Unmittelbar nach Absenden der Bestellung wird diese validiert. Wenn als Status lediglich Entwurf (DRAFT) oder Angebot (OFFER) angefragt wird, stoppt der Prozess hier. Es werden noch keine weiteren Aktionen (Zahlung, Kunde anlegen etc.) ausgelöst.
  2. Asynchroner Teil: Wird die Bestellung verbindlich aufgegeben (Status ORDERED), übernimmt der Order-Prozess im Hintergrund. Dieser asynchrone Workflow steuert die Steuerung der Folgeprozesse, ohne das Frontend zu blockieren.

Aus dem Order-Prozess heraus werden je nach Anwendungsfall diverse weitere Prozesse ausgelöst:

  • Zahlungsvereinbarungen: Ein Prozess zur Etablierung z. B. eines SEPA-Mandats.
  • Zahlungsautorisierung: Das Reservieren oder Einziehen von Zahlungen.
  • Versand (Logistik): Das Anstoßen des Versands von physischen Gütern.
  • Fulfillment: Die eigentliche Provisionierung der Subscriptions, Lizenzen oder SIM-Karten.
  • Rückabwicklungen (Retouren): Sollte der Kunde später widerrufen, wird die Rückabwicklung gesteuert.

Eine Bestellung durchläuft von der Anlage bis zur Archivierung verschiedene, fest definierte Zustände (Status).

Das folgende Zustandsdiagramm (Statusmodell) veranschaulicht den Ablauf und die möglichen Verzweigungen einer Bestellung:

stateDiagram-v2
    [*] --> DRAFT
    [*] --> ORDERED
    DRAFT --> OFFER
    DRAFT --> CANCELLED
    OFFER --> ORDERED
    OFFER --> CANCELLED
    
    ORDERED --> WAIT_FOR_PAYM_ARRANGEMENT
    ORDERED --> WAIT_FOR_APPROVAL
    ORDERED --> WAIT_FOR_SCHED_DATE
    ORDERED --> WAIT_FOR_PAYMENT_AUTHORIZE
    ORDERED --> FULFILMENT
    ORDERED --> CANCELLED
    
    WAIT_FOR_PAYM_ARRANGEMENT --> WAIT_FOR_APPROVAL
    WAIT_FOR_PAYM_ARRANGEMENT --> WAIT_FOR_SCHED_DATE
    WAIT_FOR_PAYM_ARRANGEMENT --> WAIT_FOR_PAYMENT_AUTHORIZE
    WAIT_FOR_PAYM_ARRANGEMENT --> FULFILMENT
    WAIT_FOR_PAYM_ARRANGEMENT --> FINISHED_FAILED
    
    WAIT_FOR_APPROVAL --> WAIT_FOR_SCHED_DATE
    WAIT_FOR_APPROVAL --> WAIT_FOR_PAYMENT_AUTHORIZE
    WAIT_FOR_APPROVAL --> FULFILMENT
    WAIT_FOR_APPROVAL --> FINISHED_FAILED
    WAIT_FOR_APPROVAL --> CANCELLED
    
    WAIT_FOR_SCHED_DATE --> WAIT_FOR_PAYMENT_AUTHORIZE
    WAIT_FOR_SCHED_DATE --> FULFILMENT
    WAIT_FOR_SCHED_DATE --> CANCELLED
    
    WAIT_FOR_PAYMENT_AUTHORIZE --> FULFILMENT
    WAIT_FOR_PAYMENT_AUTHORIZE --> FINISHED_FAILED
    
    FULFILMENT --> FINISHED_SUCCESS
    FULFILMENT --> FINISHED_PARTIAL_SUCCESS
    FULFILMENT --> FINISHED_FAILED
    
    note left of FULFILMENT : ERROR state can be both source\nand target of nearly every other state.
  • DRAFT / OFFER: Entwurf und Angebot. Vorstufen ohne abgeschlossenen Bestellprozess.
  • ORDERED: Die Bestellung ist platziert. Der asynchrone Workflow startet nun.
  • WAIT_FOR_PAYM_ARRANGEMENT: Warten auf die Einrichtung z. B. eines Lastschriftmandats.
  • WAIT_FOR_PAYMENT_AUTHORIZE: Das System wartet auf die Autorisierung des Zahlungsanbieters (z. B. PayPal oder 3D-Secure).
  • WAIT_FOR_APPROVAL: Wartet auf manuelle kaufmännische Freigabe durch einen Portalnutzer mit entsprechender Berechtigung.
  • WAIT_FOR_SCHED_DATE: Der Kunde hat die Bestellung abgeschlossen, aber als Startdatum einen Tag in der Zukunft gewählt (z. B. Vertragsbeginn am 01.01.).
  • FULFILMENT (Ausführung): Der Moment der Provisionierung. Das System übersetzt nun die Bestellpositionen in echte Subscriptions.
  • FINISHED_SUCCESS (Abgeschlossen): Die Ausführung wurde erfolgreich abgeschlossen. Die Bestellung ist nun historisch archiviert und schreibgeschützt.
  • CANCELLED / FINISHED_FAILED: Die Bestellung wurde abgebrochen oder ist aufgrund technischer/kaufmännischer Probleme fehlgeschlagen.