1. When changing a header field value on an existing order, why don't my
Defaulting Rules cascade the change down to my existing order lines?
Defaulting Rules and conditions only control the initial defaulting into a
field when the record is created. Once the field has a value, Defaulting
Rules do not apply again. Unless, there are clear dependencies setup to
cause a re-defaulting. The Mass Change capability may be utilized to
cascade header changes down to any pre-existing order lines.
2. Can you set up a defaulting rule to apply only for a specific operating
unit and not globally?
Yes, this is possible. The default condition ALWAYS is a global condition
and rules setup with this condition will apply to all operating units.
However, users can setup defaulting conditions based on the operating unit.
These defaulting conditions can be set up for a combination of operating
units or separate conditions can be defined for multiple operating units.
They can then be used to setup defaulting rules specific to the operating
unit.
3. What is the Default Generator concurrent program used for?
This concurrent program is used to generate defaulting packages. It is used
internally by Order Management. Users do not need to run this program
unless asked to by the developers for debugging purposes. See Note 122094.1
for more detailed information.
4. Why when I try to access the Defaulting Rules form in Order Management
(Nav= Setup-Rules-Defaulting), I get the following error:
FRM-47023: No such parameter named G_QUERY_FIND exists inform OEXDEFWK.
Answer: Please review Note #122758.1 on Metalink for information on how
to avoid this error.
5. What is the purpose of the Defaulting Generator?
Answer: The Default Generator makes sure that any changes you made to
your Defaulting Rules are activated and they take affect the next time you
call them during Order Management (or other applications).
You need to run the Default Generator after each time you make any
changes to your Defaulting Rules in order for those changes to take affect.
How to run:
1. Requests/Single Requests
2. LOV & select "Defaulting Generator"
3. Application = Oracle Order Management
4. Level = (Select the appropriate level)
6. What is an Entity in Order Management?
Answer: An 'Entity' in this context is a group of related attributes
that roughly correspond to a table or a form in Order Management. So
we have 'entities' of Order Header, Order Line, Order Price Adjustment,
Line Price Adjustment, etc. Entities correspond to 'blocks' in the old
SVRS.
7. What is an Attribute in Order Management?
Answer: An 'Attribute' is a field or column that belongs to that
entity. Therefore, the 'ordered unit of measure' is an attribute of the
'Order Line' entity. Attributes correspond to 'fields' in the old
SVRS. When you query up the Defaulting Setup form for a particular
entity, you'll see a list of all the attributes for which you can define
defaulting rules. As in Order Entry, you will not be able to define
defaulting rules for descriptive flexfields, since their defaulting is
controlled by AOL's flexfield routines.
8. What are Conditions in Order Management?
Answer: 'Conditions' are rules you set up that will control when a
particular group of default sources will be looked at. You define one
or more 'condition validation templates' based on whatever common
business rules you may have. You define one or more of these condition
templates per entity, and then you can use them over and over for the
attributes of that entity. For example, you might set up a condition
template for all return lines, or another one for all internal order
lines. The ALWAYS condition is seeded for each entity. If you are
defining a set of Conditions and using them in rules, be sure to place
the ALWAYS condition last in the Precedence for Defaulting Conditions.
9. What are Sources of defaulting information?
Answer: 'Sources' are places where values can be defaulted from.
Defaulting Rules provide a variety of sources that you can use in
building your defaults. Most of them will be familiar to users of
Oracle Order Entry.
10. How do I control changes to defaulting values?
Answer: In Order Entry SVRS, there used to be two checkboxes on each
rule line where you could control changes to an attribute. You could
check whether or not to allow users to override a defaulted value
(Override Allowed) and you could control whether the rules should
re-default over user-specified values (Override User-Specified
Values). These checkboxes often were viewed to be confusing and to
operate inconsistently. Order Management's Defaulting Rules solved that
problem by getting rid of those checkboxes. Instead, you control who
can change data (and when) using the new Processing Constraints
framework, regardless of how or whether an attribute was defaulted. In
addition, you have the ability when you define Processing Constraints to
indicate that you want the system to be able to update an attribute, but
a user cannot make changes.
The only time that Defaulting Rules result in a change to an existing
attribute on an entity is when that attribute has a dependency on
another attribute that has been changed.
11. I am upgrading to release 11i, do my Standard Value Rule Sets get
upgraded to Defaulting Rules?
Answer: Because of the magnitude of the changes to the fundamental
architecture between SVRS and Defaulting Rules, the decision was made to
not upgrade any user-defined SVRS. Defaulting Rules have been seeded
that provide equivalent functionality to the R11 seeded SVRS. There is
a good table in Appendix E of the Oracle Order Management R11i User's
Guide that lists all attributes of the Order Header and Order Lines
entities, and what the seeded defaulting rule is for each of those
attributes.
Users of Order Entry who created their own Standard Value Rules or
customized the seeded rule sets will need to carefully review the logic
behind their changes or customizations, and create equivalent Defaulting
Rules for the attributes affected. Typically a user will need to create
Conditions corresponding to their particular business need, and then
create Defaulting Rules using those Conditions for the necessary
attributes.
12. Is it standard functionality that the warehouse is copied from
the top model to all child lines?
Answer: It is a standard functionality that we copy the warehouse from
the top model to all child lines. For a SMC (Ship Model Complete) model
we mandate that all lines in the model has same warehouse. For a non-SMC
model it can be a valid requirement to have different warehouses for
different lines.
13. When making revisions to the header level of a sales order, these revisions
are not reflected on the line level and do not print on the Sales Order
Acknowlegement, Pick Slip or PackSlip.
If we change any field on the header (Shipping Instructions, Bill to,
etc...)and then we requery the order and open the line level, the
revisions are not reflected here and the revisions do not print out on
the concurrent requests.
It appears that the reports pull data form the line level of the sales
order and that is why the revised data is not printing, so we need to
find out why the revisions are not propogating to the line level of the
sales order.
Answer: This is an excerpt from 'Using Defaulting Rules in Oracle Order
Management':
Defaulting vs. Cascading
In Order Management, a clear and unambiguous distinction has been made
between 'defaulting' and 'cascading', which will cause behavior different from
what we have become used to in R11 Order Entry. In OE, defaulting and cascading
were intermixed, making it sometimes difficult to predict what might happen when
an attribute at one level was changed. In OM, the defaulting logic will come
into play only when the record is initially created (when you click on a new
record on the form) , or when an attribute upon which this attribute is
dependent is changed.
Cascading, on the other hand, means replicating the value of an attribute down
To lower level entities. We do not perform cascading in Order Management. If you
want to change the value of attributes on existing rows, you need to use the new
mass change capability, where you multi-select the rows you want to change, and
then change them.
So what does this mean in real life? Here¿s an example. Assume you have a
defaulting rule set up to default a line-level attribute such as Ship Method
from the header to the line. You create an order with several lines and use Ship
Method A for the header (and therefore the lines). Then you want to change the
ship method to Ship Method B. Changing this attribute at the header will result
in any subsequent new lines getting Ship Method B defaulted onto them. The existing
lines that have Ship Method A will not get changed to B as a result of your
changing the header attribute. You will need to use mass change to do that. The
good news is that the user has explicit and unambiguous control over what lines
get changed.
This is the intended functionality of the defaulting rules.
Please feel free to review this document via Metalink.
Go to Technical Libraries->OM Suite: Order Management ->White Papers.
14. When upgrading from 10.7 to 11i how are the 10.7 Standard Value Rule
Sets migrated or upgraded to the Defaulting Rules which are used by 11i Order
Management?
11i uses Processing Constraints and Defaulting Rules instead of Standard Value
Rule Sets and there are no conversion scripts. Rule sets, processing constraints
and defaulting rules are totally different entities and one does not convert to
the other.
No comments:
Post a Comment