Global Procurement Solutions – Not Just an Idea Anymore

Mike George, Sr. Principal Consultant

Fujitsu Consulting

Introduction:

Procurement has become an ever increasingly sought after topic of discussion in today’s environment. Many focus
groups exist that offer expert opinions as to how operations should be conducted. As business has expanded, internal
roles, responsibilities and expectations have changed as well. There has been a decided shift to split tactical and
strategic efforts, both from a personnel and process perspective. The old back-office purchasing model has evolved
into one of centers of excellence. Traditionally, software has lagged behind the best practice models, forcing
personnel to focus on daily operational activities, with minimal time to keep up with modern theory. However, with
the release of Oracle Applications 11.5.10, Oracle has helped bridge the gap between business desire and software
capabilities.

This paper will explore how and why a global manufacturing company has implemented Oracle’s Global Purchase
Agreement functionality to address their Original Design Manufacturer (ODM) and Contract Manufacturer (CM)
operations in the Americas, Europe, and Asia Pacific. The audience should learn detailed functionality and
requirements regarding Centralized Purchasing across Multiple Operating Units, and how Oracle Purchasing
integrates with other modules through utilizing this type of solution. It is not primarily intended to be an
implementation guide, although setups will be covered in detail, but rather a provocative thought process as to how a
company has, and others could, more fully utilize existing application functionality, providing opportunities for both
hard and soft-dollar savings.

Although the author has attempted to elaborate as much as practical, there is an inherit assumption that the audience
is familiar with Oracle Purchasing functionality and concepts from an advanced functional perspective. The paper
will begin with business processing procedures from a case study, and conclude with a system solution. Intermixed
within the paper are both factual statements and observations. The centralized purchasing model being discussed
requires application team integration in the purest sense. While the Purchasing module may be considered a key
component of the process, it is merely a partner within multiple applications that ultimately delivers the entire
enterprise solution.

COLLABORATE 07 Copyright © 2007 by Mike George Page 1

Understanding Global Purchase Agreements

A Global Agreement is a purchasing document that can be shared across Operating Units. For the context of this
paper, we will focus on Global Blanket Purchase Agreements, referred to hereafter as GPAs. To begin to understand
GPAs, we’ll first take a quick review of the normal Blanket Purchase Agreement (BPA) that has been around for
years.

A BPA is typically a time sensitive pricing document. Multiple items can be placed on the agreement’s lines with
specific Supplier pricing. This reference data is then available IF the company decided to procure any of those items
at “contract pricing” from that supplier. Fewer and fewer companies are actually using the document as a binding
commitment to purchase a set quantity of an item from a supplier, although that capability is still an option. To
further that usage, many companies maintain this as an internal document and do not transmit/share it with a
supplier. In this essence, the BPA is an internal pricing document used to facilitate automatic Release creation. Now,
without getting sidetracked on how each individual company may use the BPA from a commitment or
communication standpoint, let us take a look at the Blanket Release.

The Blanket Release is the actual order for the items. It states which line is being ordered along with quantity, when
and where it should be delivered, along with referencing information from the originating BPA, such as price.
Actual accounting information is contained on the Release, and not the BPA. The “Purchase Order Number” is
actually the BPA number concatenated with the Release number, similar to 1000987-1, where ‘1000987’ represents
the BPA, and ‘1’ represents the first Release.

The entire BPA/Release process is Operating Unit specific. If a company has 7 Operating Units defined and they
have global item pricing with a supplier that all organizations order against, they would need to define 7 distinct
BPAs with the same information on it. Anytime a price change needs to be implemented, it would be necessary to
update all 7 documents. Additionally, the company would be looking to potentially make 7 different check runs to
pay for the applicable orders.

In 11.5.9 or Procurement Family Pack I, buyers were able to leverage Blanket Purchase Agreement prices across
operating units but Purchase Order creation was only possible in the operating unit where demand originated. This
functionality helped minimize the strategic pricing dilemmas, but any type of centralized operational activities, such
as PO maintenance or Invoice Processing remained in segregated OU’s, requiring multiple responsibilities and other
issues in the event a Shared Service Center had been created.

