इंजीनियरिंग
कस्टम सॉफ़्टवेयर के लिए Tally इंटीग्रेशन, सही तरीक़े से
ज़्यादातर भारतीय कारोबार अपनी बहियाँ Tally में रखते हैं, इसलिए पैसे से जुड़ी हर प्रणाली को उससे बात करनी पड़ती है। अच्छी तरह हो तो यह दिखता भी नहीं। ख़राब तरह हो तो ऐसे डुप्लिकेट वाउचर बनते हैं जिन्हें कोई समझा नहीं पाता।
किसी भारतीय कारोबार के लिए हम जो भी प्रणाली बनाते हैं, वह लगभग हमेशा एक ही जगह ख़त्म होती है: हिसाब Tally में है, और अकाउंटेंट उसे छोड़ने वाले नहीं। यह आम तौर पर सही फ़ैसला है। Tally वह है जिसे अकाउंटेंट जानते हैं, जिसकी ऑडिटर अपेक्षा करते हैं, और जहाँ रिटर्न तैयार होते हैं। कस्टम प्रणाली का काम उसे साफ़-सुथरा डेटा देना है, उसकी जगह लेना नहीं।
नई प्रणाली अकाउंटेंट का समय बचाती है या उनके लिए काम बढ़ाती है, यह लगभग पूरी तरह इस पर निर्भर है कि वह जुड़ाव कैसे डिज़ाइन किया गया है।
डेटा Tally में कैसे पहुँचता है
- HTTP पर XMLTallyPrime जिस मशीन पर इंस्टॉल है, वहाँ सर्वर की तरह चल सकता है — डिफ़ॉल्ट रूप से पोर्ट 9000 पर — और मास्टर व वाउचर बनाने या रिपोर्ट निकालने वाले XML अनुरोध स्वीकार कर सकता है। यह सबसे सीधा रास्ता है और ज़्यादातर इंटीग्रेशन यही इस्तेमाल करते हैं। इसके लिए Tally का चालू होना और कंपनी का खुला होना ज़रूरी है।
- फ़ाइल इम्पोर्टवाउचर और मास्टर XML फ़ाइलों के रूप में तैयार होते हैं और अकाउंटेंट उन्हें इम्पोर्ट करते हैं। धीमा, पर इसमें व्यक्ति शामिल रहता है, और यह वहाँ भी काम करता है जहाँ Tally मशीन तक पहुँचा ही नहीं जा सकता।
- ODBCTally अपना डेटा ODBC के ज़रिए भी उपलब्ध कराता है, जो रिपोर्ट किसी दूसरी प्रणाली में पढ़ने के लिए सुविधाजनक है। यह पढ़ने का रास्ता है, एंट्री लिखने का नहीं।
- TDL कस्टमाइज़ेशनTally की अपनी डेफ़िनिशन लैंग्वेज Tally के भीतर फ़ील्ड और रिपोर्ट जोड़ सकती है। यह उपयोगी है, पर यह ऐसा कोड है जिसे Tally के हर नए रिलीज़ के साथ संभालना पड़ता है, इसलिए हम इसे काम की ज़रूरत भर तक सीमित रखते हैं।
जब Tally ऑफ़िस के डेस्कटॉप पर हो
Tally आम तौर पर ऑफ़िस के कंप्यूटर पर चलता है, और वेब एप्लिकेशन कहीं और किसी सर्वर पर। दोनों सीधे एक-दूसरे को कॉल नहीं कर सकते, और ऐसा करवाना भी नहीं चाहिए। भरोसेमंद तरीक़ा है Tally मशीन पर एक छोटा कनेक्टर, जो वेब एप्लिकेशन से बाकी एंट्री माँगता है, उन्हें स्थानीय रूप से Tally में पोस्ट करता है, और बताता है कि क्या हुआ। कनेक्शन सिर्फ़ बाहर की ओर जाता है, इसलिए ऑफ़िस का कुछ भी खुला नहीं रहता।
वाउचर से पहले मास्टर
वाउचर लेजर, स्टॉक आइटम, गोदाम और कॉस्ट सेंटर को नाम से जोड़ता है। अगर कोई नाम Tally के मास्टर से हूबहू मेल न खाए, तो इम्पोर्ट विफल हो जाता है, या इससे बुरा, ग़लत मास्टर पर दर्ज हो जाता है। इसलिए इंटीग्रेशन के पास एक मैपिंग होनी चाहिए: नई प्रणाली की हर पार्टी, आइटम और लेजर Tally में अपने मास्टर से जुड़ा।
नए मास्टर के लिए भी नियम चाहिए। या तो इंटीग्रेशन उन्हें तय नियमों के तहत बनाए, या एंट्री रोककर अकाउंटेंट से पूछे। उसे यह कभी नहीं होने देना चाहिए कि वर्तनी का भटकाव — आख़िर में एक पूर्ण विराम, बदला हुआ संक्षिप्त रूप — चुपचाप उसी पार्टी का दूसरा लेजर बना दे।
कभी दो बार पोस्ट न करें
इंटीग्रेशन की सबसे आम विफलता डुप्लिकेट वाउचर है। Tally एंट्री स्वीकार कर लेता है, जवाब आने से पहले नेटवर्क टूट जाता है, और प्रणाली उसे फिर भेज देती है। दोनों प्रतियाँ बहियों में हैं, और जोड़ इस तरह ग़लत हैं कि ढूँढने में पूरी दोपहर लग जाए।
- हर एंट्री की स्थिर पहचानहर वाउचर स्रोत प्रणाली का एक पहचानकर्ता लेकर चलता है, और इंटीग्रेशन कुछ भी बनाने से पहले उसे जाँचता है। तब एक ही एंट्री दो बार भेजने पर वह दूसरी जोड़ने के बजाय पहली को अपडेट करता है या छोड़ देता है।
- पोस्टिंग लॉगहर प्रयास दर्ज, कि क्या भेजा गया और Tally ने क्या जवाब दिया, ताकि छूटी या दोहरी एंट्री मिनटों में खोजी जा सके, दोबारा गढ़नी न पड़े।
- मिलानदोनों प्रणालियों के बीच दिन और लेजर के हिसाब से जोड़ों की नियमित तुलना, जो उन मामलों को पकड़ती है जिन पर उस समय किसी का ध्यान नहीं गया।
- सावधानी से दोबारा प्रयासकनेक्शन की विफलताओं पर अपने-आप दोबारा प्रयास होता है। जो कुछ Tally ने अस्वीकार किया, वह कारण के साथ किसी व्यक्ति के पास जाता है, बजाय इसके कि बार-बार भेजा जाए जब तक कहीं ग़लत जगह दर्ज न हो जाए।
विस्तार या सारांश
हर लेन-देन Tally में अपने अलग वाउचर के रूप में नहीं जाना चाहिए। चुनाव लेन-देन के प्रकार के हिसाब से है, और यह अकाउंटेंट के साथ मिलकर करना चाहिए, उनकी जगह नहीं।
- बिक्री के इनवॉइस आम तौर पर एक-एक करके जाते हैं, क्योंकि जहाँ रिटर्न Tally से तैयार होते हैं, वहाँ इनवॉइस स्तर का विवरण होना ज़रूरी है।
- पेरोल आम तौर पर महीने में एक समीक्षा किए गए जर्नल के रूप में जाता है, कॉस्ट सेंटर के हिसाब से बँटा, न कि हर कर्मचारी का अलग वाउचर।
- बड़ी मात्रा वाली काउंटर रसीदें अक्सर भुगतान के तरीक़े के हिसाब से रोज़ के सारांश के रूप में जाती हैं, और विवरण स्रोत प्रणाली में रहता है।
- स्टॉक की आवाजाही इस पर निर्भर है कि स्टॉक का मूल्यांकन Tally में होता भी है या नहीं। अगर इन्वेंटरी नई प्रणाली के पास है, तो Tally को अक्सर सिर्फ़ उसका लेखा असर चाहिए।
GST की वे बारीकियाँ जो रिटर्न बिगाड़ती हैं
- हर लाइन पर GSTIN, सप्लाई का स्थान और HSN या SAC, ताकि हर वाउचर Tally में बदलाव किए बिना रिटर्न के लिए पूरा हो।
- टैक्स लेजर दर और प्रकार के हिसाब से मैप हों, CGST और SGST बनाम IGST, न कि हर चीज़ के लिए एक टैक्स लेजर।
- दोनों प्रणालियों में राउंडिंग एक ही तरह से। वरना जोड़ एक रुपये से अलग होते हैं, और उसके बाद कोई किसी पर भरोसा नहीं करता।
- क्रेडिट नोट उसी इनवॉइस से जुड़े जिसे वे सुधारते हैं, न कि अलग-थलग नकारात्मक एंट्री के रूप में पोस्ट।
- बंद अवधि की तारीख़ वाला वाउचर इंटीग्रेशन अस्वीकार करे, बजाय इसके कि वह चुपचाप उस महीने में पोस्ट हो जाए जिसे अकाउंटेंट बंद कर चुके हैं।
Zoho Books और दूसरे लेजर
Zoho Books के पास दस्तावेज़ों में बताया गया REST API है, जो ऑफ़िस-मशीन की समस्या पूरी तरह हटा देता है। इस लेख की बाकी हर बात फिर भी लागू होती है: मास्टर की मैपिंग, हर एंट्री की स्थिर पहचान, पोस्टिंग लॉग और मिलान। यही किसी भी लेजर के साथ इंटीग्रेशन को भरोसेमंद बनाते हैं, और यही सबसे ज़्यादा छूट जाते हैं।