При разборе входящего сообщения мдлп возникла ошибка текст ошибки нет данных для обработки

Компания «ЦРПТ» поясняет сложные моменты работы с системой маркировки в аптеках и ЛПУ

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

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

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

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

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

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

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

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

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

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

Еще одно средство разрешения нештатных ситуаций — обращение в службу поддержки по адресу [email protected] или телефону 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 и далее не делали разагрегацию группового кода, то вы можете так настроить свою товарно-учетную систему. Запрета на это нет.

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

Источник

Часто задаваемые вопросы

Вопрос: «При разборе входящего сообщения МДЛП возникла ошибка: Не удалось заблокировать документ <Объект не найден> (545:9cf400155d64740f11ed2e72b42484ae).»

Ответ: Это стандартное информационное сообщение от системы Честного знака. Его следует игнорировать


Вопрос: При списании препаратов в атомарных единицах на этапе указании серий требуется заполнение на целочисленного значения

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

Вопрос: Как поменять единицу измерения в документах расхода

Ответ: См. скриншот . При отсутствии атомарной ед. изм. необходимо обратиться в СТП.

Вопрос: как добавить номенклатуру или внести изменения в уже существующую (наименование, атомарные единицы)

Ответ: Направить обращение на портал техподдержки. Обязательно должны быть указаны наименование, МНН, производитель, единицы измерения, атомарные единицы

Источник

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

Ошибка 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, при нахождении товара на территории РФ.

Вопросы и ответы при работе с МДЛП

Ошибки при авторизации на портале «Честный знак»

  • Нет доступных сертификатов
  • Не включен КриптоПро Browser plug-in
  • Проверьте аутентификационные данные
  • Нет доступа в личный кабинет

Проблемы и ошибки сканирования кодов маркировки в документах

  • Код маркировки уже есть в документе
  • Не сканируется код маркировки
  • Некорректный код
  • Не получается добавить код маркировки в документ при списании через регистратор выбытия
  • Регистратор выбытия недоступен

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

  • Не приходят документы
  • Код не соответствует формату маркировки
  • Указанный контрагент отсутствует в списке доверенных контрагентов
  • Код маркировки из документа принадлежит другому участнику
  • Некоторые коды маркировки из документа не найдены в ИС МДЛП
  • Запрещено удалять зарегистрированную маркированную продукцию
  • Коды принадлежат другой организации или выбыли из оборота
  • Некоторые коды маркировки не принадлежат поставщику
  • Невозможно подтвердить коды
  • Сертификат недоступен или введен неверный ПИН-код

Маркировка лекарств

Честный знак

МДЛП

Нашли неточность? Выделите текст с ошибкой и нажмите ctrl + enter.

Компания «ЦРПТ» поясняет сложные моменты работы с системой маркировки в аптеках и ЛПУ

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

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

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

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

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

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

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

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

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

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

Еще одно средство разрешения нештатных ситуаций — обращение в службу поддержки по адресу [email protected] или телефону 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 и далее не делали разагрегацию группового кода, то вы можете так настроить свою товарно-учетную систему. Запрета на это нет.

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

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

Ошибка 1.

Ошибка подписания данных при обмене МДЛП (нажатие на кнопку «Выполнить обмен»).

Ошибка 1

Причина – неверно выбран адрес API.

Решение ошибки:

  • проверьте правильность указания адреса API;
  • выберите из контекстного меню поля «Адрес API» пункт «Промышленная система».

Решение 1

Ошибка 2.

Ошибка подписания данных при обмене МДЛП (нажатие на кнопку «Выполнить обмен»).

Ошибка 2

Причина – ошибка при вводе пароля.

Решение ошибки – введите корректный пароль.

Ошибка 3.

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

Ошибка 3

Причина – для определения причины отклонения посмотрите xml-текст квитанции МДЛП в протоколе обмена.

П р и м е ч а н и е – Отклонение по причине некорректного документа – в уведомлении все упаковки отсканированы на закладке «Товары».

Решение ошибки:

  • запросите информация об упаковке;
  • выполните обмен;
  • проверьте поступившие товары;
  • передайте данные. 

П р и м е ч а н и е – Серию достаточно проверить визуально, если она такая же, то генерировать не надо, можно повторно нажать кнопку «Сгенерировать».

Ошибка 4.

Ошибка «Данные по штрихкоду не найдены» после сканирования ЛП и выгрузке штрихкодов в 1С.

Причины:

  • данные из ТСД передаются в неверном формате;
  • неверный код маркировки.

П р и м е ч а н и е – Индийские препараты имеют код маркировки, но не той структуры.

Решение – Проверьте штрих код.

П р и м е ч а н и е – Промаркированный штрихкод должен выглядеть следующим образом:

Отличие маркировки РФ от других стран

Ошибка 5.

Не приходят уведомления после нажатия кнопки «Выполнить обмен».

П р и м е ч а н и е – Если известно, что поставщик отгрузил ЛП по прямой схеме, уведомление на рабочем столе 1С получено.

Причины:

  • компьютер не подключен к интернету;
  • неполадки у интернет-провайдера;
  • подключение к интернету блокирует межсетевой экран, антивирусная программа или другое программное обеспечение.

Решение: 

  • восстановите подключение к интернету;
  • отключите (настройте) блокирующие программы.

Маркировка для МДЛП

 Я

Альбатрос

25.09.19 — 08:02

Киньте схемой из чего состоит SGTIN?

Я вижу, что туда зашит gtin, серия, срок годности и т.д.

Но есть куча неопознанных цифр) Для примера:

010800266002506717210831103578442189317267284382403004

piter3

1 — 25.09.19 — 08:05

Альбатрос

2 — 25.09.19 — 08:15

(1) Ага, только к ЛП не подходит что-то)

1snik_d

3 — 25.09.19 — 08:24

Куча цифр, а еще может быть и букв — это так называемый криптохвост, который призван защитить Datamatrix от подделки.

1snik_d

4 — 25.09.19 — 08:26

Для отправки информации на портал нужен GTIN, криптохвост не нужен.

Альбатрос

5 — 25.09.19 — 08:38

(4) Мне при обратном акцептировании нужно вытащить уникальный серийный номер, я вкурить не могу с какой позиции его тащить. В рекомендациях к КИЗ написано:

«– первая группа данных – Идентификационный номер ЛП (GTIN), которому предшествует идентификатор применения (01). Количество цифровых символов составляет 14.» Тут понятно, на моем примере 01 это ид применения, а 08002660025067 собссно ШК (gtin). Далее:

«– вторая группа данных – индивидуальный серийный номер вторичной (потребительской) упаковки ЛП, которому предшествует индикатор применения (21) и который генерируется эмитентом КИЗ. Количество символов в цифровой или буквенно-цифровой последовательности (латинского алфавита) составляет 13 (тринадцать). Завершающим символом для данной группы данных должен использоваться разделитель Function 1 Symbol Character (FNC1) (в качестве которого используется символ <GS>, код 29 в таблице символов ASCII).»

И вот тут у меня ступор, ибо на моем примере:

01 — ид применения.

08002660025067 — шк.

1721083110357844 — вот это как разобрать? На глаз вижу, что 357844 это серия, 210831 — это срок годности. Что такое 17 и 10? Это криптохвост?

Альбатрос

6 — 25.09.19 — 08:40

2189317267284382403004 — н а оставшаяся часть ваще непонятна.

1snik_d

7 — 25.09.19 — 08:51

(6) Вот пример правильной маркировки 010460714356061121HF3XRR6ZVZ00P100030617240300417200600

1snik_d

8 — 25.09.19 — 08:52

(01) 04607143560611 — GTIN 14 символов

(21) HF3XRR6ZVZ00P — Номер 13 символов

ptiz

9 — 25.09.19 — 08:53

