Share via


Dynamics 365 財務と運用、Enterprise edition 7.3 の新機能および変更された機能

この記事では、Microsoft Dynamics 365 財務と運用、Enterprise edition 7.3 の新機能または変更された機能について説明します。 このバージョンは 2017 年 12 月にリリースされ、ビルド番号は 7.3.11971.56116 です。

最新の製品リリースの新機能および変更点の詳細については、新機能または変更点 および Dynamics 365 for Retail の新機能または変更点 を参照してください。

新機能についての補足情報の検索および開発中の新機能に関する詳細については、Dynamics 365 ロードマップ を参照してください。

需要予測エントリ データ エンティティがデータ管理フレームワークで有効になっている

需要予測のエントリ データ エンティティ (ForecastDemandForecastEntryEntity) でデータ管理フレームワーク (DMF) が有効になり、サード パーティ システムとの統合が可能になりました。

さらに、各需要予測のエントリは、順序番号 (エンティティ フィールド ForecastEntryNumber) で一意に識別されます。 すべての統合に関して、ソースまたはサードパーティ システムで存在しない場合でも、この固有識別子を検討してください。

データ パッケージのデモ データ

以前のリリースでは、多数の企業を持つデータベースとしてデモ データが提供されていました。 そのデータベースに加えて、データ管理フレームワークを使用する空の環境でデモ データを読み込むことができるように、デモ データの会社を使用するデータ パッケージも作成します。 これらのデータ パッケージは、特定のリリースでは、Lifecycle Services (LCS)のグローバル共有アセット ライブラリのアセットとして配信されます。 データ パッケージを読み込むための指示も提供されます。

データ パッケージは、既存のデモ会社と類似しているが同一ではなく、時間とともに変化する可能性があります。 パッケージは非常に小さく、デモ データを環境にインポートする前に、デモ データをすばやくダウンロードして変更することができます。 今後も複数の会社とモジュール機能の追加のデモ データを引き続き追加します。

Dynamics 365 for Project Service Automation から Dynamics 365 財務と運用の統合 - フェーズ1 (プライベート プレビュー)

Dynamics 365 for Project Service Automation から Dynamics 365 財務と運用への統合の最初のフェーズは、プライベート プレビューで使用できるようになりました。

Project Service Automation から財務と運用の統合ソリューションは、データの統合機能を使用して、Dataverse 経由で Microsoft Dynamics 365 財務と運用および Dynamics 365 for Project Service Automation インスタンス間でデータを同期します。 データ統合 機能で利用できる統合テンプレートは、Project Service Automation から Finance and Operations へのプロジェクト、プロジェクト契約、プロジェクト契約ラインの流れを有効にします。 Dataverse データ統合の詳細については、Power Apps ドキュメントの アプリ用 Dataverse へのデータ統合 を参照してください。

このソリューションは、次の領域で直接同期を提供します。

  • Project Service Automation でプロジェクト契約を管理し、Project Service Automation から Finance and Operations に直接同期させます。
  • Project Service Automation でプロジェクトを作成し、Project Service Automation から Finance and Operations に直接同期させます。
  • Project Service Automation でプロジェクト契約明細行を管理し、Project Service Automation から Finance and Operations に直接同期させます。
  • Project Service Automation でプロジェクト契約明細行のマイルストーンを管理し、Project Service Automation から Finance and Operations に直接同期させます。

プライベート プレビューに参加するように組織を推薦するには、https://aka.ms/psafinandopsintpreview のアンケートを記入してください。

Dynamics 365 for Sales と Dynamics 365 財務と運用間での見込顧客の現金化の拡張統合

Dynamics 365 for Sales と Dynamics 365 財務と運用、Enterprise edition 7.3 の間の見込顧客の現金化統合の拡張により、次のプロセスでの直接同期が可能になります。

  • Sales でアカウントを管理し、顧客として Finance and Operations に同期させます。
  • Sales の連絡先を管理し、顧客または顧客向けの連絡先として Finance and Operations に同期させます。
  • Finance and Operations での製品を管理し、Sales に同期させます。
  • Sales で見積を作成し、Finance and Operations に同期させます。
  • 既存の製品に対して Sales で販売注文を生成し、Finance and Operations に同期させます。
  • Finance and Operations で販売注文を生成、変更、および履行し、Sales に同期させます。
  • Finance and Operations で請求書を生成し、Sales に同期させます。

