The Complete Guide to Power BI + Odoo Integration

Connect Power BI to Odoo ERP for advanced analytics. PostgreSQL direct queries, key tables, sales/inventory/HR dashboards, and incremental refresh setup.

E
ECOSIRE Research and Development Team
|17 मार्च 202629 मिनट पढ़ें6.5k शब्द|

हमारी Data Analytics & BI श्रृंखला का हिस्सा

पूरी गाइड पढ़ें

पावर बीआई + ओडू इंटीग्रेशन के लिए संपूर्ण गाइड

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

कारण सीधा है: Odoo की अपनी अंतर्निहित रिपोर्टिंग है, और अधिकांश Power BI परामर्शदाता Microsoft Dynamics, SAP, या Salesforce एकीकरण पर ध्यान केंद्रित करते हैं। बहुत कम कंपनियों के पास दोनों प्लेटफार्मों में गहरी विशेषज्ञता है। ECOSIRE में, हमने 43 से अधिक Odoo मॉड्यूल बनाए और तैनात किए हैं और गहरी Power BI विशेषज्ञता बनाए रखी है, जिससे Odoo + Power BI संयोजन हमारी मुख्य विशेषज्ञताओं में से एक बन गया है। यह मार्गदर्शिका वास्तविक दुनिया के दर्जनों एकीकरणों से हमने जो कुछ भी सीखा है, उसे उजागर करती है।


मुख्य बातें

  • Odoo के PostgreSQL डेटाबेस को मूल PostgreSQL कनेक्टर का उपयोग करके सीधे Power BI डेस्कटॉप से जोड़ा जा सकता है, जिससे आपको प्रत्येक तालिका और फ़ील्ड तक पूर्ण पहुंच मिलती है।
  • एनालिटिक्स के लिए पांच सबसे मूल्यवान ओडू टेबल हैं सेल_ऑर्डर, अकाउंट_मूव, स्टॉक_पिकिंग, एचआर_कर्मचारी, और एमआरपी_प्रोडक्शन --- साथ में वे 80 प्रतिशत कार्यकारी रिपोर्टिंग जरूरतों को कवर करते हैं
  • पावर बीआई में वृद्धिशील रिफ्रेश केवल अंतिम रिफ्रेश के बाद बदले गए रिकॉर्ड को लाकर ओडू डेटा लोड समय को घंटों से मिनटों तक कम कर सकता है
  • ओडाटा एंडपॉइंट और ओडू का बाहरी एपीआई सीधे डेटाबेस एक्सेस अनुपलब्ध होने पर क्लाउड-अनुकूल विकल्प प्रदान करता है
  • पावर बीआई में पंक्ति-स्तरीय सुरक्षा ओडू के मल्टी-कंपनी एक्सेस नियंत्रणों को प्रतिबिंबित कर सकती है, जिससे यह सुनिश्चित होता है कि उपयोगकर्ता केवल अपनी निर्दिष्ट कंपनियों का डेटा देख सकें
  • Odoo के PostgreSQL डेटाबेस के विरुद्ध कस्टम SQL क्वेरीज़ सामान्य तालिका आयात को 5-10x तक बेहतर प्रदर्शन करती हैं क्योंकि आप डेटाबेस स्तर पर फ़िल्टर, जुड़ और एकत्र कर सकते हैं
  • एक अच्छी तरह से डिज़ाइन किया गया Odoo + Power BI परिनियोजन दर्जनों स्प्रेडशीट रिपोर्टों को एकल शासित एनालिटिक्स प्लेटफ़ॉर्म से बदल देता है

क्यों Odoo + Power BI एक शक्तिशाली संयोजन है

ओडू की अंतर्निहित रिपोर्टिंग की सीमाएँ

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

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

दूसरा, ओडू में समय-बुद्धि कार्यों का अभाव है। साल-दर-साल तुलना, रोलिंग औसत, संचयी योग और अवधि-दर-तारीख गणना के लिए कस्टम विकास या मैन्युअल स्प्रेडशीट निर्यात की आवश्यकता होती है।

तीसरा, ओडू के पास शासित डेटा मॉडल की कोई अवधारणा नहीं है। "राजस्व" या "ग्राहक जीवनकाल मूल्य" जैसे मेट्रिक्स के लिए कोई साझा परिभाषा नहीं है। प्रत्येक उपयोगकर्ता अपनी स्वयं की व्याख्या बनाता है, जिससे प्रबंधन बैठकों में परस्पर विरोधी संख्याएँ उत्पन्न होती हैं।

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

पावर बीआई क्या जोड़ता है

पावर बीआई इनमें से प्रत्येक सीमा का समाधान करता है। यह Odoo के PostgreSQL डेटाबेस (या API) से जुड़ता है और सभी मॉड्यूल में एक एकीकृत सिमेंटिक मॉडल बनाता है। DAX सूत्र समय संबंधी बुद्धिमत्ता, सांख्यिकीय कार्य और जटिल व्यावसायिक तर्क प्रदान करते हैं। विज़ुअलाइज़ेशन लाइब्रेरी में 300 से अधिक चार्ट प्रकार शामिल हैं। और पावर बीआई की शासन सुविधाएँ --- कार्यस्थान, पंक्ति-स्तरीय सुरक्षा, समर्थन, संवेदनशीलता लेबल --- एंटरप्राइज़-ग्रेड डेटा प्रबंधन प्रदान करती हैं।

यह संयोजन आपको दैनिक कार्य के लिए ओडू की परिचालन उत्कृष्टता और रणनीतिक निर्णय लेने के लिए पावर बीआई की विश्लेषणात्मक गहराई प्रदान करता है। ऑपरेशन टीमें ओडू में काम करना जारी रखती हैं; अधिकारियों और विश्लेषकों को Power BI डैशबोर्ड मिलते हैं जो स्वचालित रूप से अपडेट होते हैं।


कनेक्शन के तरीके: डायरेक्ट डेटाबेस बनाम एपीआई

Power BI को Odoo से कनेक्ट करने की तीन प्राथमिक विधियाँ हैं। आपके होस्टिंग मॉडल और सुरक्षा आवश्यकताओं के आधार पर प्रत्येक में ट्रेड-ऑफ़ होते हैं।

विधि 1: सीधा पोस्टग्रेएसक्यूएल कनेक्शन

ऑन-प्रिमाइसेस या स्वयं-होस्टेड ओडू परिनियोजन के लिए यह पसंदीदा तरीका है। Odoo सभी डेटा को PostgreSQL में संग्रहीत करता है, और Power BI में एक मूल PostgreSQL कनेक्टर है।

फायदे:

  • सबसे तेज़ क्वेरी प्रदर्शन (कोई एपीआई ओवरहेड नहीं)
  • कस्टम मॉड्यूल सहित प्रत्येक तालिका और फ़ील्ड तक पूर्ण पहुंच
  • डेटाबेस स्तर पर जुड़ाव और एकत्रीकरण के साथ जटिल SQL क्वेरी का समर्थन करता है
  • वृद्धिशील ताज़ा सक्षम बनाता है (डेटाटाइम कॉलम की आवश्यकता है)
  • कोई ओडू लाइसेंस या एपीआई दर सीमा नहीं

सेटअप चरण:

  1. Power BI डेस्कटॉप खोलें और डेटा प्राप्त करें चुनें, फिर PostgreSQL डेटाबेस चुनें
  2. अपना Odoo सर्वर होस्टनाम और डेटाबेस नाम दर्ज करें (आमतौर पर Odoo इंस्टेंस नाम)
  3. केवल पढ़ने योग्य डेटाबेस उपयोगकर्ता का उपयोग करें (ओडू व्यवस्थापक खाता कभी नहीं)
  4. अधिकांश परिदृश्यों के लिए आयात मोड का चयन करें, या वास्तविक समय की जरूरतों के लिए DirectQuery का चयन करें
  5. तालिका सूची पर नेविगेट करें या कस्टम SQL क्वेरी का उपयोग करें

कनेक्शन स्ट्रिंग पैरामीटर:

पैरामीटरविशिष्ट मूल्य
सर्वरyour-odoo-server.com:5432
डेटाबेसodoo_production
उपयोगकर्ता नामPowerbi_readonly
पासवर्ड(प्रमाण-पत्रों में संग्रहीत)
एसएसएल मोडआवश्यकता है (उत्पादन के लिए)
कमांड टाइमआउट600 (सेकंड, बड़े प्रश्नों के लिए)

