更新22A

改訂履歴

本書は、既存の項の変更と、新規情報の追加に伴って、今後も引き続き更新されます。これまでの更新内容は次の表のとおりです。

日付	製品	機能	ノート
2021年12月20日			初版作成。

概要

アイデアをお寄せください

ご意見をお待ちしています。クラウド・サービスをさらに改善する方法について提案がございましたらどうぞお教えください。アイデアを送信するにはいくつかの方法があります。たとえば、Oracle Customer ConnectのIdeas Labを使用します。機能名の後にこのアイコンが表示されている箇所は、お客様のアイデアを実現した機能です。

フィードバックをお寄せください

本書の内容改善のため、ご意見やご提案をお待ちしております。フィードバックは、oracle_fusion_applications_help_ww_grp@oracle.comまでお送りください。

免責事項

この文書に記載された情報には、オラクルの製品開発プランに関する説明文が含まれていることがあります。オラクルの製品開発プランと、今後の製品リリースの本質および時期に対し、様々な要因が大きく影響を及ぼします。したがって、この情報はあくまで情報として提供されるものであり、マテリアルやコード、機能を提供することのコミットメント(確約)ではないため、購買決定を行う際の判断材料になさらないでください。記載されている機能の開発、リリースおよび時期については、オラクルの単独の裁量により決定されます。

この情報は、オラクルおよびその子会社や関連会社との契約を構成するものではありません。特にこの情報についてオラクルは一切の責任を負いかねます。詳細は、法律上の注意点および使用条件を参照してください。

更新前および更新後のタスク

クラウド・アプリケーションで使用している機能によっては、四半期更新の直前または直後に特定のステップを実行する必要がある場合があります。これらの更新前および更新後のステップおよび影響を受ける製品領域の詳細は、My Oracle SupportでOracle SCM Cloud: Performing Your Quarterly Update (文書ID 2337485.1)を参照してください。

任意の新機能の導入(オプトイン)

Oracle Cloudアプリケーションは、四半期ごとに新しい更新を配信します。つまり、ビジネスの効率的かつ効果的な管理に役立つ新しい機能を3か月ごとに受け取ります。一部の機能は使用可能な状態でされ、エンド・ユーザーが即時に使用できます。その他の機能はすぐ使用できない状態で提供され、使用可能にするために処理を実行する必要があります。無効化の状態で提供されている機能は、次のステップでエンド・ユーザーに対してアクティブ化できます。これを行うには、次の権限を使用します。

• アプリケーション・オファリングのレビュー(ASM_REVIEW_APPLICATIONS_OFFERINGS_PRIV)
• Oracle Fusion Applicationsオファリングの構成(ASM_CONFIGURE_OFFERING_PRIV)

新機能をオプトインする方法を次に示します。

1. 「ナビゲータ」→「自分の企業」→「新機能」をクリックします。
2. 機能の概要のページで、オファリングを選択し、それに固有の新機能をレビューします。または、デフォルトの選択である「すべての使用可能オファリング」をそのまま使用して、すべてのオファリングの新機能を確認できます。
3. 「新機能」タブで、新機能を確認し、「使用可能」列で機能のオプトイン・ステータスを確認します。機能がすでに有効化されている場合は、チェック・マークが表示されます。それ以外の場合は、機能を使用可能にするアイコンが表示されます。
4. 「使用可能」列にあるアイコンをクリックし、機能を使用可能にするステップを完了します。

「新機能」作業領域に表示されない機能をオプトインすることもできます。オプト・インする方法を次に示します。

1. 「ナビゲータ」→「自分の企業」→「オファリング」をクリックします。
2. 「オファリング」ページで、オファリングを選択し、「オプト・イン」機能をクリックします。
3. 「オプトイン」ページで、オファリングまたは機能が含まれている機能領域の「機能の編集」(鉛筆)アイコンをクリックします。
4. 「機能の編集」ページで、機能を使用可能にするためのステップを完了します。

オファリングの新機能をオプトインする方法の詳細および詳細な手順は、オファリングの構成を参照してください。

オプト・イン失効

