Beruflich Dokumente
Kultur Dokumente
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.
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.
· 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.
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
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:
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.
Supplier Price DB
China Hong Kong Pricing
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
PO Entry GPA
HK Purchasing HK Sourcing
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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 Organizations
Chart: Common Chart: Common
Set of Books Calendar: Common Calendar: Common
Currency: USD Currency: SGD
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.
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.
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
Enter your Terms information, including effectivity dates if you want workflow to automatically generate Source
Rules and Approved Supplier List (ASL) entries for you.
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.
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.
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.
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.
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.