Oracle Procurement Contract (a step by step user guide)

Download Word File

Mass Feature Available in Oracle Purchasing R12

Click Link To Download

How to Get Approval Group assigned to specific Job and Position in Oracle Purchasing

How to Get Approval Group assigned to specific Job and Position in Oracle Purchasing

Remittance Advice by Email to Supplier by Using UTL_SMTP

Click on Link to Read Article

Strength and Weakness of Approval Hierarchies available in Oracle Purchasing

Strengths and Weaknesses of Approvals Using the Employee/Supervisor Relationship

Strengths

• Allows flexibility of establishing approval groups around either jobs or positions.

• Assuming Oracle Human Resources (HR) is installed and the data is being maintained, Purchasing uses the supervisor name on the employee record which should be entered and maintained for HR purposes already.

Weaknesses

• Documents may not travel by the employee/supervisor relationship for approval purposes, but take a different path in part or entirely.

• Documents can get hung up more frequently due to the volume of personnel changes that typically occur in companies.

• Higher volumes of documents need to be re-routed using the Forward-To settings. Recall that the first name alphabetically appears as the default.

Strengths and Weaknesses of Approvals Using Position Approval Hierarchies

Strengths

• Allows approval paths to be set up that follow the actual flow of documents for approval

• Assuming Human Resources is installed and the data is being maintained, Purchasing can make an employee representation of the position approval hierarchy by simply running the Fill Employee Hierarchy process. This will allow changes occurring in personnel assignments to be updated in the position approval hierarchy.

• Documents can get hung up less frequently due to the lower volume of structural hierarchy changes compared to the higher volume of personnel changes that typically occur in companies.

• Lower volumes of documents need to be re-routed using the Forward To settings, especially when there are multiple holders in a particular job or position. Recall that the first name alphabetically appears as the default when there are multiple holders.

Weaknesses

• Cannot be used with jobs, but must be used with positions.

Some Doubts………..In Oracle Purchasing

What if there is more than one holder in a job or position?

Multiple holders in the same job or position can only occur if Oracle Human Resources is installed. If only Oracle Purchasing is installed, you can assign only one employee to each job or position. If multiple holders exist when using position approval hierarchies, Oracle Workflow will route the document to the holder based on alphabetical order. You can see who the system will route the document to by clicking the Forward radio button, overriding the defaulted name if needed.

What if there are changes to the position approval hierarchy?

Personnel changes are updated in the position approval hierarchy by running the Fill Employee Hierarchy process which reviews the employee record to determine the current position assignment. You will probably want to schedule this process to run on a frequent basis to ensure smooth processing of all approval requests. Structural changes to the position approval hierarchy require the hierarchy to be rebuilt from the point where the change occurs to the bottom of that branch. Documents are routed according to the hierarchy in effect at the time they are submitted for approval.

What if Human Resources were already implemented with jobs set up, but no positions?

Unless the decision to set up jobs only and no positions can be revisited, you will have to route all documents by the employee/supervisor relationship and maintain this data on the employee records.

What if the approver is unavailable for an extended period?

Oracle Purchasing has the ability to automatically forward documents when users do not respond to notifications. This tool should be used when possible to prevent documents from holding up business productivity. Oracle Workflow manages this functionality, typically set up to send a first and second reminder after pre-determined time periods before forwarding the notification to the next approver.

What if the document has a status of Pre-Approved?

The status of Pre-Approved is the outcome of a person forwarding a document for approval even though the forwarding person has the necessary authority to approve it. The document may have been forwarded by mistake or for business reasons. Once the person it was forwarded to approves the document, the status will be changed to Approved and subsequent actions such as receiving and invoicing can be completed.

What if there is no account range on an approval group assigned to a job or position?

By default, all accounts are excluded from an approval group and therefore documents governed by this approval group cannot be approved. You avoid this situation by ensuring that there is at least one Account Range Include rule on every Approval Group.