(0) Не читайте старых кодов и постановлений.

Последняя редакция:

Группа 1:

(01) 14 символов (цифры) – GTIN

Группа 2:

(21)13 символов (цифры и буквы) – инд серийный номер упаковки<символ 29>

Группа 3:

(91)4 символа (цифры и буквы) – ключ проверки<символ 29>

Группа 4:

(92)44 символов (цифры и буквы) – криптохвост

На рынке сейчас таких упаковок еще НЕТ !

Альбатрос

10 — 25.09.19 — 09:00

(7) (9) в (0) считанная сканером инфа с реальной упаковки. В руках ее держу) Нам ее официально продали с обратной схемой акцепта. Тут впринципе 13 значный код написан на упаковке и он 8931726728438. Что не подходит под ваши схемы) Я в замешательстве)

Альбатрос

11 — 25.09.19 — 09:02

(7) (9) Или вы про то, что в моих руках какая-то старая маркировка и сейчас такая не должна использоваться?

d4rkmesa

12 — 25.09.19 — 09:08

(10) Если по аналогии с GTIN, то получается (01)08002660025067(17)210831(10)357844(21)8931726728438(240)3004

d4rkmesa

13 — 25.09.19 — 09:09

(12) Тьфу, т.е. с GS1-128

1snik_d

14 — 25.09.19 — 09:15

(9) Уже есть

1snik_d

15 — 25.09.19 — 09:15

(11) Именно

1snik_d

16 — 25.09.19 — 09:18

(11) Это похоже вообще не Datamatrix

1snik_d

17 — 25.09.19 — 09:25

Хотя попробуйте на портал код собрать из (12). Должно сработать. 080026600250678931726728438 — вот так как-то

Альбатрос

18 — 25.09.19 — 09:27

(17) Попробовал) Отказано)

<error_code>11</error_code>

      <error_desc>Некорректное состояние</error_desc>

      <object_id>080026600250678442189317267</object_id>

Альбатрос

19 — 25.09.19 — 09:28

(16) Да не, DataMatrix, только схема как из (12)

Альбатрос

20 — 25.09.19 — 09:29

Всем спасибо!

ptiz

21 — 25.09.19 — 09:30

(10) «Нам ее официально продали с обратной схемой акцепта.» — «официально» продажи будут с 01.01.2020. Пока все операции в МДЛП — эксперимент. В коде Datamatrix на упаковках, продающихся на рынке — полная белиберда: индивидуальный код может быть расположен черт-те где, т.к. программировалось это по самым древним вариантам постановлений. Ваш выбор: хотите — разбирайте эти коды, не хотите — ваше право отказаться.

Альбатрос

22 — 25.09.19 — 09:32

(21) Да, так и есть, спасибо. Разбор кода все равно не помог.

ptiz

23 — 25.09.19 — 09:33

(18) Такой упаковки в МДПЛ нет вообще:

  <?xml version=»1.0″ encoding=»UTF-8″ standalone=»yes» ?>

— <documents version=»1.31″ session_ui=»76a037c6-21d6-4a9f-9efe-5f24383e0b35″ xmlns:ns2=»http://www.mdlp.org/wsdl/MdlpService.wsdl»>;

— <kiz_info action_id=»211″>

— <result>

  <found>false</found>

  <sgtin>080026600250678442189317267</sgtin>

  </result>

  </kiz_info>

  </documents>

ptiz

24 — 25.09.19 — 09:38

А вот 080026600250678931726728438 — есть.

  <?xml version=»1.0″ encoding=»UTF-8″ standalone=»yes» ?>

— <documents version=»1.31″ session_ui=»687c5fac-4739-4677-a528-eadfddaf5957″ xmlns:ns2=»http://www.mdlp.org/wsdl/MdlpService.wsdl»>;

— <kiz_info action_id=»211″>

— <result>

  <found>true</found>

  <sgtin>080026600250678931726728438</sgtin>

  </result>

— <sgtin>

— <info_sgtin>

  <status>in_circulation</status>

  <gtin>08002660025067</gtin>

  <series_number>357844</series_number>

  <expiration_date>31.08.2021</expiration_date>

  </info_sgtin>

  </sgtin>

  </kiz_info>

  </documents>

Альбатрос

25 — 25.09.19 — 09:52

(24) Даже если так, то:

      <error_code>11</error_code>

      <error_desc>Некорректное состояние</error_desc>

      <object_id>080026600250678931726728438</object_id>

Альбатрос

26 — 25.09.19 — 09:55

Может с источником финансирования что то не так?

Альбатрос

27 — 25.09.19 — 09:56

Ошибка конечно поражает своей полнотой описания)

ptiz

28 — 25.09.19 — 09:57

(25) Это ответ на какое сообщение?

1snik_d

29 — 25.09.19 — 10:00

(25) Что-то неправильно в схеме формируете.

1snik_d

30 — 25.09.19 — 10:00

Поставьте на телефон приложение Честный знак и проверьте упаковку. Там место хранения можно увидеть.

1snik_d

31 — 25.09.19 — 10:01

Убедиться, что в МДЛП она за Вашим поставщиком числится.

1snik_d

32 — 25.09.19 — 10:02

(24) 211 схема говорит, что упаковка в системе.

Альбатрос

33 — 25.09.19 — 10:11

(28) (29)

<?xml version=»1.0″ encoding=»UTF-8″?>

<documents xmlns:xs=»http://www.w3.org/2001/XMLSchema»;

    xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»;

    version=»1.30″>

  <receive_order action_id=»416″>

    <subject_id>00000000186285</subject_id>

    <shipper_id>00000000000502</shipper_id>

    <operation_date>2019-09-25T13:50:51+07:00</operation_date>

    <doc_num>115989170-001</doc_num>

    <doc_date>23.09.2019</doc_date>

    <receive_type>1</receive_type>

    <source>1</source>

    <contract_type>1</contract_type>

    <contract_num>883 от 09.12.13</contract_num>

    <order_details>

      <union>

        <sgtin>080026600250679836713789897</sgtin>

        <cost>1001</cost>

        <vat_value>91</vat_value>

      </union>

      <union>

        <sgtin>080026600250679755476052187</sgtin>

        <cost>1001</cost>

        <vat_value>91</vat_value>

      </union>

      <union>

        <sgtin>080026600250678931726728438</sgtin>

        <cost>1001</cost>

        <vat_value>91</vat_value>

      </union>

    </order_details>

  </receive_order>

</documents>

Альбатрос

34 — 25.09.19 — 10:16

(30) Поставил. Действительно числится за поставщиком. Пишет в приложении «код статуса проверки 11». Что это значит?

ptiz

35 — 25.09.19 — 10:33

(33) Странно. А по другим упаковкам что пишет? Покажи полную квитанцию.

Кстати, поставщик вас добавил в доверенные? (хотя тогда, наверное, ошибка была бы другая).

Мы к проверке 415 и 416 только-только подходим.

1snik_d

36 — 25.09.19 — 10:33

(34) Напишите в СТП, они оперативно отвечают.

Альбатрос

37 — 25.09.19 — 10:34

(35)

<?xml version=»1.0″ encoding=»UTF-8″ standalone=»yes»?>

<documents xmlns:ns2=»http://www.mdlp.org/wsdl/MdlpService.wsdl»;

    version=»1.30″>

  <result action_id=»200″

      accept_time=»2019-09-25T09:51:12.807+03:00″>

    <operation>416</operation>

    <operation_id>4765c384-7379-486b-a7c4-fa5a97342851</operation_id>

    <operation_result>Rejected</operation_result>

    <operation_comment>Операция отклонена</operation_comment>

    <errors>

      <error_code>11</error_code>

      <error_desc>Некорректное состояние</error_desc>

      <object_id>080026600250679836713789897</object_id>

    </errors>

    <errors>

      <error_code>11</error_code>

      <error_desc>Некорректное состояние</error_desc>

      <object_id>080026600250679755476052187</object_id>

    </errors>

    <errors>

      <error_code>11</error_code>

      <error_desc>Некорректное состояние</error_desc>

      <object_id>080026600250678931726728438</object_id>

    </errors>

  </result>

