Skip to main content

Proposed Order Flow

Overview​

The sequence diagram in this document represents the proposed Order Flow after the transformation from the as-is to the cleaned up version, available to review in the previous two documents:

The main change is the replacement of Hybris with CommerceLayer as our eCommerce solution with the particularity that CommerceLayer doesn't provide (for a good reason) the flexibility of customising any steps of the order process flow.

This means that CommerceLayer steps away from the complexity of providing a tool to differ from the expected Order Process, keeping it as simple as possible, but covering all the required statuses. It actually contemplates statuses for the Order itself, its Payment and Fulfilment.

Ideally, we should avoid the heavy customisation and patching we've done on the Order Process over the last ten years. We should challenge ourselves, questioning any customisation before adding extra complexity to it.

The other major change is to receive fulfilment notifications from the existing integration with GXO (already built on our MW) , rather than NAV. This way we avoid having a middle-service resending events we are capturing in the MW layer, where we can add a new subscriber without impacting the existing systems involved.

GXO current integration​

As mentioned, GXO is currently integrated with NAV via our MW by the transaction event bus, receiving events of order statuses & shipments. We can add a new CommerceLayer subscriber to receive the changes and modifying its status accordingly, as per our requirements.

StatusShipment
GXO Order Status IntegrationGXO Order Shipment Integration

CommerceLayer Order Flow​

CommerceLayer team shared with us an internal diagram where we can see the transitions between statuses on their end.

CommerceLayer Order / Payment / Fulfilment flow

We can then use the existing webhooks on their end to perform the tasks required in our case, at least on Order level, see Realtime Webhooks documentation

EventDetail
orders.createA new order is created
orders.payAn existing order payment status is set to paid
orders.start_fulfillingAn existing order fulfillment status is set to in_progress
......

Please notice that the current webhooks doesn't include Payment & Fulfiment status changes, but keeping them at Order level only. I've raised a question with the CL team to review if there will be this level of granularity in the future or not.

Order Process Flow​

We will split the order in blocks to simplify the sequence representation

Checkout​

TODO :

Order process - Creation of an order​

Order process running prior sending to NAV.

sequenceDiagram actor C as Customer participant CL as CommerceLayer participant AV as Avalara participant B as Bloomreach participant AD as Adyen participant N as NAV autonumber C->>CL: Place_Order CL->>AV: avataxPost Note right of CL: Save the tax record in Avalara.<br>Will be committed once the order is placed.<br>TODO: this is not entirely clear, see documentation in Resources and confirm CL->>CL: checkAuthorizeOrderPayment Note right of CL: Checks if the Authorisation was successful in Adyen/Paypal.<br>TODO: Confirm if this is required based on CommerceLayer's default process CL->>B: sendOrderPlacedNotification Note right of CL: Notification to the customer that their order has been placed<br>Use webhook from CL into Bloomreach activate CL CL->>CL: isPaypalPayment Note right of CL: Checks if order has been paid using PayPal, and triggers takePaypalPayment if so<br>TODO: Confirm if this is required based on CommerceLayer's default process CL->>AD: takePaypalPayment Note right of CL: Capture from Paypal<br>TODO: Confirm if this is required based on CommerceLayer's default process CL->>CL: splitOrder Note right of CL: Creates the consigment.<br>TODO: Check how this works on CL deactivate CL CL->>N: sendOrderToNav Note right of CL: XML build to send to NAV's API<br>Use CL's webhooks - TODO: which event will allow us to send after the Authorisation check?<br>TODO: Retry mechanism. Propose a default architecture in our MW that can be cloned & reused activate N N-->>CL: OK N-->>CL: NOK deactivate N

Fulfilment process​

As mentioned, This would use the existing integration between GXO and NAV. The details of the payloads are documented here:

sequenceDiagram participant CL as CommerceLayer participant G as GXO autonumber alt Order Status: gxoorderstatus activate G G-->>CL: ACCEPTED G-->>CL: ALLOCATED G-->>CL: CANCELLED Note left of G: TODO: Cancellation process required<br>DC can cancel orders if no stock available deactivate G end alt Shipment status: gxoordershipment activate G G->>CL: SHIPPED deactivate G end G-->>CL: Stock Adjustment Note left of G: TODO: Confirm this sent after order processing, see Stock Snapshot, too

Order Process - post-shipped processing​

sequenceDiagram participant CL as CommerceLayer participant AD as Adyen participant AV as Avalara participant B as Bloomreach participant N as NAV autonumber CL->>AD: Take Payment Note right of CL: TODO Capture is not a synchronous call, check how this works on CL CL->>AV: Tax Filing CL->>CL: Order COMPLETED CL->>B: Send notification to customer CL->>N: Send Order Completed

Regarding Tax Filing, CommerceLayer team shared with us the following:

About tax filing it is possible to enable a flag on the avalara tax calculator (commit_invoice) so that CL is going to send directly the transactions on Avalara. Then there are two ways to use it:

  • Setup tax categories per SKU on Commerce Layer, configuring Avalara with their help
  • Setup directly all SKU rules on Avalara

If you are going to follow the first way, consider that you need to import tax categories on Commerce Layer only if you need exceptions in comparison to the tax rate of the country, otherwise it is not needed.

Invoice commit on Avalara is going to happen when there is a capture of the payment and the payment status of the order is paid. A similar communication will happen on refund

Resources​