Exchange Protocol Process

Definition

Exchange Protocol is the process of approving Oracle Receivables and Payables subledger transactions. Transactions are first grouped by a client, Payables supplier, or Receivables customer in documents called dialog units. The dialog units are then batched into a transmission unit, which is passed through a hierarchy of authorizers until the batch is approved.

Overview

The Exchange Protocol system is designed as a generic solution to be used by public sector clients using Oracle Financials where a sophisticated batch approval system is required. Exchange Protocol ensures that all subledger transactions within Payables and Receivables are carefully approved before being accounted for within Financials.

Exchange Protocol requires that all subledger transactions are batched for approval. The transactions are first grouped into predefined dialog units and then the dialog units are batched into transmission units. The process is as follows:

• Dialog unit types are created for an operating unit, which define the transactions to be included for the specific type. For example, the type DU-A may contain only Payables standard invoices, and type DU-B Payables credit notes.

• Transmission unit types are defined for an operating unit specifying which dialog unit types to include and the approval hierarchy to be used.

• A numbering system per operating unit is defined for each type of dialog unit and transmission unit. Public sector users require these documents to be sequentially numbered.

• Dialog units are created containing subledger transactions for an operating unit.

• The dialog units of each operating unit are included in transmission units and the batch is sent for approval using Oracle Workflow.

The Exchange Protocol workflow defines the approval process as follows:

• Create one or more position hierarchies for use in the approval cycle.

• Additional information is required to enhance the basic hierarchy definition. The user can create a profile for the hierarchy defining the following:

  • If the final approver in the hierarchy is only allowed acceptance status, for example, the approver is not able to reject the documents.

  • If legal numbering of documents is required. Many public sector users require a new legal number to be assigned to the batch when the documents are approved.

• At any stage in the approval cycle, the following actions can be taken by the approver:

  • Approve the transmission unit

    All dialog units are Approved and the whole transmission unit is sent to the next authorizer in the hierarchy.

  • Finally approve dialog units

    All dialog units are Finally Approved and the transmission unit status is Complete.

  • Reject the transmission unit

    All the dialog units are Rejected. The rejected dialog units are released from the transmission unit and the transactions within the dialog units are released. The transactions can be altered and are available for inclusion in another dialog unit. The status of the dialog units is set to Rejected and the transmission unit is set to Complete.

  • Partially reject

    Some dialog units are Rejected and some dialog units are Approved. The rejected dialog units are released from the transmission unit and the transactions within these dialog units are released. The transactions can then be altered and are available to be included in another dialog unit. The transmission unit, now containing only the approved dialog units, is sent to the next authorizer in the hierarchy.

    Note: If a legal number is generated, then the dialog units remain with transmission unit even if the dialog units are rejected, else the dialog unit is released from the transmission unit.

  • Partially place on hold

    Some dialog units are placed On Hold and some dialog units are Approved. The dialog units on hold are released from the transmission unit but the transactions stay within the dialog units. The transactions can then be altered and included in other dialog units. The transmission unit, now containing only the approved dialog units, is sent to the next authorizer in the hierarchy.

  • Return the transmission unit

    The whole transmission unit can be returned to the previous approver.

• When the final person in the approval cycle approves or accepts a transmission unit, the following happens:

  • The status of the transmission unit is set to Complete and the status of the dialog units within it are set to Complete.

  • The transactions within approved dialog units are set to Approved or Completed.

Note: Subledger transactions can be posted without approval in the Exchange Protocol workflow. To do this, navigate to the Invoice Hold and Release Names window and deselect the Allow Accounting option for the Core Holds. This ensures that unless the Exchange Protocol hold is released through the approval process the invoice cannot be accounted and posted.

Exchange Protocol Process Flow Diagram

The diagram below shows the Exchange Protocol process flow, described in the accompanying text.

Exchange Protocol Process Flow Diagram

Exchange Protocol Processes

Define Hierarchies

The approval process using Oracle Workflow requires that a positional hierarchy is created to define the document flow within the client’s approvers. This work structure defines jobs, positions within the jobs, and a hierarchy of positions. The employees are assigned to positions and a user identity is assigned to an employee.

The user must set up at least one positional hierarchy to be used as an approval cycle. However, if documents require different approval cycles, then many hierarchies can be created. For example, a batch of Payables invoices may need to be approved by several levels of accounts managers, but a Receivables invoice may only need approval from a single manager.

If the Oracle Human Resources system is installed, then the work structure that forms the basis for creating positional hierarchies can be activated using this system, if not, the Oracle Purchasing setup workflow structures system can be used.

The work structure is set up as follows:

• Job window

  Users must set up jobs to be used, for example, authorizer, and manager.

