PO Implementation

Conception document

07/17/2019
Sommaire
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix
1 – General conception approach

Goals of this step

Define the functional adequacy between

the needs and Oracle functionalities

Identify the gaps: developments to

realize, organizational impacts

Analyze the wanted reporting list,

prioritize them and identify the target
tool

Define and validate the functional &

applicative architecture of the project

This document is the result of the 10 workshops of the general conception taken place from the 25th of April to the 27th of June
3
1 – Project’s context and main stakes

Procurement is basically a matter of harmoniously orchestrating 7 processes

And of course, each process has plenty of sub-processes…

So it is not that simple to buy stuff!
4
1 – Project’s context and main stakes

Always the same questions…

Always the same answers…

. . .

So we need a little bit more processes and a tool!

5
1 – Focus on P2P

Increase data quality and validation workflow with direct impact on accounting department to ease the invoice validation chasing
job!

6
1 – Project’s context and main stakes
EDENRED Group created the Group Purchasing Department at the end of 2017 with the following objectives

• To acculturate entities to the best purchasing practices

• To harmonize and coordinate practices and policies within the Group
• To monitor and better control expenditures

The Group Purchasing Department is growing in terms of skills, team sizing and organization but still suffers from the lake o f
IT purchasing tools
• To monitor and analyze spends
• To sustain the P2P process (except from a « light » PO implemented in Mexico)

As such, it has decided as a priority to launch the implementation of a P2P tool

• To deploy best practices all along the value-chain of the P2P process
• To allow buyers to be involved in the process, provide more added-value and better monitor spends

 In terms of IT Tool, the Group Purchasing Department has chosen Oracle modules PO & E-procurement in order to benefit from SAXO
ongoing roll out 7
1 – Scope
Pilots
 HQ IT Department: P2P good maturity, high volume of spends
 Mexico: already uses oracle PO
 Both are enough representatives of the Group to conceive a global solution

General P2P process

Purchase requisition PR approval RFQ/RFP Purchase Order and Send PO

approval

Receiving

Before invoicing

After invoicing

PO/invoice matching

Payment Invoice validation

Departments and entities & Buyer Departments and entities Accounting department
Buyer

8
1 – Convention

This document resumes all the themes in the general conception phase and the last decisions taken by the work group

Taken decision

Action to do

Open point

Bespoke

9
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

10
2 – Supplier repository structure
The supplier master data is in Oracle
A supplier is used in a PO or in an Invoice and has to be defined at 3 levels:

1
Header
Stores general information such as supplier name, supplier number, Fiscal ID, classification, etc.
This repository is shared at instance level: all the entities who use SAXO can see the supplier

• Fiscal ID : used to identify the unicity of a supplier • Classification:

• The product and service tab is used to categorize the type and goods that each
HQ • SIREN number - if it already exists, the system alerts you and you supplier can provide. The tab is used when supplier portal is installed
just have to complete the info
• Purchasing categorization is not automatically linked to the supplier and the
Mexico • Tax ID functionality of feeding the purchasing categorization when filling a PR or a PO is
not standard neither

• Purchasing department wants to use a unique international identification using BVD numbering
• There are 2 possibilities for the identification field:
• Put the BVD ID in the DUNS field and rename DUNS field by BVD ID
• Create a new Descriptive Flex Field (DFF); in this case, no research in the Oracle forms using this field is possible but can be used in specific reporting

Create a new DFF since some entities use the DUNS field

11
2 – Supplier repository structure
2 3
Address Site

Stores supplier’s addresses and type (purchasing or payment) Stores information defaulted from supplier headers and address that can be
changed (bank account for instance)

• Defined at operating unit level: to be able to use a site in a PO or an

invoice, the address has to be linked to the operating unit concerned
• Banking details: no document attachment possible in this tab

Check why the tax registration number is not mandatory yet

