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

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

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

В наличии

Первичное взаимодействие с ФГИС МДЛП — Федеральной государственной информационной системой мониторинга движения лекарственных препаратов от производителя до конечного потребителя с использованием маркировки в аптечной сети на 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/XHLSchemainstance" 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 (//sale.itcity.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) поставщик сам будет присылать значение МОД в электронной накладной. Первый способ, скорее всего не рабочий, так как МОД придется выбирать случайным образом, из всего множества, а смысл Честного знака состоит именно в том, чтобы проследить РЕАЛЬНУЮ цепочку движения лекарственного препарата. Так что, думается, поставщиков просто обяжут присылать значение МОД конечному розничному продавцу лекарственного препарата в электронной накладной (нам правда пока никто не присылает).

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

has been added to your cart:
Оформление заказа