檔案·自由發票工具
正確計算發票總額：四捨五入、稅金及浮點
· 工作原理
發票 JavaScript 驗證
您的發票和客戶系統之間一美分的不匹配通常來自四捨五入的地方，而不是錯誤的匯率。這篇文章解釋了行級與總級舍入、為什麼電腦會出現 0.1 + 0.2 錯誤，以及如何檢查任何產生器的算術。
減少一美分 — 應付帳款查詢拖延了原本完美的發票
即使數量、價格和費率看起來相同，一個小單位的不匹配也足以使兩個系統產生分歧。原因可能是計算順序、不同的捨去模式或不同的稅務基礎。透過逐步比較方法來解決它，而不是手動更改最終總數。
發生捨去的地方 - 計算每行稅並求和，與先求和並徵稅一次，以及結果不同的原因
出貨模型根據單價乘以數量對每行毛額進行四捨五入，應用並四捨五入行折扣，對行淨額進行求和，應用總體折扣，跨應稅行分配該折扣，然後根據折扣應稅基數計算稅金。對每條線路獨立徵稅的系統可能有所不同。
為什麼 JavaScript 中的 0.1 + 0.2 不是 0.3 — 二進制浮點數以及以整數小單位計算的情況
JavaScript 二進位數無法準確表示每個小數，這就是為什麼直接 0.1 加上 0.2 的比較會讓人感到驚訝。 Money 模組將十進位文字解析為完整的小單位，並使用 BigInt 有理算術進行乘法、除法和百分比，而不是透過總計攜帶二進位分數。
舍入模式 - 一半向上、一半偶數和截斷，以及為什麼選擇必須在整個檔案中保持一致
模組支援半上、半偶、上、下模式，檔案預設為半上。一致性很重要，因為在行、折扣或稅務階段處理不同的關係會改變以後的輸入。這些測試運用正面和負面的聯繫，而不是從一個友善的例子中假設一個方向。
具有零位或三位小數的貨幣 - 為什麼日圓和一些海灣貨幣打破了美分的假設
大綱提到了三位小數的貨幣，但目前的註冊表僅包含零次要單位貨幣和兩位次要單位貨幣。此實現仍然從貨幣元資料而不是假設美分中獲得精度，因此整個單位貨幣不會獲得人為的小數位。
工作範例 - 三個計費項目的稅率尷尬，雙向計算，並解釋了分差
對於三個尷尬的行金額，將工具顯示的小計、行折扣、發票折扣、應稅基數、稅金和總額與客戶的階段進行比較。不要只是比較最後一個數字：不同的第一階段確定爭議是解析、捨去、分配還是稅基選擇。
這不包括什麼——哪種費率適用於您，或者您客戶的系統如何輪換；如果重要的話同意方法
算術無法決定適用哪一種稅率、某行是否合法應稅或另一個會計系統如何捨去。該工具需要稅務確認，並每個檔案僅實施一種稅率。就方法達成一致仍然是計算器之外的業務和合規問題。
重點 — 根據客戶期望的方法檢查總計，然後讓自由發票工具產生乾淨的 PDF
將價格保留為輸入的十進位文字，選擇一種舍入模式，並在系統不一致時比較完整的計算鏈。自由發票工具提供確定性的小單位算術和可讀的 PDF，但根據定義，它不會使客戶的不同方法變得不正確。