Visits: 461
PINTが必要ですか
PINTが提供する新機能に対して議論が尽くされているか疑問です。
PINTでは、実装仕様が異なるデジタルインイスでも共通項目（Shared）の範囲のデータは受け取ることとされています。共通項目（Shared）の範囲だけでは日本における『適格請求書』の要件を満たしていないので、日本版の機能拡張(Aligned)が定義されているわけですから、実装仕様が異なるデジタルインイスは、消費税の仕入税額控除制度における適格請求書として使えません。実装仕様が異なるデジタルインイスは受け付けられないという従来のBIS Billing 3.0をわざわざPINT対応に変更することの意味は何でしょうか。付加価値税(VAT)の詳細は、EU加盟国それぞれで異なると思いますので、EUにおいても状況は同様だと思います。それぞれの地域での機能拡張(Aligned)は、それぞれの地域における付加価値税(VAT)の違いに基づくものが多いと思われます。「実装仕様が異なるデジタルインイスでも受け取りなさい。」というPINTが役に立つ場面があるのでしょうか。
海外からのデジタルインボイスであっても適格請求書の記載事項が記録されたデジタルインボイスを受け取りたいものです。
「税率ごとに区分した消費税額等（外貨）(IBT-117 TAX category tax amount）」は必須項目なので記載さているものの、Alignedで拡張した「税率ごとに区分した消費税額等（日本円）（IBT-190 TAX category tax amount in accounting currency（Sharedでは任意項目）」が含まれていない、適格請求書の記載事項を満たしていない請求書データは、受け取りたくないですね。
注1 PINTは、Open Peppol International Invoiceの略語です
注2 外貨建てのインボイスの端数処理の計算
外貨建てのインボイスの端数処理の計算でJP PINTで対応可能な税抜きパターンは、国税庁Q&A 「問56 外貨建取引における適格請求書の記載事項」から次の2パターンが考えられます。
パターン１の「税率ごとに区分した対価の額【円換算後】」は、対応する項目がありませんのでデジタルインボイス上は記録されません。税率ごとに区分した対価の額【外貨税抜】（IBT-116 TAX category taxable amount）と税率ごとに区分した消費税額等【日本円】 （IBT-190 TAX category tax amount in accounting currency）のみデジタルインボイスに記録されています。「税率ごとに区分した対価の額【円換算後】」および円換算レートも記録されていないので、適用された端数処理が正しいか検証できません。
パターン３の「計算過程の消費税額等【外貨】」は、IBT-117 TAX category tax amountですから必須項目です。Q&Aの（注）３では、『消費税額等の端数処理は、「１円未満」の端数が生じた場合に行うものであるため、計算過程の外貨建ての消費税額等を算出する際に、端数処理を行うことはできません。』と説明されていますが、この項目は小数点以下2桁までしか記録できないのでどうしたものでしょうか。また、こちらの場合も外貨についての税額計算の検証ルールはありますが、この金額は端数処理を行わないこととされており、円換算レートも記録されていないので、税率ごとに区分した消費税額等【日本円】を求めるときに適用された端数処理が正しいか検証できません。端数処理の妥当性を検証しようとすれば円換算レートが必要となります。
JP PINTでは、いづれのパターンでも外貨建てのデジタルインボイスに記録されたデータから端数処理が正しいか検証できません。
IBT-190 TAX category tax amount in accounting currency（税率ごとに区分した消費税額等【日本円】）は、Alignedでは必須項目ですがSharedでは任意項目なのでPINTでは記録されていない場合もあります。PINTでは、税率ごとに区分した消費税額等【日本円】が記載されていないデジタルインボイスでもSharedなので受け取らねばならないとされています。
企業の経理業務のDXが最終目的ですから、海外からのデジタルインボイスであっても適格請求書の記載事項が記録された、「文書仕様」に規定された内容（端数処理が正しいこと）が検証済みの、買掛金や未払金の仕訳として記帳可能なデータが記載されているデジタルインボイスを受け取りたいものです。
シンガポールでAlignedとして必要とされた、Tax accounting currency (日本の場合は日本円)での合計請求金額（税込み/税抜き）は、外貨建ての仕訳を個別管理していなければ、日本でも企業の経理業務のDXには必要な項目です。
閑話休題
PINTのC4のCompliance要請は、
“As defined in the more general registered receiving capability”がどのような処理を要求しているのか全く説明がありません。
“As defined in the more general registered receiving capability but may ignore additional distinct content.”についても同様です。
これではプログラム仕様書に展開できませんし、こういったルールが守られているかどうか第3者が検査することもできません。したがって、書かれてはいるが実現したものを検査できない要請です。
先の記事 で書いたISO DP2の「標準化の目的」では次の文書作成ルールが要請されています。
標準規格の目的は、国際貿易と相互理解を支援するために、明確で曖昧なところのない規定を文書化することである。
この目的を達成するために、文書作成では次のことを行う必要がある。
• 規格が対象とする範囲（Scope）で指定している範囲内で完全であること。
注記 1 文書が要件または推奨事項を規定する場合、これらは明示的に記述するか、または他の文書を参照して作成しなければならない。
• 一貫性があり、明確かつ正確であること。
• 最先端技術に関する利用可能なすべての知識を使用して書かれていること。
• 現在の市況を考慮に入れること。
• 将来のこの規格の開発のための枠組み（フレームワーク）を提供すること。
• 規格制定の当初の段階に参加していない専門家や技術者が（後から参加してもその前提が）理解できるようにしておくこと。 及び、
• この文書（DP2)に準拠して作成すること。
Open Peppolが、「文書仕様」「ネットワーク」「運用ルール」に関する仕様だとすれば、その仕様に準拠できているかどうか判断できる一貫性があり、明確かつ正確な文書が不可欠です。「ネットワーク」「運用ルール」については根拠となる文書がありますが、PINTの「文書仕様」については、仕様を記述する文書が公開されているだけで、その仕様定義の際に準拠すべき規定を記述した文書がありません（Peppol International Invoice model review – PINT に2020年の版が公開されていますが、最新版への更新が見られません）。
CEF eInvoiceでは、次のように仕様に準拠することを求めています。BIS Billing 3.0は、eInvoiceの実装の一つとして位置づけられた標準仕様です。
EN 16931 compliance
The invoice document
The electronic invoice document that is created and sent must comply with all the rules that are defined for the CORE invoice or the CIUS specification that it is based on.
This includes that it:
shall contain all mandatory information.
relevant information must be structured as specified.
amounts must be calculated as specified.
elements shall only contain allowed values, such as codes.
（翻訳）
請求書
作成および送信されるデジタルインボイス文書は、コアインボイスに定義されているすべてのルール、または基になる CIUS 仕様に準拠する必要がある。
注3 コアインボイスおよびCIUS (Core Invoice Usage Specification)仕様については、EN 16931-1で規定されています。
これには次のことが含まれる。
- すべての必須情報を含むものとする。
- 関連情報は、指定されたとおりに構成する必要がある。
- 金額は指定どおりに計算する必要がある。
- 要素には、コードなどの許可された値のみを含める必要がある。
注4 この条件を満足した構造と値を持ったデジタルインボイスかどうかC2のサービスプロバイダーが提供されたスキーマトロンファイルで検証しています。検証結果に不備があるとその旨報告されC3には送られません。これと比較したとき、JP PINT(PINT)では、指定されたとおりに構成されていることを検証するBasic Ruleのほとんどが提供されていません。また一部の項目については計算が正しく行われたかチェックするルールも提供されていません。
詳細は、次の記事を参照してください。
BIS Billing 3.0からJP PINT 0.9.3に引き継がれなかった検証ルール 2022-08-10
準拠すべき規格には次があります（図をクリックすると一覧表のページに遷移します）。
無償提供される規格や利用する際のガイドラインといった規格群に準拠しています。BIS Billing 3.0の公開ページの記載はこれらの規定を前提として記述されています。
PINTは、EN 16931からの自立を目指しているようですから、これらの規格群に準拠しているかどうか不明です。PINTが、根拠とする規格文書もありませんので、仕様としては根無し草の状態です。特定の専門家の思惑に依存した状態から脱皮していただきたいと思います。
標準仕様とするには、”more general registered receiving capability”が何を意味するのかを規定する必要があります。”registered receiving capability”が何を意味しているのか、曖昧なところが残らない定義を行った後、”more general registered receiving capability”の定義が必要です。本来これらの用語は、PINTにおける”Shared”,”Aligned”,”Distinct”の用語の定義に基づき、場合を分けて規定していくという正道の規定文書が不可欠です。必ず守らなくてはならない条件と守ることが望ましい条件を明確に区別し定義したうえでそれぞれについて記述していく、そのためには、先ず、基本となる用語や概念を文書で規定したうえで、それらの枠組み（フレームワーク）を用いて規定条件を記述するというのが標準仕様（標準規格）の文書化です。
基礎をしっかり固めたうえで構造物を作り上げないとせっかく構築した構造物が軟弱基盤のため傾いてしまったり崩れ落ちてしまったりといったことはよくニュースになっています。こんなときこそ手戻りのない作業を着実に進めるために技術的な枠組み（フレームワーク）の定義から始めなけばいけません。これが標準化の基本思想であり、産業革命以降の工業化の基礎となる考えかたでしたが、時代遅れでしょうか。2023年秋は、ゴール地点ではなくスタート地点です。
気にされている方は少ないと思いますが、PINT対応では、実装仕様が異なるデジタルインイスの共通項目（Shared）の範囲の項目を受け取るための処理の追加が必要となります。但し、具体的に何をどうすればよいか規定されていないので対処のしようがないかもしれません。対処するとしても、適格請求書として保存できないので、「受け取ったデジタルインボイスは適格請求書の要件を満たしていないので、正しい形式のデジタルインボイスで請求してください。」という連絡を返すことになります。こんなことなら、C2で「形式不備で送付できません。」とC1に通知されたほうが、C1およびC4の時間と労力の無駄が省けます。
C4でPINT対応で必要となる改修は誰のどんなニーズに対応するためなのでしょうか。デジタルインボイスの導入は、適格請求書の保存は当然として、その先にある企業の経理業務のDXが最終目的です。PINTが提供する新機能に対して議論が尽くされているか疑問です。
これに加えて、PINTでは、スキーマトロンで検証される範囲が（Distinctへの対応のためか）小さく限定されたものになりますので、後続のデジタル処理につなげるには、C4でスキーマトロンの検証処理（BIS Biling 3.0ではC2でチェックされていた内容）を追加する必要があります。
PINTにして、うれしいことは何もありません。仕入明細書（self-billing）もBIS Billing 3.0の拡張として定義されるようです。Invoice だけ PINT対応とするメリットはないと思います。
実績のBusDox
また、JP PINT 0.9.3は、当初予定していたPINTの前提であるDDTSではなく、実績のあるBusDoxでスタートします。
BusDoxについては、2014年のJNSAの電子署名に関連した発表資料 をご確認ください。
準備期間18か月
DDTS対応の際の準備期間については、2020年のOpen Peppol発表資料 のスライド48では、18か月とされています。当初の計画では、ネットワークの疎通テストは昨年2021年末を予定していました。その時に着手できていたとても18か月後では、2023年秋は厳しい日程でした。
Open Peppol運営協議会の承認後 18 か月のプロジェクト
- PA がドメイン固有の仕様を適応させるのに 2 か月
- SMP と AP が必要な変更を実装するのに 7 か月
- C4 がPINTを受信する機能を実装するのに 6 ～ 8 か月
それに続いて強制原則の変更 - C1がPINTへの送信を変更するのに6か月
Shared, Aligned, Distinctを区分したJP PINTとせず、Alignedの結果をBIS Billing 3.0の拡張として定義することが望ましいと思います。
関連情報が指定されたとおりに構成されていることを検証するBasic Ruleを提供し、仕様で規定したとおりに計算が正しく行われたかチェックするルールも提供した形に戻す必要があります。
企業の経理業務のDXが最終目的です。
デジタルインボイスに基づいて、具体的にどのようなDXが可能か、という観点から、JP PINTの「文書仕様」の検討や提供される「文書仕様」に基づいて、テストデータをOpen Peppolテスト環境で流通させた上での会計アプリとの連携やZEDI連携も含めた実証実験が必要だと思います。Open Peppolの幅広い導入を推進するうえで、こうした実証実験の成果を紹介することが、大きな説得力となります。
既に環境は整備されています。EIPAには、様々なベンダーが参加されておられるのですから、会計士の先生や税理士の先生方も参加したEIPA主導でのOpen Peppol実証実験の具体化を計画いただきたいと思います。
