移動時間の計算のためのルーティングの設定

拡張されたスケジュール設定および最適化を使用する場合の考慮事項

拡張されたスケジュール設定および最適化を使用している場合は、次の考慮事項に注意してください。

• 2 地点間予測ルーティングは、拡張されたスケジュール設定および最適化で常に使用されます。他のスケジュール方法 (2 地点間予測ルーティングで移動の計算に失敗した場合の空間へのフォールバックを除く) は、拡張されたスケジュール設定および最適化では適用されません。
• 移動距離に関係なく 2 地点間予測ルーティングが使用されます。
• スケジュール設定エンジンがリソースの開始点と終了点を認識するには、サービスリソースの本拠地のロケーションが地理コード化されている必要があります。
• スケジュールするサービス予定をガントチャートにドラッグすると、ルーティングの計算は選択した開始時刻によって異なります。たとえば、時間帯は通常の道路の速度の測定値に影響する可能性があります。
• [Travel From Home (minutes) (自宅からの移動時間 (分))] を [サービスリソースの対応可能状況(Service Resource Availability)] 作業ルールの一部として定義した場合、リソースは始業時間前に移動できます。この追加時間は、出発時間の計算時に考慮されます。
• 拡張されたスケジュール設定および最適化で 2 地点間予測ルーティングによる移動時間を計算できない場合、エンジンは空間ルーティングを使用して移動時間を推定します。移動モードの制限が適用されている場合、ロケーションが公道から 1.5 キロメートル以上離れている場合、データカバー率が不完全な場合、予測ルーティングでルートを実行できない可能性があります。たとえば、Alan しか対応できないリソースであるため、派遣担当者が手動で作業を割り当てるとします。Alan がトラックを運転する場合に Alan に割り当てられているルートでトラックを使用できなかったり、または、Alan は道路から 2 キロメートル離れた資産や新しい近隣にある資産を管理するよう割り当てられます。サービス予定、リソースの不在、または本拠地への移動時間を計算するために使用される移動元は、割り当て済みリソースまたはリソースの不在の [Specific Travel Time From Source (ソースからの推定移動時間)] 項目と [Specific Travel Time To Source (ソースへの推定移動時間)] 項目に自動的に表示されます。
• 拡張されたスケジュール設定および最適化を使用している場合、その日の最後のサービス予定がサービスリソースの本拠地と同じ住所にあると、割り当て済みリソースオブジェクトの [おおよその移動時間 (分)] 値が最後から 2 番目の予定で計算されます。前回の予定の [おおよその移動時間 (分)] の値が 0。拡張されたスケジュール設定および最適化を使用していない場合、サービスリソースの本拠地までのこの移動時間は、その日の最後のサービス予定で [割り当て済みリソース] オブジェクトの [推定移動時間 (分)] 値として計算されます。

拡張されたスケジュール設定および最適化を使用していない場合の考慮事項

拡張されたスケジュール設定および最適化を使用していない場合は、次の考慮事項に注意してください。