これらの統合機能拡張のハイライトは次のとおりです。

  • 見積、販売注文、および請求書 (番号順序を手動に設定する必要はありません) の番号のデータ エンティティの上書きをサポートします。
  • 単位あたりの行ごとに、見積、売上、または請求書の行割引を変換します。
  • 運賃税など、Finance and Operations から Sales への税関連の料金の同期をサポートします。
  • Sales から Finance and Operations への販売注文同期をサポートするための追加機能。
  • Finance and Operations から Sales への販売注文同期をサポートするための追加機能。
  • データ エンティティで公開された請求先住所の国/地域の ISO コードのサポートを同期します。

詳細情報

経費管理モバイル ワークスペースの強化

この機能は、経費管理のモバイル ソリューションでは利用できない、経費管理で利用可能な機能をサポートします。 このリストには次のものが含まれます (ただしこれに限定されません)。

  • マイレージ経費のサポート。
  • 会社間経費のサポート。
  • 日当経費のサポート。

詳細については、経費管理モバイル ワークスペース を参照してください。

Power BI を使用した財務報告

Power BI を使用した新しい視覚化を使用する一連の既定のレポートは、財務報告に使用できます。 新しい財務レポートは、Finance and Operations に組み込まれ、シームレスなレポート作成エクスペリエンスを提供し、サポート ドキュメントにドリルダウンすることができます。 制限付き補助元帳データは、元帳と補助元帳の分析を向上させるために使用できます。 試算表、貸借対照表、損益などの既定のレポートはすぐに出荷されますが、最初は Finance and Operations を使用した編集は許可されません。 編集は、Power BI デスクトップを使用して行う必要があります。 レポート デザイナーを使用した既存の財務諸表は引き続き使用可能で、完全にサポートされています。

Power BI を使用した財務諸表についての追加情報を表示するには、次のビデオをご覧ください: Dynamics 365 財務と運用のレポート

固定資産ロール フォワード レポート

新しい 固定資産ロール フォワードレポートは、期間決算、財務諸表、および税レポートに必要な詳細な固定資産データを、分かりやすい Excel 形式で提供します。 GER フレームワークを利用したこのレポートは、特定期間の固定資産財務の詳細を示しています。 包括的なデータには、特定の期間内に発生した新たな資産の取得および処分に加え、個々の資産の開始時および終了時の残高および当期の評価移動が含まれます。 固定資産グループおよび法人の合計が提供されます。

グローバル補充 - コンフィギュレーション可能な電子申告

