СИСТЕМА АВТОМАТИЗАЦИИ ОБМЕНА КОДАМИ МАРКИРОВКИ Российский патент 2022 года по МПК H04L12/28 G06Q10/06 

Область техники

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

Предшествующий уровень техники

Проблема борьбы с контрафактной продукцией занимает существенное место в различных сферах производства и потребления. Как производитель товара, так и потенциальный потребитель заинтересованы в создании существенных препятствий для недобросовестных и преступных организаций по выпуску поддельного продукта.

В связи с этим в уровне техники представлен широкий спектр методов противодействия выпуску контрафакта, различающихся по применяемым техническим средствам и по стоимости осуществления.

Так, известны методы защиты, заключающиеся в выпуске упаковки (тары) продукта определенной сложной формы, использование голографических элементов, водяных знаков, интеграцию линии по выпуску продукта с системой определения подлинности и прочее. Данные способы лишены универсальности, поскольку для разного вида продукции предполагают применение различных технических средств и достаточно быстро воспроизводятся злоумышленниками.

Известны решения, основанные на маркировке товаров или документов двухмерными кодами (QR-code, DataMatrix и т.п), которые являются универсальными в смысле возможности их применения для маркировки выпускаемой продукции и последующей прослеживаемости маркированного продукта по товаропроводящей цепи

Так, известно решение, (US 2018314869 А1, 01.11.2018) представляющее собой способ для проверки подлинности маркировки, который включает съемку подлинного отпечатка двухмерного кода, формирование уникальной цифровой последовательности, описывающей микронеровности печати подлинного отпечатка двухмерного кода, сохранение уникальной цифровой последовательности в базе данных, для проверки другого отпечатка двухмерного аналогично формируют цифровую последовательность, сравнивают указанные две цифровые последовательности и, в случае если цифровые последовательности совпадают, делают вывод о подлинности другого отпечатка двухмерного кода, в противном случае делают вывод о том, что другой отпечаток двухмерного кода не является подлинным.

Однако данное решение не имеет ряд недостатков и широкого применения не получило. В настоящее время решения, осуществляющие маркировку товаров, в большинстве своем базируются на принципе эмиссии кода маркировки, преобразовании кода маркировки в средство идентификации - двумерный код стандарта DataMatrix и последующую прослеживаемость смены статуса кода маркировки и смены его владельца через централизованную государственную информационную систему.

Основной проблемой такого подхода, решаемой в рамках данной заявки, является то, что государственные информационные системы не автоматизируют бизнес-процессы, лежащие за пределами непосредственно эмиссии кода маркировки и прослеживаемости его статуса и смены владельца внутри системы. В то время как для участников оборота продукции подлежащей обязательной маркировке появляется ряд задач, которые необходимо решать самостоятельно, основной из которых является обмен кодами маркировки с контрагентами.

Таким образом, в связи с вводом обязательной цифровой маркировки товаров в странах ЕАЭС, со стороны участников оборота товаров данных стран, подлежащих обязательной маркировке, появляется спрос на целый ряд новых услуг. Все услуги связаны с основной сущностью бизнес-процессов маркировки товаров - кодом маркировки и основными действиями над ними:

- получением кода маркировки из информационной системы Оператора Маркировки;

- доставкой кодов маркировки поставщикам услуг, которые осуществляют его преобразование в средство идентификации, таким как типографии, логистические операторы, таможенные склады и др. Доставкой в неизмененном (неискаженном) виде, с контролем срока годности кода маркировки, контролем смены владельца кода маркировки (его текущего местонахождения) и его статуса (состояния);

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

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

Следовательно, код маркировки представляет собой новую сущность, которая заставляет участников оборота продукции, подлежащей обязательной маркировке, устанавливать новые связи с контрагентами по всему миру, включая собственные производственные площадки, склады, офисы и др. Участники оборота вынуждены внедрять новые бизнес-процессы, необходимые для работы с кодом маркировки и сопутствующим процессам его эмиссии и использования документооборотом.

При этом национальные Операторы Маркировки не предоставляют участникам оборота продукции, подлежащей обязательной маркировке инструментов для автоматизации этих, новых процессов. Операторы Маркировки предоставляют программные интерфейсы необходимые для взаимодействия с их инфраструктурой, интеграция и реализация требуемых бизнес-процессов целиком и полностью ложится на участника оборота.

Серьезной проблемой для участников оборота продукции, подлежащей обязательной маркировки является внедрение новых бизнес-процессов связанных с кодом маркировки у своих контрагентов, которые не хотят нести дополнительные затраты на инфраструктуру, что необходима для обеспечения процессов доставки кодов маркировки на их производственные площадки и сопутствующему документообороту с участником оборота товаров (импортером).

Печать кода маркировки на выпускаемую продукцию непосредственно на производственной площадке методом прямого нанесения самим участником оборота продукции, подлежащей обязательной маркировке, получающем коды от национального Оператора маркировки, напрямую в свою систему управления производственными процессами (АСУТП), применяется достаточно редко, так как требует переоснащения производства, реализации интеграций в сложных система, зачастую иностранного производства (с долгим циклом выхода обновлений) и подходит для очень ограниченной группы участников оборота.

Участникам оборота необходимо решение-посредник, упрощающее интеграцию с информационными системами Операторов Маркировки и их существующими инфраструктурами, облачный сервис, обеспечивающий взаимодействие с контрагентами и поставщиками услуг маркировки.

В большинстве случаев для маркировки товаров применяется технология этикетирования (печати кода маркировки на этикетке типографским способом, либо на специализированном оборудовании размещенном на логистических, либо таможенных складах), либо печати кода маркировки на упаковке (таре) продукции в типографиях. Таким образом, маркировка «обрастает» целым слоем поставщиков услуг и новых бизнес-процессов, обеспечивающих взаимодействие с ними, и это только на услугах, связанных с нанесением кода маркировки на этикетку или упаковку (тару), а необходима еще и логистика, услуги таможенных брокеров, имеющих экспертизу в процессах таможенного оформления маркированной продукции. Очень важно в этой связи отметить, что большой объем продукции, подлежащей обязательной маркировке выпускается за пределами стран ЕАЭС, в частности в Китае. Согласно действующим НПА продукция в страны, где введена обязательная маркировка, должна поступать уже маркированной. Таким образом у участников оборота продукции, подлежащей обязательной маркировке, в данном случае импортеров продукции производимой за пределами стран ЕАЭС, возникает необходимость в передаче больших массивов кодов маркировки на иностранные производственные площадки, контроле доставки (гарантированной доставке) и получения отчетности от производственных площадок по использованию кодов маркировки. Для самих площадок, которые не всегда заинтересованы во внесении серьезных изменений в свои бизнес-процессы и реализации новых интеграций в свои системы, необходимо предоставить максимально простые и удобные интерфейсы, в ряде случаев даже не программные а пользовательские, реализованные в личных кабинетах облачной платформы (онлайн-сервиса, системы).

В условиях быстрого роста и внедрения проектов маркировки в различных странах, необходима виртуальная среда, коммуникационная сеть, облачная платформа платформа (сервис), для поиска поставщиков услуг, заказа услуг по преобразованию кодов маркировки в средства идентификации и их печати на этикетках, таре, либо упаковке и обмена кодами маркировки с поставщиками услуг и зарубежными производственными площадками. При этом такая среда должна обеспечивать повышенную надежность передачи кодов без искажения с целью их соответствия установленным в НПА требованиям, так же среда должна обеспечивать контроль смены владельца кода маркировки внутри системы, его текущий статус и оценку качества (валидацию) средства идентификации, в которое преобразуется код маркировки. Без такой среды внедрение маркировки в существующих условиях будет существенно затруднено, а в ряде случаев невозможно, по той причине, что единственной альтернативой предлагаемому решению является передача кодов маркировки от участника оборота до поставщика услуг, посредством стандартных средств обмена информацией, таких как:

1. Электронная почта

2. Файловые серверы

3. Носители информации

Так как в данном случае речь идет об огромных (миллиарды единиц) массивах кодов маркировки, их учет, контроль целостности, текущего местоположения и статуса, при использовании вышеперечисленных средств и способов передачи будет невозможен. Как следствие будут потери, кражи, применение кодов маркировки для осуществления маркировки контрафакта. Самой болезненной проблемой в данном контексте является искажение кода маркировки, так как приводит к невозможности его обработки средствами технического зрения в товаропроводящей цепи и соответственно невозможности осуществления прослеживаемости маркированной продукции. Следствием данной ситуации может стать дискредитация проекта маркировки и признание его нереализуемым со стороны государственных органов стран, где внедряется обязательная маркировка продукции. Необходимо дополнительно отметить, что в случае искажения кода маркировки, продукция на которую будет нанесено средство идентификации (код маркировки в графической форме), его содержащее будет считаться немаркированной и за ее оборот будут соответствующие штрафы.

В качестве иллюстрации решений, имеющих отношение к национальным системам маркировки, известных из патентных источников, можно указать программно-аппаратный комплекс, предназначенный для создания распределенной системы по заказу, выпуску и контролю уникальных кодов маркировки продукции, раскрытый в патентном документе RU 2183349 С1, опубликованном 10.06.2002.

Известное решение содержит центральный сервер и периферийные АРМ (автоматизированные рабочие места), связанные каналами передачи данных. Функционально известное средство обеспечивает прием заказов на выпуск (эмиссию) кодов маркировки, передачу кодов для печати и нанесения на их продукцию. Валидация кодов при печати и их идентификация на пути продвижения товаров осуществляется обычным для данной области техники образом.

Вместе с тем известный комплекс не позволяет обеспечить автоматизацию бизнес-процессов, которые лежат за пределами таких систем (систем непосредственно осуществляющих маркировку), а также решить отмеченную выше проблему искажения кодов маркировки при их передаче, проблему отсутствия контроля передачи и статуса кода маркировки и верификации качества преобразования в средство идентификации, а так же проблему интеграции системы маркировки с оборудованием участника оборота.

