Spaces:

stephenmccartney1234
/

LockedProjectBot1

Build error

File size: 183,114 Bytes

050b5b1

Project Concert

FDD009 – Project Systems & Time Sheets (PS & TM)
Functional Design Document
V3.00 Approved
[Publish Date]

Purpose: The objective of this document is to define the detailed functional design to meet the business requirements across the E2E business processes for Project Systems and Time Sheeting and provide a solution scope including:
• To provide the functional design including the organisational structures and configuration rational to support the E2E processes at CT as part of Project Concert.
• Document the key design decisions that underpin the functional design.
• Provide information on integrated end to end processes in within the Project Systems and Time Sheeting solution
• Document the System and Technology requirements for the Project Systems and Time Sheeting process i.e., Workflow, Reports, Interfaces, Conversions, Enhancement and Forms.

This Document will align with the processes covered in the Business Process documentation (BPD) and the process flow diagrams will provide the information on the end-to-end processes.

Scope: In scope are the detailed functional design and configuration recommendations of the end-to-end Project Systems and Time Sheeting processes covered in the Business Process documentation (BPD).
Change history
This version replaces all previous versions. Please destroy any previous versions.

Version Date/
Date approved Author
To be approved by Comments
0.2 07/01/22
Priya Bajpeyi / Chinmaya Mohapatra Initial Draft
0.2 07/03/22 Marco Desentis Changes on sections 2.0
0.2 11/03/22 Uche Nnene QA Review
0.2 22/03/11 Marco Desentis Changes on sections 2.0, 2.7 and 2.8
0.2 25/3/22 Uche Nnene QA Review of sections 03.08.06-08
0.2 28/03/22 Marco Desentis Changes on sections 2.7, 2.8 and 2.9
0.9 29/03/22 Carl Scarlett Updated to 0.9 for final review
0.98 30/05/22 Matt Allen Issuing for Approval
0.99 09/06/22 Carl Scarlett Updated for Approval Comments
1.00 09/06/22 Matt Allen Marking record of approval and baselining
2.00 15/01/23 Marco Desentis Adding scope for Easy cost planning
3.0 23/01/23 Marco Desentis Updates provided by the DA

RACI table
Function Name
Responsible: E2E Functional Leads Marco Desentis
Accountable: BPE Carl Scarlett
Contributed: SME / BDO network / Architects Enter the names of SME
Informed: Project Management Chris Fogg, John Chapamba

Document Review & Sign-off
Signatories
Role Name Comments Received Date
Sol Arch Lead Ian Triccas 09/06/22

Reviewers
Role Name Comments Received Date
BPE Carl Scarlett
BPE
BPE
SME
SME
SME

Reference documents
Nr. Document
1 L1-L3 BPML - Link

2 Consolidated Business Case - Link
3 Scope items master sheet - Link

4 CT Interface register
5 Inventory of all CT applications
6 Inventory of all CT Teams
7 High Level Design Document (HLD)
8 Business Process Design Document (BPD)

Abbreviations
Abbreviation Description
BPD Business Process Design
BU Business Unit of JM
UP Unify Programme
IR Invoice Receipt]
LIV Logistics Invoice Verification (SAP sub module)
P-Card Procurement card
PO Purchase Order
PR Purchase Requisition
RICEFW Reports, Interfaces, Conversions, Extensions, Forms, Workflows
RTM Requirements Traceability Matrix
SME Subject Matter Expert
PS Project System
RA Result Analysis
PS Project system
TM Time management
TS Timesheets
Contents
Change history 2
Contents 4
1. Business Process Requirements 6
1.1. Business Process Area Introduction 6
1.2. Business Process Requirements 6
1.2.1. Business scope items 6
1.2.2. Business requirements 8
1.3. Design Options 11
1.3.1. Business Requirement: Interface between SAP and Workday 11
2. Functional Solution Design 11
2.1. Project System and Time Management Overview 11
2.1.1. SAP Project System Structure 12
2.2. Maintain Project Definition and Structures 16
2.2.1. Introduction 16
2.2.2. Develop project policy and procedure 17
2.2.3. Project Profile 25
2.2.4. Project Type 28
2.2.5. Project Number 30
2.2.6. Create and maintain Work Breakdown Structure (WBS) and Networks 31
2.2.7. Project Template and Master Data Maintenance 37
2.2.8. Maintain and configure project TEMPLATES & Networks. 44
2.2.9. User Fields in projects - Segmentation 45
2.2.10. Person responsible 47
2.3. Project East Cost Planning (ECP) 50
2.3.1. Planning at Activity Level 58
2.3.2. Planning at Cost element Level 59
2.4. Project Budgeting 61
2.4.1. Original Budget 65
2.4.2. Budget Update 66
2.4.3. Supplements 66
2.4.4. Transfers 66
2.4.5. Returns 66
2.4.6. Budget Release 66
2.4.7. Availability Control 67
2.4.8. Configuration: 67
2.4.9. Standard Reports on Budget 68
2.4.10. Year-End Functionality in Budget and Commitment Carry Forward 68
2.5. Capture Project Costs & Timesheets 69
2.5.1. Finance integration 70
2.5.2. Timesheet allocation 73
2.5.2.1 Maintain HR Mini master 73
2.5.2.2 Maintain CATS Profile 77
2.5.2.3 Enter and Approve Time 82
2.5.2.4. Time administration 85
2.5.2.5. Intercompany projects timesheet allocation 88
2.5.2.6 Converting Time to Cost 89
2.5.2.7. Timesheet reporting 90
2.5.3. Integration with procurement 93
2.5.4. Integration with Sales 94
2.6. Capture Project Revenue (Billing) 95
2.6.1. Maintain Policy and Procedures for revenue recognition 95
2.6.2. Milestone billing for revenue projects 95
2.6.3. Account revenue recognition (Result Analysis & POC and PIT) 100
2.7. Project Monitoring 110
2.7.1. Scope 110
2.7.2. Integration with Primavera 110
2.7.3. Integration with Tableau (R&D) 113
2.7.4. Integration with KeyedIn 113
2.7.5. Integration with Workday 115
2.8. Project Period End/Year close 116
2.8.1. Introduction 116
2.8.2. Perform Result Analysis 117
2.8.3. Perform Project Settlement 117
2.8.4. Year-end close in projects 119
2.9. Project Reporting 119
2.9.1. Analysing Projects with the standard Information Systems 119
2.9.2. Analysing Projects with Financial Reports 120
2.9.3. Standard Reports Available in Time sheeting 121
2.9.4. Project reporting for segmentation 121
2.9.5. Forecasting report & Cost report (Licensing) 124
2.9.6. Forecasting report & Cost report (Formox) 126
3. Technical and Development Related Items 127
3.1. Workflow - Fiori 127
3.2. Report 128
3.3. Interface 128
3.4. Conversion 129
3.5. Enhancements 130
3.6. Forms 130
3.7. Modifications 130
4. Appendix 131
4.1. Segmentation 131
5. Design Authority Board (DAB) Work Package Sign-off 134

1. Business Process Requirements
1.1. Business Process Area Introduction
The processes “Project Systems” and “Time Sheeting” are end-to-end business operations that involve the creation, planning, budgeting, cost collection, man hour recording, monitoring, reporting, and closing of projects etc.
The scope of this document is to identify the to-be high-level processes within the defined business context. It identifies the standardised functional and process design across the JM Catalyst Technologies (CT) sites. Where there are site-specific variations in the design this will be highlighted as part of this document.
The sites impacted as part of this process are captured in this document, including details of variations and significance of change per site. This FDD only covers those upstream and downstream processes which are designated ‘Project System & Timesheets’.
1.2. Business Process Requirements
Project systems (PS) and Time Management (TM) related requirements have been captured in two phases, High-Level Design and Detailed Design. Below is the consolidated list of requirements based on Level 2 Process.
1.2.1. Business scope items
Detailed process requirements are captured below.:
Table 1
Business Process Requirements
ID Requirement Description Business Criticality (MoSCoW) Fit To Standard (1-4) Solution Design
PS/TS_BR001 Percentage complete calculation of Revenue Recognition automation [Improvement] Critical 4 SAP will provide several methods to perform revenue recognition.
Two main methods will be supported:
•POC – Percentage of completion
•PIT – Point in time
These methods will be available to every business.
PS/TS_BR002 The requirements are to setup HR mini master and Time sheet (CATS) module to capture employee timesheet/effort. Also consider alternatives such as Workday, KeyedIn, etc. [Consolidation] Critical 4 In SAP there will be an interface between the corporate HR system, Workday, and SAP HR.
With this interface, the Licensing, Formox Plant Designs and R&D business will be able to process employee timesheets on a weekly basis.
The main benefit will be the centralization of the processing of timesheets through one main system.
PS/TS_BR003
Requirement for using Projects, replacing Internal Orders. Budget tracking currently manual process. [Consolidation] Critical 4 PS will replace the current use of Internal Orders by the Formox Plant Designs business.
PS will improve the scope of the size of projects managed and PS will provide a strong platform to manage complex projects.
PS/TS_BR004
Not all sites currently integrate with Concur across CT sites to enable uniform management of expense payment.
Also, CO objects (i.e., Projects, Cost centres) will need to be integrated with Concur Critical 4 Travel expenses will be integrated with PS, to allow the different businesses to submit travel expenses to be approved and costs to be allocated and reflected in the projects.
This mechanism will provide visibility of the costs allocated on projects related with travel expenses.

1.2.2. Business requirements
Detailed process requirements are captured below:
Table 2
Business Process Requirements
ID Requirement Description Criticality FTS (1-4) Solution Design
BR001 Requirement to use SAP Project Systems for all Capex, R&D, Opex and revenue project works. Use of Capex/Opex requires confirmation. Must Have 4 2.1.1
Note: Capex projects are out of the scope.
BR002 Requirement for using Projects, replacing Internal Orders. Budget tracking currently manual process. Must Have 4 2.1.1 / 2.1.2
Note: Limited to the businesses described in this document
BR003 Requirement to have a standard time sheeting solution to capitalise engineering time and tech service time. Must Have 4 2.5.2
BR078 The requirement is to setup HR mini master and Time sheet (CATS) module to capture employee timesheet/effort. Also consider alternatives such as Workday, KeyedIn, etc Must Have 4 2.5.2
BR113 Introduce a flexible and user-friendly portal for recording the time. Explore the option to fill the time sheet on a mobile device. Must Have 4 2.5.2
BR114 Ability to enter the time sheet without the requirement for an SAP user ID Must Have 4 2.5.2.3
BR115 Ability to approve the time sheets. Must Have 4 2.5.2.3
BR116 Ability to manage change management comms when a role of a person changes. Must Have 4 2.5.2.1
BR117 Introducing a central policy for time sheeting Must Have 4 2.5.2.5
BR118 Ability to set up multiple layers of activity rates based on the role. Internal and external rates.
Salary rate
Payroll Burden rate
Overhead Recovery rate Must Have 4 2.5.2.4
BR119 Ability to generate time sheet reports for various purposes Must Have 4 2.5.2.6
BR120 Interface to Workday for activity rates Must Have 3 2.5.2.1 /
2.5.2.4
BR121 Project for maintenance type activities need to be confirmed with PM functional team Must Have 4 Out of scope
BR122 Interfaces required to external project management / planning tools i.e., Primavera, ProMap, MS Project, KeyedIn, SQL for forecasts Must Have 4 2.7
BR123 Current 4-digit coding for projects are used across multiple systems & templates. It would be preferential to retain this numbering alongside SAP projects coding (This applies for Licensing projects) Must Have 4 2.2.1 / 2.2.2
BR124 Projects will need to settle to assets, cost centres, COPA Must Have 4 2.8.2 / 2.8.3
Settlement to assets is out of the scope
BR125 Improvements needed to CONCUR interface for master data updates so that resources can book expenses to live projects or not book to closed projects Must Have 4 Out of scope
BR126 Projects can be closed with outstanding technical provisions. TECO may be applied after accruals for outstanding invoices. Policy & controls are required to prevent open-ended projects Must Have 4 2.2.1 / 2.8.2
BR019 Extension to existing or addition of new payroll interfaces or journal load for consolidated entities Must Have 4 Out of scope
BR132 Requirement for time sheeting outside of Licensing/R&D/Formox Plant Designs needs a proper review as it could involve other sites if confirmed as being needed for CAPEX projects or Technical Services Must Have 4 Out of scope
BR021 Automate Revenue Recognition based on percentage completion in revenue projects Must Have 4 2.6.4
BR148 Requirement for 'open project' / project status report to ensure old projects can be closed Must Have 4 2.2.1 / 2.2.2
BR157 Tableau Must Have 4 2.7.3
BR158 Intercompany Must Have 4 2.4
BR159 Proposals/Forecasting Must Have 4 2.2.1 / 2.9.6
BR160 CAPEX Must Have 4 Out of the scope
BR161 Early Work Must Have 4 2.9 / 2.9.6

1.3. Design Options
1.3.1. Business Requirement: Interface between SAP and Workday
This section captures business requirements for the creation of an interface between SAP HR and HR Workday.

Proposal Description: Interface between HR Workday and SAP HR
Business Value: The main value added to the business will come by the fact that every employee from CT, will be able to process timesheets and allocate their time into a project or multiple projects.
Benefits: With the enabling of this integration every employee from the CT business, will be able to process timesheets for multiple projects.
The user will be able to allocate their time using their SAP user through a Fiori interface and from any browser.

Preferred Solution and Justification:
To allow the employees from CT business to process their timesheets it will mandatory the construction of the SAP HR-Mini master, that will contain the basic information from the employees that will be used with the Fiori interface to process their timesheets. Transferring this information from Workday to SAP through an automated interface will ensure that the SAP data is updated whenever a change occurs with Workday remaining as the master HR record system.
2. Functional Solution Design
2.1. Project System and Time Management Overview
SAP Project System (PS) is a part of SAP’s Project and Portfolio Management solution. Project System will support the process to control and manage projects throughout the entire project lifecycle in the Licensing, R&D and Formox Plant Design parts of the Catalyst Technology (CT) business, from the creation of a project to the preparation of detailed plans, project execution and completion.
Due to its tight integration with SAP’s Finance and Logistics modules, the SAP PS Module will be used especially for large and complex projects in the Licensing and Formox businesses and will support the following types of projects:
• Externally financed projects
o Customer (revenue) projects

• Internally financed projects
o Overhead cost projects
As well as implementing Project System, Time Sheeting will be implemented for these businesses as part of the scope of project Concert. This is key to managing projects for the businesses concerned, as the major resource for projects is people and hence the tracking of manhours and the associated costs is necessary.
The administration and management of CAPEX projects is not included as part of the scope of project Concert for Project System and Timesheets.

One of the strengths that SAP PS will provide to JM CT as a project management tool, is that it is integrated with other SAP modules as shown in the image below, and it can be integrated with other external non–SAP project management tools such as Primavera and Keyed In.

There will be an interface between SAP PS and Primavera, however this will be performed manually through the interchange and upload of a “flat file” (excel) between both systems; Project Concert is not considering the setup of the standard SAP connector between both applications.
In simple terms, the user will generate, extract and download the information from SAP into an Excel file and to their “C:” drive and then this same file, will be uploaded into the Primavera, following the current process performed by the user.
This interface will be explained in detail in section “2.7 Project Monitoring”.
Integration with MS Project is not part of the Project Concert scope.
2.1.1. SAP Project System Structure
The Enterprise Structures described in this section are the major entities related to the Project Systems process. The Project System has no organisational structures of its own; but is incorporated into the organisations existing structure by making assignments to the org units in Accounting and Logistics.
In simple terms, every time a project is created, it will be assigned to a:
• Company Code - If a Company Code is entered here, it must belong to the Controlling Area.
• Controlling Area – (KAT1) - If an entry is made here, the Controlling Area Currency is defaulted as well.
• Plant - If Plant is entered here, it must be associated with the Controlling Area/Company Code. Note that the plant entered here does not influence Networks, only WBS Elements.
• Profit Centre - If Profit Centre entered here, it must be associated with the Controlling Area/Company Code.
• Project Currency - Generally, currency is determined by either the Controlling Area, the object being used (WBS, Network) or Transaction. If a Company Code was entered in the Project Profile, it will set to the default currency, but you can override it by entering a valid currency here.
This will guarantee that all the costs and revenues allocated into the project during the normal life cycle, will be reflected into the correct P&L and Balance Sheet of business that is managing the project.
These key parameters will be predefined in the “project profile”, that is described further in section 2.2.3 of this document.
The following key objects and assignments are defined below and will be used for the creation of projects:

Project system main structures to be used (definitions):
The following table describes the main structures that will be available for the different CT businesses, to create and organise the structure of projects.

Structure Description Existing / New
Project definition Top level of a project that holds general project information that applies to the whole structure including the project profile, person responsible (PM), financial information. New
WBS elements Components/parts of the project that can be used to split the project work. Cost/revenue collectors for the project. New

Network Header Higher level network used to group together several networks/tasks. Used for reporting purposes only. New

Network activities Represents a task or a group of activities within a project and are used to plan, analyse, control, and monitor schedules, dates, and resources. Internal/external activities and pieces of work that are needed to complete a network task. New

Milestones Represents key dates/progress on a project and can be related to billing for customer projects. New

Material components Procurement of internal or external goods/services required to complete the network task(s) New

Example:

This will allow the different businesses to assign parts of the phases of a project into different organisational structures.

Note: the structures mentioned above have been explained in detail in the Record to Report (RTR).
FDD – (refer to FDD003)

