हर Odoo परियोजना अंततः एक ही प्रश्न पर पहुँचती है: मानक प्रवाह लगभग सही है, लेकिन ठीक वैसा नहीं जैसा व्यवसाय चाहता है। क्या आपको कोई सेटिंग बदलनी चाहिए, Odoo Studio खोलना चाहिए, या किसी डेवलपर से कस्टम मॉड्यूल लिखवाना चाहिए? इस उत्तर के लागत, स्थिरता और सबसे बढ़कर अपग्रेड पर दीर्घकालिक परिणाम होते हैं।
1CBMS में हम हर इम्प्लीमेंटेशन में एक सरल नियम का पालन करते हैं: पहले कॉन्फ़िगरेशन, फिर Studio, फिर कस्टम मॉड्यूल। इस सीढ़ी पर हर कदम नीचे उतरने से लचीलापन बढ़ता है, लेकिन साथ ही कुछ ऐसा भी जुड़ता है जिसका स्वामित्व और रखरखाव व्यवसाय को सिस्टम के पूरे जीवनकाल तक करना पड़ता है।
स्रोतों के बारे में एक टिप्पणी: यह लेख संस्करण 19.0 के लिए Odoo के आधिकारिक दस्तावेज़ों पर आधारित है। मेनू और विकल्प संस्करणों, एडिशन और होस्टिंग प्रकारों के बीच भिन्न हो सकते हैं, इसलिए प्रोडक्शन बदलने से पहले व्यवहार की पुष्टि हमेशा किसी टेस्ट डेटाबेस में करें।
पहली परत: सबसे पहले कॉन्फ़िगरेशन
Odoo हर ऐप में बड़ी संख्या में सेटिंग्स, विकल्प और कॉन्फ़िगर करने योग्य रिकॉर्ड के साथ आता है। कस्टमाइज़ेशन जैसे लगने वाले कई अनुरोध वास्तव में ऐसी मानक सुविधाएँ होते हैं जिन्हें अभी चालू नहीं किया गया है, जैसे अतिरिक्त वर्कफ़्लो चरण, दस्तावेज़ लेआउट, या वैकल्पिक फ़ील्ड जो किसी सुविधा को सक्षम करने पर दिखाई देते हैं।
Studio या कोड के लिए कोई भी विनिर्देश लिखने से पहले प्रक्रिया के प्रमुख यूज़र्स के साथ निम्नलिखित जाँचें करें:
- संबंधित हर ऐप के Settings पेज की समीक्षा करें और पढ़ें कि हर विकल्प क्या सक्षम करता है।
- जाँचें कि क्या आवश्यकता चरणों, टैग, टीमों, ऑपरेशन प्रकारों या ईमेल टेम्पलेट जैसे कॉन्फ़िगर करने योग्य रिकॉर्ड से पूरी हो जाती है।
- रिपोर्ट टेम्पलेट संपादित करने के बजाय लोगो, रंग, फ़ॉन्ट और फ़ुटर के लिए कंपनी की दस्तावेज़ लेआउट सेटिंग्स का उपयोग करें।
- पूछें कि क्या व्यवसाय अपनी प्रक्रिया को मानक प्रवाह के अनुसार ढाल सकता है, क्योंकि मानक प्रवाहों का परीक्षण और अपग्रेड Odoo करता है।
कॉन्फ़िगरेशन स्वामित्व के लिहाज़ से सबसे सस्ती परत है। यह मानक उत्पाद का हिस्सा है, अपग्रेड प्रक्रिया द्वारा आगे ले जाया जाता है, और कोई अलग कोडबेस नहीं बनाता जिसका रखरखाव किसी को करना पड़े।
दूसरी परत: Odoo Studio क्या कर सकता है
Odoo के दस्तावेज़ Studio को एक टूलबॉक्स के रूप में बताते हैं जिसका उपयोग कोडिंग ज्ञान के बिना Odoo को कस्टमाइज़ करने के लिए होता है। इसे उस ऐप और मॉडल पर रहते हुए Toggle Studio आइकन से खोला जाता है जिसे आप बदलना चाहते हैं, और Close बटन से बंद किया जाता है।
आधिकारिक दस्तावेज़ों के अनुसार Studio इन क्षेत्रों को कवर करता है:
- फ़ील्ड: टेक्स्ट, इंटीजर, दशमलव, मौद्रिक, तारीख, चेकबॉक्स, सेलेक्शन, फ़ाइल और इमेज जैसे सरल फ़ील्ड, और Many2One, One2Many, Lines, Many2Many, Tags तथा related फ़ील्ड जैसे रिलेशनल फ़ील्ड।
- व्यू: फ़ॉर्म, ऐक्टिविटी, सर्च, कानबन, लिस्ट, मैप, कैलेंडर, कोहोर्ट, Gantt, पिवट और ग्राफ़ व्यू।
- मॉडल और ऐप्स: शुरू से बनाए गए नए मॉडल, जिनमें निर्माण को तेज़ करने के लिए चैटर, पाइपलाइन चरण, टैग, आर्काइविंग और लाइनों जैसी सुझाई गई सुविधाएँ होती हैं।
- ऑटोमेशन नियम: मान अपडेट, ईमेल घटनाओं, समय शर्तों, रिकॉर्ड बनने या हटने, UI बदलाव और बाहरी वेबहुक पर आधारित ट्रिगर।
- स्वीकृति नियम: बटनों से जुड़े स्वीकृति चरण, जिनमें स्वीकृतकर्ता यूज़र, ग्रुप या दोनों के रूप में परिभाषित होते हैं। Studio वेबहुक और सुरक्षा नियम भी कवर करता है।
- PDF रिपोर्ट: रिपोर्ट टेम्पलेट में स्थिर टेक्स्ट संपादित करना, डायनेमिक फ़ील्ड, तालिकाएँ, कॉलम और इमेज जोड़ना; ध्यान दें कि रिपोर्ट हेडर या फ़ुटर संपादित करने से सभी रिपोर्टें प्रभावित होती हैं।
जब आप ड्रैग एंड ड्रॉप से कोई व्यू बदलते हैं, तो Studio मानक व्यू को ओवरराइट करने के बजाय उपयुक्त इनहेरिटेड व्यू और XPath अपने-आप बनाता है। Studio का सारा काम आपके डेटाबेस में studio_customization नाम के एक मॉड्यूल में समूहित रहता है, जिसे ZIP फ़ाइल के रूप में एक्सपोर्ट करके किसी दूसरे डेटाबेस में इम्पोर्ट किया जा सकता है।
Studio एक Odoo Enterprise ऐप है। आधिकारिक पेज यह भी बताता है कि Standard प्राइसिंग प्लान वाले डेटाबेस पर Studio इंस्टॉल करने से Custom प्लान में अपग्रेड लागू हो जाता है, इसलिए इसे सक्षम करने से पहले व्यावसायिक प्रभाव की जाँच अपने Odoo अकाउंट मैनेजर से करें। Community डेटाबेस में Studio शामिल नहीं है; वहाँ कॉन्फ़िगरेशन से आगे का कोई भी काम डेवलपर मोड की तकनीकी सेटिंग्स या मॉड्यूल के माध्यम से किया जाता है।
दूसरी परत जारी: Studio की सीमाएँ
Studio शक्तिशाली है, लेकिन दस्तावेज़ स्वयं कई सीमाओं और जोखिमों की ओर इशारा करते हैं जिनका हर परियोजना को ध्यान रखना चाहिए:
- किसी फ़ील्ड का तकनीकी नाम बनने के बाद Studio में बदला नहीं जा सकता, और कस्टम फ़ील्ड में कम से कम x_ उपसर्ग रहना चाहिए, जबकि Studio फ़ील्ड x_studio_ का उपयोग करते हैं।
- रिपोर्टों में ऐक्टिविटी व्यू और कंडीशनल ब्लॉक केवल XML संपादित करके बदले जा सकते हैं, जिसके लिए डेवलपर मोड आवश्यक है।
- मानक या इनहेरिटेड व्यू को सीधे संपादित करने की सलाह नहीं दी जाती, क्योंकि वे बदलाव अपडेट या मॉड्यूल अपग्रेड के दौरान रीसेट होकर खो जाएँगे।
- Odoo दृढ़ता से अनुशंसा करता है कि किसी मानक रिपोर्ट की डुप्लिकेट बनाकर उसकी कॉपी संपादित करें, और चेतावनी देता है कि रिपोर्ट XML को सीधे बदलने से अपग्रेड के दौरान समस्याएँ हो सकती हैं।
- ऑटोमेशन नियमों में Execute Code ऐक्शन Python चलाता है, और दस्तावेज़ों के अनुसार कस्टम कोड का रखरखाव Standard या Custom प्लान में शामिल नहीं है और इसके लिए अतिरिक्त शुल्क लगता है।
- वेबहुक किसी डेवलपर या तकनीकी भूमिका वाले व्यक्ति के साथ डिज़ाइन किए जाने चाहिए, क्योंकि गलत ढंग से कॉन्फ़िगर किए गए वेबहुक डेटाबेस को बाधित कर सकते हैं।
- एक्सपोर्ट किए गए Studio कस्टमाइज़ेशन केवल उसी Odoo संस्करण वाले और समान ऐप्स तथा मॉड्यूल इंस्टॉल किए गए डेटाबेस में ही इम्पोर्ट किए जा सकते हैं।
व्यवहार में Studio डेटा कैप्चर, लेआउट, सरल ऑटोमेशन और स्वीकृतियों के लिए आदर्श है। यह तब जोखिम भरा हो जाता है जब इसका उपयोग वास्तविक प्रोग्रामिंग को ऐसे XML संपादनों या Execute Code ऐक्शन में छिपाने के लिए किया जाता है जिनका कोई दस्तावेज़ीकरण नहीं करता।
तीसरी परत: कस्टम Python मॉड्यूल कब उचित है
कस्टम मॉड्यूल एक अलग कोडबेस है जो मॉडल, व्यू, सुरक्षा, डेटा फ़ाइलों और Python लॉजिक के माध्यम से Odoo का विस्तार करता है, और उसी फ़्रेमवर्क से बनता है जिसका उपयोग Odoo अपने ऐप्स के लिए करता है। यह तब सही उपकरण है जब आवश्यकता उससे आगे जाती है जिसे कॉन्फ़िगरेशन और Studio साफ़ ढंग से व्यक्त कर सकते हैं।
सामान्य स्थितियाँ जहाँ हम कस्टम मॉड्यूल की अनुशंसा करते हैं:
- जटिल व्यावसायिक नियम, गणनाएँ या बाध्यताएँ जिनके लिए स्वचालित परीक्षण और वर्ज़न कंट्रोल ज़रूरी है।
- बाहरी सिस्टम के साथ इंटीग्रेशन जिनके लिए मज़बूत त्रुटि प्रबंधन, पुनःप्रयास और लॉगिंग आवश्यक है।
- मानक व्यावसायिक लॉजिक में बदलाव, जैसे दस्तावेज़ों का सत्यापन कैसे होता है या मानों की गणना कैसे होती है, न कि केवल वे कैसे प्रदर्शित होते हैं।
यहाँ होस्टिंग मायने रखती है। आधिकारिक दस्तावेज़ों के अनुसार Odoo Online कस्टम मॉड्यूल या Odoo Apps Store के मॉड्यूल के साथ संगत नहीं है। कस्टम मॉड्यूल के लिए Odoo.sh या ऑन-प्रिमाइस इंस्टॉलेशन आवश्यक है, इसलिए होस्टिंग का निर्णय और कस्टमाइज़ेशन रणनीति साथ-साथ तय की जानी चाहिए।
हर विकल्प का अपग्रेड पर प्रभाव
- कॉन्फ़िगरेशन: मानक उत्पाद का हिस्सा है और मानक अपग्रेड प्रक्रिया द्वारा माइग्रेट होता है।
- Studio: Odoo के दस्तावेज़ों में वर्णित अपग्रेड सेवाओं में Studio ऐप से बनाए गए सभी कस्टमाइज़ेशन का अपग्रेड शामिल है, जब तक Studio इंस्टॉल है और उसका सब्सक्रिप्शन सक्रिय है।
- कस्टम मॉड्यूल: कस्टम मॉड्यूल वाले डेटाबेस को तब तक अपग्रेड नहीं किया जा सकता जब तक उन मॉड्यूल का लक्ष्य Odoo संस्करण के लिए कोई संस्करण उपलब्ध न हो, और उसे संगत बनाना मॉड्यूल के मेंटेनर की ज़िम्मेदारी है।
कस्टमाइज़ किए गए डेटाबेस को अपग्रेड करने के लिए Odoo की गाइड अनुशंसा करती है: डेवलपमेंट रोक दें, जाँचें कि कौन-सी कस्टम सुविधाएँ अब मूल रूप से उपलब्ध हैं, हर मॉड्यूल को लक्ष्य संस्करण के खाली डेटाबेस पर साफ़ ढंग से इंस्टॉल होने योग्य बनाएँ, नाम बदले गए मॉडल, फ़ील्ड और एक्सटर्नल आइडेंटिफ़ायर के लिए अपग्रेड स्क्रिप्ट लिखें, और प्रोडक्शन को छूने से पहले अपग्रेड का पूर्वाभ्यास करें।
परत चाहे जो भी हो, अपग्रेड किए गए डेटाबेस का पूरी तरह परीक्षण करें। दस्तावेज़ इंटीग्रेशन, स्वचालित ऐक्शन, सर्वर ऐक्शन और रिपोर्टों सहित व्यावसायिक प्रवाहों का शुरू से अंत तक परीक्षण करने की सलाह देते हैं, और याद दिलाते हैं कि टेस्ट डेटाबेस न्यूट्रलाइज़ किए जाते हैं, जिनमें शेड्यूल्ड ऐक्शन और बाहर जाने वाले ईमेल निष्क्रिय रहते हैं।
गवर्नेंस: कस्टमाइज़ेशन को नियंत्रण में रखना
कस्टमाइज़ेशन शायद ही कभी पहले दिन विफल होते हैं। वे वर्षों बाद विफल होते हैं, जब किसी को याद नहीं रहता कि कोई फ़ील्ड क्यों मौजूद है या कोई ऑटोमेशन नियम किसने लिखा। एक हल्का गवर्नेंस मॉडल इसे रोकता है।
- एक कस्टमाइज़ेशन रजिस्टर रखें जिसमें हर Studio फ़ील्ड, व्यू बदलाव, ऑटोमेशन नियम, स्वीकृति नियम, रिपोर्ट और कस्टम मॉड्यूल उसके स्वामी और व्यावसायिक कारण के साथ दर्ज हो।
- सभी बदलाव पहले किसी टेस्ट या स्टेजिंग डेटाबेस में करें, फिर उन्हें एक नियंत्रित प्रक्रिया के माध्यम से प्रोडक्शन में ले जाएँ।
- Studio और डेवलपर मोड को प्रशिक्षित एडमिनिस्ट्रेटर तक सीमित रखें; दस्तावेज़ स्वयं चेतावनी देते हैं कि कुछ डेवलपर टूल उन्नत हैं और उनमें जोखिम होते हैं।
- हर अपग्रेड से पहले रजिस्टर की समीक्षा करें और उन कस्टमाइज़ेशन को हटा दें जिन्हें नया संस्करण मूल रूप से कवर करता है।
- कस्टम मॉड्यूल का कोड परीक्षणों के साथ वर्ज़न कंट्रोल में रखें, और सुनिश्चित करें कि उसके रखरखाव की व्यवस्था मौजूद हो।
वर्कशॉप में लागू करने योग्य एक निर्णय मैट्रिक्स
जब कोई नई आवश्यकता सामने आती है, तो हम इन प्रश्नों पर क्रम से विचार करते हैं और उस पहली परत पर रुक जाते हैं जो उसे पूरा करती है।
- क्या कोई मानक सेटिंग, कॉन्फ़िगर करने योग्य रिकॉर्ड या प्रक्रिया में बदलाव ज़रूरत पूरी कर सकता है? कॉन्फ़िगरेशन का उपयोग करें।
- क्या यह एक नया फ़ील्ड, व्यू लेआउट में बदलाव, सरल ऑटोमेशन, स्वीकृति चरण या रिपोर्ट की शब्दावली में बदलाव है? Studio का उपयोग करें।
- क्या इसके लिए Python लॉजिक, स्वचालित परीक्षण, जटिल इंटीग्रेशन या कई डेटाबेस में पुनः उपयोग चाहिए? कस्टम मॉड्यूल का उपयोग करें।
- क्या डेटाबेस Odoo Online पर है? कॉन्फ़िगरेशन और Studio के भीतर रहें, या पहले Odoo.sh या ऑन-प्रिमाइस पर जाने की योजना बनाएँ।
1CBMS कैसे मदद कर सकता है
1CBMS मिस्र और इराक की कंपनियों को ऐसे Odoo 19 Enterprise समाधान डिज़ाइन करने में मदद करता है जो मानक के क़रीब रहें। हम कॉन्फ़िगरेशन को वास्तविक कमियों से अलग करने के लिए फ़िट-गैप वर्कशॉप चलाते हैं, अनुशासित Studio कस्टमाइज़ेशन बनाते हैं, वास्तव में ज़रूरत होने पर कस्टम मॉड्यूल विकसित और बनाए रखते हैं, और कस्टमाइज़ेशन रजिस्टर तथा अपग्रेड परीक्षण योजनाएँ तैयार करते हैं ताकि आपका सिस्टम रखरखाव योग्य बना रहे। अपने मौजूदा कस्टमाइज़ेशन की समीक्षा या नए इम्प्लीमेंटेशन की योजना के लिए www.1cbms.com के माध्यम से हमसे संपर्क करें।