異なる種類のデータのインポート
異なる種類のデータをインポートする場合はガイドラインを適用してください。
新規顧客
ファイルベース・データ・インポート(FBDI)を使用して、取引先コミュニティ・アーキテクチャに存在しない顧客、担当者または住所をインポートする場合は、「インポート用のインタフェース・ファイルのロード」スケジュール済プロセスを実行するユーザーのロールに権限を手動で割り当てる必要があります。
権限 |
説明 |
---|---|
HZ_ENTER_TRADING_COMMUNITY_PERSON_PRIV |
取引先コミュニティ個人の入力 |
HZ_UPDATE_TRADING_COMMUNITY_PERSON_PRIV |
取引先コミュニティ個人の更新 |
HZ_ENTER_TRADING_COMMUNITY_ORGANIZATION_INFORMATION_PRIV |
取引先コミュニティ組織情報の入力 |
HZ_UPDATE_TRADING_COMMUNITY_ORGANIZATION_PRIV |
取引先コミュニティ組織の更新 |
権限を追加する方法について学習します。 詳細は、「データ・セキュリティ」を参照してください。
下書き販売オーダー
ダウンストリーム履行の問題を回避するために、下書きステータスの販売オーダーをインポートすることが重要である場合があります。 たとえば、販売オーダーをインポートし、在庫レベルが変動しているため、オーダーが出荷待ちステータスのままにならないように、数量を変更する必要があるとします。 ドラフトとしてインポートし、ダウンストリーム履行要件を満たすようにオーダー管理作業領域で数量を変更して送信できます。
インポートした注文を履行に送信せず、かわりに下書き販売オーダーとしてインポートする場合:
テクノロジのインポート |
説明 |
---|---|
FBDI |
オーダー・インポート・テンプレートのDOO_ORDER_HEADERS_ALL_INTワークシートで、 |
REST API |
Order Hub REST APIリソースのSales OrdersでSubmittedFlag属性をfalseに設定します。 Falseは、REST APIのデフォルト値です。 詳細および例については、「Oracle Supply Chain Management CloudのREST API」に移動し、Order Managementを展開して、Order Hubの販売オーダーをクリックします。 |
Webサービス |
webサービス・ペイロードでSubmittedFlag属性をNに設定します。 |
ドラフトでの改訂のインポート
FBDI、REST APIまたはwebサービスを使用して下書き販売オーダーをインポートする場合は、下書きを変更する別のインポートを実行すると、オーダー管理によって新しいオーダー番号が下書きに割り当てられます。
後続の更新または処理では、新しいオーダー番号を使用する必要があります。 たとえば、FBDIを使用してソース・オーダー57486をインポートし、オーダー管理で57486がドラフトとして保存されているとします。 次に、FBDIを使用して、オーダー57486の日付属性への変更をインポートします。 オーダー管理では、57490などの新しいオーダー番号が作成され、57490に変更が保存されます。 オーダー管理では、オーダー57486のすべてのデータ(適用した保留を含む)が削除されます。 オーダー57486は使用できなくなりました。 オーダー57490を使用する必要があります。
改訂
下書きオーダーをインポートする場合は、オーダー管理作業領域で変更して発行し、後続のインポートでオーダーの改訂をインポートした後、インポートした改訂に現在の属性値が含まれている必要があります。 属性値を変更する場合は、インポートされた改訂に新しい値が含まれている必要があります。
たとえば、出荷方法属性のデフォルト値を設定するオーダー管理拡張を設定するとします。 出荷方法の値をインポートし、オーダー管理作業領域で出荷方法を鉄道に変更し、オーダーを発行してから、後続のインポートでオーダー改訂をインポートします。 Railを保持する場合は、後続のインポートに出荷方法用のRailの値を含める必要があります。 後続のインポートに出荷方法の値が含まれていない場合、オーダー管理では、変換前ルールに応じて出荷方法が他の値に設定されます。
RevisionSourceOrderSystem属性
RevisionSourceOrderSystem属性を使用して、販売オーダーの改訂を送信するソース・システムを識別できます。 処理制約でRevisionSourceOrderSystemを使用すると、ソース・システムからリビジョンをインポートするときに許可する変更を制御できます。
RevisionSourceOrderSystemは、改訂のドラフトの作成時または発行時にオーダー管理が実行する他の処理には影響しません。 たとえば、オーダー管理では、RevisionSourceOrderSystemの設定方法に従って新しい改訂は作成されません。
次のように仮定します。
-
オーダー45768の改訂1(明細1に数量10、このオーダーのインポート・ペイロードにRevisionSourceOrderSystemはEastSystem含む)をインポートします。
-
ソース・システムEastSystemからオーダー45768のリビジョン2をインポートし、インポート・ペイロードのRevisionSourceOrderSystemにEastSystemが含まれ、インポートによって数量5の行2が追加され、ドラフト・ステータスのままになります。
-
インポート・ペイロード内の別のシステムWestSystem、RevisionSourceOrderSystemから改訂1の更新をインポートすると、WestSystemが含まれ、インポートによって行1から7の数量、行2から5の数量が更新され、オーダーが発行されます。 オーダー管理はこの更新を送信し、EastSystemから受信したリビジョン2を上書きします。 発行されたオーダーには、明細1に数量7、明細2に数量5が含まれます。 オーダー管理では、3番目の改訂は作成されません。
クローズ済オーダー明細
すでにクローズされているオーダー明細をインポートできますが、クローズした明細を処理しないようにオーケストレーション・プロセスを変更する必要があります。
すべてのクローズ済オーダー明細をインポートする必要があるとします。
-
事前定義済DOO_BillOnlyGenericProcessオーケストレーション・プロセスを複製します。
詳細は、「オーケストレーション・プロセスの設定」を参照してください。
-
重複する名前をインポート済販売オーダーの即時クローズに変更します。
-
請求書の作成ステップで明細選択基準を修正します。
-
請求書の作成ステップの明細選択基準列で「ルールのクリック」をクリックします。
-
「明細選択基準セット」ダイアログのIf領域で、最初の条件を次のように変更します。
If 1 is 2
1は2になることはないため、この条件によって、オーダー明細の請求をスキップしてオーダー明細を即時にクローズするようにオーケストレーション・プロセスに指示されます。
-
If領域の他のすべての条件を削除します。
-
-
新しいオーケストレーション・プロセスをリリースしてデプロイします。
-
販売オーダーのプロセス割当ルールの管理タスクを使用して、要件に従って新しいオーケストレーション・プロセスを割り当てる割当ルールを作成します。 インポート・ペイロードでステータス値クローズ済を使用して、クローズ済明細を示しているものとします。 これがあなたのルールです。
If Status Code (Order Fulfill Line) is equal to Closed, then Process Name is set to Immediately Close Imported Sales Orders
詳細は、「オーダー管理でのビジネス・ルールの使用の概要」を参照してください。
-
販売オーダーをインポートします。
カスタム・オーケストレーション・プロセスは、基準を満たす販売オーダーをただちにクローズします。
構成品目
ノート
- インポートでは、親構成モデルとその子構成オプションの関係を維持する必要があります。
- 構成モデルには、1つ以上の子構成オプションを設定できます。 子構成オプションには、1つ以上の子を含めることもできます。
4本の線を含むモデルがあるとします。 行1はルートの親で、行2は行1の子です。 2行目もモデルであり、3行目と4行目は2行目の子です。 階層は次のようになります。
Line 1
Line 2
Line 3
Line4
説明
-
SourceTransactionLineIdは親です
-
ParentSourceTransactionLineIdは、子エンティティの親を識別します。
階層を正しく保持するペイロードを次に示します。
"lines": [{
"SourceTransactionLineId": "1",
"SourceTransactionLineNumber": "1",
"SourceScheduleNumber": "1",
"SourceTransactionScheduleId": "1",
"OrderedUOMCode": "Ea",
"OrderedQuantity": 1,
"ProductNumber": "PTO54222",
"RequestedFulfillmentOrganizationId": 204
},
{
"SourceTransactionLineId": "2",
"SourceTransactionLineNumber": "2",
"SourceScheduleNumber": "1",
"SourceTransactionScheduleId": "1",
"OrderedUOMCode": "Ea",
"OrderedQuantity": 1,
"ProductNumber": "OP44136",
"RequestedFulfillmentOrganizationId": 204,
"ParentSourceTransactionLineId": "1"
},
{
"SourceTransactionLineId": "3",
"SourceTransactionLineNumber": "3",
"SourceScheduleNumber": "1",
"SourceTransactionScheduleId": "1",
"OrderedUOMCode": "Ea",
"OrderedQuantity": 1,
"ProductNumber": "KB18761",
"RequestedFulfillmentOrganizationId": 204,
"ParentSourceTransactionLineId": "2"
},
{
"SourceTransactionLineId": "4",
"SourceTransactionLineNumber": "4",
"SourceScheduleNumber": "1",
"SourceTransactionScheduleId": "1",
"OrderedUOMCode": "Ea",
"OrderedQuantity": 1,
"ProductNumber": "KB18759",
"RequestedFulfillmentOrganizationId": 204,
"ParentSourceTransactionLineId": "2"
}
]
説明
-
"SourceTransactionLineId": "1"
は、行1がルートの親であることを指定します。 -
SourceTransactionLineId 2エンティティの
"ParentSourceTransactionLineId": "1"
は、行1が行2の親であることを指定します。 -
SourceTransactionLineId 3エンティティの
"ParentSourceTransactionLineId": "2"
は、行2が行3の親であることを指定します。 -
SourceTransactionLineId 4エンティティの
"ParentSourceTransactionLineId": "2"
は、行2が行4の親であることを指定します。
次に、5行目を追加し、このコードを使用します。
"SourceTransactionLineId": "5",
"SourceTransactionLineNumber": "5",
"SourceScheduleNumber": "1",
"SourceTransactionScheduleId": "1",
"OrderedUOMCode": "Ea",
"OrderedQuantity": 1,
"ProductNumber": "KB18760",
"RequestedFulfillmentOrganizationId": 204,
"ParentSourceTransactionLineId": "9"
}
]
ParentSourceTransactionLineIdの値が9ですが、ペイロードに9を含むSourceTransactionLineIdがないため、このインポートは失敗します。
出荷セットまたはキット
セットまたはキットを含む行のPartialShipAllowedFlag属性をNに設定する必要があります。
カバレッジおよびサブスクリプション
インポート・ペイロードの各カバレッジ品目が、対象にする対象品目を含む一意の履行明細を参照していることを確認してください。 履行明細を分割すると、これらの各明細は同じソース明細を参照します。 1行目を1-1行目と1-2行目に分割するとします。 明細1-1と明細1-2は両方とも同じソース明細を参照し、ソース明細は一意ではないため、ソース明細を使用してカバレッジを追加できません。 明細は一意である必要があります。
カバレッジを含むペイロードの例を次に示します。
<ns2:DocumentReference>
<ns2:DocumentReferenceType>COVERAGE_COVERED_ASSOCIATION</ns2:DocumentReferenceType>
<ns2:DocumentIdentifier>300100546398344</ns2:DocumentIdentifier>
<ns2:DocumentSubLineIdentifier>3001005463983461</ns2:DocumentSubLineIdentifier>
</ns2:DocumentReference>
<ns2:DocumentReference>
<ns2:DocumentReferenceType>SOURCE_COVERAGE_COVERED_ASSOC</ns2:DocumentReferenceType>
<ns2:DocumentIdentifier>jm_PDSC_PTO_IC_12_08_01</ns2:DocumentIdentifier>
<ns2:DocumentAdditionalIdentifier>GPR</ns2:DocumentAdditionalIdentifier>
<ns2:DocumentNumber>jm_PDSC_PTO_IC_12_08_01</ns2:DocumentNumber>
<ns2:DocumentLineIdentifier>104</ns2:DocumentLineIdentifier>
<ns2:DocumentAdditionalLineIdentifier>101</ns2:DocumentAdditionalLineIdentifier>
<ns2:DocumentSubLineIdentifier>101</ns2:DocumentSubLineIdentifier>
</ns2:DocumentReference>
在庫
ロットとシリアル
オーダー・インポート・サービスwebサービスを使用し、オーダー明細のロットおよびシリアル詳細をインポートする場合は、インポート・ペイロードのLotSerialエンティティに、オーダー明細のこれらの属性の少なくとも1つに値が含まれている必要があります。
-
LotNumber
-
SerialNumberFrom
-
SerialNumberTo
-
ItemRevisionNumber
-
保管棚
-
LocatorIdentifier
LotSerialエンティティでこれらの属性の値を指定しない場合。
-
インポートでは、DOO_LOT_SERIAL_NUMBERS表のロットまたはシリアルのレコードは作成されません。
-
また、SourceTransactionLotIdentifier属性に値を指定すると、インポートでエラーが表示されます。
保管場所
インポートでSubInventoryCode属性に値が含まれている場合は、次のことを確認する必要があります:
-
品目を履行するためにオーダー明細で指定するリクエスト履行組織には、オーダー明細で指定する保管場所が含まれます。
-
保管場所の終了日は将来に発生するか、保管場所を収集する前に空です。
-
保管場所を収集します。
たとえば、完成品保管場所を使用して、Vision Manufacturing組織のオーダー明細を履行する必要があるとします。 完成品保管場所の保管場所コードはFGIです。 インポートが機能することを確認する方法を次に示します。
-
「設定および保守」作業領域に移動してから、タスクに移動します。
-
オファリング: 製造およびサプライ・チェーン資材管理
-
機能領域: 在庫管理
-
タスク: 保管場所および保管棚の管理
-
-
表示されたダイアログで、Vision Manufacturing組織を選択します。
-
「保管場所の管理」ページで、値を検索します。
属性
値
保管場所
FGI
検索結果に完成品保管場所が含まれていない場合は、追加するか、オーダー明細で別の保管場所を使用する必要があります。
説明
完了製品
-
検索結果の値を確認します。
属性
値
終了日
将来、または空です。
日付が過去に発生した場合は、値が空になるように変更するか、将来発生するようにする必要があります。
-
「設定および保守」作業領域で、タスクに移動します。
-
オファリング: オーダー管理
-
機能領域: オーダー
-
タスク: オーダー参照データの収集
-
-
表示されたページで、「参照データ」をクリックします。
-
保管場所を選択したエンティティ・ウィンドウに移動し、「送信」をクリックします。
これにより完成品保管場所が収集され、オーダー・オーケストレーションおよびプランニング・データ・リポジトリで使用できるようになります。
このページの使用方法について学習します。 詳細は、オーダー管理のプランニング・データの収集を参照してください。
-
ダイアログに表示される値に注目し、OKをクリックします。
この例では、値が107610であるとします。
-
スケジュール済プロセス作業領域に移動し、値を確認します。
属性
値
名前
収集ジョブ・セット
プロセスID
107610
ステータス
成功
ソース・オーダーの明細番号のプリフィクス
ソース・オーダー明細番号にインポートする値は英数字である必要があります。 数値を使用しないでください。 ソース・オーダー明細番号属性の値の前にテキスト値を指定し、意味のあるテキストを使用することをお薦めします。 たとえば、LEGを使用して、LEG_576849などのレガシー・システムを識別します。
明細番号の表示
ペイロードに、オーダー管理作業領域で履行明細番号を正確に表示するために必要なすべてのデータがあることを確認してください。
オーダー管理のデータには、表示行番号がFulfillLineId属性とFulfillLineNumber属性(300100562534985 1-1など)の連結として格納されます。 salesOrdersForOrderHub Rest APIは、Order Management作業領域に表示されるのと同じ連結形式で履行明細を返します。
次に、いくつかの例を見ていきます。 例が示すように、salesOrdersForOrderHub REST APIペイロードが履行明細を表していることを確認する必要があります。
履行明細の分割の例
2つの履行明細に分割したオーダー明細があるとします。 次に、salesOrdersForOrderHub REST APIペイロードがこれらの行を表す方法の例を示します。
{
"lines" : {
"items" : [
{
"FulfillLineId" : 300100562534985,
"DisplayLineNumber" : "1-1",
"FulfillLineNumber" : "1"
},
{
"FulfillLineId" : 300100562535469,
"DisplayLineNumber" : "1-2",
"FulfillLineNumber" : "2"
}
]
}
}
単一のitems
エンティティには、分割履行明細ごとに1つのグループのFulfillLineId、DisplayLineNumberおよびFulfillLineNumber属性が含まれ、DisplayLineNumberには、オーダー管理作業領域に表示されるのと同じ値(1-1など)があることに注意してください。
単一のOrderLine
エンティティには1つのDisplayLineNumberエンティティが含まれ、DisplayLineNumberエンティティには分割履行明細ごとにFulfillLineIdおよびFulfillLineNumber属性のグループが含まれていますが、DisplayLineNumberには1-1の値がありません。
カバレッジがある履行明細の分割の例
オーダー明細を2つの履行明細に分割し、明細にカバレッジ品目が含まれているとします。 次に、salesOrdersForOrderHub REST APIペイロードがこれらの行を表す方法の例を示します。
{
"lines": {
"items": [
{
"FulfillLineId": 300100565241163,
"DisplayLineNumber": "1:1-1",
"FulfillLineNumber": "1"
},
{
"FulfillLineId": 300100565241034,
"DisplayLineNumber": "1:1-2",
"FulfillLineNumber": "2"
}
]
}
}
たとえば、このペイロードは履行明細300100565241034のDisplayLineNumber属性を1:1-2
に設定します。 オーダー管理作業領域には、1:1-2
値も表示されます。
- コロンの前の1は、対象行のDisplayLineNumberを表します。
- コロンの後の1は、カバレージのシーケンス番号を表します。 たとえば、
1:1
は、同じ対象明細に別のカバレッジがあることを意味します。1はカバレッジの順序番号です。 - ダッシュは、オーダー管理がオーダー明細を複数の履行明細に分割することを意味します。 この例では、履行明細1と履行明細2です。
- ダッシュの後の2は、2番目の分割明細である履行明細2を表します。
構成品目のある分割履行明細の例
項目 | DisplayLineNumber |
---|---|
AS54888デスクトップ・コンピュータ | 1 |
ストレージ・オプション区分 | 1.1 |
1 テラバイト・ハード・ドライブ | 1.1.1 |
2 テラバイト・ハード・ドライブ | 1.1.2 |
ポート・オプション区分 | 1.2 |
USB 3.0ポート | 1.2.1 |
USB 2.0ポート | 1.2.2 |
ノート
- AS54888ルート品目のDisplayLineNumberは1であるため、AS54888のすべての子品目も1で始まります。
- ストレージ・オプション区分品目のDisplayLineNumberは1.1であるため、ストレージ・オプション区分のすべての子品目も1.1で始まります。
- ルート品目が常に1であるとは限りません。 たとえば、AS54888がある行を手動で削除し、下書き順序でAS54888を含む新しい行を追加すると、オーダー管理はAS54888のDisplayLineNumberを1から2に変更し、AS54888のすべての子品目も2から始まるように変更します。
1テラバイトのハード・ドライブ品目に対して数量2のオーダー・ラインがあるとします。 数量1を履行するのに十分な供給しかないため、オーダー管理はそのオーダー明細を2つの履行明細に分割します。 次に、salesOrdersForOrderHub REST APIペイロードがこれらの行を表す方法の例を示します。
{
"lines": {
"items": [
{
"FulfillLineId": 300100563721562,
"DisplayLineNumber": "1.1.1-1",
"FulfillLineNumber": "1"
},
{
"FulfillLineId": 300100563723289,
"DisplayLineNumber": "1.1.1-2",
"FulfillLineNumber": "2"
}
]
}
}
このペイロードは、履行明細300100563721562のDisplayLineNumber属性を1.1.1-1
に設定します。 オーダー管理作業領域には、1.1.1-1
値も表示されます。
- 最初の1は、構成品目のルート明細を表します。
- 2番目の1は、Storageオプション・クラスを表します。
- ダッシュの前の1は、1テラバイトのハード・ドライブ構成オプションを表します。
- ダッシュは、オーダー管理が履行明細を分割することを意味します。
- ダッシュの後の1は、1テラバイト・ハード・ドライブ構成オプションの最初の履行明細を表します。
当初オーダー参照
originalOrderReferenceエンティティを使用するための具体的なガイドラインがあります。 詳細は、「返品オーダーの処理のガイドライン」を参照してください。