Национальные системы маркировки, например проект «Честный знак» в РФ, не имеют связей с другими системами маркировки в странах, где так же внедряется обязательная маркировка товаров. Каждая система автономна и обслуживает локальный рынок. Поставщики услуг преобразования (печати) кода маркировки не являются участниками государственных информационных систем, обслуживающих маркировку, т.е не имеют к ним доступа (потому что не являются участниками оборота продукции, подлежащей обязательной маркировке) и не могут получать коды маркировки непосредственно от национальных Операторов Маркировки.

В тоже время, поставщики услуг, например типографии, обслуживают контрагентов не только из стран своей непосредственной локации, но и зарубежных стран, где так же внедрена обязательная маркировка. Логистические склады, зарубежные производственные площадки так же работают с импортерами из всех стран ЕАЭС. Таким образом, возникает явно выраженная потребность бизнеса в существовании единой среды, облачной платформы (сервиса), которая свяжет участников оборота маркированной продукции различных стран и позволит им осуществлять обмен кодами маркировки с поставщиками услуг, при этом сохраняя их целостность и обеспечивая гарантированную доставку кода маркировки, контроль перемещения кода маркировки (смены владельца), его текущий статус и срок годности.

Проблема уровня техники также заключается в том, что обмен кодами маркировки по электронной почте и через любые носители, как отмечено выше, в большинстве своем приводит к нарушению целостности кода маркировки, в силу наличия в его составе специальных и нечитаемых символов (например, символы символики Data Matrix в версии ЕСС 200 по ISO/IEC 16022, являются единственной версией, поддерживающей структуры данных Системы GS1, включая специальное использование функционального знака FNC 1), которые искажаются, либо удаляются программами, посредством которых осуществляются обмен либо конвертация в различные форматы обмена данными. В результате средство идентификации содержит искаженный код маркировки, не соответствующий НПА страны, выпустившей код маркировки и продукция на которую нанесено такое средство идентификации согласно действующему законодательству считается немаркированной, а за оборот такой продукции налагается штраф.

Еще одной проблемой уровня техники является необходимость обеспечения сопутствующего документооборота для поставщиков услуг с участниками оборота продукции подлежащей обязательной маркировке для обмена сведениями о смене статуса кода маркировки с национальными Операторами маркировки. Согласно действующим требованиям национальных Операторов маркировки, участник оборота продукции, подлежащей обязательной маркировке обязан отчитываться перед национальным Оператором маркировки об изменении статуса кода маркировки, путем отсылки соответствующих отчетов в государственные информационные системы. Реализация такой отчетности представляет собой серьезную проблему, если решать ее через множественные интеграции учетных систем поставщиков услуг и участников оборота продукции подлежащей обязательной маркировке. Такой подход порождает потери данных и неконсистентность состояний кода маркировки в различных системах у участников такого процесса.

Участникам оборота требуется более простая интеграция с сервисами Операторов маркировки, через систему-посредник, которая возьмет на себя часть обработки сведений и упрощение бизнес-процессов. Программные интерфейсы Операторов достаточно сложны для интеграции, как правило их более одного, собственные интерфейсы для выделенных компонентов. Так же Операторы маркировки не предоставляют клиент-ориентированных сервисов, упрощающих внедрение маркировки на производственных площадках. Для транснациональных участников оборота (компаний, ведущих свой бизнес в более чем одной стране, где внедрена обязательная маркировка продукции), подобные интеграции являются крайне затратными, особенно если они используют для своей автоматизации информационные системы стороннего производства. Одновременные интеграции одной информационной системы, управляющей производственными процессами в нескольких странах с несколькими Операторами маркировки требуют глобальной переделки систем управления. Участникам оборота приходится проводить реинжиниринг бизнес-процессов управления производством.

Таким образом существует необходимость решения проблемы обмена кодами маркировки, документами и сведениями, между участниками национальных систем маркировки и поставщиками услуг, в особенности международных, через централизованное решение, облачную платформу (сервис) и необходимость упрощения процессов интеграции с инфраструктурами Операторов маркировки для участников оборота, так же через предоставление им облачной платформы (сервиса), как системы единого окна, одной точки входа ко всем национальным Операторам маркировки.

Предложенное изобретение направлено на преодоление указанных недостатков уровня техники и позволяет обеспечить достижение основных технических результатов, заключающихся в обеспечении автоматизации гарантированной доставки кодов маркировки от участника оборота до поставщика услуги и на производственные площадки контрагентов, с целью исключения риска искажения кода маркировки и сопутствующего документооборота, включающего квитанции, подтверждающие получение сведений и кодов маркировки и отчеты об использовании кодов маркировки в соответствии с требованиями национальных Операторов маркировки, а так же на упрощение интеграции производственных площадок участников оборота, в особенности транснациональных, с инфраструктурами национальных Операторов маркировки.

Раскрытие изобретения

Для достижения указанных технических результатов предложена распределенная система, состоящая из ряда функциональных компонентов, связанных через сетевое взаимодействие. Это естественная модель, которая имплементирует существующие в реальном мире связи между поставщиками и потребителями услуг (контрагентами), создающая максимально адаптированную под бизнес-задачи экосистему, позволяющую поставщикам услуг быстро находить друг друга и клиентов и устанавливать надежные связи, а участникам оборота получить готовое облачное решение, интегрированное с Операторами маркировки всех стран, где вводится обязательная маркировка продукции.

Предложенное изобретение характеризуется следующими существенными признаками: система обмена кодами маркировки (доставки кодов маркировки) и сопутствующего документооборота, состоящая из одного сегмента или нескольких разнесенных территориально и связанных каналами связи через центральный сервер системы или напрямую друг с другом, сегментов сети, каждый из которых выполнен на базе программно-аппаратного комплекса, содержащего сервер сегмента системы, включающего: подсистему личных кабинетов, выполненную с возможностью регистрации участников с разделением их по типам участников на, по меньшей мере: Типография, Логистический склад, Контрактная площадка, Участник оборота товаров, Иностранный производитель, Производитель ПО или оборудования, Таможенный брокер, Контент-провайдер, Транспорт, Консалтинг; подсистему безопасности, включающую модуль авторизации/аутентификации, модуль управления пользователями системы, реализующий функционал управления профилями участников системы и модуль аудита (логирования действий и событий системы); подсистему каталогов, включающую модуль каталога поставщиков услуг, модуль каталога участников оборота, модуль реестра связей между участниками оборота и поставщиками услуг; подсистему обмена кодами маркировки, включающую модуль документооборота, модуль контроля правил оборота и использования кодов маркировки, реестр кодов идентификации; подсистему рейтинга участников сети, включающую модуль расчета рейтинга участника сети; подсистему финансов, включающую модуль биллинга; подсистему взаимодействия, включающую модуль API (программный интерфейс). Внутренняя логика работы клиентской части, равно как и ее функциональная архитектура в рамках данного изобретения не раскрывается, так как в качестве клиентов могут выступать готовые, существующие на рынке решения, например ERP системы, либо автоматизированные системы управления производственными процессами. Система обмена кодами маркировки обеспечивает/предоставляет клиентским системам программный интерфейс (API) для взаимодействия, тем самым определяя правила информационного обмена с ней (протокол). Интеграция с Системой и имплементация правил информационного обмена, определенных структурами данных программного интерфейса является задачей разработчиков клиентских решений, равно как и выбор технологического стека и набора функциональных компонентов клиентского решения.

В следующем разделе описания представлены подробные сведения, раскрывающие изобретение с указанием средств и методов для его осуществления и подтверждением возможности достижения указанных выше, а также иных, следующих для специалиста из описания технических результатов.

Краткое описание фигур чертежей

Сущность изобретения поясняется чертежами, где:

на фиг. 1.1 представлен вариант топологии системы с центральным сервером;

на фиг. 1.2 - вариант топологии системы «кольцо»;

на фиг. 2 - схема функциональной архитектуры системы;

на фиг. 3 - схема функционального взаимодействия;

на фиг. 4 - блок-схема алгоритма отправки заявки на эмиссию КМ;

на фиг. 5 - блок-схема алгоритма получения КМ;

на фиг. 6 - блок-схема алгоритма печати КМ.

Осуществление изобретения

Ниже в описании представлено изобретение в его предпочтительном варианте осуществления, не предназначенном для ограничения объема охраны. Для специалиста будет понятно, что представленные в иллюстративных вариантах элементы системы, обозначенные используемыми в описании понятиями, могут быть также частично или полностью заменены тождественными или пересекающимися понятиями, характеризующими средства, позволяющие выполнить соответствующие функции.

Описанные примеры являются всего лишь возможными вариантами осуществления изобретения. Если явным образом не указано иное, компоненты и функции могут использоваться не во всех вариантах, могут быть использоваться в различных сочетаниях и могут быть разделены, и, кроме того, может варьироваться последовательность действий (стадий), могут использоваться их различные сочетания, и некоторые стадии могут быть разделены. В нижеприведенном описании для обеспечения четкого понимания рассмотренных вариантов осуществления настоящего изобретения указаны различные конкретные детали. Однако специалисту в данной области техники будет ясно, что изобретение может быть осуществлено и без некоторых таких конкретных деталей.

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

АСУТП - Автоматизированная система управления технологическими процессами. Основное программное обеспечение, управляющее производственными линиями или процессами печати у участников проекта.

БД - База данных.

ИС - Информационная система.

ГИС - Государственная Информационная Система национального Оператора маркировки в странах, с обязательной маркировкой.

КМ - Код маркировки. Код маркировки представляет собой цифробуквенную последовательность в электронном виде, сформированную по правилам, которые определены в соответствующих НПА. Код маркировки выпускается (эмититируется) уполномоченными национальными Операторами, полномочия которых определяются государственными органами в странах, где внедряется обязательная маркировка товаров.

ПАК - Программно-аппаратный комплекс.

УОТ - Участник оборота товаров.

