In a previous project, I worked with EDI message to interchange with partners, but before I send the message to the partner I have the need to pass then to the loopback adaptor, that was configured with EDISend pipeline and EDIReceive Pipeline.
The objective is to get some proprieties, configured in the Party, that I need to precede the orchestration.
The send work well and create a correct EDI message, but on the receive, I expect an Edifact Interchange Message but when I receive back the message it gives the following error:
“Transation Set Errors
Sequence No: 1
TS Id code: INVOIC
Control Number: 1
Error: 1 (Field level error)
Position in TS: 13
Data Element ID: C08001
Position in Segment: 5
Position in Field: 1
Data Value: XXXXXXXXX Xï¿½X DE Xï¿½XXXX XX XXXXX
39: Data element too long
For more information, see Help and Support Center at”
- The value “C08001” is too long for the defined length of the element.
This error is simple and it occurs because the total of characters, including spaces, is greatest that what is allowed in element C08001, “XXXXXXXXX Xï¿½X DE Xï¿½XXXX XX XXXXX” contains 36 chars and the element allows 35.
But, if you look carefully, the string has encoding problem:
- The first sequence of these 3 characters “ï¿½” represents the char “Ã”
- And the second sequence represents the char “Ç”
In my case, the problem is not the size of the string but the character set configured in the party, which causes that the string length is greatest than it really is.
- Check the max length of the UNB9 element and correct your data. If you and your trading partner agree, both may increase the max length, in which case you would modify your schema.
To resolved encoding problems (my situation)
- In the party, select EDI Properties and change the character set for a party by setting the UNB1.1 party property in the UNB Segment Definition property page for the party as interchange receiver.
- Under “Party as Interchange Receiver” -> “EDIFACT Interchange Envelope Generation” -> “UNB Segment Definition” –> “Syntax (UNB1)” -> “UNB1.1 (Identifier)”
- In my case, I used UNOD, more tolerant encoding (As defined in ISO 8859-2 : Information processing – Part 2: Latin alphabet No. 2.)