Мдлп ошибка 200 идентичный документ был отправлен ранее что делать

№ Текст ошибки Описание возможной причины Рекомендации и примечания 1

ORA-20103: Не задан мнемокод пользователя ИС Маркировка.

Не заполнен системный параметр №1816.

Файл – Сервис – Параметры
В окне отбора в поле Номер с-по – необходимо указать 1816.
Откроется окно Параметры: Идентификация
В поле Пользователь – ввести логин пользователя, под которым возникает ошибка.
В поле Организация – Министерство здравоохранения КК
Параметр:
Каталог – Документы операций с упаковками
Номер – 1 816
Код – MRKPackageOperationDocuments_MrkApiUser
Наименование – Пользователь ИС Маркировка
ПКМ – Исправить значение
Указывается значение из раздела: Учет – Пользователи ИС Маркировка
Проверяем, чем заполнен параметр и соответствует ли это сведениям из раздела Учет — Пользователи ИС Маркировка. 

2

Ошибка сервиса: «Для документа XML должен существовать документ более высокого уровня.

Line: 0

«.

Ошибка свидетельствует о том, что для данного IP-адреса компьютера не настроено подключение к серверу МИАЦ.

В Парусе Консультанте необходимо создать событие. 

В заявке предоставляется следующая информация:

1. Наименование организации
2. Ответственный сотрудник и телефон
3. Адреса VIPnet coordinator/Адрес Vipnet Clinet (через что подключен АРМ)
4. Адрес АРМ пользователя (IP-адрес компьютера)

Сведения оформляются в заявку и отправляются в Отдел информационной безопасности ГБУЗ «МИАЦ» для дальнейшей настройки.

3 В разделе «Документы операций с упаковками» при попытке Получить/Отправить документы ничего не происходит. Часто проблема связана с тем, что не предоставлена актуальная ЭЦП.

1. Необходимо проверить данные действия через «Журнал взаимодействия с ИС Маркировка». После выполнения операции необходимо обязательно нажимать кнопку ОБНОВИТЬ.
2. Для специалистов Отдела технической поддержки: Если после этого ничего не произошло, необходимо в разделе Учет — Пользователи ИС Маркировка на пользователе ПКМ — Исправить в поле Сертификат нажать на 3 точки и провалиться в раздел Электронные сертификаты, в каталоге слева выбрать каталог учреждения и проверить сертификат, который подвязан пользователю: Действителен с — Действителен по. Если сертификат закончился, дать пояснение клиенту.  -И сказать, чтобы зарегистрировали событие в Парус Консультанте и добавили новую ЭЦП в присоединенные документы.
3. Для клиента: Если после этого ничего не произошло, необходимо в разделе Учет — Пользователи ИС Маркировка на пользователе ПКМ — Исправить в поле Сертификат — сверить отпечаток ЭЦП с тем, что в Личном Кабинете Честного знака.
4. Если отпечаток в Личном Кабинете Честного знака не совпадает с тем, что в Парусе в разделе Учет — Пользователи ИС Маркировка, необходимо в Парус Консультанте прислать событие с текстом: Актуальная ЭЦП для маркировки. Актуальную ЭЦП прикрепить к событию.

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

Текст ошибки — Операция не может быть выполнена. Хронология событий нарушена, неверно указана дата операции.

1. Пользователь указал не верную дату документа в поле «Дата». Тем самым нарушив хронологию событий по дате.
2. Поставщик не указал в документе временную зону или указал +0:00, соответственно искажается время

1. Пример:
   Документы операций с упаковками
   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

Текст ошибки — Идентичный документ был отправлен ранее

Ошибка может возникнуть при попытке загрузки дублирующего документа.

1. Проанализировать, почему документ был отправлен повторно
2. Проверить статус обработки отправленного раннее идентичного документа

Если необходимо отправить документ повторно, то необходимо размножить документ, на закладке «Дополнительно» проверить заполнение полей «Документ-подтверждение»/»Документ — основание» и выполнить отправку в ИС Маркировка.

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 ДОУ, в котором присутствуют КИЗ упаковки из текста ошибки. Выбрать документ, ПКМ — Состояние — Отработан как факт. Если возникает ошибка  «Невозможна отработка операции расхода как факт для упаковки «**», оприходованной как план.», в таком случае ПКМ — Состояние — Отработан как план.

34

Документы операций с упаковками

Тип документа — 701

Статус отправлен
ПКМ-связи-Журнал взаимодействия с ИС Маркировка
в поле примечании Произошла ошибка при отправке запроса.

Ошибка возникает при наличии принятого документа в ЧЗ но с другим идентификатором операции ИС Маркировка

Необходимо найти отклоненный 701 документ в ЛК ЧЗ, рядом должен быть еще один 701 документ, который со статусом принят с небольшим разрывом по времени, скачать квитанцию документа и сравнить КИЗ.

В модуле Маркировка статус не обновить, поскольку отличается идентификатор. Со стороны пользователя никаких действий производить не нужно.

35

Документы операций с упаковками

Тип документа — 531

ПКМ — ИС Маркировка — сформировать отчет о выбытии

Не отправляются документы, статус не определен

Очередь создается на регистратор выбытия и удаляется, документ в ЛК ЧЗ не загружается. Необходимо обратить внимание на номер документа, максимально допустимая длина поля «номер документа»  16 символов. 36

Документы операций с упаковками

Тип документа — 531

ПКМ — ИС Маркировка — сформировать отчет о выбытии

ПКМ —  ИС Маркировка — Проверить статус

Статус — «Принят частично» 

Не все упаковки выгружены в МДЛП или часть упаковок отклонены.

Если упаковки не были отправлены, сформировать новый 531 документ и направить повторно недостающие упаковки.