</documents>

Альбатрос

38 — 25.09.19 — 10:35

(36) Ага, написал уже.

ptiz

39 — 25.09.19 — 10:35

Да, и ответом поделитесь, пожалуйста! Интересно, в чем дело.

Альбатрос

40 — 25.09.19 — 10:43

(39) Хорошо, но в прошлый раз они мне 2 недели отвечали.

Альбатрос

41 — 26.09.19 — 10:08

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

Альбатрос

42 — 26.09.19 — 10:09

Отдельная попоболь это конечно информативность ошибок, описанных в квитанциях.

ptiz

43 — 26.09.19 — 10:13

(42) Похоже, что при отсутствии в доверенных, чужие упаковки просто не попадают в доступные — и формируется текст ошибки «на все случаи жизни», когда упаковка недоступна (например, с неверным статусом).

Альбатрос

44 — 26.09.19 — 10:22

(43) Ага, только у них это «на все случаи жизни» похоже реально на все случаи) У меня такая же ошибка в песочнице была, когда я пробовал продать товар по «собственным средствам» когда он поступил мне по рег. бюджету. Но мысль верная, при неправильном «срезе» упаковка видимо становится недоступна.

NorthWind

45 — 26.09.19 — 10:23

(0) > 010800266002506717210831103578442189317267284382403004

По порядку

(01) 08002660025067

(17) 210831

(10) 3578442189317267284382403004

в десятке должен быть FNC1, который не отображается. Если его найти, то можно разбирать дальше. Что значат какие AI (01, 17, 10) — есть в сети.

Как-то так…

victuan1

46 — 27.09.19 — 05:41

(7) И где тут «Символ 29»?

victuan1

47 — 27.09.19 — 05:48

(0) Формат кода маркировки ЛП, стр. 38 согласно документу «Методические рекомендации» по ссылке

http://честныйзнак.рф/upload/iblock/226/Metodicheskie_rekomendatsii_dlya_uchastnikov_eksperimenta_po_markirovke_sredstvami_identifikatsii_i_monitoringu_za_oborotom_otdelnykh_vidov_lekarstvennykh_preparatov_dlya_meditsinskogo_primeneniya_ot_23.04.2018.pdf

Формирование кода вторичной (потребительской) упаковки — Data Matrix:

а) первая группа данных — глобальный идентификационный номер торговой единицы, состоящий из 14 цифровых символов, которому предшествует идентификатор применения (01);

б) вторая группа данных — индивидуальный серийный номер вторичной (потребительской) упаковки, состоящий из 13 символов цифровой или буквенно-цифровой последовательности (латинского алфавита), которому предшествует идентификатор применения (21). Завершающим символом для данной группы данных должен использоваться специальный символ-разделитель, имеющий код 29 в таблице символов ASCII;

в) третья группа данных — код ТН ВЭД, которому предшествует идентификатор применения (240). Количество цифровых символов в коде ТН ВЭД составляет 4 (указываются первые 4 символа 10-значного кода ТН ВЭД). В случаях, если код ТН ВЭД не располагается в конце кодируемой последовательности в составе двумерного кода, необходимо использовать завершающий символ-разделитель, имеющий код 29 в таблице символов ASCII.

Дополнительно на усмотрение эмитента средств идентификации допускается включение в состав двумерного штрихового кода следующих двух групп данных:

г) четвертая группа данных — номер производственной серии ЛП, состоящий не более чем из 20 символов цифровой или буквенно-цифровой последовательности (латинского алфавита), которому предшествует идентификатор применения (10). Завершающим символом для данной группы данных должен использоваться символ-разделитель, имеющий код 29 в таблице символов ASCII;

д) пятая группа данных — дата истечения срока годности, которой предшествует идентификатор применения (17) и которая формируется эмитентом средством идентификации. Формат записи числовых символов для даты истечения срока годности ЛП — ГГММДД (6 символов).

В тех случаях, когда на производственной линии в момент выпуска продукции значение даты истечения срока годности в днях «ДЦ» не устанавливается, то эмитент средств идентификации может указать значение даты по своему усмотрению.

unbred

48 — 27.09.19 — 06:01

вот такую штуку ляпаю на траспортные упаковки

http://skrinshoter.ru/s/270919/nwho4Cdj

NorthWind

49 — 27.09.19 — 08:36

(46) Не скопировался или сканер его не вернул.

ptiz

50 — 27.09.19 — 09:20

(47) Это давно устаревшая редакция!

victuan1

51 — 30.09.19 — 12:58

(50) Что ж тогда Честный знак мне ее скинул на мой запрос.

victuan1

52 — 30.09.19 — 13:00

(51) 18.06.19 они дали мне такой ответ.

Успело за это время устареть?

ptiz

53 — 30.09.19 — 13:04

(52) Еще как

victuan1

54 — 01.10.19 — 11:29

(53) Можно ссылку на новую редакцию?

ptiz

55 — 01.10.19 — 17:16

victuan1

56 — 01.10.19 — 17:48

(55) «Пункт 5 изменен с 17 сентября 2019 г.» vs «Это давно устаревшая редакция!»

ptiz

57 — 02.10.19 — 09:24

(56) Методические рекомендации (где еще фигурирует код ТНВЭД), указанные в (47) — это апрель 2018, они устарели с выходом еще первой версии Постановления 1556 в конце 2018 года.

Garykom

58 — 02.10.19 — 09:40

На интерфейсном уровне кто то смог https (после авторизации через сертификат) по ГОСТ без stunnel-msspi?

ptiz

59 — 02.10.19 — 11:17

(58) Это о чем? А то может мне тоже надо, а я и не знаю.

Garykom

60 — 02.10.19 — 11:22

(59) https://xn--80ajghhoc2aj1c8b.xn--p1ai/upload/iblock/819/API.Protokol-obmena-interfeysnogo-urovnya_v2.30.pdf

«Обратить внимание: Если Участник, к которому относится пользователь, Резидент, то после

процедур аутентификации и авторизации все методы API должны вызываться с ипользованием

HTTPS протокола. Для взаимодействия по https используется ГОСТ Р 34.10-2012 сертификат.»

  

ptiz

61 — 02.10.19 — 11:31

(60) Ну, мы стучимся из 1С с того компа, где стоит КриптоПро, а в нем, как я понял, всё нужное реализовано.

Garykom

62 — 02.10.19 — 11:39

(61) Из какой версии платформы 1С ? 8-ка из последних?

Я то для 7.7 промежуточный сервер мдлп на go пишу и там ошибка ‘remote error: tls: handshake failure’ вылезла для этих

ssl_protocols: TLSv1

ssl_ciphers: GOST2012-GOST8912-GOST8912

ptiz

63 — 02.10.19 — 11:40

(62) Да, 8.3.12, где есть поддержка этого ГОСТ.

ptiz

64 — 02.10.19 — 11:42

(62) А почему не хочешь использовать stunnel-msspi ?

Garykom

65 — 02.10.19 — 12:13

(64) Сча его и использую, просто хотелось бы отказаться от лишнего.

Чтобы легче в установке/настройке и порты не занимало.

web1984

66 — 19.11.19 — 14:24

Аналогичная проблема, что и автора темы.

415 схема.

Делаю в песочнице. Работаю от типографии.

Добавил в типографии и у своей организации доверенных контрагентов друг друга.

Ошибка постоянно выходит при отправке

<?xml version=»1.0″ encoding=»UTF-8″?>

