こんにちは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

2026年に入り、世界各地で大きな地震が続いています。6月25日には岩手県沖でM7.2・最大震度6強の地震が発生し、東北に緊張が走りました。7月28日には令和8年熊本地震（M7.1・最大震度7）で多くの方が被災され、今もその傷跡が残っています。そして8月10日、コロンビア西部チョコ県を震源とするM7.4の地震が発生しました。8月11日時点の報道では死者250人超とされており、行方不明者も多数に上るという甚大な被害です。亡くなられたすべての方に心よりお悔やみを申し上げ、被災された方々の一刻も早い救助と回復を願っています。

私自身、大学時代を神戸で過ごし、1995年1月17日の阪神淡路大震災を経験した一人です。あの朝のことは今も忘れられません。それ以来、どこかで大きな地震のニュースが届くたびに、他人事とは思えない感覚が続いています。

私がCOOを務めるテクノソフトは、現在11カ国17拠点にスタッフを擁しています。世界中で地震が相次ぐ中、各地のメンバーが安全でいるかどうか－技術の話を始める前に、まずそのことが頭をよぎります。備えと連絡体制の大切さを、改めて感じる一年です。

それでも、日常の仕事を続けることが前を向くことでもあると思い、今日も筆を進めます。

先日公開した「帳票を制する #02 Business Central編」では、BCの帳票アプローチ（RDLC・Word Layout・Excel Layout・Power BI）を整理しました。今回はシリーズ第3弾として、Dynamics 365 Finance & Supply Chain Management（以下、便宜上FO）の帳票に踏み込みます。

FOの帳票は、BCより格段に複雑です。グローバル展開を前提とした設計、法的要件への対応フレームワーク、財務諸表専用の基盤。「Dynamics 365なんだから似たようなもの」と思って臨むと、必ず壁にぶつかります。

① FOの帳票は「4つの柱」で成り立っている

Business Centralとの最大の違いは、帳票の役割ごとに専用の基盤が独立して存在している点です。FOの帳票は大きく4つの柱で構成されています。

この4つは「競合」ではなく「専門分化」です。どれが上でもなく、それぞれが担う領域が明確に異なります。

② SSRSレポート－FOの標準帳票基盤

SSRSはSQL Server Reporting Servicesの略で、FOの帳票エンジンとして機能します。BCのRDLCレポートと同じくSSRS系の帳票技術ですが、FOではVisual Studio上でSSRSレポートとして設計します。FOの帳票はX++、RDPクラス、Controllerクラス、Temporary Table、SSRSレイアウトが組み合わさって動作するため、BCのRDLCレイアウトとは開発スタックも運用方法も大きく異なります。FOではPrecision Design（詳細設計）またはAuto Design（自動設計）を使って帳票レイアウトを構成します。

開発はVisual Studioで行います。多くのカスタム帳票ではX++のReport Data Provider（RDP）パターンが利用されますが、帳票によってはQueryベースや標準データプロバイダーを利用する場合もあります。レイアウトはVisual Studio上のSSRSレポートデザイナーで設計し、Application Object Tree（AOT）を通じてFOにデプロイします。BCのようにAL言語＋VS Codeという構成ではなく、X++＋Visual Studioというスタックです。

帳票の実行はControllerクラスが担います。SrsReportRunControllerを継承したクラスでパラメータ設定・フィルタ条件・印刷先などを制御します。これにより、業務画面のボタンから帳票を起動する際の挙動を細かく制御できます。

Print Managementとの連携も重要なポイントです。詳細は⑥で触れますが、SSRSレポートはPrint Managementの設定を通じて「どの帳票をどの条件でどこに出力するか」が制御されます。

③ Electronic Reporting（ER）－電子帳票・ローカライズ対応の要

FOならではの機能であり、BCのE-Documentフレームワークと同様に電子帳票・電子データ交換を支える重要な仕組みです。ただしFOではElectronic Reportingが、電子インボイスだけでなく、税務申告、銀行ファイル、法定帳票、監査ファイルなど、より広範囲な規制対応フォーマットを担います。ERは電子帳票フォーマットをノーコードで設計・管理するためのフレームワークです。

