ГОСТ Р 59168-2020 (ИСО/МЭК 19988:2017). Национальный стандарт Российской Федерации. Информационные технологии. Стандарт базовой деловой лексики

(утв. и введен в действие Приказом Росстандарта от 22.12.2020 № 1359-ст)

Утвержден и введен в действие Приказом Федерального

Information technology. Core business vocabulary standard

Предисловие

1 ПОДГОТОВЛЕН Ассоциацией автоматической идентификации «ЮНИСКАН/ГС1 РУС» при участии федерального государственного бюджетного образовательного учреждения высшего образования «Московский автомобильно-дорожный государственный технический университет (МАДИ)» на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 355 «Технологии автоматической идентификации и сбора данных» совместно с ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 декабря 2020 г. № 1359-ст

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Настоящее введение содержит следующие структурные элементы, приведенные в &[1]&:

• аннотацию к документу &[2]&,
• протокол изменений в &[2]&,
• отказ от ответственности.

Аннотация к документу &[2]&

Протокол изменений в [2]

Отказ от ответственности

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

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

НАСТОЯЩИЙ ДОКУМЕНТ ПРЕДОСТАВЛЯЕТСЯ "КАК ЕСТЬ" БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ, ПАТЕНТНОЙ ЧИСТОТЫ, ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ, ИЛИ КАКИХ-ЛИБО ИНЫХ ГАРАНТИЙ, ПРОИСТЕКАЮЩИХ ИЗ НАСТОЯЩЕГО ДОКУМЕНТА. GS1 снимает с себя всякую ответственность за любые убытки, проистекающие из использования или ненадлежащего использования настоящего стандарта, включая фактические, непрямые, косвенные и компенсаторные убытки, а также включая ответственность за нарушение каких-либо прав интеллектуальной собственности, связанное с использованием информации, содержащейся в настоящем документе, или основанное на использовании настоящего документа.

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

1 &Область применения& <1>

<1> Раздел 1 "Введение. Базовая деловая лексика" ИСО/МЭК 19988:2017 переименован в "Область применения".

Настоящий стандарт устанавливает базовую деловую лексику (БДЛ, англ. сокращение CBV от Core Business Vocabulary). Целью настоящего стандарта является описание различных лексических элементов и их значений для совместного использования с &ГОСТ Р 59167& <2>, который устанавливает механизмы обмена информацией, как в рамках одного предприятия, так и за его пределами. Идентификаторы и определения лексики в настоящем стандарте обеспечивают единое понимание всеми сторонами, обменивающимися данными по EPCIS с помощью базовой деловой лексики, семантического значения указанных данных.

<2> ГОСТ Р 59167-2020 (ИСО/МЭК 19987:2017) "Информационные технологии. Стандарт информационных сервисов EPC (EPCIS)" является модифицированным по отношению к [6]. В тексте ИСО/МЭК 19988:2017 вместо ссылки на [6] используется ссылка на [7], в то же время [6] соответствует [7].

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

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

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

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

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

• объектов;
• мест нахождения;
• бизнес-транзакций;
• идентификаторов начальных/конечных пунктов;
• идентификаторов преобразований;
• идентификаторов событий.

Настоящий стандарт предоставляет значения и атрибуты мастер-данных для описания физических мест нахождения, включая:

• место нахождения производственной территории;
• тип производственной площадки;
• характеристики производственной площадки;

- подробные сведения о производственной площадке.

Дополнительные подробные мастер-данные для мест нахождения (адресов и т.п.) не установлены настоящим стандартом.

2 Связь с архитектурой Системы GS1

Базовая деловая лексика (БДЛ) - это стандарт, сопутствующий EPCIS по &ГОСТ Р 59167&, который определяет технические интерфейсы для сбора и обмена данными о событиях, а также структурную модель данных для данных о событиях. Базовая деловая лексика - это стандарт данных GS1, дополняющий эту структуру путем определения конкретных значений данных, которые могут присутствовать в модели данных EPCIS. В таком качестве БДЛ существует в группе стандартов GS1 по обмену данными.

3 Связь с EPCIS

В настоящем разделе устанавливается, каким образом настоящий стандарт БДЛ связан с информационными сервисами EPC (EPCIS) по ГОСТ Р 59167.

3.1 Структура события EPCIS

&ГОСТ Р 59167, соответствующий [7]&, определяет элементы данных в событии EPCIS. Ниже приведены такие элементы данных и указано, где базовая деловая лексика предоставляет идентификаторы, которые могут быть использованы в качестве значений таких элементов данных:

• параметр "что" ("what"): Параметр "что" для большинства типов событий содержит один или несколько уникальных идентификаторов физических или цифровых объектов или классов физических или цифровых объектов. Идентификаторы физических или цифровых объектов в базовой деловой лексике определены в 8.2 (уровень экземпляра) и 8.3 (уровень класса). В случае события преобразования EPCIS (TransformationEvent) можно использовать необязательный идентификатор преобразования (TransformationID) для связи нескольких событий, описывающих одно и то же преобразование. Базовая деловая лексика включает в себя идентификаторы преобразования (TransformationID) (см. 8.7);
• параметр "когда" ("when"): Момент времени, когда произошло событие EPCIS. Время события полностью устанавливается в &ГОСТ Р 59167&;
• параметр "где/куда" ("where"): Параметр "где/куда" состоит из двух идентификаторов, описывающих разные аспекты места, где произошло событие: - место считывания (Read Point): место, где произошло событие EPCIS. В

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

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

или радиочастотной метки. Идентификаторы мест считывания, указанные в

базовой деловой лексике (БДЛ), приведены в 8.4 <1>;

        Пример  -  Устройство  считывания размещается у погрузочно-разгрузочных
    ворот  N  3  в  Лондонском распределительном центре. Продукция перемещается
    через  погрузочно-разгрузочные  ворота.  Место  считывания  (Read  point) =
    <Идентификатор,   соответствующий    погрузочно-разгрузочным  воротам  N  3

Лондонского распределительного центра>. - производственное место назначения (Business Location): место, где

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

приведены в 8.4 <1>;

Пример - данные о продукции считываются при ее прохождении через ворота, ведущие на торговый зал торгового предприятия № 123. В текущий момент времени продукция находится в торговом зале. Производственное место назначения (Business location) = <Идентификатор, соответствующий торговому залу торгового предприятия № 123>.

<1> В [1] ошибочно приведена ссылка на подраздел 8.3.

• параметр «на каком основании» (why): Параметр «на каком основании» состоит из двух идентификаторов и ряда идентификаторов документов бизнес-транзакций, в совокупности составляющих бизнес-контекст или показывающих, «на каком основании» произошло событие: - бизнес-этап (Business Step) обозначает конкретное действие

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

7.1;

Пример — событие EPCIS вызвано отправкой продукции из места нахождения,

идентифицированного посредством места считывания. Бизнес-этап (Business

Step) = <Идентификатор, обозначающий «отгрузку» («shipping»)>. - состояние (Disposition) обозначает состояние объекта. Поле состояния

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

состояния в базовой деловой лексике указаны в 7.2;

        Пример  -  создано  событие  EPCIS,  после  чего  продукция  может быть
    реализована  в  состоянии  "как  есть" и покупатели могут получить доступ к
    продукции   для  ее  покупки.  Состояние  (Disposition)  =  <Идентификатор,

обозначающий «пригодность для реализации и доступный»>.

• ссылки документы бизнес-транзакций (Business Transaction References): Событие EPCIS может относиться к одному или нескольким документам бизнес-транзакций. Каждая подобная ссылка состоит из двух идентификаторов: - тип документов бизнес-транзакции (Business Transaction Туре)

    обозначает  определенный  вид  бизнес-транзакции. Например - Идентификатор,
    обозначающий   "заказ   на   поставку".   Идентификаторы  типов  документов

бизнес-транзакций в базовой деловой лексике указаны в 7.3; - идентификатор документа бизнес-транзакции (Business Transaction

    Identifier)  обозначает конкретный документ бизнес-транзакции определенного
    типа,   который   указан  параметром  "тип  документов  бизнес-транзакции".
    Например  -  <Идентификатор, обозначающий заказ на поставку N 123456> некой
    корпорации.   Идентификаторы   документов  бизнес-транзакций,  указанные  в

базовой деловой лексике, приведены в 8.5.

• ссылки на начальный и конечный пункт (Source and Destination References): Событие EPCIS может относиться к одному или нескольким начальным и/или конечным пунктам, описывающим крайние точки перемещения в процессе хозяйственной деятельности, частью которой является указанное событие. Каждая ссылка на начальный или конечный пункт состоит из двух идентификаторов: - тип начального или конечного пункта (Source or Destination Туре)

    обозначает  определенный  вид  начального  или конечного пункта. Например -
    Идентификатор,   обозначающий  "сторону-собственник".  Идентификаторы  типа
    начального  и  конечного  пункта,  указанные  в  базовой  деловой  лексике,

приведены в 7.4; - идентификатор начального или конечного пункта (Source or Destination

    Identifier)  обозначает  начальный  или  конечный пункт определенного типа,
    который  указан  параметром  типа  документов бизнес-транзакции. Например -
    <Идентификатор,  обозначающий  некую  корпорацию как  сторону-собственник>.
    Идентификаторы  начального  и конечного пункта, указанные в базовой деловой

лексике, приведены в 8.6.

3.2 Виды лексики

(Материал данного подраздела взят непосредственно из &ГОСТ Р 59167-2020&, подраздел 6.2.)

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

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

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

• типовая лексика (Standard Vocabulary): типовая лексика представляет собой набор лексических элементов, определения и значения которых должны быть согласованы торговыми партнерами, которые будут обмениваться данными о событиях с использованием этой лексики;
• пользовательская лексика (User Vocabulary): пользовательская лексика представляет собой набор лексических элементов, определение и значение которых находятся под контролем одной организации.

Эти понятия подробнее объясняются далее.

3.2.1 Типовая лексика

Типовым лексиконом называют набор лексических элементов, определения и значения которых должны быть заранее согласованы торговыми партнерами, которые будут обмениваться данными о событиях с использованием лексикона. Например, в &ГОСТ Р 59167& определен лексикон под названием «бизнес-этап» (business step), элементами которого являются идентификаторы, обозначающие «отгрузку» (shipping), «получение» (receiving) и т.д. Один из торговых партнеров может создать событие с бизнес-этапом «отгрузка», а другой партнер, получив это событие посредством запроса, сможет интерпретировать его в силу предшествующего соглашения о смысловом значении лексического элемента «отгрузка».

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

Типовые лексиконы, указанные в БДЛ, включают: бизнес-этапы (business steps) (см. 7.1), состояния (dispositions) (см. 7.2), типы документов бизнес-транзакций (business transaction types) (см. 7.3) и типы начального и конечного пункта (source и destination types) (см. 7.4). Элементы и определения согласовываются сторонами до обмена данными, обеспечивая общее согласие относительно их смысловых значений.

Для примера далее приведен идентификатор бизнес-этапа, определенный в 7.1:

Пример - urn:epcglobal:cbv:bizstep:receiving.

Данный идентификатор определен стандартом базовой деловой лексики GS1, и его значение известно и принято всеми сторонами, внедряющими этот стандарт.

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

3.2.2 Пользовательская лексика

Пользовательским лексиконом называют набор элементов, определения и значения которых контролируются одной организацией. Например, в &ГОСТ Р 59167-2020& определен лексикон под названием «производственное место назначения» (business location), элементами которого являются идентификаторы, обозначающие такие объекты, как, например, «распределительный центр № 3 компании A». Идентификатор места нахождения и все связанные мастер-данные присваиваются пользователем. «Компания A» может создать событие, поле производственного места назначения которого будет включать идентификатор, обозначающий «распределительный центр № 3 компании A», а другой партнер, получая это событие посредством запроса, сможет интерпретировать его, распознав идентификатор как идентичный идентификатору, полученному по другим событиям, произошедшим в том же месте нахождения, или сверив атрибуты мастер-данных, связанные с данным идентификатором места нахождения, или с использованием обоих вышеперечисленных средств.

Пример - urn:epc:id:sgln:0614141.12345.400.

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

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

В то время как стандарт базовой деловой лексики не устанавливает (и не может, как следует из вышесказанного) конкретных лексических элементов пользовательской лексики, базовая деловая лексика обеспечивает синтаксические шаблоны, рекомендуемые для применения конечными пользователями при построении своих лексических элементов пользовательских лексиконов (см. 8.1). В настоящем стандарте представлены шаблоны для следующих пользовательских лексиконов: физические или цифровые объекты (physical or digital objects) (см. 8.2 и 8.3), места нахождения (locations), включая и места считывания (read points) и производственные места назначения (business locations) (см. 8.4), идентификаторы документов бизнес-транзакций (business transaction identifiers) (см. 8.5), идентификаторы начальных или конечных пункта (source/destination identifiers) (см. 8.6), и идентификаторы преобразования (transformation identifiers) (см. 8.7).

4 Терминология и условные обозначения

В рамках настоящего стандарта термины ДОЛЖЕН (SHALL), НЕ ДОЛЖЕН (SHALL NOT), СЛЕДУЕТ (рекомендуется) (SHOULD), НЕ СЛЕДУЕТ (не рекомендуется) (SHOULD NOT), МОЖЕТ (разрешается) (MAY), НЕ ОБЯЗАТЕЛЬНО ДОЛЖЕН (не требуется) (NEED NOT), МОЖЕТ (способен) (CAN) и НЕ МОЖЕТ (не способен) (CANNOT) будут интерпретироваться согласно &[8]&. В случае использования указанным выше образом любые данные термины будут всегда приведены в записи ПРОПИСНЫМИ БУКВАМИ; в случае записи строчными буквами их следует понимать в обычном значении слов.

Все разделы настоящего документа, за исключением разделов 2, 3 и 3, являются нормативными, кроме случаев, когда в тексте документа прямо указано иное.

В настоящем документе используются следующие соглашения о типографских обозначениях:

• записи ПРОПИСНЫМИ БУКВАМИ используются для специальных терминов, приведенных из вышеуказанного документа &[8]&;
• шрифт Courier используется для выделения идентификаторов на языке программирования, унифицированном языке моделирования (UML) и расширяемом языке разметки (XML), а также в тексте XML-документов <1>;
• места для внесения изменений, которые необходимо произвести в настоящем документе до достижения им завершающей стадии, соответствующей одобренному стандарту GS1, предваряются знаком в виде обращенной вправо стрелки, как указанной в начале настоящего абзаца.

