MD050- Quarterly PO Price Updaterev2

MD.050 – FUNCTIONAL REQUIREMENTS DOCUMENT

VeriFone Inc.Quarterly PO Price Update Program

Author: Magesh Babu

Creation Date: Feb 09, 2009

Last Updated: Nov 09, 2009

Version: V1.3

Approvals:

Vincent Ong Supply Planner, Verifone Inc.

Siva Saravanan IT Manager(SCM), Verifone Inc.

Document Control

Change Record

Date Author Version

Change Reference

09-Feb-09

Magesh babu Draft New Document

12-Feb-09

Magesh babu V1.0 Modified based on Review

26-Feb-09

Magesh babu V1.1 BO Report attached

18-Mar-09

Shaik Basha V1.2 BO Report modification and User Procedure

21-Sept-09

Shaik Basha V1.3 Addendum 1(Create Concurrent Request for PO Price Update Script)

06-Nov-09

Shaik Basha V1.4 Addendum 2(Create Concurrent Request for PO Price Update Script)

Reviewers

Name Position

Siva Sravannan SCM IT MgrVincent IHQ Purchasing Business User

Distribution

Copy No.

Name Location

1 Library Master Project Library

MD050 Quarterly PO Price Update Program Introduction ii

Company Confidential - For internal use only

Contents

Introduction.................................................................................................1

Glossary.................................................................................................1

PO Price Update Project...............................................................................1

Background...........................................................................................1Business Requirements.........................................................................2Assumptions..........................................................................................2Pre Requisites........................................................................................3Proposed Solution..................................................................................4Open Issues.........................................................................................11Closed Issues.......................................................................................11Estimates.............................................................................................12Recommended Staffing.......................................................................12User Procedure....................................................................................13

Addendum………………………………………………………………………………16

MD050 Quarterly PO Price Update Program Introduction iii


Introduction

This document summarizes the business requirements for updating the GPA Number in PO Lines and for updating the Open Purchase Order line price based on New Global Purchase Agreement, created during every new quarter beginning. The solution includes use of standard features, data update script and few business process changes. It also documents the assumptions that are the basis of the work effort estimates provided.

Glossary

GPA – Global Purchase AgreementCM - Contract ManufacturerVFI - VeriFone IncIT - Information TechnologyPO – Purchase Order

PO Price Update Project

Background

VeriFone Purchasing creates New GPA for each CM for every new quarter. There are 5 contract manufacturers who supplies material to VFI, to buy material from them VFI creates GPA for each CM.

Contract Manufacturers:-

1. Wincor Nixdorf Pte Ltd.

2. Sanmina-SCI Systems Singapore Pte.Ltd

3. Inventec Apploances Corp.

4. Jabil Circuit Inc

5. Wong’s Electronics CO., Ltd

Once the new GPA is created and approved. User will manually update the GPA Number in all the Open PO Lines (PO Lines not yet received and ASN not yet created). Which will automatically update the new GPA price in the PO line and it will unpeg the consumption from Old GPA and Peg to New GPA.

For updating the New GPA number in PO lines manually, business is spending 13 hours per quarter during quarter beginning. So business wants to automate this process to avoid manual error and to make the process faster.

This project needs one update script, use of Retro Pricing standard functionality and two reports to be developed in BO or Oracle. This document covers all the requirements and proposed solution.

MD050 Quarterly PO Price Update Program Introduction 1


Business Requirements

Based on the background process of PO Price update process, the following business requirements are defined.

Current Process

“Buyer/User” needs to go through PO by PO to update the GPA Number and Quarterly Price for each PO Line per the GPA Document every quarter.

Requirement

• Mass-update of GPA Number / GPA Line# in PO Lines for all Open PO lines which satisfy the below condition:

o PO Lines pegged to "Old GPA Number”

o Approved PO

o PO Lines - Received Qty = 0 (Open PO Lines)

o No ASN loaded for the PO Lines.

• To update Price in PO Line as specified in New GPA Document.

• Updated PO of Approved Status will have the PO document in pdf format send to Buyer's email account.

• Need a two reports:

o To show Items in existing POs that meets the above conditions but doesn't exist in "New GPA#”

