Welcome back. In this video I’ll be talking about application APIs and how their use can have major benefits for your business.
If you use a reasonably modern ERP system, there’s a good chance it already has a REST API, just waiting to strengthen your business in new and cost-saving ways.
A good example is the Interprise system from ApexIT.
Its REST API has allowed us to build what might be described as an “intimate” interface that feeds data from traditional EDI orders directly into the system in real time.
The EDI messages are received and validated as normal and then mapped to the JSON format required by the API’s “POST salesorder” endpoint.
In case you’re not familiar with the term, an “endpoint” is section of an API that does a specific job, in this case it’s used to create new sales orders. Interprise has a large number of these endpoints, over 250 at the last count, so there’s not much that can’t be automated if we needed to.
The JSON version of the order is then sent to the API which immediately responds with either an “Order xxx created” message, or an error message that describes why the order could not be accepted.
This is pure gold. Prior to the use of APIs, the approach would have been to create a file of order data that could be sent over to the ERP system. Other software would then attempt to import the orders.
The EDI system couldn’t know for sure that each order had gone all the way through to the ERP, it simply had to hope for the best.
Using the API means that it can instantly know whether or not the process has worked. If something goes wrong, such as Interprise rejecting a sales order because it contained an invalid item code, then alarms can be sounded.
Running an EDI system correctly is mostly about quickly knowing when something has gone wrong, and doing something about it before it impacts the business. It would be foolhardy to think that just because an EDI system has been running perfectly for six months, it will run perfectly forever. Something unexpected can always happen.
If an order fails to go through, and it is not noticed immediately, then the delivery could be missed and the customer will be mightily unhappy. If that happens too often, you’ll lose the customer.
Knowing the sales order number is also extremely useful in other respects. If the EDI system knows the customer, customer’s order number and supplier’s sales order number, and records this information in a register, then when the invoice comes through for that sales order it can be matched to the original customer’s order.
This makes it possible to produce automated exception reports to list, for example, all sales orders that have not been invoiced within two days of their delivery date. It may be that there’s a good reason for this, but when it highlights an order should have been invoiced but wasn’t, the quicker the business can know about it the better.
Application APIs also permit certain tasks to be automated that would often be perceived as outside the scope of EDI.
A good example is the settlement report generated by Amazon for each of its sellers.
This report is typically generated every two weeks and lists the customer orders that have been handled by Amazon, together with the fulfilment fees and commission incurred.
We were asked to deliver a project for a customer who sells a lot of its products via Amazon. Manually handling this settlement report was proving to be a particular drain on resources.
We’d already used the Amazon API to retrieve information about customer orders each night and used it to create sales orders in the customer’s ERP system. Because The orders were fulfilled by Amazon, the API could also be used to immediately create invoices for those orders.
So far, so good, but there was a slight problem. The process couldn’t accurately know what the Amazon fees and commission would be for each order, so the invoices couldn’t include that information. Fortunately, this wasn’t a major issue since the invoices would never actually be sent anywhere, they only needed to exist for accounting purposes.
When the settlement report came through, the fees and commission for each order would finally be known. The system we created used the data from the settlement report to create credit notes in the customer’s ERP for the actual fees and commission, again using the API.
We can then create a receipt for the amount of money paid by Amazon to the supplier, and allocate the corresponding invoices and credits to it.
Previously, each settlement report required two days of manual effort from one of the businesses most experienced Financial Controllers. Now, the automated process delivers a report, detailing the receipt and the invoices/credits allocated to it, by the time they open their e-mail in the morning and take their first swig of coffee.
As a result, the Financial Controller has the bandwidth to focus on things that are far more beneficial to the business.
One final note on this, many APIs can also be used to retrieve master data from the ERP and this is particularly useful when data needs to be validated by the EDI server.
In one real-world scenario, it’s necessary to run an extra validation check on incoming orders to ensure that all the product codes on them are recognisable and available to that customer. If a customer A attempts to order a product that is packaged in a way that means it can only be sold to customer B, or they attempted to order a product that has been discontinued, then the EDI system can send an automated e-mail to customer A asking them to correct and resubmit their order.
To do this, ZEDI will routinely use a “GET products” endpoint to get an up-to-date list of all the active products and customer-specific variants of them. It would then store this in a table so that it can be used to validate the incoming orders.
Similarly, it might be necessary to block the delivery of orders into the ERP for customers who are currently on credit hold. Again, ZEDI would regularly run a “GET customers” to get a current customer list, including their hold status, and store the information in a table. That table can then be used by the validation process to block orders from customers who are on hold.
By making your system’s API part of your EDI process, all sorts of unexpected but beneficial things become possible. All that’s needed is a bit of out-of-the-box thinking, and ZEDI to implement it.