I just downloaded this.
First thing I tried was the new importer, as the old one could not import .csv from my bank (ING.nl).
I think it's a big step forward, now that it can deal with datafiles without account fields.
But I'm sorry to say that it is *still* cannot import my bank's datafiles.

What it does right:
- line/field delimiters work, so transactions are identified correctly
- header line (with field names) is ignored
- dates are correct

What goes wrong:
- content of many "payee" fields is ignored

What goes horribly wrong:
- source file has both "transaction type" and "comment" fields. Content of "transaction type" is put into "comment", and actual comment is lost
- even worse: decimals are ignored for "amount": "63,75" is read as "63,00"

I thought this all might result from a text encoding problem, so I changed from 'none' to 'utf8'. This made things worse.
But choosing the wrong encoding should not result in field content being switched around.

I then opened the source file in Excel, and saved to another file (this I DO NOT want to do on a regular basis).
Mmm. Excel thinks CSV uses ";" as separator. There goes the 'standard'...

This gave some improvement: comment and amount fields were now OK, but "Payee" still ignored many values. I believe these contain 'forbidden' values: numbers and/or any of "greater than", "forward slash", "backward slash", maybe others.
"Payee", imho, should be read as text, no exceptions.

"Transaction type" was still set to "Unknown", with one exception. The source file can have two values in this field that iCash does not have. I can understand that these would show up as "Unknown", but ignoring *all* others?

So pulling the source file through Excel resolves the "horribly wrong" partly, and the "wrong" not at all.
What is going on??

[Mac OS X 10.6.3]

Yes. Use the list on the top right to define the fields.
Do you mean the payee field on the op right list is properly lined-up and checked but finally not imported in the Preview when you click on the Preview button?
Are you sure you are lining-up fields properly on the top right list? iCash simply imports the data the way you tell it to do.
Does your iCash decimal settings corresponds to both your system settings and your file settings?
No, encoding only affect accentuated characters.
iCash has a defined list of transaction types, does it match your file? This list is editable. Personally I prefer not to modify it and use the rule editor.
Perhaps it is a problem with your file, is it a real valid CSV? I have seen many banks calling whatever thing a CSV file.

I'm quite sure I did not misalign fields.
I'm also quite sure that these are regular .csv files; fields are separated by comma's, and enclosed in double quotes.

Please assume file format is valid CSV, and fields are aligned correctly. Is there any explanation at all for what I see?
Mixed encoding?
Does the importer validate text fields in any way?

I called my bank, and asked to speak to someone who knows about the format of their data files. I'm awaiting their call, and will post again when I have spoken with them.

I don't have any other explanation. Encoding has nothing to do. Encoding just affects how you see accentuated characters, you would see some junk rather than the right characters. That doesn't affect iCash. The importer doesn't validate the text. Let me know if you have more information.

This one I resolved.
I clicked 'Factory settings" and discovered I had changed this in the past (I started with iCash 5.3 on OSX 10.4. I'm now on 10.6).
Somehow iCash 6 did not think the old list matched the values in my transaction file, although it did match to the human eye. After editing the list from scratch all values were accepted.

I figured this list is kept in the iCash document that is open when you edit it. I'm guessing something did not go well when iCash 6 converted that old document.