ZATCA ई-इनवॉइसिंग API इंटीग्रेशन: फ़ेज़ 2 चरण-दर-चरण कैसे काम करता है

फ़ेज़ 2 में ZATCA ई-इनवॉइसिंग API इंटीग्रेशन आपके इनवॉइसिंग सिस्टम और ज़कात, टैक्स और सीमा शुल्क प्राधिकरण के Fatoora प्लेटफ़ॉर्म के बीच का लाइव कनेक्शन है। आपका सिस्टम हर इनवॉइस एक तय फ़ॉर्मेट में इसी प्लेटफ़ॉर्म को भेजता है। स्टैंडर्ड इनवॉइस खरीदार तक पहुँचने से पहले क्लीयर किए जाते हैं। सरल इनवॉइस तुरंत जारी किए जाते हैं और 24 घंटे के भीतर रिपोर्ट किए जाते हैं। अगर आपका सॉफ़्टवेयर यह काम पहले से करता है, तो आपकी टीम में किसी को कोड लिखने की ज़रूरत नहीं है।

API शब्द सुनकर लगता है कि यह प्रोग्रामरों का काम है, लेकिन यह सिर्फ़ उस तरीके का नाम है जिससे दो सिस्टम आपस में बात करते हैं। यह बातचीत कैसे होगी, यह ZATCA तय करता है, इसलिए फ़ेज़ 2 के सिस्टम एक जैसे नियमों का पालन करते हैं। इस गाइड में इन हिस्सों को आसान शब्दों में समझाया गया है, ताकि कारोबार का मालिक या आईटी प्रमुख तय कर सके कि कनेक्शन खुद बनाना है या तैयार सॉफ़्टवेयर पर निर्भर रहना है।

कोई सिस्टम असली इनवॉइस भेज सके, इससे पहले उसका ZATCA के साथ पंजीकरण ज़रूरी है। इसी को ऑनबोर्डिंग कहते हैं, और यह काम Fatoora पोर्टल पर करदाता करता है, सॉफ़्टवेयर वेंडर नहीं। सबसे पहले आप पोर्टल से एक वन-टाइम पासवर्ड (OTP) लेते हैं। फिर आप एक सर्टिफ़िकेट साइनिंग रिक्वेस्ट (CSR) जनरेट करते हैं, जिसके ज़रिए ZATCA से अनुरोध किया जाता है कि वह आपके सिस्टम के लिए एक डिजिटल पहचान जारी करे।

जवाब में ZATCA एक अनुपालन CSID जारी करता है, जिसका इस्तेमाल सिर्फ़ टेस्टिंग के लिए होता है। इसके बाद आपका सिस्टम सैंपल इनवॉइस अनुपालन जाँच के लिए भेजता है। जब ये जाँच में सफल हो जाते हैं, तो ZATCA प्रोडक्शन CSID जारी करता है और असली इनवॉइसिंग शुरू हो सकती है। सॉफ़्टवेयर इन चरणों में आपका मार्गदर्शन कर सकता है, लेकिन ये चरण आपके कारोबार की ज़िम्मेदारी हैं, सॉफ़्टवेयर वेंडर की नहीं, इसलिए लिखकर रखें कि इन्हें किसने और कब पूरा किया।

हर इनवॉइस के लिए सिस्टम XML में एक डेटा फ़ाइल बनाता है, जिसमें UBL 2.1 नाम का एक मानक फ़ॉर्मेट इस्तेमाल होता है। इसे एक ऐसे फ़ॉर्म की तरह समझें जिसके हर फ़ील्ड का एक तय नाम होता है, ताकि ZATCA के कंप्यूटर उसे बिना अनुमान लगाए पढ़ सकें। इस फ़ाइल के साथ सिस्टम नीचे दिए गए तत्व जोड़ता है, और हर तत्व का काम सीधा-सा है। नीचे की सूची इन्हें समझाती है, ताकि आप जान सकें कि आपके सिस्टम को क्या चाहिए।

इन्हें कोई हाथ से टाइप नहीं करता। हर बार जब कोई कर्मचारी जारी करने का बटन दबाए, सॉफ़्टवेयर को इन्हें खुद बनाना चाहिए, और चूँकि काउंटर और हैश मिलकर एक चेन बनाते हैं, इसलिए उसे अपना भेजा हुआ पिछला इनवॉइस भी याद रखना होता है। अगर आप कनेक्शन खुद बनाते हैं, तो याद रखने का यह हिस्सा उन हिस्सों में से एक है जिनमें सबसे ज़्यादा सावधानी चाहिए, इसलिए इसे नज़रअंदाज़ न करें।

• UUID: एक पहचान कोड, जो किसी और इनवॉइस का नहीं होता
• काउंटर वैल्यू: जारी किए गए इनवॉइस की लगातार चलती गिनती
• पिछले इनवॉइस का हैश: पिछले इनवॉइस का फ़िंगरप्रिंट, जो इनवॉइस को एक चेन में जोड़ता है
• क्रिप्टोग्राफ़िक स्टैम्प: एक डिजिटल सील, जो इनवॉइस को आपके सिस्टम से जोड़ती है
• QR कोड: स्कैन किया जा सकने वाला कोड, जिसमें इनवॉइस के मुख्य विवरण होते हैं
• वैकल्पिक PDF/A-3 कॉपी: पढ़ने लायक फ़ाइल, जिसके अंदर XML रखा जा सकता है

