『AWSなどでMicrosoft製品(SPLAライセンス)が使えなくなる!?』ってホント??

2023年8月18日付けのIIJのエンタープライズIT Columns(JJI-ITCと略記)に、『AWSなどでMicrosoft製品(SPLAライセンス)が使えなくなる!? 』という記事が掲載されています。

だいぶ前の記事なのですが、「2025年9月30日以降、AWSやGoogle Cloudなどのパブリッククラウドを利用しているサービス提供事業者は、Microsoft製品(SPLAライセンス)の持ち込みができなくなる」とあるので、本当だとすると、結構インパクトが大きそうです。

現時点で1年半ほど先の話ですが、弊社でも関係するクラウドサービスを提供しているため調査を始めています。

マイクソロソフトのWebページで関連する情報を探すと、次の記事が見つかりました。
クラウドへのワークロードとライセンスの導入を容易にする、新たなライセンス特典(2022年9月12日)

この中の「アウトソーシングに関するSPLAプログラムのアップデート」と見出しのついた段落がJJI-ITCの記事で言っている内容に該当するようです。

この記事は次の元記事(英語)の翻訳とされています。
New licensing benefits make bringing workloads and licenses to partners’ clouds easier (2022年8月29日:元の記事を読むにはブラウザで言語を英語にする必要があります。)

この記事を読むと、マイクロソフトのSPLA(Services Provider Licensing Agreements)は、データセンターを運営する事業者とユーザーの間の契約を想定していた。しかし、マネージド・サービス・プロバイダーが、SPLA契約でマイクロソフト製品のライセンスを購入して、他社のデータセンターでサービスを行うようになった。これを元の意図に沿って正したいということのようです。

そこで、リストに該当するプロバイダーの上にSPLAを持ち込むことができないようにするという措置を講じるということです。

リストに該当するプロバイダーとは次のとおりです。
Alibaba, AWS (Amazon Web Service), Google, Microsoft およびサービスの一部としてこの4つのプロバイダを使ってアウトソースサービスを提供しているプロバイダ

英文の記事中で掲げられている対応策は
現在マイクロソフト製品をSPLAで利用しているパートナーは、2025年9月までに上記のリストに該当するプロバイダーから移行するか、上記のリストに該当するプロバイダーからライセンスをSPLAとは別に直接取得しなければならない
とされています。

この記事を読んで、よく行くTOHOの映画館で映画上映前にいつも出る「当館以外で購入された飲食物の持ち込みはご遠慮ください」という無粋な告知を思い浮かべてしまいました。

館内で販売されているやや高めの飲食物を買って楽しむか、上映中に飲食すること自体を諦めるか、どっちかの選択が必要になるということですかね。

もしかすると、弊社の『Office Server Document Converter』の出番がありますか?

【ご注意】本記事の詳細はさらに調査中です。(当社の主体の記事ではなく、解釈なので)誤っている可能性もありますのでご注意ください。


米国国債の利回り変化と国債価格の値動きを調べてみた

一般には、金利が上がると債券の価格は下がると言われている。では、金利のうごきと債券価格の動きは定量的にどのような関係になっているのだろうか。

債券運用の本を読んでみたところ、次のような説明があった。ここでは単純化するために利息(クーポン)の付かない割引債(ゼロクーポン債)の場合について示す。

割引債の価格(P)と複利最終利回り(r)には次の関係がなりたつ。

P=100/((1+r)^n) (n:残存年数)

これは価格Pの割引債を満期まで(n年)保有すると100で償還される。そのときの複利計算の利回りがrとなるということを表す式なので、割引債がデフォルトしない限り必ず成り立つ一種の定義式である。

上式の両辺をrで微分すると次のようになる。

dP/dr=-100n/((1+r)^(n+1))=-nP/(1+r)

これは次のように置き換えられる。

dP/P=-(n/(1+r))*dr

この式は残存n年の割引債の価格変化率(dP/P)は複利最終利回りの変化幅(dr)に対して、n/(1+r) 倍した値になるということを表している。

現在の米国30年国債の利回りは概ね4%強になっている。なので残存期間30年の米国割引国債を買って保有したとき、利回りが1%下落すると、価格は28%ほど上昇するということになる。