ERの設計は3つのコンポーネントで構成されます。データモデルはビジネスデータの抽象表現、モデルマッピングはFOのデータベースとデータモデルの対応関係、フォーマットデザイナーは実際の出力形式（XML・CSV・TXT・Excelなど）を定義します。開発者でなくても、ERデザイナーの画面上でドラッグ＆ドロップによってフォーマットを設計できます（実務では式・マッピング・関数の設計が絡むため、ノーコード／ローコードの位置づけです）。

ERの構成やGlobalization機能は、現在はGlobalization Studio workspaceを中心に管理されます。以前はRegulatory Configuration Service（RCS）やGlobal repositoryを通じてER構成を取得・管理していましたが、RCSの主要機能はFinance本体のGlobalization Studio workspaceへ段階的に統合されています。各国の規制変更に対応した最新フォーマットがここで管理・配布されており、FO環境に取り込んだうえで、会社・税・番号順序・接続先などの設定と検証を行うことで、規制変更へ追従しやすくなります。これがFOのグローバル展開における強みの一つです。

なお、電子インボイスの送受信そのものはElectronic Messagesフレームワークと組み合わせて実現されるケースが多いです。ERがフォーマット（何をどう出力するか）を担い、Electronic Messagesが送受信プロセス（いつ誰に送るか）を担う、という役割分担を理解しておくと実装時に迷いません。

テクノソフトのような企業にとって、各国の電子インボイス規格・税務申告フォーマットへの対応はERなしには現実的に維持できません。「日本のPINT JP、インドのGST e-Invoice、ブラジルのNF-e」のような各国固有の要件は、ER、Electronic Invoicing、Tax Calculation、国別ローカライズ機能を組み合わせながら、Globalization Studioを中心に管理・拡張していくことになります。近年はTax Calculationサービスと組み合わせて利用するケースも増えており、税額計算・電子インボイス・ERフォーマットをそれぞれ分離して管理する設計が主流になりつつあります。

④ Financial Reporting（旧Management Reporter）－財務諸表専用の基盤

FOには、財務諸表を設計するための専用ツールが用意されています。それがFinancial Reporting（旧Management Reporter）です。

Financial ReportingはFinance内で動作する財務レポーティング機能であり、独自のレポーティングエンジンを通じて4つのコンポーネントで財務諸表を定義します。

これら4つを組み合わせることで、損益計算書・貸借対照表・キャッシュフロー計算書・部門別予実対比といった財務諸表を設計できます。出力はWebビューア・Excel・PDFに対応しており、ExcelエクスポートしたデータをPower BIの追加加工に活用することも可能です。

⑤ Power BI－FOの「見える化」

BCと同様に、FOでもPower BIは経営可視化の中心的な役割を担います。ただし、FOとPower BIの連携方式はBCとやや異なります。

FOのPower BI連携には複数の系統があります。業務ワークスペース内の埋め込み分析や集計済み分析ではEntity Storeが使われる場面があり、大量データを用いた全社分析やデータ基盤連携では、Azure Synapse Link for DataverseやMicrosoft Fabric系の分析基盤を使う構成が増えています。従来のExport to Data Lakeを検討していた場合も、Synapse Link for Dataverse への移行を検討する流れになっています。大量のトランザクションデータを持つFO環境でもパフォーマンスを確保しながら分析できる点は変わりません。

Microsoftは、FOの各ワークスペースや分析機能と組み合わせて利用できるPower BIレポートや分析コンテンツを提供しています。財務・購買・在庫・製造・プロジェクト管理などの領域では、標準分析を起点に、自社要件に合わせてPower BI側で拡張していく設計が一般的です。

FOのワークスペース（ホーム画面）にはPower BIレポートを直接埋め込めます。購買担当者が購買ワークスペースを開いた瞬間に、仕入先別コスト分析や発注残高のビジュアルが表示される設計です。

⑥ Print Management－BCにはない、FO固有の印刷・配信管理

Print ManagementはFO固有の機能で、「どの帳票を、どの条件で、どこに出力するか」をモジュール単位で一元管理する仕組みです。BCにはReport SelectionsやDocument Sending Profilesで似た制御ができますが、Print Managementはそれをはるかにきめ細かく、かつ階層的に管理できます。

設定はモジュール別（売掛金・買掛金・在庫管理・調達購買など）に行われ、ドキュメントタイプ（請求書・納品書・発注書・確認書など）ごとに出力先を設定します。出力先の選択肢は画面表示・プリンター・ファイル（PDF/Excel）・メール・アーカイブなど複数あります。