<documents session_ui=»4Aa246a6-D7e2-2465-a056-0234554369a3″ version=»1.34″ xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»>;

    <move_order action_id=»415″>

        <subject_id>00000000104494</subject_id>

        <receiver_id>00000000113607</receiver_id>

        <operation_date>2019-11-19T15:13:10+03:00</operation_date>

        <doc_num>000000010</doc_num>

        <doc_date>30.10.2017</doc_date>

        <turnover_type>1</turnover_type>

        <source>1</source>

        <contract_type>1</contract_type>

        <order_details>

            <union>

        <sgtin>507540413987650008761187946</sgtin>

        <cost>300</cost>

        <vat_value>54</vat_value>

        </union>

        </order_details>

    </move_order>

</documents>

Ответ

<?xml version=»1.0″ encoding=»UTF-8″ standalone=»true»?>

-<documents xmlns:ns2=»http://www.mdlp.org/wsdl/MdlpService.wsdl»; session_ui=»4Aa246a6-D7e2-2465-a056-0234554369a3″ version=»1.34″>

-<result accept_time=»2019-11-19T13:55:32.882+03:00″ action_id=»200″>

<operation>415</operation>

<operation_id>2f16a130-8a37-4bcc-8ff9-08856f75ed4a</operation_id>

<operation_result>Rejected</operation_result>

<operation_comment>Операция отклонена</operation_comment>

-<errors>

<error_code>11</error_code>

<error_desc>Некорректное состояние</error_desc>

<object_id>507540413987650008761187946</object_id>

</errors>

</result>

</documents>

1. Проверил товар на складе у Типографии

2. Отправляю с склада Забакайля

3. Sgtin не в sscc и в обороте.

Почему не проходит.

web1984

67 — 19.11.19 — 14:26

Кстати, кто какое решение от 1с собирается использовать? Пробую 1с fresh МДЛП. Про УТ я так понимаю ждать бесполезно. Счас в ут 10.3

ptiz

68 — 19.11.19 — 16:38

(66) Доверенные — это для обратной схемы (получатель товара должен быть в доверенных у отправителя).

Такая ошибка говорит о том, что на момент 2019-11-19T15:13:10+03:00 упаковка 507540413987650008761187946 не была в статусе in_circulation на балансе поставщика.

ptiz

69 — 19.11.19 — 16:43

Возможно, место деятельности неверное.

Garykom

70 — 19.11.19 — 16:44

(0) Не путаешь DataMatrix 2D ШК с SGTIN?

В SGTIN (длиной 27 символов) только GTIN (14 цифр ean) и SN (13 символов уникальный серийный номер штуки)

victuan1

71 — 20.11.19 — 07:52

(0) Если есть 1С 7.7, то можно проверить штрихкоды с помощью внешней обработки для тестирования ШК и формирования кода товара в виде последовательности байт для передачи через тег 1162 в чеке ККТ

на основании документа «Протокол информационного обмена (ОФД)» (https://xn--80ajghhoc2aj1c8b.xn--p1ai/upload/iblock/34f/Protokol_informatsionnogo_obmena_OFD.pdf)

выложена здесь https://yadi.sk/d/zg87QbQ9TTA3aQ

Добавили в обработку (версия 2.4) возможность проверять ШК даже если в нем пропущены символы с кодом (29) /например, сканер не читает их/

Пример работы:

ШК = 010460406000600021N4N57RSCBUZTQ24030040029101612181724010191ffd092tIAF/YVoU4roQS3M/m4z78yFq0fc/WsSmLeX5QkF/YVWwy8IMYAeiQ91Xa2z/fFSJcOkb2N+uUUmfr4n0mOX0Q==

Код товара в формате GS1 Data Matrix или Data Matrix маркировки

GTIN = 04604060006000  Serial = N4N57RSCBUZTQ

КТ = 44 4D 04 2F F7 5C 76 70 4E 34 4E 35 37 52 53 43 42 55 5A 54 51

(Побайтно перевили в вид, необходимый для передачи в ОФД через тег 1162 в составе чека)

http://www.picshare.ru/view/10338497/

web1984

72 — 20.11.19 — 08:37

(69)

Доверенных добавлял только для устранения этого варианта.

1. Проверил товар на складе у Типографии

2. Отправляю с склада Забакайля

3. Sgtin не в sscc и в обороте.

web1984

73 — 20.11.19 — 08:40

(70) Если ты меня перепутал с Альбатросом, то у него уже все решилось.

Я отправляю именно sgtin. можно посмотреть в xml.

Брал ил ЛК Типографии с остатка лекарств с склада с Забайкайля и в обороте, без sscc/

web1984

74 — 20.11.19 — 08:42

(71) у нас оптовая продажа, там обмен чисто по sgtin.

victuan1

75 — 20.11.19 — 08:57

(74) А какая разница. DM ведь всё равно нужно преобразовывать в SGTIN, извлекая из него GTIN и Serial.

web1984

76 — 22.11.19 — 08:49

(75) не понял что такое DM. я просто брал примеры запросов которые прошли, там были sgtin. Я неправильно запрос написал, вы это имеете ввиду?

unbred

77 — 22.11.19 — 08:53

data matrix

dezss

78 — 22.11.19 — 08:57

Mihenius

79 — 22.11.19 — 10:55

Есть отличная новость.

Внесен законопроект о переносе срока на 01.07.2020

Мы уже регистраторы получили.

В большинстве МИС для поликлиник модуль будет готов к декабрю, в половине уже есть.

А вот для мелких аптек или мелких поставщиков на древнем ПО проблемы есть.

Mihenius

80 — 22.11.19 — 11:44

Garykom

81 — 22.11.19 — 11:57

(80) 30 октября новость датируется а сегодня какое число?

ptiz

82 — 22.11.19 — 12:21

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

Вчера должны были рассмотреть, но отложили.

https://sozd.duma.gov.ru/bill/834261-7

Mihenius

83 — 22.11.19 — 13:24

(82) Не настолько же дураки? Или будут опять ждать волшебного пинка Путина?

Текущая готовность поликлиник/фапов 15%!

В малодоступных регионах ниже, в крупных думаю много лучше.

У 1с — Больничная аптека за 44600 или 10 тысяч в год в облаке для МО

для мелких это большие деньги, благо хоть регистраторы выбытия бесплатно

web1984

84 — 22.11.19 — 14:06

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

Все молятся, чтобы перенесли. Крупные производители говорят не отложат.

web1984

85 — 22.11.19 — 14:07

Кто в песочнице мне может грузануть немножко товара))) Плиз!!!

Garykom

86 — 22.11.19 — 14:27

ptiz

87 — 22.11.19 — 15:17

(83) «Не настолько же дураки?» — вчерашняя история про медсправки для водителей всё показала на этот счет. Я уже против переноса сроков — хочу чтобы дурь с маркировкой проявилась во всей красе. Но больных жалко.

web1984

88 — 24.11.19 — 15:50

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

shuvaev

89 — 25.11.19 — 12:39

Да есть небольшой затык в подписании с сервера, в типовом МДЛП используется при подписании сообщения функция НачатьПодключениеРасширенияРаботыСКриптографией, а доступность у нее — Тонкий клиент, веб-клиент, мобильный клиент, толстый клиент, мобильное приложение(клиент)

Следовательно с сервера нельзя будет к ней обратиться.

Garykom

90 — 25.11.19 — 12:48

(89) Особый прикол будет когда сертификат только на сервере стоит, и на все компы клиентов их ставить никто не собирается.

shuvaev

91 — 25.11.19 — 13:10

Так о по сути, есть ли рекомендации, как сделать?

Garykom

92 — 25.11.19 — 13:21

(91) Вместо встроенной в 1С криптографии использовать https://www.cryptopro.ru/products/other/cryptcp

shuvaev

93 — 26.11.19 — 09:47

