Вы находитесь на странице: 1из 72

СТАНЦИЯ УПРАВЛЕНИЯ ЗАКАЗАМИ

(ORDER MANAGEMENT STATION)

Спецификация API
(API Specification)

Версия 2.8
(Version 2.8)
ФАРМА
PHARMA
Содержание
1. Введение (Introduction) .................................................................................................................. 1
2. Сокращения, определения (Terminology) ....................................................................................... 3
3. Общее описание (General description)............................................................................................ 4
4. Описание процесса (General description process) ........................................................................... 6
4.1 01.01.00.00 Создать заказ на эмиссию КМ (Create order for emission IC) .............................. 7
4.2 01.02.00.00 Получить статус массива КМ из бизнес-заказа (Get IC buffer status) ................ 12
4.3 01.03.00.00 Получить КМ из бизнес-заказа (Get ICs from the order) .................................... 16
4.4 01.04.00.00 Отправить отчёт об использовании КМ (Send IC utilisation report to OMS)....... 20
4.5 Буфер хранения кодов маркировки внутри СУЗ (ICs storage buffer in the OMS).................. 24
5. Описание API (API description).................................................................................................... 25
5.1 Описание API (API description) ........................................................................................... 25
5.1.1 Проверить доступность СУЗ (Ping OMS) ........................................................................ 25
5.1.1.1 Запрос (Request)...................................................................................................... 26

5.1.1.2 Ответ на запрос (Response to request) ...................................................................... 26

5.1.2 Создать бизнес-заказ на эмиссию кодов маркировки (Create order for emission IC) ........ 27
5.1.2.1 Запрос (Request)...................................................................................................... 28

5.1.2.2 Ответ на запрос (Response to request) ...................................................................... 31

5.1.3 Получить статус массива КМ из бизнес-заказа (Get IC buffer status)............................... 32


5.1.3.1 Запрос (Request)...................................................................................................... 33

5.1.3.2 Ответ на запрос (Response to request) ...................................................................... 33

5.1.4 Получить КМ из бизнес-заказа (Get ICs from the order) .................................................. 36


5.1.4.1 Запрос (Request)...................................................................................................... 36

5.1.4.2 Ответ на запрос (Response to request) ...................................................................... 38

5.1.5 Отправить отчёт об использовании КМ (Send IC utilisation report to OMS) ..................... 39


5.1.5.1 Запрос (Request)...................................................................................................... 40

5.1.5.2 Ответ на запрос (Response to request) ...................................................................... 45

5.1.6 Получить статус бизнес-заказов (Get status orders) ......................................................... 46


5.1.6.1 Запрос (Request)...................................................................................................... 47

5.1.6.2 Ответ на запрос (Response to request) ...................................................................... 47

5.1.7 Закрыть подзаказ по заданному GTIN (Close IC array for the specified product GTIN) ..... 49
5.1.7.1 Запрос (Request)...................................................................................................... 50

5.1.7.2 Ответ на запрос (Response to request) ...................................................................... 51


5.1.8 Получить статус обработки отчёта (Get status processing report)..................................... 52
5.1.8.1 Запрос (Request)...................................................................................................... 53

5.1.8.2 Ответ на запрос (Response to request) ...................................................................... 53

5.2 Справочники (Dictionary).................................................................................................... 55


5.2.1 Справочник №1 «Способ формирования индивидуального серийного номера» (Voc. №1
«Method of generation of individual serial number») ....................................................................... 55
5.2.2 Справочник №2 «Шаблоны КМ» (Voc №2 «Template IC») .............................................. 55
5.2.3 Справочник №3 «Статус массива КМ» (Voc №3 «IC array status») ................................. 57
5.2.4 Справочник №4 «Статус буфера КМ» (Voc №4 «IC buffer status»).................................. 58
5.2.5 Справочник №5 «Статус обработки отчёта» (Voc №5 «Report Processing Status») .......... 59
5.2.6 Справочник №6 «Тип использования» (Voc №6 «Usage Type»)....................................... 60
5.2.7 Справочник №7 «Статус бизнес заказа» (Voc №7 «Order status») ................................... 61
5.3 Формат и коды ошибок (Format and error codes).................................................................. 63
5.3.1 Формат ошибки (Error format)......................................................................................... 63
5.3.2 Описание ошибок (Error description) ............................................................................... 64
6. Список изменений (List of changes).............................................................................................. 65

3
1. Введение (Introduction)

Контроллер API REST аутентифицирует клиентов с помощью так называемого


клиентского токена, отправляемого клиентом в заголовке HTTP-запроса. Маркер
безопасности (ClientToken) передаётся в заголовке HTTP () клиентского токена –
«clientToken».

Некоторые методы API при отправке данных используют метод HTTP POST. В таких
случаях следует использовать указание дополнительного HTTP-заголовка – «Content-Type:
application/json».

Методы API СУЗ в качестве параметров используют идентификатор СУЗ «omsId»,


идентификатор СУЗ «omsId» доступен в настройках СУЗ.

API REST controller authenticates the clients by so-called client token sent by the client
in the HTTP request header. The client token HTTP header name is “clientToken”.

Some API calls require sending data using HTTP POST method. In such cases you should
use specify additional HTTP Header - Content-Type: application/json.

API methods of the OMS as parameters use the ID «Omsid», the ID «Omsid» is available
in the settings of the OMS.

Допустимые символы КМ приведены ниже в таблице. Данные символы используются


в следующих группах данных кодов маркировки: «Идентификатор ключа», «Код проверки».

Valid characters IC are listed in the table below. These symbols are used in the following
groups of marking code data: “Key identifier”, “Verification code”.

Таблица 1 – Допустимые символы КМ (Table 1 – Valid characters of IC)

Допустимые символы КМ. Valid characters IC

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!”%&’()*+,
-./_:;=<>?

СУЗ поддерживает возможность заказа КМ в двух режимах (на усмотрение субъекта


обращения):

− генерация КМ с использованием предоставленных субъектом обращения


серийных номеров;

− генерация КМ с одновременной генерацией серийных номеров.

1
OMS supports ordering IC in two modes (chosen by the client):

− generation of IC using the serial numbers provided by the client («Self-made» mode);

− generation of IC with the generation of serial numbers («Generated by Information


System MDLP operator» mode).

2
2. Сокращения, определения (Terminology)

Таблица 2 – Сокращения, определения (Table 2 – Glossary)

Термин Описание
Term Description

Автоматизированная система управления технологическими процессами или иная


АСУТП,
информационная система клиента, осуществляющая взаимодействие с СУЗ
Automated process
Automated process control system or another client information system integrating with
control system
the OMS

Информационная система мониторинга движения лекарственных препаратов


ИС МДЛП
для медицинского применения
Information System
Marking Information System - MDLP

КМ, Код маркировки


IC Identification Codes

РЭ Устройство регистрации эмиссии (регистратор эмиссии)


Emission Registrar Emission Registrar

СУЗ Станция управления заказами.


OMS Order management station

СЭ Сервер эмиссии
Emission Server Emission Server

ФЛК запроса Осуществление форматно логического контроля


Check Request Format-logical control

3
3. Общее описание (General description)

В данном разделе приведено описание API СУЗ, взаимодействие осуществляется


по протоколу HTTP, используя формат JSON.

This section describes the OMS API, the interaction is carried out using the HTTP protocol,
using the JSON format.

Ниже представлена последовательность вызова методов СУЗ при создании нового


бизнес заказа на эмиссию КМ (Below is the sequence of call of OMS methods when creating
a new business order for issuing a IC):

1. Проверить доступность СУЗ (Ping OMS).

2. Создать бизнес-заказ на эмиссию кодов маркировки (Create order for emission IC).

3. Получить статус массива КМ из бизнес-заказа (Get IC buffer status).

4. Получить КМ из бизнес-заказа (Get ICs from the order).

5. Отправить отчёт об использовании КМ (Send IC utilisation report to OMS).

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


в обычном процессе взаимодействия с СУЗ (Optional methods):

1. Получить статус бизнес-заказов (Get status orders).

2. Закрыть подзаказ по заданному GTIN (Close IC array for the specified product
GTIN).

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


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

Примечание: при наличии не использованных кодов маркировки при закрытии заказа,


будет сформирован и отправлен отчёт об изменении статуса кодов маркировки,
не использованным КМ будет присвоен статус «ELIMINATED» (не использован).
Closing an order is used when there is no need for marking codes that remain unused in this
order. Fully used orders are closed automatically. Note: when the order with codes is closing, all
remaining codes will be canceled.

4
Note: if there are unused marking codes when closing an order, a report will be generated and
sent on changing the status of marking codes that are not used by the CM and will be assigned
the status “ELIMINATED” (not used).
Диаграмма последовательности вызова методов СУЗ представлена на рисунке ниже
(Рисунок 1 ). Diagram of the call sequence of the OMS methods is presented in the figure below
(see Figure 1).

API СУЗ также предоставляет вспомогательные методы (The OMS API also provides
helper methods):

− Получить статус обработки отчёта (Get status processing report).

Метод предназначен для получения статуса отправленного отчета о нанесении кодов


маркировки. This method is used to receive status processing report.

Рисунок 1. Последовательность вызова методов СУЗ (Figure 1. Sequence of calling OMS methods)

5
4. Описание процесса (General description process)

В данном разделе приведено общее описание процесса эмиссии кодов маркировки.


Общий процесс эмиссии КМ включает четыре ключевых этапа:

1. «01.01.00.00 Создать заказ на эмиссию КМ»;

2. «01.02.00.00 Получить статус массива КМ из бизнес-заказа»;

3. «01.03.00.00 Получить КМ из бизнес-заказа»;

4. «01.04.00.00 Отправить отчёт об использовании КМ».

This section provides a general description of the process of issuing marking codes.
The overall emission process of the IC includes four key stages.

1. «01.01.00.00 Create order for emission IC»;

2. «01.02.00.00 Get IC buffer status»;

3. «01.03.00.00 Get ICs from the order»;

4. «01.04.00.00 Send IC utilisation report».

6
4.1 01.01.00.00 Создать заказ на эмиссию КМ (Create order for emission IC)

Диаграмма процесса создания заказа на эмиссию КМ приведена на рисунке ниже


(см. Ошибка! Источник ссылки не найден.).

Рисунок 2. Создать заказ на эмиссию КМ

Описание:

1. АСУТП формирует бизнес-заказ и отправляет его в СУЗ.

2. СУЗ проводит проверку запроса и отправляет заказ в Регистратор эмиссии.

3. Регистратор эмиссии формирует запрос содержащий заказ на эмиссию КМ и отправляет


его в Сервер эмиссии.

4. Сервер эмиссии, получив запрос, содержащий заказ на эмиссию КМ, производит


проверку запроса:

4.1. В случае если запрос содержит ошибки, Сервер эмиссии регистрирует ошибку
в журнале.

4.2. Сервер эмиссии формирует сообщение об ошибке и отправляет в Регистратор


эмиссии.
7
4.3. Осуществляется переход на шаг 8 основного сценария.

5. Сервер эмиссии при отсутствии ошибок, проверяет заказ на эмиссию КМ:

5.1. В случае если запрос содержит ошибки, Сервер эмиссии регистрирует ошибку
в журнале.

5.2. Сервер эмиссии формирует сообщение об ошибке и отправляет в Регистратор


эмиссии.

5.3. Осуществляется переход на шаг 8 основного сценария.

6. Сервер эмиссии при отсутствии ошибок в заказе на эмиссию КМ присваивает заказу


идентификатор и рассчитывает время готовности заказа:

6.1. Сервер эмиссии отправляет заказ на обработку (действие выполняется


асинхронно).

7. Сервер эмиссии формирует ответное сообщение и отправляет в Регистратор эмиссии.

8. Регистратор эмиссии получает результат обработки запроса.

9. Регистратор эмиссии проверяет наличие ошибок:

9.1. В случае если сообщение содержит ошибки, Регистратор эмиссии регистрирует


ошибку в журнале.

9.2. Регистратор эмиссии формирует сообщение об ошибке и отправляет в СУЗ.

9.3. Осуществляется переход на шаг 12 основного сценария.

10. Регистратор эмиссии при отсутствии ошибок формирует пустой пул КМ:

10.1. Регистратор эмиссии ожидает время готовности заказа и запрашивает


эмитированные КМ в Сервере эмиссии (действие выполняется асинхронно).

11. Регистратор эмиссии отправляет ответное сообщение в СУЗ.

12. СУЗ получает результат обработки запроса от Регистратора эмиссии.

13. СУЗ проверяет наличие ошибок:

13.1. СУЗ при наличии ошибок регистрирует ошибку в журнале.

13.2. СУЗ формирует сообщение об ошибке и отправляет в АСУТП.

13.3. Осуществляется переход на шаг 16 основного сценария.

14. СУЗ при отсутствии ошибок создаёт массив КМ:

8
14.1. СУЗ ожидает время готовности заказа и запрашивает эмитированные КМ
в Регистраторе эмиссии (действие выполняется асинхронно).

15. СУЗ формирует ответное сообщение и отправляет в АСУТП.

16. АСУТП получает результат обработки запроса от СУЗ.

17. АСУТП проверяет наличие ошибок:

17.1. АСУТП при наличии ошибок регистрирует ошибку в журнале.

17.2. Процесс завершается.

18. АСУТП при отсутствии ошибок сохраняет данные заказа:

18.1. АСУТП инициирует выполнение процесса 01.02.00.00 «Получить статус массива


КМ из бизнес-заказа» (действие выполняется асинхронно).

19. Процесс завершается.

A diagram of the process of creating an order for emission IC is shown in the figure below
(see Figure 3).

Figure 3. Create order for emission IC

9
Description:

1. APCS forms a business order and sends it to the OMS.

2. The OMS conducts the verification of the request and sends the order to the Emission Registrar.

3. The Emission Registrar forms a request containing an order for the emission ICs and sends it
to the Emission Server.

4. Emission Server receives a request containing an order for the emission ICs, checks
the request:

4.1. In case the request contains errors, the Emission Server logs an error in the log.

4.2. The Emission Server generates an error message and sends it to the Emission Registrar.

4.3. The transition to step 8 of the main scenario Is carried out.

5. The Emission Server, in the absence of errors, checks the order for the emission of ICs:

5.1. In case the request contains errors, the Emission Server logs an error in the log.

5.2. The Emission Server generates an error message and sends it to the Emission Registrar.

5.3. The transition to step 8 of the main scenario Is carried out.

6. The Emission Server if there are no errors in the order for the emission of ICs, assigns the order
ID and calculates the time of order readiness:

6.1. The Emission Server sends the order for processing (the action is performed
asynchronously).

7. The Emission Server forms a response message and sends it to the Emission Registrar.

8. The Emission Registrar receives the result of processing the request.

9. The Emission Registrar checks for errors:

9.1. In case the message contains errors, the Emission Registrar registers an error
in the journal.

9.2. The Emission Registrar generates an error message and sends it to the OMS.

9.3. The transition to step 12 of the main scenario Is carried out.

10. The Emission Registrar generates an empty pool of ICs in the absence of errors:

10.1. The Emission Registrar waits for the order readiness time and requests the emitted ICs
in the Emission Server (the action is performed asynchronously).

10
11. The Emission Registrar sends a reply message to the OMS.

12. The OMS receives the result of the request processing from the Emission Registrar.

13. The OMS checks for errors:

13.1. In case of errors, logs an error in the log.

13.2. The OMS generates an error message and sends it to the APCS.

13.3. The transition to step 16 of the main scenario Is carried out.

14. The OMS creates an array of ICs in the absence of errors:

14.1. The OMS expects the time of readiness of the order and requests the emitted ICs
in the Emission Registrar (the action is performed asynchronously).

15. The OMS forms a reply message and sends it to the APCS.

16. The APCS receives the result of processing the request from the OMS.

17. The APCS checks for errors:

17.1. In case of errors, registers an error in the log.

17.2. The Process is completed.

18. If there are no errors, the APCS saves the order data:

18.1. The APCS initiates the 01.02.00.00 process «Get IC buffer status» (the action is
performed asynchronously).

19. The Process is completed.

11
4.2 01.02.00.00 Получить статус массива КМ из бизнес-заказа (Get IC
buffer status)

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


(см. Рисунок 6).

АСУТП СУЗ

Идентификатор заказа и GTIN Запрос статуса КМ из бизнес-заказа

Время готовности
заказа
Проверить ФЛК
запроса
Сформировать
01.02.00.00 «Получить статус массива КМ из бизнес-заказа»

Да запрос статуса КМ из
Проверить наличие
бизнес-заказа
ошибок

Да Нет
Ошибки есть?

Зарегистрировать
ошибку в журнале

Сформировать Получить
сообщение об информацию о
ошибке массиве КМ
Проверить наличие
ошибок Сформировать
ответное
сообщение
Нет Да
Есть ошибки?
Статус буфера КМ
равен «PENDI NG»?
Зарегистрировать Ответное сообщение
ошибку в журнале включает информацию о
буфере и массивах КМ
Нет Статус буфера КМ
равен «ACTIVE»?

Нет
Да

01.03.00.00
«Получить КМ из
бизнес-заказа» Завер шение

Рисунок 4. Получить статус массива КМ из бизнес-заказа

Описание:

1. АСУТП ожидает время готовности заказа.

2. АСУТП формирует запрос получения статуса массива КМ и отправляет его в СУЗ.

3. СУЗ проводит проверку запроса.


12
4. СУЗ проверяет наличие ошибок:

4.1. В случае если запрос содержит ошибки, СУЗ регистрирует ошибку в журнале.

4.2. СУЗ формирует сообщение об ошибке и отправляет в АСУТП.

4.3. Осуществляется переход на шаг 7 основного сценария.

5. СУЗ получает информацию о массиве КМ.

6. СУЗ формирует ответное сообщение и отправляет в АСУТП.

7. АСУТП получает ответное сообщение.

8. АСУТП проверяет наличие ошибок:

8.1. В случае если запрос содержит ошибки, АСУТП регистрирует ошибку в журнале.

8.2. Процесс завершается.

9. АСУТП при отсутствии ошибок проверяет статус буфера КМ – равен «PENDING»:

9.1. В случае если статус буфера КМ равен «PENDING», АСУТП инициирует


повторный запрос статуса массива КМ.

9.2. Осуществляется переход на шаг 1 основного сценария.

10. АСУТП при отсутствии ошибок, проверяет статус буфера КМ – равен «ACTIVE»:

10.1. В случае если статус буфера КМ не равен «ACTIVE» процесс завершается.

11. В случае если статус буфера КМ равен «ACTIVE», АСУТП инициирует выполнение
процесса 01.03.00.00 «Получить КМ из бизнес-заказа» (действие выполняется
асинхронно).

12. Процесс завершается.

A diagram of the process of obtaining the status of an array of IC is shown in the figure below
(see Figure 5).

13
Figure 5. Get IC buffer status

Description:

1. The APCS expects the time of order readiness.

2. The APCS forms a request to obtain the status of the array of ICs and sends it to the OMS.

3. The OMS conducts the request verification.

4. The OMS checks for errors:

4.1. In case the request contains errors, the OMS logs an error in the log.

4.2. The OMS generates an error message and sends it to the APCS.

4.3. The transition to step 7 of the main scenario Is carried out.

5. The OMS receives information about the ICs array.

6. The OMS forms a response message and sends it to the APCS.

7. The APCS receives a response message.

14
8. The APCS checks for errors:

8.1. In case the request contains errors, the APCS registers an error in the log.

8.2. The process is completed.

9. The APCS in the absence of errors, checks the status of the buffer ICs equals «PENDING»:

9.1. If the status of the IC buffer is equal to «PENDING», the APCS initiates a repeated
request for the status of the IC array.

9.2. The transition to step 1 of the main scenario is carried out.

10. APCS in the absence of errors, checks the status of the IC buffer equals «ACTIVE»:

10.1. If the status Of the IC buffer is not equal to «ACTIVE» the process terminates.

11. If the status of the IC buffer is «ACTIVE», the APCS initiates the process of 01.03.00.00 «Get
IC from the order» (the action is performed asynchronously).

12. The process is completed.

15
4.3 01.03.00.00 Получить КМ из бизнес-заказа (Get ICs from the order)

Диаграмма процесса получения КМ из бизнес заказа приведена на рисунке ниже


(см. Рисунок 6).

АСУТП СУЗ

Идентификатор заказа, GTIN и количество запрашиваемых кодов Запрос КМ из бизнес-заказа

Проверить ФЛК
запроса
Сформировать
запрос КМ из бизнес-
заказа Проверить наличие
ошибок
01.03.00.00 «Получить КМ из бизнес-заказа»

Да Нет
Ошибки есть?

Зарегистрировать
ошибку в журнале

Сформировать Сформировать
сообщение об массив
ошибке эмитированных КМ
Проверить наличие
ошибок Сформировать
ответное
сообщение
Нет Да
Есть ошибки?

Обработать ответное Зарегистрировать Ответное сообщение


сообщение ошибку в журнале включает информацию о
буфере и массивах КМ

Есть ещё КМ в
заказе?
Нет

Да Требуется загрузить
КМ из заказа?

Да Нет

Эмитированные КМ загружаются
блоками, при загрузке следующего Завер шение
блока в запросе должен
указываться параметр «lastBlockId»
- Идентификатор блока кодов,
выданных в предыдущем запросе.

Рисунок 6. Получить КМ из бизнес-заказа

Описание:

1. АСУТП формирует запрос получения КМ из бизнес заказа и отправляет его в СУЗ.

2. СУЗ проводит проверку запроса.

3. СУЗ проверяет наличие ошибок:

3.1. В случае если запрос содержит ошибки, СУЗ регистрирует ошибку в журнале.

16
3.2. СУЗ формирует сообщение об ошибке и отправляет в АСУТП.

3.3. Осуществляется переход на шаг 6 основного сценария.

4. СУЗ формирует массив эмитированных КМ.

5. СУЗ формирует ответное сообщение и отправляет в АСУТП.

6. АСУТП получает ответное сообщение.

7. АСУТП проверяет наличие ошибок:

7.1. В случае если запрос содержит ошибки, АСУТП регистрирует ошибку в журнале.

7.2. Процесс завершается.

8. АСУТП обрабатывает полученное сообщение.

9. АСУТП проверяет есть ли ещё КМ в заказе:

9.1. В случае если КМ в заказе отсутствуют, процесс завершается.

10. При наличии КМ в заказе, АСУТП проверяет, требуется ли загрузка оставшихся КМ:

10.1. В случае если требуется загрузить оставшиеся КМ в заказе, АСУТП инициирует


повторное выполнение процесса 01.03.00.00 «Получить КМ из бизнес-заказа».

10.2. Осуществляется переход на шаг 1 основного сценария.

11. В случае если не требуется загрузка оставшихся КМ в заказе, то процесс завершается.

A diagram of the process of obtaining a CM from a business order is shown in the figure
below (see Figure 7).

17
Figure 7. Get IC buffer status

Description:

1. The APCS forms a request to receive ICs from the business order and sends it to the OMS.

2. The OMS conducts the request verification.

3. The OMS checks for errors:

3.1. In case the request contains errors, the OMS logs an error in the log.

3.2. The OMS generates an error message and sends it to the APCS.

3.3. The transition to step 6 of the main scenario Is carried out.

18
4. The OMS forms an array of emitted ICs.

5. The OMS forms a response message and sends it to the APCS.

6. The APCS receives a response message.

7. The APCS checks for errors:

7.1. In case the request contains errors, the APCS registers an error in the log.

7.2. The process is completed.

8. The APCS processes the received message.

9. The APCS checks if there are more IC in the order:

9.1. In case the IC is absent in the order, the process is completed.

10. If there is an IC in the order, the AOP checks whether the remaining IC is required to be
downloaded:

10.1. If it is necessary to load the remaining IC in the order, the company initiates
the re-execution of the process 01.03.00.00 «Get IC from the order».

10.2. The transition to step 1 of the main scenario is carried out.

11. If you do not need to download the remaining ICs in the order, the process is completed.

19
4.4 01.04.00.00 Отправить отчёт об использовании КМ (Send IC utilisation
report to OMS)

Диаграмма процесса отправки отчёта об использовании КМ приведена на рисунке ниже


(см. Рисунок 8).

Рисунок 8. Отправить отчет об использовании КМ

Описание:

1. АСУТП формирует запрос, содержащий отчёт об использовании КМ и отправляет его


в СУЗ;

2. СУЗ проводит проверку запроса и отправляет запрос содержащий отчёт


об использовании КМ в Регистратор эмиссии.

3. Регистратор эмиссии формирует запрос, содержащий отчёт об использовании КМ, и


отправляет его в Сервер эмиссии.

4. Сервер эмиссии, получив запрос, содержащий отчёт об использовании КМ, производит


проверку запроса:

20
4.1. В случае если запрос содержит ошибки, Сервер эмиссии регистрирует ошибку
в журнале.

