الدليل الكامل لتكامل Power BI + Odoo

يعد Odoo أحد أقوى منصات تخطيط موارد المؤسسات (ERP) مفتوحة المصدر في العالم، مع أكثر من 12 مليون مستخدم و43 وحدة رسمية تغطي كل شيء بدءًا من المبيعات والمخزون وحتى التصنيع والموارد البشرية. Power BI هي منصة ذكاء الأعمال الرائدة في الصناعة مع أكثر من 300 مليون مستخدم نشط شهريًا. ومع ذلك، فمن المثير للدهشة أن عددًا قليلاً من المنظمات تربط بين هذين النظامين --- مما يترك قيمة تحليلية هائلة على الطاولة.

السبب واضح ومباشر: لدى Odoo تقارير مدمجة خاصة به، وتركز معظم استشارات Power BI على تكاملات Microsoft Dynamics أو SAP أو Salesforce. عدد قليل جدًا من الشركات لديها خبرة عميقة في كلا المنصتين. في ECOSIRE، قمنا ببناء ونشر أكثر من 43 وحدة Odoo وحافظنا على خبرة عميقة في Power BI، مما يجعل مجموعة Odoo + Power BI واحدة من تخصصاتنا الأساسية. يلخص هذا الدليل كل ما تعلمناه من العشرات من عمليات التكامل في العالم الحقيقي.

---

الوجبات السريعة الرئيسية

• يمكن ربط قاعدة بيانات PostgreSQL الخاصة بـ Odoo مباشرة بـ Power BI Desktop باستخدام موصل PostgreSQL الأصلي، مما يتيح لك الوصول الكامل إلى كل جدول وحقل
• جداول Odoo الخمسة الأكثر قيمة للتحليلات هي Sale_order، وaccount_move، وstock_picking، وhr_employee، وmrp_production --- وتغطي معًا 80 بالمائة من احتياجات إعداد التقارير التنفيذية
• يمكن أن يؤدي التحديث المتزايد في Power BI إلى تقليل أوقات تحميل بيانات Odoo من ساعات إلى دقائق عن طريق جلب السجلات التي تغيرت منذ آخر تحديث فقط
• توفر نقاط نهاية OData وواجهة برمجة تطبيقات Odoo الخارجية بدائل صديقة للسحابة عندما لا يكون الوصول المباشر إلى قاعدة البيانات متاحًا
• يمكن للأمان على مستوى الصف في Power BI أن يعكس عناصر التحكم في الوصول للشركات المتعددة في Odoo، مما يضمن أن المستخدمين لا يرون سوى البيانات من الشركات المخصصة لهم
• تتفوق استعلامات SQL المخصصة مقابل قاعدة بيانات PostgreSQL الخاصة بـ Odoo على عمليات استيراد الجدول العامة بمقدار 5-10x لأنه يمكنك التصفية والانضمام والتجميع على مستوى قاعدة البيانات
• يؤدي نشر Odoo + Power BI المصمم جيدًا إلى استبدال العشرات من تقارير جداول البيانات بمنصة تحليلات واحدة محكومة

---

لماذا يعد Odoo + Power BI مزيجًا قويًا

القيود المفروضة على التقارير المدمجة في Odoo

يأتي Odoo مزودًا بالعديد من أدوات إعداد التقارير: طرق العرض المحورية، وطرق عرض الرسم البياني، ولوحة التحكم المدمجة. بالنسبة للعمليات اليومية، فهذه كافية. لكنها لا تفي بتحليلات المؤسسات بعدة طرق مهمة.

أولاً، لا يمكن لعروض Odoo المحورية دمج البيانات من وحدات متعددة في تصور واحد. لا يمكنك تراكب إيرادات المبيعات مع معدل دوران المخزون وإنتاجية التصنيع في مخطط واحد. يتم عزل تقارير كل وحدة.

ثانيًا، يفتقر Odoo إلى وظائف تحليل الوقت. تتطلب المقارنات السنوية والمتوسطات المتدرجة والإجماليات التراكمية وحسابات الفترة حتى تاريخه تطويرًا مخصصًا أو تصدير جداول البيانات يدويًا.

ثالثًا، ليس لدى Odoo مفهوم لنموذج البيانات المحكومة. لا توجد تعريفات مشتركة لمقاييس مثل "الإيرادات" أو "القيمة الدائمة للعميل". يقوم كل مستخدم بإنشاء تفسيره الخاص، مما يؤدي إلى أرقام متضاربة في اجتماعات الإدارة.

رابعًا، تقتصر إمكانيات التصور في Odoo على المخططات الشريطية الأساسية، والمخططات الخطية، والمخططات الدائرية. لا تتوفر الخرائط الحرارية والمخططات المبعثرة والمخططات الانحدارية وأشجار التحليل وبطاقات KPI.

ما يضيفه Power BI

