新年度になりました。
みなさん新年度最初のリリースは何を行いましたか？
私はECサイトを外税化しました。
なぜやったか？
登録されている価格値は全て税込価格だったのですが、5% → 8% 増税の際には価格値を全て更新していました。
税率, 税金額の情報を持っていませんでした。
競合他社が外税で運用しているため、ユーザー目線だと一見はこちらの価格の方が高いと思われることがありました。
そして、新年度がスタートするから。
(取引先によりますが、公的機関だと年度の途中で内税→外税の変更はしてはいけない決まりがあるそうです)
やったこと
ざっくり一覧
1.ユーザーサイド
- 外税金額表示に
- 商品金額, 送料など
- レジでの税金額算出, 表示
- 商品金額合計 + 送料から算出
- 割引もあれば割引後に算出
- 注文毎に税率, 税金額を保存
- 注文履歴の表示変更
- 過去のものは内税表記のまま
2.管理画面サイド
- 注文履歴
- ユーザーサイド同様
- 価格一覧
- 外税額, 内税額どちらも表示
- 価格登録画面
- 入力値に対しての税込額を表示
- 購入時の税込金額は単価でなくもろもろの合計に掛かるので、ここでの税込表記はあくまでも見込み値となる
- 売上確認画面
- 内税, 外税どちらも表示
- 営業確認用
- 内税購入での売上からは外税の見込み値を算出
- 外税購入での売上からは内税の見込み値を算出
3.バッチ実装
リリース当日に流すやつ
- 価格バックアップ作成
- 価格値一括更新
- カート内金額一括更新
ポイント
数ある決済手段
クレジットカード, コンビニ. ATM, 銀行ネットなどいろいろな決済方法を選べる場合が多いと思います。
決済代行会社を使われている場合は、そちらに注文情報(主に支払い方法と支払い金額)を渡せば問題ないですが、
(今回の場合) paidy決済は例外でした。
きちんと仕様を確認すれば問題ないですが、 paidy API reference 2-1-2 Orderオブジェクト
税金額を渡さず合計金額に齟齬が出るとエラーになってしまいます。
税率の保存
DB設計の際、値は消費税8%の8を持たせることにしました。
では、型はintegerか？
次の増税では10%になるのでintegerで問題はないかもしれませんが、
海外では小数点ありの税率があるそうです。
例: インドで12.5%
全国間税会総連合会 世界の消費税(付加価値税)152ヵ国
今後の税率がどうなるかはわかりませんが、小数点を考慮しておいても良いかもしれません。
金額更新
税込額 → 税抜額への変換になりますが、8%なのでほぼ割り切れません。
小数点以下の扱いは社内や取引先との決めの問題になるかと思います。
その結果、切り捨て, 切り上げ, 四捨五入になるかは商品によって異なりました。
なので、価格値一括更新は上記を考慮する必要があります。
※ ここは価格設定の話で、ユーザーが購入する際の端数処理は統一となります。
しかし、カート内金額の一括更新では以下にも注意が必要です。
- 商品がキャンペーン中(割引対象中)ではないか？
本システムの場合、カート内の金額情報には割引が適応された金額が入る仕様でした。
逆算でも問題なかったかもしれませんが、
今回は商品IDから税抜価格に更新した価格テーブルの値を元に、再度キャンペーン価格の計算をしました。
所感
15年近く運用しているサービスだったこともあり、レジフローや売上集計周りのコード,設計がとにかく古かった。
サービスの歴史を感じた。
価格設定から売上集計まで一連の流れを把握する必要があった。
ユーザーサイドから管理画面サイドの仕様も把握する必要があった。
社歴は長い方なので、大抵の仕様は把握してましたが
本件に関してはブラックボックスすぎた。。。
後は、何事もトラブルが起きないことを祈るばかりです。