segunda-feira, 28 de janeiro de 2019

SAP S/4HANA vs ECC MRP Essential Changes

SAP introduced new changes to MRP (Material Requirement Planning) in SAP S/4HANA. I would like to present the major changes SAP S/4HANA vs ECC MRP.
The following items are the main impact in S/4HANA MRP.

MRP in S/4HANA – Storage location MRP
In SAP ERP, storage locations can be excluded from MRP planning, or they can be planned separately from other storage locations.
As MRP area covers the very same business requirements, the solution location functionality is a subset of the MRP area’s capabilities. Materials with MRP area-specific MRP type ND – no MRP can be used instead of materials with a storage location excluded for MRP.
In SAP S/4HANA, the master data maintenance has been simplified, and modeling alternatives for similar functions of the MRP planning on storage location level have been reduced.
The SAP S/4HANA MRP only plans on plant and MRP area level. Planning on storage location level is not available in SAP S/4HANA.

MRP in SAP S/4HANA – MRP Area
SAP ERP, you need to activate the MRP areas in customizing for MRP transaction OM01. SAP S/4HANA systems, MRP area is active by default and cannot be deactivated.
PP-MRP subcontracting, the master data maintenance has been simplified in SAP S/4HANA. The planning logic and evaluation process for the procurement of the subcontracting component is simplified in SAP S/4HANA. By using the subcontracting MRP area, SAP S/4HANA provides separated planning of every subcontractor, without having to create MRP area/supplier-specific material master data.
Basically, there are three types of MRP area in SAP S/4HANA.
  1. Plant MRP area contains a whole plant. MRP area for storage locations.
  2. MRP area for storage locations consists of a particular storage location. Material requirements
    for this storage location are then planned separately from the plant.
  3. MRP areas for vendor created for subcontractor vendor. In the case of SAP S/4HANA
    system, it is recommended to create subcontracting MRP areas for every subcontractor.

MRP in SAP S/4HANA – Simplified sourcing
In material requirements planning, the SAP S/4HANA system calculates material shortages, then the lot size, and then it determines the sourcing of supply. The sourcing determines whether the required
quantity is manufactured or purchased, and if purchased, from which supplier.
In SAP ERP, the sourcing logic is defined at different places with an asymmetrical definition for purchasing and manufacturing. The basic idea of this simplification is a reduced set of possible sources of supply with a clear and symmetrical definition that does not require any additional settings in the material master or in the customizing.
In addition, quote arrangements are always considered if they exist.
SAP S/4HANA supports the following types of sources of supply. If the material is manufactured, production versions are the only valid source of supply. If the material is purchased, delivery schedules, purchasing contracts, and purchasing for records are valid sources of supply, even without using source list records. If you want MRP to source a purchase requisition from a certain supplier, you no longer have to define a source list entry.
It is sufficient to set the indicator relevant for automatic sourcing in the purchasing info records. If sourcing determines several valid sources of supply for the same material, plant, quantity, and date, but does not find any quote arrangements, then it prefers production versions over delivery schedules, delivery schedules over purchasing contracts and purchasing contracts over purchasing for records.

MRP in SAP S/4HANA – Production version
In SAP S/4HANA for manufacturing, the production versions are the only valid source of supply. So, the production versions are mandatory in SAP S/4HANA.
MRP planned order creation and production order creation only find a bill of material and routing
alternatives, if the production version is maintained for them. The mandatory production versions make MRP sourcing simpler, as there are only the options to determine bill of material and routing alternatives for a manufactured material.
These production versions are already mandatory in PP/DS, and PP/DS as part of the SAP
S/4HANA product. The production versions make sourcing MRP and PP/DS more similar.


Best Regards,
Lingaiah


Source: https://blogs.sap.com/2018/10/27/sap-s4hana-vs-ecc-mrp-essential-changes/

SAP S/4HANA 1809 Release Update: Production Planning and Execution Migration to S/4 – Summary