式の導出過程を振り返れば分かるとおり、上の関係は理論的なものだ。

実際には国債の価格は市場の需給関係で決まっていると言われている。自然界ではニュートンの万有引力の法則が成り立つとしても、魑魅魍魎が支配する証券業界で、こんな理論的関係が、あたかも万有引力の法則のように働くものなのだろうか。

俄かには信じがたいので、早速、楽天証券で米国30年ストリップ国債(残存期間25年3カ月)を少額だけ購入して実際の値動きを調べてみた。

1.楽天証券では評価額は毎日当日夕方の17時頃にわかる。
2.また別にQuick情報で米国30年国債の利回りを調べる。米国30年国債の利回り(終値)は翌日の朝にわかる。

1月16日から2月8日までのデータは次のとおりであった。

この結果を見ると、前日に国債利回りが上がっているときは、ストリップ国債の楽天の評価価格が下がり、逆に利回りが下がっているときは、ストリップ国債の評価価格が上がっている。

国債利回りの変化(drに相当)をx軸に、ストリップ国債の価格の変化率(dP/Pに相当。Pは前日の価格、dPは前日からの価格変化)をy軸にとって分布図にすると次のようになる。

Excelで回帰分析して、次の関係式を得た。xとyは1日ずれている。

y=-0.241x+0.001

これによると、利回りが1%下がると、価格は概ね24%アップする、という関係になる。

概ね、理論どおりの関係が成り立っているようだ。

実際には、前日の米国30年国債の利回り終値を見て、楽天証券が評価価格を計算しているのかもしれない。もし、そうなら観測値がほぼ直線上に並ぶはずなのだが。

「債券の価格と利回りはコインの裏表の関係にある。しかし、主従関係からみれば価格が主」という説明もあるが、債券の価格決定過程はブラックボックスなので、真実はわからない。

参考資料:『債券運用と投資戦略』(金融財政事情研究会)


DeepLによるHTML翻訳でタグが正しく取り扱われるか?

日本語の文章を英語に翻訳するためにツールとして、機械翻訳がかなりいいレベルまで来ているのは周知のとおりです。では、HTMLでタグ付けされたWebページの翻訳にも機械翻訳を使えるでしょうか?

HTMLファイル機械翻訳の課題

日本語HTMLファイルは大きくわけるとテキストコンテンツと画像やマークアップ(タグなど)から構成されます。

タグにはいろいろな種類があります[注1]。メタ情報を表すタグ、見出し、段落、箇条書き、表などのブロックの区別を表すタグ、強調、アンダーライン、上付き・下付きなどテキストの意味合いを表すインラインタグ、リンクや画像を埋め込むタグ、などです。

WebページのレイアウトはCSSで指定します。このため多くのタグに、CSSによるレイアウトを制御するための属性が付加されます。また、HTMLファイル内にはブラウザで表示する際のダイナミックな動作を表現するためにJavaScriptが埋め込まれます。このためHTMLファイルは、コンテントのテキストと比べてかなり複雑になり、通常はマークアップ作業に多大な時間がかかります。

機械翻訳のシステムでHTMLファイルを日本語から英語に翻訳するとき、(1)テキストコンテンツの翻訳の品質に関わる課題と、(2)タグの扱いが適切かどうかという課題があります。

タグの扱いについての要件

ここでは、主にタグの取り扱いを考えてみます。まず、タグの扱いは基本的には次の条件を満たす必要があります。

1.タグ自体は翻訳せず、タグのツリー構造は保持されなければならない。つまりタグの順序が変更されないこと。開始タグと終了タグの対が保持されること。タグの親子関係(入れ子関係)が崩れないことなどが満たされること。
2.開始タグには属性と属性値が付随することがあります。属性は翻訳せず、属性値は多くの場合、翻訳しない方が望ましいが、翻訳してほしいこともある。

日本語のHTMLファイルを機械翻訳した結果、タグのツリー構造が壊れてしまったり、マークアップが不適切になってしまうと、機械翻訳の出力として得られたHTMLファイルのタグ付けを修正する作業が必要になります。もし、タグの構造が完全に破壊されてしまうと、プレーンテキストにゼロからタグ付け作業をする方が手間が少ないということになります。

