DDD Pur Po V1.1

DETAILED DESIGN DOCUMENT
Print Date: 26-Sep-1917-Jul- DOCUMENT1ALTAIR_FNC_DDD_PO_V34_FINAL_15 Formatted: Font: (Default) Arial, 10 pt, English (United
1723-Sep-1525-Mar-1428-Jun-
States), Do not check spelling or grammar
1320-May-13 09 2010_FINAL.DOCX
Area: Purchasing
Business Process: Purchase order creation
Status: Approved
Created by: Timothy Radlak
Last Modification by: Philippe RIVIERE Mehdi ZINE
Last Modification Date: 13.09.2010 25.03.2014 (ENH10382: PO commitment for Return items)
Internal Controls:
Approved by:
Approval Date:
Approval Signature:
Page 1 of 75
1723-Sep-1525-Mar-1428-Jun-
Contents
1 INTRODUCTION ...................................................................................................................................4
2 SAP ORGANIZATION STRUCTURE SUPPORTING THE PROCESS OF PO CREATION ............... 5
2.1 Organizational chart ...................................................................................................................................................... 5
2.2 Naming and numbering convention .............................................................................................................................. 5
2.3 Definitions ..................................................................................................................................................................... 5
3 PURCHASE ORDER STRUCTURE AND FIELDS .............................................................................. 8
3.1 Purchase order type and number ranges ...................................................................................................................... 8
3.2 Company code and purchasing organization ................................................................................................................ 8
3.3 Vendor ........................................................................................................................................................................... 9
3.4 Purchasing group ........................................................................................................................................................... 9
3.5 Payment terms .............................................................................................................................................................. 9
3.6 Partner functions ......................................................................................................................................................... 10
3.7 Currency ...................................................................................................................................................................... 10
3.8 Account assignment category ..................................................................................................................................... 11
3.9 Item types .................................................................................................................................................................... 13
3.10 “Print price” indicator .................................................................................................................................................. 13
3.11 Work code ................................................................................................................................................................... 13
3.12 Purchase order pricing ................................................................................................................................................. 14
3.13 Plant ............................................................................................................................................................................. 15
3.14 Alternate Delivery Address .......................................................................................................................................... 15
3.15 Tax code determination............................................................................................................................................... 16
3.16 Delivery Dates – Actual/Planned ................................................................................................................................. 19
3.17 WBS element (Job number) at header level ................................................................................................................ 22
3.18 Pay when paid flag ....................................................................................................................................................... 23
3.19 Lowered By amount..................................................................................................................................................... 26
3.20 Month of service at item level (EKPO- Z_MOS) and header level (EKKO- Z_MOS) ..................................................... 26
3.21 Billable / Non-Billable key (EKKN – ZZBILLIND). ........................................................................................................... 27
3.22 Client and Brand .......................................................................................................................................................... 29
3.23 Long description (EKPO - Z_LONGD) ............................................................................................................................ 30
3.24 “Single match and close” ............................................................................................................................................. 30
3.25 “Employee” .................................................................................................................................................................. 31
3.26 PO Field Listing ............................................................................................................................................................ 31
4 PURCHASE ORDER TYPES..............................................................................................................32
4.1 G&A Purchase Order (ZG&A) ....................................................................................................................................... 32
4.1.1 G&A workflow ............................................................................................................................................................. 33
4.1.2 Commitments Forecast for Financial and Operating Leasing ...................................................................................... 33
4.2 Asset PO (ZAST) ........................................................................................................................................................... 34
4.3 Blanket PO (ZBLK) ........................................................................................................................................................ 35
4.4 Job/Estimate PO (ZJOB) ............................................................................................................................................... 37
4.5 Rebates processing (ZREB) .......................................................................................................................................... 37
4.6 Mandat purchasing (ZMAN) ........................................................................................................................................ 39
4.7 Intercompany Procurement ........................................................................................................................................ 41
4.8 Quick PO ...................................................................................................................................................................... 43
5 PO CREATION AND MAINTENANCE PROCESS ............................................................................44
5.1 PO creation .................................................................................................................................................................. 44
5.1.1 PO Creation from Estimate .......................................................................................................................................... 45
Page 2 of 75
1723-Sep-1525-Mar-1428-Jun-
5.1.2 Create a Purchase Order manually for a Job ............................................................................................................... 48

5.1.2.1 Create a Purchase Order manually for a Job with an estimate ............................................................................... 48
5.1.2.2 Create a Purchase Order manually for a Job without any estimate........................................................................ 51
5.1.3 Create a Purchase Order manually in reference to multiple Job................................................................................. 53
5.1.4 Tolerance limit and budget control ............................................................................................................................. 55
5.2 Copying PO .................................................................................................................................................................. 56
5.3 Copying PO item .......................................................................................................................................................... 56
5.4 Closing PO .................................................................................................................................................................... 57
5.5 “Single match and close” function............................................................................................................................... 58
5.6 PO deletion .................................................................................................................................................................. 59
5.7 PO in Hold .................................................................................................................................................................... 59
5.8 PO return items / credit memos .................................................................................................................................. 60
5.9 Texts into the purchase order ..................................................................................................................................... 62
5.10 PO print out ................................................................................................................................................................. 63
5.10.1 PO output ................................................................................................................................................................ 63
5.10.2 PO re-printout ......................................................................................................................................................... 63
5.10.3 PO amendment ....................................................................................................................................................... 64
5.11 PO mass maintenance ................................................................................................................................................. 64
6 OTHER DESIGN CONSIDERATIONS ............................................................................................... 65
6.1 GL account determination ........................................................................................................................................... 65
6.2 Purchase order history ............................................................................................................................................ 6867
6.3 Status of the PO ....................................................................................................................................................... 6867
6.4 Workflow status ...................................................................................................................................................... 6968
6.5 PO Change tracking ................................................................................................................................................. 6968
6.6 Workflow and release procedure ............................................................................................................................ 6968
7 OTHER DESIGN CONSIDERATIONS ........................................................................................... 7271
7.1 Roles and Authorizations ..................................................................................................................................... 7271
7.2 Migration ............................................................................................................................................................. 7271
8 DESIGN LOCALIZATIONS .............................................................................................................7372
8.1 Mainland Europe.................................................................................................................................................. 7372
8.2 North America ...................................................................................................................................................... 7372
8.3 United Kingdom ................................................................................................................................................... 7372
9 OPEN ISSUES ................................................................................................................................ 7372
10 REFERENCE TO OTHER DOCUMENTS ...................................................................................... 7372
APPENDIX ..............................................................................................................................................7574
Page 3 of 75
1723-Sep-1525-Mar-1428-Jun-
1 Introduction
The purpose of this document is to define the Publicis requirements and linked SAP solutions, in relation
to the creation of the Purchase Order (PO).
The DDD Purchasing document will outline the various means of purchasing within the Publicis group. In
order to purchase there are some key master data requirements:
 Vendor Master data

 Work code.
 Work code list for purchasing via an Estimate.
 WBS/Estimate
 Cost Centre (for G&A PO’s)
Page 4 of 75
1723-Sep-1525-Mar-1428-Jun-
2 SAP organization structure supporting the process of PO creation
2.1 Organizational chart

The following organization structure will be maintained in SAP system:
Company Code 103 - Legal Entity Plant 1030
1030, UK
REMARK
Depending on the local structure of each
agency, the purchasing organization can be
Purchasing Org 1031
variably mapped to: Office 1, 3, 4
 An agency
Purchasing Org 1032
 Or an office
Office 2
 Or a business unit
Purchasing Org 103A
The appropriate level for the purchasing
organization is to be ascertained by review Business Unit A
operations conducted as part of the roll out
activities (see “decision table” below)
2.2 Naming and numbering convention

Here below, an example of the defined naming convention:
Country Company Name of Company Purchasing Purchasing

Purchasing Org Name
ISO Code Code Org group
FR F01 Publicis Net SA F011 Publicis Net F00
FR F03 Publicis Conseil SA F031 Publicis Conseil Base Agency F00

F00
FR F03 Publicis Conseil SA F032 Publicis Conseil Coordination France
F00
FR F03 Publicis Conseil SA F033 Publicis Conseil Holding
Publicis Conseil Coordination F00
FR F03 Publicis Conseil SA F034 Internationale
FR F03 Publicis Conseil SA F035 PWW HQ F00
The detailed description of SAP organizational structure mapping with Publicis org structure is described into
document: ALTAIR_FNC_DDD_CC_ORG v1.5.doc
2.3 Definitions
 Company code
The company code is an organizational unit used in accounting. It is used to structure the business
organization from a financial accounting perspective.
Page 5 of 75
1723-Sep-1525-Mar-1428-Jun-
In SAP a company code is a representative of a stand-alone legal entity that requires its own set of
accounting records for statutory reporting purposes. Creation of one SAP company code per statutory
legal entity will allow SAP standard statutory reporting functionality to be used.
Plants will be created 1:1 with company codes.
 Purchase Organization
A purchasing organization is responsible for all purchasing activities (including the processing of requests
for quotations and purchase orders, for example).
It is an organizational for Logistics, subdividing an enterprise according to the requirements of Purchasing.

