金額は負の数であっても構いません: ビジネスルールと型ルールを分けてください
すべての金額フィールドを `minimum: 0` として書き込みます。これは、表面的には非常に厳密に見えますが、通常の払い戻しレコードがブロックされます。金額が数値に抽出されているかどうかと、このビジネスで負の数値が許可されているかどうかは 2 つの問題です。文書の意味を確認してから範囲ルールを記述します。
・例では種類と記号の検証のみを行っており、通貨換算やアイテム合計の検証は行っておりません。通貨計算には、明確な精度と丸め戦略が必要です。
注文、請求書、または財務書類の構造化された抽出を行っている場合、多くの場合、金額フィールドが最もエラーが発生しやすい場所です。多くの人はすべての金額を minimum: 0 と書きますが、これは非常に厳密に思えますが、これにより通常の返金記録は拒否されます。
金額が数値に抽出されているかどうかと、このビジネスで負の数値が許可されているかどうかは、別の問題です。まずドキュメント内の負号が何を表しているかを確認し、次に範囲ルールを決定して、適切なデータを誤って損傷することなく型が正しいことを確認します。
この記事では、合成サンプルを使用して処理方法を説明します。コードは、隔離された環境でサンプルを使用してチェックされています。これは、すべての実際のファイルや製品のパフォーマンスを保証するものではありません。重要な書類を処理する前に、原本を保管し、本文の境界と許容事項に従って確認してください。
金額がマイナスになることはありますか?一文の結論
金額がマイナスになるかどうかは、フィールドの種類自体ではなく、ビジネスの契約によって決まります。最初に負符号の意味を定義し、次に型によって制約を決定します。
| あなたの状況 | 推奨される実践方法 | 理由 |
|---|---|---|
| 契約上の返金はマイナスの金額で表現されます | 料金フィールドは負でない値に制限されており、払い戻しには負の値が許可されます。 | シンボルはビジネス セマンティクスであり、すべてに適合するものではありません |
| システムは「プラス金額プラス返金型」を採用 | 金額は一律に正であり、タイプフィールドは払い戻しを区別するために使用されます。 | どちらの方法も確立できますが、同じインターフェイスに対して選択できるのは 1 つだけです。 |
| 厳密に正の量が必要です | minimum: 0 の代わりに exclusiveMinimum を使用してください | minimum には境界が含まれており、ゼロ値を渡します |
| ソース内のマイナス記号が欠落しているか、間違って配置されている可能性があります | 元のテキストの断片を保存し、手動で確認します。絶対値を直接取らないでください。 | 自動修正により実際のエラーが隠蔽される可能性がある |
まず、負符号が何を表すかを定義します
この記事の合成契約では、通常の料金はマイナスではなく、払い戻しはマイナスの金額で表現されると規定されています。実際のシステムでは、「正の金額プラス返金タイプ」の会計方法が使用される場合もあります。どちらの方法も確立できますが、同じインターフェイスで読者が推測することに依存することはできません。
ここでのゼロ点境界はサンプル プロトコルであり、金融業界の統一標準ではありません。
型によって制約を決定させます
JSON スキーマの minimum には境界が含まれますが、exclusiveMinimum には境界が含まれません。ビジネス要件が厳密にポジティブである場合、minimum: 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 | 値がゼロを含む | ゼロ価値で許容される金額 | ゼロ値を許容し、厳密に正のシナリオには適していません |
exclusiveMinimum: 0 | ゼロ値は含まれていません | 厳格な要件は正の量に設定されています | 無料のアイテムやリバーサルが誤って拒否されないようにしましょう |
🎯 どの方法があなたに合いますか?
契約書が返金を示すために負の金額を使用している場合
- チャージフィールドに非マイナス制約を設定し、返金フィールドにマイナス値を許可し、文書で合意を明示する。
システムが「プラス金額プラス返金タイプ」を使っている場合
- 金額フィールドは正に統一され、タイプフィールドは数字だけで文書の性質を判断しないようにチェックされます。
ビジネスがその金額を厳密にプラスにすることを要求する場合
exclusiveMinimumを使用し、まずフリープロジェクト、オフセット、推定値が誤って却下されるかどうかを確認します。
ソースファイルの負の符号が欠けている場合
- 元のスニペット、ページ番号、解析前文字列を保持し、データベースに入る前に手動で確認し、絶対値を直接選択しないでください。
❓ よくある質問(FAQ)
1. minimumとexclusiveMinimumの違いは何ですか?
minimumは境界値を持ちますが、exclusiveMinimumは含みません。 ビジネス要件が厳格かつ肯定的であれば、minimum: 0は使用できません。
2. スキーマ検証に合格しているからといって、その金額はいつも正しいのでしょうか?
必ずしもそうとは限りません。 この例は通貨換算を行わず、サブアイテムと合計の関係も検証していません。 通貨計算には明確な精度と四捨五入戦略も求められます。
3. なぜ浮動小数点数を使って直接金額を加算できないのでしょうか?
通貨計算には明確な正確さと丸め方が必要です。数値がスキーマ検証に合格したからといって、浮動小数点数を恣意的に加えることはできません。
4. 異常な陰性の兆候に遭遇した場合、絶対値を直接取ることができますか?
おすすめしません。 OCRの抜け落とし、移動による負の記号、異なるビジネスシンボルは異常を引き起こすことがあります;絶対値を直接取ることで診断の手がかりがなくなります。
📝 概要
量フィールドの鍵は、まず負の符号が何を意味するかを確認し、その後型が制約を決定することです。 ビジネスルールとタイプルールを分けて、誤った返金拒否を防ぎ、実際のミスを見落とさないようにしましょう。


