CSV Import Update

[Derek Atkins]

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
>> (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
       warlord at MIT.EDU                        PGP key available