Số tiền có thể là số âm: quy tắc kinh doanh và quy tắc loại riêng biệt

Những điểm chính của bài viết này

Số tiền có được trích ra dưới dạng số hay không và doanh nghiệp có cho phép số âm hay không là hai vấn đề khác nhau. Trước tiên bạn nên xác nhận ý nghĩa của tài liệu trước khi viết quy tắc phạm vi.
Thỏa thuận mẫu quy định phí không âm và số tiền hoàn lại là số âm; nếu hệ thống sử dụng số tiền dương cộng với hình thức hoàn tiền thì phải được thỏa thuận rõ ràng trên cùng một giao diện.
tối thiểu bao gồm ranh giới, độc quyềnTối thiểu thì không; tối thiểu: 0 không thể được sử dụng cho số tiền dương hoàn toàn.
Khi báo lỗi, đoạn văn bản gốc, số trang và chuỗi trước khi phân tích cú pháp phải được lưu lại và không nên sử dụng trực tiếp abs() để che đậy manh mối về các ký hiệu bị thiếu.
Ví dụ chỉ xác minh loại và ký hiệu chứ không thực hiện chuyển đổi tiền tệ hoặc xác minh tổng số mặt hàng. Việc tính toán tiền tệ đòi hỏi phải có chiến lược làm tròn và độ chính xác rõ ràng.

Nếu bạn đang thực hiện trích xuất có cấu trúc các đơn đặt hàng, hóa đơn hoặc tài liệu tài chính thì trường số tiền thường là nơi dễ xảy ra lỗi nhất. Nhiều người sẽ viết tất cả số tiền là minimum: 0, điều này có vẻ rất nghiêm ngặt, nhưng hồ sơ hoàn tiền thông thường sẽ bị từ chối vì điều này.

Số tiền đã được trích ra thành số hay chưa và liệu số âm có được phép trong hoạt động kinh doanh này hay không là hai vấn đề khác nhau. Trước tiên, hãy xác nhận dấu âm trong tài liệu thể hiện điều gì, sau đó xác định các quy tắc phạm vi để đảm bảo rằng loại đó là chính xác mà không vô tình làm hỏng dữ liệu hợp lý.

Bài viết này sử dụng các mẫu tổng hợp để trình bày phương pháp xử lý. Mã đã được kiểm tra bằng các ví dụ trong môi trường biệt lập; điều này không thể hiện sự đảm bảo về tất cả các tệp thực hoặc hiệu suất của sản phẩm. Trước khi xử lý các văn bản quan trọng, vui lòng giữ lại bản chính và xem xét theo ranh giới và các mục chấp nhận trong văn bản.

Số tiền có thể âm không? Một câu kết luận

Số tiền có thể âm hay không phụ thuộc vào thỏa thuận của doanh nghiệp chứ không phải bản thân loại trường. Trước tiên, hãy xác định ý nghĩa của dấu âm, sau đó để loại xác định các ràng buộc.

hoàn cảnh của bạn	Các phương pháp được đề xuất	lý do
Số tiền hoàn lại trong thỏa thuận được thể hiện dưới dạng số tiền âm	Trường phí được giới hạn ở các giá trị không âm và giá trị âm được phép hoàn lại.	Biểu tượng là ngữ nghĩa kinh doanh và không thể có một kích thước phù hợp cho tất cả
Hệ thống sử dụng "số tiền dương cộng với loại hoàn tiền"	Số tiền đều dương và trường loại được sử dụng để phân biệt số tiền hoàn lại	Cả hai phương pháp đều có thể được thiết lập nhưng chỉ có thể chọn một phương pháp cho cùng một giao diện.
Cần phải có một số tiền dương hoàn toàn	Sử dụng `exclusiveMinimum` thay vì `minimum: 0`	`minimum` chứa các ranh giới và sẽ vượt qua các giá trị 0
Dấu hiệu tiêu cực trong nguồn có thể bị thiếu hoặc đặt sai vị trí	Lưu đoạn văn bản gốc và xem lại nó theo cách thủ công. Không trực tiếp lấy giá trị tuyệt đối.	Tự động sửa lỗi có thể che giấu các lỗi thực sự