Level 1: Easy ; 20 minute read
Audience: Subject Matter Experts
Author: Teresa Tay, SAP S/4HANA RIG APJ
Introduction
This blog provides an overview of the key changes that are required or should be considered for MRP when performing a system conversion from SAP ERP to SAP S/4HANA.
Functional Pre-checks before conversion to S/4HANA on premise
  • Pre-Transition has to be executed before the convert to S/4HANA
    • Implement this note. 2216435 – Pre-checks for PP-MRP. The checks will be executed during the transition process
  • Pre-conversion check for storage location migration report.
    • Pre-upgrade check for PP-MRP functionality when preparing upgrade to S4H determined that there are some materials in the system having field DISKZ set to 1 or 2 in table MARD. This means such materials had to be excluded from planning or planned separately by means of this setting. In S4H a different way is used to achieve the same goal: a material has to be assigned to a storage location MRP Area which is either excluded from planning, or is planned separately. Therefore to keep your scenarios running as before, a conversion of the data is needed.
    • The report MRP_AREA_STORAGE_LOC_MIGRATION delivered with note 2216528 can give more details about missing storage location MRP Areas. Missing storage location MRP Areas will have to be created manually
    • Link to note http://sap.com/sap/support/notes/2216528
    • Report MRP_AREA_STORAGE_LOC_MIGRATION will perform all the necessary checks one more time and if all the customizing settings are correct, will generate the missing MRP area assignments to your materials
  • Further refer  to:
  • To check if you are using any of the deleted or adjusted ABAP development objects in your customer coding refer sap note http://service.sap.com/sap/support/notes/2227579

BOM and Routing migration to Production Version
  • As of SAP S/4HANA, on-premise edition 1511, the functional relation between Bill of Material (BOM), Routing and Production Version has changed.
  • BOM Explosion for Manufacturing BOM will depend on Production Versions only. Manufacturing BOM determination can only happen via production version. Refer SAP Note 2267880 for further details .
  • The customizing that determines the items valid for BOM explosion now has the default value ‘2’ (Version with latest valid-from date). This customizing is available under Production -> Basic Data -> Bill of Material -> Control Data for Bills of Material -> Define Modification Parameters
 

  • It is recommended to migrate BOMs, for which there is no corresponding routing using report CS_BOM_PRODVER_MIGRATION. It is recommended to migrate BOMs, for which there exist corresponding routings using report
  • The migration of data for existing BOM selection methods like (a)selection by order quantity, (b)selection by explosion date, (c) selection by production version and (d) selection by only production version all need to unify into a production version approach. A migration report merging all such data and associating it to a new/existing production version is necessary.
  • Refer to notes 2194785 2201551.

MRP in HANA
SAP S/4HANA features MRP Live; an MRP run optimized for SAP HANA. MRP Live reads material receipts and requirements, calculates shortages, and creates planned orders and purchase requisitions all in one database procedure. This minimizes the volume of data that has to be copied from the database server to the application server and back, which considerably improves performance. MRP Live has some additional advantages including the following, for example:
  • The definition of the planning scope is more flexible. MRP Live allows you to plan a set of materials with all components, materials for which a certain production planner is responsible, or one material across all plants.
  • If a material is transferred from one plant to another then the stock-transfer requirement is not known in the supplying plant until after the material has been planned in the receiving plant. MRP Live determines the sequence in which materials have to be planned across several plants.
  • MRP Live is a prerequisite for the future production planning and detailed scheduling PP/DS solution in SAP S/4HANA.
