消費税の実装ってむずかしい（ベタ打ちもあるヨ）

なんかいろんなニュースに押されてすっかりブームが去ったみたいな消費税率改定についてちょっとシステム的な話をしてみたい。
　
業務システムやってる人はみんな知ってることだけど消費税って難しいんですよ。
売り上げに1.05掛けるだけかと思えば端数処理あるし、端数は大抵は切り捨てでよかったりするけど法律で決まってるわけじゃないから慣習的にこのお客さんは四捨五入とかあったりして。それから個別に掛けてから合計したときと合計してから掛けたときとで結果が異なったりするしいろいろすっきりしない処理が出てくる。
　
で、まあ会計的な面倒くささはおいといても、システム的にもいろいろと考慮しなければいけない点が多い。5%とかの値はベタ打ちはダメでテーブルに入れておけ、というのは定石ではあるけれどことはそう簡単じゃない。
　
たとえば2014年4月から8%になりますというときにどうするか？　4月1日の深夜0時になったら担当者が値を書き換えるの？　いやいや人力でやるのはちょっとナニだし。そう考えたら適用開始年月日、適用終了年月日のカラムが必要だよね。
で、消費税テーブルには、

ID	税率	適用開始年月日	適用終了年月日
1	5%	1997年4月1日	2014年3月31日
2	8%	2014年4月1日	2015年9月30日

というレコードが並ぶことになる。
もちろん売り上げ計算のたびに現在日時と比較して適切な税率を取得するロジックを入れる。長いバッチ処理だと一連の処理の途中で税率切り替え日時がきてもおかしくならないように処理の最初に税率を取得してそれを使い回すとか。
ほら、もうかなり面倒になってきた。
　
しかもこの税率切り替えの仕組み10年に1度使うかどうかっていう使用頻度。システム寿命よりも長いくらい。だったらそんな仕組み作らずに切り替え当日だけ簡単な深夜作業で対応しようかとかそういったトレードオフになるよね。
　
それから会社の中の業務システムが一枚岩で完全に連動してるってことは少なくて導入時期だったり部署ごとだったりけっこうわかれてたりする。まあ、疎結合なのはそんなに悪いことじゃないけどね。でもそれらバラバラのシステムでたいてい消費税を扱ってる。
　
NTPサーバが現在時刻を配信するみたいな仕組みで消費税率を一元的に配信してたりすると楽なんだけど、もちろんそんな仕組みはなくて、ということは消費税の値を格納しているテーブルがいろんなところに点在してたりする。どのテーブルのどのカラムに入っているかわからない値を探すのって大変だし、カラム名もtaxとかshohizeiとかsyouhizeiとかいろいろあり得るから、それらを全部洗い出す作業は想像するだけでも大変そうだ。
　
ねえ、それって税率をテーブルに入れずにソースコードにベタ打ちして10年に1度くらいの税率変更のときは全ソースを1.05と0.05でgrepした方が楽じゃない？　って気持ちになったりもするんだけど、どうだろ。
　
まあ、そこまでやってもExcelの数式に埋まってるのとか必ず見落としちゃうんだけどね。