Sales Order Processing Replicated Master Data
Böder, Gröne (Editors)
THE BEST-RUN BUSINESSES RUN SAP™
SAP Architecture Governance and Standards
Find more Information in the Architecture Library: https://portal.wdf.sap.corp/go/architecture-library
SAP Internal Replicated
Conditions SAP GTS
R
Sales Activity
to ERP
Billing
Delivery
Billing Documents
RFQ / Inquiry
Sales Order Processing
Delivery Orders
Sales Orders
THE ARCHITECTURE OF SAP ENTERPRISE RESOURCE PLANNING (ERP) SAP ARCHITECTURE BLUEBOOK R
Availability Check
Sales and Distribution (SD) Purchase Material
Produce Material R
Ship / Deliver
Master Data R
Material
R
Business Partner
Global ATP Logic
PP Materials Requirement Planning (MRP)
SAP APO
FI / CO
Planned Orders
ControllingProfitability Analysis Financial Accounting
Production Orders R R
R
Purchase Requisition Processing
Purchase Order Processing
Goods Issue Processing
Goods Issues
R
Shipment Processing
Pricing
Goods Receipt Processing
Goods Receipts
Trigger ATP check
R
FI Data
R
Purchase Orders
Sagar Joshi (SAP ERP HCM) joined SAP Labs India in 2000 and since then worked in the HCM Development team. In the initial years with SAP, he focused on the HCM country version for India and was a key contributor to delivering the payroll and HR localization to Indian customers. Since 2004, Sagar is working as Architect on various topic in the area of HCM self services and shared services. His current responsibility is the renovation of HCM user interfaces.
Business Partner
Product
Purchase Requisition
Sushil Kumar (SAP ERP Financials) started in SAP IMS development support India in 2005 with the FI Business Warehouse topic and has become an expert of the financial inconsistencies area which deals with database corrections for customer financials data. In his current role as an Associate Architect he has overall responsibility for various financials topics which are supported in India, including GL inconsistencies, archiving, and analytics.
SAP CRM
Pre sales Processing
Satish Karthik (SAP ERP Operations) joined SAP Labs India in 2003 and has been working as a Solution Architect in IMS development support India for Materials Management (MM). In the past years, Sathish also worked across development areas such as consulting, custom development, or product management within SAP. Currently, Sathish is working in the SAP APO (Advanced Planner & Optimizer) area at SAP Labs Palo Alto.
THE ARCHITECTURE OF SAP ENTERPRISE RESOURCE PLANNING (ERP)
This book provides the first comprehensive description of the architecture concepts of SAP Enterprise Resource Planning (ERP). It is an extended compilation of the Architecture Bluebooks about SAP ERP Operations, SAP ERP Financials, and SAP ERP Human Capital Management (HCM) written by the following authors:
Sales Orders
Invoice Verification
Update
Materials Management (MM)
Inventory
Editors Jochen Böder and Bernhard Gröne, Architecture Governance and Standards
Jochen Böder, Bernhard Gröne (Editors)
Sathish Karthik R, Sushil Kumar, Sagar Joshi (Authors)
The Architecture of SAP Enterprise Resource Planning (ERP) SAP Architecture Bluebook
Internal
Version 1.0 December 2010
i
SAP Architecture Bluebook: SAP ERP
©2010 SAP AG. All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. in the United States and in other countries. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (“SAP Group”) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
ii
Internal
© Copyright SAP AG 2010
SAP Architecture Bluebook: SAP ERP
Table of Contents Foreword ............................................................................................................ 1 Preface................................................................................................................ 2 1 Architecture of SAP ERP .............................................................................. 3 1.1 1.2 1.3 1.4
SAP ERP Overview ............................................................................................... 4 SAP ERP Operations ............................................................................................ 4 SAP ERP Financials ............................................................................................. 5 SAP ERP Human Capital Management .............................................................. 6
2 SAP ERP Operations ..................................................................................... 7 2.1 Introduction of SAP ERP Operations ................................................................. 9 2.1.1 Master Data and Reuse .........................................................................................10 2.1.2 Integration with SAP Business Suite ......................................................................13
2.2 Material Master ................................................................................................... 16 2.2.1 Architecture Overview ............................................................................................16 2.2.2 The View Concept of Material Master ....................................................................17 2.2.3 Database Design of Material Master ......................................................................20
2.3 Business Partner Master Data .......................................................................... 22 2.3.1 Partner Determination ............................................................................................22
2.4 Sales and Distribution ....................................................................................... 24 2.4.1 2.4.2 2.4.3 2.4.4
Architecture Overview ............................................................................................24 Integration ..............................................................................................................27 Pricing ....................................................................................................................28 Availability Check ...................................................................................................36
2.5 Production Planning .......................................................................................... 43 2.5.1 2.5.2 2.5.3 2.5.4
Master Data ............................................................................................................43 Integration ..............................................................................................................44 Planning Functions .................................................................................................45 Production Execution .............................................................................................51
2.6 Materials Management ....................................................................................... 56 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5
Procurement of Materials .......................................................................................57 Procurement of Services ........................................................................................58 Integration ..............................................................................................................58 Framework-Based Implementation of Purchase Requisition ..................................60 Pattern-based User Interface .................................................................................64
2.7 Logistics Execution ........................................................................................... 70 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 2.7.6
Architecture Overview ............................................................................................70 Integration ..............................................................................................................71 Inbound Delivery Processing ..................................................................................71 Outbound Delivery Processing ...............................................................................72 Transportation Management ..................................................................................76 Warehouse Management .......................................................................................79
2.8 Quality Management .......................................................................................... 83
© Copyright SAP AG 2010
Internal
iii
SAP Architecture Bluebook: SAP ERP
2.8.1 2.8.2 2.8.3 2.8.4 2.8.5 2.8.6
Quality Planning .................................................................................................... 84 Quality Inspection .................................................................................................. 86 Quality Control ....................................................................................................... 88 Quality Notification ................................................................................................. 88 Quality in Procurement Processing ....................................................................... 88 Quality Certificate Processing................................................................................ 89
2.9 ERP OPS Further Reading .................................................................................91 2.10 ERP OPS Glossary .............................................................................................92
3 SAP ERP Financials .................................................................................... 93 3.1 Introduction to SAP ERP Financials .................................................................95 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6 3.1.7
Overview of SAP ERP Financials .......................................................................... 96 Financial Accounting ............................................................................................. 96 Management Accounting ....................................................................................... 98 Financial Supply Chain Management .................................................................... 99 Treasury .............................................................................................................. 100 Accounting Interface ............................................................................................ 100 Deployment ......................................................................................................... 101
3.2 Recording Financial Transactions Using the Accounting Interface ...........102 3.2.1 Create Interface ................................................................................................... 103 3.2.2 Post Interface ...................................................................................................... 105
3.3 Financial Accounting .......................................................................................107 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 3.3.9 3.3.10 3.3.11
The Financial Document ...................................................................................... 108 Financial Interface ............................................................................................... 109 FI Document Posting ........................................................................................... 110 New General Ledger Accounting ......................................................................... 113 FI Document Processing with NewGL ................................................................. 115 Sub-Ledger Processing ....................................................................................... 116 Clearing ............................................................................................................... 122 Tax Accounting .................................................................................................... 123 Periodic Processing ............................................................................................. 125 Asset Accounting ................................................................................................. 129 Special Purpose Ledger ...................................................................................... 131
3.4 Management Accounting .................................................................................134 3.4.1 Management Accounting ..................................................................................... 135 3.4.2 Profitability Analysis ............................................................................................. 137 3.4.3 Profit Center Accounting ...................................................................................... 138
3.5 Financial Supply Chain Management .............................................................141 3.5.1 Collections and Dispute Management ................................................................. 141 3.5.2 Biller Direct .......................................................................................................... 143 3.5.3 Credit Management ............................................................................................. 145
3.6 Treasury.............................................................................................................147 3.6.1 Treasury and Risk Management: ......................................................................... 147 3.6.2 Cash and Liquidity Management ......................................................................... 148 3.6.3 In-House Cash..................................................................................................... 152
3.7 Outlook: Other topics of ERP Financials .......................................................154 3.8 ERP FIN Further Reading .................................................................................155
iv
Internal
© Copyright SAP AG 2010
SAP Architecture Bluebook: SAP ERP
3.9 ERP FIN Glossary ............................................................................................. 155
4 SAP ERP Human Capital Management .................................................... 157 4.1 Introduction to SAP ERP HCM ........................................................................ 159 4.1.1 Supported Business Processes............................................................................159 4.1.2 Layers of HCM Applications .................................................................................160 4.1.3 Scope of the Document ........................................................................................162
4.2 HCM Core Applications ................................................................................... 163 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6
Personnel Administration (PA) .............................................................................163 Personnel Development (PD) ...............................................................................164 Organizational Management ................................................................................166 Personnel Time Management ..............................................................................167 Payroll ..................................................................................................................169 Appraisals, Evaluation and Survey Engine ...........................................................172
4.3 HCM Extension Applications .......................................................................... 174 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6
Talent Management Overview..............................................................................174 Career and Succession Management ..................................................................176 Compensation Management ................................................................................178 Performance Management ...................................................................................179 E-Recruiting..........................................................................................................180 Enterprise Learning ..............................................................................................182
4.4 HCM Service Delivery Applications ................................................................ 185 4.4.1 Self Service Applications ......................................................................................185 4.4.2 HCM Processes and Forms .................................................................................192 4.4.3 Employee Interaction Center (EIC) .......................................................................194
4.5 Enterprise Services in HCM ............................................................................ 199 4.5.1 Service Enabling in HCM .....................................................................................199
4.6 ERP HCM Further Reading .............................................................................. 201 4.7 ERP HCM Table of Acronyms ......................................................................... 202
5 Appendix .................................................................................................... 203 5.1 ERP OPS Appendix .......................................................................................... 204 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6
Material Master.....................................................................................................204 Sales and Billing ...................................................................................................205 Production Planning .............................................................................................206 Materials Management .........................................................................................208 Logistics Execution ...............................................................................................209 Quality Management ............................................................................................212
5.2 ERP FIN Appendix ............................................................................................ 214 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5
Accounting Interface.............................................................................................214 Financial Accounting ............................................................................................214 Financial Supply Chain Management ...................................................................217 Treasury ...............................................................................................................219 Debit Credit in Financial Accounting .....................................................................223
5.3 ERP HCM Appendix ......................................................................................... 226 5.3.1 Software Components in SAP HCM .....................................................................226 5.3.2 PD Objects in HCM and Organizational Management .........................................227
© Copyright SAP AG 2010
Internal
v
SAP Architecture Bluebook: SAP ERP
5.3.3 PD Objects in E-Recruiting .................................................................................. 228 5.3.4 Business Object Models in SOA .......................................................................... 228
vi
Internal
© Copyright SAP AG 2010
SAP Architecture Bluebook: SAP ERP
Table of Figures Figure 1-1
Overview of SAP ERP................................................................................... 4
Figure 2-1
Architecture Overview of SAP ERP .............................................................. 9
Figure 2-2
Architecture Overview of SAP ERP OPS.................................................... 11
Figure 2-3
Integration Overview of SAP ERP OPS ...................................................... 14
Figure 2-4
Overview of Material Master ....................................................................... 16
Figure 2-5
Screen Sequence in Material Master .......................................................... 18
Figure 2-6
Views and Maintenance Status ................................................................... 19
Figure 2-7
Database Table Structure of Material Master (see also Appendix 5.1.1) ... 20
Figure 2-8
Partner Determination and Address Management used in SD ................... 23
Figure 2-9
Architecture Overview of Sales and Distribution ......................................... 25
Figure 2-10
Condition Technique – Example ................................................................. 30
Figure 2-11
Architecture of Pricing ................................................................................. 32
Figure 2-12
Reuse of Condition Determination Technique ............................................ 33
Figure 2-13
Conditions Customizing for Pricing ............................................................. 34
Figure 2-14
Output Control ............................................................................................. 35
Figure 2-15
Control Parameters for Availability Check in SD ........................................ 39
Figure 2-16
Architecture of ATP Logic ........................................................................... 40
Figure 2-17
Architecture of ATP Server ......................................................................... 41
Figure 2-18
Architecture of Production Planning and Production Execution ................. 45
Figure 2-19
Material Requirement Planning ................................................................... 49
Figure 2-20
Architecture of Production Execution .......................................................... 53
Figure 2-21
Architecture of Production Order Confirmation Processing ........................ 55
Figure 2-22
Architecture of Materials Management ....................................................... 56
Figure 2-23
Business Entities and Dependencies .......................................................... 60
Figure 2-24
Architecture of Purchase Requisition Framework ....................................... 62
Figure 2-25
Preconditions and Dependencies of Validation Rules ................................ 63
Figure 2-26
Enjoy Transaction – User Interface Layout ................................................. 65
Figure 2-27
Enjoy Transaction - Architecture Overview ................................................. 66
Figure 2-28
Business Logic Extensions ......................................................................... 68
Figure 2-29
Processing Purchase Order Extensions ..................................................... 69
Figure 2-30
Architecture of Logistics Execution ............................................................. 70
Figure 2-31
Shipping Point Determination ..................................................................... 73
Figure 2-32
Route Determination ................................................................................... 75
Figure 2-33
Inbound Shipment Cost Processing ............................................................ 77
© Copyright SAP AG 2010
Internal
vii
SAP Architecture Bluebook: SAP ERP
Figure 2-34
Outbound Shipment Cost Processing .........................................................78
Figure 2-35
Outbound Processing in LE.........................................................................81
Figure 2-36
Architecture Overview of Quality Management ...........................................84
Figure 3-1
Architecture Overview of SAP ERP ............................................................95
Figure 3-2
Architecture Overview of SAP ERP Financials ...........................................97
Figure 3-3
SAP ERP Fin Software Components ........................................................101
Figure 3-4
The Accounting Interface as Integration Hub ............................................102
Figure 3-5
Data Flow in Accounting Interface ............................................................104
Figure 3-6
Financial Accounting Overview .................................................................107
Figure 3-7
Financial Interface .....................................................................................110
Figure 3-8
FI Posting (Classic) ...................................................................................111
Figure 3-9
FI Posting (NewGL) ...................................................................................114
Figure 3-10
Dunning .....................................................................................................118
Figure 3-11
Automatic Payment ...................................................................................120
Figure 3-12
Clearing .....................................................................................................122
Figure 3-13
Tax Accounting ..........................................................................................124
Figure 3-14
Foreign Currency Valuation .......................................................................126
Figure 3-15
InterCompany Reconciliation ....................................................................128
Figure 3-16
Asset Accounting .......................................................................................129
Figure 3-17
Special Purpose Ledger ............................................................................132
Figure 3-18
Cost Objects Relation ................................................................................134
Figure 3-19
Management Accounting ...........................................................................135
Figure 3-20
Profitability Analysis ..................................................................................137
Figure 3-21
Profit Center Accounting ...........................................................................139
Figure 3-22
Collections and Dispute Management ......................................................141
Figure 3-23
Biller Direct ................................................................................................144
Figure 3-24
Credit Management ...................................................................................146
Figure 3-25
Treasury and Risk Management ...............................................................147
Figure 3-26
Cash Management ....................................................................................149
Figure 3-27
Liquidity Planner ........................................................................................150
Figure 3-28
In-House Cash ..........................................................................................153
Figure 4-1
SAP ERP ...................................................................................................159
Figure 4-2
Architecture Overview SAP ERP HCM .....................................................161
Figure 4-3
Architecture of Time Management Application .........................................167
Figure 4-4
Architecture of Payroll Application ............................................................169
Figure 4-5
Schema and Rules Relationships .............................................................171
viii
Internal
© Copyright SAP AG 2010
SAP Architecture Bluebook: SAP ERP
Figure 4-6
Architecture of AES Engine ...................................................................... 173
Figure 4-7
Adobe flash Islands in Web Dynpro .......................................................... 175
Figure 4-8
Architecture overview of Career and Succession Management. .............. 177
Figure 4-9
Architecture overview of Compensation Management ............................. 179
Figure 4-10
Architecture of E-Recruiting ...................................................................... 180
Figure 4-11
Architecture of Enterprise Learning .......................................................... 183
Figure 4-12
Architecture of ESS WD ABAP Applications (Portal Agnostic) ................. 187
Figure 4-13
Architecture of WD ABAP Application based on BOL (e.g. Personal Information Scenarios in ESS) .................................................................. 188
Figure 4-14
Architecture of ESS and MSS Applications .............................................. 189
Figure 4-15
Detailed View of Floor Plan Manager WD Java for ESS and MSS .......... 190
Figure 4-16
Architecture of HCM Processes and Forms.............................................. 193
Figure 4-17
Architecture of EIC (based on CRM) ........................................................ 195
Figure 4-18
Architecture of EIC (based on ECC) ......................................................... 197
Figure 5-1
T Accounts ................................................................................................ 224
Figure 5-2
Software Components used in SAP ERP HCM ........................................ 226
Figure 5-3
PD Objects in HCM and Organizational Management ............................. 227
Figure 5-4
PD Objects in E-Recruiting ....................................................................... 228
Figure 5-5
Business Object Models in SOA ............................................................... 229
© Copyright SAP AG 2010
Internal
ix
Foreword SAP ERP (and the former SAP R/3) is the product which was the main reason for success and growth of SAP in the past. The excellent implementation of functional and quality requirements of our customer‟s business in software was crucial for this success. This book provides the first comprehensive architecture description of the concepts of SAP ERP. An important feature of enterprise standard software is to cover the requirements of many customers in a flexible way, allowing on the one hand standardized processes and standardized software, on the other hand flexibility to tailor the processes to the individual needs. A number of concepts have been developed and combined in SAP ERP to allow both, standardization and flexibility. Also in future, many products and solutions will use SAP ERP functionality via interfaces, either directly or indirectly. Therefore basic knowledge about the architecture concepts of SAP ERP is a prerequisite to develop new products in time and ready for the market. Documenting architecture is much more than just abstracting source code in various types of diagrams. Source code and data type definitions contain no information about development or architecture decisions, and it is very hard to recognize business abstractions in the implementation. This book provides these reasons and business abstractions and fills the gap between user documentation and implementation. Like software, this book is not complete and finished – follow-up editions are planned which will provide additional information such as the central data model of SAP ERP.
Gordon Mühl Head of Architecture Governance and Standards
1
SAP Architecture Bluebook: SAP ERP
Preface Architecture Bluebooks have a long tradition at SAP. Twenty years ago, in 1990, work on the first bluebooks about the architecture of the R/3 basis system started. Since then, an impressive number of internal technical reports about products and technology in SAP were written by skilled writers with deep technical and architectural background. In 2006, the scope of architecture bluebooks was widened to also cover the architecture of SAP business applications. With the architecture bluebooks about SAP ERP Operations, SAP ERP Financials, and SAP ERP Human Capital Management, all major business applications of SAP Enterprise Resource Planning (ERP) have been covered with a bluebook. The content of the three architecture bluebook has been combined in this book, which provides the first comprehensive architecture overview of SAP ERP. Surely you cannot expect learning all details of these applications that took thousands of man years to program and refine. Nevertheless, you will learn a lot about the various business problems and the architecture of the applications that solve these problems. The appendix provides more details and references to further information. Although this book is about the architecture of SAP ERP, a reader will require some basic knowledge of SAP technology such as the Application Server ABAP or the Enqueue mechanism. All architecture diagrams show models following the TAM (Technical Architecture Modeling) notation. This book provides five parts: Part 1. Architecture of SAP ERP, provides an architecture summary of SAP ERP and its main components. Parts 2. SAP ERP Operations, 3. SAP ERP Financials, and 4. SAP ERP Human Capital Management describe the architecture of the corresponding SAP ERP components. Part 5. Appendix provides additional information for each SAP ERP component, such as concrete program names or database tables. The editors want to thank the three authors for their excellent work and their managers for their support. Big thanks also go to the subject matter experts and reviewers. Since readers are always interested in contacts for further questions, the names of the colleagues involved in the architecture bluebooks are listed in each part separately. Finally, the editors want to thank our board and senior management who support our long-term goal to make architecture knowledge tangible.
The Editors Jochen Böder, Bernhard Gröne Architecture Governance and Standards
2
Internal
© Copyright SAP AG 2010
1 Architecture of SAP ERP
3
1 Architecture of SAP ERP
SAP ERP
1.1 SAP ERP Overview SAP Enterprise Resource Planning (SAP ERP) embraces SAP ERP Operations (ERP OPS), SAP ERP Financials, and SAP ERP Human Capital Management, complemented by common Corporate Services. Most industry solutions use or extend SAP ERP functionality. SAP ERP integrates with many other systems, such as SAP Customer Relationship Management (SAP CRM). Figure 1-1 gives an overview of SAP ERP and the most important integration systems. SAP NetWeaver BW (Business Warehouse)
SAP SRM (Supplier Relationship Management) SAP SCM (Supply Chain Management) SAP GRC (Governance & Risk Compliance) SAP MII (Manufacturing Integration and Intelligence)
Industry-Specific Functionality Operations
Financials
Sales and Distribution (SD)
Financial Accounting (FI)
Materials Management (MM) Production Planning (PP) Logistics Execution (LE)
Management Accounting (CO) Financial Supply Chain Management (FSCM)
Human Capital Management ( HCM) HCM Service Delivery (ESS, ...) HCM Extensions (E-recruiting, ...) HCM Core (Payroll, ...)
Corporate Services
SAP CRM (Customer Relationship Management)
SAP ERP
Treasury
Quality Management (QM)
SAP NetWeaver PI (Process Integration)
Figure 1-1
Overview of SAP ERP
1.2 SAP ERP Operations SAP ERP Operations (SAP ERP OPS) is SAP‟s core solution for procuring, selling, producing, stocking, shipping, and transporting of material. Using Sales and Distribution (SD), products are sold and sent to business partners or services are performed for them. Data about products, services and business partners are the basis for sales processing. The sales process is based on a set of business documents such as customer inquiry, quotations, and most important the sales order. These business documents are maintained and stored by SD. Follow-up activities are triggered based on them. The calculation of prices for material and services is based on the condition technique. Production Planning (PP) supports the development and execution of efficient production plans, which takes warehouse, material, and production capacity information as well as
4
Internal
© Copyright SAP AG 2010
SAP ERP
1.3 SAP ERP Financials
sales planning into account. When the production plan is transformed to a production order in order to trigger execution, PP reserves and procures required raw material using MM. Materials Management (MM) provides the functions that are necessary to deal with the inbound flow of goods and services. MM supports procurement using the business documents purchase requisition and subsequently purchase order. The arrival of the ordered goods results in a goods receipt and is handled by the inventory management. MM maintains the central inventory for the complete enterprise, which means that also outgoing material movements are communicated to MM. MM provides a pattern-based user interface implemented in ABAP Dynpro. The purchase requisition functionality is based on a framework. Logistics Execution (LE) controls and organizes the movement of material within the enterprise (warehouse management), but also transportation between enterprises. The central business documents which are maintained and stored by LE are the delivery, the shipment document, and the transfer order. They are used to trigger and control material movement. Quality Management (QM) allows planning and conducting inspections to check the quality characteristics of material. It is integrated in procurement, production, and sales processes. To support reliable business processes across the different ERP OPS components based on consistent data, they are closely integrated using database integration. Based on the same mechanism, SAP ERP OPS communicates with SAP ERP Financials. All components share the same material master data. The functional scope of SAP ERP OPS can be extended by integrating it with the other applications provided by SAP ERP Business Suite, such as SAP Customer Relationship Management, SAP Supply Chain Management, and SAP Supplier Relationship Management.
1.3 SAP ERP Financials SAP ERP Financials (SAP ERP FIN) is SAP‟s core solution for financial accounting, controlling, financial supply chain management and treasury functions. SAP ERP FIN consists of the following application components: Financial accounting (FI) records, classifies, and summarizes the financial transactions of a company. For this purpose financial accounting provides general ledger, accounts payables and receivables, and asset accounting. Financial accounting records business transactions, such as customer invoice, vendor invoice, payment, and clearing, as financial documents. Based on Transaction Figures / Balances on these documents, financial accounting periodically generates the balance sheet as well as profit and loss financial statements which are then reported to the government, investors, and other interested parties.
© Copyright SAP AG 2010
Internal
5
1 Architecture of SAP ERP
SAP ERP
Management accounting (CO) is used for internal accounting within a company to prepare operating data such as product costing, cost of goods sold, overheads, and actual costing of inventory. This operative data is used for the business analysis of the company and to support management decisions. Financial supply chain management (FSCM) processes accounts receivables and accounts payables to ensure a smooth inflow of funds. In addition, it contains collection management, dispute management, online payment facilities for customers (Biller Direct) and vendors (Payer Direct), and credit management to check on credit awarded to a customer. Treasury applications ensure proper cash flow and liquidity of the company for smooth day-to-day operations. Funds, derivatives, securities, loans, financial stocks and market risks are also managed within treasury.
1.4 SAP ERP Human Capital Management SAP ERP Human Capital Management (SAP ERP HCM) is the SAP solution for managing the people working for an organization. SAP ERP HCM is part of SAP Enterprise Resource Planning (SAP ERP), but it can be deployed separately from the other ERP applications to protect sensitive employee data. SAP ERP HCM is split into three layers of applications. The foundation are the HCM core applications which implement the core HR processes such as organizational management, personnel administration, payroll, personal development, and time management. They provide data and functions, which are reused by HCM extension applications which support additional processes such as e-recruiting and enterprise learning. On top reside the HCM service delivery applications, which enable users to interact with the HCM applications via different channels and media, for example selfservices, employee interaction center and online forms. The HCM data model is based on infotypes. One infotype defines the data structure for semantically related data, which is stored together on the database and also displayed together on the user interface. Infotypes support the time-dependent storage of data, which is important in HCM processes. HCM processes are typically country-specific and have to comply with many legal requirements. Infotypes support different country-specific variants of UI logic. Also the business logic can be extended for processing of country-specific logic. In payroll countryspecific payroll drivers have been introduced to provide country-specific payroll runs.
6
Internal
© Copyright SAP AG 2010
2 SAP ERP Operations Author: Sathish Karthik R (IMS Logistics)
2 SAP ERP Operations
SAP ERP
Acknowledgement This bluebook was created during my fellowship with the Office of the CTO - Architecture Excellence team. The following colleagues contributed in various ways to make this or previous editions of the document possible: Rüdiger Buck-Emden, Jochen Böder, Bernhard Gröne, Wolfram Kleis (Office of the CTO), and Ralf Müller (Development Architect) I would like to thank in general the following colleagues Ursula Nani Sven-Eric Eigemann Frank Nuxol Thomas Christ For PP topic I would like to thank mainly the architects Thomas Lehnecke Andreas Siebel For MM topic I would like to thank mainly the architects Markus Wolf Sven Richter Marcel Kieser For SD topic I would like to thank mainly the architects Manfred Hirn Martin Arzt For LE topic I would like to thank mainly the architects Volker Barth Martin Beykirch Thomas Steiner For material master topic I would like to thank mainly the architects Carsten Pluder Rolf Walthemathe For QM topic I would like to thank mainly the architect Holger Ulrich Eisele I would also like to thank the following colleagues for acting as additional reviewers Thomas Gruber Andreas Kasper Michael Eyd Satish Karthik 8
Internal
© Copyright SAP AG 2010
SAP ERP
2.1 Introduction of SAP ERP Operations
2.1 Introduction of SAP ERP Operations Enterprises want to provide the right products and services at the right price, to the right customer at the right time. To achieve this kind of operational excellence business processes in procurement, in logistics execution, in product development, in manufacturing, as well as in sales and service have to work hand in hand. To support end-to-end processes across these areas SAP provides SAP ERP Operations (SAP ERP OPS) as part of the application SAP Enterprise Resource Planning (SAP ERP) as shown in figure 2-1. All applications share one common database. However, it is possible to deploy SAP ERP HCM on a separate system with its own database. SAP ERP FIN, SAP ERP OPS, and corporate services always run on one system.
SAP CRM (Customer Relationship Management) SAP SRM (Supplier Relationship Management) SAP SCM (Supply Chain Management) SAP GRC (Governance & Risk Compliance) SAP MII (Manufacturing Integration and Intelligence)
SAP ERP Industry-Specific Functionality Operations Sales and Distribution (SD) Materials Management (MM) Production Planning (PP)
Financials
Human Capital Management (HCM)
Logistics Execution (LE)
Corporate Services
SAP NetWeaver BW (Business Warehouse)
Quality Management (QM)
SAP NetWeaver PI (Process Integration)
Figure 2-1
Architecture Overview of SAP ERP
The functionality of the SAP ERP OPS is bundled into the following components (see figure 2-2): Sales and Distribution (SD) which includes creation of sales orders, checking the availability of the requested products, price calculation, and finally delivery and billing. Materials Management (MM) which includes creation of purchase orders for procuring material and services from external vendors, verifying incoming invoices, and managing the inventory. Production Planning (PP) which includes planning the production of the materials and execution.
© Copyright SAP AG 2010
Internal
9
2 SAP ERP Operations
SAP ERP
Logistics Execution (LE) which controls and organizes the movement of material1 Quality Management (QM), which includes quality planning, quality inspection, and quality control during sales, production and procurement. For application-to-application-communication (A2A) between the different subapplications – as there are SD, MM, LE, PP and quality management - database integration is used. In addition SAP ERP OPS and SAP ERP FIN are integrated in the same way. In database integration the sending and receiving application share database tables. To transfer data the sending application creates records in these tables, which triggers then follow-up processing in the receiving application. The sending application creates the records in the transfer tables within the same logical unit of work as it stores the business data processed in the transaction. This makes database integration very reliable. Data transfer only happens, when the business transaction can be processed successfully.
2.1.1 Master Data and Reuse Within SAP ERP OPS the most important master data is the material as it is shared across SD, MM, and LE (see figure 2-2). The material master data has a set of attributes which are common and separate sets to cover the specific requirements of sales, logistics, and procurement. Business partner information, such as vendor or customer master data, is not shared. So MM and SD store their own master data versions of their respective business partners. Besides material master the most important master data for PP is the bill of material (BOM), which lists all components required to manufacture a certain product. Routing master data is also used by PP which has information about the operations need to be performed to produce the finished product.
1
In this context material is the general term. It includes products (material which is build from pieces to be sold), goods (material to be shipped), raw material and parts (material as input for production). If a dedicated type of material is intended, we use the corresponding term. 10
Internal
© Copyright SAP AG 2010
SAP ERP
2.1 Introduction of SAP ERP Operations
ERP Central Component General Functions
ERP OPS Applications SD
MM PP
Sales Order Processing
Production Planning
Production Execution
Delivery Processing
QM Billing
Inspection Planning
Purchasing
Batch Management
Inventory Management
Serial Number Processing
Invoice Verification
Handling Unit Management
Inspection Lot Processing
LE Transportation Management
Shipping Processing
Logistics Information Systems
Shipment Costs Processing
ERP OPS
Cross Application Components Central Address Management
Workflow Functions
Document Management System
Classification System
Change Documents Functions
BASIS Components Archiving Functions
Master Data
Customizing Data
Application Data
Material
BOM
Vendor
Customer
Routing
Purchase Orders
Sales Orders
Production Orders
Deliveries
ERP Database
Figure 2-2
Architecture Overview of SAP ERP OPS
Reuse components which are used across all SAP ERP OPS applications are provided either by the general functions, by the cross-application components or within the basis which is part of SAP NetWeaver (see figure 2-2). © Copyright SAP AG 2010
Internal
11
2 SAP ERP Operations
SAP ERP
General functions provide additional functions to support specific processes in the supply chain. Examples are batch management, variant configuration, handling unit management, and logistics information systems (LIS). Cross-application components provide reuse components for all SAP ERP functions. It includes the classification system which allows maintaining characteristics of a material, and the document management system (DMS) for attaching documents (e.g. design or engineering diagrams) to objects (e.g. material master or business documents). The basis component provides central address management, workflow, change document functions for writing the change documents in the transactions, and archiving functions. Enterprises adapt the software of SAP ERP to their individual requirements by maintaining customizing settings. At runtime the customizing data influences the execution of SAP ERP OPS. All application data, master data, and customizing data created and used by SAP ERP OPS is stored in the central database of SAP ERP.
2.1.1.1 General Functions The general functions of SAP ERP OPS provide specific functions to handle material. Enterprises can activate general functions if required. The activation is typically enabled by configuration of the material master. The most often used general functions are described below, however the details of their architecture are not covered within the scope of this book.
Batch Management In various industries particularly in the process industry, there is a need to work with homogenous partial quantities of a material or product throughout the logistics supply chain. This homogenous partial quantity is called a batch. Managing material in batches is required for the following reasons: Legal requirements, for example the guidelines set out by GMP (Good Manufacturing Practice or regulations on hazardous material Defect tracing, callback activities, and regression requirement The need for differentiated quantity-and value-based inventory management, for example, due to heterogeneous yield/result qualities or varying constituents in production. Differences in usage and the monitoring thereof in materials planning in SD and PP Production or procedural requirements, for example settlement of material quantities on the basis of different batch specifications Batch management is integrated in all applications of SAP ERP OPS to support the management and processing of batches in all operational business processes.
12
Internal
© Copyright SAP AG 2010
SAP ERP
2.1 Introduction of SAP ERP Operations
Serial Number Processing Serial number processing is used to identify individual items of material by consecutive identifiers. It supplements the material master record, which contains the attributes which describe the material and are required to manage it. The serial numbers are used in various business procedures within logistics. For each material with a serial number, serial number processing creates a transaction history and tracks its status. The serial numbers can be used within the following business processes: Component involved
Business procedure or operation
Production Planning
Production order
Sales and Distribution
Sales order, inquiry, quotation Delivery and returns delivery Completeness check for deliveries and returns deliveries
Quality Management
Original value recording of inspection lots
Inventory Management and Physical Inventory
Goods movements, Entering the physical inventory count Posting inventory differences
Handling Unit Management When using handling unit management (HUM) multiple materials are can be combined to a handling unit, which movements are tracked within the logistics processes. Goods movements processing deals then with the entire handling units and the materials they contain instead of tracking the movement of each material individually. Handling unit management works together with the existing packing function in shipping and warehouse processing in the warehouse management system.
2.1.2 Integration with SAP Business Suite To support end-to-end business processes, SAP ERP Operations is closely integrated with the other SAP Business Suite applications using RFC (see figure 2-3). The functionality of SD can be extended by SAP Customer Relationship Management (SAP CRM) which provides additional pre-sales functions, and supports marketing and sales order management. Sales orders created in SAP CRM are transferred to SD for further processing such as delivery and billing. In addition SD can be extended by SAP Global Trade Services (SAP GTS) which automates global trade processes in imports and exports. SAP GTS provides tools to exchange required information with government and custom authorities electronically. MM can be integrated with SAP Supplier Relationship Management (SAP SRM) which provides additional procurement functionalities such as shopping cart, maintaining
© Copyright SAP AG 2010
Internal
13
2 SAP ERP Operations
SAP ERP
catalogs for products, contract management, and sourcing. MM and SD can also be integrated with SAP Advanced Planner and Optimizer (SAP APO). SAP APO provides additional planning functionalities such as demand planning, forecasting the requirements for materials, and global availability check for materials. SAP CRM (Customer Relationship Management)
SAP SRM (Supplier Relationship Management)
CRM data
SAP SCM (Supply Chain Management)
SRM data
SAP ECC (ERP Central Component) ERP OPS
SAP NW BI (Business Intelligence)
SAP SNC (Supplier Network Collaboration) SAP APO (Advanced Planner and Optimizer) SAP GTS (Global Trade Services) SAP EWM (Extended Warehouse Managem.) SAP TMS (Transportat. Management System.)
SD (Sales and Distribution)
PP (Production Planning)
BI data MM (Materials Management)
QM (Quality Management)
LE (Logistics Execution)
Integration SAP NW PI (Process Integration) PI data SAP MII (Manufacturing Integration and Intelligence) MII data
Cross Application Components BASIS Components
SCM data
To external Systems and Devices
ERP data
Figure 2-3
Integration Overview of SAP ERP OPS
SAP Extended Warehouse Management (EWM) provided by SAP Supply Chain Management (SAP SCM) enhances LE with functionalities to effectively manage the operations in a warehouse. Transportation management system (TMS) is a part of the SAP SCM solution that provides functions to support the planning and the execution of the transportation of the goods or materials from the shipper to the consignee (party who receives the goods; usually the buyer). Some of the functions include for example service provider management, transportation forecasting, freight order tracking, freight cost calculation and settlement. Supply Network Collaboration (SNC) is a part of the SAP SCM solution that provides a platform for vendors to manage the inventory and handle special processes like 14
Internal
© Copyright SAP AG 2010
SAP ERP
2.1 Introduction of SAP ERP Operations
subcontracting and consignment stocks. Consignment stock is any stock that the vendor has placed in the warehouse of the manufacturer without charge until the stock is used. For analyzing SAP ERP OPS data, SAP NetWeaver Business Information can be connected to the system. Business data is replicated to the business information warehouse, where it is prepared for analysis and reporting. SAP ERP OPS provides business application programming interfaces (BAPI) and enterprise services to access the functionality from outside. Non-SAP applications can be integrated with SAP ERP OPS using SAP NetWeaver Process Integration (formerly known as SAP NW XI) for message transfer, routing, and mapping.. SAP Manufacturing Integration and Intelligence (SAP MII) can be used to integrate external devices such as barcode scanners to track material along the supply chain. For more details about enterprise service provisioning of SAP Business Suite please refer to the bluebook on “mySAP Service Provisioning” [SAP06].
© Copyright SAP AG 2010
Internal
15
2 SAP ERP Operations
SAP ERP
2.2 Material Master Almost all business operations in a company deal with material. Material is procured, produced, stocked, sold, delivered, and transported. As it is typically the same material which is produced, stocked, sold, and so on, it has been decided to maintain common material master data to be used by MM, SD, PP, LE, QM, and SAP ERP FIN (financials, controlling, see figure 2-4). This approach avoids redundant storage and maintenance of material data and ensures consistency within end-to-end business processes. In addition industry or company-specific extensions to material master data structure can be done at a single place.
2.2.1 Architecture Overview Material master data record consists of common attributes shared by all applications and processes, such as material id, name, base unit of measure, and application-specific attributes which are used only in a certain context, for example the cost price of the material which is maintained in the material master is used by the pricing application, the country specific tax details are maintained in the material master is used by SD applications for tax calculation. Similarly production planning makes use of certain attributes of material master like goods receipt processing time and whether the material should be produced in-house during the planning phase.
SAP CRM
SAP SCM
SD
Plug In
MM
Update Material Master Data Maintenance
PP
Stock/Price/Forecast/ Consumption
Material Master Data
QM
FI
CO
SAP ERP
Figure 2-4
Overview of Material Master
In SAP ERP OPS material master is a set of database tables for storing material master data together with a set of read interfaces and maintenance transactions. The common
16
Internal
© Copyright SAP AG 2010
SAP ERP
2.2 Material Master
attributes are stored in a set of tables, which are separated from the tables which store sales relevant data, purchasing relevant data, and so on. Creation and update of material master data can only be performed using the maintenance transactions of material master. These transactions provide the necessary user interface screens, validate the input data, and manage the database access for creating and updating material master data. In general the different applications, which make use of material master, have only read access using the corresponding interfaces. They are only allowed to update some context-specific attributes of material master data, for example MM updates the stock and price information and PP maintains the forecast and consumption data. When SAP ERP is used together with other SAP applications such as SAP SCM and SAP CRM at an enterprise, material master data is created and updated centrally in SAP ERP and data is replicated to SAP CRM and SAP SCM. The material master data in SAP ERP corresponds to the product master data in SAP CRM and SAP SCM. In both cases the exchange of material master data is performed using the plug-in, which exchanges iDocs with SAP CRM and synchronous RFC calls to communicate with SAP SCM. When material master data is updated in SAP ERP OPS business transaction events (BTE) are called which trigger communication with the external systems.
2.2.2 The View Concept of Material Master As mentioned material master data has a set of common attributes as well as applicationcontext specific attributes. Altogether to create one material master data instance a lot of attributes have to be maintained. For displaying and maintaining the attributes on the user interface they are grouped in views. One view embraces a set of semantically related attributes, for example a set of sales-specific attributes or a set of common attributes. Every view is implemented as an ABAP Dynpro screen and displayed as a tab in a tab strip control.
2.2.2.1 View Sequence Which views and also which fields need to be maintained to create a material master data record depends on the intended usage of the material, which is influenced for example by the following factors: Material type2 to which a material is assigned. If, for example, the material is a raw material, the sales screens are not displayed because raw materials are not sold. Industry sector of the enterprise: for example in chemicals industry other attributes need to be maintained than in automotive or retail sector.
2
Material master data is categorized by material type, for example raw material, finished good, and variant material. All material master data instances of one material type share a set of properties, for example raw material cannot be sold or finished goods are produced in-house. Enterprises can create additional material types if required. © Copyright SAP AG 2010
Internal
17
2 SAP ERP Operations
SAP ERP
Organizational level at which data is entered. If, for example, data is entered at plant level only, storage-location-specific fields are hidden. Used SAP application components: in case a company does not use the warehouse management component, the warehouse management views do not appear. So, when creating a material master record the maintenance transactions need to determine which views need to be maintained. As certain attributes depend on each other, also the sequence in which the views are displayed needs to be evaluated. Both are done by the view sequence controller. It determines the next view that needs to be displayed based on the specific material type and the industry sector. Material Master Data Maintenance
Subscreen for Header Data
Tabs for Multiple View Subscreen Area 1
1
Initial Screen
3
2
Subscreen Area 2 Views Selection 3
UI – Org Units Specific
4
Subscreen Area 10
Figure 2-5
Screen Sequence in Material Master
The material master maintenance transactions provide the following view sequence (see figure 2-5): 1. First the initial screen is displayed for entering basic material data, such as material type and industry sector. This information influences which additional views need to be maintained. 2. The view sequence controller triggers the display of the view selection popup. The user can select multiple views which should be maintained for the material 3. The view sequence controller checks whether the selected views require the maintenance of additional organization-specific data. If yes, a corresponding maintenance view is displayed. For example if the purchasing view is selected plant data needs to be maintained and for sales views a sales organization is required. 4. Now the view sequence controller displays the main maintenance screen, which consists of a sub-screen for material master header data and a tab strip offering 18
Internal
© Copyright SAP AG 2010
SAP ERP
2.2 Material Master
multiple views. Each view is implemented by an ABAP Dynpro screen, which consists of one or more sub-screens. The sub-screens are used to group fields. The relationships between the views, screens, and sub screens are defined in customizing. The customizing also allows creating industry-specific materials, such as article in retail. When displaying a view the field selection logic determines the properties of the fields. In customizing every field is assigned to a field selection group which defines whether the field is hidden, displayed, mandatory, optional, and so on.
2.2.2.2 Authorizations Typically in enterprises the material master data maintenance is distributed across different departments. For example the sales department is responsible to maintain the sales attributes and the purchasing department maintains the purchasing views of material master.
User 1..* 1 View Sequence 1
1
Sub Screen
1..* 1..* View
1..*
0..*
1..*
1
1 1
1
Dynpros Screen Container
Maintenance Status
1..* 1
1..*
1 Program
1 1..*
Additional Data View
Figure 2-6
Standard Program or Extensions
1..*
Views and Maintenance Status
Thus it is required that certain views and even attributes are only maintained by certain users. To do so, all views and attributes which should be accessible altogether share the same maintenance status (see figure 2-6). For example all views which display sales attributes have the maintenance status “sales”. Maintenance statuses are also defined for individual attributes. For example the attribute “purchasing group” belongs to purchasing and is not relevant for sales. Hence this field will not appear on a sales view. But if “purchasing group” needs to appear on an
© Copyright SAP AG 2010
Internal
19
2 SAP ERP Operations
SAP ERP
accounting view for some reason the field has the maintenance status of both purchasing and accounting. At runtime when performing authority checks a user can only see and maintain the views and attributes which are assigned to him using the maintenance status.
2.2.3 Database Design of Material Master The database design of material master reflects the view concept (see figure 2-7).
Language
Basic Data
Sales Specific Data
Plant Specific Data
Storage Locn Specific Data
Short Text Data
Unit of Measure Data Additional Data
Application-Specific Data
Material
Client
Sales Organization
Purchasing Organization
Plant
Storage Location
Organization Data
Figure 2-7
Database Table Structure of Material Master (see also Appendix 5.1.1)
There is one central table (MARA) which stores the material ID and references multiple tables with more specific data (see figure 2-7). These tables can be categorized in three types: Basic data: these tables store the header data of material master, such as material group and dimensions of the material (gross weight, net weight, volume). Additional data: these tables store specific common attributes, where a material has typical more than one values. For example there is a table to store all units of measures and another for storing material short texts in multiple languages. Application-specific data: these tables store attributes relevant for a specific application context. Typically these tables correspond to views or sub-screens on the UI. Examples are sales data, plant data, and storage location data. In addition the organizational structure of the enterprise influences how material master data is distributed across different tables. For example the basic data and the additional data are common across all organizational units. The application-specific data is
20
Internal
© Copyright SAP AG 2010
SAP ERP
2.2 Material Master
maintained based on the selection of the organizational unit chosen from the view popup (see figure 2-5). If for example the plant 0001 is entered, meaning the material can be maintained only for the plant 0001 and the plant specific tables are affected. This data however can be accessed only if the plant 0001 is used by the application. The same holds true for all other organizational units like sales organization and storage location. The view together with the organizational data determines which tables store the information of the material.
© Copyright SAP AG 2010
Internal
21
2 SAP ERP Operations
SAP ERP
2.3 Business Partner Master Data A company has different business relationships with different business partners. In dependence of the relationship the business partner acts as a customer, vendor, employee, or contact person. Within a business transaction a specific business partner can fulfill multiple functions. For example SD deals mainly with selling products and services to the customer. The different functions of a customer in a sales process are the following: Sold to party Bill to party Ship to party Payer In SAP ERP OPS these functions are called partner functions. They are assigned to a partner type, which is for example customer, vendor, and logistic provider. The different SAP ERP OPS applications store the business partner master data for their partner type separately. So SD owns the customer master data, MM owns the vendor master data, LE owns the logistic provider master data, and so on. There is no central business partner storage and maintenance like for material master data (see chapter 2.2). However there is some central functionality which is re-used by the master data of all partner types: Partner determination Address management Partner determination is used to determine the partner functions and their values which are required by a business transaction. For example sales order processing triggers partner determination to get the mandatory partner functions that includes sold to party, bill to party, ship to party and the payer and other partner functions (like forwarding agent) if determined and also the corresponding partner address that needs to be used. Address management is a framework for storing and retrieving address data which belongs to business partner master data.
2.3.1 Partner Determination As the partner functions vary for different business document types the superset of partner functions for a specific business document type is defined by a so-called partner determination procedure. At runtime partner determination determines the partner functions required in the specific business context. Partner determination is called during the processing of header of business documents, such as sales order, purchase order, and delivery. In the following we use sales order processing as an example to describe the architecture of partner determination.
22
Internal
© Copyright SAP AG 2010
SAP ERP
2.3 Business Partner Master Data
When a sales order is created, the customer name is entered as sold-to party. To do so, the user can select an existing customer master data record or create a new one. Then sales order processing calls partner determination, which performs the following steps (see figure 2-8): Partner procedure determination selects the partner procedure which is valid for sales order Sales order header processor triggers partner determination logic for the selected partner procedure Partner determination logic evaluates customizing rules to identify which partner functions are required for the current sales process, for example ship-to party, bill-to party, and payer and what is the data source (for example customer master) to determine each partner function. Partner determination logic calls central address management to retrieve the address data which correspond to the address numbers. The data is copied to the sales order document. The partner functions can also be passed on to pricing or output determination for further usage.
R
Header Processor
Partner Determination Logic
Partner Buffer Data
R
Partner Procedure Determination
Address Number
Logic for Partners
Central Address Management Sales Document Processing
Sales Document Data Customer Master Data
Figure 2-8
Address Data
Operational Customizing Data
Partner Determination and Address Management used in SD
© Copyright SAP AG 2010
Internal
23
2 SAP ERP Operations
SAP ERP
2.4 Sales and Distribution The Sales and Distribution (SD) application of SAP ERP OPS provides the necessary functionalities to sell products and services to customers. This includes sales order processing, creating delivery and shipment documents, delivery monitoring, billing, and also returns handling.
2.4.1 Architecture Overview To provide the required functionality SD contains four main components (see figure 2-9): Sales order processing Delivery processing Outbound shipment processing Billing Sales order processing is responsible for creation, update, and persistence of the sales order documents. It triggers availability check and pricing calculations as well as delivery. Delivery processing creates delivery documents for a sales order document. It triggers shipment, monitors the delivery, and finally initiates billing. Outbound delivery processing takes care of the transportation of the ordered products to the customer. Billing creates and sends the customer invoice. It is closely integrated with the SAP ERP FIN application, where the received payments are tracked. All sales documents such as sales order, delivery, and invoice use material and customer master data. In the following the SD architecture is explained by describing a standard sales process.
2.4.1.1 Pre-Sales Processing SD allows sales departments to perform pre-sales activities via inquiries and quotations. If a potential customer asks for example about the details of a product or price, the sales department creates an request for quotation (RFQ) document (also known as inquiry) using the pre-sales processing component (see figure 2-9). The response of the sales department is documented as quotation with a reference to the RFQ document. The quotation contains already information such as price of the product and discounts. Output determination (see chapter 2.4.3.3) is used to identify the communication channel (e-mail, letter, fax, B2B message) with which the quotation is sent to the customer. In addition SD provides functions for maintaining the sales activity data, contact persons, interested parties, promotions, and competitor data.
24
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
Sales Order Processing Replicated Master Data Sales Orders
SAP GTS
R
RFQ / Inquiry
Sales Order Processing
Billing Delivery
Billing Documents
Sales Orders
Sales Activity
Replicated to ERP
Pre sales Processing
Conditions
Delivery Orders
SAP CRM
Business Partner
Product
R
Availability Check
Sales and Distribution (SD) Trigger ATP check
R
R
Purchase Material
Produce Material R
Shipment Processing
Pricing
Ship / Deliver
Master Data R
Material
R
Business Partner
Global ATP Logic
PP Materials Requirement Planning (MRP)
SAP APO
FI / CO FI Data
R
Planned Orders
ControllingProfitability Analysis Financial Accounting
Production Orders R R
Goods Issue Processing
Goods Issues
Goods Receipt Processing
Goods Receipts
Purchase Order Processing
Purchase Orders
Purchase Requisition Processing
Purchase Requisition
R
Invoice Verification
Update
Materials Management (MM)
Figure 2-9
Inventory
Architecture Overview of Sales and Distribution
2.4.1.2 Sales Order Processing The most important activity in the sales process is the creation of the sales order document which is the first step towards the actual sale of a product. The sales order © Copyright SAP AG 2010
Internal
25
2 SAP ERP Operations
SAP ERP
document is structured in header, items, and schedule lines which store the following information: Sales Order Header: o Sales order ID and type o Customer name and address Sales Order Item (one or more): o Products ordered by the customer o Quantity of the product to be delivered o Schedule line for each separate delivery which includes quantity to be shipped, date of delivery, and ship to location Header, item, and schedule lines are stored in separate database tables. The header can have multiple items and each item can have multiple schedule lines. The characteristic of an item (for example standard item or third party item or a free item) is defined by the item category. Likewise the characteristic of the schedule line is determined using the schedule line category. A sales order can be created by converting a purchase order document into a sales order or by referencing a quotation. In both cases data such as customer and product data, is taken over from the original document. When a sales order is created, the sales order processing component triggers various functions like price determination, checking the availability check of the requested product, and partner determination to identify involved partners (see chapter 2.3.1). If the requested products are on stock sales order processing informs outbound delivery processing for delivering the products to the ship-to-location. If the products need to be procured from a third-party vendor sales order processing creates a purchase requisition and sends it to materials management (MM). If the products need to be produced inhouse sales order processing transfers the requirements to materials requirement planning in production planning (PP).
2.4.1.3 Outbound Delivery Processing Delivery processing prepares the shipment of the ordered products to the ship-to location by creating the outbound delivery document. The delivery document is created with reference to the sales order. While creating the delivery document the shipping point which embraces the loading point and the persons responsible for delivery is determined (see chapter 2.7). Delivery processing triggers picking of the ordered products from stock, packing them and finally shipping them. Each step is documented in the delivery document. If the products need to be transported to the customer, delivery processing initiates shipment. Else it initiates goods issue processing in MM to update the inventory. In the inventory the quantity of material is reduced by the products sold and delivered.
26
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
2.4.1.4 Outbound Shipment Processing Shipment processing which embraces transportation planning and execution is provided by logistics execution (see chapter 2.7). During this process the outbound shipment document is created which contains all deliveries which are shipped together. Shipment processing determines the way of transportation, such as flight, truck, or train, the route, but also the responsible logistic provider or forwarding agent. This information is stored in the shipment document together with the references to the deliveries. All costs that are raised by the transportation are recorded using the shipment cost document (SCD). The freight costs or the shipment costs settlement is possible only after the outbound shipment document is created. After the products have left the plant or warehouse, shipment processing initiates goods issue processing to update the inventory in MM.
2.4.1.5 Billing When the customer has received the ordered products, which is tracked in delivery processing by the proof of delivery document, billing is performed. During billing invoices for the delivered products are created. A billing document is generated in this process which facilitates the payment processing by the financials. The automatic G/L account determination happened during the billing to debit the customer receivables account and credit the revenue account. The billing document is created either with reference to the sales order or the outbound delivery document. The invoice is then sent to the customer by mail, fax, e-mail as determined by output determination.
2.4.1.6 Returns Order Processing Customers can return a product delivered in case it does not fit their expectations or is damaged. SD supports handling these returns using the returns order. The returns order is a sales order of a particular type which is created with reference to the existing sales order or billing document. Returns order processing creates then a returns delivery, where the receipt of the returned material is documented. At last a credit memo is posted to billing which pays the customer back.
2.4.2 Integration 2.4.2.1 Integration within SAP ERP SD is integrated with PP, MM, and SAP ERP FIN using database integration. SD transfers requirements to PP in order to trigger in-house production of the material sold. PP is responsible for planning the production, monitoring the execution of the production and for reporting the produced materials to update the stocks in inventory management. The sales order reserves the quantity through the availability check functions and when the material is delivered to the customer the stock is reduced and the corresponding requirements in the PP are reduced and reflect in the stock monitors.
© Copyright SAP AG 2010
Internal
27
2 SAP ERP Operations
SAP ERP
If the material is not produced in-house but procured from a third-party vendor, sales order processing creates a purchase requisition directly and passes it over to MM (see figure 2-9), where the purchase requisition is converted to a purchase order and sent to the vendor. The billing document generates financial postings in FI. FI is responsible for getting the payments from the customer. The controlling-profitability analysis (CO-PA) of SAP ERP FIN is updated with the details of the revenue and the cost from SD functions for analyzing the profitability of the company.
2.4.2.2 Integration with SAP Business Suite SD can be integrated with the following applications of SAP Business Suite (see figure 2-22): SAP CRM SAP SCM that includes SAP APO and GTS SD can be used in combination with SAP CRM. In this case sales orders are created in SAP CRM and the SD functions are called in the SAP ERP OPS to fulfill the order requirement. This is done by the replication of the sales order in the ERP and the followon process happens in the ERP from delivery to billing. Once the billing is done the billing status is updated in the SAP CRM sales order from ERP. This is done via the CRM middleware component which is a part of the SAP CRM. The middleware is responsible for the handshake between the SAP CRM and SAP ERP OPS. Another aspect is the master data replication, the customer master and the material master data in the SAP ERP OPS are replicated to the business partner data and the product master (which has additional fields compared to material master) respectively in the SAP CRM. In addition, the condition masters are also replicated both ways. However, a change to the conditions is only possible by the system which created the conditions. The SD functions like availability check (see chapter 2.4.4 for more details) can be triggered in the SAP APO systems as SAP ERP has certain limitations like the check is carried out in the local inventory and the system always assumes infinite capacity is available for the production of the material. The SAP APO provides additional features such as search on alternative locations propose alternative products and check against actual production plan taking into account the capacity constraints.
2.4.3 Pricing For every product or service sold, as well as procured a price is required. The sales organization decides the price with which a company sells a material or service to a customer (selling price) and the purchasing organization decides the price at which a material or service is procured from the vendor (cost price). But a price is not just a fix number. The overall price of a material (net price) consists of a base price (gross price) plus for example taxes, discounts and surcharges which may
28
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
vary from customer to customer depending on the nature of business, location, and so on. In addition, the price of a material depends on the market and varies from time to time based on external parameters, for example tax regulations and seasons. SD provides a pricing component to define, manipulate, and retrieve pricing data for day to day business operations. In pricing the different factors which influence a price are called pricing elements. These are for example taxes and discounts. When sales order processing requests a price, the pricing component first provides the base price that‟s maintained for the material. Afterwards it calculates the net price based on the various pricing elements, which have to be taken into account. This eliminates the manual determination of the price for a material. However the price that‟s automatically proposed by the pricing component can also be overridden manually. The pricing component was originally provided for SD, but is now also reused in MM. The following explanation focuses on pricing in SD.
2.4.3.1 Condition Determination in Pricing From an architecture perspective the main challenge is to offer a framework which is on one hand flexible enough to perform the different price calculations which enterprises require, while on the other hand operates accurate and with high performance. To achieve this condition technique has been developed. Basically a condition defines a rule to determine a certain result value. The result value depends on selected influencing factors (such as customer, customer group, and material) and is valid for a specified period. An example of a typical condition is: the gross price of material A between certain dates of validity from vendor A will be 1 EUR / 1 Kg. The condition determination technique is based on a look-search-match strategy: Look up which tables contain relevant conditions Search the identified condition tables in a predefined sequence Match every record in the condition tables with the input parameters The condition technique is such a successful approach, that it is not only used for pricing, but also for other use cases where a result value has to be determined based on multiple influencing factors and rules. Examples are account determination and output determination. The following example illustrates how price conditions are maintained and determined (see figure 2-10). In this example the requirement is to find the base price for material A provided for pricelist 01. The requirement then has to be matched with every record in the tables defined for access, in the above example condition table TABLE1 and condition table TABLE2 are accessed. The different pricing elements (price, discounts, freight charges etc) are stored as condition types. The pricing procedure (aka pricing schema) embraces all condition types
© Copyright SAP AG 2010
Internal
29
2 SAP ERP Operations
SAP ERP
that can be used in business transactions. The pricing procedure can be customized to the company‟s needs. Requirement : To find the price of material A , given pricelist is 01 Pricing Procedure No.
Condition Type
1.
PRICE
2.
DISCOUNT1
3. 4.
DISCOUNT2 FREIGHT CHARGES
Access Sequence Lookup Cond Type
Access Sequence
PRICE
0001
DISCOUNT1 DISCOUNT2
-
FREIGHT CHARGES
-
ACCESS SEQUENCE 0001 TABLE 1 Pricelist/ Material TABLE 2 Material
Condition Table TABLE1 Cond Type Pricelist PRICE PRICE PRICE
02 01 02
Material …. Cond Record No A B B
100 101 102
Access failed as no record for A with pricelist 01
Condition Table TABLE2 Cond Type Material
…. Cond Record No
PRICE
A
200
PRICE
B
201
Access successful for A
Master data Cond Record No 100 200
Cond Type …..
Price
PRICE PRICE
1000 ( EUR) 2000 ( EUR)
Price found 2000 EUR
Figure 2-10 Condition Technique – Example
30
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
The condition determination technique starts with the pricing procedure (see figure 2-10). In our example the expected result value is the price (base price). So first condition determination checks in the pricing procedure table if “price” is listed as condition type. In the next step condition determination has to identify all tables which store conditions for price. In the example there are exactly two condition tables for price: TABLE1 and TABLE2. The question is which should be searched first. The sequence in which condition tables should be searched is defined by the access sequence which is stored in the access sequence lookup table. Condition determination determines the access sequence and starts to search the corresponding tables. Once a condition record is found which corresponds to the input parameters, the system will not access further condition tables. When defining the access sequence it is important to define the tables that need to be searched in a way that the maximum number of key field combinations is searched first, followed by the next smaller key field combination and so on. In the above example material and plant have the biggest number of key combination of condition table 1 and only material is the key for the condition table 2, so the sequence in the example is first condition table TABLE1 and then TABLE2. Every record in a condition table that‟s used for matching is called condition record. The key fields in the condition tables are called access keys. In our example the input parameters price and material A are met in TABLE2, where plant-independent conditions are listed. The actual price of the material is maintained as master data (see figure 2-10). When the matching is successful the condition record number is used to get the price value from the corresponding material master record. In our example 201 is the condition record number, so the price of material A at plant 001 is 2000 EUR.
2.4.3.2 Pricing Architecture In SD pricing is triggered by sales order processing (see figure 2-11). When a sales order document is created, sales order processing determines the pricing procedure based on the parameters defined in customizing like sales order document type and sales organization. Each sales order document has only one pricing procedure. Each time a material is added to a sales order item, sales order processing sends a request to the pricing engine. There the pricing pre-step logic calls the condition processor reuse layer to get the pricing relevant customizing data such as condition types used in the schema and access sequences. The pre-step logic loads these tables into the pricing buffer. The buffer is used to improve performance, especially when multiple prices need to be calculated. The pricing logic is then responsible for getting the result values of the condition types that are required by the sales order. For each condition type the pricing logic sends a request to the condition processor to determine the actual value based on the condition technique (for details see chapter 2.4.3.1).
© Copyright SAP AG 2010
Internal
31
2 SAP ERP Operations
SAP ERP
The base price is retrieved from material master data.
UIs
Document Flow – Copying Rules
Item Category
SD Operational Control Customizing Sales Order Item Processing
R
Pricing Pre-Step Logic
Pricing Schema Determination
Sales Order Processing
Pricing Buffer Data
R
Pricing Result Data
R
Pricing Logic
R
Pricing Engine
Pricing Analysis R R
Condition Processor - Reuse Layer
Condition Schema
Condition Type
Access Sequence
Access Tables Condition Customizing Data
Pricing Master Data
Figure 2-11 Architecture of Pricing In pricing, the condition processor is used to determine the pricing procedure and its condition types. For condition types with complex rules, such as base price and net price, access sequences and condition tables are evaluated. Finally the pricing engine sends the complete selling price together with the individual values of the different condition types (gross price, discount, etc) back to sales order processing. The result of the price calculation is made persistent within the sales order document (see figure 2-11). The pricing engine provides ABAP Dynpro sub-screens that can be reused by applications that provide pricing functionality. In addition it provides a pricing analysis tool which is used by pricing experts for analyzing the price calculation process for the specific
32
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
sales order document, such as the condition types that were used, the condition tables that were accessed at runtime, and the table from where the price was picked up. In customizing the copy rules for pricing from source document to target document are specified. For example when a delivery is created with reference to sales order the pricing conditions are automatically copied to the delivery. In addition the item category determines if the pricing functions at all have to be triggered in the first place. For example in case of free goods pricing is not relevant.
2.4.3.3 Condition Determination Technique - Reuse The condition determination technique is used in SAP ERP OPS not only for price determination, but also for other use cases, where a value needs to be determined based on defined rules. Currently condition determination is used for the following usage (see figure 2-12): Pricing Output control Account determination Material determination / exclusion Taxes Free goods/Bonus buy
Applications
R
Usage
R
Output Control - OC
Pricing
R
R
R
R
Account Determination
R
Material Determination
R
R
Material Exclusion
R
R
Free Goods / Bonus buy
R
Condition Determination Processor
Pricing Condition Customizing
OC Condition Customizing
Account Determination Condition Customizing
Mat Determination Condition Customizing
Material Exclusion Condition Customizing
Free Goods / Bonus buy Condition Customizing Customizing
Figure 2-12 Reuse of Condition Determination Technique To distinguish between the different calling applications the condition determination processor requires as input the application, which sends the request, as well as the
© Copyright SAP AG 2010
Internal
33
2 SAP ERP Operations
SAP ERP
intended usage. Thereby usage defines the function which uses the condition technique for example pricing, output control, and so on. Since it can make a difference for condition determination, from which application it has been called, this information is required, too. For example pricing can be triggered from the application SD and MM, but with different condition tables. Every usage and application has their own condition data maintained in customizing (see figure 2-12): The condition determination processor can only access data that belongs to the application and usage, which sends the request. Figure 2-13 shows the relationship between usage, application, condition type, access sequence, and condition tables (for details on condition type, access sequence, and condition tables, see chapter 2.4.3.1).
Usage
1 1
1 1..* Applications
1 1..* Access Procedure / Schema
1 1..*
1
Condition Types
1..*
1 0..* 1..*
Access Sequence 1 1..*
1..*
Condition Tables
1
1..*
Access Fields
1..*
1 Pricing Table Master Data
Figure 2-13 Conditions Customizing for Pricing In the following we explain one other important usages of condition technique, which is output determination.
Output Control In SAP ERP OPS can perform communication with business partners (Business-toBusiness, B2B) using letter, fax, e-mail, or electronic message exchange. To figure out which communication medium should be used in a specific business transaction, output control is used.
34
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
Output control is based on two process steps (see figure 2-14): Message output determination that uses condition technique Actual output of the messages via EDI, print or fax The message determination is controlled via a message output schema that every message type is assigned to an access sequence which is a search strategy to find the output record from the set of condition tables. Afterwards message output assembles and sends messages according to the input from message determination. The following figure 2-14 represents the message determination and processing.
Sales Order Processing
Purchase Order Processing
Delivery Processing
Customizing Data Relevant for Output Determination
Applications R R
Propose Results Message Deteremination Logic Condition Technique Reuse Logic
R
Message Status Data Update Status Message processing logic R
Print Processing
R
R
EDI IDOc Processing
FAX Processing Processing Programs Output Control
Figure 2-14 Output Control All the applications that require performing B2B communication uses the message based communication which is based on the condition technique. The message determination reuses the condition technique to find the appropriate message type and format for the current business transaction. The first step in any of the above transaction is to determine the message output schema that is valid for the current transaction. For example the purchase order can have a schema totally different from the sales order. The schema consists of a set of output message types for example purchase order printout, reminder, and goods receipts slip. Once the message output schema is determined the application calls the message determination logic. The message determination logic prepares to call the reuse condition technique that results with all the valid conditions for the current transaction.
© Copyright SAP AG 2010
Internal
35
2 SAP ERP Operations
SAP ERP
The result is an output record which defines the communication medium, the number of copies, and the time at which the message should be sent. The results are proposed back to the transaction and also stored in the message status table which acts as a reference for the message processing logic. The message processing logic is a separate program that is used to run immediately or can be scheduled for a certain point in time. This program picks up the result from the condition determination. The message processing logic constructs the application data at runtime from the entries of the message status table. Based on the processing medium like printer, EDI or fax the processing logic then calls the respective processing routines which finally dispatch the message to the recipient. The status is also updated in the message status table. In case of EDI processing, the output is an iDoc (Intermediate document) that is sent electronically to another SAP or a third-party system. iDoc‟s allow different application systems to be linked via a message-based interface. An iDoc consists of three important sections Control record (has details about the sender, receiver etc) Data record (application data) Status record (IDoc created, successfully sent, failure etc) In this case the sender and receiver systems have to be set up initially for IDoc transfer. The system that sends the IDoc output is called the outbound system and the system that receives the IDoc is the inbound system. The message determination and dispatching happens from the outbound system where the message processing logic calls the outbound function modules to map the application data structure to a standard structure which the other system understands. In this case the message determination just determines the output type as IDoc and all the processing is done by the IDoc processing logic.
2.4.4 Availability Check When a customer places an order, he expects the requested amount of material to be delivered on a certain date to his destination. So the selling party is interested to check, when the requested material is available to be shipped to the customer. For this purpose SD provides the availability check, which performs basically the following: Check in the inventory, if the material is on stock. If not check if the material is produced or procured and when it will be available Check if the material is reserved for another customer or for inspection Finally availability check calculates the date, at which the material is available in the inventory. This date is referred to as the material availability date (MAD). The final delivery date displayed in the sales order however takes also time for packing, loading, and transportation into account.
36
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
The availability check is intensively used by sales order processing in SD, but also called from MM, PP, and LE. As an alternative to the availability check provided by SD, sales order processing can also call the availability check provided by SAP APO. SD provides the following basic methods to perform the availability check: Availability check on the basis of the available-to-promise (ATP) quantities The ATP quantity is calculated from warehouse stock, the planned inward movements of stock (receipts) documented in production orders, purchase orders, planned orders, and the planned outward movements of stock (issues), such as sales orders, deliveries and reservations. Availability check against planning The check against planning is performed against independent requirements which are usually created for an „anonymous‟ market. These requirements result from demand planning and are used for planning expected sales quantities independent from individual sales-orders. Availability Check against product allocation Product allocation facilitates period-based distribution of products for certain customers (or customer groups) or regions. This ensures, for example, that when production is low, the first customer does not get the full amount, resulting in following sales orders not being confirmed or being confirmed far too late. Sales order processing usually uses the availability check on the basis of ATP quantities, in short called ATP check. In the following the architecture of the ATP check is explained.
2.4.4.1 Availability-to-Promise Check When a sales order is created a sales order item is added for each material the customer orders. The quantity of material requested by the customer at a certain delivery date is stored in the schedule line of the corresponding sales order item. The schedule line category defines if the ATP check needs to be carried out or not. For example for schedule lines of a returns order no ATP check is executed. When the ATP check is performed for a schedule line, the material, the quantity, and the delivery date requested by the customer are used as input. ATP check performs now the following steps: Check in the inventory, if the requested quantity is available Check if there are planned receipts of the material by evaluating goods receipts, stock transfer orders, planned orders, production orders Check if material will be procured by evaluating purchase orders Check if there are already requirements from other sales orders which reserve quantities of the material Check if the material is reserved by production planning Retrieve from material master how long it takes to procure or produce the material
© Copyright SAP AG 2010
Internal
37
2 SAP ERP Operations
SAP ERP
As output the ATP check calculates the available quantity for the requirement date. Additionally the material availability date is calculated. If no quantities can be confirmed then zero quantity is returned. If only partial quantities are available then ATP check proposes the partial quantity as confirmed quantity. When the requested delivery date of the customer can be confirmed, sales order processing reserves the amount of material by storing a requirement. A requirement describes which quantity of material is needed by a sales order at a certain point in time. So in this context requirement means a kind of material reservation. The requirements are used by the ATP check logic to make sure that quantities that are already reserved for other sales orders are not taken into account when confirming quantities for a new sales order. Requirements are also used by PP and MM to provide the requested material in time. This process is called transfer of requirements (TOR) and it triggers either the production or the procurement of the requested material. Once the material is available in the inventory the corresponding requirements are deleted. The material is ready for delivery.
Control Parameters to Activate ATP Check As mentioned there are three types of availability check which are supported by SAP ERP OPS (see chapter 2.4.4). In order to trigger the appropriate availability check the following control parameters have to be evaluated (see figure 2-15): Requirement type Requirements class Checking group Checking rule The requirement type defines whether the requirement is a customer requirement, noncustomer requirement (independent requirement that comes as a demand) or warehouse requirement. The requirement class defines the type of availability check. For sales order processing it ensures that the ATP check is carried out. In addition it defines, if the requirements has to be passed to production or not. The second scenario is used, when an ATP check is executed without reservation. How a requirement is passed to production is defined by the checking group. So for example the checking group can define, that requirements should be collected daily or weekly and then transferred or that individual requirements for each sales order should be handed over. The checking group together with checking rule determines the scope of the availability check, for example what type of stock should be considered and what type of orders should be taken into account.
38
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
PP/SD Specific Control Parameters
SD Specific Control Parameters Sales Order Item
1
1..*
Item Category
1
MRP Type
1
1 1..*
1
Schedule line
1
Requirement Type
1..*
1
Requirement Class
1 1 Schedule Line Category 1
1
1
Availability Check
Checking Rule Hard coded for SD
1
Checking Group
Availability Check Specific Control Parameters
Figure 2-15 Control Parameters for Availability Check in SD Figure 2-15 shows the relationships between the different control parameter and in addition the SD and PP components that are required to facilitate the transfer of requirements to production. Each item category together with material requirement planning (MRP) type determines the requirement type. MRP type is a procedure that determines how the material has to be planned. For example if the material has to be planned based on forecasting , reorder etc. This information comes from material master. Every requirement type is associated to a requirement class in the customizing. As requirement class is general there can be many requirement types that a requirement class contains. The requirement class has the option to activate the availability check. Much finer control of the availability check can be obtained through the schedule line category. The other parameter that also has to be considered for the check is the checking rule and the checking group. Every material has a checking group associated to it and the information of the checking group comes from the material master data.
2.4.4.2 Architecture of ATP Check The request for an ATP check can be sent from different sources for example sales order processing in SD, stock transport order processing in MM or from external requested by a BAPI (see figure 2-16). The ATP logic is encapsulated inside an ATP controller that acts as a service provider.
© Copyright SAP AG 2010
Internal
39
2 SAP ERP Operations
SAP ERP
UI Update Delta management Logic
Avail Check Request 1 Ex :Sales Order
R
UI Avail Check Request 2 Ex :STO
BAPI UI Applications
Sales Order Requirements Data
Reservation Data
Availability Check Monitors
R
ATP Explanation Error Handling Logic
SAP APO RFC
RFC
R
R
Preprocessor
R
ATP Logic
R
ATP Server Call Interface
R
Error Handling Logic
RFC
ATP Controller
ATP Logic
Consistency Check Delta Merge
Sales Order Requirements Data
Reservation Data Shared Buffer
Buffer Preload Logic Buffer Monitors ATP Server Optional
Figure 2-16 Architecture of ATP Logic There are three options for performing the ATP check: By the local SAP ERP system By an connected ATP server which is called via RFC By SAP APO which performs a global ATP check The server-based set up provides better performance and scalability (see below). The global ATP check provided by SAP APO is not in the scope of this book. The ATP controller includes a preprocessor that determines whether the call has to be routed to SAP SCM APO. If not then the request is forwarded to the ATP server call interface. If a dedicated ATP server is connected, the ATP server call interface calls it via RFC. Otherwise the ATP logic is triggered locally within the ATP controller. As mentioned during the ATP check the ATP logic evaluates the existing sales order requirements as well as reservations from production planning, transfer orders, purchase
40
Internal
© Copyright SAP AG 2010
SAP ERP
2.4 Sales and Distribution
orders, production orders, and material master. The elements which are actually taken into account can be widely controlled via the ATP customizing (checking scope). Based on this information the ATP logic determines if the material is available and if so confirms the quantity which is available to the proposed material availability date. In addition the ATP controller takes care of error handling and provides transactions to monitor the results of the availability check.
Architecture of ATP Server The ATP server is an option to improve the performance of the ATP check. It is an additional installation and configuration option of SAP ERP.
Application Server
Avail Check Req1
Application Server
Avail Check Req1
Avail Check Reqn
Avail Check Req2
Enqueue Server
Avail Check Reqn
SAP ERPInstance
Sales Order Reservation Requirements Data Data SAP ERP DB
ATP Logic + Buffer Synchronization
Sales Order Requirements Data
Enqueue Server
Reservation Data Shared Buffer ATP Server
Figure 2-17 Architecture of ATP Server The ATP server improves the performance as a result of two features Shared Buffer ATP-Server stores specific ATP relevant database information such as requirements and reservations in main memory thus eliminating expensive database reads during the ATP check. Aggregation When requirement records are loaded into the shared buffer they are stored aggregated by plant, requirement date, requirement quantity, and confirmed quantity.
© Copyright SAP AG 2010
Internal
41
2 SAP ERP Operations
SAP ERP
Requests for ATP check is sent from the ATP server call interface to the ATP server via RFC (see figure 2-16). The calls are enqueued in the enqueue server (see figure 2-17). Hence it is a mandatory requirement to have an enqueue server attached to the ATP server. The initial load in the shared buffer can happen by running certain tools already provided for ATP or as an alternative the administrator can manually load the shared buffer using the buffer monitor (see figure 2-16).When the availability check is in progress the buffered data needs to be locked so that no other application can modify the shared buffered data. The locks for buffered data are set within the ATP server‟s enqueue server. Once the availability check is finished the buffer is updated and the entries in the enqueue server are removed so that the next application can use the ATP logic. The SAP ERP database and the ATP server buffer are synchronized using delta management. After sales order processing has executed the ATP check by calling the ATP call service interface it creates a requirement record to reserve the material and simultaneously updates the delta management (see figure 2-16). The delta management retrieves the old and the new data, aggregates the data and sends the information to the delta merge functions in the ATP server via RFC. The ATP server then updates the shared buffer. In this way it is ensured, that the ATP check is always performed on up-todate data. The ATP server takes care about error handling and provides tools to synchronize the buffer with the SAP ERP database in case of any inconsistencies.
42
Internal
© Copyright SAP AG 2010
SAP ERP
2.5 Production Planning
2.5 Production Planning Manufacturing is the use of tools and labor to create finished goods from raw material or assembly parts. In SAP ERP OPS manufacturing processes are supported by the production planning component (PP) which makes sure that the sales demand is met by producing the requested materials in time. Logically PP in SAP ERP OPS can be divided into two functional parts: Production planning phase Production execution. The basis for production planning is the sales plan, which defines the demand of a certain product over time. Production planning allows simulating and planning the production in a way that the required products are available for sale in time. Production execution initiates and monitors the actual production. It triggers for example the procurement of raw material required for production, reserves material in the inventory for production, and initiates transfer of material from warehouse to production site. Production execution in PP does not control the assembly line or the shop-floor scheduling of the production site. But corresponding third-party applications can be integrated with PP using enterprise services or BAPIs. Finally the produced material is listed in the inventory and put into the warehouse. For this PP is integrated with MM and LE. Manufacturing is driven by requirements. A requirement is a quantity of a specific material that is needed on a certain date in a plant. Requirements can arise directly from a sales order (make-to-order) or from production planning (make-to-stock). In the first case the ATP-check which is initiated by sales order processing, creates the requirement (see chapter 2.4.4). In different industries production planning and execution are processed in different ways. For example in process industries like pharmaceuticals the materials are produced and managed in batches (for batch management, see chapter 2.1.1.1).
2.5.1 Master Data The master data that is required for production planning and execution is bill of materials (BOM), routing, work center, and material master. The bill of materials (BOM) is the complete list of components that make up a product or assembly. The list contains the component names, its ids and the required quantities. The BOM is required for all production planning and execution activities. Within a plant the work center describes the place where a production operation is carried out. For each work center the production capacity (manpower and machines) is defined. Routing defines the list of the production operations to be performed, their sequence and various work centers involved in manufacturing the material.
© Copyright SAP AG 2010
Internal
43
2 SAP ERP Operations
SAP ERP
The material master (see also chapter 2.2) provides separate views which include attributes required for producing the material. For example the material requirement planning view has all information related to the planning of that material like MRP type: is a configuration setting for the MRP planning program. This indicator differentiates whether the planning happens for the finished product or for subassemblies (see also chapter 2.5.3.4) or for all sub-components as well. Procurement type: defines whether material is produced in-house or procured externally MRP controller: person responsible to run the MRP in the plant The material requirement view of a material can vary from one plant to another.
2.5.2 Integration 2.5.2.1 Integration within SAP ERP Production planning is integrated to SD and MM via database integration. SD triggers planning through the availability check in case there is not sufficient material to meet the customers demand. The planning program creates purchase requisitions or schedule lines in MM if raw materials have to be procured externally to start production. Production execution triggers goods movement in MM (goods issue and goods receipt, see also chapter 2.5.4.2) to update the inventory. The production execution is also integrated to the subcontracting functions of MM for outsourcing the manufacturing operation to external vendors. In addition the financial documents are posted to SAP ERP FIN and the costs incurred during production are posted to the cost elements of SAP ERP FIN.
2.5.2.2 Integration with SAP Business Suite PP can be integrated with the following applications of SAP SCM: SAP APO for planning Extended warehouse management (EWM) for execution The SAP APO provides a high performance, memory resident data processor to perform planning and optimization. When the planning is performed by SAP APO production execution still happens in the SAP ERP system. The requirements can either be transferred from SAP ERP OPS to SAP APO or the global ATP check can trigger the planning directly in SAP APO. Planning in SAP APO takes the capacity situations into account. The planning results are then transferred to PP for execution. EWM is used when separate warehouse management systems manage the inventory of the materials. In this case goods movement functions are triggered from EWM for posting the material movement data in order to record the material movement from warehouse to the production plant. Likewise the goods movement functions are triggered from EWM when the finished product is moved back to the warehouse.
44
Internal
© Copyright SAP AG 2010
SAP ERP
2.5 Production Planning
Sales Order Processing
Planned Independent Requirements Generation Logic
Demand Forecasting Logic
ATP Logic
Sales & Distribution (SD) (Planned Requirements)
SAP SCM APO Demand Planning (DP) (Planned Independent Requirements) R
Transfer of Requirements
R
Production Planning Sales and Operations Planner (SOP)
Transfer of Requirements
Production Execution
Sales & Operations Data JIT Processing
Kanban Control Processing
Demand Management Logic
Lean Manufacturing Planned Independent Requirements
Long Term Planning Logic
Batch Management Logic
Master Production Scheduling Processor
R
R
Repetitive Manufacturing Logic To long term planning logic, SOP
Production Order Processing Capacity Requirement Planning (CRP)
Planned Orders
Materials Requirement Planning (MRP)
Process Order Processing
Detailed Scheduling Logic
Execution steps Logic (Production Orders)
PI Sheet Processing (Process Orders)
Production / Process Order Confirmation Processing
To HR system
Discrete + Process Manufacturing
Production Orders
Process Orders
Manufacturing (MAN) Initiate Planning
R R
Planning Results
FI / CO
Master Data
SAP APO Material
Planning Logic (PP/DS)
Routing
Work Center
BOM
Goods Issue Processing
Goods Issues
Goods Receipt Processing
Goods Receipts
Purchase Order Processing
Purchase Orders
Purchase Requisition Processing
Purchase Requisition
R
Invoice Verification
Update
Inventory
MM
Figure 2-18 Architecture of Production Planning and Production Execution
2.5.3 Planning Functions Production planning includes multiple planning functions (see figure 2-18): © Copyright SAP AG 2010
Internal
45
2 SAP ERP Operations
SAP ERP
Sales and operations planning (SOP) Long term planning (LTP) Material requirement planning (MRP) The planning functions are performed top-down starting from forecasting the sales demand down to the planning of production orders with MRP.
2.5.3.1 Sales and Operations Planning Sales and operations planning (SOP) provide functionality to create a sales plan and a corresponding high-level production plan. Within the sales plan SOP creates a sales forecast for a given planning horizon based on historical sales data such as market requirement statistics, sold products and trends. SOP proposes the quantity of products or product groups the company will sell in a certain future timeframe. When calculating this, SOP does not consider actual stocks and available production capacities. In a next step SOP prepares a production plan, which checks if the sales plan is feasible by checking production capacities. As user interface SOP provides a spreadsheet as planning table. SOP supports the import of sales plan data from MS Excel. A sales plan looks for example like this: an automobile manufacturer plans to sell 100 cars and 100 trucks in 6 months. In this case cars and trucks are different product groups. In the next step the product groups are planned: 60% of cars belong to variant A and 40% as variant B 50% of trucks are belong to variant C and remaining 50% variant D. So finally the sales plan provides requirements, which say in 6 months 50 trucks of variant C need to be available, and so on. SOP transfers these requirements to the demand management logic for further planning. The SOP is performed at the product group level. For further planning they are transformed to planned independent requirements (PIR) by the demand management functions.
2.5.3.2 Demand Management Demand management receives requirements from SOP processing via database integration. Demand management is used to create and maintain the planned independent requirements (PIR). The user interface for creating the PIRs is a spreadsheet where each row corresponds to the requirement quantities of the material in the day, month or week format for a plant. This is referred to as the planning period. Demand management translates the rough cut plan to the actual plan that can be used by MRP. The PIRs are stored as database records which form the basis for further planning. In doing so certain characteristics of the material like planning strategy, requirement type, consumption and plant responsible for producing the material are attached to the material information in the PIR. The planning strategy could be different for every material and is maintained in the material master.
46
Internal
© Copyright SAP AG 2010
SAP ERP
2.5 Production Planning
Demand management takes requirements from sales orders in the PIR into account. Based on the requirements type, the quantity of planned independent requirements is reduced by the quantity from incoming sales orders. This is called consumption and is reflected in the stock monitor. However the physical reduction of the quantity from the database happens during the goods movement. Based on the PIR all further planning steps, such as long term planning, master production scheduling, or material requirement planning (MRP) happen (see figure 2-18).
2.5.3.3 Long Term Planning Long term planning (LTP) checks the feasibility of the sales plan created by SOP. It checks, if the available production capacities are sufficient to make the sales plan happen. The LTP forecasts also stock and capacity situation which helps users to decide early in the planning phase whether additional work centers and machines are required. The result of LTP is simulated planned orders. Technically LTP is a simulated MRP run and the same MRP logic is reused. LTP takes into account additional parameters which are defined in a so called planning scenario. This allows the planner for example to forecast the raw materials demand and plan the procurement process well in advance, or to see how the planning is affected when there is a change in BOM by creating separate planning scenarios. Finally the best planning scenario one can be transferred to MRP, which transforms them into a planned order and initiates production or procurement. The results of LTP are also used by the purchasing to identify the sources of supply for the material well in advance and negotiate long term agreements with the vendors. LTP does not create purchase requisitions. The LTP has an interface to the capacity requirement planning (CRP) for calculating the capacity requirements and plan the budgets required for producing the product.
2.5.3.4 Master Production Scheduling Master production scheduling (MPS) is used to plan the production of material that greatly influences the company‟s profits or take up critical resources with extra care. The material master data differentiates whether a material is relevant for MPS or MRP. MPS creates the master production schedule for a material and its components (first level of BOM). The master production schedule data can be changed manually to trigger different simulation runs. Finally MPS creates planned orders according to the master production schedule. In addition MPS creates single level dependent requirements based on the BOM of the planned order. For example for the production of a car the wheels, the engine, and the steering wheel are dependent requirements. MPS considers only the components listed on the first level of BOM, components listed below are planned only by MRP. MPS reuses the MRP logic except that only the first level BOM is exploded. Generally the MPS is done at the finished product level or for important sub assemblies.
© Copyright SAP AG 2010
Internal
47
2 SAP ERP Operations
SAP ERP
2.5.3.5 Materials Requirement Planning The final step in planning is material requirement planning (MRP). MRP is a planning tool for the raw material and assembly components which are required to produce a certain product in a given plant. MRP goes top-down through the BOM of the material to be produced. Initially it plans the net requirement of the material to be produced. Then the planning continues on detailed level, which means all components listed in BOM are considered. For each component listed in BOM MRP creates a dependent requirement. MRP checks for each requirement, if there is enough supply of each component for the production. If not, MRP makes sure that the right quantity is available at the right time in the inventory. To do so, it creates either a planned order to produce the missing components or a purchase requisition in order to procure them. If the first level of BOM is already planned by MPS, then MRP takes only care about the rest. In contrast to MPS, MRP does not consider the production capacity of the plant. MRP receives planned independent requirements from demand management or MPS. During MRP material master data is evaluated. The MRP views of material master for example define the procurement type (in-house production or external procurement) and the goods receipt processing time. In addition the routing and BOM master data is also used by the MRP logic. The MRP logic has to make sure that the same material of BOM component is not planned again. This is ensured through a so called planning file which is an input queue for the MRP logic. The planning file is a record that consists of the materials that are relevant for planning. The MRP run happens only for the materials in the planning file. Once the material is planned the entries are deleted from the planning file. The planning file is updated from many places by those applications that change the material planning status, for example when A new material is created with the MRP view, The MRP logic itself deletes the planning file entries once the planning is done and creates a planning file entry for the dependent requirements during BOM explosion in order to plan for all the components A sales order requirement quantity changes, then the planning is updated for the new quantities. In general any application that could change the planning status of the material updates the planning file so that the MRP run is up to date. MRP logic calculates the net requirement of material in order to satisfy current or future stock shortages and generates either a planned order (in case of in-house production) or purchase requisition (in case of external procurement). The following explains the steps in the MRP logic in more detail (see figure 2-19)
48
Internal
© Copyright SAP AG 2010
SAP ERP
2.5 Production Planning
Materials Requirement Planning (MRP) Logic
Read the planning file
Planning file entries Exists ?
N Y Pre processing logic
Reads the database for Warehouse stock Requirements (-) Receipts (+)
Perform Net requirements calculation, check if requirements are negative ?
N
Assembly scrap taken into account Y
Uses Material master data
Quota arrangment and Source of supply logic
Lot sizing procedures Fixed lot size Periodic lot size Min/max lot size Lot for lot size ..etc
Basic date deteremination
Uses BOM master data
Uses Routing master data
Relevant for Inhouse production and subcontracting BOM explosion Component scrap taken into account
Exception handling
Lot sizing
Detailed scheduling Procurement proposal
Prepare for database updates
Process results of planning and perform database updates
Create MRP list and update planning file entries
Planning file entry exists ? Y
N
Relevant for Inhouse production
Delete unneccessary procurment proposals if the requirements are NOT negative Result of MRP run is either Planned order Purchase request Schedule lines Reservation
Planning file record added with components of dependent requirements in BOM Planning file record deleted - after MRP Run
Figure 2-19 Material Requirement Planning © Copyright SAP AG 2010
Internal
49
2 SAP ERP Operations
SAP ERP
The first operation of the MRP is to check if entries for materials exist in the planning file. MRP selects the first entry in the planning file and prepares internally a table to calculate the current stock situation in the warehouse for the material. To do so, it evaluates all requirements and receipts of the given component. Receipts are documented for example in production orders, purchase requisitions, purchase orders, and goods receipts. Requirements are documented by sales orders and PIR. The system calculates net requirements for every material. For this calculation, the system checks whether the requirements are covered by the warehouse stock and dispatched receipts from purchasing or production. If the requirements cannot be covered, the system creates a procurement proposal. The system calculates procurement quantities. When doing this, the system takes into account the selected lot-sizing procedure and, if necessary, scrap and rounding values Lot sizing determines how the requirement quantities must be handled. For example in case of the fixed lot sizing if the lot quantity is 1000 for material A, and if the MRP net requirements calculates a demand of 500 for material A, then the procurement proposal is created for 1000 units. The remaining 500 units will be consumed later when subsequent requirements are generated for material A. MRP performs lot sizing based on the lot sizing procedures which are maintained in the material master (for examples see figure 2-19) The MRP carries out the scheduling in order to calculate the start and finish dates for the procurement proposals taking into account the procurement lead time, production time, and the goods receipt processing time, which is maintained in the material master. The MRP then determines the type of procurement proposal. Dependent upon the defined setting, planned orders, purchase requisitions or delivery schedules are created by the system for a material. If necessary entries for quota arrangements are maintained, then the system also determines the source of supply and allocates this to the procurement proposal. To do so, MRP calls the MM interfaces. For every procurement proposal of an assembly, MRP explodes the BOM and determines the dependent requirements. Then MRP Performs detailed scheduling which reads the routing data where the exact time of the operations and the average time to complete the production of a material are maintained. With this data a detailed scheduling happens and the basic start and end dates are adjusted (increased or decreased) accordingly. Finally MRP prepares the tables to be updated and creates a planned order, purchase requisition, schedule lines or reservations. Then the planning file is created for the planned dependent materials during BOM explosion and the material that is planned is deleted from the planning file.
50
Internal
© Copyright SAP AG 2010
SAP ERP
2.5 Production Planning
MRP reads the planning file and checks if there are any further materials or components that need to be planned. The planning run is over when there are no more entries in the planning file. During the planning run, the system recognizes critical situations that have to be assessed manually in the planning result. The system creates exception messages that are collected and logged at every phase of the MRP run. The MRP logic doesn‟t react to any of the exception messages or in other words they are not handled. It is just to bring to notice to the MRP controller to decide whether or not to react to the exceptions.
2.5.4 Production Execution Production is executed in different ways in different industries. PP supports: Discrete manufacturing Process manufacturing Repetitive manufacturing (REM) Discrete manufacturing (aka shop floor production) describes the production of single, distinguishable products. Manufacturing manages this kind of production using production orders (see chapter 2.5.4.1). Process manufacturing is characterized by batch-oriented production of products in the process industry (for example chemicals, pharmaceuticals, food). For managing this kind of production manufacturing uses a specific type of production order called process order and batch management. Repetitive manufacturing is characterized by the interval-based and quantity-based creation and processing of production plans. With repetitive manufacturing, a certain quantity of a stable product is produced over a certain period of time. The product moves through the machines and work centers in a continuous flow. Repetitive manufacturing is suitable for a variety of industries, such as electronics, semiconductors, and packaging. Discrete, process, and repetitive manufacturing also can be used for pure make-to-stock production. Production in this case has no direct connection to a sales order. The requirements are created by demand management and the sales orders are supplied from stocks. The material master data settings determine if a material is to be produced by means of repetitive manufacturing. The BOM for the material to be produced specifies how many units of which components are required for production. In repetitive manufacturing, not every goods issue is recorded at the same time as the physical withdrawal of the material from stock. The component usage is automatically posted only when the finished product is received. This is called back flushing. To do this, a storage location is specified in every BOM item, and the back flush is carried out for this location.
© Copyright SAP AG 2010
Internal
51
2 SAP ERP Operations
SAP ERP
2.5.4.1 Production Order Processing Once the planning phase is over, the actual production execution starts. To do so, production order processing creates production orders based on the planned orders from MRP. A production order can be created directly from a sales order or manually, too (make-to-order scenario). In all cases production order processing retrieves the information necessary for production from the planned order or sales order as well as from the following master data: Material master which for example defines the production process BOM which lists all the components required to produce the final product Routing which embraces the operations involved in producing the final product Work center which provides information about the tools and machines required for production In production execution the production order is the central business document used for controlling and monitoring the production process in the shop floor. It includes the following attributes: Production start date Production end date Bill of material (BOM) Operations to be performed to produce the final product Capacity required for producing the material Status of the production (such as work in progress, completed, and so on) Information about costs involved in the production for later settlement Production resources and tools (PRT) for producing the material The production order passes through a number of different stages. Beginning with the order creation, which is usually performed through the conversion of a planned order, it involves a number of functions like availability check on the raw materials, capacity planning, order releasing, order printing, order accounting, followed by production order confirmation and order settlement. When a production order is created, production order processing performs the following activities: Select appropriate routing and include operations and sequences into the production order. Explode BOM of the material to be produced and include components into the production order. Create a reservation for each BOM component kept in stock Calculate planned order costs Create capacity requirements for the work centers Create purchase requisitions for all BOM components, which are not on stock Create purchase requisitions for production operations which are performed by a third-party
52
Internal
© Copyright SAP AG 2010
SAP ERP
2.5 Production Planning
The production order processing is integrated with the inventory management of MM and the warehouse management of LE for material staging (see figure 2-20). If the company uses warehouse management the production order triggers the creation of transfer requests. Warehouse management transfers these requests into transfer orders which ensure that the raw material and components required for production are supplied from the warehouse to the shop floor in time.
Master Data Material
Routing
Work Center
BOM
Batch Management Logic
Sales Orders
Classification Logic
Availability Check Manual Entry
Serial Number Processing
Document Management
Scheduling Logic
R
Trigger Point Logic
Planned Orders
Production Order Release R
Source
External Operation R
Purchase Requestion Processing
Purchase Order Processing
Purchase Orders
Production Order Processing
Purchase Requesition
Functions
Purchasing Capacity Planning
Reservation
R
R
Transfer Requests
Material Staging Transfer Request Processing
Transfer Order Processing
Transfer Orders
Inventory Management
Warehouse Management Costing R R
EWM Production Orders
Production Order
Figure 2-20 Architecture of Production Execution
© Copyright SAP AG 2010
Internal
53
2 SAP ERP Operations
SAP ERP
Production order processing needs to reserve in the inventory the raw material and components which are needed to execute the production order. MRP creates this reservation for the planned dependent requirements derived from BOM. When production order processing converts the planned order into a production order it creates reservations for the dependent requirements. The components and raw material, which have to be taken from stock, are reserved in the inventory for the production order. This is done by the production order processing logic. Finally the production orders are subject to release which is the starting point for production workers. The order can also be printed and made available to the shop floor. The reserved material can be withdrawn only after the order is released.
2.5.4.2 Production Order Confirmation Production order confirmation processing records the actual status of the production based on the production order. The status information of the production confirmation includes the following: Produced quantity as yield and scrap Activities leading to actual costs Work center that was involved in the production Person responsible for the execution of the operation The production order confirmation is a separate document which references one production order or an operation of a production order. The master data that is required for its processing is the material master data and the work center data to record the work center responsible for production. Production order confirmation processing triggers goods movement. The finished product is updated in the inventory via the goods receipts processing and a goods receipt document is posted. The quantities of the components that were used for producing the product are updated in the inventory via goods issue processing. This is called back flushing of materials. The FI/CO documents are posted during the confirmation. The confirmation updates the following Production order with the status, quantities and the activities that were performed to complete the production Batch characteristics of material if the materials are handled in batches Capacity requirements via capacity reduction logic Production resources and tools (PRTs) equipment data Costing data from activities leading to cost for cost settlement HR data like person responsible and time taken for operation is passed to SAP HCM.
54
Internal
© Copyright SAP AG 2010
SAP ERP
2.5 Production Planning
Master Data Work Center
R
Batch Management Logic
Post GI (backflushing)
Classification Logic
Goods Issue Processing
Goods Issues
Production Order Processing
Production Orders
Update
Goods Receipt Processing
Goods Receipts
Material
R
Post GR (finished product)
Update
R
Production Order Confirmation Processing
Source
Update
Inventory
R
Inventory Management
FI/CO Post
R
PRT Update Logic
R
HR
Trigger Point Processing
R
Update
R
Capacity Reduction Logic
Actual Cost Determination Processor
R
EWM
Trigger actual costs calculation R
Production Orders Confirmation Data
Production Order Confirmation
Figure 2-21 Architecture of Production Order Confirmation Processing Unexpected events which disturb the production for example machine breakdown calls the trigger points which initiate follow up actions such as new operations.
© Copyright SAP AG 2010
Internal
55
2 SAP ERP Operations
SAP ERP
2.6 Materials Management Enterprises procure materials and services to run their business. Within SAP ERP OPS materials management (MM) focuses on the procurement needs of an organization. MM supports the procurement of materials as well as services, manages the inventory, and performs invoice verification to check and issue payment to the vendors. The business processes in MM affect the financial accounting of SAP ERP FIN, which is therefore tightly integrated with MM.
Purchase Order Processing
Purchase Request Processing
Confirmation/Invoice Processing
Purchase Request/ Contracts/RFx Data
Contracts Processing
RFx Processing
Supplier Relationship Management (SRM)
R R
R
FI Data
SUS
Funds Management
R
Financial Accounting
FI / CO
Contracts Processing
Production Planning
Scheduling Agreements
Contracts
R
Scheduling Agreements Processing
R R
Outline Agreements
Purchase Order Processing
Plant Maintenance
R
R
Inbound Shipping Process
Project System
Source
Service Entry Processing
Goods Receipt Processing
Goods Receipts
Purchase Requisition Processing
Purchase Orders
Purchase Requisition
R
Service Entry Sheets
R
Sales and Distribution
R
Invoice Verification
Update Inventory
Materials Management (MM) R
R
R
R
R
SAP APO
SAP EWM Purchase Order Processing
Confirmation Processing
Invoice Processing
Supplier Network Collaboration (SNC)
Figure 2-22 Architecture of Materials Management
56
Internal
© Copyright SAP AG 2010
SAP ERP
2.6 Materials Management
External procurement supports procuring material or services from an external vendor or from a supplier who delivers the goods or services. The purchasing organization holds the responsibility of managing the procurement process. Within MM the following business documents are a part of the procurement process (see figure 2-22): Purchase requisition (PR) Request for quotation (RFQ) Contracts Scheduling agreement Purchase order (PO) Goods receipt document Service entry sheet (SES) Invoice The purchase requisition is a document that informs the purchasing department in an enterprise about the demand to procure certain material or services. The purchasing department is then responsible for identifying an appropriate vendor. For a single purchasing transaction a request for quotation is sent to the vendor to negotiate the price. For regular purchases from the same vendor contracts and scheduling agreements are stored in MM which describes the terms and conditions with the enterprise have negotiated with the vendor. To actually procure material or service, purchase orders are created referencing the purchase requisition (see figure 2-22) or the corresponding outline agreements (contracts and scheduling agreements. When the material or services are delivered the goods receipt or service entry processing takes place. Afterwards invoice verification happens based on the invoice sent by the vendor. If the invoice verification is successful finally the payment is made to the vendor which is triggered by SAP ERP FIN. Procurement of material and of services is based on the same architecture. The procurement of services is implemented as an extension to the original material procurement functionality.
2.6.1 Procurement of Materials Materials owned by the company are managed in the inventory. All goods movements are monitored and updated in the inventory. When additional material is required, a purchase order is created first (see figure 2-22). The purchase order includes information about the vendor, the amount and type of material requested, and the requested delivery date. When the material is delivered from the vendor goods receipt processing starts. Within that process a material document is created which contains all details about the material, its movement type, posting date. The material document references the initial purchase
© Copyright SAP AG 2010
Internal
57
2 SAP ERP Operations
SAP ERP
order. In this way it is tracked, if the purchase order is fulfilled. During goods receipt processing the quantity and the value of the inventory is updated, too. The goods issue processing initiates the financial postings (financial document) to update the value of the material in the balance sheet general ledger (G/L) accounts If the received material is damaged or of the wrong type the goods receipt process can be reversed. In this case the material is sent back to the vendor, the inventory gets updated, and the material document and the financial document are also reversed. Once the delivery is completed and the invoice from the vendor is received invoice verification takes place. During this process the invoice is compared with the purchase order and the goods receipt document. If the check is successful payment is triggered via financial accounting.
2.6.2 Procurement of Services The procurement of services, for example construction of a floor, fitting of electrical equipments, and cleaning, differs slightly from the procurement of material because for services no inventory has to be managed. First the purchase order is created and sent to the service provider. Now instead of a goods receipt an entry of services is maintained after the services are provided by the vendor (see figure 2-22). To do so, a service entry sheet is created based on the purchase order. The service entry sheet is used to track the actual services performed by the vendor. Follow-up processes such as invoice verification and financial accounting are only triggered after the complete service entry sheet is accepted. Typically this happen, when all services of the service entry sheet are provided. Once a service entry is accepted, then internally the good receipt processing functionality from material procurement is reused. This means a material document is generated, and financial data is transferred to ERP financial accounting to trigger payment. If the services are not provided properly, the service entry sheet can be revoked, which also reverses the material document and the financial postings. After service entry the invoice is matched with the material document (invoice verification) and then a payment process is initiated via financial accounting.
2.6.3 Integration 2.6.3.1 Integration within SAP ERP MM is closely integrated with SD, PP, Project Systems and Plant Maintenance using database integration (see figure 2-22). All these applications create purchase requisitions together with their business documents (store them in the same logical unit of work) So when a sales order is created and the material ordered is not produced by the company itself, sales order processing creates a purchase requisition directly to procure the material. Similarly material requirement planning in PP creates purchase requisitions for material which need to be procured in order to produce the planned products. 58
Internal
© Copyright SAP AG 2010
SAP ERP
2.6 Materials Management
SAP ERP FIN is also integrated using database integration. SAP ERP FIN is triggered by goods receipts processing in MM. SAP ERP FIN is responsible for the payments to the vendor. Before the payments are made invoice verification happens. To do so, invoice verification compares the invoice sent from the vendor with the purchase order and the goods receipt. SAP ERP Fin only initiates payment to the vendor is the invoice verification is successful. Controlling and budgeting of procurement is managed by the funds management component of SAP ERP FIN. This component is linked to MM to track the cost and to make sure that the budget allocated for the procurement doesn‟t exceed the overall budget.
2.6.3.2 Integration with SAP Business Suite MM can be integrated with the following applications of SAP Business Suite (see figure 2-22): SAP SRM SAP SCM that includes SAP APO, extended warehouse management and supply network collaboration (SNC). SAP SRM provides features like indirect or the self service procurement, central contract management and supplier self services (SUS). Unlike the purchasing process in ERP that‟s triggered by the production planning, the self service procurement offers capability for the end user or the employee in a company to purchase materials or services. This is mainly used for low cost consumable materials for example paper, pencils or services which are maintained in the product catalog. The materials or services are requested via the shopping cart is converted to a purchase requisition or the purchase orders in the ERP system. SAP ERP MM acts as a backend system and provides the necessary business functions to support the procurement process. The central contract management of SAP SRM offers the possibility to maintain the contracts with vendor at the company level for large companies which offers the possibility of negotiating better terms and conditions with the vendor and maintaining them in the system. The contract is distributed to the multiple ERP system and local contracts are created in the ERP system. A purchase order is created for the contract and the contract statistics are updated back to the central contract which provides more visibility of the contract usage. This is achieved via integration with the MM in the backend. The SUS is a part of the SAP SRM which offers the platform to collaborate with vendors who doesn‟t have ERP system. The vendor can log on to the SAP SRM system provided by the buyer and can respond to the purchase orders, perform confirmations, send an invoice which calls the MM functions in the backend to update the purchase order, post goods receipts, posts invoices respectively. SUS supports procurement of external services. For more details on SAP SRM please refer the blue book on “SAP SRM 6.0”.
© Copyright SAP AG 2010
Internal
59
2 SAP ERP Operations
SAP ERP
MM functions are integrated to SAP SCM. The SCM APO availability check functions are triggered during the stock transport orders processing in MM. In addition the SCM APO systems can create purchase requisitions in MM when the planning is done in SCM APO system. If the EWM is used for managing the operations in a warehouse the necessary goods movement functions in the warehouse uses the Inventory management interfaces from MM. SNC provides platform for vendors to manage the inventory and handle special processes like third party processing, subcontracting process and consignment stocks. SNC handles materials and not services. This special process of materials handling is not covered within the scope of this blue book.
2.6.4 Framework-Based Implementation of Purchase Requisition When a business document is created by a user, the format, correctness, and consistency of the entered data needs to be validated by the business logic. Thereby the sequence of validation checks is influenced by the dependencies between different input values.
Vendor
Company Code
Purchasing Organization
Purchasing Group
Plant
Material
Depends on
Dependent obj
Dependent obj
Dependent obj
Business Objects dependencies
Figure 2-23 Business Entities and Dependencies Figure 2-23 shows an example of input value dependencies when creating a purchase requisition. Purchasing group for example depends on company code. Vendor and material is dependent on plant. Typically these validation rules are implemented as a long block of if-statements. This made it difficult to create and maintain the validation rules, for example to change the sequence or add a new rule.
60
Internal
© Copyright SAP AG 2010
SAP ERP
2.6 Materials Management
To address this problem and also to ease the maintenance of the business logic a framework-based approach is used for the implementation of purchase requisition and outline agreements (contracts, scheduling agreements) in MM. In this approach each validation rule is implemented in one local ABAP class. At runtime generic framework instantiates a rule interpreter which calls the registered rules in the right sequence. The encapsulation of the validation rules by providing a generic framework for the execution makes the implementation of a rule an easy task. In addition this approach also improves runtime performance, since only relevant validation rules are executed. For example if the validation of the input for vendor is not successful then all its dependent inputs like purchasing organization, purchasing group is not validated.
2.6.4.1 Framework The purchase requisition document is structured in header and items. Accounting information is part of the item. The business logic which takes care about header, item, and accounting is encapsulated by the corresponding manager (see figure 2-24). They handle the state and trigger the validation checks. The business logic is executed by a generic framework. The main components of the framework are as follows (see figure 2-24) Instance factory This is responsible for initializing the header manager which in turn initializes the item manger. The item manager is then responsible for initializing the account manager. The instance factory also initializes the rule factory and the rule interpreter which is used later for processing the rules. Rule factory A collection of all rules and their interdependencies belonging to a business document. The rule factory includes all the business logic rules (header, item and accounting rules). The set of rules is further characterized by a scope. The scope determines whether the rule has to be executed immediately or later. Context Contains a reference to the interpreter and the scope. This provides additional information on the state of a business document at runtime. State Header, item and accounting manager maintain their own state. The state holds the information like the old state, new state and before checks. For example when a price in the purchase requisition is changed the old state will have the information from the database and the new state will have the new price. Rule interpreter Given a context, a rule factory and a scope, the interpreter executes one rule after the other. The set of rules is derived from the scope and provided by the rule factory. The
© Copyright SAP AG 2010
Internal
61
2 SAP ERP Operations
SAP ERP
rule registry provides the information of the business rules to be executed. The rule interpreter is a generic component and can be reused by other applications. Purchase requisition processing is integrated with other components like purchase order processing. They are referred to as foreign applications. Purchase requisition processing provides an interface to the foreign applications.
R
Header R
Header Manager Header Context
Header Rule Rule Interpreter
Header State
R
R
Items R
Item Rule
Item Manager
Item Context
R
Accounting Rule
Rule Registry
Foreign Applications
Item State
Accounting Manager
Accounting Context
Accounting State Rule Factory
Business Logic – Purchase Requisition
Figure 2-24 Architecture of Purchase Requisition Framework
2.6.4.2 Rule Execution The validation rules are implemented as ABAP classes at design time. At runtime the rules are instantiated and executed by the rules interpreter (see figure 2-24). When doing this the rules interpreter considers the dependencies and preconditions of the validation rules. Say for example that rule 1 is the current validation rule that needs to be validated (see figure 2-25). Rule 1 has Rule 2 and Rule 3 as precondition. This means that Rule 1 will be executed only if Rule 2 and Rule 3 are valid. The result of Rule 1 is dependent on Rule 4
62
Internal
© Copyright SAP AG 2010
SAP ERP
2.6 Materials Management
and Rule 5. These rules are observers of Rule 1 and act based on the result of Rule 1 which means that Rule 4 and Rule 5 have to be executed, immediately or later. The execution of a validation rule provides one of the following results: Valid Invalid Unchecked After all rules are executed a decision is made whether the given context (or the business entity) is compatible with the rules. If all the rules are satisfied then the document is processed without errors. In case the rules are invalidated an error message is placed in the error log and requires further processing. A rule interpreter is responsible for the execution of the rules at run time.
Rule 2
Precondition of
Rule 3
Precondition of
Rule 1
Depends on
Depends on
Rule 4
Rule 5 Rule Based Business Logic
Figure 2-25 Preconditions and Dependencies of Validation Rules The complete validation process of a purchase requisition document works like this: 1. A special header rule loops over all items and invokes the process method of each item. 2. Two copies of the item state are created – one remains unchanged (item before checks) and one is updated by some rules at the end of method for delta management purposes. 3. The context information is built from the item state and transferred to the rule interpreter together with the rule factory and the scope.
© Copyright SAP AG 2010
Internal
63
2 SAP ERP Operations
SAP ERP
4. The interpreter determines which rules have to be carried out depending on the scope. Previously broken rules are always reprocessed. 5. The interpreter gets all the rules from the rule factory. 6. The interpreter starts with the first rule and executes one rule after the other until all rules are executed. The state of a rule is updated each time the rule is executed and every rule is implemented as a local class in ABAP. The rule interpreter is responsible for calling the local classes that executes the rules. The document can be saved only after all the rules are successfully executed.
2.6.5 Pattern-based User Interface With the enjoy initiative for SAP R/3 release 4.6 the user interface of MM was reimplemented based on a new architecture and a new screen layout. A pattern-based approach ensures that the different user interface screens for maintaining purchase requisition, purchase order, goods receipt and invoice receipt have a uniform and consistent look and feel. Also user input has been simplified by collecting the faulty input data instead of interrupting the user after each erroneous data entry with an error message.
2.6.5.1 User Interface Design The design defines a pattern for single screen maintenance of header, item and item details (see figure 2-26). The window embraces the complete screen and is implemented by one ABAP Dynpro screen that provides a placeholder for the document overview and the document view. The document overview on the left is a tree control that is used for listing the documents created earlier by the user. It has also options to select documents based on selection parameters like document date creation, and document type.
64
Internal
© Copyright SAP AG 2010
SAP ERP
2.6 Materials Management
Window Document Overview
Document View Plugin Purchase OrderType , Creation Date , Vendor) TopforLine (Document Header Item
Plug-ins
Provide Views
Provide Views
Item Details
Plug-in for Purchase Requisition
Plug-in for Purchase Order
Figure 2-26 Enjoy Transaction – User Interface Layout The document view displays the header, item, and item details of the business document. It is structured in different sub-screens where plug-ins provides the content. On top the top line plug -in is loaded which provides general information such as document type, creation date and vendor. In dependence of the actual business document to be displayed, different plug ins are used to present the corresponding header, item and item detail data (see figure 2-26).
2.6.5.2 Model View Controller The pattern-based user interface is implemented using the Model-View-Controller (MVC) design pattern. By using the MVC pattern the user interface (UI) is decoupled from the business logic. This was not the case in the older transactions. Model, view, and controller play the following roles: Model Models define the application data to be presented on the user interface. In MM the models represent the business documents, for example purchase requisition or purchase order. The model provides services needed by the controller. The model is responsible for triggering the business logic and provides the information back to the view for display.
© Copyright SAP AG 2010
Internal
65
2 SAP ERP Operations
SAP ERP
View View provides the visible screen output. Each plug-in in figure 2-26 corresponds to a view. The views are implemented as object oriented wrappers around ABAP Dynpro screens. Examples are header data screens like partners, address. Controller Controllers (in MM also called framework) handle the communication between model and views. The controller registers the views that have been changed by the user. Once the data entry is completed the framework informs all the registered views to send the entered data to the model for further processing.
View + Framework (Controller) PAI FINISHED Main Window Object
4 Handle PAI
1
Transport Changed Views
Handle PBO
2
3
Notify Data Changed Views
Set / Get Data from Model R
6
Framework
Initiate Data Transport to Model Get Data from Model
7
5 List of Changed Views
Dynpro Logic
Message Handler
R
Model
R
8
Business Logic Purchase Requisition
Business Logic Purchase Order
Figure 2-27 Enjoy Transaction - Architecture Overview Model, view, and controller (framework) is implemented as ABAP classes. The communication between them is based on class events. For the PBO, the logic is quite simple. The Dynpro logic raises an event handle PBO and the views respond to the event. The views then check if the model is changed by using the get data method in model. If there are changes then they are displayed on the screen with changes else the screens are then displayed in the window. To process input data models, controllers, and views work together in the following way:
66
Internal
© Copyright SAP AG 2010
SAP ERP
2.6 Materials Management
1. When the user has entered data on the screen the ABAP Dynpro logic raises an event handle PAI. 2. The views that correspond to the screen know that data is changed and informs the framework to register the changed view. The event name is “notify data changed”. 3. The framework collects all the views that have been changed by the user and stores it temporarily in the buffer. 4. Once all the views have registered the changes with the framework the Dynpro logic triggers the event PAI Finished to the window (that contains all the views). 5. The window informs the framework to initiate the transport of all the changed views to the model. 6. The framework then initiates a call to the model through the view (changed views in the list) and all the views that were collected are transported to the model. 7. The view calls the get data first to check if there are any changes in the model and then sets the data entered by the user through the set data method provided by the model. 8. The model calls the business logic to perform operation on the data. The data validation happens in the business logic. The message handler provides all necessary functions for error handling and incompletion process for purchase requisition and purchase order.
2.6.5.3 Business Logic Extensibility Industry and business requirements of a company cannot always fulfilled by the standard functionality provided by SAP ERP OPS. Therefore the business logic can be extended for: Processing custom objects Processing additional data on standard objects Performing additional check and derivations Changing data in standard fields Changing the field selection To ensure that the extensions are compatible with the existing business logic the BAdI technology is used. Predefined BAdIs are called when the existing business logic is executed, being it triggered by a dialog transaction or an external BAPI call.
© Copyright SAP AG 2010
Internal
67
2 SAP ERP Operations
SAP ERP
Standard Header Logic
Extensions Header Processor
Extensions
Standard Item Logic
Item Processor
Standard Schedule Logic
Standard Accounting Logic
Extensions
Extensions
Schedule Processor (Not for PR)
Accounting Processor Business Logic and Extensions
Figure 2-28 Business Logic Extensions Figure 2-28 shows the different places in document processing logic where extensions are possible. The extensions are available in the header processor, item, schedule and accounting and can be implemented based on the custom requirement. The extensions are plugged in the main business logic.
Extending Purchase Order Processing As an example we explain how the business logic of purchase order processing can be extended. Purchase order processing is structured into multiple logic parts (see figure 2-29). When the purchase order is opened the open logic is called to perform the read operation. The initialization is logic is responsible for initializing the purchase order for the usage in the transaction. The field selection logic is responsible for switching a field on or off, making field available for input.
68
Internal
© Copyright SAP AG 2010
SAP ERP
2.6 Materials Management
Core
Extensions
Open Open Extension Active Open Logic Extension
Initialize Initialize Extension Active Initialize Logic Extension
Field Selection
Process Header
Process Item
Process Schedules
Process Accounting Process Logic Check Post Close
Figure 2-29 Processing Purchase Order Extensions The process logic handles all the operations related to processing of purchase order document that includes header, item, accounting and schedules. The check logic is triggered once when all the user input is made and the document is ready to save. The post logic calls the update functions to post the transaction data followed by the close logic. Within the flow of standard business logic extensions can be added to each logic part.
© Copyright SAP AG 2010
Internal
69
2 SAP ERP Operations
SAP ERP
2.7 Logistics Execution Logistics execution (LE) controls and organizes the movement of material within the enterprise (warehouse management), but also transportation between enterprises. Movement of material includes the outbound processing of sending materials to customers, the corresponding inbound processing of receiving materials from vendors, and organizing and monitoring the transportation of material.
2.7.1 Architecture Overview From architecture perspective LE is divided into the following areas (see figure 2-30):
Purchase Order Processing
Production Order Processing
Sales Order Processing
Order Processing R
R
R
Batch Management
Advance Shipping Notification Processing
Transfer Order Processing
Inbound Delivery Processing
Transfer Orders
R
Billing Outbound Delivery Processing
Proof of Delivery Processing
R
Picking Logic Packing Logic Warehouse Management
Inbound Shipment Processing
Handling Unit Management
Inbound Shipment Document
Inbound Shipping (SHP)
Transportation Management (TRA)
Freight Cost processing
Shipment Cost Document
Outbound Delivery Document Outbound Shipping (SHP)
Outbound Shipment Document
Inbound Delivery Document
Extended Warehouse Management (EWM)
Outbound Shipment Processing
Logistics Execution (LE) R
R
Invoice Receipt Processing
Transportation Management System (TMS)
R
Inventory Management
Goods Issue Processing
Inventory
Goods Receipt Processing
Update Inventory
Update Inventory
Figure 2-30 Architecture of Logistics Execution Inbound delivery processing which covers receiving goods from the vendor and storing them in the company's warehouse. Warehouse management which supports stock transfer, picking and packing
70
Internal
© Copyright SAP AG 2010
SAP ERP
2.7 Logistics Execution
Transportation management which supports inbound and outbound shipment processes Outbound delivery processing which includes picking the goods and transporting them to the customer Typically logistic execution is initiated by purchase order processing in MM or sales order processing in SD. The inventory itself is part of MM. Logistics execution processes are closely integrated with inventory management, which maintains the actual inventory
2.7.2 Integration 2.7.2.1 Integration with SAP ERP LE is integrated with SD and MM using database integration. SD triggers LE to perform the order fulfillment process for a sales order, in especially the delivery processing. In this case an outbound delivery document is created referencing the sales order. When material is received by a company LE creates an inbound delivery with reference to the purchase order and triggers goods receipt processing in MM.
2.7.2.2 Integration with SAP Business Suite LE can be integrated with SAP SCM to extend its functional scope. Extended warehouse management (EWM) can be connected to the warehouse management of LE to provide additional warehouse management functions in the areas of advanced shipment notification (ASN), work assignment, and picking bin determination. Deliveries are created in LE and transferred to Extended Warehouse Management using queued RFC. The transportation management functionality of LE can be replaced by SAP Transportation Management System (SAP TMS) which supports transportation request management, transportation dispatching and execution. In this case LE forwards all transportation requests to SAP TMS using asynchronous message transfer.
2.7.3 Inbound Delivery Processing Inbound delivery processing only starts after the enterprise has purchased material (raw material, goods) which the vendor has confirmed by sending a purchase order confirmation. If the procured material needs to be transported to the enterprise inbound shipment processing is performed. It is part of transportation management (see chapter 2.7.5) To be prepared to receive the ordered material inbound delivery processing is initiated in one of the following ways: Manually an inbound delivery document is created with reference to the purchase order The vendor sends an advance shipping notification to the enterprise via iDoc, which triggers the creation of an inbound delivery document
© Copyright SAP AG 2010
Internal
71
2 SAP ERP Operations
SAP ERP
The vendor may send an updated version of the advance shipping notification which updates the inbound delivery document if this has not been processed yet. The inbound delivery document includes the following data: Header: o ID o Status o ID of corresponding purchase order o Vendor o Date of delivery Item: o Quantity and type of material to be received The inbound delivery document is used to track the arrival, unload, unpack, and put into warehouse of the material. When the material is received at the plant or warehouse inbound delivery processing sends a proof of delivery as iDoc to the provider. In addition the inventory is updated by goods receipt processing.
2.7.4 Outbound Delivery Processing The outbound delivery processing within LE is mainly responsible for sales order fulfillment. If the vendor organizes the transportation of the material to the customer outbound delivery processing initiates outbound shipment processing which is part of transportation management (see chapter 2.7.5). Outbound delivery processing is integrated with warehouse management if the materials are stored in the warehouse (see chapter 2.7.6). Sales order processing initiates outbound delivery processing as soon as the requested material is available in the inventory (see figure 2-30). Then outbound delivery processing creates an outbound delivery documents with reference to the sales order. It includes the following information: Header: o ID o Status o ID of corresponding sales order o Customer o Date of delivery o Ship-to party o Shipping point o Route Item: o Quantity and type of material to be delivered o Delivering plant or warehouse
72
Internal
© Copyright SAP AG 2010
SAP ERP
2.7 Logistics Execution
o Loading point Outbound delivery processing performs the following tasks: Shipping point determination Delivery scheduling Route determination Receive proof of delivery If the material is not picked up directly by the customer, but transported to the customer‟s ship-to location outbound shipment processing is performed. Once the goods are delivered the goods issue processing updates the inventory by reducing the quantity that was delivered. Subsequent financial documents are posted so that billing can be performed.
2.7.4.1 Shipping Point Determination The shipping point is the organizational unit of a company which is responsible for a dedicated way of shipment, for example the mail depot or a plant rail station. Within LE the shipping point is responsible for delivery creation, update and monitoring as well as goods issue processing. One delivery is processed by one shipping point only.
Shipping Conditions Delivery Scheduling Logic
Sold to Party / Order
Shipping Determination Logic
Loading Group
Shipping Point
Material Master Route Determination Logic
Plant Sales Order
Shipping Point Determination
Figure 2-31 Shipping Point Determination Outbound delivery processing determines the shipping point for ordered material based on the following three input values (see figure 2-31): Shipping conditions, for example that the material should be delivered as soon as possible. Plant which delivers the material (provided within the sales order document)
© Copyright SAP AG 2010
Internal
73
2 SAP ERP Operations
SAP ERP
Loading group which defines the way of loading, for example that the material must always be loaded with a crane or a forklift For each possible combination of values the corresponding shipping point is defined in customizing tables. So outbound delivery processing looks up the corresponding shipping point. The shipping point is a prerequisite for delivery scheduling and route determination.
2.7.4.2 Delivery Scheduling Delivery scheduling defines a timeline for all activities that have to be carried out before the material can be delivered to the customer, for example picking, packing, and loading the material. To do so, delivery scheduling determines the material availability deadline, at which the material must be picked from the bin and packed as well as the loading deadline, at which the material must be available for loading.
2.7.4.3 Route Determination A route describes a course of travel between the shipping point and an end point. A transportation planner maintains routes which are stored in customizing tables. At run time the route determination logic checks if there is a route which connects the shipping point to the ship-to location of the sales order. The following attributes determine the route selection (see figure 2-32): Departure country and zone from where the materials are to be shipped (this information comes from shipping point) Shipping conditions which define how the materials are to be delivered (this information comes from the sales order) Transportation group (this information comes from material master) Destination country and transportation zone indicates where the materials are to be delivered (this information comes from customer master) Weight group (relevant for delivery) indicates how much of materials can be delivered. The weight group is determined on the basis of the total weight of the delivery. Based on the above input values the route is determined during creation of a delivery. Route determination is prerequisite for transportation scheduling, which defines the timelines for preparing and carrying out the transportation. Transportation scheduling determines the following two deadlines: The transportation scheduling deadline is the date on which transportation of the goods must be organized. The goods issue deadline is the date on which the goods must leave the company in order to arrive at the customer location without any delays. To do so, it calculates for example the transit time of a foreign forwarding agent and the transportation lead time for arranging a truck.
74
Internal
© Copyright SAP AG 2010
SAP ERP
2.7 Logistics Execution
Departure Country + Departure Zone Shipping Point
Shipping Conditions Sold to Party / Order
Transportation Group Material Master
Route Determination Logic
Route
Transport Scheduling Logic
Destination Country + Transportation Zone Customer Master
Weight Group Delivery
Route Determination
Figure 2-32 Route Determination
2.7.4.4 Proof of Delivery Processing Customers can send a proof of delivery (POD) document to LE to confirm that they received the ordered material. The proof of delivery is required in business processes in which an invoice is issued only after the customer has confirmed the receipt of the delivery. The proof of delivery includes the following attributes: POD date POD time Actual quantity that arrived Reason for possible differences in quantities if any. This is especially important for deliveries in which the delivery quantity varies because of the nature of the goods or for which the exact delivery quantity is unknown from the start. The proof of delivery document reflects the actual delivery status thereby facilitating an accurate billing process and eliminating unnecessary credit memos. The ship-to party transfers the proof of delivery to the SAP ERP OPS via iDoc. The message is received by proof of delivery processing. Now billing is initiated based on the POD quantity.
© Copyright SAP AG 2010
Internal
75
2 SAP ERP Operations
SAP ERP
If the customer uses SAP ERP, too, inbound delivery processing sends the proof of delivery via EDI (Electronic Data Interchange) technology. Inbound delivery processing calls output determination which determines the system address to which the proof of delivery has to be sent. Then inbound delivery processing creates an iDoc which is transmitted to the vendor‟s SAP ERP. For more details on output determination, see section 2.4.3.3
2.7.5 Transportation Management Transportation management embraces inbound shipment processing as well as outbound shipment processing. It is triggered by the respective delivery processing. Transportation management includes the following functions: Transportation planning and shipment completion Service agent selection Shipment costs calculation Shipment costs settlement Billing of customer freight Follow-up and supervision of shipments Management of shipment costs Inbound as well as outbound shipment processing creates a shipment document which first of all defines which deliveries is part of one shipment. In addition the following information is maintained in the shipment document: Service agent or logistics provider which is responsible for the transport Mode of transport, such as rail, truck, plane Shipment type Estimated freight cost During shipment processing the shipment document is used to keep track of the shipment status. In addition the system does a leg determination which provides information about how the material reaches from the source to destination by calculating subsequent legs, transfer points (mode of transport: air, land, water) from the point of departure to destination. The determination is based on the simple rules maintained in the customizing and does not involve optimization algorithms and also has no geographical intelligence. One aspect of the transportation management is to handle the freight costs or the shipment costs that were involved when the material was delivered. The handling of freights is an integral part of the LE Transportation functions and always happens in the ERP system even though an external TMS system is used. In this case the freight requests are initiated by the external system to do the freight cost settlement in ERP. The costs incurred during the freights are booked separately and a separate FI documents are generated for this purpose to settle the freights. The freights can be handled by the manufacturer or by a third party logistics provider.
76
Internal
© Copyright SAP AG 2010
SAP ERP
2.7 Logistics Execution
2.7.5.1 Shipment Costs Processing The following explains how the shipment costs are calculated in the SAP ERP OPS with respect to the inbound and outbound point of view.
Shipment Costs: Inbound Shipment Processing As mentioned the inbound delivery processing creates a delivery document based on the purchase order. If transportation is required an inbound shipment document is subsequently created with reference to the delivery. The shipment document specifies who transports the material when to the customer. If the transportation cost is not included in the sales prices inbound shipment processing creates a shipment cost document. The shipment cost document stores the price of the transport, which can be entered manually or using price determination based on the customized pricing conditions. The second case is used, if the enterprise has a contract with the transportation provider. Afterwards the goods receipt processing is triggered which calls the shipment costs interface to transfer the cost as shown in figure 2-33. Thereby the shipment cost is transferred to goods receipt processing logic which passes them on to SAP ERP FIN. The successful receipt of material is also documented in the purchase order and also the delivery costs are updated in the purchase order.
Purchase Order (PO) Processing
Purchase Order
Invoice Verification Logic
Invoice for Materials + Invoice for Delivery Costs
R
Inbound Delivery Processing
Delivery Post Goods Receipt
R
Inbound Shipment Processing
Shipment
Goods Receipt Processing
Financials
R
Shipment Cost Processing
Shipment Cost Document
Transfer Delivery Costs
R
Pricing Logic Goods Receipts
Transportation + Delivery Cost
Logistics Execution (LE) Inbound
Figure 2-33 Inbound Shipment Cost Processing © Copyright SAP AG 2010
Internal
77
2 SAP ERP Operations
SAP ERP
The whole process ends with the invoice verification where two separate invoices are posted with reference to the purchase order. One invoice for the supplier and another for paying the delivery costs to the transportation agent. The payment is then initiated by SAP ERP FIN.
Shipment Costs: Outbound Shipment Processing Outbound shipment processing creates a shipment document to manage the transportation of the material from the shipping point to the ship-to location. One shipment document can plan the transportation of one or more deliveries.
Sales Orders
Sales Order Processing R
Outbound Delivery Processing
Delivery
Order Processing + Order Fullfillment R
Billing Logic
Outbound Shipment Processing
Shipment
R
Shipment Cost Processing (Estimated Cost)
Shipment Cost Document
Financials Pricing Logic
Account Assignment Logic
Customizing Transportation + Freight Costs R
Billing Document
Transfer Cost Data
Purchase Order Processing
Purchase Order
R
R
Service Entry Sheet Processing
Invoice Verification Logic (Actuals)
Service Entry Sheet
Invoice MM
Logistics Execution (LE) Outbound
Figure 2-34 Outbound Shipment Cost Processing Shipment cost processing contains the functions for calculating and settling shipment costs which arise from material transportation. To do so, outbound shipment processing
78
Internal
© Copyright SAP AG 2010
SAP ERP
2.7 Logistics Execution
triggers the creation of a shipment cost document with reference to the original shipment document (see figure 2-34). The separate shipment cost document helps companies to effectively plan transportation with transparent cost. Shipment cost processing calls the pricing engine to calculate the estimated shipment cost. The calculation of shipment costs is carried out using the condition technique in pricing (see chapter 2.4.3.1). In addition shipment cost processing triggers the account assignment logic where the appropriate accounting object for the shipment cost is determined for example cost center. If a third party logistics provider is involved in the shipment the shipment cost processing triggers the creation of a purchase order in MM to procure the corresponding services. The shipment cost as well as the account is passed to the purchase order. Now the process continues in MM: once the materials are delivered a service entry sheet is created with reference to the purchase order. As soon as the invoice from the third party logistics provider is received and verified SAP ERP FIN is triggered, which initiates payment of the invoice and billing of the shipment cost to the customer.
2.7.6 Warehouse Management SAP ERP OPS keeps track of the material stock in the inventory provided by MM. Every movement of goods into or out of the company is reflected there. Warehouse management supports controlling the movement and storage of material inside the company, more precisely within the company‟s warehouse. The typical operations in a warehouse include receiving, put away, picking, packing and transfer of material. LE provides only a lean warehouse management. But SAP ERP OPS can be integrated with the extended warehouse management provides by SAP SCM.
2.7.6.1 Technical Representation of the Warehouse Within LE a warehouse is represented in the following way: Warehouse number Each warehouse has an identifier, which allows managing multiple warehouses in parallel. Storage type A warehouse can provide multiple storage areas, which are defined by the storage type. Examples are high rack storage, bulk storage or fixed storage. Picking area (aka storage section) Each storage type has a picking area, where the material is picked. Storage bin Represents the storage space, where the material can be put. It is the smallest unit of space in the warehouse (also known as storage slot). Each storage type and picking area consists of a row of storage bins.
© Copyright SAP AG 2010
Internal
79
2 SAP ERP Operations
SAP ERP
Quant Describes whether there is material stored in a storage bin. Having the real warehouse mapped to the LE warehouse allows monitoring the stock, locating the exact position of material in the warehouse, and plan and triggering goods movements into, out of and within the warehouse. Warehouse management is integrated with the inventory management of MM. The inventory is still the central place, where all the material stock of the company is maintained.
2.7.6.2 Transfer Order The most important document that is used in the warehouse management is the transfer order. A transfer order is an instruction to move materials from source storage bin to destination storage bin in a specific warehouse at a specified time. It provides the information about the quantity of the materials that needs to be moved. A transfer order is created based on delivery, transfer requirement (created from production order to the issue materials of BOM for production) or posting change notice. The transfer order is created during both the inbound and the outbound shipping process to handle all the movements in the warehouse. Once the materials are moved to the destination the transfer order is confirmed.
2.7.6.3 Operation of Logistics Execution The number and size of warehouses vary a lot from company to company, which leads to different requirements regarding warehouse management. SAP addresses the different needs by offering four ways of running warehouse management: Central execution of lean warehouse management Execution of lean warehouse management on a separate system Integration of SAP ERP OPS with extended warehouse management of SAP SCM Integration with third-party warehouse management systems In the first case lean warehouse management runs together with SD and MM on one SAP ERP system. SD, MM, and warehouse management are integrated using database integration. Warehouse management as well as inventory management happens in the same system. But it is also possible to run the lean warehouse management on a separate system. In this case SD, MM (including inventory management) is performed within one SAP ERP system, whereas the complete LE is operated on a separate SAP ERP system. It is possible to run one or more LE systems together with one central SAP ERP system (see figure 2-35). In this case the delivery created by the central ERP system is replicated to the decentralized LE system using iDoc. Once the delivery is replicated the warehouse which
80
Internal
© Copyright SAP AG 2010
SAP ERP
2.7 Logistics Execution
is responsible for it performs delivery, shipment processing, as well as warehouse management operations. Once the LE confirms the delivery the relevant updates and postings happen in the central SAP ERP system to ensure consistency. The communication across systems happens via iDoc. Companies prefer to run LE decentralized for example when their warehouses are in different geographical locations or the warehouse itself wants to perform the logistics execution functions to meet high demands and ensure faster delivery of goods to the customers.
R
PP
Transfer Order Processing
Non-SAP System
Picking Logic
Packing Logic Lean WM
MM
Transfer Order Processing
R
R
Outbound Delivery Processing
Goods Issue Posting Logic
R
Delivery Processing (Replicated)
Picking Logic Packing Logic
R
SD
Trigger Goods Issue
Dispatcher Order Processing
Delivery Processing (Replicated)
Transfer Order Processing Picking Logic
R
Delivery Processing (Replicated)
Packing Logic Delivery Data
Extended Warehouse Management (EWM)
LE Shipping (Order Fulfillment) R
Localized Warehouse Management System
Additional Functions
Transfer Order Processing Picking Logic Packing Logic
Delivery Data
Localized Warehouse Management System
Decentralized Warehouse Management
Figure 2-35 Outbound Processing in LE The third option is to integrate SAP ERP OPS with extended warehouse management of SAP SCM which provides additional functions. In this case the delivery is sent from SAP ERP to SAP SCM using qRFC. Delivery and shipment processing is then performed within SAP SCM, but inventory management is still in the responsibility of SAP ERP. LE provides enterprise services, which can be used to integrate SAP ERP OPS with thirdparty warehouse management systems and external applications which support specific warehouse processes such as warehouse control units and fork lift control systems. Enterprise services are for example available to send transfer orders and cancel transfer orders.
© Copyright SAP AG 2010
Internal
81
2 SAP ERP Operations
SAP ERP
In all cases where warehouse management is operated on a separate system delivery processing calls the dispatcher located in the central SAP ERP system (see figure 2-35). The dispatcher determines the target system and sends the request to the corresponding system. To do so, the dispatcher reads a mapping table where the storage location, warehouse number are stored together with the destination system details. The dispatcher is called during the save operation of the delivery document.
82
Internal
© Copyright SAP AG 2010
SAP ERP
2.8 Quality Management
2.8 Quality Management Enterprises have to ensure that procured, produced, and sold material fulfills certain quality characteristics. These quality characteristics are checked by quality inspections and documented using quality certificates. In SAP ERP OPS quality management (QM) provides functions for quality planning, quality inspection, and quality control during sales, production and procurement. QM complies with standard ISO 9001which defines the requirements for a quality management system. A material becomes subjected to the quality inspection process by maintaining the corresponding setting in the material master. Quality management is divided in the following building blocks (see figure 2-36): Quality planning for defining which kind of quality inspection has to be performed at which point in time Quality inspection for performing the inspection and documenting its results Quality notification for triggering follow-up steps when an inspections discovered bad quality Quality control provides reporting functions to evaluate quality management processes Quality certification processing for checking as well as creating quality certification documents Quality in procurement logic for checking if procured material fulfills its quality requirements and certifications Quality management processes are closely interlinked with the business processes in MM, SD, and PP. QM is integrated with SD to perform quality inspections of the outgoing material and issue quality certificates if required. Similarly QM is integrated with MM to check, if incoming material fulfills the company‟s quality requirements. The company can check, if the material is accompanied by a valid quality certificate or inspect the material on its own. If the check is not successful goods receipt or invoice processing can be blocked. To control the quality of raw material after a production order is created and finished products after production the QM process can be triggered to perform the quality inspection on the characteristic properties of the material In addition, QM also provides integration to the batch management when the material is handled in batches and to the classification system (see also chapter 2.1.1.1).
© Copyright SAP AG 2010
Internal
83
2 SAP ERP Operations
SAP ERP
PP
MM
SD
Source R
R
R R
Quality Inspection Quality in Procurement Info Record
Quality Planning R
Inspection Plan Processing
Inspectionn Lot Processing
Quality in SD Logic Quality in Procurement Logic
Batch Management
R
Material Specification Processing
R
Inspection Lot Data Quality Control R
Result Recording Logic
Failure Mode Effect Analysis (FMEA) Processing
Usage Decisions Data
FMEA Data
Classification System
Quality Control Chart
Results Data
Usage Decision Processor
Quality Certificate Processing
Certificate Profile
Quality Evaluation Tools
R
R
Quality Notification FMEA Determination Logic
Quality Notification Data
Document Management System (DMS)
Quality Management (QM)
Master Data Master Characteristics
Material
Inspection Plan
CodeList
Material Spec Data
Figure 2-36 Architecture Overview of Quality Management
2.8.1 Quality Planning Quality planning is used to define the inspections and plan their execution. The quality planning in SAP ERP provides functions to maintain the master data for the inspection process, for example:
84
Internal
© Copyright SAP AG 2010
SAP ERP
2.8 Quality Management
Master inspection characteristics Inspection method Inspection plan Material Specification The master inspection characteristics provides information such as tolerances, reference to class characteristic (for example, dimension, color), and assigned inspection methods. Master inspection characteristics can be reused by multiple materials. The inspection method describes how to carry out an inspection for a given inspection characteristic. Documents for example specific inspection instructions and drawings can be attached to an inspection method using document management system (DMS). The inspection method and the master inspection characteristics can have multiple versions. In QM, the quality inspection is either based on an inspection plan which is at the plant level or based on material specifications. The inspection plan defines a sequence of operations or tasks to be performed for inspection. Some of the details that are maintained at the operation level include: How the inspection is to take place The work center for the inspection The sequence in which the inspections are to take place The test equipment that is required for the inspection Default values (such as base quantity, unit of measure, conversion of units of measure (header/operation) In addition it is possible to describe within which processes inspections take place, for example goods receipt process, goods issue process, or inspection of stock transfers. The inspection plan can be assigned to multiple materials. Several inspection plans with different operations or inspection characteristics can be assigned for a combination of material, vendor and manufacturer, material and customer. During the actual quality inspection the details of the inspection plan are read and used for further processing. A material specification defines a inspection of a specific material. It is maintained by assigning master inspection characteristics to a specific material. The material specification can replace or supplement a plant-specific inspection plan. It is used during the quality inspection especially during the inspection lot creation. The inspection specifications defined in the material specification take precedence over the inspection specifications of the inspection plan. Material specification processing has interfaces to batch management to reference the batch characteristics in the material specification.
© Copyright SAP AG 2010
Internal
85
2 SAP ERP Operations
SAP ERP
2.8.1.1 Failure Mode Effect Analysis Processing (FMEA) Failure Mode Effect Analysis Processing (FMEA) is used to keep track of failures and trigger follow-up steps. It is used by quality managers to analyze failures. If a new failure occurs for the first time it is added to the FME data. If the failure is already known, the data is updated. FMEA processing allows calculating the probability of a failure occurrence which is used to calculate a so called risk priority number (RPN). These numbers are part of the quality notification which is sent to the quality manager.
2.8.2 Quality Inspection The quality inspection component is used to determine whether the company‟s product consistently meets defined quality requirements by conducting quality inspections. In a quality inspection, a material or product is inspected, based on the inspection criteria maintained in the inspection plan. Quality inspection has the following important functions (see figure 2-36) which are discussed in more detail: Inspection lot creation Results recording Usage decision logic for inspection lot completion In addition the quality inspection is integrated with QM in procurement (for example, quality info record in procurement, quality assurance agreements in procurement). QM in production (for example, inspecting by batch, serial number processing, inspection of variant products). QM in SD (for example issuing of quality certificates, quality assurance agreements in sales).
2.8.2.1 Inspection Lot Processing Quality inspections are processed on the basis of inspection lots, which define a specific quantity of a material or a piece of equipment to be inspected. In QM the inspection lot is a document that is created for the material at plant level. It is the first step for performing the quality inspection. An inspection lot can be assigned to goods receipt, goods issue, and production process. The inspection lot processing is integrated with MM, PP, SD functions as shown in figure 2-36. The inspection lot has information like the inspection start date, end date, inspection quantity and lot quantity. The inspection lot also specifies whether it is relevant for the goods movement. If the inspection lot for example is relevant for goods movement then the lot quantity will be posted to inspection stock. Inspection stock indicates that the material is subjected to quality inspection and cannot be used until the stock is posted for the unrestricted use. The postings in the inventory happen based on the inspection results and usage decision. 86
Internal
© Copyright SAP AG 2010
SAP ERP
2.8 Quality Management
Once the inspection is completed and the material meets the quality standards then the material is moved from the status “inspection” to “unrestricted use” and is made available in the inventory. The inspection lot processing can happen in the following processes: Process inspections for goods receipts in MM Process inspections during production when production orders or process orders are released Process goods issue inspections when deliveries are created in LE When an inspection lot is created, the following functions are executed by the inspection lot processing: 1. Inspection lot creation 2. Assignment of an inspection specification which was created in inspection planning 3. Calculation of sample size (using sampling procedures or entered manually) 4. Printout of instructions Once an inspection lot has been created, the goods can be inspected and the results or defects are recorded and a usage decision is made to complete the inspection.
2.8.2.2 Result Recording Processing The results recording processing is used to record the results of the quality inspection for an inspection lot. The results are stored separately with references to the inspection lot. The recorded inspection results document the quality of the inspected product and provide the basis for providing batch values and inspection certificates. The recorded result data are also used to make evaluations for quality control purposes. The result recording has interfaces to the quality control chart for statistical process control (SPC) tools. If the inspected material does not meet the quality standards the defects are maintained in the result recording. The defects are included into the quality notification which is sent to the quality manager to take appropriate actions.
2.8.2.3 Usage Decision Logic The usage decision is the last step in the quality inspection which completes the whole inspection process. Based on the results and defects that were recorded for the inspection lot, a decision is now made whether the inspected goods can be accepted or rejected for use. The usage decision logic helps document the information via the usage decision document of the decision that was taken as the result and can trigger follow-up actions if required. To make a usage decision, the inspection results have to be recorded for all obligatory inspection characteristics
© Copyright SAP AG 2010
Internal
87
2 SAP ERP Operations
SAP ERP
The usage decision has interfaces to the goods movement functions of MM. The quality stock which is blocked for inspection can be given free to unrestricted use or moved to scrap based on the usage decision. If an inspection lot is not stock-relevant, then no stock postings are possible with the usage decision functions. Examples of inspection lots that are not stock-relevant include all manually created inspection lots and lots that were created for a production order The usage decision can also influence if the materials are handled in batches. Some of the functions include Change the current batch status (from "unrestricted" to "restricted" or vice versa) Transfer the results of the batch characteristics value If for example an inspection lot material is processed in batches and the results of the quality inspection doesn‟t meet the quality expectations then the entire batch status is set to restricted use. In this case the quality notification could be triggered and the quality manager can decide if further inspections needs to be planned or not.
2.8.3 Quality Control The quality control provides tools for evaluating the inspection results using statistical process control (SPC). The most important tool in SPC is the quality control chart, which is a graphical tool used by quality technicians to control, analyze and document the quality issued in the different business processes. The quality control components read the data from the quality inspection components to compute the statistics. The quality control can also trigger quality notifications for example if inspection result values exceed the limits of a control chart.
2.8.4 Quality Notification The quality notification records general quality problems for example faced during the quality inspection. It records some of the information like problem, materials affected, vendor, names of partners involved in the problem. The quality notification provides a user interface to maintain the above details and has an action box which maintains possible actions that can be triggered. The action box has predefined actions that the company can use to react to the quality situations and in addition can have own actions depending on the custom requirement. The quality notification is a separate object that is persisted in the database.
2.8.5 Quality in Procurement Processing The quality in procurement processing is a separate component in QM and is integrated with procurement, goods receipt and invoice processing of MM. Through this component the materials procured from the external vendor is subjected to the incoming quality check and for the same reason this component is integrated with the inspection lot
88
Internal
© Copyright SAP AG 2010
SAP ERP
2.8 Quality Management
processing. The quality in procurement processing is also used by companies that demand quality certificate from the vendor for the material. In SAP ERP OPS the quality in procurement info record is maintained for the material, vendor and plant combination that contains data such as block function (process during which the material was blocked for example goods receipt) , block reason, medium through which the quality certificate should be transferred from vendor and control data for inspection. Based on the data the quality in procurement performs certain functions such as Release or block vendors Evaluate vendors on the basis of quality Request that quality certificates be submitted with the delivered goods and monitor the receipt of these certificates Inspect vendor goods upon receipt (goods receipt inspections) Block the payment of invoices until the goods have been inspected and accepted The quality in procurement info record will be required based on the setting of the control key in material master. When the inspection lot is created by the goods receipt process, the quality in procurement info record is read by the system for further processing. Then checks are made if the vendor is subjected to block for any reason or if the quality certificates should be issued by vendor. If the inspection results suggest a block then the system for example posts the goods to the blocked stock The quality in procurement results are used during the invoice verification as well, for example the invoice is blocked until the quality inspection is complete or the usage decision during the goods receipt inspection was not approved that led to the invoice block.
2.8.6 Quality Certificate Processing A quality certificate certifies that a material meets specific physical and chemical properties. The quality certificate component provides the following functions: Automatic creation of the quality certificates when materials are shipped Distribute quality certificates to a predefined list of recipients Print certificates, or send them for example via iDoc based on output determination technique Create certificates in the language of each recipient Store certificates using SAP Archive Link Quality certificate processing is integrated with SD and MM processes. The quality certificate processing component generates quality certificates that certify the inspected material. The quality certificate is an electronic document transmitted via iDoc to the customer on demand or received from vendor on request.
© Copyright SAP AG 2010
Internal
89
2 SAP ERP Operations
SAP ERP
In case the manufacturer has to issue the quality certificate the goods issue processing triggers the quality certificate process which collects the quality data at runtime in the buffer with reference to the delivery document. The collected data is constructed and transmitted electronically using the message output determination technique (see chapter 2.4.3.3). QM does not store the quality certificates directly in the database. They are automatically stored using SAP Archive Link directly after printing. The certificate profile is an important master data that is used by quality certificate processing. It is used to determine the selection and sequence of the characteristics whose results are to be documented in the certificate. The certificate profile is attached to material, material group, or material/customer combinations. By doing so, certificates can be sent individually for specific customers. At the same time, general certificate profiles can be used, if there is no special certificate profile for the customer. The condition technique is used to determine the right combination to issue the quality certificate (for condition technique see chapter 2.4.3) From the MM point of view, the quality certificate processing is linked to the quality in procurement processing component (see figure 2-36). The goods receipt document doesn‟t supply all the quality related data for performing the incoming quality check. For the same reason the quality certificate is not linked to the goods receipt document. In LE the quality certificate is linked to the goods issue processing. The quality certificate in procurement is a separate database object which is linked to the incoming quality certificate (iDoc) from the vendor. The inspection lot is then created with respect to the goods receipt and the characteristics of the inspection lot gets the value transferred from the iDoc for performing quality inspection.
90
Internal
© Copyright SAP AG 2010
SAP ERP
2.9 ERP OPS Further Reading
2.9 ERP OPS Further Reading [Mur08]
Martin Murray, SAP MM: Functionality and Technical Configuration (2nd Edition), SAP Press, 2008
[Mur07]
Martin Murray, SAP Warehouse Management: Functionality and Technical Configuration, SAP Press, 2007
[Hop06]
Marc Hoppe, Inventory Optimization with SAP - Effective Inventory Management with mySAP ERP and mySAP SCM, SAP Press, 2006
[Iye07]
D. Rajen Iyer, Effective SAP SD, SAP Press, 2007
[DKW07]
Jörg Dickersbach, Gerhard Keller, and Klaus Weihrauch, Production Planning and Control with SAP, SAP Press, 2007
[Gau08]
Othmar Gau, Transportation Management with SAP LES, SAPpress 2008
[SAP06]
Office of the CTO, mySAP Business Suite Service Provisioning, SAP Architecture Bluebook, SAP AG, 2006, https://portal.wdf.sap.corp/irj/go/km/docs/guid/60f07fd0-7f4c-2910-2b98-a4ec00df5f74
[SAP07]
SAP Masterguide: mySAP ERP 2005 powered by SAP NetWeaver 2004s, SAP AG, 2007, https://service.sap.com/~sapidb/011000358700005293822005E
© Copyright SAP AG 2010
Internal
91
2 SAP ERP Operations
SAP ERP
2.10 ERP OPS Glossary Term
Definition
Plant
Place where the material is procured, sold or produced
Client
Represents the legal entity for example a company, has its own master data
Company code
Its defined for financial purpose, also a subdivision of company
Sales organization
Responsible for selling the material to customers
Purchasing organization
Responsible for procuring the materials from vendors
Storage location
Location within a plant to store the material
Shipment location
Shipping points are independent organizational entities within which processing and monitoring of the deliveries as well as goods issue is carried out.
Condition technique
The condition technique refers to the method by which the system determines prices for example from information stored in condition records.
Lot Size
This refers to the quantity that is planned for production or that needs to be procured during MRP. Based on the lot size procedures the system calculates the lot size
Foreign applications
Generally in purchasing applications this term refers to the applications that are called by the purchasing functions which have their own UI and business logic. Like for example services, account assignment etc are considered as a foreign application.
92
Internal
© Copyright SAP AG 2010
3 SAP ERP Financials Author: Sushil Kumar (IMS Financials)
3 SAP ERP Financials
SAP ERP
Acknowledgement The following colleagues contributed in various ways to make this or previous editions of the document possible: Jochen Böder, Rüdiger Buck-Emden, Bernhard Gröne, Wolfram Kleis, Lai Wei (Architecture Governance and Standards)
I would like to thank the following colleagues for FI Topics: Volker Kleinhenz, Dieter Gietl, Reiner Kastner, Silke te Uhle, Olaf Wellm, Steffen Hoffmann, Alla Korchminskaya, Ralph Stadter, Klaus Moser, Michael Lang, Gerhard Rupp, Arndt Koester, Georg Tewes, Bernd Oberdorf,
Management Accounting Topics: Marco Valentin, Alexander Mueller, Thomas Kessler, Ralf Humbert, Winfried Teltscher, Peter Himmighoefer, Susanne Richter,
FSCM topics: Dietmar Engelmann, Kannan K R, Sreeram Subram N, Sidhartha Chakravarty, Hari Krishna K, Kartik R, Scott Sun, Volker Kleinhenz, Friedrich Schattmaier,
Treasury Topics: Klaus Mueller, Andreas Martin, Thomas Haertlein, Vinodh A R, Vishwanath G, Balaji Sundaram S.
I would like to thank the following colleagues acting as additional reviewers: Juergen Alfred Seyfried, Dietmar Engelmann, Artur Berlinger.
I would like to thank in general the colleagues for providing valuable inputs and / or support for the blue book: Sathish Karthik R, Christian Klensch, Andreas Baur, Uma Rani T M, Sundaresan LN, Ankush Mane, Peter Buendgen, Uwe Dieckbreder, Shrikant Varma, Pranav Wankawala, Aruna Kumari S, Vidya Omprakash. Sushil Kumar
94
Internal
© Copyright SAP AG 2010
SAP ERP
3.1 Introduction to SAP ERP Financials
3.1 Introduction to SAP ERP Financials The analysis and control of financial transactions as well as correct reporting are crucial for today‟s enterprises. In this context financial accounting is about recording, classifying, and summarizing the financial transactions of a company and reporting the results to the stakeholders of a company. The stakeholders are for example employees, investors, shareholders, creditors, government, and communities. Management accounting on the one hand collects accounting information to enable an enterprise‟s management to make informed decisions. On the other hand it allows managing and controlling budget and spending. SAP ERP Financials (SAP ERP FIN) is SAP‟s solution for financial as well as management accounting (see figure 3-1). In addition, SAP ERP Financials includes financial supply chain management (FSCM) for managing payables and receivables, and treasury which helps to ensure the liquidity of the enterprise. SAP NetWeaver BW (Business Warehouse)
SAP ERP Industry-Specific Functionality
SAP CRM (Customer Relationship Management)
Financials
SAP SRM (Supplier Relationship Management) SAP SCM (Supply Chain Management)
Management Accounting (CO)
Human Capital Management (HCM)
Operations Financial Supply Chain Management (FSCM)
SAP GRC (Governance & Risk Compliance)
Corporate Services
Financial Accounting (FI)
Treasury
SAP MII (Manufacturing Integration and Intelligence) SAP NetWeaver PI (Process Integration)
Figure 3-1
Architecture Overview of SAP ERP
SAP ERP FIN is part of SAP Enterprise Resource Planning (SAP ERP), which also embraces Corporate Services, Human Capital Management (HCM), Operations, and Industry Specific Functionality. 3
Within this document, the architecture of SAP ERP FIN 6.0 is described, which is the stable core release. New functionalities for SAP ERP FIN are developed and shipped within enhancement packages.
3
ERP 6.0 was released in 2006. Latest EhP (Enhancement Package) released in 2010 is EhP 5.
© Copyright SAP AG 2010
Internal
95
3 SAP ERP Financials
SAP ERP
3.1.1 Overview of SAP ERP Financials As SAP ERP FIN is responsible for accounting, it receives information about financial transactions from other business applications. Within the SAP Business Suite these are the following applications: SAP ERP Materials Management4 (SAP ERP MM) which posts inventory movements, costs, payables, taxes, etc. SAP ERP Sales and Distribution (SAP ERP SD) which posts sales receivables, revenue, taxes, etc. SAP ERP Human Capital Management (SAP ERP HCM) which posts payroll data. SAP Customer Relationship Management (SAP CRM) which posts sales receivables, revenue, taxes, etc. In a typical deployment scenario, SAP ERP MM, SAP ERP PP, and SAP ERP SD share one system with a common database with SAP ERP FIN. But also in distributed deployment scenarios, SAP ERP Operations and SAP ERP FIN use the same master data such as material, customer, and vendor. SAP ERP HCM and SAP CRM are operated on separate systems and integrated with SAP ERP FIN using Application Link Enabling (ALE) and iDOC. Treasury could be run on a separate server. 5
These applications post data about financial transactions using the accounting interface which distributes the data to financial accounting, management accounting, treasury, and FSCM (see figure 3-2). Each of these applications is structured in sub-applications, which are described in the following sections. Reuse components (see figure 3-2) is a layer which provides basic functionality for all SAP ERP FIN applications. It includes archiving, currency conversion and financial basis. SAP ERP FIN is built in ABAP using Dynpro as UI technology. The online payment infrastructures Biller Direct & Payer Direct (see also section 3.5.2) are implemented in Java.
3.1.2 Financial Accounting Financial accounting records all expense, revenue, and stocks (assets) related business transactions of a company in ledgers. There is the general ledger and the subsidiary ledgers (also referred to as sub-ledgers, see figure 3-2).
4
SAP Supplier Relationship Management (SRM) is not integrated directly with SAP ERP FIN, but with SAP ERP MM, which then communicates SAP ERP FIN. 5 Some old MM transactions such as MR01 have their own coding to trigger the creation of FI documents directly. 96
Internal
© Copyright SAP AG 2010
SAP ERP
3.1 Introduction to SAP ERP Financials
Product Cost Controlling
Cost Center Accounting
Cost Element Accounting
Internal Order Accounting
Activity Based Costing
Profitability Analysis
Profit Center Accounting Consolidation
R
SAP Governance & Risk Compliance
R
Business Planning
Controlling
Enterprise Controlling
Management Accounting
Accounting Interface
GRC Data
SAP ERP Human Capital Management
Executive Information System
R ALE
Payroll Data
General Ledger Processing (Classic / NewGL)
R
Accounts Payable Processing
Tax Accounting Managment
Cash Journal Accounting Management
Accounts Receivable Processing
Asset Accounting Management
Contract Accounting
Subsidiary Ledger Processing
R
Financial Accounting SAP Customer Relationship Managment
R
R
Sales & Distribution
R
Treasury and Risk Management
In House Cash
Collection Management
Dispute Management
Bank Communication Management
Cash and Liquidity Management
Credit Management
Biller Direct (Java)
SD Data
CRM Data SAP Supplier Relationship Managment
R
Material Management
R
Treasury R
SRM Data
MM Data
ERP Operations
Reuse Components
Archiving
Financial Supply Chain Management Currency Conversion
SAP ERP Finanicals
Customizing Data (Company Code,Currency, Fiscal Year, and so on)
Master Data (G/L Accounts, Customer, Vendor, etc)
Transaction Data (G/L Account/Customer/Vendor Lines and Summary)
ERP Database
SAP ERP
Figure 3-2
Architecture Overview of SAP ERP Financials
The general ledger (G/L) contains all financial transactions and their summarizations for a defined reporting entity, for example a company. The general ledger is used to generate (periodic) legal reporting, for example the enterprise‟s balance sheet. Subsidiary ledgers are used for recording, summarizing, and reporting financial transactions according to specific categories. The Sub-ledgers explain in detail the G/L Accounts that are assigned. The following subsidiary ledgers are kept within financial accounting:
© Copyright SAP AG 2010
Internal
97
3 SAP ERP Financials
SAP ERP
Accounts receivable which stores and manages for example invoices and payments for each customer of the enterprise. Accounts payable which stores and manages for example the enterprise‟s invoices and payments for each vendor. Fixed asset accounting which stores and manages financial values of assets such as buildings, machines, and equipment. Cash journal accounting which stores and manages cash transactions of the company. Tax accounting which stores all tax-relevant financial transactions. 6
Contract Accounting (FI-CA) manages the collection processes for SAP industry solutions with a huge number of customers and documents (such as utilities, telecom, insurance, public sector). It provides highly automated processes and compressed document structures for an efficient and scalable management of mass data. The postings are transferred to FI-GL in a consolidated form. Financial accounting includes closing operations which run periodically to fulfill legal reporting needs. With the release SAP ERP ECC 5.0, a new general ledger (NewGL) has been introduced in financial accounting. NewGL has an improved update and reporting architecture which supports reporting in different dimensions such as profit center, segment, business area (for NewGL details, see chapter 3.3.4).
3.1.3 Management Accounting Management accounting (Controlling) refers to recording and controlling the accounting activities within a company or a group of companies. The objective of management accounting is to enable the management to have information such as costs, comparisons of planned versus actual costs, origin of costs etc. in order to maximize profits and minimize losses. It also supports valuation of stocks for FI like WIP. Management accounting is divided into Controlling and Enterprise Controlling (see figure 3-2). Controlling supports management accounting with focus on companies. From controlling perspective, one or more companies are assigned to one controlling area. Under the controlling area the profit centers, cost centers, internal order and cost objects are defined. These are the building blocks for recording and managing costs in a controlling area. Controlling consists of the following components (see also chapter 3.4): Cost element accounting, which describes the origin of costs, Cost center accounting, which describes where the costs were incurred (for example a location),
6
The details about FI-CA are not covered in this document. For more details please see SAP Help: Contract Accounting http://help.sap.com/saphelp_erp60_sp/helpdata/en/48/0c2842e11bca7ee10000000a1550b0/frameset.htm 98
Internal
© Copyright SAP AG 2010
SAP ERP
3.1 Introduction to SAP ERP Financials
Internal order, which describes for what purpose the costs incurred, Activity based costing to assign and manage costs of a business process, Product cost controlling, which collects the costs related to production and sales of goods, and Profitability analysis which helps analyzing the profitability of a market segment. Enterprise controlling provides management accounting functionality for a group company or an enterprise, which consists of multiple profit centers. It consists of the following modules: Profit center accounting measures profits with reference to a profit center on a periodic basis. For a profit center, it collects financial data and provides key figures such as return on investment, cash flow, and sales per employee. Consolidation aggregates financial statements of a group of companies as consolidated statements. It provides statutory and internal management reporting and consolidation functions for companies, divisions, business areas and profit centers. Executive information system (EIS) is a system which is used to collect and evaluate information from different areas of a business and its environment. Sources of this information can be the financial accounting information system, management accounting information system, the human resource information system and the logistics information system. The information provided serves both management and the employees in accounting. Business planning records and aggregates financial data from various operative systems, such as the financial information system, human resource information system, and logistic information system. It enables group-wide planning based on this data. It has the same data basis as the EIS. The data pool is organized in individual sub-sections of summarized business information called aspects. These aspects are then used for planning. Management accounting receives cost relevant data from SAP ERP Operations, financial accounting, treasury, and SAP ERP HCM. It is integrated with financial accounting to post the actual costs that needs to be reported as per legal requirements.
3.1.4 Financial Supply Chain Management Financial supply chain management (FSCM) provides the extension for both SAP and non-SAP systems in finance, customer relation management, supplier relation management, and operations. FSCM contains the following components (see figure 3-2): Collections management helps managing the company‟s receivables. It allows identifying and prioritizing customers with open invoices, and contacting them to collect the receivables. Dispute management supports monitoring and managing disputes which arise in case a customer disagrees with an invoice. Dispute management is integrated with biller direct.
© Copyright SAP AG 2010
Internal
99
3 SAP ERP Financials
SAP ERP
Biller direct is a Java application which allows customers to pay invoices online, for example using credit card. Credit management makes transparent risk of losses from the enterprise‟s receivables, supporting efficient credit decisions. FSCM is integrated with financial accounting to exchange financial information.
3.1.5 Treasury Treasury provides functionality to model, assess, and minimize financial risks and to control payments and bank transactions. Treasury consists of the following components: Treasury and risk management provides various application tools for recording and managing financial transactions and instruments such as loans, securities, derivatives. This also helps in managing the risk associated. Cash management monitors the cash flow to meet the current and future payments to be made. Liquidity planner is part of liquidity management, which provides capabilities to enter, summarize, and to evaluate the cash flow planned. This also helps determining and comparing the actual values in cash flow. These two modules provide the management transparency and control over the financial resources. In-house cash allows global enterprises to create a central in-house cash center acting as a virtual bank for internal and external payment transactions. The central in-house cash center is maintained at the head office within a group company or enterprise and performs all internal and external money transfers. This reduces the number of external money transfers and the number of bank accounts of the enterprise. Bank communication management allows connecting to external bank systems via SWIFT network to carry out money transfers in a more secure and faster method compared to the usage of payment media or file transfers.
3.1.6 Accounting Interface Business applications such as SAP ERP SD, SAP ERP MM, SAP ERP HCM, and SAP CRM, use the accounting interface to report their expense, revenue and stocks (assets) related business transactions to SAP ERP FIN. The accounting interface is the central integration hub of SAP ERP FIN, as it receives data from multiple applications and again distributes it to the relevant SAP ERP FIN sub-applications (see figure 3-2). Applications which are installed on a separate system call the accounting interface synchronously to create a financial document (FI document). Within the same logical unit of work, the accounting interface then calls the different sub-applications of SAP ERP FIN accordingly. For example general ledger is updated by any financial transaction which is posted using the accounting interface.
100
Internal
© Copyright SAP AG 2010
SAP ERP
3.1 Introduction to SAP ERP Financials
3.1.7 Deployment With the exception of biller direct, SAP ERP FIN is running on top of the ABAP application server of SAP NetWeaver. It is installed together with SAP ERP Operations, but it is possible to operate SAP ERP FIN without operating SAP ERP Operations on the same system. SAP ERP FIN software components are as depicted in figure 3-3.
SAP_APPL Financial Accounting (FI)
FSCM Components Financial Supply Chain Management (FSCM) FSCM Components
FSCM Components
Management Accounting
Treasury FIN-BASIS
EA-FINSERV
SAP ERP Fin
Figure 3-3
© Copyright SAP AG 2010
SAP ERP Fin Software Components
Internal
101
3 SAP ERP Financials
SAP ERP
3.2 Recording Financial Accounting Interface
Transactions
Using
the
The accounting interface is the central integration hub of SAP ERP FIN. It receives data from multiple applications and distributes it to the relevant SAP ERP FIN subapplications, such as financial accounting and controlling (see figure 3-4).
Sales & Distribution
R
Material Management
SD Data
MM Data
SAP ERP Operations (Ext.) R
R
R
TR Documents R
Accounting Interface
Check Human Capital Management
Financial Accounting
Controlling
...
R
ALE
Project
Post Interface
CO Documents
Split
SAP ERP HCM (Ext.)
R
...
Payroll Data
Close
FI Documents
Create Interface
FI Interface
RFC
SAP CRM
CO Interface
CRM Data
Treasury
...
Customer Relationship Management
Old MM Transactions
MM/ML Data Accounting Interface Data SAP ERP FIN
Figure 3-4
The Accounting Interface as Integration Hub
The accounting interface consists of two interfaces which are called in sequence by external business applications (see figure 3-4): Create interface which checks the incoming accounting data and distributes it to the different accounting applications of SAP ERP FIN and Post interface which triggers the database update of the accounting tables. Whenever a financial relevant business document is created, for example a goods receipt, a customer invoice, or a payroll run, the corresponding application in SAP ERP MM, SAP ERP SD, SAP CRM, or SAP ERP HCM releases the corresponding document 102
Internal
© Copyright SAP AG 2010
SAP ERP
3.2 Recording Financial Transactions Using the Accounting Interface
to SAP ERP FIN by calling the create interface of the accounting interface. In case the calling application is installed on the same SAP ERP system as SAP ERP FIN, the interface is called using an ABAP function call. In case the calling application is remote, RFC is used. SAP ERP HCM is integrated by ALE. The create interface performs four processing steps – check, close, split, and project (see figure 3-4) – during which the incoming data is checked, validated, enriched, split, and mapped. To do so, the create interface calls the check, close, split, and project modules provided by the receiving applications. The receiving applications store the incoming data in separate documents, for example financial accounting in FI documents (see also chapter 3.3.1) and controlling in CO documents. When the create interface returns successful execution, the calling application calls the post interface to trigger the database update of SAP ERP FIN. The accounting interface is also used to distribute data within SAP ERP FIN, for example from controlling to financial accounting, or from financial accounting to controlling or performance cost analysis. The financial accounting interface can also be used to post financial data from non-SAP systems using BAPI or IDoc interfaces.
3.2.1 Create Interface The create interface receives the input parameters as internal tables which are structured in the following way: Header which contains common data such as the entry date and time, document header text; Line items which contain item-specific data such as the account information (except tax accounts, which are in some cases derived in FI interface), amounts, transaction identifiers, posting key, or debit-credit indicator; Currency information which contains the amounts for each currency type and currencies for each line item. Currency types could be local currency, group currency, hard currency, and so on. These internal table structures are the super structures that contain all the necessary information for all SAP ERP FIN applications. Also, when necessary, accounting applications derive other specific information from this data during posting of the document.
© Copyright SAP AG 2010
Internal
103
3 SAP ERP Financials
SAP ERP
Calling Application
Accounting Interface
Registered Modules
Release Document to Accounting
Call Create Identify registered Check modules Error in Check
Identify registered Close modules Error in Close
Identify registered Split modules Error in Split
Identify registered Project modules
Check Modules
Execute Check
Close Modules
Execute Close
Split Modules
Execute Split
Project Modules
Error in Project
Execute Project Raise Error Handle Error
Call Post Identify registered Post modules
Post Modules
Execute Post Raise Error Handle Error
Commit Postings
Figure 3-5
104
Data Flow in Accounting Interface
Internal
© Copyright SAP AG 2010
SAP ERP
3.2 Recording Financial Transactions Using the Accounting Interface
As mentioned above, the create interface consists of four processing steps which are 7 executed in sequence: check, close, split, and project (see figure 3-5). Each SAP ERP FIN application which receives data via the accounting interface provides corresponding check, close, split, and project modules, which are registered for certain accounting data. The registration is defined in a system table. The customizing also defines the sequence in which the modules need to be called. This is important because every module depends on information enriched by the previously called module. When the create interface is called, the following processing steps are performed (see figure 3-5). For each step, the create interface first checks which modules are registered and then calls them in the right sequence. Check modules check the consistency and correctness of the incoming financial data and derive further information which is required for accounting. For example they check whether the company code exists, and they derive the currency in which the value should be accounted. They write back the enriched data to the accounting interface data. Close modules perform various checks on the incoming accounting data as per their own application requirements. For example, a close module in financial accounting checks whether the amounts in a document balance to zero. Here the data received from the Check module is read and checks are performed. The data is not enriched or written back to accounting interface. Split (introduced in release ERP 5.0) module internally calls „project‟ event related functions and then splits the business transaction line items based on special split criteria (refer to NewGL section 3.3.4 where the split functionality is described). Project modules map the checked and enriched accounting data to the accounting tables of the target application (projection). Now each accounting application is ready to post the received accounting data in their specific documents – for financial accounting these are FI documents, for controlling these are CO documents, and so on. If the processing of one of the steps fails, an error is raised and communicated back to the calling applications. Otherwise the create steps are completed successfully for all registered applications and the external application calls the post interface to trigger the final database update.
3.2.2 Post Interface During the create call, the receiving applications prepare the incoming data to create their internal document and store it within internal tables. When the post interface is called, all registered post modules are identified and then called in sequence. The post modules store the documents in the database. With successful execution of the post call, the corresponding documents are posted. 7
Check, close, split, and project are common for all incoming accounting data. Further processing steps can be added for processing incoming accounting data using customizing settings. © Copyright SAP AG 2010
Internal
105
3 SAP ERP Financials
SAP ERP
Both create and post calls of the accounting interface are processed together in one logical unit of work (LUW). When the post interface call is successfully completed, the sending business transaction completes the process by issuing „commit work‟, which makes the changes permanent on the database. When the accounting data is successfully posted, the post interface returns a success message, else a failure message along with necessary details is passed on. The possibility of registering individual accounting applications with their check, close, split, project, and post modules allow to flexibly add further accounting applications without changing the interface or the posting process of the other components. In case the accounting data is received from SAP ERP MM such as goods movement, it is possible to store a backup of the incoming data during post (see figure 3-4). Later on this backup data can be used to post the data again manually in case of failure. Other applications can post their data again by re-releasing it, but during the postings from SAP ERP MM important information such as price is available only during the time of posting and not afterwards. The reason for this is that SAP ERP MM calculates the price for a material on the fly based on available quantity and price per quantity which changes over time.
106
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
3.3 Financial Accounting Financial accounting is the core of SAP ERP FIN. It is required by each enterprise to record all expense, revenue and stocks (assets)-related business transactions in ledgers and provides legal reporting, such as the balance sheet. External Application (such as SD,MM,HCM..) Account Determination R
Create
Accountant / CFO
R
Post
Create Interface R
Check
Close
Split
Post Interface
Project
Accounting Interface R
R
Simulation/Post Processing
Check Modules
R
R
Close Modules
Split Modules
Project Modules
User Interface GL/Customer/Vendor/ Company Code Master/Customizin data
R
R
FI Interface R
Tax Supplementary Items Creation
Common Routines
Validation & Substitution at Document Level
Document Processing
FI Document (Buffer)
Header
Post Modules
R
R
Specific Routines
R
FI Posting Simulation
Line Items
Document Number Range
R
Document Number assignment
Secondary Information Update Routines (Commitment/Barcode etc)
Trigger WorkFlow
R
Create Accounting Documents
Preprocessing for DB update R
Document Creation /Update
G/L Update
Accounting Interface
Line Item Entry Processing
Header Entry Processing
R
Sub-Ledger Update Database Update Routines
Reporting (Reports / Transactions / Financial Statements)
FI Documents
P&L Accounts
Balance Sheet / Asset Accounts
General Ledger Data
Customers (Accounts Receivables)
Vendors (Accounts Payables)
Assets
Sub-Ledger Data
Transaction Data
Financial Accounting
Figure 3-6
Financial Accounting Overview
Business documents, such as invoices, receipts, or checks, are recorded in financial accounting documents (FI documents). FI documents are either created by the financial interface (FI interface, see 3.3.2) which receives the data from the accounting interface
© Copyright SAP AG 2010
Internal
107
3 SAP ERP Financials
SAP ERP
(see chapter 3.2) or manually (see figure 3-6). The FI document is used to update the general ledger and the sub-ledgers. General ledger is the collection of all the postings in the financial system used and gives the complete view of the accounts and balances necessary for reporting. Sub-ledgers hold the transaction data of the customers, vendors, tax, assets, cash journal, and so on. This data is updated in parallel to the general ledger into an account category called reconciliation account. The sub-ledgers provide detailed information of the assigned GL reconciliation accounts.
3.3.1 The Financial Document Each FI document stores data for financial accounting. It consists of a header and line items. The header describes the business transaction context such as document number, document type, fiscal year, and company code. One line item describes for one specific account the amount, debit or credit indicators, and tax code. For example, if the business transaction is tax relevant, then the FI document includes tax items for tax reporting. The items created vary depending on the business transactions. Some of the possible cases 8 are tax items, one-time customer or vendor items, bill of exchange items etc. In such 9 cases separate tables are updated in parallel. 10
Different types of financial documents are identified by different document types , for example: SA – G/L account posting KR – Vendor invoice DR – Customer invoice KZ – Vendor payment DZ – Customer payment ZP – Payment document An example of an FI document created from a vendor invoice received from user entry looks as follows:
8
More information on Bill of exchange could be obtained from help portal http://help.sap.com/erp2005_ehp_04/helpdata/EN/01/a9c9d0455711d182b40000e829fbfe/frameset.htm 9 There are separate tables for tax (BSET), one-time customer / vendor (BSEC), bill of exchange (BSED), in addition to normal FI header (BKPF), item (BSEG) tables and separate table groups for NewGL. 10 Document types are customizable by the customer and not necessarily have the same meaning as described above in all cases. An FI document type is identified by a two letter code which is delivered in SAP standard. Customers are free to add their own document types. Each document type is also assigned to a particular number range for easier identification. 108
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
Header: Document Number
Company Code
Fiscal Year
Document Type
Currency
Posting Date
1900000001
1000
2010
KR – Vendor Invoice
EUR
01.01.2010
Line Items: G/L Account
Description
Account
Amount
Debit/Credit
Tax Code
160000
Vendor , Berlin
Vendor1
1000,00
Credit
V1
204000
Expenses Account
862,07
Debit
V1
154000
Input Tax
137,93
Debit
V1
Each line item of an FI document is assigned to general ledger accounts and in addition to a sub-ledger assignment such as Customer or Vendor, if relevant. In this example, the “vendor, Berlin” (with vendor account Vendor1) line item belongs to the accounts payables sub-ledger. Depending on the account type of the item, the line item(s) will record them in their respective sub-ledgers, that is for example accounts payables or accounts receivables. Same is true for the case of asset sub-ledger. The above is the case where the postings happen within a company code. If the FI transaction is across company codes, then the postings are recorded as cross-company code FI documents. These are multiple documents, created per company code. The financial document can have different nature based on the business transaction, for example Normal postings such as invoices, payments, or account transfers, Recurring entries such as periodic rent, or premium payments, Sample documents which are used as template documents, or Cross company code documents which record transactions between company codes FI documents can be created manually or are posted via the financial interface (see figure 3-6).
3.3.2 Financial Interface When receiving a business document, the accounting interface determines the receiving SAP ERP FIN applications. In case a business document should be transferred to financial accounting, the accounting interface modules (check, close, split project, post) call the corresponding modules of the financial interface (FI interface). These modules include mappings and check logic specific for financial accounting. Finally, the post module calls FI update routines to create an FI document (see figure 3-7). The information provided by the application that calls the FI interface is enriched further by the accounting interface. For example the business transactions at SAP ERP MM, which involve the movement of goods, have their own representation: SAP ERP MM categorizes transactions by using so-called movement-type and origin of transactions. © Copyright SAP AG 2010
Internal
109
3 SAP ERP Financials
SAP ERP
During account determination, SAP ERP MM uses this information together with the valuation class, the grouping code, and the FI chart of accounts to identify the relevant accounts of financial accounting. Figure 3-7 depicts the creation of an FI document via the FI interface as well as manually by a user. In both ways the FI common routines are used to check the incoming data, for example whether the fiscal period of the FI document is valid with respect to the current customizing settings. Otherwise an error is raised. External Application (such as SD,MM,HCM..)
Account Determination R
R
Create
Check Document Creation
Close
Post
Split
Project
R
Post Interface
Create Interface Accounting Interface R
R
R
R
R
R
R
FI Common Routines
Manually
R
Check Modules
Close Modules
Via Interface
Split Modules
Project Modules
Post Modules
FI Interface
FI Documents (Buffer)
R
Update Routines
Financial Documents Financial Accounting ERP FIN
Figure 3-7
Financial Interface
The update routines are the common routines which store the FI document into the database tables permanently. The update routines are also responsible for locking the data when a document is updated.
3.3.3 FI Document Posting When an FI document is posted, the following sequence of processing steps is performed: Validation of header data Validation of line items Actual posting of the document 110
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting 11
Customizing & Current Settings
In case of manual posting, for each of these steps a separate ABAP Dynpro screen is displayed to the user. When financial data is posted via the FI interface, the same validation, simulation and posting functions are called by create, project, split, close, and post modules. Displaying the simulated document is optional, but the steps in simulation are also performed even if the document simulation is not triggered by the user manually.
Org Data Verification
Document Type Identfication
Customer Info Processing
Vendor Info Processing
Tax Supplem. Items Creation
Exchange Difference Lines Creation
Validation & Substitution at Header level
Posting Date Check
Validation & Substitution at Line Item Level
GL Info Processing
Cash Discount/ Deduction Lines Creation
Comp‟y Code Clearing Line Items Creation
Clearing Line Items Creation
Validation & Substitution at Document level
Authorization Check
Exchange Rate Processing
A/C Specific Checks
Header Data Processing
Authorization Check
Line Item Data Processing Document Processing
FI Document (Buffer)
Header
Line Items
FI Posting Simulation R
Document Number Range
Barcode
Document Number assignment
Update MM Commitment Process
Validation & Substitution at Docum. Level
Document Creation /Update
Update Lines and Totals
G/L Update
Trigger BarCode Linkage
Second. Info Upd.
Trigger WorkFlow
Create Accounting Documents
Database Update
Sub-Ledger Update
Update Routines
FI Documents
P&L Accounts
Balance Sheet / Asset Accounts
Customers (Accounts Receivables)
General Ledger Data
Figure 3-8
Vendors (Accounts Payables)
Assets
Sub-Ledger Data
FI Posting (Classic)
3.3.3.1 Processing of Header Data Validation of header data compares the incoming header attributes company code, currency of the transaction, fiscal year, and document type with the customizing settings. The header can also include the exchange rate to translate the given currency into the 12 currency of the company code which is also known as local or home currency .
11
In case of „Enjoy‟ transactions, the number of screens is reduced, and often have only one screen for most of the data entry part. 12 Local / Home currency is the currency of the company code in which the legal reporting is done. If the transaction currency is different from the home currency, transactions done in FI are always translated into home currency. There are two more currencies allowed which are known as second © Copyright SAP AG 2010
Internal
111
3 SAP ERP Financials
SAP ERP
In addition, specific validation conditions are checked, for example when a particular document type should be restricted to particular type of transactions as per business needs. Posting date is checked against the periods that are open for posting. If the posting period is not open, then an error message is displayed. The appropriate exchange rate is looked up from the exchange rate customizing tables (if this was not entered manually). With this it is possible to process foreign currency business transactions and cases where the parallel currency differs from the reporting local currency. Authorization checks ensure that the user or system is allowed to post the FI document.
3.3.3.2 Processing of Line Items Line items contain the details of the business transaction such as account, amount, tax code, or posting key. The posting key is a two digit number where customizing settings define which posting key relates to what type of account the line item should be booked for, for example customer account, vendor account, general ledger account, whether the line item is debit or credit (see appendix 5.2.5), and the field status of the additional data entered in the line item and its options (optional, suppressed, required entry). For example payment terms, business area, or cost center are allowed to be entered or suppressed for entry based on the field status. Posting key account type (customer / vendor / G/L) could also be restricted via field status. The posting key controls how an individual item is processed by financial accounting. Depending on the posting key, the account input is checked (for example only customer account is allowed for posting key 01). Some of the important fields are the amount field(s), tax fields, account assignment fields such as business area, profit center, functional area, cost center, payment terms (for vendor and customer accounts), or free text for the line item. Customer, vendor, and G/L account information is looked up and checked for existence, validity, and user‟s authorization to post against a particular account. Customer, vendor and G/L master data is looked up for entry of the data in the line items against them. Such data could be payment methods of a vendor which define what types of payment are allowed (e.g. check, direct debit). Validations and substitutions are also possible at the line item level to give more control to the customer-specific needs such as to allow posting to a special vendor for a particular user only.
local currency (group currency) and third local currency. Group currency is used for consolidation at the company level, and third local currency is customizable to suit specific needs such as hard currency. Hard currency is used as stable and reference currency in countries where the currency fluctuation of the local currency is too high. 112
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
3.3.3.3 Posting of the FI Document During posting, all necessary steps are performed to create a complete FI document. The 13 posting steps are Create tax items based on the tax code entered at the line item level; Create exchange rate difference lines. Exchange rate difference line items are generated automatically to compensate the differences that could occur during translation of the amounts from the transaction currency to other currencies or from local currency to the rest of the currency amounts depending on the customizing; Create cash discount lines, for example based on payment terms. A defined percentage of cash discount can be given based on the customizing settings; Create cross-company clearing line items (in case of posting between two or more different company codes) to balance the document company code, since it is required that the document balances to zero when totaling the amounts per company code per transaction currency and per local currency (all three local currencies). When the actual update of the database tables happens, the following important steps are performed (see figure 3-6): A document number is assigned by fetching it from the number range available, The MM commitment item is updated, parallel actions such as barcode linking14 or workflow are triggered, Create other accounting documents such as Controlling, Profit Center Accounting, and Profitability Analysis, depending on the account assignments such as cost center, profit center, or profitability segment respectively, and Update the lines and totals in the respective ledgers (General Ledger and subledgers). During the above steps of document creation, the accounting interface (see chapter 3.2) is also called to check whether other SAP ERP FIN applications need to be informed about the posting of the FI document.
3.3.4 New General Ledger Accounting From ECC 5.0 onwards, SAP has delivered the New General Ledger (NewGL) within financial accounting which enhances the existing implementation in order to support the following use cases:
13
All or some of the steps can be relevant for posting a document. For example, clearing postings can have steps to create clearing lines, which will not be necessary for postings without any clearing or payment with clearing etc. 14 A barcode can be entered during the posting of FI documents which represents for example a barcode of an invoice. A barcode can be generated, entered , and linked to a scanned copy. This is relevant when optical archiving is active. For more details refer to SAP Note 832548 © Copyright SAP AG 2010
Internal
113
3 SAP ERP Financials
SAP ERP
R
User Interface Simulate / Post
R
Document Processing (Classic)
R
FI Posting/Simulation R
FI Document (Buffer)
Document Number (NewGL)
Split Information
FI Documents
Post Document Number (Classic)
Enter Header And Line Items
Classic Posting / Update Routines (Classic) FI Documents NewGL Simulate (NewGL) R
NewGL Update Routines
Split Processor
R
Post (NewGL)
R
Post (Classic)
R
NewGL Simulation NewGL
Balancesheet P&L Accounts Accounts
P&L Accounts
FI Documents
Balancesheet Accounts
General Ledger Data
General Ledger Data
Ledger
Customers (Accounts Receivables)
Split Information
Vendors (Accounts Payables)
Assets
Sub-Ledger Data
NewGL
Classic General Ledger
FI Document Posting with NewGL
Figure 3-9
FI Posting (NewGL)
Manage parallel accounting standards. In the classical general ledger, a company could only have one ledger. Therefore, parallel accounting had to be realized using special ledger or using parallel accounts. NewGL enables a company to report the ledger and sub-ledgers with multiple accounting standards such as IFRS or local GAAP. NewGL provides standard ledgers and groups of ledgers which allow posting to different ledgers simultaneously. Each of these ledgers can be assigned to a different accounting standard. Segment Reporting. In the classical general ledger there was only the Business Area field for reporting, or the reporting using dedicated applications (Profit Center Accounting or Special Ledger) in order to obtain a segment reporting.
114
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
NewGL is based on the architecture of Special Ledger (see 3.3.11). Thus, NewGL is able to use flexible structures in totals and line item tables which allow adding 30 additional customer fields and additional SAP fixed fields. One of the standard additional account assignment fields is the field “SEGMENT”, which can be used for segment reporting. Based on the customer‟s requirements, any other adequate field (for example profit center field or a customer defined field) can be used for segment reporting as well. Perform a fast period end closing. In classic G/L, the level of detail available in the totals table is limited to business area and company code. Hence, to get a detailed reporting, the closing had to be done iteratively to distribute this available information into different levels such as profit center or segment. Due to the flexible structures of NewGL, all relevant account assignments, such as profit center, are included in one totals table. Therefore, redundancy is minimized and reconciliation with other ledgers and applications is in most cases not necessary any more. The real-time integration between CO and FI transfers the documents from CO to FI instantly. In classical FI, a period end job has to be scheduled to provide this information. Document Splitting. The document split processor splits the documents online based on defined rules and processes. For example, within an invoice the vendor line is split based on the expense lines (rule based) and the clearing document is split based on the invoice (process based). The document splitter creates split information and split document lines parallel to the entry view. In classical G/L, a document split had to be achieved by batch reports for balance sheet and P&L (Profit and Loss) adjustment in a period end closing process. The document split is relevant for management reporting and to fulfill the requirements of accounting principles.
3.3.5 FI Document Processing with NewGL To illustrate the processing of an FI document within NewGL we use as example the report of financial statements per profit center. Let‟s assume the line items of the FI document look as follows (which is known as entry view): G/L Account
Description
Account
Amount
Profit Center
160000
Vendor, Berlin
Vendor1
1000,00 EUR Credit
204000
Expense 1
800,00 EUR Debit
PC1
204000
Expense 1
200,00 EUR Debit
PC2
The above lines are part of a vendor invoice. When the accountant entered this invoice in the system, he split the expense of this invoice into two profit centers PC1 and PC2 for the same expense account 204000. This is the business process within a company where the expense is posted to respective organizational units to which they belong. In this case the total invoice amount is 1000 EUR. Now to make the actual assignment of the invoice amounts to their respective expense lines, the invoice amounts need to be split into two lines PC1 and PC2, exactly in the ratio of the expense lines. The resulting view is known as G/L view or general ledger view.
© Copyright SAP AG 2010
Internal
115
3 SAP ERP Financials
SAP ERP
G/L Account
Description
Account
Amount
Profit Center
160000
Vendor , Berlin
Vendor1
800,00 EUR Credit
PC1
160000
Vendor, Berlin
Vendor1
200,00 EUR Credit
PC2
204000
Expense 1
800,00 EUR Credit
PC1
204000
Expense 1
200,00 EUR Credit
PC2
This process of splitting lines based on well-defined rules is called document splitting. With this it is possible to determine the exact amount of invoice amount (in this case) resulting in expenses for different dimensions, in this case profit center. With classic G/L, you would have to do this with a separate profit center accounting ledger. With NewGL, there is a separate set of line items and totals created as per customizing. Hence during simulation the line item to be created in the G/L view is also simulated apart from the classic or the entry view. The data from the entry view and online data (data transferred to accounting interface) from other application via the accounting interface is obtained to simulate the G/L view lines. These lines undergo a splitting process with the split processor called during simulation (and posting). The split processor takes the information from the entry view (or data from FI interface for postings from other sources like MM Invoice, SD Invoice etc) and generates the split line items according to the split rule and business transaction mapping that was customized. How the document split should be done depends on the customizing. The split information is also stored in database tables per document for use in future subsequent processes such as payment and clearing. The documents in G/L view can have a different number range and hence a new document number is fetched from the number range (of G/L view) and is assigned. The G/L view update happens in parallel to the classic G/L update. Another important aspect of NewGL is the update of a document in different ledgers. It is possible to define multiple ledgers with different currencies, fiscal years, customizing etc. which are then updated separately per ledger by a single posting of a financial transaction.
3.3.6 Sub-Ledger Processing A sub-ledger in financial accounting is set up for processing a large number of postings. In particular, business transactions involving receivables and payables are continuously updated to the sub-ledger and updated to the general ledger in an aggregated form. Hence the sub-ledger provides a detailed view and processing capabilities for receivables and payables which are updated to general ledger in aggregated form. This is also true for assets and contract accounting.
116
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
3.3.6.1 Accounts Receivable The account receivable application component records and maintains all customerrelated business transactions such as invoices, credit memos, or down payments. These transactions could be either created manually within accounts receivable or they are transferred via the accounting interface from SD and SAP CRM. Open invoices, credit memos etc are collected in the accounts receivable until they are processed in the payment process. The customer payment can be documented in the system in the following ways: A user enters a payment document, An automatic payment program creates the payment document, Credit memos, or Via bank statement processing, etc. The process of creating a payment is the same as that of posting an FI document. The manual creation of a payment document is assigned to a special „transaction code‟. This has a customized user interface screen for capturing payment-related information, such as payment methods (for example check, direct bank debit). The payment program, bank statement processing, and some other transactions also clear the open items. The postings made in the accounts receivable module are also automatically recorded in the General Ledger, where the accounts related to receivables are updated. The respective account for posting is obtained based on the master data of the customer and type of the transaction. In the master data, each customer is assigned to a General Ledger account where the respective customer invoices, credit memo, and so on are recorded. In case the transaction is having a special significance or a legal requirement (where a separate item in the balance sheet is required) such as down-payment, this is recorded in other accounts which are maintained separately. These are identified as 15 special G/L transactions . To post such transactions, either special transaction codes (tcodes) are used, or special G/L indicators are maintained in the FI document posting transactions.
3.3.6.2 Dunning In case a customer does not pay an invoice until the due date, a company can start the dunning process which sends a dunning letter to the customer as a reminder for the payment(s) to be made. The subsidiary ledger accounts receivables integrate dunning 16 which consists of two functions (see figure 3-10): Batch job for checking open invoices and triggering the dunning process 15
Some more examples of the special G/L transactions are guarantees or security deposits. Refer to the SAP help at http://help.sap.com/erp2005_ehp_04/helpdata/EN/01/a9c698455711d182b40000e829fbfe/frameset.htm
for more details. 16
Dunning, normally a process for accounts receivables, could also be run for accounts payables for example in case of credit memos. © Copyright SAP AG 2010
Internal
117
3 SAP ERP Financials
SAP ERP
User interface for accessing the dunning history of an individual customer Customizing Administrator
Dunning Processor
R
Business Partner (Customer)
R
Customizing Interface
User Interface for Dunning Selection Parameters
R
R
Levels
Dunning Batch Job (incl. Interest Calculation)
Charges / Limits Dunning Customizing Customer/Vendor Master Data
Dunning Proposal
Procedure
R
Display Dunning History
Dunning Data Customer / Vendor Open Invoices / Credit Memos
Print
Dunning Letters
FI-AR Dunning
Figure 3-10 Dunning The dunning batch job can be started periodically. Dunning processing will check customizing and transaction data whether dunning should be done. When scheduling the dunning batch job, the range of customers and the date of dunning can be defined. The dunning batch job selects the customer and vendor documents (invoices and credit memos) for the given selection. Then it decides whether the item can be dunned based on due date, total amount of pending payments, open credit memos for the same business partner, and so on. The dunning proposal is created, which can be edited by the dunning processor, for example to exclude some invoices from dunning. Dunning calculates the interest on the due amount and creates the appropriate dunning letter. The dunning letter is printed and sent to the customer via e-mail, fax or by post. The dunning processor can access the dunning history of a customer and also display the individual dunning notes.
3.3.6.3 Accounts Payables The account payable application component records and maintains all vendor business transactions such as invoices, credit memos, payments, down payments etc. Accounts payable is closely integrated with the purchasing component in ERP Operations. Invoices can either be created directly within accounts payable, or they are transferred via the accounting interface from the invoice verification component of SAP ERP Operations.
118
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
The open received invoices, credit memos etc are recorded in accounts payable and are processed in the payment process. The company can document its payments by Creating the payment documents manually, Creating the payment documents by an automatic payment program, Automatic debit transactions, etc. Similar to accounts receivables as described above (3.3.6.1), a special „transaction code‟ is used in an FI document to support the user with customized user interfaces. The postings made in the accounts payable module are also automatically recorded in the General Ledger, where the accounts related to payables are updated. The respective account for posting is obtained based on the master data of the vendor and type of the transaction. In the master data, each vendor is assigned to a General Ledger account. This will be used for invoices, credit memos etc. In case the transaction is having a special significance or legal requirement (where a separate item in balance sheet is required), such as down-payment, this is recorded in other accounts which are maintained separately. These are identified as special G/L transactions. For posting such transactions, you could use special transaction codes (t-codes) assigned for them or by entering special G/L indicators in the FI document posting transactions.
3.3.6.4 Automatic Payment 17
Automatic payment processing is used to make payments to vendors and customers periodically. It is a batch job that can be scheduled to process a set of invoices, credit memos etc. which are due for payment. During automatic payment, clearing also takes place between invoices and payments. The clearing process is explained in the next section 3.3.7. As shown in figure 3-11, the user can enter the necessary selection parameters to select particular FI document lines for customers and vendors. This selection is passed on to payment proposal processing which generates the payment proposal which Contains a list of items selected for payment, Can be edited via the user interface, for example to change discount, payment method, bank instructions etc, and which Contains a list of items that have to be excluded from the selection due to any reason (for example no payment method found, or payment block set on item/master data of vendor / customer).
17
Automatic Payment Processing is also called Payment Program.
© Copyright SAP AG 2010
Internal
119
3 SAP ERP Financials
SAP ERP
R
User Interface for Automatic Payment R
Schedule Payment
Dislpay Payments
Automatic Payment Processing (started as Batch Job) R
R
R
Payment Enqueue Processing Customer / Vendor Invoices & Payments
Payment Proposal
Posting & Clearing Processing
Payment & Clearing
Customizing(Payment methods, bank details etc)
Create Payment Media
Payment Medium Creation Schedule Processing R
Level of Detail
Payment Proposal Processing (Create/Edit Proposal)
R
Sort & Grouping Process R
Customizing
Edit Proposal
R
Payment Data
Selection Variant
Payment Proposal
Customize
Schedule Proposal
Note to Payee Processing R
Payment Advice & Medium Creation
Payment Medium Workbench
Payment Medium (Check / e-File / Spool / ...) Payment Advice (Print / E-mail / Fax / ...)
Payment & Print Program
Figure 3-11 Automatic Payment This payment proposal data is passed on to payment processing when the scheduled payment is run. Payment enqueue processing ensures the unique payment processing of selected items. This is required to ensure that items are not processed simultaneously by different parallel payment processes. The selected items necessary for posting the FI documents and clearing are processed. The payment data, containing the list of payment 18 19 documents created along with the paid document item list is created. The payment data that is generated can directly be used to create a printout of the result, 20 or the user can run payment medium programs to create payment mediums (for example checks / e-files, etc). Payment data can also be displayed by the user. The creation of a payment medium can also be chosen during selection, when scheduling the payment program. Payment medium creation can also be achieved by the payment medium workbench (PMW). The PMW has functionalities of most former payment medium programs.
18
The Payment Document is an FI document that has line items which correspond to the amount that needs to be paid to customer / vendor. 19 The Paid Document is an FI document which contains items that were due for payment (open) and which are now paid / cleared by the payment document. 20 Payment Medium programs are chosen depending on the type of payment medium, type of format etc. These are now replaced by central PMW – Payment Medium Workbench. 120
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
Once the payment run has finished successfully, the payment medium workbench is triggered either by the user or by the payment program. The items that are to be sent in the medium are sorted and grouped based on the level of detail stored in customizing. A 21 note to payee is prepared depending on the customizing and this is passed on to the payment medium creation process. The payment medium creation process takes the necessary payment information and creates a payment medium, depending on the 22 selected type of payment medium, for example Data Medium Exchange (DME) . The payment program has allows customizing details of payment methods, banks to use etc. This is used by the payment program during the payment run.
3.3.6.5 Bank Statement Processing Bank statement processing provides the functionality to automatically import or manually enter bank statements. Other information sources (check deposit transactions, lockbox and account balances) are supported as well. Bank statements usually contain the following information: Header data: General information on the house bank account (bank and account number, account currency, statement number, statement date, and opening / closing balances). Line items: A list of individual business transactions that were posted to the account since the previous statement. Accordingly the information in bank statements might be relevant for several components in Financials, for example the cash receipt has to be posted (posting to a bank account in G/L, update in cash management), whereas clearing information is used to search for paid items (clearing in accounts receivables or accounts payables). The bank statement processing usually follows a sequence of steps: Upload of the bank statement file into the SAP bank data storage (enriched with SAPspecific information such as company code, house bank account ID, customer number of payer). Automatic analysis of the payment (including interpretation of notes to payee, search for paid items) resulting in clearing information for subsequent automatic subledger posting. Automatic posting: For a customer payment typically one document is posted for the cash receipt and a second document for clearing the debitor invoice (sub-ledger). Manual post processing of payments which could not be posted automatically, with the goal to find and clear the paid items manually.
21
Note to payee is a short note to the business partner (vendor / customer) containing additional information, such as Invoice number. 22 For more details refer to SAP Documentation: Data Medium Exchange Engine. http://help.sap.com/saphelp_erp60/helpdata/en/e0/443d38a4136168e10000009b38f8cf/frameset.htm © Copyright SAP AG 2010
Internal
121
3 SAP ERP Financials
SAP ERP
3.3.7 Clearing Clearing is a procedure by which open items (invoices, credit memos, payments, etc) belonging to one or more accounts are indicated as cleared or paid. Open items can be cleared when the sum total of credit amounts is equal to sum total of debit amounts. For example, a vendor invoice of credit 100 EUR can be cleared by a payment made to the vendor with amount debit 100 EUR.
R
User Interface R
R R
Select & Prepare Open Items
Handle Open Items Display
Activate discount etc
Selected Open Items (Temp)
Residual Items (Temp)
Clearing Items
Exchange Rate Differences
Differences
(Temp)
Postings Preparation
Deductions
Clearing Info
Document Header and Lines
(Temp)
Posting and Clearing Data Creation Process
Tax Lines
Document Posting Process
Open/Cleared Secondary Items
Line Items
Headers
Tax Items FI Documents
FI Posting with Clearing
Figure 3-12 Clearing The clearing process is triggered by the business user, either by interactive manual method or by invoking the automatic clearing process. In the interactive manual method, the user has more control, such as Further selection options (such as posting date of invoice or payment) for selection of items that need to be selected for clearing (more selective), Editing amount that needs to be paid / cleared, or
122
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
Editing cash discount items, residual items23, etc. As shown in figure 3-12, the user selects the open items from one or more accounts (G/L / Vendor / Customer) in one or more Companies. The selected open items are then passed on to further processing. Once the items are selected, the user can also activate or de-activate cash discount on them. He can also make partial payments out of the total amount that is due (sum total of amounts in all the open items selected). The selected items are then provided to Postings Preparation. In this step, the selected items are used to build the clearing items, exchange rate difference lines, differences lines (total balance of the clearing), and deductions in the invoice amount due to cash discount. This temporary information is provided to the posting and clearing data creation process which creates the necessary clearing information, document header and line items of the clearing document and tax lines. Clearing information contains the data that will be updated in the cleared and in clearing lines such as clearing document number, clearing date, clearing year, or clearing entry date. The document header and line items of the clearing document is a new FI document that is created to represent the clearing document. Tax lines are created if necessary. This information is finally given to the document posting process which updates the FI documents. This completes the clearing process. The clearing process can also be triggered by other processes such as automatic payment runs (see 3.3.6.4) which make payment for lots of invoices which are cleared automatically by calling the clearing process internally. There are also mass clearing transactions that can be run by a user in cases where a large number of open items have to be cleared. For example report SAPF124 could be used to mass-clear bank clearing accounts.
3.3.8 Tax Accounting Tax accounting records tax-relevant items from all FI documents for reporting and submission to the tax authorities of a particular country. Tax accounting is generally binding to a particular country where the company is located and reporting as per local accounting standards. Based on the legal requirements in a country, country specific tax percentages and customizing are maintained. Different types of tax could be applicable to business transactions based on the country specific requirements. Some of the types of taxes are Sales tax – tax applicable on sale of goods or services,
23
A residual item is created when you make a payment that is lesser than the due amount. The due amount line is cleared but another item (residual) with the remaining payment due is created. This is contained in the new document that is posted during this process. © Copyright SAP AG 2010
Internal
123
3 SAP ERP Financials
SAP ERP
Deferred tax – taxes recognized during the payment, or Withholding tax – tax with-held during payment is made on behalf of the payment receiver. Tax calculation is an integral part of the FI document posting process. There are three ways in which the tax amounts are posted. As part of the line items that are posted in an FI document, tax amounts are automatically calculated during the FI document posting, based on tax codes in the document. Represented with new lines in the FI document, tax amounts are automatically calculated by the tax accounting routines, based on tax codes in the document. The user enters tax amounts when posting the document. Figure 3-13 shows the different ways how tax amounts are posted. Accounting Interface Postings with Tax Relevant Lines R
R
Tax Customizing ( eg. Tax Jurisdict. Codes)
Tax accounts (G/L master data)
Interface for FI Document Posting R
R
Document Posting Routines R
Manual Entry of Tax Base / Tax Amounts
FI Document (Buffer)
Tax base amount derivation (Automatic)
R R
R
R
Get Tax amounts calucated from pricing / Calculate from Base amount
FI Tax Derivation
Tax Amounts / Lines (Buffer)
Line Items
Tax Lines
Condition Tables Sales and Distribution
FI Update Routines
Header
Calculate Tax Amounts (SD-Pricing)
Financial Document
FI Posting
Figure 3-13 Tax Accounting Within tax customizing, country-specific tax information such as tax jurisdiction codes, tax codes, tax percentages are defined.
124
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
The user interface allows entering the tax amounts directly in the line items. These tax amount values are directly transferred to the tax amount buffer, which is then passed to the FI update routines. This is then updated to the FI documents including tax tables. The information passed on from the user interface to the document posting routines call the tax derivation. Here the tax base amount is derived from the amount in each tax relevant line indicated by a tax code in the line. In case there are cash discounts and any other deductions in the amount to be taxed, these are considered and the tax base is recalculated. This information is then passed to the pricing interface to get the tax amounts calculated. This calculated information is based on the condition tables maintained in the SD Pricing module (see also section 2.4.3.3). The tax information is then passed to the FI update routines which update the tax information in the FI documents, containing the tax accounts, accordingly.
3.3.9 Periodic Processing Periods such as fiscal year, or accounting period play an important role in financials because certain financial reports must be published, or certain payments must be made at certain points in time. So in financial accounting several processes need to be carried out on a periodic basis to be able to reconcile, plan, and report the current financial figures to company‟s stakeholders. Examples for periodic processes are Period end Interest calculation for the open items such as vendor and customer invoices, Period end automatic clearing process of linking process chains such as payment and invoice, Periodic posting of recurring entries such as interest on a loan per period, Archiving – to reduce the amount of data in the main server, a defined set of data is moved to other storage systems; The processes in closing include foreign currency valuation, intercompany reconciliation, roll-up of ledgers, allocation, reclassification, carry forward of account balances to the new fiscal year, and generation of financial statements for reporting purposes. The following sections will explain foreign currency valuation and intercompany reconciliation in more detail. Foreign currency valuation is one of the most critical processes in closing and is used by all customers who use foreign currencies for business. Intra-company reconciliation, though rarely used, is an important part of enterprise consolidation.
3.3.9.1 Foreign Currency Valuation Foreign currency valuation is a component in financial accounting which valuates the foreign currency transaction balances of the G/L accounts and the customer / vendor
© Copyright SAP AG 2010
Internal
125
3 SAP ERP Financials
SAP ERP
open items. This is necessary to have a current value at a key date (usually last date in a st period / year such as 31 Dec) to reflect the same in the balance sheet. Foreign currency valuation is carried out as a periodic process before the financial reporting is performed for a company.
R
User Interface for Foreign Currency Valuation
Valuation Areas
Foreign Currency Items Selection Processing R
Exchange Rates Exchange Rate Differences Gain/ Loss Accounts
Valuation Processing
R
R
Error Cases
R
Batch Input Processor
FI Posting Routines R R
Update Routines
Foreign Currency Valuation
G/L Account Balances G/L Open Items AP/AR Open Items
Check/Resolve Errors
Postings Creation Process
Balance Sheet Adjustment Account Customizing
Start Postings
Re-Posting Batch
Valuation Method
Schedule FC Valuation
Valuation Data
R
Valuation Documents FI Documents
Financial Accounting
Figure 3-14 Foreign Currency Valuation Foreign currency valuation needs the following input: Valuation method which defines the valuation procedure, for example lowest value 24 principle , Valuation area which assigns company codes to valuation method and currencies, Exchange rates which are updated manually or from external sources via online update or file upload, Exchange rate difference accounts which defines the G/L account to which the exchange rate differences must be posted to, and Balance sheet adjustment account which defines the G/L account to which the balance sheet adjustment amounts occurring due to valuation have to be posted.
24
The lowest value principle is one of the types of valuation which valuates, for example, customer invoices in a foreign currency. In case the exchange rate differs between document date and valuation key date (for example period end), the lower value is taken. The opposite is true when a vendor invoice is involved. 126
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
Foreign currency valuation is one of the processes in closing, and this can be scheduled as a batch job. This could also be monitored via the closing cockpit. As shown in figure 3-14, the user interface allows scheduling foreign currency valuation. The user starts with selecting items for valuation depending on the key date entered in the selection. The G/L account balances and open items from G/L account, accounts receivables and account payables are selected, and valuation of all these are done based on the valuation method to evaluate the value of the amounts posted in foreign currencies. For this purpose, exchange rates are picked based on the key date. This valuation data may be updated in the documents or in account balances depending on the kind of valuation. As next step, new FI documents are created based on the new currency exchange rates by initiating the posting. This creates new FI documents which post the valuation data into the respective G/L accounts specified by customizing. In case an error occurs during posting (for example due to missing customizing or posting checks), a batch input session is created which has to be checked by the administrator who then asks the business user to resolve the errors and re-post these documents via the batch input interface.
3.3.9.2 Intercompany Reconciliation Consolidation of corporate results is performed at the level of legal entities represented by the SAP entity company. Part of the consolidation process is the elimination of intercompany payables and receivables as well as intercompany profit or loss in transferred inventory. If the companies within the corporate group report different balances regarding the same business relationships, these differences have to be eliminated which in turn decreases the corporate group result. Reasons for differences are typically missing postings or posting errors. For example company A sells some products to company B. Company A sends a receivables invoice for EUR 100 to company B, but the accountant at company B posts the corresponding payables invoice as USD 100. Also it is possible that company B may not have received the invoice at all and therefore did not post a corresponding document. Intercompany reconciliation (ICR) is an application which assists the accounting department in determining the accounting documents causing such differences before the companies report their data to consolidation. ICR consists of three parts (see figure 3-15): Data Selection Processing, Automatic Assignment of FI documents to business transactions, and Interactive Reconciliation.
© Copyright SAP AG 2010
Internal
127
3 SAP ERP Financials
SAP ERP
Email
R
Fax
Trigger correction posting R R
User Interface for Intercompany Reconciliation R
Posting
Data Enrichment (BAdI)
Get FI Docs R
Data Selection
Remote Import
SAP ERP FIN System n
Posting
Exporter
Financial Documents
Exported Financial Documents (Files)
Data Selection Processing
R
Interactive Reconciliation
Data R Analysis and Manual Trigger Assignment correction Posting
Assignment Rules
File Upload
Local Import
Automatic Assignment
Automatic Assignment
RFC
Financial Documents
R
Request Communicator
R
ICR Database R
Data Enrichment (BADI)
non-SAP FIN System Customizing Settings
Financial Documents
SAP ERP Fin Central System
Figure 3-15 InterCompany Reconciliation Depending on the requirements, ICR can be part of the period, quarter or year end closing process. The data selection processing step of ICR is usually scheduled as a batch job. First the data to be processed (see figure 3-15) is selected. The data sources are financial transactions from all the SAP ERP FIN systems operated within the group company, imported using RFC, and also from non-SAP financial systems, imported via file upload. The imported data is stored in the central SAP ERP FIN database. FI documents stored in the central SAP ERP FIN database can be enriched with additional information that is helpful during reconciliation (via BAdI). The selected data is then passed to automatic assignment (matching) which assigns the selected FI documents to business transactions using a defined set of assignment rules. For example, the FI documents include reference data that can be used to assign the documents to specific business transactions. The data is then presented to the user for interactive reconciliation focusing on the documents which are most likely causing existing differences. In case correction documents have to be posted, the user triggers this posting by informing the respective other users via already customized / defined email communication or by calling them by telephone. Once the other users receive the information of the correction postings, they can post these correction documents in their respective financial systems.
128
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
Once the intercompany reconciliation is processed completely, only minor or no differences among the companies will be reported to consolidation.
3.3.10 Asset Accounting Asset accounting records the values of the fixed assets owned by organization. Asset Accounting is a sub-ledger of the general ledger. Asset accounting allows management of assets from the creation or purchase of a new asset to its retirements. The life cycle of an asset has different stages: 1. Creation or purchase of an asset; 2. Transferring an asset completely or partially into another asset, known as transfer posting (but this is not necessarily happening for all assets); 3. Maintenance of assets which could incur costs; 4. Depreciation of the value of the asset (explained below); 5. Retirement of an asset (selling or scrapping of an asset): The productive usage of the asset is complete, and it will not add any value on further usage, or it would result into higher maintenance. A scrap value may be calculated and sold.
R
User Interface Asset Under Construction Capitalization Process (Investment Management)
R
R
R
R
Create/Change Asset
Depreciation Posting
Post Asset Acquisition
Periodic Posting to FI
Post Manual Depreciation
Balance Carry Forward
Retirement / Scraping of asset
Fiscal Year Closing
Asset Maintenance & Manual Posting
Periodic Processes
R
Profit Center Accounting
R
Accounting Interface
R
Cost Accounting (CO)
Goods Receipt Process
Asset Posting
R
Financial Accounting
R
Asset Documents & Asset Transactions Asset Master (Asset, Depreciation Area, Asset Class etc.)
Goods Receipts
ERP FIN Database
Asset Accounting
ERP OPS
Figure 3-16 Asset Accounting
© Copyright SAP AG 2010
Internal
129
3 SAP ERP Financials
SAP ERP
During this life cycle, an asset can be depreciated, that is, the value of the asset will be reduced over a period of time (as per defined customizing, conforming to the legal requirements). For example the value of a car, bought in 2010 for 20000 EUR, will be 16000 EUR in 2011 with depreciation at the value of 20% per year. This reduction of the value of the asset is posted as depreciation. This ensures that the value of the asset is equally distributed over the years of its usage, rather than only in the first year when it was created or purchased. Asset accounting consists of three parts (see figure 3-16): Asset posting triggered from accounting interface or directly from investment management, Asset maintenance and manual posting which provides the transactions available on the assets, and Periodic processing which includes batch jobs to be scheduled at period ends. Asset accounting in SAP ERP FIN receives the asset postings from Financial accounting postings containing asset lines (identified by the link to the asset accounts) via the accounting interface, Asset relevant settlement postings from controlling (overhead management and product cost accounting, see 3.4.1) via the accounting interface, Goods receipts which have asset lines via the accounting interface, or Capitalization of asset under construction from the investment management. The SAP ERP FIN database stores master data for the assets, customizing for asset transactions, and asset transaction data. Asset master data provides attributes such as asset class (type of asset, such as building, machinery), company code to which an asset belongs, location or origin of the asset, and depreciation area according to which it will be depreciated. Asset accounting has a user interface that allows asset maintenance, manual posting, and periodic processing. In asset maintenance and manual posting, the user can create or change assets, updating the asset master data. When the user posts the acquisition of an asset, this actually creates a new asset. Furthermore, the user can post an unplanned depreciation if necessary. Usually depreciations are run periodically. Periodic processing (see 3.3.9) of asset accounting includes: Depreciation posting which posts the depreciated values of the assets to the respective asset accounts. This also posts the FI documents accordingly via the accounting interface; Periodic postings to financial accounting which contain the depreciation values for different GAAPs that may be active in the financial accounting. Balance carry forward which is similar to the posting that happens in the financial accounting. This is used for carry forward of balances during year end processing.
130
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
Fiscal year closing in asset accounting is carried out before the financial accounting fiscal year closing. This is normally carried out as a background job for performance reasons. This contains a series of steps such as posting the last regular depreciation, preparation of the asset accounting balance sheet, and running the year end closing report to get the complete set of outputs of the asset accounting transactions for the year. Adjustment postings can be posted if any differences arise during period end closing.
3.3.11 Special Purpose Ledger Special purpose ledger (SL) allows companies to create ledgers for customer-specific financial reporting. The company can define and customize the ledgers and their features, for example Whether the ledger will contain only totals or also line items, Whether there should be split of line items based on some criteria, such as profit center, Which business transactions should be the source information for this ledger, and Whether the ledger receives the planning data from Overhead Cost Controlling (COOM, see 3.4.1) or Profitability Analysis (CO-PA, see 3.4.2), or from an Excel sheet. Customizing defines a particular number range to be used for the SL documents. The ledgers are assigned to object tables, which contain mappings of various account assignments (for example profit center; business area) with a particular key. This key is 25 assigned to an object number which is used during update of the totals (summary) table. The ledger uses the object table to determine the key of the totals table. This is designed to allow more than 16 key fields in a table which is otherwise a restriction by the 26 database. This feature allows reporting based on these multiple account assignments.
25
Object number determines how the summary and line items are accessed via the object tables. Object tables contain the characteristics, such as account number, which is then linked to an object number. The object number(s) form the keys of the summary (totals) tables. 26 Reporting in SL (also in FI) depends on the number of key fields in the summary fields. Assuming you have only company code as the key field in the summary table, then you can only report at the level of company code. If you need more details, then you will have to add characteristic such as business area to the key field of the summary table, so that details per business area are updated and can be reported. In the database interface there is a restriction that you can have only 16 key fields. But this may not be sufficient if you need more than 16 characteristics fields. To be able to cater to such needs, the object tables use a special key which maps to a number of key fields, allowing defining more than 16 key fields. © Copyright SAP AG 2010
Internal
131
3 SAP ERP Financials
SAP ERP
SAP MM
SAP SD
SAP FI
MM Docs
SD Invoices
FI Docs
R
External DataSource
R
R
Subsequent Posting
Accounting Interface
Customize Ledger(s) Interface
Manual Posting Interface
Reporting
Interface data
R
R
R
R
Selection Processing (Ledger/Table Group processing) Substitutions and Validations
Customize Ledger(s)
Field Movement Currency Translation
Document Update
Document Number Range
Summary Records
Periodic Processes (Roll-Up, Allocation. etc)
Actual / Plan Lines Ledger 1
Object Tables
Ledgers Special Purpose Ledger ERP Fin
Figure 3-17 Special Purpose Ledger The postings from other applications such as SD, MM, financial accounting and 27 subsequent postings pass through the accounting interface and then are posted to SL ledgers (see figure 3-17). This goes through the following processing steps, Field movements which map the fields from the information source structures to the target fields, Substitutions and validations to enrich and validate data, and Document update which updates the lines items (if necessary) and totals accordingly. This also splits the line items (if customized) before update. There are further capabilities in SL such as Roll up to collect the total items from various ledgers into one ledger for consolidated reporting, Allocation to allocate various amounts from one source object to one target object (object can be an account assignment),
27
Normally postings into SL are configured to be posted along with the postings in MM, FI etc. But it is also possible to transfer the postings from these applications subsequently (later). 132
Internal
© Copyright SAP AG 2010
SAP ERP
3.3 Financial Accounting
Currency translation to translate amounts that were posting in the ledgers, Balance carry forward to carry forward account balances into the new fiscal year, or Manual planning to enter plan values manually into the ledgers. Reporting provides a report builder interface and displays information via report 28 29 writer and report painter . The special purpose ledger provides many features, in which are now also fulfilled by NewGL. Nevertheless, since special purpose ledger allows great flexibility to the user requirements, it was not replaced by NewGL.
28
Refer to report writer documentation http://help.sap.com/saphelp_470/helpdata/en/5b/d22db643c611d182b30000e829fbfe/frameset.htm 29 Refer to report painter documentation http://help.sap.com/saphelp_470/helpdata/en/66/bc7d2543c211d182b30000e829fbfe/content.htm © Copyright SAP AG 2010
Internal
133
3 SAP ERP Financials
SAP ERP
3.4 Management Accounting In contrast to financial accounting which records financial transactions for legal reporting, management accounting records financial transactions to support the company‟s managers in controlling resources and making decisions. In German, management accounting is also known as Controlling (CO). Controlling starts with assignment of cost objects such as order, WBS (Work Breakdown Structure), cost center, network, or activity to cost originating transactions (such as revenues and expenses of financial accounting, overheads) and collecting various costs from different cost objects. The costs collected on these are then further processed to reclassify them to appropriate categories.
Sales Order 1 Sales Order Item
Operating Concern 1
Project
Controlling Area
Account Assignments
Order
1
1
1
WBS
Cost Center
Network 1
Company Code
1
1
Activity Primary Total Assignments
Org Structure
Secondary Total
1
1
CO Line Item with Cost Elements Assigned
Figure 3-18 Cost Objects Relation The cost objects that are created, recorded and processed have relations to the organizational units as represented in figure 3-18. Each record created in the controlling module is related to the cost objects. This is done to be able to distribute the costs according to their cost originators and then report them. In the example of a sales order item, the cost related to the manufacturing of the goods which have been sold is collected in the cost object „sales order item‟.
134
Internal
© Copyright SAP AG 2010
SAP ERP
3.4 Management Accounting
3.4.1 Management Accounting
MM
CATS
SD
Invoice Receipt / Goods Receipts
PP
Sales Order /Invoice
R
ERP OperaProduction tions Order
Financial Accounting ( With NewGL)
Special Purpose Ledger
SL Documents
HCM
FI Documents
Management accounting, also known as Controlling (CO), has modules that facilitate internal accounting. Management accounting consists of the following components, as shown in figure 3-19:
R R
Accounting Interface R
CO Interface
R
Secondary Postings CO posting R
Cost Element Accounting
Settlements Assessment and Distribution
R
CO Transaction Data Lines/Summary
R
R
PS documents
Profit Center Accounting
Value Types
Controlling Database
Cost Object Controlling Settlements Actual Costing / Material Ledger
PCA documents
Product Cost Reporting
Product Cost Planning
Profitability Analysis
Project Systems
Overhead Cost Controlling
Cost Objects
R
PA documents
Settlement / Allocation Posting
Primary Postings
Overhead Cost Planning
R
Cost Center, Internal Order, Activity Based Costing
Overhead Cost Reporting
R
R
R
Consolidation
R
Product Cost Controlling
Controlling
CS documents
Enterprise contolling ERP Financials
Material Price
Figure 3-19 Management Accounting Cost element accounting classifies the cost and revenue objects into various objects types and value types and then stores them in the ERP FIN database.
© Copyright SAP AG 2010
Internal
135
3 SAP ERP Financials
SAP ERP
Overhead cost controlling manages the costs due to overhead processes in a company, and consists of the following sub-components: Overhead cost planning enables planning for the costs that could be incurred in the next periods. Cost center accounting enables managing the overhead costs to the management units where the costs were incurred. Internal order accounting manages the costs occurring due to internal activities. Activity-based costing manages the allocation of costs arising from business processes to overhead orders. Allocations assignment of the costs to the respective cost origins. This consists of the sub-processes Settlements for assignments of different orders(such as sales order, WBS, network), and Assessments and distributions which distribute the secondary and primary costs respectively to the receiving cost objects Overhead cost reporting. Product cost controlling: Product cost planning enables planning for the product-related costs that could be incurred in the next periods. Cost object controlling assigns the costs that incur during the production in company activities (such as goods produced) to the activities. Settlements of the costs from cost objects to receiving cost objects. Actual costing or the Material ledger provides the value of materials in multiple currencies (which is otherwise available only in one currency) and actual costing using valuation of the materials. Product cost reporting. Profitability analysis which helps analyzing the profitability of a market segment (see section 3.4.2 below). Enterprise controlling provides management accounting functionality for a group company or an enterprise which consists of multiple profit centers. It consists of the following modules: Profit center accounting (see section 3.4.3 below) measures profits with reference to a profit center on a periodic basis. For a profit center, it collects financial data and provides key figures such as return on investment, cash flow, and sales per employee. Consolidation aggregates financial statements of a group company as consolidated account. It provides statutory and internal management reporting for business areas and profit centers. In the following each of the components is explained in more detail.
136
Internal
© Copyright SAP AG 2010
SAP ERP
3.4 Management Accounting
3.4.2 Profitability Analysis An organization, which has multiple market segments defined, can use profitability analysis to measure the profitability of a market segment. This analysis can be drilled down in products, company codes, as well as customers. Figure 3-20 shows the architecture within the profitability analysis module (also known as CO-PA or PA).
MM/FI/CO/SD Bill ERP User
SD (Sales Order Processing) R
R R
CO-PC-OBJ Settlement Get PA Segment Characteristics Derivation
R
R
Accounting Interface
R
R
R
Account Assignment
CO-PA Interfaces for Posting
Reporting Tools
Characteristics Profitability Segments Value Fields
Valuation
Summarization Level
Line Items
COPA documents Totals
ERP Fin Database R
Get costs of Materials/ Goods
Costing Sheet Processing (SD)
Profitability Analysis
R
Product Cost Estimation (CO-PC)
SAP ERP
Figure 3-20 Profitability Analysis The role of the profitability analysis module begins at document entry in SD, MM, CO (settlement runs), or FI. Whenever a new document, such as sales order or purchase order, is entered into these modules, posting routines of these applications request for a profitability analysis (PA) segment to be populated in the document in their respective modules. This PA segment information is provided by the account assignment process, which gets the necessary information from the master data of the profitability segments and characteristics derivation within the profitability analysis. Once the PA document is saved with a filled profitability segment, the document information is passed to the profitability analysis by direct call from SD sales orders or via the accounting interface for documents from MM, FI, CO, or SD invoices. In the controlling module, product cost settlement settle the costs on a PA segment which will also create postings in CO-PA.
© Copyright SAP AG 2010
Internal
137
3 SAP ERP Financials
SAP ERP
The creation of documents in CO-PA creates line items and (updates) totals records in the transaction data. CO-PA has the provision of valuation, which values the incoming sales order items or 30 billing documents based on the amounts obtained from the costing sheet and product cost estimation in SD and CO respectively. This is then updated to the value fields within the CO-PA. Product cost estimation provides the costs of goods manufactured and services given. The value fields in combination with the profitability segments, summarization levels, and transaction data is then used for deeper analysis of the profitability of different market segments. The master data of the profitability analysis contains the following: Characteristics on which the reporting will be based, such as products and customers, Profitability segments which contain data such as market segments, Value fields such as gross sales, discounts (on what you would like to track / analyze) for fields such as revenue, sales deductions respectively, and Summarization level – levels of summarization and their criteria. Reporting is done based on the transaction data collected via the reporting tools in COPA.
3.4.3 Profit Center Accounting Profit center accounting (PCA) allows division of an organization into areas of responsibility for profits. It records revenues and certain balance sheet items to report the operating profit as well as key figures (like ROI) at the level of profit centers. The master data of profit center accounting defines profit centers and hierarchies. PCA receives invoices and deliveries from SD and material movements and invoice receipts from MM via the accounting interface which posts the data using the PCA posting interface. Financial accounting sends expense and revenue lines with filled profit center to PCA (see figure 3-21). The PCA relevant transactions are postings in these source applications which satisfy any of the conditions below: All items which contain a cost element (CO object) entered, Accounts maintained for postings to profit center accounting, Line items with P&L accounts containing a profit center, or Line items with P&L accounts such as goods receipts, goods issues, delivery, billing. In case these do not contain a profit center, they will be filled with dummy profit centers.
30
Refer further details on valuation in CO-PA using Pricing and conditions in SD: http://help.sap.com/saphelp_46c/helpdata/en/7a/4c39d84a0111d1894c0000e829fbbd/frameset.htm 138
Internal
© Copyright SAP AG 2010
SAP ERP
3.4 Management Accounting
Materials Management (MM)
Sales and Distribution (SD)
GR/IR
Invoices & Deliveries
ERP Operations
R
R
Vendor / Customer Lines
R
R
Settlements ; Allocations ; Transfer Prices
PCA Posting Interface Customizing (Fiscal Year; Controlling Area)
R
PCA Posting Profit Centers Customer/ Vendor Data Transfer
R
Closing (Balance Carry..)
Hierarchy Master data
Assessment Material Stock (MM) & WIP
Assets (FI-AA)
ERP Fin
Distribution
Asset / Material Stock Transfer & WIP transfer User Interface for PCA processes
Line Items
Totals
PCA Transaction Documents
Profit center / Hierarchy Updater
Expense/Revenue/ Balance Sheet Lines
Overhead Management , Product Costing , Actual Costing. (CO)
Accounting Interface
Reporting & Planning Tools
Financial Accounting
FI Interface
R
Enterprise Controlling - Profit Center Accounting (PCA)
Figure 3-21 Profit Center Accounting These transactions are posted to the PCA via the PCA posting interface which then calls PCA posting. PCA posting, updates the line items and the totals of the transactions PCA documents. Customer / vendor transfer transfers the customer and vendor open items (e.g. invoices, not yet paid) to PCA during period end processes. Asset / Material Stock transfer and Work in Process (WIP) build up the opening balance of the profit centers and they can also get the periodic transfers from MM, CO and FI-AA for the values of the material stock, WIP and assets respectively. Nevertheless, online (real time) transfer is recommended for these balance sheet items. Assessment and Distribution have the same functionality as in controlling, but in PCA, the assessment and distribution is done on profit centers. This can be triggered to get necessary correct profit center values by re-distribution based on organizational structure and needs. Closing in PCA typically consists of running assessments and distribution and then a balance carry forward to the next fiscal year. This should be done only after the source applications as FI, MM have completed their closing activities.
© Copyright SAP AG 2010
Internal
139
3 SAP ERP Financials
SAP ERP
The user has the reporting tools which give the detailed reports at the profit center level for all the transactions recorded in the PCA.
140
Internal
© Copyright SAP AG 2010
SAP ERP
3.5 Financial Supply Chain Management
3.5 Financial Supply Chain Management 3.5.1 Collections and Dispute Management Collections and dispute management is an application delivered in the software component financial basis. It supports follow-up processes triggered by the sub-ledger accounts receivables. Collections and dispute management can be installed and operated directly within a SAP ERP FIN system or with a two system scenario where the FSCM system (FINBASIS) is in a different box. In the second case, it communicates remotely (via RFC / iDoc) with SAP ERP FIN.
Collections Manager
Collections Specialist R
Dispute Processor
Biller Direct R
R
R
R
R
Display/Change Dispute UI For Dispute Management
FI – Biller Direct interface
Credit Management (Credit Rating) Business Partner Collection Strategy
Process Receivables
Worklist Generator
R
Read Process Worklist
Collection Worklist
R R
FI-AR Display/ Clearing Interface R R
Customer Contacts
(Create/Display/ Change Dispute Case Processing)
RFC R
Dispute Integration
Dispute Case Create (BAPI) Dispute Management
FI-Accounts Receivables Data (Invoices/ Payments)
Collection Items Resubmission
R
Interface to Access Cases
R
FI-AR Data Update Processing
Promise to Pay Dispute Case
Collections Management
FI-AR Data Transfer IDoc / RFC
FI Acccount Receivables (APPL Layer)
Fin Basis Layer
Dispute Case Case and Records Management
Fin Basis Layer
Figure 3-22 Collections and Dispute Management
3.5.1.1 Collections Management Collections management is an application of Financial Supply Chain Management (FSCM) which provides users a work list of receivables to be collected. Companies use collection management to collect outstanding receivables according to a prioritized list. Collections management is organized around the collection work list which contains the customer‟s overdue items which should be collected. When account receivables processes invoices and payments, it sends this data to collections management as an
© Copyright SAP AG 2010
Internal
141
3 SAP ERP Financials
SAP ERP
iDoc (see bottom of figure 3-22). Based on this data, collections management creates collection items. The batch job generate work list runs in regular time intervals, and selects collection items per customer and then prioritizes the list of customers according to the collection strategy. The collection strategy is defined by rules such as credit rating limit, invoice overdue for 1 month or more, or amount to be collected greater than 1000 EUR. The final list is stored as collection work list. To collect receivables, a collection specialist assesses the collection work list. The work list user interface displays the prioritized list of business partners to the specialist who is responsible for collecting the amount. The collection specialist works along his individual work list, calls the customer with the pending payment details, and updates the collection items based on the customer response. Based on the response, the collection specialist creates one of the following business documents: A resubmission of work list item till the next notified date, A promise to pay the due amount on a promised date, or A dispute case, requesting more clarification. To create a dispute case, collections management calls receivables processing which again calls the dispute update BAPI of dispute management.
3.5.1.2 Dispute Management Dispute management allows managing and tracking disputes with customers over receivables. Dispute management stores the information about a dispute in a so-called dispute case (see right-hand side of figure 3-22). To do so, it creates a dispute case using 31 the SAP records and case management which acts as repository to create, store, and maintain dispute cases. Dispute cases can be created in three different ways: directly from the dispute management user interface, from FI-AR using dispute integration BAPI, or from Biller Direct via the dispute case create BAPI. When a processor of a dispute case views the dispute, he can navigate to linked 32 objects . The linked object holds references to the corresponding financial accounting data such as customers, invoices, and cleared items. The dispute processor can create notes for the dispute case. He can access and change various dispute case attributes such as reason, escalation reason, status, and priority. The processor can add invoices and credit memos to the dispute case. Dispute cases can be created from customer line
31
Records and case management is a re-usable module in basis layer which allows registering, managing and processing records and documents easily. 32 Linked object functionality is part of the records and case management in basis layer, and stores the metadata which links the actual source of information in a repository. 142
Internal
© Copyright SAP AG 2010
SAP ERP
3.5 Financial Supply Chain Management
items display, customer document display / change functionality, and during clearing in financial accounting. Dispute management also supports correspondence to the customer by letter, email or fax. It is integrated with business workflow to be able to integrate with customer‟s own 33 workflows in an organization. Dispute management is integrated with collections management and Biller Direct in SAP ERP FIN. Dispute cases can be created from Accounts Receivable (FI-AR) using Dispute Integration. Changes in FI-AR disputed items are also reflected by an update in Dispute Management. This is done via IDoc in multiple-system scenarios and by direct BAPI calls in a single-system scenario.
3.5.2 Biller Direct Biller Direct is part of FSCM and provides functions for electronic invoice presentment and payment (EIPP). Companies can use Biller Direct to display bills, credits, payments, and the account balance to their customers online. Biller Direct allows customers to maintain their customer data, initiate payments, and create disputes. The bills can come from accounts receivables (FI-AR), SAP ERP SD, or SAP CRM. SAP Biller Direct is a J2EE application which is integrated with SAP ERP FIN using RFC and SAP Java Connector (JCO). The Biller Direct Web user interface can be provided stand-alone or integrated in SAP NetWeaver Portal. Biller direct is divided into the frontend application (Java) and the Biller Direct interface (ABAP) which provides the integration with accounts receivables (FI-AR) and dispute management (see figure 3-23) It supports the following services: Read and update customer data such as bank details, address. This gets the necessary information from the user and then updates the data in the master data in accounts receivables module. Read open customer invoices, credit memos, and paid bills from accounts receivables. Make customer payment by calling the accounting interface.
33
These workflows enable further processing of the dispute case at the customer side, such as checking the status of the dispute case and prompt the responsible person to take further action. © Copyright SAP AG 2010
Internal
143
3 SAP ERP Financials
SAP ERP
Biller Direct User
CRM User R
R
Web UI for BIller Direct
CRM Application
SD Application
Biller Direct Application
Customer Invoices SAP CRM
Customer Invoices SAP SD
Biller Direct Application (Java) JCo RFC
R
R
Partial Payment
FI User
R
R
R
R
Read / Update Customer Data
R
(Bank / CC / Check / Address)
FI Interface R
Read Customer Invoices/ Credit Memo/ Payments Read/Update FI Data Interfaces
Biller Direct Interface (ABAP)
R
Accounting Interface
Call Post FI Document
FI-AR Master Data / Transaction Data Read / Update modules
FI Document Creation
R
R
Dispute Integration (Create Dispute)
R
SD User
Dispute Management Interface (Create Dispute)
Dispute Cases
Dispute Management
Update Routines
User / Bank / Customer Invoices / Credit Card Data Credit Memo / Payments FI-AR Data
R
Payment Processing
Financial Accounting
ERP FIN
Figure 3-23 Biller Direct Typically, a Biller Direct user will browse the list of open invoices or credit memos assigned to the customer. Biller Direct allows the user to just pay the total, pay on invoice level, or make partial payments by a payment method of choice. On the application side, this information is then appropriately sent to the relevant backend interface which sets the 34 payment method on the invoice paid in the FI-AR. The clearing of this paid invoice happens in the FI-AR by automatic payment (see 3.3.6.4). A document with payment method set by the Biller Direct payment cannot be cleared by manual clearing transactions in FI-AR. In case the user opts to pay partially, then the backend calls the posting interfaces to create a partial payment document in accounts receivables (FI-AR) with a payment method set on it. The user can also opt to create a dispute during this process for this partially paid invoice, which will call the BAPI interface in the backend to create a dispute case (see 3.5.1.2).
34
Allowed Payment methods are set in customizing, such as Bank payment; Credit Card; Auto Debit Authorization. 144
Internal
© Copyright SAP AG 2010
SAP ERP
3.5 Financial Supply Chain Management
Payer Direct Payer Direct referred to as Biller Direct buy side is a portal application delivered along with Biller Direct. This application displays the open bills, payments and credits to their vendors that are to be processed in future and that are processed over a period of time. This application also provides an interface where a company can request their vendors to update invoices directly via the Enterprise Portal and Microsoft Excel files. This information is then processed and a corresponding FI document is posted to the SAP R/3 system. Similar to Biller Direct, Payer Direct also provides an option to maintain the vendor master details such as Address Data, Responsible Contact Person, Bank Details etc. via the portal.
3.5.3 Credit Management Often goods or services sold to customers are given on credit. To limit the risk of losing money, enterprises assess a customer‟s credit rating before selling on credit. This is managed by credit management. The central part of credit management, as shown in figure 3-24, is credit limit management and control which is integrated with the following components: Credit rules engine reads the external credit ratings (via XML interfaces) of the business partner (in this case customer) and re-calculates the rating based on a set of rules. The rating of the business partner is updated accordingly. This new rating is used for the calculation of the credit limit and is updated to the business partner credit account via credit limit management and control. Credit eventing creates follow-up activities such as workflows based on the events raised by credit limit management and control, for example to inform the credit information officer via email or SAP User Inbox. Credit decision support gets the necessary information about the credit data of business partners and credit usage information, and provides necessary data for factsheets, credit history, and worklist. This information is also used by the credit rules engine to determine the credit limit for the credit account of a business partner. When a customer-related transaction such as sales order is to be created, the application (SD / CRM) requests a credit check in credit management system via enterprise service or the XML interfaces (via PI). The credit limit management and control processes this request and sends back to the requesting application whether the credit could be granted or not based on the existing credit information of the business partner. In case the credit was not granted, a block is usually created on that particular business transaction (sales order in this case). In addition, an event can be triggered which also may start a workflow to ask the necessary persons for further actions.
© Copyright SAP AG 2010
Internal
145
3 SAP ERP Financials
SAP ERP
Workflow Initiator PI Interface
Application Triggers for Customer Transactions (FI/SD/CRM) BADI – PI message
R R
External Customer Ratings
Credit Rules Engine R
R
R
Credit Eventing
Credit Limit Update
Check Credit Information / Update Commitment
R
Portal
R
Get Credit information
R
Get Credit Information
Credit Limit Management and Control R
Get/Update Credit Limits
SAP Business Partner
Business Partner credit accounts
Credit Data / Usage
Credit Decision Support
Figure 3-24 Credit Management An update of credit exposure information is made to credit management, which updates the credit limit on the business partner (customer) by the credit limit management and control for this sales order when a delivery is posted, an invoice is created, the invoice is sent to financial accounting, or the payment is made by the customer for the invoice. In all the above cases, the exposure is updated, but with different types to identify the states of exposure made. There is also an interface to the portal which gets the information from the credit decision support to display the fact sheets (customer credit details) or credit history.
146
Internal
© Copyright SAP AG 2010
SAP ERP
3.6 Treasury
3.6 Treasury 3.6.1 Treasury and Risk Management: Treasury and risk management is part of Treasury Applications from SAP. It consists of the following components, as shown in figure 3-25:
R
User Interface R
BI
Reporting Tools R
Credit Risk Analyzer
Market Risk Analyzer
Portfolio Analyzer
InHouse Cash
R R
Position Management& Treasury Ledger
R
Transaction Management
R
R
Credit Rating
Cash Flows
Hedge Classic
Financial Accounting
Internal Postions Managment
Accounting Interface
Risk Management
Hedge Relationships
Transactions / Deals
Exposures R
R
Securities Account Management
Hedge FAM (with EHP4)
Hedging Relationships
Securities
R
Futures Account Management
Exposure Management
Futures
Exposures
R
Cash Managment ERP Fin
External Exposure Provider External Market Data Business Partner Information
External Positions Management Transaction Mangement
SWIFT Integration SWIFT File Transfer
Product Types Deals
Transaction Types Hedges
Condition Types
Analysis Results Database ( RDB)
Exposures
ERP Fin Database – Transactions and Master data
Treasury And Risk Management
Figure 3-25 Treasury and Risk Management Transaction management manages the operational flow of transactions for all financial instruments, covering everything from transaction origination to the conclusion of a transaction, to transaction processing including confirmation management for counterparties and payment processing, to position management and to accounting.
© Copyright SAP AG 2010
Internal
147
3 SAP ERP Financials
SAP ERP
Hedge management: Financial instruments are most used to safeguard against financial risks. This module is used to mitigate the risk of a particular risk position with a counteracting hedging transaction. Exposure management is a tool to support the process of collecting forex (Foreign Exchange) exposure information and to send the exposure to hedge management for hedging. It supports the decentralized collection and entry of existing and future forex exposures from planning processes. It also supports the version management of exposures, the exposure analysis with regard to internal hedging policies. Treasury includes three different analyzers: Market risk analyzer does analysis of market risks in financial positions. Changes in market prices represent important influencing factors for company success. Changes to market prices can influence the value, transaction value, or the timing of payment flows. Risks can be analyzed according to risk factors such as exchange rates, interest rates, stock price risk, index price risk or volatility. Credit risk analyzer enables the active control of default risks by computation of amounts and specifications of limits. Only counterparty risk is considered, that is, the risk of loss of value of a receivable due to the degradation of credit standing of the business partner. Portfolio analyzer groups tools for the calculation of yield and performance figures as well as for the comparison of those key values with benchmarks. It is designed to measure the success of investments from different custom defined perspectives independently from the transactional entities and using a variety of methods. The analyzers are the heart of Risk Management. The external market data are imported via file upload. Swift integration provides necessary communication to the banking systems for linking the transactions between treasury and external banks. Treasury is also integrated into Cash management. Cash management receives the transactions data of the treasury and updates the cash flows. Treasury can also be connected to an existing in-house cash application to allow carrying out financial transactions to external banks via central head office.
3.6.2 Cash and Liquidity Management 3.6.2.1 Cash Management The cash management module allows monitoring the cash flows and provides the necessary tools to ensure liquidity in an organization. Figure 3-26 shows how cash management works. The cash management receives data from ERP operations: the SD and MM invoices and purchase order details, Financial accounting: invoices, payment, bank statement information,
148
Internal
© Copyright SAP AG 2010
SAP ERP
3.6 Treasury
Treasury: Deals, hedging information, Industry specific solutions: loans, agency, real estate transactions information, and Bank statement processing in FI updates cash position. All the above information is updated to the cash management either via the cash management interface, by direct calls, or RFC in case the system is remote. The user interface also allows manual posting of cash-relevant transactions. The cash management interface and the manual postings update the necessary cash management line items and the summary tables from the posting process. Cash management can also be operated in a distributed scenario, where the information from other cash management systems is transferred to the central cash management system through the treasury workstation via ALE transfer. Cash concentration is the process of accumulating the available liquidity to a central bank account (which provides the best interest rates) from other bank accounts. This results in creation of payment advices and then payment orders to the banks for the transfer of the necessary funds in the payment processing.
Real Estate Transactions Industry Specific data
Sales Orders SD Invoices Purchase Orders
Agency Transactions Loan Data
R
MM Invoices User Interface
ERP Operations Data
Bank Statement Processing R
Customer/Vendor Invoices/Payments G/L Lines Financial Accounting
R
R
R
Manual Posting R
R
Posting Process
Bank Statements
Cash Management Interface
R
Bank Accounts Intermediate Accounts
Cash Position
Cash Concentration
Liquidity Forecast
R
Payment Processing (create payment advices ...)
R
Treasury Work Station ALE
Cash Forecast
Cash Management (Local)
R
Treasury Planning Levels Deals/Securities / Bonds Treasury
G/L / Customer / Vendor Account Groups
External System (FI / MM / SD ...)
Summaries
Line Items
Cash Management ( Central )
Figure 3-26 Cash Management Cash forecast has Cash position, providing a tool to get details of the up-to-date cash position of the company, and Liquidity forecast, providing a tool to get the liquidity forecast snapshot over a short period of time. © Copyright SAP AG 2010
Internal
149
3 SAP ERP Financials
SAP ERP
Based on the planning levels set up by the user and the cash forecast, the user gets the actual and planned information and can furthermore trigger necessary actions in other modules such as FI or Treasury to get enough liquidity in the company.
3.6.2.2 Liquidity Planner Liquidity Planner (LP) is used to generate cash flow statements in order to determine the liquidity of an organization. Cash flow statements provide information on the overall financial situation of an organization. Liquidity Planning Consultants
FI Consultants R
Banks
R
R
Bank Statements
Bank Statement Upload reports R
Actuals Reporting
BW Planning & Plan/Actual Reporting
Forecast Reporting
R
FI Interface
FI Document Creation R
FI Document Post
Reporting Programs
R
R
Liquidity Planner Actuals Interface Liquidity Item Assignment
Customer Invoices
Vendor Invoices
Customer/Vendor Payments
Forecast Data Collector Liquidity Item Assignment
Financial Accounting Cash Management Application
Liquidity item amounts before payment Forecast Data
MM Purchase Order Cash Management
Data Staging
Liquidity item amounts after payment
BW Extrac -tors
BW DataStore
Actuals Data
SD Sales Order
Cash Accounting
Liquidity Planning (BW)
Liquidity Planner
Figure 3-27 Liquidity Planner Cash flow statements are generated from three different activities: Operating, investing, or financing activities. Liquidity Planner consists of two applications: Cash accounting records cash-related transactions which includes incoming payments and outgoing payments. Cash accounting determines cash flow either based on electronic bank statement or by financial data. Liquidity Planning is done in business intelligence tools.
150
Internal
© Copyright SAP AG 2010
SAP ERP
3.6 Treasury
The liquidity calculation starts with actual data and determines the sources and uses of payments with a subsequent analysis. The customer and vendor payments occurring in FI-AR and FI-AP are transferred to 35 liquidity planner via the FI Interface to the LP actuals interface. The actuals interface captures the actual line, a line item containing the bank account, and assigns a dummy 36 liquidity item . This information is created in the liquidity planner actuals data. This information has to be enriched to get the source of the liquidity. For example a vendor payment is a post process that is performed based on vendor invoice(s). In this case the vendor invoice is the source of the liquidity and this information must be updated to the actuals data. For this purpose, a liquidity item assignment program is run on a regular interval (daily / weekly). Liquidity item assignment first reads the actuals data that was created by the actuals interface, then it traverses the document chain, i.e. it starts finding the origin of the payment, as follows: 1. It starts with payment documents and finds the vendor / customer information. 2. Temporarily assigns vendor / customer liquidity item (provided by the user in the user interface as buffer Item). 3. Starting with the buffer item, it finds the invoice and assigns the „real‟ liquidity item from the expense / revenue line in the invoice. The „real‟ liquidity item can be obtained by the customizing of the account, by using query sequence, or by selection screen exits where customer‟s code derives liquidity items based on the selections provided by the liquidity assignment program. The second method for liquidity item assignment is via the electronic bank statement 37 details according to defined rules . The forecast data collector reads the open items (vendor; customer and bank clearing accounts) and traces to the revenue or expense lines to get the liquidity item and assigns the same to open item amounts. This information is stored in the forecast tables. For forecast information from purchase orders and sales order, the information is read from cash management (if cash management is active), it is enriched with liquidity items (based on purchase order and sales order information), and finally stored in the liquidity planner forecast data. There are two types of reporting possible in liquidity planner. Actuals reporting reads the information from the actuals data based on the selection provided by the user and displays the liquidity information. 35
Actuals are those payment-related transactions which refer to „actual‟ money flow, as compared to the invoices which are only representing the liabilities on one side, 36 Liquidity items represent information accounts, such as expense or revenue accounts in FI. 37 One example for such a rule: “If the note to payee in a bank statement reads as „world tel‟ and the posting text says „debit memo‟, then the corresponding amount is to be documented in the liquidity item „telephone‟ ”. © Copyright SAP AG 2010
Internal
151
3 SAP ERP Financials
SAP ERP
Forecast reporting reads the information from the forecast data based on the selection provided by the user and displays the liquidity information. It is also possible to transfer both actuals and forecast data to the BW system via the BW extractor programs. This data then can be used for analytical reporting in the BW system.
3.6.3 In-House Cash Multi-national enterprises which are organized as group company typically have a wide network of international subsidiaries. Typically these subsidiaries have bank accounts in their respective countries. It is a complex and also costly task to manage the mass of internal and external payments of a group company using the various bank accounts of the subsidiaries and the headquarters, especially as international money transfer is still expensive. In-house cash module (IHC) helps optimizing the payment transactions within a group company by providing a virtual central bank to Reduce the number of external accounts to be maintained, Reduce the number of cross-border payment transactions, and Manage payments at global and regional levels. To illustrate the usage of IHC we assume that the group company has a set of 38 subsidiaries , each running an own financial accounting and having an own bank account (see figure 3-28). The group company itself operates a central SAP ERP FIN system with IHC. To act as a virtual bank, IHC maintains for each subsidiary a current account, where the subsidiary has its balances. In SAP ERP FIN each subsidiary is represented as a business partner. To explain how IHC works, we describe the four most important scenarios in the following.
3.6.3.1 Payments between Subsidiaries In this scenario, subsidiary 1 has to make a payment to subsidiary 2 as a result of a business transaction. For example, a vendor invoice is created in subsidiary 1 with the vendor being subsidiary 2. When the vendor invoice is cleared using the automatic payment program, a payment document is created and sent to IHC via iDoc (see figure 3-28). IHC creates a payment order based on this incoming iDoc. Now payment order processing updates the current accounts of IHC, which means IHC account of subsidiary 1 is debited and IHC account of subsidiary 2 is credited. This virtually signifies the transfer of money from subsidiary 1 to subsidiary 2. This is notified to the participating subsidiaries via the bank statement generated in the IHC center for each of these accounts during end of day processing. The bank statement is transferred to the subsidiary system via iDoc (Fin statement iDoc). In the subsidiary
38
Subsidiaries are units of an organization which operate independently and have a head office to which they report. 152
Internal
© Copyright SAP AG 2010
SAP ERP
3.6 Treasury
R
Financial Accounting
Initiate Payment iDoc
Idoc Processing
Process Event-Create Payment Order
R
R
Event
R
Bank Statement Upload Programs
R
RFC
Subsidiary 1
Bank Statement
system the bank statement is processed to clear the invoices or open item(s) in the respective accounts.
Bank Statement Upload Programs
Bank System 1
A/C Subsidiary 1
Payment Order Creation Bank Statements Payment Order
Bank System 2 For External Payments
Payment Order Processing
Subsidiary 2
Create
Payment Request
Update
Create
Current Accounts
Payment Processing
Subsidiary 1 Subsidiary 2
Financial Accounting
A/C Subsidiary 2
Bank System 3
Subsidiary 3
A/C Subsidiary 3
R
Subsidiary 3
Subsidiaries
Payment Media
Financial Accounting
End of Day Processing Fin Statement iDoc
In-House Cash ERP Fin
Financial Accounting External Banks
Figure 3-28 In-House Cash
3.6.3.2 Outgoing Payments of Subsidiary In this scenario subsidiary 1 has to make a payment to an external business partner as a result of a business transaction. For example a vendor invoice is created in the subsidiary 1. This vendor invoice is cleared using the automatic payment program. The payment document created by this process is sent to the IHC system using iDoc (Initiate payment iDoc). Based on this incoming iDoc, IHC creates a payment order. Payment order processing now debits the IHC account of subsidiary 1 and credits the clearing partner 39 account which represents the external business partner. To transfer money to the external business partner, IHC creates a payment request in the central SAP ERP FIN system. The payment request processing creates a payment medium file or direct transfer request via SWIFT to make actual transfer from the head office‟s central account to the external bank account of the business partner.
39
The Clearing Partner Account is a technical / temporary account used for offset posting in case of external payments or cross bank payments. © Copyright SAP AG 2010
Internal
153
3 SAP ERP Financials
SAP ERP
The IHC end of day processing again creates the necessary bank statement for the subsidiary involved in the payment. The bank statement is transferred to SAP ERP FIN system of subsidiary 1 via iDoc, where it is processed to clear the open item(s).
3.6.3.3 Central Incoming Payments In this scenario subsidiary 1 is a vendor who is supposed to receive a payment from an external business partner. In this case the business partner pays directly to the bank account of subsidiary 1. When the bank sends the bank statement to the head office to notify the payment, it is uploaded via bank upload programs and is processed by the IHC. During this process a payment order is created by IHC. When this payment order is processed, it updates the corresponding account of subsidiary 1. Subsidiary 1 is notified via the generated bank statement which is sent by the IHC using iDoc.
3.6.3.4 Local Payments In this scenario a payment is made by a subsidiary to an external business partner on behalf of another subsidiary using a local house bank. For example subsidiary 1 and the external business partner are in different countries. In such a case a payment made by subsidiary 1 to the business partner is a foreign transaction. However using IHC, the payment is routed via a local house bank of a subsidiary, which belongs to the same country of the external business partner. By this way the cross-border cost is avoided.
3.7 Outlook: Other topics of ERP Financials Not all important topics were covered in detail in the current version of the blue book, such as CO-PC (Product Costing), CO-OM Overhead costing, Biller Consolidator, Real Estate Management, Product Design Cost Estimate (PDCE), Contract Accounting (FI-CA), Enterprise Controlling, or Treasury – Bank Communication Management. To get more information about these topics, start with the official documentation (see chapter 3.8).
154
Internal
© Copyright SAP AG 2010
SAP ERP
3.8 ERP FIN Further Reading
3.8 ERP FIN Further Reading SAP Documentation: SAP ERP Central Component: Financials http://help.sap.com/saphelp_erp60_sp/helpdata/en/38/e34434c0df0c6ee10000009b38f83b/frameset.htm SAP Service Marketplace: SAP ERP Financials. http://service.sap.com/erp-financials Accounting Standards Board http://www.frc.org.uk/asb/ Naeem Arif and Sheikh Tauseef: SAP ERP Financials: Configuration and Design. SAP Press, April 2008 Eric Bauer and Jörg Siebert: New General Ledger in SAP ERP Financials. SAP Press, September 2007 Aylin Korkmaz: Financial Reporting with SAP. SAP Press, March 2008 Sartish Karthik R.: SAP ERP 6.0 (Operations). SAP Architecture Bluebook, Version 1.0, June 2008
3.9 ERP FIN Glossary Term
Definition
Balance Sheet
A financial statement showing assets and liabilities of an organization at a particular date, usually at the end of accounting period or fiscal year.
Chart of Accounts
List of accounts usually in a predefined order and sequence that will be used to record, manage and list financial transactions in a company.
Company
The smallest organizational unit of external accounting out of which legal individual financial statements, this can include one or more company codes.
Company Code
The smallest organizational unit of external accounting out of which legal individual financial statements like balance sheet and profit and loss statement created.
Controlling Area
Basic organizational unit in Management Accounting. It is a closed entity used for cost accounting like company code for financial accounting.
Cost Center
It is the organizational unit under a controlling area representing the location of cost incurrence.
General Ledger
A ledger (book/list of financial transactions) having nominal accounts (income and expense) and real accounts (cash, land etc.) which are necessary to represent a company‟s accounts.
Profit Center
Part of an organization where profits could be calculated based on the revenue and the costs associated.
© Copyright SAP AG 2010
Internal
155
3 SAP ERP Financials
156
SAP ERP
Internal
© Copyright SAP AG 2010
4 SAP ERP Human Capital Management Author: Sagar Joshi (Development HCM)
4 SAP ERP Human Capital Management
SAP ERP
Acknowledgement The following colleagues contributed in various ways to make this or previous editions of the document possible: Members of HCM Architecture Roundtable (DL HCM Architecture Round Table), Biraj Mandavilli and Vijaya Sarathi Durvasula (E-Recruiting), Ravi Murthy & Srikanth Chandru (EIC), Seshatalpasai Madala (Enterprise Learning, Talent Management parts), Richa Agarwal (ESOA), Puspen Chattopadhyay, Christian Behrens, Holger Bohle, and Andreas Kemmler.
Sagar Joshi
158
Internal
© Copyright SAP AG 2010
SAP ERP
4.1 Introduction to SAP ERP HCM
4.1 Introduction to SAP ERP HCM Human capital management is the strategic and coherent approach to the management of the people working for an organization. The goal of human capital management is to help an organization to meet strategic goals by attracting, and maintaining employees and also to manage them effectively. SAP ERP Human Capital Management (SAP ERP HCM) is the SAP application for human capital management and is part of SAP ERP, which is the SAP solution for enterprise resource planning (see figure 4-1). SAP NetWeaver BW (Business Warehouse)
SAP ERP Industry-Specific Functionality
SAP CRM (Customer Relationship Management) SAP SRM (Supplier Relationship Management) SAP SCM (Supply Chain Management)
HCM Service Delivery (ESS, ...)
Operations
Financials
HCM Extensions (E-recruiting, ...) HCM Core (Payroll, ...)
SAP GRC (Governance & Risk Compliance)
Corporate Services
Human Capital Management ( HCM)
SAP MII (Manufacturing Integration and Intelligence) SAP NetWeaver PI (Process Integration)
Figure 4-1
SAP ERP
4.1.1 Supported Business Processes SAP ERP HCM supports business processes under theme “Best People and Talent” in the following areas: Talent Management: Support people during every phase of their employment - from recruitment through training, development, and retention. Find the right people, put their talent to best use, align employee goals with corporate goals, maximize the impact of training, and retain top performers. Workforce Process Management: Streamline and integrate essential workforce processes such as employee administration, organizational management, time management, benefits, payroll, and legal reporting. SAP ERP HCM standardizes and consolidates all workforce-related processes and data onto a single platform, while ensuring adherence to country-specific regulations and laws.
© Copyright SAP AG 2010
Internal
159
4 SAP ERP Human Capital Management
SAP ERP
Workforce Deployment: Deploy the right people with the right skills to the right positions at the right time. Create project teams based on skills and availability, monitor progress on projects, track time, and analyze results for strategic decision making. SAP ERP HCM supports the assignment of workers to appropriate jobs, projects, and teams and the optimal scheduling of call center staff and retail staff. Further details about the HCM business processes can be found in [Bad07], [KLR04], and [KRY06].
4.1.2 Layers of HCM Applications Basically SAP ERP HCM is split into three layers of applications (see figure 4-2). The foundation is the HCM core applications which implement the core HR processes such as organizational management, personnel administration, payroll, personal development, and time management. They provide data and functions, which are reused by HCM extension applications to support additional processes like e-recruiting and enterprise learning. On top reside the HCM service delivery applications, which enable users to interact with the HCM applications via different channels and media, for example selfservices, employee interaction center and online forms. Organizational management provides the basis for organizational planning in other SAP Business Suite applications such as SAP CRM, SAP SRM as well as SAP Business Workflow. HCM core applications are the following: Personnel administration (PA) Personnel development (PD) Organizational management (OM) Personnel time management Payroll Appraisal, evaluation and survey engine (AES engine) HCM extension applications target a specific use case. A good example for an extension application is enterprise learning, which supports organizing classroom training, as well as producing and consuming e-learning content. They have their own business logic, but reuse functionality and data of the core applications, for example employee data or time recordings. E-recruiting which supports online job offering and online job application is an extension application, which can be installed on a separate server. Currently SAP HCM includes the following extension applications: Compensation management and personnel cost planning Enterprise learning Performance management Career and succession planning E-recruiting
160
Internal
© Copyright SAP AG 2010
SAP ERP
4.1 Introduction to SAP ERP HCM
There are additional HCM extension applications that are specific for certain regions and countries. Examples are benefits management, pension funds, and claims. These applications are not shown in the overview diagram.
R
Employee and Manager Self Services
Employee Interaction Center
HCM Forms and Processes
HCM Service Delivery Applications R
R
Compensation Management and Cost Planning
Enterprise Learning
Career and Succession Planning
Performance Management
E-Recruitment
HCM Extension Applications R
Payroll
R
R
Personnel Time Management R
AES Engine
R
Personnel Administration
R
R
Personnel Development R
Organizational Management HCM Core Applications SAP ERP HCM 6.0 Server
HCM Application Data
Figure 4-2
Architecture Overview SAP ERP HCM
HCM core as well as extension applications provide their own user interface. But there are additional output channels for delivering HCM services. These are self services offered via a Web browser, Web forms, or telephone and e-mail supported by the employee interaction center. Currently the following HCM service delivery applications exist: Self services for employees and managers (ESS, MSS)
© Copyright SAP AG 2010
Internal
161
4 SAP ERP Human Capital Management
SAP ERP
HCM processes and forms Employee interaction center (EIC) In addition HCM functionality is offered as BAPIs and enterprise services. All applications use SAP NetWeaver Business Information for reporting and analytics.
4.1.3 Scope of the Document In this document we describe the conceptual architecture of SAP Business Suite 7 Innovations 2010. The intent of this document is to provide an overview of the SAP ERP HCM architecture, which means that it cannot cover all details and all applications. First the main architecture concepts of the HCM core applications are explained. In addition, the architectures of talent management applications enterprise learning, erecruiting, compensation management, performance management, and career and succession planning are described in this document. Furthermore, the basic architecture of HCM service delivery applications is depicted, as there are self services, HCM processes and forms, and employee interaction center. The document also provides the basic description of the enterprise services in SAP ERP HCM.
162
Internal
© Copyright SAP AG 2010
SAP ERP
4.2 HCM Core Applications
4.2 HCM Core Applications 4.2.1 Personnel Administration (PA) Personnel administration (PA) deals with the administrative activities related to employee master data such employee personal data, address details, bank details, work agreement information, and so on. Employee master data has multiple country-specific specificities and needs to be compliant to legal requirements. Examples are tax details, social security rules and pension administration. The HCM extension applications benefits management and compensation management are based on personnel administration. In this chapter we focus on the central architecture concepts of personnel administration and not the application itself.
4.2.1.1 Infotype Concept In SAP ERP HCM infotypes are the units of information. One infotype defines the data structure for semantically related data, which is stored together on the database and also displayed together on the user interface. Each Infotype has an own database table structure, which stores all instances of the infotype as records. Each infotype is well-defined by a 4 digit number, which is also used to name the corresponding database table. So PAnnnn is the database table of infotype nnnn. For example infotype 0001 includes the attributes for employee organizational assignment. The data of infotype 0001 is stored in database table PA0001. In HCM typically data is valid only in a certain period of time. For example employee‟s st bank details are valid from March 1 2007 to October 30, 2007. Infotypes support the time-dependent storage of data. When data is updated then old data is internally time delimited using a date dependent validity of the record. The infotype framework (see chapter 4.2.1.2) creates for each infotype a data entry screen for displaying and editing its attributes. The usage of the infotypes depends on the use case and is therefore different in personnel administration and personnel development. In PA infotypes are used to store administrative employee data (such as personal information, address, bank details, benefits and social security), time data (such as leave, attendance) and payroll relevant data (such as compensation and tax details). In personnel development the organizational hierarchy is described using only two infotypes. One describes the nodes of the hierarchy, the other the relationships (see chapter 4.2.2.1). Additional infotypes are used to store the attributes.
4.2.1.2 PA Infotype Framework The PA infotype framework provides design time tools for definition and implementation of infotypes and a runtime engine. Based on the defined data structure of the infotype the
© Copyright SAP AG 2010
Internal
163
4 SAP ERP Human Capital Management
SAP ERP
PA infotype framework generates the required technical object like data and table structures, ABAP classes, and modules. At runtime the PA infotype framework provides the following generic features: Persistency handling Buffering of data using read and write buffers Time delimitation handling Change management documents (infotype data change log) Authorization handling In older releases the PA infotypes were generated as ABAP module pools. One module pool contained the application-specific business logic together with the generated user interface. Several function modules and BAPIs were made available which call these dialog modules for dark processing. Since the release SAP R/3 Enterprise a new PA infotype framework is available based on ABAP OO classes. All infotypes are now available in the new framework, too. Within the new infotype framework business logic specific for infotypes is decoupled from generic functionality such as the user interface. For each infotype application-specific business logic is encapsulated in a separate class. The new framework is used for all new extension and service delivery applications as well as for enterprise services proxy implementation. Existing module pools based on the former framework are continued to be supported for existing transactions. The PA infotype framework uses technical customizing tables to store internal technical information of the infotypes. So database structures, dialog modules, module pools, and iDOC definition is stored in the infotype customizing tables T777D and T777ID. Additional technical customizing information (like time constraints, display characteristics) for PA infotypes is stored in T582A table.
4.2.1.3 PA Infotype Internationalization and Extensibility SAP ERP HCM supports more than 40 countries with different legal requirements. Due to this the globalization and extension features become extremely important. Infotypes support many customizing features for having different variants of the UI logic for various country versions, for example enabling and hiding of UI fields, changing field attributes. Also the business logic can be inherited and extended for special processing of countryspecific requirements. Customers also have the choice of extending the infotype structure, business logic as well as the UI screens. A workbench transaction (PM01) is provided for globalization and customer-specific extensions.
4.2.2 Personnel Development (PD) Personnel development deals with the activities related to employee development, for example capture employee potential and qualifications, career and succession planning,
164
Internal
© Copyright SAP AG 2010
SAP ERP
4.2 HCM Core Applications
and creation of development plans. Personnel development as well as organizational management is based on the PD infotypes.
4.2.2.1 The PD Infotype Concept Conceptually PA infotypes and PD infotypes are similar. Both are defined by a data structure, are identified by a 4 digit number, and have their own persistency table (table names: HRPnnnn). However they target different use cases. PA handles only employee related data. For each semantically related subset of attributes it uses a separate PA infotype. In contrast PD works with a variety of business entities which relate to the company‟s organizational structure and job roles. Examples are organizational unit, position, job, e-recruiting object for candidate, and appraisal. As the relationships between these entities change often, for example between position and organizational unit, PD supports the flexible adaptation of these relationships. To do so, the object concept has been introduced, which separates object instances and their relationships in separate infotypes. Each PD business entity is represented as object within the PD infotypes. The PD infotype framework uses specific infotypes (1000, 1001 and 1002) to maintain instances of PD objects and their relationships. Other infotypes are used for storing additional attributes of objects. Object types are defined in a customizing table (T778O) using two characters (A-Z*). It is possible to integrate objects, which are not persisted within PD, such as cost center from FI and user from user management. These Object Types are defined in table T77EO. For all object types (except with external persistency) object instances are created in infotype 1000. The corresponding object descriptions are maintained in infotype 1002. Additional object attributes are maintained using different additional infotypes. Relationships define links between individual object instances. Relationship types are defined in customizing table T778V by 3 character string (SAP name range 000-999). Relationships are bi-directional and the direction is identified by character A (Bottom Up) and B (Top Down). Each relationship between two instances is stored in both directions using infotype 1001. For some external objects just one direction is stored. Search for objects within organizational management is based on a concept called evaluation path. It uses infotype 1000 and 1001 information to identify the objects along a defined structural path. Example: Organizational unit has object type „O‟ and position has object type „S‟. Organizational unit 00000001 “Executive Board” and position 99999999 “CEO” are stored in infotype 1000 together with their object types. Position (S) belongs to Organizational Unit (O) is described by relationship type A003; Organizational Unit (O) incorporates Position (S) is described by relationship type B003 Now in infotype 1001 the following relationships are maintained: 99999999 -> A003 -> 00000001
© Copyright SAP AG 2010
Internal
165
4 SAP ERP Human Capital Management
SAP ERP
00000001 -> B003 -> 99999999
Examples of important PD infotypes such as organizational unit, position, employee, and candidate and their relationships are depicted in the appendix (see chapters 5.3.2 and 5.3.3).
4.2.2.2 PD Infotype Framework PD infotype framework provides the same generic features as PA infotype framework (persistency handling, buffering, time delimitation handling, document change management (log), authorization handling). PD infotype framework is developed in software component SAP BASIS. Also the basic infotypes (1000, 1001, 1002) and the organizational management are part of SAP BASIS to enable reuse across SAP ERP and SAP Business Suite. In older releases the PD infotypes were developed as ABAP module pools with UI and business logic embedded in the same module pool. Several function modules and BAPIs were made available that used to call these dialog modules for dark processing. A new PD infotype framework (based on OO ABAP classes) is available since SAP R/3 Enterprise release and some infotypes are made available in the new framework. However both frameworks are used in parallel. The tables which store internal technical characteristics such as database structures, dialog modules, module pools, and iDOC definitions of infotypes are shared with PA infotype framework (see chapter 4.2.1.2). PD infotype framework provides a design time environment (transaction PPCI) to extend and create new infotypes for customers. Customers can create own objects in infotype 1000 and add new infotypes for the attributes. They can also extend SAP objects by additional attributes.
4.2.3 Organizational Management Organizational management is used to create an organizational plan, which describes the functional structure of an enterprise. It includes organizational unit, position, task, job and so on. Organizational management is used by HCM core and extension applications for example to evaluate headcount, identify reporting structures and assign agents to workflow tasks. So organizational management is integrated with personnel administration (bi-directional) so that the changes made in personnel data (for example change of position) is correctly reflected in the organizational plan and vice versa. The authorization concept of SAP ERP HCM uses organizational management, too. The access rights of many objects within HCM depend on the organizational structure of the enterprise. For example a manager is only allowed to access data of employees reporting to him. It is possible to define authorization profiles based on the user‟s position and generate the corresponding authorization role and profile (transaction PFCG). There are PD infotypes available for defining the position based authorization profiles.
166
Internal
© Copyright SAP AG 2010
SAP ERP
4.2 HCM Core Applications
Technically organizational management is based on the concept of PD objects and PD infotypes as described in section 4.2.2. The main PD objects used in organizational management and their relationships are shown in appendix 5.3.2, figure 5-3. The central functionality of organizational management, in especially creating the organizational structure, is part of software components SAP BASIS and SAP ABA to enable reuse by all applications of SAP Business Suite.
4.2.4 Personnel Time Management Personnel time management supports all processes related to planning, recording and valuation of internal and external work as well as absence data. Time and labor data can be recorded centrally by a time clerk or by each employee himself. Master data required for time management is stored in PA infotypes. Examples are absences (infotype 2001) and quotas (infotype 2006). For decoupled access to time infotypes an additional business logic layer, the business logic processor layer (BLP) has been introduced. Employee/Manager
Time Clerk/ Manager Plant Data Collection (PDC), Logistics, Project Mng. Systems
R
R
R
R
External Time Recording Systems
R Cross Application Time Sheet (CATS)
Time Transactions PA61, PT40 User Interface R
R CATS Business Logic
Time Manager‟s Workplace
R
Personnel Work Schedule and Shift Planning
Personnel Time and Work Events Processing R R
Time Data Recording and Administration
Personnel Administration
R Time Evaluation Driver
Payroll
R
CATS Interface Reports
CATS Interface Tables
Time Data (Time Infotypes)
Figure 4-3
SAP ERP Logistics (LO)
Accounting (SAP ERP FI)
Time Evaluation Results (PCL1 and PCL2)
Architecture of Time Management Application
The architecture of personnel time management comprises the following components (see figure 4-3): Personnel work schedule and shift planning provides functionality for planning working times, shifts and absences. Employee qualifications, working time preferences, and statutory requirements can be taken into account for shift planning.
© Copyright SAP AG 2010
Internal
167
4 SAP ERP Human Capital Management
SAP ERP
This functionality can be integrated with SAP ERP Logistics for capacity planning and order scheduling. Time data recording and administration is the core of the time management application. It is used to maintain and store all work time recordings. It receives employee-related data from PA, for example number of vacation days. For recording and administration of time related data it provides the following interfaces: o Time manager‟s workplace is a specialized user interface for time clerks and managers to capture and correct time related events. Also there is a transaction PA61 that is widely used for time recording data. o External time recording systems, such as time recording clocks or plant data collection systems can be integrated using file-based integration via the HRPDC interface. There are various certified third party products available which support the interface. Cross-application time sheet (CATS) provides self services to managers and employees for time recording and tasks. CATS enables cross application processes like payment to employees, project monitoring or creating invoices for billing. CATS is integrated with time management, payroll, logistics (plant maintenance, project systems, customer service) and SAP ERP accounting for confirmation of work and activity allocation. In the diagram only the recording part relevant from time management perspective is shown and not all possible integrations. Several interfaces are provided to integrate CATS with time management and other applications. Basically CATS has its own persistency mechanism based on CATS interface tables. The data is transferred from CATS to other applications like time management infotypes using interface reports. Time evaluation component valuates employees‟ working times. It calculates planned times and overtime, administrates time accounts and forms wage types, updates time quotas, and is used to check working time specifications. Time evaluation determines overtime and bonus wage types by taking into account holiday calendar, conditions and durations of work performed. It also enables accrual of absence entitlements. Incentive wage calculations are used for performance based remuneration. Typically employee related data is transferred from logistics (production planning, plant maintenance, project systems). Data determined by incentive wages and time evaluation are transferred to payroll for payment processing. Time evaluation is performed by a driver program that uses a particular schema and rules to determine the time results. Conceptually the time driver and schema is similar to payroll driver and schema that is explained in chapter 4.2.5.2. The data transfers with external systems are done via interface database tables and also by external upload and download functionality. For data transfer with SAP ERP logistics, various background jobs can be scheduled for extraction reports.
168
Internal
© Copyright SAP AG 2010
SAP ERP
4.2 HCM Core Applications
4.2.5 Payroll Payroll supports all processes related to the remuneration of each employee. Based on the employee‟s time recordings and working contract the payroll application calculates the gross and net pay, which comprises the individual payments and deductions that are calculated during a payroll period. The payroll result is generally transferred to SAP ERP Financials (SAP ERP FI), which posts the cost and triggers payment to the employee, for example via check or bank transfer. SAP ERP HCM can create data medium exchange files (DME) for triggering payments directly, too.
Payroll Admin
Employee
R
R
Payroll Application HR Process Workbench
Job Scheduler
Process Templates
Legal Forms and Reporting
R R
R
Payroll Driver International
R
Payroll Driver Country A
Payroll Driver Country Z
HRForms Tool
Payroll Drivers
Form Customizing Payroll Schemas
R
Payroll Rules
R
Payroll Driver Customizing
Time Calculations
Gross Pay Calculations
External Payroll Interface Toolbox
Net Pay Calculations
Time Evaluation Driver
External Payroll System
,,, Payroll Posting To FI And Bank Transfer (DME)
Payroll Functions and Operations R
R
SAP ERP FI
R Personnel Administration
Time Evaluation Results (PCL1 and PCL2)
Payroll Master Data Payroll Result (PCL2) (PCL1) HCM Application Data and Payroll Cluster Data
Figure 4-4
© Copyright SAP AG 2010
Posting Documents
Architecture of Payroll Application
Internal
169
4 SAP ERP Human Capital Management
SAP ERP
4.2.5.1 Initiation of Payroll Runs Payroll administrators can configure payroll runs using the HR process workbench (see figure 4-4). The HR process workbench is a design time tool to design a process template for executing payroll runs and initiate subsequent activities like posting the results to SAP ERP FI and providing pay slips for the employee. The administrator selects a process template, which defines the sequence of activities (for example payroll posting and bank transfer document preparation) to be performed before and after payroll runs. Payroll administrators can start and monitor payroll runs manually using the HR process workbench. As payroll runs are executed regularly on a monthly basis, the administrator typically plans payroll runs as jobs starting at a defined point in time using the job scheduler. Payroll runs are executed by payroll drivers which are dedicated programs for controlling the sequence of payroll processing activities. The sequence can be configured using payroll schema and rules (see section 4.2.5.2). To adhere to country-specific legal and statutory requirements for each country a specific payroll driver is provided. When starting a payroll run, the administrator selects the payroll driver, which corresponds to the employees‟ country. Payroll supports also payroll runs apart from regular pay cycles (off-cycle payroll processing). They are triggered using the off-cycle workbench (not in the diagram).
4.2.5.2 Execution of Payroll Runs The payroll driver is the main program used to run the payroll. For each country version supported by SAP ERP HCM there is a country specific payroll driver (see figure 4-4). Payroll driver is configured by a country specific schema and by rules (see figure 4-5). A schema is the central customizing object of payroll application and defines the payroll functions and personnel calculations rules for one payroll run. Typically a country specific payroll driver uses only one main schema but some customers use the option of different schemas for different processing units (based on geographic and enterprise structures). Payroll functions provide logic for payroll calculations. Payroll functions access personal administration to retrieve information about the employee, his contract, and organizational information. In addition the payroll driver calls payroll functions to calculate benefits, taxes, as well as net and gross amount. For example there is one payroll function which considers employees‟ time data which results from time evaluation driver. Payroll personnel calculation rules define under which conditions which payroll operations are executed by the payroll driver. The rules contain the most basic logic used in payroll. Payroll operations are the basic operations that provide smallest possible granularity of operations (like mathematical operands). Payroll operations are used to manipulate the wage types, which are basically the placeholders for storage of rates, amounts, and numbers. The properties of a wage type define how the processing happens on
170
Internal
© Copyright SAP AG 2010
SAP ERP
4.2 HCM Core Applications
amounts and rates during a payroll run. An example for a payroll operation is to multiply the number of working hours by a hourly rate and store the result in the amount of a wage type.
Payroll Driver 1 1 1..* 1..*
Uses
Payroll Schema 1..*
Is Made Up Of
1..*
* *
Payroll Functions Uses
Payroll Rules 1..*
Is Made Up Of
1..* Payroll Operations Elements of Payroll
Figure 4-5
Schema and Rules Relationships
Technically speaking payroll functions as well as payroll operations are ABAP form routines included in the payroll driver and that are called from payroll driver according to the schema. The data declaration for these form routines is done centrally in the payroll driver
4.2.5.3 Payroll Results After the payroll run, the results are stored in the following two payroll cluster data tables (see figure 4-4): PCL1 which stores master data and time data, such as confirmation from time recording, infotype texts, incentive wage time tickets PCL2 which stores payroll results (results of wage types post payroll, cumulated values) and secondary information like generated schemas (schema image used for payroll) The payroll results contain information that is relevant for accounting which is part of SAP ERP FI. The “posting to accounting” component extracts the accounting-relevant data from the payroll results and stores them as posting data. The preparation of posting data includes mapping of wage types to symbolic accounts relevant for posting. Afterwards it transfers the posting data to the accounting components of SAP ERP FI/CO using ALE push mechanism.
© Copyright SAP AG 2010
Internal
171
4 SAP ERP Human Capital Management
SAP ERP
In accounting there exist multiple country-specific programs to trigger the final payment of the wages to the employees. The preliminary data medium exchange programs valuate payroll results and prepare for bank transfers via data medium exchange (DME). Other programs prepare the payroll result for payment by check or cash. Payroll results are communicated to the employee using pay slip forms. These forms are defined as smart forms or Adobe forms using the HR forms tool (see chapter 4.4.2). In addition HR form tools can be used to define forms for legal reporting. The external payroll interface toolbox depicted in figure 4-4 supports multiple integration modes with external payroll applications, for example: Only master data export Gross payroll calculation in SAP ERP HCM and net payroll calculation externally Export master data and payroll results for further evaluation External payroll interface toolbox is used to provide reporting outside of SAP system and for internationalization (see below).
4.2.5.4 Internationalization and Localization SAP HCM payroll supports the specific local payroll processes for 47 countries. To do so, each country has a specific cluster structure for storage of country specific data and a specific payroll driver. All legal and statutory requirements that are specific for a country are fulfilled by using a corresponding payroll driver and country specific payroll schema. SAP delivers the country specific payroll drivers together with schemas that reuse some sub-schemas from international schema version. The payroll solution is kept up-to-date by providing regular legal changes via legal change packages (support package delivery mechanism). In countries where SAP or partner solution is not available a localized solution can be developed using the international payroll driver version as basis. Another option is to use the external payroll interface toolbox to integrate with a third party application, which supports the country-specific requirements. Then gross payroll can be processed by SAP ERP HCM and net localized payroll (taxes, social security) by the third party application.
4.2.6 Appraisals, Evaluation and Survey Engine Appraisals, evaluation and survey engine (AES engine) provides services for conducting and evaluating appraisals and surveys. AES engine is part of the software component SAP_ABA to enable reuse. It is a HCM core application used by many SAP ERP HCM applications for example in the learning solution for course evaluation (see chapter 4.3.6.2), in the employee interaction center to collect agent feedback (see chapter 4.4.3), and in e-recruiting for candidate questionnaires (see chapter 4.3.5.2). Especially the HCM extension application performance management uses the AES engine heavily for setting objectives and creating appraisals.
172
Internal
© Copyright SAP AG 2010
SAP ERP
4.2 HCM Core Applications
AES engine generates user interfaces based on Business Server Pages (BSP). The administration user interface is implemented using ABAP Dynpro. Applications which use the AES engine typically implement a wrapper to create an application-specific variant of the AES engine. In addition AES engine provides multiple BAdIs to enhance its functionality. Adobe document server is used for generating Adobe documents for offline usage.
R
R
Dynpro UI
BSP UI
Adobe Forms
Appraisals / Surveys/ Questionnaires Appl.-Specific Wrappers
R AES Engine
Performance Mngt.
R User Interface Generation
Enterprise Learning
R R
EIC
Adobe Document Server
Generated Forms
R
Engine Logic 3rd Party Appl. R
R R TREX
Index
PD Framework
SAP ERP HCM Server
AES Application Data
Figure 4-6
© Copyright SAP AG 2010
Template and Process Customizing
Architecture of AES Engine
Internal
173
4 SAP ERP Human Capital Management
SAP ERP
4.3 HCM Extension Applications HCM extension applications enhance the core applications and support additional business scenarios. From architecture perspective most extension applications are just additional functional building blocks on top of the core applications.
4.3.1 Talent Management Overview From functional perspective talent management covers talent processes from attracting talent to developing and retaining talent. From an architectural point of view talent management can be described as an extension layer of the ERP HCM foundation layer. While the foundation layer implements the core HR processes such as organizational management, personnel administration, payroll, personal development, and time management the HCM talent management applications on top include applications like E-Recruiting, career management, compensation management and enterprise learning. The foundation layer provides data and functions, which are reused by the application in the extension layer (see figure 4-2). Talent Management covers the following applications components, Career and succession management Compensation management Performance management E-recruiting Enterprise learning In the following each of these applications is described in more detail. But first cross topics like UI technologies used in talent management and persistency layer are covered.
4.3.1.1 UI Technologies The user interface of talent management applications are implemented in Web Dynpro ABAP. To display organizational charts graphically as well as for highly interactive user interfaces the talent management applications use Adobe Flash Islands and NAKISA.
Adobe Flash Islands To enhance Web Dynpro ABAP UIs with highly graphical or interactive UI elements UI parts are implemented using Adobe Flex. These Adobe Flex UI Elements are embedded in WD ABAP as Flash Islands. The principal architecture of Adobe Flash Islands in a Web Dynpro application is shown in the following figure 4-7. Adobe Flash Island consists of flash based application (compiled as SWF). This flash application consists of flash components. Data and events are handled using the flash island library component. Flash islands are stored in Mime Repository of ABAP server. Additional style files are also stored in Mime.
174
Internal
© Copyright SAP AG 2010
SAP ERP
4.3 HCM Extension Applications
Loading Style SWFs during runtime from WAS MIME Repository
Browser Adobe Flash Player
Flash Application Flash Island Wrapper
Local SWFs
Flash Component R
Flash Island Component
Loader
R
HTTP
R
XBCML
WAS Web Dynpro Mime Rep. Service
WD Component Flash Island UI Element
R
Context
Mime Repository
Figure 4-7
Adobe flash Islands in Web Dynpro
Listed below are some examples of controls that are based on Adobe flex embedded in WD ABAP as Flash Islands. Talent management grid (2-dimensional N*M grid) – to display for example performance Vs potential graph o Displays employee business card/s (Tile View) o Employee list view (Data Grid View) Work experience (employee resume) – Graph drawn on time scale Performance management – Overall appraisal rating on N * M grid Performance management – Calibration (Bell curve adjustment) Performance management – ranking view (Calibration and ranking) Accordion navigation control – Used in performance management documents as menu navigation control Process roadmap – Used in performance management document to display time phase scale Compensation column chart – Compare old/new compensation, deviation, etc. Pie chart – summary of documents
© Copyright SAP AG 2010
Internal
175
4 SAP ERP Human Capital Management
SAP ERP
Talent visualization by NAKISA based UIs Besides Flash Islands also the NAKISA hierarchy visualization control is used, mainly in various MSS applications to visualize organizational charts. This control is implemented by the SAP partner Nakisa. When the control is used new .Net server is required in the customer‟s system landscape to keep this server an optional component. SAP GUI based UIs are implemented as a fallback. These UIs are integrated in an existing SAP GUI based framework (“hierarchy framework”) which is used to maintain hierarchical structures in HR (e.g. transaction PPOME for the maintenance of the organizational structure). By the usage of this framework significant reuse of already existing Dynpros is achieved.
4.3.1.2 Persistence layer Generally speaking the talent management uses Infotype framework for its persistency. Mainly the persistency is handled in PD Infotype framework. Certain data regarding employee work agreement is stored in PA Infotype framework. The business objects like talent, talent review meeting, job family etc. are implemented in the PD infotype framework (for a detailed description see section 4.2.2.2). The PD Object Layer allows the object oriented handling of these entities. The PD framework offers transactional services like persistency handling, buffering, time limitation handling, document change management and authorizations.
4.3.2 Career and Succession Management Career management handles processes related to career planning for an employee. Succession management handles processes from organization perspective to ensure continuous talent supply for key positions. Key features includes support of processes related to talent data storage, talent assessment and review. Customers can use the partner product SAP® TALENT VISUALIZATION BY NAKISA to visualize the talent data and perform succession planning. Career management key features: Enable employees to manage their own career paths and aspirations, either through self-service capabilities or as a result of planning with managers. Compare employee profiles with the requirements of specific positions to determine skill and knowledge gaps, which can then be tied directly to training plans. Implement structured career paths to guide employees through career progressions based on their jobs within the organization. Succession management key features: Identify and track high-potential employees and implement development plans to ensure that they are prepared to assume future leadership roles. Identify specific key positions and target specific employees as potential successors.
176
Internal
© Copyright SAP AG 2010
SAP ERP
4.3 HCM Extension Applications
The following figure 4-8 gives a detailed overview of the architecture.
Talent Management Specialist
Manager
Employee
R
R
Enterprise Portal 7.0
iView Repository (PCD)
R
OBN Target Repository (PCD)
R
R
R
SAP ERP HCM 6.0
Nakisa UI Server
WD/FPM Talent Review UI
Assessment UI
Job Architecture UI
Talent Profile UI
Succession Planning UI
R
TM PD Objects Talent
R R
Talent Review Meeting
R
R
Job Family
RFC R
Internet Graphics Server R
R
R
KPRO
PD Object Layer
AES
Enterprise Search
Print Workbench
Adobe Document Server
R
PD Framework
R
R
TREX 7.1 Search Engine
Indexing ERP Application Data KPRO Documents
Figure 4-8
HR Infotypes
Architecture overview of Career and Succession Management.
Data related to talent (e.g. work experience, preferences, skills, education, accomplishment, etc), relationship to Job family, talent review is stored as PD Objects using PD Infotype framework. Other process data like documents, attachments are stored as KPRO documents.AES engine is used to define templates and conduct the assessments and reviews. The user interface of talent management applications like Talent Review, talent profiles are implemented in Web Dynpro ABAP and Adobe flash islands. Integration with partner product SAP® TALENT VISUALIZATION BY NAKISA is also shown in the diagram which enables to use Nakisa UIs to visualize and act on talent data stored in ERP HCM.
© Copyright SAP AG 2010
Internal
177
4 SAP ERP Human Capital Management
SAP ERP
As described in figure 4-8, TREX is used as the search engine to search for talents with complex search criteria. Complex searches involve a search with not only the criteria directly defined as attributes at the business object itself but also the criteria defined at associated business objects where the association path length can be > 1. As ABAP client for TREX the Enterprise Search is used as only this tool (in contrast to the Search Engine Service (SES) offers the following possibilities, to define search requests with association paths of length > 1. to execute authorization checks directly in the search engine. to handle time dependencies in a comfortable way. During the talents review process all managers shall have the possibility to have a comprehensive overview over all talents to be handled in the talent review meeting. Therefore a PDF-document has to be generated based on the available talent data and stored as an attachment to the talent review meeting instance. The PDF-generation is accomplished by the usage of the print workbench which itself is based on Adobe Print Forms generation and that requires an Adobe Document Server (see figure 4-8).
4.3.3 Compensation Management Compensation Management enables an enterprise to implement innovative reward strategies, such as performance- and competency-based pay, variable pay plans, and long-term incentives reward programs. It allows also to analyze and compare compensation packages using internal and external salary data to ensure competitiveness in the marketplace. Key functions of Enterprise Compensation Management are, Compensation Administration – processes related to compensation guidelines, planning, eligibility, reviews, granting salary increases and bonuses are handled. Long-Term Incentives – processes related to long term incentives like equity, stock purchase are handled Budgeting – processes related to creating and monitoring budgets on basis of organizational structures are handled The following figure 4-9 describes the detailed architecture. Apart from the usual Persistency Layer offered by the PD Infotype framework compensation management uses its own persistence for performance reasons(see figure 4-9) and ensuring overall process consistency considering ongoing changes in other master data. All relevant information for the compensation planning will be stored before hand in a dedicated planning storage. Complex and long-lasting operations of the HCM backend are thus removed from the manager User Interface and transferred to a report which would run before the start of the planning cycle.
178
Internal
© Copyright SAP AG 2010
SAP ERP
4.3 HCM Extension Applications
Compensation Specialist
Manager
R
Administrator
R
R
SAP ERP HCM 6.0 Budget Creation UI
Planning UI
Activation UI
R
OADP
Initial Job
UI Component Periodic/ OnDemand Job UI Meta Data
R
R
R
Function Module Repository
R
Planning Storage Service
Planning Persistence
HCM Application Data Budget
Figure 4-9
...
IT759
Payroll Infotypes
Architecture overview of Compensation Management
4.3.4 Performance Management Employee performance management helps enterprises define and monitor objectives for the entire enterprise, individual departments, and employees themselves. Objectives can be monitored using key figures and appropriate benchmarking.
Key Benefits Stronger strategy focus at the management level Enhanced workforce alignment with enterprise strategy Simplified performance reviews and identification of top performers Comprehensive comparison options as a basis for fair performance-based compensation Performance Management is largely built on the AES engine. New UIs are built in WD ABAP and Flash Islands. For more details on AES refer to the section 4.2.6.
© Copyright SAP AG 2010
Internal
179
4 SAP ERP Human Capital Management
SAP ERP
4.3.5 E-Recruiting With E-Recruiting, job applicants and candidates can search for job offers, register themselves in a talent pool, and provide their job application online using a Web browser. Recruiters can post job requisitions within the e-recruiting application, but also on external job boards via HR-XML interfaces (see http://www.hr-xml.org). Applicant tracking and reporting functions helps recruiters to process job applications in an organized way and monitor the effectiveness of the recruitment department and process. External Candidate External Job Portal R
Firewall
R
Manager Firewall
Employee Recruiter Administrator Duet R
R
R
R
R R
Web Dynpro ABAP
Business Server Pages (BSP)
Search Engine (T-Rex)
HCM Forms & Processes
R
User Interface
Requsition Request (RFC)
R
R
R
Candidate
Requisition
Application
Activity
New Hire (XI or RFC R
Business Logic Objects New Employee (RFC) R Business Partner Framework
R
R
Knowledge Provider (KPRO)
PD Framework
R
Personnel Dev. (PD)
R
R
AES Engine
Read Org Data Qualifications (RFC)
HCM Core Appl.
R
SAP ERP HCM Server (Relevant components for e-rec. are shown)
E-Recuriting Add-On (Standalone)
E-Recruiting Application Data (PD Infotypes)
Personnel Admin. (PA)
Org Data, Qualifications, Employee Data (ALE) KPRO Repository
HCM Business Data
Figure 4-10 Architecture of E-Recruiting E-recruiting is an add-on to SAP ERP HCM, which can be deployed in three different ways: Stand-alone installation without any integration with a backend system. For initial setup organizational data and qualification categories have to be imported via ALE from SAP ERP HCM.
180
Internal
© Copyright SAP AG 2010
SAP ERP
4.3 HCM Extension Applications
Stand-alone installation with integration into SAP ERP HCM. In this case after completing the recruiting activities, data is sent to the SAP ERP HCM for actual hiring either by using RFC or via SAP NetWeaver Exchange Infrastructure (SAP XI). Integral part of SAP ERP HCM installation: e-recruiting calls directly functions of SAP ERP HCM, especially from PD Usually e-recruiting is deployed as a stand-alone installation with firewalls protecting the access from the Web to the e-recruiting applications and from the E-recruiting application to SAP ERP HCM (as depicted in figure 4-10).
4.3.5.1 User Interface The user interface of e-recruiting is completely role based and is displayed using a Web browser. The user interface is implemented using Web Dynpro ABAP and Business Server Pages (BSP): the UI screens for the roles recruiter and administrator are based on BSP, whereas the UI screens for internal and external candidates are implemented using Web Dynpro ABAP (see figure 4-10). In addition SAP Duet is used to provide an alternative user interface to recruiters and managers within their MS Outlook client.
4.3.5.2 Business Objects Business objects, such as candidate, requisition, posting, and application are used for data retrieval and manipulation tasks. Each business logic object is implemented as an ABAP OO class. Data of these e-recruiting objects are stored in PD infotypes using the underlying PD framework (see chapter 4.2.2.1). As a consequence the entire data model of e-recruiting is based on the PD framework. The PD objects data model is shown in appendix (see chapter 5.3.3). For every candidate (internal or external) in the e-recruiting system a business partner is created which holds the identity and contact data. Appraisal evaluation and survey engine (see chapter 4.2.6) is used for creating, publishing, and analyzing questionnaires, which are used for capturing information and evaluating the candidates in the talent pool.
4.3.5.3 Data Persistency The e-recruiting application stores data in both structured and unstructured formats. Business object data, for example about candidates, is stored in infotypes. A background job periodically collects the data of the e-recruiting objects, converts them into XML documents and stores them into the knowledge provider (KPro). In addition knowledge provider (KPro) is used to store documents and files, which are uploaded from the applicant as part of their resume data (MS Word documents, PDF files, pictures and so on). Above mentioned KPro data is indexed by the search engine TREX to support fast search on posted jobs as well as suitable candidates.
© Copyright SAP AG 2010
Internal
181
4 SAP ERP Human Capital Management
SAP ERP
4.3.5.4 Integration with Other Systems E-recruiting provides interfaces according to HR-XML standards (see http://www.hr-xml.org) for integration with external job boards. Job requisitions can be posted to these boards and applications can be received using SAP NetWeaver XI. If not installed on the SAP ERP HCM server, e-recruiting is integrated with SAP ERP HCM using RFC calls and ALE (see figure 4-10). The processes publication of job requisition and new data hire transfer are supported with SAP NetWeaver XI, too. Existing employee master data within PA can be transferred and mapped to internal candidate in e-recruiting. In addition PD data like skills, qualifications can also be transferred. In figure 4-10 a particular use case is depicted for requisition request. When a manager starts the process using HCM processes and forms of SAP ERP HCM server the requisition data is passed to e-recruiting via RFC. Non-SAP ERP systems can be integrated using HR-XML interfaces and SAP NetWeaver XI.
4.3.6 Enterprise Learning The enterprise learning application of SAP ERP HCM supports following main use cases: Creation and publication of e-learning content Organization of training courses Learner activities Within each scenario different components of the enterprise learning application are involved. The complete architecture is depicted in figure 4-11.
4.3.6.1 Creation and Publication of E-Learning Content Enterprise learning provides a set of Java desktop applications for course authors and designers to create e-learning content (see figure 4-11). Authoring environment which contains instructional design editor for structuring elearning content and tests and instructional element editor and test editor for editing the course content and tests. Offline content player for previewing and testing of e-learning content. Repository explorer for publishing e-learning content. The applications run on the users‟ client which enables offline usage. The created content is initially stored in the local file system. When connected, the content can be published using the repository explorer. E-learning content is made available to learners by storing it in a content management system using WebDAV. As content management system Knowledge Management of SAP NetWeaver Enterprise Portal can be used. In parallel information about offered e-learning trainings is transferred to the publisher database on SAP ERP HCM server. Publisher database is a database table that stores the meta data of the e-learning content published in content management server. The content management server can use TREX for search related functionality required for content 182
Internal
© Copyright SAP AG 2010
SAP ERP
4.3 HCM Extension Applications
authoring environment. The results of the search are made available in repository explorer of content authoring environment.
R
Administrator
Instructor / Tutor
Content Author
SAP GUI
Browser
Java Desktop Applications
Firewall
External Learning Management System
Content Authoring Environment
Publish Withdraw (XI) Training Administration
Learner
Java Desktop Appl.
Content Repository Explorer
Content Offline Player
Browser
Local Repository (File System)
Local Repository (File System)
R
HTTP(S)
R
R
R
R
TREX Search Engine
R
R
Index TREX
JEE Engine Administration UI (Dynpro)
Instructor Portal (Web Dynpro)
Learner Portal (BSP) LSO-FE Add-on User Interface R
Course Catalogue
R
Course Participants
R
Update Learning Progress (RFC)
Content Player (JSP UI) R
R
Publish Content (WebDAV) R
SAP ERP Time Management / MM / FI
R
Course Instructor Business Objects R
Appraisals, Evaluation and Survey (AES) Engine
R
PD Framework
Publisher Database Learning & Course Application Data
Content Management Services
Master Repository (Published Content) Content Management Server
SAP ERP HCM Server (ABAP)
Figure 4-11 Architecture of Enterprise Learning The e-learning offering is presented to the learners within the learning portal. If the learner books an e-learning course, he can view it online or offline using the corresponding player (see figure 4-11). The authoring environment supports the creation of content according to SCORM1.2/ SCORM2004, which is a specification and standard from Advanced Distributed Learning (ADL) and Aviation Industry Computer-Based Training Committee (AICC). Details about SCORM2004 standards can be found at http://www.adlnet.gov/scorm/index.aspx and http://en.wikipedia.org/wiki/SCORM. The enterprise learning solution (mainly the training and event management parts) is also integrated to other SAP ERP applications like time management (for activity recording), materials management (resource booking), and financial accounting.
4.3.6.2 Organization of Training Courses The administration UI (training management functionality) of enterprise learning serves as the administration area for organizing, publishing and booking of classroom training. Training management is comprised of two main processes:
© Copyright SAP AG 2010
Internal
183
4 SAP ERP Human Capital Management
SAP ERP
Course offering which involves course planning and creation of course catalog Training administration which involves booking activities. The instructor portal is the user interface for instructors and tutors. Instructors can access their courses to manage the course participants. They can perform appraisals to get feedback from the participants using the AES engine. Achieved qualifications can be assigned to participants and are then stored in the corresponding PD infotypes. It is possible to integrate Adobe Connect Professional (see http://www.adobe.com/products/acrobatconnectpro/) with enterprise learning to conduct virtual classroom learning. The integration is not shown in figure 4-11.
4.3.6.3 Learner Activities All offered classroom and e-learning courses are presented to the learners within the learning portal (see figure 4-11). The learning portal includes functionality to search course content and to book training courses. It also includes a content player for playing e-learning content. The content player loads the e-learning content from the content management system whenever a learner starts it in his Web browser. The separate offline player can be used to learn offline and synchronize the learner‟s progress with the central learning portal online.HCM Service Delivery Applications
184
Internal
© Copyright SAP AG 2010
SAP ERP
4.4 HCM Service Delivery Applications
4.4 HCM Service Delivery Applications HCM service delivery applications provide additional output channels for HCM applications. In the following we describe the architecture of the most prominent service delivery applications, as there are: Self services for employees and managers (ESS and MSS) HCM Processes and Forms based on SAP Interactive Forms by Adobe. Employee Interaction Center (EIC) which provides call center functionality with role specific access to services and information for professionals A new channel is the access of HCM services within a Microsoft Office environment based on Duet. The architecture of Duet is not discussed here since it is a separate addon application not specific to SAP ERP HCM.
4.4.1 Self Service Applications Self services provided via Web browser play a significant role in the interaction between a company‟s employees and managers and the SAP ERP HCM application. The self services application component enables the creation and operation of employee and manager self services (ESS and MSS). Examples of employee self services are employee personal information, leave and time management, benefits and compensation, and travel management. Examples for manager self services are employee administration, compensation and budget planning, and project planning.
4.4.1.1 Self Service Applications Deployment Options As of SAP Business Suite 7 Innovations 2010, SAP has provided ESS based on WD ABAP technology. WD ABAP-based ESS services are available with software component EA-HR 605. In future MSS role will be also offered on WD ABAP technology. Which means the companies have the option of not installing the JAVA parts of self services (SAP ESS 603 and other related pre-requisite JAVA (For e.g., SAP PCUI GP 603) components). An additional deployment option using NetWeaver Business Client (NWBC) for HTML without using SAP NetWeaver Portal is also available for Employee Self-Service (WDA). Customers deploying the new WD ABAP services on SAP Enterprise Portal must deploy the ESS business package content BPERPESSWDA1.50. Delivery Strategy of ESS (Will be adopted for MSS as well in future): SAP supports both WD ABAP and WD JAVA based ESS applications as per the existing maintenance strategy SAP supports standard deployment options based on SAP NetWeaver Portal and NWBC (mainly NWBC for HTML).
© Copyright SAP AG 2010
Internal
185
4 SAP ERP Human Capital Management
SAP ERP
Integration into other portals like Microsoft SharePoint and IBM websphere can be done based on NWBC for HTML New innovations and features via upcoming enhancement packages will be delivered only in WD ABAP based ESS Starting EhP5, usage of Homepage/Area page framework is discontinued in new versions of Employee role and is replaced by service map capabilities based on NWBC client (PFCG role) or as a WD ABAP application based on launchpad customizing.
4.4.1.2 Employee Self Services based on WD ABAP Employee self services are based on the following set of reusable functions and framework components (see figure 4-12) PFCG role or launchpad customizing for creating overview pages, from which employees can access individual self services Floor plan manager (ABAP) for combining different UI components which form a self service user interface (https://wiki.wdf.sap.corp/wiki/display/FPM/Home) BOL (Business Object Layer) and GenIL (Generic Interaction layer) to encapsulate business logic (https://wiki.wdf.sap.corp/wiki/display/WEBCUIF/Architecture) Employee central services for employee authentication Navigation based on object-based navigation for handling navigation of self service applications. Role content delivered using PFCG and SAP NetWeaver Portal. In case of portal only a lightweight role (single iView as entry point to service map) is created and actual structure is maintained via launchpad customizing. POWL based worklists and workflow inbox for approval scenarios All new applications use the UI Guideline 2.0 Self services themselves are implemented using Web Dynpro ABAP technology and navigations are programmed in such a way that are independent of SAP NetWeaver portal. As per existing architecture guidelines the business logic is encapsulated using GenIL components. Wherever UI permits the GUIBB (Generic UI Building blocks) are used to render the simple form and list layouts so that maximum configurability is offered. Navigation across applications is defined using FPM launchpad API and launchpad customizing.
186
Internal
© Copyright SAP AG 2010
SAP ERP
4.4 HCM Service Delivery Applications
NWBC HTML
Browser
R
SAP Enterprise Portal
Other Portals (e.g. WebSphere, Sharepoint)
R
R
Adobe Document Server (ADS)
R
Adobe Form Repository
PFCG Roles OBN (BOR) Definition Launchpad Configuration FPM/POWL Feeders
Report Launchpad Menu & Navigation
Floorplan Manager (FPM) / Personal Object Worklist (POWL) UI Building Block (G)UIBB on WD ABAP
BOL
POWL Workflow Inbox
SAP Business Workflow
Workflow Process Models
R
Business Logic (Layer)
Process Object Framework
ERP Application Data
Process Data
ECC Server AS ABAP
Figure 4-12 Architecture of ESS WD ABAP Applications (Portal Agnostic) As shown in figure 4-13 certain applications like personal information scenarios are based on BOL (Business Object Layer). These applications use the Generic UI Building blocks (GUIBBs) like form and List. The GUIBBs use the WD ABAP component configurations to create the layouts. These can be completely configured by administrators in a modification free manner providing highly configurable UIs. Certain UIBBs which cannot be rendered by simple form/list layouts are created as WD ABAP components.
© Copyright SAP AG 2010
Internal
187
4 SAP ERP Human Capital Management
SAP ERP
End User
Browser R
WD ABAP Application
Config. for UI Composition
Floorplan Controller R
Configurable UI Building Blocks (UIBB) R
Config. for screen definition
R
Freestyle UI Building Blocks (UIBB)
Administrator UI Feeder Classes
R
R
BOL Application R
ESS specific Business Logic Customizing Data
R
PA Infotype Framework
ERP Application Data HCM Backend
Figure 4-13 Architecture of WD ABAP Application based on BOL (e.g. Personal Information Scenarios in ESS) Applications that require workflow and approval steps are typically implemented using HCM Processes and Forms. UI here is based on WD ABAP using SAP Interactive forms by Adobe. This requires Adobe document server and the process related data is stored in process object framework using case/records management. Workflow technology is used for performing approval steps (see also chapter 4.4.2)
4.4.1.3 Self Services based on WD Java Manager and employee self services are based on the following set of reusable functions and framework components (see figure 4-14): Homepage framework creating overview pages, from which employees and managers can access individual self services 188
Internal
© Copyright SAP AG 2010
SAP ERP
4.4 HCM Service Delivery Applications
Floor plan manager (Java) for combining different UI components which form a self service user interface Employee central services for employee authentication Object and data provider framework (OADP) for displaying organizational structures Portal content and navigation for application configuration and handling navigation of self service applications. Self services themselves are implemented using Web Dynpro Java technology and deployed in SAP NetWeaver Enterprise Portal as iViews. Employee
Manager
R
SAP NetWeaver Portal
Employee (GP User)
R
R
iView (WebDynpro Java)
Guided Procedures Runtime
R
R Self Service (WebDynpro Java Application) R
Employee Central Services
Floor Plan Manager
OADP Framework
Navigation and Portal Content
Homepage Framework
Self Services Generic Components Configuration (PCD) SAP AS (Java) R
R
RFC
SAP ERP HCM (ABAP Backend)
RFC
Other SAP Applications (SAP SRM, cProjects, SAP NW BI)
HCM Business Data
Figure 4-14 Architecture of ESS and MSS Applications Guided procedure technology provided by SAP NetWeaver is used for creating multi-step user interfaces reusing ESS applications for the individual user interaction areas. An example is the combination of different ESS applications in one guided procedure called “my first days”, which guides new employees through different services.
© Copyright SAP AG 2010
Internal
189
4 SAP ERP Human Capital Management
SAP ERP
Floor Plan Manager for WD Java The Web Dynpro Java floor plan manager is the central design and runtime component for self services applications. Each self services consists of one floor plan which combines one or more visual application components (VAC, see figure 4-15). Each visual application component is assigned to one business logic component (BLC), which provides input checks and handles the communication with the backend. Employee
Manager
R
R iView (Web Dynpro Java)
R Self Service (Web Dynpro Application) R FPM Main Window
R
Floor plan Controller
R
Configuration Controller
Floor Plan Manager R Visual Application Component
Configuration
R Business Logic Component Self Service SAP AS (Java) R
RFC
SAP ERP HCM (Backend)
HCM Business Data
Figure 4-15 Detailed View of Floor Plan Manager WD Java for ESS and MSS The floor plan manager provides design time tools for the implementation of visual application components and the configuration of floor plans. For each self service application a dedicated configuration of floor plan is created and stored in portal content directory (PCD). In the floor plan configuration the view assembly of the referring visual application components is defined. Visual application components can be reused in different floor plans.
190
Internal
© Copyright SAP AG 2010
SAP ERP
4.4 HCM Service Delivery Applications
At runtime the iView and the corresponding Web Dynpro Java application of the self service is instantiated (see figure 4-15). It accesses the floor plan manager main window, which passes the call the floor plan controller. The floor plan controller retrieves the configuration of the floor plan via the configuration controller. Then it initiates the visual application components, defined in the configuration. The visual application components use business logic components to access the SAP ERP HCM backend using RFC.
Home Page Framework (WD Java) Homepage framework enables the creation of overview and area pages in SAP NetWeaver Portal which combines related self services. Homepage framework consists of a Web Dynpro Java application which can be configured. According to the configuration pages created with the homepage framework group and describe different self services and provide hyperlinks with which they can be started. For this the homepage framework uses the standard portal navigation features. Homepage framework provides the following functions: descriptions for the individual services that will appear on the user interface edit the link texts of the hyperlinks that the employees use to start the services emphasize certain services (for example, because there is an urgent deadline) deactivate services display employee-specific information as dynamic links (for example "Nine days of leave will expire by ") Homepage framework consists of the following components: Web Dynpro Java application which provides the user interface of the homepages. Development Components for handling Portal Navigation Customizing layer in SAP ERP HCM backend Proxy class implementation layer to implement specific logic for individual self services, for example to deactivate self services, and display application or employee specific information. The homepage framework is mainly used to group employee self services.
4.4.1.4 Object and Data Provider Framework (Used in both WD Java and WD ABAP) Object and data provider (OADP) is a generic framework to display structures from organizational management in a list or tree structure. It consists of a generic, configurable Web Dynpro application. The customizing of the OADP framework is provided in SAP ERP HCM backend. There are the following two customizing areas: Object selection defines the rules for selecting various objects, for example the evaluation paths for searching organization structure (all employees in a manager‟s responsible organizational unit)
© Copyright SAP AG 2010
Internal
191
4 SAP ERP Human Capital Management
SAP ERP
Data provider defines columns, column groups, hierarchies and data views. This OADP framework is reused by many self services applications in MSS area.
4.4.2 HCM Processes and Forms Form-based processes play a significant role in HCM. Forms are used to capture information and to apply for certain services. To address this, SAP ERP HCM provides the HCM service delivery application HCM processes and forms, which supports simple paper-like electronic processes using SAP interactive forms by Adobe. HCM processes and forms is for example used by self services, by the HR administration role and within the employee interaction center for processes like employee hiring process, employee termination process, organizational change process, maternity leave and birth of child process. HCM processes and forms allows creating forms and defining interactive processes based on forms. Process definition and execution is based on SAP Business Workflow. HCM processes and forms supports search and tracking of processes, and automatic transfer of data to backend PA and time infotypes. HCM Processes and Forms consist of the following components (see figure 4-16): User interface consisting of Web Dynpro ABAP applications and SAP interactive forms by Adobe. Adobe Document Server for designing and processing SAP interactive forms by Adobe. HCM processes and forms uses the ABAP application server workbench repository for Adobe forms. Forms are cached on the Adobe Document Server. Internal service request (ISR) framework. In HCM processes and forms this framework is used as a communication layer between UI application and process object and HCM backend services layer. Technically ISR provides set of standard RFCs and BAdIs that applications can implement. Process object layer provides services, for process tracking, error handling, process search and for managing process related data (like form data, file attachments). First process object layer provides runtime persistence for each HCM process. It persists the process data like form data and uploaded attachments. For persistency of process data it uses SAP NetWeaver Case and Records Management. Attachments are stored using knowledge provider. Process object layer also provides the search capabilities on the persisted process data.
192
Internal
© Copyright SAP AG 2010
SAP ERP
4.4 HCM Service Delivery Applications
Manager HR Administrator
Employee Adobe Document Server
R E-Recruiting
R
Adobe Forms Repository in ABAP Server
R
R
R
Web Dynpro Applications and Adobe Forms
R
Background Workflow steps (Dark Save) R
ISR Framework and RFCs (Calls ISR BAdI Implementation for HCM Processes and Forms) R
R HCM Application Services Form Customizing
Process Object Framework Process Object API Layer (RFC)
Dispatcher Layer for HCM Application Services R
Personnel Administration Service Layer
New Hire Interface & Requisition Process
Time Management Service Layer
R
Other (Generic) Services Layer
Process Object Business Logic
R
Process Workflow Integration Layer
R
SAP Business Workflow Engine
Services R R
Personnel Administration
R
Time Management
R
Other Application
Case Management
R
Records Management
R
Knowledge Provider
Applications
HCM Application Data
Case Management Data
Records Management Data
KPRO Data
Figure 4-16 Architecture of HCM Processes and Forms SAP workflow engine is used for executing processes. POWL based Workflow inbox in NWBC environment or Universal Work List (UWL) in portal environment is used for accessing work items by human process agents. Generic service dispatcher provides services for making the adobe forms interact with real time (online) application data. It connects to backend services, such as PA, PD and time management. It is possible to create custom backend application services where standard services are not available. The generic service dispatcher provides services for online checks of input data, and for value help. The HCM processes and forms provides integrated design time environment, which acts as a single customizing transaction. It integrates various tools like the workflow builder and form designer (integrated with Adobe Live cycle designer). Within the design environment it is possible to map the fields on form to backend application data (e.g. HCM Infotype fields). The design time environment is not shown in figure 4-16.
© Copyright SAP AG 2010
Internal
193
4 SAP ERP Human Capital Management
SAP ERP
HCM processes and forms provides external interfaces to support specific processes like new hire from e-recruiting. SAP XI triggers a new HCM process for hiring by creating a process object instance during inbound processing and passing on the data and attachments from the e-recruiting XI message.
4.4.3 Employee Interaction Center (EIC) The employee interaction center (EIC) is an important part of a HCM service delivery concept, especially in an organization model in which particular services are provided for the whole company by a central unit (internal or external outsourcing). Employees can contact the EIC whenever they require help or support regarding HR-related issues, for instance, when they want to request that their personal data should be changed or updated. EIC is used mainly in the following cases, for example: HR services to be concentrated in one location irrespective of company locations. Employees have limited access to SAP ERP HCM system and ESS EIC is based on the Interaction Center Web Client framework (IC Web Client), originally created for the interaction center of SAP CRM. From SAP Business Suite 7 Innovations 2010 EIC is tightly integrated with CRM functionality. The goal here is to provide a single Interaction center for all business suite scenarios based on CRM.
4.4.3.1 Interaction Center Web Client Framework The IC Web Client framework provides the basic functionality required for the agent dashboard. It consists of the following three layers (see figure 4-18): User interface based on Business Server Pages (BSP), which is displayed in a Web browser The business object layer (BOL) provides business objects optimized for UI presentation. The business objects retrieve their data from the underlying generic interaction layer. Generic interaction layer handles the data transfer between underlying application data and BOL using corresponding connectors. This layer also takes care of session management and data management of IC Web Client. Communication management software to support telephony, fax, e-mail and so on is integrated using the integrated communication interface. Additional general information regarding IC Web Client features can be found at: http://help.sap.com/saphelp_erp2005vp/helpdata/en/07/2129d48928430ca741e03111ecee18/frameset.htm
4.4.3.2 Architecture of Employee Interaction Center (based on CRM) – from enhancement package 5 Features that allows CRM EIC Agents: 194
Internal
© Copyright SAP AG 2010
SAP ERP
4.4 HCM Service Delivery Applications
Search and Authenticate the employees (the caller) before the service request is created Start Employee Self Services on Behalf of an employee Create an HCM Process and link the process to a service request Display the HCM Process form via the linkage in the service request Search an existing HCM Process and link the process to a service request Execute the HCM P&F workflows via agent's Inbox Execute Process Browser to search for processes launched for employees Access Digital Personnel File of employees Start HR Services like Master Data transactions PA20, PA30, PA40 for an employee Creation and triggering of a survey to be sent to the employee via email automatically when a service request is completed by the CRM EIC Agent Following figure 4-17 shows the integration aspects in CRM based employee Interaction center. Employee, Manager, HR Admin
Firewall
EIC Agent
R
Employee SelectIon / Verfication
Service Request
Launch Application (https)
Web Client UI R R
Employee Business Partner
Service Request
Business Objects (BOL) CRM (Employee Interaction center)
Business Partner
R
R
R
Setting Employee and Service context (RFC)
HCM Forms & Processes (WD ABAP & Adobe Forms)
Process Object Framework
Personnel Admin. (PA)
R Org Data, Employee Data (ALE)
Service Request Persistency
R
R
R
Self Service UI (WD ABAP)
Personnel Dev. (PD)
HCM Core Appl. SAP ERP HCM Server (Relevant components for EIC are shown)
Process Object Data
HCM Data
Figure 4-17 Architecture of EIC (based on CRM) To achieve a unique work place for the EIC agent there are two integration aspects to be considered: Service request integration and User Interface integration. From the CRM UI service request, HCM Processes can be triggered and an activity object (process object) is created on HCM side. A unique activity object id is created and stored in service request.
© Copyright SAP AG 2010
Internal
195
4 SAP ERP Human Capital Management
SAP ERP
In order to create an entry in the CRM Linked Object table (filled with Object key, Object type and Logical system), callback functionality provided by the Business Suite Foundation layer is used. One of the key technologies for the UI integration of HCM Processes and Forms in CRM Shared Service Framework is Transaction Launcher. It allows HCM P&F applications, which are based on Web dynpro ABAP technology, to be launched within the IC framework. Transaction Launcher along with Navigation Bar Profiles is used in the case of integrating ESS on Behalf scenario and HR Services like PA20, PA30 and PA40 to be launched for an employee within the IC framework. The integration of HR services uses the possibility of CRM IC WebClient to call BOR object methods via navigation bar and transaction launcher. The BOR Objects used are EMPLOYEEIC and BUS1065. Integration of Employee SelfServices is achieved by integrating a URL pointing to a Web Dynpro self-service application into the CRM IC WebClient navigation bar. The authentication functionality includes infotype 0816 (Authentication), Authentication ESS Service and Authentication questions and answers on CRM IC Employee details view. This survey functionality, which is triggered by CRM action when a service request is set to 'Completed', is realized by integrating CRM survey tool, mail form with the service request. It is delivered as part of the new CRM EIC business role IC_EIC_AGENT. Authorizations in the CRM IC are implemented in the Access Control Engine (ACE) based on the employee attributes and CRM IC agent attributes mainly organizational unit, country code, and company code.
4.4.3.3 Architecture of Employee Interaction Center (based on ECC) – up to enhancement package 4 EIC uses the generic functionality provided by IC Web Client. To support EIC-specific functionality three components have been added: employee management, activity management, and inbox and work item management (see figure 4-18). Technically each of these EIC components consists of two parts: Connector which implements the standard interfaces provided by the generic interaction layer of IC Web Client and calls the underlying HCM functionality. Central class with several sub-classes which implements the functionality for employee management, activity management, and inbox and work item management. In the following each component is described in more detail.
196
Internal
© Copyright SAP AG 2010
SAP ERP
4.4 HCM Service Delivery Applications
EIC Agent
R
UI Controllers (BSP pages) Inbox & Work Item Management UI
Employee Management UI
User Interface
Interaction Center Web Client (IC WebClient) R Business Object Layer
Cache
Application Model
R R
Data Container
Generic Interaction Layer
Multi-Channel Management
R Connectors Activity Connector
Inbox Connector
R
Integrated Communication Interface
Employee Connector
R
Telephony/Email/Fax Systems
Activity Management UI
R
EIC Layer Activity Management R
R
Process Object Framework
R
Inbox Management R
HCM Processes and Forms
Employee Management
R
AES Engine
R SAP Business Workflow SAP ERP HCM Server (ABAP)
Activity (Process) Data
HCM Applicaton Data
Figure 4-18 Architecture of EIC (based on ECC)
Employee Management Employee management automatically identifies an employee based on email id or telephone number. It allows to search for employees and to display employee details. Employee management is launched at the beginning of an EIC agent‟s activity. Search functionality is performed using SAPQuery application “Who is Who”. Employee management also handles the interface to the digital personnel file, and launches transaction from personnel administration and ESS using the IC Web Client transaction launcher. Employee management conducts employee satisfaction survey and collects feedback using AES engine.
© Copyright SAP AG 2010
Internal
197
4 SAP ERP Human Capital Management
SAP ERP
Activity Management Activity management is used by the EIC agent to track service requests. The activity business object can handle notes and attachments and provides the functionality for follow-up management, such as forwarding the task to another agent or HR Administrator. Activities are persisted by the process object framework. Activity is finally persisted in SAP NetWeaver Case Management. Process object framework (see figure 4-16) is reused in EIC and HCM processes and forms. Additionally it is possible to start a HCM process and forward the data and attachments from the activity.
Inbox and Work Item Management Inbox and work item management acts as central repository for processing of e-mails, work items, activities, follow-up activities, and Web requests from self-service applications. It provides features like search by different criteria‟s (category, status, date), and substitution. There is also a rule modeler (not shown in diagram) that can automatically handle inbox items like e-mail, web requests, and activities.
198
Internal
© Copyright SAP AG 2010
SAP ERP
4.5 Enterprise Services in HCM
4.5 Enterprise Services in HCM HCM provides synchronous and asynchronous A2X, A2A and B2B enterprise services. Synchronous services are point-to-point whereas asynchronous services are mediated through SAP NetWeaver PI. All synchronous request-confirmation services are idempotent. Exactly-Once-In-Order and Forward Error Handling are supported for asynchronous services. BO-Eventing and other delta mechanisms are provided for several scenarios. All the services are developed considering the SOA Architecture guideline and SOA modeling process. Refer to the Architecture bluebook “mySAP Business Suite Service Provisioning” [SAP07a] for architecture details.
4.5.1 Service Enabling in HCM HCM has been SOA-enabled in the following areas: Personnel administration (PA) Organizational management (OM) Personnel time management Benefits Compensation
4.5.1.1 Personnel administration The Business Partner Data Management process component provides services for queries related to person-specific information on employees. The HCM related business objects modeled here is Employee. The Human Capital Master Data Management process component enables the management of work agreements, employments, and human capital master data that is used in different HCM areas. The business objects modeled here are Work Agreement and Employment. The Personnel Administration process component provides services for personnel management administrative processes that take place within a company. The business objects modeled here are Personnel Leaving and Personnel Hiring. The Competency Management process component enables the company to define, structure, and manage competency. The business object modeled here is Competency.
4.5.1.2 Organizational management The Organizational Management process component provides services for queries relating to information on reporting structure, department hierarchy, and the organizational plan. Through use of HR personnel data, it also provides identification of employee assignment within an organization, and an overview of the organizational
© Copyright SAP AG 2010
Internal
199
4 SAP ERP Human Capital Management
SAP ERP
structure. The HCM related business objects modeled here are Organizational Centre, Position, Company and Cost Centre.
4.5.1.3 Personnel time management The Time and Labor Management process component provides services for management of employees planned working times and recording and valuation of completed activities and absence times. This can include recording and processing requests for leave, displaying time accounts, recording working times, providing functions for automatically recording undocumented working times, displaying the recorded data for an employee‟s information or for reporting of employee times etc. The business objects modeled here are Employee Leave Request, Employee Leave Request Configuration, Employee Time, Employee Time Account, Employee Time Agreement, Employee Time Calendar, Employee Time Event, Employee Time Sheet and Employee Time Sheet Configuration.
4.5.1.4 Benefits The Benefits Administration process component provides services for queries related to the various benefits plans like Health plans, Insurance plans, Savings plans, Credit plans, Miscellaneous plans, Stock purchase plans, Flexible spending accounts and Flexible spending account claims. The business object modeled here is Employee Benefits Administration.
4.5.1.5 Compensation The Compensation Management provides services to query the estimated annual salary of a particular employee, the compensation structure grade to which the employee has been assigned and the long-term incentives that apply for the employee. The business object modeled here are Employee Compensation Adjustment Plan and Employee Compensation Agreement. More detailed information on process components, business objects and service interface and operations can be found at ES Workplace http://esworkplace.sap.com/.
200
Internal
© Copyright SAP AG 2010
SAP ERP
4.6 ERP HCM Further Reading
4.6 ERP HCM Further Reading [Bad07]
Satish Badgi: Practical SAP U.S. Payroll. SAP Press, 2007
[KLR04]
Christian Krämer, Christian Lübke, Sven Ringling: HR Personnel Planning and Development Using SAP. SAP Press, 2004
[KRY06]
Christian Krämer, Sven Ringling, Song Yang: Mastering HR Management with SAP. SAP Press, 2006
[SAP07a]
Office of the CTO (ed.): mySAP Business Suite Service Provisioning. SAP Architecture Bluebook, Version 1.2, March 2007 https://portal.wdf.sap.corp/irj/go/km/docs/guid/60f07fd0-7f4c-2910-2b98-a4ec00df5f74
[SAP07b]
SAP Masterguide: mySAP ERP 2005 powered by SAP NetWeaver 2004s. SAP AG, 2007, https://service.sap.com/~sapidb/011000358700005293822005E
Developer Pages HCM Architecture Wiki https://wiki.wdf.sap.corp/wiki/display/HCMARC/Welcome+to+HCM+Architecture HCM Guidelines and Cookbooks https://wiki.wdf.sap.corp/wiki/display/HCMARC/HCM+Guidelines+and+Documents PA and PD Infotypes at https://bis.wdf.sap.corp/twiki/bin/view/Applications/HcmGuidelinesAndCookbooks
HCM Service Delivery applications ESS/MSS WD Java Parts: https://bis.wdf.sap.corp/twiki/bin/view/Applications/XSSDevelopersCorner ESS WD ABAP Parts: https://wiki.wdf.sap.corp/wiki/display/ESS/Welcome+To+Employee+Self+Service+Wiki HCM Processes and Forms: https://wiki.wdf.sap.corp/wiki/display/HRPF/Home Employee Interaction center https://wiki.wdf.sap.corp/wiki/display/HCMEIC/Home
HCM Extension applications E-Recruiting: https://wiki.wdf.sap.corp/wiki/display/ERECRUIT/Home Enterprise Learning: https://bis.wdf.sap.corp/twiki/bin/view/Applications/LearningSolutionMain
© Copyright SAP AG 2010
Internal
201
4 SAP ERP Human Capital Management
SAP ERP
4.7 ERP HCM Table of Acronyms Term
Definition
AES
Appraisals, evaluation and survey (engine)
EIC
Employee interaction center
ESS
Employee self services
FI
Financials
HCM
Human capital management
KPro
Knowledge provider
LO
Logistics
MM
Material management
MSS
Manager self services
OADP
Object and data provider (framework)
PA
Personnel administration
PCD
Portal content directory
PD
Personnel development
SD
Sales and distribution
202
Internal
© Copyright SAP AG 2010
5 Appendix
5 Appendix
SAP ERP
5.1 ERP OPS Appendix 5.1.1 Material Master Important Transactions MM01-MM03
Material Master Create/Change/Display
MM06
Material Master Flag for Deletion
MM17
Mass Maintenance
MMAM
Change Material Type
Important Tables MARA
General Material Data (Basic data related)
MAKT
Material Descriptions (Additional data related)
MARM
Units of Measure for Material (Additional data related)
MBEW
Material Valuation (Plant related)
MPOP
Forecast Parameters (Plant related)
MVKE
Sales Data for Material (Sales related)
MLGN
Material Data for Each Warehouse Number (Warehouse related)
MLGT
Material Data for Each Storage Type (Warehouse related)
Important Programs Object Name
Usage
Object type
MATERIAL_READ
Read Material data
Function Module
MATERIAL_MAINTAIN_DIALO GUE
Main Program Material Master Maintenance Std
Function Module
MATERIAL_DYNPRO_SEQUE NCE
Screen Sequence Control: Material Master
Function Module
RMMMPERI
Period closing program in material master
Program
GET_DATEN_BILD
Gets buffered data into main function group
Form
BILDFOLGE
Program for Screen Sequence control
Form
MATERIAL_UPDATE_ALL
Update Functions: Material
Function Module
MATERIAL_UPDATE_DB
Update Material Master Data in Database
Function Module
BADI_MATERIAL_OD
Integration of New Objects in Material or Article Master
BAdI
SET_DATEN_BILD
Put the collected and verified data into buffer
Form
204
Internal
© Copyright SAP AG 2010
SAP ERP
5.1 ERP OPS Appendix
5.1.2 Sales and Billing Important Transactions VA01 – VA03:
Create/Change/Display Sales Order
VA21 – VA23:
Create/Change/Display Quotation
VF01 – VF03:
Create/Change/Display Billing Document
VA05, VA25, VF05
:
List Sales Orders, Quotations, Billing Documents
VF04:
Maintain Billing Due List
VF06:
Create Background Job for Billing Processing
VK31-VK33:
Create/Change/Display Condition Records
Important Tables Customer: KNA1
Customer Master Data
KNVK
Customer Contact
KNVV
Customer Sales Data
KNVP
Customer Partner Functions
KNVD
Customer record sales request form
KNVA
Customer Unloading Point
KNVI
Customer Tax Indicator
KNVL
Customer Licenses
KNVS
Customer Shipping Data
Sales Order: VBUK
Sales Order Header Status (also for Billing and Delivery Document)
VBAK
Sales Order Header Data
VBKD
Sales Order Business Data
VBUP
Sales Order Item Status
VBAP
Sales Order Item Data
VEDA
Contract Data
VBEP
Sales Order Schedule Line
VBFA
Sales Order Flow (also for Billing and Delivery Document)
KONV
Conditions (also for Billing Document)
VBPA
Sales Order Partner (also for Billing and Delivery Document)
VBUV
Sales Order Incompletion Log
FPLA
Billing Plan
FPLT
Billing Plan Dates (also for Billing Document)
SADR
Address Management: Company Data (also for Billing and Delivery Document)
(also for Billing Document)
Billing Document: © Copyright SAP AG 2010
Internal
205
5 Appendix
SAP ERP
VBRK
Billing Document Header
VBRP
Billing Document Item Data
EIKP
Foreign Trade: Export/Import Header Data (also for Delivery Document)
EIPO
Foreign Trade: Export/Import Item Data (also for Delivery Document)
Delivery Document: LIKP
SD Document: Delivery Header Data
LIPS
SD Document: Delivery Item Data
Important Programs Object Name
Usage
Object type
SAPMV45A
Sales document: Main program
Program
SAPFV45K
Sales document: Customer data processing
Program
SAPFV45P
Sales document: Item data processing
Program
SD_SALESDOCUMENT_CRE ATE
Create sales document
Function Module
RV_INVOICE_CREATE
Create billing document
Function Module
SAPMV60A
Billing: Dialog processing
Program
SDBILLDL
Billing: Billing due list processing
Program
RV60SBAT
Billing: Create background jobs (Batch)
Program
Further Reading See the SD Knowledge Transfer Folder for further reading: \\dwdferp\erP_ALL\33_ERP_OPS\30_Units\DC3\SD\KnowledgeWare\SD_Know_How_Transfer Also see the training document from course SCM600 “Business Processes in Sales Order Management” for detailed descriptions of Master Data and Processes in SD: \\dwdferp\erP_ALL\33_ERP_OPS\30_Units\DC3\SD\Education\SCM605_DE_Col62.pdf
5.1.3 Production Planning Important Transactions MDBT, MD01
Total MRP Run (Plant level)
MD02
Single-Item, Multi-Level MRP
MD04, MD07
Stock/Requirements List
206
Internal
© Copyright SAP AG 2010
SAP ERP
5.1 ERP OPS Appendix
MD05, MD06
MRP List
MD61 - MD63
Create/Change/Display Planned Independent Requirements
MFBF
Repetitive Manufacturing – Production Confirmation
CO01 – CO03
Create/Change/Display Production Order
CO40, CO41
Convert Planned Orders to Production Orders
CO11N, CO12 - CO16, CO1V
Production Order Confirmations
COR1 - COR3
Create/Change/Display Production Order
COR7, COR8
Convert Planned Order to Process Order
COR6N, CORK, CORR – CORT, CORZ COGI
Process Order Confirmations
Post processing of Error Record form Automatic Goods Movements
Important Tables PLAF
Planned Order
PBED. PBIM
Planned Independent Requirements
AFKO, AFPO
Production/Process Order Header/Item
AFVC
Operation of PP Orders
AFRU
Order Confirmation
AFFW
Goods Movements with Errors from Confirmations
BLPK, BLPP; BLPR
Document Logs for REM Production confirmations
Important Programs Object Name
Usage
Object type
M61X
Determination of the current planning situation (relevant for MD04, all MRP runs, REM planning board, requirement consumption in PP-DEM, etc.)
Function Group
M61Y
Net-requirement calculation, lotsizing for the MRP
Function Group
SAPMM60X
Maintenance of Planned Independent Requirement
Program
M60A
Consumption and reduction of Planned Independent Requirements
Function Group
BARM
Production Confirmation in Repetitive Manufacturing
Function Group
CO
Production Order Processing
Package
COCR
Process Order Processing
Package
CORU
Production Order Confirmation
Package
COCR
Process Order Confirmation
Package
© Copyright SAP AG 2010
Internal
207
5 Appendix
SAP ERP
Further Reading Technical documentation of the PP area: https://wiki.wdf.sap.corp/display/PSupportERPMAN/Product+Support+KB+-+ERP+MAN
5.1.4 Materials Management Important Transactions ME51N
Create Purchase Requisition
ME21N
Create Purchase Order
MIGO
Create Goods Movement
ML81N
Create Service Entry Sheet
MIRO
Create Invoicing Document
Important Tables Purchasing EBAN
Purchase Requisition
EBKN
Purchase Requisition Account Assignment
EKKO
Purchasing Document Header (Request for Quotation, Quotation, Purchase Order, Contract, Scheduling Agreement)
EKPO
Purchasing Document Item (same documents as above)
EKKN
Account Assignment in Purchasing Document
EKET
Scheduling Lines (Purchase Order, Scheduling Agreement)
Inventory Management MSEG
Document Segment: Material
MARC
Plant Data for Material
MARD
Storage Location Data for Material
MBEW
Material Valuation
RESB
Reservation/dependent requirements
MCHB
Batch Stocks
Invoice Verification RBKP
Document Header: Invoice Receipt
RSEG
Document Item: Incoming Invoice
RBCO
Document Item, Incoming Invoice, Account Assignment
RBTX
Taxes: Incoming Invoice
Important Programs Object Name
208
Usage
Object type
Internal
© Copyright SAP AG 2010
SAP ERP
5.1 ERP OPS Appendix
BAPI_PO_CREATE1/ BAPI_PO_CHANGE
BAPIs to create/change Purchase Order
BAPI
MEGUI
UI for enjoy transactions in purchasing
Function Group
MEPO
Business Logic for Purchase Order
Function Group
MEREQ
Business Logic for Purchase Requisition
Function Group
MEOUT
Business Logic for Outline Agreements
Function Group
SAPMM06E
„Old‟ program with UI and Business logic for purchasing document
Module pool
BAPI_ENTRYSHEET_CREAT E
BAPI to create a Service Entry Sheet
BAPI
BAPI_ENTRYSHEET_RELEA SE
BAPI to release/approve a Service Entry Sheet
BAPI
MLSP
Function group with UI and business logic for handling of External Services
Function Group
BAPI_GOODSMVT_CREATE
BAPI to create Goods Movements
BAPI
MIGO
Function group with UI and business logic for goods movement transaction
Function Group
BAPI_INCOMINGINVOICE_C REATE
BAPI to create incoming invoice
BAPI
MR1M
Function group with UI and business logic for invoicing document transaction
Function Group
Further Reading Wikis: Purchasing Services Inventory Management Invoice Verification
5.1.5 Logistics Execution Important Transactions VL01N
Create outbound delivery in dialog (VL02N and VL03N are the related change and display transactions)
© Copyright SAP AG 2010
Internal
209
5 Appendix
SAP ERP
VL10
Mass creation of outbound deliveries
VL06
Delivery monitor
LT03
Create warehouse management (WM) transfer order
LT12
Confirm WM transfer order
LS24
List of warehouse stock per material
VT01N
Create shipment (VT02N and VT03N are the related change and display transactions)
VT04
Create shipments in collective processing
VT20
Transport Execution Monitor
Important Tables Delivery Processing (LE-SHP) LIKP
Header data for deliveries
LIPS
Item data for deliveries
VBUK*
Header status information for deliveries
VBUP*
Item status information for deliveries
VBPA*
Delivery partners
)* These tables are commonly used by sales orders, deliveries and billing documents Warehouse Management (LE-WM) LTAK
Header data for WM ransfer orders
LTAP
Item data for WM transfer orders
LAGP
Storage bin (master data, describing the physical structure of the warehouse)
LEIN
Storage units (movement data, describing movable units in the warehouse which could be stored in bins)
LQUA
Quant (movement data, holds the actual stock information for a certain material in a certain storage unit or storage bin)
Transportation (LE-TRA) VTTK
Header data for shipments
VTTP
Item data for shipments
VTTS
Stage of a shipment
Important Programs Delivery Processing (LE-SHP) Object Name
210
Usage
Object type
Internal
© Copyright SAP AG 2010
SAP ERP
5.1 ERP OPS Appendix
SAPMV50A
Modul pool to control the delivery dialog, main program for delivery processing
Module pool
SAPFV50P
FORM routines for delivery item processing
FORM routine pool
SAPFV50W
FORM routines interfacing to inventory management
FORM routine pool
GN_DELIVERY_CREATE
Create deliveries of different types in background
Function module
RV_DELIVERY_CREATE
Create sales order related deliveries in background
Function module
WS_DELIVERY_UDPATE_2
Updates existing deliveries in background
Function module
Package VL contains most of the objects which are relevant for delivery processing. Warehouse Management (LE-WM) Object Name
Usage
Object type
SAPML03T
Module pool for dialog processing of transfer orders
Module pool
L_TA_HINZUFUEGEN
Function module for creating a transfer order
Function module
L_TA_QUITTIEREN
Function module for confirming a transfer order
Function module
Most of the relevant programs can be found in package LVS. Transportation (LE-TRA) Object Name
Usage
Object type
SAPMV56A
Module pool to control the shipment dialog
Module pool
SD_SHIPMENT_CREATE
Function module for creating a shipment
Function module
SD_DELIVERY_ASSIGN_TO_SHIP MENT
Function module to assign deliveries to a certain shipment
Function module
Package VTR contains most of the objects related to shipment processing; package VTRA contains objects related to shipment costs which is one important function within transportation.
Further Reading Documentation in SAP Library: http://help.sap.com/erp2005_ehp_03/helpdata/en/cb/973735ec50d33de10000009b38f889/frameset.htm
© Copyright SAP AG 2010
Internal
211
5 Appendix
SAP ERP
5.1.6 Quality Management Important transactions QM01
Creation of a quality notification
QA03
Display inspection lot
QE51n
Result recording for inspection lot operation
QA11
Usage decision for inspection lot
CWBQM
Inspection planning with engineering workbench
Important Tables QMAT
Material Data: QM inspection data (Master data)
PLMK
Inspection plan characteristics (Master data)
QPMK
Master Characteristic (Master data)
QMEL
Quality notification
QALS
Inspection lot
QAVE
Usage decision
Important Programs Object Name
Usage
Object type
IQS0
Maintenance of quality notification
Function group
QPL1
Maintenance of inspection lot
Function group
QEEM
Result recording
Function group
QAAT
Interface to other components
Function group
SAPMQEVA
Usage decision
Dialog program
CL_PLM_AUDIT_APPLICATIO N
Audit management application
Class
CL_PLM_FMEA_APPLICATIO N
FMEA application
Class
CQCL
Maintenance of inspection plan characteristics with engineering workbench
Function group
CL_RPLM_QI_API_RECORD RESULTS
Result recording API for role quality inspector
Class
Further Reading Knowledge Warehouse documentation for core quality management http://help.sap.com/saphelp_erp60_sp/helpdata/en/a6/df293581dc1f79e10000009b38f889/frameset.htm Knowledge Warehouse documentation for audit management http://help.sap.com/saphelp_auditmgmt/helpdata/EN/index.htm
212
Internal
© Copyright SAP AG 2010
SAP ERP
5.1 ERP OPS Appendix
Documentation on the SAP Portal under Business Suite Organization -> Products -> ERP -> ERP Corporate Services -> Quality Management https://portal.wdf.sap.corp/irj/portal?NavigationTarget=navurl://dd276bc5aa58c19a28181e00a7c25c66
© Copyright SAP AG 2010
Internal
213
5 Appendix
SAP ERP
5.2 ERP FIN Appendix 5.2.1 Accounting Interface Important Tables ACCTHD
Accounting Interface Header Information
ACCTIT
Accounting Interface Items Information
ACCTCR
Accounting Interface Currencies Information
Important Programs Object Name
Usage
Object Type
RWCL
Accounting Interface Functions
Function Group
AC_DOCUMENT_RECORD
Display Accounting Documents
Function Module
AC_DOCUMENT_SENDER
Display source/sending/original document
Function Module
AC_DOCUMENT_CREATE
Create Accounting Documents
Function Module
AC_DOCUMENT_POST
Post Accounting Documents
Function Module
Further Reading SAP Documentation: Interfaces to Accounting (AC). http://help.sap.com/saphelp_erp60_sp/helpdata/en/6c/089cb556c511d18ef20000e8366fc2/frameset.htm
5.2.2 Financial Accounting Important Tables T000
Client
T001
Company code
SKA1/ SKB1
List of GL Accounts at Chart of Accounts / Company Code level
LFA1/LFB1
List of Vendors General / Company code Data
KNA1/KNB1
List of Customers General / Company code Data
BKPF
Accounting Document Header
BSEG
Accounting Document Line Item
BSET…
Tax Line items
BSI* / BSA*
Index Tables for AP/AR/GL on accounting document and Item
GLT0/LFC1/KNC1
Account totals for GL/AP/AR
FAGLFLEXA
Accounting Document Line Item in NewGL (Customizing Dependant)
FAGLFLEXT
Accounting totals for GL in NewGL (Customizing Dependant)
214
Internal
© Copyright SAP AG 2010
SAP ERP
5.2 ERP FIN Appendix
Important Transactions FS01-03
GL Account Create/Change/Display
FD01-03
Customer Create/Change/Display
FK01-03
Vendor Create/Change/Display
FB01-03
Accounting Document Create/Change/Display
FB01L
Accounting Document Create to specific Ledger/Ledger Group
FS10N
Display GL Balances in Classic GL
FK10N
Display Vendor Balances in Classic GL
FD10N
Display Customer Balances in Classic GL
FAGLB03
Display GL Balances in NewGL
FBL*N
Line item Display
FAGLL03
New GL Line item Display
FB1S/K/D
Clear GL/Vendor/Customer open items
F110
Automatic Payment
F150
Dunning
F123/F124
Automatic Clearing
FB05
FI posting and clearing transaction
FBZ1/F-28
incoming payments
FBZ2/F-53
outgoing payments
FB1S/F-03
G/L account clearing
FB1D/F-32
customer account clearing
FB1K/F-44
vendor account clearing
FBA1
customer down payment request
FBA2
customer down payment
FBA3
customer down payment clearing
FBA6
vendor down payment request
FBA7
vendor down payment
FBA8
vendor down payment clearing
F.13
automatic clearing program
FB02
change FI document
FB03
display FI document
FBV1
park FI document
FBV2
change parked FI document
FBV3
display parked FI document
FB60
post vendor invoice
FB70
post customer invoice
FB50
post G/L document
F110
automatic payment program
F150
dunning program
© Copyright SAP AG 2010
Internal
215
5 Appendix
SAP ERP
Important Programs Object Name
Usage
Object Type
SAPMF05*
FI Posting and Clearing
Module pool
G_BEB_SPLIT_DOCUMENT
NewGL Splitter
Function module
SAPMF05B
Open item selection
Module pool
SAPFF001
service routines for SAPMF05A/B
Module pool
SAPMF05L
Document change and display
Module pool
SAPF110*
Automatic payment program
Module pool
SAPF124
Automatic clearing program
Module pool
SAPF150*
Dunning program
Module pool
RFUMSV00/10
VAT tax reporting
Report program
RFUMSV25
Deferred tax reporting
Report program
FACI
Financial accounting interface
Function group
FACS
Financial accounting interface services
Function group
RWCL ; FACG
Accounting interface
Function group
RWFI
Direct input
Function group
TAX1; TAX2
FI Tax calculation
Function group
GLT0
FI-SL, NewGL
Function group
F005
FI Update function modules
Function group
GBAS
GL and SL Basis
Package
FBZ
Payment
Package
GLT0
GL
Package
GLT0
GL/SL/NewGL functions
Function Group
Further Reading SAP Documentation: Financial Accounting (FI). http://help.sap.com/saphelp_erp60_sp/helpdata/en/51/df293581dc1f79e10000009b38f889/frameset.htm
5.2.2.1 Asset Accounting Important Tables ANEK
Document Header for Asset Posting
ANEP
Document Line Items for Asset Posting
ANLC
Asset Totals per Asset, Depreciation Area and Fiscal Year
ANEA
Asset lines for retirements and retiring transfers
216
Internal
© Copyright SAP AG 2010
SAP ERP
5.2 ERP FIN Appendix
ANLB
Depreciation Terms for each asset
ANLA
Asset master
Important Transactions AS01-03
Asset Create/Change/Display
AB01-03
Asset Transaction Create/Change/Display
AW01N
Asset Explorer
AFAB
Execute Depreciation Run
ABT1N
Intercompany Asset Transfer
ABUMN
Transfer Asset within Company Code
AJAB
Asset Year End Closing
Important Programs Object Name
Usage
Object Type
AB
Asset Accounting Package
Package
Further Reading SAP Documentation: Asset Accounting. http://help.sap.com/saphelp_erp60_sp/helpdata/en/4f/71d9f6448011d189f00000e81ddfac/frameset.htm
5.2.2.2 Special Purpose Ledger Further Reading SAP Documentation: Special Purpose Ledgers. http://help.sap.com/saphelp_erp60_sp/helpdata/en/d5/6ada3889432f48e10000000a114084/frameset.htm
5.2.3 Financial Supply Chain Management 5.2.3.1 Collection Management Important Tables UDM_WL_ITEM
Worklist items data
UDM_COL_ITEM
Customer data transferred from FI system
UDM_STRATEGY
List of Strategies used.
FDM_P2P_ATTR
Attributes of Promise to Pay; Required for Process Integration
Important Transactions UDM_SUPERVIOR
View the Worklist items
UDM_SPECIALIST
View the Worklist items
UDM_GENWL
Generate Worklist
© Copyright SAP AG 2010
Internal
217
5 Appendix
SAP ERP
UDM_STRATEGY
To simulate a Worklist item for a business partner.
FDM_COLL01
Customer list - Process receivables.
MDS_LOAD_COCKPIT
Synchronization of customer - BP
UDM_BP
Creation and editing of Business partner
Important Programs Object Name
Usage
Object Type
FDM_COLL_SEND_ITEMS
Transfers data from FI
Function Module
FDM_P2P_JUDGE
Program for evaluating open promise to pay
UDM_GEN_WORKLIST
Generate Worklist
Function Module
UDM_BUPA_TRANSACTION_DATA UDM_WORK_LIST UDM_STRATEGY
Packages for Collection Management Module
Package
Further Reading SAP Documentation: SAP Collections Management (FIN-FSCM-COL). http://help.sap.com/saphelp_erp60_sp/helpdata/en/40/e16240067cc44ce10000000a1550b0/frameset.ht m
5.2.3.2 Dispute Management Important Tables SCMG_T_CASE_ATTR
Contains Case Attributes
UDMCASEATTR00
Holds Dispute Case Attributes
FDM_DCOBJ
FSCM-DM
FDM_DCPROC
FSCM-DM Integration: Dispute Case Processes
Integration: Disputed Objects
Important Transactions UDM_DISPUTE
Launch Dispute Management
Important Programs Object Name
Usage
Object Type
FDM_AR_DOC_DISPUTE_BUILD
Building up of a dispute case.
Function Module
UDM_DC_CREATE
Creates dispute case and insertion of objects to Records management.
Function Module
UDM_WORKFLOW UDM_CORRESPONDENCE
Packages for Dispute Management Module
Package
218
Internal
© Copyright SAP AG 2010
SAP ERP
5.2 ERP FIN Appendix
FDM_AR UDM_GENERAL
Further Reading SAP Documentation: SAP Dispute Management for FI-AR (FIN-FSCM-DM). http://help.sap.com/saphelp_erp60_sp/helpdata/en/9a/abcf16aad5934395e1f5913866e9de/frameset.htm
5.2.3.3 Biller Direct Further Reading SAP Documentation: Electronic Bill Presentment and Payment Purpose). http://help.sap.com/saphelp_erp60_sp/helpdata/en/43/72fc28e1356fcae10000000a1553f6/frameset.htm
5.2.3.4 Credit Management Further Reading SAP Documentation: Credit Management http://help.sap.com/saphelp_erp60_sp/helpdata/en/99/5351403ab46f13e10000000a1550b0/frameset.htm
5.2.4 Treasury 5.2.4.1 Treasury and Risk Management Important Transactions JBDO
Maintain Financial Object
TPM60
Save NPV values
JBRX
NPV Single Value Analysis
AISS
Sensitivity Key Figures
RMV0
Value at Risk Display of Single Values
RMTD
Transaction Selection Display
RAEP1
Determination of Single Records
RAEP2
Determination of Final Results
AIS_STDREP
Analyser Information System
KLNACHT
End of Day Processing
KLNACHT2
Postprocessing
TBLB
Utilizations Overview
TBL1
Maintain Limits
TLM0
Drilldown Reporting
S_KFM_86000165
SAP Query Overview of Limits
S_KFM_86000166
SAP Query Overview of Limits Utilization
PAEP1
Portfolio Analyzer Determination of Single Records
© Copyright SAP AG 2010
Internal
219
5 Appendix
SAP ERP
PAEP2
Portfolio Analyzer Determination of Final Results
PAEPBM
Calculate Benchmark Keyfigures
JBRT_CFM
ALM
JBRTOBJ_CFM
ALM Single Value Analysis
Simulation
Further Reading PS KB – Financial Services: SEM Banking. https://wiki.wdf.sap.corp/wiki/display/PSupportFinServ/SEM+Banking (SAP-Internal WIKI) SAP Community Network WIKI: Treasury and Corporate Finance Management. https://wiki.sdn.sap.com/wiki/display/ERPFI/Treasury+and+Corporate+Finance+Management SAP Documentation: SAP Treasury and Risk Management (TRM). http://help.sap.com/erp2005_ehp_04/helpdata/EN/08/a9e139709ba63be10000000a114084/content.htm Sönke Jarré, Reinhold Lövenich, Andreas Martin, and Klaus G. Müller: SAP Treasury and Risk Management. SAP Press, April 2008
5.2.4.2 Cash Management Important Tables FDD1
Cash management and Forecast : Loan line items-Memo Records
FDES
Cash Management and Forecast: Memo Records
FDI1
Cash Management Line Item for RE Classic Planning Records
FDLF
Cash Management Line Items for Agency Business
FDM1
Cash Management & Forecast: Line Items of MM Documents
FDM2
Cash management line items from MM purchase requisitions
FDMV
Cash Planning Line Items of Earmarked Fund
FDRE
Cash Management Line Items from RE-FX (Real Estate)
FDS1
Cash Management & Forecast: Line Items of SD Documents
FDS2
CM&F Line Items in SD Documents
FDSB
CMF Totals Records for G/L Accounts
FDSP
Cash Management Adjustment Items from Document Splitting
FDSR
CMF Totals Records for Planning Groups
FDT1
CMF Line Items for Forex, Money Market, Derivatives
FDW1
Cash Mgt and Forecast - Securities Line Items- Planned Flows
FDZA
Cash Management line items in payment requests
FDLF2
Cash Management Line Items for Agency Business (As of 604)
FDSB2
CMF Totals Records for G/L Accounts (As of Release 604)
FDSR2
CMF Totals Records for Planning Groups (As of Release 604)
FDSRDIST
Cash management totals records for planning groups (distbd)
FDSBDIST
CMF Totals Records for G/L Accounts (distributed)
FDESDIST
Cash management memo records (distributed)
220
Internal
© Copyright SAP AG 2010
SAP ERP
FDFIEP
5.2 ERP FIN Appendix
CM: FI Line Items (OP of Deb/Cred for Drilldown)
Important Transactions FDFD
Cash Management Implementation Tool
FF/8
Import Bank Statement into Cash Mgmt
FF/9
Compare Advices with Bank Statement
FF63
Create Planning Memo Record
FF65
List of Cash Management Memo Records
FF67
Manual Bank Statement
FF68
Manual Check Deposit Transaction
FF6A
Edit Cash Management Position Payment Advices
FF6B
Edit liquidity forecast planned item
FF70
Cash Management Position / Liquidity Forecast
FF71/ FF7A
Cash Position
FF72
Liquidity forecast
FF73
Cash Concentration
FF74
Use Program to Access Cash Concentration
FF7B
Liquidity forecast
Important Programs Object Name
Usage
Object Type
FF
Cash Management Package
Package
Further Reading SAP Documentation: SAP Cash Management. http://help.sap.com/erp2005_ehp_04/helpdata/EN/8b/0e3d4014fa6f13e10000000a1550b0/frameset.htm
5.2.4.3 Liquidity Planner Important Tables FLQITEMFI
Liquidity Calculation - Line Items for Other FI Documents
FLQITEMBS
Liquidity Calculation - Line Items for Bank Statement Docs
FLQHEADMA
Liquidity Calculation - Header for Manual Transfer Postings
FLQITEMMA
Liquidity Calculation - Line Items for Manual Transfers
FLQSUM
Liquidity Calculation - Totals Records
FLQITEMFI_FC
Liquidity Calculation - Forecast Line Items for FI Documents
FLQITEMPO_FC
Liquidity Calculation - Forecast Line Items for MM Pos
FLQITEMSO_FC
Liquidity Calculation - Forecast Line Items from Sales Orders
FLQSUM_FC
Liquidity Calculation - Forecast Totals Records
FLQCLNT
Liquidity Calculation - Global Settings
© Copyright SAP AG 2010
Internal
221
5 Appendix
FLQASSET
SAP ERP
Liquidity Calculation - Settings for FI Mechanisms
Important Transactions FLQC2
Global Data
FLQC13
Settings for FI Mechanisms
FLQC4
Other Actual Accounts
FLQC7
G/L Accounts Relevant for Query
FLQINFACC
G/L Accounts w/ Liquidity Item Info
FLQAB
Assignment from Bank Statement Info.
FLQAC
Assignment from FI Information
FLQAD
Assignment from Invoices(Transaction Currency)
FLQAL
Assignment from Invoices(Local Currency)
FLQAM
Manual Assignment
FLQT1
Create Transfer Posting
FLQREP
Payment Report
FLQLI
Line Item List
FLQLS
Totals List
Important Programs Object Name
Usage
Object Type
FFLQ
Liquidity Planner Package
Package
Further Reading SAP Documentation: SAP Liquidity Planner. http://help.sap.com/erp2005_ehp_04/helpdata/EN/47/f23d4050d89523e10000000a1550b0/frameset.htm Stephan Kerber and Dirk Warntje: Cash Accounting and Cash Flow Planning with SAP Liquidity Planner. SAP Press, November 2005
5.2.4.4 In House Cash Important Tables IHC_DB_PN
IHC Payment order
BKKIT
Payment items
BKKITGL
General Ledger: Payment Item Data
BKKM1
Bank Statement Data
TBKKIHB1
Central incoming: Account determination from payment notes
TBKKIHB6
Central incoming: Account determination from ext. bank account number
IHC_DB_CL_XBS
Central incoming: Determine sender/clearing partner
222
Internal
© Copyright SAP AG 2010
SAP ERP
5.2 ERP FIN Appendix
Important Transactions IHC1IP
Create internal IHC payment order
IHC1EP
Create external IHC payment order
IHC0
Payment order browser
F9K3
Display: IHC account master data
F9HL
Balance sheet preparation
F9HI
GL transfer: transfers current account balance to FI general ledger
IHCCM1
Transfer IHC Financial Status to Cash Management
F9H4
Cash concentration run
F996
Account balancing run
F9N7
Bank Statement Generation
Important Programs Object Name
Usage
Object Type
FIN_IHC
In House Cash Package
Package
IHC_APPL_PROCESS
Payment Order Posting
Report Program
IHC_APPL_ARCHIVE_READ
IHC: Archiving, Reload Program
Report Program
IHC_APPL_ARCHIVE_WRITE
IHC Payment Orders Archiving: Write Program
Report Program
IHC_CHECK_BKKM1
Check bank statements begin/end balance
Report Program
Further Reading SAP Documentation: SAP In-House Cash (FIN-FSCM-IHC). http://help.sap.com/erp2005_ehp_03/helpdata/EN/34/239739f4e38a2ce10000000a11402f/frameset.htm
5.2.5 Debit Credit in Financial Accounting In the Accounting System the transaction entries are recorded with double entry principle. The double entry means that the transactions are always recorded using two sides debit and credit. „Debit‟ refers to the „left side‟ and „credit‟ refers to the „right side‟. The sum of debit sides must always be equal to the sum of credit sides. Then and only then the transaction is called „balanced‟. The representation is as in the Figure 5-1
© Copyright SAP AG 2010
T Accounts,
Internal
223
5 Appendix
SAP ERP
Account
Debit
Cash Account
Credit
100 EUR
T Account Representation
Supplies
100 EUR
Step 2
Step 1
Figure 5-1
T Accounts
Since the representation of Debit and Credit looks like the letter „T‟, this is also known as T Account. If we take an example of a business transaction where we buy some supplies (stationary) for our office by shelling out some amount of cash, the representation is as in Step 1 and Step 2 respectively for Cash and the Supplies accounts. The transaction of buying supplies is balanced as the sum of the debit and credit are equal to 100 EUR. Now the next question would be why we credit the cash and debit the supplies when we expect it the other way in normal understanding that a debit is something „outgoing‟? That‟s not true in accounting principles. It follows the rule as represented in the following table, Type of Account
To Debit the respective account
To Credit the respective account
Personal (Vendor, Customer etc)
Debitor (Customer)
creditor (Vendor)
Real (tangible) (Cash, Asset etc)
When the account gets in money or equivalent
When the account gives out money or equivalent
Nominal or Profit and Loss (Income, Expense etc)
All Expense accounts
All Income accounts
Another easy way to remember is, Personal Accounts
Real Accounts
Nominal Accounts
C – Credit
G - Giver
O – Outgoing
I – Income
D – Debit
R - Receiver
I - Incoming
E - Expense
That could be remembered as CGOI and DRIE for PRN accounts. That should be read as Credit the Giver (Vendor is the one who gives you) Debit the receiver (Customer is the one who receives from you) Credit the outgoing
224
Internal
© Copyright SAP AG 2010
SAP ERP
5.2 ERP FIN Appendix
Debit the Incoming Credit Income Debit Expense
© Copyright SAP AG 2010
Internal
225
5 Appendix
SAP ERP
5.3 ERP HCM Appendix 5.3.1 Software Components in SAP HCM From development perspective SAP HCM is split into the following software components (see figure 5-2): SAP ERP 6.0 (Relevant Software components for SAP ERP HCM)
LSO(AC) 600
LSO(OP) 600
Front-end Desktop Applications (Java)
EP Content Business Packages SAP ESS 600
XI Content 600
SAP MSS 600
LSO(CP) 600
PCUI_GP 600 Relevant Software Components for HCM Applications on NW 7.0 (Java)
ABAP ADD-Ons ECC-SE 600 (ESOA Services)
E-Recruiting 600
LSOFE 600 (Front End)
EA-HR 600
SAP-HR 600
SAP-APPL 600
BI Content 7.0
SAP ECC 600 (Relevant Software Components for HCM Applications) on NW 7.0 (ABAP)
Figure 5-2
Software Components used in SAP ERP HCM
SAP-HR 600 - which includes the core SAP HCM functionality such as PA and PD EA-HR 600 – extension for adding new functionality to core HCM E-Recruiting 6.0 – recruiting application which can be installed separately or on the same server LSO(FE) 600, LSO(AC) 600, LSO(OP) 600 – learning solution (e-learning) components SAP ESS 6.0 and SAP MSS 6.0 – self service applications for ESS, MSS,
226
Internal
© Copyright SAP AG 2010
SAP ERP
5.3 ERP HCM Appendix
SAP_APPL 600 – cross HR applications like CATS SAP_ABA(700) and SAP_BASIS(700) which include reusable components such as AES engine, PD infotype framework, and so on All new developments of SAP ERP HCM are implemented in the EA-HR software component. SAP-HR component that contains the core functionality is now mainly used for minor enhancements and as well to keep the product updated from legal functionality (mainly in PA and payroll). E-recruiting and enterprise learning are also available as separate products. With enhancement package concept some of these software components have new release versions (e.g. EA-HR 605 in release suite 2010). In all enhancement packages normally the Software component EA-HR is opened for development and has a new release version. SAP_HR is not opened for development every enhancement package unless there are major changes. Other application specific component are opened case to case basis.
5.3.2 PD Objects in HCM and Organizational Management Figure 5-3 shows the object data model used in HCM and organizational management structure. The diagram covers only the important objects and relationships. There are many other relationships possible between objects which are not depicted here.
Otype K Cost Center Is Assigned To B011
Otype T Task
Cost Center assignment A011
Describes A007
Is Described By B007
Belongs to A003 Otype O Organizational Unit
Incorporates B003 Otype S Position
Manages A012
Is Candidate For A650 Has Candidate B650
Is Filled By A209 Otype CP Central person
Is Identical To A207
Otype C Job
Is Managed by B012 Holder B008
Otype NA E-Rec Candidate
Describes A007 Is Described By B007
Has employment contract B209
Holder A008
Otype P Person (Employee Work Agreement)
Is Identical To A208 Otype US User Is Identical To B208
Is Identical To B207
Otype BP Business partner Note: Rounded Box represents External Objects
Figure 5-3
© Copyright SAP AG 2010
PD Objects in HCM and Organizational Management
Internal
227
5 Appendix
SAP ERP
5.3.3 PD Objects in E-Recruiting Figure 5-4 shows the PD object data model used in e-recruiting. The details of infotypes that are important for PD objects are mentioned, too. Otype BP Business partner
Is Identical To B207
Is Identical To A207
Is Filled By A209 Otype US User
Is Identical To A208
Otype CP Central Person
Has employment contract B209
Is Identical To B208
Results in occupation Of B657
Holder B008
Holder A008 Is Candidate For A650
Otype P Person (Employee Work Agreement)
Otype S Postition
Has Candidate B650
Is occupied by means Of A657 Applies For B653
Has Application A651 Otype ND Application
Otype NA Candidate Is Application From B651
Ha Is
Is Member Of A658 Is assigned To B658
Ca
nd
s
id
Ca
ac
y
nd
id
B6
ac
y
Has Candidacy A6 56 A655
Otype NC Posting
Application By A653
Is Candidacy B655
Is posted Via B652 Posts A652
56
Is candidacy For A654 Otype NE Candidacy
Otype NF Talent Group
Has Candidacy B654
Otype NB Requisition
Note: Rounded Box represents External Objects
Figure 5-4
PD Objects in E-Recruiting
5.3.4 Business Object Models in SOA Figure 5-5 shows the business object models Employee, Work Agreement and Employment. The diagram covers only the important objects and relationships. There are many other relationships possible between objects which are not depicted here.
228
Internal
© Copyright SAP AG 2010
SAP ERP
5.3 ERP HCM Appendix
Employee Work Agreement Employee
Work Agreement
Common
Communication Data Assignment Yes
Nationality
Address Assignment
Address Information
Communication Data
Competency
Competency CompetencyVal uation
CompetencyEvidence
Work Agreement Employment
Employment
Company
Employment
Work Agreement
Capacity Utilisation Level
Company Position Employment
Organisational Assignment
Employee
Employee
Figure 5-5
Position
Address Assignment
Personnel Area
Communication Data Assignment
Personnel Area
Personnel Sub Area Assignment
Organisational Assignment Position Assignment
Business Object Models in SOA
More detailed information on process components, business objects and service interface and operations can be found at ES Workplace: http://esworkplace.sap.com
© Copyright SAP AG 2010
Internal
229