About EDI and the Foodware Data Exchange Framework

Written by Dänny Hellemons, Product Development Manager at Schouw Informatisering

Approximately two years ago, we at Schouw Informatisering decided to investigate the options for an improved EDI proposition. Until then, EDI was part of our Dynamics NAV based product SI Foodware, and of our implementation services. Handling the Order-To-Cash process as well as basic Vendor-Managed-Inventory. On the Dynamics AX side of our product and implementation services, we offered a similar proposition: primarily focused on the ERP side of the EDI proposition. The EDIFACT message transformation and transport as well as the implementation was handled through Value-Added-Network (VAN) suppliers such as Descartes, Generix and Tie Kinetix. VAN suppliers handle lots of EDIFACT messages and the related traffic between food companies and retailers. Schouw Informatisering handles the food company’s specific EDI mapping and processing in the back-end ERP application.  

Implementation projects therefore required three parties to be involved.  The customer EDI lead, the VAN partner and the Schouw project team. Where the latter two were working on a different rhythm: an ERP project implementation versus an EDI service setup. This often led to challenges in timing and project management, with the customer stuck in the middle. The need for flexibility and a short time-to-market only increased the bar. As our customers signed up with new retailers in other markets, outside the Netherlands, additional requirements and extended EDI processes (and therefore mappings) were required. A challenge to be solved as we strive to become more of a full services partner for our customers and perform in a flexible and timed manner, to meet the EDI demands from retailers. To unburden our customer.

Building the EDI base

As a first step, we needed to increase our EDI knowledge. By now, we have the essential EDI knowledge inhouse, from all three angles: the VAN partner, the retailer and our customer, the food company. The internal investigation that we ran subsequently made us realize we needed to detangle the EDI process handling from our other software. Followed by the desire to decouple the data mappings from the EDI processing steps in the ERP solution. One step further would also take the EDIFACT mappings into account. In a way that consultants would be enabled to perform these tasks, adding or adjusting mappings for our customers.

As we progressed, an architecture arose, a three-layered model.

  • In the first layer, the integrated EDI processes that are available within the Foodware 365 ERP platform are decoupled using staging tables.
  • Next, a mapping is made based on an internal XML-based data model. This enables standardization of data traffic based on the business entities such as orders and invoices. These are based on the capabilities of the backend ERP, therefore creating less dependencies on a possible multitude of external standards.
  • By separating the transformation and transport, we enable customers to either leave the EDIFACT message handling to a VAN or take full control on their own.

An audit trail ensures the logging on both ends and acts to investigate errors.

A standardized layered approach to offer flexibility, decoupling and extensibility for other external data exchange standards and the need for customer customization on top. Delivering a complete service approach during ERP implementations. So now we got a functional blueprint to start the search for tooling and a platform. More than just an EDI framework, a Data Exchange Framework.

A solution framework based on Azure Services

Over time, we looked at a variety of iPaaS platforms, since we were looking for one to provide us with transformation, integration and transport capabilities. Furthermore, it should be an SMB affordable, pay-as-you-grow model. A model that could be constructed step-by-step, learning and expanding along the way. It was closer than we expected, Azure Serverless Apps: Azure services such as Logic Apps, Azure Functions, Azure Service Bus, Azure Event Grid etc.

With guidance and validation from Microsoft architects, we started defining our architecture with Azure services building blocks. Enabling us to build our Data Exchange Framework step-by-step. Furthermore, we decided to use Altova Mapforce as a visual data mapping & transformation tool. To enable consultants and customers to do the mappings instead of having to source this task to developers.

Our product emerged last summer. Completely re-thinking and re-developing the EDI process in our Foodware proposition. The result, a solution framework that supports the Order-To-Cash EDI messaging and process for suppliers, based on Azure Services. It is more than EDI though. It is a first version of our Data Exchange Framework that is able to cope with any means of data transport, transformation and processing.

In the fall of last year, we started an implementation project at one of our larger food customers in the Netherlands. We combined it with the implementation of our Data Exchange Framework for the Order-To-Cash EDI process. The entire project went live at the end of March 2019. Our first successful implementation.

Planned for later this year is a connection of the framework to Business Central SaaS. Extending Foodware 365 with the Data Exchange Framework capabilities.