[GNC-dev] KVP's

Derek Atkins derek at ihtfp.com
Sat Sep 11 10:04:47 EDT 2021


Hi,

On Sat, September 11, 2021 9:42 am, David Carlson wrote:
> I can imagine that some financial institution will either discontinue or
> just plain break their OFX or csv export, so I think it should be left
> possible for users to mix and match import types for the same account.  I
> myself have seriously considered that for a couple of my accounts, one of
> which is currently reversing the signs on their OFX exports and
> structuring
> their csv exports to always have positive numbers for both debits and
> credits..

Sure, I can see someone switching from one to the other, but what I mean
is I don't see anyone who would import OFX one day, CSV the next, then OFX
the day after, CSV the day after that, etc.  (for ONE account).

-derek

>
> On Sat, Sep 11, 2021 at 7:29 AM Derek Atkins <derek at ihtfp.com> wrote:
>
>> I can't imagine that someone is going to import both OFX and CSV for the
>> same account.  So I think using the account_id is fine.
>>
>> My question would be on backwards-compatibility; if you "modify" the
>> account-id, and then open the data file in an older version of gnucash,
>> what will happen if you try to import into that account?  Most likely it
>> would not auto-find the account (because the account-id wouldn't match),
>> and would overwrite the over-loaded KVP.
>>
>> So I think it would be better to have a new KVP under the account.
>>
>> -derek
>>
>> On Sat, September 11, 2021 4:55 am, Chris Good wrote:
>> > Hi Geert,
>> >
>> > I haven't yet figured out how not to affect the CSV and aqbanking
>> imports
>> > but it's on my list to do.
>> > Maybe this would be useful for those too but I cannot test aqbanking.
>> >
>> > Regards, Chris
>> >
>> > On Sat, 11 Sep 2021, 6:47 pm Geert Janssens,
>> <geert.gnucash at kobaltwit.be
>> >
>> > wrote:
>> >
>> >> Upon re-reading in more detail I find it is exactly your idea to make
>> it
>> >> depend on the account-id. I am not sure how this interacts with the
>> csv
>> >> importer. So perhaps all of my reservations are moot.
>> >>
>> >> Regards,
>> >>
>> >> Geert
>> >>
>> >> Op zaterdag 11 september 2021 10:44:18 CEST schreef Geert Janssens:
>> >> > Hi Chris,
>> >> >
>> >> > I haven't followed the original issue discussion in detail so I can
>> >> only
>> >> add
>> >> > some generic considerations.
>> >> >
>> >> > The generic import transaction matcher is used by both the OFX and
>> the
>> >> csv
>> >> > importer (and perhaps even by the aqbanking one as well). So your
>> >> option
>> >> > would affect all of these.
>> >> >
>> >> > Saving this value just like that would mean it will define
>> behaviour
>> >> of
>> >> all
>> >> > two or three importers at once. Imagine a user imports in three
>> >> different
>> >> > formats depending on the bank to import from, would it then be
>> >> desirable
>> >> to
>> >> > have this option set for all different banks ? Or would it be more
>> >> desirable
>> >> > to have it apply only to specific bank accounts ? The latter could
>> >> even
>> >> be
>> >> > the case if a user imports ofx data from two different banks.
>> Perhaps
>> >> only
>> >> > for one bank you'd want this override and not for the other ?
>> >> >
>> >> > In other words my concern is that making it a single book level
>> option
>> >> may
>> >> > be too generic and while it would reduce effort in the use case you
>> >> have
>> >> in
>> >> > mind it may increase effort in other scenarios.
>> >> >
>> >> > Regards,
>> >> >
>> >> > Geert
>> >> >
>> >> > Op zaterdag 11 september 2021 10:22:07 CEST schreef Chris Good:
>> >> > > Hi,
>> >> > >
>> >> > >
>> >> > >
>> >> > > I'm working on adding an "Append" checkbox to the bottom of the
>> >> "Generic
>> >> > > import transaction matcher" so that when Update+Clear'ing
>> >> > >
>> >> > > a matched transaction, the imported Trans->Desc and Trans->Notes
>> can
>> >> be
>> >> > > optionally appended to the matched transaction Desc/Notes
>> >> > >
>> >> > > instead of overriding them.
>> >> > >
>> >> > >
>> >> > >
>> >> > > I'd like to store the value of the checkbox (True or False) for
>> the
>> >> > > imported account so that in the next import, it will default to
>> the
>> >> same
>> >> > > value.
>> >> > >
>> >> > >
>> >> > >
>> >> > > I'm thinking this should be a KVP, either:
>> >> > >
>> >> > > 1.  A New slot under the account or
>> >> > > 2.  Add a pipe symbol and the True or False value to the end of
>> the
>> >> > > account "online_id" slot
>> >> > >
>> >> > >
>> >> > >
>> >> > > I assume a new slot would be backwards compatible with older
>> >> versions
>> >> of
>> >> > > GnuCash as they would just be ignored.
>> >> > >
>> >> > >
>> >> > >
>> >> > > Is a new slot the way to go? Any hints on how to do this please?
>> >> > >
>> >> > >
>> >> > >
>> >> > > Regards,
>> >> > >
>> >> > > Chris Good
>> >> > >
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > gnucash-devel mailing list
>> >> > > gnucash-devel at gnucash.org
>> >> > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> >> >
>> >> > _______________________________________________
>> >> > gnucash-devel mailing list
>> >> > gnucash-devel at gnucash.org
>> >> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> >>
>> >>
>> >>
>> >>
>> >>
>> > _______________________________________________
>> > gnucash-devel mailing list
>> > gnucash-devel at gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> >
>>
>>
>> --
>>        Derek Atkins                 617-623-3745
>>        derek at ihtfp.com             www.ihtfp.com
>>        Computer and Internet Security Consultant
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
>
> --
> David Carlson
>


-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant



More information about the gnucash-devel mailing list