[GNC-dev] KVP's

[David Carlson]

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

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