Выдержка из технической спецификацииhttps://честныйзнак.рф/upload/iblock/92b/TC...2019/06/07 · добавлять поле следующего

Страница 1 из 66

Выдержка из технической

спецификации

на поставку регистратора выбытия

Москва

2019


Приложение А. «API РВ КМ»

Общие положения

Взаимодействие программного обеспечения с РВ КМ осуществляется посредством

сервисов REST API РВ КМ с использованием формата JSON. Взаимодействие должно

осуществляться по протоколу HTTPS.

REST API РВ КМ используется при обоих типах подключения: сетевое

взаимодействие, USB (см. Рисунок 1).

При подключении через USB, сервисы REST API РВ КМ предоставляются

промежуточным программным обеспечением, которое далее именуется драйвером (драйвер

представляет собой «Web-сервер», предоставляющий набор как унифицированных, так и

проприетарных методов).

При сетевом подключении, сервисы REST API РВ КМ предоставляются

непосредственно регистратором выбытия.

Рисунок 1 - Взаимодействие клиентского ПО с регистратором выбытия

Алгоритм взаимодействия

Для безопасного взаимодействия с РВ КМ Поставщик должен обеспечить механизм

аутентификации и авторизации, а также проработать меры безопасного использования пароля

при его хранении и передаче.

Для использования данных методов в заголовок каждого HTTP-запроса необходимо

добавлять поле следующего вида: Authorization: Basic <данные пользователя>, где данные

пользователя – это строка, содержащая логин и пароль, разделенные двоеточием, и

закодированная в формате Base64. Подробнее о данном методе авторизации можно прочитать

в RFC 7617.


В РВ КМ используется два пользователя:

− Оператор - логин: user1, пароль: Pas$w0rd;

− Администратор - логин: user2, пароль: qwE123xx.

Пароли могут быть изменены через меню РВ КМ.

Метод запроса POST предназначен для запроса, при котором Web–сервер принимает

данные, заключённые в тело сообщения, для хранения. Клиент отправляет серверу запрос на

постановку задания в очередь, сервер отвечает клиенту либо пакетом с данными успешного

выполнения операции, либо пакетом с ошибкой.

Примеры заголовка запроса и ответа приведены в таблицах ниже (Таблица 1 и

Таблица 2).

Таблица 1 – Пример заголовка запроса (метод POST)

Пример

POST /v1/requests HTTP/1.1

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

Authorization: Basic b64_auth

Accept: application/json

Content-Length: 298

{Body}

Таблица 2 – Пример заголовка ответа на запрос

Пример

HTTP/1.1 200 OK


Content-Length: 908 Метод запроса GET предназначен для получения информации от сервера. В рамках

GET запроса некоторые данные могут быть переданы в строке запроса URL, указывающие

информацию, определяющую запрос. Клиент запрашивает у сервера результат по заданному

идентификатору операции. Сервер отвечает клиенту либо статусным пакетом (операция ещё

не завершилась), либо пакетом с ошибкой (операцию завершить не удалось, т.к. в ходе

выполнения произошла ошибка), либо пакетом с данными успешного выполнения операции.

Примеры запроса и ответа приведены в таблицах ниже (Таблица 3 и Таблица 4).

Таблица 3 – Пример заголовка запроса (метод GET)

Пример

GET //v1/settings HTTP/1.1




{Body}


Таблица 4 – Пример заголовка ответа на запрос

Пример

HTTP/1.1 200 OK


Content-Length: 196

{Body}

Генерация идентификатора документа mdlpRequestId

Идентификатор mdlpRequestId присваивается документу при отправке отчета о

выбытии на регистрацию в ФГИС МДЛП. Для генерации mdlpRequestId документа

используется uuid v3, описанный стандартом ITU-T Rec. X.667. Подробное описание

стандарта доступно по ссылке: https://www.itu.int/rec/T-REC-X.667-201210-I/en.

В качестве пространства имён (name space) используется NameSpace_DNS.

Для генерирования mdlpRequestId сформируется массив, состоящий из следующих

данных:

1. время в секундах с 1 января 1970 г., UnixTime, функция time();

2. время в наносекундах с момента включения РВ, функция

clock_gettime(CLOCK_REALTIME, &t), где "время в наносекундах" = t.tv_nsec. При

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

числом;

3. серийный номер МБ РВ;

4. случайное число, генерируемое РВ.

Описание методов API РВ КМ

Для выполнения любого действия с использованием РВ необходимо отправить

соответствующий запрос на URL-адрес РВ или драйвера РВ. В случае положительного

результата выполнения запроса будет возвращен результат в виде JSON, или, в случае

отрицательного результата, будет возвращено описание возникшей ошибки.

Порядок использования методов API РВ КМ согласно процессам выбытия ЛП

представлены на схемах в Приложении В. Описание параметров методов приведено ниже в

этом приложении.


Метод «Записать задание в очередь» (QueueUp)

Описание

Метод «Записать задание в очередь» служит для добавления запроса в общую очередь

заданий на выполнение. В связи с отсутствием возможности спрогнозировать время

выполнения конкретного задания, все задания добавляются на выполнение в общую очередь

по одному и тому же URL. Задания в зависимости от типа запроса могут быть трех типов:

− registration – регистрация РВ;

− checkMarks – проверка кода маркировки;

− registerMarksByRequisites – регистрация выбытия кодов маркировки по

реквизитам документа-основания.

Для записи задания в очередь необходимо отправить POST запрос, где в структуре

“request” указывается соответствующее содержимое согласно типу задания.

Запрос

Метод: POST

Краткое наименование: QueueUp

URL: https://<server>[:port]/v1/requests[?deviceId={deviceIdvalue}]

server – IP адрес или имя сервера.

port – порт.

deviceId – уникальный идентификатор устройства (опциональный параметр).

Параметры запроса записи задания в очередь приведены в таблице ниже (Таблица 5).

Таблица 5 – Параметры запроса записи задания в очередь

Наименование

поля Тип поля Обязательные поля Ограничения

rvRequestId string Да

Уникальный идентификатор запроса, присваиваемый

клиентом.

Максимальная длина 64 символа.

request object Да Задание.

json json Да

Текст задания.

Содержимое зависит от типа запроса (подробное

описание приведено ниже).

Пример запроса приведён в таблице ниже (Таблица 6).

Таблица 6 - Пример запроса записи задания в очередь

Пример запроса

{

"rvRequestId":"2ea26f17-0884-4f08-b120-306fc096",

"request":{

json

}

}


Задание типа «Регистрация РВ»

Задание типа «Регистрация РВ» формируется при отправке запроса регистрации РВ.

Параметры данного метода не являются окончательными и могут быть доработаны позже на

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

«Запросить статус задания».

Данный тип задания не обязателен для реализации.

Параметры запроса регистрации РВ КМ приведены в таблице ниже (Таблица 7).

Таблица 7 – Параметры запроса регистрации РВ КМ

Наименование поля Тип

поля

Обязательные

поля Ограничения

type enum,

string

Да Тип задания. Фиксированное значение:

registration – регистрация РВ.

registrationParams object Да Реквизиты регистрации РВ.

controlToken string Да Идентификационный код регистрации.

Минимальная длина 8 символов.

Максимальная длина 8 символов.

Параметры регистрации РВ КМ вводятся пользователем на веб-форме регистрации

РВ КМ, после чего сервером формируется код подтверждения регистрации РВ КМ, и именно

его РВ КМ должен передать в вызове в параметре controlToken.


Таблица 8 – Пример запроса регистрации РВ КМ

Пример

{

"type":"registration",

"registrationParams":{

"controlToken":"12345678"

}

}

Задание типа «Проверить код маркировки»

Задание типа «Проверить код маркировки» формируется при отправке запроса

проверки кода маркировки. Результат проверки кода можно получить вызовом метода

«Запросить статус задания».

Параметры запроса проверки кода маркировки приведены в таблице ниже

(Таблица 9).

Таблица 9 – Параметры запроса проверки кода маркировки


поля Тип поля

Обязательные поля Ограничения

type enum,

string

Да Тип задания. Фиксированное значение:

checkMarks – проверить код маркировки.

localCheck boolean Да Признак проведения локальной проверки при

проверке КМ. Перечисление со значениями:

− true (выполняется ФЛК и локальная

проверка подписи);

− false (выполняется только ФЛК).





marks object Да Словарь марок, где каждый ключ - это уникальный

идентификатор марки в пределах словаря марок.

mark string Да Код маркировки в формате base64.

Максимальная длина 226 символов при длине кода

169 символов.

Пример кода маркировки в формате base64 приведён в таблице ниже (Таблица 10):

Таблица 10 – Пример кода маркировки в формате base64

Пример

"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwNh0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFCQ0RFRjEyMz

QdMTcxNzA5MTE5MTExMjkdOTJqNFZPemdHMlkvVXoxQ1ZoTWQzV25CNlRxVmp1cUZzZTIzQkJobUNFMldyQWczc2VJeUlDS2hiUlI4

S29nZnVaajFhUEQwVmhKSUMzVzBqbUFoaDYrdz0974"

=

