पावत्या आणि पावत्या समान प्रवेशद्वार सामायिक करतात. दोन रचनांचे मिश्रण कसे टाळावे?

इन्व्हॉइस आणि पावत्या अनेकदा प्रक्रियेसाठी समान इंटरफेसमध्ये ठेवल्या जातात, परंतु ते प्राप्त करण्यासाठी फक्त "सर्व फील्ड ऐच्छिक" असलेली एक विस्तृत ऑब्जेक्ट वापरल्यास, ते कोणतेही इनपुट सामावून घेऊ शकते, परंतु ते कोणत्या प्रकारचे दस्तऐवज प्राप्त झाले हे सांगू शकत नाही. हा लेख डेव्हलपर आणि व्यावसायिक कर्मचाऱ्यांसाठी आहे ज्यांना इंटरफेस प्राप्त करणारा दस्तऐवज डिझाइन करणे किंवा JSON स्कीमा प्रमाणीकरण नियम राखणे आवश्यक आहे. हे वाचल्यानंतर, तुम्ही दोन स्वतंत्र करार कसे ठेवायचे, स्पष्ट प्रकार फील्डसह एक निवडा आणि शाखा संघर्ष आणि अज्ञात प्रकार कसे हाताळायचे ते शिकाल.

या लेखातील उदाहरणे प्रक्रिया पद्धती प्रदर्शित करण्यासाठी सिंथेटिक नमुने वापरतात. कोड एका वेगळ्या वातावरणात उदाहरणांसह तपासला गेला आहे, परंतु हे सर्व वास्तविक फाइल्स किंवा उत्पादन कार्यक्षमतेची हमी नाही. महत्त्वाच्या कागदपत्रांवर प्रक्रिया करण्यापूर्वी, कृपया मूळ कागदपत्रे ठेवा आणि मजकूरातील सीमा आणि स्वीकृती आयटमनुसार त्यांचे पुनरावलोकन करा.

पावत्या आणि पावत्या सामायिक केलेल्या प्रवेशाचा सामना कसा करावा? एका वाक्याचा निष्कर्ष

एकाच पोर्टलवरून दोन दस्तऐवज प्राप्त करताना, सर्व काही ठेवू शकणारी विस्तृत वस्तू वापरण्याऐवजी दोन स्वतंत्र करार ठेवणे आणि त्यापैकी एक निवडण्यासाठी आवश्यक kind फील्ड वापरणे अधिक स्पष्ट आहे.

तुम्ही ब्रॉड ऑब्जेक्ट का वापरू शकत नाही?

सर्व फील्ड ऐच्छिक बनवण्याचा धोका

जेव्हा इंटरफेस पावत्या आणि पावत्या दोन्ही स्वीकारतो तेव्हा "सर्व फील्ड ऐच्छिक" सह मोठ्या वस्तू लिहिणे सोपे असते. अशा ऑब्जेक्टला विविध प्रकारचे इनपुट मिळू शकतात, परंतु या किंमतीवर:

• कोणते दस्तऐवज प्राप्त झाले ते संरचनेवरून सांगणे अशक्य आहे.
• दोन दस्तऐवजांच्या आवश्यक बाबी आणि पर्यायी बाबी एकमेकांमध्ये मिसळल्या गेल्या आहेत आणि पडताळणीचे नियम अधिकाधिक अस्पष्ट होत आहेत.
• जेव्हा एरर येते तेव्हा नेमके कुठे इनपुट अपेक्षेप्रमाणे नाही हे स्पष्ट करणे कठीण असते.

दोन स्वतंत्र करार ठेवणे आणि त्यातील एक स्पष्ट प्रकार फील्डसह निवडणे अधिक स्पष्ट होईल.

oneOf फक्त कोणीच नाही

आच्छादित शाखांमुळे कायदेशीर इनपुट अयशस्वी होईल.

oneOf ला इनपुट एका शाखेशी तंतोतंत जुळणे आवश्यक आहे. दोन्ही शाखा एकाच वेळी पास झाल्यास, एकूण पडताळणी अयशस्वी होईल.