SAP Time sheeting and Personnel structure
For the implementation of timesheets, it is necessary to setup the following structures to administer employee data and manage timesheet processing.
• Company Code
Company Code is the smallest organisational unit of Financial Accounting for which we draw individual financial statements like Balance Sheet and Profit & Loss Account for purpose of external reporting (e.g., GB30, GB35 – Licensing & R&D business). It is identified by a 4-character alphanumeric code.
• Personnel Area
PA represents a subdivision of the company code. It is identified by a 4-character alphanumeric code, same as the company code (ex. GB35). The personnel area is assigned to a unique company code. The Personnel Area is also used as selection criteria for evaluations and used in authorisation checks
• Personnel Sub Area
A personnel subarea is an organisational entity which represents part of a personnel area characterized by personnel administration, time management, and payroll criteria. Each Personnel Area can have multiple personnel sub areas.
• Employee Group
The employee group is an organisational entity which is governed by specific personnel regulations. An employee group is divided into several employee subgroups. It is identified by a 1-character alphanumeric code. (e.g., Active, Terminated, Inactive, Contractor, Expatriate, Inpatriate)
• Employee subgroup
An employee subgroup is an organisational entity within an employee group which is governed by specific personnel regulations. (e.g., Salaried, Hourly). It is identified by a 2-character alphanumeric code.
• Cost Centre
Cost centre is a location where the costs occur inside the organization. Cost centre is the lowest organisational unit in controlling enterprise structure. Cost centres are areas of responsibility for costs within an organization and used to capture actual costs of an organization. The RTR team will be providing details of Cost Centre.
• Organisational Unit
Organisational units are functional units in an enterprise. According to how tasks are divided up within an enterprise, these can be departments, groups, or project teams, for example. Organisational units differ from other units in an enterprise such as personnel areas, company codes, business areas etc. It is identified by an 8-character numeric code.
• Position
A position is assigned the characteristics and attributes of a job. Positions are assigned to organisational units and are linked one to the other, they are linked using tables HRP1000 and HRP1001. It is identified by an 8-character numeric code
Note: The definitions of the above will be confirmed once the conversations with Workday and HR take place.

2.2. Maintain Project Definition and Structures
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.02 Maintain Project Definition and Structures
• 03.08.02.01 Develop project policy and procedure
• 03.08.02.02 Create and maintain projects
• 03.08.02.03 Project template maintenance
2.2.1. Introduction
The project structure within SAP Project System allows the business to allocate and process all the information related to the execution of a project lifecycle. The project structure helps the business represent the different parts, phases and activities required to deliver a project.
Several templates will be developed to support the delivery of projects by the following parts of CT:
• Licensing business
• Formox business
• R&D business
• CAPEX projects are not included in the scope of PS&TM and will not be included at this time
The following 4 main structures in projects (PS) will be used in the templates for the businesses mentioned above.
Main structures:
• Project definition
• WBS elements
• Networks and activities
• Milestones
These structures will enable the business to standardaise the approach to creating, monitoring and excecuting projects within CT.
It is intended to move towards common project numbering and structures across the CT business.
The Project Definition is a general description of the project that you want to manage. It is a framework laid down for all the objects created within a project. It contains organisational data that is common across the entire project
The following table explains the main structures that will be used per business to create their project structures or what will be known in the future as “Operative projects”.

Business Proj. Definition WBS elements Networks/activities Milestones
Licensing In scope In scope In scope In scope
Formox In scope In scope Out of scope Out of scope
R&D In scope In scope Out of scope Out of scope

With the implementation of this project module in SAP, the JM CT businesses that are moving into PS/TM will be able to consolidate and manage their projects under the same process.
The definition of each of these structures will be explained in more detail in the following sections of this document.
2.2.2. Develop project policy and procedure
A unique policy and procedure has been developed to set up the Coding mask which helps display complex project numbers and indicate the position of a WBS element in the hierarchy.
Project Concert will use the project coding nomenclature established by Unify to identify projects as far as possible, however some deviations are required.

The project code has a length limit of 24 digits. The Unify project code is shown below:

For Project Concert, CT requires a slightly modified project code to enable the use of more levels in the WBS hierachy. This is necessary to enable the appropriate project structure to be used for the Licensing part of the CT business.
The project code being used by Project Concert is as follows:

The Country code has been removed from the Unify project coding structure to allow for the extra WBS level needed by CT. This is required as the UNIFY code was not created with the ability to support the delivery of complex engineering projects, like those delivered by the CT Licensing business. The country will be identified by the company code that is assigned at WBS element level. The list of company codes has already been described on the RTR FDD document.

Project Coding Mask
For Project Concert, we will specify the masks and the special characters for editing the project number. We will set up Project Systems so that the project number can be broken into sections via special characters.
The way this number is structured depends on the first characters of the project number. These characters are used as keys for project coding.

Special character for Project Coding Mask
In table V_TCJ01, we will maintain a special character,this will specify how a project number is coded for editing. The following parameters will be used for editing the project number:
As per Unify,’.’, will be used as separator.

Example:
24 Digit Project Coding Structure
R . L I . 0 0 2 5 2 7 . E N G . 1 0 . 1 0 . 1 0

Define project coding Mask
1. The coding mask will be created on the SAP transaction: T-code OK02
2. The project coding mask created here will be used during the creation of the project definition and WBS elements.
3. The Coding mask will be X.XX.XXXXXX.XXX.XX.XX.XX
4. The new mask will have a length of 24 digits, with a “.” to separate each section of the code
5. The new project code will have a mix of characters between numeric values and character values
6. The Country has been excluded from the original project code adopted (UNIFY programme) and this will be managed by the company code (every standard report in SAP PS&TM has this selection parameter available)
Key points of the business solution:
1. Unify Project Profiles will be retained as appropriate.
2. Unify Project Types will be retained and where appropriate project types from Unify will be used with some new project types created.
The following tables describe the coding proposal in detail to manage and describe projects in JM CT.
Note: the final proposal will be refined during the build phase. It has been decided not to use the technology specific codes implemented in Unify as this would require a significant number of additional codes.
Notes:
• CT is implementing Segmentation tagging of projects using User Fields.
• CAPEX projects are not considered in the scope of Projects and Timesheets; CAPEX projects will be continue being managed using Internal Orders as per the current approach in CT.
Intercompany allocations:
There will be two types of process defined in the system that will produce and intercompany allocation for the different CT businesses:
a) Intercompany allocation timesheets – for this case a user (employee, engineer) that belongs to the business unit FORMOX (example), will be able to charge hours via timesheets to a project that belongs to a different CT business like Licensing Davy (example).
a. It has been established with the RTR workstream that the CT profit centres defined, will be able to receive postings from different company codes (businesses).
b. This change in the master record of the profit centre will allow to users from different businesses to allocate time into projects that belong to different business units.
c. Example:

d. Once a month, every business will be able to review and know in detail, the hours that have been assigned into projects that do not belong to their business and then proceed to invoice these hours to the business unit that requested this work.
e. This reconciliation processes have been described on the BPD and FDD from the RTR workstream.

b) Intercompany contracts – for this case, there can be a situation where there is a project already signed with the client, where the works will be delivered by Davy (example), but PLC (example) will be the entity that holds the contract.
a. For these cases, there will be a specific WBS element in the structure of the project, where the organizational structures will be pointing to PLC, so the Sales order will be raised against this WBS element and once a milestone is achieved, PLC will invoice to the client and Davy will invoice to PLC.
b. This has been explained in more detail in section 2.5.2.5. Intercompany projects timesheet allocation.

24 Digit Project Coding Structure - with Country Code removed
R . L I . 0 0 2 5 2 7 . E N G . 1 0 . 1 0 . 1 0
Project Profile: Type of Project
C JM CAPEX Project Profile Retain Unify codes
O JM OPEX Project Profile Retain Unify codes
R JM Revenue Project Profile Retain Unify codes
H JM Hybrid Project Profile Retain Unify codes
Project Type
Initial assumption, align with Unify, but will require additional types
C = Type required for Concert.
U = Existing Unify Type
GREY indicates not intended to be used in Concert and not to be created during build

C U Type Description
x A L Analytical Labs
x A M Ammonia
x C 1 Customer Revenue Project with WIP
x C 2 Customer Revenue Project without WIP
x D B Distribution and selling
x D V Development
x E H EHS
x E M Engineering & Maintenance
x E V Environmental
x F I Finance
x F L Facilities
Y F X Formox
x H R Human Resources
x I 1 IT – Clean Air specific
x I 2 IT - Corporate specific
x I 3 IT - Health specific
x I 4 IT - ENR specific
x I 5 IT - New Markets specific
x I 6 IT – Battery Materials specific
x I R IT - R&D specific
x I T IT - Global (non sector specific)
x L E Legal
Y L I Licensing (Davy)
x L W Logistics & Warehousing
x M 1 Manufacturing – Clean Air specific
x M F Manufacturing - Global (non-sector specific)
x O A Oxo Alcohols
x O F Office
x P C Production
x P D Product Development
x P R Procurement
Y x P S Proposal
x Q A Quality Assurance
x R 1 R&D – Clean Air specific
x R 2 R&D - Corporate specific (Innovator)
x R 3 R&D - Health specific
x R 4 R&D - ENR specific
x R 5 R&D - New Markets specific
x R 6 R&D – Battery Materials specific
x R C R&D - Corporate specific (excl Innovator)
x R D R&D - Global (non-sector specific)
Y R 7 R&D - CT specific
Y R K R&D - CT KeyedIn Project
x S N SNG

Codes for WBS level 2:
WBS L2 - Core Activity (Contracts)
C S 0 Catalyst Supply
E N G Engineering
E Q P Equipment Supply
E X C Execution (Formox specific)
J M 0 Used as bucket for JM Plc
L F 0 License Fee (Licensing Project specific)
a b c Numeric coding for proposals etc.
W a b R&D KeyedIn Workstreams - use W01, W02
Note actual unique workstream number will need to be stored in user field

Codes for WBS level 3:
WBS L3 - Work Orders (Equivalent)
L3 used by Licensing projects, studies and plant upgrades and R&D, not currently used by Formox
1 0 PDP - below ENG
2 0 Post PDP - below ENG
4 0 Training - below ENG
5 1 Meetings - below ENG
5 5 Site Services - below ENG
5 8 Home Office Support - below ENG
C A Catalyst Supply may need a WBS element
Note: depends on the contract arrangements and activities
E A Equipment Supply will need at least one L3 WBS element
Note: number of WBS elements will depend on equipment supply scope
0 1 R&D Manhours
0 2 R&D Costs

Codes for WBS level 4:
WBS L4 – Disciplines
L4 used by Licensing projects, studies, and plant upgrades, not currently used by R&D or Formox
L4 discipline codes repeat across the different L3 elements
1 0 Design Engineering
2 0 Process Engineering
3 0 R&D
4 0 Projects
6 0 Others

Codes for WBS level 5:
WBS L5 - Functions
L5 used by Licensing projects, studies, and plant upgrades, not currently used by R&D or Formox
L5 functions need to be aligned to the relevant disciplines, see reference below
1 0 Engineering Management part of Design Engineering (L4. 10)
1 3 Procurement part of Design Engineering (L4. 10)
1 4 Vessels & Heat Exchangers part of Design Engineering (L4. 10)
1 5 Mechanical part of Design Engineering (L4. 10)
1 6 E&I part of Design Engineering (L4. 10)
1 7 Piping/Layout part of Design Engineering (L4. 10)
1 8 Civil/Structural part of Design Engineering (L4. 10)
1 9 Fired Equipment part of Design Engineering (L4. 10)
2 1 Process Design part of Process Engineering (L4, 20)
2 2 Systems Design part of Process Engineering (L4, 20)
2 3 Commissioning part of Process Engineering (L4, 20)
2 5 Process Detailed Engineering part of Process Engineering (L4, 20)
2 6 QA part of Others (L4, 60)
3 0 R&D part of R&D (L4, 30)
4 0 Project Management part of Projects (L4, 40)
4 1 Project Engineering part of Projects (L4, 40)
4 2 Project Controls part of Projects (L4, 40)
6 1 Secretarial part of Others (L4, 60)
6 4 Office Services part of Others (L4, 60)
7 0 Accounts part of Others (L4, 60)
9 0 Business Services part of Others (L4, 60)
2.2.3. Project Profile
The Project profile will be defined to maintain default values and control parameters like planning methods for costs, planning and budgeting. The information entered in project profile is copied to a project in project definition and in the WBS elements during the creation of the project.
In essence, the project profile will contain a series of sub-profiles and parameters associated to the project, that will rule how specific functionality will work in a project, like settlements, planning, budgeting etc.
The following information will have to be maintained under project profile section.
1 Basic data
2 Time scheduling
3 Costs/revenues/finances
4 Organisational data
In Project Concert, the project Coding Mask will be used to create a structure for the project number. The structure will help in displaying complex project numbers and indicate the position of a WBS element in the project hierarchy.
The structure of the code will follow the coding masks defined on the section 2.2.2 of this document.
The project profile contains default values and other control parameters such as the planning method for dates and costs. The data that you enter in the project profile will be copied into a project in its project definition or in the WBS Element which can later be overwritten.
Project profiles will be created using Transaction Code – OPSA. Below are the fields which must be updated during the setup of the project definition.
• Project profile − Enter the unique ID that identifies project profile in SAP system.
• Controlling Area − Controlling area belongs to project profile
• Company Code − Company code that belongs to controlling area
• Plant − Enter plant code belongs to company code
• Profit Centre − Enter profit centre belongs to controlling area
• Project Currency − Enter project currency

Project Profile Project Profile Description Existing / New
ZRD001 Project Profile for R&D New
ZFOR001 Project Profile for Formox New
ZLIC001 Project Profile for Licensing New
ZNC001 Non Chargeable projects New
ZLP001 Project Proposals New
The configuration of the project profiles will be made in the following transaction:
T-code: OPSA in the configuration menu in SAP Tcode: SPRO

Validations & substitutions
As it has been commented before, there no additional validations and substitutions considered to be customized at project definition level or at WBS elements.

As part of the setup of the project profile, there are 4 main key sub-profiles that will be configured on a 1 to 1 relationship, this means there will be one of this sub-profiles created for every project profile already defined.

The following subprofiles will have to be created to allow the performance of cost planning scenarios, revenue recognition and financial settlements.

Items out of scope:
• Planning tables in SAP will not be availalable for any user from the different CT businesses, because the planning of a project will be perfomed outside of the system; This means that this configuration will be not customized for the any of the CT businesses.
• The different automatic planning functions in PS for dates are out of the scope of the current solution. Any dates that the business require to update in the project, will have to be updated and changed manually by the user.
• Example:

Sub-profiles Description
Planning profile The planning profile establishes the control parameters for planning costs. The profile determines planning aspects like:
• Time horizon – start year, total/annual values
• Format - Decimal places and scaling factor
• Availability control parameters – annual/ total budget
• Currency translation - Exchange rate type
The configuration will be explained in detail on section: 2.3 Project Planning.

Budget profile The budget profile establishes the control parameters for budgeting. The profile determines the budgeting aspects like:
• Time horizon – start year, total/annual values
• Format - Decimal places and scaling factor
• Availability control parameters – annual/ total budget
• Currency translation - Exchange rate type
The configuration will be explained in detail on section: 2.4 Project Budgeting.

Result analysis key The Result Analysis Key (RA Key) is a control parameter that determines the method used by the system to calculate Percentage of Completion (POC) and Revenue recognition. The key is assigned to a WBS element and is part of the project profile.
When a RA Key is present in WBS it becomes Result Analysis relevant. The method assigned to RA Key will be considered when Result Analysis is executed.
The configuration will be explained in detail on section: 2.6 Capture project revenue.

Settlement profile In a project, the project can collect cost and revenues during a period which then must be settled (transferred) as part of period end processing. The settlement profile stored in the project profile or network type, sets the rules used to determine whether settlement is required, allowed, or blocked.
The configuration will be explained in detail on section: 2.8 Project Month/Year end process.

These profiles will be defined at WBS Element level and will be copied from the templates into the operative project. By exception the user will have the option to change these if this required via transaction CJ20N.
Note:
The functionality of “stock on projects” is not considered as part of the scope defined for CT projects. The reason being all the products consumed by CT projects are purchased, so products are not taken from an existing inventory and when they are purchased, the products are received directly into the project.
2.2.4. Project Type
A number of project types have already been defined by Unify and where appropriate these will be used by the Licensing, Formox and R&D business. At this stage the core project types are identified in the table below. Some project types may be required, this will be confirmed during review of the existing open projects that need to be transferred from Agresso to SAP. Some project types will not be required but are documented here to ensure that existing Unify project types are not reused for other purposes on the CT SAP system.
Project types will be created using Tcode-OPSO,

Project Type Description Existing/New to CT Required Configuration Source
AL Analytical Labs New No Unify
AM Ammonia New No Unify
C1 Customer Revenue Project with WIP New No Unify
C2 Customer Revenue Project without WIP New No Unify
DB Distribution and selling New No Unify
DV Development New No Unify
EH EHS New Yes Unify
EM Engineering & Maintenance New No Unify
EV Environmental New No Unify
FI Finance New No Unify
FL Facilities New No Unify
FX Formox New Yes New
HR Human Resources New No Unify
I1 IT – Clean Air specific New No Unify
I2 IT - Corporate specific New No Unify
I3 IT – Health specific New No Unify
I4 IT - ENR specific New No Unify
I5 IT - New Markets specific New No Unify
I6 IT – Battery Materials specific New No Unify
IR IT - R&D specific New No Unify
IT IT - Global (non-sector specific) New No Unify
LE Legal New No Unify
LI Licensing (Davy) New Yes New
LW Logistics & Warehousing New No Unify
M1 Manufacturing – Clean Air specific New No Unify
MF Manufacturing – Global (non-sector specific) New No Unify
OA Oxo Alcohols New No Unify
OF Office New No Unify
PC Production New No Unify
PD Product Development New No Unify
PR Procurement New No Unify
PS Proposal New Yes Unify
QA Quality Assurance New No Unify
R1 R&D – Clean Air specific New No Unify
R2 R&D - Corporate specific (Innovator) New No Unify
R3 R&D – Health specific New No Unify
R4 R&D - ENR specific New No Unify
R5 R&D - New Markets specific New No Unify
R6 R&D – Battery Materials specific New No Unify
R7 R&D – CT Specific New Yes New
RC R&D - Corporate specific (excl Innovator) New No Unify
RD R&D - Global (non-sector specific) New No Unify
RK R&D - CT KeyedIn Project New Yes New
SN SNG New No Unify
Note:
The codes from the previous table marked with “Yes” on the column required, have been confirmed to be used by the CT business during the definition of the project number.
The rest of the codes are currently used by Unify and are not intended to be created at the initial set up for Concert. They should be kept aside in case they are required at a future time and these codes not used if any additional Concert specific codes are required to avoid conflict with Unify.
Regarding the standard field in SAP “project type”, its use for the different CT businesses will be determined during the realisation phase.

