1. サービス・ロジスティクスとフィールド・サービスの統合
  2. レシピのアクティブ化および実行
機械翻訳について

レシピのアクティブ化および実行

接続を構成し、前に説明した必要なタスクを完了したら、レシピをアクティブ化して実行できます。

フィールド・サービス統合レシピの動作

フィールド・サービス統合レシピの仕組みを理解するには、この項の説明を確認してください。

ノート:
統合がアクティブ化されていることを確認するには:
  1. プロジェクト・ワークスペースで、「アクティブ化」をクリックします。
  2. 「プロジェクトのアクティブ化」パネルで、デフォルトのプロジェクト・デプロイメントが選択されている状態で、適切なトレース・オプションを選択し、「アクティブ化」をクリックします。
  3. 統合がアクティブ化されたことを示すメッセージが表示されます。 ページをリフレッシュして、インテグレーションの更新済ステータスを表示します。

自動車部品報告(統合名): Oracle Service Logistics OFS自動報告): 作業オーダーで情報が使用可能な場合は、この統合によって部品情報が報告に移入されます。 サービス・ロジスティクスとフィールド・サービスの統合フローは次のとおりです:

  1. フィールド・サービス技術者は、アクティビティを開始する「開始」ボタンをクリックして、Oracle Field Service Cloud (OFSC)で報告プロセスを開始します。
  2. このアクティビティでは、Oracle Service Logistics OFS Auto Debrief統合を開始するイベントが発生します。
  3. 統合プロセスは、アクティビティIDおよび作業オーダー詳細を含むイベント詳細を受け取ります。
  4. 統合プロセスは、OFSC Rest APIをコールして、その報告タスクにすでに追加されている部品を検索します。
  5. 追加済みのパーツがある場合、処理は停止します。
  6. アクティビティの部品が見つからない場合、統合プロセスはCustomerWorkOrders REST APIをコールして、アクティビティに添付されている作業オーダーを検索します。
  7. 統合プロセスは、作業オーダーに対して別のpartRequirementLines Rest APIをコールして、作業オーダーにすでに添付されている部品を検索します。
  8. 作業オーダーにすでに追加されている部品がある場合、次のように報告に追加しようとします:
    1. Oracle Field Service REST API (resources/{resourceId}/inventories)をコールして、リソース・インベントリ内の使用可能な部品を検証します。
    2. 部品がある場合は、Oracle Field Service REST API (resources/{resourceId}/inventories/{inventoryId}/custom-actions/install)をコールして在庫をインストールするために追加されます

カスタム・ルール・プロセッサ(統合名): Oracle Service Logistics OFSカスタム・ルール・プロセッサ): これは、課金ラインの転記にカスタム・ルールを使用する方法を示す統合の例です。 この統合の処理は次のとおりです:

  1. 「課金の課金時にカスタム・ルール処理を有効化」プロファイルが「はい」に設定されている場合、統合は課金の課金時に開始されます。
  2. データに基づいて、統合プロセスはREST API (debriefs/(debriefHeaderId)を呼び出して報告ヘッダー情報を取得します。
  3. この例では、ステップ2の顧客アカウント情報がチェックされ、料金を転記する特定の顧客についてのみチェックされます。 これを行うには、「報告手数料の自動処理」ESSジョブをコールし、手数料明細が「レビュー」としてマークされている場合に使用します。
ノート: これは特定のシナリオです。 さらに複雑なルールを追加して、必要に応じて処理できます。

報告統合(統合名) : Service Logisticsに関する報告) : Field ServiceとService Logisticsの簡単な統合は、次のように行われます:

  1. 技術者がフィールド・サービスでアクティビティを完了すると、この統合をトリガーするイベントが発生します。

  2. フィールド・サービスRESTサービス(activities/{activityId}/installedInventories)は、すべての労務、部品および経費報告明細をフェッチするためにコールされます。

  3. フィールド・サービスRESTサービス(activities/{activityId}/deinstalledInventories)がコールされ、返されるすべての部品がフェッチされます。

  4. サービス・ロジスティクスRESTサービス(debriefs/{debriefHeaderId}/child/lines)は、次のものを作成するためにコールされます:

    • 報告トランザクション

    • 手数料

    • 使用された部品の予約(予約は料金の転記時に解除されます)。

  5. 報告手数料の自動処理ジョブが起動され、定義したルール・セットに基づいて手数料の自動転記が試行されます。

  6. フィールド・サービス管理者は、自動的に転記されない手数料をレビューし、手動で転記する必要があります。

  7. Service Logisticsにアップロードする報告情報には、次のものが含まれます:

    1. 労務報告

      • サービス活動

      • 労務品目

      • 開始時間

      • 終了時間

    2. 資材報告

      • サービス活動

      • 品目番号

      • 数量

      • 単位

    3. 経費報告

      • サービス活動

      • 経費品目

      • 金額

      • 通貨コード

