In the orderflow we make a distinction between order types. On the send side this is mostly related to where we are in the process and what is the data needed in this step. In the case that we “functionaly” explore a order flow we start with:
- the quotation towards the customer.
- If the customer approves this quotation it can be transformed in to a Order.
- If the order is accepted and picked the customer can be invoiced.
- Once the invoice is approved a financial mutations is created in the corresponding ledger.
Basically this is the complete process of an order flow. Within APIcenter we determine in what stage we want to add our “order data” and there are a few differentiation functional wise to have it posted in the correct format.
Which order types are available depends on the combination of applications you use.
“Quotation”
If a application supports quotations via the api we use the source data and make a quotation in to the target systems. Logical integrations for these are CRM packages where the customer is send a quotation from the CRM and finance wants to have that data in their ERP. Or the customer requested a quotation in their ecommerce system and want it send towards theire CRM system for follow up.
- Product data needs to be in sync between both systems. If a product doesn’t exist we will throw an error in the validation process.
“Order”
Most of the integrations we make will make use of the Order type “Order”. If a order is placed in a webshop and paid, it needs to be send to the ERP and the warehouse system to have its follow up. Customers are invoiced from the ERP system. Logical Integrations are Ecommerce towards ERP or POS systems, but also CRM systems that have the status won and want their quotation converted to a order in the ERP system.
- Product data needs to be in sync between both systems. If a product doesn’t exist we will throw an error in the validation process.
“Invoice”
There are ERP systems that support a seperate invoice API where, we create an invoice in the system. This is normally the step after a order is created and picked/packed shipped. Generally this does not create a stock mutation in the target system as we post the data after this normally happens.
- Product data needs to be in sync between both systems. If a product doesn’t exist we will throw an error in the validation process.
“Direct Invoice”
There are ERP systems that support a seperate Direct invoice API. A direct invoice is comparible with a cash order and manual transaction with the customer. There is a handover of material and direct payment. This should adjust the stock and create directly the corresponding booking in the ledger. You can state it is a combination of the order/picking and invoicing at once.
- Product data needs to be in sync between both systems. If a product doesn’t exist we will throw an error in the validation process.
“Sales Invoice”
A Sales Invoice differs from the normal invoice by the fact it doesn’t need articles to create an invoice. The accounting is created based upon standard defined values in the target system and most of the time by the values that are set upon the customer. This is mostly used between systems that dont manage products and sell for example services. The most integrations that make use of this are between CRM systems and ERP systems. As long as the send side supports the sales invoice it can work with every combination of integrations.
- Product Data is not needed in this type of booking we create a line without an article /sku on it
“Financial Mutation”
This is normally the final step in the process and that is the actual adjustment in the ledger. Via this way me create a booking directly in to the ledger, if a financial mutation is supported we differentiate in the type of the mutation we do we make a difference in the complexity:
- Simple; this is a booking that is customer top revenue so for example
- Recommended; this is a booking where we split revenue in a tax part and revenue part
- Advanced; we also split up the value per “cost” revenue line like shipping/fee’s etc
- Extreme; in his case there will be per line item a line in the financial mutation, this is not recommended as these create possible issues with balancing the mutations due to calculation difference between source and target systems
Product Data is not needed in this type of booking we create a line without an article /sku on it