It procures materials and services, negotiates conditions of purchase with vendors, and is responsible for
such transactions.
Purchasing view of vendor masters must be created on each purchasing organization for which they will
be used into purchase orders.
At Publicis, one purchasing organization will be created per autonomous purchasing entity. This will
generally be the Agency or Office level, but may also be the Business Unit.
(The appropriate level below company code is to be ascertained by review of operations conducted as part
of the rollout activities).
Remark: purchasing organization need to have a unique definition (agency, office or business unit) into a
same company code.
For central purchasing, a dedicated purchasing organization will be used (see chapter “intercompany
purchasing”
Proposed “decision table” for determination of purchasing organization:

Entity Name :
Questions: Y/N
Unique PO logo script?
Unique workflow on PO approval?
Ownership of Vendor master data?
Ownership of procurement data (POs outstanding)?
Page 6 of 75
1723-Sep-1525-Mar-1428-Jun-
 Plant
The plant is a subdivision of an organisational unit according to production, procurement, maintenance

etc. i.e. the place where either materials are produced and stored or services are provided.
A z-table may be utilised to link each Business Unit (Profit centre) to a particular delivery address and
logo at time of purchase order creation. This will reduce the need for multiple plants per company code.
One plant will be created per company code. This will minimise the need for material master data
extension across Agencies / Offices.
Unlike Clients and vendors, Materials (work codes) tend to be generic and should thus be available to all.
A possible exception is a production house such as Mundocom, which may need additional materials to
be created.
The detailed description of SAP organizational structure mapping with Publicis org structure is described
into document: ALTAIR_FNC_DDD_CC_ORG v1.5.doc
Page 7 of 75
1723-Sep-1525-Mar-1428-Jun-
3 Purchase order structure and fields
HEADER FIELDS
3.1 Purchase order type and number ranges
The following PO types and number ranges will be used by Publicis:

Each PO type is described into next chapter:“Purchase order types”.
PO Description Number From To

Type Range
ZG&A G&A Purchase Order 42 4200000000 4299999999
ZAST Asset PO 48 4800000000 4899999999
ZBLK Blanket PO 49 4900000000 4999999999
ZITA Intra company PO 46 4600000000 4699999999
ZITE Intercompany PO 47 4700000000 4799999999
ZJOB Job/Estimate PO 45 4500000000 4599999999
ZREB Rebates Credit req. 44 4400000000 4499999999
ZMAN Mandat PO 43 4300000000 4399999999
Length restriction of the lookup for the PO type
Requirement
When creating a PO, user has to choose to right PO type.
A Publicis requirement is to restrict the length of the look-up on field PO type (EKKO – BSART).The look-
up should be restricted to document types that start with a Z.
SAP solution
This will enable the user to only select document types that have been specifically created for the Publicis
group.
3.2 Company code and purchasing organization

Company code and purchasing organization are mandatory into the PO.
They can be defaulted into the user parameters and changeable.
For more details, see chapter “SAP organization structure supporting the process of PO creation” into the
present document.
Page 8 of 75
1723-Sep-1525-Mar-1428-Jun-
3.3 Vendor
A vendor must be specified into the purchase order.
The requested vendor must have been created / extended on the relevant company code and purchasing
organization being used into the purchase order.
Vendor master data are described into “ALTAIR_FNC_DDD_CC_VENDOR_V28.doc”
3.4 Purchasing group
A purchasing group is technically independent of the purchasing organization. It represents an employee

or a group of employees in charge of operational purchasing tasks.
A purchasing group is mandatory in purchasing documents.
At Publicis, a generic purchasing group (F00) will be created and used by all employees.
For certain type of purchasing (e.g. couriers and catering) specific purchasing groups will be managed for
authorization and reporting purposes.
(The complete list is to be determined as part of the ongoing rollout activity).
Proposed “decision table” for determination of purchasing groups:

Entity Name :
Questions: Y/N
Specific types of purchasing?
Specific purchasing departments or dedicated buyers?
Special reporting requirements?
Special approval workflow?
Remarks on purchasing groups:
- Printers.
Into SAP standard customizing, printer device used for editing purchase orders (PO) can be automatically
determined via purchasing groups.
This functionality won’t be used as users will use the same value for purchasing group and may be located in
different departments with dedicated printers. Printer “LOCL” (local) will be defined into condition records for PO
messages. It means SAP will use the default windows printer of the users when printing PO out. It will be part of roll
out activities.
- Release strategy requirements

Release strategy is the SAP technical method for determining the right approver into a PO. It uses such criteria as
company code, purchasing organization or purchasing group for activating the right approval strategy. Depending
on business requirements, more purchasing groups might be necessary.
3.5 Payment terms

Payment terms are automatically defaulted into the purchase order from the vendor master data.
Payment terms can be changed manually into the PO by authorised users (authorization for PO change
transaction).
Page 9 of 75
1723-Sep-1525-Mar-1428-Jun-
3.6 Partner functions
Partner functions are automatically copied from vendor master to the PO header, where they are
changeable.
During the procurement processing, if multiple partners are defined for a partner function, the system
prompts you to choose just one partner and presents the default partner as the first choice of a pop up
window.
3.7 Currency
Requirement
Publicis requirement is to be able to create Purchase Orders in currencies different to the currency of
Company Code specified in the PO, and different to the default currency of the vendor, as well as be able
to manually specify the exchange rate.
Golden rules
As the currency of the PO is set on the header level, there can be only one currency for all the items of
each PO.
Currency of the PO will be automatically defaulted from the vendor (purchasing view) as a first source,
and then overwritten by the one of Estimate (if applicable). If jobs with different currencies will be
assigned to one PO, system will issue an error message and will not allow for such an operation
[enhancement].
The currency of the PO and invoice currency may differ unless the “Exchange rate fixed (EKKO-KUFIX)”
is marked. (See DDD Logistic Invoice Verification)
PO and Hedging exchange rate
The situation described below takes place when the purchase order is created in a foreign currency and
the exchange rate used is a “hedging rate” (special fixed exchange rate negotiated with a bank).
If the hedging rate is unknown at the moment of PO creation, PO is created with a defaulted exchange
rate and then this one is updated once the hedging contract has been signed off with the bank.
Process description
When a finance (treasury) person in charge of the hedging contract provides the information, PO creator
will change the purchase order, updating the exchange rate and hedging contract number fields on the
PO.
Page 10 of 75
1723-Sep-1525-Mar-1428-Jun-
User will proceed with the following steps:
1. In order to input hedging exchange rate, PO creator will manually change the exchange rate on
the PO
2. Press “Exchange rate fixed” checkbox to ensure that the hedging exchange rate will be passed on
to the vendor invoice registered with reference to the PO and to FI-AP posting.
3. Manually input the hedging contract number in specific Z* header field “Hedging contract”. This
value will be passed on to the vendor invoice created with reference to the PO and to FI-AP
posting.
Both the fields (exchange rate and Hedging contract) will not be workflow relevant. This means that the
change will not trigger a workflow (enhancement to be managed in case the approval range is changed)
The PO can be sent to the vendor prior to the hedge contract being signed with the bank.
However, before posting the invoice, the contract must exist between the bank and Publicis because the
hedged rate must be entered in the PO.
If the purchase order has to be paid in two parts with two different rates, two purchase orders have to be
created, as the hedged rate will not be placed at line item level in the purchase order, but at the header
level.
ITEM FIELDS
3.8 Account assignment category
Field description
The account assignment category (AAC) is a field chosen by the user on a PO in order to assign the PO
line item with a cost object. Depending on the AAC chosen the cost object can be either:
- Cost centre
- WBS Element
- Balance Sheet Account
Account assignment category includes parameters into the customizing, which will drive next steps of the
process. Following common values will be maintained for Publicis account assignment categories:
 No goods receipt will be posed into the system.
 An invoice receipt will be booked and cost object will be changeable inside.
 Cost object (cost centre or WBS) is mandatory when selecting an AAC.
 General ledger account is mandatory (G/L account will be automatically determined but can be
changed: see chapter “GL account determination”).
The following account assignment categories will be used for the PO document types defined
above:
 Y - Publicis Cost Centre

 Z - Publicis WBS Element
Page 11 of 75
1723-Sep-1525-Mar-1428-Jun-
 X – Publicis Balance Sheet Account

This account assignment type has been created especially for the following purchases: ASF (advisory
service fee) intercompany invoicing
Golden rules for AAC assignment:
In UI, account assignment category should appear at header level.

Account assignment as PO item field in backend and in the UI.
For PO creation both in backend and in the Flex UIUI the same field input logic will be applied with one
exception:
Account assignment object in UI will be also displayed and ready for input in item line next to the account
assignment category.
Example:
Line Account WBS Element Cost Centre GL account Item type

assignment
category
10 Y 100 4* _
Account assignment is a line item field and will not be available on the header of the PO.
For each PO only one account assignment object type will be allowed.
This means that for one PO only one AAC will be used, PO with mixed account assignment objects like
cost centre and WBS element on one PO should never be created.
Within one PO there may be multiple account assignment objects within the same AAC.
This means that for one PO with AAC- Y Publicis Cost Centre, and many items, different cost centres
may be assigned to each item. The same applies to the remaining AAC.
One PO line can have only one account assignment object.
This means that one PO line can be assigned to one and only one cost centre, WBS element or Balance
Sheet Account.
Page 12 of 75
1723-Sep-1525-Mar-1428-Jun-
The AAC will be defaulted based on the PO type as in the table below [ENHANCEMENT]. The AAC field
will be changeable by the user and if required the X - Publicis Balance Sheet AAC could be manually
assigned by the user to any PO type.
PO Type Default Account

Assignment Category
ZG&A Y (cost center)
ZAST Z (job)
ZBLK Z (job)
ZITE Z (job)
ZITA Z (job)
ZJOB Z (job)
ZREB Z (job)
ZMAN Z (job)
3.9 Item types

The item category determines the field selection and whether any additional data screens are shown.
 Item type “Standard” (Blank value) will be used for all purchase order types, with an
exception:
 Item type “Limit” (value “B”) should be used only for blanket purchase orders ZBLK
It automatically defaults PO quantity to 1 and unblocks new tab at the item level “Limits” with
the actual line limit to be defined.
See chapter “blanket PO” below.
3.10 “Print price” indicator
“Print price” (suppress PO amount) indicator is used in order to determine whether or not the price
is to be included in the purchase order printout form.
Within the UI, print price indicator (EKK0_ZPRSDR), must appear at header level.
Once it’s activated, this indicator is automatically flagged for each item of the PO (into the back end).
3.11 Work code

A work code is a mandatory entry into the field “material” of the purchase order item.
As a prerequisite, work code need to be extended to the relevant plant.
Work code are described into document: ALTAIR_FNC_DDD_CC_WORKCODES_V8.doc
Page 13 of 75
1723-Sep-1525-Mar-1428-Jun-
3.12 Purchase order pricing

 Publicis PO pricing is based on a combination of:
o Purchasing organization
o Vendor
o Client
o Brand
o Effective date (From start date to end date)
o Work code ID
o Work code short description
o Alternative work code description
This requirement is being fulfilled by creating a specific (Z*) table: ZALT_T_VEND_PRIC.
 When a PO is created manually, after entering the work code and the job number, the user will
access a drop down list from “unit price” field, from where he will look for the right price.
When the user will launch the price search, the system will:
1/ Access table ZALT_T_VEND_PRIC and search for possible entries by filtering:
o “Purchasing organisation” value from the one within the PO header

o “Vendor ID” from the one within the PO header (if it has already been filled)
o “Client” and “Brand” from the ones in the PO item
o “Work code ID” from the one in the PO item
o “Effective date”: only table entries for which PO item “delivery date” is included
into their effective date must be selected (if delivery date has already been
filled in the PO item)
2/ Display drop down list including selected entries. This list will include:
o “Work code ID”
o “Work code short description”
o “Alternative work code description”
o “Vendor”
o Effective date
o Unit of measure
o Price per unit
o Currency
If no price has been maintained in the table, the user will have to manually update the PO price.
 The ZALT_T_VEND_PRIC table will also enable use of scales – a maximum of 20 scaling levels
can be used (this is from quantity X1 Price P1, from quantity X2 price P2).
See table ALTAIR_FNC_DDD_PO_APPENDIX 1_Table ZALT_T_VEND_PRIC .doc
 The price in the PO currency determined from the table above will be input into condition type
PBXX (item net price) of the pricing procedure defined into the customizing.
Page 14 of 75
1723-Sep-1525-Mar-1428-Jun-
Important remark: when a value is selected from the vendor price list into a PO item, the alternative
work code description overwrites the work code short description of the work code into the PO item.
The detail design for PO pricing will be described in functional specification - E0073B.
3.13 Plant
Plant is mandatory into the PO items.
They can be defaulted into the user parameters and changeable.
A PO can include different plants at item level.
For more details, see chapter “SAP organization structure supporting the process of PO creation” into the
present document.
3.14 Alternate Delivery Address
Requirement
The delivery address for a Purchase Order is normally defined at item level and is linked to the Plant.
Publicis has a requirement to overwrite this address that automatically defaults through on ad-hoc basis.
A development required by Publics will default the delivery address based on the purchasing organization
keyed into the PO.
Exception: in case of intercompany central purchasing, delivery address may not be the one of the
header purchasing organization (see chapter: “intercompany procurement”).
SAP Solution
Purchasing organization ID will be connected with Sales Organization ID into a dedicated specific (Z*)
table, accessible from the backend (transaction code SM30). The connection between sales and
purchasing organizations has to be unique.
The delivery address on the PO will be defaulted from sales organization connected with the PO. If no
connection will be defined into this specific table, SAP standard mechanism will apply by defaulting
delivery address from plant.
If the delivery address is changed for one item, the system will ask user in a popup message if the
address shall be replicated (or not) to all remaining items of the PO.
The standard functionality for address selection on item level will be used, hence user will be able to
search any address in the SAP database, including customer addresses, and over write the address
details for all items simultaneously. Delivery address can also be typed manually by the user in such a
case user will have an option to automatically replicate the address to all the remaining items of the PO.
Page 15 of 75
1723-Sep-1525-Mar-1428-Jun-
Overwrite
this address
with the
customer
address
Standard SAP functionality will be used to determine the customer address (EKPO-ADRN2 field). To
enable this, the standard SAP search on address group BP (Business Partner: customer, supplier)
should be chosen.
In case of intercompany central purchasing, each item address will be blank and can be changed
manually by the user. He will retrieve the address corresponding to the right entity by selecting “address:
customizing address (address group CA01)”.
Remark: it is not possible to determine automatically the delivery address for a specified plant as several
purchasing organization could be assigned to it (depends on the organizational structure defined for each
roll out)
3.15 Tax code determination
Requirement
Publicis requirement is to be able to determine a tax code on the PO item automatically. This tax code is
statistical information, without any impact on the net price of the PO item.
During invoice verification, the tax code from the PO will be defaulted into the invoice item, and will be
used as reference for tax calculation. As the process of invoice creation will be automated (using a
scanning process), the tax determination on the PO will play an important factor in the workload required
during invoice creation.
Golden rules
A condition type (flagged as statistical) will be used for tax determination and insert into a pricing
procedure into the customizing. Condition records will be entered into the system in order to determine
tax code to be applied.
The tax code determined on the PO item will be transferred to the invoice as a default entry but
changeable by the user.
Page 16 of 75
1723-Sep-1525-Mar-1428-Jun-
SAP Solution
Tax code determination will be carried out automatically on the PO item level based on condition records
entered into the system on following criteria:
Access sequence 1 (Designed for US, verified as first):
1. Company Code –[BURKS]
2. Destination country – [LLAND]]
3. Departure Country – [ALAND]
4. Region (State, Province, County) of the Vendor [REGION]
5. Tax Jurisdiction [TAXJURCODE]
6. Tax indicator for material (Purchasing) – field name - [TAXIM]
7. Schema group vendor – field name – [KALSK]. (Named “tax indicator” into UI for vendor
master data maintenance).
Page 17 of 75
1723-Sep-1525-Mar-1428-Jun-
If external software is to be used the solution for TAX on PO will be determined during invoice creation
and not on the PO. In such a case the above access sequence will not be used.
Access sequence 2 (verified as second):