在庫残高ダウンロード (統合名) : サービス・ロジスティクス在庫) : 技術者の在庫事業所の在庫残高は、次のステップを使用してフィールド・サービスにダウンロードされます:

  1. Oracle Integrationフローは、オンデマンドまたはスケジュールで実行できるスケジュール済統合です。

  2. サービス・ロジスティクスRESTサービス(stockingLocations REST API)は、すべての技術者の在庫事業所を取得するためにコールされます。

  3. OFSCアダプタ( Resource.Get Resource)がコールされ、在庫事業所がすでに存在するかどうかが確認されます。

  4. 在庫事業所が存在しない場合は、次のようになります:

    • OFSCアダプタ(Resource.Create Resource)がコールされ、在庫事業所がトラック・リソースとして作成されます。 トラック・リソースは親リソース(プロファイル「デフォルトの親リソース名」)に関連付けられています。

  5. 在庫事業所の在庫残高を取得するために、サービス・ロジスティクスRESTサービス(trunkStocks)がコールされます。

  6. OFSC RESTサービス(resources/custom-actions/bulkUpdateInventories)は、フィールド・サービスの在庫残高を置換するためにコールされます。

  7. OFSCにダウンロードされる在庫事業所の詳細は、次のとおりです:

    • リソースID (トラックID)

    • 在庫事業所名(組織コード+保管場所名)

    • 品目番号

    • 品目摘要

    • 品目改訂

    • シリアル番号

    • 手持数量

    • プライマリ単位

在庫残高増分ダウンロード (統合名) : サービス・ロジスティクス在庫増分) : 技術者の在庫事業所の新規更新済在庫残高は、次のステップを使用してフィールド・サービスにダウンロードされます:

  1. Oracle Integrationフローは、スケジュールされた統合で、1日に複数回実行する必要があります。

  2. サービス・ロジスティクスRESTサービス(stockingLocations REST API)は、すべての技術者の在庫事業所を取得するためにコールされます。

  3. OFSCアダプタ( Resource.Get Resource)がコールされ、在庫事業所がすでに存在するかどうかが確認されます。

  4. 在庫事業所が存在しない場合は、次のようになります:

    • OFSCアダプタ(Resource.Create Resource)がコールされ、在庫事業所がトラック・リソースとして作成されます。 トラック・リソースは親リソース(プロファイル「デフォルトの親リソース名」)に関連付けられています。

  5. インベントリRESTサービス(inventoryCompletedTransactions)がコールされ、現在日に取引されたすべての品目が検索されます。

  6. 品目の在庫残高を取得するために、サービス・ロジスティクスRESTサービス(trunkStocks)がコールされます。

  7. OFSC RESTサービス(resources/custom-actions/bulkUpdateInventories)は、フィールド・サービスで在庫残高を作成または更新するためにコールされます。

  8. OFSCにダウンロードされる在庫事業所の詳細は、次のとおりです:

    • リソースID (トラックID)

    • 在庫事業所名(組織コード+保管場所名)

    • 品目番号

    • 品目摘要

    • 品目改訂

    • シリアル番号

    • 手持数量

    • プライマリ単位