特に、インラインタグは翻訳テキスト中に混在するのでタグのツリー構造を維持するのが難しい場合がありそうです。そこで機械翻訳システムがテキストコンテントとタグを分離してうまく扱えるかどうかは詳しく調べてみる必要があります。

機械翻訳のHTMLファイル形式サポート

機械翻訳システムによってはタグでマークアップしたテキストを翻訳対象にできないことがあります。ここで使用するDeepLは、Free版ではHTML形式ファイルを扱えません。一方、Pro版とAPI版がHTMLファイル形式を翻訳対象としてサポートしています。

Which file formats can I translate?

DeepLによる日本語HTMLファイルの英語への翻訳例

そこで、今回、DeepLでHTMLを翻訳したときタグが正しく扱われるかを調べてみました。翻訳の対象としたのは、Formatter V7.4(開発中)の日本語HTMLマニュアル(XSL/CSS拡張)です。

Formatterのマニュアルは、日本語と英語版のWebヘルプとして作成されています。V7.3(現行バージョン)についてはこちらからご覧いただけます。現在、翻訳は社内の専門スタッフが行っており、機械翻訳は使っていません。
Antenna House Formatter V7 日本語版マニュアル
Antenna House Formatter V7 日本語版マニュアル・XSL/CSS拡張
Antenna House Formatter V7 英語版マニュアル
Antenna House Formatter V7 英語版マニュアル・XSL/CSS Extensions

DeepL翻訳結果・第一印象

日本語のHTMLをDeepLで英語に翻訳翻訳した結果はいちおうHTMLなのでブラウザで表示できます。最初に、翻訳元の日本語HTMLファイルと、DeepLで翻訳した英語HTMLファイルのブラウザ表示を比較してみます。

1)目次部分

翻訳元日本語目次(左)、翻訳結果の目次(右)

2)見出し、本文や表

見出し、本文(太字)、リンク、表

3)表と箇条書き

表と箇条書き

こうしてみますと、ブラウザで表示して比較できるレベルでタグが付いているようです。ただし、ブラウザはHTMLファイルのタグが正しくなくても表示できるように作られているので、ブラウザで表示できるからと言って、タグが完全に適切に付けられているとは言い切れません。

また、翻訳された内容を詳しく見ると、細かい点に問題が見つかります。

では、HTMLタグがどの程度まで適切に設定されているでしょうか? これを確認するにはHTMLファイルのタグを詳細にチェックする作業が必要になります。そこで、次回は、DeepLのHTML翻訳結果のタグ付けについて詳細に検討してみることにします。

[注1]
HTMLのタグの種類やタグ付けの規則については次の標準仕様で規定されています。
HTML Living Standard


骨抜き加速? 電子取引データ保存制度

令和5年11月17日 国税庁のWebサイトの制度のパンフレット等

新しいちらし「システム導入が難しくても大丈夫!!令和6年1月からの電子取引データの保存方法」(PDF)が掲載されました。

2024年1月から施行される電子取引データ保存制度への対応策が、国税庁のパンフレットにしては優しく表現されています。

制度が易しくなったのかな? と思いつつ読んでみると、このパンフレットに記載されている内容は、本ブログで紹介したことと同じです。但し、国税庁のちらしの方が分かりやすい印象はあります。

電子帳簿保存法の電子取引データ保存は、なにしろ、準拠する要件項目の組み合わせが多いので、条件の組み合わせを間違えないようにしつつ、説明を分かりやすくするのが難しい制度です。

これまでの説明はちょっと難しすぎたかな~? ちなみに、前回・前々回のブログへのリンクは次のようになります。

前回 2024年1月からの電子取引データ保存方策検討:検索要件対応で選択肢を細分すると・・・
前々回 電子取引データ保存要件の中で、複雑なパズル並みに理解し難いのが検索要件だ

関連記事


Wordでマニュアルを執筆してWebマニュアルを作る

お知らせ
2024年1月30日 事例紹介ウェビナーを開催いたします。
どうぞ、ご参加ください。
お申し込みは次からどうぞ。
ワードからすばやくウェブ オンワード

Microsoft Wordを製品やサービスのマニュアルを執筆するのに使用している人はかなり多いと思われます。