2.2.5. Project Number
The project number will follow the guidelines given below for different project types. This is to align with existing numbering already presented to the CT businesses.

Licensing (JM Davy) projects will be numbered using a 4-digit number preceded by 00 (XX according to the mask defined). This aligns with the existing 4-digit numbering used in the Licensing business. Example: Existing project 2543 will be numbered as 002543. The 4-digit number will allow the large number of existing document templates used in Licensing to continue to be used. Studies and Plant Upgrades will also use the same 4-digit numbers preceded by 00 but with a different project type detailed in the text Project Type field in the Root WBS element. The Project Type text field options will include:
• Licensed Technology Project
• Plant Upgrade
• Study
The Project Type code in the coding will remain LI.
Licensing Proposals will use a 5-digit number preceded by a L and the Project Type code PS. This allows other business to use the same Project Type code (PS) and incorporate a different leading letter in the future. At this stage only L will be used for Licensing proposals. There is the option of using the Project Type text field in the Root WBS element if required as per Licensing projects.
Formox Plant Design projects will be numbered using a 3-digit number preceded by 000. This aligns with the existing 3-digit numbering used in the Formox business. Example: Existing project 218 will be numbered as 000218.g
R&D projects that are in KeyedIn (NPI & PIM projects) will use a 6-digit number which will align with that used in KeyedIn. Where necessary leading zeros will be added to make the project number 6 digits long. Example: Existing project PRJ1985 will be numbered as 001985. For R&D projects in KeyedIn, the full KeyedIn project number including programme number will be captured in a User Field in the Project Definition, e.g., 0521-PRJ1985 would be stored in the User Field for this example project. Any reference to a workstream number will be stored in a User Field in the appropriate WBS element.
Segments: All projects will be tagged with a Segment code. This provides an indication of the market segment that the project is associated with. This combined, where appropriate, with the customer will enable projects to be reported based on market segment. The segments are detailed in the BPD.
Other Activities will require projects to be set up to provide a cost element for time to be booked to. The structure and numbering of these are expected to be simpler and needs further development.
2.2.6. Create and maintain Work Breakdown Structure (WBS) and Networks
With the WBS elements, the business wi]ll be able to represent simple or complex project structures in the system.
The WBS elements will be used on the operative projects as cost collectors and will come from the “project templates” defined (see section 2.2.7 Project template and master data maintenance). The WBS elements will also collect information related with planning and budgeting and schedule dates per WBS and activities.
The WBS elements will be created on the SAP transaction Project Builder Tcode: CK20N.

On this transaction the user will be able to model and tailor the final version of the their operative project.
The nomenclature and use of each WBS element has been already documented on the project template section of this document.

User status
Apart from the System status, SAP has the option of using User Statuses for all the projects. User Status is defined by the user to enable more statuses for the same document in addition to the existing System statuses.
For CT, the set of user statuses at Project definition level and at WBS element, will be defined during the build phase because there is not enough information currently, to deterrmine the best case and most effective way to use it.

Maintain network profiles
The Network Profile is an important configuration object to control and use network headers and activities in the project structure. In JM CT we are creating only 1 network profile for the Licensing business.
It has already been established and confirmed that only the Licensing business will integrate Networks and activities on their project structures.
The Formox and R&D business will manage their projects only at project definiton level and WBS element levels (according to the templates already defined).
The network profile will contain default values and parameters for controlling the processing of networks, such as control keys for activities.
The data which we will enter here in the network profile is copied into the header, activities, and activity elements when you create a network. You can overwrite these values in each new network.
As part of the current design and scope defined, the following network profile will be created:
Network Profile Network Profile Description Existing / New Sites
ZLIC001 Network Profile for Licensing New Only Licensing

There are 3 main sections to be configured in the Network Profile:
• Network
• Graphic
• Activities

Network - Key configuration parameters (in scope):
Field Description In scope
Network type For Licensing a network type will be set up, and an also a new control key.
The key configuration of this control key will be explained below. In scope
Summarisation This indicator will help to specify the activities in the networks with activity account assignment, that will have to be considered in project summarisation
In scope

Control Key
One important requirement from the business is the closing of the activities without the need to perform a “notification” on each activity. It will be necessary to create the following new control keys to plan “internal activities” and “external activities”.
Control key Network Profile Description Existing / New Sites
ZPS1 Network Profile for Licensing (internal) New Only Licensing
ZPS2 Network profile for Licensing (external)
General Costs New Only Licensing
These control keys will have the option to allow the user to close a network, without the need to confirm each activity.

Notes:
• Planning – The licensing business has decided to perform all the planning (time) outside of the system, so this is not considered in the customisation of this functionality in SAP.
• MPR integration – This is not part of the requirements, and this integration will not be customised, the PR and PO’s will be created manually by the user.
• Validations and Substitutions – So far, there are no validations or substitutions considered to be customised at network level; However, during the realisation this will be confirmed.
• User fields – User fields are not considered at network level to be available for the user; However, this will be reviewed during the realisation phase in case there is a need for the use of any of the standard fields.
The configuration for Licensing will be more oriented to cost allocation, instead of planning boards and integration with MRP and production.
Anything related with planning and the integration with MRP is not considered in the scope of the customising of project system for CT.

Graphic – (out of the scope)
Graphics and planning boards are not considered in the scope for Licensing.
Any planning related with time will be performed outsite of SAP or in Primavera.

Activities Key configuration parameters (in scope):
The following parameters will be maintained in the Network Profile:
• Network type (parameter)
• Activity parameter

In JM CT the Network Type will be used to hold the information for controlling and managing the networks.

Configuration rational:
The configuration required for the Licensing business for networks is very simple, because it will not be necessary for them manage capacities, integration with production (routings) and the integration with MRP.
The user will be able to plan activities and general costs only according to the business requirements.

Set Up Number Ranges for Network
During the creation of a network, the system will automatically assign the number of the network and this will come from a predetermined number ranges in the configuration.
The user will not have to assign any number to each network.

Configuration Object Description Existing / New Relevant Site Configuration Source
OPUU Network profile New All Sites NA

To maintain Licensing networks with a complete independency, the setup of new Network number range is proposed.

The range will be defined during the realisation phase with internal assignment.

Project Milestones
A milestone will mark the completion of a work step in a phase delivered by the project or the conclusion of a phase.
JM CT will use milestones to monitor the progress on a project. The user will be able to define milestones or use predefined milestones from a Roadmap that you have selected for your project.
For JM CT, the following milestones will be available:
• For progress analysis
• As release stop indicators
• To trigger predefined functions and workflow tasks

Milestone Billing
Milestone billing is typically used for billing projects, such as plant engineering, licensing, and equipment amongst others. Such projects often include a series of milestones that mark the completion of different stages of the work delivered to the clients.
In the SAP PS System, milestones will be defined in a Project definition level along with planned and actual dates for the completion of work and this will have to be fully aligned with the contract agreed with the client (billing plan in the sales order).
This alignment has been agreed to be a “manual” process, this means that the project manager will have to create their project milestones in the system, but these milestones will have to be completely aligned with the billing plan established in the contract and in the sales order.
For the Licensing business there will be only one universal type of milestone, this type of milestone will be used to manage any “milestones” agreed with the client in a contract; This is because of the high variety of type of milestones in a contract, is not possible established a fixed catalogue of milestones to be used in project.
The milestones will work only as an indicative item for the project manager, to notify that a specific phase or work order has been completed; There will not be any kind of standard integration between projects and sales.
Each milestone-related billing will remain open (clear) until the Project manager confirms that the milestone is completed (transaction: CJ20N).

The user will have the option to create all the necessary milestones for the project, according to the conditions established in the contract with the client.
The users from Licensing, will have the option to assign a free description on every milestone and a due date, the description should be aligned to the description of the contract.
As general rule, the milestones will be created at CONTRACT LEVEL, because is possible and specially in Licensing that can be multiple contracts in one project.
Milestones will be configured in the following transaction:

Configuration Object Description Existing / New Relevant Site Configuration Source
OPSR Milestone creation New All sites New
For the Licensing and Formox business, there will be created milestones for “Billing” only (Milestone usage type). It is not currently considered a requirement for the creation of additional types of milestones, to manage times, meetings, or other kind of events.
2.2.7. Project Template and Master Data Maintenance
Project Templates will be used to help the business standardise the structure of each project depending on the nature of the business and the project.
A project template is a preconfigured project, that can be used as a library to setup a new project or what SAP PS calls an “Operative Project”.
The template will contain the Project Definition and master data such as WBS elements, Network activities, Milestones, Material Components as required.
The following templates have been defined for the Licensing, Formox Plant Designs and R&D Businesses to enable the move to using Project Systems and Time Sheeting.
When a project is created it will be assigned a Segment (in the user fields), where appropriate, to enable tracking of costs and revenues by business segment. This information will be stored in a User Field in the Project to enable this reporting (explained in more detail section 2.2.9). The exact element the Segment will be recorded in will depend upon the project type and the need to split across multiple segments. It is anticipated that for major projects one segment will be required at project level, however for day-to-day activities where a single project may cover multiple segments, the segment will need to be recorded at the appropriate WBS level.
The final level to assign the segment will be determined during the testing phase, the new model will allow the business to allocate the segment at project definition level or at WBS element.

Project Templates Project template Description Existing / New
R&D KeyedIn Projects Refer to Figure 4
New
Formox Plant Designs Refer to Figure 3
New
Licensing Refer to Figure 1
New
Non-chargeable projects Refer to Figure 5
New
Proposals (Licensing) Refer to Figure 2
New

Project Template for Licensing
The diagram below shows the template structure for Licensing projects. This structure will be used for all Licensing projects (Licensed Packages, Studies and Plant Upgrades). Other activities such as proposals and day-to-day activities will use the simpler structures described below.

Figure 1 - Licensing Project Structure
The intent of the structure is to enable the Licensing business to continue to manage projects in a similar way to currently in Agresso down to a similar level of detail. In addition the structure in SAP will enable the planning of manhours within SAP and the production of Cost Reports from SAP.
The project template includes all the elements that make up a single project. For Licensed packages this can include License, Engineering, Equipment Supply and Catalysts. There is also consideration of the need to manage contracts which are owned and managed by a different legal entity to the entity doing the work (e.g. JM Plc (GB30) contracts with JM Davy performing the work and receiving the revenue). It is likely there will be some contracts where changes will be required but the template should form a good basis for most Licensed packages. The same template will be used for Studies and Plant Upgrades, where not all elements will be used but will be created as part of the template and can then be removed or ignored.
The project template is made up of a number of levels, details of which are provided below. Note additional WBS elements can be created as required during the creation and operation of the project.
WBS Level 2 (Core Activities)
This level includes WBS elements that relate to the different elements of a Licensed package, i.e. License, Engineering, Equipment Supply and Catalysts. There is also a WBS element for JM Plc at this level to handle the cases where JM Plc manages the contracts (including invoicing and receipt of payment). This will enable these to be handled within the project and then the costs/revenue transferred to the correct WBS element.
WBS Level 3 (Work Orders)
This level replicates the work orders currently found in Licensing. The total list of work orders has been reduced from those currently in use to a key sub-set agreed with the business. The sections below outline the workorders and the relevant WBS elements provided in the template and the reasoning behind the design.
License
No WBS levels are required below Level 2 for License as there are no costs associated with this activity. The Level 2 WBS element will be used to handling billing etc. for the License contract.
Engineering Work Orders
The Engineering WBS Level 2 is designed to cover the engineering aspects of the project, excluding those costs, billing etc. related to the supply of equipment by JM to the customer which will be covered under the Equipment Supply WBS Level 2. The Level 3 WBS elements used here are:
Description Agresso Work Order SAP WBS Element
PDP 10 10
Post PDP 20 20
Training 40 40
Meetings 51 51
Site Services (Re-imbursible) 55 55
Home Office Support 58 58
If Technical Procurement Support (for customer procurement) is required then an additional WBS element in the 20 series can be created to capture these costs.
Work Order 30 is not included here as equipment costs associated with the supply of equipment by JM to the customer are moved to the Equipment Supply WBS Level 2
Equipment Supply
The Equipment Supply WBS Level 2 is designed to cover the engineering, procurement, billing etc. activities related to the supply of equipment by JM to the customer. This does not include Technical Procurement Support of customer procurement which would be under the Engineering WBS Level 2 – see above.
A minimum of one WBS element would be created at WBS Level 3 for equipment supply as shown in the diagram (e.g. E1). It may be appropriate for some contracts to create multiple WBS Level 3 elements to cover multiple major items of equipment supply.
Catalysts
The Catalysts WBS Level 2 is designed to cover the procurement, billing, supply etc. activities related to the supply of equipment by JM to the customer as part of the project. Future charges of catalyst would be handled as normal sales.
Level 3 WBS elements may be required if there is a need to separate for example JM supply vs. PFR catalysts within the project. A typical WBS Level 3 would be C1.
WBS Level 4
This level enables a roll-up of the various functions within the project to a discipline level. This is used in the reporting and management of manhours. The Level 4 WBS and Level 5 WBS elements will be repeated under each of the Level 3 WBS elements under Engineering (Level 2 WBS ENG) and Equipment Supply (Level 2 WBS EQP).
The Level 4 WBS elements are:
Description (Discipline) SAP WBS Level 4
Engineering 10
Process 20
R&D 30
Projects 40
Others 60
WBS Level 5
This level enables the split of activties by function and roll-up to the functional level. This aligns with the Cost Reporting and planning activities. Activities will be placed below the Level 5 WBS elements. The information from these Level 5 WBS elements and reporting will also be fed to the planner for updating the forecast manhours and this then provides input to the forecasting of costs and revenue.
The table below shows the mapping of existing codes to the new SAP WBS Level 5 numbering and the roll-up to the Level 4 WBS elements.
Description (Function) Agresso Code SAP WBS Level 5 SAP WBS Level 4
Engineering Management 100 10 10
Procurement 103 13
Vessels & Heat Exchangers inc. Metallurgy 104 14
Mechanical 105 15
Electrical / Instrument 106 16
Piping / Layout 107 17
Civil / Structural 108 18
Fired Equipment 109 19
Process Design 201 21 20
Systems Engineering 202 22
Process Detailed Engineering 205 25
QA 206 26
R&D 300 30 30
R&D Commissioning 300 31
Project Management 400 40 40
Project Engineering 401 41
Project Controls (inc. Planning) 402 42
Secretarial (London) 601 61 60
Document Control/Office Services 604 64
Accounts 700 70
Business Services 900 90
Unallocated 999 99

Project template for Licensing Proposals
The diagram below shows the template structure for Licensing Proposals. The intent here is a separate project is created for each proposal.

Figure 2 - Licensing Proposals Structure
The structure allows for the capture of manhours and costs on proposals. The intent is to use generic discipline activities below the Manhours WBS Level 2 element to enable an understanding of manhours by discipline if required.
Project template for Formox
The diagram below shows the template structure for Formox Plant Design projects. Note: other Formox activities will continue to use Internal Orders as currently, only Formox Plant Design projects are moving to using PS/TM.

Figure 3 - Formox Plant Designs Structure
The aim of the structure is to align with the current approach within Formox. Existing GLs will be used within the WBS Level 2 elements to capture costs. It is anticipated that this approach will allow the Formox Plant Design business to continue to use their existing planning, forecasting and revenue recognition tools, although some modifications will be required based on the finally developed reports that are available from SAP.
WBS Level 2 will be divided into:
Equipment Supply
Equipment Supply will include vessels, rotating equipment, valves, steel, pipes, spare parts, EI & equipment and shipping/transport costs
Catalysts
Catalysts will cover those catalysts provided as part of the initial supply with the plant design. Future charges will be handled via the standard STC processes.
Engineering
Engineering will include EI & engineering, process engineering, mechanical engineering and engineering (Ext. consultants).
Execution
Execution – this will capture all the costs associated with activities not covered in the other WBS elements such as project management (external), installation costs (external site supervisor), contingencies, commissioning and start-up costs, travel expenses, bank charges and representation and administration costs and non-taxable deductions.

Project template for R&D KeyedIn Projects
The diagram below shows the template structure for R&D projects that are established in KeyedIn. These will typically be NPI or PIM projects and will be created in KeyedIn before being set up in SAP. Other R&D activities will be covered by standard project structures described later for day-to-day activties.

Figure 4 - R&D KeyedIn Projects Structure
In order that the data can be transferred from SAP to KeyedIn for actual manhours and costs, the project template includes User Fields which will be populated at set-up with the matching information from KeyedIn. This includes:
• KeyedIn Programme Number
• KeyedIn Project Number
• KeyedIn Workstream Number
These fields are required to enable the import of the data from SAP into the correct entry in KeyedIn. A field will also be provided to allow a project that is eligible for Tax Credits to be marked as such.
At WBS Level 2, one workstream WBS element will be created by default. This aligns with the current CT use of workstreams in KeyedIn. However using this structure would enable the use of multiple workstreams at a future date which is already used in other parts of JM.
At WBS Level 3, two WBS elements are created, one for manhours and one for costs. At the present time CT does not capture costs on specific R&D KeyedIn projects, but again this structure provides this capability. Initially only time will be captured against specific projects using the appropriate WBS element when employees complete timesheets.

Project Structures for “day-to-day” activities
As CT is implementing timesheeting for the whole of RD&E including Licensing, Formox Plant Design projects and R&D, it is necessary to have projects set up to provide places for time to be booked for on-going activities such as customer support, manufacturing support, innovation and overheads. These projects will be continuous and used simply to collect time/costs as part of timesheeting.
The structure of these projects will be straightforward as there will be no need to segregate by activity or discipline. In some instances multiple activities will be included in one over arching project, for example:
Customer Support
A single project could be created for Customer Support. Within this project the WBS Level 2 would provide a split by business area, e.g. Refinery Hydrogen, Additivies, SNG and GTL, Ammonia & Nitrogen etc. Below this the WBS Level 3 could include various Key Accounts, plus Non-Key Accounts to which hours would be booked. The diagram below shows how this might look.