Check in the additional information frame (DFF), the hidden fields to see if there are some useful ones (limited number of fields in this frame)

No extra information needed

Categorization in the PO only & not at supplier level

12
 Start Accounting Non system
2 – Supplier creation End
department action
Requester
process Decision Purchasing
department System action
Bespoke

Need to buy something using No Fill in the supplier creation form and
iProc 1
a non catalog request send it to the purchasing department
Yes

Purchase requisition
processs

1 No
Check the supplier form et and
Create a purchasing contract Create the supplier and inform the Yes
PO and inform the requester purchasing department
2 transfer it to the accounting
department

1 Does the supplier exist?

1 Contract PO creation
2 Is the supplier form OK?

Contract PO creation (Gap document 7)

• Autocreate the PO contract systematically when a supplier is created

How to manage the contracts data transfer?

13
2 – Supplier creation process
Contract PO creation (Gap document 7)

Each time a supplier and his site This creation can be done through the Each day, an interface can be
(defined as a purchasing one) are PO agreement interface automatically launched and:
created, a purchase contract agreement  Identify new supplier
has to be created and approved in order  Identify new purchasing site
to be available in iProcurement (linked to the new supplier
mentioned above)
in order to create and approved
purchase contract agreement for the
operating unit linked to the supplier
site

How to specify the buyer of the contract? Constant of the interface? Descriptive Flex Field on the operating unit?

14
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

15
3 – Purchasing segmentation structure
Purchasing category is used for Purchasing category structure

The structure is shared at the instance level so EDENRED has defined

Social account the same structure in 3 segments
Spend analysis Buyers assignment
determination

Segment Family Class

Impacts on Mexico implementation

 For Mexico, the purchasing segmentation has a 2-segment structure

 If we do not change the structure for Mexico’s PO, when looking for a previous PO, there is a warning message and you cannot see the lines
 EDENRED has to migrate all the data from Mexico
 Basic solution for instance: N/A for the 3rd segment and they just keep their way or they define a new mapping between the old and the new PO

Purchasing segmentation structure divided into 3 segments: Segment/family/class

• For Mexico, define for old PO a segmentation that matches the new one: for instance, define for each segment which key
corresponds to the new one
• At Go live, if no match has been defined, the third segment will be filled up with « N/A » 16
3 – Catalog structure
Catalog data consists of items and services available for purchase
Every good or service must belong to a purchasing category
The catalog is structured as a combination of categories and hierarchy
 The catalog structure is the same for the whole instance
 Shopping categories are used to group similar goods or services for presentation for the iProcurement users
 Shopping categories are found at the lowest level of the hierarchy and are linked to a purchasing category
 Intermediate level shopping categories are used to define the category hierarchy and help requesters to browse to the items

PO purchasing category iProc shopping category

Servers Servers
Hardware

Hardware Accessories Accessories IT

IT

Software Public cloud Public cloud Cloud

Com Media

Define the iProc and PO catalogs in a mirror way (the mapping is done by the administration)
17
3 – Loading catalog content
There are two ways to load the catalog content:
 Real time loading from blanket purchase order and PR template
 Punch out from external suppliers

Punch out
Blanket order
PO iProc
PR template

No punch out

18
3 – Agreements Start Non system
action
End

Blanket order: Buyer System action

 A BO represents an agreement with fixed prices and discounts with a supplier
 It is the main source of the iProc catalog

Need to create a Self approve the

PO blanket order
Enter the blanket order
blanket order

iProc Available on iProc

 There is a header with lines for the blanket agreement (catalog)

 One catalog line of a blanket agreement is linked to one category
 The blanket agreement has to be entered and maintained internally by EDENRED
 It is possible to attach some documents
 It is possible to share the blanket agreement with other operating units
19
3 – Agreements
Contract:
 A contract represents a global agreement with a supplier without details on the negotiated items
 When contract exists for a supplier, the PO can be automatically created from the PR
