Requester change Order in Procurement

An Oracle White paper

Jan 2005
 Table of Contents
Executive Summary ............................................................................................................ 3
Introduction......................................................................................................................... 3
Function Security ................................................................................................................ 4
View my Reqs Change Order ......................................................................................... 4
View Reqs Change Order History .................................................................................. 4
Functional flow ................................................................................................................... 4
Change requisition and Purchase Order (PO) status....................................................... 4
Route the change request to requesters approval hierarchy............................................ 4
Approvers response......................................................................................................... 4
Action history Updation.................................................................................................. 5
Display status as Pending Response from buyer ............................................................ 5
Buyers response .............................................................................................................. 5
Response processing ....................................................................................................... 5
Simulation Cycle................................................................................................................. 7
Requester Change Order Workflows ................................................................................ 15
Requester change order request tolerance Workflow ....................................................... 23
Tables Involved and Important Queries/Scripts ............................................................... 25
Important Points to be consider using this functionality .................................................. 26
Recommended Patch List ................................................................................................. 28
Summary........................................................................................................................... 29
Acknowledgement ............................................................................................................ 29
Executive Summary
Requester-initiated amendments to purchase orders can often be time-consuming and
labor-intensive. Oracle iprocurement has provided self-service process for making
amendments. Requesters can request line cancellations, changes to the order quantity or
amount, need by date, and under some conditions, price. Once submitted and approved,
the Purchasing organization retains appropriate controls and can accept or reject proposed
changes. This additionally provides user the capability to select and cancel individual
requisition lines, before the corresponding Purchase orders are received or the
Requisition is placed in Sales Order.

This white paper focuses on the features that Requester Change Order provides to buyers
and requester. It lays down the road map for implementing the Change order
functionality, which allows requesters to communicate the changes and the buyer to
respond effectively to these requests. It also discusses requester change order request
tolerance workflow which provides the administrator such capability to customize the re-
routing rules i.e. whichever changes to requisition—for example, to need-by date,
quantity ordered, unit price and requisition amount —require manual re-approval and
which need not require manual re-approval and would get automatically re-approved.

Introduction
The purchase order management process starts with the requester sending a requisition to
the buyer of the company. Typically, the requisition goes through a chain of approvals
within the buying organization before being placed on one or more purchase orders. The
buyer sends the purchase order to the supplier using one of the many communication
methods.

After a purchase order (PO) has been sent to suppliers, there may be instances when the
requester may want to make changes to the order corresponding to his requisition.
Currently, in these scenarios requesters have to call the buyer who would then make the
required changes manually to the order and then send the revised order to the supplier.

This purchasing experience can be improved for both requester and buyer by
implementing a requester Change Order module. The module allows requester to
communicate the changes and the buyer to respond to these requests.
Function Security
Two function securities can be used to control the user's access to this feature:

View my Reqs Change Order

This is the function security to request changes and cancellations to requisition line(s) on
purchase order(s). This is used to control whether the iProcurement user can request
changes to purchase orders.

View Reqs Change Order History

This is the function security for View Change History button. This is used to control
whether the user can access the Change History page in the iProcurement application to
track the progress of the change requests.

Functional flow
The following sequence of events results after the requester has submitted a change
request -

Change requisition and Purchase Order (PO) status

Requisition Status is changed to show that it is pending for approval but the status of PO
changes only when change request is approved by the requisition hierarchy.

Route the change request to requesters approval hierarchy

After submission, the request is routed through the requester’s approval hierarchy. The
approvers should be determined based on the entire document total and not just the
change. Cancel request is not sent to the hierarchy.

Approvers response

Approvers from the requester’s approval hierarchy are allowed to approve the change
request via the notification. This notification indicates the changes that are happening to
the original requisition. The approvers will then be able accept or reject the changed
requisition.

Note: If approver rejects the change the requester will have to resubmit a new change
request. Requester is not allowed to modify the existing change request and resubmit.
Action history Updation

. The action history displays the approval history of the original and modified requisition.

Change request to buyer for approval (If the req is already placed on the PO)

Change requests approved by the requester’s approval hierarchy are submitted to the
buyer for approval.
It first verifies that the revision number of the purchase order when the requester initiates
the change is the same as the current PO revision. If the revision numbers are the same,
the buyer will receive a notification of the change and will have the option of responding
via the notification. If the revision numbers are different, or if the purchase order has
supplier changes pending to be responded to or the purchase order is an IN PROCESS
status, the buyer will receive an FYI notification of the requester change request. The
buyer will not be allowed to respond to the change request via the notification.