Đầu tiên hãy xác định dấu âm đại diện cho điều gì

Thỏa thuận tổng hợp trong bài viết này quy định rằng các khoản phí thông thường là không âm và số tiền hoàn lại được thể hiện dưới dạng số tiền âm. Các hệ thống thực cũng có thể sử dụng phương pháp kế toán "số tiền dương cộng với loại hoàn tiền". Cả hai phương pháp đều có thể được thiết lập nhưng bạn không thể dựa vào việc người đọc đoán trong cùng một giao diện.

Ranh giới điểm 0 ở đây là một giao thức mẫu và không phải là một tiêu chuẩn thống nhất trong ngành tài chính.

Để kiểu xác định các ràng buộc

minimum của Lược đồ JSON chứa các ranh giới, exclusiveMinimum không chứa các ranh giới. Nếu yêu cầu kinh doanh hoàn toàn tích cực thì không thể sử dụng minimum: 0.

Liệt kê các trường hợp cho phép giá trị 0 trước khi chọn từ khóa để tránh hiểu sai các mục miễn phí, xóa sổ hoặc ước tính là lỗi.

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})

Ví dụ phụ thuộc vào jsonschema và được xác minh theo Dự thảo 2020-12. Nó không thực hiện chuyển đổi tiền tệ cũng như không xác minh mối quan hệ giữa các mục và tổng số.

Việc tính toán tiền tệ đòi hỏi phải có chiến lược làm tròn và độ chính xác rõ ràng. Chỉ vì các giá trị vượt qua xác minh Schema nên bạn không thể sử dụng số dấu phẩy động để tích lũy theo ý muốn.

Khi báo lỗi cần nêu rõ bối cảnh nghiệp vụ

Khi xác minh không thành công, thông báo lỗi sẽ giúp mọi người xác định nguyên nhân thay vì chỉ cho biết "bất hợp pháp".

quan sát	Quá trình xử lý ở đây	Vẫn cần kiểm tra
Hoàn tiền là tích cực	từ chối	Biểu tượng có bị thiếu hoặc nguồn sử dụng giao thức khác không?
Phí bằng không	chấp nhận cấu trúc	Đây có phải là một dự án miễn phí?
Số tiền là một chuỗi	kiểu từ chối	Quy tắc hàng nghìn vị trí, tiền tệ và số thập phân
Thiếu loại	từ chối	Đoán loại tài liệu mà không cần dựa vào ký hiệu số tiền

Không sử dụng giá trị tuyệt đối tự động để che đậy lỗi

OCR thiếu dấu gạch ngang, di chuyển các dấu âm trong quá trình dịch hoặc doanh nghiệp sử dụng quy ước ký hiệu ngược lại đều có thể biểu hiện dưới dạng bất thường giống nhau.

Gọi trực tiếp cho abs() sẽ loại bỏ các manh mối chẩn đoán quan trọng. Một cách tiếp cận an toàn hơn là lưu các đoạn văn bản gốc, số trang và chuỗi trước khi phân tích cú pháp, sau đó quyết định xem nên trích xuất lại hay xem lại theo cách thủ công.

Kiểm tra số lượng và chủng loại khi giao hàng

Khi sử dụng OmniDoc (cổng thông tin sản phẩm) để xử lý tài liệu có chứa số tiền, bạn có thể sử dụng bảng quy tắc này như một phần của quá trình chấp nhận sau dịch: không chỉ kiểm tra xem các số có bị mất hay không mà còn kiểm tra xem bối cảnh hoàn tiền, tín dụng, v.v. có thay đổi hay không.

Các công cụ có thể giúp hoàn thiện bản dịch nhưng thỏa thuận về số lượng vẫn phải được phía doanh nghiệp rõ ràng.

📊 So sánh cốt lõi

