GnuCash XML sched-xaction split amount formatting

[Ngewi Fet]

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


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


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

Cheers,
Ngewi


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