Display status as Pending Response from buyer

The change request status in the change request object indicates that the change is now
pending response from the buyer. The PO and the requisition status displayed indicates
that the change request is now pending with the buyer.
The PO status indicates that there are requester changes pending. The internal status of
the PO will be IN PROCESS. The change type flag value is set to REQUESTER. The
status displayed on the PO is REQUESTER CHANGE PENDING. When a purchase
order is in this state, it implies the following:

· No PO transactions such as receiving etc should be allowed on purchase orders

that are in this status.
· No other change requests can be made to this PO by anyone (buyers, requesters,
or suppliers), until the buyer responds to the pending change requests.

Buyers response

Buyers can respond via notification and can either accept or reject all of the change
requests.
The buyer is not allowed to respond via notification if the PO revision numbers are
different or if there are supplier changes pending to be responded to.
The buyer is not allowed to respond through UI screen if the PO is in ‘IN PROCESS’
status.

Response processing

As per the buyer’s response, the following sequence of event takes place:

If request is accepted
 The status of the individual request will be updated to “ACCEPTED”.

The purchase order will be revised to reflect the accepted changes

If encumbrance is ON the original PO needs to be un-encumbered first and then

encumbered again for the revised PO total when quantity, price and cancellation
requests are accepted. If the encumbrance checks fail due to lack of funds then a
rejected response will be communicated to the requester and the buyer.

The corresponding requisition will be modified to reflect the accepted changes

A new revision of the PO will be created, requiring re-approval – the document

will be routed to the buyer’s approval hierarchy (based on the approval hierarchy
rules setup).

Once the buyer’s approval hierarchy approves the PO, the new revision will be
archived (assuming that “Archive On Approval” is turned on) and all items on the
PO will be ready for shipment.

If the accepted request was for cancellation then the corresponding requisition
will be canceled as well.

For distribution level quantity changes the corresponding PO distribution should

be updated.

An acceptance notification will be sent out to the requester. The acceptance

notification will itemize decisions for each component of the change request.

The revised purchase order will be communicated to the supplier.

Note: The notification will be sent only if all the PO change requests have been
responded to.

If the buyer only responded to part of the change request, the only event that will
take place is that the status on the change request line item will be changed to
“ACCEPTED”. If the change request was on multiple Purchase orders then the
changes will be updated on a per PO basis. When all the change requests on a PO
have been responded to, the PO will be updated even if the change request on
another purchase order is pending response.
If request is rejected

If the change request is rejected, there will be no changes to the purchase order. The
status on the change request will be updated to “REJECTED”. A notification will be sent
out to the requester if all other PO change requests are responded to. In the case of partial
response, the status on the change request line item will be changed to “REJECTED”.
It will route the modified purchase order to buyer’s approval hierarchy.
When the purchase order is modified to reflect the change requests accepted by the buyer,
the revised purchase order is sent to the buyer’s approval hierarchy if required.
The encumbrance reservations will happen at the time of PO approval.

Modify PO action history

When the requester’s change request is submitted to the buyer for approval the PO status
is changed to IN PROCESS. It will also add a record to the PO’s action history as follows
Change Request Submitted Ms Catherine Baker
When the buyer approves the change –
Change Request Accepted/Rejected/Responded Ms Pat Stock

Note: Buyers are allowed to cancel the PO, line or shipment even if the changes are
pending. In this scenario the pending requester change is treated as rejected and the
requester is notified accordingly in the final notification.

Simulation Cycle
1. Created one requisition in iprocurement by requester “Stock Pat” with three line
items. Requisition is approved also.
Requisition number is 3544.

Fig: 1
2. Buyer “Catherine Baker” converts Requisition 3544 into PO 4320.

Fig: 2

3.Change request is created by “Stock Pat” and added one manager CBROWN approval
in the approval process.

First Line quantity increased to 3 from 1

Second Line quantity increased to 5 from 1
Third line cancelled
The screenshot shows (Fig: 3) the previous quantity as well as the changed quantity
and the reason for these changes

Following validations take place before changing the requisition and PO:

Is there an internal order associated with line? If YES, then no changes can be
made on that line.
Is there any negotiation? If YES, then no changes can be made on that line.
Check if PO is in APPROVED status. If NO, then no changes can be made on that
line.
Check for CANCEL_FLAG and closed code at PO Shipment Level: If Cancel
Flag is set to ‘Y’ or closed code is yes, no change is allowed.
 Check if distributions for a PO shipment correspond to same requisition line. If
