Search Results reject_value_found

Overview

The APPS.JG_GLOBE_FLEX_VAL package body implements the globe flexfield validation engine used by Oracle E-Business Suite globalization (JG) functionality. Its principal business purpose is to validate and enforce the context-sensitive descriptive flexfield structures that support country-specific and legal-entity-specific attributes on key Oracle Receivables and Oracle Payables entities — most notably customers, customer profiles, and AP invoices. The package combines a private context-code index (implemented via a PL/SQL associative array and the private find function) with a suite of public validation routines that check whether a supplied flexfield context exists, whether attribute values conform to the defined context and business rules, and whether the combination of context and attribute values preserves referential integrity across the relevant interface and transaction tables.

In the EBS 12.1.1 and 12.2.2 code lines, this package is central to the JG (Globalization) descriptive flexfield validation stack. Because it mediates between the flexfield definition tables and the country-specific transaction tables, it is invoked whenever user-entered or imported invoice and customer data must be validated against globally defined context structures before being accepted into the system.

Key Procedures and Functions

The documented public API comprises thirteen procedures and functions, organized around four validation concerns.

• Context resolution and existence: GDF_CONTEXT_EXISTS determines whether a given descriptive flexfield context code is valid and available, and REASSIGN_CONTEXT_CODE moves records from one context to another, supporting context migration and correction.
• Attribute-level validation: CHECK_ATTR_VALUE is the generic attribute validator; CHECK_ATTR_VALUE_AP and CHECK_ATTR_VALUE_AR are the Payables and Receivables specializations that apply the appropriate segment and value-set rules for each product.
• Context integrity and business rules: CHECK_AP_CONTEXT_INTEGRITY, CHECK_AR_CONTEXT_INTEGRITY, CHECK_AP_BUSINESS_RULES, CHECK_AR_BUSINESS_RULES, and REJECT_VALUE_FOUND enforce that a context/invoice or context/customer combination is internally consistent and permitted, rejecting values that violate configured globalization business rules.
• Interface insertion: AR_CUST_INTERFACE, INSERT_JG_ZZ_INVOICE_INFO, and INSERT_GLOBAL_TABLES populate the Receivables customer interface and globalized JG holding tables with validated context data, making verified attributes available to downstream AutoInvoice and Payables import processes.

These routines share the package-global g_context_tab context list and FND_LOG-based diagnostic constants defined in the package initialization section.

Tables Accessed

Table access is performed through APPS synonyms. AP_INVOICE_DISTRIBUTIONS_ALL is read to validate the invoice distributions against which AP context and business-rule checks are applied. RA_CUSTOMERS_INTERFACE and RA_CUSTOMER_PROFILES_INTERFACE receive the rows produced by AR_CUST_INTERFACE, enabling validated customer attributes to flow into the Receivables interface. AR_SYSTEM_PARAMETERS supplies Receivables configuration controlling validation behavior. FND_DESCR_FLEX_CONTEXTS provides the descriptive flexfield context definitions that underpin context existence and integrity checks. FND_CONCURRENT_REQUESTS is referenced for concurrent program context, and PLITBLM is the standard PL/SQL integer table type used in bulk-processing logic.

Usage Notes

JG_GLOBE_FLEX_VAL is invoked indirectly rather than as an end-user-facing API. It is called from globalization forms and validation triggers during entry of AP invoices and AR customers, from concurrent programs that import invoices and customers (AutoInvoice and Payables Invoice Import), and from custom code that needs to perform the same globalized flexfield validation. Five other packages reference it, indicating it is a shared low-level validation service. Because the package performs interface inserts as well as validation, callers should invoke it within the transaction that commits the corresponding interface rows and must not assume it is a read-only checker. Version header 120.23.12020000.6 reflects the patched level shipped for the 12.1.1/12.2.2 code lines.