Search Results po_orgs_sv




Overview
Explore in AI Chat

Overview

PO_ORGS_SV is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite releases 12.1.1 and 12.2.2. The suffix "SV" denotes a validation or security-validation helper package, a naming convention widely used in the Procure-to-Pay and Order-to-Cash product families. PO_ORGS_SV encapsulates the rules that determine which inventory organizations a user, responsibility, or operating unit is permitted to transact in when creating or querying purchasing documents. Rather than embedding organization-access logic directly in each form, Oracle centralizes it in this package so that requisitions, purchase orders, releases, shipments, receiving, and vendor records all apply a consistent organization security model. The package is documented with the API classification OTHER in the ETRM repository and carries a VALID status. It exposes five documented procedures and functions and depends on the SYS.STANDARD package, a small set of inventory-related tables accessed through APPS synonyms, and the sibling validation package RCV_SHIPMENT_OBJECT_SV. Because it is a shared utility, PO_ORGS_SV is referenced by ten other packages across purchasing and receiving, which makes it a foundational element of organization-level access control rather than an end-user-facing API.

Key Procedures and Functions

The documented interface of PO_ORGS_SV contains five procedures and functions. The ETRM metadata records the member count but does not publish individual signatures, and no parameter lists should be assumed. Functionally, this family of routines performs the following work:

  • Validation of an organization identifier against the set of organizations accessible to the current session, returning a Boolean or status indicator.
  • Determination of the default or "current" inventory organization for a given responsibility or user, used to pre-populate purchasing and receiving forms.
  • Resolution of the operating unit and ledger context associated with an organization, supporting multi-org (MOAC) access control in Release 12.
  • Item and revision level checks that confirm an item is valid and enabled within the target organization before a document line is saved.
  • Utility functions that return lists or flags consumed by the calling validation packages.

These routines are internal helpers; they do not commit transactions and are not intended for direct invocation by customer code.

Tables Accessed

The package reads the following tables through APPS synonyms:

  • MTL_PARAMETERS — the master organization definition, supplying the organization name, code, and default inventory parameters used to resolve organization identity.
  • MTL_INTERORG_PARAMETERS — inter-organization transfer settings, used to determine whether a source and destination organization pairing is valid and whether transfers are permitted between them.
  • MTL_SYSTEM_ITEMS — item master records, confirming that an item exists and is enabled in the organization being validated.
  • MTL_ITEM_REVISIONS — revision definitions, verifying the revision attached to a document line is valid and effective in that organization.
  • DBMS_OUTPUT and PLITBLM — the standard Oracle output buffer and PL/SQL table utility package, used for debugging and in-memory collection handling rather than for persistent storage.

All access is read-oriented; the package does not maintain organization data, it only validates and resolves it.

Usage Notes

PO_ORGS_SV is invoked indirectly. Its documented consumers include PO_RELEASES_SV2, PO_REQ_LINES_SV1, PO_SHIPMENTS_SV1, PO_VENDORS_SV, RCV_HEADERS_INTERFACE_SV, RCV_RMA_TRANSACTIONS, RCV_ROI_HEADER_COMMON, RCV_ROI_RETURN, RCV_ROI_TRANSACTION, and RCV_TRANSACTIONS_INTERFACE_SV. In practice this means the package executes whenever a purchasing or receiving form performs organization validation—for example when the Purchasing, Requisitions, or Receiving windows default the current organization, validate a ship-to or deliver-to organization, or commit a receipt against an organization. It is also reached through the public validation packages when custom code calls those APIs, since the organization check is inherited rather than repeated. Administrators should treat PO_ORGS_SV as internal infrastructure: it should not be called directly from custom PL/SQL, and its logic should never be duplicated. Troubleshooting organization access problems typically begins by inspecting the security profile and MOAC configuration that this package reads, rather than by modifying the package itself.