Document Service Basic Concepts
The document service is a generic multi purpose service to handle business documents such as sales orders, customer inquiries, purchase orders. The service allows you to create different kind of business document configurations.
We'll start with explaining common concepts shared across most business documents and how the Document Service should handle them.
A typical business document in a business process has at different stages different statuses. Consider for example a purchase order. First it would be in status "draft" , continued by "waiting for manager validation" to go on with statuses such as "sent to supplier", "delivered" and "closed". These statuses usually follow a predefined sequence (eg. it doesn't make sense to from status "closed" back to status "draf"). The status configuration holds this kind of configuration.
Even for a same type of business document different status configurations could hold, depending how the business document is processed. For instance, a sales order could be handled differently depending on the customer group. Hence we need a way to identify different kinds of configurations for a sales order. The business document type identifies a business document configuration.
Often a business document has associated items. A sales order can contain multiple products with different quantities and other item related data. The association between a document and document item is maintained by the document service.
A document item can also have an individual status. In the case of a back order, the related sales order item would need to be set in status 'Item In backorder - waiting for delivery'. Other items part of the same sales order could be set in status 'fulfilled' if the sales order can be partially fulfilled.
Documents can be related to each other. A sales order with items in back order could be linked to the purchase order for ordering the items in back order. The previous/next binary relationship is commonly used.
Multiple parties interact with business documents. Take the case of a sales order where the customer creates the initial sales order. He sales order is processed by a sales clerk and is linked to an account manager. A document partner is an individual or organization that is somehow linked to the business document. Multiple document partners can exist for a document over time.
The same employee can play different roles in different documents. For one sales order he might have the role of contact person whereas for another sales order he could be the complaint manager.
Documents are typically identified by an (alpha) numerical key used within a company. When communicating with external systems (ERP, manufacturing systems, third party services) other identifications numbers should be able to be attached to the business document as well depending on the business context.
Example of internal identification keys scenarios:
- Sales order with numerical incrementation over years: 10000, 10001, 10002, ...
- Invoices with incrementation restarting every fiscal year: 2011-00001, 2011-00002, ..., 2012-00001, 2012-00002
- Sales orders with different key ranges based on a business unit (region or product based split): EMEA-00001, EMEA-00002, ...., APAC-00001, APAC-00002, ...
- Sales orders with different keys depending on sales channel such as web or Point of Sales: WEB-00001, WEB-00002, POS1-00001, POS1-00002, POS2-00001, POS-00002.
External identification key scenarios:
- Shipment identifications
- Batch number in a manufacturing process
- ...
The document service should be able to validate whether or not a given document is valid based on customer specific business rules. Example of such rules:
- Field 'shipping location' is mandatory if status is 'ready for shipment'
- If document has been canceled, field 'reason for cancellation' is mandatory.