<1> В настоящем стандарте данный шрифт используется также для перевода на русский язык содержания указанных идентификаторов.

5 Соответствие и совместимость

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

В связи с этим, настоящий стандарт определяет два уровня соответствия документов EPCIS:

• соответствующий БДЛ (CBV-Compliant): документ EPCIS, использующий только идентификаторы лексики, установленные в стандарте базовой деловой лексики в типовых полях событий EPCIS;
• совместимый с БДЛ (CBV-Compatible): документ EPCIS, использующий комбинацию идентификаторов лексики, установленных в стандарте базовой деловой лексики, и иных идентификаторов, выходящих за рамки стандарта.

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

Ниже приведено официальное определение данных терминов.

5.1 Документ, соответствующий БДЛ

«Документ, соответствующий БДЛ» (CBV-Compliant Document) является документом, который соответствует схеме и учитывает другие ограничения, указанные в &ГОСТ Р 59167 и [7]&, а также соответствует всем требованиям, приведенным в настоящем стандарте и относящимся к определению «Документ, соответствующий БДЛ».

«Приложением, соответствующим БДЛ» (CBV-Compliant Application), является любое приложение, для которого действительны оба из следующих условий:

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

В следующем перечне сведены требования к документу EPCIS, удовлетворяющему требованиям «Документа, соответствующего БДЛ», приведенным в других частях настоящего стандарта:

• документ, соответствующий БДЛ, ДОЛЖЕН удовлетворять требованиям схемы и другим ограничениям, указанным в &ГОСТ Р 59167&;
• документ, соответствующий БДЛ, НЕ ДОЛЖЕН использовать какой-либо универсальный идентификатор ресурсов URI, начинающийся с urn:epcglobal:cbv:, каким-либо образом, отличным от указанного в настоящем стандарте;
• любое событие EPCIS в документе, соответствующем БДЛ, ДОЛЖНО содержать поле bizStep (бизнес-этап), при этом значение поля bizStep (бизнес-этап) ДОЛЖНО быть универсальным идентификатором ресурсов (URI), состоящим из префикса urn:epcglobal:cbv:bizstep:, за которым следует строка, указанная в первом столбце соответствующей строки в таблице &1&, приведенной в 7.1.3;
• документ, соответствующий БДЛ, МОЖЕТ содержать поле disposition (состояние). Если поле disposition (состояние) присутствует, значение поля disposition (состояние) ДОЛЖНО быть идентификатором URI, состоящим из префикса urn:epcglobal:cbv:disp:, за которым следует строка, указанная в первом столбце соответствующей строки в таблице &2&, приведенной в 7.2.3;
• любое событие EPCIS в документе, соответствующем БДЛ, МОЖЕТ содержать один или несколько элементов bizTransaction (документ_Бизнес-транзакции). Если элементы bizTransaction (документ_Бизнес-транзакции) присутствуют, каждый такой элемент МОЖЕТ содержать атрибут type (тип). Если данный элемент bizTransaction (документ_Бизнес-транзакции) содержит атрибут type (тип), значением такого атрибута type (тип) ДОЛЖЕН быть универсальный идентификатор ресурсов (URI), состоящий из префикса urn:epcglobal:cbv:btt:, за которым следует строка, указанная в первом столбце соответствующей строки в таблице &4&, приведенной в 7.3.3;
• любое событие EPCIS в документе, соответствующем БДЛ, МОЖЕТ содержать один или несколько элементов source (начальный_пункт) или destination (конечный_пункт). Значением атрибута type (тип) каждого подобного элемента ДОЛЖЕН быть идентификатор URI, включающий префикс urn:epcglobal:cbv:sdt:, за которым следует строка, указанная в первом столбце соответствующей строки в таблице &5&, приведенной в 7.4.3;
• любое событие EPCIS в документе, соответствующем БДЛ, МОЖЕТ содержать элемент ErrorDeclaration (Заявление_об_Ошибке), и при наличии элемент ErrorDeclaration (Заявление_об_Ошибке) МОЖЕТ включать в себя поле reason (причина). При наличии в документе, соответствующем БДЛ, значение поля reason (причина) элемента ErrorDeclaration (Заявление_об_Ошибке) ДОЛЖНО быть идентификатором URI, состоящим из префикса urn:epcglobal:cbv:er:, за которым следует строка, указанная в первом столбце соответствующей строки таблицы &6&, приведенной 7.5.3;
• идентификаторы URI, определенные в стандарте данных радиочастотных меток EPC, ДОЛЖНЫ использоваться только в документе, соответствующем БДЛ, как указано в 8.1.1;
• документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из трех форм идентификатора URI, указанных в 8.2, для заполнения идентификаторов на уровне экземпляра по параметру «что» в событиях EPCIS (то есть полей epcList (список_EPC), parentID (идентификатор_Родителя), childEPC (epc_Потомка), inputEPCList (список_EPC_на_Входе), и outputEPCList (список_EPC_на_Выходе) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией), TransacationEvent (Событие_с_Документом_Транзакции) и TransformationEvent (Событие_с_Преобразованием)), для любого соответствующего поля, значение которого отлично от нуля. Документу, соответствующему БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI, как указано в 8.2.1, если нет веских причин поступить по-другому;
• документ, соответствующий БДЛ, НЕ ДОЛЖЕН использовать номер SGLN EPC <1> (urn:epc:id:sgln:...) в качестве идентификатора объекта;
• документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из трех форм идентификатора URI, указанных в 8.3, для заполнения идентификаторов на уровне класса по параметру «что» в событиях EPCIS (то есть полей epcClass (epc_на_уровне_Класса) во всех типах событий EPCIS) для каждого соответствующего поля, значение которого отлично от нуля. Документу, соответствующему БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI, как указано в 8.3.1, если нет веских причин поступить иначе;
• документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из четырех возможных форм идентификатора URI, приведенных в 8.4, для заполнения полей по параметру «где/куда» в событиях EPCIS (то есть полей readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS), для каждого соответствующего поля, значение которого отлично от нуля; документу, соответствующему БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI, как указано в 8.4.1, если нет веских причин поступить иначе;
• при использовании идентификатора EPC URI в качестве идентификатора места нахождения (см. 8.4.1), в документе, соответствующем БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC, отличные от схемы с номером SGLN (urn:epc:id:sgln:...), если нет веских причин поступить иначе;
• документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из четырех возможных форм идентификатора URI, приведенных в 8.5, для заполнения поля идентификатора документов бизнес-транзакции (то есть, текстового содержания элемента bizTransaction (документ_Бизнес-транзакции)) событий EPCIS, для каждого соответствующего поля, значение которого отлично от нуля;
• при использовании идентификатора EPC URI в качестве идентификатора документа бизнес-транзакции, документам, соответствующим БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC кроме схем с идентификатором GDTI EPC (urn:epc:id:gdti:...) или GSRN EPC (urn:epc:id:gsrn:...), если нет веских причин поступить иначе. Идентификаторы GDTI EPC СЛЕДУЕТ использовать в качестве идентификаторов документов бизнес-транзакций, только когда их присваивают для обозначения самих бизнес-транзакций, а не физических документов, не связанных с какой-либо бизнес-транзакцией;
• документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из трех форм идентификатора URI, указанных в 8.6 для заполнения поля идентификатора начального или конечного пункта (то есть, текстовое содержание элемента source (начальный_пункт) или destination (конечный_пункт)), для каждого подобного поля с ненулевым значением. Документу, соответствующему БДЛ, СЛЕДУЕТ использовать форму с идентификатором EPC URI, как указано в 8.6.1, если нет веских причин поступить иначе;
• при использовании идентификатора EPC URI в качестве идентификатора места нахождения (см. 8.6.1), документу, соответствующему БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC кроме схемы с номером SGLN (urn:epc:id:sgln:...), если нет веских причин поступить иначе;
• документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из четырех возможных форм идентификатора URI, приведенных в 8.7, для заполнения поля идентификатора документа транзакции (то есть текстового содержания элемента transformationID (идентификатор_Преобразования)) событий EPCIS TransformationEvents (События_с_Преобразованием), для каждого соответствующего поля, значение которого не равно нулю;
• при использовании идентификатора EPC URI в качестве идентификатора преобразования, документам, соответствующим БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC кроме схемы с идентификатором GDTI EPC (urn:epc:id:gdti:...), если нет веских причин поступить иначе. Идентификаторы GDTI EPC СЛЕДУЕТ использовать в качестве идентификаторов преобразования, только когда они были присвоены для обозначения преобразования, а не физического документа, не связанного с преобразованием;
• документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из форм идентификатора URI, приведенных в 8.8.1 для заполнения поля идентификатора события EPCIS (то есть текстового содержания элемента eventID (идентификатор_События)), значение которого не равно нулю.

<1> SGLN — структура данных GS1, соответствующая глобальному номеру места нахождения GLN, с включением или без опционального добавочного компонента, используемая для идентификации физического места нахождения.

5.2 Документ, совместимый с БДЛ

«Документ, совместимый с БДЛ (англ. „CBV-Compatible Document“) является документом, который соответствует схеме по &ГОСТ Р 59167&, и учитывает другие ограничения, приведенные в этом документе, и который также соответствует нормативному языку настоящего стандарта, относящемуся к определению „документ, совместимый с БДЛ“.»

«Приложение, совместимое с БДЛ» является любым приложением, для которого действительно выполнение следующих двух условий:

• приложение функционирует в режиме, в котором оно, как заявляется, принимает документ, совместимый с БДЛ, в качестве ввода информации; приложение ДОЛЖНО принимать любой документ, совместимый с БДЛ, согласно настоящему стандарту, и, при обработке такого документа, ДОЛЖНО интерпретировать любой идентификатор БДЛ согласно значению, установленному в настоящем документе;
• если приложение работает в режиме, в котором оно, как заявляется, создает документ, совместимый с БДЛ, результатом приложения ДОЛЖЕН быть только документ, совместимый с БДЛ, согласно настоящему стандарту, и кроме того, при создании такого документа ДОЛЖНЫ быть использованы только идентификаторы БДЛ для указания их значений, приведенных в настоящем документе.

В следующем перечне сведены требования к документу EPCIS, удовлетворяющему требованиям «документа, совместимого с БДЛ», приведенным в других частях настоящего стандарта:

• документ, совместимый с БДЛ, ДОЛЖЕН удовлетворять требованиям схемы и другим ограничениям, указанным в &ГОСТ Р 59167&;
• документ, совместимый с БДЛ, НЕ ДОЛЖЕН использовать какой-либо идентификатор URI, начинающийся с urn:epcglobal:cbv:, каким-либо образом, отличным от указанного в настоящем стандарте;
• идентификаторы URI, определенные в стандарте данных радиочастотных меток EPC, ДОЛЖНЫ использоваться только в документе, совместимом с БДЛ, как указано в 8.1.1;
• документу, совместимому с БДЛ, СЛЕДУЕТ использовать форму EPC URI, как указано в 8.2.1 для каждого идентификатора объекта на уровне экземпляра, если нет веских причин поступить иначе;
• документу, совместимому с БДЛ, СЛЕДУЕТ использовать форму EPC URI, как указано в 8.3.1 для каждого идентификатора объекта на уровне класса, если нет веских причин поступить иначе;
• документ, совместимый с БДЛ, НЕ ДОЛЖЕН использовать схему с номером SGLN EPC (urn:epc:id:sgln:...) в качестве идентификатора объекта;
• документу, совместимому с БДЛ, СЛЕДУЕТ использовать форму EPC URI, как указано в 8.4.1, для каждого идентификатора места нахождения, если нет веских причин поступить иначе;
• при использовании EPC URI в качестве идентификатора места нахождения (см. 8.4.1), документу, совместимому с БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC кроме схемы с номером SGLN (urn:epc:id:sgln:...), если нет веских причин поступить иначе;
• при использовании EPC URI в качестве идентификатора документа бизнес-транзакции, документам, совместимым с БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC кроме схемы с идентификатором GDTI EPC (urn:epc:id:gdti:...) или GSRN EPC (urn:epc:id:gsrn:...), если нет веских причин поступить иначе. Идентификаторы GDTI EPC СЛЕДУЕТ использовать в качестве идентификаторов документов бизнес-транзакций, только когда их присваивают для обозначения самих бизнес-транзакций, а не физических документов, не связанных с какой-либо бизнес-транзакцией;
• при использовании идентификатора EPC URI в качестве идентификатора начального или конечного пункта (см. 8.6.1), документу, совместимому с БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC кроме схемы с номером SGLN (urn:epc:id:sgln:...), если нет веских причин поступить иначе;
• при использовании EPC URI в качестве идентификатора преобразования, документам, совместимым с БДЛ, НЕ СЛЕДУЕТ использовать какие-либо схемы EPC кроме схемы с идентификатором GDTI EPC (urn:epc:id:gdti:...), если нет веских причин поступить по-другому. Идентификаторы GDTI EPC СЛЕДУЕТ использовать в качестве идентификаторов преобразования, только когда они были присвоены для обозначения преобразования, а не физического документа, не связанного с преобразованием.

В общем случае, любой документ, соответствующий БДЛ, также является документом, совместимым с БДЛ, однако не каждый документ, совместимый с БДЛ, является документом, соответствующим БДЛ. Документ, совместимый с БДЛ, может включать в себя идентификатор, соответствующий &ГОСТ Р 59167&, который не будет допустимым для документов, соответствующих БДЛ, при условии, что он отвечает указанным выше требованиям. Документ, совместимый с БДЛ, может также включать событие, в котором опущено поле bizStep (бизнес-этап), тогда как это поле обязательно требуется в документах, соответствующих БДЛ.

6 Использование универсальных идентификаторов ресурса (URI)

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

6.1 Префикс идентификатора URI для типовых лексиконов в БДЛ

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

urn:epcglobal:cbv:qualifier:payload,

где qualifier (квалификатор) обозначает тип лексикона, к которому относится данный лексический элемент, а payload (информационное_наполнение) уникальным образом идентифицирует лексический элемент.

6.2 Ограничение использования префикса идентификатора URI

Стандарт базовой деловой лексики является единственным стандартом GS1, в котором определено значение идентификаторов URI, начинающихся с urn:epcglobal:cbv:.

Документ, соответствующий БДЛ, или документ, совместимый с БДЛ, НЕ ДОЛЖЕН использовать какой-либо идентификатор URI, начинающийся с urn:epcglobal:cbv:, каким-либо образом, отличным от указанного в настоящем стандарте.

