Created attachment 373008 [details] Sample transaction CSV Been experimenting with the new /Import Transactions from CSV/, which is neat. Particularly, after creating transactions in Excel Mobile on an iPhone. I've created a multi-split mapping to import Date, Num, Description, Memo, Account, and Deposit. When I import transactions, the first split--whether single Dr/Cr transaction or multiple debits against a single credit--comes in with the reconciliation flag set to 'c'. I have to manually it to 'n'. For expense accounts, it's no biggie, but it is for credit card and bank accounts. I've tried an import with a single transaction, and an import file with multiple transactions and the behaviour is the same across the board. The behaviour is the same on Windows too. The attached sample CSV results in the reconciliation field being set to 'C' for each line entry that includes the date, ie., the first line item in each transaction.
Apologies! Call it sleep deprived! Forgot to sign off, ;-) - Keith PS. I first noticed this issue in v3.2. I've since upgraded to v3.3 but it's still exhibiting the same behaviour.
The importer's presumption is that you're importing the transaction from the financial institution where the account is located, so the split to that account is indeed "cleared", meaning that it's been processed by them. Obviously the presumption is incorrect for your use-case and the associated one of importing QIFs from GnuCash for Android.
I was wondering if that may be the case but thought at the outside it would be different approach because institutional exports would be single line transactions. Consequently I included a "Reconciled" column where each entry was 'n', however, that had no effect. May I assume then that the functionality of the reconciled field is an export status rather than as a control flag to the importer defining the reconcile status of the line item? Is there a means to override the default option? Or, is it assumed the importer will only be run once on creating a new set of accounts?
I don't think there currently is a way to override this behaviour. As John already suggested the import functionality has gradually started to cover more use cases than it was initially designed for. The cleared first line assumption no lnoger holds in all cases. As I see it this will need some review and adjustments in code to get it right.
As a temporary workaround for this, in my local copy, I changed this line https://github.com/Gnucash/gnucash/blob/maint/gnucash/import-export/import-backend.c#L924 to use "NREC" instead of "CREC". File: gnucash/import-export/import-backend.c Function: gnc_import_process_trans_item() case GNCImport_ADD Old line xaccSplitSetReconcile(gnc_import_TransInfo_get_fsplit (trans_info), CREC); New line xaccSplitSetReconcile(gnc_import_TransInfo_get_fsplit (trans_info), NREC);
