P. 1
White Paper - Global Procurement Solutions

White Paper - Global Procurement Solutions

|Views: 5|Likes:

More info:

Published by: Narasiman Velladurai on Nov 29, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/09/2015

pdf

text

original

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

driving innovation in PC navigation. established the 8 Factors related to Global Sourcing Performance listed below: 1. all sourcing and procurement activities related to this area of business are centrally located in Hong Kong. home-entertainment control. Internet communications. While demand for the product may originate from anywhere across the globe. 8. A recently published 2006 CAPS Research study.Using Global Purchase Agreements – A Case Study The Company is a world leader in personal peripherals. yet had been lacking the final touches from a systematic perspective. A significant portion of their procurement activities involve working with Original Design Manufacturers (ODM) located in China. or International Purchasing Office). it was now time to replace an antiquated system with one that would generate a complete and efficient solution. adding modules such as Advanced Supply Chain Planning.5. and several others. 4. gaming and wireless devices. COLLABORATE 07 Copyright © 2007 by Mike George Page 3 . The Company had all the non-system ingredients in place to be successful. They had been running Oracle Applications 11. two distinct groups exist: one for strategic sourcing and another for order execution (sometimes referred to as an IPO. 2. digital music. 6. iSupplier Portal.03 for over 5 years and recently migrated to Release 11.2.10. 3. 7. Company Organization Suppliers China Strategic Sourcing Hong Kong Office Tactical Execution Sales/ Distribution Centers Worldwide The Company was a classic example of a very good business structure to support global sourcing and execution. Collaborative Planning. Effective Global Sourcing and Supply for Superior Results. 5. A defined global sourcing process Centrally coordinated/centrally led decision making Site-based control of operational activities Information sharing with suppliers Real-time communication tools Availability of critical resources Global sourcing and contracting systems International purchasing office support The relevancy of these findings indicates that it requires a combination of events in order to obtain excellence. Within the Hong Kong organization.

11. 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. Complex inter-company customizations had been created to handle various payments between the internal companies.03 Systems Model Supplier China Price DB Hong Kong Pricing AP Invoice US Payables AP Invoice EU Payables AP Invoice Asia Payables PO Entry US Purchasing PO Entry Europe Purchasing PO Entry Asia Purchasing PR Entry US Planning PR Entry Europe Planning PR Entry Asia Planning COLLABORATE 07 Copyright © 2007 by Mike George Page 4 . and logging into multiple responsibilities to process purchase orders.03 solution had been quite maintenance and transaction intensive.The 11.

and software had helped bridge the gap. 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.10.5. which mirrored their organizational structure. 4. They had a defined sourcing process where they routinely put items out for bid at regular intervals. state-of-the-art systematic transaction flow was introduced. 3. they were conforming to these exact same principles listed by CAPS Research. they had allowed the sites to maintain control over operational activities. Although Oracle Sourcing is under review for implementation. real-time data was within the suppliers grasp 6.10 GPA Model Supplier China HK Operating Unit AP Invoice HK Payables PO Entry HK Purchasing GPA HK Sourcing PR Entry US Planning PR Entry Europe Planning PR Entry Asia Planning COLLABORATE 07 Copyright © 2007 by Mike George Page 5 . Their sourcing organization for this particular piece of business was centrally located in Hong Kong. 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. 7. 8. a new. By utilizing the functionality provided by GPAs and centralized procurement. and 3 others). Whether The Company realized it or not.Upon migrating to 11. Forty-seven (47) Operating Units had been reduced to thirteen (3 Purchasing OU’s. with awards controlled by Source Rules. operational efficiencies were found and various customizations eliminated. By moving to the GPA functionality with Requesting and Purchasing OU’s. Additional benefits that were realized: · Multiple check runs reduced to one. 7 Requesting OU’s. for the given business model. From automatic PO transmission to iSupplier and Collaborative Planning functionality. 5. 1. Both strategic and operational roles were sufficiently staffed and located in the proper arena of engagement. A single sourcing document was able to be maintained and all actual purchase orders occurred in a single Operating Unit. 2. the results are now converted into GPAs.5. Information was being shared with suppliers via iSupplier and Collaborative Planning.

5. Intercompany payments occur behind the scenes to relieve balances between the internal organizations. we will take an actual transaction and reconstruct it in an 11. 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 .10 instance.10 – multiple Requesting Organizations referencing a single source document (GPA). I/C AR Invoice Purchasing OU I/C AP Payment Requesting OU PR Requesting OU PR Supplier AP Payment Requesting OU Purchasing OU PR Std PO Purchasing OU GPA Purchasing OU Requesting OU Receipt Requesting Inv Orgs Based on this model.Global Purchase Agreement Transaction Flows The below figure represents how Centralized Purchasing works in 11.5. owned by a common Purchasing Organization where the actual order to the supplier is placed.

the PO Approval workflow is automatically called. 2. Source Rules will default the supplier and Purchasing OU site for the item on the requisition. This is an inherit efficiency when using the Procurement workflows. The entire PR to PO process can and should be automated via workflow when there is no value added by a buyer. Min-Max Planning. The PR creation can be from ASCP/MRP. During this workflow processing. 3. Inter-company transactions will be created via standard functionality. 1. etc. Clearing payments/receipts can be generated to relieve these balances. based on that supplier/item combination on the requisition line. The Purchasing Organization will be receiving and paying for the invoice from the supplier. Upon PR approval. resulting in approval and automatic transmission of the PO to the supplier. the PO Create Documents workflow is automatically launched. manual entry. Automatic Sourcing will default the GPA information. The Purchase Requisition (PR) is created in a Requesting OU. and a receipt is entered. If the PR is created via a planning system.Transaction Flow Summary 5 5 I/C AR Invoice Singapore Distribution I/C AP Payment Vision Ops 4 Supplier China AP Payment Singapore Distribution 2 1 Std PO Singapore Distribution PR Vision Ops 3 Receipt M1 Inventory Org We will begin to look at the detailed components and steps of a simulated transaction. COLLABORATE 07 Copyright © 2007 by Mike George Page 7 . The inventory and balance now resides in the Requesting Org as desired. 5. 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). automatic sourcing and approval should occur during the Requisition Import process systematically. The supplier ships the goods to the Requesting Organization. The Purchasing Org will generate an Invoice to the Requesting Org. 4. requiring them to pay for the order. resulting in the creation of a Standard PO.