PostgreSQL में केवल पढ़ने योग्य उपयोगकर्ता बनाना:

CREATE ROLE powerbi_readonly WITH LOGIN PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE odoo_production TO powerbi_readonly;
GRANT USAGE ON SCHEMA public TO powerbi_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO powerbi_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO powerbi_readonly;

यह दृष्टिकोण सुनिश्चित करता है कि पावर बीआई आपके उत्पादन डेटाबेस तक किसी भी लेखन पहुंच के बिना सभी वर्तमान और भविष्य की तालिकाओं को पढ़ सकता है।

विधि 2: ओडू बाहरी एपीआई (एक्सएमएल-आरपीसी / जेएसओएन-आरपीसी)

Odoo डेटा पढ़ने और लिखने के लिए एक पूर्ण एपीआई प्रदर्शित करता है। पावर बीआई कस्टम कनेक्टर्स या पायथन स्क्रिप्ट के माध्यम से इसका उपभोग कर सकता है।

फायदे:

  • Odoo.sh और Odoo ऑनलाइन के साथ काम करता है (कोई प्रत्यक्ष डेटाबेस पहुंच की आवश्यकता नहीं)
  • ओडू के अभिगम नियंत्रण नियमों और रिकॉर्ड नियमों का सम्मान करता है
  • डेटाबेस पोर्ट को बाहरी रूप से उजागर करने की कोई आवश्यकता नहीं है

नुकसान:

  • प्रत्यक्ष डेटाबेस क्वेरीज़ की तुलना में काफी धीमी (बड़े डेटासेट के लिए 10-100x)
  • एपीआई दर सीमाएं उच्च मात्रा वाले अर्क को कम कर सकती हैं
  • एक कस्टम पावर क्वेरी फ़ंक्शन या इंटरमीडिएट ईटीएल चरण की आवश्यकता है
  • पृष्ठांकन जटिलता जोड़ता है

ओडू के JSON-RPC एंडपॉइंट के लिए, एक विशिष्ट पावर क्वेरी एम फ़ंक्शन प्रमाणीकरण के साथ https://your-odoo.com/jsonrpc को कॉल करेगा और फिर परिणामों के माध्यम से पेजिनेट करेगा। यह काम करता है लेकिन 50,000 से अधिक रिकॉर्ड वाली तालिकाओं के लिए अव्यावहारिक हो जाता है।

विधि 3: ओडू कनेक्टर मॉड्यूल के माध्यम से ओडाटा एंडपॉइंट

कई Odoo समुदाय मॉड्यूल OData फ़ीड को उजागर करते हैं जिन्हें Power BI मूल रूप से उपभोग कर सकता है। Power BI में OData कनेक्टर बॉक्स से बाहर प्रमाणीकरण और पेजिनेशन का समर्थन करता है।

इस विधि का उपयोग कब करें:

  • Odoo ऑनलाइन / Odoo.sh परिनियोजन जहां डेटाबेस पहुंच प्रतिबंधित है
  • डेटा में ओडू के व्यावसायिक तर्क (गणना किए गए फ़ील्ड, एक्सेस नियम) की आवश्यकता वाले परिदृश्य
  • छोटे डेटासेट (प्रति इकाई 100,000 से कम रिकॉर्ड)

अधिकांश एंटरप्राइज़ परिनियोजन के लिए, विधि 1 (प्रत्यक्ष PostgreSQL) की पुरजोर अनुशंसा की जाती है। प्रदर्शन अंतर पर्याप्त है, और SQL क्वेरी का लचीलापन आपको स्रोत पर डेटा को आकार देने की अनुमति देता है।


पावर बीआई के लिए आवश्यक ओडू टेबल्स

Odoo के PostgreSQL डेटाबेस में सैकड़ों टेबल हैं। प्रभावी पावर बीआई मॉडल के निर्माण के लिए मुख्य तालिकाओं और उनके संबंधों को समझना महत्वपूर्ण है। नीचे वे तालिकाएँ हैं जो 80 प्रतिशत कार्यकारी डैशबोर्ड को शक्ति प्रदान करती हैं।

बिक्री मॉड्यूल तालिकाएँ

| तालिका | उद्देश्य | प्रमुख क्षेत्र | |-------|--------| | बिक्री_आदेश | बिक्री आदेश (हेडर) | आईडी, नाम, पार्टनर_आईडी, दिनांक_आदेश, कुल राशि, राज्य, कंपनी_आईडी, उपयोगकर्ता_आईडी | | सेल_ऑर्डर_लाइन | विक्रय आदेश पंक्ति वस्तुएँ | ऑर्डर_आईडी, उत्पाद_आईडी, उत्पाद_uom_मात्रा, मूल्य_इकाई, मूल्य_उपयोग, छूट | | res_partner | ग्राहक और विक्रेता | आईडी, नाम, ईमेल, देश_आईडी, श्रेणी_आईडी, ग्राहक_रैंक, आपूर्तिकर्ता_रैंक | | उत्पाद_उत्पाद | उत्पाद प्रकार | आईडी, डिफॉल्ट_कोड, लिस्ट_प्राइस, स्टैंडर्ड_प्राइस, कैटेग_आईडी, सक्रिय | | उत्पाद_टेम्पलेट | उत्पाद टेम्पलेट्स | आईडी, नाम, प्रकार, बिक्री_ठीक, खरीद_ठीक |

मुख्य संबंध: sales_order.partner_id res_partner.id से लिंक करता है। Sale_order_line.product_id product_product.id से लिंक करता है। product_product.product_tmpl_id product_template.id से लिंक करता है।

एक विशिष्ट बिक्री विश्लेषण क्वेरी इन तालिकाओं से जुड़कर एक असामान्य तथ्य तालिका तैयार करती है:

SELECT
  so.id AS order_id,
  so.name AS order_number,
  so.date_order,
  so.state,
  rp.name AS customer_name,
  rp.country_id,
  rc.name AS country_name,
  sol.product_id,
  pt.name AS product_name,
  pc.name AS product_category,
  sol.product_uom_qty AS quantity,
  sol.price_unit,
  sol.discount,
  sol.price_subtotal AS line_total,
  so.amount_total AS order_total,
  ru.login AS salesperson
FROM sale_order so
JOIN sale_order_line sol ON sol.order_id = so.id
JOIN res_partner rp ON so.partner_id = rp.id
LEFT JOIN res_country rc ON rp.country_id = rc.id
JOIN product_product pp ON sol.product_id = pp.id
JOIN product_template pt ON pp.product_tmpl_id = pt.id
LEFT JOIN product_category pc ON pt.categ_id = pc.id
LEFT JOIN res_users ru ON so.user_id = ru.id
WHERE so.state IN ('sale', 'done')
ORDER BY so.date_order DESC;

लेखांकन मॉड्यूल तालिकाएँ

| तालिका | उद्देश्य | प्रमुख क्षेत्र | |-------|--------| | अकाउंट_मूव | चालान, बिल, जर्नल प्रविष्टियाँ | आईडी, नाम, चाल_प्रकार, भागीदार_आईडी, चालान_दिनांक, कुल राशि, राज्य, भुगतान_स्थिति | | अकाउंट_मूव_लाइन | जर्नल प्रविष्टि पंक्तियाँ | move_id, account_id, डेबिट, क्रेडिट, बैलेंस, दिनांक, पार्टनर_id | | खाता_खाता | खातों का चार्ट | आईडी, कोड, नाम, खाता_प्रकार | | खाता_भुगतान | भुगतान | आईडी, पार्टनर_आईडी, राशि, तिथि, राज्य, भुगतान_प्रकार | | अकाउंट_जर्नल | जर्नल (बैंक, बिक्री, आदि) | आईडी, नाम, प्रकार, कोड |

महत्वपूर्ण अंतर: ओडू में, account_move चालान (मूव_टाइप = 'आउट_इनवॉइस'), विक्रेता बिल ('इन_इनवॉइस'), क्रेडिट नोट्स ('आउट_रिफंड', 'इन_रिफंड'), और जर्नल प्रविष्टियां ('एंट्री') संग्रहीत करता है। अपनी Power BI क्वेरीज़ में हमेशा move_type के अनुसार फ़िल्टर करें।