शाखांमध्ये फक्त काही पर्यायी फील्ड असल्यास, ते लक्षणीयरीत्या ओव्हरलॅप होण्याची शक्यता आहे. यावेळी, कायदेशीर इनपुट सत्यापन पास करण्यात अयशस्वी झाले.

ओव्हरलॅप दूर करण्यासाठी प्रकार आणि स्थिरता वापरा

आवश्यक kind फील्ड वापरून तसेच const चे निश्चित मूल्य शाखांमधील स्पष्ट सीमा स्थापित करू शकते आणि अशा आच्छादनांना आगाऊ काढून टाकू शकते.

संयोजन नियमांबद्दल अधिक तपशीलांसाठी, कृपया JSON स्कीमा संयोजन नियम पहा.

एक एक्झिक्यूटेबल ऑफलोड प्रोटोकॉल

from jsonschema import Draft202012Validator

def branch(kind, identity):
    return {
        "type": "object", "additionalProperties": False,
        "required": ["kind", identity],
        "properties": {"kind": {"const": kind},
                       identity: {"type": "string", "minLength": 1}}
    }

schema = {"oneOf": [branch("invoice", "invoice_number"),
                    branch("receipt", "receipt_number")]}
v = Draft202012Validator(schema)
valid = lambda x: not list(v.iter_errors(x))
assert valid({"kind": "invoice", "invoice_number": "I-1"})
assert valid({"kind": "receipt", "receipt_number": "R-1"})
assert not valid({"kind": "invoice", "receipt_number": "R-1"})
assert not valid({"kind": "receipt", "receipt_number": ""})
assert not valid({"kind": "invoice", "invoice_number": "I-1",
                  "receipt_number": "R-1"})
assert not valid({"kind": "unknown"})

हे एक सरलीकृत उदाहरण रेकॉर्ड आहे आणि वास्तविक इनव्हॉइसचे संपूर्ण फील्ड मॉडेल नाही. कोड शाखा निवड आणि अनावश्यक फील्ड नाकारणे दर्शवितो. कर दर, शीर्षलेख आणि रक्कम स्वतंत्रपणे परिभाषित करणे आवश्यक आहे.

व्यवसायाने अतिरिक्त फील्डला परवानगी दिल्यास, या फील्डसाठी नेमस्पेसेस शांतपणे सर्व मर्यादा रद्द करण्याऐवजी स्पष्ट केल्या पाहिजेत.

एरर मेसेजमध्ये फक्त "कोणतीही जुळणी नाही" दाखवू नका

फक्त "विसंगत" प्रदर्शित केले जाते आणि वापरकर्ते किंवा देखभाल करणाऱ्यांना समस्या कुठे आहे हे माहित नाही. खालील तक्त्यामध्ये अनेक सामान्य इनपुट वैशिष्ट्ये आणि संबंधित अभिप्राय पद्धती सूचीबद्ध आहेत:

अनिश्चित प्रकारांना देखील आउटलेट आवश्यक आहे

जर क्लासिफायर इनव्हॉइस आणि पावत्या यांच्यात फरक करू शकत नसेल, तर त्याने "यशाचा" अंदाज लावण्यासाठी यादृच्छिक शाखा निवडण्याऐवजी अज्ञात स्थिती सोडली पाहिजे.

येथे तीन भिन्न स्तर आहेत ज्यांना स्वतंत्रपणे पाहणे आवश्यक आहे:

• वर्गीकरण आत्मविश्वास: दस्तऐवजाच्या प्रकाराचा न्याय करताना प्रणाली किती विश्वासार्ह आहे.
• संरचना पडताळणी: इनपुट निवडलेल्या कराराशी सुसंगत आहे की नाही.
• व्यावसायिक सत्यता: दस्तऐवज स्वतःच प्रामाणिक आणि वैध आहे की नाही.

स्ट्रक्चरल पडताळणी उत्तीर्ण केल्याने वर्गीकरण योग्य असल्याचे सिद्ध करता येत नाही किंवा कागदपत्र प्रामाणिक असल्याचे सिद्ध करता येत नाही.

दस्तऐवजाचा प्रकार अनुवाद प्रक्रियेत देखील ठेवला पाहिजे