4.2. Сервер эмиссии формирует сообщение об ошибке и отправляет в Регистратор


эмиссии.

4.3. Осуществляется переход на шаг 7 основного сценария.

5. Сервер эмиссии при отсутствии ошибок присваивает отчёту идентификатор:

5.1. Сервер эмиссии конвертирует отчет в форму 10311/10319.

5.2. Сервер эмиссии отправляет форму 10311/10319 в обработку в ИС МДЛП


(действие выполняется асинхронно);

6. Сервер эмиссии формирует ответное сообщение и отправляет в Регистратор эмиссии.

7. Регистратор эмиссии получает результат обработки запроса.

8. Регистратор эмиссии проверяет наличие ошибок:

8.1. В случае если сообщение содержит ошибки, Регистратор эмиссии регистрирует


ошибку в журнале;

8.2. Регистратор эмиссии формирует сообщение об ошибке и отправляет в СУЗ.

8.3. Осуществляется переход на шаг 10 основного сценария.

9. Регистратор эмиссии при отсутствии ошибок формирует и отправляет ответное


сообщение в СУЗ.

10. СУЗ получает результат обработки запроса от Регистратора эмиссии.

11. СУЗ проверяет наличие ошибок:

11.1. СУЗ при наличии ошибок, регистрирует ошибку в журнале.

11.2. СУЗ формирует сообщение об ошибке и отправляет в АСУТП.

11.3. Осуществляется переход на шаг 13 основного сценария.

12. СУЗ при отсутствии ошибок формирует ответное сообщение и отправляет в АСУТП.

13. АСУТП получает результат обработки запроса от СУЗ.

14. АСУТП проверяет наличие ошибок:

14.1. АСУТП при наличии ошибок регистрирует ошибку в журнале.

14.2. Процесс завершается.

21
15. АСУТП при отсутствии ошибок сохраняет идентификатор отчёта, процесс завершается.

A diagram of the process of sending a report on the IC utilisation is shown in the figure below
(see Figure 9).

Figure 9. Send IC utilization report

Description

1. The APCS forms a request containing an IC utilisation report and sends it to the OMS.

2. The OMS conducts a request verification and sends a request containing an IC utilisation
report in the Emission Registrar.

3. The Emission Registrar forms a request containing an IC utilisation report and sends it
to the Emission Server.

4. The Emission Server receives a request containing an IC utilisation report, checks the request:

4.1. In case the request contains errors, the Emission Server logs an error in the log.

4.2. The Emission Server generates an error message and sends it to the Emission Registrar.

4.3. The transition to step 7 of the main scenario is carried out.

5. The Emission Server, if there are no errors, assigns an ID to the report:

22
5.1. The Emission Server convert the report to 10311/10319 form.

5.2. The Emission Server sends the 10311/10319 form to the processing in Information
System MDLP (the action is performed asynchronously).

6. The Emission Server forms a response message and sends it to the Emission Registrar.

7. The Emission Registrar receives the result of processing the request.

8. The Emission Registrar checks for errors:

8.1. In case the message contains errors, the Emission Registrar registers an error
in the journal.

8.2. The Emission Registrar generates an error message and sends it to the OMS.

8.3. The transition to step 10 of the main scenario is carried out.

9. The Emission Registrar generates and sends a response message to the OMS in the absence
of errors.

10. The OMS receives the result of the request processing from the Emission Registrar.

11. The OMS checks for errors:

11.1. In case of errors, logs an error in the log.

11.2. The OMS generates an error message and sends it to the APCS.

11.3. The transition to step 14 of the main scenario is carried out.

12. If there are no errors, the OMS forms a response message and sends it to the APCS.

13. The APCS receives the result of processing the request from the OMS.

14. The APCS checks for errors:

14.1. In case of errors, registers an error in the log.

14.2. The process is completed.

15. If there are no errors, the process retains the ID of the report.

23
4.5 Буфер хранения кодов маркировки внутри СУЗ (ICs storage buffer
in the OMS)

Для обеспечения необходимой производительности для высокоскоростных


производственных линий, СУЗ хранит внутри небольшой буфер с кодами маркировки,
на каждую номенклатуру (GTIN) бизнес-заказа. Размер блока кодов, который возможно
получить из СУЗ для данной номенклатуры за один раз, ограничен размером буфера. Он
настраивается под потребности производства. Структура хранения кодов маркировки в СУЗ
приведена на рисунке ниже (см. Рисунок 10). Такая структура хранения, дополнительно
обеспечивает отказоустойчивость блока эмиссии кодов маркировки на производстве.

To ensure the necessary performance for high-speed production lines, the OMS stores inside
a small buffer with marking codes for each item of a business order. The size of the block of codes
that can be obtained from the control system for a given item at a time is limited by the size
of the buffer. It is customized to the needs of production. This storage structure additionally ensures
the fault tolerance of the emission unit marking codes in production The storage structure
of marking codes in the OMS is shown in the figure below (see Figure 10).

Регистратор эмиссии 1
Заказ 1 (Order 1) (Emission Registrar 1)

GTIN 1 Заказ 2 (Order 2)

Буфер КМ Заказ (Order..) Хранилище КМ


(IC buffer) (ICs Storage)

GTIN 1
Бизнес-заказ Регистратор эмиссии 2
(Business order) (Emission Registrar 2)
Буфер КМ Заказ 1 (Order 1)
(IC buffer)

Заказ 2 (Order 2)
GTIN 1

Заказ (Order..) Хранилище КМ


Буфер КМ (ICs Storage)
(IC buffer)

Рисунок 10 – Распределение заказов на КМ между РЭ / Figure 10 - Distribution of orders for IC between


Emission Registrants)

24
5. Описание API (API description)

5.1 Описание API (API description)

Доступ к расширению API СУЗ для фармацевтической промышленности


обеспечивается при помощи URL.

Структура URL API СУЗ имеет следующие параметры:


http://<server-name>[:server-port]/api/v2/{extension}/

параметры:

− server-name – имя сервера или IP адрес;

− server-port – порт для соединения;

− extension – параметр URL определяющий доступ к расширению API СУЗ.

Параметр URL extension определяющий доступ к расширениям, должен иметь


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

Access to the OMS API extensions for the pharmaceutical industry is provided via a URL.

The OMS API URL structure has the following parameters:


http://<server-name>[:server-port]/api/v2/{extension}/

options:

− server-name – server name or IP address;

− server-port – connection port;

− extension – URL parameter defining access to the OMS API extensions.

The URL parameter «extension» that defines access to extensions has the value = pharma
for the pharmaceutical industry.

Внимание! Названия полей и их значения являются регистрозависимыми.

Attention! Field names and their values are case sensitive.

5.1.1 Проверить доступность СУЗ (Ping OMS)

Этот метод проверяет доступность СУЗ и использует следующие параметры: маркер


безопасности (token) и идентификатор СУЗ. Маркер безопасности (token) генерируется СУЗ

25
при регистрации клиента СУЗ. Маркер безопасности (token) передаётся на сервер в HTTP-
заголовке с именем «clientToken».

This method checks the availability of the OMS and requires the following parameters:
security token and unique OMS identifier. The security token is generated by OMS during
registration of OMS client. The security token is sent to the server in the HTTP-Header named
"clientToken".

5.1.1.1 Запрос (Request)

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-
port]/api/v2/{extension}/ping?omsId={omsId}
Method:GET
clientToken:{clientToken}

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

The query string parameter are listed in the table below (see Table 3).

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


Table 3 - Query string parameters

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

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

Sample of REST query


GET /api/v2/pharma/ping?omsId=CDF12109-10D3-11E6-8B6F-0050569977A1
HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Host: localhost:8080

5.1.1.2 Ответ на запрос (Response to request)

При успешном выполнении запроса, сервер возвращает HTTP код - 200 и уникальный
идентификатор СУЗ. Формат ответа на запрос доступности СУЗ приведён в таблице ниже
(см. Таблицу 4). Коды ошибок приведены в разделе 5.3.

26
If the request is successful, the server returns the HTTP code - 200 and unique OMS
identifier. The format of the response to the request for availability of OMS are listed in the table
below (see Table 4). Error codes are described in section 5.3.

Таблица 4 – Формат ответа на запрос доступности СУЗ


Table 4 - The format of the response to the request for availability of OMS

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Пример JSON ответа.

Sample of JSON response.


HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Content-Length: 19
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

{
"omsId":"CDF12109-10D3-11E6-8B6F-0050569977A1"
}

5.1.2 Создать бизнес-заказ на эмиссию кодов маркировки (Create order for emission IC)

Этот метод используется для создания и отправки заказа на эмиссию КМ. Маркер
безопасности (token) генерируется СУЗ при регистрации клиента СУЗ. Маркер безопасности
(token) передаётся на сервер в HTTP-заголовке с именем «clientToken».

This method is used to create and send an order for emission IC. The security token is
generated by OMS during registration of OMS client. The security token is sent to the server in the
HTTP-Header named «clientToken».

Примечание: товарная позиция (GTIN) в одном бизнес-заказе не должна превышать


150 000 кодов маркировки, количество товарных позиций в одном бизнес-заказе
для фармацевтической промышленности - 1 (1 бизнес-заказ - 1 GTIN). Количество активных
заказов не более 100.

27
Note: product item (GTIN) in one business order should not exceed 150 000 marking codes,
the number of product items in one business order for the pharmaceutical industry - 1 (1 business
order - 1 GTIN). The number of active orders is not more than 100.

5.1.2.1 Запрос (Request)

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-
port]/api/v2/{extension}/orders?omsId={omsId}
Method:POST
Content-Type:application/json
clientToken:{clientToken}

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

The query string parameters are listed in the table below (see Table 5).

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


Table 5 – Query string parameters

Обязательность.
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Описание формата JSON запроса создания и отправки заказа на эмиссию КМ (объект


«Order»), приведено в таблице ниже (см. Таблицу 6).

The description of the JSON format for creating and sending an order for emission CM are
listed in the table below (see Table 6).

Таблица 6 – Описание формата JSON запроса создания и отправки заказа на эмиссию КМ, объект
«Order»
Table 6 – Request of the JSON format for creating a business order for issuing a CM, object «Order»

Поле Описание Тип Обязательность


Field Description Type Is it mandatory to
complete the field?

JSON Array of
Список товаров OrderProduct
products Да (Yes)
List of products Таблица 7
Table 7

Описание формата объекта «OrderProduct» приведено в таблице ниже (см. Таблицу 7).

The format of the object «OrderProduct» are listed in the table below (see Table 7).
28
Таблица 7 – Формат объекта «OrderProduct»
Table 7 – Format of object «OrderProduct»

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?

GTIN продукта String (14)


gtin Да (Yes)
Product GTIN [0-9]{14}

Количество КМ Integer
quantity Да (Yes)
Quantity of ICs / Identifiers ($int32)

Способ генерации серийных номеров String


serialNumberType Method of generation of individual serial Voc. №1 Да (Yes)
number (See section 5.2.1.)

Массив серийных номеров. Это поле


Нет(No)
указывается в случае, если значение
JSON Array of Условно
«serialNumberType = SELF_MADE»
serialNumbers String (13) обязательное
Unique serial numbers. This field is to be
filled if only «serialNumberType» = [a-zA-Z0-9]{13} (conditionally
mandatory)
SELF_MADE (See section 5.2.1.)

Идентификатор шаблона КМ. Раздел Integer


5.2.2. Используется шаблон 2 или
($int32)
templateId шаблон 5 согласно справочнику Да (Yes)
Voc. №2
IC template ID. Template 2 or Template 5
must be used according to the Voc (See section 5.2.2.)

Примечание: первично установленная схема генерации КМ для конкретного типа


товара (GTIN), определяемая атрибутом «serialNumberType» не может быть изменена
в дальнейшем.

Note: the initially established IC generation scheme for a specific type of product (GTIN),
defined by the attribute «serialNumberType» cannot be changed in the future.

Описание расширения объекта «Order» для фармацевтической промышленности


приведено в таблице ниже (см. Таблицу 8).
The extension of the object «Order» for the pharmacy industry is listed in the table below
(see Table 8).

Таблица 8 - Описание расширения объекта «Order» для фармацевтической промышленности


Table 8 – The extension of the object «Order» for the pharmacy industry

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?
subjectId Субъект обращения. Номер, String Да (Yes)
присвоенный при регистрации в ИС (36)
МДЛП.
GUID
Subject ID. Number assigned during
registration with IS MDLP

29
Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?
freeСode Признак оплаты эмиссии КМ. boolean Нет (No)*
true - КМ не подлежит оплате; (Условно
false - КМ подлежит оплате. обязательное,
Sign of payment for IC issue. Conditionally
true - IC is not payable;
Mandatory)
false - IC payable

