この更新で選択されたオーダー管理のバグ修正
この更新には、Oracle Order Managementの動作を変更する不具合修正が含まれています。 これは、この更新に関するすべてのバグ修正の完全なリストではありません。 このリストには、アプリケーションの動作に顕著な変化をもたらす可能性のあるバグ修正が含まれています。
販売オーダーのインポート時にサプライヤ番号およびサプライヤ・サイト・コードを含める
25Dを更新する前に、SalesOrdersforOrderHubまたはSalesOrdersforOrderHubRequests REST API、またはSourceSalesOrderImportTemplate.xlsm FBDIテンプレートを使用して販売オーダーをインポートしたときに、サプライヤ番号を使用してサプライヤを識別したり、サプライヤ・サイト・コードを使用してサプライヤ・サイトを識別できませんでした。
更新25D以降では、SalesOrdersforOrderHubまたはSalesOrdersforOrderHubRequestsを介してインポートするときに、SupplierNumber属性にサプライヤ番号、およびSupplierSiteName属性にサプライヤ・サイト・コードを含めることができます。 SourceSalesOrderImportTemplate.xlsmを介してインポートする場合は、「リクエスト済サプライヤ番号」属性にサプライヤ番号を、リクエスト済サプライヤ・サイト・コード属性にサプライヤ・サイト・コードを含めることができます。
Oracleリファレンス: 38059874
出荷セットでの一貫したリクエスト・タイプのインポート
RequestType属性には、出荷セット内の各オーダー明細に同じ値が含まれている必要があります。
25Dを更新する前に、REST APIを介して改訂をインポートし、インポート・ペイロードで同じ出荷セット内の明細間でRequestTypeの値が異なる場合、Order Managementではこれらの値の一部が変更されて一貫性が保たれ、インポートは成功しましたが、履行中にスケジューリング・エラーが発生しました。
更新25Dから、出荷セット内の複数の明細にわたってRequestTypeに異なる値をインポートすると、インポートは失敗し、エラー・メッセージで応答します。
Oracleリファレンス: 38106968
出荷タスク後の請求書タスクの追加
更新25Dの前に、出荷タスクなどの履行タスクの前にオーケストレーション・プロセスに請求書タスクを追加した場合、次の理由でスタックした販売オーダーが発生している可能性があります:
- インポートに必須出荷属性がありませんでした。
- Order Managementで出荷後にオーダー明細を正しく補正できませんでした。
明細はすでに請求されているため、これらの問題を解決できません。
更新25D以降、Order Managementでは次のことができません:
- 出荷、DOO_Procurementまたは返品履行タスクの前に請求書タスクを追加します。 新規オーケストレーション・プロセスの作成時に適用されます。
- 履行タスクを設定する前に、請求書タスクを設定します。 オーケストレーション・プロセスの改訂時に適用されます。
Oracleリファレンス: 37587558
返品の法的エンティティを当初と一致させる
受注を作成し、その法的エンティティをVision Manufacturingに設定する受注管理拡張を記述するとします。ただし、ビジネス・ユニットのデフォルト法的エンティティはVision Salesです。 オーダーを送信、出荷およびクローズします。 次に、参照される返品を作成しますが、必要なもの(Vision Manufacturing)ではなく、法的エンティティのVision Salesが返品に含まれていることを確認します。 返品時にVision Manufacturingが必要な場合は、次の拡張を使用します。
import oracle.apps.scm.doo.common.extensions.ValidationException;
//Extension - default legal unit and validate it against all return lines.
Map<Long, Set<String>> legalUnitIdsToDlnMap = new HashMap<>();
def lines = header.getAttribute("Lines");
while( lines.hasNext() ) {
def line = lines.next();
def rootId = line.getAttribute("RootParentLineReference");
def flineId = line.getAttribute("FulfillmentLineIdentifier");
if (rootId == null || rootId == flineId) {
def origOrder = line.getOriginalOrderForReferencedReturn();
// origOrder can be null if the current line object is not a return line or is an unreferened line.
if (origOrder != null) {
def origOrderLegalUnitId = origOrder.getAttribute("RequestingLegalUnitIdentifier");
if (origOrderLegalUnitId != null) {
if (!legalUnitIdsToDlnMap.containsKey(origOrderLegalUnitId)) {
Set<String> displayLineNumbers = new HashSet<>();
legalUnitIdsToDlnMap.put(origOrderLegalUnitId, displayLineNumbers);
}
legalUnitIdsToDlnMap.get(origOrderLegalUnitId).add(line.getAttribute("SourceTransactionLineNumber"));
}
}
}
}
int size = legalUnitIdsToDlnMap.size();
if (size == 0) return;
if (size == 1) header.setAttribute("RequestingLegalUnitIdentifier", legalUnitIdsToDlnMap.keySet().iterator().next());
if (size > 1) {
def sourceOrderId = header.getAttribute("SourceTransactionIdentifier");
def sourceOrderSystem = header.getAttribute("SourceTransactionSystem");
def orderKey = sourceOrderSystem + ":" + sourceOrderId
throw ValidationException("In order " + orderKey + ", the original orders of the return lines have different legal units. Refer to lines " + legalUnitIdsToDlnMap.values());
}
Oracleリファレンス: 33013626
REST APIを使用した、保留を適用およびリリースするユーザーの識別
salesOrdersForOrderHubペイロードのRequestedBy属性を使用して、オーダー明細の保留を適用またはリリースしたユーザーを識別できるようになりました。 この例では、DOO_SHIP_ALL保留を適用したユーザーとしてcflureyを識別します。
{
"processRequestOfflineAfter": 240,
"holdRequests": [
{
"FulfillLineId": "300100661860756",
"HoldCode": "DOO_SHIP_ALL",
"HoldComments": "Applied hold on fulfillment line from REST",
"RequestedBy": "cflurey"
}
]
}
ユーザーがOracle実装に存在することを確認します。 ユーザーが存在しない場合、REST APIはエラー・メッセージで応答します。 RequestedByに値を含めない場合、REST APIでは、RESTリクエストを送信した個人またはアカウントが使用されます。
Oracleリファレンス: 37556740
有効化のステップ
この機能を有効化するうえで必要な操作はありません。