پاور BI + اوڈو انٹیگریشن کے لیے مکمل گائیڈ

Odoo دنیا کے سب سے طاقتور اوپن سورس ERP پلیٹ فارمز میں سے ایک ہے، جس میں 12 ملین سے زیادہ صارفین اور 43 آفیشل ماڈیولز سیلز اور انوینٹری سے لے کر مینوفیکچرنگ اور انسانی وسائل تک ہر چیز کا احاطہ کرتے ہیں۔ پاور BI 300 ملین سے زیادہ ماہانہ فعال صارفین کے ساتھ صنعت کا معروف کاروباری انٹیلی جنس پلیٹ فارم ہے۔ پھر بھی حیرت انگیز طور پر چند تنظیمیں ان دو نظاموں کو جوڑتی ہیں --- میز پر بہت زیادہ تجزیاتی قدر چھوڑ کر۔

وجہ سیدھی ہے: Odoo کی اپنی بلٹ ان رپورٹنگ ہے، اور زیادہ تر پاور BI کنسلٹنسیز Microsoft Dynamics، SAP، یا Salesforce انضمام پر توجہ مرکوز کرتی ہیں۔ بہت کم فرموں کو دونوں پلیٹ فارمز میں گہری مہارت حاصل ہے۔ ECOSIRE پر، ہم نے 43 سے زیادہ Odoo ماڈیولز بنائے اور تعینات کیے ہیں اور پاور BI کی گہری مہارت کو برقرار رکھا ہے، جس سے Odoo + Power BI کے امتزاج کو ہماری بنیادی مہارتوں میں سے ایک بنا دیا گیا ہے۔ یہ گائیڈ ہر وہ چیز نکالتا ہے جو ہم نے درجنوں حقیقی دنیا کے انضمام سے سیکھا ہے۔

---

اہم نکات

• Odoo کے PostgreSQL ڈیٹا بیس کو مقامی PostgreSQL کنیکٹر کا استعمال کرتے ہوئے براہ راست Power BI ڈیسک ٹاپ سے منسلک کیا جا سکتا ہے، جو آپ کو ہر ٹیبل اور فیلڈ تک مکمل رسائی فراہم کرتا ہے۔
• تجزیات کے لیے پانچ سب سے قیمتی Odoo ٹیبلز ہیں sale_order، account_move، stock_picking، hr_employee، اور mrp_production --- مل کر وہ ایگزیکٹو رپورٹنگ کی 80 فیصد ضروریات کو پورا کرتے ہیں۔
• پاور BI میں اضافی ریفریش صرف آخری ریفریش کے بعد تبدیل ہونے والے ریکارڈز کو بازیافت کرکے Odoo ڈیٹا لوڈ کے اوقات کو گھنٹوں سے منٹ تک کم کر سکتا ہے۔
• OData اینڈ پوائنٹس اور Odoo's External API کلاؤڈ فرینڈلی متبادل فراہم کرتے ہیں جب ڈیٹا بیس تک براہ راست رسائی دستیاب نہ ہو
• پاور BI میں قطار کی سطح کی سیکیورٹی Odoo کے ملٹی کمپنی ایکسیس کنٹرولز کی عکاسی کر سکتی ہے، اس بات کو یقینی بناتے ہوئے کہ صارفین صرف اپنی تفویض کردہ کمپنیوں کا ڈیٹا دیکھیں۔
• Odoo کے PostgreSQL ڈیٹا بیس کے خلاف حسب ضرورت ایس کیو ایل کے سوالات جنرک ٹیبل کی درآمدات کو 5-10x تک بہتر بناتے ہیں کیونکہ آپ ڈیٹا بیس کی سطح پر فلٹر، جوائن، اور ایگریگیٹ کر سکتے ہیں۔
• ایک اچھی طرح سے ڈیزائن کردہ Odoo + Power BI کی تعیناتی درجنوں اسپریڈشیٹ رپورٹس کو ایک واحد زیر انتظام تجزیاتی پلیٹ فارم سے بدل دیتی ہے۔

---

کیوں اوڈو + پاور BI ایک طاقتور مجموعہ ہے۔

اوڈو کی بلٹ ان رپورٹنگ کی حدود

کئی رپورٹنگ ٹولز کے ساتھ Odoo جہاز بھیجتا ہے: محور کے نظارے، گراف کے نظارے، اور ایک بلٹ ان ڈیش بورڈ۔ روزانہ کی کارروائیوں کے لیے، یہ کافی ہیں۔ لیکن وہ کئی اہم طریقوں سے انٹرپرائز اینالیٹکس کے لیے کم ہیں۔

سب سے پہلے، Odoo کے محور کے نظارے ایک ہی تصور میں متعدد ماڈیولز کے ڈیٹا کو یکجا نہیں کر سکتے۔ آپ ایک چارٹ میں انوینٹری ٹرن اوور اور مینوفیکچرنگ تھرو پٹ کے ساتھ سیلز ریونیو کو اوورلی نہیں کر سکتے۔ ہر ماڈیول کی رپورٹنگ سائلوڈ ہے۔

دوسرا، اوڈو میں وقتی ذہانت کے افعال کی کمی ہے۔ سال بہ سال موازنہ، رولنگ اوسط، مجموعی کل، اور مدت سے تاریخ کے حسابات کے لیے حسب ضرورت ترقی یا دستی اسپریڈشیٹ کی برآمدات کی ضرورت ہوتی ہے۔

تیسرا، اوڈو کے پاس زیر انتظام ڈیٹا ماڈل کا کوئی تصور نہیں ہے۔ میٹرکس کے لیے کوئی مشترکہ تعریفیں نہیں ہیں جیسے "آمدنی" یا "کسٹمر لائف ٹائم ویلیو"۔ ہر صارف اپنی تشریح خود بناتا ہے، جس کی وجہ سے انتظامی میٹنگز میں متضاد نمبر ہوتے ہیں۔

چوتھا، Odoo کی ویژولائزیشن کی صلاحیتیں بنیادی بار چارٹس، لائن چارٹس، اور پائی چارٹس تک محدود ہیں۔ ہیٹ میپس، سکیٹر پلاٹ، واٹر فال چارٹ، سڑنے والے درخت، اور KPI کارڈ دستیاب نہیں ہیں۔

پاور BI کیا شامل کرتا ہے۔

