Skip Headers

Oracle Order Management User's Guide
Release 12.1
Part Number E13408-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Tracking Changes through Order Actions

Versioning Overview

Versioning is a method to capture changes and updates made to any transaction, that includes sales orders, quotes, and Sales Agreements. Creating and managing versions can be of great assistance during the negotiation phase of any transaction and helpful when maintaining history throughout the life of a sales order, quotes, and Sales Agreement. The history of changes that are made to a transaction are captured and stored, available to be viewed and compared later. Depending on the set up in the Processing Constraint Framework, changes can automatically trigger versioning or you can choose to manually version the transaction.

In quotes and Sales Agreements, versioning helps to manage extended negotiations between the customer service representative (CSR) or sales representative and the customer.

Both the quote and Sales Agreement have a formal negotiation phase where versioning can be used. You can create new versions to thereby capture changes made to the transaction and have the ability to compare versions to contrast the changes between versions.

You can view previous versions and create new versions automatically for all three transactions: sales order, quote, and Sales Agreement. You can view a previous version irrespective of whether it was created manually or automatically.

Example: The customer calls in for a quote on insurance, selects coverage, and the Quote, 49876: version 1, is prepared by the CSR. The customer decides to amend the coverage, the CSR inputs the change Order 49876: version 1 saves the change and a new version of the Quote, 49876: version 2 is automatically generated. (Version 1 is stored in history and can be compared against version 2 using Version History window). The Quote, 49876: version 2 is sent for the customer's approval. The customer calls back and approves to confirm the Quote, 49876: version 2. (The item field had been set up to automatically trigger versioning, when any item is amended).

Versioning Major Features

You can automatically generate or record a version manually, that can be amended if the amendment does not violate a processing constraint or the responsibility is authorized to make the change. Sales Agreements and sales orders currently support manual revisions and now incorporate automatic versioning functionality and the ability to view version history.

Version Generation

Versioning will default a whole number, the initial version will always be 0. The version field is a hidden attribute that can be displayed via folders and positioned to the right of the document number next to the sales order number, quote number, or the Sales Agreement (Sales Agreement). You can however, enter any number manually to create a new version, but this number must be greater than the current one. Automatic versioning can be set up via processing constraints to support automatic generation.

Note: Existing upgraded orders will have the version number of 1, while new orders will begin with 0.

You can update a version manually at any time unless a processing constraint has been defined to disallow the action. You can disable versioning completely, or just manual versioning. You can restrict automatic versioning to increment when a specific attribute is changed, for example: a client may wish to increment a version when a change is made to:

Note: If processing constraints have been defined you cannot disable versioning. There is no single control feature to disable this feature

When a version is updated you may amend the quote or Sales Agreement name but the original name will be retained on the former version.

Version History

Quotes and Sales Agreements (Sales Agreement) have a negotiation phase, a phase that can prove to be volatile as with more complex products, and can be continuously re-engineered before the document is approved.

An historical view of the life of the quote or Sales Agreement is available and can be printed. Previous versions of the transaction are retained in history and it can be viewed whereas the current version of the sales order, quote, or Sales Agreement are available to amend as required.

Only the active version can be amended/maintained. Previous versions are for reference or templates for creating new sales orders, quotes, or Sales Agreement via copy.

Searching

Find window has the version number field as one of the search fields. If the version number is not entered then only the active versions of the quote or sales order will be queried/displayed in the Order Organizer. Through the Order Organizer and Sales Orders window a drill-down capability is provided to review the prior versions.

When a prior version number is specified along with some other search criteria and a find operation is performed, the Version History window displays instead of the Order Organizer. Version History window lists all the orders/quotes that match the search criteria in a tree region and the specific version that was queried is available as the child node for each of the quotes. By selecting each of the tree nodes, you can traverse across orders to look at the specific version. Sales Agreement provides a similar view from the sales agreement Organizer.

Search and Compare

When you initiate a find and select the version history action the Version History window opens.

Prior versions are displayed on the tree and you can view any version with a click of the mouse. The display tree contains a fulfilment node listing versions of the order and a negotiation node if a quote and multiple versions exist.

