Ошибка формата ответного сообщения

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

Коды ответов

Результатом выполнения и критерием успешности любой операции является Код ответа (Responce Code (RC)). В рамках протокола ISO 8583 он передается в поле 39 ответного сообщения. Формат RC зависит от версии ISO 8583: в версии ISO 8583:1987 он двузначный, в версии ISO 8583:1993 — трехзначный. Главным образом будем рассматривать обмен в рамках версии 1987 г., по причине ее большей распространенности. При этом заметим, что каждый конкретный разработчик ПЦ использует различные подходы к обеспечению совместимости между версиями: какие-то хосты передают в рамках P2H три символа RC, при этом, в случае если обмен выполняется в рамках версии 1987 г., заполняя лидирующий символ (первый слева) нулем. В других случаях ПЦ выполняет конвертацию трехзначного RC версии 1993 г. — в его двузначный эквивалент версии ISO 8583:1987 и в таком виде отправляет его на POS.

Коды ответов можно разделить на успешные и негативные. Негативным является любой ответ, кроме явного ответа «Одобрено» либо его семантического эквивалента. При этом причиной может быть как техническая ошибка, так и отказ эмитента в выполнении той или иной операции.

Ниже приведем наиболее распространенные RC, разбив их на две условные группы — Технические и Сервисные.

Технические RC

В это группу включим основные коды ответов, полученные в результате тех или иных технических сбоев, либо ошибок при заполнении сообщения. Заметим, что вариативность причин возникновения любого их описанных ниже RC более или менее широка, и в рамках материала дана исключительно в целях примера.

00 — Approved (Одобрено). Транзакция завершена успешно.

12 — Invalid Transaction (Неверная транзакция). Неверны какие-либо параметры транзакции. Допустим, поля сообщения заполнены таким образом, что из них следует, что операция Выдача наличных выполняется в торговом POS-терминале. Что, в общем случае, недопустимо.

13 — Invalid Amount (Неверная сумма). Поле 4 (Сумма) заполнено неверным значением. Данный RC может возникнуть в случае срабатывания какого-либо лимита, либо в рамках операций, подразумевающих предварительную авторизацию с ее последующим завершением (например, предварительное бронирование услуг с последующим расчетом).

14 — Invalid Card Number(Неверный номер карты). Неверно заполнено поле 2 (Номер карты), либо имеет место быть попытка выполнить транзакцию по карте, отсутствующей в базе данных эмитента.

15 — Invalid Issuer (Неверный эмитент). Такой RC обычно отправляется авторизационной платформой ПС и говорит о том, что маршрут отправки операции эмитенту не найден (в большинстве случаев, по причине неверного БИНа карты).

30 — Format Error (Ошибка формата данных). Возникает в результате тех или иных ошибок при заполнении сообщения в рамках определенного диалекта. Например, какое-либо поле превышает допустимое количество символов, либо вообще отсутствует, либо заполняется в неверном формате и/или кодировке. При этом ряд ПС, в случае отправки данного RC, направляет в ответном сообщении дополнительное поле с конкретным указанием на ошибочный элемент входящего сообщения.

88 и 89 — Cryptographic Failure (Криптографическая ошибка). Транзакция отклонена по причине ошибок криптографии. К примеру, таких как, ошибка шифрования пинблока, ошибка проверки цифровой подписи и других.

96 — System Error (Системная ошибка). В общем случае ошибка свидетельствует о том, что произошел сбой на каком-либо из этапов обмена. Как правило, в рамках ПЦ эквайрера, однако нам известны случаи, когда данный RC передавался и в рамках H2H.

Сервисные RC

К сервисным RC можно отнести коды ответов по операциям в рамках которых отсутствовали технические ошибки, а отказ был получен по причине ограничений доступа к тому или иному сервису со стороны эмитента или ПС, либо других условий, не связанных с техническими проблемами.

00 — Approved (Одобрено). Транзакция завершена успешно.

01 — Refer to Call Issuer (Позвоните эмитенту). Для завершения транзакции необходимо связаться с эмитентом.