(92) Спасибо, пробуем

kyvv

94 — 26.11.19 — 10:30

ptiz

95 — 26.11.19 — 11:15

(94) Маркировка пчел — это правильно! По 50 копеек за штучку.

baboon

96 — 29.11.19 — 15:58

Всем приветствие!

Коллеги, свалилось на меня внезапно ЭТО. Третий день разбираюсь, пока только осилил создание учетных записей в тестовом контуре, по потрясающей инструкции, где кроил руками текст сертификата и лепил тела REST-запросов. Кое-как с помощью Advanced REST Client таки зарегистрировал пользователя, но что делать с этим дальше — пока до конца не понимаю.

«Песочница» и тестовый стенд — это вроде бы разные ресурсы, с чем лучше работать, на чем отлаживать?

Я могу самостоятельно и ввести товар в оборот (и коды сгенерить?), и принять, и отгрузить? Как вообще получить входящую транзакцию? Поддержка молчит, пишут только, что мое сообщение обрабатывается…

Скачал библиотеку 1С:Библиотека интеграции с МДЛП, но это такое куцее (относительно моего опыта) пособие, что слабо понимаю.

Её же можно настроить на «свою» учетку, которую я «вымутил» по Краткая инструкция по быстрому старту для изучения API?

Поделитесь любезно, сведущие…

baboon

97 — 03.12.19 — 17:32

Всем привет!

Кое-что прояснилось, но в целом вопрос к сообществу — типовую библиотеку МДЛП кто-нибудь использует?

Или она годится только как трамплин (или болото :)?

ptiz

98 — 03.12.19 — 17:37

(96) Насчет «самостоятельно выпустить», вот вчера в скайпе выложили материал

https://yadi.sk/d/hQq_bYqylGheBg

baboon

99 — 03.12.19 — 17:57

(98) Спасиб, ознакомлюсь!

В части выпустить в оборот в тестовом стенде вроде всё получилось. А вот по части приемки как-то убого выглядит, или я не понимаю.

Сканировать факт в уведомлении как бы и некуда…, ну номенклатуру по GTIN Не пытается искать, ладно, на то и демо…и с отображением состава SSCC чудит — вроде заполняет Объект.НомераУпаковок, но не отображает, что-то там в обработке делается. Если рядом в сыром виде разместить отображение ТЧ — все норм.

Pivas15

100 — 03.12.19 — 19:01

(97) Пользуемся, но надо допиливать. Код который призван разобрать штрихкод пришлось частично переписать. И так везде. Что-то, но надо доделать.

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

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 &apos;contract_num&apos;, 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 &apos; 2 АПТ&apos; is not facet-valid with respect to pattern &apos;S.*&apos; for type &apos;document_number_200_type&apos;.
Не соответствие формату элемента
В документе на закладке «Дополнительно» заголовок «Документ-подтверждения (соответствия) / документ розничной торговли» в поле «Номер» перед введенным номером есть пробел.

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 автоматически передаётся для ЛП, код маркировки которых не прошёл верификацию.

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

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

464-основа.png

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

Вероятная проблема 

При обработке «Честным ЗНАКОМ» направленных ему участниками рынка универсальных передаточных документов (УПД) могут выявляться ошибки.

Например, статус кода маркировки не соответствует выполняемой операции. Или УПД содержит коды разных товарных групп. Или поставщик наклеил коды на товар, но забыл передать в «Честный ЗНАК» сведения о вводе товара в оборот.

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

«Такском-Файлер» поможет исправить ошибки 

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

— документ отправлен;

— получен положительный ответ;

— получен отрицательный ответ.

Последний вариант ответа указывает на допущенные ошибки, в том числе технические. «Такском-Файлер» делает их текстовое описание и рекомендует пользователю, как их исправить. 

Ошибки и рекомендации 

Номер ошибки

Описание ошибки

Рекомендация по действиям пользователя

4

Документ с таким номером уже зарегистрирован в ГИС МТ

Документ уже зарегистрирован в ГИС МТ.

Обратитесь на support@crpt.ru или направьте новый документ с уникальным номером или УКД/УПДи к направленному ранее документу.

10

Покупатель не зарегистрирован в ГИС МТ

Для успешной смены собственника оба участника оборота товаров должны быть зарегистрированы в системе ГИС МТ. Покупателю (получатель товара) необходимо зарегистрироваться в системе мониторинга ГИС МТ по ссылке. 

12

Участник(и) (ИНН: {ИНН}) не зарегистрирован(ы) в ГИС МТ

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

16

УКД №{номер} от {дата} не обработан. Не найден исходный УПД в ГИС МТ

Исходный УПД не поступал в систему мониторинга ГИС МТ или после поступления документа УПД уже был обработан корректирующий (исправительный) документ. Сведения в отношении переданных маркированных товаров в УПД на основании корректировочного документа не могут быть изменены. Проверьте отправку исходного УПД.

22

Коды маркировки {КМ} не найдены в ГИС МТ

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

23

У участника оборота (ИНН: {ИНН}) товаров нет полномочий на выполнение операции с кодом(ами) маркировки {КМ}

Код(ы) маркировки не принадлежит(ат) в ГИС МТ отправителю товаров. Отправитель (Поставщик товара) должен обратиться на support@crpt.ru

24

Статус кода маркировки {КМ} не соответствует выполняемой операции

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

46

Состав или имя документа некорректно

Необходимо проверить корректность поданных сведений. Требования к оформлению УПД указаны в Методических рекомендациях по оформлению электронных документов или обратитесь на support@taxcom.ru

54

Не заполнена дата исправления

Для корректировочных документов ИУПД и УКД необходимо проверить дату исправления. В случае её отсутствия необходимо её указать.

64

УПДи №{номер} от {дата} не бработан. Был проведен УПДи с более поздними номером или датой исправления

Было отправлено по очереди несколько УПДи. Корректировка информации в ГИС МТ проводится на основании документа, присланного с более поздней датой. Документ с более поздней датой считается итоговым.

79

Коды маркировки {КМ} некорректные

В УПД должны указываться коды идентификации, присутствующие в личном кабинете ГИС МТ. Требования к указанию кодов идентификации товаров и к экранированию специальных символов указаны в Методических рекомендациях по оформлению электронных документов. Коды указанные в документе имеют неверный формат. Отправитель (Поставщик товара) должен обратиться на support@crpt.ru

102

УПДУКД №{номер} от {дата} не обработан. Содержит коды маркировки разных товарных групп

УПД содержит коды идентификации разных товарных групп (например: обувь и одежда), такой документ не может быть обработан.  Необходимо формировать отдельные УПД в разрезе товарных групп.  

103

УПДУКД №{номер} от {дата} не обработан. Не содержит кодов маркировки

Оператор ГИС МТ обрабатывает УПД/УКД, подписанные двумя сторонами и содержащие сведения о маркированном товаре. Документ не содержит коды маркировки и не может быть принят в ГИС МТ.

Отправить

Запинить

Твитнуть

