Search Results csd_repairs_interface_s2

Overview

CSD_REPAIR_MANAGER_UTIL is a utility package body in the APPS schema that supports the Oracle E-Business Suite Depot Repair module (CSD). Its role is to provide reusable, mass-processing primitives that operate on repair orders without the overhead of the full public API transaction flow. The package is invoked primarily by concurrent programs and internal service layers that need to create, update, or enrich repair orders in volume, such as bulk repair order generation from an external or staged data source, mass attachment creation, and threshold lookups that drive repair planning decisions.

Because it is classified as a UTIL package rather than a public API, it is not intended as an integration entry point. It assumes the caller supplies validated identifiers and context, and it depends heavily on sibling packages such as CSD_REPAIRS_PVT, CSD_REPAIRS_PUB, CSD_PROCESS_UTIL, CSD_BULK_RECEIVE_UTIL, and FND_MSG_PUB for transactional and error-handling behavior. The package is documented in ETRM as VALID at 12.1.1 and 12.2.2, with a documented set of nine procedures and functions.

Key Procedures and Functions

• GET_ITEM_QUALITY_THRESHOLD — Retrieves the quality threshold configured for a given item, reading from CSD_QUALITY_THRESHOLDS_B, for use in repair evaluation logic.
• GET_AGING_THRESHOLD — Retrieves the aging threshold configuration from CSD_AGING_THRESHOLDS_B, used to classify repair orders by age for reporting or escalation.
• MASS_UPDATE_REPAIR_ORDERS — Applies bulk updates across a set of existing repair orders, driving changes into CSD_REPAIRS and related history records.
• MASS_CREATE_ATTACHMENTS — Creates attachments in bulk via FND_ATTACHED_DOCUMENTS and FND_DOCUMENTS_PKG, typically associating documents with repair orders or service requests.
• MASS_CREATE_REPAIR_ORDERS — Creates multiple repair orders in a single pass, validating and staging rows against CSD_REPAIRS_INTERFACE before persisting to CSD_REPAIRS.
• MASS_CREATE_REPAIR_ORDERS_CP — The concurrent-program wrapper for mass repair order creation, providing the parameter/error-handling envelope required by a concurrent request.
• CREATE_SR_REPAIR_ORDER — Creates a repair order linked to a service request, interacting with CS_INCIDENTS_ALL_B and CS_SERVICEREQUEST_PUB to maintain the SR-to-repair relationship.
• UPDATE_EXTERNAL_REFERENCE — Updates the external reference field on a repair order, supporting reconciliation with external or legacy systems.
• STRING_AGGREGATE — A string aggregation helper used internally to concatenate values, commonly for building messages or delimited lists.

Tables Accessed

The package reads and writes repair order data through CSD_REPAIRS, CSD_REPAIRS_INTERFACE, CSD_REPAIRS_INTERFACE_S2, CSD_REPAIR_HISTORY, CSD_REPAIR_TYPES_B, CSD_FLOW_STATUSES_B, and CSD_PRODUCT_TRANSACTIONS (with index CSD_PRODUCT_TRANSACTIONS_S1). Configuration data is read from CSD_QUALITY_THRESHOLDS_B and CSD_AGING_THRESHOLDS_B. Item and instance context comes from CSI_ITEM_INSTANCES, CSI_I_PARTIES, MTL_SYSTEM_ITEMS_B, MTL_ITEM_CATEGORIES, and MTL_SERIAL_NUMBERS. Attachment handling uses FND_ATTACHED_DOCUMENTS, FND_ATTACHED_DOCUMENTS_S, FND_DOCUMENTS_SHORT_TEXT, and FND_LOBS. Service request linkage draws on CS_INCIDENTS_ALL_B, while customer and site data derive from HZ_CUST_ACCOUNTS, HZ_PARTIES, HZ_PARTY_SITES, HZ_PARTY_SITE_USES, HR_LOCATIONS_ALL, and PO_LOCATION_ASSOCIATIONS_ALL.

CSD_REPAIRS_INTERFACE_S2 is the staging index associated with the repair interface table, which is why the search term "csd_repairs_interface_s2" surfaces this package. Interface staging is the mechanism through which bulk repair order loads are validated before they are committed to the transactional CSD_REPAIRS table.

Usage Notes

CSD_REPAIR_MANAGER_UTIL is normally invoked from Depot Repair concurrent programs, from internal service-layer code that has already validated the caller's context, and from custom extensions that require bulk repair order processing. It should not be treated as a substitute for CSD_REPAIRS_PUB, which is the supported public API for single-transaction integration. The ETRM documentation records two other packages referencing this utility, indicating that it sits beneath a higher-level orchestration layer rather than at the top of the call stack. Because the package performs DML against interface, transaction, and history tables, callers are responsible for committing or rolling back and for interpreting the messages returned through the standard FND_MSG_PUB and FND_LOG mechanisms.