문서 · 프리랜서 송장 도구
송장 합계를 올바르게 계산: 반올림, 세금 및 부동 소수점
· 작동 방식
송장 자바스크립트 검증
송장과 고객 시스템 간의 1센트 불일치는 일반적으로 잘못된 요율이 아니라 반올림이 발생하는 지점에서 발생합니다. 이 게시물에서는 라인 수준 대 전체 수준 반올림, 컴퓨터가 0.1 + 0.2 오류를 얻는 이유 및 생성기의 산술을 확인하는 방법에 대해 설명합니다.
1센트 차이 — 완벽한 송장을 지연시키는 지급 계정 쿼리
수량, 가격 및 요율이 동일해 보이는 경우에도 두 시스템이 동의하지 않을 정도로 작은 단위 하나의 불일치만으로도 충분합니다. 원인은 계산 순서, 다른 반올림 모드 또는 다른 과세 기준일 수 있습니다. 최종 합계를 수동으로 변경하기보다는 단계별로 방법을 비교하여 문제를 해결하세요.
반올림이 발생하는 경우 — 줄당 세금을 계산하고 합산하는 것과 먼저 합산하고 한 번 과세하는 것과 결과가 다른 이유
선적 모델은 단가 x 수량에서 각 라인 총액을 반올림하고, 라인 할인을 적용 및 반올림하고, 라인 순액을 합산하고, 전체 할인을 적용하고, 해당 할인을 과세 라인 전체에 할당한 다음, 할인된 과세 기준에 대한 세금을 계산합니다. 각 라인에 독립적으로 과세하는 시스템은 다를 수 있습니다.
JavaScript에서 0.1 + 0.2이 0.3가 아닌 이유 — 이진 부동 소수점 및 전체 보조 단위로 계산하는 경우
JavaScript 이진수는 모든 소수점을 정확하게 나타낼 수 없으므로 0.1과 0.2을 직접 비교하면 사람들이 놀라게 됩니다. 돈 모듈은 십진수 텍스트를 전체 작은 단위로 구문 분석하고 총계를 통해 이진 분수를 전달하는 대신 곱셈, 나눗셈 및 백분율에 BigInt 유리수 산술을 사용합니다.
반올림 모드 — 반올림, 반 짝수 및 잘림 및 선택이 문서 전체에서 일관되어야 하는 이유
모듈은 반쪽, 반짝, 위쪽 및 아래쪽 모드를 지원하며 문서 기본값은 반쪽입니다. 라인, 할인 또는 과세 단계에서 동점이 다르게 처리되므로 이후 입력이 변경되므로 일관성이 중요합니다. 테스트는 친근한 예에서 한 방향을 가정하는 대신 긍정적이고 부정적인 관계를 행사합니다.
소수점 이하 0자리 또는 3자리가 있는 통화 — 엔화와 일부 걸프 통화가 센트 단위로 설정된 가정을 깨는 이유
개요에는 소수점 세 자리의 통화가 언급되어 있지만 현재 등록에는 0개의 부 단위 통화와 2개의 부 단위 통화만 포함되어 있습니다. 구현에서는 여전히 센트를 가정하는 대신 통화 메타데이터에서 정밀도를 도출하므로 전체 단위 통화는 인위적인 소수 자릿수를 얻지 않습니다.
실제 사례 — 어색한 세율로 청구된 3개 항목, 양방향으로 계산, 센트 차이 설명
세 가지 어색한 라인 금액에 대해 도구에 표시된 소계, 라인 할인, 송장 할인, 과세 기준, 세금 및 총액을 고객의 단계와 비교하십시오. 단지 마지막 숫자만 비교하지 마십시오. 차이가 나는 첫 번째 단계에서는 분쟁이 구문 분석, 반올림, 할당 또는 과세 기준 선택인지 식별합니다.
여기에 포함되지 않는 내용 — 귀하에게 적용되는 요율 또는 고객의 시스템 반올림 방식 중요하다면 방법에 동의하세요
산술은 어떤 세율이 적용되는지, 라인이 법적으로 과세되는지 여부 또는 다른 회계 시스템이 반올림되는 방법을 결정할 수 없습니다. 이 도구는 세금 확인이 필요하며 문서당 하나의 세율만 구현합니다. 방법에 대한 합의는 계산기 외부의 비즈니스 및 규정 준수 문제로 남아 있습니다.
요점 — 고객이 기대하는 방법과 비교하여 총계를 확인한 다음 프리랜서 송장 도구를 사용하여 깨끗한 PDF을 생성합니다.
가격을 입력된 소수점 텍스트로 유지하고 하나의 반올림 모드를 선택하고 시스템이 일치하지 않는 경우 전체 계산 체인을 비교합니다. Freelance Invoice Tool은 결정적 소단위 산술과 읽기 가능한 PDF를 제공하지만 정의에 따라 클라이언트의 다른 방법을 올바르지 않게 만들지는 않습니다.