Start
Non system
End action
1
Buyer
Need to create a Self approve the System action
PO contract
Enter the contract
contract Bespoke

iProc Available on iProc

1 Contract PO creation

 There is just a header without lines for the contract agreement (non catalog)
 It is possible to attach some documents
 It is possible to share the contract agreement with other operating units

Contract PO creation (Gap document 7)

• Autocreate the PO contract systematically when a supplier is created 20
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

21
 Start Non system
4 – Purchase requisition approval End
Requester
action

process Decision
Superior
System action
Requisition general process: Open points Bespoke

No Create a non catalog Yes Supplier creation

Need to buy something Search in the catalog 1 2 process
request

Yes No

1
Add it to the shopping Approve the
Submit for approval
cart requisition
iProc

3
PO

1 Does an item exist in the catalog? 1 Account generator customization

2 Do I have a supplier?
PR validation module AME or PO
3 From an approved PR to an approved PO process Requisition approval person
22
4 – Purchase requisition approval process

PR approval is based on the employee supervisor hierarchy with only one level of approval (eg. N+1 has full right to approve the PR whatever the
amount)

Account generator customization (Gap document 3)

• Automatically generate the account assignment lines of purchasing requisitions
• Business rules described in the next slides

Everyone has access to all the purchase requisitions and all the purchase orders of the entity or everyone has only access to his own purchase
requisitions and his own purchase orders

23
4 – Purchase requisition account generator
 All purchase orders, requisitions and releases require accounting distributions. Oracle purchasing automatically builds a charge, budget (if
using budgetary control), accrual and variance accounts for each document distribution

Accounting key:
 The accounting key is only generated once in the whole process. There are two ways to change it:
• Manually
• By removing the line and recreating a new line

24
4 – Purchase requisition account generator
Charge account rules
Expense Asset

Entité Defaulted from employee charge account Defaulted from employee charge account

Compte Defaulted from purchasing category Constant 475100 (to be confirmed)

From DFF on catalog line otherwise purchasing category otherwise

Département analytique Specific constant for asset
employee charge account
Flux Constant – To be defined Specific constant for asset

Solution DFF on PR otherwise defaulted from employee charge account Non significant constant – To be defined

Nature écriture Constant L Constant L

Partenaire Defaulted from supplier key Defaulted from supplier key

Projet DFF on PR otherwise defaulted from amployee charge account Defaulted constant but can be modified

Millésime Non significant constant defaulted from employee charge account Non significant constant defaulted from employee charge account

Spare Blank Blank

Spare Blank Blank

Spare Blank Blank

Add DFF at the purchase requisition level for « solution », « project » and for CAPEX (to mention if it is an expense or an asset)
25
4 – Purchase requisition account generator
Accrual account rules
Entité Defaulted from accrual account of the operating unit

Compte Specific accounts for ITEC, partners (internal) & others

Département analytique Non significant constant defaulted from accrual account of the operating unit

Flux Non significant constant defaulted from accrual account of the operating unit

Solution Non significant constant defaulted from accrual account of the operating unit

Nature écriture Constant L defaulted from accrual account of the operating unit

Partenaire Defaulted from supplier

Projet Non significant constant defaulted from accrual account of the operating unit

Millésime Non significant constant defaulted from accrual account of the operating unit

Spare Blank

Spare Blank

Spare Blank

For « Compte », 2 possibilities: either by a DFF at the supplier site level or at the « Partenaire » level with a DFF

Provide a mapping table between purchasing categories and accrual & social accounts 26
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

27
5 – Purchase order approval process Start Requester’s
superior Buyer
End
Superior’s
Yes Decision superior
3 System action
1
No Yes 4
No Bespoke
1 2 3 Auto create the PO The system

No Yes

2
Create the PO Yes
Approve the PO 5 Approve the PO
manually
No
PO
4

Generate the PO Send PO form to the Receiving

