Dear Wm,
On Thu, August 30, 2018 10:10 am, Wm via gnucash-devel wrote:
> On 29/08/2018 23:52, David Cousens wrote:
>
>> I think the decision about whether to import a small number of
>> transactions by hand is really one for the user and not the importer to
>> make. I would import small batches,
On 29/08/2018 23:52, David Cousens wrote:
I think the decision about whether to import a small number of
transactions by hand is really one for the user and not the importer to
make. I would import small batches, maybe 20-30 to test the importer
function and ensure it was working as expected
William,
I have experienced the importer trying to match data out of the range
of dates in the current import. It only occurred from memory when I
first changed over to version 3.0. The matcher appeared to have lost
all memory of what accounts to assign in the changeover form 2.6.
However I found
On 25/08/2018 07:22, David Cousens wrote:
i thank David for his posting which i have read, I don't address all he said
Keep trying. Tthe brain dead importer does get less brain dead with repeated
use.
i'm not sure it does get better as implemented because 2 of the bits of
brain dead-ity are
William
I think the answer to your question lies in the fact that files users wish
to import don't come from a single source and don't always conform to any
well defined standard with regard to both the data format and the
information supplied.
Importing OFX data is considerably more
in case it is appropriate to your import, don't allow it to check every
transaction in your existing file against the one you want to import and
know is unique [1]
[1] who thought that was a good idea anyway ?
redefine your import as a multi=split, then it doesn't seem to do the
zombie
