Confluence Mobile
ПЕРЕЧЕНЬ СХЕМ ЛОГИЧЕСКОЙ МОДЕЛИ ФАЙЛОВ ОБМЕНА ФГИС МДЛП
Схема 417 в Честном знаке используется для возврата поставщику недоброкачественных лекарственных препаратов, которые были:
Особенности движения приостановленных SGTINПриостановленные лекарственные препараты необходимо вернуть поставщику по схеме 417. Реализация их конечному потребителю будет считаться нарушением.
Схема 417 позволяет также выполнять возврат в составе SSCC, но рекомендуется осуществлять возврат именно списком SGTIN.
В случае, если загрузка схемы 417 отклоняется, то рекомендуется проконсультироваться о причинах ошибки у службы технической поддержки. В качестве альтернативы, допускается принятие на баланс приостановленных ЛП через схему 702 и с типом 2 (возврат).
Приостановленные SGTIN могут быть также списаны по схеме 552, либо переданы на уничтожение (схема 541), с последующим уничтожением (542).
Выполнение схемы 417 допускается с заблокированных мест деятельности.
Информация о выводе из оборота лекарственных препаратов поступает в ФГИС МДЛП в автоматическом режиме посредством функционала регистратора выбытия. В случае осуществления частичного использования упаковки вакцины для профилактики новой коронавирусной инфекции в товарно-учетной системе медицинской организации (при использовании регистратора выбытия в “сетевом режиме”) или в регистраторе выбытия (при использовании регистратора выбытия в “автономном” режиме) необходимо отразить сведения о долях содержимого упаковки вакцины (дозах), использованных для вакцинации с применением схемы 10531 логической модели файлов обмена ФГИС МДЛП. Неиспользованные дозы вакцины подлежат выводу из оборота с применением схемы 552 логической модели файлов обмена ФГИС МДЛП.
Передача сведений о частичном или полном использовании упаковок вакцины, выведенной из оборота обособленными подразделениями медицинской организации (кабинетами вакцинации, мобильными пунктами вакцинации), не оснащенными регистраторами выбытия, в ФГИС МДЛП осуществляется ответственными сотрудниками головной медицинской организации. Сообщения формируются на основании отчетности обособленного подразделения медицинской организации, содержащей информацию об упаковках вакцины, использованных в ходе вакцинации.
Информация о частично или полностью выведенных из оборота упаковок вакцины может быть также передана сотрудниками обособленных подразделений медицинской организации с помощью мобильного приложения “Фарма.Просто”, установленного на смартфоне.
Перейти в текст документа »
Больше документов и разъяснений по антикризисным мерам – в системе КонсультантПлюс.
Зарегистрируйся и получи пробный доступ
Дата публикации на сайте: 18.02.2021
Уведомления в личный кабинет МДЛП («Реестр документов» — «Входящиие») и в тораро-учётный системы поступают после операции, ниже описанных в списке:
39.
umbra777
Сейчас в теме
Добрый день, Владимир! Возник вопрос использования готовой системы для обмена с МДЛП, так как нет уверенности, что получится реализовать
своими силами. Опишу схему товаро и документооборота в нашей фирме (аптечная сеть в глубинке, юридически у нас 2 ООО, физически – более 10
аптек). У нас есть подобие ЦС (центральный склад), куда часть поставщиков привозит товар, но часть везут напрямую по аптекам/ Это к вопросу о том, что физически сканирование GTIN-ов будет точно по аптекам, а не на ЦС
Теперь сам документооборот. В офисе на ЦС сидят операторы, которые приходуют накладные от поставщиков в 1С 7.7 и делают выписки – сборную солянку от нескольких поставщиков в одном электронном документе – по аптекам
Эти выписки кидаются на фтп-шник, откуда потом заведующие аптек их скачивает и приходуют в аптечном ПО (самописное на Delphi)
Так вот, вопрос стоит так – оставаться ли на своем ПО или переходить наконец на готовое с поддержкой МДЛП типа ИнфоАптеки Переходить начальство естественно не горит желанием, так как допрасходы. Итак надрываемся в неравной борьбе с федералами, закрываем одну точку за другой, срезали 13-ю зарплату всем и все такое.
Пока решили допиливать свое ПО и работать по такой схеме: аптеки как обычно приходуют товар, сканируют GTIN-ы и отправляют нам их обратно на ФТП. Мы в офисе грузим GTIN-ы со всех аптек, делаем обратную разбивку по поставщикам и соответственно отправляем в МДЛП через свое самописное ПО централизованно из офиса. Это на первом этапе. Потом вроде как начальство планирует, чтобы все аптеки отправляли инфу самостоятельно, опять же через наше самописное ПО
Но возникли сомнения, сможем ли все это реализовать своими силами. А с 01.07.2020 права на ошибку получается уже нет. Поэтому возникла такая мысль (которая была изначально) – отправлять данные по приходу централизованно, но с помощью внешнего готового решения. Например вашего
Если удастся интегрировать его в нашу 1С 7.7 (Бухгалтерский учет, но очень переписанная и поэтому давно не обновлявшаяся – 7.70.446) было бы на мой взгляд идеально. И к тому же значительно бы упростился этап сверки – все ли GTIN-ы прислали обратно аптеки. Если делать в Delphi то будет ужасный гемор с обратной сверкой – оператором придется глазами смотреть что мы отправили по аптекам и все ли отсканированные GTIN-ы они
прислали нам обратно. А если удастся интегрировать ваше решение, то все замкнется на 1С 7.7 и можно будет намного проще сверять – что мы послали аптекам и что они прислали нам обратно. И дополнительно снимется огромный пласт работы, связанной непосредственно с программированием отправки данных по приходу в МДЛП
Но есть очень большой минус – централизованная отправка из офиса. Вроде писали, что это разрешено ЧЗ. Но весь вопрос – постоянно или временно? Есть ли у вас достоверная инфа по этому поводу? И самое главное – есть уверенность, что в итоге вы допилите свою конфигу до полностью работоспобного состояния и будете регулярно выпускать нужные обновления? Мы за ценой не постоим и оплачивали бы все обновления отдельно, лишь бы была 100% уверенность, что ваше решение будет работоспособным и регулярно поддерживаться.
Вывод из оборота лекарственных препаратов для оказания медицинской помощи осуществляется с использованием регистратора выбытия.
Информация о выводе из оборота таких лекарственных препаратов поступает в ФГИС МДЛП в автоматическом режиме посредством функционала регистратора выбытия (схема 10531 логической модели файлов обмена ФГИС МДЛП).
Для осуществления частичного выбытия лекарственных препаратов для оказания медицинской помощи в товарно-учетной системе (при использовании регистратора выбытия в “сетевом режиме”) субъекта обращения лекарственных средств или в регистраторе выбытия (при использовании регистратора выбытия в “автономном” режиме) необходимо ввести долю упаковки лекарственного препарата. Вторичная упаковка лекарственного препарата сохраняется до момента отпуска последней доли вторичной упаковки. Товарно-учетная система (или регистратор выбытия) должны обеспечивать проверку количества ранее выведенных из оборота долей и блокировать выбытие “излишков”, выводя соответствующее уведомление.
В случае обнаружения попытки осуществить вывод из оборота “излишка”, ФГИС МДЛП осуществит вывод ЛП из оборота, при этом будет зафиксировано нарушение, и соответствующая информация будет направлена в надзорный орган (Росздравнадзор).
Алгоритм действий сотрудника медицинской организации при использовании им регистратора выбытия всегда одинаков и не зависит от способа его подключения.
1. Сотрудник получает или создает документ-основание для регистрации вывода лекарственного препарата из оборота. Это может быть требование-накладная, акт списания при использовании для оказания медицинской помощи или любой другой документ в соответствии с внутренней учетной политикой участника оборота.
2. Сотрудник подбирает упаковки препаратов в соответствии с документом-основанием и сканирует коды маркировки DataMatrix. Если при этом используется товарно-учетная система, интегрированная с ФГИС МДЛП и регистратором выбытия, то сотрудник может сразу видеть на экране компьютера информацию о данном лекарственном препарате и о том, может ли данный препарат быть выведен из оборота. Регистратор выбытия при сканировании кодов маркировки DataMatrix при успешном распознавании кода маркировки, нанесенного на упаковку
3. лекарственного препарата, выводит на экран наименование лекарственного препарата.
4. Завершив подбор, сотрудник выбирает действие
5. “Зарегистрировать выбытие” на регистраторе выбытия. Если не используется товарно-учетная система, на дисплее устройства будет выведено сообщение о необходимости ввода номера и даты документа-основания перед отправкой сведений.
6. В случае частичного выбытия вторичной упаковки из оборота, соответствующая информация о количестве долей лекарственного препарата указывается в регистраторе выбытия или в товарно-учетной системе участника. При этом вторичная упаковка сохраняется до момента выбытия последней первичной упаковки.
Поддерживаемые схемы МДЛП
Отправляются в МДЛП, с указанием соответствия с документами конфигурации:
Загружаются из МДЛП, с указанием соответствия с документами конфигурации:
Публикация № 1556445
– Логистика, склад и ТМЦ
Исправление ошибки с получением квитанции о перемещении МДЛП (“Мониторинг движения лекарственных препаратов для медицинского применения от производителя до конечного потребителя”).
На днях обновили систему МДЛП, но каким-то образом новый вид сообщения 629 (уведомление о перемещении) попал в схему 1.36.
Хотя его анонсировали на 1.37
Ситуация получается такая, что все решения на базе 1С:Бибилиотека МДЛП не видят успешную квитанцию по 431 сообщению, а видят новое уведомление 629.
Что делать? Самым экстренным способом исправить ситуацию это сказать системе что 629 сообщение было как 627 – это которое формируется по 702 сообщению.
Это не решение проблемы, но это позволит продолжит работать пока не выпустят обновление или пока не скроют в схеме 1.36 уведомление 629.
Создаем расширение, с видом исправление.
На функции КодыОперацийУведомленияОбОприходовании – делаем добавить в расширение – изменение и контроль.
&ИзменениеИКонтроль(“КодыОперацийУведомленияОбОприходовании”)
Функция Расш1_КодыОперацийУведомленияОбОприходовании()
КодыОперацийУведомленияОбОприходовании = Новый Массив;
КодыОперацийУведомленияОбОприходовании.Добавить(627);
КодыОперацийУведомленияОбОприходовании.Добавить(628);
#Вставка
КодыОперацийУведомленияОбОприходовании.Добавить(629);
#КонецВставки
Возврат КодыОперацийУведомленияОбОприходовании;
КонецФункции
Подключение стандартное согласно документации “Руководство разработчика” Глава 36. Расширение конфигурации
или “Управление расширениями конфигурации”
После подключения расширения, уведомления перестанут мешать загрузке ответа по 431 сообщению.
Скачать файлы
1.
Evgen13
Сейчас в теме
Сделал все как описано, но квитанцию о перемещении не получает(
3.
Vladimir45
Сейчас в теме
(1) день перезагрузите весь.
5.
Evgen13
Сейчас в теме
2.
Evgen13
Сейчас в теме
В МДЛП такая же схема осталась при перемещении
4.
maloy-v
Сейчас в теме
я даже так скажу: если понизиться до версии схем 1.35, то в ответ на схему 431, всё равно, прилетает схема 629.
Мы подготовили ответ на Ваше обращение: В рамках релиза 4.42 было произведено обновление версии XSD-схем до 1.37.
Комплект схем 1.37 и обновленные бизнес-процессы обратно совместимы с актуальной версией схем 1.36.
Ваши документы был поданы через товароучетную систему с версией схемы 1.36.
629 уведомление также вернулось с версией 1.36.
Со стороны системы МДЛП документы прошли корректно. За информацией по Вашей товароучетной системе и ее обновлению необходимо обратиться к Вашему разработчику.
6.
Vladimir45
Сейчас в теме
Ответ огонь!
Давайте перефразирую чтоб было понятнее:
Ваши документы был поданы через товароучетную систему с версией схемы 1.36, и мы решили уведомление из схемы 1.37 отправить вам обратно в схеме 1.36, по которой это сообщение не предусмотрено. И считаем это корректным.
Просим вас обратится к разработчику вашей ТУС, который обновит Вашу ТУС и добавит уведомление 629 по схеме 1.36 которой нет в документации и она не предусмотрена схемой 1.36.
Мы считаем что корректно нарушить спецификации Оператора МДЛП, и внести изменения в ТУС не соответствующие документации.
Сотрудники оператора – обратите внимание, это чо за подстава?
7.
gmkushkunov
Сейчас в теме
Спасибо большое!
Помогло. Документы перемещения ушли.
8.
DemonMax45
Сейчас в теме
Спасибо помогло, но только с обычными перемещениями. С перемещениями ГЛО не помогло
9.
DemonMax45
Сейчас в теме
Существует 4 типа передачи лекарств от одного участника к другому:
Виды источников финансирования (source)
Если указан вид финансирования 2 при получении лекарственных препаратов на склад, то дальнейшая отгрузка будет недоступна для дальнейшей продажи и не может использоваться другой вид источников финансирования.Виды операции приёмки (turnover_type)
В случае возврата (receive_type = 2), допускается операция 415, при условии, что лекарственные препараты были направлены изначально 415-ым документом.
Если при этом получение было в коробах, но по ним были изъятия (913), докладки (914) или расформирование (912) и новая агрегация (911, 915) тем же составом, то операция завершится отказом. Короба уже будут считаться другими при возврате.
В данном случае возврат по 415-му документу с receive_type = 2 может производиться россыпью.Расшифровка всех параметров
Честный знак фиксирует движение лекарственных препаратов по разным схемам. Выбор зависит от вида операции. Для каждой схемы в СБИС реализован документ.
МДЛП может запросить у участника оборота сведения о кодах маркировки по определенной схеме.
Нашли неточность? Выделите текст с ошибкой и нажмите ctrl + enter.
Агрегирование – процесс объединения субъектом обращения лекарственных средств упаковок лекарственных препаратов на любом этапе обращения лекарственных препаратов в групповую упаковку с нанесением соответствующего группового кода третичной (транспортной) упаковки лекарственных препаратов и с сохранением в ФГИС МДЛП информации о взаимосвязи средств идентификации, нанесенных на потребительские упаковки лекарственных препаратов (в случае отсутствия потребительских на первичных упаковках), с групповым кодом третичной (транспортной) упаковки лекарственных препаратов создаваемой групповой упаковки.
Агрегирование предполагает возможность наличия любого уровня вложенности упаковок:
– агрегирование первого уровня – объединение первичных и вторичных упаковок лекарственных препаратов в третичную (транспортную) упаковку;
– агрегирование второго уровня – объединение третичных (транспортных) упаковок в другую третичную (транспортную) упаковку вышестоящего уровня вложенности.
В целях обеспечения удобства работы с поставками ЛП производителям и дистрибьюторам лекарственных препаратов рекомендуется ограничиваться двумя уровнями вложенности: транспортный короб и паллета.
Также не рекомендуется наносить отдельный транспортный код SSCC на “спайку” упаковок (при агрегации 3 – 5 потребительских упаковок ЛП).
Агрегирование может выполняться субъектом обращения лекарственных средств на различных этапах производственного цикла и оборота лекарственных препаратов.
Для агрегирования участнику оборота необходимо выполнить следующие действия:
1. Удостовериться в том, что упаковки лекарственных препаратов, содержащие уникальные идентификаторы SGTIN, которые участник оборота планирует агрегировать, находятся по данным ФГИС МДЛП у него на балансе.
3. Агрегировать во множество транспортных упаковок и зарегистрировать в ФГИС МДЛП сведения об агрегировании во множество третичных (транспортных) упаковок (схема 915 логической модели файлов обмена ФГИС МДЛП), используя для передачи информации документ в формате xml. В поле “SSCC” xml-документа необходимо указать коды SSCC всех транспортных упаковок. В поле “SGTIN” xml-документа необходимо перечислить все уникальные идентификаторы упаковок лекарственных препаратов, которые были агрегированы в каждую транспортную упаковку.
4. Для агрегирования третичной упаковки первого уровня в третичную упаковку второго уровня и выше необходимо произвести аналогичные действия с указанием перечня агрегируемых упаковок SSCC.
Допускается дополнительное вложение потребительских упаковок лекарственных препаратов в третичную упаковку. Данная операция применяется как в случае доукомплектования третичной упаковки вторичными (потребительскими) и третичными упаковками лекарственных препаратов, так и в случае перемещения упаковок лекарственного препарата из одной третичной упаковки в другую.
Вложение упаковки лекарственного препарата может выполняться субъектом обращения лекарственных средств на различных этапах оборота лекарственных препаратов.
Для дополнительного вложения упаковок участнику оборота необходимо выполнить следующие действия:
1. Удостовериться в том, что упаковки лекарственных препаратов, содержащие уникальные идентификаторы SGTIN, которые участник оборота планирует вложить в транспортную упаковку, находятся по данным ФГИС МДЛП у него на балансе.
2. Доукомплектовать транспортную упаковку и зарегистрировать в ФГИС МДЛП сведения о дополнительном вложении упаковок в третичную (транспортную) упаковку (схема 914 логической модели файлов обмена ФГИС МДЛП), используя для передачи информации документ в формате xml. В поле “SSCC” xml-документа необходимо указать коды SSCC транспортной упаковки, в которую произошло вложение. В поле “SGTIN” xml-документа необходимо перечислить все уникальные идентификаторы упаковок лекарственных препаратов, которые были вложены в транспортную упаковку.
3. Для добавления третичной упаковки первого уровня в третичную упаковку второго уровня и выше необходимо произвести аналогичные действия с указанием перечня упаковок SSCC.
Изъятие – процедура извлечения лекарственных препаратов из третичной упаковки.
Изъятие упаковок лекарственных препаратов из третичной упаковки может выполняться субъектом обращения лекарственных средств на различных этапах оборота лекарственных препаратов.
Для изъятия упаковок лекарственных препаратов участнику оборота необходимо выполнить следующие действия:
1. Удостовериться в том, упаковки лекарственных препаратов, содержащие уникальные идентификаторы SGTIN, которые участник оборота планирует изъять из транспортной упаковки, находятся по данным ФГИС МДЛП у него на балансе.
2. Изъять упаковки лекарственных препаратов из транспортной упаковки и зарегистрировать в ФГИС МДЛП сведения об изъятии (схема 913 логической модели файлов обмена ФГИС МДЛП), используя для передачи информации документ в формате xml. В поле “SGTIN” xml-документа необходимо перечислить все уникальные идентификаторы упаковок лекарственных препаратов, которые были изъяты из транспортной упаковки.
3. Для изъятия третичной упаковки первого уровня из третичной упаковки второго уровня необходимо произвести аналогичные действия с указанием упаковки вышестоящей SSCC.
При наличии нескольких уровней вложенности транспортной упаковки изъятие упаковок ЛП необходимо осуществлять последовательно, для каждого из уровней, отражая каждую операцию в ФГИС МДЛП.
Запрещается отправлять в ФГИС МДЛП информацию об извлечении упаковок разной степени вложенности, используя один и тот же xml-документ (например, xml-документ, содержащий объединенную информацию об упаковках лекарственных препаратов, извлекаемых из коробки и паллеты).
В рамках выполнения одной операции нельзя извлекать SGTIN из разных групповых упаковок одного уровня, т.е. нельзя изъять SGTIN 1 из короба 1 и SGTIN 2 из короба 2 одной операцией.
Расформирование – процесс расформирования (уничтожения) одного, нескольких или всех уровней третичной упаковки до вторичных (потребительских) упаковок лекарственных препаратов.
Расформирование (уничтожение) третичных упаковок может выполняться участником оборота на различных этапах оборота товара.
Для расформирования транспортных упаковок участнику оборота необходимо выполнить следующие действия:
1. Удостовериться в том, что упаковки лекарственных препаратов, содержащие уникальные идентификаторы SGTIN и помещенные в транспортную упаковку, которую участник оборота планирует расформировать, находятся по данным ФГИС МДЛП у него на балансе.
2. Расформировать третичную упаковку и зарегистрировать в ФГИС МДЛП сведения о расформировании (схема 912 логической модели файлов обмена ФГИС МДЛП), используя для передачи информации документ в формате xml. В поле “SSCC” xml-документа необходимо указать код SSCC транспортной упаковки, которую требуется разагрегировать.
При наличии нескольких уровней вложенности транспортной упаковки допускается осуществлять расформирование от вышестоящего уровня к нижестоящему, отражая операцию для каждого из уровней в ФГИС МДЛП или, указав соответствующий тип расформирования в схеме 912 логической модели файлов обмена ФГИС МДЛП, сразу расформировать паллету до вторичной упаковки.
После успешного расформирования третичной упаковки ее номер (код SSCC) становится “свободным”, то есть доступным для последующего использования.
В случае необходимости проверки содержимого третичной упаковки необходимо:
– Использовать метод просмотра информации о существовании SSCC в Системе – /reestr/sscc/sscc_check;
– Использовать задачу получения аналитических данных sscc_hierarchy – Выгрузка иерархии по SGTIN;
– Использовать задачу получения аналитических данных number_sgtins_in_batches – Выгрузка информации о количестве SGTIN и их сериях в SSCC;
– использовать схему 210/220 логической модели файлов обмена ФГИС МДЛП. Xml-документ, направленный по данной схеме в ФГИС МДЛП, позволяет получить подробную информацию о SGTIN или SSCC.
По результатам успешной обработки запросов, ФГИС МДЛП возвращает участнику оборота информациюо результатах обработки сведений по запрашиваемому SGTIN/SSCC, подготовленный по формату обмена с ФГИС МДЛП.
Сроки передачи информации в ФГИС МДЛП: при расформировании третичной упаковки лекарственного препарата, изъятии лекарственных препаратов из третичной (транспортной) упаковки лекарственного препарата, дополнительном вложении лекарственных препаратов в третичную (транспортную) упаковку лекарственного препарата для лекарственных препаратов, находящихся на территории Российской Федерации, в 1 рабочего дня.
или для лекарственных препаратов, находящихся за пределами территории Российской Федерации, в течение 20 рабочих дней с даты соответствующей операции с лекарственными препаратами или третичной (транспортной) упаковкой лекарственного препарата.
Способ создать полноценный ТСД без мобильной разработки. Теперь новая версия – Simple UI (обновлено 14. 2019)
Промо
Оптовая торговля Готовая продукция, работы и услуги Розничная торговля Учет ОС и НМА Логистика, склад и ТМЦ Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Бухгалтерский учет Управленческий учет Абонемент ($m)
Путевые листы грузовых, легковых автомобилей, спец. автомобилей, строительной техники (v.
Учет рабочего времени Логистика, склад и ТМЦ Платформа 1С v8.3 Транспорт, автопарки, такси Россия Бухгалтерский учет Управленческий учет Абонемент ($m)
Это самостоятельная Конфигурация, используемая для учета и печати Путевых листов грузовых, легковых автомобилей, спец. автомобилей, строительной техники, тракторов.
Конфигурация может работать на любой версии платформы, начиная с 8.2 и выше.
Одним из достоинств является отличная скорость работы.
Очистка видов запасов
Обработка документов Готовая продукция, работы и услуги Логистика, склад и ТМЦ Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бухгалтерский учет Абонемент ($m)