o To show what PO has been updated to "New GPA#” prices.

Assumptions

The Proposed solution for the requirements is based on the following assumptions:

New/Old GPA should exist and approved.

This process should be run by the Business process owner during the quarter beginning.

First Update script should be ran before running the Retro Pricing Program for the particular New GPA Number and Supplier.

Retro Pricing updates the price of all the Open PO lines based on the GPA number and GPA Line # referred to it.

If the Buyer approval limit > PO Document amount then Retro Pricing will do PO document revision and Approve the PO automatically.



If the Buyer approval limit < PO Document amount then Retro Pricing will do PO document revision and forwards the PO document based on Reporting Hierchary for Requires-ReApproval automatically.

Before requesting for update script business user should compare items of old GPA and New GPA by using BO Report1(Discrepancy B/W old/New GPA ).

Pre Requisites

The proposed solution for updating the price in PO based on New GPA requires following tasks to be completed:

New/Old GPA should be approved.

New GPA should contain all the open po items which are pegged to Old GPA, which can be verified using BO report1 (Discrepancy B/W old/New GPA.Rep).

Before running “Retroactive Price Update on Purchasing Documents program” following tasks to be completed:

Planner should request the IT to run the update script to update the Old GPA with New GPA and GPA Line#.



Proposed Solution

Process Flow

Up

da

te s

cri

pt

Val

ida

tio

n (

IT)

Re

tro

Pri

cin

g

(Bu

sin

ess

Use

r)U

pd

ate

Sc

rip

t P

roc

ess

(IT

)In

pu

t

(Bu

sin

ess

Use

r)

