Search Results multi_org_rule_code

Overview

CS.CS_MULTI_ORG_RULES is a configuration table in the Oracle E-Business Suite Service (CS) module. It defines the Multi-Org rules used by Service to determine which operating unit (organization) context applies to a given transaction, and it also stores the sequence in which those rules are evaluated. In practice, the table acts as a rules registry and ordering mechanism: each row represents a named Multi-Org rule together with the priority order that Service applies when resolving organizational context. The object is owned by the CS schema and is marked VALID in the ETRM 12.2.2 reference data.

From a data-modeling perspective, the mined relationship data classifies this object as standalone, with a heuristic Data Vault suggestion of a small reference/hub-style entity keyed on the rule code. This classification is a modeling suggestion only; the table does not exhibit the dense foreign-key fan-out typical of transactional link tables. Its only documented outgoing foreign key is SECURITY_GROUP_ID to FND_SECURITY_GROUPS, which ties the table into the EBS security-group framework rather than into a business transaction chain.

Key Information Stored

The table contains nine documented columns. The most significant are:

• MULTI_ORG_RULE_CODE — the business identifier of the rule. It is the leading column of the primary key CS_MULTI_ORG_RULES_PK and of the unique index CS_MULTI_ORG_RULES_U1, and it is the column most commonly used in application lookups.
• MULTI_ORG_RULE_ORDER — the numeric sequence in which the rule is evaluated relative to other rules. This is the attribute that gives the table its stated purpose: defining the order in which Multi-Org rules are applied.
• SECURITY_GROUP_ID — the security group associated with the rule; it carries the documented foreign key to FND_SECURITY_GROUPS and supports security-group-based filtering of rule visibility.
• ZD_EDITION_NAME — the editioning column. It participates in the unique index CS_MULTI_ORG_RULES_U1 along with MULTI_ORG_RULE_CODE, making the business-key candidate the composite (MULTI_ORG_RULE_CODE, ZD_EDITION_NAME).

The remaining documented columns are the standard EBS audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — which record who created and last modified each rule row and when. There is no separate numeric surrogate key documented beyond the rule code itself; MULTI_ORG_RULE_CODE functions as the primary key column, with ZD_EDITION_NAME completing the uniqueness constraint.

Common Use Cases and Queries

Typical usage centers on inspecting which rules exist and the order in which Service will evaluate them. A straightforward listing query returns the rule codes in evaluation sequence:

• SELECT multi_org_rule_code, multi_org_rule_order, security_group_id FROM cs.cs_multi_org_rules ORDER BY multi_org_rule_order;
• Retrieve a single rule and its sequence: SELECT multi_org_rule_code, multi_org_rule_order FROM cs.cs_multi_org_rules WHERE multi_org_rule_code = :rule_code;

Reporting and diagnostic scenarios include auditing the configured rule ordering, confirming which security group a rule is bound to, and validating that no two rules share the same order value. Join-based validation against the security framework uses the documented relationship, for example linking CS_MULTI_ORG_RULES.SECURITY_GROUP_ID to FND_SECURITY_GROUPS to resolve the group name associated with each rule. Comparisons of the audit columns (CREATION_DATE, LAST_UPDATE_DATE, LAST_UPDATED_BY) are useful when tracking when rule configuration was last changed.

Related Objects

The following objects are the most significant in relation to this table, based on the documented relationship data and the Multi-Org rule configuration context:

• FND_SECURITY_GROUPS — referenced through CS_MULTI_ORG_RULES.SECURITY_GROUP_ID = FND_SECURITY_GROUPS.SECURITY_GROUP_ID. This is the sole documented foreign key and the primary integration point with the EBS security model.
• CS_MULTI_ORG_RULES_PK — the primary key constraint, defined on MULTI_ORG_RULE_CODE.
• CS_MULTI_ORG_RULES_U1 — the unique index on (MULTI_ORG_RULE_CODE, ZD_EDITION_NAME), which enforces the business-key uniqueness of a rule within an edition.
• CS_INCIDENTS_ALL — Service request/incident data that relies on Multi-Org context resolution to determine the operating unit under which a service request is created and queried.
• CS_SR_* / Service request configuration objects — the broader CS setup entities whose org resolution behavior depends on the active Multi-Org rule set.
• FND_ORG_ASSIGNMENTS / HR_OPERATING_UNITS — the operating unit definitions that rule resolution ultimately maps a Service transaction to.

Because the table is standalone with only one documented foreign key, dependency analysis should treat it as a low-fan-in reference table rather than part of a transaction link. Its influence is felt indirectly, through the runtime organizational-context decisions that the ordered rule set drives across the Service module.