The Order system is used for processing and tracing orders.

The core functions are implemented in the DOKA standard. Further functions are conceptually intended. Sample implementations are available and have to be customized for individual projects.

1. Registering and providing the order for processing

• Automatic creation of orders in managers for incoming messages
• Automatic creation of orders on manual registration of documents or graphic files
• Automatic creation of orders when starting a business transaction without taken-up order/incoming message
• Manual creation of orders when receiving telephone or letter messages

2. Defining and processing an order workflow

Various actions that are required for processing an order can be organized in a (partial) workflow, which has to be processed, before a DOKA business transaction can be started.

Afterwards, the order runs through the following steps:

• Registration with creation of the order workflow
• Processing various outgoing, waiting and incoming services of the order workflow
• Service SRVSPT = Completing the order workflow, deleting tables WFS and WFE and creating an SPT record
• Record is called from the incoming tray in SPTSEL by the clerk
• Processing the business transaction
• Processing the TRN workflow items automatically one after another
• Service SRVFIN = Setting the order to 'done'

3. Monitoring the execution state and controlling the whole processing time of an order

• Defining and using the target execution date to prioritize the processing steps
• Measuring compliance with Service Level Agreements
• Avoiding to exceed the desired total processing time by timely identification of critical (potentially late) partial states
  

4. Collecting statistical information of processing, idle time and throughput times

Under certain organizational circumstances, several business transactions may want to be considered together in processing a customer request, i.e. in contrast to the information described above, that serveral TRN have the same order record - e.g. that xxxRAM and xxAME share the same common order record.

If xxxRAM and xxAME are not to be treated as one customer order, for instance, a new ORD record has to be generated when the autoregistration is triggered, instead of using the RAM ORD record again.

When making the required adjustments in the project phase, the following issues need to be taken into consideration:

• When should the FIN service be carried out for the order record?
• Are there any knock-on effects for stastical reports caused by the waiting times between TRNs?
• How are conflicts to be managed that may arise between SLAs (guaranteed overall lead times, for instance) and waiting times between business transactions that are not caused by the bank?

The functions that probably have to be customized or to be used can be found in the ORDMOD module.

The activation of the entire Order system is done centrally via the init rule ORDMOD.

The access to the ORDs is implemented in the business transactions, SPTSEL, TRNREL and all relevant INF transactions.

DBxORD maintenance programs for ORD (for system administrators) are available. Furthermore, INFORD can be used for displaying orders.

The functions required for handling the ORDs are implemented (as static functions) in ORDMOD. The typical sequence is:

1. Initialization step
2. ORD amendment
3. Update (incl. continuous update of the status)

1. Possible functions for the initialization step:

“ORDNew”
“ORDUpdate” has to create a new ORD record.

or

“ORDReadHold”
Reading and Locking an ORD for modifications within the TD-Basic rules. If user interactions are possible, “RDReadLock” has to be used.

or

“ORDReadLock” Reading with Lock
The ORD record will be read and locked for interactive modification. Caution, this triggers an implicit “DBCommit”!

2. After one of these actions the fields in ORDMOD\ORD can be modified/amended directly (except STA, INR).

3. The function “ORDUpdate” is used to

• set the status of the ORD record
• write the ORD record
• write an ORE (Order Event)
  

At any time, the initialization for an ORD record can take place. A possibly existing lock will then automatically be switched off. When completing a transaction, a “DBFreeAll” can be executed instead of an update.

The database table ORD ('Order') represents the customer order, like it is received via electronic medium or via telephone/letter like it is entered when registering documents or images. In case there is no order when executing a transaction (i.e. the TRN is not created by taking up an SPT), an ORD record is created automatically on save/break, so that the transaction processing (Break, Rejection in the release process, Taking-up) can be watched via the order history.

Triggered by an order, one or multiple (if and only if registered transactions are sent to correction) processings of business transactions (TRN records) are created. Only one TRN can be completed for one ORD record.

The registration can be done via an interactive transaction or automatically via a manager for incoming messages. The automatic registration is performed in the incoming managers e.g. in 'Manager for incoming Messages' (SWITSK) and the manual registration has to be customized for each project based on the prototype DBMORD. In doing so, the following steps are taken:

• an ORD record is created
• the tables WFS and WFE are created with object ORD
• an SPT is created at that point in time when using an order workflow, but it is set to 'Hold' by SRVSPT until completion.

This is the technical framework for implementing the processing steps, that have to be carried out by DOKA business transactions.

In the order workflow the following prototypes/individual functions are available:

Examples:

• Email confirmation on receiving the order is sent to the customer
• Internal Email with orders for other departments
• Writing ACK records, so that it can be waited for secondary incoming messages

The output services of the order workflow (before the transaction) are processed by transaction ORDTSK. The processing of the services by MGRTSK can be implemented.

Special Case: SRVPDS and SRVFIN both process the service for the business transaction, but also update the status of the associated ORD record, if such a record exists.

Standard PDx services that ensure to wait for incoming amendment messages/confirmations/acknowledgments.

For secondary messages that are, for example, replies to internal notifications. The content of such secondary messages can, for example, be used to amend the ORD record with additional information.

Permit/accompany manual extra work (e.g. scanning documents) based on WFEs (e.g. scanning documents). ORDSMP is available as an example and needs to be customized depending on the given project.

Transaction DBWORD (considering its functions, it equals DBWTRN) is used for modifying the order workflow.

This service substitutes the functionality of the input manager for an installation without order workflow and executes the following actions:

• Creating an SPT record
• Filling the BIMEMU structure with values out of the original incoming message
• Filling applicable BIMEMU\SWIADD fields with additional content out of the ORD record (alternatively, the business transactions can directly access values of the ORD record)

This service signalizes the completion of the customer order from the view of the customer. According to organizational requirements, this service can also be positioned at an applicable spot in the TRN workflow. Typically it is positioned directly before SRVCLN, but it can also be set behind the services that are sending messages.
.

The (optional) service 'FIN' in the transaction workflow sets the status to 'done' in the associated ORD record and the completion date (directly before SRVCLN in the TRN workflow, however, according to organizational requirements, it could also be processed when all external messages have been sent.)

The correct positioning of the 'FIN' service is the prerequisite for monitoring the execution state of Service Level Agreements of the relevant organization.

By monitoring the overdue WFEs, overdue SPT and ORD are analyzed and displayed.

In every change of state of the order an Order Event (ORE) is created. The respective duration (from taking-up until cancelation of the transaction) as well as the idle time in the state reached beforehand (e.g. the time how long the order had to wait before it has been taken up interactively or it has been signed) is stored in the Order Event record. Through this, a data pool for analyzing the throughput is created, out of which the total throughput time is made up of.

Via the fields ORD\DUR, ORE\DUR and ORE\WAI the following information can be analyzed:

• How long lasted the actual (interactive) processing in each single processing step.
• How long lasted the total elapsed time for handling an order.
• How long was the idle time for each step until completion (ORE\WAI).

Table ORD - (Customer) Order

Project-relevant fields have to be added to table ORD, if required. These fields are usually filled within the 'Order-Workflow' framework.

Table ORE - Order Event (Individual records of the customer order - ORD)