Power BI を ERP システムに接続する方法

増分更新とデータ変換を使用して Power BI を Odoo、SAP、Dynamics 365、Oracle、NetSuite、および QuickBooks に接続するためのステップバイステップ ガイド。

E
ECOSIRE Research and Development Team
|2026年3月17日8 分で読める1.7k 語数|
power-bierp-integrationodoosap+2

Power BI を ERP システムに接続する方法

ERP システムには、組織内の最も包括的な運用データが含まれています。注文、請求書、在庫移動、購入受領書、製造作業指示書、従業員のタイムシート、顧客とのやり取りなど、ビジネスを推進するあらゆる取引イベントがそこに記録されます。問題は、ERP システムがトランザクションを分析するためではなく、記録するために設計されていることです。ほとんどの ERP に組み込まれているレポートは、基本的な運用クエリには十分ですが、機能横断的な分析、傾向検出、予測、または複数のドメインからのデータを統合するエグゼクティブ レベルのダッシュボードが必要な場合には役に立ちません。

Power BI はこのギャップを埋めます。 ERP の基盤となるデータベースまたは API に接続し、トランザクション データを分析スター スキーマに変換し、ERP のネイティブ レポートでは表示できないパターンを明らかにする対話型ダッシュボードを提供します。ただし、接続は単に「Power BI をデータベースに接続する」だけではありません。各 ERP プラットフォームには独自のデータ構造、アクセス方法、および接続の構築方法、データのモデル化方法、長期にわたる統合の維持方法に影響を与える特徴があります。

このガイドでは、Power BI を 6 つの主要な ERP プラットフォーム (Odoo (当社の主な専門分野)、SAP、Microsoft Dynamics 365、Oracle、NetSuite、QuickBooks) に接続するための実践的な手順について説明します。私たちは、アーキテクチャの決定、接続方法、データ モデリング、増分更新、および生の ERP データを分析のゴールドに変える変換パターンに焦点を当てています。

重要なポイント

  • すべての ERP 統合は同じ 3 段階のパターンに従います: 接続 (データへのアクセス)、変換 (分析のための再構築)、モデル (スター スキーマ関係の構築)
  • Odoo の PostgreSQL データベースは、最も直接的かつ柔軟な Power BI 接続を提供します --- SQL ビューとマテリアライズド ビューは運用環境の展開に推奨されるアプローチです
  • SAP には SAP HANA または SAP BW コネクタが必要です。 SAP 環境では、データベースへの直接アクセスが許可されることはほとんどありません。
  • Dynamics 365 は Dataverse を通じてネイティブに統合され、すでに Microsoft エコシステムに参加している組織にとって最も簡単に接続できる ERP になります。
  • 大規模な ERP データセットには増分リフレッシュが不可欠です --- 数百万行のトランザクション テーブルの完全リフレッシュは持続不可能です
  • 運用テーブルを直接クエリするのではなく、常に ERP と Power BI の間に分析レイヤー (ビュー、ステージング テーブル、またはデータ ウェアハウス) を作成します。
  • Power Query でのデータ変換では、ERP 固有のパターン (複数通貨の正規化、会計カレンダーの調整、ステータス コードの変換) を処理する必要があります。

ユニバーサル ERP 統合アーキテクチャ

3 層のアプローチ

どの ERP を使用するかに関係なく、統合アーキテクチャは次の 3 つの層に従います。

レイヤー 1: 抽出。 ERP から Power BI にデータを取得します。これは、データベース接続 (PostgreSQL、SQL Server、Oracle)、API 呼び出し (REST、OData、SOAP)、または中間ストレージ (データ ウェアハウス、データ レイク、CSV エクスポート) を通じて行われます。抽出方法は、ERP がサポートしている内容と、組織のセキュリティ ポリシーで許可されている内容によって異なります。

レイヤー 2: 変換。 生の ERP データはトランザクションであり、正規化されています。分析用ではなく、挿入と更新用に最適化されています。それを分析図形に変換します。トランザクション明細を集計表に集約し、ステータス コードを読み取り可能なラベルにピボットし、複数通貨の金額を基本通貨に変換し、日付を会計カレンダーに合わせます。これは、Power Query、SQL ビュー、または専用の ETL ツールで発生します。

レイヤー 3: モデリング。 変換されたデータを、ファクト テーブル (販売、購入、在庫移動) とディメンション テーブル (顧客、製品、日付、倉庫) を含むスター スキーマに構造化します。リレーションシップを構成し、DAX メジャーを作成し、レポート作成者が使用するセマンティック レイヤーを構築します。

