Методика описания требований к электронному виду документов

(утв. Коллегией Евразийской экономической комиссии)

(вместе с «Техническими требованиями к формированию описания формата и структуры электронного вида документа», «Техническими требованиями к перечню правил формирования реквизитов электронного вида документа»)

МЕТОДИКА ОПИСАНИЯ ТРЕБОВАНИЙ К ЭЛЕКТРОННОМУ ВИДУ ДОКУМЕНТОВ

I. Общие положения

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

2. Для целей настоящей Методики используются понятия, которые означают следующее:

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

«графа документа» — часть документа на бумажном носителе, в виде отдельного раздела (пункта), имеющая номер и (или) наименование;

«диапазон значений» — множество возможных значений определенного типа;

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

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

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

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

«структура электронного вида документа» — состав реквизитов электронного вида с указанием их иерархических связей;

«техническая схема» — описание структуры документа на формальном языке, например, на языке описания XML Schema;

«шаблон» — строка-образец, устанавливающая ограничение лексического пространства значений реквизита (атрибута);

«XML-документ» — совокупность данных, соответствующая требованиям расширяемого языка разметки XML (eXtensible Markup Language), рекомендованного Консорциумом Всемирной паутины (W3C);

«XML-схема» — описание структуры документа, приведенное на языке XML Schema;

«XML Schema» — язык описания структуры XML-документа, позволяющий описать структуру и ограничения содержимого документа в формате XML;

«XSLT-преобразование» — программный код, написанный на расширяемом языке преобразований таблиц стилей XSLT (eXtensible Stylesheet Language Transformations), предназначенный для выполнения преобразований документов, представленных в формате XML.

Иные понятия, используемые в настоящей Методике, применяются в значениях, определенных Договором о Евразийском экономическом союзе от 29 мая 2014 г. (далее — Договор о Союзе), Таможенным кодексом Евразийского экономического союза (далее — Кодекс), а также в значениях, определенных Методикой анализа, оптимизации, гармонизации и описания общих процессов, утвержденной Решением Коллегии Евразийской экономической комиссии от 9 июня 2015 г. № 63 (далее — Методика анализа) и Положением о Модели данных Евразийского экономического союза, утвержденным Решением Коллегии Евразийской экономической комиссии от 26 декабря 2017 г. № 190 (далее — Положение о модели данных Союза).

3. Настоящая Методика может быть использована:

Евразийской экономической комиссией (далее — Комиссия) и уполномоченными органами государств — членов Евразийского экономического союза (далее соответственно — уполномоченные органы государств-членов, государства-члены) при разработке требований к электронному виду документов;

заинтересованными лицами при формировании электронного вида документов.

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

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

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

5. Требования к электронному виду документов, разработанные в соответствии с настоящей Методикой, включают в себя:

требования к структуре электронного вида документа;

требования к формированию реквизитов структуры электронного вида документа.

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

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

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

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

взаимосвязи сведений, указанных в нескольких реквизитах одного документа;

соответствия информации, указанной в реквизитах документов информации, содержащейся в других информационных ресурсах.

8. Требования к электронному виду документов, разработанные в соответствии с настоящей Методикой, подлежат применению:

заинтересованными лицами при формировании электронного вида документов;

уполномоченными органами государств-членов при формировании электронного вида документов и (или) проведении контроля электронного вида документа.

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

10. Действие настоящей Методики не распространяется на формирование требований к электронным сообщениям, в составе которых передаются электронные документы.

II. Основные принципы и этапы разработки требований к электронному виду документов

11. Основными принципами разработки требований к электронному виду документов являются:

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

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

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

12. Комплекс работ по разработке требований к электронному виду документов включает следующие этапы:

разработка требований к структуре электронного вида документа,

разработка требований к формированию реквизитов электронного вида документа.

13. Разработка требований к структуре электронного вида документа включает следующие этапы:

разработка (доработка) и описание структуры электронного вида документа,

разработка технических схем электронного вида документа.

14. Разработка требований к формированию реквизитов электронного вида документа включает следующие этапы:

разработка правил формирования реквизитов структуры электронного вида документа,

описание набора разработанных правил,

формализация разработанных правил.

1. Разработка требований к структуре электронного вида документа

15. Разработка (доработка) структуры электронного вида документа включает в себя:

анализ требований к электронному виду документа;

доработку (создание) структуры электронного вида документа;

формирование описания структуры электронного вида документа;

разработку технических схем электронного вида документа.

16. Разработка (доработка) структуры электронного вида документа осуществляется в соответствии с требованиями Методики анализа и Положения о модели данных Союза.

17. Технические требования к форме описания структуры электронного вида документа приведены в Приложении 1 к настоящей Методике. Формирование описания структуры электронного вида документа осуществляется с учетом требований Методики анализа.

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

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

19. Разработка и описание правил формирования реквизитов структуры электронного вида документов (далее — правила формирования) осуществляется в соответствии с настоящей Методикой на основе права Союза и (или) законодательства государств-членов.

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

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

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

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

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

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

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

принцип атомарности, в соответствии с которым правила должны быть максимально декомпозированы на более простые правила, пока это не противоречит остальным принципам.

22. Разработка каждого правила формирования включает:

определение вида правила в соответствии с требованиями, приведенными в подразделе 1 раздела IV;

присвоение правилу уникального кода в соответствии с требованиями, приведенными в подразделе 2 раздела IV;

определение реквизита целевого (атрибута), к которому относится правило в соответствии с требованиями, приведенными в подразделе 3 раздела IV;

описание ссылок на реквизиты (атрибуты) в соответствии с требованиями, приведенными в подразделе 4 раздела IV;

формулирование правила в соответствии с видом правила и требованиями, приведенными в подразделах 5 - 10 раздела IV;

спецификацию правила в соответствии с требованиями, приведенными в разделе III.

23. После разработки всех правил совокупность правил проверяется на соответствие принципам, приведенным в пунктах 11 и 20 настоящего раздела.

24. Описание совокупности правил осуществляется в соответствии с техническими требованиями, приведенными в Приложении 3 к настоящей Методике.

25. Формализация совокупности правил осуществляется в соответствии с требованиями, приведенными в разделе V.

3. Утверждение и ввод в действие требований к электронному виду документов

26. Требования к электронному виду документов, оформленные в виде описаний структур и правил формирования реквизитов структуры электронного вида документа, разработанные Комиссией, утверждаются в виде решений, распоряжений или рекомендаций Комиссии в соответствии с регламентом ее работы.

27. Требования к электронному виду документов, утвержденные Комиссией, подлежат публикации на информационном портале Союза.

4. Применение разработанных требований к электронному виду документов

28. Применение требований при формировании и проверке электронного вида документов осуществляется в соответствии с рекомендациями, приведенными в разделе VI.

III. Требования к спецификации правил формирования реквизитов электронного вида документа

29. Требования к спецификации правил формирования реквизитов электронного вида документа приведены в Приложении 2 к настоящей Методике.

30. Требования по представлению перечня правил формирования реквизитов электронного вида документа приведены в Приложении 3 к настоящей Методике.

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

IV. Технические требования к разработке и описанию правил формирования реквизитов электронного вида документа

1. Классификация правил

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

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

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

реквизит должен быть заполнен

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

заинтересованное лицо должно указать организационно-правовую форму организации

34. В зависимости от уровня нормативного регулирования выделяются следующие виды правил:

общее правило — правило, которое устанавливается правом Союза и обязательно к применению во всех государствах-членах;

частное правило — правило, которое устанавливается правом Союза и определяет особенности заполнения реквизита в государстве-члене;

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

35. В зависимости от формы требований правила подразделяются на обязывающие и запрещающие.

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

реквизит должен быть заполнен

или:

заинтересованное лицо должно указать организационно-правовую форму организации

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

реквизит не должен использоваться

или:

заинтересованное лицо не должно указывать организационно-правовую форму организации

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

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

реквизит должен быть заполнен

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

если реквизит «Код вида документа» (csdo:DocKindCode) содержит значение «09999», то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен

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

если реквизит «Код вида документа» (csdo:DocKindCode) содержит значение «09999», то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен, иначе реквизит не должен использоваться

37. В зависимости от количества требований в утвердительной части правила требования подразделяются на правила с простой утвердительной частью и правила с составной утвердительной частью. Требования могут быть связаны между собой операторами конъюнкции («и») или дизъюнкции («или»). Например:

реквизит не должен использоваться или реквизит должен содержать значение «другое»

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

если реквизит «Код вида адреса» (csdo:AddressKindCode) содержит значение «1» — адрес регистрации, то реквизит «Город» (csdo:CityName) должен быть заполнен и реквизит «Почтовый индекс» (csdo:PostCode) не должен использоваться

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

если реквизит «Код вида адреса» (csdo:AddressKindCode) содержит значение «1» — адрес регистрации, то реквизит «Город» (csdo:CityName) должен быть заполнен

и:

если реквизит «Код вида адреса» (csdo:AddressKindCode) содержит значение «1» — адрес регистрации, то реквизит «Почтовый индекс» (csdo:PostCode) не должен использоваться

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

38. В зависимости от количества условий в условной части правила требования подразделяются на правила с простой условной частью и правила с составной условной частью. Условия могут быть связаны между собой операторами конъюнкции («и») или дизъюнкции («или»). Например:

если реквизит «Код вида документа» (csdo:DocKindCode) содержит значение «09999» и номер указываемого документа соответствует шаблону «ТТТТТТТТ/ДДММГГ/ННННННН/РР», где ТТТТТТТ — код таможенного органа (2, 5 или 8 знаков), ДДММГГ — дата регистрации документа, ННННННН — номер документа по журналу регистрации, РР — порядковый номер изменений и (или) дополнений (элемент РР может отсутствовать), то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен

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

если реквизит «Код вида документа» (csdo:DocKindCode) содержит значение «09999» или реквизит «Признак наличия или отсутствия информации» (casdo:InformationUnknownIndicator) имеет значение «1», то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен

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

если реквизит «Код вида документа» (csdo:DocKindCode) содержит значение «09999», то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен

и:

если реквизит «Признак наличия или отсутствия информации» (casdo: InformationUnknownIndicator) содержит значение «1», то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен

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

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

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

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

в) прикладные правила, которые определяют смысловое содержимое реквизита в соответствии со справочниками, классификаторами, словарями, глоссариями и прочими источниками прикладного смысла;

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

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

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

41. Структурные правила подлежат формализации и автоматизации в соответствии с настоящей Методикой и формулируются в соответствии с рекомендациями, приведенными в подразделах 5 - 10 настоящего раздела в зависимости от специфики требований к информации.

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

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

43. При кодировании правил применяется фасетный метод кодирования. При кодировании применяются правила, приведенные в разделе VIII Методики анализа, с учетом положений настоящего подраздела.

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

44. Код правила содержит следующие фасеты и группы фасетов кодового обозначения:

первый фасет принимает значение «B», которое определяет принадлежность объекта кодирования к правилам формирования реквизитов электронного вида документов;

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

третий фасет содержит кодовое обозначение структуры электронного вида документа;

четвертый фасет содержит 5-значный порядковый номер правила, начиная с «00001».

3. Определение целевого реквизита (атрибута) правила

45. Целевым реквизитом (атрибутом) правила с простой утвердительной частью является реквизит (атрибут), требования к заполнению которого оно формулирует. Например, следующее правило относится к реквизиту «Код электронного документа» (csdo:EDocCode):

реквизит «Код электронного документа» (csdo:EDocCode) должен быть заполнен

46. Если правило с составной утвердительной частью формулирует требования к заполнению единственного реквизита (атрибута), то последний является целевым реквизитом (атрибутом) правила. Например, следующее правило относится к реквизиту «Код электронного документа» (csdo:EDocCode):

реквизит «Код электронного документа» (csdo:EDocCode) должен быть заполнен и должен содержать значение «R.035»

47. Если правило с составной утвердительной частью формулирует требования к заполнению более чем одного реквизита (атрибута), то в качестве целевого реквизита (атрибута) правила необходимо выбрать один из них, либо использовать их общий родительский реквизит. Если таковой отсутствует, то целевым реквизитом является корневой реквизит структуры электронного вида документа. Например, для следующего правила в качестве целевого реквизита может быть выбран реквизит «Дата выпуска» (casdo:GoodsIssueDate), либо корневой реквизит структуры документа «Сведения в отношении автомобилей, ввезенных и выпущенных для внутреннего потребления (в свободное обращение)» (R.CA.CP.05.001):

значение реквизита «Дата выпуска» (casdo:GoodsIssueDate) должно быть не менее значения реквизита «Дата документа» (csdo:DocCreationDate) в составе реквизита «Регистрационный номер таможенной декларации» (cacdo:CustomsDeclarationIdDetails)

4. Описание ссылок на реквизиты (атрибуты) документа

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

значение реквизита должно соответствовать шаблону «YYYY-MM-DD»

49. Название нецелевого реквизита правила указывается следующим образом:

«[прикладной термин]» ([префикс пространства имен]:[конструкция UML]),

где «прикладной термин», «префикс пространства имен» и «конструкция UML» — это свойства элемента данных, соответствующего реквизиту, которые определенны в Положении о модели данных Союза.

Например:

«Дата документа» (csdo:DocCreationDate)

50. Название нецелевого атрибута правила указывается следующим образом:

«[прикладной термин]» ([конструкция UML]),

где «прикладной термин» и «конструкция UML» — это свойства контекстной характеристики, соответствующей атрибуту, которые определены в Положении о модели данных Союза.

Например:

«Идентификатор классификатора» (codeListId)

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

атрибут [название атрибута] реквизита [название реквизита].

Например:

атрибут «Идентификатор справочника (классификатора)» (measurementUnitCodeListId) реквизита «Количество товара с указанием единицы измерения» (casdo:GoodsMeasure)

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

реквизит [название реквизита] в составе реквизита [название реквизита] в составе реквизита [название реквизита]...

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

Например, для реквизита «Описание транспортного средства» (casdo:VehicleDescriptionText) определено правило:

если реквизит «Код страны» (csdo:UnifiedCountryCode) принимает значение «KZ» и значение реквизита «Дата документа» (csdo:DocCreationDate) в составе реквизита «Регистрационный номер таможенной декларации» (cacdo:CustomsDeclarationIdDetails) не менее 01 января 2004 года и не более 31 декабря 2010 года, то реквизит «Описание транспортного средства» (casdo:VehicleDescriptionText) должен быть заполнен

Указанное правило ссылается в условной части на реквизиты «Код страны» (csdo:UnifiedCountryCode) и «Дата документа» (csdo:DocCreationDate), при этом:

реквизит «Код страны» (csdo:UnifiedCountryCode) находится на том же уровне вложенности, что и целевой реквизит правила «Описание транспортного средства» (casdo:VehicleDescriptionText), поэтому родительский реквизит не указывается;

реквизит «Дата документа» (csdo:DocCreationDate) не является вложенным в реквизит «Описание транспортного средства» (casdo:VehicleDescriptionText), не находится с ним на одном уровне вложенности, а также используется более одного раза в структуре электронного вида документа, поэтому для его однозначной идентификации требуется указание родительского реквизита «Регистрационный номер таможенной декларации» (cacdo:CustomsDeclarationIdDetails).

5. Общие требования по формулированию правил

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

54. Типовые формулировки правил представляют собой шаблонный текст, содержащий поля подстановки, заключаемые в квадратные скобки «[» и «]».

При формулировании правила шаблонный текст приводится без изменений, поля подстановки заменяются на значения соответствующих полей. Например, на основе типовой формулировки «атрибут должен содержать значение „[код]“ — [описание кода]» может быть сформулировано правило:

атрибут должен содержать значение «214» — киловатт

55. При необходимости шаблонный текст склоняется в соответствии с правилами русского языка. Например, на основе типовой формулировки «должно быть заполнено [в точности, не менее, не более] [количество] экземпляров реквизита» могут быть сформулированы следующие правила:

должно быть заполнено не менее 1 экземпляра реквизита

или:

должно быть заполнено не менее 2 экземпляров реквизита

56. Формулировка правила начинается со строчной буквы. В конце формулировки знаки препинания не ставятся.

57. Для числительных используется цифровая форма написания. Например:

значение реквизита должно быть не менее 0 и не более 1000

58. Если поле подстановки содержит более одного варианта подстановки, указанных через вертикальную черту, то при формулировании правила может быть выбран любой из указанных вариантов. Например, при формулировании правила на основе типовой формулировки «[значение] должно быть [равно | не равно | менее | не менее | более | не более] [значение]» могут быть сформулированы следующие правила:

значение реквизита должно быть более 0

или

значение реквизита должно быть менее 1000

59. Если типовая формулировка содержит повторяемое поле подстановки, то при формулировании правила указывается необходимое количество значений данного поля. Между предпоследним и последним значениями поля используется разделитель, указанный в типовой формулировке между вторым и третьим вхождением поля подстановки. Между остальными значениями поля используется разделитель, указанный в типовой формулировке между первым и вторым вхождением поля подстановки. Например, на основе следующей типовой формулировки «должно быть заполнено [в точности | не менее | не более] [количество] из реквизитов: [реквизит], [реквизит] и [реквизит]» может быть сформулировано правило

должно быть заполнено не менее 1 из реквизитов: «Идентификационный номер транспортного средства» (csdo:VehicleId), «Идентификационный номер шасси (рамы) транспортного средства» (csdo:VehicleChassisId), «Идентификационный номер кузова транспортного средства» (csdo:VehicleBodyId) и «Регистрационный номер транспортного средства» (cacdo:TransportMeansRegId)

60. Обязывающие или запрещающие безусловные правила формулируются с использованием типовых формулировок, приведенных далее в подразделах данного раздела. Например:

реквизит должен быть заполнен

61. Обязывающие или запрещающие условные правила формулируются на основе формулировок для безусловных правил в виде «если [условие], то [утверждение]» или «если [условие], то [утверждение 1], иначе [утверждение 2]». Например:

если реквизит «Код вида документа» (csdo:DocKindCode) содержит значение «09013», то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен

или:

если реквизит «Код вида документа» (csdo:DocKindCode) содержит значение «09999» и номер указываемого документа соответствует шаблону «ТТТТТТТТ/ДДММГГ/ННННННН/РР», где ТТТТТТТ — код таможенного органа (2, 5 или 8 знаков), ДДММГГ — дата регистрации документа, ННННННН — номер документа по журналу регистрации, РР — порядковый номер изменений и (или) дополнений (элемент РР может отсутствовать), то реквизит «Регистрационный номер таможенного документа» (cacdo:CustomsDocIdDetails) должен быть заполнен, иначе реквизит не должен использоваться

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

реквизит должен быть заполнен

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

6. Требования к формулированию правил формирования реквизитов структур электронного вида документов

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

64. Правила, которые определяют обязательность (необязательность) заполнения реквизита (атрибута), имеют формулировки следующего вида:

[реквизит | атрибут] должен быть заполнен — для обязывающих правил;

[реквизит | атрибут] не должен использоваться — для запрещающих правил.

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

[реквизит | атрибут] заполнен;

[реквизит | атрибут] не заполнен.

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

должно быть заполнено [в точности | не менее | не более] [количество] экземпляров [реквизит];

должно быть заполнено не менее [количество] и не более [количество] экземпляров [реквизит];

должно быть заполнено [в точности | не менее | не более] [количество] из [реквизитов | атрибутов]: [реквизит | атрибут], [реквизит | атрибут] и [реквизит | атрибут].

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

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

должен быть заполнен в точности 1 из реквизитов «Район» (csdo:DistrictName) и «Город» (csdo:CityName)

7. Требования по формулированию форматных (синтаксических) правил

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

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

значение [реквизит | атрибут] должно быть [равно | не равно | менее | не менее | более | не более] [значение];

значение [реквизит | атрибут] должно быть [не менее | более] [значение] и [менее | не более] [значение].

Например:

значение реквизита должно быть более 0

