Первичное взаимодействие с ФГИС МДЛП в аптечной сети на 1С 7.7 (для "чайников"!)

03.03.20

Интеграция - Обмен с ГосИС

Первичное взаимодействие с ФГИС МДЛП - Федеральной государственной информационной системой мониторинга движения лекарственных препаратов от производителя до конечного потребителя с использованием маркировки в аптечной сети на 1С 7.7 (для «чайников»!).

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

Итак, на первом этапе Вы должны зарегистрировать Вашу организацию и ip-адрес(а), с которого (ых) будете подключаться к ФГИС МДЛП. Для этого надо было писать письмо с техподдержку Честного Знака (ЧЗ). Думаю этот этап расписывать не нужно, так как на сегодняшний момент все субъекты системы маркировки лекарственных средств в обязательном порядке должны быть зарегистрированы в ФГИС МДЛП. Следовательно, Ваша организация и ее ip-адрес (постоянный и белый) уже зарегистрированы в ФГИС МДЛП.

Итак, приступим в проверке. Все актуальные версии документов доступны по ссылке:  https://честныйзнак.рф/business/projects/medicines/#documents@for_developers

Там же имеется Краткая инструкция по быстрому старту для подключения к API (взаимодействие с ФГИС МДЛП происходит по API): https://честныйзнак.рф/upload/iblock/25b/Kratkaya_instruktsiya_po_bystromu_startu_dlya_izucheniya_API.pdf

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

Первый шаг: прописать в hosts операционной системы домен тестового стенда 185.196.171.27 api.stage.mdlp.crpt.ru

То есть отладка на первом этапе идет на тестовом стенде  и в «Песочнице», потом идет переход непосредственно на промышленный контур.

Далее устанавливаем Crypto Pro. Для тестирования насколько я помню можно получить временный бесплатный сертификат, потом в реальных условиях придется естественно покупать. Это все расписано подробно в инструкции, поэтому повторяться не буду.

Далее в инструкции предлагается

Шаг 1. Авторизация тестовым участником

На тестовом стенде API необходимо авторизоваться тестовым участником и получить «Код аутентификации», используя метод API

POST http://api.stage.mdlp.crpt.ru/api/v1/auth

Content-Type: application/json;charset=UTF-8

{

"client_id": "01db16f2-9a4e-4d9f-b5e8-c68f12566fd5",

"client_secret":"9199fe04-42c3-4e81-83b5-120eb5f129f2",

"user_id":"starter_resident_1",

"auth_type":"PASSWORD" }

Ответ:

     {"code": "7386a68f-c1e5-42c6-8ed5-5b933017c66c" }

 

Этот код будет запускаться в ПО (самописном или покупном), которое Вы будете использовать для автоматизации подключения к ЧЗ. Но в данном случае нас интересует – как протестировать подключение к ЧЗ без установки специального ПО. Для этого используется обычный браузер. Заранее отмечу, рекомендую скачать chromium-gost, так как только он сможет работать с ЧЗ по https, ни один другой браузер с любым расширением не сможет этого.

Хотя на самом первом этапе https даже не понадобится, потому что просто обращение происходит по http.  Далее устанавливаем соответствующий API клиент, к примеру, Advanced REST client

Итак, в данном клиенте, заполняем headers и body

 

Примечание: здесь и далее в url добавляется sb, это означает песочницу: 

Как я понимаю, изначально должен был быть такой порядок: тестовый стенд -> песочница -> промышленный контур.

Но тестовый стенд можно уже исключить и сразу начинать в песочнице.

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

В свое время долго бился над тем, откуда же брать client_id и client_secret. В тестовом примере они готовые, уже сгенерированные, а где брать реальные – вот вопрос. Сначала думал, что их должен прислать ЧЗ на почту, потом – что их надо сгенерировать опять таки через API ЧЗ. Но тогда не хватало других вводных, которые в свою очередь не могли быть получены без client_id и client_secret. Все оказалось намного проще - брать client_id и client_secret нужно просто скопировать в личном кабинете (ЛК) ЧЗ.

