While working on a BizTalk project that required the exchanging of EDI messages with external partners, I came across a situation whereby the partner’s EDIFact messages contained data elements which exceeded the maximum lengths as dictated by their Message Implementation Guide (MIG), which also happened to be the default maximum length in the out of the box BizTalk EDI schemas.  And even though they exceeded the maximum lengths, our trading partner still insisted that they were valid values!!!

This specific EDI message was of the COPARN (Container Announcement Message) variety, and the element in question was the temperature element as defined in the below out of the box Coparn D95B schema.

You’ll notice that the minimum and maximum lengths are both set to 3 (as supported by the trading partner’s MIG), so we would expect all temperature setting values to be 3 characters long.  These are just out of the box xsd schema properties, pretty simple.  Regardless whether the data type is string or int, the exact same validation should occur.

The catch is that it was possible (and extremely likely) for refrigerated containers to have negative temperatures, and the trading partner in question pointed us to some documentation which advises that the minus character in negative numbers is a special character which mustn’t be counted towards the length of a data element.

This article states that “Numeric data element values are to be sent as positive. Although conceptually a deduction is negative, it is represented by a positive value: eg in a credit note all values are sent as positive amounts, and the application software will take note of the message name code (DE 1001) and process the values accordingly. In addition some data element and code combinations will lead to implied negative values, eg DE 5463 with code value “A” (allowance) in an ALC segment in an invoice. Again, the values are sent as positive amounts.

If, however, a value has to be explicitly represented as negative, it must be sent immediately preceded by a minus sign, eg -112. The minus sign is not counted as a character when computing the maximum field length of the data element.“

Since refrigerated container temperatures could potentially be greater or less than 0, it is necessary to explicity precede negative numbers with the minus sign, and thus it is not counted.

I haven’t seen any documentation from Microsoft that claims that they have catered for this requirement in any fashion, nor was I able to find any blogs by anyone else at that time that suggested any ideas.

In this specific scenario we took the easy way out and just raised the Maximum Length on the temperature element to be 4 as we really didn’t have any time left to waste in the project to cater for what was essentially a big surprise to us given the lack of documentation (that I could find at least) around this.

Does anyone have a good way to deal with this or is this the only (or just the easiest) option?  I would be extremely wary of this in the future given how big EDI schemas tend to be, and will always discuss this specific scenario with trading partners first rather than trusting their MIGs before settling on using the out of the box schemas.