Re: [GNC] [SPAM] Re: Decimal points messed up

[Axel Essbaum]

> On 23 Aug 2019, at 23:10, John Ralls  wrote:
>> On Aug 23, 2019, at 9:01 AM, Axel Essbaum  wrote:
>> Hi All,
>> 
>> Longtime Mac GC user, still running my original 2.4.11 install from… 10 
>> years ago?  I am now looking at upgrading to 3.6 and am encountering a 
>> problem with the "grouping" character and decimal points being transposed.  
>> I am using GC with CHF (I am in Switzerland), but my computer is set up in 
>> English.
>> 
>> In System Prefs > Langauge and Region I have Region = Switzerland.  On that 
>> pane in Advanced I have Number Separator Grouping = ' and decimal = .  
>> Currency is CHF and Currency Grouping = ' and decimal = .
>> 
>> In GC Prefs I have Locale = CHF (Swiss Franc).
>> 
>> But two thousand CHF, which I would expect to see as CHF 2'000.00 is 
>> actually displayed SFr. 2.000,00.
>> 
>> I can live with SFr. but I can't have a decimal point used for grouping.
>> 
>> Anyone have any ideas what I can adjust to fix this?
> 
> The problem is that while Apple's native localization (based on a library 
> called ICU) has the correct numeric and monetary formats for Switzerland, 
> their C runtime library localization files that GnuCash uses have the wrong 
> values for thousands separator and decimal point.
> 
> MacOS won't let you edit the file even with admin privileges (i.e. sudo) and 
> AFAIK no other country uses an apostrophe for the thousands separator so I 
> don't think that there's any way to get the apostrophe thousands separator 
> short of switching to Linux.
> 
> Since you're using GnuCash in English anyway you could just tell defaults
>  defaults write -a Gnucash AppleLocale en_GB.UTF-8
> and it will use comma for the thousands separator and dot for the decimal 
> point. You'll want to change the default currency in Preferences on the 
> Accounts and Reports tabs to CHF instead of locale.

Hi John,

Thanks for the helpful response.  I am happy with a comma separator.  But I get:

$ defaults write -a Gnucash AppleLocale en_GB.UTF-8
2019-08-24 06:54:51.749 defaults[13856:1130038] Unexpected argument 
en_GB.UTF-8; leaving defaults unchanged.

This is Mojave, btw.

Any idea what I need to do different?

Thanks!

- Axel
a...@essbaum.com 

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Mis-presentation of detail lines in balance sheet

[David H]

Peter/Adrian,

If it's the font under Prefs >> Printing >> Checks which is the only one I
can find my Default font is set to "Sans Regular 10" and I don't recall
ever changing it as I don't use cheques.

Cheers Dave H.

On Wed, 21 Aug 2019 at 10:39, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Not sure, I’ve been using custom fonts for years.
>
> Maybe someone else is still using the default and can chime in.
>
> Glad you’ve got it solved though.
>
> Regards,
> Adrien
>
> > On Aug 20, 2019 w34d232, at 7:07 PM, Peter West  wrote:
> >
> > I changed the font (to Palatino) and it came good.  What’s the default
> font when run on a Mac?
> >
> > --
> > Peter West
> > p...@pbw.id.au
> > When the disciples heard this, they were greatly astonished, saying,
> “Who then can be saved?”
>
>
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Decimal points messed up

[John Ralls]

> On Aug 23, 2019, at 9:01 AM, Axel Essbaum  wrote:
> 
> 
> Hi All,
> 
> Longtime Mac GC user, still running my original 2.4.11 install from… 10 years 
> ago?  I am now looking at upgrading to 3.6 and am encountering a problem with 
> the "grouping" character and decimal points being transposed.  I am using GC 
> with CHF (I am in Switzerland), but my computer is set up in English.
> 
> In System Prefs > Langauge and Region I have Region = Switzerland.  On that 
> pane in Advanced I have Number Separator Grouping = ' and decimal = .  
> Currency is CHF and Currency Grouping = ' and decimal = .
> 
> In GC Prefs I have Locale = CHF (Swiss Franc).
> 
> But two thousand CHF, which I would expect to see as CHF 2'000.00 is actually 
> displayed SFr. 2.000,00.
> 
> I can live with SFr. but I can't have a decimal point used for grouping.
> 
> Anyone have any ideas what I can adjust to fix this?