そうして作成した原稿はPDFとして配布されることが多いでしょう。なぜならば、Wordはもともとプリンタで紙に印刷して配布するための文書を執筆するツールだからです。

ところが、現在は、あらゆる情報をWebで閲覧・聴取する時代です。PDFは紙のページをそのまま電子化したもので、ディスプレイで閲覧するにはあまり便利ではありません。これは現実に多くの方が実感されていることでしょう。

そうすると、マニュアルをWordで制作した場合、どのようにしてWebページにするか、ということが大きな課題になるはずです。

この解決策はいろいろあります。一番、革命的解決策は、Wordでマニュアルの原稿を執筆するのをやめる、というものです。具体的には、マニュアルの内容をXMLとして用意するといったものです。

その対極としては、Wordで書いたマニュアルの原稿をWebページに変換する、という方法もあります。

ここにご紹介する『HTML on Word』は、後者の方法を実現するものです。今回、1年ぶりにV2にバージョンアップしました。今回のバージョンアップは、Wordで執筆してマニュアルからより実用的なWebページが作成できる様になりました。

主な機能強化点
1.HTMLを分割出力
 Word文書の章や節など、指定したアウトラインレベル単位で分割してHTMLを出力できるようになりました。

2.ページ移動リンクの出力
HTMLを分割して出力する場合は、オプションの指定で「前へ/次へ」といった、ページを順に移動するリンクを出力することができるようになりました。

3.目次の変換を強化
Wordの目次機能で作成した目次箇所を、HTMLの<nav>タグで出力するようにしました。また、目次箇所のタグやclassなどの要素を追加しました。

4.目次を別ファイルで出力
HTMLの分割時は目次箇所を別のファイル(html)として出力することができるようになりました。

30日間試用できるV2.0の評価版も提供しておりますので、上記新機能を実際にお試しいただけます。下記よりお申し込みの上、是非おご利用ください。

製品ページ
https://www.antenna.co.jp/xhw/

製品ページ・機能詳細
https://www.antenna.co.jp/xhw/function.html

評価版ダウンロード申込
https://www.antenna.co.jp/xhw/trial.html

英語版も
『HTML on Word』は英語版も用意しております。
英語版についての情報は次からご覧ください。

https://www.antennahouse.com/html-on-word-2.0


10月24日16時より電子取引データ保存についてのウェビナーを開催します。

電子取引データのデジタル保存完全義務化が数か月後に迫っています。皆様準備はお済でしょうか?
まだ、準備完了していない方は、お急ぎください。

その節は丁度良い機会ですので、次のウェビナーを視聴されてみてはいかがでしょうか。

来週、10月24日16時よりZoomウェビナー「電子取引データを効率的にデジタル保存」(視聴無償)を開催します。

本ウェビナーは、前半と後半に分かれています。

前半は電子取引データのデジタル保存についてです。

既に本ブログで何回も繰り返しているのでご承知のことでしょうが、2024年から電子取引データを必ずデジタル保存することが義務付けられます。この対策が中心となります。

<前半のアジェンダ>
1. 電子データの保存を行ううえでの課題と対処法
2. 「電子取引Save V2.0」の紹介
3. 製品デモンストレーション

後半では、デジタルインボイス交換システム(JP PINT)で交換した電子取引データ保存になります。JP PINTはまだまだ一般的ではありませんが、今後は普及する可能性が大きいと予想されます。

<後半のアジェンダ>
1. 「連携補完機能」とは
2. 日本のデジタルインボイスの標準仕様「JP PINT」
3. 製品デモンストレーション

ウェビナー録画をYouTubeで公開しました。次のリンクでご視聴ください。
電子取引データを効率的にデジタル保存


日本に残っている「紙と電子の間」のベルリンの壁を壊せ

1989年11月にベルリンの壁が崩壊してから既に34年近くなる。ベルリンの壁は東西冷戦の時代に東と西を分断する象徴だった。その壁が崩壊して東西の主に経済的な融合、グローバル化が急速に進展して世界が今のようになった。ベルリンの壁と聞いて、そういう歴史の経過を実感をもって思い浮かべることができる人は少数派かもしれない。

