[Kmymoney-devel] KMyMoney - Mutable?

Allan agander93 at gmail.com
Mon Jan 14 17:54:14 UTC 2013


Hi Cristian

On 14/01/13 15:57, Cristian Oneț wrote:
> 2013/1/4 Allan <agander93 at 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.

> - 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







More information about the KMyMoney-devel mailing list