अकाउंट_मूव पर payment_state फ़ील्ड आपको बताती है कि कोई चालान 'भुगतान नहीं किया गया', 'भुगतान में', 'भुगतान किया गया', 'आंशिक' या 'उलटा' है। यह प्राप्य खातों के पुराने डैशबोर्ड के लिए आवश्यक है।

इन्वेंटरी मॉड्यूल टेबल्स

| तालिका | उद्देश्य | प्रमुख क्षेत्र | |-------|--------| | स्टॉक_पिकिंग | वितरण आदेश, रसीदें, आंतरिक स्थानान्तरण | आईडी, नाम, पार्टनर_आईडी, शेड्यूल_डेट, डेट_डन, राज्य, पिकिंग_टाइप_आईडी | | स्टॉक_मूव | व्यक्तिगत उत्पाद चालें | पिकिंग_आईडी, उत्पाद_आईडी, उत्पाद_यूओएम_मात्रा, मात्रा, स्थिति, दिनांक | | स्टॉक_मात्रा | वर्तमान ऑन-हैंड इन्वेंट्री | उत्पाद_आईडी, स्थान_आईडी, मात्रा, आरक्षित_मात्रा | | स्टॉक_स्थान | गोदाम, जोन, डिब्बे | आईडी, नाम, उपयोग, स्थान_आईडी (मूल) | | स्टॉक_गोदाम | गोदाम परिभाषाएँ | आईडी, नाम, कोड, पार्टनर_आईडी |

वास्तविक समय सूची: स्टॉक_क्वांट हमेशा इन्वेंट्री की वर्तमान स्थिति को दर्शाता है। ऐतिहासिक इन्वेंट्री विश्लेषण के लिए, आपको दिनांक फ़िल्टर के साथ स्टॉक_मूव को क्वेरी करना होगा और चल रहे शेष की गणना करनी होगी।

विनिर्माण मॉड्यूल टेबल्स

| तालिका | उद्देश्य | प्रमुख क्षेत्र | |-------|--------| | एमआरपी_प्रोडक्शन | विनिर्माण आदेश | आईडी, नाम, product_id, product_qty, date_start, date_finished, state | | mrp_bom | सामग्री के बिल | आईडी, product_tmpl_id, product_qty, प्रकार | | mrp_bom_line | बीओएम घटक | bom_id, product_id, product_qty | | mrp_वर्कऑर्डर | कार्य आदेश संचालन | उत्पादन_आईडी, कार्यकेंद्र_आईडी, अवधि, स्थिति | | mrp_workcenter | कार्य केंद्र/मशीनें | आईडी, नाम, क्षमता, समय_दक्षता |

OEE गणना: समग्र उपकरण प्रभावशीलता को वास्तविक अवधि के विरुद्ध नियोजित अवधि की तुलना करके, डाउनटाइम कारणों का विश्लेषण करके और गुणवत्ता मेट्रिक्स पर नज़र रखकर mrp_workorder रिकॉर्ड से प्राप्त किया जा सकता है।

मानव संसाधन तालिकाएँ

| तालिका | उद्देश्य | प्रमुख क्षेत्र | |-------|--------| | hr_कर्मचारी | कर्मचारी रिकार्ड | आईडी, नाम, विभाग_आईडी, नौकरी_आईडी, कार्य_ईमेल, सक्रिय | | घंटा_विभाग | विभाग | आईडी, नाम, पेरेंट_आईडी, मैनेजर_आईडी | | घंटा_अनुबंध | रोजगार अनुबंध | कर्मचारी_आईडी, वेतन, दिनांक_प्रारंभ, दिनांक_अंत, राज्य | | घंटा_छोड़ें | समय-अवकाश अनुरोध | कर्मचारी_आईडी, अवकाश_स्थिति_आईडी, दिनांक_से, दिनांक_से, राज्य | | घंटा_उपस्थिति | क्लॉक इन/आउट रिकॉर्ड | कर्मचारी_आईडी, चेक_इन, चेक_आउट, काम के घंटे |


पावर बीआई डेटा मॉडल का निर्माण

स्टार स्कीमा डिज़ाइन

ओडू एनालिटिक्स के लिए सबसे प्रभावी डेटा मॉडल एक स्टार स्कीमा पैटर्न का अनुसरण करता है। तथ्य तालिकाएँ (बिक्री आदेश, चालान, स्टॉक चाल, उत्पादन आदेश) केंद्र में बैठती हैं। आयाम तालिकाएँ (उत्पाद, ग्राहक, तिथियाँ, कर्मचारी, स्थान) उन्हें घेर लेती हैं।

अनुशंसित तथ्य तालिकाएँ:

  1. Fact_Sales - सेल_ऑर्डर + सेल_ऑर्डर_लाइन से (ग्रेन: प्रति ऑर्डर लाइन एक पंक्ति)
  2. Fact_Invoices - अकाउंट_मूव + अकाउंट_मूव_लाइन से (ग्रेन: प्रति जर्नल लाइन एक पंक्ति)
  3. Fact_Inventory - स्टॉक_मूव से (अनाज: प्रति स्टॉक मूवमेंट एक पंक्ति)
  4. Fact_Production - mrp_production + mrp_workorder से (अनाज: प्रति कार्य ऑर्डर एक पंक्ति)
  5. Fact_Attendance - hr_attendance से (ग्रेन: एक पंक्ति प्रति घड़ी इन/आउट जोड़ी)

साझा आयाम तालिकाएँ:

  1. Dim_Date - पावर बीआई में उत्पन्न एक कैलेंडर तालिका (समय की जानकारी के लिए आवश्यक)
  2. Dim_Customer - res_partner से (ग्राहक_रैंक > 0 पर फ़िल्टर किया गया)
  3. Dim_Product — product_product + product_template + product_category से
  4. Dim_Employee - hr_employee + hr_department + hr_job से
  5. Dim_Location — स्टॉक_लोकेशन + स्टॉक_वेयरहाउस से
  6. Dim_Company - res_company से (बहु-कंपनी Odoo परिनियोजन के लिए)

दिनांक आयाम बनाना

Odoo के पास कोई समर्पित दिनांक आयाम तालिका नहीं है। आपको DAX का उपयोग करके Power BI में एक बनाना होगा:

Dim_Date =
ADDCOLUMNS(
    CALENDAR(DATE(2020, 1, 1), DATE(2030, 12, 31)),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "MonthNumber", MONTH([Date]),
    "WeekNumber", WEEKNUM([Date]),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "FiscalYear", IF(MONTH([Date]) >= 4, YEAR([Date]), YEAR([Date]) - 1),
    "FiscalQuarter", "FQ" & SWITCH(TRUE(),
        MONTH([Date]) >= 10, 3,
        MONTH([Date]) >= 7, 2,
        MONTH([Date]) >= 4, 1,
        4
    ),
    "IsWeekend", IF(WEEKDAY([Date], 2) > 5, TRUE(), FALSE()),
    "YearMonth", FORMAT([Date], "YYYY-MM")
)

इस तालिका को Power BI में दिनांक तालिका के रूप में चिह्नित करें और प्रत्येक तथ्य तालिका के दिनांक कॉलम से Dim_Date[Date] तक संबंध बनाएं। अपने संगठन से मेल खाने के लिए वित्तीय वर्ष आरंभ माह को समायोजित करें।

ओडू की मल्टी-कंपनी संरचना को संभालना

ओडू मल्टी-कंपनी कॉन्फ़िगरेशन का समर्थन करता है जहां एक एकल डेटाबेस कई कानूनी संस्थाओं को सेवा प्रदान करता है। प्रत्येक लेनदेन तालिका में एक company_id विदेशी कुंजी शामिल होती है। Power BI में, res_company से एक Dim_Company तालिका बनाएं और प्रत्येक तथ्य तालिका से संबंध स्थापित करें।

पंक्ति-स्तरीय सुरक्षा के लिए, लॉग-इन उपयोगकर्ता के कंपनी असाइनमेंट के आधार पर Dim_Company को फ़िल्टर करने के लिए Power BI की RLS सुविधा का उपयोग करें। यह बीआई परत में ओडू के मल्टी-कंपनी एक्सेस नियंत्रण को प्रतिबिंबित करता है।


डैशबोर्ड रेसिपी: सेल्स एनालिटिक्स