Для этого заходим на сайт ЧЗ с помощью усиленной квалифицированной электронной подписи (УКЭП):

 

Логинимся по УКЭП, заходим в Администрирование

Далее выбираем учетную систему и вуаля, client_id – это соответственно Идентификатор клиента, а client_secret – Секретный код

User_id – это отпечаток сертификата из Крипто Про

Итак, нажимаем кнопку Send, получаем ответ:

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

POST http://api.stage.mdlp.crpt.ru/api/v1/token

Content-Type: application/json;charset=UTF-8

{

"code": "7386a68f-c1e5-42c6-8ed5-5b933017c66c",

"password": "password"

}

Ответ:

{

"token": "13b5b046-0cd7-4e1c-8409-da9541986d1c",

"life_time": 30

}

В ответе на запрос приходит ключ сессии (token, всегда разный) и время его жизни (life_time).

 

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

Далее запускаем cmd и переходим в папку, где установлен Crypto Pro.

Запускаем соответствующую команду из инструкции

csptest -sfsign -sign -in C:\ЧЗ\Code.txt -out C:\ЧЗ\Signature.txt -my "Имя сертификата" -detached -base64 –add

Открываем полученный файл в Notepad ++ и заменяем конец строки, как указано в регламенте:

 

Получаем сигнатуру, которую вставляем в тело запроса:

Отправляем запрос, получаем токен, время действия которого – 30 минут

Далее с этим токеном можно делать все операции, предусмотренные в системе – отправка,  получение документов, просмотр информации, добавление пользователей, контрагентов и прочее. Все это указано в инструкции. Там есть пример оправки документа в формате xml, например, в блокноте необходимо создать файл с расширением txt. Например, doc.txt. В текстовый файл вставить тело документа:

<documents xmlns:xsi="http://www.w3.org/2001/XHLSchema-instance" version="1.19">

  <register_end_packing action_id="311">

    <subject_id>00000000000517</subject_id>

    <operation_date>2018-08-22T15:00:00+05:00</operation_date>

    <order_type>l</order_type>

    <series_number>100000001</series_number>

    <expiration_date>30.03.2020</expiration_date>

    <gtin>11170012610151</gtin>

    <tnved_code>3004</tnved_code>

    <signs>

      <signs>07091900400001TRANSF2000021</signs>

    </signs>

 </register_end_packing>

</documents>

Далее сохраняем в txt и подписываем как на предыдущем этапе:

csptest -sfsign -sign -in C:\ЧЗ\doc.txt -out C:\ЧЗ\signed_doc.txt -my "Имя сертификата" -detached -base64 –add

Исходя из примера на выходе будет получен файл signed_doc.txt, в котором будет указана сигнатура подписи. В сигнатуре подписи необходимо удалить символы переноса строк. Полученную сигнатуру подписи использовать для отправки документа. Переводим тело документа в Base64:

PGRvY3VtZW50cyB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB2ZXJzaW9uPSIxLjE5Ij48cmVnaXN0ZXJfZW5kX3BhY2tpbmcgYWN0aW9uX2lkPSIzMTEiPjxzdWJqZWN0X2lkPjAwMDAwMDAwMDAwNTE3PC9zdWJqZWN0X2lkPg==

Параметр request_id – это сгенерированный GUID, например, тут:

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

Поэтому приведу схему товаро и документооборота в нашей фирме (аптечная сеть в глубинке, юридически у нас 2 ООО, физически - более 10 аптек). Итак, у нас есть подобие ЦС (центральный склад), куда часть поставщиков привозит товар, но часть везут напрямую по аптекам

