Search Results cs_contracts_val_success

Overview

APPS.CS_CONTRACTS_PUB is a public PL/SQL package body belonging to the Oracle Service (Service Contracts / Contracts Core) module of Oracle E-Business Suite. It exposes business logic for the validation and maintenance of service contracts, coverages, and covered service lines. The package is classified as a public API (PUB), meaning its procedures are intended to be called from external code such as forms, concurrent programs, or custom extensions, rather than being restricted to internal use.

The package encapsulates the logic needed to verify the structural and date-related integrity of a service contract before it is committed, and to persist changes to contract data. It maintains a set of global constants for standard date formatting (DD-MM-YYYY) and for a family of reusable error message names, including CS_CONTRACTS_NO_CHILDREN, CS_CONTRACTS_SVC_ATT_TEMPLATE, CS_CONTRACTS_INCMPTBL_COV_LVLS, CS_CONTRACTS_VAL_SUCCESS, CS_CONTRACTS_COVERAGE_OVERLAP, CS_CONTRACTS_INVD_SVC_START_DT, CS_CONTRACTS_INVD_SVC_END_DT, CS_CONTRACTS_INVD_TXNGRP_DT, and CS_CONTRACTS_INVD_SVC_COV_DT. These messages support date token substitution (DATE1 through DATE4) for transaction group, coverage, and service start/end dates.

Key Procedures and Functions

The ETRM metadata documents three callable units in this package. Only two procedures are named explicitly; the third is referenced in the metadata count and relates to the service name lookup associated with the user's search term.

• VALIDATE_CONTRACT — Performs validation of a service contract and its related coverage and service structures. It applies the package's message constants to detect conditions such as missing children on a parent record, services attached to a template, incompatible contract coverage levels, overlapping coverages, invalid service or transaction group dates, and mismatched coverage versus service dates. It returns a validation result, typically signalling CS_CONTRACTS_VAL_SUCCESS when the contract passes.
• UPDATE_CONTRACT — Persists changes to contract header, billing, coverage, and covered-product data. It is the write-side counterpart to VALIDATE_CONTRACT and is invoked when a contract is created or modified through the public API.
• Service name retrieval — In the context of the search term "get_service_name", the package exposes logic to resolve a service name, typically by joining covered-product and service records against inventory item definitions. The documented table list includes MTL_SYSTEM_ITEMS_KFV, which is the key flexfield view used to obtain the concatenated item/service name.

Tables Accessed

The package reads and writes a defined set of contract and service tables through APPS synonyms:

• CS_CONTRACTS_ALL — master contract header and version records.
• CS_CONTRACTS_BILLING and CS_COV_BILLING_TYPES, CS_COV_BILL_RATES — billing terms and rates applied to contracts and coverages.
• CS_CONTRACT_COV_LEVELS and CS_CONTRACT_LINE_TPLTS — coverage level definitions and contract line templates.
• CS_COVERAGES, CS_COVERAGE_TXN_GROUPS, CS_COVERED_PRODUCTS, CS_COV_REACTION_TIMES — coverage records, transaction groups, covered products, and reaction time definitions.
• CS_CP_SERVICES_ALL and CS_CP_SERVICE_TRANSACTIONS — service line definitions and service transactions.
• CS_CONTRACT_STATUSES — contract status lookup values.
• MTL_SYSTEM_ITEMS_KFV — item key flexfield view, used to resolve service names.
• PLITBLM — the PL/SQL message table used to retrieve the text of the G_* message constants.

Usage Notes

CS_CONTRACTS_PUB is typically invoked from the Service Contracts forms and from concurrent programs that validate or update contracts. It is also referenced by one other package, indicating use as a shared validation/update utility within the Service Contracts codebase. Because it is a PUB API, custom code can call VALIDATE_CONTRACT prior to committing contract changes and UPDATE_CONTRACT to apply them. Callers should expect message names rather than literal text, retrieving actual message strings from FND_MESSAGE or PLITBLM, and should account for the date-token convention (DATE1–DATE4) when interpreting error output.