ERP (Enterprise Resource Planning) - программный пакет, реализующий стратегию интеграции производства и операций.

Поставщики услуг - Типографии, контрактные производственные площадки, логистические склады, таможенные склады. Третьи лица, не участники систем маркировки или оборота маркированной продукции. Предоставляют услуги по преобразованию КМ в СИ и другие сопутствующие услуги, участникам оборота товаров, подлежащих обязательной маркировке.

Средство идентификации (СИ) - Код маркировки в машиночитаемой форме, представленный в виде штрихового кода, формируемый в соответствии с требованиями, предусмотренными требованиями НПА стран, где введена обязательная маркировка, для нанесения на потребительскую упаковку, или на этикетку, или стикер.

Преобразование кода маркировки в средство идентификации - Процесс кодирования цифробуквенного представления кода маркировки в графическое средство идентификации (знак) в соответствии с требованиями стандарта ГОСТ Р ИСО/МЭК 16022-2008 "Автоматическая идентификация. Кодирование штриховое. Спецификация символики Data Matrix". В процессе кодирования должна применяться символика версии ЕСС 200 и признак соответствия данных типовому формату идентификаторов применения (Al) GS1, согласно разделу 11.1 вышеприведенного ГОСТа.

Верификация преобразования кода маркировки в средство идентификации - Оценка качества нанесения средства идентификации на предмет соответствия его структуры требованиям НПА, а также качества печати в соответствии с ГОСТ Р ИСО/МЭК 15415-2012 и правильности преобразования кода маркировки в средство идентификации в формате DataMatrix в соответствии с требованиями ГОСТ Р ИСО/МЭК 16022-2008, символика версии ЕСС 200, с признаком соответствия данных типовому формату идентификаторов (Al) GS1.

Национальный Оператор маркировки - Государственная или коммерческая организация (как правило, работающая по модели ГЧП), осуществляющая разработку, развитие и сопровождение национальной системы маркировки товаров в странах, где введена обязательная маркировка продукции.

В обобщенном виде инфраструктура предложенной системы представлена на фиг. 1.1 и фиг. 1.2. Как показано в данном иллюстративном варианте, инфраструктура системы может быть реализована в виде нескольких разных топологий. Перечисленные на фиг. 1.1 и фиг. 1.2 варианты являются рекомендуемыми и типовыми, но не единственными и окончательными, система в том числе, может состоять и из одного сервера.

Функциональные компоненты сервера (сегмента) системы описаны далее, каждый сегмент сети содержит такой же, либо адаптированный под цели и задачи сегмента, набор функциональных компонентов. Необходимо отметить, что каждый сегмент системы, включает в себя подсистему «Взаимодействие», состоящую из модулей, обеспечивающих связь сегмента с другими сегментами, системами национальных Операторов маркировки и клиентскими решениями участников оборота и поставщиков услуг.

Следует отметить, что указанная структура может легко масштабироваться как в сторону территориального увеличения, так и сужения. Например, сегменты системы могут быть расположены в регионах одной и той же страны, либо также в любых иных странах, участвующих в программе обязательной маркировки товаров.

Здесь и далее в целях краткости изложения сущности в описании непосредственно не приводятся соответствующие функциональные или информационные связи между модулями. Вместе с тем, указанные связи охарактеризованы посредством указания функций каждого из модулей и описаны в процессах взаимодействия модулей, а отражение связей на поясняющих чертежах в полной мере позволяет раскрыть сущность предложенного изобретения.

Таким образом, в рамках данной заявки под понятием «модуль» понимается часть системы, выполняющая четко определенные функции. Конкретное внутреннее выполнение модуля не имеет значения для возможности функционирования системы в целом, поскольку специалист на основании общих знаний может выбрать конструктивно завершенное средство, выполняющее определенные функции и заменить его другим, выполняющим те же функции. Например, конструктивно модуль может представлять собой программируемую логическую интегральную схему (ПЛИС), логика работы которой может быть задана посредством программирования с использованием программатора и отладочной среды (IDE) на основании алгоритмов или блок-схем (фиг. 4-6) функционирования, представленных в материалах заявки. Также модуль может представлять собой, например, постоянное запоминающее устройство с размещенным на нем программным кодом, выполнение которого процессором компьютера приводит к реализации предписанных кодом функций. В подходящих для этого вариантах осуществления модуль может представлять собой средство, предназначенное для управления электронными устройствами (например, контроллер печати).

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

В качестве не ограничивающего примера, модуль аутентификации/авторизации может представлять собой аппаратный модуль доверенной загрузки, использующий предпочтительную в том или ином случае модель безопасности. Модель безопасности может представлять собой, например, модель дискреционного доступа, модель мандатного управления доступом, модели распределенных систем (синхронные и асинхронные), модель трансформации прав доступа, иерархическая модель, модель безопасных спецификаций, модель информационных потоков, а также иные известные из уровня техники модели, представленные, например, в источнике [1] (В.А. Конявский, Управление защитой информации на базе СЗИ НСД "Аккорд", М.: Радио и связь, 1999), входящим в состав описания в той мере, которая раскрывает более подробную информацию о возможности осуществления определенных признаков.

В заявленном решении, как и в отмеченном уровне техники [1], модуль аутентификации/авторизации должен требовать от пользователей идентифицировать себя при запросах на доступ, а также должен подвергать проверке подлинность идентификатора субъекта - осуществлять аутентификацию. Модуль должен располагать необходимыми данными для идентификации и аутентификации и должен препятствовать доступу к защищаемым ресурсам неидентифицированного пользователя или пользователя, чья подлинность при аутентификации не подтвердилась. Модуль должен обладать способностью надежно связывать полученные результаты идентификации со всеми действиями данного пользователя. ([1], с. 70). В рамках данной заявки модуль аутентификации/авторизации может, согласно указанному уровню техники, включать в себя touch-memory интерфейс, энергонезависимую память, датчик случайных чисел, ROM BIOS. Кроме этого, должен быть организован интерфейс связи с ЭВМ ([1], с. 100). Структура и выбор аппаратных средств, а также их взаимосвязей для осуществления модуля аутентификации/авторизации может быть легко определена специалистом на основании уровня техники (см., например, [1], с. 100-130). Например, модуль аутентификации/авторизации может быть выполнен на базе контроллера «Аккорд 4++» и соответствующих шин и интерфейсов ([1], с. 107). Также для специалиста будет понятна сама процедура осуществления аутентификации/авторизации, поскольку это представляется очевидным из уровня техники (см., например, [1], с. 132-137) и конкретный ее вид не входит в рамки правовой охраны предложенного решения.

Вместе с тем, необходимо отметить, что здесь и далее в каждом из входящих в состав системы модулей, при функционировании которых требуется осуществлять выборочный/ограниченный/доверенный доступ к ресурсам системы (например, право на доступ к определенным операциям) под средствами контроля доступа следует понимать средства, с помощью которых ресурсы системы обработки данных предоставляются только авторизованному субъекту в соответствии с установленными правами на доступ (см. [2] ГОСТ ISO/TS 22600-3-2013, п. 3.1).

Например, логика работы модуля управления пользователями системы может быть задана с учетом известных из [2] средств и алгоритмов.

В частности, функция принятия решения о доступе (access control decision function, ADF) представляет собой специализированную функцию, применяющую правила политики контроля доступа к требуемому действию для принятия решения о доступе. Под политикой (policy) понимается комплекс юридических, методических, организационных, функциональных и технических обязательств или запретов по обмену информацией и совместной деятельности.

Функция применения решения о доступе (access control enforcement function, AEF) представляет собой специализированную функцию, обеспечивающую запрашивающей стороне доступ к требуемому ресурсу в соответствии с решением, принятым функцией принятия решения о доступе.

Информация, используемая для управления доступом (access control information) представляет собой любую информацию, используемую для целей контроля доступа, в том числе контекст.

Учетность (accountability) - свойство, обеспечивающее однозначное отслеживание собственных действий любого логического объекта.

Заявитель (claimant) - организация или лицо, запрашивающее у контролера выполнение или предоставление чувствительного сервиса в соответствии с привилегиями, указанными в его сертификате атрибута или в расширении атрибутов каталога субъекта его сертификата открытого ключа.

Например, при использовании веб-сервисов спецификация политик веб-сервисов (WS-policy) является гибкой и расширяемой грамматикой на языке XML и предназначена для описания возможностей, требований и общих характеристик объектов систем, основанных на применении веб-сервисов, в форме информации о политике веб-сервиса, специфичной для конкретной предметной области. Она определяет комплекс альтернативных политик, каждая из которых является комплексом объявлений политики, например, схема аутентификации, выбор транспортного протокола, политика конфиденциальности, характеристики качества сервиса QoS (Quality of Service) и т.д. Для совместимости политик могут использоваться установки о словаре данных и семантике. Спецификация WS-Policy Attachment (Web Services Policy Attachment) описывает, как связать политики с субъектами, с которыми они применяются, используя описания WSDL.

В частном случае, может применяться язык политик веб-сервисов WSPL (Web Services Policy Language), который является ограниченным подмножеством стандарта XACML организации OASIS, обеспечивающим отображение политик. Объединенные политики могут быть выражены с помощью детальных атрибутов, например, время дня, цена или сетевые характеристики.

На технологическом уровне управление доверием может включать в себя:

- протоколы, с помощью которых потребитель сервиса взаимодействует с его поставщиком. Например, может требоваться передача сообщений SOAP (simple object access protocol) по протоколу HTTPS;

- уникальную идентификацию всех интересующих лиц; к ним относятся лица, имеющие роли потребителей, контрагентов или служащих;

- обеспечение совместного доступа к информации, необходимого внутренним структурам предприятия и внешним партнерам.

К примеру, может быть определена политика регистрации, автоматически создающая учетные записи пользователей (каталог LDAP или база данных с идентификатором учетной записи joe для Joe Smith) в хранилище предприятия (идентификатор учетной записи joesmith для Joe Smith) и в системе сервиса идентификации объектов (учетная запись прикладного уровня с идентификатором joe1234 все для того же пользователя Joe Smith).

