GTI, While I am not addressing the issue you stated in your first post, I do expect an import to consider existing multi-split transactions that match the amount and timing of a single line imported transaction in the base account. A very common case would be to match an existing payroll transaction to an incoming bank account import. Of course a lot of similar date and amount transactions are not matches. Matching splits in more than one account during an import that is based on one account at a time would be very complex to execute. I am not sure what your previous bug report addressed, as you did not give the report number.
One of your posts states that the new GnuCash CSV importer does correctly import single line transactions but you said originally that is the structure of the transaction that it does not correctly import. I guess I am missing something. David C On Thu, Nov 22, 2018 at 9:29 PM GTI .H <gti90...@gmail.com> wrote: > Thanks for the answers! > > Em qui, 22 de nov de 2018 às 19:14, David Cousens < > davidcous...@bigpond.com> > escreveu: > > > GTI , > > > > Don't know how to do it but perhaps the easiest way to find out is to > > export > > the record of a similar transaction from Gnucash in the default GnuCash > > Export Format and then examine the exported structure. You can use the > > default Export Format for importing GnuCash records. > > > > David Cousens > > > > Yes, I had already checked the CSV structure exported before attempting the > import. > > So . . . > Gnucash always exports Multi-line transactions and can import Multi-line or > Single-Line transactions like the template transaction in my first post. > Turning single-line transactions into multi-line requires extensive extra > processing because I have a ton of transactions. > > Em qui, 22 de nov de 2018 às 21:09, David Carlson < > david.carlson....@gmail.com> escreveu: > > > I have not used the new CSV importer, so I am not sure whether this > comment > > actually applies to your case... > > > > If the new CSV importer is used similarly to the old CSV importer, there > is > > a step in the process to offer an opportunity to match the new > transaction > > to existing transactions if there are candidates to consider. At this > step > > the importer may be offering a match to an existing multi-split > > transaction. If you do not correct it and declare the incoming > transaction > > to be new, that may cause your issue. > > > > David C > > > Long ago I opened a bug report with a similar issue to this one. > > On importer process, first we need to do the Accounts Mappings, then if > there is an unbalance, we must choose accounts to do the balancing. > > In this topic's case here, there are no existing transactions to consider, > these are new and non-existent transactions, there are no existing > transactions to match. > > Note that the template transaction in my first post has no way to be > unbalanced (splitted transaction). > > Regards > GTI > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