Figure 5 - Typical Non-project Activity Structure
Further work is required to finalize these project structures and coding's with the business, the aim being to reduce the significant number of codes in use at present in Agresso and consolidate to common coding's across CT where possible.
2.2.8. Maintain and configure project TEMPLATES & Networks.
For the creation of project templates (standard projects) there will be the need to use two main key profiles:
• Project profile (templates)
o In the case of this profile, the creation of new project profiles is not considered as the profiles described in section 2.2.3 of this document will be used.
o There is no need to make a differentiation between project profiles for operative projects and project profiles for standard WBS elements.
o Below is the definition of the project profiles that will be used to create standard WBS elements.

Project Profile Project Profile Description Label
ZRD001 Project Profile for R&D New
ZFOR001 Project Profile for Formox New
ZLIC001 Project Profile for Licensing New
ZNC001 Non Chargeable projects New
ZLP001 Project Proposals New

• Standard network profile.
Only one standard network profile will be created that will be used only for the Licensing business.

Network Profile Netwrok Profile Description Existing/New Sites
ZLSD001 Network Profile for Licensing (Std) New Only Licensing
For the Formox and R&D business, no standard network profiles will be set up as they will not use networks.
The setup of this Standard network profile will be made on transaction: CN01
e.g.

2.2.9. User Fields in projects - Segmentation
Reporting segmentation is an important business requirement for JM CT, especially to produce a series of reports to present information organized around specific business segments.
To cover this requirement, it is necesssary to setup a user field at project definition and at WBS element, where the user will be able record the business “segment” for a project.
This field will be used like “tag” that will be available for the user for reporting results per project and per segment.
The segment value in this field, will be validated against a new table that will be created, so the user will be able to assign only values from this table.
This is a WRICEF that is already proposed to be developed to validate this field.
The currently defined segments are detailed in Appendix: 4.1. The User Field has a limit of 20 characters and hence the abbreviated segment names shown in the table will be used in SAP.
The following CT Businesses will have this user field available and they will be able to assign the value “segment” at WBS element level.
Licensing business (WBS element level):

Field name: Length Label Validation Values
USR00 20 Segment Yes See Appendix 4.1

Validations associated:
• The field “segment” will be validated against the list of values defined on a Z table, the user will not be able to capture values in this field that are not on this table.
• The main use of this field will be for reporting purporses.
• The details of this development will be explained on the corresponding WRICEF already raised.

Formox business (WBS element level):
Field name: Length Label Validation Values
USR00 20 Segment Yes See Appendix 4.1

R&D business (WBS element level):
R&D projects will have available the segment field plus, some additional fields that has been requested in comparission with rest of the business.
In the following list the only field that will have validation is the field defined to manage the “segment”, the rest of the fields will be free entry as the values will come from KeyedIn and cannot be pre-defined.
The list of user fields defined for R&D is as follow:
Field name: Length Label Validation Values
USR00 20 Segment Yes See Appendix 4.1

USR02 10 Programme No From KeyedIn
USR03 10 Project Number (KeyedIn) No From KeyedIn
USR04 10 Workstream No From KeyedIn
Validations associated:
• The field “segment” will be validated against the list of values defined on a Z table, the user will not be able to capture values in this field that are not on this table.
• The fields programme, project number and workstream, the content will be managed as a label.
• The main use of these fields will be for reporting purporses and to enable transfer to KeyedIn.
• The details of this development will be explained on the corresponding WRICEF already raised.

Configuration:
The configuration of these “user fields” will be performed on the configuration transaction: OPS1.
There will be created one “Field key” per project profile, this is to allow that any changes made on the logic of these fields, only affect projects of the corresponding business.
Project Profile Project profile description Field Key Existing/New
ZRD001 Project Profile for R&D ZRUS001 New
ZFOR001 Project Profile for Formox ZFUS001 New
ZLIC001 Project Profile for Licensing ZLUS001 New

Note:
There is no considered the definition of user fields for “project proposals” and “Non-projects”, however, during the realisation phase this position may change additional user fields may be defined.

Theses fields will be able to be used by the user on the standard transactions in SAP.

The final catalogue of segments will be reviewed during the build phase. The currently proposed values are listed in Appendix 4.1.
From the reporting perspective, the user will be able to report results using filters by specific segment or by a range of segments.
2.2.10. Person responsible
The person responsible field in the system will be defined as the name of the person that is managing (responsible for) the project. This field will be established as mandatory for the different businesses and project profiles.
The system will provide a field to assign the “person responsible” at WBS element level. The project person responsible is the person that will have full control of the project or for this specific part of the project.

The full list of persons responsible for each business will be defined during the build phase.
This list will be defined by every business with the full name of the employee, that can be responsible for a project or multiple projects. In general, the person responsible will be the project manager.

Licensing:
Person responsible Full name: SAP user
00001 Project Manager SAPABCDE

Formox:
Person responsible Full name: SAP user
00001 Project Manager SAPABCDE

R&D:
Person responsible Full name: SAP user
00001 Project Manager SAPABCDE

The configuration of this table will be made on the SPRO configuration:

The “Office user” is the SAP user that the system will use to send notifications to, regarding the utilisation of the budget by the “availability control”. Section 2.4.7 Availability control from this document.

Substitution – Project responsible copy
Configuration of a substitution that will copy the project responsible on each level of the project structures is included in the design.

This is to maintain consistency in all the levels of the project structure and also to be alligned with guidelines established by the Unify programme.
Note:
The final list of persons responsible will be prepared and delivered by every business during the build phase. Meanwhile, tests will be conducted using some names selected randomly.

2.3. Project Planning – Easy cost planning
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.03.02 Perform Project cost and revenue planning
• 03.08.03.03 Perform project Forecasting

In Project Systems costs will be planned using the functionality of Easy cost planning in SAP PS :
The Easy Cost Planning tool will enable the business to plan costs at WBS level, based on quantities, characteristics and amounts ECP.
It will be used to create quantity structures (possibly temporary) for the cost calculation, starting from the project structure. The system valuates the entries using the prices and rates defined in the system, then distributes the costs in line with the basic dates for the respective WBS elements.
ECP will provide 3 sections for planning

Costing Structure Area - The top node is the object being planned or the ad hoc cost estimate. You cannot cost structure nodes, meaning you cannot assign them a planning form.
Worklist Area – to create cost estimates using Easy Cost Planning, the user will be able to load the planning forms that you use frequently into your worklist. You can create worklists,

Automatic cost planning using networks and assigned orders
In cost planning using networks, costs are automatically calculated based on the resource requirements identified for network activities and operations.
• The resulting plan data can be copied to new projects.
• If parts of the project are rescheduled, cost planning is shifted automatically with activities.
• Costs for network activities are planned by cost element and period

In this step, the detailed estimate of the cost expected to be incurred on the project is determined, reviewed, entered on the project. Cost planning has different objectives in the different project phases:
· At the design and initial stage, cost planning acts as the basis for an initial cost estimate.
· At the approval stage, cost planning serves as a base for allocating the budget.
· During project execution, cost planning is the means of monitoring and controlling cost variances.
Cost and revenue planning is intended to address Planning and Approval of the projects in order to prepare the project for execution. Once the project is properly mapped with the Work Break Down Structure, various functions will be used to plan the individual work packages with expected costs before the project starts.
During the execution phase, the same project plan data will be used to compare with the actual data that is posted to the WBS elements by different business transactions.

The following table describes the level of planning required by every business:

Business Planning level Manual cost planning Automatic cost planning
Licensing At WBS and activity level Overall planning / annual
Cost element level Activity cost calculation, cost automatic calculation
Formox At WBS level (activity not required) Overall planning / annual
Cost element level Not in scope
R&D At WBS level (activity not required) Overall planning / annual
Cost element level Not in scope

Easy cost planning (Planning profile)
Easy cost planning will be pivoting on the planning phrofile is an important configuration to be able to plan projects. Separate planning profiles will be created for the Licensing, Formox and R&D businesses as below table.
Planning Profile Planning Profile Description Existing / New
ZPRD01 Planning profile for R&D New
ZPFOR01 Planning profile for Formox New
ZPLIC01 Planning profile for Licensing New
ZPC001 Planning profile Non Chargeable projects New
ZPP001 Planning project proposals New

Configuration:
The configuration and creation of the project profiles mentioned above will be performed in the following transactions:
Configuration Object Description Existing / New Relevant Site Configuration Source
Maintain Planning Profiles
T. Code - OPSB Costing Variants New All New

For planning purposes and costing purposes, the project will use the standard costing variant PS06.

General parameters:
There is only one key parameter that will have to be activated at project profile level, that is the assignment of the planning profile to the project profile.

The activation of this check box is considered as part of the design defined and will support all the different CT businesses.

Key configuration parameters:

Manual Planning: -
Bottom-up Planning – This indicator will be used only if bottom-up planning is required in Hierarchical planning. If we check this indicator, we can enter the plan value for the lower level WBS which will be automatically rolled up to the higher-level WBS once the entries are saved.
Planning elements – This indicator controls whether a cost planning is possible only if WBS is defined as a planning element. WBS can be defined as a planning element in the operative indicator section in the project builder. If this indicator is not checked, one can carry out cost planning in any WBS element.
Hierarchical cost and revenue planning: – Overall planning where we enter costs for each WBS element manually. Figures will be broken down by fiscal year. So both Overall and Annual Planning is possible in this method. This is ideally a bottom-up approach where we will plan the lowest-level WBS first and then roll the values up to the higher level in the hierarchy.
Planning for Total and/or annual values: – In CT we want to maintain both total and annual Planning. To be able to do that we are going to set for both total and annual values in the planning profile,
Note: - In this case, we must maintain total planning values first, after that annual from it and sum of all annual values should not be greater than total planning values.
Representation: - Decimal places and scaling factor as default values.
Currency translation: - Exchange rate type M to be used in the budget profile.
Planning currency is controlling area currency.

The values highlighted in yellow are indicative and not proposed values, the values proposed are described below.
Automatic Revenue Planning: – There are possibilities in this section for automatic revenue planning on WBS either from quotation or sales order. Revenue elements from the billing plan can also default in the planning profile.
Controlling Version: – Controlling version “0” will be used as a standard for cost and revenue planning and also for the initial planning in the project. As the project progresses and actuals are posted in the project. The initial plan will be revised by the project controllers in separate versions like 1 to 11 which needs to be configured in the system.
WBS Planning: – In CT manual cost planning in the WBS will be done by the method described below:-
Overall planning is where we enter costs for each WBS element manually. Figures will be broken down by fiscal year. So both Overall and Annual Planning is possible in this method. This is ideally a bottom-up approach where we will plan the lowest-level WBS first and then roll the values up to the higher level in the hierarchy.
Detailed planning on the WBS which is both cost element and period based will be covered in detail below in section 2.3.2
Configuration rational planning profiles:
For the different CT businesses the following parameters in the planning profile will be activited for each business.
Configuration item Rational Licensing Formox R&D
Bottom-up planning The activation of this indicator will be necessary, because the planning will take place on different levels of the project structure. Activated Activated Activated
Planning elements The activation of this indicator is necessary, because part of the costs planned in a project will be at cost element level. Activated Activated Activated
Time frame – past Initial proposal is a window of 5 years to review in the past. Activated (5 years) Activated (5 years) Activated (5 years)
Time frame – future Initial proposal is a window of 5 years to review in the future. Activated (5 years) Activated (5 years) Activated (5 years)
Total values The activation of this indicator will be necessary, because the different CT businesses need to plan at total and at annual levels. Activated Activated Activated
Annual Values The activation of this indicator will be necessary, because the different CT businesses need to plan at annual level. Activated Activated Activated
Primary CE group This group of CE will be defined during the realisation phase. Activated
(group TBC) Activated
(group TBC) Activated
(group TBC)
Revenue CE group This group of CE will be defined during the realisation phase. Activated
(group TBC) Activated
(group TBC) Activated
(group TBC)
Exchange rate type The default to be used is (M) Activated
(default M) Activated
(default M) Activated
(default M)
Controlling area currency The activation of this indicator will be necessary; The planning will be performed respecting the controlling currency. Activated Activated Activated
Automatic reveue from sales orders This indicator will allow the project pull into the planning revenue planned from the sales orders. Activated Activated Activated
CT Process of Planning at WBS Level
Before the project is set up in SAP the initial planning will be done off-system. When the project structure is created, along with all the WBS elements, the initial planning will be set up for the WBS elements in the original plan version CCE.
During the execution phase, when the actuals are posted, the project controllers or the managers will have the ability to revise the original plan estimate in a new controlling version. This process will be carried out during all the periods of the fiscal year.
Plan version (rationality):
The plan versions wil be used by the different project managers to capture the different effects or deviations that their projects can have on a weekly or monthly basis. This will allow them to compare their current and future situation with different plan versions from previous months.
A plan version can be represented as a photograp of the project on an specific moment in time.
The following diagra explains, how these versions will be used to capture all these deviations or changes, that can be on the forecast of a project or on their budget.
Example:

The previous diagram, is explaning how the different versions created (table of below), will be used by the project managers to reflect changes on their budgets and forecast every month, but they will have the option to keep any change made on previous months.

For planning purposes, It will be necessary to set up the following planning versions.
Plan versions for Forecast
Plan Version Description
ASS As-sold budget version
CCE Budget approved
M1 Budget adjustments Jan
M2 Budget adjustments Feb
M3 Budget adjustments Mar
M4 Budget adjustments Apr
M5 Budget adjustments May
M6 Budget adjustments Jun
M7 Budget adjustments Jul
M8 Budget adjustments Aug
M9 Budget adjustments Sep
M10 Budget adjustments Oct
M11 Budget adjustments Nov
M12 Budget adjustments Dec

Plan versions for budget adjustments
Plan Version Description
BCE Budget approved
B1 Budget adjustments Jan
B2 Budget adjustments Feb
B3 Budget adjustments Mar
B4 Budget adjustments Apr
B5 Budget adjustments May
B6 Budget adjustments Jun
B7 Budget adjustments Jul
B8 Budget adjustments Aug
B9 Budget adjustments Sep
B10 Budget adjustments Oct
B11 Budget adjustments Nov
B12 Budget adjustments Dec
Configuration rational – Planning versions:
For the configuration of the planning versions mentioned above, there will not be any special configuration required other than the standard.
All these new versions will be able to manage only plan costs and revenues; Version 0 is the only version that will manage plan and actuals, because this is the version that will be used as pivot to create new versions (as copies).

In general every version will be setup to manage “plan” and “cost forecast.
These versions will be used by the business to make adjustments and their project forecast and project budget every month, depending on the adjustments identified by the project manager.
Example:
The final approved budget will be updated and uploaded manually by the Cost Engineer/Business Controller in the project structure created (TC: CJ20N).
Planning at cost element level:
Easy cost plannig on CJ20n will provide the user to create and have multiple easy cost planning versions available.

Planning at activity level:

Any adjustment on the planning versions mentioned above will be automatically rolled-out to the following level above until reaching the WBS element “root” and project definition.

With the budget already uploaded into the project structure, the user will have to copy this version to the version CCE. This version will be used to control the original budget reviewed and approved by the PM.
Every month, the manager will have to update versions with M1 to M12 to update the forecast.
2.3.1. Planning at Activity Level
This function will be carried out by the controlling team as activity rate planning is a controlling activity. In CT we will be using the CATS module to enter timesheets of employees working on the project. To convert time into the cost it will be necessary to define activity rates planning in the controlling module.
Planning at activity level will be activited and will be avilable for the user, this is necessary because the business requires to plan hours and costs at activity level.
Planning at activity level ECP:
At the activity level, the user will have available the option to cost activities, assigning the number of units (hours) and the cost associated (activity types in CO).

The previous tic will be activated on the configuration, to allow the business to plan at activity level.

Automatic planning will calculate the cost of the activity, multiplying the number of hours by the cost of the activity type.
The JM CT business has currently identified the following set of activities:
Activity type Description Unit
1000 Normal Hours Hours
1100 Overtime | Mon-Fri Hours
1500 Overtime | Sat-Sun Hours
2000 Overtime | Bank Holiday Hours
These activities will be created as activity types in Controlling (TC: KL01)

Note:
The final list of activity types will be confirmed once the team has reviewed and agreed on the level of cost for the activities with JM HR and the businesses.
The price of the activity will be defined on transaction KP26.
The values highlighted in yellow are indicative and not proposed values, the values proposed are described further in this document.
2.3.2. Planning at Cost element Level in Easy cost planning
On Easy cost planning the screen displays all cost elements based on the cost element group entered in the planning profile of the project. In this planning method, we can also plan period wise for each WBS.
CT Process of Planning in WBS with Cost Element
The final group of cost elements available to be used for planning will be established during the construction phase.

The business will have the option to select the range of the cost elements to use for planning.

The group of cost elements for planning will be defined for each business during the build phase.
So far, there is no intent to make changes on the standard planning layouts provided by SAP. Consideration will be given to using the same “planning layouts” defined by the Unify programme.
This will be reviewed and confirmed during the realisation phase of the project.
Reports on Planning
Standard reports are available to compare plan values in a project for any two plan versions at a time.
If additional versions need to be compared at the same time a custom report may need to be developed. Also, there are standard reports available in SAP, both hierarchical as well as cost element based, which compare the plan cost along with the actual cost, budget, commitments and variances.
Note:
The implementation of easy cost planning is not considered in the scope of projects, so the use of costing variants like PS06 is not considerd.

2.4. Project Budgeting
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.03.01 Perform Budget for project spend
• 03.08.03.04 Perform Project amendment (Over/under)

Projects consist of many phases; Concept/Planning/Execution & Closure. The project cost within CT will be estimated during the planning phase; accordingly, the available funds are defined for the project in the form of a budget. The Budget is the device by which management approves the expected development of project costs over a given timeframe.