In 11.5.10, the GPA with a supplier can now be shared between Operating Units. The concept of Purchasing
Organizations and Requesting Organizations are fully introduced. The Purchasing Organization is defined as where
the PO should be created. The Requesting Organization is defined as where the demand is generated. Purchase
Order creation can now be performed in one central operating unit and then received by another operating unit
where the requisition was raised. The actual order against a GPA is a Standard Purchase Order, not a Blanket
Release. One incredible benefit of the Standard PO generation is that the GPA Line is not referenced, as is the case
with a Blanket Release. If a BPA had 100 lines on it and line 57 was selected for a Release, the Release would show
Line #57 with the item number, quantity, price, etc. Many suppliers, especially those outside of manufacturing
(interpret as Indirect), have little knowledge about the release concept. Improper communications have led to more
than one supplier calling to inquire about lines 1 -56. Utilizing GPA line #57 becomes Standard PO line #1 – a much
simpler concept for many suppliers.

To summarize some of the major differences between a BPA and GPA:

· BPA orders result in Blanket Releases. GPA orders result in Standard PO’s.
· A BPA is an OU-specific source document. A GPA can be referenced by multiple OU’s.

COLLABORATE 07 Copyright © 2007 by Mike George Page 2

Using Global Purchase Agreements – A Case Study

The Company is a world leader in personal peripherals, driving innovation in PC navigation, Internet
communications, digital music, home-entertainment control, gaming and wireless devices. They had been running
Oracle Applications 11.03 for over 5 years and recently migrated to Release 11.5.10.2, adding modules such as
Advanced Supply Chain Planning, Collaborative Planning, iSupplier Portal, and several others.

A significant portion of their procurement activities involve working with Original Design Manufacturers (ODM)
located in China. While demand for the product may originate from anywhere across the globe, all sourcing and
procurement activities related to this area of business are centrally located in Hong Kong. Within the Hong Kong
organization, two distinct groups exist: one for strategic sourcing and another for order execution (sometimes
referred to as an IPO, or International Purchasing Office).

Company Organization

Suppliers
China

Strategic Tactical
Sourcing Execution

Hong Kong Office

Sales/
Distribution
Centers
Worldwide

The Company was a classic example of a very good business structure to support global sourcing and execution, yet
had been lacking the final touches from a systematic perspective.

A recently published 2006 CAPS Research study, Effective Global Sourcing and Supply for Superior Results,
established the 8 Factors related to Global Sourcing Performance listed below:

1. A defined global sourcing process

2. Centrally coordinated/centrally led decision making
3. Site-based control of operational activities
4. Information sharing with suppliers
5. Real-time communication tools
6. Availability of critical resources
7. Global sourcing and contracting systems
8. International purchasing office support

The relevancy of these findings indicates that it requires a combination of events in order to obtain excellence. The
Company had all the non-system ingredients in place to be successful; it was now time to replace an antiquated
system with one that would generate a complete and efficient solution.

COLLABORATE 07 Copyright © 2007 by Mike George Page 3

The 11.03 solution had been quite maintenance and transaction intensive. In addition to the dozens of Operating
Units in place which had been ordering and processing invoices for the same item from the same supplier, an offline
pricing database was also being maintained. The IPO had been maintaining list price at the item-organization level,
and logging into multiple responsibilities to process purchase orders. Complex inter-company customizations had
been created to handle various payments between the internal companies.

11.03 Systems Model

Supplier Price DB
China Hong Kong Pricing

AP Invoice AP Invoice AP Invoice

US Payables EU Payables Asia Payables

PO Entry PO Entry PO Entry

US Purchasing Europe Purchasing Asia Purchasing

PR Entry PR Entry PR Entry

US Planning Europe Planning Asia Planning

COLLABORATE 07 Copyright © 2007 by Mike George Page 4

Upon migrating to 11.5.10, a new, state-of-the-art systematic transaction flow was introduced, which mirrored their
organizational structure. Forty-seven (47) Operating Units had been reduced to thirteen (3 Purchasing OU’s, 7
Requesting OU’s, and 3 others). By utilizing the functionality provided by GPAs and centralized procurement,
operational efficiencies were found and various customizations eliminated. A single sourcing document was able to
be maintained and all actual purchase orders occurred in a single Operating Unit, for the given business model.

