Search Results amv_temp_numbers

Overview

AMV_TEMP_NUMBERS is a table owned by the APPS schema within the AMV (Marketing Encyclopedia System) product module of Oracle E-Business Suite, valid in both 12.1.1 and 12.2.2. Its documented physical structure is minimal, comprising only two columns: NUMBER_VALUE and SECURITY_GROUP_ID. As its name implies, the object functions as a temporary or staging store for numeric values, typically used by concurrent processes or internal AMV routines that need to persist a transient set of numbers before they are consumed by downstream logic, reports, or bulk operations.

The table carries neither a documented surrogate primary key nor a business-key unique index in the ETRM metadata, and the heuristic Data Vault classification mined from the foreign-key structure is standalone. In Data Vault modeling terms this is best treated as a standalone staging or work-table artifact rather than a true hub, link, or satellite; it should not be integrated into a Core Data Vault as a durable entity.

Key Information Stored

The documented schema exposes exactly two columns, and both are significant:

• NUMBER_VALUE — the numeric payload of the table. This holds the individual integer or decimal values being staged for temporary processing. Depending on the calling AMV routine, this column may contain identifiers, sequence values, or calculation inputs that are later filtered, joined, or aggregated.
• SECURITY_GROUP_ID — the security grouping associated with each staged numeric value. This is the only documented foreign key in the table, resolving to FND_SECURITY_GROUPS, and it supports multi-tenant or organization-level data isolation consistent with the EBS security model.

No surrogate primary key or unique business key is documented for AMV_TEMP_NUMBERS. Because the object is a transient store, uniqueness is expected to be enforced only by application logic, not by a database constraint.

Common Use Cases and Queries

Practical interaction with AMV_TEMP_NUMBERS is almost always programmatic and short-lived. Typical scenarios include bulk inserts by an AMV concurrent program prior to a join against a larger query, and cleanup by scope of security group. A representative query to inspect staged values per security group is:

• SELECT NUMBER_VALUE, SECURITY_GROUP_ID FROM AMV_TEMP_NUMBERS WHERE SECURITY_GROUP_ID = :p_security_group_id;
• SELECT COUNT(*), SECURITY_GROUP_ID FROM AMV_TEMP_NUMBERS GROUP BY SECURITY_GROUP_ID; — validation that a batch populated the expected number of rows.
• SELECT n.NUMBER_VALUE, g.SECURITY_GROUP_NAME FROM AMV_TEMP_NUMBERS n, FND_SECURITY_GROUPS g WHERE n.SECURITY_GROUP_ID = g.SECURITY_GROUP_ID; — resolving staged values to their security group for diagnostic reporting.

Because the table is temporary in nature, reporting use cases are limited to debugging AMV processes, verifying batch populations, and confirming that a staging step completed before the calling program truncates or deletes the content. Persistent reporting should not be built on this object; downstream AMV or FND tables should be the source for analytical queries.

Related Objects

The documented relationship surface for AMV_TEMP_NUMBERS is narrow. The single foreign key identifies the following related object:

• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID = AMV_TEMP_NUMBERS.SECURITY_GROUP_ID; provides the security group definition and is the parent of the only documented FK.

Beyond this FK, AMV_TEMP_NUMBERS is referenced by whatever AMV concurrent programs or API routines populate and consume the staged values. Integration developers and DBA analysts should treat the object as an internal implementation detail of the Marketing Encyclopedia System rather than a shared integration point, and should never assume referential or uniqueness constraints beyond SECURITY_GROUP_ID.