test bench configuration · web viewthe service shall return to the manufacturer's information...

Approved

______________________

______________________

______________________

«___» ____________ 2018

DraftMethods of testing the processes of generation, deposition and

verification of a crypto-protected marking codeWorking documentation of LLC “Operator-CRPT”

1. Term or Abbreviation

Term or Abbreviation

Description

IC Identification codeCPMC Crypto-protected marking code; marking code

containing key verification and cryptographic

signature. In terms of this document, “CC” and “CPMC” are synonymous.

DP Drug productMI, means

identification

The labeling code on the packaging of the drug product.

OMC Order management station.MDLP Marking and Information System Markirovka.VC Verification code, "crypto".APCS Automated process control system.IR [Identification code] issue recorder.MIE Means of information encryptionSCPMC, IS, MDLP

System of cryptographic protection of marking codes, Issue server, Information system of marking and traceability [of goods]. In terms of this document are synonymous.

TS Technological station.UI The unique identifier for the secondary (consumer) package.

Alphanumeric sequence, field contents (01) Serial and (21) GTIN in the CM structure

2. General information

3. Automation Object Characteristic

4. Network Connection of the Issue Recorder's Hardware Package

5. Procedure for Process Testing at Preparation for Production

6. Procedure for Process Testing at Marking of Products

7. Procedure of Testing the Processes of Wholesale Circulation and Distribution

8. General Requrements to Serialization and Aggregation Equipment Setting

9. Procedure for connecton to the test Bench of the Encrypted Identification Codes Generation Service

1. Term or Abbreviation

CLM Center for labeling and marking. Outside organization. Not part of Operator infrastructure. Carries out a means of identification on labels.

IS MFMP Information System for Monitoring of Flow of Medicinal Products

AD Aggregation document. Data structure describing logistics package and its contents

System Operator From 01.11.2018 Operator-CPRT LLC, according to the Government Decree of August 28, 2018 No. 1018

S Software

2. General Information

Pursuant to Resolution of the Government of the Russian Federation of January 24, 2017 No. 62 "On Carrying out of an Experiment for Labeling with Control (Identification) Marks, and Monitoring of Circulation of Certain Types of Drug Products for Human Use", the experiment has been carried out with regard to certain drug products for human use starting from February 1, 2017.

To implement the provisions of the Federal Law of December 28, 2017 No. 425 on Amendments to the Federal Law of April 12, 2010 No. 61 “On Circulation of Medicinal Products” regarding the introduction of mandatory labeling of medicinal products with control (identification) marks, all drug manufacturers in the Russian Federation must be equipped with specialized equipment for applying identification tools no later than December 2019.

In accordance with the requirements of market regulators (federal executive authorities), 4 groups of data should be included in the composition of the identification code (IС) applied to the secondary packaging by the manufacturer:

а) first data group – Global Trade Identification Number of trade item consisting of 14 numeric characters preceded by application identifier (01);

b) second data group – individual serial number of trade item consisting of 13 characters of numeric or alphanumeric sequence (Latin alphabet) preceded by application identifier (21). Ending character for this data group must be a special delimiting character with ASCII code value 29.

c) third data group – verification key provided by the monitoring system operator to identifier issuers as part of a verification code in accordance with this procedure, which consists of 4 numeric characters preceded by application identifier (91). Ending character for this data group must be a special delimiting character with ASCII code value 29.

d) fourth data group – electronic signature provided by the monitoring system operator to identifier issuers as part of a verification code in accordance with this procedure, which consists of 88 characters (numbers, lower and upper case letters of the Latin alphabet, as well as special characters) preceded by application identifier (92). Ending character for this data group must be a special delimiting

character with ASCII code value 29.

The third and fourth data groups constitute a verification code (VC) generated according to GOST 34.10-2012.

Medicinal product manufacturers shall obtain verification codes from the operator using the drug product identifier issue recorders provided by the operator.

Issuer of drug product identifiers registered with the monitoring system shall file an application to the operator for provision of verification codes.

The application shall be filed using the drug product identifier issue recorders.

This document sets out the process of ordering verification codes by the issuer, process of their provision, and requirements as to the technical infrastructure used by circulation participants when performing the said operations.

3. Automation Object Characteristic

The automation object within this technical solution is the marking business process, i.e. the process of requesting, application and verification of the identification code of drug product using the Russian cryptographic technologies according to GOST 34.10-2012 both at the manufacturing sites in and outside the RF.