The Budget is defined as the approval for a project and it is different from the cost plan. The Budget is the approved cost by management for the expected project activities in a given period.

The following table describes the level of budgeting required by every business:
Business Budgeting level Availability control Source
Licensing At the WBS element level Yes Plan version (approved)
Formox At the WBS element level Yes Plan version (approved)
R&D At the WBS element level Yes Plan version (approved)

Budget Profile
The Budget Profile is the important configuration to be able to budget projects. Separate budget profiles will be created for Licensing, Formox and R&D businesses as in the table below.

Budget Profile Budget Profile Description Existing / New
ZBRD01 Budget profile for R&D New
ZBFOR01 Budget profile for Formox New
ZBLIC01 Budget profile for Licensing New
ZBN001 Budget profile Non Chargeable projects New
ZBLP001 Budget profile project proposals New

Configuration:
The configuration and creation of the budget profiles mentioned above will be performed in the following transactions:

Configuration Object Description Existing / New Relevant Site Configuration Source
Maintain Budget Profiles
T. Code - OPS9 Budget Profile New All Unify
Create Number Ranges
T. Code – OK11 Number Ranges New All Unify

Key Configuration parameters
The following parameters in the budget profile are relevant for Project budgeting:
Time horizon: The number of years for the budget. It has three options Past, Future and Start.
Budgeting for Overall and/or annual values: - In CT we want to maintain both overall and annual budget. To be able to do this we need to define both overall and annual values in the budget profile.
Note: - In this case, we must maintain the overall budget first, after that annual from it and sum of all annual values should not be greater than the overall budget.

Representation: Decimal places and scaling factor as default values.
Currency translation: Exchange rate type M to be used in the budget profile.
Availability Control: In CT we are going to use availability control for released budget usage.
Note: - In this case, the overall budget must be released first, then the annual from it and sum of all annual values should not be greater than the overall budget.
Budgeting Currency is controlling area currency.

Configuration rational budget profiles:
For the different CT businesses the following parameters will be activated in the budget profile of each business.
Configuration item Rational Licensing Formox R&D
Time frame – past Initial proposal is a window of 5 years to review the budget in the past.
(to be consistent with planning) Activated (5 years) Activated (5 years) Activated (5 years)
Time frame – future Initial proposal is a window of 5 years to review the budget in the future.
(to be consistent with planning) Activated (5 years) Activated (5 years) Activated (5 years)
Total values The activation of this indicator will be necessary, because the different CT businesses need to track their budget at total and annual level. Activated Activated Activated
Annual Values The activation of this indicator will be necessary, because the different CT businesses need to track their budget at annual level. Activated Activated Activated
Availability control – activation type The indicator will be “1”, the activation of the availability control function, will be performed once the budget has been assigned. Activated (1) Activated (1) Activated (1)
Exchange rate type The default to be used is M Activated
(default M) Activated
(default M) Activated
(default M)
Controlling area currency The activation of this indicator will be necessary; The planning will be performed respecting the controlling currency. Activated Activated Activated
Note:
It is not currently exepcted that Proposal projects and Non-projects will have assigned a budget profile.
Number Ranges
In CT number ranges are required to be defined for budgeting to identify any changes in the budget line item. Changes to the original budget can occur as a part of the budget supplement, return and transfer for which the budget line item is generated and gets stored with an internal document number for which a number range is required to be defined.
The following number ranges are defined in the standard system for the use of planning and budgeting projects.
· 01 Plan Project
· 02 Budget Project

Tolerance Limits
In CT tolerances will be defined according to use of 70%, 90% & 100% of the budget consumed. So budget overrun can be checked in a project and initiate various actions. Warnings with an email to the person responsible for the project are triggered when these limits are reached.
The configuration will be explained in more detail in section 2.4.7 Availability Control of this document.
2.4.1. Original Budget
In CT the Original Budget will be maintained during the initial stage of the project when there is a need to allocate funds and have control of expenditure throughout the project life cycle. Ideally, this will be one-time activity and any change to the original budget will be done through budget update functionality as detailed in section 2.4.2 Budget Update. A budget can be defined as an overall budget or distributed by year. This can be configured by the budget profile.
2.4.2. Budget Update
Unexpected/unforeseen events, additional requirements, price changes for external activities, and other parameters may cause a project to require more funds. In such cases, we may need to update the original budget within CT. There are three types of Budget updates:
• Supplements, Returns & Transfers
2.4.3. Supplements
If the funds provided are not sufficient, the system enables the use of budget supplements, which can be used on projects in CT.
There are two types of supplements for projects.
1. In The Project
A Supplement can be made in the project from the top-down, from the higher-level WBS element to the lower level. We can supplement only as much budget on a WBS element, as is contained in the higher level. The system determines these values in the controlling area currency or object currency and includes budget in line items that were entered in different currencies.
2. To The Project
Making a supplement to a project means providing a selected WBS element with the additional external budget. This is independent of the remaining budget on the higher level. The system updates the supplemented budget on the WBS upwards.
If we use more than one currency for budgeting, the system always translates a supplement with the current exchange rate into the controlling area currency or object currency. If the exchange rate for the supplement is different from what was entered as the original budget, the new total budget is translated using an average rate.
We cannot supplement the budget in all project statuses. The project or the WBS element for which the budget is to be supplemented needs to have a status that allows the budget to supplement business transactions.
2.4.4. Transfers
In CT transfer budget functionality will be intended for transfers between WBS within the same project and applicable for transfer among WBS elements of different projects.
2.4.5. Returns
In CT this function will allow us to return unused budget on a WBS element to the top-level WBS element in the project thereby increasing the distributable amount in the project. This can be used when the activities against a WBS element have been over-budgeted.
2.4.6. Budget Release
In CT we will leverage the standard SAP functionality of approving partial or total budget originally allocated to the project. Management in CT may try to optimize the use of funds and hence this additional step of budget release will be defined. This will also be done to ensure the original available budget is not exhausted at an early stage of the project and so we can release the budget in stages.
Using released budget CT will have further control by using authorisation restriction. For example, if the original budget is maintained by the project manager, the budget release will only be maintained by the controller.

Note: This will be reviewed with the business during the construction phase, to adopt or discard the use of this budgeting functionality.
2.4.7. Availability Control
The availability control in CT will be configured for the overall as well as the annual budget which will be released.
Availability control will compare the released budget with the assigned value by issuing a warning via email to the person responsible when budget reaches the Tolerance Limits Settings as mentioned in the table below.
Licensing
Tolerance Limit for Licensing 70% 90% 100%
Actions Warning Warning with an email to the person responsible Warning with an email to the person responsible

Formox
Tolerance Limit for Licensing 70% 90% 100%
Actions Warning Warning with an email to the person responsible Warning with an email to the person responsible

R&D
Tolerance Limit for Licensing 70% 90% 100%
Actions Warning Warning with an email to the person responsible Warning with an email to the person responsible

2.4.8. Configuration:
Configuration Object Description Existing / New Relevant Site Configuration Source
Define Tolerance Limits Tolerance Limits New All Unify

e.g.

2.4.9. Standard Reports on Budget
Standard reports on the budget are available to compare the budget, commitments, plan and the actuals. Budget line-item reports are also available in standard to see the budget update line item.
2.4.10. Year-End Functionality in Budget and Commitment Carry Forward
Two functions will be carried out by CT during year-end
1. Budget Carry forward: - This function will be used to carry forward the project budget to the next year
2. Commitment Carry forward: - For financial reporting purposes, every year closing activity takes place at the end of the financial year. If during Fiscal year closing, if a certain amount of commitment has not been executed, it can be carried forward to the next year depending upon Management approval. Subsequently, this commitment can be utilized in next year’s budget and can then be closed.

2.5. Capture Project Costs & Timesheets
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.04.01 Capture project related costs
• 03.08.04.02 Maintain HR Mini master
• 03.08.04.03 Maintain CATS Profile
• 03.08.04.04 Enter & Approve Time
• 03.08.04.05 Time Administration
• 03.08.04.06 Reporting for time sheets

The project system is closely integrated with other SAP modules like Logistics, Material Management, Sales and Distribution, Plant Maintenance and Production Planning module.
The integration between the SAP Project System with the rest of the application modules will allow JM CT to design, plan, and execute the projects as part of their normal processes.
The following diagram shows the modules where SAP Project System will integrate with other modules:

Modules Description
Finance and Controlling To manage actual costs and planned posts.
Material Management To manage procurement and inventory functions occurring in the project lifecycle. The purchases will be integrated with PS, the user from the project will be able to visualize the detail of the total “commitment” in projects.
Sales and Distribution To manage the sales process in the project lifecycle, including quotations for customer projects, billing and shipping of goods and services required in the project.
Human Resources To manage the processing of timesheets, it will be required to enable the setup of the “master record” of the employee.
2.5.1. Finance integration
In Project Systems every project (WBS element) will become a cost collector that will be assigned to specific financial structures.

In general, every time a project receives a posting from finances (cost allocation), the posting will be assigned to the following financial structures as a minimum:
1. Company code
2. Cost element
3. Profit centre
4. Plant
5. WBS / Network
The Finance team will be able to allocate costs to projects via:
• FI Journals being posted directly to a Project - FI Journals will be posted to the project via transaction FB50 referring to a WBS element.
• Financial Allocations, Interest etc. - Distribution or assessment cycle functionalities will be used to allocate cost from a cost centre to projects or WBS elements
• Postings will also come from procurement and sales via the use of cost elements.
• Financial accounting: WBS elements and Networks codes will act as cost objects in Financial Accounting transactions.
With the standard integration between FI and PS, every WBS element and network will become a cost collector that will be assigned to some specific organisational structures.
E.g.
The following project was created on the company code 1710, this means that any cost allocation made will be assigned to the P&L of this company.

Example A: in the case of an invoice that is to pay for “goods” delivered to a project, the person from accounts payable will create the invoice following the process established in SAP (STC process), but they will allocate the value of the invoice to the correct WBS element.
Example B: In the case of a timesheet, the cost will be allocated to the right WBS element (or network), this means the user will allocate their hours into the correct project to ensure the project manager sees the value reflected in the project.
e.g.

To allocate a cost in a project, the vehicle that the system will use is what SAP call a “cost element” (GL accounts).
There are two types of cost elements in SAP:
• Primary cost element
• Secondary cost element

e.g.

The definition and catalogue of each of these types of cost elements are described in the RTR FDD (FDD003 RTR Project Concert. Doc).

The following table describes the coding blocks defined for each business:
Business Company code Profit centre WBS Network Cost Elem.
primary Cost Elem.
Secondary
Licensing Yes Yes Yes Yes Yes Yes
Formox Yes Yes Yes No Yes Yes
R&D Yes Yes Yes No Yes Yes
2.5.2. Timesheet allocation
The Cross-Application Time Sheet (CATS) component is a tool used for recording time and tasks in projects. JM CT employees will be able to record their own time and this will then be available for analysis and to capture the associated costs on projects.
2.5.2.1 Maintain HR Mini master
An HR Mini-Master will be used in JM CT to access employee profile information for Time Sheeting purposes. Workday will transfer the minimum information required into SAP, related to the master record and details of the employee. The interface between Workday and SAP HR will support information from the following list of infotypes in SAP HR.

• 000 (Actions)
• 001 (Org-Data)
• 002 (Personal data)
• 007 (Planned working hours)
• 0105 (Communication)
• 315 (Timesheet Default)

An interface will be set up between SAP and Workday to bring into SAP the information required for the above info types for all JM CT employees.

Note: Details of this integration will be confirmed with the Workday team during realisation.

The interface will transfer the necessary information into SAP to allow employees to process their timesheets on a weekly basis.
The diagram below shows the high-level integration to be built between the systems.

• Workday – Workday is the corporate system selected by JM, to manage all the personal and payroll information for all employees.
• Middleware – the middleware (SAP PI/PO) will be used to administer the mapping and flow of the information between both systems.
• SAP – SAP CATS is the system to be used by CT to allow the employees to process and generate timesheets.
Note: This technical and functional integration will be developed in conjunction with the Workday team and the JM IT technical team. At this stage, this document outlines the proposed solution only.

Technical Integration Architecture

• Scheduled integrations
• PO/PI to be used as entry point to SAP Fiori
• Integration to be API based
• PO/PI API to accept data in Workday format
• PO/PI to carry out any transformation from Workday to SAP formats
• Only relevant and necessary data to be sent from Workday to consuming applications (PII requirement)
• Workday delivers data in WECI (Worker Effective Change Interface) process for initial load and subsequent deltas

The table below shows the initial set of fields to be updated as part of the HRMM (Workday to SAP integration),
Note: This is just the proposed list from EY, this list is yet to be confirmed by the Workday team and business, and the authorisation objects to secure HR data will be confirmed as part of the Workday to SAP integration.
The list presented below has been through an initial review with business and as far as possible the GDPR issues have been considered. Where fields could present a GDPR issue, the option to be defaulted to a given value will be considered.

Below are the Info types that will be updated as part of the HRMM, Workday to SAP integration,
SAP Infotypes Description
IT0000 Actions
IT0001 Org Data
IT0002 Personal Data
IT0007 Planned working Time
IT0315 Timesheet Defaults
IT0105 Communication

Below is the consolidated list of SAP fields that will be updated from Workday to SAP via the integration,
SAP Fields for HRMM Description Mandatory in SAP
PERNR Personnel number Y
ENDDA End Date Y
BEGDA Start Date Y
MASSN Action Type Y
MASSG Action Reason Y
BUKRS Company Code Y
WERKS Personnel Area Y
PERSG Employee Group Y
PERSK Employee Subgroup Y
BTRTL Personnel Subarea Y
KOSTL Cost Center Y
ORGEH Organizational Unit Y
PLANS Position Y
STELL Job Y
INITS Initials N
NACHN Last Name Y
VORNA First Name Y
MIDNM Middle Name N
GESCH Gender Key Y
PERID Personnel ID number N
SCHKZ Work Schedule Rule Y
TEILK Part time Employee Y
EMPCT Employment Percentage Y
ARBST Daily Working Hours Y
WOSTD Weekly working hours Y
MOSTD Monthly working hours Y
JRSTD Annual working hours Y
WKWDY Weekly workdays Y
USRTY Communication Type Y
USERID Communication ID/Number Y
KOKRS Controlling Area N
KOSTL Sender Cost Centre N
LSTAR Activity type N

Below is the list of configuration objects in SAP HR. The SAP HR functional consultant will perform this configuration.
Configuration Object Configuration rationality Existing / New Relevant Site
Maintain Personal area and personal area, Config Table: T500P, T001P The personnel area is an organizational unit that represents a specific area of the enterprise. A personnel area is divided into several personnel subareas. We need to configure JM specific PA and PSA for HRMM values to be accepted during transfer from workday to SAP as part of HRMM integration. Existing All
Employee Groups and Employee Subgroup, config Table: T501, T503K The employee group allows SAP to divide employees into groups and define their relationship to the enterprise. Employee groups are further divided into several subgroups. We need to configure Employee group and subgroup for HRMM values to be accepted during transfer from workday to SAP. Existing All
Assignment of Personnel Area to Company Code,
Config Table: T500P We will allocate each of JM's personnel areas to JM’s company codes, this step is needed to update records in IT0001 as per of HRMM. Existing All
Assign employee subgroup to employee group
Config table: T503Z We will assign employee subgroups to their respective employee groups; this step is needed to update records in IT0001 as per of HRMM transfer. Existing All
Maintain Number Ranges for Organization Objects
Tcode-OONR Number range is maintained for all Objects (Job/position/org unit) Existing All
Integration with Personnel Administration of Organization Management
Config Table: T77S0, If the value of PLOGI-ORGA is set to X that means integration is switched ON between PA and OM We will integrate Personal administration module to Organizational Management module, so that we will have Object values from OM available to be maintained in PA, which is basically info type IT0001 updates. Existing All
Set up personnel actions, Config Table: T529A JM specific Personal actions needs to set up, to be available for IT0001 update as part of HRMM integration Existing All

2.5.2.2 Maintain CATS Profile
A CATS profile will be created for each business group in JM CT. Single or Multiple CATS Profiles will be created depending on the variations required by the different business groups.
As part the design requested and identified there will be created the following entry profiles:
• 3 Data entry profiles will be created for each set of CT business (R&D, Formox and Licensing ) users.
• 3 Data entry profiles for Time Adminstrator will be created, 1 for each CT business (R&D, Formox and Licensing business).
Entry profiles for users
Data Entry profile Entry profile description Existing / New
Z_R&D Data profile for R&D New
Z_FORMOX Data profile for Formox New
Z_LICENS Data profile for Licensing New

Entry profiles for administrators
Data Entry profile Entry profile description Existing / New
Z_R&D_TA Time administrator profile for R&D New
Z_FOR_TA Time administrator profile for Formox New
Z_LIC_TA Time administrator profile for Licensing New
Note: Data entry profile configuration for both users and time administrators are going to be same, except the check box for time administrator, for more details please look at section 2.5.2.4 Time Administration .

Certain CT employees will have access to Transaction Code CAC1 which will be used to create and maintain CATS profiles. Based on the data entry profile, the timesheet view can be customized and this includes general settings, e.g., if we want to display all weekdays or workdays only (from HRMM Info type 007), the checkbox can be checked/unchecked accordingly as shown in below screenshot.

If we want to see target hours on timesheets (from HRMM Infotype007), if we want to see and release future times and many more settings can be selected using the checkboxes.

R&D, Formox and Licensing require the display of all weekdays and target hours to be shown for all users and would like to release future times as well.

CT employees can have Time-specific settings that can be used to determine if data is entered daily, weekly, semi-monthly, or monthly. Which day should be shown as the start of week in the CATS screen (Fiori) can be selected as shown in the screenshot below.
Lower and upper limit relative values of week can be given, for example if lower limit relative is 5, user can go 5 weeks before the current week to make any changes in past timeheets
If upper relative limit is 2, user can see and fill timesheet for next 2 weeks from current week.