9月21日岸田首相が、ニューヨークで演説して、海外資産運用業の日本市場参入を呼び掛けたというニュースが流れた。これを伝える各社のニュースを読んで、日本国民のためを考えて、日本で株式などによる資産運用を増やすために、もっと他にやることがあるだろうと感じた。

ご承知のように株式による資産運用の方法を大きく分けるとインデックス投資と個別株投資がある。そして運用によって益を得る方法を大きく分けると売買による収益(キャピタルゲイン)と配当による収益(インカムゲイン)がある。インデックス投資は資産を少しずつ増やすには良いが配当収益にはあまり重きがない。それに対して個別株投資は銘柄選択が難しいが、配当収益を得られるというメリットが大きい。ざっくり考えると、例えば、年金生活者などにとっては個別株投資で得られる株式配当を生活費の足しにするというやり方があっているのではないだろうか。一旦買い取った株式を死ぬまで保有すると考えたら、評価額の上下に一喜一憂する必要もないのだから。

少しばかり前置きが長くなったが、このような観点で、日本株と米国株で、主に配当重視の個別株投資を行ってみた結果、米国株の方が日本株よりも遥かに株主にとって有利になっていると感じた。

例えば、次のような点である。
(1) 米国株は1株から買い付けできるが、日本株は原則100株からとなり投資単位が大きい。
(2) 米国株は四半期毎(3か月に1回)の配当が多いが、日本株は半期毎の配当が主であり小さな銘柄では1年一回の配当である。
(3) 配当の権利確定日から配当が支払われるまでの日数でみると米国株は概ね30日程度であるが、日本株は90日程度かかる。
(4) 日本株は3月決算が圧倒的に多数で、12月決算と合わせると決算期が集中しており、その結果、配当支払い月も集中している。しかし、米国株の配当支払い月はかなり分散しているようだ。そこで、米国株を組み合わせることで毎月のコンスタントな配当収入の流れを作れるだろう(2023/10/11追記)。

なぜ、そのようなことになっているのか? これは恐らく日米の投資に関する規制の違いによるのではないかと思われる。これについては専門家の意見を聞いてみたいところだ。

昔、まだデジタルによる配信がなかった時代には、株式配当の受け取り用書類は郵便で送られてきたようだ。現代は株式の売り買いもネットでデジタルで行う時代である。ところが驚いたことに、日本株では株主総会招集通知はもとより、株式配当計算書が毎回郵便で送られてくる。株主総会は1年一回だが、株式配当計算書を毎回郵便で送付するのでは、株主数が増え、さらに配当回数が増えたらコストが膨大になることは容易に想像できる。また書面を作成して、印刷・送付するのに要する日数もかかる。株式配当計算や振込はコンピュータを使って実施すれば低コストで瞬時にできるはずである。ところが日本はいまだに書面なのである。

なぜ、デジタル化をさっさとやらないのか? デジタル化すればコストをそれほど増やすことなく一株株主の獲得も可能だろう。

2023年度の決算から、上場企業については株主総会招集通知のWeb化が義務付けられるようだが、このように、従来書面で行っていた手続きを、デジタル化にするには法規制が大きな壁になっているようだ。

銀行などの案内を見ても、書面の手続きとデジタルの手続きの間の壁が非常に複雑で大きいということを感じる。

岸田首相は、ニューヨークで富裕層向けの演説をする前に、日本の市民株主がもっと手軽に株を売買し、配当所得を享受できるようにするべきではないだろうか?

そのためにはまず書面とデジタルの間にあるベルリンの壁をぶち壊すことだろう。

ちなみに、ベルリンの壁の建設を担当したのはホーネッカーとされている。ホーネッカーは1989年にベルリンの壁が崩壊するまで東ドイツの権力者としての地位にとどまった。ベルリンの壁は東ドイツの発展を妨げ、ホーネッカーにとっては自ら構築した壁によって権力が維持されたのである。翻って、日本の紙と電子の壁は誰によって作られ、誰のために存在するのだろうか? 

関連情報:DX時代に逆行する電子帳簿保存法は、そろそろ、いさぎよく廃止するべきではないでしょうか? 
前回:2024年1月からの電子取引データ保存方策検討:検索要件対応で選択肢を細分すると・・・

関連記事


