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

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

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

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

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 19988:2017 "Информационные технологии. Стандарт базовой деловой лексики" (ISO/IEC 19988:2017 "Information technology - Core Business Vocabulary Standard", MOD) путем включения раздела "Введение", переименования раздела 1 в "Область применения", перевода раздела "12 Ссылки" в "Библиографию", введения нумерации таблиц и ссылок на пронумерованные таблицы, замены ссылок на международные документы на порядковые номера, приведенные в "Библиографии". В дополнительном приложении ДА приведен перечень сокращений, использованных в настоящем стандарте. Изменения, включенные в текст стандарта, выделены в тексте курсивом и подчеркиванием. Сноски в тексте настоящего стандарта, выделенные курсивом, приведены для пояснения его содержания. Подробная информация об изменениях и пояснения по необходимости их внесения приведена в дополнительном приложении ДБ. В приложении ДВ указан рекомендуемый примерный порядок следования бизнес-этапов в цепи поставок

5 ВВЕДЕН ВПЕРВЫЕ

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

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

- аннотацию к документу &[2]&,

- протокол изменений в &[2]&,

- отказ от ответственности.

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

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

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

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

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

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

--------------------------------

<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 и применяемых в широком наборе бизнес-сценариев, используемых во многих отраслях, где требуется обмен данными. Настоящий стандарт предназначен для предоставления набора значений и определений, которые будут одинаково пониматься всеми участниками цепи поставок.

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

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

- идентификаторы бизнес-этапов;

- идентификаторы состояний;

- типы документов бизнес-транзакций;

- типы начальных/конечных пунктов;

- идентификаторы причин ошибок.

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

- объектов;

- мест нахождения;

- бизнес-транзакций;

- идентификаторов начальных/конечных пунктов;

- идентификаторов преобразований;

- идентификаторов событий.

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

- место нахождения производственной территории;

- тип производственной площадки;

- характеристики производственной площадки;

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

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

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

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

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

- параметр "что" ("what"): Параметр "что" для большинства типов событий содержит один или несколько уникальных идентификаторов физических или цифровых объектов или классов физических или цифровых объектов. Идентификаторы физических или цифровых объектов в базовой деловой лексике определены в 8.2 (уровень экземпляра) и 8.3 (уровень класса). В случае события преобразования EPCIS (TransformationEvent) можно использовать необязательный идентификатор преобразования (TransformationID) для связи нескольких событий, описывающих одно и то же преобразование. Базовая деловая лексика включает в себя идентификаторы преобразования (TransformationID) (см. 8.7);

- параметр "когда" ("when"): Момент времени, когда произошло событие EPCIS. Время события полностью устанавливается в &ГОСТ Р 59167&;

- параметр "где/куда" ("where"): Параметр "где/куда" состоит из двух идентификаторов, описывающих разные аспекты места, где произошло событие:

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

--------------------------------

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

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

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

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

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

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

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

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

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

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

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

Типовым лексиконом называют набор лексических элементов, определения и значения которых должны быть заранее согласованы торговыми партнерами, которые будут обмениваться данными о событиях с использованием лексикона. Например, в &ГОСТ Р 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:

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

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

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

Указанный идентификатор присвоен конечным пользователем с префиксом предприятия 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).

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

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

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

- записи ПРОПИСНЫМИ БУКВАМИ используются для специальных терминов, приведенных из вышеуказанного документа &[8]&;

- шрифт Courier используется для выделения идентификаторов на языке программирования, унифицированном языке моделирования (UML) и расширяемом языке разметки (XML), а также в тексте XML-документов <1>;

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

--------------------------------

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

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

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

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

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

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

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

"Документ, соответствующий БДЛ" (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, с включением или без опционального добавочного компонента, используемая для идентификации физического места нахождения.

"Документ, совместимый с БДЛ (англ. "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 (бизнес-этап), тогда как это поле обязательно требуется в документах, соответствующих БДЛ.

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

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

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

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

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

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

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

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

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

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

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

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

--------------------------------

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

Любое событие 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) из базовой деловой лексики:

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

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

<1> ASN - сокращение от "advanced shipping notice" (предварительное уведомление об отгрузке).

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

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

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

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

Любое событие 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" (в процессе выполнения):

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

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

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

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" (подлежащее реализации), даже при отсутствии дефектов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Любое событие 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, которые запрещены настоящим стандартом или предназначены для других целей.

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

В отличие от типовых лексиконов, которые рассматривались в разделе 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 несколько ограничены в плане синтаксиса (например, ограничения допустимого набора знаков и числа знаков), и их не всегда легко приспособить к созданию идентификаторов на основе кодов, которые уже используются в существующих системах компаний. Прочие формы предлагают альтернативные способы.

В случае применения идентификаторов 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.2 - 8.5, документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частное и общеотраслевое имя URN, как указано ниже.

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

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

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

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

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

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

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

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

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

Идентификаторы на уровне экземпляра физических или цифровых объектов заполняют параметр "что" в событиях 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 определены варианты структуры идентификатора для идентификации объектов на уровне класса.

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать чистый ключевой идентификатор 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).

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные или общеотраслевые имена 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, ДОЛЖНЫ принимать следующий вид:

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

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

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

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель 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.

Идентификаторы на уровне класса физических или цифровых объектов заполняют параметр "что" в событиях 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, если нет веских причин поступить по-другому.

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

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать частные или общеотраслевые имена 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.

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель 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, ДОЛЖЕН принимать следующий вид:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать указатель 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.

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать идентификатор 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 географического места нахождения.

Идентификаторы документов бизнес-транзакций заполняют параметр "на каком основании" событий 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. (Обеспечивается совместимость с БДЛ, но не соответствие БДЛ).

Документ, совместимый с БДЛ, или документ, соответствующий БДЛ, МОЖЕТ использовать чистый ключевой идентификатор 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настоящий раздел устанавливает атрибуты мастер-данных, которые могут быть использованы для описания идентификатора предмета торговли, присутствующего в параметре "что" события EPCIS, включая поля EPC, идентификатора родителя (parentID), EPC на уровне класса (EPC Class). Различные идентификаторы предметов торговли используются на разных уровнях идентификации предметов торговли. Любой атрибут мастер-данных, определенный в БДЛ для идентификаторов предметов торговли, устанавливает один или несколько из следующих трех уровней идентификации, которые применимы для данного случая (&см. таблицу 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 (Элемент_Количество) в рамках данного события.

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

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

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

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

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

- предмет торговли: атрибутом мастер-данных является атрибут на уровне предметов торговли, как указано в разделе 9;

- серия: атрибутом мастер-данных является атрибут на уровне серии, как указано в разделе 9;

- экземпляр: атрибутом мастер-данных является атрибут на уровне экземпляра, как указано в разделе 9;

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

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

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

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

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

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

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

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

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

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

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

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

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

- производственная площадка (sub-site): Определенное физическое место нахождения, входящее в состав производственной территории.

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

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

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

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

В таблице &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.

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

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

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

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

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

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

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

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

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

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

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

--------------------------------

<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.

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