GTI, >No. I have in my register a ton of one-line two-currency transactions even >though the register allow them to be displayed on 4 lines pressing the >split button: 1 Description, 2 involved currencies, 1 in white. > >In my humble understanding, splitted transactions are transactions where a >value is transferred to two or more destinations because the possible logic >for this is split. >Two-currencies transactions does not allow the logic for splits = Division >by 1 (if you prefer).
David Carlson's description is actually more correct in accounting terms and the way GnuCash actually works. This is a double entry accounting system which means that all transactions have at least two splits. In the case of a currency conversion transaction, the transfer of asset value is between the account in the initial currency and a separate account in the final currency, so there is at least a split for each account. (If there are currency conversion fees involved that are not incorporated in the price/currency conversion information for example you could have additional splits to account for this.) Each of the two (or more) "splits" which constitutes the transaction only affects the account to which it refers. The data structures internal to GnuCash maintain a separate data structure for each component of the split which has a pointer to the transaction it belongs to and the transaction data structure maintain pointers to all the splits which constitute that transaction. For convenience and compactness, in the register display, this is normally (depending on optional choices in the preferences for the register display) compacted to a single line display which can be expanded to show the full structure of the transaction. That expanded structure is more representative of the way a transaction is represented internally inside GnuCash. As you noted GnuCash's default export format is multiline but it can also export in single line format if you check the SImple Layout box in the first page of the wizard but this can cause a loss of information compared to the multiline format. There is currently a problem with importing data with a currency exchange even with the multilline format, which I will be reporting as a separate bug. In essence for importing a currency exchange between an AUD and a USD account for $100AUD to $110 USD, the importer creates the trnsaction correctly in the AUD asset account and the USD asset account but it also creates an Imbalance account transaction for $1000, which it should not. To correct this requires deletion of the Imbalance account transaction which is incorrectly created on import, The single line format data cannot be imported correctly at all at the moment as Geert indicated in his reply. The single line exported data has a separate column for the base account for the transaction and a separate column for the transfer account but in the importer as it is coded at the moment there is no facility to associate a transfer account to this column. Geert also indicated that the main developer effort is currently directed to other areas. I have had a little bit of experience with some parts of the importer code although not that associated with currency/commodities to data so far. I will try have a look at the code area to see if I can isolate at least the above problem with the multiline import which is in the import-matcher I have previously looked at and fix that. I may learn enogh to start looking at the single line import problems, but that will certainly take longer. David Cousens ----- David Cousens -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html _______________________________________________ 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.
