Table of Contents

General Information

Handling and Tracing Customer Orders (Order System)

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.

Targets

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.

General

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.

Overview of order statuses:

Further Comments

Watchdog - SYSWDR

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

Technical Details

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