2023年3月23日に「スマート証憑管理」システムの更新が行われた。「電帳法種別」で「電子取引」「対象外」に加え「スキャナ保存」が加わった。スマート取引取込のスキャナ保存との違いは、タイムスタンプ付与機能が無い事、「png」ファイルも対象になっている事、仕訳連携が任意である事、画像以外のページや複数ページPDFを扱える事、などである。
「弥生の青色申告23で電子帳簿保存法のスキャナ保存」でスマート取引取込のスキャナ保存に不具合がある事が分かっているが、スマート証憑管理がどうか確認してみた。
![](https://blogimg.goo.ne.jp/user_image/20/60/bcfca462b683d402477b0dffabcd708b.png)
「スマート証憑管理」へは、「電子取引」証憑と仕訳連携登録、「口座連携」で仕訳された取引の証憑をスキャナでファイル化し仕訳連携無しで登録後、青色申告から「口座連携」された取引の証憑番号を転記している。
確認方法は、スマート証憑管理の電帳法種別を「対象外」としていた登録を「スキャナ保存」に変更する。
変更すると「スキャナ保存」に適合したデータかチェックがされる。
適合している事を確認する。
(1)アップロードしたPDF/JPEG/PNGファイル
アップロードしたファイルをダウンロードする事が出来る。
ダウンロードするとJPEG/PNGファイルは、PDFファイルに変換されてしまう。
JPEGファイルは、PDFファイル内にExifデータと共に保存されるがPNGファイルは、PDFファイル内でバイナリーイメージで保存されるため補助チャンクなどの一部データが保存されない。
ファイル名は、アップロード時のファイル名でダウンロードされる。
しばらくアップロードしたファイルを保管しておいた方が良さそうである。
(2)スキャナ保存
Canon のTS9030で国税庁の「スキャナ保存」に適合した条件でスキャンした証憑(レシート)ファイル
![](https://blogimg.goo.ne.jp/user_image/73/53/dc78efe4be730ee4b43d2b767a2860e3.png)
スマート証憑管理に「電帳法種別」を「対象外」として登録してあった。
「編集」で「スキャナ保存」に変更して「保存」した結果
![](https://blogimg.goo.ne.jp/user_image/1d/16/2e373bb01a88dcfc23c5bccf390c1dd6.png)
「スキャナ保存」の条件を満たしていない証憑ファイルです。」と警告される。。。
弥生の「あんしん保守サポート」に問い合わせ
(サポート)アップロード時に判定が行われるので「証憑ファイルの差し替え」を行ってください
(私)ダウンロードして、そのファイルを差し替えでも大丈夫ですか?
(サポート)はい
実行してみたが「スキャナ保存」の条件を満たしていない証憑ファイルです。」と警告される
該当データのURLを提供し調査を依頼する
ダウンロードしたJPEGファイルのEXIF情報を確認してみる事にした。
JPEGファイルで無いと警告されるので確認したところ「PDF」ファイルでダウンロードされている。
「PDFExplorer」で確認すると
![](https://blogimg.goo.ne.jp/user_image/5b/ab/207585b307a86b3175d4e38de6715b0f.png)
PDF内部のResourcesにオリジナルのJPEGファイルが保存されている。
①②は、JFIF定義の分解能。④⑤は、Exif定義の分解能。⑥は、分解能単位。③は、orientation。
弥生が作成したPDFは、MediaBox 492point x 792pointのエリアにResourcesのJPEGをContentsとして「492 0 0 792 0 0 cm」で表示。
656pixel x 1056pixelのJPEGデータをこの条件で表示すると
( 656 / 493 ) x 72 = 96dpi
( 1056 / 792 ) x 72 = 96dpi
となる。これでは、「スキャナ保存」条件に不適合。
JPEGは、300dpiの分解能で作成されているのでMediaBox 157point x 253pointにContentsとして「157 0 0 253 0 0 cm」で表示する事が必要。
何回かのやり取りで弥生も状況を把握したようだ。修正時期については明言出来ないと。。。
(3)PDFファイルのスキャナ保存
青色申告23の「スマート取引取込」「スキャナ保存」(弥生の青色申告23で電子帳簿保存法のスキャナ保存)時にA4サイズの白紙にA4サイズ以下のJPEGデータが貼り付いたPDFの分解能計算が間違えていたので確認した。
![](https://blogimg.goo.ne.jp/user_image/56/c3/fd2e833a8918121124b5c5ca18e7ac6d.png)
「「スキャナ保存」の条件を満たしていない証憑ファイルです。」となる。
スマート取引取込と同様にPDF内の分解能計算を間違えている。
PDFExplorerで確認すると
MediaBox 595.2756 x 841.8898ポイント
Contents 157.44 0 0 253.44 218.9178 294.2249 cm
A4白紙内の中心部に157.44 x 253.44ポイントで656pixel x 1056pixelのJPEG画像を表示するPDFとなっている。
スマート取引取込のスキャナ保存でもJPEGデータがMediaBoxサイズに表示しているとして計算していたので確認すると
( 656 / 595.2756 ) x 72 = 79.3 dpi
( 1056 / 841.8898 ) x 72 = 90.31 dpi
実際の分解能計算は
( 656 / 157.44 ) x 72 = 300 dpi
( 1056 / 253.44 ) x 72 = 300 dpi
となるはず。
(4)JPEGファイルのOrientationとスキャナ保存
スマート取引取込のスキャナ保存でJPEGのOrientation情報を正しく反映出来ない状態だった。スマート証憑管理ではどうなのか確認してみた。
(A)Orientaion=1の証憑
![](https://blogimg.goo.ne.jp/user_image/02/87/858617b45fa18778e51e1c0eaae2d898.png)
1158 X 2190pixel/300dpi/8bit Colorの証憑だが「「スキャナ保存」の条件を満たしていない証憑ファイルです。」となる。
(B)Orientaion=6の証憑
![](https://blogimg.goo.ne.jp/user_image/70/4e/46c3f5cab02dc56caed8e9b8110e6de2.png)
90°時計方向回転させた表示が適切なのだが。。。「スキャナ保存」条件は適合。
両ファイルをダウンロードし 弥生が作成したPDF内容を確認してみた(プログラム内部のデータ取り扱いが推察出来るかもしれない)
(A)Orientaion=1
1158 x 2190pixel/300dpi/orientaion=1
MediaBox 868 x 1642 ポイント
Contents 868 0 0 1642 0 0 cm
( 1158 / 868 ) x 72 = 96dpi
( 2190 / 1642 ) x 72 = 96dpi
JPEGファイルの分解能を取得できなかったのか?
取得できない場合は、JPEGの初期値72dpiとしないのか?
ディスプレー分解能とされている96dpiを設定しているのか?
(B)Orientaion=6
1158 x 2190pixel/300dpi/Orientaion=6
MediaBox 277 x 525 ポイント
Contents 277 0 0 525 0 0 cm
( 1158 / 277 ) x 72 = 300dpi
( 2190 / 525 ) x 72 = 300dpi
JPEGファイルの分解能を解釈しMediaBox値を設定している。描画命令も正しそう。
JPEGのOrientaion=6を反映させるためPDFに「/Rotate 90」が必要。
内部的に回転を忘れている?
(5)PNGファイルのスキャナ保存
PNGファイルには、Orientation情報が無い。JPEGからPNGに変更すると画像そのものをOrientaionに従い変換後にPNGファイルが生成される。
古い画像処理プログラムでは、補助チャンクが扱われずExif情報が失われる(JTRIM 2007年最終更新 を常用している)。最近のプログラムは、eXIfチャンクが追加され、分解能などが正しく適応される。JPEG ExifのOrientationは、画像回転処理後Orientaion=1でPNGのeXIfチャンクに記載されるようだ。
「IMG_20230124_0011y-png-test.png」 JPEG EXIF Orientaion=6 → PNG eXIf Orientaion=1
「IMG_20230124_0011y-png-test2.png」 JPEG EXIF Orientaion=1 → PNG eXIf Orientaion=1
「test2.png」 JPEG EXIF Orientaion=6 → PNG eXIf 無し
「test2-2.png」 JPEG EXIF Orientaion=1 → PNG eXIf 無し
![](https://blogimg.goo.ne.jp/user_image/3e/14/eeb0c2b82a794fa962f140ff499c75c9.png)
PNGのeXIfチャンクが無いと分解能が得られないので「スキャナ保存」条件不適合となる。PNGのeXIfチャンクがあると分解能が正しく取得されている。
IMG_20230124_0011y-png-test2.png
![](https://blogimg.goo.ne.jp/user_image/36/ed/c0acc2a6d2c2c97d36bda1628e685c68.png)
ダウンロードしたPDF情報は
Image: 1158 x 2190 pixel / 8bit Color
MediaBox: 277 x 525 ポイント
Contents: 277 0 0 525 0 0 cm
分解能:300 x 300dpi
IMG_20230124_0011y-png-test.png
![](https://blogimg.goo.ne.jp/user_image/55/60/ea769a2558f70a4301fae5b35b2da9f5.png)
ダウンロードしたPDF情報は
Image: 2190 x 1158pixel / 8bit Color
MediaBox: 525 x 277 ポイント
Contents: 525 0 0 277 0 0 cm
分解能:300 x 300dpi
test2-2.png
![](https://blogimg.goo.ne.jp/user_image/11/9e/cb65cb765d07ad908f5101c4a98949a9.png)
ダウンロードしたPDF情報は
Image: 1158 x 2190pixel / 8bit Color
MediaBox: 868 x 1642 ポイント
Contents: 868 0 0 1642 0 0 cm
分解能:96 x 96dpi
PNGの基本情報には、分解能の設定が無い。
JPEGのEXIFでは、分解能の初期値が72dpi。
PNGのeXIFチャンク未定義であるが、72dpiが適切ではないかと思う。
「弥生 レシート」アプリからアップロードされたJPEG画像は分解能が未定義で72dpiと扱う事になっている。
test2.png
![](https://blogimg.goo.ne.jp/user_image/13/57/4859bffcf1fe2c04412b72bf2ff31ab7.png)
ダウンロードしたPDF情報は
Image: 2190 x 1158pixel / 8bit Color
MediaBox: 1642 x 868 ポイント
Contents: 1642 0 0 868 0 0 cm
分解能:96 x 96dpi
(6)総括
アップロードしたファイル種別でダウンロード出来ない
(勝手にPDF変換する。PDF変換が適切でない。)
PDFファイルの「スキャナ保存」条件検査に不具合
JPEGファイルの「スキャナ保存」条件検査と表示に不具合
PNGファイルの「スキャナ保存」条件検査は適切
「弥生の青色申告23で電子帳簿保存法のスキャナ保存」でスマート取引取込のスキャナ保存に不具合がある事が分かっているが、スマート証憑管理がどうか確認してみた。
![](https://blogimg.goo.ne.jp/user_image/20/60/bcfca462b683d402477b0dffabcd708b.png)
「スマート証憑管理」へは、「電子取引」証憑と仕訳連携登録、「口座連携」で仕訳された取引の証憑をスキャナでファイル化し仕訳連携無しで登録後、青色申告から「口座連携」された取引の証憑番号を転記している。
確認方法は、スマート証憑管理の電帳法種別を「対象外」としていた登録を「スキャナ保存」に変更する。
変更すると「スキャナ保存」に適合したデータかチェックがされる。
適合している事を確認する。
(1)アップロードしたPDF/JPEG/PNGファイル
アップロードしたファイルをダウンロードする事が出来る。
ダウンロードするとJPEG/PNGファイルは、PDFファイルに変換されてしまう。
JPEGファイルは、PDFファイル内にExifデータと共に保存されるがPNGファイルは、PDFファイル内でバイナリーイメージで保存されるため補助チャンクなどの一部データが保存されない。
ファイル名は、アップロード時のファイル名でダウンロードされる。
しばらくアップロードしたファイルを保管しておいた方が良さそうである。
(2)スキャナ保存
Canon のTS9030で国税庁の「スキャナ保存」に適合した条件でスキャンした証憑(レシート)ファイル
![](https://blogimg.goo.ne.jp/user_image/73/53/dc78efe4be730ee4b43d2b767a2860e3.png)
スマート証憑管理に「電帳法種別」を「対象外」として登録してあった。
「編集」で「スキャナ保存」に変更して「保存」した結果
![](https://blogimg.goo.ne.jp/user_image/1d/16/2e373bb01a88dcfc23c5bccf390c1dd6.png)
「スキャナ保存」の条件を満たしていない証憑ファイルです。」と警告される。。。
弥生の「あんしん保守サポート」に問い合わせ
(サポート)アップロード時に判定が行われるので「証憑ファイルの差し替え」を行ってください
(私)ダウンロードして、そのファイルを差し替えでも大丈夫ですか?
(サポート)はい
実行してみたが「スキャナ保存」の条件を満たしていない証憑ファイルです。」と警告される
該当データのURLを提供し調査を依頼する
ダウンロードしたJPEGファイルのEXIF情報を確認してみる事にした。
JPEGファイルで無いと警告されるので確認したところ「PDF」ファイルでダウンロードされている。
「PDFExplorer」で確認すると
![](https://blogimg.goo.ne.jp/user_image/5b/ab/207585b307a86b3175d4e38de6715b0f.png)
PDF内部のResourcesにオリジナルのJPEGファイルが保存されている。
①②は、JFIF定義の分解能。④⑤は、Exif定義の分解能。⑥は、分解能単位。③は、orientation。
弥生が作成したPDFは、MediaBox 492point x 792pointのエリアにResourcesのJPEGをContentsとして「492 0 0 792 0 0 cm」で表示。
656pixel x 1056pixelのJPEGデータをこの条件で表示すると
( 656 / 493 ) x 72 = 96dpi
( 1056 / 792 ) x 72 = 96dpi
となる。これでは、「スキャナ保存」条件に不適合。
JPEGは、300dpiの分解能で作成されているのでMediaBox 157point x 253pointにContentsとして「157 0 0 253 0 0 cm」で表示する事が必要。
何回かのやり取りで弥生も状況を把握したようだ。修正時期については明言出来ないと。。。
(3)PDFファイルのスキャナ保存
青色申告23の「スマート取引取込」「スキャナ保存」(弥生の青色申告23で電子帳簿保存法のスキャナ保存)時にA4サイズの白紙にA4サイズ以下のJPEGデータが貼り付いたPDFの分解能計算が間違えていたので確認した。
![](https://blogimg.goo.ne.jp/user_image/56/c3/fd2e833a8918121124b5c5ca18e7ac6d.png)
「「スキャナ保存」の条件を満たしていない証憑ファイルです。」となる。
スマート取引取込と同様にPDF内の分解能計算を間違えている。
PDFExplorerで確認すると
MediaBox 595.2756 x 841.8898ポイント
Contents 157.44 0 0 253.44 218.9178 294.2249 cm
A4白紙内の中心部に157.44 x 253.44ポイントで656pixel x 1056pixelのJPEG画像を表示するPDFとなっている。
スマート取引取込のスキャナ保存でもJPEGデータがMediaBoxサイズに表示しているとして計算していたので確認すると
( 656 / 595.2756 ) x 72 = 79.3 dpi
( 1056 / 841.8898 ) x 72 = 90.31 dpi
実際の分解能計算は
( 656 / 157.44 ) x 72 = 300 dpi
( 1056 / 253.44 ) x 72 = 300 dpi
となるはず。
(4)JPEGファイルのOrientationとスキャナ保存
スマート取引取込のスキャナ保存でJPEGのOrientation情報を正しく反映出来ない状態だった。スマート証憑管理ではどうなのか確認してみた。
(A)Orientaion=1の証憑
![](https://blogimg.goo.ne.jp/user_image/02/87/858617b45fa18778e51e1c0eaae2d898.png)
1158 X 2190pixel/300dpi/8bit Colorの証憑だが「「スキャナ保存」の条件を満たしていない証憑ファイルです。」となる。
(B)Orientaion=6の証憑
![](https://blogimg.goo.ne.jp/user_image/70/4e/46c3f5cab02dc56caed8e9b8110e6de2.png)
90°時計方向回転させた表示が適切なのだが。。。「スキャナ保存」条件は適合。
両ファイルをダウンロードし 弥生が作成したPDF内容を確認してみた(プログラム内部のデータ取り扱いが推察出来るかもしれない)
(A)Orientaion=1
1158 x 2190pixel/300dpi/orientaion=1
MediaBox 868 x 1642 ポイント
Contents 868 0 0 1642 0 0 cm
( 1158 / 868 ) x 72 = 96dpi
( 2190 / 1642 ) x 72 = 96dpi
JPEGファイルの分解能を取得できなかったのか?
取得できない場合は、JPEGの初期値72dpiとしないのか?
ディスプレー分解能とされている96dpiを設定しているのか?
(B)Orientaion=6
1158 x 2190pixel/300dpi/Orientaion=6
MediaBox 277 x 525 ポイント
Contents 277 0 0 525 0 0 cm
( 1158 / 277 ) x 72 = 300dpi
( 2190 / 525 ) x 72 = 300dpi
JPEGファイルの分解能を解釈しMediaBox値を設定している。描画命令も正しそう。
JPEGのOrientaion=6を反映させるためPDFに「/Rotate 90」が必要。
内部的に回転を忘れている?
(5)PNGファイルのスキャナ保存
PNGファイルには、Orientation情報が無い。JPEGからPNGに変更すると画像そのものをOrientaionに従い変換後にPNGファイルが生成される。
古い画像処理プログラムでは、補助チャンクが扱われずExif情報が失われる(JTRIM 2007年最終更新 を常用している)。最近のプログラムは、eXIfチャンクが追加され、分解能などが正しく適応される。JPEG ExifのOrientationは、画像回転処理後Orientaion=1でPNGのeXIfチャンクに記載されるようだ。
「IMG_20230124_0011y-png-test.png」 JPEG EXIF Orientaion=6 → PNG eXIf Orientaion=1
「IMG_20230124_0011y-png-test2.png」 JPEG EXIF Orientaion=1 → PNG eXIf Orientaion=1
「test2.png」 JPEG EXIF Orientaion=6 → PNG eXIf 無し
「test2-2.png」 JPEG EXIF Orientaion=1 → PNG eXIf 無し
![](https://blogimg.goo.ne.jp/user_image/3e/14/eeb0c2b82a794fa962f140ff499c75c9.png)
PNGのeXIfチャンクが無いと分解能が得られないので「スキャナ保存」条件不適合となる。PNGのeXIfチャンクがあると分解能が正しく取得されている。
IMG_20230124_0011y-png-test2.png
![](https://blogimg.goo.ne.jp/user_image/36/ed/c0acc2a6d2c2c97d36bda1628e685c68.png)
ダウンロードしたPDF情報は
Image: 1158 x 2190 pixel / 8bit Color
MediaBox: 277 x 525 ポイント
Contents: 277 0 0 525 0 0 cm
分解能:300 x 300dpi
IMG_20230124_0011y-png-test.png
![](https://blogimg.goo.ne.jp/user_image/55/60/ea769a2558f70a4301fae5b35b2da9f5.png)
ダウンロードしたPDF情報は
Image: 2190 x 1158pixel / 8bit Color
MediaBox: 525 x 277 ポイント
Contents: 525 0 0 277 0 0 cm
分解能:300 x 300dpi
test2-2.png
![](https://blogimg.goo.ne.jp/user_image/11/9e/cb65cb765d07ad908f5101c4a98949a9.png)
ダウンロードしたPDF情報は
Image: 1158 x 2190pixel / 8bit Color
MediaBox: 868 x 1642 ポイント
Contents: 868 0 0 1642 0 0 cm
分解能:96 x 96dpi
PNGの基本情報には、分解能の設定が無い。
JPEGのEXIFでは、分解能の初期値が72dpi。
PNGのeXIFチャンク未定義であるが、72dpiが適切ではないかと思う。
「弥生 レシート」アプリからアップロードされたJPEG画像は分解能が未定義で72dpiと扱う事になっている。
test2.png
![](https://blogimg.goo.ne.jp/user_image/13/57/4859bffcf1fe2c04412b72bf2ff31ab7.png)
ダウンロードしたPDF情報は
Image: 2190 x 1158pixel / 8bit Color
MediaBox: 1642 x 868 ポイント
Contents: 1642 0 0 868 0 0 cm
分解能:96 x 96dpi
(6)総括
アップロードしたファイル種別でダウンロード出来ない
(勝手にPDF変換する。PDF変換が適切でない。)
PDFファイルの「スキャナ保存」条件検査に不具合
JPEGファイルの「スキャナ保存」条件検査と表示に不具合
PNGファイルの「スキャナ保存」条件検査は適切