オプト・インを経由してすぐ使用できない状態で提供された機能は、将来の更新で自動有効化される場合があります。これはオプト・イン失効と呼ばれます。クラウド・サービスにオプト・イン失効がある場合、このドキュメントに関連タブが表示されます。このタブをクリックすると、最初に機能が無効状態で提供されたのはいつか、そしてこの機能のオプト・インがいつ失効し、自動で使用可能となる見込みかが表示されます。ここをクリックして、すべてのOracle Cloudアプリケーションのオプト・インが失効した機能を確認することもできます。

機能概要

保守

保守

実行中に作業オーダー工程の再順序付け

この更新の前は、作業オーダーで定義された事前設定の順序で保守工程を実行する必要がありました。実際には、工程上の制約を克服し、資産を最短で稼働させるために、順序を外れて保守工程を実行することが必要になる場合があります。

この更新により、作業オーダーで定義された順序とは異なる順序で特定の工程を実行できます。工程10、20、30、40および50の順序の作業オーダーについて考えてみます。ここで、技術者には工程20の前に工程30を完了するオプションがあります。

工程が再順序付け可能工程として定義されている場合のみ、工程完了の順序を変更できます。

この機能では、次のことを実行できます。

• 再順序付け可能工程のある作業定義の作成および編集
• 再順序付け可能工程のある作業オーダーの作成および編集
• 再順序付け可能工程の実行
• 再順序付け可能工程のある作業オーダーのスケジュール
• 再順序付け可能工程のある作業オーダーの原価計算

これらの各機能は、適切なRESTサービスによってモデル化およびサポートされます。このサービス指向構造は、この機能全体で利用されます。

再順序付け可能工程のある作業定義の作成および編集

「原価計上ポイント」チェック・ボックスと「自動処理」チェック・ボックスに加えて、工程用の新しい「再順序付けの許可」チェック・ボックスがあります。後で工程を再順序付けできるようにするには、「再順序付けの許可」チェック・ボックスを選択します。再順序付け可能工程として有効にできるのは、原価計上ポイント工程のみです。

常に、作業オーダーの最初の工程と最後の工程を原価計上ポイントのみの工程として指定する必要があります。

「保守作業定義の作成」UI

工程を再順序付け可能として設定するビジネス・ルールをいくつか次に示します。

• 2つの原価計上ポイント工程の間にあれば、任意の数の再順序付け工程を定義できます。
• サプライヤ工程は、再順序付け可能工程として識別できません。
• 2つの再順序付け可能工程の間に、自動処理またはオプション工程は追加できません。

この例では、作業定義に工程10、20、30、40および50があり、工程20、30および40のみが再順序付け可能工程として識別可能です。つまり、工程10を最初に実行し、工程20、30および40を任意の順序で実行できます。工程50を完了できるのは、工程40までの前の工程をすべて完了した後のみです。

再順序付け可能工程のある作業オーダーの作成および編集

再順序付け可能工程がある作業定義を使用して作業オーダーを作成すると、「再順序付けの許可」チェック・ボックスが選択された状態で工程が作業オーダーに渡されます。ただし、作業オーダーでは、作業オーダーがリリースされるまで、新しい再順序付け可能工程を追加したり、工程の「再順序付けの許可」チェック・ボックスを更新できます。

作業オーダーがリリースされると、すべての工程が新しい実行順序で配置され、昇順の数値が各工程に自動的に割り当てられます。実行順序の値は、定義された順序から工程が完了すると自動的に更新されます。

作業オーダーの編集: 「工程」タブ

実行順序が作業オーダー工程に割り当てられると、作業オーダーのスケジューリングは工程の実行順序に基づいて取得されます。これは、作業オーダー工程日、資材所要日およびリソース日付が実行順序に基づいて取得されることを意味します。

再順序付け可能工程の実行

原価計上ポイント工程の後に一連の再順序付け可能工程が続く場合、原価計上ポイント工程が完了すると、作業手配リスト内のすべての再順序付け可能工程を表示できます。これにより、再順序付け可能工程を任意の順序で完了できます。再順序付け可能工程は、作業手配リストのビジュアル・インジケータで識別されます。

再順序付け可能アイコンをクリックして工程完了の順序を変更すると、実行順序が自動的に更新されます。同時に、作業オーダー工程は改訂された実行順序に基づいて自動的に再スケジュールされます。

保守作業手配リストのレビュー: 再順序付け処理