Документы, и соответствующие БДЛ, и совместимые с БДЛ, МОГУТ содержать идентификаторы URI, которые не начинаются с urn:epcglobal:cbv:, при условии выполнения требований, указанных в настоящем стандарте. Они ДОЛЖНЫ использоваться для идентификации лексических элементов, значение которых не определено стандартом БДЛ. Идентификаторы URI, начинающиеся с urn:epcglobal:, НЕ ДОЛЖНЫ использоваться каким-либо образом, отличным от указанного в настоящем стандарте или другом стандарте GS1.

6.2.1 Пример ограничения использования префикса идентификатора URI (условный)

Предположим, пользователю требуется новое значение состояния для обозначения «на карантине». Пользователю НЕ разрешается использовать следующий идентификатор URI:

urn:epcglobal:cbv:disp:quarantined

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

http://epcis.example.com/disp/quarantined

7 Типовые лексиконы

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

7.1 Бизнес-этапы (Business steps)

В настоящем подразделе определяются типовые идентификаторы для лексикона EPCIS BusinessStepID (Идентификатор_Бизнес-Этапов). Такие идентификаторы записываются в поле bizStep (бизнес-этап) события EPCIS, как указано ниже.

7.1.1 Структура идентификатора URI

Все значения бизнес-этапов, установленные в настоящем подразделе, имеют следующий вид:

urn:epcglobal:cbv:bizstep:payload,

где (составляющая) payload (информационное_наполнение) — это строка знаков, указанная в следующем разделе. Каждая строка payload (информационное_наполнение), определенная в настоящем документе, содержит только строчные буквы и знак подчеркивания (underscore <1>).

<1> В ИСО/МЭК 19988 приведено нетиповое наименование знака «underline» — «подчеркивание».

7.1.2 Соответствующее использование

Любое событие EPCIS в документе, соответствующем БДЛ, ДОЛЖНО содержать поле bizStep (бизнес-этап), при этом значение поля bizStep (бизнес-этап) ДОЛЖНО быть идентификатором URI, состоящим из префикса urn:epcglobal:cbv:bizstep:, за которым следует строка, указанная в первом столбце соответствующей строки в таблице &1&, приведенной в 7.1.3. Часть, следующая за префиксом, ДОЛЖНА быть указана точно так, как приведено в указанной таблице &1&, только с использованием строчных букв (с возможным включением знаков подчеркивания, как показано).

Любое событие EPCIS в документе, совместимом с БДЛ, МОЖЕТ содержать поле bizStep (бизнес-этап), и значением поля bizStep (бизнес-этап) МОЖЕТ быть идентификатор URI, как указано выше для документа, соответствующего БДЛ, и МОЖЕТ быть любым другим идентификатором URI, отвечающим общим требованиям, установленным в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для иных целей.

7.1.2.1 Пример соответствующего и несоответствующего использования (условный)

Следующая выдержка из документа EPCIS, соответствующего БДЛ, в формате XML, содержит одиночное событие, в котором бизнес-этапом этого события является значение «отгрузка» (shipping) из базовой деловой лексики:

  <EPCISBody>
    <EventList>
      <ObjectEvent>
       ...
         <bizStep>urn:epcglobal:cbv:bizstep:shipping</bizStep>
       ...
      </ObjectEvent>
    </EventList>
  </EPCISBody>
</epcis:EPCISDocument>

Следующий пример является НЕ соответствующим БДЛ, поскольку в нем не используется полная строка идентификатора URI в поле бизнес-этапа. Он также не является совместимым с БДЛ, поскольку значение поля бизнес-этапа не содержит идентификатор URI с указанием полномочий собственника, как того требует &ГОСТ Р 59167-2020&, пункт 6.4.

<epcis:EPCISDocument xmlns:epc«s=»urn:epcglobal:epcis:xsd:1» ...> ... shipping НЕВЕРНО ... </epcis:EPCISDocument>

Дополнительные примеры приведены в 11.1.

7.1.3 Значения и определения элементов бизнес-этапов

&Таблица 1

Значения и их определения для элементов бизнес-этапов с примерами&

Значение (перевод)	Определение	Пример
accepting (приемка)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где меняется право владения и/или собственности на объект Предприятие розничной торговли X выгружает поддон на разгрузочную платформу получателя. Подсчитывается число ящиков на поддоне. Поддоны разгружаются из транспортного средства. Количество проверяется по документам на поставку [грузовой накладной (Freight Bill) или транспортной накладной (Bill of Lading)] с указанием любой недостачи, излишка или повреждений товара на момент поставки. Как правило, этот процесс предваряет осуществление оплаты фрахта и завершает договорные обязательства с грузоперевозчиком на поставку продукции/ имущества в установленное место нахождения.	Грузоперевозчик выгружает пять коробок в распределительный центр Y. Работник разгрузочной платформы подписывает подтверждение получения пяти коробок от грузоперевозчика.	Оптовый продавец получает партию рыбы на рыбном аукционе, проверяет количество и подтверждает получение. Водитель вилочного погрузчика предприятия-изготовителя сканирует идентификационные номера комплектующих изделий, которые были выведены с консигнационного склада. В ходе этого процесса комплектующие изделия добавляют в на баланс предприятия-изготовителя arriving (прибытие)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект прибывает в некоторое место нахождения Машина с грузом прибывает на складскую площадку. Груз еще не был получен или принят	assembling	(комплектование)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где один или несколько объектов собираются вместе, создавая новую законченную продукцию. В отличие от преобразования, в результате выполнения бизнес-этапа assembling (комплектование) исходные объекты остаются распознаваемыми и/или процесс обратим; в связи с этим бизнес-этап assembling (комплектование) будет использоваться в событии агрегирования, а не преобразования	Комплектующие части компьютера (жесткие диск, блок питания, RAM) собираются в готовый для использования компьютер. Комплектование в здравоохранении: хирургический комплект, включающий медицинский препарат, шприц и марлю, собираются вместе, создавая новую «продукцию» — комплект	collecting (сбор)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект забирается для будущей утилизации, переработки или повторного использования Организация забирает ненужные потребителям электронные устройства в конце жизненного цикла у различных организаций. После того, как изделия получены, они, как правило, привозятся обратно и принимаются центром сбора.	Взятые в аренду или в наем поддоны забираются и привозятся в центр сбора	commissioning (присвоение_идентификатора)
Процесс привязывания идентификатора на уровне экземпляра (такого как номер EPC) к определенному объекту, или процесс привязывания ранее не использованного идентификатора на уровне класса к одному или нескольким объектам. Радиочастотная метка может кодироваться и наноситься на этом этапе или кодироваться предварительно. В случае идентификатора на уровне класса этап commissioning (присвоение_идентификатора) отличается от этапа creating_class_instance (создание_экземпляра_на_уровне_класса) тем, что этап commissioning (присвоение_идентификатора) всегда указывает на первый случай использования идентификатора на уровне класса, тогда как этап creating_class_instance (создание_экземпляра_на_уровне_класса) не указывает, использовался ли идентификатор на уровне класса ранее	На упаковочной линии закодированная радиочастотная метка EPC наносится на ящик, и кодированное значение привязывается к продукции. Отдельному виртуальному документу (например, цифровому купону, цифровому ваучеру и т.п.) присваивается номер EPC.	Изготавливается сто флаконов определенной партии фармацевтической продукции, которые являются первыми изготовленными флаконами партии. Полутуши говядины делятся и фасуются как отдельно упакованные стейки. Это может быть событием TransformationEvent (Событие_с_Преобразованием) по &ГОСТ Р 59167&, если исходные полутуши также отслеживаются consigning (передача_на_консигнацию)
Указывает на общий процесс, включающий бизнес-этапы staging_outbound (подготовка_к_отправке), loading (погрузка), departing (отправка) и accepting (приемка), который может использоваться, когда более детальная информация о этапах процесса неизвестна или недоступна. Использование бизнес-этапа consigning (передача_на_консигнацию) взаимоисключает использование бизнес-этапов staging_outbound (подготовка к отправке), loading (погрузка), departing (отправка) и accepting (приемка).	Примечание — Данный бизнес-этап схож с этапом shipping (отгрузка), но включает смену права владения и/или собственности со стороны отправителя. Оптовый продавец приходит на рыболовное судно, выбирает и закупает ящики с рыбой и привозит их на территорию своего предприятия. Изготовитель выбирает на консигнационном складе комплектующие изделия для использования на сборочной линии. В логический момент выхода со склада право собственности на комплектующие изделия переходит к изготовителю.	Изготовитель подготавливает продукцию для погрузки, загружает ее в контейнер, контейнер запечатывают и отправляют. В ходе данного процесса право собственности переходит к получателю. Если этот процесс является одноэтапным, тогда он обозначается как бизнес-этап consigning (передача на консигнацию) creating_class_instance (создание_экземпляра_на_уровне_класса)
Обозначает этап в бизнес-процессе, на котором формируется идентифицируемый на уровне класса экземпляр предмета или возрастает его количество. В отличие от бизнес-этапа commissioning (присвоение_идентификатора), этот бизнес-этап может быть выполнен повторно для того же идентификатора на уровне класса	Вода, сахар и другие ингредиенты объединяются для производства одной партии газированного напитка за одну смену на одной производственной линии. Это может быть событие TransformationEvent (Событие_с_Преобразованием) по &ГОСТ Р 59167&, если исходные ингредиенты отслеживаются. Картофель сортируется по размеру и качеству, моется и пакуется в ящики одной партии на одной упаковочной линии в один день	cycle_counting (подсчет)
Процесс подсчета объектов в рамках места нахождения с целью получения точной инвентарной информации, скорее для потребностей хозяйственной деятельности, чем в целях бухгалтерского учета (например, пополнения запасов или размещения) Предварительно выбранное подмножество объектов (например, вся продукция, принадлежащая определенному владельцу товарного знака или относящаяся к определенному классу объектов) в пределах предприятия розничной торговли подсчитываются портативным устройством считывания.	Все объекты в определенном месте нахождения производственной площадки (торговом зале или на полке в торговом зале) подсчитываются с помощью портативного устройства считывания	decommissioning (снятие_присвоенного_идентификатора)
Процесс устранения связи между идентификатором на уровне экземпляра (таким как номер EPC) и объектом. В будущем объекту может быть вновь присвоен идентификатор, но это должен быть новый идентификатор на уровне экземпляра Электронная пломба на многооборотном контейнере вскрывается, когда контейнер открывается, таким образом, контейнер не может в дальнейшем быть идентифицирован с помощью идентификатора на уровне экземпляра, который содержался в электронной пломбе.	Цифровой купон или ваучер на возмещение за возврат тары активируется в контрольно-кассовом узле предприятия розничной торговли	departing (отправка)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект покидает место нахождения на пути к пункту назначения Машина с грузом отбывает со складской площадки, как правило, через ворота и начинает перевозку к другому месту нахождения	destroying	(утилизация)
Процесс уничтожения объекта. Для идентификатора на уровне экземпляра объект не должен быть предметом последующих событий; наличие последующих событий, вероятнее всего, будет указывать на ошибку (такую как побочное считывание радиочастотной метки внутри мусоросжигательной печи). Для идентификатора на уровне класса сокращается количество, однако, идентификатор на уровне класса может по-прежнему использоваться в последующих событиях (указывая на различные экземпляры, которые не были уничтожены) Распределительный центр или предприятие розничной торговли помещает пустой ящик в мусоросжигательную печь или установку для измельчения	disassembling	(разукомплектование)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект разбивается на отдельные, уникальным образом идентифицированные детали Прежде, чем передать предмет потребительской электроники (компьютер) в конце его жизненного цикла на повторную переработку, важно разобрать его на части для повторной переработки или утилизации экологически безопасным способом.	Хирургический комплект (например, от 2 до 50 флаконов медицинского препарата и один шприц с марлей) разбивается на отдельные компоненты	dispensing (предоставление_потребителю)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где продукция в полном объеме или частично предоставляется потребителю Провизор выдает потребителю или пациенту лекарственный препарат в соответствии с рецептом врача.	Работник отдела кулинарии нарезает упаковку индейки, весом пять килограммов, для реализации по частям	encoding (кодирование)
Процесс записи идентификатора на уровне экземпляра (как правило, номера EPC) в символ штрихового кода или радиочастотную метку, где идентификатор еще не привязан к объекту на этом этапе процесса Третья сторона осуществляет запись на носители данных и возвращает катушку с носителями данных для коробок изготовителю	entering_exiting	(выход_вход_с_продукцией)
Обозначает определенный вид деятельности на входной/выходной двери помещения, где покупатели либо выходят с приобретенной продукцией, либо входят с продукцией, подлежащей возврату в это помещение Покупатель выходит с предприятия розничной торговли X с приобретенными товарами через дверь для входа/выхода покупателей	holding	(задержание_для_проверки)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект изолируется для дальнейшей проверки Предприятие розничной торговли X выгружает на свой склад второй поддон и, не найдя заказа на поставку для этого поддона, перемещает поддон на участок временного хранения на складе.	Распределительный центр Y приобретает партию фармацевтической продукции. Распределительный центр Y выясняет, что его поставщик не может предоставить все данные о ее происхождении. Распределительный центр Y перемещает партию продукции в зону карантина на своем складе.	Грузоотправителю Z на таможне приказывают переместить контейнер в специальную зону до тех пор, пока таможенная служба не проведет осмотр и таможенное оформление контейнера inspecting (проверка)
Процесс осмотра объектов на предмет потенциальных физических дефектов или ошибок в документации Производитель A выбирает 10 флаконов из каждой партии, чтобы убедиться в том, что продукция и число таблеток во флаконах соответствуют предписанному.	Распределительный центр Y проверяет все возвращенные изделия, чтобы пометить их, либо как пригодные для реализации, либо как испорченные.	Надзорный орган R выбирает с полки 3 флакона для проверки их надлежащего происхождения. Сотрудник таможенной службы C с помощью сканера проверяет содержимое транспортного контейнера. Оператор парка поддонов Z проверяет, соответствуют ли определенные поддоны критериям качества installing (установка)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект помещается в составной объект (не просто контейнер). На бизнес-этапе installing (установка) составной объект существует и до указанного этапа, тогда как на бизнес-этапе assembling (комплектование) составной объект создается во время этого этапа Дополнительные микросхемы памяти и аккумуляторная батарея устанавливаются в компьютер.	Модуль двусторонней печати устанавливается на лазерный принтер.	Дополнительные средства обеспечения безопасности устанавливаются в салон самолета или дорожно-транспортного средства (например, огнетушители) killing (ликвидация_радиочастотной_метки)
Процесс ликвидации радиочастотной метки, ранее связанной с объектом. Объект и его идентификатор на уровне экземпляра может продолжать существовать и являться предметом последующих событий (посредством считывания символа штрихового кода, ручного ввода данных, замены радиочастотной метки на другую и т.д.) Радиочастотной метке дается команда Kill на ее ликвидацию, чтобы предотвратить дальнейшее ее считывание или получение информации, содержащейся в радиочастотной метке	loading	(погрузка)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект загружается в транспортное средство Изготовитель A загружает поддоны в контейнер. Поддоны группируются в контейнере.	Распределительный центр Y загружает весь груз в грузовой автомобиль	other (прочее)
Бизнес-этап, не идентифицированный каким-либо образом в списке значений, приведенных в базовой деловой лексике Бизнес-этап other (прочее) может использоваться для условий, которые еще не были добавлены в базовую деловую лексику из отраслевого или пользовательского лексикона	packing	(упаковывание)
Обозначает определенный вид деятельности в рамках бизнес-процесса, который включает в себя размещение объектов в таре большего размера, как правило, для транспортирования. Объединение одного предмета с другими, как правило, происходит в этот момент 12 упаковок газированного напитка помещаются в ящик.	Развесной картофель помещается в транспортную тару	picking (отбор)
Обозначает определенный вид деятельности в рамках бизнес-процесса, который включает отбор объектов для выполнения заказа Распределительный центр Y помещает три единичных предмета в контейнер, чтобы выполнить требования заказа на поставку.	Производитель A извлекает три поддона со стеллажей, чтобы выполнить заказ на поставку	receiving (получение)
Обозначает определенный вид деятельности в рамках бизнес-процесса, который указывает, что происходит получение объекта в каком-либо месте нахождения и добавление его к товарно-материальным запасам получателя. Использование бизнес-этапа receiving (получение) взаимоисключает использование бизнес-этапов arriving (прибытие) и accepting (приемка) Предприятие розничной торговли X подтверждает, что число ящиков на поддоне соответствует указанному в заказе на поставку. Предприятие розничной торговли X принимает ящики в товарно-материальные запасы. Как правило, этот процесс выявляет соответствие продукции, поставленной по заказу, для осуществления платежа поставщику.	Поставка от производственной территории изготовителя до распределительного центра изготовителя сопоставляется с записями транзакции, а затем добавляется в местную товарно-материальную базу	removing (извлечение)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект извлекается из составного объекта Дефектная деталь самолета извлекается из двигателя	repackaging	(переупаковывание)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где конфигурация упаковки объекта изменяется Распределительный центр Y получает одну коробку с аккумуляторами и другую — с ноутбуками без аккумуляторов. Распределительный центр Y отгружает новые коробки, содержащие один ноутбук и один аккумулятор	repairing	(ремонт)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где неисправное изделие ремонтируется (как правило, в процессе послепродажного обслуживания), без замены на новое Компьютер привозится в ремонтный центр для исправления неполадки.	Деталь самолета находится в центре технического обслуживания для диагностики проблемы	replacing (замена)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект заменяется или обменивается на другой объект Дефектная деталь самолета заменяется на новую	reserving	(резервирование)
Процесс, в котором комплект идентификаторов на уровне экземпляра, еще не введенных в действие, предоставляются другой стороне для использования Производитель предоставляет комплект номеров EPC для ящиков этикетировщику, представляющему третью сторону	retail_selling	(розничная_продажа)
Обозначает определенный вид деятельности в рамках бизнес-процесса в контрольно-кассовом узле с целью передачи права собственности покупателю в обмен на определенное ценностное возмещение (деньги, кредит и т.п.) Предприятие розничной торговли X осуществляет реализацию отвертки покупателю, путем подтверждения оплаты с использованием системы в контрольно-кассовом узле	shipping	(отгрузка)
Указывает на весь процесс с бизнес-этапами staging_outbound (подготовка_к_отправке), loading (погрузка) и departing (отправка). Указанный бизнес-этап может использоваться, когда более детализированная информация о процессе на этапе неизвестна или недоступна. Может указывать на завершающее событие с точки зрения отгрузки. Использование бизнес-этапа shipping (отгрузка) взаимоисключает использование бизнес-этапов staging_outbound (подготовка_к_отправке), departing (отправка) или loading (погрузка)	Изготовитель A загружает продукцию в транспортный контейнер и считывает данные о продукции, после чего закрывает дверь. Данные о продукции считываются со стороны транспортного средства. Груз незамедлительно забирается и в этот момент с ним соотносится транспортная накладная (груз покидает площадку). На территории распределительного центра Y грузовик, нагруженный стеллажами с наполненной транспортной тарой, отъезжает от загрузочной платформы или зоны погрузки.	Изготовитель A завершает погрузку продукции в прицеп и опечатывает дверь. Прицеп готов к перевозке. Создание уведомления об отгрузке (Despatch Advice/ASN <1>) инициирует событие «shipping» (отгрузка). Поставщик логистических услуг (3PL) забирает и маркирует продукцию. Продукция загружается в прицеп, и оформляется ее передача грузоперевозчику. Поставщик логистических услуг (3PL) уведомляет изготовителя, который создает событие «shipping» (отгрузка). Примечание — Такая последовательность действий отмечается, если ОТСУТСТВУЕТ бизнес-этап departing на месте считывания у ворот. Типовая последовательность бизнес-этапов: staging_outbound (подготовка_к_отправке) loading (погрузка) departing (отправка) Описанные выше этапы предполагают способность и намерение организации обмениваться информацией обо всех этапах процесса. Если на этих этапах процесса не отсутствует сбор данных, будет использоваться единственный бизнес-этап — shipping (отгрузка) staging_outbound (подготовка_к_отправке)
Обозначает определенный вид деятельности в рамках бизнес-процесса, в ходе которого объект перемещается в зону, где он будет ожидать погрузки для транспортирования Контейнер закрывают для последующей погрузки в автотранспортное средство на площадке.	Контейнер закрывают и опечатывают для последующей погрузки в автотранспортное средство на площадке.	Продукция отобрана и теперь ожидает загрузки в контейнер в зоне погрузки stock-taking (инвентаризация)
Процесс подсчета объектов в пределах одного места нахождения согласно установленным правилам и/или стандартам, служащим основой для бухгалтерского учета Все номера EPC в предприятии розничной торговли считывают портативным устройством считывания согласно процедуре, установленной бухгалтерией организации	stocking	(пополнение)
Обозначает определенный вид деятельности в рамках бизнес-процесса в каком-либо месте нахождения с целью обеспечения доступности объекта для покупателя или выполнения заказа в распределительном центре Предприятие розничной торговли X размещает банки из ящика на полке в торговом зале.	Распределительный центр X перемещает товары из зоны хранения в зону комплектования	storing (хранение)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект перемещается на хранение на склад или со склада в пределах какого-либо места нахождения Предприятие-изготовитель A перемещает поддон из зоны приемки на стеллаж.	Предприятие розничной торговли X перемещает ящик с разгрузочной платформы на полку на складе	transforming (преобразование)
(устаревший бизнес-этап) Обозначает определенный вид деятельности в рамках бизнес-процесса, где один или несколько объектов являются исходным материалом процесса, который необратимо меняет эти объекты, превращая их в новый объект или объекты; на выходе получают новый ключевой идентификатор и новые характеристики. Этот бизнес-этап является устаревшим для использования в версии по &ГОСТ Р 59167&, который содержит тип события TransformationEvent (Событие_с_Преобразованием) для преобразований. Такие бизнес-этапы, как commissioning (присвоение_идентификатора), creating_class_instance (создание_экземпляра_на_уровне_класса) или другие бизнес-этапы могут использоваться совместно с TransformationEvent (Событие_с_Преобразованием)	Предприятие-мясозаготовитель X разделывает целую коровью тушу на две полутуши («один ко многим»). Пищевое предприятие Y соединяет воду, овощи и мясо, создавая порцию супа («многие к одному»). Мясник Z смешивает мясо разных туш, пропускает через мясорубку и создает отдельные упаковки говяжьего фарша («многие ко многим»)	transporting (транспортирование)
Процесс перемещения объекта из одного места нахождения в другое с помощью транспортного средства (например, корабля, поезда, грузовика, самолета) Грузоперевозчик X транспортирует 150 контейнеров для морских перевозок из морского порта Гонконга в морской порт Гамбурга на контейнерном судне.	Поезд с 20 товарными вагонами следует от одной железнодорожной станции к другой.	Грузовик везет прицеп со склада в распределительный центр unloading (разгрузка)
Обозначает определенный вид деятельности в рамках бизнес-процесса, где объект выгружается из транспортного средства Производитель A выгружает поддоны из транспортного средства. Поддоны дезагрегируются от транспортного средства.	Распределительный центр Y выгружает сетки с контейнерами из грузовика	unpacking (распаковывание)
Обозначает определенный вид деятельности в рамках бизнес-процесса, который включает извлечение продукции (отдельных изделий, упаковок меньшего размера, ящиков, поддонов) из контейнера большего размера — как правило, после получения или приемки. Дезагрегирование одного предмета от другого, как правило, происходит в этот момент 12 упаковок газированной воды извлекаются из ящика.	Развесной картофель извлекается из транспортной тары	void_shipping (недействительная_отправка)
Обозначает процесс декларирования того, что один или несколько объектов в предыдущем процессе отправки (обработанных в событии EPCIS с бизнес-этапами shipping (отгрузка), departing (отправка), или consigning (передача на консигнацию)) не были отгружены (или отправлены или переданы на консигнацию), как было указано ранее Отправитель отменяет поставку после предыдущего события отгрузки.	Отправитель узнает, получив соответствующее уведомление от получателя или самостоятельно, о том, что отправка, которую он считал состоявшейся и в отношении которой он создал событие отправки, на самом деле не состоялась. Этот факт фиксируется соответствующим образом.	Отправитель обнаруживает, что три из десяти ранее отправленных предметов, не были включены в отправку. Событие voidShipping (недействительная_отправка) указывает на то, что эти три предмета не были отправлены <1> ASN — сокращение от «advanced shipping notice» (предварительное уведомление об отгрузке).