R&D, Licensing and Formox all have weekly timesheet entry , with lower and upper limit relative maintained as 2.

The CATS profile can also specify whether the released data records for this data entry profile are subject to an approval procedure before being transferred to the target applications as shown below.

If we check without approval procedure, the system will allow filled timesheets, irrespective of approval status to be transferred to CO/PS component.

If we select with approval procedure, the system will not allow transfer of timesheet data, until timesheet approval status is approved.

All CT business group users will use approval and will have a single level of approval, which will be the line manager.

The CATS profile helps set up default values like cost centre, activity type, Absence/Attendance types as shown below.

All CT business groups will have as default cost centre, controlling area and activity types.

Key parameters entry profile (user):

Not Activated

Release Future Times Determines that future data, that is data for a period that lies after the system date, may also be released. Activated Activated Activated
Period Type Determines how often users should enter data in the time sheet, weekly, monthly etc Activated Activated Activated
Lower/Upper relative Limit The Upper/lower limit relative field determines how many times users can scroll forward/backward relative to the key system date. Activated Activated Activated
Time Administrator Determines that the system selects all personnel numbers assigned to the user in his or her capacity as time data administrator, when you call the data entry profile Not Activated Not Activated Not Activated
Enter for several personnel no's Determines that you can enter data for several personnel numbers at once Not Activated Not Activated Not Activated
Without approval procedure Specifies that the released data records for this data entry profile are not subject to an approval procedure before being transferred to the target applications Not Activated Not Activated Not Activated
With Approval procedure Specifies that the released data records for this data entry profile are subject to an approval procedure before being transferred to the target applications Activated Activated Activated
Activity type Default values from IT 315 Activated Activated Activated
Controlling area Default values from IT 315 Activated Activated Activated
Cost Centre Default values from IT 315 Activated Activated Activated

Key parameters entry profile (administrator):

Configuration item Rational Licensing Formox R&D
Profile changeable Controls whether the user can change certain specifications for the data entry profile. If you set this indicator, users with authorisation for this profile can go to the Settings CATS to change the profile settings to suit their current requirements Activated Activated Activated
With target Hours Determines whether the time sheet displays target hours from Human Resources (HRMM IT0007) Activated Activated Activated
Display Weekdays Displays only weekdays according to the user calendar. Activated Activated Activated
Workdays only Displays only workdays according to the user calendar. Not Activated Not Activated Not Activated
Release Future Times Determines that future data, that is data for a period that lies after the system date, may also be released. Activated Activated Activated
Period Type Determines how often users should enter data in the time sheet, weekly, monthly etc Activated Activated Activated
Lower/Upper relative Limit The Upper/lower limit relative field determines how many times users can scroll forward/backward relative to the key system date. Activated Activated Activated
Time Administrator Determines that the system selects all personnel numbers assigned to the user in his or her capacity as time data administrator, when you call the data entry profile Activated Activated Activated
Enter for several personnel no's Determines that you can enter data for several personnel numbers at once Activated Activated Activated
With Approval procedure Specifies that the released data records for this data entry profile are subject to an approval procedure before being transferred to the target applications Activated Activated Activated

2.5.2.3 Enter and Approve Time
The current scope includes the development of an SAP Fiori interface that will be available for every JM CT employee to prepare and submit their timesheets on a weekly basis.
Fiori interface (example)

The web application is the most user-friendly option for inputting data. The layout that the interface will display, will be based on the entry profile that will be defined for every business (Licensing, R&D and Formax).
Approval of timesheets
There will be a process where managers will be able to review and approve timesheets for all employees that have worked on projects.
It is expected that the line managers will approve timesheets, instead of the project managers in charge of the project. This is in line with the approach currently being used in CT.
Note: Employees and Line Managers will not use the SAP interface for timesheet submission, correction or approval. Submission, correction and approval of Time Sheets will be done via Fiori interface.
Steps:
• The employees will record their working time in the Cross-Application Time Sheet using a standard Fiori interface. Depending on the settings in the data entry profile, they will save their working time, and release it for approval.
• The working time will be processed under status 20 (Released for Approval, which can be viewed using report CATS_DA). Please note that, CATS_DA is not available on the standard Fiori interface.
• The system will determine the person to approve the working time based on the workflow.
Note: We are going to use the standard SAP workflows. Further workflow details will be confirmed during the realisation phase.
• The approver will approve timesheets via standard Fiori Interface
• The approver approves or rejects the working time.
Note: We are proposing to use BTP process for timesheet approval, as this is an established process in JM.
• If the approver rejects the timesheet via Fiori, the following Timesheet Rejection reasons can be applied; The final list will be determined during the realisation phase.
Code Timesheet Rejection reasons
REJ1 Hours booked to incorrect number
REJ2 Incorrect number of hours booked
REJ3 Incorrect overtime booked
REJ4 Incorrect work centre used
REJ5 Other error in timesheet

• Once the timesheets are approved, they will be transferred to Finance and Controlling using SAP TCODE CAT7 by the JM CT Finance team. This process will be performed manually by the Finance project controller. In Controlling the Hours will be converted to Cost.

The following are the proposed fields that the system will display:
• Personnel number, PERNR
• Work breakdown schedule element (WBS element)
• WBS element text
• Activity type
• Text for activity type
• Network
• Activity number
• Work Centre
• Attendance or absence type
• Name of attendance or absence type
• Start time
• End time
Note: Users will not have authorisation to confirm the completion of activities through Fiori interface. This is only applicable for Licensing (as only Licensing uses activities).
Note: the final layout will be refined during the build phase.
Example Screenshot,
Notes:
• It is intended there will be only one level of approval for timesheets managed by the Line Managers for Licensing, R&D and Formox.
• IT0007 will come as part of HRMM, with the workschedule rule, the system will update the public holiday, target hours, and reflect these in the Fiori interface for each employee (Note:public holidays/target hours will only be for display purpose for a better user experience).
• There will be no restrictions on hours booked either over or under. We will implement warning/indication if users' book under or over the number of hours to encourage users to ensure they have completed a full timesheet.
• For all the CT employees, the system will allow to time to be allocated to non project activities such as holidays. Users will use Fiori Timesheeting with a different code for non project time allocation which will be non chargeable.
2.5.2.4. Time administration
The Time Data Recording and Administration component supports automatic recording of timesheets and manual recording.
Configuration:
Data Entry profile: The data entry profile determines the data entry process and the layout of the timesheet for CT business users who are time administrators.
The data entry profile ensures the system selects all personnel numbers assigned to the user in his or her capacity as a time data administrator when you call the data entry profile as shown below.
Please note, for the time administrator profile, check box “Time administrator” has to be checked, along with another checkbox “Enter for Multiple personnel nos” as shown below
3 Data entry profiles for Time Adminstrator will be created one for each business; R&D, Formox and Licensing.

Pre-requisite/Dependencies,
• You assign personnel numbers to a time data administrator using the Organizational Assignment infotype (0001) in HR.
• You define a user as a time data administrator for the time sheet using the user parameters SAZ (time data administrator)

Note: The roles will be updated by the JM security team using the SAP Tcode: SU01.

For JM CT, we need 3 different time administrators profiles, one for each business group (R&D,Formox and Licensing).
CATS Data-Entry Profile for Time Administrators Profile Description Existing / New Relevant Site Configuration Source
Z_R&D_TA Time administrator profile for R&D New All Sites NA
Z_FOR_TA Time administrator profile for Formox New All Sites NA
Z_LIC_TA Time administrator profile for Licensing New All Sites NA

After defining the data entry profiles (for R&D, Licensing and Formox) and assigning the Data entry profile to user ID using SU01 paramater SAZ, we will assign personnel numbers to a time administrator using the Organisational Assignment infotype (0001) in HR using Tcode PA30 as shown below screenshot:

Once Time adminstrator data entry profile is called using Fiori, he/she has the right to update/approve/reject timesheet hours for associated personnel numbers .

Configuration Object Description Existing / New Relevant Site Configuration Source
IT0001 Assign Time administrator New All Sites NA
CAC1 Maintain CATS Entry Profile New All Sites NA

2.5.2.5. Intercompany projects timesheet allocation
JM CT users will have the option to allocate time to projects that do not belong to the company code that they are assigned to.
An engineer, whose office base is in Sweden (for example), working on a project that is managed by the UK, for timesheet processing purposes will ask the UK project manager for the WBS element or Network/activity number where time should be allocated.

There will be an intercompany process defined and operated by finance, to allocate timesheets coming from different business units.
The process requires:
1. The setup of automatic intercompany account postings between business units (explained in the RTR FDD)
2. A process to clear and review the amounts allocated on each business unit during month-end
3. A process to invoice these amounts to the business unit that has requested the work in the project
These processes and the postings required are documented in FDD001 RTR Project Concert and FDD002 STC Sales to Cash.
The main change will come from the profit centres that will be allowed to receive postings from different companies, this will allow an employee to allocate their timesheets to projects that belong to different company codes, because the system internally will create an intercompany posting.
2.5.2.6 Converting Time to Cost
Activity Type, Secondary Cost Elements and Cost Allocation:
In JM CT, R&D, Licensing and Formox will have list of activities associated with every established WBS element, which will be used to allocate time within a Timesheet. Each Activity will be linked to a Secondary cost element (set up in Finance).

Every Activity type will be linked to a secondary cost element as shown in the above screenshot. Secondary Cost Elements are used exclusively in Controlling (CO) and need not be defined in FI. They will be used for internal allocation purposes only.
Activities incurred in hours multiplied by rate gives Activity cost (Secondary cost).
The Secondary Cost Element will be used for reporting the total time and cost incurred by an employee for single or multiple projects.
Below is the initial list of activity types for Licensing that will be created in the system:
Activity type Description
1000 Normal Hours
1100 Overtime | Mon-Fri
1500 Overtime | Sat-Sun
2000 Overtime | Bank Holiday

Below is the initial list of activity types for Formox that will be created in the system
Activity type Description
1000 Normal Hours
1100 Overtime | Mon-Fri
1500 Overtime | Sat-Sun
2000 Overtime | Bank Holiday

Below is the initial list of activity types for R&D that will be created in the system
Activity type Description
1000 Normal Hours
1100 Overtime | Mon-Fri
1500 Overtime | Sat-Sun
2000 Overtime | Bank Holiday

The secondary cost elements represent the flow of costs internally because these costs are created and used only in Cost accounting. They are used to secure that the source of costs can be traced. These cost elements are used in cost allocations and overhead calculations.

The rates for the activities will be updated on standard transaction KP26. The rates will need to be updated at least once a year.
Note: It is expected that there will be different rates per role assigned, this will be defined during the build phase with input from the businesses and HR.
2.5.2.7. Timesheet reporting
Various Standard SAP reports will be available to JM CT employees for analysis and reporting of timesheets.
The following list describes the initial reports that will be used and validated with the business to review information related to timesheets.

Configuration Object Description Existing / New Relevant Site Configuration Source
CATS_DA Display Working hours Existing/SAP Standard All Sites Not required
CJI3 Actual Line-Item Report Existing/SAP Standard All Sites Not required
Note: Development of additional reports for timesheets for Licensing, Formox and R&D is not being considered at this point of the project. This will be confirmed during the build.

CATS_DA Report
TCODE: CATS_DA, Display Working Times
Report: RCATS_DISPLAY_ACTIVITIES
Path: Human Resources → Time Management → Time Sheet → Information System → Display Working Times
This SAP standard report can be used by the different CT businesses to view working hours, WBS elements, networks, activity types, processing status (In progress/Approved/released etc), approvers, Timesheet filling and approval dates etc

All CT business group users will have the option to customize above fields as per their requirements. Number of hours, timesheet status, Activity type, who changed the timesheet details (Last changed date) can all be reported as shown above.

All CT business group users will have option to customize above fields as per their requirement, approved by, approval date, username, user employee ID etc as shown above.
CJI3 Report
TCODE: CJI3, Actual Cost Line Items for projects
Report: RKPEP003

Report CJI3, Project Actual Cost Line Items – This report is used to review and analyse expenditure line items posted against projects.
As shown in the above screenshot, we can see the total cost incurred by WBS 1710-2021-0007-02.01 based on document dates.
2.5.3. Integration with procurement
Purchase orders will be able to be booked against WBS elements. This will allow the user to know the commitment per project. This also means that goods receipt/invoice receipt will be recorded for the project.
The SAP PS module is integrated with MM through the usage of networks. This allows the automatic creation of purchasing data (reservations and purchase requisitions) in logistics (MM module) to fulfil the requirements for the project.

Direct procurement for non-Stock items:
Material with Item Category “N – Non-Stock” are procured directly by the network activity. Purchase requisitions are created for these components. When the goods are received, they are posted directly to the activity and do not go through the stock.
When using direct procurement with item category “N”. Two procurement types are possible:
• Purchase requisition for the network
• Third-party
Stock materials are not considered in the design for JM CT projects, and this includes Licensing, Formox, and R&D, as in general JM CT projects buy parts from third parties.
The user will be able to request the purchase of services or materials and trigger the creation of the purchase requisition from the project builder (Tcode: CJ20N).

The Implementation of this process will allow the user to know the total value of purchase requisitions and purchase orders open per project.
In summary, the user will be able to visualize per project their “commitments” because every PO will be referenced to a WBS element or Network/activity.
The procurement process has already been documented in the STP FDD document: FDD001 STP – Project Concert.
2.5.4. Integration with Sales
This integration will be explained in more detail in section 2.6 Capture Project Revenue (Billing) of the current document.

2.6. Capture Project Revenue (Billing)
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.05.01 Maintaining policy and procedure for revenue recognition
• 03.08.05.02 Milestone billing for revenue projects
• 03.08.05.03 Normal billing for revenue project
• 03.08.05.04 Resource related billing for revenue project
• 03.08.05.05 Account Revenue recognition
2.6.1. Maintain Policy and Procedures for revenue recognition
Revenue recognition is an accounting principle used to determine when and how revenue is recognized for accounting purposes. By using the result analysis functionality, the different businesses will be able to calculate revenue recognition on projects, based on the guidelines established for each business. For the Licensing and Formox Plant Design businesses CT will adopt the cost-based percentage of completion method to recognize revenue for revenue projects

Business Revenue Recognition Methods Existing / New
Licensing Required 1- Revenue Recognized = Plan revenue x POC
POC = actual costs incurred / Forecast total costs
2- PIT = Revenue Recognition equal to actual cost (at one specific point of time) In scope
Formox Required 1- Revenue Recognized = Plan revenue x POC
POC = actual costs incurred / Forecast total costs
2- PIT = Revenue Recognition equal to actual cost (at one specific point of time) In scope
R&D Not applicable Not applicable Out of scope
2.6.2. Milestone billing for revenue projects
Milestones will be used by JM CT in a project to designate significant events or the completion of a project phase and in determining billing document value, based on the amounts established in the contract.

For CT businesses it has been agreed that the milestones will be created by the project manager in the project (Tcode: CJ20n), but these milestones will be used only to inform and to report the completion of the phase.
There will not be any kind of integration between milestones and sales orders, the completion of a milestone will not trigger any additional action in the system.

The milestones will have to be created first in project builder (CJ20n). For CT there will be specific WBS elements defined in templates to allocate the revenues collected.

The setup of the milestones in the project structure will be performed by the project manager, who will have to work with the commercial team to review and translate into milestones, the commercial conditions agreed in the contract signed by the client.
The project manager will have the option to create the milestones required on their project and assign the correspoding description (this will be a free entry field text).
The project manager will be able to release a specific milestone manually (TCODE: CJ20n) to the accounting department (this will not be an automatic process), the accounting department will receive a email notification from the PM requesting the creation of the invoice, but the invoice created will not be sent directly to the client; This will only happen when all the supporting documentation of the milestone has been collected and has been reviewed by the project manager.
Currently, is considered that only the Licensing and Formox Plant Design businesses will use this process between milestones and sales orders. R&D is not planned to use this functionality; However, the configuration and the functionality will be available if required.

Milestone billing will be applicable for revenue projects for Licensing and Formox Plant Design businesses.
Milestones will be flagged as Billing Elements and the milestone must be release prior to SD invoicing.

Configuration:

Configuration Object Description Existing / New Relevant Businesses Configuration Source
SIMG It will be necessary to define one generic milestone usage. New Licensing, Formox and R&D NA

CT will have standard milestones for revenue where the actual revenue in the projects will be reflected and when the billing will be carried out by the sales team.

Note:
It has been already commented on this document, but the milestones in PS will be used only for indicative purposes. There will not be any kind of action associted of action triggered once the milestone has been released.
There is no need to customize any integration standard integration between PS and SD.

Standard functional flow to be implemented in JM CT
The maintenance of the “Billing Indicator” in the Project Structure (CJ20n) is critical for planned and actual revenues and to make the values visible in PS. This setting allows for planned revenue on WBS elements.
For CT projects, WBS elements that will have active this indicator will be pre-established in the definition of the templates.

Customization Prerequisites:
Transactions: OPSB and OPSA, the configuration rational has been explained on section 2.3 Project planning.

To ensure that planned revenues flow from the Sales Order, it is important that the planning profile associated with the project contains certain customization settings as shown below. For CT the Planning Profile will be assigned to the project profile which is used to create the project as shown below.

In section 2.2.3, Project Profile in this document, the planning profiles that will be created per project profile are defined.
The planning profile should have the check box “from the sales order” selected if the values need to come from sales order, this is required for CT.

PS Transactions (CJ43)
In CT transactions CJ42/CJ43 (revenue planning) or CN41 (PS Financial reports) will be used to check if the revenue has transferred to the WBS element from the sales order.
In this example, as only 30% is to be billed at “contract sign” this year and the remaining revenue is due next year, as shown by the dates in the billing plan, the “sales order value” column in CJ43 shows the distribution of the revenues across this period.

The Cumulative column shows total values for both years (Sales Order Value + Prev Year). The “Sales Order Value” shows the amount to be billed in 2008. When the actual billing is done as per the dates in the billing plan, the actual revenue gets posted to the WBS elements.
Standard report CN41 – PS Information Report
CT users in Licencing and Formox Plant Designs will be able to review planned revenues on the WBS elements, with the values flowing from the sales order to the WBS elements