特定の順序で工程が完了すると、実行順序は実績完了の順序に設定されます。その後、工程のオーダー実行順序に基づいて工程完了を戻し処理できます。

資材トランザクションのプッシュ、手動のリソース・トランザクション、資材のピッキング、および工程の資材予約を実行しても、実行順序は変更されません。通常どおり、クイック完了、詳細完了、品質検査の入力など、再順序付け可能工程に対するすべての処理を実行できます。

作業手配リストに表示されているすべての再順序付け可能工程を完了すると、直後の原価計上ポイント工程が表示され、完了できます。

再順序付け可能工程のある作業オーダーのスケジュール

生産スケジューリングは、再順序付け可能工程を持つリリース済作業オーダーの実行連番に準拠します。他のすべての作業オーダーは、工程連番に基づいてスケジュールされます。

再順序付け可能工程のある作業オーダーの原価計算

保守作業オーダー原価計算は、工程完了の順序の変更による影響を受けません。ただし、「保守作業オーダー原価」UIには実行順序も表示されるようになりました。

実行順序が表示された「保守作業オーダー原価」ページ

ファイルベース・データ・インポート(FBDI)の変更:

FBDIを使用して再順序付け可能工程を定義できます。「再順序付けの許可」列が、作業定義のインポートおよび作業オーダーのインポートのスプレッドシートに追加されます。22Aにアップグレードした後、最新のテンプレートを使用してください。

「工程トランザクション」スプレッドシートを使用して工程を再順序付けすることはできません。

REST APIの変更:

RESTサービスを使用して、再順序付け可能工程を定義できます。作業定義、作業オーダーのサービスに対して、ResequenceFlag属性が工程レベルで導入されました。作業オーダー・サービスの一部である構成済処理ResequenceAsNextOperationを使用して、次の工程を再順序付けして実行できます。生産スケジューリングのRESTサービスでは、実行順序をオプション・パラメータとして指定できます。

実行中に作業オーダー工程を再順序付けすると、製造現場の緊急事態を克服し、資産を最短で稼働させることで、保守アクティビティを続行できます。

有効化のステップ

この機能を有効にするには、オプト・インUIを使用します。手順は、この文書の「新機能のオプションの取込み」の項を参照してください。

オファリング: 製造およびサプライ・チェーン資材管理 オプションではなくなった開始バージョン: 更新22D

ロール情報

• 次の事前定義済ジョブ・ロールのいずれかが割り当てられているユーザーは、自動的にこの機能にアクセスできます。
  • 保守マネージャ(ORA_MNT_MAINTENANCE_MANAGER_JOB)
  • 保守技術者(ORA_MNT_MAINTENANCE_TECHNICIAN_JOB)

RESTサービスを使用した保守の統合および拡張

REST APIを使用した資産グループ詳細のフェッチ

REST APIを使用して資産の資産グループ詳細をフェッチします。レスポンスには、標準フィールドだけでなく、アプリケーション・コンポーザを使用して定義するフィールドも含まれるようになりました。レスポンス詳細は、サードパーティ・アプリケーションで使用できます。また、資産グループREST APIを使用して、標準フィールドとユーザー定義フィールドを編集できます。

資産グループ・オブジェクトは、アプリケーション・コンポーザを使用して拡張されます。これにより、アプリケーション・ページおよび資産グループREST APIで使用する独自のフィールドを作成できます。

まず、テスト環境でアプリケーション・コンポーザに対して有効なサンドボックスを作成して入力します。次に、アプリケーション・コンポーザに移動し、「アプリケーション」フィールドでERPおよびSCM Cloudを選択し、標準オブジェクトとして「資産グループ」を選択します。

「資産グループ」標準オブジェクト

定義できるフィールドのタイプを次に示します。

フィールドのタイプ

次に、「資産グループの作成」および「資産グループの編集」ページにフィールドを追加できます。これらのフィールドを編集および追加するには、ページを複製する必要があります。

ページへのフィールドの追加

その後、サンドボックス内のアプリケーション・ページでページとフィールドを検証できます。検証されると、サンドボックスを公開できます。

新規フィールドの検証

最後に、サンドボックスが公開されると、新しく定義されたフィールドが資産グループREST APIで使用可能になります。

REST GETレスポンス

