Search Results get_file_id

Overview

IBY_EC_OP_FILE_NAME_EXT_PUB is a public PL/SQL package body owned by the APPS schema that participates in the Oracle Payments (IBY) electronic commerce processing flow. Specifically, it supports the ECE (Electronic Commerce Engine) gateway used when payments are transmitted to a bank or payment partner as an output file. The package supplies logic for generating a file identifier (fileID) associated with a payment instruction being processed through that gateway.

In the standard Oracle EBS payments model, output files are produced by concurrent processes that group payable documents into runs, and each run is assigned a file name. The header comment in the source states that the file name is calculated by concatenating the literal string PYO with the file ID. Consequently, the value returned by this API directly influences the naming convention applied to the generated payment file. The package is designated as a public API (classification PUB) and is referenced by two other packages in the application, indicating that it is a deliberate extension point rather than an internal utility.

The package body is small, consisting of a single documented function, and it was introduced under version 120.0.12010000.1 with a creation date of 22 February 2010. This places the object in the Oracle EBS 12.1.1 and 12.2.2 code lines, where the Payments module retained the ECE output run infrastructure.

Key Procedures and Functions

• GET_FILE_ID — The single documented function in this package. It accepts a payment instruction identifier and returns an integer file ID. In the seeded body, the local variable is initialized to null and the function returns that null value unconditionally. The significance of this behavior is described in the source comment: if the function returns null, the file ID is instead generated from the sequence ece_output_runs_s.

Because the packaged body ships as a stub that always returns null, its practical role is that of an override hook. Customers or partners who require file IDs from an external source — for example, a value supplied by a clearing house, a bank-assigned reference, or an upstream payment system — can replace the package body and return a non-null integer. When a value is returned, the sequence-based default is bypassed and the caller uses the returned value to construct the PYO-prefixed file name.

Tables Accessed

The documented metadata for this package records no tables accessed through APPS synonyms. This is consistent with the source excerpt, which contains no SELECT, INSERT, UPDATE, or DELETE statements and no cursors. The only database object referenced in the description is the sequence ece_output_runs_s, which is mentioned as the fallback generator of file IDs when GET_FILE_ID returns null. That sequence is used by the calling ECE output processing logic, not by this package itself.

Custom implementations that replace the body may of course query payment instruction or payment document tables to derive a meaningful identifier, but such access is not part of the delivered code.

Usage Notes

The package is invoked indirectly during payment output processing through the ECE gateway. The caller is the ECE output run logic, which requests a file ID for a given payment instruction. Typical invocation scenarios include:

• Standard payment processing concurrent programs that format and write payment instruction output files for transmission.
• Any custom or partner program that calls the ECE output APIs and therefore reaches this extension point.
• Upgrade and patching activities, where the stub body may be overwritten; customized bodies must be reapplied after patching.

Because the delivered function always returns null, administrators searching for get_file_id should recognize that out-of-the-box behavior depends entirely on ece_output_runs_s. To customize, the body must be modified to return a deterministic, unique integer for each payment instruction; returning duplicate or non-numeric values can produce colliding or malformed PYO file names. The package should be treated as a public extension interface, and changes should be made in a custom schema or documented as a patchable modification to APPS.