پاور BI ان حدود میں سے ہر ایک کو حل کرتا ہے۔ یہ Odoo کے PostgreSQL ڈیٹا بیس (یا API) سے جڑتا ہے اور تمام ماڈیولز میں ایک متحد سیمنٹک ماڈل بناتا ہے۔ DAX فارمولے وقت کی ذہانت، شماریاتی افعال، اور پیچیدہ کاروباری منطق فراہم کرتے ہیں۔ ویژولائزیشن لائبریری میں 300 سے زیادہ چارٹ اقسام شامل ہیں۔ اور پاور BI کی گورننس کی خصوصیات --- ورک اسپیس، قطار کی سطح کی سیکیورٹی، توثیق، حساسیت کے لیبلز --- انٹرپرائز گریڈ ڈیٹا مینجمنٹ فراہم کرتے ہیں۔

یہ امتزاج آپ کو روزمرہ کے کام کے لیے Odoo کی آپریشنل فضیلت اور سٹریٹجک فیصلہ سازی کے لیے Power BI کی تجزیاتی گہرائی فراہم کرتا ہے۔ آپریشن ٹیمیں اوڈو میں کام جاری رکھے ہوئے ہیں۔ ایگزیکٹوز اور تجزیہ کاروں کو پاور BI ڈیش بورڈز ملتے ہیں جو خود بخود اپ ڈیٹ ہو جاتے ہیں۔

---

کنکشن کے طریقے: ڈائریکٹ ڈیٹا بیس بمقابلہ API

پاور BI کو Odoo سے جوڑنے کے تین بنیادی طریقے ہیں۔ آپ کے ہوسٹنگ ماڈل اور حفاظتی تقاضوں کے لحاظ سے ہر ایک کے پاس ٹریڈ آف ہیں۔

طریقہ 1: براہ راست PostgreSQL کنکشن

یہ آن پریمیسس یا خود میزبان Odoo تعیناتیوں کے لیے ترجیحی طریقہ ہے۔ Odoo تمام ڈیٹا کو PostgreSQL میں اسٹور کرتا ہے، اور Power BI کا مقامی PostgreSQL کنیکٹر ہے۔

فائدے:

• تیز ترین استفسار کی کارکردگی (کوئی API اوور ہیڈ نہیں)
• اپنی مرضی کے ماڈیولز سمیت ہر ٹیبل اور فیلڈ تک مکمل رسائی
• ڈیٹا بیس کی سطح پر جوائنز اور مجموعوں کے ساتھ پیچیدہ SQL سوالات کی حمایت کرتا ہے۔
• اضافی ریفریش کو فعال کرتا ہے (ڈیٹ ٹائم کالم کی ضرورت ہوتی ہے)
• کوئی Odoo لائسنس یا API کی شرح کی حد نہیں۔

سیٹ اپ کے مراحل:

1. پاور BI ڈیسک ٹاپ کھولیں اور ڈیٹا حاصل کریں، پھر PostgreSQL ڈیٹا بیس کو منتخب کریں۔
2. اپنے Odoo سرور کا میزبان نام اور ڈیٹا بیس کا نام درج کریں (عام طور پر Odoo مثال کا نام)
3. صرف پڑھنے کے لیے ڈیٹا بیس کا استعمال کریں (کبھی بھی Odoo ایڈمن اکاؤنٹ نہیں)
4. زیادہ تر منظرناموں کے لیے امپورٹ موڈ، یا حقیقی وقت کی ضروریات کے لیے DirectQuery کو منتخب کریں۔
5. ٹیبل کی فہرست پر جائیں یا حسب ضرورت SQL استفسار استعمال کریں۔

کنکشن سٹرنگ کے پیرامیٹرز:

پوسٹگری ایس کیو ایل میں صرف پڑھنے کے لیے صارف بنانا:

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;

یہ نقطہ نظر اس بات کو یقینی بناتا ہے کہ پاور BI آپ کے پروڈکشن ڈیٹا بیس تک تحریری رسائی کے بغیر تمام موجودہ اور مستقبل کے ٹیبلز کو پڑھ سکتا ہے۔

طریقہ 2: Odoo External API (XML-RPC / JSON-RPC)

Odoo ڈیٹا کو پڑھنے اور لکھنے کے لیے ایک مکمل API کو ظاہر کرتا ہے۔ پاور BI اسے کسٹم کنیکٹرز یا ازگر اسکرپٹس کے ذریعے استعمال کر سکتا ہے۔

فائدے:

• Odoo.sh اور Odoo آن لائن کے ساتھ کام کرتا ہے (براہ راست ڈیٹا بیس تک رسائی کی ضرورت نہیں)
• اوڈو کے رسائی کنٹرول کے قواعد اور ریکارڈ کے قواعد کا احترام کرتا ہے۔
• ڈیٹا بیس پورٹ کو بیرونی طور پر بے نقاب کرنے کی ضرورت نہیں ہے۔

نقصانات:

• براہ راست ڈیٹا بیس کے سوالات سے نمایاں طور پر سست (بڑے ڈیٹا سیٹس کے لیے 10-100x)
• API کی شرح کی حدیں زیادہ حجم کے نچوڑ کو روک سکتی ہیں۔
• حسب ضرورت پاور کوئری فنکشن یا انٹرمیڈیٹ ETL مرحلہ درکار ہے۔
• صفحہ بندی پیچیدگی کا اضافہ کرتی ہے۔

Odoo کے JSON-RPC اینڈ پوائنٹ کے لیے، ایک عام Power Query M فنکشن https://your-odoo.com/jsonrpc کو تصدیق کے ساتھ کال کرے گا اور پھر نتائج کے ذریعے صفحہ بندی کرے گا۔ یہ کام کرتا ہے لیکن 50,000 سے زیادہ ریکارڈ والی میزوں کے لیے ناقابل عمل ہو جاتا ہے۔

طریقہ 3: اوڈو کنیکٹر ماڈیولز کے ذریعے OData اینڈ پوائنٹس

کئی Odoo کمیونٹی ماڈیولز OData فیڈز کو بے نقاب کرتے ہیں جنہیں Power BI مقامی طور پر استعمال کر سکتا ہے۔ پاور BI میں OData کنیکٹر باکس کے باہر تصدیق اور صفحہ بندی کی حمایت کرتا ہے۔

یہ طریقہ کب استعمال کریں:

• Odoo Online / Odoo.sh تعیناتیاں جہاں ڈیٹا بیس تک رسائی پر پابندی ہے۔
• اعداد و شمار میں Odoo کی کاروباری منطق (کمپیوٹیڈ فیلڈز، رسائی کے قواعد) کی ضرورت والے منظرنامے
• چھوٹے ڈیٹاسیٹس (100,000 ریکارڈ فی ادارہ سے کم)

زیادہ تر انٹرپرائز تعیناتیوں کے لیے، طریقہ 1 (براہ راست PostgreSQL) کی سختی سے سفارش کی جاتی ہے۔ کارکردگی کا فرق کافی ہے، اور SQL استفسارات کی لچک آپ کو ماخذ پر ڈیٹا کی شکل دینے کی اجازت دیتی ہے۔

