間違っても変数名(フィールド名)に price なんて名前をつけるんじゃない。
フィールド名は price_tax_excluded と price_tax_included としろ。両方作れ。
tax_excluded_price でもいいし price_without_tax でもいいが、
price なんて名前はつけるな。早死にするぞ。
そして価格の型は Integer にするんじゃない。Float や Double もダメだ。Decimal にしろ。絶対だ。
JS のことは知らんけど多分ライブラリがあるからうまくやれ。そして Json でやりとりする時は文字列で送って Decimal に復号しろ。
会計システムを税別主体でいくか税込主体で行くか決めたら、計算で求めるもう片方は小数点以下も保持して最後まで失わないようにしろ。
小数点以下は、お客さんには見せる必要は無いし、実際に請求する際は整数にするため最後の最後は四捨五入や切り捨てをすることもあるが間違っても各商品(小計)単位で税の端数を切り捨てたりするんじゃない。違法だ。
セブンイレブンで税込100円のものを3買って301円になるのは何も間違っちゃいない。正しい計算だ。笑い飛ばす前に自分を反省しろ。
ただあれは説明が不足していただけだ。お客様に誤解を与えないように徹底的に説明しろ。
あれは税別主体で動作しているレジで、税別で 93円 の商品が、税込だと税率 1.08 で 100円に見える。内部的には 100.44円だ。 3つ買うと 301.32 になって301円の請求になる。世の中のモダンなレジは、このように小数点以下の金額も保持している。端数の .44 円はお客様には見せなくとも絶対に失うな。最後まで保持してDBにもそのまま入れろ。
お客様に 税込 100.44 円 と表示したほうが親切かもしれないがサービスに応じてうまくやれ。最近のコンビニやスーパーでは表示してるのをよく見る。
税率も商品ごとに格納するようにしろ。ついでに、税率とは別に、軽減税率対象かの真偽値も入れておくと、税率が変わった後に過去のデータを精査する時、困らなくていい。情報はなるべく残せ。さらに言うと、通貨フィールドも作っておくと海外展開をする時にいい。
YAGNIポリシーというのは常識だが、DBに関しては一歩先を考えておいたほうがいいこともある。覚えとけ。
お客様や使用者の操作は全部ログに残せ。どのバーコードをスキャンしたか、どのボタンを押したか、逐一残せ。ログがない分お前の睡眠時間が減ると思え。
ページを作る時はわかりやすさを最優先にしろ。ページ数は多くなってもいい。使用者に、今すべきことに集中させろ。コンビニのセルフレジを使い倒して勉強しろ。
ディスカウント系の処理を作る時は、税込み商品金額に対する支払いの代替なのか、税別金額に対する割引処理にするのか、サービスのマネージャーや会社の会計部門と一緒にしっかり設計しろ。
最終的にはおそらく両方が必要になる。
会計に対しての支払い方法は1対多の関係とし、複数登録できるようにしろ。会計の一部を商品券を支払って、残りは現金で、おつりも出す。なんてことはザラにある。気を抜くな。
その場合、会計に軽減税率と通常税率が混じっている場合、商品券の使用はどちらに対して行われるのか、どのような処理になるのが理想か会計部門としっかり相談しろ。
あとは商品券に関して、釣りが出るものと釣りが出ないものがある。釣りが出ないものは、使われなかった金額分を最終的に計上しなければならないため、商品券の額面、種別、本来釣りとして扱わなければいけなかった金額などを細かく記録しろ。
わかったか若造。これからインボイス制度という地獄が待っている。インボイス制度を乗り切って長生きするためにこれは守っとけ。じゃあな。