Matcher and copier classes must be implemented for all custom effective dated entities. Matching entity instances is an important task in setting up PolicyCenter implementation. When we create a new entity type or extend an existing type, we must consider which matching strategy to implement. We must also test the matcher implementation to confirm that you do not have the following types of matching errors: • Matching two entity instances that actually refer to different items. This error causes PolicyCenter to discard a valid object. • Not matching two entity instances that actually refer to the same item. This error causes PolicyCenter to create an invalid duplicate object. • Matching two objects is straightforward for transactions that are in sequence because we can rely on the ID and, for effective-dated objects, the FixedID properties. Transactions that occur out of sequence require careful consideration.

General guidelines for writing new matchers are described below. • We can match on any property(ies), but using properties backed by database columns is recommended over using virtual properties. • Avoid matching on non-database-backed properties, such as dynamically generated Gosu properties. • Column values must be immutable values that never change over the life of the object. For example, an automobile VIN does not change over time. The only reason for editing a VIN is to correct a data entry error.

Copier classes plays a very important role in Split, Spin, OOS transactions, Future renewals etc. It is required that copiers are defined and all the custom fields are added as part of copiers

See the highlighted section in attached screen shot to understand how to locate the copier and matchers for effdated entities.