base64("TURFd01USXpORFUyTnpnNU1USXpOVEl4TURBd01EQXdNREF3TURBd05oMHlOREF4TWpNMEhURXdNREV5T

XpRMU5qYzRPVUZDUTBSRlJqRXlNelFkTVRjeE56QTVNVEU1TVRFeE1qa2RPVEpxTkZaUGVtZEhNbGt2VlhveFExWm9UV1F6VjI1Q0

5sUnhWbXAxY1VaelpUSXpRa0pvYlVORk1sZHlRV2N6YzJWSmVVbERTMmhpVWxJNFMyOW5ablZhYWpGaFVFUXdWbWhLU1VNelZ

6QnFiVUZvYURZcmR6MDk3NA==")

Base64 – стандарт кодирования двоичных данных при помощи 64 символов ASCII.

Функция base64 производит обратимое кодирование всех символов восьмибитной кодовой

таблицы в символы, гарантированно сохраняющиеся при передаче данных в любых сетях и

между любыми устройствами.


Таблица 11 – Пример запроса проверки кода маркировки

Пример

{

"type":"checkMarks",

"localCheck":true,

"marks":{

"1":{

"mark":"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwNh0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFC

Q0RFRjEyMzQdMTcxNzA5MTE5MTExMjkdOTJqNFZPemdHMlkvVXoxQ1ZoTWQzV25CNlRxVmp1cUZzZTIzQkJobUNFMldyQWczc2

VJeUlDS2hiUlI4S29nZnVaajFhUEQwVmhKSUMzVzBqbUFoaDYrdz09"

},

"2":{

"mark":"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwNx0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFC

Q0RFRjEyMzQdMTcxNzA5MTE5MTExMjkdOTJVTHNIbWZQZmcwdUNHN05JNlpaN3RrZGlXZlU1ci92VzVYUENhTmJjbXEyYWpEMU

QrME9FNHdWL2JVeWJHbmpneThNQ3BCdGdJOEpmNGVEem80VHF1dz09"

},

"3":{

"mark":"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwOB0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFC

Q0RFRjEyMzQdMTcxNzA5MTE5MTExMjkdOTIzZjNoc3ZsbE9kRk9sWVdLMU11QUJkalVLZHk4TnIzR2pFcjNLTElMcFZtODNPZ2

c1cUVIS0p4ajdBZkNyeGJOUTV2ODVmekZwb3pETGFLOFhjNVZrZz09"

}

}

}


Задание типа «Регистрация отчёта о выбытии по реквизитам документа-основания»

Задание типа «Регистрация отчёта о выбытии по реквизитам документа-основания»

формируется при вызове запроса регистрации отчета о выбытии в ФГИС МДЛП. Результат

регистрации отчета о выбытии можно получить вызовом метода «Запросить статус задания».

Параметры запроса регистрации отчета о выбытии по реквизитам документа-

основания приведены в таблице ниже (Таблица 12):

Таблица 12 – Параметры запроса регистрации отчёта о выбытии по реквизитам документа-

основания

Наименование поля Тип поля Обязательные


type enum,

string

Да Тип запроса задания. Фиксированное значение:

registerMarksByRequisites – регистрация отчета о

выбытии по реквизитам документа-основания.

documentOut object Да Реквизиты документа-основания.

type enum,

integer

Да Тип документа-основания. Перечисление со

значениями:

0 – Требование-накладная или другой документ

внутреннего учета товародвижения участника

оборота;

1 – Рецепт.

code string Нет Код элемента справочника. Кодируется

справочником «ОКУД» (например, «0504204»).


codeName string Да Текстовое значение элемента справочника

(например, «Требование накладная» или «Рецепт

по форме 107/у»).


При перобразовании в метаданные поля code и

codeName преобразовываются в поле docNum

(см.Таблица 85).

date string Да Дата документа основания в формате "yyyy-MM-

dd'T'HH:mm:ss'Z'".

series string Нет Серия документа-основания.

Является обязательным параметром, если

документом-основанием является льготный

рецепт.

number string Да Номер документа основания.

Максимальная длина 16 символов

marks object Да Словарь марок, где каждый ключ - это уникальный

идентификатор марки в пределах словаря марок.


Максимальная длина 226 символов (при длине

кода 169 символов).

soldPart string Нет Доля от вторичной упаковки. Обыкновенная

(простая) правильная дробь.



Таблица 13 – Пример запроса регистрации отчёта о выбытии по реквизитам документа-

основания

Пример

{

"type":"registerMarksByRequisites",

"documentOut":{

"type":1,


"code":"0504204",

"codeName":"Требование накладная",

"date":"2019-07-21T17:32:28Z",

"series":"123456N",

"number":"12345"

},

"marks":{

"1":{

"mark":"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwNh0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFCQ0RFRjEyMzQdMTcxNz

A5MTE5MTExMjkdOTJqNFZPemdHMlkvVXoxQ1ZoTWQzV25CNlRxVmp1cUZzZTIzQkJobUNFMldyQWczc2VJeUlDS2hiUlI4S29n

ZnVaajFhUEQwVmhKSUMzVzBqbUFoaDYrdz09"

},

"2":{

"mark":"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwNx0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFCQ0RFRjEyMzQdMTcxNz

A5MTE5MTExMjkdOTJVTHNIbWZQZmcwdUNHN05JNlpaN3RrZGlXZlU1ci92VzVYUENhTmJjbXEyYWpEMUQrME9FNHdWL2JVeWJH

bmpneThNQ3BCdGdJOEpmNGVEem80VHF1dz09"

},

"3":{

"mark":"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwOB0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFCQ0RFRjEyMzQdMTcxNz

A5MTE5MTExMjkdOTIzZjNoc3ZsbE9kRk9sWVdLMU11QUJkalVLZHk4TnIzR2pFcjNLTElMcFZtODNPZ2c1cUVIS0p4ajdBZkNy

eGJOUTV2ODVmekZwb3pETGFLOFhjNVZrZz09",

"soldPart":"3/200"

}

}

}

Ответ на запрос

В ответ сервер вернёт код HTTP-статуса добавления задания в очередь. Коды

состояний ответе на запрос записи задания приведены в таблице ниже (Таблица 14):

Таблица 14 – Коды состояний в ответе на запрос записи задания

Код состояния

HTTP Описание

201 Задание добавлено в очередь.

400 Ошибка формата запроса.

409 Задание с заданным rvRequestId уже существует.


Метод «Запросить статус задания» (RequestStatus)

Описание

Метод используется для запроса статуса выполнения задания. Осуществляется с

помощью GET запроса. Структура ответа запроса статуса задания зависит от типа задания, а

также от статуса задания.

Запрос

Метод: GET

Краткое наименование: RequestStatus

URL: https://<server>[:port]/v1/requests/{rvRequestId}[?deviceId={deviceIdvalue}]


port – порт.


rvRequestId – уникальный идентификатор задания, присвоенный клиентом

(обязательный параметр).


Структура ответа на запрос статуса задания по rvRequestId приведён в таблице ниже

(Таблица 15).

Таблица 15 – Общая структура ответа на запрос статуса задания по rvRequestId


поля

Тип

поля



results object Да Результаты выполнения задания.

error object Нет Ошибка, заполняется при наличии ошибок, если

поле «status» имеет значение «error».

code integer Да Код ошибки.

description string Да Описание ошибки.


status enum,

string

Да Статус задания. Перечисление со значениями:

− ready – задание выполнено без ошибок;

− wait – задание находится в очереди;

− inProgress – задание в процессе

выполнения;

− error – выполнение задания завершено с

ошибкой.

result object Нет Результат задания.

Результат задания возвращается если поле «status»

имеет значение «ready». Содержимое результата

задания зависит от типа задания (подробное

описание приведено ниже).

Ответ на запрос статуса задания «регистрация отчета о выбытии по реквизитам

документа-основания»

Ответ на запрос статуса задания типа «регистрация отчета о выбытии по реквизитам

документа-основания» в случае его готовности (статус задания задан как «ready») приведён в

таблице ниже (Таблица 16).


Таблица 16 – Ответ на запрос статуса задания регистрации отчёта о выбытии по реквизитам

документа-основания


поля



result object Да Результаты выполнения задания.

mdlpRequestId string Да Уникальный идентификатор документа,

присвоенный при отправке отчёта о выбытии в

ГИС МТ.


Принцип генерации mdlpRequestId описан выше.

marks object Да Словарь марок, где каждый ключ - это

уникальный идентификатор марки в пределах

словаря марок.

localCheckStatus enum,

integer

Нет Статус локальной проверки. Перечисление со


0 – проверка не проводилась (для

симметричной криптографической системы);

1 – код маркировки проверен, достоверный;

2 – код маркировки проверен, недостоверный;

3 – проверка не проводилась

(криптографическая система асимметричная, но

в МБ РВ нет ключа с идентификатором

КПКИЗ);

4 – проверка не проводилась (криптоподпись 44

символа).

saleAllowed boolean Нет Разрешение на реализацию. Перечисление со


− true (разрешение получено);

− false (разрешение не получено).

onlineCheckStatus enum,

integer

Нет Статус проверок сервером. Перечисление со


0 – Прошла успешно;

1 – Не проводилась;

2 – Прошла не успешно.

onlineCheckError enum,

integer

Нет Код ошибки от сервера. Перечисление со


0 – Статус успешно изменён;

1 – КИЗ отсутствует в базе АС «Серверы

СКЗКМ» или ГИС МТ;

2 – Некорректный формат КИЗ;

3 – Не прошла криптографическая проверка

КПКИЗ;

4 – КИЗ имеет в базе АС «Серверы СКЗКМ»

статус не совместимый с запрашиваемым

изменением.

deviceError enum,

integer

Да Код ошибки РВ. Перечисление со значениями:

0 – Нет ошибок;

1 – Устройство недоступно;

2 – Устройство не функционирует;

3 – Отсутствует МБ РВ; 4 – Истек срок использования МБ РВ;

5 – МБ РВ блокирован;

6 – МБ РВ не функционален;

7 – РВ не зарегистрирован;

8 – Отсутствует связь с СЭ.

flcError enum,

integer

Да Код ошибки ФЛК. Перечисление со



1 – Не допустимое значение идентификатора

применения (GS AI) в КМ;

2 – Не допустимые символы КМ;

3 – Не допустимое количество символов в

составе идентификатора применения (GS AI);



поля



4 – Значение ТН ВЭД не относится к

фармацевтической продукции;

5 – Недопустимая последовательность групп в

КМ.

6 – Недопустимое значение доли от вторичной

упаковки

registrationStatus enum,

integer

Нет Статус регистрации КМ в СЭ. Перечисление со


0 – КМ зарегистрирован;

1 – КМ не зарегистрирован.

state enum,

integer

Нет Статус кода маркировки. Перечисление со


1 – Сформирован;

2 – Готов;

3 – Выдан;

4 – Выпущен;

5 – Не использован;

6 – Упакован;

7 – Распакован;

8 – Выбыл;

9 – Выбыл через розничную сеть;

10 – В состоянии выбытия;

11 – Утерян;

12 – Оборот приостановлен;

13 – Оборот запрещён;

14 – Потреблён;

15 – Дублирован;

16 – Выбыл через оптовую сеть.

Пример ответа на запрос статуса задания типа «регистрация отчета о выбытии по

реквизитам документа-основания» приведён в таблице ниже (Таблица 17).

Таблица 17 – Пример ответа на запрос регистрации отчёта о выбытии по реквизитам

документа-основания

Пример

{

"results":{

"status":"ready",

"result":{

"mdlpRequestId":"2ea26f1708844f08b120",

"marks":{

"1":{

"localCheckStatus":2,

"saleAllowed":true,

"onlineCheckStatus":0,

"onlineCheckError":0,

"deviceError":0,

"flcError":0,

"registrationStatus":0,

"state":8

},

"2":{


"saleAllowed":true,




"deviceError":0,

"flcError":0,


"state":8

},

"3":{


"saleAllowed":true,



"deviceError":0,

"flcError":0,


"state":8

}

}

}

}

}

Ответ на запрос статуса задания «проверить код маркировки»

Ответ на запрос статуса задания типа «проверить код маркировки» в случае его

готовности (статус задания задан как «ready») приведён в таблице ниже (Таблица 18).

Таблица 18 – Ответ на запрос статуса задания проверки кода маркировки




marks object Да Словарь марок, где каждый ключ - это

уникальный идентификатор марки в

пределах словаря марок.


integer

Нет Статус локальной проверки. Перечисление

со значениями:


симметричной криптографической

системы);