NO only possible option is: quantity update.
Price change is allowed ONLY on non-catalog items.
If there is any blanket agreement for non-catalog item, price override flag must be
set to 'Yes'. Else price cannot be changed.
Price cannot be changed even if at least one accounting entry is recorded. I.e.
Accrue on receipt is Y and partially/fully received or partially/fully invoiced
If PO line has been partially received or invoiced, then Price cannot be changed.
The Change Request uses the PO change API to make the changes. So all the
rules applied to PO Change API will also applicable for this change request too.

Fig: 3

Table PO_CHANGE_REQUESTS stores the data for this requisition and shows the
request_status as MGR_APP for the line 3 (Fig: 4). It shows MGR_APP for line 3
because Cancel request does not need the approval from the requisition approval
hierarchy. So it will be directly sent to buyer for buyer’s approval. And buyer’s decision
is the final decision (which means the PO cancel request does not need the approval from
buyer’s approval hierarchy).

Line 1 and 2 is showing as MGR_PRE_APP because it is pre approved by a manager in

requisition approval hierarchy who has enough approval authority.

Line 3 is showing the status as MGR_APP because Cancel request will not go through
the approval hierarchy
Following are the different status in table PO_CHANGE_REQUESTS:

Status Meaning
NEW Initial status. When requisition change request is created, it is set to
‘NEW’ status
MGR_PRE_APP It is pre approved by a manager in requisition approval hierarchy who
has enough approval authority.
MGR_APP It is approved in requisition approval hierarchy
ACCEPTED It is finally accepted by buyer
REJECTED It is rejected by either the approval manager in approval hierarchy or
the buyer

Fig: 4

CHANGE_PENDING_FLAG, in PO_REQUISITION_HEADERS_ALL indicates

whether there are pending changes on this requisition (Fig: 5). When requester submits a
change request, it will be set to ‘Y’; and when the change is responded, it will be reset to
‘N’.

Fig: 5

There is no row inserted in PO_CHANGE_REQUEST for the Purchase Order because

presently the change request for Requisition is not approved by requisition approval
hierarchy (Fig: 6)
Fig: 6

Cancel request does not need the approval from the requisition approval hierarchy. So it
will be directly sent to buyer for buyer’s approval. And buyer’s decision is the final
decision (which means the PO cancel request does not need the approval from buyer’s
approval hierarchy). As the manager CBROWN has approved the other two lines, they
will go to the buyer for PO approval process.

If the whole requisition change request is a pure cancel request, it will directly be
converted into multiple PO cancel requests and will be sent to buyer for approval.
If the change request is a mixture of cancel and change, then the change part will be
routed to requisition approval hierarchy for approval, and hold the cancel part till the
change part is approved or rejected by the approval hierarchy. If the change is approved,
the mixture of the cancel and change request will be converted into PO change (cancel)
requests. If the change is rejected, then only cancel request will get converted into PO
cancel requests.

If the buyer and supplier have decided to cancel the PO and respective requisition, and
there happens to be a change request on that requisition line pending in the requisition
approval hierarchy, then this Change request will be rejected automatically (or accept the
change if it is a cancel request)
Fig: 7

After approval the Buyer will get the following notification (Fig: 8)

Fig: 8

Now the data in table PO_CHANGE_REQUESTS shows for requisition 3544. (Fig: 9)

Line1 and line 2 are showing as MGR_APPR because change request is approved in
requisition approval hierarchy
Fig: 9

CHANGE_PENDING_FLAG, in PO_REQUISITION_HEADERS_ALL indicates Y still

because request is not completed and waiting for Buyer to approve. (Fig: 10)

Fig: 10

Data in table PO_CHANGE_REQUESTS for PO shows that lines are showing as

PENDING (Fig: 11)

Fig: 11

Ran the wfstatus for ITEMTYPE “POREQCHA” and ITEMKEY “32955-295-264”

The output shows the complete steps taken in the workflow. Few important activities to
be noticed are

Does the change require approval? COMPLETE Y

Can Owner Approve? COMPLETE Y
Does approver Have Authority? COMPLETE Y
Is there any req change request in 'MGR_APP' status? COMPLETE Y
 Convert Req Change request to PO change request COMPLETE