Если упаковки выгружены все, данную информацию можно посмотреть в регистраторе выбытия, в ЛК ЧЗ должен быть документ 10532 — «Выдача для мед. помощи ЛП с невалидными КМ (регистратор выбытия)»

Документ 10532 автоматически передаётся для ЛП, код маркировки которых не прошёл верификацию.

В данном случае дальнейших действий не требуется — ЛП считается выведенным из оборота.

Обращаем внимание, что лекарственные препараты, КМ которых не прошли проверку, рекомендуется возвращать поставщику.

30 сентября на нашем сайте состоялся вебинар от оператора системы мониторинга движения лекарственных препаратов компании «ЦРПТ», на котором эксперт компании рассказал об общих подходах к решению нештатных ситуаций, возникающих при работе с ГИС МДЛП. К сожалению, из‑за ограниченного времени вебинара и большого количества участников, лектор не успел ответить на все заданные вопросы. Для тех, кто по каким‑либо причинам пропустил трансляцию, мы приводим ее краткий обзор и ответы на вопросы, заданные во время эфира.

Общие решения для нештатных ситуаций при работе с системой маркировки

По данным компании ЦРПТ, больше всего проблем у пользователей возникает в процессе выбытия лекарственных препаратов из оборота. Самый частый вопрос: «Если система недоступна, проводятся технические работ и т. д. — как быть?». Здесь стоит отметить основные моменты, что отпуск возможен двумя способами — продажа через ККТ (т. е. с оформлением чеков) и по регистраторам выбытия. Оба этих способа умеют «накапливать» в себе данные о выбытии и передавать их в систему при появлении соединения с ней.

В первом случае за передачу данных в систему отвечает оператор фискальных данных. Таким образом, при наличии каких‑либо задержек, вызванных теми или иными причинами, аптеки могут не переживать за ответственность, потому что агрегированная информация передается именно оператором.

При использовании регистратора выбытия, даже если ГИС МДЛП недоступна, можно просканировать препараты, и сформировать с помощью регистратора документы о выбытии лекарств из оборота. Они будут отправлены в «буфер», который будет передан в систему МДЛП, когда она станет доступна.

Кроме этого в системе ГИС МДЛП предусмотрен механизм «реестра ожидания», он работает в том случае, когда аптека собирается отпустить лекарственный препарат, однако информация о его приемке не поступила в систему из‑за регламентных работ. В этом случае ЛП можно отпускать, фискальный оператор передаст в систему данные о выбытии, а система, в свою очередь «увидит», что на этот ЛП нет информации, подтверждающей поставку на место деятельности, где был осуществлен отпуск. Тогда, для завершения цикла, информация о выбытии будет находиться в реестре ожидания до получения данных о приемке.

Таким образом, с помощью этого механизма можно отпускать лекарственные средства даже если на момент их приемки система МДЛП была недоступна. Максимальный период ожидания составляет две недели. В этот срок любые технические работы в системе МДЛП будут закончены. Обратите внимание, что механизм «реестра ожидания» работает только при обратном акцепте приемки ЛС.

Также в решении большинства проблемы могут помочь документы, доступные на сайте «Честный знак». В большинстве из них приведены примеры нештатных случаев, а также даны алгоритмы по правильной работе с системой, которые помогут самостоятельно найти и устранить причину возникших трудностей:

• Методические рекомендации по работе с маркированными лекарствами — инструкции по работе с системой;
• Паспорта процессов — описание всех действий при обращении лекарственных препаратов;
• Руководство пользователя ЛК субъекта обращения лекарственных препаратов — инструкция по заполнению информации в личном кабинете;
• Описание схем передачи данных (версия 1.35) — технические данные, необходимые для интеграции программного обеспечения. Эта информация может понадобиться при контакте с поставщиками программного обеспечения и общением со службой поддержки.

Кроме этого, на сайте есть раздел «Обучающий центр», где даны краткие, но подробные видео-инструкции по основным направлениям работы с системой ГИС МДЛП.

Еще одно средство разрешения нештатных ситуаций — обращение в службу поддержки по адресу [email protected].ru или телефону 8‑800‑222‑1523. При этом следует правильно формулировать свою проблему. Грамотное описание ситуации, с указанием всех подробностей и действий (время выполнения операции, предшествующие шаги, описание используемого оборудования, ПО и так далее) значительно сокращает время, требуемое на решение проблемы. Помните, что информация со стороны участников системы является приватной, это значит, что у сотрудников поддержки будет доступ только к тем данным, которые вы предоставите.

Ответы на вопросы

После теоретического вступления перейдем к практическим вопросам участников вебинара:

Как оформить возврат промаркированного товара, если выявлены недостатки после продажи?

Есть такая операция «Возврат в оборот» — ее описание можно найти в «Паспортах процесса». Стоит отметить, что возврат в оборот лекарственного препарата возможен только для последующего возврата поставщику, поскольку он (препарат) будет признан недоброкачественным.

Почему медицинским организациям запретили повторный ввод ЛС в оборот? Планируется ли возобновление данной операции?

Здесь нужно уточнить — повторный ввод после каких операций, и при каких условиях. Например, при выбытии ЛС в рамках стационара он должен быть доступен.

Как в реестре отправленных документов быстро найти необходимый документ?

В реестре есть функция фильтрации, где можно указать критерии поиска по идентификатору организации, ИНН, времени совершения операции и так далее.

Первый раз получили маркированный товар. Пришла товарная единица, содержащая 180 упаковок товара. Не считали код с коробки, а только с каждой упаковки. Коробку после этого выкинули. Теперь выпадает ошибка. Как ее исправить?

Самый быстрый путь решения этой проблемы — узнать, какой был акцепт передачи товара. Если акцепт прямой, то уточнить код SSCC (который был на коробке) у поставщика. И отправить документ подтверждения с этим кодом. Если акцепт обратный, то SSCC также можно узнать у поставщика, а в систему надо подавать документ 416.