2 – код маркировки проверен,

недостоверный;


(криптографическая система

асимметричная, но в МБ РВ нет ключа с

идентификатором КПКИЗ.ид);


(криптоподпись 44 символа).

deviceError enum,

integer

Да Код ошибки РВ. Перечисление со





3 – Отсутствует МБ РВ;

4 – Истёк срок использования МБ РВ;





flcError enum,

integer

Да Код ошибки ФЛК. Перечисление со






1 – Не допустимое значение

идентификатора применения (GS AI) в КМ;



составе идентификатора применения (GS

AI);



5 – Недопустимая последовательность групп

в КМ.

Пример ответа на запрос статуса задания типа «проверить код маркировки» приведён

в таблице ниже (Таблица 19).

Таблица 19 – Пример ответа на запрос проверки кодов маркировки

Пример

{

"results":{

"status":"ready",

"result":{

"marks":{

"1":{


"deviceError":0,

"flcError":0

},

"2":{


"deviceError":0,

"flcError":0

},

"3":{


"deviceError":0,

"flcError":0

}

}

}

}

}

Ответ на запрос статуса задания «регистрация РВ»

Ответ на запрос статуса задания типа «регистрация РВ» в случае его готовности

(статус задания задан как «ready») приведён в таблице ниже (Таблица 20).

Таблица 20 – Ответ на запрос статуса задания регистрации РВ




registationRv enum,

integer

Да Результат регистрации РВ. Перечисление со


0 – РВ успешно зарегистрирован;




1 – Не удалось зарегистрировать РВ.

Пример ответа на запрос статуса задания типа «регистрация РВ» приведён в таблице

ниже (Таблица 21).

Таблица 21 – Пример ответа на запрос регистрации РВ

Пример

{

"results":{

"status":"ready",

"result":{

"registationRv":0

}

}

}

Ответ на запрос статуса задания в случае ошибки

Ответ на запрос статуса задания в случае ошибки выполнения запроса задания (статус

задания задан как «error») приведён в таблице ниже (Таблица 22).

Таблица 22 – Ответ на запрос статуса задания в случае ошибки



results object Да Результаты выполнения задания.

error object Нет Ошибка, заполняется при наличии ошибок,

если поле «status» имеет значение «error».




status enum,

string

Да Статус задания. Задано значение «error»

(задание выполнено без ошибок).

Пример ответа на запрос статуса задания в случае ошибки приведён в таблице ниже


Таблица 23 – Пример ответа на запрос статуса задания в случае ошибки

Пример

{

results":{

"error":{

"code":5090,

"description":"Внутренняя ошибка сервера"

},

"status":"error"

}

}

Описание ошибок

Коды ошибок в ответе на запрос статуса задания приведены в таблице ниже



Таблица 24 – Коды в ответе на запрос статуса задания

Код ошибки Описание

5003 Не корректно указан идентификационный код регистрации.

5010 Отсутствует авторизация пользователя.

5030 Введены не верные данные адреса выбытия.

5031 Введены не верные данные кода маркировки.

5090 Внутренняя ошибка сервера.


Метод «Отменить задание» (Delete)

Описание

Метод используется для отмены задания. Осуществляется с помощью запроса

DELETE путем указания идентификатора задания rvRequestId, которое требуется отменить.

Запрос

Метод: DELETE

Краткое наименование: Delete

URL: https://<server>[:port]/v1/requests/{rvRequestId}[?deviceId={deviceIdvalue}]


port – порт.


rvRequestId – уникальный идентификатор задания, присвоенный клиентом

(обязательный параметр).


В ответ будет возвращен код HTTP-статуса удаления задания из очереди. Коды

состояний в ответе на запрос удаления задания приведены в таблице ниже (Таблица 25).

Таблица 25 – Коды состояний в ответе на запрос удаления задания

Код состояния Описание

200 Задание успешно удалено.

404 Задание с заданным rvRequestId не найдено.

405 Задание с заданным rvRequestId нельзя удалить.


Метод «Запросить состояние РВ» (RequestStatusRv)

Описание

Метод используется для запроса состояния РВ. Осуществляется с помощью GET

запроса.

Запрос

Метод: GET

Краткое наименование: RequestStatusRv

URL: https://<server>[:port]/v1/state[?deviceId={deviceIdvalue}]


port – порт.

Параметры строки запроса:



Ответ на запрос состояния РВ приведён в таблице (Таблица 26).

Таблица 26 – Структура ответа на запрос состояния РВ




lifePhase enum,

string Да Состояние РВ. Перечисление со значениями:

− notRegistered - не зарегистрирован /

учебный режим;

− onRegistration - в процессе регистрации;

− registered - зарегистрирован;

− expired - истёк срок регистрации. processState enum,

string Да Состояние процесса обработки данных в РВ.

Перечисление со значениями:

− waiting - ожидание;

− checkCode - проверка кода;

− documentOpened - документ открыт;

− checkDocument - проверка документа. logState enum,

string Да Состояние журнала КМ с ошибками. Перечисление


− full – заполнен;

− empty – не заполнен;

− partial – частично заполнен. expirationDate string Да Дата истечении срока службы МБ РВ в

формате "yyyy-MM-dd'T'HH:mm:ss'Z'". С

округлением до минут.

Пример ответа на запрос состояния РВ приведён в таблице ниже (Таблица 27).

Таблица 27 – Пример ответа на запрос состояния РВ

Пример

{

"lifePhase":"registered",

"processState":"waiting",

"logState":"full",

"expirationDate":"2020-07-21T00:00:00Z"


}

Структура ответа с ошибкой на запрос состояния РВ приведена в таблице (Таблица

28).

Таблица 28 – Структура ответа с ошибкой на запрос состояния РВ


поля

Тип

поля



error object Да Ошибки. code integer Да Код ошибки. description string Да Описание ошибки.


Пример ответа с ошибкой приведён в таблице (Таблица 29).

Таблица 29 – Пример ответа с ошибкой

Пример

{

"error":{

"code":5090,


}

}


Коды ошибок ответа на запрос состояния РВ приведены в таблице ниже (Таблица

30).

Таблица 30 – Коды ошибок в ответе на запрос состояния РВ



5025 Не удалось получить состояние РВ.



Метод «Получить настройки интерфейсов обмена данными» (GetSettings)

Описание

Метод «Получить настройки интерфейсов обмена данными» используется для

получения настроек интерфейсов обмена данными. Осуществляется с помощью GET запрос.

Запрос

Метод: GET

Краткое наименование: GetSettings

URL: https://<server>[:port]/v1/settings[?deviceId={deviceIdvalue}]


port – порт.



Структура ответа на запрос получения настроек интерфейсов обмена данными

приведена в таблице ниже (Таблица 31).

Таблица 31 – Структура ответа на запрос получения настроек интерфейсов обмена данными



settings object Да Настройки соединения.

ethernet object Нет Канал связи Ethernet.

Примечание: поддержка Ethernet –

опциональна.

ipAddress string Да IP адрес.


IP-адрес должен соответствовать 4 версии

интернет протокола.

subnet string Да Маска подсети.


gateway string Да Шлюз.


dns string Нет Адрес DNS.


dynamicIp enum,

string

Да Динамический IP адрес. Перечисление со


− true;

− false.

iface string Нет Имя интерфейса в РВ.


hwAddress string Нет MAC-адрес интерфейса.


wifi object Нет Канал связи Wi-Fi.

networkName string Да Имя точки доступа или имя пользователя.


ipAddress string Да IP адрес.




subnet string Да Маска подсети.


gateway string Да Шлюз.





dns string Нет Адрес DNS.


dynamicIp enum,

string

Да Динамический IP адрес. Перечисление со


− true;

− false.



hwAddress string Нет MAC-адрес интерфейса.


usb object Нет Канал связи USB.

baudRate enum,

string

Нет Скорость обмена в бод. Перечисление со


− 1200;

− 2400;

− 4800;

− 9600;

− 14400;

− 38400;

− 57600;

− 115200;

− 230400;

− 460800;

− 921600.

dynamicIp enum,

string

Нет Динамический IP адрес. Перечисление со


− true;

− false.

gateway string Нет Шлюз.


ipAddress string Нет IP адрес.




subnet string Нет Маска подсети.




Пример ответа запроса получения настроек интерфейсов обмена данными приведён в


Таблица 32 – Пример ответа на запрос получения настроек интерфейсов обмена данными

Пример

{

"settings":{

"ethernet":{

"ipAddress":"0.0.0.0",

"subnet":"0.0.0.0",

"gateway":"0.0.0.0",

"dns":"0.0.0.0",

"dynamicIp":"false"

}

}

}

Структура ответа с ошибкой на запрос получения настроек интерфейсов обмена

данными приведена в таблице ниже (Таблица 33)


Таблица 33 – Структура ответа с ошибкой на запрос получения настроек интерфейсов обмена

данными


поля

Тип

поля





Пример ответа с ошибкой приведён в таблице ниже (Таблица 34).


Пример

{

"error":{

"code":5090,


}

}