Whether The Company realized it or not, they were conforming to these exact same principles listed by CAPS
Research.
1. They had a defined sourcing process where they routinely put items out for bid at regular intervals.
2. Their sourcing organization for this particular piece of business was centrally located in Hong Kong.
3. By moving to the GPA functionality with Requesting and Purchasing OU’s, they had allowed the sites to
maintain control over operational activities.
4. Information was being shared with suppliers via iSupplier and Collaborative Planning.
5. From automatic PO transmission to iSupplier and Collaborative Planning functionality, real-time data was
within the suppliers grasp
6. Both strategic and operational roles were sufficiently staffed and located in the proper arena of
engagement.
7. Although Oracle Sourcing is under review for implementation, the results are now converted into GPAs,
with awards controlled by Source Rules.
8. The international purchasing office had been established

All in all – they had successfully met the required criteria to enable them for success in this business model, and
software had helped bridge the gap. Additional benefits that were realized:
· Multiple check runs reduced to one, with the ability for invoice netting
· Multiple points of price maintenance reduced to a single source document (GPA)
· Ability to automatically create ASL and Source Rule entries via GPA Approval workflow
· Multiple responsibilities and potential data access/security issues reduced to one
· Overall additional reductions in various other inefficient processes

11.5.10 GPA Model

Supplier HK Operating Unit

China
AP Invoice
HK Payables

PO Entry GPA
HK Purchasing HK Sourcing

PR Entry PR Entry PR Entry

US Planning Europe Planning Asia Planning

COLLABORATE 07 Copyright © 2007 by Mike George Page 5

Global Purchase Agreement Transaction Flows

The below figure represents how Centralized Purchasing works in 11.5.10 – multiple Requesting Organizations
referencing a single source document (GPA), owned by a common Purchasing Organization where the actual order
to the supplier is placed. Intercompany payments occur behind the scenes to relieve balances between the internal
organizations.

I/C AR I/C AP
Invoice Payment PR
Purchasing OU Requesting OU Requesting OU

PR
Supplier AP Payment
Requesting OU
Purchasing OU

PR
Std PO GPA
Requesting OU
Purchasing OU Purchasing OU

Receipt
Requesting Inv Orgs

Based on this model, we will take an actual transaction and reconstruct it in an 11.5.10 instance. We will address the
following topics in this section:

· Transaction Flow Summary – introduce the high-level concepts being employed

· Transaction Flow Details – review each step of the transaction
· Transaction Flow Results – observe the accounting impacts of the transaction
· Transaction Flow Setups – address the required setups that were used in the transaction example

COLLABORATE 07 Copyright © 2007 by Mike George Page 6

Transaction Flow Summary

5 5
I/C AR I/C AP
Invoice Payment
Singapore Distribution Vision Ops

4
Supplier AP Payment
Singapore Distribution
China

2 1
Std PO PR
Singapore Distribution Vision Ops

3
Receipt
M1 Inventory Org

We will begin to look at the detailed components and steps of a simulated transaction. We will be focusing on a
single Requesting Organization (Vision Operations) placing orders against a GPA owned and maintained by the
Purchasing Organization (Singapore Distributions).

1. The Purchase Requisition (PR) is created in a Requesting OU. Source Rules will default the supplier and
Purchasing OU site for the item on the requisition. Automatic Sourcing will default the GPA information,
based on that supplier/item combination on the requisition line. The PR creation can be from ASCP/MRP,
Min-Max Planning, manual entry, etc. If the PR is created via a planning system, automatic sourcing and
approval should occur during the Requisition Import process systematically.
2. Upon PR approval, the PO Create Documents workflow is automatically launched, resulting in the creation
of a Standard PO. During this workflow processing, the PO Approval workflow is automatically called,
resulting in approval and automatic transmission of the PO to the supplier. The entire PR to PO process can
and should be automated via workflow when there is no value added by a buyer. This is an inherit
efficiency when using the Procurement workflows.
3. The supplier ships the goods to the Requesting Organization, and a receipt is entered. The inventory and
balance now resides in the Requesting Org as desired.
4. The Purchasing Organization will be receiving and paying for the invoice from the supplier.
5. Inter-company transactions will be created via standard functionality. The Purchasing Org will generate an
Invoice to the Requesting Org, requiring them to pay for the order. Clearing payments/receipts can be
generated to relieve these balances.

