कस्टम ERP या अनुकूलित रेडीमेड ERP?

बुडापेस्ट की सॉफ़्टवेयर विकास कंपनी Mesterséges Intelligencia Központ Kft. के अनुसार, रेडीमेड ERP तब ठीक है जब प्रक्रियाएँ उसके मानक के अनुसार ढल सकें; कस्टम ERP तब, जब कामकाज अलग हो, या अनुकूलन अपग्रेड को ख़तरे में डाल दे।

मुख्य बात: तीन रास्ते हैं: रेडीमेड ERP, जैसा है वैसा; कॉन्फ़िगर किया गया और निर्माता के विस्तार बिंदुओं पर पूरक बनाया गया रेडीमेड ERP; और कस्टम ERP। रेडीमेड सिस्टम के कोर (मूल हिस्से) में जितना गहरा हाथ डालना पड़े, उतना ही उचित है कि अनोखे हिस्से को अलग मॉड्यूल में रखा जाए, या अपना सिस्टम बनाया जाए। किसी भी रास्ते पर, पहले से डेटा की सफ़ाई के साथ चरणों में किया गया बदलाव एक बार के, बड़े बदलाव से कम जोखिम वाला होता है।

ERP क्या है?

ERP (enterprise resource planning, हिंदी में उद्यम संसाधन योजना प्रणाली) कंपनी की बुनियादी प्रक्रियाओं को एक सिस्टम में जोड़ता है। Microsoft की परिभाषा के अनुसार, ERP एक ऐसा व्यवसाय-प्रबंधन सॉफ़्टवेयर है जो संगठनों को उनकी बुनियादी प्रक्रियाओं (जैसे वित्त, आपूर्ति शृंखला, उत्पादन, मानव संसाधन, ख़रीद और प्रोजेक्ट प्रबंधन) को एकीकृत करने में मदद करता है (Microsoft: What is ERP?)।

व्यवहार में ERP का मूल्य इसमें है कि एक ही डेटा सिर्फ़ एक बार बनता है: आने वाले ऑर्डर से गोदाम से माल की निकासी बनती है, उससे इनवॉइस, और इनवॉइस से लेखांकन प्रविष्टि और बकाया राशि। अगर ये क़दम अलग-अलग प्रोग्रामों और स्प्रेडशीट में रहते हैं, तो डेटा हाथ से एक जगह से दूसरी जगह जाता है, और उसके साथ ग़लतियाँ भी। ग्राहकों और बिक्री पर नज़र रखना एक संबंधित क्षेत्र है, लेकिन अलग निर्णय; इसके बारे में हम कस्टम CRM विकसित करना कब फ़ायदेमंद है? लेख में लिखते हैं।

ERP तक पहुँचने के तीन रास्ते

“कस्टम या रेडीमेड” का सवाल असल में तीन विकल्पों के बीच का चुनाव है। इनके बीच की सीमा स्पष्ट नहीं है, लेकिन लागत, अपग्रेड और निर्भरता में अंतर बड़ा है।

रेडीमेड ERP, जैसा है वैसा

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

रेडीमेड ERP, कॉन्फ़िगर और विस्तारित

ज़्यादातर कार्यान्वयन कहीं यहीं पहुँचते हैं। तीन चीज़ों में अंतर करना उचित है, क्योंकि अपग्रेड की संभावना के लिहाज़ से उनका अर्थ बहुत अलग है:

• कॉन्फ़िगरेशन (सेटिंग्स): निर्माता द्वारा पहले से दिए गए विकल्पों का, बिना प्रोग्रामिंग के, उपयोग (कार्यप्रवाह, स्वीकृति के स्तर, फ़ील्ड, फ़ॉर्म, अनुमतियाँ)।
• विस्तार (extension): निर्माता द्वारा समर्थित, प्रलेखित विस्तार बिंदुओं और इंटरफ़ेस के ज़रिए नई सुविधा, उत्पाद के अपने कोड में बदलाव किए बिना।
• संशोधन (कोर का अनुकूलन): निर्माता के अपने कोड या ऑब्जेक्ट को दोबारा लिखना, या उनकी कॉपी बनाकर उसे दोबारा लिखना। इससे सबसे ज़्यादा आज़ादी मिलती है, लेकिन निर्माताओं के अपने दस्तावेज़ीकरण के अनुसार अपग्रेड के समय इसी में सबसे ज़्यादा जोखिम होता है (नीचे देखें)।

कस्टम ERP