[XSL-FO試行錯誤]索引のページ番号表示で一部を太字にする

索引語に続くページ番号表示。「3,6,11-15,100,…」のように並んでいても、「どこがその語を説明している箇所なのか」は分かりません。そのようなときに、索引表現ではとくに重要・説明的である箇所のページ番号についてスタイルを変えて表現することがあります。これを実現するFOについて考えてみましょう。


「ある箇所について特別な処理をしたい」というとき、必要なのは次の情報です。

  • 「ある箇所」と他を区別するルール
  • 特別な処理を実現するFO

今回の場合、「通常の索引と、重要な1箇所の索引が区別できること」については元のXMLとXSLT処理の書き方によって
大きく異なると思われますので、それらを最終的に落とし込むFOについて検討します。

索引用FOの機能

索引用のFOの基本は、@index-keyによって指定されるキーと、そのキーを表示するための<fo:index-citation-reference>です。

索引 XSL-FOの基礎 第2版

これらのFOでは、該当するキーを含むページ番号について、FOプロセッサが列挙し表示を調整するという処理を行います。
つまり、FOプロセッサというユーザの手を離れた段階で処理されるので、「索引用のFOで一部のページ番号だけを太字にしたい」という要求を実現するには、このFOでは上手くいかなさそうだということを意味します。


索引用FOでは「2ページだけを太字にする」処理は難しい

索引にリンクを付けたい場合はfo:index-citation-list/@page-number-treatment="link"で表示されたページ番号にリンクが付与されます。

汎用のページ番号参照

あるページの参照だけであれば、fo:page-number-citaionに該当箇所のidを指定すれば実現できます。これを利用することにします。
制限として、数ページにわたるページ番号参照には対応できません。

汎用的なリンク用のFOであるfo:basic-linkでは、internal-destinationにidを指定することで内部リンクを付与できます。

よって、id情報があれば、該当の番号のページへジャンプするリンクが付与されたページ番号参照が実現できます。

最終的な方針とFO

重要な箇所の索引をspとします。通常の索引のときは、fo:wrapper/@index-keyを挿入する通常の索引用の属性を、spの索引のときはfo:wrapper/@idを本文に挿入します。このとき、spの前後でindex-keyの値は変えておきます。

本文のFOを通常の索引とspとで切り換える
<fo:block><fo:wrapper index-key="あんてなはうす1"/>アンテナハウスは、Data Usability Companyです。</fo:block>
<!-- spの索引語 -->
<fo:block ...><fo:wrapper id="antenna"/>アンテナハウスは、日本のソフトウェア企業で、XML自動組版ソフトウェアAntenna House Formatterや、PDFに関連した製品を開発・販売しています。</fo:block>
<fo:block ...><fo:wrapper index-key="あんてなはうす2"/></fo:block>
<fo:block ...><fo:wrapper index-key="あんてなはうす2"/></fo:block>

索引ページのFO
<fo:block ... space-after="2rem" font-size="72pt">索引</fo:block>
  <fo:block background-color="black" color="white">あ</fo:block>
  <fo:block text-align-last="justify" text-align="justify">アンテナハウス<fo:leader leader-pattern="dots" leader-alignment="center"/><!--
--><fo:index-page-citation-list merge-sequential-page-numbers="merge"
	merge-pages-across-index-key-references="merge" 
	merge-ranges-across-index-key-references="merge">
	<fo:index-page-citation-list-separator>,</fo:index-page-citation-list-separator>
	<fo:index-page-citation-range-separator>-</fo:index-page-citation-range-separator>
	<fo:index-key-reference ref-index-key="あんてなはうす1" page-number-treatment="link" />
</fo:index-page-citation-list><!--spの索引--><fo:inline>,<fo:inline font-weight="bolder"><fo:basic-link
 internal-destination="antenna"><fo:page-number-citation ref-id="antenna"/></fo:basic-link></fo:inline>,</fo:inline><fo:index-page-citation-list
  merge-sequential-page-numbers="merge"
  merge-pages-across-index-key-references="merge" 
  merge-ranges-across-index-key-references="merge">
	<fo:index-page-citation-list-separator>,
	<fo:index-page-citation-range-separator>-
	<fo:index-key-reference ref-index-key="あんてなはうす2"  page-number-treatment="link"/>
