Сведения приведены в документе Перечень типовых ошибок, возвращаемых участнику при работе в СМЭВ 3.0.
SMEV-100
1. Текст ошибки: Отсутствует ЭП-ОВ.
Возникает на этапе проверки ЭЦП в рамках синхронной обработки xml-сообщения, принятого методом GetRequest, GetResponse, Ack.
| Причина | Пример |
| Запрос не подписан электронной подписью органа власти (ЭП-ОВ) (отсутствует или некорректно заполнен блок SenderInformationSystemSignature) |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>Отсутствует ЭП-ОВ</faultstring> <detail> <ns3:SignatureVerificationFault xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"> <Code>fed0:PRODUCTION_AREA:FED0_CORE2 : TR:SYNC:SPS:1</Code> <Description>SMEV-100:Отсутствует ЭП-ОВ</Description> <ns3:SignatureVerificationFault>NoSignatureFound</ns3:SignatureVerificationFault> </ns3:SignatureVerificationFault> </detail> </soap:Fault> </soap:Body> </soap:Envelope> |
Рекомендуется подписать сообщение ЭП-ОВ и повторить отправку.
2. Текст ошибки: @signatureTypeAsString не соответствует подписанным данным.
Возникает на этапе проверки ЭЦП в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.
| Причина | Пример |
| ЭП-СП не соответствует подписанным данным: данные изменены после подписания или допущены ошибки при формировании подписи |
<ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>0f952bd0-3868-11ea-b0b7-0050569445fb</ns2:OriginalMessageId>
<ns2:StatusCategory>requestIsRejectedBySmev</ns2:StatusCategory>
<ns2:StatusDetails>ЭП-СП не соответствует подписанным данным: ru.voskhod.crypto.exceptions.SignatureValidationException:
Ошибка проверки ЭП: Нарушена целостность ЭП.</ns2:StatusDetails>
<ns2:SmevFault xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns3:SignatureVerificationFault">
<Code>fed0:P:FED0_ASYNC_CORE1:TR:ASYNC:SPS:2</Code>
<Description>SMEV-100:ЭП-СП не соответствует подписанным данным:
ru.voskhod.crypto.exceptions.SignatureValidationException: Ошибка проверки ЭП: Нарушена целостность ЭП.</Description>
<ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault></ns2:SmevFault>
</ns2:AsyncProcessingStatus>
|
| ЭП-ОВ не соответствует подписанным данным: данные изменены после подписания или допущены ошибки при формировании подписи |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется проверить алгоритм подписи. Общая последовательность должна быть такой (на примере SendRequest):
- каноникализация содержимого узла SenderProvidedRequestData;
- нормализация;
- расчет хэша;
- формирование ЭП-ОВ:
- запись cодержимого хэша в CallerInformationSystemSignatureSignatureSignedInfoDigestValue
- каноникализация, нормализация элемента CallerInformationSystemSignatureSignatureSignedInfo
- расчёт хэша элемента CallerInformationSystemSignatureSignatureSignedInfo
- подпись хэша CallerInformationSystemSignatureSignatureSignedInfo
- запись значения подписи в CallerInformationSystemSignatureSignatureSignatureValue
- запись данных сертификата в CallerInformationSystemSignatureSignatureKeyInfoX509DataX509Certificate
3. Текст ошибки: Проверка подписи на вложении @id_вложения: @error.
Возникает на этапе проверки ЭЦП в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Неправильно подписано вложение или ошибка в структуре конверта СМЭВ |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
<ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>35861260-1599-11ea-b248-000c2904fa57</ns2:OriginalMessageId>
<ns2:StatusCategory>requestIsRejectedBySmev</ns2:StatusCategory>
<ns2:StatusDetails>Проверка подписи на вложении 35880e30-1599-11ea-b248-000c2904fa57:
Дайджест не прошел проверку!</ns2:StatusDetails>
<ns2:SmevFault xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns3:SignatureVerificationFault">
<Code>tsmev3:P:TSMEV3_ASYNC_CORE2:TR:ASYNC:PP:SPS:7</Code>
<Description>SMEV-100:Проверка подписи на вложении 35880e30-1599-11ea-b248-000c2904fa57:
Дайджест не прошел проверку!</Description>
<ns3:SignatureVerificationFault>SignatureIsInvalid</ns3:SignatureVerificationFault>
</ns2:SmevFault></ns2:AsyncProcessingStatus>
|
Рекомендуется проверить в каком формате электронная подпись добавлена в сообщение, а так же проверить структуру XML-сообщения на соответствие общим схемам СМЭВ с помощью инструмента «Проверки корректности xml-сообщения», размещенном на главной странице неавторизованной зоны ЛК УВ.
4. Текст ошибки: Проверка подписи на вложении @id_вложения: Ошибка получения дайджеста (OID) из подписи.
Возникает на этапе проверки подписи вложения на соответствие формату PKCS#7 в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Подпись вложенных файлов не удовлетворяет Профилю формата PKCS#7 |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется проверить что подпись вложения удовлетворяет профилю формата PKCS#7 согласно п.6.3.1. Подписи в формате PKCS#7 и
Приложение В. Профиль формата PKCS#7, которому должны удовлетворять подписи вложенных файлов» Методических рекомендаций по работе с Единой системой межведомственного электронного взаимодействия версии 3.5.0.7.
5. Текст ошибки: Срок действия сертификата ЭП-* истёк. Сертификат действителен до @validUntil.
Возникает на этапе проверки ЭЦП в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.
| Причина | Пример |
| Срок действия ЭП-ОВ истёк. | <soap:Envelope xmlns:soap=»http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body> |
| Срок действия ЭП-СП истёк. |
<AsyncProcessingStatus><OriginalMessageId>4fd0f689-1d79-11e9-831b-00155d1c2b05</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Срок действия сертификата ЭП-СП истёк. Сертификат действителен до 2018-10-12 10:16</StatusDetails>
<SmevFault xsi:type="ns3:SignatureVerificationFault"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:SPS:4</ns2:Code>
<ns2:Description>SMEV-100:Срок действия сертификата ЭП-СП истёк.
Сертификат действителен до 2018-10-12 10:16</ns2:Description>
<ns3:SignatureVerificationFault>CertificateIsExpired</ns3:SignatureVerificationFault>
</SmevFault></AsyncProcessingStatus>
|
Рекомендуется проверить сроки действия сертификата в блоке PersonalSignature.Заменить ЭП на действительную электронную подпись и повторить отправку сообщения.
6. Текст ошибки: Срок действия сертификата ЭП-* не начался. Сертификат действителен с @validSince
Возникает на этапе проверки ЭЦП в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.
| Причина | Пример |
| Срок действия ЭП-ОВ не начался. | <soap:Envelope xmlns:soap=»http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body> xmlns:ns2=»urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.3″ |
| Срок действия ЭП-СП не начался. |
|
Рекомендуется обратиться в Удостоверяющий центр, выдавший сертификат.
7. Текст ошибки: Cертификат отозван. Код ответа в ГУЦ: @code
Возникает на этапе проверки сертификата ЭП-ОВ в ГУЦ в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse.
| Причина | Пример |
| Возникла ошибка при проверке сертификата в ИС ГУЦ |
<AsyncProcessingStatus><OriginalMessageId>03e1b072-1993-11e9-99c3-62fe784ec952</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Cертификат отозван. Код ответа в ГУЦ:14</StatusDetails>
<SmevFault xsi:type="ns3:SignatureVerificationFault"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:GUTC:1</ns2:Code>
<ns2:Description>SMEV-100:Cертификат отозван. Код ответа в ГУЦ:14</ns2:Description>
<ns3:SignatureVerificationFault>CertificateIsExpired</ns3:SignatureVerificationFault>
</SmevFault></AsyncProcessingStatus>
|
Рекомендуется обратиться в Удостоверяющий центр, выдавший сертификат.
8. Текст ошибки: Технологический доступ к СМЭВ временно отозван в связи с нарушением установленного лимита обращений в систему.
Возникает на этапе проверки лимитов обращения к методам Единого сервиса СМЭВ 3 в рамках синхронной обработки.
| Причина | Пример |
| Превышены допустимые лимиты по одному из методов Единого сервиса СМЭВ 3 |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется Уменьшить интенсивность обращения к методам Единого сервиса СМЭВ 3 до рекомендованных. Значения лимитов по умолчанию зафиксированы в п. 5.4 Методических Рекомендаций СМЭВ.
SMEV-200
1. Текст ошибки: Превышен максимально допустимый суммарный размер присоединённых файлов и сообщения.
Возникает на этапе проверки размера сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Размер присоединённых файлов превысил 5 Мб при отправке через MTOM |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется проверить размер прикрепляемых файлов — суммарный размер вложений для передачи с помощью МТОМ с одним сообщением не должен превышать 5 Мб.
2. Текст ошибки: Количество ФТП-вложений превышает допустимое.
Возникает на этапе проверки количества ФТП-вложений в сообщении, принятого методом SendRequest либо SendResponse в рамках синхронной обработки.
| Причина | Пример |
| Количество вложений в сообщении превысило лимит. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется сократить количество вложений, передаваемых в сообщении, до разрешенного. Целевой лимит количества вложений указан в синхронном ответе в блоке PermittedTotalAttachmentSize.
SMEV-201
1. Текст ошибки: Некорректная информация о фтп вложениях; message id = @id_сообщения.
Возникает на этапе проверки файлов вложения в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
|
1.Несоответствие заголовка и вложений 2. Вложение не загружено перед отправкой сообщения |
<AsyncProcessingStatus> |
Рекомендуется:
-
убедиться, что вложение было предварительно загружено на файловое хранилище СМЭВ
-
проверить корректность указания в сообщении содержимого заголовка RefAttachmentHeader
2. Текст ошибки: Ошибка СМЭВ. Обратитесь в службу технической поддержки.
Возникает на этапе проверки заголовков файлов вложения сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
|
Несоответствие заголовка и вложений |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- убедиться, что каждому AttachmentHeader в сообщении соответствует AttachmentContent
- убедиться, что количество заголовков равно количеству вложений.
- убедиться, что содержимое элементов Id в AttachmentContent не дублируется»
SMEV-202
Текст ошибки: Квота на файловое хранилище для получателя превышена!
Возникает на этапе определения файловой квоты в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Закончился выделенный на файловом хранилище СМЭВ объем свободного места для ИС УВ-получателя сообщения с вложением в результате несвоевременного разбора входящей очереди сообщений. | <AsyncProcessingStatus> |
Рекомендуется повторить отправку сообщения с вложением через промежуток времени или обратиться к получателю сообщения через СЦ.
SMEV-206
Текст ошибки: Количество символов в идентификаторе файла вложения превышает допустимое.
Возникает на этапе валидации идентификатора файла вложения МТОМ в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Идентификатор файла МТОМ вложения, передаваемого в сообщении превышает 255 символов | <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется сформировать идентификаторы, передаваемые в тегах //AttachmentHeader/contentId и //AttachmentContent/id, не превышающие размер в 255 символов.
SMEV-300
Текст ошибки: Недопустимый формат идентификатора сообщения. См. RFC-4122.
Возникает на этапе валидация идентификатора сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Формат идентификатора сообщения MessageID не соответствует стандарту RFC-4122. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется проверить корректность содержимого элемента MessageID. UUID необходимо генерировать по версии 1 (см. п. 4.2 «Algorithms for Creating a Time-Based UUID» RFC 4122 http://rfc.askapache.com/rfc4122/rfc4122.html#section-4.2). СМЭВ использует метку времени, содержащуюся в UUID, для проверки срока годности сообщения, к которому относится данный UUID. Для СМЭВ срок годности одного сообщения составляет 24 часа.
SMEV-301
Текст ошибки: Сообщение с идентификатором @messageId было послано ранее.
Возникает на этапе валидации идентификатора сообщения в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Отправляется сообщение с MessageID, который уже отправлялся ранее. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
<AsyncProcessingStatus><OriginalMessageId>a95b71d6-1993-11e9-8758-3bde16b3418d</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Сообщение с идентификатором
a95b71d6-1993-11e9-8758-3bde16b3418d было послано ранее.</StatusDetails>
<SmevFault><ns2:Code>LOCAL:P:localhost:TR:ASYNC:UNQ:3</ns2:Code>
<ns2:Description>SMEV-301:Сообщение с идентификатором
a95b71d6-1993-11e9-8758-3bde16b3418d было послано ранее.</ns2:Description>
</SmevFault></AsyncProcessingStatus>
|
Рекомендуется сгенерировать новое значение для MessageID и повторить отправку.
SMEV-302
Текст ошибки: Timestamp идентификатора сообщения слишком давний.
Возникает на этапе валидации идентификатора сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Метка времени в идентификаторе сообщения MessageID более 24-х часов. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется проверить дату и время генерации метки времени. Сгенерировать MessageID с новой меткой времени.
SMEV-401
1. Текст ошибки: Не найден вид сведений.
Возникает на этапе проверки наличия вида сведений в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| В блоке MessagePrimaryContent указаны корневой элемент или целевое пространство имен незарегистрированного в СМЭВ 3 Вида сведений или текущее время отправления запроса не входит в срок действия ВС (с/по) |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
<st3:AsyncProcessingStatus> |
Рекомендуется:
- определить контур СМЭВ, в который осуществляется обращение (разработческий, тестовый, продуктивный), для этого посмотреть вызываемый адрес сервиса и сопоставить с опубликованными в разделе «»Часто задаваемые вопросы»» Технологического портала СМЭВ адресами Единого сервиса;
- найти на Технологическом портале зарегистрированный в соответствующем контуре(тестовом или продуктивном) Вид сведений. Сверить содержимое блока MessagePrimaryContent c эталонным сообщением, опубликованным в руководстве пользователя Вида сведений — проверить, правильно ли указаны корневой элемент и целевое пространство имен корневого элемента;
- проверить срок действия ВС в карточке.
2. Текст ошибки: Попытка отправить сообщение, не соответствующее типу вида сведений.
Возникает на этапе проверки наличия вида сведений в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| В рамках метода SendRequest отправлено сообщение в блоке MessagePrimaryContent которого указан корневой элемент ответа или для сообщения, отправляемого по методу SendResponse, указан корневой элемент запроса. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- для запроса, отправляемого методом SendRequest проверить, что в блоке MessagePrimaryContent вложенный элемент соответствует корневому элементу запроса в соответствии со схемой Вида сведений, опубликованной в руководстве пользователя;
- для ответа отправляемого методом SendResponse проверить, что в блоке MessagePrimaryContent вложенный элемент соответствует корневому элементу ответа в соответствии со схемой Вида сведений, опубликованной в руководстве пользователя.
SMEV-402
Текст ошибки: Входящая очередь запрошенного типа сообщений, принадлежащая пользователю @CallerCertificate.getSubjectX500Principal().getName(X500Principal.RFC1779) не зарегистрирована в СМЭВ.
Возникает на этапе обработка сообщения в рамках синхронной обработки xml-сообщения, принятого методом GetRequest, GetResponse.
| Причина | Пример |
|
1. Неверно указаны параметры фильтрации в тегах NamespaceURI и RootElementLocalName блока MessageTypeSelector (в том числе, если указанный ВС не зарегистрирован в нужной среде). 2. Информационная система Участника не зарегистрирована в СМЭВ 3, либо ИС отсутствует в необходимой среде. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- проверить содержимое элементов NamespaceURI и RootElementLocalName блока MessageTypeSelector — целевое пространство имен и корневой элемент должны соответствовать зарегистрированному в СМЭВ 3 Виду сведений;
- проверить зарегистрирован ли данный ИС в той среде СМЭВ 3, в которой идет обращение;
- проверить зарегистрирован ли сертификат, которым подписано направленное сообщение, в соответствующей среде СМЭВ 3;
- получить серийный номер сертификата, указанного в блоке CallerInformationSystemSignature в элементе X509Certificate отправляемого сообщения (сохранить содержимое элемента с разрешением cer, открыть вкладку «Состав», получить значение из поля «Серийный номер»);
- убедиться, что ранее был направлен запрос в Ситуационный центр на регистрацию информационной системы с сертификатом из п.1 и получено положительное решение;
- если заявка ранее не направлялась — зарегистрировать запрос через Ситуационный центр и после получения положительного решения по заявке повторить отправку сообщения.
SMEV-403
1. Текст ошибки: Сообщение содержит не все вложенные элементы. Блок @tagname отсутствует либо пуст.
Возникает на этапе синхронной валидации xml-сообщения, принятого методами SendRequest, SendResponse, GetRequest, GetResponse.
| Причина |
Пример |
|
Отправляемое сообщение не соответствует схемам Единого сервиса |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- выполнить проверку сообщения с помощью «Инструментов разработчика», размещенных на главной странице Технологического портала — раздел «Проверка xml-сообщения на соответствие схемам сервиса СМЭВ»;
- привести сообщение в соответствие схемам Единого сервиса — схемы опубликованы в документе «Методические рекомендации по работе с Единой системой межведомственного электронного взаимодействия» на главной странице Технологического портала, а также могут быть получены с помощью ссылок в конструкции import в описании сервиса (wsdl);
- повторить отправку сообщения.
2. Текст ошибки: Сообщение содержит не все вложенные элементы. Один из блоков (MessagePrimaryContent, RequestRejected, RequestStatus) отсутствует либо пуст.
Возникает на этапе синхронной валидации xml-сообщения, принятого методами SendRequest, SendResponse.
| Причина | Пример |
| Отправляемое сообщение не соответствует схемам Единого сервиса |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- выполнить проверку сообщения с помощью «Инструментов разработчика», размещенных на главной странице Технологического портала — раздел «Проверка xml-сообщения на соответствие схемам сервиса СМЭВ»;
- привести сообщение в соответствие схемам Единого сервиса — схемы опубликованы в документе «Методические рекомендации по работе с Единой системой межведомственного электронного взаимодействия» на главной странице Технологического портала, а также могут быть получены с помощью ссылок в конструкции import в описании сервиса (wsdl);
- повторить отправку сообщения.
3. Текст ошибки: Метка времени сообщения @timestamp не действительна.
Возникает на этапе синхронной валидации xml-сообщения, принятого методами GetRequest, GetResponse, GetStatus, GetIncomingQueueStatistics.
| Причина | Пример |
| Значение временной метки в сообщении отличается от текущего | <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется выполнить проверку значения времени в элементе Timestamp по методам Timestamp:
- Метод GetRequestRequest : GetRequestRequest — MessageTypeSelector — Timestamp
- Метод GetResponseRequest : GetResponseRequest – MessageTypeSelector — Timestamp
- Метод GetStatus : GetStatusRequest — Timestamp
- Метод GetIncomingQueueStatisticsRequest : GetIncomingQueueStatisticsRequest — Timestamp
Значение должно совпадать с текущим (допустимая дельта — 30 минут).
4. Текст ошибки: Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ. MessageId = @Message_Id
Возникает на этапе Асинхронная валидация xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Отправляемое сообщение не соответствует схемам Вида сведений |
<ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>704b80da-2268-11e9-afd2-02579a2b356e</ns2:OriginalMessageId>
<ns2:StatusCategory>requestIsRejectedBySmev</ns2:StatusCategory>
<ns2:StatusDetails>Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ.
MessageId = 704b80da-2268-11e9-afd2-02579a2b356e</ns2:StatusDetails>
<ns2:SmevFault xsi:type=""ns3:InvalidContent"" xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"">
<Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:BSV:3</Code>
<Description>SMEV-403:Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ.
MessageId = 704b80da-2268-11e9-afd2-02579a2b356e</Description>
<ns3:ValidationError errorPosition=""-1"">cvc-pattern-valid: Value '' is not facet-valid with respect to pattern
'[A-Za-z0-9]{1,32}' for type 'documentseriesType'.</ns3:ValidationError>
<ns3:ValidationError errorPosition=""-1"">cvc-type.3.1.3: The value '' of element
'tns:passportSeries' is not valid.</ns3:ValidationError>
<ns3:ValidationError errorPosition=""-1"">cvc-pattern-valid: Value '' is not facet-valid with respect to pattern
'[A-Za-z0-9]{1,32}' for type 'documentnumberType'.</ns3:ValidationError>
<ns3:ValidationError errorPosition=""-1"">cvc-type.3.1.3: The value '' of element 'tns:passportNumber'
is not valid.</ns3:ValidationError>
</ns2:SmevFault></ns2:AsyncProcessingStatus>
|
Рекомендуется:
- скачать схемы Вида сведений в карточке на Технологическом портале;
- выполнить валидацию содержимого блока MessagePrimaryContent отправляемого сообщения по схемам Вида сведения с помощью xml-валидаторов или сверить с эталонным сообщением, опубликованным в руководстве пользователя;
- исправить ошибки и повторить отправку сообщения
SMEV-405
Текст ошибки: Входящая очередь «наименование очереди» сообщений, принадлежащая пользователю «мнемоника ИС», не зарегистрирована в СМЭВ.
Возникает на этапе Проверка наличия очереди ИС в СМЭВ в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Очередь ИС не зарегистрирована в СМЭВ |
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- убедиться, что сертификат, которым подписывается сообщение, зарегистрирован в СМЭВ;
- проверить, что указанная в тексте ошибки мнемоника ИС и ее очередь (общая или выделенная — NodeId) была зарегистрирована в СМЭВ;
- если были выявлены ошибки, исправить их (скорректировать мнемонику ИС, зарегистрировать ИС в СМЭВ, зарегистрировать сертификат, добавить выделенный узел ИС) и повторить попытку отправить запрос.
SMEV-406
Текст ошибки: Входящая очередь «мнемоника ИС_мнемоника узла» сообщений, принадлежащая пользователю «мнемоника ИС», деактивирована в СМЭВ.
Возникает на этапе проверки активации выделенного узла ИС в рамках синхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Выделенный узел (NodeId) ИС деактивирован |
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется создать обращение через СЦ с просьбой активировать выделенный узел ИС, приложив логи запроса и ошибки, указав номер обращения в рамках которого производилась регистрация узла ИС.
SMEV-500
Текст ошибки: Превышение пороговой продолжительности обработки вызова.
Возникает на этапе проверки EOL сообщения в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| Истекло установленное отправителем время жизни сообщения |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
<ns2:AsyncProcessingStatus>
<ns2:OriginalMessageId>e35b183b-2093-11e9-a8e6-aaaaaa2cac00</ns2:OriginalMessageId>
<ns2:StatusCategory>cancelled</ns2:StatusCategory>
<ns2:StatusDetails>Превышение пороговой продолжительности обработки вызова</ns2:StatusDetails>
<ns2:SmevFault><Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:PP:3</Code>
<Description>SMEV-500:Превышение пороговой продолжительности обработки вызова</Description>
</ns2:SmevFault></ns2:AsyncProcessingStatus>
|
Рекомендуется установить новое значение для элемента EOL и повторить отправку сообщения.
SMEV-501
Текст ошибки: Сообщение @AckTargetMessage не найдено среди неподтверждённых.
Возникает на этапе обработки сообщения в рамках синхронной обработки xml-сообщения, принятого методом Ack.
| Причина | Пример |
| Подтверждение получения сообщения с указанным MessageId было выполнено ранее или указанное значение MessageID некорректно |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- убедиться что сообщение Ack отправлено в тот же контур СМЭВ 3 (разработческий, тестовый, продуктивный), в котором было получено сообщение GetRequest или GetResponse;
- извлечь значение MessageID из полученного методом GetRequest или GetResponse сообщения;
- в элементе AckTargetMessage сообщения AckRequest указать полученный MessageID и отправить в адрес Единого сервиса.
SMEV-502
Текст ошибки: Не найден получатель по виду сведений.
Возникает на этапе обработки получателя сообщения по виду сведений в рамках синхронной обработки xml-сообщения, принятого методом SendRequest.
| Причина | Пример |
| Неверно указан код маршрутизации либо его формат. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- убедиться, что среди Поставщиков, получивших технологический доступ к Виду сведений, присутствует Поставщик с указанным в сообщении кодом маршрутизации;
- в случае неверного кода маршрутизации исправить и повторить отправку запроса.
SMEV-503
Текст ошибки: Отправитель сообщения не зарегистрирован.
Возникает на этапе проверки регистрации отправителя сообщения в рамках синхронной обработки xml-сообщения, принятого методом SendRequest, SendResponse, GetRequest, GetResponse, Ack.
| Причина | Пример |
| Информационная система Участника не зарегистрирована в СМЭВ 3 |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется:
- получить серийный номер сертификата, указанного в блоке CallerInformationSystemSignature в элементе X509Certificate отправляемого сообщения (сохранить содержимое элемента с разрешением cer, открыть вкладку «Состав», получить значение из поля «Серийный номер»);
- убедиться, что ранее был направлен запрос в Ситуационный центр на регистрацию информационной системы с сертификатом из п.1 и получено положительное решение;
- если заявка ранее не направлялась — зарегистрировать запрос через Ситуационный центр и после получения положительного решения по заявке повторить отправку сообщения.
SMEV-504
Текст ошибки: Доступ запрещён.
Возникает на этапе проверки доступа отправителя к виду сведений в рамках асинхронной обработки xml-сообщения, принятого методом SendRequest либо SendResponse.
| Причина | Пример |
| ИС не добавлена в СМЭВ 3 в качестве потребителя для запрашиваемого ВС |
<AsyncProcessingStatus>
<OriginalMessageId>9f5ac848-1fad-11e9-bd88-7901cd343bf5</OriginalMessageId>
<StatusCategory>requestIsRejectedBySmev</StatusCategory>
<StatusDetails>Доступ запрещён.</StatusDetails>
<SmevFault><ns2:Code>fed0:P:FED0_ASYNC_CORE2:TR:ASYNC:ACSM:1</ns2:Code>
<ns2:Description>SMEV-504:Доступ запрещён.</ns2:Description>
</SmevFault></AsyncProcessingStatus>
|
Рекомендуется:
- получить серийный номер сертификата, указанного в блоке CallerInformationSystemSignature в элементе X509Certificate отправляемого сообщения (сохранить содержимое элемента с разрешением cer, открыть вкладку «Состав», получить значение из поля «Серийный номер»);
- проверить корректность указания целевого пространства имен и корневого элемента Вида сведений (содержимое MessagePrimaryContent);
- убедиться, что ранее был направлен запрос в Ситуационный центр на получение доступа к Виду сведений из п.2 для ИС, зарегистрированной в соответствующем контуре СМЭВ (разработческий, тестовый, продуктивный) из п.1;
- если заявка ранее не направлялась — зарегистрировать запрос через Ситуационный центр и после получения положительного решения по заявке повторить отправку сообщения.
SMEV-505
Текст ошибки: Превышение пороговой продолжительности обработки вызова.
Возникает при получении на коннекторе клиентов сообщения ответа (SendResponseRequest), в рамках синхронной проверки.
| Причина | Пример |
| Норматив продолжительности подготовки сообщения-ответа превышен на n секунд m миллисекунд . Значение норматива продолжительности N секунд. |
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> |
Рекомендуется обратить внимание на следующее: ответ на запрос по версии вида сведений не сможет быть направлен с нарушением норматива продолжительности подготовки сообщения-ответа.
SMEV-600
Текст ошибки: Очередь, в которую должно быть отправлено сообщение, переполнена.
Возникает на этапе проверки квоты на количество сообщений в рамках синхронной/асинхронной обработки xml-сообщения, принятого методом SendRequest.
| Причина | Пример |
| Ошибка связана с ограничением на допустимое количество сообщений в очереди запросов ИС-получателя сообщения и вызвана несвоевременным разбором входящей очереди ИС получателя запроса. |
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
<AsyncProcessingStatus>
<OriginalMessageId>e86b5350-1995-11e9-b078-0050568925e4</OriginalMessageId> <StatusCategory>requestIsRejectedBySmev</StatusCategory> |
Рекомендуется повторить отправку сообщения с вложением через промежуток времени или обратиться к получателю запроса через СЦ
SMEV-60
Текст ошибки: Ошибка СМЭВ. Обратитесь в службу технической поддержки.
Возникает на этапе проверки в рамках синхронной или асинхронной обработки xml-сообщения, принятого методами SendRequest, SendResponse, GetRequest, GetResponse, Ack.
| Причина | Пример |
| 1. Некорректная структура сообщения 2. Отсутствует или некорректно заполнен элемент to сообщения-ответа. 3. Сообщение направлено неверным методом (например, если запрос направлен по методу SendResponse) 4. Технологические работы в СМЭВ |
<soap:Envelope |
Рекомендуется:
- выполнить проверку сообщения с помощью «Инструментов разработчика», размещенных на главной странице Технологического портала — раздел «Проверка xml-сообщения на соответствие схемам сервиса СМЭВ», в случае ошибок — привести сообщение в соответствие схемам Единого сервиса, опубликованным в документе «Методические рекомендации по работе с Единой системой межведомственного электронного взаимодействия» на главной странице Технологического портала (также могут быть получены с помощью ссылок в конструкции import в описании сервиса (wsdl)) и повторить отправку сообщения;
- проверить, что сообщение направляется нужным методом (запрос — при помощи метода SendRequest, ответ — при помощи метода SendResponse);
- для успешного инициирования процесса обмена, необходимо направлять запрос при помощи метода SendRequest, отправив запрос (SendRequestRequest), после чего запрос пройдет проверки и будет поставлен в очередь запросов поставщика ВС. Далее поставщик при помощи метода GetRequest совершает выборку запроса из очереди и формирует конверт SendResponseRequest;
- убедиться, что в соответствующем контуре СМЭВ на момент отправки сообщения не проводились технологические работы (информация о работах публикуется в разделе «Новости».
№
Текст ошибки
Описание возможной причины
Рекомендации и примечания
1
ORA-20103: Не задан мнемокод пользователя ИС Маркировка.
Не заполнен системный параметр №1816.
Файл – Сервис – Параметры
В окне отбора в поле Номер с-по – необходимо указать 1816.
Откроется окно Параметры: Идентификация
В поле Пользователь – ввести логин пользователя, под которым возникает ошибка.
В поле Организация – Министерство здравоохранения КК
Параметр:
Каталог – Документы операций с упаковками
Номер – 1 816
Код – MRKPackageOperationDocuments_MrkApiUser
Наименование – Пользователь ИС Маркировка
ПКМ – Исправить значение
Указывается значение из раздела: Учет – Пользователи ИС Маркировка
Проверяем, чем заполнен параметр и соответствует ли это сведениям из раздела Учет — Пользователи ИС Маркировка.
2
Ошибка сервиса: «Для документа XML должен существовать документ более высокого уровня.
Line: 0
«.
Ошибка свидетельствует о том, что для данного IP-адреса компьютера не настроено подключение к серверу МИАЦ.
В Парусе Консультанте необходимо создать событие.
В заявке предоставляется следующая информация:
- Наименование организации
- Ответственный сотрудник и телефон
- Адреса VIPnet coordinator/Адрес Vipnet Clinet (через что подключен АРМ)
- Адрес АРМ пользователя (IP-адрес компьютера)
Сведения оформляются в заявку и отправляются в Отдел информационной безопасности ГБУЗ «МИАЦ» для дальнейшей настройки.
3
В разделе «Документы операций с упаковками» при попытке Получить/Отправить документы ничего не происходит.
Часто проблема связана с тем, что не предоставлена актуальная ЭЦП.
- Необходимо проверить данные действия через «Журнал взаимодействия с ИС Маркировка». После выполнения операции необходимо обязательно нажимать кнопку ОБНОВИТЬ.
- Для специалистов Отдела технической поддержки: Если после этого ничего не произошло, необходимо в разделе Учет — Пользователи ИС Маркировка на пользователе ПКМ — Исправить в поле Сертификат нажать на 3 точки и провалиться в раздел Электронные сертификаты, в каталоге слева выбрать каталог учреждения и проверить сертификат, который подвязан пользователю: Действителен с — Действителен по. Если сертификат закончился, дать пояснение клиенту. -И сказать, чтобы зарегистрировали событие в Парус Консультанте и добавили новую ЭЦП в присоединенные документы.
- Для клиента: Если после этого ничего не произошло, необходимо в разделе Учет — Пользователи ИС Маркировка на пользователе ПКМ — Исправить в поле Сертификат — сверить отпечаток ЭЦП с тем, что в Личном Кабинете Честного знака.
- Если отпечаток в Личном Кабинете Честного знака не совпадает с тем, что в Парусе в разделе Учет — Пользователи ИС Маркировка, необходимо в Парус Консультанте прислать событие с текстом: Актуальная ЭЦП для маркировки. Актуальную ЭЦП прикрепить к событию.
4
При сканировании возникает ошибка:
ORA-20103: Контрольный (идентификационный) знак «(01)04680013242190(21)axzxywxxfx4w9» в реестре не определен.
Некорректно нанесен Data Matrix (марка) на ЛП.
Нарушен документооборот.
Проблема в сканере штрих-кодов.
1. Раздел Учет — Реестр контрольных идентификационных знаков
Данная ошибка означает, что КИЗ — (01)04680013242190(21)axzxywxxfx4w9 не найден в разделе Учет — Реестр контрольных идентификационных знаков. Если выполнить ПКМ — Отобрать в поле «Контрольный (идентификационный) знак» вставить — (01)04680013242190(21)axzxywxxfx4w9.
Каталог выбран Вашего юр. лица.
Таким образом делаем вывод, что данный ЛП отсутствует в нашей базе КИЗ.
По умолчанию у каждого пользователя ПКМ — Настройки закладка Прочие стоит чекер «Учитывать регистр символов», таким образом мы в отборе искали КИЗ, в котором маленькие буквы — *axzxywxxfx4w9*. Если Вы уберете этот чекер (временно для проверки КИЗ), то увидите, что в Реестре КИЗ есть КИЗ — (01)04680013242190(21)AXZXYWXXFX4W9 (большие буквы).
2. Проверка документооборота.
Необходимо проверить в документах 601(612), 211, 701 какой КИЗ использовался и какой статус у этих документов, правильно ли они приняты по схеме 601(612)-210-211-701-912 у всех ли статус Получен/Принят?
Если КИЗ с большими или с маленькими буквами не находится в документах (Отбор по колонке КИЗ), значит КИЗ не проходил в ИС Маркировка.
3. Проверка сканера.
При считывании сканера символы имеют разную кодировку, это может быть связано со сканером (там есть настройка регистра символов, для каждого сканера она своя, поэтому пользователь читает руководство пользователя своего сканера и настраивает).
Проверку сканера можно осуществить: Открыть текстовый редактор (Блокнот) и попробовать отсканировать упаковку в документ. Сканированный код сравнить со строкой КИЗ, отсканированной в Парусе. Если одинаковые, то обратиться в ЧЗ, либо к поставщику. Если разные, то скопировать из Блокнота и вставить в строку КИЗ в Парусе.
Если есть другой компьютер и сканер можно проверить еще с помощью них считывание марки.
5
Ошибка: Не удалось поставить запрос в очередь (ORA-29273: сбой запроса HTTP
ORA-06512: на «SYS.UTL_HTTP», line 1130
ORA-12541: TNS:нет прослушивателя
).?
Связана с работой сервиса.
Обратиться в отдел технической поддержки или прислать событие в Парус Консультант.
Ошибка технического характера.
6
ПКМ — ИС Маркировка – Отправить
Выходит ошибка:
ORA-20103: Содержимое упаковки «*» не найдено в товарных запасах.
Нарушен документооборот 612-210-211-701-912.
Пример анализа по клиенту:
Документы операций с упаковками
Для документа 912 (хотя может и для другого типа) ПКМ — ИС Маркировка – Отправить
Выходит ошибка:
ORA-20103: Содержимое упаковки «*» не найдено в товарных запасах.
Проверяю:
612 ДОУ 13.04.2021 Получен 12.04.2021 11:56
1) 210 ДОУ 13.04.2021 Получен ответ 13.04.2021 16:35
211 нет
912 ДОУ 16.04.2021 Не определен
2) 210 ДОУ 13.04.2021 Получен ответ 13.04.2021 16:35
211 ДОУ 13.04.2021 Получен 13.04.2021 16:35:46
912 ДОУ 16.04.2021 Не принят 16.04.2021 10:40
701 ДОУ 13.04.2021 Принят 16.04.2021 14:23
Общая проблема: нарушена цепочка документооборота: 612-210-211-701-912.
2 проблемы:
1) 912 ДОУ 16.04.2021 Не определен — при отправке ошибка, так как нет документа 211. Пусть попробуют еще раз отправить 210 документ, если не получится, размножить 210 и отправить еще раз, получить ответ 211 и 912.
2) 912 ДОУ 16.04.2021 Не принят 16.04.2021 10:40 — не принят, так как 701 принят позже ДОУ 13.04.2021 Принят 16.04.2021 14:23. Соответственно нарушили цепочку документооборота.
Должны были сначала 701 отправить и получить статус Принят, затем отправить 912.
7
Документ операций с упаковками
Статус — Принят частично
В Журнале взаимодействия с ИС Маркировка
Статус — Принят частично
Код ошибки — 52
Текст ошибки — Операция не может быть выполнена. Указанный SGTIN/SSCC не найден в системе
Ошибка может возникнуть, если указанный в документе SGTIN/SSCC не зарегистрирован в системе МДЛП или был перемещен в архив.
В Документе в спецификации Упаковки, ошибка возникла по какой-то упаковке «Тип», «КИЗ» в графе «Код ошибки» и «Текст ошибки» мы видим ошибку 52, именно по ней отсутствует информация в ИС Маркировка.
Рекомендуется проверить отправляемый документ на корректность цепочки документооборота и обратиться с техническую поддержку Честного Знака.
8
Документы операций с упаковками
Тип — 531
Статус — Не принят
ПКМ — Связи — Выходные документы — ЖВсИСМ
Код ошибки — 15
Текст ошибки — Попытка изменить состояние вложенного КиЗ
При попытке зарегистрировать операцию движения SGTIN, который вложен в SSCC.
Необходимо проверить цепочку приемки ЛП на баланс 601-210-211-701-912. Так как пытаются выдать вторичную упаковку, которая вложена в транспортную. А транспортную не расформировали.
9
Документы операций с упаковками
Статус – Не принят
В Журнале взаимодействия с ИС Маркировка
Код ошибки — 34
Текст ошибки — Операция не может быть выполнена. Отправитель сведений и владелец SGTIN/SSCC не совпадают.
Ошибка может возникнуть, если операции
агрегации/изъятия/докладки/расформирования должны осуществляться владельцем SGTIN/SSCC.
Рекомендуется проверить владельца КИЗ и убедиться, что текущий владелец совпадает с участником, регистрирующим операцию по КИЗ. Для подтверждения статуса владельца рекомендуется акцептовать полученные документы (при их наличии) или дождаться акцептования от отправителя.
Необходимо проверить цепочку документооборота, например если ошибка возникла по документу 912, необходимо проверить, чтобы 701 документ был отправлен раньше, чем 912 и имел корректный статус Принят. Только после этого необходимо совершать действия с документом 912.
Если 912 документ был отправлен раньше чем 701, и на данный момент находится в статусе Не принят с данным кодом ошибки, то необходимо восстановить корректную цепочку отправки документа: сначала отправить 701 документ, дождаться статуса Принят, и только после этого размножить 912 и отправить заново.
10
601 документ пользователь нажимает ПКМ- Формирование — Документ акцептования нажимает ОК (пытается создать 701 документ)
Выходит ошибка:
В документе «*» не найдены упаковки, для которых возможно формирование документа акцептования.
Возникает не ошибка, а предупреждение, так как в уведомительном окне есть выбор действия (Продолжить, Прервать, Игнорировать все).
Предупреждение свидетельствует о том, что все упаковки в документе 601 уже имеют привязку к созданному документу акцептования 701. Это можно проверить если на 601 документе нажать ПКМ – Связи – Выходные документы – Документы операций с упаковками.
В открывшемся окне Документы операций с упаковками будут отображаться связанные документы.
Если пользователю необходимо переотправить 701 документ, то на нужном 701 документе произвести действие размножить и далее выполнить действие Отправить.
11
Документ 912 статус – Не принят.
На документах ПКМ — Связи — Выходные документы — ЖВсИСМ ошибка:
Код ошибки — 33
Текст ошибки — Операция не может быть выполнена. Указанный SGTIN/SSCC находится в промежуточном состоянии.
Ошибка возникает, по причине нарушения цепочки документооборота, неверный порядок отправки документов выглядит чаще всего так: 601-210-211-912-701(702).
Когда пользователь отправляет документ 912 «Расформирование транспортной упаковки» раньше, чем принимает себе на баланс с помощью отправки документа 701 «Приемка с прямым порядком акцептования» (702 «Оприходование лекарственных препаратов»), ЧЗ такие 912 не принимает.
Пользователю необходимо восстановить правильную цепочку документооборота и выполнить корректно отправку документов по цепочке:
601-210-211-701 (702) -912.
Таким образом необходимо произвести отправку 701 (702) документа, дождаться пока статус будет Получен и дальше уже произвести отправку 912 документов.
Документы необходимо будет создать путем размножения с текущих (по которым уже есть статусы).
12
Если у документа статус — Не принят
При проверки в Журнале взаимодействия с ИС Маркировка в графе Комментарий ошибка (так как ошибка длинная, путем копи паста в блокнот):
Обработка запроса провалилась: ошибка на этапе обработки документа системой: invalid request data: data.properties.contract_type should be equal to one of the allowed values, data.properties.contract_type should be equal to one of the allowed values, data.properties.source_type should be equal to one of the allowed values, data.properties should have required property 'contract_num', data.properties should match exactly one schema in oneOf
Не заполнен «Реестровый номер контракта»
В документе заполнить поле «Реестровый номер контракта (договора) в Единой ИС в сфере закупок.
13
ORA-20103: Не найден корректный идентификатор применения в тексте КИЗ
При сканировании упаковки ЛП, считывается код Data Matrix, который не имеет установленных стандартом идентификаторов применения. Поставщик некорректно сгенерировал штрихкод или упаковка повреждена.
Открыть текстовый редактор (Блокнот) и попробовать отсканировать упаковку в документ. Сканированный код сравнить со строкой КИЗ, отсканированной в Парусе. Если одинаковые, то обратиться в ЧЗ, либо к поставщику. Если разные, то скопировать из Блокнота и вставить в строку КИЗ в Парусе.
Согласно Постановление Правительства РФ от 14.12.2018 N 1556 (ред. от 28.01.2021) код маркировки должен состоять только из групп применения с символами 01, 21, 91, 92.
первая группа данных — глобальный идентификационный номер торговой единицы, состоящий из 14 цифровых символов, которому предшествует идентификатор применения (01);
вторая группа данных — индивидуальный серийный номер торговой единицы, состоящий из 13 символов цифровой или буквенно-цифровой последовательности (латинского алфавита), которому предшествует идентификатор применения (21).
третья группа данных — идентификатор (индивидуальный порядковый номер) ключа проверки, предоставляемый эмитентам средств идентификации оператором системы мониторинга в составе кода проверки в соответствии с настоящим Положением, состоящий из 4 символов (цифр, строчных и прописных букв латинского алфавита), которому предшествует идентификатор применения (91).
четвертая группа данных — значение кода проверки, предоставляемое эмитентам средств идентификации оператором системы мониторинга в составе кода проверки в соответствии с настоящим Положением, которому предшествует идентификатор применения (92), и состоящее из 44 символов (цифр, строчных и прописных букв латинского алфавита, а также специальных символов).
14
При отправке документов в Журнале взаимодействия с ИС маркировка зарегистрирована ошибка:
Код ошибки -19
Текст ошибки — Операция не может быть выполнена. Хронология событий нарушена, неверно указана дата операции.
- Пользователь указал не верную дату документа в поле «Дата». Тем самым нарушив хронологию событий по дате.
- Поставщик не указал в документе временную зону или указал +0:00, соответственно искажается время
- Пример:
Документы операций с упаковками
601 дата 05.04.2021
ПКМ — Связи выходные документы
701 дата 02.04.2021
Поэтому и выходит ошибка: 19 Операция не может быть выполнена. Хронология событий нарушена, неверно указана дата операции.
Операции, производимые над SGTIN, должны совершаться последовательно.
Причина: в операции неверно указана operation_date.
Решение:
Проверить поле Дата в документах. В 701 документе дата не может быть раньше, чем в 601.
Проверить в 601 документе поле «Реестровый номер контракта (договора) в Единой информационной системе в сфере закупок, заполнить данное поле таким же значением в 701 документе. Заполняется только при федеральном или региональном источнике финансирования, для собственных средств не является обязательным.
2. Попробовать отправить документ позже в течение дня. Если документ не отправится успешно, то обратиться в СТП ЧЗ.
15
Документ 210 «Запрос информации по номеру SGTIN/SSCC»
Статус — Получен ответ, но по связям не находит документ 211 «Результат обработки сведений по номеру SGTIN/SSCC»
Проверяем:
Учет — Документы операций с упаковками
Проверить первоначальный документ 601 или 612. Как это сделать?
На 210 ПКМ – Связи – Входные документы – нашли документ 601/612 и проверяем статус у этого документа, должен быть «Статус обмена данными с ИС Маркировка» – Получен.
Далее на 601 или 612 ПКМ – Связи – Выходные документы – проверяем какие документы по связям есть.
Если видим только 210 проверяем статус у этих 210.
Если статус — Получен ответ – это значит что из ЧЗ пришел по ним ответ в виде 211. Но если на 210 ПКМ – Связи – Выходные документы мы не находим 211 документа, то возникает проблема у клиента, которую можно решить с помощью рекомендаций.
Рекомендации:
1. В разделе Учет — Журнал взаимодействия с ИС Маркировка
на документах: 210 выполнить действие ПКМ — ИС Маркировка — Проверить статус еще раз. По связям еще раз проверить выходные документы не подгрузился ли 211. Если не подгрузился переходим к пункту 2.
2. Документы — Документы операций с упаковками
на документах: 210 выполнить действие ПКМ — Размножить и далее на размноженных документах выполнить действие ПКМ — ИС Маркировка — Отправить. Дождаться пока документ получит статус — Получен ответ и по связям ПКМ — Связи — Выходные документы проверить 211 документы.
16
Указание Доли выбываемого ЛП
Реализована возможность «быстрого» указания доли выбываемого ЛП после сканирования кода маркировки.
Для режима «Работа с упаковками ⇒ Добавление» реализована редактируемая колонка грида «Доля от вторичной упаковки». Механизм указания доли доступен только для типов документов 511, 521, 531, т.к. в других документах учет доли не предусмотрен системой МДЛП.
Для выбытия целой упаковки, как и ранее, ничего дополнительно указывать не требуется.
Для выбытия доли вторичной упаковки ее значение необходимо указывать в формате правильной дроби, числитель которой обозначает количество выбываемых первичных упаковок, а знаменатель – количество первичных упаковок во вторичной упаковке.
Указание дроби допускается в формате, например, «2/10», «210», при этом разделитель «» автоматически заменяется на «/». При указании дроби в формате «2.10» и подобных пользователь получит ошибку вида: «Некорректные символы в тексте доли от вторичной упаковки: «.»».
Внимание! При последующем долевом выбытии кода маркировки необходимо указывать тот знаменатель дроби, который был выбран в первый раз – это правило, действующее в системе МДЛП.
17
Документ — 531
531 ПКМ — ИС Маркировка — Сформировать отчет о выбытии
выходит ошибка:
В документе «**» присутствуют позиции без криптозащиты. Формирование отчета о выбытии невозможно.
Данная ошибка означает, что в упаковках отсутствует информация о криптозащите.
Выбытие через РВ может осуществляться только при отсканированных упаковках (на документе ПКМ — Работа с упаковками — Добавление). Если по какой-то причине у Вас нет возможности создать документ и отсканировать заново упаковки, то ЛП без криптозащиты Вы можете отправить по упрощенной схеме (по согласованию с ЧЗ) при помощи действия ПКМ — ИС Маркировка — Отправить.
Возможно, код маркировки (КМ) выбрали из списка существующих или отсканировали, но не в разделе Работа с упаковками — Добавление, а в спецификации «Упаковки» после действия «Добавить». В этих случаях даже если КМ содержит криптохвост, то в ДОУ его не будет. При размножении ДОУ и после успешной отправки на РВ — криптохвост удаляется.
18
Документ – 531
ПКМ – Работа с упаковками – Добавление
В открывшемся окне «Набор упаковок» нажимают ПКМ – Добавить
В поле КИЗ – сканируют упаковку нажимают ОК.
Первая упаковка – сохраняется и отображается в разделе «Набор упаковок».
Вторую упаковку сканируют нажимают ОК, вторая упаковка не отображается в разделе «Набор упаковок». Но при нажатии в разделе «Набор упаковок» еще раз ОК в спецификацию «Упаковки» добавляются 2 записи, визуально мы видели только одну, а сканировали 2.
Наблюдается только в ВЕБ версии под конкретным пользователем.
Пользователю необходимо обратиться в Отдел технической поддержки или прислать событие через Парус Консультант с описанием проблемы.
Следующие действия выполняются специалистами Отдела технической поддержки или профильным аналитиком:
Под пользователем выйти из всех запущенных сеансов.
В Администраторе – Учет – Профили пользователей
Отбор по графе «Пользователь (наименование)»
Тип – WEB
Приложение системы — Учет маркированных товаров
Раздел системы — Набор упаковок
Вид — Формы просмотра раздела, Параметры действий раздела – пометить чекером и удалить.
Перезайти под пользователем в раздел и проверить.
19
605 «Уведомление получателя об отзыве отправителем переданных лекарственных препаратов».
Схема:
1. поставщик формирует документ 415 «Отгрузка со склада» и отправляет в систему;
2. мы получаем 601 «Уведомление об отгрузке со склада».
3. Если поставщик понял что где-то в 415 «Отгрузка со склада» допущена ошибка, то он отправляет в систему 251 «Отзыв отправителем переданных получателю лекарственных препаратов»;
4. мы получаем 605 «Уведомление об отзыве отправителем переданных лекарственных препаратов».
5. клиенту необходимо в разделе Учет — Документы операций с упаковками выполнить действие ПКМ — ИС Маркировка — Получить(если не получится попробовать Загрузить из журнала)
В появившемся документе 605 «Уведомление об отзыве отправителем переданных лекарственных препаратов» будет информация в спецификации Упаковки. По информации в данной спецификации пользователь может сверить информацию упаковок и узнать какой именно 601 документ был отозван поставщиком.
20
627 «Уведомление владельца о регистрация в ИС МДЛП сведений
об оприходовании».
Реализована работа с типом документа 627 (Уведомление владельца о регистрации в ИС МДЛП сведений об оприходовании). Действие ПКМ — ИС Маркировка — Получить.
После успешной обработки схемы 702 в сторону Участника, который по данным МДЛП являлся
владельцем оприходованных лекарственных препаратов, отправляется уведомление об оприходовании
– 627-posting_notification.xsd. Уведомление содержит в себе перечень оприходованного товара, а
также сведения об Участнике, который осуществил оприходование.
21
На действие «Добавление/размножение документа операций с упаковками» раздела «Документы операций с упаковками» в каталоге «552. Вывод ЛП из оборота по различным причинам» по юридическому лицу «Организация» у Вас нет прав. Обратитесь к Администратору.
Не верно указано значение в поле Принадлежность
Ошибка свидетельствует о том, что у пользователя нет прав на юр. лицо — «Организация».
В поле Принадлежность необходимо указать юр. лицо код мединфо.
22
1) Документы операций с упаковками
В документе «531. Выдача ЛП в медицинском учреждении»
Статус обмена данными с ИС Маркировка — Принят частично
Код ошибки — 11
Текст ошибки — Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке
2) В документе «701. Подтверждение (акцептование) сведений»
Статус обмена данными с ИС Маркировка — Принят частично (Не принят и т.д.)
Код ошибки — 11
Текст ошибки — Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке
1) Статус — Принят частично возвращает Честный Знак. Из Паруса отправляется все корректно.
Проблема возникает, когда пытаются выдать лекарственные препараты, которые не находятся на балансе. Необходимо в ЛК ЧЗ проверить статусы 701 и 702 документа. Если документы были корректно сформированы, то ЛП должны стоять на балансе в ЛК ЧЗ. Необходимо проверить фактическое наличие выдаваемых упаковок и далее за разъяснениями обратиться в СТП Честного знака.
2) Статус — Принят частично (Не принят и т.д.) возвращает Честный Знак. Из Паруса отправляется все корректно.
Проблема возникает, когда пытаются выдать лекарственные препараты, которые не находятся на балансе, либо не получена информация по цепочке 210-211. Необходимо проверить цепочку документов 601(612)-210-211-912. Убедиться, что информация по всем транспортным упаковкам была получена и отправлена корректно. И что 912 документ не был отправлен в ЧЗ раньше, чем отправили 701. Если вся последовательность была выполнена корректно, далее за разъяснениями обратиться в СТП Честного знака.
23
Зависание при сканировании большого объема упаковок.
Документы — Документы операций с упаковками
ПКМ — Работа с упаковками — Добавление
В открывшемся окне Набор упаковок ПКМ — Добавить
В окне Набор упаковок: Добавление в поле КИЗ производят сканирование КИЗа с упаковки лекарственного препарата и нажимают Ок.
В поле КИЗ на данный момент происходит сохранение истории сканированных КИЗ, когда объем достигает большого количества возникает зависание.
Можете применять ручную очистку поля по shift+del.
24
702 «Оприходование лекарственных препаратов» третичные упаковки
При создании документа выполняем действия согласно инструкции, размещенной у нас на портале info.parusyug.ru Парус 8. Учет маркированных товаров/документ — 2.Пользовательская инструкция по работе с модулем «Учет маркированных товаров».
В спецификацию «Упаковки» производим добавление и сканирование упаковок, заполняем «Сведения о цене», отправляем документ, проверяем статус.
Если в документе содержатся третичные упаковки, необходимо пометить их чекерами, далее нажать ПКМ — Формирование — Запрос содержимого транспортных упаковок (документ 210 «Запрос информации по номеру SGTIN/SSCC») заполняем Реквизиты документа: каталог (можно сразу указать 210.Запрос информации по номеру SGTIN/SSCC), тип документа — ДОУ, префикс документа, дата.
Отрабатываем схему 210-211-912.
В ответ на наш запрос (документ 210 «Запрос информации по номеру SGTIN/SSCC») нам приходит ответ от ИС МДЛП документ 211 «Результат обработки сведений по номеру SGTIN/SSCC», и документ 912 «Расформирование упаковки».
25
Документы операций с упаковками
В разделе Учет — Журнал взаимодействия с ИС Маркировка уже получен документ 601.
В разделе Документы — Приходные документы выполнить действие ПКМ — ИС Маркировка — Загрузить из журнала
Выбрать документ, нажать Ок.
Выходит ошибка:
Не найдена операция приходования для документа операций с упаковками.
Документ пришел по новой операции приходования.
Необходимо в ЛК ЧЗ по документу выгрузить квитанцию .xml и прислать событие на Парус Консультант с указанием по какому документу возникла ошибка и приложить квитанцию из ЧЗ.
26
Документы операций с упаковками
Статус — Не принят
Код ошибки — 200
Текст ошибки — Идентичный документ был отправлен ранее
Ошибка может возникнуть при попытке загрузки дублирующего документа.
- Проанализировать, почему документ был отправлен повторно
- Проверить статус обработки отправленного раннее идентичного документа
Если необходимо отправить документ повторно, то необходимо размножить документ, на закладке «Дополнительно» проверить заполнение полей «Документ-подтверждение»/»Документ — основание» и выполнить отправку в ИС Маркировка.
27
Документ — 531 статус — Не принят
При проверки в Журнале взаимодействия с ИС Маркировка в графе Комментарий ошибка (так как ошибка длинная, путем копи паста в блокнот):
Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-pattern-valid: Value ' 2 АПТ' is not facet-valid with respect to pattern 'S.*' for type 'document_number_200_type'.
Не соответствие формату элемента
В документе на закладке «Дополнительно» заголовок «Документ-подтверждения (соответствия) / документ розничной торговли» в поле «Номер» перед введенным номером есть пробел.
28
Документы операций с упаковками
Документ — 601(612) в поле контрагент — пусто, поле Место деятельности контрагента — заполнено.
При формировании документа 701 выходит ошибка:
Контрагент должен быть задан
В поле контрагент не задано юр. лицо
Необходимо предоставить сведения для настройки места деятельности и контрагента:
Место деятельности
Наименование контрагента
ИНН
КПП
р/с
Адрес
Заявку можно прислать через Парус Консультант или обратиться в Отдел технической поддержки.
29
Документы операций с упаковками
Тип документа — 521, 531
Действие ПКМ — ИС Маркировка — Сформировать отчет о выбытии
В разделе Учет — Регистраторы выбытия кодов маркировки
Спецификация Очередь заданий
Происходит зависание в очереди
Проверить работоспособность регистратора выбытия
Возможно связано с ошибкой 5090: «Срок действия ПИН-кода истек. Необходимо ввести его в РВ повторно» (ошибка отображается только в логах сервиса взаимодействия)
Раз в сутки нужно вводить PIN-код.
Ввод PIN-кода раз в сутки является обязательным условием для соблюдения требований безопасности и отключить его нельзя.
30
Документы операций с упаковками
ПКМ — Работа с упаковками — Добавление
При попытке сохранить отсканированную упаковку выходит ошибка:
ORA-20103: Добавление упаковки в документ операций с упаковками в состоянии отличном от «Не отработан» недопустимо.
Возникает, когда у документа в гриде «Состояние» статус «Отработан как план» или «Отработан как факт»
Ошибка возникает, когда в документ который имеет в гриде «Состояние» статус «Отработан как план» или «Отработан как факт». Необходимо снять отработку с документа (ПКМ — Состояние — Снять отработку) и тогда производить добавление новых упаковок в спецификацию.
31
619 «Уведомление получателя об отгрузке лекарственных препаратов со склада отправителя в рамках агентского договора»
Это 619 уведомление означает, что в адрес участника оборота была выполнена отправка ЛП по 472 схеме.
В настоящий момент в ПП «Парус-Бюджет 8. Учет маркированных товаров» эта цепочка не реализована, т.к. существует её аналог — схема 415 со значениями (в том числе) «Тип договора при реализации» (contract_type):
— 2 (комиссия);
— 3 (агентский договор);
Следовательно, предлагаем в текущей деятельности использовать её.
32
Документы операций с упаковками
Тип документа — 912 (или др.)
Статус — Не принят
Код ошибки — 38
Текст ошибки — Операция не может быть выполнена — указанный SGTIN/SSCC не найден в системе или расформирован.
Ошибка может возникнуть при попытке осуществления операции агрегации/ изъятия/ докладки/ уничтожения для SGTIN/SSCC, которые не зарегистрированы в системе или раннее были расформированы.
Рекомендуется проверить отправляемый документ и убедиться, что:
- указаны существующие SGTIN/SSCC;
- SSCC не расформирован по данным системы.
Необходимо проверить цепочку документов 601(612)-210-211-701-912. Убедиться, что информация по всем транспортным упаковкам была получена и отправлена корректно. И что 912 документ не был отправлен в ЧЗ раньше, чем отправили 701. Если вся последовательность была выполнена корректно, далее за разъяснениями обратиться в СТП Честного знака.
33
Документы операций с упаковками
Тип документа — 531
ПКМ — ИС Маркировка — Отправить
или
ПКМ — ИС Маркировка — Сформировать отчет о выбытии
ошибка: В документе «**» присутствуют упаковки, входящие в нерасформированную транспортную упаковку
Ошибка возникает из-за отсутствия «Отработки» документа 912
Необходимо найти 912 ДОУ, в котором присутствуют КИЗ упаковки из текста ошибки. Выбрать документ, ПКМ — Состояние — Отработан как факт. Если возникает ошибка «Невозможна отработка операции расхода как факт для упаковки «**», оприходованной как план.», в таком случае ПКМ — Состояние — Отработан как план.
Повторить отправку 531 ДОУ.
В ситуациях, когда 912ДОУ не получается отработать ни как план, ни как факт, а 531ДОУ — без Отработки 912ДОУ не хочет отправляться в ЧЗ, нужно снять отработку с 211ДОУ. Для этого находим 912й ДОУ с упаковкой из ошибки, на нём «ПКМ — Связи — вХодные документы» выбираем в окне «Документы операций с упаковками» и переходим к 211ДОУ. Снимаем отработку с 211ДОУ. Затем пробуем повторно отправить 531ДОУ.
Если при отправке будет ругаться уже на другую упаковку, повторяем теже действия, но для другого 211.
34
Документы операций с упаковками
Тип документа — 701
Статус отправлен
ПКМ-связи-Журнал взаимодействия с ИС Маркировка
в поле примечании Произошла ошибка при отправке запроса.
Ошибка возникает при наличии принятого документа в ЧЗ но с другим идентификатором операции ИС Маркировка
Необходимо найти отклоненный 701 документ в ЛК ЧЗ, рядом должен быть еще один 701 документ, который со статусом принят с небольшим разрывом по времени, скачать квитанцию документа и сравнить КИЗ.
В модуле Маркировка статус не обновить, поскольку отличается идентификатор. Со стороны пользователя никаких действий производить не нужно.
35
Документы операций с упаковками
Тип документа — 531
ПКМ — ИС Маркировка — сформировать отчет о выбытии
Не отправляются документы, статус не определен
Очередь создается на регистратор выбытия и удаляется, документ в ЛК ЧЗ не загружается.
Необходимо обратить внимание на номер документа, максимально допустимая длина поля «номер документа» 16 символов.
36
Документы операций с упаковками
Тип документа — 531
ПКМ — ИС Маркировка — сформировать отчет о выбытии
ПКМ — ИС Маркировка — Проверить статус
Статус — «Принят частично»
Не все упаковки выгружены в МДЛП или часть упаковок отклонены.
Если упаковки не были отправлены, сформировать новый 531 документ и направить повторно недостающие упаковки.
Если упаковки выгружены все, данную информацию можно посмотреть в регистраторе выбытия, в ЛК ЧЗ должен быть документ 10532 — «Выдача для мед. помощи ЛП с невалидными КМ (регистратор выбытия)»
Документ 10532 автоматически передаётся для ЛП, код маркировки которых не прошёл верификацию.
В данном случае дальнейших действий не требуется — ЛП считается выведенным из оборота.
Обращаем внимание, что лекарственные препараты, КМ которых не прошли проверку, рекомендуется возвращать поставщику.
Содержание:
1. XML – расширяемый язык разметки
2. Устранение Ошибки разбора XML в 1С
3. «Обход» Ошибки разбора XML в 1С
1. XML – расширяемый язык разметки
В данной статье речь пойдёт о причинах возникновения фатальной ошибки «Ошибка разбора XML» и способах устранения данной неполадки. Также будет дана инструкция не по устранению, но «обходу» ошибки, то есть действиям на опережение.
XML (с английского – extensible markup language – расширяемый язык разметки) – это язык разметки, который рекомендует Консорциум Всемирной паутины. Обычно язык разметки XML служит для описания документации, соответствующего типа, а также описывает действия соответствующих процессоров. Расширяемый язык разметки имеет довольно простой синтаксис, поэтому используется по всему миру, чтобы создавать и обрабатывать документацию программным способом. Он создавался именно для использования в Интернете. XML назвали именно расширяемым языком разметки, так как в нём нет фиксации разметки, которая содержится внутри документа, а именно: программист может создавать любую разметку, а ограничения будут встречаться лишь в синтаксисе.
2. Устранение Ошибки разбора XML в 1С
«Ошибка разбора XML» возникает исключительно в тонком клиенте 1С. Также стоит отметить, что «Ошибка разбора XML» также довольна схожа с ошибкой по формату потока, которая возникает в толстом клиенте. Обычно в 1С «Ошибка разбора XML» возникает по причине наличия кэша метаданных. И если очистить кэш, то ошибка будет устранена. Выглядит окно с ошибкой, а также окно с комментариями от технической поддержки следующим образом:
Рис. 1 Окно Ошибки разбора XML в 1С
XML данные читаются по потокам, так что в каждый из моментов времени объект «сосредоточен» в некотором узле XML. Из-за этого также может возникать фатальная ошибка «Ошибка разбора XML». Для того чтобы её устранить, можно вызвать функцию «ИсключениеЧтенияXml», как показано на скриншоте примера ниже:
Рис. 2 Вызов функции ИсключениеЧтенияXML для устранения Ошибки разбора XML в 1С
3. «Обход» Ошибки разбора XML в 1С
Данные два способа (очистка кэша метаданных и функция «ИсключениеЧтенияXml») – не все возможные варианты устранения ошибки разбора XML. Далее рассмотрим нестандартный подход, который позволит избежать ошибки еще до её возникновения.
Для наглядности будем работать в конфигурации 1С:Бухгалтерия предприятия, одной из наиболее распространенных программ фирмы 1С. У многих людей, которые пользуются программой 1С:Отчётность появляются неполадки при попытках открыть данные/файлы от налоговой. Чтобы открыть такой файл повторяем следующие действия:
· Переходим по пути: «Настройки 1С:Отчётности → Журнал обмена с контролирующими органами», как показано на скриншоте ниже:
Рис. 3 Настройка 1С Отчетности
· Далее кликаем на «Запросы» и выделяем ту выписку, которую не было возможности открыть из-за ошибки, как продемонстрировано на скриншоте ниже:
Рис. 4 Выбор выписки с Ошибкой разбора XML в 1С
· Обращаем внимание на стадию отправки, которая располагается внизу этого сообщения, и кликаем два раза на зелёный круг:
Рис. 5 Стадия отправки документа с Ошибкой разбора XML в 1С
· Появляется транспортное сообщение, в нём кликаем на «Выгрузить» и выбираем папку, куда необходимо провести выгрузку, после чего сохраняем данный файл. Пробуем открыть его, при помощи любого из графических редакторов, который может поддерживать формат PDF, как показано на скриншоте ниже:
Рис. 6 Результат обхода Ошибки разбора XML в 1С
· Всё успешно открылось, а ошибка даже не успела возникнуть.
Специалист компании «Кодерлайн»
Айдар Фархутдинов
ORA-20103: Не задан мнемокод пользователя ИС Маркировка.
Файл – Сервис – Параметры
В окне отбора в поле Номер с-по – необходимо указать 1816.
Откроется окно Параметры: Идентификация
В поле Пользователь – ввести логин пользователя, под которым возникает ошибка.
В поле Организация – Министерство здравоохранения КК
Параметр:
Каталог – Документы операций с упаковками
Номер – 1 816
Код – MRKPackageOperationDocuments_MrkApiUser
Наименование – Пользователь ИС Маркировка
ПКМ – Исправить значение
Указывается значение из раздела: Учет – Пользователи ИС Маркировка
Проверяем, чем заполнен параметр и соответствует ли это сведениям из раздела Учет — Пользователи ИС Маркировка.
Ошибка сервиса: «Для документа XML должен существовать документ более высокого уровня.
Line: 0
«.
Ошибка свидетельствует о том, что для данного IP-адреса компьютера не настроено подключение к серверу МИАЦ.
В Парусе Консультанте необходимо создать событие.
В заявке предоставляется следующая информация:
- Наименование организации
- Ответственный сотрудник и телефон
- Адреса VIPnet coordinator/Адрес Vipnet Clinet (через что подключен АРМ)
- Адрес АРМ пользователя (IP-адрес компьютера)
Сведения оформляются в заявку и отправляются в Отдел информационной безопасности ГБУЗ «МИАЦ» для дальнейшей настройки.
- Необходимо проверить данные действия через «Журнал взаимодействия с ИС Маркировка». После выполнения операции необходимо обязательно нажимать кнопку ОБНОВИТЬ.
- Для специалистов Отдела технической поддержки: Если после этого ничего не произошло, необходимо в разделе Учет — Пользователи ИС Маркировка на пользователе ПКМ — Исправить в поле Сертификат нажать на 3 точки и провалиться в раздел Электронные сертификаты, в каталоге слева выбрать каталог учреждения и проверить сертификат, который подвязан пользователю: Действителен с — Действителен по. Если сертификат закончился, дать пояснение клиенту. -И сказать, чтобы зарегистрировали событие в Парус Консультанте и добавили новую ЭЦП в присоединенные документы.
- Для клиента: Если после этого ничего не произошло, необходимо в разделе Учет — Пользователи ИС Маркировка на пользователе ПКМ — Исправить в поле Сертификат — сверить отпечаток ЭЦП с тем, что в Личном Кабинете Честного знака.
- Если отпечаток в Личном Кабинете Честного знака не совпадает с тем, что в Парусе в разделе Учет — Пользователи ИС Маркировка, необходимо в Парус Консультанте прислать событие с текстом: Актуальная ЭЦП для маркировки. Актуальную ЭЦП прикрепить к событию.
ORA-20103: Контрольный (идентификационный) знак «(01)04680013242190(21)axzxywxxfx4w9» в реестре не определен.
Некорректно нанесен Data Matrix (марка) на ЛП.
Нарушен документооборот.
Проблема в сканере штрих-кодов.
Данная ошибка означает, что КИЗ — (01)04680013242190(21)axzxywxxfx4w9 не найден в разделе Учет — Реестр контрольных идентификационных знаков. Если выполнить ПКМ — Отобрать в поле «Контрольный (идентификационный) знак» вставить — (01)04680013242190(21)axzxywxxfx4w9.
Каталог выбран Вашего юр. лица.
Таким образом делаем вывод, что данный ЛП отсутствует в нашей базе КИЗ.
По умолчанию у каждого пользователя ПКМ — Настройки закладка Прочие стоит чекер «Учитывать регистр символов», таким образом мы в отборе искали КИЗ, в котором маленькие буквы — *axzxywxxfx4w9*. Если Вы уберете этот чекер (временно для проверки КИЗ), то увидите, что в Реестре КИЗ есть КИЗ — (01)04680013242190(21)AXZXYWXXFX4W9 (большие буквы).
2. Проверка документооборота.
Необходимо проверить в документах 601(612), 211, 701 какой КИЗ использовался и какой статус у этих документов, правильно ли они приняты по схеме 601(612)-210-211-701-912 у всех ли статус Получен/Принят?
Если КИЗ с большими или с маленькими буквами не находится в документах (Отбор по колонке КИЗ), значит КИЗ не проходил в ИС Маркировка.
3. Проверка сканера.
При считывании сканера символы имеют разную кодировку, это может быть связано со сканером (там есть настройка регистра символов, для каждого сканера она своя, поэтому пользователь читает руководство пользователя своего сканера и настраивает).
Проверку сканера можно осуществить: Открыть текстовый редактор (Блокнот) и попробовать отсканировать упаковку в документ. Сканированный код сравнить со строкой КИЗ, отсканированной в Парусе. Если одинаковые, то обратиться в ЧЗ, либо к поставщику. Если разные, то скопировать из Блокнота и вставить в строку КИЗ в Парусе.
Если есть другой компьютер и сканер можно проверить еще с помощью них считывание марки.
ORA-06512: на «SYS.UTL_HTTP», line 1130
ORA-12541: TNS:нет прослушивателя
).?
Обратиться в отдел технической поддержки или прислать событие в Парус Консультант.
Ошибка технического характера.
Выходит ошибка:
ORA-20103: Содержимое упаковки «*» не найдено в товарных запасах.
Пример анализа по клиенту:
Документы операций с упаковками
Для документа 912 (хотя может и для другого типа) ПКМ — ИС Маркировка – Отправить
Выходит ошибка:
ORA-20103: Содержимое упаковки «*» не найдено в товарных запасах.
Проверяю:
612 ДОУ 13.04.2021 Получен 12.04.2021 11:56
1) 210 ДОУ 13.04.2021 Получен ответ 13.04.2021 16:35
211 нет
912 ДОУ 16.04.2021 Не определен
2) 210 ДОУ 13.04.2021 Получен ответ 13.04.2021 16:35
211 ДОУ 13.04.2021 Получен 13.04.2021 16:35:46
912 ДОУ 16.04.2021 Не принят 16.04.2021 10:40
701 ДОУ 13.04.2021 Принят 16.04.2021 14:23
Общая проблема: нарушена цепочка документооборота: 612-210-211-701-912.
2 проблемы:
1) 912 ДОУ 16.04.2021 Не определен — при отправке ошибка, так как нет документа 211. Пусть попробуют еще раз отправить 210 документ, если не получится, размножить 210 и отправить еще раз, получить ответ 211 и 912.
2) 912 ДОУ 16.04.2021 Не принят 16.04.2021 10:40 — не принят, так как 701 принят позже ДОУ 13.04.2021 Принят 16.04.2021 14:23. Соответственно нарушили цепочку документооборота.
Должны были сначала 701 отправить и получить статус Принят, затем отправить 912.
Статус — Принят частично
В Журнале взаимодействия с ИС Маркировка
Статус — Принят частично
Код ошибки — 52
Текст ошибки — Операция не может быть выполнена. Указанный SGTIN/SSCC не найден в системе
Рекомендуется проверить отправляемый документ на корректность цепочки документооборота и обратиться с техническую поддержку Честного Знака.
Тип — 531
Статус — Не принят
ПКМ — Связи — Выходные документы — ЖВсИСМ
Код ошибки — 15
Текст ошибки — Попытка изменить состояние вложенного КиЗ
Документы операций с упаковками
Статус – Не принят
В Журнале взаимодействия с ИС Маркировка
Код ошибки — 34
Текст ошибки — Операция не может быть выполнена. Отправитель сведений и владелец SGTIN/SSCC не совпадают.
агрегации/изъятия/докладки/расформирования должны осуществляться владельцем SGTIN/SSCC.
Рекомендуется проверить владельца КИЗ и убедиться, что текущий владелец совпадает с участником, регистрирующим операцию по КИЗ. Для подтверждения статуса владельца рекомендуется акцептовать полученные документы (при их наличии) или дождаться акцептования от отправителя.
Необходимо проверить цепочку документооборота, например если ошибка возникла по документу 912, необходимо проверить, чтобы 701 документ был отправлен раньше, чем 912 и имел корректный статус Принят. Только после этого необходимо совершать действия с документом 912.
Если 912 документ был отправлен раньше чем 701, и на данный момент находится в статусе Не принят с данным кодом ошибки, то необходимо восстановить корректную цепочку отправки документа: сначала отправить 701 документ, дождаться статуса Принят, и только после этого размножить 912 и отправить заново.
Выходит ошибка:
В документе «*» не найдены упаковки, для которых возможно формирование документа акцептования.
В открывшемся окне Документы операций с упаковками будут отображаться связанные документы.
Если пользователю необходимо переотправить 701 документ, то на нужном 701 документе произвести действие размножить и далее выполнить действие Отправить.
На документах ПКМ — Связи — Выходные документы — ЖВсИСМ ошибка:
Код ошибки — 33
Текст ошибки — Операция не может быть выполнена. Указанный SGTIN/SSCC находится в промежуточном состоянии.
Пользователю необходимо восстановить правильную цепочку документооборота и выполнить корректно отправку документов по цепочке:
601-210-211-701 (702) -912.
Таким образом необходимо произвести отправку 701 (702) документа, дождаться пока статус будет Получен и дальше уже произвести отправку 912 документов.
Документы необходимо будет создать путем размножения с текущих (по которым уже есть статусы).
При проверки в Журнале взаимодействия с ИС Маркировка в графе Комментарий ошибка (так как ошибка длинная, путем копи паста в блокнот):
Обработка запроса провалилась: ошибка на этапе обработки документа системой: invalid request data: data.properties.contract_type should be equal to one of the allowed values, data.properties.contract_type should be equal to one of the allowed values, data.properties.source_type should be equal to one of the allowed values, data.properties should have required property 'contract_num', data.properties should match exactly one schema in oneOf
Согласно Постановление Правительства РФ от 14.12.2018 N 1556 (ред. от 28.01.2021) код маркировки должен состоять только из групп применения с символами 01, 21, 91, 92.
первая группа данных — глобальный идентификационный номер торговой единицы, состоящий из 14 цифровых символов, которому предшествует идентификатор применения (01);
вторая группа данных — индивидуальный серийный номер торговой единицы, состоящий из 13 символов цифровой или буквенно-цифровой последовательности (латинского алфавита), которому предшествует идентификатор применения (21).
третья группа данных — идентификатор (индивидуальный порядковый номер) ключа проверки, предоставляемый эмитентам средств идентификации оператором системы мониторинга в составе кода проверки в соответствии с настоящим Положением, состоящий из 4 символов (цифр, строчных и прописных букв латинского алфавита), которому предшествует идентификатор применения (91).
четвертая группа данных — значение кода проверки, предоставляемое эмитентам средств идентификации оператором системы мониторинга в составе кода проверки в соответствии с настоящим Положением, которому предшествует идентификатор применения (92), и состоящее из 44 символов (цифр, строчных и прописных букв латинского алфавита, а также специальных символов).
При отправке документов в Журнале взаимодействия с ИС маркировка зарегистрирована ошибка:
Код ошибки -19
Текст ошибки — Операция не может быть выполнена. Хронология событий нарушена, неверно указана дата операции.
- Пользователь указал не верную дату документа в поле «Дата». Тем самым нарушив хронологию событий по дате.
- Поставщик не указал в документе временную зону или указал +0:00, соответственно искажается время
- Пример:
Документы операций с упаковками
601 дата 05.04.2021
ПКМ — Связи выходные документы
701 дата 02.04.2021
Поэтому и выходит ошибка: 19 Операция не может быть выполнена. Хронология событий нарушена, неверно указана дата операции.
Операции, производимые над SGTIN, должны совершаться последовательно.
Причина: в операции неверно указана operation_date.
Решение:
Проверить поле Дата в документах. В 701 документе дата не может быть раньше, чем в 601.
Проверить в 601 документе поле «Реестровый номер контракта (договора) в Единой информационной системе в сфере закупок, заполнить данное поле таким же значением в 701 документе. Заполняется только при федеральном или региональном источнике финансирования, для собственных средств не является обязательным.
2. Попробовать отправить документ позже в течение дня. Если документ не отправится успешно, то обратиться в СТП ЧЗ.
Документ 210 «Запрос информации по номеру SGTIN/SSCC»
Статус — Получен ответ, но по связям не находит документ 211 «Результат обработки сведений по номеру SGTIN/SSCC»
Учет — Документы операций с упаковками
Проверить первоначальный документ 601 или 612. Как это сделать?
На 210 ПКМ – Связи – Входные документы – нашли документ 601/612 и проверяем статус у этого документа, должен быть «Статус обмена данными с ИС Маркировка» – Получен.
Далее на 601 или 612 ПКМ – Связи – Выходные документы – проверяем какие документы по связям есть.
Если видим только 210 проверяем статус у этих 210.
Если статус — Получен ответ – это значит что из ЧЗ пришел по ним ответ в виде 211. Но если на 210 ПКМ – Связи – Выходные документы мы не находим 211 документа, то возникает проблема у клиента, которую можно решить с помощью рекомендаций.
Рекомендации:
1. В разделе Учет — Журнал взаимодействия с ИС Маркировка
на документах: 210 выполнить действие ПКМ — ИС Маркировка — Проверить статус еще раз. По связям еще раз проверить выходные документы не подгрузился ли 211. Если не подгрузился переходим к пункту 2.
2. Документы — Документы операций с упаковками
на документах: 210 выполнить действие ПКМ — Размножить и далее на размноженных документах выполнить действие ПКМ — ИС Маркировка — Отправить. Дождаться пока документ получит статус — Получен ответ и по связям ПКМ — Связи — Выходные документы проверить 211 документы.
Для режима «Работа с упаковками ⇒ Добавление» реализована редактируемая колонка грида «Доля от вторичной упаковки». Механизм указания доли доступен только для типов документов 511, 521, 531, т.к. в других документах учет доли не предусмотрен системой МДЛП.
Для выбытия целой упаковки, как и ранее, ничего дополнительно указывать не требуется.
Для выбытия доли вторичной упаковки ее значение необходимо указывать в формате правильной дроби, числитель которой обозначает количество выбываемых первичных упаковок, а знаменатель – количество первичных упаковок во вторичной упаковке.
Указание дроби допускается в формате, например, «2/10», «210», при этом разделитель «» автоматически заменяется на «/». При указании дроби в формате «2.10» и подобных пользователь получит ошибку вида: «Некорректные символы в тексте доли от вторичной упаковки: «.»».
Внимание! При последующем долевом выбытии кода маркировки необходимо указывать тот знаменатель дроби, который был выбран в первый раз – это правило, действующее в системе МДЛП.
531 ПКМ — ИС Маркировка — Сформировать отчет о выбытии
выходит ошибка:
В документе «**» присутствуют позиции без криптозащиты. Формирование отчета о выбытии невозможно.
Возможно, код маркировки (КМ) выбрали из списка существующих или отсканировали, но не в разделе Работа с упаковками — Добавление, а в спецификации «Упаковки» после действия «Добавить». В этих случаях даже если КМ содержит криптохвост, то в ДОУ его не будет. При размножении ДОУ и после успешной отправки на РВ — криптохвост удаляется.
ПКМ – Работа с упаковками – Добавление
В открывшемся окне «Набор упаковок» нажимают ПКМ – Добавить
В поле КИЗ – сканируют упаковку нажимают ОК.
Первая упаковка – сохраняется и отображается в разделе «Набор упаковок».
Вторую упаковку сканируют нажимают ОК, вторая упаковка не отображается в разделе «Набор упаковок». Но при нажатии в разделе «Набор упаковок» еще раз ОК в спецификацию «Упаковки» добавляются 2 записи, визуально мы видели только одну, а сканировали 2.
Пользователю необходимо обратиться в Отдел технической поддержки или прислать событие через Парус Консультант с описанием проблемы.
Следующие действия выполняются специалистами Отдела технической поддержки или профильным аналитиком:
Под пользователем выйти из всех запущенных сеансов.
В Администраторе – Учет – Профили пользователей
Отбор по графе «Пользователь (наименование)»
Тип – WEB
Приложение системы — Учет маркированных товаров
Раздел системы — Набор упаковок
Вид — Формы просмотра раздела, Параметры действий раздела – пометить чекером и удалить.
Перезайти под пользователем в раздел и проверить.
1. поставщик формирует документ 415 «Отгрузка со склада» и отправляет в систему;
2. мы получаем 601 «Уведомление об отгрузке со склада».
3. Если поставщик понял что где-то в 415 «Отгрузка со склада» допущена ошибка, то он отправляет в систему 251 «Отзыв отправителем переданных получателю лекарственных препаратов»;
4. мы получаем 605 «Уведомление об отзыве отправителем переданных лекарственных препаратов».
5. клиенту необходимо в разделе Учет — Документы операций с упаковками выполнить действие ПКМ — ИС Маркировка — Получить(если не получится попробовать Загрузить из журнала)
В появившемся документе 605 «Уведомление об отзыве отправителем переданных лекарственных препаратов» будет информация в спецификации Упаковки. По информации в данной спецификации пользователь может сверить информацию упаковок и узнать какой именно 601 документ был отозван поставщиком.
об оприходовании».
Реализована работа с типом документа 627 (Уведомление владельца о регистрации в ИС МДЛП сведений об оприходовании). Действие ПКМ — ИС Маркировка — Получить.
После успешной обработки схемы 702 в сторону Участника, который по данным МДЛП являлся
владельцем оприходованных лекарственных препаратов, отправляется уведомление об оприходовании
– 627-posting_notification.xsd. Уведомление содержит в себе перечень оприходованного товара, а
также сведения об Участнике, который осуществил оприходование.
В поле Принадлежность необходимо указать юр. лицо код мединфо.
1) Документы операций с упаковками
В документе «531. Выдача ЛП в медицинском учреждении»
Статус обмена данными с ИС Маркировка — Принят частично
Код ошибки — 11
Текст ошибки — Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке
2) В документе «701. Подтверждение (акцептование) сведений»
Статус обмена данными с ИС Маркировка — Принят частично (Не принят и т.д.)
Код ошибки — 11
Текст ошибки — Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке
1) Статус — Принят частично возвращает Честный Знак. Из Паруса отправляется все корректно.
Проблема возникает, когда пытаются выдать лекарственные препараты, которые не находятся на балансе. Необходимо в ЛК ЧЗ проверить статусы 701 и 702 документа. Если документы были корректно сформированы, то ЛП должны стоять на балансе в ЛК ЧЗ. Необходимо проверить фактическое наличие выдаваемых упаковок и далее за разъяснениями обратиться в СТП Честного знака.
2) Статус — Принят частично (Не принят и т.д.) возвращает Честный Знак. Из Паруса отправляется все корректно.
Проблема возникает, когда пытаются выдать лекарственные препараты, которые не находятся на балансе, либо не получена информация по цепочке 210-211. Необходимо проверить цепочку документов 601(612)-210-211-912. Убедиться, что информация по всем транспортным упаковкам была получена и отправлена корректно. И что 912 документ не был отправлен в ЧЗ раньше, чем отправили 701. Если вся последовательность была выполнена корректно, далее за разъяснениями обратиться в СТП Честного знака.
Документы — Документы операций с упаковками
ПКМ — Работа с упаковками — Добавление
В открывшемся окне Набор упаковок ПКМ — Добавить
В окне Набор упаковок: Добавление в поле КИЗ производят сканирование КИЗа с упаковки лекарственного препарата и нажимают Ок.
При создании документа выполняем действия согласно инструкции, размещенной у нас на портале info.parusyug.ru Парус 8. Учет маркированных товаров/документ — 2.Пользовательская инструкция по работе с модулем «Учет маркированных товаров».
В спецификацию «Упаковки» производим добавление и сканирование упаковок, заполняем «Сведения о цене», отправляем документ, проверяем статус.
Если в документе содержатся третичные упаковки, необходимо пометить их чекерами, далее нажать ПКМ — Формирование — Запрос содержимого транспортных упаковок (документ 210 «Запрос информации по номеру SGTIN/SSCC») заполняем Реквизиты документа: каталог (можно сразу указать 210.Запрос информации по номеру SGTIN/SSCC), тип документа — ДОУ, префикс документа, дата.
Отрабатываем схему 210-211-912.
В ответ на наш запрос (документ 210 «Запрос информации по номеру SGTIN/SSCC») нам приходит ответ от ИС МДЛП документ 211 «Результат обработки сведений по номеру SGTIN/SSCC», и документ 912 «Расформирование упаковки».
Документы операций с упаковками
В разделе Учет — Журнал взаимодействия с ИС Маркировка уже получен документ 601.
В разделе Документы — Приходные документы выполнить действие ПКМ — ИС Маркировка — Загрузить из журнала
Выбрать документ, нажать Ок.
Выходит ошибка:
Не найдена операция приходования для документа операций с упаковками.
Документы операций с упаковками
Статус — Не принят
Код ошибки — 200
Текст ошибки — Идентичный документ был отправлен ранее
- Проанализировать, почему документ был отправлен повторно
- Проверить статус обработки отправленного раннее идентичного документа
Если необходимо отправить документ повторно, то необходимо размножить документ, на закладке «Дополнительно» проверить заполнение полей «Документ-подтверждение»/»Документ — основание» и выполнить отправку в ИС Маркировка.
При проверки в Журнале взаимодействия с ИС Маркировка в графе Комментарий ошибка (так как ошибка длинная, путем копи паста в блокнот):
Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-pattern-valid: Value ' 2 АПТ' is not facet-valid with respect to pattern 'S.*' for type 'document_number_200_type'.
Документы операций с упаковками
Документ — 601(612) в поле контрагент — пусто, поле Место деятельности контрагента — заполнено.
При формировании документа 701 выходит ошибка:
Контрагент должен быть задан
Необходимо предоставить сведения для настройки места деятельности и контрагента:
Место деятельности
Наименование контрагента
ИНН
КПП
р/с
Адрес
Заявку можно прислать через Парус Консультант или обратиться в Отдел технической поддержки.
Документы операций с упаковками
Тип документа — 521, 531
Действие ПКМ — ИС Маркировка — Сформировать отчет о выбытии
В разделе Учет — Регистраторы выбытия кодов маркировки
Спецификация Очередь заданий
Происходит зависание в очереди
Проверить работоспособность регистратора выбытия
Возможно связано с ошибкой 5090: «Срок действия ПИН-кода истек. Необходимо ввести его в РВ повторно» (ошибка отображается только в логах сервиса взаимодействия)
Ввод PIN-кода раз в сутки является обязательным условием для соблюдения требований безопасности и отключить его нельзя.
Документы операций с упаковками
ПКМ — Работа с упаковками — Добавление
При попытке сохранить отсканированную упаковку выходит ошибка:
ORA-20103: Добавление упаковки в документ операций с упаковками в состоянии отличном от «Не отработан» недопустимо.
Это 619 уведомление означает, что в адрес участника оборота была выполнена отправка ЛП по 472 схеме.
В настоящий момент в ПП «Парус-Бюджет 8. Учет маркированных товаров» эта цепочка не реализована, т.к. существует её аналог — схема 415 со значениями (в том числе) «Тип договора при реализации» (contract_type):
— 2 (комиссия);
— 3 (агентский договор);
Следовательно, предлагаем в текущей деятельности использовать её.
Документы операций с упаковками
Тип документа — 912 (или др.)
Статус — Не принят
Код ошибки — 38
Текст ошибки — Операция не может быть выполнена — указанный SGTIN/SSCC не найден в системе или расформирован.
- указаны существующие SGTIN/SSCC;
- SSCC не расформирован по данным системы.
Необходимо проверить цепочку документов 601(612)-210-211-701-912. Убедиться, что информация по всем транспортным упаковкам была получена и отправлена корректно. И что 912 документ не был отправлен в ЧЗ раньше, чем отправили 701. Если вся последовательность была выполнена корректно, далее за разъяснениями обратиться в СТП Честного знака.
Документы операций с упаковками
Тип документа — 531
ПКМ — ИС Маркировка — Отправить
или
ПКМ — ИС Маркировка — Сформировать отчет о выбытии
ошибка: В документе «**» присутствуют упаковки, входящие в нерасформированную транспортную упаковку
Необходимо найти 912 ДОУ, в котором присутствуют КИЗ упаковки из текста ошибки. Выбрать документ, ПКМ — Состояние — Отработан как факт. Если возникает ошибка «Невозможна отработка операции расхода как факт для упаковки «**», оприходованной как план.», в таком случае ПКМ — Состояние — Отработан как план.
Повторить отправку 531 ДОУ.
В ситуациях, когда 912ДОУ не получается отработать ни как план, ни как факт, а 531ДОУ — без Отработки 912ДОУ не хочет отправляться в ЧЗ, нужно снять отработку с 211ДОУ. Для этого находим 912й ДОУ с упаковкой из ошибки, на нём «ПКМ — Связи — вХодные документы» выбираем в окне «Документы операций с упаковками» и переходим к 211ДОУ. Снимаем отработку с 211ДОУ. Затем пробуем повторно отправить 531ДОУ.
Если при отправке будет ругаться уже на другую упаковку, повторяем теже действия, но для другого 211.
Документы операций с упаковками
Тип документа — 701
Статус отправлен
ПКМ-связи-Журнал взаимодействия с ИС Маркировка
в поле примечании Произошла ошибка при отправке запроса.
Необходимо найти отклоненный 701 документ в ЛК ЧЗ, рядом должен быть еще один 701 документ, который со статусом принят с небольшим разрывом по времени, скачать квитанцию документа и сравнить КИЗ.
В модуле Маркировка статус не обновить, поскольку отличается идентификатор. Со стороны пользователя никаких действий производить не нужно.
Документы операций с упаковками
Тип документа — 531
ПКМ — ИС Маркировка — сформировать отчет о выбытии
Не отправляются документы, статус не определен
Документы операций с упаковками
Тип документа — 531
ПКМ — ИС Маркировка — сформировать отчет о выбытии
ПКМ — ИС Маркировка — Проверить статус
Статус — «Принят частично»
Если упаковки не были отправлены, сформировать новый 531 документ и направить повторно недостающие упаковки.
Если упаковки выгружены все, данную информацию можно посмотреть в регистраторе выбытия, в ЛК ЧЗ должен быть документ 10532 — «Выдача для мед. помощи ЛП с невалидными КМ (регистратор выбытия)»
Документ 10532 автоматически передаётся для ЛП, код маркировки которых не прошёл верификацию.
В данном случае дальнейших действий не требуется — ЛП считается выведенным из оборота.
Обращаем внимание, что лекарственные препараты, КМ которых не прошли проверку, рекомендуется возвращать поставщику.
Передача документов на языке XML является одним из самых распространенных и универсальных методов передачи данных через Интернет.
Протокол XML подразумевает обмен запросами на языке XML. Обмен информацией происходит через соединение TCP/IP по протоколу HTTP или HTTPS (HTTP over SSL) методом POST.
Для обмена информацией посылается XML-запрос вида: <xml_request name=″”>
Возможные значения поля name:
- name=″sms_send″ – запрос на отправку SMS
- name=″sms_status2″ – запрос на получение статуса ранее отправленных SMS
В ответ приходит отклик вида: <xml_result xml_name=″″ res=″″>
Возможные значения поля name:
- name=″sms_send″ – запрос на отправку SMS
- name=″sms_status2″ – запрос на получение статуса ранее отправленных SMS
Возможные значения поля res:
- res=″0″ – ошибок нет
- res=″-xxxxx″ – обнаружена ошибка с кодом -xxxxx
Авторизация происходит передачей логина и пароля: <xml_user lgn=″″ pwd=″″/>
Преимущества:
- возможности расширения благодаря гибкости языка XML
- безопасность и сохранность данных, передаваемых по протоколу HTTPS методом POST
1. Входные параметры
- Адрес обращения :
http://service.qtelecom.ru/public/http/z.php или https://service.qtelecom.ru/public/http/z.php - Формат входных данных :
Content-Type: application/x-www-form-urlencodedContent-Charset: UTF-8
- Тип авторизации : PLAIN (открытым текстом)
- Метод отправки запроса : POST
2. XML-запросы
Отправка SMS сообщения и получение статусов ранее отправленных сообщений производятся отправкой XML-запроса определенной структуры.
В одном XML-запросе может быть отправлено до 250 SMS сообщений.
2.1 XML-запрос для отправки сообщений
Клиент отправляет XML-запрос на отправку сообщения (определить, что идет отправка SMS можно по полю name=″sms_send″)
<?xml version="1.0" encoding="UTF-8" ?>
<xml_request name="sms_send">
<xml_user lgn="" pwd=""/>
<sms sms_id="1" number="XXXXXXXXXXX" source_number="sender" ttl="10">text sms</sms>
<sms sms_id="2" number="XXXXXXXXXXX" source_number="" ttl="15">text sms</sms>
<sms sms_id="s_3" number="XXXXXXXXXXX" source_number="">text sms</sms>
</xml_request>
Параметры запроса:
- sms_id – уникальный идентификатор SMS в системе клиента. Строка длиной до 50 символов. На основе уникальности параметра sms_id проверяется дублирование запросов на отправку SMS. Если sms_id использован повторно, система вернет xml_result/push/@res=1, а в push_id будет указан идентификатор первой попытки отправки сообщения с данным sms_id.
- number – телефонный номер получателя в международном формате или короткий номер. Строка длиной до 25 символов. Параметр не может быть пустым.
- source_number – номер отправителя. Строка длиной от 11 до 16 символов в зависимости от nипа (номер или текст). Параметр не может быть пустым.
- ttl – Время жизни сообщения в минутах. Необязательный параметр. Максимальное время, в течение которого сообщение должно быть доставлено на телефон. Если в течение этого времени доставка не возможна (например абонент не в зоне действия сети), сообщение не будет доставлено вовсе. Внимание, данная функция может не работает для некоторых направлений, например для CDMA телефонов.
При успешном разборе XML-запроса в ответ придет сообщение вида:
<xml_result xml_name="sms_send" res="" >
<push sms_id="1" push_id="XXXX" res="0" number="XXXXXXXXXXX" sms_count=""/>
<push sms_id="2" push_id="XXXX" res="0" number="XXXXXXXXXXX" sms_count=""/>
<push sms_id="3" res="" description=""/>
</xml_result>
Параметры ответа:
- push_id – уникальный идентификатор SMS в системе ESME
- sms_id – уникальный внутренний идентификатор SMS в системе клиента
- res=0 – SMS было отправлено успешно
- res – ″-xxxx″ – код ошибки, возникшей при отправке конкретного SMS
- description – описание ошибки, возникшей при отправке конкретного SMS
- number – номер телефона получателя SMS
- sms_count – количество SMS, из которых состоит одно набранное сообщение
Если в результате разбора XML-запроса возникли ошибки, придет сообщение вида:
<xml_result res=″-XXXX″ description=″″/>
Параметры ответа:
- res – код ошибки XML-запроса или его обработки
- description – описание ошибки
2.2 XML-запрос для получения статуса ранее переданных сообщений
Клиент отправляет XML-запрос на получение статуса переданных сообщений (определить, что идет получение статуса SMS можно по полю name=″sms_status2″)
<?xml version="1.0" encoding="UTF-8" ?> <xml_request name="sms_status2" > <xml_user lgn="" pwd=""/> <sms push_id=""/> <sms push_id=""/> <sms push_id=""/> <sms push_id=""/> </xml_request>
Параметры запроса:
- push_id – идентификатор ранее переданного SMS в системе ESME
При успешном разборе XML-запроса в ответ придет сообщение вида:
< xml_result name="sms_status2" res="" > < sms push_id="" status="" number="XXXXXXXXXXX" delivery_date="" delivery_time="" description="" /> < sms push_id="" status="" number="XXXXXXXXXXX" delivery_date="" delivery_time="" description="" /> < sms push_id="" status="" number="XXXXXXXXXXX" delivery_date="" delivery_time="" description="" /> </xml_result>
Параметры ответа:
- push_id – идентификатор ранее переданного SMS в системе ESME
- status – код статуса доставки
- number – номер телефона, на который было отправлено сообщение с указанным push_id
- delivery_time – время доставки SMS. Строка вида «hh:mm:ss»
- delivery_date – дата доставки SMS. Строка вида «dd.mm.yyyy»
- description – описание статуса. Строка.
Если в результате разбора XML-запроса возникли ошибки, придет сообщение вида:
<xml_result res="-XXXX" description=""/>
Параметры ответа:
- res – код ошибки XML-запроса или его обработки
- description – описание ошибки
3. Ограничение на передачу специальных символов в тексте SMS
Для предотвращения ошибок при разборе XML-запросов и ответов, символы в тексте сообщения, которые используются как служебные в языке XML, необходимо заменять. Замена производится в запросах по таблице слева направо, а в ответах производится обратная замена справа налево.
| Специальный символ | Замена |
|---|---|
| < | < |
| > | > |
| » | " |
| ‘ | ' |
| & | & |
4. Статусы доставки ранее отправленных SMS
При выполнении запроса на получение статусов доставки ранее переданных сообщений <sms_status2> возвращаются коды, представленные в таблице.
| Статус | Описание | Расшифровка статуса |
|---|---|---|
| -1004 | Push to SMSC failed | SMS не доставлена по одной из следующих причин: – абонент находится вне зоны действия сети; – номер не обслуживается оператором связи; – недостаточно средств на счете; – для абонента заблокирован/не поддерживается прием SMS; – переполнена очередь входящих SMS на телефоне абонента; либо по другим причинам, связанным с невозможностью доставки. |
| -1 | Bad submit_id | Указан не существующий push_id сообщения |
| 1 | Push request queued | SMS помещена в очередь на отправку |
| 2 | Request redirected to SMSC/MMSC | SMS передана оператору связи и ожидает доставку |
| 4 | Content delivery confirmed | SMS доставлена |
5. Коды ошибок, возникающих при обработке запросов
При обработке XML-запроса могут возникать ошибки, код которых возвращаются в атрибуте <res>, а описание в атрибуте <description> ответа. Не следует путать эти коды ошибок со статусами доставки SMS!
Система выдает описания ошибок, возникших как при разборе XML-запроса в целом, так и для каждого отдельного переданного сообщения.
5.1 Ошибки, относящиеся к XML-запросу в целом
Код и описание ошибки при разборе XML-запроса передается параметрами res и description в теге <xml_result>. Если возникли ошибки при разборе XML-запроса, она относится ко всем сообщениям данного запроса и ни одно из переданных в этом запросе сообщений не будет доставлено.
5.2 Ошибки, относящиеся к передаче отдельных сообщений запроса
Код и описание ошибки при отправке каждого конкретного SMS передается параметрами res и description в теге <push>. Код и описание ошибки в теге <push> относится только к сообщению с данным <push_id>. Все сообщения запроса при этом будут доставлены или не доставлены независимо друг от друга.
0 – проверка ЭП успешна или создание ЭП успешна или проверка сертификата открытого ключа успешна;
-1 – нет поля data или signed в json;
-2 – нет тега
<ds:DigestValue> или нет хеша; -3 – нет тега
<ds:SignatureValue> или нет подписи; -4 – нет тега
<ds:X509Certificate> или нет сертификата проверки; -5 – внутренняя ошибка libgzcryptosign.so;
-6 – электронная подпись целостная, но срок действия ключа подписи истек;
-7 – электронная подпись целостная, но в сертификате отсутствует назначение — для подписи;
-8 – ошибка каноникализации или трансформации данных, полученных для проверки подписи;
-9 – ошибка вычисления хэша;
-10 – вычисленный хэш от данных и хэш в xml не совпадают;
-11 – ошибка создания каноклизированной xml для проверки подписи;
-12 – нарушена целостность электронной подписи или данных;
-13 – алгоритм формирования подписи не является ГОСТ 34.10-2001_256 или ГОСТ 34.10-2012_256;
-14 – нет данных для подписи;
-15 – ошибка создания каноклизированной xml для создания подписи;
-16 – срок действия сертификата открытого ключа менее 10 лет
-17 – В запросе отсутствует HTTP заголовок CertificateType
-18 — Отсутствуют или имеют неправильный формат атрибуты со ссылками и значениями доказательств подлинности.
-19 — В сообщении не найден действительный штамп времени на подпись.
-20 — Значения ссылок на доказательства подлинности и сами доказательства, вложенные в сообщение, не соответствуют друг другу.
-21 – Подпись на штамп времени не действительна.
-22 – XAdES содержит не поддерживаемые атрибуты.
-23 – Тип содержимого XAdES не соответствует
1 – электронная подпись целостная, но этот сертификат или один из сертификатов в цепочке сертификатов недействителен;
4 – электронная подпись целостная, но текущий сертификат или один из сертификатов в цепочке отозван;
8 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов не имеет действительной подписи;
16 – электронная подпись целостная, но сертификат или цепочка сертификатов недействительны для предполагаемого использования;
32 – электронная подпись целостная, но сертификат или цепочка сертификатов основана на не доверенном корневом сертификате;
64 – электронная подпись целостная, но статус отзыва текущего сертификата или одного из сертификатов в цепочке сертификатов неизвестен;
128 – электронная подпись целостная, но один из сертификатов в цепочке был выдан центром сертификации, который был сертифицирован исходным сертификатом;
256 – электронная подпись целостная, но один из сертификатов имеет неправильное расширение;
512 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение policy constraints, а один из выпущенных сертификатов имеет запрещенное расширение сопоставления политик или не имеет необходимого расширения политик выдачи;
1024 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение basic constraints, и либо сертификат не может быть использован для выдачи других сертификатов, либо длина пути цепочки превышена;
2048 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет недопустимое расширение name constraints;
4096 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, которое содержит неподдерживаемые поля;
8192 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, а name constraints отсутствует для одного из вариантов имени в конечном сертификате;
16384 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, и нет разрешенного name constraint для одного из вариантов имени в конечном сертификате;
32768 – электронная подпись целостная, но сертификат или один из сертификатов в цепочке сертификатов имеет расширение name constraints, и одно из вариантов имени в конечном сертификате явно исключен;
16777216 – электронная подпись целостная, но статус отзыва сертификата или одного из сертификатов в цепочке сертификатов недоступен или устарел;
33554432 – электронная подпись целостная, но конечный сертификат не имеет каких-либо результирующих политик выдачи, а один из выдающих сертификатов центра сертификации имеет расширение policy constraints, требующее этого;
67108864 – электронная подпись целостная, но сертификат не доверенный;
134217728 – электронная подпись целостная, но сертификат не поддерживает критическое расширение;
1048576 – электронная подпись целостная, но сертификат подписан слабым алгоритмом;
65536 – электронная подпись целостная, но цепочка сертификатов не полная;
131072 – электронная подпись целостная, но список отзывов сертификатов (CTL), использованный для создания этой цепочки просрочен;
262144 – электронная подпись целостная, но список отзывов сертификатов (CTL), использованный для создания этой цепочки, не имеет действительной подписи;
524288 – электронная подпись целостная, но список отзывов сертификатов (CTL), использованный для создания этой цепочки, не имеет правильного предназначения.
2021
Описание кодов ошибок при
обработке xml-документов
Версия 4.41
Оглавление
История изменений ............................................................................................................................................................................................................................ 3
1 Введение ..................................................................................................................................................................................................................................... 4
2 Работа с квитанцией.................................................................................................................................................................................................................... 4
3 Ошибки, возникающие на этапе приема документов ............................................................................................................................................................... 7
3.1 Общие ошибки при работе с идентификаторами............................................................................................................................................................. 8
3.2 Ошибки в структуре отправленного документа................................................................................................................................................................ 9
3.3 Ошибки в описании элементов xsd-схем. Несоответствие форматов ............................................................................................................................ 13
3.4 Ошибки в формате отправленного документа ............................................................................................................................................................... 16
3.5 Технические ошибки........................................................................................................................................................................................................ 18
4 Ошибки трассировки (Ошибки реализации бизнес-процессов) .............................................................................................................................................. 19
4.1 Ошибки на уровне документа ......................................................................................................................................................................................... 19
4.2 Ошибки на уровне КИЗ .................................................................................................................................................................................................... 31
2
История изменений
Дата Версия Описаний изменений
изменений
21.09.2021 4.41 Добавлена ошибка на уровне документа: 3010;
В разделы «Ошибки на уровне документа» и «Ошибки на уровне КИЗ» добавлена информация по ошибкам в
случае, если при формировании квитанции не удалось определить код ошибки.
16.08.2021 4.40 Обновлены рекомендации для ошибок уровня документа: 100, 3001, 3002,3012.
Обновлены рекомендации для ошибок уровня КИЗ: 20, 28, 100, 3012.
Убраны ошибки на уровне документа: 33. Данная ошибка не используется.
Убраны ошибки на уровне КИЗ: 3001, 3002, 3003, 3005, 3008, 3009, 3011, 3101, 3102. Данные ошибки
возвращаются на уровне документа.
В пункт «Ошибки в формате отправленного документа» добавлена информация по возникновению ошибки при
первичной обработке документа. В случае попытки загрузки документа объемом более 15 Мб документ будет
загружен в систему, но в ответной квитанции будет возвращаться 1000 код ошибки: «Превышен размер
загружаемого файла».
28.06.2021 4.39 Детализирован текст ошибки: 54, 19 и 3012.
Обновлены рекомендации для ошибок уровня документа: 4, 3012.
Добавлены рекомендации для ошибок уровня КИЗ: 19, 28, 54, 3012.
01.04.2021 4.38.2 Детализирован текст 52 ошибки.
Обновлены рекомендации по 52 ошибке.
26.02.2021 4.38 Добавлен раздел «Работы с квитанцией».
Добавлены рекомендации для ошибок уровня документа: 200, 3012.
Добавлены рекомендации для ошибок уровня КИЗ: 11, 19, 22, 33, 34, 38, 52, 100, 3012.
3
1 Введение
В данном документе представлена информация по кодам ошибок, которые могут возникать при обработке xml – документов, которые
поступают в федеральную государственную информационную систему мониторинга и движения лекарственных препаратов (ФГИС МДЛП).
На данный момент в системе есть два уровня проверок и фиксации ошибок:
Ошибки, которые возникают в момент приема документов;
Ошибки трассировки (Ошибки реализации бизнес-процессов):
o Ошибки на уровне документа;
o Ошибка на уровне КИЗ.
2 Работа с квитанцией
Чтобы понять, что документ обработан и квитанция сформирована, необходимо ориентироваться на статус обработки документа. Статус
обработки имеет несколько значений:
«PROCCESSING» - обозначает, что документ находится в процессе обработки. На этом этапе квитанция не формируется;
«ACCEPTED» - документ успешно обработался (без ошибок), ответная квитанция сформирована. Пример успешной квитанции
приведен на рисунке 1.
Рисунок 1 – Успешная квитанция. Статус «Accepted».
«PARTIAL» - документ обработался частично, т.е. часть КИЗ указанных в документе обработались успешно, а часть с бизнес-
ошибкой. В ответной квитанции фиксируется:
o «error_code» - код ошибки;
4
o «error_desc» - описание ошибки;
o «object_id» - КИЗ, у которого произошла ошибка.
Пример квитанции приведен на рисунке 2 (а).
Рисунок 2 – Квитанция с ошибкой на уровне КИЗ. а) Статус «Partial» б) Статус «Rejected»
«REJECTED» - обозначает, что документ обработался с бизнес-ошибкой.
В случае, если произошла ошибка на уровне КИЗ, то в ответной квитанции фиксируется:
o «error_code» - код ошибки;
o «error_desc» - описание ошибки;
o «object_id» - КИЗ, у которого произошла ошибка.
Пример квитанции приведен на рисунке 2 (б).
В случае, если произошла ошибка на уровне документа, то в ответной квитанции фиксируется:
o «error_code» - код ошибки;
5
o «error_desc» - описание ошибки.
Пример квитанции приведен на рисунке 3.
Рисунок 3 – Квитанция с ошибкой на уровне документа. Статус «Rejected»
Подробнее с ошибками можно ознакомиться в разделе «Ошибки трассировки (Ошибки реализации бизнес-процессов)».
«TECH_ERROR» - документ обработался с ошибкой форматно-логического контроля (ошибки при приеме документа). В ответной
квитанции фиксируется код и описание ошибки. Пример квитанции приведен на рисунке 4.
Рисунок 4 – Квитанция с ошибкой на уровне приема документа. Статус «Rejected»
Подробнее с ошибками можно ознакомиться в разделе «Ошибки, возникающие на этапе приема документов».
Если обработка документа завершилась статусом «PARTIAL», «REJECTED» или «TECH_ERROR», необходимо скачать квитанцию и
проанализировать ошибки. При необходимости сформировать корректный документ и отправить его повторно.
6
3 Ошибки, возникающие на этапе приема документов
Код Текст в квитанции для Причина возникновения
ошибки пользователя
1. «1000»; «Обработка запроса Данные ошибки не относятся к ошибкам трассировки SGTIN (ошибкам реализации
2. «1001»; провалилась: {причина}» бизнес-процессов), т.к. документ блокируется на этапе подачи в систему. Такие
3. «1003»; ошибки могут возникать:
4. «1004»;
5. «1005»; 1. При некорректном указании идентификатора в передаваемом xml-документе;
6. «1006»; 2. При некорректном указании структуры и последовательности расположения
7. «1007»; элементов в передаваемом xml-документе;
8. «1008»; 3. При несоответствии форматов элементов в передаваемом xml-документе;
9. «1009»; 4. При некорректном указании формата самого xml-документа;
10. «1010»; 5. При технических неполадках работы системы;
11. «1011». 6. При загрузке документа объемом более 15 Мб.
В случае возникновения данных ошибок в квитанции будет отображаться код
ошибки и описание.
7
3.1 Общие ошибки при работе с идентификаторами
К данным ошибкам относятся ошибки работы с идентификаторами в системе (возможные коды ошибок указаны в разделе «Ошибки,
возникающие на этапе приема документов»).
Текст в квитанции для пользователя Описание возможной Рекомендации и примечания
причины возникновения
Обработка запроса провалилась: ошибка В загруженном документе Для обработки документа требуется добавить в загружаемый
на этапе первичной обработки документа. указана версия схемы, xml документ актуальную версию схемы – параметр version и,
Указанная версия схемы не которая не поддерживается. при необходимости, также привести структуру документа к
поддерживается. актуальной версии.
Обработка запроса провалилась: ошибка В загруженном документе С актуальными версиями схем можно ознакомиться в
на этапе первичной обработки документа. не указана версия схемы. документах «Описание XSD», «Примеры XML c result», которые
В загруженном документе не указана опубликованы на официальном сайте честныйзнак.рф в
версия. разделе «Документы по работе в МДЛП – Комплекты схем».
Обработка запроса провалилась: ошибка Указанный в документе Для обработки документа требуется указать идентификатор
на этапе первичной обработки документа. идентификатор участника не участника, который соответствует отправителю.
Указанный идентификатор организации соответствует тому Для уточнения корректности фиксации субъектов операции
(subject_id) в документе не соответствует участнику, который рекомендуется воспользоваться документом «Описание XSD»,
отправителю. авторизован и загружает которые опубликованы на официальном сайте честныйзнак.рф
документ. в разделе «Документы по работе в МДЛП – Комплекты схем».
Обработка запроса провалилась: ошибка В документе не заполнен Для обработки документа требуется указать идентификатор
на этапе первичной обработки документа. параметр с участника, который соответствует отправителю.
В загруженном документе не указан идентификатором С актуальными версиями схем можно ознакомиться в
идентификатор отправителя. отправителя – subject_id. документах «Описание XSD», «Примеры XML c result», которые
опубликованы на официальном сайте честныйзнак.рф в
разделе «Документы по работе в МДЛП – Комплекты схем».
8
Обработка запроса провалилась: ошибка Указанный тип документа Для обработки документа требуется указать корректный тип
на этапе первичной обработки документа. (action_id) не используется в документа.
Некорректный тип документа (action_id). системе. С перечнем схем можно ознакомиться в документе «Схемы и
ограничения» или в документе «Описание XSD», которые
опубликованы на официальном сайте честныйзнак.рф в
разделе «Документы по работе в МДЛП – Комплекты схем».
Обработка запроса провалилась: ошибка Указанный тип документа С ограничениями на отправку схем можно ознакомиться в
на этапе первичной обработки документа. автоматически формируется документе «Схемы и ограничения», который опубликован на
Указанный тип документа запрещен к через устройство официальном сайте честныйзнак.рф в разделе «Документы по
отправке через ЛК Участника и API регистрации эмиссии или работе в МДЛП – Комплекты схем».
выбытия и не доступен для
отправки через ЛК
Участника и API.
Обработка запроса провалилась: ошибка По указанному Для обработки документа требуется указать корректный
на этапе первичной обработки документа. идентификатору не найден идентификатор участника.
Некорректный идентификатор зарегистрированный Рекомендуется проверить указанное значение subject_id по
организации (subject_id) участник, место данным своего личного кабинета – по идентификатору
деятельности (МД) или участника, который был присвоен организации при регистрации,
место ответственного и зарегистрированным МД и МОХ.
хранения (МОХ).
3.2 Ошибки в структуре отправленного документа
Данные ошибки относятся к структуре и последовательности расположения элементов в передаваемых xml-документов. Для
минимизации таких ошибок рекомендуется проверка составляемых документов по образцам и рекомендациям, публикуемым на сайте
«Честный знак».
В таких ошибках, помимо общего описания, присутствует детализация с указанием параметра, после которого была зафиксирована
ошибка в структуре или последовательности элементов (возможные коды ошибок указаны в разделе «Ошибки, возникающие на этапе приема
документов»).
9
Текст в квитанции для пользователя Описание возможной Рекомендации и примечания
причины возникновения
Обработка запроса провалилась: Ошибка в структуре На основании полученного текста ошибки рекомендуется
ошибка на этапе первичной обработки документа. В блоке проверить, какой именно элемент не обнаружен при проверке
документа. Некорректный документ. «query_kiz_info» ожидается ожидаемой структуры. Такой элемент указывается как
Cvc-complex-type.2.4.b: The content of одно из трех значений: sgtin,
ожидаемый между апострофами – One of 'ожидаемый элемент'
element ‘query_kiz_info’ is not complete. sscc_down, sscc_up. is expected.
One of ‘{sgtin, sscc_down, sscc_up}’ is Перед отправкой документа рекомендуется проверить его по
expected. актуальному описанию схем, форматов: «Описание XSD»,
Обработка запроса провалилась: Ошибка в структуре «Схемы и форматы для разработчиков учетных систем»,
ошибка на этапе первичной обработки документа. В блоке «detail» «Примеры XML c result», которые опубликованы на
документа. Некорректный документ. ожидается элемент union. официальном сайте честныйзнак.рф в разделе «Документы по
Cvc-complex-type.2.4.a: Invalid content работе в МДЛП – Комплекты схем».
was found starting with element ‘detail’.
One of '{union}' is expected.
Обработка запроса провалилась: Ошибка в структуре На основании полученного текста ошибки рекомендуется
ошибка на этапе первичной обработки документа. Обнаружено проверить, какой именно элемент был задублирован. Такой
документа. Некорректный документ. дублирование параметров. элемент фиксируется в квадратных скобках как – Duplicate
Cvc-identity-constraint.4.1: Duplicate Дубликаты SSCC в элементе unique value [указанное значение] с указанием в каком именно
unique value [006426210930569690] «by_sscc». элементе - «by_sscc». В данном случае рекомендуется
declared for identity constraint Такая ошибка может проверить значения в by_sscc/detail/sscc или
“ux_multi_pack_sscc_by_sscc” of element возникать для операции 915. by_sscc/detail/content/sscc.
“by_sscc”.
10
Обработка запроса провалилась: Ошибка в структуре На основании полученного текста ошибки рекомендуется
ошибка на этапе первичной обработки документа. Ожидается проверить, какой именно элемент не обнаружен при проверке
документа. Некорректный документ. параметр 'is_recursive' после ожидаемой структуры. Такой элемент указывается как
Cvc-complex-type.2.4.a: Invalid content параметра 'sscc'. ожидаемый между апострофами – One of 'ожидаемый элемент'
was found starting with element ‘sscc’. One Данный элемент или is expected.
of '{is_recursive}' is expected. отсутствует в документе, или Перед отправкой документа рекомендуется проверить его по
находится на другой актуальному описанию схем, форматов: «Описание XSD»,
позиции. «Схемы и форматы для разработчиков учетных систем»,
Такая ошибка может «Примеры XML c result», которые опубликованы на
возникать для операции 912. официальном сайте честныйзнак.рф в разделе «Документы по
работе в МДЛП – Комплекты схем».
Обработка запроса провалилась: Ошибка в структуре Данная ошибка возникает при некорректном указании
ошибка на этапе первичной обработки документа. Для параметра вложенных элементов. В приложенном описании ошибки
документа. Некорректный документ. 'union' не доступны указано, в каком месте схемы указаны некорректные данные –
Cvc-complex-type.2.4.d: Invalid content дочерние элементы. Invalid content was found starting with element 'параметр, после
was found starting with element ‘union’. No которого указаны некорректные данные'.
child element is expected at this point. Перед отправкой документа рекомендуется проверить его по
актуальному описанию схем, форматов: «Описание XSD»,
«Схемы и форматы для разработчиков учетных систем»,
«Примеры XML c result», которые опубликованы на
официальном сайте честныйзнак.рф в разделе «Документы по
работе в МДЛП – Комплекты схем».
11
Обработка запроса провалилась: Ошибка в структуре На основании полученного текста ошибки рекомендуется
ошибка на этапе первичной обработки документа. В документе проверять, какой именно элемент не обнаружен при проверке
документа. Некорректный документ. после параметра cost ожидаемой структуры. Такой элемент указывается как
Cvc-complex-type.2.4.a: Invalid content ожидается параметр gtin. ожидаемый между апострофами – One of 'ожидаемый элемент'
was found starting with element ‘cost’. One Данный элемент или is expected.
of '{gtin}' is expected. отсутствует в документе, или Перед отправкой документа рекомендуется проверить его по
находится на другой актуальному описанию схем, форматов: «Описание XSD»,
позиции. «Схемы и форматы для разработчиков учетных систем»,
«Примеры XML c result», которые опубликованы на
официальном сайте честныйзнак.рф в разделе «Документы по
работе в МДЛП – Комплекты схем».
Обработка запроса провалилась: Ошибка в структуре На основании полученного текста ошибки рекомендуется
ошибка на этапе первичной обработки документа. В документе проверять, какой именно элемент не обнаружен при проверке
документа. Некорректный документ. после параметра ожидаемой структуры. Такой элемент указывается как
Cvc-complex-type.2.4.a: Invalid content 'operation_date' ожидается ожидаемый между апострофами – One of 'ожидаемый элемент'
was found starting with element параметр receiver_id. is expected.
‘operation_date’. One of '{receiver_id}' is Данный элемент или Перед отправкой документа рекомендуется проверить его по
expected. отсутствует в документе, или актуальному описанию схем, форматов: «Описание XSD»,
находится на другой «Схемы и форматы для разработчиков учетных систем»,
позиции. Такая ошибка «Примеры XML c result», которые опубликованы на
может быть для схемы 251. официальном сайте честныйзнак.рф в разделе «Документы по
работе в МДЛП – Комплекты схем».
Обработка запроса провалилась: В документе превышено С ограничениями на отправку схем можно ознакомиться в
ошибка на этапе обработки документа ограничение на количество документах «Схемы и ограничения» и «Описание XSD»,
системой. Invalid request data: SGTIN (не более 1500) в которые опубликованы на официальном сайте честныйзнак.рф
data.kizs[0].metadata.kizs should NOT have одной упаковке SSCC. в разделе «Документы по работе в МДЛП – Комплекты схем».
more than 1500 items
Обработка запроса провалилась: В документе превышен С ограничениями на отправку схем можно ознакомиться в
ошибка на этапе обработки документа лимит по одновременной документах «Схемы и ограничения» и «Описание XSD»,
системой. Invalid request data: data.kizs передаче SSCC (не более которые опубликованы на официальном сайте честныйзнак.рф
should NOT have more than 20000 items 20000). в разделе «Документы по работе в МДЛП – Комплекты схем».
12
3.3 Ошибки в описании элементов xsd-схем. Несоответствие форматов
Данные ошибки относятся к несоответствию форматов элементов в передаваемых xml-документах. Для каждого элемента в
документации xsd-cхем присутствует описание шаблона. В случае несоответствия передаваемого значения описанному шаблону, возникают
ошибки (возможные коды ошибок указаны в разделе «Ошибки, возникающие на этапе приема документов»).
Для минимизации таких ошибок рекомендуется проверка значений параметров по шаблонам, описанным в документации xsd-схем,
публикуемых на сайте «Честный знак», в частности документ base_types.xsd (из комплекта схем) и «Описание XSD».
Текст в квитанции для пользователя Описание возможной Рекомендации и примечания
причины возникновения
Обработка запроса провалилась: ошибка В загруженном документе в На основании полученного текста ошибки рекомендуется
на этапе первичной обработки документа. одном из параметровпроверить, какому именно типу элемента (for type 'тип элемента')
Некорректный документ. Cvc-pattern- передана пустая строка вместо соответствует некорректно переданное значение (оно
valid: Value ‘’ is not facet-valid with respect данных, которые быуказывается между апострофами (Value 'переданное значение') и
to pattern ‘[0-9]{18}’ for type ‘sscc_type’. соответствовали форматусравнивать его с требуемым форматом шаблона. Формат можно
'sscc_type'. проверить по документации или по тексту полученной ошибки,
Обработка запроса провалилась: ошибка В загруженном документе в он также фиксируется между апострофами как pattern 'пример
на этапе первичной обработки одном из параметровшаблона'.
документа. Некорректный документ. Cvc- передана пустая строка вместо С актуальным описанием схем, форматов и примерами xml-
pattern-valid: Value ‘’ is not facet-valid with данных, которые быдокументов рекомендуется ознакомиться в документах
respect to pattern ‘S.*’ for type Соответствовали формату«Описание XSD», «Схемы и форматы для разработчиков учетных
‘string1000_type’. 'string1000_type'. систем» «Примеры XML c result», которые опубликованы на
официальном сайте честныйзнак.рф в разделе «Документы по
Обработка запроса провалилась: ошибка В загруженном документе в работе в МДЛП – Комплекты схем».
на этапе первичной обработки одном из параметров
документа. Некорректный документ. Cvc- передана пустая строка вместо
datatype-valid.1.2.1: ‘’ is not a valid value for данных, которые бы
‘integer’. соответствовали формату
'integer'.
Обработка запроса провалилась: ошибка В загруженном документе в
на этапе первичной обработки одном из параметров
документа. Некорректный документ. Cvc- передано значение 'Брак ', что
13
pattern-valid: Value ‘Брак ‘ is not facet- не соответствует формату
valid with respect to pattern ‘.*S’ for type элемента 'string1000_type'.
‘string1000_type’. В данном случае формату не
соответствует наличие
пробела.
Обработка запроса провалилась: ошибка В загруженном документе в
на этапе первичной обработки одном из параметров
документа. Некорректный документ. Cvc- передана пустая строка вместо
pattern-valid: Value ‘’ is not facet-valid with данных, которые бы
respect to pattern ‘[0-9]{14}|([a-fA-F0-9]{8}- соответствовали формату
[a-fA- F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}- 'subject_any_type'.
[a-fA-F0-9]{12})’ for type
‘subject_any_type’.
Обработка запроса провалилась: ошибка В загруженном документе в
на этапе первичной обработки одном из параметров
документа. Некорректный документ. Cvc- передана пустая строка вместо
pattern-valid: Value ‘’ is not facet-valid with данных, которые бы
respect to pattern ‘[0-9]{14}[!-“%-/0-9A- соответствовали формату
Z_a-z]{13}’ for type ‘sign_sgtin_type’. 'sign_sgtin_type'.
Обработка запроса провалилась: ошибка В загруженном документе в
на этапе первичной обработки документа. одном из параметров
Некорректный документ. Cvc-pattern-valid: передана пустая строка вместо
Value '2020-02-03 12:17:50Z' is not facet- данных, которые бы
valid with respect to pattern '((000[1- соответствовали формату
9])|(00[1-9][0-9])|(0[1-9][0-9]{2})|([1-9][0- 'datetimeoffset'.
9]{3}))-((0[1-9])|(1[012]))-((0[1-9])|([12][0-
9])|(3[01]))T(([01][0-9])|(2[0-3]))(:[0-5][0-
9]){2}(.[0-9]+)?(([+-]((((0[0-9])|(1[0-3]))(:[0-
5][0-9]))|14:00))|Z)' for type
'datetimeoffset'.
14
Обработка запроса провалилась: ошибка В загруженном документе в
на этапе первичной обработки документа. одном из параметров
Некорректный документ. Cvc-pattern-valid: передано значение '
Value ‘ 00000000099998’ is not facet-valid 00000000099998', что не
with respect to pattern ‘[0-9]{14}’ for type соответствует формату
‘subject_id_type’. элемента 'subject_id_type'.
В данном случае формату не
соответствует наличие
пробела.
15
3.4 Ошибки в формате отправленного документа
Данные ошибки относятся к некорректному формату xml-документа (возможные коды ошибок указаны в разделе «Ошибки,
возникающие на этапе приема документов»).
Текст в квитанции для пользователя Описание возможной Рекомендации и примечания
причины возникновения
Обработка запроса провалилась: ошибка Некорректный формат Рекомендуется проверить отправляемый документ на
на этапе первичной обработки документа. документа. Возможные соответствие спецификации формата xml и документом
Некорректный документ. An invalid XML причины – формат «Примеры XML c result», которые опубликованы на
character (Unicode: 0x0) was found in the документа не xml, официальном сайте честныйзнак.рф в разделе «Документы по
element content of the document. присутствуют символы, не работе в МДЛП – Комплекты схем».
Обработка запроса провалилась: ошибка соответствующие формату
на этапе первичной обработки документа. xml, структура не
Некорректный документ. An invalid XML соответствует формату
character (Unicode: 0x4) was found in the xml.
element content of the document.
Обработка запроса провалилась: ошибка
на этапе первичной обработки документа.
Некорректный документ. The content of
elements must consist of well-formed
character data or markup.
Обработка запроса провалилась: ошибка
на этапе первичной обработки документа.
Некорректный документ. Invalid byte 1 of
1-byte UTF-8 sequence.
Превышен размер загружаемого файла В систему загружен Рекомендуется проверить отправляемый документ на
документ объемом более допустимый размер в соответствии с документом «Описание
15 Мб. API Государственной информационной системы мониторинга
движения лекарственных препаратов», который опубликован
на официальном сайте честныйзнак.рф в разделе «Документы
16
по работе в МДЛП – Разработчикам – Внешнее
взаимодействие с МДЛП».
17
3.5 Технические ошибки
Данные ошибки могут возникнуть при техническая неполадках работы системы (возможные коды ошибок указаны в разделе «Ошибки,
возникающие на этапе приема документов»).
Текст в квитанции для пользователя Описание возможной Рекомендации и примечания
причины возникновения
Обработка запроса провалилась: Данные ошибки возникают При возникновении данных ошибок необходимо обратиться в
ошибка на этапе первичной обработки при технических неполадках. Службу технической поддержки или повторить попытку позже.
документа. Неизвестная ошибка.
Обработка запроса провалилась:
ошибка на этапе подготовки ответа.
Обработка запроса провалилась:
внутренняя системная ошибка.
18
4 Ошибки трассировки (Ошибки реализации бизнес-процессов)
Ошибки делятся на два уровня:
1. Ошибки на уровне документа;
2. Ошибка на уровне КИЗ.
Для минимизации ошибок трассировки рекомендуется ознакомиться с документами, которые опубликованы на официальном сайте
честныйзнак.рф в разделе «Документы по работе с МДЛП – Разработчикам – Комплекты схем»:
1. «Паспорта бизнес-процессов»;
2. «Описание XSD»;
3. «Примеры XML c result».
4.1 Ошибки на уровне документа
Код Текст в квитанции для пользователя Причина возникновения и рекомендации
1 Указанная сущность зарегистрирована Попытка зарегистрировать сущность повторно.
ранее
2 Указанная сущность не может быть Невозможно идентифицировать полученные данные и соотнести их с какими-либо
идентифицирована (не атрибутами в системе.
зарегистрирована)
3 Некорректная операция (ошибка Данная ошибка возникает при попытке фиксации операции 250. Причина – неверно
отмены операции) указаны данные в операции.
4 Некорректная операция (операция не Ошибка может возникнуть в случае, если:
может быть выполнена для указанных КМ, указанный в документе, отсутствует в системе МДЛП (операция 10300 не
реквизитов) загружена или ее обработка не завершена);
МД, от которого подается операция, не зарегистрировано в системе МДЛП;
GTIN, указанный в документе, не зарегистрирован в системе МДЛП;
Идентификатор собственника (owner_id), указанный в документе, при контрактном
производстве (order_type 2) не зарегистрирован в системе МДЛП.
19
Рекомендуется проверить данные в системе и переотправить документ.
Проверить, что предыдущий документ обработан успешно можно:
через ЛК Участника в реестре отправленных документов с помощью параметров
фильтрации;
через API с помощью методов:
o «Получения списка исходящих документов» – POST /documents/outcome;
o «Получение списка исходящих документов из витрины документов» – POST
/documents/showcase/outcome.
Получить информацию по местам деятельности можно:
через ЛК Участника в разделе «Профиль – Адреса – Места деятельности»;
через API с помощью методов:
o «Метод для поиска информации о местах осуществления деятельности по
фильтру» – POST /reestr/branches/filter;
o «Получение информации о конкретном месте осуществления деятельности»
– GET /reestr/branches/{branch_id}.
Получить информацию по GTIN можно:
через ЛК Участника в реестре описаний с помощью параметров фильтрации;
через API с помощью методов:
o «Метод для получения информации из реестра производимых организацией
ЛП» – POST /reestr/med_products/current;
o «Метод для получения детальной информации о производимом
организацией ЛП» – GET /reestr/med_products/{gtin}.
Посмотреть информацию о контрагенте можно:
через ЛК Участника в реестре доверенных контрагентов с помощью параметров
фильтрации;
через API с помощью метода «Метод фильтрации доверенных контрагентов» – POST
/reestr/trusted_partners/filter.
20
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном
сайте честныйзнак.рф в разделе «Документы по работе в МДЛП – Разработчикам –
Внешнее взаимодействие с МДЛП».
6 Операция не может быть выполнена. Неверно указаны параметры в операции. Проверьте корректность данных.
Указаны некорректные параметры
запроса.
8 Ошибка. Отсутствует необходимая Отсутствует необходимая лицензия, для осуществления операции, при регистрации
лицензия для осуществления операции операций: 311/313/511/521/531.
9 Операция не может быть выполнена. Данная ошибка вызвана из-за недоступности одного из компонентов системы во время
Возникла техническая ошибка при обработки документа.
обработке. При необходимости Рекомендуется проверить, произошла ли смена статуса КИЗ и при необходимости
отправьте документ повторно. отправить документ повторно.
Проверить данные по КИЗ можно:
через ЛК Участника в реестре товаров по SGTIN;
через API с помощью методов:
o «Метод для поиска по реестру КИЗ» - POST /reestr/sgtin/filter;
o «Метод поиска по реестру КИЗ по списку значений» - POST
/reestr/sgtin/sgtins-by-list.
с помощью операции «Запрос информации по номеру SGTIN/SSCC (210-
query_kiz_info.xsd)».
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном
сайте честныйзнак.рф в разделе «Документы по работе в МДЛП – Разработчикам –
Внешнее взаимодействие с МДЛП».
100 Частичное завершение Возникает, когда документ обработался частично. Более детальная ошибка фиксируется
на уровне КИЗ.
Описание ошибок см. в пункте 4.2. Ошибки на уровне КИЗ.
200 Идентичный документ был отправлен Ошибка может возникнуть при попытке загрузки дублирующего документа.
ранее. Рекомендуется:
проанализировать, почему документ был отправлен повторно;
проверить статус обработки отправленного ранее идентичного документа.
21
Если необходимо отправить документ повторно, то указать корректную дату операции
(текущие дата и время) в атрибуте «operation_date».
Получить информацию по документам можно:
через ЛК участника в реестре исходящих документов с помощью параметров
фильтрации;
через API с помощью методов:
o «Получение списка исходящих документов» – POST /documents/outcome;
o «Получение списка исходящих документов из витрины документов» –
POST /documents/showcase/outcome;
o «Получение метаданных документа» – GET /documents/{docId}.
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном
сайте честныйзнак.рф в разделе «Документы по работе в МДЛП – Разработчикам –
Внешнее взаимодействие с МДЛП».
201 Отсутствуют атрибуты для Ошибка в указании атрибутов для корректировки. Проверьте корректность данных.
корректировки
300 Указанный лекарственный препарат не Указанный ЛП не найден в реестре зарегистрированных ЛП.
найден в Реестре ЛП.
301 Данные отправителя и получателя не Данная ошибка возникает при попытке перевести КИЗ между своими адресами, в то
проходят проверку принадлежности время, когда ожидается перевод между адресами разных участников.
участнику. Для перемещения между своими адресами оба адреса должны принадлежать одному
участнику.
В остальных случаях данные должны принадлежать разным участникам.
302 Указанный адрес недействителен. Указанный в операции адрес не может быть идентифицирован в ФИАС.
303 Проведение указанной операции Попытка совершения операции, не применимой для МОХ. В системе запрещена
недоступно с места ответственного реализация с МОХ.
хранения.
304 Данные отправителя и получателя не Возникает при попытке перевести КИЗ между адресами разных участников, в то время,
принадлежат одному участнику. когда ожидается перевод между своими адресами.
22
400 Превышено максимальное количество Возникает при попытке приостановить КИЗ в количестве, превышающем установленный
КИЗ для приостановки обращения. предел.
2000 Данная операция недоступна для Попытка совершения операции доступной только для резидентов РФ.
иностранных участников
2001 Указанный участник неактивен Попытка выполнить операцию от имени заблокированного МД.
2002 Указанный участник не является Неверно указан идентификатор контрагента – указан идентификатор
иностранным контрагентом зарегистрированного в качестве участника субъекта обращения.
2010 Указанный продавец не Неверно указан идентификатор отправителя (seller_id) в операции: 362/332.
зарегистрирован в системе
2011 Указанный продавец отсутствует в Идентификатор продавца (seller_id) в операциях 331/332/361/362 не зарегистрирован в
списке иностранных контрагентов списке иностранных контрагентов.
2012 Страна регистрации продавца Ошибка может возникать при попытке фиксации следующих операций: 361/362/363.
отсутствует в списке государств-членов Причина ошибки: Идентификатор продавца (seller_id) отсутствует в списке государств-
ЕАЭС членов ЕАЭС.
2013 Указанный продавец неактивен Субъект (seller_id) неактивен в системе.
2014 Операция не может быть выполнена. Добавьте контрагента в список доверенных контрагентов и повторите отправку.
Указанный контрагент отсутствует в
списке доверенных контрагентов
2020 Указанный системе получатель не Неверно указан идентификатор получателя (receiver_id).
зарегистрирован в системе
2021 Указанный покупатель не является Ошибка может возникать при фиксации следующих операций: 331/332.
резидентом РФ Получатель товара в операции приемки на склад в ЗТК должен являться резидент РФ.
2022 Страна регистрации получателя Ошибка может возникать при попытке фиксации следующих операций: 361/362/363.
отсутствует в списке государств-членов Причина ошибки: Идентификатор получателя, указанный в поле
ЕАЭС receiver_id, отсутствует в списке государств-членов ЕАЭС.
23
2023 Указанный получатель неактивен Ошибка в указании идентификаторов участников. Проверьте корректность данных.
2030 Указанный получатель не Ошибка в указании идентификаторов участников. Проверьте корректность данных.
зарегистрирован в системе
2031 Указанный покупатель неактивен Ошибка в указании идентификаторов участников. Проверьте корректность данных.
2040 Указанный собственник не Ошибка в указании идентификаторов участников. Проверьте корректность данных.
зарегистрирован в системе
2041 Указанный собственник неактивен Ошибка в указании идентификаторов участников. Проверьте корректность данных.
2050 Указанный производитель, Ошибка в указании идентификаторов участников. Проверьте корректность данных.
осуществивший упаковку/фасовку во
вторичную (третичную) упаковку, не
зарегистрирован в системе
2060 Указанный производитель, Ошибка в указании идентификаторов участников. Проверьте корректность данных.
осуществляющий выпускающий
контроль качества, не зарегистрирован
в системе
2070 Указанное для возврата место Ошибка в указании идентификаторов участников. Проверьте корректность данных.
деятельности/место ответственного
хранения не зарегистрировано в
системе
2071 Указанное для возврата место Ошибка в указании идентификаторов участников. Проверьте корректность данных.
деятельности/место ответственного
хранения неактивно
2090 Указанный контрагент не Ошибка в указании идентификаторов участников. Проверьте корректность данных.
зарегистрирован в системе
2091 Указанный контрагент неактивен Ошибка в указании идентификаторов участников. Проверьте корректность данных.
24
2100 Указанный идентификатор места Ошибка в указании идентификаторов участников. Проверьте корректность данных.
приемки в зоне таможенного контроля
не зарегистрирован в системе
2110 Указанное место отгрузки в зоне Ошибка в указании идентификаторов участников. Проверьте корректность данных.
таможенного контроля не
зарегистрировано в системе
3001 Операция не может быть выполнена. Ошибка может возникнуть при агрегации.
Произошел системный сбой при Рекомендуется обратиться в Службу технической поддержки или повторить попытку
создании SSCC. отправки документа позже.
3002 Операция не может быть выполнена. Ошибка может возникнуть при агрегации.
Указанный SSCC уже существует в Нельзя зарегистрировать SSCC повторно.
системе.
3003 Операция не может быть выполнена. Операция агрегации должна осуществляться владелец брони SSCC.
Бронь SSCC принадлежит другому
участнику.
3005 Операция не может быть выполнена. Нельзя осуществить операции изъятия/докладки/уничтожения для SSCC, который не
Указанный SSCC не найден в системе зарегистрирован в системе или раннее был расформирован. Проверьте корректность
или расформирован. данных.
3006 Операция не может быть выполнена. Нельзя осуществить операции изъятия/докладки/уничтожения для вложенного SSCC.
Нельзя осуществить операцию для
SSCC, который является вложенным.
3008 Операция не может быть выполнена. Нельзя осуществить операции изъятия/докладки/уничтожения для содержимого SSCC,
Содержимое SSCC находится в которое находится в процессе оплаты.
процессе оплаты.
3009 Операция не может быть выполнена. При возникновении данной ошибки обратитесь в Службу технической поддержки.
По указанному SSCC нет информации о
предыдущих операциях.
3010 Операция не может быть выполнена. Ошибка может возникнуть, если операция агрегации выполняется одновременно для
Нельзя осуществить операцию просроченных и не просроченных КИЗ.
агрегации одновременно для Рекомендуется:
просроченных и не просроченных проверить срок годности у указанных SGTIN;
25
SGTIN. провести доступную операцию для SGTIN с истекшим сроком годности.
Доступные операции:
перемещение между местами деятельности (документ 431);
трансформация (агрегация, докладка). При выполнении данных операций
недопустимо указание просроченных и непросроченных лекарственных
препаратов для SSCC;
возврата (документы 415/416 с типом «Возврат», 472 с типом «Возврат», 471 и
473 с типом «Возврат»);
передача на уничтожение и уничтожение (документы 541 и 542);
оприходование (документ 702);
отмена ранее поданных сведений (документы 251 и 252);
вывод лекарственного препарата из оборота (документ 552 с типом 11-
«недосдача», 13 - «списание без передачи на уничтожение», 16 - «списание
разукомплектованной потребительской упаковки»).
Все указанные операции, кроме агрегации и докладки, разрешены для SSCC, в составе
которого находятся КИЗ с истёкшим и не истёкшим сроком годности. Также данные
операции разрешены для перемещения как отдельных SGTIN с истёкшим сроком
годности, так и просроченных SGTIN, которые находятся в SSCC.
Получить информацию по сроку годности SGTIN можно:
через ЛК Участника:
o «Реестр SGTIN» с помощью параметров фильтрации по gtin и серии;
o «Реестр SGTIN, эмитированных до 28.03.2021» с помощью параметров
фильтрации по gtin и серии;
o «Реестр серий» с помощью параметров фильтрации по gtin и серии;
через API с помощью методов:
o «Создание задачи» - POST export/tasks/{task_type} с типом
«batches_registry» - «Выгрузка из реестра серий»;
o «Метод для поиска по реестрам КИЗ» - POST /reestr/sgtin/filter;
26
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном
сайте честныйзнак.рф в разделе «Документы по работе с МДЛП – Разработчикам –
Комплекты схем».
3011 Агрегация запрещена – попытка Нельзя осуществить операцию агрегации/докладки с разными GTIN. Проверьте
агрегации КИЗ с разными GTIN. корректность данных.
3012 Операция не может быть выполнена. Ошибка может возникнуть, если операции над SGTIN выполняются не последовательно.
Хронология событий нарушена, В данной операции неверно указан атрибут «operation_date». Данная ошибка
неверно указана дата операции возвращается при мультиагрегации и мультидокладке.
(last_operation_date="op_date"). Рекомендуется:
проверить предыдущую зарегистрированную операцию по КИЗ;
указать корректную дату операции (текущие дата и время) в атрибуте
«operation_date», и отправить документ повторно.
В целях недопущения подобной ошибки рекомендуется соблюдать хронологию
операций с КИЗ, учитывая, что каждая следующая операция должна быть по дате и
времени позже предыдущей.
Получить информацию по дате последней операции - "last_operation_date" можно
в ответной квитанции в описании "error_desc".
Для автоматизации поиска даты в квитанции можно использовать регулярное
выражение last_operation_date="(.+)".
Получить информацию по дате последней операции по SGTIN можно:
через ЛК Участника в реестре товаров по SGTIN с помощью параметров
фильтрации;
через API с помощью методов:
o «Метод для поиска по реестру КИЗ» - POST /reestr/sgtin/filter;
o «Метод поиска по реестру КИЗ по списку значений» - POST
/reestr/sgtin/sgtins-by-list;
o с помощью операции «Запрос информации по номеру SGTIN/SSCC (210-
query_kiz_info.xsd)».
Получить информацию по SSCC можно:
27
через ЛК Участника в реестре товаров по SGTIN (поиск по SSCC);
через API с помощью методов:
o «Метод для получения информации об иерархии вложенности третичной
упаковки» – GET /reestr/sscc/{sscc}/hierarchy;
o «Метод для получения информации о КИЗ, вложенных в третичную
упаковку» - POST /reestr/sscc/{sscc}/sgtins;
o «Создание задачи» - POST export/tasks/{task_type} с типом «sscc_hierarchy»
- «Выгрузка иерархии по SGTIN»;
с помощью операции «Запрос информации об иерархии вложенности SSCC (220-
query_hierarchy_info.xsd)».
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном
сайте честныйзнак.рф в разделе «Документы по работе в МДЛП – Разработчикам –
Внешнее взаимодействие с МДЛП».
3101 Операция не может быть выполнена. В Нельзя вложить один и тот же SGTIN/SSCC в разные упаковки.
документе содержатся
множественные вхождения одного и
того же SGTIN/SSCC.
3102 Операция не может быть выполнена. Операции агрегации и докладки осуществляются только для одинакового уровня
На одном уровне агрегации могут быть вложенности.
либо транспортные (SSCC), либо
потребительские (SGTIN) упаковки.
4001 При списании средств с лицевого счета Во время обработки документа возникла ошибка из-за недоступности одного из
произошла техническая ошибка компонентов, отвечающих за оплату кодов маркировки.
Рекомендуется повторно сформировать и отправить отчет о нанесении с указанными в
документе КИЗ.
4002 Для осуществления операции Ошибка возникает случае, если на лицевом счете Участника недостаточно средств для
недостаточно средств на лицевом оплаты кодов маркировки.
счете Рекомендуется пополнить лицевой счет, далее повторно сформировать и отправить
отчет о нанесении с указанными в документе КИЗ.
Для пополнения баланса лицевого счета необходимо осуществить оплату на расчетный
счет Оператора-ЦРПТ с указанием номера лицевого счета в назначении платежа.
28
Состояние баланса можно проверить в Личном кабинете Участника в разделе «Финансы
– Лицевые счета».
4003 Техническая ошибка. Номер лицевого Ошибка возникает в случае, если у Участника в системе не найден лицевой счет.
счета не найден Рекомендуется проверить наличие лицевого счета в Личном кабинете Участника в
разделе «Финансы – Лицевые счета».
В случае наличия лицевого счета необходимо проверить, что договор на предоставление
КМ успешно подписан. Статус договора можно посмотреть в разделе «Договорные
документы – Предоставление кодов маркировки».
В случае, если документ подписан, повторно сформировать и отправить отчет о
нанесении с указанными в документе КИЗ.
Если ошибка повторяется, обратиться в Службу технической поддержки.
4004 Ошибка подготовки документа для Ошибка возникает в случае технических неполадок при подготовке документов для
оплаты оплаты и снятия денежных средств.
При получении данной ошибки необходимо обратиться в Службу технической
поддержки.
4005 Ошибка подготовки документа для Ошибка возникает в случае технических неполадок при подготовке документов для
оплаты оплаты и снятия денежных средств.
При получении данной ошибки необходимо обратиться в Службу технической
поддержки.
4006 В отчете о нанесении переданы КиЗ с Ошибка возникает в случае, когда в отчете о нанесении для одного GTIN указаны КМ из
разными тарифами разных заказов СУЗ с разными тарифами (тариф для ЛП из перечня ЖНВЛП, стоимость
которых не превышает 20 рублей, и тариф ЛП, не попадающих в эту категорию, согласно
данным реестра ЕСКЛП).
Рекомендуется проверить корректность данных, сформировать отчет по КИЗ с
одинаковым тарифом и отправить отчет о нанесении повторно.
4010 В процессе оплаты возникла Ошибка возникает в случае технических неполадок в процессе оплаты и снятия
техническая ошибка денежных средств.
При получении данной ошибки необходимо обратиться в Службу технической
поддержки.
29
Неизвестная ошибка обработки Ошибка возникает в случае, если при формировании квитанции не удалось определить
документа. Обратитесь в Службу код ошибки. При получении данной ошибки необходимо обратиться в Службу
технической поддержки. технической поддержки.
30
4.2 Ошибки на уровне КИЗ
Код Текст в квитанции для пользователя Причина возникновения и рекомендации
10 КИЗ уже зарегистрирован Возвращается при попытке выпустить существующий КИЗ.
11 Операция не может быть выполнена. Ошибка может возникнуть, если обрабатываемая операция не соответствует текущим
Недопустимый переход в бизнес-процессам.
товаропроводящей цепочке. Рекомендуется проверить отправляемый документ и убедиться, что все КИЗ:
находятся в разрешенном для операции статусе;
имеют корректный источник финансирования, который разрешен для
выполняемой операции;
находятся на МД, которое указано в операции.
Получить информацию по SGTIN можно:
через ЛК Участника в реестре товаров по SGTIN с помощью параметров
фильтрации;
через API с помощью методов:
o «Метод для поиска по реестру КИЗ» - POST /reestr/sgtin/filter;
o «Метод поиска по реестру КИЗ по списку значений» -
POST/reestr/sgtin/sgtins-by-list;
с помощью операции «Запрос информации по номеру SGTIN/SSCC (210-
query_kiz_info.xsd)».
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном сайте
честныйзнак.рф в разделе «Документы по работе в МДЛП – Разработчикам – Внешнее
взаимодействие с МДЛП».
31
13 Ошибка акцепта или возврата Данная ошибка может возникать при фиксации следующих операций:
приостановленных КИЗ 701(акцептование)/251(отзыв)/252(отказ)/17(возврат приостановленного ЛП) Причины
возникновения ошибки.
В операциях 701/251/252 отсутствует элемент «confirm_paused» - подтверждение
приемки приостановленного товара.
Осуществление операции возврата, приостановленного ЛП (417 операция) в отношении
ЛП, для которого отсутствуют сведения о приостановлении.
14 SSCC содержит приостановленные Попытка осуществления операции отгрузки, c указанием групповой упаковки, внутри
КИЗ которой содержится приостановленный SGTIN.
15 Попытка изменить состояние При попытке зарегистрировать операцию движения SGTIN, который вложен в SSCC.
вложенного КИЗ.
16 Операция возврата невозможна. Попытка осуществить возврат товара, для которого отсутствуют сведения о приемке.
Отсутствует предыдущий владелец
КИЗ.
17 Операция возврата запрещена. Для текущего состояния КИЗ операция возврата запрещена.
18 Не заполнены данные по В операции 335 документы, подтверждающие соответствие, обязательны к заполнению
документам, подтверждающим пользователем при указании кода таможенной процедуры «выпуск для внутреннего
соответствие при выпуске для потребления». Причина: отсутствует элемент confnum_info.
внутреннего потребления
19 Операция не может быть выполнена. Ошибка может возникнуть, если операции над SGTIN выполняются не последовательно. В
Хронология событий нарушена, данной операции неверно указан атрибут «operation_date».
неверно указана дата операции Рекомендуется:
(last_operation_date="op_date"). проверить предыдущую зарегистрированную операцию по КИЗ;
указать корректную дату операции (текущие дата и время) в атрибуте
«operation_date», и отправить документ повторно.
В целях недопущения подобной ошибки рекомендуется соблюдать хронологию операций
с КИЗ, учитывая, что каждая следующая операция должна быть по дате и времени позже
предыдущей.
Получить информацию по дате последней операции - "last_operation_date" можно
в ответной квитанции в описании "error_desc". Для автоматизации поиска даты в
32
квитанции можно использовать регулярное выражение last_operation_date="(.+)".
Получить информацию по дате последней операции по SGTIN можно:
через ЛК Участника в реестре товаров по SGTIN с помощью параметров
фильтрации;
через API с помощью методов:
o «Метод для поиска по реестрам КИЗ» - POST /reestr/sgtin/filter;
o «Метод поиска по реестру КИЗ по списку значений» - POST
/reestr/sgtin/sgtins-by-list;
с помощью операции «Запрос информации по номеру SGTIN/SSCC (210-
query_kiz_info.xsd)».
Получить информацию по SSCC можно:
через ЛК Участника в реестре товаров по SGTIN (поиск по SSCC);
через API с помощью методов:
o «Метод для получения информации об иерархии вложенности третичной
упаковки» – GET /reestr/sscc/{sscc}/hierarchy;
o «Метод для получения информации о КИЗ, вложенных в третичную
упаковку» - POST /reestr/sscc/{sscc}/sgtins;
o «Создание задачи» - POST export/tasks/{task_type} с типом «sscc_hierarchy» -
«Выгрузка иерархии по SGTIN»;
с помощью операции «Запрос информации об иерархии вложенности SSCC (220-
query_hierarchy_info.xsd)».
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном сайте
честныйзнак.рф в разделе «Документы по работе в МДЛП – Разработчикам – Внешнее
взаимодействие с МДЛП».
20 Истек срок годности лекарственного Ошибка может возникнуть, если у SGTIN истек срок годности.
препарата. Рекомендуется:
проверить срок годности у указанных SGTIN;
провести доступную операцию для SGTIN с истекшим сроком годности.
33
Доступные операции:
перемещение между местами деятельности (документ 431);
трансформация (агрегация, докладка). При выполнении данных операций
недопустимо указание просроченных и непросроченных лекарственных
препаратов для SSCC;
возврата (документы 415/416 с типом «Возврат», 472 с типом «Возврат», 471 и 473
с типом «Возврат»);
передача на уничтожение и уничтожение (документы 541 и 542);
оприходование (документ 702);
отмена ранее поданных сведений (документы 251 и 252);
вывод лекарственного препарата из оборота (документ 552 с типом 11-
«недосдача», 13 - «списание без передачи на уничтожение», 16 - «списание
разукомплектованной потребительской упаковки»).
Все указанные операции, кроме агрегации и докладки, разрешены для SSCC, в составе
которого находятся КИЗ с истёкшим и не истёкшим сроком годности. Также данные
операции разрешены для перемещения как отдельных SGTIN с истёкшим сроком годности,
так и просроченных SGTIN, которые находятся в SSCC.
Получить информацию по сроку годности SGTIN можно:
через ЛК Участника:
o «Реестр SGTIN» с помощью параметров фильтрации по gtin и серии;
o «Реестр SGTIN, эмитированных до 28.03.2021» с помощью параметров
фильтрации по gtin и серии;
o «Реестр серий» с помощью параметров фильтрации по gtin и серии;
через API с помощью методов:
o «Создание задачи» - POST export/tasks/{task_type} с типом «batches_registry»
- «Выгрузка из реестра серий»;
o «Метод для поиска по реестрам КИЗ» - POST /reestr/sgtin/filter;
С актуальным описанием API можно ознакомиться в документе «ИС «Маркировка».
МДЛП. Протокол обмена интерфейсного уровня», опубликованном на официальном сайте
34