なぜやったか？

登録されている価格値は全て税込価格だったのですが、5% → 8% 増税の際には価格値を全て更新していました。

税率, 税金額の情報を持っていませんでした。

競合他社が外税で運用しているため、ユーザー目線だと一見はこちらの価格の方が高いと思われることがありました。

そして、新年度がスタートするから。
(取引先によりますが、公的機関だと年度の途中で内税→外税の変更はしてはいけない決まりがあるそうです)

やったこと

ざっくり一覧

リリース当日に流すやつ

クレジットカード, コンビニ. ATM, 銀行ネットなどいろいろな決済方法を選べる場合が多いと思います。
決済代行会社を使われている場合は、そちらに注文情報(主に支払い方法と支払い金額)を渡せば問題ないですが、
(今回の場合) paidy決済は例外でした。

DB設計の際、値は消費税8%の8を持たせることにしました。
では、型はintegerか？

次の増税では10%になるのでintegerで問題はないかもしれませんが、
海外では小数点ありの税率があるそうです。
例: インドで12.5%
全国間税会総連合会世界の消費税(付加価値税)152ヵ国

今後の税率がどうなるかはわかりませんが、小数点を考慮しておいても良いかもしれません。

税込額 → 税抜額への変換になりますが、8%なのでほぼ割り切れません。
小数点以下の扱いは社内や取引先との決めの問題になるかと思います。

その結果、切り捨て, 切り上げ, 四捨五入になるかは商品によって異なりました。
なので、価格値一括更新は上記を考慮する必要があります。
※ ここは価格設定の話で、ユーザーが購入する際の端数処理は統一となります。

しかし、カート内金額の一括更新では以下にも注意が必要です。

本システムの場合、カート内の金額情報には割引が適応された金額が入る仕様でした。
逆算でも問題なかったかもしれませんが、
今回は商品IDから税抜価格に更新した価格テーブルの値を元に、再度キャンペーン価格の計算をしました。

15年近く運用しているサービスだったこともあり、レジフローや売上集計周りのコード,設計がとにかく古かった。
サービスの歴史を感じた。

価格設定から売上集計まで一連の流れを把握する必要があった。
ユーザーサイドから管理画面サイドの仕様も把握する必要があった。

社歴は長い方なので、大抵の仕様は把握してましたが
本件に関してはブラックボックスすぎた。。。

後は、何事もトラブルが起きないことを祈るばかりです。