GDSNDocumentId

The GDSNDocumentId and GDSNParentDocumentId export functions create unique identifiers for each document output in an export file. Note: these functions are only used and available for the IM pool.

EnumerationKey

Usually, GDSN messages contain codes for attributes that refer to a valid values list. By default, an exports output the labels for such attributes. The EnumerationKey export function is used to output the code instead of the label of enumeration values.

EnumerationKeyStandard

In contrast to the function EnumerationKey, this function can only be used for data having an enumeration assigned which is an extension of a standard enumeration. The function only returns a key if the value is contained in the standard enumeration, keys of the extended enumeration won't be returned.

This is needed for data fields that are logical keys in the data model but should be empty in the context of GDSN. Those fields got enumerations providing all valid GDSN values and a "<no code>" value.

GDSNEnumerationCode

Some GDSN attributes use other codes than the codes maintained in PIM. This function reads the GDSN codes from the corresponding configuration. It is possible to add additional codes, see Repository configurations.

GDSNDutyFeeTaxAgencyCode

The value for DutyFeeTaxAgencyCode depends on the target market and the tax type. The DSE specific export function GDSNDutyFeeTaxAgencyCode returns the configured value for "DutyFeeTaxAgencyCode" depending on target market and tax type.

Similar to the enumeration codes you can configure the values for DutyFeeTaxAgencyCode in the plugin_customization.properties file. The pattern of such entries is

com.heiler.ppm.gdsn.core/GDSN.dutyFeeTaxAgencyCode.<target market code>.<tax type code> = <DutyFeeTaxAgencyCode>

Empty values

All optional fields don't create a XML tags in case there is no value maintained. This is needed because an error will occur for empty tags. For this the export function CreateXMLTagWithValue respectively CreateXMLTagWithContent are used.

Format numbers and dates

It is important to format the numbers and dates in the needed format of the GDSN pool.

Therefore all fields with numbers must use the FormatDecimal export function. This function is responsible for formatting and transferring the given number according to the specified decimal separator and the number of decimal places. The decimal separator must be always "." for decimal values. All used date fields will use the FormatDate export function which is formatting the given date with a given pattern to match the needed format.

Encoding

There is need for defining or prevent the encoding of strings according to their encoding setting. There are possibilities to define this actively by the export functions IfNotEmptyThenNotEnc or IfEmptyThenNotEnc and inactively by using export function which are handling the encoding already like CreateXMLTagWithValue which returns the transferred fragment itself as not encoded.

Conditional output

The data to output often depends on if any other specific data is set. Therefore you can define a conditional output by using export functions around the section that is to be output if the condition is fulfilled. This is possible in general by using the IfNotEmptyThen export function or you can use specific export functions to generate conditional output by using a Boolean comparison with the CompareBooleanValue export function for example. Besides this it is also possible to define a default value for some export functions.

Debug

There are two different possibilities to enable some debug information to be able to detect a problem.

Check output

There are different ways to provide the opportunity to inspect the output XML file when errors occurs. Find two examples described in more detail below.

Add an additional "Copy export file" post-processing step before the "Validate XML file(s)" step. Define a specific target directory for this new export step. Whenever an export will be executed the export file will be copied to the target directory even if the XML validation will cause on error. But the target directory will always only contain the last executed export file.

Another way would be to disable the cancelling of the export within the "Validate XML file(s)" export step by setting the "Cancel export in case of error" to "No". Furthermore you need to change the "copy export file" target directory because you will probably send not valid XML files to the GDSN pool which will lead to errors.

With both of the mentioned examples it is possible to find out what the output is on a specific line in a XSD validation error. This makes it easier to figure out where a problem is in the data and/or template.

Besides this, it's always possible to manually transfer the export files to the pool. To put this into action the "Copy export file" export step can be deleted and after each export execution the export file can be downloaded in case of no error. This file has to be copied manually into the B2B DX receive endpoint directory.