يعالج Power BI كل واحد من هذه القيود. وهو يتصل بقاعدة بيانات PostgreSQL (أو واجهة برمجة التطبيقات) الخاصة بـ Odoo ويقوم بإنشاء نموذج دلالي موحد عبر جميع الوحدات. توفر صيغ DAX معلومات الوقت والوظائف الإحصائية ومنطق الأعمال المعقد. تتضمن مكتبة التصورات أكثر من 300 نوع من الرسوم البيانية. وميزات حوكمة Power BI --- مساحات العمل، والأمان على مستوى الصف، والمصادقة، وعلامات الحساسية --- توفر إدارة البيانات على مستوى المؤسسة.

يمنحك هذا المزيج التميز التشغيلي لـ Odoo للعمل اليومي والعمق التحليلي لـ Power BI لاتخاذ القرارات الإستراتيجية. تستمر فرق العمليات في العمل في Odoo؛ يحصل المديرون التنفيذيون والمحللون على لوحات معلومات Power BI التي يتم تحديثها تلقائيًا.

---

طرق الاتصال: قاعدة البيانات المباشرة مقابل واجهة برمجة التطبيقات

هناك ثلاث طرق أساسية لتوصيل Power BI بـ Odoo. لكل منها مقايضات اعتمادًا على طراز الاستضافة ومتطلبات الأمان الخاصة بك.

الطريقة الأولى: اتصال PostgreSQL المباشر

هذه هي الطريقة المفضلة لعمليات نشر Odoo المحلية أو المستضافة ذاتيًا. يقوم Odoo بتخزين جميع البيانات في PostgreSQL، ويحتوي Power BI على موصل PostgreSQL أصلي.

المزايا:

• أسرع أداء للاستعلام (بدون حمل لواجهة برمجة التطبيقات)
• الوصول الكامل إلى كل جدول وحقل، بما في ذلك الوحدات المخصصة
• يدعم استعلامات SQL المعقدة مع الصلات والتجمعات على مستوى قاعدة البيانات
• تمكين التحديث المتزايد (يتطلب عمود التاريخ والوقت)
• لا يوجد ترخيص Odoo أو حدود لمعدلات API

خطوات الإعداد:

1. افتح Power BI Desktop وحدد Get Data، ثم قاعدة بيانات PostgreSQL
2. أدخل اسم مضيف خادم Odoo واسم قاعدة البيانات (عادةً اسم مثيل Odoo)
3. استخدم مستخدم قاعدة بيانات للقراءة فقط (وليس حساب مسؤول Odoo أبدًا)
4. حدد وضع الاستيراد لمعظم السيناريوهات، أو DirectQuery لتلبية الاحتياجات في الوقت الفعلي
5. انتقل إلى قائمة الجدول أو استخدم استعلام SQL مخصص

** معلمات سلسلة الاتصال: **

إنشاء مستخدم للقراءة فقط في 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;

يضمن هذا الأسلوب أن يتمكن Power BI من قراءة جميع الجداول الحالية والمستقبلية دون أي حق وصول للكتابة إلى قاعدة بيانات الإنتاج الخاصة بك.

الطريقة الثانية: واجهة برمجة تطبيقات Odoo الخارجية (XML-RPC / JSON-RPC)

يعرض Odoo واجهة برمجة تطبيقات كاملة لقراءة البيانات وكتابتها. يمكن لـ Power BI استهلاك هذا من خلال الموصلات المخصصة أو البرامج النصية لـ Python.

المزايا:

• يعمل مع Odoo.sh وOdoo Online (لا يلزم الوصول المباشر إلى قاعدة البيانات)
• يحترم قواعد التحكم في الوصول وقواعد التسجيل الخاصة بـ Odoo
• لا حاجة لكشف منفذ قاعدة البيانات خارجيًا

عيوب:

• أبطأ بشكل ملحوظ من استعلامات قاعدة البيانات المباشرة (10-100x لمجموعات البيانات الكبيرة)
• قد تؤدي حدود معدل واجهة برمجة التطبيقات (API) إلى اختناق المستخلصات كبيرة الحجم
• يتطلب وظيفة Power Query مخصصة أو خطوة ETL متوسطة
• ترقيم الصفحات يضيف التعقيد

بالنسبة لنقطة نهاية JSON-RPC الخاصة بـ Odoo، ستستدعي وظيفة Power Query M النموذجية https://your-odoo.com/jsonrpc مع المصادقة ثم تقوم بترقيم النتائج. يعمل هذا ولكنه يصبح غير عملي بالنسبة للجداول التي تحتوي على أكثر من 50000 سجل.

الطريقة الثالثة: نقاط نهاية OData عبر وحدات موصل Odoo

تعرض العديد من وحدات مجتمع Odoo خلاصات OData التي يمكن أن يستهلكها Power BI محليًا. يدعم موصل OData في Power BI المصادقة وترقيم الصفحات خارج الصندوق.

متى تستخدم هذه الطريقة:

• عمليات نشر Odoo Online / Odoo.sh حيث يكون الوصول إلى قاعدة البيانات مقيدًا
• السيناريوهات التي تتطلب منطق أعمال Odoo (الحقول المحسوبة، وقواعد الوصول) في البيانات
• مجموعات بيانات أصغر (أقل من 100000 سجل لكل كيان)

