Hieronymusのインボイス番号対応について

決算の処理をやるにあたって、インボイス番号をどうしようかなというのを考えていました。

とは言え、弊社は直接は関係ないのですが、どうせどこかで対応しなければなりませんし、「会計システム」と言うからには対応してないといけません。また、DB設計に関係あることなので、使うかどうかは別としても設計上考慮するべきものです。

運用も含めて楽で間違いのない設計を考えて悩んでいたのですが、無事解決ができました。

背景

インボイス制度が始まって、登録番号(俗に言うインボイス番号)を記録することが必要になりました。

インボイス制度の概要

制度そのものには色々思うところがあるのですが、とにかく「適格請求書(領収書)」を入手して、その番号を記録しておくことが必要です。

課題

番号のついた請求書(領収書)を入手することそれ自体は特に困難さはありません。登録事業者から来る請求書(領収書)は、基本的かつ自動的に「適格請求書(領収書)」ですから、必要事項は書かれています。つまり番号も入っています。

これをシステムに入力するのですが、

• どのテーブルにどう保持するか
• どう管理するか

という課題があります。

どのテーブルにどう保持するか

インボイス番号は請求書(領収書)に紐ついた情報です。

これを保持するには、だいたい以下のテーブルが考えられます。

1. 伝票の明細行テーブル
2. 取引先テーブル
3. 証憑テーブル

最初に考えたのは、1の伝票の明細行のテーブルです。もっと前には伝票の情報として保持することを考えたのですが、1枚の伝票に書く取引相手が1つとは限らないかも知れないので、明細行のテーブルかなということです。実際、請求書(領収書)と伝票はいつもセットで扱うので、打ち込みの時には「そこ」に番号を書いたものがあります。それをそのまま入力すれば良いので、いろいろ簡単で間違いもありません。

それは良いんですが、伝票を入力する度に毎回入力することになって面倒臭いです。13桁もある番号を都度入力して間違えない自信はありません。

次に考えたのは2の取引先テーブルです。どうせほとんどの取引先は登録されているわけなので、そこに番号を入れておけばそれを引くだけで済みます。何なら引くまでもないかも知れません。オペレーションは簡単ですし、入力ミスもありません。

それは良いんですが、たとえば「出張先で使ったコンビニ」とかのように、多分もう二度と取引しないであろう「取引先」まで登録するのはちょっとナンセンスに感じます。そういったものはどこかのテーブルに直接入力出来れば都合が良いです。とは言え、どこのテーブルにも属さないで取引データ(伝票)にだけ番号が存在しているのは、あまり気持ちが良くありません。

そうなると次に保存場所として考えられるのは、証憑データの入ったテーブルです。そもそも、インボイス番号は証憑に紐付いているわけですから、ここにあるのが一番自然だと言えます。ある意味自明です。

とは言え、現会計システムの運用では「証票テーブル」は電子化データの保存のためのものであって、全ての証憑が入っているわけではありません。電子化データを持たない証憑については「伝票と一緒にクリップする(後述)」ということで管理されています。

ということで、「ここだ！」と言える場所は、そのままでは存在していません。

どう管理するか

基本的にはインボイス番号は証憑に紐付いているとは言え、取引先固有のデータです。現会計システムは取引先を管理していますから、どういった形であれここで「管理」をする必要があります。

ここで問題になるのは、多くの取引先は「法人」であって、法人はM&A等があれば変わるということです。それと共にインボイス番号が変わることはありうることなので、そこを管理する必要があります。

と同時に、国税庁のサイトであまり明示的には書いてないですが、保持するべきインボイス番号は証憑単位で有効だということです。どういうことかと言えば、仮に途中でインボイス番号が変わったとしても、既に発行された証憑に書かれたインボイス番号はその証憑に書かれた番号としては有効であり、取引先のインボイス番号が変わっても元のままでなければならないということです。

ですから、「インボイス番号は取引先情報にリンクしておけば良い」という実装にはできないということです。取引毎に証憑なり伝票なりのデータに複製されてないといけません。つまり、仮に「一見さん取引先」まで取引先に登録するという運用にしたとしても、それでインボイス番号の実装そのものが完了するわけではありません。

実装

Twitterでこの辺の話を書いていたのですが、そこでヒントがもらえました。

まず第一にインボイス番号は保持さえしてあれば良く、それ以上の処理が必要がないということです。これは結局、電子化証憑の話と同じで、「後で見てわかればいい」だけであってそれで何かをする必要はまずなく、せいぜい検索が出来れば十分であるということです。何なら「実物見れば書いてあるじゃん」でも良いようです。

そして結局のところインボイス番号は証憑に紐付いた情報であり、それ以上でもそれ以下でもないということです。伝票の明細行に入れるという実装は、この時点で消えます。

ということで、

1. 基本的に証票テーブルの項目として入力して保持する
2. その入力補助のために取引先テーブルにも保持する
3. 証票テーブルは電子化証憑のためという実装を変更する

ということにしました。1. 2.は自明とも言えるんですが、3がなかなか思いつかなかったのです。

裏の話

実は弊社の会計は創業の時から「会計システム」を運用していて、最初から電子化されていました。とは言え、ごく初期(1期とか)は自分の勉強のために伝票を書いていましたし、2期から3期の間でDBを飛ばすという経験をしてしまい、その時に「手書き伝票があったお陰で復旧が容易だった」という体験があって、伝票を書くことにしていたのです。

かなり経って色々慣れたりしたのですが、紙の証憑を保存する時の「しおりとメモ」としての伝票は便利なので、紙の証憑がある場合は面倒でも手書き伝票を作ることにしていたのです。紙の証憑がないものについては伝票も書かずに済ますようになっても、紙の証憑がある場合には必ず伝票を書いていました。

それゆえ、証票テーブルも電子化データのことだけ考えていて、チェックの中で「電子化データが添付されていないとエラー」なんてのが入ってるくらいでした。

まとめ

そんなわけで、Hieronymusも無事インボイス対応ができました。

「相手先」を入力すると、登録済みの取引先はそこにあるインボイス番号を持って来てくれます。

紙の証憑があるものまで証憑登録するのは面倒臭いですが、これは許容範囲でしょう。今後は電子化証憑の方が増えるでしょうし。インボイス制度そのものの面倒臭さは別の話ですけど。

次回のメジャーバージョンアップの時にリリースできると思います。

PS. 「証票」or「証憑」

mayumiが「証憑と証票とどっち？」とか言ってたのですが、解説がありました。

証憑と証票の違い

前者の意味で後者を使ったりするのはよくありますし、私もそうしちゃってたことがあるので、実用的には「同じ」でもいいと思うのですが念のため。上の説明で「証票」を使っているのは、テーブル名をそうしちゃってるからです。まぁコード上ではvoucherって書いてるんですが。