एकाच फील्डला वेगवेगळ्या कागदपत्रांमध्ये वेगवेगळ्या संज्ञा वापरण्याची आवश्यकता असू शकते. OmniDoc च्या शब्दावली आणि द्विभाषिक पुनरावलोकन वर्कफ्लो वापरताना, वितरण सूचीसह दस्तऐवजाचा प्रकार प्रदान केल्याने समीक्षकांना संख्या आणि रकमेचा संदर्भ समजण्यास मदत होते.

विस्तृत JSON ऑब्जेक्टला हे फरक मिटवू देऊ नका.

📊 मुख्य तुलना

🎯 तुमच्यासाठी कोणती पद्धत योग्य आहे?

जर तुम्हाला पावत्या आणि पावत्या दोन्ही मिळण्याची आवश्यकता असेल

दोन वेगळे करार ठेवा आणि kind ला आवश्यक फील्ड बनवा.

जर तुमची शाखा फील्ड खूप ओव्हरलॅप होत असेल

एकाच वेळी अनेक शाखांशी जुळणारे कायदेशीर इनपुट टाळण्यासाठी प्रत्येक शाखेत const सह kind निश्चित करा.

जर तुमची प्रणाली अतिरिक्त फील्डला परवानगी देत असेल

प्रथम अतिरिक्त फील्डचे नेमस्पेस स्पष्ट करा, आणि नंतर निर्बंध कसे शिथिल करायचे ते ठरवा.

जर तुमचा क्लासिफायर पुरेसा आत्मविश्वास नसेल

स्थिती अज्ञात राहू द्या, क्रमवारी लावण्यासाठी दस्तऐवज रांगेत पाठवा आणि जबरदस्तीने शाखा निवडू नका.

❓ वारंवार विचारले जाणारे प्रश्न (FAQ)

1. फक्त सर्व फील्ड ऐच्छिक असलेले ऑब्जेक्ट का वापरू नये?

अशी वस्तू काहीही ठेवू शकते, परंतु ती नेमकी काय प्राप्त होते हे सांगणे कठीण आहे.

२. oneOf कायदेशीर इनपुट का अयशस्वी होतो?

oneOf ला अगदी एका शाखेशी जुळणे आवश्यक आहे. दोन्ही शाखा एकाच वेळी पास झाल्यास, एकूण पडताळणी अयशस्वी होईल. जेव्हा शाखा फील्ड खूप ओव्हरलॅप होतात तेव्हा ही परिस्थिती सहजपणे उद्भवू शकते.

३. अतिरिक्त फील्डला परवानगी देताना तुम्ही कशाकडे लक्ष द्यावे?

सर्व मर्यादा शांतपणे रद्द करण्यापेक्षा अतिरिक्त फील्डचे नेमस्पेस स्पष्ट केले पाहिजे.

४. क्लासिफायर दस्तऐवज प्रकार निर्धारित करू शकत नसल्यास मी काय करावे?

अज्ञात स्थिती ठेवा आणि वर्गीकृत करण्यासाठी स्वतंत्र रांग प्रविष्ट करा. यश मिळविण्यासाठी यादृच्छिकपणे शाखा निवडू नका.

5. जर संरचना पडताळणी पास झाली तर याचा अर्थ कागदपत्र अस्सल आहे का?

करू शकत नाही. वर्गीकरण आत्मविश्वास, संरचना पडताळणी आणि व्यवसाय सत्यता हे तीन भिन्न स्तर आहेत. रचना उत्तीर्ण केल्याने कागदपत्र अस्सल असल्याचे सिद्ध होऊ शकत नाही.

📝 सारांश

पावत्या आणि पावत्या एकाच एंट्रीमध्ये ठेवताना, दोन वेगळे करार ठेवा आणि आवश्यक kind फील्डसह ते निवडा जेणेकरून प्रविष्ट केलेला दस्तऐवजाचा प्रकार स्पष्टपणे दृश्यमान होईल. शाखा पडताळणी, त्रुटी अभिप्राय आणि अज्ञात प्रकारचे निर्गमन देखील एकत्रितपणे डिझाइन केले पाहिजे.

हे आता वापरून पहा: मूळ लेआउट कायम ठेवून भाषांतर सुरू करण्यासाठी दस्तऐवज अपलोड करा