Почему данные от поставщиков не приходят в МДЛП? Скопилось много накладных!

Попробуйте с данным вопросом обратиться к поставщику вашей товарно-учетной системы, возможно проблема кроется именно в ней. Также всегда проверяйте по какому акцепту вам поставляется товар — при обратном акцепте вам не должны приходить документы первыми.

Что делать если препарат продан (выбит чек ОФД), а в ГИС МДЛП не прошло выбытие?

Во-первых, нужно убедиться, что этот препарат не значится в реестре ожидания — т. е. нужно проверить, что вы осуществили и подтвердили его приемку. Во-вторых, как уже было сказано ранее, за передачу данных в систему через ККТ отвечает ОФД, а значит это может происходить не мгновенно. И в‑третьих, если проблема сохраняется, об этом можно написать в службу поддержки, указав все необходимые сведения.

Почему нет уведомлений о сбое сервиса и времени проводимых технических работ?

Уведомления о плановых работах ГИС МДЛП приходят на электронный адрес, который организация указала при регистрации. Кроме этого анонсы дублируются в социальных сетях и Telegram-канале.

Из-за ошибки учетной программы два препарата ушли с ошибкой — система их не восприняла. Теперь по учетной они ушли, а по системе остались в обороте, что делать?

Нужно обратиться к вендору учетной системы с вопросом — по какой причине произошла ошибка обработки данных и информация в систему не была передана, а после, совместно с ним, составить обращение в службу технической поддержки ГИС МДЛП. Обращение к поставщику товарно-учетной системы необходимо для заполнения технического описания проблемы, чтобы наши специалисты смогли ее решить.

В МДЛП был отправлен документ об успешном агрегировании. Через какое время агрегированные короба будут отображены в личном кабинете?

Если вы получили квитанцию об агрегировании, то это значит, что система уже обработала данный документ — и, если вы не проводили разеграгации, SGTIN и SSCC будут доступны в кабинете. Если этого не произошло — нужно написать в службу поддержки.

Как изменить идентификатор места деятельности поставщика?

Его нельзя изменить. Он выдается исходя из адреса, указанного в лицензии, выданной Росздравнадзором. Таким образом, при смене адреса места осуществления деятельности, код идентификатора может изменить только сам контрагент.

Если после приемки возникла ошибка обработки пакета, а препарат продан — что тогда?

Если он продан, то SGTIN будут в документах о выбытии. И при возникновении такой ситуации можно написать в службу поддержки и решить эту проблему, имея на руках фактуры приемки, где указан SGTIN этого препарата.

Как вывести препарат из оборота не через кассу и не через регистратора выбытия?

Никак. Это невозможно.

Многие организации по ошибке зарегистрировали лишние места деятельности. Теперь поставщики путаются. Как «почистить» свой список неактивных мест деятельности?

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

Если товар появился на остатке аптеки в «Честном знаке», значит ли это, что приходные операции проведены правильно?

Да, именно так.

С какого момента начинает свой отчет один рабочий день?

С момента приемки товара, зафиксированного в накладной.

Аптека получила от поставщика препарат с признаками маркировки, передала в систему информацию об этом. В ответ пришла ошибка «Попытка изменить состояние вложенного КИЗ». Поставщик предложил сделать возврат. Аптека может сделать возврат товара как немаркированного?

Такая ошибка возвращается, когда полученные аптекой SGTIN находятся в каком‑либо коробе — т. е. поставщик не разагрегировал транспортную упаковку. В первую очередь нужно просить поставщика найти их у себя на балансе, а потом сделать частичный или полный вывод из SSCC. После этого ошибка исчезнет и операция будет успешно завершена.

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

Если ЛС произведен до 1 июля (кроме препаратов ВЗН), то информация о нем может не передаваться в систему. Чтобы уточнить информацию по поводу соблюдения товаропроводящей цепи, нужно узнать у поставщика по какому акцепту он передавал вам ЛС. И отправить в систему МДЛП данные об успешной приемке. Если на этом ЛС будет ошибка «недопустимая операция для данного SGTIN», то не нужно пугаться — это нормально для ЛС, выпущенных в рамках проекта.

Аптека получает товар по обратному акцепту, сканирует каждую упаковку, поставщики не подтверждают по несколько дней или приходит «Ошибка состояния вложенного КИЗ», которую также не могут исправить по несколько дней. Какие сроки отводятся для устранения ошибок и подтверждения поставщику или производителю? Какие санкции их ждут за нарушения?

Это статья 6.34. Кодекса об Административных правонарушениях.

Аптечная сеть снабжает ФАП по договорам комиссии. Как отгружать ЛС с учетом соблюдения таких документов?

Отгрузку нужно осуществлять по обратному или прямому акцепту, а в типе документа указать «Договор комиссии». Если ФАП не имеет ККТ или регистраторов выбытия, то информацию в ГИС МДЛП должна передавать головная организация.

Аптека получила 4 упаковки с признаком маркировки. Передала данные в систему. На три упаковки пришло подтверждение, а на четвертую — ошибка. Поставщик говорит, что ошибка на стороне производителя. Что делать?

Этого не может быть. Потому что поставщик не мог принять препарат от производителя и не передать сведения об этом в ГИС МДЛП. Нужно решать такие вопросы с поставщиком. Для дополнительной помощи можно обратиться в службу поддержки.

Если проблема с ОФД и данные не переходят в ГИС МДЛП, но препараты уже проданы — является ли это нарушением?

Зависит от типа проблемы. Если не меняется статус в течение первых 10–20 минут, то это нормально, он поменяется позднее.

За сколько дней по закону поставщик должен подтвердить приемку товара?

За один рабочий день.

Программа не дает продать товар — от нас документы ушли в систему, но там не отобразились!

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

