Уловка 22 в создании файла 999

Question

Ну, я должен сказать, что это довольно забавно, когда я встречаю эту ситуацию:

Я отправляю файлы HIPPA 837, и я полагаю, что для создания 999 файлов ACK после получения файла 837. BizTalk сгенерирует сообщение 999, если я настрою для этого соглашение с торговым партнером. И пока все работает отлично.

Сегодня я получил файл 837 с некоторой структурной ошибкой: в элементе есть несколько начальных пробелов. Затем был создан 999, но когда мой порт отправки подписался на это сообщение 999, попытался сохранить его в виде файла, я получил ошибку проверки и жалуется, что само сообщение 999 является недопустимым, поскольку его элемент имеет начальные пробельные символы.....

Ошибка: 3 (ошибка уровня поля)
SegmentID: IK4
Положение в TS: 18
Идентификатор элемента данных: IK44
Положение в сегменте: 4
Значение данных:
6: Найден начальный или конечный пробел

Для меня это выглядит как уловка 22: предполагается, что ваши 999 файлов сообщают об ошибке структуры входящего файла,в качестве части отчета будет указано неверное значение элемента (в моем случае это сегмент IK4), но неправильный элемент само значение делает файл 999 недействительным тоже.

Я просто хочу знать, сталкивался ли кто-нибудь с такой же ситуацией? И что вы предлагаете по этому вопросу?

Answer 1

Я не видел этого, и действительно, я немного удивлен, что это не подходило раньше, если это настоящая добыча-22:)

Попробуйте это, на вкладке "Вы-> Их" в Соглашении установите строку "По умолчанию" в разделе "Проверка", чтобы начальные и конечные пробелы были разрешены.

Возможно, вам придется явно установить для всех других tx значение "Не разрешено", поскольку 999 отсутствует в списке типов транзакций.

Answer 2

Я бы попробовал предложение @Johns-305, но я знаю, что у меня были проблемы с использованием пробела в начале / в конце ранее в соглашении (некоторые поля кажутся мне взорванными, даже если он включен).

Я бы попробовал перехватить сообщение 999 до того, как оно попадет в отправку EDI и использовать normalize-space() (в XSLT) или .Trim() (в C#) на рассматриваемых узлах. Вы можете сделать это, создав порт отправки, который фильтрует на 999 BTS.MessageType,

Это может не полностью соответствовать ожиданиям вашего торгового партнера, поскольку сегмент может быть действительным без пробела (что приводит к путанице в отношении того, почему, возможно, иным образом действительный сегмент был отклонен).

Вы также можете обсудить это с Microsoft, хотя это может быть ограничением использования XML (где начальные пробелы могут рассматриваться как незначительные) для представления EDI (где начальные пробелы - плохие новости).