Коды ошибок в ответе на запрос получения настроек интерфейсов обмена данными

приведены в таблице ниже (Таблица 35).

Таблица 35 – Коды ошибок в ответе на запрос получения настроек интерфейсов обмена

данными



5026 Не удалось получить настройки интерфейсов обмена данными.



Метод «Передать документы-основания» (GetInvoice)

Описание

Метод используется для передачи документов-основания. Может быть осуществлен

как с помощью POST запроса, когда РВ выступает в качестве сервера, так и с помощью GET

запроса, когда РВ выступает в качестве клиента.

Запрос POST передачи документов-основания

Метод: POST

Краткое наименование: GetInvoice

URL: https://<server>[:port]/v1/documents[?deviceId={deviceIdvalue}]


port – порт.


Запрос на передачу документов-оснований в РВ приведён в таблице ниже


Таблица 36 – Структура тела POST запроса на передачу документов-оснований


поля



documents array Да Документы-основания.

type enum,

integer



0 – Требование-накладная или аналогичный

документ;

1 – Рецепт.

number string Да Номер документа требование-накладная (ТН).


date string Да Дата документа ТН формате "yyyy-MM-

dd'T'HH:mm:ss'Z'".



items array Да Товары (лекарственные препараты).

gtin string Нет GTIN.



itemName string Да Наименование товара.


itemBatch string Нет Серия лекарственного препарата.

Максимальная длина 32.

quantity integer Да Затребованное количество товара.




Если поле присутствует, quantity должно быть

равно 1

Пример запроса на передачу документов-оснований в РВ приведён в таблице ниже


Таблица 37 – Пример POST запроса на передачу документов-оснований

Пример


{

"documents":[

{

"type":1,

"number":"123456",

"date":"2019-07-21T17:32:28Z",

"series":"9784363",

"items":[

{

"gtin":"04620032570010",

"itemName":"ВАЛИДОЛ, капсулы 100мг",

"itemBatch":"1012345678900987654321",

"quantity":10

}

]

}

]

}

Ответ на запрос POST

При отсутствии ошибок в ответ сервер вернёт код HTTP-статус 200.

В ответ сервер вернёт код HTTP-статуса передачи документов-оснований. Коды

состояний ответе на запрос записи задания приведены в таблице ниже (Таблица 38):

Таблица 38 – Коды состояний в ответе на запрос передачи документов-оснований



201 Документы-основания переданы.


409 Документ-основания с заданным number уже существует.


Запрос GET передачи документов-основания

Структура ответа на запрос передачи документов-оснований приведён в таблице ниже


Таблица 39 – Структура ответа на GET запрос передачи документов-оснований


поля



documents array Да Документы-основания.

type enum,

integer




документ;

1 – Рецепт.

number string Да Номер документа требование-накладная (ТН).


date string Да Дата документа ТН формате " yyyy-MM-dd".



items object Да Товары (лекарственные препараты).

gtin string Нет GTIN.



itemName string Да Наименование товара.


itemBatch string Нет Серия лекарственного препарата.


quantity integer Да Затребованное количество товара




Если поле присутствует, quantity должно быть

равно 1

Пример ответа на запрос передачи документов-оснований приведён в таблице ниже


Таблица 40 – Пример ответа на GET запрос передачи документов-оснований

Пример

{

"documents":[

{

"type":1,

"number":"123456",

"date":"2019-07-21",

"series":"9784363",

"items":[

{

"gtin":"04620032570010",

"itemName":"ВАЛИДОЛ, капсулы 100мг",

"itemBatch":"1012345678900987654321",

"quantity":10

}

]

}

]


}

Структура ответа с ошибкой на GET запрос передачи документов-оснований

приведена в таблице ниже (Таблица 41).

Таблица 41 – Структура ответа с ошибкой на GET запрос передачи документов-оснований


поля

Тип

поля






Пример ответа с ошибкой приведён в таблице ниже (Таблица 42).


Пример

{

"error":{

"code":5090,


}

}


Коды ошибок в ответе на запрос передачи документов-оснований приведены в


Таблица 43 – Коды ошибок в ответе на запрос передачи документов-оснований





Метод «Получить информацию об устройстве» (GetInformationRv)

Описание

Метод используется для получения информации об устройстве. Осуществляется с

помощью запроса GET.

Запрос

Метод: GET

Краткое наименование: GetInformationRv

URL: https://<server>[:port]/v1/deviceInfo[?deviceId={deviceIdvalue}]


port – порт.



Структура ответа запроса информации об устройстве приведена в таблице ниже


Таблица 44 – Структура ответа на пакет запроса информации об устройстве



devices array Да Устройства. Список если вызов обращен

к драйверу РВ КМ на ПК.

id string Да Уникальный идентификатор устройства.


connectionType enum,

string

Да Тип подключения. Перечисление со


− usb – разъем USB;

− wifi – сеть Wi-Fi;

− ethernet – локальная сеть.

modelInfo string Да Сведения о модели (исполнении)

технического средства АС СКЗКМ.


softwareVersion string Да Версия программного обеспечения РВ

КМ

deviceSerialNumber string Да Серийный номер технического средства,

строка-идентификатор из 16 буквенно-

цифровых символов.


moduleSerialNumber string Да Серийный номер модуля безопасности

технического средства, строка-

идентификатор из 16 буквенно-

цифровых символов.


startDateRegistration string Нет Дата регистрации в формате "yyyy-MM-

dd'T'HH:mm:ss'Z'".

endDateRegistration string Нет Дата окончания регистрации в формате

"yyyy-MM-dd'T'HH:mm:ss'Z'".

timeBlock string Нет Время до блокировки РВ с момента

потери сигнала спутника в формате

"'T'HH:mm:ss'Z'".




suid string Нет Идентификатор субъекта деятельности

МДЛП.


Пример ответа на запрос информации об устройстве приведён в таблице ниже


Таблица 45 – Пример ответа на запрос информации об устройстве

Пример

{

"devices": [

{

"id":"123456789",

"connectionType":"usb",

"modelInfo":"Модель РВ КМ",

"softwareVersion":"1.24",

"deviceSerialNumber":"6521658DSE795874",

"moduleSerialNumber":"6521BAFE79587400",

"registarionNumber":"12345",

"startDateRegistration":"2019-07-21T17:32:28Z",

"endDateRegistration":"2020-06-20T17:32:28Z",

"timeBlock":"T20:03:00Z"

}

]

}

Структура ответа ошибки на запрос получения информации об устройстве приведена


Таблица 46 – Структура ответа ошибки на запрос информации об устройстве





Пример ответа с ошибкой запрос получения информации об устройстве приведён в



Пример

{

"error":{

"code":5090,

"description":" Внутренняя ошибка сервера"

}

}



Коды ошибок в ответе на запрос получения информации об устройстве приведены в


Таблица 48 – Коды ошибок в ответе на запрос информации об устройстве





Метод «Получить результаты обработки отчетов о выбытии» (GetResult)

Описание

Метод используется для получения результатов обработки отчетов о выбытии. Может

быть осуществлен как с помощью запроса GET, когда РВ обращается к облачному серверу,

так и с помощью запроса POST, когда ТУС либо ПО клиента ФГИС МДЛП присылает

результат обработки в РВ. Метод не обязателен для реализации.

Запрос GET получения результатов обработки отчетов о выбытии

Метод: GET

Краткое наименование: GetResult

URL: https://<server>[:port]/v1/documents/results[?deviceId={deviceIdvalue}]


port – порт.


Ответ на запрос GET

Ответ на пакет GET запроса получения результатов обработки отчетов о выбытии

приведён в таблице ниже (Таблица 49).

Таблица 49 – Структура ответа на пакет GET запроса получения результатов обработки

отчетов о выбытии

Название поля Тип поля Обязательные


documentList array Да Список запрашиваемых документов.

mdlpRequestId string Да Идентификатор транзакции mdlpRequestId из

МДЛП.


result array Да Результат обработки документа.

gtin string Да GTIN.


serialNumber string Да Серийный номер.


error object Да Ошибки.




Пример ответа на запрос получения результатов обработки отчетов о выбытии

приведён в таблице ниже (Таблица 50).

Таблица 50 – Пример ответа на пакет GET запроса получения результатов обработки отчетов

о выбытии

Пример {

"documentList":[

{

"mdlpRequestId":"123123",

"result":[


{

"gtin":"4260076865026",

"serialNumber":"1234567890"

}

]

}

]

}

Структура ответа с ошибкой на запрос получения результатов обработки отчетов о

выбытии представлена в таблице ниже (Таблица 51).

Таблица 51 – Структура ответа с ошибкой на запрос получения результатов обработки




еrror object Да Ошибки. сode integer Да Код ошибки. description string Да Описание ошибки.


Пример ответа с ошибкой на запрос получения результатов обработки отчетов о

выбытии приведён в таблице ниже (Таблица 52).


Пример

{

"error":{

"code":5090,


}

}


Ошибки в ответе на запрос получения результатов обработки отчетов о выбытии с

помощью запроса GET приведены в таблице ниже (Таблица 53).

Таблица 53 – Коды ошибок в ответе на пакет GET запроса получения результатов обработки






Запрос POST получения результатов обработки отчетов о выбытии

Структура запроса получения результатов обработки отчетов о выбытии приведена в


Таблица 54 – Структура пакета POST запроса для получения результатов обработки отчетов о

выбытии

Название поля Тип поля Обязательные


documentList array Да Список запрашиваемых документов.

mdlpRequestId

string Да Идентификатор транзакции mdlpRequestId из

МДЛП.


result array Да Результат обработки документа.



serialNumber string Да Серийный номер.


error object Да Ошибки.




Пример запроса получения результатов обработки отчетов о выбытии приведён в


Таблица 55 – Пример пакета POST запроса получения результатов обработки отчетов о

выбытии

Пример {

"documentList":[

{


"result":[

{

"gtin":"4260076865026",

"serialNumber":"1234567890"

}

]

}

]

}



В ответ код HTTP-статуса выполнения запроса. Коды состояний приведены в таблице

ниже (Таблица 56):


Таблица 56 – Коды состояний в ответе на запрос получения результатов обработки отчетов о

выбытии


200 Результат обработки отчетов получен.


