- SAP Managed Tags:
In sales orders, texts can bring meaningful context from buyers to suppliers, or record internal notes entered by the internal employees who act as an important role in EDI communication. Hence it is important to handle the text mapping in sales order inbound EDI. This blog will explain the text mapping rules in sales order EDI and show how to use Cloud BAdIs to customize text mapping.
In the XML payload of the "OrderRequest_In" SOAP service, Text node is used to store a segment of text data with specified types. Taking two nodes as examples in the image, this XML segment specifies two types of text: "PickPackInstructions" and "SalesNote". Under each text node, it specifies the language (EN, FR) and text content ('Test', 'Bonjour').
Previously, text mapping primarily relies on a configuration activity to define mapping rules. This configuration activity has a total of five columns, where the first three columns serve as conditions, and the last two are result. The "XML Message Type" field has a fixed value of "OrderRequest", which stands for Sales Order EDI. The second field "Text Object" has two selectable values: 'header' and 'item', which indicates whether the system should look at the header text or item text
The third field "XML Text Type" is the text type demonstrated in section 1. Only three XML text types are acceptable for text nodes in the sales order header, and likewise, only three XML text types are acceptable for text nodes in the sales order item (see pictures above).
The “Text Procedure” field is generally T3, while the “Text ID” field determines which kind of text type do you want to show on the sales order.
As shown in the section 2, no matter it is for the header or item, only three XML text types are supported. Inbound EDI cannot handle other XML text types that may be sent by the buyer through third-party client. Additionally, we cannot selectively ignore unwanted text types. To address these pain points, we can utilize Cloud BAdIs to achieve custom mapping rules.
We have provided two Cloud BAdIs, where one is for header text mapping and the other one is for item text mapping. Both BAdIs are almost the same and we will take the header BAdI as an example.
The importing parameter of this method is a structure with three properties. In EDI, we can filter whether the document type equals to 'TA' (standard order) according to your needs. As usual, the "Text_Procedure" is T3. The final property is the most important "XML_TEXT_TYPE". Here we can define customizing condition to our needs. Even though the payload passed an unsupported text type, we can also directly set the changing parameter which also the resulting field in the configuration activity.
The changing parameter "TEXT_TYPE" consists of 2 properties. "TEXT_ID" is the same as the last result field in the configuration activity, which will be reflected in sales orders. "IGNORE_TEXT" is an ABAP bool type parameter. If we set it as 'X', the filtered text type's content will be ignored.
As shown in example 1, if the payload passes a text node with text type "XMLNOTE1" in order request header, the resulting TEXT_ID will be 'TX01'. The BAdI takes precedence over the configuration activity. Even if we configure the same mapping rule in configuration activity but with a different "TEXT_ID", the result determined by BAdI will override the result from configuration activity.
For example 2, though we set the TEXT_ID for text type "XMLNOTE2", but we also set the IGNORE_TEXT as 'X' (true),then on sales order the text "Bonjour" will not be shown, because it was ignored
If you have any thoughts or comment, please comment me directly under this blog. Also Please check community tag(Link) for other knowledges about S/4HANA Cloud for Sales. You can also post and answer questions here.
1.Texts Node introduction in Payload
Text Node Example in Payload
In the XML payload of the "OrderRequest_In" SOAP service, Text node is used to store a segment of text data with specified types. Taking two nodes as examples in the image, this XML segment specifies two types of text: "PickPackInstructions" and "SalesNote". Under each text node, it specifies the language (EN, FR) and text content ('Test', 'Bonjour').
2.Mapping Rules in EDI inbound Process Without Cloud BAdls
SSCUI for Defining Mapping Rules
Previously, text mapping primarily relies on a configuration activity to define mapping rules. This configuration activity has a total of five columns, where the first three columns serve as conditions, and the last two are result. The "XML Message Type" field has a fixed value of "OrderRequest", which stands for Sales Order EDI. The second field "Text Object" has two selectable values: 'header' and 'item', which indicates whether the system should look at the header text or item text
Three Allowed XML Text Types for Header
Three Allowed XML Text Types for Item
The third field "XML Text Type" is the text type demonstrated in section 1. Only three XML text types are acceptable for text nodes in the sales order header, and likewise, only three XML text types are acceptable for text nodes in the sales order item (see pictures above).
The “Text Procedure” field is generally T3, while the “Text ID” field determines which kind of text type do you want to show on the sales order.
Text ID Reflect the Txt Content on Sales Order
3.Using Cloud BAdls to customize your Mapping Rules
As shown in the section 2, no matter it is for the header or item, only three XML text types are supported. Inbound EDI cannot handle other XML text types that may be sent by the buyer through third-party client. Additionally, we cannot selectively ignore unwanted text types. To address these pain points, we can utilize Cloud BAdIs to achieve custom mapping rules.
BAdI Code Example
We have provided two Cloud BAdIs, where one is for header text mapping and the other one is for item text mapping. Both BAdIs are almost the same and we will take the header BAdI as an example.
3.1 Parameter Introduction
The importing parameter of this method is a structure with three properties. In EDI, we can filter whether the document type equals to 'TA' (standard order) according to your needs. As usual, the "Text_Procedure" is T3. The final property is the most important "XML_TEXT_TYPE". Here we can define customizing condition to our needs. Even though the payload passed an unsupported text type, we can also directly set the changing parameter which also the resulting field in the configuration activity.
The changing parameter "TEXT_TYPE" consists of 2 properties. "TEXT_ID" is the same as the last result field in the configuration activity, which will be reflected in sales orders. "IGNORE_TEXT" is an ABAP bool type parameter. If we set it as 'X', the filtered text type's content will be ignored.
3.2 Code Sample
Payload for Code Example 1
As shown in example 1, if the payload passes a text node with text type "XMLNOTE1" in order request header, the resulting TEXT_ID will be 'TX01'. The BAdI takes precedence over the configuration activity. Even if we configure the same mapping rule in configuration activity but with a different "TEXT_ID", the result determined by BAdI will override the result from configuration activity.
Payload for Code Example 2
For example 2, though we set the TEXT_ID for text type "XMLNOTE2", but we also set the IGNORE_TEXT as 'X' (true),then on sales order the text "Bonjour" will not be shown, because it was ignored
Additional Note.
If you have any thoughts or comment, please comment me directly under this blog. Also Please check community tag(Link) for other knowledges about S/4HANA Cloud for Sales. You can also post and answer questions here.
