Spaces:
Runtime error
Runtime error
| Project Concert | |
| BPD002 – Sales to Cash (STC) | |
| Business Process Document | |
| V2.00 Re-Baseline following Approval | |
| 23/05/2022 | |
| BPD STC Sales - to - Cash | |
| Purpose: The objective of this document is to summarise the validated Concert Programme business processes for STC Processes including: | |
| • Business scope and requirements | |
| • Site-specific variation | |
| • Detailed business activity | |
| • High-level roles and skills | |
| • Integration points | |
| Scope: In scope is the key activities of day-to-day Sales to Cash management, more specifically processing customer sales orders, customer payments, customer credit management and intercompany processing. | |
| Summary: All sales related activities should be harmonized and improved for sites already on SAP. The sites not using SAP will be consolidated to the SAP system and adopt the baseline sales processes. This includes processes related to customer master data management, sales related activities (i.e. forecasts, quotations, sales orders, order confirmations, invoicing, billing plans, available to promise), credit management, and accounts receivable. | |
| Document Information | |
| Document Name BPD002 Sales to Cash V02 Master.docx | |
| Last Saved 23/05/2022 22:05:00 | |
| Printed | |
| Author(s) Bob Campbell (EY), Susan Simpson (JM), Prathima Lanki Reddy (EY), Jason Flynn (JM) | |
| Business Owner Susan Simpson | |
| Contents | |
| 1. Document Control 7 | |
| 1.1. Authors 7 | |
| 1.2. Change History 7 | |
| 1.3. Approvers 7 | |
| 1.4. Reviewers 8 | |
| 1.5. Distribution Information 8 | |
| 1.6. External References 9 | |
| 1.7. Related Business Process Documents 9 | |
| 1.8. Glossary 9 | |
| 2. Introduction, Purpose and Scope 11 | |
| 2.1. Document Purpose 11 | |
| 2.2. Document Architecture 11 | |
| 3. Business Context 11 | |
| 3.1. Concert Programme Vision 11 | |
| 3.2. Design Principles 13 | |
| 4. Design Scope 15 | |
| 4.1. Business Process Framework 15 | |
| 4.2. Organization’s Process Hierarchy 16 | |
| 4.3. Process Area Scope 16 | |
| 4.3.1. Process Areas - In Scope 16 | |
| 4.3.2. Scope Items – In Scope 17 | |
| 4.3.3. Process Areas - Out of Scope 18 | |
| 4.4. Site Related Scope 19 | |
| 4.4.1. Existing CT Site Scope 19 | |
| 4.4.2. Consolidation Site Scope 20 | |
| 5. Detailed Design 22 | |
| 5.1. Level 3 & 4 Business Processes: Flow Legend 22 | |
| 5.2. Level 3 Business Area – 02.02.04 Perform Pricing Administration 23 | |
| 5.2.1. Level 4 Process Description – 02.02.04.01 Perform Pricing Administration 23 | |
| 5.2.1.1. Level 4 Process Flows and Steps 24 | |
| 5.2.1.2. To-be Changes 25 | |
| 5.2.1.3. Site Specific Changes 26 | |
| 5.3. Level 3 Business Area – 02.03.02 Perform Requirements Evaluation 26 | |
| 5.3.1. Level 4 Process Description – 02.03.02.01 Generate Sales Forecasts 26 | |
| 5.3.1.1. Level 4 Process Flows and Steps 27 | |
| 5.3.1.2. To-be Changes 28 | |
| 5.3.1.3. Site Specific Changes 29 | |
| 5.4. Level 3 Business Area – 02.03.03 Prepare and Monitor Sales Proposals / Bids 29 | |
| 5.4.1. Level 4 Process Description – 02.03.03.01 Create Proposals 29 | |
| 5.4.1.1. Level 4 Process Flows and Steps 30 | |
| 5.4.1.2. To-be Changes 31 | |
| 5.4.1.3. Site Specific Changes 32 | |
| 5.5. Level 3 Business Area – 02.03.04 Prepare and Monitor Sales Quotations 32 | |
| 5.5.1. Level 4 Process Description – 02.03.04.01 Create Quotations 32 | |
| 5.5.1.1. Level 4 Process Flows and Steps 33 | |
| 5.5.1.2. To-be Changes 35 | |
| 5.5.1.3. Site Specific Changes 36 | |
| 5.6. Level 3 Business Area – 02.04.01. Perform Sales Order Processing 36 | |
| 5.6.1. Level 4 Process Description – 02.04.01.01 Create Customer Order 36 | |
| 5.6.1.1. Level 4 Process Flows and Steps – Create Customer Order 37 | |
| 5.6.1.2. To-be Changes 40 | |
| 5.6.1.3. Site Specific Changes 41 | |
| 5.6.2. Level 4 Process Description – 02.04.01.02 Create Order Confirmation 41 | |
| 5.6.2.1. Level 4 Process Flows and Steps 43 | |
| 5.6.2.2. To-be Changes 44 | |
| 5.6.2.3. Site Specific Changes 45 | |
| 5.6.3. Level 4 Process Description – 02.04.01.04 Create Sales Order with Billing Plan / Down Payment 45 | |
| 5.6.3.1. Level 4 Process Flows and Steps 46 | |
| 5.6.3.2. To-be Changes 49 | |
| 5.6.3.3. Site Specific Changes 49 | |
| 5.6.4. Level 4 Process Description – 02.04.01.05 Create Sales Order with Project 50 | |
| 5.6.4.1. Level 4 Process Flows and Steps 51 | |
| 5.6.4.2. To-be Changes 52 | |
| 5.6.4.3. Site Specific Changes 53 | |
| 5.6.5. Level 4 Process Description – 02.04.01.07 Create Sales Order for Intercompany Debit 53 | |
| 5.6.5.1. Level 4 Process Flows and Steps 54 | |
| 5.6.5.2. To-be Changes 55 | |
| 5.6.5.3. Site Specific Changes 56 | |
| 5.7. Level 3 Business Area – 02.04.02 – Monitor Sales Orders 56 | |
| 5.7.1. Level 4 Process Description – 02.04.02.01 Monitor Sales Orders 56 | |
| 5.7.1.1. Level 4 Process Flows and Steps 56 | |
| 5.7.1.2. To-be Changes 58 | |
| 5.7.1.3. Site Specific Changes 61 | |
| 5.7.2. Level 4 Process Description – 02.04.02.02 Execute Period End Processing 61 | |
| 5.7.2.1. Level 4 Process Flows and Steps 61 | |
| 5.7.2.2. To-be Changes 62 | |
| 5.7.2.3. Site Specific Changes 63 | |
| 5.8. Level 3 Business Area – 02.06.01 Evaluate & Monitor Customer Credit 63 | |
| 5.8.1. Level 4 Process Description – 02.06.01 Maintain Customer Credit Master Data 63 | |
| 5.8.1.1. Level 4 Process Flows and Steps 65 | |
| 5.8.1.2. To-be Changes 68 | |
| 5.8.1.3. Site Specific Changes 68 | |
| 5.8.2. Level 4 Process Description – 02.06.01.02 Complete Customer Credit Check 68 | |
| 5.8.2.1. Level 4 Process Flows and Steps 70 | |
| 5.8.2.2. To-be Changes 71 | |
| 5.8.2.3. Site Specific Changes 72 | |
| 5.9. Level 3 Business Area – 02.06.02 – Perform Customer Billing 72 | |
| 5.9.1. Level 4 Process Description – 02.06.02.01 Create Customer Invoice 72 | |
| 5.9.1.1. Level 4 Process Flows and Steps 73 | |
| 5.9.1.2. To-be Changes 75 | |
| 5.9.1.3. Site Specific Changes 76 | |
| 5.10. Level 3 Business Area – 02.07.01 Process Accounts Receivable (AR) 77 | |
| 5.10.1. Level 4 Process Description – 02.07.01.01 Process Customer Account Clearing 77 | |
| 5.10.1.1. Level 4 Process Flows and Steps 77 | |
| 5.10.1.2. To-be Changes 79 | |
| 5.10.1.3. Site Specific Changes 79 | |
| 5.10.2. Level 4 Process Description – 02.07.01.02 Process Lockbox and Manual Receipts 79 | |
| 5.10.2.1. Level 4 Process Flows and Steps – 02.07.01.02 Process Lockbox and Manual Receipts 80 | |
| 5.10.2.2. To-be Changes 80 | |
| 5.10.2.3. Site Specific Changes 81 | |
| 5.10.3. Level 4 Process Description – 02.07.01.03 Perform Bank Reconciliation 81 | |
| 5.10.4. Level 4 Process Description – 02.07.01.04 Manage Bad Debt Accounting 81 | |
| 5.10.4.1. Level 4 Process Flows and Steps 81 | |
| 5.10.4.2. To-be Changes 84 | |
| 5.10.4.3. Site Specific Changes 84 | |
| 5.10.5. Level 4 Process Description – 02.07.01.05 Create Customer Statements 84 | |
| 5.10.5.1. Level 4 Process Flows and Steps 85 | |
| 5.10.5.2. To-be Changes 86 | |
| 5.10.5.3. Specific Changes 86 | |
| 5.10.6. Level 4 Process Description – 02.07.01.06 Process Accounts Receivable with Withholding Tax 86 | |
| 5.10.6.1. Level 4 Process Flows and Steps 86 | |
| 5.10.6.2. To-be Changes 88 | |
| 5.10.6.3. Specific Changes 88 | |
| 5.11. Level 3 Business Area – 02.07.02 – Process Collections 88 | |
| 5.11.1. Level 4 Process Description – 02.07.02.01 Complete Debt Notification 88 | |
| 5.11.1.1. Level 4 Process Flows and Steps 89 | |
| 5.11.1.2. To-be Changes 92 | |
| 5.11.1.3. Site Specific Changes 92 | |
| 5.12. Level 3 Business Area – 02.07.03 Process Customer Credits 92 | |
| 5.12.1. Level 4 Process Description – 02.07.03.01 Process Customer Credits for Returns 92 | |
| 5.12.1.1. Level 4 Process Flows and Steps 93 | |
| 5.12.1.2. To-be Changes 96 | |
| 5.12.1.3. Site Specific Changes 96 | |
| 5.12.2. Level 4 Process Description – 02.07.03.02 Process Customer Credit / Debits 96 | |
| 5.12.2.1. Level 4 Process Flows and Steps 96 | |
| 5.12.2.2. To-be Changes 98 | |
| 5.12.2.3. Site Specific Changes 99 | |
| 5.13. Level 3 Business Area – 02.09.01 Maintain Customer Records 99 | |
| 5.13.1. Level 4 Process Description – 02.09.01.01 Create and Update Customer Master Data 99 | |
| 5.13.1.1. Level 4 Process Flows and Steps 100 | |
| 5.13.1.2. To-be Changes 101 | |
| 5.13.1.3. Site Specific Changes 102 | |
| 5.14. Level 3 Business Area – 02.09.02. Maintain Sales Master Data 102 | |
| 5.14.1. Level 4 Process Description – 02.09.02. Maintain Sales Master Data 102 | |
| 5.14.1.1. Level 4 Process Flows and Steps 103 | |
| 5.14.1.2. To-be Changes 105 | |
| 5.14.1.3. Site Specific Changes 105 | |
| 5.15. Level 3 Business Area – 02.09.04 – Manage Customer Payment Terms 105 | |
| 5.15.1. Level 4 Process Description – 02.09.04.01 Manage Customer Payment Terms 105 | |
| 5.15.1.1. Level 4 Process Flows and Steps 105 | |
| 5.15.1.2. To-be Changes 106 | |
| 5.15.1.3. Site Specific Changes 106 | |
| 6. Change Management: “To- Be’ Design Changes 107 | |
| 7. Key Design Decisions 107 | |
| 8. Policies and Compliance 108 | |
| 9. Key Value Drivers 108 | |
| 10. Risk and Controls 110 | |
| 11. Roles and Skills 110 | |
| 11.1. Business Role Description 110 | |
| 11.2. Business Role Change Summaries 167 | |
| 12. Business, Functional and Non-functional Requirements and Solution Design 168 | |
| 12.1.1. Business and Functional Requirements 168 | |
| 12.1.2. Non-functional Requirements 168 | |
| 13. Design Gaps 168 | |
| 13.1.1. Data Impacts 168 | |
| 14. Risks, Issues, Actions and Dependencies 169 | |
| 14.1.1. Design Risks and Issues (outstanding) 169 | |
| 14.1.2. Design Related Actions 169 | |
| 14.1.3. Process Area Dependencies 169 | |
| 15. Appendix 170 | |
| 1. Document Control | |
| 1.1. Authors | |
| Author Role | |
| Bob Campbell STC Workstream Functional Lead | |
| Susan Simpson STC Workstream Business Process Lead | |
| Prathima Lanki Reddy R2R Workstream Functional Consultant | |
| 1.2. Change History | |
| This version replaces all previous versions. Please archive any previous versions: | |
| Version Date Created / | |
| Changed Author Comments / Summary of Change | |
| 0.1 March 14, 2022 Bob Campbell / Sue Simpson / Prathima Lanki Reddy Initial draft | |
| 0.2 April 5, 2022 Bob Campbell / Sue Simpson / Prathima Lanki Reddy Updated in response to SA review. | |
| 1.0 April 13, 2022 Bob Campbell / Sue Simpson BPE Signed off version | |
| 1.1 May 19, 2022 Bob Campbell / Sue Simpson Draft after scope alignment | |
| 1.98 May 23, 2022 Matt Allen Issuing for Re-Approval | |
| 2.00 May 23, 2022 Matt Allen Recording re-approval and baselining | |
| June 17, 2022 Sue Simpson Highlighted in Red removal of CRM | |
| 1.3. Approvers | |
| This document requires the following approvals: | |
| Name Signature Role Date of Issue Version | |
| Susan Simpson STC Workstream Business Process Lead - JM April 13, 2022 1.0 | |
| Susan Simpson STC Workstream Business Process Lead - JM May 23, 2022 2.0 | |
| 1.4. Reviewers | |
| This document requires the following reviewers: | |
| Name Role Date of Issue Version | |
| Jennifer Tynski Senior Supply Chain Coordinator 3/25/22 0.1 | |
| Dave Hawkes Sales and Operations Planning Advisor 3/23/22 0.1 | |
| Helen Pitchford Credit Controller 3/29/22 0.1 | |
| Anne Rundström Eliasson Sales and Planning Coordinator 3/21/22 0.1 | |
| Gabriella Bicki Business Controller 3/21/22 0.1 | |
| Michael Moelders Accountant IFRC 3/18/22 0.1 | |
| Chris Hemke Customer Service Representative 3/18/22 0.1 | |
| Shannon Thomson Customer Service Team Lead 3/24/22 0.1 | |
| Alisen Proctor Sales Support Coordinator 3/21/22 0.1 | |
| Setu Bajpai Regional Sales Manager APAC 4/7/22 0.1 | |
| Sophia Warwick Reporting Manager | |
| Jason Flynn Financial Accounting Manager 4/5/22 0.1 | |
| Uche Nnene Business & Functional Lead - EY | |
| Ashley Winsper Data Business Process Lead - JM | |
| Aninda Roy Business & Functional Lead - EY | |
| 1.5. Distribution Information | |
| This document has been distributed to: | |
| Name Role Date of Issue Version | |
| Chris Fogg Program Manager - EY | |
| John Chopamba Unify Program Director - JM | |
| Jessica Kerruish Business Implementation Manager - JM | |
| Gemma Srodzinski-Myers Change Team - EY | |
| David Lee Roles and Controls Lead | |
| 1.6. External References | |
| The following referenced documents have been compiled but do not form a part of this document: | |
| Name Link/ Location | |
| Business Process Master List Link | |
| Master Requirements Traceability Matrix Link | |
| RAID Log Management (Master RAID Consolidated) Link | |
| RICEFW Inventory Link | |
| Change Impact Assessment Link | |
| Risk & Controls Matrix Link | |
| Functional Design Documents TBC | |
| 1.7. Related Business Process Documents | |
| Reference of other Business Process Documents impacted by this Process (End to End): | |
| Business Process Doc ID/Name Cross-function Business Process Author Link/Location | |
| BPD003 – Record to Report Evaluate and Monitor customer credit, | |
| Process accounts receivables, | |
| Process collections, | |
| Process customer credits Martin Assirati / Jason Flynn TBC | |
| BPD009 – Project Systems Project sales Marco Padron / Carl Scarlett TBC | |
| 1.8. Glossary | |
| Acronym/Term Description | |
| AP Accounts Payable | |
| AR Accounts Receivable | |
| ATP Available to Promise | |
| BPD Business Process Documents | |
| BPE Business Process Expert | |
| BPML Business Process Master List | |
| BU Business Unit | |
| CIA Change Impact Assessment | |
| CRA Credit Rating Agency | |
| CRM Customer Relationship Management System | |
| CS Customer Service | |
| CT Catalyst Technologies | |
| DoA Delegation of Authority | |
| E2E End to End | |
| ERP Enterprise Resource Planning (SAP) | |
| FDD Functional Design Documents | |
| LN Lotus Notes | |
| MDG Master Data Governance | |
| OTIF On Time In Full | |
| PO Purchase Order | |
| RFQ Request for Quote | |
| RICEFW Reports, Interface, Conversion, Enhancements, Forms, Workflow | |
| RTM Master Requirements Traceability Matrix | |
| SME Subject Matter Expert | |
| SO Sales Order | |
| STC Sales to Cash | |
| 2. Introduction, Purpose and Scope | |
| 2.1. Document Purpose | |
| This Business Process Document has been developed by Project Concert specifically in relation to the delivery of this programme. The document provides a detailed description of the organization’s related business processes and sub processes. The key business driver for this document is to provide a structured schematic that can be used for development and for future operational reference. | |
| This document aims to outline the business process, interfaces, controls, measures, systems, and roles for the business processes of Sales to Cash (STC). This document covers the scope of capabilities indicated below. | |
| This document provides the detail to support: | |
| • Guiding principles to design the future state of the CT Business function and more specifically STC with the enablement of SAP technology | |
| • Process flow diagrams with associated process narratives | |
| • Agreed specific STC requirements in the context of what is to be designed for the business function and configured in SAP | |
| • Agreed site-specific requirements in the context of what is to be designed for the business function and configured in SAP | |
| 2.2. Document Architecture | |
| The intention of this BPD document is to detail: | |
| • The process area scope | |
| • A summary of the key changes agreed through the workshops for each process area | |
| • The Level 3 and 4 process inventories (otherwise abbreviated to L3 / L4) | |
| • The design decisions for each component impacting the operating model | |
| 3. Business Context | |
| The context for the programme is outlined below. | |
| 3.1. Concert Programme Vision | |
| The goal of the Concert programme is to enable the delivery of the Concert business case, decommissioning of legacy ERPs (Agresso and Minox) and to harmonise and improve the SAP processes for the Catalyst Technologies (CT) Business Unit. | |
| Project Concert will deliver a value design that supports: | |
| • A strategic standard technology platform supported by SAP ECC 6.0 EHP 7 fit for the future of our business | |
| • A consistent enterprise and data design (e.g., chart of accounts design), underpinned by robust data controls and governance | |
| • Harmonized and improved sales, procurement, finance, manufacturing, logistics, maintenance, R&D and licensing processes and controls | |
| • Harmonized and improved transparency of reporting within ECC | |
| • A single version of the truth for financial reporting, compliance, and control | |
| • Vastly improved insight into our business drivers, allowing us to make the right decisions earlier | |
| • Business-driven change to enable the adoption of consistent and leading SAP practices. | |
| At the end of the Concert programme, there will be a step change from how the CT business works today. | |
| 3.2. Design Principles | |
| Theme No Design Principle Descriptions | |
| Value Based Design and Build | |
| 1 Concert scope is bounded by the Catalyst Technologies Business unit; it will prioritise scope that achieves the goals of “Harmonisation”, “Improvement” and “Consolidation” prioritised based on value (maximise benefit, maximise ROI and minimise implementation cost) | |
| 2 Scope classified as achieving “Harmonisation” will adopt the best of what exists today within CT business | |
| 3 Scope classified as achieving “Improvement” will either adapt from Group / JM Standards / Unify or from Industry reference models / SAP Standard Best Practice | |
| 4 Scope classified as achieving “Consolidation” will adopt the target SAP design (incl. any integrated applications) | |
| 5 Concert Scope should consider vendor roadmaps and end of life dates to avoid regret spending on obsolete technology. | |
| Business Led Adoption 6 CT BPEs (Business Process Experts) and Subject Matter Experts (SMEs) will own and govern the Concert design | |
| Leverage JM and Global Best Practice Approach 7 Concert design will not compromise health & safety, regulatory compliance, controls, and service continuity | |
| 8 Group / JM standards / Unify processes will be adapted for “Improvement” scope | |
| 9 Concert design will align with the JM Target Architecture | |
| CT Process Design Aligned to Global Framework 10 Concert will establish a new CT Business Process Master List (BPML) that defines the E2E processes and numbering taxonomy for the CT business | |
| 11 CT BPML will cover the full E2E processes down-to Level 1 to Level 3. BPML Level 4 and below will only be defined for prioritised Concert scope items | |
| 12 Levels 1 to 5 of the CT BPML will follow the globally agreed process architecture levels and design standards | |
| 13 Concert design aligned to agreed target operating model and CT organisational changes needed to realise the Concert Business Case | |
| Fit to Standard Approach | |
| 14 Processes designed for cross-site standardisation while minimising site-specific variants / localisations | |
| 15 Concert design will minimise customisation to reduce the cost and complexity of the solution | |
| Figure 1 Overarching Concert Design Principles | |
| The Concert Programme will be based these 15 key Design Principles: | |
| Figure 2 Overarching Concert Design Principles Themes | |
| 4. Design Scope | |
| 4.1. Business Process Framework | |
| During the Prepare and High-Level Design phases a future state level 1 and 2 process frameworks was defined and produced to provide a schematic view of how CT Organisation wished to transform the business to best deliver on the vision. This model gives a complete view of all the processes needed to function as a chemical manufacturing organisation. The scope of the Concert programme is articulated in the diagram below. Defined scope items are agreed and documented within Event Scope Items V1 Baselined.xlsx | |
| Other aspects of the process framework out of scope for Concert will be impacted through other initiatives. | |
| Figure 1 - CT business process framework | |
| 4.2. Organization’s Process Hierarchy | |
| During Detailed Design the Concert Programme aims to provide Level 4 detail for impacted processes in accordance with business process definitions: | |
| Figure 2 - CT Process Hierarchy | |
| 4.3. Process Area Scope | |
| 4.3.1. Process Areas - In Scope | |
| This BPD refers to the STC process areas shown below. | |
| Figure 3 – Processes in Scope | |
| The STC process covers the following Level 3 Process areas. | |
| • 02.02.04. Perform pricing administration | |
| • 02.03.02. Perform requirements evaluation | |
| • 02.03.03. Prepare and monitor sales proposals/bids | |
| • 02.03.04. Prepare and monitor sales quotations | |
| • 02.04.01. Perform sales order processing | |
| • 02.04.02. Monitor sales orders | |
| • 02.06.01. Evaluate and monitor customer credit | |
| • 02.06.02. Perform customer billing | |
| • 02.07.01. Process accounts receivable | |
| • 02.07.02. Process collections | |
| • 02.07.03. Process customer credits | |
| • 02.09.01. Maintain customer records | |
| • 02.09.02. Maintain sales master data | |
| • 02.09.04. Manage customer payment terms | |
| 4.3.2. Scope Items – In Scope | |
| Scope Item Number Scope Item Name Scope Item Description | |
| 2.2.4 Target pricing validation Implementation of statistical pricing and a report to highlight variance from actual (BAG Paper 38 brought this into scope.) | |
| 2.3.1 Receipt of forecasts and quotes from CRM Microsoft Dynamics and export to S&OP forecasting tool | |
| Integration of new CRM forecasts and quotes to SAP and SAP to S&OP forecasting tool | |
| 2.4.1A Introduction of milestone billing plans and down payment processing Milestone billing plans and down payments | |
| 2.4.1B Emergency order flag indicator for reporting Emergency order flag indicator for reporting | |
| 2.4.5 Sales order confirmation update Modernise order confirmation with T&Cs attached. Support enhanced email (title and body text) for CS to mail to self and forward to customer | |
| 2.4.6A Migrate to STC template for licensing Enable general licence, engineering, and study sales by Davy through SAP using standard functionality | |
| 2.4.6B Migrate to STC template for IEBV Setting up IEBV on standard STC processes | |
| 2.4.7 Reports to support sales processes Move toward standard SAP reports with limited customization to support sales processes. | |
| 2.6.1 Improvements to credit management A solution for removing unexplained credit blocks (UK specific) and possible new risk categories as defined by JM policy | |
| 2.6.2 Sales invoice enhancements Modernise invoice appearance for consistency | |
| 2.7.1 Implement Dunning procedure Create and automatically distribute debt notification (dunning and forms) notices to chase payments | |
| 2.9.1 Partner function for account manager Move account manager from sales group to partner function and assess reporting impact | |
| 2.9.2 Customer master data General master data cleansing and improvements for Customers and STC | |
| 3.2.6 Correspondence - customer statements (was RTR) Requirement to create a customer account statement covering all business requirement. | |
| 3.2.7 Credit management (was RTR) Update customer credit group for purposes of credit exposure reporting and associated master data updates | |
| 4.3.3. Process Areas - Out of Scope | |
| The following Level 3 process areas have been agreed as out of scope for Concert Design: | |
| • 02.01.01. Develop sales strategies and approach | |
| • 02.01.02. Execute sales strategy | |
| • 02.01.03. Manage sales partners and alliances | |
| • 02.01.04. Perform segmentation and sales analytics | |
| • 02.01.05. Perform sales governance | |
| • 02.02.01. Define contract management strategy and approach | |
| • 02.02.02. Execute contract management strategy | |
| • 02.02.03. Perform sales contract administration | |
| • 02.03.01. Manage customer sales enquiries | |
| • 02.04.03. Compliance with policies, procedures & controls | |
| • 02.05.01. Support make or buy strategy development | |
| • 02.08.01. Manage leads and opportunities | |
| • 02.08.02. Manage customer onboarding and accounts | |
| • 02.08.03. Manage customer relationships and collaboration | |
| • 02.09.03. Manage terms and conditions of sale | |
| • 02.10.01. Develop & manage commercial sales standards, policies & procedures | |
| In addition, the following scope items have been removed. | |
| Removed Scope Item Number Removed Scope Item Name Removed Scope Item Description Reason | |
| 2.2.1 Migrate to STC template for Paddington Setting up Paddington on standard STC processes This was a duplicate to 2.4.6A. | |
| 2.4.1 Intercompany direct sales Implement standard SAP Intercompany Direct Ship processing whereby a sales organisation in one company code can direct ship from a plant in another JM CT Company Site. Moved to Concert 2 due to complexity with STO and MRP | |
| 2.4.3 Material master record creation procedure It’s necessary to create a procedure for the material master record creation under all the areas in order to clarify how this request is done and what data is required under each area. Process exists in PTM | |
| 2.4.4 Functionality to allow attach documents to sales order in SAP Customer Service need to attach several documents to the sales order and this option is not available in the system Solution established in sharepoint | |
| 2.4.6C Migrate to STC template for SEV Setting up Sevierville on standard STC processes Complexity with metal accounting solution | |
| 2.4.6D Sales processes for branch offices System consolidation of sales processes for branch offices No customer sales processed in branch office; GB30 is used | |
| 2.4.6E Migrate to STC template for Tracerco Setting up Tracerco on standard STC processes Limited benefit for effort required | |
| 2.5.1 Implement ATP process for sales and dispatch ATP will be implemented to improve OTIF. This will include back-order scheduling and route planning. Moved to Concert 2 due to complexity with STO and MRP | |
| 2.7.2 Automated Credit Approval | |
| Reduce manual tasks by using system functionalities such as WF notifications to allow credit approval Business agreed to solution in Lotus Notes until MDG is implemented in CT | |
| 4.4. Site Related Scope | |
| This BPD refers to the harmonization, improvement, and consolidation of the STC process area across the different CT sites. | |
| 4.4.1. Existing CT Site Scope | |
| The CT existing sites will harmonize their processes across the following sites for the L3 process area. Any deviation will be explained in the sub-section of the process area discussed. | |
| L3 Process Area L3 Process Description Baseline DE35 GB30 IN10 US32 US38 SE33 | |
| 02.02.04 Perform pricing administration - L L L L L L | |
| 02.03.02 Perform requirements evaluation UK H M M M M H | |
| 02.03.03 Prepare and monitor sales proposals/bids - L L L L L H | |
| 02.03.04 Prepare and monitor sales quotations UK/Chicago H M M M H H | |
| 02.04.01 Perform sales order processing Chicago/UK/Sav M M M M M M | |
| 02.04.02 Monitor sales orders Chicago L L L L L L | |
| 02.06.01 Evaluate & Monitor customer credit Germany M M M M M M | |
| 02.06.02 Perform Customer Billing Unify L L L L L L | |
| 02.07.01 Process Accounts Receivable (AR) UK L L L L L L | |
| 02.07.02 Process Collections Unify/Best Practise H H H H H H | |
| 02.07.03 Process customer credits UK L L L L L L | |
| 02.09.01 Maintain Customer Records UK L L M L L L | |
| 02.09.02 Maintain Sales Master Data UK L L L L L L | |
| 02.09.04 Manage Customer Payment Terms UK L L L L L L | |
| 4.4.2. Consolidation Site Scope | |
| The CT sites to be consolidated onto the existing ECC system will adopt the processes for the L3 process area. Any deviation will be explained in the sub-section of the process area discussed. | |
| Sales processes for the branch offices of Moscow, Bahrain, Trinidad and Saudi will be completed through the UK and will reflect a similar impact to GB30. | |
| L3 Process Area L3 Process Description Baseline Licensing IEBV Moscow Bahrain Trinidad Saudi | |
| 02.02.04 Perform pricing administration TBD H H H H H H | |
| 02.03.02 Perform requirements evaluation UK/Chicago H H M M M M | |
| 02.03.03 Prepare and monitor sales proposals/bids UK/Chicago H H M M M M | |
| 02.03.04 Prepare and monitor sales quotations UK/Chicago H H M M M M | |
| 02.04.01 Perform sales order processing Chicago/UK/Sav H H L L L L | |
| 02.04.02 Monitor sales orders Chicago H H L L L L | |
| 02.06.01 Evaluate & Monitor customer credit Germany H H M M M M | |
| 02.06.02 Perform Customer Billing Unify H H L L L L | |
| 02.07.01 Process Accounts Receivable (AR) UK H H L L L L | |
| 02.07.02 Process Collections Unify/Best Practise H H H H H H | |
| 02.07.03 Process customer credits UK H H L L L L | |
| 02.09.01 Maintain Customer Records UK H H L L L L | |
| 02.09.02 Maintain Sales Master Data UK H H L L L L | |
| 02.09.04 Manage Customer Payment Terms UK H H L L L L | |
| 5. Detailed Design | |
| 5.1. Level 3 & 4 Business Processes: Flow Legend | |
| The Level 4 processes have been designed to cover both business and system steps. The Level 4 processes have been used as a “golden thread” throughout the design to bring together all the operating model elements. Each process map documents the activities, controls, roles, decisions, and systems in use, indicated by the icons shown below. | |
| 5.2. Level 3 Business Area – 02.02.04 Perform Pricing Administration | |
| 5.2.1. Level 4 Process Description – 02.02.04.01 Perform Pricing Administration | |
| Pricing management involves establishing pricing for orders, processing pricing exceptions, maintaining and updating pricing, and monitoring compliance to guidelines. This process does not replace commercial negotiated processes with JM customers. | |
| In standard SAP, pricing of sales document line items may be manual or automatic. In the current JM CT system, sales document pricing is carried out manually. To use a reference base price, it is necessary to maintain pricing condition records. The current pricing conditions used for this in the JM CT system include: | |
| • PR00 | |
| • ZPR0 | |
| Where pricing condition records are maintained, they may be keyed as show below, with PR00 being the example in this instance. | |
| Figure 4 - PR00 Access Sequence | |
| This access sequence allows the system to record prices that are: | |
| • Customer and material specific /*material sales price for a given customer */ | |
| • Price list and material specific /* a price list that can apply to many customers */ | |
| • Material specific /* material sales price only */ | |
| The system will search for a price in the sequence defined above and find the appropriate price for a given sales document line item. Typically, this search sequence will be the specific to the general price. | |
| According to the CT Pricing Policy, Target Price Lists will be reviewed at least every six months, and re-issued at least annually with updates for inflation, variances to input costs and exchange rates. Products not listed in the Target Price Lists should be priced based on discussions with the Market Manager and Regional Head of Sales or Commercial Director. | |
| JM CT Requirements: | |
| • Provide pricing visibility and price exception reporting | |
| • Automate tax calculation – tax codes in customer master data, tax as a pricing condition | |
| • Include freight as pricing condition | |
| • Manage intercompany pricing | |
| • Include customer specific pricing in SAP | |
| • Use reporting to enable analysis of pricing trends and margin analysis by key metrics such as region, industry market, customer, and product | |
| • Provide a report to highlight variances between actual and target pricing | |
| • Review regularly and maintain proactively pricing master data | |
| • Complete mass pricing updates to reduce manual effort and limit the risk of input errors. | |
| 5.2.1.1. Level 4 Process Flows and Steps | |
| 02.02.04.01 Perform Pricing Administration | |
| Figure 5 - Process Map 02.02.04.01 – Perform Pricing Administration | |
| Process Steps: | |
| 02.02.04.01 Perform Pricing Administration | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Review target pricing at least every 6 months. Manual According to the CT pricing policy, the Target Price List will be reviewed at least every 6 months and re-issued at least annually. Market Manager N/A | |
| Review pricing records Manual Selected condition records are displayed using the Display Condition transaction. Market Manager VK13 | |
| Request new product pricing Lotus Notes Off system request to confirm pricing for a new product. Customer Service N/A | |
| Create pricing record SAP Creation of a new pricing record. Master Data VK11 | |
| Request update to product pricing Lotus Notes Off system request to confirm a change to product pricing. Customer Service N/A | |
| Update pricing record SAP Update to an existing pricing record. Where the price of a material changes the current price is given an end date and the new price starts from the next day. Master Data VK12 | |
| 5.2.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.2.4 - Target pricing validation | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| At this phase of the project, JM CT will not adopt automatic quotation and sales order pricing. Price lists will be maintained in system. It is understood that items subject to metals pricing will be too complex for inclusion in this phase of the project. | |
| A report will be created to compare actual sales price to the target pricing to provide variance visibility. It will not be used to block a sales order. The report will only include items for which there is a price maintained in master data. | |
| The proper tax code determination for sales documents is triggered by SAP VAT determination. The condition technique will read an appropriate tax code by determining the tax condition record in sales documents. Where a legal entity owns a distribution centre in a different country) specific VAT conditions must be maintained. | |
| Once these VAT conditions have been setup in the system, their determination / application on the sales documents will default. Tax codes are determined on the sales order before being automatically copied to the customer’s invoice at the time of billing. | |
| The VAT sales condition types are aligned with the Group Tax requirements. All the business scenarios – domestic sales, exports and plant abroad – will trigger in background the appropriate financial tax code and percentage. All the sales transactions will carry out mandatory VAT calculation and it will be automatically populated in the legal VAT reports. | |
| US localization: Sales Tax, Use Tax and VAT in US are determined through a third-party application ‘ONESOURCE’. This integrated tax determination helps in minimizing user decisions and tax errors. This also removes the need to change SAP tax codes each time a rate/rule changes, so eliminates any business interruptions. | |
| 5.2.1.3. Site Specific Changes | |
| CT Sites Changes Business justification | |
| Savannah, Sweden, and Germany Will review inclusion of pricing for products with a metal component as the complexity may be beyond the scope of project | |
| 5.3. Level 3 Business Area – 02.03.02 Perform Requirements Evaluation | |
| 5.3.1. Level 4 Process Description – 02.03.02.01 Generate Sales Forecasts | |
| This process encompasses the forecasting process within JM CT. Commercial account managers maintain a forecast of potential sales by customer and product (material). These forecasts are currently maintained by three methods: | |
| • Forecasts from an excel spreadsheet that are not transferred into SAP | |
| • Forecasts from an excel spreadsheet that are manually transferred into SAP | |
| • Forecasts from an external (Lotus Notes or Access) database that are manually transferred into SAP. | |
| SAP forecasts are Quotation document types. Two different document types are used, these being: | |
| • ZFUS - US Forecast | |
| • ZF - JM Forecast | |
| These document types are essentially identical apart from the fact that ZF invokes a simple credit check and issues a warning in the case of credit breach. | |
| Key attributes of the forecast include: | |
| • Forecast owner /* Account manager – VBAK-VKGRP – sales group */ | |
| /* To be replaced with a document partner function */ | |
| • Customer | |
| • Material | |
| • Plant | |
| • Industry code | |
| • Incumbent | |
| • Forecast date | |
| • Sales price / value | |
| • Forecast probability. | |
| To supply planning / demand management with a view on future demand the forecast line item is provided with a probability value. These values are: | |
| Likelihood, % Entered in SAP, % | |
| Confident 80-100 100 | |
| Planned 65-79 75 | |
| Opportunity 30-64 50 | |
| Doubtful <30 0 | |
| Only forecast lines with probability 100% and 75% are used in production planning. | |
| It is assumed for purposes of this BPD that the Lotus Notes database will be replaced by the Microsoft Dynamics 365 CRM system. This is discussed in “To-Be Changes” below. | |
| JM CT Requirements: | |
| • Provide an E2E solution for CRM, ERP, and demand planning tool. | |
| • Standardize the use of forecasts in SAP | |
| • Integrate transfer of forecast data from CRM to SAP | |
| • Integrate transfer of data from SAP to excel file for demand planning | |
| • Provide a single source of commercial data | |
| • Provide a report to check for credit issues on confident and planned forecasts (excluding licensing) in the 3-month window. This would not include a hard stop but just a warning. | |
| • Provide a report on forecast accuracy at order line level for demand managers (not OTIF) | |
| 5.3.1.1. Level 4 Process Flows and Steps | |
| 02.03.02.01 Generate Sales Forecasts | |
| Figure 6 - Process Map 02.03.02.01 – Generate Sales Forecasts | |
| Process Steps: | |
| 02.03.02.01 – Generate Sales Forecasts | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receive customer requirement N/A Capture future potential customer requirement Account Manager N/A | |
| Does customer exist? CRM Determine if customer is in system. If no, follow the “Create and update customer master data” process. Account Manager N/A | |
| Create forecast CRM Capture the potential order details by creating a forecast in CRM. Account Manager N/A | |
| Enter customer and forecast header details CRM Capture the key header details such as Customer, Commercial Account Manager, etc. These will be defined by the CRM project. Account Manager N/A | |
| Enter product details and unit of measure CRM Capture the key product details such as material, supplying plant, date(s), etc. These will be defined by the CRM project. Account Manager N/A | |
| Enter pricing and other relevant information CRM Enter the expected material sales price. Account Manager N/A | |
| Save forecast CRM Save. Account Manager N/A | |
| Accepted? Manual Customer service will approve the forecast prior to uploading to SAP. Customer Service N/A | |
| Create forecast (Interface / VA21) SAP It is assumed the approved forecast will be interfaced to ECC via SAP PO. Inbound processing will create a ZF sales document. Customer Service VA21 | |
| Validate product exclusion SAP Savanah have some restrictions that will be enforced via Product Exclusion – an error will be raised if an excluded combination is received or entered manually, Customer Service VA22 | |
| Validate pricing SAP If pricing is maintained a statistical condition type will be populated to record this price. The purpose is to support down-stream reporting. Customer Service VA22 | |
| Save forecast SAP Save document. Customer Service VA22 | |
| Export S&OP output SAP Forecast data will be exported an excel spreadsheet for S&OP demand planning analysis Customer Service N/A | |
| 5.3.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.3.1 - Receipt of forecasts and quotes from CRM Microsoft Dynamics and export to S&OP forecasting tool | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.9.1 - Partner function for account manager | |
| The most significant change envisaged is replacement of the Lotus Notes database and forecast spreadsheets currently used by Commercial with Microsoft Dynamics 365 CRM and an automated interface into ECC. | |
| It is further envisaged that changes to the target forecast document types in the CT SAP system will require integration with the current method of using the forecast for purposes of demand planning. The transfer of requirements will remain as is to avoid any unwanted impact upon current processing. The existing configuration of Forecast document types, Item Categories and Schedule Lines is discussed in detail in the STC FDD – please refer to section 2.2.3 of that document. | |
| To harmonize CT forecasting process, only a single forecast document type will be used in future. This will be ZF – JM Forecast. | |
| 5.3.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| Licensing Forecasts will be in CRM only As forecasts in licensing are not customer specific, they will not be included in SAP | |
| 5.4. Level 3 Business Area – 02.03.03 Prepare and Monitor Sales Proposals / Bids | |
| 5.4.1. Level 4 Process Description – 02.03.03.01 Create Proposals | |
| Projects are being used in CT for the management of activities across the Licensing, R&D and Formox Plant Designs business areas. In Licensing and Formox Plant Designs, commercial proposals are sent to a customer for the purpose of winning a specific project. Licensing managers maintain a proposal including the potential sales of catalyst and engineering by customer and product (material) or service. The proposals are currently maintained in offline spreadsheets. This process encompasses the creation of proposals within SAP for JM CT. | |
| The working assumption, for this BPD, is that Proposals will be interfaced directly from CRM. The licensing account managers will enter a proposal into CRM with the appropriate details which will then be integrated into SAP upon acceptance of the Business Support Manager. If CRM is not available when licensing “goes live”, the current spreadsheet solution will be used until CRM is available. | |
| In SAP, a new quotation document type will be used in the future ZQP for proposals. This will distinguish proposals for projects from standard catalyst and service orders. This document type will be based upon existing sales document type ZR - JM Customer Order and will support used of Billing Plans. By basing this document type upon ZR, functionality in addition to billing plans and project assignment will be supported. | |
| Key attributes of the proposal include: | |
| • Proposal owner /* Account manager – VBAK-VKGRP – sales group */ | |
| /* To be replaced with a document partner function */ | |
| • Customer | |
| • Material or service | |
| • Plant | |
| • Industry code | |
| • Incumbent if applicable | |
| • Proposal date | |
| • Sales price / value | |
| • Proposal probability. | |
| To provide visibility on the likelihood of future projects, the proposal line item is provided with a probability value. These values are: | |
| Likelihood, % Entered in SAP, % | |
| Confident 80-100 100 | |
| Planned 65-79 75 | |
| Opportunity 30-64 50 | |
| Doubtful <30 0 | |
| JM CT Requirements: | |
| • Provide an E2E solution for CRM, ERP, and demand planning tool. | |
| • Standardize the proposal process in SAP | |
| • Integrate transfer of proposal data from CRM to SAP | |
| • Provide a single source of commercial data. | |
| 5.4.1.1. Level 4 Process Flows and Steps | |
| 02.03.03.01 Create Proposals | |
| Figure 7 - Process Map 02.03.02.01 – Create Proposals | |
| Process Steps: | |
| 02.03.03.01 - Create Proposals | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receive customer RFP N/A Capture customer proposal. Account Manager N/A | |
| Create and maintain projects SAP Refer to PS Process Flow Create and Maintain Projects 8.1.1.2 in BPD Projects & Timesheets. Project Accountant N/A | |
| Does customer exist? CRM Determine if customer is in system. If no, follow the “Create and update customer master data” process. Account Manager N/A | |
| Create proposal CRM Capture the potential order details by creating a proposal. Account Manager N/A | |
| Enter customer and proposal header details CRM Capture the key header details such as Customer, Commercial Account Manager, etc. Account Manager N/A | |
| Enter service/product material CRM Enter the “dummy” service/product material code. Account Manager N/A | |
| Generate billing plan CRM Manually add a billing plan referring to STC Section 2.4.1.4. Account Manager N/A | |
| Save proposal CRM Save. Account Manager N/A | |
| Accepted? Manual The proposal will be checked and approved before integrated to SAP Business Support Manager N/A | |
| Save proposal SAP Save proposal upon approval. Business Support Manager VA21 | |
| 5.4.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.3.1 - Receipt of forecasts and quotes from CRM Microsoft Dynamics and export to S&OP forecasting tool | |
| • 2.4.1A - Introduction of Milestone Billing plans and down payment processing | |
| • 2.4.6A - Migrate to STC template for licensing | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.9.1 - Partner function for account manager | |
| The most significant change is the consolidation of the licensing and Formax technology business to SAP from offline spreadsheets. To properly align projected revenue, a separate SAP proposal will be needed for portions of the proposal that are associated with a different company code. For example, if the catalyst portion is with JM Plc. and the engineering portion is with Davy, two proposals will be created in SAP – one for each business. A new quotation document type will be used in the future for proposals: ZQP. | |
| It is further envisaged that the Proposal will reference Project Systems for milestones in the billing plan. | |
| It is also intended that project referenced line items will be managed by a different item category and requirements type compared to standard product sales. This will be managed by using service materials with a different Item Category Group. The Category Group will include: license fee, engineering, catalyst, equipment, services, etc. Note: Item Category is the SAP approach to defining business rules that apply to the sales document line item, for example whether the line is relevant for delivery or not. | |
| Additionally, where a billing plan is required, it will be managed in SAP by users manually altering the items category to select the billing plan relevant option. | |
| 5.4.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| None identified | |
| 5.5. Level 3 Business Area – 02.03.04 Prepare and Monitor Sales Quotations | |
| 5.5.1. Level 4 Process Description – 02.03.04.01 Create Quotations | |
| This process encompasses the creation of quotations within JM CT. Commercial quotations are sent to a customer for the purpose of listing the price of goods or services offered to a customer. Account managers maintain a quotation by customer and product (material). These quotations are currently maintained by three methods: | |
| • an excel spreadsheet that is managed on SharePoint; | |
| • the personal computers of account managers; | |
| • a Lotus Notes database that is manually transferred into SAP. | |
| Three different document types are used, these being: | |
| • QT - JM Quotation | |
| • ZQUS - US Quotation | |
| • ZQ - JM Quotation | |
| Note that the ZA02 - FORMOX Quotation output type is used in the Quotation process. | |
| These document types are essentially identical apart from the fact that ZQ has a solely external number range assignment – the users manually enter the same number as quotes generated from the Lotus Notes quotation application. | |
| Key attributes of the quotation include: | |
| • Quotation owner /* Account manager – VBAK-VKGRP – sales group */ | |
| /* To be replaced with a document partner function */ | |
| • Customer | |
| • Quotation date | |
| • Valid from date | |
| • Valid to date | |
| • Material or service | |
| • Plant | |
| • Delivery date | |
| • Industry code | |
| • Incumbent if applicable | |
| • Sales price / value | |
| • Quotation probability. | |
| To supply planning / demand management with a view on future demand, the quotation line item is provided with a probability value. These values are: | |
| Likelihood, % Entered in SAP, % | |
| Confident 80-100 100 | |
| Planned 65-79 75 | |
| Opportunity 30-64 50 | |
| Doubtful <30 0 | |
| Only quotations lines with probability 100% and 75% are used in production planning. | |
| It is assumed for purposes of this BPD that Microsoft Dynamics 365 CRM system is implemented within CT in a parallel project. | |
| JM CT Requirements: | |
| • Provide an E2E solution for CRM, ERP, and demand planning tool. | |
| • Standardize the quotation process in SAP | |
| • Integrate transfer of quotation data from CRM to SAP | |
| • Provide a single source of commercial data | |
| 5.5.1.1. Level 4 Process Flows and Steps | |
| 02.03.04.01 Create Quotations | |
| Figure 8 - Process Map 02.03.02.01 – Create Quotations | |
| Process Steps: | |
| 02.03.04.01 Create Quotations | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receive customer RFQ N/A Capture customer requirement from the request for quotation. Account Manager / Customer Service N/A | |
| Does customer exist? CRM Determine if customer is in system. If no, follow the “Create and update customer master data” 2.9.1.1 process. Account Manager N/A | |
| Create quote CRM Capture the potential order details by creating a quotation in CRM with or without reference to forecast. Account Manager / Customer Service N/A | |
| Check quote details against forecast before confirming Manual Confirm data details in the request for quotation are consistent with forecast and update as required prior to saving Account Manager / Customer Service N/A | |
| Enter customer and forecast header details CRM Capture the key header details such as Customer, Commercial Account Manager, etc. These will be defined by the CRM project. Account Manager / Customer Service N/A | |
| Enter product details and unit of measure CRM Capture the key product details such as material, supplying plant, date(s), etc. These will be defined by the CRM project. Account Manager / Customer Service N/A | |
| Enter pricing and other relevant information CRM Enter the expected material sales price. Account Manager / Customer Service N/A | |
| Save quotation CRM Save. Account Manager / Customer Service N/A | |
| Send quotation to customer Manual Commercial sends quotation to customer typically by email or electronic platform. Account Manager / Customer Service N/A | |
| Accepted? Manual Customer service will review the quotation for accuracy and completeness prior to accepting it for uploading to SAP. Customer Service N/A | |
| Create quotation (Interface / VA21) SAP It is assumed the approved quotation will be interfaced to ECC via SAP PO. Inbound processing will create a ZQUS or ZQ sales document. Customer Service VA21 | |
| Validate product exclusion SAP Savanah have some restrictions that will be enforced via Product Exclusion – an error will be raised if an excluded combination is received or entered manually, Customer Service VA21 | |
| Validate pricing SAP If pricing is maintained a statistical condition type will be populated to record this price. The purpose is to support down-stream reporting. Customer Service VA21 | |
| Save quote SAP Save document. Customer Service VA21 | |
| Export data to S&OP demand planning tool SAP Forecast data will be exported an excel spreadsheet for S&OP demand planning analysis. WRICEF STC_I0002 - SAP demand data to be exported to S&OP forecasting tool contains further details. Customer Service N/A | |
| 5.5.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.3.1 - Receipt of forecasts and quotes from CRM Microsoft Dynamics and export to S&OP forecasting tool | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.9.1 - Partner function for account manager | |
| The most significant change envisaged is replacement of the Lotus Notes database and spreadsheets currently used by Commercial with Microsoft Dynamics 365 CRM and an automated interface into ECC. | |
| As ATP is not in scope, no change to this configuration will be made. The current usage of Item Categories and Schedule Lines will remain as-is. The overriding principle is to ensure we have no adverse impact in the current processes used for demand planning and the timely satisfaction of customer orders. | |
| Only a single quotation document type will be used in future, ZQ -JM Project Quotation. This will have internal number range assignment, using number range 51, 400000 to 499999. Where received from CRM, the external quotation number will be held in a new header “Z” field. | |
| 5.5.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business justification | |
| None identified | |
| 5.6. Level 3 Business Area – 02.04.01. Perform Sales Order Processing | |
| 5.6.1. Level 4 Process Description – 02.04.01.01 Create Customer Order | |
| This process encompasses the creation of sales orders within JM CT for the sales of goods and services and the various checks that take place in accordance with JM policy and guidelines. These order requests are received by various routes including: | |
| • Directly placed by customer via email | |
| • Conversion of customer forecasts and quotations to sales orders. | |
| A customer purchase order is required before creating a sales order in SAP. Any exceptions to this will follow company business unit standard operating procedures. | |
| The sales order creation process details the creation of a sales order with reference to a forecast or quotation or the direct entry of the customer order into the SAP system. For the latter, the relevant information from the customer purchase order such as customer name, product, quantity, and requested delivery date are captured in the sales order. Once the order requirements are captured, the order processing checks are conducted such as availability of products, compliance, and credit management checks. When the order is confirmed and complete, an order confirmation can be sent to the customer to acknowledge the order details. | |
| The strategy to complete the process from point of sale to delivery of product is the order fulfilment strategy which is defined by the business. The strategy defines the supply chain cycle such as Make to Order, Make to Stock, and Make to Forecast. JM CT utilizes the Make to Stock strategy. | |
| JM CT Requirements: | |
| • Identify emergency orders | |
| • Check stock availability and confirm customer orders | |
| • Obtain visibility of pending orders in SAP reports | |
| • Rationalize and move toward standard SAP reports to support sales activities | |
| 5.6.1.1. Level 4 Process Flows and Steps – Create Customer Order | |
| 02.04.01.01 Create Customer Order | |
| Figure 9 - Process map 02.04.01.01 – Create Customer Order | |
| Process Steps: | |
| 02.04.01.01 Create Customer Order | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receive purchase order Manual Receipt of customer order. Details are reviewed to ensure accuracy Customer Service N/A | |
| Does customer exist? SAP Determine if customer is in system. If no, follow the “Create and update customer master data” 2.9.1.1 process. Customer Service N/A | |
| Is forecast or quote in SAP? SAP Decide if related forecast or quotation exists. If existing, create order with reference. Customer Service VA01 | |
| Check order details against quotation / forecast before confirming Manual Confirm data details in the purchase order are consistent with forecast/quotation and update as required prior to saving. Customer Service N/A | |
| Enter sales order type and sales area SAP User selects sales document type and sales area. Customer Service VA01 | |
| Enter customer and order header details SAP Partners such as sold-to, ship-to, and bill-to are required. Enter the SAP number and system will automatically determine corresponding partner details form the Customer Master. Customer Service VA01 | |
| Enter product details SAP Once partner details are determined, the customer requirements are keyed into order fulfilment system including volumes and packaging. Customer Service VA01 | |
| Enter pricing and other relevant information SAP This step covers pricing based on contract terms or price lists. It can be manually added as well. Customer Service VA01 | |
| Deloitte e-invoice bolt-on SAP US tax will be added to the order confirmation through integration with a tax engine. Customer Service N/A | |
| Validate product exclusion SAP Product exclusion is maintained for a specific customer and the system will not allow the sale of the specified product to that customer. Customer Service VA01 | |
| Third party supplier? Manual Determine if product will be supplied from a third-party source. | |
| Customer Service N/A | |
| Select third party item category SAP If a third-party supplier will be used, the TAS item category will be selected. TAS will create a back-to-back purchase requisition linked to the sales order. The purchase requisition is converted to a PO with the customer delivery address. This is in reference to PR Creation flow 1.4.1.1 Customer Service TAS | |
| Can dates be met? SAP A manual evaluation is done for product availability (reviewing material availability and replenishment lead time) to check if the customer delivery date can be met. A physical check of material could also be performed using a separate transaction. Customer Service N/A | |
| Resolve supply issues Manual If the dates cannot be met, CS arranges for iterative meetings with the Production, commercial, and Logistics teams to arrive at a suitable date and presents the same to the customer. Negotiations may ensue, and adjustments may be made to come to a consensus between the parties. Customer Service N/A | |
| Revised dates accepted? Manual Once the new revised dates are agreed with commercial, logistics and shipping, the dates are proposed to the customer to confirm if they are acceptable. Customer Service N/A | |
| Amend or reject customer order SAP If the customer does not accept the dates and negotiations fail, the order is rejected and closed. The case can be escalated depending on the severity of not meeting the customer’s required delivery date (if other options such as special freight still do not resolve the issue). Customer Service VA02 | |
| Update requested delivery date SAP If the customer agrees and accepts the delivery date determined as negotiated in the previous steps; the requested delivery date is updated, and the material availability is triggered. Customer Service VA02 | |
| Review and save order SAP Save the sales order. Customer Service VA01 / VA02 | |
| Successfully saved? SAP Determine if the sales order was successfully saved. Customer Service VA01 / VA02 | |
| Correct issues Manual If the order was not saved; the cause should be investigated, and the correction made. Customer Service N/A | |
| Create order confirmation SAP After the order is successfully saved, output determination is currently set to manually issue. Customer Service N/A | |
| 5.6.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.3.1 - Receipt of forecasts and quotes from CRM Microsoft Dynamics and export to S&OP forecasting tool | |
| • 2.4.1B - Emergency order flag indicator for reporting | |
| • 2.4.5 - Sales order confirmation update | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.9.1 - Partner function for account manager | |
| The primary changes to sales order processing for a standard order or delivery related document include: | |
| • Replacing use of the sales group functionality with a new partner function for account manager data | |
| • Updates to corresponding sales reports affected by the account manager partner function | |
| • Update to order confirmation – see 2.4.1.2 | |
| • Use of billing plans and down payments – see 2.4.1.4 | |
| Emergency Orders will be identified to assist in the analysis for the determination of safety stock levels. Emergency orders are orders that were not forecasted or otherwise anticipated. During Realization, categories of emergency will be defined. The master data team has requested a new field be created rather than repurposing an existing field. In addition, a report will be developed to review these orders. | |
| Service orders are created by the same process utilizing service material codes. Service line items are order related billing and should not be delivery related. Currently, if the service is free of charge, a £0.01 price is included and later invoiced to be cleared but not sent to customer. In the future, a free of charge item category will be used to simplify this process. | |
| Third Party Order Processing will be implemented when a non-JM site supplies product for a customer order. If the material will be shipped directly from the supplier to the customer, a standard item category TAS (Third Party Item) will be raised. This can be done automatically or manually as selected by customer service. TAS will create a back-to-back purchase requisition linked to the sales order. The purchase requisition is converted to a purchase order with the end customer delivery address. Once the vendor has delivered and their invoice is received, the system will provide order related billing to the end customer. Labels are typically supplied by JM manually (through Atrion) and applied at the supplier’s site. This process will support PFR (purchased for resale) in the licensing business. | |
| If the material is shipped to a JM warehouse (as typically done in non-licensing CT businesses in the UK and US) from a third-party supplier, standard inbound and outbound logistics processes will be executed. In general, labels are still provided by JM manually (through Atrion) and applied at the supplier’s site. A few suppliers apply their own labels, and JM labels are applied when the material is sold out of the JM warehouse. These labels are printed in SAP. Standard billing process will then be executed. | |
| 5.6.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| Germany Provide solution for current allocation pain point. Initial look shows ATP is executed at delivery creation not at sales order. Rules will be established to correct this. | |
| 5.6.2. Level 4 Process Description – 02.04.01.02 Create Order Confirmation | |
| This process documents the issue of an order confirmation from SAP to confirm the receipt and acceptance of an order and delivery date. The terms and conditions will be attached automatically for standard and manually for customer specific. An indicator will be added in customer master data for this. If applicable, SDS will be manually attached to the email prior to customer issuing. | |
| Output management for sales orders (and quotations, also) is managed through the SAP output determination process. Each document type has an assigned Output Determination Procedure that lists the outputs that may be issued by that document type. In JM CT, SAP orders are assigned to output determination procedure V10000 - Order Output. | |
| The following output types are supported: | |
| • ESYM Internal Output | |
| • BA00 Order Confirmation | |
| • MAIL Internal Output | |
| • KRML Credit Processing /* internal Credit Management email message */ | |
| • ZIEP JMCIPL Exp Proforma | |
| • ZSAV Additives email | |
| • ZA00 Additives ord.conf. | |
| • ZA01 FORMOX Order Conf. | |
| However, only the following order confirmation types are used: | |
| • BA00 Order Confirmation | |
| • ZA00 Additives ord.conf. | |
| • ZA01 FORMOX Order Conf. | |
| The creation of an output may be manual or automatic. Using BA00 as an example, master data is maintained using the following Access Sequence: | |
| Figure 10 – BA00 Access Sequence | |
| A detailed analysis of master data maintained will be conducted during Realization, but the following master data is maintained against the Sales Organisation key field: | |
| Figure 11 – Example Output Condition Records | |
| Records set to Date/Time 3 are issued at user request whilst those with Date/Time 4 are issued automatically in the absence of a credit management block. Additionally, it is possible to schedule the outputs to be sent via a regular SAP background job. In the absence of output master data, the users manually select and create the output whilst editing the sales order. The Medium fields specifies whether the output will be issued via print or email. | |
| The current process used by the business is to convert the output to a PDF document, which is then manually emailed to one or more customer recipients. Additional documents are included in this email, namely the Terms and Conditions of Sale and the relevant Safety Data Sheets. | |
| The key reasons for this manual intervention include: | |
| • Multiple email recipients /* which is not supported in SAP standard */ | |
| • Changing recipients | |
| • Lack of interface to Atrion which holds SDS data. | |
| Note also that the order confirmation is also used internally at some sites. For example, Savannah sends a copy to production planning to confirm the order has been raised. | |
| JM CT Requirements: | |
| • Harmonize and modernize the order confirmation format | |
| • Include T&Cs for customers with standard and flag those that do not | |
| • Standardize email to send to customer with OC attachment. | |
| 5.6.2.1. Level 4 Process Flows and Steps | |
| Create Order Confirmation | |
| Figure 12 - Process Map 02.04.01.02 – Create Order Confirmation | |
| Process Steps: | |
| 02.04.01.02 Create Order Confirmation | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Create customer order SAP Creation of the sales order. Where an output is not automatically generated due to the presence of output master data, the user manually selects the output type, method, and timing of output to be used. Customer Service VA01/ VA02 | |
| Trigger order confirmation from SAP sales order output with self as recipient SAP Since the recipient changes frequently and multiple recipients are required, the customer service rep will email to self by changing recipient in the sales order. Then SDSs will be attached, and the order confirmation forwarded to customer. Customer Service VA01/ VA02 | |
| Output triggered successfully? SAP Was the output triggered successfully? Customer Service N/A | |
| Check email status in transaction SAP Customer service works with IT if there are any technical issues with the triggered output. IT Support SO ST/SOSG | |
| Review email SAP The users can print preview the output to confirm all is as expected. The standard terms and conditions will be attached as part of the document if applicable. Customer Service VA01/ VA02 | |
| Attach SDSs Manual The SDSs will be manually added from the Atrion database if applicable. Customer Service N/A | |
| Issue to customer Manual The order confirmation is then manually issued to the customer. Customer Service N/A | |
| 5.6.2.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.5 - Sales order confirmation update | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| The improvements to be implemented by the Concert project have been discussed in detail at several workshops. The aspiration was to automate standard SAP processing to the greatest extent possible. | |
| To fully automate the issue of order confirmations with all necessary information would require: | |
| • A RICEFW to support multiple email addressees | |
| • RICEFW to include title and email body text in emails | |
| • Interface to Atrium for SDS information | |
| • Possible RICEFW for Terms & Condition | |
| An additional consideration was the frequency with which email addresses change and the overhead of maintaining a bespoke table, by Customer, to track these changes. The user community felt that the costs of automation outweighed the potential benefits. | |
| Thus, the agreed scope of change for Concert comprises a re-design of the existing outputs so that they have a more modern look and feel and correctly reflect the JM CT branding. | |
| Inclusion of the Terms & Conditions will be investigated; it is noted that they can vary so inclusion may not be feasible without a corresponding RICEFW. | |
| In re-designing the layouts, the design principles will include commonality across sites (wherever possible) and support for other new Concert functionality such as the use of Billing Plans with down payment functionality. | |
| 5.6.2.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.6.3. Level 4 Process Description – 02.04.01.04 Create Sales Order with Billing Plan / Down Payment | |
| A down payment is made by a customer in advance of receiving the goods or services for which they have a commercial agreement with JM CT. The decision on whether a down payment is required rests with the Commercial and Financial Teams and is made before the commercial agreement is finalized. | |
| This process is used to create the request(s) for down payment, record the receipt of the down payment, and create a final invoice including the deduction of the down payment and the final amount due. It is noted that a single sales order may contain both multiple down-payment requests within a single billing plan and down payment requests on multiple sales document line items. | |
| Whilst the line item within the billing plan may also be relevant for delivery, the billing process requires order-based billing with SAP. Hence a manual check is retained to prevent delivery until the Customer Service team are satisfied that the delivery can be created. Due to scheduling requirements, the delivery may be created prior to receipt of the down payment request payment from the customer. The link between delivery and payment is thus subject to user decision and can be flexible enough to meet the business requirements in this regard. | |
| Payment terms can be maintained at the individual billing plan element level, allowing different terms to be specified for the down payment request compared to the final invoice, for example. | |
| Both the standard order confirmation and invoice outputs will be adjusted to accurately include the down payment details as needed. An example of a currently used billing plan is shown below. | |
| Figure 13 – Billing Plan Used in the Current JM CT SAP System | |
| JM CT Requirements: | |
| • Support for both order-based line items and delivery-based line items | |
| • Support Payment terms at billing plan line item level | |
| • Support 100% down payment, i.e. cash in advance | |
| • Support for multiple part deliveries | |
| • Update invoice layouts for down payment invoice and standard invoice with clearing | |
| • Identify emergency orders | |
| • Provide billing plans/ milestone billing/pre-payments in system | |
| • Check the real time stock availability and confirm customer orders | |
| • Rationalize and move toward standard SAP reports to support sales activities | |
| • Obtain real-time visibility of pending orders in SAP reports | |
| 5.6.3.1. Level 4 Process Flows and Steps | |
| 02.04.01.04 Create Sales Order with Billing Plan / Down Payment | |
| Figure 14 - Process Map 02.04.01.04 – Create Sales Order with Billing Plan / Down Payment | |
| Process Steps: | |
| 02.04.01.04 Create Sales Order with Billing Plan /Down Payment | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Maintain sales order with billing plan SAP Create the sales order in the normal manner and selects the items category that invokes the down payment request at the item level. | |
| Note it is also a requirement to have the facility to enter the billing plan at header level also. | |
| Complete the necessary Billing plan entries at item level if different to header level. | |
| Payment terms are optionally entered at the billing plan item level. Customer Service VA01 / VA02 | |
| Is there a down payment? Manual Determine if a down payment is required. Customer Service N/A | |
| Remove billing block for down payment item SAP When the down payment request is ready for issue, the user removes the billing block. Customer Service VA02 | |
| Create down payment request SAP Create the FAZ invoice using VF01 or VF04. It is necessary to manually set the target billing type to FAZ. | |
| Note during Realization it is probable that a CT version of this will be created – ZFAZ. Billing Clerk VF01 / VF04 | |
| Receive down payment Manual Payment is received in the normal manner. Account Receivable N/A | |
| Post down payment request SAP Down payments may be posted either manually or automatically (using payment program SAPF110, automatic debit or bank direct debit payment method). | |
| In this flow we have shown manual processing using F-29. | |
| Account Receivable F-29 | |
| Remove delivery block SAP Remove the sales document line-item delivery block. Account Receivable VA02 | |
| IM Outbound logistics execution SAP Standard LE transaction to create the delivery. Logistics N/A | |
| Change sales order (remove billing block) SAP Remove the billing block on the next (may be final or otherwise) billing plan line item. Customer Service VA02 | |
| Create customer invoice SAP Standard billing transaction to create the F2 customer invoice for balance. Billing Clerk VF04 | |
| Process customer account clearing SAP Clear account. Accounts Receivable N/A | |
| 5.6.3.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.1A - Introduction of Milestone Billing plans and down payment processing | |
| • 2.4.5 - Sales order confirmation update | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.6.2 - Sales invoice enhancements | |
| • 2.9.1 - Partner function for account manager | |
| The business has trialled the use of billing plans with limited success. In addition, these currently post to sales revenue. | |
| The specific changes made will be to adopt SAP standard processing in this area. | |
| The down payment line will be for the deliverable product, in the case of delivery related transactions. A specific Billing Plan Type will be configured for this. | |
| Additionally, the SAP standard approach will be adopted by use of billing type FAZ - Down payment request, or a local copy thereof. This will post to a special general ledger transaction with an alternative general ledger account. This will require configuration by the Finance team. Subsequent billing will be with a standard F2. | |
| The billing document will have two items: one for the final invoice and one for the down payment settlement. Settlement of the down payment will be processed automatically upon invoice release to accounting. | |
| The order confirmation and invoice output will be adjusted to accommodate down payment; note these outputs are being “modernised” under a related scope item. | |
| 5.6.3.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| Licensing The invoice will be sent to the project manager who will gather the required documentation prior to sending to the customer. | |
| 5.6.4. Level 4 Process Description – 02.04.01.05 Create Sales Order with Project | |
| This process is intended to be used wherever the JM CT business activity is managed through the use of SAP projects that include elements of customer invoicing. For example: | |
| • Licensing – Davy | |
| • Formox Technology | |
| The precise scope for the use of SAP Project System has been determined by the PS&TM workstream and their BPD should be consulted for a complete definition regarding where the application will be used, and also how, within JM CT. | |
| That BPD contains a description of how PS and Sales will work together to enable customer billing where project work is on behalf of an external customer; this BPD mirrors that and defines the integration from a Sales perspective. | |
| SAP supports several approaches to the integration of sales order processing with PS, ranging from the closely coupled approach to a looser, financially focussed integration. An example of close integration would be the so called “Engineer-to-order” process. In this case the customer requirement is modelled within the planned project and a Quotation is generated based upon that information, so called Resource Related Quotation processing (DP80/81/82). The resulting Quotation reflects the costs and schedule contained within the project. Similarly, it is possible to generate a project from the Quotation itself, using standard project templates; this too results in very close integration between PS and Sales. | |
| The approach documented here reflects a looser, financial integration. The sales order is created using standard sales order transactions, namely VA01. The sales document line item is then account assigned to the project by entering the billing WBS element. This ensures that both planned and actual revenue can be reported and reviewed using standard PS reports, and hence the profitability of the project determined. | |
| Upon completion of a milestone, the project manager, or administrator, will release the line item and collect the required documentation to support billing. They will manually contact finance to remove the billing block when milestone documentation is completed. Invoicing will not be completed automatically in system. | |
| Invoices generated against the account assigned sales order line item post with reference to the billing WBS, which must be released to receive revenue prior to invoice generation. This is a new process for JM CT and is intended to provide much improved management of customer billing with respect to complex engineering project and related activities. | |
| It is planned to create a new sales document type that will be used with project related contracts; this will enable simplified reporting and training. | |
| JM CT Requirements: | |
| • Include customer specific pricing in system | |
| • Support customer billing of activities managed through a project | |
| • Support for milestone billing with link to project | |
| • Support for billing of services such as training and engineer site visits | |
| • Link planned revenue visibly to the project | |
| • Link actual revenue visibly to the project | |
| • Cross charge from one legal entity to another | |
| • Need time for non-Davy employees to be input for % completion calculations for revenue recognition – revenue recognition is addressed in the PS&TM BPD | |
| • Limit the number of transactions to manage billing associated with intercompany actions | |
| • Automate interactions between JM entities | |
| • Handle revenue recognition across JM legal entities, especially where % complete is required. | |
| 5.6.4.1. Level 4 Process Flows and Steps | |
| 02.04.01.05 Create Sales Order with Project | |
| Figure 15 – Process Map 02.04.01.05 – Create Sales Order with Project | |
| Process Steps: | |
| 02.04.01.05 Create Sales Order with Project | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receive signed contract Manual The customer signed contract is received by JM Project Accountant N/A | |
| Create and maintain projects SAP Refer to 3.8.2.2 in project systems on the creation of projects. Project Accountant N/A | |
| Does customer exist? Manual Determine if customer is in system. If no, follow the “Create and update customer master data” process. Customer Service N/A | |
| Enter sales order type and sales area SAP Create new sales order that represents the contract with the customer. | |
| Select sales area and order type. Project Accountant VA01 | |
| Enter customer and order header details SAP Enter order header details. Project Accountant VA01 | |
| Enter material SAP Enter the service material and related line-item details including Plant, dates and sales price. Project Accountant VA01 | |
| Enter WBS SAP Enter the Billing WBS if available Project Accountant VA01 | |
| Enter billing plan SAP Generate or manually create the billing plan to reflect the billing milestones for this leg of the project, Project Accountant VA01 | |
| Release billing WBS SAP When ready for billing it is necessary to release the billing WBS element if not already released. Failure to do so will cause a failure in releasing the invoice to accounting. Project Manager CJ20N | |
| Declare billing milestone complete SAP Project Manager/Project Administrator declares the Milestone complete. This includes the gathering of supporting documentation. | |
| If the milestone billing plan was auto generated this will release the milestone for billing. Otherwise, a manual release is required. Project Manager CJ20N | |
| Inform finance of completed milestone Manual The project manager / administrator will notify finance when a milestone is completed to proceed with further processing Project Manager N/A | |
| Remove billing block SAP Release milestone for billing if required. | |
| The milestone is now ready for order related billing. Project Accountant VA02 | |
| Create customer invoice SAP Complete standard customer billing process Project Accountant N/A | |
| Account revenue recognition SAP Complete revenue recognition for projects process Project Accountant N/A | |
| 5.6.4.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.1 - Introduction of Milestone Billing plans and down payment processing | |
| • 2.4.6A - Migrate to STC template for licensing | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.6.2 - Sales invoice enhancements | |
| • 2.9.1 - Partner function for account manager | |
| This is a new process to be used by JM CT that will include the functionality outlined above. | |
| The WBS will not be integrated to the billing plan, but there will be a WBS reference in the line item. Dates will be updated manually throughout the project life. The use of the down-payment option is an optional step. | |
| Notes on structure of the sales orders: | |
| 1. An engineering engagement will consist of more than 1 contract with the customer. A QT will be created for EACH contracting sales org. | |
| 2. Within each contract, the quotation line items will reflect the main elements as described - so a line each for Licence Fee, PDP&Tech, Training, Technical Services and TPS (for example). On each line, the billing plan will reflect the charging structure for that element of the contract - say Contract Signed, Initial Design, etc. | |
| 3. Upon creation of the sales order for a project, the proposal sales document will be closed out. The proposal can stay active in the project, but the proposal sales document will be closed to prevent double counting of revenue. | |
| 5.6.4.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.6.5. Level 4 Process Description – 02.04.01.07 Create Sales Order for Intercompany Debit | |
| This process is intended to be used wherever the JM CT need to create a cross-company charge for services. Examples include: | |
| • Reconciliation of revenue on cross-company projects | |
| • Charging for Engineer time across company codes. | |
| It is understood that this will typically be related to a project in the requesting company code. Non-project related cross company charges will be created using a standard debit memo (2.7.3.2) request line item, i.e. without reference to a project. | |
| In both cases the JM CT company code to be charged will be represented by a standard Sold-To Party customer. In other words, these transactions will be executed as “arms-length” processes. | |
| Invoices generated against the account assigned sales order line item post with reference to the billing WBS, which must be released to receive revenue prior to invoice generation. This is a new process for JM CT and is intended to provide much improved management of cross company code billing with respect to complex engineering project and related activities. | |
| JM CT Requirements: | |
| • Support cross-company code billing of activities managed through a project | |
| • Support for billing of services such as training and engineer site visits | |
| • Link planned revenue visibly to the project | |
| • Link actual revenue visibly to the project | |
| • Cross charge from one legal entity to another | |
| • Automate interactions between JM entities | |
| • Handle revenue recognition across JM legal entities, especially where % complete is required. | |
| 5.6.5.1. Level 4 Process Flows and Steps | |
| 02.04.01.07 Create Sales Order for Intercompany Debit | |
| Figure 16 – Process Map 02.04.01.07 – Create Sales Order for Intercompany Debit | |
| Process Steps: | |
| 02.04.01.05 Create Sales Order with Project | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Determine Interco debit charge Manual The customer signed contract is received by JM – for initial planned cross company charges. As the project progresses, additional charges will be identified. Project Accountant N/A | |
| Billing for revenue project SAP Refer to 8.1.4.2 in project systems on project revenue Project Accountant N/A | |
| Does customer exist? Manual Determine if customer is in system. If no, follow the “Create and update customer master data” process. Customer Service N/A | |
| Enter sales order type and sales area SAP Create new sales order that represents the contract with the customer. | |
| Select sales area and order type. Project Accountant VA01 | |
| Enter customer and order header details SAP Enter order header details. Project Accountant VA01 | |
| Enter service material SAP Enter the service material and related line-item details including Plant, dates and sales price. Project Accountant VA01 | |
| Enter WBS SAP Enter the Billing WBS if available. Project Accountant VA01 | |
| Release billing WBS SAP When ready for billing it is necessary to release the billing WBS element if not already released. Failure to do so will cause a failure in releasing the invoice to accounting. Project Manager CJ20N | |
| Inform finance of WBS release Manual The project manager / administrator will notify finance when a milestone is completed to proceed with further processing. Project Manager N/A | |
| Create customer invoice SAP Complete standard customer billing process. Project Accountant N/A | |
| Account revenue recognition SAP Complete revenue recognition for projects process. Project Accountant N/A | |
| 5.6.5.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6A - Migrate to STC template for licensing | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.6.2 - Sales invoice enhancements | |
| • 2.9.1 - Partner function for account manager | |
| This is a new process to be used by JM CT that will include the functionality outlined above. | |
| 5.6.5.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.7. Level 3 Business Area – 02.04.02 – Monitor Sales Orders | |
| 5.7.1. Level 4 Process Description – 02.04.02.01 Monitor Sales Orders | |
| Monitoring tools are used to track the status of sales orders in the system to provide early detection of issues that could result in increased collection time and increased working capital. This process comprises the periodic and ad hoc process of checking the status of open sales orders. The aim of the process is to ensure: | |
| • Open orders are delivered on time and in full | |
| • Identification of orders where delivery on time may be an issue | |
| • Identification of incomplete sales orders | |
| • Identification of sales orders blocked for delivery | |
| • Identification of sales orders blocked for billing. | |
| Orders identified will be expedited or otherwise updated to enable completion of the next step in the sales process. | |
| JM CT Requirements: | |
| • Validate customer pricing versus price list and report variances | |
| • Rationalize and move toward standard SAP reports | |
| • Improve on time in full (OTIF) | |
| 5.7.1.1. Level 4 Process Flows and Steps | |
| 02.04.02.01 Monitor Customer Orders | |
| Figure 17 – Process map 02.04.02.01 – Monitor Customer Orders | |
| Process Steps: | |
| 02.04.02.01 Monitor Customer Orders | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Run sales order status report SAP It is planned to provide a bespoke report that will include sufficient details to identify whether there is potential supply problem for the order. Report discussed in to be detail below. Customer Service ZSOMS | |
| Review order information/ details Manual Analyse/ Review the data in the report to view the current order position (has Production or Logistics Execution been performed, current billing status etc Customer Service N/A | |
| Need to expedite order? Manual After an analysis of the report, it may be required to expedite the order to meet the delivery date. Customer Service N/A | |
| Liaise with supply chain Manual The process of deciding with supply chain when to expedite a customer order understanding it may disrupt the established schedule. Customer Service N/A | |
| Order blocked? Manual Check if the sales order is blocked. Customer Service N/A | |
| Identify order blocks SAP If blocked, identify the type of block that has been set automatically or manually on the sales order, by running a standard SAP transaction, so that the subsequent resolution for the issue can be determined. Customer Service VA06 | |
| Update incomplete details SAP If the block due to an incomplete order, complete the missing data in the sales order. Customer Service VA02 | |
| Release delivery block SAP Delivery Blocks are either manually or automatically applied to sales documents. If the order is blocked due to a delivery block placed to prevent delivery of an item due to down payment awaiting funds, then block would need to be removed manually once down payment is received. The Accounts team would need to confirm receipt of payment first. | |
| The block is removed only via authorized users and only after necessary confirmation has been received. | |
| VA14L can also be used. Customer Service V.14 | |
| Release billing block SAP If the billing is blocked, it is removed only via authorized users and only after necessary confirmation has been received. Please note that Credit / Debit Memo requests are handled separately via the Credit Debit Process because these need to be authorised by the appropriate Approver in line with JM’s DoA Policy. Customer Service V.23 | |
| IM Outbound logistics execution SAP When blocks are removed, product can be shipped. Logistics N/A | |
| Create customer invoice SAP After product is shipped, invoicing can occur. Billing clerk N/A | |
| 5.7.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.2.4 - Target pricing validation | |
| • 2.4.1 - Emergency order flag indicator for reporting | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| Monitoring of sales orders is a key process to ensure the business achieves on-time delivery in full. The table below lists the currently known list of commercial reports used. | |
| Index Report Description Output File Name | |
| 1 MCRS extract for Lotus Notes upload MCRS 11_120721 | |
| 2 Sales/end-user/country/year A7 | |
| 3 Batting list to be discussed with production Batting List - 15.07.21 (TG – variant Batting List ) | |
| 4 Q4 List (Q4 - variant (IB Download)) Quote history Q4 (2001-2099) 08.07.21 | |
| 5 AA – BJC01 PURASPEC 2443M | |
| 6 AA Despatches Report AA Report GB30 IN10 US32 | |
| 7 Download PA Line Items for Pivot Table – A complete download of all the transactions, characteristics and value fields SQ01L10621 | |
| 8 SD SALES FORECASTS/QUOTES/ORDERS REPORT SQ01ZB0621 | |
| 9 SAP Document Details – Specific layout to determine industry group linked to sales order based on sales doc KR SQ01ZZ0621 | |
| 10 PA Analysis KE24SplitVal0621 | |
| 11 Compared to MCRS report to see if margins are as expected KE30 | |
| 12 EO uses for monthly reporting, Jennifer uses for history AN Flexible Global Sales Report | |
| 13 Monthly AMOG download JT report | |
| 14 Month end reports - Forecasts/Quotes/Orders SQ01 - ZB w/ variant US38 RAA | |
| 15 Month end reports SQ01 ZC w/ variant "Batches-US38) | |
| 16 Notification of order confirmation Automatic emails of order confirmation from SAP | |
| 17 US38 RAA is from transaction is my version of ZR13 | |
| Used for forecasts and has look ups to fill in full sales manager name US38 RAA 15072021 | |
| 18 Forecasts, month end sales SQ01 - ZB w/ variant US38 RAA | |
| 19 Month end ZZMAC078 with variant US38 within System – Services – Reporting (transaction SA38) | |
| 20 Monthly Target Collection Report ZAR_OI_ANALYSIS | |
| 21 Sales analysis SQ01, user PW, variant L1 | |
| 23 Used to create monthly margin analysis, | |
| this is basis for Tableau data PA Download June 2021 | |
| 24 Used for monthly report on bin surcharges (A custom layout is set up to show freight condition breakdown) SQ01-TX - SD Billing Document Details Report with Conditions | |
| 25 Used for downloading actual figures to our forecast access db SQVI – ZACTFOREC | |
| 26 Used for downloading actual figures to our forecast access db SQVI – ZKONV | |
| 27 Used for updating of KPI data SQVI – ZORDSE33 | |
| 28 Used for keeping track on actual sales/received orders for reporting to Commercials and Finance SQ01 – A1 | |
| 29 Used for reporting of actual sales/invoices for reporting to Commercials and Finance. Also used for reporting to statistics sales to Swedish Central Bureau of Statistics SQ01 – ZA | |
| 30 Used to find open orders at a point in time SQ01 => Standard area => User Group: PW => Name: UM – OPEN ORDRS AT A POINT IN TIME | |
| Figure 18 – AS-IS List of Commercial Reports | |
| The JM CT SAP system is a mature ECC implementation where, as can be seen in the table above, many bespoke reports have been created to support the current ways of working and reflects the current system design. | |
| It has not been possible, in the Detailed Design timeframe, to carry out an exhaustive review of each of these reports. Additionally, as new scope items are introduced; there will be an inevitable impact upon reporting. | |
| The guiding principle, during Realisation, will be to use SAP standard reporting wherever possible. However, it is also acknowledged that at least one non-standard report will be required. This will be designed to act as a Workbench for Customer Services with respect to sales order processing. | |
| It is envisaged the report will provide the following functionality: | |
| • Comprehensive selection screen parameters | |
| • Enhanced integration of data (such as delivery and stock availability information) | |
| • Functionality enabling the replacement of multiple legacy reports | |
| • Calls to standard SAP functionality from the reporting results screen | |
| • Increased robustness and lower costs of maintenance compared to current reporting. | |
| The key requirements satisfied by this design will be to provide enhanced real-time reporting facilities (when compared to SAP standard reports) whilst facilitating access to the necessary update functions to allow the users to speedily complete their regular transactional processing needs. This approach mimics the standard SAP approach widely used, in transactions such as VA06 – The Sales Order Monitor. | |
| If additional reporting requirements are identified during Realisation, they will be subject to change control and agreed based on business need. | |
| 5.7.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.7.2. Level 4 Process Description – 02.04.02.02 Execute Period End Processing | |
| On a monthly basis, steps will be taken to ensure all invoicing and goods issue are completed and cash applied. | |
| JM CT Requirements: | |
| • Execute month end processing | |
| • Rationalize and move toward standard SAP reports | |
| 5.7.2.1. Level 4 Process Flows and Steps | |
| 02.04.02.02 Execute Period End Processing | |
| Figure 19 – Process map 02.04.02.02 – Execute Period End Processing | |
| Process Steps: | |
| 02.04.02.02 Execute Period End Processing | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Remove billing block of any post goods issued SAP User runs VL06o to identify recently goods issued deliveries. Selection criteria are Shipping Point, Actual Goods Movement Date and Total Goods Movement Status. | |
| For recent deliveries, the corresponding sales order billing block is removed if not already invoiced. Logistics VL06o | |
| Check all deliveries and returned deliveries are billed SAP For any of the above deliveries that are unbilled – raise the invoice accordingly. Customer Service VF04 | |
| Check goods issued completed for invoices issued SAP For recently created invoices – confirm goods issue is complete. Customer Service ZSOMS | |
| Released blocked billing documents to accounting SAP User runs VFX3 to identify any invoices that have not released to accounting. Finance VFX3 | |
| Process customer account clearing SAP Refer to 2.7.1.1 for the customer account clearing process Finance N/A | |
| Review AR analysis reports SAP Review reporting Finance N/A | |
| Close customer accounts SAP Close customer accounts for period end Finance ZM30_OB52 | |
| 5.7.2.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| This process is currently being completed by SAP sites and will be adopted by the consolidation sites. | |
| 5.7.2.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.8. Level 3 Business Area – 02.06.01 Evaluate & Monitor Customer Credit | |
| 5.8.1. Level 4 Process Description – 02.06.01 Maintain Customer Credit Master Data | |
| This process analyses the credit worthiness of customers, according to JM CT company policy, and allocates a credit management record accordingly. The aim is to protect JM from the risk of financial loss from non-payment or bankruptcy of a customer. Controls are provided to manage credit risk, reduce bad and aged debt, maximize profitable sales and improve debt collections, cashflow, and working capital. Possible outcomes are: | |
| • Credit permitted and assigned accordingly | |
| • Credit refused; alternative payment terms required to agree a sale. | |
| Customers must be identified through key information entered into the New Account Set-Up / Credit Application Form. It is mandatory for this form to be completed by the customer prior to credit assessment and account opening in order to meet JM’s “Know Your Customer” requirements. | |
| Before credit is extended to a customer, the customer’s credit worthiness is assessed and an appropriate credit limit is authorized, set, and monitored. When possible, JM will use the credit assessment from a reputable Credit Rating Agency (CRA). The credit limits must comply with the Credit Group Authority Matrix. The credit assessment must be done at legal entity level. | |
| The results of this evaluation are maintained in SAP as a credit management record assigning a Credit Control Area, a Risk Category and credit limit. In some cases, a Reference Credit Account is assigned whereby a given customer shares, and consumes, the credit limit of an associated customer. | |
| Every customer must have a risk category to determine review frequency according to the JM Credit Risk Policy. | |
| Figure 20 – JM CT Credit Risk Categories | |
| Credit assessment and credit checks must be completed for all new customers prior to creation in the system. The CRA’s reference number (D&B’s DUNS Number) and company registration must be entered into the designated fields. In addition, all accounts must have a credit limit. If no credit limit is extended, a “1” must be entered. The credit limit should not be left blank. | |
| Credit limit reviews should be conducted based on the frequency indicated by the risk categorization. | |
| Credit Management reports relevant to master data include: | |
| Report Description | |
| RFDKLI10 Customers with missing credit data. | |
| This report checks the data for the credit limit for completeness and produces the corresponding error lists. These can be used to re-maintain the corresponding definitions manually, or per Batch Input. | |
| RFDKLI20 Reorganization of credit limit for customers. | |
| This report enables you to reorganize the credit limit information in the control areas. | |
| RFDKLI30 Short overview credit limit. | |
| The report lists the central and control area-related data per customer. | |
| RFDKLI40 Overview credit limit. | |
| The report provides you with an extensive overview of the customer’s credit situation. | |
| RFDKLI41 Credit master sheet. | |
| The credit master sheet enables you to display and print out the customer master data for a single account, which is needed for the area of credit management. | |
| RFDKLI42 Early warning list. | |
| The early warning list enables you to display and print out customers in credit management, who are viewed as critical customers in the area of credit checks in SD. | |
| RFDKLI43 Master data list. | |
| The master data list enables you to display and print out customers’ credit cards. | |
| In particular, you can display information not contained in the standard system, for example, user-defined fields or external data, which you have created with specific additonal software. | |
| RFDKLI50 Mass change credit limit data | |
| This report allows quick mass change for master data in credit management. | |
| RFDKLIAB Change display, credit management. | |
| With this report, you can display changes for credit management master data for all accounts. | |
| RVKRED08 Checking sales documents which reach the credit horizon | |
| Figure 21 – List of Credit Management Reports – Master Data | |
| JM CT Requirements: | |
| • Provide a single credit control area per company code | |
| • Provide an efficient process to evaluate the credit worthiness of new customers based on established guidelines before JM enters into business transactions with them. | |
| • Enable timely fulfilment of commercial transactions with acceptable credit risk. | |
| • Provide the ability to aggregate individual customer credit profiles into a customer group to understand the macro-level risk in JM’s credit portfolio | |
| • Manage credits in SAP for customers that exist in multiple regions or BU (RTR) | |
| • Determine what level credit limits are set: by customer legal entity, geographic region/country, key customer. | |
| • Enable JM to compare customer credit exposure against credit policies and guidelines | |
| • Report visibility of credit status to appropriate personnel | |
| • Report the number of sales orders on credit block and reason | |
| • Report old/small balances on a customer account for cleansing | |
| • Include the credit limit in customer master data | |
| • Harmonize risk categories and corresponding rules | |
| • Remove credit checks for intercompany sales | |
| • Develop a process for systematic credit approvals. It was agreed to meet this requirement in Lotus Notes as currently done by Germany. | |
| 5.8.1.1. Level 4 Process Flows and Steps | |
| 02.06.01.01 Maintain Customer Credit Master Data | |
| Figure 22– Process Map 02.06.01.01 – Maintain Customer Credit Master Data | |
| Process Steps: | |
| 02.06.01.01 Maintain Customer Credit Master Data | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receive Credit Request Manual A request for a new credit management record is received. However, if there is an existing credit record already for this customer, this will be evidenced by the existence of a credit management record in SAP. Customer Service N/A | |
| Does customer exist? SAP Determining if the customer is new, creates two separate paths | |
| If yes, the new customer process will be completed | |
| If no, the existing credit status will be checked. Customer Service FD32 | |
| Check existing credit status SAP Several reports are available via transaction FD32 that allow an evaluation of the customer credit status. | |
| Additionally, FD32 indicates whether the customer is blocked for credit. Customer Service FD32 | |
| Blacklisted? SAP FD32 indicates whether the customer is blocked for credit. Customer Service FD32 | |
| Inform Requestor Lotus Notes If the customer is on credit block, customer service informs the requestor accordingly. Customer Service N/A | |
| Is CRA report available and adequate? (D&B) Manual The credit assessment must be done at a legal entity level and credit limits must be allocated based on assessment of a credit rating agency (CRA) such as Dun & Bradstreet, if possible, to gather information regarding the new customer’s credit history and current credit standing. The intention of this step is to obtain objective information on the customer’s credit risk from an external party. The customer’s past and current credit standings will determine the monetary amount for the customer’s credit. Credit Controller N/A | |
| Review CRA report Manual The CRA report is reviewed Credit Controller N/A | |
| Is CRA recommended limit higher than the required limit? Manual Check whether allowable limit is higher than the required limit? Credit Controller N/A | |
| Submit required credit limit for approval with risk category Lotus notes If yes, where the credit reference limit indicated is higher than the requested limit approval is requested via Lotus Notes. | |
| Every customer must have a risk category to determine review frequency. Credit Controller N/A | |
| Is sought credit limit over £500K? Manual If no, check whether credit limit requested is over £500K. Credit Controller N/A | |
| Use JM Internal credit scoring model Manual Where the requested limit is over £500k an internal JM credit evaluation is carried out. Credit Controller N/A | |
| Is the customer risk band too risky? Manual Based on the JM Internal Credit Scoring Model determine if the risk ban is too risky. Credit Controller N/A | |
| Seek financial accounts signed by authorized external party Manual If below £500K, obtain financial accounts signed by authorized external party. Credit Controller N/A | |
| Are financial accounts available? Manual Credit Controller N/A | |
| Review financial statements Manual If yes, financial accounts signed by authorized external party reviewed to determine whether the customer is credit worthy. Head of Finance N/A | |
| Is customer credit worthy? Manual Output of the review of company financial statements. Head of Finance N/A | |
| Are at least one bank and three trade references available? Manual Manual request for bank and trade references. Credit Controller N/A | |
| Execute alternative payment terms Manual If no and the customer fails all credit checks and a credit limit is not granted, payment in advance will be requested prior to raising and releasing a sales order. Credit Controller N/A | |
| Extend credit of £25K max. Manual If yes, extend £25K max if bank and trade references are available. Credit Controller N/A | |
| Approved? Manual Approver will be based on amount of credit required. Approver N/A | |
| Notify requestor of rejection reason Manual Requestor will be notified if customer is rejected for credit. Approver N/A | |
| Add credit limit to customer master data SAP After the Credit parameters have been approved, the process will continue with Master Data setting up the customer credit data in SAP. Master Data XD01 / FD32 | |
| 5.8.1.2. To-be Changes | |
| During Detailed Design it was determined that Germany will be the baseline for the process to determining and maintaining credit limits. Use of the Lotus Notes database, with its built-in workflow functionality, will be adopted throughout JM CT. | |
| JM CT Credit Management policy maintains four risk categories, but only two are maintained in SAP for purposes of credit checking sales documents. This will be reviewed during the detailed credit management investigation and additional categories created if the business requirement is to do so. | |
| Customer credit groups will be assigned for reporting purposes to agglomerate risk to a specific customer globally. | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.6.1 - Improvements to Credit Management | |
| • 2.9.2 - Customer master data | |
| • 3.2.7 - Credit management | |
| 5.8.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.8.2. Level 4 Process Description – 02.06.01.02 Complete Customer Credit Check | |
| This process focuses on applying credit monitoring activities to sales order processing by looking at the customer’s total credit limit compared to the open balances that are owed to the company. | |
| Automatic credit checks are executed at: | |
| • Sales document creation and change. | |
| • Delivery creation | |
| • Post Goods Issue. | |
| Credit checking applies only to document types and item categories that are agreed to be checked. For example, standard orders are subject to credit checks whereas quotations and returns orders are not. | |
| The credit checks executed are additionally determined by the Risk Category assigned to the customer in credit master data. JM CT currently has two risk categories: | |
| • 010 - Standard Risk customers | |
| • 020 - Possible slow payment by Agent | |
| Additionally, these checks are further defined by the Document Credit Group, being: | |
| • Credit Group for Sales Order | |
| • Credit Group for Delivery | |
| • Credit Group for Goods Issue. | |
| Finally, these checks may be refined by Credit Control Area. | |
| This means that the precise credit control checks can be determined by Credit Control Area, Customer credit Risk Category and whether the transaction is the creation of a sales order (or change), the creation of a delivery document, or whether the delivery is being Post Goods Issued. | |
| Documents that are blocked by the checks described above can generate alerts to credit managers. Additionally, they appear on a range of standard reports. From these reports the credit control staff can release documents should the risk appear justified. | |
| Credit Management monitoring reports include: | |
| Report Description | |
| RVKRED06 Checking blocked credit documents. | |
| The report checks all blocked documents from credit view. The report is started in the background, and should run after the incoming payments programs. | |
| RVKRED77 | |
| Reorganization credit data SD. | |
| The report enables you to reorganize open credit, delivery and billing document values. It is used, for example, when updating errors occur. | |
| RVKRED08 Checking sales documents which reach the credit horizon. | |
| The report checks all sales documents, which reach the dynamic credit check horizon, as new. The report runs periodically and should run at the start of a period. The period for the ‘date of the next credit check’ is proposed from the current date, with the help of the period split for open sales order values. | |
| RVKRED09 Checking the credit documents from credit view. | |
| Released documents are only checked if the validity period for the release has run out (number days). | |
| RVKRED88 Simulation reorganization credit data SD. | |
| Figure 23 – List of Credit Management Reports - Transactional | |
| It should be noted that blocked sales orders do not transfer a requirement to demand management. | |
| In addition, no delivery or shipment should be made to a customer who has exceeded the credit limit (considering sales orders and receivables outstanding) without approval from the authorities for credit limits. | |
| JM CT Requirements: | |
| • Enable timely fulfilment of commercial transactions with acceptable credit risk. | |
| • Provide the ability to aggregate individual customer credit profiles into a customer group to understand the macro-level risk in JM’s credit portfolio | |
| • Enable JM to compare customer credit exposure against credit policies and guidelines | |
| • Report visibility of credit status to appropriate personnel | |
| • Report the number of sales orders on credit block and reason | |
| • Report old/small balances on a customer account for cleansing | |
| • Remove credit checks for intercompany sales | |
| • Report credit blocks likely to occur for confident and planned forecasts in the next three months. | |
| • Apply a blanket credit block on new orders from any customers with over-due invoices (RTR) | |
| 5.8.2.1. Level 4 Process Flows and Steps | |
| 02.06.01.02 Complete customer credit check | |
| Figure 24 – Process Map 02.06.01.02 – Complete Customer Credit Check | |
| Process Steps: | |
| 02.06.01.02 Complete Customer Credit Check | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Process PO Manual Receipt of customer sales order Customer Service N/A | |
| New customer? Manual Determine if customer is in system. If no, follow the “Create and update customer master data” process. Customer Service N/A | |
| Create order and check credit SAP For orders and customers subject to credit management SAP automatic credit checking executes. Possible outcomes are: | |
| • Check passed successfully | |
| • Check failed. Customer Service VA01 | |
| Apply sales order req. transfer block SAP Blocked sales orders prevent the transfer of requirements to demand management so that the system does not procure or manufacture in response to blocked sales order line items. Customer Service VA01 | |
| Review blocked sales order SAP Credit controller regularly runs list of blocked sales orders to identify blocked documents. Credit Controller VKM4 | |
| Why blocked? Manual Determine why the sales order is blocked. Credit Controller N/A | |
| Release blocked sales order SAP Depending upon the reason for the block such as a system issue, the Credit Controller may elect to manually unblock the sales document to allow progression. Credit Controller VKM4 | |
| Remove sales order req. transfer block SAP Where the sales order is un-blocked the sales document line items automatically release and transfer demand. Credit Controller VKM4 | |
| Execute alternative payment terms Manual Where the document is legitimately blocked, or a credit override is regarded as inadvisable; the process is to advise Customer Service so that alternative payment terms (such as payment in advance) can be applied to allow the order to progress. Credit Controller N/A | |
| Maintain customer credit master data Where it is determined that a credit increase would be most appropriate, the Maintain customer credit master data process (02.06.01.01) is invoked to increase the credit limit for the customer. Credit Controller N/A | |
| 5.8.2.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.6.1 - Improvements to Credit Management | |
| • 2.9.2 - Customer master data | |
| • 3.2.7 - Credit management | |
| The primary focus during the workshop review of this process concerned problems with the existing credit checking functionality. Issues mentioned included: | |
| • Inexplicable reasons for blocking of orders | |
| • Large and long-term orders causing a credit breach by fully consuming the customer credit limit | |
| • Small and old balances appearing in the customer’s credit data | |
| • Possible need for additional risk categories | |
| The focus during Realisation will be a through configuration review of the existing CM functionality with a view to addressing the above problems. | |
| Reports such as CHECK_CM will be used to analyse the system reason for blocking, and these will be fed back to the business to agree the most appropriate configuration updates. | |
| 5.8.2.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| Licensing and Formox technology Projects will manage separately at the price fix meeting. Project should not interfere with customer credit on product sales. | |
| 5.9. Level 3 Business Area – 02.06.02 – Perform Customer Billing | |
| 5.9.1. Level 4 Process Description – 02.06.02.01 Create Customer Invoice | |
| ‘Billing document’ is the SAP term for a customer invoice created in SAP. It is sent from a provider of a product or service to the purchaser establishing an obligation on the part of the purchaser to pay. They can either be created individually or en masse by using the ‘Billing Due List’. | |
| The pre-requisite for creation of a billing document is a delivery which has been post goods issued (delivery-related billing), a completed sales order, or billing milestone (order-related billing). | |
| Automated checks are performed in the system to screen for errors in the invoice before it is issued to the customer. Reviews should be performed, and corrective action taken to correct and complete the invoice before issue. For project related invoices the referenced billing WBS must have been released. The invoice document may only then be generated and issued to the customer. | |
| Invoices, when possible, should be issued the same day as dispatched goods or upon the provision of services (milestones/completion). They must accurately quote the correct tax, payment terms, and JM bank account details and meet all legal requirements. | |
| JM CT Requirements: | |
| • Harmonize and modernize invoice format | |
| • Automate single recipient invoices and provide a process for multiple recipient invoices | |
| • Provide freight and tax on invoice | |
| • Display origin of goods statement on invoice automatically | |
| • Display the preferential origin statement | |
| • Include tax when applicable on customer invoice | |
| • Provide a solution for delivered duty paid (DDP) for the UK due to Brexit | |
| • Provide a payment due date change process (UK cannot update baseline date) (RTR). | |
| 5.9.1.1. Level 4 Process Flows and Steps | |
| 02.06.02.01 Create Customer Invoice | |
| Figure 25 – Process Map 02.06.02.01 – Create Customer Invoice | |
| Process Steps: | |
| 02.06.02.01 Create Customer Invoice | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Create customer order SAP Execute create customer order process Customer Service N/A | |
| Order related? Manual Determine the basis of billing: Delivery or order based. Customer Service N/A | |
| Outbound logistics execution SAP For standard delivery processing, follow logistics process 5.2.2.1 IM outbound logistics execution. Logistics N/A | |
| Individual? Manual Determine if individual or multiple invoices will be processed. Billing Clerk N/A | |
| Complete unscheduled billing SAP This step represents unscheduled billing. In the case of delivery related billing, the delivery or deliveries to be billed are entered. The system determines the billing document type and the billing date, and an invoice is generated. Billing Clerk VF01 | |
| Complete due list billing SAP Execution of the billing dues list which may be manually triggered or initiated via a scheduled job. All documents ready for billing that match the selection criteria are billed automatically, and a log of the run is created. | |
| When executing collective invoice correction, SAP will attempt to combine source documents into a single invoice wherever possible. However, the following fields, for example, will cause a split: | |
| • Different billing dates | |
| • Different Payers | |
| • Different payment terms | |
| • Different payment method, etc. Billing Clerk VF04 | |
| Successful? Manual Determining if invoice creation was successful. Billing Clerk N/A | |
| Review Billing Blocks SAP If not successful, run report to list sales orders blocked for billing – header level blocks only – “SD Documents Blocked for Billing” | |
| Filter by document category to exclude quotations. Billing Clerk V23 | |
| Remove Billing Block SAP Documents returned by V23 can be selected and VA02 – edit sales document is invoked. The billing block can then be removed enabling billing to be carried out. | |
| For order related billing, the bill block is removed straight away. Billing Clerk VA02 | |
| Add freight if applicable SAP Add freight charges (which can include bin surcharge). Billing Clerk VF02 | |
| Deloitte e-invoice bolt-on SAP US tax will be added to the invoice through integration with a tax engine. Billing Clerk N/A | |
| Account revenue recognition SAP For projects, process 8.1.4.5 Account revenue recognition should be used. Billing Clerk N/A | |
| Save invoice SAP Invoices created by VF01 or VF04 are saved automatically. | |
| Numerous automated checks are executed to ensure Release to Accounting can occur. Possible failures include: | |
| • Posting period is closed | |
| • GL Account determination error | |
| • WBS not released. Billing Clerk VF01/VF04 | |
| Posted to Accounting? Manual Check if posted. Billing Clerk N/A | |
| Correct Invoice Errors SAP In the case of invoices that fail to release to accounting, this step allows the Finance team to review the cause of the error and correct where possible. Billing Clerk VF02 | |
| Release billing documents SAP Corrected documents will release to accounting automatically upon saving the updated invoice. Billing Clerk VFX3/VF02 | |
| Resolved? Manual Check if resolved. Billing Clerk N/A | |
| Invoice reversal SAP Reverse invoice if errors are not resolved Billing Clerk VF02 | |
| Create invoice output SAP Output master data determines the invoice output type to be used, for example RD00 – Invoice. | |
| This output will only be instantiated if the invoice is complete and released to accounting. | |
| It is a requirement that project Concert will review and rationalise the invoice output types used and update the layout. The updated layout will additionally support new functionality adopted by Concert, such as Down Payment processing. Billing Clerk VF02 | |
| Send invoice to customer Manual Output master data determines whether the invoice output is printed or emailed to the customer. Billing Clerk N/A | |
| 5.9.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.1A - Introduction of Milestone Billing plans and down payment processing | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.6.2 - Sales invoice enhancements | |
| Invoice outputs will be reviewed in detail during Realisation so that harmonised and updated layouts are used. During the process we will attempt to further harmonise the approach by rationalising and reducing the number of different output types used by the business. | |
| Support for Down Payment processing will require use of a new invoice type – FAZ - Down payment request. This will post to a special general ledger transaction A with an alternative general ledger account. This will require configuration by the Finance team. | |
| Subsequent billing will be with a standard F2. The billing document will have two items: one for the final invoice and one for the down payment settlement. Settlement of the down payment will be processed automatically upon invoice release to accounting. | |
| Some discussion was had regarding the approach to delivery and order-based billing. It is noted that a process is in use whereby delivery of catalyst product is managed using order-based billing. The rationale for this is that there is frequently an over-delivery due to customers ordering by volume and the business supplying by weight. This is further complicated by the packed-density issue to convert and the use of transaction ZL02n to add batches to the delivery. The business requirement is to invoice the ordered quantity rather than the delivered quantity. There is currently no project proposal to alter this approach; however, opportunities to move to delivery-based billing will be explored during Realisation. | |
| Revenue Recognition for Projects | |
| There is a business requirement that milestone billing for projects should be subject to revenue recognition. From the sales and billing point of view, this requirement will be achieved by posting relevant invoices to GL Account 18700000. This will be driven by the Material Account Assignment on the service material used in the sales order line item. Revenue will be moved to the sales revenue GL Account by the Project Results Analysis process. | |
| Surcharges | |
| Savannah has a requirement to add a bin surcharge to the customer invoice. This charge is a portion of the return freight for bins. Currently it is calculated on a spreadsheet (35% of return freight for 1-8 bins and 50% of return freight for 9-16 bins) and either added to regular freight or recorded as a separate line on invoice depending on customer requirement. Requirement is to automate with 3 condition options on invoice for regular freight, surcharge combined with freight, and surcharge and freight separate. Each month, a Bin Surcharge report is run to show the amount paid on return bin shipping and surcharges fees collected from the customer. The goal is to collect 50% of the return bin shipping. Pacman is currently used to manage the bin inventory with no scope to change. | |
| 5.9.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| Savannah | |
| Bin surcharge needs manually adding to the outbound invoice – meaning we cannot use the billing due list as each invoice requires manual update. Packaging managed off-SAP and charges manually entered. | |
| Licensing For licensing business, the invoice will be sent to the project manager who will send to customer after collecting the required documentation. | |
| 5.10. Level 3 Business Area – 02.07.01 Process Accounts Receivable (AR) | |
| The following Level 4 processes described will be adopted by JM: | |
| 02.07.01.01 Process Customer Account Clearing | |
| 02.07.01.02 Process Lockbox and Manual Receipts | |
| 02.07.01.03 Perform Bank Reconciliation | |
| 02.07.01.04 Manage Bad Debts Accounting | |
| 02.07.01.05 Create Customer Statement | |
| 02.07.01.06 Process Withholding Tax | |
| 5.10.1. Level 4 Process Description – 02.07.01.01 Process Customer Account Clearing | |
| Customer account clearing is the process that is carried out when customer payments are received and are matched against outstanding items. | |
| JM CT Requirements: | |
| • With introduction of BCM, the to-be process flow is required to be updated across sites. | |
| 5.10.1.1. Level 4 Process Flows and Steps | |
| 02.07.01.01 Process Customer Account Clearing | |
| Figure 26 – Process Map 02.07.01.01 – Process Customer Account Clearing | |
| Process Steps: | |
| 02.07.01.01 Process Customer Account Clearing | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receipt method Manual The process is triggered when the accounting Clerk determines if the payments required to be processed is a lockbox receipt, Manual receipt, Bank Statement or Notional intercompany settlement. Finance N/A | |
| Match and clear Electronic/Man in open item SAP If the payments to be processed is a lockbox receipt, Manual receipt, the payment file is processed through transaction FEBAN and automatically matched. Finance FEBAN | |
| Elect/Man ‘In’ clearing accounts zero SAP The Accounting clerk checks if the clearing account balances to zero. At this point there is a possibility the clearing account may not balance to zero. Finance FBL3N | |
| Receipt Method Manual If the clearing account doesn’t balance to zero, the finance clerk will check if the payment receipt method is ‘Electronic Fund Transfer (EFT) or non-EFT. This step is also carried out if a Bank Statement is being processed. Finance N/A | |
| SAP Originated Receipt SAP If the payment receipt method is non-EFT, the clerk will check if the payment receipt is originated within SAP System. If the payment is non-EFT and originated with SAP system, the process is looped back to the matching and clearing of the open item. Finance FB03 | |
| FBL5N | |
| FBL3N | |
| Post to Correct Account SAP After checking if the payment receipt is non-EFT and is not originated within SAP system, then a manual posting is made to the correct account. Finance FEBAN | |
| Customer Ref and Value Match SAP If the payment receipt is an EFT, the finance clerk checks if the Customer reference and the value of the items are matched. Finance N/A | |
| Identify customer and apply receipt to customer account SAP If the customer reference and value of the items are not matched, the clerk manually identifies the customer and applies the receipt to the invoice. Finance FEBAN | |
| Invoice ref and value match SAP The Clerk will check if the invoice reference and the value match on the customer account. Finance FBL5N | |
| Find invoice number? SAP If the invoice reference and value do not match, the clerk finds the invoice for further investigation. Finance VF03 | |
| Clear AR open item as partial payment or residual item SAP Once the invoice is found, the clerk will then clear the AR open item if it is a partial payment. Finance F-28 | |
| Resolve unapplied cash or underpayment with customer Manual After the invoice and receipts have been investigated and it has been established there is unapplied cash, the clerk then matches the payments or if there is an underpayment by the customer, the issue will be resolved with the customer. Finance N/A | |
| Background Autopost | |
| and clear AR open item SAP Once all the discrepancies have been resolved and the customer open items are matched with the receipts, the background job is triggered to run the autopost and clearing of customer open items. Finance F.13 | |
| 5.10.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| 2.4.6 - Migrate to STC template for consolidation sites | |
| 3.5.1 – Electronic bank statements | |
| With introduction of BCM, the bank statements for the incoming receipts will be processed using the transaction FEBAN. | |
| JM business will use the automatic account clearing (F.13) program will clearing the customer line items. | |
| Bank Reconciliation accounts will be introduced to capture the bank transactions accurately. | |
| No changes planned for current SAP sites. | |
| 5.10.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.10.2. Level 4 Process Description – 02.07.01.02 Process Lockbox and Manual Receipts | |
| Lockbox is a product used primarily within the USA to facilitate cheque receipts. Customers send their cheques directly to JM’s Bank. The bank opens the mail and scans cheques and associated remittance information. Scanned images are available through an online platform for record-keeping. Lockboxes can be opened at multiple locations to cater for clients sending cheques from different localities. | |
| Manual receipts of cheques are processed in a similar way as the lock box process. The cheques are receipted physically by JM and are then sent to the bank for processing. The bank processes the cheques as above. | |
| JM CT Requirements: | |
| • Provide a customer account clearing process for all sites | |
| 5.10.2.1. Level 4 Process Flows and Steps – 02.07.01.02 Process Lockbox and Manual Receipts | |
| 02.07.01.02 Process Lockbox / Manual Receipts | |
| Figure 31 – Process Map 02.07.01.02 – Process Lockbox and Manual Receipts | |
| Process Steps: | |
| 02.07.01.02 Process Lockbox Receipts (US only) / Manual Receipts | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Log into bank account Manual Finance N/A | |
| Run and download report Manual Finance N/A | |
| Apply payment SAP AR clerk will apply the payment to the customer account. Accounts Receivable F-28 | |
| 5.10.2.2. To-be Changes | |
| The relevant scope items for this process are: | |
| 2.4.6 - Migrate to STC template for consolidation sites | |
| 3.5.1 – Electronic bank statements | |
| 5.10.2.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.10.3. Level 4 Process Description – 02.07.01.03 Perform Bank Reconciliation | |
| Bank reconciliation process has been covered in the RTR BPD at L3 - 03.03.03 Manage operational banking relationships. | |
| Please refer to section 5.8.1 of RTR BPD | |
| 5.10.4. Level 4 Process Description – 02.07.01.04 Manage Bad Debt Accounting | |
| Bad debt management is the process where customer receivables are monitored at regular frequencies and actions taken there has been a delay in the payment or a failure in payment. It also includes the process for recording impairments or accruals for potential bad debts. JM will follow the standard dunning procedure and send the reminders complying with JM policies. The finance and commercial teams might also contact the customers to follow up on overdue invoices. | |
| JM CT Requirements: | |
| • Introducing Dunning letters to send reminders to the customers. | |
| 5.10.4.1. Level 4 Process Flows and Steps | |
| 02.07.01.04 Manage Bad Debts Accounting | |
| Figure 27 – Process Map 02.07.01.04 – Manage Bad Debt Accounting | |
| Process Steps: | |
| 02.07.01.04 Manage Bad Debt Accounting | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Run the customer aged debt report SAP Finance run the Customer aged debt report as a regular activity to monitor the payments received. Finance ZAR_OI_ANALYSIS | |
| Analyse report and calculate Impairment | |
| (IFRS9 Calculations at CT level) Manual The aged debt report is analysed, and the impairment calculations are applied as per the IFRS9 calculations at CT level across all sites. If there are any impairments, the postings will be made accordingly. 03.01.07.01.01 – Manual journals process is followed to make the postings. Finance N/A | |
| Contact customer if no response to Dunning level 2 Manual In parallel to the impairment calculations and postings, Dunning process is also carried out and reminder letters will be sent to the customers. | |
| If the customer failed to respond to the 2nd Dunning letter, the Account manager contacts (either mail or phone) the customer to follow up on the payments. Finance N/A | |
| Has the customer responded? Manual The Account manager checks if the customer has responded and agreed on the payments. If the customer responded and agreed to pay, no further action is taken. | |
| If the customer has failed to respond, then the Dunning is carried out for the Level 3. Finance N/A | |
| Contact customer if no response to Dunning Level 3 Manual If the customer has failed to respond the 3rd Dunning letter, Commercial/Customer Service team contact the customer to follow on the failed payments. Account Manager / Customer Service N/A | |
| Has the customer responded? Manual If the customer responded and agreed to pay, no further action is taken. | |
| If the customer failed to respond the details will be handed over to the legal team for further action. Account Manager / Customer Service N/A | |
| Follow up with the customer and take action accordingly Manual At this point the legal team may follow up with the customer and proceed with further legal action. | |
| Legal N/A | |
| Is the debt collectable? Manual After the communication with the customer, the legal team may decide if the bad debt is collectable. If the customer agrees to pay, no further action is required. | |
| If the payment is not collectable JM finance team will be notified of the bad debt. Legal N/A | |
| Impairment is written off SAP JM Finance team will write off the impairment Finance FV50 | |
| Customer account is cleared against the provisions SAP The debt on the customer account is cleared off against the provisions so no further reminders are sent to the customer. Finance F-04 | |
| 5.10.4.2. To-be Changes | |
| The relevant scope items for this process are: | |
| 2.4.6 - Migrate to STC template for consolidation sites | |
| 2.7.1 – Implement Dunning procedure | |
| This process will include the responses from the dunning letters sent out prior to reaching out to the customers by the respective teams. | |
| 5.10.4.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.10.5. Level 4 Process Description – 02.07.01.05 Create Customer Statements | |
| The usage of customer statements is optional. In SAP standard, customer statements are generated at legal entity level. Each account statement will contain the invoices and credit notes relevant to that customer. | |
| JM CT Requirements: | |
| • Create and distribute customer statements to notify customers of invoices and credit when required. | |
| • Rationalize and move toward standard SAP reports to support collection activities | |
| • F.27 - Requirement is to create a customer account statement covering all business requirement. Issues currently with customer statements (logos etc…) (RTR) | |
| 5.10.5.1. Level 4 Process Flows and Steps | |
| 02.07.01.05 Create Customer Statement | |
| Figure 28 – Process Map 02.07.01.05 – Create Customer Statements | |
| Process Steps: | |
| 02.07.01.05 Create Customer Statements | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Is account statement indicator set in customer master? SAP Finance verifies if the “account statement indicator” is set in customer master data. If not, Finance contacts the customer master data responsible with the request to maintain it. Further details of process are described in “Maintain Customer Records”. Finance FD03 | |
| Create customer statement SAP Once the account statement indicator is properly maintained in customer master data, the statement can be created Finance F.27 | |
| Generate correspondence SAP As next step the correspondence is generated. (The open item list or the payment notice is issued to the screen). Finance F.61 | |
| Display customer account statement SAP Finance can display the statement and check whether it is correct. Finance FBL5N | |
| Check if correct? SAP If the statement is not correct, the statement can be recreated. The statement might be incorrect because the wrong type was selected (e.g. open items list instead of payment notice) or the wrong date was used. Finance FBL5N | |
| Send customer statement to customer SAP If the customer statement is correct, the statement can be sent to the customer, either via post or e-mail. The preferred method is to send statements by email to customers where possible. Finance N/A | |
| 5.10.5.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 3.2.6 – Correspondence - Customer Statements | |
| This is a new process as customer statements are not created currently. | |
| 5.10.5.3. Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.10.6. Level 4 Process Description – 02.07.01.06 Process Accounts Receivable with Withholding Tax | |
| Withholding tax is a government requirement for the payer of an invoice to withhold or deduct tax from the payment and pay that tax to the government. Typically, withholding taxes are deducted from the amount to pay as the tax will be paid by the customer. | |
| SAP handles withholding taxes in Accounts Receivable (FI-AR). When a customer payment is entered, the system automatically calculates the taxes withheld by the customer and makes the corresponding accounting postings. | |
| JM CT Requirements: | |
| • Process withholding tax. | |
| 5.10.6.1. Level 4 Process Flows and Steps | |
| 02.07.01.06 Process Accounts Receivable with Withholding Tax | |
| Figure 29 – Process Map 02.07.01.06 – Process Accounts Receivable with Withholding Tax | |
| Process Steps: | |
| 02.07.01.06 Process Accounts Receivable with Withholding Tax | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Is payment short? Manual Decide if payment is less than invoice amount Accounts Receivable N/A | |
| Process customer account clearing SAP If payment is not short, complete the customer account clearing process Accounts Receivable N/A | |
| Ask customer why? Manual Ask customer why the payment is short Customer Service N/A | |
| Complete a partial clear while waiting for withholding tax certificate SAP If payment is short due to withholding tax, complete a partial clear while waiting for withholding tax certificate Accounts Receivable F-28 | |
| Create a customer credit with an offset to the balance sheet after receipt of the certificate SAP Create a customer credit with an offset to the balance sheet after receipt of the certificate Accounts Receivable FB70 | |
| Apply credit note to remaining balance SAP Apply credit note to remaining balance Accounts Receivable F-28 | |
| 5.10.6.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| 5.10.6.3. Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| US US has no certificates at time of cash collection so WHT is transferred to GL upon confirmation. | |
| 5.11. Level 3 Business Area – 02.07.02 – Process Collections | |
| 5.11.1. Level 4 Process Description – 02.07.02.01 Complete Debt Notification | |
| Collections refers to money owed to a business by a customer. When a customer does not pay the business within the terms specified, the amount of the bill becomes past due, and notifications are sent to the customer. Dunning is the process of methodically communicating with customers to ensure collections of accounts receivable. | |
| Dunning process in SAP is used to issue reminder letters to the customers for the outstanding amounts. Dunning procedure determines the number of dunning levels (reminder letters) to be maintained and is stored in the Customer Master data. Dunning is currently not used in CT, and the requirement is to set up a new Dunning procedure with 3 Dunning levels. Letters will be sent out on the overdue items at 7, 14 and 30 days. Various Dunning procedures can be defined and assigned based on the customer groups and credit management. | |
| Aged debt reports must be run at least twice a month to track collection progress and focus collections accordingly. It only applies to bill to and sold to customers. | |
| Businesses must hold accurate contact details and payment run dates of customers in ERP. Notifications must be sent to customers when debtors become overdue to ensure all overdue invoices are paid as soon as possible. Challenges in collecting past due invoices should be escalated to the account manager if the amount is greater than £100,000 or if the customer does not respond. All notes in relation to collection activities must be entered into the ERP system, if possible, for a clear audit trail. | |
| Prior to late payment interest, approval must be given from the BU Financial Controller. Mediation of legal action must be a last resort. The BU Financial controller, legal, sales, and regional finance director must agree on actions, communicate actions with counterparts in other sectors with a shared customer, and obtain Sector Financial Director approval. This is very seldom in JMCT. | |
| Metrics and reports | |
| • Days Sales outstanding | |
| • Aged Debt Analysis | |
| • Weighted average overdue days | |
| • Bad debt | |
| • Weighted average payment terms | |
| • Customer exposures | |
| • Customers where credit limits had to be increased | |
| • Other - List of customers with overdues over 90 days; customer segmentation into high/medium/low risk; customers where debtors reach 80% of the credit limit; customers where the credit limit is >10% of the customer’s net worth; customers on credit block; debt in dispute (e.g. amounts, volume and time to resolve); cash collection targets; billing accuracy; longest outstanding debtors | |
| JM CT Requirements: | |
| • Create and automatically distribute Dunning Letters for customers to provide a method for debt notification and collection including a method for an accurate start date in SAP (ex based on receipt of invoice - - back to payment term issues) and maintenance of emails. Business would like to control if this is not wanted in certain situations | |
| • Capture notes from collection phone calls | |
| • Rationalize and move toward standard SAP reports to support collection activities | |
| • Reduce days of sale outstanding | |
| 5.11.1.1. Level 4 Process Flows and Steps | |
| 02.07.02.01 Complete Debt Notification | |
| Figure 30 – Process Map 02.07.02.01 – Complete Debt Notification | |
| Process Steps: | |
| 02.07.02.01 Complete Debt Notification | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Create Dunning proposal SAP Finance Clerk creates the dunning proposal. This is a list of all overdue items for all customers in scope of the dunning run with their respective dunning level. The dunning level reflects the severity of the overdue items. Each level is linked to a certain lay-out of the dunning letter. The letter for dunning level 1 typically represents a friendly reminder, whereas level 2 is a stricter request for payment. Certain customer accounts can be excluded from the dunning run. Finance F150 | |
| Dunning proposal reviewed and approved? Manual Approver is informed of the proposal available for review and approval. Approver reviews the proposal for completeness. They can reject the proposal if any inconsistency is found. Finance N/A | |
| Edit Dunning proposal Manual If the proposal is rejected, it is sent back to the finance clerk for amending the proposal and sending for approval. | |
| All changes made to the dunning proposal are logged directly on SAP UP, so that the audit trail can be seen at any time. If too many changes are required, the dunning proposal can also be cancelled and re-created (as often as required). The dunning data in the open items and customer master data is not updated until the final dunning run is performed. Finance F150 | |
| Send for approval to customer service Manual Once the AR Credit Clerk is comfortable with the dunning proposal, he/she sends the proposal to the Customer Services Representative (CSR). In order not to impact customer relations, the AR Credit Clerk should send dunning proposals to the commercial team with the request to review and approve. Customer Service N/A | |
| Agree to send Dunning letter to customer? Manual As result of approval step, the CSR has the chance to avoid dunning letters being sent to customers who have made a promise to pay or for other reasons why the commercial team do not want a dunning letter to be sent. After review, the CSR either approves or rejects the dunning proposal. Customer Service N/A | |
| Execute Dunning run SAP Once the CSR has approved the dunning proposal, the dunning run is executed. At this point in time, the system performs several activities in parallel: | |
| • The dunning letters are created | |
| • The dunning level in the open item is increased, indicating that the invoice reached a more severe state of overdue items. | |
| The dunning level in the customer master data is increased, leading to a more severe text in the dunning letter. Finance F150 | |
| Has Dunning level reached maximum? SAP Finance Clerk check if the customer reached the maximum dunning level. Finance N/A | |
| Manage bad debt accounting Manual If the maximum dunning level is reached, the customer details are passed on to the bad debt accounting team. Finance N/A | |
| 5.11.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.7.1 - Implement Dunning procedure | |
| • 2.9.2 – Customer master data | |
| Dunning process is a new process that will be introduced for JM CT business. A Standard SAP dunning process will be introduced for sending out the reminder letters to the customers as part of the debt management process. There will be 3 levels of reminders sent out and the Dunning letters will be worded as per the business decision and in line with JM policies. SAP forms will be used for generating the output. As a pre-requisite the customer master data is required to be updated with a valid email ID. | |
| 5.11.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.12. Level 3 Business Area – 02.07.03 Process Customer Credits | |
| 5.12.1. Level 4 Process Description – 02.07.03.01 Process Customer Credits for Returns | |
| This process of encompasses the returning of goods to Johnson Matthey, which were previously delivered and invoiced to the customer. Goods might be returned due to issues with the material(s) and / or packaging (e.g. damage in transit). It may also be that the material(s) is simply no longer required by the customer. | |
| Returns must be subject to an approval process before being accepted by JM. Once accepted, the process is fully supported by SAP. Customer Service collects information relevant to the return, including the customer and material details, quantity to be returned and reason for return. The reason for return will be logged in SAP and can be used to analyse customer returns to improve the quality of products, packaging, and customer service. | |
| A return order is created in SAP to facilitate the receipt of returned goods and generate a subsequent credit to the customer. The order can be created without reference to an existing SAP order or invoice. However, it is usually created in SAP with reference to the customer invoice relating to the original sale. When created with reference prices and quantities used on the return order will be inherited from the original invoice to ensure consistency. These may be overridden if required. | |
| Upon receipt, the inventory in SAP is updated. Returned material should be placed into quarantine to be inspected before a decision is taken on whether it can be placed into saleable inventory, requires rework, marked as to be scrapped or written off in case of Lost in Transit scenarios. Customer reimbursement is calculated on a case-by-case basis and can depend on company policy, the relationship with the customer or a combination of both. Return fees have usually been notified to the customer earlier in the process and, if required, may be applied at this stage. Customer credits will normally be subject to an approval process. If this is successful, a credit invoice will be raised in relation to the return and applied to the customer’s account | |
| JM CT Requirements: | |
| • Harmonize process for customer returns and credits | |
| 5.12.1.1. Level 4 Process Flows and Steps | |
| 02.07.03.01 Process Customer Credit for Returns | |
| Figure 31 – Process Map 02.07.03.01 – Process Customer Credits for Returns | |
| Process Steps: | |
| 02.07.03.01 Process Customer Credits for Returns | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Receive customer request to return goods Manual Customer contacts Johnson Matthey and requests return of the material(s). If applicable, request to CS to raise a Customer Complaint using an offline system. Account Manager N/A | |
| Approve return Manual The request is analysed as part of customer claims management (outside of SAP) and using any documentary evidence provided, to check if it is a valid claim and if it can be approved. This might involve discussions with other departments such as Logistics and Quality. Account Manager N/A | |
| Create return sales order SAP If approval is granted, collect information related to the return to create the return order. Information includes customer data, product details, returned quantity and reason for return & the preceding SAP Billing Document reference. The returns order is created with reference to this document. This means that the details from the original document are automatically defaulted into the returns order. If the quantity being returned is less than the quantity originally despatched, it should be changed in the sales order. No other details should be changed (other than adding text). The returns order is automatically blocked for billing on order save. Customer Service VA01 | |
| Create returns delivery SAP When the returns order has been completed and saved, a return delivery is created with reference to the returns order. Customer Service VL02n | |
| Arrange transport Manual Shipping services are arranged for the physical return of material if required, or the Customer themselves might arrange shipping. Within the delivery, the item category indicates that this is a return delivery. Logistics N/A | |
| Post goods receipt for return delivery to restricted stock SAP Following arrival at JM’s warehouse, goods are received in the system directly into quality inspection (blocked stock) The warehouse operator performs a brief visual check of the goods to check for any obvious error in the quantity returned. Shipment Planner completes the delivery in SAP by performing the goods receipt. Goods are received in the system directly into quality inspection (blocked stock) Logistics VL01N | |
| Manage quality inspection Manual Quality inspection of the returned material might be performed, or a visual check might be sufficient. Inspection may result in the material being placed into saleable inventory, reworked or scrapped and the usage decision is therefore applied accordingly. If there is any discrepancy in what has been physically returned and what was stated in the order, inform CS so that the customer is contacted, and further clarification sought. Once Quality inspection is complete, the process to credit the Customer can be initiated. Logistics N/A | |
| Authorized? Manual This activity starts with a decision point to review the Credit memo request and whether it is authorised or rejected. If the credit request is approved, the document is released for invoicing in SAP by removing the Billing block. A return with reference pulls through the costs from the original document and based on the returned quantity entered in the sales order (if not the full quantity originally despatched). Logistics N/A | |
| Transfer to unrestricted stock SAP If yes, product can be moved to unrestricted stock. Logistics MIGO | |
| Create credit return invoice SAP Once the Billing Block is removed, the Invoice (Credit Memo) is triggered. Customer Service VF01 | |
| Process customer account clearing SAP Follow process 2.7.1.1 Process customer account clearing. Accounts Receivable Handoff to AR process | |
| Amend or reject return order and dispose of product safely Manual If after inspection product is not accepted, the return order is rejected, and product disposed of safely. Logistics N/A | |
| Update account manager to inform customer Manual Account manager is notified of rejected return by email. Logistics N/A | |
| 5.12.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| 2.4.6 - Migrate to STC template for consolidation sites | |
| No changes planned for current SAP sites. | |
| 5.12.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.12.2. Level 4 Process Description – 02.07.03.02 Process Customer Credit / Debits | |
| Credit and debit memo requests are sales documents that are used to address customer complaints and correct discrepancies. The credit / debit memo will include an order reason to identify why the amount stated on the memo has been issued. This can be used to analyse credit /debit memo usage in the business. These documents should ideally be created with reference to a preceding document (invoice), but there may be situations where the preceding document cannot be identified and created without reference. | |
| The approval of credit notes must comply with the limits in Group Authority Matrix prior to processing and access to raise credit notes limited restricted to appropriate personnel. Appropriate approvers are based on the order reason and the requested value. | |
| This process also applies to the spent catalyst business in Sweden. Customers can return spent catalyst which is separated from the ceramic rings that can be reused. The customer typically receives a credit for the metal and a debit for the recovery fee. On occasion, the customer may receive payment for the metals. | |
| JM CT Requirements: | |
| • Harmonize process for customer returns and credits | |
| 5.12.2.1. Level 4 Process Flows and Steps | |
| 02.07.03.02 Process Customer Credit / Debits | |
| Figure 32 – Process Map 02.07.03.02 – Process Customer Credit / Debits | |
| Process Steps: | |
| 02.07.03.02 Process Customer Credit / Debits | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Request for Credit / Debit memo Manual The request for a Credit / Debit memo can be received by various departments. Customer Service N/A | |
| Gather necessary information Manual Collect information on affected account (address, sold to SAP number, etc); order reason for credit / debit memo request and value required Customer Service N/A | |
| Preceding document provided? Manual Verify / check the information captured and determine if a preceding SAP invoice reference has been provided Credit Controller N/A | |
| Select credit/ debit without reference SAP If no preceding invoice exists, the debit or credit memo request is created as a stand-alone document Credit Controller VA01 | |
| Select credit/ debit with reference SAP If a preceding invoice exists, the debit or credit memo request is created in the system with reference to that invoice. Credit Controller VA01 | |
| Enter required data, save the document SAP If a credit or debit memo request is created with reference to a preceding document, most required fields are populated with the information that is automatically copied from the reference document, including pricing. The following details need to be entered manually: | |
| 1) Order Reason for the Credit/Debit request being created and | |
| 2) Value of Credit/Debit memo When created without reference all information except for header details (sold to, metal account holder etc. these details should already have been provided in the initial sales activity captured information) will need to be manually entered Credit Controller VA01 | |
| Authorized? Manual This activity is a decision point. The debit or credit memo is created with an automatic billing block. It is reviewed by an authorised stakeholder, and a decision to either approve or reject it. Finance N/A | |
| Notify controller of rejection Manual The relevant stakeholders are notified if the correction invoice debit or credit memo has been rejected. Since the AR Clerk has raised the request, the Finance Controller needs to notify them of the rejection. The AR Clerk then in turn notifies the initial requestor who asked for the invoice debit/ credit to be raised. The Customer can then be informed of the decision. Finance N/A | |
| Remove order billing block SAP If approved, the block is removed Finance V.23 | |
| Create credit /debit memo SAP A customer invoice is generated for the debit / credit memo. Billing Clerk VA01 | |
| What action is required? Manual Decide what course of action is required by commercial / Customer Billing Clerk N/A | |
| Purchase requestion SAP If cash return, apply cash to customer by treating them as a one-time vendor. Then follow STP process 1.4.1.1 Purchase Requisition Procurement N/A | |
| Apply credit to existing invoice SAP The credit can be applied to another existing invoice. Finance F28 | |
| Credit customer account N/A The credit is left on the customer account for future use. The customer should be sent the credit memo. Billing Clerk N/A | |
| 5.12.2.2. To-be Changes | |
| The relevant scope items for this process are: | |
| 2.4.6 - Migrate to STC template for consolidation sites | |
| No changes planned for current SAP sites | |
| 5.12.2.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.13. Level 3 Business Area – 02.09.01 Maintain Customer Records | |
| 5.13.1. Level 4 Process Description – 02.09.01.01 Create and Update Customer Master Data | |
| This process details the steps to maintain customer master data within JM CT. It is anticipated that the review of the customer master will result in updates to certain fields. | |
| The process references assessment of the customer credit worthiness and setting of customer credit data in the system. The credit process is detailed in 02.06.01 Maintain Customer Credit Master Data. Until the customer credit limit is determined, the customer is blocked from processing a sales order. When the credit limit is assigned in the Customer Master Data Record, the block is removed; and transactions can be performed. The request for a new customer should be carried out in parallel with the due diligence checks in accordance with the Risks and Controls Matrix. | |
| For new customers with a low probability of a successful sale (opportunity or doubtful) for a forecast or quotation, the prospective customer account group 005 will be selected. The prospective customer does not require a credit check to be added into Customer Master Data. However, if a sale is successful, the account group will be updated; and a credit check completed prior to processing the purchase order. | |
| It is additionally noted that there is a data cleansing workstream within Project Concert that is updating master data across all workstreams including STC and the JM CT customer master database. | |
| JM CT Requirements: | |
| • Rationalise customer master data such as: | |
| o Payment Terms | |
| o Incoterms | |
| • Add Account Manager as Partner Function to Sold-To customers | |
| • Integration with CRM | |
| 5.13.1.1. Level 4 Process Flows and Steps | |
| 02.09.01.01 Create and Update Customer Master Data | |
| Figure 33 – Process Map 02.09.01.01 – Create and Update Customer Master Data | |
| Process Steps: | |
| 02.09.01.01 Create and Update Customer Master Data | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Request new customer Manual Sales or Customer Service identify the need for a new customer record. Requestor / Customer Service N/A | |
| Does customer exist? Manual Check if customer is in system. Requestor / Customer Service N/A | |
| Request customer master data update Lotus Notes If customer exists, raise request to change customer master data in LN. Customer Service N/A | |
| Credit limit change required? Manual If a credit limit change is required, use 2.6.1.1 Maintain Customer Credit Master Data Finance N/A | |
| Change customer data SAP Update customer master data Master Data XD02 | |
| Complete New Customer and Risk Forms Manual If customer does not exist, manually complete Group new customer and risk forms – new customers only. Sales / Customer Service N/A | |
| Request new customer master data Lotus Notes Raise new customer master data request in LN. Customer Service N/A | |
| Is this a perspective customer? Manual If this is a perspective customer, no credit check is required and the Account Group 005 – Prospective customer will be selected. If a sales order results, the account group will be changed, and a credit check completed. N/A | |
| Request Credit Check Email New customers – request for a credit check if not prospective. Finance N/A | |
| Maintain customer credit master data Manual Use 2.6.1.1 Maintain Customer Credit Master Data Finance N/A | |
| New customer approved? Manual Check approval. Finance N/A | |
| Notify requestor of reason for rejection Email In case of new customer rejection, notify requestor. Finance N/A | |
| Create customer SAP If approved, create new customer record – central, company code and sales area views. If this is a perspective customer, Account Group 005 will be entered. Master Data XD01 | |
| Notify and confirm process completion Email Process confirmation via email. Finance N/A | |
| Notify requestor of reason for rejection Email If the new customer is not accepted, the requestor will be notified. Finance N/A | |
| 5.13.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.9.1 - Partner function for account manager | |
| • 2.9.2 - Customer master data | |
| • 3.2.7 - Credit management groups | |
| A new account group will be configured and assigned to the existing Sold-To customer master Partner Determination Procedure for the account manager data. The sales Group will no longer be used for this data. | |
| For new customers with a low probability of a successful sale (opportunity or doubtful), the perspective customer account group 005 will be selected. The perspective customer does not require a credit check to be added into Customer Master Data. However, if a sale is successful, the account group will be updated, and a credit check completed prior to processing the purchase order. | |
| Should the review of payment terms require updates to customer master data this will be communicated to the master data team accordingly. | |
| 5.13.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.14. Level 3 Business Area – 02.09.02. Maintain Sales Master Data | |
| 5.14.1. Level 4 Process Description – 02.09.02. Maintain Sales Master Data | |
| This section describes the sales master data maintained in the JM CT system. | |
| The following sales master data is maintained: | |
| • Material master – sales views /* master data team */ | |
| • Product Exclusions /* master data team */ | |
| • Customer Material Information Record /* master data team */ | |
| • Pricing conditions – see 02.02.04. Perform pricing administration – above. | |
| • Output master data for: | |
| o Quotations | |
| o Sales orders | |
| o Invoices. | |
| These are standard master data transactions shown in the standard SAP menu below. | |
| Figure 34 – SAP Sales Master Data Maintenance Transactions | |
| Customer material information records capture information that is specific to customer-material combination such as material name, plant, delivery tolerance, etc. CMIR can be required for labels at point of production and at shipping. CMIR is not a mandatory field. | |
| Product exclusion is used to control which materials a specific cannot purchase. Material exclusion lists restrict a customer’s buying choices, and the customer cannot order excluded materials. | |
| 5.14.1.1. Level 4 Process Flows and Steps | |
| 02.09.02.01 Maintain Sales Master Data | |
| Figure 35 – Process Map 02.09.02.01 Maintain Sales Master Data | |
| Process Steps: | |
| 02.09.02.01 Maintain Sales Master Data | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Request New / Amended Customer Material Information Record Manual Customer Service identifies the need for a new or amended customer material information record. Customer Service N/A | |
| Maintain Customer Material Information Record SAP Creation or maintenance of customer material information record. Master Data VD51 | |
| Request New / Amended Exclusion Manual Customer Service identifies the need for a new or amended product exclusion Customer Service N/A | |
| Maintain Product Exclusion SAP Creation or maintenance of product exclusion. Master Data VB01 | |
| 5.14.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.4.7 - Reports to support sales processes | |
| • 2.9.1 - Partner function for account manager | |
| • 2.9.2 - Customer master data. | |
| Data maintenance will continue as in the current JM CT system. The Customer Material Information Record will remain available for use as required in the future. The only addition will be the use of Product Exclusion that permits the system to automatically deny the sale of certain items to specified customers. This is being adopted for Savannah as they restrict sales of products by customer; on occasion sales have inadvertently been made breach this rule. | |
| 5.14.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 5.15. Level 3 Business Area – 02.09.04 – Manage Customer Payment Terms | |
| 5.15.1. Level 4 Process Description – 02.09.04.01 Manage Customer Payment Terms | |
| Payment terms must be agreed in advance with customers. The default should be JM’s standard payment terms of not more than 30 days from date of invoice. Any deviations for new customers must be approved by the Sector Finance Director but deviations by more than 30 days require approval of Group Treasurer. | |
| Goods should not be delivered, or services provided, if there is no written agreement between the contracting parties on payment terms. | |
| JM CT Requirements: | |
| • Customer analysis to get improvements for Sales Process - credit management, incoterms, payment terms for example | |
| • Rationalize payment terms | |
| 5.15.1.1. Level 4 Process Flows and Steps | |
| 02.09.04.01 - Manage Customer Payment Terms | |
| Figure 36 – Process Map 02.09.04.01 – Manage Customer Payment Terms | |
| Process Steps: | |
| 02.09.04.01 Manage Customer Payment Terms | |
| L4 Process Step System / Manual Narrative Step owner SAP T-Code | |
| Request New / Amended Payment Term Manual Finance identifies the need for a new or amended payment term. Account Manager N/A | |
| Maintain Payment Terms SAP Creation or maintenance of sales terms of payment. IT Support OBB8 | |
| 5.15.1.2. To-be Changes | |
| The relevant scope items for this process are: | |
| • 2.4.6 - Migrate to STC template for consolidation sites | |
| • 2.9.2 - Customer master data | |
| JM CT currently have 217 payment terms that are relevant for Customers. These will be reviewed and rationalised during Realisation. It is understood that the ability to flex payment terms at Billing Plan line-item level will make some of the above redundant. | |
| 5.15.1.3. Site Specific Changes | |
| In addition, the following site-specific changes (Existing and New Consolidation sites) and business justification for variation in the process is specified: | |
| CT Sites Changes Business Justification | |
| None identified | |
| 6. Change Management: “To- Be’ Design Changes | |
| The business has requested for several changes to the way in which the STC process will be managed and executed in the future: | |
| Change Theme Change Statement | |
| Pricing validation Price lists will be stored in SAP with a report to highlight variance of actual from target | |
| Integration for forecasts and quotes with CRM and S&OP planning tool Integration of new CRM forecasts and quotes to SAP and SAP to S&OP forecasting tool | |
| Utilize billing plans Introduction of milestone billing plans and down payment processing | |
| Creation of customer statements Creation of a customer account statement covering all business requirement. | |
| Use of Dunning process Create and automatically distribute debt notifications (Dunning and forms) to chase payments | |
| Credit Approval Process Credit limit approval will be authorized through Lotus Notes workflow | |
| These changes were identified in HLD and do not provide an exhaustive list but were to provide indicative direction for the detailed design. | |
| To help deliver on these change themes, all aspects of the Operating Model wheel were considered through a series of workshops and the following changes have been identified. | |
| 7. Key Design Decisions | |
| The business has agreed to the following Key Outstanding Design Decisions as part of the new ways of working as it impacts STC to be managed and executed as part of the to-be design: | |
| No BAG Ref Theme Decisions | |
| 1 BAG0021 Master Data Management Customers will be mastered in SAP with the request and approval process managed via Lotus Notes across all sites. | |
| 2 BAG0029 Tax Integration A decision is required regarding the adoption on OneSource tax Engine for US tax solution. | |
| 4 BAG0038 Pricing validation Maintain the price list in SAP and report actual price variance from target pricing. | |
| 5 BAG0039 Customer statements Automate the creation of customer statements to encourage timely payments | |
| 8. Policies and Compliance | |
| The STC must comply with JM Policies set by Group. They can be found on My JM. Many of the policies dealing with ERP systems are codified in the ICFR, including Segregation of Duties, Proper Approvals, and Access Rights. Sites are also responsible for compliance with local Tax and Governmental Reporting requirements, which are typically supported by data from SAP. | |
| The following key policies have been identified as being impacted by the Concert design. | |
| No New / Existing Decisions | |
| 1 Existing None identified. | |
| 2 | |
| 9. Key Value Drivers | |
| The design has highlighted for L3 processes the key value drivers resulting in the process harmonization and improvement (the why), to meet the business value statements and KPIs as highlighted in the High-level design. | |
| L3 Reference Value Driver Description KPI Reference Name (KPI's) Benefits | |
| CT will establish a standardized, consolidated forecast, quotation, price, and order solution across all sites with increased automation/controls and direct integration to SAP to decrease manual activity, improve accuracy, and enable complete visibility to sales data. Operational Excellence Total cost to perform the sales-to-cash processes - | |
| CT will establish a standardized, consolidated approach to credit control across all sites with increased automation/controls to decrease manual activity for credit approval and checks, enable complete visibility to JM true customer exposure, and improve compliance. Credit Control Total cost to perform the customer credit processes - | |
| CT will establish a harmonized, consolidated solution with controls to customer payment terms and collections across all sites that will improve payment efficiency and collections to reduce working capital. Payment Terms and Collections Days sales outstanding £5.58m | |
| CT will establish an improved customer's experience by establishing and consolidating consistent and accurate master data and invoicing thereby enhancing visibility to customer sales data and product stock, reducing billing errors and rejected invoices, and improving forecasting. Customer Experience and Data CT Total Annual Sales - | |
| 10. Risk and Controls | |
| Leveraging SAP Standard functionality can prove to be beneficial when controling and managing risk within workstreams. The STC workstream will need to implement and thereafter operate a range of controls that are Automated, Semi-Automated or Manual. | |
| The following is an overview of the controls that will be introduced as new or continue to operate within CT: | |
| STC Control Type Summary | |
| Automated Automated – Access Automated – SOD Manual Semi-automated Total | |
| 38 8 14 14 6 80 | |
| STC Control Risk Rating Summary | |
| Critical High Medium Low Total | |
| 13 58 6 3 80 | |
| STC Control Current State Summary | |
| Not Operating Operating Partially Operating Total | |
| 27 40 13 80 | |
| Refer to the Risk and Control Matrix for detailed view of controls that will be applied - Link | |
| 11. Roles and Skills | |
| Within the CT design a number of roles have been designed to support the new ways of working. These include changes to exiting roles by updating the roles and authorisation objects or adding new system roles. | |
| 11.1. Business Role Description | |
| Business Role analysis | |
| 1. Analysis is based on only composite roles, excluding display only composite role, and excluding direct assignment of single roles. | |
| 2. Global roles indicated below are our grouping of existing composite roles across company codes/purchasing organisation/plants for ease of reference. | |
| 3. Please refer file- STC Business Role Analysis.xlsb for mapping the existing composite roles to the grouping, as referred in point 2. | |
| Business Role SAP T-Code SAP T-Code Description | |
| Account Receivable F-29 Post Customer Down Payment | |
| Account Receivable VA02 Change Sales Order | |
| Account Receivable F-28 Apply Payment | |
| Account Receivable FB70 Credit with Offset to Balance Sheet | |
| Account Receivable FBL5N Customer Line Items | |
| Billing Clerk VF01 Create Billing Document | |
| Billing Clerk VF04 Maintain Billing Due List | |
| Billing Clerk V23 Sales Documents Blocked for Billing | |
| Billing Clerk VF02 Change Billing Document | |
| Billing Clerk VFX3 Release Billing Documents | |
| Billing Clerk VF31 Output from Billing Documents | |
| Billing Clerk VF02 Change Billing Document | |
| Billing Clerk VF03 Display Billing Document | |
| Billing Clerk VA03 Display Sales Order | |
| Billing Clerk VF05 List Billing Documents | |
| Credit Controller VKM4 SD Documents | |
| Credit Controller VA01 Create Sales Order | |
| Credit Controller FD32 Change Customer Credit Management | |
| Credit Controller VKM1 Blocked Sales Documents | |
| Credit Controller VKM2 Released Sales Documents | |
| Credit Controller VKM3 Sales Documents | |
| Credit Controller VKM5 Deliveries | |
| Customer Service VA01 Create Sales Order | |
| Customer Service VA02 Change Sales Order | |
| Customer Service VA21 Create Quotation | |
| Customer Service VA22 Change Quotation | |
| Customer Service VF04 Maintain Billing Due List | |
| Customer Service ZSOMS #N/A | |
| Customer Service VFX3 List Blocked Billing Documents | |
| Customer Service VA06 Sales Order Monitor | |
| Customer Service V.14 Sales Orders Blocked for Delivery | |
| Customer Service V.23 Release Orders for Billing | |
| Customer Service FD32 Change Customer Credit Management | |
| Customer Service VL02N Return Delivery | |
| Customer Service VF01 Credit Return Invoice | |
| Customer Service XD03 Display Customer (Centrally) | |
| Customer Service SOST SAP connect Send Requests | |
| Customer Service CJ20N Project Builder | |
| Customer Service VA23 Display Quotation | |
| Customer Service VA03 Display Sales Order | |
| Customer Service VA05 List Sales Documents | |
| Finance VF04 Maintain Billing Due List | |
| Finance VF02 Change Billing Document | |
| Finance VFX3 List Blocked Billing Documents | |
| Finance FEBAN Bank statement postprocessing | |
| Finance F-28 Clear AR | |
| Finance F.13 Clear AR | |
| Finance FBL3N G/L Account Line Items | |
| Finance FB03 Display Document | |
| Finance ZAR_OI_ANALYSIS #N/A | |
| Finance F-04 Post with Clearing | |
| Finance FD03 Display Customer (Accounting) | |
| Finance F.27 Periodic Account Statements | |
| Finance F.61 Correspondence: Print Requests | |
| Finance F150 Dunning Run | |
| Finance V.23 Release Orders for Billing | |
| Finance ZM30_OB52 Close Customer Accounts | |
| IT Support OBB8 C FI Maintain Table T052 | |
| Logistics VL02n Change Outbound Delivery | |
| Logistics VL01N Create Outbound Dlv. with Order Ref. | |
| Logistics VL10 Edit User-specific Delivery List | |
| Logistics ZS12 #N/A | |
| Logistics VL10C Order Items Due for Delivery | |
| Logistics VL06O Outbound Delivery Monitor | |
| Logistics MIGO Goods Movement | |
| Market Manager VK13 Display Condition | |
| Master Data FD32 Change Customer Credit Management | |
| Master Data VK11 Create Condition | |
| Master Data VK12 Change Condition | |
| Master Data XD01 Create Customer (Centrally) | |
| Master Data XD02 Change Customer (Centrally) | |
| Master Data VD51 Maintain Customer-Material Info | |
| Master Data VB01 Create Material Listing/Exclusion | |
| Project Account VA01 Create Sales Order with Project | |
| Project Account VA02 Change Sales Order | |
| Project Manager CJ20N Project Builder | |
| Legends Description | |
| Business Role EY’s grouping of different business | |
| EY Global Role EY’s company code and/or site agnostic grouping of existing composite role(s) | |
| Distinct User Unique number of users that currently hold access to the composite role(s) | |
| Comments Brief description of the access the composite role provides | |
| Tcodes (required by Business Role) Tick mark means Composite role provides access | |
| SoD EY’s indicator of whether the existing composite role(s) contain segregation of duties concern | |
| SA EY’s indicator of whether the existing composite role(s) contains sensitive access from a financial reporting perspective | |
| 1. Business Role Account Receivable | |
| a. As per BPD, individuals with business role ‘Account Receivable’ require access to 5 specific T-codes – | |
| i. F-29 Post Customer Down Payment | |
| ii. FBL5N Customer Line Items | |
| iii. AL11 Display SAP Directories | |
| iv. FLB2 Import Lockbox File | |
| v. FLB1 Postprocessing Lockbox Data | |
| b. Through analysis of the existing SAP composite roles, we noted that 9 such unique SAP composite roles were providing access to one or more of the aforementioned T-codes, though none of these 9 unique composite roles provide access to all 5 Account Receivable T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Account Receivable SoD SA | |
| AL11 FBL5N F-29 FLB2 FLB1 | |
| Account Receivable Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Customer Service, Credit Controller, Finance, Logistics, Manufacturing, and Market Manager Tcodes | |
| Account Receivable Y:EC_CCXX_FIN:FINANCE_ACCT1 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Customer Service, Finance, Logistics, Manufacturing, and Market Manager Tcodes | |
| Account Receivable Y:EC_CCXX_FIN:FINANCE_ACCT2 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y:EC_CCXX_FIN:FINANCE_ACCT3 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y:EC_CCXX_FIN:FINANCE_CONTROL 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to one of the Tcodes relevant to all other PM Business Roles | |
| Account Receivable Y_FI_CCXX_ACCOUNTS_RECEIVABLE 1 1. This role is currently implemented for Company Codes IN10 and DE36 only | |
| 2. Additionally, this role also provides access to Finance and Logistics | |
| Account Receivable Y_FI_CCXX_ACCOUNTS_RECEIVABLE 2 1. This role is currently implemented for Company Codes US32 and GB30 only | |
| 2. Additionally, this role also provides access to Finance and Logistics | |
| Account Receivable Y_FI_CCXX_ACCOUNTS_RECEIVABLE 3 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Account Receivable Y_FI_CCXX_ACCOUNTS_RECEIVABLE 4 1. This role is currently implemented for Company Codes US38 and DE35 only | |
| 2. Additionally, this role also provides access to Finance and Logistics | |
| Account Receivable Y_FI_CCXX_PAYMENT_RUNS 1 1. This role is currently implemented for Company Code IN10 only | |
| Account Receivable Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 13 1. This role is currently implemented for Company Codes IN20 and DE36 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 38 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 39 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 50 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 57 1. This role is currently implemented for Company Code DE35 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 84 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Account Receivable Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 137 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Change(s) Required – | |
| 1. Add 2/5 missing Account Receivable Tcodes to existing composite role(s) - None of the 9 unique composite roles provide access to 2/5 Account Receivable Tcodes (FLB2,FLB1) | |
| 2. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 3. Ensure that users across all sites with Account Receivable responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 4. As these are marked as Sensitive Access; ensure that no users outside of those with Account Receivable responsibilities are assigned these SAP roles. | |
| 5. 2/9 unique composite roles are marked as SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 6. Ensure that none of these SAP roles are intended for business roles that do not have Account Receivable responsibilities. | |
| 2. Business Role Billing Administrator | |
| a. As per BPD, individuals with business role ‘Billing Administrator’ require access to 5 specific T-codes – | |
| i. VF01 Create Billing Document | |
| ii. VF04 Maintain Billing Due List | |
| iii. V23 Sales Documents Blocked for Billing | |
| iv. VF02 Change Billing Document | |
| v. VF31 Output from Billing Documents | |
| b. Through analysis of the existing SAP composite roles, we noted that 11 such unique SAP composite roles were providing access to one or more of the aforementioned T-codes, though none of these 11 unique composite roles provide access to all 5 Billing Administrator T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Distinct Users Billing Administrator SoD SA | |
| VF01 VF02 VF04 VF31 | |
| Billing Administrator Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Billing Administrator Y_MM_CCXX_LOGISTIC_TEAM_LEADER 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Billing Administrator Y_MM_CCXX_OPERATIONS_EXP_ADMTR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Billing Administrator Y_MM_CCXX_STOCK_TRANSPORT_OFFR 1 1. This role is currently implemented for Company Code IN20 only | |
| 2. Additionally, this role also provides access to Finance, Logistics and Manufact.Tcodes | |
| Billing Administrator Y_MM_CCXX_STOCK_TRANSPORT_OFFR 2 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Finance, Logistics and Manufact.Tcodes | |
| Billing Administrator Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Manufact., Market Manager and Master Data Team Tcodes | |
| Billing Administrator Y_SD_CCXX_EXPORT_OPERATOR 3 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Customer Service, Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_EXPORT_PROCESS_PLXX 2 1. This role is currently implemented for Company Code IN10, sales organisation IN18 only | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_SO_SOXX_BILLING_EXEC 1 1. This role is currently implemented for Company Code IN20, sales organisation IN20 only | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_SO_SOXX_BILLING_EXEC 4 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_SO_SOXX_BILLING_OPR 1 1. This role is currently implemented for | |
| a. Company Code GB30, sales organisation GB51 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_SO_SOXX_BILLING_OPR 2 1. This role is currently implemented for Company Code US32, sales organisation US32 only | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_SO_SOXX_BILLING_OPR 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_SO_SOXX_BILLING_OPR 5 1. This role is currently implemented for Company Code SE33, sales organisation SE33 only | |
| 2. Additionally, this role also provides access to Finance and Logistics Tcodes | |
| Billing Administrator Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Billing Administrator Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 13 1. This role is currently implemented for Company Codes IN20 and DE36 only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Billing Administrator Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 38 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Billing Administrator Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 39 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Fince, Logistics, Manufact.and Market Manager Tcodes | |
| Billing Administrator Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 50 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Billing Administrator Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 57 1. This role is currently implemented for Company Code DE35 only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Billing Administrator Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 84 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Billing Administrator Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 137 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Change(s) Required – | |
| 1. Add 1/5 missing Billing Administrator Tcodes to existing composite role(s) - None of the 11 unique composite roles provide access to 1/5 Billing Administrator Tcode (VA23) | |
| 2. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 3. Ensure that users across all sites with Billing Administrator responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 4. As these are marked as Sensitive Access; ensure that no users outside of those with Billing Administrator responsibilities are assigned these SAP roles. | |
| 5. 2/11 unique composite roles are marked as SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 6. Ensure that none of these SAP roles are intended for business roles that do not have Billing Administrator responsibilities. | |
| 3. Business Role Commercial | |
| a. As per BPD, individuals with business role ‘Commercial’ require access to 1 specific T-code – VA21 Create Quotation | |
| b. Through analysis of the existing SAP composite roles, we noted that 8 such unique SAP composite roles were providing access to the only T-code. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Commercial SoD SA | |
| VA21 | |
| Commercial Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to one of the Tcodes relevant to all other PM Business Roles | |
| Commercial Y_MM_CCXX_OPERATIONS_EXP_ADMTR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Credit Controller, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Commercial Y_MM_CCXX_OPERATIONS_TEAM_LEAD 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Commercial Y_PP_CCXX_PRODUCTION_PLANNER 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Market Manager, Logistics, Master Data Team and Manufact. Tcodes | |
| Commercial Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to one of the Tcodes relevant to all other PM Business Roles | |
| Commercial Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Commercial Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Billing Administrator, Credit Controller, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Commercial Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Commercial Y_SD_CCXX_SO_SOXX_FORCS"ES 3 1. This role is currently implemented for Company Code DE35, sales organisation DE35 only | |
| 2. Additionally, this role also provides access to Customer Service and Master Data Team Tcodes | |
| Commercial Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 5 1. This role is currently implemented for | |
| a. Company Code SE33, sales organisation SE33 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Commercial Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 6 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Change(s) Required – | |
| 1. Align role ‘CUST_SRV_REP’ so that it is consistent with the same role for other company code (including missing authorisation). | |
| 2. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 3. Ensure that users across all sites with Commercial responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 4. As these are marked as Sensitive Access; ensure that no users outside of those with Commercial responsibilities are assigned these SAP roles. | |
| 5. 2/8 unique composite roles are marked as SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 6. Ensure that none of these SAP roles are intended for business roles that do not have Commercial responsibilities. | |
| 4. Business Role Credit Controller | |
| a. As per BPD, individuals with business role ‘Credit Controller’ require access to 2 specific T-codes – | |
| i. VKM4 SD Documents | |
| ii. VA01 Create Sales Order | |
| b. Through analysis of the existing SAP composite roles, we noted that 11 such unique SAP composite roles were providing access to one or more of the aforementioned T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Credit Controller SoD SA | |
| VKM4 VA01 | |
| Credit Controller Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Credit Controller Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Commercial, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_FI_CCXX_CREDIT_MANAGEMENT 1 1. This role is currently implemented for Company Code DE35 only | |
| Credit Controller Y_FI_CCXX_CREDIT_MANAGEMENT 2 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Customer Service and Master Data Team Tcodes | |
| Credit Controller Y_FI_CCXX_CREDIT_MANAGEMENT 3 1. This role is currently implemented for Company Code US38 only | |
| Credit Controller Y_FI_CCXX_CREDIT_MANAGEMENT 7 1. This role is currently implemented for Company Code US32 only | |
| Credit Controller Y_FI_CCXX_CREDIT_MANAGEMENT 8 1. This role is currently implemented for Company Code GB30 only | |
| Credit Controller Y_FI_CCXX_FINANCIAL_CRITICAL 3 1. This role is currently implemented for Company Codes US38 and IN10 | |
| Credit Controller Y_FI_CCXX_FINANCIAL_CRITICAL 4 1. This role is currently implemented for Company Codes GB30 and US32 | |
| Credit Controller Y_FI_CCXX_FINANCIAL_CRITICAL 5 1. This role is currently implemented for Company Codes DE35 and SE33 | |
| Credit Controller Y_MM_CCXX_OPERATIONS_EXP_ADMTR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Credit Controller Y_MM_CCXX_OPERATIONS_TEAM_LEAD 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Credit Controller Y_PP_CCXX_PRODUCTION_PLANNER 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Market Manager, Logistics, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Manufact., Market Manager and Master Data Team Tcodes | |
| Credit Controller Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 1 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 5 1. This role is currently implemented for | |
| a. Company Code SE33, sales organisation SE33 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 6 1. This role is currently implemented for Company Code IN10, sales organisation IN10 | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Credit Controller Y_ZZ_ZALL_GLOBAL_MASTER_DATA 5 1. This role is currently implemented for all Company Codes | |
| 2. Additionally, this role also provides access to Customer Service, Market Manager and Master Data Team Tcodes | |
| Change(s) Required – | |
| 1. Align role ‘CREDIT_MANAGEMENT’ for so that it is consistent with the same role for other company code. | |
| 2. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 3. Ensure that users across all sites with Credit Controller responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 4. As these are marked as Sensitive Access; ensure that no users outside of those with Credit Controller responsibilities are assigned these SAP roles. | |
| 5. 2/11 unique composite roles are marked as SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 6. Ensure that none of these SAP roles are intended for business roles that do not have Credit Controller responsibilities. | |
| 5. Business Role IT Support | |
| a. As per BPD, individuals with business role ‘IT Support’ require access to 1 specific T-code – OBB8 for C FI Maintain Table T052 | |
| b. Through analysis of the existing SAP composite roles, we noted that none of the existing SAP composite roles were providing access to the mentioned T-code above. | |
| Change(s) Required – | |
| 1. Add Tcode OBB8 to one of the existing SAP composite roles per company code or by creating independent role covering all company codes. | |
| 2. Ensure that users across all sites with IT Support responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 3. Ensure that no users outside of those with IT Support responsibilities are assigned with SAP roles providing access to Tcode OBB8 and ensure that there is no SoD by addition of the Tcode (OBB8) to any of the existing SAP composite role. | |
| 6. Business Role Project Administrator | |
| a. As per BPD, individuals with business role ‘Project Administrator’ require access to 1 specific T-code – CJ20N for Project Builder | |
| b. Through analysis of the existing SAP composite roles, we noted that none of the existing SAP composite roles were providing access to the mentioned T-code above. | |
| Change(s) Required – | |
| 1. Add Tcode CJ20N to one of the existing SAP composite roles per company code or by creating independent role covering all company codes. | |
| 2. Ensure that users across all sites with Project Administrator responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 3. Ensure that no users outside of those with Project Administrator responsibilities are assigned with SAP roles providing access to Tcode CJ20N and ensure that there is no SoD by addition of the Tcode (CJ20N) to any of the existing SAP composite role. | |
| 7. Business Role Master Data | |
| a. As per BPD, individuals with business role ‘Master Data’ require access to 7 specific T-codes – | |
| i. FD32 Change Customer Credit Management | |
| ii. VK11 Create Condition | |
| iii. VK12 Change Condition | |
| iv. XD01 Create Customer (Centrally) | |
| v. XD02 Change Customer (Centrally) | |
| vi. VD51 Maintain Customer-Material Info | |
| vii. VB01 Create Material Listing/Exclusion | |
| b. Through analysis of the existing SAP composite roles, we noted that 11 such unique SAP composite roles were providing access to one or more of the aforementioned T-codes, though none of these 11 unique composite roles provide access to all 7 Master Data T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Master Data Team SoD SA | |
| FD32 VK11 VK12 XD01 XD02 VD51 | |
| Master Data Team Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Credit Controller, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Master Data Team Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Billing Administrator, Commercial, Credit Controller, Customer Service, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Master Data Team Y_BC_ZALL_SAP_LOCAL_SUPPORT 1 1. This role is currently implemented for all Company Codes | |
| 2. Additionally, this role also provides access to Customer Service, Finance and Logistics Tcodes | |
| Master Data Team Y_FI_CCXX_BUSINESS_ACCOUNTANT 2 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Customer Service, Finance and Logistics Tcodes | |
| Master Data Team Y_FI_CCXX_CREDIT_MANAGEMENT 2 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Customer Service and Credit Controller Tcodes | |
| Master Data Team Y_PP_CCXX_PRODUCTION_PLANNER 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Tcode(s) to all other STC Business Roles | |
| Master Data Team Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Tcode(s) to all other STC Business Roles | |
| Master Data Team Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, Sales Organisation GB51 only | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Credit Controller, Finance, Logistics, Manufact. and Market Manager Tcodes | |
| Master Data Team Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Tcode(s) to all other STC Business Roles | |
| Master Data Team Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, Sales Organisation GB31 only | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Credit Controller, Finance, Logistics, Manufact. and Market Manager Tcodes | |
| Master Data Team Y_SD_CCXX_SO_SOXX_FORCS"ES 3 1. This role is currently implemented for Company Code DE35, Sales Organisation DE35 only | |
| 2. Additionally, this role also provides access to Commercial and Customer Service Tcodes | |
| Master Data Team Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 5 1. This role is currently implemented for | |
| a. Company Code SE33, sales organisation SE33 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Logistics, Market Manager, Master Data Team and Commercial Tcodes | |
| Master Data Team Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 6 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Commercial, Customer Service, Credit Controller, Logistics, Market Manager and Manufact. Tcodes | |
| Master Data Team Y_ZZ_ZALL_GLOBAL_MASTER_DATA 5 1. This role is currently implemented for all Company Codes | |
| 2. Additionally, this role also provides access to Customer Service, Market Manager and Credit Controller Tcodes | |
| Change(s) Required – | |
| 1. Align role ‘CUST_SRV_REP’ so that it is consistent with the same role for other company code (including missing authorisation). | |
| 2. Add 1/7 missing Master Data Tcodes to existing composite role(s) - None of the 11 unique composite roles provide access to 1/7 Master Data Tcode (VB01) | |
| 3. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 4. Ensure that users across all sites with Master Data responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 5. As these are marked as Sensitive Access; ensure that no users outside of those with Master Data responsibilities are assigned these SAP roles. | |
| 6. 3/11 unique composite roles are marked as SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 7. Ensure that none of these SAP roles are intended for business roles that do not have Master Data responsibilities. | |
| 8. Business Role Market Manager | |
| a. As per BPD, individuals with business role ‘Market Manager’ require access to 1 specific T-code – VK13 for Display Condition | |
| b. Through analysis of the existing SAP composite roles, we noted that 13 such unique SAP composite roles were providing access to the only T-code. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Market Manager SoD SA | |
| VK13 | |
| Market Manager Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics, Master Data Team and Manufact. Tcodes | |
| Market Manager Y:EC_CCXX_FIN:FINANCE_ACCT1 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y:EC_CCXX_FIN:FINANCE_ACCT2 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y:EC_CCXX_FIN:FINANCE_ACCT3 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y:EC_CCXX_FIN:FINANCE_CONTROL 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Tcodes corresponding to all the other STC Business Role Tcodes | |
| Market Manager Y_BC_ZALL_SAP_LOCAL_SUPPORT 1 1. This role is currently implemented for all Company Codes | |
| 2. Additionally, this role also provides access to Master Data Team Tcodes | |
| Market Manager Y_PP_CCXX_PRODUCTION_PLANNER 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Logistics, Master Data Team and Manufact. Tcodes | |
| Market Manager Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Manufact. Tcodes | |
| Market Manager Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Manufact. Tcodes | |
| Market Manager Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Tcodes corresponding to all the other STC Business Role Tcodes | |
| Market Manager Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Manufact. Tcodes | |
| Market Manager Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 5 1. This role is currently implemented for | |
| a. Company Code SE33, sales organisation SE33 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Logistics, Master Data Team and Manufact. Tcodes | |
| Market Manager Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 6 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Logistics, Master Data Team and Manufact. Tcodes | |
| Market Manager Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 13 1. This role is currently implemented for Company Codes IN20 and DE36 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 38 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 39 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 50 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 57 1. This role is currently implemented for Company Code DE35 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 84 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 137 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Manufact. Tcodes | |
| Market Manager Y_ZZ_ZALL_GLOBAL_MASTER_DATA 5 1. This role is currently implemented for all Company Codes | |
| 2. Additionally, this role also provides access to Credit Controller, Customer Service, Market Manager and Finance Tcodes | |
| Change(s) Required – | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Market Manager responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 3. As these are marked as Sensitive Access; ensure that no users outside of those with Market Manager responsibilities are assigned these SAP roles. | |
| 4. 3/13 unique composite roles are marked as SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 5. Ensure that none of these SAP roles are intended for business roles that do not have Market Manager responsibilities. | |
| 9. Business Role Manufact. | |
| a. As per BPD, individuals with business role ‘Manufact.’ require access to 2 specific T-codes – | |
| i. VA01 Create Sales Order | |
| ii. MIGO Goods Movement | |
| b. Through analysis of the existing SAP composite roles, we noted that 41 such unique SAP composite roles were providing access to either of the aforementioned T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Manufact. SoD SA | |
| MIGO VA01 | |
| Manufact. Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y:EC_CCXX_FIN:FINANCE_ACCT1 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y:EC_CCXX_FIN:FINANCE_ACCT2 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y:EC_CCXX_FIN:FINANCE_ACCT3 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y:EC_CCXX_FIN:FINANCE_CONTROL 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y:EC_CCXX_INV:PURC_REQS_CREA 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y:EC_CCXX_PUR:PROC_APPRV 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y:EC_CCXX_PUR:PROC_CREATE 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y:EC_CCXX_QC:PREPARER 3 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Account Receivable, Billing Administrator, Commercial, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y_MM_CCXX_BONDED_WAREHOUSE_OPR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_GETTER_TABLETS_MGMT 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_HANSONS_OPR_PLXX 1 1. This role is currently implemented for Company Code GB30, plant GB26 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_LOGISTIC_TEAM_LEADER 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance and Logistics Tcodes | |
| Manufact. Y_MM_CCXX_LOGISTICS_MANAGER 6 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_LOGISTICS_OPERATOR 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_MANUFACTURING_ACCTNT 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_OPERATIONS_EXP_ADMTR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Credit Controller, Customer Service, Finance and Logistics Tcodes | |
| Manufact. Y_MM_CCXX_OPERATIONS_TEAM_LEAD 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service and Logistics Tcodes | |
| Manufact. Y_MM_CCXX_PHARMORPHIX_OPR_PLXX 1 1. This role is currently implemented for Company Code GB30, plant GB02 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_PO_PUXX_PURCH_CLERK 1 1. This role is currently implemented for Company Code DE35, purchase organisation DE35 only | |
| 2. Additionally, this role also provides access to Customer Service and Logistics Tcodes | |
| Manufact. Y_MM_CCXX_POTTERS_OPR_ZVAR 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_STD_GDS_MVT_OPR_PLXX 12 1. This role is currently implemented for Company Code SE33, plant SE01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 1 1. This role is currently implemented for | |
| a. Company Code GB30, plant GB05 | |
| b. Company Code SE33, plant SE01 | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 2 1. This role is currently implemented for Company Code IN10, all plants only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 4 1. This role is currently implemented for | |
| a. Company Code GB30, plant GB02 | |
| b. Company Code DE35, all plants | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 7 1. This role is currently implemented for Company Code GB30, plant GB01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_STOCK_TRANSPORT_OFFR 1 1. This role is currently implemented for Company Code IN20 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Finance and Logistics Tcodes | |
| Manufact. Y_MM_CCXX_STOCK_TRANSPORT_OFFR 2 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Finance and Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 1 1. This role is currently implemented for | |
| a. Company Code IN10, plant IN18 | |
| b. Company Code IN20, all plants | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 3 1. This role is currently implemented for Company Code GB30, plant GB01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 4 1. This role is currently implemented for Company Code GB30, plant GB05 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 5 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 7 1. This role is currently implemented for Company Code GB30, plant GB02 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 9 1. This role is currently implemented for Company Code US38, plant US28 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 15 1. This role is currently implemented for Company Code SE33, plant SE01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 20 1. This role is currently implemented for Company Code DE35, plant DE02 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 22 1. This role is currently implemented for Company Code DE35, plant DE01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WAREHOUSE_OPR_PLXX 24 1. This role is currently implemented for Company Code US38, plant US26 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WRITE_ON&OFF_ZALL 1 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_MM_CCXX_WRITE_ON&OFF_ZVAR 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PM_CCXX_MAINT_MANAGER_PLXX 2 1. This role is currently implemented for Company Code IN10, plant IN11 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PM_CCXX_MAINT_OPERATOR_PLXX 3 1. This role is currently implemented for Company Code IN10, plant IN11 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PM_CCXX_MAINT_OPERATOR_PLXX 5 1. This role is currently implemented for Company Code DE35, plant DE02 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PM_CCXX_MAINT_OPERATOR_PLXX 8 1. This role is currently implemented for Company Code DE35, plant DE01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PM_CCXX_MAINT_PLANNER_PLXX 23 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE01 | |
| b. Company Code DE35, sales organisation DE02 | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_MANAGER_PLXX 7 1. This role is currently implemented for Company Code US38, sales organisation US26 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_MANAGER_PLXX 9 1. This role is currently implemented for Company Code IN10, sales organisation IN16 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_MANAGER_PLXX 12 1. This role is currently implemented for Company Code GB30, sales organisation GB08 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_OPERATOR_PLXX 4 1. This role is currently implemented for Company Code SE33, sales organisation SE01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_OPERATOR_PLXX 5 1. This role is currently implemented for Company Code DE35, sales organisation DE02 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_OPERATOR_PLXX 8 1. This role is currently implemented for Company Code DE35, sales organisation DE01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_OPERATOR_PLXX 9 1. This role is currently implemented for | |
| a. Company Code IN10, sales organisation IN16 | |
| b. Company Code US38, sales organisation US26 | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_OPERATOR_PLXX 63 1. This role is currently implemented for Company Code GB30, sales organisation GB08 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_PLANNER_PLXX 6 1. This role is currently implemented for Company Code GB30, sales organisation GB08 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODTN_SUPRVISR_PLXX 3 1. This role is currently implemented for Company Code SE33, sales organisation SE01 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_PP_CCXX_PRODUCTION_PLANNER 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Tcodes corresponding to all the other STC Business Role Tcodes | |
| Manufact. Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y_SD_CCXX_SO_SOXX_DELIVERY_OPR 2 1. This role is currently implemented for Company Code US32, sales organisation US32 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Manufact. Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 1 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Credit Controller and Customer Service Tcodes | |
| Manufact. Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 5 1. This role is currently implemented for | |
| a. Company Code SE33, sales organisation SE33 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 6 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Logistics, Master Data Team and Market Manager Tcodes | |
| Manufact. Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 13 1. This role is currently implemented for Company Codes IN20 and DE36 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 38 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 39 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 50 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 57 1. This role is currently implemented for Company Code DE35 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 84 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Manufact. Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 137 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Logistics and Market Manager Tcodes | |
| Change(s) Required – | |
| 1. Align role ‘CUST_SRV_REP’ so that it is consistent with the same role for other company code (including missing authorisation). | |
| 2. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 3. Ensure that users across all sites with Manufact responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 4. As these are marked as Sensitive Access; ensure that no users outside of those with Manufact responsibilities are assigned these SAP roles. | |
| 5. 15/41 unique Composite roles are marked for SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 6. Ensure that none of these SAP roles are intended for business roles that do not have Manufact responsibilities. | |
| 10. Business Role Customer Service | |
| a. As per BPD, individuals with business role ‘Customer Service’ require access to 14 specific T-codes – | |
| i. VA02 Change Sales Order | |
| ii. VA21 Create Quotation | |
| iii. VA22 Change Quotation | |
| iv. VA01 Create Sales Order | |
| v. V_RA Backorder Processing: Selection List | |
| vi. V_V2 Updating Sales Documents by Material | |
| vii. ZSOMS #N/A | |
| viii. VA06 Sales Order Monitor | |
| ix. V.14 Sales Orders Blocked for Delivery | |
| x. V.23 Release Orders for Billing | |
| xi. FD32 Change Customer Credit Management | |
| xii. XD03 Display Customer (Centrally) | |
| xiii. SOST SAP connect Send Requests | |
| xiv. CJ20N Project Builder | |
| b. Through analysis of the existing SAP composite roles, we noted that 21 such unique SAP composite were providing access to one or more of the aforementioned T-codes, though none of these 21 composite roles provide access to all 14 Customer Service T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Customer Service SoD SA | |
| VA02 VA22 VA21 VA01 FD32 XD03 SOST | |
| Customer Service Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Credit Controller, Finance, Logistics, Manufact., Master Data Team and Market Manager Tcodes | |
| Customer Service Y:EC_CCXX_FIN:FINANCE_ACCT1 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y:EC_CCXX_FIN:FINANCE_ACCT2 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y:EC_CCXX_FIN:FINANCE_ACCT3 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y:EC_CCXX_FIN:FINANCE_CONTROL 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to one of the Tcodes relevant to all other PM Business Roles | |
| Customer Service Y_FI_CCXX_BUSINESS_ACCOUNTANT 2 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Finance, Logistics and Master Data Team Tcodes | |
| Customer Service Y_FI_CCXX_CREDIT_MANAGEMENT 2 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Credit Controller and Master Data Team Tcodes | |
| Customer Service Y_MM_CCXX_LOGISTIC_TEAM_LEADER 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Finance, Logistics and Manufact. Tcodes | |
| Customer Service Y_MM_CCXX_OPERATIONS_EXP_ADMTR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Credit Controller, Finance, Logistics and Manufact. Tcodes | |
| Customer Service Y_MM_CCXX_OPERATIONS_TEAM_LEAD 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Logistics and Manufact. Tcodes | |
| Customer Service Y_MM_CCXX_PO_PUXX_PURCH_CLERK 1 1. This role is currently implemented for Company Code DE35, purchasing organisation DE35 only | |
| 2. Additionally, this role also provides access to Logistics and Manufact. Tcodes | |
| Customer Service Y_PP_CCXX_PRODUCTION_PLANNER 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Customer Service Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Billing Administrator, Finance, Logistics, Manufact., Market Manager and Master Data Team Tcodes | |
| Customer Service Y_SD_CCXX_EXPORT_OPERATOR 3 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Finance and Logistics Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Finance, Logistics, Market Manager, Master Data Team and Man | |
| Customer Service Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Billing Administrator, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Credit Controller, Commercial, Finance, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_DELIVRY_PLXX 5 1. This role is currently implemented for Company Code US38, plant US26 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_DELIVRY_PLXX 7 1. This role is currently implemented for Company Code US38, plant US28 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_FORCS"ES 3 1. This role is currently implemented for Company Code DE35, sales organisation DE35 only | |
| 2. Additionally, this role also provides access to Commercial and Master Data Team Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 1 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Credit Controller and Manufact. Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 5 1. This role is currently implemented for | |
| a. Company Code SE33, sales organisation SE33 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Customer Service Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 6 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Credit Controller, Commercial, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Customer Service Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 13 1. This role is currently implemented for Company Codes IN20 and DE36 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 38 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 39 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 50 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 57 1. This role is currently implemented for Company Code DE35 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 84 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 137 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Finance, Logistics, Manufact.and Market Manager Tcodes | |
| Customer Service Y_ZZ_ZALL_GLOBAL_MASTER_DATA 5 1. This role is currently implemented for all Company Codes | |
| 2. Additionally, this role also provides access to Credit Controller, Market Manager and Master Data Team Tcodes | |
| Change(s) Required – | |
| 1. Add 7/14 missing ‘Customer Service’ Tcodes to existing composite role(s) - None of the 14 unique composite roles provide access to 7/14 ‘Customer Service’ Tcodes (V_RA,V_V2,ZSOMS,V.14,V.23,VA06,CJ20N) | |
| 1. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 2. Ensure that users across all sites with Customer Service responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 3. As these are marked as Sensitive Access; ensure that no users outside of those with Customer Service responsibilities are assigned these SAP roles. | |
| 4. 5/14 unique Composite roles are marked for SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 5. Ensure that none of these SAP roles are intended for business roles that do not have Customer Service responsibilities. | |
| 11. Business Role Finance | |
| a. As per BPD, individuals with business role ‘Finance’ require access to 14 specific T-codes – | |
| i. VF04 Maintain Billing Due List | |
| ii. VF02 Change Billing Document | |
| iii. VFX3 List Blocked Billing Documents | |
| iv. FEBAN Bank statement postprocessing | |
| v. FBL3N G/L Account Line Items | |
| vi. FB03 Display Document | |
| vii. ZAR_OI_ANALYSIS #N/A | |
| viii. F-04 Post with Clearing | |
| ix. FD03 Display Customer (Accounting) | |
| x. F.27 Periodic Account Statements | |
| xi. F.61 Correspondence: Print Requests | |
| xii. FBL5N Customer Line Items | |
| xiii. F150 Dunning Run | |
| xiv. V.23 Release Orders for Billing | |
| b. Through analysis of the existing SAP composite roles, we noted that 24 such unique SAP composite were providing access to one or more of the aforementioned T-codes, though none of these 24 composite roles provide access to all 14 Finance T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Finance SoD SA | |
| VF02 VF04 VFX3 FEBAN FBL3N FB03 ZAR_OI_ANALYSIS F-04 F.27 FD03 FBL5N | |
| Finance Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y:EC_CCXX_FIN:FINANCE_ACCT1 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y:EC_CCXX_FIN:FINANCE_ACCT2 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y:EC_CCXX_FIN:FINANCE_ACCT3 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y:EC_CCXX_FIN:FINANCE_CONTROL 1 1. This role is currently implemented for Company Codes IN10 and DE36 | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Manufact., Market Manager and Logistics Tcodes | |
| Finance Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Codes IN10 and DE36 | |
| 2. Additionally, this role also provides access to Tcodes relevant to all other STC Business Roles | |
| Finance Y_FI_CCXX_ACCOUNTS_RECEIVABLE 1 1. This role is currently implemented for Company Codes IN10 and DE36 | |
| 2. Additionally, this role also provides access to Account Receivable and Logistics Tcodes | |
| Finance Y_FI_CCXX_ACCOUNTS_RECEIVABLE 2 1. This role is currently implemented for Company Codes GB30 and US32 | |
| 2. Additionally, this role also provides access to Account Receivable and Logistics Tcodes | |
| Finance Y_FI_CCXX_ACCOUNTS_RECEIVABLE 3 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Account Receivable and Logistics Tcodes | |
| Finance Y_FI_CCXX_ACCOUNTS_RECEIVABLE 4 1. This role is currently implemented for Company Codes DE35 and US38 | |
| 2. Additionally, this role also provides access to Account Receivable and Logistics Tcodes | |
| Finance Y_FI_CCXX_BANK_STATEMENTS 2 1. This role is currently implemented for Company Code IN10 only | |
| Finance Y_FI_CCXX_BUSINESS_ACCOUNTANT 2 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Customer Service, Logistics and Master Data Team Tcodes | |
| Finance Y_FI_CCXX_EXPENSE_CLAIMS 2 1. This role is currently implemented for Company Codes US32 and US38 | |
| Finance Y_FI_CCXX_EXPENSE_CLAIMS 3 1. This role is currently implemented for Company Codes DE35, GB30 and IN10 | |
| Finance Y_FI_CCXX_FINANCE_OPERATIONS 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Finance Y_FI_CCXX_FINANCE_OPERATIONS 2 1. This role is currently implemented for Company Code DE36 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Finance Y_FI_CCXX_FINANCE_OPERATIONS 4 1. This role is currently implemented for Company Codes US32, US38 and IN10 | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Finance Y_FI_CCXX_FINANCE_OPERATIONS 6 1. This role is currently implemented for Company Codes DE35 and SE33 | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Finance Y_FI_CCXX_FINANCE_OPS_PARK 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Finance Y_FI_CCXX_FINANCE_OPS_POST 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Logistics Tcodes | |
| Finance Y_FI_CCXX_PAYMENT_RUNS 3 1. This role is currently implemented for Company Codes US32 & US38 only | |
| Finance Y_MM_CCXX_LOGISTIC_TEAM_LEADER 1 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Manufact. and Logistics Tcodes | |
| Finance Y_MM_CCXX_OPERATIONS_EXP_ADMTR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Tcodes relevant to all other STC Business Roles | |
| Finance Y_MM_CCXX_STOCK_TRANSPORT_OFFR 1 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Manufact. and Logistics Tcodes | |
| Finance Y_MM_CCXX_STOCK_TRANSPORT_OFFR 2 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Manufact. and Logistics Tcodes | |
| Finance Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to all other STC Business Role Tcodes | |
| Finance Y_SD_CCXX_EXPORT_OPERATOR 3 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service and Logistics Tcodes | |
| Finance Y_SD_CCXX_EXPORT_PROCESS_PLXX 2 1. This role is currently implemented for Company Code IN10, sales organisation IN18 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Logistics Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_BILLING_EXEC 1 1. This role is currently implemented for Company Code IN20, sales organisation IN20 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Logistics Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_BILLING_EXEC 4 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Logistics Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_BILLING_OPR 1 1. This role is currently implemented for | |
| a. Company Code GB30, sales organisation GB51 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Billing Administrator and Logistics Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_BILLING_OPR 2 1. This role is currently implemented for Company Code US32, sales organisation US32 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Logistics Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_BILLING_OPR 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Logistics Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_BILLING_OPR 5 1. This role is currently implemented for Company Code SE33, sales organisation SE33 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Logistics Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Logistics, Market Manager, Master Data Team and Man | |
| Finance Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 | |
| b. Company Code US32, sales organisation US32 | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Billing Administrator, Customer Service, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Finance Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Credit Controller, Commercial, Customer Service, Logistics, Market Manager, Master Data Team and Manufact. Tcodes | |
| Finance Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 13 1. This role is currently implemented for Company Codes IN20 and DE36 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 38 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 39 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 50 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 57 1. This role is currently implemented for Company Code DE35 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 84 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Logistics, Manufact.and Market Manager Tcodes | |
| Finance Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 137 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Logistics, Manufact.and Market Manager Tcodes | |
| Change(s) Required – | |
| 1. Add 3/14 missing ‘Finance’ Tcodes to existing composite role(s) - None of the 24 unique composite roles provide access to 3/14 ‘Finance’ Tcodes (F.61,F150,V.23) | |
| 2. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 3. Ensure that users across all sites with Finance responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 4. As these are marked as Sensitive Access; ensure that no users outside of those with Finance responsibilities are assigned these SAP roles. | |
| 5. 5/24 unique Composite roles are marked for SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 6. Ensure that none of these SAP roles are intended for business roles that do not have Finance responsibilities. | |
| 12. Business Role Logistics | |
| a. As per BPD, individuals with business role ‘Logistics’ require access to 7 specific T-codes – | |
| i. VL02n Change Outbound Delivery | |
| ii. VL01N Create Outbound Dlv. with Order Ref. | |
| iii. VL10 Edit User-specific Delivery List | |
| iv. ZS12 #N/A | |
| v. VL10C Order Items Due for Delivery | |
| vi. VL06O Outbound Delivery Monitor | |
| vii. MIGO Goods Movement | |
| b. Through analysis of the existing SAP composite roles, we noted that 55 such unique SAP composite roles were providing access to one or more of the aforementioned T-codes, though 49/55 composite roles do not provide access to all 7 Logistics T-codes. See summary below :- | |
| Business Role EY Global Role Distinct Users Comments Logistics SoD SA | |
| VL01N VL02N VL10 VL10C VL06O ZS12 MIGO | |
| Logistics Y:EC_CCXX_FIN:DEP_MANAGER1 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y:EC_CCXX_FIN:FINANCE_ACCT1 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y:EC_CCXX_FIN:FINANCE_ACCT2 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y:EC_CCXX_FIN:FINANCE_ACCT3 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Customer Service, Credit Controller, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y:EC_CCXX_FIN:FINANCE_CONTROL 1 1. This role is currently implemented for Company Codes IN10 and DE36 | |
| 2. Additionally, this role also provides access to Account Receivable, Customer Service, Manufact., Market Manager and Finance Tcodes | |
| Logistics Y:EC_CCXX_INV:PURC_REQS_CREA 2 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y:EC_CCXX_PUR:PROC_APPRV 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y:EC_CCXX_PUR:PROC_CREATE 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y:EC_CCXX_QC:PREPARER 3 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y:EC_CCXX_SAL:ORDER_CREATOR 1 1. This role is currently implemented for Company Code INPGM only | |
| 2. Additionally, this role also provides access to various Tcodes corresponding to all other STC Business Roles | |
| Logistics Y_FI_CCXX_ACCOUNTS_RECEIVABLE 1 1. This role is currently implemented for Company Codes IN10 and DE36 | |
| 2. Additionally, this role also provides access to Account Receivable and Finance Tcodes | |
| Logistics Y_FI_CCXX_ACCOUNTS_RECEIVABLE 2 1. This role is currently implemented for Company Codes GB30 and US32 | |
| 2. Additionally, this role also provides access to Account Receivable and Finance Tcodes | |
| Logistics Y_FI_CCXX_ACCOUNTS_RECEIVABLE 3 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Account Receivable and Finance Tcodes | |
| Logistics Y_FI_CCXX_ACCOUNTS_RECEIVABLE 4 1. This role is currently implemented for Company Codes DE35 and US38 | |
| 2. Additionally, this role also provides access to Account Receivable and Finance Tcodes | |
| Logistics Y_FI_CCXX_BUSINESS_ACCOUNTANT 2 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Customer Service, Finance and Master Data Team Tcodes | |
| Logistics Y_FI_CCXX_BUSINESS_ACCOUNTANT 9 1. This role is currently implemented for Company Code GB30 only | |
| Logistics Y_FI_CCXX_FINANCE_OPERATIONS 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Finance Tcodes | |
| Logistics Y_FI_CCXX_FINANCE_OPERATIONS 2 1. This role is currently implemented for Company Code DE36 only | |
| 2. Additionally, this role also provides access to Finance Tcodes | |
| Logistics Y_FI_CCXX_FINANCE_OPERATIONS 4 1. This role is currently implemented for Company Codes US32, US38 and IN10 | |
| 2. Additionally, this role also provides access to Finance Tcodes | |
| Logistics Y_FI_CCXX_FINANCE_OPERATIONS 6 1. This role is currently implemented for Company Codes DE35 and SE33 | |
| 2. Additionally, this role also provides access to Finance Tcodes | |
| Logistics Y_FI_CCXX_FINANCE_OPS_PARK 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Finance Tcodes | |
| Logistics Y_FI_CCXX_FINANCE_OPS_POST 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Finance Tcodes | |
| Logistics Y_MM_CCXX_BONDED_WAREHOUSE_OPR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_GETTER_TABLETS_MGMT 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_HANSONS_OPR_PLXX 1 1. This role is currently implemented for Company Code GB30, plant GB26 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_LOGISTIC_TEAM_LEADER 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, Finance and Manufact. Tcodes | |
| Logistics Y_MM_CCXX_LOGISTICS_MANAGER 6 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_LOGISTICS_OPERATOR 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_MANUFACTURING_ACCTNT 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_OPERATIONS_EXP_ADMTR 1 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also various Tcodes corresponding to all STC Business Roles | |
| Logistics Y_MM_CCXX_OPERATIONS_TEAM_LEAD 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_PHARMORPHIX_OPR_PLXX 1 1. This role is currently implemented for Company Code GB30, plant GB02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_PO_PUXX_PURCH_CLERK 1 1. This role is currently implemented for Company Code DE35, purchase organisation DE35 only | |
| 2. Additionally, this role also provides access to Customer Service and Manufact. Tcodes | |
| Logistics Y_MM_CCXX_POTTERS_OPR_ZVAR 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_STD_GDS_MVT_OPR_PLXX 12 1. This role is currently implemented for Company Code SE33, plant SE01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 1 1. This role is currently implemented for | |
| a. Company Code SE33, plant SE01 only | |
| b. Company Code GB30, plant GB05 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 2 1. This role is currently implemented for Company Code IN10, all plants only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 4 1. This role is currently implemented for | |
| a. Company Code DE35, all plants only | |
| b. Company Code GB30, plant GB02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_STOCK_ADJUSTMNT_PLXX 7 1. This role is currently implemented for Company Code GB30, plant GB01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_STOCK_TRANSPORT_OFFR 1 1. This role is currently implemented for Company Code IN20 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Finance and Manufact. Tcodes | |
| Logistics Y_MM_CCXX_STOCK_TRANSPORT_OFFR 2 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Finance and Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 1 1. This role is currently implemented for Company Code DE35, plant DE03 only | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 3 1. This role is currently implemented for Company Code GB30, plant GB01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 4 1. This role is currently implemented for Company Code GB30, plant GB05 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 5 1. This role is currently implemented for Company Code GB30, all plants only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 7 1. This role is currently implemented for Company Code GB30, plant GB02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 9 1. This role is currently implemented for Company Code US38, plant US28 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 15 1. This role is currently implemented for Company Code SE33, plant SE01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 20 1. This role is currently implemented for Company Code DE35, plant DE02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 22 1. This role is currently implemented for Company Code DE35, plant DE01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WAREHOUSE_OPR_PLXX 24 1. This role is currently implemented for Company Code US38, plant US26 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WRITE_ON&OFF_ZALL 1 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_MM_CCXX_WRITE_ON&OFF_ZVAR 2 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PM_CCXX_MAINT_MANAGER_PLXX 2 1. This role is currently implemented for Company Code IN10, plant IN11 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PM_CCXX_MAINT_OPERATOR_PLXX 3 1. This role is currently implemented for Company Code IN10, plant IN11 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PM_CCXX_MAINT_OPERATOR_PLXX 5 1. This role is currently implemented for Company Code DE35, plant DE02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PM_CCXX_MAINT_OPERATOR_PLXX 8 1. This role is currently implemented for Company Code DE35, plant DE01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PM_CCXX_MAINT_PLANNER_PLXX 23 1. This role is currently implemented for Company Code DE35, plants DE01 & DE02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_MANAGER_PLXX 7 1. This role is currently implemented for Company Code US38, plant US26 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_MANAGER_PLXX 9 1. This role is currently implemented for Company Code IN10, plant IN16 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_MANAGER_PLXX 12 1. This role is currently implemented for Company Code GB30, plant GB08 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_OPERATOR_PLXX 4 1. This role is currently implemented for Company Code SE33, plant SE01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_OPERATOR_PLXX 5 1. This role is currently implemented for Company Code DE35, plant DE02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_OPERATOR_PLXX 8 1. This role is currently implemented for Company Code DE35, plant DE02 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_OPERATOR_PLXX 9 1. This role is currently implemented for - | |
| a. Company Code IN10, plant IN16 only | |
| b. Company Code US38, plant US26 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_OPERATOR_PLXX 63 1. This role is currently implemented for Company Code GB30, plant GB08 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_PLANNER_PLXX 6 1. This role is currently implemented for Company Code GB30, plant GB08 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODTN_SUPRVISR_PLXX 3 1. This role is currently implemented for Company Code SE33, plant SE01 only | |
| 2. Additionally, this role also provides access to Manufact. Tcodes | |
| Logistics Y_PP_CCXX_PRODUCTION_PLANNER 5 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Manufact., Market Manager and Master Data Team Tcodes | |
| Logistics Y_QC_CCXX_QUALITY_EXEC_PLXX 1 1. This role is currently implemented for Company Code IN10, plant IN16 only | |
| Logistics Y_QC_CCXX_QUALITY_LABORATORY 2 1. This role is currently implemented for Company Code DE35 only | |
| Logistics Y_SD_CCXX_CUSTOMER_SERVICE_REP 4 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Credit Controller, Customer Service, Manufact., Market Manager, Master Data Team and Finance Tcodes | |
| Logistics Y_SD_CCXX_EXPORT_OPERATOR 3 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Customer Service, and Finance Tcodes | |
| Logistics Y_SD_CCXX_EXPORT_PROCESS_PLXX 2 1. This role is currently implemented for Company Code IN10, plant IN18 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Finance Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_BILLING_EXEC 1 1. This role is currently implemented for Company Code IN20, sales organisation IN20 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Finance Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_BILLING_EXEC 4 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Finance Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_BILLING_OPR 1 1. This role is currently implemented for - | |
| a. Company Code GB30, sales organisation GB51 | |
| b. Company Code US38, sales organisation US38 | |
| 2. Additionally, this role also provides access to Billing Administrator and Finance Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_BILLING_OPR 2 1. This role is currently implemented for Company Code US32, sales organisation US32 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Finance Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_BILLING_OPR 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Finance Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_BILLING_OPR 5 1. This role is currently implemented for Company Code SE33, sales organisation SE33 only | |
| 2. Additionally, this role also provides access to Billing Administrator and Finance Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_BILLING_PRNT 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| Logistics Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Manufact., Market Manager and Master Data Team Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 2 1. This role is currently implemented for | |
| a. Company Code DE35, sales organisation DE35 only | |
| b. Company Code US32, sales organisation US32 only | |
| 2. Additionally, this role also provides access to Billing Administrator, Commercial, Credit Controller, Customer Service, Finance, Manufact., Market Manager and Master Data Team Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_CUST_SRV_REP 3 1. This role is currently implemented for Company Code GB30, sales organisation GB31 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Finance, Manufact., Market Manager and Master Data Team Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_DELIVERY_OPR 1 1. This role is currently implemented for Company Code GB30, sales organisation GB51 only | |
| Logistics Y_SD_CCXX_SO_SOXX_DELIVERY_OPR 2 1. This role is currently implemented for Company Code US32, sales organisation US32 only | |
| Logistics Y_SD_CCXX_SO_SOXX_DELIVERY_OPR 7 1. This role is currently implemented for Company Code SE33, sales organisation SE33 only | |
| Logistics Y_SD_CCXX_SO_SOXX_DELIVRY_EXEC 1 1. This role is currently implemented for Company Code IN20, sales organisation IN20 only | |
| Logistics Y_SD_CCXX_SO_SOXX_DELIVRY_EXEC 4 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| Logistics Y_SD_CCXX_SO_SOXX_DELIVRY_PLXX 5 1. This role is currently implemented for Company Code US38 - sales organisation US38 and plant US26 only | |
| 2. Additionally, this role also provides access to Customer Service Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_DELIVRY_PLXX 7 1. This role is currently implemented for Company Code US38 - sales organisation US38 and plant US28 only | |
| 2. Additionally, this role also provides access to Customer Service Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 5 1. This role is currently implemented for | |
| a. Company Code SE33, sales organisation SE33 only | |
| b. Company Code US38, sales organisation US38 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Manufact., Market Manager and Master Data Team Tcodes | |
| Logistics Y_SD_CCXX_SO_SOXX_SALE_OR_EXEC 6 1. This role is currently implemented for Company Code IN10, sales organisation IN10 only | |
| 2. Additionally, this role also provides access to Commercial, Credit Controller, Customer Service, Manufact., Market Manager and Master Data Team Tcodes | |
| Logistics Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 13 1. This role is currently implemented for Company Codes IN20 and DE36 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 38 1. This role is currently implemented for Company Code US32 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 39 1. This role is currently implemented for Company Code IN10 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 50 1. This role is currently implemented for Company Code SE33 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 57 1. This role is currently implemented for Company Code DE35 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 84 1. This role is currently implemented for Company Code US38 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Manufact.and Market Manager Tcodes | |
| Logistics Y_ZZ_CCXX_ACCESS_FOR_ALL_USERS 137 1. This role is currently implemented for Company Code GB30 only | |
| 2. Additionally, this role also provides access to Accounts Receivable, Billing Administrator, Customer Service, Finance, Manufact.and Market Manager Tcodes | |
| Change(s) Required – | |
| 1. Align roles ‘CUST_SRV_REP’ , ‘BUSINESS_ACCOUNTANT’ , ‘BILLING_PRNT’ so that it is consistent with the same role for other company code (along with missing authorisation) | |
| 2. Clone roles mentioned above for each site without such a role (including consolidation sites) - following the same naming convention, altering underlying company code specific authorisations accordingly. | |
| 3. Ensure that users across all sites with Logistics responsibilities are assigned the relevant SAP role or roles from these based on their specific responsibilities and the company code(s) within which they operate | |
| 4. As these are marked as Sensitive Access; ensure that no users outside of those with Logistics responsibilities are assigned these SAP roles. | |
| 5. 16/55 unique Composite roles are marked for SoD; ensure that access to conflicting Tcodes is either mitigated or access to conflicting Tcode(s) are withdrawn from these SAP roles. | |
| 6. Ensure that none of these SAP roles are intended for business roles that do not have Logistics responsibilities. | |
| 11.2. Business Role Change Summaries | |
| ** Based on the analysis performed, changes required have been mentioned in the section 11.1 for each of the STC Business roles captured within this BPD. | |
| 12. Business, Functional and Non-functional Requirements and Solution Design | |
| 12.1.1. Business and Functional Requirements | |
| Refer to the STC Functional Design Document (FDD). | |
| 12.1.2. Non-functional Requirements | |
| Specify any No-functional Requirements (NFRs) that are identified during the design activities. These will be fed into the NFR section of the RTM after high level design. NFRs include SLAs, user numbers, transaction volumes, archiving, system performance, Business continuity / disaster recovery requirements. | |
| Ref NFR Category NFR Description NFR Type (SLA / Volumes etc.) | |
| 1 None identified. | |
| 13. Design Gaps | |
| Specify requirement that is not met by SAP Standard and which a design decision is still to be determined through the JM Governance process | |
| Ref Requirement Description GAP Resolution Options Impact (L/M/H) Resolution Date Owner | |
| 1 It has been assumed that CRM will be implemented withing the Project Concert timeframe and that it will capture both Sales Forecasts and customer Quotations that will be interfaced to SAP. Implement CRM interface as stated | |
| Or | |
| Manual entry of forecasts and Quotations into SAP M TBD Mngmnt. | |
| 13.1.1. Data Impacts | |
| Name of Data Object Object Type (Standard/Custom) (New/Existing) Name of the (Table) Name of the (Field) Data Requirement | |
| (Mention "No Improvement" if object not in scope for any data improvements) Sites Impacted/ Affected Remarks | |
| Customer Existing KNVP PARVW Sales Manager as a partner function All | |
| Sales Order Existing VBAK ZZ_CRM_NUMBER CRM Forecast or QT number All | |
| 14. Risks, Issues, Actions and Dependencies | |
| 14.1.1. Design Risks and Issues (outstanding) | |
| Document any risks / Issues impacting on the business process design / solution and ability to deliver the scope within the agreed schedule timeline and budget and deliver on the benefits. | |
| Ref No Risk / Issue Description Impact Status Mitigation Resolution Date | |
| 140/146 CRM will be implemented withing the Project Concert timeframe and that it will capture both Sales Forecasts and customer Quotations that will be interfaced to SAP. Manual entry of forecasts and Quotations into SAP may continue. In Progress | |
| 142 Catalyst is frequently in volume on a sales order and supplied by weight. Standard density adjustment factors are used in SAP that do not accurately represent the supplied batch. Under / over supply of catalyst to customer In Progress | |
| 14.1.2. Design Related Actions | |
| Document any open actions assigned to the design group as part of the business process design / solution that is required to be completed and could impact the realisation phase. | |
| Ref No Action Owner Due Date Status Closed / Open | |
| 1 Business to share example of the Customer Credit Form as maintained in Lotus Notes to enable the harmonization of input fields required for SAP entry across all sites | |
| 2 | |
| 14.1.3. Process Area Dependencies | |
| Document any dependencies with other processes that will impact the end-to-end design of the above solution. | |
| Ref ID Dependency Area Dependency Description Agreed (Y/N) Type | |
| Predecessor / Post step Integration Process Flow Ref | |
| D001 RTR Dunning procedure Y | |
| D002 RTR Credit Management Y | |
| D003 LES Stock Allocation for sales (Germany) Y | |
| 15. Appendix | |
| Project Concert | |
| FDD002 – Sales to Cash (STC) | |
| Functional Design Document | |
| V1.01 DRAFT | |
| [Publish Date] | |
| Purpose: The objective of this document is to define the detailed functional design to meet the business requirements across the six E2E process workstreams (STP, STC, RTR, LES, PTM and R&D and Licencing business) and provide a solution scope including: | |
| • To provide the functional design including the organisational structures and configuration rationale to support the six 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 within the STC solution | |
| • Document the System and Technology requirements for the STC 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 information on the end-to-end processes. | |
| Scope: In scope are the detailed functional design and configuration recommendation of the end-to-end Sales to Cash processes covered in the Business Process documentation (BPD): List the L4 / L5 processes that are in scope for this process area e.g., Creation of Sales Order. | |
| Change history | |
| This version replaces all previous versions. Please destroy any previous versions. | |
| Version Date/ | |
| Date approved Author | |
| To be approved by Comments | |
| 0.1 14/02/22 | |
| Anil Agarwal | |
| Bob Campbell Initial Draft | |
| 0.2 13/04/2022 Bob Campbell Update in response to SA review | |
| 0.3 16/05/22 Bob Campbell Updates following Concert scope update | |
| 0.96 20/05/2022 Bob Campbell For Review | |
| 0.97 09/06/2022 Bob Campbell Updating walkthrough comments | |
| 0.98 09/06/2022 Matt Allen Issuing for Approval | |
| 1.00 10/06/2022 Matt Allen Marking record of approval and baselining | |
| 1.01 29/07/2022 Bob Campbell Updates during Realisation | |
| Changes in RED as tracking till baselined | |
| RACI table | |
| Function Name | |
| Responsible: E2E Functional Leads Bob Campbell | |
| Accountable: BPE Susan Simpson | |
| Contributed: SME / BDO network / Architects | |
| Informed: Project Management Chris Fogg, John Chapamba | |
| Document Review & Sign-off | |
| Signatories | |
| Role Name Comments Received Date | |
| Sol Arch Lead Ian Triccas Yes on v0.97 09/06/2022 | |
| Reviewers | |
| Role Name Comments Received Date | |
| BPE Susan Simpson Yes V0.97 | |
| 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 | |
| AP Accounts Payables (SAP module) | |
| AR Accounts Receivables (SAP module) | |
| BPD Business Process Design | |
| BU Business Unit of JM | |
| ERS Evaluated Receipt Settlement | |
| EDI Electronic Data Interchange | |
| GR Goods Receipt | |
| UP Unify Programme | |
| IR Invoice Receipt | |
| LIV Logistics Invoice Verification (SAP sub module) | |
| MM Materials Management (SAP module) | |
| OCR Optical Character Recognition | |
| 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 | |
| SR Service Receipt | |
| WHT Withholding Tax | |
| Table of Content | |
| Contents | |
| Change history 3 | |
| Table of Content 5 | |
| 1. Business Process Requirements 8 | |
| 1.1 Business Process Area Introduction 8 | |
| 1.2 Business Process Requirements 9 | |
| 1.2.1 Level 2: 02.03 Perform Contract & Pricing Lifecycle Management 9 | |
| 1.2.2 Level 2: 02.03 Develop & Manage Sales, Proposals Bids and Quotes 9 | |
| 1.2.3 Level 2: 02.04 Perform Operational Sales 10 | |
| 1.2.4 Level 2: 02.06 Manage Customer Billing & Credit 11 | |
| 1.2.5 Level 2: 02.07 Manage Accounts Receivable 12 | |
| 1.2.6 Level 2: 02.09 Manage Customer & Sales Master Data 13 | |
| 1.3 Design Options 13 | |
| 1.3.1 STC Integration Scope BAG 034 13 | |
| 2. Functional Solution Design 15 | |
| 2.1 SAP Organisation for STC 15 | |
| 2.1.1 Company Code 15 | |
| 2.1.2 Sales Organisation 16 | |
| 2.1.3 Distribution channel 17 | |
| 2.1.4 Division 18 | |
| 2.1.5 Maintain Sales Office 18 | |
| 2.1.6 Maintain Sales Group 19 | |
| 2.1.7 Define Credit Control Area 19 | |
| 2.1.8 Set up Sales Area 19 | |
| 2.1.9 Assign Sales organization to company code. 20 | |
| 2.1.10 Assign Distribution Channel to Sales Organization. 21 | |
| 2.2 Forecasting 25 | |
| 2.2.1 Introduction 25 | |
| 2.2.2 CRM Interface - Forecasting 26 | |
| 2.2.3 Forecast Documents in SAP 27 | |
| 2.2.4 Forecast Accuracy Reporting 33 | |
| 2.2.5 Forecast Credit Outlook Reporting 34 | |
| 2.3 Quotation Processing 36 | |
| 2.3.1 Introduction 36 | |
| 2.3.2 CRM Interface - Quotations 37 | |
| 2.3.1 Quotation Documents in SAP 37 | |
| 2.4 Sales Order Processing 44 | |
| 2.4.1 Introduction 44 | |
| 2.4.2 Sales Orders in SAP 45 | |
| 2.4.3 General Sales Order Updates 49 | |
| 2.4.4 Billing Plans & Down-Payments 54 | |
| 2.4.5 Output Determination 58 | |
| 2.5 Monitoring Sales Orders 59 | |
| 2.5.1 Introduction 59 | |
| 2.5.2 Order blocked due to incompletion 59 | |
| 2.5.3 Release Delivery Block 62 | |
| 2.5.4 Release Billing Block 63 | |
| 2.5.5 Sales Order Monitor - To be Changes 65 | |
| 2.5.5.1 Target pricing validation 65 | |
| 2.5.5.2 Emergency order indicator for reporting 65 | |
| 2.5.5.3 Reports to support sales processes 66 | |
| 2.6 Credit Management 72 | |
| 2.6.1 Introduction 72 | |
| 2.6.2 Risk Categories 73 | |
| 2.6.3 Define Automatic Credit Control 74 | |
| 2.6.4 Customer Credit Group 77 | |
| 2.6.5 Other Core Configuration 77 | |
| 2.6.6 Credit Reporting 77 | |
| 2.7 Billing 78 | |
| 2.7.1 Introduction 78 | |
| 2.7.2 Perform Customer Billing 78 | |
| 2.7.2.1 Billing Document Number Range - 80 | |
| 2.7.2.2 Billing Block 81 | |
| 2.7.2.3 Collective Billing 81 | |
| 2.7.2.4 Copy Control Setting 81 | |
| 2.7.3 Credit and Debit Memo 82 | |
| 2.7.4 Returns Process 83 | |
| 2.7.5 Billing Output Types 85 | |
| 2.7.5.1 Key JM CT requirements related to invoice forms include: 85 | |
| 2.8 Accounts Receivable 87 | |
| 2.8.1 Introduction 87 | |
| 2.8.2 Process Accounts Receivable 88 | |
| 2.8.3 Process Customer Account Clearing 88 | |
| 2.8.3.1.1 House bank 88 | |
| 2.8.3.1.2 Statement Status 88 | |
| 2.8.3.1.3 Posting Rule 89 | |
| 2.8.3.1.4 Automatic account determination 89 | |
| 2.8.3.1.5 Automatic clearing rules 90 | |
| 2.8.4 Process Lockbox 91 | |
| 2.8.5 Create Customer Statements 91 | |
| 2.8.5.1 Periodic Account Statement Indicator 91 | |
| 2.8.5.2 Correspondence types 92 | |
| 2.8.5.3 Assign Program for Automatic Correspondence 93 | |
| 2.8.6 Process Collections 94 | |
| 2.8.6.1 Complete Debt Notification 94 | |
| 2.8.6.1.1 Dunning Procedures 95 | |
| 2.8.7 Process Customer Credits for Returns 99 | |
| 2.9 Master data 102 | |
| 2.9.1 Customer Master Data 102 | |
| 2.9.2 Customer Account Group 102 | |
| 2.9.3 Define and Assign Number range for Customer master records- 104 | |
| 2.9.4 Additional Customer Master fields and Requirements - 105 | |
| 2.9.5 Incoterms 105 | |
| 2.9.6 Customer Payment Terms 106 | |
| 2.9.7 Maintain Sales Master Data 107 | |
| 2.9.7.1 Define Customer Groups 107 | |
| 2.9.7.2 Define Sales District 110 | |
| 2.9.7.3 Maintain Reserve fields in Customer Master 110 | |
| 2.9.8 Perform Pricing Administration 111 | |
| 2.9.8.1 Document pricing procedure 114 | |
| 2.9.8.2 Pricing procedure assigned to customer 116 | |
| 2.9.8.3 Maintain Pricing Procedure 117 | |
| 2.9.8.4 Define Pricing Procedure Determination 118 | |
| 3. Technical and Development Related Items 121 | |
| 3.1 Workflow 121 | |
| 3.2 Report 121 | |
| 3.3 Interface 124 | |
| 3.4 Conversion 125 | |
| 3.5 Enhancements 125 | |
| 3.6 Forms 126 | |
| 3.7 Modifications 127 | |
| 4. Appendix 128 | |
| 1. Business Process Requirements | |
| 1.1 Business Process Area Introduction | |
| Process “Sales to Cash” is an end-to-end business operation that involves sales strategy to cash collection. This section provides a description of the business process areas and business scenarios for sales to cash and will give the reader a high-level understanding of the scope for the Harmonization, Improvement, and Consolidation project. It also serves to provide a pictural representation of the Level 1 and Level 2 process, highlighting which Level 2 processes are in scope for sales to cash. | |
| The scope of this document is to identify the to-be high-level processes within the defined business context. It identifies the standardized functional and process design across the 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 the UK, Chicago, Savannah, Sweden, Germany, India, Paddington, Netherlands, and branch offices. This document only covers those upstream and downstream Level 3 processes in the ‘Sales to Cash’ scope (shown in blue in the following diagram). | |
| Sites not currently on SAP –Licensing, Netherlands, Trinidad, and Saudi Arabia (designated as Branch in the workshop) were not at the scoping workshops. | |
| 1.2 Business Process Requirements | |
| STC related requirements have been captured in two phases, High-Level Design and Detailed Design. Below is the consolidated list of requirements based on the Level 2 Process. | |
| 1.2.1 Level 2: 02.03 Perform Contract & Pricing Lifecycle Management | |
| Detailed process requirements are captured below: | |
| Table 1 | |
| Business Process Requirements | |
| ID Requirement Description Business Criticality (MoSCoW) FTS (1-4) Solution Design | |
| BR009_STC Perform pricing administration | |
| 1) Maintain price list in SAP | |
| 2) Provide pricing visibility and audit trail of exceptions | |
| 3) Automate tax calculation to be included on the invoice | |
| 4) Include freight in pricing calculation | |
| 5) Maintain contract and customer-specific pricing Must Have 4 Perform Pricing Administration | |
| 1.2.2 Level 2: 02.03 Develop & Manage Sales, Proposals Bids and Quotes | |
| Detailed process requirements are captured below: | |
| Table 2 | |
| Business Process Requirements | |
| ID Requirement Description Criticality FTS (1-4) Solution Design | |
| BR011_STC Perform requirement evaluation | |
| 1) Provide an E2E solution for CRM and ERP. | |
| 2) Harmonize forecast process | |
| 3) Integrate transfer of forecast data from CRM to SAP | |
| 4) Provide a single source of commercial data | |
| 5) Report on forecast accuracy at order line level for demand managers (not OTIF) Must Have 4 Forecasting | |
| Quotation Processing | |
| BR012_STC Prepare and monitor sales proposals/Bids | |
| 1) Provide an E2E solution for CRM and ERP. | |
| 2) Harmonize proposal process | |
| 3) Provide a single source of commercial data Must Have 4 Sales Order Processing | |
| BR013_STC Prepare and monitor sales quotations | |
| 1) Provide an E2E solution for CRM and ERP. | |
| 2 Harmonize quotes process | |
| 3) Integrate transfer of quotation data from CRM to SAP | |
| 4) Provide a single source of commercial data Must Have 4 Quotation Processing | |
| 1.2.3 Level 2: 02.04 Perform Operational Sales | |
| Detailed process requirements are captured below: | |
| Table 3 | |
| Business Process Requirements | |
| ID Requirement Description Criticality FTS (1-4) Solution Design | |
| BR014_STC Perform sales order processing | |
| 1)Identify emergency orders | |
| 2) Provide billing plans/ milestone billing/pre-payments in system | |
| 3) Automate order confirmation generation and email | |
| 4) Harmonize and modernize order confirmation format | |
| 5) Attach T&Cs to order confirmation | |
| 6) Rationalize and move toward standard SAP reports to support sales activities | |
| 7) Consolidate non-SAP sites | |
| 9) Modify material master data to alleviate stock allocation issues (Germany) Must Have 4 Sales Order Processing | |
| BR015_STC Monitor sales orders | |
| 1) Rationalize and move toward standard SAP reports to monitor customer orders | |
| Must Have 4 Monitoring Sales Orders | |
| 1.2.4 Level 2: 02.06 Manage Customer Billing & Credit | |
| Detailed process requirements are captured below: | |
| Table 4 | |
| Business Process Requirements | |
| ID Requirement Description Criticality FTS (1-4) Solution Design | |
| BR022_STC Evaluate and monitor customer credit | |
| Credit Reports - | |
| 1) Rationalize and move toward standard SAP reports to support credit management | |
| 3) Develop a report to highlight small balances on a customer account for cleansing. | |
| Credit Management Configuration - | |
| 1) Manage customer credit block rules to remove unfound credit blocks. (UK) | |
| 2) Create customer credit group to give visibility to JM risk at global level. | |
| Credit Master - | |
| 1) Complete credit limit in customer master data Must Have 4 Credit Management | |
| BR023_STC Perform customer billing | |
| Invoices for sales process - | |
| 1) Harmonized and modernize invoice format. | |
| 2) Develop process for DDP sales from UK to EU | |
| 3) Provide freight and bin surcharge on invoice Must Have 4 Billing | |
| 1.2.5 Level 2: 02.07 Manage Accounts Receivable | |
| Detailed process requirements are captured below: | |
| Table 5 | |
| Business Process Requirements | |
| ID Requirement Description Criticality FTS (1-4) Solution Design | |
| BR024_STC Process Accounts Receivable (AR) | |
| 1) Process Credit and Debit memo request | |
| 2) Update AR process with BCM Must Have 4 Process Accounts Receivable | |
| BR025_STC Process collections | |
| 1) Create and automatically distribute Dunning Letters for customers with no send option | |
| 2) Capture notes from collection phone calls | |
| 3) Rationalize and move toward standard SAP reports to support collection activities | |
| 4) Provide customer statements for collection reminder or on request Must Have 4 Process Collections | |
| BR026_STC Process customer credits | |
| 1) Harmonized process for customer returns and credits Must Have 4 Process Customer Credits for Returns | |
| 1.2.6 Level 2: 02.09 Manage Customer & Sales Master Data | |
| Detailed process requirements are captured below: | |
| Table 6 | |
| Business Process Requirements | |
| ID Requirement Description Criticality FTS (1-4) Solution Design | |
| BR030_STC Maintain customer records | |
| 1) Represent Account Manager in a partner function (from sales group) | |
| 2) Set governance to annually review active customers. | |
| 3) Cleanse and enhance customer master data | |
| Include D&B reference, DUNS number, Dunning, payment terms, statement indicator. Must Have 4 Sales Order Processing | |
| Customer Master Data | |
| Additional Customer Master fields and Requirements | |
| BR031_STC Maintain sales master data | |
| 1) Introduce product exclusions Must Have 4 Sales Order Processing | |
| BR033_STC Manage customer payment terms | |
| 1) Rationalize customer payment terms and add into customer master data Must Have 4 Customer Payment Terms | |
| 1.3 Design Options | |
| 1.3.1 STC Integration Scope BAG 034 | |
| Option 1 | |
| Proposal Description: This BAG paper, together with supporting PTM enhancements is aimed at delivering a core forecast to Master Production Schedule solution supporting the implementation of parallel CRM and S&OP initiatives and enabling automation and optimisation of the front end sales process. | |
| Business | |
| Value: Enablement of parallel CRM project | |
| Enablement of parallel S&OP Initiatives | |
| Benefits: Interface with CRM for forecasts and quotations. | |
| Note that the ATP aspects of this BAG paper were delayed as a result of the re-scoping exercise conducted at the end of detailed design. | |
| Option 2 – not identified | |
| Proposal Description: | |
| Business | |
| Value: | |
| Benefits: | |
| Preferred Solution and Justification: | |
| Option 1: | |
| Provides MVP for full strategic end state integration with CRM. | |
| Transfers Quotations to SAP so pricing schemas and tax conditions can be used to determine the final quotation price. | |
| Enables sales forecast to be generated automatically in (Sales Orders plus unconverted quotations above a specific probability of success). | |
| Transfers forecast to S&OP (initially in spreadsheet format) to support sales and operations planning. | |
| 2. Functional Solution Design | |
| 2.1 SAP Organisation for STC | |
| The Enterprise Structure described in this section are the major entities related to Sales to Cash (STC) process. The Enterprise Structure for STC contains the following objects: | |
| Definition | |
| 1. Company Code | |
| 2. Sales Organization | |
| 3. Distribution channel | |
| 4. Division | |
| 5. Sales Office | |
| 6. Sales group | |
| 7. Credit Control Area. | |
| Assignment | |
| 1. Setup Sales Area | |
| 2. Assign Sales organization to company code | |
| 3. Assign Distribution channel to Sales organization | |
| 4. Assign Division to Sales organization | |
| 5. Assign Sales organization Distribution channel to Plant | |
| 6. Assign Sales Area to Credit Control Area | |
| 7. Assign Sales Office to Sales Area | |
| 8. Assign Sales Group to Sales Office | |
| Note: - Definitions of company codes, controlling areas and assignments are in the RTR document FDD003 and plants and shipping points in FDD001. | |
| The Sales related enterprise structure for CT is: | |
| 2.1.1 Company Code | |
| The Company Code is the central organizational unit for which a complete set of self-contained accounts can be drawn up for external reporting. Company Codes are used to create legally independent entities. | |
| Company ID Company Name Existing / New Comments | |
| DE35 Johnson Matthey Emmerich Existing | |
| GB30 JM PT UK Existing | |
| IN10 JMCIPL Amog Existing | |
| SE33 Johnson Matthey FORMOX AB Existing | |
| US32 JM PT US Existing | |
| US38 JM PT Savannah Existing | |
| GB35 Licensing (Paddington UK) New - | |
| NL10 IEBV New - | |
| TT10 Trinidad & Tobago New | |
| SA10 Saudi Arabia New | |
| CA36 Synetix Canada Existing Not in use | |
| IN20 JM PT India - Taloja Existing Not in use | |
| IN30 JMCIPL PGMCAT Existing Not in use | |
| IN34 Synetix India (CO-PA) Existing Not in use | |
| DE36 X-Zyme GmbH Existing Not in use | |
| GB31 PPS Ltd Existing Not in use | |
| GB50 Johnson Matthey ACMA Existing Not in use | |
| GB90 Synetix Haverton (CO-PA) Existing Not in use | |
| GB95 Synetix Emmerich (CO-PA) Existing Not in use | |
| IN01 Country Template - IN Existing Not in use | |
| 2.1.2 Sales Organisation | |
| Definition | |
| The sales organization is an organizational unit within logistics, that structures the company according to its sales requirements. | |
| Use | |
| A sales organization is responsible for the sale and distribution of goods and services. | |
| It represents the selling unit as a legal entity. It is responsible for product guarantees and other rights to recourse, for example. Regional subdividing of the market can also be carried out with the help of sales organizations. Each business transaction is processed within a sales organization. | |
| The sales organization must be specified in all sales documents. It is therefore available for all basic functions of SD (such as pricing, availability, etc.). | |
| Structure | |
| A sales organization can be subdivided into several distribution chains which determine the responsibility for a distribution channel. | |
| Several divisions can be assigned to a sales organization which is responsible for the materials or services provided. | |
| A sales area determines which distribution channel can be used to sell the products from one division in a sales organization. | |
| Integration | |
| Each sales organization is assigned exactly one company code for which enter all accounting details of the sales organization. | |
| A distribution chain can be active for several plants and the plants can be assigned to different company codes. If the sales organization and plant are assigned to different company codes, an internal billing document is sent between the company codes before the sales transactions are entered for accounting purposes. | |
| Sales Org ID Sales Organization Name Existing / New Comments | |
| DE35 PCT DE Existing | |
| GB30 PCT UK Existing | |
| IN10 JMCIPL AMOG Existing | |
| SE33 JM Formox Sweden Existing | |
| US32 PCT US Existing | |
| US38 JM PT Savannah Existing | |
| GB35 Licensing (Paddington UK) New | |
| NL10 IEBV New | |
| GB31 PCT Services UK Existing | |
| GB50 PCT UK Haverton Existing Not in use | |
| GB51 Pharmorphix Existing Not in use | |
| GB90 PCT Haverton PA Existing Not in use | |
| GB95 PCT Emmerich PA Existing Not in use | |
| IN20 JMCIPL PCEO Existing Not in use | |
| IN30 JMCIPL PGMCAT Existing Not in use | |
| IN34 PCT India Existing Not in use | |
| US33 Univar Existing Not in use | |
| US42 Services US Existing Not in use | |
| US50 StePac USA INC Existing Not in use | |
| 2.1.3 Distribution channel | |
| Distribution Channel is the process of distributing the goods and/or services to the customer. Distribution channel can be used as selection criteria for creating lists. One or more distribution channel can serve the same customer within the same sales organization. | |
| Distribution channel can be assigned to one or more sales organization. | |
| Distribution channel Distribution channel Name Existing / New Comments | |
| 00 Standard channel Exiting | |
| 01 Distribution Channel 01 Exiting Not in use | |
| 2.1.4 Division | |
| Division is products or range of products or a group of products. Divisions assign to the Sales Organization and multiple divisions can be assigned to Sales Organization. Material always belongs to one division. | |
| Divisions can be assigned to Sales organization and multiple divisions assigned to single sales organization. Division can be assigned to one or more distribution channels. Sales office can be assigned to division. | |
| Division Division Name Existing / New Comments | |
| 00 PCT Products Existing | |
| 99 PGM Products Existing Not in use | |
| 2.1.5 Maintain Sales Office | |
| Sales office is an organizational unit which can use as a branch. Sales office contains group of salespersons working to perform the direct or indirect sales. Sales office can be assigned to sales area and multiple sales offices can assign to a Sales Area. | |
| Sales Office Description Existing / New Comments | |
| DE35 PCT DE Existing | |
| GB30 PCT UK Existing | |
| IN01 AMOG - Gurgaon Existing | |
| SE33 JM Formax Sweden Existing | |
| US32 PCT US Existing | |
| US38 JM PT Savannah Existing | |
| GB35 Licensing (Paddington UK) New | |
| NL10 IEBV New | |
| IN02 PCEO - Taloja Existing Not in use | |
| IN03 PGMCat - Taloja Existing Not in use | |
| GB31 ICI PPS Ltd Existing | |
| GB40 PCT Services - UK Existing Not in use | |
| GB41 PCT Services - Azeri Existing Not in use | |
| GB42 PCT Services - Aus. Existing Not in use | |
| GB43 PCT Services - Abu D Existing Not in use | |
| GB50 PCT UK Haverton Existing Not in use | |
| GB51 Pharmorphix Existing Not in use | |
| US33 VWR US (do not use) Existing Not in use | |
| US50 StePac USA INC Existing Not in use | |
| VC01 VWR CANADA Existing Not in use | |
| VU01 VWR USA Existing Not in use | |
| 2.1.6 Maintain Sales Group | |
| Sales Group is the group of salespersons working for various purposes. Sales Group can be assigned to the Sales Office and multiple Sales Groups can assign to one Sales Office. | |
| Note that currently Sales Group is maintained as Account Manager. | |
| As noted above, we will use a new partner function to capture the Account Manager in future. However, old values must be left in this organisational element field to maintain the integrity of the legacy sales orders. Sales Group will be removed from the relevant incompletion procedures, and no future use for this field is planned. | |
| 2.1.7 Define Credit Control Area | |
| Credit Control Area Description Existing / New Comments | |
| CR01 JM Credit control area PCT GB30 Existing | |
| CR02 JM Credit control area PCT DE35 Existing | |
| CR04 JM Credit control area PCT US32 Existing | |
| CR08 JM Credit control area PCT US38 Existing | |
| CR09 JM Credit control area PCT SE33 Existing | |
| CR05 JM Credit control area PCT IN10 Existing | |
| CR10 JM Credit control area PCT GB35 New | |
| CR11 JM Credit control area PCT NL10 New | |
| CR06 JMCIPL NICAT Credit Control Area Existing Not in use | |
| CR07 JMCIPL PGMCAT Credit Control Area Existing Not in use | |
| CR03 JM Credit control area PCT GB50 Existing Not in use | |
| 2.1.8 Set up Sales Area | |
| Sales Area plays an important role while processing sales. Sales Area defines the sales organization, distribution channel used to sell the products from the specific division. Sales Area is a combination of sales organization, distribution channel and division. | |
| Sales Area belongs to only one company code. Sales Area can be assigned to credit control area. Multiple sales areas can be assigned to one or multiple credit control areas. | |
| Sales org Sales org Name Distribution channel Distribution channel name Division Division name Existing / New Comments | |
| DE35 PCT DE 00 Standard channel 00 PCT Products Existing | |
| GB30 PCT UK 00 Standard channel 00 PCT Products Existing | |
| IN10 JMCIPL AMOG 00 Standard channel 00 PCT Products Existing | |
| SE33 JM Formox Sweden 00 Standard channel 00 PCT Products Existing | |
| US32 PCT US 00 Standard channel 00 PCT Products Existing | |
| US38 JM PT Savannah 00 Standard channel 00 PCT Products Existing | |
| GB35 Licensing (Paddington UK) 00 Standard channel 00 PCT Products New | |
| NL10 IEBV 00 Standard channel 00 PCT Products New | |
| IN20 JMCIPL PCEO 00 Standard channel 00 PCT Products Existing Not in use | |
| IN30 JMCIPL PGMCAT 00 Standard channel 99 PGM Products Existing Not in use | |
| GB31 PCT Services UK 0 Standard channel 0 PCT Products Existing | |
| GB50 PCT UK Haverton 0 Standard channel 0 PCT Products Existing Not in use | |
| GB51 Pharmorphix 0 Standard channel 0 PCT Products Existing Not in use | |
| US33 Univar 00 Standard channel 00 PCT Products Existing Not in use | |
| US42 Services US 00 Standard channel 00 PCT Products Existing Not in use | |
| US50 StePac USA INC 00 Standard channel 00 PCT Products Existing Not in use | |
| 2.1.9 Assign Sales organization to company code. | |
| Sales organization can assign to only one Company code where the company code can have multiple sales organizations assigned. | |
| Sales Org Sales Org Name Company Code Company code Name Existing / New Comments | |
| DE35 PCT DE DE35 Johnson Matthey Emmerich Existing | |
| GB30 PCT UK GB30 JM PT UK Existing | |
| IN10 JMCIPL AMOG IN10 JMCIPL Amog Existing | |
| SE33 JM Formox Sweden SE33 Johnson Matthey FORMOX AB Existing | |
| US32 PCT US US32 JM PT US Existing | |
| US38 JM PT Savannah US38 JM PT Savannah Existing | |
| GB35 Licensing (Paddington UK) GB35 New | |
| NL10 IEBV NL10 New | |
| IN34 PCT India IN34 Synetix India (CO-PA) Existing Not in use | |
| GB31 PCT Services UK GB30 JM PT UK Existing Not in use | |
| GB50 PCT UK Haverton GB50 Johnson Matthey ACMA Existing Not in use | |
| GB51 Pharmorphix GB30 JM PT UK Existing Not in use | |
| GB90 PCT Haverton PA GB90 Synetix Haverton (CO-PA) Existing Not in use | |
| GB95 PCT Emmerich PA GB95 Synetix Emmerich (CO-PA) Existing Not in use | |
| US33 Univar US32 JM PT US Existing Not in use | |
| US42 Services US US32 JM PT US Existing Not in use | |
| US50 StePac USA INC US32 JM PT US Existing Not in use | |
| 2.1.10 Assign Distribution Channel to Sales Organization. | |
| Distribution channel can be assigned to one or more Sales Organizations. | |
| Sales Org Sales Org Name Distribution Channel Distribution Channel Name Existing/New Comments | |
| DE35 PCT DE 00 Standard channel Existing | |
| GB30 PCT UK 00 Standard channel Existing | |
| SE33 JM Formox Sweden 00 Standard channel Existing | |
| US32 PCT US 00 Standard channel Existing | |
| US38 JM PT Savannah 00 Standard channel Existing | |
| IN10 JMCIPL AMOG 00 Standard channel Existing | |
| GB35 Licensing (Paddington UK) 00 Standard channel New | |
| NL10 IEBV 00 Standard channel New | |
| IN20 JMCIPL PCEO 00 Standard channel Existing Not in use | |
| IN30 JMCIPL PGMCAT 00 Standard channel Existing Not in use | |
| GB31 PCT Services UK 00 Standard channel Existing | |
| GB50 PCT UK Haverton 00 Standard channel Existing Not in use | |
| GB51 Pharmorphix 00 Standard channel Existing Not in use | |
| US33 Univar 00 Standard channel Existing Not in use | |
| US42 Services US 00 Standard channel Existing Not in use | |
| US50 StePac USA INC 00 Standard channel Existing Not in use | |
| 2.1.11 Assign Division to Sales Organization. | |
| Division can be assigned to one or more distribution channels. Division can be assigned to sales organization and multiple divisions assigned to single sales organization. | |
| Sales Org Sales Org Name Division Division Name Existing/New Comments | |
| DE35 PCT DE 00 PCT Products Existing | |
| GB30 PCT UK 00 PCT Products Existing | |
| IN10 JMCIPL AMOG 00 PCT Products Existing | |
| SE33 JM Formox Sweden 00 PCT Products Existing | |
| US32 PCT US 00 PCT Products Existing | |
| US38 JM PT Savannah 00 PCT Products Existing | |
| GB35 Licensing (Paddington UK) 00 PCT Products New | |
| NL10 IEBV 00 PCT Products New | |
| IN20 JMCIPL PCEO 00 PCT Products Existing Not in use | |
| IN30 JMCIPL PGMCAT 99 PGM Products Existing Not in use | |
| GB31 PCT Services UK 00 PCT Products Existing | |
| GB50 PCT UK Haverton 00 PCT Products Existing Not in use | |
| GB51 Pharmorphix 00 PCT Products Existing Not in use | |
| US33 Univar 00 PCT Products Existing Not in use | |
| US42 Services US 00 PCT Products Existing Not in use | |
| US50 StePac USA INC 00 PCT Products Existing Not in use | |
| 2.1.12 Assign Sales Organization Distribution channel to Plant | |
| Plant manufactures the goods and organization sells them in market through different distribution channel. | |
| Sales Organization Distribution channel and plant should be linked with each other. | |
| 2.1.13 Assign Sales Area to Credit Control Area. | |
| Sales Area can be assigned to credit control area. Multiple sales areas can be assigned to one or multiple credit control areas. | |
| Sales Org Distribution Channel Division Credit Control Area Existing/New Comments | |
| DE35 00 00 CR02 Existing | |
| GB30 00 00 CR01 Existing | |
| IN10 00 00 CR05 Existing | |
| SE33 00 00 CR09 Existing | |
| US32 00 00 CR04 Existing | |
| US38 00 00 CR08 Existing | |
| GB35 00 00 CR11 New | |
| NL10 00 00 CR12 New | |
| IN30 00 99 CR07 Existing | |
| IN20 00 00 CR06 Existing | |
| US32 00 00 CR04 Existing | |
| US33 00 00 Existing Not in use | |
| US42 00 00 Existing Not in use | |
| US50 00 00 CR04 Existing Not in use | |
| GB31 00 00 Existing | |
| GB50 00 00 CR03 Existing Not in use | |
| GB51 00 00 CR01 Existing Not in use | |
| 2.1.14 Assign Sales Office to Sales Area. | |
| Sales office can be assigned to Sales Area and Multiple Sales offices can be assign to sales area. | |
| Sales Org Description Distribution Channel Division Sales Office Description Existing/New Comments | |
| DE35 PCT DE 00 00 DE35 PCT DE Existing | |
| GB30 PCT UK 00 00 GB30 PCT UK Existing | |
| IN10 JMCIPL AMOG 00 00 IN01 AMOG - Gurgaon Existing | |
| SE33 JM Formox Sweden 00 00 SE33 JM Formox Sweden Existing | |
| US32 PCT US 00 00 US32 PCT US Existing | |
| US38 JM PT Savannah 00 00 US38 JM PT Savannah Existing | |
| GB35 Licensing (Paddington UK) 00 00 GB35 Licensing New | |
| NL10 IEBV 00 00 NL10 IEBV New | |
| IN20 JMCIPL PCEO 00 00 IN02 PCEO - Taloja Existing Not in use | |
| IN30 JMCIPL PGMCAT 00 99 IN03 PGMCat - Taloja Existing Not in use | |
| US33 Univar 00 00 US33 VWR US (do not use) Existing Not in use | |
| US33 Univar 00 00 VC01 VWR CANADA Existing Not in use | |
| US33 Univar 00 00 VU01 VWR USA Existing Not in use | |
| US42 Services US 00 00 US32 PCT US Existing Not in use | |
| US50 StePac USA INC 00 00 US50 StePac USA INC Existing Not in use | |
| GB31 PCT Services UK 00 00 GB40 PCT Services - UK Existing Not in use | |
| GB31 PCT Services UK 00 00 GB41 PCT Services - Azeri Existing Not in use | |
| GB31 PCT Services UK 00 00 GB42 PCT Services - Aus. Existing | |
| GB31 PCT Services UK 00 00 GB43 PCT Services - Abu D Existing Not in use | |
| GB50 PCT UK Haverton 00 00 GB50 PCT UK Haverton Existing Not in use | |
| 2.1.15 Assign Sales group to Sales office. | |
| Sales group should be assigned to the sales office and multiple sales groups can assign to one sales office. | |
| Due to the number of entries – excel file attached (below) | |
| 2.2 Forecasting | |
| This section covers the following STC Level 3 processes: | |
| • 02.03.02. Perform requirements evaluation – Forecasting. | |
| 2.2.1 Introduction | |
| The current forecasting process within JM CT differs across sites. Commercial account managers maintain a forecast of potential sales by customer and product (material). These forecasts are maintained by three methods: | |
| • an excel spreadsheet is managed off-line and not entered in SAP | |
| • an excel spreadsheet is managed offline and forecasts are manually entered into SAP | |
| • forecasts from within a Lotus Notes database are manually transferred into SAP. | |
| The SAP forecasts are created as Quotation document types. Two different document types are currently used, these being: | |
| • ZFUS - US Forecast | |
| • ZF - JM Forecast | |
| These document types are essentially identical apart from the fact that ZF invokes a simple credit check and issues a warning in the case of credit breach. This will be removed as this is no longer required. | |
| It is assumed, for purposes of this FDD, that the Lotus Notes database and other forecasting tools will be replaced by the Microsoft Dynamics 365 CRM system. Forecasts will be maintained in CRM and interfaced into the JM CT SAP system. The current target date for this is May 2023. Should CRM not be available within the Concert timeframe manual entry of forecast data will continue, as now. | |
| Key JM CT requirements include: | |
| • Provide an E2E solution for CRM, ERP, and demand planning tool | |
| • Standardize the use of forecasts in SAP | |
| • Integrate transfer of forecast data from CRM to SAP | |
| • Integrate transfer of data from SAP to demand planning tool | |
| • Provide a report to check for credit issues on confident and planned forecasts (excluding licensing) in the 3-month window. This would not include a hard stop but just a warning. | |
| • Provide a report on forecast accuracy at order line level for demand managers (not OTIF). | |
| Design Considerations: | |
| • Rationalise and harmonise use of existing quotation document types for purpose of forecast capture in SAP | |
| • Support integration with planned deployment of CRM | |
| • Maintain current functionality to allow creation of QT with reference to the forecast document | |
| • Allow manual entry of forecasts in SAP. | |
| 2.2.2 CRM Interface - Forecasting | |
| The receipt of forecasts from CRM can only be fully specified once the CRM team have determined what they will provide to the interface. The interface build requirement is captured in WRICEF STC_I001 – CRM tool to be integrated with SAP. However, the following design is anticipated: | |
| • Interface will be near real-time | |
| • Interface will be via SAP PO | |
| • IDocs will be used /* ORDERS05 IDoc will be used to trigger a forecast quotation | |
| document in SAP */ | |
| • WE20 partner profiles will be needed for the sending system against which the inbound processing will be specified | |
| • Updates / changes will be supported /* bi-directional or not to be determined in conjunction with the CRM team, beyond the timeframe of this FDD */ | |
| At this point it is felt that IDoc processing is the preferred inbound interface messaging approach. An alternative is to use a bespoke format and process using BAPI BAPI_QUOTATION_CREATEFROMDATA. However, in this case bespoke message handling would be needed. If volumes are relatively low, then this may be an approach worthy of investigation. However, an overriding consideration will be to conform to the overall approach and strategy for integrating CRM with the JM CT SAP system. | |
| It is further assumed at this stage that only CT product forecasts will be received from CRM. In other words, project related Engineering and Licensing forecasts will not be received from CRM and are therefore out of scope for this interface. | |
| Key additional considerations for this interface include: | |
| • Target document type will be rationalised to be solely ZF /* ZFUS no longer used */ | |
| • Number range assignment will be internal in SAP | |
| • The CRM Forecast identifier will be held on the SAP document. This is to facilitate manual creation of forecast in SAP. /* bespoke VBAK Z field */ | |
| Assumptions: | |
| • Customers will exist in CRM with the same identifiers as in SAP – SAP is the master for customer data | |
| • Materials will exist is CRM with the same identifiers as in SAP – SAP is the master for material master data. | |
| Key data to be received via this interface will include (examples only): | |
| • Forecast owner /* Employee number of the Account Manager */ | |
| • CRM forecast number | |
| • Sold-To Customer | |
| • Ship-To Customer | |
| • Material | |
| • Plant | |
| • Industry Code | |
| • Incumbent | |
| • Forecast date | |
| • Sales price / value | |
| • Forecast probability. /* at line-item level */ | |
| 2.2.3 Forecast Documents in SAP | |
| This sub-section outlines a review of the current significant configuration settings with respect to JM CT Forecasting quotation document types, and an indication of the changes that will be made during project Concert. These changes are to support: | |
| • the interface from CRM | |
| • rationalisation and harmonization of the use of these documents within the JM CT SAP system | |
| • support for the parallel work to implement an S&OP process with JM CT SAP. | |
| Document Types: | |
| Sales document types control the system settings that influence the sales process, such as the sales document category (in this case, Quotation), subsequent delivery and billing, etc. | |
| Forecast documents are currently manually created using transaction VA21. These document types are listed in the table below. | |
| Configuration Object Description Existing / New Relevant Site Configuration Source | |
| Sales Document Type ZF - JM Forecast Existing All Sites CT | |
| Sales Document Type ZFUS - US Forecast Existing US32 | |
| US38 | |
| US42 | |
| To be discontinued. See discussion below. | |
| The assignment of number ranges is as follows: | |
| Doc Type NR Internal NR External | |
| ZF 50 90 | |
| ZFUS 51 90 | |
| These number ranges are: | |
| Number Range From To Internal / External | |
| 50 100000 199999 Internal | |
| 51 400000 499999 Internal | |
| 90 9000000 9999999 External | |
| It is proposed that a single forecast quotation type will be used going forward – ZF, and that only number range 50 will be used, i.e., internal number range assignment will be used. The CRM system will have its own number range, and where a forecast is received from CRM, that number will be stored on a new VBAK header field and made available for viewing only on the Header Additional Data B screen. This will be implemented as part of the WRICEF for the quotation interface from CRM. The reason this approach is used is to enable a single forecast document type to be used whether it is loaded via the interface or manually entered in SAP. Note that if the interface is not implemented in a timely fashion, the VBAK header field will be created to allow entry of the external number manually. | |
| Item Categories: | |
| Item categories together with the sales document types represent different business transactions and rules within the SAP system. The item category controls functionality within the initial sales document and in any subsequent processing. | |
| The essential characteristics of an item category determine: | |
| • Whether business data in the item can be different to that of the document header | |
| • Whether pricing applies to the item | |
| • Whether and how an item is billed | |
| • Whether the item refers to a material or whether it is just a text item | |
| • Which incompleteness procedure is used to check the item data. | |
| Item categories assigned to this ZF document type are: | |
| Doc Type Item Category Group Usage Higher Level Item Cat Default Manual Alt | |
| ZF TEXT AGTX | |
| ZF 0002 AGC AGN | |
| ZF 0004 AGN AGC | |
| ZF BANS AGN AGNN | |
| ZF DIEN AGX | |
| ZF DIEN AGN AGX | |
| ZF LEIS AGX ZGNN | |
| ZF LEIS AGN AGX | |
| ZF NLAG AGX ZGXN | |
| ZF NLAG AGN AGX | |
| ZF NORM AGN AGNN | |
| ZF NORM AGC AGX | |
| ZF NORM AGN AGN AGNN | |
| ZF ZNRM AGN AGNN | |
| Entries actually used in current operations are highlighted in Blue. Note that these (and many other SD configuration) tables additionally contain copies of standard configuration that are not used in the current operation of JM CT SAP. Examples include any entry with a Higher-Level Item Category: sub-item functionality is not used within the JM CT forecast model. | |
| No changes are proposed to the current item category configuration. | |
| Note that only AGN, AGNN and AGX are currently used. These are: | |
| • AGN Standard Item | |
| • AGNN Free of Charge Item | |
| • AGX Quotation Item | |
| Relevant Item Category Groups in use are: | |
| • DIEN Service w/ Delivery | |
| • LEIS Service w/o Delivery | |
| • NLAG Non-stock Material | |
| • NORM Standard item - Ord | |
| • ZNRM Standard item - Del | |
| To verify this evaluation a 12-month sample has been taken of all forecast documents created and the usage indicated above has been derived. The purpose of this analysis is to understand the scope of current configuration, as currently used in JM CT, given the materials forecasted and the key data settings on these materials. | |
| Schedule Lines: | |
| Schedule lines contain delivery dates and quantities as well as information about requirements transfer and inventory management. They are a prerequisite for delivering materials. | |
| The use of schedule lines within the JM CT SAP system does not conform to standard SAP usage. For example, Forecast documents (actually document types with Document Category B – Quotation) determine Schedule Lines as documented below. | |
| Across both quotation document types the following Schedule Line Categories are currently used: | |
| • BN No MRP | |
| • BT No inventory mgmt. | |
| • CP MRP | |
| Figure 1 - Schedule line category BN – JM CT SAP System | |
| Figure 2 - Schedule line category BT – JM CT SAP System | |
| Figure 3 - Schedule line category CP– JM CT SAP System | |
| Note that Schedule line category CP has been changed, when compared to the standard settings, in the JM CT SAP system. The availability checking flag (TVEP-ATPPR) and product allocation flag (TVEP-QUOTA) have both been deactivated. | |
| Schedule Line determination is configured as shown below. | |
| Item Cat MRP Type Sched Line Manual | |
| AGN BN BP | |
| AGN ND BN | |
| AGN PD CP BN | |
| AGN VB BV | |
| AGN VM BV | |
| AGN VV BV | |
| AGNN BN BP | |
| AGNN ND BN | |
| AGNN VB BV | |
| AGNN VM BV | |
| AGNN VV BV | |
| AGX BT | |
| A check of the materials used show the following MRP Types are used: | |
| • ND No planning | |
| • P1 MRP, fixing type -1- /* no entry so “blank” used */ | |
| • P3 MRP, fixing type -3- /* no entry so “blank” used */ | |
| • PD MRP | |
| • Y0 MPS without PTF /* no entry so “blank” used */ | |
| • Y3 MPS with PTF (Manual firming) /* no entry so “blank” used */ | |
| From this we can determine that the only schedule line determination currently being used, for forecasting are those highlighted in blue. | |
| Item Cat MRP Type Sched Line Manual | |
| AGN BN BP | |
| AGN ND BN | |
| AGN PD CP BN | |
| AGN VB BV | |
| AGN VM BV | |
| AGN VV BV | |
| AGNN BN BP | |
| AGNN ND BN | |
| AGNN VB BV | |
| AGNN VM BV | |
| AGNN VV BV | |
| AGX BT | |
| Whilst changes to the above configuration would have been necessary to support the adoption of ATP, no change to schedule line configuration will be made. The current usage of Item Categories and Schedule lines will remain as-is. | |
| In summary, forecasting quotation document types will now consist of: | |
| • A single document type – ZF | |
| • Number range will be NR 50 – 100000 – 199999 | |
| • Item categories AGN, AGNN and AGX | |
| • Schedule line categories CP, BN and BT | |
| • Simple credit checking will be removed | |
| • A “Z” field will be added to header table VBAK to capture the CRM (or otherwise external) forecast document number. | |
| The impact on reporting, of rationalizing forecasting to a single document type, will be considered as necessary. | |
| Copy control will be updated as needed, depending upon any changes made to Quotation processing, below. | |
| Copying of forecasts to quotations is an optional step; the closure of forecasts through quotation reference is standard processing; because reference by quotation is an optional step, then rejection of no longer relevant forecast items is expected to continue as now. | |
| It is proposed to block the creation of ZFUS document types. This will be implemented by setting the TVAK-SPERR (Sales Document Block) indicator to X – “The sales document type is blocked”. Testing has confirmed that this will prevent the creation of new ZFUS quotations but will not prevent editing of existing forecast quotations. This change will impact any use of this document type outside of the JM CT organisation scope and should be communicated accordingly. | |
| No changes are anticipated to pricing beyond anything required to support the introduction of a statistical reference base price. | |
| Complex legacy text procedures will remain unchanged. | |
| Posting to credit management open items will be removed from forecasting item categories by unchecking the Credit Relevant indicator. | |
| Document type ZF will be assigned for use by the new Consolidation site sales areas – reference configuration item “Assign sales order types permitted for sales areas”. | |
| 2.2.4 Forecast Accuracy Reporting | |
| The STC BPD has captured the following requirement: | |
| • Provide a report on forecast accuracy at order line level for demand managers (not OTIF) | |
| WRICEF catalogue item STC_R005 logs this as a report on forecast accuracy at order line level for demand managers. | |
| This WRICEF will be fully elaborated in the Functional Specification that will be written during Realisation. The primary business purpose of the report is to provide a backwards looking evaluation of the accuracy of Account Manager demand forecasts in the light of actual sales. The purpose of this is to iteratively improve the quality of forecasting over time. Key elements of the report are noted below. | |
| An additional criteria will include a tolerance factor or KPI. As forecasts are never completely accurate it will be possible to specify a forecast tolerance KPI. The Evaluation Report will indicate which materials where within or outwith the tolerance criteria; this will enable a focus on problematic material forecasts. | |
| The Architecture Review has observed that once the S&OP process is fully in place this report will require amendment to use the outputs of the S&OP process itself – the Planned Independent Requirements – as the forecast source data for this report. The report will be developed with this planned change in mind. | |
| Selection Screen: | |
| This report will have a wide range of selection criteria. These will accept user parameters to supply default values. | |
| Ranges of input values will be provided as per SAP standard. | |
| Where possible, match codes will be provided as help for selection field population. | |
| Selection variants will be supported. | |
| Key selection criteria will include: | |
| • Sales Area /* Sales org, DC, Div */ | |
| • Forecast Date range /* line-item Planned Delivery Date */ | |
| • Document Type /* ZF, plus any others included in the forecast */ | |
| • Account Manager /* New Partner function ZC – Account Manager */ | |
| • Sold-To | |
| • Material | |
| • Industry Segment /* VBAP-MVGR5 */ | |
| • Price | |
| • Probability | |
| • Tolerance /* V0.97 following review */ | |
| • Plant. | |
| Results Screen: | |
| Results will be formatted in the form of a standard ALV screen. | |
| This will list all matching forecast documents matching the selection criteria above. | |
| This will include for each document and line item: | |
| • Forecast document header and line-item data /* schedule lines if needed – TBD */ | |
| • Follow on QT document header and line-item data /* schedule lines if needed – TBD */ | |
| • Follow on Order document header and line-item data /* schedule lines if needed – TBD */ | |
| • At line-item level a traffic light indicator showing degree of accuracy. | |
| A download option will be provided to export the report to Excel as per standard ALV functionality. | |
| Issue: Not all QTs and orders are created with reference to a forecast document. How this is dealt with will be agreed upon during detailed design of the report. One possibility is to list apparently “un-forecasted” sales that otherwise match the selection criteria with reference to the “Emergency Order” indicator – see below. | |
| Evaluation Report: | |
| In addition to the line-item results screen that allows the user to delve into matching transactional data a summary report screen will be available via an option in the selection screen. | |
| This will select all forecast data matching the selection criteria and will be summarised by a set of selectable criteria including: | |
| • Material | |
| • Industry Segment /* VBAP-MVGR5 */ | |
| • Customer | |
| • Plant | |
| • Others TBD | |
| Minimum criteria will be Material. | |
| Actual orders within the forecast period will be summarised by the same criteria and a traffic light assigned indicating the degree of forecast accuracy. | |
| A download option will be provided to export the report to excel as per standard ALV functionality. | |
| 2.2.5 Forecast Credit Outlook Reporting | |
| The STC BPD has captured the following requirement: | |
| • Provide a report to check for credit issues on confident and planned forecasts (excluding licensing) in the 3-month window. Report to include Quotations where required. | |
| The WRICEF catalogue captures this as a report identify customers, with a confident or planned probability for a forecast or quote with a delivery date in the next 3 months, having a credit block. WRICEF reference is STC_R003. | |
| A copy of the current spreadsheet used is included here for reference. | |
| Key attributes of this report, as requested by the business include: | |
| • Customer account Number (Credit Master for grouped accounts) | |
| • Account Manager | |
| • Customer Name | |
| • Credit Limit | |
| • Credit Status | |
| • List of forecasts (confident/planned) and when planned for | |
| • Total value of forecasts in GBP. | |
| Selection Screen: | |
| This report will have a wide range of selection criteria. These will accept user parameters to supply default values. | |
| Ranges of input values will be provided as per SAP standard. | |
| Where possible, match codes will be provided as help for selection field population. | |
| Selection variants will be supported. | |
| Selection criteria will include: | |
| • Organisation | |
| • Customer | |
| • Forecast / Quotation Dates | |
| • Document type | |
| • Probability | |
| • Credit Status | |
| Results Screen: | |
| Results will be formatted in the form of a standard ALV screen. | |
| Download to excel will be available. | |
| A list of matching documents will be presented, grouped by the credit master record. | |
| Forecast / quotation values will be provided and an evaluation with regard to the credit status will be provided. | |
| A detailed design will be created and presented in the report Functional specification developed during Realisation. | |
| 2.3 Quotation Processing | |
| This section covers the following STC Level 3 processes: | |
| • 02.03.03. Prepare and monitor sales proposals/bids | |
| • 02.03.04. Prepare and monitor sales quotation | |
| 2.3.1 Introduction | |
| Quotations are created within the current JM CT SAP system. Commercial quotations are sent to a customer for the purpose of listing the price of goods or services offered to a customer. Account managers maintain a quotation by customer and product (material). These quotations are currently maintained by two methods: an excel spreadsheet that is managed on SharePoint; or quotations from within a Lotus Notes database that are manually transferred into SAP. Three different document types are used, these being: | |
| • QT - JM Quotation | |
| • ZQUS - US Quotation | |
| • ZQ - JM Quotation | |
| These document types are essentially identical apart from the fact that QT and ZQ have a solely external number range assignment and the users manually enter the same number used in the Lotus Notes quotation application. | |
| Key JM CT requirements include: | |
| • Provide an E2E solution for CRM, ERP, and demand planning tool. | |
| • Standardize the quotation process in SAP | |
| • Integrate transfer of quotation data from CRM to SAP | |
| • Provide a single source of commercial data. | |
| Design Considerations: | |
| • Reversion to SAP standard quotation processing to the greatest extent possible | |
| • Facilitate use of standard SAP reports | |
| • Rationalise and harmonise use of existing quotation document types for purpose of quotation and proposal capture in SAP | |
| • Support integration with planned deployment of CRM | |
| • Maintain current functionality to allow creation of the ZQ quotation with reference to the forecast document | |
| • Allow manual entry of quotations and proposals into SAP. | |
| 2.3.2 CRM Interface - Quotations | |
| The receipt of quotations from CRM can only be fully specified once the CRM team have determined what they will provide to the interface. However, the following design is anticipated: | |
| • Interface will be near real-time | |
| • Interface will be via SAP PO | |
| • IDocs will be used /* ORDERS05 IDoc will be used to trigger a quotation document in SAP */ | |
| • WE20 partner profiles will be needed for the sending system against which the inbound processing will be specified | |
| • Updates / changes will be supported /* bi-directional or not to be determined | |
| in conjunction with the CRM team, beyond the timeframe of this FDD */ | |
| It is assumed that both CT product quotations and project related Engineering and Licensing quotations (known as proposals) will be received from CRM. If required, it will be possible to link the proposal quotation line item to a billing WBS in the project, but only after the Proposal quotation is received from CRM. | |
| Key additional considerations for this interface include: | |
| • Target document type for products will be rationalised to be ZQ /* QT & ZQUS not used */ | |
| • A new quotation document type for project related quotations will be created as a copy of ZQ – ZQP – JM Project Quotation | |
| • Number range assignment will be internal in SAP | |
| • The CRM Quotation identifier will be held on the SAP document. This is to facilitate manual creation of quotations in SAP. /* bespoke VBAK Z field */ | |
| 2.3.1 Quotation Documents in SAP | |
| This sub-section outlines a review of the current significant configuration settings with respect to JM CT quotation document types, and an indication of the changes that will be made during project Concert. These changes are to support: | |
| • the interface from CRM | |
| • rationalisation and harmonization of the use of these documents within the JM CT SAP system | |
| • support for the parallel work to implement an S&OP process with JM CT SAP (alongside forecast quotation documents) | |
| Sales document types control the system settings that influence the sales process, such as the sales document category (in this case, Quotation), subsequent delivery and billing. | |
| Document Types: | |
| Quotation documents are currently manually created using transaction VA21. These document types are listed in the table below. | |
| Configuration Object Description Existing / New Relevant Site Configuration Source | |
| Sales Document Type QT - JM Quotation Existing All Sites | |
| DE35 | |
| GB30 | |
| IN10 | |
| IN20 | |
| IN30 | |
| SE33 To be discontinued. See discussion below. | |
| Sales Document Type ZQ - US Quotation – Rename to JM CT Quotation Existing All Sites CT | |
| Sales Document Type ZQUS - US Quotation Existing US38 To be discontinued | |
| Sales Document Type ZQP - JM Project Quotation New GB35, SE33 Copy of ZQ | |
| The assignment of number ranges is as follows: | |
| Doc Type NR Internal NR External | |
| QT -- 05 | |
| ZQ -- 52 | |
| ZQUS 51 90 | |
| These number ranges are: | |
| Number Range From To Internal / External | |
| 05 200000 299999 External | |
| 51 400000 499999 Internal | |
| 52 500000 599999 External | |
| 90 9000000 9999999 Internal | |
| It is proposed that a single quotation type will be used for product quotations – ZQ. Additionally, a new quotation type will be created for project based quotations – ZQP. In both cases number range 51 will be used, i.e., internal number range assignment will be used. The CRM interface will have its own number range, and where a quotation is received from CRM, that number will be stored on a new VBAK header field and made available for viewing only on the Header Additional Data B screen. This will be implemented as part of WRICEF STC_I001 implementing the quotation interface from CRM. The reason this approach is used is to enable the same quotation document type to be used whether it is loaded via the interface or manually entered in SAP. | |
| Output determination will be left unchanged. | |
| It is recommended that all open quotations that have expired should be rejected (i.e., closed out) to support the use of standard reporting transactions. The current proposal is that quotations one year beyond their validity end data are closed out by rejection. | |
| Item Categories: | |
| Item categories together with the sales document types represent different business transactions and rules within the SAP system. The item category controls functionality within the initial sales document and in any subsequent processing. | |
| The essential characteristics of an item category determine: | |
| • Whether business data in the item can be different to that of the document header | |
| • Whether pricing applies to the item | |
| • Whether and how an item is billed | |
| • Whether the item refers to a material or whether it is just a text item | |
| • Which incompleteness procedure is used to check the item data. | |
| Item categories assigned to this ZQ document type are: | |
| Doc Type Item Category Group Usage Higher Level Item Cat Default Manual Alt | |
| ZQ TEXT AGTX | |
| ZQ 0002 AGC AGN | |
| ZQ 0004 AGN AGC | |
| ZQ BANS AGN AGNN | |
| ZQ DIEN AGX | |
| ZQ DIEN AGN AGX | |
| ZQ LEIS AGX ZGNN | |
| ZQ LEIS AGN AGX | |
| ZQ NLAG AGX | |
| ZQ NLAG AGN AGX | |
| ZQ NORM AGN AGNN | |
| ZQ NORM AGC AGX | |
| ZQ NORM AGN AGN AGNN | |
| ZQ ZNRM AGN AGNN | |
| Entries actually used in current operations are highlighted in Blue. Note that these (and many other SD configuration) tables additionally contain copies of standard configuration that are not used in the current operation of JM CT SAP. Examples include any entry with a Higher-Level Item Category: sub-item functionality is not used within the JM CT quotation processing model. | |
| No changes are proposed to the existing item QT document type category configuration. As quotation document type ZQP will be created as a copy of ZQ, all dependant configuration will be copied and will apply accordingly to the new quotation document type. In addition, it is anticipated that a new Item Category that supports a Billing Plan will be added to quotation document type ZQP. This will be a manual alternative. | |
| Note that only AGN, AGNN, ZGN, ZGX and AGX are currently used. These are: | |
| • AGN Standard Item | |
| • AGNN Free of Charge Item | |
| • AGX Quotation Item | |
| • ZGN Standard Item | |
| • ZGX Syn QT Val Item | |
| Relevant Item Category Groups in use are: | |
| • DIEN Service w/ Delivery /* minimal usage */ | |
| • LEIS Service w/o Delivery | |
| • NLAG Non-stock Material | |
| • NORM Standard item - Ord | |
| • ZNRM Standard item - Del | |
| To verify this evaluation a 12-month sample has been taken of all quotation documents created and the usage indicated above has been derived. The purpose of this analysis is to understand the scope of current configuration, as currently used in JM CT, given the materials quoted and the key data settings on these materials. | |
| Where a setting on a currently unused item category needs updating in line with changes to the “used” item categories, this will be included in the planned changes to be made. | |
| Default Item Category Settings: | |
| Key Item Category configuration settings, are shown below: | |
| Figure 4 – Relevant Item Category settings | |
| Key items to consider are: | |
| • Billing block at line-item level /* remove as not needed */ | |
| • Incompletion procedure /* no change planned */ | |
| • Credit active. /* Simple credit check with warning will be retained | |
| as requested by the business */ | |
| The text procedure, 90, will be left unchanged. | |
| Schedule Lines: | |
| Schedule lines contain delivery dates and quantities as well as information about requirements transfer and inventory management. They are a prerequisite for delivering materials. | |
| The use of schedule lines within the JM CT SAP system does not conform to standard SAP usage. For example, determine Schedule Lines as documented below. | |
| Across all three quotation document types in the JM CT SAP system, the following Schedule Line Categories are currently used: | |
| • BN No MRP | |
| • BT No inventory mgmt. | |
| • BV Consumption MRP | |
| • CP MRP | |
| Figure 5 - Schedule line category BV | |
| Note: The other relevant schedule line categories are shown in the preceding section. | |
| Current Schedule line determination is shown below. Only determination lines of the relevant (i.e., currently used) Item Categories are included. | |
| Item Cat MRP Type Sched Line Manual | |
| AGN BN BP | |
| AGN ND BN | |
| AGN PD CP BN | |
| AGN VB BV | |
| AGN VM BV | |
| AGN VV BV | |
| AGNN BN BP | |
| AGNN ND BN | |
| AGNN VB BV | |
| AGNN VM BV | |
| AGNN VV BV | |
| AGX BT | |
| ZGN BN BP | |
| ZGX BT | |
| As with Forecasting, above, a check of the materials used show the following MRP Types are used: | |
| • ND No planning | |
| • P1 MRP, fixing type -1- /* no entry so “blank” used */ | |
| • P3 MRP, fixing type -3- /* no entry so “blank” used */ | |
| • PD MRP | |
| • Y0 MPS without PTF /* no entry so “blank” used */ | |
| • Y3 MPS with PTF (Manual firming) /* no entry so “blank” used */ | |
| From this we can determine that the only schedule line determination currently being used for quotations are those highlighted in Blue. | |
| Item Cat MRP Type Sched Line Manual | |
| AGN BN BP | |
| AGN ND BN | |
| AGN PD CP BN | |
| AGN VB BV | |
| AGN VM BV | |
| AGN VV BV | |
| AGNN BN BP | |
| AGNN ND BN | |
| AGNN VB BV | |
| AGNN VM BV | |
| AGNN VV BV | |
| AGX BT | |
| ZGN BN BP | |
| ZGX BT | |
| Whilst changes to the above configuration would have been necessary to support the adoption of ATP, no change to schedule line configuration will be made. The current usage of Item Categories and Schedule lines will remain as-is. | |
| In summary, forecasting quotation document types will now consist of: | |
| • A single document type – ZQ | |
| • Number range will be NR 51 – 400000 – 499999 Item categories AGN, AGNN, AGX, ZGN and ZGX | |
| • Schedule line categories BN, BT, and BV – no availability check and no transfer of requirements | |
| • Simple credit checking will be retained at the request of Sweden | |
| • A “Z” field will be added to header table VBAK to capture the CRM forecast document number. | |
| As for Forecasts, the impact on reporting, of rationalizing quotations to a single document type, will be considered as necessary. | |
| Copy control will be updated as needed, depending upon any changes made to sales order processing, below. | |
| It is proposed to block the creation of QT and ZQUS document types. This will be implemented by setting the TVAK-SPERR (Sales Document Block) indicator to X – “The sales document type is blocked”. Testing has confirmed that this will prevent the creation of new QT and ZQUS quotations but will not prevent editing of existing quotations. This change will impact any use of these document types outside of the JM CT organisation scope and should be communicated accordingly. | |
| Posting to credit management open items will be removed from relevant item categories by unchecking the Credit relevant indicator. | |
| Document types ZQ and ZQP will be assigned for use by the new Consolidation site sales areas, and any existing ones where it is not already set. The relevant configuration item for this is “Assign sales order types permitted for sales areas”. | |
| No changes are anticipated to pricing beyond anything required to support the introduction of a statistical reference base price. | |
| Complex legacy text procedures will remain unchanged. | |
| The report for forecast credit outlook will be designed to be flexible enough to include quotations as an option (by document type). | |
| 2.4 Sales Order Processing | |
| This section covers the following STC Level 4 processes: | |
| • 02.04.01. Perform sales order processing | |
| • 02.04.01.01 Create Customer order | |
| • 02.04.01.02 Create order confirmation | |
| • 02.04.01.04 Create sales order with billing plan / down payment | |
| • 02.04.01.05 Create sales order with project | |
| • 02.04.01.07 Create Sales Order for Intercompany Debit | |
| 2.4.1 Introduction | |
| This functional area encompasses the creation of sales orders within JM CT for the sales of goods / services and the various checks that take place in accordance with JM policy and guidelines. The JM CT SAP system is a mature application within which many sales order processes are supported. To illustrate this, the following sales document types are currently in use:** | |
| • CR Credit Memo Request | |
| • DR Debit Memo Request | |
| • RE Returns | |
| • ZDOM JMCIPL Domestic Ord | |
| • ZEXF JMCIPL Exp FOC Order | |
| • ZEXP JMCIPL Export Order | |
| • ZP JM Formox Plant Proj | |
| • ZR JM Customer Order | |
| • ZRFX Formox Cust Order | |
| • ZRUS US Customer Order | |
| • ZS Sundry Sales Order | |
| • ZSER JMCIPL Service order | |
| Note: Only currently used sales order types will be assigned for use within the new Consolidation sites unless a requirement to do otherwise is identified. | |
| ** Elaborated further, below. | |
| Key JM CT requirements include: | |
| • Cross Business Unit harmonization | |
| • Roll-out to Consolidation sites | |
| • Real-time visibility of pending orders in SAP reports | |
| • Improved order confirmation output | |
| • Email output updates to support onward transmission of email to the customer | |
| • Rationalizing and moving towards use of standard SAP reports to support sales activities | |
| • Identification of emergency orders | |
| o A report is needed to review these orders | |
| • Use of Partner Function to represent the account manager | |
| • Use of Billing Plans and Down-payment functionality. | |
| Design Considerations: | |
| • Adoption of SAP standard sales order processing wherever this has been identified by a scope item requirement | |
| • Use of standard SAP reports | |
| • Maintenance of existing processing wherever change has not been identified – do not introduce regression errors into current processing | |
| • Integration with Forecasting, Quotation processing and demand management. | |
| 2.4.2 Sales Orders in SAP | |
| This sub-section outlines a review of the current significant configuration settings with respect to JM CT sales order document types, and an indication of the changes that will be made during project Concert. These changes are to support: | |
| • roll-out of existing (used) document types to the consolidation sites | |
| • support for specific scope item improvements identified withing the scope of sales order processing. | |
| Document Types: | |
| Sales orders are manually created using transaction VA01, either with or without reference to a preceding document. The document types in use are listed in the table below. In use has been determined by taking a two-year download of all sales documents with category C through L. | |
| Configuration Object Description Existing / New Relevant Site Configuration Source | |
| Sales Doc Type CR - Credit Memo Request Existing DE35 | |
| GB30 | |
| GB31 | |
| GB51 | |
| IN10 | |
| SE33 | |
| US32 | |
| US38 | |
| US34 | |
| GB35 | |
| NL10 | |
| GB40 CT | |
| Sales Doc Type DR - Debit Memo Request Existing DE35 | |
| GB30 | |
| IN20 | |
| SE33 | |
| US34 | |
| GB35 | |
| NL10 | |
| GB40 CT | |
| Sales Doc Type RE - Returns Existing DE35 | |
| GB30 | |
| IN10 | |
| IN20 | |
| SE33 | |
| US32 | |
| US38 | |
| US34 | |
| GB35 | |
| NL10 | |
| GB40 | |
| CT | |
| Sales Doc Type ZDOM - JMCIPL Domestic Ord Existing IN10 | |
| IN20 | |
| CT | |
| Sales Doc Type ZEXF - JMCIPL Exp FOC Order Existing IN10 CT | |
| Sales Doc Type ZEXP - JMCIPL Export Order Existing IN10 | |
| IN20 | |
| CT | |
| Sales Doc Type ZP - JM Formox Plant Proj Existing SE33 CT | |
| Sales Doc Type ZR - JM Customer Order Existing DE35 | |
| GB30 | |
| SE33 | |
| GB35 | |
| NL10 | |
| GB40 | |
| CT | |
| Sales Doc Type ZRFX - Formox Cust Order Existing SE33 CT | |
| Sales Doc Type ZRUS - US Customer Order Existing US32 | |
| US38 | |
| US34 | |
| CT | |
| Sales Doc Type ZS - Sundry Sales Order Existing GB30 | |
| GB31 | |
| GB51 | |
| US34 | |
| GB35 | |
| NL10 | |
| GB40 | |
| CT | |
| Sales Doc Type ZSER - JMCIPL Service order Existing IN10 CT | |
| We need to agree which doc types are to be used by each Consolidation site. | |
| It is planned that the credit and debit memo request document types will be used for the purpose of arms length intercompany financial reconciliation. An example would be where Davy wish to charge Corp on a cross-company code managed project. Reference process is 02.04.01.07 Create Sales Order for Intercompany Debit. | |
| The assignment of number ranges is as follows: | |
| Doc Type NR Internal NR External | |
| CR 13 14 | |
| DR 15 16 | |
| RE 13 14 | |
| ZDOM 01 02 | |
| ZEXF 01 02 | |
| ZEXP 01 02 | |
| ZP 01 02 | |
| ZR 01 02 | |
| ZRFX 01 02 | |
| ZRUS 53 02 | |
| ZS 70 02 | |
| ZSER 01 02 | |
| These number ranges are: | |
| Number Range From To Internal / External | |
| 01 300000 399999 Internal | |
| 02 5000000 5999999 External | |
| 13 60000000 64999999 Internal | |
| 14 65000000 69999999 External | |
| 15 70000000 74999999 Internal | |
| 16 75000000 79999999 External | |
| 53 600000 699999 Internal | |
| 70 700000 799999 Internal | |
| No changes to sales document types used or their number ranges is proposed, apart from the following: | |
| • Retire use of sales document type ZP - JM Formox Plant Proj | |
| • New sales document type ZPRJ – JM Projects Order. | |
| Item Categories: | |
| Item categories together with the sales document types represent different business transactions and rules within the SAP system. The item category controls functionality within the initial sales document and in any subsequent processing. | |
| The essential characteristics of an item category determine: | |
| • Whether business data in the item can be different to that of the document header | |
| • Whether pricing applies to the item | |
| • Whether and how an item is billed | |
| • Whether the item refers to a material or whether it is just a text item | |
| • Which incompleteness procedure is used to check the item data. | |
| Item categories used are shown below, by document type. | |
| Sales Document | |
| Type ItCat ItCat ItCat ItCat ItCat ItCat ItCat ItCat ItCat ItCat | |
| RE REN | |
| ZDOM ZAN ZIN ZINA | |
| ZEXF TANN | |
| ZEXP TANN ZAS ZEX ZTAS | |
| ZP ZPP | |
| ZR TAN TANN TAX ZAD ZADD ZAN ZAW ZFOC ZGXN ZTNN | |
| ZRFX ZFW | |
| ZRUS TAD TAN TANN TAO TAX ZAN ZAW ZFOC | |
| ZS ZAD ZAN ZAW | |
| ZSER ZSER | |
| The determination of the item category is primarily controlled by sales document type and Item Category Group. The following Item Category Groups are used: | |
| • DIEN | |
| • LEIS | |
| • NLAG | |
| • NORM | |
| • ZNRM | |
| Unless specified below, to support a specific functional update, item category determination will remain unchanged. | |
| Schedule line determination will be discussed below. | |
| 2.4.3 General Sales Order Updates | |
| Some common updates have been identified that will be applied to the relevant sales document types. These comprise: | |
| • Identify emergency orders | |
| o Master data team requested a new field be created rather than repurposing an existing field | |
| o A report is needed to review these orders | |
| • Discontinue use of Sales Group field to capture the identity of the relevant Account Manager | |
| • Correct the use of Free Of Charge items so that users no longer need to add a nominal price such as £0.01 | |
| • Add support for Third Party order processing to support the PFR drop ship process. | |
| Emergency Orders: | |
| JM CT requires the ability to flag a sales order (in its entirety) as an Emergency order. These are orders that were not in the forecast or otherwise anticipated; the flag will also be used to indicate where a forecast date has been brought forward. | |
| A number of solutions to this requirement are possible. | |
| Index Option Evaluation | |
| 1 New sales document type Only a good solution if additional functionality, such as immediate delivery creation, is needed. Also, would need to be able to change the document type. Discounted. | |
| 2 Re-purpose existing field. Customer group 1 (VBAK- KVGR1) and Customer group 2 (VBAK- KVGR2) have already been used. KVGR3 would be the obvious choice here. 12/05/22: The JM CT Solution Architect has agreed with the Master Data team that this is the preferred option. | |
| 3 Create a new VBAK Z field. Add a new field to VBAK–ZZEMERGENCY_ORDER. | |
| This meets the functional requirement but is not selected option. | |
| Following review with the JM CT Solution architect, Option 2 is now the preferred solution. The exact list of values for this field will be agreed during Realisation. | |
| This field will be available for reporting by use of the new Sales Order Processing Workbench report described below. | |
| Account Manager: | |
| The account Manager is currently captured in an organisation structure field – VBAK-VKGRP. | |
| Figure 6 – Account Manager as Sales Group | |
| The requirement, captured in the BPD, is to discontinue this use and replace it with a partner function. | |
| Currently, used partner functions based on the Employee record are shown below. | |
| Figure 7 – Employee Partner functions in current use | |
| It is therefore proposed to create a new partner function ZC - Account Manager as a copy of the VE Sales Employee and add that to the relevant partner determination procedure. | |
| All relevant sales document types are assigned to Partner Determination Procedure TA - Standard Order. The new ZC partner function will be added to this procedure. | |
| It will be necessary to ensure that Account Managers are loaded to table PA0001 so that they are available to enter as the ZC Account Manager in the sales order. This has been agreed with the data team. | |
| Additionally, the Sales Group will be removed from the order header incompletion procedures: | |
| • 11 - Standard Order | |
| • 14 - Credit Memo | |
| • 15 - Debit Memo | |
| • Z1 - Formox - Plant Proj | |
| • Z3 - Formox - Load.Serv. | |
| It will not be possible to make the new partner mandatory without affecting all open sales orders created before cut-over, so this will be left optional, for now. | |
| No changes will be made to the historic open sales orders and only the new sales orders will follow the new process. | |
| The impact on reporting, of changing the system location of the Account Manager, will be considered as necessary. | |
| Free Of Charge Items: | |
| Currently, FoC items are priced at £0.01 because the settings on the pricing procedure make the entry of a price mandatory – even when using item category TANN. | |
| This will be resolved by: | |
| • Taking the mandatory flag off the pricing procedures | |
| • Adding Net Value as a mandatory item in the non-FoC item categories. | |
| Third Party Order Processing – PFR Drop-Ship: | |
| Third Party Order Processing is discussed in the STP BPD, which provides business background to this requirement, where it is used and labelling requirements, etc. | |
| SAP standard Third Party order processing will be used to support this requirement, generally, and specifically to support the direct delivery of PFR Catalyst. | |
| The standard Item Category for this process is TAS - Third Party Item. Whilst we would usually create a local copy of this, in case of changes to default configuration, a CT local copy of this has already been created – ZTAS - 3rdParty FreightServ. This will be left as is. | |
| The design intent is to use the standard TAS item category, unchanged from default settings – whilst noting the allocation of a bespoke item text procedure – 90 - Synetix Sales Item. | |
| The default Item Category Group BANS will be used to make this the default choice, and we will ensure that it is also a manual alternative to relevant materials, such as those flagged as Item Category Group NORM. | |
| This will apply to all relevant document types, including ZR - JM Customer Order. It will not apply to sales document type ZEXP which uses the ZTAS - 3rdParty FreightServ item category. | |
| The business will determine the default Item Category Group for each material, sales area and plant combination; in other words, they will decide whether drop ship or consolidation is the default processing option. | |
| New Sales Document Type ZPRJ | |
| A new Quotation document type for Proposals has been agreed; this is ZQP - JM Project Quotation, and a corresponding new sales order type ZPRJ - JM Project Order. Copy control will be maintained accordingly. | |
| This document type will be based upon the existing sales document type ZR - JM Customer Order, and will support the use of Billing Plans as discussed below. By basing this document type upon ZR, functionality in addition to billing plans and WBS assignment will be supported. | |
| Integration with OneSource for US Tax Calculation: | |
| Given the complexity of multiple Jurisdictions in the US, JM CT have decided to follow the Unify approach and adopt OneSource Tax Engine to address the tax reporting requirements. Data from the CT SAP system will be sent to OneSource tax engine via an Interface which will be set-up between the two systems (See WRICEF RTR_I003 for Interface details). | |
| Sales transactions will ‘call’ OneSource for a tax decision. For each transaction OneSource determines which tax (Sales/Use Tax) is applied, the amount of tax and the authorities to whom tax is owed. Once this is established OneSource returns the tax authority name, rates and the tax amounts back to SAP system. | |
| The Interface is triggered by the SAP Tax Code on the document lines. | |
| Figure 8 – SAP SD and OneSource Integration Schematic | |
| To support this integration the following updates will additionally be required: | |
| • Creation of five VOFM pricing routines: | |
| o Collecting data and calling Determination (non-group process) [RV64A990] | |
| o Update tax condition with tax data (non-group process) [RV64A991] | |
| o Collecting line tax data (group process) [RV64A992] | |
| o Calling Determination (group process) [RV64A993] | |
| o Update tax condition with tax data (group process) [RV64A994] | |
| • SD User exits in: | |
| o MV45AFZZ | |
| o RV60AFZZ. | |
| These coding updates are documented in the OneSource Installation Guide, below. | |
| In addition the following config elements are relevant: | |
| • Sales and Distribution/Basic Functions/Pricing/Pricing Control/Define Access Sequences | |
| • Sales and Distribution/Basic Functions/Pricing/Pricing Control/Define Condition Types | |
| • Sales and Distribution/Basic Functions/Pricing/Pricing Control/Define And Assign Pricing Procedures | |
| • Sales and Distribution/Basic Functions/Taxes/Define Tax Determination Rules | |
| • Sales and Distribution/Basic Functions/Taxes/ Define Tax Relevancy Of Master Records | |
| The UNIFY SD configuration in this area will be used as a guide. | |
| Full configuration is documented in the OneSource configuration guide, below. | |
| Assign Sales Area To Sales Document Types: | |
| This configuration option is not mandatory, but once activated it must be fully and consistently populated. There are a number of sub-options: | |
| Figure 9 – Assign Sales Area To Sales Document Types | |
| It is proposed that, when adding the new sales organisations, the current settings are reviewed to ensure they are consistent in approach. In other words, combinations are consistent, and assignments reflect the combinations appropriately. | |
| 2.4.4 Billing Plans & Down-Payments | |
| It is intended to use Billing Plans where a regular, periodic or milestone related invoice should be raised. Currently, this is manually managed by using separate billing lines in the sales order, although it is noted that the US38 business has attempted minimal use of the functionality, mainly for the supply of loaders. | |
| Where Project related, the billing plan can be generated with reference to the billing milestones in the project. However, as Project Managers need to manage the release of the billing blocks, in order to ensure all contractual and documentation requirements are in place, the billing plan will be manually created in the sales order. Reference to a project is not mandatory for the use of billing plans. | |
| Milestone billing will additionally be used to manage down payment processing. A down payment is made by a customer in advance of receiving the goods or services for which they have a commercial agreement with JM CT. The decision on whether a down payment is required rests with the Commercial Team and is made before the commercial agreement is finalized. | |
| It is intended to utilize standard SAP billing plan and down payment functionality going forward. | |
| Configuration Considerations: | |
| Item Categories: | |
| Standard Item Category for Billing Plans is TA0 - Milestone billing. | |
| Current item category determination is shown below. | |
| SaTy ItCGr Usg. ItemCat-HighLevItem DfItC | |
| ZP 0005 TAO | |
| ZR 0005 TAO | |
| ZRFX 0005 TAO | |
| ZRUS 0005 TAO | |
| ZS 0005 TAO | |
| Figure 10 – Current Item category determination | |
| Item Category Group 0005 is defined as “Milestone Billing” in SAP standard but has been renamed to “Partial Billing” in the JM CT SAP system. Whilst it is not recommended to change standard SAP setting or objects, this will be left as-is. | |
| Item Category TAO is defaulted to a Make to Order requirement type by the following standard configuration setting. | |
| Sales and Distribution> Basic Functions> Availability Check and Transfer of Requirements> Transfer of Requirements> Determination Of Requirement Types Using Transaction | |
| Figure 11 – Assignment of Requirement Type to TAO | |
| This setting conflicts with the need to assign a WBS element as it removes the field from the sales document line items. | |
| As this is a JMCT requirement, Item Category TAO will be copied to ZTAO – JM Milestone Billing. All necessary settings will copy, and the above entry will be deleted for ZTAO. | |
| A new Item Category Group Z005 – JM Milestone Billing will be created, and the entries above will be replicated / replaced as needed following copying of the item. That will ensure that materials created with Item Category Group Z005 will determine Item Category ZTAO as required. A check has been made of materials in the JM CT system and none have Item Category Group 0005. The only TAO items created have been manually selected where the Item Category Group is ZNRM. This configuration will be left in place so that existing sales documents are unaffected. | |
| Billing Plan Type: | |
| The current Milestone Billing plan type is 01 – Milestone Billing. This will be copied to Z1 – JM Milestone Billing, | |
| Figure 12 – Milestone Billing Plan Type 01 – Source for Z01. | |
| No change planned to Date Descriptions. | |
| Only a single Default Date Category can be assigned to a Billing plan Type. | |
| Default is 01 - Milestone Billing. | |
| Figure 13 – Milestone Billing Date Category 01. | |
| Note the default billing type will be updated from Blank to F2, the standard invoice type. | |
| Where a down payment is required this must be manually changed, by the user setting up the billing plan, to FAZ – Down Payment Request. | |
| Figure 14 – Example order with Down Payment Request Line | |
| A new Billing Block Z1 – Milestone Open will be created and assigned to the Date Category shown above. The rationale for this is that it makes it clear to the business why the billing plan line item remains blocked for billing. | |
| Sales Documents: | |
| A request has been made to support header level billing plans. Billing Plan Z1 will be assigned to sales document types: | |
| • ZR JM Customer Order | |
| • ZRFX Formox Cust Order | |
| • ZRUS US Customer Order | |
| • ZS Sundry Sales Order | |
| • ZPRJ JM Project Order /* new order type */ | |
| Where sales documents are project related, these will be account assigned to the Billing WBS element in the sales document line-item field. | |
| GL Account Determination: | |
| Overall, no requirement to change the current GL Account determination has been identified during the requirements gathering phase of the project. However, the need to support revenue recognition for project related sales orders and invoices is noted. These invoices need to post revenue to a Deferred Revenue GL Account – 18700000 - Deferred Revenue SVA. To support this the existing Material Account Assignment Group value, ZP – Plant Projects, will be used and assigned to the service materials used for project related billing. | |
| During Realisation we must ensure that, for every sales organisation intending to post to this account, that the account is created in the corresponding company code. For example, it is anticipated that this will be used by GB30, yet the account currently does not exist in the GB30 Company code. | |
| No change is planned to the GL Account Determination Procedure or access sequences. It will suffice to create the appropriate entries in table 0001 of the GL Account Determination Procedure. This design decision is dependent upon service materials being exclusively used for Project related revenue recognition relevant transactions only, within a given sales organisation. The rationale for this is that we will use the Material Account Assignment Group field to determine revenue account. The current GL Account Determination tables are shown below. | |
| Figure 15 – GL Account Assignment tables | |
| 2.4.5 Output Determination | |
| WRICEFs STC_F002 - Update Orders confirmation (BA00) layout - Single layout to be adopted by CT and also F001 - Update to order confirmation e-mail and title, have been raised to provide for updates to, and standardisation of the order confirmation output, and addition of an email title and boilerplate text to order confirmation emails generated from SAP. | |
| It remains with the business to specify which of the current output types will be replaced by a single updated BA00. | |
| The current output types available within output determination procedure V10000 are: | |
| • ESYM Internal Output | |
| • BA00 Order Confirmation | |
| • MAIL Internal Output | |
| • KRML Credit Processing /* internal Credit Management email message */ | |
| • ZIEP JMCIPL Exp Proforma | |
| • ZSAV Additives email | |
| • ZA00 Additives ord.conf. | |
| • ZA01 FORMOX Order Conf. | |
| • ZA10 ACT order confirm. /* no longer used as business has been sold */ | |
| BA00 will be replaced by the new standard order confirmation output type ZBA0 – JM CT Order Confirmation. | |
| Access sequence will be new – Z902 comprising: | |
| • Sales Organization/Order Type | |
| • Sales Org. | |
| This replaces Z901 comprising: | |
| • Sales Org/Doc Type/Sales Group /* sales group no longer used */ | |
| • Sales Organization/Order Type | |
| • Sales Org. | |
| BA00 and all other rationalised outputs will be removed. | |
| ZA10 will similarly be removed. | |
| Note that updates to the output type, inclusion of standard T&Cs and email enhancements will be documented in the appropriate functional specifications. Note that the standard T&Cs will be held in an SO10 Standard Text and will be printed on the reverse of the order confirmation. | |
| 2.5 Monitoring Sales Orders | |
| This section covers the following STC Level 3 processes: | |
| • 02.04.02 Monitor sales orders | |
| 2.5.1 Introduction | |
| Monitoring tools are used to track the status of sales orders in the system to provide early detection of issues that could result in increased collection time and increased working capital. This process comprises the periodic and ad hoc process of checking the status of open sales orders. The aim of the process is to ensure: | |
| • Open orders are delivered on time and in full | |
| • Identification of orders where delivery on time may be an issue | |
| • Identification of incomplete sales orders | |
| • Identification of sales orders blocked for delivery | |
| • Identification of sales orders blocked for billing. | |
| Orders identified will be expedited or otherwise updated to enable the completion of the next step in the sales process. | |
| JM CT Requirements: | |
| • Validate customer pricing versus price list and report variances | |
| • Rationalize and move toward standard SAP reports | |
| • Improve on time in full (OTIF). | |
| 2.5.2 Order blocked due to incompletion | |
| Check if the sales order is blocked. Identify the type of block that has been set automatically or manually on the sales order, by running a standard SAP transaction, so that the subsequent resolution for the issue can be determined. | |
| 1) To identify the sale order which is blocked due to incompletion or order is incomplete SAP Standard report VA06 can be used by checking the specific Processing Status – Incomplete. | |
| 2) The report can be filtered based on Sales document type, Sales org, Created on/by, Plant, Material, Vendor etc. | |
| Figure 16 – Sales Order Monitor | |
| 3) Incompletion log assignment to Sales Document type; | |
| Sales Doc Type Sales Doc Description Incompletion procedure Description | |
| CR Credit Memo Request 14 Credit Memo | |
| DR Debit Memo Request 15 Debit Memo | |
| RE Returns 14 Credit Memo | |
| ZDOM JMCIPL Domestic Ord 11 Standard Order | |
| ZEXF JMCIPL Exp FOC Order 11 Standard Order | |
| ZEXP JMCIPL Export Order 11 Standard Order | |
| ZF JM Forecast 60 Inquiry/Quotation(K) | |
| ZFUS US Forecast 60 Inquiry/Quotation(K) | |
| ZP JM Formox Plant Proj Z1 Formox - Plant Proj | |
| ZQ US Quotation 60 Inquiry/Quotation(K) | |
| ZQUS US Quotation 60 Inquiry/Quotation(K) | |
| ZR JM Customer Order 11 Standard Order | |
| ZRFX Formox Cust Order Z3 Formox - Load.Serv. | |
| ZRUS US Customer Order 11 Standard Order | |
| ZS Sundry Sales Order 11 Standard Order | |
| ZSER JMCIPL Service order 11 Standard Order | |
| 4) Incompletion log assignment to sales document items. | |
| Item Category Item Cat Description Incompletion procedure Description | |
| G2N Request 21 Credit/Deb.Memo Item | |
| G2W Request 28 Value Item | |
| L2N Request 21 Credit/Deb.Memo Item | |
| L2W Request 28 Value Item | |
| REN Standard Item 20 Standard Item | |
| TAD Service 28 Value Item | |
| TAN Standard Item 20 Standard Item | |
| TANN Free of Charge Item 24 Free of Charge Item | |
| TAO Milestone-Bill.Plan 20 Standard Item | |
| TATX Text Item | |
| TAX Non-stock Item 25 Service Item | |
| ZAD Syn. Service 25 Service Item | |
| ZADD Syn. F.O.C. Service 26 Free of Charge Serv. | |
| ZAN Std Item OR billing 20 Standard Item | |
| ZAS Third Party Item-JM 28 Value Item | |
| ZAW Syn Non-stk value it 28 Value Item | |
| ZEX JMCIPL Export item 20 Standard Item | |
| ZFOC FOC Item (Del-Rel ) 24 Free of Charge Item | |
| ZFW Formox NLAG Value it Z2 Formox - Value Item | |
| ZGNN Syn QT Ser FOC Item 26 Free of Charge Serv. | |
| ZIN JMCIPL Standard Item 20 Standard Item | |
| ZINA JMCIPL Freegood char SI Sample Item | |
| ZPP FX Plant Pr Value it Z4 Formox - Plant Proj | |
| ZSER JMCIPL Service 28 Value Item | |
| ZTAS 3rdParty FreightServ 28 Value Item | |
| ZTNN FX FoC(no inv split) 24 Free of Charge Item | |
| Since we are rationalising the order type and item category as discussed in the above section, incompletion log assignment and definition need to be reviewed once finalised. Specific changes, where they are needed, have been noted above. | |
| Sales document types that will no longer be used, also as noted above, will be blocked for further users. | |
| 5) Below is the structure of incompletion log 11 - Standard | |
| Figure 17 – Define Incompletion log | |
| 6) If the block is due to Incomplete Order, complete the missing data in the sales order using VA02. | |
| 2.5.3 Release Delivery Block | |
| Delivery Blocks are either manually or automatically applied to sales documents. If the order is delivery blocked due to down payment awaiting funds, then the block would need to be removed manually once the Down payment is received. The Accounts Receivable team would need to confirm receipt of payment first. | |
| The block is removed only via authorized users and only after necessary confirmation has been received. | |
| 1) Below are the Delivery Blocks currently configured in the system, No change is expected. | |
| Figure 18 – Delivery Blocks | |
| Delivery blocks 01 – 08 are SAP standard, whereas 09 and 99 are JM specific. | |
| 2) Identify the sales order having Delivery Block using SAP Standard report V.14 or VA14L | |
| 3) We can filter based on Sales org, document type etc. | |
| Figure 19 – Sales Documents blocked for delivery | |
| 2.5.4 Release Billing Block | |
| The block is removed only via authorized users and only after necessary confirmation has been received. Please note that Credit Debit Memo requests are handled separately via the Credit Debit Process because these need to be authorized by the appropriate Approver in line with JM’s DoA Policy. | |
| 1) Below are the Billing Block Configured in the system, no change is expected. | |
| Figure 20 – Billing Block Reasons | |
| 2) Identify the Billing block in the Sales document using SAP Standard report V.23 | |
| 3) We can filter the content based on sales org, created by/on, sales document number etc. | |
| Figure 21 – Release Sales Order for Billing | |
| 4) The block is removed only via authorised users and only after necessary confirmation has been received. | |
| 2.5.5 Sales Order Monitor - To be Changes | |
| The relevant scope items for this process are: | |
| • Target pricing validation | |
| • Emergency order flag indicator for reporting | |
| • Reports to support sales processes | |
| 2.5.5.1 Target pricing validation | |
| There is a requirement to implement statistical pricing and a report to highlight variance from actual. | |
| Requirement for new condition type ZLIS (statistical) which will be further used to capture variance in reporting. | |
| • Validate customer pricing versus price list and report variances. | |
| • The requirement to capture statistical price (ZLIS) in the pricing procedure will be determined in the sales transaction. | |
| • | |
| • The condition will be determined automatically based on the condition records maintained. | |
| • Implementation of statistical pricing and a report to highlight variance from actual. | |
| • A report will be built against the statistical condition and the net value to capture the variance – WRICEF reference STC_E001 | |
| • If pricing is maintained a statistical condition type will be populated to record this price. The purpose is to support downstream reporting. | |
| Detail configuration steps Please refer to section 2.9.9 - Perform Pricing Administration | |
| 2.5.5.2 Emergency order indicator for reporting | |
| JM CT requires the ability to flag a sales order (in its entirety) as an Emergency order. This indicator will be used for reporting and by the export to S&OP process. | |
| The Emergency Order Indicator will be implemented using VBAK-KVGR3, with a limited range of values to be agreed during Realisation; these will classify the nature of the emergency order. The business has expressed a requirement to distinguish between “true” emergency orders and those that are brought forward due to other reasons. The field will be visible on the Header Additional Data B tab. This meets the functional requirement and is the selected option. | |
| Detail design please refer to section 2.4.3 General Sales Order Update. | |
| This field will be available for reporting by use of the new Sales Order Processing Workbench report described below. | |
| 2.5.5.3 Reports to support sales processes | |
| Following are the reports requirements which are in -scope: | |
| New Requirement - | |
| • A report on forecast accuracy at order line level for demand managers – WRICEF reference STC_R005 | |
| • A report to identify customers, with a confident or planned probability for a forecast or quote with a delivery date in the next 3 months, having a credit block STC_R003 | |
| • A report to identify inactive customers for annual customer master data review – WRICEF reference STC_R004 | |
| • Create sales reports to provide crucial information to support Customer Service work – WRICEF reference STC_R002 | |
| • Support of Variance in pricing to Target pricing. Adding control in the process and saves mime - STC_E001 | |
| A bespoke report (ZSOMS) that will include sufficient details to identify whether there is a potential supply problem for the order. Analyse/ Review the data in the report to view the current order position (has Production or Logistics Execution been performed), current billing status etc. After an analysis of the report, it may be required to expedite the order to meet the delivery date. This report will include hotspots to allow editing of Quotations, sales orders etc. In addition action buttons will be provided, for example, one allowing a call to CO09 to examine the supply situation for a sales document line item. | |
| The impact on reporting, of rationalizing forecasting to a single document type, will be considered as necessary. | |
| Whilst the design intent is to use standard SAP reports to the greatest extend possible, it is recognised that key bespoke reports will continue to be used, in addition to standard reports. | |
| Monitoring sales orders is a key process to ensure the business achieves on-time delivery in full. The table below lists the currently known list of commercial reports used. | |
| Index Report Description Output File Name | |
| 1 MCRS extract for Lotus Notes upload MCRS 11_120721 | |
| 2 Sales/end-user/country/year A7 | |
| 3 Batting list to be discussed with production Batting List - 15.07.21 (TG – variant Batting List) | |
| 4 Q4 List (Q4 - variant (IB Download)) Quote history Q4 (2001-2099) 08.07.21 | |
| 5 AA – BJC01 PURASPEC 2443M | |
| 6 AA Despatches Report AA Report GB30 IN10 US32 | |
| 7 Download PA Line Items for Pivot Table – A complete download of all the transactions, characteristics, and value fields SQ01L10621 | |
| 8 SD SALES FORECASTS/QUOTES/ORDERS REPORT SQ01ZB0621 | |
| 9 SAP Document Details – Specific layout to determine industry group linked to sales order based on sales doc KR SQ01ZZ0621 | |
| 10 PA Analysis KE24SplitVal0621 | |
| 11 Compared to the MCRS report to see if margins are as expected KE30 | |
| 12 EO uses for monthly reporting, Jennifer uses it for history AN Flexible Global Sales Report | |
| 13 Monthly AMOG download JT report | |
| 14 Month end reports - Forecasts/Quotes/Orders ZR-13 US38 Sales Report RAA | |
| 15 Month end reports SQ01 ZC w/ variant "Batches-US38) | |
| 16 Notification of order confirmation Automatic emails of order confirmation from SAP | |
| 17 US38 RAA is from a transaction is my version of ZR13 | |
| Used for forecasts and has look ups to fill in full sales manager name US38 RAA 15072021 | |
| 18 Forecasts, month-end sales Call Reporting Tree – Ref Additives’ (transaction ZR13) | |
| 19 Month-end ZZMAC078 with variant US38 within System – Services – Reporting (transaction SA38) | |
| 20 Monthly Target Collection Report ZAR_OI_ANALYSIS | |
| 21 Sales analysis SQ01, user PW, variant L1 | |
| 23 Used to create monthly margin analysis, | |
| this is the basis for Tableau data PA Download June 2021 | |
| 24 Used for monthly report on bin surcharges (A custom layout is set up to show freight condition breakdown) SQ01-TX - SD Billing Document Details Report with Conditions | |
| 25 NEW ORDERS REC'D IN THE MONTH SQ01, ZR14, Report O1 | |
| User PW | |
| 26 CA Customer master data SQ01, Report CA, User PW | |
| 27 Sales org customer info SQ01, Report ZUS38_SALEORG User PW | |
| 28 TG BATTING ORDER SQ01, Report TG, User PW | |
| 29 OPEN ORDERS AT A POINT IN TIME SQ01, Report UM, User PW | |
| 30 SALES DOCS WITHOUT VSDE OR VPRS DEDUCTION VSDE DEDUCTIONS - US38 | |
| VPRS DEDUCTIONS - US38, Report GB, User PW | |
| 31 BATCH MEMO TEXT FROM SALES ORDER/DELIVERY US38 DOCS, Report 20, User PW | |
| 32 NEW ORDERS ENQUIRY US38 NEW ORDERS, Report O1, User PW | |
| 33 ORDERS CHANGED IN PERIOD US38 NEW/CHANGED DOCUMENTS Report O5, User PW | |
| 34 Sundry Sales Documents By Customer, Cost Centre AR INVOICE/CREDIT NOTES-US38 | |
| Report DA, User PW | |
| 35 List Blocked Billing Documents VFX3 | |
| 36 S4 BILLING DOCUMENTS IN MONTH TO DATE BY INDUSTRY US38 SALES INVOICES | |
| Report S4, User PW | |
| 37 CREDIT NOTES List of Credit notes -US38, Report D3, User PW | |
| 38 SD BILLING DOCUMENT DETAILS REPORT US38 BILLING DOCS, Report ZA, User PW | |
| 39 S2 BILLING DOCUMENTS AND COMMISSION CONDITIONS COMMISSION PARTNERS-US38, Report GD, User PW | |
| 40 Output Docs SD Distribution Papers printing ZS12 | |
| 41 Indirect Acty Alloc. Plan: Overview | |
| TCode CPCC | |
| 42 Display Stock/Requirements Situation Tcode MD04 | |
| 43 SD Order Info Print Tcode ZS11 | |
| 44 Batch details | |
| Program -ZZMAC040 | |
| 45 Stock listing ZZMAC044 | |
| 46 OTIF Data re Deliveries ZZPLW003 | |
| 47 ICI KATALCO - DELIVERY NOTES GOODS ISSUED BUT NOT BILLED ZKTS040P | |
| 48 Haulier Despatches Reports ZZMAC086 | |
| 49 DELIVERIES - STATUS ZZMAC044 | |
| 50 Order Book Statistical Summary Report ZKTS068P | |
| 51 PRICING UPDATE REPORT - OPEN ORDERS/FORECASTS PRICING UPDATE REPORT - OPEN ORDERS/FORECASTS | |
| Report A6, User PW, Variant DETAILS | |
| 52 ORDERS DESPATCHED IN THE MONTH BY PAYMENT TERM ORDERS DESPATCHED BY PAY TERM | |
| BLANK PAYMENT TERMS -GB30/US32 | |
| Report O2, User PW, Variant AXRG610 and AXRG611 | |
| 53 S2 BILLING DOCUMENTS IN MONTH TO DATE SALES INVOICES MONTH TO DATe | |
| Report S2, User PW, Variant INVOICES | |
| 54 TH REGULATORY AFFAIRS BATTING LIST TH REGULATORY AFFAIRS BATTING LIST, Report TH, User PW, Variant EXUS32 and TOUS32 | |
| 55 MJREPORT MJREPORT, Report TH, User PW, Variant CUMDESP and FORCASTDESP | |
| 56 Release Billing Documents for Accounting | |
| BILLING DOCS NOT PASSED TO FI | |
| Program RVFAKSPE, Variant RVFAKSPEV01 | |
| 57 JM Contract Query P5 Contracts, Report P5, User MM, Variant DE35 | |
| 58 MONTHLY FORECASTS ENQUIRY MONTHLY QUOTE/FORECAST - PS | |
| MONTHLY QUOTE/FORECAST - PR | |
| MONTHLY QUOTE/FORECAST – UL | |
| Report TE, User PW, Variant POSSIBLES | |
| PROBABLES, UNLIKELY | |
| 59 NEW QUOTES/FORECASTS/ORDERS IN PERIOD ORD/QT/FC IN MONTH TO DATE | |
| Report TZ, User PW, Variant 20070108 070742, 20070108 071826 and AXR01121 | |
| 60 QUOTE HISTORY SQ01, Report Q4, User PW | |
| 61 ORDERS CHANGED IN PERIOD NEW/CHANGED DOCUMENTS Report O5, User PW, Variant CHANGES | |
| AXRG600, Report O3, User PW, Variant AXRG600 | |
| QUOTES, Report Q1, User PW, Variant QUOTES | |
| 62 SUMMARY OF ORDERS & QUOTES BY YEAR BY INDUSTRY SEGMENT | |
| ORDERS/QUOTES BY IND. BY MONTH | |
| Report S1, User PW, Variant AXRG632 | |
| AXR01171, Report TK, User PW, Variant AXR01171 | |
| 63 SD BILLING DOCUMENT DETAILS REPORT WITH CONDITIONS SD BILLING DOCUMENT DETAILS REPORT WITH CONDITIONS | |
| Report TX, User PW, Variant AXM0122 | |
| QUOTES Report TY, User PW, Variant QUOTES | |
| 64 K1 DOCUMENT CHANGES DETAILS NEWQUOTES Report Q6, User PW, Variant NEWQUOTES | |
| 65 SQVI – ZACTFOREC Used for downloading actual figures to our forecast access db | |
| 66 SQVI – ZKONV Used for downloading actual figures to our forecast access db | |
| 67 SQVI – ZORDSE33 Used for updating of KPi data | |
| 68 CUSTOMER RETURNS IN PERIOD CUSTOMER RETURNS - US32 | |
| Report TO, User PW, Variant AXRK190 | |
| 69 QUOTATIONS ISSUED IN THE MONTH (UC) | |
| QUOTES/F'CASTS IN PERIOD - USA | |
| Report UC, User PW, Variant QUOTESUSA | |
| 70 LOST BUSINESS IN THE MONTH (UD) | |
| LOST BUSINESS IN PERIOD - US32 | |
| Report UD, User PW, Variant LOSTBUS | |
| 71 Imminent delivery list (Batting list) | |
| SQ01, Report G5, User PW | |
| 72 EMMERICH SOP SPREADSHEET UPLOAD QUERY ZR08, Report GA, User PW | |
| There are some changes expected or may get encountered due to requirement objects; | |
| • SALES ACCOUNT MANAGER REPORT DIRECTORY | |
| • Rationalisation of Forecast and QT doc types | |
| • New org structures – sales org, company code, plant etc | |
| Below are the reports which may get impacted; these will be reviewed as necessary during Realisation. | |
| Index Report Description Output File Name Changes Expected due to changes in - | |
| 1 Budget Report (Sales) Z Program "ZKTS060P" Sales Org, Company Code – Report has sales org, company code, Customer info | |
| 2 Order Book Statistical Summary Report Z Program "ZKTS068P" Sales Group | |
| 3 SD SALES FORECASTS/QUOTES/ORDERS REPORT ZR99 ZB Ouery Name PW - Reporting Sales Document and Sales Group | |
| 4 SALES/DEDUCTIONS FOR SALES & EXP. SALES - DE35 ZR99 Report G9 User PW Sales Document and Sales Group | |
| 5 NET REVENUE/GM FOR SALES & EXP. SALES ZR99 Report G8 User PW Sales Document and Sales Group | |
| 6 SD BILLING DOCUMENT DETAILS REPORT ZR99 Report ZA User PW Billing document type, Fright Condition, Sales Org. | |
| Used for reporting actual sales/invoices for reporting to Commercials and Finance. Also used for reporting statistics sales to Swedish Central Bureau of Statistics | |
| New Req - include a column of the actual amount of pure catalyst (pure catalyst | |
| 7 Sales Order document printing Program ZZMAC059 Layout is different, | |
| 8 Sales org customer info ZR14 Report ZUS38_SALEORG User PW Sales Group(Account manager) - Report contain customer, BP, sales org, partner function, Account group and address | |
| 9 SALES & EXP. SALES BY SALES ORG/OWNER/CTRY/YEAR/STATUS ZR14 Report A1 User PW Sales Org, Sales document, status, sales group (Account manager) | |
| Used for keeping track of actual sales/received orders for reporting to Commercials and Finance | |
| New Req - include a column of the actual amount of pure catalyst (pure catalyst products and mixtures products). | |
| 10 MCRS extract for Lotus Notes upload MCRS 11_120721 Account Manager | |
| 11 Sales/end-user/country/year A7 Sales Group(Account manager) and sales document type - Report contain customer, BP, sales org, partner function, Account group and address | |
| 12 Batting list to be discussed with production Batting List - 15.07.21 (TG – variant Batting List ) Sales Document and Sales Group(Account manager) – Batting list | |
| 13 Q4 List (Q4 - variant (IB Download)) Quote history Q4 (2001-2099) 08.07.21 Sales Document and Sales Group(Account manager) – Quote History | |
| 14 AA – BJC01 PURASPEC 2443M Sales Document and Sales Group(Account manager) – Sales and exp sales showing product name as ordered | |
| 15 AA Despatches Report AA Report GB30 IN10 US32 Sales Document and Sales Group(Account manager) – Sales and exp sales showing product name as ordered | |
| 16 Download PA Line Items for Pivot Table – A complete download of all the transactions, characteristics and value fields SQ01L10621 Report with Sales Group (Account manager) | |
| 17 SD SALES FORECASTS/QUOTES/ORDERS REPORT SQ01ZB0621 Sales Group (Account manager) - SD sales forecasts/quotes/orders report | |
| 18 SAP Document Details – Specific layout to determine industry group linked to sales order based on sales doc KR SQ01ZZ0621 Sales Group (Account manager) – SAP Document Details | |
| 19 PA Analysis KE24SplitVal0621 Report with Sales Group (Account manager) | |
| 20 Compared to the MCRS report to see if margins are as expected KE30 Report with Sales Group (Account manager) | |
| 21 EO uses for monthly reporting, Jennifer uses for history AN Flexible Global Sales Report Report with Sales Group (Account manager) | |
| 22 Monthly AMOG download JT report Report with Sales Group (Account manager) | |
| 23 Month-end reports - Forecasts/Quotes/Orders ZR-13 US38 Sales Report RAA Report with Sales Group (Account manager) | |
| 24 Month-end reports SQ01 ZC w/ variant "Batches-US38) Report with Sales Group (Account manager) | |
| 26 US38 RAA is from transaction is my version of ZR13 Used for forecasts and has look ups to fill in full sales manager name US38 RAA 15072021 Report with Sales Group (Account manager) | |
| 28 Forecasts, month-end sales Call Reporting Tree – Ref Additives’ (transaction ZR13) Report with Sales Group (Account manager) | |
| 29 Month-end ZZMAC078 with variant US38 within System – Services – Reporting (transaction SA38) Report with Sales Group (Account manager) | |
| 30 Monthly Target Collection Report ZAR_OI_ANALYSIS Report with Sales Group (Account manager) | |
| 31 EMMERICH SOP SPREADSHEET UPLOAD QUERY ZR08, Report GA, User PW Report with Sales Group (Account manager) | |
| 32 Sales and Exp. Sales by Document SQ01, Report ZT, User PW Report with Sales Group (Account manager) | |
| 2.6 Credit Management | |
| This section covers the following STC Level 3 processes: | |
| • 02.06.01 Evaluate & Monitor Customer Credit | |
| 2.6.1 Introduction | |
| The Credit Management process analyses the creditworthiness of customers, according to JM CT company policy, and allocates a credit management record accordingly. The aim is to protect JM from the risk of financial loss from non-payment or bankruptcy of a customer. Controls are provided to manage credit risk, reduce bad and aged debt, maximize profitable sales, and improve debt collections, cashflow, and working capital Define Risk Categories. | |
| Sales transactions are checked at: | |
| • Sales document create / change | |
| • Delivery creation | |
| • Post goods issue. | |
| The rules applied at each of these points depends upon: | |
| • Credit Control Area | |
| • Customer risk category | |
| • Transaction being executed. | |
| In essence each sales area has been assigned its own credit control area. No change is required in this design, apart from the creation and assignment of credit control areas to the new consolidation sites being brought onto the JM CT SAP system. This is documented in the organisation structure section and is not repeated here. | |
| During Detailed Design it was agreed that the existing Lotus Notes database would be retained for purposes of credit approval. Processes used in Germany will form the basis for the harmonization of credit management. | |
| 2.6.2 Risk Categories | |
| In order to classify customers according to the risk they represent and also to trigger the relevant credit checks, we must assign a risk category to a customer. This risk category determines which checks the system will carry out when processing transactions in Sales and Distribution. The following Risk Categories are present in the JM CT System. | |
| Conceptually there are two levels of risk identified: | |
| • 010 - Standard Risk customers | |
| • 020 - Possible slow payment by Agent | |
| It is proposed to rename the latter to “High Risk”; this will aid the business understanding that 020 will encapsulate a more restrictive credit check. | |
| Note that Risk Category is further defined by Credit Control area as shown below. | |
| Risk Categories Credit Control Area Risk Categories Description Relevant Sales Org Configuration Source | |
| 010 CR01 Standard Risk customers GB30 JM CT | |
| 010 CR02 Standard Risk customers DE35 JM CT | |
| 010 CR03 Standard Risk customers GB50 JM CT | |
| 010 CR04 Standard Risk customers US32 JM CT | |
| 010 CR05 Standard Risk customers IN10 JM CT | |
| 010 CR06 Standard Risk customers IN20 JM CT | |
| 010 CR07 Standard Risk customers IN30 JM CT | |
| 010 CR08 Standard Risk customers US38 JM CT | |
| 010 CR09 Standard Risk customers SE33 JM CT | |
| 010 CR11 Standard Risk customers GB35 JM CT | |
| 010 CR12 Standard Risk customers NL10 JM CT | |
| 020 CR01 High Risk GB30 JM CT | |
| 020 CR02 High Risk DE35 JM CT | |
| 020 CR03 High Risk GB50 JM CT | |
| 020 CR04 High Risk US32 JM CT | |
| 020 CR05 High Risk IN10 JM CT | |
| 020 CR06 High Risk IN20 JM CT | |
| 020 CR07 High Risk IN30 JM CT | |
| 020 CR08 High Risk US38 JM CT | |
| 020 CR09 High Risk SE33 JM CT | |
| 020 CR11 High Risk GB35 JM CT | |
| 020 CR12 High Risk NL10 JM CT | |
| Figure 22 – Credit Control – Risk Categories | |
| Entries entirely in Blue are new entries for the new consolidation sites in SAP. Amended descriptions are also shown in Blue. | |
| Corresponding entries will be made for assignment of the credit control area to company code, in order to remain consistent with the current JMCT credit control area assignment approach. | |
| 2.6.3 Define Automatic Credit Control | |
| Under this configuration option the actual parameters of the credit control check are specified. | |
| Figure 23 – Credit checks – list of checks | |
| Under this menu option the actual checks themselves are specified by: | |
| • Credit control area | |
| • Risk category | |
| • Credit Group. /* sales order, delivery, PGI */ | |
| Figure 24 – Example credit checking rule | |
| The screenshot above shows an example credit check rule set for CCA 01, standard risk customer in a sales order. | |
| The current rule set used within JM CT is broadly consistent but does exhibit some subtle differences that have been applied either initially or over time. The figure below illustrates this in the case of standard risk sales order checks. | |
| Figure 25 – Current Standard Risk, sales order checks by CCA | |
| Elements of the check that vary have been highlighted. These are: | |
| • Deviation of document value by x % | |
| • Number of days without check | |
| • Credit horizon | |
| • Maximum percentage of overdue open items/customer balance. | |
| These setting will be reviewed with the business during realisation as the settings are very specific and technical and the discussion during the detailed design phase did not achieve this degree of business input or approval. Indeed, discussions during the preparation of this document have shown that, whilst the business has great experience of using credit management from an operational perspective, the details of the checks executed are not fully known. | |
| The approach, during this task will be: | |
| • Harmonise the check settings to the maximum possible extent | |
| • Deviate the settings, by CCA, where the business imperative requires us to do so | |
| • Resolve current unwanted check failures that require credit release | |
| • Use of standard report CHECK_CM to analyse current credit check issues | |
| • Test and update the underlying credit management tables S066 and S067 using standard reports to improve credit data | |
| • Test and perfect the approach to rolling out updated credit settings to QA And Production RVKRED77 and other SAP standard reports TBD | |
| • It is intended that running report RVKRED77 will correct the issue of small, incorrect, balances showing in CM reports. | |
| Note that RVKRED77 will be run , as it does not lock the sales order processing tables. It will be run initially as part of the cut-over to the improved credit management settings, and also when users identify discrepancies that may arise during use of the SAP system. RVKRED88 will also be used as a check report prior to running the update version of the report during BAU operations. | |
| Integration Points: | |
| Delivery blocks are used to prevent delivery of an item to a customer. In addition, they can also block creation of a confirmed quantity These settings will be reviewed during Realisation to confirm whether they fully meet the users’ requirements; particular attention will be paid to the Confirmation Block setting. The key issue here is that Delivery Block 01 will be set in the case of a credit check failure, and requirements will not be transferred to demand management. | |
| Figure 26 – Delivery Blocking Reasons and settings | |
| 2.6.4 Customer Credit Group | |
| These are freely defined groups of customers. For example, these can be by industry sector, by country, or by any characteristic that will help focus credit management processing. Credit representatives can then use these groups to help select credit holds for processing and to generate reports for statistical analysis. | |
| Customer Credit Group file attached. | |
| The business requirement is to rationalise these groups so that they are up to date and correctly assigned. This two-stage process will be carried out during realisation, alongside the refinement of credit checking rules noted above. | |
| 2.6.5 Other Core Configuration | |
| All other core Credit management configuration will be checked for consistency and to ensure new elements introduced elsewhere are fully integrated with the core credit management solution. Items include: | |
| • Define Text IDs for Credit Management /* no change anticipated */ | |
| • Maintain Text IDs for Central Texts in Credit Management /* no change anticipated */ | |
| • Define Credit Representative Groups /* update if needed */ | |
| • Define Credit Representatives /* update if needed */ | |
| • Define Intervals for Days in Arrears in Credit Management /* update if needed */ | |
| • Pricing procedure settings – ensure changes conform as needed | |
| • Item categories /* include new and review existing */ | |
| • Sales document types /* update if needed */ | |
| • Internal mail to credit representatives in case of credit block. | |
| Receivables risk management is regarded as out of scope. | |
| 2.6.6 Credit Reporting | |
| The standard reports noted in the STC BPD will be reviewed and appropriate recommendations made for their best use by the business. In addition, all existing reports that include credit management information will be reviewed as necessary. For a list of standard SAP credit management reports see the BPD – sections 02.06.01 Maintain Customer Credit Master Data and 02.06.01.02 Complete Customer Credit Check. | |
| 2.7 Billing | |
| This section covers the following STC Level 3/4 processes: | |
| • 02.06.02. Perform customer billing | |
| 02.06.02.01 Create Customer Invoice | |
| 2.7.1 Introduction | |
| Billing documents contain billing-relevant data for one or more business transactions. Billing documents are created as the result of the billing process and form the basis of a physical document or electronic file that can be sent to customers. | |
| Types of invoice: | |
| • Customer invoice | |
| • Credit memo | |
| • Debit memo | |
| • Pro forma invoice. | |
| Key JM CT Requirements related to invoice type and process include: | |
| • As a part of harmonization and Improvement, we are going to align the layout of different invoices into a single layout based on business confirmation and requirement | |
| • Support for Down Payment processing will require use of a new invoice type – FAZ - Down Payment Request. This will post to a special general ledger transaction A with an alternative general ledger account. | |
| • Savannah has a requirement to add a bin surcharge to the customer invoice | |
| • WRICEF STC_F003 - Update invoice layout (x3) & FAZ for down payments will implement the requirement for correct VAT wording on invoice layouts. | |
| 2.7.2 Perform Customer Billing | |
| Billing Processing also includes creation of billing documents as per the below reference − | |
| • To a sales order | |
| Order - typically for a service | |
| Reconciled manually | |
| Tax compliance - you should pay taxes on the service. | |
| • To a Delivery | |
| Delivery - typically for goods | |
| More automated | |
| Tax compliance - you should pay taxes on what is delivered. | |
| A Billing document can be created in the following ways − | |
| • Create a billing document explicitly | |
| Currently all sales orgs are creating billing document using VF01 explicitly except that Savannah uses VF04. | |
| • By manually processing from a worklist. | |
| VF04 - just Savannah use as of today | |
| System checks invoices that can be raised | |
| Can combine multiple invoices into one | |
| Can do mass transactions | |
| Not as good for order based since all of them will be included | |
| Can uses status and date to filter | |
| Can use billing blocks. | |
| Propose to have both VF01, VF04 available to create billing document, but encourage to use VF04 as it provides more functionality and ease to create billing documents. | |
| Below are the billing documents which are, and will continue to be, used: - | |
| Billing Document type Description Existing / New Comments Configuration Source | |
| F1 Invoice Existing Order related billing – US38 CT | |
| F2 Invoice Existing Delivery Related billing – All sites CT | |
| F2SM Invoice for stk tran Existing For stock Transfer GB30/IN10 CT | |
| F2SS Sundry Sale Invoice Existing Only GB – Used by finance CT | |
| F5 Pro Forma for Order Existing All sites CT | |
| F8 Pro Forma Inv f Dlv Existing SE33/US38/GB CT | |
| G2 Credit Memo Existing All sites CT | |
| L2 Debit Memo Existing All sites CT | |
| RE Credit for Returns Existing All sites CT | |
| S1 Cancellation of Inv Existing Cancel normal invoice or debit – All sites CT | |
| S2 Cancel of Cred Memo Existing cancel credit memo or return – All sites CT | |
| ZDR JMCIPL Debit Memo Existing Not used CT | |
| ZEXF JMCIPL ExpFOCInvoice Existing Only India CT | |
| ZF8 Pro Forma Inv f Dlv Existing SE33/IN10 CT | |
| ZG2 Commission Credit Existing Not used CT | |
| ZIS JMCIPL Serv Invoice Existing Only India CT | |
| ZJH JMCIPL High Seas Existing Only India CT | |
| ZPP Formox - Plant Proj Existing Only Sweden CT | |
| FAZ Downpayment New All sites | |
| Note that ZPP will no longer be used when sales document type ZP is retired. | |
| Currently below billing types are used and in scope, and their high-level definition and description. | |
| • FI - Order related billing type used with service material. | |
| • F2 – Default Tax invoice type used by all sites and main invoice. | |
| • F2SM – Use with Stock Transfer scenario. | |
| • F2SS - GB30 - Sundry used by finance | |
| Marketing uses this for conferences/supplies | |
| F5 - Proforma Invoice with reference to Order | |
| F8 - Proforma Invoice with reference to delivery- down payment in UK/US/Sweden | |
| Export - US proforma - to review if customer asks but no payment | |
| • G2 - Credit Memo | |
| • L2 - Debit Memo | |
| • RE - Credit for Returns | |
| • S1 - Cancellation of Inv | |
| • S2 - Cancel of Cred Memo | |
| • ZDR - JMCIPL Debit Memo | |
| • ZEXF - JMCIPL ExpFOCInvoice | |
| • ZF8 - Sweden uses as STO to Shanghai | |
| • ZIS - JMCIPL Serv Invoice | |
| • ZJH - JMCIPL High Seas | |
| • ZPP - used for plant projects in Sweden. | |
| Various pricing requirements in billing - | |
| • Freight - Include freight in pricing calculation | |
| - . Requirement is to automate with 3 condition options on invoice for regular freight, surcharge combined with freight, and surcharge and freight separate. | |
| • Tax - Should be added at the sales order, Savannah adds at billing level | |
| 2.7.2.1 Billing Document Number Range - | |
| The SAP System manages Billing as documents. In this step, each transaction is assigned to a number range group. The number range interval is defined for each group. In addition, it is specifying whether the number range is assigned by the user at the time of entry (i.e., externally) or by the system (i.e., internally). | |
| Currently Number range object 19 is used for all the billing document type (RV). For existing and new company codes going forward, the same number range object will continue to be used and extended to the new entities. | |
| Document Type Number Range From To Internal / External | |
| RV 19 90000000 94999999 Internal | |
| 2.7.2.2 Billing Block | |
| The system does not allow the creation of a billing document for a delivery that is blocked for billing in the underlying sales order. When creation of an individual billing document is attempted, the system enters a message in the relevant log. In the case of collective processing of billing documents, the delivery is not included in the billing due list. | |
| In addition, it is possible to block transactions at the customer master data level. | |
| In sales document, the billing block is set at header level and for the individual items: | |
| Billing Block Reason Description Existing / New Comments | |
| 01 Await Dist. release Existing | |
| 02 Compl Confirm Missng Existing | |
| 03 Prices Incomplete Existing | |
| 04 Check Terms of Paymt Existing | |
| 05 Check Terms of Dlv Existing | |
| 08 Check Credit Memo Existing | |
| 09 Check Debit Memo Existing | |
| 10 Service confirmation Existing | |
| 11 Missing Cust PO No. Existing | |
| 2.7.2.3 Collective Billing | |
| When executing collective invoice creation SAP will attempt to combine source documents into a single invoice wherever possible. However, the following fields, for example, will cause a split: | |
| • Different billing dates | |
| • Different Payers | |
| • Different payment terms | |
| • Different payment method, etc. | |
| As of now there is no requirement to capture additional split criteria. | |
| 2.7.2.4 Copy Control Setting | |
| Copy Control is defined as a process in which important transactions in a sales document are copied from one document to other. It consists of routines, which determine the system on how the data is to be copied from a source document to a target document. | |
| Below are existing copy control setting from Sales to Billing, Delivery to Billing and Billing to Sales. | |
| There are lot of copy control links which may not be required going forward. This will be checked and harmonized. | |
| Below is the screenshot at item level from sales (OR) to Billing (F2). | |
| Figure 27 - item level from sales (OR) to Billing (F2). | |
| There will be new copy control settings for billing type FAZ for Downpayment from sales to billing. | |
| 2.7.3 Credit and Debit Memo | |
| Credit memo request is a sales document used in complaints processing to request a credit memo for a customer. If the price calculated for the customer is too high, for example, because the wrong sale prices were used or a discount was forgotten, a credit memo request can be created. | |
| Debit memo request is a sales document used in complaints processing to request a debit memo for a customer. If the prices calculated for the customer were too low, for example, calculated with the wrong scaled prices, a debit memo request can be created. | |
| Both Credit and debit memo request can be blocked so that it can be checked. When it has been approved, the block can be removed. | |
| Blocking reason are explained in section 2.7.2.2. | |
| Key consideration points regarding Credit and Debit memo: - | |
| 1) Credit and Debit can be created with or with reference to original invoice, with reference is preferable as it brings all the related information from the previous document. | |
| 2) Documents will be block for processing after creation. Once approved, the block can be removed manually from requests followed by creation of memos. | |
| 3) Blocks can be reviewed in VFX3. | |
| 4) Release to accounting currently is a two-step process with the invoice first and then release to accounting; it can be one step approval. | |
| Below are the Sales document type used for Credit and Debit process by all sites - | |
| Sales Document Type Description Credit/Debit Comments | |
| CR Credit Memo Request K - Credit All Sites | |
| DR Debit Memo Request P- Debit All Sites | |
| With reference to above document, below billing type (Credit and Debit) will get created. | |
| Billing Type Description Credit/Debit Comments | |
| G2 Credit Memo O - Credit All Sites | |
| L2 Debit Memo P- Debit All Sites | |
| Currently the same number range is used for debit and credit. There is no change here | |
| Number Range From To Internal / External | |
| 19 90000000 94999999 Internal | |
| 2.7.4 Returns Process | |
| Return is where a customer is not satisfied with the product and the business needs to create a return request, based on customer return request. | |
| The complaint is approved, and a credit memo created. This is done when customer wants a refund for the goods. The system creates a credit memo to the customer with reference to the sales order. | |
| Key points regarding returns - | |
| 1) Return can be created with or without reference to original invoice, with reference is preferable as it brings all the related information from the previous document. | |
| 2) Documents will be block for processing after creation. Once approved, block can be removed manually from requests followed by creation of memos. | |
| 3) Blocks can be reviewed in VFX3. | |
| 4) Release to accounting currently is a two-step process with the invoice first and then release to accounting; it can be one step approval. | |
| Below are the Sales document type used for Credit and Debit process by all sites - | |
| Sales Document Type Description Doc Category Comments | |
| RE Returns H - Return All Sites | |
| With reference to above document, below billing type (Credit and Debit) will get created. | |
| Billing Type Description Doc Category Comments | |
| RE Credit for Returns O - Return All Sites | |
| Currently the same number range is used for returns as well as other invoice types. No change to the number range is planned. | |
| Number Range From To Internal / External | |
| 19 90000000 94999999 Internal | |
| Current Order Reasons are shown below. There is no change to CT design, and it is expected that new consolidation sites will use the same order reason codes. | |
| Order Reason Description Existing / New Comments | |
| 001 Commission Existing | |
| 002 Price discrepancy: price was too high Existing | |
| 003 Price discrepancy: price was too low Existing | |
| 004 Guarantee Claim Existing | |
| 101 Poor quality Existing | |
| 102 Damaged in transit Existing | |
| 103 Quantity discrepancy Existing | |
| S01 Services Pre-Contractual work - open Existing | |
| S02 Services Pre-Contractual work - lost Existing | |
| Z01 Licence Fees Existing | |
| Z02 East European Charges Existing | |
| Z03 Maintenance Work Existing | |
| Z04 Consultancy Existing | |
| Z05 Re-Work Existing | |
| Z06 Credit Notes-Withholding Tax On Invoice Existing | |
| Z07 Goods - Steel Drums Existing | |
| Z08 Capital Existing | |
| Z09 Technical Service Fee Existing | |
| Z10 Dispute re expenses Existing | |
| Z11 Euro conversion Existing | |
| Z12 Customer Agreement Existing | |
| Z13 Freight Recovery / Reimbursement Existing | |
| Z14 C Form not submitted Existing | |
| Z15 Non submission of Bank guarantee docs Existing | |
| Z16 Insurance recovery / Payment Existing | |
| Z17 Late payment charges / Interest Existing | |
| Z18 Other recovery / Payment Existing | |
| Z19 Incorrect Product dispatched / Shipped Existing | |
| Z20 Despatched / Shipment to wrong location Existing | |
| Z21 Other as specified Existing | |
| Z22 Spent Catalyst Existing | |
| Z23 WH Tax balance Existing | |
| Z24 Invoice balance Existing | |
| Z99 Sample Sales Existing | |
| No changes to order reasons have been identified. | |
| 2.7.5 Billing Output Types | |
| Once a billing document is created in the system, we can print out the appropriate business document (known in Sales and Distribution (SD) as an output) in the approved format using the generic output functions. For example, when you create an invoice, you can generate the tax invoice.t. | |
| 2.7.5.1 Key JM CT requirements related to invoice forms include: | |
| • As a part of harmonization and Improvement, the layout of different invoices will be aligned into a single layout based on business confirmation and requirement. | |
| • Provide customer specific invoices (Sevierville – maybe just add text?) | |
| - This can be done via adding customer specific text or SO10 Text. | |
| • Provide freight and tax on invoice | |
| • Display origin of goods statement on invoice automatically – this to be reviewed during re-design of the invoice layout and accommodated if possible | |
| • Include tax when applicable on customer invoice | |
| • Also, there are some layouts that are developed in SAP Scripts, going forward these layouts will be re-developed using Adobe forms as part of future proof to support future move to S/4HANA. | |
| Below are the Billing output types currently configured: | |
| Billing Output Type Description Existing / New Comments | |
| RD00 Invoice Existing All sites | |
| ZFI1 Final Invoice ZS12 Existing UK Only | |
| ZFO1 FORMOX Invoice Existing Sweden Only | |
| ZGST JMCIPL GST Invoice Existing India Only | |
| ZPF1 Proforma InvoiceZS12 Existing For Proforma choice | |
| ZUAE Invoice for UAE Existing UK Only | |
| ZIDI JMCIPL Dom Invoice Existing India Only – Not Used | |
| ZIEI JMCIPL Exp Invoice Existing India Only – Not Used | |
| ZIEX JMCIPL Excis Inv. Existing India Only – Not Used | |
| ZIPL JMCIPL Exp Packing Existing India Only – Not Used | |
| ZITX JMCIPL VAT Invoice Existing India Only – Not Used | |
| ZPCL JMI PackingList Cust Existing India Only – Not Used | |
| ZEXL JMI Export Inv.Cust. Existing India Only – Not used | |
| Currently for Output type RD00, we have only access sequence (key combination) i.e., Sales Organization/Billing type to maintain entries. | |
| Figure 28 – Display output and Condition Records | |
| Outputs are maintained with medium ‘1’ – print output, and Dispatch time as ‘Send immediately (when saving the application)’ which will trigger the output as soon as invoice is saved. Commonly used Output type is RD00. | |
| • ZFI1 - users in the UK use transaction ZS12 to print the output, UK emails to self (customer service) and after that send it to customer. | |
| • ZPF1 -ZS12 - if proforma choice | |
| • ZUAE - UK country only | |
| A proposed template (refer to Forms Development - STC_F003) will be developed for invoice layout that will be used for all the countries going forward and reviewed with all the countries to check if their country specific requirement is met. | |
| Some of the requirement from different country that were discussed include: | |
| • Sweden - has contact name in invoice layout, that is required also going forward | |
| • Chicago also has contact name, but it is not populated need to investigate and check for option. | |
| • EU, SE, GE - needs to include a VAT# in invoice layout. | |
| • Chicago – when exporting to SA – need a tax ID in invoice layout. | |
| All the missing information from current layout will be reviewed and try to harmonize as much as possible. | |
| 2.8 Accounts Receivable | |
| This section covers the following STC Level 3 processes: | |
| 02.07.01 Process Accounts Receivable (AR) | |
| 2.8.1 Introduction | |
| The Accounts Receivable process involves processing of the customer receipts, processing collections and managing customer credits. | |
| JM CT Requirements related to processing Accounts Receivable involves: | |
| • Improve the AR Collections process by introducing the dunning procedure. | |
| • Standardising the credit management process for Customer Credit Notes. | |
| • Issuing customer statements to notify the customer of the open items / debt. | |
| 2.8.2 Process Accounts Receivable | |
| Process Accounts Receivable focuses on the recording of payments from customers. Customer payments are received in various forms such as cash, cheque, or electronic bank payments, etc. Once payments are received and processed by the bank, the details of the transaction are included in the daily file sent by the receiving bank. With the introduction of Bank Communication Manager (BCM) all the files will be received and sent to the SAP system via BCM connector. | |
| This section will cover the settings required to be maintained for processing the payments in the SAP system. | |
| 2.8.3 Process Customer Account Clearing | |
| 2.8.3.1.1 House bank | |
| Each bank account that a company code holds is represented by a “House Bank” ID in the SAP system, and every account within a house bank is assigned an account ID. All banking transactions in SAP require a House Bank, and that house bank should be the one that represents the actual bank account that the funds came into or out of. | |
| Using the BCM Connector will impact the file format that we receive from the banks. Each bank will have their own file format and we will be maintaining different file formats to be able to process the statements. | |
| Further details on how to maintain and manage the House Bank and Bank accounts are available in the RTR FDD003 in the below section: | |
| 03.03.03.01.03 – Maintain Bank master data in FDD003 | |
| 2.8.3.1.2 Statement Status | |
| The statement status indicates the status of the bank file that is being processed. Below are the existing standard options available for processing the file. We do not plan to change these under Project Concert, and these will be used across all sites including consolidation sites. | |
| Statement Status Short Description Existing/New | |
| 0 Being Entered Existing | |
| 1 Being Re-Entered Existing | |
| 2 Entered On Existing | |
| 3 Re-Entered On Existing | |
| 4 Being Updated Existing | |
| 5 Deletion Indicator Reset Existing | |
| 7 Incompletely Posted Existing | |
| 8 Completely Posted Existing | |
| 9 Deletion Indicator Set Existing | |
| 2.8.3.1.3 Posting Rule | |
| The posting rules are required to for processing the bank statement. The posting rules determine the document type for each transaction, GL accounts used for each transaction type and the debit and credit posting keys. Currently there are 145 posting rules available for processing the statement, which include both SAP standard and bespoke rules. | |
| Existing rules will be utilised. New Posting Rules will be established only if new Bank file formats are not compatible with the existing rules or if the bank introduces new requirements (ex. new transaction type) to the file format. | |
| If the consolidation Company Codes are not compatible with existing Posting Rules for processing the transactions, new Posting Rules will be created. This information will be established during realisation. | |
| 2.8.3.1.4 Automatic account determination | |
| Automatic account determination is maintained for processing of the bank statements. The setting is required when the bank files are processed, and the documents are posted to the bank Clearing GL accounts as maintained in the automatic account determination settings. As the GL is assigned to the House Bank master data the settings are expected to be the same across all the company codes which use the House Bank account. | |
| Bank GL Accounts will be created and assigned to the Bank Account IDs for the Consolidated sites, new Company Codes and for Germany as they have a new Bank account set-up in process. The GL accounts will be updated for the automatic postings and extended for the new company codes where applicable. | |
| The new bank G/L accounts will be defined during the build phase and the associated configuration will be maintained in the system. | |
| 2.8.3.1.5 Automatic clearing rules | |
| Automatic clearing rules determine the fields used in the document for clearing purpose. For Ex, When clearing a customer document, the program looks for the customer number and matches the invoice and receipts for clearing. If the customer numbers do not match the next criteria will be searched. You can maintain 5 search criteria for the clearing purpose. | |
| The automatic clearing rules are currently maintained but are expected to be updated during the realisation phase, when the bank GL Accounts have been finalised and depending upon the search criteria required for the automatic clearing of the GLs. This configuration will be maintained for all company codes including the consolidation company codes. | |
| Once the payment file is processed successfully, automatic clearing is carried out to match the open items. If the items are not cleared automatically, AR team will manually clear the items. | |
| Figure 29 – Change View “Additional Rules for Automatic Clearing” | |
| 2.8.4 Process Lockbox | |
| Lockboxes are special depository accounts set up at a bank and tied to a bank-owned postal address to which a customer remits their physical invoice payments. A process for handling Lockbox payments is currently used in the US by CT business for processing cheque payments. | |
| US Treasury are investigating the replacement of the current lockbox service with Remote Deposit Capture, however this is unlikely to be operational before CT go-live. The Lockbox service process is to continue with the BAU process of manually obtaining Lockbox details and clearing of Lockbox cash. Current Lockbox volumes are very low. | |
| 2.8.5 Create Customer Statements | |
| Creating customer statements is the process of issuing statements of account to customers, which include the list of all customer open items, including credits and open invoices. The statements can be generated on a regular basis or on ad-hoc basis or at customer request based on the business decision. | |
| This process will be set up for all Company Codes across JM CT business to provide the open item list to the customers before sending out the dunning letters. The process will be applicable for the new company codes and will be inherited by the consolidated sites. | |
| The correspondence letter outputs are company code specific, and the output forms will be maintained for every company code to include correct company logo, header and footer details. | |
| Forms will be maintained for the new company codes and consolidation company codes based on the requirement. WRICEF STC_F005 has been created for the maintenance of the forms for statement output. | |
| 2.8.5.1 Periodic Account Statement Indicator | |
| For generating the customer account statements, there are a number of configuration settings that are required to be maintained. The Periodic Account Statement Indicator specifies the frequency at which the Customer account statements are generated. This key should be maintained and specified as a selection criterion for the program that creates the periodic account statements. | |
| Figure 64 - 2.8.5.1 Periodic account statement indicator | |
| 2.8.5.2 Correspondence types | |
| For the Customer Statement letters to be issued, the correspondence type will be maintained. Correspondence types are the different types of letters that are maintained and sent out. You can use the SAP standard correspondence types or create new which meet the business requirement. | |
| SAP13 is the available correspondence type for generating the customer statements. This will be used to generate the statements. | |
| The same type of correspondence form will be used by the new company codes and the consolidation sites. | |
| Figure 65 – Correspondence Types | |
| 2.8.5.3 Assign Program for Automatic Correspondence | |
| To generate the correspondence outputs, a print program is required to be assigned to the correspondence type. SAP standard program RFKORD11 will be used for generating the customer statement outputs. | |
| Once the correspondence interval and the type has been established and maintained, the print program to output the correspondence will be assigned. | |
| . | |
| Figure 66 - 2.8.5.3 Assign Program for Automatic Correspondence | |
| 2.8.6 Process Collections | |
| Dunning is the process of sending reminder letters to customers about outstanding or overdue payments. The letters are generated at regular intervals (e.g. monthly) or on an ad-hoc basis, and then sent to the customers. | |
| The Dunning process requires forms to be set up for every company code and the details will be covered in the WRICEF STC_F006. | |
| The requirement is for JM CT business to send out the reminder letters on a regular basis to the customers. | |
| The dunning process will be carried out by the different sites locally. | |
| 2.8.6.1 Complete Debt Notification | |
| Dunning process is being introduced to CT business and all the configuration required is to be set up. The below section covers all the configuration required for the dunning letters to be output. | |
| Dunning process within CT will involve 3 levels of reminder letters being triggered for customer overdue items on the 7th, 14th and 30th days. The process of issuing 3 dunning letters will be consistent across the sites except for GB35 Company Code. The dunning settings will be inherited by the new company codes and the consolidation sites. | |
| Dunning process is not required to be set up for the proposed Davy Licensing Company Code GB35. | |
| 2.8.6.1.1 Dunning Procedures | |
| The dunning procedure defines the dunning levels and the intervals between the letters. Intervals for the dunning letters to be issued, the forms used for the letter output are assigned to the dunning procedures. | |
| JM CT will maintain one Dunning Procedure JM01, which will be used across all Company Codes. The Company Code specific details such as the correspondence will be maintained as a Text Object and will be determined based on the parameters entered when executing the Dunning Run. | |
| Procedure Name Existing / New / Update Comments | |
| 0001 Four-level dunning notice, every two weeks Existing Not in use | |
| 0003 Payment reminder, every two weeks Existing Not in use | |
| GB30 DUMMY DUNNING PROCEDURE FOR USE OF DUNNING BLOCK FIELD Existing Not in use | |
| GB40 Tracerco dunning procedure Existing Not in use | |
| GB30 JM PT UK dunning procedure Update Update and use the existing dunning procedure | |
| JM01 JM dunning procedure New | |
| Below is the screen which shows the settings that are required to be maintained for the dunning area. This includes the dunning procedure code and the name of the procedure amongst the other settings. | |
| Figure 30 - 1.1.1.1.1 Dunning Procedures | |
| The below screen shows the number of dunning levels and the intervals at which the letters are sent out. | |
| Figure 31 – Dunning Levels | |
| Dunning texts are required to be maintained and this is maintained in the forms. Forms are assigned to each dunning step for the output. | |
| Figure 32 – Dunning Texts | |
| Selecting the Special GL indicator determines if the Special GL transactions are included in the dunning. | |
| Figure 33 – Special G/L Indicator | |
| 2.8.7 Process Customer Credits for Returns | |
| When processing the customer credits for returns, creation of a credit invoice automatically generates an accounting entry. This entry will be posted against the customer account as a credit memo and can be processed in 2 ways. | |
| • The credit memo will be sat on the customer Open Item list until further processed. | |
| • The customer credit memo will be charged off against an incoming customer invoice. | |
| JM CT business use document type ‘DG’ to differentiate the Billing document and credit memos and there are no changes being implemented for this process. | |
| JM CT use the standard ECC process for customer returns. | |
| The sales document type used is RE – Returns. | |
| Figure 34 – RE – Returns sales document type. | |
| Using the same approach to current system used as above, over the last two years, some 400 returns orders have been processed in the system, equating to around four per week. So, it is a relatively low volume exercise. | |
| The sales document type is used by the following sales organisations: | |
| • DE35 | |
| • GB30 | |
| • IN10 | |
| • IN20 | |
| • SE33 | |
| • US32 | |
| • US38 | |
| The Returns process will additionally be used by all new Consolidation sales organisations: | |
| • GB35 Licensing (Paddington UK) | |
| • NL10 IEBV | |
| The system permits creation of a returns sales order: | |
| • Without reference to a preceding document | |
| • With reference to a preceding sales order /* the default SAP option */ | |
| • With reference to a preceding invoice. | |
| Material is retuned to Returns stock via a standard Returns Delivery and movement type 651 – 651 - GD ret.del. returns. A QM Usage decision is made, and the material returned to unrestricted use stock or alternatively scrapped off the system. | |
| The returns sales order has an automatic billing block assigned – 08 - Check Credit Memo. This billing block is removed, and the document is then invoiced using the SAP standard invoice type, RE – Credit For Returns. | |
| A sample document flow is shown below: | |
| Figure 35 – Returns – sample document flow | |
| Standard posting to AR is executed upon release to accounting, see example below: | |
| Figure 36 – Returns account posting – customer line | |
| Figure 37 – Returns account posting – GL line | |
| No changes to this process have been identified. | |
| 2.9 Master data | |
| This section covers the following STC Level 4 processes: | |
| • 02.02.04. Perform pricing administration | |
| • 02.09.01. Maintain customer records | |
| • 02.09.02. Maintain sales master data | |
| • 02.09.04. Manage customer payment terms | |
| • Incoterms | |
| 2.9.1 Customer Master Data | |
| Customer master is maintained centrally for all in scope Concert businesses. This section covers the configurations related to the customer master in SAP. | |
| Customers in CT will be created directly in SAP after following a series of approval process via Lotus Notes, as documented in the BPD document. All the customers will initiate from the customer justification form that will be used uniformly across all the sites. | |
| To capture the type of customer, customer account groups are populated in the customer justification form and captured in the Lotus Notes request. | |
| 2.9.2 Customer Account Group | |
| The customer master data contains the information about business transaction and how transactions are recorded and executed by the system. A customer master record contains the information about the customers that an organization uses to do business with them. | |
| The Account Group is the highest level of Customer Master Data. Account Groups control various functionalities of the Customer Master Data: | |
| • Fields of Customer Master Data | |
| • Classify Customer to use various functions like partner functions | |
| • Interval for the Account number | |
| There is no change in current account group configuration, apart from the Account Manager update, discussed above. Total 28 account groups exist in the system out of which only 6 are in scope 0001, 0002, 0003, 0004, 0005. Below, the given table will give an overview of all the customer account groups. | |
| Account Group Description Existing / New Comments | |
| 0001 Sold-to party Existing All Sites – Sold to party | |
| 0002 Ship-to party Existing All Sites – Ship to party | |
| 0003 Payer Existing All Sites – Payer | |
| 0004 Bill-to party Existing All Sites – Bill to Party | |
| 0005 Prospective customer/end-user Existing All Sites - Prospective customer/end-user | |
| 0006 Competitor Existing Not in use | |
| 0007 Sales partner Existing Not in use | |
| 0012 Hierarchy node Existing Not in use | |
| 0100 Distribution center Existing Not in use | |
| 0110 Branch w/o intercomp.billing Existing Not in use | |
| 0120 Branch with intercomp.billing Existing Not in use | |
| 0130 Branch with external billing Existing Not in use | |
| 0140 Assortment (obsolete,don't use Existing Not in use | |
| 0150 Franchisee Existing Not in use | |
| 0160 Wholesale customer Existing Not in use | |
| 0170 Consumer Existing Not in use | |
| BFSC BFSC accounts Existing Not in use | |
| CPD One-time cust.(int.no.assgnmt) Existing Not in use | |
| CPDA One-time cust.(ext.no.assgnmt) Existing Not in use | |
| DEBI Customer (int.number assgnmnt) Existing Not in use | |
| HIST History customer Existing Not in use | |
| INSR Services Vendor Existing Not in use | |
| KUNA Customer (ext.number assgnmnt) Existing Not in use | |
| VVD TR-LO customer Existing Not in use | |
| Z003 Commission Agents Existing Not in use | |
| Z004 India CA End Users Existing Not in use | |
| ZPLT Plant as Customer Existing Not in use | |
| 2.9.3 Define and Assign Number range for Customer master records- | |
| In this step, you define the number intervals of the number ranges for Customer master records. | |
| When a Customer master record is created, a unique number identifying the master record is assigned. The number comes from the number range provided for the account group. | |
| There are two ways in which numbers can be assigned: | |
| • Internal number assignment | |
| o Here the SAP R/3 System automatically assigns a consecutive number from the number range defined. | |
| • External number assignment | |
| o Here you specify a number from the external number range. | |
| Recommendation | |
| With internal number assignment, you can start search functions for Customer master records using match codes. This largely eliminates the need for mnemonic customer numbers. | |
| For this reason, SAP recommends that you use internal number assignment. | |
| There is no change proposed to the Number range and Number range object. | |
| Account Group Description Number Range object Existing / New | |
| 0001 Sold-to party 01 Existing | |
| 0002 Ship-to party 01 Existing | |
| 0003 Payer 01 Existing | |
| 0004 Bill-to party 01 Existing | |
| 0005 Prospective customer/end-user 01 Existing | |
| 2.9.4 Additional Customer Master fields and Requirements - | |
| Key JM CT requirements include: | |
| CT business requires some new fields in the customer master to capture more information of the customers, few of the requirements can be captured in standard SAP given fields but for some custom fields and some new configuration required. Below are the related details: | |
| 1) D&B number - In this field business wants to capture the D&B number of the customer, for this standard field KRAUS can be used (same as Unify). | |
| 2) Domestic Ultimate DUNS Number – For capturing the DUNS number of customers a custom field is required. WRICEF reference CO46. | |
| 3) Tax classification- Existing SAP fields; Will need to include "Tax Liable" flag (sales Org -> Billing Documents tab) on ship to customer as needed | |
| 4) Preferred payment terms (on sales org and company code) - Existing SAP fields [Part of Payment Terms Harmonization] | |
| 5) Tax 1-5, VAT Reg Number- Existing SAP fields, to capture the requirements. | |
| 6) Terms & Conditions Indicator- Existing SAP field (for specific customers for whom standard T&C does not apply, will be at sales area level KNVV) | |
| Customer Fields Description Existing / New Relevant Site | |
| KNKK - KRAUS D&B number New All Sites | |
| KNA1 - ZDUNS Domestic Ultimate DUNS Number New All Sites | |
| KNA1 - STCD1 | |
| KNA1 – STCD2 | |
| KNA1 - STCEG Tax 1 – 5 and VAT Reg number New All Sites | |
| KNVV - KVGR3 | |
| Possible value | |
| 01 – Standard T&C | |
| 02 – Non-Standard T&C Terms and Conditions New All Sites | |
| A new Partner function ZC - Account Manager will be created and All relevant sales document types are assigned to Partner Determination Procedure TA - Standard Order. The new ZC partner function will be added to this procedure. It will be necessary to ensure that Account Managers are loaded to table PA0001 so that they are available to enter as the ZC Account Manager in the sales order. A new account group will be configured and assigned to the existing Sold-To customer master Partner Determination Procedure. | |
| 2.9.5 Incoterms | |
| Incoterms are an international commercial term that defines the terms of sale and the passing of risks for the import and export of merchandise. Incoterms play an important role in global business. In other words, Incoterms are the codification of international rules for the interpretation of the commonly used terms in foreign trade. | |
| JM CT Requirements: | |
| • Rationalise customer master data such as: | |
| o Payment Terms | |
| o Incoterms | |
| There are no changes to existing Incoterms proposed. | |
| Currently, we have below Incoterms defined: | |
| Incoterms Description Existing / New Comments | |
| CFR Costs and freight Existing No Change | |
| CIF Costs, insurance & freight Existing No Change | |
| CIP Insured freight-free Existing No Change | |
| CPT Freight-free Existing No Change | |
| DAF Border delivered Existing No Change | |
| DAP Delivered at Place Existing No Change | |
| DAT Delivered at Terminal Existing No Change | |
| DDP Delivered duty paid Existing No Change | |
| DDU Delivered Duty Unpaid Existing No Change | |
| DEQ Delivered from quay (cleared) Existing No Change | |
| DES Delivered from ship Existing No Change | |
| EXW From plant Existing No Change | |
| FAS Free along side Existing No Change | |
| FCA Free Carrier Existing No Change | |
| FH Free house Existing No Change | |
| FOB Free on board Existing No Change | |
| N/A Not applicable Existing No Change | |
| UN Not free Existing No Change | |
| 2.9.6 Customer Payment Terms | |
| Terms of payment is used in SAP to determine the due date and discount calculation. Terms of payment is maintained in Customer master default at invoice level however this can be changed at invoice level as well. | |
| • For Customer Invoices from SD side the payment is defaulted from “Sales Data” view. | |
| • For FI invoices payment terms is defaulted from “Accounting View” for customer and vendor. | |
| • For Purchasing invoices payment term is defaulted from “Purchasing View” in Purchase Order/ MIRO invoices | |
| Payment terms must be agreed in advance with customers. The default should be JM’s standard payment terms of not more than 30 days from date of invoice. Any deviations for new customers must be approved by the Sector Finance Director but deviations by more than 30 days require approval of Group Treasurer. | |
| Goods should not be delivered, or services provided, if there is no written agreement between the contracting parties on payment terms. | |
| JM CT Requirements: | |
| • Customer analysis to get improvements for Sales Process - credit management, incoterms, payment terms for example | |
| • Rationalize payment terms | |
| Steps to create new payment terms – | |
| • Request New / Amended Payment Term - Finance identifies the need for a new or amended payment term (Manual) | |
| • Maintain Payment Terms - Creation or maintenance of sales terms of payment (SAP) | |
| Below are Payment Terms which are relevant for Sales- | |
| JM CT currently have 217 payment terms that are relevant for Customers and 143 for vendor relevant. | |
| These will be reviewed and rationalised during Realisation. It is understood that the ability to flex payment terms at Billing Plan line-item level will make some of the above redundant. | |
| 2.9.7 Maintain Sales Master Data | |
| Define various customer attributes which represent classification profiles and allocations to market segments. You use these customer attributes mainly for statistical purposes in sales and distribution. They are not used for control. | |
| The SAP System copies the attributes from the master records into the sales documents. | |
| 2.9.7.1 Define Customer Groups | |
| You define the customer groups to which a customer can belong. | |
| You specify the customer group for sales data in the customer master record for each sales area. | |
| The SAP System copies this specification automatically into the sales documents at header and item level | |
| Actions | |
| 1. Specify an alphanumeric key which can have up to 2 characters and a description for the customer groups. | |
| 2. Make sure that the customer groups are entered in the customer master records. | |
| There is no change in customer master groups - | |
| Customer group Description | |
| 01 Major (non services) | |
| 02 Independent | |
| 03 Industrial Gas | |
| 04 DRI | |
| 20 Major Operators | |
| 21 Regional Tech. Advan | |
| 22 Oil Field Service | |
| 23 Remote Majors | |
| 24 Regional Coasters | |
| 25 Lean Operators | |
| 26 Scavengers | |
| 27 Regional Laggards | |
| 28 Separator Consultanc | |
| 40 Operators Tech Lead | |
| 41 Operators Tech Follo | |
| 42 Original Equip Manf | |
| 43 E&P Contract. Majors | |
| 44 E&P Minors | |
| 45 Low Cost Operators | |
| 46 E&P Backyarders | |
| 60 Technology Valuers | |
| 61 Tech. & Eng. Vendors | |
| 62 Maintenance Contract | |
| 63 Large Scale Dithers | |
| 64 Small Fish | |
| 65 Process Consultants | |
| 66 Infant Adopters | |
| 67 Lg Scale Penny Pinch | |
| 80 Fiscal Marking | |
| 81 Brand Protection | |
| D0 Default Dyson | |
| D1 Major Dyson | |
| D2 Independent Dyson | |
| D3 Industrial Gas Dyson | |
| D4 DRI Dyson | |
| E0 ACH | |
| E1 Adecsa | |
| E2 ADM | |
| E3 AGP | |
| E4 Akzo Nobel | |
| E5 Alicorp | |
| E6 Arhuus | |
| E7 Bunge | |
| E8 Cargill | |
| E9 Clariant | |
| EA Cognis | |
| EB Fuji | |
| EC Grasco | |
| ED Karlschamns | |
| EE Lonza | |
| EF Mateos | |
| EG Oleon | |
| EH SOGIS | |
| EI Southern Group | |
| EJ Team | |
| EK Undesa | |
| EL Unilever | |
| EM Uniqema | |
| EN Total | |
| EO DSM | |
| EP Huntsman | |
| EQ Degussa | |
| ER BP | |
| ES Celanese | |
| ET Exxon/Mobil | |
| EU Sasol | |
| F1 Chemical | |
| F2 Wood | |
| F3 Others | |
| H1 Sun Worldwide | |
| H2 Coates Worldwide | |
| H3 Coates Europe | |
| H4 Coates Harlow | |
| H5 Coats Rochdale | |
| H6 Nippon Soda | |
| H7 Ciba Speciality Chem | |
| H8 Exxon | |
| H9 Magni | |
| HA Dow | |
| HB Atofina | |
| HC Flint | |
| HD Haldor Topsoe | |
| HE Core Customers | |
| I1 Ruchi Soya | |
| I2 Bunge | |
| I3 Cargill | |
| I4 Amrit Vanaspati | |
| I5 Godrej | |
| I6 Pan Century | |
| I7 Wilmar | |
| I8 Lam Soon | |
| I9 Cognis | |
| 2.9.7.2 Define Sales District | |
| You define the sales districts in which the customers' subsidiaries can be located. | |
| You specify the sales districts for the sales data in the customer master record for each sales area. | |
| The SAP System copies this specification into the sales documents at header and item level. Here, you find the sales districts of general business data on the detail screen. | |
| Actions | |
| 1. Specify an alphanumeric key which can have up to 6 characters and a description for the customer sales districts. | |
| 2. Make sure that the sales districts are entered in the customer master records. | |
| Sales District Description | |
| AMC Americas (Canada) | |
| AMO Americas (Other) | |
| AMU Americas (USA) | |
| ASPA Asia Pacific (Aust) | |
| ASPJ Asia Pacific (Japan) | |
| ASPO Asia Pacific (Other) | |
| CWE Cont.Western Europe | |
| OTHER Other countries | |
| UKE United Kingdom | |
| 2.9.7.3 Maintain Reserve fields in Customer Master | |
| There are reserve fields in the customer master record which are not used in the standard system. They are available for use and are as follows: | |
| • Customer group 1 (View: V_TVV1 Field:KVGR1) | |
| • Customer group 2 (View: V_TVV2 Field:KVGR2) | |
| • Customer group 3 (View: V_TVV3 Field:KVGR3) | |
| • Customer group 4 (View: V_TVV4 Field:KVGR4) | |
| • Customer group 5 (View: V_TVV5 Field:KVGR5) | |
| Customer Group 1 | |
| Customer Group 1 Description | |
| S1 Assigned to Synetix | |
| T1 Assigned to TDG | |
| T2 Confirmed by TDG | |
| T3 Checked by TDG | |
| T4 Arranged by TDG | |
| X1 Split responsibility | |
| Customer Group 2 | |
| Customer Group 2 Description | |
| V1 Key Customer | |
| V2 Core Customer | |
| V3 General Customer | |
| Customer Group 3 is empty, but suggested for Terms and Conditions - | |
| Possible value | |
| 01 – Standard T&C | |
| 02 – Non-Standard T&C | |
| Customer Group 4 and Customer Group 5 are empty | |
| 2.9.8 Perform Pricing Administration | |
| Pricing management deals with establishing pricing for orders, processing pricing exceptions, maintaining, and updating pricing, and monitoring compliance to guidelines. | |
| Pricing of sales document line items may be manual or automatic. Sales document pricing is carried out manually. The current pricing conditions used include | |
| • PR00 | |
| • ZPR0 | |
| As of now pricing is maintained manually in directly in transactional data rather than automatic pricing. | |
| At this phase of the project, JM CT will not adopt automatic quotation and sales order pricing. | |
| Figure 38 – Key combination | |
| This access sequence allows the system to record prices that are: | |
| • Customer and material specific /*material sales price for a given customer */ | |
| • Price list and material specific /* a price list that can apply to many customers */ | |
| • Material specific /* material sales price only */ | |
| The system will search for a price in the sequence defined above and find the appropriate price for a given sales document line item. Typically, this search sequence will be the specific to the general price. | |
| JM CT Requirements: | |
| • Maintain price list in SAP | |
| • Provide pricing visibility and price exception reporting | |
| • Automate tax calculation to be included on invoice – tax codes in customer master data, tax as a pricing condition | |
| • Include freight in pricing calculation | |
| • Include customer specific pricing in SAP | |
| • Use reporting to enable analysis of pricing trends and margin analysis by key metrics such as region, industry market, customer, and product | |
| • Review regularly and maintain proactively pricing master data | |
| • Complete mass pricing updates to reduce manual effort and limit the risk of input errors. | |
| Various pricing requirements in billing - | |
| • Freight - Freight to add | |
| • Tax - Should be added | |
| • Pricing conditions include: | |
| o Discount | |
| o Freight | |
| o Bin surcharge - for Savannah | |
| Requirement for new statistical condition type ZLIS – JM CT Target List Price which will further used to capture variance in reporting. | |
| • Validate customer pricing versus price list and report variances | |
| • Requirement to capture statistical price (ZLIS) in pricing procedure which will be determined in the sales transaction. | |
| • The condition will be determine automatically based on condition record maintained. | |
| • Implementation of statistical pricing and a report to highlight variance from actual. | |
| • A report will be built against the statistical condition and the net value to capture the variance. | |
| • If pricing is maintained a statistical condition type will be populated to record this price. The purpose is to support down-stream reporting. | |
| Below are config required to capture the requirement (customer pricing versus price list and report variances). | |
| It is anticipated that the standard access sequence PR02 will suffice for the JMCT statistical pricing requirement. | |
| Figure 39 – Change View “Accesses” | |
| New Condition type ZLIS – JM CT Target List Price - which will be statistical in nature and has subtotal to capture the value. | |
| These prices will be maintained through condition records. | |
| Figure 40 – Condition Records | |
| Assignment of condition type ZLIS to pricing procedures {ZKATDE, ZKAT00, ZSUN00, ZEXPOR, ZSERV, ZFACT, ZKATSE, ZKAUSA}. | |
| Figure 41 – Assignment of condition type to pricing procedures | |
| 2.9.8.1 Document pricing procedure | |
| The key that specifies the Pricing procedure for sales document. | |
| Document pricing procedure is one of the important fields in determining the pricing procedure | |
| During pricing, the system determines the pricing procedure by considering: | |
| o The Sales Area | |
| o The pricing procedure key in the header of the sales document type | |
| o The pricing procedure key in the customer master record | |
| Currently below are document pricing procedures we have defined in system, there is no requirement to create new pricing procedures with the exception of the intercompany pricing procedure noted above. | |
| Document Pricing Procedure Description Existing / New | |
| 1 Deemed Exp:(JMCIPL) Existing Not Used | |
| 2 CA transfer(JMCIPL) Existing Not Used | |
| 3 CA Sales(JMCIPL) Existing Not Used | |
| 4 Services (JMCIPL) Existing Used | |
| 5 Export(JMCIPL) Existing Used | |
| 6 Comm:JMCIPL Existing Not Used | |
| 7 Spent cat Existing Not Used | |
| 8 Indenting Sale Existing Not Used | |
| 9 JMC Returns/Re-activ Existing Not Used | |
| A Standard Existing Used | |
| C Free Existing Not Used | |
| E Stock transfer Existing Not Used | |
| F Depot Sales Existing Not Used | |
| H High Seas Existing Not Used | |
| S Sundry Sales Existing Used | |
| T Stock transfers Existing Not Used | |
| V Contract Existing Not Used | |
| W Contract - Expense Existing Not Used | |
| X JMCIPL Credit Memo Existing Not Used | |
| Y JMCIPL Debit Memo Existing Not Used | |
| Z Commission Credits Existing Not Used | |
| Below are sales document – Doc Pricing procedure assignment. | |
| Figure 42 – Doc Pricing procedure assignment | |
| 2.9.8.2 Pricing procedure assigned to customer | |
| This determines which pricing procedure the system will apply when you create a sales document for the customer. | |
| Currently, below, are the customer pricing procedure we have, we need to create new for Intercompany (mentioned last) also need to review all during realisation phase. | |
| The one in green are used by existing sites and will continue using that. | |
| Customer Pricing Procedure Description Existing / New Used by Sales org | |
| 1 Commission Agent 1 Existing GB30, US32 Used | |
| 2 Commission Agent 2 Existing Not Used | |
| 3 Direct Exports Existing Not Used | |
| 4 CA (JMCIPL) Existing Not Used | |
| 5 Domestic (JMCIPL) Existing IN10 Used | |
| 6 Deemed Ex (JMCIPL) Existing IN10 Used | |
| 7 Nepal Exp:(JMCIPL) Existing Not Used | |
| 8 Export (JMCIPL) Existing IN10 Used | |
| 9 Scrap Sales (JMCIPL) Existing Not used | |
| A ACT Existing Not Used | |
| K Synetix Existing GB30 , DE35, US32, US38 Used | |
| P Pharmorphix Existing Not Used | |
| 2.9.8.3 Maintain Pricing Procedure | |
| The pricing procedure contains the pricing model for sales document, specifying both automatic and manual pricing. It comprises a sequence of prices, surcharges, discounts and taxes that, in total determine both the Net and Gross price for the sales document line item and document overall. | |
| It is recommended to copy a similar pricing procedure & make the necessary changes in the new pricing procedure. | |
| Below are the pricing procedures which we are using for existing sites. | |
| Pricing Procedure Sales Org Assigned Used with Doc type | |
| ZKATDE DE35 All doc type | |
| ZKAT00 GB30 All doc type except Sundry | |
| ZSUN00 GB30 Only Sundry sales (ZS) | |
| ZEXPOR IN10 Only export sales (ZEXP, ZEQT, ZEXF) | |
| ZSERV IN10 With service order (ZSER) | |
| ZFACT IN10 All doc type except export, service ZF, QT, ZDOM, CR, RE | |
| ZKATSE SE33 All doc type | |
| ZKAUSA US32 and US38 All doc type | |
| Below is the structure of pricing procedure: | |
| Figure 43 – Structure of pricing procedure | |
| Existing Pricing Procedure can be used for new consolidated sites below - | |
| Sales Org Pricing Procedure Condition Type Comments | |
| GB35 (Licensing (Paddington UK)) ZKAT00 ZPR0 New | |
| NL10 (IEBV) ZKATDE ZPR0 New | |
| 2.9.8.4 Define Pricing Procedure Determination | |
| During sales documents processing, the SAP system automatically determines a corresponding pricing procedure. Pricing procedure determination is based on combination of sales area, document pricing procedure and customer pricing procedure. | |
| Below are the existing configurations for sales org in scope. For new sales org, we need to define pricing procedure so that it will determine sales transaction. | |
| Sales Organization Distribution Channel Division Doc. pric. procedure Cust.p.p Pricing procedure Condition type Comments | |
| DE35 00 00 A K ZKATDE ZPR0 Used | |
| DE35 00 00 C 1 ZKATDE ZPR0 Used | |
| DE35 00 00 S 1 ZSUN00 ZPSS Not used | |
| DE35 00 00 S K ZSUN00 ZPSS Not used | |
| DE35 00 00 T K ZVSTKE Not used | |
| DE35 00 00 Z 1 ZDECOM ZC00 Not used | |
| DE35 00 00 Z 2 ZDECO2 ZC10 Not used | |
| GB30 00 00 A 1 ZKAT00 ZPR0 Used | |
| GB30 00 00 A 2 ZKAT00 ZPR0 Used | |
| GB30 00 00 A K ZKAT00 ZPR0 Used | |
| GB30 00 00 C 1 ZKAT00 ZPR0 Used | |
| GB30 00 00 C 2 ZKAT00 ZPR0 Used | |
| GB30 00 00 C K ZKAT00 ZPR0 Used | |
| GB30 00 00 S 1 ZSUN00 ZPSS Used | |
| GB30 00 00 S 2 ZSUN00 ZPSS Used | |
| GB30 00 00 S K ZSUN00 ZPSS Used | |
| GB30 00 00 T 1 ZVSTKE Not used | |
| GB30 00 00 T 2 ZVSTKE Not used | |
| GB30 00 00 T K ZVSTKE Not used | |
| GB30 00 00 V K ZKAT00 ZPR0 Used | |
| GB30 00 00 Z 1 ZVACOM ZC00 Not used | |
| GB30 00 00 Z 2 ZVACO2 ZC10 Not used | |
| IN10 00 00 1 6 ZDEMEX PR00 Used | |
| IN10 00 00 2 4 ZSTKTR PR00 Not used | |
| IN10 00 00 2 5 ZFACT PR00 Used | |
| IN10 00 00 3 4 ZDEPOT PR00 Not used | |
| IN10 00 00 3 5 ZDEPOT PR00 Not used | |
| IN10 00 00 4 5 ZSERV ZPSV Used | |
| IN10 00 00 5 7 ZFACT PR00 Used | |
| IN10 00 00 5 8 ZEXPOR ZFOB Used | |
| IN10 00 00 6 4 ZCOMM Not used | |
| IN10 00 00 6 5 ZCOMM Not used | |
| IN10 00 00 6 6 ZCOMM Not used | |
| IN10 00 00 6 7 ZCOMM Not used | |
| IN10 00 00 6 8 ZCOMM Not used | |
| IN10 00 00 8 4 ZINDEN PR00 Not used | |
| IN10 00 00 8 5 ZINDEN PR00 Not used | |
| IN10 00 00 8 6 ZINDEN PR00 Not used | |
| IN10 00 00 8 7 ZINDEN PR00 Not used | |
| IN10 00 00 8 8 ZINDEN PR00 Not used | |
| IN10 00 00 9 4 ZDEPOT PR00 Not used | |
| IN10 00 00 9 5 ZDEPOT PR00 Not used | |
| IN10 00 00 A 4 ZFACT PR00 Used | |
| IN10 00 00 A 5 ZFACT PR00 Used | |
| IN10 00 00 A 6 ZDEMEX PR00 Used | |
| IN10 00 00 A 7 ZFACT PR00 Used | |
| IN10 00 00 A 8 ZEXPOR ZFOB Used | |
| IN10 00 00 E 4 ZSTKTR PR00 Not used | |
| IN10 00 00 H 4 ZFACT PR00 Used | |
| IN10 00 00 H 5 ZFACT PR00 Used | |
| IN10 00 00 H 6 ZFACT PR00 Used | |
| IN10 00 00 H 7 ZFACT PR00 Used | |
| IN10 00 00 H 8 ZFACT PR00 Used | |
| IN10 00 00 T 1 ZSTKTR PR00 Not used | |
| IN10 00 00 T 4 ZINSTO ZSTO Not used | |
| IN10 00 00 X 1 ZCRDR ZVAL Not used | |
| IN10 00 00 X 2 ZCRDR ZVAL Not used | |
| IN10 00 00 X 3 ZCRDR ZVAL Not used | |
| IN10 00 00 X 4 ZCRDR ZVAL Not used | |
| IN10 00 00 X 5 ZCRDR ZVAL Not used | |
| IN10 00 00 X 6 ZCRDR ZVAL Not used | |
| IN10 00 00 X 7 ZCRDR ZVAL Not used | |
| IN10 00 00 X 8 ZCRDR ZVAL Not used | |
| IN10 00 00 X 9 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 1 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 2 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 3 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 4 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 5 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 6 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 7 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 8 ZCRDR ZVAL Not used | |
| IN10 00 00 Y 9 ZCRDR ZVAL Not used | |
| IN10 00 99 A 6 ZDEMEX PR00 Used | |
| SE33 00 00 A K ZKATSE ZPR0 Used | |
| US32 00 00 A 1 ZKAUSA ZPR0 Used | |
| US32 00 00 A 2 ZKAUSA ZPR0 Used | |
| US32 00 00 A A ZKAACT ZCSP Not used | |
| US32 00 00 A K ZKAUSA ZPR0 Used | |
| US32 00 00 V K ZKAUSA ZPR0 Used | |
| US32 00 00 Z 1 ZVACOM ZC00 Not used | |
| US32 00 00 Z 2 ZVACO2 ZC10 Not used | |
| US38 00 00 A K ZKAUSA ZPR0 Used | |
| GB35 (Licensing (Paddington UK)) 00 00 A K ZKAT00 ZPR0 New | |
| NL10 (IEBV) 00 00 A K ZKATDE ZPR0 New | |
| We may need to define more entries for new consolidated sites based on different doc pricing or customer pricing-based discussion. | |
| 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 | |
| Following is a list of Workflow which fall under operating procedures for project Concert: | |
| Workflows | |
| WRICEF | |
| ID Description Data Object | |
| (Sales Order) Engaged Parties Owner | |
| 3.2 Report | |
| Following is the list of Reports to be built as part of project Concert. | |
| Reporting | |
| WRICEF | |
| ID Description Report Type (ABAP, BI, BOBJ) Data Elements Relevant KPI Owner | |
| STC_R002 Create sales reports in order to provide crucial information to support Customer Service work. | |
| A bespoke ALV ABAP report (ZSOMS) that will include sufficient details to identify whether there is a potential supply problem for the order. Analyse/ Review the data in the report to view the current order position (has Production or Logistics Execution been performed), current billing status etc. After an analysis of the report, it may be required to expedite the order to meet the delivery date. ABAP Susan Simpson | |
| STC_R003 A report to identify customers, with a confident or planned probability for a forecast or quote with a delivery date in the next 3 months, having a credit block. | |
| See section 2.2.5 for further details. ABAP Susan Simpson | |
| STC_R004 A report to identify inactive customers for annual customer master data review. | |
| Selection screen with standard ALV selection criteria including: | |
| • Customer Number | |
| • Sales Organisation | |
| • Document Type | |
| • Document Category | |
| • Date Range | |
| • Account Group | |
| ALV Results Screen with key details of inactive customers – that is those without any sales transactions in the selected date range. ABAP Susan Simpson | |
| STC_R005 An ABAP ALV report on forecast accuracy at order line level for demand managers. | |
| See section 2.2.4 for further details. | |
| ABAP Susan Simpson | |
| STC_E001 Support of Variance in pricing to Target pricing. ABAP report with standard selection screen functionality, ALV results screen. | |
| See section 2.5.5.1 for further details. ABAP Susan Simpson | |
| STC_R006 Report to show sales orders flagged as Emergency Orders. Standard ABAP report. | |
| Standard ALV report with selection screen and ALV results screen. Lists orders matching selection criteria that are flagged as an emergency. ABAP Susan Simpson | |
| STC_R007 Report to show OTIF (on time in full performance). Standard ABAP report. | |
| Standard ALV report with selection screen and ALV results screen. | |
| The precise criteria for judging delivery due date performance will be agreed with the business. The target date requires definition and agreement. This will then be compared to the Actual Goods Issue Date. | |
| Formatting and presentation of the data has yet to be agreed. | |
| ABAP Susan Simpson | |
| 3.3 Interface | |
| Following are 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 | |
| STC_I001 CRM tool to be integrated with SAP. Integration method to be determined by technical architect and technical team. | |
| The current working assumptions regarding implementation of the interface is documented in section 2.2.2 – CRM Interface – Forecasting, above. TBD CRM SAP TBA Susan Simpson | |
| STC_I002 SAP demand data to be exported to S&OP forecasting tool via spreadsheet. Standard ABAP ALV report that can be executed manually or via a batch job. | |
| Selection screen will include organisational and document type selection criteria. | |
| Results screen will show matching open documents with a traffic light evaluation as to whether they are possible duplicate demands. | |
| User will be able to select / deselect documents for export. ABAP SAP Spreadsheet TBA Susan Simpson | |
| 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 | |
| STC_C001 Customer Credit Master - Credit Management (Credit groups) Aggresso/MINOX ETL automated TBA Susan Simpson | |
| STC_C002 Customer Master | |
| V1.01: New fields added as shown below | |
| Aggresso/MINOX ETL automated TBA Susan Simpson | |
| STC_C004 Open Forecast/Quotation Aggresso ETL automated TBA Susan Simpson | |
| STC_C005 Open Sales Orders Aggresso/MINOX ETL automated TBA Susan Simpson | |
| • ZDUNB - D&B Number | |
| • ZDBNU - Domestic Ultimate D&B Number | |
| • ZDBGU - Global Ultimate D&B Number | |
| 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 Functional Gap Alternative SAP Standard Reason Owner | |
| STC_E001 Placeholder for pricing determination routines (VOFM/load program routine) KONV, KONP Pricing – standard approach to enhancing configuration None Standard technique. Susan Simpson | |
| STC_E002 Emergency Sales Order Indicator – see section 2.5.5.2. VBAK Ability to flag an order as Emergency None Standard technique. Susan Simpson | |
| STC_E003 Update to KNA1-KATR1 to rename as Std T&C Indicator KNA1 Ability to flag a customer as subject to standard terms & conditions None Standard technique. Susan Simpson | |
| 3.6 Forms | |
| Following are 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 | |
| STC_F005 Customer a/c statement : A new adobe form will be created in English which will be triggered by the customer statement processes and will be sent to the customer. The expectation is to use the standard form across all sites. Form periodic TBA Susan Simpson | |
| STC_F006 Dunning Forms : A new adobe form will be created in English which will be triggered by the dunning processes and will be sent to the customer. The expectation is to use the standard form across all sites and the content reflecting of the dunning levels. Form monthly TBA Susan Simpson | |
| STC_F004 Update to order confirmation e-mail and title Form daily TBA Susan Simpson | |
| STC_F003 Billing Output Form | |
| Update invoice layout (x3) & FAZ for down payments. New adobe forms output type. Form daily TBA Susan Simpson | |
| STC_F002 Order confirmation layout is created under sales order and it might be required some adjustments to update information printed in this layout. New adobe forms output type. Form daily TBA Susan Simpson | |
| 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 | |