كيفية توصيل Power BI بنظام تخطيط موارد المؤسسات (ERP) الخاص بك
يحتوي نظام تخطيط موارد المؤسسات (ERP) الخاص بك على البيانات التشغيلية الأكثر شمولاً في مؤسستك. يتم تسجيل الطلبات والفواتير وحركات المخزون وإيصالات الشراء وأوامر عمل التصنيع والجداول الزمنية للموظفين وتفاعلات العملاء --- كل حدث معاملة يدفع عملك. المشكلة هي أن أنظمة تخطيط موارد المؤسسات (ERP) مصممة لتسجيل المعاملات، وليس لتحليلها. تعد التقارير المضمنة في معظم أنظمة تخطيط موارد المؤسسات (ERP) كافية للاستعلامات التشغيلية الأساسية ولكنها تنهار عندما تحتاج إلى تحليل متعدد الوظائف، أو اكتشاف الاتجاه، أو التنبؤ، أو لوحات المعلومات على المستوى التنفيذي التي تجمع البيانات من مجالات متعددة.
يقوم Power BI بسد هذه الفجوة. فهو يتصل بقاعدة البيانات الأساسية لـ ERP أو واجهات برمجة التطبيقات (APIs)، ويحول بيانات المعاملات إلى مخطط نجمي تحليلي، ويقدم لوحات معلومات تفاعلية تكشف عن الأنماط التي لا يمكن لتقارير ERP الأصلية إظهارها. لكن الاتصال لا يقتصر على مجرد "توصيل Power BI بقاعدة البيانات". يحتوي كل نظام أساسي لتخطيط موارد المؤسسات (ERP) على بنية بيانات خاصة به وطريقة وصول ومراوغات تؤثر على كيفية إنشاء الاتصال ونمذجة البيانات والحفاظ على التكامل بمرور الوقت.
يغطي هذا الدليل الخطوات العملية لتوصيل Power BI بست منصات رئيسية لتخطيط موارد المؤسسات (ERP): Odoo (تخصصنا الأساسي)، وSAP، وMicrosoft Dynamics 365، وOracle، وNetSuite، وQuickBooks. نحن نركز على قرارات التصميم وطرق الاتصال ونمذجة البيانات والتحديث المتزايد وأنماط التحويل التي تحول بيانات ERP الأولية إلى ذهب تحليلي.
الوجبات الرئيسية
- يتبع كل تكامل لـ ERP نفس النمط ثلاثي المراحل: الاتصال (الوصول إلى البيانات)، التحويل (إعادة التشكيل للتحليلات)، النموذج (بناء علاقات المخطط النجمي)
- توفر قاعدة بيانات PostgreSQL الخاصة بـ Odoo اتصال Power BI الأكثر مباشرة ومرونة --- تعد طرق عرض SQL وطرق العرض المتحققة هي الطريقة الموصى بها لعمليات نشر الإنتاج
- يتطلب SAP موصل SAP HANA أو SAP BW؛ نادرًا ما يُسمح بالوصول المباشر إلى قاعدة البيانات في بيئات SAP
- يتكامل Dynamics 365 محليًا من خلال Dataverse، مما يجعله أبسط نظام تخطيط موارد المؤسسات (ERP) للاتصال بالمؤسسات الموجودة بالفعل في نظام Microsoft البيئي
- يعد التحديث المتزايد أمرًا ضروريًا لمجموعات بيانات ERP الكبيرة --- التحديث الكامل لجداول المعاملات المكونة من عدة ملايين من الصفوف أمر غير مستدام
- قم دائمًا بإنشاء طبقة تحليلية (طرق العرض أو الجداول المرحلية أو مستودع البيانات) بين ERP وPower BI بدلاً من الاستعلام عن الجداول التشغيلية مباشرةً
- يجب أن يتعامل تحويل البيانات في Power Query مع الأنماط الخاصة بـ ERP: تسوية العملات المتعددة، ومحاذاة التقويم المالي، وترجمة رمز الحالة
البنية العالمية لتكامل تخطيط موارد المؤسسات (ERP).
نهج ثلاثي الطبقات
بغض النظر عن نظام تخطيط موارد المؤسسات (ERP) الذي تستخدمه، تتبع بنية التكامل ثلاث طبقات:
الطبقة الأولى: الاستخراج. اسحب البيانات من نظام تخطيط موارد المؤسسات (ERP) إلى Power BI. يحدث هذا من خلال اتصالات قاعدة البيانات (PostgreSQL، SQL Server، Oracle)، أو استدعاءات واجهة برمجة التطبيقات (REST، OData، SOAP)، أو التخزين الوسيط (مستودع البيانات، بحيرة البيانات، صادرات CSV). تعتمد طريقة الاستخراج على ما يدعمه نظام تخطيط موارد المؤسسات (ERP) وما تسمح به سياسات الأمان الخاصة بمؤسستك.
الطبقة 2: التحويل. بيانات ERP الأولية عبارة عن معاملات وموحدة --- مُحسّنة للإدراج والتحديثات، وليس للتحليل. قم بتحويلها إلى أشكال تحليلية: تجميع خطوط المعاملات في جداول ملخصة، ورموز الحالة المحورية إلى تسميات قابلة للقراءة، وتحويل المبالغ متعددة العملات إلى عملة أساسية، ومواءمة التواريخ مع التقويم المالي الخاص بك. يحدث هذا في Power Query أو طرق عرض SQL أو أداة ETL مخصصة.
الطبقة 3: النمذجة. قم ببناء البيانات المحولة في مخطط نجمي باستخدام جداول الحقائق (المبيعات والمشتريات وحركات المخزون) وجداول الأبعاد (العملاء والمنتجات والتواريخ والمستودعات). قم بتكوين العلاقات، وكتابة مقاييس DAX، وإنشاء الطبقة الدلالية التي يستخدمها مؤلفو التقارير.
قاعدة البيانات المباشرة مقابل واجهة برمجة التطبيقات مقابل مستودع البيانات
الاتصال المباشر بقاعدة البيانات هو الأسرع في الإعداد ويوفر أكبر قدر من المرونة. تقوم بكتابة استعلامات SQL في قاعدة بيانات ERP وتسحب البيانات التي تحتاجها بالضبط. ومع ذلك، فهو يتطلب الوصول إلى قاعدة البيانات (وهو ما لا يشجعه أو يقيده بعض موردي تخطيط موارد المؤسسات)، ويمكن أن يؤثر على أداء تخطيط موارد المؤسسات (ERP) إذا تم تحسين الاستعلامات بشكل سيئ، ويربط تحليلاتك مباشرة بمخطط تخطيط موارد المؤسسات (الذي يتغير مع الترقيات).
اتصال API يحترم أنماط الوصول المقصودة لمورد ERP ولا يخاطر بالتأثير على أداء قاعدة البيانات. ومع ذلك، تكون واجهات برمجة التطبيقات عادةً أبطأ من استعلامات قاعدة البيانات المباشرة، وقد يكون لها حدود للمعدل، وغالبًا ما تُرجع البيانات بتنسيقات هرمية (JSON/XML) التي تتطلب المزيد من أعمال التحويل في Power Query.
مستودع البيانات يوفر أفضل عملية فصل. يستخرج خط أنابيب ETL البيانات من ERP ليلاً، ويحولها إلى مخطط تحليلي، ويحملها إلى قاعدة بيانات مخصصة (Azure SQL، وSnowflake، وPostgreSQL) التي يتصل بها Power BI. هذه هي البنية الأكثر قابلية للصيانة على المدى الطويل ولكنها تتطلب الاستثمار الأكثر مقدمًا لبناء خط أنابيب ETL.
بالنسبة لمعظم المؤسسات، نوصي بالبدء باتصالات قاعدة البيانات المباشرة (أو واجهات برمجة التطبيقات حيث لا يكون الوصول المباشر ممكنًا) والانتقال إلى مستودع البيانات مع نضوج بيئة التحليلات وزيادة عدد مصادر البيانات.
توصيل Power BI بـ Odoo
لماذا يعتبر Odoo مثاليًا لـ Power BI
يتميز Odoo عن معظم منصات تخطيط موارد المؤسسات (ERP) في إمكانية الوصول إليه من أجل تكامل التحليلات. إنه يعمل على PostgreSQL، وهي واحدة من أكثر قواعد البيانات الصديقة لـ Power BI. مخططه موثق جيدًا، وتسمية جدوله متسقة (تنسيق module_model)، وطبيعته مفتوحة المصدر تعني عدم وجود عوائق ترخيص أمام الوصول إلى قاعدة البيانات. إذا كنت تستخدم Odoo، فلديك بالفعل كل ما تحتاجه لإنشاء لوحات معلومات Power BI ذات مستوى عالمي.
في ECOSIRE، يعد تكامل Odoo-to-Power BI أحد الكفاءات الأساسية لدينا. لقد قمنا ببناء حلول تحليلية عبر المشهد الكامل لوحدة Odoo --- المبيعات، والمشتريات، والمخزون، والتصنيع، والمحاسبة، والموارد البشرية، ومكتب المساعدة، وإدارة المشاريع. تم اختبار الأنماط التي نصفها هنا عبر التطبيقات التي تخدم المؤسسات التي لديها الملايين من معاملات تخطيط موارد المؤسسات (ERP).
اتصال PostgreSQL المباشر
الخطوة 1: تكوين PostgreSQL للوصول عن بُعد. إذا كان مثيل Odoo وبوابة Power BI موجودين على خوادم مختلفة، فيجب أن يسمح PostgreSQL بالاتصالات عن بُعد. في postgresql.conf، قم بتعيين listen_addresses = '*'. في pg_hba.conf، أضف سطرًا يسمح بعنوان IP الخاص بخادم البوابة من خلال مصادقة MD5. أعد تشغيل PostgreSQL لتطبيق التغييرات.
الخطوة 2: إنشاء مستخدم قاعدة بيانات للقراءة فقط. لا تقم أبدًا بتوصيل Power BI باستخدام مستخدم قاعدة بيانات Odoo الرئيسية. إنشاء مستخدم مخصص للقراءة فقط:
CREATE USER powerbi_reader WITH PASSWORD 'secure_password_here';
GRANT CONNECT ON DATABASE odoo_production TO powerbi_reader;
GRANT USAGE ON SCHEMA public TO powerbi_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO powerbi_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO powerbi_reader;
يمكن لهذا المستخدم قراءة كافة الجداول ولكن لا يمكنه تعديل البيانات أو إدراج السجلات أو تغيير المخطط. يضمن السطر ALTER DEFAULT PRIVILEGES أن الجداول الجديدة التي تم إنشاؤها بواسطة ترقيات Odoo قابلة للقراءة تلقائيًا.
الخطوة 3: الاتصال من Power BI Desktop. افتح Power BI Desktop → الحصول على البيانات → قاعدة بيانات PostgreSQL. أدخل عنوان الخادم والمنفذ (الافتراضي 5432) واسم قاعدة البيانات. استخدم بيانات الاعتماد powerbi_reader. حدد وضع "الاستيراد" لمعظم الجداول (البيانات المحملة في الذاكرة) أو "DirectQuery" للجداول الكبيرة جدًا حيث تريد الاستعلامات المباشرة.
الخطوة 4: كتابة استعلامات SQL مخصصة. بدلاً من استيراد جداول Odoo الأولية، استخدم استعلامات SQL المخصصة في الخيارات المتقدمة لضم البيانات وتصفيتها على مستوى قاعدة البيانات. يعد هذا أكثر كفاءة من استيراد الجداول الأولية والانضمام إليها في Power Query.
جداول Odoo الأساسية للتحليلات
يتم تعيين مخطط قاعدة بيانات Odoo مباشرة إلى بنية الوحدة الخاصة به. فيما يلي الجداول الرئيسية للمجالات التحليلية الأكثر شيوعًا:
تحليلات المبيعات:
| جدول اودو | يحتوي على | الأعمدة الرئيسية |
|---|---|---|
sale_order | أوامر البيع | المعرف، Partner_id، date_order، المبلغ_الإجمالي، الحالة، معرف_المستخدم، معرف_الشركة |
sale_order_line | طلب بنود | معرف الطلب، معرف المنتج، المنتج_uom_qty، سعر_الوحدة، السعر_الإجمالي، الخصم |
res_partner | العملاء/البائعين | المعرف، الاسم، البريد الإلكتروني، معرف_البلد، معرف_الصناعة، نوع_الشركة |
product_template | سيد المنتج | المعرف، الاسم، list_price، Standard_price، categ_id، اكتب |
product_product | متغيرات المنتج | المعرف، Product_tmpl_id، default_code |
تحليلات المخزون:
| جدول اودو | يحتوي على | الأعمدة الرئيسية |
|---|---|---|
stock_move | حركات المخزون | Product_id، location_id، location_dest_id، Product_uom_qty، التاريخ، الحالة |
stock_quant | مستويات المخزون الحالية | معرف المنتج، معرف الموقع، الكمية، الكمية المحجوزة |
stock_warehouse | مستودعات | المعرف، الاسم، الرمز، معرف الشريك |
stock_location | المواقع | المعرف، الاسم، الاستخدام، location_id (الأصل) |
التحليلات المحاسبية:
| جدول اودو | يحتوي على | الأعمدة الرئيسية |
|---|---|---|
account_move | إدخالات دفتر اليومية/الفواتير | المعرف، Partner_id، التاريخ، المبلغ_الإجمالي، الحالة، نوع_النقل، معرف_المجلة |
account_move_line | خطوط الدخول | move_id، account_id، الخصم، الائتمان، الرصيد، التاريخ، Partner_id |
account_account | شجرة الحسابات | المعرف، الكود، الاسم، نوع_الحساب |
account_journal | المجلات | المعرف، الاسم، النوع، الكود |
تحليلات التصنيع:
| جدول اودو | يحتوي على | الأعمدة الرئيسية |
|---|---|---|
mrp_production | طلبيات التصنيع | معرف المنتج، منتج_الكمية، تاريخ_البدء، تاريخ_الانتهاء، الحالة، bom_id |
mrp_workcenter | مراكز العمل | المعرف، الاسم، القدرة، كفاءة الوقت |
mrp_bom | فاتورة المواد | Product_tmpl_id، Product_qty، اكتب |
بناء طرق عرض تحليلية في PostgreSQL
بالنسبة لعمليات نشر الإنتاج، نوصي بشدة بإنشاء طرق عرض SQL التي تربط جداول Odoo وتجميعها مسبقًا في أشكال تحليلية. يؤدي هذا إلى نقل التعقيد من Power Query إلى SQL، حيث يكون من الأسهل صيانته وتقديم أداء أفضل.
مثال لعرض ملخص المبيعات:
CREATE VIEW v_sales_analysis AS
SELECT
so.id AS order_id,
so.name AS order_reference,
so.date_order::date AS order_date,
so.state AS order_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.price_subtotal AS line_total,
sol.discount,
ru.login AS salesperson,
so.company_id
FROM sale_order so
JOIN sale_order_line sol ON sol.order_id = so.id
JOIN res_partner rp ON rp.id = so.partner_id
LEFT JOIN res_country rc ON rc.id = rp.country_id
JOIN product_product pp ON pp.id = sol.product_id
JOIN product_template pt ON pt.id = pp.product_tmpl_id
LEFT JOIN product_category pc ON pc.id = pt.categ_id
LEFT JOIN res_users ru ON ru.id = so.user_id
WHERE so.state IN ('sale', 'done');
يقوم Power BI باستيراد طريقة العرض هذه كجدول واحد، مرتبط مسبقًا ومصفى. لا حاجة إلى تحويلات Power Query المعقدة. عندما يتغير مخطط Odoo أثناء عمليات الترقية، يمكنك تحديث طريقة عرض SQL مرة واحدة بدلاً من تعديل خطوات Power Query عبر مجموعات بيانات متعددة.
العروض المادية تذهب أبعد من ذلك من خلال الحوسبة المسبقة للنتائج وتخزينها، مما يجعل تحديث Power BI أسرع بشكل كبير:
CREATE MATERIALIZED VIEW mv_sales_daily AS
SELECT
so.date_order::date AS order_date,
rp.country_id,
pt.categ_id AS product_category_id,
so.user_id AS salesperson_id,
COUNT(DISTINCT so.id) AS order_count,
SUM(sol.product_uom_qty) AS total_quantity,
SUM(sol.price_subtotal) AS total_revenue
FROM sale_order so
JOIN sale_order_line sol ON sol.order_id = so.id
JOIN res_partner rp ON rp.id = so.partner_id
JOIN product_product pp ON pp.id = sol.product_id
JOIN product_template pt ON pt.id = pp.product_tmpl_id
WHERE so.state IN ('sale', 'done')
GROUP BY so.date_order::date, rp.country_id, pt.categ_id, so.user_id;
-- Refresh nightly via cron
-- REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales_daily;
يلخص هذا العرض المجمع مسبقًا الملايين من سطور الطلب في آلاف صفوف الملخص اليومية. يستورد Power BI الملخص للوحات المعلومات ويستخدم التعمق في عرض التفاصيل عندما يحتاج المستخدمون إلى بيانات على مستوى السطر.
التعامل مع الأنماط الخاصة بنظام Odoo
شركات متعددة. يدعم Odoo شركات متعددة في قاعدة بيانات واحدة. قم دائمًا بتضمين company_id في استعلاماتك وقم بتكوين الأمان على مستوى صف Power BI لتقييد كل مستخدم ببيانات شركته.
حقول الحالة. يستخدم Odoo رموز الحالة النصية (draft، sent، sale، done، cancel). قم بتعيين هذه التصنيفات إلى تسميات سهلة الاستخدام في Power Query أو في طريقة عرض SQL الخاصة بك:
CASE so.state
WHEN 'draft' THEN 'Quotation'
WHEN 'sent' THEN 'Sent'
WHEN 'sale' THEN 'Sales Order'
WHEN 'done' THEN 'Locked'
WHEN 'cancel' THEN 'Cancelled'
END AS order_status
متعدد العملات. يقوم Odoo بتخزين المبالغ بعملة المعاملة وعملة الشركة. بالنسبة إلى لوحات معلومات Power BI، حدد العملة التي تريد إعداد التقارير بها واستخدم الأعمدة المناسبة. إذا كنت بحاجة إلى تحويل سعر الصرف في الوقت الفعلي، انضم إلى الجدول res_currency_rate.
علاقات متعدد بمتعدد. يستخدم Odoo جداول الوصلات لعلاقات متعدد بمتعدد (علامات المنتج، وفئات الشركاء). تظهر هذه كجداول تسمى {model1}_{model2}_rel. تعامل معها باستخدام الجداول الجسرية في نموذج بيانات Power BI الخاص بك.
بالنسبة للمؤسسات التي تبحث عن تحليلات Odoo الجاهزة، تقدم خدمات تكامل Power BI ERP من ECOSIRE قوالب لوحة معلومات Odoo مسبقة الصنع تغطي المبيعات والمخزون والمحاسبة والتصنيع والموارد البشرية --- مخصصة بالكامل لتكوين Odoo ومتطلبات العمل. يتمتع فريقنا بخبرة عميقة في كل من Odoo وPower BI، مما يزيل الفجوة التي توجد عادةً عندما يحاول مستشارو ذكاء الأعمال العمل مع نظام تخطيط موارد المؤسسات (ERP) الذي لا يفهمونه.
توصيل Power BI بـ SAP
خيارات اتصال SAP
تعد بيئات SAP أكثر تقييدًا فيما يتعلق بالوصول المباشر إلى قاعدة البيانات من أنظمة تخطيط موارد المؤسسات (ERP) مفتوحة المصدر. يستخدم معظم عملاء SAP أحد مسارات الاتصال التالية:
موصل SAP HANA. بالنسبة لعملاء SAP S/4HANA، يوفر موصل SAP HANA الأصلي الخاص بـ Power BI وصولاً مباشرًا إلى طرق عرض HANA (طرق العرض التحليلية والسمة والحسابية). يعد هذا هو الخيار الأعلى أداءً ويدعم وضعي الاستيراد والاستعلام المباشر. يتطلب وجود مستخدم SAP HANA يتمتع بامتيازات SELECT في طرق العرض ذات الصلة.
موصل SAP BW. بالنسبة للمؤسسات التي تستخدم SAP Business Warehouse، يتصل Power BI باستعلامات BW (استعلامات BEx أو موفري BW/4HANA المركبين). يعمل هذا على تعزيز الهياكل التحليلية المضمنة بالفعل في BW، مما يتجنب الحاجة إلى نمذجة البيانات من البداية في Power BI.
خدمات SAP OData. تعرض SAP بيانات الأعمال من خلال واجهات برمجة تطبيقات OData (خاصة بوابة SAP وSAP API Business Hub). يستهلك موصل OData الخاص بـ Power BI هذه الخدمات. يحترم هذا الأسلوب نموذج ترخيص SAP ولكنه أبطأ من الوصول المباشر إلى قاعدة البيانات وقد يكون له حدود للصفحات لمجموعات البيانات الكبيرة.
الاستخراج إلى وحدة تخزين وسيطة. بالنسبة للسيناريوهات المعقدة، قم باستخراج بيانات SAP باستخدام أدوات SAP الأصلية (Open Hub، أو النسخ المتماثل لـ SLT، أو طرق عرض CDS) إلى Azure Data Lake، أو Snowflake، أو Azure SQL. يتصل Power BI بوحدة التخزين الوسيطة. هذا هو النهج الأكثر مرونة وقابلية للتطوير لعمليات النشر المؤسسية.
اعتبارات نمذجة بيانات SAP
تعتبر هياكل بيانات SAP معقدة وموحدة بشكل كبير. تستخدم الجداول مثل VBAK (رأس أمر المبيعات)، وVBAP (عناصر أمر المبيعات)، وKNA1 (رئيس العميل)، وMARA (رئيس المواد) أسماء أعمدة قصيرة ومبهمة وقيم مخزنة مشفرة تتطلب ربط الجداول للترجمة.
عند إنشاء نماذج Power BI من بيانات SAP:
ترجمة الرموز مبكرًا. يقوم SAP بتخزين البلد كرمز مكون من حرفين، والعملة كرمز مكون من 3 أحرف، ونوع المادة كرمز مثل "FERT" أو "HALB". انضم إلى الجداول النصية (T005T للبلدان، وTCURT للعملات، وT134T لأنواع المواد) في استعلام الاستخراج الخاص بك، وليس في Power Query.
التعامل مع تنسيق تاريخ SAP. يقوم SAP بتخزين التواريخ كسلاسل مكونة من 8 أرقام (YYYYMMDD) مع "00000000" للتواريخ الخالية. قم بتحويلها إلى أنواع التاريخ المناسبة في طبقة التحويل الخاصة بك والتعامل مع نمط التاريخ الفارغ.
احترم كائنات التفويض. يتحكم نموذج التفويض الخاص بـ SAP في البيانات التي يمكن لكل مستخدم الوصول إليها على مستوى تفصيلي. عند استخراج البيانات لـ Power BI، تأكد من أن عملية الاستخراج تحترم هذه الحدود أو قم بتنفيذ أمان مكافئ على مستوى الصف في Power BI.
توصيل Power BI بـ Dynamics 365
Dataverse: المسار الأصلي
يقوم Dynamics 365 بتخزين البيانات في Microsoft Dataverse، ويحتوي Power BI على تكامل Dataverse من الدرجة الأولى. وهذا يجعل Dynamics 365 أسهل ERP رئيسي للاتصال بـ Power BI، خاصة للمؤسسات التي استثمرت بالفعل في النظام البيئي لـ Microsoft.
موصل Dataverse. Power BI Desktop → الحصول على البيانات → Dataverse. قم بالمصادقة باستخدام بيانات اعتماد Dynamics 365 الخاصة بك. تصفح وحدد الجداول (الكيانات) التي تحتاجها. يحترم الموصل أدوار أمان Dataverse، بحيث يرى المستخدمون فقط البيانات المصرح لهم بالوصول إليها.
Azure Synapse Link for Dataverse. بالنسبة لمجموعات بيانات Dynamics 365 الكبيرة، يقوم Azure Synapse Link باستمرار بنسخ بيانات Dataverse إلى Azure Synapse Analytics أو Azure Data Lake. يتصل Power BI بـ Synapse/Data Lake بدلاً من الاستعلام عن Dataverse مباشرةً. يؤدي هذا إلى التخلص من تأثير الأداء على Dynamics 365 ويوفر نظامًا أساسيًا أفضل للتحويلات المعقدة.
نقطة نهاية TDS. يكشف Dataverse عن نقطة نهاية تدفق البيانات الجدولية (TDS) التي يمكن لـ Power BI الاتصال بها باستخدام موصل SQL Server. يعد هذا مفيدًا للسيناريوهات التي تريد فيها كتابة استعلامات SQL مخصصة مقابل بيانات Dataverse.
جداول Dynamics 365 للتحليلات
جداول Dataverse الرئيسية للسيناريوهات التحليلية الشائعة:
المبيعات: salesorder, salesorderdetail, opportunity, account, contact, product
الخدمة: incident (الحالات)، knowledgearticle، entitlement، sla
التمويل: invoice, invoicedetail, payment, generaljournal
الخدمة الميدانية: workorder، bookableresource، agreement
تعتبر بنية جدول Dynamics 365 تحليلية نسبيًا بالفعل --- تحتوي الكيانات مثل salesorder على حقول غير طبيعية لاسم الحساب والمالك وتسمية الحالة. ومع ذلك، للحصول على الأداء الأمثل لـ Power BI، لا يزال عليك إنشاء مخطط نجمي بدلاً من استيراد جداول Dataverse كما هي.
توصيل Power BI بـ Oracle وNetSuite
مجموعة أوراكل للأعمال الإلكترونية / فيوجن
بالنسبة إلى Oracle EBS، استخدم موصل Oracle Database الخاص بـ Power BI مع عميل Oracle المثبت على جهاز البوابة. توفر تطبيقات Oracle Fusion Cloud واجهات برمجة تطبيقات REST التي يمكن أن يستهلكها Power BI من خلال موصل الويب أو موصل OData.
يمكن تكوين تقارير BI Publisher من Oracle لإخراج البيانات بتنسيقات يمكن أن يستهلكها Power BI، مما يوفر مسار استخراج مدعومًا من البائع يحترم منطق عمل Oracle وأمانه.
نت سويت
يوفر NetSuite مسارات اتصال متعددة لـ Power BI:
SuiteAnalytics Connect (ODBC). يسمح برنامج تشغيل ODBC الخاص بـ NetSuite لـ Power BI بالاتصال باستخدام موصل ODBC. يوفر هذا وصول SQL إلى مجموعة بيانات NetSuite باستخدام مخطط علائقي أكثر ملاءمة للتحليلات من مخطط NetSuite الأصلي.
SuiteQL API. تدعم واجهة REST API الخاصة بـ NetSuite SuiteQL، وهي لغة استعلام تشبه SQL. يمكن لـ Power BI استدعاء واجهة برمجة التطبيقات هذه من خلال وظائف Power Query المخصصة. يعد هذا مفيدًا لعمليات الاستخراج المستهدفة ولكنه أقل كفاءة من ODBC لمجموعات البيانات الكبيرة.
موصلات الجهات الخارجية. توفر أدوات مثل CData موصلات Power BI محسنة لـ NetSuite والتي تتعامل مع ترقيم الصفحات والمصادقة وتعيين المخطط تلقائيًا.
توصيل Power BI بـ QuickBooks
الكتب السريعة على الإنترنت
يعرض QuickBooks Online البيانات من خلال REST API التي يمكن أن يستهلكها Power BI. يتطلب الاتصال تسجيل تطبيق OAuth2 في Intuit Developer Portal وموصل Power Query مخصص أو موصل الويب مع إدارة رمز OAuth المميزة يدويًا.
بالنسبة لمعظم مستخدمي QuickBooks، فإن أبسط مسار هو موصل جهة خارجية (CData أو Skyvia أو ما شابه) الذي يتعامل مع المصادقة وترقيم الصفحات وتعيين نوع البيانات. تظهر هذه الموصلات كمصادر بيانات أصلية في Power BI وتلخص تعقيد واجهة برمجة التطبيقات (API).
بيانات QuickBooks الرئيسية لبرنامج Power BI
بيانات قائمة الدخل: الفواتير، الدفعات، مذكرات الائتمان، إيصالات المبيعات بيانات الميزانية العمومية: أرصدة الحسابات، وقيود دفتر اليومية البيانات التشغيلية: العملاء والبائعين والمنتجات/الخدمات والتقديرات
عادةً ما تكون أحجام بيانات QuickBooks صغيرة بما يكفي بحيث يكون التحديث الكامل سريعًا (أقل من 5 دقائق). نادرًا ما يكون التحديث المتزايد ضروريًا لعمليات تكامل QuickBooks.
التحديث المتزايد لبيانات تخطيط موارد المؤسسات (ERP).
لماذا يعد التحديث المتزايد أمرًا ضروريًا
قواعد بيانات تخطيط موارد المؤسسات (ERP) تنمو بشكل مستمر. تقوم شركة متوسطة الحجم بإنشاء آلاف المعاملات يوميًا. وبعد بضع سنوات، أصبح جدول أوامر المبيعات يحتوي على ملايين الصفوف. يؤدي تحديث الجدول بأكمله كل صباح إلى إهدار موارد البوابة وسعة قاعدة البيانات والوقت.
يخبر التحديث التزايدي Power BI بتحديث البيانات الحديثة فقط (على سبيل المثال، آخر 30 يومًا) مع الاحتفاظ بالبيانات التاريخية المخزنة مؤقتًا من عمليات التحديث السابقة. التحديث الكامل الذي يستغرق 45 دقيقة يصبح تحديثًا تزايديًا مدته 3 دقائق.
خطوات التكوين
الخطوة 1: إنشاء معلمات Power Query. قم بإنشاء معلمتين بالاسم بالضبط RangeStart وRangeEnd، وكلاهما من النوع DateTime. قم بتعيين القيم الافتراضية (يتم استخدامها فقط في Power BI Desktop، وتتجاوزها الخدمة).
الخطوة 2: تصفية الاستعلام المصدر. قم بتطبيق عامل تصفية على عمود التاريخ في جدول البيانات الفعلية باستخدام المعلمات:
#"Filtered Rows" = Table.SelectRows(Source, each [order_date] >= RangeStart and [order_date] < RangeEnd)
يجب أن يتم طي عامل التصفية هذا إلى قاعدة البيانات المصدر حتى يعمل التحديث المتزايد. إذا كنت متصلاً بـ PostgreSQL (Odoo)، فسيقوم المرشح بإنشاء عبارة WHERE التي ينفذها PostgreSQL، ويعيد الصفوف المطابقة فقط.
الخطوة 3: تحديد سياسة التحديث التزايدي. في Power BI Desktop، انقر بزر الماوس الأيمن فوق الجدول → التحديث التزايدي. تكوين:
- بيانات الأرشفة تبدأ: إلى أي مدى يجب الاحتفاظ بالبيانات التاريخية (على سبيل المثال، 3 سنوات).
- بدء تحديث البيانات بشكل متزايد: كيفية تحديث البيانات الحديثة (على سبيل المثال، 30 يومًا).
- تحديث الفترات الكاملة فقط: حدد هذا الخيار لتجنب مشكلات بيانات اليوم الجزئي.
- كشف تغييرات البيانات: قم بالتمكين إذا كان الجدول المصدر الخاص بك يحتوي على عمود موثوق به "آخر تعديل" (يقلل وقت التحديث بشكل أكبر عن طريق تخطي الأقسام التي لم تتغير).
الخطوة 4: النشر والتكوين. بعد النشر إلى خدمة Power BI، قم بتكوين التحديث المجدول. تقوم الخدمة بإنشاء أقسام تعتمد على الوقت وتقوم بتحديث الأقسام التي تقع ضمن النافذة المتزايدة فقط.
أنماط التحديث التزايدي الخاصة بـ ERP
Odoo: استخدم write_date كعمود اكتشاف التغيير. يقوم Odoo بتحديث هذا الطابع الزمني عند كل تعديل للسجل، مما يجعله موثوقًا لاكتشاف الصفوف التي تم تغييرها.
SAP: استخدم الحقل AEDAT (تاريخ التغيير) المتوفر في معظم جداول معاملات SAP. بالنسبة إلى HANA، يمكن أن توفر طرق عرض HANA المتحققة إمكانية تتبع التغيير.
Dynamics 365: تحتوي كيانات Dataverse على طوابع زمنية modifiedon تعمل بشكل جيد لاكتشاف التغيير. يوفر Azure Synapse Link إمكانية التقاط بيانات التغيير المضمنة.
Oracle: استخدم صفوف Oracle أو عمود آخر_تاريخ_التحديث المخصص. يمكن أن يوفر Oracle GoldenGate التقاط بيانات التغيير لسيناريوهات الوقت الفعلي.
أفضل ممارسات تحويل البيانات
التطبيع متعدد العملات
تقوم معظم أنظمة تخطيط موارد المؤسسات (ERP) بتخزين مبالغ المعاملات بعملة المعاملة. بالنسبة للوحات المعلومات التحليلية، تحتاج عادةً إلى مبالغ بعملة تقارير واحدة.
نهجان:
التحويل من جانب المصدر. إذا كان نظام تخطيط موارد المؤسسات (ERP) الخاص بك يخزن مبالغ المعاملات والعملة الأساسية (يخزن Odoo amount_total بعملة المعاملة وamount_total_company_currency بالعملة الأساسية)، فاستخدم عمود العملة الأساسية مباشرةً. يؤدي ذلك إلى تعزيز أسعار الصرف الخاصة بنظام تخطيط موارد المؤسسات (ERP) وتجنب التناقضات بين التقارير التشغيلية والتحليلية.
تحويل Power Query. إذا كنت بحاجة إلى إعداد التقارير بعملة مختلفة عن العملة الأساسية لـ ERP، فقم بإنشاء جدول سعر الصرف في نموذج Power BI الخاص بك واستخدم DAX لتحويل المبالغ في وقت التقرير. وهذا النهج أكثر مرونة ولكنه يتطلب الحفاظ على بيانات سعر الصرف.
ترجمة رمز الحالة
تستخدم أنظمة تخطيط موارد المؤسسات (ERP) رموزًا داخلية للحالات والأنواع والفئات. قم بترجمة هذه إلى تسميات سهلة الاستخدام في طبقة التحويل الخاصة بك، وليس في DAX. تعتبر الصورة المرئية التي يتم تجميعها حسب "مسودة، مرسلة، مؤكدة، تم، ملغاة" واضحة بذاتها. الصورة التي يتم تجميعها حسب "1، 2، 3، 4، 5" ليست كذلك.
بالنسبة لـ Odoo، تكون الترجمة واضحة نظرًا لأن Odoo يستخدم حالات نصية قابلة للقراءة. بالنسبة إلى SAP، قم بتعيين الرموز المشفرة (AUFNR، MATNR، BUKRS) لأسماء ملائمة للأعمال. بالنسبة لـ Dynamics 365، استخدم تسميات مجموعة الخيارات بدلاً من قيم الأعداد الصحيحة الأساسية.
محاذاة التقويم المالي
إذا كانت السنة المالية الخاصة بك تختلف عن السنة التقويمية، فقم بإنشاء بُعد تقويم مالي يربط كل تاريخ بالسنة المالية والربع المالي والفترة المالية. يعد هذا أمرًا ضروريًا للوحات المعلومات المالية حيث يعني "Q1" الربع الأول المالي (الذي قد يكون من يوليو إلى سبتمبر)، وليس الربع الأول من التقويم (من يناير إلى مارس).
قم بتضمين كل من سمات التقويم والمالية في بُعد التاريخ الخاص بك حتى يتمكن المستخدمون من التبديل بين المنظورات دون تغيير نموذج البيانات.
للحصول على مساعدة شاملة في توصيل Power BI ببيئة تخطيط موارد المؤسسات (ERP) الخاصة بك، اتصل بفريق تحليلات ECOSIRE لمناقشة متطلباتك. نحن متخصصون في تحليلات Odoo ونوفر لوحات معلومات قالب Power BI مسبقة الصنع لكل وحدة Odoo رئيسية.
الأسئلة الشائعة
هل يجب علي توصيل Power BI مباشرة بقاعدة بيانات ERP الخاصة بي أو استخدام مستودع بيانات؟
بالنسبة لعمليات النشر الأولية التي تحتوي على عدد صغير من التقارير وأحجام بيانات معتدلة (أقل من 10 ملايين صف)، تكون اتصالات قاعدة البيانات المباشرة أسرع في الإعداد وملائمة تمامًا. مع نمو بيئة التحليلات الخاصة بك لتتجاوز 10-15 تقريرًا أو البدء في دمج البيانات من أنظمة مصادر متعددة، يصبح مستودع البيانات جديرًا بالاهتمام. يوفر المستودع مخططًا ثابتًا لـ Power BI (معزولًا عن تغييرات مخطط ERP)، وأداء استعلام أفضل (من خلال التجميع المسبق والفهرسة)، ومكانًا واحدًا لتنفيذ منطق الأعمال (تحويل العملة، والتخطيط المالي، وترجمة الحالة). تبدأ معظم المؤسسات باتصالات مباشرة وتنتقل إلى المستودع في غضون 12 إلى 18 شهرًا.
هل تؤدي استعلامات Power BI إلى إبطاء نظام تخطيط موارد المؤسسات (ERP) الخاص بي؟
يمكنهم ذلك إذا لم تتم إدارتهم بشكل صحيح. تقوم عمليات التحديث المجدولة لـ Power BI بتنفيذ استعلامات SQL مقابل قاعدة بيانات ERP الخاصة بك، والتي تستهلك موارد وحدة المعالجة المركزية والذاكرة والإدخال/الإخراج. يمكنك التخفيف من ذلك عن طريق جدولة عمليات التحديث خارج ساعات الذروة (في الصباح الباكر وفي وقت متأخر من المساء)، وإنشاء نسخ متماثلة للقراءة للاستعلامات التحليلية (النسخ المتماثل لتدفق PostgreSQL لـ Odoo، وAlways On لـ SQL Server)، باستخدام طرق العرض المادية التي تحسب النتائج مسبقًا، وتنفيذ التحديث التزايدي لتقليل البيانات التي تم فحصها. بالنسبة لأنظمة تخطيط موارد المؤسسات (ERP) للمهام الحرجة، تعد النسخة المتماثلة المقروءة هي الطريقة الأكثر أمانًا --- يستعلم Power BI عن النسخة المتماثلة بينما تظل قاعدة بيانات الإنتاج غير متأثرة.
كيف أتعامل مع ترقيات وحدة Odoo التي تغير مخطط قاعدة البيانات؟
تقوم ترقيات وحدة Odoo أحيانًا بإضافة أعمدة وجداول قاعدة البيانات أو إعادة تسميتها أو إزالتها. إذا كانت استعلامات Power BI تشير إلى عمود تمت إعادة تسميته أو إزالته، فسيفشل التحديث. يمكنك التخفيف من ذلك باستخدام طرق عرض SQL كطبقة تجريد بين جداول Odoo الأولية وPower BI. عندما تؤدي الترقية إلى تغيير المخطط، قم بتحديث طريقة عرض SQL لتعكس البنية الجديدة. يستمر Power BI في الاستعلام عن مخطط العرض الثابت دون أي تغييرات. بعد كل ترقية لـ Odoo، قم بتشغيل تحديث Power BI يدويًا للتحقق من نجاح جميع الاستعلامات قبل التحديث المجدول التالي.
هل يمكنني دمج البيانات من أنظمة ERP متعددة في تقرير Power BI واحد؟
نعم، وهذه إحدى أقوى إمكانيات Power BI. يمكن للمؤسسات التي تقوم بتشغيل أنظمة تخطيط موارد المؤسسات (ERP) مختلفة في مناطق أو وحدات أعمال مختلفة إنشاء لوحات معلومات موحدة تجمع البيانات من جميع الأنظمة. المفتاح هو بناء مخطط تحليلي مشترك (مخطط نجمي) يعمل على تطبيع هياكل تخطيط موارد المؤسسات (ERP) المختلفة في تنسيق مشترك. تقوم جداول أبعاد العميل بدمج العملاء من كافة أنظمة تخطيط موارد المؤسسات (ERP) باستخدام معرف مشترك. تعمل أبعاد المنتج على محاذاة فئات المنتجات عبر الأنظمة. تعمل جداول الحقائق على توحيد المبالغ إلى عملة مشتركة والحالات إلى مفردات مشتركة. يمكن للنماذج المركبة الاتصال ببعض المصادر عبر الاستيراد وغيرها عبر DirectQuery.
كيف أتعامل مع علاقات Odoo متعدد إلى متعدد في Power BI؟
يستخدم Odoo جداول الوصلات (المسماة بالنمط {model1}_{model2}_rel) لعلاقات متعدد إلى متعدد، مثل علامات المنتج، وفئات الشركاء، وقوائم التحكم في الوصول. في Power BI، قم باستيراد جدول الوصلات وإنشاء علاقتين رأس بأطراف: واحدة من البعد الأول إلى جدول الوصلات، والأخرى من البعد الثاني إلى جدول الوصلات. يتعامل نمط جدول الجسر هذا بشكل صحيح مع تصفية متعدد إلى متعدد. انتبه إلى أن بعض علاقات Odoo متعدد إلى متعدد تنشئ صفوفًا تُعقد التجميع --- تحقق دائمًا من الإجماليات مقابل تقارير Odoo الأصلية أثناء التحقق من الصحة.
بقلم
ECOSIRE Research and Development Team
بناء منتجات رقمية بمستوى المؤسسات في ECOSIRE. مشاركة رؤى حول تكاملات Odoo وأتمتة التجارة الإلكترونية وحلول الأعمال المدعومة بالذكاء الاصطناعي.
مقالات ذات صلة
ميزات Power BI AI: مساعد الطيار، وAutoML، والتحليلات التنبؤية
ميزات Master Power BI AI بما في ذلك Copilot لتقارير اللغة الطبيعية، وAutoML للتنبؤات، واكتشاف الحالات الشاذة، والسرد الذكي. دليل الترخيص.
الدليل الكامل لتطوير لوحة تحكم Power BI
تعرف على كيفية إنشاء لوحات معلومات Power BI فعالة باستخدام تصميم مؤشرات الأداء الرئيسية وأفضل الممارسات المرئية وصفحات التصفح والإشارات المرجعية وتخطيطات الأجهزة المحمولة وأمان RLS.
نمذجة بيانات Power BI: تصميم مخطط النجوم لذكاء الأعمال
نمذجة بيانات Master Power BI مع تصميم المخطط النجمي، وجداول الحقائق والأبعاد، ومقاييس DAX، ومجموعات الحساب، وذكاء الوقت، والنماذج المركبة.