オーダー・プロファイルを使用したOrder Managementの動作の制御
事前定義済のプロファイル値を管理して、Oracle Order Managementでの動作を制御します。
ほとんどのプロファイルには事前定義済の値が含まれているため、ニーズにあわせて異なる値を必要としないかぎり、プロファイルを設定する必要はありません。
オーダー・プロファイルの管理
-
「設定および保守」作業領域に移動してから、タスクに移動します。
-
オファリング: オーダー管理
-
機能領域: オーダー
-
タスク: オーダー・プロファイルの管理
-
-
「オーダー・プロファイルの管理」ページのプロファイル・オプション領域で、「検索」をクリックします。
-
検索結果のプロファイル・オプション・リストで、編集する必要がある「プロファイル」をクリックします。
-
プロファイル値リストで、必要に応じて値を追加または削除します。
オーダー・プロファイルの階層
異なるレベルでプロファイルを設定して、階層を指定できます。
製品またはユーザーの値を設定する前に、プロファイル・オプションにサイト値を設定することをお薦めします。
レベル
優先度
例
サイト
最下位
すべてのオーダー管理に影響します。
たとえば、すべてのオーダー管理の通貨をユーロに設定します。
製品
サイトより高い
品目にのみ影響します。
たとえば、AS54888品目の通貨をRenminbiに設定します。
ユーザー
製品より高い
現在のユーザーのみに影響します。
たとえば、ユーザーの通貨をUSドルに設定します。
各プロファイルは単一のサイトに対してのみ使用できますが、1つのサイトおよび各ユーザーに対して、インポート時に通貨換算タイプおよび販売オーダー番号を保持できます。
オーダー・プロファイル
|
プロファイル・オプション |
説明 |
|---|---|
|
通貨換算タイプ |
オーダー管理作業領域で通貨を換算するときに使用する値を指定します。 この値は変換タイプです。 |
|
表示通貨 |
オーダー管理がデフォルトでオーダー管理作業領域に表示する通貨を指定します。 |
|
履行ラインで日付変更を許可するまでの待機時間 |
このトピックの次のセクションを参照してください。 |
| 親から子への販売実績のマップ | 親構成品目の販売実績を、まだクレジットがない子構成オプションの販売実績にマップします。 例について考えてみます。
|
|
概要ステータス・フィルタ要 |
オーダー管理作業領域の概要ページでステータス・データの要約をフィルタリングする際に使用するデフォルト顧客を指定します。 ユーザーは、一度に1人の顧客の要約データのみを表示できます。 すべてオプションが削除されます。 デフォルトでは、オーダー管理には値がありません。 パフォーマンスを向上させるために、顧客識別番号を入力できます。 |
|
インポート中に販売オーダー番号を保持 |
詳細は、「インポート時にオーダー番号を保持」を参照してください。 |
| 各時間のオーダー明細の合計数 | 通常処理するオーダー明細の平均数を1時間で指定します。 |
| 売掛/未収金の属性値の切捨て | このトピックの次のセクションを参照してください。 |
|
ユーザー・リクエスト待機期間(秒) |
アクションの終了後に待機する秒数を指定します。 この時間により、各非同期webサービスが終了してから、オーダー管理作業領域に確認メッセージまたは警告メッセージを表示できます。 デフォルト値は、5です。 |
| 販売オーダーの手数料および手数料コンポーネントの検証 | このトピックの次のセクションを参照してください。 |
管理者プロファイルの管理
オーダー・プロファイルを変更して、実装を管理できます。 管理者プロファイルの変更が必要になる場合もあります。
- 「設定および保守」作業領域に移動し、「タスク」>「検索」をクリックします。
- 検索ページで、管理者プロファイル値の管理を検索して開きます。
- 「管理者プロファイル値の管理」ページで、値を検索します。
属性 値 プロファイル・オプション・コード ORA_FOM
FOMは、Oracle Order Managementの以前の名前であるFusion Order Managementを意味します。
- 検索結果を確認します。 Order Managementの動作を制御するために使用できる様々なプロファイルが含まれています。 プロファイルの説明を読み、概要を確認します。 詳細は、次のヘルプ・トピックを参照してください:
プロファイル・オプション・コード ヘルプ・トピック ORA_FOM_COPY_EFF_ON_CPLN オーダー管理での拡張可能フレックスフィールドの使用の概要 ORA_FOM_GET_CUSTOMER_ITEM オーダー管理での顧客品目 ORA_FOM_SHOW_MARGIN 販売オーダーの価格設定方法 ORA_FOM_ENABLE_CARD_PAYMENT オーダー管理でのクレジット・カード機能の有効化 ORA_FOM_DEFAULT_ADJ_REASON - 「管理者プロファイル値の管理」ページで、値を検索します。
属性 値 プロファイル・オプション・コード ORA_DOO
DOOは、分散オーダー・オーケストレーションを意味し、Oracle Order Managementの以前の名前でもあります。
これらの日、分散オーダー・オーケストレーションは、オーダー履行への販売オーダーの送信後にOrder Managementが実行するオーケストレーションに主に適用されます。
- 検索結果を確認します。 Order Managementの動作を制御するために使用できる様々なプロファイルが含まれています。 プロファイルの説明を読み、概要を確認します。 詳細は、「管理者プロファイル」サブトピックを参照してください。
管理者プロファイル
|
プロファイル・オプション |
説明 |
|---|---|
|
ORA_DOO_DS_FDTL_AR_MAPPING 直接出荷の履行詳細を売掛/未収金に送信 |
このオプションは事前定義されており、サイト・レベルが無効になっています。 これを有効にすると、オーダー管理によって直接出荷の履行詳細が売掛/未収金に送信されます。 運送状番号、船荷証券などが送信されます。 |
|
ORA_FOM_RESPOND_ON_SUBMISSION_START 送信リクエストの開始時に即時応答 |
オーダー・ハブREST APIの販売オーダーが受信した各リクエストにいつレスポンスを送信するかを指定します。
詳細および例については、「Oracle Supply Chain Management CloudのREST API」に移動し、Order Managementを展開して、Order Hubの販売オーダーをクリックします。 |
| ORA_DOO_FULFILLMENT_TASK_RETRIES | 「履行タスク再試行」サブトピックを参照してください。 |
|
ORA_DOO_ENABLE_AGGR_V2 変更されたオーダー明細数に従った集計 |
このオプションは、変更されたオーダー明細の数に応じてオーダー明細を集計します。 デフォルト値は「はい」です。 詳細は、『履行明細の集計』サブトピックを参照してください。詳細は、「直送の機能の設定、変更の管理など」の履行明細の集計サブトピックを参照してください。 時間またはルーティング・ルール内の明細数に従って明細を集計するには、いいえに設定します。 詳細は、「オーダー管理が履行システムに送信するリクエストの集計」を参照してください。 このオプションは、直接出荷のオーダー明細にのみ適用されます。 ソース・オーダーで発生する変更に適用されます。 |
|
ORA_DOO_AGGR_HOLD_TIMEOUT 総計保留タイムアウト期間(分) |
アグリゲータは、調達の購買オーダーに保留を適用して、集計中に他のプロセスでオーダーが更新されないようにします。 オーダー明細の集計中にタイムアウトするまで保留操作が待機する分数を指定します。
アグリゲータ・プロファイルを一緒に使用します。 変更されたオーダー明細数に従って集計を有効にしない場合、オーダー管理では総計保留タイムアウト期間(分)は無視されます。 |
| ORA_FOM_DEFAULT_BUSINESS_UNIT |
オーダー・ヘッダーのビジネス・ユニット属性にOrder Managementで設定する値を、デフォルトで指定します:
|
ORA_FOM_ORCH_PROCESS_BATCH_SIZE 大量の販売オーダーに対して同時に開始するオーケストレーション・プロセスの数 |
販売オーダーに対して同時に開始するオーケストレーション・プロセス・インスタンスの数を指定します。 このプロファイルを使用して、大規模な販売オーダーのパフォーマンスを向上できます。 事前定義済のShipOrderGenericProcessオーケストレーション・プロセスを使用し、販売オーダーに5,000行あり、このプロファイルを次のように設定するとします:
デフォルト値は100です。 目的のパフォーマンスが得られるまで、デフォルト値から開始し、変更してテスト環境のパフォーマンスを監視し、本番環境の値を設定することをお薦めします。 |
ORA_FOM_POPULATE_VALUES_ON_SPLIT_LINE 当初明細からの値を分割明細に移入 |
このオプションを有効にし、ユーザーが「履行明細の分割」ダイアログで行を分割した場合、オーダー管理は分割明細の値を元の行の値で移入します。 ノート
|
| ORA_DOO_RECOMPUTE_PROMISE_DATE | 「Order Managementでの日付の再計算にGlobal Order Promisingを使用」サブトピックを参照してください。 |
|
ORA_DOO_SKIP_AVAILABILITY 品目の検索時に有効数量をスキップ |
ユーザーがカタログ明細の品目を検索するときのパフォーマンスが向上します。 このオプションをはいに設定すると、オーダー管理では、品目が使用可能かどうかを判断するためのリクエストがGlobal Order Promisingに送信されません。 Global Order Promisingを使用しない場合は、このオプションをはいに設定します。 |
|
PricingTotalsおよび価格設定検証をスキップ |
パフォーマンスの向上。 ユーザーがカタログ明細で追加をクリックしたときに、価格を検証せず、販売オーダーの合計価格を計算しません。 オーダー管理では、ユーザーがオーダーをドラフトとして保存するか、発行をクリックした場合にのみ、販売オーダー合計が計算されます。 |
履行タスク再試行
明細がロックされているか待機タスクに問題がある場合に、オーダー管理が履行タスクを再実行してから履行システムに応答を送信する回数を設定します。
プロファイル値属性に値を入力する必要があります。 次の書式を使用します:
task_type#times_to_retry,task_type#times_to_retry,task_type#times_to_retry,task_type#times_to_retry
説明
- task_typeは、履行タスクのタイプを識別します。
- times_to_retryは、タスクを再試行する回数を指定します。
- タスク・タイプは任意の順序で指定できます。 たとえば、最初にすべてを指定し、次に出荷、調達、一般を指定できます。
タスク・タイプの指定
task_typeには、次の値を使用します。
| 値 | 説明 |
|---|---|
| 出荷 | 出荷タスク・タイプに関連するすべての履行タスクを再試行します。 |
| DOO_Procurement | 調達タスク・タイプに関連するすべての履行タスクを再試行します。 |
| DOO_$GENERIC$ | これはプロファイル値です。 作成したすべての履行タスクが再試行されます。 作成する履行タスクの詳細は、「自分のタスク・タイプの作成」を参照してください。 |
| DOO_$ALL$ | これはプロファイル値です。 すべての事前定義済履行タスクと、作成したすべてのカスタム・タスクが再試行されます。 |
書式の要件に注意してください。 次の手順を実行する必要があります:
- GENERICおよびALLのDOO_プレフィクスを含めます。
- DOO_GENERICおよびDOO_ALLにはすべて大文字を使用します。
- DOO_GENERICおよびDOO_ALLをドル記号($ $)で囲みます。 たとえば、DOO_$ALL$およびDOO_$GENERIC$です。 ドル記号はワイルドカードです。
- カンマを使用して各値を区切ります。
コード内のどこにもスペース文字を含めないでください。
事前定義済タスク・タイプの指定
事前定義済の各タスク・タイプの名前(大文字を含む)を正確に一致させる必要があります。 一部の事前定義済タスク・タイプにはDOO_プレフィクスが含まれますが、含まれないものもあります。 必要なフォーマットを決定する方法を次に示します:
- 「設定および保守」作業領域に移動してから、タスクに移動します。
- オファリング: オーダー管理
- 機能領域: オーダー
- タスク: タスク・タイプの管理
- 「タスク・タイプの管理」ページで、Task Type列の値を確認します。 この値を使用する必要があります。 たとえば:
- スケジュールにDOOプレフィクスがないため、スケジュール・タスク・タイプのプレフィクスを含めないでください。
- DOO_ProcurementにはDOOプレフィクスがあるため、DOO_Procurementタスク・タイプのプレフィクスを含める必要があります。
再試行時間の指定
times_to_retryには、次のガイドラインを使用します。
- 最小値として0、最大値として9を指定します。
- 9より大きい値を指定すると、オーダー管理では9が使用されます。 たとえば、再試行を10に設定すると、オーダー管理は、履行タスクをエラーで応答する前に9回再実行しようとします。
- 指定した回数後にOrder Managementが履行タスクを処理できない場合は、履行システムにエラーを送信します。
- 指定する値は、サーバーのパフォーマンスによって異なります。 高い値を指定するとパフォーマンスが低下することがわかった場合は、小さい値を使用します。
例
例について考えてみます。
Shipment#5,DOO_Procurement#4,DOO_$GENERIC$#7,DOO_$ALL$#3
この例では、オーダー管理によって再試行されます:
- 出荷タスク5回
- 調達タスク4回
- 一般タスク7回
- 出荷、調達および汎用タスクを除くすべてのタスクを3回
優先度の検討
DOO_ALLの優先度が最も低い。 出荷、DOO_ProcurementまたはDOO_GENERICの値を指定し、DOO_ALLの値も指定した場合、オーダー管理では、Shipment、DOO_ProcurementまたはDOO_GENERIC、DOO_ALLの順で指定する値が使用されます。
次のものを提供すると仮定します:
DOO_$ALL$#4,DOO_$GENERIC$#6,Shipment#5
Order Managementは、作成するすべての履行タスクを6回、すべての出荷タスクを5回、その他すべてのタスクを4回再試行します。
ノート
- プロファイル・オプション・コードはORA_DOO_FULFILLMENT_TASK_RETRIESです。
- 一部の履行タスクの返信を受信しない場合があります。 たとえば、Order Managementでは、直接出荷フローで履行タスクの再試行が試行されますが、返信は送信されません。
- レスポンスは即時または遅延が可能です。 遅延レスポンスがあるとは、必ずしも問題があることを意味するわけではありません。 たとえば、オーダー管理は出荷タスクの終了を待機しているため、そのタスクが完了するまでレスポンスを送信できません。 または、他の多数の明細が処理されており、履行タスクが他の明細で実行されるまで処理できない場合があります。 遅延レスポンスの詳細は、「オーダー管理を履行システムに接続する概要」および「オーダー管理を履行システムに接続」を参照してください。
履行ラインで日付変更を許可するまでの待機時間
オーダー入力スペシャリストが直接出荷の履行明細の属性を更新できるようにするまでの待機時間数を指定します。
オーダー管理では、これらの条件のいずれかがtrueの場合に属性を変更できます。
-
Oracle Procurementで購買依頼が作成されていません。
-
このプロファイルで指定する時間が経過しました。
-
予定出荷日または予定到着日が発生しました。
デフォルト値は4時間です。
直接出荷を含むオーダー明細を追加し、販売オーダーを発行すると、オーダー管理は履行明細をOracle Procurementに送信し、Procurementは品目の購買依頼を作成するフローを開始しますが、フローが終了するまで更新をオーダー管理に送信しません。 履行明細が購買依頼と一貫性を保つために、オーダー管理では、調達から購買依頼を受け取るまで履行明細を変更できません。 通常、調達では数分以内に購買依頼が作成されますが、場合によってはレスポンスが遅延したり、オーダー管理でレスポンスが受信されないことがあります。
購買依頼を再処理するには、履行明細の属性値を編集する必要がある場合があります。 このプロファイル・オプションを使用して、待機時間を指定します。 たとえば、Procurementからのレスポンスの中には、終了までに1時間かかるものの、2時間を超えることはないという経験から学習した場合は、このプロファイルを3に設定します。 これにより、オーダー入力スペシャリストは、レスポンスが遅延している間は属性を変更できません。
各時間のエラーのオーダー明細のパーセント
「エラーのリカバリ」スケジュール済プロセスの実行時に発生する可能性のあるパフォーマンスの問題を回避するには、毎時におけるオーダー明細の合計数プロファイルと毎時処理するエラー明細の割合プロファイルを一緒に使用します。
これらの値を設定するとします。
| プロファイル・オプション | 値 |
|---|---|
| 各時間のオーダー明細の合計数 | 25000 |
| 各時間のエラーのオーダー明細のパーセント | 10 |
2,500は25,000の10%であるため、エラーのリカバリ・スケジュール済プロセスでは、1時間にエラーのあるオーダー明細が約2,500件リカバリされます。 エラーの実際の明細数が2,500回(約5,000回)を大幅に超える場合、エラーのリカバリ・スケジュール済プロセスでは、約2時間で明細のリカバリが試行されます。
Percent of Order Lines in Error in Each Hourを保守的に設定します(10%など)。 多数の明細でエラーが発生することが予想されない通常の営業日に機能する値に設定します。
エラーの明細を通常よりもはるかに高速にリカバリする必要がある場合にのみ、エラーのオーダー明細のパーセントを毎時間増やします。 たとえば、サーバーが停止するなど、エラーが蓄積する原因になります。 増やすと、次のようになります:
-
徐々に増やし、パフォーマンスを観察し、ビジネス要件を満たす値を使用します。
エラーの回復プロセスを実行する時間を考えてみます。 サーバーで多くのリソースを消費する他のアクティビティが実行されていない場合に実行してください。
-
パフォーマンスの監視。 観察したパフォーマンスに従って、必要に応じてこれらのプロファイルの値を調整します。
このトピックの値は、値の例です。 推奨ではありません。 ビジネス要件を満たすには、独自の値を使用する必要があります。
詳細は、すべての販売オーダーのエラー修正を参照してください。
売掛/未収金の属性値の切捨て
「売掛/未収金の属性値の切捨て」プロファイルを使用して、Order Managementから売掛/未収金に送信される属性値の一部を切り捨てます。 プロファイルを次のように設定できます:
- はい。 属性値を推奨される長さに切り捨てます。
- いいえ。 値は切り捨てないでください。
Order Managementは、これらの受注明細属性を請求のために売掛管理に送信します。
| 属性 | 最大推奨長 |
|---|---|
|
船荷証券 搬送名 |
各属性の値は30文字を超えないようにしてください。 |
| 手数料コンポーネント説明 | 属性の値は240文字を超えないようにしてください。 |
これらの属性のいずれかに対してOrder Managementが送信する値が売掛管理が使用する長さと一致しない場合、売掛管理で請求が失敗します。 この問題を回避するには、推奨される長さを超えないように長さを切り捨てる必要があります。
- 販売オーダーをインポートまたは改訂するときにPreCreditCheckedFlag属性をYに設定し、インポートまたは改訂の「与信チェック承認番号」属性の値が30文字を超える場合、Order Managementでは「与信チェック承認番号」の値は切り捨てられませんが、かわりに販売オーダーは拒否されます。
- Order Managementは、Oracle Accounts Receivableと統合する場合にのみこの動作を適用します。 これは、他の売掛/未収金消込と統合する場合には適用されません。
- Order Managementでは、プロファイルの設定方法に関係なく、販売オーダーをインポートするときに「与信チェック承認番号」属性が検証されます。
プロファイル・コードはFOM_TRUNCATE_AR_ATTRIBUTE_VALUESです。
例
たとえば、プロファイルを有効にすると、Order Managementによって値が切り捨てられ、30文字を超えないようにするとします。
| 属性 | プロファイルが有効ではありません | プロファイル使用可能 |
|---|---|---|
| 船荷証券 |
この値は57文字です:
|
この値は30文字です:
|
| 搬送名 |
この値は57文字です:
|
この値は30文字です:
|
プロファイルを有効にすると、Order Managementによって値が切り捨てられ、240を超えないようになります。
| 属性 | プロファイルが有効ではありません | プロファイル使用可能 |
|---|---|---|
| 手数料コンポーネント説明 |
この値は262文字です:
|
この値は240文字です:
|
グローバル・オーダー納期回答を使用してオーダー管理で日付を再計算
このオプションを有効にした場合:
-
Oracle Procurementで約束出荷日または約束到着日を変更した場合
-
または、Oracle Manufacturingで作業指示日を変更した場合
-
または、Oracle Inventoryでリクエスト日を変更した場合
その後、Order ManagementはGlobal Order Promisingを使用して、Order Managementの販売オーダーの予定出荷日または予定到着日を計算します。
この動作を適用するタイミングを決定するプロファイル値を指定します。
| 値 | 説明 |
|---|---|
| バック・トゥ・バック | この動作は、バック・トゥ・バック・フローでのみ適用します。 |
| 直接出荷 | この動作は、直送を含む販売オーダーにのみ適用します。 |
| バック・トゥ・バックおよび直接出荷 | バック・トゥ・バック・フローおよび直接出荷を含む販売オーダーでこの動作を適用します。 |
| バック・トゥ・バックと直接出荷のいずれでもない | この動作を販売オーダーに適用しないでください。 これがデフォルト値です。 |
ノート
-
オーダー管理では、改訂された予定出荷日または予定到着日がOracle Procurementに送信されないため、オーダー管理の販売オーダーの日付がProcurementの購買オーダーの日付と一致しません。
-
この機能は、グローバル・オーダー納期回答を使用するオーケストレーション・プロセスでのみ使用できます。
-
このオプションは、単一のサイトに対してのみ使用できます。
-
バイヤーが輸送を管理する場合、オーダー管理は購買オーダーのリクエスト搬送日を販売オーダーの予定到着日にマップします。 オーダー管理とGlobal Order Promisingでは、予定到着日を再計算するときにリクエスト搬送日の値が無視されます。
バイヤーが輸送を管理する場合の例
ノート
|
バイヤーによる輸送の管理 |
バイヤーが輸送を管理しない |
|---|---|
|
Global Order Promisingで、移動リード・タイムを5日間に設定したとします。 |
Global Order Promisingで、移動リード・タイムを3日間に設定したとします。 |
|
バイヤーは、調達の約束出荷日を改訂できます。 |
バイヤーは約束搬送日を改訂できますが、調達の約束出荷日は改訂できません。 |
|
Global Order Promisingでは、予定到着日が更新されます。 |
Global Order Promisingでは、予定出荷日が更新されます。 |
販売オーダーの手数料および手数料コンポーネントの検証
このプロファイル・オプションを使用して、手数料および手数料コンポーネントに関連する各属性を検証します。 これらの属性は、履行レスポンス・サービスまたはオーダー履行レスポンス・サービスからOrder Managementに送信するレスポンスで指定します。 詳細は、「Order Managementの統合に使用できるWebサービス」を参照してください。
このプロファイルはデフォルトの「はい」の値のままにすることをお薦めします。 使用不可にすると、Order Managementでは、インポートした手数料および手数料コンポーネントの値は検証されません。
プロファイルを有効にする場合は、インポート・ペイロードが検証要件を満たしていることを確認する必要があります。
各オーダー手数料エンティティの検証
| 属性 | ペイロードに含める必要がある | Oracle Pricingにすでに存在している必要があります |
|---|---|---|
| ApplyTo | Y | Y |
| ChargeDefinitionCode | Y | Y |
| ChargeSubTypeCode | Y | Y |
| ChargeTypeCode | Y | Y |
| PricePeriodicityCode | Y | Y |
| PriceTypeCode | Y | Y |
| SourceChargeIdentifier | Y | N |
ノート
- 「ペイロードに含める必要がある」は、インポート・ペイロードに属性を含める必要があることを意味します。
- 「Oracle Pricingにすでに存在している必要があります」は、インポート・ペイロードの属性に指定する値がOracle Pricingのデータにすでに存在している必要があることを意味します。
- ChargeSubTypeCode属性で指定する参照コードが、ORA_QP_CHARGE_SUBTYPES価格設定参照で有効になっていることを確認します。
- ChargeTypeCode属性で指定する参照コードが、ORA_QP_CHARGE_TYPE価格設定参照で有効になっていることを確認します。
- 繰返し料金がある場合のみ、pricePeriodicityCodeを含めます。
次の属性のインポート・ペイロードに指定する値の組合せに対して、Oracle Pricingに手数料定義が存在することを確認する必要があります:
- ChargeDefinitionCode
- ChargeTypeCode
- ChargeSubtypeCode
- PriceTypeCode
各手数料コンポーネント・エンティティの検証
| 属性 | ペイロードに含める必要がある | Oracle Pricingにすでに存在している必要があります |
|---|---|---|
| ChargeCurrencyCode | Y | Y |
| HeaderCurrencyCode | Y | Y |
| HeaderCurrencyDurationExtendedAmount | Y | N |
| HeaderCurrencyExtendedAmount | Y | N |
| HeaderCurrencyUnitPrice | Y | N |
| PriceElementCode | Y | Y |
| PriceElementUsageCode | Y | Y |
| SourceChargeComponentIdentifier | Y | N |
ノート
- 手数料に複数の定価または複数の正価が含まれていないことを確認してください。
- オーダー履行レスポンス・サービスでは、SourceChargeComponentIdentifierのかわりにChargeInterfaceKeyが使用されます。
- 繰返し料金がある場合のみ、HeaderCurrencyDurationExtendedAmountを含めます。
- PriceElementUsageCodeは、定価または正価にのみ使用します。
各手数料階層エンティティの検証
| 属性 | ペイロードに含める必要がある | Oracle Pricingにすでに存在している必要があります |
|---|---|---|
| AdjustmentAmount | Y | N |
| ApplicationMethod | Y | N |
| ApplicationMethodCode | Y | N |
| BlockSize | Y | N |
| SourceOrderChargeTierId | Y | N |
| TierFrom | Y | N |
| TierSequenceNumber | Y | N |
| TierTo | Y | N |
ノート
- ApplicationMethodに値を含める場合は、BlockSizeにも値を含める必要があります。
- TierToの値がTierFromの値以上であることを確認してください。