直接データベース、API、データ ウェアハウス

直接データベース接続 はセットアップが最も速く、柔軟性が最も優れています。 ERP のデータベースに対して SQL クエリを作成し、必要なデータを正確に取得します。ただし、データベースへのアクセスが必要であり (一部の ERP ベンダーはこれを推奨または制限していません)、クエリの最適化が不十分な場合は ERP のパフォーマンスに影響を与える可能性があり、分析を ERP のスキーマ (アップグレードによって変更されます) に直接結合します。

API 接続 は、ERP ベンダーの意図したアクセス パターンを尊重し、データベースのパフォーマンスに影響を与える危険はありません。ただし、API は通常、直接データベース クエリよりも遅く、レート制限がある場合があり、多くの場合、Power Query でのより多くの変換作業を必要とする階層形式 (JSON/XML) でデータを返します。

データ ウェアハウス は最も明確な分離を提供します。 ETL パイプラインは毎晩 ERP からデータを抽出し、分析スキーマに変換して、Power BI が接続する専用データベース (Azure SQL、Snowflake、PostgreSQL) に読み込みます。これは最も保守しやすい長期的なアーキテクチャですが、ETL パイプラインを構築するために最も多くの先行投資が必要です。

ほとんどの組織では、直接データベース接続 (または直接アクセスが不可能な場合は API) から始めて、分析環境が成熟してデータ ソースの数が増加するにつれて、データ ウェアハウスに移行することをお勧めします。

Power BI を Odoo に接続する

Odoo が Power BI に最適な理由

Odoo は、分析統合のためのアクセシビリティにおいて、ほとんどの ERP プラットフォームとは一線を画しています。これは、Power BI と最も親和性の高いデータベースの 1 つである PostgreSQL 上で実行されます。そのスキーマは十分に文書化されており、テーブルの命名には一貫性があり (module_model 形式)、オープンソースであるため、データベース アクセスにライセンスの障壁がないことを意味します。 Odoo を運用している場合は、世界クラスの Power BI ダッシュボードを構築するために必要なものがすべて揃っています。

ECOSIRE では、Odoo から Power BI への統合がコア コンピテンシーの 1 つです。当社は、販売、購買、在庫、製造、会計、人事、ヘルプデスク、プロジェクト管理など、Odoo モジュール全体にわたる分析ソリューションを構築してきました。ここで説明するパターンは、何百万もの ERP トランザクションを扱う組織に実装されているさまざまな環境で徹底的にテストされています。

PostgreSQL 直接接続

ステップ 1: リモート アクセス用に PostgreSQL を構成します。 Odoo インスタンスと Power BI ゲートウェイが異なるサーバー上にある場合、PostgreSQL はリモート接続を許可する必要があります。 postgresql.confにはlisten_addresses = '*'を設定します。 pg_hba.conf に、MD5 認証を使用してゲートウェイ サーバーの IP アドレスを許可する行を追加します。 PostgreSQL を再起動して変更を適用します。

ステップ 2: 読み取り専用データベース ユーザーを作成します。 Odoo のメイン データベース ユーザーを使用して Power BI に接続しないでください。専用の読み取り専用ユーザーを作成します。

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 のデータベース スキーマは、そのモジュール構造に直接マッピングされます。最も一般的な分析ドメインの主要なテーブルは次のとおりです。

販売分析:

オドゥーテーブル含まれています主要な列
コード0販売注文id、partner_id、date_order、amount_total、state、user_id、company_id
コード0注文品目order_id、product_id、product_uom_qty、price_unit、price_小計、割引
コード0顧客/ベンダーID、名前、電子メール、国 ID、業界 ID、会社タイプ
コード0製品マスターid、名前、list_price、standard_price、categ_id、type
コード0製品バリエーションid、product_tmpl_id、default_code

在庫分析:

オドゥーテーブル含まれています主要な列
コード0在庫移動product_id、location_id、location_dest_id、product_uom_qty、日付、状態
コード0現在の在庫レベル製品 ID、場所 ID、数量、予約数量
コード0倉庫ID、名前、コード、パートナー ID
コード0所在地ID、名前、使用法、location_id (親)

会計分析:

オドゥーテーブル含まれています主要な列
コード0仕訳/請求書id、partner_id、date、amount_total、state、move_type、journal_id
コード0エントリーラインmove_id、account_id、借方、貸方、残高、日付、partner_id
コード0勘定科目表ID、コード、名前、アカウントの種類
コード0ジャーナルID、名前、タイプ、コード

製造分析:

オドゥーテーブル含まれています主要な列
コード0製造注文製品 ID、製品数量、開始日、終了日、状態、BOM_ID
コード0ワークセンターID、名前、容量、時間効率
コード0部品表製品_tmpl_id、製品数量、タイプ

PostgreSQL での分析ビューの構築

運用環境の場合は、Odoo テーブルを分析形状に事前結合および事前集計する SQL ビューを作成することを強くお勧めします。これにより、複雑さが 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 のスキーマが変更された場合、複数のデータセットにわたって Power Query のステップを変更するのではなく、SQL ビューを 1 回更新します。

マテリアライズド ビュー は、結果を事前に計算して保存することでさらに進化し、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 分析を求めている組織向けに、ECOSIRE の Power BI ERP 統合サービス は、販売、在庫、会計、製造、人事をカバーする事前構築済みの Odoo ダッシュボード テンプレートを提供しており、Odoo の構成とビジネス要件に合わせて完全にカスタマイズされています。私たちのチームは Odoo と Power BI の両方について深い専門知識を持っており、BI コンサルタントが理解できない ERP を使用しようとしたときに通常存在するギャップを解消します。

Power BI を SAP に接続する

SAP 接続オプション

SAP 環境では、オープンソース ERP よりもデータベースへの直接アクセスが制限されています。ほとんどの SAP 顧客は、次の接続パスのいずれかを使用します。

SAP HANA コネクタ。 SAP S/4HANA のお客様の場合、Power BI のネイティブ SAP HANA コネクタは、HANA ビュー (分析ビュー、属性ビュー、計算ビュー) への直接アクセスを提供します。これは最もパフォーマンスの高いオプションであり、インポート モードと DirectQuery モードの両方をサポートします。関連するビューに対する SELECT 権限を持つ SAP HANA ユーザーが必要です。

SAP BW コネクタ。 SAP Business Warehouse を使用している組織の場合、Power BI は BW クエリ (BEx クエリまたは BW/4HANA 複合プロバイダー) に接続します。これにより、BW にすでに構築されている分析構造が活用され、Power BI でデータを最初からモデル化する必要がなくなります。

SAP OData サービス。 SAP は、OData API (特に SAP Gateway と SAP API Business Hub) を通じてビジネス データを公開します。 Power BI の OData コネクタはこれらのサービスを使用します。このアプローチは SAP の認証モデルを尊重していますが、データベースへの直接アクセスよりも遅く、大規模なデータセットの場合はページネーションの制限がある場合があります。

中間ストレージへの抽出。 複雑なシナリオの場合は、SAP のネイティブ ツール (オープン ハブ、SLT レプリケーション、CDS ビュー) を使用して SAP データを Azure Data Lake、Snowflake、または Azure SQL に抽出します。 Power BI は中間ストレージに接続します。これは、エンタープライズ展開にとって最も柔軟でスケーラブルなアプローチです。

SAP データモデリングの考慮事項

SAP のデータ構造は複雑で、深く正規化されています。 VBAK (販売注文ヘッダー)、VBAP (販売注文品目)、KNA1 (顧客マスター)、MARA (品目マスター) などのテーブルは、短く不可解な列名を使用し、変換のためにテーブルを結合する必要があるコード化された値を格納します。

SAP データから Power BI モデルを構築する場合:

コードを早めに変換します。 SAP では、国を 2 文字のコードとして、通貨を 3 文字のコードとして、材料タイプを「FERT」や「HALB」などのコードとして保存します。 Power Query ではなく、抽出クエリでテキスト テーブル (国は T005T、通貨は TCURT、材料タイプは T134T) と結合します。

SAP の日付形式を処理します。 SAP は日付を 8 桁の文字列 (YYYYMMDD) として保存します。NULL 日付の場合は「00000000」が使用されます。これらを変換レイヤーで適切な日付タイプに変換し、NULL 日付パターンを処理します。

認可オブジェクトを尊重します。 SAP の認可モデルは、各ユーザーがどのデータにアクセスできるかを詳細なレベルで制御します。 Power BI 用にデータを抽出するときは、抽出でこれらの境界が尊重されていることを確認するか、Power BI に同等の行レベルのセキュリティを実装してください。