1. Company Code –[BURKS]
2. Destination country – [LLAND]]
3. Departure Country – [ALAND]
4. Tax indicator for material (Purchasing) – field name - [TAXIM]
5. Schema group vendor – field name – [KALSK]. (Named “tax indicator” into UI for vendor
master data maintenance).
All suitable combination of selection criteria and tax codes will be maintained by Publicis (during cutover
activity or by SSC if changes are required) into these condition records.
Example:
Company Code (CC the P.ORG is Destinatio Departur Tax indicator Schema group vendor Tax Code determined on the
assigned to) n country e for material. kept on P.ORG level PO
Country kept on the
(from the plant level (in
vendor Publicis
master) system one
plant for each
company
code)
301(Saatchi & Saatchi 1 - Tax V1 - VAT Input Dom

Group) UK UK 17.5 1 - Taxable 17.5%
301 (Saatchi & Saatchi 2 - Tax
Group) UK DE zero 2 – Non-Taxable X2 - VAT Exempt
As “schema group vendor” and “Tax Jurisdiction” fields are not a standard dictionary field for price
determination a customer development will be applied to:
- Add the fields mentioned above as possible condition determination criteria (standard dictionary
extended)
- Extend Purchase Order user exits to make the fields applicable during pricing determination.
Page 18 of 75
1723-Sep-1525-Mar-1428-Jun-
SPECIFIC (Z*) FIELDS
There are a number of Z fields that are needed in the PO in order to match Publicis business
requirements. These Z fields will be added to header (EKKO) or item (EKPO) levels of the purchase
order and are described below:
PO functional specifications are described into document: Altair_DEV_PUR_E0056_Procurement.doc
3.16 Delivery Dates – Actual/Planned
Requirement:
The Planned delivery date of goods or services purchased must be recorded in the system as a
mandatory requirement.
The delivery dates are used in accordance with establishing accruals and reporting.
In addition, the Actual delivery date of goods or services can also be recorded as an optional entry.
PLANNED DELIVERY DATE Sap solution

Planned delivery date will be available for the user both on the header and item levels. Inputting value at
the header level will populate the PO item planned delivery dates.
 Planned delivery date (Header level EKKO - Z_PDD)

The field will be used to input a date on the PO header level. When the field is populated it will
automatically populate all lines of the PO with the same value. Field changes will not trigger workflow.
 Planned delivery date (Item level EKPO- EEIND)

The field can be populated automatically each time user changes/inputs planned delivery at the header
level, or manually (field will be editable even after PO approval). Field changes will not trigger workflow.
ACTUAL DELIVERY DATE SAP Solution

No goods receipt in SAP will take place ((functionality not implemented in order to limit number of
steps)).Functionality described below will be used to record the actual delivery date if required.
After the PO item has been delivered or service provided, the agency user or buyer will have a possibility
to add this date on the FLEX UIUI PO in change mode. On FLEX UIUI PO, there will be an “Actual
Delivery Date” field available on both levels; header and item.
Page 19 of 75
1723-Sep-1525-Mar-1428-Jun-
 Actual delivery date (Header level: EKKO-Z_ADD)

The field will be used to input the actual delivery date on the PO header level. When the field is updated it
will automatically populate all lines of the PO “Latest GR Date” with the same value. Field changes will
not trigger workflow.
At the same time the final delivery indicator will be set for all items upon the PO.
 Actual delivery date (item level: EKPO- LEWED)

The field can be populated automatically each time user changes/inputs actual delivery at the header
level, or manually (field will be editable even after PO approval). Field changes will not trigger workflow.
 Mock-Up Screen Design
Page 20 of 75
1723-Sep-1525-Mar-1428-Jun-
 Final delivery indicator at item level (EKPO – ELIKZ) and at header level (EKKO – ELIKZ -
Enhancement)
Golden rule
- Although no good receipt will be posted into the system, “final delivery indicator” is used for
updating “delivery status” of the PO (This functionality is described into chapter “closing PO”) and
tracking if a service/good acceptance is completed or partial.
- This flag must appear into UI at header level (enhancement), and at item level (standard field) just
near field “actual delivery date”.
- This flag must be activated in the following way:
- When “actual delivery date” is keyed at header level, it must trigger automatically
activation of Final delivery indicator into each existing items and at header level. It means
that all items have been totally received.
- When “actual delivery date” is keyed into a PO item, “final delivery indicator must be
activated automatically for this item. If all PO items have the flag activated, it must be
activated automatically at header level also. If only some items have the flag activated, it
must remain none activated at header level.
Partial receipt(s)
- PO with multiple items and only few items fully received.
If the “actual delivery date” is keyed at header level:
- “Actual delivery date” and “final delivery flag” will be filled in the same time automatically
for all items.
- The user need to remove “actual delivery date” for items not received (in such case
“delivery completed” flag will be deactivated automatically at item level and at header
level).
2/ PO with one or multiple line and with one of the items partially received.
The user needs to deactivate “final delivery flag” for the item received partially. “Item delivery text”
can be used for specifying percentage of completion of the service (refer to the chapter “Texts into
the purchase order”).
If the actual delivery date is populated at header level it doesn’t overwrite values already existing at item
level. It only populates blank or incomplete values.
Reversal operation
- When “actual delivery date” is deleted at header level, it must trigger automatically deactivation of
“Final delivery indicator” into each existing items
- When “actual delivery date” is deleted into a PO item, “final delivery indicator must be deactivated
automatically for this item
Page 21 of 75
1723-Sep-1525-Mar-1428-Jun-
3.17 WBS element (Job number) at header level
Requirement
Publicis requirement is to be able to input WBS Element into PO header and have it populated (default it)
into all the PO items. This way the PO creation effort can be significantly reduced.
Sap Solution
Golden rules
Each PO line could have only one WBS Element assigned

For one PO with multiple lines there could be different WBS elements assigned to different lines.
User will have an option to manually change each PO line WBS Element defaulted from PO header.
Header WBS Element will be used only to populate the item WBS Elements.WBS Element on the line of
PO will be used as a cost element and for workflow determination process.
Any change of WBS Element at the header level during PO creation will automatically overwrite all PO
line WBS Elements.
Technical description
WBS Element field on the line level (EKKN- PS_PSP_PNR) could be mandatory or hidden on a PO line
depending on the account assignment category (AAC) (EKPO-KNTTP
If WBS at header level has not been specified by the user – the field should not influence the creation
process.
Remark: when a WBS element is keyed in the field, it’s description must appear on the right side of the
field.
The copying of the WBS Element from header to the line item will take place:
 During the item creation, WBS element will be copied to the line item as a default value
 With any change of the WBS element on the PO Header. In this case the WBS Element assigned
to a PO line will be automatically overwritten. Every change of the WBS element on the header
level will always be applied to all PO items.
Page 22 of 75
1723-Sep-1525-Mar-1428-Jun-
3.18 Pay when paid flag
Requirement
“Pay when paid” functionality enables the business to identify any invoices in the SAP system that should
only be paid when the customer invoice has been settled on the sales side. The pay when paid (PWP)
flag on the PO will be activated based on a number of pre-defined rules. These rules have been
highlighted below.
This chapter covers in detail the requirement for PWP flag on the purchase order, the full scope of the
solution has been described in detail in additional document linked at the end of the chapter.
SAP Solution
The Pay when Paid flag will be treated differently depending on how the Purchase order is created.
When PWP is activated into vendor or / and job:

 If the Vendor (EKKO - LIFNR) has a default pay when Paid flag and the Job has a default pay
when Paid flag, the PWP flag (LFM1 - Z_PWP) on the PO will be set. The user in SAP backend
CAN manually overwrite this setting if required.
 If the Vendor has a PWP flag active but the job does not. The PO will not have the PWP flag
defaulted but the user in the UI or SAP backend CAN manually activate this flag (a warning
message must inform the user that the vendor is PWP)
 If the job has a PWP flag active but the Vendor does not. The PO will not have the PWP flag
message must inform the user that the job is PWP)
 If both the job and the vendor does not have a PWP flag active the PO will not have the PWP flag
message must inform the user that the job and vendor is not PWP)
Additional control on PWP on PO required by treasury:
 A specific table (Z_PWP_Amount) will define per company code (Z_PWP_Amount_BURKS), a
net value in base currency – currency of company code (Z_PWP_Amount_ NETWR) on which the
PWP control will apply.
 The logic of the Z table (Z_PWP_Amount) will be as follows – when creating a PO, a function
should be called to check the total value of the Purchase Order (KOMP-NETWR) against the
value that has been defined in the table. If the total value is above the value defined in the table,
the Pay when Paid (EKKO-Z_PWP) flag should be activated in the PO and grayed out so no
further changes can be made. The user in SAP backend must be able to remove the flag.
 If the flag will be activated automatically, a warning message should appear on the PO informing
user that the PWP flag has been set.
 It no entry will exist for the company code in the table the control will not be active.
Page 23 of 75
1723-Sep-1525-Mar-1428-Jun-
 A specific transaction (Z*) will be created in order to maintain this table and manage specific
authorizations.
The PWP Flag on the PO will be changeable (user can manually activate/deactivate it), according to the
rules described above. The authorization concept for PWP management has not been used to avoid
roles multiplication and significantly lower effort needed for future system maintenance.
PWP on the invoice

It is important to note that this pay when Paid flag should be transferred to the creation of an invoice,
transaction MIRO. If the pay when Pay flag has been selected in EKKO-Z_PWP this should be
transferred to a custom field (Z_PWP) in table RBKP (Invoice Header table).
An indication of where the Pay when Paid flag should be located on the Purchase Order (ME21N) and UI:
Pay when Paid
Page 24 of 75
1723-Sep-1525-Mar-1428-Jun-
A graphical indication of the “pay when pay” flag in transaction MIRO, table RBKP – Z_PWP.
Pay when Paid
As the PWP flag is displayed on the PO header the PO will be marked as PWP relevant, meaning all of
the PO items will be PWP relevant (EKKO-Z_PWP).
Pay when paid functionality is described in detail in the following documents:

- E0024C - AP - Pay_when_paid for estimate billing
- E0024B - AP - Pay_when_paid for progressive billing
- E0024A - AP - Pay_when_paid for Media
Page 25 of 75
1723-Sep-1525-Mar-1428-Jun-
3.19 Lowered By amount
Lowered By amount stands for a Publicis requirement to be able to input an absolute header discount
when creating a PO into UI.
In standard backend SAP GUI the requirement can be fulfilled by using the standard condition HB01 to
the header pricing conditions of the PO.
After inputting a value in the condition it will automatically be applied to the PO pricing header conditions
as the value for HB01. This will lower PO amount distributing the amount of the discount proportionally to
all the PO items.
The discount will always be applied in the PO currency. The net amount of the PO (i.e. the total amount
including the discount) is the amount used for determining the number of levels of PO approval as
defined in the agency’s approval hierarchy.
3.20 Month of service at item level (EKPO- Z_MOS) and header level (EKKO- Z_MOS)
Definition
Month of service (“MOS”) is a date field used to group transactions into a specific month and year so that
they can be reported on and billed as a group. MOS is not specific to the day, rather it is defined as a
specific month for a specific year.
For example, the MOS for January 12th, 2010 is “1/10” or “01-10” or “Jan 2010”. Publicis requires being
able to assign the MOS date to a PO and later transfer it to an invoice created with reference to the PO.
SAP solution description
Into the purchase order, the month of service will be a specific field (EKPO- Z_MOS) at the PO item level
and header level If the user fills the information at header level, it is defaulted for each items
The field will be a date field, ready for user input. As most agencies do not use a MOS, the field will not
automatically default to any value on the PO. The field will remain empty, unless changed by the user.
When an invoice is created with reference to the PO, the value from month of service on the PO will be
copied to the line item of the invoice with the following rules:
 if the MOS is blank in the PO, the MOS in the invoice booking becomes the vendor invoice date
(RBKP-BLDAT)
If the MOS is filled in on the PO, then it should be the MOS from the PO that gets booked into the
resulting invoice.
The MOS field will be changeable during both the PO and Invoice creation.
If a particular line is required to be split between different months of service, then multiple lines will need
to be created in the PO, quoting the varying months of service.
This rule must be part of document ALTAIR_FNC_DDD_CC_LIV.doc

Page 26 of 75
1723-Sep-1525-Mar-1428-Jun-
3.21 Billable / Non-Billable key (EKKN – ZZBILLIND).
 The billable / non-billable indicator will in turn influence the GL account determination ( see chapter
“GL Account Determination”) and must be mandatory on every PO type:
Here below is a screen capture of where the billable flag should exist on ME21N:
Billable/Non billable
 Value “B” or “N” are automatically populated when the PO is created either via the estimate.
Page 27 of 75
1723-Sep-1525-Mar-1428-Jun-
Matrix below is used to determine which value will be defaulted and changeable or not into the PO item.
In a general way, following rule is applied:
o If the PO item is created from an estimate, B or N value are derived automatically from the
estimate value, and:
 changeable if the indicator has a blank value into the AWL (rules R1, , R5 above)
 Not changeable, if the indicator does not have a blank value within the AWL (R2)
o If the PO item is created manually from an Allowed Work code List (AWL), the system
checks the job :
 If the work code in AWL is only billable: “B” is defaulted into PO item (Rule R14
above)
 If the work code in AWL is only non billable: “N” is defaulted into PO item (Rule
R15 above)
 If the work code in AWL has a only “blank” value: a default value will be taken from