ACTIVITY_PERFORMED
Is there any req change request in 'MGR_APP' status? COMPLETE Y
Launch "Notify buyer of PO Change" workflow process for each PO COMPLETE
ACTIVITY_PERFORMED

Ran the wfstatus for ITEMTYPE “PORPOCHA” and ITEMKEY “INFORM_301_265”

The output shows the complete steps taken in the workflow. Few important activities to
be noticed are:

Is the Purchasing Order Approved? COMPLETE Y

Record 'Change Submit' In Action History COMPLETE
ACTIVITY_PERFORMED
Set the PO to IN PROCESS status COMPLETE
Has PO changed after req change submitted? COMPLETE N
Notify Buyer of New PO change NOTIFIED CBAKER

a. Buyer CBAKER has approved the change request and after that the query results are:
Requester Change Order Workflows

The workflow processing of the requester change order is divided in two steps:

1. First it approves the requisition change request internally in requisition approval

hierarchy. And once approved, Multiple PO change requests will get created. This
is handled in workflow “Requester change order approval” item type
‘POREQCHA'.
Two processes, which handle this part of process, are

· Main Requisition Change Approval Process

The requisition change request will be routed to approval list for approval. After the
change request is finally approved or rejected by the approval hierarchy, it will start the
next workflow process “Process the requisition approval hierarchy approval result” to
process the approval result.

· Process the requisition approval hierarchy approval result

This workflow first checks if there is any change request lines in status ‘MGR_APP’. If
not, then it means that the requisition change request is fully rejected and requester
should be informed with the results Otherwise, the change request lines with status
‘MGR_APP’ will be sent to buyer or even buyer’s approval hierarchy for approval.

2. Each PO change request will be approved.

The PO change request need to be approved by the buyer first. If the buyer rejects the
change request, then it won’t get submitted to PO approval hierarchy. If buyer approves
the change request, then PO will get updated and a new revision PO will be submitted to
PO approval hierarchy for approval. This is handled in workflow ’PO change approval
for requester’ item type ‘PORPOCHA'. The processes which handles this are

· Inform buyer of PO change

PO change request will be routed to buyer for approval. After buyer makes the decision,
‘Process buyer’s response’ will be started to inform requester of buyer’s decision, update
the requisition and PO if needed, and kick off the PO approval workflow if needed.

· Process buyer’s response

This process is started when buyer responds the entire PO change request. First it will
update the corresponding requisition change request status to ‘REJECTED’ for those
buyer-rejected PO change request. Then it will call CANCEL API for accepted cancel
request. After that, it will check if there is buyer-accepted change request, if yes, the
process will update the PO and the requisition. PO approval workflow will be kicked off
to approve the PO. If there is no buyer-accepted change request, the process will check if
the entire requisition change request is finally processed. If yes, it will send the requester
notification.

Following are the activities handled in this workflow:

When requisition change request is submitted, the first thing is to get it approved in
requisition approval hierarchy. The top process ‘Main Requisition Change Approval
Process’ does it.

Main Approval Process is the top process to approve the requisition change.

1.The first sub process is “ Approve Requisition Change Process”

“The Approve Requisition Change Process” first activities are:

· Clears previous notification related to this requisition

· Set the start-up value of workflow attribute
· Set the requisition change flag, save the item_type and item_key to the table
· Find the approval list
· Decide whether the approval should run as background process
· Set change request related attributes (like new total, net tax)

2. After this, it checks "Does the change request need re-approval?" This node decides
whether the change request is within the tolerance so that it can be automatically
approved.

Once requester submits the change request, a workflow will be run to decide whether the
change request can be automatically approved. If it can, then the change request will be
saved into the database with the ‘APPROVAL_REQUIRED_FLAG’ set to ‘N’.
This procedure also set the cancel requests status to ‘MGR_APP’ since those requests do
not require approval.

3. Now it checks Can Owner Approve?

This node checks if Owner Can Approve is enabled for the specific document type in the
Document Types window. It checks the field ‘ Owner can approve ‘ from document type
based on document type code and document subtype to figure out whether the owner can
approve the document or not

4.Verify Approval Authority

It checks whether the person has enough authority to approve the document.

5. Set Change Request Status to MGR_PRE_APP

If the requester has the approval authority to approve the document, this function set the
requisition change status from ‘NEW’ to ‘MGR_PRE_APP’.
6. Is Approval List Empty
This node checks if there are no more approvers in the approval list. If there are, the
workflow routes the change request for their approval