Classic MRP is still available as an interim solution (Functionality available in SAP S/4HANA on-premise edition delivery but not considered as future technology. Functional equivalent is available), which at the moment has to be used for creating MRP lists.
For more details, refer to SAP note 2268085 – S4TWL – MRP in HANA
Planning File
In the classic Business Suite, reports RMMDVM10 and RMMDVM20 made a first setup of planning file entries and checked planning file consistency for operative planning. In SAP S/4HANA, run report PPH_SETUP_MRPRECORDS instead. For long-term planning, the reports RMMDVL10 and RMMDVL20 are replaced by the report PPH_SETUP_MRPRECORDS_SIMU.
SAP S/4HANA, on-premise edition no longer supports net change planning in the planning horizon (processing key NETPL). MRP always determines material shortages for all known material requirements. MRP can no longer cover only the material shortages inside a limited planning horizon. This is valid both for the classic MRP and MRP Live.
After the system conversion, you should run report PPH_SETUP_MRPRECORDS to populate the new planning file table with operative MRP records (PP-MRP) and the report PPH_SETUP_MRPRECORDS_SIMU for simulative MRP records (PP-MP-LTP).
Total Dependent Requirements
BOM explosion creates dependent requirements for all component materials needed to manufacture a material. Total dependent requirements create locking problems if the same component material is used in the BOM of different materials. MRP live creates very many planned orders in parallel. Locking conflicts would impair parallel processing and total MRP runtime.
Business processes are not changed. MRP reads individual dependent requirements rather than total dependent requirements. Refer to note https://launchpad.support.sap.com/#/notes/0002268089
Follow the instructions for “Clean up Total Requirements” in the SAP help portal (Link)
MRP areas for Subcontractors
 Simplified Sourcing
 Work In Progress Batches (WIP)
  • The Mill specific Process Batch functionality is not available in SAP S/4HANA and is replaced by the core solution WIP Batch (Work in Process Batch)
  • It is required to use/convert to WIP Batch functionality in SAP S/4HANA.
    • Please refer to SAP Note 2326769 for migration from process batch to WIP batch.
    • Please refer to SAP Note 2346054 for information on enhancement to support order combination with WIP Batch.
 Job Scheduling
  • You are doing a system conversion to SAP S/4HANA, on-premise edition
  • SAP S/4HANA contains a new component which automatically schedules certain technical background jobs. Deleting or modifying such jobs manually (via transaction SM37) will not have a lasting effect since the automation mechanism will re-schedule these jobs with predefined attributes
  • In SAP S/4HANA, this manual action has been replaced by an automatic mechanism, the Technical Job Repository. SAP S/4HANA Technical Job Repository takes care of scheduling (and de-scheduling) necessary standard jobs (as defined and delivered by SAP) automatically, without any user intervention
  • For more details please refer following notes
 I hope you enjoyed this blog and are able to articulate new features released with SAP S/4HANA 1809 FPS00.
 Additional Information
 SAP S/4HANA Discovery
 SAP Knowledge Management
Further reading in this S/4HANA RIG Plan to Product blog series
  • N/A

Brought to you by the S/4HANA RIG


Source: https://blogs.sap.com/2019/01/24/sap-s4hana-1809-release-update-production-planning-and-execution-migration-to-s4-summary/

quarta-feira, 23 de janeiro de 2019

Understanding launchpad object relationship with screenshots

After you create a custom app or extend a standard Fiori app, tile is required for launching the app.
Here are screenshots explain the launchpad objects relationship.
A0.png
  1. User -> Role (Transaction: SU01)
  2. Role -> Catalog/Group (Transaction: PFCG)
  3. Catalog/Group -> Tile (launchpad designer)
  4. Tile -> Intent ( launchpad designer, Tile)
  5. Semantic Object (Transaction: /UI2/SEMOBJ and /UI2/SEMOBJ_SAP)
  6. Intent -> Application Alias (launchpad designer, Target Mapping)
  7. Application Alias -> App URL (in LPD_CUST)
    Application Alias -> Component ID (in LPD_CUST)
  8. App -> Component ID in Configuration.js (Transaction: SE80)
Example app is Approve Purchase Order.

1. User -> Role (Transaction: SU01)
The user has roles SAP_MM_BCR_BUYER_X1 (Group) and SAP_MM_TCR_T_X1 (Catalog).
A1.png
Role names are documented in App catalog of help.sap.com.
Business Role = Group.
Technical Role = Catalog.
A2.png
2. Role -> Catalog/Group (Transaction: PFCG)
The role SAP_MM_BCR_BUYER_X1 has Menu object Group:SAP_MM_BCG_BUYER_X1.
A3.png
3. Catalog/Group -> Tile (launchpad designer)
The catalog has the tile Approve Purchase Order. When the tile is selected in the launchpad, the app should be launched.
A4.png
4. Tile -> Intent ( launchpad designer, Tile)
The tile Approve Purchase Order has intent PurchaseOrder-approve. Intent = Semantic Object + Action.
A5.png
5. Semantic Object (Transaction: /UI2/SEMOBJ and /UI2/SEMOBJ_SAP)
Semantic Objects are defined in the transaction /UI2/SEMOBJ(for customer) and /UI2/SEMOBJ_SAP(for SAP)
A7.png
6. Intent -> Application Alias (launchpad designer, Target Mapping)
The intent has Application Alias.
A6.png

