Search Results phone_date
Overview
GMF_AR_CUSTOMER is a stub package body owned by APPS within the Oracle E-Business Suite, delivered as part of the Oracle Process Manufacturing (OPM) financial integration layer. Its header comment ($Header: gmfcscob.pls 120.1 2006/02/01) indicates it belongs to the OPM cost/accounting source family of PL/SQL units prefixed "GMF." The package exposes a set of customer-information accessor functions that callers — historically OPM order capture, pricing, and shipping modules — use to retrieve Accounts Receivable attributes for a given customer, address, contact, party, or party site combination.
Despite its name and API surface, every documented function in this package body returns a hard-coded NULL (or FALSE, in the case of IS_OPM_ORG). In ETRM 12.1.1 and 12.2.2 it is therefore classified as an API classification of OTHER rather than a functioning public API. It serves as a placeholder or vestigial shim: the real implementations of customer phone, terms, FOB, sales representative, currency, and currency-date lookups reside in Oracle Receivables or in OPM-specific seeded logic, while GMF_AR_CUSTOMER preserves the historic call signature so that dependent code compiles and runs without error.
Key Procedures and Functions
The package body documents eight functions, each returning NULL or FALSE:
- PHONE — returns a VARCHAR2 intended to hold a customer's telephone number for the supplied customer, address, contact, party, and party-site identifiers, filtered by phone type.
- TERMS — takes a payment-terms identifier and returns the payment-terms description or name as VARCHAR2.
- FOB — accepts an FOB point code and returns the corresponding FOB description.
- SALESREP — given a salesperson identifier and organization identifier, returns the sales representative name.
- CURRENCY — returns the currency code applicable to a customer/site-use/organization combination.
- CURRENCY_DATE — returns the DATE on which the customer's currency relationship became effective.
- IS_OPM_ORG — returns a BOOLEAN indicating whether the supplied organization identifier is an OPM (Process Manufacturing) organization; the stub always returns FALSE.
- PHONE_DATE — the function associated with the user search term "phone_date." It accepts customer, address, contact, party, and party-site identifiers and returns a DATE. Its documented purpose is to supply the date context associated with a customer phone record (for example, the effective or last-updated date of the phone entry). Because the body is a stub it unconditionally returns NULL.
Tables Accessed
The ETRM metadata records no tables referenced via APPS synonyms for this package. This is consistent with the source listing: no SQL statements appear in any function body, and no SELECT, INSERT, UPDATE, or DELETE is issued. The package is entirely self-contained and performs no database I/O against customer, contact, phone, terms, or currency tables. Any table access a caller expects — for example HZ_CUST_ACCOUNTS, HZ_CUST_SITE_USES_ALL, HZ_CONTACTS, or AR_TERMS — must be performed directly by the calling code or by the replacement logic in Oracle Receivables.
Usage Notes
GMF_AR_CUSTOMER is referenced by one other documented package, indicating that at least one OPM component still binds to its call signatures. Typical invocation contexts include OPM order-management forms and concurrent programs that previously depended on GMF-supplied customer attributes, as well as custom extensions layered on OPM.
Because every function returns NULL, callers must not rely on this package for production data. In Oracle EBS 12.1.1 and 12.2.2, customer-facing attributes should be sourced from the Oracle Trading Community Architecture (TCA) and Receivables APIs, such as HZ_CUST_ACCOUNT_V2PUB or the AR customer interfaces. Where the dependent package requires the GMF_AR_CUSTOMER signature, the recommendation is to redirect those lookups to supported TCA/AR views and functions, or to wrap the calls in custom logic that treats a NULL return as "no OPM override." PHONE_DATE in particular should be replaced with a direct query against the phone/contact effective-date columns in TCA. The stub may be retained during upgrades to preserve compilation integrity, but should be treated as deprecated and excluded from any new development.