COLLABORATE 07 Copyright © 2007 by Mike George Page 7

Transaction Flow Details

1. Transaction Data: PR Creation in the Requesting OU

Purchasing > Requisitions > Requisitions

Upon entering the item number and moving to the next block, the system automatically sources the item.
· The supplier information defaults in based on the Source Rule.
· The supplier item number defaults in based on the ASL.
· The GPA and pricing defaults in based on Automatic Document Sourcing.

COLLABORATE 07 Copyright © 2007 by Mike George Page 8

2. Transaction Data: PO Creation in the Purchasing OU
Purchasing > Autocreate

The approved requisition line resides in our Requesting OU’s requisition pool. While ideally we would have
configured workflow to automatically create and approve the purchase order, we will simulate this process using the
Autocreate form.

Select your line item(s) and click the Automatic button, followed by the Create button.

Upon successful autocreation, a note is displayed indicating document generation.

Note: Be advised the PO form will not be displayed as is typical (based on the profile option for PO:
Display the Autocreated Document = Yes). The PO resides in Singapore Distributions (Purchasing OU)
and we are logged into Vision Operations (Requesting OU). It is imperative that you log into Singapore and
manually submit the PO for approval. From a processing standpoint, this is yet another reason to configure
workflow for automatic PO creation and approval.

Some key workflow attributes for optional configuration:

PO Requisition Approval workflow: Send PO Autocreation to Background

The default setting for this attribute is ‘N’, meaning you must run the Workflow Background Processor in
order to launch the PO Create Documents workflow. Evaluate your company’s preference. For real-time
processing, the value should be set to ‘Y’. However, be advised the requisition entry form will not be
released to the user until all workflows have been completed (potential performance problems).

PO Create Documents workflow: Is Automatic Approval Allowed?

The default setting for this attribute is ‘N’, meaning that even though the PO will be created from the
approved requisition, someone must manually log into the system and submit for approval. It is typically
recommended to change this attribute to ‘Y’. Setting this value to ‘Y’ will automatically launch the PO
Approval workflow as if the buyer had submitted the PO for approval. Providing the buyer has the
authority to approve the document, it will be approved and follow whatever automatic document
transmission method you have established.

COLLABORATE 07 Copyright © 2007 by Mike George Page 9

Purchasing > Purchase Orders > Purchase Orders

The Purchase Order has been created in Singapore Distributions (Purchasing OU), maintaining the shipping
information of Vision Operations (Requesting OU). Destination accounting information is additionally displayed for
this type of order.

Note: The purchase order does not have to originate from a requisition. When manually creating a
Standard Purchase Order and navigating to the Shipments form, all inventory organizations that have the
item enabled and are included in an Intercompany Transaction Flow are available for selection.

Follow-up Note: The standard Purchasing Documents Open Interface (PDOI) fully supports importing
Standard PO’s with destination organizations in other Operating Units, as discussed in this model. Standard
validation has been included to ensure all Intercompany Transaction Flow setups have been met. This may
prove useful as the interface is commonly used for both conversion and ongoing legacy interfacing of data.

COLLABORATE 07 Copyright © 2007 by Mike George Page 10

3. Transaction Data: Receiving the PO Shipment
Purchasing > Receiving > Receipts

Receiving follows the standard procedure, with a technical twist. Manual receiving is typically centralized by
location/organization. In our example, a receiver would typically have a receiving responsibility and always select
the M1 Inventory Organization (or have his access restricted to M1 through Organization Access
restrictions/assignments).

Common receiving practice has the receiver key in the purchase order number to find the shipment for receiving,
and then continue processing the receipt. Our technical twist is that the Find Receipts form validates the Purchase
Order number against the Operating Unit found in the profile option MO: Operating Unit. This will most likely
necessitate multiple receiving responsibilities, if performing manual receipts through the forms. You will probably
need a standard receiving responsibility (tied to Vision Operations in this example) to receive M1 normal shipments
and a secondary receiving responsibility (tied to Vision Distributions in this example) to receive M1 GPA
shipments.

Note: It may prove highly useful to use intelligent PO numbering sequences in your Operating Units,
where a receiver could readily know that based on a packslip listing, which responsibility to log into.

Examples:

· Pack slip shows PO #112000654, where 112 represents Vision Operations and local purchase
orders. Receiver logs into: Receiving, Vision Operations (or shortened to Receiving – 112)

· Pack slip shows PO #455000789, where 455 represents Vision Distributions and ODM GPA
purchase orders. Receiver logs into: Receiving, Vision Distributions for Operations (or shortened
to Receiving – 455 for 112)

· Pack slip shows PO #567001435, where 567 represents a secondary OU used for centralized
purchasing, other than ODM transactions. Receiver logs into: Receiving, Contract MFG for
Operations (or shortened to Receiving – 567 for 112)

The idea is that shipments are typically centrally received and something needs to be available in order to
distinguish what responsibility is required to key the receipt, and individuals need training on what this
distinguishing factor is. Finally, if receipts are to be handled programmatically, the Receiving Open
Interface could easily handle this situation during the load process.

COLLABORATE 07 Copyright © 2007 by Mike George Page 11

The figure above shows the completion of the receiving process. A receipt has been keyed for 100 units.

4. Transaction Data: AR Intercompany Invoicing

Inventory > Reports > Intercompany Invoicing

After creating the receipt, ensure the RCV and MTL transaction managers have processed. We will now be creating
an Intercompany AR Invoice. This invoice will be created in Singapore Distributions (Purchasing OU), indicating
that Vision Operations (Requesting OU) owes them payment. The internal customer will come from the
Intercompany Transaction Flow setup.

After the concurrent program has completed, we run the Receivables AutoInvoice program (shown below) to
generate the actual invoice.

Note: It is may be feasible to create specific Intercompany transaction responsibilities, along with
including and scheduling Request Sets for transaction types such as these.

COLLABORATE 07 Copyright © 2007 by Mike George Page 12

Receivables > Interfaces > AutoInvoice

Actual AR Invoice generated

COLLABORATE 07 Copyright © 2007 by Mike George Page 13

5. Transaction Data: AP Intercompany Invoicing
Inventory > Reports > Intercompany Invoicing

Since we now have a Receivable created in Singapore Distributions (Purchasing OU), we will be generating the
Payable in Vision Operations (Requesting OU). The Create Intercompany AP Invoice process will generate an
invoice to the internal supplier defined in the Intercompany Transaction Flow setup.

Payables > Other > Requests > Run

The Expense Report Import concurrent program is used to import the invoice from the interface tables. The Payables
Open Interface Import is NOT used for Intercompany Invoicing.

COLLABORATE 07 Copyright © 2007 by Mike George Page 14

Payables > Invoices > Entry > Invoices

The resulting invoice is created in Payables and should be picked up by the standard Validation sweep program that
is typically scheduled to run at regular intervals.

COLLABORATE 07 Copyright © 2007 by Mike George Page 15

Transaction Flow Results
Three journal batches have been created in both the Vision Operations and Singapore Distribution sets of books,
reflected in the below tables. The code combinations used in setups were defined distinctly to easily identify where
and how each journal was being derived.

Vision Operations SOB (USD): PO Journal

Account Description Net Debit Net Credit
01-210-1410-0000-000 M1 RCV Inventory Acct 624.94
01-210-2210-0000-000 I/C INV Accrual 624.94

Vision Operations SOB (USD): M1 INV Journal

Account Description Net Debit Net Credit
01-000-1410-0000-000 Subinventory Material Acct 625.00
01-210-1410-0000-000 M1 RCV Inventory Acct 624.94
01-520-5210-0000-000 PPV (Currency Rounding) * 0.06
*USD to SGD: (1.53294) --- US$6.25 unit cost = SGD$9.58 x 100 units = SGD$958 / 1.53294 conversion = 624.94

Vision Operations SOB (USD): AP Journal

Account Description Net Debit Net Credit
01-210-2210-0000-000 I/C INV Accrual 624.94
01-000-2210-0000-000 AP Liability (I/C Vendor Site) 624.94

Singapore Distributions SOB (SGD): PO Journal

Account Description Net Debit Net Credit
02-550-1222-0000-000 D1 RCV Clearing Acct 919.76
02-000-2210-0000-000 AP Liability (Vendor Site) * 919.76
**USD to SGD: (1.53294) --- US$600 PO Price x 1.53294 = 919.76

Singapore Distributions SOB (SGD): D1 INV Journal