the system automatically sources the item. · The GPA and pricing defaults in based on Automatic Document Sourcing.Transaction Flow Details 1. · The supplier information defaults in based on the Source Rule. COLLABORATE 07 Copyright © 2007 by Mike George Page 8 . Transaction Data: PR Creation in the Requesting OU Purchasing > Requisitions > Requisitions Upon entering the item number and moving to the next block. · The supplier item number defaults in based on the ASL.

Select your line item(s) and click the Automatic button. Transaction Data: PO Creation in the Purchasing OU Purchasing > Autocreate The approved requisition line resides in our Requesting OU’s requisition pool. 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). PO Create Documents workflow: Is Automatic Approval Allowed? 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. followed by the Create button. the value should be set to ‘Y’. The PO resides in Singapore Distributions (Purchasing OU) and we are logged into Vision Operations (Requesting OU). someone must manually log into the system and submit for approval. However. Setting this value to ‘Y’ will automatically launch the PO Approval workflow as if the buyer had submitted the PO for approval.2. Some key workflow attributes for optional configuration: PO Requisition Approval workflow: Send PO Autocreation to Background The default setting for this attribute is ‘N’. From a processing standpoint. this is yet another reason to configure workflow for automatic PO creation and approval. it will be approved and follow whatever automatic document transmission method you have established. COLLABORATE 07 Copyright © 2007 by Mike George Page 9 . Providing the buyer has the authority to approve the document. meaning that even though the PO will be created from the approved requisition. Upon successful autocreation. a note is displayed indicating document generation. we will simulate this process using the Autocreate form. Evaluate your company’s preference. For real-time processing. It is imperative that you log into Singapore and manually submit the PO for approval. While ideally we would have configured workflow to automatically create and approve the purchase order. It is typically recommended to change this attribute to ‘Y’. be advised the requisition entry form will not be released to the user until all workflows have been completed (potential performance problems).