REST APIを使用して資産グループ詳細を取得すると、サードパーティ・アプリケーションでこれらの詳細を統合できます。また、資産グループの拡張性により、独自のフィールドを柔軟に使用して、資産グループ定義をさらに定義および管理できます。

有効化のステップ

アプリケーション・コンポーザを利用してページ・レイアウトおよび属性を表示/調整します。アプリケーション・コンポーザの使用によるアプリケーションの拡張の詳細は、Oracle Help Center→関心のあるアプリケーション・サービス領域→「Books」→「Configuration and Extension」を参照してください。

ヒントと考慮事項

• 独自のフィールドの定義には、「資産グループの作成」ページと「資産グループの編集」ページの両方にそれらを追加することが含まれます。

• また、アプリケーション・コンポーザで作成したフィールドを表示および操作するには、ユーザーにカスタム・オブジェクト管理(ORA_CRM_EXTN_ROLE)ロールが必要です。詳細は、保守の使用ガイドおよび製造およびサプライ・チェーン資材管理の実装ガイドの保守の章を参照してください。

ロール情報

• 事前定義済ジョブ・ロール名およびコード:
  • 実装コンサルタント(ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB)
  • 資産管理者(ORA_CSE_ASSET_ADMINISTRATOR_JOB)
  • 保守マネージャ(ORA_MNT_MAINTENANCE_MANAGER_JOB)

• 権限:
  • カスタム・オブジェクト管理(ORA_CRM_EXTN_ROLE)
  • 顧客資産の管理(CSI_MANAGE_CUSTOMER_ASSETS_PRIV)
  • 保守可能資産の管理(MNT_MANAGE_MAINTAINABLE_ASSETS_PRIV)
  • 保守作業オーダーの管理(MNT_MANAGE_MAINTENANCE_WORK_ORDER_HEADERS_PRIV)
  • 保守作業オーダー工程の管理(MNT_MANAGE_MAINTENANCE_WORK_ORDER_OPERATIONS_PRIV)

REST APIを使用した資産失敗の追跡

資産失敗、原因および解決の特定と取得を標準化することで、組織は、資産の信頼性と可用性に加え、保守の有効性や効率性を測定および分析できます。失敗のデータは、資産固有の保守戦略を決定し、保守プログラムを最適化し、根本原因分析、失敗モードと結果分析、確率プロット、統計モデリングなどの信頼性ツールをサポートするために必要な基盤を提供します。機械学習の予測と推奨事項からインサイトを得るには、失敗の履歴データが必要です。

多くの新しいREST APIが、資産失敗の追跡と分析に堅牢なサポートを提供します。これには次が含まれます。

• 資産失敗イベント
• 失敗インスタンス
• 失敗の根本原因(失敗インスタンスの子リソース)
• 資産診断の症状
• 保守の推奨事項
• 資産失敗セット
• 条件イベント・コード

このAPIのセットは、失敗追跡、履歴および分析用のユーザー・モジュールを開発するための基盤を提供します。

失敗イベントは、資産が適切に機能していない特定の期間、およびその機能的失敗によって資産のダウンタイムが発生するかどうかを表します。失敗インスタンスは、失敗、原因、解決および失敗部品の特定の組合せを表します。1つの失敗イベントに複数の失敗インスタンスがある場合があります。たとえば、複数の部品が失敗した場合などです。失敗イベントに1つ以上の根本原因がある場合もあります。これらは不適切な設計、不適切なプロセス、不十分なトレーニングなど、失敗の直接的かつ観察可能な原因につながる要素を表します。

症状は、異常な資産動作に関連する観察または診断情報であり、失敗イベントに先行して発生または同時発生する可能性があります。症状は多くの場合、資産のエンドユーザーやIoT対応資産によって報告され、検査が行われますが、失敗レコードになる場合とそうでない場合があります。ただし、症状情報は、類似の失敗を伴う、将来の失敗を予測するために重要です。推奨事項は、特定の失敗の最も考えられる原因、失敗に対する最善の修正、失敗の原因となった可能性が最も高い失敗部品について、コンテキスト固有のガイダンスをユーザーに提供します。これらの推奨事項は、一般に、過去の失敗イベント、失敗インスタンス、症状およびその他のデータの機械学習分析から得られます。

