消費税が上がると、世の中の多くのシステムで問題が発生して混乱が起きると予想されます。

汎用的に作られているパッケージなどでは問題は少ないと思いますが、受託開発などで専用に作られたシステムでは特に早急な確認が必要だと思います。

つーか税率が恒久的に変わらないわけないんだからそもそも考慮されてるべきだろ!は正論ですが、多くのシステムでは実際そうなっていないと思われます。

消費税が現行の5%になったのは1997年。もう15年も前のこと。今回の増税は、本格的にインターネットが普及してから初の消費税率UPと言えます。つまり世の中のほとんどのWebシステムにとって今回が初めての経験となります。

販売を扱うシステムでは消費税という要素はもちろん考慮されているはずです。しかし多くの場合「税率はめったに変わらない」という前提で作られているのが現状ではないでしょうか。

国際対応のシステムでもない限り「消費税率の設定」なんて機能を持つシステムは稀なくらいだと思います。多くの場合、ロジック内に組み込まれているような完全なハードコーディングではないにしても、内部的な設定ファイルに書かれていたり、定数などの形でプログラムに埋め込まれていたりしています。

いずれにしてもこういう作りではユーザーが自分で簡単に変更、というのは難しいので、開発元に依頼してのシステム改修・テスト、ということになります。場合によっては古い開発環境を整えたりしなければならないかもしないから、とにかくできるだけ早いうちに開発元に相談するべきです。でも10年以上前ともなると、開発元とすでに連絡がとれなくなっているような場合もあるでしょう。そんな時は他の開発者に頼むしかありませんが、それを十分な調査なく安請け合いする奴は危険かもしれません。

単純にプログラムの税率を変えるだけなら、そう難しいことではないはずです。「.05」とかをgrepして書き換えれば、なんとなくうまくいくかも。しかしシステムの中には、異なる消費税率のデータが共存することを想定していない、あるいは十分にテストされていないものもあります。たとえば注文履歴表示で、毎回設定税率で再計算表示するように実装されているものとか。消費税率8%に変更したら、過去のデータも8%で扱われてしまうかもしれません。こういうシステムはかなり厄介。最悪改修不可能というケースもありそうです。いずれにしても単に直すだけでなく、テストのことなども考えるとそれなりに大変な作業になりそうです。

 

とりあえず今後作るシステムでは、まず税率が段階的に上がることがわかっているのだから、簡単に税率を変更できるようにするべきなのはもちろんとして、税率を変えた場合の動作、複数税率でのデータ共存について、きちんとテストしておきべき。また、将来欧州みたいに商品によって税率が変わることも想定しておいたほうがいいと思います。

僕自身がこれまで作ったシステムでは、商品データを扱う場合は商品レコードに消費税率を持つようにすることと、確定した金額は再計算しないように複製を持つということを常に心がけてはいたけど、税率変更を想定したテストは十分ではなかったりするので、見直さないといけない状況。