• Positions window

  Positions are defined as positions within the jobs, for example, Authorizer - Clerk and Authorizer - Supervisor are within the job Authorizer, Manager within the job Manager.

• Employees window

  Employees are defined within the positions, for example, employees A and B are Authorizer - Clerks, employees C and D are Authorizer - Supervisors, and employees E and F are Managers.

• Position Hierarchies

  The diagram below defines an example of a position hierarchy used by the approval process.

Position Hierarchies

The following step is required to create the work structure:

• Associate the employees with user identities, for example, create a logon user identity of USERB and assign employee B to USERB.

For information on creating job descriptions within work structures, see Enterprise Modeling, Oracle Human Resources Management Systems User's Guide.

For information on creating position descriptions within work structures, see Enterprise Modeling, Oracle Human Resources Management Systems User's Guide.

For information on creating position hierarchies within work structures, see Enterprise Modeling, Oracle Human Resources Management Systems User's Guide.

Define Profiles for Exchange Protocol

Workflow profiles must be defined for each positional hierarchy.

This process adds the following additional features to the approval cycle:

• The French public sector users require that an additional legal number is associated with each dialog unit number and transmission unit number when the final or principal authorizer has approved the batch.

• In France and other European countries, if payment of invoices is actioned by a central treasury department, then the final approver, called an account officer in France, can only accept the transmission unit for payment, and can not approve or reject the batch.

The information required to create a workflow profile is as follows:

• profile name; for example, EXP-1

• position hierarchy; selected from a list of the position hierarchies created

• optional final approver position. To be defined if the last approver can only accept the transmission unit previously approved by a principal authorizer.

• optional legal document position. In some countries it is necessary to assign an additional reference number to the exchange protocol documents. This legal number is assigned at a pre-specified stage in the approval cycle. For example, in France, the legal number is assigned after the principal authorizer has approved the batch and before the batch is passed to the account officer.

• view hierarchy; allowing drill-down to view the selected hierarchy

For example, using the hierarchy department A, the entries would be:

• profile name, EXP-1

• hierarchy, department A

• final approver, Manager

• legal document, Authorizer - Supervisor

For information on the workflow hierarchy, see the Workflow Hierarchy diagram.

For information on defining position hierarchies, see Define Hierarchies.

Define Dialog Unit Types

The user must define which subledger transactions are to be grouped together belonging to an operating unit for a client. This process is the creation of dialog unit types. When the Exchange Protocol functionality is used all subledger transactions require approval using this requirement, therefore all transactions must be included in at least one dialog unit type.

Dialog unit types are defined as follows:

• dialog unit type; a descriptive name

• transaction type; one or many selected from a list of all available transactions

The table below shows an example of how the dialog units are created.

Dialog Units

Dialog Unit Name	Transactions
DU-A	Payables invoices
DU-B	Payables invoices, credit notes, and debit notes
DU-C	Receivables invoices, credit notes, and debit notes

Define Transmission Unit Types

The user must define each type of transmission unit to be used in the system for an operating unit. This process defines which dialog units are batched together for approval.

Transmission unit types are defined as follows:

• transmission unit type; a descriptive name, for example, Mandate-Batch

• dialog unit type; one or many selected from a list of all available dialog unit types

• profile hierarchy; the approval hierarchy to be used with this type of transmission unit, selected from a list of available positional hierarchies

The table below shows an example of how transmission units are created.

Transmission Units

Transmission Unit Name	Dialog Units	Hierarchy
TU-A	DU-A, DU-B	Department A
TU-B	DU-C	Department B

Define Exchange Protocol Numbering

Users can set up a numbering sequence for each type of document of an operating unit. This number prefixes and suffixes a sequential count of all dialog units and transmission units created during the Exchange Protocol process for the financial year.

Document numbers within Exchange Protocol are defined as follows:

• exchange protocol type

  There are two types of exchange protocol type: dialog unit or transmission unit.

• class

  Actual; at creation and during approval by authorizers.

  Legal; optional, to be allocated after approval by the specified approver.

• document type

  The document type is linked to the predefined transmission unit and dialog unit types.

The information required for exchange protocol numbering is as follows:

• prefix

  The prefix precedes the sequential number; for example, Def.

• suffix

  The suffix describes the documents; for example, Mandate.

All of the available document types within the dialog unit and transmission unit structures must have a unique numbering system applied for each financial year.

The table below shows an example of Exchange Protocol numbering.

Exchange Protocol Numbering Example

Exchange Protocol Type	Class	Document Type	Prefix	Suffix	Year	Numbering Created
Dialog Unit	Actual Legal	DU-A DU-A	ActDef	MandateMandate	2001 2001	Act1Mandate2001 Def1Mandate2001
Dialog Unit	Actual Legal	DU-C DU-C	ActDef	Payback Payback	2001 2001	Act1Payback2001 Def1Payback2001
Transmission Unit	Actual Legal	TU-A TU-A	ActDef	Mandate Mandate	2001 2001	Act1Mandate2001 Def1Mandate2001

