Results for “so_cycles”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

SO_CYCLES is a reference and configuration table in the Oracle E-Business Suite Order Entry (OE) module, owned by the OE schema. It stores the order cycles used to process sales orders and returns within Oracle Order Management. An order cycle represents a defined sequence of process steps and activities that an order or return must traverse — for example, entry, booking, fulfillment, shipping, and invoicing stages. Each row in SO_CYCLES defines a named cycle that can be assigned to orders, order lines, and interface records, thereby controlling the workflow paths those documents follow.

The table is central to order processing configuration. Because orders, lines, and interface records all carry a CYCLE_ID reference, SO_CYCLES functions as a master (dimension) table within the OE schema. From a Data Vault modeling perspective, the metadata's heuristic classification is hub-leaning: SO_CYCLES exhibits the characteristics of a hub, defined by its stable business key (NAME) and referenced by multiple surrounding link and satellite structures. This classification is a modeling suggestion rather than a physical implementation, as the table remains a conventional relational entity in EBS 12.1.1 and 12.2.2.

Key Information Stored

SO_CYCLES contains 26 documented columns. The most significant are listed below.

• CYCLE_ID — Surrogate primary key, enforced by the constraint/index SO_CYCLES_PK (also documented as unique index SO_CYCLES_U1). It is the value propagated to all foreign-key references across order tables.
• NAME — Business-key candidate, protected by the unique index SO_CYCLES_UK1 / SO_CYCLES_U2. This is the user-facing cycle name displayed in Order Management setup forms and referenced by users when assigning cycles.
• DESCRIPTION — Free-text description clarifying the purpose or scope of the cycle.
• START_DATE_ACTIVE — The date from which the cycle becomes valid and selectable for order processing.
• END_DATE_ACTIVE — The date after which the cycle is no longer active, supporting effective-dated configuration and controlled retirement of cycles.
• CREATION_DATE, CREATED_BY — Standard audit columns recording when and by whom the cycle definition was created.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit columns recording the most recent modification and the responsible user/session.
• CONTEXT and ATTRIBUTE1 through ATTRIBUTE15 — The standard Oracle DFF (Descriptive Flexfield) columns, providing extensible, customer-defined attributes for the cycle definition.

The distinction between the surrogate key (CYCLE_ID) and the business-key candidate (NAME) is important: joins and foreign keys use CYCLE_ID, while user searches and reports typically filter on NAME.

Common Use Cases and Queries

Typical uses include identifying the active cycle assigned to orders, listing all cycles available for a business scenario, and validating that a cycle is within its effective date range before assignment.

Listing active cycles by name:

• SELECT cycle_id, name, description FROM oe.so_cycles WHERE TRUNC(SYSDATE) BETWEEN NVL(start_date_active, SYSDATE) AND NVL(end_date_active, SYSDATE);

Resolving the cycle for a set of orders:

• SELECT h.order_number, c.name cycle_name FROM oe.so_headers_all h, oe.so_cycles c WHERE h.cycle_id = c.cycle_id AND h.org_id = :org_id;

Counting orders per cycle for utilization reporting:

• SELECT c.name, COUNT(*) FROM oe.so_headers_all h JOIN oe.so_cycles c ON h.cycle_id = c.cycle_id GROUP BY c.name;

Common reporting scenarios include cycle utilization analysis, auditing which cycle definition applies to historical orders, and troubleshooting order processing failures caused by an inactive or misconfigured cycle.

Related Objects

SO_CYCLES is referenced through the CYCLE_ID foreign key by several OE objects. The principal related tables are:

• SO_CYCLE_ACTIONS — joins on SO_CYCLE_ACTIONS.CYCLE_ID = SO_CYCLES.CYCLE_ID; defines the individual process steps and activities that make up each cycle.
• SO_HEADERS_ALL — joins on SO_HEADERS_ALL.CYCLE_ID = SO_CYCLES.CYCLE_ID; the order header carries the assigned cycle governing its processing path.
• SO_LINES_ALL — joins on SO_LINES_ALL.CYCLE_ID = SO_CYCLES.CYCLE_ID; order lines may inherit or carry their own cycle reference.
• SO_HEADERS_INTERFACE_ALL — joins on SO_HEADERS_INTERFACE_ALL.CYCLE_ID = SO_CYCLES.CYCLE_ID; interface (staging) records must resolve a valid cycle before import into order tables.

Because SO_CYCLE_ACTIONS, SO_HEADERS_ALL, SO_LINES_ALL, and SO_HEADERS_INTERFACE_ALL all reference SO_CYCLES via CYCLE_ID, integrity of the SO_CYCLES_PK constraint is essential; deleting or inactivating a cycle in use can affect order processing across all of these dependent objects.