Visits: 139
JP PINT V1.0の問題箇所へのコメント
請求書処理の文脈において、これらのコメントは一貫性の不足、欠落している要素、および潜在的な改善点を強調しています。提案は、特定の要素に新しいビジネス用語を定義することから、特定の要素の値を整えることまでさまざまです。さらに、例内で欠落している要素を含め、文書内で説明を追加する提案もあります。全体的に、これらのコメントは、PEPPOLフレームワーク内の請求書処理における仕様の明確さと一貫性を向上させ、円滑な実装と相互運用性を確保することを目的としています。
1. Selectorって何?
1.1. XMLセレクタとUBL（Universal Business Language）請求書のXPath
XMLセレクタは、XML文書内の特定の要素やノードを見つけるのに重要な役割を果たします。XML Path Language（XPath）は、XML文書をナビゲートし、クエリするための強力なツールとして機能し、正確な要素の特定を可能にします。
UBL（Universal Business Language）請求書のXML表現を持つシナリオを考えてみましょう。この場合、目標は`Allowance`要素を選択的に識別することですが、それは`ChargeIndicator`属性が`false`に設定されているドキュメントレベルでのみ行います。
以下は、このタスクを達成するためにXPathを使用する例です：
<?xml version=“1.0" encoding=“UTF-8”?>
<Invoice xmlns=“urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac=“urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2”
xmlns:cbc=“urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<!-- ... other invoice elements ... -->
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<!-- ... other allowance charge details ... -->
</cac:AllowanceCharge>
<!-- ... other invoice elements ... -->
</Invoice>`ChargeIndicator`が`false`に設定されている`Allowance`要素を単独で抽出するには、次のXPath式を使用できます：
//cac:AllowanceCharge[cbc:ChargeIndicator = ‘false’]この式の詳細を見てみましょう：
– // はXML文書内の任意の場所からノードを選択します。
– cac:AllowanceCharge はXML内の`AllowanceCharge`要素を対象とします。
– [cbc:ChargeIndicator = 'false'] は述語として機能し、`ChargeIndicator`という子要素が`false`というテキスト値を持つ条件に基づいて`AllowanceCharge`要素をフィルタリングします。
ただし、このセレクタは文書レベルと行アイテムレベルの両方の手当を取得することに注意してください。文書レベルの`AllowanceCharge`要素だけを選択したい場合、これらの要素の特定のコンテキストを考慮したXPath式を使用できます。文書レベルの`AllowanceCharge`要素がルートの`Invoice`要素の直下にあると仮定すると、次のXPath式が使用できます：
/Invoice/cac:AllowanceCharge[cbc:ChargeIndicator = ‘false’]この修正された式の動作は以下の通りです：
– /Invoice はルートの`Invoice`要素を特定します。
– /cac:AllowanceCharge[cbc:ChargeIndicator = 'false'] は`Invoice`要素の直接の子で、子要素`ChargeIndicator`の値が`false`である`AllowanceCharge`要素を選択します。これにより、文書レベルの`AllowanceCharge`要素が排他的に選択されます。
1.2. cac:PartyTaxScheme[cac:TaxScheme = “VAT”]におけるセレクタの問題
Syntax binding定義表では、IBT-031 Seller TAX identifierの上にPARTY TAX •• cac:PartyTaxScheme [cac:TaxScheme = “VAT”] という行が定義されています。ここに記載されているセレクタ`[cac:TaxScheme = “VAT”]`は、複雑型である`TaxScheme`という要素が文字列`VAT`である要素を特定しようとする試みのようです。ただし、このセレクタには根本的な問題があります。それは、`TaxScheme`が単純なテキスト要素ではなく、複雑型であるという性質から生じています。
XMLでは、複雑型は一般的に子要素や属性を含み、直接テキストコンテンツを持たないため、`=`演算子を使用して比較することができません。UBL XML構造の説明に基づくと、関連情報は`cac:TaxScheme`という複雑型内の`cbc:ID`という子要素に存在すします。したがって、`cac:TaxScheme`内の`cbc:ID`の値に基づいて要素を正確に選択するには、まずその子要素に移動し、その値を比較する必要があります。
XML編集ソフトXML SpyでXPathを指定するとそのXPathが指定する要素が表示されますが、Syntax binding表に基づいて定義した次のXPathでは、該当する要素は見つかりません。
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme = "VAT"]
以下は、XPath式を調整して、`cbc:ID`の値が`VAT`と一致するものを選択する方法の例です：
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = "VAT"]
この修正された式について説明します：
– /Invoice/cac:AccountingSupplierParty/cac:Party/ はXMLドキュメント内のルート要素の子孫要素cac:Partyから選択します。
– cac:PartyTaxScheme は`cac:PartyTaxScheme`要素を特定します。
– [cac:TaxScheme/cbc:ID != ‘VAT’] は、条件として`cac:TaxScheme`子要素内の`cbc:ID`孫要素が`VAT`と等しい要素をフィルタリングする述語として機能します。
2. XPathの採用によるJP PINT標準の向上
CEN/TC 16931-3-2は、EN-16,931-1で規定している電子インボイスとUBL2.1の対応を規定しています。
対応表として、Table3とTable4が提供されており、それぞれセマンティックモデルとXMLパスの要素の対応関係を示しています。
Table3はnormativeで、Table4はinformativeとされ、これにはそれぞれ理由があります。
Table3とTable4は、EN-16,931-1で規定されている電子インボイスとUBL2.1との関係をマッピングするために異なる、しかし補完的な目的を持っています。Table3は、セマンティックモデルがどのXMLパスの要素に対応しているかを理解するのに役立ち、電子インボイスの要素をUBL2.1に翻訳する明確な手法を提供します。一方、Table4は逆のマッピングを提供し、XMLパス上の要素がどのセマンティックモデルの項目に対応するかを示します。両方のテーブルを持つことで、ユーザーは両方の方向でマッピングを簡単に相互参照して検証することができます。
以下省略
Table 3
以下省略
Table 4
Table3とTable4の間の規範と参考資料という区別は重要です。Table3は規範であり、電子インボイスのマッピングをUBL2.1に対して一貫して正確に実装するためには不可欠な部分です。一方で、Table4は参考資料であり、マッピングを理解するのを助けるもので、実装のためには必須ではありません。これは、ユーザーがマッピングを解釈し、適用するのを助け、電子インボイスとUBL2.1要素間の関係の理解を深めるためのガイドです。
2.1. XPathの採用のメリット
しかしながら、この標準化の進め方には、改善の余地があると考えられます。
具体的には、XML要素の定義において、Pathの代わりにXPathを採用することで、より効率的で正確なマッピングが可能になるという点です。
Table3のBT-18 Invoiced object identifierには、Rule欄に “with cbc:DocumentTypeCode = 130” という設定が記載されています。これは、パスにRuleの文書記述が含まれていることを意味しますが、これを機械が理解しやすくするためには人間が読んで解釈し、それをプログラムコードに変換する作業が必要です。この作業は時間がかかるうえに、解釈のバリエーションやエラーのリスクが伴います。
もしXPathでの定義が与えられていた場合、この手間が大幅に削減され、より効率的なデータ処理が可能になります。XPathは、XMLドキュメント内の要素や属性に対するクエリ言語で、精密なデータ抽出と操作を可能にします。XPathの使用により、人間による解釈のステップをスキップし、コンピュータプログラムがRuleの内容を自動的に解釈してデータ変換を行うプロセスを直接、正確、かつ迅速に実行できます。これによって、データの一貫性が保たれ、エラーや解釈の違いに起因する問題が最小限に抑えられます。
XPathの採用には、多くのメリットがあります。それは、複雑なXMLドキュメントのナビゲーションを容易にし、特定のエレメントやアトリビュートを効率的に検索・選択する能力を持っているからです。この特性により、電子インボイスとUBL2.1間のマッピングをより柔軟で精緻に行うことが可能となります。
2.2. ペポルへの提案
ペポルが、グローバルに採用され、幅広い産業で利用されている現状を鑑み、標準の精度と効率性の向上は必須です。
XPathの採用は、この標準を次のレベルに引き上げ、より多くの組織がスムーズに採用できる道を開くでしょう。
その第一歩として、XPathの採用をOpen Peppolに強く推奨し、Selectorの記述が従来のパス定義に追加されましたが、その精度にはまだ改善の余地があります。
次のサイトでは、パス定義をXPathに置き換えた対応表をそれぞれ提供しています。
3. 構文バインディングのセレクタ指定で正しく定義されているもの
3.1. Additional Document Reference (DocumentTypeCode = 130)におけるセレクタ
Additional document reference class:
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AdditionalDocumentReference-1/
3.1.1. コメント
Status:
正しい。
現在のセレクタ指定: [cbc:DocumentTypeCode = 130]
解釈されたXPath:
/Invoice/cac:AdditionalDocumentReference[cbc:DocumentTypeCode = 130]
3.2. LINE OBJECT IDENTIFIERにおけるセレクタ
LINE OBJECT IDENTIFIER
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-DocumentReference-2/
3.2.1. コメント
Status:
問題なし。このセレクタは、”DocumentTypeCode” が 130 と等しい要素を正しく選択することを意図しています。
現在のセレクタ指定: [cbc:DocumentTypeCode = 130]
解釈されたXPath:
/Invoice/cac:InvoiceLine/cac:DocumentReference[cbc:DocumentTypeCode = 130]
4. 構文バインディングのセレクタ指定の課題
4.1. Additional Document Reference (DocumentTypeCode != 130)におけるセレクタの問題
ADDITIONAL SUPPORTING DOCUMENTS
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AdditionalDocumentReference-2/
4.1.1. コメント
状態:
cbc:DocumentTypeCode要素の定義がSyntax bindingの一覧表に記載されていませんので、UBL 2.1の定義が適用されます。cbc:DocumentTypeCode要素は必須ではありません。
元のセレクタ cbc:DocumentTypeCode != 130 は、`DocumentTypeCode`が130と等しくない要素を選択しようとしていることを示唆しています。ただし、このセレクタには潜在的な問題があり、すべてのインスタンスで`cbc:DocumentTypeCode`が常に定義されていると仮定しているため、そうでない場合があるかもしれません。
任意要素(0..1)ですから、もし`cbc:DocumentTypeCode`が未定義の場合、このセレクタはcac:DocumentReference要素を返さない可能性があります。
現在のセレクタ指定: [cbc:DocumentTypeCode != 130]
解釈されたXPath:
/Invoice/cac:AdditionalDocumentReference[cbc:DocumentTypeCode != 130]
*改訂されたXPath:
/Invoice/cac:AdditionalDocumentReference[not(cbc:DocumentTypeCode = 130)]
4.1.2. 改善案
改訂されたセレクタ: [not(cbc:DocumentTypeCode = 130)]
Syntax binding一覧表に記載されていない要素は、基本的に使用禁止と解釈されます。cbc:DocumentTypeCode要素の定義を明細行と同様にSyntax bindingの一覧表に記載することでこの要素の定義が必要なことを規定すべきでしょう。
4.2. Party Identification (SEPA scheme)におけるセレクタの問題
Bank assigned creditor identifier
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AccountingSupplierParty/cac-Party/cac-PartyIdentification-1/
4.2.1. コメント
問題点:
正しい名前空間 “cbc:” を指定せずに “cac:ID” を使用する誤った使い方です。”ID” の前には “cbc:” の接頭辞が必要です。 “cac:” ではなく “cbc:” の接頭辞が必要です。
現在のセレクタ指定: [cac:ID/@schemeID = “SEPA”]
解釈されたXPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification[cac:ID/@schemeID = “SEPA”]
改訂されたXPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification[cbc:ID/@schemeID = “SEPA”]
4.2.2. 改善案
改訂されたセレクタ: [cbc:ID/@schemeID = “SEPA”]
4.3. Party Tax Scheme (TaxScheme = “VAT”)におけるセレクタの問題
4.3.1. コメント
問題:
cac:TaxScheme内の比較対象の子要素を指定していない。
現在のセレクタ指定: [cac:TaxScheme = “VAT”]
解釈されたXPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme = “VAT”]
改訂されたXPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID = “VAT”]
4.3.2. 改善案
改訂されたセレクタ: [cac:TaxScheme/cbc:ID = “VAT”]
4.4. Party Tax Scheme (Not Equal to “VAT”)におけるセレクタの問題
4.4.1. コメント
問題点:
前の問題と同様に、cac:TaxScheme 内の比較対象の子要素を指定していません。
現在のセレクタ指定: [cac:TaxScheme != “VAT”]
解釈されたXPath:
/invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme != “VAT”]
改訂されたXPath:
/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme[cac:TaxScheme/cbc:ID != “VAT”]
4.4.2. 改善案
改訂されたセレクタ: [cac:TaxScheme/cbc:ID != “VAT”]
4.5. Allowance Charge (ChargeIndicator = false)におけるセレクタの問題
DOCUMENT LEVEL ALLOWANCES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AllowanceCharge-1/
4.5.1. コメント
問題点:
“false” の周りに二重引用符がないことが問題です。元のセレクター cbc:ChargeIndicator = false は、”ChargeIndicator” が true である要素を選択しようとしているようです。しかし、これには潜在的な問題があり、それは文字列値 “false” と比較していないためです。 “ChargeIndicator” が文字列として表現されている場合、文字列比較を行うことが重要です。
現在のセレクタ
cbc:ChargeIndicator = false
解釈されたXPath:
/Invoice/cac:AllowanceCharge/[cbc:ChargeIndicator = false]
改訂されたXPath:
/Invoice/cac:AllowanceCharge[cbc:ChargeIndicator = “false”]
4.5.2. 改善案
改訂されたセレクタ: [cbc:ChargeIndicator = “false”]
4.6. Allowance Charge (ChargeIndicator = true)におけるセレクタの問題
DOCUMENT LEVEL CHARGES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-AllowanceCharge-2/
4.6.1. コメント
問題点:
“true” の周りに二重引用符がありません。元のセレクター cbc:ChargeIndicator = true は、”ChargeIndicator” が true である要素を選択しようとしているようです。しかし、これには潜在的な問題があり、それは文字列値 “true” と比較していないためです。 “ChargeIndicator” が文字列として表現されている場合、文字列比較を行うことが重要です。
今のセレクタ指定:
cbc:ChargeIndicator = true
解釈されたXPath:
/Invoice/cac:AllowanceCharge/[cbc:ChargeIndicator = true]
改訂されたXPath:
/Invoice/cac:AllowanceCharge[cbc:ChargeIndicator = “true”]
4.6.2. 改善案
改訂されたセレクタ: [cbc:ChargeIndicator = “true”]
4.7. Tax Total (Currency Equals Document Currency Code)におけるセレクタの問題
4.7.1. コメント
問題点:
元のセレクター cac:TaxTotal/TaxAmount/@currency = cbc:DocumentCurrencyCode は、”TaxAmount” 内の “currency” 属性とルートの “DocumentCurrencyCode” を比較しようとしているようですが、この方法ではアクセスできません。正しい比較の文脈が確立されておらず、セレクターには適切な名前空間（たとえば、cac と cbc）がありません。
a) TaxAmount/@currency は、”TaxAmount” 要素の “currency” 属性にアクセスしようとしていることを示唆しています。
b) cbc:DocumentCurrencyCode は、この属性をルートレベルの “cbc:DocumentCurrencyCode” と比較しようとしていることを示唆しています。+
ただし、XML内の正しい構造は異なる場合があり、このセレクターはそれを考慮していません。実際の構造は次のようになるかもしれません。
<Invoice>
<cac:TaxTotal>
<cbc:TaxAmount currencyID=“DocumentCurrencyCode”>...</cbc:TaxAmount>
</cac:TaxTotal>
</Invoice>これを訂正するために、以下の手順を実行します：
c) TaxAmount`には、通貨情報を格納する`currencyID`という名前の属性があるかもしれません。/Invoice/cbc:DocumentCurrencyCode`）。
d) `TaxAmount`には`cac:`という名前空間接頭辞が必要です。
e) `cbc:DocumentCurrencyCode`は文書のルートからアクセスする必要があります（つまり、
したがって、訂正されたセレクタは次のようになります：
cac:TaxTotal[cbc:TaxAmount/@currencyID = /Invoice/cbc:DocumentCurrencyCode]
この訂正されたセレクタでは、cac:TaxAmount`要素の@currencyID`属性にアクセスし、それをルートレベルの`cbc:DocumentCurrencyCode`と比較します。これは意図された動作です。
@currency`から@currencyID`への変更と、位置の調整により、XML構造内の関連する値に正しくアクセスし、比較できるようになります。
現在のセレクタ指定: [cac:TaxTotal/TaxAmount/@currency = cbc:DocumentCurrencyCode]
解釈されたXPath:
/Invoice/cac:TaxTotal[cac:TaxTotal/TaxAmount/@currency = cbc:DocumentCurrencyCode]
改訂されたXPath:
/Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID=/Invoice/cbc:DocumentCurrencyCode]
4.7.2. 改善案
改訂されたセレクタ: [cbc:TaxAmount/@currencyID=/Invoice/cbc:DocumentCurrencyCode]
4.8. Tax Total (Currency Equals Tax Currency Code)におけるセレクタの問題
DOCUMENT TOTALS IN TAX ACCOUNTING CURRENCY
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-TaxTotal-2/
4.8.1. コメント
問題点:
a) 元のセレクタcac:TaxTotal/TaxAmount/@currency = cbc:TaxCurrencyCodeは、”TaxAmount”内の”currency”属性をルートから来る”TaxCurrencyCode”と比較しようと試みており、この方法ではアクセスできません。比較のための正しいコンテキストが確立されておらず、セレクタには適切な名前空間（例：cacとcbc）が不足しています。
a) `TaxAmount/@currency`は、”TaxAmount”要素の”currency”属性にアクセスしようとしていることを示唆しています。
b) `cbc:DocumentCurrencyCode`は、この属性をルートレベルの”cbc:TaxCurrencyCode”と比較しようとしていることを意味します。
ただし、XML内の正しい構造は異なる場合があり、このセレクタはそれを考慮していません。実際の構造は次のようになる可能性があります：
<Invoice>
<cac:TaxTotal>
<cbc:TaxAmount currencyID=“TaxCurrencyCode”>...</cbc:TaxAmount>
</cac:TaxTotal>
</Invoice>これを修正するには：+
c) TaxAmount`には通貨情報を格納する`currencyID`という属性がある可能性があります。/Invoice/cbc:DocumentCurrencyCode`）。
d) `TaxAmount`には`cac:`という名前空間接頭辞が必要です。
e) `cbc:DocumentCurrencyCode`は文書のルートからアクセスする必要があります（つまり、
したがって、訂正されたセレクタは次のようになります：
cac:TaxTotal[cbc:TaxAmount/@currencyID = /Invoice/cbc:DocumentCurrencyCode]
この訂正されたセレクタでは：
– cac:TaxTotal[cbc:TaxAmount/@currencyID = /Invoice/cbc:DocumentCurrencyCode]、”cac:TaxAmount”要素の`@currencyID`属性にアクセスし、それをルートレベルの”cbc:TaxCurrencyCode”と比較します。これが意図された動作です。
@currency`から@currencyID`への変更、’TaxAmount’の名前空間接頭辞`cac:`の追加、および場所の調整により、XML構造内の関連する値に正しくアクセスして比較できるようになります。
現在のセレクタ指定: [cac:TaxTotal/TaxAmount/@currency = cbc:TaxCurrencyCode]
解釈された:
/Invoice/cac:TaxTotal[cac:TaxTotal/TaxAmount/@currency = cbc:TaxCurrencyCode]
改訂されたXPath:
/Invoice/cac:TaxTotal[cbc:TaxAmount/@currencyID=/Invoice/cbc:TaxCurrencyCode]
4.8.2. 改善案
改訂されたセレクタ: [cbc:TaxAmount/@currencyID=/Invoice/cbc:TaxCurrencyCode]
4.9. Document Reference (DocumentTypeCode != 130)におけるセレクタの問題
LINE DOCUMENT REFERENCE
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-DocumentReference-1/
4.9.1. コメント
問題点:
元のセレクタ cbc:DocumentTypeCode != 130 は、`DocumentTypeCode`が130と等しくない要素を選択しようとしていることを示唆しています。ただし、このセレクタには潜在的な問題があり、すべてのインスタンスで`cbc:DocumentTypeCode`が常に定義されていると仮定しているため、そうでない場合があるかもしれません。
任意要素(0..1)ですから、もし`cbc:DocumentTypeCode`が未定義の場合、このセレクタはcac:DocumentReference要素を返さない可能性があります。
現在のセレクタ指定: [cbc:DocumentTypeCode != 130]
解釈されたXPath:
/Invoice/cac:InvoiceLine/cac:DocumentReference[cbc:DocumentTypeCode != 130]
改訂されたXPath:
/Invoice/cac:InvoiceLine/cac:DocumentReference[not(cbc:DocumentTypeCode = 130)]
4.9.2. 改善案
改訂されたセレクタ: [not(cbc:DocumentTypeCode = 130)]
4.10. Allowance Charge (ChargeIndicator = false)におけるセレクタの問題
INVOICE LINE ALLOWANCES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-AllowanceCharge-1/
4.10.1. コメント
問題点:
元のセレクタ cbc:ChargeIndicator = false は、`ChargeIndicator`がfalseである要素を選択しようとしているようです。ただし、これには潜在的な問題があり、文字列値`false`と比較していないため、もし`ChargeIndicator`が文字列として表されている場合、文字列比較を使用することが重要です。
現在のセレクタ指定: [cbc:ChargeIndicator = false]
解釈されたXPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = false]
改訂されたXPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = “false”]
4.10.2. 改善案
改訂されたセレクタ: [cbc:ChargeIndicator = “false”]
4.11. Allowance Charge (ChargeIndicator = true)におけるセレクタの問題
INVOICE LINE CHARGES
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-AllowanceCharge-2/
4.11.1. コメント
問題点:
元のセレクタ cbc:ChargeIndicator = true は、`ChargeIndicator`がtrueである要素を選択しようとしているようです。ただし、これには潜在的な問題があり、文字列値`true`と比較していないため、もし`ChargeIndicator`が文字列として表されている場合、文字列比較を使用することが重要です。
現在のセレクタ指定: [cbc:ChargeIndicator = true]
解釈されたXPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = true]
改訂されたXPath:
/Invoice/cac:InvoiceLine/cac:AllowanceCharge[cbc:ChargeIndicator = “true”]
4.11.2. 改善案
改訂された: [cbc:ChargeIndicator = “true”]
4.12. Allowance Charge (ChargeIndicator = false)におけるセレクタ未定義の問題
4.12.1. コメント
問題点:
この文脈にはセレクタが定義されていませんが、ChargeIndicator=“false”の`Price`要素内の要素を正確に指定するためには、XPathが必要です。
セレクタ未定義
XPath Required:
/Invoice/cac:InvoiceLine/cac:Price/cac:AllowanceCharge[cbc:ChargeIndicator=“false”]
4.12.2. 改善案
Selector Required: [cbc:ChargeIndicator=“false”]
5. 仕様文書と構文バインディングの齟齬
5.1. PAYMENT CARD INFORMATIONにおけるfinancial service network provider of the card情報
Page URLs:
– Syntax Binding PAYMENT CARD INFORMATION:
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-PaymentMeans/cac-CardAccount/
– Business Information Specification (BIS) 2.5.2. Card Payment:
https://docs.peppol.eu/poac/jp/pint-jp/bis/#_card_payment
5.1.1. コメント
PAYMENT CARD INFORMATION（IBG-18）の文脈におけるcbc:networkID要素の使用に関して、ビジネス情報仕様（BIS）と関連する構文バインディング間に不一致が存在しています。構文バインディングでは、この要素の存在が義務付けられ、セマンティックビジネス用語にマッピングされていない場合には値”NA”で埋める必要があると指定されています。一方、Card Paymentの説明の2.5.2節では、「必須」とされ、カードの金融サービスネットワークプロバイダを識別するために使用されると示されています（例：VISA、MasterCard、American Expressなど）。
5.1.2. 改善案
この不一致を解消するために、2つの潜在的な解決策を提案します：
-
新しいビジネス用語の定義: cbc:networkID要素の意図した目的を明示的に示す新しいビジネス用語またはセマンティックコンセプトを導入します。このアプローチにより、アプリケーションはデータの文脈に基づいてこの要素を埋めることができ、その使用が意味のあるものになります。
-
値の変更: 代替案として、構文バインディング内でカードの金融サービスネットワークプロバイダの値を “VISA” から “NA” に変更することを検討してください。同時に、2.5.2節の関連する説明を削除することができます。これにより、要素が明示的に金融サービスネットワークプロバイダに関連付けられていない場合を正確に表現できます。
これらの変更のいずれかを実施することで、cbc:networkID要素のBISと構文バインディング間での解釈と使用を調和させることができます。
5.2. 必須要素cbc:LineIDがDESPATCH REFERENCEの例から欠落
page URLs
– Syntax Binding DESPATCH REFERENCE
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/syntax/cac-InvoiceLine/cac-DespatchLineReference/
– Business Information Specification (BIS) 2.3.5. Despatch and receipt advice references
https://docs.peppol.eu/poac/jp/pint-jp/bis/#_despatch_and_receipt_advice_references
5.2.1. コメント
DESPATCH REFERENCEのコンテキストにおいて、構文バインディングと関連するビジネス情報仕様（BIS）との間に注目すべき不整合が存在します。構文バインディングは、cbc:LineID要素の含まれることを義務付け、セマンティックなビジネス用語に明示的にマッピングされていない場合、値を「NA」と指定します。しかし、2.3.5. Despatch and Receipt Advice Referencesのセクションで提供されたBISの例を見ると、cbc:LineID要素が明らかに欠落していることが分かります。
5.2.2. 改善案
この不整合を修正し、構文バインディングとBISの間での整合性を確保するために、以下のアクションを提案します：
-
例示にcbc:LineIDを含める
BISの例にcbc:LineID要素を組み込み、その使用法を値「NA」とともに示す。この追加は、DESPATCH REFERENCEのコンテキストにおけるcbc:LineIDの必要性を説明するのに役立ちます。 -
説明的追加
この例に簡潔な説明を添え、cbc:LineIDの重要性と構文バインディングに従った必須性を明確にします。この説明により、ユーザーはこの要素の意図された使用法とデータ交換における重要性を理解しやすくなります。
これらの提案を実施することで、BISと構文バインディングが調和し、関連する文書全体でDESPATCH REFERENCE要素の表現と解釈に一貫性が確保されます。
Nobuyuki SAMBUICHI
ISO/TC295 Audit data services/SG1 Semantic model Convener
- 1. Selectorって何?
- 2. XPathの採用によるJP PINT標準の向上
- 3. 構文バインディングのセレクタ指定で正しく定義されているもの
- 4. 構文バインディングのセレクタ指定の課題
- 4.1. Additional Document Reference (DocumentTypeCode != 130)におけるセレクタの問題
- 4.2. Party Identification (SEPA scheme)におけるセレクタの問題
- 4.3. Party Tax Scheme (TaxScheme = “VAT”)におけるセレクタの問題
- 4.4. Party Tax Scheme (Not Equal to “VAT”)におけるセレクタの問題
- 4.5. Allowance Charge (ChargeIndicator = false)におけるセレクタの問題
- 4.6. Allowance Charge (ChargeIndicator = true)におけるセレクタの問題
- 4.7. Tax Total (Currency Equals Document Currency Code)におけるセレクタの問題
- 4.8. Tax Total (Currency Equals Tax Currency Code)におけるセレクタの問題
- 4.9. Document Reference (DocumentTypeCode != 130)におけるセレクタの問題
- 4.10. Allowance Charge (ChargeIndicator = false)におけるセレクタの問題
- 4.11. Allowance Charge (ChargeIndicator = true)におけるセレクタの問題
- 4.12. Allowance Charge (ChargeIndicator = false)におけるセレクタ未定義の問題
- 5. 仕様文書と構文バインディングの齟齬