بالنسبة لمعظم عمليات النشر المؤسسية، يوصى بشدة باستخدام الطريقة الأولى (PostgreSQL المباشرة). الفرق في الأداء كبير، وتسمح لك مرونة استعلامات SQL بتشكيل البيانات في المصدر.

---

جداول Odoo الأساسية لبرنامج Power BI

تحتوي قاعدة بيانات PostgreSQL الخاصة بـ Odoo على مئات الجداول. يعد فهم الجداول الأساسية والعلاقات بينها أمرًا بالغ الأهمية لبناء نماذج 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;

جداول وحدة المحاسبة

التمييز الحاسم: في Odoo، يقوم account_move بتخزين الفواتير (move_type = 'out_invoice')، وفواتير المورد ('in_invoice')، وإشعارات الائتمان ('out_refund'، و'in_refund')، وإدخالات دفتر اليومية ('entry'). قم دائمًا بالتصفية حسب move_type في استعلامات Power BI الخاصة بك.

يخبرك الحقل payment_state في account_move ما إذا كانت الفاتورة "غير مدفوعة"، أو "في_الدفع"، أو "مدفوعة"، أو "جزئية"، أو "معكوسة". يعد هذا أمرًا ضروريًا للوحات معلومات تقادم الحسابات المدينة.

جداول وحدة المخزون

المخزون في الوقت الفعلي: يعكس Stock_quant دائمًا الحالة الحالية للمخزون. لتحليل المخزون التاريخي، تحتاج إلى الاستعلام عن Stock_move باستخدام مرشحات التاريخ وحساب الأرصدة الجارية.

جداول وحدات التصنيع

حساب OEE: يمكن استخلاص الفعالية الإجمالية للمعدات من سجلات mrp_workorder من خلال مقارنة المدة المخططة مقابل المدة الفعلية، وتحليل أسباب التوقف عن العمل، وتتبع مقاييس الجودة.

جداول الموارد البشرية

---

بناء نموذج بيانات Power BI

تصميم مخطط النجوم

يتبع نموذج البيانات الأكثر فعالية لتحليلات Odoo نمط المخطط النجمي. توجد جداول الحقائق (أوامر البيع، الفواتير، تحركات المخزون، أوامر الإنتاج) في المركز. وتحيط بها جداول الأبعاد (المنتجات والعملاء والتواريخ والموظفين والمواقع).

جداول الحقائق الموصى بها:

1. Fact_Sales — من Sale_order + Sale_order_line (الحبوب: صف واحد لكل سطر طلب)
2. Fact_Invoices — من account_move + account_move_line (الحبوب: صف واحد لكل سطر دفتر يومية)
3. Fact_Inventory — من Stock_move (الحبوب: صف واحد لكل حركة سهم)
4. Fact_Production — من mrp_production + mrp_workorder (الحبوب: صف واحد لكل أمر عمل)
5. Fact_Attendance — من hr_attendance (الحبوب: صف واحد لكل زوج دخول/خروج على مدار الساعة)

جداول الأبعاد المشتركة:

1. Dim_Date — جدول تقويم تم إنشاؤه في Power BI (ضروري لتحليل الوقت)
2. Dim_Customer — من res_partner (تمت التصفية إلى customer_rank > 0)
3. Dim_Product — من منتج_المنتج + قالب_المنتج + فئة_المنتج
4. Dim_Employee — من hr_employee + hr_department + hr_job
5. Dim_Location — من موقع المخزون + مخزن المخزون
6. Dim_Company — من res_company (لعمليات نشر Odoo متعددة الشركات)

إنشاء بُعد التاريخ

لا يحتوي Odoo على جدول مخصص لأبعاد التاريخ. يجب عليك إنشاء واحد في Power BI باستخدام DAX:

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]. قم بضبط شهر بداية السنة المالية ليتناسب مع مؤسستك.

التعامل مع هيكل Odoo متعدد الشركات

يدعم Odoo تكوينات الشركات المتعددة حيث تخدم قاعدة بيانات واحدة كيانات قانونية متعددة. يتضمن كل جدول معاملات مفتاحًا خارجيًا company_id. في Power BI، أنشئ جدول Dim_Company من res_company وأنشئ علاقات مع كل جدول حقائق.

للحصول على الأمان على مستوى الصف، استخدم ميزة RLS الخاصة بـ Power BI لتصفية Dim_Company استنادًا إلى تعيين الشركة الخاص بالمستخدم الذي قام بتسجيل الدخول. وهذا يعكس عناصر التحكم في الوصول للشركات المتعددة في Odoo في طبقة BI.

---

وصفات لوحة المعلومات: تحليلات المبيعات

لوحة تحكم المبيعات التنفيذية

تجيب لوحة المعلومات هذه على الأسئلة الخمسة التي يطرحها كل مدير تنفيذي: ما مقدار الإيرادات هذا الشهر؟ هل نحن على المسار الصحيح للربع؟ ما هي المنتجات الفائزة؟ مندوبي المبيعات الذين يؤدون؟ أين هم عملائنا؟

