white paper - global procurement solutions

COLLABORATE 07 Copyright © 2007 by Mike George

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.


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.


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).

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.

Company Organization

Strategic Sourcing

Tactical Execution

Sales/ Distribution

Centers

Suppliers

Worldwide

Hong Kong Office

China


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

Hong Kong Pricing China

PR Entry

US Planning

PO Entry

US Purchasing

Price DB

PR Entry

Europe Planning

PO Entry

Europe Purchasing

PR Entry

Asia Planning

PO Entry

Asia Purchasing

AP Invoice

US Payables

AP Invoice

EU Payables

AP Invoice

Asia Payables


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

China

PR Entry

US Planning

PR Entry

Europe Planning

PR Entry

Asia Planning

PO Entry

HK Purchasing

AP Invoice

HK Payables

GPA

HK Sourcing

HK Operating Unit


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.

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

Supplier

PR

Requesting OU Std PO

Purchasing OU

AP Payment

Purchasing OU

Receipt

Requesting Inv Orgs

GPA

Purchasing OU

PR

Requesting OU

PR

Requesting OU

I/C AP Payment

Requesting OU

I/C AR Invoice

Purchasing OU


Transaction Flow Summary

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.

Supplier China

PR Vision Ops

Std PO Singapore Distribution

AP Payment Singapore Distribution

I/C AP Payment

Vision Ops

I/C AR Invoice

Singapore Distribution

Receipt M1 Inventory Org

1 2

3

4

5 5


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.


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.


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.


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.


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.


Receivables > Interfaces > AutoInvoice

Actual AR Invoice generated


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.


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.


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


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


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):

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.

Vision Organizations

Singapore Distribution Center

Vision Operations

V1 – Item Master

M1 – Seattle D1 – Validation Org

Chart: Common Calendar: Common Currency: USD

Legal Entities and Operating Units

Inventory Orgs

Set of Books

Chart: Common Calendar: Common Currency: SGD


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.


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


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.


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.


PO Create Documents workflow > Verify Req Line Information


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.


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.


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.


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 [email protected]

mailto:[email protected]

mailto:[email protected]

white paper - global procurement solutions

Documents

purchasing document

blanket release

bpa number

oracle purchasing

global item pricing

purchase order number

release number

purchase order creation