Veeva OpenData data models have been added for the following countries/regions:
Hong Kong (HK)
The data models are based on the Other Countries (ZZ) data model. The data model also includes additional fields so they are consistent with the China OpenData data model.
The activated reference codes are based on the reference codes that are activated for Other Countries (ZZ), along with additional reference codes supported by the China OpenData team.
Chinese (zh) and Traditional Chinese (zh-TW) will be used for the Network UI, data model fields, and reference data.
Albanian (SQ) is now supported as a reference language. It is not supported for Network data model fields or for the Network UI.
This enhancement is enabled in your Network instance by default.
Select the language for reference codes
To view reference codes in this language:
- On the Network menu bar, click My Profile.
- In the Settings section, expand the Language list and select Albanian.
- Apply your changes.
HCO and HCP name formatting rules have been added for the following regions:
Hong Kong (HK)
This enhancement is enabled by default in your Network instance.
HCO Name calculation
The formatted name for HCOs uses the
HCP Name calculation
HCP names will use the
full_name__v field is blank, the formatted name will be calculated using these Veeva fields in the following order:
last_name__v + first_name__v
The formatted name displays on the profile page.
Field updates and merges
The dataflow functionality for record updates and merges now considers how standard (__v) and custom (__c) fields are managed.
Fields can be managed locally, managed by Veeva OpenData, or managed by a third party data provider. Previously, data could be lost when updates or merges occurred because the process was unaware of the field management. For example, if you do not subscribe to field-level OpenData subscriptions (Email, HIN, NCPDP, GeoSubdivision, or CIP), those standard (__v) fields can be used for local data. When a record was merged in Veeva OpenData, any local data in those fields could be lost when the updates came down to your Network instance. These enhancements ensure that the update and merge logic respects the management of the field data.
Additionally, the merge logic will now treat NULL and EMPTY fields as the same in customer instances.
These enhancements are enabled in your Network instance by default.
These process enhancements are supported in the following activities:
OpenData ad hoc download jobs
Null and non-empty fields
In customer instances, NULL and EMPTY fields will be treated as the same. NON-EMPTY fields will prevail over NULL fields during survivorship.
The merge loser has a NON-EMPTY field. The winning record has a NULL value for the field and its source has an equal or higher rank in survivorship. The field value on the winning record will be the value from the merge loser.