Search Results shipment_method

Overview

AS_COLLATERAL_REQ is a multi-organization reporting view owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. It belongs to the AS – Sales Foundation product family and presents collateral request records — the internal documents that drive the printing, faxing, and shipment of marketing collateral, letters, and related correspondence to customers and contacts. The view is registered in EBS with STATUS = VALID and exposes a stable, read-oriented projection of the underlying transactional data, making it suitable for concurrent programs, BI Publisher reports, Oracle Reports, and custom integrations that must respect the session's current operating unit.

Because the object is a view rather than a table, it carries no independent storage and no autonomous transaction semantics. It functions as an access layer over the base collateral request entity, filtering rows by the organization context established at runtime. For the searched attribute fax_number, the view exposes both FAX_NUMBER and FAX_AREA_CODE, allowing output programs to reconstruct the destination fax number for a collateral request without joining to the customer or contact master.

Underlying Base Objects

The documented base object for this view is the synonym AS_COLLATERAL_REQ_ALL, which resolves to the underlying multi-org table holding collateral request rows for all operating units. The view definition is a straightforward column projection combined with an organization security predicate. That predicate evaluates the client information string via USERENV('CLIENT_INFO'), extracts the leading organization identifier, and compares it to the row's ORG_ID using NVL logic that substitutes -99 when the organization context is undetermined. In practice this means a session with no organization context returns only rows whose ORG_ID is null or -99, while a session with a valid operating unit returns only that unit's collateral requests.

The view therefore inherits the multi-org security model of the AS product rather than enforcing any additional filtering. Any query that fails to establish an operating unit through the standard EBS initialization will return an unexpected result set, which is a common source of confusion when the view is used from external tools.

Key Columns

• COLLATERAL_REQUEST_ID — primary identifier for the collateral request; the join key to related entities.
• FAX_NUMBER and FAX_AREA_CODE — the destination fax number and its area code, used when the delivery method is fax.
• DELIVERY_METHOD, PRINTER_NAME, MAIL_BLITZ_ID — control how and where the collateral is dispatched.
• CUSTOMER_ID, CONTACT_ID, PERSON_ID, ADDRESS_ID — the recipient party and location references.
• LIST_ID, LIST_ENTRY_ID, LETTER_ID — the source list and letter definition driving the request.
• STATUS, SCHEDULED_DATE, COMPLETION_DATE, PARTIAL_SHIP_FLAG — lifecycle and fulfillment state.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID — the concurrent request that generated the record.
• ORG_ID and ORGANIZATION_ID — operating unit and inventory organization context.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — descriptive flexfield storage.

Common Use Cases and Queries

Typical uses include auditing fax-based collateral fulfillment, reconciling scheduled versus completed requests, and extracting recipient fax details for downstream notification systems. A representative query retrieving pending fax requests is:

• SELECT collateral_request_id, customer_id, fax_area_code, fax_number FROM apps.as_collateral_req WHERE delivery_method = 'FAX' AND status = 'SCHEDULED';
• SELECT status, COUNT(*) FROM apps.as_collateral_req GROUP BY status;

Queries should always be executed within an initialized EBS session so that the multi-org predicate resolves to the intended operating unit.