{"id":56,"date":"2026-09-23T09:00:00","date_gmt":"2026-09-23T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=56"},"modified":"2026-09-21T22:09:30","modified_gmt":"2026-09-21T20:09:30","slug":"foravida-orderstroom-traceerbaar","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/behind-foravidas-order-flow\/","title":{"rendered":"Behind ForaVida\u2019s order flow"},"content":{"rendered":"

At ForaVida, the Connect foundation has been implemented to make WooCommerce, AFAS and route planning work together as one traceable order flow.<\/strong> An order is not merely copied from system A to system B. The data is checked, translated and distributed to the applications that need it for administration and operations.<\/p>\n

That distinction matters for configurable products and different delivery methods. Many operational decisions follow checkout: is the order complete, which items and quantities belong to it, how will it be delivered, which date applies and what happens when information is missing? The integration\u2019s value therefore lies in error handling as much as in the normal route.<\/p>\n

This account describes the implemented Connect integration<\/a>. ForaVida uses Yindle Desk for customer enquiries and order handling.<\/p>\n

The order starts in WooCommerce<\/h2>\n

The customer configures a product, completes the order and chooses a suitable delivery method. WooCommerce is therefore the starting point of the commercial transaction. But an online store order is not automatically usable by every downstream system.<\/p>\n

An administration system may expect different field names, references or required values. Route planning mainly needs delivery details, a date and operational characteristics. Parcel delivery and collection follow different routes again. Building every transfer separately creates duplicate rules and unclear ownership.<\/p>\n

Yindle Connect<\/a> therefore forms the connecting layer. The online store remains the online store, and AFAS remains the administrative source for the elements that belong there. Connect makes the event usable for each destination.<\/p>\n

Six steps from order to execution<\/h2>\n
    \n
  1. Receive:<\/strong> a relevant order event from WooCommerce starts processing.<\/li>\n
  2. Identify:<\/strong> the order, customer and order lines are treated as one coherent event.<\/li>\n
  3. Validate:<\/strong> required data and known mappings are checked before the transfer continues.<\/li>\n
  4. Translate:<\/strong> fields, statuses and process rules are converted to the meaning expected by AFAS or operations.<\/li>\n
  5. Distribute:<\/strong> only the information a destination needs goes to the appropriate delivery flow.<\/li>\n
  6. Record:<\/strong> each step receives a recognisable status, so success, skipping and failure can be traced afterwards.<\/li>\n<\/ol>\n

    The sequence prevents a downstream step from starting while the core of the order has not yet been processed reliably. A logistics instruction should not, for example, run ahead of an order rejected by the administration system.<\/p>\n

    Not every order follows the same route<\/h2>\n

    An important design choice is that the delivery method does not remain a separate text field. It determines which operational route applies. Broadly, an order may go through the company\u2019s own transport, parcel delivery or collection by appointment, for example.<\/p>\n\n\n\n\n\n\n\n
    Delivery flow<\/th>\nRequired context<\/th>\nTypical exception<\/th>\n<\/tr>\n<\/thead>\n
    Own delivery service<\/td>\nAddress, postcode zone, planned day and route<\/td>\nThe date or zone no longer fits<\/td>\n<\/tr>\n
    Parcel delivery<\/td>\nShippable items and tracking context<\/td>\nThe order has been processed administratively but not yet submitted for shipping<\/td>\n<\/tr>\n
    Collection<\/td>\nCollection time, available order lines and handover<\/td>\nThe customer arrives at a different time or the order is incomplete<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Making those routes explicit lets the organisation determine which information takes precedence in each flow and which status means something to the customer. After all, \u201cprocessed\u201d in the administration system means something different from \u201cscheduled\u201d or \u201creceived by the carrier\u201d.<\/p>\n

    Traceability matters when an exception occurs<\/h2>\n

    An integration is not reliable because the ideal order arrives correctly once. It is reliable when a discrepancy remains visible and can be resolved in a controlled way.<\/p>\n

    Consider an item without a valid mapping, a missing required address field or an external system that temporarily stops responding. Processing must not disappear silently. Blindly retrying is risky too: if the first attempt may have succeeded, a second attempt could create a duplicate order or duplicate follow-up action.<\/p>\n

    A recoverable flow therefore has four characteristics:<\/p>\n