This may prove useful as the interface is commonly used for both conversion and ongoing legacy interfacing of data. all inventory organizations that have the item enabled and are included in an Intercompany Transaction Flow are available for selection. Standard validation has been included to ensure all Intercompany Transaction Flow setups have been met. as discussed in this model. maintaining the shipping information of Vision Operations (Requesting OU). Follow-up Note: The standard Purchasing Documents Open Interface (PDOI) fully supports importing Standard PO’s with destination organizations in other Operating Units. Destination accounting information is additionally displayed for this type of order.Purchasing > Purchase Orders > Purchase Orders The Purchase Order has been created in Singapore Distributions (Purchasing OU). When manually creating a Standard Purchase Order and navigating to the Shipments form. COLLABORATE 07 Copyright © 2007 by Mike George Page 10 . Note: The purchase order does not have to originate from a requisition.

and individuals need training on what this distinguishing factor is. In our example. Finally.3. 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. other than ODM transactions. and then continue processing the receipt. where 112 represents Vision Operations and local purchase orders. if receipts are to be handled programmatically. Vision Operations (or shortened to Receiving – 112) Pack slip shows PO #455000789. if performing manual receipts through the forms. 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. the Receiving Open Interface could easily handle this situation during the load process. Manual receiving is typically centralized by location/organization. where 567 represents a secondary OU used for centralized purchasing. Common receiving practice has the receiver key in the purchase order number to find the shipment for receiving. Note: It may prove highly useful to use intelligent PO numbering sequences in your Operating Units. where 455 represents Vision Distributions and ODM GPA purchase orders. Transaction Data: Receiving the PO Shipment Purchasing > Receiving > Receipts Receiving follows the standard procedure. with a technical twist. 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). Examples: · Pack slip shows PO #112000654. 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. COLLABORATE 07 Copyright © 2007 by Mike George Page 11 . This will most likely necessitate multiple receiving responsibilities. Vision Distributions for Operations (or shortened to Receiving – 455 for 112) Pack slip shows PO #567001435. where a receiver could readily know that based on a packslip listing. Receiver logs into: Receiving. Receiver logs into: Receiving. which responsibility to log into. Receiver logs into: Receiving.

indicating that Vision Operations (Requesting OU) owes them payment. After the concurrent program has completed. 4. A receipt has been keyed for 100 units. Note: It is may be feasible to create specific Intercompany transaction responsibilities.The figure above shows the completion of the receiving process. COLLABORATE 07 Copyright © 2007 by Mike George Page 12 . along with including and scheduling Request Sets for transaction types such as these. This invoice will be created in Singapore Distributions (Purchasing OU). We will now be creating an Intercompany AR Invoice. we run the Receivables AutoInvoice program (shown below) to generate the actual invoice. Transaction Data: AR Intercompany Invoicing Inventory > Reports > Intercompany Invoicing After creating the receipt. ensure the RCV and MTL transaction managers have processed. The internal customer will come from the Intercompany Transaction Flow setup.

Receivables > Interfaces > AutoInvoice Actual AR Invoice generated COLLABORATE 07 Copyright © 2007 by Mike George Page 13 .

Payables > Other > Requests > Run The Expense Report Import concurrent program is used to import the invoice from the interface tables. we will be generating the Payable in Vision Operations (Requesting OU). Transaction Data: AP Intercompany Invoicing Inventory > Reports > Intercompany Invoicing Since we now have a Receivable created in Singapore Distributions (Purchasing OU). COLLABORATE 07 Copyright © 2007 by Mike George Page 14 . The Payables Open Interface Import is NOT used for Intercompany Invoicing.5. The Create Intercompany AP Invoice process will generate an invoice to the internal supplier defined in the Intercompany Transaction Flow setup.