失敗セットでは、失敗データの取得方法、および技術者に作業オーダーの失敗データを取得することを求める条件について、ルールを定義します。条件イベント・コードは、失敗コード、原因コード、解決コード、診断コードなどの標準化されたコーディフィケーションを提供します。条件イベント・コードおよびそれらを管理するページは以前に存在していましたが、現在、企業はREST APIを使用してコードを設定できます。

このAPIのセットでは、保守技術者、管理者、信頼性エンジニア、またはIoT対応資産による失敗データの入力、編集、レビューまたは分析が求められるフローがサポートされます。

失敗の追跡と分析は、資産の信頼性の向上、計画外のダウンタイムの削減、保守原価の削減に不可欠です。

有効化のステップ

REST APIガイドのRESTサービス定義(「Oracle Help Center」→関心のあるアプリケーション・サービス領域 →「REST API」から使用可能)を参照してください。OracleのRESTサービスを初めて利用する場合は、「クイック・スタート」セクションから始めることができます。

この機能を有効にするために何もする必要はありません。

ヒントと考慮事項

利用するREST APIガイドでRESTサービス定義を確認します(Oracle Help Center→「Maintenance」→「APIs and Schema」から利用できます)。OracleのRESTサービスを初めて利用する場合は、クイック・スタート・セクションから始めることができます。

主なリソース

Oracle Supply Chain Management Cloud REST APIドキュメントを参照してください(Oracle Help Centerからアクセスできます)。

ロール情報

• 権限名およびコード:        
  • 条件イベント・コードの管理(MNT_MANAGE_FAILURE_CONDITION_EVENT_CODE_BY_SERVICE)
  • 条件イベント・コードの取得(MNT_GET_FAILURE_CONDITION_EVENT_CODE_BY_SERVICE)
  • 失敗セットの管理(MNT_MANAGE_FAILURE_SET_BY_SERVICE)
  • 失敗セットの取得(MNT_GET_FAILURE_SET_BY_SERVICE)
  • 失敗イベントの管理(MNT_MANAGE_FAILURE_EVENT_BY_SERVICE)
  • 失敗イベントの取得(MNT_GET_FAILURE_EVENT_BY_SERVICE)
  • 失敗イベント・インスタンスの取得(MNT_GET_FAILURE_EVENT_INSTANCE_BY_SERVICE)
  • 症状の管理(MNT_MANAGE_FAILURE_SYMPTOM_BY_SERVICE)
  • 症状の取得(MNT_GET_FAILURE_SET_SYMPTOM_BY_SERVICE)

• ジョブ・ロール名およびコード:       
  • 保守管理Webサービス職務

REST APIを使用した導入ベース資産と固定資産の関係の管理

RESTサービスを使用して、導入ベース資産と固定資産間の関係を作成します。

この更新で実行できる処理は次のとおりです。

• 導入ベース資産と固定資産間の関係の作成
• 導入ベース資産と固定資産の関係の更新
• 導入ベース資産と固定資産の関係の詳細の取得

fixedAssetAssociations RESTリソース(既存のInstalledBaseAssetsリソースの子)を使用します。

導入ベースREST APIを使用して資産の詳細を簡単に管理します。

有効化のステップ

REST APIガイドのRESTサービス定義(「Oracle Help Center」→関心のあるアプリケーション・サービス領域 →「REST API」から使用可能)を参照してください。OracleのRESTサービスを初めて利用する場合は、「クイック・スタート」セクションから始めることができます。

REST APIガイドのRESTサービス定義(「Oracle Help Center」→関心のあるアプリケーション・サービス領域 →「REST API」から使用可能)を参照してください。OracleのRESTサービスを初めて利用する場合は、「クイック・スタート」セクションから始めることができます。

ヒントと考慮事項

RESTサービスを使用して関係を正常に作成または更新するための要件を次に示します。

• ユーザーには、固定資産の関連付け(MNT_ASSET_FIXEDASSET_ASSOCIATE)権限が必要です。
• 在庫組織パラメータには、新しい「固定資産会計用資産台帳」属性の値が必要です。

UIと同様に、有効な固定資産タイプはCIPおよび資産計上済です。

主なリソース