04 — Capture Card (Изъять карту). Эмитент или ПС направил команду на изъятие карты.

05 — Do Not Honor (Не оплачивать). Отказ без объяснения причины. В подавляющем большинстве случаев такой RC отправляется эмитентом. Причины также следует уточнять у эмитента.

41 — Lost Card (Карта утеряна). Попытка выполнить операцию по карте, помеченной в БД эмитента или ПС как утерянная.

43 — Stolen Card (Карта украдена). Попытка выполнить операцию по карте, помеченной в БД эмитента или ПС как украденная.

51 — Not Sufficient Funds (Недостаточно средств). Сумма операции превышает сумму доступных средств на карточном счете.

52 и 53 — No Checking/Saving Account. Попытка выполнить операцию с неверным карточным счетом.

54 — Expired Card (Карта просрочена). Попытка выполнить операцию по карте с истекшим сроком действия.

55 — Incorrect PIN (Неверен пин). При выполнении операции с онлайн-пинкодом он был введен некорректно.

57 — Transaction Not Permitted to Issuer/Cardholder (Транзакция не разрешена для Эмитента/Держателя карты). Попытка выполнить операцию, не разрешенную для конкретного эмитента или держателя карты.

58 — Transaction Not Permitted to Acquier/Terminal (Транзакция не разрешена для Эквайрера/Терминала). Попытка выполнить операцию, не разрешенную для конкретного эквайрера или терминала.

Таков список наиболее часто встречающихся кодов ответа, имеющих одинаковые значения для всех ведущих ПС. Заметим, что их число несколько шире и варьируется в зависимости от конкретного диалекта ПС. Например в рамках спецификации Visa могут присутствовать RC, отсутствующие у Mastercard, и наоборот.

Эквайринг для торговой точки

Оффлайновые коды ответов

В общих чертах следует коснутся и оффлайновых RC. К ним относятся коды, сгенерированные программным обеспечением POS-терминала. Поскольку в данном случае обмен выполняется не в рамках ISO 8583, а условия возникновения таких RC наступают в процессе т.н. EMV Transaction Flow, ограничимся общим описанием (Вопросы APDU/EMV-обмена будут подробно освещены в будущих материалах).

Z1 — OFFLINE DECLINED (Отклонено оффлайн). Было принято решение отклонить транзакцию, не отправляя онлайн-сообщение.

Z3 — NO ONLINE, DECLINED (Нет связи, отклонено оффлайн). POS-терминал предпринял попытку отправить онлайн-запрос, которая закончилась неудачно по причине отсутствия связи. В оффлайне транзакция отклонена.

Y1 — OFFLINE APPROVED (Одобрено оффлайн). Транзакция одобрена без онлайн-обращения к эмитенту. Справедливо для терминалов, поддерживающих оффлайн-транзакции.

Y3 — NO ONLINE, APPROVED (Нет связи, одобрено оффлайн). POS-терминал предпринял попытку отправить онлайн-запрос, которая закончилась неудачно по причине отсутствия связи. В оффлайне транзакция была одобрена. Справедливо для терминалов, поддерживающих оффлайн-транзакции.

SMS-информирование

Достаточно популярная ныне услуга SMS-информирования используется многими держателями карт. Помимо очевидного удобства, являясь в ряде случаев причиной споров, а иногда и скандалов между мерчантом и кардхолдером. Рассмотрим наиболее типичный случай:

  • Клиент расплачивается картой.
  • Получает SMS о списании суммы услуги/покупки.
  • Терминал не печатает чек/зависает/перезагружается.
  • Мерчант не имеет на руках успешного чека по операции.
  • Клиент утверждает, что операция успешна, при этом ссылается на SMS.

Дальнейший сценарий развития событий зависит от опытности персонала ТСП и многих других факторов.