تدابير الإنشاء:

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: أربع بطاقات مؤشرات الأداء الرئيسية (الإيرادات منذ بداية العام، والإيرادات خلال الربع الأول من العام، والإيرادات منذ بداية العام، ونسبة النمو %)
• الصف 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])
)

المرئيات:

• بطاقات مؤشرات الأداء الرئيسية: إجمالي قيمة المخزون، نسبة الدوران، معدل نفاذ المخزون، العناصر التي تقل عن نقطة إعادة الطلب
• المخطط المبعثر: يتم رسم كل منتج حسب معدل الدوران (المحور السيني) مقابل الهامش (المحور الصادي)، وحجمه حسب مساهمة الإيرادات --- هذا هو التحليل المرئي 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 Manufacturing، يوفر جدولي 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، يمكنك بناء نماذج تخطيط السعة التي تتنبأ بالوقت الذي ستصل فيه إلى الحد الأقصى من الاستخدام.

---

وصفات لوحة المعلومات: الموارد البشرية والقوى العاملة

لوحة تحكم تحليلات القوى العاملة

توفر لوحات معلومات الموارد البشرية المبنية من بيانات Odoo رؤى تتقاضى معظم أنظمة معلومات الموارد البشرية أسعارًا مرتفعة مقابلها.

** مقاييس عدد الموظفين ودورانهم: **

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 التي تحتوي على ملايين السجلات، يعد التحديث الكامل للبيانات أمرًا غير عملي. تقوم ميزة التحديث التزايدي في Power BI بتحميل السجلات الجديدة والمتغيرة فقط، مما يقلل أوقات التحديث من ساعات إلى دقائق.

المتطلبات الأساسية

• ترخيص Power BI Pro أو Premium
• يجب أن يحتوي كل جدول على عمود تاريخ/وقت يمكن الاعتماد عليه (يعد write_date في Odoo مثاليًا --- ويتم تحديثه كلما تم تعديل السجل)
• يجب أن يدعم مصدر البيانات طي الاستعلام (يدعم PostgreSQL ذلك)

خطوات التكوين

الخطوة 1: إنشاء معلمات RangeStart وRangeEnd

في Power Query، قم بإنشاء معلمتين من النوع DateTime:

• RangeStart: القيمة الافتراضية = 1/1/2020 12:00:00 صباحًا
• RangeEnd: القيمة الافتراضية = 31/12/2030 12:00:00 ص

الخطوة 2: تصفية الجداول حسب المعلمات

لكل جدول حقائق، أضف خطوة تصفية في Power Query:

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

يجب أن يتم طي هذا المرشح إلى قاعدة البيانات (يظهر في SQL الذي تم إنشاؤه). تحقق من خلال النقر بزر الماوس الأيمن على الخطوة وتحديد "عرض الاستعلام الأصلي".

الخطوة 3: تحديد سياسة التحديث التزايدي

انقر بزر الماوس الأيمن فوق الجدول الموجود في النموذج، وحدد تحديث تزايدي، وقم بتكوين:

يقوم هذا التكوين بتخزين ثلاث سنوات من المحفوظات ولكنه يقوم فقط بتحديث الأيام السبعة الأخيرة أثناء كل تحديث مجدول. يتم تحديث عمود write_date الخاص بـ Odoo تلقائيًا عند تغيير أي حقل في السجل، مما يجعله عمودًا موثوقًا لاكتشاف التغيير.

تأثير الأداء

تعتبر مكاسب الأداء هائلة، خاصة بالنسبة لمجموعات بيانات التصنيع والمخزون التي تولد كميات كبيرة من بيانات المعاملات.

---

متقدم: متعدد الشركات ومتعدد العملات

التعامل مع عمليات نشر Odoo متعددة الشركات

تخدم العديد من عمليات نشر Odoo Enterprise كيانات قانونية متعددة من قاعدة بيانات واحدة. يحتوي كل سجل معاملة على حقل company_id. في الطاقة BI:

1. قم بإنشاء جدول Dim_Company من res_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;

وبدلاً من ذلك، احتفظ بجدول Dim_Currency_Rate في Power BI مع أسعار الصرف اليومية واستخدم DAX للتحويل في وقت التقرير. يعتبر هذا النهج أكثر مرونة بالنسبة لسيناريوهات "ماذا لو" (على سبيل المثال، "كيف ستبدو الإيرادات بأسعار الصرف في العام الماضي؟").

---

تكامل OData وREST API لـ Odoo Online

بالنسبة للمؤسسات التي تستخدم Odoo Online أو Odoo.sh حيث لا يتوفر الوصول المباشر إلى PostgreSQL، توجد طرق اتصال بديلة.

استخدام واجهة برمجة تطبيقات JSON-RPC الخاصة بـ Odoo

يعرض Odoo نقطة نهاية JSON-RPC عند /jsonrpc (أو 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}
    ]
  }
}

