Introduction
In many B2B integration scenarios, it’s common to encounter values that must be converted depending on a specific dimension—such as weight, length, volume, or even currency. Each of these dimensions can have multiple possible units, and the integration process must ensure that the target payload uses the correct unit and precision.
For instance, this article uses a weight conversion example involving kilograms (KGM), grams (GRM), and decigrams (DG). However, similar challenges arise with other measurements, eg. centimeters vs. meters, liters vs. milliliters, or different currency codes with varying decimal rules. Without proper handling, these mismatches can cause data errors, disrupt downstream processes, and lead to costly corrections.
At present, the Integration Advisor’s Mapping Guideline (MAG) does not include built-in functions for this type of unit-based calculation with dynamic precision control. However such functionality can be implemented by applying an XSLT transformation MAGs.
In this blog, we will explore an XSLT-based approach using the KGM/GRM/DG case as an example and the same pattern can be adapted to many other dimensions in B2B integration scenarios.
Example: Mapping Quantity with UnitCode from EDIFACT to SAP SOAP
Let´s assume that a trading partner X sends an UN/EDIFACT D.10B Purchase orders to my company, and we want to receive OrderRequest as an SOAP message.
In the source message, the data element “6060” quantity and “6411” measurement unit code in the segment “QTY”. And the data element “unitCode” unitCode and “CONTENT” quantity in the segment “RequestedQuantity” of the target message.
We assume that my company expects the quantity with the unit KGM, therefore in order to handle a mapping from source path /ORDERS/SG29/QTY where the data element 6063 equals KGM/GRM/DG, to target path /OrderRequest/Order/OrderItem/RequestedQuantity with the attribute unitCode=”KGM”, we will need the following steps.
In the target MIG(Message Implementation Guidelines), select and assign Codelist to the unitCode. Then qualifer the segment “RequestedQuantity” with KGM.
In the Shared Code of MAG(Mapping Guidelines), input the following xslt code with the name fx_sumOfDimensionValues_in_KGM. Then it is possible to assign this shared code into mapping function for the quantity mapping.<xsl:variable name=”vFraction” select=”‘4′” />
<xsl:variable name=”vFraString”
select=”string-join(for $i in 1 to xs:integer($vFraction) return ‘0’, ”)” />
<xsl:variable name=”vSum” select=”
if (upper-case($nodes_in[1]/D_6411) = ‘GRM’) then
xs:decimal(sum($nodes_in[1]/D_6060) div 1000)
else if (upper-case($nodes_in[1]/D_6411) = ‘DG’) then
xs:decimal(sum($nodes_in[1]/D_6060) div 100)
else if (upper-case($nodes_in[1]/D_6411) = ‘KGM’) then xs:decimal(sum($nodes_in[1]/D_6060))
else sum($nodes_in[1]/D_6060)
“/>
<xsl:value-of select=”format-number($vSum, concat(‘#0.’, $vFraString))” />
This snippet first defines a variable $vFraction to control the decimal precision dynamically. In this case, the value is set to 4, meaning that the final output will always display up to four decimal places. The second variable, $vFraString, creates a string of zeros corresponding to the precision length, which is later used by the format-number() function to ensure consistent formatting.
The heart of the logic is in the $vSum variable. Here, we inspect the unit code from the source element D_6411 and apply the appropriate conversion:
GRM → KGM: Divide by 1,000 (grams to kilograms)DG → KGM: Divide by 100 (decigrams to kilograms)KGM → KGM: No conversion needed, the value is used as-isFallback: If the unit code does not match any of the above, the raw value is used without conversion
Finally, format-number() applies the desired precision formatting by combining #0. with the zero string generated earlier. This ensures that regardless of the original format, the resulting value in the target XML will adhere to a consistent numeric pattern—essential for downstream systems that rely on strict schema validation.
Adapting the Pattern for Other Dimensions
Although this example focuses on weight conversion, the same approach can be applied to other measurable dimensions. For example:
Length: mm ↔ cm ↔ mVolume: ml ↔ L ↔ m³Currency: adjusting for minor units (e.g., cents vs. yen)Custom Units: industry-specific codes with defined conversion ratios
The main changes involve:
Adjusting the if/else if logic to account for the specific unit codes you expect in the source.Modifying the conversion factor according to the required unit transformation.Setting $vFraction to match the level of precision required by your target system.
Summary
By embedding this logic directly into the MAG’s XSLT, you gain:
Dynamic Unit Handling: No need to pre-normalize values outside the integration flow.Precision Control: Flexible decimal formatting without post-processing.Reusability: The pattern can be packaged as a reusable function and applied across multiple mappings.
This approach ensures your integration not only transforms the data structure but also intelligently adapts values, reducing manual intervention and preventing costly data mismatches.
IntroductionIn many B2B integration scenarios, it’s common to encounter values that must be converted depending on a specific dimension—such as weight, length, volume, or even currency. Each of these dimensions can have multiple possible units, and the integration process must ensure that the target payload uses the correct unit and precision.For instance, this article uses a weight conversion example involving kilograms (KGM), grams (GRM), and decigrams (DG). However, similar challenges arise with other measurements, eg. centimeters vs. meters, liters vs. milliliters, or different currency codes with varying decimal rules. Without proper handling, these mismatches can cause data errors, disrupt downstream processes, and lead to costly corrections.At present, the Integration Advisor’s Mapping Guideline (MAG) does not include built-in functions for this type of unit-based calculation with dynamic precision control. However such functionality can be implemented by applying an XSLT transformation MAGs.In this blog, we will explore an XSLT-based approach using the KGM/GRM/DG case as an example and the same pattern can be adapted to many other dimensions in B2B integration scenarios.Example: Mapping Quantity with UnitCode from EDIFACT to SAP SOAPLet´s assume that a trading partner X sends an UN/EDIFACT D.10B Purchase orders to my company, and we want to receive OrderRequest as an SOAP message.In the source message, the data element “6060” quantity and “6411” measurement unit code in the segment “QTY”. And the data element “unitCode” unitCode and “CONTENT” quantity in the segment “RequestedQuantity” of the target message. We assume that my company expects the quantity with the unit KGM, therefore in order to handle a mapping from source path /ORDERS/SG29/QTY where the data element 6063 equals KGM/GRM/DG, to target path /OrderRequest/Order/OrderItem/RequestedQuantity with the attribute unitCode=”KGM”, we will need the following steps.In the target MIG(Message Implementation Guidelines), select and assign Codelist to the unitCode. Then qualifer the segment “RequestedQuantity” with KGM. In the Shared Code of MAG(Mapping Guidelines), input the following xslt code with the name fx_sumOfDimensionValues_in_KGM. Then it is possible to assign this shared code into mapping function for the quantity mapping.<xsl:variable name=”vFraction” select=”‘4′” />
<xsl:variable name=”vFraString”
select=”string-join(for $i in 1 to xs:integer($vFraction) return ‘0’, ”)” />
<xsl:variable name=”vSum” select=”
if (upper-case($nodes_in[1]/D_6411) = ‘GRM’) then
xs:decimal(sum($nodes_in[1]/D_6060) div 1000)
else if (upper-case($nodes_in[1]/D_6411) = ‘DG’) then
xs:decimal(sum($nodes_in[1]/D_6060) div 100)
else if (upper-case($nodes_in[1]/D_6411) = ‘KGM’) then xs:decimal(sum($nodes_in[1]/D_6060))
else sum($nodes_in[1]/D_6060)
“/>
<xsl:value-of select=”format-number($vSum, concat(‘#0.’, $vFraString))” />This snippet first defines a variable $vFraction to control the decimal precision dynamically. In this case, the value is set to 4, meaning that the final output will always display up to four decimal places. The second variable, $vFraString, creates a string of zeros corresponding to the precision length, which is later used by the format-number() function to ensure consistent formatting.The heart of the logic is in the $vSum variable. Here, we inspect the unit code from the source element D_6411 and apply the appropriate conversion:GRM → KGM: Divide by 1,000 (grams to kilograms)DG → KGM: Divide by 100 (decigrams to kilograms)KGM → KGM: No conversion needed, the value is used as-isFallback: If the unit code does not match any of the above, the raw value is used without conversionFinally, format-number() applies the desired precision formatting by combining #0. with the zero string generated earlier. This ensures that regardless of the original format, the resulting value in the target XML will adhere to a consistent numeric pattern—essential for downstream systems that rely on strict schema validation. Adapting the Pattern for Other DimensionsAlthough this example focuses on weight conversion, the same approach can be applied to other measurable dimensions. For example:Length: mm ↔ cm ↔ mVolume: ml ↔ L ↔ m³Currency: adjusting for minor units (e.g., cents vs. yen)Custom Units: industry-specific codes with defined conversion ratiosThe main changes involve:Adjusting the if/else if logic to account for the specific unit codes you expect in the source.Modifying the conversion factor according to the required unit transformation.Setting $vFraction to match the level of precision required by your target system. SummaryBy embedding this logic directly into the MAG’s XSLT, you gain:Dynamic Unit Handling: No need to pre-normalize values outside the integration flow.Precision Control: Flexible decimal formatting without post-processing.Reusability: The pattern can be packaged as a reusable function and applied across multiple mappings.This approach ensures your integration not only transforms the data structure but also intelligently adapts values, reducing manual intervention and preventing costly data mismatches. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
