ドキュメント · フリーランス請求書ツール
請求書の合計を正しく計算する: 四捨五入、税金、浮動小数点
· 仕組み
請求書 JavaScript 検証
請求書とクライアントのシステム間の 1 セントの不一致は、通常、レートの間違いではなく、四捨五入が行われる場所に起因します。この投稿では、行レベルの丸めと合計レベルの丸め、コンピュータが 0.1 + 0.2 を誤る理由、およびジェネレーターの演算をチェックする方法について説明します。
1 セントのオフ — 買掛金クエリにより、完璧な請求書が発行できなくなります
数量、価格、レートが同一に見える場合でも、2 つのシステムが一致しない場合は、1 マイナー単位の不一致で十分です。原因としては、計算順序、異なる丸めモード、または異なる課税ベースが考えられます。最終的な合計を手動で変更するのではなく、方法を段階的に比較することでこの問題を解決します。
四捨五入が発生する場所 — 行ごとの税金を計算して合計する場合と、最初に合計して 1 回課税する場合と、結果が異なる理由
出荷されたモデルは、単価と数量の積から各明細の総額を四捨五入し、明細割引を適用して四捨五入し、明細の純額を合計し、全体の割引を適用して、その割引を課税明細全体に割り当ててから、割引された課税標準に基づいて税金を計算します。各明細に個別に課税するシステムは異なる場合があります。
JavaScript で 0.1 + 0.2 が 0.3 ではない理由 — バイナリ浮動小数点とマイナー単位全体で計算する場合
JavaScript の 2 進数は、すべての小数を正確に表すことができないため、0.1 と 0.2 の直接比較は人々を驚かせます。 Money モジュールは、10 進数のテキストをマイナー単位全体に解析し、乗算、除算、パーセンテージに 2 進の分数を合計に渡す代わりに BigInt 有理算術を使用します。
丸めモード — 半数切り上げ、半偶数、切り捨て、およびドキュメント全体で選択が一貫している必要がある理由
このモジュールは、ハーフアップ、ハーフイーブン、アップおよびダウン モードをサポートしており、ドキュメントのデフォルトはハーフアップです。ライン、割引、税金の段階で異なる方法で処理されるタイは、後の入力を変更するため、一貫性が重要です。テストでは、わかりやすい例から 1 つの方向を仮定するのではなく、肯定的な関係と否定的な関係を検証します。
小数点以下 0 桁または 3 桁の通貨 — 円と一部の湾岸通貨がセントの前提を破る理由
概要では小数点以下 3 桁の通貨について言及していますが、現在のレジストリには小単位ゼロ通貨と小単位 2 通貨のみが含まれています。この実装では、セントを想定するのではなく通貨メタデータから精度を導き出すため、単位全体の通貨には人為的な小数点以下の桁が取得されません。
実用的な例 — 3 つの請求項目を不自然な税率で両方法で計算し、セントの差を説明
3 つの厄介な明細金額について、ツールに表示される小計、明細割引、請求書割引、課税標準、税および合計をクライアントの段階と比較します。単に最後の数値を比較するだけではありません。異なる最初の段階では、紛争が解析、四捨五入、配分、または課税ベースの選択であるかどうかが識別されます。
これでカバーされない内容 — どのレートが適用されるか、またはクライアントのシステムがどのように四捨五入するか。重要な場合は方法に同意する
算術では、どの税率が適用されるか、明細が法的に課税対象であるかどうか、または別の会計システムの四捨五入方法を決定できません。このツールは税金の確認を必要とし、ドキュメントごとに 1 つの税率のみを実装します。方法に関する合意は、依然としてビジネス上およびコンプライアンス上の問題であり、計算の外にあります。
要点 — クライアントが期待する方法と照らし合わせて合計をチェックし、フリーランス請求書ツールできれいな PDF を生成させます。
価格を入力された 10 進数テキストのままにし、丸めモードを 1 つ選択し、システムが一致しない場合は計算チェーン全体を比較します。 Freelance Invoice Tool は、確定的なマイナー単位の演算と読み取り可能な PDF を提供しますが、定義上、クライアントの別の方法が不正になるわけではありません。