In the previous screen the superior WBS elements/project definition can act as the pivotal point, on which costs and revenues can be compared and act as monitors to review profitability in the project.

These reports will be available to better monitor cash, cost & revenue flows.
2.6.3. Account revenue recognition (Result Analysis & POC and PIT)
As mentioned in Section 2.6.1, the Licensing and Formox businesses will adopt cost based POC method for revenue recognition for some activities.
To achieve this it will be required to assign the result analysis key which is defined as a part of the configuration into the Billing WBS element, which is assigned to the sales document (Sales order).
The result analysis key will be assigned a WBS element and only for Revenue WBS elements.

Result analysis key:
The result analysis Key will be assigned at WBS element level during the creation of the project. Because every result analysis key can only hold one calculation method, it will be necessary to create additional RA keys to cover the two revenue recognition methods requested by the business.
This initial definition will be inherited from the project template definition, so the following 4 Result Analysis Keys will be created as configured below.

Result Analysis key Description Calculation Method Existing / New
LIPOC1 Result analysis key Licensing – Percentage of completion 03 Cost-Based POC Method In scope
LIPIT1 Result analysis key Licensing – Point in time 16 Cost-Based POC Method witout profit realisation In scope
FOPOC1 Result analysis key Formox – Percentage of completion 03 Cost-Based POC Method In scope
FOPIT1 Result analysis key Formox – Point in time 16 Cost-Based POC Method witout profit realisation In scope
(to be confirmed)
Note:
The previous table describes the methods that will be available and the “calculation method” to be used. This method will be tested and their configuration will be ajusted (if is required) during the realisation phase.
During the period end, results analysis will be performed on those WBS elements which are assigned to sales orders, like license agreement, engineering agreement, catalyst agreement etc in Licensing business.
While doing result analysis on a WBS element the system will consider all sub level WBS elements and Network activites under it to calculate the result analysis. Result analysis will consider various data like actual cost of work done, forecast total cost (not budget), planned revenue and actual revenue (Milestone billing).
Result analysis will calculate the results but it will not post any values to Finances, unless the settlement process has been executed.

Methods that will be available for CT based on business requirements
Percentage of completion method (POC) - Cost Based
Under this method:
• Calculate POC of a project based on how much has been already spent on the project in comparison with thetotal forecast cost, i.e., POC = (Actual Cost/Total Forecast Cost) * 100
• Recognize revenue to the extent of POC, i.e., Calculated Revenue = Planned Revenue * POC
• There will be no change in reported cost
Revenue Based Method
Under this method:
• We keep revenue as it is;
• Calculated Cost = (Actual Revenue/Planned Revenue) * Planned Cost
• There will be no change in reported revenue
Point in time
Under this method:
• We consider the actual cost acumulated as the total revenue to be recognized
• Revenue recognition = Actual cost acumulated at the point in time of the calculation
• There will be no change in reported revenue, because there is no revenue in this case

Rational:
The configuration of RA for the calculation of revenue recognition for the different CT businesses has been conceptualized as follow.
Result analysis will use the following inputs to calculate the revenue recognition effect, to be posted in the P&L and BS for each business at the end of the period.

Revenue assignments:
Licensing - As per the project structures already established for the different CT businesses, for the Licensing business the revenues will be allocated at contract level.

Is at contract level (WBS element) where the different RA keys will be assigned and depending on the method defined by the user to calculate revenue on this contract.
There will be a clear guideline established on the method to be used to calculate revenue recognition per type of contract.
Example:

For the Licensing business RA will be executed at WBS element at Work order level.
Formox - As per the project structures already established for the different CT businesses, for the Formox business the revenues will be allocated at contract level.

Is at project level (WBS element) or WBS element “root” where the different RA keys will be assigned and depending on the method defined by the user to calculate revenue on this contract.
There will be a clear guideline established on the method to be used to calculate revenue recognition per type of contract.
Example:

For the Formox business the RA will be executed at WBS element at contract level (WBS root).
For the two previous CT businesses the RA keys as it has been commented before, will be predefined in the project template and the project manager will have the option to change it.
The following example is trying to present how RA will work.
For this case, there is a contract with plan revenue of 100.00 and a plan cost of 80.
During the first month the revenue (invoiced to the client) achieved is for: 10 and the cost incurred is 2.
Example 03:
RA analysis will calculate the following effect for POC first:
(2 / 80) *100 = 2.5% - so POC equal to 2.5%

Then Revenue recognition will: 100 (plan revenue) X POC (2.5%) = 2.50

Note: this is an example that correspond to the use of the RA method 03.

To achieve the above it will be necessary setup the following configuration:
Configuration required:
Conf. Object Description Rational Existing/New Relevant Site
OKG1 Create a result analysis key In this configuration transaction is where the RA keys will be defined for each of the businesses mentioned above. New Licensing/Formox
OKG2 Define the result analysis versions for the key In this transaction will be configured the RA version.
RA works at controlling area and the version to be used is the version 0. New Licensing/Formox
OKG3 Maintain the valuations methods for the versions On this transaction it will be assigned the RA key to the RA version to be used.
For Licensing and Formox is considered to use the version 0. Example:

Is on this transaction where the calculation method will be selected, that for POC currently is planned to use method 03 – cost-based POC Method

And for PIT (point in time method) is currently planned to use the calculation method 16.

The method will be tested in expert mode to review and maybe ammend some parameters. New Licensing / Formox
SIMG / (SPRO) Define the line ID’s and the cost elements relevant for RA On this transaction the Line ID’s will be configured, however is currently considered the use of the following standards:
New Licensing/Formox
OKG5 Define the updates for RA On this transaction will be configured the different range of accounts that will have assigned every Line ID. Basically is to establish the accounts that will collect revenues on projects and costs.
These accounts will be defined during the realisation phase, because the GL account mapping for Licensing has not started yet.
This transaction helps RA to identify the GL accounts with postings, that needs to be considered for COP, COS, REV and SET as per the previous transaction.
Example:

This configuration is necessary, otherwise, the system will not be able to determine and for calculation purposes, the amounts that are revenues and amounts that are costs. New Licensing/Formox
OKG8 Setting the posting rules for settlements from RA On this configuration transaction it will be defined the accounts that the system will use to post into finances the revenue recognition results.

This account deterrmination will be defined during the realisation phase.
New Licensing/Formox

Result analysis process:
As per the configuration commented, RA will create the following postings and will take in consideration the revenues accumulated.

Example:
The first posting will reflect the revenues collected by the project.

Notes:
• The user will have the option to execute this process in “test” as many times they required before transferring the final amounts to Finances.
• This will help the user to review case by case (project) to perform any change or amendment in the information.
• The calculated results obtained by RA will be saved but will not be posted into Finance, until the project settlement has been executed (08.01.06.02 Perform project settlement).
• Once the user has confirmed the results, the settlement will create the postings established in the account determination of RA.

The revenues will continue to be posted into the current accounts, but now using the global chart of accounts defined by JM (the accounts will be confirmed during the realisation phase).

The next posting presents the allocation of costs into a project that will come from timesheets and purchases (goods or services with reference to a project).

Example:

Finally, depending on the method used, RA in SAP will generate the following posting at project level, to recognize the revenue calculated.

RA will calculate the effect and will generate a posting per project “Debiting the cumulative revenue account” and “Crediting Revenue”.
This effect will be posted on the last day of the period and then, the system will create a reverse movement on the first day of the following period.

This is because RA will calculate the revenue recognition for a project in a cumulative basis depending on the NEW progress achieved in the month.

The main target is that the different CT businesses must have a “netting effect” in their revenue accounts against their balance sheet, as the following diagram presents.

Result analysis process
In CT, a project will be created with the required structure (following the template structures), but the forecast (cost and revenue) will have to be maintained in the corresponding planning version (this has been explained in more detail in section 2.3 of this document)
Note: the revenue forecast can be taken automatically by the system from the dates in the billing plan.
Revenue relating to the project should be posted from SD (billing) to the WBS elements.
During period end, Result Analysis (Transaction KKA2) will be performed on the project to match cost and revenue. It is performed at WBS level and considers all the sub level WBS elements and Network Activities under it.
To calculate and propose accounting adjustment entries as per matching principle, Result Analysis considers various data like planned cost, planned revenue, actual cost, actual revenue, method to be used to match cost and revenue, and GL accounts to be posted. Result Analysis does not post any accounting entries.
E.g.

The calculated results obtained by RA will be saved but it will not be posted into Finance, until the project settlement has been executed with transactions CJ88 or CJ8G.
Following Result Analysis, the next step will be the Settlement (Transaction CJ88) of the project.
The Settlement of the project will be performed based on the settlement rule assigned. Normally in the case of customer projects for Licensing and Formox, settlement happens on COPA.
Settlement will post settlement accounting entries as well as result analysis entries.

Result Analysis Key
If you want to settle amounts from result analysis, you need to maintain results analysis key for the relevant object. The Key contains all the relevant control data necessary for result analysis.
In CT, we have the following options for settling objects within a project (WBS Elements, Networks, activities)
Direct Settlement- Each object is settled directly to the external cost object (example Cost centre, profitability segment)
Multi-level Settlement – Settles individual objects in the project to the higher level WBS element first. This then settles the costs collected to the corresponding receiver.
Configuration Object Description Existing / New Relevant Site Configuration Source
Maintain Settlement Profile Settlement Profile New All Sites NA
Maintain Settlement Rule Settlement Rule New All Sites NA
Define Result Analysis Key Result Analysis Key New All Sites NA

Project Closure
The CLSD status (Closed) will allow the user to declare a project officially closed, this means that it will not be possible to make any change to the project costs or create new invoices or Purchase Orders.
Closing a project will have to be performed in transaction CJ20n, by changing the system status to closed.

2.7. Project Monitoring
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.06.01 Perform Project Reporting Budget/Actual/Commitment/Plan
• 03.08.06.02 Perform integrations with another project management tool
2.7.1. Scope
For project monitoring purposes, there have been identified the following integrations between SAP with legacy systems or applications currently used by CT.

Below is the list of the integrations already identified:
Business Description Type Comments:
Licensing Integration with Primavera SAP standard Report
(manual) Outbound only
Licensing / Formox Integration with Tableau (Segmentation) SAP standard Report
(manual) Outbound only
R&D Integration with KeyedIn SAP standard Report
(manual) Inbound and outbound

All business Integration Workday/HR-Mini-master Interface (automatic) Inbound only
2.7.2. Integration with Primavera
Primavera is a project management tool, currently used by the Licensing business to prepare reporting information regarding forecast and availability per project.
For the new design, Licensing will continue using Primavera to prepare the current reports requested by the business. There will be a manual interface where the user from Licensing will be able to download the information requested from SAP to an excel file.
There will be a predetermined “layout” in SAP defined in the following report, that the user will use to extract and present the information with the content required.
Report transaction: Description Existing / New Relevant Site
CJI3 Actual Line-Items Report Standard All sites
This will be an “outbound” interface from SAP PS to Primavera and the extraction process will manual.

Current situation:
Currently the business is following the next process to extract and process this forecast:

Future situation:
The following diagram shows how the new process will operate.

The user will be able to create and extract a file from the system with the following structure:

Field SAP Field Description
Project PSPID Project Number
Project Name POST1 Project Name
WBS element PSPNR WBS element (discipline)
Start date AFVGD Start date
End date AFVBD End date
Date BUDAT Date when the hours were booked
Manhours MEGBTR Hours booked
Manhour Costs WTGBTR Cost of hours booked

The final layout will be agreed and reviewed with the business during the build base.
2.7.3. Integration with Tableau (R&D)
For the integration between Tableau and SAP, there will be available a manual download that the user will be able to execute, to extract from SAP the data required by this interface.
The user will have the following transaction available to generate, first, the layout with the data required from the report and then, the data extracted can be downloaded to a flat file.

Report transaction: Description Existing / New Relevant Site
CJI3 Actual Line-Items Report Standard All sites

The user will be able to create and extract a file from the system with the following structure:

Field SAP Field Description
Segment USR001 Segment
Project PSPID Project Number
WBS element PSPNR WBS element (discipline)
Start date AFVGD Start date
End date AFVBD End date
Date BUDAT Date when the hours were booked
Manhours MEGBTR Hours booked
Manhour Costs WTGBTR Cost of hours booked

This will be an “outbound” interface from SAP PS to Tableau and the extraction process will manual.
The final layout will be reviewed during the realisation phase.
2.7.4. Integration with KeyedIn
For the integration between SAP and KeyedIn there has been identified two main interfaces that will be perform manually.
A. Project creation
B. Project actuals

A. Project creation. - for project creation, every time a project is created in KeyedIn the user will have to create manually and simultaneously the project in SAP CJ20n.
a. The creation in SAP will be a manual process and the project structure of the project, will have to follow the project template defined for R&D in sections 2.2.2 and 2.2.7 Project Templates of this document.
b. The user will populate manually in a predefined "user field" from the project, the project number used by KeyedIn to setup the project. This is how the user will be able to identify the project in SAP and in KeyedIn.

B. Project actuals (times). - SAP will transfer manually to KeyedIn the hours allocated into a project, plus their equivalent in cost.
a. As part of the standard functionality defined, SAP is converting the hours allocated in projects by multiplying the units (hours) against the hourly rate established for the activity developed.

The following diagram describes the two integrations that SAP will have with KeyedIn.

Project actuals – extraction:
For the extraction of the project actuals, the user will have the following transaction available to generate, first, the layout with the data required from the report and then, the data extracted can be downloaded to a flat file.

Report transaction: Description Existing / New Relevant Site
CJI3 Actual Line-Items Report Standard All sites

The user will be able to create and extract a file from the system with the following structure:

Field SAP Field Description
Project PSPID Project Number
WBS element PSPNR WBS element (discipline)
Date BUDAT Some way of identifying the period - may be better to have start/end dates
Manhours MEGBTR Hours booked
Manhour Costs WTGBTR Cost of hours booked
KeyedIn Project no. USR03 KeyedIn Project number (user field in the WBS)
Once the file has been downloaded, the user will just have to import it into KeyedIn, following exactly the process already defined by JM R&D.
2.7.5. Integration with Workday
For CT there will be an important integration between the current global HR system Workday and SAP HR.
This interface, will transfer information related with the master record of the employee from Workday to SAP HR.
This interface and integration have been explained in detail on the section 2.5.2 Maintain HR Mini master in this document and the integration will be as follow:

2.8. Project Period End/Year close
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.07.01 Result analysis
• 03.08.07.02 Perform Project Settlement
• 03.08.07.03 Project Closure
• 03.08.07.04 Project Year end Close
2.8.1. Introduction

For JM CT the month-end and year-end processes for projects are quite simple, in terms of the processes that need to be executed.
There are two main processes that will have to be executed for projects in JM CT every month:
1. Result analysis
2. Project settlement

These processes must be executed every month-end and should be part of the financial month-end close process established by RTR.
These two processes will have to be executed in this order:
• Result analysis
• Settlement
For the year-end close process, there will be some additional processes that will have to be executed:
1. Budget Carry Forward
2. Commitment Carry Forward
2.8.2. Perform Result Analysis
Results Analysis (RA) is a functionality in SAP Controlling to value ongoing, unfinished activities, such as service activities on projects at month-end.
With Result Analysis the JM CT businesses will be able to calculate revenue recognition on projects.
The configuration objects for the result analysis are explained above in section 2.6.4. Account Revenue Recognition.
Result analysis functionality will be used by the Licensing and Formox business to calculate:
1. POC – Percentage of completion
2. Revenue recognition
2.8.3. Perform Project Settlement
During the execution of the project settlement, costs and revenues which are collected in projects must be settled to one or more receivers as part of the period end processing and year-end close. In JM CT settlement function is used to settle (transfer) values from P&L accounts to Cost centres of profit centres.
The configuration will be required in project systems for all JM CT projects, to allow the business to settle values to the different receivers defined.
This configuration will be saved in the “settlement profile” and it will be defined only for WBS elements and networks, that has activated the “operative indicators”:
1. Account assignment element
2. Billing element
This configuration will be predefined on each project template, so the project settlement field will have a predefined settlement profile assigned.

Settlement Profile
For JM CT the settlement profile assigned in the project profile (during the creation) determines whether the settlement is required, allowed, or blocked.
Below is the list of the settlement profiles that will be defined for JM CT, that will be assigned to each project profile:

Project profile Project Profile Description Settlement profile Settlement profile description Existing / New
ZRD001 Project Profile for R&D ZSRD01 Settlement profile for R&D New
ZFOR001 Project Profile for Formox ZSFO01 Settlement profile for Formox New
ZLIC001 Project Profile for Licensing ZSLI01 Settlement profile for Licensing New
ZNC001 Non-Chargeable projects ZSNC01 Settlement profile for non-chargeable projects New
ZLP001 Project Proposals ZSLP01 Settlement profile for non-project activities New

Key configuration to be considered:
For JM CT the settlement rules will have a sender and receivers.
Senders: the senders will be cost element groups that will be defined during the build phase, these cost elements groups will contain the range of cost elements, where the projects collect costs from different modules.
Receivers: for JM CT there will be only 4 types of receivers.
• GL Account
• Cost Centre
• Order
• WBS element

The following table summarises the senders and receivers that will be defined for each business:

Project profile Senders Receivers Allocation structure Source structures
Licensing 2 cost element groups
• Revenue
• Cost Cost centres and
Balance Sheet accounts 1 allocation structure to be defined Not required
Formox 2 cost element groups
• Revenue
• Cost Cost centres and
Balance Sheet accounts 1 allocation structure to be defined Not required
R&D 2 cost element groups
• Revenue
• Cost Cost centres and
Balance Sheet accounts 1 allocation structure to be defined Not required
Non-chargeable projects 1 cost element group Cost centres only 1 allocation structure to be defined Not Required
Proposals 1 cost element group Cost centre only 1 allocation structure to be defined Not Required
Note:
The final set of parameters will be confirmed during the realisation phase (specially the receivers).