7. Application Alias -> App URL (in LPD_CUST)
    Application Alias -> Component ID (in LPD_CUST)

The Application Alias is defined in the transaction LPD_CUST. LPD_CUST role is documented in the step 1.
A8.png
Application Alias has App URL. URL = /sap/bc/ui5_ui5/sap/mm_po_apv.
Additional information has Component ID. SAPUI5.Component=ui.s2p.mm.purchorder.approve
A9.png
8. App -> Component ID in Component.js (Transaction: SE80)
The app mm_po_apv has several Java Script and component ID is defined.
A10.png


Source: https://blogs.sap.com/2014/06/16/understanding-launchpad-object-relationship-with-screenshots/

SAP S/4HANA Treasury – Trade Finance – Overview and Configuration

SAP S/4 HANA Treasury – Trade Finance – Overview and Configuration
Global and Local Banks support international trade through a wide range of products that help their customers manage their international payments and associated risks, and provide needed working capital. The term “trade finance” is generally reserved for bank products that are specifically linked to underlying international trade transactions (exports or imports). As such, a working capital loan not specifically tied to trade is generally not included in this definition. Trade finance products typically carry short-term maturities, although they trade in capital.

One of the most common and standardized forms of bank-intermediated trade finance is a letter of credit (L/C). L/Cs reduce payment risk by providing a framework under which a bank makes (or guarantees) the payment to an exporter on behalf of an importer once delivery of goods is confirmed through the presentation of appropriate documents. SAP has introduced new products to cover the trade finance in S/4HANA Treasury.
  • Letter of Credit
  • Bank Guarantee
  • Standby Letter of Credit
The Trade Finance Management process generally covers the creation of financial transactions and executes payments for fees and cash collateral for bank guarantee issuing. For further processing, the roll over and termination of transactions is possible. All of the financial transactions can be monitored and reported in S/4HANA.
Functions and Business Values Available in SAP S/4HANA Treasury For Trade Finance
Master Data Management
  • Master data for Letter of Credit, Bank Guarantee, and Standby Letter of Credit
  • Support Master Data Management for both buyer and seller
  • Customizable user interface with many tab screens
  • Comprehensive and Flexible document management for Letter of Credit
Lifecycle Management
  • Status Management with different steps, Contract – Settlement – Rollover – Termination
  • Customer Specific workflow can be configured
  • Full support of presentation and payment process for letter of Credit
Integration
  • Represented as a new product category in TRM – covering Transaction and Position Management
  • Integration with Accounting and Cash Management
  • Full support of Loan generation out of Letter of Credit Directly
  • Integration with Facility
  • Integration with Credit Risk Analyzer
  • Support the combined usage of the facility and cash collateral for the Applicant.
  • Provide comprehensive BAPI’s for Transaction Management
Communication
  • Integrated in the correspondence Framework
  • SWIFT Messages with respective sub-messages
Trade Finance Customization
We will start by configuring the Trade finance instrument in S/4HANA . In this activity, you can maintain the product type as per your requirements. This will help you differentiate between your financial transactions and the transaction types used for each product type and their assignment.
In SAP S/4HANA Trade Finance, 2 product type categories available, namely:
  1. 850 – Letter of Credit
  2. 860 – Bank Guarantee
An underlying transaction is used in presentation to create an import bill advance for buyers or create export bills negotiation loans for sellers.
Defining Product type


Defining Transaction Types



Defining Flow types
In the S/4HANA Trade Finance area the following flow categories are available:
  • 10 – Principal Increase
  • 11 – Principal Decrease
  • 84 – Payment Obligation
  • 85 – Trade Finance payment
  • 86 – Remaining credit amount
  • 90 – Other flow condition
  • 91 – Collateral
Reference Flow types
  1. Flow category 85 could be assigned with 84 in reference type 1 and flow category 11 in reference type 2, which is assigned for the same product type and transaction type.
  2. Flow category 86 could be assigned with 10 in reference type 1 and flow category 11 in reference type 2, which is assigned for the same product type and transaction type.