Exchange Protocol Approval Process

Transaction Entry

All transactions are usually entered in the subledger. When the user approves the subledger transaction, a document hold is automatically applied to the transaction. This hold can only be released by the Exchange Protocol approval process. The transaction is then paid in Payables or completed in Receivables.

The transaction entry process applies to both Payables and Receivables; for example, invoices and credit notes. The following in an example of the transaction entry process:

1. Enter a Payables standard invoice for a supplier.

2. Approve the invoice.

3. Apply an exchange protocol hold to the invoice.

   The hold cannot be manually cleared, it must be cleared by Exchange Protocol approval.

For information on transactions, see Enter Transactions, Oracle Receivables User's Guide.

For information on invoices, see Entering Invoice Batches in the Invoice Workbench, Oracle Payables User's Guide.

Dialog Unit Creation

The first stage in the Exchange Protocol process is to create a dialog unit. A dialog unit is a collection of transactions requiring exchange protocol approval, for example, all standard Payables invoices for a supplier. The process is as follows:

1. Select the document type to be created. This predefines which transactions are to be included in the dialog unit.

2. Select a supplier or customer. All available transactions are then included in the dialog unit.

3. Exclude individual transactions before creating the dialog unit if desirable.

4. Assign an actual number to the dialog unit.

Transmission Unit Creation

The second stage in the Exchange Protocol process is to create a transmission unit. A transmission unit is a collection of dialog units requiring exchange protocol approval. For example, all dialog units containing the document type, Mandate. The process is as follows:

• Select the document to be created. This predefines which dialog units are to be included in the transmission unit.

• Exclude individual dialog units before creating the transmission unit if desirable.

• Optionally, amend the positional hierarchy to be used in the approval cycle.

• Assign the transmission unit an actual number and transmit for approval.

Exchange Protocol Approval

Transmission units are approved through a workflow process. The transmission unit enters the workflow at the point where the transmission unit user exists in the hierarchy. The next user in the hierarchy is sent a notification to approve or reject the transmission unit.

If rejected, a notification is sent to the user who raised the transmission unit. If approved, a notification is sent to the next position in the hierarchy, if there is more than one user defined for the position then a user must be selected, until all users in the hierarchy have approved the transmission unit.

The approval process using the workflow hierarchy, including the special features for the French public sector, is shown in the diagram below.

Workflow Hierarchy

The Workflow Hierarchy diagram, assumes that the profile defines the Manager as the legal document numbering position and that Account Officer is a final approver. The following actions describe the process:

1. The Authorizer - Clerk creates a transmission unit numbered Act16Mandate2001 and submits it for approval.

2. A notification to approve is sent to the Authorizer - Supervisor, who drills down to the transmission unit to view the details and approve the dialog units.

   From the Notification Details window, the approver can drill-down to the individual documents within the list of dialog units in the transmission unit.

   If an individual dialog unit is rejected, all transactions within that dialog unit are released and made available for inclusion in a future dialog unit.

3. The Authorizer - Manager receives a notification and also approves the transmission unit, the additional legal number is now assigned to the transmission unit and all the approved dialog units; for example, Def16Mandate2001.

4. A notification is sent to the Account Officer. This stage is called the point of acceptance. The Account Officer can only accept the transmission unit, complete the process and return a completed notification to the Authorizer - Clerk.

   This notification can contain instructions to the originator if the Account Officer requires changes to be made. For example, if an incorrect account has been used on a Payables invoice, the Account Officer can request issuance of a credit note and a new debit note created to correct the account.

5. When the exchange protocol process for the transmission unit is complete and all dialog units within the transmission unit have been approved, the status of all the transactions within the approved dialog units is set to Approved or Completed.

Year End Process

Exchange Protocol Numbering

New numbering schemes should be created for all dialog unit and transmission unit types for the new financial year.

Dialog Unit Creation

The financial year is specified when a dialog unit is created. The dialog unit can only include transactions for the specified year. This ensures that transactions in different years are kept separate at the change of financial year.

Transmission Unit Creation

A transmission unit can only contain dialog units for the same financial year.

Approved Documents

When documents have successfully completed the approval process, the General Ledger effective date is updated.

For documents in the current year, the General Ledger date is set to the current date.

For documents in a previous year, the date is set to 31 December in the current year minus 1. For example, in a transmission unit dated 2002 which completes the approval process on 20 January 2003, the transaction dates are set to 31 December 2002, assuming that the accounting period is still open.