paymentType Тип оплаты. Int32 Нет (No)*


Допустимые значения:
1- Оплата по эмиссии;
2- Оплата по нанесению
Payment type.
Valid Values:
1- Payment by issue;
2- Application Payment

Значение subjectId (value of subjectId):

36-значный номер (GUID), присвоенный субъекту обращения лекарственных средств


по итогам регистрации при его регистрации в ИС МДЛП.

36-characters pharmaceutical entity’s identifier in the information system MDLP).

Примечание* : поле freeСode является не обязательным, заполняется автоматически


значением по умолчанию freeСode=false, поле paymentType является не обязательным,
заполняется автоматически значением по умолчанию paymentType=2.
Note*: freeСode field is optional and filled automatically by OMS (the default value is
freeСode = false ), paymentType field is optional and filled automatically by OMS (the default
value is paymentType = 2).
Внимание! Тип оплаты «Оплата по эмиссии» временно отключен, в поле
paymentType необходимо передавать значение «2» (оплата по нанесению).

При передаче paymentType=1 возвращается ошибка: «Обработка заказа с типом


оплаты «Оплата по эмиссии» временно недоступна».

Attention! The payment type «1- Payment by issue» is temporarily disabled. PaymentType
field must contain value=2.
If you send paymentType = 1, then an error will be returned: «Order processing with the
payment type “Payment by issue” is temporarily unavailable».

Пример REST запроса (для фармацевтического производства).

Sample REST query (for the pharmacy industry).

* на период реализации интеграционных работ со стороны субъектов обращения лекарственных средств


* for the period of implementation of integration work by the pharmaceutical entity

30
POST /api/v2/pharma/orders?omsId=CDF12109-10D3-11E6-8B6F-
0050569977A1 HTTP/1.1
Accept: application/json
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Content-Length: 559
Content-Type: application/json;charset=UTF-8
Host: localhost:8080

{
"products" : [ {
"gtin" : "01334567894339",
"quantity" : 20,
"serialNumberType" : "SELF_MADE",
"serialNumbers" : [ "77X4DdOGGDc9d", "6KfL3i7igypkd",
"oBtEYaq1HCxHN", "kRGmTQoeOckPx", "KHnFN1fj7NmL6", "LSsbD7BrWRyFX",
"rEw3MOgC86H4w", "7WQ4FZapQpacq", "Qaty1C5Imop1O", "mSWjzXd5axLRj",
"2sneq3ZzQPxRD", "m6edPWjxsTc6R", "pIfdgy1XyYIkx", "CTQzSe9ZTormg",
"dock4TYN5HSkW", "ZA6AITKGQNfO1", "AJfr6XoYxRIHE", "GpxniqfHc6iBA",
"57gx4I7fj8J58", "iQ4PtkYIYfxKL" ],
"templateId":5
} ],
"subjectId ":"65468245-fb47-4c8a-af3d-d3486ead8c4a"
}

5.1.2.2 Ответ на запрос (Response to request)

Метод возвращает уникальный идентификатор заказа и время планируемого


выполнения заказа в миллисекундах (полученное время необходимо поделить на 1 000,
чтобы получить секунды и на 60, чтобы получить минуты). Значение «orderId» используется
для получения КМ из заказа, когда заказ выполнен (см. раздел 5.1.4.). Коды ошибок
приведены в разделе 5.3.

The method returns a unique OMS order ID and the expected order completion time
in milliseconds (The received time must be divided by 1 000 to get seconds and 60 to get minutes).
The “orderId” value is used to get the CM from the order when the order is completed (see section
5.1.4.). Error codes are described in section 5.3.

Таблица 9 – Формат ответа на запрос


Table 9 – Format of the response to the request

Обязательность
Поле Описание Тип Is it mandatory
Field Description Type to complete the
field?

Уникальный идентификатор СУЗ String Да (Yes)


omsId
Unique OMS identifier (UUID)

31
Обязательность
Поле Описание Тип Is it mandatory
Field Description Type to complete the
field?

Уникальный идентификатор бизнес- Да (Yes)


String
orderId заказа на эмиссию КМ
(UUID)
Unique OMS order ID

Время планируемого выполнения Да (Yes)


Integer
expectedCompletionTime заказа в миллисекундах
($int64)
Expected order completion time in msec

Пример JSON ответа

Sample of JSON response


HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Content-Length: 111
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

{
"omsId" : "CDF12109-10D3-11E6-8B6F-0050569977A1",
"orderId" : "b024ae09-ef7c-449e-b461-05d8eb116c79",
"expectedCompleteTimestamp" : 5100
}

5.1.3 Получить статус массива КМ из бизнес-заказа (Get IC buffer status)

Этот метод используется для получения текущего статуса массива КМ из заказа,


в качестве параметров требует: маркер безопасности (token), идентификатор СУЗ,
идентификатор заказа «orderId» и GTIN. Маркер безопасности (token) генерируется СУЗ при
регистрации клиента СУЗ. Маркер безопасности (token) передаётся на сервер в HTTP-
заголовке с именем «clientToken».

The method of getting current IC buffer status for a specific order requires the following
parameters: security token, OMS identifier, order ID, and product GTIN. The security token is
generated by OMS during registration of OMS client. The security token is sent to the server
in the HTTP-Header named "clientToken".

32
5.1.3.1 Запрос (Request)

Структура запроса получения статуса массива КМ из заказа.

Structure of query for getting IC array status for the order.

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-
port]/api/v2/{extension}/buffer/status?
omsId={omsId}&orderId={orderId}&gtin={gtin}
Method:GET
clientToken:{clientToken}

Параметры строки запроса приведены в таблице ниже (см. Таблицу 10).

The query string parameters are listed in the table below (see Table 10).

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


Table 10 - Query string parameters

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Идентификатор бизнес-заказа на эмиссию КМ String


orderId Да (Yes)
Unique OMS Order ID (UUID)

GTIN товара, по которому нужно получить статус заказа String


gtin Product GTIN (14) Да (Yes)
[0-9]{14}

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

Sample of REST query


GET /api/v2/pharma/buffer/status?orderId=b024ae09-ef7c-449e-b461-
05d8eb116c79&gtin=01334567894339&omsId=CDF12109-10D3-11E6-8B6F-
0050569977A1 HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Host: localhost:8080

5.1.3.2 Ответ на запрос (Response to request)

Формат JSON ответа на запрос получения статуса массива КМ приведен в таблице


ниже (см. Таблицу 11). Коды ошибок приведены в разделе 5.3.

33
The JSON format of the response to the request for obtaining the status of the KM array are
listed in the table below (see Table 11). Error codes are described in section 5.3.

Таблица 11 – Формат ответа на запрос, объект «BufferInfo»


Table 11 - Format of the response to the request, object «BufferInfo»

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?
Общее количество доступных КМ для
товара в буфере и пулах регистратора Integer
availableCodes Да (Yes)
Number of available codes in buffer and ($int32)
pools
String
Статус буфера
bufferStatus Voc. №4 Да (Yes)
Buffer status
(See section 5.2.4.)
String
GTIN – по которому был сделал запрос
gtin (14) Да (Yes)
Product GTIN
[0-9]{14}
Количество неиспользованных КМ
Integer
leftInBuffer (локальный буфер) Да (Yes)
($int32)
Number of unused ICs in the array
Уникальный идентификатор СУЗ String
omsId Да (Yes)
Unique OMS identifier (UUID)
Уникальный идентификатор заказа на
эмиссию КМ. Заказ, по которому был String
orderId Да (Yes)
сделан запрос (UUID)
A unique order ID in OMS
JSON Array of
Массив пулов, созданных для буфера PoolInfo Object
poolInfos Да (Yes)
Array of pools created for the IC buffer Таблица 12
Table 12

Пулы КМ в регистраторах исчерпаны


poolsExhausted Boolean Да (Yes)
IC buffer of ERs was exhausted
Причина отклонения буфера СУЗ-ом
rejectionReason String Нет (No)
Buffer rejection reason

Заказанное количество КМ в заказе Integer


totalCodes Да (Yes)
Order quantity of IC in the order ($int32)
Суммарное кол-во КМ полученных из
Integer
totalPassed буфера Да (Yes)
($int32)
Buffer total passed codes
Количество недоступных кодов Integer
unavailableCodes Да (Yes)
Number of unavailable codes ($int32)

34
Таблица 12 – Формат объекта «PoolInfo»
Table 12 - Format of object «PoolInfo»

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?

Готовность РЭ
isRegistrarReady Logical flag that shows if the Emission Boolean Да (Yes)
Registrar is currently ready for orders

Метка времени, последней


lastRegistrarErr наблюдавшейся ошибки РЭ Long
Да (Yes)
orTimestamp Timestamp when the last Emission Registrar ($int64)
error occurred

Оставшееся количество КМ в пуле Integer


leftInRgistrar Да (Yes)
Number of unused ICs in the pool ($int32)

Заказанное количество КМ в пуле Integer


quantity Да (Yes)
Number of ICs ordered in the array ($int32)

Количество ошибок РЭ
registrarErrorCo Integer
Number of Emission Registrar errors Да (Yes)
unt ($int32)
occurred

Идентификатор РЭ (номер)
registrarId String Да (Yes)
Emission Registrar Identifier

Причина отказа
rejectionReason The IC array rejection reason returned by String Нет (No)
the Emission Registrar

String
Статус пула КМ
status Voc. №3 Да (Yes)
IC array status
(See section 5.2.3.)

Пример JSON ответа

Sample of JSON response


HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 659
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

{
"poolInfos" : [ {
"status" : "READY",
"quantity" : 9,

35
"leftInRegistrar" : 0,
"registrarId" : "Virtual Registrar",
"isRegistrarReady" : true,
"registrarErrorCount" : 0,
"lastRegistrarErrorTimestamp" : 0
}, {
"status" : "READY",
"quantity" : 11,
"leftInRegistrar" : 0,
"registrarId" : "Virtual Registrar",
"isRegistrarReady" : true,
"registrarErrorCount" : 0,
"lastRegistrarErrorTimestamp" : 0
} ],
"leftInBuffer" : 0,
"totalCodes" : 20,
"unavailableCodes" : 0,
"orderId" : "b024ae09-ef7c-449e-b461-05d8eb116c79",
"gtin" : "01334567894339",
"bufferStatus" : "ACTIVE",
"omsId" : "CDF12109-10D3-11E6-8B6F-0050569977A1"
}

5.1.4 Получить КМ из бизнес-заказа (Get ICs from the order)

Этот метод используется для получения массива КМ определённого заказа используя


следующие параметры: маркер безопасности (token), идентификатор СУЗ, идентификатор
заказа, GTIN, количество запрашиваемых кодов. Маркер безопасности (token) генерируется
СУЗ при регистрации клиента СУЗ. Маркер безопасности (token)передаётся на сервер
в HTTP-заголовке с именем «clientToken». Если бизнес-заказ находится в процессе
выполнения и массив кодов еще не сформирован, данный метод возвращает ошибку.

The method of getting ICs from the specified order requires the following parameters:
security token, OMS identifier, order ID, product GTIN and quantity of ICs to be provided.
The security token is generated by OMS during registration of OMS client. The security token is
sent to the server in the HTTP-Header named «clientToken». If the order is still in progress and
the IC array has not been generated yet, the method return an error.

5.1.4.1 Запрос (Request)

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-port]/api/v2/{extension}/codes?
omsId={omsId}&orderId={orderId}&gtin={gtin}&quantity={quantity}&
lastBlockId={lastBlockId}
Method:GET

36
clientToken:{clientToken}

Параметры строки запроса приведены в таблице ниже (см. Таблицу 13).

The query string parameters are listed in the table below (see Table 13).

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


Table 13 - Query string parameters

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Идентификатор бизнес-заказа на эмиссию КМ String


orderId Да (Yes)
Unique OMS Order identifier (UUID)

String
GTIN товара, по которому запрашиваются коды
gtin (14) Да (Yes)
Product GTIN
[0-9]{14}

Количество запрашиваемых кодов Integer


quantity Да (Yes)
Quantity of requested codes ($int32)

Идентификатор блока кодов, выданных в


предыдущем запросе. Может быть равен 0 при
первом запросе КМ из пула. Далее должен
передаваться идентификатор предыдущего
lastBlockId пакета. Значение по умолчанию: 0 String Нет (No)
ID of the block of codes issued in the previous
request. May be 0 on the first IC request from the
pool. Further, the identifier of the previous packet
should be transmitted. Default value: 0

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