Configuration rationale:
Project profile Licensing Formox R&D Non-projects
To be settled in full Activated Activated Activated Activated
% settlement Activated Activated Activated Activated
Allocation structure Activated Activated Activated Activated
Receivers Activated
• Cost C.
• Profit C. Activated
• Cost C.
• Profit C. Activated
• Cost C.
• Profit C. Activated
• Cost C.
• Profit C.
Note:
The group of cost elements source will be defined during the realisation phase.

2.8.4. Year-end close in projects
For the year-end process there will be two main processes to be executed:
• Commitment Carry forward - During year-end closing, any commitment values that are still open can be carried forward to the first period of the following fiscal year. This transaction will have to be executed for every JM CT business.
• Budget carry forward - This transaction will be used to carry unused budget from a closed fiscal year forward to the next year.
This section has been described in more detail in the BPD.

2.9. Project Reporting
This section covers the following PS/TS Level 3/4 processes as defined in the BPD:
• 03.08.08.01 Project Commitments
• 03.08.08.02 Project Revenues
• 03.08.08.03 Project costs
• 03.08.08.04 Project Cash flow
2.9.1. Analysing Projects with the standard Information Systems
Within the SAP PS, the project information system is a tool to monitor and control the project data. It is possible to analyse individual projects, sub-projects, or several projects together. Overview reports and detailed reports are available.
The following set of reports will be available for JM CT, to perform analysis on project structures and individual project analysis:
Report transaction Description Existing / New Relevant Site
CN41N Structure information system Standard All sites
CN50N Capacity Analysis Standard All sites
S_ALR_87015125 Progress Analysis Standard All sites
2.9.2. Analysing Projects with Financial Reports
The following three types of reports will be available for financial reporting:
• Hierarchy reports
• Cost element reports
• Line-item reports
Each of these types of reports analyses a different level of detail; Line-item reports are more detailed than cost element reports, and cost element reports are more detailed than hierarchy reports. On the other hand, hierarchy reports run faster than cost element reports, and cost element reports run faster than line-item reports.
A reporting interface is built into the reports so that you can easily shift from one report to another. For JM CT the user will be able to go from one hierarchy report to other hierarchy reports or cost element reports by choosing the appropriate icon.
These report interfaces also enable you to go from hierarchy reports and cost element reports to line-item reports.
You can branch from line-item reports to the original documents and the various accounting documents. This allows you to drill down into the cost structure of the hierarchy report so that you can analyse the actual costs in your project. You can select fields in the report and go to a cost element report to carry out further analysis.
You can call the line-item report you require from the cost element report to display the accounting documents.
The following reports will be available for the users from JM CT to review and analyse information.

Budget reports
• Plan/Actual/Variance (S_ALR_87013564)
• Budget/Actual/Variance (S_ALR_87013557)
• Actual/Commitment/Total/Plan in CO Currency (S_ALR_87013542)
• Budget/Actual/Commitment/Remaining Plan/Assigned (S_ALR_87013558)

Logistic reports
• Commitments per month (S_ALR_87100187)
• Receipts/Expenditures (S_ALR_87100191)
• Purchase Requisitions for Project (ME5J)
• Purchasing Documents for Project (ME2J)
• Planned Orders (CN44N)

Cost reports
• Actuals per month (S_ALR_87100185)
• Annual overview (S_ALR_87013562)
• Line-item reports to evaluate line items and documents (CJI3)
• Actuals in CO, Object and Transaction currency (S_ALR_87013535)
• Cost/Revenue/Expense/Receipts (S_ALR_87013531)
• Plan/Actual/Variance for Each Project and Person Responsible (S_ALR_87100190)
• Revenue Actual Contribution Margin (S_ALR_87013566)
2.9.3. Standard Reports Available in Time sheeting
There are a few standard reports which are available in PS to review timesheets.
Actuals, budgets, and other reports are available under the information system of Time Management which allows reporting on Time Recording in Project/WBS.
Alternatively, Standard SAP report CATS_DA can be used to check timesheet working hours details.
It is a condition, however, that the timesheet must have been approved and posted to the project. Further, these reports are also extendable in terms of their data source allowing the end-user to add additional standard fields to the reports out-of-the-box.
The standard reports below are available in SAP GUI and are used to view the recorded times of the employees on the projects based on the status of approval:

Report transaction: Description Existing / New Relevant Site
CATS_DA Display working times Standard All sites
CATSXT_DA Display working times and tasks Standard All sites
CATSXT_DTL Working Times and Tasks: Display Details Standard All sites
CJI3 Actual Line-Items Report Standard All sites
2.9.4. Project reporting for segmentation
For reporting segmentation, the following reports will be used to create a predefined layout, that will contain all the information required for segmentation.

Report transaction: Description Existing / New Relevant Site
CJI3 Actual Line-Items Report Standard All sites
CN41 Structure Overview Standard All sites

The following layout will be configured in SAP PS reporting system to produce a file that will have the following structure:
Time & Cost Reporting for RD&E
Field SAP Field Description
Resource ID PERNR Employee Number
Resource Name ENAME Employee Name
Project PSPID Project Number
Project Name POST1 Project Name
Segment Group USR02 Segment Group - if possible
Segment USR00 Segment
Period BUDAT Period code - typically YEARWEEK (e.g., 202227)
Date CPUDT Date of transaction
Hours MEGBTR Hours booked
Cost WTGBTR Cost of Hours booked

Project-Based Reporting for RD&E
Field SAP Field Description
Project PSPID Project Number
Project Name POST1 Project Name
Segment Group USR02 Segment Group
Segment USR00 Segment
Period BUDAT Some way of identifying the period - may be better to have start/end dates
Manhours MEGBTR Hours booked
Manhour Costs WTGBTR Cost of hours booked
Non-manhour Costs WTGBTR Non-manhour costs
Revenue NETWR
/WODBTR (Val/obj. currency) Revenue received
Forecasts FORECAST Where available forecast information (costs, manhours, revenue)

Considerations:
1. The solution will use transaction CN41 to produce a report in ALV format with the structure listed above and then, the file will be downloaded and imported into the reporting system.
E.g.

Field selection:

2. The final layout adopted could have some minor changes vs the layout above, but this will be reviewed and confirmed during the build phase.
3. The fields will be selected from the standard fields to create a layout that meets business requirements.
4. This is not a report that will have to fulfil a specific layout for presentation purposes, this is a manual download (manual interface) to extract information from SAP to be uploaded into a different system.
5. The fields will be selected from the standard fields to create a layout that meets business requirements.
2.9.5. Forecasting report & Cost report (Licensing)
The “cost report” is a standard report used by the Licensing (only) business to know the situation of a project on a specific period. To fulfil this requirement, the project team is considering the development of a new report using “report painter” in SAP.
Report painter is a standard reporting tool in SAP to create and combine multiple views, extracting and presenting the information from multiple tables.
The following diagram is presenting the main components of this report and from where the information will be extracted from SAP.

The following image shows the layout of the report that is expected to be built.

The rationality behind the columns in the image above:

Column Description Description
A Original Budget The original budget will come from a project version created. The original budget will be updated manually into the system by the project manager.
B Approved changes Changes approved will come from changes approved on the original budget. This will also be registered in a project version.
C Current budget This field will be a calculated field that will be the result of the sum of the field A and B.
D Commitment This column will present the “commitment” that is, the total of Purchase orders and purchase requisitions created per WBS and activity
This is a new column for this report and the user of this report in general in the Licensing and the Formox Business
This is part of the improvements made by the standard integration and process in SAP.
E Spent to date This field (column) will display the total actual cost.
F Forecast to go This field will display the estimated forecast established by the project manager.
These values will be stored on a project version.
G Total Forecast This will be a calculated field that will equal the sum of D + E + F
H Budget (over/under) Calculated field
I Changes in forecast Calculated field
J Remarks The notes will be extracted from every WBS from the documentation section.
Note:
There is currently a WRICEF considered for the development of this report:
• 3.9.1. Project Cost Report.
The development of this report will be managed using the standard reporting tool from SAP Report Painter.

2.9.6. Forecasting report & Cost report (Formox)
The “Financial forecast” for the Formox business is a standard report used to know the situation of a project on a specific period.
This report will be created and extracted from the systems using standard cost elements reports.

Currently, the report is created via the monthly download of the information into excel and then is formatted and organized in excel to fulfil the requirement.
• This process will be remaining exactly in the same way that is currently managed, however, the user will have to use some different reports in PS (cost elements reporting), to download and format the information in excel.
• Some additional cost elements groups will be created for reporting purposes and the range of cost elements for each group will be determined during the build phase of the project.
• Below there is the initial list of cost elements that will be defined to group the information of this report.

Column Description
FOR-TOT-EQ&CT Total Equipment and Catalyst
FOR-TOT-ENG Total Engineering
FOR-TOT-EXEC Total Execution
FOR-TOT- OVER Total Overheads
FOR-TOT-CONT Total Contingencies
FOR-TOT-SALES Total Sales
3. Technical and Development Related Items
Following are the lists of all developments that were deemed necessary by the analysis of gaps in the process coverage, or which are needed to support a given process. If there are any other types of custom developments that are not addressed by the sections below (Examples - Some of these need to be modified, corrected, re-designed, discarded or a complete new technical development is necessitated as and when required along the implementation processes) will be dealt with case by case.

3.1. Workflow - Fiori
Following is a list of Workflow which fall under operating procedures for Project Concert:
Workflows
WRICEF
ID Description Data Object
Engaged Parties Owner
PSTM_U001 Fiori application to support timesheet entry and approval The following Fiori Apps:
My Timesheet (Version 3/Fiori 2.0)
My Time Events (Version 2/Fiori 2.0)
Approve Timesheets (Version 3/Fiori 2.0)
Approve Time Events (Fiori 2.0)
My Inbox Carl Scarlet / Marco Desentis

3.2. Report
Following is the list of Reports to be updated or build as part of project Concert.
Reporting
WRICEF
ID Description Report Type (ABAP, BI, BOBJ) Data Elements Relevant KPI Owner
PSTM_R001 Project cost report
Project Cost (budget / Actual Forecast / Variance) Report (Man hour Units and Cost on Projects + Primary Costs Report Painter Project status Carl Scarlet / Licensing

3.3. Interface
Following is the list of Interfaces identified in the source systems to be updated or build as part of project Concert:
Interfaces
WRICEF
ID Description Interface Method Application Source Target Frequency / Volumes Owner
PSTM_I004 HR Mini Master
Interface from Workday to SAP on HR Info types TBC Workday SAP ERP TBC Carl Scarlett/
Marco Desentis
PSTM_I005 HR Organizational structure TBC Workday SAP ERP TBC Carl Scarlett/
Marco Desentis

3.4. Conversion
All master and transactional data conversion requirements are covered in project Concert.
Conversions
WRICEF
ID Conversion Object Source Conversion Activities
(e.g., cleansing) Conversion Method (manual / automated) # Of Objects to be converted Owner
PSTM_C001 Activity rates for timesheets Agresso Data load for PS
SB 07/03 - New load program is needed for existing SAP entities, Agresso and JDE (Check with CS) TBC Carl Scarlett/
Marco Desentis
PSTM_C002
1001 Activity types Agresso TBC TBC Carl Scarlett/
Marco Desentis

PSTM_C003
1060-Project/WBS element Agresso
/JDE
CAPEX projects are not in scope.
SB 07/03- load program (Create/Change) needed with the reference of UNIFY DCT template TBC Carl Scarlett/
Marco Desentis

PSTM_C004
075-WBS Budget Agresso
/JDE
SB 07/03 - New load program to create and update the budget TBC Carl Scarlett/
Marco Desentis
PSTM_C005
1077-WBS Plan Agresso
SB 07/03 - New load program to create and update TBC Carl Scarlett/
Marco Desentis
PSTM_C007
Project Hours Agresso Will be migrated all the hours allocated on projects. TBC Carl Scarlett/
Marco Desentis
PSTM_C006
Network
/Activities Agresso
Scope not yet defined, depends on Project structure. Data Load may be needed here. TBC Carl Scarlett/
Marco Desentis

3.5. Enhancements
List the required Enhancements based on the proposed gap resolutions listed in the Detailed Requirements and Design Documents.
Enhancements
WRICEF
ID Description Data Object (Sales Order) Functional Gap Alternative SAP Standard Reason Owner
PSTM_E003 PS User defined fields and validation Implementation of User Fields in WBS elements plus ability to provide defined list of available entries for these fields where required User Fields for Segmentation (market + Customer + Material) Carl Scarlett/ Marco Desentis

3.6. Forms
Following is the list of Outputs and Forms. A separate Techno-Functional document will be maintained once the new form layout details are provided by the business:

Output/Form
WRICEF
ID Description Data Object (Sales Order) Output Type (Form, EDI, etc.) Frequency Volumes Owner

3.7. Modifications
Modifications expected for the Custom Transactions (Z Transaction Codes):

Modifications
WRICEF
ID Description Report Type (ABAP, BI, BOBJ) Data Elements Relevant KPI Owner

4. Appendix
4.1. Segmentation
The following table details the segmentation structure that will be used to tag projects within CT. This is to enable reporting of time and costs based on market segments. This list will be used to create a table from which the segment can be selected when a project is created. The table will use the column of names that are 20 characters long or less due to limitations with the User Fields in SAP.
URN Category Group Value Chain Segment Group Segment Segment for User Field
(≤ 20 characters)
URN01 Base Business Building Blocks Formaldehyde Formaldehyde - Wood & Chemicals Formaldehyde - W&C
URN02 Base Business Building Blocks Methanol Methanol - Fuel Additives & Chemicals Methanol - F&C
URN03 Base Business Building Blocks Nitrogen Amines Amines
URN04 Base Business Building Blocks Nitrogen Ammonia - Fertilizers & Chemicals Ammonia - Fertil.
URN05 Base Business Building Blocks Nitrogen Nitric Acid Nitric Acid
URN06 Base Business Building Blocks PTA PTA PTA
URN07 Base Business Fuels & Energy FCC Additives FCC Additives Additives
URN08 Base Business Fuels & Energy FCC Additives (ZSM-5) FCC Additives (ZSM-5) Additives (ZSM-5)
URN09 Base Business Fuels & Energy Gas Purification Natural Gas Processing Nat. Gas Processing
URN10 Base Business Fuels & Energy GTL GTL GTL
URN11 Base Business Fuels & Energy Refinery Fuels Refinery Fuels Refinery Fuels
URN12 Base Business Fuels & Energy Refinery Hydrogen Refinery Hydrogen Refinery Hydrogen
URN13 Base Business Fuels & Energy Refinery Purification Refinery Purification Refinery Purif.
URN14 Base Business Fuels & Energy SNG SNG from Coal SNG from Coal
URN15 Base Business Intermediates Acetic Acid Acetic Acid Acetic Acid
URN16 Base Business Intermediates Agchem Paraquat Alternatives Paraquat Altern.
URN17 Base Business Intermediates Alcohols Alcohols - Detergent Alcohols Alcohols - DA
URN18 Base Business Intermediates Alcohols Alcohols - Natural Detergent Alcohols Alcohols - NDA
URN19 Base Business Intermediates Alcohols Alcohols - Oxo-Alcohols Alcohols - Oxo
URN20 Base Business Intermediates Alcohols Alcohols - Polyols Alcohols - Polyols
URN21 Base Business Intermediates Alcohols Alcohols - Tech Polymer Diols Alcohols - Tech Pol
URN22 Base Business Intermediates Edible Oils Edible Oils Edible Oils
URN23 Base Business Intermediates Fluorochemicals Fluorochemicals Fluorochemicals
URN24 Base Business Intermediates Hydrogen Peroxide Hydrogen Peroxide Hydrogen Peroxide
URN25 Base Business Intermediates Olefins Olefins Olefins
URN26 Base Business Intermediates Oleochemicals Oleochemicals Oleochemicals
URN27 Base Business Intermediates Solvents Solvents Solvents
URN28 Base Business Intermediates Sponge Sponge Sponge
URN29 Base Business Intermediates VCM VCM via Ethylene (EDC) VCM via Ethylene
URN30 Base Business Other Copper Zeolite Copper Zeolite (77-1 and CuZe) Copper Zeolite
URN31 Base Business Other Environmental Catalysts Environmental Catalysts Environ. Catalysts
URN32 Emerging Building Blocks CO2 Purification CO2 Purification CO2 Purification
URN33 Emerging Building Blocks MEG MEG MEG
URN34 Emerging Building Blocks SNG SNG for CO2 Transport SNG - CO2 Transport
URN35 Emerging Fuels & Energy Bio-pyrolysis Bio-pyrolysis (Anellotech) Bio-pyrolysis
URN36 Emerging Fuels & Energy Blue Hydrogen Blue Hydrogen (LCH) Blue Hydrogen (LCH)
URN37 Emerging Fuels & Energy Electrolyser Gas Purification Electrolyser Gas Purification Electr. Gas Purif.
URN38 Emerging Fuels & Energy Green Hydrogen Green Hydrogen Purification for Automotive Green H2 Purif.
URN39 Emerging Fuels & Energy Sustainable Fuels non Syngas routes Biodiesel Biodiesel
URN40 Emerging Fuels & Energy Sustainable Fuels non-Syngas routes Biorefining (Virent) Biorefining
URN41 Emerging Fuels & Energy Sustainable Fuels Syngas routes FT for SAF FT for SAF
URN42 Emerging Intermediates Ethyl Acetate Ethyl Acetate Ethyl Acetate
URN43 Emerging Intermediates VCM VCM via Acetylene VCM via Acetylene
URN44 Emerging Other Low Carbon Solutions Low Carbon Solutions Low Carbon Solution
URN45 Emerging Other Plastics Recycling Plastics Recycling - Catalytic Pyrolysis & Purification Plastics Recycling
URN46 Emerging Other Ventilation Air Methane Abatement Ventilation Air Methane Abatement (COMET) Methane Abatement

5. Design Authority Board (DAB) Work Package Sign-off
Release Chapter Scope Item Sign-off(Y/N)