luyện tập	Ý nghĩa dấu âm	Phù hợp với cảnh	Ghi chú
Hoàn tiền với số tiền âm	Dấu âm cho biết khoản tiền hoàn lại	Hiệp định đã thống nhất sử dụng ký hiệu để phân biệt các hướng	Trường phí phải được giới hạn ở các giá trị không âm và trường hoàn tiền cho phép các giá trị âm.
Số tiền dương cộng với loại tiền hoàn lại	Dấu âm không mang ý nghĩa kinh doanh	Hệ thống phân biệt hoàn tiền theo trường loại	Số tiền là dương đồng đều và loại phải được xác minh cùng một lúc.
`minimum: 0`	Chứa giá trị 0	Số tiền cho phép giá trị bằng 0	Sẽ giải phóng các giá trị bằng 0, không phù hợp với các tình huống hoàn toàn tích cực
`exclusiveMinimum: 0`	Không chứa giá trị 0	Bắt buộc phải là số tiền dương	Cần xác nhận rằng các mặt hàng miễn phí hoặc đảo ngược sẽ không bị từ chối nhầm

🎯 Phương pháp nào phù hợp với bạn?

Nếu thỏa thuận của bạn sử dụng số tiền âm để biểu thị khoản tiền hoàn lại

Đặt ràng buộc không âm cho trường phí, cho phép giá trị âm cho trường hoàn tiền và ghi thỏa thuận vào tài liệu.

Nếu hệ thống của bạn sử dụng "số tiền dương cộng với loại hoàn tiền"

Trường số lượng phải dương đồng đều và trường loại phải được xác minh đồng thời để tránh đánh giá bản chất của tài liệu chỉ bằng cách nhìn vào các con số.

Nếu số lượng yêu cầu kinh doanh hoàn toàn dương

Sử dụng exclusiveMinimum và kiểm tra trước để xem liệu các mặt hàng miễn phí, giảm giá và ước tính có bị từ chối nhầm hay không.

Nếu dấu âm của file nguồn có thể bị mất

Giữ nguyên các đoạn văn bản gốc, số trang, chuỗi đã phân tích trước và xem lại thủ công trước khi nhập vào cơ sở dữ liệu. Không trực tiếp lấy giá trị tuyệt đối.

❓ Câu hỏi thường gặp (FAQ)

1. Sự khác biệt giữa `minimum` và `exclusiveMinimum` là gì?

minimum chứa các giá trị biên, exclusiveMinimum không chứa các giá trị biên. Nếu yêu cầu kinh doanh hoàn toàn tích cực thì không thể sử dụng minimum: 0.

2. Nếu nó vượt qua xác minh Schema, số tiền có chính xác không?

không chắc chắn. Ví dụ này không thực hiện chuyển đổi tiền tệ cũng như không xác minh mối quan hệ giữa các mục và tổng số; tính toán tiền tệ cũng đòi hỏi chiến lược làm tròn và độ chính xác rõ ràng.

3. Tại sao số tiền không thể được tích lũy trực tiếp bằng số dấu phẩy động?

Việc tính toán tiền tệ đòi hỏi phải có chiến lược làm tròn và độ chính xác rõ ràng. Các số dấu phẩy động không thể được sử dụng để tích lũy ngẫu nhiên chỉ vì các giá trị đã vượt qua xác minh Schema.

4. Khi gặp ngoại lệ dấu âm, bạn có thể lấy trực tiếp giá trị tuyệt đối không?

Không được khuyến khích. Thiếu từ trong OCR, di chuyển các dấu âm trong bản dịch hoặc các quy ước ký hiệu kinh doanh khác nhau có thể gây ra những bất thường. Trực tiếp lấy giá trị tuyệt đối sẽ loại bỏ các manh mối chẩn đoán.

📝 Tóm tắt

Chìa khóa của trường số lượng trước tiên là xác nhận dấu âm đại diện cho nội dung gì, sau đó để loại xác định các giới hạn. Bằng cách tách biệt các quy tắc công việc và quy tắc loại, bạn không thể từ chối hoàn tiền do nhầm lẫn cũng như không bỏ lỡ các lỗi thực sự.

Thử ngay: Tải tài liệu lên để bắt đầu dịch, giữ nguyên bố cục ban đầu

Tham khảo: Các ràng buộc về số của Lược đồ JSON