Hi all,
I'm new to an organisation where it seems a lot of duplicate records were created during the V11 upgrade, mostly teachers affiliated to school records, i.e. EXACT matching records.
Strangely, they aren't being picked up as potential duplicates in the constituent merge utility. The values in Duplicate Matching in T_DEFAULTS are: fname=1,lname=20,postal_code=3,street1=10.
Creating an auto-merge script is definitely on the horizon but if anyone is privy to this issue, I'd love to hear from you, thanks!
Hi Kevin,
A teacher record and a school record would never be matched as a duplicate, nor could they be merged, because they are in different constituent categories. A school record is an organization record and a teacher record is an individual record. And even if right now the only data on the teacher record is the school’s address, the intention is that you have a separate record for the teacher and the school so they can be tracked separately. In v12, this will allow you to set the school as the owner of group orders, for example, and also record the teacher as the initiator so that the order shows on both records. Then if the teacher later leaves the school, you don’t lose the record of the groups she brought from that school. Also you can start to collect more personalized data about the teacher, and have multiple teachers linked to the same school.
Kevin Sheehan
Senior Technical Writer & Consultant
Tessitura Network
+1 888 643 5778 x 329
ksheehan@tessituranetwork.com
Sorry I wasn't clear at first - there are duplicate *teacher* records affiliated to the same school so for example:
#123456 John Doe 1 Sydney Street SYDNEY 2000
#987654 John Doe 1 Sydney Street SYDNEY 2000
are both affiliated to the same school record.
They have exact matching addresses and are of same constituent type (individual).
Kevin,
You may want to check your parameters for the AP_IDENTIFY_DUPLICATES procedure as the parameters have changed from v10 to v11. In addition, you may want to look specifically at the changed_since_days parameter against the last_activity_dt or create_dt on the constituents you listed. If null, the procedure only looks at constituents changed since the last identify procedure has been run, or the last merge, and if specified only constituents that have changed in the time specified will be considered in the identification process.
Best,
Anna
Thanks, Anna, I've since discovered that the records' last_activity_dt have null values causing the issue.
Cheers,
Kevin