Version History Window

the picture is described in the document text

From the Version History window you can select a version and compare it against previous or latter versions, by using Actions > Compare. The Compare screen is split into header and line regions. If you enter this screen while on the details of version 2 this column becomes fixed and you can use the directional arrows to look at previous or later changes.

Version Comparisons Window

the picture is described in the document text

Line Splits

You can define a constraint to generate a version on a line split, but manually split lines may result in multiple lines with a single version. If a line is split and another attribute that is under a constraint control is amended, the version will be incremented by two.

Automatic line splits will not generate a version irrespective of any constraint as system splits do not validate against processing constraints.

Sales Order Versioning

When the quote transitions to a sales order, the latest version of the quote is carried over.

Note: To automatically version during the transition to fulfilment a constraint must be defined to generate version on update at transaction phase attribute.

All edit rules for the quote will apply to the sales order except for going back to the Draft status to amend the order. Constraints will control where and when the amendments may be made.

Once the customer accepts the quote, workflow will convert the quote into an order. This will trigger the change of the transaction phase from negotiation to fulfillment.

Capturing Reason and Comments for Versioning

You can capture the Reason for changes made to a transaction, determined by setup in the Processing Constraint Framework, and these are available on all Entities supported for versioning.

Versioning can also automatically increment because of system changes. A typical example is when changes to a non-versioning attribute triggers clearing and re-defaulting of the attribute that is set to increment the version. In such cases if reason is required it will be enforced.

You can enter/update a Reason and Comments for any change.

Note: There will be a seeded constraint requiring a reason for manual versioning. Comments are always available as an optional field.

Changes specific to Quick Sales Orders window for Manual and Automatic Versioning

An action Create Version exists. This can be accessed from the Actions button, right mouse menu, and also can be displayed as a button using the configure button feature. The button when clicked opens a window where the reason and comments can be entered for automatic versioning. The version number will default to the next higher version. For manual versioning, version number can be entered even in this window in addition to the order header region. The reason and comments field are available on the order header also. They are hidden by default on the order header.

The Create Version button is available from the Sales Credits & Price Adjustments window. The reason, comments & version number information for manual versioning can be entered in the window without navigating back to the order header. If the version number is entered in the Version Control window, the version number on the order header will also reflect the change.

For automatic versioning, if an attribute is changed, a pop up window indicating the incremented version number and asking for reason (if it requires a reason) opens up when the user saves the transaction or navigates to the other block (header to line or vice versa) or clicks the Actions button and invokes the Version history window. If multiple attributes are changed which cause version increments, you have the option of capturing these in a single version or capturing the individual changes as separate versions. If you wish to capture all the changes in a single version, entering a reason once when the version and reason window first pops up, is sufficient for the transaction. The version window will not appear for subsequent attribute changes. If you wish to have separate versions for each attribute change, then you should save the transaction every time after you have changed an attribute and provided the reason (if it is required as per the processing constraints framework) in the version window. A version can be generated manually by selecting the Create Version action. You enter a version and reason code. If you override the version in the header block, then when you navigate from that block, the same window will open allowing you to select a reason.

Manual versioning always requires reason. If a version number is entered and saved without the reason, the Version Control windows will appear automatically. The Version Number field will be populated with the value that was entered on the order header. All these changes are applicable for the current Sales Orders window.

Quick Sales Orders Window - Enter Reason For Window

the picture is described in the document text

Viewing a Quote from Sales Orders

Once a quote is transitioned to a sales order, the quote is backed up to history and is no longer available to be viewed directly in the Sales Order Pad. A quote can be viewed by button called View Quote from the sales order. This is available in the right mouse menu and also in the Actions button. The view quote will launch the Version History window, with the last version of the quote being selected and displayed in the Version History window.

Note: A quote and sales order may have the same version if the version is not updated when a quote converts to a sales order depending on the processing constraints set up for the transition from quote to sales order.

If the same version exists for a quote and sales order, then there will be subnodes called Quotes and the other Sales Orders where the respective version of the quote and sales order are displayed.

