【データベース】インボイスで必要となるDB変更や追加を書いてみた。
最近「インボイス対応、大変過ぎ!」という経理さんの投稿をSNSで見かけます。
そうだろうな…と思いつつも、会社組織を離れてフリーランスの身である自分。加えて、インボイスには登録しなかったため、イマイチはっきりとはわからず。。
で、「自分が会社内の情報システム部にいて、何か対応を依頼されるとしたら…」という視点でメモ書きをしてみました。
するとやっぱり、大変さがわかってきたので、ここに転記してみようと思います。
①社内に独自の顧客DBがあると仮定する
自分が昔SEやってた時は、市販の顧客管理システム使っているところじゃなくて、独自のシステム作っているところのDBに関わっていたため(下請けですけどね☆)、それを前提条件とします。
②現在ある顧客マスタにはインボイス関連のフラグを追加
で、今ある顧客マスタに2つ、項目が必要になるかなぁと。
ひとつめが、インボイス登録の有無ですね。0が登録なしで 1だと登録あり。
ふたつめが、登録情報の確認を社内でしてあるか否か。
0が未確認。2が済。1が再確認を必要とする状態、にしてみました。
0だとレコードを Insertする。 1だと、項目を再確認して一致しないものを新しいものに上書き=update、という感じで使うのかなぁと。
③インボイス情報のマスタを新設
で、顧客マスタとCustNo=顧客番号で一致するものの、インボイス登録情報を公式サイト(https://www.invoice-kohyo.nta.go.jp/index.html)で検索&取得した情報を格納するマスタ=インボイス情報マスタを新設かなぁと。
ここで、Tから始まる登録番号って、一回発行されたらずっと変わらないよね…?いや、変わるケースってあり得る??と不安に。
どちらでも対応できるように、ユニークナンバーはやはり内部番号にした方が無難だよね、と考えます。
これを調べているときに、住所と屋号の登録が任意だということに気づきました。
これが、世間のニュースでいうところの「身バレ」しちゃうとかなんとかなんですね…。
DB設計の立場では、必須項目にするか否かがポイントでした。
①②③をまとめると、以下の図が出来上がりました ↓↓↓
④バッチ(一括)処理の必要性を考える
これ、わたしみたいな顧客数が少ないところと違って、ある程度大きい会社なら、
何百という数を
「Tから始まる登録番号をコピペして検索して表示された情報から、屋号や代表者名、住所が請求書と一致しているか確認」
って作業が必要になるってことですよね。
…大変だ!!!
手順は
①顧客マスタを名簿として、メールなり文書なりで「インボイス登録事業者になりますか?」の確認をとる
②①の返事を顧客マスタに反映
③インボイス登録するお客様ならTから始まる番号を知らせてもらう
④③の番号から、公式サイトで確認した内容をインボイス情報マスタに登録する
公式サイトにAPIがあるってことだったので、情報システム部か外注かで、一括処理をするツールを作ることになるんだろうな、と思いました。
っていう感じでしょうか…。
で、経理さんが個別に対応するケースもあるでしょうから、インボイス情報マスタに登録できる画面もひとつ作って。
⑤インボイス番号のある請求書や領収書があるなら、確認も自動でして欲しいかも
請求書や領収書がすでに存在する(10月過ぎてるからありますよね…)なら、そこに記載されているTから始まる番号と住所、会社名などが、公式サイト、もしくはインボイス情報マスタと一致しているかも確認必要ですよね。
で、自動で確認してくれるツール…求められると思います…。。。
うーん、①~⑤までで、いくつ処理を追加したでしょうね…💦
⑥まとめ
「情報システム部に、もし自分がいたら…」
で、予想でつらつら書いてみたのですが、たぶん、これ以外にも実務できっちり条件を詰めて決めないといけないことがたくさんあると思います。
やっぱり大変です💦
今というより、年度末・確定申告時期にはもっと大変になりそうな予感です。
全国の経理担当者さん&情報システム担当者さんに、心からの敬意をー。
お読みいただき、ありがとうございました☆ スキorコメントでどの記事が役立ったかリアクションして頂ければ、それ関連の記事をたくさん書くよう頑張ります♬ https://chitose-it.com https://asagao-startup.com