Это к вопросу о том, что физически сканирование GTIN-ов будет точно по аптекам, а не на ЦС. Теперь сам документооборот. В офисе на ЦС сидят операторы, которые приходуют накладные от поставщиков в 1С 7.7 и делают выписки - сборную солянку от нескольких поставщиков в одном электронном документе - по аптекам. Эти выписки кидаются на фтп-шник, откуда потом заведующие аптек их скачивают и приходуют в аптечном ПО (самописное на Delphi).

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

Это на первом этапе. Потом вроде как начальство планирует, чтобы все аптеки отправляли информацию в МДЛП самостоятельно. Поэтому возникла такая мысль (которая была изначально) - отправлять данные по приходу централизованно, но с помощью внешнего готового решения, например: Маркировка: обмен с ГИС МДЛП из 1С 7.7 (//infostart.ru/public/1147679)

Если удастся интегрировать его в нашу 1С 7.7 было бы, на мой взгляд, идеально. И к тому же значительно бы упростился этап сверки - все ли GTIN-ы прислали обратно аптеки.

Если делать в Delphi то будет ужасный геморрой с обратной сверкой - оператором придется глазами смотреть что мы отправили по аптекам и все ли отсканированные GTIN-ы они прислали нам обратно. А если удастся интегрировать представленное выше решение, то все замкнется на 1С 7.7 и можно будет намного проще сверять - что мы послали аптекам и что они прислали нам обратно. И дополнительно снимется огромный пласт работы, связанной непосредственно с программированием отправки данных по приходу в МДЛП.

Но есть и некоторый минус - централизованная отправка из офиса. Вроде везде пишут, что это разрешено ЧЗ,  но весь вопрос - постоянно или временно.

Теперь что касается видов необходимых документов. Форматы и примеры есть на сайте ЧЗ. Далее рассмотрим наиболее распространенную операцию – акцепт прихода товара от поставщика. Непосредственно продажу товара на кассе рассматривать не будем, потом что предполагается, что GTIN-ы непосредственно при продаже лекарственных средств будут отправляться оператору ОФД (например, Ярус), который в свою очередь бесплатно или за отдельную плату будет отправлять их уже в ЧЗ. То есть непосредственно отслеживание продажи маркированной продукции должно быть в теории переложено на операторов ОФД.

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

Итак, предусмотрен прямой и обратный акцепт товара от поставщика, соответственно 415 и 416 схемы. Первая схема – прямой акцепт, когда поставщик (как правило, крупный фармдистрибьютор – Катрен, Пульс и прочие) самостоятельно инициирует цепочку обращения в ЧЗ, отправляя в систему информацию о поставленной Вашей аптечной сети маркированной продукции.

Однако на сегодняшний момент есть слухи, что лишь небольшая часть фармдистрибьюторов планирует работать с аптечными сетями по прямой схеме. Поэтому наиболее распространенной, видимо, будет обратная (416-ая) схема, когда сама аптечная четь будет инициировать обращение в ЧЗ, а фармдистрибьютор будет подтверждать или не подтверждать поставку.

Вот пример файла для ЧЗ по 416-ой схеме:

<?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">

            <receive_order action_id="416">

                        <subject_id>19527400000028</subject_id>

                        <shipper_id>19527400000005</shipper_id>

                        <operation_date>2017-10-26T15:02:00+05:00</operation_date>

                        <doc_num>dok 1</doc_num>

                        <doc_date>27.10.2017</doc_date>            

                        <receive_type>1</receive_type>

        <source>1</source>

                        <contract_type>1</contract_type>

                        <order_details>

                                   <union>

                                               <sgtin>11670012610151RPN906FGKMVBG</sgtin>

                                               <cost>123.20</cost>

                                               <vat_value>54</vat_value>

                                   </union>

                                   <union>

                                               <sgtin>11670012610151F4NQ3H6V5PD47</sgtin>

                                               <cost>123.20</cost>

                                               <vat_value>54</vat_value>

                                   </union>

                                   <union>

                                               <sgtin>1167001261015175FFBRHCS96LF</sgtin>

                                               <cost>123.20</cost>

                                               <vat_value>54</vat_value>

                                   </union>

                                   <union>

                                               <sgtin>116700126101515YMT254E7IH2B</sgtin>

                                               <cost>123.20</cost>

                                               <vat_value>54</vat_value>

                                   </union>

                        </order_details>

            </receive_order>

</documents>

 

Как можно видеть, все более, чем понятно. Единственный вопрос, который возник у меня в свое время – параметр <shipper_id>

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

Есть два способа получения значения МОД: 1) самостоятельно, путем обращения к системе МДЛП по ИНН контрагента, 2) поставщик сам будет присылать значение МОД в электронной накладной. Первый способ, скорее всего не рабочий, так как МОД придется выбирать случайным образом, из всего множества, а смысл Честного знака состоит именно в том, чтобы проследить РЕАЛЬНУЮ цепочку движения лекарственного препарата. Так что, думается, поставщиков просто обяжут присылать значение МОД конечному розничному продавцу лекарственного препарата в электронной накладной (нам правда пока никто не присылает).

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

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

