SAP offers 2 different processes of Vendor Returns: returns with Returns Delivery Ref to Inbound Delivery and returns with Returns PO. So what is the difference? In this blogs I will compare this 2 processes with EWM steps.
My Testing is based on Embedded EWM – S/4HANA 1909.
Compare Vendor Return Process with Returns Delivery Ref to Inbound and Returns PO
Overall Process with EWM steps
Comparation
Prerequisite
Active BC Set – /SCWM/DLV_OUTBOUND_RETURN
Configuration
General Customizing
Set up confirmation Control Key
IMG: MM > Purchasing > Confirmations > Set Up Confirmation Control
Assign 0004 as Quantity Difference Profile
IMG: MM > Purchasing > Confirmations > Set Up Quantity Difference Profiles (GR Automotive)
In this post, the objective is to help you to understand data fields in standard template and successfully migrate object “Condition record for Pricing” by file load approach under ERP to S/4 HANA migration scenario in new version S/4 HANA 2020 OP. As described in many other posts about Migration Cockpit and the standard template delivered by SAP, I will show that it is not much difficult to populate correct field value in the template to meet migration cockpit program.
Understand Foreground Work
Understand Technical Table
Hands On DMC Template
Hands On Fiori Migration Cockpit
1. Understand Foreground Work
First, to start with foreground work, we need to know how to manually create price master data under Transaction Code VK11.
Understanding Data Field Maintenance Sequence and Relationship in Creation is helpful for following template value filling.
The first data field when we enter in screen is “Condition Type” in price condition. In business requirement, we need to acquire data value about what kinds of condition type from business users side need to be migrated.So here we will take an example of condition type as “PR00” which is frequently used in purchasing price condition.
In condition type PR00, there are 3 types of Key Combination. And here we need to understand those 3 Combinations in fields differences. Because different Combinations need different data fields in the header.1) In combination “Customer/material with release status”, it needs fields as mandatory are “sales organization/distribution channel/customer” in the header.
2) In combination “price list category/currency/material with release status”, it needs fields as mandatory are “sales organization/distribution channel/price list type/ document currency” in the header.
3) In combination “material with release status”, it needs fields as mandatory are “sales organization/distribution channel” in the header.
Therefore, we need to check which combination needs to migrate from legacy table.
2. Understand Technical Table
Let’s move to technical table – KONH (Conditions Header) and KNOP (Conditions Item).
In the foreground screen, there are different types of Key Combination. Here we run Transaction Code SE16N to check what value is recorded in legacy table.
Input the filter condition that the condition type equals to PR00, then execute it.Here we got the “table” field which we need to query it from technical table “A + table field value”, e.g. “Table” value is 304, then we need to go to Technical Table “A304” to get key combination field.Here we run Transaction Code SE16N to go into technical table A304. Input the filter condition that condition record number we need to migrate, then execute it.From table A304, we also have the table name “Material with release status” to know which combination is as same as foreground work.
In foreground work, combination is “Material with release status”, it needs two mandatory fields “sales organization/distribution channel” in the header.
Also we can get details from table header to know that it needs fields “sales organization/distribution channel” as mandatory.
3. Hands On DMC Template
Now we need to get load template from Fiori Migration Cockpit. Open Fiori by Transaction Code /UI2/FLP and click “Migrate Your Data”.Choose “Create->Migrate Data Using Staging Table”Fill project name and keep option as below. Click Step 2.Input “condition” to search, and tick it from left list to right list, and click “Review”.
There are many migration objects for condition, but we choose the general template which is suitable for all scenarios.Choose “Do Not Add”Click “Create Project”
Double confirm project name and object and create project.Click the down arrow and choose “Download Template” and save template.In the template, there are 2 sheets in orange color which are marked as mandatory. And data fields in background header table meet it in those 2 sheets.Now we can progress fields mapping by the fields name or description from legacy background table to template. But here we need to pay more attention to is that “field name” in sheet of Key field for condition needs to transform into field technical name. “Field Name” is the field that refers to key combination, we need to identify how many combination fields are in one condition record No. Here it needs to be checked by “table” field in KONH.There is the scope of “Field Name” delivered by SAP. If your migration scenario is new implementations, pls refer to note 2332748 to check the field value which is mandatory in field name.
Below is the mapping list about Field name frequently usage in condition.
Field Name
Description
KFRST
Release status
KUNNR
Customer number
LIFNR
Supplier’s Account Number
MATKL
Material Group
MATNR
Material Number
PERNR
Personnel Number
SPART
Division
VKORG
Sales Organization
VTWEG
Distribution Channel
WERKS
Plant
PLTYP
Price List Type
KDGRP
Customer Group
KUNAG
Sold-To Party
KUNRG
Payer
KUNWE
Ship-To Party
VRKME
Sales Unit
WAERK
SD document currency
UKONM
Material pricing group of main item
UPMAT
Pricing reference material of main item
VARCOND
Variant condition
BSTME
Order unit
BUKRS
Company Code
EKORG
Purchasing Organization
ESOKZ
Purchasing info record category
EVRTN
Purchasing Document Number
EVRTP
Item Number of Purchasing Document
INFNR
Number of purchasing info record
INCO1
Incoterms
LAND1
Country Key
LLAND
Country of Destination
REGIO
Region
LIFRE
Different Invoicing Party
Now we understand background table and template requirement, we can fill the correct fields value in the template as below.
4. Hands On Fiori Migration Cockpit
Now we have correct value in the template. The next step is to load template into Fiori migration cockpit.
Access project object and upload file.Click upload and locate file in PC.Here we need patience to wait for upload status, once it reminds “Data Successfully Transferred to Staging Tables”, back to mapping task.We can see instance record change into 1 record. Click “Prepare”.Click “Mapping Task”.Complete the batch of 8 open mapping tasks.There are 3 ways to complete mapping task:
choose all 8 mapping tasks and click confirm.
select mapping object one by one, go into details to change and confirm value.
Download mapping template, upload mapping value through template.
Here we have simple example, we will take the first one simple approach.After mapping task done, click “Simulate”We get the successful simulation status, then click “Migrate”, the data will be officially transferred into S/4 HANA.The last step is to check background table to validate the data.
Conclusion
Price Condition becomes an easy object to migrate after you understand the most difficult field “Field Name” in data migration cockpit standard template.
I hope this blog post makes you get the ways of how to migrate price condition data object from source ERP to S/4 HANA and will help you in data value populated by SAP delivered migration template to meet your business requirements.
This blog targets SAP solution architects and Global IT members that are studying a future SAP rollout to Brazil or the conversion/implementation of S/4HANA to replace ECC or legacy ERP systems.
Last week (CW 38 2020) was the SAP Now event where SAP and partners showcased several new solutions for Brazilian Localization of S/4HANA.
With all the changes done in the most recent releases of S/4HANA and all new solutions available it’s valid to discuss and analyze what’s the best strategy for doing a rollout to Brazil in terms of technical architecture and busines process to cover both the business requirements as well as the technical requirements.
I’ll not enter into specific details of the scope item configuration for Brazil (as there many differences to other coutnries) but rather focus on the main topics on architecture and project decisions.
With the trends on digital transformation and agile implementation projects it’s normal to question the processes, developments and new needs contemplated in the Brazil localization in S/4HANA.
The main country-specific challenges in S/4HANA for Brazil continue to be the same that we had in ECC:
Real-Time Integration of Electronic Documents such as outbound and inbound invoices (NF-e) and Freight bills (CT-e) into AP/AR processes
Complex taxation on sales/purchases (several taxes and taxation due at goods movement without added value)
Complex legal reporting (SPED electronic bookkeeping reports) with several national, state and city level reporting with different layouts and very high level of complexity
High Maintenance/Administration effort for IT to create new document types, new settings and ensure data can be consolidated into a useful manner for group reporting and performance comparison
There are other implications of Brazil localization with impact in FICO (Country Specific Reference Chart of Accounts for legal reporting, Bank Statement formats based on Febraban Standards, Actual Costs at Month-End Closing with Material Ledger) but these types of requirements are more common in rollouts to other countries and will not be part of this article.
Summed to the country-specific requirements there are still other project and technology challenges that come from new deployment model possibilities (Cloud or Hybrid models besides On-Premise) and Business Process Management, that is how to handle the Global Template (Balance business requirements, legal requirements and company global/local processes).
Deployment possibilities for Brazil S/4HANA implementation
There is an interesting blog from SAP that explains the difference between the different capabilities and functionalities available in the different deployment possibilities of SAP S/4HANA cloud and on-premise deployment options
I’ll highlight specific points related to Brazil country specific features:
On-premise
That’s the most traditional deployment (although SAP is pushing cloud solutions to become the go-to for new customers) for S/4HANA so far.
The main advantages of the On-Premise for Brazil are keeping the schedule of changes totally under the company control (SAP publishes correction notes frequently for XX-CSC-BR* components and sometimes they contain critical updates needed for allowing invoices to be issued correctly) and allowing all enhancement techniques, some country specific features are not supported by SAP and they require extensive usage of “implicit enhancements” in localization function modules and classes/methods. On the downside it requires higher administration and IT efforts to be maintained and generally cause higher complexity for upgrades and system updates.
Cloud
SAP S/4HANA offers different cloud deployments ( Cloud Essentials, Cloud Extended and Private Cloud HEC ) for Brazil.
SAP released Brazil localization for S/4HANA cloud (Essentials/Extended) and it also released cloud enabled solutions like NF-e Inbound/Outbound as a Service and Tax as a Service. Interestingly some of the cloud solutions from SAP can be also integrated with an On-Premise S/4HANA via SAP cloud Platform.
S/4HANA Cloud seems an interesting solution mainly for companies that are primarily service providers ( with less complex taxation requirements ) and also for companies that have less complex operations ( only administration office to do imports with external warehouse ) where they’ll not need the full scope of complex operations ( Production, Procurement and Transportation Management ).
The service tax in Brazil is less complex than the taxes for goods and also the legal requirements due for service companies are easier to be implemented. It’s also possible to implement it in other companies with more processes but then it will require more extensions to be developed in SAP Cloud Platform to complement scenarios that are not available directly in the ERP.
The cloud essentials also enforce the usage of FIORI apps ( No ABAP Dynpro or SPRO availability ) while the other cloud options have still more possibilities ( with certain restrictions only ).
SAP is focusing more and more in cloud solutions so new functionalities for Brazil localization are usually released for Cloud first and later on ( once a year ) for the On-Premise Versions.
Hybrid
An on-Premise S/4HANA system can be “plugged” into cloud-based solutions such as NF-e solutions or Tax as a Service or other products in SAP Cloud Platform depending on customer requirements.
It reduces the needs of maintenance by IT and ensure that frequent updates are implemented in the cloud systems ( according to legal requirements ) without changing the core ERP functionalities.
That provides an option to reduce administration effort of country specific features for companies that still want to maintain an On-Premise ERP installation.
Now we can go into details for each of the main Brazil country specific challenges listed above as well other important information:
1. Real-Time Integration of eDocuments
Probably the most known example of the brazilian legal complexity for business is the Electronic Invoice (NF-e). Unlike other eDocuments being currently implemented in Europe the Brazilian NF-e is more detailed (more than 500 tags) and the rules to accept the documents are more strict (more than 400 different validation rules). As of 2020 there are basically two main options for NF-e / CT-e (Freight Invoice) implementation.
The SAP on-Premise NFe solution GRC has both inbound and outbound functionalities ( separate licensing for each one ). The outbound solution receives data from ERP via RFC and builds the XML of the electronic invoice, sign it and send to PI that communicates with government.
The inbound automation receives XML from government webservice ( or from partners via PI / e-mail ) and processes them to allow the posting of the goods receipt and the invoice receipt. It’s integrated into ERP so the majority of the BAdI implementations are done in S/4HANA side. It supports NF-e, NFC-e, CT-e and MDF-e.
It does not support NFS-e ( Service Electronic Invoices ). Service Invoices are a special topic as service documents are linked to each city hall and there are several different file formats and integration methods such as WebServices, WebPortals and also still old paper invoices ( not all city halls work with electronic service invoice ).
Cloud solutions
SAP has a suite of solutions called SAP Document Compliance that compreehends edocuments for several countries. An interesting overview about it can be seen in the blog post Overview of SAP document compliance. Similarly to On-Premise there are different solutions for Incoming and Outgoing Electronic Documents:
In summary SAP already developed a replacement solution for the on-premise NF-e and has live customers using it. The product covers NF-e, CT-e and NFS-e ( for RJ and SP city hall ). This solution is not based on the eDocument Framework from SAP but uses SAP Cloud Platform for communication.SAP recently released a partner enablement solution where partners can integrate other city halls with the SAP solution to extend its reach.
It’s interesting to highlight that it’s possible to acquire from SAP partners the SAP NFE ( AKA GRC NFE ) as a service ( installed, managed and monitored by partner ) which is also a viable cloud solution for E-Invoicing.
The SAP Cloud solution for Incoming NF-e’s is based on the eDocument Framework and it has been released after the outgoing part. The scope of NFe as a Service inbound is not yet the same of GRC NFE, but SAP is developing additional functionalities for this solution and probably they’ll have very similar scope until end of 2021..
For this case it’s also possible to acquire from SAP partners the SAP NFE Inbound ( AKA GRC NFE inbound ) as a service ( installed, managed and monitored by partner ) which is also a viable cloud solution for E-Invoicing.
Additional Info on Edocuments
There is one lecture from SAP Inside Track Brazil where I explain more technical details about the eDocument Framework from SAP.
2. Taxation in Sales/Purchases/Transfers
Brazil taxation contains several different taxes ( don’t think about VAT as it does not apply to Brazil ) and it requires different implementation in all logistics/finance processes to ensure the correct taxes are determined, calculated and postings into Accounting. In the past there was only On-Premise Solution but for S/4HANA it was also developed an interface for external tax calculation ( similarly to AC-INT / VERTEX in USA ):
On Premise
Popularly known by consultants as TAXBRA/RVABRA this is the pricing procedure for Brazil used in ECC and S/4HANA and it uses CBT ( Condition-based technique ) to determine validity of taxes and calculate their values.
The pricing in brazil is quite complex ( if you check SD pricing procedure you’ll find more than 80 tax-related conditions in the standard procedure ). The configuration of it requires deep expertise from Tax Topics in SD, MM and Logistics in General ( Taxation on Stock Transfers and Repairs/Free Goods apply in Brazil ).
The number of conditions and tax exceptions necessary for Brazil would start around 2 or 3 thousand entries and it can easily go into more than 100 thousand entries depending on the busines sector and in how many states a company operates.
In the SAP Best Practices even though the default implementation for S/4HANA systems is the Tax As a Service (discussed in the next section) as replacement for TAXBRA/RVABRA, most companies are still implementing S/4HANA with TAXBRA/RVABRA.
Cloud solutions
SAP has a solution called SAP Localization Hub where it offers a Tax Service engine. According to SAP the tax service helps you to determine and calculate applicable country/region-specific indirect taxes. The tax service works with sample tax determination / calculation content and increases automation in tax-relevant transactions.
For some countries SAP has a standard content for the tax engine, but for Brazil you have to integrate it with homologated partner tax solutions for having the tax calculation.
SAP has an interesting video with additional details about the solution:
It’s interesting to note that SAP has a few partners homologated for the implementation of the tax service in Brazil and you’ll need to establish a contract with them before you start using the solution in the development/test systems in your project.
3. Electronic Legal Reporting (SPED bookkeeping and Additional Obligations)
Brazil has Legal Reports at federal, state and city level and it’s a major point for customers implementing SAP as it requires for most of the companies a complementary solution for tax reporting. In S/4HANA SAP offers two native solutions for Tax Reporting ( licensed separately from S/4HANA ) in addition to external tax reporting tools from Partners.
TDF is a framework that SAP developed to work as a central repository of tax data for Brazilian reports. It provides the structure of SPED Reports but requires complementary developments to meet the legal requirements to deliver the report files. It works as an add-on, so it has to be installed in a separate SAP Netweaver system. TDF does not have as standard state or city hall reports, so they have to be developed during the project or acquired from partner complementary products.
The main SPED reports are ECD, ECF, EFD-ICMS/IPI, EFD-Contribuicoes and EFD-Reinf but in projects it’s usually needed to develop additional state reports ( GIA’s and others ) and city reports ( for ISS service tax ).
ACR is an embedded solution in S/4HANA for legal reporting. The base framework for ACR BRazil are the calculation views from TDF CTR ( central tax repository ). The User Interface of ACR is based on UI5/FIORI ( TDF has both ABAP Dynpro and UI5/FIORI ) and there are differences in reporting from TDF ( REINF solution uses a different framework for the event processing for example).
Partner Solutions
It’s important to note that even if you choose SAP standard solution for tax reporting you’ll need to have custom developments to do the tax appraisal or you’ll need to integrate them with add-on’s from partner. There are partner products that can be used to complement TDF/ACR and also options to fully replace them. In the context of S/4HANA the only SAP homologated partner solutions are the ones that are integrated to TDF.
4. Maintenance challenges for S/4HANA Brazilian Rollout
Due to the points mentioned before you can certainly understand that a global template designed elsewhere in the world will need many adaptations for local processes to be able to serve the company in Brazil. Two important details are highlighted in regards to this topic:
Fit-to-standard ( former Fit-Gap )
One of the main challenges in the rollouts is fitting the local requirements of Brazil to the template in a way that balances the complexity of IT efforts (to create new settings and support local processes exclusive to Brazil ) and the needs from the Business areas.
It’s normal that when this balance is compromised either the IT will have higher support demands to maintain hundreds of country specific settings ( document types, Tax Codes, Item Types, etc.. ) or the business will have to execute too many processes manually to redetermine data because the template settings don’t meet the requirements for automating a process.
It’s advisable to have trusted partners with local expertise to help conduct the sessions and also to communicate with users in Brazil to help them bring their needs to the workshops.
Best practices
The SAP Best Practices was revamped for S/4HANA making it easier to build a prototype system for doing a workshop with IT to analyze gaps between template processes and Brazil Processes and also to standard SAP Brazil localization functionalities and the company legal requirements to be implemented in Brazil.
These best practices can speed up the initial settings but will require effort to be implemented prior to fit-to-standard workshops.
As it’s possible to see in the blog post there are several specific requirements from Brazil for a rollout but they are manageable when the right approach is followed for the implementation and it’s possible to have a successful Go-Live that enables the company to perform their operations well with an SAP System in the Brazilian Market.
Although it requires a lot of orchestration from project team with local business and Global Process Managers if all the points mentioned above are taken into consideration for project planning and implementation it’s very likely the outcome of the project will be a successful implementation.
If you want to get in touch or share your thoughts to discuss some of the topics please feel free to leave a comment on the post with your view or the challenges you see in such projects.
Regards,
Renan Correa
All views expressed on this blog post are my own and do not represent the opinions of any entity whatsoever with which I have been, am now or will be affiliated.
These views are subject to change in future due to new developments or products in S/4HANA and other systems.
So here we will take an example of condition type as “PR00” which is frequently used in purchasing price condition.
1) In combination “Customer/material with release status”, it needs fields as mandatory are “sales organization/distribution channel/customer” in the header.
Here we got the “table” field which we need to query it from technical table “A + table field value”, e.g. “Table” value is 304, then we need to go to Technical Table “A304” to get key combination field.
Here we run Transaction Code SE16N to go into technical table A304. Input the filter condition that condition record number we need to migrate, then execute it.
From table A304, we also have the table name “Material with release status” to know which combination is as same as foreground work.
Choose “Create->Migrate Data Using Staging Table”
Fill project name and keep option as below. Click Step 2.
Input “condition” to search, and tick it from left list to right list, and click “Review”.
Choose “Do Not Add”
Click “Create Project”
Click the down arrow and choose “Download Template” and save template.
In the template, there are 2 sheets in orange color which are marked as mandatory. And data fields in background header table meet it in those 2 sheets.
Now we can progress fields mapping by the fields name or description from legacy background table to template. But here we need to pay more attention to is that “field name” in sheet of Key field for condition needs to transform into field technical name. “Field Name” is the field that refers to key combination, we need to identify how many combination fields are in one condition record No. Here it needs to be checked by “table” field in KONH.
There is the scope of “Field Name” delivered by SAP. If your migration scenario is new implementations, pls refer to note 2332748 to check the field value which is mandatory in field name.
Click upload and locate file in PC.
Here we need patience to wait for upload status, once it reminds “Data Successfully Transferred to Staging Tables”, back to mapping task.
We can see instance record change into 1 record. Click “Prepare”.
Click “Mapping Task”.
Complete the batch of 8 open mapping tasks.
There are 3 ways to complete mapping task:
After mapping task done, click “Simulate”
We get the successful simulation status, then click “Migrate”, the data will be officially transferred into S/4 HANA.
The last step is to check background table to validate the data.
