[GNC] Any resolution to the 'red flagged' transactions on batch import problem?
Wm Tarr
wm at ilipsis.net
Wed Aug 19 09:07:22 EDT 2026
Have you looked at Tools / Import map editor to see if that provides any
clues ? Possibly zap it all and start again as it is quite possible
whatever you are experiencing is local to you. Try it out on a copy of
your book first, of course.
Wm
On 2026-08-19 09:29, arthur brogard via gnucash-user wrote:
> I have queried this before and back then it was apparently unresolved. Recently I took it to AI and it couldn't come up with anything - and it of course has access to just about everything so I'm thinking it is not resolved.
> However I will ask again just to be sure.
>
> The question:
>
> What causes the 'red flagging' of some transactions in a batch import from .csv that on testing seems to be totally invalid?
> i.e. if you for instance take those red flagged transactions and put them in a batch of their own they will be accepted without demur. 'green flagged'.
>
> I just found/did/experienced an example of it.
>
> A batch of maybe 60 transactions being one bank statement's worth flagged four as red. Numbers 1, 4, 5, 8.
> All transactions totally valide I know for sure because the book is reconciled and updated only statement by statement. So no overlaps. No duplicates.
>
> I took the four and put them at the end of the batch and submitted again. Exactly the same result so the position in the batch has nothing to do with it.
>
> Then I batched them up by themselves in their own csv and submitted it: no problem, all green.
>
> Then I submitted the original on top of that and I got again the same red flagging now that they existed already. (Where AI had assured me that if a transaction already exist it will be 'yellow flagged'.
>
> So I don't know what causes it and I'm not impressed by AI's understanding.
>
> I will mention that I recently imported at least 3000 transactions in a couple or three batches and without one single red flag. Transactions from the same statements, csv's produced by the same software.
>
> I find it very intriguing and am surprised if there is no answer. I'd expect today's debugging software to be capable of quickly showing the problem even if its not so easy to provide a cure or rewrite to remove it, at least find it I'd expect.
>
> Any ideas?
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
More information about the gnucash-user
mailing list