• リリース・ドキュメント導入ベース資産および固定資産の関連付けを参照してください
• Oracle SCM Cloud REST APIドキュメントを参照してください(Oracle Help Centerからアクセスできます)。

ロール情報

• 次の事前定義済ジョブ・ロールのいずれかが割り当てられているユーザーは、自動的にこの機能にアクセスできます。
  • 保守マネージャ(ORA_MNT_MAINTENANCE_MANAGER_JOB)
  • 資産管理者(ORA_CSE_ASSET_ADMINISTRATOR_JOB)

• 次の1つ以上のサービス権限が含まれる構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。
  • サービス別企業資産の管理(CSE_MANAGE_ENTERPRISE_ASSETS_BY_SERVICE_PRIV)
  • サービス別企業資産の取得(CSE_GET_ENTERPRISE_ASSETS_BY_SERVICE_PRIV)
  • サービス別顧客資産の管理(CSI_MANAGE_CUSTOMER_ASSETS_BY_SERVICE_PRIV)
  • サービス別顧客資産の取得(CSI_GET_CUSTOMER_ASSETS_BY_SERVICE_PRIV)

• 次のいずれかの職務ロールが含まれる構成済ジョブ・ロールが割り当てられているユーザーは、この機能にアクセスできます。
  • 保守管理Webサービス(ORA_MNT_MAINTENANCE_SERVICE_DUTY)
  • 導入ベースWebサービス(ORA_CSI_INSTALLED_BASE_WEB_SERVICE_DUTY)

サービス・ロジスティクス

フィールド・サービスに対する複数パーティへの請求

サービス・ロジスティクスでは、報告ヘッダーを使用して個々の報告明細を介して複数のパーティに請求する機能が提供されるようになりました。以前は、フィールド・サービス作業オーダーおよびデポ修理作業オーダーの手数料は、報告ヘッダー・レベルで請求先顧客にのみ請求されていました。「顧客」、「アカウント」および「請求先住所」属性は、報告明細レベルで更新できるようになりました。別の「顧客」、「アカウント」または「請求先住所」の詳細を報告明細に追加すると、新しく追加した顧客詳細の請求書処理を容易にするために、一致する販売オーダー明細が作成されます。

「手数料」タブに追加された新しい「請求先詳細」フィールド

報告明細レベル属性に基づいて請求できるように、フィールド・サービス作業オーダーおよびデポ修理作業オーダーの「手数料」タブに新しいフィールドが追加されました。報告ヘッダーで使用可能な「顧客」、「アカウント」および「請求先住所」が明細レベルでも更新可能になりました。

「手数料」タブへの新しい「請求先住所」列の追加

「請求先詳細」コンテキスト・メニュー

報告手数料明細は、明細レベルの請求先詳細に基づいて価格設定されます。手数料明細に対する追加または変更は明細金額合計に影響し、価格設定情報は更新後に再計算され、請求に正しい金額が使用されるようになります。

報告明細レベルの請求先手数料により、労務費やその他のサービス経費などの様々な品目について、単一のフィールド・サービス作業オーダーおよびデポ修理作業オーダーで、複数のパーティに請求できます。

有効化のステップ

この機能を有効にするために何もする必要はありません。

ロール情報

• 次の事前定義済ジョブ・ロールのいずれかが割り当てられているユーザーは、この機能にアクセスできます。
  • フィールド・サービス管理者(ORA_RCL_FIELD_SERVICE_ADMINISTRATORS)
  • フィールド・サービス技術者職務(ORA_RCL_FIELD_SERVICE_TECHNICIAN_DUTY)
  • デポ・マネージャ(ORA_RCL_DEPOT_REPAIR_MANAGER_JOB)

支払条件を顧客アカウントから直接取得

顧客マスター・レベルで定義された支払条件に基づいて、フィールド・サービス作業オーダーおよびデポ修理作業オーダーの販売オーダーを作成できるようになりました。以前は、販売オーダーの作成時に使用されるデフォルトの支払条件を提供するために、事前変換ルールを設定していました。事前変換ルールはオプションになり、販売オーダーの作成時に顧客マスター・レベルで定義された支払条件がデフォルト設定されます。

顧客アカウント設定から直接取得されるオーダー手数料明細のデフォルト支払条件

顧客アカウントから支払条件を直接取得することで、追加の設定ステップの数を最小限に抑えます。