Первое и самое важное, что следует принимать во внимание в такой ситуации: критерием успешности операции по карте является чек (либо, если речь идет об одобренных ПС терминалах, не оснащенных чековым принтером — его электронный эквивалент), содержащий успешный код ответа и/или его расшифровку. Никакие SMS, полученные клиентом, критерием успешности операции не являются. Ни один диспутный цикл ни по одной претензии не будет рассматривать полученное кардхолдером SMS в качестве аргумента. Основная причина состоит в том, что такая услуга как SMS-информирование никак не специфицирована со стороны ПС. То есть, технические инструменты, в том числе и протоколы/формат обмена, которыми она достигается, зависят от каждого конкретного эмитента. В том числе, может быть реализована и с помощью различных самописных решений. В общем случае, некий условный «SMS-сервер» анализирует запросы к карточному контракту и фиксирует изменения его доступного остатка. Помимо этого, в большинстве случаев могут анализироваться поля 41 (Идентификатор Терминала (Terminal ID)), 42 (Идентификатор Мерчанта (Merchant ID)) и 43 (Имя и местонахождение мерчанта (Card Acceptor Name/Location)) из входящего запроса от эквайрера. Затем эти данные вносятся в «тело» SMS-сообщения и отправляются на номер телефона, который кардхолдер указал при выпуске карты. На выходе получается SMS-сообщение примерно такого формата: «КАРТА, ДАТА/ВРЕМЯ, Тип операции, Сумма, НАИМЕНОВАНИЕ ТСП, ДОСТУПНЫЙ ОСТАТОК».

Подчеркнем ряд важных моментов: фактически, принцип функционирования SMS-сервера базируется на срабатывании триггеров. При этом он может быть настроен на срабатывание при выполнении операции Оплата, но не срабатывать на операцию Отмена оплаты; далее, SMS-сервер ничего «не знает» про состояние каналов связи в момент выполнения операции. Соответственно, не способен «понять», был ли ответ на авторизацию успешно доставлен на POS-терминал. Сумма и комбинации всех этих факторов, а также отсутствие регламентов со стороны ПС, делают SMS-инфо крайне ненадежным источником. Этот факт необходимо учитывать как мерчантам, так и кардхолдерам. Безусловно, качество предоставления такой услуги, как SMS-информирование в последние годы существенно возросло. Однако это не отменяет сказанного выше.

Источник
+  Форум АО «ВЗЛЕТ»
|-+  Автоматизация и диспетчеризация
| |-+  Взлет СП3
| | |-+  Ошибка формата ответного сообщения при снятие показаний Км-5		 0 Пользователей и 1 Гость смотрят эту тему. « предыдущая тема следующая тема »
Страниц: [1] Печать

Автор 		Тема: Ошибка формата ответного сообщения при снятие показаний Км-5  (Прочитано 5311 раз)
Энерго_алексей

Наш человек
***

Харизма: 9
Офлайн Офлайн

Сообщений: 859

Ошибка формата ответного сообщения при снятие показаний Км-5

« : 18.05.2016, 16:50:29 »

Здравствуйте, суть проблемы такой, звоню через Взлет СП3 на модем настроен он по CSD и постоянно пишет Ошибка форма ответного сообщения. Что может быть и как быть? П.С модемы соединяются


Записан
dimoniche

Global Moderator
*****

Харизма: 21
Офлайн Офлайн

Сообщений: 564

Re:Ошибка формата ответного сообщения при снятие показаний Км-5

« Ответ #1 : 20.05.2016, 15:06:36 »

Здравствуйте.
У КМ-5 вышли новые версии прошивок, видимо что-то поменялось в протоколе.
Пришлите контакты модема для подключения, мы попробуем разобраться.

Записан
Энерго_алексей

Наш человек
***

Харизма: 9
Офлайн Офлайн

Сообщений: 859

Re:Ошибка формата ответного сообщения при снятие показаний Км-5

« Ответ #2 : 23.05.2016, 16:07:52 »

Хорошо, а кому отправить в личку номер модема?

Записан
Страниц: [1] Печать 
« предыдущая тема следующая тема »

Перейти в:
 

Источник
   zasyadko

08.06.15 — 23:09