409 Результат обработки отчета по транзакции id уже получен.


Метод «Получить отчёты о выбытии» (GetReports)

Описание

Метод используется для получения отчётов о выбытии. Осуществляется с помощью

GET запроса. Метод не обязателен для реализации.

Запрос

Метод: GET

Краткое наименование: GetReports

URL: https://<server>[:port]/apis/v1/documents/reports?deviceId={deviceIdvalue}&date=

yyyy-MM-dd'T'HH:mm:ss'Z]


port – порт.


deviceId – уникальный идентификатор устройства (обязательный параметр).

date – дата, начиная с которой требуется получение отчетов о выбытии.


Структура запроса получения отчетов о выбытии представлена в таблице ниже


Таблица 57 – Структура запроса получения отчетов о выбытии


поля

Тип

поля



document object Да Отчёт о выбытии.

type enum,

string




документ;

1 – Рецепт.

number string Да Номер документа о выбытии.

Максимальное длина 64 символов.

date string Да Дата отчёта о выбытии формате "yyyy-MM-

dd'T'HH:mm:ss'Z'".

mdlpRequestId string Да Идентификатор транзакции mdlpRequestId из

МДЛП.


documentOut object Да Реквизиты документа-основания.

number string Да Номер требования-накладной.


date string Да Дата документа ТН формате "yyyy-MM-dd".



gtins array Да Массив GTINS.



completed enum,

string

Да Признак подтверждения выбытия. Перечисление со


− true;

− false.

serial string Нет Серийный номер ЛП.



поля

Тип

поля




description string Нет Наименование ЛП согласно номенклатуре ИС

МДЛП.





Пример ответа на запрос выгрузки отчетов о выбытии приведен в таблице ниже


Таблица 58 –Пример ответа на запрос выгрузки отчетов о выбытии

Пример

{

"document":{

"type":"invoice",

"number":"123321",

"date":"2019-07-23T17:32:28Z",


"documentOut":{

"number":"12345",

"date":"2019-07-21",

"series":"9784363",

},

"gtins":[

{

"gtin":"4260076865026",

"completed":"true"

},

{

"gtin":"4260076865026",

"completed":"true"

},

{

"gtin":"4260076865026",

"completed":"true"

}

]

}

}

Структура ответа с ошибкой на запрос получения отчета о выбытии приведена в









Коды ошибок в ответ на запрос получения отчетов о выбытии приведены в таблице


Таблица 60 – Коды ошибок в ответе на запрос получения отчетов о выбытии





Метод «Получить номенклатуру из ФГИС МДЛП» (GetNomenclature)

Описание

Метод используется для загрузки в РВ номенклатуры из ФГИС МДЛП. Метод не

обязателен для реализации.

Запрос

Метод: POST

Краткое наименование: GetNomenclature

URL: https://<server>[:port]/v1/nomenclatureRefresh[?deviceId={deviceIdvalue}]


port – порт.

deviceId – уникальный идентификатор устройства



В ответ сервер вернёт код HTTP-статуса получения номенклатуры из ФГИС МДЛП.

Коды состояний ответе на запрос получения номенклатуры из ФГИС МДЛП приведены в

таблице ниже (Таблица 613):

Таблица 613 – Коды состояний в ответе на запрос получения номенклатуры из ФГИС МДЛП



200 Успешное получение номенклатуры из ФГИС МДЛП.



Метод «Запросить статус обмена с ФГИС МДЛП» (NomenclatureState)

Описание

Метод используется получения статуса загрузки номенклатуры из ИС МДЛП. Метод

не обязателен для реализации.

Запрос

Метод: GET

Краткое наименование: NomenclatureState

URL: https://<server>[:port]/v1/nomenclatureState[?deviceId={deviceIdvalue}]


port – порт.

deviceId – уникальный идентификатор устройства

Ответ на запрос GET

Таблица 64 – Структура на пакет GET запроса статуса обмена с ФГИС МДЛП



count integer Нет Общее количество GTIN локальной БД

РВКМ.

lastSync string Нет Дата последней синхронизации в формате "yyyy-MM-dd'T'HH:mm:ss'Z'".

state enum,

string

Нет Состояние синхронизации. Перечисление со


− Синхронизация не проведена;

− Запущен процесс синхронизации;

− Синхронизация завершена.

loadingProgress object Нет Прогресс загрузки.

local Integer Нет Количество загруженных GTIN.

remote Integer Нет Общее количество GTIN в ИС МДЛП.

Пример ответа на запрос статуса обмена с ФГИС МДЛП приведен в таблице ниже ().

Таблица 65 –Пример ответа на запрос статуса обмена с ФГИС МДЛП

Пример

{

"count":1632,

"lastSync":"2019-07-23T17:32:28Z",

"state":"Запущен процесс синхронизации",

"loadingProgress":{

"local":2136,

"remote":5478

}

}

Структура ответа с ошибкой на запрос статуса обмена с ФГИС МДЛП представлена



Таблица 66 – Структура ответа с ошибкой на запрос статуса обмена с ФГИС МДЛП



еrror object Да Ошибки. сode integer Да Код ошибки. description string Да Описание ошибки.


Пример ответа с ошибкой на запрос статуса обмена с ФГИС МДЛП приведён в



Пример

{

"error":{

"code":5090,


}

}


Ошибки в ответе на запрос статуса обмена с ФГИС МДЛП с помощью запроса GET

приведены в таблице ниже (Таблица 53).

Таблица 68 – Коды ошибок в ответе на пакет GET запроса статуса обмена с ФГИС МДЛП





Общий список ошибок

Общий список ошибок приведён в таблице ниже (Таблица 62Ошибка! Источник

ссылки не найден.).

Таблица 62 – Коды ошибок


5003 Не корректно указан идентификационный код регистрации.


5025 Не удалось получить состояние РВ.

5026 Не удалось получить настройки интерфейсов обмена данными.

5030 Введены не верные данные адреса выбытия.

5031 Введены не верные данные кода маркировки.



Приложение Б. «API ГИС МТ Выгрузка журналов»


Взаимодействие регистратора выбытия с ГИС МТ осуществляется посредством

набора унифицированных методов REST API, с использованием формата JSON (см. Рисунок

6). Взаимодействие должно осуществляться по протоколу HTTPS.

Рисунок 2 - Взаимодействие РВ КМ и ГИС МТ в части отправки журналов.

Алгоритм взаимодействия

Для безопасного взаимодействия РВ КМ с ГИС МТ, Поставщик должен обеспечить

механизм аутентификации и авторизации, а также проработать меры безопасного

использования пароля: хранение, передача (см. раздел 4.1.4).

Метод запроса POST предназначен для запроса, при котором информационная

система, выступающая в качестве web-сервера, принимает данные, заключённые в тело

сообщения, для хранения. Клиент (АРВ) отправляет серверу запрос, в ответ сервер присылает

HTTP-статус запрошенной операции. Взаимодействие представлено на рисунке ниже

(Рисунок 7).

Client Web-server

POST

Result

Рисунок 3 - Взаимодействие с Web-сервером

Примеры заголовка запроса и ответа приведены в таблицах ниже (Таблица 63 и

Таблица 64).


Таблица 63 – Пример заголовка запроса (метод POST)

Пример

POST /apis/v1/log?deviceId=12345678 HTTP/1.1




Content-Length: 298

{Body}

Таблица 64 - Пример заголовка ответа на запрос

Пример

HTTP/1.1 200 OK


Content-Length: 908

Описание методов

Для выполнения соответствующего метода необходимо отправить его запрос на URL.

В случае положительного результата выполнения метода сервер вернёт его статус или в случае

отрицательного результата вернёт описание возникшей ошибки.

Метод «Выгрузить журнал КМ с ошибками в ГИС МТ»

Описание

Для выгрузки журнала КМ с ошибками в ЛК ЦРПТ необходимо отправить POST

запрос.

Запрос

Метод: POST

URL: https://<server>[:port]/apis/v1/log[?deviceId={deviceIdvalue}]


port – порт.



Запрос выгрузки журнала КМ с ошибками приведен в таблице ниже (Таблица 65).

Таблица 65 – Структура тела запроса выгрузки журнала КМ с ошибками


поля Обязательные поля Ограничения

log array Да Журнал КМ с ошибками.


Максимальная длина 226 символов при длине

кода 169 символов.

date string Да Дата отчёта о выбытии формате "yyyy-MM-

dd'T'HH:mm:ss'Z'".

stage enum,

string

Да Стадия проверки КМ. Перечисление со


− ФЛК;

− Проверка КМ в МБ РВ;

− Выбытие.



поля Обязательные поля Ограничения

errors object Да Ошибки КМ.


integer

Нет Статус локальной проверки. Перечисление со



симметричной криптографической системы);


2 – код маркировки проверен,

недостоверный;


(криптографическая система асимметричная,

но в МБ РВ нет ключа с идентификатором

КПКИЗ);

4 – проверка не проводилась (криптоподпись

44 символа).

onlineCheckStatus enum,

integer

Нет Статус проверок сервером. Перечисление со


1 – Не проводилась;

2 – Прошла не успешно.

onlineCheckError enum,

integer

Нет Код ошибки от сервера КМ. Перечисление со


1 – КИЗ отсутствует в базе АС «Серверы

СКЗКМ» или ГИС МТ;

2 – Некорректный формат КИЗ;

3 – Не прошла криптографическая проверка

КПКИЗ;

4 – КИЗ имеет в базе АС «Серверы СКЗКМ»

статус не совместимый с запрашиваемым

изменением.

deviceError enum,

integer

Нет Код ошибки РВ. Перечисление со










flcError enum,

integer

Нет Код ошибки ФЛК. Перечисление со


1 – Не допустимое значение идентификатора

применения (GS AI) в КМ;



составе идентификатора применения (GS AI);



5 – Недопустимая последовательность групп

в КМ;

6 – Недопустимое значение доли от

вторичной упаковки.

registrationStatus enum,

integer

Нет Статус регистрации КМ в СЭ. Перечисление


1 – КМ не зарегистрирован.

Пример запроса выгрузки журнала КМ с ошибками в ГИС МТ приведены в таблице


Таблица 66 – Пример запроса выгрузки журнала КМ с ошибками в ГИС МТ



