OmniDocЧи може сума бути від’ємним числом: окремі бізнес-правила та правила типу
Напишіть усі поля суми як `minimum: 0`, що на перший погляд виглядає дуже суворим, але блокує звичайний запис відшкодування. Чи була сума виділена в число і чи дозволені від’ємні числа в цьому бізнесі – дві проблеми. Ви повинні спочатку підтвердити значення документа, а потім написати правила сфери дії.
Ключові моменти цієї статті
– Чи витягується сума як число і чи дозволяє бізнес від’ємні числа – це дві різні проблеми. Ви повинні спочатку підтвердити значення документа, перш ніж писати правила діапазону.
- Зразок договору передбачає, що нарахування є невід'ємними, а повернення коштів - від'ємними; якщо система використовує позитивну суму плюс тип відшкодування, це має бути чітко погоджено в тому ж інтерфейсі.
- мінімум включає межу, ексклюзивний мінімум — ні; мінімум: 0 не можна використовувати для суворо додатних сум.
- Під час повідомлення про помилку оригінальний фрагмент тексту, номер сторінки та рядок перед синтаксичним аналізом слід зберегти, а abs() не слід використовувати безпосередньо для приховування підказок щодо відсутніх символів.
- У цьому прикладі перевіряються лише тип і символ і не виконується конвертація валюти чи перевірка загальної кількості елементів. Валютні розрахунки вимагають чіткої точності та стратегії округлення.
Якщо ви виконуєте структуроване вилучення замовлень, рахунків або фінансових документів, поле суми часто є найбільш схильним до помилок місцем. Багато людей пишуть усі суми як minimum: 0, що здається дуже суворим, але через це звичайні записи про відшкодування будуть відхилені.
Чи була сума виділена в число і чи дозволені від’ємні числа в цьому бізнесі – дві різні проблеми. Спочатку перевірте, що означає негативний знак у документі, а потім визначте правила діапазону, щоб переконатися, що тип є правильним без випадкового пошкодження прийнятних даних.
У цій статті використовуються синтетичні зразки для демонстрації методу обробки. Код було перевірено з прикладами в ізольованому середовищі; це не є гарантією всіх справжніх файлів або продуктивності продукту. Перед обробкою важливих документів збережіть оригінали та перегляньте їх відповідно до меж і пунктів прийняття в тексті.
Чи може сума бути від'ємною? Висновок одним реченням
Чи може сума бути від’ємною, залежить від угоди компанії, а не від самого типу поля. Спочатку визначте значення негативного знака, а потім дозвольте типу визначити обмеження.
| ваша ситуація | Рекомендовані практики | причина |
|---|---|---|
| Відшкодування в угоді виражені як від’ємні суми | Поле заряду обмежено невід’ємними значеннями, а від’ємні значення дозволені для відшкодування. | Символи є бізнес-семантикою і не можуть бути універсальними |
| Система використовує «позитивна сума плюс тип повернення» | Сума рівномірно позитивна, а поле типу використовується для розрізнення відшкодувань | Можна встановити обидва методи, але для одного інтерфейсу можна вибрати лише один. |
| Потрібна суто позитивна сума | Використовуйте exclusiveMinimum замість minimum: 0 | minimum містить межі та пропускатиме нульові значення |
| Негативні знаки в джерелах можуть бути відсутні або неправильно розміщені | Збережіть вихідний фрагмент тексту та перегляньте його вручну. Не приймайте безпосередньо абсолютне значення. | Автокорекція може маскувати справжні помилки |
Спочатку визначте, що означає мінус
Об’єднана угода в цій статті передбачає, що звичайні витрати є невід’ємними, а відшкодування виражаються як від’ємні суми. Реальні системи також можуть використовувати метод обліку «додатна сума плюс тип відшкодування». Обидва методи можна встановити, але ви не можете покладатися на те, що зчитувачі вгадають в одному інтерфейсі.
Межа нульової точки тут є зразком протоколу і не є єдиним стандартом у фінансовій галузі.
Нехай тип визначає обмеження
minimum схеми JSON містить межі, 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 і перевіряється відповідно до проекту 2020-12. Він не виконує конвертацію валют і не перевіряє зв’язок між елементами та підсумками.
Валютні розрахунки вимагають чіткої точності та стратегії округлення. Просто тому, що значення проходять перевірку схеми, ви не можете використовувати числа з плаваючою комою для накопичення за бажанням.
Повідомляючи про помилку, потрібно вказати бізнес-контекст
Якщо перевірка не вдається, повідомлення про помилку має допомогти людям визначити причину, а не просто вказувати «незаконно».
| спостерігати | Обробка тут | Ще треба перевірити |
|---|---|---|
| Повернення позитивне | відхилити | Символ відсутній чи джерело використовує інший протокол? |
| Заряд нульовий | прийняти структуру | Це безкоштовний проект? |
| Сума є рядком | тип відхилення | Знак тисячі, правила валюти та десяткового числа |
| Відсутній тип | відхилити | Вгадайте тип документа, не покладаючись на знак суми |
Не використовуйте автоматичні абсолютні значення, щоб приховати помилки
Відсутність тире в оптичному розпізнаванні символів, переміщення негативних знаків під час перекладу або бізнес, що використовує протилежні знаки, можуть проявлятися як одна аномалія.
Безпосередній виклик abs() усунув би важливі діагностичні підказки. Більш безпечний підхід — зберегти оригінальні фрагменти тексту, номери сторінок і рядки перед синтаксичним аналізом, а потім прийняти рішення про повторне вилучення або перегляд вручну.
Перевірте суму та введіть разом під час доставки
Використовуючи OmniDoc (портал продуктів) для обробки документів, що містять суми, ви можете використовувати цю таблицю правил як частину прийняття після перекладу: не лише перевірте, чи не втрачено числа, але й чи змінився контекст відшкодувань, кредитів тощо.
Інструменти можуть допомогти завершити переклад, але угода про суму має бути зрозумілою для бізнесу.
📊 Основне порівняння
| практика | Значення негативного знака | Підходить для сцени | Примітка |
|---|---|---|---|
| Повернення з від’ємною сумою | Знак «мінус» означає повернення коштів | Угода погодилася використовувати символи для розрізнення напрямків | Поле нарахування повинно бути обмежено невід’ємними значеннями, а поле відшкодування дозволяє вводити від’ємні значення. |
| Позитивна сума плюс тип відшкодування | Знак мінус не несе ділового значення | Система розрізняє відшкодування за типом поля | Сума рівномірно додатна, і тип повинен бути перевірений одночасно. |
minimum: 0 | Містить нульове значення | Суми, що допускають нульові значення | Буде випускати нульові значення, не підходить для строго позитивних сценаріїв |
exclusiveMinimum: 0 | Не містить нульового значення | Обов’язково має бути додатною сумою | Необхідно підтвердити, що безкоштовні товари або скасування не будуть помилково відхилені |
🎯 Який спосіб вам підходить?
Якщо у вашій угоді використовується від’ємна сума для позначення відшкодування
- Встановіть невід’ємні обмеження для поля нарахування, дозвольте від’ємні значення для поля відшкодування та запишіть угоду в документі.
Якщо ваша система використовує "позитивна сума плюс тип відшкодування"
- Поле суми має бути рівномірно додатним, а поле типу має бути перевірено одночасно, щоб не судити про природу документа, просто дивлячись на числа.
Якщо сума бізнес-вимоги суто позитивна
- Використовуйте
exclusiveMinimumі спочатку перевірте, чи не будуть помилково відхилені безкоштовні товари, знижки та оцінки.
Якщо негативний знак вихідного файлу може бути втрачений
- Зберігайте оригінальні фрагменти тексту, номери сторінок і попередньо проаналізовані рядки та переглядайте їх вручну перед введенням у базу даних. Не приймайте безпосередньо абсолютне значення.
❓ Часті запитання (FAQ)
1. Яка різниця між minimum і exclusiveMinimum?
minimum містить граничні значення, exclusiveMinimum не містить граничних значень. Якщо бізнес-вимога суто позитивна, minimum: 0 не можна використовувати.
2. Якщо він пройде перевірку схеми, чи буде сума правильною?
невизначений. У цьому прикладі не виконується конвертація валют і не перевіряється зв’язок між елементами та підсумками; валютні розрахунки також вимагають чіткої точності та стратегії округлення.
3. Чому суму не можна накопичувати безпосередньо за допомогою чисел з плаваючою комою?
Валютні розрахунки вимагають чіткої точності та стратегії округлення. Числа з плаваючою комою не можна використовувати для випадкового накопичення лише тому, що значення проходять перевірку схеми.
4. Коли ви зустрічаєте виняток з негативним знаком, чи можете ви безпосередньо взяти абсолютне значення?
Не рекомендується. Пропущені слова в OCR, переміщення негативних знаків у перекладі або різні умовні позначення бізнес-символів можуть спричинити відхилення. Безпосереднє визначення абсолютного значення усуне діагностичні ознаки.
📝 Підсумок
Ключ до поля суми полягає в тому, щоб спочатку підтвердити, що означає від’ємний знак, а потім дозволити типу визначити обмеження. Розділивши бізнес-правила та правила типів, ви не зможете ні помилково відхилити відшкодування, ні пропустити справжні помилки.
Спробуйте зараз: завантажте документ, щоб розпочати переклад, зберігаючи вихідний макет
Джерела: Числові обмеження схеми JSON