COLLABORATE 07 Copyright © 2007 by Mike George Page 15 .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.

00 Net Results (Rounded) .06 *USD to SGD: (1.94 Vision Operations SOB (USD): M1 INV Journal Account Description Net Debit Net Credit 01-000-1410-0000-000 Subinventory Material Acct 625.76 Singapore Distributions SOB (SGD): D1 INV Journal Account Description 02-230-4163-0000-000 I/C COGS (Logical Sale) 02-000-1410-0000-000 D1 Material Acct 02-000-1410-0000-000 D1 Material Acct (Logical Receipt) 02-550-1222-0000-000 D1 RCV Clearing Acct Singapore Distributions SOB (SGD): AR Journal Account Description 02-000-1210-0000-000 Receivable (Auto Accounting) 02-430-4110-0000-000 Revenue (Auto Accounting) Net Debit 624. Vision Operations SOB (USD): PO Journal Account Description 01-210-1410-0000-000 M1 RCV Inventory Acct 01-210-2210-0000-000 I/C INV Accrual Net Debit 624.94 Net Debit 919.00 Net Credit 958.76 Net Credit 919.53294) --.58 x 100 units = SGD$958 / 1.Singapore shows a profit since they sold at M1 cost instead of PO Price.25 unit cost = SGD$9.94 Net Credit 624. reflected in the below tables.76 Net Debit 919.53294 conversion = 624.76 Net Credit 919.94 01-520-5210-0000-000 PPV (Currency Rounding) * 0.76 919.53294 = 919.76 Net Debit 958. The code combinations used in setups were defined distinctly to easily identify where and how each journal was being derived.US$600 PO Price x 1.00 01-210-1410-0000-000 M1 RCV Inventory Acct 624.94 Net Credit 624.Transaction Flow Results Three journal batches have been created in both the Vision Operations and Singapore Distribution sets of books.53294) --.94 Vision Operations SOB (USD): AP Journal Account Description 01-210-2210-0000-000 I/C INV Accrual 01-000-2210-0000-000 AP Liability (I/C Vendor Site) Singapore Distributions SOB (SGD): PO Journal Account Description 02-550-1222-0000-000 D1 RCV Clearing Acct 02-000-2210-0000-000 AP Liability (Vendor Site) * **USD to SGD: (1.76 919. Vision Operations SOB (USD) Description Net Debit Material Acct 625 AP Liability Singapore Distributions SOB (SGD) Description Net Debit COGS 920 Revenue Receivables 958 AP Liability Net Credit 625 Comments To be cleared via I/C Clearing Payment Net Credit 958 920 Comments To be cleared via I/C Clearing Receipt To be cleared via actual Vendor Payment COLLABORATE 07 Copyright © 2007 by Mike George Page 16 .US$6.

but rather a favorable PPV for the Requesting OU (Vision Operations). Vision Operations SOB (USD) Description Net Debit Material Acct 625 AP Liability PPV Singapore Distributions SOB (SGD) Description Net Debit COGS 920 Revenue Receivables 920 AP Liability Net Credit 600 25 Comments To be cleared via I/C Clearing Payment Net Credit 920 920 Comments To be cleared via I/C Clearing Receipt To be cleared via actual Vendor Payment COLLABORATE 07 Copyright © 2007 by Mike George Page 17 .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. You will notice that the IC AR Invoice is priced at PO Price and in USD. a new invoice is generated. New journal results will no longer show a profit.

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. The transaction flow between a source and a destination identifies the chain of operating units and associated inventory organizations involved in the costing. The logical transaction is an accounting event without the physical movement of goods. transfer of liability. This will be different than the physical flow of goods (the Purchasing OU never actually receives the goods). COLLABORATE 07 Copyright © 2007 by Mike George Page 18 . You transfer liability and revenue from one OU to another using logical transactions.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 Set of Books Chart: Calendar: Currency: Common Common USD Chart: Calendar: Currency: Common Common SGD Legal Entities and Operating Units Vision Operations Singapore Distribution Center Inventory Orgs V1 – Item Master M1 – Seattle D1 – Validation Org 1. and revenue when you ship material from a source to a destination.

We will define a single node for this transaction. Chapter 14. or Vision Operations We will be generating IC transactions utilizing a Transfer price. and Internal Suppliers have already been defined. enabled in D1 (Purchasing OU validation org). Our transfer price will come from an internal price list that is used in conjunction with Advanced Pricing. 4.. and enabled in M1 (Requesting OU receiving org). transactable. in the Inventory User’s Guide. Internal Customers.1. We have defined an Internal Price list that will automatically price invoices at standard cost. the item is being created in V1 (Item Master). the item must be stockable. We have also defined item costs in our destination organization. COLLABORATE 07 Copyright © 2007 by Mike George Page 19 . 3. indicating our Internal Customer and Internal Supplier information. Transacting at PO Price will be discussed towards the end of the transaction example. Item Setup Inventory > Items > Master Items / Tools Internal Items need to be defined and enabled in all applicable inventory organizations. or Singapore Distributions The Ending Operating Unit is our Requesting Organization. For Intercompany Transaction purposes. and invoiceable. Based on our transaction organizations. 2. Button: Intercompany Relations Note: We are assuming that the prerequisite setups of Internal Price Lists and Transaction Types. It may be helpful to review Intercompany Invoicing. The Starting Operating Unit is our Purchasing Organization. 2.

you cannot go back and correct this if previously forgotten.3. From a Requesting Organization standpoint. Note: If grouping multiple items on a single GPA. only items enabled in the destination inventory organization will be visible in the requisition entry form. In the event you have negotiated different terms based on destination org (say DDU for Europe and CIF for Australia). Enter the header data and make sure to check the Global checkbox at this time. This example shows only a single line item. 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. Enter your line items. Once you have saved data. but it may be quite practical to enter and maintain a single GPA for all your items from a single supplier.1 and patch 5094995) · Modify your Printed PO · Other options COLLABORATE 07 Copyright © 2007 by Mike George Page 20 . we will create a GPA. remember that the resulting Standard PO will pull Terms information from the GPA. Global Purchase Agreement Setup Purchasing > Purchase Orders > Purchase Orders Upon logging into our centralized purchasing OU (Singapore Distributions).