a “project profile (= job group) default table” (Rule R13 above)
 If the PO item is assigned to a cost centre, value “N” is defaulted into the item.
Remark: in case of a PO is assigned to a cost center, billing indicator is not relevant for account
determination..
 In case the billing indicator is changed in the estimate, the indicator in the PO open items (invoice not
recorded) will need to be changed accordingly. This will be procedure driven, which means that the
desired adjustments will be done manually by the authorized user.
 Billable/Non billable on the PO line should be greyed out – not changeable as soon as any invoice
has been received with reference to the PO line.
Page 28 of 75
1723-Sep-1525-Mar-1428-Jun-
3.22 Client and Brand
Business requirement
When a PO is created with reference to a WBS element, client and brand from the job must appear on
the PO screen
Client Client name

Brand Brand name
If a PO is created without WBS element (PO with cost centre or balance sheet account), the client and
Brand are not required.
SAP solution: Client and Brand in the Purchase order when creating a PO manually into standard
transaction code ME21N and in Flex UIUI.
The Client and Brand are custom fields that are required on the Purchasing document. The following
rules should be used to determine the Client and Brand from the WBS element that is entered into the
purchasing document by the user in ME21N and in UI.
For both the client and the Brand the user exit need to search for the following – go to the table WBS
element table (PRPS – PSPNR), enter the WBS element from the Purchase order (COBL - PS_POSID).
The object category for the WBS Element should be read (PRPS - OBJNR) and transferred to IHPA –
OBJNR.
Page 29 of 75
1723-Sep-1525-Mar-1428-Jun-
Once this had been derived, the following entries need to be read
Field Table/Field Data Element Data Type Field length
Client IHPA-PARNR I_PARNR Char 12
Brand IHPA-PARNR I_PARNR Char 12
Brand description
Client description
To derive the Client – the following need to be read PARVW = 'SP'

To derive the Brand – the following needs to be read PARVW = 'ZB'
Once the client and brand have been derived they should be placed in the following fields in the PO:
 Client EKPO – Z_PARNR

 Brand EKPO – Z_PARNR
Client and brand number must be filled into respective fields and their names must also appear
alongside.
If a PO is created without WBS element (PO with cost centre or balance sheet account - account
assignment) (COBL - PS_POSID) the client and Brand are not required.
3.23 Long description (EKPO - Z_LONGD)

An additional text field (200 characters) will be available at PO item level
This filed is described into chapter “Texts into the purchase order”
3.24 “Single match and close”
A check box “single match and close” (EKKO_ZSINGLE) will be available at header level.
See chapter “single match and close function”.
Page 30 of 75
1723-Sep-1525-Mar-1428-Jun-
3.25 “Employee”
A specific Z* field “Employee” (EKKN_ZEMP) must be available at item level in UI and the backend.
A match code function must allow user to select employee number from the HR table (PA0001-PERNR).
When an employee number is keyed into this field, employee user name (PA0001-UNAME) must appear
on the right side of the field.
3.26 PO Field Listing
Po field listing is detailed into document: Altair_FNC_PUR_Procurement_Fieldmapping.doc.
Page 31 of 75
1723-Sep-1525-Mar-1428-Jun-
4 Purchase order types
4.1 G&A Purchase Order (ZG&A)
Requirement
Publicis requirement is to be able to create Purchase orders for general and administrative expenses.
These purchase orders should be created against Cost Centres as an account assignment object, and
will take on different release procedures to the PO’s created against WBS Elements.
Any user within the Agency and SSC can create this kind of PO.
SAP Solution
In SAP for general and administrative expenses a new purchase order type will be created: ZG&A - G&A
Purchase Order.
Choosing the ZG&A purchase order type will have the following impact:
- The account assignment category Y – Publicis cost centre will be defaulted.

- Number range 4200000000 – 4299999999 will be set for the order type.
For G&A PO the user will have to pick up a relevant material designed for the PO type. The choice will be
made based on the material group and short description of the material. For G&A purchases a dedicated
set of materials will be created in such a way to enable automatic GL account determination.
Page 32 of 75
1723-Sep-1525-Mar-1428-Jun-
4.1.1 G&A workflow
After inputting all the necessary data and saving the G&A purchase order a two level approval workflow
will be triggered as follows:
Approval Approvers Additional Remarks

levels
required
Two Reviewed by SSC user and Finance Both approval levels will always be required.
approval Controller (as defined in Purchase Approval will be done sequentially. The PO will
levels Org.) be considered approved when both approvals
have been done.
PO will be available for printing before it is completely approved and, in this case, would be printed as a
Draft (PO output form with watermark “Draft”).
4.1.2 Commitments Forecast for Financial and Operating Leasing
For leasing purposes, Publicis requirement is to have a commitment split by month, same as the payment
schedule.
SAP solution
The Financial Controller of the Agency will create a G&A PO by entering a line item for each month to be
invoiced, using the same material reference in each line item
Example: In case of monthly payments for a 1 year leasing, the user will add manually (using copy/paste
function) 12 line items: 1 item per month (including the right delivery date).
Commitment will then be generated by month and invoices will be booked consecutively in reference to
each item.
Page 33 of 75
1723-Sep-1525-Mar-1428-Jun-
4.2 Asset PO (ZAST)
Requirement
Publicis requirement is to have PO type dedicated for the purchase of assets. The PO type will have a
separate number range as well as being an authorization object making it possible to restrict the access
to the PO type.
Invoices must be posted on dedicated P&L G/L accounts and later settled to balance sheet accounts.
SAP Solution
In SAP system a new PO type will be created: ZAST – Asset PO.
Choosing the ZAST purchase order type will have the following impact:
- Z – Publicis WBS account assignment category will be defaulted

In case of the PO for an asset acquisition, user will specify the dedicated work code (including
dedicated material groups) for asset purchasing, which will automatically default a G/L account (P&L 9*
technical GL account - Automatic G/L account determination is part of a specific chapter of this
document).
Remark about automatic G/L account determination:

The material groups for assets will reflect accounting requirements in such a way to create at least one material group for each
asset class / G/L account to be determined.
Examples:
- investment asset Office Equipment and Furniture,
- investment asset IT infrastructure
Work codes created for assets must only be used for PO type ZAST. An error message should appear if
one of these work codes is filled into another PO type (a control can be done on materials groups,
isolated through a specific numbering). (enhancement)
The default account assignment category Z – Publicis WBS will trigger a WBS element to be keyed in by
the user. The Job used should be an investment job.
Page 34 of 75
1723-Sep-1525-Mar-1428-Jun-
4.3 Blanket PO (ZBLK)
Requirements
Publicis requirement is to lower the cost of purchasing and provide an efficient process to avoid repetitive
procurement against budgeted expenses; for example administrative expenses for small value items
such as stationery, coffee, etc or larger value items such as utilities (gas, electricity, etc.) In order not to
create a purchase order each time the low value service/material is being purchased a blanket PO will
enable the user to set a value and a time frame within which invoices could be assigned to the PO.
SAP Solution
Blanket PO can be used to procure a variety of work codes up to a certain predefined maximum value
(the value limit), or until a certain predefined date (the date limit). If any of the two limits will be exceeded,
system will display an error message during an invoice creation. The PO type works like a contract –
invoices can be created with reference to the PO as long as the aforementioned limits are not exceeded.
For this kind of the PO one purchase order will be created for potentially many invoices like in a graphic
below:
In order to create a blanket purchase order user will have to manually choose the “ZBLK” purchase order
type.
Choosing the ZBLK PO type will have the following impact:
- At the PO header level the PO timeframe will appear as ready for input
- Number range 4900000000 – 4999999999 will be set for the order type
When Blanket PO is created an account assignment “Z – Publicis WBS” will be defaulted nevertheless
user will have a possibility of manually changing the default to Y - Publicis Cost Centre or X – Balance
sheet account.
For the account assignment selection criteria please visit “PO Account assignment categories”.
Page 35 of 75
1723-Sep-1525-Mar-1428-Jun-
Assignment category and an account assignment object need to be entered.
item type B – “Limit” needs to be defaulted as soon as PO type is ZBLK. It will make a limit for the
PO value appear as a required field (net price for the item will be greyed out, and quantity defaulted to 1).
Sheet “limits”:
A maximum amount allowed must be controlled during invoice verification:

o “Overall limit” must contain this maximum amount allowed. An error message will appear if
this amount is exceeded during invoice verification (the overall limit is equivalent to the PO
expected value (PO amount) plus tolerance)
o “Expected value” must be filled in. It will be used for:
 generating commitments into Controlling and
 defining the amount to be taken into account into the workflow
The invoice verification process is detailed into document ALTAIR_FNC_DDD_CC_LIV
Page 36 of 75
1723-Sep-1525-Mar-1428-Jun-
4.4 Job/Estimate PO (ZJOB)
The ZJOB PO type will be used for most of the operational expenses both billable and non billable.
This PO type can be created directly from the estimate screen, or manually with reference to a job as an
account assignment object. Full process is described in chapter “PO creation”.
Choosing the ZJOB PO type will have the following impact:
- Z – Publicis WBS account assignment category will be defaulted

4.5 Rebates processing (ZREB)
Global rebate on turnover for certain vendors is manually assessed at the end of the year, or other
settlement period according to the agreement with the vendor.
When the rebate is calculated, the vendor is notified of the amount and a credit memo is despatched to
cover the rebate amount.
The accounts payable document (credit memo) must be separated from other payable transactions.
Currently this is achieved by posting the payable to an alternative reconciliation account.
Choosing the ZREB PO type will have the following impact:
- Z – Publicis account assignment category will be defaulted

- Return item (EKPO-RETPO) will be checked for every item.
Page 37 of 75
1723-Sep-1525-Mar-1428-Jun-
Process execution steps in SAP system.
Rebate amount calculation

The rebate agreement will be kept outside of the SAP system. The volume of purchase from the vendor
will be assessed by the authorised user based on the standard reports (ME80FN – General Evaluations,
ME2L – Purchasing documents per Vendor) or any other report, through the possibility of BW / BI
reporting, if required.
PO Creation
With the rebate amount calculated the user will create a Purchase Order (ZREB type).
Authorizations will be managed to allow usage of this PO type to a restricted selection of users (control
on the PO
type).
The PO creation process will be no different than for regular POs with two exceptions:
1. For the line item a checkbox. “Return item (EKPO-RETPO)” will be marked (automatically into the
User Interface (Enhancement)). The checkbox is essential for the rebate agreement processing,
because by enabling it the user confirms that not an invoice but a credit memo is expected.
Remark: return item can be used for the other PO types as well, that’s why specific PO type
ZREB will be useful for reporting usage and authorization management.
2. The process will require a dedicated work code, identified by the short description “Rebate
agreement”. This will enable automatic G/L account determination as well as importing specific
material purchasing texts to the Purchase order.
An error message should appear if one of these work codes is filled into another PO type (a
control can be done on materials groups, isolated through a specific numbering).
If required by the vendor, the PO creator will have a possibility to use header long text to relate to the
conditions/agreement on basis of which the periodic settlement is requested.
Form will be adapted in order to specify to the vendor that the document is not a purchase order but a
credit memo request.
After inputting all necessary data the PO will be saved and workflow process for PO approval will start
automatically. When released the PO will be printed and sent to the vendor.
Invoice verification
During invoice verification, an alternative account will be used for postings. This account will be
determined via the same enhancement as for mandat in France (see next chapter), which will be
described into a dedicated functional specification (“ALTAIR_FNC_FIN_ E0107_ Loi SAPIN in France (on
behalf of)”).
Page 38 of 75
1723-Sep-1525-Mar-1428-Jun-
4.6 Mandat purchasing (ZMAN)
Due to the mandat requirements impacting numerous business processes, it has been decided to create
a dedicated detailed design document to detail all of the business requirements and proposed solution
across all process areas: “ALTAIR_FNC_DDD_MANDAT.doc”
Purchase orders that are created with reference to a job that is flagged as ‘on behalf of’ should create a
specific type of purchase order that is used to influence the following:
 The number range of the purchasing document

 The tax code of the purchase order items
 Variations on the standard purchase order output to be limited to the document title and statutory
variation such as ultimate client information.
Choosing the ZMAN PO type will have the following impact:
 Z – Publicis WBS account assignment category will be defaulted

 Number range 4300000000 – 4399999999 will be set for the order type.