アクティビティの部品のオーダー(統合名) : サービス・ロジスティクス・オーダー部品) : サービス・ロジスティクスとフィールド・サービス間の部品オーダーの統合は、次のように行われます:

  1. フィールド・サービス技術者は、「オーダー」ボタンをクリックして、サービス・ロジスティクスを使用してOFSCから部品をオーダーします。

  2. これにより、OFSCにオーダー・アクティビティが作成されます。

  3. ステップ1では、統合をトリガーするイベントが発生します。

  4. OFSCアダプタ(Activity Inventory)は、技術者がオーダーしたすべての部品を取得するためにコールされます。

  5. OFSCからService Logisticsに渡されるデータ要素は、次のとおりです:

    • 品目番号

    • 数量

    • 単位

    • 出荷先住所タイプ(技術者または顧客)

    • 作業オーダーID (Fusionサービス作業オーダーID)

  6. サービス・ロジスティクスRESTサービス(partRequirementLines)は、部品要件を作成し、供給ソースを見つけるためにコールされます(partRequirementLines/{partsReqLineId}/action/getPreferredSource))。

  7. 供給オーケストレーションRESTサービス(supplyRequests)は、部品を技術者または顧客サイトに出荷するための転送オーダーの作成に使用されます。

  8. 作業オーダーのフィールド・サービス技術者がオーダーした部品は、Oracle Field Service作業オーダーに、エージェントが「Fusionサービス」ページを使用してオーダーしたその他の部品とともに表示されます。

  9. 部品が見つからない場合は、補充ソースのバックオーダーが作成されます。

  10. OFSCに次がダウンロードされます:

    • 転送オーダー番号

    • オーダー・アクティビティのステータス

    • 転送オーダー・ヘッダーID

ノート:

フィールド・サービス技術者は、複数のパーツ番号と複数のパーツ数量をオーダーできます。

部品の受入(統合名): サービス・ロジスティクス受入部品): この統合により、フィールド・サービス技術者による部品の受入プロセスが完了します。 サービス・ロジスティクスとフィールド・サービスの統合は、次のように行われます:

  1. フィールド・サービス技術者は、受入済品目数量を提供し、「受領」ボタンをクリックして受入プロセスを開始します。

    アプリケーションは、次の処理を実行します。

    • Oracle Field Serviceにアクティビティを作成します。
    • サービス・ロジスティクス部品の受入統合をトリガーするイベントを生成します。

  2. 統合プロセスでは、Oracle Field Serviceアダプタ(アクティビティ)を使用して、Oracle Field Service Cloudからアクティビティ詳細を取得します。

  3. アプリケーションによってInventory Management RESTサービス(linesToReceive)がコールされ、アクティビティ詳細情報(部品品目番号および転送オーダー・ヘッダーID)を使用して受入可能な予想出荷明細が取得されます。

  4. 有効な出荷明細が見つかった場合は、別のInventory Management RESTサービス(receivingTransaction)がコールされ、受入転送オーダーが作成されます。 アプリケーションは、この転送オーダー・トランザクションの作成時に次のパラメータを渡します:

    • Oracle Field Serviceアクティビティ詳細の数量および単位コード。
    • 品目番号、出荷ヘッダーID、出荷明細ID。
    • 宛先タイプ・コードのデフォルトはINVENTORY、ソース文書コードはTRANSFER ORDER、トランザクション・タイプはRECEIPTです。