कार्यकारी बिक्री डैशबोर्ड

यह डैशबोर्ड उन पांच सवालों के जवाब देता है जो हर सीईओ पूछता है: इस महीने कितना राजस्व? क्या हम तिमाही के लिए सही रास्ते पर हैं? कौन से उत्पाद जीत रहे हैं? कौन से विक्रेता प्रदर्शन कर रहे हैं? हमारे ग्राहक कहाँ हैं?

बनाने के उपाय:

Total Revenue = SUM(Fact_Sales[line_total])

Revenue MTD =
TOTALMTD([Total Revenue], Dim_Date[Date])

Revenue QTD =
TOTALQTD([Total Revenue], Dim_Date[Date])

Revenue YTD =
TOTALYTD([Total Revenue], Dim_Date[Date])

Revenue PY =
CALCULATE([Total Revenue], SAMEPERIODLASTYEAR(Dim_Date[Date]))

Revenue Growth % =
DIVIDE([Total Revenue] - [Revenue PY], [Revenue PY], 0)

Average Order Value =
DIVIDE([Total Revenue], DISTINCTCOUNT(Fact_Sales[order_id]))

Orders Count =
DISTINCTCOUNT(Fact_Sales[order_id])

दृश्य लेआउट:

  • पंक्ति 1: चार KPI कार्ड (राजस्व MTD, राजस्व QTD, राजस्व YTD, विकास%)
  • पंक्ति 2: लाइन चार्ट (मासिक राजस्व, चालू वर्ष बनाम पिछले वर्ष) और बार चार्ट (उत्पाद श्रेणी के अनुसार राजस्व)
  • पंक्ति 3: मानचित्र दृश्य (ग्राहक देश के अनुसार राजस्व) और तालिका (राजस्व, ऑर्डर संख्या, औसत डील आकार के साथ शीर्ष 10 विक्रेता)
  • पंक्ति 4: झरना चार्ट (राजस्व पुल: नए ग्राहक बनाम मौजूदा बनाम खोए हुए) और डोनट चार्ट (बिक्री चैनल द्वारा राजस्व)

बिक्री पाइपलाइन विश्लेषण

यदि आप सेल्स मॉड्यूल के साथ ओडू सीआरएम का उपयोग करते हैं, तो पाइपलाइन डैशबोर्ड बनाने के लिए crm_lead तालिका कनेक्ट करें:

| तालिका | उद्देश्य | प्रमुख क्षेत्र | |-------|--------| | सीआरएम_लीड | अवसर और नेतृत्व | आईडी, नाम, पार्टनर_आईडी, अपेक्षित_राजस्व, संभाव्यता, स्टेज_आईडी, उपयोगकर्ता_आईडी, दिनांक_डेडलाइन | | सीआरएम_स्टेज | पाइपलाइन चरण | आईडी, नाम, क्रम |

पाइपलाइन उपाय:

Pipeline Value =
SUMX(
    FILTER(Fact_Pipeline, Fact_Pipeline[active] = TRUE()),
    Fact_Pipeline[expected_revenue] * Fact_Pipeline[probability] / 100
)

Win Rate =
DIVIDE(
    CALCULATE(COUNTROWS(Fact_Pipeline), Fact_Pipeline[stage_name] = "Won"),
    CALCULATE(COUNTROWS(Fact_Pipeline),
        OR(Fact_Pipeline[stage_name] = "Won", Fact_Pipeline[stage_name] = "Lost")
    )
)

Average Sales Cycle Days =
AVERAGEX(
    FILTER(Fact_Pipeline, Fact_Pipeline[stage_name] = "Won"),
    DATEDIFF(Fact_Pipeline[create_date], Fact_Pipeline[date_closed], DAY)
)

डैशबोर्ड रेसिपी: इन्वेंटरी और आपूर्ति श्रृंखला

इन्वेंटरी हेल्थ डैशबोर्ड

यह डैशबोर्ड स्टॉक स्तर, टर्नओवर दर और आपूर्ति श्रृंखला प्रदर्शन पर नज़र रखता है।

मुख्य उपाय:

Inventory Value =
SUMX(Fact_Inventory_Current, Fact_Inventory_Current[quantity] * RELATED(Dim_Product[standard_price]))

Inventory Turnover =
DIVIDE(
    [COGS Trailing 12 Months],
    [Average Inventory Value]
)

Days of Inventory =
DIVIDE(365, [Inventory Turnover])

Stockout Rate =
DIVIDE(
    CALCULATE(COUNTROWS(Dim_Product), Dim_Product[on_hand_qty] <= 0, Dim_Product[active] = TRUE()),
    CALCULATE(COUNTROWS(Dim_Product), Dim_Product[active] = TRUE())
)

Reorder Point Items =
CALCULATE(
    COUNTROWS(Dim_Product),
    FILTER(Dim_Product, Dim_Product[on_hand_qty] <= Dim_Product[reorder_min])
)

दृश्य:

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

डिलिवरी प्रदर्शन

stock_picking से, समय पर डिलीवरी मापें:

On-Time Delivery Rate =
DIVIDE(
    CALCULATE(
        COUNTROWS(Fact_Deliveries),
        Fact_Deliveries[date_done] <= Fact_Deliveries[scheduled_date]
    ),
    COUNTROWS(Fact_Deliveries)
)

Average Lead Time Days =
AVERAGEX(
    Fact_Deliveries,
    DATEDIFF(Fact_Deliveries[create_date], Fact_Deliveries[date_done], DAY)
)

डैशबोर्ड रेसिपी: विनिर्माण

उत्पादन प्रदर्शन डैशबोर्ड

ओडू मैन्युफैक्चरिंग चलाने वाले निर्माताओं के लिए, mrp_production और mrp_workorder तालिकाएँ समृद्ध परिचालन डेटा प्रदान करती हैं।

OEE (समग्र उपकरण प्रभावशीलता) गणना:

Availability =
DIVIDE(
    [Actual Production Time],
    [Planned Production Time]
)

Performance Rate =
DIVIDE(
    [Ideal Cycle Time] * [Total Units Produced],
    [Actual Production Time]
)

Quality Rate =
DIVIDE(
    [Good Units],
    [Total Units Produced]
)

OEE = [Availability] * [Performance Rate] * [Quality Rate]

दृश्य:

  • गेज चार्ट: ओईई, उपलब्धता, प्रदर्शन, गुणवत्ता (प्रत्येक लक्ष्य सीमा के साथ: हरा 85% से ऊपर, पीला 60-85%, लाल 60% से नीचे)
  • लाइन चार्ट: नियंत्रण सीमा के साथ सप्ताह के अनुसार ओईई प्रवृत्ति
  • क्लस्टर्ड बार चार्ट: कार्य केंद्र द्वारा ओईई, यह बताता है कि कौन सी मशीनें खराब प्रदर्शन करती हैं
  • तालिका: नियोजित बनाम वास्तविक अवधि, भिन्नता और स्क्रैप मात्रा के साथ उत्पादन आदेश

कार्य केंद्र उपयोग

Utilization Rate =
DIVIDE(
    SUM(Fact_WorkOrders[duration_minutes]),
    [Available Minutes Per Period]
)

Downtime Hours =
DIVIDE(
    [Available Minutes Per Period] - SUM(Fact_WorkOrders[duration_minutes]),
    60
)

यह डैशबोर्ड उत्पादन प्रबंधकों को बाधा कार्य केंद्रों की पहचान करने और शेड्यूलिंग को अनुकूलित करने में मदद करता है। ओडू के नियोजन मॉड्यूल डेटा के साथ संयुक्त होने पर, आप क्षमता नियोजन मॉडल बना सकते हैं जो पूर्वानुमान लगाते हैं कि आप अधिकतम उपयोग कब तक पहुंचेंगे।


डैशबोर्ड रेसिपी: मानव संसाधन और कार्यबल

कार्यबल विश्लेषण डैशबोर्ड

ओडू डेटा से निर्मित एचआर डैशबोर्ड ऐसी अंतर्दृष्टि प्रदान करते हैं जिसके लिए अधिकांश एचआरआईएस सिस्टम प्रीमियम मूल्य वसूलते हैं।

कुल संख्या और टर्नओवर उपाय:

Active Employees =
CALCULATE(
    COUNTROWS(Dim_Employee),
    Dim_Employee[active] = TRUE()
)