Поделиться

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

    Дата проводки документа ранее даты предыдущей операции.
    Решение: Необходимо исправить дату фактической поставки

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

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

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


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

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

    Решение: транспортная упаковка (sscc) не содержит вложений (sgtin). необходимо обратиться к поставщику за устранением ошибки 
  7. Ошибка при проводке  накладной: Попытка изменить состояние вложенного КИЗ.

    Данные sgtin находятся в транспортной упаковке 
    Решение: при проводке  приходной накладной по обратной схеме необходимо сканировать транспортную упаковку, а не sgtin 
    при проводке перемещение или требования необходимо выполнить распаковку ТУ в ПН 
  8. Ошибка РВ: Ошибка ДРВ: Отчет о выбытии. Неверное состояние отчета

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

    Интервал между запросом ТУ должен быть 30 сек. Требование МДЛП
    Решение: между сканированием ТУ делать перерыв в 30 сек. 
  10. Ошибка при проверке настроек МДЛП в «администрирование»: Некорректный запрос. проверьте настройки МДЛП. 

    Решение:  Если менялся сертификат, проверить имеет ли доступ этот сертификат в личный кабинет МДЛП. Если нет, обратиться в тех. поддержку МДЛП и добиться входа в личный кабинет. 
  11. При отпуске рецепта: Не удалось запросить документы по отчету СУЗ 

    Решение: обязательно нужно проверить чтобы у роли в ЛК МДЛП стояли права «Прослеживание документов по отчету из СУЗ»
  12. Ошибка при проверке настроек МДЛП: Запрашиваемые данные не найдены. 

    Решение: Проверить правильность внесенных настроек МДЛП. 
  13. Ошибка при открытии «Журнала сценариев»: Ошибка мониторинга сценариев — не удалось открыть порт ‘61862’/ Отслеживание новых событий будет недоступно. 

    Порт занят другим процессом. Это не мешает выполнению сценариев, можно запустить сценарий- он пройдет в фоновом режиме. Либо освободить порт и повторить попытку запуска журнала сценариев.  
  14. Ошибка при проводке документа-перемещения: Обработка запроса провалилась: ошибка на этапе первичной обработки документа: некорректный документ…..  

    У склада назначение указано МД, но не проставлен признак «склад БА» (основной склад). Решение: если перемещение производится на склад отделения убрать МД у склада назначения.  
  15.  Ошибка при отпуске рецептов: Ошибка задания регистратора выбытия

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

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


Ошибка может возникнуть, если указанный в документе SGTIN/SSCC не зарегистрирован в системе или был перемещен в архив. Напоминаем, что в архивное хранилище перемещаются коды, у которых прошло более 60 дней после выбытия.
 Рекомендуется проверить отправляемый документ и убедиться, что: 
 — указаны существующие SGTIN/SSCC;
— указанные SGTIN НЕ находятся в архиве;
— SSCC не расформирован по данным системы;
— оборудование правильно считывает SGTIN/SSCC (Внимание! КМ регистрозависимые). В случае некорректной работы устройств необходимо обратиться к интегратору.
 Получить информацию по SGTIN можно через ЛК Участника в: 
— «Реестр SGTIN» с помощью параметров фильтрации;
— «Реестр SGTIN, эмитированных до 28.03.2021» с помощью параметров фильтрации;
— «Архив SGTIN» с помощью поиска;
Получить информацию по SSCC можно через ЛК Участника:

-«Реестр SGTIN» с помощью поиска по SSCC;

-«Реестр SGTIN, эмитированных до 28.03.2021» с помощью поиска по SSCC;

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

17. Ошибка при отпуске электронного рецепта: Ошибка при получении СЭМД. Текст ошибки: некорректный запрос. проверьте настройки СЭМД(«Не указаны Фамилия и/или Имя пациента»)

Решение: это ошибка не связана с настройками, проблема с отсутствием ФИО у льготников ОНЛП, проблема будет решена когда все Аптеки будут подключены в защищенной сети

18. Ошибка при проводке документа: Операция отклонена. Операция не может быть выполнена. Операция не может быть выполнена. Недопустимое значение параметра withdrawal_reason и/или reason_return для SGTIN

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

Получить информацию о причине вывода из оборота выбранного SGTIN можно через ЛК участника в «Реестр SGTIN» с помощью параметров фильтрации;

19. Ошибка при загрузки мест деятельности конкретного поставщика: Некорректный запрос. проверьте настройки МДЛП

Решение: Необходимо проверить ОГРН данного поставщика, возможно. в начале или конце стоит пробел 

20. Документ заблокирован другим пользователем 

Решение: Под пользователем admin зайдите в раздел «администрирование», далее «операции»-«диагностика»-«управление логическими блокировками», удалите блокировку

21. При проверке сервиса подписи

необходимо проверить сертификат:

1. Сертификат установлен под пользователем который указан в пуле приложений IIS?

4. Сертификат в крипто про установлен в реестр?

5. У сертификата сохранен пароль?

22. При проверки настроек МДЛП

Проверить,как внесена настройка номер сертификата, должен быть внесен без пробелов и «?»

Фото Кирилла Кухмарь / ТАССФото Кирилла Кухмарь / ТАСС

Эксперимент по обязательной маркировке лекарств стартовал еще в 2017 году. С 1 октября 2019 года процедура стала обязательной для части препаратов, а с 1 июля 2020 года — для всех остальных. При этом для ряда препаратов, произведенных с 1 июля по 1 октября 2020 года, сделали исключение — их можно было продавать немаркированными. Несмотря на долгую подготовку к началу маркировки, осенью аптеки и дистрибьюторы начали жаловаться на сбои в системе, появились опасения, что маркировка может привести к дефициту лекарственных средств.

Голос фармы

Один из крупных сбоев в системе произошел 30 сентября — были потеряны данные об уже загруженных в нее препаратах, продажа и поставка маркированных лекарств затруднилась. На сегодня восстановлено всего лишь 38% данных. Об этом со ссылкой на выступление представителя Центра развития передовых технологий Егора Жаворонкова на закрытой встрече рабочей группы по маркировке лекарственных препаратов при Росздравнадзоре сообщили «Открытые медиа». Подобные случаи были и раньше, например, 26 июня часть маркированных лекарств оказалась заблокирована. В ЦРПТ факт сбоя опровергли, но сбои в системе — только часть проблем.

Например, заведующая одной из тверских аптек жалуется, что им приходится отказываться от заказа части товаров из-за несоизмеримого объема работы по сканированию: «Большинство препаратов поступают в аптеку в крупных упаковках, например, парацетамол в упаковках по 250 блистеров. И аптекари должны все 250 штук просканировать. Это нереально». Когда лекарство приходит в аптеку, провизор должен отсканировать код Data Matrix с каждой принимаемой и реализуемой упаковки. Продавать немаркированный товар или товар, который не получил подтверждения из ИС МДЛП, аптеки не имеют права. «На некоторых препаратах маркировка нанесена некачественно, требуется повторное сканирование или занесение кода вручную — эти процедуры замедляют процесс», — говорит заместитель гендиректора «Эркафарм» Дмитрий Боков.

Группа компаний «Эркафарм» (сети аптек «Доктор Столетов», «Самсон-Фарма», «Озерки») начала готовиться к запуску маркировки год назад: оборудовала аптеки специальными сканерами для считывания штрих-кодов, протестировала систему с дистрибьюторами, обучила персонал. Группа потратила на подготовку около 40 млн рублей, но в результате все равно не избежала проблем. Система мониторинга не справляется с нагрузкой, регулярные технические сбои тормозят обработку документов. Упрекнуть разработчика системы в бездействии нельзя: для решения проблем техподдержка МДЛП вносит изменения, но в этот момент система недоступна по 4-5 часов. Во время сбоя 30 сентября и вовсе зависла на двое суток. «Часто технические работы проводятся без заблаговременного извещения участников процесса», — добавляет Боков. Соответственно, все это ведет к сокращению продаж каждой торговой точки и сети в целом.

Одна из крупнейших интернет-аптек «Еаптека» (порядка 100 собственных и 1000 партнерских пунктов выдачи заказов в 76 городах России) испытывает такие же сложности, что и коллеги в офлайн. «Процедура довольно проблемная, особенно для недорогих позиций, — говорит исполнительный директор сети Василий Артамонов. — Нужно считывать QR-код по каждой принятой упаковке. А их много, и не всегда код считывается с первого раза». Ежедневно на складе «Еаптека» принимается до 100 000 упаковок, процесс приемки замедлился в 6-8 раз. «Спасает то, что не все приходы еще идут по маркированному товару», — добавляет Артамонов. Кроме того, маркировка добавила лишней работы во время приемки товара в аптеках. «Еаптека» была вынуждена нанять отдельную команду по работе с МДЛП: трех разработчиков и двух бизнес-аналитиков. По словам Артамонова, сейчас поставщики с трудом принимают возвраты по маркированному товару. «В процедуре отпуска покупателю корректировок меньше. Но, что важно, раньше была возможность оформить возврат покупателю при ошибке заказа. Теперь такой возможности нет, и на это многие покупатели реагируют негативно», — говорит он.