7.2 Состояния (Dispositions)

В настоящем подразделе определяются типовые значения идентификаторов для лексикона EPCIS DispositionID (Идентификатор_Состояния).

Данные идентификаторы заполняют поле disposition (состояние) в событии EPCIS, как показано ниже.

7.2.1 Структура идентификатора URI

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

urn:epcglobal:cbv:disp:payload,

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

7.2.2 Соответствующее использование

Любое событие EPCIS в документе, соответствующем БДЛ, МОЖЕТ содержать поле disposition (состояние). Если поле disposition (состояние) присутствует, то значением поля disposition (состояние) ДОЛЖЕН быть идентификатор URI, состоящий из префикса urn:epcglobal:cbv:disp:, за которым следует строка, указанная в первом столбце соответствующей строки нижеуказанной таблицы &2&. Часть, следующая за префиксом, ДОЛЖНА быть записана точно так, как указано в ниже приведенной таблице &2&, и только строчными буквами (возможно использование знака подчеркивания).

Любое событие EPCIS в документе, совместимом с БДЛ, МОЖЕТ содержать поле disposition (состояние), и значением поля disposition (состояние) МОЖЕТ быть идентификатор URI, как указано выше для документа, соответствующего БДЛ, и МОЖЕТ быть любым другим идентификатором URI, выполняющим общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для других целей.

7.2.2.1 Пример соответствующего и несоответствующего использования (условный)

Далее приведена выдержка из документа EPCIS, совместимого с БДЛ, в формате XML, содержащая единственное событие, где состоянием события является значение базовой деловой лексики «in progress» (в процессе выполнения):

<epcis:EPCISDocument xmlns:epc«s=»urn:epcglobal:epcis:xsd:1» ...>

  <EPCISBody><br>
    <EventList>

      <ObjectEvent>
       ...
          <disposition>urn:epcglobal:cbv:disp:in_progress</состояние>
           ...
      </ObjectEvent>
    </EventList>
  </EPCISBody>
</epcis:EPCISDocument>

Далее приведен НЕ соответствующий БДЛ пример, поскольку в нем не используется полная строка идентификатора URI в поле disposition (состояние). Он также не является совместимым с БДЛ, поскольку значение поля disposition (состояние) не содержит идентификатор URI с указанием владельца, как требуется согласно &ГОСТ Р 59167-2020&, пункт 6.4.

<epcis:EPCISDocument xmlns:epc«s=»urn:epcglobal:epcis:xsd:1» ...> ... in_progress</состояние> НЕВЕРНО ... </epcis:EPCISDocument>

Дополнительные примеры приведены в 11.1.

7.2.3 Значения и определения элементов состояний

Таблица 2

Значения и их определения элементов состояний с примерами

7.2.3.1 Значения Disposition (Состояние) из [3] (версия лексики CBV 1.0), признанные устаревшими в &[4]& (версия лексики CBV 1.1)

В &[3]& (версии лексики CBV 1.0) были установлены некоторые значения disposition (состояние), которые признаны устаревшими в &[4]& (версии лексики CBV 1.1). В таблице &3& перечислены устаревшие значения disposition (состояние) и значения, которые заменяют их в &[4]&. Любое значение в &[4]& применимо ко всем ситуациям, в которых использовалось соответствующее значение из &[3]&, но также может быть также применимо к подобным ситуациям, где понятие «sellable» (подлежащее реализации) не является актуальным. Например, в &[4]& состояние damaged (поврежден) может применяться к возвратному активу, который никогда не рассматривался в качестве «sellable» (подлежащее реализации), даже при отсутствии дефектов.

&Таблица 3&

7.3 Типы документов бизнес-транзакций (Business Transaction Types)

В настоящем подразделе устанавливаются типовые идентификаторы для лексикона типов документов бизнес-транзакций EPCIS BusinessTransactionTypeID (Идентификатор_Типа_Документа_Бизнес-Транзакции). Указанные идентификаторы могут использоваться для заполнения атрибута type (тип) элемента bizTransaction (документ_Бизнес-транзакции) в событии EPCIS. Подробная информация приведена в 8.5, где объясняется, когда следует использовать такие идентификаторы.

7.3.1 Структура идентификатора URI

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

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

7.3.2 Соответствующее использование

