This blog is targeted to ABAP technical team working on S4 HANA conversion projects.
In S4HANA conversion program, custom code impact analysis is the most important stage. In this stage ATC check variant S4HANA_READINESS_<release>is executed on the custom code to identify the areas of impact on the custom code with respect to HANA database and S4 HANA application.
HANA database impact analysis covers following observations
- Missing of ORDER BY statement in the SELECT statements.
- Use of Database HINTs
- Non unique SELECT SINGLE statements Etc.
S4HANA impact analysis covers following area-
- Field length extension related to Material , Amount and Segment.
- Views using the simplified tables
- Database operations on simplified tables
- Usage of deprecated objects like Function modules, domains, data elements etc.
In this blog I am going to discuss impact of MATERIAL field length extension on the custom code.
What is changed in Material Field length from ECC to S4 HANA?
Material Length is CHAR18 in ECC
Material Length is CHAR40 in S4 HANA
As you see here Material Field length has been changed from 18 CHAR to 40 CHAR from ECC to S4 HANA. Hence after conversion to S4 HANA , development team must adjust the custom code wherever data element / domain MATNR is being used in the data definition of Material variables in custom code .
How to Identify is customer has adapted extended field length of Material?
Transaction FLETS
FLETS This transaction is used for extending the Material Field Length to 40 CHAR
Another transaction OMSL used for setting the Material Number Format. This setting decides how many characters of Material to be displayed including all characters like punctuation, full stop etc.
What is impact on the custom code if extended Material Field length needs to be adapted?
Let’s see the example of WRITE statement.
DATA: lv_material TYPE matnr18,
lv_matnr18 TYPE matnr18,
lv_matnr TYPE matnr.
lv_matnr18 = ‘00000000345466’.
lv_matnr = ‘0000000000000045678900000000003534534590′.
lv_material = lv_matnr.
WRITE : lv_material.Output
4567
As you see here 40 CHAR material is being passed to variable of 18 CHAR , the code was written in ECC environment. However after conversion as new Materials will have length of CHAR40, the same old code will not work since it will truncate the characters after 18, hence in output, only characters up to length 18 are being displayed.
Therefore the code needs to be adapted as per new Material length , that is CHAR40.
What is impact on the custom code if extended Material Field length not adapted?
Let’s take similar example
DATA: lv_material TYPE matnr,
lv_matnr18 TYPE matnr18,
lv_matnr TYPE matnr.
lv_matnr18 = ‘00000000345466’.
lv_material = ‘00000000345466’.
WRITE: / lv_material, ‘End’,
/ lv_matnr18, ‘End’.Output
As you see, we are passing same material number in 2 variables with different data type that is MATNR18 and MATNR(40). The output shows how the same material number is displayed with 2 variables. If we do not adjust the data type of lv_material to MATNR18 post conversion, the WRITE statement will be impacted and program will show distorted output.
Therefore development team must analyze the impact on custom code and then adjust custom code so that old material length will be used post conversion with zero impact of functionality of the program.
Now we will see, how to analyze the impact on custom code and how to adjust the custom code with some examples.
Steps to Analyze the Field Length Extension impact on custom code?
1. Update Simplification database with latest information.
This most important step before running the custom code impact analysis.
After updating the database, Go to Transaction SYCM and verify if Simplification database has been updated.
Click on Overview
2. Edit the READINESS check variant in Transaction SCI
SAP has provided standard check variant S4HANA_READINESS_<release> to perform the analysis on the custom code. It not only covers FLE ( Field Length Extension) scenarios but lot of other scenarios as well.
Open READINESS Check variant S4HANA_READINESS_<release>
In my case it is S4HANA_READINESS_2021
Open check variant in Edit mode.
Click on highlighted arrow
Maintain the no of characters of Material Field to be used by customer as per the requirement. Make sure that the Character value is maintained as per FLETS and OMSL configurations in the S4 HANA system. Save the changes in the transport request. You can also create custom variant by copying the Standard check variant and then make changes in the custom check variant.
3. Execute ABAP Test cockpit (ATC) check on the custom package.
sample ATC Output
Now let’s see some of the most prominent issues from ATC output related to Material Field Length extension.
Here I am discussing the scenario where customer is adapting extended field length of Material. In brackets you can find the message code of particular issue . You can find these message codes if you execute the Readiness analysis with SCI transaction.
- Compare Length Conflict (Message code COMP_LENG)
- Old Compare length conflict (Message code COMP_LENGO)
- Old Compare type conflict (Message code COMP_TYPE)
- Concatenate (Message code CONCAT)
- Move Length Conflict (Message code MOVE_CUT)
- Structure-Component Length Conflict (Message code MVC_CUT)
Solution
- Offset/Length-Access (Message code OFFLEN)
- Transfer (Message code TRANSFER)
As you see in all the above cases, we must adjust the data type to material to new MATNR so that all characters of new Materials will be considered.
Similarly, when customer is not going to adapt the new MATERIAL field length extension, developer must adjust the data type to MATNR18 to wherever required.
How should I keep custom code “S4 HANA compatible” going forward?
The answer is very simple , include the ATC checks in the code review checklist with readiness check variant S4HANA_READINESS_<release>. Development team must execute the ATC check on the custom code before releasing the transport request.