Александр Кузин, гендиректор сети аптек «36,6» считает, что, поскольку в полной мере система не введена в действие, это не мешает продажам: «Да, есть некоторые сбои, отдельных затрат требует процесс оприходования товара, но ответственность пока не введена до конца 2020 года. Мы не ждем отклика от МДЛП, сразу продаем. Поэтому очень важно, чтобы к моменту, когда система начнет работать в полномасштабном режиме, предусматривающем ответственностью участников, все технические проблемы «Честного знака» были решены».

Чем это грозит покупателям и аптечным сетям

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

По словам гендиректора аналитической компании DSM Group Сергея Шуляка, сбои в системе МДЛП происходят регулярно. По его словам, последний из них произошел вчера, 20 октября. При попытке зайти в систему высветилось объявление о проведении технических работ до 21 октября 11:00. Позже время восстановления работы системы перенесли еще на полтора часа. «Сети, безусловно, понесут экономические потери, но оценить сейчас масштаб сложно, — говорит эксперт. — Пока это компенсируется ажиотажным спросом на некоторые лекарства, а также продажами немаркированных препаратов». Тем не менее аптеки уже сейчас вынуждены увеличивать закупки с учетом товара, который будет считываться системой МДЛП дольше обычного. «Товарный запас скапливается в аптеках, а значит, растет нагрузка на движение денежных средств в рамках компании, — объясняет Шуляк. — Пока нет ответа от системы, аптека не может продавать товар, а значит, сокращается ее время для реализации товара и срок для того, чтобы рассчитаться с дистрибьютором за поставку. Это особенно критично для небольших региональных сетей».

Ответ системы

Центр развития перспективных технологий (ЦРПТ) был создан в 2017 году, 50% центра принадлежит структурам Алишера Усманова и его партнеров, по 25% у «Ростеха» и управляющего партнера Almaz Capital Александра Галицкого. Сентябрьский сбой оператор объясняет «техническим фактором» и уверяет, что его последствия уже устранены. «С июля по октябрь 2020-го количество документов по маркированным препаратам в системе выросло более чем в 20 раз и продолжает расти — система работает стабильно, инциденты не повторялись», — заверяют в пресс-службе ЦРПТ. По словам компании, случившиеся сбои — единичные случаи, «связанные с нарушением целостности данных».

По данным оператора, объем введенных в оборот маркированных препаратов превысил 1 млрд упаковок, их продают 48% аптек по всей стране. У 68% аптек лекарства с маркировкой есть на балансе. На сегодняшний день более 97% поступающих в МДЛП документов обрабатываются менее чем за 10 минут. В системе вообще не существует такого сценария, при котором аптека не может продать маркированный препарат, утверждают в ЦРПТ. Любая продажа лекарств через кассу и со сканированием кода маркировки практически сразу поступает в виде электронного чека в МДЛП. После этого готовится разрешение для аптечной организации немедленно приступать к реализации маркированного товара. Время на обработку и подтверждение, что лекарство теперь в системе, не должно влиять на доступность товаров для граждан, говорят в центре. «В случае некорректной подачи или обработки сведений фактическое товародвижение через аптечную сеть будет восстановлено через анализ чеков, сформированных кассой при продаже, — объясняет представитель оператора. — Данная мера позволит довести качество интеграций аптек с системой и скорость информационного обмена до «незаметного» для товаропроводящей цепи».

Приемка товара РїРѕ обратному акцепту ¶

Схема обратного акцепта

Документ должен быть обработан согласно описания:

Выбрать курсором строку с наименованием товара.

Выбрать курсором колонку штрихкода упаковки товара SGTIN в правой части Таблицы кодов.

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

Информация по SGTIN в документах из МДЛП

Контрольные точки РІ обработке документа¶

Если для этих типов документов в колонке Комментарий указано значение получено подтверждение, то документ обработан успешно:

Получены подтверждения для 416 и 607 типа документа

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

Проверка SGTIN¶

Узнать информацию о SGTIN в личном кабинете Честный знак.

Выбрать курсором строку штрихкода упаковки товара SGTIN в правой части Таблицы кодов

Нажать сочетание «горячих клавиш» Ctrl + Ins или вызвать пункт Копировать SGTIN в буфер Ctrl+Ins контекстного меню, которое открывается по нажатию правой клавиши мыши в правой части Таблицы кодов на строке с отмеченным SGTIN.

Открыть личный кабинет на сайте «Честный знак».

Выбрать вкладку «Товары».

Нажать кнопку «Фильтр».

Выбрать поле SGTIN для ввода значения.

Поиск в личном кабинете

Нажать кнопку «Применить».

Поиск в личном кабинете

Возможные результаты поиска и пояснения к ним:

Если SGTIN есть в личном кабинете, и товар числится в обороте, но 607 документа нет, то это значит, что Честный знак не отправил 607 документ в программе «М-АПТЕКА плюс», нужно ждать, какие-то задержки на стороне Честного знака.

В обоих случаях мы не можем повлиять на процесс ускорения процесса получения документа 607. Но в первом случае можно обратиться к поставщику и попросить акцептировать товар в Честном знаке.

Известные ошибки¶

Перечислены некоторые ошибки из таблицы Ошибки на уровне документа с указанием причины и способа решения.

Нет подтверждения поставщика¶

Есть квитанция по 416 документу с успешным завершением операции и нет документа 607 от поставщика.

Получено подтверждение для 416 и его нет для 607 типа документа

Найти информацию по SGTIN: Проверка SGTIN.

Операция РЅРµ может быть выполнена. Недопустимый переход РІ товаропроводящей цепочке.¶

В квитанции по документу ошибка №11. Текущий статус/состояние SSCC/SGTIN не позволяет совершить операцию.

Нарушение статусной модели (переходов);

Отсутствуют сведения о регистрации предшествующей требуемой операции 911/912/913/914

Проверить, что известно по документу 416:

Выполнить действия для получения Информации от ИС МДЛП.

Найти всё строки, где занчение 416 в колонке Тип док-та.

Если есть такие строки и хотя бы на одной из них в колонке Комментарий есть значение получено подтверждение, то товар перешел в состояние ожидания подтверждения (акцептирования) от поставщика, НО поставщик не подтвердил (не акцептировал, 607 документ). Необходимо сообщить это поставщику.

Если таких строк нет, то уточнить у поставщика и выслать ему документ 416 и квитанцию.

Попытка изменить состояние вложенного КИЗ¶

В квитанции по документу ошибка №15.

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

Фармацевту внимательно осмотреть коробку с товаром на наличие транспортной упаковки (SSCC):

Если транспортной упаковки нет, то обратиться к поставщику для разагрегации товара на SGTIN. После чего отправить данные в ИС МДЛП повторно.

Идентификатор текущего владельца Рё субъекта операции РЅРµ совпадают.¶

В квитанции по документу ошибка №22.

КИР— (товар) принадлежит РґСЂСѓРіРѕРјСѓ участнику.

Убедиться в том, что отправляют данные в МДЛП с верным адресом поставщика (Местом деятельности). Требуется отправить данные с верным адресом.

Если выслали данные с верным адресом, то проверить SGTIN на наличие в личном кабинете Честного знака. Подробне см. Проверка SGTIN.

