Search Results get_due_date

Overview

ARP_PROCESS_RECUR is an Oracle Receivables PL/SQL package in the APPS schema that supports the creation and processing of recurring invoices. It is declared with AUTHID CURRENT_USER, meaning that its SQL statements execute with the privileges of the invoking user rather than the package owner, a design choice that allows the package to be called from multiple contexts, including Oracle Forms, concurrent programs, and custom code, while respecting the caller's security profile.

The header comment ($Header: ARTERECS.pls 115.3 2002/11/15) indicates the package has been part of the Receivables code line since the earlier 11i releases and was carried forward unchanged into 12.1.1 and 12.2.2. It forms part of the internal recurring invoice infrastructure that underpins the Recurring Transactions feature in Oracle Receivables, where a recurring billing schedule generates invoices on a defined cycle. The package is exposed as an OTHER classification API in the ETRM repository, indicating it is a supporting (non-public) programmatic interface rather than a formally supported open API.

Key Procedures and Functions

• CREATE_INV_CONC_REQ — Accepts a creation flag and returns a numeric status. It is responsible for submitting the concurrent request that generates recurring invoices, allowing the recurring process to be launched programmatically rather than only through the standard concurrent manager submission.
• GET_DUE_DATE — Accepts a payment term identifier and a transaction date and returns the calculated due date. This is the function matched by the user's search term "get_due_date". It encapsulates the payment terms due-date derivation logic, including the day-of-month rules and the number of days or months defined against the term, so that recurring transactions can be assigned a correct due date before insertion.
• GET_AUTO_TRX_NUMBERING_FLAG — Accepts a batch source identifier and returns a flag indicating whether automatic transaction numbering is enabled for that batch source. The recurring process uses this to decide whether a transaction number should be generated automatically or supplied by the caller.
• INSERT_RECUR — Inserts a recurring transaction record. It receives form name and version context, an interim record structure of type RA_RECUR_INTERIM%ROWTYPE, the batch source and customer transaction type identifiers, and returns the assigned transaction number. This is the primary write path for creating recurring invoice data.
• GET_TRANSACTION_AMOUNT — Accepts a customer transaction identifier and line type and returns the corresponding transaction amount, supporting amount derivation and validation during recurring transaction processing.

Tables Accessed

• RA_BATCH_SOURCES — Read to validate the batch source and to determine the automatic transaction numbering setting via GET_AUTO_TRX_NUMBERING_FLAG. The batch source controls defaulting and numbering behaviour for transactions created through the recurring process.
• RA_RECUR_INTERIM — The interim staging table for recurring transactions. INSERT_RECUR writes rows into this table, and its row type is used as the parameter structure, making it the central data object of the package.

Usage Notes

ARP_PROCESS_RECUR is typically invoked from the Oracle Receivables recurring transactions form and from the concurrent programs that generate recurring invoices. Because the package is not a formally documented public API, direct calls from custom code should be treated with caution. Custom integrations that need due-date logic rather than full recurring processing should consider the public Receivables APIs, or replicate the payment terms rules, rather than depending on GET_DUE_DATE, whose signature and behaviour are not guaranteed across patches. Where the package is called, the caller must supply a valid batch source and customer transaction type, and must handle the returned transaction number for the created recurring record. The package is referenced by one other package within the ETRM repository, confirming its role as an internal building block rather than an entry point.