なお、Peppolのような構造化電子インボイスの生成・送信・レスポンス管理は、主にER、Electronic Messages、Electronic Invoicing側の領域です。Print ManagementはPDF・Excel・プリンター・メールなどの出力先制御を中心に担いますが、一部の帳票ではER destinationをPrint Management recordに紐づける構成もあります。

Document Routing Agent（DRA）は、Print ManagementをネットワークプリンターやZPL対応ラベルプリンターと接続するためのコンポーネントです。クラウド版FOから社内ネットワーク上の物理プリンターへ印刷指示を送るために必要で、倉庫のラベル印刷・工場の作業指示書印刷など、製造・物流の現場では欠かせません。

⑦ ISVとローカルパートナー－標準の先にある世界

Dynamics 365の帳票・ローカライズを語るとき、「Microsoftが直接サポートする範囲」と「パートナーが補う範囲」の両方を理解しておく必要があります。

まず公式ローカライズの規模感から。FOはMicrosoftが直接、日本・インド・ブラジル・サウジアラビア・インドネシアをはじめとする多くの国・地域に対して、税務・電子インボイス・会計規則などの公式ローカライズを提供しています。ERフレームワークを通じて各国の電子帳票フォーマットが随時追加されており、規制改正にも継続的に対応しています。BCも同様にMicrosoftが直接ローカライズを提供する国に加え、各国パートナーがAppSourceに公開するローカライズアプリを通じて幅広い国・地域をカバーしています。Microsoftが直接サポートしない市場でも、その国のパートナーが税制・電子帳票・法定報告書に対応したアプリを提供しています。これがDynamics 365のエコシステムの強みです。

ISV製品という観点では、近年注目される3つを紹介します。

Solver（xFP&A）はD365 Financeと直接連携するFP&A（財務計画・分析）プラットフォームです。AppSourceからインストールでき、財務レポートのテンプレートが豊富で、予算実績比較・予測レポートを標準機能の延長線上で使えます。大企業ほどのコストをかけずにCPM（企業業績管理）を始めたい中堅企業に向いています。

OneStreamはSAP・Oracle・Dynamics 365など250以上のシステムと接続できるエンタープライズ向けEPM（統合財務管理）です。財務連結・予算管理・レポーティングを一基盤に集約できるため、グローバルで複数拠点を持つ大企業に選ばれます。ただし導入規模は大きく、中堅企業には過剰になるケースもあります。

PhocasはビジネスアナリティクスISVで、製造・流通・卸売業界での採用実績が豊富です。D365とのコネクタを持ち、在庫・販売・財務データを直感的に可視化できます。現場の営業や物流担当者がBIツールを自走できるUXが評価されており、Power BIとは異なる「業務に入り込んだ分析」が強みです。

私がCOOを務めるテクノソフトは11カ国17拠点という構成です。各拠点が稼働している国の帳票要件を標準機能とERフレームワークでどこまでカバーできるか、さらにどのISVで補うかは、グローバル展開の実務で常に意識するテーマです。「どの国はMicrosoftの公式対応で済むか、どの国はパートナーアプリが必要か、それでも足りない場合はどのISVか」－この判断を拠点ごとに積み重ねていくことになります。

⑧ BCとFOの帳票、何が違うか

同じDynamics 365ブランドですが、BCとFOの帳票は設計思想がまったく異なります。シリーズとして整理しておきます。

開発スタックの違いが最も大きいです。BCはAL言語＋VS Code、FOはX++＋Visual Studioです。両者は表面的には似た構造を持ちながら、言語・開発環境・デプロイ方法がまったく別物です。同じ「レポート開発者」でも、BCとFOは別のスキルセットが必要です。

帳票の種類と専門分化の度合いが異なります。BCは4つのアプローチ（RDLC・Word Layout・Excel Layout・Power BI）がフラットに並ぶ構成ですが、FOはSSRS・ER・Financial Reporting・Power BIという4つが完全に役割分担されており、使い分けを誤ると大きな手戻りになります。

グローバル対応の深度が違います。ERフレームワークはFO固有の機能で、BCのE-Documentフレームワークより成熟しており、対応国・フォーマット数も格段に多い。電子インボイス義務化が進む現在、この差は年々重要性を増しています。