</fo:index-page-citation-list>
</fo:block>

fo:index-page-citation-listは複数のfo:index-page-referenceを持てますが、今回は特別扱いするfo:inlineを挟みたいため、一旦終了して特別処理の箇所の後に別のfo:index-page-citation-listを開始しています。

これをFormatterで組版し、冒頭に上げた画像の索引が作成できました。

補足

実作業で厄介なのはXSLTでの処理時に@index-keyを持たないspを、索引リスト作成時にどのようにして取得するかでしょうか。また、spである索引が登場する場合としない場合、sp前後に同じ語の索引が登場しない場合の「,」表示の分岐など、索引FOが吸収していた面倒な分岐も自前で用意する必要があるでしょう。

索引ウェビナーの宣伝

索引について、もう少し全般的な紹介をするウェビナーを2023年9月19,26日(火)16時に行います。今回の記事は応用実装よりでニッチ度が高いものでしたが、まだまだ話題がありますので、どうぞご検討ください。


2024年1月からの電子取引データ保存方策検討:検索要件対応で選択肢を細分すると・・・

電子帳簿保存法第7条で義務付けられている電子取引データ保存の方策を続けて検討します。2024年1月から施行される財務省令(施行規則)で適法とされる保存方策を検索要件対応まで考慮して分けると次の図の1~4の4レベルになります。

背景を黄色で塗りつぶしたセルは2024年より変更(対象者拡大)になったもの。背景をうす緑色で塗りつぶしたセルは2024年より新規追加されたものです。

保存要件対応策については、本ブログで何回か検討してきました。これまでは、検索要件対応についてのレベルを分けずに、次の二つの対応策を検討しました。
A 規則第4条第一項の保存要件に対応して保存する。
B 電子取引データの保存要件に対応せず保存だけする。

参考)
電子取引データ保存の2つの方策を比較する(9月5日)
2024年1月からの電子取引データ保存義務化への対応方法(9月4日)

保存方策Aは検索要件への対応レベルを加味すると、図表の1~3に細分できることになります。

検索要件については前回のブログで説明しています。
電子取引データ保存要件の中で、複雑なパズル並みに理解し難いのが検索要件だ

イは、①取引年月日その他の日付、②取引金額、③取引先の3項目を検索の条件として適用できるように設定するという要件です。

検索項目の設定方法としては、ワークフローシステムから電子取引データを登録するときに、自動的に検索項目を設定するシステムを構築できれば工数がかかりません。しかし、そうではなく、電子取引データを人手で登録し、そのときに検索項目を設定することになると結構工数がかかり負担が大きくなります。

検索要件のロ、ハは検索を手作業で行うときは負担になるかもしれませんが、データ保存にデータベースシステムを使っている場合は負担にならないでしょう。つまり図表の「2 検索要件イのみ対応」のメリットは大きくありません。

こうしてみると図表の「3 検索要件に対応せず保存する」という方策は検索項目を設定する必要がなくなるので、手作業で登録する際のデータ保存コストが小さくなりメリットがあります。

検索要件に対応しなくても良いケースは、2024年1月からの施行規則で適用範囲が拡大されました。具体的にはつぎのようになっています。

(1) 基準期間の売上高が5000万円以下の事業者は、税務調査でのダウンロードの求めに応じる場合、検索項目の登録が不要です。(2023年12月までは同期間の売上高が1000万円以下)。
(2) 電子取引データを出力した書面を日付などで整理をしたうえで提示・提出する求めに応じ、かつ、電子取引データのダウンロードの求めに応じる場合は検索機能の確保の要件は不要になります。(2024年1月より新設)

(2)は売上高が多くても適用されます。書面に出力したものを整理しておく必要があるので電子取引データの件数が多いとコストが大きくなりますが、件数が少ないときは採用を検討する価値があります。

前回:電子取引データ保存要件の中で、複雑なパズル並みに理解し難いのが検索要件だ
次回:日本に残っている「紙と電子の間」のベルリンの壁を壊せ

関連記事


電子取引データ保存要件の中で、複雑なパズル並みに理解し難いのが検索要件だ