ランク在庫を補充する部品のオーダー(統合名) : サービス・ロジスティクス補充部品) : サービス・ロジスティクスとフィールド・サービス間の部品オーダーの統合は、次のように行われます:

  1. フィールド・サービス技術者は、「オーダー」ボタンをクリックして、OFSCから部品をオーダーし、ランク在庫を補充します。

  2. これにより、OFSCにオーダー・アクティビティが作成されます。

  3. ステップ1では、統合をトリガーするイベントが発生します。

  4. OFSCアダプタ(Activity Inventory)は、技術者がオーダーしたすべての部品を取得するためにコールされます。

  5. OFSCからService Logisticsに渡されるデータ要素は、次のとおりです:

    • 品目番号

    • 数量

    • 単位

    • 出荷先住所タイプ(技術者または顧客)

    • 作業オーダーID (Fusionサービス作業オーダーID)

  6. サービス・ロジスティクスRESTサービス(partRequirementLines)は、部品要件を作成し、供給ソース(partRequirementLines/{partsReqLineId}/action/getPreferredSource)を見つけるためにコールされます。

  7. 供給オーケストレーションRESTサービス(supplyRequests)は、部品を技術者または顧客サイトに出荷するための転送オーダーの作成に使用されます。

  8. 部品が見つからない場合は、補充ソースのバックオーダーが作成されます。

  9. OFSCに次がダウンロードされます:

    • 転送オーダー番号

    • オーダー・アクティビティのステータス

    • 転送オーダー・ヘッダーID

ノート:

フィールド・サービス技術者は、複数のパーツ番号と複数のパーツ数量をオーダーできます。

部品品目番号ダウンロード(統合名): サービス・ロジスティクス部品カタログ): フィールド・サービス技術者には、交換部品をオーダーするための部品品目番号が必要です。 部品品目番号は、次のプロセスを使用してダウンロードされます:

  1. バッチ・プログラムは、Oracle Integrationを使用して、Oracle Product Information CloudからField Serviceに品目をロードします。 バッチ・プログラムはOIC統合プログラムで、オンデマンドで実行することも、OICから実行するようにスケジュールすることもできます。

  2. この統合では、プロファイル・デフォルト在庫組織で定義された在庫組織のすべての品目がダウンロードされます。 サービス・ロジスティクス請求タイプが請求カテゴリ=資材に関連付けられている品目のみが含まれます。 ダウンロードされる品目詳細は次のとおりです:

    • 品目番号

    • 品目摘要

    • 品目改訂

    • プライマリ単位

    ノート:

    Product Information Managementの品目マスターの労務品目および費用品目と一致するように、OFSCで労務品目および費用品目を設定する必要があります。 詳細は第4章 を参照してください。