(гарантированное получение эмитированных кодов маркировки) с передачей в запросах
подтверждения получения кодов маркировки и при закрытии заказа. Правила получения
кодов маркировки представлено ниже:
− При первом запросе кодов маркировки, значение атрибута «lastBlockId»
указывается равным «0» (ноль), в ответном сообщении будет содержаться
идентификатор блока кодов (значение атрибута «blockId»), который должен
быть указан в следующем запросе кодов маркировки. Далее каждый запрос
должен содержать значение атрибута «lastBlockId», равный идентификатору
блока кодов, полученных в предыдущем запросе (передача идентификатор блока
кодов является подтверждением получения эмитированных кодов маркировки);
− В случае если в запросе в качестве значения атрибута «lastBlockId» будет указан
идентификатор блока кодов, отличный от полученного в предыдущем запросе,
то коды маркировки, отправленные в предыдущем запросе, будут считаться

37
утерянными, в этом случае коды маркировки будут отбракованы (СУЗ
сформирует отчёт об отбраковке и отправит его в систему).
− Финальным шагом является закрытие заказа, закрытие заказа должно
осуществляться клиентом посредством вызова метода «Закрыть подзаказ
по заданному GTIN» (см. раздел 5.1.7), в запросе которого должен передаваться
последний полученный идентификатор блока кодов.

Note: Receipt of emitted ICs is performed by a client (guaranteed receipt of emitted ICs) with
a transfer in confirmation requests for receipt of ICs and upon closing of the order. The rules
for ICs obtaining are presented below:
− The first request for ICs, the value of the «lastBlockId» attribute is set to «0» (zero),
the response message will contain the identifier of the code block (the value
of the attribute «blockId»), which should be specified in the next request for ICs. Then
each request should contain the value of the «lastBlockId» attribute equal
to the identifier of the code block received in the previous request (the transfer
of the code block identifier is a confirmation of receipt of the emitted ICs).
− If in the request the code block identifier other than the one received in the previous
request is specified as the value of the «lastBlockId» attribute, the ICs sent
in the previous request will be considered lost, in this case the ICs will be rejected
(OMS will generate a report rejection and send it to the system).
− The final step is to close the order, closing the order should be carried out
by the client by calling the method «Close IC array for the specified product GTIN»
(see section 5.1.7) in the request of which the last received code block identifier
should be transmitted.

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

Sample of REST query


GET /api/v2/pharma/codes?orderId=b024ae09-ef7c-449e-b461-
05d8eb116c79&gtin=01334567894339&quantity=15&lastBlockId=0&omsId=CDF
12109-10D3-11E6-8B6F-0050569977A1 HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Host: localhost:8080

5.1.4.2 Ответ на запрос (Response to request)

При успешном выполнении запроса, сервер возвращает HTTP код -200 и массив КМ
КМ. Формат ответа на запрос получения КМ для заданного товара приведён в таблице ниже.
Коды ошибок приведены в разделе 5.3.

38
If the request is successful, the server returns the HTTP code -200 and IC array. The format
of the response to the request for receipt of the IC for a given product are listed in the table below.
Error codes are described in section 5.3.

Таблица 14 – Формат ответа на запрос получения КМ для заданного товара


Table 14 - The format of the response to the request for receipt of the CM for a product

Обязательность.
Поле Описание Тип Is it mandatory to
Field Description Type complete the
field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Массив КМ JSON Array of


codes Да (Yes)
IC array Strings

Идентификатор пакета КМ String


blockId Да (Yes)
ID of the block of codes (UUID)

Пример JSON ответа

Sample of JSON response


HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 820
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

{
"omsId" : "CDF12109-10D3-11E6-8B6F-0050569977A1",
"codes" : [
"010460165303004621u003drxdv3Mu0\u001d91VXQI\u001d92X8s451dPdmHvUKs6
cTvZgqTFvvagZl/NFVUNwo+ufaM= "],
"blockId" : "CAF16549-15B1-11E6-8A4F-0056563378A1"
}

5.1.5 Отправить отчёт об использовании КМ (Send IC utilisation report to OMS)

Этот метод используется для отправки отчёта об использовании КМ в СУЗ. Маркер


безопасности (token) генерируется СУЗ при регистрации клиента СУЗ. Маркер безопасности
(token) передаётся на сервер в HTTP-заголовке с именем «clientToken».

39
This method is used for sending the IC utilisation report to OMS. The security token is
generated by OMS during registration of OMS client. The security token is sent to the server
in HTTP-Header named "clientToken".

5.1.5.1 Запрос (Request)

Структура запроса JSON для отправки отчёта об использовании КМ в СУЗ.

Structure of JSON query for sending the IC utilization report to OMS.

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-
port]/api/v2/pharma/utilisation?omsId={omsId}
Method:POST
Content-Type:application/json
clientToken:{clientToken}

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

The query string parameters are listed in the table below (see Table 15).

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


Table 8 – Query string parameters

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Описание структуры объекта «UtilisationReport» для отправки отчёта


об использовании КМ в СУЗ приведено в таблице ниже (см. Таблицу 16).

The description of the structure of the object «UtilisationReport» for sending a report
on the IC utilization report to OMS are listed in the table below (see Table 16).

Примечание. Передаваемые коды маркировки в качестве параметров «sntins»


должны включать полный код маркировки, включающий код проверки, так как данный отчёт
передаётся в регистратор эмиссии, где осуществляется проверка подлинности кода
маркировки. Количество КМ в отчете об использовании не должно превышать 30 000 кодов.

Note. Transmitted IСs as “sntins” parameters should include the full marking code,
including the verification code (crypto code), since this report is transmitted to the issue registrar,

40
where the authentication of the IС is performed. The number of IC in the utilization report should
not exceed 30 000 codes).

Таблица 16 – Структура объекта «UtilisationReport»


Table 16 – Structure of the object «UtilisationReport»

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?

Массив строк (GTIN + Серийный номер +


код проверки - полный код маркировки,
включая код проверки)
sntins JSON Array of String Да (Yes)
Array of GTIN+serial+ crypto code (IС should
include the full marking code, including the
verification code (crypto code))

Тип использования. Раздел 5.2.6


Usage Type String
usageType Используется значение VERIFIED Voc. №6 Да (Yes)
согласно справочнику
(See section 5.2.6.)
usageType=VERIFIED must be used
according to the Voc

Описание расширения объекта «UtilisationReport» для фармацевтической


промышленности приведено в таблице ниже (см. Таблицу 17).

The extension of the object «UtilisationReport» for the pharmacy industry are listed
in the table below (see Table 17).

Таблица 17 – Описание расширения объекта «UtilisationReport» для фармацевтической промышленности


Table 17 – The extension of the object «UtilisationReport» for Pharmacy Industry

Обязательность
Поле Описание Тип†
Is it mandatory to
Field Description Type
complete the field?

expirationDate Дата истечения срока годности String Да (Yes)


Expiration Date (dd.mm.yyyy)

orderType Тип производственного заказа Integer Нет (No)


Order Type (1 or 2)

ownerId Идентификатор владельца String Нет (No)


Owner Identifier (36)
GUID

seriesNumber Номер производственной серии String Да (Yes)


Series Number (1-20)


Формат и допустимые символы должны соответствовать форматам соответствующих полей в ИС МДЛП.
The format and valid characters must comply with the formats of the corresponding fields in Information System MDLP

41
Обязательность
Поле Описание Тип†
Is it mandatory to
Field Description Type
complete the field?

subjectId* Субъект обращения. Идентификатор String Да (Yes)


места деятельности или (14 or 36)
регистрационный номер субъекта
[0-9]{14} or
обращения.
GUID
Subject ID. Identifier of the location
according the license or registration
number

packingId Идентификатор производителя, String Нет (No)


осуществившего упаковку/фасовку во (36)
вторичную (а при ее отсутствии –
GUID
первичную упаковку)
The ID of the packaging manufacturer

controlId Идентификатор производителя, String Нет (No)


осуществляющего выпускающий (36)
контроль качества
GUID
The ID of the manufacturer who produced
the quality control

Примечание (Note)*: Значение subjectId (value of subjectId):

– при производстве лекарственного препарата на территории Российской Федерации:


14-значный идентификатор места осуществления деятельности субъекта обращения согласно
лицензии, присвоенный по итогам регистрации субъектом обращения места осуществления
деятельности в ИС МДЛП (local drug production in Russia: 14-digit identifier of the location
according the license in the information system MDLP);

– при производстве лекарственного препарата вне территории Российской Федерации:


36-значный номер, присвоенный держателю регистрационного удостоверения (или его
представительству) при его регистрации в ИС МДЛП (drug production outside the Russia:
36-characters MAH (or representative office) registration number in the information system
MDLP).

Внимание!

А) При производстве лекарственных препаратов на территории Российской


Федерации:

Поле orderType является обязательным. Указанное поле должно содержать


числовое значение типа производственного заказа – (1) собственное или (2) контрактное
производство.

В случае указания orderType=1 поле ownerId не заполняется.


42
В случае указания orderType=2 в обязательном порядке должно быть указано
значение поля ownerId - 36-значный номер, присвоенный субъекту обращения,
являющемуся заказчиком контрактного производства, при его регистрации в ИС МДЛП.

Поля packingId и controlId не заполняются.

Б) При производстве лекарственных препаратов вне территории Российской


Федерации:

Поля packingId и controlId являются обязательными. Должны содержать


36-значные идентификаторы, присваиваемые иностранным контрагентам при их регистрации
в ИС МДЛП держателем регистрационного удостоверения лекарственного препарата (или
его представительством).

Поля orderType и ownerId не заполняются.

Attention!

А) Local drug production in Russia:

Field orderType must be completed. The specified field must contain the numeric value
of the production order type – (1) own, (2) contract.

If orderType=1 field ownerId are not required.

If orderType=2 field ownerId must be completed – 36-characters identifier


of the production customer in the information system MDLP.

Fields packingId and controlId are not required.

B) Drug production outside the Russia:

Fields packingId and controlId must be completed. The specified field must contain
the 36-characters identifiers of secondary packaging manufacturer and manufacturer, who
produced the quality control, from the register of foreign counter companies in the information
system MDLP.

Fields orderType and ownerId are not required.

Пример REST запроса (для фармацевтической промышленности, для собственного


производства на территории Российской Федерации).

43
Sample of REST query (for Pharma industry, Local own drug production in Russia)
POST /api/v2/pharma/utilisation?omsId=CDF12109-10D3-11E6-8B6F-
0050569977A1 HTTP/1.1
Accept: application/json
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Content-Length: 271
Content-Type: application/json;charset=UTF-8
Host: localhost:8080

