さて、ちょっと起業ネタはお休みしまして、まったく別のお話。

先日、弊社に、古いシステムのリプレース(作り替え)をご相談にいらしたお客さんがいました。

いろいろと状況をお聞きしましたところ、Accessで開発されたかなり古いシステムを、AjaxやjQueryをガチャガチャ使ったカッコイイWEBシステムにしたいという、まあよくあるお話しだったのですが、ご依頼に来られた社長さんがヒアリングの途中で一つ気になることをおっしゃいました。

私は、「あ、ああーー、そうですよね。了解です。」と返事をしたのですが、それからしばらく、「ん？ん？」と、それをどうやって実装するのかで頭が一杯になってしまいました。

消費税の増税。。ついに現実にそういう話が出てくるのですね。

おお、これを見ると意外と近い話です。来年2013年の秋ぐらいから段階的に増税されていくというように書かれていますね。

まあ、途中に解散総選挙とかあると、実際はいつになるか分かりませんが。

しかし「税率は段階的に引き上げていく」というのは、自民党案でもそうだと聞きます。

これは、消費者視点でみれば、「なんだよ、だんだん苦しくなっていくのかよ、納得いかないな」程度で済むのですが、消費税の管理をしているシステムにとってはかなり厄介な問題です。

ということで、今日は仮に

こんな事態を想定しまして、これに耐えられるにはシステム的にどのように対応したらよいのでしょうか？を考えます。

これまで、「消費税が変わっても大丈夫なようにしておいて」とお客さんに言われたら、「はい、かしこまりました」という感じでやるのが

という方法でした。

これは、見積書、請求書を作成する際には必ずこの設定ファイルを参照して税率を確定し、データベースの個々のデータレコードにその税率、税額を残していく方法です。これで、たとえばある日から消費税が8％になっても、古いデータは書き換わらず、その日以降のデータのみが8％になる、ということが可能になります。

これまでは消費税増税が現実的ではなかったので、こんな方法でお茶を濁していたのですが、(ウチが酷いのではなく、大抵どこの会社もそうです)実はこれでは消費税増税には対応できません。

この方法を貫き通そうとすると、上記の例の場合、2013年の9月30日の夜、業務が終了した深夜に、私どものような開発屋が、システムの設定値を「5」から「8」に書き替えます。

すると、翌日オペレータさんがシステムにデータを入力する時点では消費税は8％になっています。しかし、実際は、2013年9月30日のデータを入れる必要があるというケースがあり、その場合は5％で計算しないといけません。

また実際の業務では、先月発行した請求書について、宛先を書き替えて送って欲しいと言われたり(顧客マスタが異なるから変更ではなく新規の起票になる)、バックデート(昔の日付)での捏造見積書などを出して欲しいと言われたり、と、コンピュータさん的には訳の分からない業務があり、この時点で完全に破綻するわけです。

もう少し本気で考えている開発会社なら、消費税率を複数登録できるようにしておいて、その適用日と一緒に設定できるようにしているかも知れません。

そして、請求書や見積書の発行日付を元にして、消費税率を算出する、と。

このようなイメージ。

この方法なら、設定ファイルをリアルタイムに変更する必要はありませんし、過去の発行日付で税率を変えて出すこともできます。

しかしながら、見積書や請求書の発行日を元にして、消費税を計算すればよい、という保証はどこにもありません。

たとえば、請求は商品の納品時に行うという契約になっていて、消費税5％の期間内に納品される予定だったのに、業者側の手違いで納品が遅れたので請求書の発行が遅れ、それで消費税が8％になった、などというが許されるとは考えにくいわけです。

なので、このように慎重に消費税を適用日と共に管理しようとしても、税額を自動計算させている限り、実用に耐えられません。

結局のところは、人間の判断が必要ということでしょう。

消費税の設定自体は[2]のように、適用日とセットで複数保持できるようにしておいて、請求書、見積書の発行日を元に自動で計算し、デフォルト表示させますが、都度オペレータ判断で手でも直せるようにしておくのが良さそうです。

もう少し頑張ってみます。

データの持ち方的には、ここ数年の私の脳内トレンドでは、請求明細行には消費税を持たせず、請求の親テーブルにのみ持つようにしていました。そうしないと端数が合わなくなることがあるし、それを一生懸命合わせるユーザーインターフェースを作ってもメリットがほとんどないからです。

しかし、今後は品目ごとに消費税が変わることも十分考えられるので、明細行にも税額と適用税率の両方を持たせておいた方がよさそうです。非課税品目も許容するようにしておいた方がいいかも知れません。

税額が変動すると、一番問題になるのは、納付すべき税額の計算ですが、とりあえず上記のようなデータの格納をしておけば、「原則課税」であっても「簡易課税」であってもどちらにも対応できます。

見積書、請求書の出し方は若干工夫が必要でしょう。

やはり段階的に消費税がアップしていくという前提で考えると、総額方式(内税表示)の見積書、請求書は分かりにくく、お客さんとの間でトラブルの元になります。

2004年の税制改正によって、請求書は総額方式が義務づけられましたが、決して消費税額を記載してはいけない訳ではありませんので、これは今のうちから明確に分離して「外税方式的に」表示するようにしておいた方がいいです。

そして見積と請求の間にタイムラグが発生する場合は、その間に税率が変わっている可能性がありますので、一度5％で出した見積もりを呼び出して、簡単に8％、10％に修正できるシステムが求められるでしょう。

またその履歴をきちんと保持しておかないと、お客さんにいったい税率をいくらでご案内したのか、発注時点で何％ということで確定したのか、が追っていけなくなります。まあ、「そこは割り切り」で最後の1つだけ残せばよしとするかも知れませんが、しっかり作るなら、履歴を残していきます。

さて、上記のように、今政府が、「消費税額は段階的に8％から10％にアップする」などと、消費者の痛みを和らげつつズルズル行こうとしている政策は、システムとしてはかなり高度で複雑な機能が求められます。

場合によっては、現在お使いのシステムの完全な作り直しが必要になってくるかも知れません。

という経営者の方、情報システム部の方、是非弊社にご連絡下さいませ。（あっ、ステマがばれちゃいました...！）

という方もいらっしゃると思います。こちらも弊社にご連絡ください。

ご一緒にベストな方法を考えさせていただきます。

この改造をウチでやるのがベストな方法とは言えません。運用でカバーできそうであれば、そのようにご提案するのが私のようなシステムコンサルタントです。

お騒がせしました。以上で、ステマの方を終了させていただきます。

━━━━━━━━━━━━━━━━━━━━━━━━━━

 株式会社　プラムザ

 システムコンサルタント　島田　徹　(Toru Shimada)

 info@plumsa.co.jp

 http://www.plumsa.co.jp/

 twitter| https://twitter.com/#!/torshim

━━━━━━━━━━━━━━━━━━━━━━━━━━