消費税マスタの取り扱い

消費税と言えば、実務上は困難が多くシステム屋にとっては鬼門とも言える制度なのだが、どのように設計すべきなのだろうか（と、いいつつ今日この件でもめたので、意見を頂けたら幸いとか思っているのだが）。

古典的なシステム（というより消費税施行前に開発されたシステムの場合）の場合、単純に税率を計算ロジックとして持っていたこともあったのだが、この手のシステムは５％への税率アップでひどい目にあって今ではほとんど絶滅したものと思われる（移行期に旧税率のものと新税率の取引の混在が存在するため）。

現在はどうかというと、消費税率マスタを保持し適用期間で％を決めるという簡易的な手法を取ることも多い（特に基幹から少し離れた営業支援系のシステムではこのような仕組みが多いように思う）。しかし、この手法の問題点は、旧税率の商品を扱う場合（消費税法を読む限り極めて例外的なはずなのだが、どこの企業でも同じ話を聞くので何か見逃しているのかもしれない）や返品時や貸倒時の消費税の取り扱いが難しいという実務上の問題がある。また、それだけではなく、消費税申告書の作成には不課税、非課税、課税/非課税売上、課税/非課税売上対応仕入、貸倒、有価証券譲渡といった区別が必要なため、取引が特定の区分に定まらない基幹系のシステムではもう少しこった仕組みが必要となる。

では、具体的にはどうするのかと言うと、近代的なシステムの場合、消費税（あるいは税区分）マスタと呼ばれるマスタを用意して対応するのが普通である。消費税マスタには、前述の税区分や税率、内税・外税といった内容を登録する。そこで私は下記のような消費税マスタ構成を申請したわけだ*1。

すると、データモデル設計担当者より、そのような設計にすると消費税率変更時にほとんどの商品の消費税コードを変更する必要があるので、次のようなモデルにした方がよいのではないかという意見を頂いた。

消費税率変更時には、商品コードと消費税コードの紐付けを変えるのではなく消費税コードの中身を変更しようという考えである。仕入返品の際には発注イベントの取引日に注意する必要があったり、一部税率の異なる商品が混ざっていると一括変更ができないのだが、システム的に矛盾が起きるというほどのことはない。

個人的には消費税コードの税率が変化していくという概念が消費税コード自体のアイデンティティを破壊しているように思える（税率が3%から5%に変化したというのは税率が上がったのではなく、新しい税制が制定された＝新しい消費税コードの取得が必要だと考える）のでとりあえず反対はしたのだが、問題がないのであれば楽な方が良いと主張されたら反論は難しい。

さて、どうすべきか。某GRANDITという会計パッケージでは、税区分マスタと消費税率マスタに分かれているという噂も聞いたので、より良い方法を模索すべきということなのだろうか。

*1:複合主キー方式なのは、私がデータモデル設計担当ではないからである。本当のことを言えばこのような適用期間を持つ場合こそID方式の利点が明確に出てくるわけだが、今回の話題では重要ではないので気にしないことにする。