Account Description Net Debit Net Credit
02-230-4163-0000-000 I/C COGS (Logical Sale) 919.76
02-000-1410-0000-000 D1 Material Acct 919.76
02-000-1410-0000-000 D1 Material Acct (Logical Receipt) 919.76
02-550-1222-0000-000 D1 RCV Clearing Acct 919.76

Singapore Distributions SOB (SGD): AR Journal

Account Description Net Debit Net Credit
02-000-1210-0000-000 Receivable (Auto Accounting) 958.00
02-430-4110-0000-000 Revenue (Auto Accounting) 958.00

Net Results (Rounded) - Singapore shows a profit since they sold at M1 cost instead of PO Price.
Vision Operations SOB (USD)
Description Net Debit Net Credit Comments
Material Acct 625
AP Liability 625 To be cleared via I/C Clearing Payment

Singapore Distributions SOB (SGD)

Description Net Debit Net Credit Comments
COGS 920
Revenue 958
Receivables 958 To be cleared via I/C Clearing Receipt
AP Liability 920 To be cleared via actual Vendor Payment

COLLABORATE 07 Copyright © 2007 by Mike George Page 16

What IF – Pricing Options at PO instead of Transfer
Inventory > Setup > Organizations > Intercompany Transaction Flows

Receivables > Transactions > Transactions

After keying a receipt for another 100 units and running through all the Intercompany processing, a new invoice is
generated. You will notice that the IC AR Invoice is priced at PO Price and in USD. New journal results will no
longer show a profit, but rather a favorable PPV for the Requesting OU (Vision Operations).

Vision Operations SOB (USD)

Description Net Debit Net Credit Comments
Material Acct 625
AP Liability 600 To be cleared via I/C Clearing Payment
PPV 25

Singapore Distributions SOB (SGD)

Description Net Debit Net Credit Comments
COGS 920
Revenue 920
Receivables 920 To be cleared via I/C Clearing Receipt
AP Liability 920 To be cleared via actual Vendor Payment

COLLABORATE 07 Copyright © 2007 by Mike George Page 17

Transaction Flow Setups
The below figure represents the organizations that were utilized for this example and is a fairly standard
implementation model (although more requesting organizations would most likely be utilized):

Vision Organizations
Chart: Common Chart: Common
Set of Books Calendar: Common Calendar: Common
Currency: USD Currency: SGD

Legal Entities and Vision Singapore

Operating Units Operations Distribution Center

Inventory Orgs V1 – Item Master

M1 – Seattle D1 – Validation Org

1. Intercompany Transaction Flow Setups

Inventory > Setup > Organizations > Intercompany Transaction Flows

Transaction flows specify the operating units and inventory organizations involved in the financial transactions
when goods move from a source operating unit to a destination operating unit. This will be different than the
physical flow of goods (the Purchasing OU never actually receives the goods).
The transaction flow between a source and a destination identifies the chain of operating units and associated
inventory organizations involved in the costing, transfer of liability, and revenue when you ship material from a
source to a destination. You transfer liability and revenue from one OU to another using logical transactions. The
logical transaction is an accounting event without the physical movement of goods.

COLLABORATE 07 Copyright © 2007 by Mike George Page 18

 1. The Starting Operating Unit is our Purchasing Organization, or Singapore Distributions
2. The Ending Operating Unit is our Requesting Organization., or Vision Operations
3. We will be generating IC transactions utilizing a Transfer price. Our transfer price will come from an
internal price list that is used in conjunction with Advanced Pricing. We have defined an Internal Price list
that will automatically price invoices at standard cost. Transacting at PO Price will be discussed towards
the end of the transaction example.
4. We will define a single node for this transaction, indicating our Internal Customer and Internal Supplier
information.

Button: Intercompany Relations

Note: We are assuming that the prerequisite setups of Internal Price Lists and Transaction Types, Internal
Customers, and Internal Suppliers have already been defined. It may be helpful to review Intercompany
Invoicing, Chapter 14, in the Inventory User’s Guide.

2. Item Setup
Inventory > Items > Master Items / Tools

Internal Items need to be defined and enabled in all applicable inventory organizations. Based on our transaction
organizations, the item is being created in V1 (Item Master), enabled in D1 (Purchasing OU validation org), and
enabled in M1 (Requesting OU receiving org). For Intercompany Transaction purposes, the item must be stockable,
transactable, and invoiceable. We have also defined item costs in our destination organization.

