OmniDoc금액이 음수일 수 있나요? 비즈니스 규칙과 유형 규칙을 구분하세요.
모든 금액 필드를 `minimum: 0`으로 작성합니다. 이는 표면적으로 매우 엄격해 보이지만 일반적인 환불 기록을 차단합니다. 금액을 숫자로 추출했는지 여부와 이 사업에서 음수가 허용되는지 여부는 두 가지 문제입니다. 먼저 문서의 의미를 확인한 후 범위 규칙을 작성해야 합니다.
주문, 청구서 또는 재무 문서를 체계적으로 추출하는 경우 금액 필드가 오류가 가장 발생하기 쉬운 곳인 경우가 많습니다. 많은 사람들이 모든 금액을 minimum: 0로 기재하는데 이는 매우 엄격해 보이지만 이로 인해 일반적인 환불 기록이 거부됩니다.
금액을 숫자로 추출했는지 여부와 이 사업에서 음수가 허용되는지 여부는 서로 다른 문제입니다. 먼저 문서의 음수 기호가 무엇을 나타내는지 확인한 다음 범위 규칙을 결정하여 실수로 합리적인 데이터를 손상시키지 않고 유형이 올바른지 확인하십시오.
이 기사에서는 합성 샘플을 사용하여 처리 방법을 보여줍니다. 코드는 격리된 환경에서 예제를 통해 확인되었습니다. 이는 모든 실제 파일이나 제품 성능을 보장하지는 않습니다. 중요한 서류를 처리하기 전, 원본을 보관하시고, 본문에 기재된 경계 및 허용 항목에 따라 검토하시기 바랍니다.
금액이 마이너스가 될 수도 있나요? 한 문장 결론
금액이 음수일 수 있는지 여부는 필드 유형 자체가 아니라 비즈니스의 합의에 따라 다릅니다. 먼저 음수 기호의 의미를 정의한 다음 유형에 따라 제약 조건이 결정되도록 합니다.
| 당신의 상황 | 권장 사례 | 이유 |
|---|---|---|
| 계약상 환불 금액은 마이너스 금액으로 표시됩니다. | Charge 필드는 음수가 아닌 값으로 제한되며, 환불 시 음수 값이 허용됩니다. | 기호는 비즈니스 의미론이므로 모든 것에 적합할 수는 없습니다. |
| 시스템은 "양수 금액 + 환불 유형"을 사용합니다. | 금액은 균일하게 양수이며 유형 필드는 환불을 구별하는 데 사용됩니다. | 두 가지 방법을 모두 설정할 수 있지만 동일한 인터페이스에 대해서는 하나만 선택할 수 있습니다. |
| 반드시 양수 금액이 필요합니다. | minimum: 0 대신 exclusiveMinimum를 사용하세요. | minimum에는 경계가 포함되어 있으며 0 값을 전달합니다. |
| 소스의 음수 기호가 누락되었거나 위치가 잘못되었을 수 있습니다. | 원본 텍스트 조각을 저장하고 수동으로 검토하세요. 절대값을 직접 취하지 마세요. | 자동 수정으로 실제 오류를 가릴 수 있음 |
먼저 음수 기호가 무엇을 나타내는지 정의하세요.
본 글의 종합합의서에는 일반요금은 마이너스 금액이 아니며, 환불금액은 마이너스 금액으로 표시된다고 규정하고 있습니다. 실제 시스템에서는 "양수 금액 + 환불 유형" 회계 방법을 사용할 수도 있습니다. 두 방법 모두 설정할 수 있지만 독자가 동일한 인터페이스에서 추측할 수는 없습니다.
여기서 영점 경계는 샘플 프로토콜이며 금융 업계의 통일된 표준은 아닙니다.
유형에 따라 제약 조건이 결정됩니다.
JSON 스키마의 minimum에는 경계가 포함되어 있지만 exclusiveMinimum에는 경계가 포함되어 있지 않습니다. 비즈니스 요구사항이 엄격하게 긍정적인 경우 minimum: 0를 사용할 수 없습니다.
무료 항목, 상각 또는 견적을 오류로 잘못 해석하지 않도록 키워드를 선택하기 전에 먼저 0 값을 허용하는 시나리오를 나열하십시오.
from jsonschema import Draft202012Validator
schema = {
"type": "object", "required": ["kind", "amount"],
"additionalProperties": False,
"properties": {"kind": {"enum": ["charge", "refund"]},
"amount": {"type": "number"}},
"allOf": [
{"if": {"properties": {"kind": {"const": "charge"}}},
"then": {"properties": {"amount": {"minimum": 0}}}},
{"if": {"properties": {"kind": {"const": "refund"}}},
"then": {"properties": {"amount": {"exclusiveMaximum": 0}}}}
]
}
v = Draft202012Validator(schema)
valid = lambda x: not list(v.iter_errors(x))
assert valid({"kind": "charge", "amount": 0})
assert valid({"kind": "refund", "amount": -12.5})
assert not valid({"kind": "refund", "amount": 12.5})
assert not valid({"kind": "charge", "amount": True})
assert not valid({"amount": 12.5})이 예는 jsonschema에 따라 다르며 Draft 2020-12에 따라 검증되었습니다. 통화 변환을 수행하지 않으며 항목과 합계 간의 관계를 확인하지도 않습니다.
통화 계산에는 명확한 정밀도와 반올림 전략이 필요합니다. 값이 스키마 검증을 통과했다고 해서 부동 소수점 숫자를 사용하여 마음대로 누적할 수는 없습니다.
오류 보고 시 비즈니스 맥락을 명시해야 합니다.
검증에 실패했을 때, 오류 메시지는 단순히 '무효'라고 표시하는 것이 아니라 원인을 파악하는 데 도움이 되어야 합니다.
| 관찰 | 이렇게 처리되었습니다 | 아직 확인이 필요합니다 |
|---|---|---|
| 환불은 긍정적입니다 | 거부 | 심볼이 사라진 건가요, 아니면 소스가 다른 프로토콜을 사용하고 있나요? |
| 전하 제로 | 구조 수용 | 무료 프로그램인지 여부 |
| 금액은 문자열입니다 | 거부 유형 | 수천 개의 자리, 화폐, 그리고 십진법 규칙 |
| 유형 누락 | 거부 | 문서 종류를 금액 기호로 추측하지 마세요 |
자동 가져오기 절대값으로 실수를 덮지 마세요
OCR은 짧은 수평선이 빠졌거나, 번역 중 마이너스 기호가 이동하거나, 기업이 반대되는 상징적 관습을 사용할 경우 동일한 유형의 예외를 표시할 수 있습니다.
abs()를 직접 호출하면 중요한 진단 단서가 사라집니다. 더 안전한 방법은 원본 텍스트 클립, 페이지 번호, 사전 해석 문자열을 저장한 후 재추출할지 수동으로 검토할지 결정하는 것입니다.
배달 시 금액과 타이핑을 함께 확인해
OmniDoc (제품 입력)를 사용해 금액이 포함된 문서를 처리할 때, 이 규칙표를 후처리 승인의 일부로 사용할 수 있습니다: 숫자가 누락되었는지뿐만 아니라 환불, 크레딧 및 기타 사안의 맥락이 변경되었는지도 확인할 수 있습니다.
도구는 번역 완료에 도움을 줄 수 있지만, 금액 합의는 비즈니스 측에서 명확히 해야 합니다.
📊 핵심 비교
| 방법 | 마이너스 기호의 의미 | 장면에 적합하다 | 주목할 점 |
|---|---|---|---|
| 환불은 음수 금액으로 이루어집니다 | 부정적인 표시는 환불을 의미합니다 | 이 합의는 방향을 기호로 구분해야 한다고 명시하고 있습니다 | 청구 필드는 음수가 아닌 것으로 제한되어야 하며, 환불 필드는 음수일 수 있습니다 |
| 양성 금액과 환불 유형 | 부정적인 기호는 비즈니스의 의미를 담고 있지 않습니다 | 시스템은 환급금을 유형 필드별로 구분합니다 | 양은 균일하게 양수이며, 유형도 동시에 확인해야 합니다 |
minimum: 0 | 0 값을 포함함 | 0 값으로 허용되는 금액 | 0 값을 허용하며 엄격히 양의 상황에는 적합하지 않습니다 |
exclusiveMinimum: 0 | 0 값은 포함되지 않습니다 | 엄격한 요구사항은 양수로 설정됩니다 | 무료 아이템이나 취소가 실수로 거부되지 않도록 하세요 |
🎯 어떤 방법이 당신에게 맞나요?
만약 합의서에 환급을 의미하는 음수 금액이 사용된다면
- 청구 필드에 대해 음수가 아닌 제약 조건을 설정하고, 환불 필드에 음수 값을 허용하며, 문서에서 합의를 명시합니다.
만약 시스템이 "양의 금액과 환불 유형"을 사용한다면,
- 금액 필드는 양수로 통합되며, 유형 필드는 문서 성격을 숫자만으로 판단하지 않도록 검사됩니다.
사업이 그 금액이 엄격히 긍정적이어야 한다면
exclusiveMinimum를 사용하여 먼저 무료 프로젝트, 오프셋, 추정치가 실수로 거부되는지 확인하세요.
소스 파일의 음정 부호가 누락될 수 있다면요
- 원본 스니펫, 페이지 번호, 사전 구문 입력 문자열을 유지하고, 데이터베이스에 입력하기 전에 수동으로 검토하며, 절대값을 직접 선택하지 마십시오.
❓ 자주 묻는 질문 (FAQ)
1. minimum와 exclusiveMinimum의 차이점은 무엇인가요?
minimum는 경계 값을 포함하지만, exclusiveMinimum는 그렇지 않습니다. 비즈니스 요구사항이 엄격하고 긍정적일 경우 minimum: 0는 사용할 수 없습니다.
2. 스키마 검증을 통과한다고 해서 항상 금액이 정확한가요?
꼭 그런 건 아니에요. 예시는 통화 변환을 수행하지 않으며, 하위 항목과 총 간의 관계를 검증하지도 않습니다; 통화 계산에는 명확한 정확성과 반올림 전략도 필요합니다.
3. 왜 부동소수점 숫자를 사용해 금액을 직접 추가할 수 없는 걸까요?
통화 계산은 명확한 정확성과 반올림 전략이 필요하며; 값이 스키마 검증을 통과한다고 해서 임의로 부동소수점 수를 추가할 수는 없습니다.
4. 비정상적인 음정 신호를 만났을 때 절대값을 직접 측정할 수 있나요?
추천하지 않습니다. OCR 누락, 음수 기호 이동, 또는 다른 비즈니스 기호 사용은 이상 현상을 일으킬 수 있습니다; 절대값을 직접 취하면 진단 단서를 제거합니다.
📝 요약
양 필드의 핵심은 먼저 음의 부호가 무엇을 의미하는지 확인한 후, 타입이 제약 조건을 결정하도록 하는 것입니다. 비즈니스 규칙과 유형 규칙을 분리하여 환불 거부를 방지하고 실제 실수를 간과하지 않도록 하세요.
참고: JSON 스키마 수치 제약조건