電子帳簿保存法第7条の電子取引データ保存要件は全体として複雑ですが、特に分かりにくいのは、検索要件です。

検索要件の原則は登録された電子取引データから次の条件を指定して該当するものを探す(絞り込む)ことができるようにすることとされています。

イ 取引年月日その他の日付、取引金額及び取引先(ロ及びハにおいて「記録項目」という。)を検索の条件として設定することができること。
ロ 日付又は金額に係る記録項目については、その範囲を指定して条件を設定することができること。
ハ 二以上の任意の記録項目を組み合わせて条件を設定することができること。

イを実現するには、まず、それぞれの取引データに対して、①取引年月日その他の日付、②取引金額、③取引先を検索キーとして設定しておく必要があります。検索キーを設定しないで、全文検索で要件を満たすのはおそらくできないでしょうから、各取引データを保存するときに、検索キーの値を確定してその取引データに対応付けなければならないでしょう。

電子取引データの保存にデータベースシステムを使えば、検索キーを指定して入力する工数がかかりますが、ロ、ハの検索条件指定による絞り込み自体は簡単です。

ところが、国税庁の一問一答を見ると、なかなか面白いQ&Aがあります。

問16 妻と2人で事業を営んでいる個人事業主です。取引の相手方から電子メールにPDFの請求書が添付されて送付されてきました。一般的なパソコンを使用しており、プリンタも持っていますが、特別な請求書等保存ソフトは使用していません。どのように保存しておけばよいですか。
【回答】
例えば、以下のような方法で保存すれば要件を満たしていることとなります。
1 請求書データ(PDF)のファイル名に、規則性をもって内容を表示する。
例) 2022年(令和4年)10月31日に株式会社国税商事から受領した110,000円の請求書
⇒「20221031_㈱国税商事_110000」
2 「取引の相手先」や「各月」など任意のフォルダに格納して保存する。

ファイル名に検索キー3項目の値が設定されているので、ロ、ハの要件による絞り込みは実現可能なはずです。しかし、簡単ではないように思います。例えば、金額の範囲を指定して絞り込むことが簡単にできるのだろうか? そもそも、「取引の相手先」や「各月」でフォルダを分けていれば、ファイル名に取引の相手先や日付を設定する必要はないと思うのだけどね。

なお、この回答の解説には次のような検索簿の例もあります。ファイル名がこの例のようについていれば、ファイル名から図のような検索簿を作り出すのは難しくないでしょうが、いかにも整理されていない質疑応答の印象があります。


(問16の解説にある図)

こういう質問が多くあったためか基準期間の売上高が少ない事業者は検索要件が免除されています。

(上記引用の続き)
※ 税務調査の際に、税務職員からダウンロードの求めがあった場合には、上記のデータについて提出してください。
※ 判定期間に係る基準期間(通常は2年前です。)の売上高が5,000 万円以下であり、上記のダウンロードの求めに応じることができるようにしている場合又は電磁的記録を出力した書面を取引年月日その他の日付及び取引先ごとに整理されたものを提示・提出できるようにしておき、上記のダウンロードの求めに応じるようにしている場合には、上記1の設定は不要です。
(注) 令和5年度の税制改正前(令和5年12 月31 日までに行う電子取引の取引情報)については、判定期間に係る基準期間の売上高が1,000 万円以下であり、上記のダウンロードの求めに応じることができるようにしている場合に限り、上記1の設定等による検索機能の確保が不要となります。

この文章は、「上記のデータを提出してください。」と言っている一方で、「上記1の設定は不要です」と言っています。設定不要なら当該データは存在しない。しかし、データが存在しなければ提出できない。そうすると二つ目の引用部分は論理的に破綻してしまいませんか?

この質問の回答からは、検索要件の確保が不要な事業者はデータをどのように整理して出せば良いのかが理解できません。この回答を読み解くのは、筆者にとってはパズルを解くより難しいです。

出典は『電子帳簿保存法一問一答【電子取引関係】』(令和5年6月国税庁)

前回:電子取引データ保存の2つの方策を比較する
次回:2024年1月からの電子取引データ保存方策検討:検索要件対応で選択肢を細分すると・・・

関連記事


Pages: 1 2 3 4 5 6 7 8 9 10 ... 224 225 226 Next