For an international manufacturer having its manufacturing sites in and outside the RF, and employing the services of provisional (contract) manufacturers for the DP supply to the Russian market, the process of marking of drug products constitutes of the following steps:

• Placing an order for DP production;

• Creating mandatory identifier fields to be applied within a single or group order for DP production

o by means of an installed centralized software solution in charge of generation and provision of serial numbers and GTIN or

o by ordering the service for creating such fields from a third party service operator or

o by means of a centralized or decentralized manufacturing enterprise control system;

Transferring the generated alphanumeric sequence to SCPMC, via IR or cloud service to obtain a verification code;

• Transferring encrypted identifier received from IR or cloud service to

the enterprise's APCS for the application and verification of the applied code;

• Transferring reports on code/code pool application

4. Network Connection of the Issue Recorder's Hardware Package

Schematic diagram of interactions of the manufacturer's (regardless of its status or size) information system is shown on Figure 1

Hardware package SCPMC shall be integrated with the user's LAN environment in accordance with below diagrams.

If the manufacturer has international manufacturing sites (either own or contract), query for centralized generation of an encrypted code for manufacture at such sites shall be routed to the cloud service located outside the RF.

For the sites of both Russian and international manufacturers located in the RF routing can be performed to a device physically located in the enterprise's premises (issue recorder).

Important: physical location of the issue recorder in the enterprise's premises does not mean that it is incorporated in the local or global information network of the manufacturer (or manufacturing site).

Notes to the diagram of interaction via API:

1. Appeal to the API in the general case comes from the manufacturer's global serialization management system. You can access the API from any level of the enterprise information system. This does not affect the algorithm of the emission recorder.

2. The process routing (for foreign or Russian plat sites) occurs at the service level.

3. The service has two operation modes:

a. In the cryptographic verification code generation mode, the service shall obtain from the manufacturer previously generated codes consisting of a serial number and GTIN. The service shall return to the manufacturer's information system a fully generated code, including the verification code, ready for application on secondary package

b. b. In the mode of generation of full identifier, the service shall, at the manufacturer's request, create a full identifier, including serial number, GTIN and verification code.

4. Generation can be carried out both individually and in packages containing a large number of codes. The Emission Registrar has a capacity for storing in the protected mode previously generated marking codes in the amount of up to 2 million pieces.

5. Procedure for Process Testing at Preparation for Production

Process diagram

5., 6. Тестирование при подготовке производства и маркировке товаровОператор Оборудование

сериализации АСУТП РЭ

6. М

арки

ровк

а тов

аров

. 6.1.

Сери

ализ

ация

5. По

дгот

овка

про

изво

дств

а

Автоматизировнная инициация процесса на

основании сообщения об исчерпании запаса

заказанных КМ

Обработка заявки на серивализацию,

формирование пула КЗКМ

Формирование пула кодов GTIN+S/N,

составление запроса в РЭ

Формирование задания на

нанесение КЗКМНанесение КЗКМ

на упаковку

Формирование задания на

формрование пула кодов

Приняттие решения о необходимости выпуска

пула КМ

Проверка соответствия списку

сосканированнных КМ

Считывание нанесенных КМ

Формирование запроса на

закрытие пула кодов

Закрытие пула и формирование

отчета о закрытии пула кодов

Формирование сообщения оператору о

закрытии пула кодов, передача кодов на

агрегацию

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

Проверяемая функция


Индикация отправки запроса

и получения ответа

Проверка времени

генерации пула КП КМ



Process descriptionIdentification codes arrive to issue recorders against an order of the recorder

user. (Such user may be an information system or APCS). To receive identification codes at client device, an order for identification codes is executed. When the order is fulfilled, a pool of identification codes is downloaded to the client device. In this regard, the pool of identification codes is associated with the order for identification codes based on which the given pool has been generated.

Testing at preparation for production and marking of products

Operator Serialization equipment

Making a decision on the need to issue a IC pool

5. P

repa

ratio

n fo

r pro

duct

ion

6. M

arki

ng o

f pro

duct

s. 6

.1. S

eria

lizat

ion

Function verified

Function verified

Function verified

Function verified

Reading of applied ICChecking readout parameters

Checking compliance with the list of scanned IC

IRAPCS

Automated process initiation based on the message about depleted stock of ordered IC