In the instances where Publicis are purchasing under the mandat regulations, all of the purchases are
actually performed on behalf of the client.
Therefore the financial postings including input taxation need to be clearly distinguished from non-mandat
purchases. For example, as the purchase / sales taxation relationship is actually between the vendor and
the ultimate client, the purchase order should be tax exempt from a Publicis perspective.
The accounts payable document (invoices) must be clearly differentiated from non-mandat payables.
Currently this is achieved by posting the payable to an alternative reconciliation account.
The use of an alternative number range is to clearly identify and segregate those purchases performed
on behalf of the client with other types of purchase orders.
Page 39 of 75
1723-Sep-1525-Mar-1428-Jun-
SAP solution
- A specific purchase order document type (ZMAN: Mandat PO) will be used for all purchases that
occur referencing a job that is flagged as mandat relevant.
If a user manually creates a purchase order including a job NOT flagged as ‘on behalf of’, by using
purchase order type ZMAN, he must get an error message: “PO type ZMAN is mandat relevant only”.
If a user manually creates a purchase order that is not of type ZMAN, but the job is flagged as ‘on
behalf of’, he must get an error message “Please select PO type ZMAN for a job that is mandat
relevant”.
The purchase order type will then be used to influence a unique number range (4300000000 –
4399999999) and the additional requirements (specific text / mentions on the form) to the standard
purchase order output.
- A dedicated work code will be used, including a “mandat” tax code indicator (this tax code indicator
will be a criteria for automatic tax code determination into the PO item. See chapter “tax code
determination).
- A new tax code will be used which calculates the applicable taxation but is set up so that this tax is
non-deductable from the Publicis perspective.
-
This will enable the total amount to be paid to be calculated and displayed on the purchase order but
not accounted for within the Publicis tax accounts. When creating purchase orders with the UI the tax
code will be set using the back-end data provisioning function call.
However, to ensure there are no errors, a validation rule (if PO is ZMAN -> use correct tax code) will
be added in the invoice document to ensure that all mandat relevant documents have a valid tax code
set.
During invoice verification, an alternative account will be used for postings. This account will be
determined via an enhancement, which will be described into a dedicated functional specification
(“ALTAIR_FNC_FIN_ E0107_ Loi SAPIN in France (on behalf of)”).
Remark: A mandat purchase order is always PWP (Pay When Paid) relevant.
Page 40 of 75
1723-Sep-1525-Mar-1428-Jun-
4.7 Intercompany Procurement

Intercompany process is described into DDD ALTAIR_FNC_DDD_CC_IC_PROCESSES
For intercompany procurement scenarios, two PO creation business usages are possible:
- Annual intercompany recharges (example: coordination fees, ASF, budget cost recharges).
o For this scenario multiple PO items can be created, reflecting a billing plan.
o For one purchase order multiple incoming invoices will be created in the buying Agency.
o The invoice creation process will be automatic and based on the billing plan and sales
orders generated in the selling agency.
- Intercompany trading.
o For this scenario no annual budget is provided for the expenses in the buying Agency.
o The actual delivery date should be marked on the PO as a confirmation that the service
has been provided before the PO can be billed by the selling Agency
The end client (business partner) from the buying agency’s job should be quoted on the ICPO
SAP solution
Golden rules
- There is a requirement for two specific number ranges to identify between inter and intra company
purchases.
Two PO types ZITA and ZITE linked to a separated number ranges have been defined in order to
match this requirement:
o Number range 4600000000 – 4699999999 will be set for the order type ZITA (intra
company PO type)
o Number range 4700000000 – 4799999999 will be set for the order type ZITE (inter
company PO type)
Intercompany asset transfer will use PO type ZAST

- The vendor chosen on the PO should belong to ZVIN vendor account group (Vendor account
groups are described into ALTAIR_FNC_DDD_CC_VENDOR) and represents the entity the PO
will be sent to.
If PO type is ZITE or ZITA and vendor doesn’t belong to ZVIN vendor account group, an error
message will occur: “Please choose an inter/intra company vendor” (Enhancement)
Page 41 of 75
1723-Sep-1525-Mar-1428-Jun-
- System will perform following check:
o If PO type is ZITE, and intercompany radio button (LFB1-ZINTER) into vendor master data
is not activated, an error message will appear: “Please select only an intercompany vendor
for PO type ZITE”. (Enhancement)
o If PO type is ZITA, and intra company radio button (LFB1-ZINTRA) into vendor master
data is not activated, an error message will appear: “Please select only an intra company
vendor for PO type ZITA”. (Enhancement)
o If PO type is ZAST, and intra company radio button (LFB1-ZINTRA) into vendor master
data is activated, an error message will appear: “Intra company vendor not allowed for PO
type ZAST”. (Enhancement)
o It will be allowed if PO type is ZAST, and intercompany radio button (LFB1-ZINTER) into
vendor master data is activated
o If PO type is ZG&A, ZBLK, ZJOB, ZREB or ZMAN and vendor keyed into PO header
belongs to ZVIN account group, an error message will appear “Inter or intra company
vendor not allowed for this PO type”. (Enhancement)
- Output, release strategy, tax code and price determination for intercompany PO will be carried out
the same way as for the ZJOB PO.
Intercompany matrix
Matrix below summarizes main information for each process described into “intercompany DDD”, where
an intercompany purchase order (named ICPO into intercompany DDD) is required.
Remark: numbers in red color into the matrix refer to specific solutions below.
Page 42 of 75
1723-Sep-1525-Mar-1428-Jun-
(1) Specific solution for Intercompany procurement (central purchasing US)
- A dedicated central purchasing organization will be set up for the US.

This purchasing organization will not be assigned to any specific company code, but linked to
relevant plants (These plants belong to company codes other than that defined at header level)
- Company code of the PO creator will be keyed into the PO header.
- Vendor to be filled into will belong to vendor account group Z001 (“external” vendor).
Prerequisite: Vendor needs to be extended on the central purchasing organisation before creating
a PO.
- At item level, multiple lines will be created including different plants and delivery addresses,
assigned to different jobs, belonging to different company codes.
A specific rule must be implemented regarding delivery addresses. Delivery address may not be
the one of the header purchasing organization.
Each item has theoretically a different delivery address. (See chapter “alternative delivery
address”)
- When recording the vendor invoice, intercompany posting between ordering company code and
receiving ones, will be generated automatically at the same time.
(2) Specific solution for Intercompany Recharging of Overhead Costs
- As multiple purchase orders need to be created at the beginning of each year, a mass upload
functionality of POs has been requested.
A specific Z* program will be used in order to load required data into a defined format and launch
automatically a PO creation program. This program will be the one used for PO upload/ migration.
(Enhancement)
4.8 Quick PO
Quick PO is required for the provision of purchase orders relating to two particular types of purchase -
couriers and catering - whereby, in the case of couriers, the user is unaware of the actual supplier and
cost and, in the case of catering, the user selects requirements from a list of pre-priced menu items.
Quick PO will be part of a dedicated DDD to be created: ALTAIR_FNC_DDD_QUICK PO
Page 43 of 75
1723-Sep-1525-Mar-1428-Jun-
5 PO Creation and maintenance process
In SAP system three ways of PO creation will be supported:
1. Manual PO creation, available both in the backend and in the Flex UIUI
2. PO creation from the estimate, available both in the backend and in the Flex UIUI
3 PO creation with reference to existing PO, available both in the backend and in the Flex UIUI.
Whilst PO’s can naturally be created in the back end, users will be expected to create all PO’s via the
Flex UIUI, except in the case of uploading PO’s
5.1 PO creation
Requirement
The business requirement is to be able to create a PO from an estimate, or manually from the PO initial
screen, by assigning job(s) and relevant information inside.
Golden rule
 PO can only be created from the Job estimating screen, when the job (billable) is unlocked for PO
creation, i.e. when following prerequisites are met:
- Job must have status “Finance review complete”

- Estimate must have status “client approved”
- Jobs where no estimate is required will have status of client approved
 For a non-billable job (PO create manually), PO blocking status is removed when job gets status
“finance review complete”.
Remark: Billable jobs may require a PO creation before the client acceptance of one estimate scenario
and after Finance revision. In this situation, several scenarios could exist for the job, still none of them
confirmed by the client. For this purpose, a non-billable sub job will be used in order to create a PO
manually, as described in the next chapter.
Page 44 of 75
1723-Sep-1525-Mar-1428-Jun-
5.1.1 PO Creation from Estimate
 The user selects from the estimate the work codes that need to be included in the PO and selects the
button “Create PO”. The Create PO main screen is displayed and the existing information from the
work codes is populated in it.
The work code item in the estimate contains relevant pre-defined data for the PO creation:
- Vendor (ZALT_S_VARIANT_ITEM-LIFNR): This field is not obligatory in the estimate

item.
If the vendor is filled into the estimate item, it will be automatically defaulted into the PO
header.
If each estimate items do not refer to the same vendor, a dedicated PO must be created
for each vendor.
- Plant (ZALT_S_VARIANT_ITEM-WERKS)
Page 45 of 75
1723-Sep-1525-Mar-1428-Jun-
- Delivery Date (ZALT_S_VARIANT_ITEM–EINDT): This field is not obligatory in the

estimate item. In case this data is not provided, it will be required at the moment of PO
creation.
- Purchasing Group (ZALT_S_VARIANT_ITEM-BKGRP)
- Material or OOP work code (ZALT_S_VARIANT_ITEM-MATNR)
- Unit price (ZALT_S_VARIANT_ITEM-OPREIS): This is the price in object (estimate)
currency..
- Quantity (ZALT_S_VARIANT_ITEM-MENGE)
- Quantity Unit (ZALT_S_VARIANT_ITEM-PMEHT)
- Description (ZALT_S_VARIANT_ITEM-LTEXT): 40 character long text describing the
work code
- Long description from the estimate item
- When “narrative print indicator” is activated the estimate item “long description” (long text
field) will be copied into the PO item text: “Work code long description” (long text field)
When the PO is saved the PO item text “long description” (long text field) is copied (only
the first 200 characters) into PO item Z*field “Long description” (development), which can
then be used in reporting.
-
- Billable / Non Billable indicator: will be determined automatically as described into
chapter “Billable / Non Billable key (EKKN – ZZBILLIND)”
- Currency (ZALT_S_VARIANT_ITEM-FWAER_KPF): Object (estimate) currency.
Following rule is applied for determining the PO currency:
Case 1: in the event that the vendor is not defined within the estimate, a check is done to
compare the vendor currency, taken from the vendor master data (at purchasing org.
Level), and the estimate’s item currency.
If there is a discrepancy, the following happens:
- A warning is displayed about the discrepancy.
- The vendor currency is still used as the default PO currency.
- The price of the corresponding items is not copied over to ensure a proper price
conversion is done by the user.
- The PO currency can still be manually changed back to the estimate’s line item’s
currency if really needed.
- The system will not allow for multiple currencies assigned to one PO and will issue
an error message if this occurs.
Case 2: In the event that the vendor is defined within the estimate item and the item’s
currency is the one from the vendor master data (defaulted into estimate item), system will
take the vendor currency as PO currency
Case 3: In the event that the vendor is defined within the estimate item, but the currency
has been manually changed and is different from the one of the vendor master data, the
estimate item currency must be the PO currency, and replace the one of the vendor
master data into PO header.
 The user selects the PO type from the drop down list: ZJOB, ZAST, ZBLK, ZITE or ZITA
 One PO item is created per each selected work code.
 In case various vendors are pre-determined in the selected work codes, the user will be required to
select one of them or to provide an alternative one.
Page 46 of 75
1723-Sep-1525-Mar-1428-Jun-
 If the necessary data for creating the PO is still incomplete, the system will issue a message
prompting the user to maintain the missing data.
 Material and expense (OOPs) work codes into the estimate will carry a procurement indicator
detailing whether or not a work code has been purchased.
The indicator will be set automatically into the estimate item when the relative PO item is created and
cannot be maintained manually. It can have the following values:
- F – fully purchased (all related POs can be viewed)

- P – Partially purchased (any related POs can be viewed)
In case a work code has been partially procured, the user will be able to view details of previous PO’s
raised using PO search for functionality in the UI or standard SAP reports like ME2K – Purchasing
documents per Account Assignment.
Any additions or alterations to the data inherited from the estimate items in the PO creation screen will
not be fed back to the estimate (for details please refer to the document ALTAIR_PS_ DDD Job
Estimating).
PO creation from estimate is detailed into Altair_DEV_CJO_E0008_Create Purchase Order from Job
Estimate_V0
Page 47 of 75
1723-Sep-1525-Mar-1428-Jun-
5.1.2 Create a Purchase Order manually for a Job
Two different scenarios may occur depending on the job has an estimate or not.
5.1.2.1 Create a Purchase Order manually for a Job with an estimate
 To create manually a PO for a job, the user will be required to provide some basic initial data in the
PO creation screen:
- The job (WBS element)

- The purchase order type: ZJOB, ZAST, ZBLK, ZITE or ZITA
- The vendor
 Organizational data will be derived from the job and the user settings, then completed by the user as
required.
Page 48 of 75
1723-Sep-1525-Mar-1428-Jun-
 The user must enter a work code into the PO item. He is able to select one or more work codes from