Save your record. and the future order will result in a Standard PO issued in the Requesting OU. Approve the GPA. As this paper revolves around centralized purchasing.Button: Terms Enter your Terms information.no Intercompany Transactions will occur. including AP processing . including effectivity dates if you want workflow to automatically generate Source Rules and Approved Supplier List (ASL) entries for you. selecting the Additional Options tab and Enable Automatic Sourcing in order for automatic SR/ASL creation to occur. Tools > Enable Organizations Organization enablement is where we indicate which Requesting Organizations have access to the Source Document. we will set the Purchasing OU as a constant value: the owning OU of the GPA. You can define the Requesting Organization as the Purchasing Organization. COLLABORATE 07 Copyright © 2007 by Mike George Page 21 . but execution remains at the individual OU level. This type of setup provides centralized price maintenance.

See the figure below. · You may copy the GPA into a new document. and buyer). but forgot to include effectivity dates.10. it is possible to still achieve this. source document. Providing the PR line has enough information to create the order (valid supplier. it is automatically inserted into the temp table for creation (the Create Release concurrent program is not utilized). add the effectivity dates and re-approve. add the effectivity dates and add an additional line item and re-approve (current 11. · 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. COLLABORATE 07 Copyright © 2007 by Mike George Page 22 .5.Button: Approve > Additional Options tab Note: In the event you intended SR/ASL creation to occur.2 coding is looking for a new line in order to process SR/ASL creation – re-approval alone is not sufficient). · You may re-query the GPA.

PO Create Documents workflow > Verify Req Line Information COLLABORATE 07 Copyright © 2007 by Mike George Page 23 .

the Source Document order (Sequence 1. Note: If you set the profile option PO: Automatic Document Sourcing = ‘Yes’ (as many companies do). COLLABORATE 07 Copyright © 2007 by Mike George Page 24 . a Global ASL entry was created and the GPA added as a Source Document. regardless of what data is contained on this form. Setting this profile to ‘Yes’ allows the system to automatically search for and use the most recently created and approved source document. The process looks for open documents in the following order: BPAs. and then Quotations. GPAs.4. GPA 888) is not utilized here. Approved Supplier List Setup Purchasing > Supply Base > Approved Supplier Lists Via the PO Approval workflow.

Source Rule and Assignment Setup Purchasing > Supply Base > Assign Sourcing Rules Via the PO Approval workflow. the profile option ‘MRP: Default Sourcing Assignment Set’ is not updateable at the responsibility-level. 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. COLLABORATE 07 Copyright © 2007 by Mike George Page 25 . You may need to modify this using Application Developer. This Source Rule will be used to default supplier and site information onto the requisition.5. allocations. Note: By default. it is advisable that planning sessions be held to discuss topics such as what impact an item-level assignment would have. etc. depending upon your individual situation. If integrating with ASCP/MRP. source rule ownership/updates.

both internal and external. versus the group that handles the resulting daily Standard PO (Strategic vs. As an example. Prior to implementing this functionality. be prepared for potential patch application. touching many modules or remain moderately simple. COLLABORATE 07 Copyright © 2007 by Mike George Page 26 . it can flag the BPA as Global. to guarantee a change in business processing will not negatively impact your legal documents. Ensure that you have validated any logic based on Bill-To/Ship-To. this paper has sparked some interest in how you may benefit from the latest software functionality available. 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. 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. Basically. Either a custom script will need to be included after your upload process. There is currently no interface support for Organization Enablement. These notes are for informational purposes. mainly to indicate that this solution has been thoroughly tested. · Conclusion Global Purchase Agreements transcend more than just the Purchasing Application. goals. 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. along with Terms and Conditions. Be prepared to request patch application based on how data is being loaded or how sourcing is being derived. Additionally.Implementation Considerations and Challenges Organizational Structure · The model discussed involves having different groups of individuals for sourcing/pricing/GPA creation and maintenance. and provide the ability for a business process model to meet a systems solution. Regardless of who is performing the job functions. Reduction of inefficiencies result in soft-dollar savings and the concepts of landed costs become more of a factor than straight purchase price. Again. However. or users will need to “remember” to log in after the GPA has been created and update the document. yet ASCP will. Tactical). Business Model and Goals · How complex should your implementation be? Should you take a phased approach. it does lend itself to what has become accepted as a best practice in the industry. Min-Max will not load supplier data. there have been several issues with how sourcing is derived during the Requisition Import process. providing you are on the latest releases. ensure you have clearly defined business requirements. Hopefully. and are realistic about your expectations. Allow for intense integration planning and testing. again with realistic timelines. there have been numerous issues with context switching betweens orgs – many in the PO Create Documents workflow while processing multiple lines. It is imperative that you understand what systems are loading the interface and with what data. and any form of issue typically found with new functionality should be able to be readily addressed. However. · In the event you are using the PDOI to create your GPAs. 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. such as implementing a Sourcing or iSupplier module at a later point in time. in a variety of ways. or opt for a one-time. All Oracle systems that load the interface are fully supported and functional. Is this a model that your organization can embrace? While this is not required from an application point of view. It can be designed fairly complex. it will support it with limited functionality. It may be necessary to review any form of customized Printed Purchase Order reports you already have in place. 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.

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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->