予防保守(統合名): サービス・ロジスティクス予防保守: これは、予防保守作業オーダーを生成するためのスケジュール済統合です。

  1. Oracle Integration Serviceロジスティクス予防保守を日次または週次ベースで実行するようにスケジュールします。

  2. この統合では、次の5つのパラメータを使用できます:

    • MaintenanceOrganizationCode: 予防作業を実行する保守組織の短縮名。

    • カテゴリ: サービス・リクエストのカテゴリ。

    • WorkOrderIntegrationCd: Oracle Field Service Cloud (OFSC)作業オーダーの作成にはORA_WO_INT_OFSCを使用し、汎用作業オーダーの作成にはORA_WO_INT_SVCを使用します。

    • WorkOrderStatusCode: 作業オーダーの作成に使用される初期ステータス・コードです。

    • WorkOrderTypeCd: 作業オーダーの作成に使用される作業オーダー・タイプ・コードです。

  3. この統合は、デフォルトのタイム・ゾーンの設定から始まり、顧客のタイム・ゾーンに基づいて変更できます。

  4. 入力として渡された組織コードおよび作業オーダー・タイプ・コードに基づいて、アプリケーションによって、プロセスに渡される対応する識別子が取得されます。

  5. アプリケーションが保守RESTサービス(MaintenanceWorkOrders)をコールして、将来の計画開始日を持つすべてのリリース済顧客アセット・ベースの作業オーダーを取得します。

  6. 前のプロセスで返された保守作業オーダーごとに、アプリケーションによって次の処理が実行されます:

    • 保守RESTサービス(DocumentReference)をコールして、タイプORA_SERVICE_REQUESTのドキュメント参照を現在の保守作業オーダーと照合します。 参照データがある場合、処理はスキップされます。

    • 参照データがない場合は、SCM RESTサービス(installBaseAssets)をコールして現在のアセット詳細情報が取得されます。

    • アセット詳細にアセット事業所がない場合、処理はスキップされます。 それ以外の場合は、アセットの現在の事業所IDのHCM SOAP API (LocationService)がコールされ、事業所詳細が取得されます。

    • アプリケーションによってSCM RESTサービス(WorkDefinition)がコールされ、保守作業オーダー作業定義IDに基づいて作業定義詳細が取得されます。 次に、アプリケーションは、資産の担当者詳細についてCRM RESTサービス(担当者)を呼び出します。

    • OFSC作業オーダーの作成(前に設定したパラメータに基づく)の場合、アプリケーションはCRM RESTサービス(svcWOAreas)をコールして作業領域を取得します。 デフォルトでは、国と郵便番号がこの残りのサービスに渡されますが、設定に基づいてより多くのパラメータを指定できます。

    • OFSC作業指示作成用: 作業領域取得処理中にエラーが発生した場合、現在の保守作業オーダーの処理は停止します。

    • サービス・リクエスト・カテゴリに基づいて、アプリケーションはCRM RESTサービス(カテゴリ)をコールしてカテゴリIDを取得し、資産の顧客番号と顧客サイト番号を使用して別のCRM RESTサービスをコールして、資産住所を取得します。

    • 次のパラメータを使用してCRM RESTサービス(ServiceRequests)をコールして、サービス・リクエストを作成します:

      • タイトル: 作業定義名。

      • 問題の説明: 作業定義名摘要。

      • アカウント・パーティID: アセット顧客ID。

      • プライマリ担当者パーティID: アセット担当者に基づく担当者詳細のパーティID。

      • 在庫品目ID: アセット品目。

      • IBアセットID: アセットID。

      • カテゴリID: スケジュール・パラメータとして渡されたサービス・カテゴリ名に基づいて取得されたID。

    • 次のパラメータを使用してCRM RESTサービス(CustomerWorkOrders)をコールして、作業オーダーを作成します:

      • タイトル: 作業定義名。

      • SId: サービス・リクエストID。

      • アカウント・パーティID: アセット顧客ID。

      • 担当者パーティID: アセット担当者に基づく担当者詳細のパーティID。

      • IBアセットID: アセットID。

      • WO統合コード、作業オーダー・ステータス・コード: 対応する入力パラメータから。

      • WOタイプID: 作業オーダーtypeCdとして指定された入力に基づいて、処理の開始時に取得されます。

      • 作業エリア: OFSC作業オーダーの場合、前述のように取得されます。

      • 解決期日: 保守作業オーダーからの計画完了日です。

      • 担当者名、担当者電子メール、担当者電話: 前述のように、アセットの連絡先IDに基づいて取得された連絡先詳細。

      • 住所コンポーネント: 前述のとおり、SOAP APIをコールして取得された住所詳細。

      • タイムゾーン・コード: 統合で設定されたデフォルト・タイムゾーンの値。

    • 現在の保守作業オーダーの場合、アプリケーションは別のSCM RESTサービス(maintenanceWorkOrder)をコールして、作業オーダーに必要な保守操作を検索します。 これらの操作ごとに、次の操作を実行します:

      • 現在の保守作業オーダーの場合、SCM RESTサービス(maintenanceWorkOrders/{WorkOrderId}/child/WorkOrderOperation/{WoOperationId}/child/WorkOrderOperationMaterial)をコールして、作業オーダーが保守操作を実行するために必要な資材を検索します。

    • 各資材について、次の属性マッピングに基づいて部品要件明細を作成します:

      • 搬送先組織ID: 操作の組織ID。

      • 希望入手日: 工程の計画開始日。

      • 親エンティティID: この統合処理中に作成された作業オーダーID。

      • 在庫品目ID、数量、単位コード: 工程資材の定義。

      • 出荷先住所タイプ: デフォルトはCUSTOMERです。

      • 出荷先パーティID: サービス・リクエスト・アカウント・パーティID。

    • アプリケーションは、次のパラメータに基づいて参照データを記録するために、保守RESTサービス(maintenanceWorkOrders/{WorkOrderId}/child/documentReference)をコールします:

      • ソース・システムのタイプ・コード: デフォルトはORA_INTERNALです。

      • 作業オーダーID: 統合が現在処理している保守作業オーダーID。

      • 文書タイプ: デフォルトはORA_SERVICE_REQUESTです。

      • 文書ヘッダーID: 処理中に作成されるサービス・リクエストID。

  7. エラー処理: このスケジュール済統合では、サービス・リクエスト、作業オーダーおよび部品要件明細が作成されます。 また、様々な属性も検証します。 処理中に障害が発生した場合、アプリケーションは次の処理を実行します:

    • その保守作業オーダーの処理を停止します。

    • メッセージをログに記録します。

    • サービス・リクエスト、作業オーダーまたは部品要件明細など、処理中に作成されたすべてのデータを削除します。