a search screen (described below) these are transferred to the PO as one or more items on the
purchase order.
The search screen will offer 2 tabs:
Example of possible search functionality:
- In the the first tab, the system will offer to the user the AWL from the job as the work
code selection list (“option 1” on the schema above). In this case budget availability
check will be allowed at job/sub-job level or project level, not at work code or work code
group levels.
A flag indicates if work codes are included within the estimate.
- In the second tab, only work codes included into estimate and their alternative
description will be offered to the user for work code selection (“option 2” on the
schema above). The materials flagged as already procured will also be displayed
including the procurement indicator and a warning message will be issued if they are
selected for purchasing. The system will allow their selection, but the completion of the PO
creation will depend on the budget availability defined (see chapter “tolerance limit and
budget control” below)
 When the user select sthe work code(s) from the estimate list (option 2) .the system will
automatically determine the following:
- Work code descriptions

- Long description from the estimate item
- When “narrative print indicator” is activated the estimate item “long description” (long text
field) will be copied into the PO item text: “Work code long description” (long text field)
When the PO is saved the PO item text “long description” (long text field) is copied (only
the first 200 characters) into PO item Z*field “Long description” (development), which can
then be used in reporting.
- Billable/non billable indicator as described into chapter “Billable / Non Billable key
(EKKN – ZZBILLIND)”
- Vendor linked to the Estimate item (if one has been defined). Following rule then is
applied:
- Vendor is given by the user in the PO initial screen and only one vendor is allowed
per PO.
Page 49 of 75
1723-Sep-1525-Mar-1428-Jun-
-
If different vendors have been defined in the selected work codes the system will
inform of this circumstance to the user and will require his/her confirmation to
proceed.
- The vendor given initially will prevail.
- Work code net price defined into the estimate item
- Currency: the same control as described into chapter “PO creation from estimate” will be
applied
- Work code quantity and unit of measure.
- Delivery dates. These will be derived from the estimating items (work codes) if given. In
case they have not been pre-defined the user will be requested to provide them.
- Client and Brand in the job.
- PWP (pay when paid) flag in the job
 When the user selects the work code(s) from the AWL (option 1) , steps are the same one as
described in the next chapter.
Page 50 of 75
1723-Sep-1525-Mar-1428-Jun-
5.1.2.2 Create a Purchase Order manually for a Job without any estimate
 To create manually a PO for a job, the user will be required to provide some basic initial data in the
PO creation screen:
- The job (WBS element)

- The vendor
required.
 The user must enter a work code into the PO item. He is able to select one or more work codes from
the AWL (option 1) into the search screen (described into previous chapter: “Create a purchase order
manually for a job with an estimate”). These are transferred to the PO as one or more items on the
purchase order.
Page 51 of 75
1723-Sep-1525-Mar-1428-Jun-
The system will automatically determine the following:
- Work code descriptions

- Billable/non billable indicator as described into chapter “Billable / Non Billable key
(EKKN – ZZBILLIND)”
- Currency: will be defaulted from the vendor master data.
- Client and Brand in the job.
- PWP (pay when paid) flag in the job
 Finally, the user need to fill in manually following information, into the PO item:
- Long description
- Work code net price into the estimate item. User has two options:
- enter a price manually
- look for an existing price into the “vendor price list” as described into chapter
“Purchase order pricing”
Reminder: when a value is selected from the vendor price list into a PO item, the
alternative work code description overwrites the work code short description of the
work code into the PO item.
- Work code quantity and unit of measure.
- Delivery dates. These will be derived from the estimating items (work codes) if given. In
case they have not been pre defined the user will be requested to provide them.
Page 52 of 75
1723-Sep-1525-Mar-1428-Jun-
5.1.3 Create a Purchase Order manually in reference to multiple Job
 To create manually a PO for multiple jobs, the user will be required to provide some basic initial data
in the PO creation screen:

- The vendor
required.
Page 53 of 75
1723-Sep-1525-Mar-1428-Jun-
 The user needs to specify job codes:
- He can fill a value at header level: this job code is defaulted on each of the PO items. He
will then change job codes into each line item if required.
- He can leave the job code as a blank value at header level and key in one by one job
codes into each required PO items.
 Depending on whether job codes have an estimate or not, user has to follow next steps described into
both previous chapters:
- “Create a purchase order manually for a job with an estimate

- “Create a purchase order manually for a job without any estimate
 Following rule about PO vendor will be applied. If a PO item is linked to an Estimate item including a
vendor:
- Vendor is given by the user in the PO initial screen and only one vendor is allowed
per PO.
- If different vendors have been defined in the selected work codes the system will
inform of this circumstance to the user and will require his/her confirmation to
proceed.
- The vendor given initially will prevail.
 Following rule about PO currency will be applied. If one of the PO items is linked to an Estimate item
including a currency:
- Case 1: in the event that the vendor is not defined within the estimate, a check is done
to compare the vendor currency, taken from the vendor master data (at purchasing
org. Level), and the estimate’s item currency.
If there is a discrepancy, the following happens:
- A warning is displayed about the discrepancy.
- The vendor currency is still used as the default PO currency.
- The price of the corresponding items is not copied over to ensure a proper price
conversion is done by the user.
- The PO currency can still be manually changed back to the estimate’s line item’s
currency if really needed.
- The system will not allow for multiple currencies assigned to one PO and will issue
an error message if this occurs.
- Case 2: In the event that the vendor is defined within the estimate item and the item’s
currency is the one from the vendor master data (defaulted into estimate item), system
will take the vendor currency as PO currency
-
-
Page 54 of 75
1723-Sep-1525-Mar-1428-Jun-
5.1.4 Tolerance limit and budget control
Publicis requires a multiple-level budget control in the ECP (Easy Cost Planning) estimates, as standard
SAP does not offer budget control for this functionality, a specific solution will be provided to Publicis.
Whenever a cost-related posting on a WBS element (e.g. procurement, (re)postings via FI, etc.) is to be
performed, the system is to check whether there is budget tolerance data maintained. Reversal
transactions will be included from these before-posting checks as they may be reversals of reversals and
thus increase costs.
SAP Solution
Job budget check: In case budget availability check is activated in the job, the check always runs for
material procurement and Out of Pockets. Budget control may be conducted on one of the following five
different levels:
 Item (workcode) level: Percentage and/or amount tolerance limits are set in the job/sub-job
and copied into the individual estimating items.
 Work code group level: Percentage and/or amount tolerance limits are set in the job/sub-job
and derived to each of the work code groups defined in the job estimate. In this case, the
system does not check that the budget and tolerance are exceeded for any of the individual
work codes, but for the sum of all of them within the group.
 Job / sub-job level: The percentage and/or amount tolerance limit is set in the job/sub-job.
All committed and actual costs in the job/sub-job are checked for budget availability.
Available budget is given by the total estimate in the job/sub-job plus the tolerance limits.
 Total project level: The percentage and/or amount tolerance limit is set in the job. All
committed and actual costs in the main job and all sub-jobs are checked for budget
availability. Available budget is given by the sum of all the estimates in the project structure
plus the tolerance limit.
 No budget control, meaning that there is effectively no check between purchasing and the
estimate.
In all cases:
- the system checks committed and actual costs, which means that both the open PO items, vendor
invoice amounts, journal and wip transfer amounts posted to the job are checked for budget
availability.
- When a PO is created, the system informs the user (warning message: soft stop) when the
committed cost in the PO exceeds the estimating amount, but is still within tolerance, or blocks
the PO creation (error message: hard stop) when it exceeds the estimating amount plus the
tolerance limit.
- Tolerance control can be applied by both percentage and/or absolute value. If it is applied at both
percentage and value then the control will be applied at the lowest resultant amount.
- The tolerances maintained on a more detailed level will supersede tolerances maintained on
higher levels, i.e. a tolerance value maintained on a work code level will always take precedence
over any other tolerances maintained.
Page 55 of 75
1723-Sep-1525-Mar-1428-Jun-
- The solution will always consider values in object currency (company code currency)
- At the moment of saving the PO or saving the invoice in the system, the budget availability is
checked.
The detailed solution description can be found into document:

Altair_FNC_CJO_E0095_ Tolerance Limits and Budget Control V0.doc
5.2 Copying PO
In the Flex UIUI there will be a possibility of creating a new PO with reference to another existing PO. The
SAP solution will be based on a standard SAP functionality enabled by shopping cart icon (by dragging
and dropping a PO number from the document overview on the shopping cart) or by adopt icon (by
marking a PO item in the document overview and pressing adopt).
In the UI PO creation screen a button will be added described “Create with reference”. Pressing the
button will result in PO search help enabling user to search for the PO using the personalized search
criteria. For the complete list of the searchable fields please refer to the chapter “PO Field Listing” and
the external mapping file pointed there.
After the selection of a PO (by Flex UIUI selection / search), a user can select the copy button creating a
new PO by copying the data from the previously chosen document. As in the SAP backend the copied
PO will not be automatically saved allowing user to make changes before releasing the PO for the
workflow approval.
5.3 Copying PO item

In the Flex UIUI there will be a possibility of creating a new PO item by copying an existing one into the
PO:
User will select item to be copied and then push a copy button:
User will then be able to adapt data of the copied item (change quantity, delivery date…) if needed.
Page 56 of 75
1723-Sep-1525-Mar-1428-Jun-
5.4 Closing PO
Requirement description
A Publicis requirement is to be able set the final invoice checkbox, and delivery completed checkbox for
all items on the PO at the same time (i.e. at header level), in such cases where the PO has been partly
matched and the remaining commitment is no longer required.
In Standard SAP GUI the final invoice checkbox is located at item level (EKPO – EREKZ).
In Standard SAP GUI the delivery completed checkbox is located at item level (EKPO – ELIKZ).
For housekeeping purposes the user will have the opportunity to search upon and simply close unused
PO’s or those PO’s that have been part-matched and no longer required.
SAP Solution
In SAP GUI standard “Fast Change” SAP functionality will be used to apply a mass change to all PO
items as presented on the picture below.
The flex UIUI will have a button at the header level allowing user to set the final invoice flag for all items
at the same time. If the “Close PO” button is selected, all the final invoice and delivery completed
checkboxes at item level (EKPO – EREKZ), should be automatically marked with “X”.
This functionality will work in the same way as the “Fast change” functionality in the standard SAP GUI
with predefined – final invoice as a field to be changed and “All items” option selected.
This option to manually mark the checkboxes will be also available at item level.
Changing both final invoice and delivery completed checkboxes should never start a workflow for PO re-
approval.
Page 57 of 75
1723-Sep-1525-Mar-1428-Jun-
Impact of the closing a PO:
Closing the PO (marking delivery completed and final invoice checkboxes) for all PO items will clear the
PO’s commitment
Impacts of “closing a PO” during invoice verification will be part of ALTAIR_FNC_DDD_CC_LIV).
The delivery completed checkbox is purely informational – it does not influence the process flow.
Closing the PO lines will influence the status at the document header (see chapter “Status of the PO”).
Delivery status:
- Not Delivered - No delivery completed checkbox has been marked for any of the PO items.
- Partially Delivered – At least one, but not all delivery completed checkboxes have been marked in
multi item PO.
- Fully Delivered – All items of the PO has been marked as delivery completed.
Invoicing status:
- Not Invoiced - No final invoice checkbox has been marked for any of the PO items.
- Partially Invoiced - A PO can be considered as partially closed if at least one vendor invoice has
been received against the PO. The charges received do not necessarily need to tick any of the
final invoice check boxes.
- Fully Invoiced – All items of the PO have been marked with final invoice checkbox
-
-
- Remark: when a credit note is received against a PO where it is fully closed, or a line item is closed then
the line item is automatically re-opened
5.5 “Single match and close” function
Requirement
There is also a ‘Single Match and Close’ requirement, whereby, as soon as one invoice is matched to the
PO (within tolerance) the PO is closed, irrespective of the amount left outstanding. In such a case the
commitment will be deleted. The checkboxes final invoice and delivery completed will be marked. User
will have the ability to unmark these checkboxes manually afterwards, should the need arise.
SAP solution
A specific Z* check box (EKKO_ZSINGLE) will be available at header level. If this flag is activated, all PO
items will be closed automatically (see previous chapter) at the time of first invoice verification.
This functionality is described within the Logistic Invoice Verification DDD.
Page 58 of 75
1723-Sep-1525-Mar-1428-Jun-
5.6 PO deletion
For the PO lines to be rejected user will have an option of deleting PO line using the standard SAP
functionality “Delete”. The functionality will be reflected in the UI.
After making the line and using the Delete functionality, the line will be marked as deleted and as a result
the commitment for the line will be cancelled.
PO line deletion can have two results depending on the PO status.

