Past few months I had been involved in an implementation of iProcurement or you can say overriding Core Purchasing at a government client in Australia. The solution was a Procure to Pay and involved workflow customization , OAF , Personalization and some custom.pll . For me it was a completely new custom module.

The original way of working (we can call it ) was the govt. agency was making use of Core Purchasing to Create Purchase Orders Manually which based on employee-supervisor hierarchy was sent to the buyer’s approver for Approval. The Approver would receive a notification email in his/her Lotus Notes (IBM …mst say very poor in case if we have to view HTML stuff). He/She act on the email and accordingly the PO is approved or rejected. In case PO is approved, it is sent to Supplier by an email (Thats a separate custom program which is run after a while and not by the standard functionality ..).. Goods are received physically…No tracking in Oracle in terms of Receiving or Receipts..Payables department create AP invoice manually.

New way of working (I call it ) is making use of Internet procurement (having lots of good things and benefits..you can refer to Oracle.com) where each employee is a requester or preparer of the Requisition (is a buyer as well). The Preparer creates a Non-Catalog Request (They are not using Item Master..) which is then created to a specific Purchase requisition. An important business rule is Each Non-Catalog request is linked to one specific combination of Supplier/site which is in turn linked to one Purchase requisition (Standard PR allows having multiple supplier/sites linked to it..). Once PR is created , it is submitted to the same hierarchy as the PO Hierarchy. The Approver receives a notification email and acts upon it. Once the PR is approved, a PO is created automatically in Approved status as well. Technically speaking, there was some tweaking done So when Requisition Approval Workflow is launched, Create PO document wf is triggered upon approval action which in turn calls PO Approval wf. Also logic of attachments to be carried to PO was also built in.

A considerable amount of Personalization and OAF work had been taken place as well. Another thing in the original way of working was the use of context sensitive flexfields in PO Header. The same DFF’s were built in iProcurement and then built in logic of workflows to get it carried and defaulted onto the Approved PO as well. Some considerable customization was done on notification formats as well….

Receiving as a function was introduced as the new way of working. Pay on Receipt and RTS from Debit Memo were enabled. Invoice information was entered while creating a Receipt which would actually create a Invoice or a Debit Memo in Payables with the same notation as entered durinng receiving.

Aaaah..the last thing and an important thing..there was some big time trouble in analyzing and testing Change Management from PR to PO. The behaviour is however understandable. In 11.5.10.2 I Procurement , Oracle provides to update only Need bydate, Price, Quantity and Cancel. You cannot update Charge codes .. . This actually called in for a tweaking in for PO Tolerance check workflow and PR change workflow.

Finally the Go Live was easy going with no major show stoppers . My sincere thanks to Dart (We called us together Dynamic Duo of iProc) and Melinda (Our Principal )