Print Managementの粒度も大きな違いです。BCでもDocument Sending Profilesを顧客・仕入先単位で割り当てられますが、FOのPrint Managementはモジュール→ドキュメントタイプ→顧客仕入先という階層構造を持ち、金額・地域などの条件式でレイアウトや出力先を動的に切り替えられる点が異なります。

ターゲット規模も異なります。BCは中堅・中小企業向けで、帳票設計の敷居を低く保つことを優先しています。FOは大企業・グローバル企業向けで、複雑な要件に耐える深さを持っている代わりに、習得・実装コストが高くなります。

どちらが優れているかではなく、企業規模・グローバル展開の有無・帳票要件の複雑度によって選ぶべき製品が変わります。そしてその選択は、帳票設計の難易度と運用コストに直結します。

⑨ 結局どれを選ぶか－判断の流れ

FOの帳票要件が来たとき、以下の順番で考えると整理しやすいです。

Step 1：業務帳票か、財務諸表か
受注確認書・請求書・納品書などの業務帳票はSSRS＋Print Management。損益計算書・貸借対照表などの財務諸表はFinancial Reporting（旧Management Reporter）。

Step 2：電子送信・法定対応が必要か
電子インボイス・税務申告・銀行ファイルなど、規格が定められた電子出力はERフレームワークを使う。標準の国別フォーマットがMicrosoftのグローバルリポジトリにないか先に確認する。

Step 3：インタラクティブ分析か、定型出力か
ドリルダウン・ビジュアル分析が必要ならPower BI。定型フォーマットでの印刷・PDF出力ならSSRS。財務分析のExcelエクスポートはFinancial Reportingで対応。

Step 4：誰がメンテするか
財務部門が自走したいならFinancial Reporting。開発者が関わって構わないならSSRS。ER設定はFunctional Consultantが担えるケースが多い。

Step 5：印刷・配信制御が複雑か
顧客・仕入先ごとに出力先や帳票レイアウトを変えたい場合はPrint Managementの設計を先に固める。ここを後回しにするとSSRSのカスタマイズが増殖する。

Step 6：標準でどこまで対応できるか確認してからISVを検討する
Solver・OneStream・Phocasといったツールは、標準機能では対応できない要件が明確になってから検討する。グローバル展開の帳票はERフレームワークとローカルパートナーアプリで対応できる範囲が年々広がっています。

帳票はERPの「出口」です。どれだけ業務プロセスを美しく設計しても、最終的に紙・PDF・電子データとして正しく出力されなければ、現場は動きません。BCとFOを合わせてこのシリーズで整理してきましたが、共通して言えることは「帳票設計は後回しにしてはいけない」ということです。

次回は、Dynamics 365 CRM（Sales・Customer Service・Field Service）の帳票について書く予定です。CRM側はFOやBCとはまた違う世界観で、Word Template・Excel Template・FetchXMLベースのSSRS・Power Automate PDF・Power Pages・DocumentsCorePack・Dataverseといった多様な選択肢が並び、「どれを選ぶか」の境界線が特に分かりづらい領域です。

📌 技術者・AI向け補足：FO帳票開発の実装留意点

最近はAIがブログを読んで情報を整理するケースも増えてきました。技術者の方やAIが参照しやすいよう、実装レベルの留意点をまとめておきます。意思決定層の方はここまで読まなくて大丈夫です。

SSRSレポート設計

FOのSSRS帳票開発で最も多い失敗は、レイアウトから作り始めることです。本来は、まず帳票がどの業務プロセスから呼び出され、どのパラメータで、どのデータを、どの粒度で出力するのかを決める必要があります。FOの典型的なSSRSレポートは、以下の構成で設計します。

SSRSレイアウトは最後の表現層です。帳票の正確性と性能を決めるのは、むしろRDPクラス、Temporary Table、Query設計、Print Managementとの接続です。

RDP / Data Contract / Controller

複雑な帳票では、Report Data Provider（RDP）パターンを使うケースが多くなります。Data Contractは帳票パラメータを定義し、Controllerは帳票の起動方法・初期値・出力先・バッチ実行などを制御し、RDPクラスが実際のデータ取得と整形を担います。