---

پاور BI کے لیے ضروری اوڈو ٹیبلز

اوڈو کا پوسٹگری ایس کیو ایل ڈیٹا بیس سینکڑوں ٹیبلز پر مشتمل ہے۔ بنیادی جدولوں اور ان کے تعلقات کو سمجھنا موثر Power BI ماڈلز کی تعمیر کے لیے اہم ہے۔ ذیل میں وہ میزیں ہیں جو 80 فیصد ایگزیکٹو ڈیش بورڈز کو طاقت دیتی ہیں۔

سیلز ماڈیول ٹیبلز

اہم تعلقات: sale_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;

اکاؤنٹنگ ماڈیول ٹیبلز

اہم امتیاز: اوڈو میں، account_move انوائسز (move_type = 'out_invoice')، وینڈر بلز ('in_invoice')، کریڈٹ نوٹس ('out_refund'، 'in_refund')، اور جرنل اندراجات ('انٹری') اسٹور کرتا ہے۔ اپنے پاور BI سوالات میں ہمیشہ move_type کے ذریعے فلٹر کریں۔

account_move پر payment_state فیلڈ آپ کو بتاتا ہے کہ آیا کوئی انوائس 'not_paid'، 'in_payment'، 'ادائیگی'، 'جزوی'، یا 'الٹ' ہے۔ یہ اکاؤنٹس کے قابل وصول عمر رسیدہ ڈیش بورڈز کے لیے ضروری ہے۔

انوینٹری ماڈیول ٹیبلز

ریئل ٹائم انوینٹری: اسٹاک_کوانٹ ہمیشہ انوینٹری کی موجودہ حالت کو ظاہر کرتا ہے۔ تاریخی انوینٹری کے تجزیے کے لیے، آپ کو ڈیٹ فلٹرز کے ساتھ stock_move سے استفسار کرنا ہوگا اور چلتے ہوئے بیلنس کا حساب لگانا ہوگا۔

مینوفیکچرنگ ماڈیول ٹیبلز

OEE کیلکولیشن: مجموعی طور پر سازوسامان کی تاثیر mrp_workorder ریکارڈز سے منصوبہ بند مدت کا اصل دورانیے سے موازنہ کرکے، ڈاؤن ٹائم وجوہات کا تجزیہ کرکے، اور کوالٹی میٹرکس کو ٹریک کرکے حاصل کی جاسکتی ہے۔

انسانی وسائل کی میزیں۔

---

پاور BI ڈیٹا ماڈل بنانا

اسٹار اسکیما ڈیزائن

Odoo analytics کے لیے سب سے موثر ڈیٹا ماڈل اسٹار اسکیما پیٹرن کی پیروی کرتا ہے۔ حقائق کی میزیں (سیلز آرڈرز، انوائسز، اسٹاک موو، پروڈکشن آرڈر) مرکز میں بیٹھی ہیں۔ طول و عرض کی میزیں (مصنوعات، گاہک، تاریخیں، ملازمین، مقامات) انہیں گھیر لیتے ہیں۔

تجویز کردہ حقائق کی میزیں:

1. حقیقت_فروخت — سیل_آرڈر + سیل_آرڈر_لائن سے (اناج: ایک قطار فی آرڈر لائن)
2. Fact_Invoices — account_move + account_move_line سے (اناج: ایک قطار فی جرنل لائن)
3. فیکٹ_انوینٹری — اسٹاک_موو سے (اناج: ایک قطار فی اسٹاک موومنٹ)
4. حقیقت_پروڈکشن — mrp_production + mrp_workorder سے (اناج: ایک قطار فی ورک آرڈر)
5. حقیقت_حاضری — گھنٹہ_حاضری سے (اناج: ایک قطار فی گھڑی ان/آؤٹ جوڑی)

مشترکہ طول و عرض کی میزیں:

1. Dim_Date — پاور BI میں تیار کردہ کیلنڈر ٹیبل (وقت کی ذہانت کے لیے ضروری)
2. Dim_Customer — res_partner سے (کسٹمر_رینک > 0 پر فلٹر کیا گیا)
3. Dim_Product — پروڈکٹ_پروڈکٹ + پروڈکٹ_ٹیمپلیٹ + پروڈکٹ_کیٹگری سے
4. Dim_Employee — hr_employee +hr_department +hr_job سے
5. Dim_Location — stock_location + stock_warehouse سے
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")
)

پاور BI میں اس ٹیبل کو ڈیٹ ٹیبل کے بطور نشان زد کریں اور ہر فیکٹ ٹیبل کے ڈیٹ کالم سے Dim_Date[Date] تک تعلقات بنائیں۔ اپنی تنظیم سے ملنے کے لیے مالی سال کے آغاز کے مہینے کو ایڈجسٹ کریں۔

اوڈو کے ملٹی کمپنی سٹرکچر کو ہینڈل کرنا

اوڈو ملٹی کمپنی کنفیگریشنز کو سپورٹ کرتا ہے جہاں ایک ڈیٹا بیس متعدد قانونی اداروں کی خدمت کرتا ہے۔ ہر ٹرانزیکشنل ٹیبل میں ایک company_id غیر ملکی کلید شامل ہوتی ہے۔ پاور BI میں، res_company سے ایک Dim_Company ٹیبل بنائیں اور ہر فیکٹ ٹیبل سے تعلقات قائم کریں۔

قطار کی سطح کی سیکیورٹی کے لیے، لاگ ان صارف کی کمپنی اسائنمنٹ کی بنیاد پر Dim_Company کو فلٹر کرنے کے لیے Power BI کی RLS خصوصیت استعمال کریں۔ یہ BI پرت میں Odoo کے ملٹی-کمپنی تک رسائی کے کنٹرولز کا آئینہ دار ہے۔

---

ڈیش بورڈ کی ترکیبیں: سیلز تجزیات

ایگزیکٹو سیلز ڈیش بورڈ

یہ ڈیش بورڈ ان پانچ سوالوں کا جواب دیتا ہے جو ہر CEO پوچھتا ہے: اس مہینے کتنی آمدنی ہے؟ کیا ہم سہ ماہی کے راستے پر ہیں؟ کون سی مصنوعات جیت رہی ہیں؟ کون سے سیلز لوگ کارکردگی کا مظاہرہ کر رہے ہیں؟ ہمارے گاہک کہاں ہیں؟