في Power BI، يمكنك تنفيذ ذلك كوظيفة Power Query مخصصة باستخدام Web.Contents مع منطق ترقيم الصفحات. يتمثل التحدي في الأداء: حيث يُرجع كل استدعاء لواجهة برمجة التطبيقات بضعة آلاف من السجلات على الأكثر، وتحتاج إلى عدة رحلات ذهابًا وإيابًا لمجموعات البيانات الكبيرة.

وحدات بيانات OData المجتمعية

تضيف العديد من وحدات مجتمع Odoo نقاط نهاية OData:

• BI Connector for Odoo — يعرض موجزات OData القابلة للتكوين
• Odoo-Power BI Connector — نماذج بيانات معدة مسبقًا للوحدات النمطية الشائعة

تعمل هذه الوحدات على تبسيط عملية التكامل ولكنها تضيف تبعية إلى مثيل Odoo الخاص بك. قم بتقييم ما إذا كانت الراحة تفوق عبء الصيانة لوحدة المجتمع.

النهج المختلط: تصدير البيانات المجدولة

الحل الوسط العملي هو جدولة تصدير البيانات ليلاً من Odoo إلى قاعدة بيانات مرحلية أو Azure SQL. يقوم إجراء Odoo المجدول بتشغيل برنامج Python النصي الذي يصدر الجداول الرئيسية إلى ملف CSV أو يدفع البيانات عبر واجهة برمجة التطبيقات (API) إلى قاعدة بيانات Azure SQL. يتصل Power BI بعد ذلك بقاعدة البيانات المرحلية مع دعم كامل لطي الاستعلام.

يعمل هذا الأسلوب بشكل جيد مع المؤسسات التي ترغب في تحديث البيانات بشكل شبه يومي دون تعريض قاعدة بيانات إنتاج Odoo لاستعلامات Power BI.

---

أمثلة على مؤشرات الأداء الرئيسية في العالم الحقيقي

فيما يلي عشرين مؤشر أداء رئيسي يقوم عملاء ECOSIRE بإنشائها بشكل متكرر بعد توصيل Odoo بـ Power BI، ويتم تنظيمها حسب القسم.

مؤشرات الأداء الرئيسية المالية

1. أيام المبيعات المعلقة (DSO) — متوسط الأيام لتحصيل الدفع، من account_move (تاريخ الفاتورة مقابل تاريخ الدفع)
2. الهامش الإجمالي % — الإيرادات ناقص تكلفة البضائع المبيعة مقسومة على الإيرادات، من سطر_طلب_البيع (السعر_الإجمالي_الإجمالي مقابل سعر_قياسي_المنتج)
3. دورة التحويل النقدي — DSO + أيام المخزون المعلقة - الأيام المستحقة الدفع
4. الميزانية مقابل التباين الفعلي — يتطلب جدول ميزانية (account_budget في Odoo أو تحميل يدوي)
5. الإيرادات لكل موظف — إجمالي الإيرادات مقسومًا على عدد الموظفين النشطين

مؤشرات الأداء الرئيسية للمبيعات

6. تكلفة اكتساب العميل — الإنفاق التسويقي مقسومًا على العملاء الجدد المكتسبين (يتطلب إدخال تكلفة التسويق يدويًا)
7. القيمة الدائمة للعميل — متوسط الإيرادات لكل عميل مضروبًا في متوسط طول العلاقة
8. طول دورة المبيعات — عدد الأيام منذ إنشاء الفرصة وحتى الفوز (crm_lead)
9. معدل التحويل من عرض الأسعار إلى الطلب — الطلبات المؤكدة مقسومة على إجمالي عروض الأسعار
10. متوسط الخصم % — من حقل الخصم في خط_طلب_الطلب

مؤشرات الأداء الرئيسية للعمليات

11. معدل الطلب المثالي — يتم تسليم الطلبات في الوقت المحدد، بالكامل، مع الوثائق الصحيحة
12. دقة المخزون — العدد الفعلي مقابل عدد النظام (من تعديلات كمية المخزون)
13. موثوقية المهلة الزمنية للمورد — تاريخ الاستلام الفعلي مقابل التاريخ المتوقع من أوامر الشراء
14. استغلال مساحة المستودعات — المواقع المشغولة مقسومة على إجمالي المواقع
15. معدل الإرجاع — إشعارات الائتمان/المبالغ المستردة كنسبة مئوية من إجمالي المبيعات

مؤشرات الأداء الرئيسية للتصنيع

16. عائد المرور الأول — الوحدات التي تجتاز فحص الجودة دون إعادة العمل مقسومة على إجمالي الوحدات
17. الالتزام بالجدول الزمني — إكمال أوامر الإنتاج في التاريخ المخطط له
18. نفايات المواد % — يتم استهلاك المواد الخام بما يتجاوز متطلبات قائمة مكونات الصنف
19. استخدام مركز العمل — ساعات الإنتاج الفعلية مقابل الساعات المتاحة
20. متوسط الوقت بين الأعطال (MTBF) — متوسط وقت التشغيل بين تعطل المعدات

