sexta-feira, 28 de junho de 2019
SAP S/4HANA System Conversion Overview
With more than over 1500 live customers on SAP S/4HANA since January 2018, the path to SAP S/4HANA via a System Conversion is a popular transition path for existing ERP customers. With a System Conversion approach, you can conduct a technical conversion project and adapt mandatory simplification/FI migration with subsequent projects to adapt new business process innovations at your own pace. Another approach for customers is to conduct a system conversion and additional/full business process transformation scope together to SAP S/4HANA. No matter what approach you decide, Fiori UX implementation should be considered and implemented alongside of the system conversion project to obtain the value of in memory computing, the digital core, and running a live business with SAP S/4HANA.
In our SAP S/4HANA Regional Implementation group, we have supported many System Conversion projects since the SAP S/4HANA 1511, 1610, and now 1709 releases. In this blog, a presentation was created to introduce you to: the SAP Readiness Check for SAP S/4HANA, System Conversion process, an example of a mock cutover for a system conversion, and an overview of a conversion project within a 4-tier system landscape. The major point of the conversion process is practice makes a perfect conversion. Plan as many production test cycles as your project time line allows, ensure you test the production cutover like how it will be executed (e.g. Uptime Phase: implementation of precheck in production weeks in advance and business operation with precheck implemented and Downtime Phase: optimization of SUM activities and FIN migration), and freeze the software stack (e.g. SUM, HANA and S/4HANA) if possible after the development system conversion.
Link to document: SAP S/4HANA System Conversion Overview
Thanks,
SAP S/4HANA RIG
Source: https://blogs.sap.com/2018/01/18/sap-s4hana-system-conversion-overview/
S/4HANA Conversion
This blog post will give quick overview for S/4HANA conversion.
Overall journey for conversion to S/4HANA looks like as below –
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
S/4HANA conversion journey divides into pre-conversion, conversion and post-conversion phases.
In short, we should be aligned with these phases throughout S/4HANA journey. In pre-conversion phase, we are performing all pre-steps which are required to start conversion. This will help us to find any issue in early phase of project. In conversion, we are converting system to new world of SAP S/4HANA. This phase includes adaptation to new business process, validation etc… And final phase is post-conversion, here we are performing follow-up activities to make sure we get maximum use of SAP S/4HANA for our business.
(reference from SAP-Press book “S4H100 SAP S/4HANA Implementation Scenarios)
(reference from SAP Note – 2240360, 2240359)
(reference from SAP Note – 2214409)
(reference from SAP Note – 2399707)
In order to successfully use the Simplification Item Check as preparation for system conversion/upgrade project
The Custom Code Migration process describes the tools and necessary activities that help you to migrate custom code. The process consists of preparatory analysis (Custom Code Analysis) and the adaptation of the custom code (Custom Code Adaptation) after the technical conversion.
Custom Code Process –
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
For this purpose, use either UPL (usage procedure log) or ABAP Call Monitor (SCMON) in productive system to find out, which custom ABAP objects are really used within running business processes.
Tool – Solution Manager 7.2
Right size SAP HANA hardware to realize the maximum benefit from investment and reduce long-term total cost of ownership. SAP sizing report will provide estimated amount RAM, disk size etc.
The following workflow will help to size HANA hardware.
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
SUM tool segregate activities as uptime processing and downtime processing.
The uptime processing is the migration of the shadow repository. It can be migrated during uptime, because no changes are done any long – since the repository was locked at the beginning of the SUM procedure (dev lock). The shadow repository is built up from upgrade media (upgrade DVDs) + the maintenance planner download + additional files (files in the download directory, transport requests, add-ons etc).
The downtime processing is the migration of the application data, customizing data, and user master records. It can be migrated during downtime only, because it would be changed continuously during uptime. New standard customizing and new data, delivered by SAP, is imported.
The migration to SAP HANA DB takes place partially in uptime (UT) processing and partially in downtime (DT) processing of SAP up.
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
SUM tool has too started on Primary application server. After some basic configuration setting, such as stack.xml, the SAP up will start to create shadow system. It contains the basic tables and some customizing tables. The system is still running, and end user may work in the system and use functionality that may change application data into database. In this phase, the system is running and available for end users (uptime processing), but the development environment is locked. Then the ramping down phase will start which includes, locking users, cleaning up queue etc.
The technical downtime phase is started. It migrates data from the source database into the target database. After this application tables are updated to the target release. Then validation will take place and go/no-go decision. After go decision from business owner, ramping up phase will start which includes reconnecting landscape, unlocking users etc. and finally system will be live on target release and available for end user.
The system is now migrated to the target database and updated to the target release.
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
Adjust modifications and enhancements – To adapt the modifications and enhancements, use the standard transactions SPDD, SPAU, SPAU_ENH
Fix SAP HANA and SAP S/4HANA findings – Adapt custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results). Findings of SAP S/4HANA checks are related to S/4HANA Simplifications. Each simplification requires a different approach to solve findings. Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them.
Tool – ABAP Test Cockpit (ATC)
ABAP SQL Monitor allow us to get performance data for all SQL statements executed in production. SQL monitor will help to understand what are the most expensive and most frequently executed SQL statements. SQL Monitor allows you to link the monitored SQL statements to the corresponding business processes including various aggregation and drill-down options.
Tool – ABAP SQL Monitor
Source: https://blogs.sap.com/2019/06/24/s4hana-conversion/
Overview
You have an existing ERP system, and you want to leverage your previous investment in the business processes that you already have implemented in ERP. You want to bring them to the new world of SAP S/4HANA. Then S/4HANA system conversion is perfect option for you…!!!Overall journey for conversion to S/4HANA looks like as below –
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
S/4HANA conversion journey divides into pre-conversion, conversion and post-conversion phases.
In short, we should be aligned with these phases throughout S/4HANA journey. In pre-conversion phase, we are performing all pre-steps which are required to start conversion. This will help us to find any issue in early phase of project. In conversion, we are converting system to new world of SAP S/4HANA. This phase includes adaptation to new business process, validation etc… And final phase is post-conversion, here we are performing follow-up activities to make sure we get maximum use of SAP S/4HANA for our business.
Pre-Conversion
These checks will help to find out what mandatory steps we must carry out before converting S/4HANA system. The checks are divided into category such as –- System Requirement
- Maintenance Planner
- SI-Check
- Custom-code analysis
System Requirement
We need to evaluate system and check out its compatibility regarding OS, DB and Stack (Single/Dual) etc.- Unicode is needed, due to technical restriction with S/4 kernel. If legacy system is not Unicode, then at first place perform Unicode conversion
- Dual stacks are not supported on SAP HANA. So, perform dual-stack split, if required
- ECC system should be >= 6.0.
- Check minimum required version of DB/OS for conversion into S/4HANA
(reference from SAP-Press book “S4H100 SAP S/4HANA Implementation Scenarios)
Maintenance Planner
The Maintenance Planner checks the system with regards to business functions, industry solutions, and add-ons. If there is no valid path for the conversion (for example, the add-on is not released yet), the Maintenance Planner prevents the conversion.Business function
Business function can have following status: always_on, customer_switchable and always_off.- If a business function was switched on the start release system, but defined as always_off in the the SAP SAP S/4HANA target release, then a system conversion is not possible with this release
- If business function was switched off in the start release system, but defined as always_on in the SAP S/4HANA target release, then the business function will be activated during the conversion
- If business function is defined as customer_switchable in the SAP S/4HANA target release, it can be activated depending on the needs of the customer, Business functions that were active in source release, remains active in target release.
(reference from SAP Note – 2240360, 2240359)
Add-ons
All add-ons must be certified for S/4HANA in order to run on S/4HANA. If you are converting from ECC to S/4HANA and have add-ons that are not certified, the conversion tool will simply stop in its tracks when Maintenance Planner identifies the uncertified add-on.(reference from SAP Note – 2214409)
SI-Check
SI-CHECKS will identify simplification items relevant to conversion. It means that it checks data inconsistency or missing mandatory preparation activities.Tip - Do run this report early in the project.
Procedure
For performing SI-CHECKS, follow below steps- Start report /SDF/RC_START_CHECKS in transaction SA38
- In the section Simplification Item Check Options, choose the target SAP S/4HANA version
- Choose the mode in which you want to run checks
- In Online Mode – The results are displayed immediately after the check is finished
- Background job: If the check will need a long running time, use background mode
- Run the checks to get an overview over all irrelevant simplification items and then check system consistency with Check Consistency for All
- Check the Results and take appropriate action based on logs.
SI-Check message and their meanings
(reference from SAP Note – 2399707)
In order to successfully use the Simplification Item Check as preparation for system conversion/upgrade project
- Start running the Simplification Item Check and fixing the issues found by the checks as early as possible in project
- Stay up-to-date with the latest check and check content versions early in project. But don’t miss to freeze the check notes and check content versions after converting your DEV system
- Archive any data which you don’t strictly need in your SAP S/4HANA system in order to minimize the check runtime and the data cleanup effort.
Custom – Code Analysis
The Custom Code Migration process describes the tools and necessary activities that help you to migrate custom code. The process consists of preparatory analysis (Custom Code Analysis) and the adaptation of the custom code (Custom Code Adaptation) after the technical conversion.
Custom Code Process –
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
Custom Code Evaluation
ECC system contains a large amount of custom development objects (Z-Objects, enhancements and modifications) that are not used productively. Therefore, monitor system for longer period and do some housekeeping and eliminated the code, which is not used anymore within your productive business applications.For this purpose, use either UPL (usage procedure log) or ABAP Call Monitor (SCMON) in productive system to find out, which custom ABAP objects are really used within running business processes.
Tool – Solution Manager 7.2
SAP HANA Checks and SAP S/4HANA Checks
This is most important step for custom ABAP code on the way to system conversion to SAP S/4HANA.- Native SQL of the predecessor database and these database vendor specific dependencies must be eliminated
- Also, in some custom code implementation the SELECT statement without ORDER BY is used. This can lead to unexpected behavior when database is changed (eg. SAP HANA) because the results return in a different order without ORDER BY. Therefore, you need to check your SQL SELECTs without ORDER BY statement if they are still correct
- Pool/cluster tables were removed with SAP HANA, therefore the database operations on these table need to be removed from custom ABAP code
Hana Sizing
Right size SAP HANA hardware to realize the maximum benefit from investment and reduce long-term total cost of ownership. SAP sizing report will provide estimated amount RAM, disk size etc.
The following workflow will help to size HANA hardware.
Conversion
The actual conversion is started with SUM tool. Sum tool performs execution part including Database migration (DMO) and SAP S/4HANA conversion.(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
SUM tool segregate activities as uptime processing and downtime processing.
The uptime processing is the migration of the shadow repository. It can be migrated during uptime, because no changes are done any long – since the repository was locked at the beginning of the SUM procedure (dev lock). The shadow repository is built up from upgrade media (upgrade DVDs) + the maintenance planner download + additional files (files in the download directory, transport requests, add-ons etc).
The downtime processing is the migration of the application data, customizing data, and user master records. It can be migrated during downtime only, because it would be changed continuously during uptime. New standard customizing and new data, delivered by SAP, is imported.
The migration to SAP HANA DB takes place partially in uptime (UT) processing and partially in downtime (DT) processing of SAP up.
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
Overall Procedure at a Glance
SUM tool has too started on Primary application server. After some basic configuration setting, such as stack.xml, the SAP up will start to create shadow system. It contains the basic tables and some customizing tables. The system is still running, and end user may work in the system and use functionality that may change application data into database. In this phase, the system is running and available for end users (uptime processing), but the development environment is locked. Then the ramping down phase will start which includes, locking users, cleaning up queue etc.
The technical downtime phase is started. It migrates data from the source database into the target database. After this application tables are updated to the target release. Then validation will take place and go/no-go decision. After go decision from business owner, ramping up phase will start which includes reconnecting landscape, unlocking users etc. and finally system will be live on target release and available for end user.
The system is now migrated to the target database and updated to the target release.
Post – Conversion
(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
Custom Code Adaptation
- Need to adapt any modification and enhancements using the standard transactions SPDD, SPAU, SPAU_ENH
- Need to fix any issues due to SAP S/4HANA simplification
Functional Adaptation
Once system conversion to SAP S/4HANA is completed, need to carry out functional adaptation based on the ATC results.Adjust modifications and enhancements – To adapt the modifications and enhancements, use the standard transactions SPDD, SPAU, SPAU_ENH
Fix SAP HANA and SAP S/4HANA findings – Adapt custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results). Findings of SAP S/4HANA checks are related to S/4HANA Simplifications. Each simplification requires a different approach to solve findings. Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them.
Tool – ABAP Test Cockpit (ATC)
Performance Tuning
Once system conversion to SAP S/4HANA is completed, then need to look which business processes can be optimized on SAP HANA database. As we can make use of full power of SAP HANA regarding performance. Therefore, we need to look which SQL statements can be optimized.ABAP SQL Monitor allow us to get performance data for all SQL statements executed in production. SQL monitor will help to understand what are the most expensive and most frequently executed SQL statements. SQL Monitor allows you to link the monitored SQL statements to the corresponding business processes including various aggregation and drill-down options.
Tool – ABAP SQL Monitor
Cleaning up Obsolete Data after the Conversion
To delete obsolete data that may remain after the conversion of your SAP ERP system to SAP S/4HANA.Cross Application Follow-on Activities
- Adapting Database Extension to SAP S/4HANA
- Adapting the User Interface
- Output Management
Application – Specific Follow-on Activities
- Finance
- SAP Credit Management
- Human Resources
- Sales – Order and Contract Management
- Retail
- Environment, Health and Safety
- Product Safety and Stewardship
- Integration
Conclusion
The conclusion is that – for successful converting to S/4HANA system, you can align with the sequence given in the blog.Source: https://blogs.sap.com/2019/06/24/s4hana-conversion/
segunda-feira, 24 de junho de 2019
Material Ledger Customizing
Go to start of metadata
What are the benefits to use the Actual Costing - Material Ledger ?
The application component Actual Costing/Material Ledger fulfills two basic objectives: the ability to manage material prices in multiple currencies/valuations, and the actual costing functionality.
The aim is to combine advantages of both the moving average price and the standard price, to calculate the accurate actual price and to distribute price differences and follow-up costs.
The benefits of the different valuation methods S price / V price are combined:
- S price -> Stable price for controlling purposes.
- V price -> Actual price for valuation purposes.
The following functionalities are provided:
- Inventory Valuation at actual prices.
- Actual Costing: Actual Price calculation and multilevel.
- Transparency of value chain.
- Parallel Currencies and parallel valuation.
- Actual Price Cost Component Split
Customizing Material Ledger
- Basic settings for the Material Ledger in customizing
There are some basic settings for the Material Ledger in customizing:
- Activate Valuation Areas for Material Ledger: If the material ledger is active for a particular valuation area, all materials in the valuation area are valuated using the material ledger.
- Assign Currency Types to Material Ledger Type and Assign Material Ledger Type to Valuation Area.
You specify which currency types are used separately in the different applications. It is important to make sure that the settings in Financial Accounting, Controlling, and the Material Ledger harmonize with each other.
There is no possibility to change the currency type with the Material Ledger already active. The currency in T000-MWAER must remain the SAME after the ML-startup program. If you change it later you have inconsistent data. In the case of you are working with a test system, you must deactivate the ML, and then you must run the startup program again with the currencies you want to work with. Take into account that the deactivation means: Running report SAPRCKMJX, and this report DELETES all ML-data. Check the KBA 1511335. - Define Material Update Structure and Assign to a Valuation Area.
In the standard system, the categories in the material update structure 0001 are so defined that the valuation price during material price determination corresponds to the weighted average price - the sum of the beginning inventory and the prices of all receipts of the period.During the material ledger update, data is collected from valuation-relevant transactions (for example, goods receipts, invoice receipts, settlements of production orders) in different categories in the material ledger according to the material update structure.The influence that these transactions have on the valuation price during material price determination depends on the category in which they are collected. The following categories exist:- Receipts
- Consumption
- Other receipts/consumptions
A receipt always has an effect on the valuation price.If you are working with the update logic in the standard system, the material stock in the closed posting period is valuated with the weighted average price- - the sum of the beginning inventory and prices of all receipts in the period.If this logic meets your demands, you do not have to edit this section. The system automatically uses material update structure 0001. - Define and Assign Movement Type Groups of Material Ledger: Setting up the Material Ledger Update of Goods Movements for Revaluation of Consumption if you want to adjust the single-level consumption values in actual costing with the periodic unit price in all value records, if the Revaluation of Consumption step is run.
The price differences allocated to the category Consumption are allocated to the individual consumption alternatives in proportion to quantities consumed. Check the related wiki: https://wiki.scn.sap.com/wiki/x/yqw0Gg
- Transaction CKM9: Display of ML relevant customizing settings.
- Transaction CKM9 with the option 'Display Accounts': the accounts for each ML relevant transaction type and corresponding valuation class are displayed.
- Remember!: activate Actual Costing in customizing to enable multilevel and actual costing functionalities. Check CKM9 for the plant.
- IS-Retail and Material Ledger are not compatible.
Check the note 1955551.
Create STO & Delivery from EWM ODO
Hi All,
When we create a Direct ODO from EWM to another plant then system automatically creates the STO & Creates the Outbound Delivery in ECC too.
Here is the process flow
Step1: Maintain STO Setup in ECC.
This is normal STO Setup only.
Step2: Map Delivery type & item type from EWM to ECC.
SPRO –> IMG –> Logistics Execution –> Extended Warehouse Management Integration –> Direct Outbound Delivery –> Map Document type from EWM to ECC.
Step3: Map Item Categories: (Optional)
SPRO –> IMG –> Logistics Execution –> Extended Warehouse Management Integration –> Direct Outbound Delivery –> Map Item type from EWM to ECC.
Step3: Create Direct ODO in EWM.
Here Partner is Receiving Plant in my case 4902.
Now Save the Delivery.
Now system triggers the below two FM’s to create PO & Delivery.
/SPE/CREATE_STO_FOR_DIRDLV – Create STO from Direct ODO
/SPE/DELIVERY_CREATE_FROM_STO – Delivery Create From STO
Storage location is not filling in PO( need to check ).
Step4: Rest of the process is as same as normal STO with EWM.
Hint: you can create a custom RF transaction in EWM with very few input fields( rest will be picked from customizing ) to trigger the STO Process from EWM
Source: https://blogs.sap.com/2019/06/23/create-sto-delivery-from-ewm-odo/
When we create a Direct ODO from EWM to another plant then system automatically creates the STO & Creates the Outbound Delivery in ECC too.
Here is the process flow
Step1: Maintain STO Setup in ECC.
This is normal STO Setup only.
Step2: Map Delivery type & item type from EWM to ECC.
SPRO –> IMG –> Logistics Execution –> Extended Warehouse Management Integration –> Direct Outbound Delivery –> Map Document type from EWM to ECC.
Step3: Map Item Categories: (Optional)
SPRO –> IMG –> Logistics Execution –> Extended Warehouse Management Integration –> Direct Outbound Delivery –> Map Item type from EWM to ECC.
Step3: Create Direct ODO in EWM.
Here Partner is Receiving Plant in my case 4902.
Now Save the Delivery.
Now system triggers the below two FM’s to create PO & Delivery.
/SPE/CREATE_STO_FOR_DIRDLV – Create STO from Direct ODO
/SPE/DELIVERY_CREATE_FROM_STO – Delivery Create From STO
Storage location is not filling in PO( need to check ).
Step4: Rest of the process is as same as normal STO with EWM.
Hint: you can create a custom RF transaction in EWM with very few input fields( rest will be picked from customizing ) to trigger the STO Process from EWM
Source: https://blogs.sap.com/2019/06/23/create-sto-delivery-from-ewm-odo/
sábado, 22 de junho de 2019
S/4 HANA EWM Two Steps Cross Company Process and EWM – ERP integrations
This document shows that how to establish the relationship between EWM and ERP systems in the Cross Company process.
I have completed the necessary implementation steps for the EWM Cross Company Process. Testing processes have been started with sample goods issue from EWM storage location for EWM Cross Company process. In our case, stock warehouse was decreased in EWM system but we didn’t observe the same decrease in ERP sytem which belong to same EWM warehouse. i have checked the T-Code SMQ2 (inbound queue) but i didn’t observe any error message. Then, i have designed similar implementation steps once again and new error message occured while i was trying to do our testing process.
Error Message: /SCWM/ERPINTEGRATION089
In the current situation, Mr. Ozgur has provided assistance and we have found a solution for that case. You can able to find the highlights in note which has been shared by SAP in the past few days.
https://launchpad.support.sap.com/#/notes/2462035
We are matching outbound delivery orders from ” Assignment of Quantity Roles ”
The following implementations are independent from above SAP Note.
The intergration must be done between EWM and ERP systems after above implementation steps are completed properly.
We will choose the “Confirm in Foreground”(1) button. Then, we will entered the Storage address to the “Destination Storage Bin” field (2). The “Warehouse task” will be confirmed with clicking the “Confirm+Save”(3) buttons. If the storage address is determined automatically, you can able to pass this step directly by clicking the “Create WT in Background” button in the background.
Go to transaction code /SCWM/PRDO. We can make goods issue with Delivery Order number (EWM) or Outbound Delivery Document (ERP)
After making goods issue, We will go to /SCWM/MON tcode to check EWM stocks. We can see the material’s physical stocks which was making goods issue. We can not display the batch number (1000001124) in screen because goods issue has been completed from batch (1000001124).
I have completed the necessary implementation steps for the EWM Cross Company Process. Testing processes have been started with sample goods issue from EWM storage location for EWM Cross Company process. In our case, stock warehouse was decreased in EWM system but we didn’t observe the same decrease in ERP sytem which belong to same EWM warehouse. i have checked the T-Code SMQ2 (inbound queue) but i didn’t observe any error message. Then, i have designed similar implementation steps once again and new error message occured while i was trying to do our testing process.
Error Message: /SCWM/ERPINTEGRATION089
In the current situation, Mr. Ozgur has provided assistance and we have found a solution for that case. You can able to find the highlights in note which has been shared by SAP in the past few days.
SAP Note;
https://launchpad.support.sap.com/#/notes/2374224https://launchpad.support.sap.com/#/notes/2462035
The implementation has been done according to SAP Note. You can able to find the details in below.
We are matching outbound delivery order with EWM standard.
”In this Customizing activity, you can define the quantity offsetting profiles for the document types and item types in delivery processing.
Each quantity allocation profile is assigned to a system profile. The quantity offsetting profile takes the quantity roles, quantity determination rules and quantity offsetting rules from the corresponding system profile.”
We are matching outbound delivery orders from ” Assignment of Quantity Roles ”
The following parameters must be defined from the Quantity Determination tab.
The following implementations are independent from above SAP Note.
The intergration must be done between EWM and ERP systems after above implementation steps are completed properly.
Number ranges have to be maintained for ERP documents. Then, other implementation steps will be continued respectively.
We are creating a connection between ERP Delivery type and EWM Delivery Document.
We are matching Document type (ZNLC) and Item type (NLC) with EWM document type. We have used ” Differentiation Attribute for Item Type Mapping (E) ” to make it different from other item matches. Then, we associated with ODLV as EWM item type.
In the next step, we create the relationship between ERP Termin type, EWM Document Type and Item Type.
”The warehouse request differentiates between:
•Start and end date/time
•Planned and actual date/time
This means that both planned and actual start and end dates/times can be stored in the warehouse request.
When a delivery is received in the EWM system, the date/time types from the ERP system can be mapped to the start and/or end dates/times in the warehouse request. The start and/or end dates/times are then automatically stored as planned dates/times.
If you have defined that a confirmation be sent for start and/or end dates/times, these are confirmed to the ERP system when the confirmation occurs. The confirmation of dates/times occurs at the same time as the goods receipt or goods issue is reported to the ERP system.”
The next step will be message process implementation for ERP document type after above implementation steps are performed completely.
You have to maintain ” Configure Delivery Type & Availability Check Procedure by Plant ” as shown below.
”In this step, you specify whether an SD delivery is to be created in the case of a PO with a certain combination of supplying plant and document type. You can also specify which delivery type is to be used. For stock transfers with a billing document, the delivery type ‘NLCC’ is used.”
Standard NLC delivery type has been customized (Z).
I was asked to fulfill the two-step cross company process. Therefore, the fiction was made according to him.
In this step, you define which document type is to be used for a certain combination of supplying plant and receiving plant.
Cross company process will be unique step if you choose one step field as shown below.
The only requested thing that cross company process must be perform in 2 steps. Therefore, the fiction was designed accordingly.
”Depending on the supplying and issuing plants, you can also specify whether or not the stock transfer is to be executed according to the one-step procedure. With the one-step-procedure, the goods receipt in the receiving plant is posted at the same time as the goods issue in the issuing plant.”
Let’s test the accuracy of the customizing steps by testing a sample process in the system.
Let’s check the EWM and ERP stocks to see the changes before starting the processes.
The process will be started with purchase order step. If your implementations are correctly maintained, shipping tab will appear on screen. You can able to validate of data from there.
Outbound delivery document will be performed in background on T-Code VL10D/VL10B with using purchase order numbers. (5000000008)
You need to access to VL02N with the outbound delivery document number. The delivery document will be picking.
EWM storage address( W002) must be entered to storage location field and changes must be saved.
Go to /SCWM/MON and enter Outbound Delivery Order (Outbound -> Documents -> Outbound Delivery Order). Run the delivery document (80000227) by entering it to the ERP Document field on the incoming pop-up screen.
Then the warehouse task will be created for the Delivery Document (100000806) which is created on EWM.
After creating the warehouse task, we will go to the step of confirming warehouse task. We must enter the destination storage address manually due to customizing. Therefore, we will go to the ‘Confirm Warehouse Task in Foreground’ step to confirm the Warehouse task.
Here is the goods issue batch number (1000001124) from EWM and ERP systems.
The status field will change as ‘C’ after the warehouse task is confirmed. When the Warehouse task is confirmed, we are going to make goods issues with delivery document which has been created on EWM system.
Go to transaction code /SCWM/PRDO. We can make goods issue with Delivery Order number (EWM) or Outbound Delivery Document (ERP)
After you made a goods issue via SCWM/PRDO you can able to follow any error message from T-code SMQ2 to be sure abaout your process completed successfully or not.
Go to transaction code VL03N and check the information on the delivery document.
We will make goods issue(643 movement type) according to the delivery document on Two steps Cross company process. Then, we will make goods receipt referenced purchase order(101 movement type).
The goods entrance step will be started in ERP side after goods issue is done of EWM delivery document.Purchase order will be taken as references while goods entrance is processing.
I would like to mention the important points to be taken into consideration while entering goods according to the order on the ERP system;
In the two step cross company process, batch of material is disappearing while making goods issue. I want to mention an important point that you need to use same batch number while making a goods entrance in ERP system.
User has to enter batch number manually or has to read correct batch number with hand terminal(RFU device). User may make a mistake while using hand terminal or while entering batch number manually.
We need to make X batch’s goods issue from ERP and EWM stocks
The quantity of making goods issue on Two Steps Cross Company process is not be appear automatically on MIGO screen. We have to be carefoult that the quantity of making goods issue and the quantity of purchase order are can be different.
The quantity of making goods issue from W002 storage(643 movement type) and the quantity of making goods receipt (101 movement type) referenced to purchase order are have to be same. You can see as below..
After making goods issue, We will go to /SCWM/MON tcode to check EWM stocks. We can see the material’s physical stocks which was making goods issue. We can not display the batch number (1000001124) in screen because goods issue has been completed from batch (1000001124).
When we check the stocks in ERP side from transaction code MB52, you can able to see that 1000001124 batch has not stocks.
Two Steps Cross Company process and the integration between EWM and ERP systems have been completed successfully. The test results are correct as you can see.
Hopefully, this blog will be helpful for everyone
Orhan Akman
Assinar:
Postagens (Atom)