Would the ID (GUID) of a Policy object ever change?
Posted: Tue Oct 30, 2012 4:42 pm
I wasn't sure how to search for any past questions related to this topic since "Policy ID" brings back all kinds of stuff so I apologize for any duplication!
Here's my question: For a Policy object that has been created and been assigned a GUID as its ID field value in the database, is there anything that would ever cause that Policy to get a new ID assigned? Or, does SPS, under the covers, ever transfer the attributes of one Policy to a new one and suppress the old one? In other words, to code looking in via the API would that order's Policy object suddenly seem to have a new ID?
Background
-------------
Here's the deal: We are managing the assignment of virtual jacket numbers to policies with an external system that uses SPS integration to communicate, via a custom package, the underwriter, details of the policy type, all the needed particulars to our external "Virtual Jacket Manager." The VJM then records in its database that an association between a virtual jacket number (taken from a range provided to us by each Underwriter we work with) has been associated with the SPS Policy object with ID {GUID} and conveys to SPS the jacket number which is then used to populate the Policy Number field. The VJM is smart enough that if someone deletes a policy it detects the deletion (by periodically looking to see if the Policy with that GUID is still around) and returns the gently used jacket number back to the pool from whence it initially came. That way some new Policy can fetch it anew. This usually works quite well.
However, we sometimes see where a Policy is losing it's jacket but the Policy is still present--in other words the linkage between the VJM's association record which is via the ID field is saying the ID of the Policy object changed. All the details of the Policy are unchanged but it's as if the GUID got regnerated or that SPS made a clone of the Policy and slipped it in place of the original without anyone knowing.
Here's my question: For a Policy object that has been created and been assigned a GUID as its ID field value in the database, is there anything that would ever cause that Policy to get a new ID assigned? Or, does SPS, under the covers, ever transfer the attributes of one Policy to a new one and suppress the old one? In other words, to code looking in via the API would that order's Policy object suddenly seem to have a new ID?
Background
-------------
Here's the deal: We are managing the assignment of virtual jacket numbers to policies with an external system that uses SPS integration to communicate, via a custom package, the underwriter, details of the policy type, all the needed particulars to our external "Virtual Jacket Manager." The VJM then records in its database that an association between a virtual jacket number (taken from a range provided to us by each Underwriter we work with) has been associated with the SPS Policy object with ID {GUID} and conveys to SPS the jacket number which is then used to populate the Policy Number field. The VJM is smart enough that if someone deletes a policy it detects the deletion (by periodically looking to see if the Policy with that GUID is still around) and returns the gently used jacket number back to the pool from whence it initially came. That way some new Policy can fetch it anew. This usually works quite well.
However, we sometimes see where a Policy is losing it's jacket but the Policy is still present--in other words the linkage between the VJM's association record which is via the ID field is saying the ID of the Policy object changed. All the details of the Policy are unchanged but it's as if the GUID got regnerated or that SPS made a clone of the Policy and slipped it in place of the original without anyone knowing.