none
What are the "invalid characters"? RRS feed

  • Question

  • Hello, I sometimes get errors like the following when receiving inbound 810 files:

     

    Error encountered during parsing. The X12 transaction set with id '0167' contained in functional group with id '1364', in interchange with id '000001364', with sender id 'THEM           ', receiver id 'US             ' is being suspended with following errors:

    Error: 1 (Field level error)
     SegmentID: N1
     Position in TS: 5
     Data Element ID: N102
     Position in Segment: 2
     Data Value:
     6: Invalid character in data element

    Error: 2 (Field level error)
     SegmentID: N2
     Position in TS: 6
     Data Element ID: N201
     Position in Segment: 1
     Data Value:
     6: Invalid character in data element


     

    What is the list of "invalid characters" that cannot be used?

     

    Thanks

     

    ----------------------------

     

    EDIT 08/08/07:

     

    We found out the invalid character to be hex "A0". Please see Nikos_Y's question. Thanks.

    Tuesday, August 7, 2007 4:14 PM

Answers

  • Both X12 and EDIFACT define this notion of character encodings (Basic, Extended and UTF8 for X12 and UNOA, UNOB etc for EDIFACT). For example Basic in X12 allows for all upper case ASCII characters, whereas Extended allows all of Basic plus lower case. If you set Basic encoding in your settings, and you encounter a lower case character in your instance, that character would be termed as invalid character.

     

    So one form of invalid character is of type when it falls outside of the allowed character encoding set in your settings. This can be fixed by adjusting the character encoding property. More information on the allowed character types for X12 can be found under this thread.

     

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1502001&SiteID=1

     

    Another form of invalid characters are the leading and trailing zeroes and spaces. EDI engine will flag any fields with leading and trailing zeroes and spaces (unless these zeroes and spaces and required for min length restriction). This can be fixed by checking the property "Allow leading and Trailing Zeroes and Spaces" under Party as Interchange Sender (for parsing a document) and under Party as Interchange Receiver (for serializing).

     

    Hope this helps

    Mohsin

     

    Tuesday, August 7, 2007 8:20 PM
  • Extended expect the encoding page to be Latin 1 (ISO8859-1 code page)

    Wednesday, August 8, 2007 10:31 PM

All replies

  • Both X12 and EDIFACT define this notion of character encodings (Basic, Extended and UTF8 for X12 and UNOA, UNOB etc for EDIFACT). For example Basic in X12 allows for all upper case ASCII characters, whereas Extended allows all of Basic plus lower case. If you set Basic encoding in your settings, and you encounter a lower case character in your instance, that character would be termed as invalid character.

     

    So one form of invalid character is of type when it falls outside of the allowed character encoding set in your settings. This can be fixed by adjusting the character encoding property. More information on the allowed character types for X12 can be found under this thread.

     

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1502001&SiteID=1

     

    Another form of invalid characters are the leading and trailing zeroes and spaces. EDI engine will flag any fields with leading and trailing zeroes and spaces (unless these zeroes and spaces and required for min length restriction). This can be fixed by checking the property "Allow leading and Trailing Zeroes and Spaces" under Party as Interchange Sender (for parsing a document) and under Party as Interchange Receiver (for serializing).

     

    Hope this helps

    Mohsin

     

    Tuesday, August 7, 2007 8:20 PM
  • Just one thing to add. I have an EDIFACT implementation with R2, and just had the same issue.

     

    All the files came with UNOA but using extended characters as & , and so on.  It seems that other product are less strict than Biztalk when it comes to generate or parse EDI files.

     

    It's very annoying ,since there's no config (at least I didnt find one) to ignore the setting of that particular segment, so the only think I could think of to solve that is to preprocess file and change the segment to UNOB or UNOC.

     

    Victor

    Tuesday, August 7, 2007 11:26 PM
  • The received EDI document comes to us in ANSI format.   In it, there are a number of occurences of hexidecimal A0 which appears as a space in the upper collation sequence for ANSI (regular space is hex 20). If we then take that document and convert it to UETF-8 (Unicode), it goes to hexidecimal C2 A0.  The converted document will be processed correctly by the EDIReceive pipeline which is expecting UETF-8.  If, however we send the document in in its orginal ANSI format and have the EDIReceive set to use Extended character encoding, we get the error.   (Does extended character encoding assume that the input document is ANSI or does it have to be UTF8?

     

    Thanks

    Nikos

     

    Wednesday, August 8, 2007 9:32 PM
  • Extended expect the encoding page to be Latin 1 (ISO8859-1 code page)

    Wednesday, August 8, 2007 10:31 PM