COLLABORATE 07 Copyright © 2007 by Mike George Page 19

3. Global Purchase Agreement Setup
Purchasing > Purchase Orders > Purchase Orders

Upon logging into our centralized purchasing OU (Singapore Distributions), we will create a GPA.
Enter the header data and make sure to check the Global checkbox at this time. Once you have saved data, you
cannot go back and correct this if previously forgotten.

Enter your line items. This example shows only a single line item, but it may be quite practical to enter and maintain
a single GPA for all your items from a single supplier. From a Requesting Organization standpoint, only items
enabled in the destination inventory organization will be visible in the requisition entry form.

Note: If grouping multiple items on a single GPA, remember that the resulting Standard PO will pull Terms
information from the GPA. In the event you have negotiated different terms based on destination org (say DDU
for Europe and CIF for Australia), you may want to consider (besides negotiating common terms):
· Maintaining separate GPAs based on Requesting OU
· Enabling supplier site attachments where you could automatically print text on the Standard PO to
address terms (review Notes: 344888.1 and patch 5094995)
· Modify your Printed PO
· Other options

COLLABORATE 07 Copyright © 2007 by Mike George Page 20

Button: Terms

Enter your Terms information, including effectivity dates if you want workflow to automatically generate Source
Rules and Approved Supplier List (ASL) entries for you.

Save your record.

Tools > Enable Organizations

Organization enablement is where we indicate which Requesting Organizations have access to the Source
Document. You can define the Requesting Organization as the Purchasing Organization, and the future order will
result in a Standard PO issued in the Requesting OU. This type of setup provides centralized price maintenance, but
execution remains at the individual OU level, including AP processing - no Intercompany Transactions will occur.
As this paper revolves around centralized purchasing, we will set the Purchasing OU as a constant value: the
owning OU of the GPA.

Approve the GPA, selecting the Additional Options tab and Enable Automatic Sourcing in order for automatic
SR/ASL creation to occur.

COLLABORATE 07 Copyright © 2007 by Mike George Page 21

Button: Approve > Additional Options tab

Note: In the event you intended SR/ASL creation to occur, but forgot to include effectivity dates, it is possible
to still achieve this.
· You may re-query the GPA, add the effectivity dates and add an additional line item and re-approve
(current 11.5.10.2 coding is looking for a new line in order to process SR/ASL creation – re-approval
alone is not sufficient).
· You may copy the GPA into a new document, add the effectivity dates and re-approve.
· Review patch 4923689 to determine if this concurrent program is a viable option for your organization

Note: Requisition lines that reference a GPA that are being processed via the PO Create Documents workflow
do not look to the Release Generation Method on the ASL. Providing the PR line has enough information to
create the order (valid supplier, source document, and buyer), it is automatically inserted into the temp table for
creation (the Create Release concurrent program is not utilized). See the figure below.

COLLABORATE 07 Copyright © 2007 by Mike George Page 22

 PO Create Documents workflow > Verify Req Line Information

COLLABORATE 07 Copyright © 2007 by Mike George Page 23

4. Approved Supplier List Setup
Purchasing > Supply Base > Approved Supplier Lists

Via the PO Approval workflow, a Global ASL entry was created and the GPA added as a Source Document.

Note: If you set the profile option PO: Automatic Document Sourcing = ‘Yes’ (as many companies do),
the Source Document order (Sequence 1, GPA 888) is not utilized here. Setting this profile to ‘Yes’ allows
the system to automatically search for and use the most recently created and approved source document,
regardless of what data is contained on this form. The process looks for open documents in the following
order: BPAs, GPAs, and then Quotations.

COLLABORATE 07 Copyright © 2007 by Mike George Page 24

5. Source Rule and Assignment Setup
Purchasing > Supply Base > Assign Sourcing Rules

Via the PO Approval workflow, a Global Source Rule was created and an Item-level entry was made to the
Assignment Set tied to the responsibility we used to create the GPA. This Source Rule will be used to default
supplier and site information onto the requisition.

