Re: [GNC] File Format Documentation (Bug 777893)

[David T. via gnucash-user]

Stephen,


> On Aug 14, 2018, at 4:50 PM, Stephen M. Butler  wrote:
> 
> On 08/14/2018 04:24 PM, David T. wrote:
>> Steve,
>> 
>> Thanks for your input. I believe we’re in agreement here; I wasn’t trying to 
>> suggest that GC become a DBMS, but rather it would learn to utilize DBMS 
>> features that many seem to expect.
>> 
>> I’m not great with the appropriate terminology to use. Do you have language 
>> I could use that would more accurately reflect the direction that GC is 
>> headed?
>> 
>> David
> 
> I hoped as much.  Let's take this pair of sentences:
> 
> Use of SQL formats for storage implies to many that GnuCash is database 
> management software (DBMS). While that is a long term goal of the development 
> team, GnuCash as currently designed is not DBMS.
> 
> And change them to this:
> 
> Use of a SQL back-end engine for storage implies to many that GnuCash
> has fully implemented DBMS features including multi-user and incremental
> data manipulation.  That is a long-term goal of the development team. 
> However GnuCash does not currently implement these features.
> 

This is great; I will use it.

> Then I think this next section can disappear entirely:
> 
> Many features that users of DBMS expect from a DBMS are not implemented in 
> GnuCash. The GnuCash data schema is not normalized. Significant elements of 
> the data logic is implemented in code, rather than data structure.
> Gnucash uses the SQL back end to load the entire data store into memory in 
> the same manner as the XML back end. Consequently, use of the SQL back end 
> does not enable simultaneous multi-user access to a GnuCash file, although 
> that is one long term goal.
> 

I’m not sure I want to remove these comments, as they are issues of 
significance that have come up on the lists over the years. How about this:

The GnuCash data schema is not normalized. Moreover, significant elements of 
the data logic is implemented in code, rather than data structure. Finally, 
Gnucash uses the SQL back end to load the entire data store into memory in the 
same manner as the XML back end. Consequently, use of the SQL back end does not 
enable simultaneous multi-user access to a GnuCash file.

> 
> And I will change this piece:
> 
> One benefit of the SQL back end is that it saves changes incrementally, and 
> every change is committed to the back end as it happens. This is in contrast 
> to the XML back end, which only writes to the data file when the user invokes 
> the Save command.
> 
> To say:
> One benefit of the SQL back end is that it saves changes to the back end as 
> they happen. This is in contrast to the XML back end, which only writes to 
> the data file when the user invokes the Save command. 

How about:
One benefit of the SQL back end is that it commits changes to the file 
immediately. This is in contrast to the XML back end, which only writes to the 
data file when the user invokes the Save command.

The final result for this section is this:
———  
Use of a SQL back-end engine for storage implies to many that GnuCash has fully 
implemented DBMS features including multi-user and incremental data 
manipulation.  That is a long-term goal of the development team. However 
GnuCash does not currently implement these features.
The GnuCash data schema is not normalized. Moreover, significant elements of 
the data logic is implemented in code, rather than data structure. Finally, 
Gnucash uses the SQL back end to load the entire data store into memory in the 
same manner as the XML back end. Consequently, use of the SQL back end does not 
enable simultaneous multi-user access to a GnuCash file.
One benefit of the SQL back end is that it commits changes to the file 
immediately. This is in contrast to the XML back end, which only writes to the 
data file when the user invokes the Save command.
———

Better?
David

> 
> 
> Hope this helps.
> 
> --Steve
> 
>> 
>>> On Aug 14, 2018, at 3:50 PM, Stephen M. Butler  wrote:
>>> 
>>> On 08/14/2018 03:05 PM, David T. via gnucash-user wrote:
 Hello,
 
 In response to Bug 777893 (https://bugs.gnucash.org/show_bug.cgi?id=777893 
 ), I have written a more 
 detailed description of the storage choices available to users for 
 insertion into the Tutorial & Concepts Guide at section 2.5. Given the 
 extent of the text, I am including it here so that the broader community 
 can offer suggestions for improvement. Note that I will insert appropriate 
 encoding once I finalize the content.
 
 Thanks,
 David T.
 
 
 Proposed text for Tutorial & Concepts Guide section 2.5
 
 
 2.5 Storing your financial data
 2.5.1 Overview
 GnuCash offers several formats for storing your financial data. The 
 default file storage format is XML, while a number of flavors of SQL 
 storage are available. Users can choose a file format from 

Re: [GNC] Disconnect between balance on client list and account statement

[Roger Oliver]

Adrien,

A challenge here is that the GnuCash I am using is in Spanish, that is the
accounting terms and reports and in Spanish so I’m guessing at what the
names are in English. I couldn’t figure out which report was the aging
report because of that. The best I can guess is the following:

Previsión de Clientes = Customer overview
Estado de cliente = Customer Report
Calendario de cobros pendientes = Receivable aging

This last may or may not be the receivable aging report. They are not in
the same order on the menu.

I tracked down an open invoice that had not been paid. Somehow in the
switch to GnuCash from Quicken we missed a payment. Posting a payment to a
current asset cash/checking account would have messed up those balances.
Nevertheless, that is what I did by accident.

I moved that payment elsewhere, to an income/returns account so it would
not effect the cash balances. That fixed the balance on the Customer
Overview but left a credit balance on the Customer Report. The calendario
de cobros pendients (Receivable aging?) report shows the customer with the
same credit balance as the Customer Report/Estado de Cliente even though
the Customer overview shows the correct balance.

I had tried this before with the same result. I even tried issuing a credit
note using it to pay the open invoice and got the same result. Either the
Customer Overview shows the correct balance or the Customer Report shows
the correct balance but I can’t get them to match. All the other customers
match. I’m missing something but can’t figure it out for the life of me.

Thanks for the effort,
Roger

Message: 8

Date: Tue, 14 Aug 2018 20:30:31 -0500

From: Adrien Monteleone 

To: Gnucash Users 

Subject: Re: [GNC] Disconnect between balance on client list and account
statement

Message-ID: <91a3e255-86da-47db-92ee-528ec976b...@lusfiber.net>

Content-Type: text/plain; charset=utf-8

I think this is fixable. You should not need to create a new customer
account.

By ?Customer Statement? I?m presuming you mean the ?Customer Report?
correct?

If so, change the dates to reflect the entire time she?s been a customer.
If everything is paid and there are no remaining pre-payments (deposits) it
should balance to zero. You can check for remaining deposits by trying to
Process Payment on her account. If any pre-payment still shows up, then it
has not been applied. (same with any invoices that show up)

Now, run a Reports > Business > Receivable Aging report. It should show she
has a zero balance. If not, double check the options to make sure the ?To?
date matches the end date of the Customer Report. (usually ?Today?) These
numbers *should* match what is shown on the Customer Overview Balance
column.

If when these dates match, you still have non-zero balances, then there are
one or more invoices posted for her that aren?t paid. You?ll have to track
them down. Do an invoice find with her as the customer and check them all
to make sure they are paid. (one possibility is you might have a duplicate
somewhere.)

If the balances are zero when the dates match, but non-zero when you extend
the ?to? past ?today? then you?ve posted a future invoice to her account
and your report option for the Aging Report (and possibly the overview does
this as well) is set to that later date. She might be current ?today? but
based on what is posted, does (or will) owe $1500.

So the end result is there is likely a misapplied payment or not-applied
payment, or a future dated invoice. If you posted and un-posted an invoice,
it is possible the payment was not successfully re-applied and you need to
re-associate it to the proper invoice.

Regards,
Adrien



> On Aug 14, 2018, at 7:38 PM,  
wrote:

>

> I have a customer who ended the last fiscal year (school year) with a zero

> balance owed but still shows owing $1500 in the customer overview but her

> statement shows zero balance. I use the customer overview to manage
overdue

> accounts by sorting according to the balance due. In her case it should be

> zero but isn't. If I give her a credit note the customer overview will
show

> the correct amount but the statement will be off by the same amount. She

> paid ahead last year and I posted the total amount she paid against the

> invoice due at that time leaving a balance in her favor. I paid each

> following invoice with the credit balance. In every other case this works

> perfectly.

>

>

>

> I can't find where the error is or how to correct it.  If I can't figure
out

> how to correct it, one option is to deactivate her customer account
attached

> to last year's invoices and create a new account for her and start all
over

> this year.
___
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 

Re: [GNC] Disconnect between balance on client list and account statement

[Adrien Monteleone]

That is a challenge. I don’t speak Spanish, but those translations via 
translate.google seem to check out, though I’m a little fuzzy on the first two, 
but since the first one has Clientes as plural and that report indeed does 
report on all customers, and the second as Estado does transalate to Report, 
I’d say you’ve identified them correctly. To be sure I’d have to check the 
translation file. (If this is a problem, I’ll dig it out, but I think these are 
correct)

For completeness:

The Customer Overview shows for all customers:

Company Name, Customer Number, Address 1, Address 2, Phone + any additional 
columns you add. (Balance is one of the possibilities)
Nothing in this list is clickable. But you can right-click a customer and 
perform a few maintenance functions as well as run a Customer Report.

The Receivable Aging report shows (by default) only for customers with non-zero 
balances:
Company Name (as a clickable link), Current owed balance, and the balance due 
that is aged 0-30 days, 31-60 days, 61-90 days, 91+days, and the total, along 
with a total line for all customers for each aging period and a grand total. 
The totals for each customer are clickable. That brings you also, to a Customer 
Report.

The Customer Report is a table report one line for each invoice and payment 
with:

Date, Due Date, Reference Number, Type (invoice or payment), Description, 
Debits, Credits, and Amount.

At the bottom there is a Period Totals line, a Total Debit or Total Credit line 
(depending on which it is) and an aging summary which should repeat the info 
from the aging report, but just for this customer. This is what I would refer 
to as a ‘Customer Statement’ but is termed ‘Customer Report’ in GnuCash. In the 
Reports > Business menu, it is probably the first Customer report on the list. 
The ‘Customer Summary’ is something else entirely and is designed to show 
chargebacks from Vendor invoices for particular jobs.

The Customer Report also has a header with the Customer’s address and contact 
info.

-

It is possible when you moved the payment, you needed to re-apply it to the 
proper invoice. If you attempt to ‘Process Payment’ for this customer, do any 
unpaid invoices appear? Do any pre-payments appear? Also, I’m not sure an 
income:returns account was the right account to use. The payment should have 
been received to an asset. The invoice itself was booked against income. 
Processing a payment this way would reduce income erroneously. If this would 
throw off your bank balances, then that real payment is somewhere in the 
history. (otherwise, your account would be short by the amount of the payment) 
Rather than entering it again, you need only assign it as a payment to the 
invoice. (use the right-click menu on the payment transaction - this will be 
similar to ‘Process Payment’)

Also, you mention you experimented with a credit note. Did you zero out and 
unpost the credit note? If you had posted it and applied it as payment to an 
invoice, it might still be applied there and so you aren’t seeing an invoice to 
be paid. I would recommend creating a placeholder customer, say CustomerABC, 
and assign the credit note to this placeholder after you unpost it. Delete all 
lines in the credit note. Zero or blank anything you can that GnuCash will 
allow and enter placeholder info for the rest. Do NOT repost the credit note. 
(it can’t be deleted either, but it can be reused and reassigned later if you 
need one.)

I’d go back over the customer’s history from whatever other records you have 
and walk through each invoice and each payment and make sure they all line up. 
At some point, you’re going to find either a payment in your cash/checking that 
wasn’t assigned as a payment to an invoice, or that the credit note made a mess 
still to be cleaned up, or a duplicate invoice.

Again, be sure your start and end dates on the reports you are comparing are 
identical. (to make sure the same transactions are included in the totals) The 
Customer Overview (presumably Previsión de Clientes) Balance column may or may 
not be correct. I never use it though mine does agree with the Aging Report. If 
the other two reports (Aging Report and Customer Report) agree with each other, 
I’d go with those and not worry about the overview.

Finally, you note that when you moved the payment this resulted in a credit 
balance for the customer. But if the customer is paid up as you noted in the 
first post, their balance should be zero, neither credit nor debit. Really, I’d 
delete that payment entirely, find the actual payment in your asset history, 
and apply *that* transaction as a payment as noted above. IF this payment 
occurred before the opening date of your book, then there’s another solution 
for that.

Regards,
Adrien


> On Aug 14, 2018, at 10:40 PM, Roger Oliver  wrote:
> 
> Adrien,
>  
> A challenge here is that the GnuCash I am using is in Spanish, that is the 
> accounting terms and reports and in 

[GNC] Disconnect between balance on client list and account statement

[rmomxtx]

I have a customer who ended the last fiscal year (school year) with a zero
balance owed but still shows owing $1500 in the customer overview but her
statement shows zero balance. I use the customer overview to manage overdue
accounts by sorting according to the balance due. In her case it should be
zero but isn't. If I give her a credit note the customer overview will show
the correct amount but the statement will be off by the same amount. She
paid ahead last year and I posted the total amount she paid against the
invoice due at that time leaving a balance in her favor. I paid each
following invoice with the credit balance. In every other case this works
perfectly. 

 

I can't find where the error is or how to correct it.  If I can't figure out
how to correct it, one option is to deactivate her customer account attached
to last year's invoices and create a new account for her and start all over
this year.

 

What think ye? 

 

Thanks for the help,

Roger

___
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] File Format Documentation (Bug 777893)

[Stephen M. Butler]

On 08/14/2018 04:24 PM, David T. wrote:
> Steve,
>
> Thanks for your input. I believe we’re in agreement here; I wasn’t trying to 
> suggest that GC become a DBMS, but rather it would learn to utilize DBMS 
> features that many seem to expect.
>
> I’m not great with the appropriate terminology to use. Do you have language I 
> could use that would more accurately reflect the direction that GC is headed?
>
> David

I hoped as much.  Let's take this pair of sentences:

Use of SQL formats for storage implies to many that GnuCash is database 
management software (DBMS). While that is a long term goal of the development 
team, GnuCash as currently designed is not DBMS.

And change them to this:

Use of a SQL back-end engine for storage implies to many that GnuCash
has fully implemented DBMS features including multi-user and incremental
data manipulation.  That is a long-term goal of the development team. 
However GnuCash does not currently implement these features.

Then I think this next section can disappear entirely:

Many features that users of DBMS expect from a DBMS are not implemented in 
GnuCash. The GnuCash data schema is not normalized. Significant elements of the 
data logic is implemented in code, rather than data structure.
Gnucash uses the SQL back end to load the entire data store into memory in the 
same manner as the XML back end. Consequently, use of the SQL back end does not 
enable simultaneous multi-user access to a GnuCash file, although that is one 
long term goal.


And I will change this piece:

One benefit of the SQL back end is that it saves changes incrementally, and 
every change is committed to the back end as it happens. This is in contrast to 
the XML back end, which only writes to the data file when the user invokes the 
Save command.

To say:
One benefit of the SQL back end is that it saves changes to the back end as 
they happen. This is in contrast to the XML back end, which only writes to the 
data file when the user invokes the Save command. 


Hope this helps.

--Steve

>
>> On Aug 14, 2018, at 3:50 PM, Stephen M. Butler  wrote:
>>
>> On 08/14/2018 03:05 PM, David T. via gnucash-user wrote:
>>> Hello,
>>>
>>> In response to Bug 777893 (https://bugs.gnucash.org/show_bug.cgi?id=777893 
>>> ), I have written a more 
>>> detailed description of the storage choices available to users for 
>>> insertion into the Tutorial & Concepts Guide at section 2.5. Given the 
>>> extent of the text, I am including it here so that the broader community 
>>> can offer suggestions for improvement. Note that I will insert appropriate 
>>> encoding once I finalize the content.
>>>
>>> Thanks,
>>> David T.
>>>
>>> 
>>> Proposed text for Tutorial & Concepts Guide section 2.5
>>> 
>>>
>>> 2.5 Storing your financial data
>>> 2.5.1 Overview
>>> GnuCash offers several formats for storing your financial data. The default 
>>> file storage format is XML, while a number of flavors of SQL storage are 
>>> available. Users can choose a file format from the File Save and File Save 
>>> As dialogs.
>>> The primary GnuCash storage format is an XML file. The file is by default 
>>> compressed with gzip, which is a preference that is set at 
>>> Edit→Preferences→General→Use file compression. 
>>> GnuCash also supports SQL storage via the DBI back end. It supports 
>>> PostgreSQL, MySQL and SQLite3 databases.
>>>
>>> Storage Comparison
>>> As noted, GnuCash allows storage in either XML or SQL formats. Each of 
>>> these formats has benefits and shortcomings that the user should consider 
>>> for their needs and abilities. 
>>> The XML format is the most stable and established format, and for this 
>>> reason, it is the recommended format for most users. SQL storage was added 
>>> for the 2.4 release and has become an increasingly popular choice for users.
>>> Use of SQL formats for storage implies to many that GnuCash is database 
>>> management software (DBMS). While that is a long term goal of the 
>>> development team, GnuCash as currently designed is not DBMS. It is a 
>>> financial application that can store its data in SQL files.
>> I would strongly suggest that GnuCash never (triple underscore) become a
>> DBMS engine.  I would encourage it to be an application that uses a
>> strong DBMS engine (which it already does) as a back-end and that the
>> team would apply data normalization and multi-user techniques to the
>> front-end application.
>>
>> Note the difference between a front-end application and the back-end
>> DBMS engine.
>> --Steve  (retired Oracle DBA and former application developer)
>>> Many features that users of DBMS expect from a DBMS are not implemented in 
>>> GnuCash. The GnuCash data schema is not normalized. Significant elements of 
>>> the data logic is implemented in code, rather than data structure.
>>> Gnucash uses the SQL back end to load the entire data store into memory in 
>>> the same 

Re: [GNC] File Format Documentation (Bug 777893)

[David T. via gnucash-user]

Steve,

Thanks for your input. I believe we’re in agreement here; I wasn’t trying to 
suggest that GC become a DBMS, but rather it would learn to utilize DBMS 
features that many seem to expect.

I’m not great with the appropriate terminology to use. Do you have language I 
could use that would more accurately reflect the direction that GC is headed?

David

> On Aug 14, 2018, at 3:50 PM, Stephen M. Butler  wrote:
> 
> On 08/14/2018 03:05 PM, David T. via gnucash-user wrote:
>> Hello,
>> 
>> In response to Bug 777893 (https://bugs.gnucash.org/show_bug.cgi?id=777893 
>> ), I have written a more 
>> detailed description of the storage choices available to users for insertion 
>> into the Tutorial & Concepts Guide at section 2.5. Given the extent of the 
>> text, I am including it here so that the broader community can offer 
>> suggestions for improvement. Note that I will insert appropriate encoding 
>> once I finalize the content.
>> 
>> Thanks,
>> David T.
>> 
>> 
>> Proposed text for Tutorial & Concepts Guide section 2.5
>> 
>> 
>> 2.5 Storing your financial data
>> 2.5.1 Overview
>> GnuCash offers several formats for storing your financial data. The default 
>> file storage format is XML, while a number of flavors of SQL storage are 
>> available. Users can choose a file format from the File Save and File Save 
>> As dialogs.
>> The primary GnuCash storage format is an XML file. The file is by default 
>> compressed with gzip, which is a preference that is set at 
>> Edit→Preferences→General→Use file compression. 
>> GnuCash also supports SQL storage via the DBI back end. It supports 
>> PostgreSQL, MySQL and SQLite3 databases.
>> 
>> Storage Comparison
>> As noted, GnuCash allows storage in either XML or SQL formats. Each of these 
>> formats has benefits and shortcomings that the user should consider for 
>> their needs and abilities. 
>> The XML format is the most stable and established format, and for this 
>> reason, it is the recommended format for most users. SQL storage was added 
>> for the 2.4 release and has become an increasingly popular choice for users.
>> Use of SQL formats for storage implies to many that GnuCash is database 
>> management software (DBMS). While that is a long term goal of the 
>> development team, GnuCash as currently designed is not DBMS. It is a 
>> financial application that can store its data in SQL files.
> 
> I would strongly suggest that GnuCash never (triple underscore) become a
> DBMS engine.  I would encourage it to be an application that uses a
> strong DBMS engine (which it already does) as a back-end and that the
> team would apply data normalization and multi-user techniques to the
> front-end application.
> 
> Note the difference between a front-end application and the back-end
> DBMS engine.
> --Steve  (retired Oracle DBA and former application developer)
>> Many features that users of DBMS expect from a DBMS are not implemented in 
>> GnuCash. The GnuCash data schema is not normalized. Significant elements of 
>> the data logic is implemented in code, rather than data structure.
>> Gnucash uses the SQL back end to load the entire data store into memory in 
>> the same manner as the XML back end. Consequently, use of the SQL back end 
>> does not enable simultaneous multi-user access to a GnuCash file, although 
>> that is one long term goal.
>> One benefit of the SQL back end is that it saves changes incrementally, and 
>> every change is committed to the back end as it happens. This is in contrast 
>> to the XML back end, which only writes to the data file when the user 
>> invokes the Save command. 
>> The SQL back end does allow users with SQL experience to write queries 
>> against the data to create custom reports without using Gnucash’s internal 
>> report system. It is important to note that modification of GnuCash data 
>> using external access modes is strongly discouraged by the development team, 
>> and damages to a GnuCash data file that result from such modifications are 
>> strictly the responsibility of the user.
>> 
>> Storage Comparison Table
>> 
>> XML  SQL
>> Default  Optional
>> Requires no additional software  Requires additional software
>> Requires no additional expertise Requires expertise with DBMS 
>> Compressed   Uncompressed
>> Save on command  Save on commit
>> Uses log files   Does not use log files
>> Not multi-user   Not multi-user
>> Limited external processing  External processing through SQL queries
>> 
>> 
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> 

Re: [GNC] File Format Documentation (Bug 777893)

[Stephen M. Butler]

On 08/14/2018 03:05 PM, David T. via gnucash-user wrote:
> Hello,
>
> In response to Bug 777893 (https://bugs.gnucash.org/show_bug.cgi?id=777893 
> ), I have written a more 
> detailed description of the storage choices available to users for insertion 
> into the Tutorial & Concepts Guide at section 2.5. Given the extent of the 
> text, I am including it here so that the broader community can offer 
> suggestions for improvement. Note that I will insert appropriate encoding 
> once I finalize the content.
>
> Thanks,
> David T.
>
> 
> Proposed text for Tutorial & Concepts Guide section 2.5
> 
>
> 2.5 Storing your financial data
> 2.5.1 Overview
> GnuCash offers several formats for storing your financial data. The default 
> file storage format is XML, while a number of flavors of SQL storage are 
> available. Users can choose a file format from the File Save and File Save As 
> dialogs.
> The primary GnuCash storage format is an XML file. The file is by default 
> compressed with gzip, which is a preference that is set at 
> Edit→Preferences→General→Use file compression. 
> GnuCash also supports SQL storage via the DBI back end. It supports 
> PostgreSQL, MySQL and SQLite3 databases.
>
> Storage Comparison
> As noted, GnuCash allows storage in either XML or SQL formats. Each of these 
> formats has benefits and shortcomings that the user should consider for their 
> needs and abilities. 
> The XML format is the most stable and established format, and for this 
> reason, it is the recommended format for most users. SQL storage was added 
> for the 2.4 release and has become an increasingly popular choice for users.
> Use of SQL formats for storage implies to many that GnuCash is database 
> management software (DBMS). While that is a long term goal of the development 
> team, GnuCash as currently designed is not DBMS. It is a financial 
> application that can store its data in SQL files.

I would strongly suggest that GnuCash never (triple underscore) become a
DBMS engine.  I would encourage it to be an application that uses a
strong DBMS engine (which it already does) as a back-end and that the
team would apply data normalization and multi-user techniques to the
front-end application.

Note the difference between a front-end application and the back-end
DBMS engine.
--Steve  (retired Oracle DBA and former application developer)
> Many features that users of DBMS expect from a DBMS are not implemented in 
> GnuCash. The GnuCash data schema is not normalized. Significant elements of 
> the data logic is implemented in code, rather than data structure.
> Gnucash uses the SQL back end to load the entire data store into memory in 
> the same manner as the XML back end. Consequently, use of the SQL back end 
> does not enable simultaneous multi-user access to a GnuCash file, although 
> that is one long term goal.
> One benefit of the SQL back end is that it saves changes incrementally, and 
> every change is committed to the back end as it happens. This is in contrast 
> to the XML back end, which only writes to the data file when the user invokes 
> the Save command. 
> The SQL back end does allow users with SQL experience to write queries 
> against the data to create custom reports without using Gnucash’s internal 
> report system. It is important to note that modification of GnuCash data 
> using external access modes is strongly discouraged by the development team, 
> and damages to a GnuCash data file that result from such modifications are 
> strictly the responsibility of the user.
>
> Storage Comparison Table
>
> XML   SQL
> Default   Optional
> Requires no additional software   Requires additional software
> Requires no additional expertise  Requires expertise with DBMS 
> CompressedUncompressed
> Save on command   Save on commit
> Uses log filesDoes not use log files
> Not multi-userNot multi-user
> Limited external processing   External processing through SQL queries
>
>  
> ___
> 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.


-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

Re: [GNC] File Format Documentation (Bug 777893)

[Adrien Monteleone]

David,

Here are a few things I noticed. They’re really personal preferences, but 
making these changes should help this read a little more clearly.
--


The second sentence of 2.5.1 is superfluous.

> “The default file storage format is XML, while a number of flavors of SQL 
> storage are available.”

You immediately repeat the info with slightly more detail. I’d just leave it 
out.

The first sentence of the Storage Comparison (section number 2.5.2?) is 
repetitive.

> “As noted, GnuCash allows storage in either XML or SQL formats.”


A small correction for ’number’ agreement:

> Significant elements of the data logic ~~is~~ _are_ implemented in code, 
> rather than _the_ data structure.

The last clause “although that is one long term goal” of the following sentence 
is also repetitive:

> Consequently, use of the SQL back end does not enable simultaneous multi-user 
> access to a GnuCash file, although that is one long term goal.


I’d either drop it, and/or edit this earlier sentence:

> Use of SQL formats for storage implies to many that GnuCash is _multi-user_ 
> database management software (DBMS).


Otherwise, this looks very clear and to the point.

Regards,

Adrien

> On Aug 14, 2018, at 5:05 PM, David T. via gnucash-user 
>  wrote:
> 
> Hello,
> 
> In response to Bug 777893 (https://bugs.gnucash.org/show_bug.cgi?id=777893 
> ), I have written a more 
> detailed description of the storage choices available to users for insertion 
> into the Tutorial & Concepts Guide at section 2.5. Given the extent of the 
> text, I am including it here so that the broader community can offer 
> suggestions for improvement. Note that I will insert appropriate encoding 
> once I finalize the content.
> 
> Thanks,
> David T.
> 
> 
> Proposed text for Tutorial & Concepts Guide section 2.5
> 
> 
> 2.5 Storing your financial data
> 2.5.1 Overview
> GnuCash offers several formats for storing your financial data. The default 
> file storage format is XML, while a number of flavors of SQL storage are 
> available. Users can choose a file format from the File Save and File Save As 
> dialogs.
> The primary GnuCash storage format is an XML file. The file is by default 
> compressed with gzip, which is a preference that is set at 
> Edit→Preferences→General→Use file compression. 
> GnuCash also supports SQL storage via the DBI back end. It supports 
> PostgreSQL, MySQL and SQLite3 databases.
> 
> Storage Comparison
> As noted, GnuCash allows storage in either XML or SQL formats. Each of these 
> formats has benefits and shortcomings that the user should consider for their 
> needs and abilities. 
> The XML format is the most stable and established format, and for this 
> reason, it is the recommended format for most users. SQL storage was added 
> for the 2.4 release and has become an increasingly popular choice for users.
> Use of SQL formats for storage implies to many that GnuCash is database 
> management software (DBMS). While that is a long term goal of the development 
> team, GnuCash as currently designed is not DBMS. It is a financial 
> application that can store its data in SQL files.
> Many features that users of DBMS expect from a DBMS are not implemented in 
> GnuCash. The GnuCash data schema is not normalized. Significant elements of 
> the data logic is implemented in code, rather than data structure.
> Gnucash uses the SQL back end to load the entire data store into memory in 
> the same manner as the XML back end. Consequently, use of the SQL back end 
> does not enable simultaneous multi-user access to a GnuCash file, although 
> that is one long term goal.
> One benefit of the SQL back end is that it saves changes incrementally, and 
> every change is committed to the back end as it happens. This is in contrast 
> to the XML back end, which only writes to the data file when the user invokes 
> the Save command. 
> The SQL back end does allow users with SQL experience to write queries 
> against the data to create custom reports without using Gnucash’s internal 
> report system. It is important to note that modification of GnuCash data 
> using external access modes is strongly discouraged by the development team, 
> and damages to a GnuCash data file that result from such modifications are 
> strictly the responsibility of the user.
> 
> Storage Comparison Table
> 
> XML   SQL
> Default   Optional
> Requires no additional software   Requires additional software
> Requires no additional expertise  Requires expertise with DBMS 
> CompressedUncompressed
> Save on command   Save on commit
> Uses log filesDoes not use log files
> Not multi-userNot multi-user
> Limited 

[GNC] File Format Documentation (Bug 777893)

[David T. via gnucash-user]

Hello,

In response to Bug 777893 (https://bugs.gnucash.org/show_bug.cgi?id=777893 
), I have written a more 
detailed description of the storage choices available to users for insertion 
into the Tutorial & Concepts Guide at section 2.5. Given the extent of the 
text, I am including it here so that the broader community can offer 
suggestions for improvement. Note that I will insert appropriate encoding once 
I finalize the content.

Thanks,
David T.


Proposed text for Tutorial & Concepts Guide section 2.5


2.5 Storing your financial data
2.5.1 Overview
GnuCash offers several formats for storing your financial data. The default 
file storage format is XML, while a number of flavors of SQL storage are 
available. Users can choose a file format from the File Save and File Save As 
dialogs.
The primary GnuCash storage format is an XML file. The file is by default 
compressed with gzip, which is a preference that is set at 
Edit→Preferences→General→Use file compression. 
GnuCash also supports SQL storage via the DBI back end. It supports PostgreSQL, 
MySQL and SQLite3 databases.

Storage Comparison
As noted, GnuCash allows storage in either XML or SQL formats. Each of these 
formats has benefits and shortcomings that the user should consider for their 
needs and abilities. 
The XML format is the most stable and established format, and for this reason, 
it is the recommended format for most users. SQL storage was added for the 2.4 
release and has become an increasingly popular choice for users.
Use of SQL formats for storage implies to many that GnuCash is database 
management software (DBMS). While that is a long term goal of the development 
team, GnuCash as currently designed is not DBMS. It is a financial application 
that can store its data in SQL files.
Many features that users of DBMS expect from a DBMS are not implemented in 
GnuCash. The GnuCash data schema is not normalized. Significant elements of the 
data logic is implemented in code, rather than data structure.
Gnucash uses the SQL back end to load the entire data store into memory in the 
same manner as the XML back end. Consequently, use of the SQL back end does not 
enable simultaneous multi-user access to a GnuCash file, although that is one 
long term goal.
One benefit of the SQL back end is that it saves changes incrementally, and 
every change is committed to the back end as it happens. This is in contrast to 
the XML back end, which only writes to the data file when the user invokes the 
Save command. 
The SQL back end does allow users with SQL experience to write queries against 
the data to create custom reports without using Gnucash’s internal report 
system. It is important to note that modification of GnuCash data using 
external access modes is strongly discouraged by the development team, and 
damages to a GnuCash data file that result from such modifications are strictly 
the responsibility of the user.

Storage Comparison Table

XML SQL
Default Optional
Requires no additional software Requires additional software
Requires no additional expertiseRequires expertise with DBMS 
Compressed  Uncompressed
Save on command Save on commit
Uses log files  Does not use log files
Not multi-user  Not multi-user
Limited external processing External processing through SQL queries

 
___
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] Tips & CSS rule for navigating the Budget window with the keyboard

[Adrien Monteleone]

While investigating bug 760194: https://bugs.gnucash.org/show_bug.cgi?id=760194


I figured this out:


With a cell in focus, enter a value. If you want to move right or left, first 
press TAB to set the value, then use left/right arrow keys to move the focus.