Power BI を Dynamics 365 に接続する

データバース: ネイティブ パス

Dynamics 365 は Microsoft Dataverse にデータを保存し、Power BI には最高レベルの Dataverse 統合が備わっています。これにより、Dynamics 365 は、特に Microsoft エコシステムにすでに投資している組織にとって、Power BI に接続するのが最も簡単な主要 ERP になります。

Dataverse コネクタ。 Power BI Desktop → データの取得 → Dataverse。 Dynamics 365 資格情報を使用して認証します。必要なテーブル (エンティティ) を参照して選択します。コネクタは Dataverse のセキュリティ ロールを尊重するため、ユーザーにはアクセスを許可されたデータのみが表示されます。

Dataverse 用の Azure Synapse Link。 大規模な Dynamics 365 データセットの場合、Azure Synapse Link は Dataverse データを Azure Synapse Analytics または Azure Data Lake に継続的にレプリケートします。 Power BI は、Dataverse に直接クエリするのではなく、Synapse/Data Lake に接続します。これにより、Dynamics 365 へのパフォーマンスへの影響が排除され、複雑な変換のためのより優れたプラットフォームが提供されます。

TDS エンドポイント。 Dataverse は、Power BI が SQL Server コネクタを使用して接続できる表形式データ ストリーム (TDS) エンドポイントを公開します。これは、Dataverse データに対してカスタム SQL クエリを作成するシナリオに役立ちます。

分析用の 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 E-Business Suite / Fusion

Oracle EBS の場合は、ゲートウェイ マシンにインストールされた Oracle クライアントとともに Power BI の Oracle Database コネクタを使用します。 Oracle Fusion Cloud アプリケーションは、Power BI が Web コネクタまたは OData コネクタを通じて使用できる REST API を提供します。

Oracle の BI Publisher レポートは、Power BI が使用できる形式でデータを出力するように構成でき、Oracle のビジネス ロジックとセキュリティを考慮したベンダーがサポートする抽出パスを提供します。

ネットスイート

NetSuite は、Power BI 用に複数の接続パスを提供します。

SuiteAnalytics Connect (ODBC)。 NetSuite の ODBC ドライバーを使用すると、Power BI が ODBC コネクタを使用して接続できるようになります。これにより、ネイティブ NetSuite スキーマよりも分析に適したリレーショナル スキーマを使用して、NetSuite データセットへの SQL アクセスが提供されます。

SuiteQL API. NetSuite の REST API は、SQL に似たクエリ言語である SuiteQL をサポートしています。 Power BI は、カスタム Power Query 関数を通じてこの API を呼び出すことができます。これは、対象を絞った抽出には便利ですが、大規模なデータセットの場合は ODBC よりも効率が低くなります。

サードパーティ コネクタ CData などのツールは、ページネーション、認証、スキーマ マッピングを自動的に処理する NetSuite 用に最適化された Power BI コネクタを提供します。

Power BI を QuickBooks に接続する

クイックブック オンライン

QuickBooks Online は、Power BI が使用できる REST API を通じてデータを公開します。接続には、Intuit 開発者ポータルでの OAuth2 アプリの登録と、手動の OAuth トークン管理を備えたカスタム Power Query コネクタまたは Web コネクタが必要です。

ほとんどの QuickBooks ユーザーにとって、最も簡単なパスは、認証、ページネーション、データ型マッピングを処理するサードパーティのコネクタ (CData、Skyvia など) です。これらのコネクタは、Power BI でネイティブ データ ソースとして表示され、API の複雑さを抽象化します。

Power BI の主要な QuickBooks データ

損益計算書データ: 請求書、支払い、クレジットメモ、売上領収書 貸借対照表データ: 口座残高、仕訳入力 運用データ: 顧客、ベンダー、製品/サービス、見積もり

通常、QuickBooks のデータ ボリュームは十分に小さいため、完全な更新は高速 (5 分未満) で行われます。 QuickBooks の統合では、増分更新が必要になることはほとんどありません。

ERP データの増分更新

増分リフレッシュが不可欠な理由

ERP データベースは継続的に成長します。中規模企業では毎日数千件のトランザクションが発生します。数年後、販売注文テーブルには数百万行が含まれます。テーブル全体を毎朝更新すると、ゲートウェイのリソース、データベース容量、時間が無駄になります。