Note: By default, the profile option ‘MRP: Default Sourcing Assignment Set’ is not updateable at the
responsibility-level. You may need to modify this using Application Developer, depending upon your
individual situation. If integrating with ASCP/MRP, it is advisable that planning sessions be held to discuss
topics such as what impact an item-level assignment would have, source rule ownership/updates,
allocations, etc.

COLLABORATE 07 Copyright © 2007 by Mike George Page 25

Implementation Considerations and Challenges
Organizational Structure
· The model discussed involves having different groups of individuals for sourcing/pricing/GPA creation and
maintenance, versus the group that handles the resulting daily Standard PO (Strategic vs. Tactical). Is this a
model that your organization can embrace? While this is not required from an application point of view, it
does lend itself to what has become accepted as a best practice in the industry. Regardless of who is
performing the job functions, can your organization accept that they may not always be getting the “best
price”? Many factors are involved when moving from a local buying organization to a centralized structure.
Reduction of inefficiencies result in soft-dollar savings and the concepts of landed costs become more of a
factor than straight purchase price.

Business Model and Goals

· How complex should your implementation be? Should you take a phased approach, such as implementing a
Sourcing or iSupplier module at a later point in time, or opt for a one-time, one-shot big bang approach?
How many Requesting Operating Units will you be dealing with and how many Purchasing Operating
Units? Do you have any special revenue recognition requirements that might make you lean towards a
multi-node Intercompany Transaction Flow setup approach – perhaps leaning towards a flow-through
model for tax savings or other reasons?

Technical
· The example depicted within the paper shows manual PR creation. However, it may be highly likely that
you will be utilizing the requisition interface and import process (being fed from a planning system) to
actually create your requisitions. It is imperative that you understand what systems are loading the interface
and with what data. As an example, Min-Max will not load supplier data, yet ASCP will. All Oracle
systems that load the interface are fully supported and functional. However, there have been several issues
with how sourcing is derived during the Requisition Import process. Be prepared to request patch
application based on how data is being loaded or how sourcing is being derived.
Additionally, there have been numerous issues with context switching betweens orgs – many in the PO
Create Documents workflow while processing multiple lines. Again, be prepared for potential patch
application. These notes are for informational purposes, mainly to indicate that this solution has been
thoroughly tested, in a variety of ways, and any form of issue typically found with new functionality should
be able to be readily addressed. It is quite possible that a majority of these one-off patches have now been
included in CU3 and/or RUPs and your implementation will flow without event, providing you are on the
latest releases.

· In the event you are using the PDOI to create your GPAs, it will support it with limited functionality.
Basically, it can flag the BPA as Global. There is currently no interface support for Organization
Enablement. Either a custom script will need to be included after your upload process, or users will need to
“remember” to log in after the GPA has been created and update the document.

· It may be necessary to review any form of customized Printed Purchase Order reports you already have in
place. Ensure that you have validated any logic based on Bill-To/Ship-To, along with Terms and
Conditions, to guarantee a change in business processing will not negatively impact your legal documents.

Conclusion
Global Purchase Agreements transcend more than just the Purchasing Application, and provide the ability for a
business process model to meet a systems solution. It can be designed fairly complex, touching many modules or
remain moderately simple. Prior to implementing this functionality, ensure you have clearly defined business
requirements, goals, and are realistic about your expectations, both internal and external. Allow for intense
integration planning and testing, again with realistic timelines.
Hopefully, this paper has sparked some interest in how you may benefit from the latest software functionality
available. Perhaps you too will soon be realizing future savings in both time and money that stem from the
opportunities presented by using Global Purchase Agreements.

COLLABORATE 07 Copyright © 2007 by Mike George Page 26

About the Author
Mike George is a Senior Principal Consultant with Fujitsu Consulting. He has been dedicated to implementing
Oracle Procurement solutions for 10 years, having spent the previous 6 years engaged on the business side of
activities. He is considered one of the top Oracle Purchasing consultants in the country, with expert knowledge in
Purchasing, iProcurement, System Administration, and extensive experience in PL/SQL development and testing of
Workflows. Mike has completed all testing requirements to become one of the first individuals to obtain the Oracle
11i Supply Chain Certified Professional Consultant, Purchasing certification.
He can be reached at mike.george@us.fujitsu.com

COLLABORATE 07 Copyright © 2007 by Mike George Page 27