Use Order Profiles to Control Order Management Behavior
Manage predefined profile values to control behavior in Oracle Order Management.
Most profiles include predefined values so you don't have to set them up unless you need different values to meet your needs.
Manage Your Order Profiles
-
Go to the Setup and Maintenance work area, then go to the task:
-
Offering: Order Management
-
Functional Area: Orders
-
Task: Manage Order Profiles
-
-
On the Manage Order Profiles page, in the Profile Option area, click Search.
-
In the search results, in the Profile Options list, click the profile that you must edit.
-
In the Profile Values list, add or delete values, as necessary.
Hierarchy of the Order Profiles
You can set a profile at different levels to specify a hierarchy.
We recommend that you set site values for your profile option before you set the values for the product or user.
Level
Priority
Example
Site
Lowest
Affects all of Order Management.
For example, set the currency for all of Order Management to Euro.
Product
Higher than Site
Affects only the item.
For example, set the currency for the AS54888 item to Renminbi.
User
Higher than Product
Affects only the current user.
For example, set the currency for the user to US Dollar.
You can use each profile only for a single site, except you can use Currency Conversion Type and Retain Sales Order Number During Import for a single site and for each user.
Order Profiles
Profile Option |
Description |
---|---|
Currency Conversion Type |
Specify the value to use when converting a currency in the Order Management work area. This value is a conversion type. |
Display Currency |
Specify the currency that Order Management will display in the Order Management work area, by default. |
Hours to Wait Before Allowing Date Changes on Fulfillment Lines |
See the section below in this topic. |
Map Sales Credit from Parent to Child | Map the sales credit on the parent configured item to the
sales credit on child configure options that don't already have a credit.
Consider an example.
|
Required Overview Status Filter |
Specify the default customer to use when filtering the summary of status data on the Overview page of the Order Management work area. It allows your users to view summary data for only one customer at a time. It removes the All option. Order Management provides no value, by default. To improve performance, you can enter a customer identification number. |
Retain Sales Order Number During Import |
For details, see Keep Your Order Number When You Import. |
Total Number of Order Lines in Each Hour | Specify the average number of order lines that you typically process in one hour. |
Truncate Attribute Values for Accounts Receivable | See the section below in this topic. |
User Request Waiting Period in Seconds |
Specify the number of seconds to wait after an action finishes. This time allows each asynchronous web service to finish before displaying a confirmation message or a warning message in the Order Management work area. The default value is 5. |
Validate Charge and Charge Components for Sales Orders | See the section below in this topic. |
Manage Your Administrator Profiles
You can modify order profiles to manage your implementation. You might also need to modify administrator profiles.
- Go to the Setup and Maintenance work area, then click Tasks > Search.
- On the Search page, search for, then open Manage Administrator Profile Values.
- On the Manage Administrator Profile Values page, search for the value.
Attribute Value Profile Option Code ORA_FOM
FOM means Fusion Order Management, which is an earlier name for Oracle Order Management.
- Examine the search results. They contain various profiles that you can use to
control Order Management's behavior. Read the profile's description to get an
overview. For more detail, see the help topic:
Profile Option Code Help Topic ORA_FOM_COPY_EFF_ON_CPLN Overview of Using Extensible Flexfields in Order Management ORA_FOM_GET_CUSTOMER_ITEM Manage Customer Items in Order Management ORA_FOM_SHOW_MARGIN How Pricing Prices Sales Orders ORA_FOM_ENABLE_CARD_PAYMENT Enable the Credit Card Feature in Order Management ORA_FOM_DEFAULT_ADJ_REASON - On the Manage Administrator Profile Values page, search for the value.
Attribute Value Profile Option Code ORA_DOO
DOO means Distributed Order Orchestration, which is also an earlier name for Oracle Order Management.
Distributed Order Orchestration these days apply mainly to the orchestration that Order Management does after you submit a sales order to order fulfillment.
- Examine the search results. They contain various profiles that you can use to control Order Management's behavior. Read the profile's description to get an overview. For more detail, see the Administrator Profiles subtopic.
Administrator Profiles
Profile Option |
Description |
---|---|
ORA_DOO_DS_FDTL_AR_MAPPING Send Fulfillment Details for Drop Shipments to Accounts Receivable |
This option comes predefined with the Site level disabled. If you enable it, then Order Management will send fulfillment details for drop shipments to Accounts Receivable. It will send the waybill number, bill of lading, and so on. |
ORA_FOM_RESPOND_ON_SUBMISSION_START Respond Immediately on Start of Submission Request |
Specify when the Sales Order for Order Hub REST API sends a response to each request that it receives.
For details and examples, go to REST API for Oracle Supply Chain Management Cloud, expand Order Management, then click Sales Orders for Order Hub. |
ORA_DOO_FULFILLMENT_TASK_RETRIES | See the Fulfillment Task Retries subtopic. |
ORA_DOO_ENABLE_AGGR_V2 Aggregate According to Number of Order Lines That Changed |
This option aggregates order lines according to the number of order lines that changed. The default value is Yes. For details, see the Aggregate Fulfillment Lines subtopic in For details, see the Aggregate Fulfillment Lines subtopic in Set Up Features, Manage Change, and More for Drop Ship. Set it to No to aggregate lines according to time or to the number of lines in a routing rule. For details, see Aggregate Requests That Order Management Sends to Your Fulfillment System. This option only applies on order lines in a drop shipment. It applies to changes that happen on the source order. |
ORA_DOO_AGGR_HOLD_TIMEOUT Aggregator Hold Timeout Period in Minutes |
The aggregator applies a hold on the purchase order in Procurement to prevent other processes from updating the order while aggregating. Specify the number of minutes for the hold operation to wait before timing out while aggregating order lines.
Use the aggregator profiles together. If you don't enable Aggregate According to Number of Order Lines That Changed, then Order Management ignores Aggregator Hold Timeout Period in Minutes. |
ORA_FOM_DEFAULT_BUSINESS_UNIT |
Specify the value that you want Order Management to set for the Business Unit attribute on the order header, by default:
|
ORA_FOM_ORCH_PROCESS_BATCH_SIZE Number of Orchestration Processes to Start Concurrently for Large Sales Orders |
Specify the number of orchestration process instances to start concurrently for your sales order. You can use this profile to improve performance for your large sales orders. Assume you use the predefined ShipOrderGenericProcess orchestration process, your sales order has 5,000 lines, and you set this profile to:
The default value is 100. We recommend that you start with the default value, modify it and monitor performance in a test environment until you achieve the desired performance, then set the value in your production environment. |
ORA_FOM_POPULATE_VALUES_ON_SPLIT_LINE Populate Split Lines with Values from Original Line |
If you enable this option, and if the user splits a line in the Split Fulfillment Line dialog, then Order Management will populate values on the split line with values from original line. Note
|
ORA_DOO_RECOMPUTE_PROMISE_DATE | See the Use Global Order Promising to Recalculate Dates in Order Management subtopic. |
ORA_DOO_SKIP_AVAILABILITY Skip Availability When Searching for Item |
Improve performance when the user searches for an item on the catalog line. If you set this option to Yes, then Order Management doesn't send a request to Global Order Promising to determine whether the item is available. If you don't use Global Order Promising, then set this option to Yes. |
Skip PricingTotals and Pricing Validation |
Improve performance. Don't validate the price and don't calculate the total price of the sales order when the user clicks Add on the catalog line. Order Management will calculate the sales order total only when the user saves the order as a draft or clicks Submit. |
Fulfillment Task Retries
Set the number of times that Order Management should rerun a fulfillment task before it sends a reply to your fulfillment system when lines are locked or there's a problem with a wait task.
You must enter a value in the Profile Value attribute. Use this format:
task_type
#times_to_retry,task_type#times_to_retry,task_type#times_to_retry,task_type#times_to_retry
where
- task_type identifies the type of fulfillment task.
- times_to_retry specifies the number of times to retry the task.
- You can specify task types in any sequence. For example, you can specify All first, and then Shipment, Procurement, and finally Generic.
Specify the Task Type
Use these values for task_type.
Value | Description |
---|---|
Shipment | Retry all fulfillment tasks that involve the Shipment task type. |
DOO_Procurement | Retry all fulfillment tasks that involve the Procurement task type. |
DOO_$GENERIC$ | This is a profile value. It will retry all the fulfillment tasks that you create. For details about fulfillment tasks that you create, see Create Your Own Task Type. |
DOO_$ALL$ | This is a profile value. It will retry all predefined fulfillment tasks and all custom tasks that you create. |
Note the format requirements. You must:
- Include the DOO_ prefix for GENERIC and ALL.
- Use all upper case letters for DOO_GENERIC and DOO_ALL.
- Enclose DOO_GENERIC and DOO_ALL with dollar signs ( $ $ ). For example, DOO_$ALL$ and DOO_$GENERIC$. The dollar signs are wildcards.
- Use the comma to separate each value.
Don't include the space character anywhere in your code.
Specify Predefined Task Types
You must match the name of each predefined task type exactly, including capitalization. Some predefined task types include the DOO_ prefix, but others don't. Here's how you can determine the format that you need:
- Go to the Setup and Maintenance work area, then go to the task:
- Offering: Order Management
- Functional Area: Orders
- Task: Manage Task Types
- On the Manage Task Types page, notice the value in the Task Type column. You must
use this value. For example:
- Schedule doesn't have a DOO prefix, so don't include that prefix with the Schedule task type.
- DOO_Procurement has a DOO prefix, so you must include that prefix with the DOO_Procurement task type.
Specify the Times to Retry
Use these guidelines for times_to_retry.
- Specify a minimum value of 0 and a maximum value of 9.
- If you specify a value that's greater than 9, then Order Management will still use 9. For example, set the retry to 10, and Order Management will attempt to rerun the fulfillment task 9 times before it replies with an error.
- If Order Management can't process the fulfillment task after the number of times that you specify, then it will send an error to your fulfillment system.
- The value that you specify depends on your server's performance. If you find that specifying a higher value degrades performance, then use a lower value.
Example
Consider an example.
Shipment#5,DOO_Procurement#4,DOO_$GENERIC$#7,DOO_$ALL$#3
In this example, Order Management will retry:
- Shipment tasks 5 times
- Procurement tasks 4 times
- Generic tasks 7 times
- All tasks except Shipment, Procurement, and Generic tasks 3 times
Consider Priority
DOO_ALL has the lowest priority. If you provide a value for Shipment, DOO_Procurement, or DOO_GENERIC, and you also provide a value for DOO_ALL, then Order Management uses the value that you provide in Shipment, DOO_Procurement, or DOO_GENERIC, and then DOO_ALL.
Assume you provide:
DOO_$ALL$#4,DOO_$GENERIC$#6,Shipment#5
Order Management will retry all the fulfillment tasks that you create 6 times, all the shipment tasks 5 times, and all other tasks 4 times.
Notes
- The profile option code is ORA_DOO_FULFILLMENT_TASK_RETRIES.
- You might not receive a reply for some fulfillment tasks. For example, Order Management will attempt to retry a fulfillment task in a drop ship flow but it won't send a reply.
- A response can be immediate or delayed. Having a delayed response doesn't necessarily mean there's a problem. For example, Order Management might be waiting for a shipping task to finish, so it can't send a response until that task is done. Or it might be processing a number of other lines and can't process the fulfillment task until its done with those other lines. For details about the delayed response, see Overview of Connecting Order Management to Your Fulfillment Systemand Connect Order Management to Your Fulfillment System.
Hours to Wait Before Allowing Date Changes on Fulfillment Lines
Specify the number of hours to wait before allowing the Order Entry Specialist to update attributes on the fulfillment line for a drop shipment.
Order Management allows the user to modify attributes when one of these conditions is true.
-
Oracle Procurement hasn't created the purchase requisition.
-
The time that you specify in this profile has elapsed.
-
The Scheduled Ship Date or the Scheduled Arrival Date has happened.
The default value is 4 hours.
If you add an order line that includes a drop shipment and submit the sales order, then Order Management sends the fulfillment line to Oracle Procurement, and Procurement starts the flow that creates a purchase requisition for the item but it doesn't send updates to Order Management until it finishes the flow. To keep the fulfillment line consistent with the purchase requisition, Order Management doesn't allow you to modify the fulfillment line until it receives the requisition from Procurement. Procurement usually creates the requisition in a few minutes or less, but in some situations the response might be delayed or Order Management might not receive any response.
At some point, you might need to edit attribute values on the fulfillment line to reprocess the requisition. Use this profile option to specify how long to wait. For example, if you learn through experience that some responses from Procurement take as long as 1 hour to finish, but never more than 2 hours, then set this profile to 3. That way, the Order Entry Specialist can't modify attributes while the response is delayed.
Percent of Order Lines in Error in Each Hour
Use the Total Number of Order Lines in Each Hour profile and the Percent of Error Lines to Process Each Hour profile together to help avoid performance problems that might happen when you run the Recover Errors scheduled process.
Assume you set these values.
Profile Option | Value |
---|---|
Total Number of Order Lines in Each Hour | 25000 |
Percent of Order Lines in Error in Each Hour | 10 |
2,500 is 10% of 25,000, so the Recover Errors scheduled process will attempt to recover about 2,500 order lines that are in error each hour. If the actual number of lines that are in error is significantly more than 2,500, say about 5,000, then the Recover Errors scheduled process will attempt to recover the lines in about 2 hours.
Set Percent of Order Lines in Error in Each Hour conservatively, such as 10%. Set it to a value that works for a typical business day where you don’t expect a lot of lines will go into error.
Increase Percent of Order Lines in Error in Each Hour only when you must recover lines that are in error at a much faster rate than usual. For example, something happens that causes errors to accumulate, such as your server goes down. If you increase it:
-
Increase it gradually, observe performance, then use a value that meets your business requirements.
Consider the time of day when you run the Recover Errors process. Try to run it when you don't have other activities running that consume a lot of resources on your server.
-
Monitor performance. Adjust the values of these profiles as necessary according to the performance that you observe.
The values in this topic are example values. They aren't recommendations. You must use your own values to meet your business requirements.
For details, see Fix Errors in All Sales Orders.
Truncate Attribute Values for Accounts Receivable
Use the Truncate Attribute Values for Accounts Receivable profile to truncate some of the attribute values that Order Management sends to Accounts Receivable. You can set the profile to:
- Yes. Truncate the attribute values to the recommended length.
- No. Don't truncate any values.
Order Management sends these order line attributes to Accounts Receivable for billing.
Attribute | Maximum Recommended Length |
---|---|
Bill Of Lading Delivery Name |
The value for each attribute must not exceed 30 characters. |
Charge Component Explanation | The attribute's value must not exceed 240 characters. |
If the value that Order Management sends for any of these attributes doesn't match the length that Accounts Receivable uses, then billing fails in Accounts Receivable. To avoid this problem, you must truncate the length so it doesn't exceed the recommended length.
- If you set the PreCreditCheckedFlag attribute to Y when you import or revise a sales order, and if the value in the Credit Check Authorization Number attribute in your import or revision exceeds 30 characters, then Order Management doesn't truncate the value in Credit Check Authorization Number but instead will reject the sales order.
- Order Management applies this behavior only when you integrate with Oracle Accounts Receivable. It doesn't apply when you integrate with some other accounts receivable application.
- Order Management validates the Credit Check Authorization Number attribute when you import the sales order regardless of how you set the profile.
The profile code is FOM_TRUNCATE_AR_ATTRIBUTE_VALUES.
Example
Consider an example where, if you enable the profile, then Order Management truncates the value so it doesn't exceed 30 characters.
Attribute | Profile Not Enabled | Profile Enabled |
---|---|---|
Bill Of Lading |
This value has 57 characters:
|
This value has 30 characters:
|
Delivery Name |
This value has 57 characters:
|
This value has 30 characters:
|
If you enable the profile, then Order Management truncates the value so it doesn't exceed 240.
Attribute | Profile Not Enabled | Profile Enabled |
---|---|---|
Charge Component Explanation |
This value has 262 characters:
|
This value has 240 characters:
|
Use Global Order Promising to Recalculate Dates in Order Management
If you enable this option:
-
And if you change the promised ship date or promised arrival date in Oracle Procurement
-
Or if you change the work order date in Oracle Manufacturing
-
Or if you change the requested date in Oracle Inventory
Then Order Management will use Global Order Promising to calculate the scheduled ship date or scheduled arrival date for sales orders in Order Management.
Specify the profile value to determine when to apply this behavior.
Value | Description |
---|---|
Back-to-Back | Apply this behavior only in back-to-back flows. |
Drop Shipment | Apply this behavior only with sales orders that include a drop shipment. |
Back-to-Back and Drop Shipment | Apply this behavior in back-to-back flows and with sales orders that include a drop shipment. |
Neither Back-to-Back nor Drop Shipment | Don't apply this behavior on any sales orders. This is the default value. |
Note
-
Order Management doesn't send the revised scheduled ship date or scheduled arrival date to Oracle Procurement, so the dates on the sales order in Order Management won't match the dates on the purchase order in Procurement.
-
You can use this feature only with orchestration processes that use Global Order Promising.
-
You can use this option only for a single site.
-
If the buyer manages transportation, then Order Management maps the Requested Delivery Date on the purchase order to the Scheduled Arrival Date on the sales order. Order Management and Global Order Promising ignore the value in Requested Delivery Date when recalculating the Scheduled Arrival Date.
Example When Buyer Manages Transportation
Note
Buyer Manages Transportation |
Buyer Doesn't Manage Transportation |
---|---|
Assume you set the transit lead time to 5 days in Global Order Promising. |
Assume you set the transit lead time to 3 days in Global Order Promising. |
The buyer can revise the Promised Ship Date in Procurement. |
The buyer can revise the Promised Delivery Date, but can't revise the Promised Ship Date in Procurement. |
Global Order Promising updates the Scheduled Arrival Date. |
Global Order Promising updates the Scheduled Ship Date. |
Validate Charge and Charge Components for Sales Orders
Use this profile option to validate each of the attributes that involve charges and charge components. You specify these attributes in the response that you send to Order Management from the Fulfillment Response Service or the Order Fulfillment Response Service. For details about them, see Web Services That You Can Use to Integrate Order Management.
We recommend that you leave this profile at its default Yes value. If you disable it, then Order Management won't validate values for the charge and charge components that you import.
If you enable the profile, then you must make sure your import payload meets the validation requirements.
Validation for Each Order Charge Entity
Attribute | Must Include in Payload | Must Already Exist in Oracle Pricing |
---|---|---|
ApplyTo | Y | Y |
ChargeDefinitionCode | Y | Y |
ChargeSubTypeCode | Y | Y |
ChargeTypeCode | Y | Y |
PricePeriodicityCode | Y | Y |
PriceTypeCode | Y | Y |
SourceChargeIdentifier | Y | N |
Note
- Must Include in Payload means you must include the attribute in your import payload.
- Must Already Exist in Oracle Pricing means the value that you specify for the attribute in your import payload must already exist in Oracle Pricing's data.
- Make sure the lookup code that you specify in the ChargeSubTypeCode attribute is enabled in the ORA_QP_CHARGE_SUBTYPES pricing lookup.
- Make sure the lookup code that you specify in the ChargeTypeCode attribute is enabled in the ORA_QP_CHARGE_TYPE pricing lookup.
- Include pricePeriodicityCode only if you have a recurring charge.
You must make sure a charge definition exists in Oracle Pricing for the combination of values that you provide in your import payload for these attributes:
- ChargeDefinitionCode
- ChargeTypeCode
- ChargeSubtypeCode
- PriceTypeCode
Validation for Each Charge Component Entity
Attribute | Must Include in Payload | Must Already Exist in 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 |
Note
- Make sure the charge doesn't include more than one list price or more than one net price.
- The Order Fulfillment Response Service uses ChargeInterfaceKey instead of SourceChargeComponentIdentifier.
- Include HeaderCurrencyDurationExtendedAmount only if you have a recurring charge.
- Use PriceElementUsageCode only for list price or net price.
Validation for Each Charge Tier Entity
Attribute | Must Include in Payload | Must Already Exist in 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 |
Note
- If you include a value in ApplicationMethod, then you must also include a value in BlockSize.
- Make sure the value in TierTo is equal to or greater than the value in TierFrom.