If you want to move up or down, simply use the up/down arrow keys after 
entering a value. (you can press TAB if you like, but it isn't necessary)

In both cases, you need to press the spacebar to begin editing a cell.

By default, the outline of the focused cell is very faint and so this process 
is difficult as it is hard to tell if you accidentally pressed TAB too many 
times and changed focus to other parts of the screen. (it seems to cycle to the 
summary bar and then the toolbar and back)

To make the focus outline more visible, add this rule to your custom css file:

.GncBudgetPage #account_tree {
  outline-color: white; /* default = rgba(50,50,50,0.3)
  outline-width: 2px; /* default = 1px
}

Play with these values as desired. You can also change these other default 
settings to your liking:

outline-offset: -3px;
outline-style: dashed;

Note, leaving off the .GncBudgetPage class will make the rule also affect the 
CoA tab since it also uses the #account_tree ID.

I’ve attempted to attach a screenshot below to illustrate the result of the CSS 
rule.

I’ll also take a look at the wiki pages to see if there’s a good place to put 
this.

Regards,
Adrien




___
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] keeping entities separate

[Stephen M. Butler]

On 08/13/2018 10:28 PM, patrushkha via gnucash-user wrote:
> Thanks for responding. I am clear that I want to have all the entities 
> separate- I thought I had set them up that way, but cannot discern how to 
> access them individually, and that's why I think I might have missed 
> something in the initial set up and that they are combined.

You will need to have three separate file names.  Could be in the same
folder but I put mine in different folders.  You may need to dump the
transactions as a csv file and use a spreadsheet to break them into
three different csv files to import to the new files.  Others on here
may have other shortcuts to break this apart.
>
> -Original Message-
> From: Mike or Penny Novack 
> To: gnucash-user 
> Sent: Mon, Aug 13, 2018 6:54 am
> Subject: Re: [GNC] keeping entities separate
>
> On 8/13/2018 8:52 AM, patrushkha via gnucash-user wrote:
>> I just started using Gnucash and thought I'd gotten through the learning 
>> curve; I have 2 small businesses and entered both of them as well as my 
>> personal data, but discovered they are all mixed together. At least I think 
>> so, I'm not versed enough to understand how I got there or how to untangle 
>> entities.
>> Can anyone suggest a process to separate them OR do I have to start all over?
>>
>> I'm also willing to hire someone to get me on track- Los Angeles area.
>>
>> Thank you so much,
>> Pat
> Oh dear. You are describing THREE entities here so ideally you should 
> want to have three sets of books If you are showing somebody the set of 
> books for one of the businesses (say you are selling it) no reason for 
> this prospective buyer to see anything about the other business or your 
> personal finances.
>
> I can't tell you whether better literally to start over or to 
> disentangle (temporarily having FOUR sets of books). There are other 
> questions you need to answer. For example, do these businesses have 
> their own bank accounts? Or are you perforce going to remain somewhat 
> entangled.
>
> Michael D Novack
>
> PS: If one or both of these "businesses" are small/minor it WOULD be 
> possible to carry them within your main personal books. And still be 
> able to see/report on each separately. BUT be advised that the chances 
> of error would be very high because neither gnucash nor any other 
> bookkeeping system would prevent you from entering a transaction in the 
> wrong place.
>
>
>

-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

___
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] Loan/Mortgage payments with "adjusted" principle (eg after an extra principle payment), SOLVED

[Mike or Penny Novack]

On 8/13/2018 11:29 AM, azalea4va wrote:

I addressed this in the file I provided.  There is one and only one
correct
answer mathematically.


I am surprised the moderators have not stepped in.

If you want to continue this, I suggest off list.


Michael D Novack
___
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] Trial Balance report error

[James Thorpe]

Thanks, bugfix edit to html-utilities.scm seems to have worked!


On 14/08/2018 15:00, Christopher Lam wrote:

https://bugs.gnucash.org/show_bug.cgi?id=796696

Known bug, fixed for next release. This bug report has instructions 
for fixing in interim.


On Tue, 14 Aug 2018, 19:52 James Thorpe > wrote:


Dear List

I just upgraded to the latest version on Windows (3.2) and now it
seems
the Trial Balance report is not working (no matter what options I
choose, it just returns "Report error"). I was previously on a
version
around 2.6 I think.

Can anyone give me guidelines as to how to trace the error? Same
seems
to be the case on my Fedora Linux installation.

kind regards

-- 
--

James Thorpe
061 476 2775
ja...@fusionsystems.co.za 

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



--
--
James Thorpe
061 476 2775
ja...@fusionsystems.co.za

___
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] keeping entities separate

[Mike or Penny Novack]

On 8/14/2018 1:28 AM, patrush...@aol.com wrote:
Thanks for responding. I am clear that I want to have all the entities 
separate- I thought I had set them up that way, but cannot discern how 
to access them individually, and that's why I think I might have 
missed something in the initial set up and that they are combined.
 If you are keeping books for multiple entities and there is no good 
reason to suppose that you would be wanting to work on the same set of 
books as the last set you were working on (as opposed to last having 
worked on one of the others) you can set gnucash to override the default 
"open the last books that were opened" << look up references to "nofile" 
for how to do that >> I suspect that your problem began because you were 
always just opening the last set of books even if you had created 
separate books for each entity.


Then gnucash will start without opening a file, requiring you to 
choose/specify "which" but there will be a drop down list of the last 
several you can simply pick from instead of typing in the file name,


The only time I would not do that is if out of entities, one would be 
worked on daily and the others rarely, perhaps only once a month or even 
less frequently. Even when gnucash does open the last set worked on you 
can tell it to open a different set of books.


Michael D Novack
___
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] Column widths again

[Graham Balin]

Thanks. doesn't work for me.
However, I have discovered that closing Gnucash and re-opening re-sets
things, so as long as I leave the column widths alone, all is well. The
moment I try to re-size, bang.
Masterly inactivity is called for, I think!
--

Cheerio,

Graham


On Mon, 13 Aug 2018 at 21:45, Colin Law  wrote:

> On Mon, 13 Aug 2018 at 19:37, Graham Balin  wrote:
>
>> ...
>> Once I have made the error of re-sizing one of the columns -bang, I have
>> to
>> keep horizontal scrolling to see what is going on.
>>
>
> All you have to do is to set the column sizes (apart from description) as
> you want then double click the description column and it should resize to
> fit the window.  At least that works for me.
>
> Colin
>
>
___
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] Trial Balance report error

[Christopher Lam]

https://bugs.gnucash.org/show_bug.cgi?id=796696

Known bug, fixed for next release. This bug report has instructions for
fixing in interim.

On Tue, 14 Aug 2018, 19:52 James Thorpe  wrote:

> Dear List
>
> I just upgraded to the latest version on Windows (3.2) and now it seems
> the Trial Balance report is not working (no matter what options I
> choose, it just returns "Report error"). I was previously on a version
> around 2.6 I think.
>
> Can anyone give me guidelines as to how to trace the error? Same seems
> to be the case on my Fedora Linux installation.
>
> kind regards
>
> --
> --
> James Thorpe
> 061 476 2775
> ja...@fusionsystems.co.za
>
> ___
> 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.

[GNC] Trial Balance report error

[James Thorpe]

Dear List

I just upgraded to the latest version on Windows (3.2) and now it seems 
the Trial Balance report is not working (no matter what options I 
choose, it just returns "Report error"). I was previously on a version 
around 2.6 I think.


Can anyone give me guidelines as to how to trace the error? Same seems 
to be the case on my Fedora Linux installation.


kind regards

--
--
James Thorpe
061 476 2775
ja...@fusionsystems.co.za

___
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] Unable to save to database. Build ID: 3.2+ (2018-06-24)

[mike]

On Mon, 2018-08-13 at 12:05 -0700, John Ralls wrote:
> > On Aug 13, 2018, at 11:20 AM, mike  wrote:
> > 
> 
> Look in the trace file [1] and your MySQL logs for error messages.
> 
> Regards,
> John Ralls
> 
> [1] https://wiki.gnucash.org/wiki/Tracefile
> 

Thanks, that was the sort of information I needed.

Problem now fixed.

___
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] GC 3.2 Import Price File CSV

[Deva -]

Can you please share a screenshot? Of both CSV import setting screen and the 
definition of the security in the security editor.

The CSV import price screen should also allow settings for date formats, 
locale, delimiters and such. Once I look at your whole import screen, I may be 
able to help further.

Things to check -

a. your date formats (though this is less likely to be your problem)
b. are your stock ids enclosed in quotes? If so, either change the import 
setting to imply that or remove enclosed quotes from the file
c. In the small grid shown in the import window, are all your fields correctly 
divided into columns? If not, there may be a delimiter problem

Cheers.

On 14-Aug-2018, at 11:31 AM, 
mailto:gnucash-user-requ...@gnucash.org>> 
mailto:gnucash-user-requ...@gnucash.org>> 
wrote:


Message: 8
Date: Mon, 13 Aug 2018 03:59:24 -0500 (CDT)
From: Megagrumpy mailto:megagru...@hotmail.com>>
To: gnucash-user@gnucash.org
Subject: Re: [GNC] GC 3.2 Import Price File CSV
Message-ID: 
<1534150764820-0.p...@n4.nabble.com>
Content-Type: text/plain; charset=us-ascii

I was specifically referring to the the CSV price import tool in Version 3.2.
I am trying to import the stock prices using this tool. Cannot get the Share
ID to be recognised whatever I do.



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html


--

Message: 9
Date: Mon, 13 Aug 2018 07:49:19 -0500 (CDT)
From: Megagrumpy mailto:megagru...@hotmail.com>>
To: gnucash-user@gnucash.org
Subject: Re: [GNC] GC 3.2 Import Price File CSV
Message-ID: 
<1534164559579-0.p...@n4.nabble.com>
Content-Type: text/plain; charset=us-ascii

That is what I have done. I am testing now with only one commodity -
Associated British Food. I have the id set in the security editor as ABF.L.
I have tried setting this on the CSV file to ABF.L. I have also tried ABF.
Still get the message "Commodity From could not be recognised". I have
changed the ID in the security editor to both ABF.L and ABF and still get
the same error message.



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html


___
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] GnuCash Theme Library

[Peter Jackson]

Michael, I think this is a good idea. There certainly is much more to be
discovered, and there are conflicts and associations that could be
unravelled. It's a matter of time and inclination, and needs the
participation of someone like Adrien who knows his way around the code. As
for me, I can tolerate a few imperfections if the overall appearance is
pleasing.
Peter




On 13 August 2018 at 19:50, Fross, Michael  wrote:

> Hello everyone,
>
> GnuCash, via GTK, has a very rich ability to change the fonts and colors
> and customize how GnuCash looks.  However, I think it's safe to say that
> it's not a trivial exercise for the average user.
>
> However, the recent discussions between Adrien, GTI, Peter, and others
> have made a lot of progress, IMHO, in understanding how CSS can control the
> look at feel.  I'm also sure there is much more than could be discovered
> and documented.
>
> Therefore, I'd like to create a GnuCash Theme Library in the Wiki where
> people who create custom GTK-3.0.css theme files can share them.  Other
> users can download the files (instructions will be provided by platform in
> the library) and try them out or use them as a base for their own tweaking.
>
> I was thinking of including the following information for each uploaded
> theme (* denotes a required field):
>   - Theme Name*
>   - Author*
>   - Date*
>   - Version*
>   - Description*
>   - Screenshot (no financial data please)
>   - Link to download file*
>
> I also think it would very useful to have a template file with every
> settable option in it that we know about with a brief description about
> each one detailing what it does.  That would really encourage people to
> download and tweak, or discover areas of customization they didn't know
> could be.
>
> While I'm new to MediaWiki, I'd be happy to spend time creating this theme
> library.  However, I'd like to get feedback on what we should include and
> overall thoughts on this and I'll see what I can do.
>
> Thank you very much,
>
> 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.