Hi Cristian
On 14/01/13 15:57, Cristian Oneț wrote:
2013/1/4 Allan <[email protected]>:
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.
- 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.
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.
Allan
_______________________________________________
KMyMoney-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kmymoney-devel