تخلیق کے اقدامات:

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، Revenue QTD، Revenue YTD، گروتھ %)
• قطار 2: لائن چارٹ (ماہانہ آمدنی، موجودہ سال بمقابلہ پچھلے سال) اور بار چارٹ (مصنوعات کے زمرے کے لحاظ سے آمدنی)
• قطار 3: نقشہ بصری (کسٹمر کے ملک کی طرف سے آمدنی) اور میز (آمدنی، آرڈر کی تعداد، اوسط ڈیل سائز کے ساتھ سب سے اوپر 10 سیلز لوگ)
• قطار 4: واٹر فال چارٹ (آمدنی کا پل: نئے صارفین بمقابلہ موجودہ بمقابلہ کھوئے ہوئے) اور ڈونٹ چارٹ (سیلز چینل کے ذریعہ آمدنی)

سیلز پائپ لائن کا تجزیہ

اگر آپ سیلز ماڈیول کے ساتھ ساتھ Odoo CRM استعمال کرتے ہیں، تو پائپ لائن ڈیش بورڈز بنانے کے لیے 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])
)

بصری:

• KPI کارڈز: انوینٹری کی کل قیمت، ٹرن اوور ریشو، اسٹاک آؤٹ ریٹ، آئٹمز کو ری آرڈر پوائنٹ سے نیچے
• سکیٹر پلاٹ: ہر پروڈکٹ کو ٹرن اوور ریٹ (x-axis) بمقابلہ مارجن (y-axis) کے حساب سے تیار کیا گیا، جس کا سائز ریونیو کنٹریبیوشن کے حساب سے --- یہ ABC-XYZ تجزیہ بصری ہے۔
• بار چارٹ: انوینٹری ویلیو کے لحاظ سے سرفہرست 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)
)

---

ڈیش بورڈ کی ترکیبیں: مینوفیکچرنگ

پروڈکشن پرفارمنس ڈیش بورڈ

Odoo مینوفیکچرنگ چلانے والے مینوفیکچررز کے لیے، 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]

بصری:

• گیج چارٹ: OEE، دستیابی، کارکردگی، معیار (ہر ایک ہدف کی حد کے ساتھ: سبز 85% سے اوپر، پیلا 60-85%، سرخ 60% سے نیچے)
• لائن چارٹ: کنٹرول کی حدود کے ساتھ ہفتے کے حساب سے OEE رجحان
• کلسٹرڈ بار چارٹ: OEE بذریعہ ورک سینٹر، یہ ظاہر کرتا ہے کہ کون سی مشینیں کم کارکردگی کا مظاہرہ کرتی ہیں۔
• ٹیبل: منصوبہ بند بمقابلہ اصل مدت، تغیر، اور سکریپ کی مقدار کے ساتھ پروڈکشن آرڈرز

ورک سینٹر کا استعمال

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
)

یہ ڈیش بورڈ پروڈکشن مینیجرز کو رکاوٹ کے کام کے مراکز کی شناخت اور نظام الاوقات کو بہتر بنانے میں مدد کرتا ہے۔ Odoo کے پلاننگ ماڈیول ڈیٹا کے ساتھ ملا کر، آپ صلاحیت کی منصوبہ بندی کے ماڈل بنا سکتے ہیں جو پیش گوئی کرتے ہیں کہ آپ کب زیادہ سے زیادہ استعمال کریں گے۔

---

ڈیش بورڈ کی ترکیبیں: HR اور افرادی قوت

افرادی قوت کے تجزیات کا ڈیش بورڈ

Odoo ڈیٹا سے بنائے گئے HR ڈیش بورڈ بصیرت فراہم کرتے ہیں جس کے لیے زیادہ تر HRIS سسٹم پریمیم قیمتیں وصول کرتے ہیں۔

ہیڈ کاؤنٹ اور ٹرن اوور کے اقدامات:

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 ڈیٹا بیسز کے لیے، مکمل ڈیٹا ریفریشز ناقابل عمل ہیں۔ پاور BI کی انکریمنٹل ریفریش فیچر صرف نئے اور تبدیل شدہ ریکارڈز کو لوڈ کرتی ہے، ریفریش کے اوقات کو گھنٹوں سے منٹ تک کم کرتی ہے۔

شرائط

• پاور BI پرو یا پریمیم لائسنس
• ہر ٹیبل میں ایک قابل اعتماد ڈیٹ ٹائم کالم ہونا ضروری ہے (Odoo میں لکھنے کی_تاریخ مثالی ہے --- جب بھی کسی ریکارڈ میں ترمیم کی جاتی ہے تو یہ اپ ڈیٹ ہوجاتا ہے)
• ڈیٹا سورس کو استفسار فولڈنگ کی حمایت کرنی چاہیے (PostgreSQL کرتا ہے)

کنفیگریشن کے مراحل

مرحلہ 1: رینج اسٹارٹ اور رینج اینڈ پیرامیٹر بنائیں

پاور سوال میں، DateTime قسم کے دو پیرامیٹرز بنائیں:

• رینج اسٹارٹ: ڈیفالٹ ویلیو = 1/1/2020 12:00:00 AM
• رینج اینڈ: ڈیفالٹ ویلیو = 12/31/2030 12:00:00 AM

مرحلہ 2: جدولوں کو پیرامیٹرز کے مطابق فلٹر کریں

ہر فیکٹ ٹیبل کے لیے، پاور کوئری میں ایک فلٹر مرحلہ شامل کریں:

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

اس فلٹر کو ڈیٹا بیس میں فولڈ کرنا ضروری ہے (پیدا کردہ SQL میں ظاہر ہوتا ہے)۔ مرحلہ پر دائیں کلک کرکے اور "دیکھیں مقامی سوال" کو منتخب کرکے تصدیق کریں۔

مرحلہ 3: انکریمنٹل ریفریش پالیسی کی وضاحت کریں

ماڈل میں ٹیبل پر دائیں کلک کریں، انکریمنٹل ریفریش کو منتخب کریں، اور کنفیگر کریں:

یہ کنفیگریشن تین سال کی تاریخ کو ذخیرہ کرتی ہے لیکن ہر ایک طے شدہ ریفریش کے دوران صرف آخری سات دنوں کو تازہ کرتی ہے۔ Odoo کا write_date کالم خود بخود اپ ڈیٹ ہوجاتا ہے جب کسی ریکارڈ پر کوئی بھی فیلڈ تبدیل ہوتی ہے، جس سے یہ ایک قابل اعتماد تبدیلی کا پتہ لگانے والا کالم بن جاتا ہے۔

کارکردگی کا اثر

کارکردگی کا فائدہ ڈرامائی ہے، خاص طور پر مینوفیکچرنگ اور انوینٹری ڈیٹاسیٹس کے لیے جو لین دین کے اعداد و شمار کی زیادہ مقدار پیدا کرتے ہیں۔

---

ایڈوانسڈ: ملٹی کمپنی اور ملٹی کرنسی

ملٹی کمپنی اوڈو تعیناتیوں کو سنبھالنا