{
"sntins":[
"010460165303004621u003drxdv3Mu0\u001d91VXQI\u001d92X8s451dPdmHvUKs6
cTvZgqTFvvagZl/NFVUNwo+ufaM=",
"010460165303004621u003drxdv3Mu0\u001d91VXQI\u001d92A3igGog+daH9OlF2
Atkb/UZvzZctL55wlOCsDXW1oyg="],
"usageType":"VERIFIED",
"expirationDate":"12.06.2020",
"orderType":"1",
"seriesNumber":"123",
"subjectId":"00000000000397"
}

Пример REST запроса (для фармацевтической промышленности, для контрактного


производства на территории Российской Федерации).

Sample of REST query (for Pharma industry, Local contract drug production in Russia)
POST /api/v2/pharma/utilisation?omsId=CDF12109-10D3-11E6-8B6F-
0050569977A1 HTTP/1.1
Accept: application/json
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Content-Length: 271
Content-Type: application/json;charset=UTF-8
Host: localhost:8080

{
"sntins":[
"010460165303004621u003drxdv3Mu0\u001d91VXQI\u001d92X8s451dPdmHvUKs6
cTvZgqTFvvagZl/NFVUNwo+ufaM=",
"010460165303004621u003drxdv3Mu0\u001d91VXQI\u001d92A3igGog+daH9OlF2
Atkb/UZvzZctL55wlOCsDXW1oyg="],
"usageType":"VERIFIED",
"expirationDate":"12.06.2020",
"orderType":"2",
"ownerId":"0c290e4a-aabb-40ae-8ef2-ce462561ce7f",
"seriesNumber":"123",
"subjectId":"00000000000397"
}

44
Пример REST запроса (для фармацевтической промышленности, для производства
вне территории Российской Федерации).

Sample of REST query (for Pharma industry, Drug production outside the Russia)
POST /api/v2/pharma/utilisation?omsId=CDF12109-10D3-11E6-8B6F-
0050569977A1 HTTP/1.1
Accept: application/json
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Content-Length: 271
Content-Type: application/json;charset=UTF-8
Host: localhost:8080

{
"sntins":[
"010460165303004621u003drxdv3Mu0\u001d91VXQI\u001d92X8s451dPdmHvUKs6
cTvZgqTFvvagZl/NFVUNwo+ufaM=",
"010460165303004621u003drxdv3Mu0\u001d91VXQI\u001d92A3igGog+daH9OlF2
Atkb/UZvzZctL55wlOCsDXW1oyg="],
"usageType":"VERIFIED",
"expirationDate":"12.06.2020",
"seriesNumber":"123",
"subjectId":"0c29564a-aacc-brae-8652-ce462561c898",
"packingId":"0c290e4a-aabb-40ae-8ef2-ce462561ce7f",
"controlId":"0c456e4a-aacb-42ae-8ef2-ce462662ce8a"
}

5.1.5.2 Ответ на запрос (Response to request)

При успешном выполнении запроса, сервер возвращает HTTP код - 200 и уникальный
идентификатор отчёта об использовании КМ, присвоенный СУЗ. Полученный
идентификатор отчёта об использовании КМ используется для получения статуса обработки
отчёта (см. раздел 5.1.8.). Структура ответа на запрос отправки отчёта об использовании
приведён в таблице ниже (см. Таблицу 18). Коды ошибок приведены в разделе 5.3.

If the request is successful, the server returns the HTTP code -200 and unique identifier
of the report IC utilisation, assigned to the OMS. The received identifier of the report IC utilisation
is used to obtain the status of report processing (see section 5.1.8.). The structure of the response
to the request to send information about the report IC utilisation are listed in the table below
(see Table 18). Error codes are described in section 5.3.

45
Таблица 18 – Формат ответа на запрос отправки отчёта о нанесении КМ
Table 18 – The format of the response to the request to send report IC utilisation

Обязательность
Поле Описание Тип Is it mandatory
Field Description Type to complete the
field?

Уникальный идентификатор СУЗ String Да (Yes)


omsId
Unique OMS identifier (UUID)

reportId Уникальный идентификатор отчёта о нанесении КМ String Да (Yes)


(СУЗ) (UUID)
Unique OMS report ID

Пример JSON ответа

Sample of JSON response


HTTP/1.1 200 OK
Content-Length: 74
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

{
"omsId" : "CDF12109-10D3-11E6-8B6F-0050569977A1",
"reportId" : "3179f5d2-2bf5-47d1-8df0-9452b257d851"
}

5.1.6 Получить статус бизнес-заказов (Get status orders)

Этот метод предназначен для получения статуса бизнес заказов, используя следующие
параметры: маркер безопасности (token), идентификатор СУЗ. Маркер безопасности (token)
генерируется СУЗ при регистрации клиента СУЗ. Маркер безопасности (token) передаётся
на сервер в HTTP-заголовке с именем «clientToken».

The method receives the status of business orders using the following parameters: security
token, OMS identifier. The security token is generated by OMS during registration of OMS client.
The security token is sent to the server in the HTTP-Header named «clientToken».

46
5.1.6.1 Запрос (Request)

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-
port]/api/v2/{extension}/orders?omsId={omsId}
Method:GET
clientToken:{clientToken}

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

The query string parameter are listed in the table below (see Table 19).

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


Table 19 - Query string parameters

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

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

Sample of REST query


GET /api/v2/pharma/orders?omsId=CDF12109-10D3-11E6-8B6F-0050569977A1
HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Host: localhost:8080

5.1.6.2 Ответ на запрос (Response to request)

При успешном выполнении запроса, сервер возвращает HTTP код -200 и данные статус
бизнес заказов и уникальный идентификатор СУЗ. Формат ответа на запрос получения
состава агрегата приведён в таблице ниже (см. Таблица 20). Коды ошибок приведены
в разделе 5.3.

If the request is successful, the server returns the HTTP code -200 and business order status
data and unique OMS identifier. The structure of the response to the request for obtaining
the composition of the aggregation unit are listed in the table below (see Table 20). Error codes are
described in section 5.3.

47
Таблица 20 – Формат ответа на запрос получения статуса бизнес-заказа
Table 20 - The format of the response to a request for receiving the status orders

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

JSON Array of
Массив бизнес-заказов с их статусами
OrderSummary
orderInfos An array of business orders with their Да (Yes)
Таблица 21
statuses
Table 21

Таблица 21 – Формат объекта «OrderSummary»


Table 21 - Format of object «OrderSummary»

Обязательность
Поле Описание Тип
Is it mandatory to
Field Description Type
complete the field?

Идентификатор бизнес-заказа на
String
orderId эмиссию КМ Да (Yes)
(UUID)
Unique OMS Order ID

String
Статус бизнес-заказа
orderStatus Voc. №7 Да (Yes)
Business order status
(See section 5.2.7.)

JSON Array of
Массив информации о статусе буферов BufferInfo
buffers Да (Yes)
Array of buffer status information Таблица 11
Table 11

Время создания заказа Integer


createdTimestamp Да (Yes)
Order creation time. ($int64)

Причина отклонения заказа


declineReason String Нет (No)
Order decline reason

Пример JSON ответа

Sample JSON response


HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Length: 953
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

48
{
"omsId" : "CDF12109-10D3-11E6-8B6F-0050569977A1",
"orderInfos" : [ {
"orderId" : "b024ae09-ef7c-449e-b461-05d8eb116c79",
"orderStatus" : "READY",
"createdTimestamp" : 1550650989568,
"buffers" : [ {
"poolInfos" : [ {
"status" : "READY",
"quantity" : 9,
"leftInRegistrar" : 0,
"registrarId" : "Virtual Registrar",
"isRegistrarReady" : true,
"registrarErrorCount" : 0,
"lastRegistrarErrorTimestamp" : 0
}, {
"status" : "READY",
"quantity" : 11,
"leftInRegistrar" : 0,
"registrarId" : "Virtual Registrar",
"isRegistrarReady" : true,
"registrarErrorCount" : 0,
"lastRegistrarErrorTimestamp" : 0
} ],
"leftInBuffer" : 20,
"totalCodes" : 20,
"unavailableCodes" : 0,
"orderId" : "b024ae09-ef7c-449e-b461-05d8eb116c79",
"gtin" : "01334567894339",
"bufferStatus" : "ACTIVE",
"omsId" : "CDF12109-10D3-11E6-8B6F-0050569977A1"
} ]
} ]
}

5.1.7 Закрыть подзаказ по заданному GTIN (Close IC array for the specified product
GTIN)

Этот метод предназначен для закрытия массива КМ используя следующие параметры:


маркер безопасности (token), идентификатор СУЗ, идентификатор заказа и GTIN. Маркер
безопасности (token) генерируется СУЗ при регистрации клиента СУЗ. Маркер безопасности
(token) передаётся на сервер в HTTP-заголовке с именем «clientToken».

The method closes IC array for the specified order and product GTIN and requires
the following parameters: token, order ID, and product GTIN. The token is generated by OMS

49
during registration of OMS client. The token is sent to the server in the HTTP-Header named
"clientToken".

5.1.7.1 Запрос (Request)

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-
port]/api/v2/{extension}/buffer/close
?orderId={orderId}&gtin={gtin}&omsId={omsId}&
lastBlockId={lastBlockId}
Method:POST
clientToken:{clientToken}

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

The query string parameters are listed in the table below (see Table 22).

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


Table 22 – Query string parameters

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Идентификатор бизнес-заказа на эмиссию


String
orderId КМ СУЗ Да (Yes)
(UUID)
Unique OMS Order ID

GTIN товара, по которому требуется String


gtin прекратить выдачу КМ (14) Да (Yes)
Product GTIN
[0-9]{14}

lastBlockId Идентификатор последнего полученного String Нет (No)


блока кодов (значение по умолчанию :0)
Last received Code block identifier (Default
value : 0)

Примечание: правила закрытия заказа описаны ниже:

− Клиент обязан закрыть заказ после получения эмитированных кодов


маркировки. В запросе в качестве значения параметра «lastBlockId» должно
указываться значение последнего идентификатора блока кодов полученного
в ответном сообщении при вызове метода «Получить КМ из бизнес-заказа»
(см. раздел 5.1.4). В случае если участником оборота не запрашивались коды
маркировки, то значение параметра «lastBlockId» должно быть установлено
равным «0» (ноль), что является значением по умолчанию.

50
− В случае если клиент не закроет заказ, то СУЗ выполнит закрытие заказа
по истечению времени указанного в параметрах конфигурации СУЗ и коды
маркировки, полученные в последнем запросе, будут считаться утерянными,
данные коды маркировки будут отбракованы (СУЗ сформирует отчёт
об отбраковке и отправит его в систему) по причине того, что не будет
отправлено подтверждение о получении последнего блока кодов маркировки
(подтверждение о получении кодов маркировки клиентом подтверждается
указанием последнего идентификатора блок кодов маркировки).

Note: the rules for closing an order are described below:

− The client is obliged to close the order after receiving the emitted ICs. In the request,
the value of the «lastBlockId» parameter should include the value of the last
identifier of the block of codes received in the response message when calling
the «Get CM from business order» method (see section 5.1.4). In case if the client
did not request ICs, the value of the «lastBlockId» parameter should be set to «0»
(zero), which is the default value.
− In case the client does not close the order, the OMS completes the order after
the time specified in the OMS configuration parameters and the ICs received
in the last request will be considered lost, these ICs will be rejected (OMS will
generate a rejection report and send it to the system ) due to the fact that
the confirmation of receipt of the last block of ICs will not be sent (confirmation
of receipt of ICs by the client is confirmed by indicating the last identifier and
a block of ICs).

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

Sample of REST query


POST /api/v2/pharma/buffer/close HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Host: localhost:8080
orderId=b024ae09-ef7c-449e-b461-
05d8eb116c79&gtin=01334567894339&lastBlockId=0&omsId=CDF12109-10D3-
11E6-8B6F-0050569977A1

5.1.7.2 Ответ на запрос (Response to request)

При успешном выполнении запроса, сервер возвращает HTTP код -200 и уникальный
идентификатор СУЗ. Структура ответа на запрос закрытие подзаказа по заданному GTIN
приведён в таблице ниже (см. Таблицу 23). Коды ошибок приведены в разделе 5.3.

51
If the request is successful, the server returns the HTTP code -200 and a unique OMS
identifier. The structure of the response to a request to close a sub-order according to a given GTIN
are listed in the table below (see Table 23). Error codes are described in section 5.3.

Таблица 23 – Формат ответа на запрос закрытия подзаказа по заданному GTIN


Table 23 - Format of the response to the request to close a sub-order according to a given GTIN

Обязательность
Поле Описание Тип Is it mandatory
Field Description Type to complete the
field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Пример JSON ответа

Sample of JSON response


HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Content-Length: 19
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

{
"omsId" : "CDF12109-10D3-11E6-8B6F-0050569977A1"
}

5.1.8 Получить статус обработки отчёта (Get status processing report)

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


следующие параметры: маркер безопасности (token) и идентификатор СУЗ, идентификатор
отчёта. Маркер безопасности (token) генерируется СУЗ при регистрации клиента СУЗ.
Маркер безопасности (token) передаётся на сервер в HTTP-заголовке с именем «clientToken».

The method receives the report processing status using the following parameters: token,
report identifier and unique OMS identifier. The token is generated by OMS during registration
of OMS client. The token is sent to the server in the HTTP-Header named "clientToken".

52
5.1.8.1 Запрос (Request)

Параметры REST запроса (Parameters of REST request)


URL: http://<server-name>[:server-
port]/api/v2/{extension}/report/info?omsId={omsId}&
reportId={reportId}
Method:GET
clientToken:{clientToken}

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

The query string parameter are listed in the table below (see Table 24).

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


Table 24 - Query string parameters

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Уникальный идентификатор отчёта СУЗ String


reportId Да (Yes)
Unique OMS report ID (UUID)

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

Sample of REST query


GET /api/v2/pharma/report/info?reportId=fab1c0e4-9590-4ed7-8d58-
18862d6a9aab&omsId=CDF12109-10D3-11E6-8B6F-0050569977A1 HTTP/1.1
Accept: application/json
clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f
Content-Type: application/json;charset=UTF-8
Host: localhost:8080

5.1.8.2 Ответ на запрос (Response to request)

При успешном выполнении запроса, сервер возвращает HTTP код -200 и уникальный
идентификатор СУЗ и статус обработки отчёта. Формат ответа на запрос на получение
статуса обработки отчёта приведён в таблице ниже (см. Таблицу 25). Коды ошибок
приведены в разделе 5.3.