Проблема при акцептовании — поставщик не видит запросов аптеки и приходится перевыкладывать документы, хотя по МДЛП все уходит вовремя!

Опишите подробно эту ситуацию службе поддержки — какие документы уходят, какие поставщик требует вновь. Там проверят, приходят ли уведомления об этом, и решат этот вопрос.

Уронили флакон, разбили одну ампулу — как вывести из оборота данный товар?

Это 552 схема в паспорте процессов — «Списание ЛС или передача на уничтожение».

Если выявлен заводской брак, то как быть?

Есть такая схема в паспорте процессов «Возврат поставщику по причине брака». Можно воспользоваться ей.

Как принимать ЛП, если они пришли в транспортной упаковке и россыпью?

По частям — сначала упаковка, потом добавляете то, что пришло россыпью. Поставку можно оформлять несколькими документами.

При обращении в службу поддержки попросили предоставить открытый ключ в формате CER. Что это?

Для этого надо зайти в программу «КриптоПро», найти «Хранилище сертификатов» и сделать его экспорт. Подробное описание этого процесса есть в разделе «Обучающий центр» на сайте ЦРПТ.

Можно ли сделать автоматическую разагрегацию групповой упаковки, если кассир пытается сделать выбытие первичной упаковки?

Если вы уже приняли эти ЛС на баланс по SSCC и далее не делали разагрегацию группового кода, то вы можете так настроить свою товарно-учетную систему. Запрета на это нет.

Читайте больше полезного по маркировке лекарственных препаратов в специальной рубрике на нашем сайте.

На странице представлены наиболее частые коды ошибок, которые могут возникнуть при формировании документов в МДЛП, каковы причины их возникновения и как исправить.

Ошибка 1000

Ошибка 1000 возникает в случае неправильно сформированного документа. В МДЛП отображается, как «Техническая ошибка». Необходимо в квитанции отклонённого документа найти описание ошибки и найти нужную и списка возможных ситуаций, представленных ниже.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-pattern-valid: Value ‘2021-11-23T5:19:24.000Z’ 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-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’
Причина ошибки: не корректно указана дата «2021-11-20T5:19:24.000Z», верной датой была бы «2021-11-20T05:19:24.00Z».

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-pattern-valid: Value ‘ ‘ is not facet-valid with respect to pattern ‘([0-9]{10}|[0-9]{12})’ for type ‘inn_type’.
Причина ошибки: Не указан ИНН или указан не верный ИНН в документе.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-complex-type.2.3: Element ‘health_care’ cannot have character [children], because the type’s content type is element-only.
Причина ошибки: Тэги в документе разорваны или имеются в документе лишние символы, которые нарушают размещение элементов.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-identity-constraint.4.1: Duplicate unique value [0460243150469811000RE0PU009] declared for identity constraint «ux_withdrawal_sgtin» of element «order_details».
Причина ошибки: Указаны несколько раз SGTIN в документе. Требуется удалить дубликат SGTIN из документа.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: The element type «order_details» must be terminated by the matching end-tag «</order_details>».
Причина ошибки: наличие лишних или отсутсвующих тэгов в документе.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Указанный идентификатор организации (subject_id) в документе не соответствует отправителю.
Причина ошибки: В поле subject_id необходимо указывать идентификатор МД организации, которая осуществляет отправку документа.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-pattern-valid: Value » is not facet-valid with respect to pattern ‘([0-9]{1}[1-9]{1}|[1-9]{1}[0-9]{1})[0-9]{7}’ for type ‘kpp_type’.
Причина ошибки: В документе указан тэг kpp, но сам КПП не заполнен или не соответсвует формату КПП.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-complex-type.2.4.a: Invalid content was found starting with element ‘order_details’. One of ‘{union}’ is expected.
Причина ошибки: Имеются нарушения тегов. Отсутсвуют лишние теги или нет закрывающих тегов.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: XML document structures must start and end within the same entity.
Причина ошибки: Нарушена структура тегов. Отсутствуют закрывающие теги.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: The element type «sgtin» must be terminated by the matching end-tag «</sgtin>».
Причина ошибки: в теге с указанием sgtin присутсвует пробел.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: cvc-pattern-valid: Value ‘0046700053912653EDaCpKOX00bz’ is not facet-valid with respect to pattern ‘[0-9]{14}[!-«%-/0-9A-Z_a-z]{13}’ for type ‘sign_sgtin_type’.
Причина ошибки: SGTIN имеет длину, отличную от 27 символов.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: An invalid XML character (Unicode: 0x1) was found in the element content of the document.
Причина ошибки: в документе присутствуют недопустимые символы, которые в том числе могут быть скрытыми символами-разделителями.

Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: The element type «multi_pack» must be terminated by the matching end-tag «</multi_pack>».
Причина ошибки: нарушение формирования тегов. Присутствуют лишние или отсутсвуют закрывающие теги.

Ошибка 11

error_code 11: Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке.
Причины ошибки могут быть следующие:

1. Выполняется попытка передать товар из недопустимого статуса.
2. Лекарственные препараты были получены по государственному контракту и пытаются быть перемещены, как продажа за собственные средства.
3. Попытка вернуть товар по схеме 415 с типом 2 (возврат) недопустима, если приём товара был по схеме 702. В таком случае нужно, чтобы контрагент со своей стороны загрузил схему 702.
4. Лекарственный препарат уже был реализован и не может быть перемещён далее.

Ошибка 52

error_desc 52: Операция не может быть выполнена. Указанный SGTIN/SSCC не найден в системе или находится в архиве.
Причины ошибки:

1. Указанный SGTIN уже выбыл из оборота и переведён в архив.
2. Указанный SSCC уже расформирован или введён неверно.
3. Допущены ошибки при вводе SGTIN. Некоторые символы могут быть визуально похожи, поэтому при ручном вводе SGTIN может быть совершён ввод не корректных символов.
4. В SGTIN учитывается верхний и нижний регистр, поэтому строчные символы будут отличаться от заглавных в SGTIN.

