S/4 HANA conversion functional value proposition
8 likes3,922 views
The document outlines the features and benefits of SAP S/4HANA, a revolutionary business platform built on in-memory technology that enables real-time data analysis and improved enterprise resource management. It details various enhancements in areas such as procurement, inventory management, and reporting, highlighting simplified data models, faster performance, and improved user experiences. Additionally, it discusses changes in operational processes, such as authorization management and master data handling, with the aim of streamlining workflows and increasing efficiency across business operations.
S/4 HANA conversion functional value proposition
- 1. S/4 HANA Conversion Functional Value Proposition By Vignesh Bhatt
- 2. What is SAP HANA ? A Revolutionary Business Platform - Future ready SAP HANA in memory platform • SAP HANA is the engine of the real time enterprise, enabling clients to analyze large quantities of data from virtually any source in real time. • This example showcases actual customer performance of a core reporting process. Experience real time enterprise in action • SAP HANA analyzes current point of sale data in real time, empowering this organization to review segmentation, merchandizing, inventory management and forecasting information at speed of thought. Hours before S/4 HANA Runs 3600x faster In seconds with SAP HANA 460 Billion records 50 Terabytes of data 70 net alerts 0.04 seconds Analysis response time On any device, anywhere, anytime Speed Innovation Agility Simplicity Any data Cloud Insight Applications Value
- 4. SAP HANA the great simplifier of enterprise software SAP HANA SAP Simple Finance powered by SAP HANA SAP Business warehouse powered by SAP HANA SAP Business Suite powered by SAP HANA SAP S/4 HANA In memory platform • Real time analysis •Real time reporting •Real time business •OLAP and OLTP together •SAP HANA Enterprises •Cloud for SAP Business Suite on SAP HANA •Instant financial insight •No aggregates •Single source of truth •Simplified data model •New user experience •Advanced processing •Choice of deployment
- 5. A logical evolution each being necessary to provide significant new business capability and escape the constraints of the past. R/2 R/3 R/4 S4 HANA 1979 Mainframe 1992 Client S server 2004 Web SOA 2015 IoT APIs Mobile
- 6. Phase 1 Start Release Phase 2 Prerequ isites Phase 3 Editions Phase 4 Business Case Phase 5 Project Type SAP S/4 HANA Migration path SAP ERP < 6 SAP NW x.x. Non Unicode DB SAP ERP < 6 SAP NW x.x. Any Unicode DB Legacy Any DB SAP ERP 6 EHP 0 + SAP NW 7.4 Unicode Any DB SAP ERP 6 EHP 7 + SAP NW 7.4 + SAP HANA Simple Finance SAP ERP 6 EHP 7 +SAP NW 7.5 + SAP HANA SAP Business Suite SAP Business Suite SAP Business Suite SAP Business Suite SAP Business Suite Unicode Conversion One Step Migration SAP S/4 HANA on premise SAP S/4 HANA Cloud B P G Brownfield Phased Greenfield Data Migration Custom code Remedian Architecture Complexity Business model changes Conversion effort
- 7. Some Facts about SAP S/4 HANA 1. Built on SAP HANA 2. ERP, CRM, SRM, SCM PLM in one system. 3. No locking, parallelism. 4. Actual data (25%), and historical (75%). 5. Unlimited workload capacity. 6. Predict, recommend, simulate. 7. SAP HANA Cloud Platform extensions. 8. SAP HANA multi-tenancy. 9. All data : social, text, geo, graph processing. 10. New SAP Fiori UX for any device (mobile, desktop, tablet). Three deployment options : on-premise, public cloud, managed cloud. 10x Smaller data footprint 1800x Faster reporting and analytics 4x Less process steps 7x Higher throughput 200x Faster response in end- end process
- 10. Authority Concept for Supplier Invoice The previous concept was based on checking header data against the item authorization object for all items. The system checked for all items if a user was allowed to complete certain activities in the plants. In S/4 HANA With the new concept, the behaviour of the system is more comprehensive. The new concept introduces a header authorization object that enables the system to perform the following authorization checks: • Check header data against the header authorization object (M_RECH_BUK). This authorization object checks the common activities a user performs for the header company code. • Check item data against the item authorization object (M_RECH_WRK). This authorization object checks the common activities a user performs for the plant for the respective item. Business Value The new authority concept for supplier invoice enables a simplified handling especially for invoice items w/o PO reference. ` ` In ECC
- 11. Foreign Trade within SAP S/4 HANA Procurement Currently there are two services for international trade transactions : •Foreign trade (FT) •SAP Global Trade Services (GTS). In S/4 HANA • Foreign Trade : • Global Trade Services is successor for business requirement. •Additional functions for import and export management are available with SAP GTS. Business Value • Strategic Decision to remove FT and inculcate GTS. •Selected international trade functionalities to be provided with foreign trade in S/4 HANA. ` ` In ECC
- 12. RFQ Simplified Transaction • RFQ with mandatory supplier field. •Only possible to enter one supplier quote per RFQ. •Not possible to integrate with different Sourcing Integration Scenarios like Ariba Sourcing, Ariba Spot Quote etc. In S/4 HANA • Send RFQ via FIORI app to external sourcing platforms without supplier included . • Multiple supplier quotes can be received. •Existing transaction codes like ME41, ME42, ME43, ME49, ME4B, ME4C etc. is planned to be replaced with corresponding FIORI apps. Business Value • Flexibility • Excess use of Transaction Codes ` ` In ECC
- 13. Vendor evaluation based on LIS • Vendor evaluation reporting based on tables and structures. • Real time supplier evaluation not available. In S/4 HANA • SAP HANA reporting capabilities based on CDS views. Business Value • Real time supplier evaluation capabilities without building and referring to table and structure aggregates. • Provides much more analytical visualization options as LIS. ` ` In ECC
- 14. Output management adoption in Purchase Order • Configuration through NACE. • Cannot use Adobe Forms • Smartforms and SAP Script is largely used. In S/4 HANA • Includes cloud qualities such as extensibility enablement, multi tenancy enablement and modification free configuration. • Output management based on NAST. • Business Rule Framework (BRF+) is used. • Target architecture is based on Adobe Document Server and Adobe Forms only. • Form Determination rules BRF+ is used. • Supports Channels, PRINT, EMAIL, XML (for Ariba Network Integration). Business Value • Unified solution can be used for all Output Management activities. • Due to BRF+ many integration issues resolved. •Additional capabilities of BRF+ apart from Output Management. ` ` In ECC
- 15. Logistics `
- 16. New advanced ATP in SAP S/4 HANA – Table VBBS • Database table VBBS contained pre- aggregated sales requirements. •The requested (OMENG) and confirmed (VMENG) quantities aggregated on a daily basis. In S/4 HANA • Do not need pre-aggregation anymore. Table is obsolete. • Instead of VBBS, we use VBBE where each ATP-relevant requirement is explicitly stored. •Old ERP-ATP check code is also redirected to use VBBE. •New entries automatically “choose” to use VBBE instead VBBS. Business Value • Aggregate data in real time. • Aggregate-table for sales order requirement VBBS not necessary anymore. ` ` In ECC
- 17. Blocked customer or supplier in IM • End of purpose check for customer and supplier master data. In S/4 HANA • Material documents related to customer or supplier to be blocked must be archived. • Special stocks related to customer or supplier to be archived or deleted. • Physical inventory documents related to customer or supplier to be blocked must be archived. • Open reservations related to customer or supplier to be blocked must be deleted. •The customer or supplier to be blocked must be removed from plant data. Business Value • Redundancy of data reduced. • SAP offer SI check to identify blocked customer or supplier. • Faster approach. • Flexibility ` ` In ECC
- 18. Data model in Inventory Management • MKPF table used for document header • MSEG table used for document item data. • Aggregated actual stock quantity data stored in several tables. • Material master data stored in tables like MARC, MARA,MARD and MCHB. In S/4 HANA • De-normalized table used called MATDOC which contains former header and item data of material document as well as lot of other attributes too. • Material document data will be stored in MATDOC and not in MKPF and MSEG. • Actual stock quantity data will be calculated on the fly from MATDOC. • System will work on database level in an INSERT only mode without DB locks. • For compatibility reasons, Core Data Services (CDS) views are assigned as proxy objects to all those tables. Business Value • Simple and fast reporting since most of the information is all in one place. ` ` In ECC
- 19. Availability of transactions in MM-IM • MB transactions are used like MB01 to MB05, MB0A, MB11, MB1A to MB1C, MB31, MBNL, MBRL, MBSL, MBST and MBSU. • MMBE_OLD is used. In S/4 HANA • “MB transactions” replaced by a single- screen generalized transaction called “MIGO”. • MMBE_OLD replaced by transaction MMBE. Also FIORI App stock overview is also available. Business Value • MB Transaction codes should not be used in customer coding. •MB transaction codes will become obsolete in near future. • No need to remember lot of transaction codes. •Coding simplified for Z-Reports. ` ` In ECC
- 20. Material Ledger Obligatory for Material Valuation • Material ledger not mandatory . • Inventory valuation tables used EBEW, EBEWH, MBEW, MBEWH, OBEW, OBEWH, QBEW and QBEWH. In S/4 HANA • Material ledger mandatory to be activated. • xBEW(H) tables will only store material master data attributes. • Transactional fields will be retrieved from Universal Journal Entry Line Item table ACDOCA and the Material Ledger table. • CDS views are assigned as proxy objects. • In MM02 and MR21, material prices can now be maintained in multiple currencies. •In financials, inventory account balances are calculated for each currency. Business Value • More flexible valuation method in multiple currencies and parallel accounting standards. • System resources reduced. •Scalability of business process improved. •Find actual cost component splits of materials. •Cleaner and more consistent valuation in other currencies than local currencies. ` ` In ECC
- 21. Performance optimizations within Material Document processing – lock beh • Lock strategy for materials was not required. In S/4 HANA • No locks on DB level. • Parallel execution of material document processing. • Early lock strategy : All master data and quantities are read in an array fetch before the item processing (except for special stocks) and exclusive locks are set during entire processing of material document. • Late lock strategy : No exclusive locks are set in this process. It will be set for only short duration of time during item processing for each specific item. This will be converted into shared lock after checks for stock underrun. •Locks on batches : This protects parallel changes of batch master and it reduces collision rate of parallel material document postings for batch material line items. Business Value • Consistency with material master data. • Use of lock strategies to enhance business process and bring more clarity. •Lock can be set on material, plant, storage location, stock identifier, special stock identifier level. ` ` In ECC
- 22. BOM, Routing, Production Version • Production version not mandatory in ECC for BOM, Routing etc. In S/4 HANA • Production version are mandatory in S/4 HANA, MRP, planned order creation for correct BOM explosion. • Production order creation only find a BOM and routing alternative if a production version is maintained for BOM and routing alternative. Business Value • Production version allow to define which BOM alternative goes together with which routing alternative. • Mandatory production version make MRP sourcing simpler. • No need to control MRP sourcing with additional control indicators like selection method MARC-ALTSL in material master. •Production version is mandatory in PP/DS. ` ` In ECC
- 23. MRP in HANA • MRP run determines expected material shortages and creates planned orders, PR or delivery schedule lines to cover expected material shortages. •During STO from one plant to another stock transfer requirement is not known in supplying plant until after the material has been planned in receiving plant. In S/4 HANA • MRP Live is a feature newly introduced in S/4 HANA. •MRP Live reads material receipts and requirements, calculates shortages and creates planned orders and PR all in one database procedure. •This minimizes volume of data that has to be copied from database server to application server and back, hence improving performance. • Planning scope is more flexible with MRP Live, allows you to plan a set of materials with all components across all plants. •For stock transfer requirements, MRP Live determines sequence in which materials have to be planned across several plants. •MRP Live is prerquisite for future production planning and detailed scheduling PP/DS solution. Business Value • Production version allow to define which BOM alternative goes together with which routing alternative. • Mandatory production version make MRP sourcing simpler. • No need to control MRP sourcing with additional control indicators like selection method MARC- ALTSL in material master. •Production version is mandatory in PP/DS. •Classic MRP still available as interim solution, but not considered as future technology. ` ` In ECC
- 24. MRP in HANA (contd…) ` Difference between MRP Live and Classic MRP • MRP live does not write MRP lists. • Multi-level, make-to-order planning (transaction MD50) is not optimized for HANA. • Individual project planning (transaction MD51) is not optimized for HANA. • The creation indicator for purchase requisitions is not available in MRP Live. MRP Live always creates purchase requisitions if the material is procured externally. • The creation indicator for delivery schedule lines is not available in MRP Live. MRP Live always creates delivery schedule lines if a valid delivery schedule exists.
- 25. Forecast Based Planning • In forecast based planning (MRP type VV) the MRP creates planned orders or purchase requisitions , if total forecast demand up to a certain point of time exceeds the total confirmed, the receipt quantity up to the same point of time. The total firmed receipt quantity includes inventory, production orders, purchase orders, firmed planned orders, and firmed purchase requisitions. •Forecast based planning is a simple planning procedure, which does not require managing planned independent requirements. In S/4 HANA • MRP live does not perform forecast based planning in HANA but sends the affected materials into the classic ABAP planning procedure. • The system records all changes of planned independent requirements which facilitates reporting . • The system records all changes of planned independent requirements which facilitates reporting Business Value • Not much of a change from existing Forecast based planning. ` ` In ECC
- 26. Demand Forecasting • Classic demand forecasting copies the consumption history into an ABAP application server, performs the forecasting algorithm in ABAP and writes the result back into the database. • Copying data between database server and ABAP application server takes time. In S/4 HANA • HANA has a built in library of forecasting algorithms, which could be utilized for forecasting material demand. A future demand forecasting solution will probably perform the forecasting algorithm in HANA utilizing HANA's forecasting library. • Transactions MP30, MP31, MP32, MP33, MP38, and MP39 are still available in SAP S/4HANA. Business Value • Faster forecasting • Better algorithms • In line with future technology of forecasting material demand. ` ` In ECC
- 27. PP-MRP- Subcontracting • Planning subcontracting demand together with internal demand in the make- to-stock planning section . • Separating subcontracting demand and stock into single subcontracting planning sections (one section per subcontractor) and planning uncovered subcontracting demand together with internal demand in the make- to-stock planning section. • Planning separately the demand of every subcontractor by means of subcontracting MRP areas. In S/4 HANA • Separate planning of every subcontractor is possible without having to create an MRP-area-specific material master record . • The planning logic is simplified. There are two rather than three different ways to plan parts to be provided to a subcontractor. Business Value • Master data maintenance simplified. • Sophisticated planning functionality for subcontracting components using subcontracting MRP area without necessity to maintain appropriate material master data. • Reduction of modeling alternatives for the planning and evaluation processes for the procurement of subcontracting components. ` ` In ECC
- 28. Master Data `
- 29. Logistics Batch Management • Currently transactions being used for batch management is MSC1, MSC2, MSC3 and MSC4. In S/4 HANA • New T-codes to be used for batch management is MSC1N, MSC2N, MSC3N and MSC4N. Business Value • Only transaction code related changes, not much impact on business process. ` ` In ECC
- 30. Business Partner BUT000 / Header Level Time Dependency • Currently there is no scope of time dependency. • Suppliers and customers created through T-codes XK01 to XK03, XD01 to XD03. In S/4 HANA • Activation of time-dependency available for customers through configuration. Business Value • Time dependency functionality has been disabled at header level of BUT000 in SAP S/4 HANA to ensure that there are no inconsistencies in the master data. ` ` In ECC
- 31. Business Partner hierarchy not available In S/4 HANA • Business partner hierarchy is not accessible. • Transactions not available : BPH, BPH_TYPE. • BAPIs not available : BUHI_ASSIGN_BP_TO_NODE , BUHI_CLEAR_BUFFER, BUHI_DELETE_BP_FROM_NODE • IMG activity node not available : BP Group Hierarchy. •BOR Object not available : BUS1006004 Business Value • Business partner hierarchy is removed in SAP S/4 HANA to avoid redundancy as customer hierarchy is already available for the applications to consume. `
- 32. Business Partner Tax Classification BUT_FRG0011 is deactivated • Tax classification maintained at two levels : • Business Partner ( BUT_FRG0011). • Customer (KNVI) In S/4 HANA • To ensure data consistency, now it is maintained only at one of the levels. • Tax classification must be maintained for a BP using Customer role (FLCU01) as Customer Tax Classification and NOT at BP level. Hence BP tax classification for all roles is now deactivated. Business Value • When BP tax classification is activated : • Users can maintain tax classification at business partner and customer level. • Tax classification data needs to be duplicated. • Results in inconsistency of data. • When BP tax classification is de-acticvated : • Users can maintain Tax Classification level at only CUSTOMER LEVEL. • Tax Classification data will NOT be duplicated. • Data remains consistent. ` ` In ECC
- 33. Business Partner Approach In S/4 HANA • Transactions obsolete : Series of FD*, FK*, MK*, MA*, V-*, VA*, VD*, XD*, XK*. • Transaction code available : BP • While creating consumer, use BP grouping associated to customer account group – TBD001. Customer itself is a contact person. • One time supplier/ customer : BP grouping to be used TBD001 and TBC001. Business Value • BP is leading object and single entry point to maintain BP, customer and supplier. • BP allows maintenance of multiple addresses with corresponding address usage. • BP allows multiple roles to be associated to same BP. • Max. data sharing and reuse of data leads to easier data consolidation. • General data available for all different BP roles, specific data is stored for each role. • Maintenance of multiple relationships to same BP. • Maintenance of time dependency at different sub-entities roles, address etc. ` • One customer can only be associated to one account group. • General data not available for customer or supplier. • Complex data consolidation. • No concept of Business Partner , mostly non-existent. ` In ECC
- 34. Material Number Field Length Extension In S/4 HANA • Material number field length extended from 18 to 40 characters. • Coding automatically adopts to domain changes with respect to material number length used in existing report logics. • Pure material numbers is still restricted to 18 characters. • Changes is compatible for BAPIs, IDocs and released remote-enabled function modules. Business Value • Alpha numeric material numbers can now be created as per the requirement of the client. ` • Material number field length is only 18 digits. ` In ECC
- 35. Foreign Trade fields in Material Master In S/4 HANA • The Foreign Trade functionality as part of Sales & Distribution is not available within SAP S/4HANA. The functional equivalent in SAP S/4HANA is SAP Global Trade Services (GTS). • The below mentioned fields for Letter of Credit/ Legal control/ Export control/ Preference management in Foreign Trade is supported by GTS from S/4HANA and not through Material Master: • CAP product list no. (MARC-MOWNR) • CAP prod. group (MARC-MOGRU) • Preference status (MARC-PREFE) • Vendor decl. status (MARC-PRENE) • Exemption Certificate (MARC-PRENC) • Exemption Cert. No. 9 (MARC-PRENO) • Issue date of expiry certificate (MARC-PREND) • Military goods (MARC-ITARK)
- 36. MRP fields in Material Master In S/4 HANA • SAP S/4HANA simplification is done on the following tabs in transaction MM01/02/03. • Lot Size data in MRP1 Tab: o Unit of Measure Group (MARC-MEGRU) • Procurement in MRP2: MRP considers quota arrangements always, henceforth it is not required to switch it on in the material master. o Quota arr. usage. (MARC-USEQU) • BOM explosion /dependent Requirement tab in MRP4 o Selection Method (MARC-ALTSL) • Repetitive manufacturing /assembly /deployment strategy tab of MRP4 o Action control (MARC-MDACH) o Fair share rule (MARC-DPLFS) o Push distribution (MARC-DPLPU) o Deployment horizon. (MARC-DPLHO) • Storage Location in MRP4 o SLoc MRP indicator (MARD-DISKZ) o Spec.proc.type SLoc (MARD-LSOBS) o Reoder Point (MARD-LMINB) o Replenishment qty. (MARD-LBSTF) • Also the backend database fields for these "omitted functionality" remains existing in the system.
- 37. Material Type SERV In S/4 HANA • Material type "SERV" for services is introduced for Product Master in S/4HANA for simplification purposes . • Material type SERV, some fields and departments that are irrelevant in S/4 are hidden from the screen. This gives all transactions relevant for material master, a leaner and simplified look. •A new material type SERV (Service Materials) is created with reduced user departments and fields in the classical transactions: MM01/MM02/MM03. • Supported user departments : Accounting, Purchasing, Basic Data and Sales. • The other user departments are hidden for Material Type “Service Materials”.
- 39. Why Simple Finance ?? • SAP S/4 HANA is minimizing the redundancy and complexity of existing system by consolidating multiple tables into single table. Example: Earlier there are two tables for document header and for line items, now those are consolidated. Importance- Simple finance come across the following constraints in ECC: •On time closure of financials •Easy way of reporting •Cloud storage, Cloud computing •Access the data from multiple sources like ( PC / Tab and even from mobiles) •Easier way of reconciliation between finance and controlling by introduction of secondary cost elements as GL’s. •GL creation (FS00) ends up with cost element creation. Cost element screen now available in FS00 itself. •Accounting based COPA now its easier at the same time we can use costing based COPA also. `
- 40. Customer Benefits : •Harmonized internal and external reporting. •Significantly reduced reconciliation effort. •Significantly reduced memory consumption. •Higher flexibility in reporting and analysis. •Central journal for heterogeneous system landscapes. Example of massive simplification : SAP Accounting powered by S4 HANA Stability Flexibility Pre defined aggregates FI Document CO Document Total and Indices Financial Accounting Total and Indices Management Account Processing Analytics Logisitics Document Stability Flexibility Processing Analytics Logisitics Document FI Document CO Document Aggregation on the fly via HANA views From… To… Logical Document
- 41. •Example on How Account based COPA is easier by using simple finance? Currently COPA data is storing in COEP table and it contains multiple tables like CE1XXXX, CE2XXXX, CE3XXXX, CE4XXXX, now all the data will be stored in a single table named ACDOCA. It is easier to build reports using the ACDOCA Table. Secondary cost element as a GL Account:
- 42. Replaced Transaction codes and programs in FIN In S/4 HANA Old Functionality Type New Functionality Type Text FS01 TA FS00 TA Create G/L Accounts FS02 TA FS00 TA Change G/L Accounts FS03 TA FS00 TA Display G/L Accounts CK11 TA CK11N TA Create Product Cost estimate CK13 TA CK13N TA Display Product Cost estimate CK41 TA CK40N TA Create Costing Run CK42 TA CK40N TA Change Costing Run CK43 TA CK40N TA Display Costing Run CK60 TA CK40N TA Preselection for Material/Plant CK62 TA CK40N TA Find Structure: BOM Explosion CK64 TA CK40N TA Run: Cost Estimate of Objects CK66 TA CK40N TA Mark Run for Release CK68 TA CK40N TA Release Costing Run CK74 TA CK74N TA Create Additive Costs KB11 TA KB11N TA Enter Reposting of Primary Costs KB21 TA KB21N TA Enter Activity Allocation KB31 TA KB31N TA Enter Statistical Key Figures KB33 TA KB33N TA Display Statistical Key Figures KB34 TA KB34N TA Reverse Statistical Key Figures KB51 TA KB51N TA Enter Activity Posting KE21 TA KE21N TA Create CO-PA line Item KE23 TA KE24 TA Display CO-PA line item KKE1 TA CKUC TA Add Base Planning Object KKE2 TA CKUC TA Change Base Planning Object KKE3 TA CKUC TA Display Base Planning Object KKEC TA CKUC TA Compare Base Object - Unit Cost Est KKED TA CKUC TA BOM for Base Planning Objects KKB4 TA CKUC TA Itemization for Base Planning Obj. KKBF TA KKR0 TA Order Selection (Classification)
- 43. Replaced Transaction codes and programs in FIN In S/4 HANA Old Functionality Type New Functionality Type Text KKPHIE TA CKMDUVMAT/CKMDUVACT (Distribution) TA Cost Object Hierarchy KKP2 TA CKMDUVMAT/CKMDUVACT (Distribution) TA Change Hierarchy Master Record KKP4 TA CKMDUVMAT/CKMDUVACT (Distribution) TA Display Cost Object Hierarchy KKP6 TA CKMDUVMAT/CKMDUVACT (Distribution) TA Cost Object: Analysis KKPX TA CKMDUVMAT/CKMDUVACT (Distribution) TA Actual Cost Distribution: Cost Obj. KKPY TA CKMDUVMAT/CKMDUVACT (Distribution) TA Actual Cost Distribution: Cost Obj. RAGITT01 PROG S_ALR_87011990 TRAN Asset History Sheet FAGL_FC_VAL TA FAGL_FCV TRAN Foreign Currency Valuation S_E38_98000088 TA Profit Center Group: Plan/Actual/Dif FIORI Profit Center - Plan/Actual (Fiori-ID: F0926; Query: /ERP/SFIN_M01_Q2701) S_E38_98000089 TA Profit Center Group: Plan/Plan/Actual FIORI Profit-Center - Plan/Actual current year (Fiori-ID: F0932; Query: /ERP/SFIN_M01_Q2702)
- 44. Asset Accounting In S/4 HANA • New G/L accounting gets automatically activated, if currently classic G/L accounting is used. • Actual values from tables ANEP, ANEA, ANLP, ANLC are saved in table ACDOCA in new Asset Accounting. The values from table ANEK are saved in tables BKPF and ACDOCA in new Asset Accounting. Postings are still made to table BSEG. • Statistical data and plan data: o Statistical values (for example, for tax reasons) from tables ANEP, ANEA, ANLP and ANLC, are saved in new Asset Accounting in table FAAT_DOC_IT. o Planned values from tables ANLP and ANLC are saved in table FAAT_PLAN_VALUES in new Asset Accounting.
- 45. Asset Accounting : Parallel Valuation and Journal Entry In S/4 HANA • Can map parallel valuations with ledger approach or accounts approach. A mixture of two is not supported (ledger with accounts approach). • One can record the leading valuation of Asset Accounting in any depreciation area of new Asset Accounting. It no longer necessary to use depreciation area 01 for this. The system now posts both the actual values of the leading valuation and values of parallel valuation in real time. •Delta depreciation is no longer required and supported. • One can post in real time in all valuations (for all accounting principles). • One can track posting of all valuations without taking into account the postings of leading valuation as was the case in Asset Accounting. • Asset Accounting is based on Universal Journal Entry, so no redundancy of any data store. • Reconciliation postings are no longer necessary with closing operations as General Ledger Accounting and Asset Accounting are reconciled permanently anyway due to the universal journal entry. • The hitherto existing periodic posting run for APC values is redundant. • Postings for group assets are redundancy-free.
- 46. Asset Accounting : Parallel Valuation and Journal Entry In S/4 HANA • The migration must take place at a time when only one fiscal year is open in Asset Accounting. Once migration is completed, you are not allowed to open any fiscal year again that occurred before the migration in Asset Accounting. • You cannot reverse documents that were created before the conversion from classic to new Asset Accounting. Instead, you have to make an inverse posting. • It is not possible to reverse integrated asset postings that were posted in new Asset Accounting in SAP enhancement package 7 for SAP ERP 6.0, SP02 or higher and were migrated. Instead, you have to make an inverse posting. • If until now you updated transactions in parallel valuations with different fiscal year variants and want to continue using this update, then you must implement a new representative ledger using the SAP General Ledger Migration Service. • It may no longer be possible to process worklists that have been created before the changeover to the new Asset Accounting. This involves worklists that create transaction data (however, not master data changes), such as worklists for retirement without revenue, retirement with revenue, intercompany asset transfer, and impairment posting. You should therefore either process these worklists before you activate the Customizing switch, or create them again once you have activated new Asset Accounting. • New transactions : AB01L, ABAAL, ABAKL, ABAOL, ABAVL, ABAWL, ABGFL, ABGLL, ABIFL, ABMAL, ABMRL, ABNAL, ABNEL, ABNKL, ABSOL, ABSTL, ABUML, ABZEL, ABZOL, ABZPL, ABZUL . • Obsolete transactions : ABSO_OLD, ABST, ABST2, ABSTL, ABUB, AW01_AFAR, ABF1, ABF1L, AJRW, OASV, AB02, ASKB, ASKBN, ABB1, ABMW and ABCO.
- 47. Cash Management In S/4 HANA • Centralized bank account management is supported. • Bank accounts can be replicated via IDoc to other systems. •Fuzzy search for bank accounts. • Attachments • FIORI apps applicable. •Bank hierarchy based on Business Partners. • Data Integration with MM& SD • Liquidity Forecast •Actual cash flow and cash flow detailed analysis. • Maintaining house bank accounts not available. Business Value • Flexibility • End-to-End process of monitoring bank statements imports, checking cash position and transferring fund to handle surplus and deficit. • Medium term liquidity forecast and rolling plans of long term liquidity. • Centralized bank account management, with which business users can manage bank accounts as master data with more business attributes. ` • Create Bank : FI01 • Change Bank : FI02 • Display Bank : FI03 • House Bank / Account : FI12 • Business Partner (Role TR0703) : BP • Transaction codes : FF63, FF65, F110, F111. ` In ECC
- 48. Controlling In S/4 HANA • Creation of cost estimates with reference to base planning objects is not supported. • Use transaction CKECP to prepare ad-hoc cost estimates and CKUC to prepare multilevel material cost estimates where BOMs and routings are not available for material in question. • Currently using base planning objects to store cost estimates that can be included in cost estimates for projects, SO and so on as items of type Base planning objects. ` In ECC
- 49. Technical changes in Material Ledger with Actual Costing Business Value / S4 HANA • Reduce complexity and improve runtime in Material Ledger Costing Cockpit for Actual Costing. • Separate process steps like Single level price determination, Multilevel price determination, Revaluation of Consumption, WIP Revaluation are merged to one process step called Settlement. • New 2-dimensional distribution logic to avoid rounding errors. • Less “Not distributed” values. • No lock conflicts caused by material movements (in current period). • Change of standard price for materials and activities within the period is supported. • Separate currency customizing of Material Ledger (Tx OMX2/OMX3) is obligatory. • No default Material Ledger type ‘0000’ anymore.
- 50. Technical changes in Material Ledger with Actual Costing (contd..) Business Value / S4 HANA • It is not allowed to use a ML Type that references to currency settings defined in FI or CO (flags ‘Currency Types from FI’ resp. ‘Currency Types from CO’). Instead you have to define explicitly the currency and valuation types that are relevant for Material Ledger. • The new Material Ledger Document tables MLDOC and MLDOCCCS replace most former periodic tables (MLHD, MLIT, MLPP, MLPPF, MLCR, MLCRF, MLKEPH, CKMLPP, CKMLCR, MLCD, CKMLMV003, CKMLMV004, CKMLPPWIP, CKMLKEPH) • The design of tables MLDOC/ MLDOCCCS allows storing both line item and aggregated data. • Single- and multilevel differences are no longer distinguished. In table MLDOC all price/exchange rate differences are stored in fields PRD/KDM. In table MLDOCCCS the CCS for price/exchange rate differences are stored under the CCS types E/F (field MLCCT). • The CCS is stored in a table format using the cost component (field ELEMENT) as additional key. This allows increasing the number of cost components without modification.
- 51. Technical changes in Controlling Business Value • Total records for primary and secondary costs have been removed and universal journal includes all actual cost postings, both primary and secondary. • For primary postings, all general ledger items with assignment to cost centers, orders, WBS etc are treated as one data record which is enriched with relevant profit center, functional area etc. • For secondary postings, all sender- receiver relationships that are triggered by allocations, settlement are captured in universal journal along with partner profit centers, functional area etc. • Actual data of COEP (WRTTP=’04’) is now stored in ACDOCA. • Actual statistical data of COEP (WRTTP=’11’) is stored in ACDOCA using additional columns and in COEP for compatibility access. • Actual data needed for long term orders/projects from COSP_BAK, COSS_BAK is stored in table ACDOCA. • COBK is written as before. • Access to old data in tables is still possible via the views. ` In S/4 HANA
- 52. Profitability Analysis Business Value • The universal journal (ACDOCA) is heart of Accounting and includes all Profitability Analysis (CO-PA). • All revenue and cost of goods sold postings are automatically assigned to relevant CO- PA characteristics at time of posting. • Automatic derivation of CO-PA characteristics can reduce number of settlements and allocations to be performed at period close and provide real time visibility into spending during the period. • No reconciliation issues between G/L and Profitability Analysis. • COGS postings are captured at time of GI from WH. Splitting of COGS posting to multiple accounts is possible. • Production order variances can be split to multiple accounts to separate scrap, price variances, quantity variances etc. In S/4 HANA /
- 53. Currencies in Universal Journal In S/4 HANA • Central currency configuration for universal journal. • Combined view cluster for ledgers and currencies, tx FINSC_LEDGER. • Second and Third parallel currencies of FI (BSEG-DMBE2 or BSEG-DMBE3) correspond to 2 amount fields of KSL-GSL according to config in tx FINSC_LEDGER. • Table BSEG will not be extended and still contains only 3 parallel currencies. • Currency types in customer name space are not allowed as BSEG relevant currency. Business Value • All journal entry items are converted in accounting interface for all configured currencies, regardless of source where the business transaction originates from. ` • There are 3 parallel currencies in FI (T001A/ tx OB22) and 2 parallel currencies in CO (TKA01/ tx OKKP). • The currencies of non leading ledgers in NewGL (T882G) were a subset of currencies in leading ledgers (T001A). • One of CO currencies needed to be local currency (CT 10), but it was not necessary that the other currency in CO was also configured in FI. ` In ECC