三分一技術士事務所

OpenPeppol Operation Office回答で確認するPEPPOL-T111-B03201のfallback rule

Views: 0

1. はじめに

Peppol BIS Invoice Response の Schematron ルール PEPPOL-T111-B03201 について、単独のルールページだけを見ると、cac:Status のすべての子要素が禁止されているように見える。

このルールは、次のような context と test を持つ。

https://docs.peppol.eu/poacc/upgrade-3/rules/PEPPOL-T111-B03201/

T111 B03201

test="false()" であるため、このルールが適用されると、必ず validation error になる。

しかし、このルールを「cac:Status のすべての子要素を禁止するルール」と理解すると誤りである。cac:Status の syntax page では、cbc:StatusReasonCode、cbc:StatusReason、cac:Condition が正式な子要素として定義されている [1]。

https://docs.peppol.eu/poacc/upgrade-3/syntax/InvoiceResponse/tree/

InvoiceResponse

https://docs.peppol.eu/poacc/upgrade-3/syntax/InvoiceResponse/cac-DocumentResponse/

DocumentResponse

https://docs.peppol.eu/poacc/upgrade-3/syntax/InvoiceResponse/cac-DocumentResponse/cac-Response/

Response

また、Invoice Response profile では、Invoice status、status clarification、clarification detail という構造が説明されており、cac:Status はこの clarification を表すためのコンテナとして位置付けられる [2]。

したがって、PEPPOL-T111-B03201 は、定義済みの子要素を禁止するルールではなく、定義されていない子要素を捕捉して拒否する fallback rule として理解する必要がある [3]。

この考え方は、Invoice Response だけの問題ではない。JP PINT においても、syntax binding に定義されていない UBL 要素をどのように扱うかという、適合性検証上の重要な論点につながる。

2. 問題となったルール