См. также

Оптовая торговля Розничная торговля ККМ ЭДО и ОФД Обмен с ГосИС Системный администратор Программист Оперативный учет 7.7 Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Россия Платные (руб)

Подключение фискального регистратора к 1С 7.7 в режиме онлайн-кассы (в соответствии с 54-ФЗ). Поддержка крайних версий драйверов ККТ: ДТО 10 и ДТО 8 для Атол, 4.15, 5.16 для Штрих-М. Поддержка протоколов ФФД 1.0, 1.05, 1.1 и 1.2, развитые настройки для применения частичных оплат и авансов в оптовой и розничной торговле. Поддержка чеков коррекции всех версий. Поддержка розничной продажи маркированной продукции (ЕГАИС, табак, обувь, лекарства, шины, одежда, белье, парфюмерия, молочная продукция, вода и пр.). Вывод электронного чека (на е-майл, телефон) по требованию покупателя, поддерживаются комбинированные типы оплаты, режим эмуляции печати чека на ФР. Полный цикл работы из 1С 7.7 с маркировкой Честный ЗНАК (ГИСМТ, ЦРПТ) из 1С 7.7. ЭДО (табак, обувь, шины, одежда, молочная продукция, вода и прочие группы товаров) для розницы и опта (приемка и оптовая отгрузка маркированной продукции). Поддерживается как объемно-сортовой учет (ОСУ) так и поштучный (поэкземплярный) учет.

2000 руб.

28.03.2017    476141    4393    3478    

2446

Оптовая торговля Производство готовой продукции (работ, услуг) Розничная торговля Обмен с ГосИС Программист Бухгалтер Оперативный учет 7.7 Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 1С:Упрощенное налогообложение 7.7 Сельское хозяйство и рыболовство Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Рестораны, кафе и фаст-фуд Пищевая промышленность Россия Бухгалтерский учет Управленческий учет Платные (руб)

Полностью автоматизированный обмен между конфигурациями 1С 7.7 и ФГИС Меркурий через Ветис.API для всех видов деятельности (Опт, Розница, Производство). Для организации обмена с ФГИС Меркурий требуется минимальная доработка конфигураций (поддерживается "из коробки" 1С: "Торговля и склад ред. 9.2", 1С: "Комплексная ред. 4.5", 1С: "Бухгалтерия 7.7", 1С: "УСН 7.7", 1С Предприниматель, другие конфигурации по заказу, включая нетиповые и самописные). Модуль разработан таким образом, чтобы минимизировать затраты по внедрению в произвольную конфигурацию на базе 1С 7.7. Вы можете БЕСПЛАТНО скачать демо-версию без ограничения по функционалу и опробовать решение в полном объеме перед покупкой. В данном программном продукте реализованы все технические требования Россельхознадзора по обмену в формате 2.0 и 2.1. Решение прошло опытную эксплуатацию и тестирование на крупных объектах всех видов деятельности: Производство, Опт, Розница.

