NetSuite

NetSuite is UTA's financial system. At the time of the design of this authoritative data product, there is no direct integration between Netsuite and the authoritative data in the "Onyx" systems. Instead, there is a manual data management process that involves:

As described in the transaction hub documentation, the goal state will be to get to something closer to this this:

The following documentation describes how data will be pulled from Netsuite to help complete the intiial load.

Parties

Netsuite is modeled with the role at the top of the hierarchy, and then "individual" and "company" below it:

This indicates that to consolidate this to parties, we will need to:

1. Extract all the individuals and companies by role
2. De-duplicate the individuals and companies, but ensure we retain the roles
3. Create the party nodes and associated role relationships

This sets up a complication, particularly at the time when we ask Netsuite to take the data back from authoritative data parties and into NetSuite.

Because the roles are at the top of the hierarchy in Netsuite, it appears we will need to:

1. Store the Netsuite ID for the indivdual or company in the HAS_ROLE relationship properties. This would happen as part of data migration.
2. When sending individuals and companies back to Netsuite, we have to break out the roles and send the party back individually (with the Netsuite ID)
3. When a new party is created, or when a role is added to an existing party Netsuite will need to create a new record for every new, relevant role the party plays.
4. Somehow, Authoritative Data needs to find out what that new Netsuite ID is. The most likely solution here is to ensure that the Netsuite integration be certain to store the authoritative data party ID in any new Netsuite records it creates. This means that the Netsuite integration will likely have to be "two-way":

Roles

Note that all counts below are snapshots in time (around March 2023) and do not include any de-duping. They include what we would term in our model both active and inactive relationships.

Role	Count (approximate)	Discussion
Buyer	9,202
Client	16,347
Participant	4198 4,204 451	Attorneys and law firms Managers/Personal Managers Business Managers

Buyer

1. In Netsuite, Buyers can be exported by using the "Lists" command and selecting "Relationship", then "Buyer".
2. There is a field to indicate if the Buyer is inactive; we will presume all buyers have an active buyer role unless this field is set to true.
3. Buyer role relationship dates will have to be determined as follows:
   1. If the buyer active in NetSuite, the start date will be date shown in the edit history where the record was first created.
   2. If the buyer role is inactive, the start date will be as described above, but the end date of the relationship will need to be determined from the edit history.

Client

Participant

The participant role is going to be somewhat of a challenge, but fortunately the small number of entities in Netsuite make it a tractable challenge.

The challenge is that participants in Netsuite are not drawn from a master list of attorneys and managers, but rather created as a "subclient" on the client record. This inevitably results in duplication of participants that have more than one client:

Like the Buyer role above, this implies that an integration that involves no changes to Netsuite will require exloding the parties with participant roles into duplicates inside NetSuite. Not an ideal situation, but the good news it that the scale of the data involved is small.