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