Добрый вечер всем! Столкнулся с небольшой проблемой при решении задачи о построении обмена данными между нетиповой КА и типовой бухой. Правила конвертации написал и туда и обратно, использовал КД 2.0. В КА не возникло проблем в план обмена загрузить новые правила. Инфу выгружает. А вот как вторые правила подружить с бухгалтерией не пойму совсем. Конвертацию пишу не в первый раз, но до этого лишь выгружал и загружал через обработку. Наставьте на путь истинный, пожалуйста))

   zasyadko

1 — 09.06.15 — 17:28

АП! Неужели никто не знает? Я вижу проблему в том что вроде бы в БУХ 3.0 (8.3) обмены идут через EnterpriseData новый, а в КА 1.1 (8.2) через простой XML. Как быть то?

   Wern

2 — 09.06.15 — 18:01

КД 3.0 штука необязательная. Выгружай в формате 2.0

   zasyadko

3 — 09.06.15 — 18:24

(2) Хорошо. Допустим. Есть у меня уже написанные правила конвертации, в КА я их уже поместил в план обмена. Как тоже самое сделать в БУХ 3.0? Ну в упор я не вижу где это там прячется.

   zasyadko

4 — 10.06.15 — 11:23

ап

   zasyadko

5 — 11.06.15 — 10:53

Совсем никто ничего подобного не делал что ли? Не верится даже…((

   Naumov

6 — 11.06.15 — 10:56

(3) Вообще это все кладется/прячется в соответствующий РС. А загрузка/выгрузка доступна в списке узлов ПланаОбмена, в форме элемента Плана обмена.

   zasyadko

7 — 11.06.15 — 11:20

(6) так вот в БУХ 3.0 ни в один из существующих планов обмена невозможно загрузить правила конвертации из КД2.0, это не говоря уже о том что состав существующих планов обмена не устраивает

   Naumov

8 — 11.06.15 — 11:56

(7) ДА ты что? У меня вот загружает прекрасно.

Не устраивает состав планов обмена? Добавь свой. Какие помехи? БСП позволяет это несложными доработками осуществить.

   Azverin

9 — 11.06.15 — 12:06

(7) План обмена в БП 3.0 (УФ) мягко говоря совсем не такой, как в КА.

(8) возможно связать планом обмена БП 3.0 и КА 1.1 без снятия с поддержки БП 3.0?

   zasyadko

10 — 11.06.15 — 13:18

(8) То есть выход один — создать полностью свой план обмена?

   Naumov

11 — 11.06.15 — 13:41

(9,10)  Зависит от того какой перечень документов для обмена вам нужен. Если Перечень документов, которыми идет обмен с УТ10.3, например, вам годится, то можно подменить Правила обмена и использовать этот ПланОбмена для обмена с КА.

Да, Планы обмена (не РИБ) в БП 3.0 не поддерживают обмен проводками.

   Azverin

12 — 11.06.15 — 14:11

(0) у тебя на 8.3 всё крутится?

   zasyadko

13 — 11.06.15 — 14:22

(12) у меня КА 1.1 на 8.2, а Буха на 8.3

   Azverin

14 — 11.06.15 — 14:56

(13) и у меня такое же. правда КА очень древняя, поэтому обмен там старый и не идёт(

   Naumov

15 — 11.06.15 — 15:07

(14) Что значит не идет?

   Azverin

16 — 11.06.15 — 16:04

(15) надо вспомнить. после праздников отпишусь

   zasyadko

17 — 11.06.15 — 17:12

(11) Если взять план обмена с УТ 10.3, то он хочет в качестве правил конвертации архив, в отличии от КА, тот принимает единственный XML

   Naumov

18 — 11.06.15 — 17:19

(17) в БП 3.0 обмен на базе БСП. ТАм комплект правил подразумевает архив с двумя файлами: правила источника и правила для корреспондента. КД 2.0 прекрасно такой архив делает, если при выгрузке указать, что выгружать правила корреспондента и указать соответствующую конвертацию.

  

zasyadko

19 — 30.06.15 — 18:40

Нашел способ решения проблем, но возникли новые))) Создал новый план обмена в БУХ 3.0 при помощи БСП, прописал в модули, в команды, указал состав, загрузил свои пакет своих правил. Все закрутилось, заработало, НО….

