税務LAN®ブログ

　2月18日付総税市第６号でも公的年金の光ディスクの提出に関する通知が来ておりましたが、昨日は、地電協からも公的年金のレイアウトが通知されたようですね。
　以前に通知されていたレイアウトと同じですので、特に驚くべき内容では無いのですが、普通徴収の項目が消除されておりました。
　基本、年金特徴通知されるもの以外の年金は、特に普通徴収希望としたところで、普通徴収になるわけでもないので、この項目は長らく不要なものでした。いよいよ抹消と言う事です。
　来年の課税資料のパンチレイアウトもこの事に伴って、寡婦夫の追加や、普通徴収の抹消などの影響を受けますので、予め周知いたします。

　ちなみに、この331CSVレイアウトを給報315datみたいにXMLにサンドイッチして、eLTAX年金として配信させる仕組みを作ったりしませんよね。eLTAX年金は綺麗？なXMLのままでいて欲しいと願うものです。

ｂｙ　千田

　先だって（と言っても大分前になりますが）、鯖のへしこを食べる機会がありました。
　お魚大好きの私としては、非常にありがたく戴きました。
　骨を抜いた半身を５～６ミリにスライスして、日本酒で糠を洗い落とし、３０分ほどそのお酒に漬け込みます。
　後は、熱々のご飯に載せて、これまた熱々の鰹出汁を掛けて、水菜を載せてさらさらと。
　とても濃厚で、魚卵的な、そう、カラスミの様な味がしました。
　ちょっと工夫すると、何倍も美味しくなりますね。

感謝感謝。

ｂｙ　千田

課税コンバータに関しまして準備が出来次第順次配信しております。
今週中には全て配信が完了する予定ですが、もし届かない様でしたらご一報頂くと幸いです。
複数団体で使用される課税コンバータにつきましては代表者様へ配信致しますので、お手数ですが関係者様へご展開頂く様お願い致します。

ｂｙ　山谷

国税連携で配布される申告書の画像は200dpi(203dpi)ですが、税務署のＯＣＲシステムが、この解像度の画像にＯＣＲ処理を掛けているとは思えません。ＯＣＲ認識をさせるのであれば、少なくとも300dpiは欲しいと思います。またモノクロ２値画像では認識率も落ちますので、昨今はカラー画像で罫線消去を行うのがスタンダードですから、カラー画像処理を行っていると想像するわけです。

対して、自治体で処理する場合には、モノクロ２値の解像度の低い画像で処理を行わなければならないので、それだけでもハンディキャップがあるわけです。

昨日、思いもよらないエラーに遭遇しました。
認識した数字が、「83e2000」と言う文字列でした。本当は、「8302000」なのですが、83の次の0が歪んでいたために、eと誤認識してしまったのです。この数値を受け取る変数が倍精度実数だったために、10e±308迄の制限があったために、変換値を受け取れないエラーが出てしまいました。数字を数値に変換する関数は、10e±4096（拡張倍精度実数）まで対応していたので、変換エラーにはならずに、変数に入れる時点でオーバーフローするというものでした。（対策済み）

さて、今回サンプリングした画像データを見ていてある事に気がつきました。
それは、画像を連続で見ていくとＯＣＲマークの位置が全くぶれていない事です。このことは、２年前にも確認していまして、その事で画像位置検出の精度が向上したと思っていたのです。
ところが、ＯＣＲマークの位置は動かないものの、申告書の表はぐらぐら動いていました。これはどういう事なのか？
税務署で画像を採取する際に、このＯＣＲマークによって斜め補正、縦横縮尺、台形補正などを行っていると思いますが、同時に画像の矯正も行っている様です。その際に歪んでしまうＯＣＲマークを改めて置きに行っていると考えられます。我々のＯＣＲ認識でもＯＣＲマークにより、斜め補正、縮尺補正、台形補正処理を掛けていたのですが、なぜかパラメータが変移しないのは、このためだったのです。
実際にＯＣＲマーク位置から算出したオフセットとゆがみ補正を掛けた後の読み取り位置の精度が向上しないのはこの為だったのです。

はてさて困りました。
困ってばかりもいられないので、一部のお客様向けに、読み取る場所の外枠線を認識し、その内側に認識処理を掛ける荒技ルーチンを実装してリリースを行いました。精度は期待以上に向上しています。処理時間とはトレードですが。
この処理が奏功するのであれば、２表の処理にも応用を検討しています。本年実装は無理ですが来年なら。
実は、初年度開始時に申告書の位置決めを行うために、この処理を行う基本ルーチンを実装し、検証も完了しておりました。ＯＣＲ位置が正しく来るものだから、この機能は使う必要が無くなって、そのままお蔵入りしていました。
何事も捨てずに取って置くものだと感じました。

ｂｙ　千田

税務LANの背景色がピンク色の時は「桃色申告」と呼ばれた事が有った・・・（遠い目）。