form supplier process
From a need to an approved PR process
1
The PR is assigned to a buyer, according to the category

2 Is it a request from a catalog?

1 Buyer assignment
3 Is there an existing contract?
Account generator customization
2
Is the amount of the PR superior to a threshold? (same rules but different workflow)
4
The threshold can be set up for each operating unit
3 Autocreation workflow from a PR to a PO

5 Is the amount of the PO superior to the approver rights? 4 PO form 28

5 – Purchase order approval process
To manage PO approval workflow based on the requester’s hierarchy, one order must be related to a unique purchase requisition but one
purchase requisition can generate several orders

Each operating unit will assign a local buyer for the PR whatever the origin of the item

Managing minimum order amount in Blanket Order line is useful when grouping several requisitions, in Edenred context (one order for one
requisition) this functionnality should not be used

In the validation process, everyone should approve, in a sequential validation way with a hierarchical approval:
• The orders validation path is based on the requester’s hierarchy and not on the buyer’s one
• The validation is done sequentially, the superiors have the approval rights one after another
• Everyone in the workflow can forward the request to someone else for approval
• While approving the PO, the buyer can add a decision-maker to approve

Check how to add someone in the validation process

Modify the employee interface to manage a new field « Function ». This field is used for the PO approval workflow

29
5 – Purchase order approval process
Buyer assignment (Gap document 4)
EDENRED wishes to assign requisitions lines to buyers in order to ensure a dispatching according to buyer scope and operating unit

Operating unit Category Buyer

Account generator customization (Gap document 3)

• Automatically generate the account assignment lines of purchasing requisitions
• Business rules described in the next slides
This bespoke is not presented in the following slides (already presented before, cf. slides 25-26)

Autocreation workflow from a PR to a PO (Gap document 1)

EDENRED wishes to automate some order creations according to criteria.
The different management cases identified are:
• PR on catalog (blanket order)
• PR on contract with predefined threshold

PO form (Gap document 2)

• Edited from the XML standard and adapted according to EDENRED needs

Use the same assignment matrix to add the charge and accrual accounts for each purchasing category?

30
5 – Purchase order approval process
Buyer assignment (Gap document 4)

Case 1 – PR lines sourced on a blanket PO (i.e. catalog) Case 2 – PR without blanket PO source

• In this case, a standard PO will be automatically created. Nevertheless, a • To determine the right buyer on a PR line, we have to take into
buyer must be identified on the PR lines because it will be the one defined account different information: operating unit, purchasing
in the buyer field of the standard PO category and the buyer
• This buyer has to be the one defined on the blanket PO whatever the • To build this logic, a mapping table has to be created and
operating unit linked to the standard PO. Indeed, a blanket PO can be could be an Oracle key based on 3 segments:
multi operating unit whereas a standard PO is attached to a unique
operating unit
=> This is the standard feature Operating unit Category Buyer

 Consequently, for each purchase requisition line on an operating unit, we are able to identify the buyer assigned to the purchasing category and send the PR
line to him

Buyer assignment to purchase requisition

• Define a dashboard in which an operating unit & category couple is assigned to a unique buyer with the following layout (i.e define a
buyer for each line of the segmentation):
Operating unit Category Buyer

31
5 – Purchase order approval process
Autocreation workflow from a PR to a PO (Gap document 1)

The autocreation of PO happens in two cases for EDENRED

Case 1 Case 2
Catalog request Non catalog request

• Standard feature: • Bespoke:

Non catalog request, the supplier of the purchase requisition has an existing
The purchase requisition is from a catalog (= blanket order). In this case, contract (= contract agreement) and the amount of the request is inferior to a
the PR is automatically transformed into a PO and the related PO is sent to
the approval process. defined threshold (this threshold can be set up by operating unit). In this case, the
PR is automatically transformed into a PO and the related PO is sent to the approval
process.

 Once the order is created, the approval workflow must be launched immediately afterwards. To launch it automatically, the attribute of the “PO Create
