標準ver.4パブコメ意見と回答（案）2022/8/16

No

パブコメ意見

パブコメ回答（案）1

文書サブタイプコードは、文書タイプコードとの関係が分かるように紐付けて定義するべきご意見に合わせてコード定義を修正します

2

出荷案内メッセージに対する出荷回答メッセージが必要。入荷品に異常があった場合の連絡手段として利用する出荷回答メッセージの追加を検討します。今後、ミニバージョンアップ（4.1・・）で対処します。

3

中小企業共通EDIプロバイダは電帳法に対応できるか

中小企業共通EDI標準ver.4には電帳法に対応する規定はありません。しかし共通EDIプロバイダによる電帳法対応サービス提供はユーザーメリットがあるとのご意見もあるので、電帳法対応仕様を検討します。
本件もミニバージョンアップによる対応を検討します。
ご検討いただきありがとうございます。
仕様について弊社と共通EDIプロバイダ企業様と打ち合わせをしました。
設備業界のEDI標準化を進めていくための仕様確認をしましたが、共通EDIの物品購入仕様に対しては特に変更点が必要と感じていません。
4

共通EDIプロバイダ企業様のシステム改修と弊社業務アプリの改修で可能と考えています。

請負契約プロセスは中小企業共通EDI標準ver.4にはまだ組み込まれていません。
今後、情報のご提供をいただき、仕様の検討を行いたいと考えます。
検討結果がまとまりましたら、次のバージョンアップでの対応を検討いたします。

請負工事の受発注出来高払い業務についても、今後の課題等も明確になったと感じています。その課題についても対応可能と考えています。
来月、電気設備工事会社に共通EDIシステムを納品させて頂き、利用する予定です、そこで出てきた内容は、情報共有させて頂きます。
当方目下、EIPAに関わっていることもあり、税理士関与の中小零細事業者にもデジタル･インボイスの受け渡しに取り組んでもらいたいと考えています。

JP-PINTと共通EDIインボイスは仕様が公開されたばかりなので、EDIプロバイダ各社は現在検討中の状況と思われます。
既存のEDI（大手業界EDIや中小企業共通EDI）とJP-PINTは異なる仕様のEDIです。

例えば、添付のようなクラウド上の請求書画面に品名・数量・単価を入力して変換ボタンを押すだけでJP PINT仕様のXMLファイルが生成さ 既存のEDIプロバイダはJP-PINTへ対応するためには追加の投資が必要です。
5

れるならば、インボイスの作成(C1)は何とかクリア出来そうですがEDIプロバイダは経営判断でJP-PINTに対応する追加投資の要否を決定しますので、今後の動きを待ちたいと思います。

中小零細事業者は、販売購買管理システムを日常的に使用していることは少数派であり、また利用していても電子データで客先に送信していることはまれです。
JP PINTの利用につきデジタル庁が認可するアクセスポイント(C2,C3)の役目を本件共通EDIシステムのプロバイダさんが安価に引き受けて下さるとデジタル・インボイスの実用が更にもう一歩先に進めそうに思いますがどんなものでしょうか。
既にネットワーク上でのデータの交換はXMLではなくJSONが中心になってきている。
開発の効率の観点から、標準仕様はXMLではなく、JSON形式にしていただきたい。大企
業では、既存システムや他企業グループ企業のシステムとの互換性の観点などからXMLが使われているかもしれない。しかしながら、中小企業標準が対象としているのはシステムがそもそも導入されていない企業であるのでXMLを使う必要がない。

6

企業間データ連携の国際標準は現時点ではXMLが主流であり、これらが連携してJSONに取り組めるかが今後の課題です。
（１）中小企業共通EDI仕様は国連CEFACT標準仕様に則ており、国連CEFACT標準仕様がXMLベースであることから当仕様もXMLベースとなっています。
（２）国連CEFACTでは、JSONを使用したRESTfulAPI標準も検討中ですが、単にシンタックスをXMLからJSONに変更するだけではなく、辞書（ライブラリ）の構造と扱い、他標準との連携など課題が多く、移行には時間がかかりそうです。

JSONの主な利点：
１．古くからある大企業以外では基本的にすでにJSON形式が主流である。私の理解ではトヨタなどもIOTデータの通信など含めてJSONを使っているはずである（特に切り替えにコストベネフィットが合わないような場合を除いて）。
２．WEBアプリケーションフレームワーク等の開発ソフトでのサポートが充実している（SwaggerでのAPI自動出力等）。
３．最近の業務用ソフトウェアはブラウザベースであり、データをやりとりするためにはJavascriptを使うのでJSONの方が使いやすい。
１．『⑧＜付属書＞ PDFフォーマット仕様書』についての提案です。
『１．３．２ XMPメタデータの登録方法について』について、本件は＜付属書＞PDFフォーマット仕様書への提言です。
回答案の作成をお願いします。

ここではXMPメタデータについて一例が表示されていますが、8/23の第2回表通EDI標準部会へご参加いただけない場合は、事前に事務局へ仕様をいただければ、代行して説明いたします。