If the request is successful, the server returns the HTTP code -200 and unique OMS identifier
and report processing status. The format of the response to a request for receiving the report
processing status are listed in the table below (see Table 25). Error codes are described
in section 5.3.

53
Таблица 25 – Формат ответа на запрос получения статуса обработки отчёта
Table 25 - The format of the response to a request for receiving the report processing status

Обязательность
Параметр Описание Тип
Is it mandatory to
Parameter Description Type
complete the field?

Уникальный идентификатор СУЗ String


omsId Да (Yes)
Unique OMS identifier (UUID)

Уникальный идентификатор отчёта


String
reportId СУЗ Да (Yes)
(UUID)
Unique OMS report ID

String
Статус обработки отчёта
reportStatus Voc. №5 Да (Yes)
Report processing status
(See section 5.2.5.)

Пример JSON ответа.

Sample of JSON response.


HTTP/1.1 200 OK
Pragma: no-cache
X-XSS-Protection: 1; mode=block
Expires: 0
X-Frame-Options: DENY
Content-Length: 108
X-Content-Type-Options: nosniff
Content-Type: application/json;charset=UTF-8
Cache-Control: no-cache, no-store, max-age=0, must-revalidate

{
"omsId":"CDF12109-10D3-11E6-8B6F-0050569977A1",
"reportId":"fab1c0e4-9590-4ed7-8d58-18862d6a9aab",
"reportStatus":"SENT"
}

54
5.2 Справочники (Dictionary)

5.2.1 Справочник №1 «Способ формирования индивидуального серийного номера»


(Voc. №1 «Method of generation of individual serial number»)

Значения справочника «Способ формирования индивидуального серийного номера»


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

Values of the vocabulary «Methods for generating an individual serial number» are listed
in the table below (see Table 26).

Таблица 26 – Способ формирования индивидуального серийного номера


Table 26 – Method of generation of individual serial number)

Константа Описание Тип


Constant parameter Description Type

Самостоятельно.
SELF_MADE String
Self-generated

Оператором ИС МДЛП
OPERATOR String
Generated by Information System MDLP operator

5.2.2 Справочник №2 «Шаблоны КМ» (Voc №2 «Template IC»)

Значения справочника «Шаблоны КМ» приведены в таблице ниже (см. Таблицу 27).

Values of the vocabulary «Template IC» are listed in the table below (see Table 27).

Таблица 27 – Шаблон КМ
Table 27 – Template IC

Константа Описание Тип


Constant parameter Description Type

1 01 + gtin + 21 + serial (13 chars) String

2 01 + gtin + 21 + serial (13 chars) String

3 01 + gtin + 21 + serial (7 chars) String

4 gtin + serial (7 chars) String

5 01 + gtin + 21 + serial (13 chars) String

01 + gtin + 21 + serial (13 chars) + 17 + expDate (4 char)


6 или (or) String
01 + gtin + 21 + serial (13 chars) + 7003 + expDate72 (10 char)

7 01 + gtin + 21 + serial (13 chars) String

55
Константа Описание Тип
Constant parameter Description Type

8 01 + gtin + 21 + serial (20 chars) String

9 01 + gtin + 21 + serial (13 chars) String

10 01 + gtin + 21 + serial (13 chars) String

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


шаблон 2 - при использовании кода маркировки с кодом проверки = 88 символов
шаблон 5 - при использовании кода маркировки с кодом проверки = 44 символа
The following templates are used for the pharmaceutical industry:
template 2 – when using an IC including 88 characters verification code
template 5 – when using an IC including 44 characters verification code

Таблица 28 – Описание шаблонов КМ


Table 28 – Templates description

Наименование Описание
Name Description

Шаблон 1 Лёгкая промышленность, обувь


Template 1 Consumer goods industry, footwear

Шаблон 2 Лекарственные препараты


Template 2 Medical drugs

Шаблон 3 Сигареты, блоки


Template 3 Cigarettes, cartons

Шаблон 4 Сигареты, пачки


Template 4 Cigarettes, packs

Шаблон 5 Лекарственные препараты (короткий код проверки)


Template 5 Medical drugs (short verification code)

Шаблон 6 Производители молока (короткий код проверки)


Template 6 Milk producers (short verification code)

Шаблон 7 Производители шин (короткий код проверки)


Template 7 Tire manufacturers (short verification code)

Шаблон 8 Производители фототоваров (короткий код проверки)


Template 8 Manufacturers of photo products (short verification code)

Шаблон 9 Производители парфюмерной продукции (короткий код проверки)


Template 9 Manufacturers of perfumes (short verification code)

Шаблон 10 Лёгкая промышленность (короткий код проверки), за исключением обуви


Template 9 Consumer goods industry (short verification code). Light industry, excluding shoes

56
Наименование Описание
Name Description

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


шаблон 2 - при использовании кода маркировки с кодом проверки = 88 символов
шаблон 5 - при использовании кода маркировки с кодом проверки = 44 символа
The following templates are used for the pharmaceutical industry:
template 2 – when using an IC including 88 characters verification code
template 5 – when using an IC including 44 characters verification code

5.2.3 Справочник №3 «Статус массива КМ» (Voc №3 «IC array status»)

Значения справочника «Статус массива КМ» приведены в таблице ниже


(см. Таблицу 29).

Values of the vocabulary «IC array status» are listed in the table below (see Table 29).

Таблица 29 – Статус массива КМ


Table 29 – IC array status

Константа Описание Тип


Constant parameter Description Type

Неверный формат запроса String


REQUEST_ERROR
Invalid query format

Массив (пул) КМ был запрошен в РЭ String


REQUESTED
IC array has been requested in the Emission Registrar

В процессе обработки String


IN_PROCESS
Request in processing

Массив (пул) КМ готов к использованию String


READY
IC array is ready for usage

Все КМ в массиве были использованы полностью String


CLOSED
All ICs in array have been used completely

Массив КМ был исчерпан и закрыт String


DELETED
IC array was exhausted and closed

Заказ не был выполнен (неверные параметры заказа,


например, заказ содержит неуникальные серийные
REJECTED номера) String
Order has not been completed (incorrect order parameters, e.g.
the order contains non-unique serial numbers)

57
Диаграмма состояний представлена на рисунке ниже (см. Рисунок 11).

The state diagram is shown in the figure below (see Figure 11).

REQUESTED
REQUEST_ERROR
Запрошен
Ошибка

IN_PROCESS REJECTED

В обработке Отклонен

READY

Готов

CLOSED

Закрыт

DELETED

Удален

Рисунок 11 – Статус массива КМ / Figure 11 - IC array status

5.2.4 Справочник №4 «Статус буфера КМ» (Voc №4 «IC buffer status»)

Значения справочника «Статус буфера КМ» приведены в таблице ниже


(см. Таблицу 30).

Values of the vocabulary «IC buffer status» are listed in the table below (see Table 30).

Таблица 30 – Статус буфера КМ


Table 30 – IC buffer status

Константа Описание Тип


Constant parameter Description Type

Буфер КМ находится в ожидании


PENDING String
IC buffer is pending

Буфер создан
ACTIVE String
IC buffer has been created

Буфер и пулы РЭ не содержат больше кодов


EXHAUSTED The buffer and pools of Emission Registrar do not contain more String
codes

58
Константа Описание Тип
Constant parameter Description Type

Буфер более не доступен для работы


REJECTED String
The buffer IC is no longer available for operation

Буфер закрыт
CLOSED String
IC buffer has been closed

Диаграмма состояний представлена на рисунке ниже (см. Рисунок 12).

The state diagram is shown in the figure below (see Figure 12).

PENDING

В ожидании

EXHAUSTED ACTIVE REJECTED

Исчерпан Активный Недоступен

CLOSED

Закрыт

Рисунок 12 – Статус буфера КМ / Figure 12 - IC buffer status

5.2.5 Справочник №5 «Статус обработки отчёта» (Voc №5 «Report Processing Status»)

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


(см. Таблицу 31).
Values of the vocabulary «Report Processing Status» are listed in the table below
(see Table 31).

Таблица 31 – Статус обработки отчёта


Table 31 – Report Processing Status

Константа Описание Тип


Constant parameter Description Type

Отчёт находится в ожидании


PENDING String
IC buffer is pending

59
Константа Описание Тип
Constant parameter Description Type

Отчёт готов к отправке в РЭ


READY_TO_SEND String
The report is ready to be sent to the Emission Registrar
Отчёт отклонён
REJECTED String
Report rejected

Отчёт отправлен
SENT String
Report sent

Диаграмма состояний представлена на рисунке ниже (см. Рисунок 13).

The state diagram is shown in the figure below (see Figure 13).

PENDING

В ожидании

READY_TO_SEND REJECTED

Готов к отправке Отклонен

SENT

Отправлен

Рисунок 13 – Статус обработки отчета / Figure 13 - Report Processing Status

5.2.6 Справочник №6 «Тип использования» (Voc №6 «Usage Type»)

Значения справочника «Тип использования» приведены в таблице ниже


(см. Таблицу 32).

Values of the vocabulary «Usage Type» are listed in the table below (see Table 32).

Таблица 32 – Тип использования


Table 32 – Usage Type

Константа Описание Тип


Constant parameter Description Type

КМ был передан на производственную линию


USED_FOR_PRODUCTION String
IC was transferred to the production line

60
Константа Описание Тип
Constant parameter Description Type

Производственная линия отправила КМ на принтер


SENT_TO_PRINTER String
Production line sent IC to printer

КМ был напечатан String


PRINTED
IC was printed

Подтверждённая потеря КМ принтером String


PRINTER_LOST
Confirmed loss of IC printer

Нанесение КМ подтверждено String


VERIFIED
The application of IC is confirmed

Для фармацевтической промышленности используется только тип использования VERIFIED. For the
pharmacy industry only VERIFIED is used

5.2.7 Справочник №7 «Статус бизнес заказа» (Voc №7 «Order status»)

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


(см. Таблицу 33).
Values of the vocabulary «Order status» are listed in the table below (see Table 33).

Таблица 33 – Статус бизнес заказа


Table 33 – Order status

Константа Описание Тип


Constant parameter Description Type

Бизнес-заказ создан
CREATED String
Business order created

Бизнес заказ ожидает подтверждения ИС МДЛП


PENDING Business order is awaiting confirmation of the Information String
System MDLP

Бизнес-заказ не подтверждён в ИС МДЛП String


DECLINED
Business order not confirmed in the Information System MDLP

Бизнес-заказ подтверждён в ИС МДЛП String


APPROVED
Business order confirmed in the Information System MDLP

Бизнес-заказ готов String


READY
Business order is ready

Бизнес-заказ закрыт String


CLOSED
Business order is closed.

61
Диаграмма состояний представлена на рисунке ниже (см. Рисунок 14).

The state diagram is shown in the figure below (see Figure 14).

CREATED

Создан

PENDING

В ожидании

APPROVED DECLINED

Подтверждён Отклонен

READY

Готов

CLOSED

Закрыт

Рисунок 14 – Статус бизнес заказа / Figure 14 - Order Status

62
5.3 Формат и коды ошибок (Format and error codes)

5.3.1 Формат ошибки (Error format)

Формат ответа с ошибкой на запрос описан в таблице ниже (см. Таблицу 34).

The format of the response with an error in the table below (see Table 34).

Таблица 34 – Формат ответа с ошибкой на запрос отправки сведений об агрегации


Table 34 - The format of the response with an error

Поле Описание Тип


Field Description Type

JSON Array Of
ProtobeansFieldError
Описание детальных ошибок (по полям)
fieldErrors Object
Detail error description (by the field)
Таблица 35
Table 35

Описание глобальных ошибок JSON Array Of


globalErrors
Global error description String

Результат выполнения запроса


success Boolean
The result of the query

Описание формата объекта «ProtobeansFieldError» приведено в таблице ниже


(см. Таблицу 35).

The format of the «ProtobeansFieldError » object is described in the table below (see
Table 35).

Таблица 35 – Формат объекта «ProtobeansFieldError»


Table 35 – Format of object «ProtobeansFieldError»

Поле Описание Тип


Field Description Type

Описание ошибки
fieldError String
Error description

Наименование поля
fieldName String
Field name

Пример JSON ответа с ошибкой

Sample of JSON response with error


{
"fieldErrors": [
{

63
"fieldError": "string",
"fieldName": "string"
}
],
"globalErrors": [
"string"
],
"success": false
}

5.3.2 Описание ошибок (Error description)

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

