Results for “marvin_seq”

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

Overview

IGS_UC_CYC_DEFAULTS is a configuration table within the Oracle E-Business Suite IGS (Student System) product family. It belongs to the UCAS (Universities and Colleges Admissions Service) integration sub-area, which supported the exchange of applicant and admissions data between Oracle Student System and the UK UCAS clearing house. The table holds cycle-level default values — that is, parameter defaults scoped to a specific UCAS admissions cycle and a specific external system code.

The ETRM metadata explicitly marks this object as "Not implemented in this database" and classifies the IGS product as obsolete. Consequently, the table should be regarded as a legacy artifact. It will be present in historical 12.1.1 and 12.2.2 environments only where the UCAS interface was originally deployed, and it is not created by the standard EBS installation. Any remediation or migration work should therefore treat it as read-only historical reference data.

From a Data Vault modeling perspective, the mined classification is satellite-leaning. The table does not introduce new business entities of its own; instead it hangs off IGS_UC_DEFAULTS and stores descriptive, cycle-specific attributes. A satellite attached to the IGS_UC_DEFAULTS hub (or link) is the natural analogue.

Key Information Stored

The primary key IGS_UC_CYC_DEFAULTS_PK is a composite business key comprising SYSTEM_CODE and UCAS_CYCLE. There is no separate meaningless surrogate key column documented; the unique index on these two columns serves as both the primary key and the business-key candidate.

• SYSTEM_CODE — Identifies the external source system for which the defaults apply. This is also the foreign key to IGS_UC_DEFAULTS.
• UCAS_CYCLE — The admissions cycle (year/entry point) to which the defaults are scoped.
• UCAS_INTERFACE — Controls the interface mode or variant used for the UCAS exchange in that cycle.
• MARVIN_SEQ — Sequence identifier associated with the MARVIN (UCAS data transfer) process.
• CLEARING_FLAG — Indicates whether clearing-cycle processing is enabled for the cycle.
• EXTRA_FLAG — Governs optional or extended processing behaviour for the cycle.
• CVNAME_FLAG — Controls the handling of CV (confirmation/verification) name data.
• CREATED_BY, CREATION_DATE — Standard EBS audit columns capturing record creation.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard audit columns capturing the last modification and the login session responsible.

The twelve documented columns thus split into seven functional/configuration attributes and five standard who-columns.

Common Use Cases and Queries

The principal use case is resolving the effective defaults for a given cycle before running the UCAS import or export concurrent programs. A typical lookup retrieves all defaults for a system and cycle:

• SELECT * FROM igs_uc_cyc_defaults WHERE system_code = :p_system AND ucas_cycle = :p_cycle;
• Joining to the parent to list every cycle configured for a system: SELECT d.*, c.ucas_cycle FROM igs_uc_defaults d, igs_uc_cyc_defaults c WHERE d.system_code = c.system_code;
• Auditing configuration changes over time using LAST_UPDATED_BY and LAST_UPDATE_DATE to identify who altered clearing or interface flags.

Reporting scenarios include producing a matrix of cycles against interface mode and clearing flag, and reconciling which cycles were live during a given admissions year.

Related Objects

• IGS_UC_DEFAULTS — Parent table; joined on SYSTEM_CODE. Supplies the system-level defaults that the cycle rows refine.
• IGS_UC_CYC_DEFAULTS_PK — The composite unique index on (SYSTEM_CODE, UCAS_CYCLE); enforces one row per system per cycle.
• IGS_UC_* interface and staging tables — UCAS applicant and application staging objects that consume these defaults during import.
• UCAS concurrent programs — The request set that reads these defaults at runtime to drive interface behaviour.

Because the object is obsolete and not implemented, integrators should confirm its existence in the target database before writing dependencies against it.