Order Management統合のためのSOAPからRESTへの移行

Service Logistics UIおよびAPIは、部品販売、返品、交換およびデポ修理ロジスティクスの販売オーダーと、フィールド・サービスおよびデポ修理請求を作成します。 このリリースでは、サービス・ロジスティクスが受注の作成に使用したOrder Management SOAP APIがOrder Management REST APIに置き換えられました。

これらのREST APIには、ジョブ・ロールに割り当てる必要がある権限があります。 25Cより前は、オーダーの更新REST APIを使用できるように、シード済のフィールド・サービス管理者およびデポ修理マネージャ・ジョブ・ロールにこれらの権限が割り当てられていました。 Restの更新APIは、23Dでリリースされた報告/課金訂正機能に使用されます。 25Cでは、これらの権限もシードされたフィールド・サービス技術者職務ロールに割り当てられました。

  1. 販売オーダー・リクエストの作成(FOM_SALES_ORDER_REQUEST_REST_POST_PRIV)
  2. 販売オーダーの削除(FOM_SALES_ORDER_REST_DELETE_PRIV)
  3. 販売オーダーの取得(FOM_SALES_ORDER_REST_GET_PRIV)
  4. 販売オーダーの更新(FOM_SALES_ORDER_REST_PATCH_PRIV)
  5. 販売オーダーの作成(FOM_SALES_ORDER_REST_POST_PRIV)

カスタム・ジョブ・ロールを使用する場合は、サービス・ロジスティクスのUIおよびAPIから販売オーダーを引き続き作成できるように、これらの権限を割り当てます。

また、実装に適用されるかどうかを確認するために、次の潜在的な問題を考慮する必要があります。

  1. オーダー明細品目定義組織
    OM REST APIは、オーダー明細の作成時に品目定義組織を受け入れません。     そのため、Order Management (OM)デフォルト・ルールを設定して、通常はビジネス・ユニットに基づく品目定義組織を移入する必要があります。 また、品目定義組織にトランザクション組織(報告明細の組織など)を移入するOM拡張がある場合は、かわりにOM履行表(doo_fulfill_lines_all)に履行組織を移入することを検討する必要があります。これは、トランザクション組織としてダウンストリームで使用されるためです。 今後のリリースでは、出荷および返品OM明細に対してすでに実行されているように、請求のみのOM明細を作成するときに、履行組織がサービス・ロジスティクスによって移入される場合があります。
      
  2. 返品オーダー明細の支払条件
    OM REST APIは返品オーダー明細の支払条件を受け入れないため、25Cでは、サービス・ロジスティクスは支払条件を含む返品オーダー明細を作成しません。     返品オーダー明細に支払条件を移入するOM拡張がある場合は、削除する必要があります。 また、25Cの更新前に作成されたオーダーの場合、既存の返品明細から支払条件を削除するOM拡張機能を作成する必要があります。 たとえば、手数料明細や追加部品を追加する場合です。
      
  3. オーダー・ヘッダー出荷先顧客
    OM REST APIでは、コール元プログラムによって渡されない場合、販売先顧客からの出荷先顧客がデフォルト設定されます。     そのため、この販売先/出荷先顧客に対して出荷先住所が有効である必要があります。
    フィールド・サービス料金の場合、サービス・ロジスティクスでは、報告ヘッダー・サービス住所(販売先顧客に関連付けられている)を使用してオーダー・ヘッダー出荷先住所が移入されるため、ここでは顧客に問題は発生しません。
    部品のみおよびデポ修理ロジスティクスの場合、Service LogisticsはOMヘッダーの出荷先顧客または住所を移入しません。     ここでは、これらのフィールド(出荷先顧客/パーティ、住所、出荷先連絡先、出荷先担当者)をNULLに設定したり、有効な値を移入するために、OM拡張を作成する必要があります。 サービス・ロジスティクスAPIを使用して販売オーダーを作成する顧客は、サービス・ロジスティクスAPIが出荷先顧客を入力として受け入れないため、販売先顧客に関連付けられた出荷先住所を渡す必要があります。

  4. 検証ありのREST拡張機能
    OM RESTは現在下書きを作成し、検証ありのOM拡張が送信イベントで失敗した場合に成功応答を返します。     ドラフト・ステータスのこれらのオーダー明細は、別のオーダー変更が処理されると失われる可能性があります。 この動作はSOAPとは異なります。SOAPは前払エラーを返し、オーダー草案を作成しませんでした。 そのため、顧客は、検証を含むOM拡張を「送信時」から「保存時」に移動して、検証が失敗したときにドラフト・オーダー明細が作成されないようにする必要があります。

  5. オーダー顧客関係
    OMには、販売先顧客、出荷先顧客および請求先顧客間の関係を強制する機能が追加されました。     これらの関係は、サービス・ロジスティクスのUIおよびAPIでは適用されません。 そのため、顧客は、サービス・ロジスティクスのUIおよびAPIから販売オーダーを作成するときにこの検証を実行しない場合は、「OM顧客関係タイプ」パラメータを「すべての顧客」に設定する必要があります。

拡張されなくなったSOAP APIではなく、最新のOrder Management REST APIを使用して、サービス・ロジスティクスのUIおよびAPIから販売オーダーを作成できます。

有効化のステップ

サービス・ロジスティクスUIおよびAPIを使用して販売オーダーを作成するジョブ・ロールにREST権限を割り当てます。 OM拡張に必要な変更を行います。

アクセス要件

25Cで受注を作成および更新するには、次の権限を持つジョブ・ロールが必要です。

  1. 販売オーダー・リクエストの作成(FOM_SALES_ORDER_REQUEST_REST_POST_PRIV)
  2. 販売オーダーの削除(FOM_SALES_ORDER_REST_DELETE_PRIV)
  3. 販売オーダーの取得(FOM_SALES_ORDER_REST_GET_PRIV)
  4. 販売オーダーの更新(FOM_SALES_ORDER_REST_PATCH_PRIV)
  5. 販売オーダーの作成(FOM_SALES_ORDER_REST_POST_PRIV)