Attrition Rate =
DIVIDE(
    CALCULATE(
        COUNTROWS(Dim_Employee),
        Dim_Employee[departure_date] <> BLANK(),
        YEAR(Dim_Employee[departure_date]) = YEAR(TODAY())
    ),
    [Average Headcount],
    0
)

Average Tenure Years =
AVERAGEX(
    FILTER(Dim_Employee, Dim_Employee[active] = TRUE()),
    DATEDIFF(Dim_Employee[contract_start_date], TODAY(), DAY) / 365.25
)

Cost Per Employee =
DIVIDE(
    SUM(Fact_Payroll[total_cost]),
    [Active Employees]
)

hr_leave से अनुपस्थिति विश्लेषण:

Absence Rate =
DIVIDE(
    SUM(Fact_Leaves[number_of_days]),
    [Working Days In Period] * [Active Employees]
)

Bradford Factor =
SUMX(
    Dim_Employee,
    VAR AbsenceSpells = CALCULATE(COUNTROWS(Fact_Leaves), Fact_Leaves[state] = "validate")
    VAR TotalDays = CALCULATE(SUM(Fact_Leaves[number_of_days]), Fact_Leaves[state] = "validate")
    RETURN AbsenceSpells * AbsenceSpells * TotalDays
)

hr_attendance से उपस्थिति विश्लेषण:

Average Daily Hours =
AVERAGEX(
    VALUES(Dim_Date[Date]),
    CALCULATE(SUM(Fact_Attendance[worked_hours]))
)

Overtime Hours =
SUMX(
    Fact_Attendance,
    IF(Fact_Attendance[worked_hours] > 8, Fact_Attendance[worked_hours] - 8, 0)
)

वृद्धिशील ताज़ा कॉन्फ़िगरेशन

लाखों रिकॉर्ड वाले Odoo डेटाबेस के लिए, पूर्ण डेटा रिफ्रेश अव्यावहारिक है। पावर बीआई की वृद्धिशील रिफ्रेश सुविधा केवल नए और बदले हुए रिकॉर्ड को लोड करती है, जिससे रिफ्रेश समय घंटों से मिनटों में कम हो जाता है।

पूर्वावश्यकताएँ

  • पावर बीआई प्रो या प्रीमियम लाइसेंस
  • प्रत्येक तालिका में एक विश्वसनीय डेटाटाइम कॉलम होना चाहिए (ओडू में राइट_डेट आदर्श है --- जब भी कोई रिकॉर्ड संशोधित होता है तो यह अपडेट हो जाता है)
  • डेटा स्रोत को क्वेरी फोल्डिंग का समर्थन करना चाहिए (PostgreSQL करता है)

कॉन्फ़िगरेशन चरण

चरण 1: रेंजस्टार्ट और रेंजएंड पैरामीटर बनाएं

पावर क्वेरी में, DateTime प्रकार के दो पैरामीटर बनाएं:

  • रेंजस्टार्ट: डिफ़ॉल्ट मान = 1/1/2020 12:00:00 पूर्वाह्न
  • रेंजएंड: डिफ़ॉल्ट मान = 12/31/2030 12:00:00 पूर्वाह्न

चरण 2: मापदंडों के आधार पर तालिकाओं को फ़िल्टर करें

प्रत्येक तथ्य तालिका के लिए, पावर क्वेरी में एक फ़िल्टर चरण जोड़ें:

= Table.SelectRows(Source, each [write_date] >= RangeStart and [write_date] < RangeEnd)

यह फ़िल्टर डेटाबेस में फ़ोल्ड होना चाहिए (जेनरेट किए गए SQL में दिखाई देना चाहिए)। चरण पर राइट-क्लिक करके और "मूल क्वेरी देखें" का चयन करके सत्यापित करें।

चरण 3: वृद्धिशील ताज़ा नीति को परिभाषित करें

मॉडल में तालिका पर राइट-क्लिक करें, इंक्रीमेंटल रिफ्रेश चुनें और कॉन्फ़िगर करें:

| सेटिंग | अनुशंसित मूल्य | |------|-------------------|| | पंक्तियों को अंतिम में संग्रहित करें | 3 वर्ष | | अंतिम पंक्तियाँ ताज़ा करें | 7 दिन | | डेटा परिवर्तन का पता लगाएं | राइट_डेट कॉलम | | केवल पूर्ण अवधियों को ताज़ा करें | सक्षम |

यह कॉन्फ़िगरेशन तीन वर्षों का इतिहास संग्रहीत करता है लेकिन प्रत्येक निर्धारित रिफ्रेश के दौरान केवल अंतिम सात दिनों को रिफ्रेश करता है। जब रिकॉर्ड पर कोई फ़ील्ड बदलता है तो Odoo का write_date कॉलम स्वचालित रूप से अपडेट हो जाता है, जिससे यह एक विश्वसनीय परिवर्तन-पहचान कॉलम बन जाता है।

प्रदर्शन प्रभाव

परिदृश्यपूर्ण ताज़ावृद्धिशील ताज़ा
1M बिक्री ऑर्डर लाइनें12 मिनट45 सेकंड
5M जर्नल प्रविष्टियाँ38 मिनट2 मिनट
10M स्टॉक चालें65 मिनट4 मिनट

प्रदर्शन लाभ नाटकीय है, विशेष रूप से विनिर्माण और इन्वेंट्री डेटासेट के लिए जो उच्च मात्रा में लेनदेन संबंधी डेटा उत्पन्न करते हैं।


उन्नत: बहु-कंपनी और बहु-मुद्रा

मल्टी-कंपनी ओडू तैनाती को संभालना

कई ओडू एंटरप्राइज परिनियोजन एक ही डेटाबेस से कई कानूनी संस्थाओं को सेवा प्रदान करते हैं। प्रत्येक लेन-देन रिकॉर्ड में एक company_id फ़ील्ड होता है। पावर बीआई में:

  1. res_company से एक Dim_Company तालिका बनाएं
  2. प्रत्येक तथ्य तालिका की कंपनी_आईडी से Dim_Company तक संबंध स्थापित करें
  3. प्रत्येक डैशबोर्ड पृष्ठ पर एक कंपनी स्लाइसर जोड़ें
  4. पंक्ति-स्तरीय सुरक्षा लागू करें ताकि प्रत्येक उपयोगकर्ता केवल अपनी कंपनी का डेटा देख सके

मुद्रा रूपांतरण

Odoo कंपनी की आधार मुद्रा में राशि संग्रहीत करता है। बहु-मुद्रा रिपोर्टिंग के लिए, res_currency_rate तालिका में शामिल हों:

SELECT
  so.id,
  so.amount_total AS amount_local,
  so.amount_total / COALESCE(
    (SELECT rate FROM res_currency_rate
     WHERE currency_id = so.currency_id
     AND name <= so.date_order::date
     ORDER BY name DESC LIMIT 1),
    1
  ) AS amount_usd
FROM sale_order so;

वैकल्पिक रूप से, दैनिक विनिमय दरों के साथ Power BI में एक Dim_Currency_Rate तालिका बनाए रखें और रिपोर्ट समय पर कनवर्ट करने के लिए DAX का उपयोग करें। यह दृष्टिकोण क्या होगा-अगर परिदृश्यों के लिए अधिक लचीला है (उदाहरण के लिए, "पिछले वर्ष की विनिमय दरों पर राजस्व कैसा दिखेगा?")।


ओडू ऑनलाइन के लिए ओडाटा और रेस्ट एपीआई एकीकरण

Odoo Online या Odoo.sh का उपयोग करने वाले संगठनों के लिए जहां सीधे PostgreSQL पहुंच उपलब्ध नहीं है, वहां वैकल्पिक कनेक्शन विधियां हैं।

Odoo के JSON-RPC API का उपयोग करना

Odoo /jsonrpc (या /xmlrpc/2 पर पुराने XML-RPC) पर JSON-RPC समापन बिंदु को उजागर करता है। डेटा लाने के लिए आप search_read विधि को कॉल कर सकते हैं:

{
  "jsonrpc": "2.0",
  "method": "call",
  "params": {
    "service": "object",
    "method": "execute_kw",
    "args": [
      "your_database",
      2,
      "your_api_key",
      "sale.order",
      "search_read",
      [[["state", "in", ["sale", "done"]]]],
      {"fields": ["name", "partner_id", "date_order", "amount_total", "state"],
       "limit": 1000, "offset": 0}
    ]
  }
}

