About Merging Work Order Accounts and Contacts
When two account or contact records are merged, the application associates service work orders from the merged account or contact to the remaining account or contact.
Work Order Table Columns
Foreign keys pointing to a deleted party need to be updated to the new party ID whenever a merge takes place for Accounts or Contacts. The following table shows the columns in the SVC_WORK_ORDERS table that contain contact or account party data.
|
Column |
Description |
Foreign Key To Merge To Table's Column |
|---|---|---|
|
account_party_id |
Account for this work order. |
hz_parties.party_id |
|
contact_party_id |
Contact for this work order. |
hz_parties.party_id |
|
contact_party_site_id |
Work order party site where the service will be performed. |
hz_party_sites.party_site_id |
The Merge Process
When an account or contact is merged, the work order foreign keys need to be updated to the surviving party. During the merge, both editable and non-editable work orders are updated.
Events are generated for:
-
Editable OFS work orders
-
All non-OFS work orders (excluding any that you may have made read-only using non-standard values for
WoIntegrationStatusCd)
The Merge Uptake
The merge uptake can be done either by specifying
metadata in the .rdf file or using
PL/SQL. Merges are allowed even when the foreign key has validations
that disallow the update. For example, the work order is read-only.
Such validations can be bypassed by checking if a merge is being performed.
Integration Events
When a work order is created or updated, an event is generated. These events are used by OIC to sync the data with OFS or with any other external Field Service application.
In the case of a contact or account merge, this updates the work order so it sends the events.
The following illustration shows the flow of create and update events.
Work Orders Integrating with Oracle Field Service
Work orders support a predefined integration with OFS.
The following table shows the criteria that's already coded for making a work order editable. Read-only work orders don't have events sent to OFS. This code can be reused to enable sending events only when a work order is editable.
Criteria to allow events resulting from a merge (all must be true):
|
Number |
Criteria |
Description |
|---|---|---|
|
1 |
|
The work order has a category of external. This category
is defined as: Note: This is a redundant criteria given criteria number
two.
|
|
2 |
|
The work order integrates with OFS. |
|
3 |
|
The work order is open. |
|
4 |
|
If it isn't in one of these integration statuses, it's because a work order transaction is in the process of being sent to OFS and the work order is read-only. |
|
5 |
|
The work order scheduled date isn't in the past. |
Work Orders Integrating with a Third-Party Application
These work orders support an extended integration with a third-party field service application.
The following table shows the criteria that's already coded for making a work order editable. Read-only work orders don't have events sent to third-party applications. This code can be reused to enable sending events only when a work order is editable.
Criteria to allow events resulting from a merge (all must be true):
|
Number |
Criteria |
Description |
|---|---|---|
|
1 |
|
The work order has a category of external. This category
is defined as: |
|
2 |
|
The work order doesn't integrate with OFS. |
|
3 |
|
The work order is open. |
Generic Work Orders
These work orders don't have a predefined integration with any external application. They are always editable, events are always allowed, and any external application can consume the events.
The following table shows the criteria that's already coded for making a work order editable. Criteria to allow events resulting from a merge (all must be true):
|
Number |
Criteria |
Description |
|---|---|---|
|
1 |
|
The work order has a category of Internal making
it a Generic Work Order. This category is defined as: |