1. サービス・ロジスティクスとフィールド・サービスの統合
  2. 統合の仕組みの理解
機械翻訳について

統合の仕組みの理解

サービス・ロジスティクスとフィールド・サービスの統合の動作を理解するには、次の各項を参照してください:

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

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

  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 Cloudフローは、オンデマンドまたはスケジュールで実行できるスケジュール済統合です。

  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 Cloudフローは、スケジュールされた統合で、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. Oracle Integration Cloudは、オンデマンドまたはスケジュールで実行できるスケジュール済統合です。

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

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

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

  5. OFSCにダウンロードされる在庫保管ロケーションの詳細は、次のとおりです:

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

    • 在庫事業所名(組織コード+保管ロケーション名)

    • 品目番号

    • 品目摘要

    • 品目改訂

    • シリアル番号

    • 手持数量

    • プライマリ単位

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

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

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

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

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

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

  6. OFSCにダウンロードされる在庫保管ロケーションの詳細は、次のとおりです:

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

    • 在庫事業所名(組織コード+保管ロケーション名)

    • 品目番号

    • 品目摘要

    • 品目改訂

    • シリアル番号

    • 手持数量

    • プライマリ単位

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

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

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

    • 品目番号

    • 品目摘要

    • 品目改訂

    • プライマリ単位

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

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

  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. フィールド・サービス技術者は、「オーダー」ボタンをクリックして、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

フィールド・サービス技術者は、複数の部品番号および部品の複数の数量をオーダーできます。

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

    • そのメンテナンス作業オーダーの処理を停止します。

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

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