Wednesday, February 18, 2009

11i Oracle Purchasing Technical Document

Oracle Purchasing is multi-org sensitive. The complexity depends on the set up.

Requisition Entry
Requisitions can be entered manually by the user or from the Requisition Import process.

Manual entry – Users will enter the data using the Requisitions form. At the header level, the user will enter the requisition number (if the app is set up to accept manual numbering), a requisition type and a description. At the line level, the user will enter the line type (Goods, Service, Labor etc.), and item (not required), a category (required), a description of the item or category, the units and the amount, the requestor, inventory org and location. Vendor and Vendor Site are optional. The user can enter multiple lines. After the line is entered, the user will enter the distributions for each line. Each line must have at least one distribution, but can consist of multiple. The distribution will be the code combination and/or project information for the purchase. When the user saves, the PR Account Generator is called to validate the code combination or if customized build the code combination based on auto-accounting rules from Oracle Projects. When the entry is saved, records are created in the following tables:

Import Entry – In order to import requisitions, the source must be mapped to the fields needed in the requisition interface. Coding will need to be done to utilize this functionality. Data will import using a concurrent process called Requisition Import. The data is brought into Oracle Purchasing and creates the header, lines and distributions. The main tables are:

Requisition Approval
Requisitions are approved based on specific application set-ups. The main set ups consist of determining of Approval Groups that determine the dollar value by document and/or account combination. The approval group is then assigned to a job title set up in the Oracle HR system. The amount assigned to the title determines who can have final approval authority. The user will submit the requisition from approval. The workflow then calls a process to build the initial approval list based on employee/supervisor (or position hierarchy if the system is set up that way). The list will include all approvers necessary to approve the requisition total. If there is no person with a high enough authority to approve, the requisition goes back to an incomplete status and the users will determine where the gap is and correct the assignments. If the requisition is on the incorrect path, the approver may forward the requisition to the correct person. The workflow will then call a procedure to rebuild the approval list based upon the forward to person’s employee/supervisor relationship. The procedure ends the current approval list header and creates a new header and lines. The history and status of the requisition is kept in the action history, which is viewable from the requisition form or from the requisition notification. The main tables are:

Purchase Order Entry
Purchase orders can be created 2 ways, autocreating from an approved requisition or by manual entry into the from.

Autocreate – In the autocreate form, the user will enter a requisition or search criteria to pull multiple requisitions available to be turned into purchase orders. The query will produce the lines available and the user can select all or any combination to create the purchase order. Example, if there are 3 requisitions approved for one vendor, the user can create one purchase order with all of the requisition information. The main tables are

Manual entry – The user enters into the Purchase Order form the same information as entry for the requisitions. The tables listed above are the main tables.

No comments: