Visits: 447
Open PeppolのBasicルールが何かを理解する上で重要な「カーディナリティの調整(Cardinality alignment)」について紹介する。カーディナリティの調整は、論理構造を定義しているセマンティックモデルと物理的なXMLでの文書構造を定義している構文（シンタックス）を対応づけるシンタックス・バインディングにおいて発生する問題とそれに対する回避策を定義しているCEN/TS 16931-3-1で規定されている。
勝手な思い込みや中途半端な理解は、後工程での手戻りの原因になる。規格そのものの英文を読んで理解することが必要だが、ここに重要な箇所を取り上げて紹介する。
この記事は長くなりそうだが、最後までお読みいただくことをお勧めする。
また、2020年の提言資料も基本的な方向性は現時点でも有効だと考えている。
Open peppolの技術仕様BIS Billingを理解するには、
EN 16931-1 Electronic invoicing – Part 1: Semantic data model of the core elements of an electronic invoice
で規定されている用語とその定義の理解が基礎。
セマンティックモデルは、ISO 15000-5, Electronic Business Extensible Markup Language (ebXML) — Part 5: Core Components Specification (CCS)が規定している論理データモデルの規定に従って定義されている。
シンタックス・バインディングは、
CEN/TS 16931-3-1 Electronic invoicing – Part 3-1: Methodology for syntax bindings of the core elements of an electronic invoice
で基礎的な方法論が規定されている。
CEN/TS 16931-3-2 Electronic invoicing – Part 3-2: Syntax binding for ISO/IEC 19845 (UBL 2.1) invoice and credit note
では、UBL 2.1との対応づけが、
CEN/TS 16931-3-3 Electronic invoicing – Part 3-3: Syntax binding for UN/CEFACT XML Industry Invoice D16B
でUN/CEFACT(D16B)との対応づけが、それぞれ規定されている。
このほか、Open Peppolでは。サポートしていないが、欧州規格ではUN/EDIFACTやISO 20022 Financial services — Universal financial industry message scheme も対象としていた。
欧州における電子インボイスの実用化に向けた取り組みについてはも2020年のYouTube映像をご覧いただきたい。
Open Peppolは、図に示すようにVATについての欧州指令や欧州統一市場実現を目指すデジタル化プロジェクト(CEF: Connected Europe Facility)を背景に２００８年から2012年にかけて実施された欧州における公共調達のデジタル化プロジェクトPEPPOL（Pan-European public Procurement on-Line）を継続するために発足した。
年表画像へのリンク：標準化の歴史
セマンティックモデル
用語と定義
EN 16931-1
3 Terms and definitions 用語と定義
For the purposes of this document, the following terms and definitions apply.
このドキュメントでは、次の用語と定義が適用される。
NOTE Business terms that are part of the semantic model are defined in the model itself.
注 セマンティックモデルの一部であるビジネス用語は、モデル自体で定義される。
3.1
electronic invoice
電子インボイス
invoice that has been issued, transmitted and received in a structured electronic format which allows for its automatic and electronic processing
自動および電子処理を可能にする構造化された電子形式で発行、送信、および受信された請求書（インボイス）
[SOURCE: Directive 2014/55/EU [1]]
[出典：指令2014/55/EU [1]]
3.2
semantic data model
セマンティックデータモデル
structured set of logically interrelated information elements
論理的に相互に関連する情報要素の構造化された集合
3.3
information element
情報要素
semantic concept that can be defined independent of any particular representation in a syntax
特定の構文表現とは無関係に定義できる論理的な概念
3.4
structured information element
構造化された情報要素
information element that can be processed automatically
自動的に処理できる情報要素
3.5
syntax
構文
machine-readable language or dialect used to represent the information elements contained in an electronic document (e.g. an electronic invoice)
電子文書（電子請求書など）に含まれる情報要素を表すために使用される機械可読な言語または方言
3.6
business term
ビジネス用語
label assigned to a given information element which is used as a primary reference
一次参照として使用される特定の情報要素に割り当てられたラベル
3.7
core invoice model
コアインボイス モデル
semantic data model of the core elements of an electronic invoice
電子請求書のコア要素のセマンティックデータモデル
3.8
core elements of an electronic invoice
電子インボイスのコア要素
set of essential information elements that an electronic invoice may contain in order to enable cross-border interoperability, including the necessary information to ensure legal compliance
法的なコンプライアンスを確保するために必要な情報を含む、国境を越えた相互運用性を可能にするために電子請求書に含まれる可能性のある重要な情報要素の集合
3.9
identifier
識別子
character string used to establish the identity of, and distinguish uniquely, one instance of an object within an identification scheme from all other objects within the same scheme Note 1 to entry: An identifier may be a word, number, letter, symbol, or any combination of those, depending on the identification scheme used.
識別スキーマ内のオブジェクトの1つのインスタンスを、同じスキーマ内の他のすべてのオブジェクトから識別し、一意に区別するために使用される文字列。
Note 1 to entry: An identifier may be a word, number, letter, symbol, or any combination of those, depending on the identification scheme used.
注1：識別子は、使用される識別スキーマに応じて、単語、数字、文字、記号、またはそれらの組み合わせで表しても良い。
3.10
identification scheme
識別スキーマ
collection of identifiers applicable for a given type of object governed under a common set of rules
共通のルールセットに基づいて管理される特定のタイプのオブジェクトに適用可能な識別子の集まり
CCTS
UBLやUN/CEFACTでも、ISO 15000-5の論理モデルCCS（当社は、CCTS: Core Component Technical Specificationと表記されていた）に従って、基本データ型や集約データ型をXMLスキーマで定義している。このモデルでは、電文を、基本となる情報要素(Basic Core Component)を集めた集合情報要素(Aggregate Core Component)として、定義している。集合情報要素には、基本情報要素および別の集合情報要素を参照して電文に含むための参照情報要素(Associate Core Component)があり、電文は、集合情報要素が入れ子になった構造として定義される。UBLでも、 識別子型や金額型など、CCS が定めているのと同じ、基本データ型を使用している。Open PEPPOLでは、UBL2.1やUN/CEFACT CII (D16B)をサポートしていたが、今はUBL2.1が中心になっている。
ISO 15000-5のIntroductionで紹介されているCCSの基本やAnnex A (normative) primitive type definitionやAnnex B (normative) List of approved Core Component Types (CCT) などが、Open Peppol BIS Billing 3.0の基礎となっている。
シンタックス・バインディング
論理モデルとXMLスキーマで定義する物理的な表現の対応づけにおいて発生する問題とその問題に対する対応方法は、CEN/TS 16931-3-1で規定されている。
この中で、特に重要なカーディナリティの調整について紹介する。
セマンティックモデルを具体的な業界標準のXML仕様に対応づける上で、発生する障害やそれに対する回避策が検討されており、セマンティックモデルで定義されたカーディナリティ（要素の繰返し回数に対する制約条件）とUBLのXMLスキーマで定義しているカーディナリティが異なるときの調整方法などがOpen PeppolのBasicルールがなぜそのような内容になっているのかを理解する上で重要。
カーディナリティの調整
CEN/TS 16931-3-1 4.4 Cardinality assesment (カーディナリティ評価)では、カーディナリティの調整を次の表のように規定している。
UBLカーディナリティ類型がCAR-1からCAR-5では、本規格に準拠してスキーマトロンのルールを定義するか運用を決める必要があり、セマンティックモデルで定義されていないUBL要素が使用する場合XMLスキーマ検証ではエラーとならないので、この場合の処理方法を決める必要がある。
カーディナリティの問題を回避するためにカーディナリティの類型に基づくルールが必要となる。
これがBasicルール。
| CAR-n | 論理モデル/ UBL |
問題点 | 回避策 |
|---|---|---|---|
| CAR-1 | 任意（0..x）/ 必須（1..x） |
要素が存在しないとスキーマ検証でエラー | 欠落している場合の「欠損値」（例：0、1-1-1970、AAA）を決める |
| CAR-2 | 必須（1..x）/ 任意（0..x） |
なし | 「要素がなければならない」というルールをスキマトロンで定義する |
| CAR-3 | 単数（x..1）/ 複数（x..n） |
なし | 「要素は一つだけ」というルールをスキーマトロンで定義する |
| CAR-4 | 複数（x..n）/ 単数（x..1） |
複数定義できない | 1）可能であれば、構造内でより高いレベルを繰り返す 2）テキスト要素の場合、繰り返し要素を連結する。 |
| CAR-5 | 要素が未定義/ 要素は必須 |
有 | 欠落している場合の「欠損値」（例：0、1-1-1970、AAA）を決める |
| CAR-6 | 要素が未定義/ 要素は任意 |
なし | 使用時に警告を報告する |
CAR-1およびCAR-5を定義する場合のデフォルト値。 CAR-2およびCAR-3の場合、スキマトロンルールを定義する必要があります。 CASE-4では、可能な解決策を選択する必要がある。また、要素がセマンティックモデルで未定義のときにUBL要素が使用された場合、スキーマトロンは警告を報告する必要がある。
現在、Finishing PINT 2プロジェクトでは、次のような方針が検討されている。
CAR-5の欠損値として次の値を用いる。
Text, Code, Identifier: “NA”
Numerical: 0
Date: 01-01-1900
Time: 00:00:00
CAR-6については、
これらの種類のルールはEN16931にるが、PINTでは、Distinctで個別のビジネス用語が許可されているため、対象となる要素を使用する可能性があるのでPINTには追加されない。Distinct要素は管轄区域により追加できるが、一般的なPINTルールの集合から提供されない。 これは、管轄区域がその実装の際に使用できるテンプレートの例とともに、”PINT methodology document”（PINT方法論文書)に記載されるものとする。
この方針については、最終決定されたものではないので留意すること。