ｂｙ　千田

どうでも良い事を書いてしまった。

ついでに数値丸めの話。（何がついでだ！）
四捨五入と五捨五入の話について。
数値丸めで一般的（学校で習うという意味で）なのは、四捨五入ですが、金融系では五捨五入が使われます。そう言う意味では一般的なのは、五捨五入ですね。本当かな？
数字は、１から始まって１０まであります。
でも小さい方に丸める際には０にしますよね。
つまり０～１０までの数字の間で片寄せされる訳です。要素数は１１あります。
０～４までで要素は５個。６～１０までで要素は５個。
つまり５と言う数字は、中間点であり、四捨五入したのでは、５～１０と要素数６となり平衡では無くなりますね。（バイアスが掛かると言います。）
そこで、５と言う値を切り捨て、切り上げ両方に寄せられるように機会を均等に提供するのが五捨五入の考え方です。
丸める数値の一つ上の数値が偶数か奇数か（均等に機会が与えられています）で切り捨てるか切り上げるかを振り分けます。

数年前まで、弊社の入社試験にこの問題を出していましたが、解けなかった学生があまりにも多かった。こういう事は勉強させられないんだなぁ・・・と言う感想をその時は持ちました。
上記を質問してくるＳＥも意外と多いんですよ、現実。
（JISZ8401規則A、bankers roundingを参照）

次回は、国税連携で渡される画像のOCRマークに関して。

ｂｙ　千田

e-Tax申告データのサンプリングの検証続きです。

　住宅借入金の震災被災再取得または、重複適用の入力の仕方について、１枚目にどの対象を入れて、２枚目にどっちを入れるかという問題が見つかっております。

　通常は、今現在住んでいる方が新築分の筈ですから、書類申請の関係からも１枚目に入れてあると思いたいし、特例によって、住んでいない（流された）方の住借控除を認めると言う法ですから、こちらが２枚目に記載されるべきと考えていました。（勝手な思い込みかも知れませんが）
　今回、逆の記載例が見つかりました。
　再取得前は、流された方の住借控除申告のみ行っていた訳ですから、慣れもあってなのか１枚目に従来の申告。２枚目に新築分という感じで記載したのでしょう。（と想像します）

　内部で処理する際には、居住開始年月日を確認し、震災再取得対象なのかどうかの判定を見て、適用区分4（給報記載で言う所の）と共に震災再取得にチェックを立てています。
　このチェックが立たないと1.2%の計算も回らないわけで、検算値が合わなくなってしまいます。

　震災対象の場合には、日付の大小比較を行い、データをぐりっと入れ替える操作も検討しています。

　通常の重複適用の場合には、特にどっちに何が入っていても問題無いです。両方の合計を上限でカットするだけですから。

　話変わって、今週は暖かい日が続いて、駐車場の雪山もみるみる小さくなっていきます。泥化粧も目立つ様になりまして、はっきり言って汚いです。
　震災がらみですが、あれから２年も経つのかと思うと年月の過ぎる速さを思い知らされます。

往けるものたち、菩提薩婆訶。
生かされたものたち、菩提薩婆訶。

ｂｙ　千田

e-Taxデータのサンプリングを行っていて気がついた事が有ります。

　申告書２表の生保の支払いに「源泉徴収票のとおり」の記載となっている簡易申告パターンなのに、生保控除額の金額が記載されている申告書がＡ申、Ｂ申問わず出現しています。
　もちろん、記載の無い申告書もあります。
　未年調給報で社保等に変更が有るのかと思いきや、そんな事もなく。

　この申告書に対して生保控除の支払い補完を処置すると、源泉の通りとなっているものは、支払いがオールゼロ円ですので、補完処理が走り、せっかく給報の源泉記載があり、　しかもそれが正しいとしても補完値で上書きされてしまいます。（本来は控除額記載もゼロ円であるはずなので。）
　とても残念な結果となります。
　上記の混在割合が馬鹿に出来ない様なので、何かしらの対策を施したいと考えます。

　どこぞの掲示板にも、簡易申告でもないのに「源泉徴収票のとおり」と出力されるのは問題だと書き込まれていましたが、この事が意味する事態に気がつくのが遅かったです。
（とは言うものの実サンプルで検証する事が難しいので、この時期になってしまうのですが）

　申告書作成コーナーの仕様は誰が決めているんでしょうかね？
　もう少し、住民税を課税する側の立場に立って物事を考えられないのでしょうか？
　縦割りなどと言っている場合じゃないです。「そんな時代よね～」

　関連して、介護保険料支払いだけ申告書に記載して、その他の生保、個人年金支払いは「源泉徴収票のとおり」となっているものは、補完も出来ないし、源泉スルーも出来ない。なんでこんな申告書を作るんだろう。

本日の反省
「設計者は一番のヘビーユーザーでなければならない。」

ｂｙ　千田