Search Results get_tax_amount_and_code

Overview

APPS.CLN_NTFYINVC_PKG is a PL/SQL package in the Oracle E-Business Suite APPS schema associated with Oracle's contract lifecycle and supplier invoice notification functionality (the CLN module, marketed in the context of Oracle Procurement Contracts and related 3C/electronic commerce integrations). Its primary business purpose is to manage the notification, validation, and follow-up processing of supplier invoices that originate from external trading-partner or e-commerce flows and that must be imported into Oracle Payables. The package bridges transaction data held in ECC (Exchange/XML Gateway) and Order Entry structures with the Oracle Payables invoice interface tables, providing the logic needed to detect rejected invoices, raise notifications to the system administrator, update document status, and archive rejection history. It is classified in the ETRM repository with an API classification of OTHER, meaning it is a supporting internal utility package rather than a formally published open interface. It is referenced by the CLN_3C3_AP_TRIGGER_PKG package and referenced by one other package, indicating it participates in a coordinated invoice-triggering and notification chain.

Key Procedures and Functions

The document metadata lists fourteen documented procedures and functions. Their names indicate the following responsibilities:

• GET_NOTIFYINVOICE_PARAMS — Retrieves configuration or profile-driven parameters controlling invoice notification behavior.
• GET_PAYMENT_TERM_CODE — Derives the applicable payment term code for the invoice being processed.
• GET_TAX_AMOUNT_AND_CODE — Extracts tax amount and tax code values to populate the invoice interface.
• GET_DOC_GENERATION_DATETIME — Obtains the document generation timestamp, typically used to validate document age or sequencing.
• CLN_UPDATE_DOC_STATUS — Updates the status of the associated document or transaction record.
• RAISE_UPDATE — Raises or propagates an update event, likely through the notification/error framework.
• ERROR_HANDLER — Centralized exception and error logging routine for the package.
• XGM_CHECK_STATUS — Checks the status of an XML Gateway (ECX) message or transaction.
• INVOICE_IMPORT_STATUS_HANDLER — Interprets the outcome of the invoice import process and triggers appropriate downstream action.
• UPDATE_INV_HEADER_INTERFACE — Updates invoice header records in the Payables interface tables.
• NOTIFY_INVOICE_TO_SYSADMIN — Sends notification of invoice problems or rejections to the system administrator.
• TRIGGER_REJECTION — Initiates rejection processing for an invoice that failed validation or import.
• GET_REJECTED_INVOICE_DETAILS — Retrieves details of rejected invoices for reporting or notification.
• GET_PO_SHIPMENT_INFO — Fetches purchase order shipment information used to match or enrich invoice data.

Tables Accessed

The package accesses a range of APPS synonyms. Oracle Payables interface and rejection tables — AP_INVOICES_INTERFACE, AP_INVOICE_LINES_INTERFACE, and AP_INTERFACE_REJECTIONS — are used to stage, validate, and record rejected invoices. AR_DOCUMENT_TRANSFERS and AR_PAYMENT_SCHEDULES_ALL support document transfer and payment term determinations. CLN_AP_INVOICE_REJECTION_ARCH stores archived rejection history. The ECX group (ECX_DOCLOGS, ECX_EXT_PROCESSES, ECX_TP_HEADERS, ECX_TRANSACTIONS) provides XML Gateway trading-partner, transaction, and process logging context. FND_CONCURRENT_REQUESTS is consulted for concurrent program status. HZ_PARTY_SITES supplies party/site information, while OE_ORDER_HEADERS and OE_ORDER_LINES supply order context. M4R_3C4_DOCUMENT_NUM_S is a sequence used for document numbering.

Usage Notes

CLN_NTFYINVC_PKG is invoked indirectly by the invoice trigger and 3C integration packages rather than from end-user forms. It is typically executed within concurrent program runs that import supplier invoices from trading partners, where it evaluates import outcomes, records rejections, archives rejection data, and notifies the system administrator. Custom extensions should call its documented procedures only in the same sequence as the delivered trigger chain to preserve interface table integrity and notification consistency.