Search Results zx_tds_reverse_document_pkg




Overview

ZX_TDS_REVERSE_DOCUMENT_PKG is an Oracle E-Business Tax (E-Business Tax / ETRM) PL/SQL package owned by the APPS schema. Its business purpose is to reverse tax documents—specifically, tax lines that were previously created and stored against a transaction—when a source document is cancelled, voided, or credited. In the Oracle EBS tax architecture, whenever a taxable transaction (an invoice, credit memo, or similar event) is processed, E-Business Tax creates corresponding tax lines and tax line summaries in the ZX_LINES and ZX_LINES_SUMMARY tables through the tax services layer. When that transaction must be reversed, the associated tax lines cannot simply be deleted; the tax engine must produce reversing entries that preserve the audit trail and correctly adjust the tax repository. ZX_TDS_REVERSE_DOCUMENT_PKG exists to perform precisely that reversal work. The naming convention (ZX_ prefix, TDS mnemonic) identifies it as part of the Tax Data Services group of packages within the E-Business Tax module. It is available in both 12.1.1 and 12.2.2, and the header comment in the source indicates a fairly early stable revision (120.2, dated 2004), suggesting the interface has been unchanged across releases.

Key Procedures and Functions

The package exposes a single documented procedure: REVERSE_DOCUMENT. As documented in the ETRM metadata, it accepts an event class record (typed as ZX_API_PUB.EVENT_CLASS_REC_TYPE) as its input and returns a status value indicating success or failure of the reversal. The use of the EVENT_CLASS_REC_TYPE input parameter ties the procedure to the standard E-Business Tax event model, meaning the caller supplies a fully populated event-class structure describing the transaction whose tax lines are to be reversed, rather than an individual transaction identifier or an ad-hoc set of scalar arguments. The procedure does not return tax data; its output is purely a return status, consistent with a write-oriented maintenance API. There are no other documented procedures or functions in this package.

Tables Accessed

The package operates across the core tax line and summary tables, together with two temporary global tables and a PL/SQL table type. It reads and updates ZX_LINES and its audit shadow ZX_LINES_S, the transactional table where individual tax lines are recorded for every taxed document. It likewise accesses ZX_LINES_SUMMARY and ZX_LINES_SUMMARY_S, which hold the summarized/tax-repository aggregation of those lines; reversing a document must adjust both the detail and the summary to keep the tax repository consistent. The two global temporary tables, ZX_REVERSE_TRX_LINES_GT and ZX_REV_TRX_HEADERS_GT, serve as intermediate staging areas: reversal candidates (transaction headers and lines) are collected into these temporary structures during processing, then processed against the permanent tax tables. The reference to PLITBLM indicates the use of the standard Oracle PL/SQL table-management utility package, commonly used for indexed access to PL/SQL tables in Oracle Forms-based and older EBS code.

Usage Notes

This package is an internal E-Business Tax API and is typically invoked by the tax engine's calling stack rather than directly by end users or forms. It would be triggered when a source application reverses a previously taxed transaction—for example, when an invoice is cancelled, a credit memo is applied, or a document is voided—so that the corresponding tax lines and tax line summaries are themselves reversed. Because ETRM documentation classifies the package as "OTHER" and records exactly one referenced-by relationship, it is a relatively low-level, narrowly scoped routine within the tax data services layer. Customizations and integrations should avoid calling it directly; developers requiring document reversal behavior should use the supported public tax APIs (such as ZX_API_PUB) that themselves invoke this package. The NOCOPY OUT parameter on the return status reflects the standard EBS convention for performance-sensitive API return values, and callers must check the returned status explicitly because failure does not raise an exception automatically.