Versioning History in Quick Order Entry and Sales Agreements Window

A historical view of the previous versions of the Sales Order or Quote can be viewed through the Version History window that will be available from the Sales Order window, Order Organizer when multiple versions exist for the transaction. For Sales Agreements, this Version History window is accessed from the sales agreements & sales agreement Summary window. Only the current version is the active version. All other prior versions are available as read only. Only the active version can be viewed in the Sales Order window or Sales Agreement window (transaction windows). The version number field is disabled in the Transaction window when you switch to the query mode as the query of only the highest version of the transaction is supported from the Transaction window. For viewing prior versions a drill-down capability will be provided and all the prior versions will be displayed in a separate window.

The Version History window displays the headers, lines, price adjustments, and sales credits information. All the information displayed in this window is read-only and cannot be changed.

The window is also accessible from the Quick Sales Order window and Quick Order Organizer through a separate button, right mouse menu and also through the Actions menu from the header, lines, price adjustments, and sales credits regions. The Version History window uses the tree structure to list all the different versions related to the transaction. The tree structure is displayed on the left side of the window. To the right side of the tree the header and lines information corresponding to the transaction highlighted/selected in the tree region is displayed. Using the Expand/Collapse mode, we can review addition information for the quote/order in the line details region. The additional line details that can be viewed in this mode are price adjustments for orders/quotes.

The tree region in the version history window when accessed from the Quick Sales Order window, lists all the versions corresponding to the current order/quote displayed in the Quick Sales Orders window. By selecting/clicking on the nodes corresponding to each version, we can look at the specific version of the quote/order.

The tree region in the Version History window when accessed from the Quick Order Organizer lists all the versions corresponding to the orders/quotes that match the search criteria entered in the Find window. The order/quote nodes are displayed as collapsed. By expanding the orders/quote number nodes, the versions corresponding to that particular order/quote can be viewed. By selecting/clicking on the nodes corresponding to each version, you can look at the specific version of the quote/order.

View Version History Window - Sales Agreements

the picture is described in the document text

Actions/Operations Allowed On Prior Versions

Version history window will provide access to the Copy feature. Using Copy functionality, a prior version can be copied into a new sales order or quote.

For Sales Agreements, a prior version could copy the sales agreement header, sales agreement lines and terms and conditions into a new Sales Agreement.

Mass Change

Version Reasons and comments have been added to the Mass Change window to provide the option to enter the reason and if mass change will trigger a new version creation for the transaction.

Changes to Processing Constraints Setup Window

Automatic versioning is available through the Processing Constraints Framework. To keep the setup simple and separate, you can specify business rules for automatic versioning separately. You can specify it in the User Action field. You can select Generate Version or Requires Reason and Generate Version.

A new field Applies To is on the window.

For Sales Transactions you can set it to:

For Sales Agreement you can set it to:

User Procedures

To perform manual versioning:

  1. Create and save original transaction (Sales Order, Quote, Sales Agreement).

  2. Make changes to the transaction. (Steps 2 and 3 are interchangeable).

  3. Manually select the create version action and enter a new version number, Reason, (mandatory) and Comment (The default version number is 0; the user can override this with l). Alternatively override the version number and at save, the reason window will open to allow entry.

  4. Save the transaction. The user transaction is the active version. The original transaction is backed up as history.

Note: The Cancel operation always requires a reason to be specified. For cancellations, the reason is captured either through the Reason & Comments fields on the line or through the Cancellation window. Only if there is a versioning constraint set up on the cancel operation that requires a reason, then the reason is captured through the Versioning window or the reason is captured either on the line itself or through the Cancellation window.

To set up automatic version generation:

Note: There is a seeded processing constraint which will not allow changes while in the Pending Internal Approval status. Additional Processing Constraints can be created for any additional status where your business process would not allow changes. An example of this is the Customer Accepted status.

You can use the Security Framework to specify the business rules that will automatically increment the versions on a transaction. The following entities are available for setting up automatic versioning in sales orders and quotes:

The following entities are available for setting up automatic versioning in Sales Agreements:

New Validation Templates (seeded) for quote processing:

See the Oracle Order Management Implementation Guide for Versioning setup information.

To auto generate the version:

  1. Set up the processing constraint for a Payment Term change to auto generate next version.

  2. Create and save an original transaction (Sales Order, Quote, or Sales Agreement) (version 0).

  3. Make changes to the payment term, and save the transaction. (You can also invoke the auto generate new version by traversing to the Lines block, or clicking on Actions button and invoking the Version history window).

  4. The version increments to 1. Version 1 is the active version. The original transaction version 0, is backed up to history.

To auto generate with manual version override:

  1. Set up the processing constraint for a PAYMENT TERM change to auto generate the next version.

  2. Create and save an original transaction (Sales Order, Quote, or Sales Agreement version 0).

  3. Make changes to the payment term.

  4. Since this attribute change has been governed by the processing constraints framework for automatic versioning, the version and reason window (with version number as 1) pops up.

  5. Enter ‘4’ for the version in the version number field by overriding 1. Save the transaction.

  6. Version 4 is the active version. The original transaction, version 0, is backed up to history. Version 1, 2, or 3 cannot be used for this transaction.

To auto generate with multiple constraints:

  1. Set up the processing constraint for PAYMENT TERM, SHIP TO, and ITEM changes to auto generate the next version.

  2. Create and save an original transaction (Sales Order, Quote, or Sales Agreement) (version 0).

  3. Make changes to the payment term, ship to, and item.

  4. Make updates to item quantity and UOM, and save the transaction. The save transaction will open the version and reason window (if reason applicable) and will create a single version.

  5. Version and reason window also gets invoked by traversing to the other block (header) or by clicking on actions button and invoking the action history. In this case too, save the transaction.

  6. Version 1 is the active version. The original transaction, version 0, is backed up to history. All five changes will be reflected if you compare version 0 to version 1. It does not version based on the number of changes, simply all changes made between the previous and current saves of the transaction.