بہت سے Odoo انٹرپرائز کی تعیناتیاں ایک ڈیٹا بیس سے متعدد قانونی اداروں کی خدمت کرتی ہیں۔ ہر لین دین کے ریکارڈ میں ایک company_id فیلڈ ہوتا ہے۔ پاور BI میں:

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;

متبادل طور پر، پاور BI میں Dim_Currency_Rate ٹیبل کو روزانہ کی شرح تبادلہ کے ساتھ برقرار رکھیں اور رپورٹ کے وقت تبدیل کرنے کے لیے DAX استعمال کریں۔ یہ نقطہ نظر کیا-اگر منظرناموں کے لیے زیادہ لچکدار ہے (مثال کے طور پر، "گزشتہ سال کی شرح مبادلہ پر محصول کیسا نظر آئے گا؟")۔

---

Odoo آن لائن کے لیے OData اور REST API انٹیگریشن

Odoo Online یا Odoo.sh استعمال کرنے والی تنظیموں کے لیے جہاں براہ راست PostgreSQL رسائی دستیاب نہیں ہے، وہاں کنکشن کے متبادل طریقے موجود ہیں۔

اوڈو کا JSON-RPC API استعمال کرنا

Odoo /jsonrpc پر ایک JSON-RPC اینڈ پوائنٹ کو ظاہر کرتا ہے (یا پرانا XML-RPC /xmlrpc/2 پر)۔ آپ ڈیٹا حاصل کرنے کے لیے 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}
    ]
  }
}

پاور BI میں، آپ اسے صفحہ بندی منطق کے ساتھ Web.Contents کا استعمال کرتے ہوئے حسب ضرورت پاور کوئری فنکشن کے طور پر نافذ کریں گے۔ چیلنج کارکردگی ہے: ہر API کال زیادہ سے زیادہ چند ہزار ریکارڈ واپس کرتی ہے، اور آپ کو بڑے ڈیٹا سیٹس کے لیے متعدد راؤنڈ ٹرپس کی ضرورت ہوتی ہے۔

کمیونٹی OData ماڈیولز

کئی Odoo کمیونٹی ماڈیولز OData کے اختتامی نکات کو شامل کرتے ہیں:

• Odoo کے لیے BI کنیکٹر — قابل ترتیب OData فیڈز کو بے نقاب کرتا ہے۔
• Odoo-Power BI کنیکٹر — عام ماڈیولز کے لیے پہلے سے تیار کردہ ڈیٹا ماڈلز

یہ ماڈیول انضمام کو آسان بناتے ہیں لیکن آپ کے Odoo مثال میں انحصار شامل کرتے ہیں۔ اس بات کا اندازہ کریں کہ کیا سہولت کمیونٹی ماڈیول کے دیکھ بھال کے بوجھ سے زیادہ ہے۔

ہائبرڈ اپروچ: شیڈولڈ ڈیٹا ایکسپورٹ

ایک عملی مڈل گراؤنڈ Odoo سے اسٹیجنگ ڈیٹا بیس یا Azure SQL میں رات کے وقت ڈیٹا ایکسپورٹ کا شیڈول بنانا ہے۔ ایک Odoo شیڈول کردہ ایکشن ایک Python اسکرپٹ چلاتا ہے جو کلیدی ٹیبلز کو CSV میں ایکسپورٹ کرتا ہے یا API کے ذریعے ڈیٹا کو Azure SQL ڈیٹا بیس میں دھکیلتا ہے۔ پاور BI پھر مکمل استفسار فولڈنگ سپورٹ کے ساتھ سٹیجنگ ڈیٹا بیس سے جڑتا ہے۔

یہ نقطہ نظر ان تنظیموں کے لیے اچھی طرح کام کرتا ہے جو Odoo کے پروڈکشن ڈیٹا بیس کو Power BI سوالات کے سامنے لائے بغیر تقریباً روزانہ ڈیٹا کی تازہ کاری چاہتے ہیں۔

---

حقیقی دنیا کے پی آئی کی مثالیں۔

یہاں بیس KPIs ہیں جو ECOSIRE کلائنٹ Odoo کو پاور BI سے منسلک کرنے کے بعد اکثر بناتے ہیں، جس کا اہتمام محکمہ کے ذریعے کیا جاتا ہے۔

فنانس KPIs

1. ڈیز سیلز بقایا (DSO) — اکاؤنٹ_موو (انوائس کی تاریخ بمقابلہ ادائیگی کی تاریخ) سے ادائیگی جمع کرنے کے اوسط دن
2. مجموعی مارجن % — سیل_آرڈر_لائن (قیمت_سب ٹوٹل بمقابلہ پروڈکٹ کی معیاری_قیمت) سے آمدنی مائنس COGS تقسیم
3. کیش کنورژن سائیکل — DSO + دنوں کی انوینٹری بقایا - دن قابل ادائیگی بقایا
4. بجٹ بمقابلہ اصل تغیر — ایک بجٹ ٹیبل درکار ہے (Odoo میں اکاؤنٹ_بجٹ یا دستی اپ لوڈ)
5. محصول فی ملازم — فعال ہیڈ کاؤنٹ سے تقسیم شدہ کل آمدنی

سیلز KPIs

6. کسٹمر کے حصول کی لاگت — مارکیٹنگ کے اخراجات کو حاصل کردہ نئے گاہکوں سے تقسیم کیا جاتا ہے (دستی مارکیٹنگ لاگت ان پٹ کی ضرورت ہوتی ہے)
7. کسٹمر لائف ٹائم ویلیو — فی گاہک کی اوسط آمدنی کے اوسط تعلقات کی لمبائی
8. سیلز سائیکل کی لمبائی — مواقع کی تخلیق سے جیتنے تک کے دن (crm_lead)
9. اقتباس سے آرڈر کی تبدیلی کی شرح — تصدیق شدہ آرڈرز کو کل کوٹیشن سے تقسیم کیا گیا
10. اوسط رعایت % — سیل_آرڈر_لائن ڈسکاؤنٹ فیلڈ سے

آپریشنز KPIs

11. پرفیکٹ آرڈر ریٹ — صحیح دستاویزات کے ساتھ، مکمل طور پر، وقت پر آرڈر کی فراہمی
12. انوینٹری کی درستگی — اصل شمار بمقابلہ سسٹم شمار (اسٹاک_کوانٹ ایڈجسٹمنٹ سے)
13. سپلائر لیڈ ٹائم قابل اعتبار — اصل رسید کی تاریخ بمقابلہ خریداری کے آرڈرز کی متوقع تاریخ
14. ** ویئر ہاؤس اسپیس یوٹیلائزیشن** — مقبوضہ مقامات کو کل مقامات سے تقسیم کیا گیا
15. واپسی کی شرح - کل فروخت کے فیصد کے طور پر کریڈٹ نوٹس/ریفنڈز