Ошибка 22:

error_desc 22: КиЗ принадлежит другому участнику.
Причина ошибки: SGTIN по данным МДЛП принадлежит другому участнику. В данном случае необходимо проверить, не выполнил ли контрагент уже самостоятельно перемещение товара по другому документу. Или товар изначально не был принят на баланс организации.

Ошибка 34:

error_desc 22: Операция не может быть выполнена. Отправитель сведений и владелец SGTIN/SSCC не совпадают.
Причина ошибки: В поле subject_id указан не корректный идентификатор места деятельности, отличный от фактического расположения товара. Либо указан идентификатор организации в поле subject_id, при нахождении товара на территории РФ.

Когда стороны сделки подписывают УПД, оператор ЭДО, передаёт в ГИС МТ «Честный ЗНАК» информацию, содержащуюся в этом документе. Затем в системе маркировки начинается дополнительная проверка документа и после завершения проверки, пользователь в личном кабинете системы маркировки может увидеть следующий результат:

1. Когда у документа появляется статус «Обработан успешно» — означает, что произошел переход прав собственности на маркированные товары. Товары из документа можно реализовывать дальше.
2. Когда у документа появляется статус «Обработан с ошибками» — означает, что переход права собственности на маркированные товары не произошел.

Как узнать статус документа в Честном Знаке?

Для просмотра статуса документа необходимо выполнить следующие действия:

1. Перейдите в личный кабинет по ссылке

2. Выберите необходимую товарную группу:

3. Перейдите в раздел «Документы»:

4. В разделе «Документы» выберите вкладку «Документы»:

5. Статус документа можно отфильтровать:

6. Если есть документ со статус «Обработан с ошибкой», то ошибку можно посмотреть, зайдя в документ:

7. Для того чтобы посмотреть ошибку, нажмите на кнопку «Сформировать список ошибок»

8. Дождитесь формирования списка ошибок:

9. Затем скачайте список ошибок, нажав на кнопку «Скачать список ошибок»

10. Скачанный документ рекомендуется извлечь из архива и открыть через блокнот:

11. Затем в документе можно посмотреть текст ошибки:

Например: 

В образце указан номер ошибки «24», «Статус кода маркировки {КМ} не соответствует выполняемой операции»

Обновлено: 28.01.2023

Шаг 1: Вы пробуете найти ответ с помощью быстрого поиска по базе знаний. Если ответ не найден, переходим на Шаг 2. Шаг 2: Для того что бы задать вопрос и получить ответ от нашего специалиста, нам необходима краткая информация о вас. Вы формируете вопрос, заполняете анкету и переходите на Шаг 3. Шаг 3: Если вы еще не наш клиент, Вам предоставляется выбор тарифа. Первый вопрос вы можете задать бесплатно. Важно! Мы работаем только с пользователями лицензионных программ 1С. Чтобы задать вопрос, вы должны знать регистрационный номер вашей программы 1С. Что это и как узнать номер, смотрите здесь.

Проверка регистрационного номера программного продукта показала, что , поэтому мы подготовили для Вас, следующие тарифы:

Бесплатно

• 1 бесплатный вопрос
• Консультация специалиста
• Ответ в течении 3х рабочих дней

ИТС ТЕХНО

ИТС ЛК

• Неограниченное количество консультаций
• Помощь по телефону и email
• Помощь по удаленному подключению

ИТС ПРОФ

• Помощь специалиста в обновлениях и настройке программы
• Неограниченное количество консультаций
• Доступ к сервисам 1С .

Вопрос: Как подключить регистратор выбытия к 1С:Больничная аптека?

Разобраться в проблеме самостоятельно – хорошее решение. Но время – деньги. Каждый месяц команда нашей линии консультаций отвечает на 4 тысячи вопросов.
Доверьтесь специалистам — сохраните свое время!

В программах 1С:Медицина есть функционал для работы с маркировкой лекарственных препаратов. В этой статье рассмотрим, как работать с маркировкой лекарств на примере 1С:Медицина. Больничная аптека:

1. Настраиваем программу для работы с маркировкой

• регистрационный номер участника
• идентификатор клиента
• секретный код

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

3. Подключаем оборудование для маркировки

Для приема лекарственных средств понадобятся штрихкод сканеры или терминалы сбора данных, поддерживающие двухмерные штрихкоды формата 2D Data Matrix.

При списании лекарственных средств используется регистратор выбытия (РВ).
Он может работать в двух режимах: автономном и сетевом

Поля, которые нужно заполнить для подключения РВ:

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

Подскажите, кто уже сталкивался с настройкой МДЛП в 1С Аптека Розница?

В справочнике «Организации МДЛП» есть своя организация и места деятельности подтягиваются без проблем.
Но когда таким же образом пытаюсь подтянуть контрагента, то в ответ при попытке добавить, сразу получаю «Нет настроенных подключений через API». Что это может быть?

Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа.
Фредерик Брукс-младший

В создаваемое уведомление автоматически подтягивается информация о месте деятельности-отправителе и месте деятельности-получателе, а также об организации МДЛП.

Закажите внедрение маркировки лекарственных средств в учетную систему вашей компании у АйТи План

Подробнее

Также при проведении уведомления выполняется проверка вложенности. Если попытаться отгрузить отдельно потребительскую упаковку, которая ранее была вложена в групповую, то сработает блокировка. Потребуется сперва выполнить изъятие этой потребительской упаковки из групповой. В случае, если упаковка, уже находящаяся в уведомлении, сканируется повторно, программа также выдаст предупреждение.

Далее проводим уведомление, передаем данные и выполняем обмен с системой МДЛП.

