When a process is in place and working why change the process but adapt what is new into what exists so saving time and money.
I worked on a development in which an existing Electronic Data Interchange (EDI) process had been built to support Orders and Invoicing for Wholesale.
Drop Ship Vendor (DSV) was clearly a new method of trading, at the time, and the developers adapted the old Wholesale process to also support the new DSV process.
This meant that an EDI Order could contain a Wholesale or DSV order. As the supplier I had to define a process to support the process and split the data using various fields found in the EDI orders message.
Why am I writing abut this topic?
This comes back to thinking through your strategy when it comes to how you want to trade with your retailer base plus how you then support integrations with these retailers.
What is interesting here is that there are processes in place that connect using a Value Added Network (VAN) and EDI Orders and Invoice messaging plus an sFTP connection supporting a CSV file format supporting DSV process activity (order acknowledgements, fulfilment and inventory).
The orders for both Wholesale and DSV are provided in an EDI Orders message sent via the OpenText VAN.
When processing an EDI orders file you will need to understand which order is for a Wholesale order being sent in bulk to the retailers warehouse or a DSV order being sent directly to the end consumer.
These, I believe, will be two different behaviours in your warehouse operation as I assume that the pick, pack and dispatch process will differ.
For the development I worked on I processed the orders into different accounts within the ERP system, however using the generic orders interface file there are two target data sets you could use to define how the order is to be processed:
The picture above defines the rules I applied to split a Wholesale order from a DSV order. The complete mapping document be found below:
There were two different types of order acknowledgements:
EDI ORDRSP message
CSV Order file
Both files used the generic Order Acknowledgement interface file sent from the ERP system.
Both Order Acknowledgement mapping documents can be found below:
I did not develop the Dispatch functionality to support Wholesale. A Dispatch file was generated to support the DSV orders. Again, this generic interface file generated from the ERP system was transformed into a CSV file and sent via an sFTP connection.
The Order Dispatch mapping document can be found below:
As described above the orders when processed were split into a Wholesale or DSV account. Both accounts had to generate the data to support an EDI Invoice message that would be sent to the retailer via the OpenText VAN.
The EDI Invoice mapping document can be found below:
To support the DSV aspect of this development an Inventory file had to be submitted in a CSV file format and the sFTP connection.
This was a simple task as again, the process was plugged into a generic process and interface file that was then transformed.
The CSV mapping document can be found below:
Prior to this development work the supplier had to work through the orders and allocate the DSV orders as a priority. These orders were reviewed by eye. The orders were pulled into the system manually so was limited to office hours.
The process I had developed split the orders into Wholesale and DSV automatically. DSV orders when processed into the ERP system were automatically allocated and sent to the Warehouse Management System (WMS) to be picked, packed and dispatched. This meant that the warehouse were not dependent on the office being in so could work outside of office hours to fulfil the DSV orders.
To update the Retailers CRM files were uploaded to acknowledge the orders and then fulfil the orders. Inventory files were also uploaded manually.
The automated solution I had deployed automated this process so that as DSV orders were received they were acknowledged and as the Warehouse dispatched the orders the order was updated with the tracking number.
Inventory files were also automatically sent day and night.
This development saved time and money and made the Service Level meetings a little easier as the agreed Service Levels were no longer breached. A win for the supplier and a win for the retailer.