सिस्टम कंपनी की अपनी प्रक्रियाओं और डेटा मॉडल पर बनता है, और सिर्फ़ वही बनता है जिसकी सचमुच ज़रूरत है। निर्माता का कोई कोर नहीं है जिसे अपग्रेड करना पड़े, और आगे के विकास का फ़ैसला ग्राहक करता है। बदले में विकास, संचालन और रखरखाव की व्यवस्था भी करनी होती है, चाहे अपनी टीम के साथ या अनुबंधित डेवलपर के साथ। कस्टम और रेडीमेड सॉफ़्टवेयर के बीच के सामान्य आकलन के बारे में कस्टम सॉफ़्टवेयर या रेडीमेड समाधान (SaaS)? लेख बताता है।

ज़्यादा अनुकूलन अपग्रेड को कठिन क्यों बनाता है?

रेडीमेड ERP का निर्माता नियमित रूप से सुधार और नए संस्करण जारी करता है। अगर कंपनी ने निर्माता के कोड में बदलाव किया है, तो हर अपग्रेड पर जाँचना पड़ता है कि वह बदलाव अब भी काम करता है या नहीं, और अक्सर उसे दोबारा लिखना भी पड़ता है। बड़े निर्माताओं का अपना दस्तावेज़ीकरण भी इसी निष्कर्ष पर पहुँचता है:

• SAP: “clean core” (साफ़ कोर) दृष्टिकोण के अनुसार विस्तारों को SAP ऐप्लिकेशन से सख़्ती से अलग रखा जाना चाहिए, और उन्हें अच्छी तरह परिभाषित, अपग्रेड-स्थिर इंटरफ़ेस का उपयोग करना चाहिए; निर्माता अपने ऑब्जेक्ट में सीधे बदलाव करने या उनकी कॉपी बनाने को ज़्यादा समस्याजनक मानता है, क्योंकि इसके लिए हर पैच या अपग्रेड के बाद गहन पुनः-परीक्षण की ज़रूरत पड़ सकती है (SAP Learning: Introducing the Clean Core Approach)।
• Microsoft Dynamics 365: Finance, Supply Chain और Commerce उत्पादों के लिए निर्माता विस्तार-आधारित मॉडल का कारण यह बताता है कि क्लाउड और बार-बार आने वाले अपडेट के लिए कम दख़ल देने वाला अनुकूलन चाहिए, ताकि अपडेट से कस्टम समाधानों पर असर पड़ने की संभावना कम रहे; इन उत्पादों में विस्तार ही अनुकूलन का एकमात्र तरीक़ा है, और ऐप्लिकेशन कोड को ओवरले करना (overlayering) समर्थित नहीं है (Microsoft Learn: Extensibility home page)।
• Odoo: दस्तावेज़ीकरण के अनुसार, कस्टम मॉड्यूल वाले डेटाबेस को तब तक अपग्रेड नहीं किया जा सकता, जब तक कस्टम मॉड्यूल लक्ष्य संस्करण के लिए तैयार न हो जाएँ, और संगतता की ज़िम्मेदारी कस्टम मॉड्यूल का रखरखाव करने वाले की है (Odoo: Upgrade)।

SAP और Microsoft के मामले में सबक एक ही है: कोर अछूता रहे, और कंपनी में जो अनोखा है, वह अलग किए जा सकने वाले विस्तार में या अलग मॉड्यूल में रहे, जो प्रलेखित इंटरफ़ेस के ज़रिए रेडीमेड सिस्टम से बात करे; और Odoo में कस्टम मॉड्यूलों का रखरखाव तय करता है कि सिस्टम कब अपग्रेड किया जा सकता है। अगर ज़रूरी अनोखापन इतना बड़ा है कि इसे साफ़ तरीक़े से हल करना संभव नहीं रहता, तो यह कस्टम ERP या कस्टम मॉड्यूल के पक्ष में एक मज़बूत संकेत है।

हंगरी की विशेषताएँ: NAV Online Számla, इनवॉइसिंग, बैंक, वेबशॉप

किसी हंगेरियन कंपनी के ERP को हंगरी के सिस्टमों के साथ भी काम करना होता है। सबसे महत्वपूर्ण NAV Online Számla है, जो हंगरी के कर प्राधिकरण (NAV) की ऑनलाइन इनवॉइस डेटा रिपोर्टिंग प्रणाली है: NAV की जानकारी के अनुसार, 4 जनवरी 2021 से हर उस इनवॉइस, संशोधन इनवॉइस और निरस्तीकरण इनवॉइस का डेटा भेजना अनिवार्य है, जिस पर हंगरी के VAT क़ानून के इनवॉइसिंग नियम लागू होते हैं (NAV: Online Számla)।