Error codes in response to the request are presented in the table below (see Table 36).

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


Table 36 - Error codes in response to the request

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


Error code Description

Операция не выполнена. Неверные входные параметры


400
Request failed. Incorrect parameters

Операция не выполнена. Внутренняя ошибка сервера


500
Request failed. Internal Server Error

64
6. Список изменений (List of changes)

Дата
Версия Список, внесенных изменений
изменения
Version List of changes
Date

Добавлены уточнения о необходимости использования типа оплаты


2.8 paymentType=2 (Раздел 5.1.2.1).
Added information about the need to use paymentType=2 (Section 5.1.2.1)

Внесены следующие изменения:


− в ответе на запрос получения КМ из бизнес-заказа, для параметра blockId
дополнено указание формата UUID (см. раздел 5.1.4.2. Таблица 14);
− изменены примеры REST запросов в разделе 5.1.5.1;
− добавлено уточнение по полю ownerId в примечание к Таблице 17
Раздела 5.1.5.1.
2.7 13.10.2019
The following changes have been made:
− In response to a request to receive a IC from a business order, the indication of the
UUID format is supplemented for the blockId parameter (see section 5.1.4.2.
table 14);
− samples of REST query in Section 5.1.5.1 have been changed;
− Added information about ownerId field in Note (Table 17 Section 5.1.5.1)

1. Обновлен список допустимых символов КМ согласно спецификации GS1 (Раздел 1,


Таблица 1).
2. Уточнено пояснение по правилам генерации серийных номеров (Раздел 5.1.2.1).
3. Изменена обязательность поля freeСode в расширении объекта Order (Раздел
5.1.2.1, Таблица 7) и добавлено соответствующее примечание.
4. Откорректирован пример отчета о нанесении (для производства вне территории
2.6 27.09.2019 Российской Федерации) согласно описанным форматам данных (Раздел 5.1.5.1).

1. Valid characters of IC updated according GS1 specification, see (Section 1, Table 1).
2. An explanation on how to generate serial numbers has been fixed (Section 5.1.2.1).
3. The mandatory parameters for the freeСode field in oblect Order are changed, note
added for this field (Section 5.1.2.1, Table 7).
4 Corrected sample report for drug production outside the Russia according to the
described data formats (Section 5.1.5.1)

1. Добавлено пояснение по правилам генерации серийных номеров (Раздел 5.1.2.1).


2. Внесены изменения в тип поля subjectId и правила его заполнения
(Таблица 8).
3. Добавлены поля freeСode и paymentType в расширение объекта Order
(Таблица 8).
2.5 20.09.2019
4. Добавлено примечание о тарификации бесплатных кодов (Раздел 5.1.2.1).
5. Уточнено значение поля subjectId в примере запроса (Раздел 5.1.2.1).
6. Изменено максимальное количество КМ в отчёте об использовании (30 000 КМ)
(Раздел 5.1.5.1).
7. Уточнено значение поля usageType (=VERIFIED)в примерах запросов (Раздел

65
Дата
Версия Список, внесенных изменений
изменения
Version List of changes
Date
5.1.5.1).

1. An explanation has been added on how to generate serial numbers (Section 5.1.2.1).
2. Type and rules for filling subjectId field are changed (Table 8).
3. The fields freeСode and paymentType are added to the extension of the Order
object (Table 8).
4. Added note about charging free codes (Section 5.1.2.1).
5. The value of the subjectId field in the sample of query has been fixed according to
the format (Section 5.1.2.1).
6. The maximum number of ICs in the usage report has been changed (30 000 ICs) (Section
5.1.5.1).
7. The value of the usageType (=VERIFIED)field in the query sample has been fixed
according to the vocabulary (Section 5.1.5.1)

1. Во всех методах в документе уточнён тип поля omsId – UUID. В примеры


запросов и ответов внесены правки в части указания корректного значения omsId.
2. В описание метода «Создать бизнес-заказ на эмиссию кодов маркировки»
добавлено примечание, содержащее ограничения по количеству кодов маркировки в
бизнес-заказе и количестве товарных позиций в одном бизнес -заказе (Раздел 5.1.2).
3. Изменен тип поля quantity в объекте OrderProduct (Таблица 7).
4. Изменена обязательность поля serialNumbers в объекте OrderProduct
(Таблица 7).
5. Изменен тип и описание поля templateId в объекте OrderProduct
(Таблица 7).
6. Добавлена обязательность для полей в Формат ответа на запрос (Таблица 9).
7. Изменен тип поля expectedCompletionTime в формате ответа на запрос
(Таблица 9).
8. Изменена последовательность полей в объекте BufferInfo, добавлены новые
поля rejectionReason, totalPassed (Таблица 11).
9. Изменена последовательность полей в объекте PoolInfo (Таблица 12).
2.4 25.07.2019 10. Добавлено правило (примечание) получения кодов маркировки (см. раздел
5.1.4.1).
11. Добавлена обязательность для полей в Формат ответа на запрос получения КМ
для заданного товара (Таблица 14).
12. Уточнено значение поля sntins в примерах REST запроса согласно
приведенному формату (Раздел 5.1.5.1).
13. Исправлено значение поля expirationDate в примерах REST запроса
согласно приведенному формату (Раздел 5.1.5.1).
14. Добавлена обязательность для полей в Формат ответа на запрос отправки отчёта
о нанесении КМ (Таблица 18).
15. Добавлено новое поле declineReason в объект OrderSummaryInfo
(Таблица 21).
16. Исключено поле omsId из объекта OrderSummary (Таблица 21).
17. Добавлено правило (примечание) закрытия заказа кодов маркировки (см. раздел
5.1.7.1).
18. Добавлена обязательность для полей в Формат ответа на запрос закрытия
подзаказа по заданному GTIN (Таблица 23).

66
Дата
Версия Список, внесенных изменений
изменения
Version List of changes
Date
19. Добавлен новый шаблон кода маркировки для лекарственных препаратов
(короткий код проверки), внесены уточнения по порядку применения шаблонов
(Таблица 27 и Таблица 28).
20. Внесены изменения в значения справочника «Статус буфера КМ» (Таблица30).
21. Внесены изменения в значения справочника «Статус обработки отчёта»
(Таблица31).
22. В дополнение к описанию статусов массива КМ (Раздел 5.2.3) приведена
диаграмма состояний (Рисунок 11).
23. В дополнение к описанию статусов буфера КМ (Раздел 5.2.4) приведена
диаграмма состояний (Рисунок 12).
24. В дополнение к описанию статусов обработки отчёта (Раздел 5.2.5) приведена
диаграмма состояний (Рисунок 13).
25. В дополнение к описанию статусов бизнес-заказа (Раздел 5.2.7) приведена
диаграмма состояний (Рисунок 14).

1. All methods have been updated in the omsId field format - UUID. The examples of all
queries and responses indicate the correct values of the omsId field.
2. To the description of the “Create a business order for the issue of marking codes”
method, a note is added containing restrictions on the number of ICs in a business order
and the number of product items in one business order (Section 5.1.2).
3. The quantity field type is changed in object OrderProduct (Table 7).
4. The mandatory parameters for the serialNumbers field in oblect OrderProduct
are changed (Table 7).
5. Type and description for the templateId field in oblect OrderProduct are
changed (Table 7).
6. The mandatory parameters for the fields of the Format of the response to the request
are added (Table 9).
7. The expectedCompletionTime field type is changed in the Format of the response
to the request (Table 9).
8. Changed the sequence of fields in the BufferInfo object, added new fields
rejectionReason, totalPassed (Table 11).
9. Changed the sequence of fields in the PoolInfo object (Table 12).
10. Added rule (note) to receive ICs (see section 5.1.4.1).
11. The mandatory parameters for the fields of the Format of the response to the request
for receipt of the CM for a product are added (Table 14).
12. In the sample of query the value of the sntins field is given according to the format
(Section 5.1.5.1).
13. The value of the expirationDate field in the sample of query has been fixed
according to the format (Section 5.1.5.1).
14. The mandatory parameters for the fields of the format of the response to the request to
send report IC utilisation are added (Table 18).
15. Added new field declineReason to the OrderSummaryInfo object (Table 21).
16. The omsId field is excluded from the the object OrderSummary (Table 21).
17. Added a rule (note) to close the order of ICs (see section 5.1.7.1).
18. The mandatory parameters for the fields of the Format of the response to the request
to close a sub-order according to a given GTIN are added (Table 23).
19. A new template for medical drugs has been added (short verification code=5),

67
Дата
Версия Список, внесенных изменений
изменения
Version List of changes
Date
clarifications have been made on how to use the templates (Table 27 and Ta ble 28).
20. The values of the vocabulary IC buffer status have been changed (Table 30).
21. The values of the vocabulary Report Processing Status have been changed (Table 31).
22. In addition to the description of the statuses of the KM array (Section 5.2 .3), a state
diagram is shown (Figure 11).
23. In addition to the description of the KM buffer status (Section 5.2.4), a state diagram is
shown (Figure 12).
24. In addition to the description of the report processing statuses (Section 5.2.5), a state
diagram is shown (Figure 13).
25. In addition to the description of the business order statuses (Section 5.2.7), a state
diagram is shown (Figure 14)
1. Раздел 5.1.5. перенесен в раздел 4.5.
2. Добавлен перевод раздела 4.5.
3. Добавлено описание порядка доступа к API СУЗ для фармацевтической
промышленности при помощи URL.
4. Изменено описание методов и примеров в части правила указания URL.
5. Изменено описание поля sntins в объекте UtilisationReport
(Таблица 16).
6. Изменен пример JSON ответа в разделе 5.1.4.2 в части формата кода.
7. Внесено уточнение о необходимости использования одного статуса VERIFIED
2.3 20.06.2019 в отчете о нанесении.
1. Section 5.1.5 moved to Section 4.5.
2. Added translation of section 4.5.
3. Added descriptions of the OMS API access rules for the pharmaceutical industry using
URL.
4. Description of methods and examples are changed in the part of the URL writing rule.
5. The sntins field description is changed in object UtilisationReport (Table 16).
6. Sample of JSON response in Section 5.1.4.2 has been changed.
7. Added information about using one type of status = VERIFIED

Внесены изменения в формат даты для поля expirationDate расширения


объекта UtilisationReport (Таблица 17).
2.2 22.05.2019
The type for the expirationDate field in the description of the extension of the object
UtilisationReport is changed (Table 17)
1. Исключены разделы, содержащие методы, не применимые к процессам
фармацевтической промышленности.
2. Внесены разделы с детальным описанием шагов процес са эмиссии.
3. В описании API методы описаны согласно последовательности, приведенной
в разделе 4.
4. Исключено поле ownerId из расширения объекта Order (Таблица 8).
2.1 17.05.2019
5. В описании расширения объекта UtilisationReport изменены параметры
обязательности для поля orderType (Таблица 17).
6. Для заказа и отчета о нанесении внесены уточнения о порядке заполнения
специфичных полей.
7. Откорректированы примеры отчета о нанесении согласно описанным форматам
данных.

68
Дата
Версия Список, внесенных изменений
изменения
Version List of changes
Date
8. Внесено уточнение, что функционал для производства лекарственных препаратов
вне территории Российской Федерации находится в режиме отладки.
9. Внесено новое значение статуса обработки отчета COMPLETE и внесены уточнения
в описания статусов (Таблица 31).
10. Внесено уточнение о возможности заказа КМ в двух режимах.
11. Внесено уточнение о необходимости использования одного типа шаблона = 2
12. Внесено уточнение о необходимости соответствия форматов данных в
расширения объекта UtilisationReport форматам соответствующих данных
ИС МДЛП
13. Внесена информация о регистрозависимости названий полей и их значений.
1. Excluded sections containing methods that are not applicable to the processes of the
pharmacy industry.
2. Added sections with detailed description of the emission process steps.
3. Methods are described according to the sequence given in section 4.
4. The ownerId field is excluded from the extension of the object Order (Table 8).
5. The mandatory parameters for the orderType field in the description of the extension
of the object UtilisationReport are changed (Table 17).
6. For the Order and the UtilisationReport, the rules for filling in specific fields
are included.
7. Corrected sample report according to the described data formats.
8. Added information that System function for drug production outside the Russia is under
development.
9. A new report processing status value is added (COMPLETE)and status descriptions are
detailed (Table 31).
10. Added information about the possibility of ordering IC in two modes.
11. Added information about using one type of template = 2.
12. A clarification was made on the need to match the data formats in the extensions of
the UtilisationReport object to the formats of the corresponding fields in
Information System MDLP.
13. Information about the case-dependence of field names and their values has been
entered

69