Oracle Transportation and Global Trade Management Cloud 19B What's New

アップデート19B

アップデート19B

改訂履歴

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

日付	機能	備考
2019年4月19日	エージェントのロギングおよび統計	文書の更新。19Bで提供される機能。
2019年3月28日	請求書調整原価動作の拡張	文書の更新。19Bで提供される機能。
2019年3月8日		初版作成。

概要

このガイドは、Oracle Transportation and Global Trade Management Cloudアップデート19Bの新機能や改善点に関して理解する必要がある情報の概要をまとめたものです。各項には、機能の簡単な説明、その機能を有効化または開始するために必要なステップ、ヒントや留意すべき考慮事項、および役に立つリソースが記載されています。

更新タスク

この項では、更新の計画、デプロイおよび検証に役立つ情報を紹介します。このドキュメントには頻繁に情報が追加されるので、更新を開始する前に最新情報を必ずご確認ください。

Oracle Engagement Cloudの更新を準備および検証する場合は、次の資料を使用してください。

My Oracle Supportで次をご覧ください。

Doc ID 2508854.1
- Oracle Cloud Applications - Transportation and Global Trade Management Cloud: Quarterly Updates - Preparation and Testing Recommendations
Doc ID 2095528.1
- Oracle Cloud Applications - Transportation and Global Trade Management Cloud: Quarterly Update Planning
Doc ID 2096782.1
- Oracle Cloud Applications - Transportation and Global Trade Management Cloud: Quarterly Update Planning FAQs
Doc ID 2098110.1
- Oracle Cloud Applications - Transportation and Global Trade Management Cloud: Update Policy

機能のサマリー

	機能の有効化に必要なアクション
機能	自動的に利用可	エンド・ユーザーのアクションが必要	管理者のアクションが必要	オラクル社へのサービス要求が必要
Transportation and Global Tradeプラットフォーム
アーキテクチャ
RESTサービス
デフォルト通知スタイルシートを公開コンテンツとして提供
エクスポート・ファイルの使い勝手の改善
エージェントのロギングおよび統計
ユーザー・インタフェースの刷新
アクセシビリティ - キーボード・ナビゲーション
アクセシビリティ - スキップ・ナビゲーション・メニュー
アクセシビリティ - 色の使用の検証
アクセシビリティ - スクリーン・リーダー
アクセシビリティ - ドキュメント
ユーザー・エクスペリエンス - 一般 - 新規インジケータ
ホーム・エクスペリエンスの改善 - デフォルトの色およびテーマ管理の拡張
マネージャ・レイアウト - 参照番号グリッドの削除をサポート
画面セット結果の改善
品目統合UI
ワークベンチ
ワークベンチ - ワークベンチでサポートされる追加GTMオブジェクト
ワークベンチ - ワークベンチでサポートされる追加OTMオブジェクト
ワークベンチ - ワークベンチ表でExcelへのエクスポートをサポート
ワークベンチ - レイアウト・メッセージ
ワークベンチ - スプリッタ構成 - 既存リージョンの分割
ワークベンチ - レイアウト表示書式
ワークベンチ - マネージャ・レイアウト・リージョン
ワークベンチ - ワークベンチ表の選択された行の合計
ワークベンチ - ワークベンチ表の一括更新サポート
ワークベンチ - 1つの詳細表に対する複数マスター
ワークベンチ - 表示のみアクセス
ワークベンチ - すべてリフレッシュ
ワークベンチ - 処理後のリフレッシュ
ワークベンチ - マスター表のリフレッシュ時に詳細表をリフレッシュ
ワークベンチ - ワークベンチ表の作成中または編集中に保存済問合せが実行されなくなった
その他の改善
文書管理 - 文書の追加の複数選択文書オプション
レポートの問合せベースの動的ドロップ・リスト
擬似フィールドとしての文書コンテキストのサポート
Oracle Transportation Management (ベース)
レート・エンジンのマルチ・スレッド化
走行マニフェスト
リリース方法オーダー構成オプションの追加
イベント追跡への文書処理の追加、出荷ステータス・インタフェースへの文書要素の追加
外部距離エンジンおよびマップの拡張
外部距離エンジンの構成UIの簡易化
画面セット - マップ・ホバー・フィールドの構成
ワークベンチ・マップ - ベンダー・マップ・コントロールの表示
ワークベンチ - 画面セットでのマップ・ホバー・テキストの構成
ワークベンチ・マップ - ワークベンチ・レイアウトでの複数マップのサポート
ワークベンチ・マップ - 外部距離エンジンおよびマップ - ストップ間のトラフィックの検討
ワークベンチ・マップ - ストップのペアごとに危険物を考慮
ワークベンチ・マップ - マップ上のズーム・レベルのロックおよびビューのロック
ワークベンチ・マップ - HEREでサポートされる追加のパラメータ
ワークベンチ・マップ - ALK鉄道ルート
ワークベンチ・マップ - ALKでサポートされる追加のパラメータ
ワークベンチ・マップ - マップ・フィルタ
外部距離エンジンと外部サービス・エンジンでの機材制限の考慮
輸送運用プランニング
クラスタ・マージ・アルゴリズム
同一場所ストップのマルチストップ混載
積荷構成 - スコアリング・アルゴリズム耐荷力
サービス・プロバイダの複数日の容量を考慮
ネットワーク・ルーティングで中間ロケーションのロケーション非アクティブ・フラグを考慮
ルール11およびネットワーク・ルーティング
追跡イベントETAに基づく先行/遅延の計算
ネットワーク・ルーティング内でレーティングをオフにする機能
範囲を超える重心のレポーティング
積み増しオーダー
ゲージ外積載の作成
ネットワーク・ルーティング - 通過ポイントでのオーダーの開始と終了を許可
ネットワークルーティング - クロスレグ混載
Oracle Fleet Management
組合せ機材グループの使い勝手 - 返却セット・シナリオ
スタンドアロンの作業割当プロセス
往復出荷順序vs.片道出荷順序に関するソリューション品質の向上
追跡イベントを受信したときのサービス時間の見積り
組合せ機材グループの使い勝手 - マルチストップ・シナリオのサポート
運送費支払、請求および請求
請求書調整原価動作の拡張
Logistics Network Modeling
Logistics Network Modeling
Global Trade Management (ベース)
データのグループ化および集計のためのフレックス・フィールド
データ構成を使用したフレックス・フィールドのコピー
ライセンス割当およびバランスを表示するレポート
トランザクションおよび申告に関する懸念パーティ・スクリーニングに停止信号を表示
出荷グループの関連貿易トランザクションの表示スマート・リンク
品目の分類タイプ/コード・レベルでの分類の承認または辞退
品目の分類コードのカスタムの摘要
ワークベンチ - 作業キューのサポート
GTMの方法/構成のトピック - 仕入先要請
GTMの方法/構成のトピック - 製品分類プロセス
「照合ファクタの検討」処理での逆インデックスの使用
「関税プリファレンス・タイプ」から「貿易プリファレンス」への名前変更
仕入先情報の追跡
パーティ・スクリーニング結果のアクセシビリティ向上
製品分類タイプと貿易プログラム間のスマート・リンク
製品分類コードと運賃レート間のスマート・リンク
GTMの方法/構成のトピック - ライセンス・スクリーニングの強化
AESの拡張
オーダー・リリースから貿易トランザクション
キャンペーン管理
品目原産に基づく貿易プログラムの適格性および認定の決定
品目タイプの指定
貿易品目の品目への名前変更
原産管理
パーティ・サイト
運賃レートの管理
取引先品目
貿易コンプライアンス
その他の管理タイプに対する自動例外のサポート
貿易協定
貿易協定の管理
貿易協定のスマート・リンク
Global Trade Intelligence (GTI)
ライセンスおよびライセンス明細の内訳およびディメンションが使用可能
新しい数量および原価の内訳が使用可能

Transportation and Global Tradeプラットフォーム

アーキテクチャ

RESTサービス

この機能はOracleへのREST APIのさらなる導入です。このRESTサービス機能により、使用できるRESTリソースのセットとサポートされる操作が増えるほか、docs.oracle.com上のREST APIドキュメントが刷新されます。

リソースおよびサポートされる操作

リソース	操作
Appointment	GET
Bill	GET
Claim	POST、GET、PATCH、DELETE
Consol	POST、GET、PATCH、DELETE
Contact	POST、GET、PATCH、DELETE
Contact(貿易パーティ)	POST、GET、PATCH、DELETE
Corporation	POST、GET、PATCH、DELETE
Driver	POST、GET、PATCH、DELETE
PowerUnit	POST、GET、PATCH、DELETE
Equipment	POST、GET、PATCH、DELETE
EquipmentGroup	POST、GET、PATCH、DELETE
EquipmentType	POST、GET、PATCH、DELETE
GtmShipment	POST、GET、PATCH、DELETE
GtmTransaction	POST、GET、PATCH、DELETE
GtmLicense	POST、GET、PATCH、DELETE
Invoice	GET
PackagedItem	POST、GET、PATCH、DELETE
Item	POST、GET、PATCH、DELETE
Itinerary	POST、GET、PATCH、DELETE
Location	POST、GET、PATCH、DELETE
Order	GET
OrLine	GET
OrderBase	GET
OrderMovement	GET
Quote	POST、GET、PATCH、DELETE
ServiceProvider	GET、PATCH
Shipment	GET、POST
SellSideShipment	GET、POST
Voucher	GET
Voyage	GET
WorkInvoice	GET
GtmCampaign	POST、GET、PATCH、DELETE

新しいドキュメント

新しいREST APIのドキュメントでは、各リソースおよび使用可能な操作に関する包括的なドキュメントを標準Swagger形式で提供します。このドキュメントには、すべてのREST APIリソースの正しいリクエスト、レスポンス構文、例および詳細なフィールド・レベルの説明が記載されています。

REST APIドキュメント

有効化のステップ

この機能を有効にするには、サービス・リクエスト(SR)を登録する必要があります。

ヒントと考慮事項

主キー属性

OTM/GTMのほとんどのリソースは一意のグローバル識別子(GID)をデータベースのレコードの主キーとして使用します。GIDの値は外部識別子(XID)とドメイン名を連結したものです。サブリソースは親GIDフィールドのほかにサブリソース自体のGIDフィールドを持つことができます。この更新より前は、特定のリソース・リクエストで返されるデータにGID、XIDおよびドメイン名のすべての属性が含まれていたため、それらの値の間に一定レベルの冗長性がありました。また、たとえ囲みコンテキスト内で暗黙的であっても、各サブリソース内でGIDが繰り返されるため、ほとんどのサブリソースが返していました。

注意: この更新以降では、リクエストしたリソースの主キー値を非表示にし、サブリソース内の親の主キーを非表示にすることが推奨されます。ただし、下位互換性の維持のため、デフォルトのREST API構成では今までどおりすべての属性が返されます。推奨される方法を有効にする場合は(リクエストしたリソースの主キー値を非表示にし、サブリソース内の親の主キーを非表示にする)、構成プロパティ「-glog.fusion.cil.restapi.config.hidePks=trueglog.fusion.cil.restapi.config.hideParentPks=true」を設定してください。下位互換性の懸念が解消され次第、速やかにこのプロパティ構成を使用することをお薦めします。将来の更新では、これらのプロパティ設定がデフォルトになる可能性があります。

ドキュメント

古いREST APIスタート・ガイドは、新しい対話型のREST APIガイドに置き換えられています。

主なリソース

古いREST APIスタート・ガイドは、新しい対話型のREST APIガイドに置き換えられています。

デフォルト通知スタイルシートを公開コンテンツとして提供

この機能では、公開コンテンツとしてロードされるデフォルト通知スタイルシートを提供します。これにより、通知スタイルシートのダウンロード、編集およびアップロードが以前よりも簡単になります。

デフォルト通知スタイルシートのコンテンツ

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

新しいコンテンツは、「ビジネス・プロセス自動化」>「パワー・データ」>「イベント管理」>「スタイルシート・プロファイル」にあります。

エクスポート・ファイルの使い勝手の改善

CSVエクスポートやDBMLエクスポートを実行するユーザーや、「統合コマンドの実行」を使用して特定のオブジェクトのアウトバウンド・トランスミッションを取得するユーザーのために使い勝手を改善しました。「ローカルのファイル」の保存オプションが追加され、出力をローカルに保存できるようになりました。また、新しいブラウザ・テキスト・パネルと「コピー・テキスト」オプションが追加され、エクスポート値を整然としたビューでブラウザにレンダリングできるようになりました。

「ローカルのファイル」エクスポート・オプション

ブラウザ・ベースのビューおよび「コピー・テキスト」オプション

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

ブラウザに表示されるテキストの分量が多い場合は、「コピー・テキスト」ではなく「ローカルへのファイル」の使用をお薦めします。データの一覧表示が目的の場合にのみ、「出力先」を「ブラウザ」に指定してください。

エージェントのロギングおよび統計

この機能により、エージェントおよびエージェント処理のロギングおよび統計が強化されます。各エージェント/エージェント処理の実行について、エージェントの開始、終了、エラー・メッセージまたは顧客指定のログ・インストラクションが取得されます。

また、エージェント/エージェント処理の完了に要した平均時間や最大時間など、各エージェント/エージェント処理の累積統計も取得されます。この拡張のエージェント・ロギングでは、エージェントが失敗してロール・バックした場合でもログ・エントリが生成されます。

新しい4つの表にエージェントおよびエージェント処理の情報が格納されます。

AGENT_LOG -各エージェント実行のログ。各レコードは、エージェントの開始、完了、エラーまたは顧客指定のログ・インストラクションを表しています。

AGENT_LOG - 各エージェント処理の実行ログ。各レコードは、処理の開始、完了、またはエラーを表しています。

AGENT_STATS - 各エージェントの累積統計。エージェント完了までの平均時間と最大時間が含まれます。

AGENT_ACTION_STATS - 各エージェント処理の累積統計。キュー時間、実行時間および完了時間の平均値と最大値が含まれます。

AGENT_LOGの内容

エージェント・ログに記録されるフィールドは次のとおりです。

LOG_SEQUENCE - ログ・レコードの一意の順序ID。ログの検索結果はこの順序の昇順でソートされます。これにより、エージェントのログ文を時系列で表示できます。

AGENT_RUN_SEQUENCE - エージェントの実行インスタンスの一意のID。エージェントが実行されるたびに、実行順序が生成されます。これにより、特定の実行のログ文を論理的にまとめてグループ化できます。

PARENT_AGENT_RUN_SEQUENCE - エージェント実行が別のエージェントからのアクティビティによってトリガーされた場合(RAISE EVENTエージェント処理やデータ変更後の変更継続期間イベントなど)は、親エージェントの実行IDが記録されます。

AGENT_GID - エージェントID

STATE - ログ・メッセージのタイプで、通常はエージェントの状態を表しています。
- STARTED - 最初のエージェント処理が発行されました。
- NOTE - ユーザーLOG処理で情報メッセージが指定されました。
- WARNING - ユーザーLOG処理で警告メッセージが指定されました。
- ERROR - エージェント処理で例外が発生したか、RAISE ERROR処理が実行されたか、ユーザーLOG処理でエラー・メッセージが指定されました。
- COMPLETED - 最後のエージェント処理が完了しました。

TIME - ログ・イベントのUTC時間

LOG_PROCESS_ID - エージェントの実行インスタンスのシステム・ログ・プロセスIDへのリンク。プロセスIDの24時間の期間を超えての一意性は保証されていません。検索する場合はエージェントの開始時間とプロセスIDを含める必要があります。

APP_MACHINE_GID - エージェントが実行されたサーバー。これはシステム・ログの取得用です。

LIFETIME_EVENT - エージェント実行をトリガーしたエージェント・イベント。

AGENT_DATA_QUERY_TYPE_GID - エージェント実行をトリガーするビジネス・オブジェクトのデータ問合せタイプ

AGENT_BUSINESS_OBJECT - エージェント実行をトリガーするビジネス・オブジェクトのID。

RUN_TIME - COMPLETEDレコードの場合、エージェント実行に要した時間。これは、COMPLETED TIMEからSTARTED TIMEの時間を引いて導出される時間です。この列は、OTM検索で実行時間の長いエージェントを簡単に検索できるように非正規化されます。

NOTES - LOGエージェント処理によって作成されたレコードに対してユーザーが指定した注釈。

ERROR_AGENT_ACTION_GID - エージェント処理によって発生したERRORレコードの失敗した処理。

ERROR_CAUSE - RAISE ERRORエージェント処理によって作成されたレコードについて、処理で指定されたエラー・メッセージ。エージェント処理例外の場合は、例外の最初の行。

ERROR_OBJECT - エラーの原因となったビジネス・オブジェクト。DTAまたはFORループでエラーが発生した場合は、AGENT_BUSINESS_OBJECTとは異なる可能性があります。

AGENT_ACTION_LOGの内容

エージェント処理ログに記録されるフィールドは次のとおりです。

LOG_SEQUENCE - ログ・レコードの一意の順序ID。ログの検索結果はこの順序の昇順でソートされます。これにより、エージェント処理のログ文を時系列で表示できます。

ACTION_RUN_SEQUENCE - 処理の実行インスタンスの一意のID。処理が実行されるたびに、実行順序が生成されます。

AGENT_RUN_SEQUENCE - 処理を起動したエージェントの実行インスタンスへのリンク。

AGENT_GID - エージェントID。

ACTION_FLOW - 処理を保持するエージェント・ブロック(NormまたはError)。

ACTION_SEQUENCE - エージェントの処理フローにおける処理の順序番号。(AGENT_GID, ACTION_FLOW, ACTION_SEQUENCE)で、AGENT_ACTION_DETAILS表内の処理を識別できます。ただし、ログ・レコードの書込み後にエージェントが変更された場合は、正しく識別できなくなることがあります。

STATE - ログ・メッセージのタイプで、処理の状態を表しています。
- STARTED - 処理の実行が開始しました。
- ERROR - 処理が例外をスローしました。
- COMPLETED - 処理(およびトリガーされた作業)は完了しました。

TIME - ログ・イベントのUTC時間

LOG_PROCESS_ID - 処理の実行インスタンスのシステム・ログ・プロセスIDへのリンク。

APP_MACHINE_GID - 処理が実行されたサーバー。

AGENT_DATA_QUERY_TYPE_GID - エージェント実行をトリガーするビジネス・オブジェクトのデータ問合せタイプ

AGENT_BUSINESS_OBJECT - エージェント実行をトリガーするビジネス・オブジェクトのID。

AGENT_ACTION_GID - エージェント処理ID。

ACTION_DATA_QUERY_TYPE_GID - 処理によって処理されるビジネス・オブジェクトのデータ問合せタイプ。DTAまたはFORループでエラーが発生した場合は、AGENT_DATA_QUERY_TYPE_GIDとは異なる可能性があります。

ACTION_BUSINESS_OBJECT - 処理によって処理されるビジネス・オブジェクトのID。DTAまたはFORループでエラーが発生した場合は、AGENT_DATA_QUERY_TYPE_GIDとは異なる可能性があります。

RUN_TIME - COMPLETEDレコードの場合、処理実行が開始してからすべての関連アクティビティが完了するまでの時間。

ERROR_MSG - RAISE ERRORエージェント処理によって作成されたレコードについて、処理で指定されたエラー・メッセージ。処理例外の場合は、例外の最初の行。

AGENT_STATSの内容

AGENT_GID - エージェントID

NUM_RUNS - エージェントがSINCEの日付以降に実行された回数。

TOTAL_TIME = 最初の処理が発行されてから最後の処理が完了するまでを測定した累積実行時間。

AVG_TIME = 平均実行時間。この非正規化フィールドは検索の問合せおよびソートで使用されます。

MAX_TIME = 最大実行時間。

SINCE = 統計が最後にリセットされた日付。

AGENT_ACTION_STATSの内容

AGENT_GID - 処理のエージェントID。

ACTION_FLOW - 処理を保持するエージェント・ブロック(NormまたはError)。

ACTION_SEQUENCE - エージェントの処理フローにおける処理の順序番号。(AGENT_GID, ACTION_FLOW, ACTION_SEQUENCE)は、AGENT_ACTION_DETAILS表への外部キーです。

NUM_WAITS - 処理がSINCEの日付以降に発行された回数。

TOTAL_WAIT_TIME = 発行から実行の開始までを測定した累積待機時間。

AVG_WAIT_TIME = 平均待機時間。

MAX_WAIT_TIME = 最大待機時間。

NUM_EXECS - 処理がSINCEの日付以降に実行された回数。

TOTAL_EXEC_TIME - 処理の開始から処理の完了までを測定した(つまり、公開されたトピックによる完了を含めない)累積実行時間。

AVG_EXEC_TIME= 平均実行時間。

MAX_EXEC_TIME = 最大実行時間。

NUM_RUNS - 処理がSINCEの日付以降に実行されて完了した回数。

TOTAL_RUN_TIME - 発行から処理完了までを測定した累積実行時間。

AVG_RUN_TIME = 平均実行時間。

MAX_RUN_TIME = 最大実行時間。

SINCE = 統計が最後にリセットされた日付。

OTMからのエージェントおよびエージェント処理のログの表示

OTMの任意の「プロセス管理」メニューから、エージェントおよびエージェント処理のログ・レコードにアクセスできます。

エージェントのログ

「エージェント」リンクをクリックすると、AGENT_LOGレコードの検索が表示されます。

エージェント・ログの検索の表示

エージェント・ログの検索の「エラー」タブの表示

検索ではエージェントとアプリケーション・サーバーがデータベース内に存在すると想定されます。エージェントの削除後に古いデータを検索する場合、これらの基準は使用できません。

検索結果ページには、エージェント・ログ・レコード用のスマート・リンクが2つあります。

処理ログ - 現在のエージェントの実行インスタンスに関連するすべてのエージェント処理ログ・レコードが表示されます。

システム・ログ - エージェント・ログ・レコードの時間からのすべてのシステム・ログ・レコードを表示します。レコードのシステム・ログIDを使用し、指定されたアプリケーション・サーバーから行を取得して表示します。システム・ログは頻繁に循環するため、履歴分析には使用できない場合があります。

エージェント処理ログの表示

「エージェント処理」リンクをクリックすると、AGENT_ACTION_LOGレコードの検索が表示されます。

エージェント処理の検索

検索結果ページにAgentLogスマート・リンクがあります。これをクリックすると、処理を実行したエージェント実行順序のすべてのエージェント・ログ・レコードが表示されます。

エージェントおよびエージェント処理統計の表示

エージェントおよびエージェント処理の統計は、エージェント・ビューアまたはエージェント・マネージャで直接表示できます。例を示します。

有効化のステップ

エージェントのロギングおよび統計収集の制御

エージェントのロギングおよび統計は、グローバルまたはエージェントごとに制御できます。次のプロパティは、すべてのエージェントのデフォルトの動作を制御します。

glog.agent.defaultLogLevel = [NONE| AGENT |ACTIONS] - AGENT.LOG_LEVELで明示的にロギングを設定していないエージェントのデフォルトのロギング。
- NONE = エージェント・ロギングは実行されません。エージェント・ロギングをオフにすると、パフォーマンスへのオーバーヘッドが発生しません。
- AGENT = エージェント・アクティビティがログに記録されます。これにはAGENT_LOGレコードのみが含まれます。
- ACTIONS =エージェントおよびエージェント処理のアクティビティがログに記録されます。これにはAGENT_LOGレコードとAGENT_ACTION_LOGレコードの両方が含まれます。

glog.agent.defaultStatsLevel = [NONE | AGENT | ACTIONS] - AGENT.STATS_LEVELで統計収集を明示的に設定していないエージェントのデフォルト統計収集。
- NONE =エージェント統計は収集されません。統計収集をオフにすると、パフォーマンスへのオーバーヘッドが発生しません。
- AGENT =エージェント統計が収集されます。これにはAGENT_STATSレコードへの挿入/更新も含まれます。
- ACTIONS =エージェントおよびエージェント処理の統計が収集されます。これにはAGENT_STATSレコードとAGENT_ACTION_STATSレコードに対する挿入/更新が含まれます。

これらのデフォルトは、各エージェントのエージェント・ヘッダーで上書きできます。

エージェント・ヘッダー

カスタム・ログ・レコードの追加

LOGエージェント処理を使用して、エージェントおよびエージェント処理のログに情報を追加できます。この処理は次のように更新されました。

システム・ログ、エージェント・ログまたはその両方にメッセージを書き込めます。
記録されたメッセージに重要度を割り当てることができます。
システム・ログに書き込まれたメッセージに特定のログIDを割り当てることができます。

LOG処理でASSIGN VARIABLE処理を使用することで、エージェント・ログに一時的問合せの結果を追加できます。

エージェント処理のパラメータ

必須フィールドは「メッセージ」フィールドのみです。明示的な指定がなければ、次のデフォルトが使用されます。

宛先 = システム・ログ
重要度 = 情報
ログID = ワークフロー

このため、この処理はv18 AGENT_ACTION_DETAILSレコードと下位互換性があります。データの移行は不要です。

ヒントと考慮事項

エージェント・ログの検索の「エラー」タブの表示

検索ではエージェントとアプリケーション・サーバーがデータベース内に存在すると想定されます。エージェントの削除後に古いデータを検索する場合、これらの基準は使用できません。

エージェント処理統計の表示

エージェントの統計レベルがAGENTまたはACTIONSの場合、エージェント・ヘッダーにはSinceの日付以降の平均実行時間と最大実行時間が表示されます。この実行時間は、最初のエージェント処理の発行からエージェント・プロセスの完了までを測定したものです。エージェントの保存済条件を評価する時間は含まれないことに注意してください。エージェント統計レベルがACTIONSの場合、各処理の平均完了時間および最大完了時間が表示されます。この時間は、処理の実行開始からその処理プロセスが完了するまでを測定したものです。

エージェント検索またはエージェント・マネージャ上の新しい処理「統計のリセット」を使用して、エージェント統計をリセットできます。これを使用して、特定のシナリオ(制御フロー・パスを含む場合もある)におけるエージェントのパフォーマンスをテストできます。

エージェント・ログと異なり、エージェントおよび処理の統計は、外部キーを通じて既存のエージェントまたはエージェント処理(あるいはその両方)に関連付けられます。エージェントを変更(ログ・レベルまたは統計レベルの変更を含む)すると、統計がリセットされます。

ユーザー・インタフェースの刷新

アクセシビリティ - キーボード・ナビゲーション

マウスを使わずにキーボードのみで、OTMおよびGTM内をナビゲートできます。[Tab]キーを使用してアプリケーションのほとんどの部分をナビゲートでき、[Shift]キーを押しながら[Tab]キーを押すと逆方向にナビゲートできます。

次に、改善された領域の一部を示します。

アプリケーション内のナビゲートを妨げるキーボード・トラップを排除しました。
セクション/タブ間を簡単にジャンプできるようになります。
様々なキーボード・キーでアプリケーションをナビゲートできるようになります。

次に、アプリケーションの一部の領域のキーボード・ナビゲーションの概要を示します。

ナビゲータ・メニュー

第1レベルのメニュー・グループは常に展開された状態で、折りたたむことはできません。

次の第1レベルのメニュー・グループに移動する - [Tab]キー
前の第1レベルのメニュー・グループに移動する - [Shift] + [Tab]キー
メニュー・グループ内の前の項目に上方移動する - 上矢印
メニュー・グループ内の次の項目に下方移動する - 下矢印
メニュー・グループを展開する - 右矢印
メニュー・グループを折りたたむ - 左矢印
メニュー・リンク上で選択したときに、ページを開く - [Enter]

グローバル・ヘッダー

[Tab]キーを使用するか、[Shift]キーを押しながら[Tab]キーを押して、グローバル・ヘッダー機能間をナビゲートできます。

スプリングボード・メニュー

同じレベルのメニュー・グループまたはリンクに左方移動する - 左矢印
同じレベルのメニュー・グループまたはリンクに右方移動する - 右矢印
メニュー・グループを閉じて、上位レベルのメニュー・グループにフォーカスを戻す - 上矢印
メニュー・グループを開き、次のレベルのメニュー・グループの最初の項目にフォーカスを置く - 下矢印
メニュー・リンク上で選択したときに、ページを開く - [Enter]

検索基準

検索基準ページのフィールドをナビゲートするには、[Tab]キーまたは[Shift]キーを押しながら[Tab]キーを押します。