مینوفیکچرنگ KPIs

16. پہلے پاس کی پیداوار — دوبارہ کام کے بغیر معیار کے معائنہ کو پاس کرنے والی اکائیاں کل یونٹوں سے تقسیم
17. شیڈول کی پابندی — پروڈکشن آرڈرز منصوبہ بند تاریخ پر مکمل ہو گئے۔
18. مٹیریل ویسٹ % — BOM کی ضروریات سے زیادہ استعمال ہونے والا خام مال
19. ورک سینٹر کا استعمال — حقیقی پیداواری گھنٹے بمقابلہ دستیاب گھنٹے
20. ناکامیوں کے درمیان اوسط وقت (MTBF) — آلات کی خرابی کے درمیان اوسط آپریٹنگ وقت

ان KPIs میں سے ہر ایک کو مخصوص ٹیبل جوائن اور DAX منطق کی ضرورت ہوتی ہے۔ ECOSIRE's Power BI نفاذ سروس میں تمام بیس کے لیے پہلے سے تعمیر شدہ اقدامات کے ساتھ معیاری KPI لائبریری شامل ہے۔

---

کارکردگی کی اصلاح

استفسار فولڈنگ

Odoo + Power BI انضمام کے لیے کوئوری فولڈنگ واحد سب سے اہم کارکردگی کا تصور ہے۔ جب پاور کوئری کسی تبدیلی کو "فولڈ" کرتی ہے، تو یہ اس قدم کو SQL میں ترجمہ کرتی ہے اور Power BI انجن کی بجائے PostgreSQL سرور پر اس پر عمل کرتی ہے۔

** فولڈ کرنے والے اقدامات:**

• Table.SelectRows (WHERE شق)
• ٹیبل۔کالم منتخب کریں (مخصوص کالم منتخب کریں)
• Table.Sort (ORDER BY)
• Table.Group (GROUP BY)
• Table.Join (JOIN)
• Table.FirstN (LIMIT)

وہ قدم جو فولڈنگ کو توڑتے ہیں:

• Table.AddColumn اپنی مرضی کے M افعال کے ساتھ
• ٹیبل۔بفر
• Table.Pivot/ Table.Unpivot (زیادہ تر معاملات میں)
• کوئی بھی قدم جو فولڈ نہ ہونے والے پہلے قدم کا حوالہ دیتا ہے۔

بہترین عمل: پاور کوئری فولڈنگ پر انحصار کرنے کے بجائے حسب ضرورت SQL سوالات لکھیں۔ یہ آپ کو PostgreSQL کو بھیجے گئے SQL پر مکمل کنٹرول فراہم کرتا ہے اور فولڈنگ غیر یقینی صورتحال کو ختم کرتا ہے۔

درآمد بمقابلہ DirectQuery

زیادہ تر Odoo کی تعیناتیوں کے لیے، انکریمنٹل ریفریش کے ساتھ امپورٹ موڈ کارکردگی اور تازگی کا بہترین توازن فراہم کرتا ہے۔ DirectQuery کو آپریشنل ڈیش بورڈز کے لیے مخصوص کیا جانا چاہیے جہاں 30 منٹ پرانا ڈیٹا ناقابل قبول ہے (مثال کے طور پر، براہ راست مینوفیکچرنگ فلور ڈسپلے)۔

جامع ماڈلز

پاور BI پریمیم کمپوزٹ ماڈلز کو سپورٹ کرتا ہے جو امپورٹ اور ڈائریکٹ کوری ٹیبلز کو یکجا کرتے ہیں۔ یہ Odoo کے انضمام کے لیے مثالی ہے جہاں:

• بڑی تاریخی میزیں (سیلز آرڈرز، جرنل اندراجات) اضافی ریفریش کے ساتھ امپورٹ موڈ کا استعمال کریں
• چھوٹی، تیزی سے بدلتی ہوئی میزیں (لائیو انوینٹری کے لیے اسٹاک_کوانٹ) DirectQuery کا استعمال کریں
• تاریخ کا طول و عرض اور دیگر جہتیں ڈوئل اسٹوریج موڈ استعمال کرتی ہیں۔

---

عام مسائل کا ازالہ کرنا

کنکشن کی خرابیاں

"سرور سے جڑنے سے قاصر" — تصدیق کریں کہ PostgreSQL درست پورٹ (ڈیفالٹ 5432) پر سن رہا ہے اور فائر وال کے قوانین پاور BI گیٹ وے یا آپ کے ڈیسک ٹاپ IP سے ان باؤنڈ کنکشن کی اجازت دیتے ہیں۔ postgresql.conf کو listen_addresses اور pg_hba.conf کے لئے کلائنٹ کی تصدیق کے اصولوں کے لئے چیک کریں۔

"SSL کنکشن درکار ہے" — کنکشن میں sslmode=require شامل کریں۔ خود دستخط شدہ سرٹیفکیٹس کے لیے، آپ کو CA سرٹیفکیٹ درآمد کرنے یا sslmode=allow (پروڈکشن کے لیے تجویز کردہ نہیں) سیٹ کرنے کی ضرورت پڑ سکتی ہے۔

"ٹیبل کے لیے اجازت نامنظور" — پاور BI ڈیٹا بیس صارف کے پاس SELECT مراعات کی کمی ہے۔ GRANT SELECT ON ALL TABLES IN SCHEMA public TO powerbi_readonly; چلائیں اور \dp table_name کے ساتھ psql میں تصدیق کریں۔

ڈیٹا کوالٹی کے مسائل

اہم فیلڈز میں NULL قدریں — Odoo بہت سے فیلڈز کو خالی رکھنے کی اجازت دیتا ہے۔ حساب کی غلطیوں سے بچنے کے لیے SQL سوالات میں COALESCE استعمال کریں یا DAX میں BLANK() کو ہینڈل کریں۔

ڈپلیکیٹ ریکارڈ — Odoo کا ORM بعض اوقات ترمیم کے دوران ریکارڈ کے متعدد ورژن بناتا ہے۔ active = true کے ذریعے فلٹر کریں اور یقینی بنائیں کہ آپ ڈرافٹ اور منسوخ شدہ ریکارڈز کو خارج کرنے کے لیے درست اسٹیٹ فیلڈ استعمال کر رہے ہیں۔

ٹائم زون کی مماثلت نہیں — Odoo UTC میں ٹائم اسٹیمپ اسٹور کرتا ہے۔ پاور BI مقامی ٹائم زون میں بطور ڈیفالٹ ڈسپلے ہوتا ہے۔ معمول پر لانے کے لیے PostgreSQL سوالات میں AT TIME ZONE یا Power Query میں DateTimeZone.SwitchZone استعمال کریں۔