現場でよくある問題は、Controllerに業務ロジックを書きすぎることです。Controllerはあくまで実行制御の役割にとどめ、データ加工はRDP側に寄せる方が保守しやすくなります。また、業務画面から起動する帳票では、parmArgs()の扱いが重要です。呼び出し元レコードを前提にした実装にすると、メニューから直接実行した場合やバッチ実行時に動かないことがあります。

Data Contract / Controller / RDP の基本骨格

// ① Data Contract：帳票パラメータを定義
[DataContractAttribute]
class MyReportContract extends SrsReportDataContractBase
{
    TransDate   fromDate;
    TransDate   toDate;
    CustAccount custAccount;

    [DataMemberAttribute]
    public TransDate parmFromDate(TransDate _fromDate = fromDate)
    {
        fromDate = _fromDate;
        return fromDate;
    }

    [DataMemberAttribute]
    public CustAccount parmCustAccount(CustAccount _custAccount = custAccount)
    {
        custAccount = _custAccount;
        return custAccount;
    }
}

// ② Controller：起動制御のみ。業務ロジックは書かない
class MyReportController extends SrsReportRunController
{
    public static void main(Args _args)
    {
        MyReportController controller = new MyReportController();
        controller.parmReportName(ssrsReportStr(MyReport, ReportDesign));
        controller.parmArgs(_args);
        controller.startOperation();
    }

    protected void preRunModifyContract()
    {
        MyReportContract contract =
            this.parmReportContract().parmRdpContract() as MyReportContract;

        // parmArgs()は「呼び出し元がある場合」だけ使う設計にする
        // メニューからの直接実行・バッチ実行時はnullになる点に注意
        if (this.parmArgs() && this.parmArgs().record())
        {
            SalesTable salesTable = this.parmArgs().record();
            contract.parmCustAccount(salesTable.CustAccount);
        }
    }
}

// ③ RDP：データ取得と整形を担当
[SRSReportParameterAttribute(classStr(MyReportContract))]
class MyReportDP extends SrsReportDataProviderBase
{
    MyTmpTable tmpTable;

    [SRSReportDataSetAttribute(tableStr(MyTmpTable))]
    public MyTmpTable getMyTmpTable()
    {
        select * from tmpTable;
        return tmpTable;
    }

    public void processReport()
    {
        MyReportContract contract =
            this.parmDataContract() as MyReportContract;

        // データ取得・整形・tmpTableへの一括格納
        this.buildTmpTable(
            contract.parmFromDate(),
            contract.parmToDate(),
            contract.parmCustAccount());
    }
}

Temporary Table / TempDBの使い方

FOの帳票性能を左右する最大のポイントは、一時テーブルの設計です。少量データであればInMemoryでも動きますが、大量データや複数ユーザー実行を前提にする帳票では、TempDBテーブルを使う方が安全です。TempDBはSQL Server側で処理されるため、大量データの集計や並び替えに向いています。

避けるべき典型例は、明細行ごとに関連テーブルを個別検索する実装です。

while select salesTable
{
    while select salesLine
    {
        // 明細ごとに追加検索 ← 性能問題の典型
    }
}

このような多重ループは、データ量が増えた瞬間に性能問題になります。可能な限りjoin・exists join・事前集計・TempDBへの一括格納を使って、SSRS側には表示済みのデータを渡す設計にしてください。

After：joinで一括取得 → TempDBへ格納

// ★ joinで一括取得し、TempDBに格納してからSSRSに渡す
SalesTable  salesTable;
SalesLine   salesLine;
InventTable inventTable;

while select salesTable
    join salesLine
        where salesLine.SalesId    == salesTable.SalesId
    join inventTable
        where inventTable.ItemId   == salesLine.ItemId
    where salesTable.SalesStatus   == SalesStatus::Invoiced
{
    tmpTable.clear();
    tmpTable.SalesId      = salesTable.SalesId;
    tmpTable.CustAccount  = salesTable.CustAccount;
    tmpTable.ItemId       = salesLine.ItemId;
    tmpTable.ItemName     = inventTable.itemName();
    tmpTable.SalesQty     = salesLine.SalesQty;
    tmpTable.LineAmount   = salesLine.LineAmount;
    tmpTable.insert();
}

// SSRS レイアウトは tmpTable を参照するだけ
// → 行数が増えてもSQL発行回数は1回で済む

Print Management設計