{

"log":[

{

"mark":"MDEwMTIzNDU2Nzg5MTIzNTIxMDAwMDAwMDAwMDAwNh0yNDAxMjM0HTEwMDEyMzQ1Njc4OUFCQ0RFRjEyMzQdMTcxNz

A5MTE5MTExMjkdOTJqNFZPemdHMlkvVXoxQ1ZoTWQzV25CNlRxVmp1cUZzZTIzQkJobUNFMldyQWczc2VJeUlDS2hiUlI4S29n

ZnVaajFhUEQwVmhKSUMzVzBqbUFoaDYrdz09",

"date":"2019-07-23T17:32:28Z",

"stage":"Выбытие",

"errors":{




"registrationStatus":1

}

}

]

}


В ответ сервер вернёт код HTTP - статуса добавления журнала КМ с ошибками. Коды

состояний ответа на запрос выгрузки журнала КМ с ошибками приведены в таблице ниже

(Таблица 67):

Таблица 67 – Коды состояний в ответе на запрос выгрузки журнала КМ с ошибками


201 Журнал КМ с ошибками загружен в ГИС МТ.


409 Журнал КМ с ошибками за дату уже существует.


Метод «Инициировать выгрузку журнала КМ с ошибками»

Описание

Метод «Инициировать выгрузку журнала КМ с ошибками» используется для

принудительной передачи журнала КМ с ошибками в ГИС МТ. Осуществляется с помощью

метода GET.

Запрос

Метод: GET

URL: https://<server>[:port]/apis/v1/log[?deviceId={deviceIdvalue}]


port – порт.




В ответ сервер вернёт код HTTP - статуса инициации выгрузки журнала КМ с

ошибками. Коды состояний ответа на запрос выгрузки журнала КМ с ошибками приведены в

таблице ниже (Таблица 75):

Таблица 75 – Коды состояний в ответе на запрос выгрузки журнала КМ с ошибками


201 Инициирована выгрузка журнала КМ с ошибками.



Метод «Выгрузить журнал самодиагностики РВ КМ в ГИС МТ»

Описание

Для выгрузки журнала самодиагностики РВ КМ в ГИС МТ необходимо отправить

POST запрос.

Запрос

Метод: POST

URL: https://<server>[:port]/apis/v1/diagnostics[?deviceId={deviceIdvalue}]


port – порт.



Запрос выгрузки журнала самодиагностики РВ КМ приведен в таблице ниже (Таблица

76Таблица 76).

Таблица 76 - Структура тела запроса выгрузки журнала самодиагностики


поля



diagnostics array Да Журнал самодиагностики РВ КМ.

date string Да Дата и время самодиагностики в формате "yyyy-

MM-dd'T'HH:mm:ss'Z'".

status object Да Статус самодиагностики РВ КМ.

softwareStatus enum,

integer

Да Целостность образа ПО. Перечисление со


0 – Ошибки отсутствуют;

1 – Наличие ошибок в программном обеспечении

РВ КМ;

communicationStatus enum,

integer

Да Работоспособность коммуникационного модуля.



1 – Наличие ошибок в коммуникационном модуле;

deviceStatus enum,

integer

Да Работоспособность и состояние МБ РВ.











powerStatus enum,

integer

Да Работоспособность модуля электропитания.



1 – Наличие ошибок в электропитании;

Пример запроса выгрузки журнала самодиагностики РВ КМ в ГИС МТ приведены в


Таблица 77 – Пример запроса выгрузки журнала самодиагностики РВ КМ в ГИС МТ



{

"diagnostics":[

{

"date":"2019-07-23T17:32:28Z",

"status":{

"softwareStatus":0,

"communicationStatus":1,

"deviceStatus":0,

"powerStatus":0

}

}

]

}


В ответ сервер вернёт код HTTP - статуса добавления журнала самодиагностики РВ

КМ. Коды состояний ответа на запрос выгрузки журнала самодиагностики РВ КМ приведены

в таблице ниже (Таблица 78Таблица 78):

Таблица 78 – Коды состояний в ответе на запрос выгрузки журнала самодиагностики РВ КМ


201 Журнал самодиагностики загружен в ГИС МТ.


409 Журнал самодиагностики за дату уже существует.


Приложение В. «Описание процесса выбытия ЛП»


Описанный ниже процесс выбытия ЛП приведён в соответствии с действующими

методическими рекомендациями. Процесс выбытия учитывает особенности и структуры

кодов маркировки ЛП, находящихся в обороте. На рынке будут находиться в обороте ЛП, на

которые нанесены средства идентификации содержащие коды маркировки одного их

следующих типов:

1) Коды маркировки, что наносились на ЛП до интеграции ИС МДПЛ с

инфраструктурой криптографической защиты кодов маркировки.

2) Коды маркировки, сформированные в соответствии с последними методическими

рекомендациями:

a) С применением симметричного алгоритма шифрования

b) С применением асимметричного алгоритма шифрования

Регистратор выбытия должен осуществлять выбытие (формировать отчёт об

изменении статусов кодов маркировки) всех трёх типов. Все три типа кодов маркировки

наносятся на ЛП в символике GS1 DataMatrix.

Состав данных кодов маркировки

В данном разделе приведён состав данных кодов маркировки.

Код маркировки с применением ассиметричного алгоритма шифрования

Код включает в себя группы данных, приведённые в таблице ниже (Таблица 82).

Таблица 82 – Данные кода маркировки с применением ассиметричного алгоритма

шифрования

Группа

данных Длина Формат

GS AI Комментарий

1. 14 Цифры

01

Код товара по соответствующей

товарной номенклатуре (GTIN)

2. 13

Символьная строка

(см. раздел

«допустимые

символы кодов

маркировки»

21 + FNC1 (ASCII 29) Код идентификации упаковки

лекарственного препарата

3. 4


(см. раздел



маркировки»

91 + FNC1 (ASCII 29) Идентификатор ключа подписи. В

ассиметричной системе – это 16

битный идентификатор открытого

ключа, которым подписан КМ.

4. 44 или

88


(см. раздел


92. Если производитель

добавляет после данной

Код проверки. ЭП



маркировки»)

группы свои данные, то

+ FNC1 (ASCII 29)

Последовательность групп данных в коде маркировки

Требования к последовательности групп данных в структуре средств идентификации

предъявляется к первой группе данных, которая всегда должна располагаться в начале, а также

к AI 91 и AI92, которые всегда располагаются в конце кода маркировки. Добавление групп

данных не оговорённых в МР допустимо только после кода проверки.

ВАЖНО: Ряд производителей могут использовать другие AI, которые они добавляют

после AI92. Данное обстоятельство необходимо учесть при обработке кода маркировки

Допустимые символы кодов маркировки

Допустимые символы кодов маркировки приведены в таблице ниже (Таблица 84).

Таблица 84 – Допустимые символы кодов маркировки

Допустимые символы кодов маркировки

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!”%&’*+-./_,:;=<>?

Данные символы используются в следующих группах данных кодов маркировки:

1) Серийный номер.

2) Идентификатор ключа.

3) Код проверки.

Экспериментальные коды маркировки, выпущенные с применением

несертифицированного крипто-оборудования и без него.

Экспериментальные коды маркировки, выпущенные с применением

несертифицированного крипто-оборудования и без него могут находиться в обороте.

Сертифицированное оборудование (МБ РВ) будет выдавать ошибку локальной проверки. Так

как в период отладки инфраструктуры криптографической защиты кодов маркировки (2019

год) будет действовать уведомительная система выбытия, данные коды должны быть

выведены из оборота посредством отчёта об изменении статусов кодов маркировки, точно так

же, как коды, выпущенные на сертифицированном оборудовании. МБ РВ должен позволять

добавить в отчёт об изменении статусов кодов маркировки коды, выпущенные до интеграции

ИС МДПЛ с системой криптозащиты кодов маркировки. Так как экспериментальные коды

маркировки отсутствуют в БД СКЗКМ, их онлайн проверка не может быть проведена.

По данной группе кодов маркировки, пользователь сможет ознакомиться с

результатом обработки отчёта об изменении статусов кодов маркировки (форма 200) в личном

кабинете в ФГИС МДЛП, либо в ПО, через интеграцию с ФГИС МДЛП.


Если пользователь использует РВ КМ, он может ознакомиться с результатами

обработки отчёта об изменении статусов кодов маркировки только в личном кабинете ФГИС

МДЛП.

Идентификатор системы выбытия

Система выбытия определяет режим контроля при выводе из оборота маркированной

продукции.

1) При разрешительной системе: товары, не прошедшие локальную и/или онлайн

проверку, невозможно добавить в отчёт об изменении статусов КМ (отчёт об операции с

КМ). При разрешительной системе не должна производиться операция с КМ, если

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

2) При уведомительной системе: пользователь уведомляется о результатах

проведённых проверок и принимает решение о выбытии. При уведомительной системе

можно проводить операцию, если онлайн проверка не проводилась, а также при

некоторых вариантах отрицательного результата онлайн проверки (регламентируется

Регуляторами отрасли). В любом случае, пользователь уведомляется о результатах.

Идентификатор системы выбытия представляет собой бит в поле идентификатора

ключа подписи (AI 91). Данный бит предоставляет информацию считывающей технике, каким

образом обрабатывать результаты проверок. Идентификатор системы выбытия применяется

только к кодам маркировки, которые защищены при помощи асимметричного алгоритма

шифрования. Для кодов, защищённых при помощи симметричного алгоритма шифрования,

информация о применяемой товару системе выбытия проверяется онлайн, одновременно с

проверкой самого кода маркировки, при наличии связи с сервером эмиссии. В будущем, при

разработке НПА регламентирующих системы выбытия будет выделен отдельный AI для

идентификатора системы.

Процесс выбытия

МБ РВ требует чётко определённой последовательности операций для правильной

регистрации выбытия. Данная последовательность не всегда согласуется с реальными

процессами формирования списков выбытия ЛП в медицинских организациях. Адаптация

алгоритмов работы МБ РВ к автоматизируемым бизнес-процессам производится средствами

ПО и РВ, для этого процесс выбытия разделён на 2 итерации:

1) Формирование списка выбытия. Выполняется средствами ПО. завершается