68. Правила, определяющие ограничения на допустимую длину содержимого реквизита (атрибута), имеют формулировки следующего вида:

длина [реквизит | атрибут] должна быть [равна | менее | не менее | более | не более] [количество] символов;

длина [реквизит | атрибут] должна быть [не менее | более] [количество] и [менее | не более] [количество] символов.

Например:

длина реквизита должна быть не более 100 символов

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

значение [реквизит | атрибут] должно соответствовать шаблону: [регулярное выражение].

Регулярные выражения указываются в соответствии со спецификацией XML-схемы Консорциума Всемирной паутины (W3C XML Schema, Опубликован по адресу http://www.w3.org/TR/xmlschema-2/.

Например:

значение реквизита должно соответствовать шаблону: [0-9a-fA-F]{8}(-[0-9a- fA-F]{4}){3}-[0-9a-fA-F]{12}

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

значение [реквизит | атрибут] должно соответствовать шаблону [шаблон], где [фрагмент шаблона] — [описание фрагмента шаблона], [фрагмент шаблона] — [описание фрагмента шаблона]. [Дополнительные пояснения].

Например:

значение реквизита должно соответствовать шаблону ТТТТТТТТ/ДДММГГ/ННННННН/РР, где ТТТТТТТТ — код таможенного органа (2, 5 или 8 знаков), ДДММГГ — дата регистрации документа (ДД — порядковый номер дня месяца, ММ — порядковый номер месяца, ГГ — последние две цифры года), ННННННН — номер документа по журналу регистрации, РР — порядковый номер изменений и (или) дополнений (элемент РР может отсутствовать)

71. Правила, определяющие ограничения на допустимое фиксированное значение реквизита (атрибута), имеют формулировки следующего вида:

[реквизит | атрибут] должен содержать значение «[значение]»;

[реквизит | атрибут] должен содержать значение «[код]» — [описание кода].

Например:

реквизит должен содержать значение «другое»

или:

атрибут должен содержать значение «214» — киловатт

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

[реквизит | атрибут] должен содержать одно из следующих значений: «[значение]», «[значение]», «[значение]»;

[реквизит | атрибут] должен содержать одно из следующих значений:

«[код]» — [описание кода];

«[код]» — [описание кода];

«[код]» — [описание кода].

Например:

реквизит должен содержать одно из следующих значений: «электронная почта», «телефон»

или

реквизит должен содержать одно из следующих значений:

EM — электронная почта;

TE — телефон

8. Требования по формулированию правил взаимосвязанности

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

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

[значение] должно быть [равно | не равно | менее | не менее | более | не более] [значение];

[значение] должно быть [не менее | более] [значение] и [менее | не более] [значение].

При этом [значение] может формулироваться одним из следующих способов:

[фиксированное значение];

значение [реквизит | атрибут];

длина [реквизит | атрибут];

сумма [значение], [значение] и [значение].

Например:

значение реквизита «Дата выпуска» (casdo:GoodsIssueDate) должно быть не менее значения реквизита «Дата документа» (csdo:DocCreationDate) в составе реквизита «Регистрационный номер таможенной декларации» (cacdo:CustomsDeclarationIdDetails)

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

значение [реквизит | атрибут] должно быть уникальным в [реквизит];

значение [реквизит | атрибут] должно быть уникальным в документе.

Например:

значение реквизита «Номер приложения/перечня» (casdo:AppOrdinal) должно быть уникальным в документе

76. Правила взаимосвязанности, используемые для описания требований к ссылкам на другие реквизиты (атрибуты), имеют формулировки следующего вида:

[реквизит | атрибут] должен содержать [наименование номера, кода, идентификатора] из [реквизит | атрибут];

[реквизит | атрибут] должен содержать порядковый номер [реквизит | атрибут] в [реквизит];

[реквизит | атрибут] должен содержать порядковый номер [реквизит | атрибут] в документе.

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

Например:

реквизит должен содержать порядковый номер реквизита «Предшествующий документ» (cacdo:PrecedingDocDetails) в реквизите «Товар» (cacdo:CPCGoodsItemDetails)

9. Требования по формулированию прикладных правил

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

78. Прикладные правила имеют формулировки следующего вида:

[реквизит | атрибут] должен содержать [наименование номера, кода, идентификатора] в соответствии с [наименование источника прикладного смысла];

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

Например:

атрибут должен содержать буквенный код валюты в соответствии с классификатором, идентификатор которого указан в атрибуте «Идентификатор классификатора» (currencyCodeListId)

10. Требования по формулированию правил соответствия

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

80. Правила соответствия имеют формулировки следующего вида:

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

Условия имеют формулировки следующего вида:

поле [наименование поля] [заполнено | не заполнено];

значение поля [наименование поля] [равно | не равно | менее | не менее | более | не более] [значение].

Например:

в реестре предприятий Союза должна существовать запись, в которой значение поля «Регистрационный номер предприятия» равно значению реквизита «Регистрационный номер предприятия» (smsdo:VeterinaryOrganizationId) и поле «Конечная дата и время» не заполнено

V. Требования по формализации правил формирования электронного вида документов

81. Формализация правил осуществляется с использованием объектного языка ограничений (Object Constraint Language, OCL), рекомендованного консорциумом Object Management Group для описания логических ограничений, накладываемых на объектные модели.

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

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

1. Общие требования по формализации правил

84. Числовые значения в правилах формализуются как числа, записанные в десятичной системе счисления. В качестве разделителя целой и дробной частей числа используется точка («.»).

85. Строковые (текстовые, кодовые) значения в правилах формализуются как последовательности символов, заключенных в одинарные кавычки («'»).

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

DateType::new('YYYY-MM-DDV')

TimeType::new('HH:mm:ssV')

DateTimeType::new('YYYY-MM-DDTHH:mm:ssV')

YearType::new('YYYY')

YearMonthType::new('YYYY-MM')

MonthType::new('--MM')

MonthDayType::new('--MM-DD')

DayType::new('--DD')

где «::» — обращение к операции, определенной для типа данных, который указан перед данной последовательностью символов, new — наименование операции, используемой для создания значений данного типа, YYYY — год, MM — месяц, DD — день, HH — часы, mm — минуты, ss — секунды, V — часовой пояс, T — разделитель даты и времени, «-» — разделитель компонентов даты, «:» — разделитель компонентов времени.

Часовой пояс принимает одно из следующих значений: Z — всемирное координированное время, +HH:mm — положительное смещение относительно всемирного координированного времени, -HH:mm — отрицательное смещение относительно всемирного координированного времени. Часовой пояс может не указываться.

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

DurationType::new('-P[0-9]+Y[0-9]+M[0-9]+DT[0-9]+H[0-9]+M[0-9]+S')

где «-» — это опциональный индикатор отрицательной продолжительности времени, P — индикатор продолжительности времени, T — разделитель компонентов продолжительности времени в годах, месяцах и днях с одной стороны и в часах, минутах и секундах с другой, «[0-9]+» — последовательность десятичных цифр, Y — индикатор компонента продолжительности времени в годах, M — индикатор компонента продолжительности времени в месяцах (если используется до разделителя T) или минутах (если используется после разделителя T), D — индикатор компонента продолжительности времени в днях, H — индикатор компонента продолжительности времени в часах, S — индикатор компонента продолжительности времени в секундах. Должен быть указан хотя бы один компонент продолжительности времени. Если не указан ни один из компонентов продолжительности времени в часах, минутах или секундах, то разделитель T не используется.

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

Set{[значение], [значение], [значение]}

OrderedSet{[значение], [значение], [значение]}

Bag {[значение], [значение], [значение]}

Sequence {[значение], [значение], [значение]}

88. При формализации правил используются следующие логические операции: конъюнкция (and), дизъюнкция (or), исключающая дизъюнкция (xor), импликация (implies), отрицание (not).

89. При формализации правил используются следующие арифметические операции: сложение (+), вычитание (-), умножение (*), деление (/), унарный минус (-).

90. При формализации правил используются следующие операции сравнения значений: равно (=), не равно (<>), менее (<), не более (<=), не менее (>=), более (>).

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

92. При формализации правил используются следующие операции, определенные для коллекций значений: длина коллекции (size), проверка наличия значения в коллекции (includes), проверка отсутствия значения в коллекции (excludes), проверка наличия всех значений некоторой коллекции в данной коллекции (includesAll), проверка отсутствия всех значений некоторой коллекции в данной коллекции (excludesAll), подсчет количества элементов коллекции равных заданному значению (count), проверка отсутствия в коллекции элементов (isEmpty), проверка наличия в коллекции элементов (notEmpty), получение максимального элемента коллекции (max), получение минимального элемента коллекции (min), подсчет суммы элементов коллекции (sum).

93. При формализации правил используются следующие выражения итерации по элементам коллекции: выбор элементов, соответствующих условию (select), исключение элементов, соответствующих условию (reject), сортировка элементов коллекции (sortedBy), формирование новой коллекции без вложенных коллекций путем применения функции к каждому ее элементу (collect), формирование новой коллекции, возможно с вложенными коллекциями, путем применения функции к каждому ее элементу (collectNested), рекурсивное формирование коллекции (closure), определение выполняется ли условие для каждого элемента коллекции (forAll), определение выполняется ли условие хотя бы для одного элемента коллекции (exists), определение выполняется ли условие в точности для одного элемента коллекции (one), проверка элементов коллекции на уникальность (isUnique), получение произвольного элемента коллекции, соответствующего определенному условию (any), обобщенная итерация по элементам коллекции (iterate).

94. Для бинарных операций, перечисленных в пунктах 88 - 90, используется инфиксная нотация:

[значение] [операция] [значение]

Для операций, перечисленных в пункте 91, используется следующая нотация:

[реквизит | атрибут].[операция]([аргумент], [аргумент], [аргумент])

Для операций и выражений итерации, определенных для коллекций значений, перечисленных в пунктах 92 - 93, используется следующая нотация:

[реквизит | атрибут]->[операция]([итератор] | [выражение])

где [итератор] — наименование переменной, которая на каждом шаге итерации принимает очередное значение элемента коллекции, [выражение] — некоторое выражение, которое вычисляется для каждого элемента коллекции.

95. При формализации правил допустимо использование иных операций, описанных в спецификации Object Constraint Language, рекомендованной консорциумом Object Management Group.

96. Рекомендуется формализовать правила с помощью выражений следующего вида:

[ссылка на родительский реквизит целевого реквизита (атрибута) правила]->forAll([формализованное описание правила])

Если родительский реквизит целевого реквизита (атрибута) правила является корневым элементом электронного вида документа, то выражение итерации «forAll» не используется.

2. Требования по формализации ссылок на реквизиты (атрибуты)

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

self.[реквизит].value.[реквизит].value.[реквизит | атрибут]

где self — переменная, ссылающаяся на корневой элемент данных документа, [реквизит] — имя конструкции UML элемента данных, который соответствует реквизиту, [атрибут] — имя конструкции UML контекстной характеристики, которая соответствует атрибуту, value — ссылка на тип элемента данных.

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

self.[реквизит].value.[реквизит].value.[реквизит | атрибут].value

99. Если структура электронного вида документа основана на модели данных, в которой элементы данных определяются локально в рамках их родительского агрегированного типа данных, то ссылки на типы элементов данных («value») не используются.

100. В перечнях правил формирования электронного вида документов ссылки на типы элементов данных («value») не используются.

101. Переменная «self» может быть опущена, если путь к реквизиту указывается вне выражений итерации по коллекции значений, перечисленным в пункте 93.

102. При формализации ссылок на вложенные реквизиты (атрибуты) относительно итерируемого элемента коллекции используется сокращенный путь относительно этого элемента. При формализации ссылок на иные реквизиты (атрибуты) используется полный путь, включая переменную «self».

3. Требования по формализации правил формирования реквизитного состава электронного вида документа

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

[реквизит | атрибут]->notEmpty()

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

[реквизит | атрибут]->isEmpty()

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

[реквизит]->size() [= | >= | <=] [количество]

[реквизит]->size() >= [количество] and [реквизит]->size() <= [количество]

[реквизит | атрибут]->size() + [реквизит | атрибут]->size() + [реквизит | атрибут]->size() [= | >= | <=] [количество]

4. Требования по формализации форматных (синтаксических) правил

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

[реквизит | атрибут].value [= | <> | > | >= | <= | <] [значение]

[реквизит | атрибут].value [> | >=] [значение] and [реквизит | атрибут].value [< | <=] [значение]

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

[реквизит | атрибут].value.size() [= | <> | > | >= | <= | <] [значение]

[реквизит | атрибут].value.size() [> | >=] [значение] and [реквизит | атрибут].value.size() [< | <=] [значение]

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

[реквизит | атрибут].value.matches('[регулярное выражение]')

Регулярные выражения указываются в соответствии со спецификацией XML-схемы Консорциума Всемирной паутины (W3C XML Schema) за исключением того, что вместо одинарного символа «» используется двойной символ «\».

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

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

[реквизит | атрибут].value = [значение]

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

Set{[значение], [значение], [значение]}->includes([реквизит | атрибут].value)

5. Требования по формализации правил взаимосвязанности

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

[значение 1] [= | <> | > | >= | <= | <] [значение 2]

[значение 1] [> | >=] [значение 2] and [значение 1] [< | <=] [значение 3]

При этом [значение] может быть формализовано одним из следующих способов:

фиксированное значение в соответствии с пунктами 84 - 86

[реквизит | атрибут].value

[реквизит | атрибут].value.size()

[значение] [+ | — | * | /] [значение]

[реквизит].value->sum()

иные выражения, описанные в спецификации Object Constraint Language, рекомендованной консорциумом Object Management Group.

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

[реквизит | атрибут]->isUnique([реквизит | атрибут].value)

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

[реквизит | атрибут].value->includes([реквизит | атрибут].value)

[реквизит | атрибут].value >= 1 and [реквизит | атрибут].value <= [реквизит | атрибут]->size()

6. Требования по формализации прикладных правил

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

[наименование источника нормативно-справочной информации].allInstances()->exists([наименование номера, кода, идентификатора] = [реквизит | атрибут])

Описание структуры источника нормативно-справочной информации запрашивается у лица, ответственного за формирование и ведение указанного источника.

7. Требования по формализации правил соответствия

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

[наименование информационного источника].allInstances()->exists([условие])

not [наименование информационного источника].allInstances()->exists([условие])

[наименование информационного источника]::[наименование операции]([значение], [значение], [значение])

где «::» — обращение к операции информационного источника.

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

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

VI. Применение требований по формированию и проверке электронного вида документов

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

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

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

120. Возможны следующие виды результатов проверки реквизита (атрибута):

реквизит (атрибут) успешно прошел проверку — формируется, если реквизит (атрибут) соответствует требованиям правила;

реквизит (атрибут) содержит ошибку — формируется, если реквизит (атрибут) не соответствует требованиям правила и должен быть исправлен;

реквизит (атрибут) не проверялся — формируется, если для реквизита (атрибута) не выполнено условие, описанное в условной части правила, и проверка реквизита (атрибута) не требуется;

реквизит (атрибут) не найден — формируется, если реквизит (атрибут) отсутствует в электронном виде документа и правило не предписывает обязательность заполнения данного реквизита (атрибута), не является ошибкой;

правило не поддерживается — формируется, если программная реализация не поддерживает данное правило (например, если реализация правила в виде XSLT преобразования не поддерживает проверку кодового значения реквизита в соответствии со справочником).

121. Запись о результатах проверки должна содержать следующую информацию:

кодовое обозначение правила;

описание правила;

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

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

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

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

2. Описание формата и структуры электронного вида документа должно содержать в своем составе следующие сведения:

общие сведения о структуре документа;

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

В таблице формируются следующие поля (графы):

«имя реквизита» — иерархический номер реквизита (для атрибутов используются буквы русского алфавита), устоявшееся или официальное словесное обозначение реквизита, имя конструкции UML (для реквизитов с указанием префикса пространства имен);

«описание реквизита» — текст, поясняющий прикладной смысл реквизита;

«идентификатор» — идентификатор элемента данных в модели данных, соответствующего реквизиту;

«тип данных» — идентификатор типа данных в модели данных, соответствующего реквизиту;

Пример:

6. Сведения о базовых и простых типах данных, используемых в структуре документа, приводятся отдельно по каждому виду объектов модели данных Союза (базовые типы данных, общие простые типы данных, прикладные простые типы данных). Приводятся общие сведения об используемых типах данных и перечень используемых типов данных.

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

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

«идентификатор» — идентификатор типа данных в модели данных;

«конструкция UML» — идентификатор конструкции UML в модели данных, соответствующей типу данных;

«имя» — имя типа данных в модели данных;

«область значений» — множество допустимых значений, соответствующих типу данных.

Образец:

Таблица 1 Перечень атрибутов, применяемых для спецификации правила формирования электронного вида документа

Таблица 2 Перечень атрибутов, применяемых для спецификации правила формирования электронного вида документа

Приложение 3 к Методике описания требований к электронному виду документов

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ПЕРЕЧНЮ ПРАВИЛ ФОРМИРОВАНИЯ РЕКВИЗИТОВ ЭЛЕКТРОННОГО ВИДА ДОКУМЕНТА

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

2. Для каждого правила должны приводиться следующие сведения:

код правила;

область применения;

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

формулировка правила на естественном языке;

формулировка правила в формализованном виде на языке OCL.

3. Перечень правил может приводиться в стандартном и расширенном виде.

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

Таблица содержит следующие поля (графы)

«имя реквизита» — имя реквизита в соответствии с описанием структуры электронного вида документа с указанием иерархического номера реквизита;

«N гр. формы/пункт Порядка» — номер графы формы документа или пункт (подпункт, абзац) Порядка заполнения документа в соответствии с нормативным правовым актом, соответствующие реквизиту структуры электронного вида документа.

«мн.» — множественность реквизита (обязательность (опциональность) и количество возможных повторений реквизита).

«код правила» — указывается кодовое обозначение правила;

«вид правила» — в кодированном виде указывается область применения правила. Допустимы следующие значения: 1 — правило установлено правом Союза, обязательно к применению во всех государствах-членах; 2 — правило установлено правом Союза, применяется в отдельном государстве-члене; 3 — правило установлено законодательством государства-члена, применяется в отдельном государстве-члене;

«код государства-члена» — указывается 2-значный буквенный код государства-члена, в котором применяется правило (для правил, которые применяются в отдельных государствах-членах).

«описание правила» — приводится формулировка правила на естественном языке;

«OCL выражение» — приводится формализованная формулировка правила на языке OCL.

5. Расширенный вид представления предполагает формирование двух таблиц:

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

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

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

«имя реквизита» — имя реквизита в соответствии с описанием структуры электронного вида документа с указанием иерархического номера реквизита;

«N гр. формы/пункт Порядка» — номер графы формы документа или пункт (подпункт, абзац) Порядка заполнения документа в соответствии с нормативным правовым актом, соответствующие реквизиту структуры электронного вида документа.

«код правила» — указывается кодовое обозначение правила (правил), применимого (применимых) к реквизиту структуры;

Образец:

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

«код правила» — указывается кодовое обозначение правила;

«вид правила» — в кодированном виде указывается область применения правила. Допустимы следующие значения: 1 — правило установлено правом Союза, обязательно к применению во всех государствах-членах; 2 — правило установлено правом Союза, применяется в отдельном государстве-члене; 3 — правило установлено законодательством государства-члена, применяется в отдельном государстве-члене;

«код государства-члена» — указывается 2-значный буквенный код государства-члена, в котором применяется правило (для правил, которые применяются в отдельных государствах-членах).

«описание правила» — приводится формулировка правила на естественном языке;

«OCL выражение» — приводится формализованная формулировка правила на языке OCL;

«объект НСИ» — приводится, при наличии, сведения, позволяющие однозначно идентифицировать объект НСИ Союза, который используется при выполнении правила;

«основание» — приводится ссылка на положения нормативного правового акта, в соответствии с которым установлено правило.