Данный цикл будет посвящен маркировке лекарственных препаратов (далее ЛП), нюансам работы с «1С: Библиотека интеграции с МДЛП», доступной для скачивания на сайте ИТС, методиками работы с регистраторами выбытия, и проблемам, с которыми пришлось столкнуться при интеграции. Эта статья будет представлять из себя краткую инструкцию, что делать, когда маркировка уже близко и необходимо быстро внедрить ее. Надеюсь, она станет подспорьем в данной задаче. Будут приведены рекомендации, как в короткие сроки с минимально необходимой функциональностью и минимумом чтения документации произвести интеграцию библиотеки МДЛП и выполнить начальные настройки. Также будут даны рекомендации по быстрым, но важным, на мой взгляд, доработкам.

Данный цикл будет посвящен маркировке лекарственных препаратов (далее ЛП), нюансам работы с «1С: Библиотека интеграции с МДЛП» (далее библиотека МДЛП), доступной для скачивания на сайте ИТС, методиками работы с регистраторами выбытия (далее РВ), и проблемам, с которыми пришлось столкнуться при интеграции.

Данная статья будет представлять из себя краткую инструкцию, что делать, когда маркировка уже близко и необходимо быстро внедрить ее. Надеюсь, данная статья станет подспорьем в данной задаче. Будут приведены рекомендации как в короткие сроки с минимально необходимой функциональностью и минимумом чтения документации произвести интеграцию библиотеки МДЛП и выполнить начальные настройки. Также будут даны рекомендации по быстрым, но важным на мой взгляд доработкам.

Рекомендации по регистрации в МДЛП

Для начала необходимо пройти процедуру регистрации в Личном кабинете МДЛП. Необходимо иметь ЭЦП руководителя, настроенный КриптоПро (или другое криптографическое средство защиты информации).

Далее необходимо пройти процедуру регистрации на сайте Рекомендации по интеграции библиотеки МДЛП

Библиотека МДЛП содержит в своем составе библиотеки БПО, БСП, БИП (целиком или частично сказать затруднительно), поэтому при интеграции рекомендую в первую очередь проверить общие модули:

• ОбновлениеИнформационнойБазыБИП;
• ОбновлениеИнформационнойБазыБСП;
• ОбновлениеИнформационнойБазыБПО;

Здесь необходимо обратить внимание на процедуру ПриДобавленииПодсистемы, в которой храниться текущая версия конкретной библиотеки. В случае если библиотека МДЛП содержит более позднюю версию рекомендую обновлять модули данной библиотеки. В противном случае можно обновить только контур МДЛП.

В общем случае в первую очередь необходимо обращать внимание на модули, содержащие МДЛП в своем имени.
Перечень обязательных к переносу метаданных

• ИнтеграцияМДЛП в основном предназначены для обмена с контуром МДЛП (формирование документов на отправку, получение квитанций, авторизация и пр.);
• ОбновлениеИнформационнойБазыМДЛП (стандартный модуль, содержащий процедуры обновления до текущей версии);
• СобытияФормМДЛП служат для процедур интерактивной обработки в формах документов;
• ТранспортМДЛП содержит настройки обмена с МДЛП;

Здесь следует обратить внимание на ВестиСведенияДляМониторингаДвиженияЛекарственныхПрепаратов — не забудьте установить в Истину в клиентском приложении, иначе не будете видеть документы МДЛП;

ИспользоватьАвтоматическуюОтправкуПолучениеДанныхМДЛП опция, позволяющая выполнять обмен автоматически;

• большинство необходимых типов имеют тип строка, в частности ОснованиеУведомленияО в дальнейшем необходимо будет выставить в необходимый ссылочный тип, если Вы планируете делать ввод на основании;

• АвторизацияАПИМДЛП форма ввода логина пароля для авторизации;

• Драйвер1СУстройстваВводаNative — драйвер необходимый для сканера штрих кодов;

• Необходим обязательно последний пакет (ИнтеграцияМДЛП_1_35 на текущий момент);

Необходимо перенести все (кроме имеющих префикс удалить). Подробнее о документах далее.

Необходимы все, имеющие МДЛП в своем имени;

• ПанельМаркировкиМДЛП является основным рабочим столом. Подробнее о ней далее.
• ПолучитьСоставТранспортныхУпаковокМДЛП позволяет просмотреть упаковки, входящие в групповую;
• ПроверкаИПодборУпаковокМДЛП используется в формах документов для указания наличияналичия упаковки в документе;
• СверкаОстатковМДЛП служебная обработка, позволяющая проводить сверку остатков в базе и в контуре МДЛП;

После переноса необходимых метаданных необходимо выполнить обязательные начальные настройки в клиентском приложении.

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

В справочнике Сертификаты ключей электронной подписи и шифрования должен быть виден сертификат вашей организации. Также необходимо установить корневой сертификат в доверенные корневые сертификаты. Его можно получить

Нюанс — необходимо установить нужную версии программы шифрования в самом сертификате.

Для добавления контрагента достаточно его ИНН. Подписывается в таком случае запрос сертификатом собственной организации.

Данные действия являются минимально достаточными для интеграции библиотеки МДЛП и начала обмена документами.

Рекомендации по начальным изменениям библиотеки

Библиотека МДЛП является хорошей основой для ведения учета и в принципе серьезных изменений ее не требуется для ведения базового учета. Однако работа пользователей будет достаточно неудобной, если интегрировать библиотеку хотя бы без основных изменений.

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

Самым первым, на мой взгляд, является создание документов на основании, чтобы пользователю облегчить ввод документов уведомлений в контуре МДЛП. Если вы не являетесь производителем, то становится чуть проще, так как уменьшается количество типов документов необходимых для учета.
В самом простом случае будут необходимы следующие документы уведомления (приводятся имена метаданных):