• 2 地点間予測ルーティングでは、関連する場合に有料道路が考慮されます。SLR と予測移動では有料道路の使用が避けられるため、移動時間が長くなる可能性があります。
• スケジュール設定エンジンがリソースの開始点と終了点を認識するには、サービスリソースの本拠地のロケーションが地理コード化されている必要があります。
• 空間ルーティングから SLR に切り替えると、スケジュールによって移動時間 (スケジュール済みの予定の時間を含む) が再計算されます。
• SLR が有効の場合、リソースの移動速度は考慮されません。ただし、空間ルーティングの計算に戻した場合は、移動速度が考慮されます。
• 番地レベルのルーティングキャッシュオブジェクトにより、2 地点間の過去 30 日間に計算された距離の計算時間が短縮されます。このオブジェクトを削除しないでください。
• SLR の移動速度は Google マップの運転プロファイルに基づいており、変更できません。
• 予測移動または 2 地点間予測移動を使用している場合、サービス予定がスケジュールされるようにガントチャートにドラッグされます。ルーティングの計算は、選択した開始時刻によって異なります。たとえば、時間帯は通常の道路の速度の測定値に影響する可能性があります。
• Queueable Apex を使用して作業をスケジュールする場合は、Database.AllowsCallouts アノテーションを使用して SLR で移動時間を推定します。このアノテーションを含めないと、空間ルーティングが使用されます。「Queueable Apex: More Than an @future (Queueable Apex: @future を超える機能)」を参照してください。
• [割り当て済みリソース] の [ソースからの推定移動時間] 項目には、その日の最終予定を除くすべての予定の計算方法として [エリア] が表示されます。[Travel From (移動元)] は、1 日の最後のサービス予定に対してのみ計算されるため、それ以外のすべての予定では、その値が 0 になります。1 日の最後の予定は SLR を使用して計算されます。
• サービス予定で 100 キロメートルを超える距離の移動が必要な場合、空間ルーティングが使用されます。
• 予測移動は、複数日の作業のスケジュールではサポートされていません。複数日作業のスケジュールでは、各日の正確な出発時刻が不明であるため、最も早い移動時間 (最小のトラフィックで夜間の時間枠に入る最適な SLR 移動時間) に対応する SLR が使用されます。複合作業では、最適化で 2 地点間予測ルーティングが使用され、プラットフォームのスケジュールには最適な SLR 移動時間が使用されます。
• データ操作言語 (DML) を使用するトランザクションでトリガーされるスケジュールアクションでは、空間ルーティングが使用されます。SLR が有効で、ローカルにプライミングされていない SLR 移動時間の結果がスケジュールに必要な場合、コールアウトを使用して結果を取得する必要があります。コールアウトと同じトランザクションで DML が実行された場合、例外 (コミットされていない待機中の作業エラーなど) が発生します。コールアウトに失敗したためにスケジュールが空間ルーティングに戻ると、移動時間と休憩の更新が実行された後でガントチャートに重複が表示され、移動が SLR または予測移動に更新される可能性があります。例外を避けるには、システムが空間ルーティングを使用することを許可するか、DML が別個のトランザクションで実行されるようにします。この種別のトランザクションで空間ルーティングに切り替えるのではなく例外を発生させる場合は、アプリケーションランチャーから Field Service Admin アプリケーションを見つけて開き、 [Field Service Settings | Scheduling(スケジュール)] をクリックします。[Avoid aerial calculation upon callout DML exception (DML コールアウト例外時に空間計算をしない)] を選択します。

2 地点間予測ルーティングに関するその他の考慮事項

• Spring '21 より前に作成された Salesforce 組織では、2 地点間予測ルーティングを有効にしていない場合でも、SLR または予測移動に切り替えることができます。
• 最も近い道路から 1.5 キロメートル以上離れた場所 (出発地または目的地) では、2 地点間予測ルーティングの代わりに空間ルーティングが使用されます。
• ナビゲート可能な国のリストで、2 地点間予測ルーティングで完全にカバーされているテリトリーを確認してください。
• 拡張されたスケジュール設定および最適化を使用していない場合、発信元と宛先が長距離であっても同じ大陸にあるときは、2 地点間予測ルーティングによって正確な予測ルーティングが提供され、グローバル最適化を実現します。ただし、Appointment Booking and Schedule (予定の予約とスケジュール) などのスケジュール操作では、サービス予定で 100 キロメートルを超える移動が必要な場合、2 地点間予測ルーティングではなく空間ルーティングが使用されます。拡張されたスケジュール設定および最適化を使用している場合、2 地点間予測ルーティングは、100 キロメートルを超える移動の最適化操作とスケジュール操作の両方でサポートされます。

重要 2 地点間予測ルーティングに切り替えると、スケジュールと最適化によって、スケジュール済み予定の時間を含む移動時間が再計算されます。より正確で若干長くなった移動時間によって、予定の重複が発生することがあります。リソーススケジュールの最適化を使用してローカルで (特定のリソースの) 重複を修正するか、グローバル最適化または全日最適化を実行してスケジュール全体を再最適化します (時間がかかります)。拡張されたスケジュール設定および最適化を使用していない場合、[Fix Overlaps (重複を解消)] スケジュールポリシーを適用する必要があります。