Partager via

Some recent EDI fixes of interest

  • Article

(Posted on behalf of mstern)

https://support.microsoft.com/kb/945165/en-us

You may receive error messages when you receive an X12 997 functional ACK without the AK304 segment in a BizTalk Server 2006 R2 EDI application

https://support.microsoft.com/kb/947459/en-us

FIX: The GS04 header value uses the CCYYMM format instead of the YYMMDD format in BizTalk Server 2006 R2

https://support.microsoft.com/kb/948747/en-us

You may receive an event ID 5753 error message when you try to use the BizTalk Server 2006 R2 EDI functionality with MSMQ transport

Fixes soon to be released. (Contact PSS for further information)

KB 945998

EDIFACT: If comma as decimal separator is specified in UNA segment in incoming message, monetary values are incorrectly handled by cumulative functoid

You receive an EDIFACT with an UNA segment specifying "," (comma) as decimal separator. The message is then processed in a map, using the cumulative sum functoid. This may result in unexpected results, as the cumulative sum functoid expects values only with a ".". No error is thrown but the "," is just ignored and incorrect monetary amounts are calculated.

The fix will add a property to the EDI disassembler pipeline component that will enable/disable normalization of a decimal separator.

KB 952195

EDIFACT: When UNH2.5 is present it is being used for schema lookup

E.g., you have an UNH field similar to this in your EDIFACT message

UNH+12345+INVOIC:D:93A:UN:ABCDEF

The EDIReceive pipeline will discover the document type to:

https://schemas.microsoft.com/BizTalk/EDI/EDIFACT/2006\#EFACT\_D93A\_INVOIC\_ABCDEF

To process that message, hitherto you needed to deploy a schema with the rootnodename: EFACT_D93A_INVOIC_ABCDEF

For each D93A_INVOIC with a different UNH2.5 segment you would have to deploy an individual schema.

KB 952195 now introduces new functionality in the EDI pipeline: we first look for a deployed schema with 2.5 added to the rootnodename. if it can't find one, it will try to find the schema without UNH2.5 in the rootnodename.

That way you can still use individual D93A_INVOIC_<UNH25> (or any other) schemas for partners with specific UNH2.5 values, but you can also use the standard schemas without using the UNH2.5 information.