検索結果

結果表の本体は1つのタブ・ストップです。
表にアクセスするには、[Tab]キーを使用します。
表内で移動するには、左矢印、右矢印、上矢印および下矢印キーを使用します。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

アクセシビリティ - スキップ・ナビゲーション・メニュー

統合グローバル・ヘッダーを使用するページでは、OTM/GTMページの最初のタブ・ストップでスキップ・ナビゲーション・リストが開きます。このリストを使用してグローバル・ヘッダーをスキップし、メイン・ページやページの他のコンポーネントに直接移動できます。また、[ALT]キーを押しながら[1]を押すと、いつでもスキップ・ナビゲーションにアクセスできます。アプリケーション内での現在位置によって表示されるメニューは異なります。

ホーム画面/スプリングボード上のスキップ・ナビゲーション・メニューは次のとおりです。

「コンテンツにスキップ」でスプリングボードにジャンプできます。
「検索にスキップ」でツールバー内の検索フィールドにジャンプできます。
「フッターにスキップ」で、スプリングボード内の使用可能な最後のアイコン、またはページの最下部セクションにジャンプできます。

タブが見つかったアプリケーション内のページ(「検索基準」および「マネージャ・レイアウト」)では、スキップ・ナビゲーション・メニューを使用してタブ間を移動できます。

タブ・オプション上では、使用可能なすべてのタブを確認できます。

スキップ・ナビゲーション・メニューには常に「ホーム」オプションがあり、ここからスプリングボードに戻れます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

アクセシビリティ - 色の使用の検証

アクセシビリティを考慮する場合、色のみを使用してユーザーに情報を伝達しないことが重要です。これまで色のみで情報を伝達していたページで別の伝達手段が使用されるようになりました。2つの領域を例に説明します。

以前の検索機能の一括更新では、オブジェクトの保存の成功および失敗をそれぞれ緑と赤で示していましたが、インジケータが追加されたことで、より明確に保存の成功と失敗を判別できるようになりました。

リンクには薄い青色で、さらに下線付きで表示されます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

アクセシビリティ - スクリーン・リーダー

この機能によりOTMおよびGTMで、読み上げ可能な画面ナビゲーション・パスを使用できるようになります。デジタル・テキストを合成音声に変換するスクリーン・リーダーは、視覚障害のあるユーザーが一般ユーザーと同レベルの独立性とプライバシを確保した状態で情報テクノロジを利用することを可能にします。スクリーン・リーダーにとって一貫性のあるUIフォーマットおよびレイアウトは、使用可能でシームレスなナビゲーション・プロセスを提供するうえで重要です。

OTMおよびGTMスクリーン・リーダーのナビゲーション操作を向上させるため、次の改善が行われました。

表の書式
- 適切な見出しと代替ラベルを追加し、スクリーン・リーダーで検索結果表を読み上げられるようにしました。
ロールの追加
- スクリーン・リーダー使用による利点をユーザーに提供するには、アプリケーションの様々な領域に適切なロールが割り当てられている必要があります。
- ボタンにはボタンのロールが必要です。
- メニューにはメニューのロールが必要です。
セクション/見出し
- すべてのタイプのフィールドに適切なセクション/見出しが付与されていることを確認し、スクリーン・リーダーで正しくナビゲーションできるようにします。
代替テキスト
- イメージなどの領域にテキストを追加し、スクリーン・リーダーによる読み上げを可能にします。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

アクセシビリティ - ドキュメント

OTM/GTMオンライン・ヘルプにアクセシビリティ機能ガイドという新しいトピックが追加されました。このガイドには、マウスを使わずに、またはスクリーン・リーダーを使用してOTM/GTMをナビゲートする方法が記載されています。

次のトピックが含まれています。

次を含むアプリケーション全体にわたるキーボード・コントロール。

スプリングボード
ナビゲータ・メニュー
検索結果ページ
インライン編集
ツリー・コントロール
自動エージェント処理またはエラー・ハンドラ

繰返しナビゲーションのスキップ

統合グローバル・ヘッダーを使用するページでは、OTM/GTMページの最初のタブ・ストップでスキップ・ナビゲーション・リストが開きます。このリストを使用してグローバル・ヘッダーをスキップし、メイン・ページに直接移動できます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

ユーザー・エクスペリエンス - 一般 - 新規インジケータ

OTMおよびGTM内のオプションのリストに青とオレンジの新しいインジケータを2つ追加し、以前からあるインジケータも更新しました。

新規インジケータは次のとおりです。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ホーム・エクスペリエンスの改善 - デフォルトの色およびテーマ管理の拡張

新しいデフォルト色

次の図に示すとおり、OTM/GTMのヘッダーおよびスプリングボードのデフォルト色が明るい青色の背景に変更され、濃い灰色のフォントおよびヘッダー・アイコンが使用されます。

テーマ管理の拡張 - 新しい色設定

テーマ管理に新しい機能を追加し、ホームのフォントやアイコン色を管理できるようにしました。追加された新しいフィールドは次のとおりです。

メインのフォント色: 第1レベルのスプリングボード・メニュー項目に使用するフォントの色。この色は、第3レベルのスプリングボード・メニュー項目にも使用されます。
スプリングボード・サブメニュー・フォント色: 第2レベルのスプリングボード・メニュー項目に使用するフォントの色。
スプリングボード・サブメニュー背景色: 第2レベルのスプリングボード・メニュー項目に使用する背景の色。デフォルトは白です。
ヘッダー・アイコン色 - 統合グローバル・ヘッダーのアイコンに使用する色。
ヘッダーの背景色 - 統合グローバル・ヘッダーの背景に使用する色。

テーマ管理の拡張 - カラー・スキーム

カラー・スキームを選択し、事前に選択された色およびイメージのグループを表示/選択して、これらを自身のテーマの基準として使用できます。デフォルトで使用できるカラー・スキームは次のとおりです。

オータム・レッド
新緑
濃い青
濃い灰色
濃紺
スカイ・ブルー (デフォルト): これはOTM/GTMで自動的に使用されるデフォルトのカラー・スキームです。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

マネージャ・レイアウト - 参照番号グリッドの削除をサポート

次のオブジェクトでは、マネージャ・レイアウトからの参照番号グリッドの移動または非表示/削除がサポートされます。

これにより、次を行うことができます。

このグリッドを別のタブに移動します。
マネージャ・レイアウトからグリッドを削除します。

次のオブジェクトでは、マネージャ・レイアウトの構成時にこの機能がサポートされます。

OTMオブジェクト

Driver
フレイト・フォワーディング
Invoice
請求書明細
Item
品目認定
品目注釈
Location
オーダー・ベース
オーダー・ベース明細
オーダー・ベース出荷ユニット
オーダー・リリース
オーダー・リリース明細
オーダー・リリース出荷ユニット
梱包品目
パワー・ユニット
至急オーダー
OB明細出荷準備完了
OB出荷ユニット出荷準備完了
リリース・インストラクション
出荷ユニット明細
Shipment
出荷実績
出荷の出荷ユニット
出荷の出荷ユニット明細
出荷ストップ

GTMオブジェクト

保税倉庫
キャンペーン
キャンペーン明細
コンプライアンス・ルール
Contact
ライセンス
ライセンス明細
Location
登録
Shipment
出荷明細
構造
構造コンポーネント
貿易協定
トランザクション
トランザクション明細

有効化のステップ

サポートされているマネージャ・レイアウトから参照番号グリッドを削除または移動するには、マネージャ・レイアウトを変更する手順に従う必要があります。

「構成および管理」→「ユーザー構成」→「マネージャ・レイアウト」にある「マネージャ・レイアウト」マネージャに移動します。
サポートされているマネージャを選択します。
次に、「詳細」タブを選択します。
マネージャ・レイアウト詳細ページで、参照番号グリッドを変更または削除するなどしてマネージャを構成できます。

マネージャ・レイアウトでの参照番号グリッドの移動と削除

ヒントと考慮事項

このグリッドを削除するのは主に、1つ以上の参照番号をマネージャ・レイアウト上のフィールドにグリッド・フラット化して、それらをグリッドに表示させないようにする場合です。

画面セット結果の改善

画面セット結果の改善点は次のとおりです。

検索結果内で、1つの注釈または参照番号クオリファイアに対して複数の値が表示される場合、それらはカンマ区切りで表示されます。
検索結果内で参照番号と注釈をアクティブ・リンクとして表示できます。

次は、これら両方の変更点が含まれているスクリーン・ショットです。

最初のオーダー・リリースにはバイヤー番号参照番号クオリファイアが複数あるため、それらの値がカンマ区切り文字列で表示されています。

2番目のオーダー・リリースにはバイヤー番号のリンクが表示されていて、検索結果から直接このアクティブ・リンクをクリックできます。これは画面セット結果の「リンクとして表示」設定を使用して構成します。

有効化のステップ

参照番号と注釈がアクティブ・リンクとして表示されるようにするには、画面セット結果の「リンクとして表示」設定を使用します。

品目統合UI

この機能は、1つの品目に対してOTMとGTMの全域にわたる1つのユーザー・インタフェースを提供します。統合品目には、ユーザーの輸送ニーズまたは貿易ニーズに合わせて必要なすべての情報が格納されます。新しい統合品目には以前のリリースと同じOTMメニューおよびGTMメニューからアクセスできます。また、GTMの「貿易品目」という名称が「品目」に変更されました。

統合品目 - タブ

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

OTMとGTMの両方で、これが新しいデフォルトの品目マネージャになります。

以前に構成した品目マネージャも今までどおりサポートされます。

ワークベンチ

ワークベンチ - ワークベンチでサポートされる追加GTMオブジェクト

この機能により、新たなオブジェクトがGTMワークベンチ表でサポートされるようになります。すでにサポートされている多数のオブジェクトに加え、さらにオブジェクトが追加されたワークベンチは作業環境を構成するときにアクセスする最初の場所であり、複数のオブジェクトやコンポーネントを1つのビューに関連付けるなどして作業環境を構成できます。

表として追加できる追加のGTMオブジェクトには、次のものがあります。

キャンペーン
キャンペーン明細
キャンペーン明細文書

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - ワークベンチでサポートされる追加OTMオブジェクト

ワークベンチに表を追加するときに、次を使用できるようになりました。

請求
出荷原価オブジェクト
作業割当バルク・プラン

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - ワークベンチ表でExcelへのエクスポートをサポート

ワークベンチ表のツールバーに追加された新しいアイコン/ボタンを使用して、ワークベンチ表からExcelに直接エクスポートできます。この機能により、選択した行または表内のすべての行をExcelにエクスポートできます。

エクスポート

有効化のステップ

レコードをエクスポートするワークベンチ表で「エクスポート」アイコンを選択してプロセスを開始します。次のステップとして、すべてのレコードをエクスポートするか、または選択したレコードのみをエクスポートするかのオプションが提示されます。

表内のすべてのレコードをエクスポートするオプション、または選択したレコードのみをエクスポートするオプションのいずれかを選択します。

ファイルがエクスポートされるのを待ち、ファイルをダウンロードします。
エクスポートされたxlsファイルを開きます。

ワークベンチ - レイアウト・メッセージ

エラー・メッセージまたは情報メッセージがある場合にのみ、「メッセージ」アイコンがワークベンチ・レイアウトに表示されます。アイコンの上にマウスを置くと、新しいメッセージの数(メッセージ数)がツールチップに表示されます。このアイコンをクリックすると、メッセージの詳細が含まれたウィンドウが表示されます。メッセージに表示される情報は次のとおりです。

日付: メッセージが発生した日時が表示されます。これはサーバーの日時です。
タブ名: メッセージを生成したワークベンチ・タブの名前が表示されます。
ワークベンチ・メッセージ: ワークベンチによって生成されたメッセージが表示されます。
マップ・ベンダー・メッセージ: マップ・ベンダー固有のメッセージ(存在する場合)を表示します。

これらのメッセージを確認した後、メッセージをエクスポートまたはクリアできます。メッセージ・アイコンは、メッセージがクリアされるまでワークベンチ・レイアウト・ツールバーに表示されます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - スプリッタ構成 - 既存リージョンの分割

以前のリリースでは、すでにコンテンツがあるリージョンに新しい分割リージョン(水平と垂直の両方)を追加するには、最初にタブを削除してから分割を追加し、タブを再作成する必要がありました。このリリースでは、すでにコンテンツがあるリージョンでも垂直および水平方向の分割ボタンを使用できます。

分割機能を実行すると、元のコンテンツが最初のペインに表示され、2番目の空のペインにコンテンツを追加できます。この例ではマップ・ペインが水平方向に分割されており、元のマップは左側に、新しいペインは右側に表示されます。

分割操作を取り消すには、ペイン内にある削除ボタンを使用して空のリージョンを削除します。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - レイアウト表示書式

レイアウト表示機能を使用して、空白を少なくして現在のレイアウトをよりコンパクトに表示できます。これは特に大規模なレイアウトで役立ちます。

レイアウトの表示オプションは次のとおりです。

デフォルト: 最大フォントおよび最大間隔を使用する場合に選択します。

デフォルトの最大フォント

コンパクト: 中サイズのフォントおよび間隔を使用する場合に選択します。

コンパクトの中サイズのフォント

超コンパクト: 最小のフォントおよび間隔を使用する場合に選択します。

超コンパクトの最小サイズのフォント

有効化のステップ

「レイアウトの作成」、「レイアウトのコピー」またはレイアウトの編集を使用してレイアウトを作成、コピーまたは編集するときに、特定のワークベンチ・レイアウトにレイアウト書式を割り当てることができます。

レイアウト書式の設定

「レイアウト表示」をクリックして指定したレイアウト書式は、レイアウトの作成/編集時に選択されたレイアウト書式を上書きします。

ワークベンチ - マネージャ・レイアウト・リージョン

ワークベンチ・レイアウトを構成するときに、表示または編集のマネージャ・レイアウトをワークベンチの詳細リージョンとして含めることができます。ワークベンチ・レイアウトにリージョンを追加するときに、新しいマネージャ・レイアウトのオプションを使用できます。

マネージャ・レイアウトをワークベンチに追加するときに、次を指定する必要があります。

タブ名。
このリージョンに編集と表示のどちらのマネージャ・レイアウトを表示するかを指定します。
「関連マスター表」。使用するマネージャ・レイアウトは、このマスター表の画面セット(画面セットの「一般」タブで構成される)に関連付けられます。

次は、編集マネージャ・レイアウトを使用したワークベンチ・レイアウトの例です。

次は、表示マネージャ・レイアウトを使用したワークベンチ・レイアウトの例です。

ワークベンチ・レイアウト内のその他多くの詳細リージョンと同様に、このリージョンにはロック/ロック解除機能があります。

「ビューのロック」アイコンをクリックするとマネージャ・レイアウトがロックされ、結果が固定されます。マスター表で別の行をクリックしても、マネージャ・レイアウト内の結果は変わりません。

これは、たとえば、出荷マスター表と出荷マネージャ・レイアウトを表示しているときに、表示する出荷を選択して、マネージャ・レイアウトをロックできるので便利です。出荷マネージャのレイアウトをロックしている間は、出荷表内をクリックしてもマネージャ・レイアウトの表示は変わりません。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

マネージャ・レイアウトはできるだけ簡略化/構成してから使用することをお薦めします。デフォルト/公開のマネージャ・レイアウトは膨大なデータを表示するため、ワークベンチ・レイアウトで表示するには負荷が高すぎる場合があります。

ワークベンチ - ワークベンチ表の選択された行の合計

画面セット結果列が合計として構成されている場合、選択された行の合計がワークベンチ表に表示されます。合計は表の下部に表示されます。

合計表示

有効化のステップ

画面セット内で関連する結果列を合計に構成し、ワークベンチ表を構成するときにその画面セットを使用します。

次は、画面セット結果列を合計に設定する例です。これを設定するには、画面セット結果構成の「詳細」ボタンを使用します。

ワークベンチ - ワークベンチ表の一括更新サポート

結果列が画面セット列内で編集可能として構成されている場合、それらを一括更新できます。新しい機能がワークベンチ表に追加されており、ワークベンチ表に使用されている画面セットに編集可能として構成された列がある場合に表示されます。

これにより、複数のレコードを同時に編集できます。

有効化のステップ

一括更新を開始するには、表のレコードを選択してから「一括更新」アイコンをクリックします。

ポップアップが表示され、そこで変更を行うことができます。
変更を保存します。
この機能は検索上での動作と同じですが、確認ポップアップは表示されません。

ワークベンチ - 1つの詳細表に対する複数マスター

ワークベンチに表を構成する際、その表が詳細表として構成されている場合は、1つ以上のマスター表を選択できるようになりました。これまでマスター表として選択できるのは1つの表のみでした。たとえば、プランニング・ステータスの出荷と実行ステータスの出荷の両方を、「出荷ストップ」詳細表のマスター表として選択できます。

有効化のステップ

ワークベンチ表を構成します。

表を詳細表に指定します。

目的のマスター表ごとに保存済検索を指定します。保存済検索を移入していないマスター表は、この詳細表のマスター表になりません。保存済検索は詳細とマスターの関係を確立するために使用されます。

ワークベンチ - 表示のみアクセス

ユーザー・アクセス機能が拡張され、選択したワークベンチ・レイアウトに対し表示のみアクセスをユーザーに付与できるようになりました。ワークベンチ・レイアウトに対するアクセス権が表示のみのユーザーは、レイアウトを編集または削除できません。

有効化のステップ

ユーザー・アクセス権限を持つ管理者は特定のワークベンチ・レイアウトへのアクセス権をどのユーザーに付与するかを構成できますが、このリリースではさらに、ユーザー・アクセス・マネージャのワークベンチ・レイアウトの横にあるフラグを設定することで、アクセスを「表示のみ」に制限できます。

ワークベンチ - すべてリフレッシュ

他のOTMユーザーまたはバックエンド・プロセスによってデータが変更されたことが原因で、ワークベンチ・レイアウトに表示されているOTMデータが最新の状態でなくなることがあります。すべてを自動または手動でリフレッシュするオプションを使用して、レイアウト内で各コンポーネント(子ではない)をリフレッシュできるようになりました。すべてをリフレッシュするプロセス(手動または自動)を実行すると、子ではない各コンポーネントについて既存オブジェクトの最新データが取得されます。現在選択しているオブジェクトが今も存在しているとはかぎらないため、現在の選択が無効になる可能性もあります。

ワークベンチで新しい2種類のすべてリフレッシュ機能を使用できます。

すべてリフレッシュ - ADMINユーザー(ADMINロールを持つユーザー)は、設定期間(5分から120分の間)が経過すると自動的にリフレッシュされるワークベンチ・レイアウトを構成できます。これは最小限の介入でデータをモニタリングする場合に適しています。この設定は、レイアウトの作成時、またはレイアウト編集時のレイアウト詳細で指定できます。

ツールバーの「すべてのデータのリフレッシュ」(ボタン/アイコン) - ワークベンチ・レイアウト・ツールバーにある新しい「すべてのデータのリフレッシュ」アイコン/ボタンを使用して、ワークベンチ内でワークベンチのリフレッシュを直接開始できます。

有効化のステップ

すべてリフレッシュ - 自動

ADMINユーザー(ADMINロールを持つユーザー)は、設定期間(5分から120分の間)が経過すると自動的にリフレッシュされるワークベンチ・レイアウトを構成できます。この設定は、レイアウトの作成時、またはレイアウト編集時のレイアウト詳細で指定できます。期間が過ぎると、「すべてリフレッシュ」は表示されているデータの問合せを再実行し、ワークベンチ全体を完全リフレッシュします。

自動リフレッシュを行うワークベンチ・レイアウトは、ワークベンチ・レイアウトの作成時、またはレイアウト・ツールバーにあるレイアウト詳細アイコンを使用して設定します。

ワークベンチを自動リフレッシュするように設定すると、ワークベンチ・レイアウトの上部にカレンダ・アイコンが表示されます。このアイコン上にマウスを重ねると、最後のリフレッシュの時間および次回のリフレッシュ時間が表示されます。

すべてリフレッシュ - 手動

ワークベンチ・レイアウト・ツールバーにある新しい「すべてリフレッシュ」アイコン/ボタンを使用して、ワークベンチ内でワークベンチのリフレッシュを直接開始できます。

「すべてリフレッシュ」は表示されているデータの問合せを再実行し、ワークベンチ全体を完全リフレッシュします。自動リフレッシュが構成されたワークベンチ・レイアウトで手動リフレッシュを実行すると、自動リフレッシュ・タイマーがリセットされます。たとえば、自動リフレッシュ間隔が20分で、最後のリフレッシュ時間が9: 00の場合、レイアウトを9: 15に手動でリフレッシュすると、次のリフレッシュ時間は9: 35 (手動リフレッシュ後20分)に更新されます。

ヒントと考慮事項

手動のすべてリフレッシュ機能および自動リフレッシュ機能を使用する場合の考慮事項は、次のとおりです。

コンポーネントがインライン編集モードの場合は、「すべてリフレッシュ」機能(手動または自動)を実行しないでください。データが変更され、その変更が保存されていない場合、リフレッシュ時にそれらの変更が失われます。

「すべてリフレッシュ」は表示されているデータの問合せを再実行し、ワークベンチ全体を完全リフレッシュします。

自動リフレッシュが構成されたワークベンチ・レイアウトで手動リフレッシュを実行すると、自動リフレッシュ・タイマーがリセットされます。たとえば、自動リフレッシュ間隔が20分で、最後のリフレッシュ時間が9: 00の場合、レイアウトを9: 15に手動でリフレッシュすると、次のリフレッシュ時間は9: 35 (手動リフレッシュ後20分)に更新されます。

ワークベンチ - 処理後のリフレッシュ

ワークベンチ内でオブジェクトに対する処理を完了すると自動的にリフレッシュが実行され、更新されたデータが可能な範囲で表示されます。ほとんどの処理がサポートされていますが、次のような複雑な処理は除外されます。

作業割当処理
- 出荷の追加
- 出荷の削除

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - マスター表のリフレッシュ時に詳細表をリフレッシュ

マスター表レコードがリフレッシュまたは選択されると、詳細表レコードの問合せが再実行され、レコードに加えられた変更内容が反映されます。再問合せされたデータが詳細表で使用可能になります。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - ワークベンチ表の作成中または編集中に保存済問合せが実行されなくなった

ワークベンチ・レイアウトの作成速度を上げるため、ワークベンチ表の作成または編集中に保存済問合せは実行されなくなりました。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

ワークベンチの作成または編集時に保存済問合せは自動的に実行されませんが、ワークベンチを作成または編集するときに手動で保存済問合せを実行できます。

その他の改善

文書管理 - 文書の追加の複数選択文書オプション

この機能によって、OTM出荷、GTMキャンペーンおよびGTMキャンペーン明細マネージャの文書機能が拡張されます。この新しい機能により、複数選択を実行して複数のオブジェクトにわたって文書を作成、リンクまたはコピーできるようになります。これは共通のビジネス関係に対するサポートを向上するもので、1つのドキュメントを複数の選択に関連付けることが可能になります。たとえば、標準証明を出荷のセットにコピーしたり、複数のキャンペーン明細に対して1つの原産地証明書をアップロードしたりできます。

「文書の追加」処理機能には、次が含まれます。

新規として作成 - 新規ドキュメントを、検索結果で選択した1つ以上のオブジェクトに追加できます。
リンクとして作成 - 選択済または既存の文書を、選択した1つ以上の検索結果にリンクできます。
コピーとして作成 - 選択済または既存の文書を、選択した1つ以上の検索結果にコピーできます。

この機能では、次の機能も提供されます。

文書の使用方法の指定。次の使用方法のオプションを使用できます。
1. 個別(I) - 個別文書として作成された単独の文書であることを示すために使用されます。この文書が後にその他の文書にリンクまたはコピーされても、使用方法の指定は「個別」のままです。
2. リンク済(L) - リンク済文書は、他の文書に直接リンクされている文書です。リンク元の文書はリンク済文書の関連文書IDで識別できます。また、連結フラグが選択されている「文書タイプ」から生成された文書は「使用方法」がリンク済となり、そのような文書の関連文書IDは連結文書にリンクされます。
3. 連結(C) ? 連結文書は相互参照のための文書であり、様々なオブジェクトのデータを使用して作成された文書の相互参照リンクを提供するために使用されます(複数の出荷のアクティビティを要約した四半期出荷要約文書や複数のキャンペーン明細を網羅する要約文書など)。連結文書の生成は文書に関連付けられている文書タイプで連結フラグが選択されている場合にトリガーされます。連結対象の文書に対して1つの連結文書が生成され、オブジェクトごとに1つのリンク文書が割り当てられます。このリンク文書は関連文書IDを通じて連結文書を参照します。各オブジェクトにはそれぞれのリンク文書がありますが、連結文書自体にはオブジェクトが関連付けられません。連結文書が存在する意義は、関連するすべてのオブジェクト間の相互参照を作成することにあります。
4. テンプレート(T): 空白フォームの文書を示します。ユーザーはこれをダウンロードして入力し、完成した文書としてアップロードできます。テンプレート文書を文書タイプに関連付けると、その文書タイプを選択したときにそのテンプレートをダウンロードできるようになります。

文書コンテキスト・クオリファイアIDおよび値 - 文書で使用する独自の一意識別子クオリファイア値を作成できます。

文書の有効日および失効日

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

新しい「ビジネス・プロセス自動化」→「文書」→「追加」オプションで、「文書の添付」、「文書の生成」、「文書のアップロード」の処理と同等(以上)の処理がサポートされます。新しい「追加」オプションがある場所では提示する処理の数を減らすことができるため、ユーザーが迷うことなく操作できます。

レポートの問合せベースの動的ドロップ・リスト

この機能では、SQL問合せを作成し、これを使用してレポートの値のドロップ・リストを生成できます。これにより、レポートの生成に使用するパラメータ値を制限できます。

有効化のステップ

レポート・パラメータを定義するときにテキスト領域にSQL問合せを記述すると、そのSQL問合せが実行されて、その出力に基づいてドロップ・リストが生成されます。

「ビジネス・プロセス自動化」→「パワー・データ」→「文書生成」→「レポート」に移動します。

「動的リスト」タイプのレポート・パラメータを作成します。
このパラメータのSQL問合せを入力します。

動的リストの入力

レポートを実行すると、入力したSQL問合せに基づいてドロップ・リストが生成されます。

擬似フィールドとしての文書コンテキストのサポート

この機能では、文書コンテキスト・フィールドを擬似フィールドとして使用するオプションが提供されるため、疑似フィールドで提供されるすべての構成オプションを使用できます。たとえば、文書コンテキスト・クオリファイア = 文書改訂の疑似フィールドを構成し、これを検索に追加することで改訂のあるまたは改訂のない文書を簡単に検索できます。

文書コンテキスト擬似フィールド

文書コンテキストの擬似フィールド

有効化のステップ

この機能は、その他の疑似フィールドと同じように標準の画面セット・マネージャの手順に従って有効にします。

「構成および管理」→「ユーザー構成」→「画面セット・マネージャ」に移動し、公開文書画面セットをコピーします。

「結果」タブに移動します。このページを使用して、この画面セットに割り当てられているビジネス・オブジェクトの結果ページに表示される列を構成します。すべての結果ページの最初の列として一貫して表示されるID列の幅を入力します。

文書コンテキスト・フィールドは擬似として識別され、文字pのマークが付与されます。

文書コンテキスト・フィールドを結果に追加します。

このフィールドに使用する文書コンテキスト・クオリファイアを選択します。

Oracle Transportation Management (ベース)

レート・エンジンのマルチ・スレッド化

この機能では、レート・エンジンのコール(内部OTMレート・エンジンと外部レート・エンジンへの両方のコール)をマルチスレッド化するオプションが提供されます。レート・エンジンのコールをマルチスレッド化する機能により、レーティング・コールが発生する領域(レート照会(RIQ)、バルク・プランニング、レーティングが含まれる処理など)で、OTMのレーティング・パフォーマンスを向上できる可能性があります。

有効化のステップ

初期のスレッド数/デフォルト値は1であり、レート・レコードが順次評価されることを意味します。

