Results for “ben_per_cm_prvdd_f_pk”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

The BEN_PER_CM_PRVDD_F table resides in the BEN schema, the database owner for the Oracle Advanced Benefits (OAB) module in Oracle E-Business Suite 12.1.1 and 12.2.2. It captures the communications that must be provided to a participant when a life event occurs. In practical terms, it is the delivery-tracking record for life-event driven communications: it identifies which person communication was expected, whether the communication was requested or inspection-required, and the current delivery status, method, and medium.

As with many Oracle HRMS-family date-tracked tables, the object is defined with an effective-dating convention (DateTrack) and carries the standard WHO columns and a multitenancy-related BUSINESS_GROUP_ID. The metadata's heuristic Data Vault classification identifies this as a standalone structure, meaning no foreign-key dependencies were mined from the FK structure. In Data Vault modeling terms, it is therefore best treated as a standalone satellite or transactional record rather than a hub or link, and integrators should not assume referential integrity to parent BEN objects at the database level.

Key Information Stored

The primary key is BEN_PER_CM_PRVDD_F_PK, defined over PER_CM_PRVDD_ID, EFFECTIVE_START_DATE, and EFFECTIVE_END_DATE. The unique index on these three columns is the business-key candidate: PER_CM_PRVDD_ID is the surrogate identifier for a person communication provided, while the two date columns implement DateTrack versioning. The most significant columns include:

• PER_CM_PRVDD_ID – surrogate key for the provided-communication record.
• PER_CM_ID – identifies the underlying person communication definition.
• RQSTD_FLAG – indicates whether the communication was requested.
• INSPN_RQD_FLAG – flags whether inspection of the communication is required.
• PER_CM_PRVDD_STAT_CD – current status of the provided communication.
• CM_DLVRY_MED_CD and CM_DLVRY_MTHD_CD – delivery medium and delivery method codes.
• SENT_DT, TO_BE_SENT_DT – actual and planned send dates.
• INSTNC_NUM and DLVRY_INSTN_TXT – delivery instance number and text.
• RESND_RSN_CD, RESND_CMNT_TXT – resend reason and comments.
• ADDRESS_ID – the address used for delivery.
• BUSINESS_GROUP_ID – the business group owning the record.
• OBJECT_VERSION_NUMBER – optimistic locking control.
• LAST_UPDATE_DATE, CREATED_BY – standard audit columns.

The 30 PCD_ATTRIBUTE1 through PCD_ATTRIBUTE30 columns form a descriptive flexfield segment block, with PCD_ATTRIBUTE_CATEGORY holding the context.

Common Use Cases and Queries

Typical reporting retrieves all provided communications for a person or life event, filtered to the current effective version:

• Life-event audit: list communications required versus actually sent, using RQSTD_FLAG, INSPN_RQD_FLAG, and PER_CM_PRVDD_STAT_CD.
• Delivery-channel analytics: aggregate by CM_DLVRY_MED_CD and CM_DLVRY_MTHD_CD.
• SLA tracking: compare SENT_DT against TO_BE_SENT_DT.
• Resend analysis: group by RESND_RSN_CD to identify recurring issues.

A representative query pattern selects the active DateTrack row by constraining SYSDATE between EFFECTIVE_START_DATE and EFFECTIVE_END_DATE, joined on PER_CM_ID to the person communication definition and on ADDRESS_ID to the address record.

Related Objects

Although the mined FK structure classifies this table as standalone, operational joins are normally applied on the documented columns:

• BEN_PER_CM_F – joined via PER_CM_ID to obtain the person communication definition.
• BEN_PER_CM_PRVDD_F_PK – the primary key index used for direct record lookups.
• Person communication and life-event tables in the BEN schema that share PER_CM_ID.
• Address objects joined via ADDRESS_ID.
• Advanced Benefits concurrent programs and the OAB person communication APIs that populate these records during life-event processing.

Because referential integrity is not enforced at the database level, implementers should confirm join cardinality against the BEN data model rather than assuming mandated parent-child relationships.