формированием списка выбытия внутри РВ.

2) Формирование отчёта об изменении статусов КМ. Выполняется средствами МБ РВ.


Пользователь в ЛПУ в процессе выбытия может обслуживать несколько заявок на

выдачу ЛП или льготных рецептов, на каждую заявку он может/должен сформировать

отдельный список выбытия в ПО. Описанный ниже процесс предусматривает возможность

формирования списков выбытия, последующей обработки списков с применением МБ РВ и

их отправки в ГИС МТ. Результатом обработки списка выбытия в МБ РВ являются отчёт об

изменении статусов КМ, отправляемый в ГИС МТ через СЭ, и уведомление пользователю о

формировании отчёта об изменении статусов КМ. Уведомление можно рассматривать как

аналог кассового чека, выдаваемого ККТ. Печать уведомления не обязательна, оно может

быть выведено на экран автономного устройства, при его наличии, либо передано в учётную

систему в электронном виде. Уведомление содержит ссылку на документ-основание для

выбытия, идентификатор отчёта об изменении статусов КМ, сформированный МБ РВ, и

результат отправки отчёта в СЭ (подтверждение об успешной приёмке отчёта).

В процессе формирования отчёта об изменении статусов КМ, ПО ведёт журнал

исключений, в который заносятся все КМ, не прошедшие локальную проверку или онлайн

проверку. Данный отчёт необходим для оценки работы МБ РВ и должен отсылаться в ГИС

МТ средствами ПО или РВ. Текущая версия протокола работы МБ РВ не предоставляет ни

возможности вести данный журнал, ни средств его отправки в ГИС МТ. Поэтому данная

функция должна быть реализована ПО или РВ.

Общая схема процесса выбытия представлена на рисунке ниже (Рисунок 4). Более

подробное описание шагов выбытия приведено ниже.


Рисунок 4 – Общая схема процесса выбытия

Общий процесс выбытии включает следующие основные шаги:

1. Пользователь инициирует процесс выбытия.

2. Пользователь указывает реквизиты документа основания и сохранят в ПО РВ.

3. Сканирует коды маркировки и формирует список выбытия.

4. По завершению формирования списка выбытия, пользователь подтверждает

начало формирования отчёта о выбытии.

5. После завершения формирования и отправки отчёта о выбытии, при

необходимости процесс выбытия может повториться.


Формирование списка выбытия

Схема формирования списка выбытия с локальной проверкой представлена на

рисунке ниже (Рисунок 5).

Рисунок 5 – Схема формирования списка выбытия с локальной проверкой

Процесс формирования списка выбытия начинается с поступления КМ и состоит из

следующих шагов:

1. ПО РВ проверяет наличие КМ в списке выбытия.


1.1. Если КМ есть в списке, то проводиться информирование пользователя об

ошибке.

2. ПО РВ активирует проверку КМ на предмет ФЛК (форматно-логический контроль).

2.1. Если проверка ФЛК пройдена успешно, то далее осуществляется переход к

шагу 3.

2.2. Если получена ошибка проверки ФЛК, то производится фиксирование КМ в

списке журнала КМ с ошибками. Далее производится информирование пользователя

об ошибке.

3. По факту получения успешного результата проверки на ФЛК, ПО РВ осуществляет

проверки включена ли локальная проверка КМ при формировании списка выбытия

(локальна проверка КМ является опциональной при формировании списка выбытия)

3.1. В случае если локальная проверка включена, ПО РВ проверяет возможность

проведения локальной проверки.

− Если локальная проверка КМ возможна, то ПО РВ выполняет

локальную проверку (см. подраздел «Локальная проверка кода маркировки»).

− Если результат локальной проверки КМ успешный, то производится

переход к шагу 4.

− Если результат локальной проверки КМ не успешный, то производится

информирование пользователя об ошибке с последующим уточнением

решения по выбытию данного КМ с ошибкой. Если пользователь не

подтверждает выбытие, то данный КМ не заносится в список КМ для

выбытия. Если пользователь подтверждает выбытие, то производится

переход к шагу 4.

− Если локальная проверка КМ не возможна, то производится переход к

шагу 4.

4. ПО РВ запрашивает торговое наименование ЛП, количество и GTIN и отображает

полученные данные о ЛП.

5. ПО РВ проверяет наличие срока годности в данных КМ:

5.1. Если срок годности есть в КМ, то производится переход на следующий шаг

(шаг 6).

5.2. Если срока годности нет в данных КМ, то ПО РВ производит информирование

пользователя об отсутствии срока годности с последующим уточнением решения по

возможности добавления ЛП в список выбытия.


− Если пользователь не подтверждает выбытие, то данный ЛП не

заносится в список выбытия (процесс завершается).

− Если пользователь подтверждает выбытие, то производится переход

на шаг 7.

6. ПО РВ выполняет проверку срока годности:

6.1. Если срок годности не истек, то осуществляется переход на следующий шаг

(шаг 7).

6.2. Если срок годности истек, то ПО РВ производит информирование пользователя

об истечении срока годности с последующим уточнением решения по добавлению

ЛП в список выбытия.

− Если пользователь не подтверждает выбытие, то данный ЛП не

заносится в список выбытия (процесс завершается).

− Если пользователь подтверждает выбытие, то производится переход

на следующий шаг (шаг 7).

7. ПО РВ производит необходимость задания количества выбиваемых единиц ЛП (шаг

выполняется только в случае, если получены данные о количестве из ТУС, - иначе шаг

пропускаем):

7.1. Если задано, что ЛП неделимый (не нужно указывать количество), то

производится переход на следующий шаг (шаг 8).

7.2. Если задано, что ЛП составной, то ПО РВ запрашивает у пользователя

количество выбываемых единиц.

− Пользователь вводит количество.

− ПО РВ проверяет, что введенное количество не превышает общее

количество единиц, входящих в состав данного ЛП – иначе выводится

предупреждающее сообщение о превышении.

− ПО РВ фиксирует введенное выбываемое количество, производится

переход на следующий шаг (шаг 8).

8. ПО РВ добавляет КМ в список выбытия.

9. Процесс добавление КМ в список выбытия завершён.


Локальная проверка кода маркировки

Схема проверки кода маркировки представлена на рисунке ниже (Рисунок 10).

Рисунок 6 – Схема проверки КМ

Процесс локальной проверки кода начинается с поступления КМ и состоит из

следующих шагов:

1. При получении запроса ПО РВ локальной проверки КМ, запускается процесс

локальной проверки КМ для чего:

1.1. ПО РВ активирует вызов команды 51(Локальная проверка КМ).

1.2. МБ РВ выполняет команду 51 и возвращает результат проверки в ПО РВ.

1.3. ПО РВ осуществляет анализ результата локальной проверки:

− Если получен успешный результат локальной проверки КМ сохраняет

результат проверки для включения в список выбытия.

− Если получена ошибка проверки, то производится фиксирование КМ

в списке журнала КМ с ошибками и сохраняет результат проверки.

2. Процесс локальной проверки КМ завершён.

Локаль

на

я п

рове

рка К

М

ПО РВ МБ РВ

Активировать вызов

локальной проверки КМ

Результат

успешный?

Выполнить команду 51Команда 51

Запрос локальной

проверки КМ

Получен результат


Нет

Да

Сохранить КМ в журнал

КМ с ошибками

Сохранить результат

проверки


Формирование отчёта о выбытии

Схема формирования отчёта о выбытии представлена на рисунке ниже (Рисунок 7).

Рисунок 7 – Формирование отчёта о выбытии

Процесс формирования отчёта о выбытии начинается подтверждения пользователя о

начале формирования отчёта о выбытии и состоит из следующих шагов:

1. Пользователь активирует запуск процесса формирования отчёта о выбытии.


2. ПО РВ начинает проверку отдельного КМ и проверяет возможность локальной


2.1. Если локальная проверка возможна, то запускается процесс локально проверки

КМ, далее осуществляется переход на следующий шаг (шаг 3).

2.2. Если локальная проверка не возможна, то осуществляется переход на

следующий шаг (шаг 3).

3. ПО РВ проверяет возможность онлайн проверки КМ.

3.1. Если онлайн проверка возможна, то запускается процесс онлайн проверки КМ

списка КМ отчёта о выбытии, далее осуществляется переход на следующий шаг (шаг

4)

3.2. Если онлайн проверка не возможна, то осуществляется переход на следующий

шаг (шаг 4).

4. ПО РВ вносит КМ в список отчёта об изменении статуса и проверяет есть ли ещё

КМ в списке выбытия, если есть, то осуществляется переход на шаг 2, если нет

осуществляется переход к следующему шагу (шаг 5).

5. ПО РВ открывает соединение.

5.1. Если соединение открыто не успешно, то ПО РВ производит обработку

ошибки, формирует сообщение об ошибке и информирует о результатах выполнения

пользователя (процесс завершается).

5.2. Если соединение открыто успешно, осуществляется переход на следующий

шаг (шаг 6).

6. ПО РВ активирует вызов команды 32 (Запрос статуса МБ РВ).

6.1. Если статус МБ РВ не корректный, то ПО РВ производит обработку ошибки,

формирует сообщение об ошибке и информирует о результатах выполнения

пользователя (процесс завершается).

6.2. Если статус МБ РВ корректный, осуществляется переход на следующий шаг

(шаг 7).

7. ПО РВ активирует вызов команды 67 (Формирование отчёта о выбытии). В команде

передается статус в который должен быть переведен КМ. В зависимости от типа

документа основания передается значение статуса 9 для рецепта и значение статуса 8 для

прочих документов.

8. МБ РВ выполняет команду 67 (Формирование отчёта о выбытии).

9. ПО РВ проверяет наличие ошибок.


9.1. Если результат выполнения команды 67 имеет ошибки, то ПО РВ производит

обработку ошибки, формирует сообщение об ошибке и информирует о результатах

выполнения пользователя (процесс завершается).

9.2. Если результат выполнения команды 67 не имеет ошибок, то осуществляется

переход на начало процесса выбытия.

10. На основе таймера (не менее 1 раза в секунду) ПО РВ активирует вызов команды 32

(Запрос статуса МБ РВ).

11. МБ РВ выполняет команду 32 и возвращает статус МБ РВ в ПО РВ.