Эта политика может быть расширена за границы предприятия, например, учетная запись пользователя создается еще и в регистре внешних потребителей сервиса (с идентификатором homejoe для Joe Smith). Эта политика регистрации может включать в себя несколько рабочих процессов, например, получение разрешений на управление пользователями.

Составной частью таких политик регистрации являются политики идентификации и паролей. Политики идентификации описывают, каким образом создаются различные атрибуты различных учетных записей на основе идентифицирующей информации пользователя и корпоративных правил безопасности.

В данном примере политика идентификации может состоять в создании имени учетной записи, которое состоит из первой буквы имени и букв фамилии пользователя (например, jsmith для Joey Smith). Политика идентификации может распространяться и на другие атрибуты, например, на адреса электронной почты.

Политики паролей могут применяться для контролирования способов создания и управления паролями. Например, в политике может быть указана минимально допустимая длина пароля, обязательно использование букв и специальных символов, а также срок действия, вынуждающий пользователей менять свои пароли каждые три месяца. Выполнение этих требований усиливает безопасность системы, поскольку слабость паролей создает известные риски.

Модуль аудита в предложенном изобретении предпочтительно используется для сбора, хранения и анализа логов (журналов) системы, например, в целях отслеживания (предотвращения либо расследования) инцидентов безопасности (например, так же, как в [3] Журнал «Информационная безопасность», #1, 2013, с. 47) в соответствии со стандартом PCI DSS.

Процесс логирования (журналирования) - автоматическая запись событий, происходящих в рамках определенного процесса. Логирование позволяет оценивать состояние процесса и регистрировать ошибки. Главное преимущество использования логирования заключается в предоставлении возможности контролировать процесс выполнения бизнес-логики как отдельного процесса, так и системы в целом. Непосредственными потребителями данных, предоставляемых системой логирования, могут быть: разработчики и служба сопровождения ПО; системные администраторы и администраторы безопасности аналитики информационной системы.

Процесс логирования можно логически поделить на несколько этапов: регистрация событий и передача информации о них в хранилище данных; анализ и структуризация полученных данных и запись их в хранилище; мониторинг данных хранилища и управление процессом логирования.

Сопоставив каждому логически выделенному этапу свой уровень, получим трехуровневую систему: 1) Клиентский уровень; 2) Уровень БД; 3) Уровень администрирования (см., например, [4] Журнал «Современная наука: актуальные проблемы теории и практики», Серия: Естественные и технические науки №4 апрель 2019, с. 48, рис. 6).

Журналы могут собираться со всего оборудования, входящего в область применения - с операционных систем серверов, с управляемого сетевого оборудования, со всех мест хранения данных, а также со всего ПО для доступа к данным. При наличии виртуализованных компонентов журналы возможно собирать в том числе и с гипервизоров, чтобы исключить возможность подлога на уровне управления виртуализацией. Также журналы могут вестись дополнительными системами безопасности: антивирусом, системой обнаружения вторжений, системой контроля целостности.

По типам логи могут быть разделены на следующие: системные логи, то есть те, которые связаны с системными событиями; серверные логи, регистрирующие обращения к серверу и возникшие при этом ошибки; логи баз данных, фиксирующие запросы к базам данных; почтовые логи, относящиеся к входящим/исходящим письмам и отслеживающие ошибки, из-за которых письма не были доставлены; логи авторизации; логи аутентификации; логи приложений, установленных на этих операционных системах.

В частном случае осуществления, модуль аутентификации/авторизации и модуль аудита могут быть объединены на базе аппаратных средств компании Avocent, представляющих собой централизованную систему Out-of-Band управления, включающую резервируемую и масштабируемую систему управления DSView 3, систему учета ресурсов инфраструктуры ЦОД (Asset Management) AMIE, аппаратные средства Out-of-Band управления, средства удаленного выноса интерфейсов рабочих станций (по IP или САТ5), средства локальной KVM коммутации для технологических предприятий и ЦОД.

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

Основой для осуществления указанных модулей могут служить такие понятия как сущность (thing), класс (class), взаимоотношение (Relationship) в соответствии с [5] - ГОСТ Р ИСО 15926-2-2010 применительно к материализованным физическим объектам. В частности, к таким объектам могут быть отнесены физические секторы машиночитаемого запоминающего устройства, хранящего данные об участниках системы и доступным для них услугам системы (лицензиям), которые способствуют установлению связи между участниками и принадлежащими им местами осуществления деятельности, тем самым разрешая им на системном уровне взаимодействие друг с другом. Выполняя сохраненные на машиночитаемом носителе инструкции, процессор сервера может определить и представить данные о пространственно-временных соотношениях между участниками ([5], п. 4.7.3), которые далее могут использоваться при функционировании указанных модулей системы, как это показано ниже в описании.

При осуществлении модуля документооборота под документацией понимается документация системы управления документами (СУД), представляющая собой документы, которыми необходимо управлять в автоматизированной документной системе ([6] - ГОСТР 7.0.101-2018/ИСО 30301:2011).

При участии в электронном документообороте всегда существует риск несанкционированного доступа к информационному обмену. Для защиты участников электронного обмена в документах может применяться электронная подпись (ЭЦП). ЭЦП, как реквизит электронного документа, предназначен для его защиты от подделки, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи, а также установить отсутствие искажения информации в электронном документе.

Под криптографическим преобразованием следует понимать разновидность шифрования информации, обеспечивающую ее конфиденциальность, возможность однозначной идентификации лица - отправителя информации и исключающую возможность ее несанкционированного изменения; такое шифрование информации осуществляется посредством использования средств ЭЦП.

Под средствами ЭЦП следует понимать сертифицированные программно/аппаратные средства, обеспечивающие реализацию хотя бы одной из следующих функций: создание ЭЦП в электронном документе с использованием закрытого ключа ЭЦП, подтверждение подлинности ЭЦП в электронном документе, создание закрытых и открытых ключей ЭЦП.

Закрытый ключ ЭЦП - это уникальная последовательность символов, известная владельцу сертификата ключа подписи, предназначенная для создания ЭЦП.

Открытый ключ ЭЦП - это уникальная последовательность символов, соответствующая закрытому ключу, доступная любому пользователю информационной системы и предназначенная для проверки подлинности электронного документа и установления лица, от которого исходит документ; открытый ключ ЭЦП оформляется в виде сертификата ключа подписи и передается иным участникам закрытого информационного обмена.

Сертификат ключа подписи - документ на бумажном носителе или электронный документ с ЭЦП уполномоченного лица удостоверяющего центра, который включает в себя открытый ключ ЭЦП; удостоверяющий центр выдает документ для сертификата ключа подписи участнику информационной системы для подтверждения подлинности ЭЦП и идентификации владельца сертификата ключа подписи.

Таким образом, в предложенном решении подсистема обмена кодами маркировки может представлять собой совокупность (кластер) соединенных между собой серверов, один или несколько из которых выделены для осуществления функций документооборота с применением программно-аппаратных средств, включая хранилище подписанных документов, хранилище сертификатов, а также аппаратные ключи (токены), используемые для формирования и подписания документов ЭЦП. В данном случае в рамках настоящей заявки отмеченные выделенные сервера следует принимать во внимание в качестве средства, выполняющего функции модуля документооборота.

С учетом представленных выше сведений о выполнении подсистемы обмена кодами маркировки как кластера серверов, на один или несколько из этих серверов может быть возложена функция модуля контроля правил оборота и использования кодов маркировки.

В частности, функция модуля контроля правил оборота и использования кодов маркировки технически может быть осуществлена в виде BRMS (англ. Business Rule Management System - система управления бизнес-правилами) - информационной системы, используемой для ведения, поддержки и исполнения бизнес-правил компании (см., например, [7] - OMG ВММ Business Motivation Model v1.3, 05.2015)

Заранее определенные логические функции, осуществляемые модулем контроля правил оборота и использования кодов маркировки, расположенные на физических секторах памяти машиночитаемого носителя информации, могут быть выполнены процессором сервера, входящего в кластер серверов подсистемы обмена кодами маркировки.

Модуль API представляет собой стандартный интерфейс, предназначенный для взаимодействия пользователей и/или программных средств системы между собой. Таким образом, данный модуль является неотъемлемой частью системы для возможности взаимодействия ее составных частей в целях реализации указанного в родовом понятии назначения.

Модуль биллинга в рамках данной заявки можно также рассматривать как систему, вычисляющую стоимость услуг для каждого клиента и хранящую информацию обо всех тарифах и прочих стоимостных характеристиках, которые используются операторами для выставления счетов и взаиморасчетов с другими поставщиками услуг. Например, модуль биллинга может представлять собой автоматизированную систему расчетов (АСР).

В частности, в качестве средства для реализации указанного модуля можно рассматривать известное из уровня техники решение АСР Onyma Billing (Сертификат соответствия ОС-3-СТ-0677 от 01.11.2019). В состав данного решения входят Web управляющий сервер, автоматизированные рабочие места операторов, администратора, аналитическую подсистему, ядро системы, центр авторизации и сбора статистики, сервер Web регистрации и статистики. Взаимодействие пользователей с АСР происходит через аппаратуру предоставления услуг (компьютер пользователя, мобильный терминал посредством тонкого клиента).

Система биллинга Onyma Billing позволяет описать физические и логические ресурсы компании, организовать эффективное управление этими ресурсами в тесной интеграции с системой расчета и системой авторизации. Система обеспечивает полный цикл обслуживания, и предоплатные клиенты точно в соответствии с договором будут автоматически отключены системой от получения услуг сразу, как только у них закончатся средства.

В Onyma Billing система сбора, загрузки и первичной тарификации статистики потребления услуг происходит в центрах авторизации. Они выполняют основную вычислительную работу и освобождают от лишней нагрузки основное ядро, с которым работают операторы системы и обеспечивают операторам эффективную работу при обслуживании пользователей. Количество центров авторизации не ограничено, их можно размещать в географически распределенной сети и обслуживать все филиалы компании с разными типами услуг и тарифов на одном ядре биллинг системы.