एक छोटे कैफ़े का उदाहरण लें। ग्राहक काउंटर पर भुगतान करता है, इसलिए यह सरल टैक्स इनवॉइस होता है। कैश रजिस्टर उसे तुरंत प्रिंट कर देता है और सिस्टम 24 घंटे के भीतर उसे ZATCA को रिपोर्ट कर देता है। चूँकि इनवॉइस पहले जारी होता है, इसलिए कुछ देर इंटरनेट बंद रहने पर भी लाइन नहीं रुकती, जब तक इनवॉइस उस समय-सीमा के भीतर भेज दिया जाता है।

अब एक थोक व्यापारी का उदाहरण लें, जो किसी दुकान को बिल भेज रहा है। यह स्टैंडर्ड इनवॉइस है, इसलिए इसका क्लीयरेंस होता है: ZATCA इसे पहले प्राप्त करता है, और दुकान को यह तभी मिलता है जब ZATCA इसे स्वीकार कर ले। अगर ZATCA इसे स्वीकार नहीं करता, तो इनवॉइस को ठीक करके दोबारा भेजना होता है। ऐसा सिस्टम चुनें जो अस्वीकार किए गए इनवॉइस साफ़-साफ़ दिखाए, और किसी एक व्यक्ति को यह ज़िम्मेदारी दें कि वह इन्हें रोज़, बिना देर किए, जाँचे।

खुद बनाना उस कंपनी के लिए ठीक रहता है जिसके अपने डेवलपर हों और जिसकी इनवॉइसिंग की ज़रूरतें असामान्य हों। पहला वर्ज़न बनाना आसान हिस्सा है। लगातार चलने वाला काम है ZATCA के नियम बदलने पर कनेक्शन को सही बनाए रखना, हर बदलाव को सिमुलेशन एनवायरनमेंट में टेस्ट करना, और सबसे व्यस्त समय में आने वाली खराबियाँ ठीक करना। जब तक आप इनवॉइस जारी करते हैं, किसी न किसी को इस काम की ज़िम्मेदारी लेनी होगी।

तैयार सॉफ़्टवेयर में इस रखरखाव का बड़ा हिस्सा वेंडर के ज़िम्मे चला जाता है, और कुछ खराब होने पर जवाब भी वही देता है। ऐसे में आप उस वेंडर पर निर्भर रहते हैं, इसलिए पूछें कि अपडेट कैसे आते हैं और सपोर्ट से कितनी जल्दी जवाब मिलता है। दोनों ही स्थितियों में ऑनबोर्डिंग आपका कारोबार खुद ही करता है। फ़ैसला करने से पहले ये सवाल किसी डेवलपर या वेंडर से पूछें।

• फ़ेज़ 2 के कौन-से चरण आपका सिस्टम संभालता है, और कौन-से हमारे ज़िम्मे हैं?
• ZATCA के नियमों में बदलाव हम तक कैसे पहुँचते हैं, और उन्हें कौन टेस्ट करता है?
• क्या हम पहले सिमुलेशन एनवायरनमेंट में अभ्यास कर सकते हैं?
• इंटरनेट या प्लेटफ़ॉर्म बंद होने पर इनवॉइस का क्या होता है?
• अस्वीकार किए गए या न भेजे गए इनवॉइस हमें कहाँ दिखते हैं?

ZATCA फ़ेज़ 2 को नंबर वाली वेव में लागू करता है, और हर वेव का चयन निर्धारित वर्षों में VAT के अधीन राजस्व के आधार पर होता है। वह किसी वेव के करदाताओं को उनकी इंटीग्रेशन की तारीख से कम से कम छह महीने पहले सीधे सूचित करता है, और अब तक 25 वेव की घोषणा कर चुका है। कोई भी निर्णय लेने से पहले अपनी वेव और तारीख ZATCA से जाँच लें।

ZATCA ने घोषणा की है कि वेव 24 में वे करदाता शामिल थे जिनका VAT के अधीन राजस्व 2022, 2023 या 2024 में 375,000 रियाल से अधिक रहा, और इसकी समय-सीमा अधिक से अधिक 30 जून 2026 तक थी, जो बीत चुकी है। वेव 25 में वे करदाता शामिल हैं जिनका VAT के अधीन राजस्व 2022, 2023, 2024 या 2025 में 187,500 रियाल से अधिक रहा, और इसकी समय-सीमा अधिक से अधिक 1 फ़रवरी 2027 तक है।

फ़ातूराज़ दोनों फ़ेज़, यानी फ़ेज़ 1 और फ़ेज़ 2, में ZATCA की ई-इनवॉइसिंग आवश्यकताओं को सपोर्ट करता है। ऑनबोर्डिंग Fatoora पोर्टल पर करदाता करता है, और फ़ातूराज़ आपके वर्कस्पेस के भीतर चरण-दर-चरण इसमें आपका मार्गदर्शन करता है। मुफ़्त ट्रायल ZATCA के सिमुलेशन एनवायरनमेंट में चलता है, इसलिए एक भी असली इनवॉइस जारी करने से पहले आप अपने वास्तविक मामलों के साथ अभ्यास कर सकते हैं।