کارکردگی کے مسائل

سست ریفریش اوقات — اضافی ریفریش کو فعال کریں۔ پوری میزیں درآمد کرنے کے بجائے حسب ضرورت SQL استفسارات استعمال کریں۔ غیر فعال ریکارڈ، مسودہ دستاویزات، اور تاریخی ڈیٹا کو اپنی تجزیہ ونڈو سے باہر فلٹر کریں۔

10 سیکنڈ سے زیادہ لوڈ اوقات کی اطلاع دیں — پیچیدہ DAX اقدامات کی جانچ کریں جو بڑی میزوں پر دہراتے ہیں (SUMX، بہت سی قطاروں کے ساتھ فلٹر)۔ بار بار کیلکولیشن سے بچنے کے لیے متغیرات کا استعمال کریں۔ SQL ویوز میں ڈیٹا کو پہلے سے جمع کرنے پر غور کریں۔

گیٹ وے ٹائم آؤٹ — گیٹ وے ڈیٹا سورس کنفیگریشن میں کمانڈ ٹائم آؤٹ میں اضافہ کریں۔ ڈیفالٹ 120 سیکنڈ ہے؛ بڑے Odoo ڈیٹا بیس کے لیے 600 پر سیٹ کریں۔

---

سیکیورٹی کے تحفظات

ڈیٹا بیس سیکیورٹی

Odoo ایڈمن ڈیٹا بیس صارف کا استعمال کرتے ہوئے Power BI کو Odoo سے کبھی بھی متصل نہ کریں۔ جیسا کہ پہلے دکھایا گیا ہے ایک وقف صرف پڑھنے کے لیے صارف بنائیں۔ ان اضافی اقدامات پر غور کریں:

• قطار کی سطح کی پابندیاں: اگر آپ نہیں چاہتے ہیں کہ پاور BI تمام ٹیبلز تک رسائی حاصل کرے (مثال کے طور پر، hr_payslip کو چھوڑ کر) صرف پڑھنے والے صارف کی رسائی کو محدود کرنے کے لیے PostgreSQL CREATE POLICY استعمال کریں۔
• کالم ماسکنگ: ایسے نظارے بنائیں جو حساس کالموں (تنخواہ، SSN، بینک کی تفصیلات) کو خارج کر دیں اور پاور BI کو بیس ٹیبل کے بجائے ویوز تک رسائی فراہم کریں۔
• کنکشن کی خفیہ کاری: PostgreSQL کنکشنز کے لیے ہمیشہ SSL استعمال کریں، خاص طور پر جب Power BI گیٹ وے اور Odoo ڈیٹا بیس مختلف نیٹ ورکس پر ہوں۔
• آڈٹ لاگنگ: پاور BI صارف کے تمام سوالات کو ٹریک کرنے کے لیے PostgreSQL pgaudit کو فعال کریں۔

پاور BI سیکیورٹی

• پاور BI میں قطار کی سطح کی سیکیورٹی (RLS) کو لاگو کریں جو Odoo کے ملٹی کمپنی تک رسائی کے قوانین کی آئینہ دار ہو۔
• مالیاتی یا HR ڈیٹا پر مشتمل ڈیٹا سیٹس کے لیے حساسیت کے لیبل استعمال کریں۔
• مجاز تجزیہ کاروں اور صارفین تک ورک اسپیس کی رسائی کو محدود کریں۔
• ڈیٹا کے اخراج کو روکنے کے لیے حساس رپورٹس پر ڈیٹا ایکسپورٹ کو غیر فعال کریں۔

Power BI سیکیورٹی کے بارے میں گہرا غوطہ لگانے کے لیے، ہماری گائیڈ رو لیول سیکیورٹی کے نفاذ پر دیکھیں۔

---

یہ سب ایک ساتھ رکھنا: نفاذ کا روڈ میپ

فیز 1: فاؤنڈیشن (ہفتہ 1-2)

1. Odoo ڈیٹا بیس پر صرف پڑھنے کے لیے PostgreSQL صارف بنائیں
2. آن پریمیسس ڈیٹا گیٹ وے کو انسٹال اور کنفیگر کریں (اگر پاور BI سروس استعمال کر رہے ہیں)
3. Power BI ڈیسک ٹاپ کو Odoo ڈیٹا بیس سے مربوط کریں۔
4. پانچ بنیادی ٹیبل گروپس درآمد کریں (سیلز، اکاؤنٹنگ، انوینٹری، مینوفیکچرنگ، HR)
5. تاریخ کا طول و عرض بنائیں اور تعلقات قائم کریں۔

فیز 2: کور ڈیش بورڈز (ہفتہ 3-4)

1. ایگزیکٹو سیلز ڈیش بورڈ بنائیں (آمدنی، ترقی، اعلی مصنوعات، پائپ لائن)
2. فنانس ڈیش بورڈ بنائیں (اے آر ایجنگ، کیش فلو، بجٹ میں فرق)
3. انوینٹری کا ڈیش بورڈ بنائیں (اسٹاک کی سطح، ٹرن اوور، الرٹس کو دوبارہ ترتیب دیں)
4. تمام فیکٹ ٹیبلز کے لیے اضافی ریفریش کو ترتیب دیں۔
5. پاور BI سروس پر شائع کریں اور شیڈول ریفریش سیٹ اپ کریں۔

فیز 3: ایڈوانسڈ تجزیات (ہفتہ 5-6)

1. مینوفیکچرنگ ڈیش بورڈز بنائیں (OEE، استعمال، پروڈکشن شیڈولنگ)
2. HR ڈیش بورڈز بنائیں (ہیڈ کاؤنٹ، اٹریشن، حاضری، غیر حاضری)
3. ملٹی کمپنی ڈیٹا آئسولیشن کے لیے قطار کی سطح کی حفاظت کو لاگو کریں۔
4. کلیدی ڈیش بورڈز کے لیے موبائل کے لیے موزوں ترتیب بنائیں
5. اہم KPIs کے لیے ڈیٹا الرٹس مرتب کریں (اسٹاک آؤٹ، زائد المیعاد رسیدیں، پیداوار میں تاخیر)

فیز 4: گورننس اور اسکیل (ہفتہ 7-8)

1. ورک اسپیس کے نام کے کنونشنز اور مواد کی تصدیق قائم کریں۔
2. بجلی استعمال کرنے والوں کو سیلف سروس رپورٹ بنانے کی تربیت دیں۔
3. ڈیٹا ماڈل اور حساب کی منطق کو دستاویز کریں۔
4. اپنانے کو ٹریک کرنے کے لیے استعمال کی نگرانی قائم کریں۔
5. اضافی ڈیٹا ذرائع (مارکیٹنگ پلیٹ فارمز، ای کامرس، IoT) کے لیے منصوبہ بنائیں