`

NO

1.Look for all PO which are Approved

Look for all PO lines which are 2. Pegged to old GPA Number

3. Received Qty=04.No ASN loaded for the PO Lines

Parameters 1.Old GPA#2.New GPA#

3. Buyer

Create a New GPA and Approve

1.Update all the PO lines –Ref Document# and Line#

from Old GPA# to New GPA#

2.Update Retro date to Sys date in PO lines table 3. Insert value of Old GPA#, Line# in attribute13 in PO

Lines table and PO Line Location table

Run Retro pricing program using

Supplier Name,Site,New

GPA#

System DB Trigger will automatically Unpeg the

Old GPA and Peg the New GPA

Program will update the New GPA item price in all PO Line which has New

GPA#

System will Approve the PO

If the Buyer Approval Limit > PO Document

Amount

All open po’s will get new revision and status will get changed to “Requires Re

approval”

PO Requires Re approval from

Supervisor

Yes

Yes

NO

Add items in New GPA

Run BO * * Report2,IFany Discrepancy

Run BO * Report1,IFany Discrepancy

Contact ITYes

NO

RequestITto run Update Script

Run BO *** Report2,IFany Discrepancy

Contact ITYes

NO

IT Inform Business User through email after

executed the update script in production (EBIZ)

**** Run BO Report 2 to Verify Price Update, If

any DiscrepancyContact IT

Close

Yes

NO

* Run BO Report1 (Discrepancy B/W old/New GPA.Rep) with old GPA Number, New GPA Number and Supplier Name (Last Name, First Name)

** Run BO Report2 (Before & after Retro price update.Rep) with old GPA Number and supplier Name (Last Name, First Name)

**** Run BO Report2 (Before & after Retro price update.Rep) with New GPA Number and supplier Name (Last Name, First Name)

**** Run BO Report2 (Before & after Retro price update.Rep) with New GPA Number and supplier Name (Last Name, First Name)

Step 1: Create New GPA

During every new quarter key business user creates new GPA based on existing old GPA for particular supplier and approves the new GPA.

Step 2: Run BO Report1 (Discrepancy B/W old/New GPA.Rep)

This report return all the open po line items which satisfies below conditions and has pegged to old GPA Number & doesn’t exist in new GPA for given buyer name



To show Items in existing POs that meets the below conditions and exist in Old GPA but doesn't exist in "New GPA”.

o PO Lines pegged to "Old GPA Number”

o Approved PO

o PO Lines - Received Qty = 0 (Open PO Lines)

o No ASN loaded for the PO Lines

2.1Input Parameters:

Buyer Name (Last Name, First Name), Old GPA Number and New GPA Number

2.2Output:

2.3BO Report1 Attached:

Error! Not a valid link.

2.4Discrepancy in Report1 (Discrepancy B/W old/New GPA.Rep)

Once the business user ran reprot1 and found discrepancy then items have to be added in new GPA.

Step 3: Run BO Report2 (Before & After Retro price update.Rep)

This report should be run with old GPA number and buyer name before requesting update script. Business user need to verify the PO#, PO Lines, Items etc details before requesting for an update script

This report returns all open po details including po distributions which satisfies below 4 confidtions and associated with old GPA number & buyer name.



i. PO Lines pegged to "Old GPA Number”

ii. Approved PO

iii. PO Lines - Received Qty = 0 (Open PO Lines)

iv. No ASN loaded for the PO Lines

Note:-This report should not return any rows for new GPA number before update script.

3.1Input Parameters

Old GPA Number and Buyer Name (Last Name, First Name)

3.2Output

3.3BO Report2 Attached:

Error! Not a valid link.

3.4Discrepancy in Reprot2 (Before & After Retro price update details for GPA.Rep)

Once the business user ran reprot2 and found discrepancy/issues then he has to contact IT to resolve discrepancy/issue.

Before requesting for update script, business user should verify the items using BO Report2 (Before & after Retro price update details for GPA.Rep) and decide to go for update script or not.

Step4: Request IT to run update script



Once new GPA is approved, Business user submits an IT Request with the following Input parameters to update Old GPA Number with New GPA Number and old GPA Line Number with new GPA Line number for Specific Buyer for all open PO lines.

Old GPA Number

New GPA Number

Buyer Name (Last Name, First Name)

4.1IT will run an update script using DCC which updates:-

• Update script stores the old GPA number and line number in DFF-Attribute13 of PO lines table,PO line location table for all open po’s which satisfies bellow conditions?

• Old GPA# with New GPA# and Old GPA Line Number with New GPA Line Number.

• Also update the Retrodate = Sysdate in PO_Lines_All table for New GPA number (Purpose for updating the RetroDate in new GPA: Retro Pricing Program will consider only if the new GPA lines have retro date)

For all the PO Lines which satisfies all the below conditions:

• PO Lines pegged to "Old GPA Number”

• Approved PO

• PO Lines - Received Qty = 0 (Open PO Lines)

• No ASN loaded for the PO Lines.

4.2Input Parameters:

Old GPA Number

New GPA Number

Buyer Name

4.3Validations:

Old GPA and New GPA should Exist & Approved

Old/New GPA type = “Blanket Purchase Agreement”

Global Agreement Flag=’Y’

4.4Exceptions:

DBMS_OUTPUT.PUT_LINE ('Old GPA not approved: '||l_old_gpa_approved); DBMS_OUTPUT.PUT_LINE ('New GPA not approved: '||l_new_gpa_approved);



Step5: IT inform business user through email after executed the update script in production (EBIZ)

Step6: Run BO Report2 (Before & After Retro price update.Rep)

o This report should be run with new GPA number and buyer name after update script and before retro price update program.

o This report returns all open po details including po distributions which were newly associated with new GPA number

o This report should not return any rows for old GPA number after update script

6.1Input Parameter

New GPA Number

Buyer Name

6.2 Discrepancy in Reprot2 (Before & After Retro price update details for GPA.Rep)

Once the business user ran reprot2 and found discrepancy/issues then he has to contact IT to resolve discrepancy/issue.

Step 7: Check pegging and unpegging for open po lines

Note: System automatically does pegging and unpegging for open po lines while executing update script, no need of any action by user.

While updating the Old GPA# with New GPA#, Database trigger will automatically triggers the updation of Unpegging the PO Line Qty from Old GPA and Peg the PO Line Qty to New GPA.

Step 8: Run retro price program

Once the above steps are performed successfully and then Business user should run the “Retroactive Price Update on Purchasing Documents program” in Purchasing Responsibility for the specific Supplier, Site and New GPA Number.

8.1What is retro price program?

Prices for items on blanket agreements can change over the effective period of an agreement as a result of ongoing negotiations between the buyer and the supplier. In fact, it is common practice in certain industries to initiate and execute against an agreement with an interim price. A firm price may get finalized several months into the life of the agreement. In these scenarios it is possible that the updated price is applicable retroactively. Oracle Purchasing allows buyers to make price changes on global blanket agreements and on blanket agreements.



With 11.5.10, Oracle Purchasing can optionally update prices on orders (Blanket Releases & Standard POs) to reflect the latest agreement price.

8.2Profile Option Setup

Note: VeriFone already set this profile option to “OPEN RELEASES” at Site Level. So, no need to change any setup.

User Profile Name: ‘PO: Allow Retroactive Pricing of Pos’

Profile Option Name: PO_ALLOW_RETROPRICING_OF_PO

Possible Values for the Profile option: blank, ‘Never’, ‘Open Releases’, ‘All Releases’

Profile option 'PO: Allow Retroactive Pricing of POs' must be set to determine if blanket releases and standard purchase orders can be mass updated with retroactive price change(s) entered on their corresponding Blanket Agreement. If this profile is not set or is set to ‘Never’, the 'Retroactive Price Update of Purchasing Documents' concurrent program will not update any Releases/Standard POs.

8.3 Archive Mode

In the Document Types Form, the ‘Archive on’ for Standard POs and Releases must be set to 'Approve'.

If the profile option ‘PO: Allow Retroactive Pricing of Pos’ is set to 'All Releases', then retroactive pricing will be performed on all releases, if the archive mode for that operating unit is set to Approve.

Navigation:

Purchasing Responsibility

Setup > Purchasing > Document Types

8.4 Methods of updating the Retroactive Pricing

Once the Blanket Agreement line has been updated with a new price, the Retroactive Price Update process will update the associated Blanket Releases with the new price.



If the Global Blanket Agreement line has been updated with a new price, then Retroactive Price Update process will update the associated Standard Purchase Order with the new price.

8.5 Input:

The “Retroactive Price Update on Purchasing Documents program” will have the following parameters:

Note: We advise to run the retro program only by with the below parameters

Supplier Name

Supplier Site

New GPA Number

Supplier (Required)

Enter or select the supplier whose pricing needs to be updated. Thismust be a supplier that is currently in the system.

Supplier Site (Optional)

Enter or select the supplier site.

Blanket Agreement Number (Optional) = New GPA Number

Enter a specific blanket agreement number for which you want thepricing updated.

Item Range (Optional)

Enter a range of item numbers for which you want the pricing updated.



Category Range (Optional)

Enter a range of categories for which you want the pricing updated.

Date From (Optional)

Specify a date to identify releases or standard purchase orders to beupdated. The release shipment need–by date should be on or after thespecified date. If need–by date is not available, the release shipmentcreation date will be used.

Communicate Updates (Optional)

Yes or No

8.6 Output

Updated PO of Approved Status will have the PO document in pdf format send to Buyer's email account.

Step 9: Audit (to verify the price update for New GPA open po’s)

Once the Retro price update program completed normal, business user should verify the price update for new GPA open po’s by using BO Report2 (Before & after Retro price update details for GPA.Rep) with New GPA Number and supplier Name (Last Name, First Name).

9.1 Discrepancy in Report2 (Before & After Retro price update.Rep)

If any discrepancy in po price then business user has to contact IT to resolve issue.

.

Open Issues

Closed Issues

1. If the GPA is not in Approval Status (In Progress), what would be the expected behaviors when running the Update Script or Retroactive Price Update on Purchasing Documents program?

Ans) Retro pricing program GPA number parameter LOV will not populate the “In-Progress” GPA number, only approved GPA number can be selected

2. I just want to emphasize that the Specific Buyer when update Old GPA Number with New GPA Number and GPA Line Number in specific Purchasing Org for all open PO lines is based on the "Buyer" as found in the PO. Please see attached Buyer.xls



Ans) Yes, our update script will work as you described

3. When the PO Lines Pegged to GPA "A" with no price different, running Retroactive Price Update on Purchasing Documents program on GPA "A" will not "reupdate" the Price and send it through the Approval loop.

Ans) NO

4. What is the function on the Communicate Update in Retroactive Price Update on Purchasing Documents program?

Ans) indicate if you want the updated releases or purchase orders to be communicated to the supplier. If communicate=Yes the updated document will be communicate to the supplier. The communication method is determined by the Supplier Notification Method setting of the supplier site.

5. I am interested in the Category in the Retroactive Price Update on Purchasing Documents program. What type of Category is this referring to? Purchasing Category?

Ans) Yes it is referring Purchasing category, we advice to run the retro program only by the below parameters.

• Supplier Name• Supplier Site• New GPA

Estimates

Recommended Staffing

The table below represents the maximum number of resources assigned to each development task.

Development Task Functional Technical

Create Functional Design

Create Technical Design

Perform Development

Develop Unit Test Scripts

Develop Regression/Integration Test Scripts

Perform Unit Tests

Perform Regression/Integration Tests

Create ERR Doc, PVCS folders and Check-in files



User Procedure

Step1: Create new GPA (will be created by the business user)

Step2: Run BO Report1 (Discrepancy B/W old/New GPA.Rep) with the following parameters

1. Old GPA Number

2. New GPA Number

3. Buyer Name

Sample Input

Sample Output

Note: This report should not return any records in good case; if it returns then business user needs to be correct the new GPA.

Step3: Run BO Report2 (Before & after Retro price update) with the following parameters

1. Old/New GPA Number

2. Buyer Name

Sample Input

Quarterly PO Price Update Programdocument.doc 13Company Confidential - For internal use only

Sample Output

Note1: This report should be run with old GPA number and buyer name before requesting update script. Business user need to verify the PO#, PO Line, Items etc details before for update script

Note2: This report returns all open po details including po distributions which were associated with old GPA number and buyer name.

Note3: This report should not return any rows for new GPA number before update script.

Step4: Request IT to run update script with the following parameters

1. Old GPA Number

2. New GPA Number

3. Buyer Name

Sample Input

Step5: IT creates a DCC to run update script.

Step6: IT inform business user through email after executed the update script in Production (EBIZ)

Step7: Run BO Report2 ((Before & after Retro price update) with following parameters



1. New GPA Number

2. Buyer Name

Note1: This report should be run with new GPA number and buyer name after update script

Note2: This report returns all open po details including po distributions which were newly associated with new GPA number

Note3: This report should not return any rows for old GPA number after update script.

Step8: Check pegging and unpegging for open po lines

Step9: Run retro price program with the following parameters

Note: We advise to run the retro program only by the below parameters

1. Supplier Name

2. Supplier Site

3. New GPA Number.

Sample Input



Step11: Run BO Report2 ((Before & after Retro price update) with following parameters to verify price update for all the associated open po lines

1. New GPA Number

2. Buyer Name

Addendum1: Create Concurrent Request for PO Price Update Script

Requirement: VeriFone business wants to avoid DCC execution process for an update script.

VeriFone business has been spending 3 to 4 hours for each DCC execution for every quarter, during this process, business need to verify/validate the date accuracy before request for each DCC execution.

Proposed Solution: Create concurrent request to avoid DCC execution process.

Concurrent Request Name: XXVFI: Quarterly PO Price Update.

Input Parameters: Old GPA Number, New GPA Number and Buyer Name.

In Scope: Concurrent request should be available under IHQ purchasing responsibility only.

Developer Details:

1. All the input parameters should be LOV type.

2. All the approved GPAs should be listed in LOV to select.

3. Active buyer names should be listed in LOV to select.

Note: For testing purpose, create concurrent request under IHQ purchasing super user, till we confirm appropriate responsibility from business user.

Latest Update Script:



Addendum2: Update Script Mondification.

Requirement: VFI Business user wants to update duplicate items when one of the items in cancelled status.

Proposed Solution: Modify update script.

As per the VFI business user (Vincent) request the following condition has been incorporated in the update script.

If the items are duplicated and cancelled flag=’N’ then curser shouldn’t update any of the duplicated items, in other words, curser should come out from the loop and it should populate message “Item xxxx Duplicated in new GPA”.

And

If the items are duplicated and cancelled flag=’Y’ then curser should update one of the items.

