Merging

Rattail ostensibly supports merging any 2 records, of any kind. But the devil is always in the details…

In most cases a merge involves:

• inspect differences between 2 records

• choose which one to “keep” vs. “remove”

• perform the merge, which:

• may update the “keep” record, with certain data from the “remove” record

• then deletes the “remove” record

For some things this can be pretty straightforward, for instance if your User records are maintained only in Rattail and aren’t imported from elsewhere, then a merge of 2 User records could by definition only affect Rattail anyway.

Although even that example can be tricky, because a User is often involved in some audit trail(s) of various other data records. In such cases Rattail can update the historical records to reflect the new “keep” User record; but in practice there may be edge cases as yet unexplored.

Customer and Employee records etc. can present more of a challenge, because often that data lives in multiple systems. The question becomes, what should a merge actually do, i.e. what should the ideal outcome be?

In particular your POS may have 2 customer records which you’d like to merge, but even if your ideal outcome is for one of them to be deleted (i.e. typical use case described above), the problem of historical data may come up again. Often times both of the customer records will already have accrued some transaction history within your POS, and it may not be possible or practical to correct those with the new (“keep”) customer reference.

But the merge tool is meant to be as flexible as is reasonable. Your merge logic might be able to go ahead with certain “simple” merges but then raise an error when complex situations are encountered. Then you can look more closely at those and see what can be done (if anything).