يتطلب كل من مؤشرات الأداء الرئيسية هذه صلات جدول محددة ومنطق DAX. خدمة تنفيذ Power BI من ECOSIRE تتضمن مكتبة مؤشرات أداء رئيسية قياسية مع مقاييس معدة مسبقًا لجميع العشرين.

---

تحسين الأداء

طي الاستعلام

يعد طي الاستعلام هو مفهوم الأداء الأكثر أهمية لتكاملات Odoo + Power BI. عندما "يطوي" Power Query تحويلاً، فإنه يترجم الخطوة إلى SQL وينفذها على خادم PostgreSQL بدلاً من محرك Power BI.

خطوات الطي:

• Table.SelectRows (حيث عبارة)
• Table.SelectColumns (اختر أعمدة محددة)
• جدول الترتيب (الترتيب حسب)
• جدول المجموعة (GROUP BY)
• الجدول. الانضمام (الانضمام)
• الجدول.FirstN (الحد)

خطوات كسر الطي:

• Table.AddColumn مع وظائف M المخصصة
• الجدول.المخزن المؤقت
• Table.Pivot / Table.Unpivot (في معظم الحالات)
• أي خطوة تشير إلى خطوة سابقة غير قابلة للطي

أفضل الممارسات: اكتب استعلامات SQL مخصصة بدلاً من الاعتماد على طي Power Query. يمنحك هذا التحكم الكامل في SQL المرسلة إلى PostgreSQL ويزيل عدم اليقين القابل للطي.

الاستيراد مقابل الاستعلام المباشر

بالنسبة لمعظم عمليات نشر Odoo، يوفر وضع الاستيراد مع التحديث المتزايد أفضل توازن بين الأداء والحداثة. يجب أن يتم حجز DirectQuery للوحات المعلومات التشغيلية حيث تكون البيانات التي يبلغ عمرها 30 دقيقة غير مقبولة (على سبيل المثال، عرض أرضي للتصنيع المباشر).

النماذج المركبة

يدعم Power BI Premium النماذج المركبة التي تجمع بين جداول الاستيراد وDirectQuery. يعد هذا مثاليًا لعمليات تكامل Odoo حيث:

• تستخدم الجداول التاريخية الكبيرة (أوامر المبيعات، وإدخالات دفتر اليومية) وضع الاستيراد مع التحديث المتزايد
• الجداول الصغيرة سريعة التغير (stock_quant للمخزون المباشر) تستخدم DirectQuery
• يستخدم بُعد التاريخ والأبعاد الأخرى وضع التخزين المزدوج

---

استكشاف المشكلات الشائعة وإصلاحها

أخطاء الاتصال

"غير قادر على الاتصال بالخادم" — تحقق من أن PostgreSQL يستمع على المنفذ الصحيح (الافتراضي 5432) وأن قواعد جدار الحماية تسمح بالاتصالات الواردة من بوابة Power BI أو IP لسطح المكتب. تحقق من postgresql.conf لـ listen_addresses وpg_hba.conf لقواعد مصادقة العميل.

"اتصال SSL مطلوب" — أضف sslmode=require إلى الاتصال. بالنسبة للشهادات الموقعة ذاتيًا، قد تحتاج إلى استيراد شهادة CA أو تعيين sslmode=allow (غير مستحسن للإنتاج).

"تم رفض الإذن للجدول" — يفتقر مستخدم قاعدة بيانات Power BI إلى امتيازات SELECT. قم بتشغيل GRANT SELECT ON ALL TABLES IN SCHEMA public TO powerbi_readonly; وتحقق باستخدام \dp table_name في psql.

مشكلات جودة البيانات

قيم فارغة في الحقول المهمة — يسمح Odoo بأن تكون العديد من الحقول فارغة. استخدم COALESCE في استعلامات SQL أو تعامل مع BLANK() في DAX لتجنب أخطاء الحساب.

السجلات المكررة — يقوم ORM أحيانًا بإنشاء إصدارات متعددة من السجلات أثناء التحرير. قم بالتصفية حسب active = true وتأكد من أنك تستخدم حقل الحالة الصحيح لاستبعاد المسودات والسجلات الملغاة.

عدم تطابق المنطقة الزمنية — يقوم Odoo بتخزين الطوابع الزمنية بالتوقيت العالمي المنسق (UTC). يتم عرض Power BI بالمنطقة الزمنية المحلية بشكل افتراضي. استخدم AT TIME ZONE في استعلامات PostgreSQL أو DateTimeZone.SwitchZone في Power Query للتطبيع.

مشكلات الأداء

أوقات التحديث بطيئة — تمكين التحديث المتزايد. استخدم استعلامات SQL المخصصة بدلاً من استيراد الجداول بأكملها. قم بتصفية السجلات غير النشطة ومسودات المستندات والبيانات التاريخية خارج نافذة التحليل الخاصة بك.

أوقات تحميل التقرير التي تزيد عن 10 ثوانٍ — تحقق من وجود مقاييس DAX المعقدة التي تتكرر عبر الجداول الكبيرة (SUMX، FILTER مع العديد من الصفوف). استخدم المتغيرات لتجنب الحسابات المتكررة. فكر في التجميع المسبق للبيانات في طرق عرض SQL.

