An order in this context is defined as an inherently closed work order given to a bank staff member. The work order may be triggered externally by the customer or by an internal action. An external trigger can be the receipt of an incoming message or a phone call from a customer, for example. An internal order may be triggered by certain deadlines being reached or by the start of a business transaction. A 'customer order' such as the amendment of a contract may consist of a number of orders executed one after the other.

1. Registering and providing the order for processing

2. Monitoring the execution state and controlling the whole processing time of a customer order. All orders are considered 'past due' if their target date is in the past and they have not been finalized as yet.

3. Collecting statistical information about processing time, idle time and throughput times

The functions required for creating and tracing orders are implemented in the application and can be disabled via a central rule. Using the static data transaction “Maintaining Orders” (DBxORD), new orders can be entered manually or existing ones can be amended / deleted. The transaction “Delete Order” (DBWORD) is used to set up an order workflow to finalize any process steps to be carried out prior to running the business transaction, and to define target execution times and monitoring functions. Detailed information about these topics can be found in the developer documentation about the Order System.

The Order System is made up of the order and the associated events.

Orders are created automatically when electronic messages are received or when transactions are started without taking up an incoming message.
Any change of state of the order results in the creation of an event record that includes the user ID, the new order status, the start and end dates, and the duration of the transaction.

The order information is automatically maintained across all transactions where several business transactions are required to execute an external order. Even if, for example, a business transaction has been sent for correction and is taken up again at a later time, all the information, from receiving the order until its completion, is available under one common order.

A customer order is considered to be technically “finalized” once the 'FIN' service has been run in the transaction workflow, the order has a status of 'FIN' (order closed), 'CAN' (order revoked), 'DES' (SPT deleted) or 'JOI' (joined) status. In all of these cases, the date of finalization is also fixed for the order. The date of finalization is set immediately before the service 'Clean up' (SRVCLN) in the transaction workflow (refer to Task Manager), but - depending on organization requests - could also be set as soon as all external messages have been sent.

The order data can be viewed, for example, via displaying the contract. The order to which the transaction was assigned is displayed in the “Completion” panel of the business transaction. Moreover, the Info system of the business transactions contains a clearly laid out “Order TreeView Panel” that displays the contract in connection with all orders / transactions settled under it as well as messages in an easy-to-navigate tree structure. Using this panel, all information on the individual orders can also be viewed.

• Order created (CRE): A new order was created using the transaction Creating a New Order
• TRN created (TRN): The order has now become a transaction; the order is now assigned to a contract
• To be corrected (COR): The transaction has been rolled back (e.g. Control and Release of Transactions)
• Deleted (DEL): The transaction has been deleted (e.g. Control and Release of Transactions)
• Order finalized (FIN): The transaction has run through the entire workflow
• Order cancelled (CAN): The order was deleted manually using the transaction “Delete Order”
• TRN released (REL): The transaction was released (e.g. Control and Release of Transactions)
• SPT deleted (DES): The associated SPT was deleted logically
• TRN interrupted (BRK): Saving of a (business) transaction was interrupted / paused
• Message received (INC): Using the transaction Manager for Incoming Messages, an order was created for a incoming message
• SPT released (SPT): The order was created with an SPT (e.g., via Routing of Pending Items, Icon ) or if it was determined that no order set exists yet for an SPT
• Signature (SIG): The transaction could not be released yet due to missing signatures or insufficient release authorizations
• Joined (JOI): The order was merged with another order because it logically relates to a different order set

By monitoring the overdue WFEs, overdue SPTs and ORDs are analyzed and displayed.

Technical details about implementing the Order System can be found in the Developer Documentation under “Order System”.