Любое событие EPCIS в документе, соответствующем БДЛ, МОЖЕТ содержать один или несколько элементов bizTransaction (документ_Бизнес-транзакции). Если элементы bizTransaction (документ_Бизнес-транзакции) присутствуют, каждый такой элемент МОЖЕТ содержать атрибут type (тип). Если данный элемент bizTransaction (документ_Бизнес-транзакции) содержит атрибут type (тип), значением такого атрибута type (тип) ДОЛЖЕН быть идентификатор URI, состоящий из префикса urn:epcglobal:cbv:btt:, за которым следует строка, указанная в первом столбце соответствующей строки в таблице &4&. Часть, следующая за префиксом, ДОЛЖНА быть записана точно так, как указано в таблице &4&, только строчными буквами (возможно использование знака подчеркивания, как показано). См. 8.5, где приведены требования к совместимости, касающиеся типов документов бизнес-транзакций.

Пример (условный) — Документ EPCIS в формате XML с примером использования приведен в 11.1.

Любое событие EPCIS в документе, совместимом с БДЛ, МОЖЕТ содержать один или несколько элементов bizTransaction (документ_Бизнес-транзакции). Если элементы bizTransaction (документ_Бизнес-транзакции) присутствуют, каждый такой элемент МОЖЕТ содержать атрибут type (тип). Если данный элемент bizTransaction (документ_Бизнес-транзакции) содержит атрибут type (тип), значение атрибута type (тип) МОЖЕТ быть идентификатором URI, как указано выше для документа, соответствующего БДЛ, и МОЖЕТ быть любым другим идентификатором URI, соответствующим общим требованиям, установленным в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для других целей.

7.3.3 Значения и определения элементов типов документов бизнес-транзакций

Таблица 4

7.4 Типы начальных/конечных пунктов (Source/Destination types)

В настоящем подразделе устанавливаются значения типовых идентификаторов для лексикона EPCIS SourceDestTypeID (Идентификатор_Типа_Начального_Пункта_Конечного_Пункта). Такие идентификаторы могут использоваться для заполнения атрибута type (тип) элемента source (начальный_пункт) или destination (конечный_пункт) в событии EPCIS. Подробные требования по использованию идентификаторов приведены в 8.6.

7.4.1 Структура идентификатора URI

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

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

7.4.2 Соответствующее использование

Любое событие EPCIS в документе, соответствующем БДЛ, МОЖЕТ содержать один или несколько элементов source (начальный_пункт) или destination. Значением атрибута type (тип) подобного элемента source (начальный_пункт) или destination (конечный_пункт) должен быть идентификатор URI, включающий префикс urn:epcglobal:cbv:sdt:, за которым следует строка, указанная в первом столбце соответствующей строки в таблице &5&. Часть, следующая за префиксом, ДОЛЖНА быть записана точно так, как указано в таблице &5&, только строчными буквами (возможно использование знака подчеркивания, как показано). В 8.6 приведены требования совместимости, касающиеся типов начальных/конечных пунктов.

Пример (условный) — Документ EPCIS в формате XML с примером использования приведен в 11.1.

Любое событие EPCIS в документе, совместимом с БДЛ, МОЖЕТ содержать один или несколько элементов source (начальный_пункт) или destination (конечный_пункт). Значением атрибута type (тип) подобного элемента source (начальный_пункт) или destination (конечный_пункт) МОЖЕТ быть идентификатор URI, как указано выше для документа, соответствующего БДЛ, или МОЖЕТ быть любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для других целей.

7.4.3 Значения и определения элементов лексикона типов начальных/конечных пунктов

Таблица 5

7.5 Идентификаторы причин ошибок (Error reason identifiers)

В настоящем подразделе устанавливаются значения типовых идентификаторов для лексикона идентификаторов причин ошибок EPCIS ErrorReasonID (Идентификаторы_Причин_Ошибок). Такие идентификаторы могут быть использованы для заполнения атрибута reason (причина) элемента errorDeclaration (заявление_об_Ошибке) в событии EPCIS.

7.5.1 Структура идентификатора URI

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

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

7.5.2 Соответствующее использование

Любое событие EPCIS в документе, соответствующем БДЛ, МОЖЕТ содержать элемент ErrorDeclaration (Заявление_об_Ошибке), который в свою очередь МОЖЕТ содержать поле reason (причина). В случае, когда в документе, соответствующем БДЛ, содержится поле reason (причина) элемента ErrorDeclaration (Заявление_об_Ошибке), его значением ДОЛЖЕН быть идентификатор URI, включающий префикс urn:epcglobal:cbv:er:, за которым следует строка, указанная в первой колонке одной из строк в таблице &6& в пункте 7.5.3. Часть, следующая за префиксом, ДОЛЖНА быть записана точно так, как указано в таблице &6&, только строчными буквами (возможно использование знака подчеркивания, как показано).

Любое событие EPCIS в документе, совместимом с БДЛ, МОЖЕТ содержать элемент ErrorDeclaration (Заявление_об_Ошибке), который в свою очередь МОЖЕТ содержать поле reason (причина). В случае, когда в документе, совместимом с БДЛ, содержится поле reason (причина) элемента ErrorDeclaration (Заявление_об_Ошибке), его значением МОЖЕТ быть идентификатор URI, как указано выше для документа, соответствующего БДЛ, или МОЖЕТ быть любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для других целей.

7.5.3 Значения и определения элементов лексикона идентификаторов причин ошибок

Таблица 6

8 Пользовательские лексиконы

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

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

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

&ГОСТ Р 59167-2020&, пункт 6.4, предусматривает общие ограничения для идентификаторов, которые конечные пользователи могут создавать для использования как элементов пользовательской лексики. В частности, идентификатор должен соответствовать синтаксису идентификаторов URI, а также либо соответствовать правилам синтаксиса, определенным в стандартах GS1, либо принадлежать к подпространству идентификаторов URI, которое контролируется конечным пользователем, присваивающим их.

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

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

• идентификатор EPC URI: идентификатор URI номера электронного кода продукции (EPC) «чистый ключевой идентификатор» может применяться в качестве элемента пользовательского лексикона. Номера EPC имеют структуру и значение, получившие широкое распространение. Номера EPC также могут быть закодированы на носителях данных, таких как радиочастотные метки и символы штрихового кода, в соответствии со стандартами GS1. По этой причине номера EPC зачастую представляют собой лучший выбор для создания элементов пользовательских лексиконов, когда их применение возможно;
• частное и общеотраслевое имя URN: унифицированное имя ресурса (Uniform Resource Name, URN) вида urn:URNNamespace:... может использоваться в качестве элемента пользовательского лексикона. Такой способ требует, чтобы пользователь, создающий лексический элемент, был уполномочен применять пространство имен URN, которое идет за префиксом «urn:». Например, конечный пользователь может зарегистрировать свое собственное пространство имен URN в Администрации адресного пространства Интернет (Internet Assigned Numbers Authority, IANA). В качестве альтернативы отраслевая ассоциация или иное объединение торговых партнеров может зарегистрировать пространство имен URN и определить синтаксический шаблон, начиная с данного пространства имен для использования членами такого объединения при создании лексических элементов. Учитывая сложность регистрации пространства имен URN, такой метод используется, как правило, группами торговых партнеров, а не отдельными конечными пользователями;
• указатель HTTP URL: унифицированный указатель ресурсов (URL) вида: http://Domain/... может использоваться в качестве элемента пользовательского лексикона. Такой способ требует, чтобы пользователь, создающий лексический элемент, был уполномочен использовать доменное имя, которое идет за префиксом http:. Зачастую используется субдомен домена организации конечного пользователя: например, «некая корпорация» может решить использовать epcis.example.com в качестве имени домена для построения идентификаторов пользовательского лексикона. Поскольку регистрация имени интернет-домена относительно простой процесс, этот метод вполне подходит для отдельных конечных пользователей, так же как и для отраслевых объединений.

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

Подробная информация о каждой из трех форм приведена далее.

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

8.1.1 Общие рекомендации для идентификаторов EPC URI как элементов пользовательской лексики

В случае применения идентификаторов EPC URI в качестве элементов пользовательской лексики, документы, совместимые с БДЛ, и соответствующие БДЛ, ДОЛЖНЫ использовать чистый ключевой идентификатор EPC URI, за исключением ситуаций, описанных ниже. «Чистые ключевые идентификаторы» EPC URI — это идентификатор URI, соответствующий определению в [&9&, раздел 6] (в частности идентификатор URI, следующий грамматическому правилу EPC-URI в [&9&, подраздел 6.3]. «Чистые ключевые идентификаторы» EPC URI начинаются с urn:epc:id:....

Все документы, и совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать какие-либо другие формы идентификатора URI для EPC, определенные в &[9]&. В частности, в документах НЕ ДОЛЖНЫ использоваться идентификаторы URI радиочастотных меток EPC (urn:epc:tag:...), шаблон чистого ключевого идентификатора EPC Pure URI (urn:epc:idpat:...) или шаблон идентификатора EPC URI (urn:epc: pat:...), за тем исключением, что все документы, и совместимые с БДЛ, и соответствующие БДЛ, МОГУТ использовать шаблон идентификаторов EPC URI для идентификации объектов уровня класса, как указано в 8.3.1. Все документы, и совместимые с БДЛ, и соответствующие БДЛ, МОГУТ использовать необработанный идентификатор EPC Raw URI (urn:epc:raw:...), как указано в [&9&, раздел 12], при условии, что необработанное значение (Raw) не может быть декодировано как номер EPC. Все документы, и совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать необработанный идентификатор EPC Raw URI, представляющий содержимое банка памяти EPC, которое может быть успешно декодировано в чистый ключевой идентификатор EPC URI (Pure Identity EPC URI) согласно &[9]&.

Примечание — Согласно &ГОСТ Р 59167& «когда уникальный ключевой идентификатор [для идентификатора на уровне экземпляра параметра „что“] представляет собой номер электронного кода продукции, [идентификатор] ДОЛЖЕН быть „чистым ключевым идентификатором“ („pure identity“) URI для EPC, как указано в [&9&, раздел 6]. В практических реализациях МОГУТ быть допустимы идентификаторы в формате идентификаторов URI, отличных от номеров EPC». Вышеприведенный текст проясняет данное требование и более конкретно касается &[9]&. Вышеприведенный текст также распространяет данные ограничения на использование идентификаторов EPC URI в других параметрах событий EPCIS, а не только в связи с параметром «что».

8.1.2 Общие рекомендации для частных и общеотраслевых имен URN как элементов пользовательской лексики

В случаях, указанных в 8.2 - 8.5, документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частное и общеотраслевое имя URN, как указано ниже.

Частное и общеотраслевое имя URN ДОЛЖНО принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 7&):

Кроме того, идентификатор такого вида ДОЛЖЕН содержать не более 128 знаков, при этом РЕКОМЕНДУЕТСЯ использование не более 60 знаков.

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

8.1.3 Общие рекомендации для указателей HTTP URL как элементов пользовательской лексики

В случаях, указанных в 8.2 - 8.5, документ, совместимый с БДЛ, и документ, соответствующий БДЛ, МОЖЕТ использовать указатель HTTP URL.

Указатель HTTP URL ДОЛЖЕН принимать следующий вид:

http://[Subdomain.]Domain/**/qual/Remainder

&Таблица 8&

Кроме того, идентификатор такого вида ДОЛЖЕН содержать не более 128 знаков, при этом РЕКОМЕНДУЕТСЯ использование не более 60 знаков.

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

8.2 Физические или цифровые объекты (Physical or digital objects) (идентификация на уровне экземпляра)

Идентификаторы на уровне экземпляра физических или цифровых объектов заполняют параметр «что» в событиях EPCIS. Сюда относятся поля epcList (список_EPC), parentID (идентификатор_Родителя), childEPC (epc_Потомка), inputEPC (epc_на_Входе) и outputEPC (epc_на_Выходе) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией), TransacationEvent (Событие_с_Документом_Транзакции) и TransformationEvent (Событие_с_Преобразованием). См. &ГОСТ Р 59167-2020&, раздел 1, где подробно определяется «объект» в этом смысле, выдержка также приведена ниже.

Документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из трех форм идентификатора URI, указанных в настоящем подразделе для заполнения указанных выше полей событий EPCIS для любого соответствующего поля, значение которого отлично от нуля. Документ, совместимый с БДЛ, МОЖЕТ использовать одну из трех форм идентификатора URI, указанных в настоящем подразделе, либо МОЖЕТ использовать любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для других целей.

И документам, совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI, как указано в 8.2.1, если нет веских причин поступить по-другому.

Примечание — В соответствии с &ГОСТ Р 59167& в контексте EPCIS понятие «объекты» обычно соответствует физическим объектам, которые идентифицируются либо на уровне класса, либо на уровне экземпляра, и которые рассматриваются на этапах физической обработки в рамках всего бизнес-процесса, охватывающего одну или несколько организаций. Примерами таких физических объектов являются предметы торговли, логистические единицы, возвратные активы, материальные активы, физические документы и т.д. «Объекты» также могут относиться к цифровым объектам, идентифицируемым либо на уровне класса, либо на уровне экземпляра, и участвующим на сопоставимых этапах бизнес-процессов. Примерами таких цифровых объектов являются цифровые предметы торговли (загрузки музыкальных произведений, электронные книги и т.п.), цифровые документы (электронные купоны и др.) и тому подобное. В настоящем стандарте слово «объект» используется для обозначения физического или цифрового объекта, являющегося предметом этапа бизнес-процесса и идентифицируемого на уровне класса или на уровне экземпляра». В подразделе 8.2 настоящего стандарта определены варианты структуры идентификатора для идентификации объектов на уровне экземпляра; в подразделе 8.3 определены варианты структуры идентификатора для идентификации объектов на уровне класса.

8.2.1 Идентификатор EPC URI для идентификации объектов на уровне экземпляра

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать чистый ключевой идентификатор EPC URI, как указано в 8.1.1, для заполнения полей EPCIS epcList (список_EPC), parentID (идентификатор_Родителя) и childEPC (EPC_потомка) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией) и TransacationEvent (Событие_с_Документом_Транзакции). Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать эту форму, если нет веских причин поступить по-другому.

Все документы, и совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать SGLN EPC (urn:epc:id:sgln:...) в качестве идентификатора объекта.

И документы, совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать какие-либо другие формы идентификатора URI для EPC, как указано в &[9]& (см. подробнее в 8.1.1).