技術者ダウンロード(統合名) : サービス・ロジスティクス技術者) : 「サービス・ロジスティクス」フィールド・サービス技術者は、次のステップに従ってフィールド・サービスにダウンロードされます:

  1. Oracle Integrationフローは、オンデマンドまたはスケジュールで実行できるスケジュール済統合です。

  2. SOAPサービス(PersonService.findPerson)は、すべてのフィールド・サービス技術者のリストを取得するためにコールされます。

  3. 技術者リソースがすでに存在する場合は、そのリソースを更新するためにOFSCアダプタ(resources.Update Resource)がコールされます。

  4. リソースが存在しない場合:

    • プロファイル「デフォルトの親リソース名」からリソースの親ノードを取得するために、共通RESTサービス(profileValues)がコールされます。

    • リソースを作成するためにOFSCアダプタ(Resource.Create Resource)がコールされます。 作成されるフィールド・サービス技術者リソースには、プロファイルに定義されている親リソースが割り当てられます。

  5. OFSCにダウンロードされる技術者詳細は次のとおりです:

    • 親リソース

    • 個人パーティID

    • Full Name

    • Email

    • 携帯電話番号

    • Status(active/inactive)

ノート: 次を実行できます:

  • トラック・リソースに在庫を格納するための在庫残高統合。

  • 技術者リソースに在庫を直接格納するための技術者在庫残高統合。

技術者在庫残高ダウンロード(統合名) : サービス・ロジスティクス技術者在庫) : 技術者のデフォルトの使用可能な保管場所の在庫残高は、次のステップを使用してフィールド・サービスにダウンロードされます:

  1. Oracle Integrationは、オンデマンドまたはスケジュールで実行できるスケジュール済統合です。

  2. サービス・ロジスティクスRESTサービス(stockingLocations REST API)は、すべての技術者のデフォルトの使用可能な在庫事業所を取得するためにコールされます。

  3. 在庫事業所の在庫残高を取得するために、サービス・ロジスティクスRESTサービス(trunkStocks)がコールされます。

  4. OFSC RESTサービス(resources/custom-actions/bulkUpdateInventories)は、フィールド・サービスの在庫残高を置換するためにコールされます。

  5. OFSCにダウンロードされる在庫事業所の詳細は、次のとおりです:

    • リソースID (技術者パーティID)

    • 在庫事業所名(組織コード+保管場所名)

    • 品目番号

    • 品目摘要

    • 品目改訂

    • シリアル番号

    • 手持数量

    • プライマリ単位

