Comparing two jobs on the same policy

Comparing two jobs on the same policy in PolicyCenter

PolicyCenter supports the ability to compare two jobs on the same policy. In the base configuration, this information can be viewed in the user interface from the policy's Policy Transactions screen by selecting the two jobs and clicking the Compare button. The information appears on a screen whose label is Differences Between Pending Policy Transactions.

As is the case when comparing a job to its base policy, the organization of LOB-specific information shown on this screen is defined in an LOB-specific "DiffTree" XML file. For example, the organization of information for Personal Auto policies is defined in PADiffTree.XML. For more information on DiffTree XML files and how to configure them, see the Configuration Guide.

Comparing two jobs on the same policy from Cloud API

To compare two jobs on the same policy from Cloud API, use the following endpoint:

POST /policy/v1/policies/{policyId}/compare-jobs

The request body must identify the ids of the jobs to compare. The syntax for the request body is:

{
  "data": {
    "attributes": {
        "job1": {
            "id": "<id-of-first-job>"
        },
        "job2": {
            "id": "<id-of-second-job>"
        }
    }
  }
}

The /compare-jobs endpoint returns a CompareJobAttributes resource. For this endpoint, the resource details the differences that job2 introduces assuming that job1 has been bound.

Structure of the `CompareJobAttributes` resource

The CompareJobAttributes resource has the following structure:

diffTree
- Information about the differences between the selected jobs

The diffTree node in the CompareJobAttributes resource has the same structure as the diffTree node in the JobReviewDiffs resource for the /review-diffs endpoint.

The diffTree section may have information that is LOB-agnostic (such as "Policy Info" or "Line Coverages") and/or information that is LOB-specific (such as "Vehicles").
Every node in the diffTree has a changeType field, which can have one of four values:
- Add - The node defines an entity not present in the policy or the first job that is being added by the second job.
- Remove - The node defines an entity present in the policy or the first job that is being removed by the second job.
- Change - The node defines a field whose value is either in the policy or is being set by the first job and is then being changed by the second job.
- Window - The node defines an entity whose effective window is being changed.
In the base configuration, changes of type Add, Remove, and Change can be made through the user interface and can be done for any type of job. Changes of type Window cannot be made through the user interface (though they can be made through Cloud API), and can only be done for certain types of jobs, such as General Liability and Worker's Compensation.

Example of a `/compare-jobs` response

Suppose you have a personal auto policy with an id of pc:202. It has two vehicles: a Mazda RX-8 and a Buick LaCrosse. Then, you start two policy changes without binding either.

The first policy change (pc:addSienna) adds a new vehicle (a Toyota Sienna).
The second policy change (pc:removeLaCrosse) removes the second existing vehicle (the Buick LaCrosse).

All vehicles are driven by the insured, Ray Newton.

You then make a request to the /compare-jobs endpoint as follows.

POST /policy/v1/policies/pc:202/compare-jobs

{
  "data": {
    "attributes": {
      "job1": {
        "id": "pc:addSienna"
      },
      "job2": {
        "id": "pc:removeLaCrosse"
      }
    }
  }
}

The output defines all changes present either in the policy or the first job that are not present in the second job. This means:

The Mazda Rx-8 and its driver are not referenced. (Neither job affects this vehicle.)
The Buick LaCrosse and its driver will be marked as removed. (The second job is removing this vehicle.)
The Toyota Sienna and its driver will also be marked as removed. (This is added by the first job, but not referenced in the second job. Therefore, from the second job's perspective, this vehicle is not on the policy.)

The following is a snippet of the response:

{
  "data": {
    "attributes": {
      "diffTree": {
        "children": [
          {
            "children": [
              {
                "changeType": "Remove",
                "children": [
                  {
                    "changeType": "Remove",
                    "entity": {
                      "displayName": "Ray Newton",
                      "id": "14"
                    },
                    "label": "Assigned Driver: Ray Newton"
                  }
                ],
                "entity": {
                  "displayName": "2002 Toyota Sienna in California",
                  "id": "22"
                },
                "label": "2002 Toyota Sienna in California"
              },
              {
                "changeType": "Remove",
                "children": [
                  {
                    "changeType": "Remove",
                    "entity": {
                      "displayName": "Ray Newton",
                      "id": "2"
                    },
                    "label": "Assigned Driver: Ray Newton"
                  }
                ],
                "entity": {
                  "displayName": "2005 Buick LaCrosse in California",
                  "id": "2"
                },
                "label": "2005 Buick LaCrosse in California"
              }
            ],
            "label": "Vehicles"
          }
        ],
        "label": "Difference Tree Root"
      },
      "job1": {
        "job": {
          "displayName": "0003903670",
          "id": "pc:addSienna"
        },
        "jobEffectiveDate": "2022-07-21T00:01:00.000Z",
        "jobNumber": "0003903670",
        "jobStatus": {
          "code": "Draft",
          "name": "Draft"
        },
        "jobType": {
          "code": "PolicyChange",
          "name": "Policy Change"
        }
      },
      "job2": {
        "job": {
          "displayName": "0004002589",
          "id": "pc:removeLaCrosse"
        },
        "jobEffectiveDate": "2022-07-21T00:01:00.000Z",
        "jobNumber": "0004002589",
        "jobStatus": {
          "code": "Draft",
          "name": "Draft"
        },
        "jobType": {
          "code": "PolicyChange",
          "name": "Policy Change"
        }
      }
    }
  }
}

Reversing the order of the job IDs

Reversing the order in which the jobs are listed "reverses" the output. Objects that were reflected as added will now be reflected as removed. Objects that were removed will now be added.

For example, suppose you make the following request to the /compare-jobs endpoint. This is the same as the previous request, except the ids have been swapped.

POST /policy/v1/policies/pc:202/compare-jobs

{
  "data": {
    "attributes": {
      "job1": {
        "id": "pc:removeLaCrosse"
      },
      "job2": {
        "id": "pc:addSienna"
      }
    }
  }
}

The output still defines all changes present either in the policy or the first job that are not present in the second job. With the jobs listed in this order:

The Mazda Rx-8 and its driver are not referenced. (Neither job affects this vehicle.)
The Buick LaCrosse and its driver will be marked as added. (The second job (pc:addSienna) is adding this vehicle.)
The Toyota Sienna and its driver will also be marked as added. (This is removed by the first job (pc:removeLaCrosse), but is not referenced in the second job. Therefore, from the second job's perspective, this vehicle is still on the policy.)