複数の新機能が電子申告 (ER) フレームワークに追加されました。

  • XML 形式で受信したドキュメントからのデータ インポートのサポートの改善 – 1 つの ER 書式を設定して、異なる形式の受信中の XML ファイルからデータをインポートできるようになりました。 たとえば、さまざまなルート要素、またはフォーマットであらかじめ定義されているルート要素、または特定の親要素の入れ子になった要素の任意の順序を持つことができます。 これにより、お客様は ER ソリューションの管理に必要な労力を削減し、既存の ER ソリューションを容易に採用して新しい要件をサポートできます。
  • CSV 形式で受信したドキュメントからの構成可能なインポート - ER を使用して、受信したドキュメントからのデータのインポートを CSV 形式で構成できるようになりました。 もともと XML およびテキスト形式の受信ファイルからのインポートのみをサポートするために設計された ER 形式は、特殊文字で区切られた表形式データ、および引用符の文字で囲まれた表形式データを格納するプレーンテキストのような他の形式で受信したドキュメントを解析するために使用できます。 これにより、お客様は支払い、決済およびその他のプロセスに導入できる特定の要件を容易に採用できます。
  • ER ソリューションのインポートの前提条件を確認する - この機能を使用すると、現在のアプリケーション インスタンスとインポート用に選択された ER 構成のコンプライアンスを確認できます。 選択したインポート用 ER コンフィギュレーションと互換性のあるアプリケーションを作成するために必要な前提条件をインストールするために必要な労力を大幅に削減する必要な KB 番号の一覧として、不足しているアプリケーションの更新 (存在する場合) があれば、その一覧が表示されます。
  • アプリケーション クラスのメソッドの呼び出しによるアプリケーション ロジックの再利用 – 引数を使用してアプリケーション クラスのメソッドを呼び出すための ER の式を構成する既存の機能が改善されました。 この新しい機能では、ER データ ソースを使用して、実行時にこのような引数の値が動的に定義される式を構成することができます。 これにより、お客様はアプリケーションのソースコードで必要なロジックがすでに利用可能な場合に、ER ソリューションを構成するために必要な労力を大幅に削減できます。
  • 集計関数とデータ グループ化の計算の改善 – GROUP BY タイプの一部の ER データソースの場合、データ グループ化と集計関数の計算はデータベース (SQL) レベルで実行できます。 これにより、お客様は、特に多くのレコードを含むトランザクション データ ソースの ER レポートのパフォーマンスを大幅に向上させることができます。
  • 受信したドキュメントからの情報に基づくレコード削除 – 新しいレコードを挿入するか、既存のレコードを更新するだけで、受信したドキュメントからデータをインポートするための ER フォーマットを設定できるようになりました。 既存のレコードの削除のロジックを構成することもできます。 顧客はこれにより、ER フレームワークを構成可能なものとしてさまざまな業務プロセスの自動化に使用できる機会が増えます。
  • ER フレームワークにアクセスする API の変更 - ER フレームワークにアクセスする既存の API が変更されました。(ほとんどの X++ クラスは外部の C# アセンブリに移動され、残りのクラスは内部としてマークされました。) 新しい API によって、ER フレームワークの下位互換性が向上します。 これにより、将来のアプリケーションの更新で、お客様は ER 関連のコード変更を管理するために必要な労力を大幅に削減できます。

詳細については、「電子申告の概要」を参照してください。

在庫トランザクションのログ (InventSumLogTTS) の最適化

在庫トランザクションのログ (InventSumLogTTS) がすべての品目に対して有効になり、ログに古いレコードは自動的に削除されます。

これらの変更により、特定の条件でレコードが在庫トランザクションのログ テーブル (InventSumLogTTS) に挿入されなくなります。 これにより、テーブルが大きくなりすぎてパフォーマンス上の問題が発生することがなくなります。

会社で計画プロセスが有効になると、すなわち、マスター プラン>設定>マスター プランのパラメーター>すべての計画プロセスの無効化いいえ に設定されると、在庫トランザクションのログ (InventSumLogTTS) は次の場合に有効になりません。

  • トランザクションの倉庫には、手動補充設定があります。
  • 品目の分析コードと製品分析コードは手動です。
  • トランザクションは 在庫状況のブロック に関連しています。

このアイテムは、品目マスターの 製品ライフサイクルの状態 パラメーターを使用した計画のために無効になっています。

会社で計画プロセスが無効になると、すなわち、マスター プラン>設定>マスター プランのパラメーター>すべての計画プロセスの無効化はい に設定されると、在庫トランザクションのログは有効になりません。

在庫トランザクション ログ テーブルは、90 日以上経過したすべてのレコードを削除するために定期的にクリーンアップされます。 クリーンアップは、マスター プランを再生成することによって自動的にトリガーされます。

インド ローカライズ

インド ローカライズは、次の機能を使用できます。

  • TDS および TCS を含む、源泉徴収税。
  • 固定資産は、会社法による減価償却、所得税法による減価償却、および特別償却を含みます。
  • 付加価値税 (VAT)
  • 関税およびインドの商品及びサービス税 (GST)。 詳細については、この記事の "税エンジン (GTE) – インドの販売税のみ" セクションを参照してください。

倉庫と輸送の管理のためのマスターおよび参照データ エンティティ

サプライ チェーン マネジメントの領域の設定データに対して、データ エンティティのサポートが有効になりました。 倉庫および配送領域については、既定のコンフィギュレーション テンプレートに拡張が行われました。 既定のコンフィギュレーション テンプレートは、コンフィギュレーション データを 1 つのインスタンスから別のインスタンスに単一のステップでコピーするために必要なエンティティと順序を提供します。

詳細については、倉庫コンフィギュレーション テンプレートを使用した倉庫の設定 を参照してください。

販売時点管理での通知

今日の最新の小売環境では、店舗の関係者は、顧客の支援、トランザクションの実行、在庫棚卸、店舗での受注などのさまざまなタスクが割り当てられています。 販売時点管理 (POS) クライアントは、これらおよびそれ以上の関連付けを、1 つのアプリケーションで支援します。 1 日のうちに実行されるさまざまなタスクでは、タスクが注意を必要とするときに関係者に通知する必要があります。 この要件に対処するために、通知機能を使用する通知フレームワークを POS で作成しました。 このリリースでは、通知は POS 操作に対してのみ有効でき、さらに枠を超えて、通知は注文のフルフィルメント操作に対してのみ有効にできます。 ただし、通知フレームワークは拡張可能なため、開発者が任意の操作のカスタム コードに容易にプラグインできるようにします。 どのような通知を誰が受け取るかを小売業者が容易に定義できるようにする、ロール ベースの通知を構成する機能も提供しています。

最適化アドバイザー

  最適化アドバイザー ワークスペースでは、ビジネス ユーザーが所有するビジネス プロセスを最適化するためにベスト プラクティスに従うことができます。 これは、業務プロセスを分析し、最適化の機会を検出し、アプリケーション データを利用して、機会を定量化してから、ビジネス目標に対する有効性およびアプリケーションのパフォーマンスの両方を改善できるソリューションを推奨します。

最適化アドバイザーでは、ビジネス ユーザーは以下の内容を実行することができます。

  • 1 つの場所でプロアクティブ、定量化された、使用可能な、およびカスタマイズされた最適化の機会を検索します。
  • 推奨されるアクションを実行します。
  • 推奨されるアクションを実行することの影響を分析します。

現在のリリースでは、アドバイザーが最適化する案件を提供します。

  • 在庫決算のパフォーマンス。 
  • 倉庫管理内でのウェーブ処理と作業の作成のパフォーマンス。
  • 実際のビジネス プロセスを反映するためにシステム コンフィギュレーション設定を更新することによるアプリケーションの全体的なパフォーマンス。 
  • BOM、工順、および在庫管理にわたるマスター データ品質。

詳細情報

材料の部分的なリリースおよび生産工程あたりのリリース材料

以前は、製造オーダーがリリースされたとき、注文のすべての材料が倉庫にリリースされていました。 一部の生産シナリオでは、これが最適なプロセスではありませんでした。 たとえば、次のシナリオを考えてみます。

  • さまざまな工程で材料が消費される製造オーダー。
  • 実行時間の長いの製造オーダーは、すべての材料が使用可能ではないか、作業現場に十分なスペースがないため、製造オーダーの合計数量の材料を一度にリリースできません。

このようなシナリオのサポートを向上させるために、リリース プロセスは次の機能が強化されました。

  • 材料のリリースを操作または選択された操作を限定する機能。
  • 完成品の部分的な数量の材料をリリースする機能。 プロセス産業では、たとえば、これが注文のスケジュールされている材料すべてを一度に消費するわけではないバッチ オーダーで役立ちます。 たとえば、1 日またはシフトごとに完成品を 1000 個生産する計画をする場合、この数量の要求に一致する原材料のリリースを簡単に制限できます。

支払 SDK および Retail POS ハンドラー

支払 SDK - 支払 SDK から POS にカスタム エラー メッセージを送信するサポートを追加しました。 以前、POS は、すべてのメッセージを POS で定義されている標準のエラー メッセージに変換していました。 現在は、支払エラーのトラブルシューティングを容易にするために、カスタム メッセージとエラー コードを送信できます。

POS ビューの拡張機能 – POS ピッキング、カスタム列を追加するための受信画面を拡張するためのサポートが追加されました。

POS API - 取り置きのようなシナリオのコードを使用した預金の上書きをサポートするための、新しい預金の上書き API が追加されました。

POS 上書き可能な要求ハンドラー - 拡張機能として、ロジックを上書きしてシリアル番号の入力を自動化する新しいハンドラーを POS に追加しました。 拡張子が POS で入力されたシリアル番号の変更を必要とする場合は、新しい取得シリアル番号ハンドラーを上書きできます。 たとえば、POS で、ダイアログ ボックスがシリアル番号を保存しても、外部 Web サービスまたは自動生成されたシリアル番号を呼び出すことによって、フローを自動化でき、この要求を上書きすることができます。

拡張機能のサンプル - 既存のサンプルに加えて、拡張機能を持てるようにするため、以下のサンプルを小売 SDK に追加しました。

  • 営業時間の小売プロキシの拡張機能と、クロス ロイヤルティ サンプル。
  • ピッキングおよび受信画面のカスタム列サンプルです。
  • POS シリアル番号の自動化サンプル
  • 追加の POS API サンプル。

プロダクト構成の強化

1 つまたは複数の列の属性を調整 - 構成エクスペリエンスを最適化するために、1 つ以上の列に属性を調整できます。 列の最大数は 10 で、既定の数は 1 です。 これにより、1 つの構成ステップで多数の属性を持つ構成体験をモデル化することが容易になります。 フィールドを設定する前に、最初のグループ属性を作成する必要があります。 いくつかの属性がグループに追加されていない場合は、一番左側の列に表示されます。 属性グループにすべての属性が割り当てられている場合、列にグループが表示されます。

製品構成の Z3 ソルバー戦略を有効にする - Z3 ソルバー戦略は、製品構成に使用できます。 多くのベンチマーク テストで、ソルバーは Microsoft Solver Foundation (MSF) ソルバーと比較して大幅なパフォーマンス向上が示されています。 新しい Z3 ソルバー戦略は、コンフィギュレーション モデルごとに割り当てられます。 その他 3 つのソルバー戦略は、既定トップダウン、および最小ドメインを先頭にするの MSF のすべての戦略であることに注意してください。

詳細については、製品コンフィギュレーションのソルバー戦略 を参照してください。

製品構成モデルのインポート、エクスポート、および移行 – 標準データ エンティティを使用して、製品構成モデルとモデル バージョンをエクスポートおよびインポートすることができます。 コンフィギュレーション モデルは XML 構造としてエクスポートされ、単一のエンティティに保管されるため、エクスポートおよびインポートが簡単になります。  

製品ライフサイクルの状態

製品ライフサイクル状態は、リリース済み製品および製品バリアントで利用できるようになりました。 都道府県名と説明を割り当てることにより、製品ライフサイクルの状態の番号を定義できます。 新しいリリース済製品の既定の状態として、1つのライフサイクルの状態を選択できます。 リリース済製品のバリエーションは、リリースされた製品マスターから、製品ライフサイクルの状態を継承します。 リリース済製品マスターのライフサイクルの状態を変更する際、同じの元の状態にあるすべての既存のバリエーションを更新することもできます。  

特定の製品または製品バリアントのライフサイクルにおける状況を制御し理解するためには、製品ライフサイクル管理ソリューション (PLM) で製品のライフサイクル状態を可変状態モデルに関連付けることがベストプラクティスです。 この機能は、リリースされた製品モデルに追加されました。 この拡張の主な目的は、マスター プランと BOM レベル計算から構成を含む旧式の製品と製品バリアントを除外できるスケーラブルなソリューションを提供することです。

マスター プランへの影響 – 製品ライフサイクルの状態では、1 つの制御フラグ: 計画に対して有効 のみです。 既定では、これはすべての製品ライフサイクルの状態ではいに設定されています。 フィールドがいいえに設定されると、関連付けられているリリース済製品または製品バリアントは以下のようになります。

  • マスター プランから除外
  • BOM レベルの計算から除外

パフォーマンス上の理由から、全ての古い形式のリリース済製品または製品バリアントを、特に再使用不可能な製品コンフィギュレーション バリアントを操作する際、マスタープランに対して無効な製品ライフサイクルの状態に関連付けることを強くお勧めします。  

古い形式のリリース済製品および製品バリアントを検索 - 分析を実行して、古い形式のリリース済製品および製品バリアントを検索および更新できます。

シミュレーション モードで分析を実行すると、古い形式として識別されたリリース製品と製品バリアントは、確認用に特定のフォームに表示されます。 分析では、トランザクションおよび特定のマスター データを検索して、特定の期間内に需要のないリリース済みの製品または製品バリアントをを見つけます。 特定の期間内に作成される新しいリリース済製品は、分析から除外できます。  

分析シミュレーションから期待された結果が返されると、古い形式として識別されるすべての製品に新しい製品ライフサイクルの状態を割り当てることによって、ユーザーは分析を実行できます。  

移行、インポート、エクスポート中のの規定値

  • 以前のリリースから移行するとき、すべてのリリースされた製品および製品バリアントのライフサイクルの状態は空白になります。  
  • データ エンティティを通じてリリース済製品をインポートする際、既定のライフサイクルの状態が適用されます。  
  • データ エンティティを通じてリリース済製品バリアントをインポートする際、リリース済製品マスターの製品ライフサイクルの状態が適用されます。 

ノート

リリースされた製品または製品バリアントのデータ エンティティを使用して個々の製品ライフサイクルの状態を設定する機能はサポートされていません。

詳細については、製品ライフサイクルの状態 を参照してください。

小売プロキシ - インライン変更なしで小売プロキシの拡張機能をサポートするために追加された新しい拡張ポイント

以前は、POS オフライン モードで新しい CRT/RS 拡張機能を、または電子商取引の拡張機能をサポートするために、Retail プロキシ プロジェクトをインラインで変更して Retail プロキシを生成する必要がありました。 現在は、完全に新しい拡張機能としてインライン変更を行わずにプロキシを生成できます。 また、拡張プロキシ間のコード マージなしで、複数の ISV/パートナー拡張プロキシのサポートも追加しました。 これにより、プロキシ拡張のシームレスなアップグレードが可能になります。

詳細については、Retail の Typescript プロキシと C# プロキシ を参照してください。

安全在庫補充の拡張機能

任意の時点で、品目の利用可能在庫が安全在庫要件を上回らなければならないという制約は、出荷受注、製造オーダー、およびその他の実際の、独立要求、または依存要求の遅延を招く可能性があります。 たとえば、5 日間のリード タイムを持つ品目に対して、在庫に品目が 10 個あり、安全在庫レベルが 10 に設定されている場合、販売明細行は 5 日間延期され、品目の計画オーダーの配送を待機します。

販売明細行、BOM 明細行、要件の移行、または需要予測明細行などの実際の需要の実行に関して遅延が生じるとシステムが判断する場合、利用可能な在庫が常に安全在庫要件トランザクションを上回らなければならないという制約の優先度が下がります。 それ以外の場合は、利用可能な在庫が安全在庫数量以上であり、その他の需要のタイプと同じ優先度であることを確認します。 これにより、実際のトランザクションに遅れがなく、安全在庫の超過補充および早期補充を防ぐのにも役立ちます。

マスター プランの補充フェーズでは、安全在庫補充の優先度が下がることはもうありません。 現在、手持在庫は、他の任意の需要タイプの前に使用できます。 延滞計算中に、遅れた販売明細行、BOM 明細行の要件、および他のすべての需要タイプを調べ、それらが安全在庫が使用できるように指定されている時間に期限遵守で配送されるかどうかを見極めるため、新しいロジックが追加されます。 安全在庫の使用により遅延が最小限にできることをシステムが示す場合、販売明細行またはBOM 明細行は、最初の補充を安全在庫に置き換え、代わりにシステムが安全在庫の補充をトリガーします。

計画または品目が延滞計算に対して設定されていない場合、安全在庫制約には他の任意の需要タイプと同じ優先順位があります。 これは、他の需要タイプの前に、手持在庫と他の利用可能な在庫の引当があることを意味します。

有効期限が切れるアイテムの補充計算にも新しいロジックがあります。 任意の時点で、注文明細行または BOM 明細行などの実際の需要を許可するよう、FEFO (先に期限が切れるものから先出し) の順序で履行するよう、最新の有効期限の日付で在庫入庫が安全在庫に対して使用されます。

詳細については、品目に対する安全在庫フルフィルメント を参照してください。

税エンジン (GTE) – インドの販売税のみ

税エンジン (GTE) は、Finance and Operations の構成可能なビジネス アプリケーション エクスペリエンスの重要な部分です。 これにより、高度なカスタマイズが可能になり、ビジネス ユーザー、機能のコンサルタントまたはパワー ユーザーが法的およびビジネスの要件に基づいて税の適用、計算、転記、および決済を決定する税ルールを構成することができます。 税コンフィギュレーションは GTE より柔軟です。 より簡単な拡張機能エクスペリエンスを提供し、AOT 内のデータ プロバイダーにとって拡張機能のシナリオをサポートするためのコード変更がほとんど必要ありません。

詳細情報

仕入先コラボレーション

仕入先コラボレーションが拡張され、仕入先は、連絡先情報、ビジネス識別データ、調達カテゴリ、証明書などの自社情報を表示したり、選択的に管理維持ができるようになりました。

  • 仕入先は、添付ファイルを受信してアップロードする機能を含む RFQ を表示して応答することができます。 共同インターフェイスにより、仕入先は、落札済の入札または失注した入札に関する情報を受け取ることができます。
  • 公的機関の構成で、RFQ をデータ管理からエンティティとして発行してエクスポートできるようになります。 これにより、顧客が主催する公開 Web サイトでデータを使用および公開できます。
  • 新しいワークフローでサポートされているプロセス、仕入先のオンボーディングでは、Dynamics 365 for Financial and Operations に新しい仕入先の追加を容易にできます。 仕入先は、エンティティを介してインポートされたサインアップ要求に基づいて、または Financial and Operations で直接入力された要求に基づいて、登録に招待されます。
  • 登録プロセスでは、仕入先を代表する人物に、制限的なセキュリティ ロールを持つユーザー アカウントをプロビジョニングし、ウィザード ガイド プロセスを完了してユーザーを登録に招待します。 ガイド付き登録プロセスでは、連絡先情報、ビジネス ID データ、調達カテゴリ、アンケート回答などのデータが要求されます。 仕入先の連絡担当者が入力した情報は仕入先要求に入力され、ワークフロー プロセスを介して情報が承認された後、新しい仕入先勘定が登録されます。

倉庫 - フルフィルメント ポリシーが移動オーダーの全体または一部のバッチ リリースに追加された

ウェアハウス バッチ ジョブへのリリースは、受注の機能と同等のフルフィルメント ポリシーにより充実していますが、現在は移動オーダーも含まれています。 フルフィルメント率ポリシーに従って移動オーダーをバッチ リリースすることができます。 このポリシーは、積荷のリリースからと同様に、倉庫への手動リリース フォームの場合にも適用できます。 手動でリリースするときに、行レベルで既定のポリシーを上書きすることもできます。

倉庫 - コンテナ詰めで使用される風袋重量を負荷の総重量に含む

この機能拡張により、コンテナー化に使用されるコンテナーの風袋重量が負荷の総重量に含まれます。 適用される積荷テンプレートとより適切に関連付けるため、積荷ヘッダーの操作性向上もいくらか追加されました。

コンテナーのボリュームは、総ボリューム、残りボリューム、実際のボリュームをキャプチャする機能を含め、より詳細に表示されます。

これらの更新された値は、料金ルート エンジンおよび輸送入札によって消費されます。