Hi everyone, Sorry for the long silence from my end! I just committed the work I've done over August in a big chunk. I should have committed it in smaller increments, but the main reason I refrained was that for much of the time it was in a not-so-functional state. :-( I guess this is a lesson in "release (or commit) early and often."
Anyway, most of what I've done has been to address the shortcomings discussed earlier. First, I've reworked the internal error handling code so that, if there are errors, a new column to the right is created listing the errors on each particular row. For example, if a row has "abc" in its "Deposit" column, it will put "Deposit column could not be understood" in the "Errors" column for that row. Second, fixed-width files are now supported. The interface is actually virtually identical to Gnumeric's, as I merged their code into mine, particularly for the context menu for column merging. Third (and this took much more time than expected), I've implemented a real "Balance" column. I ended up having to rework a lot of my code a few times before I got this right, mainly because of edge cases I failed to consider at first. The idea is that if we get a file that has the following values in the Balance column: $10 $20 $40 $5 we will get transactions with amounts +$10, +$10, +$20, and -$35 -- if we're importing into an empty account (which is probably the most likely use case). However, if there are already transactions in the account, the importer uses that to change the amounts appropriately such that the balances are always correct. For example, if there was a deposit of $20 already in the account that took place between the dates for the first and second transactions in the file, the second transaction's amount will be changed to -$20 (because the balance would be $40 at that point). If there is a deposit or withdrawal column, I will always use that in preference to the balance column, since this is a much more unreliable way to calculate transaction amounts (as it depends entirely on the values for other transactions, both in the file and not). Never the less, it should work as expected for most people (importing into empty accounts). I've also added support for (ignoring) currency symbols in strings, month-day and month-day (i.e. (no year) dates, and the transaction number field. I put "ignoring" in parentheses because I'm not sure if I should be checking to see if the symbols match the commodity in the account (or if we should even be doing currency conversions), but under normal circumstances this should work. There has also been a significant amount restructuring of the code to ease the building of the features above (and future features as well). During the fall, I would like to keep working on the importer, even though I won't be able to work quite as much because of school. The next feature I'd like to implement is actual editing within the dialog of data (so that users don't have to go back and manually edit it in a spreadsheet, save and reimport). I would also like to thank you, Josh and Christian, as well as the rest of the GnuCash community, for all of your help and guidance over the summer! This was definitely a great learning experience in many practical aspects of open source and software development in general. I have really enjoyed working with all of you and hope to continue in the future. Kind regards, Benny _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
