Josh Sled <[EMAIL PROTECTED]> writes: > "Benjamin Sperisen" <[EMAIL PROTECTED]> writes: >> What can the importer do now? >> 4. It can handle three different column types: Amount, Date, and >> Description. The columns can be in any order. > > Other columns you may want to support: > > - transaction number > - transaction identifier > - comment > > It might be that the easiest thing to do is just concatenate some of those > fields together into the memo of the resultant transaction, rather than try > to get a 1-to-1 mapping to gnucash fields.
Maybe provide a few options for how to translate these columns? I could surely see one mapping into the "Num" column. Maybe one tying into the "Action", and then there's the Transaction Notes field and the individual Split Memo fields. >> 5. This is not necessarily a CSV import issue, but the date parsing >> function does not yet take into account the issue raised by Thomas >> (https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020954.html). > > I'm not sure if the mixed-separator issue is significant outside of QIF > files, or otherwise wide-spread. I'd agree that we shouldn't worry about this now. We can do other "magic" to figure out the year, even just hardcoding (for now) 1969-2060 and then worrying about it again in another 50 years. If your code is still here in 50 years then I'll be extremely impressed! > I did notice that converting the "txt-format" downloads I can get from Bank > of America (which look like `lynx -dump`ed versions of their html, honestly) > into CSV left me with just 'mm/dd' dates (no year). That doesn't seem all > that unreasonable, and should be supported as well. Agreed, it should handle this by assuming either "current year" or "+/- 6 months" depending on a preference (IMHO). >> Problem 4 will largely take time, but if anyone has any CSV files that >> they'd like to try this with, feel free -- the code should be stable >> enough that it's not totally unusable at this point. As long as you > > Another thing I noticed with my manufactured CSV file was that some of the > lines had '$'s before the value, and some had column-based credit/debit value > distinctions; I could imagine other CSV-providers that used +/- for such a > distinction. This might end up as an RFE building on this project, but > handling these cases seems pretty important. Yes, it should accept: <CurrencySymbol> (maybe this can signify a currency, or just be ignored) +/- (explicit positive/negative) (<value>) (explicit negative) >> encountered that before (though I could be wrong). I'll also have to >> learn some about regular expressions, as I know next to nothing about >> them, to add the functionality. > > FWIW, regexp is one of the most useful things I've ever learned, so don't > hesitate! :) Absolutely. I highly recommend you learn regex if it's at all useful to you. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
