Altru Ideas

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):

1. 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.
2. Process the revenue using the already uploaded file. No constituent data is updated during this step.
3. Export the revenue batch, match the lookup ID's to existing constituents, and do a constituent update batch.
4. 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)