Results for “je_doc_sequence_audit_u1”

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

Overview

JE_DOC_SEQUENCE_AUDIT is a table owned by the GL schema within Oracle E-Business Suite, categorized under the JE – European Localizations product family. Its documented purpose is to provide audit information for the Greek Accounting Sequence. This places the object firmly within the localization layer that supports statutory document sequencing requirements for Greek accounting legislation, rather than within the core General Ledger posting engine itself.

The table exists to record and preserve evidence of sequence values that have been consumed by or assigned to accounting documents subject to Greek legal numbering rules. Because Greek tax and accounting regulations require an unbroken, auditable sequence of document numbers that cannot be altered retroactively, this audit table serves as the evidentiary backbone that allows the localizations to demonstrate compliance during statutory review or inspection.

From a Data Vault modeling perspective, the mined heuristic classification for this table is standalone. This suggests that, in a dimensional or Data Vault re-modeling exercise, JE_DOC_SEQUENCE_AUDIT would most reasonably be treated as an independent structure rather than as a pure hub, link, or satellite tied to a broader core model. Analysts designing downstream data marts from EBS should therefore consider retaining it as a discrete audit entity whose grain is defined by its own composite key, and should not assume it belongs to a shared conformed hierarchy within the EBS schema.

Key Information Stored

The documented physical schema for this table in ETRM 12.2.2 contains five columns. The primary key, JE_DOC_SEQUENCE_AUDIT_PK, is a composite key defined over DOC_SEQUENCE_ID and DOC_SEQUENCE_VALUE. A unique index, JE_DOC_SEQUENCE_AUDIT_U1, is defined over the same two columns (DOC_SEQUENCE_ID, DOC_SEQUENCE_VALUE), and the metadata also presents this pair as the business-key candidate. This is a notable point: the surrogate and business key coincide here, which is common in audit tables where the natural identifier of an audited event is itself unique and immutable.

• DOC_SEQUENCE_ID — The identifier of the document sequence to which the audited value belongs. This is one leg of the composite primary key and the primary selector when querying audits for a specific sequence.
• DOC_SEQUENCE_VALUE — The actual sequence value that was consumed or assigned. This is the second leg of the composite primary key and represents the numeric or string value that must remain traceable for statutory purposes.
• DOC_SEQUENCE_ASSIGNMENT_ID — A foreign key referencing FND_DOC_SEQUENCE_ASSIGNMENTS. This links the audited value back to the sequence assignment configuration, identifying which assignment (and therefore which context of use) produced the value.
• CREATION_DATE — The date and time the audit record was created, providing a temporal reference for when the sequence value was captured.
• CREATED_BY — The user identifier responsible for creating the audit row, supporting accountability and segregation-of-duties analysis.

The remaining structural facts are the identity of the owner (GL), the total column count (5), and the foreign-key relationship to FND_DOC_SEQUENCE_ASSIGNMENTS. Note that the metadata lists the foreign key under the heading this table references, meaning JE_DOC_SEQUENCE_AUDIT is the child side of the relationship to the assignments table.

Common Use Cases and Queries

The most frequent practical use of this table is statutory compliance reporting: reconstructing the complete sequence of document numbers issued for Greek accounting documents, verifying that no value was skipped, duplicated, or reused, and producing the audit trail demanded by Greek tax authorities. A second common use is reconciliation after a document-sequencing incident, where support teams must determine which values were consumed before or after a failure.

A typical query retrieves all audited values for a given sequence identifier, ordered by value or by creation date:

• SELECT doc_sequence_id, doc_sequence_value, doc_sequence_assignment_id, creation_date, created_by FROM gl.je_doc_sequence_audit WHERE doc_sequence_id = :sequence_id ORDER BY doc_sequence_value;

Because the foreign key points to FND_DOC_SEQUENCE_ASSIGNMENTS, a reporting query can join to the assignments table to enrich each audited value with its assignment context:

• SELECT a.doc_sequence_id, a.doc_sequence_value, a.doc_sequence_assignment_id, f.assignment_id FROM gl.je_doc_sequence_audit a JOIN fnd_doc_sequence_assignments f ON f.assignment_id = a.doc_sequence_assignment_id;

Gap detection is another standard reporting scenario: comparing the distinct set of DOC_SEQUENCE_VALUE entries for a sequence against the expected contiguous range to surface missing values. Auditors also filter on CREATED_BY and CREATION_DATE to isolate activity within a review period or trace responsibility for a specific set of issued numbers.

Related Objects

The following objects are the most significant in relation to JE_DOC_SEQUENCE_AUDIT, based on the documented foreign-key relationship and the surrounding document-sequencing framework in EBS:

• FND_DOC_SEQUENCE_ASSIGNMENTS — Referenced by JE_DOC_SEQUENCE_AUDIT.DOC_SEQUENCE_ASSIGNMENT_ID. This is the direct, documented parent of the audit row and the join used to resolve assignment context.
• FND_DOC_SEQUENCE_CATEGORIES — Defines the categories to which sequences and assignments belong; reached indirectly through the assignments table.
• FND_DOC_SEQUENCES — Holds the sequence definitions keyed by the DOC_SEQUENCE_ID referenced in this audit table.
• FND_DOC_SEQUENCE_AUDIT — The generic document sequence audit table in the application framework; JE_DOC_SEQUENCE_AUDIT is the Greek-localization counterpart and should be considered alongside it when building consolidated audit reports.
• GL_JE_HEADERS and GL_JE_LINES — The journal entry structures whose Greek document numbering is ultimately being audited.

Because the metadata classifies this object as standalone, no additional outbound foreign keys beyond the one to FND_DOC_SEQUENCE_ASSIGNMENTS are documented; joins to the General Ledger journal tables should therefore be driven through the sequence assignment and sequence definition chain rather than assumed direct references.