バックログが大きく、(平均の)キュー・サイズも大きい場合は、スレッド数を2の倍数で増やすことをお薦めします。最適な設定になるようにスレッド数を2ずつ増やし、設定ごとにスループット(バックログおよびキュー・サイズ)を確認する方法をお薦めします。

「イベント・キュー」ページを使用して、様々なバッチ・スレッド設定の影響を変更または調整して、状況を確認できます。「イベント・キュー」で行う設定変更は一時的なものであり、サーバーを再起動すると失われます。最適なスレッド設定が決まったら - このアプローチではスレッド・グループを設定してからサーバーを起動します。

「イベント・キュー」ページには、「構成および管理」→「技術サポート」→「診断およびツール」→「イベント管理」→「イベント・キュー」を使用してアクセスできます。

「イベント・キュー」ページにアクセスするには、DBA.ADMINとしてOTMにログインする必要があります。

イベント・キュー・レーティング・タスク

主なリソース

OTM/GTMのマルチスレッド化の効率的な使用方法の詳細は、次を参照してください。

ヘルプ・トピックのOTMでのマルチスレッド化ロジック
Cloudスタート・ガイド(https://docs.oracle.com/cd/E60665_01/otmcs_gs/OTMCG/OTMCG.pdf)のワークフロー・スレッド・チューニングの項

走行マニフェスト

この機能で提供される出荷処理を使用して、出荷の走行(ローリング)マニフェストのビューを生成できます。走行マニフェストには、輸送貨物に関するストップからストップまでのストップ・レベルの詳細が表示されます。

走行マニフェスト処理には、「出荷管理」→「出荷管理」→「運送サービスの買い」→「処理」→「出荷管理」→「表示」→「走行マニフェスト」でアクセスできます。

次は、マルチコンパートメント・トラックを使用したマルチストップ出荷の例です。

ヘッダー

ヘッダーには、地域、参照番号および機材に関する基本的な出荷情報が表示されます。「機材」セクションには出荷-機材IDへの唯一の参照が表示されます。これ以降、機材は順序番号で参照されるためです。機材情報には、実際のトラックに記載されている番号とトラックのタイプ(構成されている場合)も表示されます。

走行マニフェストのヘッダー

ストップ間の詳細

結果画面は、ストップ間の詳細ごとに分割されています。これらのセクションを展開すると、ストップ間の情報が表示されます。

走行マニフェストのストップ

各セクションを展開すると、次のストップに関連する情報について説明するヘッダーが表示されます。また、これらのストップ間の積載出荷ユニットの詳細リストも表示されます。さらに、機材とコンパートメントの稼働率に関する要約を示すセクションが2つあります。詳細を表示するには、各セクションを展開する必要があります。

ストップ1からストップ2の走行マニフェスト詳細

出荷ユニット詳細を展開すると、ストップ間の輸送貨物の情報が表示されます。これは機材、コンパートメント、ストップ番号別に整理されています。これにより、輸送中の品目とその輸送先がわかります。バルク出荷の方法を理解しているユーザーにとっては出荷ユニットの数が役立つはずです。このレポートは商用利用を目的としており、数量や重量に関する詳細が含まれています。

出荷ユニット - ストップ1からストップ2 (部分リスト)

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

走行マニフェストに危険物アイコンを表示するには、危険物認定プロセスの実行パラメータをtrueに設定する必要があります。

リリース方法オーダー構成オプションの追加

この機能では、オーダー・リリース明細レベルのフィールドが新たに2つ追加され、これらを使用してオーダー構成を定義できます。

追加されたオーダー構成オプションは次のとおりです。

オーダー・リリース明細重量
オーダー・リリース明細容積

両方のフィールドで3つの値がサポートされます。

非使用
NULLの場合 (デフォルト値)
常時

オーダー・リリース明細の重量および容積オプション

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

次のプロパティは非推奨です。

glog.business.order.orLineVolumeCalcType
glog.order.line.alwaysRecalcWeightVolume

イベント追跡への文書処理の追加、出荷ステータス・インタフェースへの文書要素の追加

この機能は、追跡イベント(ShipmentStatus)で使用できるドキュメント管理機能を提供します。

標準のすべてのビジネス・プロセス自動化文書管理処理を追跡イベントで使用できるようになりました。

文書の添付
文書の生成
制限文書
文書のアップロード

また、文書要素がShipmentStatus (別名: 追跡イベント)インタフェースに追加されました。これにより、ShipmentStatusインタフェースから直接文書をロードできるようになり、文書インタフェースを使用して文書をロードする必要がなくなります。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

主なリソース

OTM/GTMの統合機能の詳細は、Oracleヘルプ・センターの統合ガイドを参照してください(https://docs.oracle.com/cloud/latest/otmcs_gs/docs.htm)。

外部距離エンジンおよびマップの拡張

外部距離エンジンの構成UIの簡易化

外部距離エンジンおよび外部サービス・エンジンを構成するには、エンジンと互換する属性を確実に構成しなければならず、非常にわかりにくい作業でした。このプロセスを再設計し、エンジンの選択に応じて必要な互換属性のみがUIに表示されるようにしました。

UIでは、HERE、ALK、Oracle Spatialのエンジンがサポートされます。

ユーザーが外部エンジン・タイプを選択すると、選択した外部エンジン・タイプに関連付けられている属性のみがUIに表示されます。コードには正しいJavaクラスにも入力されます。

キャッシュをオフにする新しいオプションも提供されます。

エンジン構成の簡易化

HEREエンジンも更新され、新しいパラメータが表示されます。また、EDE/ESE elseに制限重量を構成して固定できるため、自動的に計算できます。制限重量は新しく追加されたパラメータであり、固定の制限重量を設定する場合にのみ使用します。パラメータを必要としない動的な計算方法と混同しないようにしてください。

新しいHEREパラメータ

ALKエンジンも更新され、新しいパラメータが表示されます。

新しいALKパラメータ

有効化のステップ

この機能は外部エンジンの構成に関するものです。EDE (外部距離エンジン)に指定した内容は、ESE (外部サービス・エンジン)にも適用されます。

設定にはスマートUIが使用されます。最初に、使用するエンジンを選択します。使用可能なオプションは選択したエンジンによって異なります。Javaクラスを覚えておく必要もありません。自動で入力されます。

ヒントと考慮事項

各エンジンでサポートされる属性に基づいて、各エンジン用のロジックを提供することになりました。これによりユーザーは、互換しない属性や値(指定された値リストがある)を指定できなくなります。

この拡張の短所は、新しいエンジンにも同様のオンボーディングが必要になる点です。このような大規模なアプリケーションで新しいベンダーが出現する可能性は低く、新製品の発表によって時期的な問題が発生する可能性は低いと考えられます。

使い勝手を向上することのメリットが一般的な解決策に対する懸念をはるかに上回ると判断しました。

ベンダー・ソリューションは高価なものが多く、使用される実装ベンダーは1社になることが多いようですが、OTMでは複数のエンジン構成を処理できます。同じベンダーに対して複数のエンジン構成が使用されることは珍しくないため、構成を簡易化するための拡張を行いました。

画面セット - マップ・ホバー・フィールドの構成

画面セット結果のホバーに含める設定が強化され、ワークベンチ・レイアウトにマップ・ホバーやガント・ホバーを構成できるようになりました。

有効化のステップ

画面セットでホバーに含める設定を使用して、ワークベンチ・レイアウトにマップ・ホバー・フィールドを構成します。

ワークベンチ・マップ - ベンダー・マップ・コントロールの表示

ワークベンチ・マップの「管理」機能を使用して、マップに追加できるベンダー固有のコントロールのリストを表示できます。コントロールのリストは、選択したマップ・ベンダーによって異なります。リストからコントロールを選択してマップに表示します。マップからコントロールを削除するには、コントロールを再度選択します。

注意: 各コントロールの機能はマップ・ベンダーによって決定されます。

HEREマップ

構成可能なコントロール:

領域にズーム
概要マップ
距離の測定

ALKマップ

構成可能なコントロール:

マウス座標
概要マップ
ナビゲーション・ツールバー
ジオロケーション・ツールバー

ORACLE ELOCATIONマップ

構成可能なコントロール:

拡大領域
ツールバー

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - 画面セットでのマップ・ホバー・テキストの構成

画面セットのホバー・テキスト構成をマップ・ホバーとガント・ホバーで使用できるようになりました。これらの画面セットをワークベンチ・マップに割り当てるための新しいセクションが追加され、これを、ワークベント・レイアウトでマップ・リージョンを構成し、各オブジェクトで使用する画面セットを指定するときに使用します。ホバーにはデフォルトのコンテンツが含まれていますが(たとえば、出荷ホバーにはオーダー・リリース・データが表示される)が、オブジェクトのデータは画面セット構成に依存します。

各セクションに「デフォルト・ホバーの表示」チェック・ボックスがあります。このチェック・ボックスにより、マップ・ホバー・テキスト・ポップアップに表示されるデフォルト・フィールドが決まります。このチェック・ボックスはデフォルトで選択されています。デフォルトのホバー・フィールドを削除するには、このチェック・ボックスの選択を解除します。

有効化のステップ

マップ・ホバー・テキストにデフォルトで表示するフィールドを変更する場合は、「ホバー画面セット」セクションを展開します。

ホバー・テキストを変更する1つ以上のオブジェクトついて、ユーザー定義の画面セットを選択します。
- ホバー画面セットは、マップで「詳細ホバーの表示」アイコンをクリックしたときに表示されるホバー・ポップアップ・ウィンドウで、どのフィールドを表示するのかを制御します。
- 「ホバー画面セット」セクションで、マップ・コンポーネントでサポートされる様々なオブジェクトの画面セットを選択できます。
- 画面セットのホバー・ポップアップ・ウィンドウに表示されるフィールドを構成するには、「結果」タブで「詳細」ボタンを使用して、対象のフィールドの「ホバー・テキストに含む」オプションを選択します。

「ホバー画面セット」セクションは展開すると、次のようにグループ化されて表示されます。
- 出荷: 出荷関連のオブジェクトが含まれます。たとえば、運送サービスの買いや出荷ストップといったオブジェクトのほか、モデリング出荷やモデリング出荷ストップなどロジスティクス・ネットワーク・モデリング関連のオブジェクトが表示されます。
- オーダー: オーダー(移動)やオーダー・リリースなどのオーダー関連オブジェクトが含まれます。
- ドライバ: ドライバ・オブジェクトが含まれます。
- ネットワーク: ロケーション、ネットワーク・レグ、リージョン、リージョン詳細など、ネットワーク関連のオブジェクトが含まれます。

ワークベンチ・マップ - ワークベンチ・レイアウトでの複数マップのサポート

ワークベンチ・レイアウトで複数のマップ・リージョンを配置できるようになりました。ワークベンチ表の「マップに追加」機能を使用して、ワークベンチ・レイアウト内のすべてのマップにオブジェクトを追加できます。この機能をマップ・フィルタ機能と一緒に使用すると、複数のマップに別々のデータを表示できます。たとえば、出荷表内のすべての出荷をマップし、マップ・フィルタを使用して一方のマップにはTL出荷を、他方のマップにはLTL出荷を表示できます。

有効化のステップ

追加のマップ・リージョンを追加するには、以前のリリースの単一のマップ・リージョンを追加する際の手順に従います。

ワークベンチ・マップ - 外部距離エンジンおよびマップ - ストップ間のトラフィックの検討

以前の実装では、搬送元の出発時間のみをマップ・ベンダー(ALKまたはHERE)に提供し、履歴的なトラフィック状況に基づいてルートを計算していました。この変更により、ロジックですべてのストップの出発時間を予測して、ベンダーに渡せるようになります。

新しいロジック・パラメータとして、ストップごとのトラフィックを使用が追加され、ストップの各ペアで使用するトラフィックを制御できるようになりました。

各ストップごとではなく、履歴的なトラフィックを使用する方針の場合は、これまでどおり既存のトラフィックを使用を使用できます。

新しいパラメータをオンにすると、各ストップの計画出発時間が計算され、各ストップ・ペアの搬送元出発時間がベンダーに渡されます。たとえば、3つのストップA-B-Cが含まれている出荷には、A-BとB-Cの2つのストップ・ペアが含まれています。最初のペアについてはAの出発時間が渡され、2番目のペアについてはBの出発時間が渡されます。

トラフィックを使用とストップごとのトラフィックを使用の両方が有効になっている場合、ストップごとのトラフィックを使用が優先されます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ・マップ - ストップのペアごとに危険物を考慮

この機能によってワークベンチ・マップ機能が拡張され、出荷ストップのペアごとに危険物が考慮されます。以前のリリースでは、マルチストップ出荷が危険物を含む2ストップ出荷と同様にプロットされたため、結果のルーティングは最適なものではありませんでした。出荷上の最も危険性の高い品目によってルートが決定されていたためです。危険品目がストップ・ペアに実装されるため、各ストップ・ペアの危険品目に基づいてルートが計算されるようになります。

危険物が存在する場合、ストップ・ペア・レベルでルーティングが検討されます
危険品目は出荷ストップのペアに関連するものとして識別され、ルートの計算時にHEREまたはALKに渡されます。
危険物の存在はマップへのルート追加と運転方向の表示の両方に影響します。
合計距離と合計所要時間はルートのセグメントごとに計算されます。

有効化のステップ

これまで、マップ上の危険物の外部距離エンジン・パラメータの機能は、出荷上のストップ数を考慮していませんでした。この機能によって、出荷ストップのペアごとに危険物が考慮されるようになります。以前のリリースでは、マルチストップ出荷が危険物を含む2ストップ出荷と同様にプロットされたため、結果のルーティングは最適なものではありませんでした。出荷上の最も危険性の高い品目によってルートが決定されていたためです。危険品目がストップ・ペアに実装されるため、各ストップ・ペアの危険品目に基づいてルートが計算されるようになります。

危険物が存在する場合、ストップ・ペア・レベルでルーティングが検討されます
危険品目は出荷ストップのペアに関連するものとして識別され、ルートの計算時にHEREまたはALKに渡されます。
危険物の存在はマップへのルート追加と運転方向の表示の両方に影響します。
合計距離と合計所要時間はルートのセグメントごとに計算されます。

ワークベンチ・マップ - マップ上のズーム・レベルのロックおよびビューのロック

この機能により、ワークベンチ・マップ・ツールバーで2つの新しいロック機能を使用できるようになります。新しいロック機能では、マップ表示の使い勝手が向上し、ビューとズームをより直接的に制御できるようになります。

ズーム・レベルのロック

「ズーム・レベルのロック」アイコンをクリックして、マップのズーム・レベルをロックし、マップの現在のズーム表示を維持きます。

たとえば、起点と終点が米国の西海岸である出荷Aを選択して「ズーム・レベルのロック」アイコンをクリックすると、その出荷がズームされた状態でマップが固定されます。この後に、起点と終点が米国の東海岸である出荷Bを選択しても、マップの再描画は行われないため出荷Bは表示されません。マップは、起点と終点が米国西海岸である出荷Aにズームされた状態のままです。

マウスまたはマップ・コントロールを使用して手動でズーム・インまたはズーム・アウトすると、ズーム・レベル・アイコンのロックは自動的に解除されます。

ビューのロック

「ビューのロック」アイコンをクリックしてマップ上の現在の項目を維持できます。ロック後、出荷やオーダー・リリースを追加するために別のオブジェクトをクリックしても、マップの表示は変わりません。

マップが2つある場合に出荷をマップに追加して、その状態でマップをロックできるので便利です。1つのマップをロックした状態で、2つ目の出荷を別のマップに追加できます。

有効化のステップ

デフォルトで「ズーム・レベルのロック」アイコンはロック解除の状態です。「ズーム・レベルのロック」アイコンをクリックしてマップをロックすると、ロック状態としてアイコンが表示されます。

「ズーム・レベルのロック」アイコンをクリックして、マップのズーム・レベルをロックし、マップの現在のズーム表示を維持きます。

たとえば、起点と終点が米国の西海岸である出荷Aを選択して「ズーム・レベルのロック」アイコンをクリックすると、その出荷がズームされた状態でマップが固定されます。

この後に、起点と終点が米国の東海岸である出荷Bを選択しても、マップの再描画は行われないため出荷Bは表示されません。マップは、起点と終点が米国西海岸である出荷Aにズームされた状態のままです。

マウスまたはマップ・コントロールを使用して手動でズーム・インまたはズーム・アウトすると、ズーム・レベル・アイコンのロックは自動的に解除されます。

ワークベンチ・マップ - HEREでサポートされる追加のパラメータ

HEREパラメータが追加され、HEREワークベンチ・マップで利用できるようになりました。

BOAT_FERRIES

0 - 標準
1 - 回避
2 - 寛容な除外
3 - 厳格な除外

MOTORWAYS

自動車道路で-2を指定した場合、自動車道路を回避できるルートがあればOTMのルート計算で自動車道路(高速)が除外されます。回避できない場合は、自動車道路を含めてルートが計算されます。

有効な値は次のとおりです。
- 0 - 標準
- -1 - 回避
- -2 - 寛容な除外
- -3 - 厳格な除外

TUNNELS

0 - 標準
1 - 回避
2 - 寛容な除外
3 - 厳格な除外

RAIL_FERRIES

0 - 標準
1 - 回避
2 - 寛容な除外
3 - 厳格な除外

DIRT_ROAD

0 - 標準
1 - 回避
2 - 寛容な除外
3 - 厳格な除外

FIXED_LIMITED_WEIGHT

設定されている場合、OTM出荷計算ではなく、この重量が使用されます。
値はトン単位で入力する必要があります。
たとえば出荷制限が8トンの場合、パラメータを8に設定する必要があります。

TUNNEL_CATEGORY

トラック・ルーティングの場合、トンネルのカテゴリを指定してルート・リンクを制限します。ルートは低い厳格カテゴリのトンネルのみを通過するようになります。

ルート・エンジンの計算でトンネル・カテゴリの値を考慮するには、HAZMAT_ROUTINGパラメータをYに設定する必要があります。HAZMAT_ROUTINGパラメータの詳細も参照してください。

有効な値は、B、C、DおよびEで、Bが最も制限の少ないカテゴリです。

EQUIPMENT_RESTRICTIONS

これは番地レベルのルーティングを確実に行うために使用します。
OTMからEDEに機材寸法(長さ、幅、高さ)を送信する必要があります。
番地レベルのルーティングでは、トンネルの高さや高さ制限、橋の重量制限など、正しい寸法が必要になります。
機材寸法には、合計の機材の長さ、幅および高さが含まれます。使用するには、これをY (オン)に設定する必要があります。
パラメータをN (デフォルト)に設定すると、制限は使用されません。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ・マップ - ALK鉄道ルート

新しい「マップ出荷明細スタイル」を鉄道で使用できるようになりました。鉄道が指定されている出荷に鉄道関連の詳細が不備なく指定されていて、ALK Railが正しく構成されている場合、すべての鉄道出荷の実際の鉄道ルートがマップに表示されます。

鉄道はALKでのみ使用されます。ALK RAILには別途ライセンスが必要です。
ALKの鉄道ルーティングAPIがコールされるのは、鉄道モードの明細スタイルに「鉄道」が設定されている場合のみです。

鉄道出荷をプロットするには、各ストップ・ロケーションの次のパラメータをALKのAPIに渡す必要があります。

書式 - ステーションの書式タイプ
名前 - ステーション名またはコード
鉄道 - 標準運送業者の英字コード

次に、前述のパラメータと対応するOTMオブジェクトのマッピングを示します。このオブジェクトから値を取得できます。

鉄道 = 「運送サービスの買い」→「モード」→「航空/鉄道輸送経路コード」→「鉄道輸送経路コード ID」→「運送業者SCAC」(順序のリストから)
- 鉄道輸送経路コードに「鉄道連絡コード」を持つ順序が複数ある場合、すべての中間連絡を使用して、ストップ・ロケーション間のルートが取得されます。
- 鉄道連絡運送業者SCACコードは、次の順序のSCACコードから取得されます。
書式 = ALKは5つのパラメータを取りますが、OTMは次の4つのパラメータをサポートします。
名前 = OTMオブジェクトから取得される実際の値。

書式	摘要	OTMオブジェクト値	備考
1	SPLC 9桁の数字の標準ポイント・ロケーション・コード	ロケーション -> 鉄道SPLC	実際の9桁の必須値の最後に必須のゼロを追加します。
2	FSAC	サポートされていません。
3	StationStateステーション名と都道府県の略称	ロケーション -> 鉄道駅コード ->鉄道駅コード、州/都道府県コード	鉄道駅コード、州/都道府県コード
4	ERPC ERPCまたは3-3-3英字コードと都道府県の略称(スペースまたはカンマ区切り)	ロケーション -> ERPC	これは古い書式であり、ほとんど使用されません。これは、SPLCまたはSTATIONの代替になります。
5	ルール260連絡コード連絡の5文字の英字コード	ロケーション -> 鉄道連絡コード	連絡にのみ使用します。RAILマーカーを使用してストップと区別します。

1つのロケーションに複数の書式値を使用できる場合があります。その場合の書式値の優先順位は、そのロケーションのロケーション・ロールによって決まります。

ロケーション・ロール = 出荷元/出荷先
- 鉄道SPLCまたは鉄道駅コード(鉄道駅コード、州/都道府県コード)またはERPC
ロケーション・ロール = 鉄道連絡
- 鉄道連絡コード

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ・マップ - ALKでサポートされる追加のパラメータ

新しいパラメータが2つ追加され、ALKを使用したワークベンチへの出荷のマッピングを向上できます。

FERRY_DISCOURAGE

ルートの作成時にフェリーの使用を敬遠するかどうかを示します。デフォルト: false

ELEVATION_LIMIT

ルートを生成するときの高さ制限を示します。
高さ制限の単位はメーターまたはフィートのいずれかで、距離単位パラメータにより決定されます。マイル = フィート、キロメートル = メートル
制限を考慮したルーティングが現実的でない、またはストップの高さが制限を上回る場合、この制限は無視されます。
デフォルトはnullです。

EQUIPMENT_RESTRICTIONS

これは番地レベルのルーティングを確実に行うために使用します。
OTMからEDEに機材寸法(長さ、幅、高さ)を送信する必要があります。
番地レベルのルーティングでは、トンネルの高さや高さ制限、橋の重量制限など、正しい寸法が必要になります。
機材寸法には、合計の機材の長さ、幅および高さが含まれます。使用するには、これをY (オン)に設定する必要があります。
パラメータをN (デフォルト)に設定すると、制限は使用されません。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ・マップ - マップ・フィルタ

マップ・フィルタ・ホバー・ポップアップで基準を指定し、マップに表示するオブジェクトを制限できます。フィルタで制限できるオブジェクトは、出荷、モデリング・シナリオ、またはその両方の組合せです。

出荷とシナリオをマップ上でフィルタ処理できます。たとえば、運送サービスの買い表に表示されているすべての出荷をマッピングした後、マップ・フィルタを使用してマップに表示される出荷を制御できます(例: LTLの輸送モードを選択すると、LTL出荷のみがマップに表示されます)。

出荷のフィルタ基準:

輸送モード
サービス・プロバイダ
機材グループ
レート・オファリング
合計重量 - 低/高値の間
合計容積 - 低/高値の間
出荷ユニット合計数 - 低/高値の間
ストップ数 - 低/高値の間

シナリオのフィルタ基準:

モデリング・シナリオID
シナリオ名
シナリオ番号

ワークベンチ・レイアウト・ツールバーにも、マップ・フィルタの管理機能があります(同じアイコンを使用)。

これを使用してレイアウト・フィルタを作成、編集または削除できます。

マップ・フィルタを保存すると、ワークベンチ・レイアウトにマップを追加したり、既存のマップ・リージョンを編集したりするときに、それらをマップに割り当てることができます。マップにマップ・フィルタが割り当てられている場合、ワークベンチ・レイアウトを開いたときにマッピング基準が自動的に適用されます。

有効化のステップ

ワークベンチ・レイアウト内でマップ・フィルタを使用するには、次の手順に従います。

「運送サービスの買い」または「モデリング・シナリオ」表とマップが含まれている既存のレイアウトを選択します。

マップ・ツールバーの(マップ・フィルタ)アイコンをクリックします。

ポップアップ内で、オブジェクトのマッピングを制限するための基準を選択します。たとえば重量範囲を指定して、特定の重量の出荷のみを表示できます。

「適用」ボタンをクリックします。

マップがリフレッシュされ、指定した基準を満たすオブジェクトのみが表示されます。「出荷 # / #」のセクションがリフレッシュされ、マッピング基準を満たす出荷の件数が表示されます。

「モデリング・シナリオ」セクションもリフレッシュされます。

外部距離エンジンと外部サービス・エンジンでの機材制限の考慮

この拡張では、機材を一般的な特性に基づいて分類するためのツールが提供されます。これにより、OTMで外部寸法および重量を正しく計算できるようになります。重要な要素としては、トラクタを含める必要があるかどうか(トレーラが必要とする場合)や、天井の有無を考慮した寸法計算、機材の突出可否などがあります。各外部エンジンにそれぞれ異なる属性をAPIの情報で渡す必要があるため、マッピング機能を追加する作業が必要でした。

最初のステップは、トラック・タイプの機材グループの属性を指定することです。これはトラック機材にのみ該当する作業で、一定の特性に基づいて機材の一般的なタイプを分類することが目的です。トレーラ・タイプは特性(天井タイプなど)のドロップ・ダウンで、ユーザー自身で構成することはできません。これらの値はコードの内部で使用されるもので、ユーザーが定義することはできません。一般に、すべての機材はこれらのカテゴリに分類されます。

ユーザーは独自のトラック・タイプを作成して、関連する属性を定義できます。これは、機材グループの定義にも役立ちます。

トレーラ・タイプは、機材の様々な一般的な組合せを示すために使用します。これは主に、トラクタを含めた車両の長さを計算するときに使用されます。

自走式はモーター付きの車両です。これはトレーラではありません。トラクタを必要としません。
セミトレーラはキングピンと後車軸のあるトレーラです。このトレーラを牽引するには、第5輪ヒッチを持つ機材が必要です。
ポニー・トレーラにはバンパー型ヒッチがある牽引車両が必要です。
ドローバー・トレーラは前方キング・ピンの下に回転するヒッチ付きの機材があるトレーラで、一般にドリーと呼ばれています。また、バンパー型のヒッチを必要とします。
Bトレイン・リーダーは独特なセミトレーラで、第5輪ヒッチのある後部拡張があるため別のトレーラを牽引できます。
ヒトコブラクダは、キャブと第5輪ヒッチの間に貨物を乗せるスペースのあるトラクタです。また、貨物を積むこともできます。

これらの各機材タイプは、天井の有無や機材からはみ出る貨物を積載できるかどうかで分類できます。

天井タイプは、高さを正しく計算するための特性を記述するために使用します。

クローズ - これにより高さが機材グループに設定されている外部高さに固定されます。
平台型 -貨物エリアに高さがなく、貨物の最大高さに階床高さを加えて外部高さが決定されます。
オープン・トップ - 側面の高さがある機材で、平台と側面高さに基づいた計算があります。外部の高さには最大値が使用されます。

突出許可は、定義されている基本の機材からの貨物の突出が許可されることを意味します。

トラック・タイプ表

牽引長さ

機材(自走式を除く)の長さは、機材の実際の長さを表すものではありません。HEREは合計の長さを、ALKはトレーラの長さを必要とします。機材の長さは簡単ですが、合計の長さを求めることは簡単ではありません。キング・ピンと第5輪は重複する部分があり、そのため牽引長さの定義にも重複が生じます。

パワー・ユニットに重要な属性が2つ追加されました。風袋重量と牽引長さです。

使用するトラクタは、使用するパワー・ユニットとして、長さ計算用のデフォルト・パワー・ユニット・パラメータとともに構成してください

牽引長さ

EDEマッピング

ベンダーによって属性に対するアプローチは異なるため、EDEおよびESEで"汎用的なAPI"という概念を実現することは不可能です。確実な接続を提供するためには、マッピング表を用意する必要がありました。「車両タイプ」列はオラクルの内部列です。あるベンダーはこれを車両タイプと呼び、また別のベンダーはこれをモードと呼んでいます。マッピングは内部で行われます。この表によりユーザーは、EDEへの入力用として車両のカテゴリを指定できるようになります。重量と組み合せた場合、ベンダー・ソフトウェアは車両に対して別の速度を求めます。これは、非常に重要な考慮事項です。

トラック・タイプEDEマッピング

幅の計算

長さの計算

コンボの長さの計算

ヒトコブラクダの長さの計算

高さの計算

走行寸法はストップ間で変化するためストップ・レベルで維持されます。EDEはストップ間の距離に対してコールされ、そのストップ間の走行寸法および重量がEDEで使用されます。

走行寸法の維持

有効化のステップ

この機能を構成するには、いくつかの作業が必要になります。

外部エンジンの「機材制限」が「Y」に設定されているとロジックが呼び出されます。

最初に2つの表を構成する必要があります。

トラック・タイプ: 車両の特性を定義します。
トラック・タイプ外部距離エンジン・マッピング - これを使用して、トラック・タイプをエンジンが認識可能な値に変換します。

適切なデータを使用して機材グループを構成する必要があります。

トラック・タイプ
牽引長さ
風袋重量
外部寸法
階床高さ

自社の標準トラクタまたはパワー・ユニットをパラメータとともに選択する必要があります。

パワー・ユニットには風袋重量と牽引長さが必要です

輸送運用プランニング

クラスタ・マージ・アルゴリズム

この機能で提供される混載アルゴリズム(クラスタ・マージ)を使用して、ストップ数の多い出荷をすばやく生成できます。クラスタ・マージ・アルゴリズムではスイープ方法を使用して、共通の搬送元を中心に広がる放射状エリアをスライスし、マルチストップ出荷を生成します。

クラスタ・マージ・アルゴリズムは次のようなシナリオに適しています。

1回の集荷と多数の搬送ストップがある
単一の機材グループの容量で混載が制限される

クラスタ・マージ・アルゴリズムの概要

クラスタの作成(スイープ・アルゴリズムを使用)
- 1つの集荷場所から最初のスイープ角度を決定します。
- 機材容量を使い切るまで、クラスタ化されていない直接出荷を時計回りにスイープします。
- スイープした直接出荷を使用してクラスタを作成します。
- すべての直接出荷がクラスタに入るまで続行します。

混載出荷の作成
- クラスタ内の直接出荷から1つの出荷(単一集荷/複数荷降)を作成します。
- ストップの順序付けを行います。
- 実現可能性を判定します。
- 実現可能でない場合は、フォールバック混載アルゴリズムを使用してクラスタ内の直接出荷を連結します。

クラスタ化 - 各クラスタ内の出荷

有効化のステップ

「マルチストップ混載アルゴリズム・タイプ」を「7.クラスタ・マージ」に設定します。
- 「マルチストップ混載アルゴリズム・タイプ」オプションは、「ロジック構成タイプ」 = マルチストップ混載グループ内の「マルチストップ」にあります。

フォールバック混載
- フォールバックとして使用される混載アルゴリズムは、新しいプロパティであるglog.business.consolidation.multistop.fallbackMergeAlgorithmによって決定されます。
- デフォルトで、これは「0」(同時削減)に設定されています。もう1つのオプションは「1」(連続削減)です。

ヒントと考慮事項

クラスタ・マージ・アルゴリズムの目的は、次の条件が存在する場合のアウトバウンドのルーティングとスケジューリング問題を解決することにあります。

計画する出荷が1つの集荷ロケーションから発生する。

類似する商品(飲料やビールのケースなど)を出荷する場合で、重量、容積、ERUのいずれかを考慮して機材を満載することに基づいて完全出荷の定義を決める場合(ドライバのサービス時間上限(HOS)の到達で制約したり、完了と見なしたりしない)。

ストップ密度が高く、作成される出荷が現地/地域の出荷(当日中に集荷と搬送のアクティビティが完了する)になると見込まれる場合。

このバージョンでは、次のようになります。

最初のスイープ角度は真南(6時)です。
機材容量は使用可能な最小能機材グループから決定されます。
機材容量の重量、容積およびERUがチェックされます。アルゴリズムで機材容量を決定するときに、積荷構成ロジックは使用されません。

フォールバック混載

クラスタに対して1つの出荷を混載ロジックで作成できない場合があります(クラスタ化失敗)。この場合は、フォールバック混載アルゴリズムを使用してクラスタの出荷を作成します。(多くの場合、このフォールバック・アルゴリズムはクラスタに対して複数の出荷を作成します。)

フォールバックとして使用される混載アルゴリズムでは、次の新しいプロパティによって決定されます。
- glog.business.consolidation.multistop.fallbackMergeAlgorithm

デフォルトで、これは「0」(同時削減)に設定されています。もう1つのオプションは「1」(連続削減)です。

注意: クラスタ・マージ・アルゴリズムは、クラスタ化の失敗が発生しにくいシナリオで使用することをお薦めします。

クラスタ・マージ特有の考慮事項/使用条件

クラスタ・マージは、1つの搬送元と複数の搬送先があるシナリオのみをサポートしています。

クラスタ・マージは、様々な機材グループの容量によって混載の決定が左右されるケースでは使用できません。

クラスタ・マージでは機材容量の決定に積荷構成ロジックが使用されません。

クラスタ・マージでは、混載ステップ中のサービス時間をチェックせず、完全出荷を機材容量(重量、容積およびERU)に基づいて判断します。

クラスタ・マージでは、次の制約によってオーダー混載が実現不可にならないことを前提としています。
- 時間ウィンドウの制約
- 商品制約
- オーダー制約(サービス・プロバイダ、機材グループなど)や、その他の容量以外の制約。

クラスタ・マージではオーダー優先度は考慮されません。

同一場所ストップのマルチストップ混載

この機能により、OTMのプランニング・ロジックに同一場所ストップ(オフィス・ビルやモール、大学など、互いに隣接するロケーション)を認識させ、それらのストップをまとめてプランニングすることで、特定された同一場所ストップに対して1台のトラック/出荷でサービスを行うことができます。

マルチストップ・ロジックが強化され、近接する集荷ストップや搬送ストップを認識して連結できるようになり、エリア内で複数の出荷サービスが発生することを回避できます。エリアは半径で定義され、半径を小さくすることが目的です。同一場所ストップの例としては、棟内に複数のストップがある大きなビル、複数のIDが存在する1つのロケーション、互いに近接するロケーションなどです。この機能が実行される可能性のある経済性よりもビジネス・ルールのほうが優先されます。すべてのレートがこの方針をサポートするとはかぎらないためです。このプロセスの目的はマルチストップの「初回通過」のような動作です。

同一場所の例

準拠するビジネス・ルール

複数の出荷により、同じロケーションまたは近接するロケーションに繰り返し訪問することを回避します。
できるかぎり、1つの出荷ですべての作業を処理できるようにします。
同一場所として定義されたロケーションからの集荷または配送を対象とします。

次に例を示します。

出荷エリアが1つである大規模な建物または複合施設。
- 同じまたは似たような住所を持つ複数のテナント
- 複数のIDを持つ同一の会社
定義した狭い半径内にあるロケーション。
- 番地全体
- 隣家
地方エリア ? 半径が大きくなる可能性あります。
- 同一村内のロケーションを取得
できるだけ小さくなるように半径が定義されます。
- 市街地と地方の例を考えること
- 半径が大きくなりすぎないようにすること

市街地の同一場所の例

有効化のステップ

この機能を使用するには、同一場所ストップ間の最大距離パラメータの値を指定します。これは、「ロジック構成タイプ」 = 「一般」グループ内の「マルチストップ」にあります。このパラメータのデフォルト値は0で、この場合、同一場所マルチストップ・ロジックは使用されません。

このパラメータでは、同一場所と見なす2つのロケーション間の最大距離を指定します。

まず、同一場所ストップを使用して入力出荷をグループ化し、グループとしてのマルチストップ混載を実行します。この手順では、同一場所ストップを使用して入力出荷のグループを作成します。これを可能にするために、マルチストップ・ロジックに同一場所ストップ間の最大距離パラメータが導入されます。

このパラメータの値が1マイルに設定されている場合、出荷1 (S1-> D1)および出荷2 (S2 -> D2)は、次の2つの条件のいずれかに当てはまる場合に同じグループの所属になります。
- S1とS2の間の距離が1マイル未満で、D1とD2の距離が1マイル未満
- S1とD2の間の距離が1マイル未満で、D1とS2の距離が1マイル未満

同一場所ストップを順序にグループ化します。ここでも、同一場所ストップ間の最大距離パラメータの値に基づいて、同一場所ストップがグループ化されます。次の2つのオプションを使用して、同一場所ストップが連続するストップ順序を生成できます。
- 複数の同一場所ストップ・グループを1つのストップとして扱い、新しいストップ順序を生成します。
- 互いに近接する同一場所ストップを現在の順序に移動して、新しいストップ順序を生成します。

ヒントと考慮事項

これはクラスタ化メカニズムではありません。小さな半径を作ることを目的としています。

距離の計算にはLATとLONを使用することをお薦めします。ロケーションのLATとLONを検証してください。郵便番号のLATとLONを使用しないように注意してください。

積荷構成 - スコアリング・アルゴリズム耐荷力

この拡張により、3Dスコアリング・メカニズム・プロセスで使用される"先読み"プロセスで、貨物の耐荷力が考慮されるようになります。新しい基準が追加され、OTMで強(耐荷重量の大きい)の貨物を積み上げ層に、弱(耐荷重量の小さい)の貨物を最上層に配置できるようになります。この目的は、スペースの断片化を減らすことにあります。

3D積荷構成で配置の組合せを評価するため、次の基準が導入されました。

断片化されたスペースが少なくなるように箱を置く: この基準により、分断化されたスペースが少なくなるように配置されるため、以降の配置への制約を少なくできます。

評価時の耐荷力の考慮: この基準により、耐荷重量の大きい強の出荷ユニットが積み上げ層に、耐荷重量の小さい弱の出荷ユニットが最上層に配置されるようになります。

次の新しい耐荷力パラメータを使用できます。

スペース非断片化のための最小重量基準: 整数 - デフォルト - 10
スペース非断片化のための最大重量基準: 整数 - デフォルト - 100
耐荷力の最小重量基準: 整数 - デフォルト - 10
耐荷力の最大重量基準: 整数 - デフォルト - 100

耐荷力の例

スコアリングが無効の場合

スコアリングを有効にし、新しいパラメータを使用した場合

有効化のステップ

3Dスコアリングの使用に関連するチューニング・パラメータは多数あります。この機能を有効にしてデフォルト設定を使用するには、3D配置のスコアリング・ロジックを考慮パラメータをTRUEに設定して3Dスコアリング機能を有効にする必要があります。このパラメータは、「ロジック構成タイプ」 = 「コンテナの最適化」のコンテナの最適化3Dスコアリンググループ内にあります。

ヒントと考慮事項

3Dスコアリングによる3Dベースの積荷構成には非常に高度な計画機能が使用されています。この機能の設定およびチューニングは、OTMのプランニング・ロジックに詳しいユーザーのみが実行するようにしてください。

サービス・プロバイダの複数日の容量を考慮

この機能により、別の日の容量制限容量の使用をOTMに考慮させることができます。この機能により、コストと優先度の観点から別の日の容量の使用を奨励するかどうかを指定できます。

容量制限のある安い運送業者の利点を享受しながら出荷の優先度(高、中、低)も尊重できるように、優先度と許容される遅延日数に基づいて出荷の遅延方針を設定できるようになりました。

新規パラメータ

SPA最大考慮日数
- 容量制限の影響を受ける各出荷について、OTMで何日間の開始日を追加で考慮するかを決定します。

SPA時間変更ポリシー
- (将来の)容量を利用するために、どのような方針で出荷開始日を変更するかを指定できます。
  - たとえば、レーン上でレートが最も安く、1日の容量がトラック1台分しかないサービス・プロバイダがあるとします。本日分の容量はすでに使い切っているのですが、もし容量が残っていたらその最低コストのサービス・プロバイダに割り当てたかった出荷がまだ残っています。今日の出荷の開始日を明日に変更して、明日の分の容量を使うことは有意義でしょうか。それとも、開始日を遅らせることで出荷タイミングの余裕時間がなくなり、サービス時間に重大な問題が発生する可能性はないでしょうか。
- SPA時間変更ポリシーで使用できるオプションは次のとおりです。
  - 3.時間変更の奨励
  - 2.高および中優先度出荷の時間変更の敬遠
  - 1.高優先度出荷の時間変更の敬遠
  - 0.時間変更の敬遠

有効化のステップ

容量制限ありでプランニグをすでに実施していると仮定します。別の日の容量を使用するように容量制限を拡張するには、「サービス・プロバイダ割当タイプ」グループにある次のパラメータを構成します。

SPA最大考慮日数
- 容量制限の影響を受ける各出荷について、OTMで何日間の開始日を追加で考慮するかを決定します。このパラメータはパフォーマンスに影響する恐れがあるため、必要以上に高い値を指定しないようにします。たとえば、2日で十分なリソースが得られる場合に、2より高い値を指定する理由はありません。
- デフォルトは「0」(ゼロ)です。詳細は、サービス・プロバイダ割当およびリソース管理のトピックと、サービス・プロバイダ割当時間ウィンドウ機能の項を参照してください。

SPA時間変更ポリシー
- このパラメータで優先度レベルを指定して、容量制限のある安いサービス・プロバイダを利用するために出荷開始日を遅らせるかどうかの判断基準を設定できます。たとえば、1日に1台のトラックしかない安い運送業者があるとします。出荷を遅らせて安いトラックを使用するのか、それとも、高いトラックを使用して今日出荷するのかの判断が必要になります。オプションは次のとおりです。
  - '0.時間変更の敬遠
  - '1.高優先度出荷の時間変更の敬遠
  - '2.高および中優先度出荷の時間変更の敬遠
  - '3.時間変更の奨励

ヒントと考慮事項

SPA最大考慮日数 - このパラメータはパフォーマンスに影響する恐れがあるため、必要以上に高い値を指定しないようにします。たとえば、2日で十分なリソースが得られる場合に、2より高い値を指定する理由はありません。

ネットワーク・ルーティングで中間ロケーションのロケーション非アクティブ・フラグを考慮

この機能により、glog.business.location.inactiveLocationSettingプロパティを使用してOTMを構成し、非アクティブ(アクティブ・フラグが選択されていない)のロケーションを、ネットワーク・ルーティングが有効な場合は中間ロケーション(クロスドック)として使用されるのを回避できるほか、オーダー・ルーティング方法に関係なく任意の経由ポイント(積荷港または荷揚港)として使用されるのを回避できます。

有効化のステップ

glog.business.location.inactiveLocationSettingのプロパティ設定

0 (アップグレード後のデフォルト): 非アクティブなロケーションが通過ポイント/経由ポイントとして使用されます。

1 (新規クライアントのデフォルト): 非アクティブなロケーションは、ネットワーク・ルーティングの通過ポイントとして、または経由ポイント(ネットワーク・ルーティングまたは原価ベース・ルーティング)として使用されません。
- glog.base.propertiesのデフォルト値は1です(非アクティブなロケーションは、ネットワーク・ルーティング他で通過ポイントとして使用されません)。

既存のクライアントの場合、glog.business.location.inactiveLocationSettingを1に設定することで新しい機能を利用できます。

ヒントと考慮事項

ロケーション非アクティブの尊重フラグはオーダー・ルーティング方法がネットワーク・ルーティングの場合にのみ機能します。この機能は、オーダー・ルーティング方法として原価ベース・ルーティングを使用している場合はサポートされず、レガシーのプール-XDockロジックを使用している場合も機能しません。

ルール11およびネットワーク・ルーティング

この機能により、ネットワーク・ルーティングでルール11プランニングをサポートするようにOTMを構成できます。これには、バルク・プランニング、RIQのネットワーク・レートおよびルートおよびネットワーク・ルーティング・オプションの表示が含まれます。

ルール11は、マルチレグ輸送行程の連続するレグについて、どのような鉄道輸送出荷を(どの鉄道運送業者に対し)作成できるかを制御します。鉄道出荷が特定のレート・レコードを持つ鉄道ハブに到着した場合、そのハブから発生する後続の鉄道出荷で使用できるレート・コードはコンボ・ルート・コードの構成とレートの以遠フラグによって制限されます。つまり連続的な鉄道出荷では、レート・レコードの"連結"は特定の組合せに限定されます。コンボ・ルート・コードは、その連絡に運送業者間の有効な交換が存在することを意味しています。レート・レコードにはルート・コードと「出荷先(以遠)」および「出荷元(以遠)」フラグが含まれています。これは、そのレートを、輸送行程内の他のレートと組み合せて使用できることを意味しています。ロジックでは、ハブに入るレートで「出荷先(以遠)」フラグが選択され、ハブを出るレートで「出荷元(以遠)」フラグが選択されているかをチェックします。連結できるレート・レコードは、ROUTE_CODE_COMBINATION表とROUTE_CODE_COMBINATION_D表("コンボ表")で指定します。

ルール11の例

ネットワーク・ルーティング・ロジックのルール11ルート・コード・ロジックにより、有効なレートの組合せのみを連絡間で許可するためのチェック機能が提供されます。このチェックを行わないと、最も安価な組合せを優先する通常のルーティング・ロジックと同じ動作になります。また、依頼に必要な組合せルート・コードが各出荷に割り当てられます。ルール11では、最初の出荷のみが依頼されますが、決済には両方が必要になります。

各出荷が有効な出荷になるようにチェックされるルール11の出荷属性。

ルート・コード。
- 現地 - 各出荷にレート・レコードからのルート・コードが必要です。
- コンボ ? ルール11のすべての出荷で同じである必要があります。
参照番号
- BM ?船荷証券番号 - 同じオーダーのすべてのルール11出荷で同じである必要があります。
- 次のルール11出荷
- 前のルール11出荷
依頼インストラクション
- 各出荷には出荷の作成に使用されたレグと一致する依頼インストラクションがあります。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

ルール11ロジックはプランニング・ロジックに組み込まれており、必要な条件下でのみ呼び出されます。このロジックは以前よりネットワーク・プロセス以外のプロセスにはありましたが、出荷の作成とネットワーク・レートおよびルートRIQ用にネットワーク・ルーティング・プロセスにも追加されました。

NR R&R RIQの場合、ネットワーク・ルーティング用に輸送行程を構成する必要はありません。

また、NR R&R RIQでは、NRロジックを含むPPSを指定する必要がありません。出荷作成処理のSNROと同じように、NR R&R RIQを選択すると自動的にNRロジックが呼び出されます。

追跡イベントETAに基づく先行/遅延の計算

出荷の進捗に伴い、ETA(予測到着時間)が変更されることがあります。この情報は管理上の重要な情報です。この拡張は、追跡イベント・エージェントが外部システムから提供されるイベントをリスニングする状況での使用を意図しています。これらのイベントから提供されるETAは計画到着時間と比較されます。この差とユーザーが設定した基準に基づき、遅延の程度に応じて追跡イベント・インジケータの色を設定できます。標準ワークフロー・ロジックを使用して、必要に応じて通知も送信できます。

この機能では、ETAに基づく追跡イベントの先行/遅延計算に基づいてインジケータを設定できます。

この拡張では保存済問合せがサンプル・エージェントのコンテキストで提供されます。このエージェントは到着の遅延の程度に応じて追跡イベント・インジケータの色を設定します。

先行/遅延の概念が導入されます。

出荷を計画すると、計画到着時間が設定されます。

出荷が進捗すると、ルートの特定の地点でベンダーからイベント・データが提供されます。

イベント・コード、ロケーション、時間別に各イベントのレコードを提供します。
ETA(予測到着時間)も提供します。

各イベントからのETAと計画到着時間を基に遅延の程度を判断する基準を設定し、追跡イベントのインジケータに視覚的に設定(赤、黄、緑)する場合があります。

特定の基準が満たされたときに通知を送信します。

構成と設定

ETAと一致するストップを検索するための基準
- イベントで提供される情報に基づく - 必須 - 常に提供される - 車両搬送先。
- ルール11内の1つの出荷のみが、同じSPLCコードを共有するストップを持ちます。
  - 標準ルール11照合では船荷証券番号が使用されます。
  - 車両搬送先を含む出荷は1つのみです。

ルール11マルチレグ出荷のセットの先行または遅延

ETA時間は車搬送先に基づいて渡されます。

イベント・データには常に車両搬送先のSPLCが含まれています(195249)。

エージェント変数: 車両搬送先の計画到着時間をフェッチします。

次の基づきます。1)共通参照番号、2)車両搬送先SPLC - 1つの出荷上の1つのストップのみが一致します。

