2023年10月から始まるインボイス制度に向けてPEPPOLの準備も進められており、今年度中には利用が開始される見込みです。
しかし、PEPPOLへの対応が期待されるソフトウェアサービス提供者目線から見ると、その仕組みやコンセプト、仕様などは必ずしもわかりやすいものではなく、何から検討してよいか、何から始めてよいかわからないという状況もあるかもしれません。
今回は少し踏み込んだトピックとして、主に、アクセスポイントを検討されている、
- ERPパッケージや会計ソフト等の事業者様
- 請求書発行・受取関連ソフトウェアサービス等の事業者様
- システムインテグレーター事業者様
向けに、アクセスポイントの「自社開発 vs 外部サービス利用」について、必要な手続や開発・実装に際しての実務的な視点から書いてみたいと思います。
目次
まず最初に
1. アクセスポイントの技術対応
2. PEPPOL仕様等の学習コスト
3. 認定を得るための手続とコスト
4. PEPPOL接続の実装・開発
5. メンテナンスやアップデート対応
6. 運用とサポート
最後にStorecove APIのご紹介
まず最初に
PEPPOLを通じてデジタルインボイスを送受信するためには、
- PEPPOLアクセスポイントとして認証されている事業者と連携する(又はそのサービスを利用する)
- 自ら認証アクセスポイントとなる
のいずれかしかありません。
これはエンドユーザーの事業者だけの話ではなく、ERPパッケージや会計ソフト、請求書関連のデータや業務を扱う各種ソフトウェアプロバイダーにとっても同様です。
結局のところ、PEPPOLへの接続機能を、「自ら作るか、外から買ってくるか」という判断になります。
海外でも、ERPシステム等の各種ソフトウェア事業者は、当初は自ら開発することを選択している事例が多かったようですが、Storecoveのウェブサイトで開示している事例以外にも、「外から買ってくる」アプローチを選択している事例も増えています。
PEPPOLの特徴の一つとして、オープンなネットワークであることがあげられますが、一方でアクセスポイントはPEPPOLネットワークへのゲートウェイであり認証制となっていることから、技術やセキュリティなどにおいて一定の水準が求められます。
仕様が公開されているので接続や実装も簡単にできるかというと、必ずしもそういうわけではありません。現時点で何かが「できる」からと言って、それが必ずしもソフトウェアプロバイダーやそのユーザーにとって最良の選択になるとは限らないと言えます。
では、具体的なポイントを見ていきましょう。
1.アクセスポイントの技術対応
PEPPOLというネットワークへ接続するためには、そこで利用されている技術、セキュリティ要件、送受信する文書のフォーマットなど多くのPEPPOL特有の専門的な要素をマスターする必要があります。また、自ら認定アクセスポイントとなるためには、Peppol Authority(日本の場合はデジタル庁)又はOpen Peppolが定める手続に従い、各種のテストを実施する必要があります。
PEPPOLネットワークに利用されている技術要素は、EDI(Web-EDI)に用いられてきたものが多く、多くのソフトウェア事業者にとって必ずしも親しみがあるものではないかもしれません。しかし、自社開発によってアクセスポイントとして認定を得るには、これらの技術対応は避けては通れない道となります。
2.PEPPOL仕様等の学習コスト
UBL、PINT・BIS、SML/SMP、AS4・・・。
PEPPOLの技術や仕様を理解するうえでのキーワードをいくつか挙げてみました。
自社開発によってPEPPOLアクセスポイントとして認定を得るためには、これらが何を指していて何のためにどう使われるかを理解することは必要不可欠です。
多くのソフトウェア事業者にとって必ずしも一般的ではない技術や仕様を理解するには、相応の学習コストと時間が必要となります。
そして、多くのドキュメントは英語であり、日本語化されていないものも多く存在します。さらに、PEPPOLの仕様のアップデートなどは英語で通知されます。
3.認定を得るための手続とコスト
PEPPOLアクセスポイントとしての認定を得るには、定められた手続を経る必要があり、これには通常時間を要します。
例えば、以下の様な事が求められます。Peppolの各種仕様の理解に加え、多くの事務的な手続も必要になります。
- Open Peppolのメンバーになること
- Open Peppolを通じたTest PKI Certificateの取得
- Peppol Authority(認証局、日本の場合はデジタル庁)との契約
- アクセスポイント機能のテスト環境への実装とテストの実施
- Production PKI Certificateの取得
- 本番環境への実装
※ 具体的かつ網羅的な手続は、デジタル庁及びOpen Peppolのウェブサイトをご確認ください。
また、Peppolの認定サービスプロバイダーとして、Open Peppolに手数料を毎年支払わなければなりません。
4.PEPPOL接続の実装・開発
認証を得るためにはテスト環境へのPeppol接続の実装が必要ですが、その後自社が提供するソフトウェア・アプリケーションにも、機能として実装が必要になります。
PEPPOLでの請求データの送受信のために必要となる主要な構成要素には、例えば以下のようなものがあります。
- AS4というメッセージングプロトコルを用いた送受信のための接続
- 送信側において必須となる、ドキュメント(エンドユーザーから受領する請求書発行者から受領する請求データ等)のValidation機能
- 受信側におけるSMP機能
多くの場合、テスト環境と本番環境への実装は重複した作業となり、その工数は少なくはないかもしれません。
また、アクセスポイントのみならずSMPとしての認証を得ようとする場合には、SMPについてもテストが必要となります。このSMPは概念的にも機能的にもアクセスポイントとは別物であり、追加的な対応が必要となります。
5.メンテナンスやアップデート対応
PEPPOLのネットワークやその通信プロトコルの仕様、文書フォーマット、セキュリティ対応など、多くの事項についてアップデートがなされます。
マイナーなアップデートは年に数回なされる場合もあり、数年に一回ほどのペースで大きなアップデートもあります。
多くの場合、これらはアップデート時に速やかな対応が求められます。
6.運用とサポート
アクセスポイントの運用に際しては、エンドユーザーに対するサポート体制も求められます。
PEPPOL ID登録時のエラーや請求データの送受信の際のエラー対応の他、場合によっては相手方のアクセスポイントとのコミュニケーションも必要になることもあり得ます。
最後にStorecoveAPIのご紹介
アクセスポイントの開発・実装及び運用に関する実務的なポイントを挙げてみました。もっと詳しく知りたい、詳細な質問をしてみたいという方は、ぜひStorecoveまでコンタクトください。
最後にStorecoveのソリューションのご紹介です。
Storecoveは、上記に挙げたようなアクセスポイントの機能開発や運用における煩わしさ・手間を、使い勝手の良いAPIで解決するソリューションで、主に以下のような特徴があります。
- APIでソフトウェアと繋ぐだけでPEPPOL接続に必要な事項のほとんどに対応
- AS4でのPEPPOL接続
- UBL等の所定のフォーマットへの変換
- 諸外国のフォーマットへの変換
- SMPの機能
- 送信の際のLookup/Discovery機能
- 送信の際のValidation機能
- Open APIに沿ったRESTful APIであり、容易なクライアントライブラリの生成
- PKI対応
- Webhookによる送受信ステータスの取得
- 受信側がPEPPOL登録していない場合のメール送信機能
Storecoveをご利用いただくことで、素早いPEPPOL対応が可能となり、エンドユーザーの事業者にとって大きなメリットをもたらすことに繋がります。
(アクセスポイント対応する意義については、こちらのブログも合わせてご覧ください。)
Storecoveのソリューションについてより詳しく知りたい方は、下記からお問い合わせくださいませ。
メールでのお問い合わせはこちらまで(日本語可)。
japan@storecove.com
Comments