CSV Import Update
warlord at MIT.EDU
Fri Jul 20 12:42:32 EDT 2007
Josh Sled <jsled at asynchronous.org> writes:
> "Benjamin Sperisen" <lasindi at gmail.com> 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
> 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
> 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 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
warlord at MIT.EDU PGP key available
More information about the gnucash-devel