Selected Order Management Bug Fixes in This Update

This update includes some bug fixes that can change the way Oracle Order Management works. This isn't a full list of all the bug fixes in this update. This list includes the bug fixes that can cause a noticeable change in application behavior.

Include Supplier Numbers and Supplier Site Codes When You Import Sales Orders

Before update 25D, you couldn't use the supplier number to identify a supplier or the supplier site code to identify the supplier site when you imported sales orders through the SalesOrdersforOrderHub or the SalesOrdersforOrderHubRequests REST API, or through the SourceSalesOrderImportTemplate.xlsm FBDI template.

Starting with update 25D, you can include the supplier number in the SupplierNumber attribute and the supplier site code in the SupplierSiteName attribute when you import through SalesOrdersforOrderHub or SalesOrdersforOrderHubRequests. You can include the supplier number in the Requested Supplier Number attribute and the supplier site code in the Requested Supplier Site Code attribute when you import through SourceSalesOrderImportTemplate.xlsm.

Oracle reference: 38059874

Import Consistent Request Types in Shipment Sets

The RequestType attribute must contain the same value for each order line in a shipment set.

Before update 25D, if you imported a revision through REST API, and if your import payload had different values in RequestType across lines in the same shipment set, then Order Management would modify some of those values so they're consistent, the import was successful, but it caused scheduling errors during fulfillment.

Starting in update 25D, if you import different values in RequestType across lines in a shipment set, then the import will fail and reply with an error message.

Oracle reference: 38106968

Add Invoice Tasks After Shipment Tasks

Before update 25D, if you added an invoice task in your orchestration process before a fulfillment task, such as the shipment task, then you might have encountered stuck sales orders because:

  • Your import didn't have a required shipment attribute.
  • Order Management couldn't correctly compensate the order line after shipment.

You can't fix these problems because the line is already billed.

Starting in update 25D, Order Management will prevent you from:

  • Adding an invoice task before a Shipment, DOO_Procurement, or Returns fulfilment task. Applies when you create a new orchestration process.
  • Setting up the invoice task before you set up the fulfilment task. Applies when you revise an orchestration process.

Oracle reference: 37587558

Make the Return's Legal Entity Match the Original

Assume you write an order management extension that creates a sales order and sets its legal entity to Vision Manufacturing, but the business unit's default legal entity is Vision Sales. You submit, ship, and close the order. You then create a referenced return, but notice that the return has Vision Sales for the legal entity instead of the one you want, which is Vision Manufacturing. If you want Vision Manufacturing on the return, then use this extension:

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 reference: 33013626

Use REST API to Identify Users Who Apply and Release Holds

You can now use the RequestedBy attribute in your salesOrdersForOrderHub payload to identify the user who applied or released a hold on an order line. This example identifies cflurey as the user who applied the DOO_SHIP_ALL hold:

{
    "processRequestOfflineAfter": 240,
    "holdRequests": [
        {
      "FulfillLineId": "300100661860756",
      "HoldCode": "DOO_SHIP_ALL",
      "HoldComments": "Applied hold on fulfillment line from REST",
      "RequestedBy": "cflurey"
        }
    ]
}

Make sure the user exists in your Oracle implementation. If the user doesn't exist, then REST API will respond with an error message. If you don't include any value in RequestedBy, then REST API will use the person or the account that sent the REST request.

 Oracle reference: 37556740

Steps to Enable

You don't need to do anything to enable this feature.