技術者在庫残高増分ダウンロード(統合名) : サービス・ロジスティクス技術者在庫増分) : 技術者のデフォルトの使用可能な在庫事業所の新規更新済在庫残高は、次のステップを使用してフィールド・サービスにダウンロードされます:

  1. Oracle Integrationは、スケジュールされた統合で、1日および毎日複数回実行する必要があります。

  2. サービス・ロジスティクスRESTサービス(stockingLocations REST API)は、すべての技術者のデフォルトの使用可能な在庫事業所を取得するためにコールされます。

  3. インベントリRESTサービス(inventoryCompletedTransactions)がコールされ、現在日に取引されたすべての品目が検索されます。

  4. 品目の在庫残高を取得するために、サービス・ロジスティクスRESTサービス(trunkStocks)がコールされます。

  5. OFSC RESTサービス(resources/custom-actions/bulkUpdateInventories)は、フィールド・サービスの在庫残高を更新するためにコールされます。

  6. OFSCにダウンロードされる在庫事業所の詳細は、次のとおりです:

    • リソースID (技術者パーティID)

    • 在庫事業所名(組織コード+保管場所名)

    • 品目番号

    • 品目摘要

    • 品目改訂

    • シリアル番号

    • 手持数量

    • プライマリ単位

購買オーダーおよび転送オーダー処理(統合名): Oracle Service Logistics OFSオーダー・ステータス)

フィールド・サービス技術者は、品目タイプ設定に基づいて転送オーダーまたは購買オーダーに変換される部品をオーダーします。 Fusionアプリケーションからの購買オーダーおよび転送オーダーの追跡に使用するステップは、この統合によって実行され、受領の準備が整います:

  1. これはスケジュールされた統合で、ニーズに応じてオンデマンドまたはスケジュールで実行する必要があります。 「購買オーダーの自動受入」パラメータを使用します。 デフォルトでは、このパラメータは「いいえ」に設定されています。 パラメータが「はい」に設定されている場合、事前出荷通知(ASN)情報が使用可能な購買オーダーの品目を受け取ります。
  2. フィールド・サービス技術者ごとに、すべてのオープン・アクティビティおよび関連するオーダー部品を検索し、一度に1つずつ処理を開始します(フィールド・サービスRESTアクティビティをコールします)。
  3. 各アクティビティについて、転送オーダーが存在するかどうかを検索し、対応するオーダー詳細を検索して、オーダーのタイプおよび現在のオーダー・ステータスに関する情報を収集します(SCM REST transferOrdersをコールします)。
  4. アクティビティに対して転送オーダーが作成され、オーダーが在庫からすでに履行されて出荷されている場合、フィールド・サービスのオーダーが「受入準備完了」に更新されます(フィールド・サービスRESTプラグインUpdateInventoryをコールします)。
  5. 転送オーダーがアクティビティに対して作成されていない場合は、対応する購買オーダーがチェックされます(REST API PurchaseRequsitionsをコールします)。
  6. 購買オーダーが作成された場合(前のAPIによって返された場合)、オーダーに添付された関連するASN情報がチェックされます。 パラメータに設定された値に基づいてASNがある場合(ステップ1を参照)、自動受信が実行されるか、または品目が受入準備完了(ステップ4と同様)としてマークされます。
  7. 自動受信を許可するように設定を行うと、受信(REST API receivingReceiptRequestsをコール)が実行され、フィールド・サービスのステータスが「受信済」として更新されます。 このシナリオでは、フィールド・サービス技術者が受入操作を実行する必要はありません。
  8. 「購買オーダーの自動受入」パラメータが「いいえ」に設定されており、購買オーダーがASNの有無にかかわらず作成されている場合は、同じ方法で処理されます。 転送オーダーの処理と同様に、オーダー・ステータスが「受入準備完了」に更新されます。 フィールド・サービス技術者は、それを最終ステップとして受け取ります。