Search Results save_physicalmap

Overview

IBE_PHYSICALMAP_GRP_W is a PL/SQL group-type wrapper package owned by APPS in the Oracle E-Business Suite. It belongs to the iStore (IBE) product family and supports the physical map feature, which associates a physical site or merchandise site with one or more language-specific display records. The package declares AUTHID CURRENT_USER and was last shipped under header revision IBEGRPSS.pls 115.4, dated 2002/12/18, indicating that the interface has remained stable across the 12.1.1 and 12.2.2 releases.

The "_GRP_W" suffix follows the standard Oracle EBS pattern for a generated group wrapper: it exposes the public DML entry point (save_physicalmap) alongside a set of generated Rosetta table-conversion helpers that marshal PL/SQL associative-array (index-by table) parameters into and out of the strongly typed collection types defined in the base package IBE_PHYSICALMAP_GRP. In this role the package is a technical rather than a business-facing API, but it is the documented programmatic entry point for creating, updating, and deleting physical map definitions.

Key Procedures and Functions

• save_physicalmap — the primary DML procedure. It accepts the standard API envelope (API version, message list initialization flag, commit flag, and the return status / message count / message data out parameters) together with an attachment identifier, a merchandise site identifier, and a language code table. It creates or updates the physical map and its associated language rows. Two overloads are documented: the first receives a single merchandise site identifier, while the second receives paired numeric tables that are internally converted into the msite_lang_tbl_type collection.
• delete_physicalmap — the complementary DML procedure, using the same API envelope, to remove a physical map definition.
• delete_attachment_msite — removes the association between an attachment and a merchandise site, supporting cleanup of physical map media.
• rosetta_table_copy_in_p0 / rosetta_table_copy_out_p0 — marshal the language code parameter between the generic JTF_VARCHAR2_TABLE_100 table and the package-typed language_code_tbl_type.
• rosetta_table_copy_in_p2 / rosetta_table_copy_out_p2 — marshal two paired numeric tables into and out of msite_lang_tbl_type, the merchandise-site-to-language mapping.
• rosetta_table_copy_in_p3 / rosetta_table_copy_out_p3 — marshal the logical physical map identifier collection, lgl_phys_map_id_tbl_type.
• rosetta_table_copy_in_p4 / rosetta_table_copy_out_p4 — marshal the merchandise site identifier collection, msite_id_tbl_type.

Tables Accessed

The only documented table reference is the APPS synonym PLITBLM, the multi-language or language-translation table that stores the language-specific text associated with the physical map. All insert, update, and delete activity against this table is funneled through save_physicalmap and delete_physicalmap, which is why direct DML against the underlying base table is not the supported integration path. The collection types referenced in the signatures (language_code_tbl_type, msite_lang_tbl_type, lgl_phys_map_id_tbl_type, msite_id_tbl_type) are defined in IBE_PHYSICALMAP_GRP and are not themselves tables.

Usage Notes

Because the ETRM metadata records that this package is referenced by zero other packages, it is not an internal building block of the iStore stack; it is an external, callable interface. It is typically invoked from a form or a custom concurrent program that maintains physical map data, or from custom PL/SQL that needs to register a merchandise site and its language rows without touching PLITBLM directly.

Callers should follow the standard EBS API conventions: initialize the message list as required, pass p_commit consistently with the surrounding transaction (deferring commit when the call participates in a larger unit of work), and always inspect x_return_status before proceeding. A value of FND_API.G_RET_STS_ERROR or G_RET_STS_UNEXP_ERROR should be handled by reading x_msg_count and x_msg_data and surfacing the message stack. Because the package executes under AUTHID CURRENT_USER, the invoking schema must hold the appropriate privileges on the underlying objects.