"先行/遅延時間"を計算し、インジケータを設定します。

この拡張ではサンプル・エージェントが提供されます。このエージェントにはエージェント処理と関連する保存済問合せが含まれています。これをテンプレートとして独自のエージェントを作成し、次のステップを追加します。次のロジックを使用してエージェントを構成します。

$SHIPMENT_PLANNED_ARRIVAL_TIMEのエージェント変数を割り当てます。
- SQLがその時間を関連付けられている出荷からフェッチします。
エージェント変数$CAR_DEST_ETAを割り当てます。
- SQLがその時間を追跡イベントからフェッチします。
保存済条件を使用してIF文を作成します。
- 保存済条件を使用して、先行/遅延時間条件を判別します。
エージェント処理を使用してインジケータの色を設定します。
IF/ELSEロジックを実行して、3つすべての色を設定します。

先行/遅延の結果

これが構成のエージェント・タイプである理由は、ユーザーが任意の数(3件に制限されることなく)のカテゴリに基準を設定できるためです。次に、IF/ELSEロジックを通じて通知を送信したり、重要度やイベント・ステータス値に応じて出荷インジケータや追跡イベント・インジケータを設定するように、エージェントを構成できます。

有効化のステップ

インジケータの色を設定するエージェント・ロジック

$SHIPMENT_PLANNED_ARRIVAL_TIMEのエージェント変数を割り当てます。
SQLがその時間を関連付けられている出荷からフェッチします。
エージェント変数$CAR_DEST_ETAを割り当てます。
SQLがその時間を追跡イベントからフェッチします。
保存済条件を使用してIF文を作成します。
保存済条件を使用して、先行/遅延時間条件を判別します。
エージェント処理を使用してインジケータの色を設定します。
IF/ELSEロジックを実行して、3つすべての色を設定します。
通知の基準も設定します。

必要に応じて、この一連の処理を他のエージェントに追加できます。

ヒントと考慮事項

ベンダーがETAを提供します。

現在、鉄道にはSPLCを使用するように設定されています。

これはユーザー自身で構築することを目的としています。ユーザーが遅延の深刻性の基準や通知のレベルを独自に指定できます。

ネットワーク・ルーティング内でレーティングをオフにする機能

この機能で提供されるネットワーク・ルーティング・ロジック・パラメータ(ROUTING SOLUTION METHOD)を使用すると、ネットワーク・ルーティング・ロジックのレベルを指定してネットワーク・ルーティングの問題を解決できます。シナリオに合わせてネットワーク・ルーティング・ロジックを構成できるため、完全なネットワーク・ルーティング最適化が必要とされないルート最適化(ネットワーク内のパスを決定する)でシナリオの実行時間を短縮できます。このパラメータを効果的に使用できる例としては、バルク・プラン計画でネットワーク・ルーティング・ロジックを使用するけれども、ネットワーク・ルーティングの決定は行わない場合です。たとえば、単一のレグ・ネットワークで作業割当ロジックを使用するようなケースです。

ネットワーク・ルーティング・ロジックの「ルーティング解決方法」パラメータの値は、次の3つのいずれかです。

最適化(デフォルト): ネットワークを評価し、ネットワーク・ルーティング最適化を行います。

レートを含む単純解決 - ネットワークを評価しますが、最適化は行いません。

レートを含まない単純解決 - ネットワークを評価せず、最適化も行いません。ロジックによって各NRLegに1つのNRLegOptionが作成されます。コンテナ・コストは1またはレグ見積コスト(ある場合)です。

有効化のステップ

デフォルトで、「ルーティング解決方法」は「最適化」に設定されています。

別の値を選択する場合は、次を実行します。

「ロジック構成タイプ」 = 「ネットワーク・ルーティング」に移動します。
「一般」グループで「ルーティング解決方法」パラメータ」を見つけます。
次のいずれかのオプションを選択します。

最適化(デフォルト)
レートを含む単純解決
レートを含まない単純解決

範囲を超える重心のレポーティング

この機能により、重心に関連して範囲外の状況が発生したときに通知を生成できます。この評価と通知には、3-D積荷構成とEVALUATE CENTER OF GRAVITYエージェント処理が使用されます。

出荷ユニットの長さ、幅、高さおよび座標情報に基づいて、EVALUATE CENTER OF GRAVITYエージェントは次の処理を実行します(構成されている場合)。

貨物の各軸の重心値をs_equipment(3-Dが永続化した場所)から読み取ります。
ユーザーがEVALUATE CENTER OF GRAVITYエージェント処理を構成したときに設定したしきい値に基づいて、通知が送信されます。

この処理はIF文の動作と似ています。重心が定義したしきい値を超えた場合にのみ、子の処理がトリガーされます。

EVALUATE CENTER OF GRAVITYエージェント処理のしきい値は次のとおりです。

中心から機材背面までのオフセットしきい値(z軸方向)
中心から機材前面までのオフセットしきい値(z軸方向)
中心から機材右側面までのオフセットしきい値(x軸方向)
中心から機材左側面までのオフセットしきい値(x軸方向)
許容される地表レベルからの最大高さ(y軸方向)
許容される最小高さ(y軸方向)
重量稼動ファクタ(0-1)

稼動ファクタは、積み込み中の出荷で誤ってアラームが発生するのを防ぐために使用されます。梱包アルゴリズムでは積み込みを常に前面から開始するため、常に不均衡な状態が発生し、長さ側のしきい値に違反することになります。稼働ファクタを使用することで、完全出荷のみが通知の評価対象となります。

この拡張では、3-Dロジックで次のs_equipmentフィールドにデータが移入されます。

EVALUATE CENTER OF GRAVITYエージェントによってS_equipmentフィールドにデータが移入される

貨物の重心長さ
貨物の重心幅
貨物の重心高さ

有効化のステップ

3-D積荷構成を使用します。EVALUATE CENTER OF GRAVITYエージェント処理で必要な計算を実行するには、出荷の各出荷ユニットの長さ、幅、高さ、原点座標(左下隅の座標)が必要になります。この情報を指定するには、いずれかの3-D積荷構成エンジンを使用する必要があります。

エージェントを作成し、EVALUATE CENTER OF GRAVITYエージェント処理を構成します。EVALUATE CENTER OF GRAVITYパラメータ:
- 重量稼動ファクタ(0-1)
- 許容される最小高さ(y軸方向)
- 許容される地表レベルからの最大高さ(y軸方向)
- 中心から機材左側面までのオフセットしきい値(x軸方向)
- 中心から機材右側面までのオフセットしきい値(x軸方向)
- 中心から機材前面までのオフセットしきい値(z軸方向)
- 中心から機材背面までのオフセットしきい値(z軸方向)

ヒントと考慮事項

考慮事項

この拡張では"モーメント計算"を使用して、3-D積荷構成による貨物の配置に応じて貨物の重心(C of G)を判定します。標準の3-Dはこの情報をShipment-equipmentに入力します。エージェント処理が構成され、ユーザーは各軸の重心のしきい値を設定できます。これによりアラートが発生するので、出荷をレビューすることができます。

評価されるのは貨物の重心のみで、計算には3-D配置のみが使用されます。

この新機能は、機材容量の再利用が発生しないマルチストップ出荷を評価するときにも便利です。このソリューションは複数搬送の前に複数集荷が発生するシナリオをサポートします。重心ソリューションでは、集荷と搬送が途中で発生するマルチストップ・シナリオはサポートしません。重心機能をマルチストップ・シナリオで使用するときには、ストップの順序付けをやり直し、出荷の均衡を取ることができます。処理を実行して出荷の再梱包を行い、EVALUATE CENTER OF GRAVITYエージェントを再実行して重心を再計算できます。

重心計算のロジック(モーメントの計算方法)。

オブジェクトの左下隅に基づいて重心寸法を求めます。立方体の場合は各寸法の半分の値です。各立方体オブジェクトの重心が幾何中心にあると想定します。

機材グループの梱包エンベロープ/機材原点を基準とした、立方体の開始位置を求めます。