8.2.2 Частные и общеотраслевые имена URN для идентификации объектов на уровне экземпляра

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные или общеотраслевые имена URN, как указано ниже, для заполнения полей epcList (список_EPC), parentID (идентификатор_Родителя) и childEPC (epc_Потомка) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией) и TransacationEvent (Событие_с_Документом_Транзакции). Однако всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.2.1), если нет веских причин поступить по-другому. См. 8.1, где приводятся общие положения относительно использования частных и общеотраслевых идентификаторов URI.

Частные и общеотраслевые идентификаторы URI, подходящие для заполнения полей epcList (список_EPC), parentID (идентификатор_Родителя) и childEPC (epc_Потомка) в событиях EPCIS, ДОЛЖНЫ принимать следующий вид:

urn:URNNamespace:**:obj:Objid

&Таблица 9&

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.2.3 Указатель HTTP URL для идентификации объектов на уровне экземпляра

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель HTTP URL, как указано ниже, для заполнения полей epcList (список_EPC), parentID (идентификатор_Родителя) и childEPC (epc_Потомка) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией) и TransacationEvent (Событие_с_Документом_Транзакции). Однако, всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.2.1), если нет веских причин поступить по-другому. См. 8.1, где приводятся общие положения относительно использования идентификаторов с указателями HTTP URL.

Указатели HTTP URL, подходящие для заполнения полей epcList (список_EPC), parentID (идентификатор_Родителя) и childEPC (epc_Потомка) в событиях EPCIS, ДОЛЖНЫ принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 10&):

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.3 Физические или цифровые объекты (идентификация на уровне класса)

Идентификаторы на уровне класса физических или цифровых объектов заполняют параметр «что» в событиях EPCIS. Сюда входит поле epcClass (epc_на_уровне_Класса) в событии EPCIS QuantityEvent (Событие_с_Количеством_Объектов) (признанное устаревшим в &[12]& <1>) и в структурах quantityElement (Элемент_Количество) событий EPCIS Object-Event (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией), TransacationEvent (Событие_с_Документом_Транзакции) и TransformationEvent (Событие_с_Преобразованием). См. &ГОСТ Р 59167-2020&, раздел 1, где подробно определяется термин «объект» в указанном смысле, выдержка также приведена &в примечании к пункту 8.2&.

Документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из трех форм идентификатора URI, указанных в настоящем подразделе для заполнения указанных выше полей событий EPCIS для любого соответствующего поля, значение которого отлично от нуля. Документ, совместимый с БДЛ, МОЖЕТ использовать одну из трех форм идентификатора URI, указанных в настоящем подразделе, либо МОЖЕТ использовать любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для других целей.

Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI, как указано в 8.3.1, если нет веских причин поступить по-другому.

8.3.1 Идентификаторы EPC URI для идентификации объектов на уровне класса

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать одну из следующих форм идентификатора URI, указанных в Стандарте данных радиочастотных меток EPC, для заполнения поля epcClass (epc_на_уровне_Класса) в событии EPCIS QuantityEvent (признано устаревшим в &[12]& <1>) и в структурах quantityElement (Элемент_Количество) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией), TransacationEvent (Событие_с_Документом_Транзакции) и TransformationEvent (Событие_с_Преобразованием) (&см. таблицу 11&):

&Таблица 11&

<1> Соответственно применимо к ГОСТ Р 59167 и [7].

<2> LGTIN — схема для номера GTIN + номер партии/серии используется для описания класса объектов, принадлежащих данной партии или серии для данного номера GTIN.

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, НЕ ДОЛЖЕН использовать какую-либо другую форму шаблона чистого ключевого идентификатора URI, указанную в [&9&, раздел 8]. Это требование включает, например, идентификатор URI шаблона чистого ключевого идентификатора SSCC или идентификатор URI шаблона чистого ключевого идентификатора SGTIN с двумя подстановочными знаками «*».

Все документы, и совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать какие-либо другие формы идентификатора URI для EPC, как указано в &[9]& (см. подробнее в 8.1.1).

8.3.1.1 Пояснение

Стандарт данных радиочастотных меток EPC определяет идентификаторы URI шаблона чистого ключевого идентификатора EPC как способ обозначения шаблона, который соответствует множеству номеров EPC на уровне экземпляра. Например, идентификатора URI шаблона чистого ключевого EPC urn:epc:idpat:sgtin:0614141.112345.* соответствует любому идентификатору SGTIN URI, который начинается с urn:epc:idpat:sgtin:0614141.112345, в частности идентификатор SGTIN URI urn:epc:idpat:sgtin:0614141.112345.400. В простом запросе события EPCIS такой шаблон может использоваться, чтобы подобрать события EPCIS, параметр «что» которых содержит идентификаторы на уровне экземпляра с определенным номером GTIN и любым серийным номером.

В таблице &11& приведено использование идентификаторов URI шаблона чистого ключевого идентификатора EPC для выполнения второй цели, а именно в качестве идентификаторов на уровне класса для использования в полях элемента количество (Quantity) в событиях EPCIS. При таком использовании идентификатора URI urn:epc:idpat:sgtin:0614141.112345.* относится к классу объекта, идентифицированному номером GTIN 10614141123459.

Не все идентификаторы URI шаблона чистого ключевого идентификатора EPC могут применяться как идентификаторы на уровне класса. Например, когда urn:epc:idpat:sgtin:0614141.. используется в запросе EPCIS для сопоставления с идентификаторами на уровне экземпляра, он сопоставляет все номера SGTIN, которые включают префикс предприятия GS1 0614141. Таким образом, он действует как условие сопоставления для запроса, но соответствующий класс объекта отсутствует, поэтому он не является применимым идентификатором на уровне класса. Аналогичные условия использования характеризуют такой идентификатор URI, как urn:epc:idpat:sscc:0614141.* и другие идентификаторы URI шаблона EPC, не включенные в таблицу &11&.

8.3.2 Частные и общеотраслевые имена URN для идентификации объектов на уровне класса

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные или общеотраслевые имена URN, как указано ниже, для заполнения поля epcClass (epc_на_уровне_Класса) в событии EPCIS QuantityEvent (Событие_с_Количеством_Объектов) (признано устаревшим в &[12] <1>&) и в структурах quantityElement (Элемент_Количество) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией), TransacationEvent (Событие_с_Документом_Транзакции) и TransformationEvent (Событие_с_Преобразованием). Однако, всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.3.1), если нет веских причин поступить иначе. См. 8.1, где приводятся общие положения относительно использования частных и общеотраслевых идентификаторов URI.

<1> Соответственно применимо к ГОСТ Р 59167 и [2].

Частные и общеотраслевые URI, подходящие для заполнения поля epcClass (epc_на_уровне_Класса) в событии EPCIS, ДОЛЖНЫ принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 12&):

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.3.3 Указатели HTTP URL для идентификации объектов на уровне класса

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель HTTP URL, как указано ниже, для заполнения поля epcClass (epc_на_уровне_Класса) в событии EPCIS QuantityEvent (Событие_с_Количеством_Объектов) (признано устаревшим в &[12]& <1> и в структурах quantityElement (Элемент_Количество) в событиях EPCIS ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией), TransacationEvent (Событие_с_Документом_Транзакции) и TransformationEvent (Событие_с_Преобразованием). Однако, всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.3.1), если нет веских причин поступить по-другому. См. 8.1, где приводятся общие положения относительно использования идентификаторов указателя HTTP URL.

<1> Соответственно применимо к ГОСТ Р 59167 и [7].

Указатель HTTP URL, подходящий для заполнения полей epcClass (epc_на_уровне_Класса) в событиях EPCIS, ДОЛЖЕН принимать следующий вид:

http://[Subdomain.]Domain/**/класс/ObjClassid

&Таблица 13&

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.4 Места нахождения (Locations)

Идентификаторы мест нахождения заполняют параметр «где/куда» событий EPCIS. Сюда относятся поля readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS.

Документ, соответствующий с БДЛ, ДОЛЖЕН использовать одну из четырех форм идентификатора URI, указанных в настоящем подразделе для заполнения указанных выше полей событий EPCIS для любого соответствующего поля, значение которого отлично от нуля. Документ, совместимый с БДЛ, МОЖЕТ использовать одну из четырех форм идентификатора URI, указанных в настоящем подразделе, либо МОЖЕТ использовать любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для других целей.

И документам, совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI, как указано в 8.4.1, если нет веских причин поступить по-другому.

8.4.1 Идентификаторы EPC URI для идентификаторов мест нахождения

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать чистый ключевой идентификатор EPC URI, как указано в 8.1.1, для заполнения полей readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS. Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать эту форму, если нет веских причин поступить по-другому.

Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, НЕ СЛЕДУЕТ использовать схемы EPC, отличные от номера SGLN EPCIS (urn:epc:id:sgln:...) для идентификаторов мест нахождения, если нет веских причин поступить по-другому.

И документы, совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать какие-либо иные формы идентификатора URI для номеров EPC, как указано в &[9]& (см. подробнее в 8.1.1).

8.4.2 Частные и общеотраслевые имена URN для идентификаторов мест нахождения

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные или общеотраслевые имена URN, как указано ниже, для заполнения полей readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS. Однако, и документам, совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.4.1), если нет веских причин поступить иначе. См. 8.1, где приводятся общие рекомендации относительно использования частных и общеотраслевых идентификаторов URI.

Частные и общеотраслевые идентификаторы URI, подходящие для заполнения полей readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS, ДОЛЖНЫ принимать следующий вид:

urn:URNNamespace:**:loc:Locid

&Таблица 14&

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.4.3 Указатели HTTP URL для идентификаторов мест нахождения

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель HTTP URL, как указано ниже, для заполнения полей readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS. Однако, и документам, совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.4.1), если нет веских причин поступить иначе. См. 8.1, где приводятся общие положения относительно использования идентификаторов указателей HTTP URL.

Указатель HTTP URL, подходящий для заполнения полей readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS, ДОЛЖЕН принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 15&):

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

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

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать идентификатор URI географического места нахождения, как указано в &[5]&, для заполнения полей readPoint (место_Считывания) и businessLocation (производственное_Место_Назначения) во всех типах событий EPCIS. Такие идентификаторы могут использоваться в ситуациях, когда присвоение уникального идентификатора места нахождения не целесообразно; например, для идентификации места нахождения корабля в открытом океане. И документам, совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать идентификатор места нахождения, как указано в 8.4.1 - 8.4.3 (отдавая предпочтение форме идентификатора EPC URI, определенной в 8.4.1), если только идентификатор URI географического места нахождения не является единственным практически осуществимым альтернативным вариантом.

Синтаксис и значение идентификатора URI географического места нахождения установлены в &[5]&.

Примечание — Простейшая форма идентификатора URI географического места нахождения, соответствующего [5], выглядит таким образом:

Данный пример обозначает географическое место нахождения в точке с координатами 22,300 градуса северной широты и 118,44 градусов западной долготы.

Другие формы идентификатора URI geo позволяют включать высоту над уровнем моря, радиус неопределенности и базовую систему координат. Следует обратиться к &[5]& за подробной информацией по этим и другим положениям, применяемым к использованию идентификатора URI географического места нахождения.

8.5 Документы бизнес-транзакций (Business transactions)

Идентификаторы документов бизнес-транзакций заполняют параметр «на каком основании» событий EPCIS. Сюда относится поле bizTransactionList (список_Документов_Бизнес-Транзакций) во всех типах событий EPCIS.

Стандарт EPCIS предусматривает идентификацию бизнес-транзакции парой идентификаторов: «идентификатором документа бизнес-транзакции» («business transaction identifier» здесь и далее обозначаемым аббревиатурой «BTI»), который определяет определенный документ бизнес-транзакции, и необязательным «типом документов бизнес-транзакций» («business transaction type» здесь и далее обозначаемым аббревиатурой «BTT»), который указывает, какой вид бизнес-транзакции обозначает идентификатор (заказ на поставку, счет-фактура и т.д.). В подразделе 7.3 настоящего стандарта приведены стандартизованные значения идентификатора BTT.

Формы идентификатора URI для идентификатора BTI приведены ниже. Документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из четырех форм идентификатора URI, указанных в настоящем подразделе, для заполнения поля идентификатора BTI (текстовое содержание элемента bizTransaction (документ_Бизнес-транзакции)) событий EPCIS, для любого соответствующего поля, значение которого отлично от нуля. Документ, совместимый с БДЛ, МОЖЕТ использовать одну из четырех форм идентификатора URI, указанных в настоящем подразделе, либо МОЖЕТ использовать любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для иных целей.

Элемент bizTransaction (документ_Бизнес-транзакции) в событии EPCIS включает идентификатор BTI и необязательный идентификатор BTT в любой из следующих трех комбинаций:

• если целью является передача идентификатора документа бизнес-транзакции без указания его вида, идентификатор BTI включается, а идентификатор BTT опускается;
• если целью является передача идентификатора документа бизнес-транзакции и указание его вида, а кроме того, этот вид является одним из типовых видов БДЛ, определенных в 7.3, в таком случае идентификатор BTI включается, и один из идентификаторов URI, указанных в 7.3, также включается как идентификатор BTT;
• если целью является передача идентификатора документа бизнес-транзакции и указание его вида, а кроме того, этот вид не является одним из типовых видов БДЛ, определенных в 7.3, в таком случае идентификатор BTI включается, и один из идентификаторов URI, который не начинается с urn:epcglobal:cbv:..., также включается как идентификатор BTT. (Обеспечивается совместимость с БДЛ, но не соответствие БДЛ).

8.5.1 Идентификатор EPC URI для идентификаторов документов бизнес-транзакций

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать чистый ключевой идентификатор EPC URI, как указано в 8.1.1, в качестве идентификатора документа бизнес-транзакции во всех типах событий EPCIS. Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, НЕ СЛЕДУЕТ использовать схемы номера EPC, отличные от GDTI EPCIS (urn:epc:id:gdti:...) или GSRN EPCIS (urn:epc:id:gsrn:...) для идентификаторов документов бизнес-транзакций, если для этого нет веских причин. СЛЕДУЕТ использовать номера GDTI EPC в качестве идентификаторов документов бизнес-транзакций, только когда они были присвоены для обозначения бизнес-транзакции, а не физических документов, не связанных с какой-либо бизнес-транзакцией.

Все документы, и совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать какие-либо другие формы идентификатора URI для EPC, как указано в &[9]& (см. подробнее в 8.1.1).