Power BI में, आप इसे पेजिनेशन लॉजिक के साथ Web.Contents का उपयोग करके एक कस्टम पावर क्वेरी फ़ंक्शन के रूप में कार्यान्वित करेंगे। चुनौती प्रदर्शन है: प्रत्येक एपीआई कॉल अधिकतम कुछ हजार रिकॉर्ड लौटाती है, और आपको बड़े डेटासेट के लिए कई राउंड-ट्रिप की आवश्यकता होती है।

सामुदायिक ओडाटा मॉड्यूल

कई Odoo समुदाय मॉड्यूल OData समापनबिंदु जोड़ते हैं:

  • ओडू के लिए बीआई कनेक्टर - कॉन्फ़िगर करने योग्य ओडेटा फ़ीड को उजागर करता है
  • ओडू-पावर बीआई कनेक्टर - सामान्य मॉड्यूल के लिए पूर्व-निर्मित डेटा मॉडल

ये मॉड्यूल एकीकरण को सरल बनाते हैं लेकिन आपके Odoo उदाहरण में एक निर्भरता जोड़ते हैं। मूल्यांकन करें कि क्या सुविधा सामुदायिक मॉड्यूल के रखरखाव के बोझ से अधिक है।

हाइब्रिड दृष्टिकोण: अनुसूचित डेटा निर्यात

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

यह दृष्टिकोण उन संगठनों के लिए अच्छा काम करता है जो पावर बीआई प्रश्नों के लिए ओडू के उत्पादन डेटाबेस को उजागर किए बिना लगभग दैनिक डेटा ताज़ाता चाहते हैं।


वास्तविक दुनिया केपीआई उदाहरण

यहां बीस KPI हैं जिन्हें ECOSIRE ग्राहक विभाग द्वारा आयोजित, Odoo को Power BI से जोड़ने के बाद अक्सर बनाते हैं।

वित्त KPI

  1. दिनों की बिक्री बकाया (डीएसओ) - अकाउंट_मूव से भुगतान एकत्र करने के औसत दिन (चालान तिथि बनाम भुगतान तिथि)
  2. सकल मार्जिन % - बिक्री_ऑर्डर_लाइन (मूल्य_उपकुल बनाम उत्पाद मानक_मूल्य) से राजस्व घटा सीओजीएस राजस्व से विभाजित
  3. नकद रूपांतरण चक्र - डीएसओ + बकाया सूची के दिन - बकाया देय दिन
  4. बजट बनाम वास्तविक भिन्नता - एक बजट तालिका की आवश्यकता है (ओडू में खाता_बजट या मैन्युअल अपलोड)
  5. प्रति कर्मचारी राजस्व - कुल राजस्व को सक्रिय कर्मचारियों की संख्या से विभाजित किया जाता है

बिक्री KPI

  1. ग्राहक अधिग्रहण लागत - विपणन व्यय को प्राप्त नए ग्राहकों से विभाजित किया जाता है (मैन्युअल विपणन लागत इनपुट की आवश्यकता होती है)
  2. ग्राहक जीवनकाल मूल्य — प्रति ग्राहक औसत राजस्व गुणा औसत संबंध लंबाई
  3. बिक्री चक्र की लंबाई — अवसर सृजन से जीतने तक के दिन (crm_lead)
  4. कोटेशन-टू-ऑर्डर रूपांतरण दर - पुष्टि किए गए ऑर्डर को कुल कोटेशन से विभाजित किया गया
  5. औसत छूट % — सेल_ऑर्डर_लाइन डिस्काउंट फ़ील्ड से

परिचालन KPI

  1. उत्तम ऑर्डर दर - ऑर्डर समय पर, पूर्ण रूप से, सही दस्तावेज़ीकरण के साथ वितरित किए गए
  2. इन्वेंटरी सटीकता - वास्तविक गणना बनाम सिस्टम गणना (स्टॉक_क्वांट समायोजन से)
  3. आपूर्तिकर्ता लीड समय विश्वसनीयता - वास्तविक प्राप्ति तिथि बनाम खरीद ऑर्डर से अपेक्षित तिथि
  4. वेयरहाउस स्पेस यूटिलाइजेशन - कब्जे वाले स्थानों को कुल स्थानों से विभाजित किया गया
  5. वापसी दर - कुल बिक्री के प्रतिशत के रूप में क्रेडिट नोट/रिफंड

KPI का विनिर्माण

  1. फर्स्ट पास यील्ड - बिना दोबारा काम किए गुणवत्ता निरीक्षण पास करने वाली इकाइयों को कुल इकाइयों से विभाजित किया जाता है
  2. अनुसूची का पालन - उत्पादन आदेश नियोजित तिथि पर पूरा किया गया
  3. सामग्री अपशिष्ट % - बीओएम आवश्यकताओं से अधिक कच्चे माल की खपत
  4. कार्य केंद्र उपयोग — वास्तविक उत्पादक घंटे बनाम उपलब्ध घंटे
  5. विफलताओं के बीच औसत समय (एमटीबीएफ) - उपकरण टूटने के बीच औसत परिचालन समय

इनमें से प्रत्येक KPI के लिए विशिष्ट टेबल जॉइन और DAX लॉजिक की आवश्यकता होती है। ECOSIRE की पावर बीआई कार्यान्वयन सेवा में सभी बीस के लिए पूर्व-निर्मित उपायों के साथ एक मानक KPI लाइब्रेरी शामिल है।


प्रदर्शन अनुकूलन

क्वेरी फ़ोल्डिंग

क्वेरी फोल्डिंग Odoo + Power BI एकीकरण के लिए सबसे महत्वपूर्ण प्रदर्शन अवधारणा है। जब पावर क्वेरी किसी परिवर्तन को "फोल्ड" करती है, तो यह चरण को SQL में अनुवादित करती है और इसे Power BI इंजन के बजाय PostgreSQL सर्वर पर निष्पादित करती है।

कदम जो मोड़ते हैं:

  • तालिका.चयन पंक्तियाँ (कहां खंड)
  • तालिका.चयन कॉलम (विशिष्ट कॉलम चुनें)
  • तालिका.क्रमबद्ध करें (क्रमानुसार)
  • तालिका.समूह (समूह द्वारा)
  • टेबल.जुड़ें (शामिल हों)
  • टेबल.फर्स्टएन (सीमा)

ऐसे कदम जो फोल्डिंग को तोड़ते हैं:

  • कस्टम एम फ़ंक्शंस के साथ Table.AddColumn
  • टेबल.बफर
  • टेबल.पिवोट / टेबल.अनपिवोट (ज्यादातर मामलों में)
  • गैर-फ़ोल्डेबल पूर्व चरण का संदर्भ देने वाला कोई भी चरण

सर्वोत्तम अभ्यास: पावर क्वेरी फोल्डिंग पर निर्भर रहने के बजाय कस्टम SQL क्वेरी लिखें। यह आपको PostgreSQL को भेजे गए SQL पर पूर्ण नियंत्रण देता है और फोल्डिंग अनिश्चितता को समाप्त करता है।

आयात बनाम DirectQuery

कारकआयात मोडडायरेक्टक्वेरी
प्रदर्शनतेज़ (डेटा स्थानीय रूप से कैश किया गया)धीमा (प्रश्न ओडू डीबी लाइव पर आते हैं)
डेटा ताजगीशेड्यूल किया गया ताज़ा (न्यूनतम 30 मिनट)वास्तविक समय
मॉडल का आकारमेमोरी द्वारा सीमित (1 जीबी मुफ़्त, 10-100 जीबी प्रीमियम)कोई आकार सीमा नहीं
DAX समर्थनपूर्णसीमित (कुछ कार्य अनुपलब्ध)
ओडू पर प्रभावताज़ा करने के बाद कोई नहींप्रत्येक रिपोर्ट इंटरेक्शन डीबी पर सवाल उठाता है
सिफारिशअधिकांश परिदृश्यों के लिए उपयोग करेंकेवल तभी उपयोग करें जब वास्तविक समय आवश्यक हो