Центр авторизации и сбора статистики обеспечивает управление оборудованием, авторизацию (RADIUS), предбиллинг и первичную тарификацию, предоставление сервисов в отсутствие связи с ядром. Аналитическая подсистема предоставляет конструктор для построения аналитических отчетов, построение по расписанию, выгрузку в файл требуемого формата (Excel, XML, CSV, PDF), пересылка отчетов по электронной почте.

Интегрирующим ядром АСР "Onyma" является система управления ресурсами, ответственная за описание, управление и конфигурацию всех имеющихся у оператора ресурсов, как физических, так и логических: оборудования, канальной инфраструктуры, адресного пространства, прейскурантов, клиентской базы и т.п. Система способна самостоятельно осуществлять управление оборудованием путем формирования конфигурационных файлов и рассылки управляющих воздействий, а также опознавать внешнее изменение инфраструктуры, получая соответствующие XML уведомления. Таким образом, система в любой момент времени обладает полной информацией о том, какие ресурсы кем используются, что позволяет организовать эффективное управление инфраструктурой в целом и является хорошей базой для построения CRM систем и систем мониторинга (некоторые функции этих систем реализованы непосредственно в АСР "Onyma"). Ядро системы поддерживает набор методов работы с данными, которым может воспользоваться любая из работающих с ним систем ([8] - «Биллинг», #6, 2002, с. 10-12).

Учитывая отмеченные выше возможности известной системы, на базе аналогичного решения может быть выполнена подсистема рейтинга участников сети, включающая модуль расчета рейтинга участника сети (в частности, в виде самостоятельной совокупности серверов, объединенных для совместного функционирования). В данном случае в ядро системы (что можно считать модулем расчета рейтинга участника сети) посредством интерфейса взаимодействия от пользователя будет поступать информация, касающиеся рейтинга участников. Данная информация будет аккумулироваться в системе, своевременно обновляться и предоставляться пользователям по мере необходимости (например, по запросу).

Представленные выше примеры не ограничивают варианты выполнения перечисленных модулей. Как было указано ранее, алгоритм функционирования конкретного модуля может быть запрограммирован в специализированной ПЛИС, либо размещен на физических секторах машиночитаемого носителя информации. Таким образом, в рамках данной заявки понятие «модуль» следует трактовать в неразрывной связи между аппаратным средством (или совокупностью взаимосвязанных средств), выполняющим определенные функции и алгоритмом работы, размещенным на физическом носителе информации.

Основным активом и объектом в предложенной системе является код маркировки и услуги по его гарантированной доставке без искажения и верификации качества преобразования в средство идентификации. Так же система обеспечивает обмен документами и сведениями в рамках сопутствующего документооборота, такими как: заказы на эмиссию кодов маркировки, отчеты об изменении статуса кода маркировки, квитанции о перемещении кода маркировки и др.

Код маркировки - это цифробуквенная последовательность, содержащая в себе специальные символы, ряд из которых является FNC кодами, в соответствии со спецификацией GS1, часть является специальными символами входящими в словарь Base64. Данная цифробуквенная последовательность требует очень аккуратного обращения, в противном случае она искажается (происходит потеря специальных и нечитаемых символов) и участники оборота получают проблемы, описанные в разделе выше.

Код маркировки является крипто защищенным активом, обращение с которым регулируется моделями угроз национальных систем маркировки и соответствующими НПА. Поэтому в предлагаемой системе предусмотрен функциональный компонент, который отвечает за соблюдение данных правил и требований по информационной безопасности при обращении с кодами маркировки, реализованный в модуле контроля правил оборота и использования кодов маркировки.

Код маркировки имеет срок жизни, определяемый в НПА стран. Необходимо не просто доставить код маркировки поставщику услуги, но еще и проконтролировать, что он использует его до истечения срока годности. Срок годности определяет время, которое отпущено национальным Оператором маркировки конкретной страны, участнику оборота с момента получения от национального Оператора кода маркировки до момента преобразования кода маркировки в средство идентификации и отправку в информационную систему национального Оператора маркировки, выпустившего код маркировки, соответствующего сообщения (отчета об использовании кода маркировки). В предложенном изобретении данная возможность реализована в модуле контроля правил оборота и использования кодов маркировки.

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

Также участниками являются поставщики услуг, которые предоставляют услуги преобразования кода маркировки в средство идентификации и/или печати средства идентификации на этикетке, таре или упаковке (непосредственно маркировки), участникам оборота.

Корневые сервисы системы связаны передачей массивов кодов маркировки между участниками системы, данных о кодах маркировки и действиях с/ над кодами маркировки и преобразовании кодов маркировки в средства идентификации (сопутствующим документооборотом), формируемыми механизмами валидации средства идентификации и направляемых в информационные системы национальных Операторов Маркировки.

Предложенное изобретение:

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

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

3. осуществляет прослеживаемость перемещения кода маркировки от одного участника системы к другому, обеспечивает данный процесс соответствующими квитанциями

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

5. предоставляет единую точку входа ко всем сервисам Операторов маркировки стран, где внедряется обязательная маркировка продукции для участников оборота

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

Например, как следует с фиг. 1.1, центральный сервер системы может обеспечить доставку кода маркировки (например, из сегмента Казахстана в сегмент Киргизии) и обеспечить доставку отчетов и сведений из Казахстана в Киргизию, в соответствии с требованиями национального Оператора маркировки Киргизии. Представленные на фиг. 1.1 связи являются иллюстративными, в то же время в рамках предложенного изобретения выбор и установление связей не ограничивается указанным и может быть осуществлен в зависимости от требований рынка (двусторонние связи, многосторонние связи и прочее), равно как и топология сети системы не ограничивается вариантами, проиллюстрированными на Фиг. 1.1 и Фиг. 1.2.

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

1. Регистрация участников;

2. Взаимодействие с национальными системами маркировки Операторов стран;

3. Регистрацию заказов на эмиссию кодов маркировки и их отправку в системы маркировки Операторов стран;

4. Получение кодов маркировки из систем национальных Операторов стран

5. Передачу кодов маркировки внутри системы, например, поставщику услуг для обеспечения нанесения или на собственную площадку участника оборота;

6. Ведение учета отправленных кодов;

7. Контроль сроков, в том числе и срока жизни (годности) кода маркировки;

8. Доставку отчета об использовании кодов маркировки от клиента поставщика услуг к участнику оборота, выпустившему код маркировки, либо в национальную систему Оператора маркировки;

9. Контроль статуса кода маркировки внутри системы;

В предпочтительном варианте осуществления предложенное изобретение представляет собой взаимодействующие между собой части - серверную часть (непосредственно сервер системы, сервер сегмента системы) и клиентские части участников поставщиков услуг и участников оборота.

Необходимо отметить, что описываемое решение, не осуществляет непосредственно процессинг документов и исполнение заказов на эмиссию кодов маркировки, так как они могут быть обработаны только национальными системами Операторов маркировки стран. Система представляет собой инфраструктуру, обеспечивающую необходимые для доставки документов процессы и взаимодействия между участниками системы и информационными системами Операторов маркировки стран, гарантированную доставку документов, контроль жизненного цикла кода маркировки внутри системы, в том числе и срока годности кода маркировки, учет и индексацию проходящих внутри системы документов и кодов маркировки. Необходимо отметить, что получение кодов маркировки и обмен ими между участниками системы так же оформляется отдельным типом внутреннего, системного документа (т.е документа не отправляемого в информационные системы Операторов маркировки)

Общая функциональная архитектура системы представлена на Фиг. 2.

Все документы, проходящие через систему, обрабатываются по единому алгоритму, поступая в подсистему «Взаимодействия» и проходя через подсистему «Обмен кодами маркировки», проходят учет и индексацию, и через подсистему «Взаимодействия» отправляются в национальные системы Операторов маркировки, либо в клиентские системы участников оборота и поставщиков услуг.

Более подробно процесс обработки входящего документа и модули системы, принимающие участие в нем, равно как и выполняемые ими задачи описаны ниже.

Для осуществления взаимодействия с системой пользователь должен пройти авторизацию/аутентификацию. Для этого он обращается на соответствующий метод модуля «API» подсистемы «Взаимодействие» и отправляет запрос на авторизацию/аутентификацию. Модуль API в свою очередь, обращается к подсистеме «Безопасность», с задачей на проверку прав доступа пользователя. Модуль «Авторизации/Аутентификации» подсистемы «Безопасность» обращается к модулю «Управление пользователями» той же подсистемы. Модуль «Управление пользователями» проверяет наличие пользователя в системе, проверяет переданные пользователем данные по своей базе данных и обращается к подсистеме «Каталоги», для проверки прав доступа пользователя. В проверке прав доступа пользователя принимают участие следующие модули подсистемы «Каталоги»:

1. Каталог участников системы - проверяется статус участника, что он активен, у него есть доступные услуги.

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

Модуль «Каталог участников системы» отвечает за сохранение и выборку информации об участниках системы и доступным для них услугам системы (лицензиям) он предоставляет сервисы для пользовательского интерфейса и для других подсистем системы, предоставляющие функции: занесение нового, выборка данных на существующего, удаление, редактирование, необходимые для сохранения и выборки из баз данных информации по участникам системы. Отдельные методы модуля предназначены для обработки и выборке информации о доступных участнику сервисах системы (лицензия) - это простой список, включающий идентификаторы услуг, доступные участнику системы, которые можно добавлять или удалять, используя методы сервиса, так же можно получить полный список услуг. Полный список услуг так же хранится в базе данных модуля «Каталог участников системы» в виде редактируемого списка. Редактирование списка услуг системы доступно только администратору системы в его личном кабинете.

Модуль осуществляет форматно-логический контроль запросов, на предмет соответствия моделям данных системы и сохраняет получаемые сведения в базу данных. Участник системы - это сущность, представляющая пользовательский акаунт. Один акаунт может содержать неограниченное количество связанных с ним пользователей, за работу с которыми отвечает модуль «Управление пользователями», подсистемы безопасность и так же неограниченное количество различных мест осуществления деятельности, таких как: офис, производственная площадка, типография, склад и др.

Модуль «Реестр связей между участниками системы» имплементирует функционал сохранения связей между участниками. В системе, где в основе лежит именно взаимодействие между участниками в части обмена документами и кодами маркировки, необходимо, для предотвращения ошибок пользователей, иметь функционал явного установления связи между участниками и принадлежащими им местами осуществления деятельности, тем самым разрешая на им на системном уровне взаимодействие друг с другом. Связь используется как фильтр в запросах по обмену данными, тем самым, не позволяя участникам системы, между которыми не установлена связь, случайно отправить друг другу документы либо коды маркировки. Модуль «Реестр связей между участниками системы» предоставляет сервисы для пользовательского интерфейса и других модулей системы, предоставляющие функции: занесение нового, выборка данных на существующей связи, удаление, редактирование, необходимые для сохранения связи и выборки данных о связях из баз данных модуля. Модуль осуществляет форматно-логический контроль запросов, на предмет соответствия моделям данных системы и сохраняет получаемые сведения в базу данных.

В случае успешного прохождения проверок запроса на авторизацию/аутентификацию в подсистеме «Каталоги», модуль «Управление пользователями» возвращает положительный ответ модулю

«Авторизация/аутентификация», тот в свою очередь формирует ответ пользователю и отправляет уведомление об успешной авторизации/аутентификации модулю «Аудит», который сохраняет его в базу данных (лог системы). Результатом, обработки запроса на авторизацию/аутентификацию пользователя является клиентский токен, дающий право обращаться на методы модуля «API». Клиентское приложение должно сохранить полученный токен в свою базу данных, для последующего использования.

Клиентский токен имеет срок действия, заданный в настройках системы. По истечении срока действия, клиентское приложение должно повторить процедуру авторизации/аутентификации.

Модуль «Управление пользователями» состоит из базы данных пользователей системы (один участник системы, пользовательский акаунт, может зарегистрировать более одного пользователя), модуль предоставляет сервисы для пользовательского интерфейса и других компонентов системы для работы с пользователями: занесение нового, выборка данных на существующего, удаление, редактирование.

Модуль «Авторизации/аутентификации» отвечает за получение запроса на авторизацию/аутентификацию, проверку структуры запроса, формирование запроса к модулю «Управление пользователями», получение результата проверок пользовательского запроса и возврат результата авторизации/аутентификации в подсистему «Взаимодействие» модуль «API», сохранения результата в системный лог, через обращение к модулю «Аудит» и сохранения клиентского токена в свою базу данных, где он будет использоваться во время проверки другими модулями системы. Модуль «Авторизации/аутентификации» так же отвечает за выдачу информации о клиентском токене (принадлежность к пользователю, срок действия) другим модулям системы.

Модуль «Аудит» предоставляет сервисы для записи сообщений в системный лог и выборки системного лога из базы данных на чтение. В системный лог нельзя вносить изменения либо удалять из него записи, поэтому операции редактирования и удаления модулем не поддерживаются. Модуль «Аудит» получив в качестве входящего сообщения сведения для записи в системный лог, форматирует их в соответствии с правилами заполнения системного лога и осуществляет запись и возвращает в качестве подтверждения об успешно выполненной операции сохранения идентификатор записи в системном логе, который используется другими модулями для ссылки на сохраненные в системном логе события и квитанции.

Так же в ответ на обращение на соответствующий метод выборки системного лога, с параметрами или без (например, фильтрами задающими диапазон выборки, уникальную. запись по ее идентификатору или компонент, логи которого необходимы), модуль «Аудит» возвращает записи системного лога соответствующие сделанному запросу.

После успешного прохождения авторизации/аутентификации, пользователь системы может отправить в нее документ.

Отправка документа начинается с его передачи клиентским приложением в модуль «API» подсистемы «Взаимодействие». Все методы модуля «API», кроме авторизации/аутентификации, требуют в качестве обязательного параметра клиентский токен, полученный клиентским решением после успешного прохождения авторизации/аутентификации.

Модуль «API» получив документ, осуществляет форматно-логический контроль, для чего он использует правила проверки, входящие в логику его работы и являющиеся имплементацией протокола взаимодействия с клиентскими системами (правила - это описание набора полей документа, типы полей, логическая связь между полями, например если заполнено поле А, должно быть заполнено поле С). В случае успешного прохождения проверки, которая осуществляется синхронно (т.е соединение с клиентом не разрывается, удерживается на время выполнения проверки), модуль «API» присваивает документу уникальный идентификатор и возвращает его клиентской системе, сохраняет полученный документ в базу данных, вносит в системный лог квитанцию об успешной приемке документа, через обращение к модулю «Аудит».

Так же модуль «API» в ответ на запросы клиентских приложений предоставляет следующий, типовой, но не конечный, набор операций:

1. Проверка статуса заказа на эмиссию кодов маркировки;

2. Выборка кодов маркировки из заказа;

3. Получение/прием отчета об использовании кода маркировки;

4. Получение/прием отчета об аннуляции кода маркировки;

5. Получение/прием отчета об агрегации кода маркировки;

6. Получение состава документа (списка кодов идентификации либо кодов маркировки) по идентификатору документа;

7. Выгрузка входящих документов для клиента системы;

8. и другие.

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

Модуль «API», сохранив документ в базу, передает ссылку на него модулю «Документооборота», который в свою очередь осуществляет его выборку из базы данных, определяет тип документа и далее в соответствии с правилами обработки документа данного типа модуль «Документооборота» осуществляет его маршрутизацию. Так как каждый документ являются частью жизненного цикла кода маркировки, т.е влияет на его статус в системе, модуль «Документооборот» передает сообщение о событии жизненного цикла кодов маркировки, входящих в состав документа в модуль «Реестр кодов идентификации». Далее модуль «Документооборота» определяет получателя документа, если это другой участник системы, то документ сохраняется в базу данных документов системы с указанием получателя, если документ необходимо передать в информационную систему Оператора маркировки, модуль «Документооборота» вызывает модуль «Взаимодействия с информационными системами Операторов маркировки» и передает ему документ на отправку. Далее модуль документооборота осуществляет индексацию документа, т.е формирование метадаты документа в соответствии с заданными правилами для данного типа документа и ее запись в специализированную поисковую базу данных. Индексация существенно ускоряет поиск и выборку документов в больших хранилищах, так же облегчает учет документов, проходящих через систему. Все компоненты системы при поиске документов по заданным критериям обращаются на сервисы модуля «Документооборота», работающие с индексами. Непосредственно в хранилище документов, в базе данных, у документов есть только один индекс - их идентификатор, по которому и осуществляется выборка документов из хранилища.

Далее модуль «Документооборота» создает квитанции об успешной индексации и успешной маршрутизации документа получателю и передает их модулю «Аудит» для сохранения в лог системы.

Далее модуль «Документооборот» осуществляет запись в истории документа, со ссылкой на квитанцию (ее идентификатор в логе системы)

Модуль «Документооборота» предоставляет пользовательскому интерфейсу, а также другим модулям системы интерфейсы для работы с документами и индексатором документов: сохранение, редактирование, удаление, поиск по заданным параметрам в индексе документов и методы записи в историю документов, используемые в жизненном цикле другими модулями системы.

Если получателем документа является участник системы, на этом его жизненный цикл завершается, документ ожидает обращение получателя к модулю «API» для выгрузки входящих документов, либо обращения через пользовательский интерфейс личного кабинета.

Если получателем документа является информационная система Оператора маркировки, то дальнейшая его обработка переходит в модуль «Взаимодействия с информационными системами Операторов маркировки».

Модуль «Взаимодействия с информационными системами Операторов маркировки» отвечает за преобразование исходного документа системы в формат данных, поддерживаемый конкретным Оператором маркировки и отправку документа в информационную систему Оператора маркировки. Модуль «Взаимодействия с информационными системами Операторов маркировки» формирует квитанцию об успешной отправке документа в информационную систему Оператора и передает ее модулю «Аудит» для сохранения в логе системы.

Далее модуль «Взаимодействия с информационными системами Операторов маркировки» через обращение к сервисам Оператора маркировки осуществляет проверку статуса обработки документа и получив соответствующие квитанции передает их модулю «Аудит» для сохранения в логе системы и модулю «Документооборот» для сохранения в истории документа.

Если отправленный в информационную систему Оператора маркировки документ, предполагает выполнение информационной системой Оператора неких действий, результатом которых будет новый документ, например выполненный заказ на эмиссию кодов маркировки, модуль «Взаимодействия с информационными системами Операторов маркировки», выгружает данный документ из информационной системы оператора, вносит запись об успешном выполнении Оператором маркировки задачи по обработке документа в историю исходного документа-запроса (например заказа на эмиссию кодов маркировки), через обращение на соответствующий сервис модуля «Документооборота» предназначенный для внесения записей в историю документа.

Полученный от Оператора маркировки документ, передается модулю «Документооборота» для маршрутизации в соответствии с правилами, заданными для данного типа документа.

Некоторые, но не все, типовые процессы работы с документами в системе представлены в иллюстративных целях на фиг. 4, 5, 6.

Модуль «Реестр кодов идентификации» представляет собой базу данных кодов идентификации и событий их жизненного цикла.

Код идентификации представляет собой код маркировки, без крипто части, т.е. без защиты, которую применяют в ряде стран, где внедряется маркировка товаров и хранить которую запрещают НПА данных стран. Код идентификации представляет собой уникальный идентификатор товара, состоящий из идентификатора товарной номенклатуры (в основном используется GTIN, от GS1) и уникального серийного номера, присвоенного производителем или импортером (эмитентом кода маркировки)

События жизненного цикла порождаются документооборотом и приходят в реестр от модуля «Документооборота» в процессе маршрутизации документов. Примеры событий:

1. Эмиссия - порождается документом «заказ кодов маркировки», коды маркировки поступают в систему в составе выполненного заказа на эмиссию кодов маркировки из информационной системы Оператора маркировки.

2. Использование - порождается документами «валидация нанесения кода маркировки», «нанесение кода маркировки на готовую продукцию» и другими.

3. Аннуляция - порождается документами «отбраковка кода маркировки» либо «аннулирование кода маркировки по причине отказа от заказа на эмиссию кодов маркировки».

4. И другими документами, состав которых меняется в зависимости от страны и товарной группы.

Событие - это запись в истории кода маркировки, ссылающаяся на исходный документ (идентификатор документа) в хранилище документов и ссылающаяся на запись в реестре кодов идентификации (код идентификации). Событие имеет дату, время, тип (зависит от типа документа).

Так же реестр кодов идентификации содержит записи о нарушениях в жизненном цикле, правила определения нарушений варьируются, но в общем случае нарушением считается повторение одного и того же события от одного источника. Например, повторное нанесение кода маркировки на готовую продукцию является грубейшим нарушением.

Реестр предоставляет другим компонентам сервисы для записи данных в него, основным поставщиком данных в реестр является модуль «Документооборота», который передает в реестр списки кодов идентификации, наименование события и идентификатор документа, породившего данное событие.

Реестр предоставляет пользовательскому интерфейсу системы и другим модулям сервисы для получения записей из реестра, списка событий по коду идентификации, списка кодов идентификации по идентификатору документа и другие. Редактирование данных в реестре запрещено, удаление данных в реестре запрещено.

Реестр хранит информацию о сроке годности кодов маркировки, которую использует в своей работе модуль «Контроля правил оборота и использования кодов маркировки».

Записи в реестре подразделяются на активные и обработанные. Обработанные - это коды идентификации чей жизненный цикл уже завершен, например они были аннулированы либо нанесены на готовую продукцию. Далее система не отслеживает их жизненный цикл и с ними не работает модуль «Контроля правил оборота и использования кодов маркировки».

Модуль «Контроля правил оборота и использования кодов маркировки» использует в своей работе базу данных реестра кодов идентификации для контроля срока годности кодов маркировки. Модуль «Контроля правил оборота и использования кодов маркировки».

Отвечает за аннуляцию кодов маркировки внутри системы, через закрытие соответствующих заказов на эмиссию кодов маркировки, хранящих коды маркировки с истекшим сроком годности. Специальный процесс проверки срока годности модуля «Контроля правил оборота и использования кодов маркировки», запускаясь по расписанию, осуществляет сканирование активных записей реестра кодов идентификации сравнивает текущую дату с датой окончания срока годности. Если дата истекла, модуль передает модулю «Документооборота» команду за закрытие документа «заказ кодов маркировки» что содержит данный код в себе.

Так же модуль «Контроля правил оборота и использования кодов маркировки» отвечает за создание записей о нарушениях жизненного цикла кодов маркировки. Анализируя события жизненного цикла кода маркировки в реестре кодов идентификации, в соответствии с заданными правилами (которые отличаются для разных типов документов, товарных групп и стран) модуль «Контроля правил оборота и использования кодов маркировки» создает записи в таблицу нарушений реестра кодов идентификации и формирует соответствующие квитанции отправляя их в модуль «Аудит» идентификаторы записей в логе системы, присваиваются как атрибуты записям в таблице нарушений.

Модуль «Контроля правил оборота и использования кодов маркировки» не предоставляет сервисов другим компонентам системы или пользовательскому интерфейсу, он не имеет собственной базы данных и является набором служебных процессов, запускаемых по расписанию.

Подсистема «Личные кабинеты» предоставляет пользователям системы формы для просмотра, редактирования и внесения документов. Для каждого типа документов есть своя экранная форма, форма-представление «список», форма поиска, с возможностью задавать параметры параметры/условия поиска.

Так же подсистема «Личные кабинеты» предоставляет возможность редактировать профиль участника, профили пользователей, описание оказываемых участником услуг, данные о его местах осуществления деятельности и другую информацию.

В подсистеме «Личные кабинеты» находится форма поиска поставщиков услуг, по их описательной части, метадате, списку услуг и другим параметрам.

Ряд функций системы:

1. Регистрация участника системы.

2. Регистрация места осуществления деятельности.

3. Установление связей между участниками и/или местами осуществления деятельности.

4. Функции администрирования системы.

5. Функции биллинга.

6. Функции работы с документами.

7. Функции работы с реестром кодов идентификации.

Доступны только в подсистеме «Личные кабинеты» и в модуле «API» подсистемы «Взаимодействие» не реализуются.

Модуль «Биллинга» подсистемы «Финансы» отвечает за формирование счетов, на основании статистики работы пользователей. Статистикой является документооборот и счета выставляются, в большинстве своем, но не только, на основании прошедших через систему кодов маркировки, их количестве, по документам, где получателем является данный участник системы.

Модуль «Биллинга», обращаясь к сервисам модуля «Документооборот» с соответствующими запросами, получает списки документов, обращаясь к модулю «Реестр кодов идентификации» по идентификаторам документов в событиях жизненного цикла кода маркировки, получает количество кодов маркировки в документах и формирует счета-фактуры за оказанные системой услуги.

Так же модуль «Биллинга» использует при выставлении счетов информацию о подключенных услугах, доступных данному участнику сети. Услуги оплачиваются на ежемесячной основе. Список услуг модуль «Биллинга» получает через обращение на методы сервиса модуля «Каталог участников сети».

Модуль «Расчета рейтинга участника сети» предназначен для хранения информации о текущем рейтинге участника сети и его мест осуществления деятельности. Местом оказания услуги, сервиса, считается место осуществления деятельности участника сети. Мест осуществления деятельности у участника сети может быть более одного. Участники устанавливают связи внутри системы, друг с другом и между местами осуществления деятельности, используя функционал модуля «Реестр связей между участниками системы». После установления связи, у участника системы появляется возможность в подсистеме «Личные кабинеты» выставить рейтинг, оценку другому участнику, либо его месту осуществления деятельности. Рейтинг представляет собой число от 0 до 4. Общий рейтинг участника или его места осуществления деятельности рассчитывается системой как среднее значение.

Модуль «Расчета рейтинга участника сети» предоставляет подсистеме личные кабинеты и другим модулям системы методы для записи значения рейтинга и выборки текущего рейтинга участника и/или его места осуществления деятельности. Так же сервис для выборки общего списка участников системы и их мест осуществления деятельности с указанием текущего рейтинга.

События изменения рейтинга оформляются квитанциями, которые модуль «Расчета рейтинга участника сети» отправляет на соответствующий сервис модуля «Аудит».

Схема функционального взаимодействия компонентов системы и внешних систем представлена на Фиг. 3.

Так, согласно Фиг. 3, модуль API связан с модулем документооборота, модулем авторизации/аутентификации, модулем аудита; модуль документооборота также связан со связанными между собой модулем биллинга и модулем реестра кодов идентификации, а также с модулем аудита; модуль аудита также связан с модулем контроля правил оборота и использования кодов маркировки, который связан с модулем реестра кодов маркировки, а также модуль аудита связан с модулем авторизации/аутентификации; модуль авторизации/аутентификации также связан с модулем управления пользователями, который связан с модулем каталога участников системы, который, в свою очередь, связан со связанными между собой модулем расчета рейтинга участников сети и модулем реестра связей между участниками системы; причем один из серверов системы выполнен с возможностью выполнять функцию центрального сервера. Указанные связи могут быть обеспечены, например, путем информационного обмена сигналами по линиям связи либо посредством программных интерфейсов.

Следует отметить, что в рамках данной заявки понятие «сервер» не ограничивается выполнением в виде какого-либо выделенного вычислительного устройства. Данное понятие следует трактовать в широком смысле, так как оно может включать также объединение нескольких или кластер серверов, одну или несколько взаимодействующих виртуальных машин и тому подобное.

Типовые бизнес-процессы системы представлены на схемах, приведенных на фиг. 4, 5, 6.

В процессах, приведенных на соответствующих схемах, указаны сторонние приложения:

1. Клиентское приложение.

2. Клиент автоподписи.

Данные приложения являются сторонними и стандартными для процессов маркировки в странах, где внедрена обязательная маркировка товаров. В иллюстративных целях и для удобства понимания они обозначены на схемах, так как играют роль в описываемом бизнес-процессе, но не являясь частью решения, описанного в данной заявке.

На фиг. 4 приведен примерный алгоритм взаимодействия частей системы при отправке заявки на эмиссию кодов маркировки по инициативе поставщика услуг.

Указанный алгоритм заключается в следующем.

Поставщик услуг выбирает участника оборота товаров, с которым у него установлена связь [1].

Поставщик услуг определяет способ формирования индивидуальных серийных номеров, самостоятельно или национальным Оператором маркировки. Если поставщик услуг формирует индивидуальный серийный номер самостоятельно, то для подачи заявки на эмиссию кодов маркировки необходимо сформировать индивидуальные серийные номера по каждому коду товара в необходимом количестве [2].

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

Клиентское приложение получает заявку на эмиссию кодов маркировки [4] и отправляет заявку на эмиссию кодов маркировки в Сервер системы [5].

Сервер системы получает заявку на эмиссию кодов маркировки и выполняет проверку заявки, включая проверку данных поставщика услуг, участника оборота товаров и наличия связи между ними [6].

Если проверка данных заявки на эмиссию кодов маркировки проходит неуспешно, то Сервер системы отправляет в Клиентское приложение сообщение со сведениями о возникших ошибках [7] [8] и процесс завершается.

Если проверка проходит успешно, то Сервер системы отправляет заявку на эмиссию кодов маркировки Клиенту автоподписи [9].

Участник оборота товаров посредством Клиента автоподписи рассматривает заявку на эмиссию кодов маркировки и в случае, если участник оборота товаров согласовывает заявку, то Клиент автоподписи выполняет подписание заявки на эмиссию кодов маркировки ЭЦП участника оборота товаров [10]. В случае, если участник оборота товаров отклоняет заявку, то она отклоняется.

После рассмотрения заявки на эмиссию кодов маркировки Клиент автоподписи отправляет в Сервер системы результат рассмотрения заявки на эмиссию кодов маркировки [11].

Сервер системы при получении результата обработки заявки на эмиссию кодов маркировки проводит проверку, и если заявка на эмиссию кодов маркировки была отклонена участником оборота товаров, то Сервер системы отклоняет заявку [12]. Процесс завершается.

Если заявка на эмиссию кодов маркировки была согласована участником оборота товаров, то Сервер системы отправляет заявку в Информационную систему национального Оператора маркировки [13].

Информационная система национального Оператора маркировки получает заявку на эмиссию кодов маркировки и производит ее обработку [14]. Процесс завершается.

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

На фиг. 5 приведен примерный алгоритм получения КМ.

Указанный алгоритм заключается в следующем.

Сервер системы дистрибуции формирует запрос на получение эмитированных кодов маркировки для поставщика услуг [1] и отправляет его в Информационную систему национального Оператора маркировки [2].

Информационная система национального Оператора маркировки получает запрос [3] и осуществляет проверку наличия эмитированных кодов маркировки для поставщика услуг [4].

Если найдены эмитированные коды маркировки для поставщика услуг, то Информационная система национального Оператора маркировки формирует пакет документов для поставщика услуг [5].

Информационная система национального Оператора маркировки формирует и отправляет результат обработки запроса на получение эмитированных кодов маркировки для поставщика услуг в Сервер системы [6].

Сервер системы получает результат обработки запроса на получение эмитированных кодов маркировки для поставщика услуг [7], и если не были получены эмитированные коды маркировки для поставщика услуг, то процесс завершается.

Если получены эмитированные коды маркировки для поставщика услуг, то Сервер системы отправляет эмитированные коды маркировки в Клиентское приложение для передачи на площадку поставщика услуг [8].

Клиентское приложение получает эмитированные коды маркировки [9]. Процесс завершается.

На фиг. 6 приведен примерный алгоритм печати кодов маркировки. Указанный алгоритм заключается в следующем.

Поставщик услуг выбирает устройство печати и отправляет в Клиентское приложение запрос, содержащий параметры создания задания на печать кодов маркировки [1]. Параметры запроса включают в себя идентификатор заявки, код товара (GTIN), идентификатор устройства печати, идентификатор шаблона этикетки.

Клиентское приложение получает запрос создания задания на печать кодов маркировки [2], формирует задание на печать кодов маркировки [3] и отправляет поставщику услуг результат формирования задания на печать кодов маркировки [4].

Поставщик услуг получает результат формирования задания на печать кодов маркировки, который содержит результат выполнения операции, идентификатор задания для печати, перечень кодов маркировки [5].

Вместе с тем Клиентское приложение отправляет на Устройство печати (принтер), указанное в запросе, задание на печать кодов маркировки [6]. Устройство печати (принтер) получает задание на печать кодов маркировки [7] и выполняет задание на печать кодов маркировки [8]. Верификатор выполняет верификацию нанесенных средств идентификации с применением камер технического зрения [9].

Клиентское приложение формирует отчеты о нанесении кодов маркировки и агрегации кодов идентификации [10].

Клиентское приложение отправляет в Информационную систему национального Оператора маркировки отчеты о нанесении кодов маркировки и агрегации кодов идентификации [11].

Информационная система национального Оператора маркировки получает отчеты о нанесении кодов маркировки и агрегации кодов идентификации [12], производит обработку полученных отчетов [13]. Процесс завершается.

Таким образом исключается риск искажения кода маркировки и производится верификация средства идентификации.

Передаваемые отчеты изменяют статус кода маркировки в информационных системах национальных Операторов маркировки и внутри системы. Реестры кодов маркировки хранятся в информационных системах национальных Операторов кодов маркировки. Код маркировки имеет статусную модель, соответствующую его жизненному циклу. Код маркировки создается (эмитируется) информационной системой национального Оператора маркировки. На различных этапах жизненного цикла КМ товарной единицы может находиться в различных состояниях (статусах), к основным из которых можно отнести такие, как: «Эмитирован» - данный статус кода означает, что маркировочный код был выдан участникам оборота для идентификации продукции; «В обороте» - данный статус кода означает, что промаркированная продукция попала в оборот; «Выбыл» - данный статус кода означает, что промаркированная продукция и, соответственно, код маркировки вышли из оборота.

Система, передавая сообщения в информационные системы национальных Операторов маркировки, изменяет тем самым статус кода маркировки в реестрах кодов маркировки этих систем. Все события, связанные с жизненным циклом кода маркировки внутри системы, квитируются (сопровождаются электронными квитанциями, защищенными ЭЦП системы). Основной сущностью, контролируемой системой, является код маркировки. Выше описаны процессы, связанные с его доставкой поставщикам услуг, которые осуществляют его преобразование в средство идентификации.

Система реализует процессы прослеживания перемещения и смены статуса кода маркировки, основанные на подаче сведений (документов), в процессах реального времени, что удобнее для интеграторов и позволяет реализовать бесшовное интегрирование в реальные бизнес-процессы интеграционные механизмы. На основе поступающих сведений система генерирует требуемую национальными Операторами маркировки первичную документацию и отправляет ее в нужном порядке в государственные информационные системы национальных Операторов маркировки. Таким образом, система обеспечивает автоматизацию бизнес-процессов, реализация которых отсутствует в государственных информационных системах и реализует прослойку между ними и ERP системами участников сети, обеспечивая правильную и своевременную подачу сведений в государственные информационные системы национальных Операторов маркировки.

Код маркировки преобразуется в средство идентификации поставщиком услуг. Далее средство идентификации наносится на готовую продукцию, подлежащую прослеживанию. Код маркировки выпускается государственными информационными системами национальных Операторов маркировки и в этот момент он имеет «хозяина», т.е. участника оборота продукции подлежащей обязательной маркировке, который заказал эмиссию данного кода маркировки у национального Оператора маркировки. Факт нанесения средства идентификации на готовую продукцию фиксируется специальным отчетом об использовании кода маркировки, формируемым клиентским приложением на основании данных, поступающих с технического зрения. Данный отчет отправляется через систему в информационную систему национального Оператора маркировки, этой операцией фиксируется факт нанесения кода маркировки. Так сведения, передаваемые системой в информационные системы национальных Операторов маркировки, напрямую влияют на историю кода маркировки и его жизненный цикл в них.

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

Ниже в таблице 1 представлена иллюстративная статусная модель жизненного цикла кода маркировки, которая может быть осуществлена внутри предложенной системы.

Изобретение относится к области распределенных систем обработки данных и может найти свое применение в качестве инструмента взаимодействия между участниками оборота товаров, в том числе международного и их контрагентов, таких как поставщики услуг преобразования кодов маркировки в средства идентификации и зарубежных производственных площадок. Технический результат заключается в обеспечении автоматизации гарантированной доставки кодов маркировки от участника оборота до поставщика услуги с целью исключения риска искажения кода маркировки и сопутствующего документооборота, включающего квитанции, подтверждающие получение сведений и кодов маркировки и отчеты об использовании кодов маркировки, а также контроль статуса кода маркировки. Система состоит из нескольких разнесенных территориально и связанных каналами связи сегментов (серверов) сети, каждый из которых выполнен на базе программно-аппаратного комплекса. 7 ил.

Система обмена кодами маркировки и сопутствующего документооборота, состоящая из нескольких разнесенных территориально и связанных каналами связи сегментов сети, каждый из которых выполнен на базе программно-аппаратного комплекса, содержащего сервер системы, включающего: подсистему личных кабинетов, выполненную с возможностью регистрации участников с разделением их по типам участников на, по меньшей мере: Типография, Логистический склад, Контрактная площадка, Участник оборота товаров, Иностранный производитель, Производитель ПО или оборудования, Таможенный брокер, Контент-провайдер, Транспорт, Консалтинг; подсистему безопасности, включающую модуль авторизации/аутентификации, модуль управления пользователями системы, реализующий функционал управления профилями участников системы и модуль аудита; подсистему каталогов, включающую модуль каталога участников системы, модуль реестра связей между участниками системы; подсистему обмена кодами маркировки, включающую модуль документооборота, модуль контроля правил оборота и использования кодов маркировки, реестр кодов идентификации; подсистему рейтинга участников сети, включающую модуль расчета рейтинга участника сети; подсистему финансов, включающую модуль биллинга; подсистему взаимодействия, включающую модуль API, предназначенный для подключения клиентских решений поставщиков услуг и информационных систем и/или других клиентских решений участников оборота продукции, подлежащей обязательной маркировке, программные интерфейсы для связи сегментов системы друг с другом и модуль взаимодействия с информационными системами Операторов маркировки; при этом подсистема взаимодействия настроена для работы с клиентской частью поставщика услуг или участника оборота, которая выполнена в виде «толстого» или «тонкого» клиентов; при этом модуль API связан с модулем документооборота, модулем авторизации/аутентификации, модулем аудита; модуль документооборота также связан со связанными между собой модулем биллинга и модулем реестра кодов идентификации, а также с модулем аудита; модуль аудита также связан с модулем контроля правил оборота и использования кодов маркировки, который связан с модулем реестра кодов маркировки, а также модуль аудита связан с модулем авторизации/аутентификации; модуль авторизации/аутентификации также связан с модулем управления пользователями, который связан с модулем каталога участников системы, который, в свою очередь, связан со связанными между собой модулем расчета рейтинга участников сети и модулем реестра связей между участниками системы; причем один из серверов системы выполнен с возможностью выполнять функцию центрального сервера.