Search Results get_service_attributes




Overview
Explore in AI Chat

Overview

ASO_SERVICE_CONTRACTS_INT is a server-side PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Order Capture and Service Contracts integration layer and forms part of the foundation that allows Oracle Advanced Service Online (ASO) to interrogate, select, and persist service and warranty information against a quote or order. In release 12.1.1 and 12.2.2 the package is classified under the ETRM "OTHER" API category, meaning it is called internally rather than published as a formal open interface. The package header declares the record type WAR_REC_TYPE together with the associative array type WAR_TBL_TYPE, both of which drive its warranty retrieval logic; the same header declares CHECK_SERVICE_REC_TYPE, AVAIL_SERVICE_REC_TYPE, OKS_ORDER_SERVICE_REC_TYPE, and ORDER_SERVICE_REC_TYPE for the service availability and ordering APIs. The package exists so that quoting and ordering flows can determine whether a service is available for a given product, customer, and revision, and can obtain the associated warranty duration and coverage attributes without duplicating that logic in client-side code.

Key Procedures and Functions

  • GET_DURATION — Returns the duration and related coverage values used when a warranty or service line is applied. It operates on the WAR_REC_TYPE structure, which carries the service item, service name, description, duration quantity, duration period, coverage schedule, and warranty start and end dates. The procedure follows the standard EBS API convention with an API version number, an initialization message list flag defaulting to FND_API.G_FALSE, and outgoing message count and message list parameters.
  • IS_SERVICE_AVAILABLE — Evaluates whether a specific service may be sold or attached for the supplied product, customer, and revision combination. It corresponds to the CHECK_SERVICE_REC_TYPE structure, which holds product item, service item, customer, product revision, and request date.
  • AVAILABLE_SERVICES — Returns the set of services that are eligible for a product and customer at a given revision and request date. It corresponds to AVAIL_SERVICE_REC_TYPE and is typically consumed by quoting UI logic that must present a validated pick list of services.
  • GET_WARRANTY — Populates the WAR_REC_TYPE/WAR_TBL_TYPE structures with warranty information, including service item, service name, service description, duration quantity, duration period, coverage schedule identifier, and warranty start and end dates.
  • GET_SERVICE_ATTRIBUTES — Retrieves descriptive and coverage attributes for a service, mapping to the OKS_ORDER_SERVICE_REC_TYPE record that carries the service item, name, description, and coverage template identifier.

Tables Accessed

The documented table references are all reached through APPS synonyms. ASO_QUOTE_HEADERS_ALL and ASO_QUOTE_LINES_ALL supply the quote context against which service availability and warranty data are validated. CSI_ITEM_INSTANCES provides installed base information used to confirm that a service or warranty applies to an existing customer asset. MTL_SYSTEM_ITEMS_B supplies the item master definitions for both the product and the service item identifiers referenced by the record types. OE_ORDER_LINES_ALL links the service selection back to the order capture line when the flow proceeds from quote to order. PLITBLM is the PL/SQL table built-in referenced through the package's table type declarations. Together these tables support the read-oriented validation characteristic of the package; the package is primarily a query and derivation layer rather than a maintenance interface.

Usage Notes

ASO_SERVICE_CONTRACTS_INT is invoked from the quoting and order capture forms within ASO when a user enters or changes a service line, and from concurrent or batch processes that must validate service eligibility for large volumes of quote lines. Because the ETRM metadata records six dependent packages, it is expected to be called by other PL/SQL units in the service contracts integration chain rather than exposed directly. Custom code should call the documented procedures using the standard API versioning and message list parameters, and should treat the record type and WAR_TBL_TYPE declarations as the contract for data exchange. As with all APPS-owned packages, direct modification is not supported; extensions belong in custom packages that wrap these APIs.