Defining Update types



Assigning General Valuation class


Defining Document type


Defining Conditions for Payment and Presentation Period
In this Customizing activity, you define conditions for presentation and payment period.
The system provides one default presentation period condition Shipment Date, and one default payment period condition Presentation Date. You can define other presentation and payment period conditions based on your needs.


Defining Rejection Reasons for L/C Presentation
In this Customizing activity, you define rejection reasons for L/C presentations by assigning a reason code and a description that you can select later when you reject a presentation.


Defining Field Selection
In this step, you can set up the user interface for transaction management according to various criteria:
  • All fields that are visible in the entry screens are grouped according to business criteria. For each field group, you can define whether it should be shown or hidden and whether the entries should be required or optional.
  • You can also configure the various tabs in the transaction entry screens (such as administration or correspondence); you can set the tabs to hidden, optional entry or display only. However, you cannot define tabs as mandatory.
Exception: You cannot hide the Structure tab.


Accounting
Indicate Update Types as Relevant to Posting.
In this IMG activity you specify (whether or not) the update type is relevant for posting.
This can depend on the valuation area. This means that you can post an update type in one valuation area and not in another.


Defining Account Determination
You define the account determination settings for the flows in the parallel valuation areas. The account determination settings define the accounts to be used when the flows are posted to Financial Accounting.
The system only posts flows in the parallel valuation areas if an update type is set as relevant for posting under Indicate Update Types as Relevant to Posting and if posting specifications have been defined for the corresponding update types in this IMG activity.

Enabling Position and Cash Management
In the following activities, you make basic organizational settings for the parallel valuation areas.
You first define the valuation areas and accounting codes, and then assign them to each other. You also have the option of defining product categories not to be transferred to the parallel valuation areas.

Settings for Position Management

Link to Cash Management

Enable Credit Risk Analyzer
This component has the following functions:
  1. Quantifies different risk items relating to the market
  2. Assigns risks to their respective sources
  3. Allows you to control risks by assigning and monitoring limits
In this section, you can make all the system settings necessary for calculating risks and aggregating them according to different criteria.

Activate/Deactivate Financial Object Integration
To be able to enter financial object data at the same time as you create master data, set the Component Active indicator. When you set this indicator, the system displays during online processing the relevant screens for entering transaction data for the component in question (such as Profitability Analysis and Default Risk Limitation). You can then enter the information required for the financial objects.
You can also define how the system reacts to errors. You can select:
  • Completely Active if you do not want the system to save the master data for the transaction when there are errors.
  • Partially Active if you want the system to save the master data but not the financial object part that is incorrect. In this case, a warning message is triggered when the system saves the data.
When you have made these settings on the company code level, you must then assign the product types for which these settings need to be active.

Activate Integrated Default Risk Limit Check


Summary
SAP S/4HANA Trade Finance Management helps you to better manage your Trade Finance instruments. This scope item supports common functionalities of Bank Guarantee, Letter of Credit and Stand by Letter of Credit. The system is able to capture the clear information classification with all details. The drawing and release facility can be automatically triggered based on the changes of the trade finance deal. Credit risk analyzer can be activated based on the product types with customizable limit rules and limit types. The utilization and release of limit can be triggered automatically from the deals themselves.
Preset status can cover the whole lifecycle of these financial instruments. You can configure approval processes for status changes and posting releases. In addition to functions for creating and changing Bank Guarantees/LC, the system also supports functions for rollover, contract settlement, and contract termination. Cash collateral and Bank Guarantee fees are also covered.
Stay tuned for my next blog post, where I will cover the following: –
  • Integration with Sales
  • Facility Management
  • Correspondence
  • Customization at BP level
  • Use of Special G/L indicator
Author: Dinesh Kumar – Business and Technology Consultant – Finance and Risk Transformation
Need to hire SAP S/4HANA resources?
Looking for SAP S/4HANA work?
Get in touch with Eursap – Europe’s Specialist SAP Recruitment Agency


Source: https://eursap.eu/2019/01/23/blog-trade-finances-sap-s4hana-treasury/