[Kmymoney-devel] KMyMoney - Mutable?

[Cristian Oneț]

2013/1/14 Allan <agander93 at gmail.com>:
> 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.

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

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

Regards,
Cristian

P.S: before proceeding with IBAN I'll issue a query on the user's list
about it's availability