अधिकांश Odoo परिनियोजन के लिए, वृद्धिशील ताज़ा के साथ आयात मोड प्रदर्शन और ताजगी का सर्वोत्तम संतुलन प्रदान करता है। DirectQuery को परिचालन डैशबोर्ड के लिए आरक्षित किया जाना चाहिए जहां 30 मिनट पुराना डेटा अस्वीकार्य है (उदाहरण के लिए, एक लाइव विनिर्माण फ़्लोर डिस्प्ले)।

समग्र मॉडल

पावर बीआई प्रीमियम समग्र मॉडल का समर्थन करता है जो आयात और डायरेक्टक्वेरी तालिकाओं को जोड़ता है। यह ओडू एकीकरण के लिए आदर्श है जहां:

  • बड़ी ऐतिहासिक तालिकाएँ (बिक्री आदेश, जर्नल प्रविष्टियाँ) वृद्धिशील ताज़ा के साथ आयात मोड का उपयोग करती हैं
  • छोटी, तेजी से बदलती तालिकाएँ (लाइव इन्वेंट्री के लिए स्टॉक_क्वांट) DirectQuery का उपयोग करती हैं
  • दिनांक आयाम और अन्य आयाम दोहरे भंडारण मोड का उपयोग करते हैं

सामान्य समस्याओं का निवारण

कनेक्शन त्रुटियाँ

"सर्वर से कनेक्ट करने में असमर्थ" - सत्यापित करें कि PostgreSQL सही पोर्ट (डिफ़ॉल्ट 5432) पर सुन रहा है और फ़ायरवॉल नियम पावर बीआई गेटवे या आपके डेस्कटॉप आईपी से इनबाउंड कनेक्शन की अनुमति देते हैं। क्लाइंट प्रमाणीकरण नियमों के लिए listen_addresses और pg_hba.conf के लिए postgresql.conf जांचें।

"एसएसएल कनेक्शन आवश्यक है" - कनेक्शन में sslmode=require जोड़ें। स्व-हस्ताक्षरित प्रमाणपत्रों के लिए, आपको CA प्रमाणपत्र आयात करने या sslmode=allow सेट करने की आवश्यकता हो सकती है (उत्पादन के लिए अनुशंसित नहीं)।

"तालिका के लिए अनुमति अस्वीकृत" - पावर बीआई डेटाबेस उपयोगकर्ता के पास चयन विशेषाधिकारों का अभाव है। GRANT SELECT ON ALL TABLES IN SCHEMA public TO powerbi_readonly; चलाएँ और psql में \dp table_name से सत्यापित करें।

डेटा गुणवत्ता संबंधी मुद्दे

महत्वपूर्ण क्षेत्रों में शून्य मान - ओडू कई क्षेत्रों को खाली रखने की अनुमति देता है। गणना त्रुटियों से बचने के लिए SQL प्रश्नों में COALESCE का उपयोग करें या DAX में BLANK() को संभालें।

डुप्लिकेट रिकॉर्ड - ओडू का ओआरएम कभी-कभी संपादन के दौरान रिकॉर्ड के कई संस्करण बनाता है। active = true द्वारा फ़िल्टर करें और सुनिश्चित करें कि आप ड्राफ्ट और रद्द किए गए रिकॉर्ड को बाहर करने के लिए सही स्थिति फ़ील्ड का उपयोग कर रहे हैं।

समय क्षेत्र बेमेल - ओडू यूटीसी में टाइमस्टैम्प संग्रहीत करता है। Power BI डिफ़ॉल्ट रूप से स्थानीय समयक्षेत्र में प्रदर्शित होता है। सामान्य करने के लिए PostgreSQL क्वेरी में AT TIME ZONE या पावर क्वेरी में DateTimeZone.SwitchZone का उपयोग करें।

प्रदर्शन संबंधी मुद्दे

धीमा ताज़ा समय — वृद्धिशील ताज़ा सक्षम करें। संपूर्ण तालिकाएँ आयात करने के बजाय कस्टम SQL क्वेरीज़ का उपयोग करें। अपनी विश्लेषण विंडो से परे निष्क्रिय रिकॉर्ड, ड्राफ्ट दस्तावेज़ और ऐतिहासिक डेटा को फ़िल्टर करें।

10 सेकंड से अधिक लोड समय की रिपोर्ट करें - जटिल DAX उपायों की जाँच करें जो बड़ी तालिकाओं (SUMX, कई पंक्तियों के साथ फ़िल्टर) पर पुनरावृत्त होते हैं। बार-बार गणना से बचने के लिए चर का उपयोग करें। SQL दृश्यों में डेटा को पूर्व-एकत्रित करने पर विचार करें।

गेटवे टाइमआउट — गेटवे डेटा स्रोत कॉन्फ़िगरेशन में कमांड टाइमआउट बढ़ाएँ। डिफ़ॉल्ट 120 सेकंड है; बड़े Odoo डेटाबेस के लिए 600 पर सेट करें।


सुरक्षा संबंधी विचार

डेटाबेस सुरक्षा

Odoo एडमिन डेटाबेस उपयोगकर्ता का उपयोग करके कभी भी Power BI को Odoo से कनेक्ट न करें। जैसा कि पहले दिखाया गया है, एक समर्पित केवल पढ़ने योग्य उपयोगकर्ता बनाएं। इन अतिरिक्त उपायों पर विचार करें:

  • पंक्ति-स्तरीय प्रतिबंध: यदि आप नहीं चाहते कि पावर बीआई सभी तालिकाओं तक पहुंच सके (उदाहरण के लिए, hr_payslip को छोड़कर) तो केवल पढ़ने वाले उपयोगकर्ता की पहुंच को सीमित करने के लिए PostgreSQL CREATE POLICY का उपयोग करें।
  • कॉलम मास्किंग: ऐसे दृश्य बनाएं जो संवेदनशील कॉलम (वेतन, एसएसएन, बैंक विवरण) को बाहर कर दें और आधार तालिकाओं के बजाय पावर बीआई को दृश्यों तक पहुंच प्रदान करें
  • कनेक्शन एन्क्रिप्शन: PostgreSQL कनेक्शन के लिए हमेशा SSL का उपयोग करें, खासकर जब Power BI गेटवे और Odoo डेटाबेस अलग-अलग नेटवर्क पर हों
  • ऑडिट लॉगिंग: Power BI उपयोगकर्ता के सभी प्रश्नों को ट्रैक करने के लिए PostgreSQL pgaudit सक्षम करें

पावर बीआई सुरक्षा

  • पावर बीआई में पंक्ति-स्तरीय सुरक्षा (आरएलएस) लागू करें जो ओडू के मल्टी-कंपनी एक्सेस नियमों को प्रतिबिंबित करता है
  • वित्तीय या मानव संसाधन डेटा वाले डेटासेट के लिए संवेदनशीलता लेबल का उपयोग करें
  • अधिकृत विश्लेषकों और उपभोक्ताओं तक कार्यस्थल की पहुंच प्रतिबंधित करें
  • डेटा घुसपैठ को रोकने के लिए संवेदनशील रिपोर्ट पर डेटा निर्यात अक्षम करें

पावर बीआई सुरक्षा पर गहन जानकारी के लिए, पंक्ति-स्तरीय सुरक्षा कार्यान्वयन पर हमारी मार्गदर्शिका देखें।


यह सब एक साथ रखना: कार्यान्वयन रोडमैप

चरण 1: फाउंडेशन (सप्ताह 1-2)

  1. Odoo डेटाबेस पर केवल पढ़ने योग्य PostgreSQL उपयोगकर्ता बनाएं
  2. ऑन-प्रिमाइसेस डेटा गेटवे स्थापित और कॉन्फ़िगर करें (यदि पावर बीआई सेवा का उपयोग कर रहे हैं)
  3. Power BI डेस्कटॉप को Odoo डेटाबेस से कनेक्ट करें
  4. पांच कोर टेबल समूह (बिक्री, लेखांकन, इन्वेंट्री, विनिर्माण, एचआर) आयात करें
  5. दिनांक आयाम बनाएं और संबंध स्थापित करें

चरण 2: कोर डैशबोर्ड (सप्ताह 3-4)

  1. कार्यकारी बिक्री डैशबोर्ड बनाएं (राजस्व, विकास, शीर्ष उत्पाद, पाइपलाइन)
  2. वित्त डैशबोर्ड बनाएं (एआर एजिंग, नकदी प्रवाह, बजट भिन्नता)
  3. इन्वेंट्री डैशबोर्ड बनाएं (स्टॉक स्तर, टर्नओवर, पुनः ऑर्डर अलर्ट)
  4. सभी तथ्य तालिकाओं के लिए वृद्धिशील ताज़ा कॉन्फ़िगर करें
  5. Power BI सेवा पर प्रकाशित करें और शेड्यूल किया गया ताज़ा सेट अप करें

चरण 3: उन्नत विश्लेषण (सप्ताह 5-6)

  1. विनिर्माण डैशबोर्ड बनाएं (OEE, उपयोग, उत्पादन शेड्यूलिंग)
  2. एचआर डैशबोर्ड बनाएं (हेडकाउंट, एट्रिशन, उपस्थिति, अनुपस्थिति)
  3. मल्टी-कंपनी डेटा अलगाव के लिए पंक्ति-स्तरीय सुरक्षा लागू करें
  4. कुंजी डैशबोर्ड के लिए एक मोबाइल-अनुकूलित लेआउट बनाएं
  5. महत्वपूर्ण KPI (स्टॉकआउट, अतिदेय चालान, उत्पादन में देरी) के लिए डेटा अलर्ट सेट करें

चरण 4: शासन और पैमाना (सप्ताह 7-8)

  1. कार्यस्थल नामकरण परंपराएं और सामग्री प्रमाणन स्थापित करें
  2. स्व-सेवा रिपोर्ट निर्माण पर बिजली उपयोगकर्ताओं को प्रशिक्षित करें
  3. डेटा मॉडल और गणना तर्क का दस्तावेजीकरण करें
  4. गोद लेने पर नज़र रखने के लिए उपयोग की निगरानी स्थापित करें
  5. अतिरिक्त डेटा स्रोतों (मार्केटिंग प्लेटफॉर्म, ईकॉमर्स, IoT) की योजना

ECOSIRE की पावर बीआई + ओडू एकीकरण सेवा इस रोडमैप का अनुसरण करती है और आम तौर पर दो सप्ताह के भीतर पहला कार्यकारी डैशबोर्ड वितरित करती है। ओडू के डेटा मॉडल और पावर बीआई के विश्लेषणात्मक इंजन में हमारी टीम की दोहरी विशेषज्ञता यह सुनिश्चित करती है कि आपको पहले दिन से ही सटीक, निष्पादन योग्य और नियंत्रित विश्लेषण प्राप्त हो।


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

क्या मैं Power BI को Odoo Online, या केवल स्व-होस्टेड Odoo से कनेक्ट कर सकता हूँ?

आप दोनों से जुड़ सकते हैं, लेकिन तरीका अलग है। स्व-होस्ट किया गया Odoo आपको सीधे PostgreSQL एक्सेस प्रदान करता है, जो तेज़ और अधिक लचीला है। Odoo ऑनलाइन और Odoo.sh डेटाबेस को सीधे उजागर नहीं करते हैं, इसलिए आपको Odoo के JSON-RPC API, एक समुदाय OData कनेक्टर मॉड्यूल, या स्टेजिंग डेटाबेस में शेड्यूल किए गए डेटा निर्यात का उपयोग करने की आवश्यकता है। बड़े डेटासेट वाले ओडू ऑनलाइन के लिए, स्टेजिंग डेटाबेस दृष्टिकोण की सिफारिश की जाती है क्योंकि 50,000 से अधिक रिकॉर्ड वाली तालिकाओं के लिए एपीआई-आधारित निष्कर्षण धीमा है।

पावर बीआई कितनी बार ओडू से डेटा रीफ्रेश कर सकता है?

पावर बीआई प्रो के साथ, आप प्रति दिन (प्रत्येक 3 घंटे) 8 रिफ्रेश तक शेड्यूल कर सकते हैं। पावर बीआई प्रीमियम के साथ, आप प्रति दिन (प्रत्येक 30 मिनट में) 48 रिफ्रेश तक शेड्यूल कर सकते हैं। वास्तविक समय डेटा के लिए, DirectQuery मोड का उपयोग करें, लेकिन ध्यान रखें कि प्रत्येक रिपोर्ट इंटरैक्शन सीधे आपके Odoo डेटाबेस से क्वेरी करेगा। वृद्धिशील रिफ्रेश प्रत्येक रिफ्रेश में लगने वाले समय को कम कर देता है, जिससे डेटाबेस को ओवरलोड किए बिना अधिक बार रिफ्रेश करना व्यावहारिक हो जाता है।

क्या Power BI क्वेरीज़ हमारे Odoo सिस्टम को धीमा कर देंगी?

यदि आप आयात मोड (अनुशंसित) का उपयोग करते हैं, तो पावर बीआई क्वेरीज़ केवल निर्धारित रिफ्रेश के दौरान चलती हैं --- आमतौर पर ऑफ-पीक घंटों के दौरान। ओडू प्रदर्शन पर प्रभाव न्यूनतम है। यदि आप DirectQuery का उपयोग करते हैं, तो प्रत्येक रिपोर्ट इंटरैक्शन आपके Odoo डेटाबेस के विरुद्ध लाइव क्वेरी उत्पन्न करता है, जो व्यावसायिक घंटों के दौरान प्रदर्शन को प्रभावित कर सकता है। शमन में एक पठन प्रतिकृति का उपयोग करना, क्वेरी टाइमआउट कॉन्फ़िगर करना और इंडेक्स का उपयोग करने वाले कुशल SQL क्वेरी डिज़ाइन करना शामिल है।

क्या एकीकरण स्थापित करने के लिए मुझे SQL जानने की आवश्यकता है?

बुनियादी SQL ज्ञान सहायक है लेकिन कड़ाई से आवश्यक नहीं है। Power BI का Power Query इंटरफ़ेस आपको तालिकाओं का चयन करने और दृश्य रूप से फ़िल्टर लागू करने की सुविधा देता है। हालाँकि, इष्टतम प्रदर्शन और डेटा गुणवत्ता के लिए, कस्टम SQL क्वेरीज़ की दृढ़ता से अनुशंसा की जाती है। वे आपको तालिकाओं को पहले से जोड़ने, अनावश्यक रिकॉर्ड को फ़िल्टर करने और डेटाबेस स्तर पर डेटा को आकार देने की अनुमति देते हैं। यदि आपकी टीम में SQL विशेषज्ञता का अभाव है, तो प्रारंभिक सेटअप के लिए एक विशेषज्ञ को नियुक्त करने और फिर Power BI के विज़ुअल टूल के साथ रिपोर्ट बनाए रखने पर विचार करें।

ECOSIRE की Odoo + Power BI सेवा सामान्य Power BI परामर्श से किस प्रकार भिन्न है?

अधिकांश पावर बीआई परामर्श फर्मों के पास पावर बीआई में विशेषज्ञता है लेकिन ओडू के डेटा मॉडल का ज्ञान सीमित है। वे ओडू-विशिष्ट सम्मेलनों (जैसे दोहरी उत्पाद_उत्पाद / उत्पाद_टेम्पलेट संरचना) को समझने, और यह पता लगाने में कि कौन से क्षेत्र सार्थक हैं, तालिका संबंधों को रिवर्स-इंजीनियरिंग करने में कई सप्ताह बिताते हैं। ECOSIRE ने 43 से अधिक Odoo मॉड्यूल बनाए और तैनात किए हैं और दोनों प्लेटफार्मों में गहरी विशेषज्ञता बनाए रखी है। हम पूर्व-निर्मित डेटा मॉडल, 50-प्लस उपायों के साथ एक मानक KPI लाइब्रेरी और राइट_डेट कॉलम पर वृद्धिशील ताज़ा जैसे ओडू-विशिष्ट अनुकूलन प्रदान करते हैं। यह दोहरी विशेषज्ञता ओडू के डेटा मॉडल को शुरू से सीखने वाली टीमों की तुलना में कार्यान्वयन के समय को 40-60 प्रतिशत तक कम कर देती है।

E

लेखक

ECOSIRE Research and Development Team

ECOSIRE में एंटरप्राइज़-ग्रेड डिजिटल उत्पाद बना रहे हैं। Odoo एकीकरण, ई-कॉमर्स ऑटोमेशन, और AI-संचालित व्यावसायिक समाधानों पर अंतर्दृष्टि साझा कर रहे हैं।

WhatsApp पर चैट करें