有効化のステップ

この機能を有効にするために何もする必要はありません。

ロール情報

• 次の事前定義済ジョブ・ロールのいずれかが割り当てられているユーザーは、この機能にアクセスできます。 
  • フィールド・サービス管理者(ORA_RCL_FIELD_SERVICE_ADMINISTRATORS)
  • フィールド・サービス技術者職務(ORA_RCL_FIELD_SERVICE_TECHNICIAN_DUTY)
  • デポ・マネージャ(ORA_RCL_DEPOT_REPAIR_MANAGER_JOB)

フィールド倉庫事業所へのフィールド・サービス部品の出荷

フィールド・サービス作業オーダーに必要な部品をフィールド在庫事業所に出荷できるようになりました。この出荷オプションにより、顧客およびフィールド・サービス技術者の事業所に出荷するための既存の機能が強化されます。

「部品の追加」UIおよび「部品要件の作成」UIヘッダー・リージョンを使用して、フィールド在庫事業所の出荷先住所を使用して、作業オーダー部品要件/オーダーを作成できるようになりました。これにより、フィールド・サービス技術者は、顧客サイトや技術者の自宅に部品を搬送するのではなく、地区のオフィスの倉庫、ドロップ・ボックスまたはその他のフィールド在庫事業所で部品をピックすることができます。この機能は、B2Bサービス作業オーダーの部品のオーダー時、およびサード・パーティ・オブジェクトの部品のオーダー時(搬送先組織が指定されている場合)に使用できます。

また、フィールド技術者が作業オーダーに割り当てられる前に部品がオーダーされると、「部品の追加」UIでは、作業オーダーの作業領域から搬送先組織がデフォルト設定されます。作業領域は、B2BサービスとOracle Field Service Cloudの統合によって割り当てられます。

フィールド・サービス作業オーダーの「部品の追加」UI

「部品要件の作成」ヘッダー・リージョン

作業オーダー部品をフィールド在庫事業所に出荷する機能が、部品サプライ・チェーンの柔軟性を高め、減損と紛失部品を削減します。

部品要件/オーダーの搬送先在庫組織を作業オーダーの作業領域からデフォルト設定すると、部品オーダーおよびフィールド技術者のスケジュールを調整する際のエラーと労力が軽減されます。

有効化のステップ

デフォルトの搬送先在庫組織を、サービス・ロジスティクス作業領域参照(ORA_RCL_WORK_AREA)のタグ列の作業領域に割り当てます。これらのデフォルト搬送先組織は、フィールド技術者がB2Bサービス作業オーダーに割り当てられる前に部品要件を作成する際に使用されます。

作業領域参照

ロール情報

次の事前定義済ジョブ・ロールのいずれかに割り当てられているユーザーは、この機能にアクセスできます。

• フィールド・サービス管理者(ORA_RCL_FIELD_SERVICE_ADMINISTRATOR)
• フィールド・サービス技術者職務(ORA_RCL_FIELD_SERVICE_TECHNICIAN_DUTY)

バックグラウンドでの手数料の転記による大量請求のサポート

Oracle Service Logistics Cloudでは、バックグラウンドで手数料を転記できるため、次の作業オーダーをすぐに更新できます。この機能の前は、次の作業オーダーを更新する前に、手数料が転記されるのを待機する必要がありました。新しい「手数料を転記してクローズ」ボタンをクリックすると、手数料を転記するバックグラウンド・ジョブが開始され、「デポ修理ワークベンチ」または「手数料および見積の管理」ページがクローズされます。

新しい「手数料を転記してクローズ」ボタン

バックグラウンドで手数料を転記することで、より大量の作業オーダーの更新および請求を処理できるようになりました。

有効化のステップ

この機能を有効にするために何もする必要はありません。

ロール情報

• 次の事前定義済ジョブ・ロールのいずれかが割り当てられているユーザーは、この機能にアクセスできます。
  • フィールド・サービス管理者(ORA_RCL_FIELD_SERVICE_ADMINISTRATOR)
  • フィールド・サービス技術者職務(ORA_RCL_FIELD_SERVICE_TECHNICIAN_DUTY)
  • デポ修理マネージャ(ORA_RCL_DEPOT_REPAIR_MANAGER_JOB)