Table of Contents

Order System

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.

Concept

1. Registering and providing the order for processing

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:

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

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

An Order for Several Business Transactions

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:


Implementation

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.

Notes on the Implementation

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


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.

Registration

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:

Order Workflow

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:

Output Services

Examples:

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.

Idle Services

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

Input Manager

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.

Interactive Transactions

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.

SRVSPT

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

SRVFIN

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.
.

Monitoring the Execution State

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.

Statistical Information

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:

Tables

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)