Search Results get_sequence_number

Overview

APPS.FUN_SEQ_W is a wrapper package within the Oracle E-Business Suite Financials sequence management architecture. It serves as the public interface layer for the core sequencing engine delivered by the FUN_SEQ package. The "W" suffix denotes a wrapper, indicating that FUN_SEQ_W does not itself implement sequence generation logic but instead exposes, adapts, and proxies calls to the underlying sequence engine. Its principal purpose is to allocate the next control document number for a given business event — for example check numbers, payment document numbers, receipt numbers, and other sequentially controlled financial documents — while maintaining context-based isolation across operating units, banks, legal entities, and other dimensions of the sequence definition.

The package is classified as an OTHER API within the ETRM repository and is owned by the APPS schema. It carries a header identifier of 120.0, indicating a mature, largely frozen interface that has been stable since the early 11i era and is carried forward into releases 12.1.1 and 12.2.2. Because it is packaged with the Oracle proprietary notice, it is an internal Oracle-supplied component rather than a documented extension point.

Key Procedures and Functions

The package exposes three documented procedures.

• ROSETTA_TABLE_COPY_IN_P1 — An inbound data-marshalling routine. It accepts incoming JTF collection types (a JTF_VARCHAR2_TABLE_100 and a JTF_DATE_TABLE) and copies their contents into the strongly typed FUN_SEQ.control_date_tbl_type record table used internally by the sequencing engine. This bridges the loose, tabular calling conventions of the Oracle Application Framework (JTF) plumbing to the strict PL/SQL types required by the sequence core.
• ROSETTA_TABLE_COPY_OUT_P1 — The inverse outbound marshalling routine. It takes a populated FUN_SEQ.control_date_tbl_type and copies the data back out into the caller-supplied JTF_VARCHAR2_TABLE_100 and JTF_DATE_TABLE collections so that results can be consumed by the calling layer.
• GET_SEQUENCE_NUMBER — The principal functional procedure. Given a context type and value, an application identifier, a table name, an event code, two groups of supplemental attribute values, and a suppress-error flag, it derives and returns the sequence version identifier, the assigned sequence number, the assignment identifier, and an error code. This is the entry point that callers use when they need the "next number" from a configured sequence. The supplemental parameters allow the sequence definition to be selected according to qualifying control attributes such as document category, payment method, or date range.

Tables Accessed

The only table documented as referenced through APPS synonyms is PLITBLM. This is the PL/SQL inter-language (PLITBLM) message table used by Oracle's generated wrapper machinery to pass table-shaped data between layered interfaces. FUN_SEQ_W accesses it indirectly to support the collection conversions performed by ROSETTA_TABLE_COPY_IN_P1 and ROSETTA_TABLE_COPY_OUT_P1. The substantive sequence metadata — sequence definitions, assignments, and version history — resides in the FUN_SEQ core objects rather than in tables directly named in this wrapper.

Usage Notes

FUN_SEQ_W is not intended for direct customer invocation. It is called by Oracle Applications forms and concurrent programs, and by the Oracle Payments and Financials document-generation flows, wherever a controlled document number must be obtained. In EBS 12.1.1 and 12.2.2 the package operates identically; no functional divergence between the two releases is documented in the metadata.

Developers who encounter FUN_SEQ_W while searching for "get_sequence_number" should treat GET_SEQUENCE_NUMBER as an internal oracle-owned entry point. Custom code that calls it must supply a valid context type and value, an application identifier, a table name, and an event code, and must be prepared to interpret the returned error code — passing a non-null suppress-error flag merely suppresses raised exceptions rather than guaranteeing success. Because the API classification is OTHER and the package is unsupported for extension, the recommended approach for custom sequencing requirements is to use the supported public APIs of Oracle Payments or to model the requirement with a dedicated sequence table rather than depending on FUN_SEQ_W directly.