Both Liip and Freitag took this opportunity to think about some of the lessons they have learned over the past five years. In doing so, Freitag is also investing in sustainability digitally, and we are both committing to a long-term working relationship. An essential part of the relaunch was the order workflow, and we now want to take a closer look at this.

Freitag sells bags made out of truck tarpaulin, so almost every piece is one-of-a-kind. Every product needs its own stock tracking unit (SKU) and a status description on Freitag that there is one in stock. Once a product has been sold, it cannot be made again. This is a real challenge when programming an online shop. This trait requires moving away from best practices in terms of user experience (UX) and technology solutions and establishing the lowest possible error rate in the order workflow. Corner cases during the checkout, fulfilment or delivery phase could mean a product is purchased by two people, which is bound to make one of them very unhappy when dealing with one-off pieces.

Background: systems

In addition to a couple of micro services, there are two main systems involved in the workflow,

  1. Drupal (basket, checkout, order processing, order changes, cancellations, customer communication, store communication, promotion management and voucher management) and
  2. Freitag’s ERP (inventory, fulfilment, delivery, controlling, returns).
    Freitag wants to make sure its customers can always purchase, even when the ERP is unavailable (e.g. during maintenance work). However, Drupal also serves other systems and use cases, and it, therefore, needs more comprehensive master data when it comes to orders. A dual solution with different systems was promised with the initial launch in 2016, and the best return on investment (ROI) was promised with the 2021 relaunch. Dividing this into even more micro services would have increased the investment needed due to the client’s particular requirements, and with few additional advantages.

1. Lesson learned: dividing tasks clearly is important

Due to the desire to have both systems operate independently and have lots of out-of-the-box functions, some duplications could lead to corner cases when in operation. Both systems could assign certain order statuses, and discount calculations and distribution formulas for refunds using multiple payment methods were partly completed in each system. Thanks to an updated ERP interface, there is now bi-directional communication. Instead of sending regular queries like before, the ERP now communicates directly with Drupal. This was one of the features that allowed tasks to be divided more clearly.

For example, there are two representations of the order, one in the ERP and one in Drupal. The process in Drupal begins earlier (basket and checkout) and ends later (omni-channel, collection in-store, etc.). What’s new is that while the order is being processed in the ERP (fulfilment and delivery), only the ERP controls the order status. As changes and cancellations may occur during this phase, Drupal can request changes and cancellations. However, it is always the ERP that changes the status in Drupal.

Example for a refund: Drupal is linked to the corresponding systems for credit cards, vouchers and promotion codes. If a refund is requested involving multiple payment methods, Drupal decides which amount is put back on which payment method. Previously, the accounting basis has always been the ERP, and even when the same rules were supposedly set for each system, there may have been some discrepancies. Now, only the ERP has authority here, and it can communicate with Drupal via an interface to tell it which amount to pay back via which payment method.

We assigned authority to further sub-processes wherever this would provide a good ROI. As this has only been in place for a few months, it is hard to say yet what the long-term stability of this workflow will be. However, our experience thus far has been positive.

2. Lesson learned: automatic inventory

Given that there is only ever 1 or 0 in stock for most Freitag products, and the systems have to function separately, some complex challenges must be overcome in this area. For example, if orders are changed outside the standard process or are edited manually, the product ordered should not be available anymore online. On the other hand, putting a piece back online with this volume of transactions cannot be a manual process as this would require too much effort.

Previously, there was a physical inventory (the ERP inventory) and a virtual one. The latter served to bridge the gaps when the ERP was unavailable or had not yet been updated. This solution worked in over 99% of cases. However, there are a few cases – that unfortunately occur regularly – where this would lead to -1 or +2 being shown. It was difficult to find out what was behind these few discrepancies due to the complexity of that solution.

We retained the double inventory for the relaunch but with one important simplification: ‘the ERP is always right’. We also added to the complexity slightly by adding another layer: reservations. As the ERP is not always right, these reservations also prevent any double purchases. By simplifying the inventory logic and having the reservations controlled by Drupal, it is now much easier to find out where something went wrong if there is an incident. This is particularly helpful now in the first few months after the relaunch.

 3. Lesson learned: tracking numbers

Yes, depending on how they are set up, tracking numbers can also pose a challenge. Freitag ships its products globally using different delivery services. These have different processes for if and when a tracking number is generated and from what point this can be used. Ultimately, it is preferable for tracking information to be already available when the shipping confirmation is sent. The previous logic for when a shipping confirmation was generated was complex and tried to show the different scenarios: with polling on the ERP, order types, delivery methods, completed information fields and waiting periods. Nevertheless, the shipping confirmation was often sent too early or too late. Attempts to improve the rules for this often led to other problems. A solution was needed.

For the relaunch, we added a new status to the order workflow: ‘packed’. This status means the order has been packed, and is possibly already on its way, but the tracking number is not yet known or is not ready to be used. As soon as you can start tracking your package, the ERP will change the status to ‘dispatched’. This will cause Drupal to generate the shipping confirmation, whether there is a tracking number there or not. This means that the various tasks are divided clearly, and if any problems arise, it will be easier to find the cause and resolve the issue. The ERP can also estimate the status of the tracking number more easily, and Drupal needs one fewer set of rules. This change has already been tested and has proven to be extremely reliable.

Summary: simplicity through complexity

Simplifying things is our natural instinct at Liip. Our experience shows that implementation and operational challenges can be kept to a minimum if you keep things simple. However, as demonstrated above, you can also achieve more simplicity by introducing more complexity. Let's not forget that we added more interfaces, an additional layer and a new order status. All three of these measures make the system significantly more robust. They also allow errors to be identified more quickly. In the case of ongoing operations, this is essential for determining how to invest in further developments. After all, we want to develop our clients’ products and solutions further, not just maintain their system.