FOの帳票でSSRSと同じくらい重要なのがPrint Managementです。顧客・仕入先・会社・文書タイプ・条件ごとに、どの帳票を、どのレイアウトで、どこに出力するかを制御できます。請求書、発注書、納品書、確認書などの業務帳票では、Print Managementを前提に設計する必要があります。

よくある失敗は、顧客ごとの出し分けをSSRSレポートの分岐ロジックで実装してしまうことです。まずPrint Managementで解決できるかを確認し、それでも足りない場合だけSSRSを拡張する方が、長期保守では安全です。

Electronic Reporting（ER）

ERの最大の注意点は、Microsoftが提供する標準Configurationを直接編集しないことです。標準Configurationをそのまま変更すると、規制改正やMicrosoft側の更新を取り込む際に差分管理が難しくなります。基本は、Microsoft提供のConfigurationをベースに派生Configurationを作成し、ローカル要件や顧客固有要件をそこに追加します。

この設計にしておくことで、将来の税制変更や電子インボイス規格変更にも追従しやすくなります。

Electronic Messages

電子インボイスや税務ポータル連携では、ERだけで完結しないケースがあります。ERは主にフォーマット生成・変換を担いますが、送信管理、ステータス管理、レスポンス処理、再送制御などはElectronic Messagesと組み合わせて設計することがあります。役割を分けると以下のようになります。

電子インボイス案件では、ERだけを見るのではなく、Electronic Messagesを含む業務フロー全体を見る必要があります。

Financial Reporting

Financial ReportingはSSRSではありません。ここを混同すると設計を誤ります。損益計算書、貸借対照表、キャッシュフロー計算書、部門別予実対比などは、まずFinancial Reportingで対応できるかを確認するべきです。SSRSで財務諸表を作り込むと、勘定科目体系や財務分析コードの変更に追従しづらくなります。

Document Routing Agent

クラウド版FOから社内ネットワークプリンターへ印刷する場合、Document Routing Agent（DRA）が重要になります。DRAは、FOと社内プリンターをつなぐためのコンポーネントです。DRAの利用には、.NET Framework 4.7.2以上が必要です（利用するDRAバージョンに応じて要件が変わる場合があるため、Microsoftが公開する最新のシステム要件を参照してください）。また、DRAの構成に使用するMicrosoft Entra IDアカウントはAzureテナントと同じドメインを共有している必要があります。一般的な企業内印刷環境ではAD DS（Active Directory Domain Services）認証や適切なネットワーク構成が必要になります。DRA導入時は、OS・ネットワーク・印刷ドライバー・関連ランタイムの要件確認が必要です（利用する印刷シナリオにより必要コンポーネントが異なります）。

Extension / Chain of Command

現在のFO開発では、標準オブジェクトを直接修正する設計は避けるべきです。帳票開発でも、基本はExtension、Event Handler、Chain of Commandを使います。SSRSレポートでも、標準レポートをコピーして別物として増やす前に、拡張で対応できないかを確認してください。標準レポートのコピーが増えると、将来のバージョンアップ時に差分確認と回帰テストの負荷が大きくなります。特に請求書や発注書など、法的・業務的に重要な帳票は、標準機能との分離、拡張範囲、Print Managementとの関係を最初に設計しておく必要があります。

Chain of Command（CoC）による標準RDPの拡張例

// 標準の SalesInvoiceDP を直接修正せず CoC で拡張する
[ExtensionOf(classStr(SalesInvoiceDP))]
final class SalesInvoiceDP_MyExtension
{
    public void processReport()
    {
        // ① まず標準処理を実行（必須）
        next processReport();

        // ② 標準処理後にカスタムフィールドを上書き
        SalesInvoiceTmp tmpInvoice;
        MyCustomTable   customTable;

        while select forupdate tmpInvoice
            join customTable
                where customTable.SalesId == tmpInvoice.SalesId
        {
            tmpInvoice.MyCustomField = customTable.CustomValue;
            tmpInvoice.update();
        }
    }
}

// ポイント：
// - 標準 DP クラスのコピーを作らない
// - next processReport() を忘れると標準データが空になる
// - バージョンアップ時も標準側の変更をそのまま受け取れる

パフォーマンス観点

