[GNC-dev] How do I get the "sign" (or side) of the transaction from the account or transaction element in xml?

[Arman Schwarz]

Thanks Geert,

I'm aware of the need to think in terms of debit/credit signs, but my
question was how I could know whether a positive value in the split element
in the XML will increase or decrease the "balance" that the user sees in
gnucash.

This depends on the side of the accounting equation the account is on, e.g.
positive split values increase the balance of an asset account, but
decrease the balance of an income account. Rather than manually maintaining
a mapping of account types and whether the sign is positive or negative, I
was hoping there'd be something in the XML or perhaps in those bindings you
mentioned that would do this for me.

By the way those python bindings are a good suggestion anyway, I'll check
them out.

On Sun, 11 Jul 2021, 9:32 pm Geert Janssens, <geert.gnucash at kobaltwit.be>
wrote:

> Op zondag 11 juli 2021 10:36:40 CEST schreef Arman Schwarz:
> > Hi Frank, I'm not sure how this helps. Are you suggesting that I should
> > change the way the GUI renders the balances? I had hoped to instead just
> > find a way to programmatically know the sign of the balance from looking
> at
> > the XML. If that makes sense.
> >
> Alas, that doesn't make sense in a few ways.
>
> Firstly transactions don't have balances in gnucash, but I guess you mean
> splits. Those have positive or negative quantities and values. Positive
> values
> represent debits, negative ones are credits.
>
> Secondly, if you want to manipulate data directly (which voids your
> waranty by
> the way ;-), you have to think in terms of those credit and debit signs,
> because that's how the data internally is signed. The way it's represented
> in
> the GUI is a matter of taste and influenced by the preferences Frank
> already
> pointed you at.
>
> Our tutorial and concepts guide should give you some information on how
> the
> accounting equation works, which is the basis for the double accounting
> gnucash is implementing. Perhaps that gives you some more insight.
>
> Regards,
>
> Geert
>
> PS
> I quickly looked at your code and notice you have chosen to parse the xml
> data
> file directly outside of gnucash. While you are certainly free to do so,
> do
> know that gnucash development will ignore that completely and you may end
> up
> with unexpected data format changes at random releases (hence the "voided
> warranty" claim earlier on).
> We also provide python bindings. Perhaps those can do what you need as
> well ?
>
>
>