Примечание (справочное) — Одно из предназначений Глобального идентификатора типа документа (GDTI) — идентифицировать документы бизнес-транзакции, такие как счета, заказы на поставку и т.п. Когда идентификатор GDTI используется таким образом, он подходит для применения в качестве идентификатора документа бизнес-транзакции в EPCIS. Однако, многие корпоративные информационные системы используют другие типы идентификаторов для бизнес-транзакций, поэтому использование идентификатора GDTI не столь рекомендуемо, как номера SGLN для мест нахождения или другие типы номеров EPC для физических или цифровых объектов. По этой же причине в 8.5.2 приведен вид идентификатора на основе номера GLN.

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.5.2 Идентификаторы на основе номера GLN для идентификаторов документов бизнес-транзакций унаследованных систем

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать идентификатор на основе номера GLN, как указано ниже, в качестве идентификатора документа бизнес-транзакции во всех типах событий EPCIS.

Идентификатор URI на основе номера GLN, подходящий для применения в качестве идентификатора документа бизнес-транзакции во всех событиях EPCIS ДОЛЖЕН принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 16&):

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.5.3 Частные и общеотраслевые имена URN для идентификаторов документов бизнес-транзакций

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные или общеотраслевые имена URN, как указано ниже, в качестве идентификатора документа бизнес-транзакции во всех типах событий EPCIS.

Частные и общеотраслевые имена URN, подходящие для применения в качестве идентификатора документа бизнес-транзакции во всех событиях EPCIS, ДОЛЖНЫ принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 17&):

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.5.4 Указатели HTTP URL для идентификаторов документов бизнес-транзакций

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель HTTP URL, как указано ниже, в качестве идентификатора документа бизнес-транзакции во всех типах событий EPCIS.

Указатель HTTP URL, подходящий для применения в качестве идентификатора документа бизнес-транзакции во всех событиях EPCIS, ДОЛЖЕН принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 18&):

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.6 Идентификаторы начальных/конечных пунктов (Source/Destination identifiers)

Идентификаторы начальных и конечных пунктов используются в элементах начального пункта source (начальный_пункт) и конечного пункта destination (конечный_пункт) (соответственно) параметра «на каком основании» в событиях EPCIS.

Документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из трех форм идентификатора URI, указанных в настоящем подразделе для заполнения указанных выше полей в событиях EPCIS. Документ, совместимый с БДЛ, МОЖЕТ использовать одну из трех форм идентификатора URI, указанных в настоящем подразделе, либо МОЖЕТ использовать любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для иных целей.

Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI, как указано в 8.6.1, если нет веских причин поступить по-другому.

8.6.1 Идентификаторы EPC URI для идентификаторов начальных/конечных пунктов

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать чистый ключевой идентификатор EPC URI, как указано в 8.1.1, для заполнения элементов source (начальный_пункт) и destination (конечный_пункт) во всех типах событий EPCIS. Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать эту форму, если нет веских причин поступить по-другому.

И документам, совместимым с БДЛ, и соответствующим БДЛ, НЕ СЛЕДУЕТ использовать схемы номеров EPC, отличные от номера SGLN EPC (urn:epc:id:sgln:...) для идентификаторов начального/конечного пункта, если для этого нет веских причин.

Все документы, и совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать какие-либо другие формы идентификатор URI для EPC, как указано в &[9]& (см. подробнее в 8.1.1).

8.6.2 Частные и общеотраслевые имена URN для идентификаторов начальных/конечных пунктов

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные или общеотраслевые имена URN, как указано ниже, для заполнения полей source (начальный_пункт) и destination (конечный_пункт) во всех типах событий EPCIS. Однако, и документам, совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.6.1), если нет веских причин поступить по-другому. См. 8.1, где приводятся общие положения относительно использования частных и общеотраслевых идентификаторов URI.

В дополнение к частным и общеотраслевым формам имен URN в соответствии с 8.4.2, частные и общеотраслевые идентификаторы URI, подходящие для заполнения полей source (начальный_пункт) и destination (конечный_пункт), во всех типах событий EPCIS ДОЛЖНЫ принимать следующий вид:

urn:URNNamespace:**:sd:Locid

&Таблица 19&

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

8.6.3 Указатели HTTP URL для идентификаторов начальных/конечных пунктов

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель HTTP URL, как указано ниже, для заполнения полей source (начальный_пункт) и destination (конечный_пункт) во всех типах событий EPCIS. Однако, и документам, совместимым с БДЛ, и соответствующим БДЛ, СЛЕДУЕТ использовать форму идентификатора EPC URI (см. 8.6.1), если нет веских причин поступить иначе. См. 8.1, где приводятся общие положения относительно использования идентификаторов HTTP URL.

В дополнение к форме указателя HTTP URL в соответствии с 8.4.3, указатель HTTP URL, подходящий для заполнения полей source (начальный_пункт) и destination (конечный_пункт), во всех типах событий EPCIS ДОЛЖЕН принимать следующий вид:

http://[Subdomain.]Domain/**/sd/SourceOrDestId

&Таблица 20&

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

8.7 Идентификаторы преобразования (Transformation identifiers)

Идентификаторы преобразования заполняют поле transformationID (идентификатор_Преобразования) в событиях EPCIS TransformationEvent (Событие_с_Преобразованием). Формы идентификатора URI для идентификаторов преобразования приведены ниже. Документ, соответствующий БДЛ, ДОЛЖЕН использовать одну из четырех форм идентификатора URI, указанных в настоящем подразделе, для заполнения поля transformationID (идентификатор_Преобразования) в событиях EPCIS TransformationEvent (Событие_с_Преобразованием), для любого соответствующего поля, значение которого отлично от нуля. Документ, совместимый с БДЛ, МОЖЕТ использовать одну из четырех форм идентификатора URI, указанных в настоящем подразделе, либо МОЖЕТ использовать любой другой идентификатор URI, выполняющий общие требования, установленные в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для иных целей.

8.7.1 Идентификаторы EPC URI для идентификаторов преобразования

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать чистый ключевой идентификатор EPC URL, как указано в 8.1.1, для заполнения поля transformationID (идентификатор_Преобразования) в событиях EPCIS TransformationEvent (Событие_с_Преобразованием).

Всем документам, и совместимым с БДЛ, и соответствующим БДЛ, НЕ СЛЕДУЕТ использовать схемы номера EPC, отличные от номера GDTI EPC (urn:epc:id:gdti:...) для идентификаторов преобразования, если для этого нет веских причин. Номер GDTI EPC СЛЕДУЕТ использовать в качестве идентификаторов преобразования, только когда они были присвоены для обозначения преобразования, а не физического документа, не связанного с преобразованием.

Все документы, и совместимые с БДЛ, и соответствующие БДЛ, НЕ ДОЛЖНЫ использовать какие-либо другие формы идентификатора URI для EPC, как указано в &[9]& (см. подробнее в 8.1.1).

Примечание — Одно из предназначений Глобального идентификатора типа документа (GDTI) — идентифицировать документы бизнес-транзакций, такие как заказы на производство, которые могут соответствовать преобразованиям один к одному. Когда идентификатор GDTI используют таким образом, он подходит для применения в качестве идентификатора преобразований в EPCIS. Однако, многие корпоративные информационные системы применяют другие типы идентификаторов для преобразований, поэтому использование идентификатора GDTI не так желательно, как номера SGLN для идентификации мест нахождения или другие типы номеров EPC для физических или цифровых объектов. По этой же причине в 8.7.2 приведен вид идентификатора на основе номера GLN.

8.7.2 Идентификаторы на основе номера GLN для идентификаторов преобразования унаследованных систем

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать идентификатор на основе номера GLN, как указано ниже, для заполнения поля transformationID (идентификатор_Преобразования) события EPCIS TransformationEvent (Событие_с_Преобразованием).

Идентификатор URI на основе номера GLN ДОЛЖЕН принимать следующий вид:

со следующими компонентами шаблона (&см. таблицу 21&):

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

8.7.3 Частные и общеотраслевые имена URN для идентификаторов преобразования

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные и общеотраслевые имена URN, как указано ниже, для заполнения поля transformationID (идентификатор_Преобразования) события EPCIS TransformationEvent (Событие_с_Преобразованием).

Частные и общеотраслевые имена URN ДОЛЖНЫ принимать следующий вид:

urn:URNNamespace:**:xform:transID

&Таблица 22&

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

8.7.4 Указатели HTTP URL для идентификаторов преобразований

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель HTTP URL, как указано ниже, для заполнения поля transformationID (идентификатор_Преобразования) событий EPCIS TransformationEvent (Событие_с_Преобразованием).

Указатель HTTP URL ДОЛЖЕН принимать следующий вид:

http://[Subdomain.]Domain/**/xform/xformID

&Таблица 23&

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

&Примечание& — Условный пример документа EPCIS в формате XML с примененным шаблоном приведен в подразделе 11.2.

8.8 Лексикон идентификаторов событий

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

Документы, соответствующие БДЛ, ДОЛЖНЫ использовать форму идентификатора URI, приведенную в 8.8.1, для заполнения поля eventID (идентификатор_События) событий EPCIS для любого указанного поля со значением, отличным от нулевого. Документ, совместимый с БДЛ, МОЖЕТ использовать форму идентификатора URI, установленную в 8.8.1, или МОЖЕТ использовать любой иной идентификатор URI, отвечающий общим требованиям, указанным в &ГОСТ Р 59167-2020&, пункт 6.4, за исключением тех идентификаторов URI, которые запрещены настоящим стандартом или предназначены для иных целей.

8.8.1 Универсальные уникальные идентификаторы (UUID) URI для идентификаторов событий

Документ, соответствующий БДЛ, ДОЛЖЕН, а документ, совместимый с БДЛ, МОЖЕТ использовать идентификатор UUID версии 1 или версии 4 по форме идентификатора URI в соответствии с &[13]& для заполнения полей eventID (идентификатор_События) в любом событии EPCIS, где данное поле не пропущено.

Пример - urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

9 Мастер-данные предметов торговли

Настоящий раздел устанавливает атрибуты мастер-данных, которые могут быть использованы для описания идентификатора предмета торговли, присутствующего в параметре «что» события EPCIS, включая поля EPC, идентификатора родителя (parentID), EPC на уровне класса (EPC Class). Различные идентификаторы предметов торговли используются на разных уровнях идентификации предметов торговли. Любой атрибут мастер-данных, определенный в БДЛ для идентификаторов предметов торговли, устанавливает один или несколько из следующих трех уровней идентификации, которые применимы для данного случая (&см. таблицу 24&).

&Таблица 24&

Документ, соответствующий или совместимый с БДЛ, МОЖЕТ включать любые атрибуты мастер-данных, указанные в настоящем подразделе, в сегменте мастер-данных заголовка EPCIS с учетом ограничений, установленных в других частях настоящего подраздела. Атрибуты мастер-данных, указанные в настоящем подразделе, также могут быть использованы в документе мастер-данных EPCIS или в ответе на запрос мастер-данных EPCIS. Документ, соответствующий БДЛ или совместимый с БДЛ, МОЖЕТ включать любые атрибуты мастер-данных уровня серии или уровня экземпляра, указанные в настоящем подразделе, в сегменте мастер-данных уровня экземпляра события EPCIS, но НЕ ДОЛЖЕН включать атрибуты уровня предмета торговли в сегмент мастер-данных уровня экземпляра.

В случае, когда атрибут мастер-данных, указанный в настоящем подразделе, используется в сегменте мастер-данных заголовка EPCIS, в документе мастер-данных EPCIS или в ответе на запрос мастер-данных EPCIS, каждый такой атрибут относится к конкретному указанному идентификатору и ко всем соответствующим идентификаторам нижнего уровня. Например, атрибут мастер-данных, указанный для идентификатора уровня предмета торговли urn:epc:idpat:sgtin:0614141.112345.*, также будет относиться к идентификаторам уровня серии и уровня экземпляра, имеющим тот же самый номер GTIN. Атрибут мастер-данных, указанный для идентификатора уровня серии urn:epc:class:lgtin:0614141.112345.L123, также будет относиться к идентификаторам уровня экземпляра, имеющим те же самые номера GTIN и серии.

В случае, когда атрибут мастер-данных, указанный в настоящем подразделе, используется в сегменте мастер-данных заголовка EPCIS, он относится ко всем идентификаторам, появляющимся в любом поле EPC или QuantityElement (Элемент_Количество) в рамках данного события.

9.1 Наименования атрибутов мастер-данных предметов торговли

В сегменте мастер-данных заголовка EPCIS, в документе мастер-данных EPCIS или в ответе на запрос мастер-данных EPCIS атрибут мастер-данных указывается в виде пары наименование/значение. Наименование каждого атрибута мастер-данных предмета торговли, указанного в настоящем подразделе, состоит из следующего идентификатора пространства имен:

urn:epcglobal:cbv:mda,

