{"id":817,"date":"2023-07-08T13:36:45","date_gmt":"2023-07-08T13:36:45","guid":{"rendered":"https:\/\/zedinet.com\/?page_id=817"},"modified":"2023-07-08T13:37:39","modified_gmt":"2023-07-08T13:37:39","slug":"application_apis_transcript","status":"publish","type":"page","link":"https:\/\/zedinet.com\/index.php\/application_apis_transcript\/","title":{"rendered":"Application APIs transacript"},"content":{"rendered":"
\r\n\t
\r\n\t\t
\r\n\t\t\t

Transcript of “Application APIs” video<\/h1>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n<\/div><\/div><\/div><\/div><\/div><\/section>
\r\n\t
\r\n\t\t
\r\n\t\t\t

Welcome back. In this video I\u2019ll be talking about application APIs and how their use can have major benefits for your business.<\/p>\n

If you<\/u> use a reasonably modern ERP system, there\u2019s a good chance it already has a REST API, just waiting to strengthen your business in new and cost-saving ways.<\/p>\n

A good<\/u> example is the Interprise system from ApexIT.<\/p>\n

Its REST<\/u> API has allowed us to build what might be described as an \u201cintimate\u201d interface that feeds data from traditional EDI orders directly into the system in real time.<\/p>\n

The EDI<\/u> messages are received and validated as normal and then mapped to the JSON format required by the API\u2019s \u201cPOST salesorder\u201d endpoint.<\/p>\n

In case you\u2019re not familiar with the term, an \u201cendpoint\u201d is section of an API that does a specific job, in this case it\u2019s used to create new sales orders. Interprise has a large number of these endpoints, over 250 at the last count, so there\u2019s not much that can\u2019t be automated if we needed to.<\/p>\n

The JSON version of the order is then sent to the API which immediately<\/u> responds with either an \u201cOrder<\/u> xxx created\u201d message, or an error message<\/u> that describes why the order could not be accepted.<\/p>\n

This is pure gold. Prior<\/u> 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.<\/p>\n

The EDI<\/u> system couldn\u2019t know for sure that each order had gone all the way through to the ERP, it simply had to hope for the best.<\/p>\n

Using the<\/u> 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.<\/p>\n

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.<\/p>\n

If an order<\/u> 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\u2019ll lose the customer.<\/p>\n

Knowing<\/u> the sales order number is also extremely useful in other respects. If the EDI system knows the customer, customer\u2019s order number and supplier\u2019s sales order number, and records this information in a register<\/u>, then when the invoice comes through for that sales order it can be matched to the original customer\u2019s order.<\/p>\n

This makes<\/u> 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\u2019s a good reason for this, but when it highlights an order should have been invoiced but wasn\u2019t, the quicker the business can know about it the better.<\/p>\n

Application<\/u> APIs also permit certain tasks to be automated that would often be perceived as outside the scope of EDI.<\/p>\n

A good example is the settlement<\/u> report generated by Amazon for each of its sellers.<\/p>\n

This report is typically generated every two weeks and lists the customer orders that have been handled by Amazon, together<\/u> with the fulfilment fees and commission incurred.<\/p>\n

We were asked to deliver a project for a customer who sells a lot of its products via Amazon. Manually<\/u> handling this settlement report was proving to be a particular drain on resources.<\/p>\n

We\u2019d already<\/u> used the Amazon API to retrieve information about customer orders each night and used it to create sales orders in the customer\u2019s ERP system. Because The orders were fulfilled by Amazon, the API could also be used to immediately<\/u> create invoices for those orders.<\/p>\n

So far, so good, but there was a slight problem. The process<\/u> couldn\u2019t accurately know what the Amazon fees and commission would be for each order, so the invoices couldn\u2019t include that information. Fortunately, this wasn\u2019t a major issue since the invoices would never actually be sent anywhere, they only needed to exist for accounting purposes.<\/p>\n

When the<\/u> settlement report came through, the fees and commission for each order would finally be known. The system<\/u> we created used the data from the settlement report to create credit notes in the customer\u2019s ERP for the actual fees and commission, again using the API.<\/p>\n

We can then<\/u> create a receipt for the amount of money paid by Amazon to the supplier, and allocate<\/u> the corresponding invoices and credits to it.<\/p>\n

Previously<\/u>, each settlement report required two days of manual effort from one of the businesses most experienced Financial Controllers. Now,<\/u> 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.<\/p>\n

As a result<\/u>, the Financial Controller has the bandwidth to focus on things that are far more beneficial to the business.<\/p>\n

One final<\/u> 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.<\/p>\n

In one<\/u> real-world scenario, it\u2019s 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.<\/p>\n

To do this<\/u>, ZEDI will routinely use a \u201cGET products\u201d 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.<\/p>\n

Similarly<\/u>, 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 \u201cGET customers\u201d 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.<\/p>\n

By making<\/u> your system\u2019s API part of your EDI process, all sorts of unexpected<\/u> but beneficial things become possible. All that\u2019s<\/u> needed is a bit of out-of-the-box thinking, and ZEDI to implement it.<\/p>\n\r\n\t\t<\/div>\r\n\t<\/div>\r\n<\/div><\/div><\/div><\/div><\/div><\/section>\n<\/div>","protected":false},"excerpt":{"rendered":"Transcript of \"Application APIs\" video Welcome back. In this video I\u2019ll 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\u2019s a good chance it already has a REST API, just waiting to strengthen your business in new and cost-saving...","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-817","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/pages\/817","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/comments?post=817"}],"version-history":[{"count":2,"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/pages\/817\/revisions"}],"predecessor-version":[{"id":819,"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/pages\/817\/revisions\/819"}],"wp:attachment":[{"href":"https:\/\/zedinet.com\/index.php\/wp-json\/wp\/v2\/media?parent=817"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}