УведомлениеОПриемкеМДЛП — первый документ с которого стоит начать знакомство. Позволяет оприходовать ЛП на вашу организацию. Различается типом акцептования, либо обратный порядок, либо прямой. Если очень кратко обратный порядок — ваша организация сделала уведомление о приемке, отдала в МДЛП, поставщик подтвердил. Прямой акцепт наоборот — поставщик отправил документ отгрузки, ваша организация загрузила документ из МДЛП и подтвердила получение.

Нюансы, на которые стоит обратить внимание:

• если источник финансирования указан Средства федерального бюджета или Средства регионального бюджета поле Номер контракта обязательно к заполнению, иначе МДЛП вернет ошибку. Рекомендую добавить проверку заполнения по условию.
• если сбита нумерации документа (пример внутренний номер документ стал вместо «00000000027» «2» при обмене будет получена ошибка с неуникальным номером). Рекомендую пользователям запретить сразу редактирование номера, так как они часто путают поля номер и номер документа (тут хранится в большинстве случаев номер накладной).
• при получении документа прямого акцепта пользователь должен подтвердить, что упаковки получены сканированием дата матрикс или вручную. Рекомендую запретить пользователю ручную простановку, так как это чревато оприходованием того что нет в документе. Поставщики тоже путаются.
• если не ошибаюсь, на данный момент не считается сумма от цены и количества в табличных частях документов. Рекомендую к доработке.
• соответственно ввод на основании данного документа должен быть в обе стороны из-за наличия двух видов акцептования. Обратный акцепт вводится на основании вашего документа оприходования в основной системе учета, прямой акцепт создает документ оприходования.
• для сопоставления организаций и контрагентов служит регистр сведений СубъектыОбращенияМДЛП доступный из ПанельМаркировкиМДЛП по гиперссылке. Однако можно прописать соответствие через константу, если у вас одна организация и одно место деятельности. После использовать при заполнении на основании всех уведомлений.

УведомлениеОПеремещенииМДЛП служит для перемещения КМ между вашими местами деятельности. Рекомендации аналогичные, за исключением акцептов — данный документ ими не оперирует.

УведомлениеОбОтгрузкеМДЛП данный документ является парным с документом УведомлениеОПриемкеМДЛП и так же оперирует акцептованием, с небольшой разницей что обратный акцепт загружается из МДЛП, прямой же создается пользователем. Рекомендации по изменениям те же что и для приемки.

УведомлениеОВыдачеВОтделенияМДЛП (мой самый любимый документ, подвергнувшийся самой большой доработке) — служит для фиксации факта выдачи ЛП (в том числе долей вторичной упаковки) и позволяет работать с Регистраторами выбытия (им планируется посвятить отдельную статью). Работает по двум схемам — с использованием РВ и без него с обменом напрямую в МДЛП. За это в форме документа отвечает галочка ИспользоватьРВ.

Библиотека МДЛП реализовала возможность работы с РВ. Необходимо заполнить справочники РегистраторыВыбытия и РабочиеМестаМДЛП. К сожалению подробных рекомендаций, по коду в этой области не могу дать, так как самостоятельно осваивал АПИ РВ и реализовывал работу с РВ еще до того, как это умела библиотека. Некоторыми подробностями планирую поделится в следующих статьях.

Важным моментом является необходимость сканирования КМ в случае выбытия через РВ, так как в таком только в таком случае мы можем получить код целиком с крипто хвостом. Это является необходимым условием для отправки КМ в РВ. Весь код оборачивается в Base64, формируется json и отправляется в РВ. Рекомендую добавить эту проверку в код для взведенной галочки ИспользоватьРВ.

Вам нужен общий модуль ИнтеграцияМДЛПКлиентСервер Функция РазобратьКакШтрихкодГС1(Штрих код)

Нижеприведенный код обрамите условием, например, по функциональной опции (для возможности быстрого включения отключения проверки). Первый кусок кода отвечает за проверку групповых упаковок, второй за проверку КМ.

УведомлениеОбАгрегированииИТрансформацииУпаковокМДЛП документ позволяет производить различные манипуляции с групповыми упаковками. В большинстве случаев на начальном этапе может потребоваться дезагрегация. Сам документ был значительно доработан в последних версиях библиотеки (ранее он позволял, например, дезагрегировать лишь одну упаковку в документе. Это приводило к необходимости существования отдельной формы документа для этой операции). Здесь основной рекомендацией на мой взгляд является создание на основании уведомления о приемке документа дезагрегации и наличия ссылки на этот документ из документа приемки. Пользователи, думаю, будут вам благодарны, когда не придется искать долго эти связанные документы. На крайний случай при нехватке времени советую набросать хотя бы быстрый отчет на СКД по этим документам, связав их по номерам групповых упаковок.

Эти документы являются самыми основными на мой взгляд, и именно их я рекомендую доработать в первую очередь. Других документов я планирую коснуться в следующих статьях.

Я надеюсь, данная статья поможет в короткий срок вам сделать быструю интеграцию, настройку и базовые доработки библиотеки МДЛП. Если у вас возникли пожелания и замечания по данной статье прошу высказаться в комментариях. Данная статья является первой, так что буду рад пожеланиям по оформлению или читаемости. Хорошего вам кода.

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

  

• Сообщение от ольги николаевны адвокат

  

• Ямантау сообщение на башкирском языке

  

• Сообщение о теракте 5 класс обж

  

• Сообщение о банкнотах россии на английском языке

  

• Сообщение о городе кирове

Самый животрепещущий вопрос — выбытие лекарственного препарата (далее ЛП). В системе мониторинга движения лекарственных препаратов (МДЛП) могут проводиться технические работы, она может быть недоступна, как тогда отпускать ЛП? Отпуск доступен двумя способами: продажа через контрольно-кассовую технику, когда оформляются чеки, и использование регистратора выбытия, работающего и в сетевом, и в автономном режиме.

