Dynamics 365 Business CentralのAL拡張を開発している場合、2026年5月19日の公式ドキュメント更新でまず確認すべき点は、品目諸費用の配賦サンプルにある with ステートメントが非推奨であることが明記されたという点です。これは機能廃止そのものではなく、Microsoft Learn上のサンプルコードに注意書きが追加された更新です。ただし、サンプルをそのままコピーしている開発チームでは、AL0606 警告や将来のビルド失敗につながる可能性があります。
今回のDynamics 365 ドキュメント更新は、管理者よりも主にBusiness Centralの拡張機能を作る開発者、SIer、運用保守チームに関係します。特に、品目諸費用の配賦方法をカスタマイズしている環境では、既存コードに with ... do が残っていないかを早めに確認し、レコード変数名を明示する書き方へ移行しておくべきです。
Dynamics 365の公式ドキュメント更新で何が変わったのか
今回の更新対象は、Dynamics 365 Business Centralの開発者向け記事「Extending Item Charge Distribution Methods」です。このページは、品目諸費用の配賦方法を拡張するためのALコード例を説明する公式ドキュメントで、Microsoft Learnでは最終更新日が2026年5月19日とされています。(Microsoft Learn)
更新内容の中心は、GetItemValues プロシージャのサンプルに使われている次のような with ステートメントに対して、非推奨であることを示すNoteが追加された点です。
with TempItemChargeAssgntPurch do
case "Applies-to Doc. Type" of
...
end;GitHub上のプルリクエストでは、このサンプルが with TempItemChargeAssgntPurch do を使っているにもかかわらず非推奨の説明がなかったため、開発者が新しいコードにそのままコピーすると非推奨警告が出る、という問題意識が示されています。プルリクエストは2026年5月19日にマージされています。(GitHub)
重要なのは、今回の更新が「Business Centralの品目諸費用機能が使えなくなる」という発表ではないことです。変更されたのは、公式サンプルコードの読み方に関する注意喚起です。ただし、サンプルコードは実装の出発点になりやすいため、開発現場では無視しにくい更新です。
更新内容の要点
| 項目 | 内容 |
|---|---|
| 更新日 | 2026年5月19日 |
| 対象 | Dynamics 365 Business Centralの開発者向けドキュメント |
| 対象記事 | Extending Item Charge Distribution Methods |
| 変更点 | 品目諸費用配賦サンプル内の GetItemValues プロシージャに、with ステートメント非推奨のNoteを追加 |
| 直接影響 | 既存の実行環境や設定が即時変更されるわけではない |
| 実務上の影響 | サンプルをコピーしたALコードで AL0606 警告が出る可能性がある |
| 推奨対応 | with を使わず、レコード変数名を明示してフィールドやメソッドにアクセスする |
公式記事では、該当サンプルの GetItemValues プロシージャが with ステートメントを使っており、これはBusiness Central 2020 release wave 2以降で非推奨であるため、新しいコードではレコード変数名でフィールドアクセスを修飾するよう案内されています。(Microsoft Learn)
そもそも品目諸費用の配賦とは何か
Business Centralの品目諸費用は、仕入や販売に伴う運賃、荷役費、保険料、輸送費などの追加コストを、対象の品目明細に配賦するための仕組みです。標準では「均等」「金額別」「重量別」「体積別」の配賦方法が用意されています。(Microsoft Learn)
たとえば、海外仕入で商品代金とは別に10万円の輸送費が発生した場合、その費用を在庫評価に反映させるには、対象品目の明細へ適切に割り当てる必要があります。標準の重量別配賦ではなく、独自の係数や業務ルールで配賦したい場合に、AL拡張で配賦方法を追加します。
公式サンプルでは、架空の「By Fairy Dust」という配賦方法を追加する例が示されています。ここで使われている GetItemValues プロシージャの一部に with が含まれていたため、今回の注意書き追加につながりました。
withステートメントが問題になる理由
with ステートメントは、レコード変数名を省略してフィールドやメソッドにアクセスできる構文です。一見するとコードが短くなりますが、Business CentralのAL開発では読みやすさと将来の安全性を損なう可能性があります。
たとえば、次のようなコードでは、Name や Modify() がどのレコードに対する操作なのか、文脈を追わないと分かりにくくなります。
with Customer do begin
Name := 'Foo';
Modify();
end;より安全な書き方は次のように、レコード変数名を明示する方法です。
Customer.Name := 'Foo';
Customer.Modify();Microsoftの説明では、with を使うと、将来ベースアプリやテーブル拡張に同名のフィールドやメソッドが追加されたときに、参照先の解決が変わる可能性があります。これにより、アップグレード時にコンパイルできなくなったり、より悪い場合は動作が変わったままアップグレードされるリスクがあります。(Microsoft Learn)
実務では、このリスクが特に問題になります。Business Central Onlineでは、プラットフォームやアプリケーションの更新時にコードが再コンパイルされます。普段は動いている拡張でも、上流側の変更で名前解決が変わると、アップデートのタイミングで警告やエラーが顕在化します。
影響を受ける環境
今回のドキュメント更新で、すべてのDynamics 365利用企業が対応を迫られるわけではありません。影響を受けるかどうかは、Business CentralのAL拡張を開発・保守しているかで判断します。
| 環境・担当者 | 影響度 | 確認すべきこと |
|---|---|---|
| Business Centralを標準機能のみで利用している企業 | 低 | 今回の更新による直接対応は基本的に不要 |
| 品目諸費用を標準配賦方法だけで使っている企業 | 低 | 独自拡張がなければ影響は限定的 |
| AL拡張を内製・外注している企業 | 中 | 拡張コードに with が残っていないか確認 |
| 品目諸費用の配賦方法をカスタマイズしている企業 | 高 | Item Charge Assignment 関連のコードを重点確認 |
| ISV・SIer・保守ベンダー | 高 | 顧客向けテンプレート、サンプル、教育資料の修正が必要 |
| CI/CDでALコンパイル警告を検知しているチーム | 中〜高 | AL0606 を警告扱いのまま放置していないか確認 |
特に注意したいのは、「公式サンプルを元に過去に作った拡張」です。サンプルコードの目的は考え方を示すことであり、そのまま本番品質のコードとして使えるとは限りません。今回の更新は、その点を改めて示すものでもあります。
管理者が確認すべきポイント
今回の更新は開発者向けの内容ですが、Business Centralの管理者も無関係ではありません。管理者は、実際にコードを書かなくても、拡張機能の保守体制と更新リスクを把握しておく必要があります。
自社環境に独自拡張があるか確認する
まず、Business Centralに導入されている拡張機能を確認します。内製アプリ、取引先ベンダーが作成したアプリ、AppSource経由のアプリが混在している場合は、それぞれ保守責任者を明確にしてください。
確認時の観点は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| 品目諸費用関連のカスタマイズがあるか | 仕入・販売伝票で独自の配賦方法を使っている場合は要確認 |
| ALソースコードを管理しているか | Gitなどで管理されていない場合、修正作業の見積もりが難しくなる |
| 開発ベンダーの保守契約が有効か | コンパイル警告の調査や修正依頼ができるか確認 |
| 定期更新前の検証環境があるか | 本番更新前に拡張のビルド・動作確認ができる環境が必要 |
| 警告を管理しているか | AL0606 などの警告を一覧化しているか確認 |
管理者がやるべきことは、with を直接修正することではありません。誰が、どの拡張を、どの環境で検証するのかを決めることです。
本番更新前にサンドボックスで検証する
Business Central Onlineを利用している場合、更新は継続的に行われます。拡張コードが古い書き方のままだと、ある更新タイミングで警告が増えたり、将来的にビルドエラーへ変わる可能性があります。
管理者は、サンドボックス環境で以下を確認してください。
| 検証項目 | 確認内容 |
|---|---|
| 拡張機能のインストール | 既存拡張が問題なくインストール・更新できるか |
| 仕入伝票・販売伝票 | 品目諸費用の追加、配賦、転記が正常に行えるか |
| 独自配賦メニュー | カスタム配賦方法が表示され、意図通りに計算されるか |
| 端数処理 | 丸め誤差が想定内に収まるか |
| エラー処理 | 未対応の伝票種類で異常終了しないか |
品目諸費用は在庫評価や原価に関係するため、単に画面が開くかどうかでは不十分です。転記後の金額、在庫評価、会計連携まで確認する必要があります。
開発者が確認すべきポイント
開発者は、まず既存コードに with が残っていないかを検索してください。対象は品目諸費用の拡張だけでなく、ALプロジェクト全体です。
検索すべきキーワード
Visual Studio CodeやGitの検索で、次のような文字列を確認します。
with
with(
do
#pragma warning disable AL0606
suppressWarnings
NoImplicitWith特に #pragma warning disable AL0606 や suppressWarnings がある場合は注意が必要です。警告を一時的に抑止するために入れた設定が、そのまま恒久対応のように残っている可能性があります。
Microsoftのドキュメントでは、AL0606 は明示的な with に対する警告、AL0604 は暗黙的な with に対する警告として説明されています。また、警告抑止の方法として app.json の suppressWarnings や #pragma warning も紹介されていますが、これは警告を消す手段であり、根本的な移行ではありません。(Microsoft Learn)
with をレコード変数名付きに書き換える
今回のサンプルに近いコードでは、次のような書き換えを検討します。
変更前のイメージです。
with TempItemChargeAssgntPurch do
case "Applies-to Doc. Type" of
"Applies-to Doc. Type"::Order:
begin
PurchaseLine.Get("Applies-to Doc. Type", "Applies-to Doc. No.", "Applies-to Doc. Line No.");
DecimalArray[1] := PurchaseLine.Quantity;
end;
end;変更後は、参照元のレコードを明示します。
case TempItemChargeAssgntPurch."Applies-to Doc. Type" of
TempItemChargeAssgntPurch."Applies-to Doc. Type"::Order:
begin
PurchaseLine.Get(
TempItemChargeAssgntPurch."Applies-to Doc. Type",
TempItemChargeAssgntPurch."Applies-to Doc. No.",
TempItemChargeAssgntPurch."Applies-to Doc. Line No.");
DecimalArray[1] := PurchaseLine.Quantity;
end;
end;少し長くなりますが、どのレコードのフィールドを参照しているかが明確になります。レビュー時にも、将来のアップグレード時にも安全です。
移行時に失敗しやすいポイント
with の削除は単純な置換に見えますが、実務ではいくつかの落とし穴があります。
| 失敗しやすい点 | 起きる問題 | 対策 |
|---|---|---|
| 文字列置換だけで対応する | フィールド、ローカル変数、別レコードの参照を取り違える | 1つずつコンパイルしながら修正する |
case のEnum参照を雑に書き換える | 列挙値の参照元が不明確になる | 元のレコード変数名を含めて修飾する |
| 警告抑止で済ませる | 将来のエラー化や動作変更リスクが残る | 抑止ではなくコード修正を基本にする |
| 品目諸費用の計算結果だけ見ない | 画面上は動いても原価・在庫評価がずれる | 転記後の金額までテストする |
| サンプルコードを本番コードに流用する | 業務要件に合わない端数処理や例外処理が残る | 自社ルールに合わせて設計し直す |
特に、with の内側にローカルプロシージャ呼び出しがある場合は慎重に確認してください。Microsoftの説明でも、with による名前解決の順序によって、将来追加された同名メソッドが優先される可能性が指摘されています。(Microsoft Learn)
CI/CDと展開時の注意点
開発チームでCI/CDを組んでいる場合、今回の更新を機にALの警告管理を見直す価値があります。警告を放置すると、将来のリリースで「突然ビルドできない」状態になりやすいためです。
警告を見える化する
まず、ビルドログで AL0606 と AL0604 を集計します。すぐに全件修正できない場合でも、次のように優先順位を付けると現実的です。
| 優先度 | 対象 |
|---|---|
| 高 | 品目諸費用、転記、在庫評価、会計連携に関わるコード |
| 高 | AppSource公開アプリや複数顧客に展開している共通アプリ |
| 中 | ページ、レポート、バッチ処理など利用頻度が高いコード |
| 低 | 既に廃止予定の機能、使用頻度が低い一時的なコード |
警告件数が多い場合は、まず重要業務に関わる拡張から対応します。品目諸費用は原価計算や在庫評価に直結しやすいため、優先度を高く設定するのが妥当です。
抑止設定を恒久対応にしない
app.json の suppressWarnings に AL0606 や AL0604 を入れると、警告を非表示にできます。しかし、これは移行中に作業ノイズを減らすための手段であり、非推奨コードの安全性を高めるものではありません。
どうしても一時的に抑止する場合は、次のようなルールを決めておくと管理しやすくなります。
| ルール | 例 |
|---|---|
| 抑止理由をコメントに残す | 「旧拡張の移行中。次回リリースで修正予定」 |
| 期限を決める | 次のマイナーリリースまでに削除 |
| 対象を限定する | 全体抑止ではなく、必要な箇所だけ #pragma を使う |
| レビュー対象にする | 抑止追加はPull Requestで必ずレビューする |
警告を消すことが目的になると、将来のアップグレード耐性が下がります。目的は、警告のない状態ではなく、名前解決が明確で保守しやすいALコードにすることです。
品目諸費用カスタマイズで見直すべき実装
公式記事では、品目諸費用の配賦方法を拡張するために、購買側では codeunit 5805「Item Charge Assgnt. (Purch.)」のイベントを利用する流れが示されています。具体的には、メニュー選択肢を操作する OnBeforeShowSuggestItemChargeAssignStrMenu と、実際に配賦処理を行う OnAssignItemCharges が説明されています。(Microsoft Learn)
この周辺をカスタマイズしている場合は、次の観点で見直してください。
配賦方法の追加処理
独自の配賦方法をメニューに追加している場合、他の拡張機能も同じメニューを操作する可能性があります。公式記事でも、他の拡張が選択肢を操作する可能性があるため、既存オプションの存在を決め打ちしないこと、他の拡張が追加したオプションを削除するようなコードを書かないことが注意されています。(Microsoft Learn)
実務では、次のような実装が安全です。
if StrPos(SuggestItemChargeMenuTxt, AssignByCustomRuleMenuText()) = 0 then
SuggestItemChargeMenuTxt += ',' + AssignByCustomRuleMenuText();逆に、固定位置を前提にして「3番目の選択肢を置き換える」といった実装は避けるべきです。他の拡張との競合が起きやすくなります。
配賦完了フラグの設定
OnAssignItemCharges で独自配賦を実行した場合、処理後に ItemChargesAssigned を true にする必要があります。公式記事では、このBooleanをtrueに設定しないとエラーが発生すると説明されています。(Microsoft Learn)
確認すべきコードの例です。
AssignByCustomRule(ItemChargeAssignmentPurch, Currency, TotalQtyToAssign, TotalAmtToAssign);
ItemChargesAssigned := true;この設定漏れは、テストケースによっては見落とされます。選択肢が独自配賦のときだけ通る分岐なので、標準配賦のテストだけでは発見できません。
端数処理と残額調整
品目諸費用の配賦では、数量や金額を複数明細に割り振るため、丸め誤差が発生します。サンプルコードでも、数量や金額の残りを保持しながら丸める考え方が含まれています。
本番実装では、次のようなケースをテストしてください。
| テストケース | 確認内容 |
|---|---|
| 明細が1行のみ | 全額が正しく割り当たるか |
| 明細が複数行 | 合計金額が元の品目諸費用と一致するか |
| 配賦基準値が0 | ゼロ除算や異常な配賦が起きないか |
| 小数点を含む数量 | 丸め後の数量・金額が想定内か |
| 通貨の丸め精度が異なる | Currencyの丸め精度に従っているか |
| 返品・入荷・出荷関連の伝票 | 対象伝票種別ごとの参照先が正しいか |
with の削除に合わせてロジックを整理する場合、計算結果が変わっていないかを必ず比較してください。コードの読みやすさを改善する作業でも、会計・在庫系の計算では回帰テストが欠かせません。
すぐに取るべき対応手順
今回のDynamics 365 ドキュメント更新を受けて、管理者と開発者は次の順番で対応すると効率的です。
| 手順 | 担当 | 実施内容 |
|---|---|---|
| 1 | 管理者 | Business Centralに独自拡張があるか確認する |
| 2 | 管理者・開発者 | 品目諸費用の配賦方法をカスタマイズしているか確認する |
| 3 | 開発者 | ALソース全体で with、AL0606、AL0604、警告抑止設定を検索する |
| 4 | 開発者 | with をレコード変数名付きの明示的な記述へ書き換える |
| 5 | 開発者 | CI/CDで警告件数を確認し、重要コードから順に解消する |
| 6 | 管理者・業務担当 | サンドボックスで品目諸費用の配賦、転記、金額を検証する |
| 7 | 管理者 | 本番展開前に保守ベンダーや関係者へ影響範囲を共有する |
小規模な拡張であれば、with の削除は短期間で対応できます。一方、古いAL資産を多く抱えている場合は、警告を一度にゼロにするより、重要領域から段階的に修正するほうが現実的です。
今回の更新をどう捉えるべきか
今回の「Dynamics 365 documentation update: Add deprecation note for with statement in item charges example」は、表面的には小さなドキュメント修正です。しかし、開発現場にとっては、古いALコードの保守性を見直す良いタイミングです。
特に、次の3点は早めに確認してください。
- 品目諸費用の配賦カスタマイズに
withが残っていないか AL0606やAL0604を警告抑止で隠していないか- サンプル由来のコードを本番要件に合わせて十分に検証しているか
Business Centralの拡張は、今動いているだけでは不十分です。継続的な更新に耐えられるよう、レコード変数名を明示し、名前解決のあいまいさを減らすことが重要です。まずはALコード全体を検索し、品目諸費用・転記・在庫評価に関わる箇所から優先的に修正計画を立ててください。
コメント