Revenue batch imports may incorrectly match constituents. And it's not just "near" matches. For example, here are a few examples of constituents that were incorrectly matched during a batch upload:
- Mary E. Herring -and- Mary K. Herring
- Catherine W. Wolf -and- Catherine L. Wolfgang
- William E. Hodge -and- William Hodges
- Rose M. Brann -and- Rose Brannigan
- Joseph T. Muller -and- Josephine Muller
- Maria D. Valle -and- Marianne Vallejo
- Joan M. Ellis -and- Joanne M. Ellison
- J.Martina Simon -and- J. Simoneau (where J.Martina is the first name)
- Michael Senko -and- Michaeline Senkowski
-
It sort of makes sense that the matching algorithm only looks at first and last name. (Sort of.) So I see why the Mary Herrings were matched. But it seems like a bug that rest were matched when the matching level for batches was set to 100%.
In any case, the way I'm trying to work around this is by breaking the process into four parts (instead of just one revenue batch):
- Imports all data and process any new constituents. Each new constituent gets a unique Alternate Lookup ID in order to be matched back to the data that was uploaded.
- Process the revenue using the already uploaded file. No constituent data is updated during this step.
- Export the revenue batch, match the lookup ID's to existing constituents, and do a constituent update batch.
- Manually add solicit codes for any existing constituents since there doesn't appear to be a way to batch update solicit codes if the constituent is already in the system.
This really shouldn't be so hard.
One option I thought of was to upload everyone as a new constituent and rely on the duplicate constituent process to merge any 100% matches. I believe that algorithm uses more than just name. But it would be nice if the Revenue import just worked the way it seems it should.
For more info, see:
- Case 13959597 (preventing near-matches in batch uploads)
- Case 13959109 (preventing near matches in batch uploads)