Итак, оператор фискальных данных. Пробиваем ЛП и проводим его через кассу. Здесь никаких проблем нет, мы защищены, т.к. оператор фискальных данных передает за нас данные в систему МДЛП, агрегирует информацию, получаемую из чеков, и, после того как сервис снова становится доступным, автоматически, без нашего участия, передает в систему в виде документов.

Есть такой механизм «реестр ожиданий», основная суть которого заключается в том, что если мы хотим произвести выбытие ЛП, который еще не поставлен на баланс, не отправлен документ о его приемке, то при внештатной ситуации данный механизм нам может помочь. В реестр ожиданий попадают документы, которые были произведены в качестве выбытия, но еще нет документа о приемке. Например, в аптеке пробили и отпустили лекарственный препарат покупателю, но не смогли отправить документ о приемке, хотя и сформировали его, из-за проводимых в системе регламентных работ. Лекарственный препарат можно отпустить потребителю, сформировать чек, оператор фискальных данных направит документ о выбытии препарата в систему МДЛП, при этом система увидит, что нет документа о приемке препарата. Система будет ожидать этот документ. Если он подготовлен, то он попадет в систему чуть позже. И тогда будет произведено корректное выбытие без нарушения. Период ожидания документа о приемке по месту деятельности составляет две недели. Но это работает только в случаях, когда система МДЛП недоступна. Скорректированы сроки передачи информации в МДЛП, они составляют один рабочий день. Реестр ожиданий работает с оператором фискальных данных при прямом и обратном акцепте. С регистратором выбытия реестр ожидания работает только в случае обратного акцепта.

Выбытие посредством регистратора выбытия. Здесь тоже все защищено. При использовании регистратора выбытия, даже в случае неработающей системы МДЛП, им можно сканировать ЛП и формировать отчет о выбытии этих препаратов. В данном случае регистратор выбытия и товароучетная система, отправляя задание на регистратор выбытия, работают от системы МДЛП автономно, формируя буфер документов на отправку в МДЛП. Эта отправка будет произведена после того как сама система станет доступна.

Итого: выбывая с использованием ККТ или регистратора выбытия, мы производим это независимо от работы системы МДЛП, т.к. оба оборудования накапливают в себе данные о выбытии и при доступности необходимых каналов производят выбытие в сторону системы МДЛП.

ПЕРЕДАЧА ДАННЫХ

Хотелось бы обратить внимание на передачу данных в систему МДЛП при приемке ЛП.

Есть один рабочий день на приемку ЛП со дня их фактической приемки получателем от отправителя. Данные о приемке фиксируются в накладной. Допустим, в пятницу вечером поступает ЛП. Один рабочий день в данном примере — это понедельник, в течение которого нужно передать информацию о приемке в МДЛП (но закон не запрещает передать их в пятницу или в выходные дни).

Основной процесс в медицинских и аптечных организациях — это работа с регистратором выбытия. Он может накапливать документы, формируемые участниками для отправки в систему МДЛП. В случае нештатных ситуаций регистратор выбытия берет на себя часть работы по формированию документов и сохранению их до момента восстановления работы системы МДЛП. Формируя заказ на провизора или на склад, с которого производится выдача ЛП, осуществляется сканирование ЛП и оформляется отчет в регистраторе выбытия. В случае каких-то затруднений отчет сохраняется в регистраторе выбытия до получения обратной связи с МДЛП. Но ЛП можно уже отпустить покупателю. То есть процесс не останавливается.

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

КОГДА РЕГИСТРАТОР ВЫБЫТИЯ НЕ РАБОТАЕТ

Что делать, если сломался регистратор выбытия? Каков порядок действий? Здесь на помощь приходят инструкции, размещенные на сайте «Честный знак». Нужно сформировать заявку на указанный на сайте электронный адрес технической поддержки и максимально описывать проблему. Если проблема с работоспособностью регистратора, то указывается ИНН организации, от которой идет обращение, адрес места деятельности регистратора выбытия, описывается проблема и запрос отправляется на линию техподдержки. Скорость реакции будет зависеть от подробностей описанной проблемы. Если консультация помогает и проблему можно решить дистанционно, она решается дистанционно. Если требуется замена регистратора, заявка передается в соответствующий отдел и оформляется заявка на замену.

Если идет замена, это не значит, что нельзя выбывать ЛП. Есть возможность открытия схем для выбытия ЛП. Два пути в случае неработоспособности регистратора выбытия.

• Первое. В товароучетной системе можно формировать документы типа 521, 531 для отправки в систему МДЛП. Техническая поддержка в данном случае открывает доступ к приему схем от вашей организации, и таким образом вы направляете данные в систему МДЛП.

• Второе. Зарегистрироваться в системе «Фарма.Просто» для формирования документов и отправить потом документы в систему ДЛП из «Фарма.Просто».

Ключевые документы для работы в системе и основные моменты, которые описывают сложности работы в системе МДЛП при любой нештатной ситуации, изложены в методических рекомендациях.

Первый момент. При товароучетной системе ничего не мешает там формировать необходимые документы для отправки в систему МДЛП и на момент недоступности системы откладывать их у себя в буфер, а отправить на обработку в систему, когда ее работа восстановится.

Второй момент. Сервис «Фарма.Просто». Если ваша товароучетная система не умеет работать, когда нет соединения с МДЛП, можно воспользоваться этим сервисом при условии регистрации заранее. Если регистрация есть, то сформировать документы на отправку и после восстановления работоспособности системы МДЛП зайти в «Фарма.Просто» и нажать кнопку «отправить» (в систему МДЛП). У сервиса есть мобильное приложение «Фарма.Просто», которое может выполнять задание по сканированию ЛП, чтобы добавлять данные в документы. Приложение также работает в режиме офлайн.

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

На сайте «Честный знак» есть раздел вопросов и ответов, где размещена вся актуальная информация о работе в системе МДЛП.