Order Capturing

By | October 22, 2015

Today we are going to talk about Order Capturing from the Order Management domain.

What is an Order?

When you ask this question to the customer, he/she will reply, it is the collection of goods and services I am demanding from the provider.

However, from the Provider (and also Order Management) perspective, it is more than that. Order is a complex data structure which includes goods/services that are demanded plus any additional information such as shipping, payment, service location etc. that will help with the fulfillment of the order.

At the end of the day, the primary responsibility of Order Management is to run the necessary orchestration and fulfill an order. It does so by interfacing the infrastructure (network, IT, OSS/BSS), functional groups in the organization, customer and other enabling organizations (shipment providers, payment providers etc.)

Most of the time, the Order’s primary components are the goods/services. These goods and services should be presented in the Product Catalogs, so that the customers can browse and pick the ones they need. At this “selection” stage, we tend not to call these selected items as Order yet, rather we tend to call it Cart. (We also see the terms Shopping Cart and Basket which refers to the same concept)

So, the customer-selected products are placed to a Cart object.  After the customer is done with his selection, this cart should be freeze. This stage is called “Checkout” phase. Most of us know this from our online shopping experiences. At some moment we are asked to hit the “Checkout” button. After the checkout stage, we cannot (or supposed not to) change what is inside the cart. (Why is that? Because Cart belongs to another domain: Catalog Management. The items, the rules between the items, the checks that are done against these items are all reside at the catalog side and we will be using its’ interfaces to construct our Cart object. We cannot change anything in this goods/services list before consulting the Catalog Manager. If we do so, we will break the integrity. We checkout, to leave the Catalog Management domain and enter to another domain: Order Management.)

Can this checked-out cart object be sent to the order management right away? No, because we do not know how to fulfill it yet. We can instantiate the products for that customer but how their rates will be collected? If there are physical goods in the list, where they will be shipped to? Without this additional information, the order cannot be fulfilled. That’s why, the Order Capture platform, will also attempt to collect these details. Some basic validations can also be done at this stage (other than the Catalog Validations, which I will write in another blog post)

The Order, prepared at the Order Capture platform (which includes Cart Information + Additional Information + Customer Information) can now be sent to the Order Management for fulfillment. The OM platform will return an identifier to the Order Capture platform to be used for future queries regarding that specific order. Most of the times, the Order Capture platform is also triggered asynchronously about the key status changes of the order at the OM side (Pending, Error, Cancelled, Success etc.)

Order Capturing, is mostly achieved by CRM systems and Enterprise Portals which allow customizations. In the absence of such system, some add-on tools offered by most of the OM providers can be used. Regardless of the tool type, we should be ready for heavy customizations as each provider’s way of handling the orders differ from the others.