GnuCash XML sched-xaction split amount formatting

Thu Apr 30 11:00:04 EDT 2015

Ngewi Fet <ngewif at gmail.com> writes:

> On Wed, Apr 29, 2015 at 4:40 PM, Derek Atkins <warlord at mit.edu> wrote:
>
>     Ngewi Fet <ngewif at gmail.com> writes:
>    
>     > Hi Geert,
>     > Thanks for that info. That puts us in a tight spot. Now GncA could
>     either:
>     > - skip scheduled transactions completely (not desirable)
>    
>     Why is this not desireable?
>
> Well, because we also backup scheduled transactions from the app in the same
> format. 
> We want to be able to at least read those back. Wherever possible, we try to
> maintain compatibilty between our XML .gnca files and .gnucash files unless
> when unavoidable. (We do have a few extra slots in there which GnuCash desktop
> happily ignores).

The nice feature of the XML slots is that you don't have to parse them
in order to store and save them.  They all get read in and then
automatically written back out.  The app does not need to know anything
about a slot entry, by default it is ignored (but the data is never
lost).

Your app should treat the SX slot data the same way.

>     > One solution that comes to mind though, if I could reliably know how many
>     > decimal places are included in the amount, then I can parse it
>     irrespective
>     > of the separator.
>     > Does GnuCash always use 2 decimal places, or does this depend on the
>     > currency, or something else?
>    
>     I think it depends on the currency.
>
> At the moment, what I've implemented is to parse the string and find the last
> non-numeric character. If the number of digits after that character are 2 or
> less, then I assume it is a decimal place and treat the digits as such. If the
> number of digits are more, then I assume it is a thousands separator. If the
> string has only digits, then I just treat it as a number.
> This way I think we can parse most of the amounts regardless of what decimal
> separator is in use.

I think this algorithm will fail in many cases (e.g. stock/fund
transactions).  Those might have > 2 decimal places.

You might be safer checking the SCU of the template account commodity.

>     > But then that also leaves the issue of GnuCash choking on XML files
>     > exported by GncA because we cannot predict what locale the user will be
>     > using.
>     > Best guess will be to use the mobile device locale and hope that the user
>     > has the same setting on the desktop!
>    
>     I suspect this is a *reasonable* assumption, but of course it wont work
>     always.
>
> Yes it won't always work. In the future we may have a setting for the user to
> specify their locale and we can use that as well. (Some users currently would
> like to use the app in a language other than the system locale). 
>
>     Perhaps you should just ignore SXes completely?  The data is stored in a
>     KVP, so just treat as the string it is.  You wont lose data, you just
>     wont *use* it.
>
> For reasons mentioned before, and we do generate transactions from the
> scheduled actions. So it will be necessary to be able to parse the amount. 

Oh, I didn't realize you were attempting to process the SXes in the
Android app!!  That changes things; I just assumed you wanted to make
sure you could read the GnuCash XML data and then re-write it back out
again.

*ponders*

Too bad you can't just incorporate the GnuCash engine (and file backend)
C code directly into your App.  ;)

> Cheers,
> Ngewi 

-derek

>     > On Wed, Apr 29, 2015 at 12:42 PM, Geert Janssens <
>     geert.gnucash at kobaltwit.be
>     >> wrote:
>     >
>     >>  On Wednesday 29 April 2015 11:35:42 Ngewi Fet wrote:
>     >>
>     >> > Hello,
>     >>
>     >> > In GnuCash XML, scheduled transaction splits do not have the
>     >>
>     >> > <split:value/> and <split:quantities/> set. Rather the amount is
>     >>
>     >> > stored as a slot with key <sched-xaction>.
>     >>
>     >> >
>     >>
>     >> > I would like to know if the formatting of this amount is (device or
>     >>
>     >> > gnucash) locale-specific, or uniform across all GnuCash instances.
>     >>
>     >> >
>     >>
>     >> > For me, it is formatted as , e.g. 200,00 or 2.500,00
>     >>
>     >> > Note the comma for decimal separator and period for thousands
>     >>
>     >> > separator (which would be correct for my device locale but incorrect
>     >>
>     >> > for my GnuCash locale which is en_US).
>     >>
>     >> > The formatting doesn't seem to change when I modify the GnuCash
>     >>
>     >> > locale.
>     >>
>     >> >
>     >>
>     >> > Can anyone shed some light on the formatting of the split amounts of
>     >>
>     >> > scheduled transactions?
>     >>
>     >> > It would help when parsing GnuCash XML files in GnuCash Android.
>     >>
>     >> > Thanks.
>     >>
>     >> >
>     >>
>     >> > Regards,
>     >>
>     >> > Ngewi F.
>     >>
>     >> > _______________________________________________
>     >>
>     >> > gnucash-devel mailing list
>     >>
>     >> > gnucash-devel at gnucash.org
>     >>
>     >> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>     >>
>     >>
>     >>
>     >> Hi Ngewi,
>     >>
>     >>
>     >>
>     >> Unfortunately you hit one of GnuCash's dark corners here. The SX amount
>     >> formula is stored in gnucash in the locale that is active at that time.
>     >> This has been a poor design decision (more like on oversight probably)
>     at
>     >> the time.
>     >>
>     >>
>     >>
>     >> It gets worse if you change locales afterwards because gnucash doesn't
>     >> store the locale information itself with the formula and hence can't
>     >> convert the stored formulas to the new locale, resulting in errors when
>     >> these formulas have to be parsed.
>     >>
>     >>
>     >>
>     >> This has been reported as a bug [1] which hasn't been fixed yet so far.
>     >>
>     >>
>     >>
>     >> I'm not sure what you can do on the gnucash-on-android side to properly
>     >> handle this if gnucash itself even doesn't.
>     >>
>     >>
>     >>
>     >> Geert
>     >>
>     >>
>     >>
>     >> [1] https://bugzilla.gnome.org/show_bug.cgi?id=370331
>     >>
>     > _______________________________________________
>     > gnucash-devel mailing list
>     > gnucash-devel at gnucash.org
>     > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>     >
>     >
>    
>     --
>            Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>            Member, MIT Student Information Processing Board  (SIPB)
>            URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>            warlord at MIT.EDU                        PGP key available
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available