増分更新は、以前の更新でキャッシュされた履歴データを保持しながら、最近のデータ (たとえば、過去 30 日間) のみを更新するように Power BI に指示します。 45 分かかった完全更新は、3 分の増分更新になります。

構成手順

ステップ 1: Power Query パラメーターを作成します。 正確に RangeStart および RangeEnd という名前の 2 つのパラメーター (どちらも DateTime 型) を作成します。既定値を設定します (これらは Power BI Desktop でのみ使用され、サービスによってオーバーライドされます)。

ステップ 2: ソース クエリをフィルターします。 次のパラメーターを使用して、ファクト テーブルの日付列にフィルターを適用します。

#"Filtered Rows" = Table.SelectRows(Source, each [order_date] >= RangeStart and [order_date] < RangeEnd)

増分更新が機能するには、このフィルタをソース データベースに折りたたむ必要があります。 PostgreSQL (Odoo) に接続している場合、フィルターは PostgreSQL が実行する WHERE 句を生成し、一致する行のみを返します。

ステップ 3: 増分更新ポリシーを定義します。 Power BI Desktop で、テーブルを右クリック → [増分更新] をクリックします。設定:

  • アーカイブ データの開始: 履歴データをどれだけ遡って保持するか (たとえば、3 年)。
  • データの増分更新の開始: 最近のデータを更新する方法 (たとえば、30 日)。
  • 完了した期間のみを更新します: 部分的な日のデータの問題を回避するには、これをオンにします。
  • データ変更の検出: ソース テーブルに信頼できる「最終更新日」列がある場合に有効にします (変更されていないパーティションをスキップすることで、更新時間をさらに短縮します)。

ステップ 4: 発行して構成します。 Power BI サービスに発行した後、スケジュールされた更新を構成します。このサービスは時間ベースのパーティションを作成し、増分ウィンドウ内にあるパーティションのみを更新します。

ERP 固有の増分更新パターン

Odoo: write_date を変更検出列として使用します。 Odoo はレコードが変更されるたびにこのタイムスタンプを更新するため、変更された行を検出する信頼性が高くなります。

SAP: ほとんどの SAP トランザクション テーブルで使用できる AEDAT (変更日) フィールドを使用します。 HANA の場合、マテリアライズされた HANA ビューは変更追跡を提供できます。

Dynamics 365: Dataverse エンティティには、変更検出に適した modifiedon タイムスタンプがあります。 Azure Synapse Link は、組み込みの変更データ キャプチャを提供します。

Oracle: Oracle の rowscn または専用の last_update_date 列を使用します。 Oracle GoldenGate は、リアルタイム シナリオの変更データ キャプチャを提供できます。

データ変換のベスト プラクティス

複数通貨の正規化

ほとんどの ERP システムは、取引金額を取引通貨で保存します。分析ダッシュボードの場合、通常は単一のレポート通貨での金額が必要です。

2 つのアプローチ:

ソース側の変換。 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」がカレンダーの第 1 四半期 (1 月から 3 月) ではなく、会計年度の第 1 四半期 (7 月から 9 月など) を意味する財務ダッシュボードには不可欠です。

日付ディメンションにカレンダー属性と会計属性の両方を含めると、ユーザーはデータ モデルを変更せずに視点を切り替えることができます。

Power BI を特定の ERP 環境に接続するためのエンドツーエンドのサポートが必要な場合は、ECOSIRE の分析チームにお問い合わせ して要件について話し合ってください。私たちは Odoo 分析 に特化しており、主要な Odoo モジュールごとに事前に構築された Power BI テンプレート ダッシュボードを提供しています。

よくある質問

Power BI を ERP データベースに直接接続する必要がありますか、それともデータ ウェアハウスを使用する必要がありますか?

レポート数が少なく、データ量が中程度 (1,000 万行未満) の初期展開の場合、データベースへの直接接続の方がセットアップが速く、完全に適切です。分析環境が 10 ～ 15 レポートを超えて拡大するか、複数のソース システムからのデータを結合し始めると、データ ウェアハウスの価値が高まります。ウェアハウスは、Power BI の安定したスキーマ (ERP スキーマの変更から隔離)、クエリ パフォーマンスの向上 (事前集計とインデックス作成による)、およびビジネス ロジック (通貨換算、会計マッピング、ステータス変換) を実装する単一の場所を提供します。ほとんどの組織は直接接続から開始し、12 ～ 18 か月以内にウェアハウスに移行します。

Power BI クエリにより ERP システムの速度が低下しますか?

適切に管理されていない場合でも可能です。 Power BI のスケジュールされた更新では、ERP データベースに対して SQL クエリが実行され、CPU、メモリ、および I/O リソースが消費されます。これを軽減するには、オフピーク時間 (早朝、深夜) に更新をスケジュールし、分析クエリ用のリードレプリカを作成し (Odoo の場合は PostgreSQL ストリーミング レプリケーション、SQL Server の場合は Always On)、結果を事前計算するマテリアライズド ビューを使用し、増分更新を実装してスキャンされるデータを最小限に抑えます。ミッション クリティカルな ERP の場合、読み取りレプリカが最も安全なアプローチです。Power BI は運用データベースに影響を与えずにレプリカをクエリします。

データベース スキーマを変更する Odoo モジュールのアップグレードはどのように処理すればよいですか?

Odoo モジュールのアップグレードにより、データベースの列やテーブルが追加、名前変更、または削除されることがあります。 Power BI クエリが名前変更された列または削除された列を参照している場合、更新は失敗します。これを軽減するには、生の Odoo テーブルと Power BI の間の抽象化レイヤーとして SQL ビューを使用します。アップグレードによってスキーマが変更された場合は、新しい構造を反映するように SQL ビューを更新します。 Power BI は、変更を加えずにビューの安定したスキーマのクエリを続行します。 Odoo をアップグレードするたびに、次回のスケジュールされた更新の前に、Power BI 更新を手動で実行して、すべてのクエリが成功することを確認します。

複数の ERP システムのデータを 1 つの Power BI レポートに結合できますか?

はい、これは Power BI の最も強力な機能の 1 つです。さまざまな地域または事業単位でさまざまな ERP を運用している組織は、すべてのシステムからのデータを組み合わせた統合ダッシュボードを構築できます。重要なのは、さまざまな ERP 構造を共有フォーマットに正規化する共通の分析スキーマ (スター スキーマ) を構築することです。顧客ディメンション テーブルは、共通の識別子を使用してすべての ERP の顧客を結合します。製品のディメンションは、システム全体で製品カテゴリを調整します。ファクト テーブルは、金額を共通の通貨に、ステータスを共通の語彙に標準化します。複合モデルは、インポートを介して一部のソースに接続し、DirectQuery を介して他のソースに接続できます。

Power BI で Odoo の多対多の関係を処理するにはどうすればよいですか?

Odoo は、製品タグ、パートナー カテゴリ、アクセス制御リストなどの多対多の関係にジャンクション テーブル ({model1}_{model2}_rel というパターンで名前が付けられます) を使用します。 Power BI で、ジャンクション テーブルをインポートし、2 つの 1 対多のリレーションシップを作成します。1 つは最初のディメンションからジャンクション テーブルへ、もう 1 つは 2 番目のディメンションからジャンクション テーブルへです。このブリッジ テーブル パターンは、多対多のフィルタリングを正しく処理します。一部の Odoo 多対多リレーションシップでは、集計を複雑にする行が作成されることに注意してください。検証中は、Odoo のネイティブ レポートに対して常に合計を検証してください。

タグ：power-bierp-integrationodoosapdynamics-365data-analytics
共有：
E

執筆者

ECOSIRE Research and Development Team

ECOSIREでエンタープライズグレードのデジタル製品を開発。Odoo統合、eコマース自動化、AI搭載ビジネスソリューションに関するインサイトを共有しています。

すべての記事を見る

関連記事

power-bi

Power BI AI の機能: Copilot、AutoML、予測分析

自然言語レポート用の Copilot、予測用の AutoML、異常検出、スマート ナラティブなどの Power BI AI 機能をマスターします。ライセンスガイド。

6 分で読める
power-bi

Power BI ダッシュボード開発の完全ガイド

KPI 設計、視覚的なベスト プラクティス、ドリルスルー ページ、ブックマーク、モバイル レイアウト、RLS セキュリティを備えた効果的な Power BI ダッシュボードを構築する方法を学びます。

5 分で読める
power-bi

Power BI データ モデリング: ビジネス インテリジェンスのためのスター スキーマ設計

スター スキーマ設計、ファクト テーブルとディメンション テーブル、DAX メジャー、計算グループ、タイム インテリジェンス、複合モデルを使用した Power BI データ モデリングをマスターします。

6 分で読める
すべての記事に戻る
WhatsAppでチャット