Рекомендации по работе с API и документами ФГИС МДЛП (Версия 4.0)
Рекомендации по работе с API и документами ФГИС МДЛП
Версия 4.0
На 22 листах
Содержание
ИСТОРИЯ ИЗМЕНЕНИЙ
3
ПЕРЕЧЕНЬ ТЕРМИНОВ И СОКРАЩЕНИЙ
3
ОБЩИЕ РЕКОМЕНДАЦИИ ПО ИНТЕГРАЦИИ С API МДЛП
5
ЛИМИТЫ API МДЛП
6
РЕКОМЕНДАЦИИ ПО ПРОЦЕССУ РАБОТЫ С ДОКУМЕНТАМИ
7
ЗАПРОС НА ПОЛУЧЕНИЕ СТАТУСА ОБРАБОТКИ ИСХОДЯЩЕГО ДОКУМЕНТА
7
ЗАПРОС НА ПОЛУЧЕНИЕ КВИТАНЦИИ ПО ДОКУМЕНТУ
7
РАБОТА С МЕТОДАМИ ПОЛУЧЕНИЯ ИНФОРМАЦИИ ПО ОБЪЕКТАМ СИСТЕМЫ
SSCC/SGTIN
7
ОБЪЕМ СВЕДЕНИЙ, ПЕРЕДАВАЕМЫЙ В ДОКУМЕНТАХ
8
ИСПОЛЬЗОВАНИЕ СПИСКА ДОКУМЕНТОВ
8
ИСПОЛЬЗОВАНИЕ ФИЛЬТРОВ ДЛЯ ПОЛУЧЕНИЯ СПИСКА НЕОБХОДИМЫХ
ДОКУМЕНТОВ
9
ОПРЕДЕЛЕНИЕ ДОКУМЕНТОВ И КВИТАНЦИЙ ДОКУМЕНТОВ, НЕОБХОДИМЫХ К
СКАЧИВАНИЮ
9
ПОСТРОЕНИЕ ОЧЕРЕДИ ПРИОРИТЕТОВ НА СКАЧИВАНИЕ ДОКУМЕНТОВ
11
РАБОТА С ГРУППАМИ ДОКУМЕНТОВ
11
СВЯЗЬ МЕЖДУ ДОКУМЕНТОМ И ФОРМИРУЕМЫМ УВЕДОМЛЕНИЕМ
12
ПОЛУЧЕНИЕ СПИСКА НОВЫХ ДОКУМЕНТОВ
13
ЗАКЛЮЧЕНИЕ
14
ИСПОЛЬЗОВАНИЕ РЕЕСТРА ВРЕМЕННО ПРИОСТАНОВЛЕННЫХ
SGTIN
15
ИСПОЛЬЗОВАНИЕ АРХИВНОГО ХРАНИЛИЩА
16
РЕКОМЕНДАЦИИ ПО РАБОТЕ С УСТАРЕВШИМИ МЕТОДАМИ
17
ЭКРАНИРОВАНИЕ СПЕЦИАЛЬНЫХ СИМВОЛОВ
22
2
История изменений
Дата
Версия
Изменение
16.08.2021
4.0
Добавлен раздел «Лимиты API МДЛП»
02.08.2021
3.0
Добавлен раздел «Экранирование специальных символов».
Добавлена информация в раздел «Рекомендации по процессу
получения квитанций после обработки документов».
Добавлена информация в раздел «Работа с группами документов».
Добавлен
раздел
«Использование
реестра
временно
28.06.2021
2.0
приостановленных SGTIN».
Добавлен раздел «Использование архивного хранилища».
Добавлен раздел «Рекомендации по работе с устаревшими
методами».
22.12.2020
1.1
Опубликована обновленная версия документа
2020
1.0
Опубликована первая версия документа
Перечень терминов и сокращений
Термин/Сокращение
Определение/Расшифровка
Описание всех методов API МДЛП приведено в документе
«ИС «Маркировка». МДЛП. Протокол обмена
интерфейсного уровня. Документация по API», актуальная
Документация по API
версия которого расположена на официальном сайте
МДЛП
честныйзнак.рф в разделе «Лекарства» → «Документы для
работы в МДЛП» → «Разработчикам» → «Внешнее
взаимодействие с МДЛП»
КМ
Код маркировки
ЛК УОТ
Личный кабинет Участника
ЛП
Лекарственный препарат
РВ
Регистратор выбытия
РЭ
Регистратор эмиссии
ОФД
Оператор фискальных данных
Оператор информационной системы мониторинга -
юридическое лицо, зарегистрированное на территории
Российской Федерации, осуществляющее создание, развитие,
Оператор ЦРПТ
модернизацию и эксплуатацию информационной системы
мониторинга, обеспечение ее бесперебойного
функционирования, а также прием, хранение и обработку
сведений
3
Федеральная Государственная Информационная Система
ФГИС МДЛП
«Мониторинг движения лекарственных препаратов»
Товарно-учётная система - автоматизированная система
ТУС
контроля и учета движения товаров Участника,
интегрированная с ФГИС МДЛП
Усиленная квалифицированная электронная подпись - один из
видов электронной цифровой подписи. Формат
усовершенствованной подписи предусматривает включение в
УКЭП
электронную подпись информации о времени создания
подписи (TSP) и о статусе сертификата электронной подписи
(OCSP) в момент подписания (действителен или отозван)
Cубъект обращения лекарственных препаратов на территории
Российской Федерации:
• Российские производители ЛП;
• Иностранные держатели регистрационных
Участник оборота
удостоверений ЛП;
товаров, Участник, УОТ
• Представительства иностранных держателей
регистрационных удостоверений ЛП;
• Организации оптовой торговли ЛП;
• Организации розничной торговли ЛП;
• Медицинские организации.
Application Programming Interface - протокол обмена
API
интерфейсного уровня для получения доступа к сервисам
системы МДЛП вне ЛК УОТ
Serialized Global Trade Item Number - уникальный
идентификатор вторичной (потребительской) упаковки
лекарственного препарата (в случае её отсутствия - первичной
SGTIN
упаковки лекарственного препарата), формируемый путём
добавления к глобальному идентификационному номеру
торговой единицы индивидуального серийного номера
торговой единицы
Serial Shipping Container Code - уникальный код,
присваиваемый группе товаров при их описании в
SSCC
информационном ресурсе, обеспечивающем учёт и хранение
достоверных данных о товарах по соответствующей товарной
номенклатуре
Документ, на основе которого происходит передача сведений
во ФГИС МДЛП. Передача сведений может происходить
XML-документ
различными способами (с использованием API, через
интерфейс ЛК Участника, через РЭ, через РВ, через ОФД)
Схема, которая подробно описывает логические элементы и
XSD-схема
атрибуты XML документов с помощью специального языка
описания структуры XML
4
Общие рекомендации по интеграции с API МДЛП
Для получения информации из системы МДЛП можно воспользоваться либо Личным
кабинетом Участника, который располагается в сети Интернет по адресу:
интерфейсом API МДЛП. Интеграция ТУС Участника с методами, используемыми в ЛК
УОТ, является неверным способом взаимодействия с системой МДЛП и может привести к
непредвиденным для Участника последствиям, т.к. эти методы являются внутренними
методами Личного кабинета. В связи с этим, методы могут быть изменены Оператором
ЦРПТ без уведомления Участников, что может привести к неисправности в работе
интеграционных взаимодействий.
Описание всех методов API МДЛП можно найти в Документации по API МДЛП.
Вызовы методов API следует осуществлять с интервалами, которые необходимо
устанавливать индивидуально для каждого пользователя системы. Для доступа к системе
каждый пользователь может получить до
10 одновременно действующих токенов
аутентификации. При этом ограничения на временной интервал между вызовами методов
действуют в рамках одной учетной записи пользователя, а не в рамках сессии (токена) или
Участника в целом.
Для увеличения производительности собственной ТУС Участнику рекомендуется
зарегистрировать несколько учетных записей пользователей, чтобы иметь возможность
запускать параллельную обработку в несколько потоков (каждый пользователь со своей
сессией).
После получения электронного ключа (токена аутентификации) Участнику
рекомендуется использовать его при осуществлении вызовов методов API до момента
истечения срока действия ключа. Получение нового электронного ключа при каждом новом
вызове метода API приводит к увеличению количества параллельных сессий и уменьшению
временного интервала между вызовами. Срок действия одного электронного ключа
составляет 10 часов. При этом есть период бездействия равный 30 минутам. Если за этот
период по ключу не будет активности (вызовов методов API), токен прекращает своё
существование.
5
При организации работы ТУС в многопользовательском режиме необходимо
корректным образом настроить обработку документов, чтобы избежать
дублирования обработки одних и тех же записей в разных потоках.
Лимиты API МДЛП
Интервал лимита вызова метода API является временной разницей между первым и
следующим вызовом метода.
Лимиты распределяются в разрезе УКЭП и конкретного метода.
В случае возникновения ошибки по превышению лимита возвращается ошибка 429 с
указанием актуального значения лимита для вызываемого метода. Таким образом ТУС
можно динамически настроить в зависимости от возвращаемого значения.
При получении ошибки 429, расчет лимитного времени происходит с момента вызова
метода, повлекшего за собой появление ошибки.
Пример ошибки с лимитом:
{"error_description": "Нарушено ограничение на временной интервал между
вызовами! Действующий интервал: 100 мс"}
Список интервалов между вызовами методов, которые нужно установить во
избежание превышения лимитов, указан в разделе
«2.2. Общие требования по
использованию методов» Документации по API МДЛП.
Заключение
• Каждый токен имеет ограниченный срок службы = 10 часов. Если не
использовать токен больше, чем доступный период бездействия = 30 минут, то
он будет аннулирован досрочно;
• Лимит на временной интервал между вызовами каждого метода API привязан
к учетной записи пользователя (к одной УКЭП), а не Участника в целом;
• Решением вопроса, связанного с необходимостью повышении частоты
запросов, может стать использование нескольких учетных записей
пользователей. Для резидентов РФ потребуется выпуск нескольких УКЭП на
разных сотрудников организации.
6
Рекомендации по процессу работы с документами
Запрос на получение статуса обработки исходящего документа
После отправки документа первый запрос на получение его статуса рекомендуется
выполнять не раньше, чем через 3 секунды. Отправлять запрос на получение ссылки на
скачивание квитанции следует не раньше, чем будет получен статус, что документ был
обработан и по нему подготовлен ответ.
Запрос на получение квитанции по документу
Запрос на получение ссылки на скачивание квитанции после того, как статус
документа изменился, рекомендуется выполнять не раньше, чем через 5 секунд после
получения данного статуса документа.
Если при запросе квитанции, квитанция отсутствует, рекомендуется использовать
постепенно увеличивающиеся интервалы между запросами или повторные запросы с
единым шагом не менее 15 секунд.
Инструкция по определению документов и квитанций документов необходимых к
скачиванию представлена в разделе «Определение документов и квитанций документов,
необходимых к скачиванию» настоящего документа.
Пример:
Номер запроса
Интервал между запросами от времени отправки документа, сек
1
5
2
15
3
30
4
60
5
90
Работа с методами получения информации по объектам системы
SSCC/SGTIN
Синхронные методы API по получению информации по SSCC/SGTIN предназначены
прежде всего для небольших организаций с малым объемом трафика между ТУС Участника
и ФГИС МДЛП. Если использовать методы для запроса информации по большому объему
7
данных, это может привести к невозможности предоставления ответа в рамках одного
запроса.
Основными рекомендациями по использованию данных методов при работе с
большими объемами данных являются:
1. Переход на использование документов (XSD-схем), которые предоставляют
идентичную информацию (схема 220). При этом механизм подготовки ответа
на документы работает асинхронно;
2. Переход на использование асинхронных методов;
3. Снижение количества SSCC, одновременно направляемых в одном запросе (в
частности, для методов из раздела «8. Получение и управление информацией в
реестрах «ИС «Маркировка». МДЛП» Документации по API МДЛП.
Объем сведений, передаваемый в документах
При формировании документов для отправки в ФГИС МДЛП, в первую очередь
рекомендуется ориентироваться на максимально допустимое количество элементов
SGTIN/SSCC. При наличии большого количества элементов, по которым необходимо
передать информацию в ФГИС МДЛП, рекомендуется разбить общее количество
элементов на части и сформировать несколько документов.
Ограничения по количеству SGTIN, обрабатываемых в рамках каждого типа
документа приведены в документе «Описание XSD». Для каждой XSD-схемы указано свое
ограничение по количеству SGTIN. Актуальная версия документа опубликована на
официальном сайте честныйзнак.рф в разделе «Лекарства» → «Документы для работы в
МДЛП» → «Разработчикам» → «Комплекты схем».
Использование списка документов
При работе с документами в системе ФГИС МДЛП с использованием методов API
можно получить список документов Участника без загрузки непосредственно документов.
Список документов может помочь как с поиском необходимых документов, так и для
оптимизации процесса скачивания. В мета данных документов есть информация, которая
позволяет понять, когда необходимо приступать к скачиванию самого документа или
квитанции о его обработке.
Описание методов получения списка документов приведено в разделах «5.11.
Получение списка исходящих документов», «5.12. Получение списка исходящих документов
8
из витрины документов»,
«5.13. Получение списка входящих документов»,
«5.14.
Получение списка входящих документов из витрины документов» и «5.18. Получение
списка документов по идентификатору запроса» Документации по API МДЛП.
Использование фильтров для получения списка необходимых
документов
При работе со списком документов для поиска необходимых сведений можно
использовать фильтры, для уточнения своего запроса. Например, таким образом можно
получить список идентификаторов документов с определенным типом или временем
отправки в систему.
Описание всех доступных полей для фильтрации можно найти в разделе «4.22.
Формат объекта DocFilter» Документации по API МДЛП.
Определение документов и квитанций документов, необходимых к
скачиванию
Ориентируясь на статус обработки документа, можно определить документы и
квитанции, которые необходимо скачать для ознакомления.
Скачивать квитанцию или сам документ необходимо только после того, как документ
перешел в конечный статус PROCESSED или FAILED_RESULT_READY, так как именно
эти статусы означают, что обработка завершена. В противном случае, если попытаться
скачать квитанцию, то вернется ошибка 404, т.к. квитанция еще не сформирована.
Квитанции документов в статусе FAILED_RESULT_READY следует загружать в
первую очередь для идентификации причин ошибки.
От запроса ссылок на скачивание документов и квитанций об их обработке следует
воздержаться, если документы находятся в следующих статусах:
• FAILED;
• UPLOADING_DOCUMENT;
• IN_BULK;
• PROCESSING_DOCUMENT;
• CORE_PROCESSING_DOCUMENT;
• CORE_PROCESSED_DOCUMENT.
9
Запрос по статусам данных документов также целесообразно осуществлять с
временным интервалом, описанным в разделе «Запрос на получение квитанции по
документу» настоящего документа.
10
Построение очереди приоритетов на скачивание документов
При использовании списков документов с настроенными фильтрами по типам
документов можно формировать список на загрузку, помещая в его начало документы в
порядке приоритета, в зависимости от текущих бизнес-потребностей Участника.
Описание методов представлено в разделе
«5.17 Получение документа по
идентификатору» Документации по API МДЛП.
Работа с группами документов
Если в бизнес-процессах Участника предусмотрена последовательная отправка
сведений по одним и тем же кодам SGTIN, в виде цепочки операций (например, 701 - 912
- 911 - 341), для отправки таких документов рекомендуется использовать специальные
методы по работе с группами документов.
Процесс загрузки и последовательной обработки документов с использованием
методов API выглядит следующим образом:
1. Загрузка документов:
a. Для отправки документов малого объема1 вызывается метод отправки
документов POST api/v1/documents/send, с указанием в параметре
bulk_processing значения true. Данный параметр позволяет установить
отложенную обработку документа, которая будет запущена позднее
отдельным методом;
b. Для отправки документов большого объема необходимо:
1. Вызвать метод отправки документов большого объема POST
api/v1/documents/send_large, указав в параметре bulk_processing
значение true;
2. Вызвать метод загрузки документов большого объема PUT
/webdav/upload/{doc_id}/{doc_id};
3. Вызвать
метод завершения отправки документа POST
api/v1/documents/send_finished. При этом документ будет загружен в
систему также с признаком отложенной обработки.
1 Лимит соответствует значению, установленному в настройках системы. Можно получить, вызвав метод
GET api/v1/documents/doc_size
11
2. Проверка возможности запуска обработки группы документов. Вызывается
метод проверки возможности запуска обработки POST api/v1/documents/bulk/check.
Метод проверяет статус готовности документов к обработке. Статус всех
документов должен быть UPLOADING_DOCUMENT, а признак ready_for_bulk
должен быть в положении true.
3. Обработка группы документов. Если все документы находятся в нужном статусе,
то вызывается метод запуска обработки документов POST api/v1/documents/bulk.
Метод запускает последовательный процессинг документов в порядке,
определенном пользователем во входном параметре document_ids, а также
присваивает группе документов уникальный идентификатор bulk_id. Если в
середине цепочки при обработке документа возникнет ошибка, то последующие
документы из группы обработаны не будут. Пользователю необходимо
самостоятельно принять решение на основании полученной ошибки и, по
необходимости, внести в документы изменения. Документы из цепочки,
обработанные успешно, в повторной загрузке и обработке не нуждаются.
Типы документов, которые не подлежат загрузке в виде группы документов: 10311,
10319, 10300, 10305, 10511, 10521, 10522, 10531 и 20521.
Подробное описание методов представлено в разделах «5.5 Запуск обработки группы
документов», «5.6 Проверка возможности запуска группы документов», «5.7 Получение
информации о группе документов», «5.8 Получение информации по имеющимся группам
документов» Документации по API МДЛП.
Связь между документом и формируемым уведомлением
Для поиска уведомлений, сформированных на основании отправленных другим
Участником документов, в системе предусмотрен атрибут request_id, используя который
можно найти взаимосвязанные документы. В системе Участника рекомендуется сохранять
и отображать этот параметр наравне с полученным идентификатором документа. В системе
получателя, используя возможности фильтрации списка и получению документа, Участник
всегда сможет однозначно идентифицировать сформированное в его сторону уведомление
(см. Рисунок 1).
12
Рисунок 1. Схема связи документа и формируемого уведомления
Параметр request_id является обязательным при отправке документа через API и
указывается Участником самостоятельно. При отправке документа через ЛК ФГИС МДЛП
данный параметр заполняется автоматически. Информация по параметру возвращается
также в квитанции в поле operation_id в случае успешной обработки документа.
Получение списка новых документов
С целью снижения рисков неполучения входящих документов при использовании
Участником запросов к реестру входящих документов с указанием временного диапазона,
а также минимизации количества дублирующих запросов к ФГИС МДЛП и уменьшения
объема информационного потока между системой Маркировки и системой Участника
реализована возможность получения списка только новых непрочитанных документов.
Данная возможность упрощает работу Участника с системой и позволяет получать
необходимые данные без использования дополнительных инструментов и логики по
сопоставлению ранее полученной информации.
Для получения только новых уведомлений необходимо в запросе на получение списка
входящих документов POST api/v1/documents/income в параметре only_new объекта
фильтрации DocIncomeFilter указать значение true (подробности см. в разделе «5.13.
Получение списка входящих документов» Документации по API МДЛП). При вызове
метода с указанным фильтром будет возвращен список документов, которые Участник
ранее не помечал как прочитанные.
13
Далее, после получения списка непрочитанных уведомлений и их необходимой
обработки следует вызвать метод POST api/v1/documents/income/mark_read (раздел «5.15.
Передача информации о прочтении документа» Документации по API МДЛП), в котором
надо указать идентификаторы обработанных документов. По факту выполнения метода
документы в системе ФГИС МДЛП помечаются как прочитанные.
Соответственно при повторном вызове метода получения списка входящих
документов с признаком only_new = true, отмеченные документы возвращаться не будут.
Особенности и ограничения:
• При использовании параметра only_new = true при фильтрации списка
документов учитываются документы, сформированные не позднее 30 дней с
момента выполнения запроса;
• В результате процедуры выгрузки документов отсутствует автоматическое
изменение статуса документа на Прочтен. Участник самостоятельно
указывает, какие документы можно считать прочитанными;
• В случае необходимости проставить статус прочтения уведомления можно
вручную в ЛК ФГИС МДЛП при помощи кнопки «Пометить как
прочитанное» в разделе «Документы» - «Входящие»
Заключение
• Интервал между отправкой документа и запросом на получение квитанции
рекомендуется устанавливать в промежутке от 2 до 5 секунд;
• Не стоит запрашивать квитанцию по документам, которые находятся в
промежуточном статусе;
• Интервал между запросами на получение квитанции рекомендуется
устанавливать равным
15 секундам или использовать равномерно
увеличивающиеся интервалы между запросами;
• Если количество SGTIN/SSCC, по которым необходимо запросить
информацию, достаточно велико, то приоритетнее использовать XSD-схемы
210/220 и асинхронные выгрузки;
• При отправке документа рекомендуется отправлять несколько документов
меньшего объема вместо одного большого;
14
• Перед скачиванием документов целесообразно получать сначала список
документов;
• Для фильтрации списка документов следует использовать многочисленные
фильтры для уменьшения информационного потока;
• На основании статуса обработки документов необходимо определиться с
приоритетами на скачивание документов и квитанций;
• Если необходимо выстроить цепочку документов, которые должны
обрабатываться последовательно, стоит использовать методы для работы с
группами документов;
• Связь между документом и уведомлением по нему осуществляется с
использованием параметра request_id. Следует сохранять и выводить данный
параметр в интерфейсе ТУС наравне с идентификатором документа;
• Для фильтрации реестра входящих документов можно использовать параметр
only_new. В паре с этим необходимо помечать обработанные документы как
прочитанные.
Использование реестра временно
приостановленных SGTIN
В ЛК УОТ реестр лекарственных препаратов, в отношении которых осуществлен
временный вывод из оборота» разделен на два реестра:
• «Реестр временно приостановленных SGTIN» - в нем хранятся сведения о
временно приостановленных SGTIN, эмитированных после 25.03.2021;
• «Реестр временно приостановленных SGTIN, эмитированных до 25.03.2021» -
в нем хранятся сведения о временно приостановленных SGTIN,
эмитированных до 25.03.2021.
Для того, чтобы обнаружить SGTIN, которые находятся в наличии у Участника и при
этом по ним вынесено решение о временной приостановке, Участнику рекомендуется:
1. Раз в сутки проверять «Реестр временно приостановленных SGTIN» и «Реестр
временно приостановленных SGTIN, эмитированных до
25.03.2021» на
наличие нового решения. Для этого необходимо выставлять фильтрацию в
указанных реестрах по полю «Дата решения»;
15
2. При появлении нового решения проверять наличие SGTIN, по которым
вынесено решение. Поиск SGTIN должен осуществляться по GTIN и серии,
которые указаны в «Реестр временно приостановленных SGTIN» и в «Реестр
временно приостановленных SGTIN, эмитированных до 25.03.2021»;
3. Обнаруженные SGTIN требуется пометить как приостановленные с указанием
идентификатора решения о приостановке.
Использование архивного хранилища
По прошествии 60 дней после перехода SGTIN в конечный статус, информация по
коду переносится в архивное хранилище. Список конечных статусов, в которых может
находиться SGTIN, подлежащий переносу в архивное хранилище:
•
«Отобран образец»;
•
«Уничтожен»;
•
«Частичная продажа, остаток списан»;
•
«Частичный отпуск по ЛР, остаток списан»;
•
«Частичное медицинское применение, остаток списан»;
•
«Частично выдан по документам, остаток списан»;
•
«Выведен из оборота»;
•
«Продан в розницу»;
•
«Отпущен по льготному рецепту»;
•
«Выдан для медицинского применения»;
•
«Реэкспорт»;
•
«Срок годности истек»;
•
«Продан в розницу с использованием ККТ с ошибкой»;
•
«Отпущен по льготному рецепту с использованием ККТ с ошибкой»;
•
«Истек срок ожидания оплаты»;
•
«Отпущен по льготному рецепту с использованием РВ с ошибкой»;
•
«Выдан для медицинского использования с использованием РВ с ошибкой»;
•
«Не использован»;
•
«Выдан по документам».
16
Рекомендации по работе с устаревшими методами
В таблице ниже приведен список методов API, а также список отельных параметров,
которые на данный момент являются устаревшими и подлежат отключению.
Дополнительно в таблице указана дата окончательного отключения методов и удаления их
из API МДЛП. Для устаревших методов обозначена замена, которую следует использовать
вместо устаревших.
Признак «Устарел» обозначает, что метод или отдельный параметр более не
возвращает данных, при этом пока не удален для сохранения обратной совместимости.
Участникам рекомендуется не интегрировать свои ТУС с обозначенными в таблицах
методами во избежание возможных проблем. Если интеграции с данными методами всё же
присутствуют - Участникам необходимо озаботиться переключением на использование
других методов, которые предложены на замену.
17
Таблица 1. Список устаревших методов
Название
Устаревший метод
Метод на замену
Дата полного
устаревшего метода
отключения
Метод для
Раздел 6.6.10
Раздел 6.6.11
Декабрь 2021
получения списка
POST api/v1/rights/list
POST
групп прав
<endpoint>/<version>/r
пользователей
ights/filter
Метод для поиска по
Раздел 6.7.1
Раздел 6.7.2
Декабрь 2021
зарегистрированным
POST api/v1/users/find
POST
пользователям
<endpoint>/<version>/
users/filter
Метод для поиска по
Раздел 6.8.1
Раздел 6.8.2
Декабрь 2021
УС
POST
POST
api/v1/account_systems/fi
<endpoint>/<version>/a
nd
ccount_systems/filter
Получение
Раздел 7.4.1
Отсутствует до
Декабрь 2021
информации о
GET api/v1/reestr/dues
появления
задолженности
функционала новой
платности
Получение
Раздел 8.1.1
Раздел 8.1.2
Декабрь 2021
информации о
GET
POST
местах
api/v1/reestr/branches
<endpoint>/<version>/r
осуществления
eestr/branches/filter
деятельности
Метод для
Раздел 8.1.6
Декабрь 2021
получения
GET
информации об
api/v1/reestr/branches/avai
адресах текущего
lable_branches_addresses
участника
Получение
Раздел 8.2.1
Раздел 8.2.2
Декабрь 2021
информации о
GET
POST
местах
api/v1/reestr/warehouses
<endpoint>/<version>/r
ответственного
eestr/warehouses/filter
хранения
Получение сводной
POST
Временно
Декабрь 2021
информации
api/v1/reestr/batches/short-
приостановлен. Метод
распределения ЛП
distribution
на замену не
требуется.
Выгрузка
Временно
Декабрь 2021
детализированной
приостановлен. Метод
информации по
на замену не
движению ЛП
требуется.
18
Таблица 2. Список устаревших параметров общих объектов
Объект
Устаревший параметр
Дата полного
Комментарий
отключения
Раздел 4.27
is_admin
Декабрь 2021
Параметр на замену: type
Group
Раздел 4.28
prod_desc_label
Декабрь 2021
Параметр на
замену: prod_sell_name
MedProductsFilter
Раздел 4.50
reg_status
Декабрь 2021
Значение поля не
заполняется и всегда
GtinInfo
является пустой строкой
prod_desc_label
Декабрь 2021
Параметр на замену:
prod_sell_name
pack_2_3_name
Декабрь 2021
Устарел
country_pack_2_3
Декабрь 2021
Устарел
pack_2_3_code
Декабрь 2021
Устарел
pack_2_3_address
Декабрь 2021
Устарел
qa_name
Декабрь 2021
Устарел
qa_country
Декабрь 2021
Устарел
qa_code
Декабрь 2021
Устарел
qa_address_name
Декабрь 2021
Устарел
pack_1
Декабрь 2021
Устарел
pack_2_3
Декабрь 2021
Устарел
QA
Декабрь 2021
Устарел
Таблица 3. Список устаревших входных параметров
Название
Метод
Устаревший
Дата полного
Комментарий
метода
параметр
отключения
Метод для
Раздел 8.4.2
gnvlp
Декабрь 2021
Устарел
получения
vzn_drug
Декабрь 2021
Устарел
POST
информации о
<endpoint>/<vers
КИЗ в третичной
ion>/reestr/sscc/{
упаковке
sscc}/sgtins
Метод
Раздел 8.8.1
branch_id
Декабрь 2021
При
фильтрации по
необходимости
POST
субъектам
получения перечня
<endpoint>/<vers
обращения
мест
ion>/reestr_partne
осуществления
rs/filter
деятельности
использовать
метод:
Раздел 8.1.3:
POST <endpoint>/<
version>/reestr/branc
hes/public/filter
Просмотр
Раздел 9.3
task_ids
Декабрь 2021
Изменена
списка задач
POST
task_status
Декабрь 2021
структуры входных
пользователя
<endpoint>/<vers
create_date_from
Декабрь 2021
параметров
create_date_to
Декабрь 2021
(параметры
19
ion>/export/tasks/
перемещены в
filter
массив TasksFilter)
n_page
Декабрь 2021
Используется
значение по
умолчанию: 1
page_size
Декабрь 2021
Используется
значение по
умолчанию: 20
Метод для
Раздел 6.6.11
is_admin
Декабрь 2021
Параметр на
поиска списка
POST
замену: type
групп прав
<endpoint>/<vers
пользователей
ion>/rights/filter
по фильтру
Таблица 4. Список устаревших выходных параметров
Название
Метод
Устаревший
Дата полного
Комментарий
метода
параметр
отключения
Метод для
Раздел 8.5.1
reg_status
Декабрь 2021
Устарел
получения
POST
prod_desc_label
Декабрь 2021
Параметр на
информации из
<endpoint>/<vers
замену:
реестра
ion>/reestr/med_p
prod_sell_name
производимых
roducts/current
packer_address
Декабрь 2021
Устарел
организацией
pack_1
Декабрь 2021
Устарел
ЛП
pack_2_3
Декабрь 2021
Устарел
QA
Декабрь 2021
Устарел
Метод для
Раздел 8.5.2
reg_status
Декабрь 2021
Устарел
получения
GET
prod_desc_label
Декабрь 2021
Параметр на
детальной
<endpoint>/<vers
замену:
информации о
ion>/reestr/med_p
prod_sell_name
производимом
roducts/{gtin}
packer_address
Декабрь 2021
Устарел
организацией
pack_2_3_name
Декабрь 2021
Устарел
ЛП
country_pack_2_
Декабрь 2021
Устарел
3
pack_2_3_code
Декабрь 2021
Устарел
pack_2_3_addres
Декабрь 2021
Устарел
s
qa_name
Декабрь 2021
Устарел
qa_country
Декабрь 2021
Устарел
qa_code
Декабрь 2021
Устарел
qa_address_name
Декабрь 2021
Устарел
pack_1
pack_2_3
Декабрь 2021
Устарел
QA
Декабрь 2021
Устарел
Фильтрация по
Раздел 7.10.1
PACK_2_3_NA
Декабрь 2021
Устарел
реестру ЕСКЛП
POST
ME
<endpoint>/<vers
PACK_2_3_COD
Декабрь 2021
Устарел
ion>/reestr/esklp/f
E
ilter
PACK_2_3_COD
Декабрь 2021
Устарел
E_F
20
COUNTRY_PAC
Декабрь 2021
Устарел
K_2_3
QA_CODE
Декабрь 2021
Устарел
QA_CODE_F
Декабрь 2021
Устарел
QA_COUNTRY
Декабрь 2021
Устарел
QA_NAME
Декабрь 2021
Устарел
QA_ADDRESS_
Декабрь 2021
Устарел
NAME
ADDRESS_FIAS
Декабрь 2021
Устарел
QA_ADDRESS_
Декабрь 2021
Устарел
FIAS
ADDRESS
Декабрь 2021
Устарел
REG_STATUS
Декабрь 2021
Устарел
pack_1
Декабрь 2021
Устарел
pack_2_3
Декабрь 2021
Устарел
QA
Декабрь 2021
Устарел
Метод для
Раздел 8.5.3
reg_status
Декабрь 2021
Устарел
поиска
POST
публичной
<endpoint>/<vers
информации в
ion>/reestr/med_p
реестре
roducts/public/filt
производимых
er
ЛП
Метод
Раздел 8.8.1
branches
Декабрь 2021
При
фильтрации по
POST
safe_warehouses
Декабрь 2021
необходимости
субъектам
<endpoint>/<vers
получения перечня
обращения
ion>/reestr_partne
мест
rs/filter
осуществления
деятельности
использовать
метод:
Раздел 8.1.3:
POST <endpoint>/<
version>/reestr/branc
hes/public/filter
Таблица 5. Список устаревших прав
Название устаревшего
Устаревшее право
Дата полного
Комментарий
права
отключения
Просмотр реестра
VIEW_BILLING_PR
Декабрь 2021
Устарели. Функционал, в
приоритетной оплаты
IORITY_RULES
котором были
Редактирование реестра
MANAGE_BILLING
Декабрь 2021
задействованы
приоритетной оплаты
_PRIORITY_RULES
перечисленные права, был
Реестр КИЗ для
REESTR_SGTIN_BI
Декабрь 2021
переработан. Сами права
биллинга
LLING
более не применяются.
21
Экранирование специальных символов
При запросе информации по документам посредством открытого API система ФГИС
МДЛП формирует уведомление в формате JSON. При формировании уведомления в
соответствии со спецификацией JSON система ФГИС МДЛП проводит экранирование
специальных символов.
Рекомендуется для полученных посредством открытого API уведомлений проводить
обратную экранированию операцию, как показано в таблице:
Экранированный
Название
Символ
Название
Примечание
символ
экранированного
символа
символа
1
\"
Обратная косая
"
Двойная
Комбинацию
черта, Двойная
кавычка
символов
кавычка
«Обратная
косая черта,
Двойная
кавычка» (\")
заменять на
символ
«Двойная
кавычка» (")
2
\\
Две обратные
\
Обратная
Комбинацию
косые черты
косая черта
символов «Две
обратные косые
черты» (\\)
заменять на
символ
«Обратная
косая черта» (\)
При вызове методов открытого API параметры запроса экранировать не требуется.
Пример проведения обратной экранированию операции для полученного посредством
открытого API уведомления:
До проведения обратной
После проведения обратной
экранированию операции
экранированию операции
Фрагмент JSON:
Фрагмент JSON:
{
{
"doc_num": "151\\702"...
"doc_num": "151\702"...
}
}
22