What if Workflow can’t find a supervisor to approve the document?

If this occurs, the person submitting the request for approval must forward the document to a different person in the list of values for Forward To. If this isn’t done, the document will be returned to an Incomplete status and a notification will be sent stating No Approver Found – Please Select a Forward To Employee. If using employee/supervisor relationship to determine approval paths, the list of values will include all active employees. If using position approval hierarchies to determine approval paths, the list of values will include all employees in the hierarchy selected.

What if a job or position has different authority levels for different document types?

You may have jobs or positions that can approve one document up to a specified dollar amount, while they can approve another document at a lower dollar amount. If this occurs, simply set up multiple approval groups with the rules properly defined for the differences and ensure that the right approval group is assigned to the correct document type.

What if documents flow employee/supervisor, but approval rules are needed?

Approval Groups can be used whether approval paths are determined by employee/supervisor relationships or by position approval hierarchies.

Document Access and Security Level in Oracle Purchasing

Document Access Levels

Specify an access level to control what modification and control actions can take on a particular document once user gain access. Document owners always have full access to their documents.

Following are Access level options

• View Only – Accessing employees can only view the document. Only the document owner may modify or control the document.

• Modify – Accessing employees can view, modify, freeze and close the document.

• Full – Accessing employees can view, modify, freeze, close, cancel and finally close the document.

Document Security Levels

Anyone with menu access to the document entry window can create a document. These individuals then become the document owners.

Security levels can be set for each document type. Following are Security level options

• Private – Only the document owner and subsequent approvers can access the document.

• Purchasing – Only the document owner, subsequent approvers, and individuals defined as buyers can access the document.

• Hierarchy – Only the document owner, subsequent approvers, and individuals above the document owner in the security hierarchy can access the document.

• Public – All system users can access the document.

Accrual Accounting – Periodic Accrual on Period End

Accrual Accounting – Periodic Accrual on Period End in Oracle Purchasing

Debugging the Approval Workflow for Purchase Order or Purchase Requisition

Step 1

Review the action history of the document having a problem. This is done in the Purchasing Summary screens – either Requisitions –> Requisitions Summary or Purchase Orders –> Purchase Order Summary. If you attempt to view the action history and you receive the following error:

APP-14288 This document is either incomplete or you do not have access to it

Then this represents that Workflow has not yet performed a submit into the action history table. The document approval manager performs the action of submitting a record into the Action History and therefore is required to be running. It should be confirmed that the document approval manager is running.

Step 2

Notification Summary – review the Notification Summary for the user that submitted the document. Are there any notifications present? Because online form messaging alerts are now present in the form of notifications, it is imperative that the summary be reviewed for any informative notifications explaining in more detail as to the problem.

Step 3

Confirmation that the Workflow Background Process has been run via the System Administrator responsibility.

This is done via Requests –> Run within the System Administrator Responsibility. The parameters should be the Item Type – PO or Requisition Approval and then

Processed Deferred = Yes, Process Time Out = Yes. Process Stuck = Yes if the Process Stuck parameter is available.

Step 4

Ensure that all tables contain the necessary space to record the Workflow processing data. As users submit a document for Approval and the Workflow process is called, data is recorded into a series of Workflow tables. To quickly confirm whether the tables are having space limitations or not? Run the following in SQL:

select value

from v$parameter

where name like ‘background_dump_dest’;

The value returned by this SQL statement represents the location of the alert log on the database server,

For the instance in question. Please ask the Database Administrator to review the latest entries into the alert.log to confirm if any errors are being thrown with regards to table space.

The most common scenario that has been linked to table space, is when a user hits the ‘Approve’ button in the approval screen, only to have nothing happen. There is no message returned stating document has been submitted for Approval, nothing happens. The hourglass comes for 1 second, and then leaves, and the approval form is still present. This is most likely a table space issue.

Step 5

Workflow Monitor from the Purchase Summary screens. Utilize the Workflow monitor to track the path which the document has taken during its submission to Workflow. Some important milestones to look for in the Workflow monitor are ‘Can Owner Approve’ and ‘Does Approver have Approval Authority’. Are there any processes that contain errors? Or does it appear that a process has stopped at a point that is incorrect?

Example is if a process stopped at a point that is not referencing a notification or some other request point for user interaction

How to Get Supplier Bank Detail In R12

In Release 12, Payables Supplier Bank Information is stored somewhere else instead of PO_VENDORS table as in 11i. After going thru the guides, it seems that the bank information (such as bank account numbers, etc) for suppliers may be in TCA or in Cash Management Bank Model. Please provide the tables names where bank account information and other bank related information is stored?

By Using Following Queries you can get Required Information on Basis on Supplier Site Name

/* For Supplier Bank Account Number Use This One */

SELECT bank_account_name, bank_account_num, branch_id

FROM iby_ext_bank_accounts

WHERE ext_bank_account_id IN (

SELECT ext_bank_account_id

FROM iby_account_owners

WHERE account_owner_party_id IN (

SELECT party_id

FROM hz_party_sites

WHERE party_site_name LIKE

‘%UPC%’))

/* USE THIS QUERY TO GET BANK NAME AND BANK BRANCH NAME OF SUPPLIER BANK*/

SELECT BANKORGPROFILE.HOME_COUNTRY BANK_HOME_COUNTRY,

BANKORGPROFILE.PARTY_ID BANK_PARTY_ID,

BANKORGPROFILE.ORGANIZATION_NAME BANK_NAME,

BANKORGPROFILE.BANK_OR_BRANCH_NUMBER BANK_NUMBER,

BRANCHPARTY.PARTY_ID BRANCH_PARTY_ID,

BRANCHPARTY.PARTY_NAME BANK_BRANCH_NAME,

BRANCHPARTY.PARTY_ID

FROM HZ_ORGANIZATION_PROFILES BANKORGPROFILE,

HZ_CODE_ASSIGNMENTS BANKCA,

HZ_PARTIES BRANCHPARTY,

HZ_ORGANIZATION_PROFILES BRANCHORGPROFILE,

HZ_CODE_ASSIGNMENTS BRANCHCA,

HZ_RELATIONSHIPS BRREL,

HZ_CODE_ASSIGNMENTS BRANCHTYPECA,

HZ_CONTACT_POINTS BRANCHCP,

HZ_CONTACT_POINTS EDICP

WHERE SYSDATE BETWEEN TRUNC (BANKORGPROFILE.EFFECTIVE_START_DATE)

AND NVL (TRUNC (BANKORGPROFILE.EFFECTIVE_END_DATE),

SYSDATE + 1

)

AND BANKCA.CLASS_CATEGORY = ‘BANK_INSTITUTION_TYPE’

AND BANKCA.CLASS_CODE IN (‘BANK’, ‘CLEARINGHOUSE’)

AND BANKCA.OWNER_TABLE_NAME = ‘HZ_PARTIES’

AND (BANKCA.STATUS = ‘A’ OR BANKCA.STATUS IS NULL)

AND BANKCA.OWNER_TABLE_ID = BANKORGPROFILE.PARTY_ID

AND BRANCHPARTY.PARTY_TYPE = ‘ORGANIZATION’

AND BRANCHPARTY.STATUS = ‘A’

AND BRANCHORGPROFILE.PARTY_ID = BRANCHPARTY.PARTY_ID

AND SYSDATE BETWEEN TRUNC (BRANCHORGPROFILE.EFFECTIVE_START_DATE)

AND NVL (TRUNC (BRANCHORGPROFILE.EFFECTIVE_END_DATE),

SYSDATE + 1

)

AND BRANCHCA.CLASS_CATEGORY = ‘BANK_INSTITUTION_TYPE’

AND BRANCHCA.CLASS_CODE IN (‘BANK_BRANCH’, ‘CLEARINGHOUSE_BRANCH’)

AND BRANCHCA.OWNER_TABLE_NAME = ‘HZ_PARTIES’

AND (BRANCHCA.STATUS = ‘A’ OR BRANCHCA.STATUS IS NULL)

AND BRANCHCA.OWNER_TABLE_ID = BRANCHPARTY.PARTY_ID

AND BANKORGPROFILE.PARTY_ID = BRREL.OBJECT_ID

AND BRREL.RELATIONSHIP_TYPE = ‘BANK_AND_BRANCH’

AND BRREL.RELATIONSHIP_CODE = ‘BRANCH_OF’

AND BRREL.STATUS = ‘A’

AND BRREL.SUBJECT_TABLE_NAME = ‘HZ_PARTIES’

AND BRREL.SUBJECT_TYPE = ‘ORGANIZATION’

AND BRREL.OBJECT_TABLE_NAME = ‘HZ_PARTIES’

AND BRREL.OBJECT_TYPE = ‘ORGANIZATION’

AND BRREL.SUBJECT_ID = BRANCHPARTY.PARTY_ID

AND BRANCHTYPECA.CLASS_CATEGORY(+) = ‘BANK_BRANCH_TYPE’

AND BRANCHTYPECA.PRIMARY_FLAG(+) = ‘Y’

AND BRANCHTYPECA.OWNER_TABLE_NAME(+) = ‘HZ_PARTIES’

AND BRANCHTYPECA.OWNER_TABLE_ID(+) = BRANCHPARTY.PARTY_ID

AND BRANCHTYPECA.STATUS(+) = ‘A’

AND BRANCHCP.OWNER_TABLE_NAME(+) = ‘HZ_PARTIES’

AND BRANCHCP.OWNER_TABLE_ID(+) = BRANCHPARTY.PARTY_ID

AND BRANCHCP.CONTACT_POINT_TYPE(+) = ‘EFT’

AND BRANCHCP.STATUS(+) = ‘A’

AND EDICP.OWNER_TABLE_NAME(+) = ‘HZ_PARTIES’

AND EDICP.OWNER_TABLE_ID(+) = BRANCHPARTY.PARTY_ID

AND EDICP.CONTACT_POINT_TYPE(+) = ‘EDI’

AND EDICP.STATUS(+) = ‘A’

AND BRANCHCA.OWNER_TABLE_ID = :IBY_BRANCH_ID /*USER BRANCH ID FROM ABOVE QUERY*/

If anyone have a better solution then please update

Accounting Entries of Accrue on receipt (APO) in Oracle Application?

Accounting entries for purchase orders with destinations type expense, item type expense and with accrue on receipt option is true.

Sequence of actions and accounting entries

Action

Create, Approve, Reserve PO

Accounting entries

Budget a/c DR @ PO price (base + Non Recoverable Tax calculated for the (received quantity * PO line unit price))

Action

Invoice Validation after matching

Accounting entries

Recoverable Tax calculated for the (received quantity * PO line unit price) and Non Recoverable Tax calculated for the (received quantity * PO line unit price) DR @ tax amount

Action

Create Accounting for invoice

Accounting entries

AP Expense accrual a/c DR @ PO price excluding tax and tax DR @ tax rate separately

AP Liability a/c CR @ invoice price

REC Tax and Non Recoverable Tax calculated for the (received quantity * PO line unit price) CR @ tax amount

Action

Receive the PO

Accounting entries

Receiving Inspection a/c DR @ PO price (base + Non Recoverable Tax calculated for the (received quantity * PO line unit price))

AP Expense accrual a/c CR @ PO price (base+ Non Recoverable Tax calculated for the (received quantity * PO line unit price))

Action

Deliver the PO

Accounting entries

Expense Charge a/c DR @ PO price (base + Non Recoverable Tax calculated for the (received quantity * PO line unit price))

Receiving Inspection a/c CR @ PO price (base + Non Recoverable Tax calculated for the (received quantity * PO line unit price))

Budget a/c CR @ PO price (base + Non Recoverable Tax calculated for the (received quantity * PO line unit price))

Reference

Accounting Flow against Purchase Orders, Receipts and Matched Invoices.

Authors: Manighandan Venkatraman & Asha Ravada

Oracle Purchasing Hierarchies used for Approval routing.

There are two types of Hierarchies used for approval routing.

a. Position Hierarchies

b. Supervisor Hierarchies

Position Hierarchies

========================

Position Hierarchies are hierarchies that have a JOB/POSITION relationship.

For example, you could have a JOB called BUYER and within BUYER you could have various grades or POSITIONS of BUYER – Junior, Senior and Chief

Each POSITION has an approval limit, so when a purchase order exceeds the limits of the POSITION, the purchase order is forwarded onto the next POSITION in the Hierarchy.

The hierarchy for this JOB/POSITION type of hierarchy is defined on the Position Hierarchy form. When this is complete or is changed, the Fill Employee Hierarchy concurrent process must be run for the new hierarchy to come into effect.

The Position Hierarchy form can be found at PO Navigator – Setup – Personnel – Position Hierarchy

Supervisor Hierarchies

==========================

Supervisor Hierarchies are hierarchies that have an Employee/Supervisor relationship

The supervisor of an employee is defined on the Assignment zone of the Employee form

This type of hierarchy does not use the Position Hierarchy form, but is defined by the employee / supervisor relationship

If the purchase order raised by the employee exceeds the approval limits, the purchase order is forwarded onto the employees’ supervisor, as defined on the Employee form.

Reference

Oracle Metalink and Oracle White Papers

Types of purchase order/agreements used in Oracle Purchasing

Standard Purchase Order

Planned Purchase Order: A planned purchase order is a long-term agreement committing to buy it items or services from a single source. We must specify tentative delivery schedules and all details for goods or services that we want to buy, including charge account, quantities and estimated cost. EX: Buying goods for Christmas from a specific dealer.

Contract Purchase Order: We can create contract purchase agreement with our supplier to agree on specific terms and conditions without indicating the goods and services that we will be purchasing i.e. for Rupees amount we must supply this much quantity. We can later issue standard PO referencing our contracts and we can encumber these purchase orders if we use encumbrance accounting.

Blanket Purchase Order: We can create blanket purchase agreements when we know the detail of goods or services we have plan to buy from a specific supplier in a period , but we do not yet know the detail of our delivery schedules. We can use blanket purchase agreements to specify negotiated prices for our items before actually purchasing them

Information Templates in Purchasing

Oracle iProcurement 11i uses information templates to pass necessary order processing information to suppliers. We can set up information templates to gather additional information when an information template is assigned to a category or item, iProcurement prompts users to provide the information specified in the template

To define an information template:

• Navigate to the Define Information Template window by using the Oracle Purchasing menu,

Setup –> Information Templates.

• Enter an attribute name and description. The attribute name is the actual
  field prompt that is displayed in iProcurement.
• Optionally, enter a default value to automatically appear in the field.
• Indicate whether the field is mandatory for iProcurement 11i users.
  If the field is mandatory, users will be prompted to enter a value in the field
  before proceeding to complete the requisition.
• Indicate whether to activate the attribute to actually display on Self Service purchasing pages. 

In certain circumstances, you may want to define an attribute, but delay enabling it for display to iProcurement users

Purchase order and Invoice Matching

Purchasing and Payables enable you to match invoices to purchase order shipments or purchase order distribution lines. There are following three ways to match Purchase Order and Invoices

2-way matching

This verifies that Purchase order and invoice information match within your tolerances as follows and check following:

Invoice price <= Purchase order price Quantity billed <= Quantity Ordered

3-way matching
This verifies that the receipt and invoice information match with the quantity tolerances defined and check following:

Invoice price <= Purchase order price Quantity billed <= Quantity Ordered Quantity billed <= Quantity received

4-way matching
This verifies that acceptance documents and invoice information match within the quantity tolerances defined and check following:

Invoice price <= Purchase order price
Quantity billed <= Quantity Ordered
Quantity billed <= Quantity received
Quantity billed <= Quantity accepted

Check Work Flow Activity In Error

I have used This Query to check Error in Purchase Order Work flow(Mean How Much PO stuck in work flow)

SELECT DISTINCT wi.item_type item_type, wi.item_key item_key,

wpa.process_name

|| ‘:’

|| wpa.instance_label error_process_activity_label,

wf_engine.getitemattrtext (‘WFERROR’,

wi.item_key,

‘ERROR_ITEM_TYPE’

) errant_item_type,

wf_engine.getitemattrtext (‘WFERROR’,

wi.item_key,

‘ERROR_ITEM_KEY’

) errant_item_key

FROM wf_items wi,

wf_item_activity_statuses wias,

wf_item_activity_statuses wias1,

wf_process_activities wpa

WHERE wi.item_type = ‘WFERROR’

AND wi.end_date IS NULL

AND TO_NUMBER (wf_engine.getitemattrtext (‘WFERROR’,

wi.item_key,

‘ERROR_ACTIVITY_ID’

)

) = wias.process_activity

AND wf_engine.getitemattrtext (‘WFERROR’,

wi.item_key,

‘ERROR_ITEM_TYPE’

) = wias.item_type(+)

AND wf_engine.getitemattrtext (‘WFERROR’,

wi.item_key,

‘ERROR_ITEM_KEY’

) = wias.item_key(+)

AND wias.activity_status(+) ‘ERROR’

AND wias1.item_type = wi.item_type

AND wias1.item_key = wi.item_key

AND wias1.end_date IS NULL

AND wias1.notification_id IS NOT NULL

AND wias1.process_activity = wpa.instance_id;

Setup Steps and Considerations Common to Oracle Purchasing and Payables

Some setup steps are common to both Oracle Purchasing and Oracle Payables. First, we will discuss the common setup steps and considerations. The common setup steps are as follows:

· System administrator

· Other modules flex fields

· Accounting calendars

· Workday calendar

· Currencies

· Conversion rates

· Set of Books

· Opening and closing accounting periods

· Organizations

· Human resources

· Tax names

· Locations

· Suppliers

System Administrator

Setting up system administrator functions is a required task, and involves setting up system security, defining user names, and defining system printers. User IDs must be defined for all users, and additional responsibilities may also need to be defined. The Oracle System Administrator responsibility will need to be set up to perform this task.

Considerations involved in this step are security and establishing naming conventions to be used throughout Oracle Applications. You must determine which responsibilities should be tied to which users and whether to exclude forms and functions from the standard menu. You must also establish a naming convention for printers and set them up. This lets users know where the printer will be located by simply reading the printer name. You must also determine whether a dedicated printer will be necessary for checks and purchase orders, which usually have special preprinted forms.

Other Module Key Flexfields

This step involves setting up other modules’ Key flexfields related to Oracle Purchasing and Oracle Payables. These Key flexfields include accounting, human resources, and inventory. The accounting Key flexfield must be defined through the General Ledger setup and configuration. Next, set up the four human resources Key flexfields: job, position, grade, and people group. You needn’t set up these flexfields if you already have installed Oracle Human Resources, or if you’re installing in a common application setup (in which case, it will be done during the HR setup). The following inventory Key flexfields should be defined as part of the inventory setup: item catalog, item category and system items. Once you have defined the system items flex field, you must run the Item Flex field view.

Considerations involved in this step involve constructing Key flex fields that have room to grow, that can be used across modules, and that can be validated according to everyone’s need. You must also determine how to maintain valid values, whether to allow dynamic insertions, and how to enforce security.

Accounting Calendars

If you have not defined your accounting calendars in Oracle General Ledger, then you must define them for Oracle Purchasing and Oracle Payables. If you are performing a multi-org implementation of Purchasing and Payables, you may also create more than one calendar.

Whether you need an adjusting period and how to name your accounting period are the two considerations for this setup step. Your accounting calendar is dictated by your business needs, and all Oracle Applications modules share the same accounting calendar, yet they maintain a separate status for each module. For example, an open period in Payables can be a closed period in Receivables.

Workday Calendar

If you have not defined your workday calendars in Oracle Inventory, you must define them for Oracle Purchasing and Oracle Payables. If you are performing a multi-org implementation of Purchasing and Payables, you may also create more than one calendar.

How to name your inventory period and how to create an exception template to filter out nonworking days are the two considerations for this setup step. Your workday calendar is dictated by your business needs, and all Oracle Applications modules share the same workday calendar.

Currencies

If you are planning to use the multi currency features of Oracle, you must also enable the currencies you need. This step is done in Oracle General Ledger.

Determining which currencies you need is the only consideration for this setup step. Oracle Applications has all ISO currencies, but if you have a currency that is not defined, you must define it in Oracle General Ledger.

Conversion Rates

If you plan to use Oracle’s multi currency features, you must also define conversion rate types, daily rates, period rates, and historical rates in Oracle General Ledger.

Determining what kind of exchange rates to use and who will maintain the exchange rates for your company are the two considerations for this setup step.

Set of Books

At least one Set of Books must be defined in Oracle General Ledger in order to use the other modules. Once you have created the Sets of Books, assign responsibilities of Oracle Purchasing and Oracle Payables to the defined Sets of Books.

Considerations for this step, which include whether you want to perform suspense accounting, intercompany accounting, and budgetary control, among others, are covered in the first part of this book.

Opening and Closing Accounting Periods

Next, you must open the appropriate accounting period in Oracle General Ledger. Whether you should open and close the accounting periods is the only consideration for this step. If you open the accounting period, accounting entries and transactions can be entered for the opened accounting period. Open the appropriate inventory and purchasing periods, and open purchasing periods for which you have purchasing activity. Oracle Purchasing will only create journal entries for transactions in an open purchasing period, including creating the correct receipt accrual journal entry. Use the Control Purchasing Periods form to open/close purchasing periods.

Organizations

If you use expense reporting in Oracle Payables, you must define one or more organizations before using Oracle Purchasing and Oracle Payables. Organizations describe and define unique entities within your company, such as manufacturing plants, warehouses, distribution centers, and sales offices. Oracle Purchasing fully supports both centralized and decentralized purchasing for multiple receiving organizations. You can change your current receiving organization at any time with the Change Organization form.

There are multiple considerations for this step. You must determine your company structure, and what kind of security precautions to enforce. In other words, define how you want to segregate data and how you want personnel from one organization to interact with data from another organization. You also need to determine whether you want to centralize or decentralize each Oracle Applications module.

Human Resources

You will need to set up personnel, or human resources information if Human Resources is not installed. This step involves defining employee lookup codes, supplier and employee numbering, positions, position hierarchies, and employees. You must define employees when you define buyers, which is a required step for Oracle Purchasing. You must also define positions, position hierarchies, and employees if you will be using hierarchies for approvals and workflow.

How you want to number your employees and approve purchasing documents are the two considerations for this step. Approving purchase orders can be very complicated, and you can use a purchasing hierarchy for this task. A purchasing hierarchy is a position hierarchy that you can use to determine the relationship between employees when Oracle Purchasing tries to get the next level of approval.

Tax Names

Until now, all common setups have been performed in Oracle Applications modules, with the exception of the procurement modules. The remaining common setup steps are specific to Oracle Purchasing and Oracle Payables. To get to the Setup form, you must sign on as the Operation user and select the Purchasing, Vision Operations (USA) responsibility. The tax name, which you can use when entering tax amounts in payables invoices, defines a specific tax rate and tax account. You must define tax names for each operating unit. To set up tax names, you follow the navigation path Setup : Financials : Accounting: Taxes.

The only consideration for this step is that the tax name you choose be sufficiently descriptive when your users select it within the Payables invoices.

Locations

For purchasing, you must set up locations, which can be defined as ship-to, bill-to, office, internal, or receiving sites. You can follow the navigation path Setup : Organizations: Locations to set up locations.

Suppliers

Suppliers can be created and maintained in Oracle Purchasing or Oracle Payables. You define the suppliers, the supplier sites, and the supplier contacts. Deciding who should maintains suppliers, since you do not want two departments within your organization to duplicate maintenance of the supplier master, is the primary consideration for this step. You must also establish and maintain a naming convention so that your users know how to select existing suppliers.

Oracle Purchasing with Other Oracle Applications Modules

Oracle Purchasing integrates with a number of other Oracle Applications modules, including:

· Oracle Order Entry

· Oracle Inventory

· Oracle Work flow

· Oracle Material Resource Planing

· Oracle Projects

· Oracle Human Resources

· Oracle Alert

· Oracle Quality

· Oracle EDI Gateway

· Oracle General Ledger

Oracle Order Entry

Once the internal requisition has been approved and interfaced to Order Entry, the sales order must proceed through the order cycle. This includes pick release, ship confirm, and inventory interface processing (not Supplier), which can automatically create internal sales orders in Oracle Order Entry. Internal sales orders are those that are ordered from another organization within your own company. The organization that fulfills the order is the selling organization, while the organization with the purchase requisition is the buying organization.

Oracle Inventory

Purchasing increases Inventory’s on-hand balance when POs are received and delivered. Internal requisitions, mentioned above, also affect demand once the item has been reserved and depletes the shipping organization’s on-hand balance once it has been shipped.

Oracle Work flow

There are two areas where Oracle Purchasing integrates with Oracle Work flow. The first is Account Generator, with a work flow process that defines the business rules in which account combinations are generated. The second area consists of some seeded approval work flow processes. These work flow processes read the approval business rules and hierarchies you set up in Oracle Purchasing, and they drive purchasing documents such as purchase requisitions and purchase orders through defined approval business rules and hierarchies.

Oracle Material Resource Planing

The material planning process in Oracle Material resource planing automatically generates purchase requisitions for raw materials (goods) or outside processing (services).

Oracle Projects

When you buy goods and/or services for a particular project, Oracle Purchasing, which allows you to capture project information on purchasing documents, integrates with Oracle Projects.

Oracle Human Resources

Oracle Purchasing shares employees and positions information with Oracle Human Resources. The two also share position hierarchies if approvals in Oracle Purchasing and Human Resources are set up to use the same position hierarchies.

Oracle Alert

Oracle Purchasing has some seeded alerts to help monitor exceptions and buyer performances, get notified with releases and expirations against planned and/or blanket purchase orders, and identify potential forecast overconsumption.

Oracle Quality

You can capture quality data, which will be automatically stored in Oracle Quality, during receiving. You can also make the capturing of quality data mandatory in Oracle Purchasing.

Oracle EDI Gateway

Oracle EDI gateways offers EDI capability to Oracle Purchasing. Supported purchasing EDI transactions in Oracle EDI gateways are Inbound Price/Sales Catalog (832), Inbound Response to Request for Quote (843), Inbound Ship Notice/Manifest (856), Inbound Shipping and Billing Notice (857), Outbound Planning Schedule (830), Outbound Shipping Schedule (862), Outbound Purchase Order (850), and Outbound Purchase Order Change request (860).

Oracle General Ledger

Oracle Purchasing posts encumbrance entries and receipt accrual entries to Oracle General Ledger.