ECOSIRE کی Power BI + Odoo انٹیگریشن سروس اس روڈ میپ کی پیروی کرتی ہے اور عام طور پر دو ہفتوں کے اندر پہلا ایگزیکٹو ڈیش بورڈ فراہم کرتی ہے۔ Odoo کے ڈیٹا ماڈل اور پاور BI کے تجزیاتی انجن میں ہماری ٹیم کی دوہری مہارت اس بات کو یقینی بناتی ہے کہ آپ کو پہلے دن سے ہی درست، پرفارمنس، اور حکومتی تجزیات حاصل ہوں۔

---

اکثر پوچھے گئے سوالات

کیا میں Power BI کو Odoo آن لائن، یا صرف خود میزبان Odoo سے جوڑ سکتا ہوں؟

آپ دونوں سے جڑ سکتے ہیں، لیکن طریقہ مختلف ہے۔ خود میزبان Odoo آپ کو براہ راست PostgreSQL رسائی فراہم کرتا ہے، جو تیز اور زیادہ لچکدار ہے۔ Odoo Online اور Odoo.sh ڈیٹا بیس کو براہ راست ظاہر نہیں کرتے ہیں، لہذا آپ کو Odoo کے JSON-RPC API، کمیونٹی OData کنیکٹر ماڈیول، یا اسٹیجنگ ڈیٹا بیس میں شیڈول ڈیٹا ایکسپورٹ کرنے کی ضرورت ہے۔ بڑے ڈیٹا سیٹس کے ساتھ Odoo آن لائن کے لیے، اسٹیجنگ ڈیٹا بیس اپروچ کی سفارش کی جاتی ہے کیونکہ 50,000 سے زیادہ ریکارڈ والے ٹیبلز کے لیے API پر مبنی نکالنا سست ہے۔

Power BI Odoo سے ڈیٹا کو کتنی بار ریفریش کر سکتا ہے؟

پاور BI پرو کے ساتھ، آپ روزانہ 8 ریفریشس (ہر 3 گھنٹے بعد) شیڈول کر سکتے ہیں۔ پاور BI پریمیم کے ساتھ، آپ روزانہ 48 ریفریشس (ہر 30 منٹ میں) شیڈول کر سکتے ہیں۔ ریئل ٹائم ڈیٹا کے لیے، DirectQuery موڈ کا استعمال کریں، لیکن آگاہ رہیں کہ ہر رپورٹ کا تعامل براہ راست آپ کے Odoo ڈیٹا بیس سے استفسار کرے گا۔ انکریمنٹل ریفریش ہر ریفریش میں لگنے والے وقت کو کم کر دیتی ہے، جس سے ڈیٹا بیس کو اوور لوڈ کیے بغیر زیادہ بار بار ریفریش کو عملی شکل دی جاتی ہے۔

کیا Power BI کے سوالات ہمارے Odoo سسٹم کو سست کر دیں گے؟

اگر آپ امپورٹ موڈ (تجویز کردہ) استعمال کرتے ہیں، تو پاور BI سوالات صرف شیڈول ریفریشز کے دوران چلتے ہیں --- عام طور پر آف پیک اوقات کے دوران۔ Odoo کی کارکردگی پر اثر کم سے کم ہے۔ اگر آپ DirectQuery استعمال کرتے ہیں، تو ہر رپورٹ کا تعامل آپ کے Odoo ڈیٹا بیس کے خلاف لائیو سوالات پیدا کرتا ہے، جو کاروباری اوقات کے دوران کارکردگی کو متاثر کر سکتا ہے۔ تخفیف میں پڑھی ہوئی نقل کا استعمال، استفسار کے ٹائم آؤٹ کو ترتیب دینا، اور انڈیکس استعمال کرنے والے موثر SQL سوالات کو ڈیزائن کرنا شامل ہے۔

کیا انضمام کو ترتیب دینے کے لیے مجھے SQL جاننے کی ضرورت ہے؟

بنیادی SQL علم مددگار ہے لیکن سختی سے ضروری نہیں ہے۔ پاور BI کا پاور کوئری انٹرفیس آپ کو میزیں منتخب کرنے اور بصری طور پر فلٹرز لگانے دیتا ہے۔ تاہم، بہترین کارکردگی اور ڈیٹا کے معیار کے لیے، حسب ضرورت SQL سوالات کی سختی سے سفارش کی جاتی ہے۔ وہ آپ کو جدولوں کو پہلے سے جوائن کرنے، غیر ضروری ریکارڈز کو فلٹر کرنے اور ڈیٹا بیس کی سطح پر ڈیٹا کی شکل دینے کی اجازت دیتے ہیں۔ اگر آپ کی ٹیم میں SQL مہارت کی کمی ہے تو، ابتدائی سیٹ اپ کے لیے کسی ماہر کو شامل کرنے اور پھر پاور BI کے بصری ٹولز کے ساتھ رپورٹس کو برقرار رکھنے پر غور کریں۔

ECOSIRE کی Odoo + Power BI سروس عام Power BI مشاورت سے کیسے مختلف ہے؟

زیادہ تر پاور BI مشاورتی فرموں کو پاور BI میں مہارت حاصل ہے لیکن اوڈو کے ڈیٹا ماڈل کے بارے میں محدود معلومات ہیں۔ وہ معکوس انجینئرنگ ٹیبل تعلقات، Odoo کے مخصوص کنونشنز (جیسے دوہری پروڈکٹ_پروڈکٹ / پروڈکٹ_ٹیمپلیٹ ڈھانچہ) کو سمجھنے اور یہ جاننے میں گزارتے ہیں کہ کون سے فیلڈز معنی خیز ہیں۔ ECOSIRE نے 43 سے زیادہ Odoo ماڈیولز بنائے اور تعینات کیے ہیں اور دونوں پلیٹ فارمز میں گہری مہارت کو برقرار رکھا ہے۔ ہم پہلے سے تیار کردہ ڈیٹا ماڈل، 50 سے زیادہ اقدامات کے ساتھ ایک معیاری KPI لائبریری، اور رائٹ_ڈیٹ کالموں پر اضافی ریفریش جیسے اوڈو کے لیے مخصوص اصلاح فراہم کرتے ہیں۔ یہ دوہری مہارت Odoo کے ڈیٹا ماڈل کو شروع سے سیکھنے والی ٹیموں کے مقابلے میں عمل درآمد کے وقت کو 40-60 فیصد تک کم کرتی ہے۔