10000 руб.

21.11.2018    53857    156    105    

70

Обмен с ГосИС Программист Платформа 1С v7.7 Платформа 1С v8.3 1С:Управление торговлей 10 Россия Абонемент ($m)

Уже с 01.04.2024 вводится так называемый "разрешительный" режим продажи маркированной продукции в розницу. Это значит, что перед продажей нужно запрашивать у сервиса ЦРПТ разрешение на реализацию каждой марки. Здесь кратко опишу, как это делается, и приложу примеры для 1С 8 и 7.7.

1 стартмани

15.03.2024    7658    87    kirlog    85    

25

Обмен с ГосИС Программист Платформа 1С v7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Ювелирная промышленность и торговля Россия Бухгалтерский учет Абонемент ($m)

Интеграция 1С 7.7 с ГИИС ДМДК (маркировка ювелирных изделий и драгоценных камней). Данная публикация является попыткой выяснения спроса на полноценную интеграцию конфигураций на базе платформы 1С 7.7 с ГИИС ДМДК (https://dmdk.ru/). На текущий момент реализована печать ценников-бирок, содержащие УИН продукции в формате ШК Datamatrix. Имеются планы разработки решения для учета розничных продаж через УТМ (Универсальный Транспортный Модуль) из 1С 7.7.

1 стартмани

01.03.2022    5923    1    victuan    0    

17

Обмен с ГосИС Программист Платформа 1С v7.7 Конфигурации 1cv7 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Россия Абонемент ($m)

Конец 2021 и начало 2022 года принесло много увлекательной работы в связи с переходом на ГИИС ДМДК. Все движения драгоценных металлов и камней должны отражаться в ГИИС. Для этого есть два пути: ручной ввод или интеграция существующей учетной системы с ГИИС. Ручной ввод не подходит тем организациям, которые имеют большое количество движений, а интеграция слишком дорога для небольших магазинчиков. Но самое неприятное в том, что в настоящий момент для интеграции требуется обезличенная ЭЦП, а выдавать ее никто не может или не имеет права. Это и привело меня к разработке продукта, который бы позволил автоматизировать часть работы с помощью эмуляции действий пользователя в личном кабинете.

1 стартмани

04.02.2022    5082    0    aldan    0    

3

ККМ Обмен с ГосИС Бухгалтер Пользователь Оперативный учет 7.7 1С:Торговля и склад 7.7 Розничная и сетевая торговля (FMCG) Россия Бухгалтерский учет Управленческий учет Абонемент ($m)

Обработка для загрузки базы кодов цен в ККТ "Меркурий" с помощью программы-конфигуратора MercConfig из базы Торговля и склад 9.2 1С: Предприятие 7.7.

1 стартмани

25.01.2021    8688    1    aleksandr_leiman    0    

2
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. vSAD 05.05.20 17:08 Сейчас в теме
Здравствуйте, как думаете решать проблему с групповыми кодами упаковки от производителя? Сканировать каждую SGTIN при поставках? и уповать на то что фармацевт разглядит что на коробке есть штрихкод ( а они то обычно есть и как сообразить что он нужный) и отсканирует его тоже.
2. link.tmb 12.08.20 17:26 Сейчас в теме
(1) Может уже неактуально, но фармацевту придется отсканировать SSCC (либо как-то его программно вытаскивать из системы) и по нему принимать товар. При попытке выполнения любой операции над SGTIN, который агрегирован в SSCC система выдаст ошибку.
3. starvg 26.10.20 07:32 Сейчас в теме
А РВ вы в своей сети используете?
4. ip0593 20 08.11.20 21:30 Сейчас в теме
можно ли как-то отправить киз через api и получить ответ, за кем они числиться?
5. hazyaka 03.08.22 12:50 Сейчас в теме
С вами можно пообщаться?
Оставьте свое сообщение