Documents” “Automatic approval allowed” must be set to “yes”

Note: The PO must be manually created by the assigned buyer in the following cases:
• The request is not from a catalog and there is no existing contract
• The request is not from a catalog, has an existing contract but the amount is superior to the defined threshold

32
5 – Purchase order approval process
PO form (Gap document 2)

The suggested solutions are illustrated by a new template of the PO form and the business rules described below:
 The implemented languages are: Spanish, French and English

 ”Order”: concatenate the order number and version number with "-" as a separator: XX - version

 "Contract": if all the lines are attached to the same contract or blanket order
• The field is feeded by the contract/blanket order description field which contains the EDENRED references of the concluded contracts with the supplier
• If there are several contracts/blanket orders referencing the order lines: display ”Several”, the contract numbers will then be displayed on the line

 "Delivery"/"Invoicing":
• Display all the address fields when they are filled
• For delivery locations, display at the end, the opening hours in the location DFF which will be created
• If there are at least 2 different delivery locations, display “Multiple” (standard feature)

Note: For invoicing sites, we could enter, at the address level, "Supplier Accounting Department" as the recipient so that the invoices will be sent directly to
the right department
This involves creating a delivery address and an invoicing address
33
5 – Purchase order approval process
PO form (Gap document 2)

 ”Payment condition” and ”Incoterm” (changed instead of “FOB”): display the description and not the code
 ”Reference”/”Description”: change the label to ”Designation”, not bold, same font size as the notes text
 Provided ”Date”/ ”Time”: display date without hours, delete ”Need” text. If there are several delivery lines with different dates, display ”Multiple”
 ”Contract”: display this field only if several contracts are referenced on the order lines. If there is only one contract, this one is displayed at the
header
• Feed the field by the contract description referenced by the line
 Line supplier note: display this field only if a supplier note is referenced at the line level
 Add a three-column table showing the different delivery locations of the lines with the following columns for the delivery code block:
Opening hours:
Delivery code Address
DFF
• If only one Delivery location is used in the PO, this block should not be displayed
 Add a table showing the contact’s information: name, phone number, requester’s email for the requester block
 The legal information of the footer come from the ”Legal entity” associated to the operating unit of the order: TBD

Create a DFF in the location for the opening hours of the delivery location

Define the legal information of the footer 34

5 – Microsoft zoom for local needs HQ action
System action
Local action
System action

Specific process for Microsoft purchases: HQ action Local action

 Operational Unit (OU) ≠ HQ Non system action Non system action

PR on ITEC internal catalog Approve PR Create PO Approve PO Send PO to global buyer

Supplier process

Enter PO on Microsoft catalog Approve PO Send PO to Insight PO receipts Microsoft invoicing for HQ Payment process

Customer process

Communicate license
ITEC invoicing for OU ITEC PO receipt Input ITEC invoices Pay invoices to HQ End
number

Local requester HQ buyer Start

Local requester’s HQ buyer

End
superior superior

Local accountant HQ accountant Automatic 35

5 – Microsoft zoom for HQ needs HQ requester Start

HQ requester’s
End
Specific process for Microsoft purchases: superior
 Operational Unit = HQ
HQ accountant

PR on Microsoft Microsoft
Approve PR Create PO Approve PO PO Receipt
catalog invoicing

• For each country, the cost center is the cost center of ITEC and not the cost center of the requester

Who creates the order?

If you want to differentiate which software belongs to ITEC cost center and which one does not, a very thin level is required and has to be
defined

36
5 – Dell zoom
Specific process for DELL purchases:
 As it is not possible to get the real prices of the items with all their options, a DELL catalog is available with indicative prices for PR
 No contract nor blanket order should be created for DELL to avoid the automatic creation of the PO from the PR
 A PR template is used to load the catalog content

Requester Buyer
Start

End Requester’s
superior System action