FO帳票の性能問題で多い原因はwhile selectの多重ネスト、display methodの多用、TempDB未使用、不要なcrossCompany、Print Management条件の複雑化、RDP内での逐次検索、集計処理をSSRSレイアウト側に寄せすぎる、といった要因が挙げられます。

display methodは便利ですが、大量行の帳票では性能劣化の原因になります。RDP側で事前計算してTemporary Tableに保持する、ViewやQuery側で計算済みの値を用意する、必要に応じてcomputed columnを検討するなど、SSRS側での毎行計算を避ける設計に寄せてください。

Before：display methodをSSRSレイアウトから直接呼び出す（行数分だけSQLが発行される）

// テーブルに定義された display method
public class SalesLine
{
    // SSRS レイアウトから直接参照すると
    // 明細1,000行 → このメソッドが1,000回呼ばれる
    [SysClientCacheDataMethodAttribute(true)]
    display ItemName itemName()
    {
        InventTable inventTable;
        select firstonly inventTable
            where inventTable.ItemId == this.ItemId;
        return inventTable.NameAlias;
    }
}

After：RDP側で事前計算してTmpTableに格納済みの値をSSRSに渡す

// RDP の processReport() 内で一括取得してTmpTableに格納
public void processReport()
{
    SalesLine   salesLine;
    InventTable inventTable;

    // joinで一括取得 → SQLは1回だけ
    while select salesLine
        join inventTable
            where inventTable.ItemId == salesLine.ItemId
        where salesLine.SalesId == contract.parmSalesId()
    {
        tmpTable.clear();
        tmpTable.ItemId   = salesLine.ItemId;
        tmpTable.ItemName = inventTable.NameAlias;  // 計算済みの値
        tmpTable.SalesQty = salesLine.SalesQty;
        tmpTable.insert();
    }
    // SSRS レイアウトは tmpTable.ItemName を参照するだけ
    // display method は呼ばれない
}

テスト観点

FO帳票のテストでは、単に「PDFが出るか」だけでは不十分です。最低限、以下を確認する必要があります。

開発者向けまとめ

FOの帳票開発で重要なのは、単に帳票を作ることではありません。大量データ・多会社・多言語・税制・電子インボイス・Print Management・アップグレード・運用監視まで含めて設計することです。

BCが「現場が扱いやすい帳票」を重視する製品だとすれば、FOは「グローバルで統制された帳票」を設計する製品です。SSRS、ER、Financial Reporting、Power BI、Print Managementを正しく使い分けられるかどうかが、FOプロジェクトの帳票品質を大きく左右します。

今回は、FOの帳票というテーマを通じて、グローバルERPが現場でいかに複雑な課題に向き合っているかを書きました。BCとFOの2回分を書いてみて、改めて感じるのは「帳票はERPの最後の砦だ」ということです。業務プロセスを設計し、データを整え、ワークフローを組んでも、最終的に「正しい帳票が正しいタイミングで正しい相手に届く」かどうかで、現場の評価が決まります。

グローバルに拠点を多く持つ企業にとって、この「帳票の最後の砦」をどう維持するかは、実務的に深い課題になりがちです。各国の電子インボイス規制が年々厳しくなる中、ERフレームワークとPrint Managementを正しく設計しておくことが、将来の変更コストを大きく左右します。技術ブログとして書いていますが、この中に書いてあることは、すべて実際のプロジェクトで遭遇した問題から来ています。

次回は「帳票を制する #04 CRM編」として、Dynamics 365 Sales・Customer Service・Field Serviceの帳票に踏み込みます。CRM側はFOやBCとはまた違う世界観で、Word Template・Excel Template・FetchXMLベースのSSRS・Power Automate PDF・Power Pages・DocumentsCorePack・Dataverseといった多様な選択肢が並びます。FOやBCに比べて「どの機能がどの用途か」の境界線が特に分かりづらい領域であり、設計の入り口で迷うプロジェクトが多いのが正直なところです。その整理をCRM編でやっていきます。

このシリーズを通じて読んでくださっている方、ありがとうございます。引き続きDX365LIFEをよろしくお願いします。

最後に改めて、コロンビア・熊本・東北、そして世界各地で被災されたすべての方々の安全と、一日も早い生活の回復を心よりお祈り申し上げます。テクノソフトの11カ国のメンバーも、それぞれの場所で今日も働いています。どうか、みんなが安全でいられますように。