7. Approval List Routing (Sub process)

This sub process routes the change request to the approval list for approval. It ends with
a result of change approved or rejected.

8. Set Change Request Status to MGR_APP

This node set the change request status to ‘MGR_APP’, which means that it is approved
by requisition approval hierarchy.

9.Update Action History to Approve or Reject accordingly

This node updates the action history according to the approval result.

10. Create PO Change Requests

This is the sub process to process the approval hierarchy’s approval result. When this sub
process is called here, all the requisition change request lines are in status ‘MGR_APP’,
‘ACCEPTED’ or ‘REJECTED’. The process will make decision based on the status of
the change request.
· If there is change request lines in status ‘MGR_APP’.
These will get converted into multiple PO change requests. For each PO change request,
an auto-approval check has to be if the PO is in ‘Approved’ or ‘REJECTED’ status.
Then, if there are still pending PO change request, then ‘Inform buyer of PO change’
workflow will be kicked off to process the PO change request. If there is no pending PO
change request after the auto-approval check, then a requester notification is sent about
the final approval result of the requisition change request.

· No change request lines in status ‘MGR_APP’

requester will get notification for the final approval result of the requisition change
request.

11 Set Change Request Status to Rejected

If the approval hierarchy rejects the change request, this function set the requisition
change status to ‘Rejected’.
This process is called in Main requisition change approval process when requisition
approval hierarchy has made the final decision to the change request. It will then process
the decision. The main task of this process is to convert the approved change request into
PO change requests and send them for approval.

1.Is there any change request in status ‘MGR_APP’?

This node will check if there are change lines in statue ‘MGR_APP’.

2. Convert Req Change request to PO change request

Since the requisition is already placed into POs, so the change to requisition should also
be converted into PO changes. This node converts the requisition change requests into
multiple PO change requests.
For each change to a requisition line, it will create a corresponding change request to PO.

Since the PO status can be changed since the requisition change request is submitted,
some POs may already be rejected, some may be changed, So after the PO change
requests are created, Status needs to be set of those change requests. For the POs that are
rejected, set the PO change request status to ‘REJECTED’, for the POs that are changed,
it will check if the changes are already in the PO and if that is the case, we set the PO
change request status to ‘ACCEPTED’, Otherwise, set the status to ‘NEW’.

3.Launch "Notify buyer of PO Change" workflow process for each PO

Inform Buyer of PO Change
After PO change requests are created, buyers are informed of all the affected POs. This
workflow process sends notification to buyer, and if buyer responds through notification,
it will also record the response, and kick off another workflow process to process the
response.

4. Get New Total/Tax

This node calculates the new change total and tax and set new workflow attribute used in
the notification.

5.Notify requester of the response to the change request

This is the notification to the requester for the response result of the requisition change
request. Reset the requisition change flag
Since the requisition change request has been fully responded, it will reset the flag in the
requisition table. The flag is used to indicate that the requisition change is under change.

6. Record ‘Change Submit’ in action history

Set the PO to IN PROCESS status
This node sets the PO to ‘IN PROCESS’ status to indicate that there is pending requester
change, it also sets the change_pending_flag in the PO to value ‘REQUESTER’.

7.Has PO changed after req change submitted?

This node checks whether the PO has been changed since the requisition change request
was submitted.
8. Inform Buyer of New PO Change FYI
This is a fyi notification to buyer about the PO change request.
Requisition change request may take a long time to be approved by requisition approval
hierarchy. If when the requisition change request is approved by requisition approval
hierarchy and converted into PO change request, the PO is already modified, then fyi
notification is send to buyer.

9.Inform Buyer of New PO Change

This is a notification to buyer about the PO change request.
Buyer can respond to this notification by accept all of the PO change or reject all of the
PO change. This notification is sent to buyer only if the PO has not been changed since
the requisition change request was submitted.

10 Record Buyer’s acceptance

If buyer accepts the change request through the notification, this node will update the
status of the PO change request from “ NEW” to “BUYER_APP”.

11 Record Buyer’s rejection

If buyer rejects the change request through the notification, this node will update the
status of the PO change request from “ NEW” to “REJECTED”.

12 Kick off Process Buyer’s Response workflow process

After buyer responds to the change request, Requester needs to be informed of buyer’s
response. If there is any PO change request approved by buyer, then requisition and the
PO needs to be updated, and PO approval workflow should be kicked off to get the PO
approved by PO approval hierarchy.

13.Record buyer’s response in Action History

This node records buyer’s response to the action history. If all the change requests are
accepted, record ‘ACCEPTED’; if all the change requests are rejected, record
‘REJECTED’, otherwise record ‘RESPONDED’.

14.Process rejected request

This node first processes the rejected request by updating the status of corresponding
requisition change request lines to ‘REJECTED’

15Process accepted cancel request

This node will check if there are accepted PO cancel request, if yes, the node will process
the accepted PO cancel request. It will call the PO cancel API to cancel the PO and the
requisition. It will also update the status of the request records.

16Are there any PO change request accepted by buyer

This node checks whether there are change request lines that are accepted by buyer (in
status BUYER_APP).

17Process accepted change request

This node will process the accepted PO change request. It will call the MoveToPO API
from the supplier change order project to merge the accepted change request into PO; it
will then merge the change request into the requisition. Finally, it will update the status of
the request records.

18Kick off PO Approval workflow

For newly updated PO, PO approval workflow is kicked off to get it approved. Change
flag is resetted, Notify Requester of the approval result

This is a sub process to reset the requisition change flag and notify the requester of the
approval result. It checks if all the requisition change request lines have been responded,
if yes, the process will reset the change flag in the requisition headers table to indicate
that there is no more changes on the requisitions and will inform the requester of the
approval result.

19Are all the requisition change request lines responded?

This node checks if all the requisition change request lines has been responded (in status
‘ACCEPTED’ or ‘REJECTED’).

20 Reset the requisition change flag (called in PO)

This node resets the requisition change flag to ‘N’ in the requisition headers table.
Requester change order request tolerance Workflow
Whenever the requester initiates a change order request for a requisition, the ‘requester
change order request’ document should be routed through the requester’s approval
hierarchy using the requester change order request workflow. Since the requisition
document has already been through the approval hierarchy at least once before, It could
be the requirement that change order request would not be re-routed through the approval
hierarchy, as it will prove to be redundant (e.g. the need-by date is changed for the
requisition, which typically does not need re-approval). However, it can also be the
requirement that the requester change order request to be re-routed in certain cases (e.g.
when quantity is increased, and it in turn increases the requisition amount).

The requester change order request tolerance workflow provides the administrator such
capability to customize the re-routing rules i.e. which changes to requisition—for
example, need-by date, quantity ordered, unit price and requisition amount —requires
manual re-approval and which would not need require manual re-approval and would get
automatically re-approved.

Change Request Processing

· The changed requisition will be checked to see if the owner can approve the
changes himself/herself.
· In the case of any failure the owner will have to route the changes through the
approval hierarchy

The workflow item type will be called ‘PORCOTOL’

Requisition Change Request Approval

When requisition change request is submitted, the first activity is to check if the owner
can approve the changes himself/herself. The top process ‘Requestor Change Order
Request Approval Process’ performs the necessary checks.

Requestor Change Order Request Approval Process

Requestor Change Order Request Approval Process is the top process to approve the
requisition change.
The requisition change request is scanned for changes made at the distribution level, line
level and requisition level to decide whether the user can approve the change request
himself/herself without routing the changes through the approval hierarchy.

The following attributes in a requisition can be impacted as a result of a change request

initiated by the requester:
1. Quantity Ordered (Numeric at Line and Distribution Level)
2. Unit Price (Numeric at Line Level)
3. Requisition Amount (Numeric at Header Level)
4. Need by Date (Non-numeric at Line Level)
The workflow process checks the changes made to the attributes in the following order
1. Need by Date
2. Unit Price
3. Quantity Ordered
4. Requisition Total

Requester Change Order Request Workflow Attributes

Follow the below steps in order to configure the Requester change order request tolerance
Workflow

1. Open the Workflow file in Workflow Builder.

2. Expand Attributes.
3. Double Click on the attribute ‘Need By Date?’
4. Specify the Value as ‘Y’

The rules for each attribute to determine whether or not the requester change order
request document should be re-routed are summarized in the following Table.

Attribute Description Upper tolerance Lower tolerance

limit (percent) Limit (percent)
Quantity Numeric so tolerance 0 100
ordered limit
Unit Price Numeric so tolerance 0 100
limit
Requisition Numeric so tolerance 0 100
Amount limit
Need By Date Non Numeric so only ‘Y’ or ‘N’ ‘Y’ or ‘N’
YES or NO

Note: Even though change requests to the ‘Quantity Ordered’ are submitted at the
‘Distribution’ level, the check for the tolerance limits should be performed at the ‘Line’
level only. This should be done after summing up the changes to the ‘Quantity Ordered’
for all the distributions for that line.
Tables Involved and Important Queries/Scripts
Following are the tables involved

1. PO_CHANGE_REQUEST
PO_CHANGE_REQUEST table stores the change requests submitted on Purchase
Orders, Releases or Requisitions by Suppliers or Requesters

2. PO_REQUISITION_HEADERS_ALL
PO_REQUISITION_HEADERS_ALL stores information about requisition
headers. In this table we have one Flag called CHANGE_PENDING_FLAG, which
Indicates whether requisition is in Change Order process, or not

For Debugging purpose we need to collect the wfstatus for the ITEMTYPE
POREQCHA - Requisition Change Request Workflow (poreqcha.wft)
PORPOCHA - Purchase Order Change Request Workflow (porpocha.wft)

ITEM KEY for POREQCHA can be retrieved with the following Query

SQL> Select WF_ITEM_TYPE, WF_ITEM_KEY from PO_CHANGE_REQUESTS

Where DOCUMENT_NUM = ‘&REQ_NUM’

With wf_item_type and wf_item_key retrieved from the above query, Wfstatus.sql output
can be taken

ITEM_KEY for PORPOCHA can be retrieved with the following method

SQL> Select change_request_group_id CRGID

From PO_CHANGE_REQUESTS
Where Initiator=’REQUESTER’
Document_num=’&PO_NUM’
Document_type=’PO’

This change_request_group_id (CRGID) needs to be added in the below Query to get the
ITEMKEY for PORPOCHA

a) SQL>select item_key from wf_items where item_type='PORPOCHA' and item_key

like
'%INFORM_ CRGID %';

b) SQL> select item_key from wf_items where item_type='PORPOCHA' and item_key

like
'%RESPONSE_ CRGID %';
With wf_item_type and wf_item_key retrieved from the above query, Wfstatus.sql output
can be taken

Following script can also be used to get the item type and item key

SELECT DISTINCT SUBSTR (poc.wf_item_type, 1, 15) ITEM_TYPE,

SUBSTR (poc.wf_item_key, 1, 15) ITEM_KEY,
prh.requisition_header_id HEADER_ID
FROM po_change_requests poc,
po_requisition_headers_all prh,
po_requisition_lines_all prl
WHERE prh.requisition_header_id = poc.document_header_id
AND prl.requisition_header_id = prh.requisition_header_id
AND prl.requisition_line_id = poc.document_line_id
AND prh.segment1 = '&ReqNum'
AND poc.document_type = 'REQ'
UNION ALL
SELECT DISTINCT SUBSTR (poc.wf_item_type, 1, 15) ITEM_TYPE,
SUBSTR (poc.wf_item_key, 1, 15) ITEM_KEY,
poc.document_header_id HEADER_ID
FROM po_change_requests poc,
po_requisition_headers_all prh,
po_requisition_lines_all prl,
po_line_locations_all poll
WHERE prl.requisition_header_id = prh.requisition_header_id
AND prl.line_location_id = poll.line_location_id
AND poll.line_location_id = poc.document_line_location_id
AND prh.segment1 = '&ReqNum'

c) SQL> @wfstatus.sql <item type> <item key>

Important Points to be consider using this functionality

At any given time, there can be only a single change request pending per
requisition. Until the pending change request is completely acted upon, the
requisitioner cannot request any new purchase order (PO) change requests for the
requisition.

Only the preparer of the requisition can request purchase order change requests
for the requisition.

If a purchase order line contains multiple distributions corresponding to the

different requisitions, then the purchase order line is not eligible for change
request and none of the Oracle iProcurement users who prepared the requisitions
can request changes to the purchase order.

If the purchase order has any approval status other than Approved, then the
purchase order is not eligible for a change request and none of the Oracle
iProcurement users who prepared the requisitions associated with the purchase
order can request changes to the purchase order.
If the purchase order has any control status other than Closed for Receiving or
Closed for Invoicing, then the purchase order is not eligible for a change request
and none of the Oracle iProcurement user who prepared the requisitions
associated with the purchase order can request changes to the purchase order.

If the purchase order shipment has a control status other than Closed for
Receiving or Closed for Invoicing, then the purchase order shipment is not
eligible for a change request and none of the Oracle iProcurement user who
prepared the requisition lines associated with the purchase order shipment can
request changes to the purchase order shipment.

If Purchase Order is in HOLD status or Frozen Status then purchase order is not
eligible for a change request.

Price changes for Non Catalog Request Items are not allowed to Partially
Invoiced, Received and Accrue on Receipt purchase orders.

When the purchase order line contains a Non-Catalog Request item in a foreign
currency, the Oracle iProcurement user can request a price change for that item in
both the foreign currency of the item as well as the functional currency for the
operating unit. In case of price change request in the foreign currency of the item,
the conversion rate used for the change request is the same as the one used at the
time of purchase order creation.

While the purchase order change request is being approved in the Oracle
iProcurement user's approval hierarchy, if the PO becomes ineligible for change
(e.g. purchase order goes into a Cancelled control status), then the PO change
request is automatically rejected. The buyer will not receive the notification to
process the change request, and nor will the change request appear in the buyer
self-service screen.

After the purchase order change request has been approved in the Oracle
iProcurement user's approval hierarchy and before the request is sent to the buyer
on the purchase order for processing, a check is made to compare the requested
values for the attributes on the change request and the current values on the PO. If
these values are same, then the purchase order change request is automatically
accepted. The buyer will not receive the notification to approve the change
request, and nor will the request appears in the buyer self-service screen.

While the purchase order change request is being approved in the Oracle
iProcurement user's approval hierarchy, if the purchase order goes into an In
process approval status or a Requires Re-approval status, then the purchase order
change request is deferred and will not sent to the buyer until the purchase order
is reverted back to Approved status.
 Encumbrance (if enabled) support is available for the change request. When the
requester is creating the purchase order change request in Oracle iProcurement,
the encumbrance funds check is performed for the revised requisition document
total if there is an increase in the document total. The actual funds reservation will
be performed after the buyer responds to the purchase order change request.

Tax support is available for the change request. While submitting the change
request, the estimated tax applicable to the requisition will be recomputed based
on the revised requisition document total.

If there is price breaks applicable to the purchase order based on the changes
requested by the requester, those will be applied to the purchase order.

Recommended Patch List

Patch 3769157: Buyer acceptance of change order notification not received by requestor
Note: This issue happens only when the buyer is responding to the requester
notification after logging into the Home page through the work list. However, if the
buyer responds by logging into Core PO and responds through notifications
summary, this issue will not happen.

Patch 3431902: In Oracle iProcurement, approving change request notification results in

error, if Purge Obsolete Workflow runs.

Patch 3107071: Requester can receive against po shipments that are changed via
Requester Change Order

Patch 3548549: Buyer approval notification fails for certain supplier with long address
information

Patch 3517453: iProcurement requisition change not emailing approved change to

supplier

Patch 3862383: In Oracle iProcurement, PO Action History for ACTION = 'CHANGE

REQUESTED' did not display correct user.
Instead of Requester, it was showing Buyer's name.

Patch 3691446: In Oracle iProcurement, changing an auto created requisition results in

encumbrance imbalance after the buyer approves the change request in requester change
order process.

Patch 3185688: In requester change order, requester cannot cancel approved requisition,
which has lines tied to multiple shipments of a same PO.
Summary
It is our desire that this white paper has helped you understand the fundamentals of
Requester change order functionality. Purchasing provides great flexibility in
implementing Requester change order workflow. To use this feature Successfully,
business needs and high level of automation in the business process transactions can be
achieved.
Requester change order functionality replaces the typical manual change process with a
streamlined automatic process that can dramatically reduce costs and time involved in
doing so. This will reduce significant manual effort on the user’s part.
We hope you are now better equipped to troubleshoot problems and determine what
needs to be done to resolve issues pertaining to Requester change order functionality. If
you encounter a problem that requires assistance, please remember to log an iTAR
with Oracle Support.

Acknowledgement

I wish to record my sincere appreciation towards:

Lisa Oinonen and Clarina Allen of Procurement Team for reviewing this paper and for
making it complete with their feedback.
A special thanks to Rajalingam Ramasamy, from Procurement PQE team for reviewing
this document and for making it complete with his inputs. We are grateful to Adiraju
Sastry and Chandu Tadanki for their constant encouragement and support.
Requester change order in Procurement
Jan 2005
Author: Rajiv Arora (CPIM)

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com

Oracle is a registered trademark of Oracle Corporation. Various

product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.

Copyright © 2003 Oracle Corporation

All rights reserved.