1
Quote the PR on DELL
PR on catalog Approve PR Create PO manually Approve PO
website

1 The buyer goes to DELL website to do a quotation with the real prices

37
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

38
6 – Receiving process

Receipt is done by the requesters in iProcurement

 During the invoicing matching process, the receipt allows the invoice to be validated and paid

Entering a receipt for IT services in iProcurement will represent a double input with the project management software

Do an ‘Express receive’ for Microsoft and Oracle licenses

Define the access security level. In standard, either the requester can receive his own orders or he can receive eveyone’s orders

39
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

40
7 – PO/invoice matching
Principle

 The creation of an invoice for a matching with a PO will change the mode of input:
Without PO With PO

Supplier PO number (supplier, site)

Site Invoice number

Invoice number Invoice date

Invoice date Invoice amount

Invoice amount Match PO line

Lines (amount, description, accounting key)

 The supplier and the site will be automatically defaulted from the PO form
 The PO/invoice matching is done at the line level by indicating the amount or the requested quantity. This creates an invoice and a
distribution line that carries the accounting key. This accounting key can be modified but not ventilated

41
7 – PO/invoice matching
Principle

 Currently, for IT services invoice, the accountant splits the invoice distribution line into several analytical distributions based on a document
provided by IT controlling
 In invoice matching process, it is not possible to ventilate on several different accounting keys. In the case of an analytical ventilation, it is
necessary to do several matchings, one for each key
 Before go live, to be able to use the PO/invoice matching, EDENRED should inform the suppliers that they must display the reference of the
order on their invoices. To do so:
• Communicate with the concerned suppliers
• Indicate a default text on the PO form such as “Reference of the PO form to remind on the invoice under penalty of rejection of this last one”

Do the ventilation in the described way

Define the exact default text on the PO form and validate it by the lawyers

42
7 – PO/invoice matching

Receipt Accounting - Expense Period-End Accruals

Charge account of the PO Accrual account of the PO

Debit Credit Debit Credit

(1) - Receipt (1) - Receipt
(2) - Period End 100 (2) - Period End 100
(3) - Open Next Periods 100 (3) - Open Next Periods 100
(4) - Invoice matching 100

Supplier account Bank account

Debit Credit Debit Credit
(4) - Invoice matching 100 (5) - Payment 100
(5) - Payment 100

Modelize the receipt accounting in the Expense perpetual accruals way

43
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

44
8 – Reporting
Two reports have been identified
 A new one: “Detailed report on purchase order”
Reports
 A modification on an existing one: “Detailed report on supplier invoices”

PO detailed report (Gap document 5)

• Have a visibility of PO lifecycle

Invoice detailed report (Gap document 6)

• Have a visibility of invoice lifecycle

45
 Summary
01 Introduction

02 Supplier repository

03 Purchasing categories and catalog structure

04 From a need to an approved purchase requisition

05 From an approved purchase requisition to an approved purchase order

06 Receiving

07 PO/Invoice matching

08 Reporting

09 Appendix

46
9 – Appendix – Gap documents
Autocreation workflow from a PR to a PO (Gap document 1)
EDENRED wishes to automate some order creations according to criteria Gap document 1

PO form (Gap document 2)

• Edited from the XML standard and adapted according to EDENRED needs Gap document 2

Account generator customization (Gap document 3)

• Automatically generate the account assignment lines of purchasing requisitions
Gap document 3
• Business rules described in the next slides

Buyer assignment (Gap document 4)

EDENRED wishes to assign requisitions lines to buyers in order to ensure a dispatching
Gap document 4
according to buyer scope and operating unit

PO detailed report (Gap document 5)

• Have a visibility of PO lifecycle Gap document 5

Invoice detailed report (Gap document 6)

• Have a visibility of invoice lifecycle Gap document 6

Contract PO creation (Gap document 7)

• Autocreate the PO contract systematically when a supplier is created Gap document 7

47