مهلات البوابة — قم بزيادة مهلة الأمر في تكوين مصدر بيانات البوابة. الافتراضي هو 120 ثانية؛ تم ضبطه على 600 لقواعد بيانات Odoo الكبيرة.

---

الاعتبارات الأمنية

أمن قاعدة البيانات

لا تقم أبدًا بتوصيل Power BI بـ Odoo باستخدام مستخدم قاعدة بيانات مسؤول Odoo. قم بإنشاء مستخدم مخصص للقراءة فقط كما هو موضح سابقًا. خذ بعين الاعتبار هذه التدابير الإضافية:

• القيود على مستوى الصف: استخدم PostgreSQL CREATE POLICY لتقييد وصول المستخدم للقراءة فقط إذا كنت لا تريد أن يصل Power BI إلى جميع الجداول (على سبيل المثال، باستثناء hr_payslip)
• إخفاء الأعمدة: قم بإنشاء عروض تستبعد الأعمدة الحساسة (الراتب، ورقم الضمان الاجتماعي، وتفاصيل البنك) ومنح Power BI حق الوصول إلى طرق العرض بدلاً من الجداول الأساسية
• تشفير الاتصال: استخدم دائمًا SSL لاتصالات PostgreSQL، خاصةً عندما تكون بوابة Power BI وقاعدة بيانات Odoo على شبكات مختلفة
• تسجيل التدقيق: قم بتمكين PostgreSQL pgaudit لتتبع جميع الاستعلامات من مستخدم Power BI

أمان Power BI

• تنفيذ الأمان على مستوى الصف (RLS) في Power BI الذي يعكس قواعد الوصول للشركات المتعددة في Odoo
• استخدم تسميات الحساسية لمجموعات البيانات التي تحتوي على بيانات مالية أو بيانات تتعلق بالموارد البشرية
• تقييد الوصول إلى مساحة العمل على المحللين والمستهلكين المعتمدين
• تعطيل تصدير البيانات في التقارير الحساسة لمنع تسرب البيانات

للتعمق في أمان Power BI، راجع دليلنا حول تنفيذ الأمان على مستوى الصف.

---

تجميع كل ذلك معًا: خريطة طريق التنفيذ

المرحلة الأولى: الأساس (الأسبوع 1-2)

1. قم بإنشاء مستخدم PostgreSQL للقراءة فقط في قاعدة بيانات Odoo
2. تثبيت وتكوين بوابة البيانات المحلية (في حالة استخدام Power BI Service)
3. قم بتوصيل Power BI Desktop بقاعدة بيانات Odoo
4. استيراد مجموعات الجدول الأساسية الخمس (المبيعات، المحاسبة، المخزون، التصنيع، الموارد البشرية)
5. بناء بُعد التاريخ وإقامة العلاقات

المرحلة الثانية: لوحات المعلومات الأساسية (الأسبوع 3-4)

1. قم ببناء لوحة تحكم المبيعات التنفيذية (الإيرادات، النمو، أفضل المنتجات، خط الأنابيب)
2. بناء لوحة المعلومات المالية (تقادم الواقع المعزز، والتدفق النقدي، وتباين الميزانية)
3. إنشاء لوحة تحكم المخزون (مستويات المخزون، معدل الدوران، تنبيهات إعادة الطلب)
4. قم بتكوين التحديث المتزايد لجميع جداول البيانات الفعلية
5. انشر على Power BI Service وقم بإعداد التحديث المجدول

المرحلة الثالثة: التحليلات المتقدمة (الأسبوع 5-6)

1. بناء لوحات معلومات التصنيع (OEE، الاستخدام، جدولة الإنتاج)
2. بناء لوحات معلومات الموارد البشرية (عدد الموظفين، التناقص، الحضور، الغياب)
3. تنفيذ الأمان على مستوى الصف لعزل بيانات الشركات المتعددة
4. قم بإنشاء تخطيط محسّن للجوال للوحات المعلومات الرئيسية
5. قم بإعداد تنبيهات البيانات لمؤشرات الأداء الرئيسية الهامة (نفاذ المخزون، والفواتير المتأخرة، وتأخير الإنتاج)

المرحلة الرابعة: الحوكمة والنطاق (الأسبوع 7-8)

1. إنشاء اصطلاحات تسمية مساحة العمل وشهادة المحتوى
2. تدريب المستخدمين المتميزين على إنشاء تقرير الخدمة الذاتية
3. توثيق نموذج البيانات ومنطق الحساب
4. قم بإعداد مراقبة الاستخدام لتتبع الاعتماد
5. التخطيط لمصادر بيانات إضافية (منصات التسويق، التجارة الإلكترونية، إنترنت الأشياء)

