Search Results print_status




Overview
Explore in AI Chat

Overview

EDR_COLLATE_PRINT_TEMP is a table owned by the EDR schema within the Oracle E-Business Suite E-Records (EDR) product family. Its documented purpose is to store the final collated PDF that is destined for printing, making it a transient staging object rather than a long-lived transactional master. In practice, this table serves as the landing area where individually generated documents are merged into a single collated PDF and then handed to the printing subsystem, keyed by the concurrent request that produced the collation job.

The table is classified heuristically as standalone under the Data Vault modeling convention. This is a suggested classification only: because no foreign-key relationships were mined from the schema, the object does not behave as a link table connecting two hubs, nor is it a pure satellite attached to a parent hub. Architects modeling EDR in a Data Vault pattern may therefore treat it as a self-contained table whose natural driver is the concurrent request identifier rather than an inbound referential dependency.

Key Information Stored

The table is documented with nine columns in ETRM 12.2.2. The most significant are:

  • REQUEST_ID — the surrogate primary key, enforced by EDR_COLLATE_PRINT_TEMP_PK. It identifies the concurrent request that owns the collation and print operation and is the single business-key candidate documented for this table.
  • PRINTER_NAME and PRINT_STYLE — the target printer and the print style applied when the collated output is submitted.
  • PRINT_STATUS — the current state of the print job, used to track progression through the collation and printing lifecycle.
  • NEW_PAGE_NUMBER — the page-numbering control applied to the collated output.
  • DRAFT_COLLATED_PDF and FINAL_COLLATED_PDF — the two BLOB or LOB payload columns holding the intermediate draft and the final collated PDF. Two LOB indexes, SYS_IL0000324968C00008$$ and SYS_IL0000324968C00009$$, are documented, consistent with these two large-object columns.
  • CREATION_DATE and CREATED_BY — standard Oracle who-columns capturing the creation timestamp and the creating user or application.

The surrogate primary key (REQUEST_ID) is distinct from the LOB indexes, which are technical indexes rather than business-key candidates. No composite unique key beyond REQUEST_ID is documented.

Common Use Cases and Queries

Because the table is request-scoped and transient, most access is by REQUEST_ID or by PRINT_STATUS for operational monitoring. Typical scenarios include verifying whether a collated PDF was produced for a given request, checking print status, and purging rows once the final output has been printed. A representative query is:

  • SELECT request_id, printer_name, print_style, print_status FROM edr.edr_collate_print_temp WHERE request_id = :request_id;
  • SELECT request_id, print_status, creation_date FROM edr.edr_collate_print_temp WHERE print_status IS NULL OR print_status = :pending;
  • SELECT request_id, created_by, creation_date FROM edr.edr_collate_print_temp ORDER BY creation_date DESC;

Reporting is generally limited to throughput and failure counts by printer or print style and to reconciliation of collation jobs against concurrent request history. Extraction of the LOB columns should be avoided in ad-hoc reporting because of their size; reporting should rely on the scalar columns instead.

Related Objects

The documented relationship data classifies this table as standalone, and no foreign-key columns are exposed beyond REQUEST_ID. The most significant related objects are therefore those that share the request-scoped identity and the EDR print pipeline:

  • FND_CONCURRENT_REQUESTS — joined on REQUEST_ID to correlate the collation and print job with its concurrent request record.
  • FND_CONCURRENT_PROGRAMS — referenced through the concurrent request to identify the program that produced the collated output.
  • FND_PRINTER — resolves PRINTER_NAME to a defined printer.
  • Other EDR schema tables — the source document and collation staging objects feeding DRAFT_COLLATED_PDF and FINAL_COLLATED_PDF.

Because the join to the concurrent request tables is on REQUEST_ID, that column is the principal integration point for both operational queries and archival or purge processes.