Search Results non_standard_article_exists

Overview

APPS.OE_CONTRACTS_UTIL is a utility package in Oracle Order Management (OE) that centralizes the shared business logic used to manage contract terms, contract documents, and contract-related attachments throughout the order-to-contract lifecycle. It belongs to the OM Contracts functional area and is classified as an API/UTIL package in ETRM. Its responsibilities span license verification, article (terms) copying and versioning, terms template instantiation, document management, and signature detection. A particularly relevant feature for users searching on "sign_date" is the presence of the IS_ORDER_SIGNED function and its relationship to contract approval workflow, where the sign date of an order is evaluated to determine whether a contract has been executed. The package is depended on by 12 additional packages, making it a foundational element of the OM Contracts architecture.

Key Procedures and Functions

A reviewed subset of the 26 documented routines illustrates the package's scope:

• GET_G_BSA_DOC_TYPE / GET_G_SO_DOC_TYPE — Accessor functions that return the global constant document type values for Blanket Sales Agreements and Sales Orders, primarily so Forms libraries can reference constants that the PL/SQL implementation would otherwise not expose.
• CHECK_LICENSE — Verifies whether the Sales Contracts license/feature is enabled before contract functionality is invoked.
• COPY_ARTICLES / COPY_DOC — Duplicate contract articles and contract documents, respectively, supporting re-use of terms across agreements.
• VERSION_ARTICLES — Creates versioned copies of contract articles when changes are committed.
• QA_ARTICLES / NON_STANDARD_ARTICLE_EXISTS / WF_NON_STNDRD_ARTICLE_EXISTS — Validate and query article definitions, flagging non-standard articles that require workflow approval.
• DELETE_ARTICLES / PURGE_ARTICLES — Remove articles from contracts and purge orphaned or obsolete article records.
• ATTACHMENT_LOCATION / TERMS_EXISTS — Resolve where a contract document attachment is stored and confirm whether terms exist on the contract.
• GET_ARTICLE_VARIABLE_VALUES / GET_TERMS_TEMPLATE / GET_TEMPLATE_NAME — Retrieve the variable values, terms template, and template name used during terms instantiation.
• INSTANTIATE_TERMS / INSTANTIATE_DOC_TERMS — Generate contract terms and document terms from a template, producing the clauses that form the agreement.
• IS_ORDER_SIGNED — Determines whether an order/contract has been signed. This is the function most closely associated with "sign_date"; it evaluates the signature state and is used by the contract approval workflow and by consumers interested in the sign date recorded on the order or contract header.
• GET_ITEM_INFO — Returns item-related attributes needed when building contract articles.

Tables Accessed

The package reads and writes the core Order Management contract tables through APPS synonyms:

• OE_ORDER_HEADERS_ALL / OE_ORDER_LINES_ALL — Header and line records for sales orders and contracts; used for order-signature evaluation (sign_date related checks), license-driven processing, and article generation.
• OE_BLANKET_HEADERS_ALL / OE_BLANKET_HEADERS_EXT / OE_BLANKET_LINES_ALL — Blanket sales agreement headers, their extension attributes, and lines, supporting terms and article management on agreements.
• FND_ATTACHED_DOCUMENTS — The Oracle Applications attachment framework, used by ATTACHMENT_LOCATION and COPY_DOC to link contract documents to their source records.
• PLITBLM — The PL/SQL item table used to pass item data into article instantiation logic for GET_ITEM_INFO and related routines.

Usage Notes

OE_CONTRACTS_UTIL is not typically called directly by end users. It is invoked internally by the Oracle Forms-based Sales Contracts and Order Management user interfaces, by the contract approval workflow, and by other PL/SQL packages in the OM Contracts stack (12 dependent packages are documented). Customizations that need to duplicate contracts, replicate terms templates, validate non-standard articles, or query whether an order is signed — for example, when retrieving a sign_date for reporting — should call the documented functions rather than reimplement the logic. Because the package manipulates base OM tables, any custom call should be wrapped in the standard FND_API exception and message handling, and executed in an environment where the Sales Contracts license is validated via CHECK_LICENSE.