12. ПО РВ анализирует состояние статуса МБ РВ:

12.1. Если статус корректный, то осуществляется переход к следующему шагу (шаг

12).

12.2. Если статус некорректный, то данная информация передаётся в ПО клиента,

который в свою очередь информирует пользователя о невозможности выбытия

(процесс завершается).

13. ПО РВ по факту получения успешного результата проверки статуса МБ РВ, ПО РВ

активирует вызов команды 65 (Формирование запроса из внутренней очереди).

14. МБ РВ выполняет команду 65 (Формирование запроса из внутренней очереди) и

возвращает контейнер с формированным отчётом о выбытии в ПО РВ.

14.1. Если результат выполнения команды 65 содержит ошибки, то данная

информация передаётся Пользователю информируя его о невозможности выбытия

(процесс завершается).

14.2. Если результат выполнения команды 65 не содержит ошибки, осуществляется

переход на следующий шаг (шаг 14).

15. ПО РВ формирует пакет с ER-header, данными, CRC.

16. ПО РВ переедает «пакет FQMS» в ГИС МТ (СЭ), контейнер с сформированным

отчётом о выбытии сопровождаемый метаданными указанными в таблице ниже (см.

Таблица 85 и Таблица 86)

17. По факту получения ответа от ГИС МТ (СЭ) о получении отчёта о выбытии, ПО РВ

активирует вызов команды 75 (Обработка ответа на запрос из внутренней исходящей

очереди).

18. МБ РВ выполняет команду 75 и возвращает результат ответа на отправку отчёта о

выбытии.

19. ПО РВ сохраняет результат выполнения команды 75 в квитанцию.

20. ПО РВ проверяет есть имеются ли ещё данные для обработки:


20.1. Если имеются ещё данные, то осуществляется переход на шаг 16.

20.2. Если данных для обработки нет, то осуществляется переход на следующий шаг

(шаг 20).

21. ПО РВ закрывает соединение.

22. ПО РВ формирует результат выбытия.

23. ПО РВ передаёт в ПО клиента результат ответа на отправку отчёта о выбытии.

24. Пользователь информируется о результате ответа на отправку отчёта о выбытии.

Таблица 85 - Структура метаданных

Наименование Описание

DODT docDate, Реквизиты документа: дата регистрации льготного рецепта, дата

документа основания выдачи, дата нанесения. Формат передачи дд.мм.гггг. DONM docNum, Реквизиты документа, на основании которого осуществлена

выдача - номер, номер льготного рецепта DOSE docSeries, Реквизиты документа: номер серии льготного рецепта

SRID mdlpRequestId. UUID отчета об изменении статусов кодов маркировки

SUID subjectId, Идентификатор субъекта обращения в ИС “Маркировка”

DOTY docType. Тип документа основания. Значения:

• Prescription – рецепт;

• Other – требование-накладная или иной документ-основание.

Таблица 86 – Пример структуры метаданных

Пример

TaggedData[] = {

(TaggedData){ (TaggedDataHeader){

{ "D", "O", "D", "T" },

20 },

"21.07.2019" };

(TaggedData){ (TaggedDataHeader){

{ "D", "O", "N", "M" },

2 },

"36" };

(TaggedDataHeader){

{ "D", "O", "S", "E" },

7

},

"VI-1234"

}

;

(TaggedDataHeader){

{ "S", "R", "I", "D" },

36

},

"434bc499-4b85-4775-8c19-bf6dbf730e93"

}

;

(TaggedDataHeader){

{ "S", "U", "I", "D" },

14

},


"00000000002220"

}

;

(TaggedDataHeader){

{ "D", "O", "T", "Y" },

12

},

"Prescription"

}

}


Онлайн проверка КМ при выбытии

Схема онлайн проверки КМ при формировании отчёта о выбытии представлена на

рисунке ниже (Рисунок 8).

Рисунок 8 – Онлайн проверка КМ

Процесс онлайн проверки КМ начинается по факту запуска формирования отчёта о

выбытии и состоит из следующих шагов:

1. ПО клиента передаёт список КМ, подготовленных для выбытия.

2. ПО РВ выделяет отдельный КМ и начинает его проверку.

3. ПО РВ активирует вызов команды 63 (Формирование запроса на удалённую

проверку КМ).

Он

лай

н п

ров

ер

ка К

М

ПО РВ СЭМБ РВ

Активировать формирование

запроса на удаленную

проверку КМ

Обработать запрос

проверки КМПакет RQMS


Отправить пакет с КМ на

проверку

Активировать обработку

ответа на удаленную

проверку КМ


Получен пакет с КМ для проверки

Запрос онлайн проверки КМ

Результат

успешный?

Да

Нет

Сохранить КМ в журнал

КМ с ошибками

Сохранить результат

проверки

Ответ получен?

Да

НетПрекратить онлайн

проверку для всех КМ

Получен результат

выполнения команды

Проверка прекращается только

после нескольких попыток


4. МБ РВ выполняет команду 63 и возвращает контейнер с КМ в ПО РВ.

5. ПО РВ осуществляет отправку контейнера с КМ в ГИС МТ для проверки (СЭ).

6. По факту получения из ГИС МТ (СЭ) ответа проверки кода ПО РВ активирует вызов

команды 73 (Обработка ответа на удалённую проверку КМ).

7. МБ РВ выполняет команду 73 и возвращает результат проверки в ПО РВ.

8. ПО РВ анализирует результат проверки КМ:

8.1. Если результат проверки неуспешный, то производится фиксирование КМ в

списке журнала КМ с ошибками. Далее производится переход к следующему шагу.

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

9. По факту завершения проверки кода ПО РВ осуществляет проверку наличия других

КМ, еще не прошедших онлайн проверку.

9.1. В случае наличия КМ, не прошедших проверку, осуществляется проверка

очередного отдельного КМ – переход к шагу 1.

9.2. В случае отсутствия КМ, прошедших проверку, осуществляется возврат к

процессу формирования отчёта о выбытии.


Отправка журнала КМ с ошибками

Схема отправки журнала КМ с ошибками представлена на рисунке ниже (Рисунок

9).

Рисунок 9 – Схема отправки журнала КМ с ошибками

Процесс отправки журнала КМ запускается на основе событий (плановое время

отправки, закончилась свободная память, запрос пользователя на отправку журнала) и состоит

из следующих шагов:

1. ПО РВ формирует пакет с журналом КМ с ошибками;

2. ПО РВ отправляет сформированный журнал на шаге 1 в ГИС МТ.

3. ГИС МТ обработав запрос возвращает результат получения журнала КМ с ошибками

4. ПО РВ сохраняет результат отправки журнала.


Приложение Д. «Структура файлов обмена»

Структура файла списка документов основания

РВ КМ должен позволять записать в каталог на устройстве список позиций

документов-оснований в виде файла со структурой csv, описанной в таблице ниже (Таблица

87).

Файл должен иметь наименование documents.csv. Разделителем полей в файле

является символ «|». Два разделителя подряд должны распознаваться как символ разделителя

в составе значения поля.

Таблица 87 – Список полей файла со списком позиций документов-оснований


поля



Тип документа enum,

integer




документ;

1 – Рецепт.

Номер string Да Номер документа требование-накладная (ТН).


Дата string Да Дата документа ТН формате "dd.MM.yyyy".

Серия string Нет Серия документа-основания.


GTIN string Нет GTIN.



Наименование товара string Нет Наименование товара.


Серия ЛП string Нет Серия лекарственного препарата.


Количество товара integer Да Затребованное количество товара




Если поле присутствует, «Количество товара»

должно быть равно 1

Пример содержимого файла приведен в таблице ниже (Таблица 88Таблица 88).

Таблица 88 – Пример содержимого файла documents.csv

Тип

докуме

нта

Номе

р Дата Серия GTIN

Наименов

ание

товара

Серия ЛП

Количес

тво

товара

soldP

art

1 1234

56

03.05.2

019

97843

63

0462003257

0010

ВАЛИДО

Л, капсулы

100мг

1012345678900987

654321 10

0 1254

87

26.05.2

019

0245679543

1254

Кагоцел

таблетки

12 мг, №30

1245789654123547

125474 1

2/3

Структура файла списка отчетов о выбытии

РВ КМ должен записывать в каталог устройства список отсканированных в ходе

формирования списка отчетов о выбытии SGTIN в виде файла со структурой csv, описанной в


таблице ниже (Таблица 89). Срок хранения файлов в РВ КМ составляет 5 дней с последующим

самоудалением.

Файл должен иметь наименование “reports<subjectId><date>.csv”, где subjectId –

идентификатор субъекта обращения в ИС «МДЛП», а date – дата в формате <DDMMYYYY>.

Разделителем полей в файле является символ «|». Два разделителя подряд должны

распознаваться как символ разделителя в составе значения поля.

Таблица 89 – Список полей файла со списком отчетов о выбытии


поля



Тип документа enum,

integer




документ;

1 – Рецепт.

Номер string Да Номер документа требование-накладная (ТН).


Дата string Да Дата документа ТН формате "dd.MM.yyyy".

Серия string Нет Серия документа-основания.


SGTIN string Да SGTIN.






mdlpRequestId string Нет Идентификатор транзакции mdlpRequestId из

МДЛП.


Пример содержимого файла приведен в таблице ниже (Таблица 90).

Таблица 90 – Пример содержимого файла reports0000000000222020190531.csv

Тип

докум

ента

Ном

ер Дата

Сери

я SGTIN

Наимено

вание

товара

Серия ЛП soldP

art

mdlpReq

uestId

1 123

456

03.05.

2019

9784

363

04620032570010qw

ertyuioplkj

ВАЛИД

ОЛ,

капсулы

100мг

10123456789009

87654321

12/2

4

0794f0d6

-ef80-

11e9-

81b4-

2a2ae2db

cce4

0 125

487

26.05.

2019

02456795431254qaz

xswedcvfrt

Кагоцел

таблетки

12 мг,

№30

12457896541235

47125474 1/15

7ff7dffb-

50b6-

40c6-

acb8-

1105c3e7

3e2f

Documents

Выдержка из технической спецификацииhttps://честныйзнак.рф/upload/iblock/92b/TC...2019/06/07 · добавлять поле следующего