1.2.8.1 Functional Enhancements
Table 1-4 Functional Enhancements
| Summary | Description |
|---|---|
| Data Segment enhancement | Following Data Segments are enhanced with
introduction of new fields to support extended party information
capture.
|
| Tax Declaration Data Segment Enhancement | The Tax Declaration data segment has been enhanced to capture comprehensive tax details, including the withholding tax information for each party. This enhancement allows for a more detailed and accurate representation of tax obligations, ensuring compliance and facilitating better financial management. |
| Event - Payload in JSON format for Onboarding | The events published during the party onboarding process have been enhanced to include the onboardPayload in JSON format. This improvement facilitates a more structured and flexible data representation, allowing for easier integration and processing of onboarding information. |
| Event - Payload in JSON format for Amendment | The events published during the party amendment process have been enhanced to include the amendPayload in JSON format. This enhancement provides a structured and standardized way to represent the changes made during the amendment process, ensuring clarity and precision in data handling. |
| Config Transport Utility Adoption (Phase 2) |
The Config Transport utility supports the automatic
transfer of maintenances from one environment to another,
eliminating the need for manual intervention. the following
maintenances are added to be supported in Oracle Banking
Party with Configuration Transport Utility.
|
| Granular PATCH API structure change |
The Retail Granular PATCH APIs are enhanced to introduce the "param" and "values" sections. "param": This section allows users to specify one or more than one attributes that uniquely identify a record based on a combination of input attributes. By leveraging these parameters, the API can accurately target the specific records intended for modification, ensuring that the right data is accessed and amended. "values": This section is designed to define the attributes that are to be amended as part of the Granular PATCH Amendment request. Users can provide the updated values for the specified attributes, facilitating a seamless update process. These enhancements improve the API’s usability by enabling more granular control over data amendments. |
| Single Event for Amendments across Data Segments | New events, "obpyRetAmendPartyInfo" for retail parties and "obpySmbAmendPartyInfo" for SMB parties, have been introduced to streamline the publication of consolidated amendment information in "amendPayload". These events enable the availability of amendments across various data segments as part of single amendment request. |
| Party to Party Relationship Enhancement |
The Party-to-Party Relationship feature has been enhanced with the following key improvements: Introduction of Tabs: Two new tabs, "Related To" and "Related With," have been implemented to display both direct and reverse relationships for the party being searched. This enhancement provides users with a clearer and more organized view of how parties are interconnected. Relationship Attributes: The relationship attributes have been enhanced to include "Primary Party" and "Secondary Party," enabling the capture of both direct and reverse relationships effectively. The "Secondary Party" attribute is designed to automatically populate based on the selection made in the "Primary Party" attribute, ensuring a streamlined and intuitive user experience. Enhanced Party Details Access: New "View Party Details" button has been introduced, allowing users to easily access detailed information about both the Primary and Secondary Parties involved in a party-to-party relationship. This feature enhances usability by providing immediate insights into the related parties. New Endpoint for Relationship Deletion: A new API endpoint has been added to facilitate the deletion of party-to-party relationships. End point - /ob/obpy/party/v1/partyToParty/deleteRelationship These enhancements collectively improve the functionality, clarity, and usability of the Party-to-Party Relationship feature, fostering a more efficient and user-friendly experience when managing party connections. |
| Party to Party - New Relationships |
The following new relationships have been introduced within the SMB Party framework: Trustee: This relationship identifies a party appointed to manage and oversee assets or rights on behalf of another party. Beneficiary: This relationship designates a party entitled to receive benefits, assets, or distributions from other legal arrangement. These enhancements enrich the SMB Party structure, allowing for a more comprehensive representation of complex financial and legal relationships, thereby facilitating better management and interaction among parties involved. |
| Dependent LoV Values (Origin and Sub-Origin) |
The Origin Code and Sub-Origin Code fields in the Basic Information section of the retail party profile have been enhanced to function interdependently. This improvement ensures that the Sub-Origin Codes are dynamically populated based on the selections made for the Origin Code. As a result, when a user selects a specific Origin Code, the corresponding Sub-Origin Codes will automatically update to reflect valid options that align with the chosen origin. This enhancement not only streamlines the data entry process but also minimizes the risk of errors, ensuring that users select appropriate and relevant codes. |
| Font Color for disabled fields | Font color of disabled fields is changed to a darker shade for easy readability. |
| Signature validation for Authorized Signatory |
A new configuration option, AUTH_SIGN_MANDATORY, has been introduced in the Properties Maintenance section. When this configuration is set to "True," signatures will be required for adding an authorized signatories in the SMB party. Conversely, if the configuration is set to "False," providing signatures will remain optional. This enhancement allows organizations to enforce signature requirements based on their compliance and operational needs. By making signatures mandatory, organizations can ensure a higher level of accountability and authenticity in their documentation processes. Alternatively, when signatures are optional, it provides flexibility in scenarios where formal authorization may not be necessary. |
| PII Data Masking in Granular APIs | The Granular APIs have been enhanced to incorporate masking of party information in accordance with Personally Identifiable Information (PII) Mask Management. This enhancement significantly strengthens data privacy and security measures by ensuring that sensitive information is protected during data transactions and interactions. |
| Migration for Closed Branch | The Data Migration Utility has been enhanced to facilitate the migration of data to closed branches. This improvement allows organizations to effectively manage, and transfer data associated with closed branches. |
| Toggle for Service Member Data Segment Enhancement in Workflow based onboarding | A new toggle button has been introduced in the Service Member data segment of the Retail Party Management process (workflow based). This enhancement provides users with greater flexibility and control over managing service member information. |
| Minor Validation | A new configuration option, USE_MINOR_VAL_MODEL, has been introduced in the Properties Maintenance section. When this configuration is set to "True," Minor age criteria will be validated using the validation model (rules framework). Conversely, if the configuration is set to "False, Minor age criteria will be validated using MINOR_AGE_CRITERIA property in properties maintenance. |
For more information on the functional activity codes, refer to the Party Configurations User Guide.
Parent topic: Party