Double entries: suggestions
LegacyUser
✭✭✭✭
Peter Heiniger said: Double entries: suggestions
1. A wife has a spouse and children on the left, but not on the right. Leave this field blank on the right.
2. A wife has parents on both sides. Bring these to the same height.
3. Identify her siblings as such and not as children, even though she is then also named as sibling.
4. Omit the parents of the siblings. They are already mentioned above. If there are half siblings, the parents have to be named again anyway and their children are listed below them.
5. Bring the siblings with identical information on the left and right at the same height, otherwise leave the space on the left or right empty.
1. A wife has a spouse and children on the left, but not on the right. Leave this field blank on the right.
2. A wife has parents on both sides. Bring these to the same height.
3. Identify her siblings as such and not as children, even though she is then also named as sibling.
4. Omit the parents of the siblings. They are already mentioned above. If there are half siblings, the parents have to be named again anyway and their children are listed below them.
5. Bring the siblings with identical information on the left and right at the same height, otherwise leave the space on the left or right empty.
Tagged:
0
Comments
-
Paul said: Regardless of the precise solution, your screenshot in an excellent illustration of why the developers need to carry out some adjustments to this feature. It's going to take a pretty conscientious and patient user to have the willingness to line everything up (in their mind's eye!) before proceeding in evaluating how well the possible duplicate matches the other record.
My worry is that many users will NOT be willing to take the necessary time over such examples and either not bother with continuing with the process / mark as "not a match" OR go the "other way" and decide, "Yeah, looks about right" and merge the IDs without a proper analysis of the data.
Probably little danger of experienced users messing up here, but under the previous method (and probably this) it was/is the many INnexperienced FT users who make incorrect merges, unless everything is laid out very clearly.
Sorry, but no point in having a (potentially) excellent enhancement to the old process if it is still going to have bits that can cause such confusion.0 -
Don M Thomas said: You will always have confusion in merging. Your "(potentially) excellent enhancement" merging, IS THE SAME, as the old merging process. I take that back, at least under the old merging process I was not forced to do something.0
This discussion has been closed.