за которым следует знак (#), за которым следует местное наименование, в соответствии с 9.2.

В сегменте мастер-данных уровня экземпляра события EPCIS атрибут мастер-данных указывается в виде элемента XML. Наименованием элемента является XML Qname, пространством имен которого является тот же самый указанный выше идентификатор пространства имен, а местным наименованием которого является местное наименование в соответствии с 9.2.

Пример - Отображение атрибута sellByDate (предельная_Дата_Реализации) в заголовке EPCIS, документе мастер-данных или ответе на запрос мастер-данных:

<VocabularyElement «d=»urn:epc:class:lgtin:0614141.012345.L«23»> 2016-03-15

Отображение этого же атрибута в сегменте мастер-данных уровня экземпляра события:

<epcis:EPCISDocument xmlns:cbv«d=»urn:epcglobal:cbv:«da» ...> ... ... urn:epc:class:lgtin:0614141.012345.L123 ... cbvmd:sellByDate2016-03-15</cbvmd:sellByDate> ... ... </epcis:EPCISDocument>

9.2 Атрибуты мастер-данных предметов торговли

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

Значение столбца «Уровень» определяется следующим образом:

• предмет торговли: атрибутом мастер-данных является атрибут на уровне предметов торговли, как указано в разделе 9;
• серия: атрибутом мастер-данных является атрибут на уровне серии, как указано в разделе 9;
• экземпляр: атрибутом мастер-данных является атрибут на уровне экземпляра, как указано в разделе 9;
• предмет торговли или экземпляр: атрибутом мастер-данных является атрибут на уровне предмета торговли или атрибут на уровне экземпляра, как указано в разделе 9, в зависимости от предмета торговли. Например, netWeight (вес_Нетто) является атрибутом уровня предмета торговли для продукции с постоянным весом и атрибутом на уровне экземпляра для продукции с переменным весом;
• предмет торговли или серия или экземпляр: атрибутом мастер-данных является атрибут на уровне предмета торговли или атрибут на уровне серии или атрибут на уровне экземпляра, как указано в разделе 9, в зависимости от предмета торговли. Например, countryOfOrigin (страна_Происхождения) может быть одинаковым для всех экземпляров предмета торговли производимого товара или быть одинаковым для всех экземпляров определенной серии, но отличаться от серии к серии для рыбы, выловленной в территориальных водах различных юрисдикций, или отличаться для всех экземпляров рыбы, индивидуально выловленных в территориальных водах различных юрисдикций.

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

9.2.1 Атрибуты мастер-данных предметов торговли — уровень предмета торговли

Следующие атрибуты могут быть использованы для описания идентификатора предмета торговли на уровне предмета торговли (GTIN) (&см. таблицу 25&).

9.2.2 Атрибуты мастер-данных предметов торговли — уровень серии

Следующие атрибуты могут быть использованы для описания идентификатора предмета торговли на уровне серии (&см. таблицы 26 - 29&).

&Таблица 26&

Значение vesselCatchInformationList (перечень_Данных_по_Вылову_Судном) включает один или несколько элементов, называемых vesselCatchInformation (данные_по_Вылову_Судном), которые содержат следующие подэлементы (&см. таблицу 27&):

Значение farmList (перечень_Данных_Сельскохозяйственного_Предприятия) включает один или несколько элементов, называемых farm (сельскохозяйственное_Предприятие), которые содержат следующие подэлементы (&см. таблицу 28&):

&Таблица 28&

Перечень кодовых значений для поля farmIdentificationTypeCode (код_Типа_Идентификации_Сельскохозяйственного_Предприятия) (&см. таблицу 29&):

9.2.3 Атрибуты мастер-данных предметов торговли — уровень экземпляра

Следующие атрибуты могут быть использованы для описания идентификатора предмета торговли на уровне предмета торговли (уровне GTIN) (&см. таблицу 30&):

&Таблица 30&

9.2.4 Значения типа измерение

Каждое значение типа Measurement (Измерение) представляет собой структуру, состоящую из следующих подэлементов (&см. таблицу 31&):

&Таблица 31&

Пример - Когда значение типа Measurement (Измерение) появляется в мастер-данных уровня экземпляра, оно принимает представленную ниже форму. В данном примере атрибутом является netWeight (вес_Нетто) со значением 3,5 кг.

<cbvmd:netWeight measurementUnitCo«e=»«GM»>3.5</cbvmd:netWeight>

Когда значение типа Measurement (Измерение) появляется в документе мастер-данных EPCIS, в разделе мастер-данных заголовка документа EPCIS или в ответе на простой запрос мастер-данных EPCIS, оно принимает представленную ниже форму.

<measurement

measurementUnitCo>>e=«>>GM»>3.5

10 Мастер-данные места нахождения и участвующей стороны

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

Различные идентификаторы места нахождения могут обозначать место нахождения с различными уровнями детализации. Атрибуты мастер-данных, установленные в БДЛ, предназначены для использования в отношении места нахождения на двух различных уровнях детализации:

• производственная территория (site): Физическое место нахождения, где расположена структура или группа структур (и/или участков). Примеры производственных территорий: распределительный центр, предприятие розничной торговли, больница и т.д.;
• производственная площадка (sub-site): Определенное физическое место нахождения, входящее в состав производственной территории.

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

Документ, соответствующий или совместимый с БДЛ, МОЖЕТ включать любые атрибуты мастер-данных, указанные в настоящем подразделе, в сегменте мастер-данных заголовка EPCIS с учетом ограничений, установленных в других частях настоящего подраздела. Атрибуты мастер-данных, указанные в настоящем подразделе, также могут быть использованы в документе мастер-данных EPCIS или в ответе на запрос мастер-данных EPCIS. Документ, соответствующий БДЛ или совместимый с БДЛ, НЕ ДОЛЖЕН включать любые атрибуты мастер-данных, указанные в настоящем подразделе, в сегменте мастер-данных уровня экземпляра события EPCIS.

10.1 Наименования атрибутов мастер-данных места нахождения и участвующей стороны

В сегменте мастер-данных заголовка EPCIS, в документе мастер-данных EPCIS и в ответе на запрос мастер-данных EPCIS атрибут мастер-данных указывается в виде пары наименование/значение. Наименование каждого атрибута мастер-данных места нахождения/участвующей стороны, указанного в настоящем подразделе, состоит из следующего идентификатора пространства имен:

urn:epcglobal:cbv:mda,

за которым следует знак номер (#), за которым следует местное наименование, в соответствии с 10.2.

Атрибуты мастер-данных site (производственная территория), sst (тип_производственной_площадки), ssa (характеристики_производственной_площадки) и ssd (сведения_о_производственной_площадке) в виде исключения используют в качестве разделителя знак «двоеточие» (:) вместо знака номер (#), для обеспечения обратной совместимости с лексикой по &[4]& и более ранних версий.

10.2 Атрибуты мастер-данных места нахождения и участвующей стороны

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

Если в столбце «Использование» таблицы &32& для атрибута мастер-данных указывается «место нахождения» («location»), документ, соответствующий или совместимый с БДЛ, МОЖЕТ использовать данный атрибут для описания идентификатора, появляющегося в любом из следующих полей события EPCIS:

• начальный пункт, если типом начального пункта является location в соответствии с 7.4;
• конечный пункт, если типом конечного пункта является location в соответствии с 7.4.

Если в столбце «Использование» таблицы &32& для атрибута мастер-данных указывается «участвующая сторона» («party»), документ, соответствующий или совместимый с БДЛ, МОЖЕТ использовать данный атрибут для описания идентификатора, появляющегося в любом из следующих полей события EPCIS:

• начальный пункт, если типом начального пункта является owning_party (сторона_собственник) или possessing_party (сторона_держатель) в соответствии с 7.4,
• конечный пункт, если типом конечного пункта является owning_party (сторона_собственник) или possessing_party (сторона_держатель) в соответствии с 7.4.

Документ, соответствующий или совместимый с БДЛ, НЕ ДОЛЖЕН использовать атрибуты мастер-данных для описания идентификатора, за исключением разрешенных случаев, указанных выше.

10.3 Значения в перечне номеров мастер-данных места нахождения

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

10.3.1 Тип производственной площадки (Sub-Site Type)

Значением атрибута мастер-данных «тип производственной площадки» (Sub-Site Type) для идентификатора места нахождения, если он имеется, ДОЛЖНО быть одно из кодовых значений из таблицы &33&.

10.3.2 Характеристики производственной площадки (Sub-Site Attributes)

Значение атрибута мастер-данных «характеристики производственной площадки» (Sub-Site Attributes) для идентификатора места нахождения ДОЛЖНО быть равно нулю или кодовому значению из следующей таблицы &34&.

&Таблица 34

Когда значение атрибута мастер-данных «характеристики производственной площадки» передается как единая строка (в том числе, когда атрибут мастер-данных «характеристики производственной площадки» передается с использованием формы EPCISMasterDataDocument (Документ_Мастер-Данных_EPCIS), указанной в &ГОСТ Р 59167&), эта строка ДОЛЖНА состоять из кодовых значений, разделенных запятыми, без начальных, конечных или внутренних пробелов; кроме того, кодовые значения ДОЛЖНЫ представлять собой возрастающую числовую последовательность, считываемую слева направо.

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

11 Пример документации EPCIS

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

11.1 Соответствующее БДЛ событие объекта с использованием типового лексикона

Далее представлен документ EPCIS, соответствующий БДЛ, в формате XML, содержащий одно событие с объектом, где соответствующие БДЛ идентификаторы используются для бизнес-этапа и состояния, а номера EPC используются для всех значений пользовательского лексикона.

<epcis:EPCISDocument xmlns:epc«s=»urn:epcglobal:epcis:xs»:1» xmlns:x«i=»http://www.w3.org/2001/XMLSchema-insta«ce» creationDa«e=»2005-07-11T11:30:47«0Z» schemaVersi«n»«1»> 2007-07-26T21:41:19Z 2007-07-26T21:41:19Z -05:00 urn:epc:id:sgtin:0614141.181335.234 urn:epc:id:sgln:0614141.00300.1 urn:epc:id:sgln:0614141.00300.0 <bizTransaction ty«e=»urn:epcglobal:cbv:btt«po»>urn:epc:id:gdti:0614141.06012.1234 </epcis:EPCISDocument>

11.2 Соответствующее БДЛ событие объекта с использованием указателей HTTP URL и частных или общеотраслевых имен URN

Далее представлен документ EPCIS, соответствующий БДЛ, в формате XML, содержащий одно событие объекта, иллюстрирующий использование указателей HTTP URL и частных или общеотраслевых имен URN для значений пользовательского лексикона.

<epcis:EPCISDocument xmlns:epc«s=»urn:epcglobal:epcis:xs»:1» xmlns:x«i=»http://www.w3.org/2001/XMLSchema-insta«ce» creationDa«e=»2005-07-11T11:30:47«0Z» schemaVersi«n»«1»> 2007-07-26T21:41:19Z 2007-07-26T21:41:19Z -05:00 <e&pc>http://epcis.example.com/user/vocab/obj/12345.67890</&epc> urn:example:epcis:id:loc:warehouse23 http://epcis.example.com/user/vocabularies/loc/abc.12345 <bizTransaction ty«e=»urn:epcglobal:cbv:btt«po»>http://transaction.example.com/prodution/orde <bizTransaction <bizTransaction ty«e=»urn:epcglobal:cbv:btt:des«dv»>urn:epcglobal:cbv:bt:0614141000029:asn123 45 </epcis:EPCISDocument>

11.3 Событие, совместимое с БДЛ

Далее представлен документ EPCIS, совместимый с БДЛ, в формате XML, содержащий одно событие объекта. Соответствующие БДЛ идентификаторы EPC используются для физических объектов и мест нахождения, но поскольку для бизнес-этапов и состояний используются нетиповые идентификаторы, данный документ является совместимым с БДЛ, а не соответствующим БДЛ.

<epcis:EPCISDocument xmlns:epc«s=»urn:epcglobal:epcis:xs»:1» xmlns:x«i=»http://www.w3.org/2001/XMLSchema-insta«ce» creationDa«e=»2005-07-11T11:30:47«0Z» schemaVersi«n»«1»> 2007-07-26T21:41:19Z 2007-07-26T21:41:19Z -05:00 urn:epc:id:sgtin:0614141.181335.234 ADD urn:example:uservocab:bizstep:guarantined <dispositi&on>http://epcis.example.com/user/vocab/disp/contaminated</&dis urn:epc:id:sgln:0614141.00300.1 urn:epc:id:sgln:0614141.00300.0 </epcis:EPCISDocument>

11.4 Мастер-данные места нахождения

Далее представлен документ EPCIS с мастер-данными, иллюстрирующий использование атрибутов мастер-данных места нахождения, установленных в 8.6.

<epcismd:EPCISMasterDataDocument xmlns:epcis«d=»urn:epcglobal:epcis-masterdata:xs»:1» xmlns:x«i=»http://www.w3.org/2001/XMLSchema-insta«ce» schemaVersi«n»«1» creationDa«e=»2005-07-11T11:30:47«0Z»>

<Vocabulary ty«e=»urn:epcglobal:epcis:vtype:ReadPo«nt»> <VocabularyElement «d=»urn:epc:id:sgln:0614141.0030».0«> <attribute „d=“urn:epcglobal:cbv:mda:s»te«>0614141003006 <VocabularyElement „d=“urn:epc:id:sgln:0614141.0030».1«> <attribute „d=“urn:epcglobal:cbv:mda:s»te«>0614141003006»

       208</attribute>

       422</attribute>
       Line #1 at Manufacturing

Plant 1 <VocabularyElement «d=»urn:epc:id:sgln:0614141.0030».2«> <attribute „d=“urn:epcglobal:cbv:mda:s»te«>0614141003006»

       251</attribute>

       416,417</attribute>
    </VocabularyElement>
  </VocabularyElementList>
</Vocabulary>

&БИБЛИОГРАФИЯ& <1>

<1> Раздел 12 «Ссылки» ИСО/МЭК 19988:2017 переименован в «Библиографию». В квадратных скобках приведены порядковые номера ссылочных документов для ссылок в тексте настоящего стандарта.

<2> Ссылка на данный документ включена дополнительно в связи с ее отсутствием в разделе 12 «Ссылки» ИСО/МЭК 19988:2017.

<3> Ссылка на данный документ включена дополнительно в связи с ее отсутствием в разделе 12 «Ссылки» ИСО/МЭК 19988:2017.

<4> Действует ГОСТ 7.67-2003 Система стандартов по информации, библиотечному и издательскому делу. Коды названий стран, модифицированный по отношению к ИСО 3166-1:1997.

<5> Действует ГОСТ 7.75-97 Система стандартов по информации, библиотечному и издательскому делу. Коды наименований языков, модифицированный по отношению к ИСО 639:1988.

Приложение ДА (справочное)

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

Перечень сокращений, использованных в настоящем стандарте, приведен в таблице ДА.1.

Таблица ДА.1

Приложение ДБ (справочное)

ПЕРЕЧЕНЬ ИЗМЕНЕНИЙ НАСТОЯЩЕГО СТАНДАРТА ОТНОСИТЕЛЬНО [1] С ПОЯСНЕНИЯМИ НЕОБХОДИМОСТИ ИХ ВНЕСЕНИЯ

В [1] отсутствует нумерация таблиц. В связи с этим для применения ссылок и удобства пользования всем таблицам в настоящем стандарте присвоены порядковые номера. Сведения о соответствующих изменениях приведены в таблице ДБ.1.

Приложение ДВ (рекомендуемое)

ПРИМЕРНЫЙ ПОРЯДОК СЛЕДОВАНИЯ БИЗНЕС-ЭТАПОВ В ЦЕПИ ПОСТАВОК

В 7.1.3 в таблице 1 приведены бизнес-этапы в алфавитном порядке. В таблице ДВ.1 указанные бизнес-этапы систематизированы по функциональному признаку следования в цепи поставок.

Таблица ДВ.1