機材原点に基づいて、立方体の"調整後"重心を計算します。

各寸法について、重量の"加重平均"と対象軸の面までの距離の乗算を求めます。

合計重量で割った数が、その軸に対する相対的な重心点です。

機材の階床高さを使用して高さの重心を増加させます。

積み増しオーダー

この機能を使用すると、OTMのプランニング・ロジックを使用して、出荷の空き容量を指定の積み増しオーダーの商品で埋めることができます。構成した場合、プロセスは次の2つの手順で動作します。

ステップ1では、通常のオーダー(非積み増しオーダー)を考慮して最適な出荷が構築されます。
ステップ2では、指定の積み増しオーダーを使用して、ステップ1の後の残りの容量を埋めます。

積み増しオーダーはあらゆる業界に適用できる概念で、顧客の発注商品のプランニングが終了した後に、出荷元が商品を追加して出荷を積み増すまたは一杯にすることです。

たとえば、DIY小売業者に季節製品を提供する出荷元は、顧客のために計画した出荷容量を顧客のオーダーだけでは一杯にできない場合に、出荷に商品を追加することがあります。DIY小売業者が42パレットのブラック・マルチを注文し、44パレット分の容量の出荷を計画したとします。この場合、マルチの供給者には、小売業者から発注がなくても2パレットを追加して出荷を一杯にする、つまり積み増して、完全出荷にするという選択肢があります。

有効化のステップ

一般的な積み増しシナリオの設定

積み増しオーダーを作成する必要があります。積み増しオーダー・フラグが選択されているオーダー・リリースが積み増しオーダーです。

積み増しパスでコンテナ最適化マージを使用パラメータをTRUEにする必要があります。
- このパラメータは、マルチストップのロジック構成タイプの中の一般パラメータ・グループにあります。
- マルチストップ・ロジック・パラメータの積み増しパスでコンテナ最適化マージを使用は、積み増しパスの出荷混載で最適化マージ・アルゴリズムを使用するオプションを提供します。積み増しパスの最大の目的は、積み増しオーダーの貨物で出荷を埋めることで機材の使用効率を最大限高めることにあります。

港における積み増し

この機能は、トラックの法的な容量制限が出荷の途中で変わるために積み増しが発生する特殊なケースもサポートしています。このシナリオでは、出荷が開始する場所の道路の法的上限は40ユニットで、出荷の搬送先エリア(通常は港)の道路の法的容量制限が50ユニットです。このエリアにトラックが入ると使用可能な容量が10ユニット増え、積み増しが可能になります。この場合、出荷がこのエリアに入ったときに機材容量が増加することをOTMに認識させる必要があります。これは簡単で直感的な方法で実現できます。

前述の積み増しパスでコンテナ最適化マージを使用パラメータをTRUEに設定する必要があります。

関連する機材グループで、関連する機材グループの低い方の法的上限になるように容量上書きを構成し、機材グループの容量を容量が増加するエリアに関連付けられている高い方の容量上限に設定する必要があります。この例では、機材グループの容量上書きは10ユニットで、機材グループの容量は50ユニットになります。

この追加容量を積み増しプランニングで効果的に使用するには、積み増しパスで容量上書きを無視パラメータをTRUEに設定します。
- このパラメータは、マルチストップのロジック構成タイプの中の一般パラメータ・グループにあります。
- このパラメータを使用すると、プランニングのステップ2で重量容量上書きを無視できるため、積み増しオーダーを使用して指定の容量まで機材を埋めることができます。上書きを使用すると、本体オーダーの下限までの配置が可能になります。たとえば、海上レグで50,000 lbs、高速道路では40,000 lbsしか積めないコンテナの場合、機材容量は50,000 lbsとして構成します。このレグには40,000 lbsの上書きがあり、梱包が制限されます。この新しいパラメータはステップ2に対してのみ機能し、そのステップで容量を無視します。1つの機材を計画しているオーダーで本体オーダーで機材を埋められないときに、常に上書きが必要になるわけではありません。積み増しオーダーはこれを2つめのパスで行います。この状況が発生するのは、顧客が注文した商品ではトラックを一杯にできないことを認識していて、残りのスペースを埋めるための品目を指定する場合です。

ヒントと考慮事項

OTMは出荷ユニット全体を分割しますが、分割した個々の出荷ユニットをカウントできません。また、この機能は重量、容積、ERUに対してのみ機能します。この機能は、このリリースの3-D梱包では使用できません。

ゲージ外積載の作成

この機能により、定義されているベース機材より幅や長さの大きい積荷を梱包できます。古いソリューションはただ機材を拡張するだけで、積荷のゲージからの逸脱を測定できませんでした。この新しい機能により、サイズを超えるコンパートメントをトラックに積載し、積荷のバランスを取ることができます。

ゲージ外の図

3-D梱包は常に前面の左下隅から開始します。この点がすべての機材寸法の原点となります。負の座標は許可されていないため、すべてのコンパートメントがここから開始します。サイズを超えるコンパートメントを、機材を基準に中央に寄せるための調整ファクタが開発されました。

実行される別のステップがあります。この機能を使用する場合は、ユーザー定義パターンを作成することが推奨されます。積荷は大きな1つのアイテムである場合と、いくつかのアイテムの集合である場合があるからです。UDパターンを使用して積荷をコンパートメント内の中央に寄せたり、指定の位置に寄せたりできます。なぜこれが重要かというと、OOGの統計はコンパートメントではなく梱包されたアイテムが基準になるためです。これは、つまり、コンパートメント全体をアイテムで埋める必要がないことを意味します。OOGは何が梱包されているかに基づき、OOGはベース機材の寸法に基づきます。

OOG寸法はメモリーに保存され、EDEの計算に適用されます。

開始点の調整

例

調整済の積荷

長さの例

ゲージ外情報は、その他の走行情報とともにストップに永続化されます。

出荷ストップのゲージ外データ

有効化のステップ

この機能は3-Dに詳しいユーザーのみが使用するようにしてください。

平台型トレーラなど、最初に機材を定義する必要があります。これは、サイズを超える積荷は壁をはみ出すためです。

OTM梱包ロジックは常に梱包されるコンテナの境界を尊重するため、機材を超えるコンパートメントを提供する必要があります。これにより機材の幅を保存でき、突出部分を計算できるようになります。

2番目の注意点は、機材の原点(0,0,0)が共通の参照点になることです。機材よりもサイズが大きいコンパートメントを積載したとき、それらの左下隅が一致します。そのためOFFSETSを開発し、想定されるコンパートメントの配置を機材上で視覚化して表示できるようにしました。

3つ目の注意点は、梱包される積荷は常に左下隅から開始することです。UDパターンでは、積荷を別の位置(中央など)から開始できるようになります。

この結果、積荷を機材の中央に寄せることのできる積荷構成と機材セットアップの定義が可能となり、既存のOTM梱包パラダイムに違反しないで済みます。これは、この拡張に互換性を持たせるうえで重要です。

突出の量はその他の走行情報とともにストップに永続化されるようになります。

ヒントと考慮事項

構成する手順を確認してください。この機能を使用するには、3-Dに関する知識、機材設定およびユーザー定義パターンが必要です。

アイテムの突出を許可するだけでは駄目なのかという疑問もありましたが、そのような変更は3-Dの梱包境界ロジックに違反することになり、変更も簡単ではないというのが答えです。この方法は複雑ではありますが、非常に明快です。

ネットワーク・ルーティング - 通過ポイントでのオーダーの開始と終了を許可

これはネットワーク・ルーティングに対する拡張で、オーダーをノードまたはハブ・ポイントで開始また終了させることができます。これまでは並行レグが必要でした。新しいコードの利点は、X - Dockからのオーダーをレグ上の混載の一部と見なせることで、これはレグのコストに影響を与えます。組合せ重量が経済的な意思決定で考慮されるようになります。この拡張以前は、各レグからのオーダー(移動)がレグ混載グループに基づいて出荷作成で結合されるだけでした。これはまるで、2つの別々のNR問題を解決してOMを作成し、出荷作成ステージで組み合せるようなものでした。この拡張では設定が簡素化され、レグの実際の容量使用が認識されるため、より優れたソリューションが提供されます。

通過ポイントで開始する

これは、4つのレグがあるネットワーク詳細の例です。最後の1つは不要になります。

ネットワークの例

有効化のステップ

この機能は、ネットワークの構成を介して呼び出されます。この拡張以前は、ハブから開始またはハブで終了する別の独立した並行レグを設定する必要がありました。これは必要ではなくなりました。

ヒントと考慮事項

注意: この機能を使用するには、輸送行程のあるオーダーに制限する必要があります。

ネットワークルーティング - クロスレグ混載

この機能によりネットワーク・ルートの最適化ロジックが最適化され、ルーティング決定ステップでクロスレグ混載ルーティングが検討されます。

ネットワーク・ルーティングで、複数のネットワーク・レグのレグ混載グループが同じである場合、それらの各レグで作成された出荷を統合できます。レグ混載グループを使用して複数のレグにわたってオーダーを統合することでコストを削減できます。この機能により、このようなクロスレグ混載が可能かどうかを検討しながら、OTMでネットワーク・ルーティングが決定されるようになります(出荷に組み込まれるオーダー(移動)の生成を含む)。この新機能により、クロスレグ混載の可能性を考慮しながら出荷を作成できます。

TRUEに設定

ネットワーク・ルーティングの新しいロジック構成パラメータ: ルート選択でレグ混載グループを使用

パラメータ: 異なる搬送元レグGIDのOMS混載を許可

ネットワーク・ルーティングのロジック構成パラメータ: 搬送元リージョンに動的クラスタ・ロジックを実行 / 搬送先リージョンに動的クラスタ・ロジックを実行

例1

次の図に示すように、4つのレグを含むネットワークで、オハイオ州で発生しニューヨークまたはフェラデルフィア地域に向かうオーダーをプランニングします。フェラデルフィア地域に向かうオーダーには、フェラデルフィアにあるクロスドック・ロケーションを通過するルートしか使用できません。ニューヨーク地域のオーダーは、直接ニューヨークに向かうルートとフェラデルフィアのクロスドックロケーションを通過するルートがあります。レグ1とレグ2は同じレグ混載グループです。つまり、これらのレグ上の出荷はマルチストップ出荷として混載できます(そうした方が安価な場合)。

クロスレグ混載の例1

このネットワークで、クリーブランドからニューヨーク市に向かうオーダー1 (NEO-SD1-0001)と、クリーブランドからフェラデルフィアに向かうオーダー2 (NEO-SD2-002)を計画するとします。どのネットワーク・レグでも、両方のオーダーを一緒に輸送できる容量のある機材グループは1つしかないとします。この場合、最適なプランニング・ソリューションの合計コストは$ 2,100で、出荷は、(1) 出荷1: クリーブランド -> フェラデルフィアXDOCK ->ニューヨーク市、(2) 出荷2: フェラデルフィアXDOCK -> フェラデルフィアの2つになります。オーダーがこのようにルーティングされれば、このようになります。

しかし、古いロジックでは、プランニングの結果は合計コスト$3,100になり、出荷は、(1) 出荷1: クリーブランド -> フェラデルフィアXDOCK、(2) 出荷2: フェラデルフィアXDOCK -> ニューヨーク市、(3) 出荷3: フェラデルフィアXDOCK -> フェラデルフィアの3つになります。オーダーは現在このようにルーティングされます。

同じレグ混載グループのすべてのレグで現在の同一レグ混載出荷オプションを使用し、別のネットワーク・レグで作成され重複しないオーダーが含まれているオプションを結合します。この例の場合、拡張前の動的クラスタリング・ロジック(搬送元)ではレグ1とレグ2で次の混載出荷オプションが作成されました。

クリーブランド -> ニューヨーク市(オーダー1)

クリーブランド -> フェラデルフィアXDOCK (オーダー1、オーダー2)

この拡張による変更で、動的クラスタリングで次の混載出荷オプションが提示されるようになります。

クリーブランド -> ニューヨーク市(オーダー1)

クリーブランド -> フェラデルフィアXDOCK (オーダー1、オーダー2)

クリーブランド -> フェラデルフィアXDOCK -> ニューヨーク市 (オーダー1、オーダー2)

例2

オーダー:

NYC地域への3件オーダー

DC地域への3件のオーダー

1つの出荷で2件のオーダーしか処理できないと仮定します。

古いロジックでのプランニング: 合計コスト = $ 8,000

出荷1: NYC地域向け、2件のオーダー($ 2,000)

出荷2: DC地域向け、2件のDCオーダー($ 2,000)

出荷3: NYC地域向け、1件のNYCオーダー($ 2,000)

出荷4: DC地域向け、1件のDCオーダー($ 2,000)

新しいロジックでのプランニング: 合計コスト = $ 7,000

出荷1: NYC地域向け、2件のNYCオーダー($ 2,000)

出荷2: DC地域向け、2件のDCオーダー($ 2,000)

出荷3: PHILLY x-dockとWILMINGTON x-dockへのマルチストップ、1件のNYCオーダーと1件のDCオーダー($2,000)

出荷4: PHILLY x-dockからNYC地域向け、1件のオーダー($500)

出荷5: WILMINGTON x-dockからDC地域向け、1件のオーダー($500)

クロスレグ混載の例2

有効化のステップ

この拡張を使用するには、次のパラメータをtrueに設定する必要があります。

ネットワーク・ルーティングの新しいロジック構成パラメータ: ルート選択でレグ混載グループを使用

パラメータ: 異なる搬送元レグGIDのOMS混載を許可

ネットワーク・ルーティングのロジック構成パラメータ: 搬送元リージョンに動的クラスタ・ロジックを実行 / 搬送先リージョンに動的クラスタ・ロジックを実行

解決する問題は、説明の項に記載されているような内容で、ハブ経由または直接の従来的なシナリオで、ユーザーがネットワーク・ルーティングを使用するものとします。

ヒントと考慮事項

ルーティングは経済的に決定されるため、レートが解決する問題と矛盾することはありません。

混載を行う隣接レグには同じレグ混載グループを設定する必要があります。

Oracle Fleet Management

組合せ機材グループの使い勝手 - 返却セット・シナリオ

この機能は、組合せ機材グループ(2つ以上の機材を使用する出荷)の往路と、組合せ機材グループの復路のシナリオに必要となる手動処理を簡素化します。この機能を使用して、ドライバを居住地に戻すための貨物がない場合に空の"返却"出荷を作成できます。これを実現するには、新しい出荷エージェント処理である再配置機材の戻しを使用します。

ユース・ケースは多岐にわたりますが、1人のドライバが4つの出荷を担当するケースを紹介します。

出荷1 - ラインホールDC- "A"からロケーション"B"に向けて、組合せ機材の機材グループが、2台の積載済のトレーラ(機材グループ 1 (48フィート)と機材グループ2 (pup))で出発します。構造的には、この出荷には2つのS_Equipmentがあります。

出荷2 - ロケーション"B"でトレーラ1機材グループ1 (48フィート)を切り離し、別の出荷を積載します。ロケーションBからの出荷2を機材グループ2(pup)ですべてのロケーションに配送し、ロケーションBに戻ります。

出荷3 - ロケーションBで機材グループ2と機材グループ1 (48フィート)を入れ替えて、搬送してロケーションBに戻ります。

出荷4 - [この機能で作成される出荷] ロケーションBで空の機材グループ2 (pup)を空の機材グループ1 (48フィート)に連結し、空の機材の組合せ機材グループでDCAに戻ります。構造的に、この出荷には2つのS_Equipmentがあります。

このシナリオには様々な種類がありますが、基本的な目標は、出荷4、つまり2つの機材グループの組合せ機材による返却出荷を作成することです。このシナリオでは、出荷1、2、3は積荷関連の出荷であることから当然OTMプランニングで作成されます。この拡張は4番目の出荷に対するニーズに応えます。積荷が発生しない出荷ですが、ドライバーは機材のバランス維持のため、居住地を出発したときと同じまたは類似の機材を持って帰宅しなければなりません。

組合せ機材グループ返却シナリオ