Generating an assignment to

generate a code pool

Generating an assignment to generate a code pool

Generating an assignment to generate a

code pool

Checking the IC VC generation time

and pool

Generating an assignment to apply

encrypted IC

Generating a query for code pool closure

Generating a message for the operator about the code pool closure; transferring

codes for aggregation

Application of encrypted IC on

package

Pool closure and generation of a code pool closure report

Each serial number constitutes an array of characters in GS1 alphabet for serial number (GS1 AI encodable character set 82).

APCS orders a defined set (pool) of IC from the issue recorder. The status of order for IC and IC pool may be as follows (Table 2):

Table 2

Status Description

"REQUESTED"

("Requested")

Order status

Receipt of IC pool is expected.

Automated transition to "RECEIVED" or "REJECTED"

status after receiving result from the server.

"RECEIVED"

("Not

distributed")

Order/pool

status

Pool of identification codes has arrived; the use of pool has

not been planned.

Pool of identification codes may pass from "Not distributed"

status to "INUSE" status by operator's explicit command

"Plan". Pool of identification codes may pass from "Not

distributed" status to "CLOSED" status by operator's explicit

command "Close".

"REJECTED"

("Pool has not

been generated")

Order status

Refusal to generate response to the order for identification

codes has been received from the issue server specifying the

reason for refusal. Need for such status results from the

demand to process the identifiers set by the user. Order may

be deleted (after investigation of the reason for refusal) by

operator's command "Delete".

"INUSE"

("In use")

Pool status

Pool may be used for distributing IC to process stations of

APCS.

Pool of identification codes may pass from "In use" status to

"EXHAUSTED" status automatically, if the stock of IC is

depleted

Pool of identification codes may pass from "In use" status to

"CLOSED" status by operator's command "Close".

"EXAUSTED"

("Exhausted")

The stock of ordered IC is depleted. Pool of identification

codes may pass from "Exhausted" status to "CLOSED" status

Pool status by operator's command.

"CLOSED"

("Closed")

Pool status

The use of code pool is completed (pool may be closed at any

utilization degree by operator's command "Close"). Issue

recorder sends a final report on identification codes statuses.

After the report is sent, pool of identification codes passes to

"REPORTED" status automatically

"REPORTED"

("Reported")

Pool status

Pool may be deleted by operator's command "Delete"

At testing, IC may be transferred on electronic media.

Estimated parameters and estimation procedure

At testing of interactions with IR, the following parameters shall be

estimated:

Time of IC pool generation (seconds)

Time of performing operations of the cycle "Query for IC pool receipt

– Receipt of IC pool closure report".

The number of requested codes shall be determined based on the enterprise's

needs in each particular case, to ensure complete reproduction of production

processes.

6. Procedure for Process Testing at Marking of Products

6.1. Serialization processes shall be tested by determining the effect of issue recording on IC application by the means provided for by the DP manufacturer's enterprise processes.

Process diagram

Is shown in cl. 5 hereof.

Process description

Описание процесса

Identification codes shall be applied on secondary package of drug products by a serialization unit or by other facilities the functions of which include marking application, and which meet any technical requirements.

Before testing the IC application, the following parameters typical of a specific test object shall be recorded in the draft test protocol:

Feeding type (manual; automated) Feeding speed (packs/min.) Type of application used (laser, bubble-jet, thermo transfer, thermal

inkjet printing)

Estimated parameters and estimation procedure

At testing of IC application, the following parameters shall be estimated:

Application speed (IC/min.) Number of packs of quality below D (pcs., % of defective items of the

total number of applied IC)

The quality of IC application shall be evaluated by an integrated equipment verification system. If technically impossible to evaluate the quality of IC application using equipment, verifier LVS-9510 with 3" (76 mm) field of vision may be used. The quantity of applied IC shall be determined based on the enterprise's needs in each particular case, in accordance with the employed production processes.

6.2. Aggregation processes shall be tested by determining the possibility of IC being read by the means provided for by the DP manufacturer's enterprise processes.

Process diagram

6. Тестирование процессов при маркировке товаровОператор Оборудование агрегации АСУТП

6.2. А

грег

ация

Считывание КЗКМ вторичных упаковок,

поступающих с оборудования сериализации

Упаковка и нанесение SSCC на третичную упаковку

Сверка КМ, полученных из процесса 9.1. и

считанных при формировании

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

Получение нанесенных КМ из

процесса 9.1.

Формирование SSCC для третичной упаковки и описи вложения

Подготовка вторичных упаковок к упаковке в

третичную

Набор вторичных упаковок для упаковки в третичную упаковку

сформирован,перечень вошедших в нее КЗКМ


Просмотр описи вложения средствами

АСУТП

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

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


Process description

Identification codes shall be read from secondary packages entering the aggregation unit which, upon readiness (completeness) for tertiary package generation, shall report the fact of readiness to APCS and transfer the read set of codes. Group code and list of enclosures may be generated both on the side of aggregation system, and on the side of APCS; this depends on the equipment used at the site, and does not influence test results.

Before testing the IC application, the following parameters typical of a specific test object shall be recorded in the draft test protocol:

Type of equipment used at the site which is employed in the tested processes (aggregation system built into the production line; data terminal; artificial vision; separate aggregation vision, etc.)

Estimated parameters

At testing of aggregation systems, the following parameters shall be estimated:

Process testing at marking of products

Function verified

Operator

Function verified

6.2.

Agg

rega

tion

Checking readout parameters against the readout indicator

of aggregation equipment

Aggregation equipment

Viewing the list of enclosures by APCS tools

APCS

Generating SSCC for tertiary package and list of enclosures

Reading encrypted IC of secondary packages that come from serialization equipment

Comparative checking of IC received from process 9.1. and read at tertiary

package generation

Receiving applied IC from process 9.1.

Preparing secondary packages for putting into tertiary package

Packaging and application of SSCC on

tertiary package

Set of secondary packages to be inserted into tertiary package has been generated; the list of

included encrypted IC

Time of reading of applied identification codes (IC/min.) Quantity of unread IC (pcs., % of the total quantity of IC transferred

for aggregation)

7. Procedure for Testing the Processes of Wholesale Circulation and

Distribution

For the participants of wholesale circulation, distribution, testing shall be carried out similarly to cl. 6.2, except that the pool of identification codes comes from the list of enclosures earlier registered by the previous circulation participant, rather than from the serialization equipment.

8. General Requirements to Serialization and Aggregation Equipment Setting

No. Name

SpecificationsRequired

Parameter Required Value

1 Serialization system

Power supplyStandby power supply: UPS to power the controller and workstations with a running time of at least 30 minutes

Printing technology

Thermal inkjet printing (resolution of at least 300 dpi),Laser printing (the laser spot size does not exceed 0.2 mm),Bubble-jet printing (resolution of at least 300 dpi)

Length of print area At least 60 mm (with due regard to human-readable information).

Minimum size of the dot character

No less than 0.255 mm for inkjet printing

Quality degree In accordance with GOST R ISO/IEC 15415-2012.

Error correction method

ECC-200(guaranteed restoration if up to 30% of the image surface is damaged)

Coding ASCII in accordance with GOST R ISO/IEC 16022-2008.

Marking types

Text, numbers, 2D codes (DataMatrix) in accordance with GOST R ISO/IEC 16022-2008, end-to-end marking from the database.

Ink feed for inkjet printing

Replacement print cartridge, direct application

Control unit Industrial controller or panel

computer for centralized control and synchronization of the operation of conveyors, systems for serialization, aggregation, warehousing and repackaging of products, selection of products at the warehouse, as well as data exchange with the IS “Labeling”.

Data download

Creation of templates having a structure used in Association for Automatic Identification "UNISCAN/GS1 RUS", generation of random numbers, download from an external database.

Data processing

Status of printing, serialization, verification, rejection, aggregation, and the current system status in real time.

Backup and recovery

Backup with further recovery of the system with configuration and archive data.

2 Aggregation system

Information display Printing status, verification, rejection, current system status in real time.

Data communication network

Ethernet

Network protocol TCP/IP, Modbus

Minimum module size for reliable reading

0.255 mm.

3 Bar code scanners

Type of information 1D bar codes, 2D codes (DataMatrix).

Functionality Readout, check, removal and addition of a serialized or aggregated product.

Connection depending on the place of use

Ethernet, RS-485, USB

4 Package Type of cardboardGC2/GT2 (coated, with impregnated reverse side) or higher grade*.*Cartons of other grades may be used subject to

pre-testing

General recommendations as to software setting for the purpose of equipment

control.

Software settings related to the length and field alteration capabilities must comply with the GS1 General Specification standard, version 18, ratified in January 2018

o Open for editing and alteration of field 91-98o Maximum length of each field: 90 characters

Fields 91-92 must be made dynamic (must alter together with the unique serial number)

The client-side software must provide for the ability (not blocked) to activate a pixelation mode and/or to change resolution.

Settings of the graphic and modular size of the code must be involuntary (in most cases, software alters the code size automatically). The user must be provided with the possibility to use the size settings

The maximum possible scanning resolution must be chosen on scanners used for initial reading and aggregation, and the artificial vision software must be set to recognize the minimum dot size of 0.255 mm.

Verification settings and requirements to the code application quality must comply with the standard ISO 15415 (GOST R ISO/IEC 15415-2012)

General equipment installation requirements.

Installation must be effected in strict adherence to the regulatory documentation requirements for the installation of production equipment and to the equipment manufacturer’s requirements.

Correctness of the equipment leveling must be checked at acceptance and validation of the production line in accordance with the applicable GOST standards.

During the operation, the printing system (print head) exposure to external factors such as dust and static electricity must be minimized (if not provided for by the station design).

o Requirements as to ingress protection IP50 according to GOST 14254-96 (partial dust protection) or higher

o Adequate equipment grounding must be ensured in accordance with the equipment installation instructions

To avoid poor readability at aggregation, a sufficient degree of the working surface illumination must be ensured (in accordance with the requirements for readout devices).

To ensure even illumination of the working surface, the use of light diffusers might be required.

9. Procedure for Connection to the Test Bench of the Encrypted

Identification Codes Generation Service

9.1Test Bench ConfigurationTest bench of the Identification Code Utilisation Task and Issue Order

Control Station is deployed to the server having IP address 172.104.154.9, TCP

port 9999.

9.2General Notes on the Use of Test BenchTo send queries in accordance with the below description of REST-API, the

following general rules must be adhered to.

REST controller performs authentication of client connections based on the

so-called client token transferred by client in HTTP query header. Header name for

the transfer of client token is "clientToken". Test token 1cecc8fb-fb47-4c8a-af3d-

d34c1ead8c4f

Data should be transferred by POST method using Content-Type:

application/json.

Standard utility cURL of Linux ОS may be used for testing the REST

controller methods.

Sample of command line cURL for REST query:

curl -H "Content-Type: application/json" -H "clientToken: 1cecc8fb-fb47-4c8a-af3d-d34c1ead8c4f" -X POST -d '{"participantName":"LLC Sportmaster","inn":"7728551528","contractNumber":"18-035","contractDate":"2018-08-01","cemName":"LMC of Moscow No. 1","cemContractNum":"2018-012","cemContractDate":"2018-08-02","cemInn":"7728551777","contactPerson":"Director Ivanov Ivan Ivanovich","deliveryAddress":{"city":"the city of Moscow","street":"Moskovskaya St.","building":"bldg.27","office":"606","note":"Knock at the door 2 short and 1 long"},"products":[{"gtin":"848839984","codeTnVed":"451202","releaseMethodType":"PRODUCTION","quantity":100,"identificationType":"PRINTED","serialNumberType":"OPERATOR","serialNumber":"","markingType":"PRODUCT","createMethodType":"CEM","receiveMethodType":"ELECTRONIC","productionLine":"1"},{"gtin":"848839333","codeTnVed":"451233","releaseMethodType":"PRODUCTIO

N","quantity":10,"identificationType":"PRINTED","serialNumberType":"OPERATOR","serialNumber":"","markingType":"PRODUCT","createMethodType":"CEM","receiveMethodType":"ELECTRONIC","productionLine":"2"}],"productionOrderId": "1234567890"}' http://172.104.154.9:9999/api/orderCodes

9.3API Description and Samples of Queries9.3.1 Generating a Business Order for IC Issue

This method accepts data structure JSON and token as a parameter. The token is generated by OCS during registration of OCS client. The token is sent to the server in HTTP-Header named "clientToken". OCS client shall be: accounting system or production line.

The structure of query for generating a business order for IC issue

REST query parameters

URL: http://<server-name>[:server-port]/api/orderCodesMethod: POSTContent-Type: application/jsonFormat of JSON object of POST query

Field Description Type Is it mandatory

to complete the field?

participantName Name of circulation participant

String No

inn INN of circulation participant

String No

contractNumber Number of contract with MTIS Operator

String No

contractDate Date of contract with MTIS Operator

Date

YYYY-MM-DD

No

cemName LMC name String No

cemContractNum Number of contract with LMC

String No

cemContractDate Date of contract with LMC

Date No

YYYY-MM-DD

cemInn LMC INN String No

contactPerson Contact person String No

deliveryAddress Delivery address JSON Object Address

No

products List of products JSON Array of

OrderProduct

Yes

productionOrderId Production order identifier String Yes

Delivery address format – Address

Field Description Type Is it mandatory to complete the field?

сity City String No

street Street String No

building Building number String No

office Office/premises String No

note Note String No

Products description format – OrderProduct


gtin Product GTIN String(14) Yes

codeTnVed Code from the Commodity Nomenclature of Foreign Economic Activity (TN VED)

String(10) Yes

releaseMethodType Method of releasing products into circulation

Guidebook No. 1

Yes

quantity Quantity of IC/MI Integer Yes

identificationType Identifier type Guidebook No. 2

Yes

serialNumberType Method of individual serial number generation

Guidebook No. 3

Yes

serialNumber Individual serial number

String No

markingType Marking type Guidebook No. 4

Yes

createMethodType Method of production Guidebook No. 5

Yes

receiveMethodType Receipt method Guidebook No. 6

Yes

productionLine Production line identifier

String Yes

Guidebook No. 1 – Method of releasing products into circulation

Constant Description Type

PRODUCTION Production in the RF String

IMPORT Import String

Guidebook No. 2 – Type of identifier


PRINTED Printed String

GLUED Glued String

HINGED Hinged String

Guidebook No. 3 – Method of individual serial number generation


SELF_MADE Self-made String

OPERATOR Operator of MTIS String

Guidebook No. 4 – Marking type


PRODUCT_PACKAGE On consumer package String

PRODUCT On products String

PRODUCT_LABEL On products label String

Guidebook No. 5 – Method of production


SELF_MADE Self-made String

CEM LMC String

Guidebook No. 6 – Receipt method


PHYSICAL On physical media String

ELECTRONIC In electronic format String

Sample of REST query URL

http://172.104.154.9:9999/api/orderCodes

Sample of POST query data in JSON format

{"participantName": "LLC Sportmaster","inn": "7728551528","contractNumber": "18-035","contractDate": "2018-08-01","cemName": "LMC of Moscow No. 1","cemContractNum": "2018-012","cemContractDate": "2018-08-02","cemInn": "7728551777","contactPerson": "Director Ivanov Ivan Ivanovich","deliveryAddress": {

"city": "Penza","street": "Moskovskaya St.","building": "27",

"office": "606","note": "Knock at the door, 2 short and 1 long knocks"

},"products": [

{"gtin": "848839984","codeTnVed": "451202","releaseMethodType": "PRODUCTION","quantity": 100,"identificationType": "PRINTED","serialNumberType": "OPERATOR","serialNumber": "will be generated by issue generator","markingType": "PRODUCT","createMethodType": "CEM","receiveMethodType": "ELECTRONIC","productionLine": "1"

}, {

"gtin": "848839333","codeTnVed": "451233","releaseMethodType": "PRODUCTION","quantity": 10,"identificationType": "PRINTED","serialNumberType": "OPERATOR","serialNumber": "","markingType": "PRODUCT","createMethodType": "CEM","receiveMethodType": "ELECTRONIC","productionLine": "2"

}],"productionOrderId": "1234567890"

}

Structure of JSON response to the query for generating a business order

for IC issue

This methods returns order UUID to OCS and estimated order execution time as

a timestamp. UUID is used to access the method of IC receipt from the order.

For production orders with direct utilisation, the returned order completion time

will be equal to zero. Interaction shall be in pseudo-asynchronous mode.

{"error":["Invalid INN parameter length"]}

9.3.2. IC Receipt from Order

Method of receiving IC from order requires the following parameters: token, order UUID, GTIN, quantity of IC to be issued, and template name for IC printing. The token is generated by OCS during registration of OCS client. The token is sent to the server in HTTP-Header named "clientToken". If the order is still being executed, and code pool has not been generated, the method shall return an empty array.

For production with direct application, order shall be executed immediately; in all other cases, order receipt method shall return the expected order execution time calculated based on IR interaction statistics with a small cushion of time.

Structure of query for IC receipt from order


URL: http://<server-name>[:server-port]/api/codes?uuid={uuid}& gtin={gtin}&quantity={quantity}&templateId={templateId}Method: GET

Format of query parameters

Parameter Description Type Is it mandatory to complete the field?

uuid UUID of business order for IC issue

UUID Yes

gtin Product GTIN String Yes

quantity Quantity of requested codes

Integer Yes

templateId IC template identifier String Yes


http://172.104.154.9:9999/api/codes?uuid=550e8400-e29b-41d4-a716-446655441234&gtin=12345678901234&quantity=1000&templateId=vertical

Structure of JSON response to the query for IC receipt from order

Response format


markCodes IC array JSON Array of

MarkCode

Yes

Object format – MarkCode



gtin Product GTIN String Yes

kiz Control and identification mark (CIM)

String Yes

kpkiz CIM verification code String Yes

Sample of JSON response

{"markCodes": [

{"gtin": "12345678901234","kiz": "(01)12345678901234(21)j89TCnKkLPd5X(240)

1234(91)1129","kpkiz": "(92)AusibQLCfH2fbOoXL3yU77gR

BOsnhdkljRGjZvl7gy0Uu9E1l0x6S2RzaWbKSgI1RmYQnZyumM6ZWhx3ktKOCw=="

},{

"gtin": "01334567894321","kiz": "(01)01334567894321(21)j89TCnKkLPd5X(240)

1234(91)1129","kpkiz": "(92)AusibQLCfH2fbOoXL3yU77gR

BOsnhdkljRGjZvl7gy0Uu9E1l0x6S2RzaWbKSgI1RmYQnZyumM6ZWhx3ktKOCw=="

}]

}

9.3.3 Sending the IC usage report to OCS

Method of transferring responses on IC use to OCS. Method accepts token and JSON structure for different types of report:

1. Aggregation – report on packed products with utilized identifiers, including codes of logistic units in which products have been packed

a. Aggregation file may have a subtype: Update which is sent in case of drawing reference samples and other operations resulting in the change of the aggregate composition

2. Rejection of ICs – report on the rejected ICsa. Non-conformity

3. IC verification – report on verified ICs4. IC printing – report on printed ICs

In the report files, the ICs are sent without verification codes. The token is generated by OCS during registration of OCS client. The token is sent to the server in HTTP-Header named "clientToken".

Structure of JSON query for sending the IC usage report to OCS


URL: http://<server-name>[:server-port]/api/reportsMethod: POSTContent-Type: application/json

Query format




String Yes


String Yes

productionOrderId

Production order identifier

String Yes

aggregationPack Aggregation information

JSON Array of AggregationPack

No

rejectedSntins Information on rejected JSON Array of No

ICs RejectedSntin

verifiedSntins Information on verified ICs

JSON Array of String

No

printedSntins Information on printed ICs


No

Object format – AggregationPack



packSerialNumber Package serial number

String Yes

aggregationType Aggregation type Guidebook No. 1 Yes

sntins Array of serial numbers + commodity nomenclatures


No

aggregationPack Aggregation information

JSON Array of AggregationPack

No

Object format – RejectedSntin


sntin Serial number + commodity classification

String Yes

rejectionType Reason for rejection Guidebook No. 2

Yes

Guidebook No. 1 "Aggregation type" – AggregationType


AGGREGATION New aggregation String

UPDATE Update of existing aggregation

String

Guidebook No. 2 "Reason for rejection" – RejectionType


REJECTED Non-conformity String

DROPPED_OUT Other reason for rejection String


http://172.104.154.9:9999/api/reports

Sample of POST query data in JSON format

{"participantName": "LLC Sportmaster","inn": "7728551528","productionOrderId": "20180801","aggregationPack": [

{"packSerialNumber": "123123123123","aggregationType": "AGGREGATION","sntins": [

"123456789012345678901","123456789012345678902","123456789012345678903","123456789012345678904","123456789012345678905"

]},{

"packSerialNumber": "123123123124","aggregationType": "UPDATE","aggregationPack": [

{"packSerialNumber": "456456456456","aggregationType": "AGGREGATION","sntins": [

"123456789012345678906","123456789012345678907","123456789012345678908","123456789012345678909","123456789012345678900"

]}

]}

],"rejectedSntins": [

{"sntin":"123456789012345678911","rejectionType":"REJECTED"

},{

"sntin":"123456789012345678912","rejectionType":"DROPPED_OUT"

}],"verifiedSntins": [

"123456789012345678921","123456789012345678922","123456789012345678923","123456789012345678924","123456789012345678925"

],"printedSntins": [

"123456789012345678931","123456789012345678932","123456789012345678933","123456789012345678934","123456789012345678935"

]}

Structure of JSON response to the query for transferring a report on IC

use to OCS

Response format


success Attribute of successful report Logical Yes

receipt (true/false)

errors Description of errors if success=false

JSON Array of Strings

No


{"success":true}

9.3.4 Receipt of IC usage report from OCS

This method is designed for loading a report on made orders for IC issue and on IC usage into the accounting system. The method accepts the token and start and end date/time of data retrieval for the report (possibly the report query parameters list will further be expanded); specifying the period of data retrieval is mandatory if the production order is not specified. The token is generated by OCS during registration of OCS client. The token is sent to the server in HTTP-Header named "clientToken". The method returns the structure of data for the selected period or, if the period is not specified, all orders for IC under the selected production order.

Structure of query for receipt of IC usage report from OCS


URL: http://<server-name>[:server-port]/api/codeUsage?from={fromTimestamp}&to={toTimestamp}&productionOrderId={productionOrderId}Method: GET

Format of query parameters


from Date and time of start of retrieval

Integer No

to Date and time of end of retrieval

Integer No

productionOrderId Production order identifier

String Yes

Response format



orderReports Data array on IC usage JSON Array of

OrderReport

Yes

Object format – OrderReport


productionOrderId Production order identifier String Yes

uuid Business order UUID UUID Yes

codeStatuses IC usage statuses JSON Array of

SntinStatus

Yes

Object format – SntinStatus


sntin Serial number + commodity nomenclature

String Yes

codeStatus IC use status Guidebook No. 1

Yes

Guidebook No. 1 "IC use statuses" - CodeStatus


GENERATED IC issued String

UTILISED IC applied String

VERIFIED IC verified String

REJECTED IC rejected (non-conformity) String

DROPPED_OUT IC rejected (another reason) String

PACKED IC packed String

UNKNOWN Unknown String


{"orderReports": [

{"productionOrderId": "12345678901234","uuid": "550e8400-e29b-41d4-a716-446655441234","codeStatuses": [

{"sntin": "123456789012345678901234","codeStatus": "GENERATED"

},{

"sntin": "123456789012345678901235","codeStatus": "PACKED"

}]

},{

"productionOrderId": "12345678901236","uuid": "550e8400-e29b-41d4-a716-446655441236","codeStatuses": [

{"sntin": "123456789012345678901236","codeStatus": "UTILISED"

},{

"sntin": "123456789012345678901237","codeStatus": "REJECTED"

}]

}]

}

9.3.5. Document transfer to MTIS

Method is intended for transferring any documents to MTIS. Method accepts token and JSON as parameters. The token is generated by OCS during registration of OCS client. The token is sent to the server in HTTP-Header named "clientToken".

Structure of request for document transfer to MTIS


URL: http://<server-name>[:server-port]/api/docsMethod: POSTContent-Type: application/json

Query format



String Yes


String Yes

receiverId Receiving subsystem identifier

String Yes

documentType Document type String Yes

document Document in the Base64 format

String Yes

The identifier parameter of the receiver sub-system is required because there may exist more than one marking system and it is therefore necessary to specify the document addressee.

Structure of JSON response to the query for document transfer to MTIS

Response format


uuid UUID assigned to the document in OCS

UUID No

status Document sending status Guidebook No. 1

Yes

UUID is assigned to the document if only the document is successfully enqueued.

Guidebook No. 1 "Document sending status" – DocStatus


ENQUEUED Document is enqueued for processing

String

REJECTED Document is rejected (format error) String

Sample of REST query URLhttp://172.104.154.9:9999/api/docs

Sample of POST query data in JSON format{

"participantName": "LLC Sportmaster","inn": "7728551528","receiverId": "20180801","documentType": "1","document":

"SW1hZ2VuYXJpdW0gaXMgYSBQb3N0LURldk9wcyBlcmEgc29sdXRpb24h"}

test bench configuration · web viewthe service shall return to the manufacturer's information...

Documents