Multiple version for multiple saves:

  1. Set up a processing constraint for PAYMENT TERM and SHIP TO changes, to auto generate the next version.

  2. Create and save an original transaction (Sales Order, Quote, or Sales Agreement) (version 0).

  3. Makes changes to the payment term and save.

  4. Automatically generate revision 1 and back up revision 0.

  5. Make changes to Ship To and save.

  6. Automatically generate revision 2 and back up revision 1.

  7. Makes updates to the item quantity and save.

  8. The transaction version will not auto generate for item quantity. Revision 2 is still the active version, as item quantity did not trigger auto generation of a new version. To reflect this change, input a value (i.e. ‘3') before saving the transaction.

Deciding Priorities for Audit Trail Vs. Versioning in the Processing Constraints Framework

The order in which constraints will be evaluated would be the following and only one constraint may take effect for a change

User Action:

  1. Not Allowed

  2. Generate Version, require reason and Raise integration event (VERSION ACTIVATION)

  3. Generate Version and require reason (VERSION ACTIVATION)

  4. Generate Version (VERSION ACTIVATION)

  5. Require reason, history and raise integration event (Audit Trail)

  6. Require reason and history (Audit Trail)

  7. Require history (only for fulfillment phase) (Audit Trail)

  8. Raise Integration event (Electronic Messaging)

For example: If multiple constraints are setup for Price List and operation = UPDATE so conditions for both versioning and audit constraint apply, only versioning will be captured.

Seeded Reason Codes: (Extensible).

Note: Please refer to Oracle Order Management Open Interfaces, APIs, and Electronic Messaging Guide for more information relating to Integration events.

Versioning in Sales Agreement (SA) post-acceptance:

  1. Set up a constraint to define on who has the ability to make changes/updates and version the Sales Agreement in Approved and/or Active status.

    Note: It is possible to set up constraints for changes in any status.

  2. The system automatically creates a version.

  3. Put the document on hold (Manual)*.

  4. Make changes to the Sales Agreement and save.

  5. Obtain the updated approval (Manual) and print the document.

  6. Update the signature date (Manual and overrides the previous date) and remove the hold (Manual).

  7. Now you can place Releases against the new version of the Sales Agreement.

    *If you do not put the Active Sales Agreement on Hold, it can result in data corruption with corresponding releases.

Versioning Setup Expected Behavior

Following tables describes the expected behavior for different setup combinations.

Expected Behavior
Operation Attribute User Action System Changes User Changes Expected Behavior
Create Null Generate Version No Effect No Effect Will not generate the version if the Create is happening as a part of the of the Order/Quote/Sales Agreement header creation. Will not generate the version for the order header and Sales Agreement header.
Update Null Generate Version No Effect No Effect Will increment the version for any UPDATE operation after the record has been created in database.
Update Value Generate Version Null (will be same as Never After Insert) Null (will be same as Never After Insert) Will not increment the version if: The attribute is changed by Defaulting on a record that is not yet created. The attribute is changed by user on a to be created record. Will increment the version if: The attribute is changed by user on an existing record. The attribute is changed by defaulting on an existing record.
Update Value Generate Version Always Null Will not increment the version if: The attribute is changed by Defaulting on an existing record or a record which is not yet created. The attribute is changed by the user on a record which is not yet created. Will increment the version if: The user is changing the attribute on an existing record.
Update Value Generate Version Always Never Will not increment the version if: The attribute is changed by Defaulting on an existing record or a record which is not yet created. Will increment the version if: The attribute is changed by the user on an existing record.

Versioning Reasons and Comments

Capturing Reasons and Comments

The following Actions (Reason Types) are supported:

  1. Version Change Reason & Comment

  2. Audit Reason & Comment

Messages

Message Text: Version Number can not be less than &current_value.

Order Audit Trail

Overview

Oracle Order Management now enables you to record, or track updates to specified order attributes as they occur. By utilizing the existing framework and functionality of Processing Constraints, Lookups, a system parameter, and the Audit Trail Consolidator concurrent program, Order Management enables you to view and generate reports to display comprehensive audit trail updates recorded for orders.

Current Processing Constraints functionality enables you to specify exactly what business functions, by entity you wish to control when performing order modifications. You can now choose to define new processing constraints that specify when, and for what attributes of an order, audit trail updates are recorded. You must first enable the Order Management system parameter Audit Trail. See: Enabling Order Management System Parameters.

You can capture updates to a given constrained order attribute based on the following entities:

For example, you can choose to record audit trail details for:

A particular field (attribute) within the sales order header or line windows that can be updated.

For example, you may want to track updates made to all orders of type of Standard, but not for orders of type of Mixed.

A workflow activity for which the order or both the order and line have reached. For example, you may want to track updates to orders only after the order has been shipped but not before.

The responsibility that is initiating the update. For example, you may want to track updates made to orders by a particular sales representative or group of sales representatives.

With this release of the Order Audit Trail functionality, Revision Control of orders is not supported. You are also limited to capturing only Processing Constraint definitions that include the operation of Update, and for attributes or entities stored in constrained columns within the database.

If an attribute of an order is updated utilizing Order Management Mass Change functionality, you must provide a Reason Code if required. View and correct any errors that occur during processing within the Processing Messages window or within the Corrections window if processing mass changes utilizing Order Import.

Note: If you are processing order updates through the Process Order API and a reason code is required when updating constrained order attributes and no reason code value is provided, you can view the associated error message in the process order api log files, the Import Orders Correction window or the Process Message window.

For schedule groups such as a configuration or Ship Set, if a change is made to an attribute which cascades changes to another attribute, then for the second attribute reason code, Order Management will populate the reason field with the seeded value SYSTEM.

Quickcodes and Audit History

Use the Order Management quickcode types CANCEL_CODE and CHANGE_CODE to define new reasons for recording audit history.

Note: The quickcode CHANGE_CODE is used for defining new audit history reasons for the entity PRICE_ADJUSTEMNTS only.

Processing Constraints and Audit Trail

Utilizing the existing Order Management Processing Constraints framework, you can choose to define additional constraints with a User Action of Requires Reason and History or define new constraints with a User Action of Requires History to record audit trail order updates as the updates occur.

Audit Trail updates now are recorded for new or current Processing Constraint definitions that contain the following partial constraint definition:

Based upon your Processing Constraint definition, if a Reason Code is required for order update and has not been provided prior to saving an order, the Reason Capture window appears as a popup to enable entry of the Reason code and any optional comments.

Note: The Reason Capture window is also accessible from the Tools Menu within the Sales Order window to enable data entry of the Reason Code (reason field is also available within the Sales Order Lines window, Main Tab). You can use this method to record optional reason codes for changes that Require History and for reason code changes where recording a reason code is mandatory (Requires Reason and History).

Note: If you are making changes to several fields at the same time and one of them has a Requires Reason constraint set up, then that reason will be displayed in the Audit History window for the fields that were updated along with the one that had a Required Reason constraint. The other fields may not have the Requires Reason set up, since they were updated along with the field which had the reason constraint set up, they also display the Reason in the Audit History window.

If you have set System Changes to Always in the Processing Constraints form, then the values set up in the defaulting rules will be used and will also be shown in the Audit History window, provided a Requires Reason and History is set for that attribute. Normally, when an attribute is updated, the original and new values are reflected in the Audit History window. However, if the attribute is updated again to its original value, Audit History does not store the original value and takes its value from the defaulting rules provided System Changes is set to Always.

Once you have made the selection and selected OK, save your work.

Find Audit Trail Window functional processing

Note: You must successfully submit the Audit History Consolidator program at least once in order to view Audit Trail details within the Audit History window.

Processing Constraints and Audit Trail

To view Audit Trail Information

  1. From an Order Management Responsibility, navigate to the Audit History window.

    Find Audit History Window

    the picture is described in the document text

    Determine your search criteria to display order audit trail information. If you leave any of the Find criteria blank, Order Management includes all orders that meet your other Find criteria.

    Select the Order Number to display audit trail information for a specific order or range of order numbers These fields are optional.

    The Operating Unit field allows you to search for Audit History in a particular Operating Unit or across all Operating Units accessible to you. When there is no default or user specified value in the Operating Unit field, the Order Type LOV will show data from all Operating Units that you have access to. If you select an Order Type, the Operating Unit field will be automatically defaulted based on the selected Order Type.

  2. Enter a History Start and End to display order audit trail information. Order Management will display only orders changes that occurred during the date range entered. These fields are optional.

  3. Select the Entity for which you wish to display order audit trail information. Select from:

  4. Select the Attribute you wish to display order audit trail information. The LOV for this field will display only valid attributes related to the value selected within the Entity field.

    Note: You must select a value in the Entity field prior to selecting a value in the Attribute field.

  5. Select a User or a Responsibility to limit display to changes made by a specific user or by a responsibility. The LOVs will show only users and responsibilities that exist in the Audit History Consolidated table.

  6. Select an Order Type to limit display to changes to orders of a specific order type.

  7. Click Find to return audit trail information for you selection criteria or click Clear to clear values selected.

Audit History window

Information initially displayed within the Audit History window is based upon criteria entered within the Audit History Find window. The data displayed is based upon the last successful completion of the Audit History Consolidator concurrent program and is sorted based upon the Last Update Date of the last audit trail order update recorded for constrained order attributes in relation to the current system date.

Audit History Window

the picture is described in the document text

The default tab displayed within the Audit History window is the Orders tab, unless a value is entered in the Entity field within the Find window. If a value is entered in the Entity field, then the default tab displayed when the Find button is selected will correspond to the value entered.

Note: Changing the inline Reason Code in View Adjustments window will not impact audit history

Audit History Window

The Audit History window displays the following 3 regions for each order selected:

Tabs

The Audit History window displays the following 6 tabs which display the following order or line attributes:

Orders, Order Sales Credits, and Order Price Adjustments Tabs

Lines, Line Sales Credits, and Line Price Adjustments Tabs