copying accounts and transactions from one book to another

[gnucash.133518b at telus.net]

On 2014-05-13 4:56 AM, Mike or Penny Novack wrote:
> I agree that this sort of testing a good idea. I also agree that being
> able to "merge" two books in this way would make the testing easier. But
> please note one point. You are saying "There will be no duplicate
> entries between the two books" but what precisely would be guaranteeing
> that within gnucash? << see the problem? what if there WERE duplicates?
> -- conditions being true only because of "work flow" decisions aren't
> true in a strong enough sense for safe computer programs -- user errors
> do occur >>

I definitely understand the problem, but given a choice between having 
NO means at all to do a merge and the ability to do one with a clear 
warning that manual duplicate resolution may be required, I would opt 
for the latter every time.

> The sort of merge you are requesting NEEDS a component "check for
> duplicates" << refuse to merge if any duplicate are found; but probably
> produce an output listing the duplicate transaction >>

Perhaps I'm missing something here. What constitutes a duplicate? Unless 
some kind of universally unique transaction ID is available for 
comparison, I would have thought it was fundamentally impossible to 
identify duplicates (although I assume something like this must be 
happening if I import the same QIF twice). Two transactions with 
identical dates, amounts, and involved accounts may still not be 
duplicates, correct? If I'm right then true duplicates will only ever be 
identified through human consideration, so the merge module need not 
consider the problem at all. I could imagine, however, that the merge 
module user might be given an option to prepend a marker to the 
description field of each merged transaction simply to ease her work in 
manually scanning the book looking for possible duplicates.

At this point then, am I to understand that there is simply NO way 
whatsoever that I can achieve a merge, even if I'm willing to put up 
with a circuitous set of steps to get there? In this particular case 
there would be so much data to enter twice that I'm willing to put up 
with a fair bit to avoid that.

Carl