The problem is that while Apple's native localization (based on a library 
called ICU) has the correct numeric and monetary formats for Switzerland, their 
C runtime library localization files that GnuCash uses have the wrong values 
for thousands separator and decimal point.

MacOS won't let you edit the file even with admin privileges (i.e. sudo) and 
AFAIK no other country uses an apostrophe for the thousands separator so I 
don't think that there's any way to get the apostrophe thousands separator 
short of switching to Linux.

Since you're using GnuCash in English anyway you could just tell defaults
  defaults write -a Gnucash AppleLocale en_GB.UTF-8
and it will use comma for the thousands separator and dot for the decimal 
point. You'll want to change the default currency in Preferences on the 
Accounts and Reports tabs to CHF instead of locale.

Regards,
John Ralls

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[david whiting]

I'm also experimenting with ways of using gnucash for a member
organisation, in my case a local football club with 27 teams across
different age groups. We have around 450 current members each year, with a
fair amount of churn (about 100 members leave and 100 new members join each
year as players switch between clubs in the area, or stop playing and new
players start). Each member pays monthly subs so I have a lot of
transactions to deal with.

At the moment I have members as assets accounts, e.g. assets:members:david
and transactions to income:subs. When members pay, ideally directly into
the club current (checking) account, I have the transaction go from the
bank account to the appropriate member account, e.g. assets:current
assets:current account -> assets:members:david. This way the asset:member
accounts show me the transactions for a given member and the income:subs
account shows me how much I (should) have received in subs. If members have
not paid-up then there will be a balance owed in their asset account. You
could have separate income accounts for each destination. So, with the
following accounts:

Assets:members:member1
Assets:members:member2
Assets:members:memberN

Income:destination1
Income:destination2
Income:destinationN

And the following transactions:

Assets:members:member1 -> Income:destination2  $10
Assets:current assets:checking account -> Assets:members:member1 $10

Assets:members:member1 -> Income:destination3  $20

you would be able to see how much each member has contributed (or at least
committed to contributing) to each destination and easily see how much each
member owes. I've created a demo gnucash file to demonstrate this and
uploaded it here:
https://www.dropbox.com/s/ccf3ugufp79miht/membership%20example.gnucash?dl=0
In this example you can see that member 1 has committed to contributing £10
to destination 1 and £20 to destination 2, but has only paid £10 so far, so
owes £20. If you look at income:destinations:destination 1 you can see that
£25 has been committed in total, and so on.

I have no accounting training whatsoever (this is the careful application
of brute force and ignorance) so this could be really bad practice, but it
does seem to me to be transparent and allows me to easily track where the
money is and who I need to chase for subs payments (a significant part of
my life now!).

David





On Fri, 23 Aug 2019 at 18:39, Michael Hendry 
wrote:

> > On 23 Aug 2019, at 14:48, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> >
> > The business features certainly offer some perks with respect to
> reporting, reminders and info lookups.
> >
> > I’d probably take that approach in some fashion if I had to tackle the
> problem myself.
> >
> > However, if the only reason you are considering using them is simply to
> handle multi-dimensional reporting, consider this:
> >
> > The Transaction Report (as well as some other reports) can be filtered
> (with regular expressions, not just with other accounts) and that report in
> particular can have 2 sorting dimensions with sub-totals. One could also
> apply a view filter to an account or run a search and then run an ‘Account
> Report’ from the result.
> >
> > For multi-dimensional issues, I’d solve those by using the ‘Description’
> field as one dimension, and the ’Notes’ and/or ‘Memo’ fields as additional
> dimensions. (the Action fields might also be useful here) This would be in
> addition to the regular ‘Account’ field as the primary dimension.
> >
> > You might even be able to keep all donations in a single account or a
> small handful of accounts, greatly simplifying your CoA and other
> organization reports.
> >
> > Consider booking the donations using the member name as the Description
> and putting the destination in the Notes or other fields. You could also
> track the sources such as ‘Foundation Dinners’ if you’ll have more than
> one, and the need to do so, in any other unused fields.
> >
> > As long as you are consistent in where the information appears, a
> semi-custom filtered report could be achieved.
> >
> > The drawback to regular transactions would be issuing reminders, but
> that could be accomplished by employing a ‘receivables’ type account that
> would be filled with scheduled transactions for each member, and then the
> actual payments would reduce those balances as transfers to some other
> account to accumulate donations YTD. (this would be a second layer of
> transaction info, not the tracking of actual funds moving around) You could
> then run a report based on such accounts.
> >
> > The only drawback to this approach would be if you also needed GnuCash
> to double as a member ‘database’ with address, contact info, etc. In that
> case, making all members ‘customers’ might be the better route because such
> information already has a place to be stored without having to shoe-horn it
> into individual transactions. (but even that would be possible, and
> auto-fill will greatly assist with 

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

> On 23 Aug 2019, at 14:48, Adrien Monteleone  
> wrote:
> 
> The business features certainly offer some perks with respect to reporting, 
> reminders and info lookups.
> 
> I’d probably take that approach in some fashion if I had to tackle the 
> problem myself.
> 
> However, if the only reason you are considering using them is simply to 
> handle multi-dimensional reporting, consider this:
> 
> The Transaction Report (as well as some other reports) can be filtered (with 
> regular expressions, not just with other accounts) and that report in 
> particular can have 2 sorting dimensions with sub-totals. One could also 
> apply a view filter to an account or run a search and then run an ‘Account 
> Report’ from the result.
> 
> For multi-dimensional issues, I’d solve those by using the ‘Description’ 
> field as one dimension, and the ’Notes’ and/or ‘Memo’ fields as additional 
> dimensions. (the Action fields might also be useful here) This would be in 
> addition to the regular ‘Account’ field as the primary dimension.
> 
> You might even be able to keep all donations in a single account or a small 
> handful of accounts, greatly simplifying your CoA and other organization 
> reports.
> 
> Consider booking the donations using the member name as the Description and 
> putting the destination in the Notes or other fields. You could also track 
> the sources such as ‘Foundation Dinners’ if you’ll have more than one, and 
> the need to do so, in any other unused fields.
> 
> As long as you are consistent in where the information appears, a semi-custom 
> filtered report could be achieved.
> 
> The drawback to regular transactions would be issuing reminders, but that 
> could be accomplished by employing a ‘receivables’ type account that would be 
> filled with scheduled transactions for each member, and then the actual 
> payments would reduce those balances as transfers to some other account to 
> accumulate donations YTD. (this would be a second layer of transaction info, 
> not the tracking of actual funds moving around) You could then run a report 
> based on such accounts.
> 
> The only drawback to this approach would be if you also needed GnuCash to 
> double as a member ‘database’ with address, contact info, etc. In that case, 
> making all members ‘customers’ might be the better route because such 
> information already has a place to be stored without having to shoe-horn it 
> into individual transactions. (but even that would be possible, and auto-fill 
> will greatly assist with data entry)
> 
> 
> Regards,
> Adrien

Thanks, Adrien.

Plenty of food for thought there!

I’m not desperately keen on using free text in the Description and Notes fields 
because minor variations in spelling might well cause a transaction to be 
missed, but I can see that this would greatly speed up data entry.

I’ve already set up an Asset account called “Members’ Commitments”, which will 
be populated (e.g.) as members commit to being paying guests at a Foundation 
Dinner, and then reduced to zero once a suitable date has been negotiated, the 
meal eaten and payment received.

I can foresee a lot of revisions going on until I settle down on a workable 
method.

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[GNC] Decimal points messed up

[Axel Essbaum]

Hi All,

Longtime Mac GC user, still running my original 2.4.11 install from… 10 years 
ago?  I am now looking at upgrading to 3.6 and am encountering a problem with 
the "grouping" character and decimal points being transposed.  I am using GC 
with CHF (I am in Switzerland), but my computer is set up in English.

In System Prefs > Langauge and Region I have Region = Switzerland.  On that 
pane in Advanced I have Number Separator Grouping = ' and decimal = .  Currency 
is CHF and Currency Grouping = ' and decimal = .

In GC Prefs I have Locale = CHF (Swiss Franc).

But two thousand CHF, which I would expect to see as CHF 2'000.00 is actually 
displayed SFr. 2.000,00.

I can live with SFr. but I can't have a decimal point used for grouping.

Anyone have any ideas what I can adjust to fix this?

Thanks!

- Axel

--
Axel Essbaum
a...@essbaum.com



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bookkeeping for a club's charity account - use business features?

[Adrien Monteleone]

The business features certainly offer some perks with respect to reporting, 
reminders and info lookups.

I’d probably take that approach in some fashion if I had to tackle the problem 
myself.

However, if the only reason you are considering using them is simply to handle 
multi-dimensional reporting, consider this:

The Transaction Report (as well as some other reports) can be filtered (with 
regular expressions, not just with other accounts) and that report in 
particular can have 2 sorting dimensions with sub-totals. One could also apply 
a view filter to an account or run a search and then run an ‘Account Report’ 
from the result.

For multi-dimensional issues, I’d solve those by using the ‘Description’ field 
as one dimension, and the ’Notes’ and/or ‘Memo’ fields as additional 
dimensions. (the Action fields might also be useful here) This would be in 
addition to the regular ‘Account’ field as the primary dimension.

You might even be able to keep all donations in a single account or a small 
handful of accounts, greatly simplifying your CoA and other organization 
reports.

Consider booking the donations using the member name as the Description and 
putting the destination in the Notes or other fields. You could also track the 
sources such as ‘Foundation Dinners’ if you’ll have more than one, and the need 
to do so, in any other unused fields.

As long as you are consistent in where the information appears, a semi-custom 
filtered report could be achieved.

The drawback to regular transactions would be issuing reminders, but that could 
be accomplished by employing a ‘receivables’ type account that would be filled 
with scheduled transactions for each member, and then the actual payments would 
reduce those balances as transfers to some other account to accumulate 
donations YTD. (this would be a second layer of transaction info, not the 
tracking of actual funds moving around) You could then run a report based on 
such accounts.

The only drawback to this approach would be if you also needed GnuCash to 
double as a member ‘database’ with address, contact info, etc. In that case, 
making all members ‘customers’ might be the better route because such 
information already has a place to be stored without having to shoe-horn it 
into individual transactions. (but even that would be possible, and auto-fill 
will greatly assist with data entry)


Regards,
Adrien


> On Aug 23, 2019 w34d235, at 3:24 AM, Michael Hendry 
>  wrote:
> 
> As previously mentioned on the list, I’ve just become Treasurer of our local 
> Rotary Club, which has two sets of books, one relating to the business of 
> running the club (annual subs, insurance, secretarial support, etc) and the 
> other to the club’s charitable activities.
> 
> The club part is straightforward, and has no need for the business features.
> 
> The charity accounts are different in that although the bulk of the income 
> comes from the general public, some of it is extracted from members with 
> particular charitable destinations in mind.
> 
> For example, the price of the meals at meetings is rounded up to the nearest 
> pound, and the remainder is earmarked for “Charity Choice”. Not all members 
> attend every meeting, and some members skip the meal and make a token payment 
> to Charity Choice. There are several such income headings to deal with.
> 
> The difficulty is that it must be possible to document each individual 
> member’s contributions over the year in order to make a Gift Aid claim to Her 
> Majesty’s Revenue and Customs (HMRC), which tops up the members’ 
> contributions by 25%.
> 
> I have set up a series of accounts of the form:
> 
> Income:Destination1:member1 … Income:Destination1:memberN
> 
> …
> 
> Income:DestinationX:member1 … Income:DestinationX:memberN
> 
> which allows me to report on the total income for each destination easily, 
> but makes it harder to pick out individual members’ contributions.
> 
> Changing the hierarchy to Income:memberN:DestinationnX would make it easy to 
> pick out the Gift Aid detail per member, but harder to report on the total 
> raised for each destination.
> 
> It occurs to me that it might be easier to treat members as customers, who 
> would “purchase” Gift-Aid-Claimable (as well as non-claimable) items. In the 
> case of “Foundation Dinners”, members commit in advance to pay for a meal at 
> another member’s home - this commitment would be equivalent to an order 
> payable on delivery of the goods. I wouldn’t anticipate issuing invoices, but 
> a monthly list of defaulters would allow me to issue gentle reminders.
> 
> It might well be easier to deal with some of these reporting tasks using 
> spreadsheets, but I’d much prefer to have a single point of entry for each 
> transaction.
> 
> It’s been the usual practice for Treasurers to serve for five years, so 
> slow-but-sure is preferable to fast-and-dirty.
> 
> I’d appreciate the advice of the list - especially from anyone with practical 
> 

[GNC] Bookkeeping for a club's charity account - use business features?

[Michael Hendry]

As previously mentioned on the list, I’ve just become Treasurer of our local 
Rotary Club, which has two sets of books, one relating to the business of 
running the club (annual subs, insurance, secretarial support, etc) and the 
other to the club’s charitable activities.

The club part is straightforward, and has no need for the business features.

The charity accounts are different in that although the bulk of the income 
comes from the general public, some of it is extracted from members with 
particular charitable destinations in mind.

For example, the price of the meals at meetings is rounded up to the nearest 
pound, and the remainder is earmarked for “Charity Choice”. Not all members 
attend every meeting, and some members skip the meal and make a token payment 
to Charity Choice. There are several such income headings to deal with.

The difficulty is that it must be possible to document each individual member’s 
contributions over the year in order to make a Gift Aid claim to Her Majesty’s 
Revenue and Customs (HMRC), which tops up the members’ contributions by 25%.

I have set up a series of accounts of the form:

Income:Destination1:member1 … Income:Destination1:memberN

…

Income:DestinationX:member1 … Income:DestinationX:memberN

which allows me to report on the total income for each destination easily, but 
makes it harder to pick out individual members’ contributions.

Changing the hierarchy to Income:memberN:DestinationnX would make it easy to 
pick out the Gift Aid detail per member, but harder to report on the total 
raised for each destination.

It occurs to me that it might be easier to treat members as customers, who 
would “purchase” Gift-Aid-Claimable (as well as non-claimable) items. In the 
case of “Foundation Dinners”, members commit in advance to pay for a meal at 
another member’s home - this commitment would be equivalent to an order payable 
on delivery of the goods. I wouldn’t anticipate issuing invoices, but a monthly 
list of defaulters would allow me to issue gentle reminders.

It might well be easier to deal with some of these reporting tasks using 
spreadsheets, but I’d much prefer to have a single point of entry for each 
transaction.

It’s been the usual practice for Treasurers to serve for five years, so 
slow-but-sure is preferable to fast-and-dirty.

I’d appreciate the advice of the list - especially from anyone with practical 
experience of my situation.

Regards,

Michael

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.