On 15/01/13 12:40, Cristian Oneț wrote:
2013/1/14 Allan <agande...@gmail.com>:
Hi Cristian
On 14/01/13 15:57, Cristian Oneț wrote:
2013/1/4 Allan <agande...@gmail.com>:
I'm in the process of modifying the CSV plugin to behave in a similar way
to
QIF import, in that if it has the account ID, it will avoid the need for
the
user to select an account for the import each time. As it has profiles,
the
account name/ID can be retained.
I've written a very basic account selector for first-run use, and the
account name/ID are saved. Next time, the account ID is available and
mymoneystatementreader.cpp does not need to show its account selector.
Should the user wish to select a different account, he may do so.
However,
what if the user wishes to create a new account? As my new selector is
very
basic, it has no creation capability, but relies instead on
mymoneystatementreader.cpp to do the necessary. So far, so good.
[...]
I would not go this way - tie an account number to a profile because
the following:
That's a shame, as I have it working -well, almost. The checking side was
pretty straight forward, but the investment side was more troublesome,
because two statements may be needed, if there are brokerage transactions.
- a csv profile usually is the serialization of a given csv format
which is kind of the same for a given bank, so how do you intend to
handle the fact that a user has different bank accounts at the same
bank? should he create different profiles?
Unfortunately, that is not the case, at least for me. So, for a particular
bank, I have two profiles, one for checking and one for savings.
Fortunately, I don't use their credit card.
So what would you do if you would have two checking accounts? You
would need to create two profiles (this is just moving the account
selection in the profile selection stage).
Well, now, of course, the account selection dialog would have to be
used. With a pre-arranged account number/IBAN to account relationship,
and with no useful ident. in the file, there would have to be an import
account setting in the profile(s).
- by creating an account selector in the CSV importer you move too
much kmymoney knowledge into the importer; the importer should only
create the standard statement format including the hint into which
account to import and not care about the account hierarchy
- the target account can be identified automatically without
presenting the user with an account selector (which will be presented
anyway later in the import process) using data from the CSV file like
the IBAN or any other account number
Yes, but I was trying to avoid the account selection stage, as is possible
with QIF import.
In spite of what Wikipedia may show, in the UK, at least in my experience,
the IBAN is not generally in use. That is, it does not appear on my
cheques, nor in my CSV files. In fact the full account number may not be in
the file either, but abbreviated, I think for security reasons. That's why
I decided not to follow your lead.
Strange, what do you use to identify an account then? When you issue a
transfer to another bank account what do you use to identify your
account and the destination account?
I'm starting off from the position of having a particular CSV file to
import, and I name each file with some ident plus the date (ESavingsPlus
2009-10-28.csv). Each bank has its own folder for CSV files, so I
'know' where the file needs to go.
Isn't the IBAN for a bank, rather that account? So some additional id
would be required.
Then, there is the more interesting question of investments. A broker
will not have an IBAN anyway, and his statement may cover more than one
investment, quite apart from the statement also including non-security
statements, possibly his fees or added interest not related to a
particular security, and a possible checkbook use, too.
I'm preparing a patch which will store in the profile a given IBAN
format (regexp) using [1] as a source for predefined values in a
selector with the possibility to add a custom format.
That way the work-flow would be the following if the CSV contains the
IBAN (maybe some feedback from others would be appreciated but from
what I saw this field is available):
1. Enter the IBAN in KMyMoney when the account is created
2. When creating a CSV profile select an IBAN format (usually
dependent on the location[country] of the bank account) - predefined
values are available
3. During the import process the IBAN is being extracted from the CSV
using the selected format (regexp)
4. If an IBAN is extracted it is used to identify the account and pass
it as a hint to the statement importer
This has the advantage that the profile can be unique/bank thus
predefined profiles can be provided (which I think should be the goal
- to import without going trough the profile setup UI).
Any thoughts?
Regards,
Cristian
[1] http://www.swift.com/dsp/resources/documents/IBAN_Registry.pdf
_______________________________________________
Anyway, I stop for the time-being and await your developments. Even if
neither an IBAN nor account number is included in the CSV file, a similar
number could be kept in the profile.
Something must be there in the CSV statement to identify the account
otherwise it does not seem very useful to me.
What is in the account varies considerably. My credit card statement
has no headers at all, just three columns. One bank has a header line
with Account : e-Savings_****nnnnn, and I have two different savings
accounts with them, withe their debit/credit column positions reversed
and one having a trailer line, so different profiles. My main bank can
provide a statement per account, or a combined one with the account
numbers in an extra column. So, I have several profiles. Then, of
course, there come the investments. Mine show account name details in
the header. They don't show a ticker symbol, so the account name is
selected from the UI. Brokerage accounts may include a symbol column,
but not every entry may have one.
I think what I'm saying is that the IBAN may not be sufficient, and that
finer detail may need to be obtained, either at profile setup, or from
the file or from the user.
Allan
Regards,
Cristian
P.S: before proceeding with IBAN I'll issue a query on the user's list
about it's availability
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