Делаю обмен, получаю:

«{Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(13603)}: Ошибка формата сообщения обмена.

            ВызватьИсключение НСтр(«ru = ‘Ошибка формата сообщения обмена.'»);»

И вот почему — КА 1.1 мне выгружает файл обмена со следующей записью: <ФайлОбмена ВерсияФормата=»2.0″ и т.д, а вот БУХ 3.0 дает: <ФайлОбмена ВерсияФормата=»3.1″.

Как мне заставить их общаться на одном формате? может параметры какие для правил? или что-то в модулях планов обмена надо подправить?

Источник

Содержание

  1. Сведения о застрахованном лице. Отправка в ФСС. Ошибка логического контроля.
  2. Ошибка при взаимодействии УПП с ФСС — 2
  3. Ошибка отправки ответа на запрос
  4. Обсуждение (5)
  5. При ответе на запрос ФСС — Ошибка формата сообщения. Unknown format message
  6. Обсуждение (6)
  7. Добавить комментарий Отменить ответ
  8. СЭДО Ответ на запрос
  9. Обсуждение (7)

Сведения о застрахованном лице. Отправка в ФСС. Ошибка логического контроля.

Ошибка выявлена. Зарегистрировано несоответствие 6476.
Ожидайте исправительный патч.

«Опубликован патч EF_50_00006476»

— уже включен в обновление 5.0.81.3 ?

-а то ошибка осталась.

— может добавите проверку этих сведений на стороне 1С камин зарплата 5.0 до отправки сведений в фсс!?

«Опубликован патч EF_50_00006476»

— уже включен в обновление 5.0.81.3 ?

-а то ошибка осталась.

да, такая «Ошибка формата сообщения. Unknown format message»

— у одного казахстанский паспорт, хотя гражданство россии, возможно из-за этого

— а пока у 3-х не понятно почему.. все заполнено

да, такая «Ошибка формата сообщения. Unknown format message»

— у одного казахстанский паспорт, хотя гражданство россии, возможно из-за этого

— а пока у 3-х не понятно почему.. все заполнено

ну вот еще проблема. не могу сохранить, при нажатии Сформировать файл пишет «Не выбран каталог выгрузки.». тут же нет настроек выбора каталога.

подскажите еще как его выбрать?

ну вот еще проблема. не могу сохранить, при нажатии Сформировать файл пишет «Не выбран каталог выгрузки.». тут же нет настроек выбора каталога.

Источник

Ошибка при взаимодействии УПП с ФСС — 2

Итак, звонит пользователь и описывает ошибку, приведенную выше. Стандартная отмазка «Ждем новый релиз УПП» не прошла — есть сроки ответа, если не ответим вовремя, будет штраф. Пришлось включать мозг.

Смотрим исходный документ. Все поля на месте: расчетный счет, адрес, данные ребенка и т.д. Чешем репу. Благо, в документе, отправленном в ФСС виден текст XML-сообщения и это уже кое-что. Если есть XML и ошибка формата сообщения, значит где-то должна быть схема XSD для его проверки. Полдня поиска в гугле и яндексе мало что дали. Оказалось, что всё лежит под самым носом:

Теперь нужен какой-то инструмент, позволяющий проверить файл XML по схеме XSD. Я для себя выбрал простой скрипт на питоне:

Здесь c:/tmp/xsd/v01/proactive/Confirmation.xsd — путь к корневому файлу схемы XSD,

c:/tmp/ans.xml — сохраненный в файл текст XML из документа.

Запускаем скрипт и получаем вот такую ошибку:

Опаньки! Оказывается для элемента benefit4Approve необходимо использовать версию спецификации пространства имен v02. Но это еще не всё. Понятно, что версия спецификации просто так не меняется, скорее всего изменилось и что-то внутри.

Редактируем в xml-файле имя пространства имен на xmlns:benefit=»urn:ru:fss:integration:types:proactive:benefit4:v02″

запускаем скрипт и видим следующие ошибки:

Лезем в спецификацию по поводу тегов workContract, childRelType, cert, birthDate.

Выясняем, что workContract — срочный трудовой контракт — не наш случай. childRelType — отношение к ребенку (перечисление 38 — мать, 39 — отец, 40 — попечитель, 41 — опекун, 42 — иной родственник, фактически осуществляющий уход за ребенком). Этого тэга раньше не было.

cert — свидетельство о рождении. Раньше было, но теперь из тэга zagsAct передвинули выше, в birthInfo.

Добавляем в XML-файл тэг 38 внутрь benefit:insuredInfo, перемещаем cert.

Запускаем скрипт — проходит без ошибок. Ошибка по birthDate оказалась наведенной. Теперь становится понятно, что нужно исправить в УПП, чтобы документ отправился в ФСС.

1. Документ ОтветНаЗапросФССДляРасчетаПособия. Модуль формы документа.

Источник

Ошибка отправки ответа на запрос

Вопрос задал Елена С. (Нягань, Ханты-Мансийский авт. окр.)

Ответственный за ответ: Юлия Щелкунова (★9.83/10)

Здравствуйте! При отправке ответа на запрос по больничному листу приходит ошибка «Ошибка формата сообщения. Unknown format message». Может быть знаете что это за ошибка, может сталкивались ? Отправляла уже не мало ответов, все приняты ФСС, проблем не было, а сегодня вот такую ошибку выдает (( Спасибо!

Обсуждение (5)

Мы получили ваш вопрос, наш консультант займется подготовкой ответа для вас.

Здравствуйте!
Вот ту разбирается похожий вопрос: https://buhexpert8.ru/voprosy/voprosy-1s-zup/otvet-na-zapros-v-fss-po-posobiyu-po-uhodu-za-bolnym-rebenkom.html.
Скажите. пожалуйста, у Вас исправление ответа на запрос или первичный ответ?

Здравствуйте! Первичный ответ

Здравствуйте!
Массово такая ошибка вылетает сейчас только у тех, кто отправляет исправленный ответ на запрос. Но теперь, поскольку у Вас исходный запрос не отправился, то сейчас придется создавать исправленный по кнопке «Исправить (подготовить новые сведения), а там это уже известная массовая проблема.
Поэтому сейчас Вам остается отправить реестр по старому. Будем ждать информации от разработчиков.
Если проблема повторится по другим ответам, то напишите, пожалуйста. Когда будет информация по ошибке исправленного ответа, я Вам напишу.

Здравствуйте! Я поняла, спасибо большое!

Вы можете задать еще вопросов

Доступ к форме «Задать вопрос» возможен только при оформлении полной подписки на БухЭксперт8

Нажимая кнопку «Задать вопрос», я соглашаюсь с
регламентом БухЭксперт8.ру >>

Источник

При ответе на запрос ФСС — Ошибка формата сообщения. Unknown format message

Вопрос задал Наталья Л.

Ответственный за ответ: Юлия Щелкунова (★9.83/10)

Платформа: 1С:Предприятие 8.3 (8.3.20.1613)
Конфигурация: Зарплата и управление персоналом, редакция 3.1 (3.1.18.484)
Добрый день!
При отправке ответа ФСС — Единовременное пособие при рождении ребенка , выдает ошибку
«Ошибка формата сообщения. Unknown format message»
В чем может быть проблема ? До этого Единовременное пособие при рождении ребенка отправляли реестром. Но сегодня последний день , когда так можно делать ((

Обсуждение (6)

Выяснила подробности у бухгалтера. При создании ответа она заполнила поля Дата актовой записи ЗАГС и номер. В документе эти поля отобразились «жирным» шрифтом. Но ответ оказался не принят с ошибкой Ошибка формата сообщения. Unknown format message. ФСС ей сказали очистить эти поля.
Далее через кнопку «Исправить(подготовить новые сведения)» создала новый ответ , очистив эти поля. Но результат тот же самый — Ошибка формата сообщения. Unknown format message.
Но в документе исправлении не поставлена «галка» «Исправление по причине» , то есть нет кода исправления .
Возможно причина в этом?

Здравствуйте!
Приложите, пожалуйста, скриншоты из обоих ответов в ФСС. И скриншот из самого запроса.

Добрый день. позвоните ФСС, наши сказали- до конца года это пособие будут принимать по-старому, не готовы еще у них программы

Добрый день!
Файлы приложила — запрос ФСС, ответ 1 и ответ2 (исправленный).
А возможности проверок этих файлов какой то программой нет, аналогично отчетности?

Здравствуйте! Похоже это все-таки ошибка на стороне 1С. На партнерском форуме есть обсуждение по теме: https://partners.v8.1c.ru/forum/topic/2068577 Если есть доступ, можете посмотреть. Правда разработчики там так и не ответили ничего.
По идее поля «Дата актовой записи ЗАГС» и «Номер актовой записи ЗАГС» заполнять в ответе нужно. Но они должны быть по идее заполниться автоматически из входящего запрос. Но программа не совсем правильно воспринимает вид пособия, и формирует документ по принципу для «Ежемесячного пособия по уходу за ребенком».
У меня к сожалению, нет возможности проверить работу с ответом, потому что для него нужен запрос.

Получается пока можно только по строму отправить. :((

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Вы можете задать еще вопросов

Доступ к форме «Задать вопрос» возможен только при оформлении полной подписки на БухЭксперт8

Нажимая кнопку «Задать вопрос», я соглашаюсь с
регламентом БухЭксперт8.ру >>

Источник

СЭДО Ответ на запрос

Вопрос задал Олеся Р.

Ответственный за ответ: Елена Пьянкова (★9.85/10)

Здравствуйте. ЗУП 3.1.23.63. При отправке ответа на запрос приходит отрицательный протокол. Ошибка логического контроля (Ошибка формата сообщения. Unknown format message). У нас осужденный сотрудник. В категории выбрали — Oсужденное к лишению свободы лицо, привлекаемое к оплачиваемому труду.
В поле способ выплаты пособия указали Через иную организацию. Ввели реквизиты.
В чем может быть ошибка?

Обсуждение (7)

Добрый день! Такая ошибка часто появляется, если в документе «Ответ на запрос ФСС для расчета пособия» не указан входящий запрос:

Входящий запрос выбран

Можно попробовать установить релиз ЗУП 3.1.23.68. В нём разработчики исправили похожую ошибку, но по другому виду пособия:

Ошибка 20173478
Код ошибки: 20173478
Код(ы) обращения: HL-540768 HL-541819
Статус: Исправлена в выпущенной версии Зарегистрирована: 26.08.2022
Исправлена: «1С:ЗУП 3, 1С:ЗГУ 3», версия 3.1.18.616
Исправлена: «1С:ЗУП 3, 1С:ЗГУ 3», версия 3.1.23.68

Описание:
При отправке ответа на запрос ФСС для расчета ежемесячного пособия по уходу за одним ребенком до 1,5 лет возникает ошибка логического контроля:

Или пока отправить «Реестр прямых выплат».

Добрый день! По данной ошибке разработчики рекомендуют предварительно отправить в ФСС новые «Сведения о застрахованном лице (ФСС)» с правильным указанием способа выплаты.

Источник

Источник

BachaGOH

0 / 0 / 0

Регистрация: 27.03.2017

Сообщений: 4

1

.NET 4.x

Возврат сообщения с несоответствующий кодировкой

29.11.2017, 08:37. Показов 3094. Ответов 6

Метки нет (Все метки)

Здравствуйте. Столкнулся со следующей проблемой:
Во время отправки запроса удалённому сервису возникает ошибка при получении ответа.

Текст ошибки:
«Тип содержимого text/html;charset=ISO-8859-1 ответного сообщения
не соответствует типу содержимого привязки (text/xml; charset=utf-8).
При использовании особого кодировщика необходимо правильно реализовать метод IsContentTypeSupported.
Первые 1024 байтов ответного сообщения: «<!DOCTYPE HTML PUBLIC «-//W3C//DTD HTML 4.01 Transitional//EN» «http://www.w3.org/TR/html4/loose.dtd»><HTML><HEAD>
<LINK type=»text/css» rel=»stylesheet» href=»/cases-ws/?stylesheet=1″>
<meta http-equiv=content-type content=»text/html; charset=UTF-8″>
<title>CXF — Service list</title></head><body><span class=»heading»>Available SOAP services:</span>
<br/><table cellpadding=»1″ cellspacing=»1″ border=»1″ width=»100%»><tr><td>
<span class=»porttypename»>MedicalCasesPortType</span><ul><li>getVersion</li>
<li>sendCase</li><li>getCaseById</li><li>searchCase</li><li>deleteCase</li></ul>
</td><td><span class=»field»>Endpoint address:</span>
<span class=»value»>https://rmis56.orb.ru/cases-ws/cases</span><br/><span class=»field»>WSDL :</span>
<a href=»https://rmis56.orb.ru/cases-ws/cases?wsdl»>{http://atria.cz/medical-cases/interchange}MedicalCasesService</a>
<br/><span class=»field»>Target namespace:</span> <span class=»value»>http://atria.cz/medical-cases/interchange</span>
</td></tr><tr><td><span class=»porttypename»>Medica».»

Текст методов:

C# 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

 private getCaseByIdRequest Get_Case_ID(string ID)
        {
            return new getCaseByIdRequest(new medicalCaseId() { id = ID });
        }
 
        public string GetCaseById(string ID) 
        {
        
           var Get_Case_By_Id = ServiceClient.getCaseById(Get_Case_ID(ID));// <--- ошибка
 
            if (Get_Case_By_Id == null)
            {
                //logo об ошибки и Error
                return "error";
            }
            else
            {
                //успешный logo
                return "список уникальных ID";
            }
        }

Ошибку гуглил несколько часов, в основном предлагаются правки сервиса. Данное решение не подходит.
Рекомендации по переподключению сервиса не помогли.

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь



0

Эксперт .NET

5462 / 4233 / 1210

Регистрация: 12.10.2013

Сообщений: 12,225

Записей в блоге: 2

29.11.2017, 10:40

2

BachaGOH, адрес сервиса дайте, иначе разговор беспредметен.



0

0 / 0 / 0

Регистрация: 27.03.2017

Сообщений: 4

29.11.2017, 12:00

 [ТС]

3

Для входа в сервис требуется логин и пароль.
Не думаю что что адреса сервиса будет достаточно…



0

Эксперт .NET

5462 / 4233 / 1210

Регистрация: 12.10.2013

Сообщений: 12,225

Записей в блоге: 2

29.11.2017, 14:10

4

Цитата
Сообщение от BachaGOH
Посмотреть сообщение

Не думаю что что адреса сервиса будет достаточно..

А мне и не нужен вход. Я хочу посмотреть что отдает запрос метаданных сервиса.
Но раз не хотите-можете обратиться на ТНТ, может там помогут



0

Эксперт .NET

5462 / 4233 / 1210

Регистрация: 12.10.2013

Сообщений: 12,225

Записей в блоге: 2

30.11.2017, 18:21

6

Цитата
Сообщение от BachaGOH
Посмотреть сообщение

Сервис:

BachaGOH, что-то он вообще никак не доступен.



0

0 / 0 / 0

Регистрация: 27.03.2017

Сообщений: 4

01.12.2017, 08:25

 [ТС]

7



0
Источник

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Ошибка формата мобильного телефона 50201
  • Ошибка формата для выпуска квалифицированного сертификата необходимо указать огрн
  • Ошибка формата выполняемого файла linux
  • Ошибка формата lid атол активация
  • Ошибка форд фьюжн p0301

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии