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 limit (percent)

Lower tolerance Limit (percent)

Quantity ordered

Numeric so tolerance limit

0 100

Unit Price Numeric so tolerance limit

0 100

Requisition Amount

Numeric so tolerance limit

0 100

Need By Date Non Numeric so only YES or NO

‘Y’ or ‘N’ ‘Y’ or ‘N’

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.