- If the line will be deleted during PO creation (before saving, or holding the PO[backend option])
the deleted line will disappear from the document.
- If the document is held or saved then using the “delete” option on the line will not erase it. The
deleted line will still be visible on the PO and marked as deleted.
Deleting the PO line will trigger the workflow.
Remark: once a PO item has been deleted within an existing PO, it is still possible to reopen it by
selecting relevant item and clicking deletion button again.
5.7 PO in Hold
The Publicis requirement is to be able to use SAP standard HOLD option in the PO flex UIUI, the
functionality will enable user to hold a purchase order during its creation and come back to complete it
later without having to release it for the approval. Held PO is an internal document and it cannot be
printed.
Page 59 of 75
1723-Sep-1525-Mar-1428-Jun-
5.8 PO return items / credit memos
Requirement
Publicis requirement is to be able to create purchase orders for return items upon which credit memos
will be requested. The credit memo will be created in the SAP system with reference to this kind of PO.
Credit memo management is part of LIV DDD (Logistic Invoice Verification)

“ALTAIR_FNC_DDD_CC_LIV”
SAP Solution
Golden Rules
To create a credit memo request instead of regular PO an additional checkbox on a line item will have to
be marked “return item”.
The checkbox will be optional for every PO type.
A credit memo will be created with reference to the PO line marked as “Return item”
Processing return items
 To enable creating credit memos with reference to purchase orders, and influence the PO printout
user will have a possibility of marking a line as a “return item”. The “return item” checkbox will be
available for every PO type.
Remark: same functionality is used for rebates processing, but this process will be treated in a specific
way by using dedicated purchase order type ZREB
 Marking an item with a return checkbox will have the following impact:
- PO will be printed as credit memo request.

- No commitment will be created for return item
- When a return item is flagged, the commitment value of this item is negative and the system
reduces the entire PO commitment/ Consumed budget amount as consequence
-
- The PO quantity will be considered a negative quantity in standard SAP reporting but
the amount will be displayed as an absolute value on the PO form.
- Release procedures will still apply to return PO requests
Page 60 of 75
1723-Sep-1525-Mar-1428-Jun-
 Mixing item types (return items and regular items) will be possible with following rules:
o For the POs with total amount positive (total net PO amount > 0):
- - PO will be printed including both regular item positive amount and return item
negative amount.
- - A regular vendor invoice can be created with reference to the PO
o For POs with total amount negative (total net PO amount <= 0) it is advised not to mix
items.
If such a case will arise, two invoices will have to be created to cover such a PO:
- A regular invoice for positive item

- A credit memo for a negative (return) one
Page 61 of 75
1723-Sep-1525-Mar-1428-Jun-
5.9 Texts into the purchase order
Texts into the PO are managed at both header and item levels. These texts can be copied automatically
from master data or added manually by the user
 Five narrative texts will be available in the PO header

Two texts are copied into the purchase order from the vendor master data (at purchasing
organization level):
- Vendor text “Purchasing memo”: internal text which is normally used for internal communications
purposes only. Can be copied into PO “header note” text, but not printed out.
- Vendor text “Purchasing order text”: used for external communication with vendor. This text can
be copied and can be changed into PO “header text” and then printed out on the PO form.
This functionality can be useful for maintaining a text regarding “mandat” requirements to be
copied into the PO.
Three additional narrative texts will be available for user manual input:
- Header delivery text – narrative at the header level used by the user to describe additional
delivery conditions or delivery status.
- Header narrative – narrative to be printed at the PO header
- Footer narrative - narrative to be printed at the PO footer
 Four narrative texts will be available at the item details level
One text will be copied into the purchase order item from the material master data:
- Material “Purchase order text”: is used to specify to the vendor additional information about the
work code (as this text is managed at master data level, this information must be applicable for all
vendors). This can be copied and can be changed within the PO and then printed out on the PO
form
- Item Delivery text – narrative at the item level used by the user to describe additional delivery
conditions or delivery status.
- Work code long description: this text referenced in the work code item, which are brought across
from the estimate, but can be edited within the PO line item. If the narrative is changed in the PO
the changes are not reflected back in the estimate.
This text is only copied from the estimate if the “Print control for narrative “ is activated into the
estimate,
 PO line description and identification
Each PO line will be described by three fields:
Page 62 of 75
1723-Sep-1525-Mar-1428-Jun-
- Material: Standard 18 characters field. The field is a material master ID, and identifies the material
in SAP database. The field is displayed on most purchasing SAP reports, and can be used as
search criteria. Field will be set a mandatory for all PO types. User will have a possibility to
change that field (chose the material that will be purchased).
- Material short text or “alternative work code description” (from price list): Standard 40 characters
field. The descriptive short text is used to identify the material, as it is a part of a master data.
When PO is created, this text is copied into PO either from Estimate or from Material Master – if
Estimate is not available. For the system efficiency reasons this field is not searchable in the SAP
standard reports, though it can be used as a search criteria in the Flex UIUI. In flex UIUI this will
be display only field (no manual changes allowed).
- Long description: Additional development field designed to store descriptive text of 200
characters. This field will be used to store additional PO line description, which in opposite to
narrative texts could be displayed in a BI reporting search result list and used as a BI search
criteria.
PO Texts printing out will be part of the functional specification

“ALTAIR_FNC_PUR_F0012_PurchaseOrder_document_V1.doc”
Prints out functionalities are detailed in next chapter.
5.10 PO print out

5.10.1 PO output
Adobe print will be used to generate the PO output. There is a general rule that there will be one template
per country. This means the standard source fields should remain consistent across all countries
however the format of the output can be changed to meet country specific/purchase organisation
requirements eg. Address in varying locations of the output.
To determine the specific changes to the template for country/purchase organisation a specific (Z*) table
will be defined. This will enable specific details to be captured eg terms and conditions of business. A
new transaction will be provided to enable the purchase organisation administrator to define the specific
details required.
Once the PO form has been generated, a PDF file will be archived on the content server and attached to
Purchase Order. A paper printing is also possible.
5.10.2 PO re-printout
PO could be printed (output can be generated) for draft or fully approved PO’s. Whenever the user
changes any data on PO the workflow for a PO approval will be started and printout will not be possible
only in the “Draft” mode until the PO is fully approved again.
The solution will enable tracking the following information about PO being printed:
Page 63 of 75
1723-Sep-1525-Mar-1428-Jun-
o When the PO was printed: date and time of the printout (down to minutes)
o By whom the PO was printed: User ID of the person printing the PO.
The PO re-printout will be possible without limitations after PO has been approved. When a PO is printed
out a second time without any modification, mention “copy version” must appear on the form.
5.10.3 PO amendment
If a change occurs on a PO, a new version of the PO must be printed including the mention of
“amendment”.
Detailed SAP solution design for PO Forms is detailed into

“ALTAIR_FNC_PUR_F0012_PurchaseOrder_document_V1.doc”
5.11 PO mass maintenance
Publicis requirement is be able to be able to use a mass maintenance functionality for PO documents in
order to simultaneously change chosen field values in more than one PO, including mass closing of PO’s.
SAP solution
The mass maintenance of the PO will be possible through standard backend transaction MASS. By
choosing the object: “BUS2012 - Purchase orders” user will have access to choose which fields and
tables of the PO will be subject to mass modification.
The Functionality will be used as standard and backend only by using transaction code MEMASSPO.
This transaction is used to modify the same field value for several purchaser orders.
Only specific users will be allowed to run this transaction through authorizations management.
Page 64 of 75
1723-Sep-1525-Mar-1428-Jun-
6 Other Design Considerations
6.1 GL account determination
Definition
When an invoice is recorded into the system in reference to a purchase order, account determination is
used in order to define automatically on which G/L accounts postings are made.
SAP solution
Following parameters are used during the automatic account determination:

- Material group
Work codes of the same nature are grouped into work code categories which are represented by material
groups in SAP. Work codes are represented into SAP by a material master which contained one material
group.
A dedicated codification will be used for material groups regarding their nature (Asset, rebates, G&A….).
A work code must be filled into each purchase order item. The system will check the material group
coming from the work code for the account determination.
- Work code accounting indicator

The work code accounting indicator allows different account determination for the same work code.
The work code accounting indicator is determined from:
 The job group of the WBS element entered in the purchase order item
 The work code type (Billable / non billable) entered in the purchase order item
Following work code accounting indicators are possible:

1) B = billable
2) C = client-related non-billable
3) H = house / departmental
4) N = new business
5) I = investment
Page 65 of 75
1723-Sep-1525-Mar-1428-Jun-
- Valuation class
Material groups have to be created as valuation classes, which are to be declined by work code
accounting indicator where needed.
Valuation class is technical key, linked to a G/L account into the customizing.
Once the system has determined the combination of parameters above, GL account determination in
purchasing can then access SAP standard table T030 where GL accounts can be found per valuation
class.
All accounts entered in table T030 under the key combination GBB/VBR must be P&L accounts (and in
some cases (e.g. assets) it will be later settled to the Balance Sheet Accounts).
This means that all material purchases will be posted as expenses. In addition to that, material purchases
for which the work code accounting indicator is B will have to generate an additional posting debiting the
WIP balance sheet account and crediting the P&L account for offsetting purchasing.
Example:
Workcode
Material Material Valuation
accounting Valuation class description GL account
group description class
indicator
Hotel
1001 accomodation B B001 Hotel accomodation billable 3200000010
Hotel
1001 accomodation C C001 Hotel accomodation non-billable 4200000010
Hotel
1001 accomodation H H001 Hotel accomodation house 4300000010
Hotel
1001 accomodation N N001 Hotel accomodation new business 4340000010
1002 Vehicle acquisition I I002 Vehicle acquisition 9123000010
Remark: a specific table (Z*) is used to link material groups, valuation class and work code accounting
indicators.
For more details on account determination for procurement processes, please refer to documents:
- ALTAIR_FNC_DDD_CC_WORKCODES.doc
- ALTAIR_FNC_DDD_CC_WORKCODES.xls
The Valuation Group is used to help in the automatic account determination. It links the
Valuation Group to the Chart of accounts.
Within the Publicis Groupe solution as we only have one set of global accounts (COA) we only
require one valuation group.’
 Update as well the following :
Page 66 of 75
1723-Sep-1525-Mar-1428-Jun-
Formatted: Font: Trebuchet MS, 12 pt
With update to H = house / departmental / cost recovery

 Update as well the reference to the workcode word document
Formatted: Font: Trebuchet MS, 12 pt
Altair_DDD_Workcode_&_Billing_Indicator_Usage.doc
Page 67 of 75
1723-Sep-1525-Mar-1428-Jun-
6.2 Purchase order history
The Publicis requirement is to have a PO history displayed in the UI.
Double-clicking on the vendor invoice number in the tab will enable user to display information from an
invoice and to review the scanned image of the invoice.
PO history data in the UI functionality detailed specification is not part of the Purchasing DDD and should
be referred within the UI DDD.
6.3 Status of the PO
For PO status tracking standard SAP solution will be reflected in the UI. Into the PO header, three PO
statuses will be displayed: Printing status, Delivery status, Invoice status.
The value for the status as in the standard solution will be generated and displayed in the UI
automatically.
For detailed description of possible statuses, please refer to the Closing PO chapter
Page 68 of 75
1723-Sep-1525-Mar-1428-Jun-
6.4 Workflow status

Workflow status should also be displayed in the UI, in the box located near the above statuses.
6.5 PO Change tracking

For PO change tracking standard functionalities will be used in the backend. This is tracking changes on
the header and item levels of each individual PO.
For the change tracking for more than one PO at the same time standard report DGR2 - Change
documents enabling user to track changes for each table of the PO.
6.6 Workflow and release procedure
The Publicis requirement is that every purchase order in the SAP system will have to be released before
it could be printed and sent to the vendor. The PO will have to be approved according to the PO approval
hierarchies defined for purchasing organisation.
See sheet below for proposed hierarchies, to be confirmed:
Proposed
Hierarchies.xls
 Approval strategies determination
Three release strategies will be available as follows:
1. For PO with account assignment Z and only 1 WBS Element.

2. For PO with account assignment Z and multiple lines (more than 1) including different WBS
Elements.
3. For PO with account assignment Y (cost centre), X (balance sheet account).
Page 69 of 75
1723-Sep-1525-Mar-1428-Jun-
 Approver and PO creator relation
The PO creator and the PO approver should never be the same person:
o Example1: on the 1st level (job responsible is the creator) his line manager should be the
approver.
o Example2: on the 2nd level (Finance Controller is a creator) his line manager should be the
approver.
PO creator and the approver will be differentiated by user ID.
 WBS Element on PO and Release strategy