خدمة تكامل Power BI + Odoo من ECOSIRE تتبع خريطة الطريق هذه وتقدم عادةً أول لوحة معلومات تنفيذية في غضون أسبوعين. تضمن الخبرة المزدوجة التي يتمتع بها فريقنا في نموذج بيانات Odoo والمحرك التحليلي Power BI حصولك على تحليلات دقيقة وفعالة ومُحكمة منذ اليوم الأول.

---

الأسئلة الشائعة

هل يمكنني توصيل Power BI بـ Odoo Online، أو Odoo المستضاف ذاتيًا فقط؟

يمكنك الاتصال بكليهما، لكن الطريقة تختلف. يمنحك Odoo المستضاف ذاتيًا وصولاً مباشرًا إلى PostgreSQL، وهو أسرع وأكثر مرونة. لا يقوم Odoo Online وOdoo.sh بكشف قاعدة البيانات مباشرة، لذلك تحتاج إلى استخدام واجهة برمجة تطبيقات JSON-RPC الخاصة بـ Odoo، أو وحدة موصل OData المجتمعية، أو تصدير البيانات المجدولة إلى قاعدة بيانات مرحلية. بالنسبة إلى Odoo Online الذي يحتوي على مجموعات بيانات كبيرة، يوصى باستخدام نهج قاعدة البيانات المرحلية لأن الاستخراج المستند إلى واجهة برمجة التطبيقات (API) يكون بطيئًا بالنسبة للجداول التي تحتوي على أكثر من 50000 سجل.

كم مرة يمكن لـ Power BI تحديث البيانات من Odoo؟

باستخدام Power BI Pro، يمكنك جدولة ما يصل إلى 8 عمليات تحديث يوميًا (كل 3 ساعات). باستخدام Power BI Premium، يمكنك جدولة ما يصل إلى 48 عملية تحديث يوميًا (كل 30 دقيقة). للحصول على البيانات في الوقت الفعلي، استخدم وضع DirectQuery، ولكن انتبه إلى أن كل تفاعل مع التقرير سوف يستعلم عن قاعدة بيانات Odoo الخاصة بك مباشرة. يعمل التحديث التزايدي على تقليل الوقت الذي يستغرقه كل تحديث، مما يجعل عمليات التحديث الأكثر تكرارًا عملية دون زيادة التحميل على قاعدة البيانات.

هل تؤدي استعلامات Power BI إلى إبطاء نظام Odoo الخاص بنا؟

إذا كنت تستخدم وضع الاستيراد (مستحسن)، فسيتم تشغيل استعلامات Power BI فقط أثناء عمليات التحديث المجدولة --- عادةً خلال ساعات خارج أوقات الذروة. التأثير على أداء Odoo ضئيل. إذا كنت تستخدم DirectQuery، فإن كل تفاعل مع التقرير يُنشئ استعلامات مباشرة مقابل قاعدة بيانات Odoo الخاصة بك، مما قد يؤثر على الأداء أثناء ساعات العمل. تتضمن عمليات التخفيف استخدام نسخة متماثلة للقراءة، وتكوين مهلات الاستعلام، وتصميم استعلامات SQL فعالة تستخدم الفهارس.

هل أحتاج إلى معرفة SQL لإعداد التكامل؟

المعرفة الأساسية بـ SQL مفيدة ولكنها ليست مطلوبة بشكل صارم. تتيح لك واجهة Power Query الخاصة بـ Power BI تحديد الجداول وتطبيق عوامل التصفية بشكل مرئي. ومع ذلك، للحصول على الأداء الأمثل وجودة البيانات، يوصى بشدة باستعلامات SQL المخصصة. إنها تسمح لك بضم الجداول مسبقًا، وتصفية السجلات غير الضرورية، وتشكيل البيانات على مستوى قاعدة البيانات. إذا كان فريقك يفتقر إلى خبرة SQL، ففكر في الاستعانة بمتخصص للإعداد الأولي ثم الاحتفاظ بالتقارير باستخدام أدوات Power BI المرئية.

كيف تختلف خدمة Odoo + Power BI من ECOSIRE عن استشارات Power BI العامة؟

تتمتع معظم الشركات الاستشارية في Power BI بخبرة في Power BI ولكن معرفة محدودة بنموذج بيانات Odoo. إنهم يقضون أسابيع في إجراء هندسة عكسية لعلاقات الجداول، وفهم الاصطلاحات الخاصة بـ Odoo (مثل بنية المنتج_المنتج / قالب_المنتج المزدوج)، ومعرفة الحقول ذات المعنى. قامت ECOSIRE ببناء ونشر أكثر من 43 وحدة من وحدات Odoo وتحتفظ بخبرة عميقة في كلا النظامين الأساسيين. نحن نقدم نماذج بيانات معدة مسبقًا، ومكتبة مؤشرات أداء رئيسية قياسية تحتوي على أكثر من 50 مقياسًا، وتحسينات خاصة بـ Odoo مثل التحديث المتزايد على أعمدة write_date. تعمل هذه الخبرة المزدوجة على تقليل وقت التنفيذ بنسبة 40-60 بالمائة مقارنة بالفرق التي تتعلم نموذج بيانات Odoo من الصفر.