TCN checks during overlay from Z39.50 can block valid overlay

[Galen Charlton]

If the "Cat: Use Internal ID for TCN Value" global flag is enabled, if you use the Z39.50 search to overlay an existing record with a new one from a Z39.50 target, the value of the incoming 001 field can block the overlay for no good reason.

Specifically, if the 001 field happens to be numeric and happens to match the ID of a non-deleted record in the database, the import will fail with a TCN_EXISTS event. In particular, open-ils.cat.biblio.record.marc.replace will consider the 001 to be the incoming record's TCN.

This is problematic on several levels:

- It ignores the cataloger's judgment for no apparent reason. By the point of the overlay, the cataloger will have both chosen the record to be overlaid and have had an opportunity to compare the incoming record and the record to be overlaid side-by-side.
- If the bib ID is being used to set the TCN value, the 001 of the incoming record should _not_ matter in a situation where the overlay target has been set manually.

Short of an overhaul of the whole TCN system, I think it would be advisable for open-ils.cat.biblio.record.marc.replace and friends to not try TCN checks at all when the global flag is enabled.

Evergreen 3.early+

[Galen Charlton (gmc)]

Noting that a workaround is to edit the incoming record to remove the 001 field before committing to the overlay.

This can also be done by creating and select a merge profile that removes the 001 field.