सिस्टमों के बीच जुड़ाव (मशीन इंटरफ़ेस) का समर्थित संस्करण 3.0 है (17 अक्टूबर 2026 को जाँचा गया)। इंटरफ़ेस विनिर्देश के अनुसार इनवॉइसिंग प्रोग्राम को डेटा रिपोर्टिंग स्वचालित रूप से, प्रक्रिया के भीतर अलग मानवीय हस्तक्षेप के बिना पूरी करनी होती है; NAV भेजे गए डेटा को एसिंक्रोनस तरीक़े से संसाधित करता है, और डेटा रिपोर्टिंग तब तक पूरी नहीं मानी जाती, जब तक प्रोग्राम ने प्रसंस्करण की सफलता की पुष्टि न कर ली हो, और इनवॉइस से जुड़ा रसीद संदेश प्राप्त न कर लिया हो (NAV Online Számla: दस्तावेज़ीकरण)। NAV समय-समय पर विनिर्देश में संशोधन करता है (अगस्त 2026 में भी उसने एक संशोधित संस्करण प्रकाशित किया था), इसलिए इस जुड़ाव का रखरखाव करना पड़ता है।

एक हंगेरियन ERP को आमतौर पर क्या करना आना चाहिए, और हम क्या जोड़ते हैं:

• NAV Online Számla: मशीन इंटरफ़ेस के ज़रिए इनवॉइस डेटा भेजना, प्रसंस्करण के नतीजे की जानकारी लेना और त्रुटियों को सँभालना।
• इनवॉइसिंग सेवाएँ: अगर इनवॉइसिंग किसी बाहरी इनवॉइसिंग सेवा में ही रहती है, तो उसके इंटरफ़ेस के ज़रिए जुड़ाव।
• बैंक: बैंक स्टेटमेंट और लेन-देन पढ़ना, और जमा राशियों का इनवॉइस से मिलान।
• वेबशॉप: वेबशॉप और ERP के बीच ऑर्डर, स्टॉक और क़ीमतों का सिंक्रनाइज़ेशन।
• कूरियर सेवाएँ और अन्य सिस्टम: पार्सल भेजना, मौजूदा CRM, ई-मेल और कैलेंडर।

रेडीमेड ERP चुनते समय यह पूछना उचित है कि क्या उत्पाद का हंगेरियन स्थानीयकरण है, विनिर्देश बदलने पर NAV जुड़ाव का रखरखाव कौन करता है, और हंगरी के बैंकों और इनवॉइसिंग सेवाओं से जुड़ाव कैसा है। कस्टम ERP में यही जुड़ाव विकास का हिस्सा होते हैं। सिस्टमों को जोड़ने के बारे में हम प्रक्रिया स्वचालन पृष्ठ पर विस्तार से लिखते हैं।

निर्णय तालिका

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

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

पुराने सिस्टम से बदलाव

कोई ERP प्रोजेक्ट शायद ही कभी कोरे काग़ज़ से शुरू होता है: कोई पुराना प्रोग्राम, कोई रेडीमेड सिस्टम या स्प्रेडशीट का कोई ढाँचा होता है, जिसमें वर्षों का डेटा रहता है। बदलाव के चरण:

1. आकलन: कौन-से डेटा, प्रक्रियाएँ और कनेक्शन मौजूद हैं, और आज क्या स्प्रेडशीट में, सिस्टम के बाहर चलता है।
2. डेटा सूची और डेटा की सफ़ाई: डुप्लिकेट ग्राहकों, अधूरे आइटम मास्टर और पुरानी पड़ चुकी प्रविष्टियों को स्थानांतरण से पहले ही ठीक करना।
3. डेटा मैपिंग: हर पुराना फ़ील्ड नए सिस्टम में कहाँ जाएगा, और पुरानी, बंद प्रविष्टियों का क्या होगा।
4. परीक्षण स्थानांतरण: पुराना डेटा एक परीक्षण वातावरण में जाता है, जहाँ मुख्य उपयोगकर्ता असली मामलों पर उसकी जाँच करते हैं।
5. चरणों में लाइव करना: मॉड्यूल-दर-मॉड्यूल या एक-एक साइट करके, ज़रूरत हो तो पुराने और नए सिस्टम को थोड़े समय तक साथ-साथ चलाकर, ताकि रोज़ का काम न रुके।
6. बाद की देखरेख: लाइव होने के बाद बग सुधार, अतिरिक्त प्रशिक्षण और संचालन।

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

जोखिम और उन्हें कम करना

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

ERP में कृत्रिम बुद्धिमत्ता कहाँ मदद करती है?

बड़े भाषा मॉडल (OpenAI का ChatGPT, Anthropic का Claude और Google का Gemini) वहाँ उपयोगी हैं जहाँ अब तक कोई व्यक्ति पढ़ता, कॉपी करता या लिखता था:

• दस्तावेज़: आने वाले इनवॉइस, डिलीवरी नोट और ऑर्डर से डेटा पढ़ना, और उसे जाँच के लिए तैयार करके दर्ज करना।
• ई-मेल: आने वाले ऑर्डर ई-मेल को संसाधित करना और जवाब का मसौदा तैयार करना।
• डेटा से सवाल: सिस्टम से आम बोलचाल की भाषा में सवाल, जैसे यह कि किन ग्राहकों के इनवॉइस की भुगतान तिथि निकल चुकी है।
• असामान्यताओं की सूचना: असामान्य प्रविष्टियों को, जैसे कोई ऐसा ऑर्डर जो ग्राहक के पिछले ऑर्डरों से बहुत अलग हो, जाँच के लिए चिह्नित करना।

जहाँ ग़लती महँगी पड़ती है, वहाँ AI सुझाव देता है और कोई व्यक्ति उसे स्वीकृति देता है। मॉडलों को जोड़ने और डेटा संरक्षण के बारे में हम AI एकीकरण पृष्ठ पर लिखते हैं।

हमारा अनुभव

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

अक्सर पूछे जाने वाले प्रश्न

कस्टम ERP विकसित करना कब फ़ायदेमंद है?

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

किसी रेडीमेड ERP को कितना अनुकूलित किया जा सकता है?

कई तरीक़ों से, लेकिन यह मायने रखता है कि कैसे। सेटिंग्स (कॉन्फ़िगरेशन) और निर्माता द्वारा समर्थित विस्तार बिंदु अपग्रेड पर कम असर डालते हैं; जबकि निर्माता के कोड में बदलाव हर अपग्रेड पर नया काम खड़ा कर सकता है। बड़े निर्माताओं (SAP और Microsoft) का दस्तावेज़ीकरण कोर को अछूता छोड़ने और अलग रखे गए विस्तार की सलाह देता है; Odoo के दस्तावेज़ीकरण के अनुसार कस्टम मॉड्यूलों का रखरखाव अपग्रेड की शर्त है।

ज़्यादा अनुकूलन का जोखिम क्या है?

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

पुराने सिस्टम से बदलाव कैसे होता है?

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

क्या आप NAV Online Számla को जोड़ते हैं?

हाँ। इनवॉइस डेटा हम NAV के मशीन इंटरफ़ेस के ज़रिए भेजते हैं, प्रसंस्करण के नतीजे की जानकारी लेते हैं, और त्रुटियों को उसी तरह सँभालते हैं जैसा NAV का इंटरफ़ेस विनिर्देश निर्धारित करता है। इसी तरह हम बाहरी इनवॉइसिंग सेवाओं, बैंकों और वेबशॉप को भी जोड़ते हैं।

हम कैसे मदद करते हैं?

Mesterséges Intelligencia Központ Kft. कस्टम ERP, CRM और बैक-ऑफ़िस सिस्टम विकसित करती है, रेडीमेड सिस्टमों के लिए कस्टम मॉड्यूल और एकीकरण बनाती है, और उन्हें कृत्रिम बुद्धिमत्ता से जोड़ती है। पहला परामर्श निःशुल्क है, और अगर कोई रेडीमेड ERP काफ़ी हो, तो यह भी हम बता देते हैं। हम विकास के कार्यात्मक आकार को COSMIC फ़ंक्शन पॉइंट (ISO/IEC 19761) में मापते हैं, और इसी से प्रस्ताव और समय-सारिणी बनती है; यह पद्धति मूल्य निर्धारण पृष्ठ पर बताई गई है। अनुरोध पर हम गोपनीयता समझौता (NDA) करते हैं, और हस्तांतरण के बाद हम संचालन और रखरखाव की ज़िम्मेदारी भी लेते हैं। सोर्स कोड और उपयोग के अधिकार अनुबंध में तय होते हैं।

विवरण व्यावसायिक सॉफ़्टवेयर पृष्ठ पर है। अगर आप अपने सिस्टम के बारे में हमसे बात करना चाहें, तो संपर्क पृष्ठ पर दिए गए विवरणों पर हमें लिखें।

स्रोत

• Microsoft: What is ERP?
• SAP Learning: Introducing the Clean Core Approach
• Microsoft Learn: Extensibility home page (Finance and Operations)
• Odoo: Upgrade (Odoo 19.0 दस्तावेज़ीकरण)
• NAV Online Számla: मुखपृष्ठ
• NAV Online Számla: दस्तावेज़ीकरण (इंटरफ़ेस विनिर्देश 3.0)