There may by multiple WBS elements per PO. Per one PO line only one account assignment object will
be allowed (no multiple account assignment. This means that for one line of the PO only one WBS
Element to Cost Center object can be assigned.
 In order to print out final version of a PO, all PO approvers have to approve the document,
before that only “Draft” printout will be possible.
SAP solution
PO approval process should be conducted using a workflow, sending notifications about objects waiting
for approval as well as allowing approver to approve or reject POs.
Golden rules
 When a PO is submitted for approval the user should be made aware of who the next approver(s)
name will be.
 The PO creation / change / will be handled via the same Workflow process.
 Any change on the approved PO will start a new approval process apart from changes to the fields
listed below:
 EKKO - Z_ADD Actual delivery date (Header level)
 EKPO - LEWED Actual delivery date (item level)
 EKPO – EREKZ The final invoice checkbox
 EKPO - ELIKZ "Delivery Completed" Indicator
 EKKO – Z_HCN “Hedging contract”
 PO exchange rate (EKKO- WKURS)
 Service acceptance text (Item and header delivery narratives)
 PO fixed exchange rate indicator (EKKO- KUFIX)

 PO printout/re-printout will not trigger the workflow
Page 70 of 75
1723-Sep-1525-Mar-1428-Jun-
 Delivery date or final invoice checkbox
 Resubmissions whilst the PO is awaiting approval will end the previous workflow and start a new
workflow. The request number remains the same.
 The approver is NOT allowed to change the extended data (might change).
 From a segregation of duties point of view, the requestor should never be able to approve his work
item either as a direct approver or as a substitute.
PO possible release statuses
Status code Status description When Applied

N Not Confirmed Applied when PO has not been
confirmed by any of the
approvers. With this status PO
will only be printable as a Draft
P Partially Confirmed Applied when PO has by
confirmed by at least one of the
approvers, and the release
strategy requires further
approvals.
With this status PO will only be
printable as a Draft
C Confirmed Applied after the last approval.
Approval levels for all strategies
will be applied sequentially. All
Approvers in the strategy will
have to approve PO for it to be
confirmed.
With this status PO will be
printable in a final verison.
Workflow outline
After saving newly created PO or changed PO the workflow process will be started.
An email with notification will be sent to the first approver with standard notification about the PO number
awaiting approval. From within the notification the approver will be able to use a shortcut directing to the
SAP approval screen. Approver will not have a possibility to change the PO. Only two options will be
available - accept or reject it.
- If POs are rejected the notification about the rejection, will be sent back to PO creator. Next the
creator will have the possibility to rework the PO and resend it for approval starting the workflow
from very beginning.
- If PO is accepted, the PO status will change to partially confirmed. And a proper notification will
be sent to the second approver, if required.
Page 71 of 75
1723-Sep-1525-Mar-1428-Jun-
The above logic is repeated for the second and third approver (if required). If the PO is rejected on any
level of approval the notification should be sent to the creator and all approvers who already approved
PO. After the PO is fully released the PO creator will receive a proper notification. PO will receive status
C Confirmed,.
The details for the process will be described in the PO workflow functional specification
Altair_FNC_PUR_W0011_Purchase Order Approval_V0.doc.
7 Other Design Considerations
7.1 Roles and Authorizations

The roles and authorizations required for Purchase order creation and maintenance are specified
separately as part of each functional specification included in this document.
There are a number of standard SAP transactions e.g. ME21N, ME22N, ME23N, ME9F, ME2N,
ME80FN, ME28, ME29N, which are linked to pre-defined SAP authorization objects (e.g. purchase
organization, purchasing group). These transaction codes will be linked to pre-defined Publicis roles.
Roles in turn will be linked to individual users.
Detailed description on roles and authorizations concept can be found in solution manager (T.Code
SOLAR01) under:
Publicis core ERP project -> Technical Architecture and Standards -> Business Processes - > User and
Access Management ALTAIR_TEC_Transaction Level Role Breakdown
Or from within Publicis network
http://FRPARALTPSM01.edc.publicisgroupe.net:08000/sap/bc/solman/SolmanDocuments/800?_CLASS
=SOLARGEN&_LOIO=DE859A91DC56F2F1BEB1002481ABD66C&LANGUAGE=EN&RELEASE=620&I
WB_INDUSTRY=/KWCUST/&TMP_IWB_TRY_OTHER_LANG=X&TMP_IWB_TRY_OTHER_IND=X&TM
P_IWB_TASK=PREVIEW2&
7.2 Migration
Publicis requirement is to have open POs migrated to the SAP system. The PO migration plan will be
based on two files. First one is the PO migration functional specification, the second one is the PO field
mapping.
Only open (not fully invoiced, not blocked or rejected) PO will be included into input files for migration.
Migrated will be the open PO value that is a value that has not yet been invoiced.
The PO historical data like statuses, PO history, release data etc will not be migrated.
The specific country requirements and solution details have been covered in the below documents
available in solution manager:
Publicis core ERP project -> Business Scenarios -> Development -> Business Processes -> Conversions
-> C0017 - Open Purchase Orders -> Altair_FNC_PUR_C0013F_Job - Open
PO_Active_version.doc
=SOLARGEN&_LOIO=DF3CAC1F1CD9C4F1832900265518CDC6&LANGUAGE=EN&RELEASE=620&I
Page 72 of 75
1723-Sep-1525-Mar-1428-Jun-
Publicis core ERP project -> Business Scenarios -> Development -> Business Processes -> Conversions
-> C0017 - Open Purchase Orders -> Altair_FMAP_C0017_Purchase Order__Active_version.xls
=SOLARGEN&_LOIO=DF00F5757D755CF1BC8900265518CDC6&LANGUAGE=EN&RELEASE=620&I
8 Design Localizations
8.1 Mainland Europe
8.2 North America
8.3 United Kingdom
9 Open Issues
10 Reference to Other Documents
Business blueprint
Publicis core ERP project -> Business Scenarios -> Procurement ->
Altair_FNC_PUR_Procurement_V1_(pdf).pdf
http://FRPARALTPSM01.edc.publicisgroupe.net:08000/sap/bc/solman/SolmanDocuments/800?_
CLASS=SOLARGEN&_LOIO=DEC867894EC3C3F1B2A900265518CDC6&LANGUAGE=EN&RE
LEASE=620&IWB_INDUSTRY=/KWCUST/&TMP_IWB_TRY_OTHER_LANG=X&TMP_IWB_TRY
_OTHER_IND=X&TMP_IWB_TASK=PREVIEW2&
Approved Business Blue Print - Procurement .doc
CLASS=SOLARGEN&_LOIO=DEA85A34FD0B1DF1B4F9002481ABD666&LANGUAGE=EN&RE
Publicis core ERP project -> Business Scenarios -> Procurement -> Business processes ->
Purchase Order Set-up and Maintenance
Altair_FNC_PUR_Procurement_Fieldmapping_V1.doc
CLASS=SOLARGEN&_LOIO=DF22C24D578061F18ED000265518CDC6&LANGUAGE=EN&RE
Page 73 of 75
1723-Sep-1525-Mar-1428-Jun-
PO additional functionalities functional spec

Publicis core ERP project -> Business Scenarios -> Development -> Business Processes ->
Enhancements -> E0056 - Backend Data Supplier for Procurement ->
Altair_DEV_PUR_E0056_Procurement__V2.doc
CLASS=SOLARGEN&_LOIO=DF46CCBE9291B7F1B47000265518CDC6&LANGUAGE=EN&RE
PO migration
Conversions -> C0017 - Open Purchase Orders
Altair_FMAP_C0017_Purchase Order__Active_version.xls
CLASS=SOLARGEN&_LOIO=DF00F5757D755CF1BC8900265518CDC6&LANGUAGE=EN&RE
Altair_FNC_PUR_C0013F_Job - Open PO_Active_version.doc
CLASS=SOLARGEN&_LOIO=DF3CAC1F1CD9C4F1832900265518CDC6&LANGUAGE=EN&R
ELEASE=620&IWB_INDUSTRY=/KWCUST/&TMP_IWB_TRY_OTHER_LANG=X&TMP_IWB_TR
Y_OTHER_IND=X&TMP_IWB_TASK=PREVIEW2&
User interface
Publicis core ERP project -> Business Scenarios -> Development -> Business Processes -> UI
Development
UI Func Spec 05 Procurement
http://FRPARALTPSM01.edc.publicisgroupe.net:08000/sap/bc/solman/SolmanDocuments/800?_ Field Code Changed
CLASS=SOLARGEN&_LOIO=DE9DE957AFD6F7F1ACCF002481ABD66C&LANGUAGE=EN&R
ELEASE=620&IWB_INDUSTRY=/KWCUST/&TMP_IWB_TRY_OTHER_LANG=X&TMP_IWB_TR
Y_OTHER_IND=X&TMP_IWB_TASK=PREVIEW2&
Pay when paid

E0024C - AP - Pay_when_paid for estimate billing
http://FRPARALTPSM01.edc.publicisgroupe.net:08000/sap/bc/solman/SolmanDocuments/800?
_CLASS=SOLARGEN&_LOIO=DF2D3AE5C53291F18ED000265518CDC6&LANGUAGE=EN&
RELEASE=620&IWB_INDUSTRY=/KWCUST/&TMP_IWB_TRY_OTHER_LANG=X&TMP_IWB_
TRY_OTHER_IND=X&TMP_IWB_TASK=PREVIEW2&
E0024B - AP - Pay_when_paid for progressive billin
_CLASS=SOLARGEN&_LOIO=DF2D529D45EF59F18ED000265518CDC6&LANGUAGE=EN&
E0024A - AP - Pay_when_paid for Media

_CLASS=SOLARGEN&_LOIO=DEFC017489FD44F1B2A900265518CDC6&LANGUAGE=EN&
Page 74 of 75
1723-Sep-1525-Mar-1428-Jun-
Limits and Budget Control

Enhancements -> E0095 - Tolerance Limits and Budget Control -> Altair_FNC_CJO_E0095_
Tolerance Limits and Budget Control V0.doc
CLASS=SOLARGEN&_LOIO=DF0127B4700A46F1BC8900265518CDC6&LANGUAGE=EN&RE
PO creation from estimate

Enhancements -> E0008 - PO Create from Estimate -> Altair_DEV_CJO_E0008_Create
Purchase Order from Job Estimate_V0
CLASS=SOLARGEN&_LOIO=DF302D541FD2EEF18ED000265518CDC6&LANGUAGE=EN&RE
Appendix
Page 75 of 75

DDD Pur Po V1.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DDD Pur Po V1.1

Uploaded by

Copyright:

Available Formats

DETAILED DESIGN DOCUMENT

Business Process: Purchase order creation

Created by: Timothy Radlak

Last Modification by: Philippe RIVIERE Mehdi ZINE

5.1.2 Create a Purchase Order manually for a Job ............................................................................................................... 48

 Vendor Master data

2 SAP organization structure supporting the process of PO creation

2.1 Organizational chart

Company Code 103 - Legal Entity Plant 1030

2.2 Naming and numbering convention

Country Company Name of Company Purchasing Purchasing

FR F01 Publicis Net SA F011 Publicis Net F00

FR F03 Publicis Conseil SA F031 Publicis Conseil Base Agency F00

Plants will be created 1:1 with company codes.

It is an organizational for Logistics, subdividing an enterprise according to the requirements of Purchasing.

Proposed “decision table” for determination of purchasing organization:

The plant is a subdivision of an organisational unit according to production, procurement, maintenance

3 Purchase order structure and fields

3.1 Purchase order type and number ranges

The following PO types and number ranges will be used by Publicis:

PO Description Number From To

Length restriction of the lookup for the PO type

3.2 Company code and purchasing organization

Vendor master data are described into “ALTAIR_FNC_DDD_CC_VENDOR_V28.doc”

3.4 Purchasing group

A purchasing group is technically independent of the purchasing organization. It represents an employee

A purchasing group is mandatory in purchasing documents.

Proposed “decision table” for determination of purchasing groups:

Remarks on purchasing groups:

- Release strategy requirements

3.5 Payment terms

3.6 Partner functions

PO and Hedging exchange rate

User will proceed with the following steps:

 Y - Publicis Cost Centre

 X – Publicis Balance Sheet Account

In UI, account assignment category should appear at header level.

Line Account WBS Element Cost Centre GL account Item type

One PO line can have only one account assignment object.

PO Type Default Account

3.9 Item types

3.10 “Print price” indicator

3.11 Work code

Work code are described into document: ALTAIR_FNC_DDD_CC_WORKCODES_V8.doc

3.12 Purchase order pricing

This requirement is being fulfilled by creating a specific (Z*) table: ZALT_T_VEND_PRIC.

1/ Access table ZALT_T_VEND_PRIC and search for possible entries by filtering:

o “Purchasing organisation” value from the one within the PO header

See table ALTAIR_FNC_DDD_PO_APPENDIX 1_Table ZALT_T_VEND_PRIC .doc

A PO can include different plants at item level.

3.14 Alternate Delivery Address

3.15 Tax code determination

Access sequence 2 (verified as second):

301(Saatchi & Saatchi 1 - Tax V1 - VAT Input Dom

SPECIFIC (Z*) FIELDS

PO functional specifications are described into document: Altair_DEV_PUR_E0056_Procurement.doc

3.16 Delivery Dates – Actual/Planned

PLANNED DELIVERY DATE Sap solution

 Planned delivery date (Header level EKKO - Z_PDD)

 Planned delivery date (Item level EKPO- EEIND)

ACTUAL DELIVERY DATE SAP Solution

 Actual delivery date (Header level: EKKO-Z_ADD)

 Actual delivery date (item level: EKPO- LEWED)