Search Results hr_maintain_proposal_swi




Overview
Explore in AI Chat

Overview

The APPS.HR_MAINTAIN_PROPOSAL_SWI package body is a server-side workflow integration (SWI) layer within the Oracle E-Business Suite Human Resources (HR) module. Its purpose is to expose the salary proposal maintenance business logic — creation, update, deletion, and approval of salary proposals and their components — in a form suitable for invocation from Oracle Workflow, forms, or other service-oriented callers. The SWI suffix denotes a "Server Web Interface"/workflow integration wrapper: rather than duplicating validation logic, HR_MAINTAIN_PROPOSAL_SWI delegates the substantive work to the underlying API package HR_MAINTAIN_PROPOSAL_API, which it references as a dependency. In Oracle EBS 12.1.1 and 12.2.2 the object is shipped in the APPS schema with a status of VALID, classified as a generic OTHER API. It is a leaf object: it is not referenced by any other database object, indicating it is an entry-point façade rather than a shared library consumed by other packages.

Key Procedures and Functions

The package body documents nine procedures covering the complete lifecycle of a salary proposal. None of the parameter lists are reproduced here, as they are not part of the documented metadata.

  • INSERT_SALARY_PROPOSAL — Creates a new salary proposal record, establishing the parent proposal entity to which components are later attached.
  • UPDATE_SALARY_PROPOSAL — Modifies an existing salary proposal, applying validated changes to the proposal header.
  • DELETE_SALARY_PROPOSAL — Removes a salary proposal in its entirety.
  • CRE_OR_UPD_SALARY_PROPOSAL — A convenience entry point that performs an insert or update as appropriate, allowing callers to submit a proposal without first determining whether it already exists.
  • INSERT_PROPOSAL_COMPONENT — Adds an individual component (for example, a compensation element or line) to an existing proposal.
  • UPDATE_PROPOSAL_COMPONENT — Modifies an existing component within a proposal.
  • DELETE_PROPOSAL_COMPONENT — Removes a component from a proposal.
  • APPROVE_SALARY_PROPOSAL — Drives the approval action on a proposal, invoking the downstream approval and transaction logic.
  • PROCESS_API — A generic dispatcher that routes an incoming request to the appropriate operation above, supporting a consolidated, parameter-driven invocation style.

Supporting dependencies confirm the design: HR_MAINTAIN_PROPOSAL_API supplies the core business rules, HR_API and HR_TRANSACTION_SWI provide the standard API and transaction control scaffolding, HR_GENERAL and HR_UTILITY supply shared helpers, and HR_MULTI_MESSAGE manages message accumulation. PER_PYP_INS indicates involvement of the payroll/person insert logic.

Tables Accessed

The documented tables referenced through APPS synonyms are XMLDOM and XMLPARSER. These are not base HR tables; they are XML processing components backed by the XDB schema objects DBMS_XMLDOM (with the XMLDOM synonym) and XMLPARSER. Their presence establishes that HR_MAINTAIN_PROPOSAL_SWI accepts and parses XML payloads, converting inbound XML documents into the structured parameters required by the underlying HR_MAINTAIN_PROPOSAL_API calls. Persistent salary proposal data ultimately resides in the standard HR proposal tables written by the API layer; the SWI package itself is a translation and dispatch layer over those APIs rather than a direct manipulator of the HR base tables.

Usage Notes

Because the package is not referenced by any other database object, it is intended to be invoked externally — most commonly from Oracle Workflow function activities, from Oracle Forms, or from custom PL/SQL that submits XML-based requests. Business events in the salary proposal cycle generate workflow activity, which calls this SWI with an XML document describing the proposal or its components; the package parses the document through XMLDOM/XMLPARSER, validates via HR_API and HR_TRANSACTION_SWI, performs the requested operation through HR_MAINTAIN_PROPOSAL_API, and returns status and messages through HR_MULTI_MESSAGE. The generic PROCESS_API procedure is the preferred entry point when integrating from custom code, since it centralizes routing and error handling. The object is deliverable-supplied and should not be modified; enhancements should be directed to the underlying HR_MAINTAIN_PROPOSAL_API or by wrapping this package in customer-owned code.