他のユース・ケースとして、まったく同じ機材をラインホール出発と返却レグで使用するのかどうかや、IDの異なるその他の類似機材を使用するのかなどのバリエーションがあります。また、"現地配送"の出荷(上のシナリオの#2と#3)の両方または片方に作業割当を作成する場合と、いずれにも作成しない場合があります。このシナリオの出荷1、2、3と出荷4の"連結"では、スタンドアロンの作業割当作成ロジック、または手動のドライバ割当を想定しています。

積荷ありの出荷は従来のプランニング・エンジンによって作成されますが、シナリオ内の出荷4を作成するのはバルク・プラン出荷作成後に実行されるエージェント・ロジックです。バルク・プランニングで作業割当ロジックが有効の場合、OTMプランニングで出荷1、2、3が作成されますが、出荷4はエージェント処理によって作成されます。一般的に推奨されるのは、最初に積荷ありの出荷を作業割当ロジックを無効にしてプランニングで作成し、その後にエージェント処理で返却出荷を作成して、それからスタンドアロンの作業割当を実行し、4つすべての出荷を1つの作業割当に組み込んで出力する方法です。

返却出荷の作成はエージェント処理からの入力出荷を逆にしたイメージです。この新しいエージェント処理はすでに提供されている空の再配置機材処理と似ていて、シナリオの出荷4では、往路のラインホール出荷(シナリオの出荷1)と搬送元と搬送先が逆になり、サービス・プロバイダと機材グループ/組合せ機材グループが同じになります。また、返却出荷は往路のラインホール出荷の終了時間直後の開始時間で作成されます。作業割当またはドライバ割当への後続出荷の挿入では、それらの出荷(このシナリオでは出荷2と3)を挿入するために、返却出荷を再駆動して前方にスライドさせることが可能です。

有効化のステップ

再配置機材の戻し出荷エージェントを構成する必要があります。

エージェント保存済問合せを用意して、エージェントをどの出荷に対して実行するか(このシナリオでは出荷#1)を決定し、少なくともどの出荷を除外するのかを(このシナリオでは出荷2と3)を決定する必要があります。

ヒントと考慮事項

エージェントの保存済問合せの基準を決定することも重要です。このシナリオをモデル化するには基準に最低でも、エージェントのソース出荷、組合せ機材グループを持つ出荷に対してのみ実行すること、および貨物が含まれている必要があります。また、エージェントの保存済問合せと一定の最低距離を追加するのも役に立ちます。それぞれの実装は異なる可能性があります。

レート基準品目「出荷ボブテイル距離」をペナルティまたは加重原価(必要であれば)として使用するのも効果的です。返却出荷を追加せずにドライバを直接居住地に戻すことを作業割当作成で回避したり、ドライバの作業割当を最適化できます。このようにボブテイルの魅力を下げることで、フリート・プランニング割当で返却出荷の追加がより魅力的なオプションとして扱われるようになります。

出荷のセット(この例の1、2、3、4)の"連結"は手動またはバッチ・プロセスで実行する必要があります。バッチ・プロセスでは、スタンドアロンの作業割当作成を使用して、これを実現できます。この更新では、ドライバ作業割当の最適化でも実現できます。これらの機能はいずれも"連結"を実行します。また、ドライバ割当を使用して4つすべての出荷を一緒に割り当てても、4つの出荷が連結されます。これらの処理の1つが実行されるまで、このシナリオの出荷4と運送費あり出荷1～3の間に本質的な関係性は生まれません。

この機能は組合せ機材グループを意図して追加されましたが、この処理が1つ/従来的な機材グループの出荷に対して実行されるのを防ぐには保存済問合せ定義が最適です。

スタンドアロンの作業割当プロセス

この機能により、作業割当プロセスをバルク・プランとは別に実行できます。以前の自動作業割当て作成は、バルク・プランニング内で排他的に実行されていました。この機能により、ユーザーが事前作成済の出荷を選択し、作業割当ロジックを使用してスタンドアロン・プロセスとして連結することを検討できます。

この新機能によってユーザーは、すでに1回以上実行された可能性のあるバルクプランから出荷を選択し、作業割当の作成に向けて送信することができます。これにより、バルク・プランを使用してフリートの作成(共通の運送業者選択ではなく)を望むユーザーが、それらのフリート出荷のみを選択して、作業割当作成に向けて送信できるようになります。出荷作成と作業割当作成の間に介入できるようになります。

また、この機能により、新しい作業割当作成プランニングの結果画面が追加されます。この画面でユーザーはスタンドアロンとバルク・プラン内の作業割当プランをモニターしたり、スタンドアロンの作業割当プランを終了したり、各スタンドアロン作業割当プランに関する詳細なメトリックを確認したりできます。

有効化のステップ

この更新前は、次のいずれかの方法で作業割当が作成されました。

手動処理: 「作業割当の作成」処理を使用して、追加する出荷を手動で選択して作業割当を作成します。

または

バルク・プラン: フリート認識バルク・プラン機能を有効にして、バルク・プランを実行します。これにより、選択されたオーダー・リリースに対して最適化された作業割当(特定のロケーションから発生し定義された時間量になるように組み合された1つのリソース用の出荷のセット)が作成されます。

この機能の結果、OTMに3つ目の方法が提供されることになります。運送サービスの買いマネージャUIに「作業割当の最適化」という新しい処理が追加され、すでに計画済の出荷から作業割当を作成できるようになりました。

この新しいプロセスはOTM内で次のように動作します。

OTM出荷マネージャでユーザーが複数の出荷を選択し、「作業割当の最適化」処理を実行します。

処理入力画面でユーザーが、処理の実行に使用するパラメータ・セットIDを入力し、オプションで摘要を追加します。

この処理は、選択されたパラメータ・セットに構成されているリソース・スケジューラ構成IDを使用して、リソース・スケジュール・インスタンス(RSI)を作成し(作成されていない場合)、作業割当作成を続行します。

これらのRSIを使用し、RSIに指定された制約に基づいて特定の出荷の作業割当が作成されます。

結果のページに、作業割当プランニング結果ページが作成されます。
- また、バルク・プラン結果と同様に、作業割当プランニング結果ページはプランの開始後に単独でも表示できます。
  - (作業割当プランニング結果への単独のナビゲーション: 「フリート管理」→「プランニング結果」→「作業割当プランニング」)

作業割当機能は次の2つの場所から呼び出せます。

「出荷管理」→「運送サービスの買い」→「処理」→「フリート管理」→「作業割当の管理」→「作業割当の最適化」
「フリート管理」→「プロセス管理」→「作業割当の最適化」。これによりスケジュールが可能になります。

実行時間の長い作業割当バルク・プランを終了できるようになりました。これは作業割当バルク・プランの画面から実行できます。

作業割当バルク・プラン結果ページは常に作成されます。これは、標準のバルク・プランを使用して作成した場合でも、この機能を使用して作成した場合でも該当します。オーダーの標準のバルク・プランで作業割当の作成を有効にした場合、バルク・プランの最後に作業割当が生成されます。このときに、作業割当バルク・プラン結果ページが作成され、ここにバルク・プランから作成されたすべての作業割当が表示されます。さらにこの標準バルク・プランの結果ページも作成されます。

プランニング結果ページの値は次のとおりです。

出荷詳細:

プランニングの開始時間
プランニングの終了時間
選択済出荷件数
割当可能出荷件数
割当済出荷件数
失敗した出荷件数

距離および期間:

合計スラック期間
合計休憩期間
合計輸送期間
合計輸送距離

リソース:

使用可能なリソース・スケジュール・インスタンスの数
新しく生成されたリソース・スケジュール・インスタンスの数

作業割当:

作成済WA数
最大出荷
最小出荷
平均出荷

作業割当前の原価:

作業割当前の出荷の合計加重原価
作業割当前の出荷の実績原価合計

作業割当後の原価:

作業割当後の出荷の合計加重原価
作業割当後の出荷の実績原価合計

次のフィールドが計算されます。

使用可能なリソース・スケジュール・インスタンスこれは、作成されたリソース・インスタンスの数 + DBから取得されたリソース・インスタンスの数です。
新しく生成されたリソース・スケジュール・インスタンス = プランニング中に作成されたリソース・インスタンスの数。

「作業割当プランニング・メトリック」タブ

リソース

使用可能
使用済

作業割当

最小出荷
最大出荷
平均出荷
最小原価
最大原価
平均原価
最小合計期間
最大合計期間
平均合計期間
最小スラック期間
最大スラック期間
平均スラック期間
最小休憩期間
最大休憩期間
平均休憩期間
最小合計距離
最大合計距離
平均合計距離
平均リソース稼働率
平均合計時間稼働率
平均スラック-合計時間稼働率
平均休憩-合計時間稼働率

ヒントと考慮事項

注意: 出荷の輸送モードはRSモードと一致している必要があります。一致していない出荷は作業割当作成で考慮されず、結果ページの出荷割当可能の値に含まれません。

次の出荷はこの処理で考慮されません。

運送サービスの売り
RSモードが異なる出荷
混載出荷
CM出荷
「陸路サービス」以外のスケジュール・タイプが指定されている出荷、または、スケジュール・タイプが分離可能トリップで出荷ステータス値が'RESERVATION_OPEN'である出荷
ドライバがすでに割り当てられている運送サービスの買い

これらの出荷は作業割当に含まれず、その他のすべての有効な出荷の数が出荷割当可能数として表示されます。

ユーザーが作業割当作成の入力として運送サービスの買いを選択したときに、これらの出荷の一部がすでに既存の作業割当の一部になっている場合があります。

既存の作業割当に存在する出荷はすべて、新規作業割当作成の再プランニングの対象となります。
- ただし、W/AステータスがWA_DRIVER_ASSIGNMENT_ASSIGNEDである場合、その作業割当のすべての出荷が作業割当作成から除外されます。

特定の既存の作業割当の出荷がすべて含まれている場合、作業割当全体が除外されてから新規作業割当が作成されます。

特定の作業割当の一部の出荷(すべてではなく)が新規作業割当作成に含まれている場合、元の作業割当は存続して再駆動され、その作業割当で選択された出荷が作業割当から削除されてから、新しい作業割当が作成されます。

往復出荷順序vs.片道出荷順序に関するソリューション品質の向上

この機能で提供される新しい順序構成オプションにより、バルク・プランニングでフリートと一般的な運送業者の選択を行うような場面で、一般的な運送業者(片道)出荷順序とフリート(往復)順序をマルチストップ・ロジック内で細かく分析できます。OTMのマルチストップ順序付けで、複数の新しいマルチストップ順序オプションが評価されるようになります。フリート(花弁型)・レートが適しているもの(デポあり、など)と、一般的な運送業者レート(デポなし)が適しているものです。サービス・プロバイダの割当が発生したときに、より適切な順序が選択されます。

この拡張により、マルチストップ出荷を作成するときに適切なストップ順序付けができるようになります。この拡張の目的は、デポ・ストップを含めて最短距離を実現するストップ順序のために最適な往復のフリート・レートを考慮することと、デポ・ストップを含まない最短距離を実現するストップ順序のために直線の一般運送業者レートを考慮することです。これら2つのストップ順序ソリューションを比較して、全体的なレート/ストップ順序の組合せが最適なものを選択できます。このように、往復を意識する出荷やデポを含む出荷を、一般的な運送業者タイプの出荷のストップ順序(デポに戻ることを考慮しない)と比較できます。

以前のアルゴリズムは出荷を組み合せるときに、組み合せる出荷の最適なストップ順序を生成し、様々なチェックやレーティング、運転のプロセスをとおして実現可能と思われる最高の順序を選択していました。新しいアプローチではレートがより重視されるようになります。組み合せる出荷のセットに対し、適用可能なレートのリストが生成されます。これらは収集されて評価されます。適用可能な各レートは現在のプロセスに似た組合せプロセス(最適な順序を判別し、様々なチェック、レーティング、運転面で実現可能な最適な順序を見つける)を通過します。すべてのレート・ソリューションの中から最適なソリューションが選択されます。組合せロジック内のデポ・プロファイルの検討で、レートのデポ適用可能ステータスのみが使用されるようになります。

新しいマルチストップ・ロジックでは、レート地域のデポ適用可能属性(実際は、レート・レコードに関連付けられているレート・オファリング)のみが考慮されます。これにより、適用可能なすべてのレートに対してストップ順序付けロジックを実行するのではなく、デポ適用可能なレート1つとデポ適用不可能のレート1つについて出荷ストップの順序付けを行うため、実行時間を短縮できます。結果の出荷ストップ順序へのレートの割当は、そのストップ順序の決定に使用されたレートに限定されません。すべてのレートに対してレーティング・プロセスをオープンすると、デポ・プロファイルを使用するパスとデポ・プロファイルを使用しないパスの2つのみが順序付けロジックを通過します。

新しいマルチストップ・ロジック構成パラメータが導入されました(マルチストップ・レート中心順序の使用)。trueにすると、マルチストップ・ロジックがマージする出荷に適用できるレートをループします。ストップ順序付けの動作はデポ適用可能レートとデポ適用不可能レートとで異なります。新しいレート重視の順序付けは3op、2optおよびMIP順序に適用されます。

既存のマルチストップ最大順序数パラメータは各レート地域の順序付け処理に適用されます(すべてのレートにわたってではなく)。

マルチストップ・デポ・リワードで開始または終了とマルチストップ順序ロジックで戻りマイルを使用のパラメータには特別な考慮事項があります。レートがデポ適用可能と判別された場合、これらのパラメータは考慮されますが、そうでなければFalseとして処理されます。

有効化のステップ

この機能を有効にするには、マルチストップ・ロジック構成で次を実行します。

マルチストップ・レート中心順序の使用を"True"に設定する必要があります。

既存のマルチストップ最大順序数パラメータは各レート地域の順序付け処理に適用されます(すべてのレートにわたってではなく)。

この機能を使用するときには、デポ・プロファイルが存在し、パラメータでデポを使用するように指定する必要があります。デポ適用可能(フリート)と適用不可能(一般の運送業者)を区別するには、レート提供デポ適用可能フラグをTrue (選択する)に設定する必要があります。

ヒントと考慮事項

順序付けでデポ・ストップを使用するマルチストップ出荷が作成されるため、ストップが花弁型ルートに合致します。

追跡イベントを受信したときのサービス時間の見積り

これまで、ドライバが割り当てられたフリート・トリップでは、OTMは追跡イベント(TE)を受信し、そこにHOS状態(残り時間または消費時間)が含まれていることを期待していました。この情報が提供されない場合、OTMではあいまいな想定しかできず、すべての関連出荷でそのドライバに未使用の新規HOSがあるものとして処理します。OTMは、そのドライバのすべての時間をドライバが使用できるものと見なしていましたが、実際には、より情報に基づいたHOS計算を可能にする出荷情報がありました。OTMはすでに情報や、現在および以前の出荷割当、最近取得したHOS情報などを入手していることが多く、これを利用すればドライバの現在のHOS状態を詳しく理解できます。これにより、より正確なHOS計算が可能になります。

この機能によりOTMは、CAT/ CAL (現在の使用可能時間/現在の使用可能ロケーション) (出荷ストップ関連である場合と、そうでない場合がある)を受信したときに、そのドライバの最新のNAT/ NAL (次の使用可能時間/次の使用可能ロケーション)の時間に戻って、その場所/時間から前方駆動します。さらに、OTMは既知の出荷データを使用して、このHOS計算をさらに通知します。

この新しい機能は最新の既知のNAT NAL情報または既知の出荷情報から駆動を始めます。OTMの内部的な働きとして、この情報はDRIVER_ASSIGNMENT表に挿入された最新のレコードから取得されます。この表にレコードを挿入するイベントとしては、出荷の割当、追跡イベントによって示された出荷の完了、次の使用可能時間(NAT)、次の利用可能ロケーション(NAL)上書き入力(UIまたは追跡イベント経由)があります。

たとえば、2月26日火曜日8:00amのNAT/NALを持つドライバが存在するとします。これは、このドライバの米国ペンシルバニア州フェラデルフィアから始まるシフトを示しています。その日の出荷割当後、未使用の新規時間を持つそのドライバは9:00amにストップ1で貨物を集荷し、業務を開始するとします。3.5時間走行した12:30 pmに、ドライバは2つ目のストップである米国ペンシルベニア州スクラントンに到着します。このときに、ドライバはOTMに追跡イベントを送信し、12:30にストップ2に到着したことを通知します。この追跡イベントに、残り時間または消費時間の情報が含まれていなかったとします。

これまでOTMはこのドライバに対してストップ2からのHOS計算を前方駆動するときに、ドライバがストップ2で未使用の新規時間を持っているものと見なしました。これは単に、OTMが受信する追跡イベントに消費または残り時間の情報が含まれていなかったためです。この機能により、OTMは最新の、DRIVER_ASSIGNMENT表内の非現在の出荷レコードに戻り(この場合、2月26日火曜日8:00am)、そこから前方に駆動してHOS計算を取得します。このシナリオでは、最新の非現在の出荷HOSレコードは2月26日8:00 amですが、実際にはドライバは9:00から3.5時間走行しています。OTM HOS計算では、実際の出荷開始時間を使用してドライバの消費/残り時間を見積もります。したがって、この場合、ドライバの消費時間は4.5時間ではなく3.5時間になります。OTMは下流の出荷ストップに対してHOSの再駆動を実行し、より正確なHOS情報に基づいて出荷割当を実施するようになります。

有効化のステップ

この機能はデフォルトでは有効になります。

注意: これまでどおりユーザーが残り時間情報を含む追跡イベントを入力する場合は、OTM HOS計算の動作に変更はありません。しかし、この機能はHOS計算を本質的に向上し、残り時間情報を含むCAT CAL追跡イベントを送信しないユーザーに情報に基づいたHOS計算を提供します。

ヒントと考慮事項

この新しい動作を抑制して以前と同じ動作にするには、現在の使用可能時間(CAT)、現在の使用可能ロケーション(CAL)追跡イベントに残り時間または消費時間情報を含めて送信します。

組合せ機材グループの使い勝手 - マルチストップ・シナリオのサポート

この機能で追加されるプランニング・ロジックを使用して、マルチストップ出荷で組合せ機材を検討できます。

LIFO (後入れ先出し)マルチストップ出荷を使用する3つのユース・ケースがあります。

単一集荷、複数荷降: 集荷 -> 荷降 -> 荷降 ->荷降など
複数集荷で単一荷降: 出荷 -> 出荷 -> 出荷 -> 荷降
複数集荷、複数荷降: 集荷 -> 集荷-> 集荷-> 荷降 -> 荷降 -> 荷降など

これは運送費関連ストップと特別サービスを組み合せたもので、特別サービスでは機材がどこで集荷を行い(PICKLOADEDという特別サービス)、どこで荷降するかを(DROPLOADEDという特別サービス)決定します。LIFOを使用しないシナリオもあります。これらのシナリオについては、新機能のサマリーで詳しく説明します。

有効化のステップ

OTMの動作を3つのユースケースで説明しますが、これらはすべてバルク・プランのコンテキストでの動作です。

単一集荷、複数荷降

例: P(1) --> D(2) --> D(3) [このストップで機材1の荷降] --> D(4)

このユースケースでは、各荷降ストップに出荷ユニットのセット(P/Dのペア)があります。ストップ3にはDROPLOADED特別サービスがあり、他の荷降ストップにはそのような特別サービスはありません(これらはLIVE UNLOADと見なされます)。最後の荷降ストップから逆方向に計算します。次のストップはDROPLOADED特別サービスのあるストップです(この場合はストップ3)。ステップ4向けのすべてのS出荷ユニットが子の機材グループ(組合せ機材の定義で定義される)とともにconopt(コンテナ最適化)に送られます。Conoptはs出荷ユニットを1つ以上の子機材に梱包し、解決に戻ります。次のストップに向けて逆方向に進むとストップ3があり、ここにはDROPLOADED特別サービスがあります。OTMはこれらのストップ(つまり、ストップ2と3)で荷降するs出荷ユニットを梱包アイテムとして、未使用の子機材グループとともにconoptに送信します。Conoptはs出荷ユニットをこれらの子機材に梱包し、戻ります。このように、すべてのs出荷ユニットが梱包されるまでプランニングが続行されます。

複数集荷、単一荷降

例: 複数集荷、単一荷降 P(1) --> P(2) [このストップで機材2の集荷] --> P(3) ---> D(4)

この例では、各集荷ストップ用の出荷ユニットのセットと1つの搬送ストップがあります。このケースでは、ストップ2にPICKLOADED特別サービスがあり、他の集荷ストップにはこの特別サービスはありません(つまりLIVE LOADです)。最初の集荷ストップから前方に進むと、PICKLOADED特別サービスのあるストップがあります。ここではストップ2です。OTMは最初のストップからPICKLOADEDストップ(排他的)までのすべてのストップで集荷したs出荷ユニットを送ります。この場合はストップ1で集荷した出荷ユニットを梱包アイテムとして、すべての子機材グループを梱包リソースとしてconoptに送ります。Conoptはs出荷ユニットを1つ以上の子機材に梱包し、結果をプランニングに戻します。次に、ストップ2から前方に進むと、OTMは次のストップでPICKLOADED特別サービスを見つけます。または残りの集荷ストップにあればそれを見つけます(このケースはありません)。次に、OTMはこれらのストップで集荷した(3で集荷した)s出荷ユニットを梱包アイテムとして、および未使用の子機材グループを梱包リソースとしてconoptに送ります。Conoptはs出荷ユニットをこれらの子機材に梱包し、結果をプランニングに返します。すべてのs出荷ユニットが梱包されるまで、OTMはこれを続行します。

複数出荷、複数荷降

例: 複数集荷と複数荷降 P (1) ---> P(2) (PICKLOADED)---> P(3) ----> D(4) --> D(5) --> D(6) (DROPLOADED) --> D(7)

組合せ機材の梱包は次のように行われます。まず最初の集荷ストップから前に進むと、PICKLOADED特別サービスのある最初のストップ(排他的)があります。このようなPICKLOADEDストップが存在しなければ、これは最後の集荷ストップになります。これらのストップで集荷するすべてのs出荷ユニットを収集します。OTMは次を行います。最後のストップから逆方向に進むと、DROPLOADED (排他的)のある荷降ストップがあります。このような荷降ストップがなければ、これは最初の荷降ストップになります。これらのストップで荷降するすべてのs出荷ユニットを梱包アイテムとして、組合せ機材のすべての子機材を梱包リソースとしてconoptに送ります。梱包の済んだ1つ以上の子機材がプランニングに戻されます。1つ以上の出荷ユニットを梱包できない可能性もあり、その場合はプロセスを停止します。梱包できない出荷ユニットがある場合、上の例のDROPLOADEDストップで逆方向に進むと、DROPLOADED (排他的)のある荷降ストップがあります。このような荷降ストップが存在しなければ、これは最初の荷降ストップになります。これらのストップで集荷するすべてのs出荷ユニットを梱包アイテムとして、組合せ機材の残りの子機材を梱包リソースとしてconoptに送ります。1つ以上の子機材が梱包され、conoptは結果をプランニングに戻します。そしてまた梱包できない出荷ユニットがあればプロセスを停止します。OTMはこの手順を繰り返し、すべてのs出荷ユニットを梱包します。前方に進むと、PICKLOADED特別サービス(排他的)の集荷があります。そのようなPICKLOADEDストップが存在しなければ、これは最後の集荷ストップになります。これらのストップで集荷するすべてのs集荷ユニットを収集し、前述の2つの手順を繰り返して、s集荷ユニットを残りの子機材に梱包します。前述の2つの手順を繰り返して、すべての集荷ストップをすべての集荷ユニットが梱包されるかソリューションがなくなるまで処理します。

上の例では、3つの子機材を持つ組合せ機材の集荷プロセスが次のように行われます。SSU1: ストップ1で集荷、ストップ7で荷降。SSU2: ストップ2で集荷、ストップ6で荷降。SSU3: ストップ2で集荷、ストップ5で荷降。SSU4: ストップ3で集荷、ストップ4で荷降。まず、最初のストップから最初のPICKLOADEDストップ (2、排他的)にはSSUIがあります。このSSUを梱包します。最後のストップから前のDROPLOADEDストップ(6)排他には、梱包アイテムとしてストップで荷降されるSSU1と、梱包リソースとしてすべての子機材('CE'):CE1、CE2、CE3があり、これらをconoptに送ります。OTMはSSU1をCE1に梱包すると仮定して、前に進むとPICKLOADEDストップはないため、これが最後の集荷ストップになります。これらのストップで集荷したSSU2、SSU3、SSU4があり、OTMはこのSSUを梱包し、残りの子機材CE2とCE3を使用します。最後のストップから前のDROPLOADEDストップ(6)排他では、SSU2、SSU3、SSU4はストップ7で荷降されません。DROPLOADEDストップ(6)からの梱包されていないs集荷SSU2、SSU3、SSU4があり、逆方向にDROPLOADEDがないため、最初の荷降ストップを見つけ、SSU2、SSU3、SSU4がこれらのストップで荷降されます。OTMはその後SSU2、SSU3、SSU4がCE2とCE3に梱包されると仮定して、SSU2、SSU3、SSU4を梱包アイテムとして、および残りの子機材CE2、CE3を梱包リソースとしてconoptに送ります。

子機材グループは連番に基づいてconoptに送られます。LIFOマルチストップの場合、tSShipUnitGroupが集荷ストップ番号に基づいてconoptに送られます。最初に集荷されたTSShipUnitが小さい連番の子機材に梱包されます。LIFOでは最初に集荷された子機材が後から荷降されます。

非LIFOのケースでは、集荷ストップ番号に基づいてTSShipUnitGroupも送信します。最初に集荷されたものが先にconoptに送られて、より小さい連番の子機材に梱包されます。ただし、先に集荷された子機材が先に荷降される場合もあります。

ヒントと考慮事項

プランニング・パラメータ

新しい計画パラメータ: 機材梱包でストップ特別サービスをチェックが追加されました。デフォルトはfalseです。

このパラメータがfalseの場合、機材の梱包ロジックは以前と同じになります。つまり、マルチストップ出荷のときに組合せ機材に対して機材梱包が発生せず、単一機材の梱包は変更されません。

このパラメータがtrueの場合、前述のマルチストップLIFO出荷を組合せ機材に梱包するロジックが呼び出されます。集荷ストップにPICKLOADEDの特別なサービスがある場合、集荷積載であると見なされます。LOADである場合、またはLOAD/PICKLOADEDでない場合、ライブ積載と見なされます。荷降ストップにDROPLOADEDの特別なサービスがある場合、荷降積載とみなされ、UNLOADがある、またはUNLOAD/DROPLOADEDの特別サービスがない場合はライブ荷降と見なされます。特別サービスと別のロケーションでのSSU集荷/荷降をマルチストップ出荷を組合せ機材に梱包できない理由を説明しました。これは、通常の機材に梱包するときにも発生します。たとえば、P ---> P( -PICKLOADED)------> Dの場合、これは通常の機材グループでは無効な出荷です。なぜならば2番目の集荷ストップはPICKLOADEDであり、ストップ1用の機材1つと、ストップ用の別の機材が必要であるためです。この出荷には組合せ機材が必要です。

注意: 組合せ機材梱包の観点から、荷降ストップではPICKLOADED特別なサービスは無視され、集荷ストップではDROPLOADED特別なサービスは無視されます。

機材梱包でストップ特別サービスをチェックがfalseに設定されている場合、PICKLOADED特別サービスのある集荷ストップが2つ以上のマルチストップ出荷、またはDROPLOADED特別サービスのある荷降ストップが2つ以上あるマルチストップ出荷は現在のマルチストップ・ロジックで形成されません。

運送費支払、請求および請求

請求書調整原価動作の拡張

この機能で提供される新しいプロパティを使用して、OTMで請求書をどのように調整するかを制御できます。新しいプロパティglog.invoice.adjustments.createNewInvoiceForAdjustmentsを使用して、次のシナリオをサポートできるようになりました。

glog.invoice.adjustments.createNewInvoiceForAdjustments=true (デフォルト)にした場合:

承認済の請求書を調整すると、調整額が新しい請求書に取り込まれます。
未承認の請求書を調整すると、調整額が既存の請求書に請求明細として追加されます。

glog.invoice.adjustments.createNewInvoiceForAdjustments=falseにした場合:

承認済の請求書を調整すると、調整額が既存の請求書に新しい請求明細として追加されます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

glog.invoice.adjustments.createNewInvoiceForAdjustmentsのプロパティ・デフォルト=true (デフォルト):

承認済の請求書を調整すると、調整額が新しい請求書に取り込まれます。
未承認の請求書を調整すると、調整額が既存の請求書に請求明細として追加されます。

Logistics Network Modeling

はじめに

Oracle Logistics Network Modeling Cloud (LNM)が貴社に勝利をもたらします。実世界の運用データを使用して、自社の輸送ネットワークを戦略および戦術面から簡単に分析できます。ルーティングにクロスドックと直接を選んだときの影響差の把握や、配送センターの出荷および受領時間の調整で削減できるコストの定量化、レートの上昇が輸送予算に与える影響調査など、LNMの直感的なツールを使用して、自社の運用環境のコンテキストで詳細なwhat-ifシナリオを実行し、詳細かつ正確な結果を入手できます。

概要

サプライ・チェーンおよび関連する輸送ネットワークは、グローバリゼーション、オムニチャネル・フルフィルメント、サプライ・チェーンのリスク軽減、合併買収といったビジネス上の課題に対応するため複雑になります。多くの企業が特定の問題のみを解決するポイント・ソリューションを採用しています。このようなソリューションから生成されるデータをネットワーク全体の観点から効果的に統合して分析することは簡単ではありません。現在の需要主導の環境で、堅牢で弾力性があり採算性の優れた輸送ネットワークを構築するには、戦略および戦術的な分析が不可欠です。

サプライ・チェーン・マネージャは変更や混乱への対応に追われています。彼らは次のような変更を計画的に行ったときの影響を把握したいと考えています。

既存のネットワークへの顧客またはサプライヤの追加
ボリューム変更が輸送業務に及ぼす影響の予測
主要サプライヤの脱退や港湾ストなど、計画外の混乱が発生した場合の最善策の決定
運用改善を目的とする現在のネットワーク設計方針または輸送方針の変更

このような分析を実行できるアプリケーションもありますが十分な機能があるとはいえません。簡易的な輸送ネットワーク・モデルを使用していることが多く、履歴的なデータから見積もった集計コストに基づいて動作するからです。また、分析に使用されている最適化およびプランニングのアルゴリズムが実際の輸送業務と乖離していて、結果として提示される方針を実世界の条件と効果的に合致させることが難しく、採用が困難な場合も多々あります。

Oracle Logistics Network Modeling Cloudでは、シンプルで直感的、簡単な方法で戦略および戦術面から自社の輸送ネットワークを自社の運用環境のコンテキストで分析できます。現行の輸送ネットワークの運用データを使用して、LNMで詳細なwhat-ifシナリオ分析を実行できます。自社の輸送業務で使用しているルールや方針、プランニング・アルゴリズムを使用できます。そのため生成される結果は精度が高く、変更が運用に与える影響が明確にわかります。実際の運用ネットワークのコンテキストにおける結果が提示されるため、特定された変更や対応を必要に応じて簡単に採用できます。

シナリオ管理

Logistics Network Modeling Cloudでは様々なシナリオを定義して、自社の現在の運用環境のコンテキストで分析できます。複数のタイプの分析を独立したプロジェクトとして同時実行できます。各プロジェクトに、データやルール、方針の変更を組み合せたシナリオを複数含め、それらのシナリオを比較できます。変更はシナリオ内に隔離されるため、実際の運用データには一切影響しません。結果を簡単に分析して、様々なシナリオを左右に並べて比較できます。シナリオ分析ワークベンチは複数のペインが含まれる構成可能なビューです。このビューに結果の出荷計画を表示し、その詳細にドリルダウンしたり出荷計画をマップに表示したりできます。

シナリオ分析ワークベンチ

シナリオ分析ダッシュボードはもう1つの便利なビューです。原価や稼働率など様々なディメンションにわたる共通のメトリックを使用してシナリオを比較できます。カスタムのメトリックとビジュアル化を定義して、実際の出荷データを使用して各シナリオを比較できます。運用パフォーマンスの測定に使用しているのと同じメトリックを使用することで、変更によってどのような影響が生じるかを理解し、最善な対応策を判断できます。

シナリオ分析ダッシュボード

Oracle Logistics Network Monitoring Cloudでは運用計画と同じプランニング・ステップでシナリオを分析し、実際の運用データを使用して、運用への影響を明らかにする結果を生成します。概算や集約といったものではなく実際の運用データを使用し、そこに各シナリオの変更点を重ねます。日常的に行っている運用プランニングを実施して、運用への影響を明らかにします。

Oracle Logistics Network Modeling Cloudの主要機能は次のとおりです。

戦略および戦術的なシナリオの両方をサポートします。運用改善に向け、簡単に実行できる戦術的なwhat-ifシナリオを実際の運用環境でモデリングして分析できます。時間のかかる戦略的な分析には別個のモデリング環境を使用できるため(必要な場合)、パフォーマンスへの影響の大きい分析によって運用に影響が及ばないようにします。

主要な基準(オーダーセットや期間など)を指定し、分析に制約を適用するなどして、現実の運用条件がより正確に反映されるようにします。

実際の運用データを使用し、必要に応じて変更の適用やデータ追加を実行し、シナリオをできるだけ正確に分析します。

複数のリンクされている日次/週次計画を順次的または並行的に実行するなど、運用計画のプロセスを忠実に再現します。

Oracle Transportation Management Cloudの高度なビジュアル化機能を使用して、各シナリオの出荷計画詳細をストップレベルの詳細を含め表示および分析できます。シナリオ結果を並べて比較します。

パッケージ化されたカスタムの主要パフォーマンス指標とそれに関連付けられたダッシュボードを使用できます。ダッシュボードではスライスアンドダイスやドリルダウン、一時的問合せのメカニズムがあり、複数のシナリオを並べて比較できます。LNMの分析機能には、業界最高レベルのOracleのビジネス・インテリジェンス・テクノロジが使用されています。

シナリオ分析を保存して、将来参照できます。これにより、ネットワーク内で同様のリスクやシナリオが発生したときに過去の分析を参照できるため、戦略を継続的に精査し、改善できます。

戦略的シナリオの管理

戦略的シナリオの管理では輸送業務の長期的な最適化が可能です。これには通常、主要なビジネス条件に関する変更をモデリングして、その変更が輸送ネットワークに長期的に及ぼす影響を分析することが含まれます。この結果導かれる方針によっては、ネットワーク構成の変更が必要になったり、ネットワークへの効果が高い対応戦略が必要になることがあります。それでもこれは有意義な変更であり、高いコスト削減効果を期待できます。

戦略的シナリオ分析の例は次のとおりです。

輸送ネットワークの混乱
運送費の変更
運送業者/サービス・プロバイダのリスク管理
サプライヤ/ベンダーのリスク管理
輸送ネットワーク・ルートの評価
輸送ネットワークの設計
持続可能性評価
Cost-to-Serve(供給コスト)および採算性分析(既存の輸送ネットワークへの新しい顧客や部門、営業品目、地域の追加など)

戦術的シナリオの管理

戦術的シナリオの管理では様々なオプションを分析し、現在の運用需要を満たす最適なアプローチを明らかにして現在のネットワークを改善します。一般的な運用システムは、1つの目的(通常はコスト削減)に従って1つの出荷計画を提示します。Oracle Logistics Network Modeling Cloudでは、日常的なビジネス・プロセスのコンテキスト内で複数の輸送戦略を同じ運用データを使用して分析し、現在の最善の戦略を明らかにすることができます。そのため、他のシステムでは簡単には実現できない新しい運用の最適化を可能にします。結果として提示されるソリューションによりネットワーク変更が必要になることはほとんどなく、現在の運用に大きなコスト削減をもたらします。

運用シナリオの管理には次のようなものがあります。

輸送制約分析(制約を和らげることでソリューションを改善できないか?)
アルゴリズムの選択/設定分析(どの設定が今日のオーダーに適切か?)
運用ネットワーク分析(非従来的なルートやモード、運送業者を適用できないか?)
輸送方針の変更(時間枠を緩和できるか?オーダーのバッチを変えられないか?)

迅速な価値実現

LNMは、Oracle Transportation Management Cloud環境ですでに使用可能な状態であり、追加の設定や統合を行わなくても機能をすぐに使用できます。OTMと同じエンティティと概念が使用されているため、直感的かつ簡単に使用でき、特別なトレーニングも必要ありません。

現実の運用データを使用して戦略的および戦術的なシナリオ分析を実行できるため、大幅なコスト削減を期待できます。輸送ネットワークに変更を加えた場合の影響を実際の運用データを使用してモデル化し、最適な対応策を明らかにできるため、ネットワークは常に最高の状態で機能しサービス・レベルを効率的に満たせます。

LNMはOTMの本質的な部分であるため、ネットワーク設定や設計、方針に対する変更を迅速に分析し、簡単に実装できます。そのため、発生する変化に簡単に対応できる弾力性のあるサプライ・チェーンを実現できます。ネットワーク中断リスクやサプライヤ変更リスクなど、サプライ・チェーン・リスク分析を簡単に実行できるため、それぞれのリスクに対して最適な対応策を準備しておくことができます。

有効化のステップ

構成

LNMは様々な構成で実行できます。LNMを実行する方法と場所は、どのタイプのモデリングを行うかによって異なります。LNMの実行に関して次のようなオプションがあります。

OTMを実行する本番またはテスト・インスタンスでLNMを実行する ? 別個のLNMドメイン内(運用データにはアクセスできない)、または運用データへの読取りアクセス権がある別のドメイン内で実行する。
1. LNMを使用して、今日や昨日といった日次のシミュレーションを行う場合に適しています。

LNMを別個のテスト・インスタンスで実行する ? これを設定するには通常、本番からテスト(PtT)への移動を実施し、本番データをLNMインスタンスに移行する必要になります。
1. 大量のデータを含むプロジェクトが多数あり、多数のバルク・プランを実行する必要がある場合に適しています。たとえば、1年分のオーダー・データをカバーする日次バルク・プラン・シミュレーションが含まれたプロジェクトを実行するような場合です。

LNMの使用方法の概要

LNMは、設定、解決、分析という3つの基本的なステップで使用します。

設定
1. 関連するモデリング・シナリオで使用するモデリング・プロジェクトとモデリング・プロジェクト・レベルのデータを定義します。
2. プロジェクトに関連する様々なモデリング・シナリオを定義します。
3. 各モデリング・シナリオについて、シナリオのモデリングに使用するデータ・ソースおよデータ変更を定義し、構成します。
解決
1. プロジェクト内のすべてのモデリング・シナリオに対してバルク・プランを実行します。
分析
1. モデリング・シナリオのバルク・プラン結果を比較します。
2. モデリング・プロジェクトおよび関連するモデリング・シナリオのワークベンチ・レビューを実行します。
3. Logistics Network Modeling Intelligenceを使用して、モデリング・プロジェクトを分析します。
  1. (モデリング・プロジェクト)データを分析に移動します。
  2. 非定型レポートとダッシュボードを構築します。
  3. 結果を分析します。

有効にする手順の概説および例

LNMを使用する前に、プロジェクトの目的と比較するモデリング・シナリオを明確にすることが重要です。プロジェクト、様々なシナリオと関連データ、パラメータ、データ変更を前もって準備しておくと、LNMを効率的に設定できます。

この例のLNMプロジェクトでは、2つの配送センターからのソーシングのコストを比較します。DC1は米国カリフォルニア州のオンタリオ、DC2は米国カリフォルニア州のコンプトンにある配送センターです。2つのDC拠点は50マイル程離れており、両方ともこのDCにとって実現可能なロケーションです。ここでの目的は、これら2つの搬送元ロケーションを使用してオーダーに対応する場合の輸送コスト(距離、時間および金額)をモデル化し、比較することです。

設定 - モデリング・プロジェクトおよび関連するモデリング・シナリオの設定が含まれます。

モデリング・プロジェクトおよびモデリングのシナリオ - プロジェクトの目標を定義した後に、モデリング・プロジェクトを作成します。モデリング・プロジェクトはプロジェクト全体を説明するもので、モデリング・プロジェト内で比較する様々なモデリング・シナリオとリンクしています。モデリング・プロジェクト・オブジェクトを使用して、関連するすべてのモデリング・シナリオで使用するデフォルトを定義します。こうすることでモデリング・シナリオの設定を簡素化できます。

モデリング・プロジェクト

例モデリング・プロジェクト - DC1 v DC2

モデリング・プロジェクト入力

モデリング・プロジェクトID - プロジェクトに意味のあるモデリング・プロジェクトIDを追加します - 目的が少しずつ異なるプロジェクトを多数の生成する可能性がある - IDに基づいてプロジェクトを特定および差別化できると便利です。
- モデリング・プロジェクトID = DC1 VS DC2

モデリング・プロジェクト名 - プロジェクトの名前を指定します。
- モデリング・プロジェクト名 = COMPARE ORDER SOURCING FROM DC1 V DC2 - IDのようなもの - より説明的な名前にします。

摘要 - このプロジェクトの目的や含まれているシナリオを明確に示す説明文を入力します。
- 摘要 = このプロジェクトには2つのシナリオがあります。1つはDC1をソース・ロケーションとして使用するモデリング・シナリオ、もう1つはDC2をソース・ロケーションとして使用するシナリオです。両方のシナリオで同じオーダー・セットを使用します。

パラメータ・セットID - 関連するすべてのシナリオで使用されるパラメータ・セットIDをプロジェクト・レベルで設定できます。
- パラメータ・セットID = Null -このプロジェクトでは、デフォルト・パラメータ・セットが使用されます。したがって、デフォルトは必要ありません。

保存済問合せタイプとオーダー保存済問合せID - 別のオーダー・リリース(またはオーダー(移動))のセットを選択して、それらをすべてのプロジェクト・シナリオで使用できます。
- このプロジェクトでは、すべてのモデリング・シナリオが同じオーダー・リリース保存済問合せに対して実行されます。
- 保存済問合せタイプ = オーダー・リリース
- オーダー保存済問合せID = DC1 V DC2 SOURCING PROJECT

輸送行程IDおよび輸送行程プロファイルID - 輸送行程または輸送行程プロファイルのプロジェクト・レベルのデフォルト値を設定し、プロジェクトのすべてのモデリング・シナリオで使用できます。
- このプロジェクトでは使用可能なすべての輸送工程を考慮するため、デフォルトは使用しません/必要ありません。

モデリング・シナリオ - プロジェクトのモデリング・シナリオを作成します。LNMにはモデリング・シナリオの構成に役立つ数々の強力なデータ選択ツールやデータ変更ツール、バルク・プラン・シミュレーション・ツールが含まれています。次の6つの主要機能を自由に使用してモデリング・シナリオを構成できます。

保存済問合せタイプ/オーダー保存済問合せ - 様々なオーダーのセットを簡単に選択して、それらを各モデリング・シナリオで考慮できます。

パラメータ・セット、輸送行程または輸送工程プロファイル - これらのフィールドのいずれかに異なる値を設定すると簡単に、各モデリング・シナリオで異なるオプションを考慮できます。

たとえば、各モデリング・シナリオで輸送行程を変更するだけで、様々なモード・オプションや機材グループ・オプション、ネットワーク・オプションをモデル化できます。

パラメータ上書き - この機能を使用すると、モデリング・シナリオごとに別のパラメータ値を設定できるため、別のプランニング・パラメータ・セットやロジック構成モードを作成することなく異なる設定をモデル化できます。

たとえば、同じベース・パラメータ・セットを使用して複数のモデリング・シナリオを実行し、1つのシナリオでは「できるだけ遅くまで保留」パラメータのデフォルト値を上書きして、どの値が最適な結果を生成するかを確認できます。

シナリオ・データ変更 - この機能を使用すると、モデリング・シナリオ内の特定の値を変更できます。

たとえば、「レートに含まれるストップ」の数を変えてモデリング・シナリオを実行できます。

データ・ルール/データ・ルール・インスタンス - データに対して仮想的な一括更新を実行できます。「データ・ルール」を使用してデータを設定し、データ内の値を増減したり消去したりできます。

たとえば、データ・ルールを使用して、セットまたはオーダー・リリースにロケーションを設定したり、オーダー・セット上の重量と容積を増減させたりできます。

バルク・プラン仕様 - 複数のバルク・プランをすべて1つのモデリング・シナリオのコンテキストで実行できます。この機能では、1日の様々な時間に開始するバルク・プランや様々なグループ化オプション(搬送元または搬送先ロケーションよるグループ化など)または異なる保存済問合せに基づいて実行するバルク・プランをシミュレーションできるほか、これらの機能を組み合せて、特定の時間、保存済問合せおよびグループに基づいて実行するバルク・プランを定義できます。

たとえば、バルク・プラン仕様を設定し、複数のバルク・プランを1つのモデリング・シナリオで実行できます。各バルク・プラン仕様がオーダー保存済問合せに基づいて異なるバルク・プランを実行します。各保存済問合せが1日分のオーダーの実行をシミュレーションしますが、3つの異なる地域のバルク・プランに分かれています。このシナリオを別のモデリング・シナリオ(バルク・プラン仕様を使用して同じオーダー・セットが設定された、3つではなく2つのバルク・プランのモデリング・シナリオ)と比較できます。

シナリオUI

例DC1のモデリング・シナリオ

モデリング・シナリオ入力

モデリング・シナリオID - 意味のあるモデリング・シナリオIDを指定します。
- モデリング・シナリオID = DC1 AS SOURCE LOCATION この例では、ソース・ロケーションごとに1つずつ、2つのシナリオがあります。

モデリング・シナリオ名を指定します。
- モデリング・シナリオ名 - DC1 AS THE SOURCE LOCATION。

このプロジェクトの目的を表す説明を入力します。
- 摘要 = DC1 - Ontario CA as source

モデリング・プロジェクトID - これは、このモデリング・シナリオが関連付けられているモデリング・プロジェクトIDです - プロジェクト内にモデリング・シナリオを作成すると、関連するモデリング・プロジェクトIDがデフォルト値になります。モデリング・シナリオUIでモデリング・シナリオを作成する場合は、関連するモデリング・プロジェクトIDを指定する必要があります。
- モデリング・プロジェクトID = DC1 VS DC2

パラメータ・セットID - プロジェクト・シナリオごとにシミュレーションで使用するパラメータ・セットを変更できます。
- パラメータ・セットID = Null - この例では、デフォルトのパラメータ・セット/同じパラメータ・セットを両方のシナリオで使用するため、入力不要です。

保存済問合せタイプとオーダー保存済問合せID - 別のオーダー・リリース(またはオーダー(移動))のセットを選択して、シナリオで使用できます。
- このプロジェクトでは、プロジェクト・レベルで設定されたオーダーを両方のシナリオで使用します。

「輸送行程ID」および「輸送行程プロファイルID」フィールドでは、シナリオ・レベルのオプションを設定できます。
- 輸送行程IDおよび輸送行程プロファイルID = Null -この場合、プロジェクトまたはシナリオに制限が設定されず、標準のプランニング・ロジックが使用されます。

パラメータ上書き - パラメータ(ロジック構成またはパラメータ・セットに基づく)を選択し、ここに入力した値で既存の値を上書きできます。シナリオ・バルク・プラン中、パラメータ・セット(このシナリオの)に定義されたパラメータよりもここに入力されたパラメータが優先されます。
- パラメータ上書き = Null - この例では上書きは使用しません。

モデリング・シナリオ・データ・ルール、データ・ルール・インスタンス - データ・ルールはLNMの強力な機能です。「モデリング・シナリオ・データ・ルール」と「データ・ルール・インスタンス」を使用して、ベース・データを実際に変更せずにモデリング・シナリオのデータを変更できます。シナリオを実行すると、データ・ルール・インスタンスに定義されている保存済問合せフィルタによって提供されるデータに対し、データ・ルール/データ・ルール・インスタンスに定義されている変更がメモリー内で適用されます。データ・ルール/データ・ルール・インスタンスを使用すると、ベースのデータ・セットについて様々なデータ構成を簡単に作成できるため、検討するシナリオに合わせてデータ・セットを生成する必要がなくなります。使用可能なデータ・ルール・オブジェクトには次のものが含まれます。使用容量、輸送行程、輸送行程レグ、ロケーション、オーダー(移動)、オーダー・リリース、レート地域、レート・オファリング、レート品質、ルーティング・ネットワーク、ルーティング・ネットワーク詳細、ルーティング・ネットワーク・レグ。
- このプロジェクトでは、2つのデータ・ルール・インスタンスを持つモデリング・シナリオ・データ・ルールを1つ使用します。モデリング・データ・ルールを構成し、オーダー・リリースのソース・ロケーションを定義できるようにします。シナリオごとに1つずつ、2つのデータ・ルール・インスタンスを使用し、オーダー・リリースのソース・ロケーションを設定します。DC1 AS SOURCE LOCATIONモデリング・シナリオには"DC1"を設定し、もう1つのデータ・ルール・インスタンスを使用して2つ目のモデリング・シナリオのオーダー・リリースのソース・ロケーションを"DC2"に設定します。

データ・ルール

モデリング・シナリオ・データ・ルールおよびデータ・ルール・インスタンス - モデリング・シナリオ・データ・ルールを使用して要素の定義を構築します。これらの要素はデータ・ルール・インスタンス内で構成できます。「データ・ルール・インスタンス」では、特定のシナリオの一部としてベース・データに加える変更を定義できます。モデリング・シナリオ・データ・ルールによりLNMスーパーユーザーに許可される構成の範囲が増えます。スーパーユーザーがデータ・ルールを定義して、そのデータ・ルールをLNMモデリング・ユーザーが使用して、自身のモデリング・シナリオでデータ・ルール・インスタンスを構成できるようになります。データ・ルールを事前に定義しておくことで、LNMユーザーがシナリオを設定する際に選択しなければならないオプションや決定事項を簡素化できます。

連番 - シナリオのバルク・プランの実行時にデータ・ルール・インスタンスをどの順番で適用するかを定義します。
- 連番 = 1 - 1データ・ルール・インスタンスのみ

データ・ルール・インスタンスID - データ・ルール・インスタンスはデータ・ルールの1つのコンポーネントです。データ・ルール定義をベースにしてデータ・ルール・インスタンスを作成します。データ・ルール・インスタンスはシナリオに割り当てられて、そのシナリオのデータを変更します。
- データ・ルール・インスタンスID = CHANGE TO DC1 - このモデリング・シナリオのデータ・ルール・インスタンス
  - データ・ルール・インスタンスの定義
    - 一意のデータ・ルール・インスタンスIDを入力します。
      - CHANGE TO DC1
    - データ・ルール・インスタンスの摘要を入力します。
      - ソース・ロケーションをDC1に変更します。
    - データ・ルール定義IDを入力します - これによりインスタンスが定義済のデータ・ルールとリンクされます。
      - CHANGE SOURCE LOCATION
    - 「表名」は、データ・ルール定義で定義されているオブジェクトに基づいて入力されます。
      - ORDER_RELEASE
    - ルール・グループはルールをグループ化するオプションの方法で、検索でレコードを取得するときに使用できます。
      - Null
    - データ・ルール・インスタンスのパラメータを入力します。
      - パラメータ名を入力します。「列名」が表示されます。
        
        DC CHANGE
        
        SOURCE_LOCATION_GID
      - オペランドを入力します。オペランドはOTMに列値の変更方法を指示します。オペランドは事前定義の公開値です。使用可能なオペランド値は、列タイプ(「文字列」、「日付」、「単位」)によって異なります。たとえば、文字列/Gidの場合、公開オペランドは、CLEAR、SET、PREPEND、APPENDです。CLEARオペランドは、ユーザー・インタフェースのnull不可列には表示されません。
        
        SET
      - 値を入力します。値のフィールドはオペランドに基づいて移入されます。「Clear」オペランドの場合、値は期待されていないため、「Clear」オペランドを選択したときには「値」フィールドが非表示になります。各オペランドには式が関連付けられていて、それらはLNM_OPERAND表で定義されています。たとえば列タイプがDATE/TIMEの場合、オペランドINCREASE BY DAYSが使用可能になり、期待値は数値です。
        
        OOTB.DC1
保存済問合せフィルタ - 保存済問合せフィルタID。これにより返されるオブジェクトのリストに対し、インスタンスに定義されているデータ・ルールが適用されます。
- DC1 V DC2 SOURCING PROJECT

DC2シナリオ

モデリング・シナリオ・データ・ルール・インスタンスDC1

モデリング・シナリオ・データ・ルール・インスタンスDC2

このプロジェクトの2つ目のシナリオの設定は、最初のシナリオの前述の手順と完全に同じです。ただし、2つ目のシナリオではデータ・ルール・インスタンスに指定するソースの場所がDC1ではなくDC2になります。

解決 - モデリング・プロジェクトとモデリング・シナリオの設定が完了したら、プロジェクト内のすべてのモデリング・シナリオに対してシナリオ・バルク・プランを実行します。

シナリオ・バルク・プラン - プロジェクトからシナリオ・バルク・プラン処理を実行すると、そのプロジェクト内のすべて(または一部)のシナリオに対してバルク・プラン実行を開始できます。

シナリオ・バルク・プラン

シナリオ・バルク・プラン実行

シナリオ・バルク・プラン出力 ? プロジェクトに対してバルク・プランを実行すると、シナリオ・バルク・プラン出力画面に実行中のシナリオ・バルク・プランのステータスが表示されます。

分析 - プロジェクトのシナリオ・バルク・プランが完了したら、次の最後のステップは結果の分析です。LNMの各種の強力なツールを使用して、モデリング・シミュレーションの結果を解釈できます。

使用可能な主要な分析ツールには、次のものがあります。

モデリング・シナリオ・バルク・プランの結果の比較 - 主要なシナリオ・メトリック(合計原価、マイル数、出荷数など)の簡単な概要を提供します。

シナリオ・バルク・プラン比較

ワークベンチ・レビューの実行 - ワークベンチでソリューションをレビューし、モデリング・シナリオを横に並べて詳細なソリューション分析(詳細レベルで出荷をレビュー)を行います。LNM出荷データの表ビューを使用してレビューしたり、モデリング・シナリオ専用のマップ表示で地理的にレビューできます。

シナリオ・ワークベンチ分析 - 並べて配置したモデリング・シナリオ・マップ・ビュー

Logistics Network Modeling Intelligence - 分析へのデータの移動

分析へのデータの移動

分析に移動されたデータ - 移動された表

Logistics Network Modeling Intelligence - 結果分析、一時的問合せ、ダッシュボードおよびレポートを作成してプロジェクトおよびシナリオを分析します。

Logistics Network Modeling Intelligenceを使用した一時的問合せ

ダッシュボード

Global Trade Management (ベース)

データのグループ化および集計のためのフレックス・フィールド

この機能により、ロジック構成の制約セットで使用する属性を定義するときに、フレックス・フィールド(データ、数値、文字列)を含めることができます。

フレックス・フィールド・オプションは、次の制約セットで使用できます。

総計
グループ化

有効化のステップ

この機能を利用するには、ロジック構成および制約セットを定義する際の標準の手順を実行します。

新しいGTM申告ロジック構成を追加します。
1. ロジック構成IDを入力します。
2. 新しい総計またはグループ化制約セット(あるいはその両方)を追加します。
  1. 制約セットIDの追加を追加します。
  2. 制約セット・タイプを選択します。
    1. 申告明細総計
    2. 申告明細グループ化
  3. いずれかのフレックス・フィールド・オプションを選択します。
    1. 日付フレックス・フィールド
    2. 数値フレックス・フィールド
    3. 文字列フレックス・フィールド
  4. 次に、選択したオプションに基づいて、制約詳細を定義します。
    1. 日付フレックス・フィールド
    2. 数値フレックス・フィールド
    3. 文字列フレックス・フィールド

ヒントと考慮事項

対応するマネージャ・レイアウトを設定するときに、次の手順を実行する必要があります。

フレックス・フィールドを定義して画面セットに含める必要があります。
この画面セットに割り当てられたマネージャ・レイアウトIDを使用して、この画面セットに関連付けられたビジネス・オブジェクトが表示されます。

データ構成を使用したフレックス・フィールドのコピー

この機能により、データ構成で使用する属性を定義するときに、フレックス・フィールド(データ、数値、文字列)を含めることができます。

フレックス・フィールド・オプションは、データ構成の次の関連タイプで使用できます。

トランザクションから申告
出荷からトランザクション
オーダー・リリースから貿易トランザクション

有効化のステップ

この機能を利用するには、データ構成を定義する際の標準の手順を実行します。

新しいデータ構成を追加します。
1. データ構成IDを追加します。
2. 次の3つの関連タイプから1つ選択します。
  1. トランザクションから申告
  2. 出荷からトランザクション
  3. オーダー・リリースから貿易トランザクション
3. 関連を選択します。
  1. ヘッダー-ヘッダー
  2. 明細-明細
4. いずれかのフレックス・フィールド・オプションを選択します。
  1. 日付フレックス・フィールド
  2. 数値フレックス・フィールド
  3. 文字列フレックス・フィールド
5. 次に、選択したオプションに基づいて、属性詳細を定義します。
  1. ソース・フレックス・フィールド名
  2. ターゲット・フレックス・フィールド名
  3. コピー・オプション
    1. NULLの場合はコピー
    2. 上書き

ヒントと考慮事項

対応するマネージャ・レイアウトを設定するときに、次の手順を実行する必要があります。

フレックス・フィールドを定義して画面セットに含める必要があります。
この画面セットに割り当てられたマネージャ・レイアウトIDを使用して、この画面セットに関連付けられたビジネス・オブジェクトが表示されます。

ライセンス割当およびバランスを表示するレポート

この機能を使用すると、ライセンス明細が貿易トランザクションおよび直接調整でどのように使用されているかを確認できます。

このレポートには、「ビジネス・プロセス自動化」→「レポート」→「レポート・マネージャ」→「ライセンス割当レポート」からアクセスできます。

ライセンス明細ID、開始日および終了日、搬送レポートの形式(PDFやCSVなど)などのパラメータを入力するように要求されます。これらのパラメータによって、レポートに含められるデータの範囲が制限されます。

具体的には、次の情報がレポートに表示されます。

ライセンス識別
- ライセンスID
- ライセンス・カテゴリ、タイプおよびコード
- 管轄区域および制度
- 有効日
ライセンス明細識別
- ライセンス明細ID
- 明細タイプ
- 明細摘要
- 承認済数量
- 承認済値
開始数量および値バランス
貿易トランザクション明細または調整ごとに、次の情報が提供されます。
- 日付
- ユーザー
- 文書(トランザクション明細または調整)
- 数量
- 数量バランス
- 値
- 値バランス

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

トランザクションおよび申告に関する懸念パーティ・スクリーニングに停止信号を表示

この機能を使用して、貿易トランザクションに含まれるパーティの懸念パーティ・リスト・スクリーニング(RPLS)ステータスを停止信号インジケータを使用して可視化できます。パーティ・マスターからRPLSステータスが取得され、様々なアイコンで表示されます。

停止信号には次の事前定義済アイコンがあります。

白い実線の円: RPLS_NOT STARTED。パーティでRPLSプロセスが実行されていません。
感嘆符が含まれている黄色の三角形: ステータスはRPLS_REQUIRES REVIEWまたはRPLS_ESCALATEDです。
- RPLS_REQUIRES REVIEW: パーティでRPLSが実行され、一致するものが存在する能性があります。
- RPLS_ESCALATED: パーティでRPLSが実行され、拒否された1つ以上のパーティがエスカレート済に設定されています。
感嘆符が含まれている赤の円: RPLS_FAILED。RPLSがパーティで実行され、確認済/検証済一致が存在します。
チェック記号が付いた緑色の円: RPLS_PASSED。RPLSがパーティで実行され、その結果、一致が見つからなかったか、または一致が見つかったけれどもすべてに「一致しない」のマークが付いていました。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

出荷グループの関連貿易トランザクションの表示スマート・リンク

この機能により、出荷グループに関連する貿易トランザクションを表示できます。

出荷グループから、スマート・リンク「関連貿易トランザクションの表示」を使用して、関連貿易トランザクションを表示できます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

標準の画面セット・マネージャのスマート・リンク機能を使用して、出荷グループ・マネージャから貿易トランザクションの表示スマート・リンクを削除できます。

品目の分類タイプ/コード・レベルでの分類の承認または辞退

この機能では、「製品分類の承認または辞退」品目処理の対象を、指定した製品分類タイプに限定できます。品目に「製品分類の承認または辞退」処理を実行するときに、製品分類タイプIDを指定して分類ステータスを更新できるようになります。この拡張により、ユーザーは更新する製品分類タイプIDに絞って作業を実行できます。

製品分類タイプIDフィルタを使用した製品分類の承認または辞退

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

製品分類タイプIDを指定せずに「OK」をクリックした場合は、以前と同じ動作となります。つまり、品目の現在の製品分類タイプおよびコードがすべて表示されます。

製品分類を指定しない場合

品目の分類コードのカスタムの摘要

この機能により、品目に定義された各製品分類コードに対して税関の摘要を追加できます。税関組織によって求められる摘要が異なることがあるため、定義した各製品分類タイプおよびコードごとに異なる税関摘要を定義できます。「カスタムの摘要」フィールドは品目の「貿易詳細」タブの「製品分類」グリッドに表示されます。この摘要を文書で使用することができます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ワークベンチ - 作業キューのサポート

この機能は、拡張レイアウトの作業キューの概念に相当する処理と機能を提供します。作業キューを使用すると、ワークベンチ内でユーザーに一定期間またはユーザーがGTMからログアウトするまでの間だけレコードを割り当てることができます。これらの新しい機能を使用すると、ワークベンチを使用してニーズやユーザーに合せた作業環境を構成できます。作業キューはGTMの一部のオブジェクトで使用できます。ワークベンチを作成するときに、次のオブジェクトに関連する作業キューを含めることができます。

Item
貿易品目構造
貿易品目構造コンポーネント
パーティ
貿易トランザクション
貿易トランザクション明細
通関出荷(申告)
通関出荷明細(申告明細)
Contact

また、懸念パーティ・リスト・スクリーニング作業キュー用のワークベンチも構成できます。次の機能がサポートされます。

RPLSレビューを必要とするパーティ用の作業キュー
レビュー中でありエスカレーション済のパーティ用の作業キュー

各オブジェクトで提供される機能には次のものがあります。

担当者オブジェクトの場合
- 要検討、合格、失敗、エスカレート済、コメントの追加
懸念パーティに一致したパーティ・オブジェクトの場合
- 見込一致、一致しない、検証済一致、エスカレート済、照合ファクタの検討、コメントの追加

有効化のステップ

この機能を利用するには、次の手順が必要です。

新しいGTM作業キュー構成を追加します。
1. 作業キューIDを追加します(例: PARTY_WQ_REQUIRES REVIEW_WORK_QUEUE)。
2. オブジェクト・タイプ「担当者」を選択します。
3. フィルタ制限を定義します(例: 10)。これは各ユーザーに割り当てられるレコード数を示します。
4. 保存済問合せを選択します。システムによって提供される2つの公開保存済問合せがあります。
  1. PARTY_WQ_REQUIRES REVIEW。これはRPLSレビューを必要とするパーティの保存済問合せです。
  2. PARTY_WQ_ESCALATED。これはレビュー中でエスカレーション済のパーティの保存済問合せです。
5. 割当て期間を定義します(例: 5M)。これはレコードがユーザーに割り当てられる期間を示します。
6. ドメイン名を定義します(例: DOMAIN1)。
新しいワークベンチを追加します。
1. 「作成」(+)アイコンをクリックして新しいレイアウトを追加します。
  1. レイアウトIDを入力します(例: WORK_QUEUE_WORKBENCH_LAYOUT)。
  2. 摘要を入力します。
  3. 公開ロジック構成WORKBENCH DEFAULT PUBLICを選択します。
  4. レイアウト書式を選択します(例: デフォルト)。
  5. ドメインを選択します(例: DOMAIN1)。
  6. プロセスを完了して「OK」ボタンをクリックします。
  7. 「水平に分割」または「垂直に分割」アイコンを選択して、画面の分割方法を指定します。(この例では水平レイアウトを選択します)
  8. 画面の上部にコンテンツを追加します。
    1. 「コンテンツ」アイコンを選択します。
      1. コンポーネント・タイプ「表」を選択します。
      2. オブジェクト・タイプ「担当者」を選択します。
      3. タブ名(例: レビュー対象のパーティ)を選択します。
      4. 画面セットを選択します。これには、公開画面セットGTM_CONTACT_SCREENING_BOARD PUBLICを使用できます。
      5. チェック・ボックスの選択は解除したままにします。
      6. 入力方法として「作業キュー」を選択します。
      7. デフォルト作業キューを選択します(例: PARTY_WQ_REQUIRES REVIEW_WORK_QUEUE)
      8. プロセスを完了して「OK」ボタンをクリックします。
      9. 次に、画面の上部で作業キューPARTY_WQ_REQUIRES REVIEW_WORK_QUEUEを選択します。作業キューに基づいてパーティの情報が表示されます。
  9. ワークベンチの下部にコンテンツを追加します。
    1. コンポーネント・タイプ「表」を選択します。
    2. オブジェクト・タイプ「懸念パーティに一致したパーティ」を選択します。
    3. タブ名(例: 懸念パーティ見込一致)を選択します。
    4. 画面セットを選択します。これには、公開画面セットGTM_PARTY_SCREENING PUBLICを使用できます。
    5. 「詳細表」チェック・ボックスを選択します。
    6. レビュー対象パーティの保存済検索であるPARTY SCREENING MATCH QUERY PUBLICを選択します。これは公開問合せです。
  10. 画面の右上にある「完了」ボタンをクリックして、レイアウトの定義を完了します。画面の情報が移入されます。

ヒントと考慮事項

作業キュー・パラメータに指定された時間の間、レコード数が割り当てられます(たとえば、10件のレコードを5分間)。時間しきい値を過ぎてからレコードに戻って処理を実行しようとすると、レコードを保持していないことを示すエラーが表示されます。

現在のコンテンツ・バージョンでない懸念パーティに対して処理を実行しようとすると、懸念パーティが無効であることを示すエラーが表示されます。

GTMの方法/構成のトピック - 仕入先要請

仕入先要請に関するGTMの方法/構成のトピックを提供します。この方法のトピックには、GTMでキャンペーン管理と仕入先要請を正しく使用するための情報が記載されています。

次のトピックが含まれています。

サプライヤ要請について - GTMのキャンペーン管理および仕入先要請プロセスについての概要です。
仕入先要請: ビジネス・プロセス - 仕入先要請のビジネス・プロセスに関する詳細です。
仕入先要請: 構成ステップ - GTMでキャンペーン管理および仕入先要請を構成するためのステップです。
仕入先要請: プロセス・ステップ - キャンペーン管理および仕入先要請プロセスの主なステップに関する情報です。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

仕入先が仕入先ポータルで要請を管理したり応答したりできるようにするには、構成ステップの仕入先アクセス構成の詳細セクションを参照して、仕入先アクセスを構成してください。

GTMの方法/構成のトピック - 製品分類プロセス

製品分類に関するGTMの新しい方法/構成のトピックとして、製品分類プロセスのトピックを提供します。この方法のトピックには、GTMで製品分類を正しく使用するための情報が記載されています。

次のトピックが含まれています。

製品分類について: GTMでの製品分類プロセスの概要です。

製品分類: 基本設定 - 製品分類タイプ、製品分類コード、製品分類階層コードなど、基本設定要素に関する情報です。

分類調査: 設定およびプロセス - 分類データを参照するための分類調査の設定方法と使用方法の詳細。

変換参照: 設定およびプロセス - 分類コードをある製品分類タイプから別の分類タイプに変換するための、変換参照の設定方法と使用方法に関する詳細。

品目分類: 設定およびプロセス - 品目の分類に使用できる設定および処理に関する情報。

複数の製品分類コード - 特定の製品分類タイプに対して複数の分類コードを割り当てることができる場合の詳細。

6桁または8桁のHTSコードの割当 - 品目、品目構成、貿易トランザクションおよび申告への6桁または8桁の統一スケジュール・コードの割当に関する情報

プロセス管理 - プロセス管理で使用可能なオプションに関する詳細

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

「照合ファクタの検討」処理での逆インデックスの使用

この機能を使用すると、パーティに対して照合ファクタの検討処理を実行するときに逆インデックスを使用できます。

具体的には、次が追加されています。

新しいオプションのサポート:
- 逆インデックスがサービス・パラメータとして含まれているサービス・プリファレンス

有効化のステップ

この機能を利用するには、サービス構成を定義する際の標準の手順を実行します。

新しいサービス構成を追加します。
1. サービス構成IDを追加します。
2. ドメイン名を選択します。
3. サービス・プリファレンス詳細を選択します。
  1. 懸念パーティ・スクリーニング・サービスを選択します。
  2. 次のパラメータを含むサービス・プリファレンス構成を追加します。
    1. dataVersionList (例: dataVersionList=null)
    2. dataSource (例: dataSource=null)
    3. matchEngine (例: matchEngine=InverseIndex)
    4. threshold (例: threshold=0.5)
    5. excludeWords (例: excludeWords=null)
    6. listCode (例: listCode=null)
    7. screeningFieldParameter (例: screeningFieldParameter=RPLS.SERVPARA-INVERSEINDEX)

前述のパラメータを考慮したサービス・プリファレンス構成は次のようになります。dataVersionList=null, dataSource=null, matchEngine=InverseIndex, threshold=0.5, excludeWords=null, listCode=null, screeningFieldParameter=RPLS.SERVPARA-INVERSEINDEX

パーティに対して照合ファクタの検討を実行するときに、逆インデックスをパラメータとして含むサービス・プリファレンスを選択できます。

ヒントと考慮事項

ビジネス・ニーズによっては、「サービス・プリファレンス構成」でサービス・パラメータのしきい値および加重の調整が必要になります。

「関税プリファレンス・タイプ」から「貿易プリファレンス」への名前変更

GTMの関税プリファレンス・タイプが貿易プリファレンスという名前に変更されます。また、この情報をサード・パーティのデータ・プロバイダからダウンロードできるようになりました。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

仕入先情報の追跡

原産国管理を向上するため、品目原産表の新機能がGTMの品目に追加されました。品目に追加された品目原産グリッドを使用して、仕入先情報を追跡できるようになります。

品目原産グリッド

品目原産詳細

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

品目の「仕入先」グリッドは非推奨となり、将来のリリースで削除される予定です。

パーティ・スクリーニング結果のアクセシビリティ向上

この機能では、既存のハイライト表示に加えて、太字や下線付きのテキストとともに、パーティ・スクリーニング結果を表示できます。これにより、色覚に障害のあるユーザーがパーティの懸念パーティ一致の詳細を簡単に確認できるようになります。太字および下線付きのテキストは、製品の様々な領域に表示されます。

「パーティ」処理メニューの「スクリーニング結果の検討」処理
貿易トランザクションおよび申告の関連パーティに関連付けられた「パーティ・スクリーニング結果の表示」リンクの詳細内

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

製品分類タイプと貿易プログラム間のスマート・リンク

この機能を使用すると、製品分類タイプに関連付けられた貿易プログラムを表示できます。

製品分類タイプから「関連貿易プログラムの表示」スマート・リンクを使用して、特定の製品分類タイプに関連するすべての貿易プログラムを表示できます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

製品分類コードと運賃レート間のスマート・リンク

この機能を使用すると、製品分類コードに関連付けられた運賃レートを表示できます。

製品分類コードから「関連運賃レートの表示」スマート・リンクを使用して、特定の製品分類コードに関連するすべての運賃レートを表示できます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

GTMの方法/構成のトピック - ライセンス・スクリーニングの強化

ライセンス管理の方法のトピックが強化されます。また、トピックの名前が「ライセンス管理」から「ライセンス・スクリーニング」に変更されました。方法のトピックが全面的に強化され、次のような詳細が追加されます。

ライセンス・スクリーニングについて - GTMのライセンス管理およびライセンス・スクリーニング・プロセスの概要。
ライセンス・スクリーニング・ビジネス・プロセス - ライセンス・スクリーニングのビジネス・プロセスに関する情報。
ライセンス・スクリーニング構成ステップ - ライセンス管理およびライセンス・スクリーニング用にGTMを構成する手順。
ライセンス・スクリーニング・プロセス・ステップ - ライセンス・スクリーニング・プロセスの主なステップの詳細。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

AESの拡張

この機能により、AES申告機能が強化されます。規制の変更に基づいて、X12 .601 Customs & Border Protection (CBP)(輸出出荷情報の仕様)に関連するAESテンプレートが次のように更新されました。

9X515コードの規制変更のサポート - 9A515、9B515および9C515で始まるECCN USコードがX107要素のシリーズ600コードと同様に処理されるようになりました。

EIN (事業主識別番号)を申告者タイプIDとして使用可能 - ISA05要素でEINとDUNSがサポートされます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

オーダー・リリースから貿易トランザクション

この機能により、OTMオーダー・リリースからGTM貿易トランザクション処理の柔軟性が高まり、構成能力も高まります。新しい方法では柔軟なクオリファイア・マッピングがサポートされ、OTMオーダー・リリースからGTM貿易トランザクションに変更を伝播できるようになります。

具体的には、次が追加されています。

新しいオプションのサポート:
- OTMオーダー・リリースからGTM貿易トランザクション

次のことが可能です。
- OTMオーダー・リリースから新しいGTM貿易トランザクションを作成します。
- OTMオーダー・リリースから既存のGTM貿易トランザクションに変更を伝播します。
- 既存のGTM貿易トランザクションからOTMオーダー・リリースを削除します。

有効化のステップ

この機能を利用するには、データ構成を定義する際の標準の手順を実行します。

新しいデータ構成を追加します。
1. データ構成IDを追加します。
2. 「オーダー・リリースからトランザクション」関連タイプを選択します。
3. 関連を選択します。
  1. ヘッダー-ヘッダー
  2. 明細-明細
4. いずれかのフィールド・オプションを選択します。
  1. 日付フレックス・フィールド
  2. 関連パーティ
  3. 数値フレックス・フィールド
  4. 数量
  5. 参照番号
  6. 注釈
  7. 文字列フレックス・フィールド
  8. 値
5. 次に、選択したオプションに基づいて、属性詳細を定義します。
  1. ソース・フィールド名
  2. ターゲット・フィールド名
  3. コピー・オプション
    1. NULLの場合はコピー
    2. 上書き

このプロセスを実行するには、処理を実行する際の標準の手順を実行します。

既存のオーダー・リリースを作成または選択します。
「処理」メニューで「グローバル貿易管理」の下のオプションのいずれかを選択します。
1. 貿易トランザクションの作成
2. 貿易トランザクションに対する変更の伝達
3. 貿易トランザクションから削除
適切なデータ構成を入力または検索します。

ヒントと考慮事項

この機能は、データ構成ルールを設定する必要がないという点で、OTM出荷からGTM貿易トランザクションの機能と異なります。プロセスの実行時に直接データ構成が取得されます。

キャンペーン管理

この機能を使用して、キャンペーンおよび要請の文書や、取引先からのその他の情報を管理できます。多数の仕入先から同時に情報を収集できます。キャンペーン管理者は次のことを実行できます。

キャンペーン詳細を定義します。これにはキャンペーン管理に必要なパラメータやリクエストする文書のほか、データ構成やロジック構成などの処理詳細が含まれます。
認定情報など、文書およびデータを収集するためのキャンペーンを開始します。
キャンペーンの応答期日を取引先に通知します。
キャンペーンを監視し、取引先からの応答をレビューします。
取引先からの発行を承認または辞退します。
承認時にキャンペーン明細から品目原産にデータをコピーします。

仕入先などの取引先は次を実行できます。

キャンペーンの参加者であることの通知を受け取ります。
キャンペーン明細を確認し、原産データ、認定および要求文書を更新します。
キャンペーンに応答します。

キャンペーン管理者が設定できるデータには次のものがあります。

データ構成 ? GTMオブジェクト間でコピーするデータを決定します。たとえば、仕入先はキャンペーン明細でキャンペーンに応答するときに、原産国や原産地証明書といった重要情報を提供します。これらを品目上の品目原産にコピーできます。
- キャンペーンを作成するときに、「関連タイプ」 = 「パートナ品目からキャンペーン」を使用して、品目またはパートナ品目からキャンペーン明細に情報をコピーできます。
- キャンペーンを承認するときに、「関連タイプ」 = キャンペーン明細から品目を使用して、キャンペーン明細から品目に情報をコピーできます。

ロジック構成 ? キャンペーン・ワークフロー構成の詳細を定義します。使用するロジック構成タイプは、GTMキャンペーン構成で、次のような詳細を含めます。
- 一般 ? 所有者連絡先、受信連絡先、送信法的エンティティといった様々な関係者に使用する関連パーティ・クオリファイアを指定します。認定詳細を取引先上に表示するかどうかも指定できます。
- キャンペーンの作成 ? データ構成やキャンペーンIDのビジネス番号ジェネレータなど、キャンペーンを作成するときに使用する情報を指定します。
- キャンペーンの通知 ? 規制参照および通知で文書テンプレートを送信するかどうかを指定します。
- キャンペーンの承認 ? データ構成など、キャンペーンの承認時に使用する情報を指定します。

キャンペーンを作成するには、取引先品目で「キャンペーンの作成」処理を使用します。キャンペーンを作成するときには次のような情報を指定する必要があり、これらはキャンペーンにコピーされます。

キャンペーン・タイプ ? 作成するキャンペーンのタイプを指定します。キャンペーン・タイプ内でロジック構成が識別されるため、この必須フィールドはキャンペーンのワークフローの促進に役立ちます。
製品分類タイプ ? キャンペーンを作成する製品分類タイプを指定します。
キャンペーン管理者 ? キャンペーンを管理している個人を識別します。
リマインダ期間 ? このフィールドは将来の使用のために予約されています。
有効日と失効日 ? キャンペーンの開始日と終了日を指定できます。
目的 ? キャンペーンの目的に関する詳細を入力します。
貿易協定 ? 貿易協定に関連する情報を要請するためのキャンペーンであるかどうかを指定します。
必須文書 ? 特定の文書を取引先に要請するキャンペーンであるかどうかを指定します。

キャンペーン・マネージャからキャンペーンを管理できます。各キャンペーンには、次のような情報が含まれます。

キャンペーン・タイプ
有効日および失効日
リマインダ期間(将来の使用のため予約されています)
視点
製品分類タイプ
貿易協定
関連パーティ
参照番号、注釈およびフレックス・フィールド

各キャンペーン明細には特定の取引先の基本的な品目情報が明記され、応答が格納されます。キャンペーン明細には次のような情報が含まれています。

取引先品目
パーティ・サイト
製品分類タイプ/コード
貿易協定
原産国と原産有効日/失効日などの原産詳細
プリファレンス基準、Regional Value Content計算方法、プロデューサなどの認定詳細
値
関連パーティ
参照番号、注釈およびフレックス・フィールド
文書およびノート

キャンペーン管理者がキャンペーンを管理するときに使用できる処理があります。キャンペーン管理者は次のことを行うことができます。

文書の追加または管理
キャンペーンの承認
取引先に通知を送信
キャンペーン・ステータスの設定

キャンペーン明細マネージャを使用して、次のようなキャンペーン明細に固有の処理をトリガーできます。

文書の追加または管理
キャンペーン明細の承認または辞退
キャンペーン明細またはパートナ発行への応答
キャンペーン明細のステータスの設定

また、ワークベンチを作成してユーザーが簡単にキャンペーンの詳細とキャンペーン明細を管理できるようにすることもできます。キャンペーンおよびキャンペーン明細のワークベンチを簡単に作成できるように、保存済問合せが用意されています。

キャンペーンが作成されると、仕入先またはその他の取引先が自身の取引先品目およびパーティ・サイトのキャンペーン明細を見ることができます。キャンペーン明細が使用可能になったときに、GTMから仕入先に通知を送信できます。通知には次のものが含まれます。

必須データを完成させる手順および証明書やその他の文書を提供する必要があるかどうかの指示
キャンペーンへのリンク
応答の送信期限

仕入先ポータルを使用して、仕入先または取引先は要求された情報を提供できます。仕入先ポータルを構成する必要があります。仕入先ポータルでは次のことが可能です。

仕入先固有の品目データの表示および編集機能
文書をアップロードする機能

仕入先ポータルにログインして、キャンペーン情報とキャンペーン明細情報の両方を表示できます。キャンペーン明細では、取引先または仕入先が次のような情報を追加または更新できます。

原産国と原産有効日/失効日
認定の詳細(適格の可否、プリファレンス基準、Regional Value Content計算方法、プロデューサ、認定有効日/失効日など)
値
関連パーティ
参照番号、注釈およびフレックス・フィールド
備考

証明書または文書が必須の場合、仕入先はキャンペーン明細で「文書の追加」処理を使用できます。キャンペーン明細にすべてのデータおよび文書を追加したら、仕入先は「キャンペーン明細への応答」処理を使用してキャンペーン管理者に情報を送信し、レビューおよび承認を受けます。

有効化のステップ

GTMでは、SERVPROVドメインを介して管理される既存のサービス・プロバイダ・ポータルが再利用されています。仕入先ポータルを使用するには、次のような特定の構成手順を実行する必要があります。

VPDプロファイル
アクセス・コントロール
ユーザー・ロール
ユーザー・メニューおよびアクセス

ヒントと考慮事項

リマインダ機能は現在非アクティブです。「キャンペーン」ヘッダーおよび「キャンペーンの作成」処理に表示される「リマインダ期間」フィールドは、将来の使用のために予約されています。

「キャンペーンの作成」処理で仕入先担当者をキャンペーン明細にコピーすることはできません。回避策としては、直接SQLエージェント処理を使用して、キャンペーン作成時にこの情報をコピーする方法をお薦めします。

主なリソース

仕入先ポータルの設定の詳細は、ヘルプで仕入先アクセス構成のページを参照してください。

品目原産に基づく貿易プログラムの適格性および認定の決定

この機能を使用して品目原産の適格性詳細を管理し、関税や税の引き下げが可能かどうかを判断できます。この機能を使用して、売りと買いの両方の品目について、この情報を管理できます。

品目マネージャで品目に対して運賃適格スクリーニング処理を実行し、関連付けられている品目原産データに基づいて、その品目で貿易プログラムを利用できるかどうかを判定できます。この手動処理をトリガーすると、基準を満たすすべての貿易協定が表示されます。

貿易プログラムの対象となる品目原産を確認することで、どの貿易プログラムがどの品目に適格なのかがわかります。適格性を判定する際は、次のような基準を考慮します。

貿易プログラムの原産ルールを満たしているか。
どのようなRegional Value Content計算方法(RVC)が使用されているか。
関税分類変更はあるか。
デミニマス・ルールは適用されるか。

品目内の「貿易詳細」タブで品目原産詳細を確認できます。各品目原産で、表示された貿易プログラムを適用する資格が自社にあるかを確認できます。自社に適用できる各貿易プログラムをマークし、ステータスを設定できます。GTMにはすぐに使用できるステータスが用意されており、品目原産に関連付けられた貿易プログラムに設定できます。

貿易プログラム情報は該当する品目原産に割り当てられます。これには次のような補助情報が含まれています。

製品分類タイプおよびコード ? この品目原産/貿易プログラムのペアに対して製品分類タイプとコードを定義できます。
貿易プログラム ? 特定の品目原産の貿易プログラムを指定します。
貿易協定 ? 貿易プログラムに貿易協定が関連付けられている場合、表示されます。
ステータス ? 特定の品目原産/貿易プログラムのペアのステータスを表示します。GTMにはすぐに利用できる次のステータスが付属しています。
- 資格あり
- 中止
- 適格
- 不適格
適格フラグ ? 品目原産が特定の貿易プログラムの対象であるかどうかを示します。
有効日と失効日 ? 認定詳細の開始日と終了日を指定できます。
プリファレンス基準 ? 貿易プログラムの対象であるかを判断するための原産基準を定義します。
Regional Value Content計算方法 ? 貿易プログラム対象の品目原産であるかを判断するためのRegional Value Content計算方法を指定します。これは貿易プログラムの原産ルールの一部です。
プロデューサ ? 仕入先が商品の生産者(製造業者など)であるかどうかを示します。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

品目に品目原産情報を移入するには次の2つの方法があります。
- UIから手動で。
- 品目の運賃適格スクリーニング処理をトリガーします。
運賃適格スクリーニング処理をトリガーする前に、品目に品目原産情報が入力されている必要があります。
認定を実行するには、品目に貿易プログラムが入力されている必要があります。
認定詳細はキャンペーン管理者と、仕入先またはパートナといった取引先が入力できます。

品目タイプの指定

購入した品目なのか製造した品目なのかによってグローバル貿易プロセスを使い分ける顧客をサポートするため、品目タイプが導入されました。この機能により、品目に新しいデータ要素が提供され、ERPで定義されている品目タイプを識別できます。品目タイプの例は、購買品目、製造品目、サービス品目などです。これにより、Oracle製品スイート全体で一貫性が生まれ、原産国追跡のための情報でユーザーの決定が通知されます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

貿易品目の品目への名前変更

OTMおよびGTMの統合品目マネージャの導入に伴い、GTM貿易品目が品目に名前変更されました。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

原産管理

品目の原産管理機能が強化されました。品目の新しい「貿易詳細」タブに「品目原産」グリッドが表示されます。品目原産を在庫組織やパートナまたはパートナ・サイト(あるいはそのすべて)ごとに区別できます。また、詳細レベルで品目原産を追跡する必要がなければ引き続き、「貿易詳細」タブの品目レベルの「デフォルト原産国」を使用できます。

次のような品目原産詳細を作成および管理できます。

在庫組織、パートナおよびパートナ・サイト ? 品目原産を在庫組織レベルまたはパートナ/パートナ・サイト・レベルで追跡できます。

原産国 ? 特定の品目原産の原産国を指定します。

製造国 ? 特定の品目原産の製造国を指定します。

有効日と失効日 ? 品目原産の開始日と終了日を指定できます。

値 ? 特定の品目原産の購買価格などの値情報を指定します。

フレックス・フィールド ? 標準フレックス・フィールド機能を使用して、会社固有のニーズ(シリアル番号、シリアル番号の範囲、ロット番号など)をモデル化します。

貿易プログラム ? 品目原産が貿易プログラムの対象であると判定されると、貿易プログラム・グリッドにデータが移入されます。また、適格チェック・ボックスを選択して、その品目原産が特定の貿易プログラムの対象であることを示すことができます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

品目に原産管理情報を移入するには次の2つの方法があります。

UIを使用して品目原産データを手動で入力します。

キャンペーン仕入先要請を使用してパートナから原産データを収集します。原産データは仕入先によってキャンペーン明細に入力されます。特定の仕入先および取引先の原産情報を、キャンペーン明細から品目にコピーできます。

注意: 品目原産の導入により、品目の「仕入先」グリッドは非推奨となり、将来のリリースで削除される予定です。

パーティ・サイト

パーティ機能が拡張され、パーティ・サイトの定義が含まれるようになりました。親のパーティを作成するときにパーティ・サイトを関連付けることができます。

パーティ・サイトは、パーティ・タイプ組織の支店または事務所として定義されます。パーティ・サイトはパーティとロケーションをリンクします。

有効化のステップ

パーティ・サイトの追加には、次の作業が含まれます。

「パーティ・サイトID」フィールドにパーティ・サイトのIDを入力します。
「パーティ・サイト名」フィールドにパーティ・サイト名を入力します。
「パーティ・サイト」に関連する「パーティ」フィールドに既存のパーティのパーティIDを入力します。
パーティ・サイトに関連する既存のロケーションのロケーションIDを入力します。

ヒントと考慮事項

EBS-GTM統合に対して拡張は行われていません。

運賃レートの管理

関税、税および貿易プログラム情報をサードパーティのデータ・コンテンツ・プロバイダからダウンロードできるようになります。この情報がGTMに格納され、品目の関税の適格性や認定をサポートするために使用されます。関税や税は特定のHSコードに関係するため、ダウンロードした運賃レートは既存のGTM製品分類タイプおよび製品分類コード・オブジェクトに関連付けられます。現在のデータ・ダウンロード・プロセスが拡張され、これらのデータがサポートされるようになりました。設定すると、次の情報をサード・パーティのデータ・コンテンツ・プロバイダからダウンロードできます。

貿易プリファレンス ? 商品の関税処理をモデル化するために使用されます。このデータをサポートしているのは、欧州連合などの特定の制度のみです。例として、「GSPに基づく輸入税率の引き下げ」や「ACP国間の協定」などがあります。以前のバージョンのGTMでは、ユーザーが貿易プリファレンスを入力していました。このデータをサード・パーティのデータ・コンテンツ・プロバイダからダウンロードできるようになりました。これは以前から存在するデータ構造で、以前は関税プリファレンス・タイプと呼ばれていました。

貿易プログラム・タイプ: 一般、特別、輸入規制など、様々なタイプの運賃レートをモデル化できます。

貿易プログラム ? 一般レート、GSP-Aレート、カリブ海経済回復促進法レートなどの運賃レートを定義する様々なプログラムをモデル化します。貿易プログラムにはメンバーの国のリストが含まれています。デフォルトで、貿易プログラムはGTMの貿易協定にリンクされていません。ただし、この情報を貿易プログラム内で追加できます。

運賃レート ? 製品分類タイプ/コードと貿易プログラムに関連付けられる実際の運賃レートを定義します。

次の図は、GTM内の運賃データの関係を示しています。

GTM内の運賃データの関係

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

ヒントと考慮事項

現行の製品分類データのダウンロードが拡張され、運賃データが含まれるようになりました。拡張された運賃情報の利用に際して実行する手順が必要かどうかは、ご利用のコンテンツ・プロバイダに確認してください。

次の現行機能では引き続き、サード・パーティのデータ・コンテンツ・プロバイダに対するリアルタイムの外部コールを使用して関税および税情報を取得します。
- 荷揚原価シミュレータ
- 貿易トランザクションおよび申告に対する「関税および税の見積」処理
- 製品分類コードに対する「関税および税の表示」処理

取引先品目

この機能により、取引先品目という新しいオブジェクトを使用して特定の仕入先または顧客の品目詳細を管理できるようになります。取引先品目を品目に追加すると、品目とその品目に関連するすべての取引先品目を簡単に確認できるようになります。

次のような詳細を含む取引先品目を作成および管理できます。

取引先タイプ ? 仕入先や顧客など、取引先のタイプを指定できます。
取引先 ? 取引先品目に関連付けられている取引先のIDおよび詳細を識別します。
取引先識別子 ? パートナの外部システム内での取引先品目の識別子を指定します。
取引先名 ? パートナの外部システム内での取引先品目の名前を指定します。
有効日と失効日 ? 取引先品目の開始日と終了日を指定できます。
注釈、参照番号、フレックス・フィールド ? 注釈、参照番号および標準フレックス・フィールド機能を使用して、取引先品目に関する追加情報をモデル化します。

取引先品目に対し、次の手動の処理を実行できます。

取引先品目のコピー
キャンペーンの作成
「文書の生成」や「文書のアップロード」など、文書ベースの処理
「インタフェース・トランスミッションの送信」、「イメージの設定」、「インジケータの設定」などのユーティリティ

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

貿易コンプライアンス

その他の管理タイプに対する自動例外のサポート

この機能により、「管理カテゴリ」 = 「その他」を自動的にリリースできます。GTMを使用してライセンス要件に基づかないトランザクション「保留」をモデル化するときに、「管理カテゴリ」 = OTHER_EXCEPTIONを使用するコンプライアンス・ルールを作成すると、それらの保留を自動的にリリースできます。トランザクション明細の「その他の管理スクリーニング結果」グリッドに、その他の理由の保留の詳細が表示されます。この機能は申告でも使用できます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

貿易協定

GTMに貿易協定という新しい領域が導入されます。貿易協定とその補助情報を使用することで、関税や税の引き下げ効果を得られる貿易協定を積極的に利用できます。世界中には様々な貿易協定があり、それぞれ必要なパラメータが異なりますが、概ね次のような構造になっています。

貿易協定に関連付けられている関税および税を活用するには、次が必要になります。

原産ルールに従い、商品が特定のプログラムの適用資格を満たすようにします。
原産地証明を作成し、顧客に提供します。
仕入先から原産地証明を収集し、将来の使用に備えて保管します。
輸入入力プロセス時に貿易協定の使用する意図を示し、適切な原産地証明を現地の関税局に送付します。

GTMでは、次のような貿易協定機能を利用できます。

サード・パーティのデータ・コンテンツ・プロバイダから関税、税、貿易プログラムおよびその他の情報をダウンロードし、保存します。
貿易協定情報の管理。
品目に対して、貿易協定適格スクリーニングと認定を実行します。
キャンペーンを作成し、認定データや文書、貿易プログラムの使用に必要なその他の情報を仕入先に要請します。
仕入先およびその他のユーザーは受信したキャンペーンに応答できます。

貿易協定の管理

この機能により、GTMで貿易協定の詳細を管理できます。使用する貿易協定および次のような補助データを作成して管理できます。

貿易協定タイプ ? 貿易協定をグループ化できます。たとえば、貿易協定を特恵(自由貿易または貿易削減)か非特恵であるか、またはその他の任意の区分でグループ化できます。

短縮名 ? 貿易協定の頭字語や短縮名を指定します。たとえば、北米自由貿易協定の短縮名はNAFTAです。

アクティブ・フラグ ? 現在使用されている貿易協定であるかどうかを示します。

有効日と失効日 ? 貿易協定の開始日と終了日を指定できます。\\データ・バージョン ? 該当する貿易協定のバージョンを指定します。

メンバーの国 ? 現行のリージョン機能を使用して、貿易協定に参加しているメンバー国を定義します。

注釈、参照番号、フレックス・フィールド ? 注釈、参照番号および標準フレックス・フィールド機能を使用して、貿易協定に関する追加情報をモデル化します。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

貿易協定のスマート・リンク

この機能を使用すると、貿易協定に関連するデータを表示できます。

貿易協定から、次のことを可能にするスマート・リンクを使用できます。

関連貿易プログラムの表示 - このスマート・リンクでは、特定の貿易協定に関連するすべての貿易プログラムを表示できます。
関連キャンペーンの表示 - このスマート・リンクでは、特定の貿易協定に関連するすべてのキャンペーンを表示できます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

Global Trade Intelligence (GTI)

ライセンスおよびライセンス明細の内訳およびディメンションが使用可能

Global Trade Intelligenceに2つの新しい分析フォルダが追加されます。「ライセンス分析」および「ライセンス明細分析」フォルダを使用して、ライセンスおよびライセンス明細データに基づいて独自のレポートを作成できます。

ライセンス分析内訳には、ライセンス数が含まれています。ライセンス分析ディメンションには、日付、関連パーティ、および詳細ディメンション(制度、コンプライアンス・データ、ロケーション、参照番号、ユーザー定義コードなど)が含まれています。

ライセンス明細分析内訳には、ライセンス明細数、承認済数量/値、有効数量/値、予約済数量/値、使用済数量/値などが含まれています。ライセンス明細分析ディメンションには、日付、ドメインおよび詳細なディメンション(制度、コンプライアンス・データ、製品、注釈、参照番号など)が含まれています。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

新しい数量および原価の内訳が使用可能

Global Trade Intelligence製品に新しい列が追加されます。

新しい数ベースの内訳は次のとおりです。
- 「貿易トランザクション分析」→「貿易トランザクション内訳」: 「オーダー済数」内訳および「出荷済数」内訳を使用して、貿易トランザクションのオーダー済データと出荷済データに基づいてレポートを作成できます。
- 「申告分析」→;「申告内訳」: 「オーダー済数」内訳および「出荷済数」内訳を使用して、申告のオーダー済データと出荷済データに基づいてレポートを作成できます。

新しい原価ベースの内訳は次のとおりです。
- 「貿易トランザクション明細分析」→「貿易トランザクション明細内訳」: 「請求金額ベース」内訳を使用して、貿易トランザクション明細の請求金額に基づいてレポートを作成できます。
- 「申告明細分析」→「申告明細内訳」: 「請求金額ベース」内訳を使用して、申告明細の請求金額に基づいてレポートを作成できます。

有効化のステップ

この機能を有効化するうえで必要なステップはありません。

---

この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、契約上の直接的および間接的義務も発生しません。本書は、事前の書面による許諾を得ることなく、電子的または機械的に、いかなる形態または手段によっても複製または伝送することはできません。

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Incの商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

完全な著作権表示