Search Posts

Views: 126

Nobuyuki SAMBUICHI
ISO/TC295 Audit data services/SG1 Semantic model Convener

1. JP PINT V1 Complience

JP PINTで記載されている仕様どおりかC2のプロバイダでチェックする条件に不備があります。

1.1. UBL 2.1として妥当かのXMLスキーマチェック

次のXML文書は、デジタル庁から公開されているサンプルインボイスの一部ですが、
提供されているサンプルメッセージ文書に次の問題があります。
<1> XMLスキーマを指定するパラメタ xsi:schemaLocation が定義されていない。
<2> JP PINT V1で公開されているSyntax Bindingに定義されていない要素 <cbc:UBLVersionID> が定義されている。

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" // (1)
	xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
	xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
	xmlns:ccts="urn:un:unece:uncefact:documentation:2"
	xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
	xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDatatypes-2"
	xmlns:udt="urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

	<!--
    Japan common commercial invoice, example1-minimum
    -->

	<cbc:UBLVersionID>2.1</cbc:UBLVersionID> // (2)
	<cbc:CustomizationID>urn:fdc:peppol:jp:billing:3.0</cbc:CustomizationID>	<!-- IBT-024 - Specification identifier -->
	<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>	<!-- IBT-023 - Business process type -->

    以下省略
— デジタル庁
Japan PINT Invoice UBL Example1-minimum.xml

xsi:schemaLocationが定義されていないので市販のXML編集ソフトでファイルを検証するとエラーメッセージが発行されます。

230708Picture1

開発される際にテストデータを確認しようとすると、このエラーメッセージに最初に出会います。
テストされる際には、次のように xsi:schemaLocation を追加すると市販のXML編集ソフトでファイルを検証することができるようになります。

<?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"
	xmlns:ccts="urn:un:unece:uncefact:documentation:2"
	xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
	xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDatatypes-2"
	xmlns:udt="urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2
     http://docs.oasis-open.org/ubl/os-UBL-2.1/xsd/maindoc/UBL-Invoice-2.1.xsd" // (3)
    >

3 xsi:schemaLocation追加行

また、インボイス文書にxsi:schemaLocationが定義されていませんが、Javaでの検証プログラムでは、次のようにxsdPath変数に明示的にXMLスキーマファイルを指定して検証させます。

SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = factory.newSchema(new File(xsdPath));
Validator validator = schema.newValidator();
validator.validate(new StreamSource(new File(xmlPath)));

詳細は、
『Open Peppol C4 で受信したインボイスの検証』 をご確認ください。

1.2. Syntax Bindingで定義されたとおりのXML文書であることが保証されない

BIS Billing 3.0のスキーマトロンの検証ルールには、XML文書がSyntax Bindingに従っているかをテストするためのBasicルールが含まれていました。しかし、PINTでは、欧州以外の各地域版ではBasicルールが提供されていないため、XML文書がSyntax Bindingに従っていることが保証されません。
上記の、Japan PINT Invoice UBL Example1-minimum.xmlには、(2)のようにSyntax Bindingに定義されていない要素 <cbc:UBLVersionID> が定義されていますが、エラーは報告されません。
これに対応するために、BIS Billing 3.0のBasicルールに相当するルールが欧州では提供されていますが、JP PINT対応にBasicルールに相当するルールを開発するのは大変なので、Syntax Bindingで定義された構成に対応する形にOASISから提供されているUBL 2.1のスキーマファイルを変更して、テスト用に使用しています。
詳細は、先に紹介した記事
『Open Peppol C4 で受信したインボイスの検証』 をご確認ください。

テスト用には、次のXMLスキーマファイルを使用しています。

2. Syntax Binding Selector条件が不正確

Syntax Bindingは、論理的な項目や項目グループがXML文書の要素とどのように対応しているかを定義する役割を果たします。BIS Billing 3.0では、UBL 2.1のXMLスキーマに基づいて、UBL要素がどの項目と対応しているかを定義していました。
PINTでは、論理的な項目や項目グループがXML文書のどの要素に対応しているかを示していますが、この対応付けの条件を指定するSelectorに誤りがあり、意味不明な状態になっています。
不正確なSelector条件に関する正誤表が『5. 不正確なSelector条件』に掲載されています。詳細を確認するには、リンク先の記事をご覧ください。
『JP PINT V1.0間違い探し』

3. 合算請求書か判定が困難

JP PINT 3.3.10の「Reference to delivery note」では、Summarised invoiceにおいて納品書(Delivery note)への参照情報をどのように記載するかが説明されています。発行されたデジタルインボイスは全て、ibt-003 Invoice type codeが’380’とされており、Invoice type codeだけではSummarised invoiceかどうかを判定することはできません。
JP PINTでは、売り手がどのように参照情報を記載するかが説明されていますが、次の記事では買い手の立場で、受け取ったデジタルインボイスがSummarised invoiceかどうかを検証しています。
『インボイスが合算請求書か判定できますか』
この記事では、UBLの明細行に記載されている<cbc:DocumentTypeCode>の値から<cbc:ID>に記載された値が納品書番号だと判定できるような例を紹介しています。
JP PINTの例では、品名に記載された”D001″を納品書番号として解釈する根拠が何もありません。そのため、売り手が「納品書番号」を意図していたとしても、買い手にとっては品番D001を1件275,000円の請求書として解釈するしかありません。
改善案として、品名に”summarised invoice”と記載し、DocumentTypeCodeに’270’を指定して納品書番号を記載する方法が考えられます。これにより、買い手はより容易に処理できるでしょう。

4. Document name code 380以外の請求書の利用

JP PINT V1のホームページには、Document name code(Subset: Invoice type code)という項目があり、そこには次のようなコード一覧が表示されています。受け取ったデジタルインボイスには、これらの値が指定されている可能性があります。コードの意味については、ChatGPTとの対話記事 ペポル JP PINT 380以外の電子請求書の利用 を参照してください。
https://docs.peppol.eu/poac/jp/pint-jp/trn-invoice/codelist/UNCL1001-inv/

UNCL1001

5. 計算ルールのなかに検証されていないものがある

JP PINTでは、昨年の記事
https://www.sambuichi.jp/?p=6801『BIS Billing 3.0からJP PINT 0.9.3に引き継がれなかった検証ルール』
で説明したように、Basicルールの廃止だけでなく、金額計算や税率に関連する検証ルールも廃止されています。

また、Syntax bindingのページには、見落としやすい記載がありますので注意が必要です。
これらの条件に留意しながら検証ルールが作成されていることが重要ですが、網羅されていません。

こちらの記事もご確認ください。
『JP PINT解体新書4 C4自動処理と記載金額の検算』

『Open Peppol C4 で受信したインボイスの検証 Part 2』では、
公開サイトからダウンロードできるサンプルインボイスを対象にして、こうした条件に違反したものがないか検証しています。

コメントを残す

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