17

英国の VAT システムは 17.5% から 15% に変更されます。VAT を格納するためにコードで使用した戦略と、変更がアプリケーションに与える影響。古い価格を計算できるように vats の履歴を保存していますか、それとも古い請求書を別のテーブルに保存していますか? それは単純な構成設定ですか、それとも邪魔しましたか? VAT を保存する理想的な方法は何ですか?

4

9 に答える 9

39

計算しないでください。保管してください！

HMRC は、適切な金額の VAT を支払うことに非常にうるさいです。VAT 計算の四捨五入は、ユーザー ガイドでやや曖昧に指定されており、将来の実装者にそれを正しく行うように任せると、問題が発生する可能性があります。請求書/項目が入力されたときに金額を保存することにより、この問題は回避されます。

これはストレージの無駄遣いや冗長性原則の違反のように思えますが、関連するストレージの量はごくわずかであり、将来的に多くの問題を回避できる可能性があります。もちろん、通貨の金額 (場合によっては、小数部分を含む VAT 率も) を乗算された整数として保存して、2 進数の小数表現の丸め誤差も入り込まないようにする必要があることは言うまでもありません。

中央レート保管

中央レート ストレージを絶対に使用する必要があります。ただし、これは新しい請求書を入力するときに使用される現在のデフォルト レートのみを提供することをお勧めします。これらは、必要に応じて自動切り替えを行うために、開始日と終了日とともに保存できます。これらの税率は、請求書が発行された時点で計算された VAT 金額とともに各請求書 (または請求明細書) に保存され、その時点での状況の絶対的なスナップショットを提供できます。

さまざまな VAT 率 (例: 標準、軽減、ゼロ税率、無 VAT) にも対応することを忘れないでください。通常、VAT の対象となります。

次のようなテーブルになる可能性があります (例):

ID | レート名 | 消費税率 | 開始日 | 終了日
-------------------------------------------------- -  
1 | 標準 | 1750年 | 1991/01/01 | 2008/11/30
2 | 標準 | 1500 | 2008 年 1 月 12 日 | 2009/12/31
等

上記の表は一例です。VAT 率は「ベーシス ポイント」の整数 (1/100 パーセンテージ ポイントなど) として保存されますが、VAT 率が小数点以下 2 桁を超えることはないと想定しています。この問題を軽減するために追加の列を使用してこれを拡張することはもちろん可能ですが、それは少しやり過ぎに思えるかもしれません。

于 2008-11-25T10:43:23.687 に答える
16

保管しないでください。それを計算してください！

パーセンテージベースのレート/利息を保存する私の推奨方法は次のとおりです。

次のようなテーブル「VAT_param」が必要です

金利 | 発効日 (日付) | 有効期限(日付)

私は信じている、

「計算できるものは 保存するべきではない」

特に、他のパーセンテージ (税金、利子など) に基づいて値を計算する必要がある場合は、時間と空間のトレードオフに惑わされないようにしてください。宇宙で時間を過ごすことで、後で自分を祝福するでしょう。

次に、請求書の日付に基づいて、期間中の有効率に基づいて VAT を適切に計算する必要があります。そうなる

  • 冗長性を最小限に抑えてください（古いテーブルや新しいテーブルについては決して話さないでください..数年にわたって、金利が年に1回変更されると、髪を引っ張り始めるでしょう）

  • レートを制御するための集中型の単一ピボットを用意します。VAT_param テーブル。

于 2008-11-25T09:12:40.077 に答える
4

私の考え ...

a-私は通常、ストアよりも計算を好みますが、この場合、計算されたVAT（および計算に使用されるレートとコード）は、トランザクションごとに保存する必要があります。これは、繰り返し生成する必要のあるドキュメントのソースデータになるためです。また、販売からのVAT額を財務元帳のVAT額と一致させることができるようにする必要があります。請求書やVATレポートなどのドキュメントを毎回同じように再生成できない可能性を危険にさらしたくありません。

b- VAT（またはその他の税金）の値は、発効日と税率とともに、絶対にテーブルに保存する必要があります。ハードコーディングされている場合は、近い将来再び変更される可能性があるため、今すぐソフトコーディングする作業を行ってください。

c-消費税は州、郡、さらには都市によっても異なるため、これは米国では大規模な（そして解決された）取引です。私はロサンゼルス郡に住んで働いており、消費税率は8.25％です。オレンジカウンティの南10マイルの消費税率は7.75％です。インターネットとカタログの小売業者は、配達場所によって決定されるため、正しいレートを知っている必要があります。

幸運を。

于 2008-11-25T23:53:59.817 に答える
3

VAT は、すべての社内アプリで共有されているデータベース テーブルから取得します。つまり、新しいコードに関しては、大した問題ではありません。このように一元化を維持することは、賢明な動きでなければなりません。

于 2008-11-25T09:04:53.057 に答える
1

私が継承した 2 つのシステムでは、レートがどこかにハードコードされているように感じます。

さらに悪いことに、ハードコードされている場合、適切に変更する時間がないため、ハードコードされた値を単に置き換えるだけです。

さらに悪いことに、実際に変更を行うための時間がどこにあるのかわかりません。なので月曜日の着替えには間に合わないと思います。もちろん、私たちの £10 サブスクリプションは、17.5% の VAT (£8.515 など) を含む £10 に基づいているなど、もっと興味深い問題があります。今では £9.79 かそこらになり、£10 で宣伝しているすべてのものと、£10 に基づくすべてのサイトの計算が完全に混乱しています。

これはすべて、貯金箱を担当する馬鹿が見出しを欲しがっていたからです。

于 2008-11-25T09:48:01.817 に答える
0

レートが元に戻ったときにこれを行うための作業を行っているところです。

どちらの方法でも、VAT 期間は連続して実行されるため、VAT テーブルに開始日と終了日を記録する必要はありません。

以下のようなクエリを実行することで、正しい vat にアクセスできます。vat_date は VAT 率の開始日です。

SELECT * FROM vat WHERE NOW() > vat_date ORDER BY vat_date DESC LIMIT 1
于 2009-12-18T12:11:56.260 に答える
0

VAT 率はデータベース テーブルに保存されているため、大した問題ではありませんが、手を挙げて、コードに加えた変更の性質上、VAT はハードコーディングされていると言わざるを得ません。いくつかの場所で（私の悪い！） 私は別のよりエキサイティングな方法で再ファッジすることができました！

于 2008-11-25T10:57:01.693 に答える
0

store 対 calc 引数に関して。保存しておけば、いつでも後で計算できます-気が変わった場合;)

于 2009-12-18T12:15:48.047 に答える
-1

昨夜、アプリケーションの重要な構成設定を格納するテーブルをコードで見つけました。

Table tbl_config
   config_id int
   config_name varchar(255)
   config_value varchar(255)

これらの設定の 1 つは、サーバーのメインの管理者ユーザー名とパスワードの組み合わせ (ハッシュ化されていない) でした。それを作成した開発者は、忘れた場合に備えて常にアクセスしたいと思っていたと思います! 言うまでもなく、今は消えています。

于 2008-11-25T09:06:11.980 に答える