В учете маркированного товара в таблице с колонкой SGTIN проверить значения в колонках:

статус и место деятельности

Операция РЅРµ может быть выполнена. Указанный контрагент отсутствует РІ СЃРїРёСЃРєРµ доверенных контрагентов.¶

В квитанции по документу ошибка №2014

Поставщик не добавил аптеку в доверенные контрагенты.

Сообщить поставщику информациюоб аптеке для добавления в доверенные контрагенты.

Источники:

https://www. forbes. ru/biznes/411869-sami-vinovaty-pochemu-apteki-stolknulis-s-problemoy-markirovki-lekarstv-i-kak-eto

https://help. aptekam. ru/markirovka/obratnyj_akcept/

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

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 &apos;contract_num&apos;, 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 &apos; 2 АПТ&apos; is not facet-valid with respect to pattern &apos;S.*&apos; for type &apos;document_number_200_type&apos;.
Не соответствие формату элемента
В документе на закладке «Дополнительно» заголовок «Документ-подтверждения (соответствия) / документ розничной торговли» в поле «Номер» перед введенным номером есть пробел.

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С.Маркировка МДПЛ по сертификату: при выполнении POST-запроса по адресу /api/v1/auth, error_code, api.authentication.error, error_description. Проверьте аутентификационные данные

Описание ошибки:
При попытке выполнить авторизацию на api-сервер Маркировки из модуля МДЛП в 1С 8:
Ошибка при выполнении POST-запроса по адресу /api/v1/auth
[400] Запрос не может быть исполнен.
{«error_code»:»api.authentication.error»,»error_description»:»Ошибка при
выполнении операции: Проверьте аутентификационные данные»}

Найденные решения:

В модуле обмена 1С.Маркировка МДЛП после нажатия на кнопку «Выполнить обмен» и выбора сертификата для подписи при попытке авторизации возникает окно «Не удалось подписать данные» с содержанием ошибки, представленным выше.

Нажатие на изображении увеличит его
1С 8 как исправить ошибку Ошибка при выполнении POST-запроса по адресу /api/v1/auth [400] Запрос не может быть исполнен.<br>
Рис.1. Момент возникновения ошибки «Ошибка при выполнении POST-запроса по адресу . /api/v1/auth. Проверьте аутентификационные данные»

Проблема исходя из описания самой ошибки заключается в том, что какие-то данные для подключения не подходят. На этом этапе обычно в промышленном контуре на сайте mdlp.crpt.ru, уже должна быть добавлена «Учётная система» в разделе «Администрирование». Поэтому первым делом необходимо проверить заполнение элемента справочника «Организации МДЛП» для «Собственной организации». Реквизит «Регистрационный номер участника» должен быть использован из профиля организации. А реквизиты «Идентификатор клиента» и «Секретный код» должны совпадать с данными раздела «Администрирование. Учетные системы» кабинета МДЛП для вашей организации. Для API «Промышленной системы» и «Тестовая система МДЛП («Песочница») значение реквизитов отличаются. Это необходимо учитывать и изменить при необходимости.

Нажатие на изображении увеличит его
1С 8 как исправить {"error_code":"api.authentication.error","error_description":"Ошибка при выполнении операции: Проверьте аутентификационные данные"}
Рис. 2. Пример с сайта infostart корректности заполнения полей настройки в 1С по данным учетной системы в кабинете МДЛП

Если будут перепутаны и не туда введены какие-либо из трех идентификаторов (рег. номер участника, идентификатор клиента или секретный код), то будет возникать ошибка. Так же если выбран не верный «Адрес API» в «Настройки и справочники» модуля МДЛП в 1С 8. В данном исходно был установлено значение «api.sb.mdlp.crpt.ru». Это не подходило.

Нажатие на изображении увеличит его
1C 8 Ошибка при выполнении POST-запроса по адресу /api/v1/auth [400] Запрос не может быть исполнен. {"error_code":"api.authentication.error","error_description":"Ошибка при выполнении операции: Проверьте аутентификационные данные"}
Рис. 3. Выбор адреса API в настройках модуля МДЛП в базе 1С 8.

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

Нажатие на изображении увеличит его

Рис. 4. Значение адреса API после выбора значения «Промышленная система».

Оцените, помогло ли Вам предоставленное описание решения ошибки?



© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

20-09-2022

Журавлев А.С.
(Сайт azhur-c.ru)

Источник

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

Ошибка 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 34: Операция не может быть выполнена. Отправитель сведений и владелец SGTIN/SSCC не совпадают.

Причина ошибки:

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

Ошибка 2

Текст ошибки: error_desc 2: Указанная сущность не может быть идентифицирована (не зарегистрирована).

Причина ошибки:
Указанные в документе данные не существуют на текущий момент в МДЛП. 
Наиболее часто ошибка может возникать в документах розничной продажи (10531). В данном случае необходимо открыть сам документ и проверить дату в поле operation_date. Если указана старая дата за 2020-2022 года, то это означает, что документ сформирован автоматически, на основании чека от указанной даты. Причиной является работа нового механизма для поиска чеков из-за некорректной настройки контрольно-кассовой техники, сведения о которых могли не попасть в систему своевременно.
Если SGTIN имеет статус «Продан в розницу», а также может быть переведён в архив, то беспокоиться об ошибке в документе не стоит. SGTIN будет считаться выбывшим и дополнительных действий по нему не требуется.
Если SGTIN будет иметь статус «Продан в розницу с отклонением от требований реализации ЛП», то это означает, что в момент вывода из оборота были допущены ошибки (продан до принятия на баланс, реализован по истечению срока годности и т.д.). За более подробными причинами, можно будет обратиться в службу технической поддержки. При этом SGTIN будет уже считаться выбывшим и не подлежит корректировке.

Ошибка 1000

Текст ошибки: error_desc 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»

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

Причина ошибки: Не указан ИНН или указан не верный ИНН в документе.

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

Причина ошибки: Тэги в документе разорваны или имеются в документе лишние символы, которые нарушают размещение элементов.

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

Причина ошибки: Указаны несколько раз SGTIN в документе. Требуется удалить дубликат SGTIN из документа.

Текст ошибки: error_desc 1000: Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Указанный идентификатор организации (subject_id) в документе не соответствует отправителю.

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

Текст ошибки: error_desc 1000: Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: 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, но сам КПП не заполнен или не соответствует формату КПП.

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

Причина ошибки: Имеются нарушения тегов. Отсутствуют лишние теги или нет закрывающих тегов.

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

Причина ошибки: Нарушена структура тегов. Отсутствуют закрывающие теги.

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

Причина ошибки: в теге с указанием sgtin присутствует пробел.

Текст ошибки: error_desc 1000: Обработка запроса провалилась: ошибка на этапе первичной обработки документа: Некорректный документ: 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 символов.

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

Причина ошибки: в документе присутствуют недопустимые символы, которые, в том числе могут быть скрытыми символами-разделителями.

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

Причина ошибки: нарушение формирования тегов. Присутствуют лишние или отсутствуют закрывающие теги.

Источник

Компания «ЦРПТ» поясняет сложные моменты работы с системой маркировки в аптеках и ЛПУ

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

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

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

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

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

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

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

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

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

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

Еще одно средство разрешения нештатных ситуаций — обращение в службу поддержки по адресу [email protected] или телефону 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 и далее не делали разагрегацию группового кода, то вы можете так настроить свою товарно-учетную систему. Запрета на это нет.

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

Источник

  • При разборе входящего сообщения мдлп возникла ошибка значение не является значением объектного типа
  • При разблокировки загрузчика xiaomi выдает ошибку
  • При разархивировании выдает ошибку архив поврежден
  • При разархивации ошибка контрольной суммы
  • При работе формы произошла системная ошибка нарушена синхронизация состояния формы на клиенте