実際のメタデータは添付する文書やXMLの準拠する規格に応じて記述を変更する必要があるためです。
具体的な改善案として、・XMPメタデータの用途とメタデータ設定の必要性についての説明・書き換えを意識した、表を用いた分かりやすい各項目の説明の追加を提案します。
補足資料：
今回のPDFフォーマットが参考にされた仏独のPDF規格[ZUGFeRD]を参考にして下さい。
XMPメタデータの用途とメタデータ設定の必要性についての説明の例→XMP拡張スキーマが必要である理由に関する記述が添付zip内の[1. FACTUR-X 1.0.06 EN.pdf]23ページ目の「6.3 PDF/A extension schema」の項にあります。
7

＜水谷様＞

会計ソフトのデベロッパー様などPDFの専門知識が無い人向けに解説を充実させるべきと思われます。

「表」の例→添付zip内[ZUGFeRD_Table001.png], [OrderX_Pic001.png],[ZUGFeRD_Table002.png], [OrderX_Pic002.png]がZUGFeRDで表されている表です。

ご検討をよろしくお願いします、

審議

２．PDFフォーマットにおけるXMP拡張スキーマの役割について、１点ご確認があります。
8/9（金）の説明会では担当者様がPDFに書き込まれるメタデータについて、「XMLスキーマファイルは添付しないが、XMP形式の情報でPDF内に定義している」という内容でXMP拡張スキーマが添付のXMLファイルと関係したものとご説明されたように聞こえました。
弊職はXMP拡張スキーマについて、「PDF内に新たに埋め込んだメタデータに関するスキーマであり、添付されたXMLファイル本体のスキーマとは無関係である」のではないかとの認識です。

[ZUGFeRD_Pic003.png]はZUGFeRDの仕様書23ページ目の抜粋です。
こちらでXMP拡張スキーマがメタデータに関するスキーマであることが説明されています。
これが上記の根拠となります。
ご確認をお願いします。

検討のテーマ）
発注企業が１００％EDIに切り替えることをどうすれば促進できるかご提案ありがとうございます。
中小企業ユーザーは多様であり、適切な層別化をして対応を検討する必要があると考えています。

EDIとFAXの併存利用の脱却を目指す→受注側のＦＡＸに代わるソリューションを提供するEDIデータの電帳法「電子取引」保存義務確保も併 EDI導入は発注企業の主導で検討が始まるケースが一般的ですが、受注企業の社内IT環境が大きく異なり、EDI導入を阻害する大きな要因にせてクリアする。（電子インボイスは、電帳法「電子取引」）

なっています、受注企業のIT環境を次のように層別化して対応策を検討しています。

現在の問題点）【第1層】社内管理を紙伝票で実施：個人事業者、小規模企業

受注側企業で個人事業主や小規模企業はＦＡＸが主流でＥＤＩデータを扱うことができない。

【第2層】受注管理をEXCELで実施：小規模企業、中規模中小企業

パソコンを使える個人事業主や小規模企業は多いとは言えない。

【第3層】受注管理・購買管理を業務アプリで実施：大規模中小企業

スマホは日常利用しているだろう。
【第1層企業】はご提言のスマホ利用企業であり、PCはないと推測
検討と仮説）
発注側が、ＥＤＩデータよりスマホでも目視確認できるＰＤＦで文書／請書／請求書を作り、受注側企業に提供する。【機能Ａ】
ＰＤＦ内にはＥＤＩデータをＸＭＬ化したデータが添付されているその際の提供方法はクラウドサービス経由で送る。【機能Ｂ】
クラウドサービスは当該データを税法上の保存期間、保存する。【機能Ｃ】→スマホで共通EDI利用ができるサービスがまだ少ない【第2層企業】はPCを導入し、受注管理はEXCEL。
会計アプリ導入企業はあると認識→EXCELと共通EDIの安価な自動連携ITサービスがない【第3層企業】は受発注・会計アプリを導入済。
→共通EDI認証アプリ・サービスを利用できる

当該ファイル名は「電子取引」の検索要件を確保した名称にする。【機能Ｄ】

8

請書／請求書は、何だかのアプリで、受注者情報や受注者確認情報を付加して、クラウドサービス経由で送る。【機能Ｅ】【第1層企業】【第2層企業】が安価に利用できる共通EDI連携ITツール・サービスがまだ十分提供されていないので、今後これらの充実が課

発注側に受注側から請書／請求書が届いた際には、ＰＤＦ内にはＥＤＩデータをＸＭ題と認識しています。

Ｌ化したデータが添付されているから自動処理が容易にできる。【機能Ｆ】

ご提言の【機能F】を実現するXML添付PDFも有力な選択肢です。

考察）
仮説通りに行くとすれば・受注側の自動処理がＰＤＦにて実現し【機能Ｅ・Ｆ】
・受注側もスマホやＰＣでＰＤＦを受信でき、確認して請書／請求書を返信できる【機能Ｂ・Ｅ】
・受注側の「電子取引」要件確保は、クラウド保存でもＰＣがあればローカル保存でも要件確保は可能【機能Ｃ・Ｄ】
今後の進め方（案）１）標準仕様の作成【機能ＡからＦ】
２）クラウドサービスベンダーへのソリューションの提供依頼
推測）
ラクス社ヤインフォマート社やサンサン社等は、すでに請求書などのクラウドサービスを多数サービス提供している
彼らのようなサービスプロバイダーに中小企業標準ＥＤＩのＰＤＦ仕様の対応を促しＦＡＸに置き換わる、ビジネスモデルとして、普及促進の協力が得られやすいだろう。
以上

ご参考になれば幸甚です。