公開されている PEPPOL-T111-B03201 の内容は、概念的には次のように読める。

      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/*">
         <assert test="false()" flag="fatal" id="PEPPOL-T111-B03201">Document MUST NOT contain elements not part of the data model.</assert>
      </rule>

cac:Status/* は、XPath としては cac:Status のすべての子要素にマッチする。

そのため、単独で見ると、次のような正式な子要素まで禁止されるように見える。

0..1 cbc:StatusReasonCode
0..1 cbc:StatusReason
0..unbounded cac:Condition

しかし、Schematron のルールは、単独の rule page だけで解釈すべきではない。

特に、同じ pattern の中に、より具体的なルールと包括的な fallback rule が並んでいる場合、その関係を確認する必要がある。

2.1. Schematronのpatternとルールチェックの順序

Schematron では、pattern が検証ルールのまとまりを構成する。

同じ pattern の中に複数の rule がある場合、対象ノードに対してどの rule が active になるかが重要である。

典型的には、より具体的な rule を先に置き、最後に * を使った包括的な rule を置くことで、次のような構造を作る。

1. 定義済みの具体的な要素を個別 rule で処理する
2. どの具体 rule にも該当しない要素を最後の fallback rule で捕捉する
3. fallback rule では test="false()" によりエラーにする

この方式により、定義済みの要素は許可され、未定義の要素だけが拒否される。

したがって、test="false()" の rule があること自体は問題ではない。問題は、その rule がどのような位置に置かれ、どの具体 rule と組み合わされているかである。

2.2. Peppol Service Deskからの回答

この点について Peppol Service Desk からは、PEPPOL-T111-B03201 は実行可能 Schematron の一部ではあるが、単独で解釈すべきではないとの回答があった。

回答の要旨は、次のとおりである。

PEPPOL-T111-B03201 is indeed part of the executable Schematron as shown. However, it should not be interpreted in isolation.

The essential element you should look for is the pattern element. Rules within the same pattern are handled based on specificity.

— PEPPOL-22842
Peppol Service Desk

つまり、注目すべきなのは個別の rule だけではなく、それが含まれている pattern である。同じ pattern 内には、cac:Status の有効な子要素に対応する、より具体的な rule が存在している。

回答では、具体的に次の要素が挙げられている。

cac:Status/cbc:StatusReasonCode
cac:Status/cbc:StatusReason
cac:Status/cac:Condition

これらは T111 data model に含まれる要素であり、同じ pattern 内の具体 rule により処理される。

一方、次の context を持つ rule が問題となった。

/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/*

Service Desk の回答では、この rule は cac:Status の下にあるすべての子要素を禁止するものではなく、具体 rule で処理されなかった残りの子要素を捕捉する catch-all rule であると説明されている。

The rule with context:

/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/*

acts as a “catch-all” rule for any remaining child elements under cac:Status that are not covered by a more specific rule in that pattern.

— PEPPOL-22842
Peppol Service Desk

また、test="false()" は、こうした想定外の要素を validation error にするために使われている。

So the rule does not reject the valid child elements listed in the syntax documentation. It only rejects elements under cac:Status that are not part of the data model.

— PEPPOL-22842
Peppol Service Desk

したがって、Service Desk の説明によれば、PEPPOL-T111-B03201 は次の要素を拒否しない。

cbc:StatusReasonCode
cbc:StatusReason
cac:Condition

これらは syntax documentation に記載された正当な子要素であり、それぞれ同じ pattern 内の具体 rule により処理される。

一方、cac:Status の下に T111 data model に含まれない要素が現れた場合には、最後の catch-all rule に捕捉され、test="false()" により validation error になる。

さらに、Service Desk は、公開されている rule page が誤解を招き得ることも認めている。

The published rule page represents the executable Schematron rule, but it can indeed be misleading when viewed without the surrounding rules in the same pattern. The complete generated Schematron should be consulted to understand how the specific rules and the catch-all rule work together.

— PEPPOL-22842
Peppol Service Desk

この回答により、PEPPOL-T111-B03201 は単独で読めばすべての子要素を禁止しているように見えるものの、実際には同じ pattern 内の具体 rule と組み合わせて動作する fallback rule であることが確認できる。

2.3. PEPPOLBIS-T111.schにおけるcac:Status周辺のルール

アップロードされた PEPPOLBIS-T111.sch を確認すると、cac:Status 周辺のルールは、同じ basic model pattern の中で、次の順序で定義されている。

      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status"/>
      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/cbc:StatusReasonCode">
         <assert test="(some $code in $clOPStatusReason satisfies $code = normalize-space(text())) or (some $code in $clOPStatusAction satisfies $code = normalize-space(text()))"
                 flag="fatal"
                 id="PEPPOL-T111-B03301">Value MUST be part of code list 'Status Clarification Reason (OpenPeppol)' or 'Status Clarification Action (OpenPeppol)'.</assert>
         <assert test="@listID" flag="fatal" id="PEPPOL-T111-B03302">Attribute 'listID' MUST be present.</assert>
         <assert test="not(@listID) or (some $code in $clClarificationListID satisfies $code = @listID)"
                 flag="fatal"
                 id="PEPPOL-T111-B03303">Value MUST be part of code list 'Clarification list identifier (OpenPeppol)'.</assert>
      </rule>
      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/cbc:StatusReason"/>
      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/cac:Condition">
         <assert test="cbc:AttributeID" flag="fatal" id="PEPPOL-T111-B03601">Element 'cbc:AttributeID' MUST be provided.</assert>
      </rule>
      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/cac:Condition/cbc:AttributeID"/>
      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/cac:Condition/cbc:Description"/>
      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/cac:Condition/*">
         <assert test="false()" flag="fatal" id="PEPPOL-T111-B03602">Document MUST NOT contain elements not part of the data model.</assert>
      </rule>
      <rule context="/ubl:ApplicationResponse/cac:DocumentResponse/cac:Response/cac:Status/*">
         <assert test="false()" flag="fatal" id="PEPPOL-T111-B03201">Document MUST NOT contain elements not part of the data model.</assert>
      </rule>

この構造で重要なのは、cac:Status/* という包括的な rule が、具体的な子要素の rule の後に置かれていることである。

つまり、次の要素は、先に現れる具体的な rule により処理される。

cac:Status/cbc:StatusReasonCode
cac:Status/cbc:StatusReason
cac:Status/cac:Condition

そのため、これらの要素は最後の cac:Status/* rule、すなわち PEPPOL-T111-B03201 により拒否される対象ではない。

一方、cac:Status の下に定義されていない子要素が現れた場合、その要素は具体的な rule にマッチしないため、最後の cac:Status/* に捕捉される。

その結果、test="false()" により validation error になる。

これが fallback rule の役割である。

2.4. fallback ruleとは何か

ここでいう fallback rule とは、定義されていない要素を最後に捕捉するための rule である。

つまり、fallback rule は「何でも受け入れるための rule」ではない。むしろ、「ここまでの具体 rule に該当しなかったものを拒否するための rule」である。

たとえば、次の XML は、cac:Status の下に定義済みの子要素だけを含む。

<cac:Status>
  <cbc:StatusReasonCode listID="OPStatusReason">REF</cbc:StatusReasonCode>
  <cbc:StatusReason>PO reference is missing.</cbc:StatusReason>
</cac:Status>

この場合、cbc:StatusReasonCode は次の具体 rule により処理される。

<rule context=".../cac:Status/cbc:StatusReasonCode">
  ...
</rule>

また、cbc:StatusReason は次の rule により定義済み要素として扱われる。

<rule context=".../cac:Status/cbc:StatusReason"/>

この rule には assert がないため、この basic model pattern の範囲では追加エラーを出さず、定義済みの子要素として受け入れることを意味する。

一方、次の XML は、cac:Status の下に未定義の子要素を含む。

<cac:Status>
  <cbc:StatusReasonCode listID="OPStatusReason">REF</cbc:StatusReasonCode>
  <cbc:UnknownElement>ABC</cbc:UnknownElement>
</cac:Status>

cbc:UnknownElement には、対応する具体 rule がない。

そのため、最後の fallback rule に到達する。

<rule context=".../cac:Status/*">
  <assert test="false()" id="PEPPOL-T111-B03201">
    Document MUST NOT contain elements not part of the data model.
  </assert>
</rule>

この場合は、PEPPOL-T111-B03201 によりエラーになる。

したがって、PEPPOL-T111-B03201 は、「すべての cac:Status 子要素を禁止する rule」ではなく、「定義済みでない cac:Status 子要素を禁止する fallback rule」である。

2.5. Invoice Responseにおけるデータ構造

Invoice Response profile では、Invoice Response の状態通知を、概ね次の構造として説明している [2]。

Invoice Status
  Status clarification
    Clarification detail

これを UBL の構造に対応させると、次のようになる。

cac:DocumentResponse
  cac:Response
    cbc:ResponseCode
      → Invoice Status

    cac:Status
      → Status clarification

      cbc:StatusReasonCode
        → Coded clarification reason or action

      cbc:StatusReason
        → Textual clarification

      cac:Condition
        → Clarification detail / affected business term

cbc:ResponseCode は、請求書処理の状態を表す。

たとえば、受領済み、処理中、照会中、条件付き承認、却下、承認済み、支払開始済みなどである。

一方、cac:Status は、その状態に対する補足説明、すなわち status clarification を表す。

たとえば、cbc:ResponseCode が RE、すなわち Rejected の場合、それだけでは、なぜ却下されたのか分からない。

その理由を、cbc:StatusReasonCode や cbc:StatusReason で示す。

さらに、どの請求書項目や Business Term に問題があるかを示すために、cac:Condition を使用する。

2.6. cac:Statusの正式な子要素

cac:Status の syntax page では、次の子要素が定義されている [1]。

Cardinality Element 意味

0..1

cbc:StatusReasonCode

請求書状態に対する説明コード。Status clarification reason または status clarification action を表す。

0..1

cbc:StatusReason

請求書状態に対する説明文。コードだけでは十分でない場合、または自由記述が必要な場合に使用する。

0..unbounded

cac:Condition

説明の対象となるデータ項目、Business Term、または補正候補値を示す。

この定義からも、cbc:StatusReasonCode、cbc:StatusReason、cac:Condition は cac:Status の正当な子要素である。

したがって、PEPPOL-T111-B03201 を、これらの子要素を禁止する rule と読むのは誤りである。

2.7. cbc:StatusReasonCodeに対するコード要件

cbc:StatusReasonCode は、cac:Status の正式な子要素であり、値、listID 属性の存在、および listID の値について、個別の validation rules により検証される [4]。

主な basic rules は次のとおりである。

Rule ID 内容

PEPPOL-T111-B03301

値は Status Clarification Reason (OpenPeppol) または Status Clarification Action (OpenPeppol) のコードリストに含まれていなければならない。

PEPPOL-T111-B03302

@listID 属性が存在しなければならない。

PEPPOL-T111-B03303

@listID の値は Clarification list identifier (OpenPeppol) のコードリストに含まれていなければならない。実質的には OPStatusReason または OPStatusAction である。

さらに、business rules として、listID に応じたコードリスト整合性もチェックされる。

Rule ID 内容

PEPPOL-T111-R006

@listID='OPStatusAction' の場合、cbc:StatusReasonCode の値は OPStatusAction のコードリストに含まれていなければならない [8]。

PEPPOL-T111-R007

@listID='OPStatusReason' の場合、cbc:StatusReasonCode の値は OPStatusReason のコードリストに含まれていなければならない [9]。

したがって、cbc:StatusReasonCode は、単に cac:Status の子要素として許可されているだけではない。

コードリストと listID の対応関係まで含めて検証される。

2.8. 存在要求ルールとの関係

cac:Status の構文上の cardinality は、次のように定義されている [1]。

0..1 cbc:StatusReasonCode
0..1 cbc:StatusReason
0..unbounded cac:Condition

ここで注意すべきなのは、cardinality と business rule による条件付き存在要求は別であるという点である。

構文上、cbc:StatusReasonCode は 0..1 である。つまり、常に必須ではない。

しかし、特定の ResponseCode の場合には、business rule により存在が要求される。

Rule ID 内容

PEPPOL-T111-R001

cbc:ResponseCode が CA、UQ、RE のいずれかである場合、cac:Status/cbc:StatusReasonCode が存在しなければならない [5]。

PEPPOL-T111-R002

cbc:StatusReasonCode='OTH' の場合、cbc:StatusReason を提供すべきである。この rule は warning である [6]。

PEPPOL-T111-R004

cbc:StatusReasonCode='PPD' の場合、cbc:StatusReason が存在しなければならない。この rule は fatal である [7]。

つまり、cbc:StatusReasonCode は構文上 0..1 であるが、ResponseCode が CA、UQ、RE の場合には、PEPPOL-T111-R001 により必須になる。

同様に、cbc:StatusReason は構文上 0..1 であるが、StatusReasonCode が PPD の場合には、PEPPOL-T111-R004 により必須になる。

このように、Invoice Response の検証は、複数の層で構成されている。

1. 構文上の定義
   例: cac:Status の子要素は何か

2. basic model rules
   例: 未定義要素を fallback rule で拒否する

3. code list rules
   例: StatusReasonCode の値と listID を検証する

4. business rules
   例: ResponseCode が UQ/CA/RE の場合に clarification code を必須にする

PEPPOL-T111-B03201 は、このうち 2 の basic model rule に属する。

したがって、PEPPOL-T111-B03201 は、3 のコードリスト要件や 4 の条件付き存在要件を置き換えるものではない。

2.9. patternが異なる場合の注意

同じ pattern 内では、fallback rule と具体 rule の関係が重要である。

しかし、別の pattern にある rule は、別の検証として実行される。

このため、たとえば cbc:StatusReasonCode は、basic model pattern では B03301、B03302、B03303 により検証される。

一方、business rule pattern では、R001、R002、R004、R006、R007 などにより、条件付き存在要件やコードリストとの整合性が追加的に検証される。

したがって、次の二つは矛盾しない。

構文上:
cbc:StatusReasonCode は 0..1

business rule:
ResponseCode が CA/UQ/RE の場合、cbc:StatusReasonCode は必須

また、次の二つも矛盾しない。

basic model rule:
cac:Status/* に fallback rule がある

具体 rule:
cac:Status/cbc:StatusReasonCode は B03301/B03302/B03303 で検証される

fallback rule は、具体 rule で処理されなかった未定義要素だけを捕捉するためのものである。

2.10. 実例: Invoice Responseのcac:Status

Invoice Response では、次のような構造が使われる。

<cac:Response>
  <cbc:ResponseCode>UQ</cbc:ResponseCode>

  <cac:Status>
    <cbc:StatusReasonCode listID="OPStatusReason">REF</cbc:StatusReasonCode>
    <cac:Condition>
      <cbc:AttributeID>BT-13</cbc:AttributeID>
      <cbc:Description>PO0001</cbc:Description>
    </cac:Condition>
  </cac:Status>

  <cac:Status>
    <cbc:StatusReasonCode listID="OPStatusAction">PIN</cbc:StatusReasonCode>
  </cac:Status>
</cac:Response>

この例では、ResponseCode が UQ である。

そのため、PEPPOL-T111-R001 により、clarification code、すなわち cac:Status/cbc:StatusReasonCode が必要になる [5]。

さらに、StatusReasonCode の listID が OPStatusReason の場合は reason code として、OPStatusAction の場合は action code として解釈される。

このように、cac:Status は単なる自由記述欄ではない。

請求書状態に対する構造化された補足情報を表すコンテナである。

2.11. なぜ公開ルールページだけでは誤解しやすいのか

PEPPOL-T111-B03201 の単独ページは、次の情報だけを示す [3]。

Context: /ubl:ApplicationResponse/.../cac:Status/*
Test: false()
Message: Document MUST NOT contain elements not part of the data model.

この表示自体は、実行可能 Schematron の一部としては正しい。

しかし、これだけでは、同じ pattern 内に次の具体 rule が存在することが分からない。

.../cac:Status/cbc:StatusReasonCode
.../cac:Status/cbc:StatusReason
.../cac:Status/cac:Condition
.../cac:Status/cac:Condition/cbc:AttributeID
.../cac:Status/cac:Condition/cbc:Description

そのため、読者は cac:Status/* の wildcard rule がすべての子要素に直接適用されると誤解しやすい。

実際には、PEPPOL-T111-B03201 は、具体的な子要素 rule の後に置かれた fallback rule である。

したがって、文書利用者向けの説明としては、単独 rule page だけでなく、同じ pattern 内での rule 関係を示す補足説明が必要である。

3. OpenPeppol BIS Billingのrule code体系

JP PINT の Basic Rule を検討する前に、OpenPeppol BIS Billing で使われている rule code 体系を確認しておくと分かりやすい。

OpenPeppol BIS Billing 3.0 では、検証ルールは大きく次の体系に分かれる [13]。

Rule code体系 概要

BR-*

EN 16931 由来の基本 business rule。必須項目、条件付き必須、基本構造などを規定する。

BR-CL-*

EN 16931 系の code list rule。通貨コード、国コード、VAT category code、単位コードなどを検証する。

BR-CO-*

計算・整合性 rule。明細金額合計、税額、税込合計、支払額などを検証する。

BR-DEC-*

小数桁数に関する rule。

BR-S-, BR-Z-, BR-E-, BR-AE- など

VAT category ごとの rule。Standard rated、Zero rated、Exempt、Reverse charge など、税カテゴリ別の詳細条件を規定する。

PEPPOL-EN16931-Rxxx

Peppol BIS 固有の business rule または運用 rule。Business process、Specification identifier など、Peppol BIS として必要な条件を規定する。

PEPPOL-EN16931-CLxxx

Peppol BIS 固有または Peppol が採用する code list rule。

PEPPOL-EN16931-Fxxx

日付形式などの format rule。

PEPPOL-EN16931-Pxxxx

Profile、文書種別、VATEX などに関する Peppol 固有条件。

UBL-CR-xxx

UBL schema 上は存在し得るが、BIS Billing では使用すべきでない要素などに対する UBL 構文制約 rule。

<国コード>-R-xxx

国別 rule。例として、スウェーデン向けの SE-R-001 などがある。

このうち、JP PINT Basic Rule の検討で特に参考になるのは、UBL-CR-* 系である。

BIS Billing では、UBL schema 上は存在し得るが BIS Billing の data model では使用しない要素に対して、UBL-CR-* rule が定義されている [14]。

たとえば、次のような rule がある。

Rule ID 概要

UBL-CR-001

UBL invoice should not include extensions.

UBL-CR-002

UBL invoice should not include UBLVersionID or it should be 2.1.

UBL-CR-006

UBL invoice should not include IssueTime.

UBL-CR-007

UBL invoice should not include PricingCurrencyCode.

これらは、多くの場合 warning として扱われる。

一方、Invoice Response の PEPPOL-T111-B03201 のような fallback rule は、test="false()" により、data model に含まれない要素を fatal error として拒否する構造を持つ。

つまり、BIS Billing の UBL-CR-* は「UBL には存在するが BIS では使うべきでない要素を検出する rule 群」であり、Invoice Response の fallback rule は「同じ pattern 内の具体 rule に該当しない要素を最後に拒否する rule」である。

両者は実装方法や severity に違いがあるが、共通しているのは、単なる UBL schema validation だけではなく、Peppol の data model として許容される要素を制御している点である。

また、Peppol BIS 固有 rule は PEPPOL-EN16931- という prefix を使い、EN 16931 由来の BR- とは明確に区別されている [15]。

このように、OpenPeppol BIS Billing では、rule code 体系により、次の層が区別されている。

1. EN 16931 由来の business rule
2. Peppol BIS 固有の business / operational rule
3. UBL 構文上は可能だが BIS data model では望ましくない要素の制約
4. 国別 rule

JP PINT に Basic Rule を追加する場合も、この考え方に従い、既存の IBR- や ALIGNED-IBR- とは別に、syntax binding に定義されていない UBL 要素を検出する rule code 体系を設けるのが望ましい。

たとえば、次のような prefix が考えられる。

PINT-JP-BM-xxx

ここで、BM は Basic Model を意味する。

この prefix を使えば、金額計算、税制固有条件、コードリストなどを扱う business rule と、syntax binding に基づいて未定義要素を禁止する basic model rule を明確に区別できる。

4. 補足: PINT EUにおけるBasic Rule相当のルール

JP PINT の Basic Rule を検討するうえでは、PINT EU のルール構成も参考になる。

PINT EU の Schematron は、公式ページ上で次の三つに分けて提示されている [16]。

1. EN16931 specific PINT rules
2. EU Peppol specific PINT rules
3. Shared PINT rules

このうち、Shared PINT rules は、PINT に共通する基本的な business rule であり、IBR- および IBR-CL- を中心に構成されている [17]。

たとえば、IBR-001 から IBR-016 では、Specification identifier、Invoice number、Issue date、Invoice currency code、Seller name、Buyer name、Invoice line など、PINT invoice としての基本的な必須項目が規定されている。

IBR-001
IBR-002
IBR-003
...
IBR-016
IBR-CL-xx

一方、PINT EU において、この記事でいう Basic Rule、すなわち「UBL schema 上は存在し得るが、PINT/EN16931 data model では使用すべきでない要素を制限するルール」に近いものは、EN16931 specific PINT rules の中に含まれる UBL-CR-* 系のルールである [18]。

UBL-CR-* は、A UBL invoice should not include …​ という形式で、PINT/EN16931 の data model に含まれない、または使用すべきでない UBL 要素を個別に列挙している。

例として、PINT EU では次のような rule が定義されている。

Rule ID 概要

UBL-CR-061

A UBL invoice should not include the ReceiptDocumentReference CopyIndicator.

UBL-CR-063

A UBL invoice should not include the ReceiptDocumentReference IssueDate.

UBL-CR-081

A UBL invoice should not include the OriginatorDocumentReference IssueTime.

UBL-CR-094

A UBL invoice should not include the ContractDocumentReference CopyIndicator.

UBL-CR-110

A UBL invoice should not include the AdditionalDocumentReference CopyIndicator.

UBL-CR-112

A UBL invoice should not include the AdditionalDocumentReference IssueDate.

UBL-CR-180

A UBL invoice should not include the AccountingSupplierParty/Party/PartyLegalEntity/CompanyLegalFormCode.

UBL-CR-238

A UBL invoice should not include the AccountingCustomerParty/Party/PartyTaxScheme/TaxScheme/TaxTypeCode.

このように、PINT EU では、PINT 共通の business rule を IBR- として定義する一方で、UBL の余剰要素または PINT/EN16931 data model に含まれない要素に対する制約を UBL-CR- として定義している。

ただし、PINT EU の UBL-CR- は、Invoice Response の PEPPOL-T111-B03201 のような parent/ と test="false()" による包括的な fallback rule とは少し性格が異なる。

Invoice Response の fallback rule は、同じ pattern 内の具体 rule に該当しなかった子要素を最後に捕捉して拒否する構造である。

これに対して、PINT EU の UBL-CR-* は、禁止または非推奨とする UBL 要素を個別に列挙する方式である。

Invoice Response の fallback rule:
  parent/allowed-child に具体 rule を置く
  parent/* に test="false()" の catch-all rule を置く

PINT EU の UBL-CR-*:
  使用すべきでない UBL 要素を個別 rule として列挙する

したがって、両者は実装方式は異なるが、目的は共通している。

すなわち、単に UBL schema として妥当であるかを確認するだけでなく、Peppol/PINT の data model として使用できる要素の範囲を制御している。

この点は JP PINT にとって重要である。

JP PINT でも、Shared PINT rules や Japanese jurisdiction specific rules により、必須項目、コードリスト、税制固有条件、金額計算などは検証されている。

しかし、JP PINT syntax binding に定義されていない UBL 要素を、JP PINT data model 外として明確に検出する rule 群は十分に明示されていない。

PINT EU の UBL-CR-* は、JP PINT においても同様の制約ルールが必要であることを示す先例と見ることができる。

JP PINT でこの考え方を採用する場合、二つの方式が考えられる。

方式 概要

UBL-CR-* 型

PINT EU と同様に、使用すべきでない UBL 要素を個別に列挙する方式。既存の PINT EU との整合性を取りやすい。

PINT-JP-BM-* 型

JP PINT syntax binding から許可要素を機械生成し、各親要素ごとに fallback rule を置く方式。JP PINT data model validation であることが明確になる。

PINT EU との整合性を重視するのであれば、UBL-CR-* 型の rule code を採用することも考えられる。

一方、JP PINT の syntax binding に基づく厳格な data model validation であることを明確にするには、PINT-JP-BM-* のような Basic Model rule として定義する方が分かりやすい。

いずれの場合でも重要なのは、UBL schema validation と JP PINT data model validation を区別することである。

UBL 2.1 schema 上は許容される要素であっても、JP PINT syntax binding に定義されていないのであれば、JP PINT としては使用できない、または少なくとも warning/fatal として検出されるべきである。

この観点から、PINT EU の UBL-CR-* は、JP PINT に Basic Rule を追加する必要性を補強する重要な参考例である。

5. JP PINTへの示唆: Basic Ruleによる厳格化

この fallback rule の考え方は、JP PINT にとっても重要である。

JP PINT 2025-Q4 では、syntax binding により、ubl:Invoice を起点として、各 IBT/IBG がどの UBL 要素に対応するかが定義されている [10]。

また、Shared PINT rules と Japanese jurisdiction specific PINT rules により、必須項目、コードリスト、税制固有条件、金額計算などが検証される [11][12]。

しかし、JP PINT には、BIS Invoice Response の basic model pattern に見られるような、「データモデルに含まれない UBL 要素を fallback rule で拒否する」包括的な Basic Rule が明示されていない。

このため、UBL 2.1 のスキーマ上は許容されるが、JP PINT の syntax binding には規定されていない要素が XML 文書に含まれた場合、それを常に validation error として検出できるとは限らない。

これは JP PINT の適合性判断において重要な問題である。

JP PINT を厳格に解釈するのであれば、次の二つを明確に区別する必要がある。

1. UBL 2.1 schema として妥当であること
2. JP PINT data model として妥当であること

UBL schema validation は、UBL で定義された要素構造として正しいかを確認するものである。

一方、JP PINT validation は、JP PINT の syntax binding に定義された業務データモデルに含まれる要素だけが使われているかを確認するものでなければならない。

この二つは同じではない。

したがって、JP PINT においても、BIS Invoice Response の fallback rule と同様に、syntax binding に定義されていない要素を禁止する Basic Rule を追加することが望ましい。

筆者は、2021年当時、PINT の開発および日本への導入検討の過程で、Basic Rule の重要性を指摘した。しかし、OpenPeppol の担当者からは、PINT プロジェクトでは Basic Rule を提供しないとの回答があった。

その後、PINT EU において Basic Rule が提供された経緯を踏まえても、各地域の PINT 実装において、それぞれの syntax binding に対応した Basic Rule を整備することは必要であると考える。

この Basic Rule は、次の考え方で定義できる。

1. 各親要素について、JP PINT syntax binding に定義された子要素を列挙する。
2. 定義済みの子要素については、より具体的な rule を置く。
3. 最後に parent/* の fallback rule を置く。
4. fallback rule では test="false()" とし、未定義要素を validation error とする。

この方式により、JP PINT に規定された要素は受け入れ、JP PINT に規定されていない UBL 要素は拒否できる。

これは、JP PINT の適合性を「UBL として正しい」レベルから、「JP PINT の data model として正しい」レベルへ厳格化するために必要である。

6. JP PINT Basic Rule定義案

6.1. 基本方針

JP PINT Basic Rule は、JP PINT syntax binding に定義された UBL 要素だけを許可し、それ以外の UBL 要素を禁止するための validation rule である。

ここでいう Basic Rule は、既存の Shared PINT rules や Japanese jurisdiction specific rules を置き換えるものではない。

それらが主として業務ルール、税制固有ルール、コードリスト、金額計算などを検証するのに対し、Basic Rule は「JP PINT data model に含まれる要素だけが文書中に現れているか」を検証する層である。

この rule set は、次を目的とする。

1. JP PINT syntax binding に定義されていない UBL 要素を禁止する。
2. 定義済み要素については、対応する具体 rule により処理する。
3. 具体 rule に該当しない要素は fallback rule により拒否する。
4. UBL schema validity と JP PINT model validity を区別する。

6.2. Rule ID体系案

Basic Rule の rule ID は、既存の IBR-、ALIGNED-IBR-、および BIS Billing の UBL-CR-* と区別するため、次のような体系とする。

PINT-JP-BM-xxx

ここで、BM は Basic Model を意味する。

例:

Rule ID 意味

PINT-JP-BM-001

Document root MUST be ubl:Invoice.

PINT-JP-BM-010

ubl:Invoice MUST NOT contain child elements not part of the JP PINT data model.

PINT-JP-BM-020

cac:InvoicePeriod MUST NOT contain child elements not part of the JP PINT data model.

PINT-JP-BM-030

cac:AdditionalDocumentReference MUST NOT contain child elements not part of the JP PINT data model.

PINT-JP-BM-040

cac:AccountingSupplierParty/cac:Party MUST NOT contain child elements not part of the JP PINT data model.

PINT-JP-BM-050

cac:TaxTotal MUST NOT contain child elements not part of the JP PINT data model.

PINT-JP-BM-060

cac:InvoiceLine MUST NOT contain child elements not part of the JP PINT data model.

このように、rule code 体系を分けることで、JP PINT の検証ルールを次のように整理できる。

IBR-* / ALIGNED-IBR-*
  業務ルール、税制固有ルール、コードリスト、金額計算など

PINT-JP-BM-*
  JP PINT syntax binding に基づく basic model rule
  すなわち、定義されていない UBL 要素・属性の禁止

6.3. Schematron定義例

以下の Schematron は、Basic Rule の設計方針を示すための例である。

実際の JP PINT Basic Rule は、JP PINT syntax binding から機械生成するのが望ましい。手作業で全親要素の whitelist を作成すると、漏れや selector 条件の誤りが生じやすいからである。

6.3.1. root要素の確認

JP PINT の syntax binding は ubl:Invoice を root として示している [10]。

したがって、最初の Basic Rule は root の確認である。

<sch:pattern id="PINT-JP-BASIC-ROOT">
  <sch:rule context="/*">
    <sch:assert id="PINT-JP-BM-001"
                flag="fatal"
                test="self::ubl:Invoice">
      [PINT-JP-BM-001]-Document root element MUST be ubl:Invoice for JP PINT Invoice.
    </sch:assert>
  </sch:rule>
</sch:pattern>

6.3.2. ubl:Invoice直下の未定義要素を禁止するfallback rule

これは root 直下の代表例である。

実際には、JP PINT syntax binding から許可要素一覧を完全に生成する必要がある。

<sch:pattern id="PINT-JP-BASIC-MODEL-INVOICE">

  <!-- Allowed root child elements defined by JP PINT syntax binding -->
  <sch:rule context="/ubl:Invoice/cbc:CustomizationID"/>
  <sch:rule context="/ubl:Invoice/cbc:ProfileID"/>
  <sch:rule context="/ubl:Invoice/cbc:ID"/>
  <sch:rule context="/ubl:Invoice/cbc:IssueDate"/>
  <sch:rule context="/ubl:Invoice/cbc:IssueTime"/>
  <sch:rule context="/ubl:Invoice/cbc:DueDate"/>
  <sch:rule context="/ubl:Invoice/cbc:InvoiceTypeCode"/>
  <sch:rule context="/ubl:Invoice/cbc:Note"/>
  <sch:rule context="/ubl:Invoice/cbc:TaxPointDate"/>
  <sch:rule context="/ubl:Invoice/cbc:DocumentCurrencyCode"/>
  <sch:rule context="/ubl:Invoice/cbc:TaxCurrencyCode"/>
  <sch:rule context="/ubl:Invoice/cbc:AccountingCost"/>
  <sch:rule context="/ubl:Invoice/cbc:BuyerReference"/>

  <sch:rule context="/ubl:Invoice/cac:InvoicePeriod"/>
  <sch:rule context="/ubl:Invoice/cac:OrderReference"/>
  <sch:rule context="/ubl:Invoice/cac:BillingReference"/>
  <sch:rule context="/ubl:Invoice/cac:DespatchDocumentReference"/>
  <sch:rule context="/ubl:Invoice/cac:ReceiptDocumentReference"/>
  <sch:rule context="/ubl:Invoice/cac:OriginatorDocumentReference"/>
  <sch:rule context="/ubl:Invoice/cac:ContractDocumentReference"/>
  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference"/>
  <sch:rule context="/ubl:Invoice/cac:ProjectReference"/>
  <sch:rule context="/ubl:Invoice/cac:AccountingSupplierParty"/>
  <sch:rule context="/ubl:Invoice/cac:AccountingCustomerParty"/>
  <sch:rule context="/ubl:Invoice/cac:PayeeParty"/>
  <sch:rule context="/ubl:Invoice/cac:TaxRepresentativeParty"/>
  <sch:rule context="/ubl:Invoice/cac:Delivery"/>
  <sch:rule context="/ubl:Invoice/cac:PaymentMeans"/>
  <sch:rule context="/ubl:Invoice/cac:PaymentTerms"/>
  <sch:rule context="/ubl:Invoice/cac:AllowanceCharge"/>
  <sch:rule context="/ubl:Invoice/cac:TaxTotal"/>
  <sch:rule context="/ubl:Invoice/cac:LegalMonetaryTotal"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine"/>

  <!-- Fallback rule -->
  <sch:rule context="/ubl:Invoice/*">
    <sch:assert id="PINT-JP-BM-010"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-010]-Document MUST NOT contain elements under ubl:Invoice that are not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

</sch:pattern>

6.3.3. cac:InvoicePeriodのBasic Rule

JP PINT syntax binding では、cac:InvoicePeriod の子要素として、cbc:StartDate、cbc:EndDate、cbc:DescriptionCode が示されている [10]。

<sch:pattern id="PINT-JP-BASIC-MODEL-INVOICE-PERIOD">

  <sch:rule context="/ubl:Invoice/cac:InvoicePeriod/cbc:StartDate"/>
  <sch:rule context="/ubl:Invoice/cac:InvoicePeriod/cbc:EndDate"/>
  <sch:rule context="/ubl:Invoice/cac:InvoicePeriod/cbc:DescriptionCode"/>

  <sch:rule context="/ubl:Invoice/cac:InvoicePeriod/*">
    <sch:assert id="PINT-JP-BM-020"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-020]-Invoice period MUST NOT contain elements not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

</sch:pattern>

6.3.4. cac:AdditionalDocumentReferenceのBasic Rule

JP PINT では、cac:AdditionalDocumentReference は、cbc:DocumentTypeCode = 130 の場合は invoiced object identifier として、cbc:DocumentTypeCode != 130 の場合は additional supporting document として扱われる。

syntax binding 上も、この二つの selector が示されている [10]。

<sch:pattern id="PINT-JP-BASIC-MODEL-ADDITIONAL-DOCUMENT-REFERENCE">

  <!-- Invoiced object identifier -->
  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference[cbc:DocumentTypeCode = '130']/cbc:ID"/>
  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference[cbc:DocumentTypeCode = '130']/cbc:DocumentTypeCode"/>

  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference[cbc:DocumentTypeCode = '130']/*">
    <sch:assert id="PINT-JP-BM-030A"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-030A]-AdditionalDocumentReference for invoiced object identifier MUST NOT contain elements not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

  <!-- Additional supporting document -->
  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference[not(cbc:DocumentTypeCode = '130')]/cbc:ID"/>
  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference[not(cbc:DocumentTypeCode = '130')]/cbc:DocumentDescription"/>
  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference[not(cbc:DocumentTypeCode = '130')]/cac:Attachment"/>

  <sch:rule context="/ubl:Invoice/cac:AdditionalDocumentReference[not(cbc:DocumentTypeCode = '130')]/*">
    <sch:assert id="PINT-JP-BM-030B"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-030B]-Additional supporting document MUST NOT contain elements not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

</sch:pattern>

6.3.5. cac:TaxTotalのBasic Rule

JP PINT では、文書通貨の tax total と税会計通貨の tax total が、同じ cac:TaxTotal 要素を条件で使い分けている。

syntax binding では、文書通貨側の cac:TaxTotal と、税会計通貨側の cac:TaxTotal が別グループとして示されている [10]。

公開ページの selector 表記は実装時に慎重に確認すべきだが、意図としては次のように、cbc:TaxAmount/@currencyID と cbc:DocumentCurrencyCode または cbc:TaxCurrencyCode を比較する形になるはずである。

<sch:pattern id="PINT-JP-BASIC-MODEL-TAXTOTAL">

  <!-- Tax total in document currency -->
  <sch:rule context="/ubl:Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID = /ubl:Invoice/cbc:DocumentCurrencyCode]/cbc:TaxAmount"/>
  <sch:rule context="/ubl:Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID = /ubl:Invoice/cbc:DocumentCurrencyCode]/cac:TaxSubtotal"/>

  <sch:rule context="/ubl:Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID = /ubl:Invoice/cbc:DocumentCurrencyCode]/*">
    <sch:assert id="PINT-JP-BM-050A"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-050A]-TaxTotal in document currency MUST NOT contain elements not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

  <!-- Tax total in tax accounting currency -->
  <sch:rule context="/ubl:Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID = /ubl:Invoice/cbc:TaxCurrencyCode]/cbc:TaxAmount"/>
  <sch:rule context="/ubl:Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID = /ubl:Invoice/cbc:TaxCurrencyCode]/cac:TaxSubtotal"/>

  <sch:rule context="/ubl:Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID = /ubl:Invoice/cbc:TaxCurrencyCode]/*">
    <sch:assert id="PINT-JP-BM-050B"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-050B]-TaxTotal in tax accounting currency MUST NOT contain elements not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

</sch:pattern>

6.3.6. cac:InvoiceLineのBasic Rule

JP PINT syntax binding では、cac:InvoiceLine が 1..n として定義され、その下に cbc:ID、cbc:Note、cbc:InvoicedQuantity、cbc:LineExtensionAmount、cbc:AccountingCost、cac:InvoicePeriod、cac:OrderLineReference などが定義されている [10]。

<sch:pattern id="PINT-JP-BASIC-MODEL-INVOICE-LINE">

  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cbc:ID"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cbc:Note"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cbc:InvoicedQuantity"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cbc:AccountingCost"/>

  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cac:InvoicePeriod"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cac:OrderLineReference"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cac:DocumentReference"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cac:AllowanceCharge"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cac:Item"/>
  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/cac:Price"/>

  <sch:rule context="/ubl:Invoice/cac:InvoiceLine/*">
    <sch:assert id="PINT-JP-BM-060"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-060]-Invoice line MUST NOT contain elements not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

</sch:pattern>

6.4. 機械生成ルールとしての定義

最終的には、上記のような rule を手作業で書くのではなく、syntax binding から次の形式で自動生成するのが安全である。

For each parent path P in the syntax binding:

  1. Collect all child element names C1..Cn directly defined under P.
  2. Generate one empty rule for each allowed child path:
       <rule context="P/Ci"/>
  3. Generate one fallback rule:
       <rule context="P/*">
         <assert test="false()">
           Document MUST NOT contain elements under P
           that are not part of the JP PINT data model.
         </assert>
       </rule>
  4. If the same UBL element is used for different semantic groups with selector predicates,
     generate separate rule groups for each selector.
  5. Attribute rules SHALL be generated separately from element rules.

この生成規則により、JP PINT syntax binding に現れるすべての complex element について、未定義子要素を禁止する Basic Rule を作成できる。

6.5. 属性に対するBasic Rule

未定義要素だけでなく、未定義属性も禁止対象にするのが望ましい。

JP PINT syntax binding では、たとえば @schemeID、@currencyID、@unitCode、@mimeCode、@filename、@listID などの属性が個別に定義されている [10]。

したがって、要素だけでなく、属性についても「定義済み属性だけを許可し、それ以外を fallback rule で拒否する」仕組みが必要である。

例:

<sch:pattern id="PINT-JP-BASIC-MODEL-ATTRIBUTES">

  <sch:rule context="/ubl:Invoice/cbc:DocumentCurrencyCode/@*">
    <sch:assert id="PINT-JP-BM-A001"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-A001]-DocumentCurrencyCode MUST NOT contain attributes not part of the JP PINT data model.
    </sch:assert>
  </sch:rule>

  <sch:rule context="/ubl:Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount/@currencyID"/>

  <sch:rule context="/ubl:Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount/@*">
    <sch:assert id="PINT-JP-BM-A002"
                flag="fatal"
                test="false()">
      [PINT-JP-BM-A002]-PayableAmount MUST NOT contain attributes other than currencyID.
    </sch:assert>
  </sch:rule>

</sch:pattern>

ただし、属性の場合には注意が必要である。

空 rule と fallback rule の順序だけでは、処理系によって意図どおりに特定属性だけを除外できるかを慎重に確認する必要がある。

そのため、属性については次のように、許可属性名を明示的に列挙した assert を使う方法も考えられる。

<sch:rule context="/ubl:Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount">
  <sch:assert id="PINT-JP-BM-A002"
              flag="fatal"
              test="not(@*[not(local-name() = 'currencyID')])">
    [PINT-JP-BM-A002]-PayableAmount MUST NOT contain attributes other than currencyID.
  </sch:assert>
</sch:rule>

この方式であれば、特定の要素に許可される属性を明示的に管理できる。

7. 追加すべき説明案

Invoice Response の profile page、syntax page、または rule page に、次のような注記を追加すると、誤解を減らすことができる。

Note

PEPPOL-T111-B03201 is a fallback validation rule for cac:Status.

It does not reject the documented child elements of cac:Status.

The permitted child elements are:

  • cbc:StatusReasonCode

  • cbc:StatusReason

  • cac:Condition

These child elements are handled by more specific rules in the same Schematron pattern.

PEPPOL-T111-B03201 rejects only other child elements of cac:Status that are not part of the T111 data model.

さらに、cbc:StatusReasonCode については、次のような説明も有用である。

Note

cbc:StatusReasonCode is a valid child element of cac:Status.

It is validated by the following rules:

  • PEPPOL-T111-B03301

  • PEPPOL-T111-B03302

  • PEPPOL-T111-B03303

In addition, where cbc:ResponseCode is CA, UQ or RE, the presence of cac:Status/cbc:StatusReasonCode is required by PEPPOL-T111-R001.

Where the clarification code is OTH, cbc:StatusReason should be provided according to PEPPOL-T111-R002.

Where the clarification code is PPD, cbc:StatusReason shall be provided according to PEPPOL-T111-R004.

JP PINT についても、次のような注記を syntax binding または rule index に追加することが望ましい。

Note

JP PINT validation should distinguish UBL schema validity from JP PINT data model validity.

UBL elements that are valid according to UBL 2.1 but are not defined in the JP PINT syntax binding should be rejected by JP PINT Basic Model Rules.

Such Basic Model Rules should be generated from the JP PINT syntax binding by listing allowed child elements for each parent element and adding a fallback rule for any other child element.

8. まとめ

PEPPOL-T111-B03201 は、cac:Status の子要素をすべて禁止する rule ではない。

正しい理解は、次のとおりである。

  • cbc:StatusReasonCode は、cac:Status の正式な子要素である。

  • cbc:StatusReason は、cac:Status の正式な子要素である。

  • cac:Condition は、cac:Status の正式な子要素である。

  • cbc:StatusReasonCode は、B03301、B03302、B03303 により、値、listID の存在、listID の値が検証される。

  • ResponseCode が CA、UQ、RE の場合、R001 により StatusReasonCode が必須になる。

  • StatusReasonCode が OTH の場合、R002 により StatusReason の提供が推奨される。

  • StatusReasonCode が PPD の場合、R004 により StatusReason が必須になる。

  • PEPPOL-T111-B03201 は、これらの定義済み子要素以外が cac:Status の下に現れた場合にエラーとする fallback rule である。

したがって、PEPPOL-T111-B03201 の standalone rule page は、実行可能 Schematron の一部としては正しいものの、それだけでは誤解を招きやすい表示である。

この fallback rule の考え方は、JP PINT においても重要である。

JP PINT では、Shared PINT rules と Japanese jurisdiction specific rules により、業務ルール、税制固有ルール、コードリスト、計算ルールは検証されている。

しかし、それだけでは、UBL schema 上は許容されるが JP PINT syntax binding には定義されていない要素を一律に禁止することはできない。

そのため、JP PINT の厳格な適合性検証には、syntax binding から生成した Basic Rule が必要である。

この Basic Rule では、各親要素について、定義済み子要素を具体 rule として先に定義し、最後に parent/* の fallback rule を置く。

fallback rule は test="false()" とし、JP PINT data model に含まれない要素を validation error とする。

OpenPeppol BIS Billing の rule code 体系を見ると、EN 16931 由来の BR-、Peppol 固有の PEPPOL-EN16931-、UBL 構文制約の UBL-CR-*、国別 rule が区別されている。

同様に、JP PINT でも、既存の business rule とは別に、PINT-JP-BM-* のような basic model rule 体系を設けることで、syntax binding に定義されていない要素や属性を明確に検出できる。

これにより、JP PINT の適合性検証は、「UBL として妥当である」ことの確認から、「JP PINT の業務データモデルとして妥当である」ことの確認へと厳格化できる。

参考文献

Share this…

投稿日

カテゴリー:

,

投稿者:

Nobuyuki

タグ:

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です