how exactly to do unit testing in scheme...

2018-01-24 Thread Christopher Lam
Dear Devel 

To rgmerk: Welcome back, and it was a nice to meet irl!

While simplifying transaction.scm and thinking of unit testing, I now have a 
conundrum worthy of an expert view.

The reports require 2 main functions – the options generator and the renderer; 
the options generator generates a options.scm controller object, and the 
renderer takes options and outputs html.

I understand unit testing to handle testing of ‘leaf’ functions e.g. 
(split->date), rather than the controller code (e.g. renderer takes options and 
outputs html) – but to me this is rather silly because split->date only tests 
xaccTransGetDate and xaccSplitGetParent, whereas the controller tests actual 
functionality.

With regards to unit testing I can see several issues

1) The refactored report has inlined most single-use functions into lambda 
expressions – I figured that directly stating (xaccTransGetDate 
(xaccSplitGetParent split)) is much more descriptive to a programmer than to 
create a testable leaf function (split->date split). I can see the benefits of 
both – leave as lambda expressions which will can be understandable by anyone 
who is familiar with the API, or break them out into 100s of single use 
functions which can be tested, but introduces a whole layer of cognitive load 
to anyone hacking code – (what does split->date actually do? Where is its 
definition). Also, breaking the lambda functions into testable functions means 
the implementation is frozen and the next hacker will have lesser scope to 
rework/optimise the report.

2) The refactored report is now flexible enough to accommodate derived reports 
with a different multicolumn data function – eg income-gst-statement.scm has 
been reworked into a transaction.scm derivative which passes its own 
calculated-cells to report on GST sales and purchases. This is not yet 
committed.

3) I think the most useful testing approach for a complex transaction.scm will 
be to test functions of various combinations of options values, and test the 
resulting html for satisfactory output. There are now dozens of bools and 
multichoices that can be triggered, each effecting html in various ways. How 
best to test?

4) My view would be the unit test would check that:
a. the TR actually exists
b. it can display empty-report
c. it can understand passing of custom-calculated-cells
d. each of the options can be toggled, and the resulting html displays/hides 
cells/detail as expected
e. and sorting options generate sorted rows

Comments welcome, I had no formal training ☹
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: how exactly to do unit testing in scheme...

2018-01-28 Thread Christopher Lam
Thank you Phil, with help from IRC I'll be separating the renderer into
multiple testable steps.

Options to accountlist, to splits, to filtered splits, and finally to
table.

Each one uses different parts of options.

On 26 Jan 2018 1:55 AM, "Phil Longstaff"  wrote:

> Usually, unit testing controller code is done by writing mocks for the
> code that is called. In this case, this would be the options.scm controller
> and the renderer. The mock code would test that the expected arguments are
> passed, and would return a canned response. This both checks the logic of
> the controller but also allows error and other paths to be tested.
>
> On Wed, Jan 24, 2018 at 11:03 AM, Christopher Lam <
> christopher@gmail.com> wrote:
>
>> Dear Devel
>>
>> To rgmerk: Welcome back, and it was a nice to meet irl!
>>
>> While simplifying transaction.scm and thinking of unit testing, I now
>> have a conundrum worthy of an expert view.
>>
>> The reports require 2 main functions – the options generator and the
>> renderer; the options generator generates a options.scm controller object,
>> and the renderer takes options and outputs html.
>>
>> I understand unit testing to handle testing of ‘leaf’ functions e.g.
>> (split->date), rather than the controller code (e.g. renderer takes options
>> and outputs html) – but to me this is rather silly because split->date only
>> tests xaccTransGetDate and xaccSplitGetParent, whereas the controller tests
>> actual functionality.
>>
>> With regards to unit testing I can see several issues
>>
>> 1) The refactored report has inlined most single-use functions into
>> lambda expressions – I figured that directly stating (xaccTransGetDate
>> (xaccSplitGetParent split)) is much more descriptive to a programmer than
>> to create a testable leaf function (split->date split). I can see the
>> benefits of both – leave as lambda expressions which will can be
>> understandable by anyone who is familiar with the API, or break them out
>> into 100s of single use functions which can be tested, but introduces a
>> whole layer of cognitive load to anyone hacking code – (what does
>> split->date actually do? Where is its definition). Also, breaking the
>> lambda functions into testable functions means the implementation is frozen
>> and the next hacker will have lesser scope to rework/optimise the report.
>>
>> 2) The refactored report is now flexible enough to accommodate derived
>> reports with a different multicolumn data function – eg
>> income-gst-statement.scm has been reworked into a transaction.scm
>> derivative which passes its own calculated-cells to report on GST sales and
>> purchases. This is not yet committed.
>>
>> 3) I think the most useful testing approach for a complex transaction.scm
>> will be to test functions of various combinations of options values, and
>> test the resulting html for satisfactory output. There are now dozens of
>> bools and multichoices that can be triggered, each effecting html in
>> various ways. How best to test?
>>
>> 4) My view would be the unit test would check that:
>> a. the TR actually exists
>> b. it can display empty-report
>> c. it can understand passing of custom-calculated-cells
>> d. each of the options can be toggled, and the resulting html
>> displays/hides cells/detail as expected
>> e. and sorting options generate sorted rows
>>
>> Comments welcome, I had no formal training ☹
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Future allocated money, aka Envelope Budgeting

2018-01-31 Thread Christopher Lam
Hi Matt- I thought this should move to the devel list, because of 
technical details, and this discussion will be very speculative.


I had a thought about how envelope budgeting could work: "divide your 
paycheck into separate envelopes for different purposes".


A solution: *Create another type of transaction.*

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid 
transactions. And (f)rozen I believe is unused. Let's create a new type 
- (b)udget. But the balances are handled differently.


It would require some UI and calculations changes --

1. The account budget balance is always maintained similarly to 
Running/Reconciled/Cleared Balances. But it would count all previous 
split-values *and* the (b)udget split amounts. However the budget 
running balance is not shown in the default register. This means, 
existing balances/register are unchanged.


    Let's say we're in a bank account register

    1/1    Opening $1 Running Balance=$1, Cleared/Reconciled 
Balance= $0, Budget=$1
    2/1    Income +$1000  Running Balance=$11000, Cleared/Reconciled 
Balance= $0, Budget=$11000
    3/1    Food -$50    Running Balance=$10950, 
Cleared/Reconciled Balance= $0, Budget=$10950
    4/1  <--- today      Running Balance=$10950, 
Cleared/Reconciled Balance= $0, Budget=$10950


2. We create another Register Action: "Allocate Budget".
"Allocate Budget" means we create a (b)udget transaction with 
multisplits from assets to expense accounts. By default we allocate the 
whole $10950. The $10950 in an asset account means "the amount remaining 
to allocate".


    4/1 Budget Transaction type "b"
           Asset:Bank -$10950
       Expense:Food $200
       Expense:Gas $200
       Expense:Taxes $300
           Imbalance $10250

Now the state of the Bank register is:

    5/1 Running Balance=$10050, Cleared/Reconciled Balance=$0, Budget 
Balance= $0


And the Food register is:

    3/1 Food $50  Running Balance=$50 Cleared/Reconciled=$0 Budget=$50
    4/1 Budget $200 Running Balance=$50 Cleared/Reconciled=$0 Budget=$250
    5/1 <--- today    Running Balance=$50 Cleared/Reconciled=$0 Budget=$250

3. We can allow the imbalance account to collect unbudgeted/spare 
monies. Or we can decide to allocate an amount smaller than $10950, 
leaving the 'budget' balance in the bank register a positive value.


4. Now the Food account has several balances accessible via API

    Running Balance $50 - as usual counts all split-values from "n" "y" 
"c" including future splits.

    Unreconciled $50 - counts splits-values from "n"
    Cleared $0 - counts splits-values from "n" "c"
    Reconciled $0 - counts splits-values from "n" "y" c"
    Budget $250 - counts all split-values from "n" "y" "c" "b"

5. A Budget report could be created, comparing the various expenses' 
running balances vs the budget balance. The difference is the amount 
left to spend in this category. For the food account it's 250-50 = $200 
left to spend.


6. Anytime the user wishes to allocate more budget to food, they can 
simply create (b)udget transaction from Bank or Imbalance account to the 
Food account.


7. This means, in the account register, we'll see regular transactions 
which can be reconciled with the bank statement. We'll also see budget 
transactions, not reconcilable with the bank statement. Perhaps they 
should be a different color/background. But this is ok, because their 
amounts do not affect the account running balance. The Reconcile window 
can also filter them out. The existing reports are unaffected. The query 
mechanism should ignore them by default.


What do we think of this?

The budget balance for an asset account represents "money remaining to 
allocate", and the budget balance for an expense account effectively 
represents "the upper limit that I'll allow this account to be". The 
budget balance, minus running balance represents "money left in 
envelope". I can increase envelope contents by transferring budget money 
from asset to the expense accounts.


I wouldn't know how to handle credit card nor loan interest.

I think it's an interesting thought experiment. The devil will be in the 
details.


The advantage will be that the underlying code can handle this augmented 
functionality without major difficulty (famous last words.)


Chris

On 31/01/18 15:59, David T. via gnucash-user wrote:

Matt,
I have to admit that I misread the tally; I did not see that the first $500 
(AllocatedCash) was balancing the others. My apologies.
I'll let you and Adrien work this out, since I don't have a lot of background 
in this.
David

  
  
   On Wed, Jan 31, 2018 at 8:58, Matt Graham wrote:   #yiv0595440679 #yiv0595440679 -- _filtered #yiv0595440679 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0595440679 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv0595440679 #yiv0595440679 p.yiv0595440679MsoNormal, #yiv0595440679 li.yiv0595440679MsoNormal, #yiv0595440679 div.yiv0595440679MsoNormal {ma

Re: Future allocated money, aka Envelope Budgeting

2018-02-01 Thread Christopher Lam

Hi Adrien,

From reviewing the code, I still believe the (b)udget transactions 
system works better. The current code calculates all 
Reconciled/Cleared/Unreconciled balances on the fly, and it'll be pretty 
easy to add one for Budget balances. If I'm right, a book with large 
number of transactions over years will require perhaps 20 (b)udget 
transactions per year, which will hardly be straining the datafile or 
the code.


It is also compatible with the suggestion for "manually triggered SX" or 
"transaction templates".


The only feature that the envelope system doesn't support is an 'expiry 
date' for the budget -- some people may prefer monthly/quarterly/annual 
budgets, and so far I can't think how this would work. The register 
would really just need color coding to identify 'balance too close to 
budget' situations.


Try opening a register and see View > Filter by... > Status you'll see 
all 5 statuses are ticked. If by default the suggested "b" transactions 
are disabled then the average user will never see them.


My suggestion also obviates the need for the shadow accounts as your 
recommendation.


IMHO Using a separate kvp system will lead to performance issues similar 
to current Budget on Windows.


I'm rather tempted to hack the code to calculate the budgeted amounts by 
abusing the current (v)oid transactions UI, and it seems very doable :-o


Chris


On 01/02/18 22:05, Adrien Monteleone wrote:

On Jan 31, 2018, at 2:48 PM, Phil Longstaff  wrote:


On Wed, Jan 31, 2018 at 11:35 AM, Adrien Monteleone mailto:adrien.montele...@gmail.com>> wrote:



On Jan 31, 2018, at 10:09 AM, Christopher Lam mailto:christopher@gmail.com>> wrote:

Hi Matt- I thought this should move to the devel list, because of technical 
details, and this discussion will be very speculative.

I had a thought about how envelope budgeting could work: "divide your paycheck into 
separate envelopes for different purposes".

A solution: *Create another type of transaction.*

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid transactions. 
And (f)rozen I believe is unused. Let's create a new type - (b)udget. But the 
balances are handled differently.

It would require some UI and calculations changes --

1. The account budget balance is always maintained similarly to 
Running/Reconciled/Cleared Balances. But it would count all previous 
split-values *and* the (b)udget split amounts. However the budget running 
balance is not shown in the default register. This means, existing 
balances/register are unchanged.

Having transactions in an account register that don’t affect the balance is 
going to be very problematic. I think this would really confuse users.

I would think budget levels for each expense account could be exposed in the 
properties/preferences for each one.

That's basically how it's done now. It uses the kvp (key-value pair) mechanism 
and each account has a kvp per budget per period with the budget amount.

But I see they aren’t exposed in the Account Edit window. The only way to see 
what was budgeted is to open the budget module, or to see what’s left is to run 
a budget report. And even that part is limited as it’s only a all-or-nothing 
figure for the year, not year-to-date.

Regards,
Adrien
  


The allocation of budget money would have to be handled with a special dialog 
on demand, or as part of an income/asset account preferences with 
percentages/formulas. (essentially a template transaction that fires when 
entries are made in that account)

We already have a budgeting mechanism to set how much we *want* to spend on a 
particular expense.

What we’re discussing here is a way to ‘save up’ funds received for each of 
those expenses.

If I understand correctly, the budget module uses hidden accounts to keep track 
of everything. I would think these same accounts, or other hidden accounts 
paired with them, could do the job.

This is incorrect. It uses kvp (key-value pair) structures attached to each 
account.
  
Phil

Thanks for clearing that up. Certainly, that seems the more sane route. I would 
think another set of kvp could be implemented to handle the envelope system 
then. One set to hold the amount already allocated and another to hold the 
allocation formula. The original budget pair could be used as the goal.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Future allocated money, aka Envelope Budgeting

2018-02-02 Thread Christopher Lam

Dear Devs

The more I consider (b)udget transactions the more I feel it is the 
right solution. See 
https://docs.google.com/spreadsheets/d/1aaMoMVVTky_Df_haNAeVk3XpsgFIC7eMOOT7uurlV-s/edit?usp=sharing 
for an example of a report with these "b"udget and regular transactions. 
This demonstrates regular $50 monthly budgeting, and quarterly $300 
spending, with 1 overspending, and 1 underspending. It also works with 
closing transactions... which are either enabled/disabled according to a 
random switch. The chart can also demonstrate the metaphorical envelope. 
I think this can easily be hacked into code.


The dilemma is to consider how to modify the schema to achieve this:

option (1) reuse (v)oided transactions which can ensure the datafile is 
backward-compatible and the balances are not affected in previous 
version, with a kvp flag on the transactions, to identify budgetary 
transfers. This will be similar to how closing txns are flagged.
Advantages - are that existing code will count the split amounts as 
zero. Previous versions will display the transfers as "v" txns.
Disadvantage - will be budget transactions being treated similar to 
voided transactions, in the UI code and will require special handling. 
Accessing budgetary amounts will need mechanism similar to 
xaccSplitVoidFormerValue.


option (2) add "b" for budget transactions as a clean slate for 3.0 
datafiles onwards.

Advantage - clear transaction-type.
Disadvantage - datafile not compatible with previous versions. Requires 
special handling within xaccAccountRecomputeBalance to ignore them.


option (3) add these transactions in a separate part of the datafile, 
outside the accounts splitlist.

Major Disadvantage - requires numerous code, UI and schema changes.

Either way I'd be grateful if some pointers could be offered? Even if 
code, UI and reports are not completed in time for 3.0, it would be nice 
to formalize the schema 3.0 release?


I may be able to do TDD for this @rgmerk

Thanks!

On 01/02/18 22:45, Adrien Monteleone wrote:

On Feb 1, 2018, at 8:22 AM, Christopher Lam  wrote:

Hi Adrien,

 From reviewing the code, I still believe the (b)udget transactions system 
works better. The current code calculates all Reconciled/Cleared/Unreconciled 
balances on the fly, and it'll be pretty easy to add one for Budget balances. 
If I'm right, a book with large number of transactions over years will require 
perhaps 20 (b)udget transactions per year, which will hardly be straining the 
datafile or the code.

It is also compatible with the suggestion for "manually triggered SX" or 
"transaction templates”.

That enhancement was only for an actual transaction that moves money from a 
parent to sub-accounts. I didn’t intend that as a separate layer ‘virtual’ 
transaction. But yes, I see it could work for both.


The only feature that the envelope system doesn't support is an 'expiry date' 
for the budget -- some people may prefer monthly/quarterly/annual budgets, and 
so far I can't think how this would work. The register would really just need 
color coding to identify 'balance too close to budget' situations.

My understanding is that the envelopes don’t expire, it’s a retained ‘savings’ 
so I get they don’t have a date. That doesn’t preclude budgeting by period 
though. Say you set a spending budget of $100/$300/$1200 for dining out 
(monthly, quarterly, yearly) then you use that as your envelope goal. As you 
allocate, you can see if you have hit your goal. (if so, the allocation stops) 
If you end up spending under budget, that money remains allocated. (unless you 
flow it somewhere else) You’ll just have a head start in your savings plan when 
the next period cycles around. An additional calculation would be needed here. 
At any point in time, you’d need to see the remaining goal to be saved for.

There should also be a mechanism for letting the user decide how to control the 
allocation or flow of money to the envelopes. This could be a ‘stop’ situation 
based on if either the monthly, quarterly, or yearly goals are reached. Someone 
might want to set a high % to be allocated until perhaps one or two quarters 
are saved up, then back off a bit. Or they might want to leave it high until 
the goal is reached, but keep saving at a lower level. (that part is good for 
emergency funds or debt retirement) Or they might want to only allocate each 
month until the goal is reached (which might be the first pay check) and then 
stop until the month rolls over.

I know this is sounding more complicated, but if the user can’t control their 
savings rate and plan, they probably aren’t going to use the feature much.

By the way, I do like the idea of some sort of color warning with respect to 
hitting budget limits.

Try opening a register and see View > Filter by... > Status you'll see all 5 statuses are 
ticked. If by default the suggested "

Re: Future allocated money, aka Envelope Budgeting

2018-02-04 Thread Christopher Lam

Hi Wm

I wished to experiment in what budgeting should look like by using the 
existing engine, UI, and reporting infrastructure.


It's actually not that difficult to create a 'budget balance 
calculator'; whether it meets the needs for everyone is another matter. 
But for people who wish to experiment with envelope budgeting, I can 
confirm that it is possible.


Rules are:

 * budget transactions must be "outside the books" so to speak, i.e.
   they are not counted in any net worth, profit/loss, transaction
   report, etc. they must be, by default, invisible to the reporting
   engine.
 * in order to be acceptable by the engine, they should they should
   satisfy the double-entry equation.
 * it should be generally useful
 * it should be better than the current budget

So this is actually a success. I don't use transaction voiding, and have 
hacked "voided transactions" to become "budget transactions" and 
upgraded the status bar display. The results are available on the 
topmost commit in 
https://github.com/christopherlam/gnucash/commits/envelope-budgeting as 
a demo of "what can be achieved using the engine". But I stress this was 
an experiment.


HTH.

On 04/02/18 20:33, Wm via gnucash-devel wrote:

On 03/02/2018 00:12, Matt Graham wrote:

Wow! That become contentious quick!!!


Only sort of.  If you read the devel list before the user list you get 
a feeling for what isn't going to happen soon and why.


The primary issue I’m seeing here is one of philosophy. What is 
GNUCash for? What is the purpose? What “should” be included and what 
“shouldn’t” be?


It is for people, of course ! Perhaps you meant, "who is it for?" :)

There is a universe of people that like, use and prefer single entry 
accounting along with the budgeting spiritualism and personal mantras 
that accompany some of them.  gnc ain't that and may not be for them.


Let me mention something else I think should, for example, be removed 
once the db is sorted out: USA and other country specific tax stuff 
(I'm not even sure how much of it works any more as governments change 
their tax systems without consulting gnc, etc)


Double entry accounting has been around for a while, that is 
definitely going to be included for ever.


Budgeting is, as I said before, personal.  It varies from person to 
person (I think envelope budgeting is short sighted) and what is 
appropriate for a person is inappropriate for more formal 
organisations that might require auditing or oversight.


If *all* the myriad of wonderful budgeting weirdness was added to gnc 
the prog would more than double in size in a year ... each year ... 
and 3 people would be using each of the special budgets and another 2 
requests would come in each year, etc.


It just doesn't make sense putting more into an over stretched db 
compared to an interface that anyone can grab anything they want from 
using an ordinary spreadsheet.


Am I making sense?
gnc isn't
for a person of a certain nationality, it should work for most
gnc isn't
for a person or an organisation, it should work for most
gnc isn't
for a charity vs a business, it should work for most
gnc isn't
for a country, it works with currencies
etc

As has been highlighted, when someone loads up software they have a 
preset notion in their own mind of how it “should” work, and that is 
usually their own very narrow context (e.g. “That’s not how budgets 
work!”).


gnc's existing budgeting is very useful to some businesses and charity 
organisations, even though I use them in that context I still think 
they should be pulled out in the long term.  Budgeting is too 
idiosyncratic.


And anyway, given a good interface you could use, I could probably 
write a budget app a day.


NB: budgeting is not complicated computing, it is largely a human 
problem rather than a computing one.


My assumption on purpose: Open source software is created out of need 
and altruism. People who know how and want help create and maintain 
the project both because they are interested in software and enjoy 
the process, but also because they like being altruistic and 
providing something that others find useful.


I won't speak for seniors, I do read what they say. Of course, my 
understanding is mine if incorrect.


Based on that assumption, I have had the attitude “All requests 
should be considered and prioritised by the devs, but of course they 
will mainly implement what they find useful and of course they will 
only give how much time they can afford to”.


devs may be busy, devs may have a long list, devs may have lives aside 
from the project, etc


The natural flow on from my attitude is that I should indeed throw in 
what I want/need from my financial tools, but not expect anyone to 
act on it. If I want it done, I need to donate my time and implement 
it because it is definitely unreasonable to demand others to do it 
when it isn’t useful for them. (On that note, I’m keen to help out, 
but don’t yet have knowledge (and also struggle f

Re: Bug in "Liabilities Barchart" report (since 2.6.19)

2018-02-05 Thread Christopher Lam

Hi Di Mang I agree bug exists - would you be able to file bug report?

We'd need to investigate category-barchart.scm


On 06/02/18 05:24, Di Mang wrote:

Hello all,

I have investigated this problem further in the last few days.
I think, it doesn't depend on some special version of GnuCash.

For example, all works fine, if I use pre-build versions of GnuCash.
I tested it with:
* GnuCash (2.6.17, 2.6.19) on Windows 7 (from GnuCash-website)
* and GnuCash 2.6.17 on Ubuntu 17.10 (from Ubuntu Software Center).

But, it does not work right (see screenshots in my first mail),
if I build GnuCash from souce files myself (2.6.19 or unstable, on Ubuntu
17.10, with cmake).

I attached the output files for "cmake" and "make" commands.
Can it be, that I am using a wrong version of some library?

2018-01-28 16:50 GMT+01:00 Frank H. Ellenberger <
frank.h.ellenber...@gmail.com>:


Hi,

Am 28.01.2018 um 15:48 schrieb Di Mang:

Hello,

I have a problem with the "Liabilities Chart", "Asset Chart" and "Net

Worth

Barchart" reports since I switched to GnuCash 2.6.19 (on Ubuntu 17.10). I
have this problem with unstable 2.7.3 too (built from source). With

GnuCash

2.6.17 the reports worked as expected.

These reports display the accumulated amounts, but only based on the
transactions from the selected period. The transactions before the start
time are ignored. See example in the appendix (as image and GnuCash

file).

​I tried to find the error. Unfortunately, I do not know where to start.​
Can someone please look at it. With the example from the attachment it
should be easy. Thanks in advance!

​DM​

Did you accitently change Preferences->Accounts->Reverse Balance Accounts?

Frank





___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: RFP: Generic Comparison Report

2018-02-09 Thread Christopher Lam

Hi D

Wish to move to devel, technical and policy details abound.

There's already work done to enable periodic subtotals comparison. This 
feature has been named "Subtotal Summary Grid". This is done by reusing 
and augmenting the (most excellent) transaction report's grouping and 
subtotals. I'm not sure whether this allows 100% coverage of users' 
requirements for periodic comparison, but I suspect it would.


For example, setting *accounts* = expense accounts (+ children), 
*primary-key* = account, *secondary-key* = date,*secondary-subtotals* = 
monthly, *subtotal-summary-grid* = enabled -> will provide a nice 2D 
grid whereby Y-axis = accounts, X-axis = monthly expense subtotals. This 
feature will reuse the subtotals already generated within the 
transaction report, therefore any errors in subtotals are not from my 
code. Example at https://imgur.com/a/unDAD


Unfortunately it was completed after string and feature-freeze for 
upcoming 3.0 -- I'm afraid that inclusion into 3.0 isn't guaranteed yet. 
Although, as I have notified devs, if this feature is renamed "Grid", it 
could be written into 3.0. The translated string "Grid" already exists.


If you wish to experiment, the code is currently available at 
https://github.com/Gnucash/gnucash/pull/266/commits/4d2ee75b4fa138c0534ae739089d4df70d6d4117 
- (note, this commit link isn't permanent).


C


On 10/02/18 13:35, D via gnucash-user wrote:

Hello,

I want to raise a discussion here about the creation of a generic comparison 
report.

I would preface this discussion by saying that, although I am a long time user 
of Gnucash, I have repeatedly demonstrated my utter inability to generate 
useful code for the project, so any ultimate action on the results of this 
discussion would have to be applied by someone else.

As we have seen recently, and as I have seen repeatedly over the years, one of 
the more common requests for reporting is to be able to see numbers from 
different time periods in order to evaluate a financial situation.

As far as I can tell, other than the multi column report, nothing of the sort 
exists in Gnucash. I started thinking that it might be good to begin the 
process of detailing what features might go into such a report in order to make 
it generally useful, with the idea of perhaps stirring up someone's interest in 
creating such a report.

Some initial ideas include:

* Definable periods. Should be able to set the unit period, with options for 
common units (month, quarter, year).
* Definable numbers of periods.
* Definable accounts, but with some common groupings (Assets, Liabilities, 
Investments... Are there others?)
* Perhaps the option to use another report as a template? I have no idea how 
that might work, but the fact that folks seem to want side by side balance 
sheets suggests this to me.

Does anyone else think this would be helpful? Is it a reasonable idea? Is it 
something that someone in the community with Scheme skills is interested in 
pursuing? Are there other elements that would make this a better idea? Are 
there elements that are absurdly difficult or impossible?

Cheers,
David
___
gnucash-user mailing list
gnucash-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: how exactly to do unit testing in scheme...

2018-02-12 Thread Christopher Lam

Hi Robert and devel,

Thank you for pointers, this is useful. The examples below illustrate 
how to test multiple items together. But I think the complexity of the 
52(and counting) options (37 binary, the rest are multiples/multichoice) 
means, I think it'll be better to handwrite tests. I'll need to reuse 
existing test frameworks to attempt maximise coverage.


C

On 31/01/18 09:01, Robert Merkel wrote:

Sorry for the tardy response - I went away for the long weekend and was
busy yesterday!

As Phil says, you can test both leaf functions and controller code with
unit tests. With controller code, you may need to write mocks for some or
all of the called code.  I don't know whether there are prewritten mocking
libraries for guile, but given the extreme flexibility of scheme it
shouldn't be difficult to write code to replace one function call with
another where necessary.

As long as xaccTransGetDate and xaccSplitGetParent are adequately tested,
there is no particular reason from a testing perspective to throw in an
intermediate function.

As far as which options to test, if testing all the combinations
exhaustively results in too many tests (and it sounds like it does) try
pairwise combinatoric testing, which works as follows:

Say you've got options {o_1, o_2, o_3, ... o_n}, each of which can take a
limited set of values {o_i^1, o_i_2, o_i^k} (for instance, if the option
can either be "on" or "off" it has two values).

For any pair of options o_x and o_y, for all the possible combinations of
option values there should be at least one test that has that combination.

To give a very simple case, for three options {a, b, c}  each of which can
take two values {off, on}, you could have the following tests:

  Option   a b c
Test
1 off  off   off
2 off   on  off
3 on   off   on
4 onon  off
5 off   offon

For the pair (a,b) tests 1 through 4 give all the possible combinations,
for the pair (a, c) tests {1, 3, 4, 5} give all the possible combinations,
and for the pair (b, c) tests {1, 2, 3, 4} give all the possible
combinations.

5 is the minimum number of tests that can meet the pairwise combinatoric
criterion, as compared to 8 if you tried all the possible combinations.
However, it becomes an even bigger win if you're trying lots of options:
you only need 9 tests for 8 options with two values, whereas you would need
256 tests to try every possible option combination!

To generate optimal pairwise test sets, you can use "jenny" (this is a
really useful but unmaintained tool, I really should take over the
maintenance):

http://burtleburtle.net/bob/math/jenny.html

Hope this helps, and feel free to ask more questions.  I will try to
respond more promptly!


On Thu, Jan 25, 2018 at 3:03 AM, Christopher Lam 
wrote:


Dear Devel



To rgmerk: Welcome back, and it was a nice to meet irl!



While simplifying transaction.scm and thinking of unit testing, I now have
a conundrum worthy of an expert view.



The reports require 2 main functions – the options generator and the
renderer; the options generator generates a options.scm controller object,
and the renderer takes options and outputs html.



I understand unit testing to handle testing of ‘leaf’ functions e.g.
(split->date), rather than the controller code (e.g. renderer takes options
and outputs html) – but to me this is rather silly because split->date only
tests xaccTransGetDate and xaccSplitGetParent, whereas the controller tests
actual functionality.



With regards to unit testing I can see several issues



1. The refactored report has inlined most single-use functions into
lambda expressions – I figured that directly stating (xaccTransGetDate
(xaccSplitGetParent split)) is much more descriptive to a programmer than
to create a testable leaf function (split->date split). I can see the
benefits of both – leave as lambda expressions which will can be
understandable by anyone who is familiar with the API, or break them out
into 100s of single use functions which can be tested, but introduces a
whole layer of cognitive load to anyone hacking code – (what does
split->date actually do? Where is its definition). Also, breaking the
lambda functions into testable functions means the implementation is frozen
and the next hacker will have lesser scope to rework/optimise the report.



1. The refactored report is now flexible enough to accommodate derived
reports with a different multicolumn data function – eg
income-gst-statement.scm has been reworked into a transaction.scm
derivative which passes its own calculated-cells to report on GST sales and
purchases. This is not yet committed.



1. I think the most useful testing approach for a complex
transaction.scm will be to test functions of various combinations of
op

Re: Scope of GNUCash

2018-02-13 Thread Christopher Lam
Hi Adrien - from someone who jumped head first into scheme, come on in :)
the water's warm, and the old guard are very happy to help you implement
your wishlist. Meanwhile you'll soon see for yourself what the project
needs and can dabble in too. Scheme currently needs lots of refactoring and
tests, and this will be independent of C++/GTK3 work.

On 14 Feb 2018 11:32, "Adrien Monteleone" 
wrote:

> Not sure what the current POTUS office holder has to do with anything
> related, but, whatever…
>
> I was just in NOLA for a few days, now back home in Lafayette. Happiness
> is measured in beer, or something similar, here. I’ve had several beers
> today, so my happiness meter is reading high at the moment.
>
> I have zero demands on the developer team. I hope they accomplish all they
> set out to. (and quickly!) But I’m thankful they’ve laid out a road map for
> me to decide where (and how) to hop on the train should I manage to chime
> in with something useful. (*note, validated code is useful, ideas? not so
> much)
>
> For now, I’m going to attempt to tackle some report issues. Sure, I could
> wait till full SQL arrives, but that wouldn’t serve needs NOW. I don’t
> ‘want’ to learn scheme, but I’ll take one for the team if it means being
> able to offer some out of the box ‘features’ people keep asking for.
>
> After that, or in the middle of doing so, I might decide to get my feet
> wet with GC code. I’d ‘like’ to work on things I want to see implemented,
> but I understand certain other tasks have to be taken care of first, most
> notably, the move to full C++ and GTK3. Once that is done, lots of legacy
> code and ways of doing things can or will be quickly discarded which will
> then clear the way for more ‘features’ that users are looking for. So when
> I do jump into code, my focus will always be to try to work on what the
> project needs, not what I need. If I can squash some bugs in the process,
> all the better.
>
> Happy Mardi Gras,
> Adrien
>
> > On Feb 13, 2018, at 6:34 PM, Wm via gnucash-devel <
> gnucash-devel@gnucash.org> wrote:
> >
> > On 13/02/2018 21:53, Matt Graham wrote:
> >> 😊 I think I would love to sit down in a pub with the three of you (Wm,
> Adrien, and Mike). I think we could have such awesome semi-drunken
> discussions about the nature of life, the universe and everything!
> >
> > I'm in London. Mike is in a Trump voting bit of Merka. Don't know where
> Adrien is and he shouldn't have to say.
> >
> > Accounting is a way of measuring life.  Happiness is harder to
> quantify.  Life should be enjoyable and measuring money shouldn't occupy
> too much of our time.
> >
> > Most crass philosophical sayings are also guaranteed to be crap.
> >
> >> I think you have basically answered my question, and I think we all
> basically agree on the rough direction things *should* go in (separate
> interacting packages).
> >
> > I'm the person arguing for stuff to be taken *out* of the basic package
> so the important stuff can more easily be better interpreted or used, the
> important stuff being the data that each of us owns or has responsibility
> for.
> >
> > Meanwhile, since I have a good understanding of accounting and databases
> and related stuff, I just do the bits I need that gnc doesn't cover using
> plain text accounting.  My point in that regard being that almost all the
> *thought* problems have been solved in the plain text accounting universe
> and plain text accounting has also solved some problems you and I didn't
> even know existed and are way more esoteric than a budget being to your
> specific needs or a report being formatted one column to the left for the
> convenience of your tax accountant.
> >
> > The problems have been solved, it is the presentation you are struggling
> with.
> >
> > > I’m just not sure how to help make it happen (I’m an enthusiastic
> amateur when it comes to programming).
> >
> > The gnc code is almost impenetrable in parts.  I'm considerably above
> average when it comes to programmings skills but there are, when I drill
> down, bits that simply don't parse.  I know exactly what the code is meant
> to be doing but someone has written it in such an obscure way I just give
> up and return to understanding the data.
> >
> > It is *this* that the seniors are working on rather than adding a bell
> or a whistle.
> >
> > If the code can't be brought into a form where more than a handful of
> people can understand it the project is going to die with the seniors as
> they naturally retire to caring more for their grandchildren than people on
> the internet thing that demand they do this or that.
> >
> > You seem like one of the demanding people to me, Matt
> >
> >> I think I’ll start by updating the budget part of the tuts and concept
> guide like I have promised elsewhere, and then start looking into how the
> C++ modules have been structured (to see what connection will be possible
> within the 3.0 releases).
> >
> >
> > Ufff, you are welcome to try to understan

Re: trial balance - how to find mismatch question

2018-02-15 Thread Christopher Lam
Hi Adrien, could you distil this to a minimal test file and submit in a bug
report and include relevant report and report parameters? C

On 16 Feb 2018 10:09, "Adrien Monteleone" 
wrote:

> How timely.
>
> Any way to solve this or do I just chalk it up?
>
> Regards,
> Adrien
>
> > On Feb 15, 2018, at 8:00 PM, David Carlson 
> wrote:
> >
> > If you have multiple currencies  or if you buy and sell commodities or
> securities  there is another level of opportunities for issues.
> >
> > David  C
> >
> > On Feb 15, 2018 5:55 PM, "Adrien Monteleone" <
> adrien.montele...@gmail.com> wrote:
> > I just noticed the subject was wrong due to a user-digest error,
> re-applying the original.
> >
> > ———
> >
> > I’m having a bit of issue understanding the point of the trial-balance
> report in modern times. (I generally don’t use it as I mentioned)
> >
> > If each transaction self-balances, that is, debits = credits, how is it
> possible to add up the debits individually and the credits individually and
> not get a result that still balances? You can’t add up 1+2+3 = 5 and 1+2+3
> = 6. It’s a mathematical impossibility.
> >
> > In addition, if you enter a transaction that doesn’t balance, Gnucash
> forces it to balance by using either the imbalance or orphan accounts. So
> at least you’re alerted to amounts you need to fix, but technically, debits
> still equal credits.
> >
> > Let’s assume I entered a transaction backwards and debited my cash
> account instead of crediting it, and credited an expense account instead of
> debiting it. This should not affect the trial-balance. Sure, the amounts
> are wrong for each account, but they still balance. Debits still equal
> credits.
> >
> > If I transpose two digits (the divisible by ‘9’ trick) then as long as
> my individual transaction I did this in balances, it still shouldn’t show
> up as an imbalance on the trial-balance report. The other side would ALSO
> have to be transposed or incorrect to match it. Gnucash won’t save the
> transaction unless it’s balanced.
> >
> > I can’t see what possible error could produce individually balanced
> transactions (required by Gnucash) and yet still have a trial-balance where
> the debits do not equal credits AND both the imbalance account and orphan
> accounts are empty.
> >
> > (note, I understand why this report is run with paper records because
> you’re copying stuff all over the place and might do so incorrectly. But
> this isn’t the case with Gnucash)
> >
> > Regards,
> > Adrien
> >
> > > On Feb 15, 2018, at 5:06 PM, Adrien Monteleone <
> adrien.montele...@gmail.com> wrote:
> > >
> > > The 1899 date seems to make me think that has something to do with a
> setting in your OS concerning how to interpret 2-year dates. (I don’t think
> Gnucash has this option, it might be hard coded)
> > >
> > > Try running the report again and make sure to enter the full 4-digit
> date and not just ’16’. Also, test with 12/30/2016 and 01/01/2017 and see
> if it does the same thing or only on exactly 12/31/2016. You might have
> some corrupt data. That might even be the source date of the imbalance.
> > >
> > > I just entered those two dates in the same report and it worked fine,
> so this wouldn’t be a generic bug to the app, though it might be a bug for
> a certain platform. (I’m on macOS 10.13 at the moment)
> > >
> > > Since you’ve narrowed down to a few weeks, I’d just take a look at the
> General Ledger which contains all transactions from all accounts. Click on
> View > Filter By… and set your date range. (maybe even a day before and
> after just to be thorough) Also be sure to check all boxes on the Status
> tab in the Filter options. You want to see all transactions for that date
> range. Then just look over them and see if anything looks out of place. In
> particular, look for either the amount you are out of balance by or half
> that amount if the variance is an even number. (meaning you have an entry
> that is entered in reverse debit/credit, or entirely duplicated)
> > >
> > > For myself, I think I want to tackle one other area first. I recall
> doing some re-organization and I went through a series of unposting paid
> invoices and reposting them, causing my lot assignments to get out of
> whack. I know I have some open lots that shouldn’t be there and many that
> are applied to the wrong documents. I’ll clean that up first, then re-run
> the trial balance and see if that does the trick. I’m not sure where the
> Trial-Balance report is pulling its numbers from, but it won’t hurt to
> perform that cleanup anyway.
> > >
> > > Regards,
> > > Adrien
> > >
> > >> On Feb 15, 2018, at 2:35 PM, Elmar  wrote:
> > >>
> > >>
> > >>
> > >> On 02/15/2018 02:28 PM, gnucash-user-requ...@gnucash.org wrote:
> > >>> 
> --
> > >>>
> > >>> Message: 1
> > >>> Date: Thu, 15 Feb 2018 13:27:17 -0600
> > >>> From: Adrien Monteleone 
> > >>> To: "gnucash-u...@gnucash.org" 
> > >>> Subject: Re: tri

Re: trial balance - how to find mismatch question

2018-02-16 Thread Christopher Lam
t manually. When I
> decided
> > to audit the report for each account is when I found the foreign currency
> > account out of whack. The remaining difference was attributable entirely
> to
> > the ‘unrealized losses’ line.
> >
> > So, the full difference between debits and credits is the SUM of the
> > ‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.
> >
> > At least in my case.
> >
> > So there are two problems with the report:
> >
> > 1) There should be no losses or gains if there were no trading
> > transactions. Certainly, this is impossible if there is only one day on
> the
> > range of the report and the price is the same. If all you have are
> opening
> > entries and you attempt to run a trial balance for that same day, you
> can’t
> > have either a gain or a loss, unrealized or not.
> >
> > 2) Because the Equity:Opening Balances account is the result of rounded
> > figures for each entry in a foreign currency, the report’s method of
> taking
> > the foreign currency ending balance as of a date and doing the exchange
> > rate calculation at the end, will always produce a discrepancy. The
> report
> > would have to sum the book-default currency amounts individually or
> somehow
> > a book-default currency balance would have to be maintained and that used
> > instead. Alternatively, a foreign currency account could use the same
> > precision as the foreign currency itself, thus removing the potential for
> > rounding errors if not eliminating them.
> >
> > Possibly, increasing the decimal places and re-entering the transactions
> > for the XAG account might resolve the rounding issue. (only because now
> the
> > USD amounts sum correctly to match since they don’t round enough) But
> then
> > ALL USD accounts would have this extra precision which is not desirable
> > generally.
> >
> > The alternative would be to reduce the precision of the XAG account, but
> > again, that is undesirable for accurate tracking of ownership quantities
> of
> > the actual metal. (or currency if that’s the case)
> >
> > The per-account precision setting seems to only affect the default
> > currency for that account, in this case, XAG, not USD, which seems only
> to
> > be controlled by the book setting.
> >
> >
> > Regards,
> > Adrien
> >
> > > On Feb 15, 2018, at 10:55 PM, David T.  wrote:
> > >
> > > I don’t believe I’ve seen anywhere in this thread any attempt to
> explain
> > that there is a difference between IMBALANCE-XXX (an indication that you
> > have transactions that lacked a balancing split) and the Imbalance entry
> in
> > the Trial Balance report. This latter most likely indicates (as David C.
> > has hinted) that your books have capital or currency gains or losses that
> > haven’t been entered into the books. If you buy a stock for $100 using a
> > balanced transaction, and later sell that share for $150 (we wish!) in a
> > balanced transaction, GnuCash will wonder where you got an additional
> $50.
> > Both transactions balance, but the books don’t. That is why you usually
> > have an entry (either as a separate transaction, or as splits in the sell
> > transaction) that account for this gain.
> > >
> > > Of course, it can get complex.
> > >
> > > David T.
> > >
> > >> On Feb 16, 2018, at 7:31 AM, Christopher Lam <
> christopher@gmail.com>
> > wrote:
> > >>
> > >> Hi Adrien, could you distil this to a minimal test file and submit in
> a
> > bug
> > >> report and include relevant report and report parameters? C
> > >>
> > >> On 16 Feb 2018 10:09, "Adrien Monteleone" <
> adrien.montele...@gmail.com>
> > >> wrote:
> > >>
> > >>> How timely.
> > >>>
> > >>> Any way to solve this or do I just chalk it up?
> > >>>
> > >>> Regards,
> > >>> Adrien
> > >>>
> > >>>> On Feb 15, 2018, at 8:00 PM, David Carlson <
> > david.carlson@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>> If you have multiple currencies  or if you buy and sell commodities
> or
> > >>> securities  there is another level of opportunities for issues.
> > >>>>
> > >>>> David  C
> > >>>>
> > >>>> On Feb 15, 2018 5:55 PM, "Adrien Monteleone" <
> > >>> adrien.

Re: Scope of GNUCash

2018-02-16 Thread Christopher Lam

Hi Matt

Thank you very much for documentation efforts.

FWIW I still prefer virtual transactions which are ridiculously easy to 
generate, and to keep up to date. The challenge is not technical, but 
it's the mindshare. I've sat through YNAB videos long enough to 
understand how it works. It is also a very optional feature that not 
everyone needs to use. e.g. I never void transactions nor bother with 
clearing balances; for me reconciled balances are sufficient.


Subaccounts will have an unfortunate consequence of being real 
transactions in real accounts, which will calculate real balances, need 
to match real bank statements, affect real reports.



On 14/02/18 12:46, Matt Graham wrote:

Not sure why you think I’m one  of the “demanding” people... I’m not actually 
asking for anything – I’m trying to figure out how this all works, what I 
really need, and how I can contribute to make it happen I don’t expect 
anything specific from the core dev group – I just want to fit in with their 
plans.

I am not sure why you think I’m defining the scope for anyone in these emails I 
started this thread asking what the scope is (triggered because you keep telling me 
that all the stuff I’m interested in is out of scope...). I don’t expect to get a say 
– I just thought there would be something that states it so that I can admit you are 
right (and stop focussing on that) or get you to stop saying that things people want 
to do “isn’t what GNUcash is for”. (Note: “We haven’t had time to implement that and 
probably wont get time” is a very different statement from “we won’t implement that 
because that isn’t what GNUCash is for”. The former => no worries I’ll help out if 
I can to get it to happen. Until then, I’ll make do. The latter => No worries, 
I’ll figure out a way to do it out of GNUCash and I’ll stop asking about it. Again: 
I’M NOT DEMANDING ANYTHING – I’M TRYING TO UNDERSTAND.

So based on the questions I’m asking you (running around in circles?), I’m 
pretty confident I’m missing a lot of your points. I’ve read through a lot of 
the text accounting references you gave me a while ago about budgeting And 
it all seems pretty much in line with what Chris L and I were talking about 
ages ago. I was thinking along the lines of envelope budgeting with 
sub-accounts and tools to help that. Chris was talking about virtual 
transactions and how that would work. Both are described in various wiki’s and 
help docs found off the plain text accounting budgeting area: 
http://plaintextaccounting.org/#budgeting. So if I understand your point, you 
are saying that I should be exporting my accounts to text, then using another 
program to implement such a system?

   1.  I would rather use GNUCash over the plaintext tools if it is an option. 
Mainly because of the convenience in layout, display and interaction with my 
data. GNUCash it already gives somewhere between 70-85% of what I would 
need/want from the ideal.
   2.  I could spend my time learning the command line tools. or I could 
spend my time helping out with GNUCash to build in the functionality I want 
(and evidently lots of other people want – but I don’t say any of this meaning 
the dev’s should do it for me. I say it to fend off your constant assertion: 
“that’s not what GNUCash is for!!!”. I’m still confused on what you think 
GNUCash should be for).
   3.  If I am supposed to export from GNUcash regularly and then import to the 
command line tool to do stuff I’ll regularly want to do... then why wouldn’t I 
just use the command line tool for everything? Based on what you say, why do 
you use GNUCash at all??? What can it do that the command line tools can’t?

For David T: What I’m planning to put into the Tut and Concepts at the moment 
is a description of how to use sub-accounts for envelope budgeting – Similar to 
the “Poor Postgrad System” in this link (but for GNUCash): 
https://memo.barrucadu.co.uk/2018-budget.html

I hope I’m not being unreasonable (or being misunderstood) in all my posts. I 
am very grateful for the functionality and capability that GNUcash already has, 
and hopefully people aren’t getting offended when I ask my questions.
Is it unreasonable to always be looking for a better way of doing things???

Thanks and regards,

Matt

From: Wm via gnucash-devel
Sent: Wednesday, 14 February 2018 11:35 AM
To: gnucash-de...@lists.gnucash.org
Subject: Re: Scope of GNUCash

On 13/02/2018 21:53, Matt Graham wrote:

😊 I think I would love to sit down in a pub with the three of you (Wm, Adrien, 
and Mike). I think we could have such awesome semi-drunken discussions about 
the nature of life, the universe and everything!

I'm in London. Mike is in a Trump voting bit of Merka. Don't know where
Adrien is and he shouldn't have to say.

Accounting is a way of measuring life.  Happiness is harder to quantify.
   Life should be enjoyable and measuring money sh

Re: [GNC-dev] [GNC] Gnucash 3.1 crashes on Windows 10 while loading Reports-Gnome

2018-04-29 Thread Christopher Lam

Hi Peter

Just putting out there... Which part of the Consolidated Transaction 
Report is particularly useful?


I think the Transaction Report 3.1 can be augmented to support some of 
them...


HTH


On 30/04/18 05:58, John Ralls wrote:



On Apr 29, 2018, at 12:28 PM, Peter Jackson  wrote:

Thank you for v 3.1, which on a clean install, opens my gnucash file and
runs perfectly.
However, if I install it over my existing 2.6.21 application, v3.1 crashes
as it is loading ./Reports-Gnome.
Of course I want to be able to do this so that I can run my Saved Reports,
especially Cindy's excellent Consolidated Transaction report.
Will the ability to install over 2.6.21 and convert the reports be
addressed in a later release?

Sounds like the Doughty reports aren't compatible with the changes in GnuCash's 
API; I'd guess that it has to do with date handling. They're not part of 
GnuCash and the GnuCash development team doesn't support them. Since nothing 
has been heard from the author in almost a year it seems that they're not 
interested in supporting the reports either. Sorry.

Regards,
John Ralls


___
gnucash-user mailing list
gnucash-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Gnucash 3.1 crashes on Windows 10 while loading Reports-Gnome

2018-04-30 Thread Christopher Lam
Hi Peter

If you're comfortable patching transaction.scm, here are the changes to
enable grouping/subtotals according to either memo or notes.

(Not thoroughly tested)

C


On 30 April 2018 at 14:34, Peter Jackson  wrote:

> Essentially,
> 1) Primary Key = Memo/Notes
> 2) Sort on Primary Key
> 3) Consolidate Transactions over selected period. The Standard Gnucash
> Period offering is fine.
>
> Regards
>
> Peter
>
>
> On 29 April 2018 at 23:22, Christopher Lam 
> wrote:
>
>> Hi Peter
>>
>> Just putting out there... Which part of the Consolidated Transaction
>> Report is particularly useful?
>>
>> I think the Transaction Report 3.1 can be augmented to support some of
>> them...
>>
>> HTH
>>
>>
>> On 30/04/18 05:58, John Ralls wrote:
>>
>>>
>>> On Apr 29, 2018, at 12:28 PM, Peter Jackson 
>>>> wrote:
>>>>
>>>> Thank you for v 3.1, which on a clean install, opens my gnucash file and
>>>> runs perfectly.
>>>> However, if I install it over my existing 2.6.21 application, v3.1
>>>> crashes
>>>> as it is loading ./Reports-Gnome.
>>>> Of course I want to be able to do this so that I can run my Saved
>>>> Reports,
>>>> especially Cindy's excellent Consolidated Transaction report.
>>>> Will the ability to install over 2.6.21 and convert the reports be
>>>> addressed in a later release?
>>>>
>>> Sounds like the Doughty reports aren't compatible with the changes in
>>> GnuCash's API; I'd guess that it has to do with date handling. They're not
>>> part of GnuCash and the GnuCash development team doesn't support them.
>>> Since nothing has been heard from the author in almost a year it seems that
>>> they're not interested in supporting the reports either. Sorry.
>>>
>>> Regards,
>>> John Ralls
>>>
>>>
>>> ___
>>> gnucash-user mailing list
>>> gnucash-u...@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.
>>>
>>
>>
>
diff --git a/gnucash/report/standard-reports/transaction.scm b/gnucash/report/standard-reports/transaction.scm
index 6dbb8945a..c6d050abf 100644
--- a/gnucash/report/standard-reports/transaction.scm
+++ b/gnucash/report/standard-reports/transaction.scm
@@ -117,11 +117,13 @@ in the Options panel."))
 ;; which a subtotal should be enabled.
 (define SUBTOTAL-ENABLED (list 'account-name 'corresponding-acc-name
'account-code 'corresponding-acc-code
+   'memo 'notes
'reconciled-status))
 
 (define ACCOUNT-SORTING-TYPES (list 'account-name 'corresponding-acc-name
 'account-code 'corresponding-acc-code))
-(define CUSTOM-SORTING (list 'reconciled-status))
+
+(define CUSTOM-SORTING (list 'notes 'reconciled-status))
 
 (define SORTKEY-INFORMAL-HEADERS (list 'account-name 'account-code))
 
@@ -227,10 +229,16 @@ in the Options panel."))
(cons 'renderer-fn #f)))
 
 (cons 'memo  (list (cons 'sortkey (list SPLIT-MEMO))
-   (cons 'split-sortvalue #f)
+   (cons 'split-sortvalue (lambda(a) (xaccSplitGetMemo a)))
(cons 'text (_ "Memo"))
(cons 'tip (_ "Sort by memo."))
-   (cons 'renderer-fn #f)))
+   (cons 'renderer-fn (lambda (a) (xaccSplitGetMemo a)
+
+(cons 'notes (list (cons 'sortkey #f)
+   (cons 'split-sortvalue (lambda (a) (xaccTransGetNotes (xaccSplitGetParent a
+   (cons 'text (_ "Notes"))
+   (cons 'tip (_ "Sort by notes."))
+   (cons 'renderer-fn (lambda (a) (xaccTransGetNotes (xaccSplitGetParent a))
 
 (cons 'none  (list (cons 'sortkey '())

Re: [GNC-dev] [GNC] Gnucash 3.1 crashes on Windows 10 while loading Reports-Gnome

2018-04-30 Thread Christopher Lam
Hi Peter, the amended report will unlock subtotals and grouping for memo
and notes, so, just tick subtotals and see?

On Tue, 1 May 2018, 14:16 Peter Jackson  wrote:

> Dear Chris,
> Thank you. I have replaced the previous transaction.scm in C:\Program
> Files (x86)\gnucash\share\gnucash\scm\gnucash\report\standard-reports. I
> restarted Gnucash.
> Unfortunately I can discern no change in the Report Options.
> Do I need to do something else?
> Peter
>
>
> Nurton Court
> Middleton-on-the-Hill
> Ludlow SY8 4BD
> Tel: 01568 750 248 Mob: 07955 586 476
>
> On 30 April 2018 at 22:33, Christopher Lam 
> wrote:
>
>> HTH
>>
>> On 01/05/18 05:14, Peter Jackson wrote:
>>
>> Dear Chris, I'm sorry, this is beyond my skills. A simple cut and paste,
>> I can do. Is it possible you could send the modified transaction.scm
>> I'm happy to test it.
>> Regards
>> Peter
>>
>> Tel: 01568 750248 <01568%20750248>
>> Mob: 07955 586476 <07955%20586476>
>>
>> -- Original message--
>> *From: *Christopher Lam
>> *Date: *Mon, 30 Apr 2018 15:27
>> *To: *Peter Jackson;
>> *Cc: *gnucash-devel@gnucash.org;
>> *Subject:*Re: [GNC] Gnucash 3.1 crashes on Windows 10 while loading
>> Reports-Gnome
>>
>> Hi Peter
>>
>> If you're comfortable patching transaction.scm, here are the changes to
>> enable grouping/subtotals according to either memo or notes.
>>
>> (Not thoroughly tested)
>>
>> C
>>
>>
>> On 30 April 2018 at 14:34, Peter Jackson  wrote:
>>
>>> Essentially,
>>> 1) Primary Key = Memo/Notes
>>> 2) Sort on Primary Key
>>> 3) Consolidate Transactions over selected period. The Standard Gnucash
>>> Period offering is fine.
>>>
>>> Regards
>>>
>>> Peter
>>>
>>>
>>> On 29 April 2018 at 23:22, Christopher Lam 
>>> wrote:
>>>
>>>> Hi Peter
>>>>
>>>> Just putting out there... Which part of the Consolidated Transaction
>>>> Report is particularly useful?
>>>>
>>>> I think the Transaction Report 3.1 can be augmented to support some of
>>>> them...
>>>>
>>>> HTH
>>>>
>>>>
>>>> On 30/04/18 05:58, John Ralls wrote:
>>>>
>>>>>
>>>>> On Apr 29, 2018, at 12:28 PM, Peter Jackson 
>>>>>> wrote:
>>>>>>
>>>>>> Thank you for v 3.1, which on a clean install, opens my gnucash file
>>>>>> and
>>>>>> runs perfectly.
>>>>>> However, if I install it over my existing 2.6.21 application, v3.1
>>>>>> crashes
>>>>>> as it is loading ./Reports-Gnome.
>>>>>> Of course I want to be able to do this so that I can run my Saved
>>>>>> Reports,
>>>>>> especially Cindy's excellent Consolidated Transaction report.
>>>>>> Will the ability to install over 2.6.21 and convert the reports be
>>>>>> addressed in a later release?
>>>>>>
>>>>> Sounds like the Doughty reports aren't compatible with the changes in
>>>>> GnuCash's API; I'd guess that it has to do with date handling. They're not
>>>>> part of GnuCash and the GnuCash development team doesn't support them.
>>>>> Since nothing has been heard from the author in almost a year it seems 
>>>>> that
>>>>> they're not interested in supporting the reports either. Sorry.
>>>>>
>>>>> Regards,
>>>>> John Ralls
>>>>>
>>>>>
>>>>> ___
>>>>> gnucash-user mailing list
>>>>> gnucash-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Gnucash 3.1 crashes on Windows 10 while loading Reports-Gnome

2018-05-01 Thread Christopher Lam

Hi Peter

This is because of two different issues:

1) the Description grouping/sorting was not really enabled in the 
previous patch. Try this new one. I think Description grouping/subtotals 
is reasonable (e.g. group/subtotals all 'Water Bills', 'Mortgage 
Repayments').


2) Primary=Memo will not necessarily sort by the "Memo/Notes" column, 
which is a complex display of split->memo, or split->transaction->notes 
if memo was blank. Moreover, technically, the default sorter needs to be 
disabled and a custom sorter used for Notes sorting. Hence I have 
reservations about enabling grouping/subtotals for Notes/Memo.


This version will enable sorting/grouping for all Description, Notes, or 
Memo. Seems to work well on mine.


Feedback still welcome!


On 01/05/18 16:27, Peter Jackson wrote:

Dear Chris, I feel guilty taking up your time, but..
I have re-booted to ensure all is clear.
To keep it simple. I have set Primary Key as Description, and 
Secondary as Date (altho' not displaying date)

Date is sorted Alpahbetically Description and Amount displaying.
I have tried ticking most combinations of boxes, including Subtotal 
Table, and Show Subtotal Only on the
Sort Tab. I still can see no difference in the Options offered and no 
way to provide a Subtotal for each discrete Description.

If I set Primary as Memo, it doesn't sort alphabetically.
In short, Gnucash is not recognising the changes in transaction.scm.
I can find no config.user. Does v3.1 need this?
Regards
Peter



Nurton Court
Middleton-on-the-Hill
Ludlow SY8 4BD
Tel: 01568 750 248 Mob: 07955 586 476

On 1 May 2018 at 07:21, Christopher Lam <mailto:christopher@gmail.com>> wrote:


Hi Peter, the amended report will unlock subtotals and grouping
for memo and notes, so, just tick subtotals and see?

On Tue, 1 May 2018, 14:16 Peter Jackson mailto:p...@nurtoncourt.net>> wrote:

Dear Chris,
Thank you. I have replaced the previous transaction.scm in
C:\Program Files
(x86)\gnucash\share\gnucash\scm\gnucash\report\standard-reports.
I restarted Gnucash.
Unfortunately I can discern no change in the Report Options.
Do I need to do something else?
Peter


Nurton Court
Middleton-on-the-Hill
Ludlow SY8 4BD
Tel: 01568 750 248 Mob: 07955 586 476

On 30 April 2018 at 22:33, Christopher Lam
mailto:christopher@gmail.com>>
wrote:

HTH


On 01/05/18 05:14, Peter Jackson wrote:

Dear Chris, I'm sorry, this is beyond my skills. A simple
cut and paste, I can do. Is it possible you could send
the modified transaction.sc <http://transaction.sc>m
I'm happy to test it.
Regards
Peter

Tel: 01568 750248 
Mob: 07955 586476 

-- Original message--
*From: *Christopher Lam
*Date: *Mon, 30 Apr 2018 15:27
*To: *Peter Jackson;
*Cc: *gnucash-devel@gnucash.org
<mailto:gnucash-devel@gnucash.org>;
*Subject:*Re: [GNC] Gnucash 3.1 crashes on Windows 10
while loading Reports-Gnome

Hi Peter

If you're comfortable patching transaction.sc
<http://transaction.sc>m, here are the changes to enable
grouping/subtotals according to either memo or notes.

(Not thoroughly tested)

C



On 30 April 2018 at 14:34, Peter Jackson
mailto:jack...@fastmail.net>> wrote:

Essentially,
1) Primary Key = Memo/Notes
2) Sort on Primary Key
3) Consolidate Transactions over selected period. The
Standard Gnucash Period offering is fine.

Regards

Peter


On 29 April 2018 at 23:22, Christopher Lam
mailto:christopher@gmail.com>> wrote:

Hi Peter

Just putting out there... Which part of the
Consolidated Transaction Report is particularly
useful?

I think the Transaction Report 3.1 can be
augmented to support some of them...

HTH


On 30/04/18 05:58, John Ralls wrote:


On Apr 29, 2018, at 12:28 PM, Peter
Jackson mailto:jack...@fastmail.net>> wrote:

Thank you for v 3.1, which on a clean
install, opens my gnucash file and
runs perfectly.
However, if I install it over my existing
2.6.21 application, v3.1 crashes
  

[GNC-dev] pricedb policy

2018-05-13 Thread Christopher Lam
Hi Devs

I wish to enquire about policy on pricedb.

As far as I can understand, pricedb receives entries from 3 different
sources:

1. from entering transactions into the register, if the transaction
involves a foreign currency conversion or stock. e.g. originating account
is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
determine which one is deemed to be the base currency). These pricedb
entries are tagged "user:price" or "user:xfer-dialog".

2. from online sources eg alphavantage. This requires careful setup, and
seems to create price entries for all foreign currencies / commodities,
compared to the book currency (in my case AUD). These are tagged
"Finance::Quote".

3. entries added by the user. These are tagged "user:price-editor".

>From my review of code so far, pricedb entries are rather important in
reports... an incorrect pricedb entry will lead to incorrect foreign
currency reporting, even if the transaction contains the exact transfer
amount.

My concerns relate to (1) above. I believe these transactional prices are
always more accurate than online quotes, because they describe the exact
prices achieved.

But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
same day, the second entered price will overwrite the first. (<- according
to my last test)

I'd think it would be important for accuracy that, upon book opening, and
Check&Repair, the user:price data should be *overwritten* by the actual
prices obtained from the transactions. Moreover if there are several
transactions involving commodities, Check&Repair should **add** relevant
amounts to ensure accurate pricing.

e.g.
01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)

should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)

Unfortunately I don't do C so cannot help with coding, but would think that*
the "user:price" prices should *always* be regenerated from the transaction
amounts during Check & Repair and upon loading datafile.*

Thoughts?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] pricedb policy

2018-05-13 Thread Christopher Lam

I'm sorry there's no complication.

There's no such thing as "price source was not correct" while entering a 
transaction.


Let's say I transfer 100 GBP to 150 USD, currently generating a pricedb 
entry of GBP/USD=1.5, later "realize" the price source was incorrect and 
should have been GBP/USD=1.6, it would mean that the USD expense or 
account would not have received $150USD in the first place, causing all 
sorts of USD imbalances or incomplete funds for purchase.


My view is that "user:price"-type pricedb entries are usually directly 
generated from transactional transfers, therefore can be considered a 
lookup-table for existing transfers, and should not be user-editable.



On 13/05/18 22:20, Adrien Monteleone wrote:

Christopher,

I’ll add a complication for you.

Suppose one enters a transaction and later realizes the price source was not 
correct.

Does editing the originally generated user:price affect the transactions in the 
register? Are they in-sync or now unrelated?

If editing user:price does not change the register, does that mean you have to 
edit the register entries (or use correcting entries) and if so, does this 
alter the original user:price? (or add another?)

If the two get out of sync, how do you determine what is the true source to use to 
regenerate upon loading and Check&Repair?

Regards,
Adrien


On May 13, 2018, at 5:34 AM, Christopher Lam  wrote:

Hi Devs

I wish to enquire about policy on pricedb.

As far as I can understand, pricedb receives entries from 3 different
sources:

1. from entering transactions into the register, if the transaction
involves a foreign currency conversion or stock. e.g. originating account
is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
determine which one is deemed to be the base currency). These pricedb
entries are tagged "user:price" or "user:xfer-dialog".

2. from online sources eg alphavantage. This requires careful setup, and
seems to create price entries for all foreign currencies / commodities,
compared to the book currency (in my case AUD). These are tagged
"Finance::Quote".

3. entries added by the user. These are tagged "user:price-editor".

 From my review of code so far, pricedb entries are rather important in
reports... an incorrect pricedb entry will lead to incorrect foreign
currency reporting, even if the transaction contains the exact transfer
amount.

My concerns relate to (1) above. I believe these transactional prices are
always more accurate than online quotes, because they describe the exact
prices achieved.

But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
same day, the second entered price will overwrite the first. (<- according
to my last test)

I'd think it would be important for accuracy that, upon book opening, and
Check&Repair, the user:price data should be *overwritten* by the actual
prices obtained from the transactions. Moreover if there are several
transactions involving commodities, Check&Repair should **add** relevant
amounts to ensure accurate pricing.

e.g.
01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)

should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)

Unfortunately I don't do C so cannot help with coding, but would think that*
the "user:price" prices should *always* be regenerated from the transaction
amounts during Check & Repair and upon loading datafile.*

Thoughts?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] pricedb policy

2018-05-13 Thread Christopher Lam
Thank you.

Hence my RFC about whether "user:price" entries in pricedb should be
considered as a lookup-table to the actual prices achieved in transactions,
and should be subject to Check&Repair fixing. I'm sure the reports will
then fix themselves if they can rely on pricedb being accurate.

IMHO if a transaction had documented an incorrect asset price, the
values/amounts should be amended. If I'd overvalued my house in
Equity:Opening Balances, I'd just go and amend the amounts.

Perhaps I'll whip out a .scm to look at the prices and (optionally) offer
to fix any discrepancies.

In future perhaps reports can offer use pricedb entries in a customizable
hierarchy - Finance::Quote prices, user:price, user:price-editor.

On 14 May 2018 at 00:56, David T. via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> The ONLY way to change the value in a transaction is to change it in the
> transaction itself—either by changing the number of shares, the actual
> price per share, or the total amount in the transaction (and note that the
> UI will ask you about this if you change one without changing the others).
> The price db doesn’t and shouldn’t push changes into existing real
> transactions.
>
> Changing the valuation in a transaction based on a price db change is the
> path to madness.
>
> The price db is for reporting on potential valuation. The transactions
> represent what actually happened. If I paid $100 for 10 shares of ABC
> stock, it doesn’t matter that the going price for ABC on the same day is $1
> per share—I’m still out $100 (and pretty gullible, too, I’d say).
>
> David T.
>
>
> > On May 13, 2018, at 7:20 PM, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> >
> > Christopher,
> >
> > I’ll add a complication for you.
> >
> > Suppose one enters a transaction and later realizes the price source was
> not correct.
> >
> > Does editing the originally generated user:price affect the transactions
> in the register? Are they in-sync or now unrelated?
> >
> > If editing user:price does not change the register, does that mean you
> have to edit the register entries (or use correcting entries) and if so,
> does this alter the original user:price? (or add another?)
> >
> > If the two get out of sync, how do you determine what is the true source
> to use to regenerate upon loading and Check&Repair?
> >
> > Regards,
> > Adrien
> >
> >> On May 13, 2018, at 5:34 AM, Christopher Lam 
> wrote:
> >>
> >> Hi Devs
> >>
> >> I wish to enquire about policy on pricedb.
> >>
> >> As far as I can understand, pricedb receives entries from 3 different
> >> sources:
> >>
> >> 1. from entering transactions into the register, if the transaction
> >> involves a foreign currency conversion or stock. e.g. originating
> account
> >> is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
> (can't
> >> determine which one is deemed to be the base currency). These pricedb
> >> entries are tagged "user:price" or "user:xfer-dialog".
> >>
> >> 2. from online sources eg alphavantage. This requires careful setup, and
> >> seems to create price entries for all foreign currencies / commodities,
> >> compared to the book currency (in my case AUD). These are tagged
> >> "Finance::Quote".
> >>
> >> 3. entries added by the user. These are tagged "user:price-editor".
> >>
> >> From my review of code so far, pricedb entries are rather important in
> >> reports... an incorrect pricedb entry will lead to incorrect foreign
> >> currency reporting, even if the transaction contains the exact transfer
> >> amount.
> >>
> >> My concerns relate to (1) above. I believe these transactional prices
> are
> >> always more accurate than online quotes, because they describe the exact
> >> prices achieved.
> >>
> >> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on
> the
> >> same day, the second entered price will overwrite the first. (<-
> according
> >> to my last test)
> >>
> >> I'd think it would be important for accuracy that, upon book opening,
> and
> >> Check&Repair, the user:price data should be *overwritten* by the actual
> >> prices obtained from the transactions. Moreover if there are several
> >> transactions involving commodities, Check&Repair should **add** relevant
> >> amounts to ensure accurate pricing.
> >

Re: [GNC-dev] pricedb policy

2018-05-14 Thread Christopher Lam
Here you go, a prices-report.scm which can be dropped into standard-reports
folder and adds a rudimentary forex analysis. If rebuilding you'll need to
add onto CMakeLists.txt as well.

It scans *only* transactions which involve 2 different commodities. eg
GBP<->EUR or AAPL<->USD.

It calculates and displays the exact price ratio achieved in the particular
transaction, and also finds the nearest pricedb entry applicable for that
date between the two commodities.

It does not modify the datafile, nor pricedb. It ignores any brokerage fees.

For illustration/entertainment only.
(define-module (gnucash report standard-reports prices-report))

(use-modules (gnucash utilities))
(use-modules (srfi srfi-1))
(use-modules (srfi srfi-11))
(use-modules (srfi srfi-13))
(use-modules (gnucash gnc-module))
(use-modules (gnucash gettext))

(gnc:module-load "gnucash/report/report-system" 0)

(define reportname (N_ "Prices Report"))

(define (options-generator)
  (let ((options (gnc:new-options)))
options))

(define (gnc-account-child-accounts-recursive account)
  (let loop ((account account)
 (initial '()))
(fold (lambda (child-account accumulator)
(append (loop child-account (list child-account))
accumulator))
  initial
  (gnc-account-get-children account

(define (split->splits split)
  (xaccTransGetSplitList
   (xaccSplitGetParent split)))

(define (split->commodities split)
  (delete-duplicates
   (map split->commodity (split->splits split))
   gnc-commodity-equal))

(define (split->commodity split)
  (xaccAccountGetCommodity (xaccSplitGetAccount split)))

(define (split-get-exact-ratio split)
  (let* ((splits (split->splits split))
 (split-1 (car splits))
 (split-2 (cadr splits)))
(/ (xaccSplitGetAmount split-1)
   (xaccSplitGetAmount split-2

(define (split-describe split op)
  (let* ((sp (op (split->splits split
(gnc:make-gnc-monetary (split->commodity sp) (xaccSplitGetAmount sp
  
(define (prices-renderer report-obj)
  ;; (define options (gnc:report-options report-obj))
  (gnc:report-starting reportname)
  (let* ((document (gnc:make-html-document))
 (accounts (gnc-account-child-accounts-recursive
(gnc-get-current-root-account)))
 (query (qof-query-create-for-splits)))
(qof-query-set-book query (gnc-get-current-book))
(xaccQueryAddAccountMatch query accounts QOF-GUID-MATCH-ANY QOF-QUERY-AND)
(xaccQueryAddDateMatchTT query #f 0 #f 0 QOF-QUERY-AND)
(gnc:query-set-match-non-voids-only! query (gnc-get-current-book))
(qof-query-set-sort-order query (list SPLIT-TRANS TRANS-DATE-POSTED) '() '())
(qof-query-set-sort-increasing query #t #t #t)

(let ((splits (xaccQueryGetSplitsUniqueTrans query)))
  (qof-query-destroy query)

  (if (null? splits)

  (gnc:html-document-add-object!
   document
   (gnc:html-make-generic-warning
reportname (gnc:report-id report-obj)
"Empty Book" "Cannot find any transactions"))

  (let ((rep (gnc:make-html-table))
(splits-with-prices (filter
 (lambda (split)
   (= 2 (length
 (split->commodities split
 splits)))

(gnc:html-document-set-title! document reportname)

(for-each
 (lambda (split)
   (gnc:html-table-append-row!
rep
(list

 (qof-print-date (xaccTransGetDate (xaccSplitGetParent split)))

 (gnc:html-transaction-anchor (xaccSplitGetParent split) "Transferring")

 (split-describe split car)
 "and"
 (split-describe split cadr)

 "exact price is"
 (split-get-exact-ratio split)

 (string-join (map gnc-commodity-get-mnemonic (split->commodities split)) "/")

 "and nearest pricedb is"
 (let ((price (gnc-pricedb-lookup-nearest-in-time64 (gnc-pricedb-get-db (gnc-get-current-book))
(cadr (split->commodities split))
(car (split->commodities split))
(xaccTransGetDate (xaccSplitGetParent split

   (val (gnc:exchange-by-pricedb-nearest (gnc:make-gnc-monetary (cadr (split->commodities split)) 1)
   (car (split->commodities split))
   (xaccTransGetDate (xaccSplitGetParent split)
   (if (null? price)
   "missing"
   (gnc:html-price-anchor price val

Re: [GNC-dev] Ubuntu. Both guile-2.0 and guile-2.2 installed, can't find guile-2.2

2018-05-17 Thread Christopher Lam
As it turns out, thanks to #guile, I found out I had to 'sudo apt 
install guile-2.2-dev' to properly get the right guile-2.2.


C


On 11/05/18 21:29, Christopher Lam wrote:

As per subject.

Having successfully worked on guile-2.0, I wished to try 2.2 and 'sudo 
apt install guile-2.2' and all was well. I can run guile-2.2.


However cmake rebuild script cannot find guile-2.2 and tries to 
configure with guile-2.0 instead.


However the test suite runs using guile-2.2 and obviously fails.

I think the CMake guile-2.0/2.2 detector can't handle having both.

Any clues?

Attached logfile from cmake... && cd build && ninja && ninja check



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] feature request, select all on reconcille

2018-05-19 Thread Christopher Lam
I believe it'll be gnc-window-reconcile-ui.xml in gnucash/ui but no idea
how to modify it either. Not a glade file.

On 20 May 2018 at 08:46, Dennis Powless  wrote:

> Ok, yes it would seem glade is much, much easier.  However, I was not able
> to open window-reconcile.c in glade, am I missing something?  I thought
> that was a gtk output? I'll look over some of the gnucash pages,
> https://wiki.gnucash.org/wiki/Development_Process for background to get up
> to speed.  Forgive me if I'm asking obvious questions, but i'll come along
> with some coaching (or directing to documentation).
>
> Are there any other specific prerequisites I need to learn?
>
> I'll have to sign up for GIT and learn about that too.
>
>
> Dennis
>
>
> On Sat, May 19, 2018 at 4:05 PM, Geert Janssens <
> geert.gnuc...@kobaltwit.be>
> wrote:
>
> > Op zaterdag 19 mei 2018 21:17:56 CEST schreef Dennis Powless:
> > > I've looked over window-reconcile.c and see the section on the menus.
> > >
> > > Odd question, how do I actually learn how to do this.  I've read up on
> > gtk,
> > > glade and see in the code where the menu items are coded.
> > >
> > > Do I edit the actual file via gedit (geany) or do I use glade?  I'm
> sure
> > I
> > > can learn the language to edit the file, but is there another easier
> way,
> > > seems glade would be this?
> >
> > The easiest way to alter glade files is to use the glade tool indeed. The
> > downside of this tool it that its changes are fairly noisy which makes
> > diffs
> > hard to decipher. But that something we have to live with.
> >
> > >
> > > Do you think the 'select all' should be a menu item in a drop down (say
> > the
> > > reconcile top level menu?) or on the menu bar as a stand alone button?
> > >
> > I would prefer to add it to the reconcile top level menu.
> >
> > > Maybe point me in the correct location to discuss this?
> >
> > The proper channel to discuss this is the gnucash-devel mailing list. I
> > have
> > redirected my reply there. You can follow up on that list.
> >
> > > I know it's a
> > > steep learning curve, but I do have some experience with doing code,
> just
> > > not this language.
> > >
> > > I want to help out with this project and feel I can do some things to
> > help
> > > out once I figure some of it out.
> >
> > That's appreciated. We can always use some help.
> >
> > If you manage to get a working change, please create a git pull request
> on
> > the
> > maint branch. You may want to read our wiki pages on git and development
> > process for more background as well.
> >
> > Good luck and have fun!
> >
> > Geert
> >
> >
> >
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] pricedb policy

2018-05-27 Thread Christopher Lam
Thanks John... For some reason Gmail had classified all direct emails as
spam so I've effectively missed a lot of similar official replies 😓

On Mon, 14 May 2018, 11:01 John Ralls  wrote:

> The hierarchy is user:price/user:xfer-dialog<-F::Q<-user:price-editor for
> the reason I explained.
>
> One more time: No, the user:price entries in the pricedb should ***NOT***
> be considered a lookup table to the actual prices in transactions. If you
> want the actual prices in transactions (actually splits, transactions don’t
> have any amounts or values) then *go look at the splits*. If for some
> reason you need to cache the prices then cache the prices. Don’t overload
> the pricedb for a purpose for which it’s not designed.
>
> Regards,
> John Ralls
>
>
> > On May 13, 2018, at 6:19 PM, Christopher Lam 
> wrote:
> >
> > Thank you.
> >
> > Hence my RFC about whether "user:price" entries in pricedb should be
> > considered as a lookup-table to the actual prices achieved in
> transactions,
> > and should be subject to Check&Repair fixing. I'm sure the reports will
> > then fix themselves if they can rely on pricedb being accurate.
> >
> > IMHO if a transaction had documented an incorrect asset price, the
> > values/amounts should be amended. If I'd overvalued my house in
> > Equity:Opening Balances, I'd just go and amend the amounts.
> >
> > Perhaps I'll whip out a .scm to look at the prices and (optionally) offer
> > to fix any discrepancies.
> >
> > In future perhaps reports can offer use pricedb entries in a customizable
> > hierarchy - Finance::Quote prices, user:price, user:price-editor.
> >
> > On 14 May 2018 at 00:56, David T. via gnucash-devel <
> > gnucash-devel@gnucash.org> wrote:
> >
> >> The ONLY way to change the value in a transaction is to change it in the
> >> transaction itself—either by changing the number of shares, the actual
> >> price per share, or the total amount in the transaction (and note that
> the
> >> UI will ask you about this if you change one without changing the
> others).
> >> The price db doesn’t and shouldn’t push changes into existing real
> >> transactions.
> >>
> >> Changing the valuation in a transaction based on a price db change is
> the
> >> path to madness.
> >>
> >> The price db is for reporting on potential valuation. The transactions
> >> represent what actually happened. If I paid $100 for 10 shares of ABC
> >> stock, it doesn’t matter that the going price for ABC on the same day
> is $1
> >> per share—I’m still out $100 (and pretty gullible, too, I’d say).
> >>
> >> David T.
> >>
> >>
> >>> On May 13, 2018, at 7:20 PM, Adrien Monteleone <
> >> adrien.montele...@lusfiber.net> wrote:
> >>>
> >>> Christopher,
> >>>
> >>> I’ll add a complication for you.
> >>>
> >>> Suppose one enters a transaction and later realizes the price source
> was
> >> not correct.
> >>>
> >>> Does editing the originally generated user:price affect the
> transactions
> >> in the register? Are they in-sync or now unrelated?
> >>>
> >>> If editing user:price does not change the register, does that mean you
> >> have to edit the register entries (or use correcting entries) and if so,
> >> does this alter the original user:price? (or add another?)
> >>>
> >>> If the two get out of sync, how do you determine what is the true
> source
> >> to use to regenerate upon loading and Check&Repair?
> >>>
> >>> Regards,
> >>> Adrien
> >>>
> >>>> On May 13, 2018, at 5:34 AM, Christopher Lam <
> christopher@gmail.com>
> >> wrote:
> >>>>
> >>>> Hi Devs
> >>>>
> >>>> I wish to enquire about policy on pricedb.
> >>>>
> >>>> As far as I can understand, pricedb receives entries from 3 different
> >>>> sources:
> >>>>
> >>>> 1. from entering transactions into the register, if the transaction
> >>>> involves a foreign currency conversion or stock. e.g. originating
> >> account
> >>>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
> >> (can't
> >>>> determine which one is deemed to be the base currency). These pricedb
> >>>> entries are tagged "user:price" or

Re: [GNC-dev] Report System Rework

2018-06-10 Thread Christopher Lam
Any rework will require stabilising the reports first, removing
unintelligible hacks, and updating to modern scheme (which is now
approaching V8 quality and speed). The current state of report code
reflects the tooling available about 20 years ago.

So the following will be on the TODO list before any foundation changes:

1. creating good tests for majority of reports
2. removing hacks and shortcuts, debugging opportunistically
3. obsoleting old reports (such as eguile )
4. modernising stylesheets (removing/merging plain/header+footer/etc)?
5. designing more modern access to data, either yaml/json/REST

For now the reports will necessarily be limited in interactivity; Input via
Report Options, and Output via HTML. Anything else is for now just a pipe
dream!

On 8 June 2018 at 04:42, Phil Longstaff  wrote:

> I don't know how it fits into this rework, but I would like to see a more
> general framework which supports reports with 'items' down the side and
> 'periods' across the top. I put them in quotes because they are a bit
> general. I've worked with an accounting system in the past which allowed
> general reports to be created. In this case, 'items' could be text strings
> (e.g. 'Income'), could be a filter for accounts (all accounts of type
> 'Income'), could be a total or subtotal row ('Total income'). Across the
> top, for 'periods', you could have real periods for an income statement or
> comparative income statement, or dates, for a balance sheet or comparative
> balance sheet. When I used quicken in the past, I liked being able to
> generate a balance sheet for 2015-2018 with all years' values at Jan 1.
> This allowed me to see how values had grown or decreased in certain
> accounts.
>
> On Thu, Jun 7, 2018 at 4:22 PM, John Ralls  wrote:
>
> >
> >
> > > On Jun 7, 2018, at 1:14 PM, John Ralls  wrote:
> > >
> > >
> > >
> > >> On Jun 7, 2018, at 12:49 PM, Carsten Rinke 
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >> this takes up a discussion with John and Christopher in PR#360 (and I
> > am happy to see that is was merged :-D )
> > >>
> > >> As the discussion turned away from the actual proposal of a test for
> > the report definition, I'd suggest to move it to this channel.
> > >>
> > >> John:
> > >> You were mentioning that you and Christopher are reworking the report
> > system.
> > >> I had in mind to create even more PRs with test proposals for the
> > report system (in response to Bug787401 which becomes a bit difficult now
> > that the bug is closed ;-) ) and I wonder:
> > >> Is this idea still worth while?
> > >> Do you already have an idea about what is going to change?
> > >>
> > >> Christopher:
> > >> Regarding your question below:
> > >> I think the report definition is triggered at the very beginning when
> > the moduels are loaded.
> > >> inner_main triggers libgncmod_report_gnome_gnc_module_init
> > (gncmod-report-gnome.c)
> > >> this triggers to load guile module "gnucash report standard-reports"
> > (standard-report.scm)
> > >> this triggers to load all standard  reports
> > >> this triggers that (gnc:define-report) is called per report
> > >> -> it has nothing to do with html rendering
> > >>
> > >> If you take the changes from PR#360 and comment out the report ID in
> > the call to gnc:define-report from any standard report, you will see that
> > an "ordinary" pop-up window is created.
> > >>
> > >> -Carsten
> > >>
> > >>
> > >>
> > >>  Weitergeleitete Nachricht 
> > >> Betreff: Re: [Gnucash/gnucash] Bug787401 test report definition
> > (#360)
> > >> Datum:   Thu, 07 Jun 2018 03:47:52 -0700
> > >> Von: Christopher Lam 
> > >> Antwort an:  Gnucash/gnucash  > 3bf8470a850e163f0c92cf00011730cf5892a169ce13999...@reply.github.com>
> > >> An:  Gnucash/gnucash 
> > >> Kopie (CC):  GnuFiBux , Author <
> > aut...@noreply.github.com>
> > >>
> > >>
> > >>
> > >> I can understand the need to remove gui calls but not entirely sure
> > exactly how the |(gnc:define-report)| is being called. I know they're
> being
> > triggered with every report code e.g. at the end of transaction.scm, but
> > not sure what exactly is causing the transaction.scm to be run. So, where
> >

Re: [GNC-dev] Build issues and some free testing

2018-06-12 Thread Christopher Lam
Dear rgmerk
Finally understood the use for combinatorics :)
https://github.com/Gnucash/gnucash/commit/da1d1b9a47939ad08ac645024f448a4820103ad8#diff-1625b4f2db9166674389d58f2f585131R497
SRFI-64 is now firmly established as the testing framework to be used in
Gnucash from now on.
I think transaction.scm and invoice.scm now have about 90% code coverage.
I'll add more as time goes on...
Chris

On 24 January 2018 at 11:59, John Ralls  wrote:

> Robert,
>
> Cool. If they should wind up writing some nice unit tests for areas where
> our coverage is poor (pretty much everywhere) we’ll happily and gratefully
> take them.
>
> Regards,
> John Ralls
>
> > On Jan 23, 2018, at 4:26 PM, Robert Merkel 
> wrote:
> >
> > Thanks all.
> >
> > I realised the VM I was working with was an LTS version, and upgraded to
> the most recent Ubuntu release.  Gnucash built without problems in the
> upgraded VM.
> >
> > It seems like the fixes were a good piece of housekeeping anyway.
> >
> > Just to let you know it's looking increasingly likely I'm going to have
> a bunch of students poking and prodding at gnucash some time in April.
> I'll make sure to file bug reports for any real bugs they find.  I'll ask
> them to route any questions they have through me, so it shouldn't result in
> masses of mailing list traffic.
> >
> > Regards,
> >
> > Robert.
> >
> > On Wed, 24 Jan 2018 at 11:19 John Ralls  jra...@ceridwen.us>> wrote:
> >
> >
> > > On Jan 22, 2018, at 6:56 PM, Robert Merkel  <mailto:robert.mer...@benambra.org>> wrote:
> > >
> > > Hello all.
> > >
> > > If you dig far enough into the mailing list archives or the
> changelogs, you
> > > might find me :)
> > >
> > > I spoke to Christopher Lam recently, who told me about the work he's
> been
> > > doing on the transaction report which I worked on many many years ago.
> > >
> > > These days, my day job is teaching students about software engineering
> and,
> > > this upcoming semester, I'm teaching a unit on testing and quality
> > > assurance.  For one of the assignments, we need some software for
> students
> > > to test, and I thought I might get them to test Gnucash.
> > >
> > > So, for the first time for quite a while, I have tried to download and
> > > build gnucash from the git repository using cmake.  I've found the
> > > following build issues:
> > >
> > > * The build process requires xsltproc and makeinfo, which are not
> mentioned
> > > in the dependency list and cmake doesn't seem to check for them.
> > >
> > > * The build failed on my Ubuntu machine with the stock version of
> > > libwebkit2-gtk available on that distribution (2.4.11).  It appears
> that
> > > Gnucash requires version
> > > 2.6 of this library, as "WebKitNavigationAction" was apparently added
> in
> > > version 2.6.  Again, the minimum version isn't listed and cmake doesn't
> > > have a check for it.
> >
> > Hi, Robert.
> >
> > Welcome back! Chris mentioned his meeting with you on IRC.
> >
> > Thanks for bringing those to our attention. I've pushed a fix.
> >
> > You will need to install xsltproc. In some distros it's part of the
> libxslt package, which may be why it wasn't mentioned separately in
> README.dependencies. You won't need makeinfo, I've made that optional. It's
> only for an obsolete design information document that is now mostly
> superseded by Doxygen comments.
> >
> > The webkit2gtk-3.0 package provided by Ubuntu 14.04LTS is fine, and
> CMake did correctly detect it and set the compile accordingly--the first
> time through. If you then subsequently ran cmake again it would see that
> WEBKIT_FOUND was true and set up for the preferred webkit2gtk-4.0. I've
> corrected that by having separate WEBKIT2_3_FOUND and WEBKIT2_4_FOUND
> variables.
> >
> > Regards,
> > John Ralls
> >
> >
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


[GNC-dev] Fwd: The two modules

2018-06-15 Thread Christopher Lam
Thanks; this is from an old version of eguile balsheet which is already
obsolete in 3.X onwards, and I know it'll be more difficult to fix as time
goes by. There are already changes from timepair to time64, compulsory CSS,
removal of slots access... There is no active eguile maintainer anymore,
and I really cannot understand eguile.

Would you be kind to comment upon the HTML output (File > Export > Export
Report) of the standard (non-eguile) balsheet, with desired amendments? I
can try to amend with backward compatibility.

For bonus points, if you have a sample datafile with accounts and
transactions that highlight the various functionality of balsheet (e.g.
income/expense, equity, any foreign currency conversions or stock purchases
- I'm sure the wife will have them in her textbooks) I'm sure I can fix the
standard balsheet to her standards!

So, wishlist:

   - datafile with example transactions
   - current html report of standard balsheet
   - annotated ideal report produced by standard balsheet :)

Let's keep this discussion public for external input too.

Regards

-- Forwarded message --
From: Stephen M. Butler 
Date: 16 June 2018 at 00:45
Subject: The two modules
To: Christopher Lam 

Hope this helps.  As I mentioned in the list email, perhaps there is a
way to show the Trading Accounts if they are present and suppress if
they are not.

Also, I think it would be acceptable to have an Income/Expense Report on
a separate page but generated by the same module.  That would ensure
that the Profit/Loss line (or whatever folks want to call it) would be
the same for both reports.  But my wife was adamant that they are two
separate reports.

Thanks for the example as this is my first time seeing this language.
You might find that I took some shortcuts where it wasn't appropriate
for the long haul -- especially around the printing of the Profit/Loss
line.  I'm still now sure what the #t #f and a couple of the other
parameters actually do -- I just got the report to look right!

--Steve

-- 
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
" x "")
  (set! depth (max depth 1)); hack for depth=0
  (if leftoverrule?
(begin
  (set! lo-adjust -1)
  (set! lo-cell " ")))
?>








 (accrec-depth accrec) 0))
)
; has sub-accounts: shift left to put balance in same column as sub-accounts
(set! rshift2 -1))
  ; Don't show zero amount for a placeholder -- the value to
  ; test for zero depends on whether or not this is a 'summary' value
  ; (i.e. a total of sub-accounts that are not shown separately)
  (if (and (accrec-placeholder? accrec)
   (if (accrec-summary? accrec)
 (not (accrec-non-zero? accrec))
 (gnc-numeric-zero-p (accrec-balance-num accrec
(set! showamt? #f))
  (display-acc-row
maxdepth
(accrec-depth accrec)
(+ rshift rshift2)
(accrec-namelink accrec)
(if showamt?
  (if (accrec-summary? accrec)
(format-comm-coll (accrec-subtotal-cc accrec))
(format-monetary (accrec-balance-mny accrec)))
  " "
  )
(< (accrec-depth accrec) 1); total?
#f) ; leftoverrule?
  (if (accrec-sublist accrec)
(begin
  ; recurse to deeper accounts...
  (display-accounts-table-r (accrec-sublist accrec) neg? maxdepth rshift onedepth1)
  ; ...and then display the total
  ; unless there is only one depth-1 account
  (if (not (and onedepth1
(= 1 (accrec-depth accrec
(display-acc-row
  maxdepth
  (accrec-depth accrec)
  (if (> (accrec-depth accrec) 1) rshift 0)
  (string-append " " )
  (format-comm-coll-total (accrec-subtotal-cc accrec))
  (<= (accrec-depth accrec) 1); total?
  (> (accrec-depth accrec) 0)))   ; leftoverrule?
  )
?>





  





  body {
<?scm (if opt-font-family (begin ?>
  font-family: <?scm:d opt-font-family ?>;
<?scm )) ?>
<?scm (if opt-font-size (begin ?>
  font-size: <?scm:d opt-font-size ?>;
<?scm )) ?>
  }
  table { /* table does not inherit font sizes for some reason */
<?scm (if opt-font-size (begin ?>
  font-size: <?scm:d opt-font-size ?>;
<?scm )) ?>
  }






   


 

 (accrec-treedepth accrec-as) 1))
  (set! rshift-as 1))
(if (and (one-depth-1 accrec-li)
   

Re: [GNC-dev] Budgets: showing total-to-date in budget period, and previous month totals only

2018-06-17 Thread Christopher Lam
Hi Phil
I've taken the liberty of fixing up your YTD-budget, renamed to budget-ytd.
I don't use budgeting myself and cannot check figures. But it seems useful
enough.
https://github.com/christopherlam/gnucash/tree/master-ytd
Would you be kind to double check it works as expected in 3.1/maint onwards?
C

On 26 March 2018 at 20:04, Phil Longstaff  wrote:

> I have attached a report which does this.
>
> I have attached ytd-budget.scm. I have this file in
> c:\Users\phill\.gnucash\reports. I then add this line to
> c:\Users\phill\.gnucash\config.user:
>
> (load "c:\\Users\\phill\\.gnucash\\reports\\ytd-budget.scm")
>
> This gives me a new "YTD budget" with 3 sets of columns:
> 1) selected month
> 2) year-to-date
> 3) full year
>
> It always shows actual and budget amounts, and there is an option to add
> difference. There is also an option to select which month you want to show.
>
> On Sun, Mar 25, 2018 at 7:21 PM, Macho Philipovich 
> wrote:
>
> > Dear Gnucash Users,
> >
> >
> > I am looking to for a report/view that will show
> > budgeted/actual/difference amounts for selected accounts for the
> > previous month, as well as the totals for all months to date in the
> > current budgeting period.
> >
> >
> > The wiki seems to suggest that GnuCash does not natively support this,
> > but that it's possible using the third-party "Little Budget Tool":
> >
> >
> > https://wiki.gnucash.org/wiki/Budget_History#Add-On:_.22The_
> > Little_Budget_Tool.22
> >
> >
> > When I tried to download and compile the said software, however I didn't
> > get anywhere. I couldn't get ./configure to recognize the presence of
> > qt, and when I told it to ignore, it balked on the first g++ command. On
> > the one hand, it would not surprise me to learn that I'm just not doing
> > the configure && make process properly. On the other, this software was
> > last revised thirteen years ago.
> >
> >
> > Any advice you can provide on getting the report view I'm looking for
> > would be greatly appreciated!
> >
> >
> > Thanks,
> >
> > Macho
> >
> >
> > ___
> > gnucash-user mailing list
> > gnucash-u...@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-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Fwd: The two modules

2018-06-18 Thread Christopher Lam
Hi Stephen
Thank you this is very helpful.
>From my understanding the non-eguile version does produce satisfactory
headings and contents.
However its alignment of numbers is odd?
Is the alignment of subtotals and totals perfect in your amended eguile
report? How should it look if there are deeper levels of subaccounts?
For html export, open the report tab, then File>Export>Export Report.
I believe the standard balsheet can be refined but this will take some time.
C

On 18 June 2018 at 00:32, Stephen M. Butler  wrote:

> Interesting on the age.  I thought I'd downloaded the most recent Linux
> install.  But, my version is 2.6.19 built from rev c1b5e6c8d+ on
> 2018-04-09.  May be best to wait for the next release due out early next
> week and see how those reports look.
>
> In the interim, attached are:
> 1.  GVE.gnucash -- my current set of books for an apartment building I'm
> selling
> 2.  Balance Sheet - standard.pdf -- Standard Balance Sheet report
> (unformatted)
> 3.  Balance Sheet - formatted.pdf -- Eguile balance sheet after my
> changes were applied
> (Wife still has problems but willing to work with this.
> Specifically, the "Profit/Loss" line should be part of Equities and be
> added just after Retained earnings.  She thinks I should have just one
> line of retained earnings rather than the yearly line I created when
> closing the books each year -- I'll have to clean up my chart of
> accounts to accomplish that -- sigh!)  Plus, I have top level accounts
> with the five major names (Assets, Liabilities, Equities -- maybe should
> rename to Capital, Income and Expense).  So the report does look funny
> with the section titles repeated due to my top level accounts.
>
> I was going to include the eguile version -- but it no longer wants to
> link in when I put that code back in place.  Wish I truly understood how
> that linkage works.  Doesn't seem to function as documented -- at least
> as to how I read/understood the document!  But, since eguile is going
> away, that probably doesn't matter.
>
> Also, is there a way to dump the html version of the reports.  I think
> that is what you wanted but I've only figured out how to capture the pdf
> version to a file rather than letting it print.  Seems strange as I do
> have 20 years on Unix type systems -- but mostly as an Oracle DBA and
> didn't delve deep into the O/S.  Even my korn shell scripting ability
> has atrophied in the past year.
>
> I need to head out and attempt to destroy some bamboo that the previous
> owner let escape.  Plus put in the column bases for the greenhouse the
> wife wants for her orchids.  Isn't retirement fun!  How did I ever have
> time to make the daily trip to downtown Seattle for a living?
>
> --Steve
>
>
> 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
>
> On 06/15/2018 09:06 PM, Christopher Lam wrote:
> > Thanks; this is from an old version of eguile balsheet which is
> > already obsolete in 3.X onwards, and I know it'll be more difficult to
> > fix as time goes by. There are already changes from timepair to
> > time64, compulsory CSS, removal of slots access... There is no active
> > eguile maintainer anymore, and I really cannot understand eguile.
> >
> > Would you be kind to comment upon the HTML output (File > Export >
> > Export Report) of the standard (non-eguile) balsheet, with desired
> > amendments? I can try to amend with backward compatibility.
> >
> > For bonus points, if you have a sample datafile with accounts and
> > transactions that highlight the various functionality of balsheet
> > (e.g. income/expense, equity, any foreign currency conversions or
> > stock purchases - I'm sure the wife will have them in her textbooks)
> > I'm sure I can fix the standard balsheet to her standards!
> >
> > So, wishlist:
> >
> >   * datafile with example transactions
> >   * current html report of standard balsheet
> >   * annotated ideal report produced by standard balsheet :)
> >
> > Let's keep this discussion public for external input too.
> >
> > Regards
> >
> > -- Forwarded message --
> > From: *Stephen M. Butler* mailto:kg...@arrl.net>>
> > Date: 16 June 2018 at 00:45
> > Subject: The two modules
> > To: Christopher Lam  > <mailto:christopher@gmail.com>>
> >
> > Hope this helps.  As I mentioned in the list email, perhaps there is a
> > way to show the Trading Accounts if t

[GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-06-22 Thread Christopher Lam

Hi All

I'm working through balance-sheet.scm and overhauling this report.

At the same time, I can see that balance-sheet.scm and 
income-statement.scm can be merged together.


After all

 * balance sheet = asset/liability/equity balance at date X,
 * income statement = difference in income/expense balances at date X and Y

The issue I have is that the balance sheet can call 
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the 
balance, whereas income statement cannot directly call it because it 
also includes closing transactions.


My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd 
boolean argument i.e. 
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will 
selectively produce the balance, ignore closing transactions.


This is partly done in the last commit of 
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
- it will augment API everywhere, and also modify Account.cpp, 
especially xaccAccountRecomputeBalance which will call 
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in 
the account to determine closing status and cache the balances for each 
split. See draft on 
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
- this currently fails because I'm not good at C.


*My query is whether it will be too expensive to call 
xaccTransGetIsClosingTxn for each split in Account.cpp to produce the 
split->noclosing_balance, which will be crucial to calculate income 
between two dates.*


*Currently this 'closing-txn' filter is done in income-statement.scm via 
a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn 
calls, which IMHO is not ideal either.

*

Any help welcome!

P.S. if this last commit is removed, the 
https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances 
branch contains work-so-far for updated balance-sheet. Screenshot 
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the 
multilevel subtotals were previously horizonal, are now vertical; 
original-currency amounts, and multiple-date balance sheets.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Budgets: showing total-to-date in budget period, and previous month totals only

2018-06-23 Thread Christopher Lam
Hi Phil, glad to know I haven't broken anything. Can't think what to do 
about headers; these are problems that should be fixed in CSS! If you 
wish I can submit a PR but ideally would wish to create a satisfactory 
test datafile and report output. I don't use budget, so, I wouldn't be 
the best here. If you can send me, I'll try make a basic test for it. C


On 23/06/18 20:05, Phil Longstaff wrote:

Hi Chris,

I am running 3.1 and it works. The only comment I have is that the 
'Bgt', 'Act' and 'Diff' headings are left-justified and look a bit 
strange. I think center- or right-justified would be better.


Thanks for doing this.
Phil

On Sun, Jun 17, 2018 at 11:16 AM Christopher Lam 
mailto:christopher@gmail.com>> wrote:


Hi Phil
I've taken the liberty of fixing up your YTD-budget, renamed to
budget-ytd.
I don't use budgeting myself and cannot check figures. But it
seems useful enough.
https://github.com/christopherlam/gnucash/tree/master-ytd
Would you be kind to double check it works as expected in
3.1/maint onwards?
C

On 26 March 2018 at 20:04, Phil Longstaff
mailto:phil.longst...@gmail.com>> wrote:

I have attached a report which does this.

I have attached ytd-budget.scm. I have this file in
c:\Users\phill\.gnucash\reports. I then add this line to
c:\Users\phill\.gnucash\config.user:

    (load "c:\\Users\\phill\\.gnucash\\reports\\ytd-budget.scm")

This gives me a new "YTD budget" with 3 sets of columns:
1) selected month
2) year-to-date
3) full year

It always shows actual and budget amounts, and there is an
option to add
difference. There is also an option to select which month you
want to show.

On Sun, Mar 25, 2018 at 7:21 PM, Macho Philipovich
mailto:mach...@riseup.net>>
wrote:

> Dear Gnucash Users,
>
>
> I am looking to for a report/view that will show
> budgeted/actual/difference amounts for selected accounts for the
> previous month, as well as the totals for all months to date
in the
> current budgeting period.
>
>
> The wiki seems to suggest that GnuCash does not natively
support this,
> but that it's possible using the third-party "Little Budget
Tool":
>
>
> https://wiki.gnucash.org/wiki/Budget_History#Add-On:_.22The_
> Little_Budget_Tool.22
>
>
> When I tried to download and compile the said software,
however I didn't
> get anywhere. I couldn't get ./configure to recognize the
presence of
> qt, and when I told it to ignore, it balked on the first g++
command. On
> the one hand, it would not surprise me to learn that I'm
just not doing
> the configure && make process properly. On the other, this
software was
> last revised thirteen years ago.
>
>
> Any advice you can provide on getting the report view I'm
looking for
> would be greatly appreciated!
>
>
> Thanks,
>
> Macho
>
>
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org <mailto:gnucash-u...@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-u...@gnucash.org <mailto:gnucash-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-06-23 Thread Christopher Lam
Hi John, the split->noclosing_balance is updated in
xaccAccountRecomputeBalance. Will continue copypasta coding until it works!

On Sat, 23 Jun 2018, 23:56 John Ralls  wrote:

>
>
> > On Jun 22, 2018, at 9:42 PM, Christopher Lam 
> wrote:
> >
> > Hi All
> >
> > I'm working through balance-sheet.scm and overhauling this report.
> >
> > At the same time, I can see that balance-sheet.scm and
> income-statement.scm can be merged together.
> >
> > After all
> >
> > * balance sheet = asset/liability/equity balance at date X,
> > * income statement = difference in income/expense balances at date X and
> Y
> >
> > The issue I have is that the balance sheet can call
> xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely retrieve the
> balance, whereas income statement cannot directly call it because it also
> includes closing transactions.
> >
> > My proposal is to augment xaccAccountGetBalanceAsOfDate to accept a 3rd
> boolean argument i.e. xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing)
> which will selectively produce the balance, ignore closing transactions.
> >
> > This is partly done in the last commit of
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - it will augment API everywhere, and also modify Account.cpp, especially
> xaccAccountRecomputeBalance which will call
> xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split in the
> account to determine closing status and cache the balances for each split.
> See draft on
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> - this currently fails because I'm not good at C.
> >
> > *My query is whether it will be too expensive to call
> xaccTransGetIsClosingTxn for each split in Account.cpp to produce the
> split->noclosing_balance, which will be crucial to calculate income between
> two dates.*
> >
> > *Currently this 'closing-txn' filter is done in income-statement.scm via
> a "Closing Entries" string/regex filter and xaccTransGetIsClosingTxn calls,
> which IMHO is not ideal either.
> > *
> >
> > Any help welcome!
> >
> > P.S. if this last commit is removed, the
> https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
> branch contains work-so-far for updated balance-sheet. Screenshot
> https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
> multilevel subtotals were previously horizonal, are now vertical;
> original-currency amounts, and multiple-date balance sheets.
> >
> > _
>
> Chris,
>
> Only profiling will tell how much of a performance hit this creates.
>
> I don’t see where in your commit you’re computing the split’s no-closing
> balance. Perhaps that’s why it doesn’t work?
>
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-06-24 Thread Christopher Lam

I think I'll forego a noclosing_balance upgrade in C.

According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the 
"Closing Entries" transactions did not always receive a special 
KVP-based flag until the commit on 
https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles 
generated from 27-11-2008 and later.


So, to find and exclude these closing entries, we can use the following 
strategies:


1. xaccTransGetIsClosingTxn, will query the KVP flag
2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
   the KVP flag)
3. Free-text search "Closing Entries" to seek these old closing entries

So a P&L report will necessarily need to do both filtering for KVP and 
free-text search.


The multicolumn report will be different enough from the old 
balance-sheet and income-statement that I think I should spin it off 
into a different report altogether, and the others will be sunsetted. 
Hopefully this new report will be broadly acceptable because the old 
reports have a *lot* of supporting unintelligible old code, especially 
to handle closing-entries as above.


C

On 24/06/18 00:51, Christopher Lam wrote:
Hi John, the split->noclosing_balance is updated in 
xaccAccountRecomputeBalance. Will continue copypasta coding until it 
works!


On Sat, 23 Jun 2018, 23:56 John Ralls <mailto:jra...@ceridwen.fremont.ca.us>> wrote:




> On Jun 22, 2018, at 9:42 PM, Christopher Lam
mailto:christopher@gmail.com>> wrote:
>
> Hi All
>
> I'm working through balance-sheet.scm and overhauling this report.
>
> At the same time, I can see that balance-sheet.scm and
income-statement.scm can be merged together.
>
> After all
>
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at
date X and Y
>
> The issue I have is that the balance sheet can call
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
retrieve the balance, whereas income statement cannot directly
call it because it also includes closing transactions.
>
> My proposal is to augment xaccAccountGetBalanceAsOfDate to
accept a 3rd boolean argument i.e.
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
selectively produce the balance, ignore closing transactions.
>
> This is partly done in the last commit of

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- it will augment API everywhere, and also modify Account.cpp,
especially xaccAccountRecomputeBalance which will call
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each split
in the account to determine closing status and cache the balances
for each split. See draft on

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- this currently fails because I'm not good at C.
>
> *My query is whether it will be too expensive to call
xaccTransGetIsClosingTxn for each split in Account.cpp to produce
the split->noclosing_balance, which will be crucial to calculate
income between two dates.*
>
> *Currently this 'closing-txn' filter is done in
income-statement.scm via a "Closing Entries" string/regex filter
and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
> *
>
> Any help welcome!
>
> P.S. if this last commit is removed, the

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
branch contains work-so-far for updated balance-sheet. Screenshot
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
multilevel subtotals were previously horizonal, are now vertical;
original-currency amounts, and multiple-date balance sheets.
>
> _

Chris,

Only profiling will tell how much of a performance hit this creates.

I don’t see where in your commit you’re computing the split’s
no-closing balance. Perhaps that’s why it doesn’t work?

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-06-24 Thread Christopher Lam

Seeking beta testers. This will not be in v3.2.

https://github.com/christopherlam/gnucash/tree/maint-balsheet-pnl

Or, anyone with a relatively recent maint can copy the file directly 
into the build's standard-reports folder: 
https://raw.githubusercontent.com/christopherlam/gnucash/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm


Adds new balsheet and new income-statement. I still have further ideas 
in the pipeline, just wish to check accuracy of amounts produced. Not 
all options have been implemented. Testing closing amounts through KVP 
wasn't an issue after all; the closing entries are first sought, cached, 
then analyzed as required. For posterity C could also produce noclosing 
balances for easier future reports, but I think this works well so far.


C

On 24/06/18 17:50, Christopher Lam wrote:


I think I'll forego a noclosing_balance upgrade in C.

According to https://bugzilla.gnome.org/show_bug.cgi?id=570042 the 
"Closing Entries" transactions did not always receive a special 
KVP-based flag until the commit on 
https://github.com/Gnucash/gnucash/commit/4b2800145 on datafiles 
generated from 27-11-2008 and later.


So, to find and exclude these closing entries, we can use the 
following strategies:


 1. xaccTransGetIsClosingTxn, will query the KVP flag
 2. Run a QofQuery and add xaccQueryAddClosingTransMatch (also queries
the KVP flag)
 3. Free-text search "Closing Entries" to seek these old closing entries

So a P&L report will necessarily need to do both filtering for KVP and 
free-text search.


The multicolumn report will be different enough from the old 
balance-sheet and income-statement that I think I should spin it off 
into a different report altogether, and the others will be sunsetted. 
Hopefully this new report will be broadly acceptable because the old 
reports have a *lot* of supporting unintelligible old code, especially 
to handle closing-entries as above.


C

On 24/06/18 00:51, Christopher Lam wrote:
Hi John, the split->noclosing_balance is updated in 
xaccAccountRecomputeBalance. Will continue copypasta coding until it 
works!


On Sat, 23 Jun 2018, 23:56 John Ralls <mailto:jra...@ceridwen.fremont.ca.us>> wrote:




> On Jun 22, 2018, at 9:42 PM, Christopher Lam
mailto:christopher@gmail.com>> wrote:
>
> Hi All
>
> I'm working through balance-sheet.scm and overhauling this report.
>
> At the same time, I can see that balance-sheet.scm and
income-statement.scm can be merged together.
>
> After all
>
> * balance sheet = asset/liability/equity balance at date X,
> * income statement = difference in income/expense balances at
date X and Y
>
> The issue I have is that the balance sheet can call
xaccAccountGetBalanceAsOfDate(acc,date) directly to nicely
retrieve the balance, whereas income statement cannot directly
call it because it also includes closing transactions.
>
> My proposal is to augment xaccAccountGetBalanceAsOfDate to
accept a 3rd boolean argument i.e.
xaccAccountGetBalanceAsOfDate(acc,date,ignoreclosing) which will
selectively produce the balance, ignore closing transactions.
>
> This is partly done in the last commit of

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- it will augment API everywhere, and also modify Account.cpp,
especially xaccAccountRecomputeBalance which will call
xaccTransGetIsClosingTxn(xaccSplitGetParent(split)) for each
split in the account to determine closing status and cache the
balances for each split. See draft on

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
- this currently fails because I'm not good at C.
>
> *My query is whether it will be too expensive to call
xaccTransGetIsClosingTxn for each split in Account.cpp to produce
the split->noclosing_balance, which will be crucial to calculate
income between two dates.*
>
> *Currently this 'closing-txn' filter is done in
income-statement.scm via a "Closing Entries" string/regex filter
and xaccTransGetIsClosingTxn calls, which IMHO is not ideal either.
> *
>
> Any help welcome!
>
> P.S. if this last commit is removed, the

https://github.com/christopherlam/gnucash/tree/maint-create-API-call-for-noclosing-balances
branch contains work-so-far for updated balance-sheet. Screenshot
https://screenshots.firefox.com/eelmGQrGCtcP6bqC/null - see the
multilevel subtotals were previously horizonal, are now vertical;
original-currency amounts, and multiple-date balance sheets.
>
> _

Chris,

Only profiling will tell how much of a performa

[GNC-dev] book-currency

2018-07-01 Thread Christopher Lam
There's lots of dead code related to an (AFAIK) unimplemented book-currency
or currency-accounting feature... Some are cluttering options.scm - should
we remove them?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-02 Thread Christopher Lam
Hi Stephen, Dave &al

Thank you -

Dave - the changes are merely cosmetic therefore easy.

It sounds there are still 2 desired presentational types - (1) Dave's
approach = *recursive-bal* - 'parent' accounts generally collect their
children account amounts; if they also have their own amount, the latter is
rendered on the next line, indented as a child account. (2) Stephen's
approach = *multilevel-bal* - parent accounts' amounts are hidden unless
they exist.

With *multilevel *balances we expect multiple sublevels; so the following
becomes feasible:
Expenses:Household:Child1   (parent-acc without amount)
Expenses:Household:Child1:Sports = $30
Expenses:Household:Child1:Clothing = $40
TOTAL Expenses:Household:Child1 = $70

Expenses:Household:Child2 = $20 (parent-acc with amounts)
Expenses:Household:Child2:Sports = $20
Expenses:Household:Child2:Clothing = $20
TOTAL Expenses:Household:Child2 = $60
TOTAL Expenses:Household = $xxx
TOTAL Expenses = $yyy
^ notice there will be as many TOTAL lines as there are levels from root.

I'll try to restore the multilevel subtotals - I had received no feedback
and it is rather difficult to debug; as I mentioned to Stephen I'd removed
it, but I expect it can be done.

The existing code is a mess and I want them gone, but will need to know the
amounts are correct.

C

On 30 June 2018 at 18:50, DaveC49  wrote:

> Chris,
>  I have the multicolumn report up and running in V3.2. In addition to
> adding
> your file I also had to incorporate it in the CMakeLists.txt in
> ~/gnucash/report/standard-reports to have it available from the menu.
> Initially I will just comment on the presentation, as I don't have a
> testfile setup with which I can check the numbers out yet.
>
> I need to emphasize that these are my personal preferences for clarity of
> presentation and not any accounting profession standard as such. IAS-1
> (https://www.iasplus.com/en/standards/ias/ias1) the IFRS standard does not
> specify any particular layout and format and mainly concentrates on what
> content has to be presented in the four standard financial statements (some
> individual jurisdictions may be more prescriptive):
> Statement of financial position (balance sheet);
> Statement of profit and loss and other comprehensive income;
> Statement of cash flows;
> Statement of changes in equity.
>
> One of the problems of a multicolumn report is in representing an account
> heirarchy which is more than 2 to 3 levels deep as I'm sure you have
> already
> discovered. You run out of ways of clearly delineating the totals at each
> level fairly quickly. This is much easier when you can have a column at
> each
> level of the heirarchy.
>
> 1. I would put the date headings one line up from the Asset Bold heading.
> 2. i wouldn't use double lines under sub-totals within the major Asset,
> Liability and Equity groups but would just use a single line under them and
> reserve the double underline for the total in each of those major sections,
> 3. With the Totals, I would not incorporate the full account heirarchy in
> the heading, but just the parent account that the subtotal is for. Then
> indenting of the account heirarchy can then indicate the heirarchy level
> and
> what are totals at that level. You could perhaps augment this by using
> decreasing font sixes as the heirarchy level increases.
> 4. If it is possible, I would have the total of any transactions direct to
> the parent account displayed in the same manner as any of its child
> accounts
> and balances so that the total displayed for the parent is the balance of
> the direct transactions + any child account totals. If no direct
> transactions, drop this as a line item. Since GnuCash does allow this
> 5. Also consider totalling up rather than down (avoids having to repeat the
> Level Heading with a Total label.
> 6. There is no need for a separate Net Worth item as that is what Equity
> is.
>
> I have attached a LibreOffice document illustrating what I mean by the
> above
> in case it is not clear. I have illustrated a case where Petty Cash is a
> parent account which has transactions into it as well as having a child
> account (Ignore any table lines).
> MultiColumnBalSheetLayoutSuggestions.odt
>  MultiColumnBalSheetLayoutSuggestions.odt>
>
> Hope this helps with some ideas.
>
> Cheers
> David
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] book-currency

2018-07-02 Thread Christopher Lam
Hi Alex
Thank you for update - would you mind letting us know the layman version of
it?
Thanks!

On 3 July 2018 at 01:02, Alex Aycinena  wrote:

>
>> -- Forwarded message --
>> From: John Ralls 
>> To: Christopher Lam 
>> Cc: gnucash-devel 
>> Bcc:
>> Date: Sun, 1 Jul 2018 20:13:37 -0700
>> Subject: Re: [GNC-dev] book-currency
>> If you’re sure it’s dead code, by all means.
>>
>> The volume of cruft often overwhelms the working code, and always wastes
>> maintenance time.
>>
>> Regards,
>> John Ralls
>>
>> > On Jul 1, 2018, at 5:47 PM, Christopher Lam 
>> wrote:
>> >
>> > There's lots of dead code related to an (AFAIK) unimplemented
>> book-currency
>> > or currency-accounting feature... Some are cluttering options.scm -
>> should
>> > we remove them?
>> > ___
>> > gnucash-devel mailing list
>> > gnucash-devel@gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
>
>  I put it there for a project I am working on (but have gotten delayed
> on). It is not dead code; however, allow me to remove it in the next week
> or so and I will re-apply it later when the project moves forward.
>
> Alex
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-03 Thread Christopher Lam
Broadly yes, one approach is that parent accounts always show totals for
themselves+children, the other approach is the totals appear after each
parent+children.

Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When reaching
an account, it just queries if it has children, and if yes check if they
have own amount, and if yes insert next line for own account.

Multilevel subtotals require collectors to keeping track of amounts while
cycling the account list.

On Tue, 3 Jul 2018, 15:41 Geert Janssens  wrote:

> Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> > Hi Stephen, Dave &al
> >
> > Thank you -
> >
> > Dave - the changes are merely cosmetic therefore easy.
> >
> > It sounds there are still 2 desired presentational types - (1) Dave's
> > approach = *recursive-bal* - 'parent' accounts generally collect their
> > children account amounts; if they also have their own amount, the latter
> is
> > rendered on the next line, indented as a child account. (2) Stephen's
> > approach = *multilevel-bal* - parent accounts' amounts are hidden unless
> > they exist.
> >
> I'm not sure I understand the difference here. Isn't this expressing the
> same
> thing twice in different ways ? Perhaps I'm missing a subtlety in the
> English
> language...
>
> Or is the difference whether the totals are shown above or below the
> children
> ?
>
> Geert
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-04 Thread Christopher Lam
I've restored multilevel-subtotals... using an easier tack than 
previously: instead of keeping lists(1 per account-depth) of lists (1 
per column) of collectors, it'll just climb up the hierarchy and print 
parent acc's balance+children until the next account-depth is reached.


Please help beta test!

I've made some cosmetic changes too. eg dates in their own row, 
double-underline for grand-total only.


I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:
Broadly yes, one approach is that parent accounts always show totals 
for themselves+children, the other approach is the totals appear after 
each parent+children.


Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When 
reaching an account, it just queries if it has children, and if yes 
check if they have own amount, and if yes insert next line for own 
account.


Multilevel subtotals require collectors to keeping track of amounts 
while cycling the account list.


On Tue, 3 Jul 2018, 15:41 Geert Janssens <mailto:geert.gnuc...@kobaltwit.be>> wrote:


Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> Hi Stephen, Dave &al
>
> Thank you -
>
> Dave - the changes are merely cosmetic therefore easy.
>
> It sounds there are still 2 desired presentational types - (1)
Dave's
> approach = *recursive-bal* - 'parent' accounts generally collect
their
> children account amounts; if they also have their own amount,
the latter is
> rendered on the next line, indented as a child account. (2)
Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are
hidden unless
> they exist.
>
I'm not sure I understand the difference here. Isn't this
expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in
the English
language...

Or is the difference whether the totals are shown above or below
the children
?

Geert




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-04 Thread Christopher Lam

Forgot to include a screenshot to illustrate

https://screenshots.firefox.com/Z7HOv5pb2qbRc5NP/null

- recursive balance vs. multilevel (and saner alignment of numbers)
- common-currency vs. original currency (notice better handling of 
missing USD/GBP prices than balance-sheet.scm)

- for this illustration periodic columns have been disabled

C


On 04/07/18 20:13, Christopher Lam wrote:


I've restored multilevel-subtotals... using an easier tack than 
previously: instead of keeping lists(1 per account-depth) of lists (1 
per column) of collectors, it'll just climb up the hierarchy and print 
parent acc's balance+children until the next account-depth is reached.


Please help beta test!

I've made some cosmetic changes too. eg dates in their own row, 
double-underline for grand-total only.


I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:
Broadly yes, one approach is that parent accounts always show totals 
for themselves+children, the other approach is the totals appear 
after each parent+children.


Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When 
reaching an account, it just queries if it has children, and if yes 
check if they have own amount, and if yes insert next line for own 
account.


Multilevel subtotals require collectors to keeping track of amounts 
while cycling the account list.


On Tue, 3 Jul 2018, 15:41 Geert Janssens <mailto:geert.gnuc...@kobaltwit.be>> wrote:


Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> Hi Stephen, Dave &al
>
> Thank you -
>
> Dave - the changes are merely cosmetic therefore easy.
>
> It sounds there are still 2 desired presentational types - (1)
Dave's
> approach = *recursive-bal* - 'parent' accounts generally
collect their
> children account amounts; if they also have their own amount,
the latter is
> rendered on the next line, indented as a child account. (2)
Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are
hidden unless
> they exist.
>
I'm not sure I understand the difference here. Isn't this
expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in
the English
language...

Or is the difference whether the totals are shown above or below
the children
?

Geert






___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-04 Thread Christopher Lam

Oops https://screenshots.firefox.com/pttTjFEtYTJLXzam/null

Sorry for spam, fixed screenshot


On 04/07/18 21:20, Christopher Lam wrote:


Forgot to include a screenshot to illustrate

https://screenshots.firefox.com/Z7HOv5pb2qbRc5NP/null

- recursive balance vs. multilevel (and saner alignment of numbers)
- common-currency vs. original currency (notice better handling of 
missing USD/GBP prices than balance-sheet.scm)

- for this illustration periodic columns have been disabled

C


On 04/07/18 20:13, Christopher Lam wrote:


I've restored multilevel-subtotals... using an easier tack than 
previously: instead of keeping lists(1 per account-depth) of lists (1 
per column) of collectors, it'll just climb up the hierarchy and 
print parent acc's balance+children until the next account-depth is 
reached.


Please help beta test!

I've made some cosmetic changes too. eg dates in their own row, 
double-underline for grand-total only.


I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:
Broadly yes, one approach is that parent accounts always show totals 
for themselves+children, the other approach is the totals appear 
after each parent+children.


Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When 
reaching an account, it just queries if it has children, and if yes 
check if they have own amount, and if yes insert next line for own 
account.


Multilevel subtotals require collectors to keeping track of amounts 
while cycling the account list.


On Tue, 3 Jul 2018, 15:41 Geert Janssens <mailto:geert.gnuc...@kobaltwit.be>> wrote:


Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
> Hi Stephen, Dave &al
>
> Thank you -
>
> Dave - the changes are merely cosmetic therefore easy.
>
> It sounds there are still 2 desired presentational types - (1)
Dave's
> approach = *recursive-bal* - 'parent' accounts generally
collect their
> children account amounts; if they also have their own amount,
the latter is
> rendered on the next line, indented as a child account. (2)
Stephen's
> approach = *multilevel-bal* - parent accounts' amounts are
hidden unless
> they exist.
>
I'm not sure I understand the difference here. Isn't this
expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety
in the English
language...

Or is the difference whether the totals are shown above or below
the children
?

Geert








___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-04 Thread Christopher Lam
Still at 
https://raw.githubusercontent.com/christopherlam/gnucash/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm


Latest - removed accountname formatting in recursive-bal. Now they are 
styled normally but the amounts are bold/bigger if they contain 
children-amounts.


https://screenshots.firefox.com/NcMKts75npXbP4Bc/null

C

On 05/07/18 03:40, Stephen M. Butler wrote:

Could you repost the location to pull the latest?  My memory is
over-full and appears to be working the LIFO method of cleanup.


On 07/04/2018 05:13 AM, Christopher Lam wrote:

I've restored multilevel-subtotals... using an easier tack than
previously: instead of keeping lists(1 per account-depth) of lists (1
per column) of collectors, it'll just climb up the hierarchy and print
parent acc's balance+children until the next account-depth is reached.

Please help beta test!

I've made some cosmetic changes too. eg dates in their own row,
double-underline for grand-total only.

I do not think it'll be wise to reduce font sizes for account-depth.

Still remaining:

- fix negative signs strategy


On 03/07/18 16:17, Christopher Lam wrote:

Broadly yes, one approach is that parent accounts always show totals
for themselves+children, the other approach is the totals appear
after each parent+children.

Same information presented in 2 different ways.

The difference is that the recursive subtotals are easier When
reaching an account, it just queries if it has children, and if yes
check if they have own amount, and if yes insert next line for own
account.

Multilevel subtotals require collectors to keeping track of amounts
while cycling the account list.

On Tue, 3 Jul 2018, 15:41 Geert Janssens mailto:geert.gnuc...@kobaltwit.be>> wrote:

 Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:
 > Hi Stephen, Dave &al
 >
 > Thank you -
 >
 > Dave - the changes are merely cosmetic therefore easy.
 >
 > It sounds there are still 2 desired presentational types - (1)
 Dave's
 > approach = *recursive-bal* - 'parent' accounts generally
 collect their
 > children account amounts; if they also have their own amount,
 the latter is
 > rendered on the next line, indented as a child account. (2)
 Stephen's
 > approach = *multilevel-bal* - parent accounts' amounts are
 hidden unless
 > they exist.
 >
 I'm not sure I understand the difference here. Isn't this
 expressing the same
 thing twice in different ways ? Perhaps I'm missing a subtlety in
 the English
 language...

 Or is the difference whether the totals are shown above or below
 the children
 ?

 Geert




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Slow user interface in 3.x gnucash (for large files), and potential optimization

2018-07-04 Thread Christopher Lam

Hi David,

Just as a matter of experimentation, try the new charting tree available 
at https://github.com/christopherlam/gnucash/tree/master-chartjs - it 
replaces the antiquated jqplot with shiny ChartJS - it is awaiting beta 
testers, and it seems you can build from source :-)


Features:

- URL jumps from barcharts and piecharts have been resurrected
- much more responsive
- much more code-efficient... html-line/pie/scatter/barcharts.scm have 
been merged into one html-charts.scm


Otherwise it's much of a likeness with old jqplot.

C


On 05/07/18 08:33, David Carlson wrote:

Christian Stimming and all developers,

First, I want to thank all of you for your great effort to roll out the 3.0
release and the quick followups to fix bugs and get releases 3.1, and 3.2
out in quick succession.

Christian has made substantial progress at isolating and solving several
major sources of lagging response with Gnucash.  I would like to ask you to
see if there is room for improvement or at least some low hanging fruit in
a couple of areas that bother me.  Actually, I would like all developers to
take an interest in this issue and to at least keep in mind that whatever
code they implement should be designed to run as efficiently as possible.

I am still using releases 2.6.15 through 2.6.17 on various computers and I
have recently observed a couple of things that are definitely not new but
that may still impact releases 3.2 and future 3.3.  These are more
pronounced when using SSH to run GnuCash on a faster computer from a slower
(Windows) computer.  Because SSH seems to be vulnerable, I suspect that
there may be repetitive screen refreshes happening as the code is
executed.

For me, the most noticeable lag happens every time an automatic file save
happens.  GnuCash does not accept user input during the save.  This is
stretched dramatically if the file resides on a network resource instead of
the local hard drive or ssd but it is also substantially slower when using
SSH to run GnuCash remotely.  This lag is 1 minute 10 seconds for me.  This
is with a local network NAS serving the foo.gnucash standard format
compressed file via Ethernet to a virtual Debian Stretch Linux machine.

When opening Edit > Preferences there is a long lag.  For my situation, the
lag is about 24 seconds before the Preferences window appears.  This is not
something users do frequently, but it is quite noticeable.

I have also noticed that after a file is opened that was previously closed
with open reports, the first time that the user touches the report tab
there is an obvious flicker as the report in the window is reconstructed
before the the users very own eyes.  This is most apparent for linechart
reports and probably barchart reports.

Thank You All,

David C


On Fri, Jun 15, 2018 at 3:47 PM, John Ralls  wrote:




On Jun 15, 2018, at 12:55 PM, Christian Stimming 

wrote:

Am Freitag, 15. Juni 2018, 10:05:09 schrieb John Ralls:

A very good catch indeed. But pre-constructing the string in
qofbook.cpp only saves two string constructions per invocation as the
vector still has to make its own copies. I guess that its much worse
for you because the ancient gcc on Ubuntu 14.04 (gcc4.8) doesn't do
small-string optimization.

Is there any reason we cant use std::string& in the vector?  Or do we
think that we might lose references there?

In this instance the string is static so it would be safe to use const
std::string&, but while there's an is_volatile type trait there's no
is_static so we can't insert a static assert to catch cases where the
actual std::string is on the stack. That could lead to some ugly bugs.

The std containers are specified in a way so that they make only sense

to

contain the values by-value (ok, this might be formulated a bit too

short, but

not too long ago this was a good rule of thumb). It is up to the
implementation to make optimizations (copy-on-write and such), but the
interface requires the programmer to think of the stored type as

"by-value".

Nevertheless I think my change made good use of the std::string's

already

existing optimizations. In particular, the saving was so surprisingly

large

here that I think gcc's std::string itself implements some sort of

copy-on-

write optimization, and this means its content isn't deep-copied in

these

calls.

Some numbers from the valgrind/callgrind evaluation. I got the following
number of calls, starting from qof_query_run and skipping some

uninterestings

calls in between:

- 6 qof_query_run
- 6 g_list_sort_with_data
- 360,000 (approx.) sort_func - due to the number of splits and txn in

my file

- 360,000 xaccSplitOrder
The most expensive part in this function is this next callee:
- 360,000 qof_book_use_split_action_for_num_field
- 360,000 (approx.) qof_book_get_property

This function in turn has approx. 1,100,000 calls to std::basic_string
constructor and destructor. The change in my commit is this:
Before my commit, these calls also caused 1,100,000 call

[GNC-dev] stress-testing reports

2018-07-11 Thread Christopher Lam
Hi all

To aid in development and refactoring of the numerous reports, I've
developed a report-options stress test.


*Premise:*
Most reports are currently defined in scheme. The reporting engine expects,
at a minimum, 2 functions to be defined - an options generator, and a
renderer.

The options generator will create a blank (gnc:report-options) object,
modify it by adding various options eg (gnc:make-string-option),
(gnc:make-simple-boolean-option), and return the options object to the
engine. This forms the basis of the report options UI.

The renderer will accept a report ID, and the options object. The renderer
will read the options used, query the database, and present a
gnc:html-document object to the engine. I'm not sure what happens
afterwards; the engine will render the html-document in Webkit.

*Refactoring*
Most of the report infrastructure was designed about 15-20 years ago...
this was using scheme/lisp conventions - bearing in mind LISP was designed
in the 1970s, and modern scripting engines such as python etc were nascent
- nonetheless scheme was chosen, for reasons that are apparent to schemers
only -- pythonistas will argue otherwise, but I do now that scheme is a
more flexible language to design financial reports; scheme has also evolved
in the past 15 years to become a powerful compilable language... Guile is
no different and will continue to evolve in a positive direction.

Unfortunately the state of Gnucash scheme code as of 2018 is stuck in the
past; for various reasons they have been kept on life support, limping
forward via every bugzilla report, and very difficult to understand and
create new types of reports. It would be good to refactor the numerous
scheme functions but, as some users have found out, refactoring the cryptic
code with good intentions do create some unusual report crashes.

*Proposal*
I have designed a mechanism whereby most standard reports in Gnucash have
been queried, and their options (string/boolean/etc) dumped, and a
test-stress-options is run continuously... This will repeatedly render the
options with various combinations of options, simply testing whether the
report will actually run. It does not verify the contents of the report.
It's designed to catch errors whereby e.g. finding periodic average on a
regular report is working well, but a refactored report whereby calculating
the average will fail on an empty book causing (total amount / num columns)
will trigger a division by zero.

The test-stress-options will come in 2 guises:

The first will perform a simple-stress-test, whereby all options are set to
successive values... if a report has 3 booleans (t/f) and 1 multichoice
with 4 values (a/b/c/d), it will run them with: (t,t,t,a), (f,f,f,b),
(t,t,t,c), (f,f,f,d) - this is fairly simple.

The second test will perform a combinatorial stress test, whereby the
number of options is sent to a local build of jenny from
http://burtleburtle.net/bob/math/jenny.html (thanks rgmerk); guile will
subprocess "jenny 2 2 2 4" which will generate an efficient list of options
(1a 2b 3a 4a), (1b 2b 3a 4b) etc, which is then interpreted by guile to run
the report repeatedly, hopefully catching more errors.

Either test is first run on an empty book, then on a book with sample
transactions.

On my laptop, a Intel i5, the simple-stress-test compiles in 1s and runs
most standard reports in 5 seconds and the combinatorial-stress-test
compiles in 8s and runs them in 20s. See its output at
https://gist.github.com/christopherlam/c04d43398ecac486d662c4e74eb293ca

Some reports e.g. multicolumn, hello-world, and eguile-based reports refuse
to be run, and are excluded.

IMHO this strategy, although complicated, is a safe and effective way to
ensure that refactoring internal functions do not lead to unexpected report
crashes. I'd think the simple stress test would be sufficient for daily
use, and combinatorics stress test prior to release. Code currently lives
on at https://github.com/Gnucash/gnucash/pull/378

Comments welcome!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-18 Thread Christopher Lam

The state of balsheet-pnl.scm, is as follows:

I think it is stable and featureful enough to be a replacement, but 
there are no tests yet to validate a transition. This may happen over 
the next few months.


It incorporates all balance-sheet.scm and income-statement.scm 
functionality with the following known differences:


 * no option to show double-column ie Asset=left, Expense/Equity=right
   (because I prefer leaving space for multiple data columns )
 * no option to hide/show individual sections/their labels (eg
   Display/show asset section)
 * no display/show accounting-style rules (no space at all)
 * flatten list at depth limit (I don't understand its strategy at all
   and prefer to disable it)
 * balance-sheet.scm with Display/Parent-account-balances=none will
   disable amounts for accounts-with-children, which I think is
   nonsensical -- if an account has children, unless its amount is $0,
   it must be displayed, either recursive or multilevel.
 * choosing a common-report-currency when there are missing prices will
   now leave the amount in its original currency, instead of converting
   to $0.00
 * new balsheet will not compute unrealized gains -- from my
   understanding this doesn't belong in the balance sheet
 * I haven't coded the price source to average-cost or
   weighted-average, both of which will set a single exchange rate
   through all multicolumns -- are these options important???

Future plans:

 * I think the account-amount calculating functions are good enough to
   be reused to replace net-charts, category-barchart etc.
 * Hopefully the unintelligible old code can then be dumped for good.

C


On 03/07/18 15:41, Geert Janssens wrote:

Op dinsdag 3 juli 2018 02:57:50 CEST schreef Christopher Lam:

Hi Stephen, Dave &al

Thank you -

Dave - the changes are merely cosmetic therefore easy.

It sounds there are still 2 desired presentational types - (1) Dave's
approach = *recursive-bal* - 'parent' accounts generally collect their
children account amounts; if they also have their own amount, the latter is
rendered on the next line, indented as a child account. (2) Stephen's
approach = *multilevel-bal* - parent accounts' amounts are hidden unless
they exist.


I'm not sure I understand the difference here. Isn't this expressing the same
thing twice in different ways ? Perhaps I'm missing a subtlety in the English
language...

Or is the difference whether the totals are shown above or below the children
?

Geert




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-19 Thread Christopher Lam
Hi Frank
Thank you - I can restore the dual-columns when the periods have been
disabled.
I'd prefer to limit the number of options; so, if the "period duration" is
disabled, the report will automatically show dual columns
(Asset/Income=left, Liability+Equity/Expense = right). This works?
Can you please show me good examples of idealised T-account balance
sheet/income statement? Or the scaled form? I have no idea.
C



On 19 July 2018 at 05:17, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:

> Hi Chris,
>
> Am 18.07.2018 um 15:13 schrieb Christopher Lam:
> > The state of balsheet-pnl.scm, is as follows:
> >
> > I think it is stable and featureful enough to be a replacement, but
> > there are no tests yet to validate a transition. This may happen over
> > the next few months.
> >
> > It incorporates all balance-sheet.scm and income-statement.scm
> > functionality with the following known differences:
> >
> >  * no option to show double-column ie Asset=left, Expense/Equity=right
> >(because I prefer leaving space for multiple data columns )
>
> That is a problem for users in continental Europe, probably also other
> non english speaking countries. We use the traditional T account
> representation, while english speaking countries prefer the scaled (from
> ital. for step stairs) form.
>
> The T account representation easens also simple liqudity checks (current
> assets > current lianilities, medium term assets > medium term
> liabilities ...). Similar comparing groups of income & expense is desired.
>
> IMHO the ability to compare groups is as much, if not more important
> than compares over time.
>
> Regards
> Frank
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


[GNC-dev] about these account-summary reports...

2018-07-22 Thread Christopher Lam

I'll be aiming to replace and upgrade the following reports:

 * balance-sheet
 * income-statement
 * account-summary
 * budget-flow
 * cashflow

Basically all of above are using html-acct-table to create a 2D grid 
(vertical = accountlist, horizontal = indented amounts). I think I can 
upgrade to use a cleaner html-multicolumn-acct-table instead.


I will be merging their display/parent-balance-mode and 
display/parent-total-mode options into one. As far as I can see, there 
are only two valid combinations that will produce useful subtotal strategy:


1. parent-account-balances = "Account balance",
   parent-account-subtotals = "Show subtotals" - this matches my
   'multilevel subtotal strategy (i.e. each parent+children account
   family is followed by the parent+children subtotal)
2. parent-account-balances = "Subtotal", parent-account-subtotals = "Do
   Not Show" - this matches my 'recursive-bal subtotal strategy (i.e.
   parent amount incorporates whole children amounts, and if parent has
   own amount, display it as a child account on the next line)

The other options are invalid - i.e. Parent-account-balances = 'Do not 
show' will obligatorily lead to amounts missing whereby parent-account 
has an amount. And the Parent-account-subtotal = "Text book-style 
(experimental)" is internally known as 'canonically-tabbed', and the 
code is peppered with comments that "The canonically-tabbed option is 
currently broken."


Any other combination for subtotals will lead to duplication of amounts, 
or missing amounts.


Conclusion:

I will merge these two options into the saner 2-option recursive-bal vs. 
multilevel subtotal strategy. I'll try to maximise compatibility with 
saved reports, as well as set up a transitioning report for users 
wishing to use old reports (with another guid). But after 1 year I think 
it will be wise to remove old code.


Any queries please ask!

C

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-07-27 Thread Christopher Lam

Latest iteration of balsheet

 * restored amount-indenting. IMHO this is now producing sane indenting
   for any subtotal strategy
 * restore dual columns (i.e. left=asset/income, right=liability/expense)
 * the above two only enabled when multicols are disabled
 * option to toggle amount/account indenting
 * incorporated bug 623381 recommendations for sections labels/totals
 * added sections for equity, liability+equity
 * modify 'original-currency' display to match eguile report i.e.
   smaller font, precedes converted currency

I would really like feedback on

 * accuracy of amounts
 * accuracy of sections
 o further tweaking of option names/sections/ordering

Screenshot:
https://screenshots.firefox.com/nhaiX1ehSA2GXA97/null

On 25/07/18 15:53, Frank H. Ellenberger wrote:

Am 19.07.2018 um 13:09 schrieb Christopher Lam:

Hi Frank
Thank you - I can restore the dual-columns when the periods have been
disabled.
I'd prefer to limit the number of options; so, if the "period duration" is
disabled, the report will automatically show dual columns

while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
years in the Income statement.
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge


(Asset/Income=left, Liability+Equity/Expense = right). This works?
Can you please show me good examples of idealised T-account balance
sheet/income statement? Or the scaled form? I have no idea.

To get an impression you could starting from:

https://en.wikipedia.org/wiki/Balance_sheet - which has
#US_small_business in account form and #Sample in scaled form -
or

https://en.wikipedia.org/wiki/Income_statement and an example in account
form: https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv

Note: There are several different methods for grouping the positions
with differrent pros and cons allowed for different company types:
Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
better idea for the grouping than adjusting the account structure.

Optionally select other languages e.g.
https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz

HTH
Frank




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-06 Thread Christopher Lam
accounts to include in Short Term Liabilities, etc. 
Perhaps this can be somewhat determined or guessed by default, but that might be 
lots of work. The same would be needed for Income/P&L.

I find totals/subtotals above the child amounts to be odd. Perhaps less 
emphasis on the parent label, with maybe a colon indicator (like on the 
wikipedia entry) would be cleaner with a bold subtotal/total line will make the 
important numbers stand out more. (that is, not showing the amount on the 
initial label line at all)

Also, usually single lines are to delineate figures from subtotals and double 
lines to indicate totals from subtotals. (again like the wikipedia sample)

I don’t think the figures need to be indented as well, just marked off with 
single/double lines and appropriate line-spacing. For account indentions, does 
the report indent contra-accounts? Most statements I’ve seen that have them do 
so.

I understand and like that I have the option for levels deeper than 1 or 2, but 
usually such official statements are intended as an overview, not for detailed 
analysis. They should be very easy to read and decipher without extraneous info 
or styling. And ideally, you should accomplish this with plain-text monospaced. 
Perhaps work it back to that point and then embellish if needed.

A few minor points:
---

Is there is a reason why the child totals are also links? It lends a sense of 
clutter.

I noticed in the Equities & Liabilities section that some figures have no currency 
symbol. While I might be able to figure out what they are by studying the document, 
that info should be more readily discern-able at a glance. I’m puzzled by that section 
though. Usually it’s one or the other (separated or consolidated) but not both. Also, 
the total for Assets and the total for Liabilities & Equity should be on the same 
horizontal line when in 2-column mode.

I see too that some child amounts show in two currencies but not others. (looks 
like just the GBP accounts) Is this intended or just an illustration (or an 
omission)?

Regards,
Adrien


On Jul 27, 2018, at 8:01 AM, Christopher Lam  wrote:

Latest iteration of balsheet

* restored amount-indenting. IMHO this is now producing sane indenting
   for any subtotal strategy
* restore dual columns (i.e. left=asset/income, right=liability/expense)
* the above two only enabled when multicols are disabled
* option to toggle amount/account indenting
* incorporated bug 623381 recommendations for sections labels/totals
* added sections for equity, liability+equity
* modify 'original-currency' display to match eguile report i.e.
   smaller font, precedes converted currency

I would really like feedback on

* accuracy of amounts
* accuracy of sections
 o further tweaking of option names/sections/ordering

Screenshot:
https://screenshots.firefox.com/nhaiX1ehSA2GXA97/null

On 25/07/18 15:53, Frank H. Ellenberger wrote:

Am 19.07.2018 um 13:09 schrieb Christopher Lam:

Hi Frank
Thank you - I can restore the dual-columns when the periods have been
disabled.
I'd prefer to limit the number of options; so, if the "period duration" is
disabled, the report will automatically show dual columns

while intl. IFRS and DE-GOB/HGB reqire one, US-GAAP requires 3 previous
years in the Income statement.
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Vorjahresbetr%C3%A4ge


(Asset/Income=left, Liability+Equity/Expense = right). This works?
Can you please show me good examples of idealised T-account balance
sheet/income statement? Or the scaled form? I have no idea.

To get an impression you could starting from:

https://en.wikipedia.org/wiki/Balance_sheet  - which has
#US_small_business in account form and #Sample in scaled form -
or

https://en.wikipedia.org/wiki/Income_statement  and an example in account
form:https://debitoor.de/lexikon/gewinn-und-verlustrechnung-guv

Note: There are several different methods for grouping the positions
with differrent pros and cons allowed for different company types:
Gesamtkostenverfahren, Umsatzkostenverfahren & IFRS. Currently I have no
better idea for the grouping than adjusting the account structure.

Optionally select other languages e.g.
https://de.wikipedia.org/wiki/Bilanz#Aufbau_der_Bilanz

HTH
Frank



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-08 Thread Christopher Lam

Hi Frank,

I would think if the multiple categories of accounts are desired, they 
should be designed in the Chart of Accounts rather than the balance 
sheet. At least this is what I'd design my book as, rather than trying 
to code various formulas in scheme.


I've rendered the same test book multiple ways.

https://imgur.com/a/s5a3oZu

Notice

1. according to the house accountant, the 'retained earnings' shouldn't 
be part of balance sheet, right?


2. balsheet-eguile and balsheet-legacy calculate retained earnings 
differently - should these be included???


C


On 08/08/18 09:57, Frank H. Ellenberger wrote:

The tables in
https://de.wikipedia.org/wiki/Gewinn-_und_Verlustrechnung#Gliederung
show the grouping for the 3 regions AT (UGB), DE (HGB) and intl (IFRS).
The latter can be adapted for the less formal US (GAAP). They are shown
for 2 different methods:
Period costing Method (Gesamtkostenverfahren) and
Cost of Sales Method (Umsatzkostenverfahren)

I have currently no idea, how to get this different forms from the
report by options.



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-08 Thread Christopher Lam

Hi devs,

On 09/08/18 08:32, John Ralls wrote:

On Aug 8, 2018, at 8:51 AM, Geert Janssens  wrote:

I haven't been following every detail of this. However I note on most balance
sheets the total assets doesn't match total net worth (or liabilities/equity).
In most, this is fixed by including the retained earnings.

I believe at least in most European countries the "left hand side" (Assets,
Active) and "right hand side" (Passive or liabilities + equity) of the
multicolumn view should balance (it's called balance sheet for a reason).
That would suggest retained earnings does have to be part of the balance
sheet.

However I'm not an accountant and perhaps your book is slightly contrived so I
don't know the exact answer here.
This book is not particularly contrived :) there are no imbalance or 
orphan accounts; there's EUR/USD/FUND; there's pricing USD/FUND only; 
there are a few income txns; and Asset:Broker is the only parent-account 
its own balance. It aims to test most aspects of balsheet. I've attached 
datafile, and it can be loaded to try existing balance-sheet and 
eguile-balsheet to confirm the $32.50 vs $32.00 discrepancy.

As for the "multi-column" vs one column debate, both present the same data.
The only difference is visual representation or style.

As of recently I have become a strong proponent of separating structure (or
accounting functionality in a different context) from style, I think this
should be delegated to the realm of css. This particular layout variation can
IMO be handled by making divs for each large group and either let them follow
normal flow or use float to move them next to each other. If you will you can
have a European style sheet and an American one, or an Australian or whatever.
This dual- or single-column or asset/liability/equity or 
asset/equity/liability sounds reasonable to define in CSS.


Account Names are either displayed indented, or as full-account-name -- 
any other option would be too confusing.


Account Balances are either displayed indented (same as account-depth, 
with a few exceptions) or single-column. I'd rather not do indenting in 
CSS because I can't figure out CSS. The CSS style would be ":n columns" 
or something and I have not idea how this works.

The Balance Sheet is indeed supposed to balance, but in normal practice it 
balances only when the book is “closed”, i.e. when all of the income and 
expense accounts are summed up and added to Equity. In US corporate books the 
cumulative total of income and expenses lives in an Equity account called 
“Retained Earnings”.

In the pen-and-paper days a  “Trial Balance” was computed outside of the books 
before closing as a way to catch errors before making the closing entries and 
writing the formal Balance Sheet.

GnuCash's existing Balance Sheet Report creates the “Retained Earnings” line so 
that one need not close the books (Tools>Close Book) in order to get a balanced 
report. Removing that feature might be more formally correct but it would mean 
that users would have to close their book before running a balance sheet. That 
would be a big change and I don’t think that we want to do it. On the other hand 
“Retained Earnings” isn’t the right term for many cases, so it would be a useful 
improvement to make it configurable.
Aha this is where the discrepancy and the retained earnings line comes 
from!... I haven't solved this yet, and still trying to figure out how 
it should work.

There’s a second problem with the current report as well: If the user does 
close their books periodically they’ll have an account for the accumulation 
that may well be called “Retained Earnings”. The Balance Sheet Report will 
dutifully report the contents of that account and, if there are income and 
expenses after the last close, add a second “Retained Earnings” line. That 
looks a bit odd and might be confusing; ISTR we’ve had comments on the user 
list about just that.

Agreed


CL&SB Inc.gnucash
Description: application/gnucash
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-10 Thread Christopher Lam

Hi John

I've managed to make the left-side (activa?) match the right-side (passiva?)

https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null

1) it does require closing books on the balance-sheet date

2) it does require adding trading-accounts

The existing balsheet introduces/calculates the "Retained Earnings", 
"Trading Gains" and "Unrealized Gains", whereas the current iteration of 
new-balsheet will not.


To me this is the easiest method to ensure both sides produce the same 
total, and is now technically correct - if the user has not closed their 
books, the balance sheet won't balance.


This is giving me a headache :(

Should a new balsheet calculate and report these '(fake) retained 
earnings', and 'unrealized gains' ???


C


On 09/08/18 08:32, John Ralls wrote:



On Aug 8, 2018, at 8:51 AM, Geert Janssens  wrote:

I haven't been following every detail of this. However I note on most balance
sheets the total assets doesn't match total net worth (or liabilities/equity).
In most, this is fixed by including the retained earnings.

I believe at least in most European countries the "left hand side" (Assets,
Active) and "right hand side" (Passive or liabilities + equity) of the
multicolumn view should balance (it's called balance sheet for a reason).
That would suggest retained earnings does have to be part of the balance
sheet.

However I'm not an accountant and perhaps your book is slightly contrived so I
don't know the exact answer here.

As for the "multi-column" vs one column debate, both present the same data.
The only difference is visual representation or style.

As of recently I have become a strong proponent of separating structure (or
accounting functionality in a different context) from style, I think this
should be delegated to the realm of css. This particular layout variation can
IMO be handled by making divs for each large group and either let them follow
normal flow or use float to move them next to each other. If you will you can
have a European style sheet and an American one, or an Australian or whatever.

As for "categories", I read Frank's earlier reply as if he agreed that at
least for now the account organization is something to be done in the CoA, not
in report code.

The Balance Sheet is indeed supposed to balance, but in normal practice it 
balances only when the book is “closed”, i.e. when all of the income and 
expense accounts are summed up and added to Equity. In US corporate books the 
cumulative total of income and expenses lives in an Equity account called 
“Retained Earnings”.

In the pen-and-paper days a  “Trial Balance” was computed outside of the books 
before closing as a way to catch errors before making the closing entries and 
writing the formal Balance Sheet.

GnuCash's existing Balance Sheet Report creates the “Retained Earnings” line so 
that one need not close the books (Tools>Close Book) in order to get a balanced 
report. Removing that feature might be more formally correct but it would mean 
that users would have to close their book before running a balance sheet. That 
would be a big change and I don’t think that we want to do it. On the other hand 
“Retained Earnings” isn’t the right term for many cases, so it would be a useful 
improvement to make it configurable.

There’s a second problem with the current report as well: If the user does 
close their books periodically they’ll have an account for the accumulation 
that may well be called “Retained Earnings”. The Balance Sheet Report will 
dutifully report the contents of that account and, if there are income and 
expenses after the last close, add a second “Retained Earnings” line. That 
looks a bit odd and might be confusing; ISTR we’ve had comments on the user 
list about just that.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-12 Thread Christopher Lam

Hi Jralls

So just wish to double check my understanding of gnucash's data format 
for a balance-sheet on date X


There are two possibilities for displaying the right-hand-side

1. Liabilities + Equity + Retained Earnings + Trading Balances
2. Liabilities + Equity + Retained Earnings + Unrealized Gains

"Retained Earnings" should be NULL if the user has properly closed the 
books on the balance sheet date X.


In my understanding, "Trading Balances" and "Unrealized Gains" are one 
and the same -- in balance-sheet.scm the unrealized-gain-collector is 
only populated if book->trading-accounts setting is disabled. (btw this 
causes a 'bug' whereby a book with 'enable-trading-accounts', but was 
later switched to 'disable-trading-accounts' will then add both the 
unrealized-gain-collector and the trading-balance the right-hand-side).


This seems to be deconstruct current balance-sheet?

(I can't seem to find any unrealized-gain issue... from using different 
price-sources... perhaps this is beyond my understanding.)



On 11/08/18 22:41, John Ralls wrote:

Chris,

Remember that we’ve long advised users that they need not close their 
books, they can run a balance sheet report for any day. IMO removing 
that capability would be a major breakage.


I suspect that you needed to use trading accounts because you didn’t 
book the trading gains and losses as income. Users should do that 
regardless of using trading accounts and doing so should make it 
unnecessary for the balance sheet report to include trading accounts.


Unrealized gains are another matter entirely and are a result of using 
prices from the price database instead of actual cost from the 
transaction data. IMO the balance sheet report shouldn’t be taking 
prices from the price db and shouldn’t be able to see unrealized 
gains, but if price source is going to be an option then an unrealized 
gains line flows from that so that users don’t waste a bunch of time 
chasing an imbalance caused by price differences.


https://bugs.gnucash.org/show_bug.cgi?id=775368 is related because 
that’s currently how the balance sheet report gets the “actual” costs.


Regards,
John Ralls

On Aug 10, 2018, at 11:40 PM, Christopher Lam 
mailto:christopher@gmail.com>> wrote:


Hi John

I've managed to make the left-side (activa?) match the right-side 
(passiva?)


https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null

1) it does require closing books on the balance-sheet date

2) it does require adding trading-accounts

The existing balsheet introduces/calculates the "Retained Earnings", 
"Trading Gains" and "Unrealized Gains", whereas the current iteration 
of new-balsheet will not.


To me this is the easiest method to ensure both sides produce the 
same total, and is now technically correct - if the user has not 
closed their books, the balance sheet won't balance.


This is giving me a headache :(

Should a new balsheet calculate and report these '(fake) retained 
earnings', and 'unrealized gains' ???


C


On 09/08/18 08:32, John Ralls wrote:


On Aug 8, 2018, at 8:51 AM, Geert Janssens 
 wrote:


I haven't been following every detail of this. However I note on 
most balance
sheets the total assets doesn't match total net worth (or 
liabilities/equity).

In most, this is fixed by including the retained earnings.

I believe at least in most European countries the "left hand side" 
(Assets,

Active) and "right hand side" (Passive or liabilities + equity) of the
multicolumn view should balance (it's called balance sheet for a 
reason).
That would suggest retained earnings does have to be part of the 
balance

sheet.

However I'm not an accountant and perhaps your book is slightly 
contrived so I

don't know the exact answer here.

As for the "multi-column" vs one column debate, both present the 
same data.

The only difference is visual representation or style.

As of recently I have become a strong proponent of separating 
structure (or
accounting functionality in a different context) from style, I 
think this
should be delegated to the realm of css. This particular layout 
variation can
IMO be handled by making divs for each large group and either let 
them follow
normal flow or use float to move them next to each other. If you 
will you can
have a European style sheet and an American one, or an Australian 
or whatever.


As for "categories", I read Frank's earlier reply as if he agreed 
that at
least for now the account organization is something to be done in 
the CoA, not

in report code.
The Balance Sheet is indeed supposed to balance, but in normal 
practice it balances only when the book is “closed”, i.e. when all 
of the income and expense accounts are summed up and added to 
Equity. In US corporate books the cumulative total of income and 
exp

Re: [GNC-dev] Training

2018-08-12 Thread Christopher Lam
Hi David

There is definitely a gap in this space. The old video
https://youtu.be/aqAaScYVeRQ is still covering the basics. Perhaps you can
focus on more more modern aspects?

On Thu, 9 Aug 2018, 22:18 David Tinoco  wrote:

> I am very interested in learning the ins and outs of GnuCash.
>
> I am also a professional videographer/animator and web developer.
>
> I was wondering if there is an interest in creating video tutorials for the
> various aspects of GnuCash. I think this would be very useful; even if the
> basics were covered (accounts setup, transaction entry, budget feature,
> reports, etc.)
>
> I would be willing to undertake the videos if I could have another person
> on the team that got me through the ropes on this.
>
> Is there a need for/interest in this?
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Training

2018-08-13 Thread Christopher Lam
It's customary here to keep discussions public. I don't use the budgets
feature at all and cannot help sorry.

My preference is to implement envelope budgeting, and the inbuilt budget is
not envelope budgeting at all.

On Tue, 14 Aug 2018, 00:08 David Tinoco  wrote:

> Hi Christopher,
>
> Thanks for getting back to me. Yes, I know the basics. I have been using
> it for about 2 years now.
>
> I have really wanted to get into the budget feature but I simply cannot
> figure it out.
>
> I am trying to figure out a way to create a budget and then report on the
> categories to show how much I have spent on an expense account compared to
> my budget.
>
> Currently, the only thing I can figure out is making a budget and then
> separately running an expenses report.
>
> But if there was a way to calculate the expenses automatically for that
> budget it would be great. Can this be done?
>
> Also, I don't understand the transfer row in the budget window and how
> that works with accounts.
>
> There are so many great features to this program--wish I could work with a
> guru and make a bunch of videos for you guys.
>
> Thanks,
> David
>
> On Mon, Aug 13, 2018 at 2:28 AM Christopher Lam 
> wrote:
>
>> Hi David
>>
>> There is definitely a gap in this space. The old video
>> https://youtu.be/aqAaScYVeRQ is still covering the basics. Perhaps you
>> can focus on more more modern aspects?
>>
>> On Thu, 9 Aug 2018, 22:18 David Tinoco  wrote:
>>
>>> I am very interested in learning the ins and outs of GnuCash.
>>>
>>> I am also a professional videographer/animator and web developer.
>>>
>>> I was wondering if there is an interest in creating video tutorials for
>>> the
>>> various aspects of GnuCash. I think this would be very useful; even if
>>> the
>>> basics were covered (accounts setup, transaction entry, budget feature,
>>> reports, etc.)
>>>
>>> I would be willing to undertake the videos if I could have another person
>>> on the team that got me through the ropes on this.
>>>
>>> Is there a need for/interest in this?
>>> ___
>>> gnucash-devel mailing list
>>> gnucash-devel@gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>
>>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-13 Thread Christopher Lam
Hi John

Thank you - plenty of material here for test cases.

I note your observation that selling a stock at an increased price, in a
book without trading-accounts, without properly booking the capital-gain to
income leads to an incorrect balance-sheet. This is illus by txn-A and
txn-B below. This shouldn't arise -- all cap-gains must be documented
according to documentation - either together with the sell transaction, or
in a separate transaction. So, IMHO the incorrect report as you found out
does not really need fixing.

01-jan-18 Txn-A - buy
Asset:Broker -$1
Asset:Broker:Stock +100 AAPL (+$1)

01-jun-18 Txn-B - sell
Asset:Broker +$2
Asset:Broker:Stock -100 AAPL (-$2)

01-jun-18 Txn-C - cap-gain
Asset:Broker:Stock 0AAPL (+$1)
Income:Capital-Gains -$1

Moreover, about that price-source... I'll try and replicate.

C
On 13/08/18 22:51, John Ralls wrote:



On Aug 12, 2018, at 10:04 PM, Christopher Lam 
wrote:

Hi Jralls

So just wish to double check my understanding of gnucash's data format for
a balance-sheet on date X

There are two possibilities for displaying the right-hand-side

   1. Liabilities + Equity + Retained Earnings + Trading Balances
   2. Liabilities + Equity + Retained Earnings + Unrealized Gains

"Retained Earnings" should be NULL if the user has properly closed the
books on the balance sheet date X.

In my understanding, "Trading Balances" and "Unrealized Gains" are one and
the same -- in balance-sheet.scm the unrealized-gain-collector is only
populated if book->trading-accounts setting is disabled. (btw this causes a
'bug' whereby a book with 'enable-trading-accounts', but was later switched
to 'disable-trading-accounts' will then add both the
unrealized-gain-collector and the trading-balance the right-hand-side).

This seems to be deconstruct current balance-sheet?

(I can't seem to find any unrealized-gain issue... from using different
price-sources... perhaps this is beyond my understanding.)

On 11/08/18 22:41, John Ralls wrote:

Chris,

Remember that we’ve long advised users that they need not close their
books, they can run a balance sheet report for any day. IMO removing that
capability would be a major breakage.

I suspect that you needed to use trading accounts because you didn’t book
the trading gains and losses as income. Users should do that regardless of
using trading accounts and doing so should make it unnecessary for the
balance sheet report to include trading accounts.

Unrealized gains are another matter entirely and are a result of using
prices from the price database instead of actual cost from the transaction
data. IMO the balance sheet report shouldn’t be taking prices from the
price db and shouldn’t be able to see unrealized gains, but if price source
is going to be an option then an unrealized gains line flows from that so
that users don’t waste a bunch of time chasing an imbalance caused by price
differences.

https://bugs.gnucash.org/show_bug.cgi?id=775368 is related because that’s
currently how the balance sheet report gets the “actual” costs.

Regards,
John Ralls

On Aug 10, 2018, at 11:40 PM, Christopher Lam 
wrote:

Hi John

I've managed to make the left-side (activa?) match the right-side (passiva?)

https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null

1) it does require closing books on the balance-sheet date

2) it does require adding trading-accounts

The existing balsheet introduces/calculates the "Retained Earnings",
"Trading Gains" and "Unrealized Gains", whereas the current iteration of
new-balsheet will not.

To me this is the easiest method to ensure both sides produce the same
total, and is now technically correct - if the user has not closed their
books, the balance sheet won't balance.

This is giving me a headache :(

Should a new balsheet calculate and report these '(fake) retained
earnings', and 'unrealized gains' ???

C


On 09/08/18 08:32, John Ralls wrote:


On Aug 8, 2018, at 8:51 AM, Geert Janssens 
 wrote:

I haven't been following every detail of this. However I note on most
balance
sheets the total assets doesn't match total net worth (or
liabilities/equity).
In most, this is fixed by including the retained earnings.

I believe at least in most European countries the "left hand side" (Assets,
Active) and "right hand side" (Passive or liabilities + equity) of the
multicolumn view should balance (it's called balance sheet for a reason).
That would suggest retained earnings does have to be part of the balance
sheet.

However I'm not an accountant and perhaps your book is slightly contrived
so I
don't know the exact answer here.

As for the "multi-column" vs one column debate, both present the same data.
The only difference is visual representation or style.

As of recently I have become a strong proponent of sep

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-16 Thread Christopher Lam

Hi John

Just to be a pain again... I found a small discrepancy - (This is 
different from the previously noted missing-capital-gains situation)


 * if trading-accounts are enabled,
 * a single 100AAPL purchase @ $100 each dated 01/01/18
 * a new increased price $200 on 01/06/18 is recorded,
 * price-source is 'latest' to pick up the new price

There's no trade sale yet -- this means 'trading gains' is $0 -- indeed 
the book will not have any Trading accounts yet.


I'd expect the balance-sheet to record the increased price as 
'unrealized gain'.


Yet the balance-sheet just displays an increased FUNDS valuation at 
$20,000 (i.e. total assets = $2) without a corresponding increase in 
right-hand-side (ie total equity+liability=$1).


I'd think the 'correct' balance sheet with trading-accounts enabled, 
*should* still report Unrealized Gains, no?



On 13/08/18 22:51, John Ralls wrote:



On Aug 12, 2018, at 10:04 PM, Christopher Lam 
mailto:christopher@gmail.com>> wrote:


Hi Jralls

So just wish to double check my understanding of gnucash's data 
format for a balance-sheet on date X


There are two possibilities for displaying the right-hand-side

 1. Liabilities + Equity + Retained Earnings + Trading Balances
 2. Liabilities + Equity + Retained Earnings + Unrealized Gains

"Retained Earnings" should be NULL if the user has properly closed 
the books on the balance sheet date X.


In my understanding, "Trading Balances" and "Unrealized Gains" are 
one and the same -- in balance-sheet.scm the 
unrealized-gain-collector is only populated if book->trading-accounts 
setting is disabled. (btw this causes a 'bug' whereby a book with 
'enable-trading-accounts', but was later switched to 
'disable-trading-accounts' will then add both the 
unrealized-gain-collector and the trading-balance the right-hand-side).


This seems to be deconstruct current balance-sheet?

(I can't seem to find any unrealized-gain issue... from using 
different price-sources... perhaps this is beyond my understanding.)



On 11/08/18 22:41, John Ralls wrote:

Chris,

Remember that we’ve long advised users that they need not close 
their books, they can run a balance sheet report for any day. IMO 
removing that capability would be a major breakage.


I suspect that you needed to use trading accounts because you didn’t 
book the trading gains and losses as income. Users should do that 
regardless of using trading accounts and doing so should make it 
unnecessary for the balance sheet report to include trading accounts.


Unrealized gains are another matter entirely and are a result of 
using prices from the price database instead of actual cost from the 
transaction data. IMO the balance sheet report shouldn’t be taking 
prices from the price db and shouldn’t be able to see unrealized 
gains, but if price source is going to be an option then an 
unrealized gains line flows from that so that users don’t waste a 
bunch of time chasing an imbalance caused by price differences.


https://bugs.gnucash.org/show_bug.cgi?id=775368 is related because 
that’s currently how the balance sheet report gets the “actual” costs.


Regards,
John Ralls

On Aug 10, 2018, at 11:40 PM, Christopher Lam 
mailto:christopher@gmail.com>> wrote:


Hi John

I've managed to make the left-side (activa?) match the right-side 
(passiva?)


https://screenshots.firefox.com/RNvkjaxnYyxpGkYn/null

1) it does require closing books on the balance-sheet date

2) it does require adding trading-accounts

The existing balsheet introduces/calculates the "Retained 
Earnings", "Trading Gains" and "Unrealized Gains", whereas the 
current iteration of new-balsheet will not.


To me this is the easiest method to ensure both sides produce the 
same total, and is now technically correct - if the user has not 
closed their books, the balance sheet won't balance.


This is giving me a headache :(

Should a new balsheet calculate and report these '(fake) retained 
earnings', and 'unrealized gains' ???


C


On 09/08/18 08:32, John Ralls wrote:


On Aug 8, 2018, at 8:51 AM, Geert Janssens 
 wrote:


I haven't been following every detail of this. However I note on 
most balance
sheets the total assets doesn't match total net worth (or 
liabilities/equity).

In most, this is fixed by including the retained earnings.

I believe at least in most European countries the "left hand 
side" (Assets,
Active) and "right hand side" (Passive or liabilities + equity) 
of the
multicolumn view should balance (it's called balance sheet for a 
reason).
That would suggest retained earnings does have to be part of the 
balance

sheet.

However I'm not an accountant and perhaps your book is slightly 
contrived so I

don't know the exact answer here.

As fo

Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-08-17 Thread Christopher Lam

Hi David

I refer you to a prior discussion: 
https://lists.gnucash.org/pipermail/gnucash-user/2018-June/077758.html


I appreciate balance-sheet is a formal accounting report. The problem 
is, as always, within the details.


Initially I thought we could leave currencies unconverted.

Then Geert reminded me *all* currencies *must* be allowed to convert to 
a user-selected common-currency. Because a balance-sheet is really a 
valuation of all of your assets, into a legal currency of your choice. 
The price used must be either (1) actual transactional prices - either 
average-cost or weighted-average - both terms whose exact definitions 
currently elude me despite looking at code (2) from the pricedb - 
latest/nearest.


(* PS what's the strategy if accounts are in EUR/USD/GBP, with plenty of 
pricing data in these 3 currencies, but user prefers common-currency to 
be JPY, and pricedb has EUR/USD, USD/GBP, GBP/AUD and AUD/JPY amounts? 
Answer: Internal logic will try to find an intermediate pricedb pair, 
eg. GBP->AUD->JPY at the nearest date available, and EUR/USD will result 
to 0 JPY Except my report will convert GBP->JPY correctly and leave 
EUR/USD in original currency )


The next issues are all to do with Equity:

(1) trading-accounts are optional. As we know, trading accounts will 
compute _REALIZED GAINS,_ so that EUR>USD>EUR transfers at different 
prices *must* result in a realized-gain recording. If the 
trading-accounts are disabled, the current balance-sheet will make an 
attempt at computing its own Realized Gains. It assumes the user hasn't 
recorded realized-gains during currency conversions. IMHO There's 
currently a logic error if there are trading-accounts in a book with 
book property trading-accounts disabled. Moreover, if trading-accounts 
are disabled, and the user has recorded but underestimated realized 
gains, I think the balsheet *should* report the delta amount as 
unrealized-gains too???


(2) selection of a report common-currency must compute _UNREALIZED 
GAINS_, e.g. if EUR/USD/GBP accounts are reported for balsheet in JPY, 
and JPY has increased in value between transaction-dates and 
report-date, presumably all amounts must increase? This is not proven 
correctly handled yet. I still think there's an error - the Asset 
report-currency amount will use the higher price, but the unrealized 
gains are not computed when trading-accounts are disabled.


(3) income and expense amounts are technically closed to equity on 
balsheet-date but we don't enforce this, so, their difference must 
account for _RETAINED EARNINGS_ or some other similar heading. If user 
has closed books correctly on balsheet-date, then the balsheet should 
report retained earnings to be $0.


If anyone can help me, please do. Spreadsheets or formula sheets 
welcome. Double-entry is all fun and games until trying to compute a 
balance-sheet! The above, not an accountant yadda yadda.


On 17/08/18 00:27, David T. wrote:

Hi,

I admit that I haven’t been following the details of thsi thread that closely, 
but it would seem to me that if a user has selected price source “Latest,” then 
the report will of necessity include an Unrealized Gains line in order to 
balance, as John said. I agree with his suggestion that Unrealized Gains might 
not belong in a Balance Sheet report, but I note that as a personal user of 
GnuCash, I am rather interested in the current value of my empire, ephemeral 
though it may be. I’m eager to see how rich I am Right Now! Bwa Ha Ha Ha!

Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
accounting to refer to a particular general type of report and content (I base 
this on the fact that Googling “Balance Sheet report definition” yields 
numerous accounting websites with explanations of what a balance sheet is and 
does), perhaps there could be a separately-identified and named report to give 
the armchair trader the putative value of their holdings as of a given date. 
Then the Balance Sheet could be dedicated to the real world situation (i.e., no 
need for the PriceDB at all—just use the transaction prices), while the new 
report could include unrealized gains explicitly. A descriptive name (“Trade 
Value”? “Speculative Value”? “Castles in the Sand”?) could help make clear the 
difference between the two.

David


On Aug 16, 2018, at 7:30 AM, John Ralls  wrote:

Chris,

That’s because you used price source = “latest” which uses the most recent 
price in the pricedb for the purchase as well as the valuation.

Regards,
John Ralls


On Aug 16, 2018, at 12:58 AM, Christopher Lam  wrote:

Hi John

Just to be a pain again... I found a small discrepancy - (This is different 
from the previously noted missing-capital-gains situation)

if trading-accounts are enabled,
a single 100AAPL purchase @ $100 each dated 01/01/18
a new increased price $200 on 01/06/18 is recorded,
price-source is 'latest' to pick up the

Re: [GNC-dev] Register Documentation Improvements (was Re: [GNC]Column widths again)

2018-08-23 Thread Christopher Lam
> So does GitHub (it’s the pencil icon to the right of Raw/Blame/History), 
> which also has a desktop front-end, https://desktop.github.com/ 
>  and a button on a file’s webpage that opens the 
> file in Github Desktop.
> I haven’t tried any of them, but perhaps David T. might like to and give us a 
> non-developer perspective.

I can confirm that 1 year ago I was hacking transaction.scm in Windows, using 
Notepad++, pasting changes into the GitHub.com web-based editor, checking edits 
using the Preview tab, until I learned enough command-line git, then emacs, 
then emacs-magit...
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] New balsheet (and P&L report), API considerations, and (slow?) KVP in Account.cpp

2018-09-05 Thread Christopher Lam
Hi All

The state of balsheet-pnl for now, imho is feature complete and has nicer
well-documented internal functions. However I'm still stumped by various
equity calculations, unsure how to emulate all combinations of
trading/unrealized/realized gains/losses. JRalls has helpfully created some
illustrative tests, but these would need plugging into the new balsheet
which isn't immediately obvious. And for me to spend a few months getting
to understand the formulas.

For this matter I wouldn't be keen to replace the current balsheet yet. I
know some users are keen to maintain the current balsheet's calculations
and I can't guarantee the new one will produce the same equity section.

So, for now, the options are to add the multicolumn balsheet as a new menu
item and seek user feedback about equity calculations, or leave it unmerged
and unfinished, which is another shame.

On Fri, 17 Aug 2018 at 21:20, Christopher Lam 
wrote:

> Hi David
>
> I refer you to a prior discussion:
> https://lists.gnucash.org/pipermail/gnucash-user/2018-June/077758.html
>
> I appreciate balance-sheet is a formal accounting report. The problem is,
> as always, within the details.
>
> Initially I thought we could leave currencies unconverted.
>
> Then Geert reminded me *all* currencies *must* be allowed to convert to a
> user-selected common-currency. Because a balance-sheet is really a
> valuation of all of your assets, into a legal currency of your choice. The
> price used must be either (1) actual transactional prices - either
> average-cost or weighted-average - both terms whose exact definitions
> currently elude me despite looking at code (2) from the pricedb -
> latest/nearest.
> (* PS what's the strategy if accounts are in EUR/USD/GBP, with plenty of
> pricing data in these 3 currencies, but user prefers common-currency to be
> JPY, and pricedb has EUR/USD, USD/GBP, GBP/AUD and AUD/JPY amounts? Answer:
> Internal logic will try to find an intermediate pricedb pair, eg.
> GBP->AUD->JPY at the nearest date available, and EUR/USD will result to 0
> JPY Except my report will convert GBP->JPY correctly and leave EUR/USD
> in original currency )
>
> The next issues are all to do with Equity:
>
> (1) trading-accounts are optional. As we know, trading accounts will
> compute *REALIZED GAINS,* so that EUR>USD>EUR transfers at different
> prices *must* result in a realized-gain recording. If the trading-accounts
> are disabled, the current balance-sheet will make an attempt at computing
> its own Realized Gains. It assumes the user hasn't recorded realized-gains
> during currency conversions. IMHO There's currently a logic error if there
> are trading-accounts in a book with book property trading-accounts
> disabled. Moreover, if trading-accounts are disabled, and the user has
> recorded but underestimated realized gains, I think the balsheet *should*
> report the delta amount as unrealized-gains too???
>
> (2) selection of a report common-currency must compute *UNREALIZED GAINS*,
> e.g. if EUR/USD/GBP accounts are reported for balsheet in JPY, and JPY has
> increased in value between transaction-dates and report-date, presumably
> all amounts must increase? This is not proven correctly handled yet. I
> still think there's an error - the Asset report-currency amount will use
> the higher price, but the unrealized gains are not computed when
> trading-accounts are disabled.
>
> (3) income and expense amounts are technically closed to equity on
> balsheet-date but we don't enforce this, so, their difference must account
> for *RETAINED EARNINGS* or some other similar heading. If user has closed
> books correctly on balsheet-date, then the balsheet should report retained
> earnings to be $0.
> If anyone can help me, please do. Spreadsheets or formula sheets welcome.
> Double-entry is all fun and games until trying to compute a balance-sheet!
> The above, not an accountant yadda yadda.
>
> On 17/08/18 00:27, David T. wrote:
>
> Hi,
>
> I admit that I haven’t been following the details of thsi thread that 
> closely, but it would seem to me that if a user has selected price source 
> “Latest,” then the report will of necessity include an Unrealized Gains line 
> in order to balance, as John said. I agree with his suggestion that 
> Unrealized Gains might not belong in a Balance Sheet report, but I note that 
> as a personal user of GnuCash, I am rather interested in the current value of 
> my empire, ephemeral though it may be. I’m eager to see how rich I am Right 
> Now! Bwa Ha Ha Ha!
>
> Seriously, though, since “Balance Sheet” seems to be a commonly-used term in 
> accounting to refer to a particular general type of report and content (I 
> base this on the fact

Re: [GNC-dev] merging failing tests

2018-09-05 Thread Christopher Lam

Hi

As an untrained hacker, I think the issue is whether these "bugs" are 
really worth fixing at all.


I can imagine the history of the dark ages; and html was being refined, 
and previously the reports were outputting plaintext or directly to 
screen via X calls; the hackers decide to start outputting html via a 
new upcoming framework called gtkhtml, with fancy tables, italics, font 
sizes... GTKhtml comes with an over-engineered api to accept x/y 
coordinates, font families, headers, pre-CSS style-sheets, paper size. 
The hacker succeeds in outputting reports and uses the api calls to 
render a nice report, helpfully reusing gtkhtml terminology.


Time has evolved, and gtkhtml is now obsolete. The api calls must be 
changed to output html. The next hacker tries to fix the minimum code to 
remove gtkhtml code, but every time a change happens, some reports break 
or dataloss occurs. Therefore they fix the minimum code to move away 
from gtkhtml and leave large swathes of dead old code around. "If it's 
not broke, don't fix it!"


I think that completing the internal framework to successfully implement 
html api code (as you have identified is incomplete) is not time well 
spent. None of the reports will generate html without headers, for 
instance. So, the code for testing headers should be ripped out, rather 
than implemented. And code should be ripped out safely, ensuring no 
tests fail, no dataloss occurs, all reports pass (including the existing 
multicolumn report) and all potential users (including those not 
subscribed to userlist or devel) are unaffected, and no subsequent 
hacker will have to fix.


There is still a need for more hackers, so, I'm sure your efforts are 
appreciated, but it's already a major headache to try understand the 
previous hackers and we don't want the situation to get worse.


I think this helps? I'd love to add more features too but I'm 
constraining myself too because every new code snippet, framework, or 
boolean test is another headache for future maintainers.


On 06/09/18 05:12, Carsten Rinke wrote:

Hi John,

I transfer this thread to this channel because I think this is not PR 
specific but more a general issue.


Let me start by saying that I do not want to "fight to get it merged". 
For me it is an interesting point to exchange views upon.


It is specifically about "We're not merging failing tests".

Example: PR#391
I have tried to follow your advice how to write SRFI-64 as good as I 
can at this point of time (I'm sure you will still find room for 
improvement, and that is fully ok).


In the test result from travis you can now see which tests are 
failing, and why, and I even mentioned the bug reports that I opened 
for it.


That the tests are not merged straight away is expected, no discussion 
about it, especially as long as the indicated bugs are not finally 
accepted as bugs.


But assume we agree that some bugs are really bugs, meaning, the test 
is correct, and it is correct that it is failing because the code is 
wrong:

Why not merging a failing test? Why waiting for the code fix?

Just to repeat: Please take these as open questions, I am not 
suggesting an answer here.


BTW:
I think I can propose fixes for most of the indicated bugs in PR#391, 
but I was planning to forward them as separate PRs. Good that you 
mention that I should place them into the existing PR.


/Carsten


Am 05.09.2018 um 01:29 schrieb John Ralls:


Since you haven't followed my instructions about how to write a 
SRFI-64 test it's impossible to tell from the output what is the 
problem... including knowing whether there's actually a bug in the 
gnc-html code or if it's in your tests. Yes, that's a defect in most 
of the Scheme test code, but fixing it was one of the main goals of 
adopting a proper unit test framework.


If your tests did find bugs then the PR needs to include fixes as 
separate commits. We're not merging failing tests and we're not 
merging non-tests. Consider that both of the failing tests in this PR 
seem not to matter: All of the existing report tests pass and the 
line charts work in use. If an important jqplot module isn't present 
or if the line chart plotting code was actually defective on Arch 
Linux that wouldn't be the case.


—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub 
, 
or mute the thread 
.




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Long Term Documentation Directions

2018-09-10 Thread Christopher Lam
On Mon, 10 Sep 2018 at 19:31, David Cousens 
wrote:

>
> One problem I see for Unix is that at present there doesn't appear to be a
> help viewer in Unix that has support for context level help. Doc books can
> obviously support defining links that can be accessed from help buttons or
> a
> key based popup help but as far as I could see yelp has no mechanism for
> linking to them.
>

Is there any merit to the idea of launching documentation and
context-sensitive help as a libwebkit tab?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] GnuCash 3.3 Released

2018-10-01 Thread Christopher Lam
Hi all

While everyone is busy shaking the program to weed out any new bugs, please be 
aware that the invoice reports have been modified, with an aim for greater 
maintainability (i.e. printable invoice, easy-invoice, fancy-invoice now share 
the same code base and have been approximated as well as possible to the 
original reports) and flexibility (invoice headers e.g. date, client details, 
invoice details etc can now be reordered at will; insert company logo; full CSS 
customisation). 

Please send any comments via bug reports.


From: John Ralls
Sent: Monday, 1 October 2018 4:48 AM
To: Gnucash-User
Cc: gnucash-devel; gnucash-annou...@gnucash.org
Subject: [GNC-dev] GnuCash 3.3 Released

The GnuCash development team announces GnuCash 3.3, the fourth release of the 
3.x stable release series.

Changes

Between 3.2 and 3.3, the following bugfixes were accomplished:

• Bug 771667 - Different warnings when changing reconciled splits vs. 
splits linked to reconciled splits.
• Bug 784420 - "Save changes on closing" window waits 2^32 seconds when 
"Time to wait for answer" is set 0.
• Bug 786708 - GnuCash won't load currency fractions larger than 
100. Also create larger fractions for the account dialog.
• Bug 787439 - Segmentation Fault in Transfer dialog after clearing 
Date field and pressing escape.
• Bug 789594 - Unable to overwrite sqlite3 database file.
• Bug 792446 - Mixed languages in error dialog.
• Bug 794526 - Python bindings can't find loadable modules.
• Bug 794755 - Commodity Register displays fractional prices.
Prices will now be displayed in decimal, rounded to two more places than the 
currency's smallest unit.

• Bug 794870 - If no book is opened, gnucash still asks if the user 
wants to save changes when opening a file.
• Bug 795821 - GnuCash could not obtain the lock for 
file://C:\Users\username\Documents\GnuCash\2.6.21\\.gnucash
• Bug 796054 - Unposting and reposting invoice doubles amounts.
• Bug 796137 - query.search_for outputs critical qof.object errors and 
prevents queries being run.
• Bug 796248 - Editing Scheduled Transaction.
In addition to not begining to edit already-loaded transactions, don't try to 
load splits that are already loaded. It shouldn't be possible to load a 
transaction without also loading its splits.

• Bug 796474 - Segmentation fault while setting up online banking.
Allow only a single instance of the assistant.

• Bug 796509 - Saved reports don't respect *some* 'Edit report options'.
• Bug 796579 - Cannot go forward with empty duplicates screen.
• Bug 796665 - Backspace Key Inoperable After Ctrl+V.
• Bug 796669 - Dark Theme Text Colors Hard to Read.
Only add the register-foreground class when using Gnucash built in colours. 
When this setting not used, the foreground colour by default will be what ever 
the theme has set and will be down to the user to over ride along with the 
other register colours.

• Bug 796724 - Can't overwrite gnucash DB on MariaDB.
• Bug 796725 - 4 of 6 Date Posted options fail to return matching 
transactions.
• Bug 796734 - Auto-complete entry not highlighting to allow for 
incremental entry.
• Bug 796737 - Patch to restore gncmod-python.c.
• Bug 796739 - Toolbar buttons have no labels.
• Bug 796751 - reconcile window usability - R column should be next to 
Amount.
• Bug 796755 - buggy window handling at startup.
• Bug 796756 - OFX import fails to recognize associated income accounts.
• Bug 796759 - --add-price-quotes leaves a lock on the file.
• Bug 796762 - Scrollbar partially hides the delete button in the Saved 
Report Configurations window.
The vertical scrollbar obscures the delete button in the tree view so add a 
dummy blank column to the end and set it to the width of the vertical scrollbar.

• Bug 796766 - Credit note creating 'imbalance' with wrong entries.
• Bug 796777 - CVE-2008-1391: Integer overflow in included strfmon 
function.
• Bug 796788 - Strange behaviour in options of multicolumn report.
• Bug 796792 - SaveAs Overwrite dialogue in background and not visible.
• Bug 796812 - gnc_date_cell_get_date and gnc_date_cell_get_date_gdate 
have different date validation behaviour.
• Bug 796813 - Date validation inconsistent.
• Bug 796814 - Changing a book's read-only threshold doesn't 
immediately affect open registers.
• Bug 796816 - Notes field in Duplicate Invoice dialogue is 'read-only'.
• Bug 796819 - Bad icon with Spanish localization.
Drop translations of the 'gnucash-icon' string from our po files and add a note 
for translators to not translate this string or use the literal 'gnucash-icon' 
as translation.

• Bug 796820 - References to 'Gnome Bugzilla' should be changed to 
'GnuCash Bugzilla'.

Re: [GNC-dev] GnuCash 3.3 Released

2018-10-01 Thread Christopher Lam
No it's stalled because I cannot figure out equity
unrealized/realized/trading gains at all. I have no reliable guidance to
create equity section reliably.

If the equity section is ignored, and only the asset/liability sections
used, then the report could be inserted into an 'experimental' menu.


On Mon, 1 Oct 2018 at 22:35, Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> Chris,
>
> Did your new Income/Balance multi-column report make it into this release
> or is it still in development?
>
> Regards,
> Adrien
>
> > On Oct 1, 2018, at 9:23 AM, Christopher Lam 
> wrote:
> >
> > Hi all
> >
> > While everyone is busy shaking the program to weed out any new bugs,
> please be aware that the invoice reports have been modified, with an aim
> for greater maintainability (i.e. printable invoice, easy-invoice,
> fancy-invoice now share the same code base and have been approximated as
> well as possible to the original reports) and flexibility (invoice headers
> e.g. date, client details, invoice details etc can now be reordered at
> will; insert company logo; full CSS customisation).
> >
> > Please send any comments via bug reports.
> >
> >
> > From: John Ralls
> > Sent: Monday, 1 October 2018 4:48 AM
> > To: Gnucash-User
> > Cc: gnucash-devel; gnucash-annou...@gnucash.org
> > Subject: [GNC-dev] GnuCash 3.3 Released
> >
> > The GnuCash development team announces GnuCash 3.3, the fourth release
> of the 3.x stable release series.
> >
> > Changes
> >
> > Between 3.2 and 3.3, the following bugfixes were accomplished:
> >
> >   • Bug 771667 - Different warnings when changing reconciled splits
> vs. splits linked to reconciled splits.
> >   • Bug 784420 - "Save changes on closing" window waits 2^32 seconds
> when "Time to wait for answer" is set 0.
> >   • Bug 786708 - GnuCash won't load currency fractions larger than
> 100. Also create larger fractions for the account dialog.
> >   • Bug 787439 - Segmentation Fault in Transfer dialog after
> clearing Date field and pressing escape.
> >   • Bug 789594 - Unable to overwrite sqlite3 database file.
> >   • Bug 792446 - Mixed languages in error dialog.
> >   • Bug 794526 - Python bindings can't find loadable modules.
> >   • Bug 794755 - Commodity Register displays fractional prices.
> > Prices will now be displayed in decimal, rounded to two more places than
> the currency's smallest unit.
> >
> >   • Bug 794870 - If no book is opened, gnucash still asks if the
> user wants to save changes when opening a file.
> >   • Bug 795821 - GnuCash could not obtain the lock for
> file://C:\Users\username\Documents\GnuCash\2.6.21\\.gnucash
> >   • Bug 796054 - Unposting and reposting invoice doubles amounts.
> >   • Bug 796137 - query.search_for outputs critical qof.object errors
> and prevents queries being run.
> >   • Bug 796248 - Editing Scheduled Transaction.
> > In addition to not begining to edit already-loaded transactions, don't
> try to load splits that are already loaded. It shouldn't be possible to
> load a transaction without also loading its splits.
> >
> >   • Bug 796474 - Segmentation fault while setting up online banking.
> > Allow only a single instance of the assistant.
> >
> >   • Bug 796509 - Saved reports don't respect *some* 'Edit report
> options'.
> >   • Bug 796579 - Cannot go forward with empty duplicates screen.
> >   • Bug 796665 - Backspace Key Inoperable After Ctrl+V.
> >   • Bug 796669 - Dark Theme Text Colors Hard to Read.
> > Only add the register-foreground class when using Gnucash built in
> colours. When this setting not used, the foreground colour by default will
> be what ever the theme has set and will be down to the user to over ride
> along with the other register colours.
> >
> >   • Bug 796724 - Can't overwrite gnucash DB on MariaDB.
> >   • Bug 796725 - 4 of 6 Date Posted options fail to return matching
> transactions.
> >   • Bug 796734 - Auto-complete entry not highlighting to allow for
> incremental entry.
> >   • Bug 796737 - Patch to restore gncmod-python.c.
> >   • Bug 796739 - Toolbar buttons have no labels.
> >   • Bug 796751 - reconcile window usability - R column should be
> next to Amount.
> >   • Bug 796755 - buggy window handling at startup.
> >   • Bug 796756 - OFX import fails to recognize associated income
> accounts.
> >   • Bug 796759 - --add-price-quotes leaves a 

Re: [GNC-dev] Gnucash and the UK's "Making Tax Digital" initiative

2018-12-02 Thread Christopher Lam
Hi All

I have reviewed one of pre-gnucash accounting software which I tried 10-15
years ago. VT Cashbook is free, uses double-entry internally, and is a good
solution for UK-based small traders who do not need accruals.

http://www.vtsoftware.co.uk/mtd/index.htm

A VAT return using sample data (sales = 300 + 20 VAT; purchases = 150+30
VAT) produces the following snippet.
[image: image.png]

So, gnucash may be used to store data, and the "Income&GST Statement"
report to produce numbers, which are then sent to tax office by the
bridging software. A small list of such software is maintained in the link
above. These numbers can be produced using "Income & GST Statement" as long
as the accounts are set up correctly. That's all it takes for the technical
aspects to work.

Chris

On Tue, 20 Nov 2018 at 16:52, Geert Janssens 
wrote:

> Op dinsdag 20 november 2018 00:30:55 CET schreef Graham Leggett:
> > Hi all,
> >
> > I just learned with some shock that the UK wants to force SMEs to submit
> VAT
> > returns “via external software packages” by 1 April 2019, and presents a
> > list of some 150 packages to choose from. If you’re lucky enough to
> already
> > be using one of those packages, great. If you’re not, you’re facing some
> > disruption.
> >
> > Gnucash is not on the list (that I could see).
> >
> > We are not in a position to re-engineer our accounts, but we are in a
> > position to submit patches to Gnucash.
> >
> > This email is exploratory - is anyone on the gnucash dev list interested
> in
> > the UK “Making Tax Digital” initiative, with the aim of getting Gnucash
> “on
> > the list” of approved software? Has anyone done any work in this area?
> >
> > I am still looking for concrete information on the protocols being used,
> if
> > anyone has information on that it would be useful too.
>
> Hi Graham,
>
> The topic has come up a few times in the past. But as far as I know noone
> is
> currently working on this.
>
> You are certainly welcome to send in patches. However I seem to remember
> from
> past discussions GnuCash stands a very small chance of getting accepted as
> it's sources are freely available. That means everybody could build their
> own
> version of gnucash with possibly important details altered. And it's not
> clear
> how to handle this or whether the government will accept this.
>
> So perhaps the first step is to figure out whether the effort is worth
> pursuing by researching the restrictions.
>
> If it turns out there is a practical way to support UK's digital VAT
> system
> from within GnuCash I'll gladly accept good patches to implement them on
> condition the author is also willing to support this feature long-term.
>
> Best of luck,
>
> Geert
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] GNUCASH Test Data

2018-12-04 Thread Christopher Lam
There's a good idea, however, I am not sure that the datafile loading
mechanism is exposed to python & scheme.

If you analyze test-transaction.scm and test-commodity-utils.scm you'll see
how each test will generate an in-memory datafile with customized data
designed to test aspects of transaction.scm and commodity-utilities.scm. So
far this is the best way I found to test individual components.

I'm sure python could receive similar tests. You're welcome to take up the
reins!


On Tue, 4 Dec 2018 at 19:54,  wrote:

> Hello all,
>
> just reading this. When I started to look into the unit tests for
> python I wondered if there was some test data to read. I thought
> it would make more sense to first test reading and then test writing.
>
> I wonderes if there was some example date that the c as well as
> the bindings could be tested on. I think that would be useful.
>
> Generating and checking such file acts like a test for the whole
> system.
>
> regards,
>
> Christoph
>
>
> Am 11.11.18 um 12:54 schrieb Sébastien de Menten:
> > Hello Chris,
> >
> > I am definitely interested into such gnucash data set of
> > books/accounts/etc
> > for testing piecash (reports, performance,.. ). With the transition to
> > gnucash 3 coming to maturity, I planned to convert/rework the existing
> > set
> > of sample books (
> > https://github.com/sdementen/piecash/tree/master/gnucash_books) so if
> > you
> > have something that may be useful in this respect...
> > Did you already share something on GitHub?
> >
> > Sebastien
> >
> > On Sun, Nov 11, 2018, 03:05 David Cousens  > wrote:
> >
> >> Chris Millsap, Chris Good
> >>
> >> There is some limited test and example data in the GnuCash sources
> >> .../gnucash-src/doc/examples. Not very extensive. These days a lot of
> >> testing effort is shifted towards unit tests rather than extensive
> >> overall
> >> functional tests although they still have a place. I would think there
> >> would
> >> be a serious problem in validation of a data set and then the
> >> maintenance
> >> issues you alluded to. Another difficulty would be defining a test
> >> data set
> >> which would cover the various feature sets adequately, e.g. business,
> >> trading, multicurrency etc. To define an adequate test data suite
> >> would
> >> also
> >> require an extensive knowledge of the code base in any case.
> >>
> >> Possible but is it really worth the effort? In accounting if major
> >> features
> >> like compliance with the accounting equation, zero sum for transaction
> >> splits are broken, then it will be generally obvious very quickly and
> >> the
> >> unit tests on the engine seem likely pick that up.
> >>
> >> What is it that you would wan't a test data suite to do that is not
> >> covered
> >> by the existing unit tests?
> >>
> >> David Cousens
> >>
> >>
> >>
> >> -
> >> David Cousens
> >> --
> >> Sent from:
> >> http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Accounts do not appear in budget

2018-12-05 Thread Christopher Lam

Agreed -- IMHO the current budget mechanism is a bad hack.

There are better ones e.g. https://wiki.gnucash.org/wiki/Zero-Sum_Budgeting

Test implementation available at 
https://github.com/christopherlam/gnucash/tree/master-envelope-budgeting


On 5/12/18 5:38 pm, D via gnucash-devel wrote:

Another option would be for someone (other than myself, because I never have 
used, liked or understood the budgets module) to write some documentation for 
the budgets.

A third option, even less likely, is for someone who cares to go in and try and 
make sense of the budget features, and rewrite the functionality in a way that 
people can understand and use. I say less likely because this area has been 
deficient for a long time without any interest in improving it developing 
anywhere.

A fourth option, more radical but based on the reality of number three, is to 
remove this module altogether, since it is neither being fixed nor improved. 
Keeping it around suggests to new users that it has any support behind it, 
which is not the case.I

David

On December 5, 2018, at 2:58 PM, Adrien Monteleone 
 wrote:

Another case of something recently being an issue all of a sudden...

Perhaps changing the default to include *all* accounts is in order.

Certainly I can see the use case of someone setting up GnuCash for the first 
time and one of the 1st items in their workflow being to create a budget before 
they enter any transactions. I would say that is more likely than someone using 
GnuCash for an entire year before diving into the budget module, which is the 
apparent assumption based on how it works.

Regards,
Adrien


On Dec 5, 2018, at 3:24 AM, Adrien Monteleone  
wrote:

Do you have any transactions in those accounts yet?

If not, they won’t show up by default.

You can change this setting in View > Filter By... > Other > Show unused 
accounts.

Regards,
Adrien


On Dec 4, 2018, at 3:32 PM, Sadhna True  wrote:

I am a new Gnucash user, and I am using the software to manage personal 
finances. I have previously used QuickBooks to do bookkeeping for a small 
company.

In Gnucash, I created my accounts. When I create a new budget, a new tab opens, 
but none of the accounts I created appear in the budget. What am I doing wrong?
___
gnucash-user mailing list
gnucash-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Interest

2018-12-12 Thread Christopher Lam
Hi
I am not an original developer on this loan assistant.
However I think that the original loan druid was designed to
calculate/estimate the loan repayment amounts, assuming a conventional
loan, with a non-zero interest rate.
If the interest rate was zero, there would be little need for a loan druid.
e.g. original loan = $1,000 and 20 repayments of $50 each... A simple
calculator would do the trick.
I do not think there has ever been a policy against having a zero-rated
loan... but I think that the loan module has not been properly tested with
such figures. So, I am not entirely sure that a "simple refactoring" is a
good description of the process; it would require a complete review of the
loan assistant, and more testing of code to handle zero-interest loans, to
ensure crashes such as division-by-zero do not occur.
There is very little time developer CPU cycles available for such work; if
you are able to assist in reviewing code, enabling and testing, you are
very welcome on board.
So I think, at least, the "Loan Repayment Calculator" message "The interest
rate cannot be zero" should really be "The loan calculator does not handle
zero interest rates."

On Tue, 11 Dec 2018 at 20:05, Hamidreza Jafari 
wrote:

> Hello,
>
> I use GnuCash mostly for personal finance and use its basic features,
> that's
> why I have not tried it completely with all its capabilities. When I
> decided
> to translate I had no idea I would encounter parts of it designed in
> specific
> doctrines. This is one such string that paused my for a while:
>
> Enter the annual interest rate in percent. Accepts values from 0.001 -
> 100.
> The Mortgage Assistant does not support zero-interest loans.
>
> Although it is possible to set up zero interest business using extra
> effort it
> is better that the tool can be used at a policy level. Historical views on
> the
> subject are clear. It is true that Islam (which was referred to as Sharia)
> takes sides about it, it is not the only one contending. There are some
> issues
> in life that are not a matter of voting simply because of limited capacity
> of
> everyday person.
>
> It is not clear to me if there are some other parts in GnuCash that have
> been
> designed in similar ideas. I would like it to be accepting of the moral
> side
> by allowing interest-free transactions (I currently suffice to this level
> of
> goodness advocacy). I hope it is designed and implemented in such a way
> that
> extension is possible if not a simple refactoring can do the job.
>
> What's the situation?
>
> Hamid
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Translation

2018-12-12 Thread Christopher Lam
Reply for qu.2 below

On Mon, 10 Dec 2018 at 11:16, Hamidreza Jafari 
wrote:

> 2 - There are some parts of the application which I find contrary to what
> is a
> major belief. That of interest. Can the application handle interest-free
> AKA
> zero interest loans and mortgages?
>

Of course GnuCash can handle them. Initial loan drawdown eg $100,000 on
1-1-1990, to be repaid in 100 monthly installments of $1000.

*Luckily I negotiated an interest-free loan.*
01/01/1990 Asset:Something +$100,000
01/01/1990 Liabilities:Loan -$100,000

*Every month for the next 100 months, I repay $1,000:*
01/02/1990 Asset:Bank -$1,000
01/02/1990 Liabilities:Loan +$1,000

01/03/1990 Asset:Bank -$1,000
01/03/1990 Liabilities:Loan +$1,000

etc...

and after 8 years or so of repayments, the Liabilities:Loan should reach
$0, debt repaid.
No interest payments are involved.

3 - How to acquire clarification on individual strings? Post to the mailing
> list per instance or is someone personally focusing on language issues?
>

IRC, gnucash-devel...


> Linux and open source conent has worked well for me. My decision makes a
> big
> difference. Its success was compelling enough so that I set some of my
> time
> and energy on doing this piece and at the same time think more about
> computing
> and all its potiential in a tiny globe.
>
>
Thank you for your efforts!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] clang-format - thoughts ?

2018-12-24 Thread Christopher Lam

From a lisp viewpoint I was thinking of putting forward a coding style too!

I use emacs which does the following automatically:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html#Coding-Conventions

C

On 25/12/18 10:23 am, c.holterm...@gmx.de wrote:

John,

it's more of a general question. I don't have something
specific. I tend to develop more sympathy towards
formatting rules lately and clang-format sounded interesting.

https://github.com/barisione/clang-format-hooks is an
example of clang-format as github hook.

As my main interest is python I am more interested
in formatting convention on that side anyway.

Just wanted to know if this topic had been discussed.

regards,

Christoph

Am 2018-12-25 01:33, schrieb John Ralls:


Christoph,

We've occasionally run artistic style (https://astyle.sourceforge.net) when one 
of us gets really irritated with a lot of poor formatting, but it has been 
several years since anyone thought it necessary.

Is there something in particular that's rubbing you the wrong way or are you 
looking for an alternative to setting up the coding style in your editor?

Regards,
John Ralls


On Dec 24, 2018, at 2:53 PM, c.holterm...@gmx.de wrote:

Hello folks,

have there been thoughts about using a code formatter like clang-format ?
My brother is taking part in cmake development and he says that he has
included clang-format in his git deployment chain.

regards and merry christmas,

Christoph Holtermann
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Make of 3.3-181

2018-12-24 Thread Christopher Lam

There is still a strong argument to clean up these reports...

They are generally messy, lots of duplicate code, impose new 
translatable strings; they use localised C API such as 
xaccAccountGetTaxUSCode (even taxtxf-de_DE.scm calls it), are poorly tested.


I have not touched any of them significantly because they are both an 
eyesore.


Yet, to move the whole code base forward means maintaining these reports 
forever.


Perhaps it would be useful to canvas the users and ask how much use they 
actually get?


C


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


[GNC-dev] taxtxf

2019-01-03 Thread Christopher Lam

Hi

I'm thinking of tackling the huge beast that is taxtxf.scm but I'm 
struggling to understand its various meandering code paths.


If anyone is willing to share a sample datafile with accounts 
appropriately tagged with tax-info then I'll try untangle this mess.


I think there are some current bugs in UI - I can't even set the book 
tax-info type properly in a new datafile, and cannot yet create tests.


But a good datafile will be useful in the meantime.

C
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] taxtxf

2019-01-04 Thread Christopher Lam
Hi Alex
Thank you for work years ago.
My aim is to try clean up the various reports, and improve the coding style
to gnu emacs style.
Example style is at
https://github.com/christopherlam/gnucash/blob/maint-balsheet-pnl/gnucash/report/standard-reports/balsheet-pnl.scm
-> while this particular multicol balancesheet is IMO working (and all's
well except I'm not 100% sure of capital-gains), I think it must be more
modularised internally to be more maintainable prior to being merge-quality.
I think taxtxf.scm is suffering from many issues - NO tests, old guile
style, too many hard-coded assumptions. I think I can fix them but would
need a good datafile (and I can't generate one due to bug as shown), and a
summary of its assumptions would be good. There's work in progress at the
moment at
https://github.com/christopherlam/gnucash/blob/maint-txf-cleanup/gnucash/report/locale-specific/us/taxtxf.scm
but I'll wish to create good tests to ensure this work is safe.

On Sat, 5 Jan 2019 at 06:06, Alex Aycinena  wrote:

>
>
> Christopher,
>
>
>>
>> ------ Forwarded message --
>> From: Christopher Lam 
>> To: GnuCash development list 
>> Cc:
>> Bcc:
>> Date: Fri, 4 Jan 2019 10:48:23 +0800
>> Subject: [GNC-dev] taxtxf
>> Hi
>>
>> I'm thinking of tackling the huge beast that is taxtxf.scm but I'm
>> struggling to understand its various meandering code paths.
>>
>> If anyone is willing to share a sample datafile with accounts
>> appropriately tagged with tax-info then I'll try untangle this mess.
>>
>> I think there are some current bugs in UI - I can't even set the book
>> tax-info type properly in a new datafile, and cannot yet create tests.
>>
>> But a good datafile will be useful in the meantime.
>>
>> C
>>
>>
> I re-wrote the original US Income Tax Report several years ago and have
> maintained the reference data that it uses, which is in the file txf.scm,
> each year. I am waiting for a few more revised tax forms to be available
> before I can do the update for tax year 2018.
>
> The book tax info dialog worked until recently. It is reported as bug
> #796687. I have just been trying to debug the problem and think the problem
> is in qof_book_set_string_option, which was updated in March 2018, but
> haven't finished my analysis.
>
> John Ralls just committed a fix that was preventing the report from
> running. A couple of users reported that it runs with his fix (bug #797002).
>
> Short-term, getting the data updated for 2018, fixing 796687, and making
> sure the report runs and is accurate is the important thing.
>
> Long-term, while I'm sure the report can be improved, I believe the
> architecture for the whole US Income Tax reporting process is problematic
> and should be replaced. For this reason, I would suggest it may not be
> worthwhile to invest a lot of time in restructuring the report, without
> first addressing underlying issues.
>
> However, if you want to go ahead and do so, please feel free to ask me any
> questions you want and I will be happy to work with you on it.
>
> Regards,
>
> Alex
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Reports -- Cleanup

2019-01-09 Thread Christopher Lam
Thanks for the interest in reports.

I'd like to take opportunity to explain current state of code.

Examples of duplication:
- html-barchart, html-linechart, html-scatter, html-pie have a lot of
duplicated code; there's a pending work for merging the charting
infrastructure into a universal one, and also upgrading from jqplot to
chartjs (responsive and animated). this is not frozen yet.

Pending work
- transaction.scm may receive a CSV export function. see last commit at
https://github.com/christopherlam/gnucash/commits/maint-export-csv/gnucash/report/standard-reports/transaction.scm
for anyone wishing to experiment.
- multicolumn balsheet is still pending and requires cleanup

Future work
- if reconciliation report gets a lot of attention and refinements it may
be spun off into a separate file like income-gst-statement.scm.
- a header for reconciliation report is not difficult, but the
determination of 'starting and ending balance' for the header is
*difficult* - I'd like to mimic the formal reconciliation tool but I'm not
sure how it calculates the balances.
- organising removal of unused old code

On Thu, 10 Jan 2019 at 05:53, David Cousens 
wrote:

> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent
> these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting
> requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving
> the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
>
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> David Cousens
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Reconciliation Report -- Can't find transactions

2019-01-12 Thread Christopher Lam

Dear Liz

Thank you for experiments - this confirms that doing a proper 
reconciliation report is *difficult*


Please experiment further (1) expand dates eg from 01/01/1980 to 
01/01/2099 (2) let me know the characteristics of the 77 missing amounts 
- are they unreconciled/cleared/reconciled?


I guess you can build from source, would you care to try 
https://github.com/christopherlam/gnucash/tree/maint-scheme-progress-and-reconcile-header 
which will add a reconcile-report header?


I'm fully aware this report is currently incomplete and will need 
further refinements. For instance IMHO the primary sortkey should be 
frozen to 'reconciled status'.


I'd be keen to discuss further to shape it into a proper report.

C

On 12/1/19 4:20 pm, Liz wrote:

On Sun, 6 Jan 2019 14:44:56 -0600 (CST)
David Cousens  wrote:


Steve,

I just ran it on an account in my recordsin 3.4  and it worked fine.
I had to explicitly select the account/accounts and period it was to
be prepared for in the Accounts tab in the Report Options dialog
(Edit Menu) once I had opened the report (initially blank) and then
the entries all came up.

David


I was just experimenting here (Debian Buster/Sid; Gnucash 3.4+ 30/12/18)

I opened the reconciliation report
Select options
Select an asset account, apply
All I had was the unreconciled amounts

Try a second and a third account, with the dates set to beginning of
last quarter to end of last quarter.
I got the reconciled and the unreconciled amounts (which I was
expecting)

Tried first account again, wouldn't change to the altered dates,
wouldn't show the reconciled amounts. Reload made no difference.

I closed Gnucash, restarted and tried again with identical results.
Output.pdf is the first account, not showing a large number of
reconciled transactions (77 missing transactions)
Output1.pdf is the second account.

Liz

___
gnucash-user mailing list
gnucash-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Reconciliation Report -- Can't find transactions

2019-01-12 Thread Christopher Lam
The only addition so far is a reconcile report custom header with total
ending balance and total ending reconciled balance. Not sure why it's not
showing in your attachment. We'll try to work this note that you can build;)

On Sun., 13 Jan. 2019, 12:32 Liz  On Sun, 13 Jan 2019 12:09:06 +1000
> David Cousens  wrote:
>
> > GTEST and GMOCK need to be installed to build GnuCash. Despite the
> > reservations expressed about using the installation of them as shared
> > libraries, I have used shared GTEST and GMOCK libraries since GTEST
> > and GMOCK have been in the GnuCash build without any problems and
> > this does not require defining GTEST_ROOT and GMOCK_ROOT.
>
> Installed both through apt on a Debian buster / sid system.
> googletest was installed by asking apt to install all the requirements
> for a Gnucash build.
> googlemock I had to install separately.
>
> I realise that you are saying that it should have "just worked" but it
> didn't. Editing CMakeLists.txt didn't work (perhaps I didn't get it
> correct). Specifying GTEST_ROOT on the command line did work.
>
> End result for my file - no change.
>
> Liz
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Reconciliation Report -- Can't find transactions

2019-01-13 Thread Christopher Lam

Report example attached.

Note the report header - your screenshot would suggest you haven't been 
able to build from my tree.


Try General / Display options summary = always to debug why txns are 
missing.


https://screenshots.firefox.com/Aw89EyPqf8O8ZL3x/null

https://screenshotscdn.firefoxusercontent.com/images/b10744f6-2ee0-4778-ba55-08a15b1c4b8f.png

On 13/1/19 2:50 pm, Liz wrote:

On Sun, 13 Jan 2019 12:53:19 +0800
Christopher Lam  wrote:


The only addition so far is a reconcile report custom header with
total ending balance and total ending reconciled balance. Not sure
why it's not showing in your attachment. We'll try to work this note
that you can build;)

I thought I may have run the installed binary so I carefully repeated
the exercise on the built gnucash, got the warning that it was a
developmental version that may not work, and an identical report output
to that which I sent earlier.

[holds two hands in air to say "I dunno"]

Liz
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Reconciliation Report -- Can't find transactions

2019-01-13 Thread Christopher Lam

Hi

If you can pull from my git again I think you'll find the reconcile 
report now matches the formal tool very well.


1. disable date filter - i.e. grab *all* transactions
2. filter to unreconciled or cleared only
3. calculate start/end balances

Comments welcome.

On 13/1/19 10:58 am, Liz wrote:

On Sat, 12 Jan 2019 18:49:05 +0800
Christopher Lam  wrote:


Please experiment further (1) expand dates eg from 01/01/1980 to
01/01/2099 (2) let me know the characteristics of the 77 missing
amounts
- are they unreconciled/cleared/reconciled?

I guess you can build from source, would you care to try
https://github.com/christopherlam/gnucash/tree/maint-scheme-progress-and-reconcile-header
which will add a reconcile-report header?


This is the result from the the git build, working from a copy of my
file
I suppressed the description column
No transactions from 31/8/18 to 31/12/18
77 or so in the file.

Liz

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] Reconciliation Report -- Can't find transactions

2019-01-16 Thread Christopher Lam
The suggested reconciliation changes will need lots of testing and bug
fixing prior to wider dissemination and merging. Because it delegates to
the very versatile transaction report, it still exposes far too many
options and I think loss of options need to be hidden but I don't wish to
impose further. You're very welcome to take part and make suggestions BTW.
C

On Mon., 14 Jan. 2019, 03:46 Adrien Monteleone <
adrien.montele...@lusfiber.net wrote:

> Christopher,
>
> There is another current thread on gnucash-user looking for something
> similar:
> https://lists.gnucash.org/pipermail/gnucash-user/2019-January/081941.html
>
> Can you share your report files there or does the new version also require
> changes to other parts of gnucash to make it work?
>
> Regards,
> Adrien
>
> > On Jan 13, 2019, at 9:39 AM, Christopher Lam 
> wrote:
> >
> > Hi
> >
> > If you can pull from my git again I think you'll find the reconcile
> report now matches the formal tool very well.
> >
> > 1. disable date filter - i.e. grab *all* transactions
> > 2. filter to unreconciled or cleared only
> > 3. calculate start/end balances
> >
> > Comments welcome.
> >
> > On 13/1/19 10:58 am, Liz wrote:
> >> On Sat, 12 Jan 2019 18:49:05 +0800
> >> Christopher Lam  wrote:
> >>
> >>> Please experiment further (1) expand dates eg from 01/01/1980 to
> >>> 01/01/2099 (2) let me know the characteristics of the 77 missing
> >>> amounts
> >>> - are they unreconciled/cleared/reconciled?
> >>>
> >>> I guess you can build from source, would you care to try
> >>>
> https://github.com/christopherlam/gnucash/tree/maint-scheme-progress-and-reconcile-header
> >>> which will add a reconcile-report header?
> >>
> >> This is the result from the the git build, working from a copy of my
> >> file
> >> I suppressed the description column
> >> No transactions from 31/8/18 to 31/12/18
> >> 77 or so in the file.
> >>
> >> Liz
> >>
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Two steps forward (Maybe three back)

2019-01-20 Thread Christopher Lam

There's no reason why the dates can't be changed.

The reason dates straggling 1.1.1970 was chosen was because 1.1.1970 
corresponds to time 0 in time64, and I felt that having a few negative 
time64 numbers would be interesting to test sorting.


However this is a weird weirdness -- the test output shows that the 
transactions were sorted correctly - 31/12/69, 31/12/69, 01/01/70, 
02/01/70, 02/10/70 (in d/m/y); it's just the display that is incorrect.


Moreover the display has to go through qof_print_date which takes a 
time64 and returns a string.


I'd be keen to know Stephen's build and try debug this.

Stephen can you modify transaction.scm as follows and let us know the 
test output? (Beware the parentheses!)


modified   gnucash/report/standard-reports/transaction.scm
@@ -1119,7 +1119,8 @@ be excluded from periodic reporting.")
  (if transaction-row?
(gnc:make-html-table-cell/markup
   "date-cell"
-  (qof-print-date (xaccTransGetDate 
(xaccSplitGetParent split
+  (let ((date (xaccTransGetDate 
(xaccSplitGetParent split
+    (gnc:pk 'date date 
'qof-print-date (qof-print-date date

  ""

    (add-if (column-uses? 'reconciled-date)


On 21/1/19 7:00 am, John Ralls wrote:



On Jan 20, 2019, at 1:24 PM, Stephen M. Butler  wrote:

Started clean this morning by recloning the git repository.  Made much
further progress but ended up with some test failures.  Here are my steps:

1.  sudo rm -rf gnucash

2.  git clone https://github.com/Gnucash/gnucash

3. cd gnucash

4.  git checkout -b debian

5.  cp -r ../debian .

 Here is the contents of that directory -- copied to Google Drive:


https://drive.google.com/open?id=1VJmtb-Fx00PQna4yQoYm49C88Bi0hneI


6.  git add debian

7. git commit

 Done on my "debian" branch

8. fakeroot debian/rules clean

9.  sudo mk-build-deps -ir debian/control

10. dpkg-buildpackage -rfakeroot -b -uc

Note:  This usually failed right up front.  This time went for nearly 10
minutes.

End testing: Jan 20 12:49 PST
+ exit 2
debian/rules:68: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/home/steve/Projects/GnuCash/gnucash'
debian/rules:23: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2


Here are the contents of ./.build/Testing/Temporary/*
https://drive.google.com/open?id=1_0gRAd-ymP1cEYM3pyPnvzeHI7-SSWMS

The file you want to look at for test failures is LastTest.log. You can search for 
"Test Failed".

This time the test failure is in 
gnucash/report/standard-reports/test/test-transaction.scm:
[pass] line:654, test: dual amount column, first transaction correct
[fail] line:678, test: dates are sorted
transaction.scm/sorting options
  -> expected: ("12/31/69" "12/31/69" "01/01/70" "02/01/70" "02/10/70")
  -> obtained: ("12/31/70" "12/31/70" "01/01/70" "02/01/70" "02/10/70")
[pass] line:684, test: sort by number

That suggests that for some reason Guile on your system can't handle dates 
before 1/1/1970. That's strange, but probably not important to many GnuCash 
users.

Chris Lam, any reason not to change that test to use later dates?

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Two steps forward (Maybe three back)

2019-01-20 Thread Christopher Lam
Thank you

This confirms my suspicion that guile is not the culprit.

Excerpt
[pass] line:647, test: dual amount column, with original currency headers
[pass] line:651, test: dual amount column, grand totals available
[pass] line:654, test: dual amount column, first transaction correct
d0.1102 t1.868: ('date -46860 'qof-print-date 12/31/70)
d0.0005 t1.868: ('date -46860 'qof-print-date 12/31/70)
d0.0005 t1.869: ('date 39540 'qof-print-date 01/01/70)
d0.0005 t1.869: ('date 2717940 'qof-print-date 02/01/70)
d0.0005 t1.870: ('date 3495540 'qof-print-date 02/10/70)

Etc

The dates are correct; -46860 is a relatively small number of seconds
before 1/1/70 yet qof-print-date reports 31/12/70.

Back to jralls for root cause analysis!

On Mon., 21 Jan. 2019, 14:50 Stephen M. Butler  On 1/20/19 8:07 PM, Christopher Lam wrote:
> > There's no reason why the dates can't be changed.
> >
> > The reason dates straggling 1.1.1970 was chosen was because 1.1.1970
> > corresponds to time 0 in time64, and I felt that having a few negative
> > time64 numbers would be interesting to test sorting.
> >
> > However this is a weird weirdness -- the test output shows that the
> > transactions were sorted correctly - 31/12/69, 31/12/69, 01/01/70,
> > 02/01/70, 02/10/70 (in d/m/y); it's just the display that is incorrect.
> >
> > Moreover the display has to go through qof_print_date which takes a
> > time64 and returns a string.
> >
> > I'd be keen to know Stephen's build and try debug this.
> >
> > Stephen can you modify transaction.scm as follows and let us know the
> > test output? (Beware the parentheses!)
> >
> > modified   gnucash/report/standard-reports/transaction.scm
> > @@ -1119,7 +1119,8 @@ be excluded from periodic reporting.")
> >   (if transaction-row?
> > (gnc:make-html-table-cell/markup
> >"date-cell"
> > -  (qof-print-date
> > (xaccTransGetDate (xaccSplitGetParent split
> > +  (let ((date (xaccTransGetDate
> > (xaccSplitGetParent split
> > +(gnc:pk 'date date
> > 'qof-print-date (qof-print-date date
> >   ""
> >
> > (add-if (column-uses? 'reconciled-date)
>
> My apologies for the long delay in getting back to you.  The wife
> indicated that we'd better spend some time in the hot tub watching the
> lunar eclipse.  So I leaned back and gazed up into the dark gray
> featureless sky at where the moon should be.  Nadda.  Good soak though
> and the spine is thankful.
>
> The other problem is that my 1119 doesn't match up.  At first when I
> went back to the maint branch the changes stayed in the directory.  I
> had to be sure I had the real file from git.  So, here is the code block
> with line 1119 marked.
>
>
>   (add-if (column-uses? 'num)
>
>(vector (if (and BOOK-SPLIT-ACTION
> (opt-val gnc:pagename-display
> (N_ "Trans Number")))
>(_ "Num/T-Num")
>(_ "Num"))
>(lambda (split transaction-row?)
>  (let* ((trans (xaccSplitGetParent split))
> (num (gnc-get-num-action trans
> split))
> (t-num (if (and BOOK-SPLIT-ACTION
> (opt-val
> gnc:pagename-display (N_ "Trans Number")))
>(gnc-get-num-action
> trans #f)
>""))
> (num-string (if (string-null?
> t-num)
> num
> (string-append
> num "/" t-num
>(if transaction-row?
>(gnc:make-html-table-cell/markup
> "text-cell" num-string)
>"")
> 1119
>(add-if (column-uses? 'description)
>(vector (_ "Description")
>(lambda (split transaction-row?)
>  (define tr

Re: [GNC-dev] Two steps forward (Maybe three back)

2019-01-21 Thread Christopher Lam
As a last test, add the following, which will help determining which 
part of qof_print_date_buff is playing up.


I think it should output ('locale 4)...

modified   gnucash/report/standard-reports/transaction.scm
    (add-if (column-uses? 'date)
    (vector (_ "Date")
    (lambda (split transaction-row?)
+ (gnc:pk 'locale (qof-date-format-get))
  (if transaction-row?
(gnc:make-html-table-cell/markup
   "date-cell"

On 21/1/19 12:58 pm, Stephen M. Butler wrote:

On 1/20/19 8:07 PM, Christopher Lam wrote:

There's no reason why the dates can't be changed.

The reason dates straggling 1.1.1970 was chosen was because 1.1.1970
corresponds to time 0 in time64, and I felt that having a few negative
time64 numbers would be interesting to test sorting.

However this is a weird weirdness -- the test output shows that the
transactions were sorted correctly - 31/12/69, 31/12/69, 01/01/70,
02/01/70, 02/10/70 (in d/m/y); it's just the display that is incorrect.

Moreover the display has to go through qof_print_date which takes a
time64 and returns a string.

I'd be keen to know Stephen's build and try debug this.


Here are my steps (I have a Projects folder in which is a GnuCash folder):

cd ~/Projects/GnuCash

git clone https://github.com/Gnucash/gnucash

cd gnucash

git checkout 3.4

cp -r ../debian .

(contents of above folder are available here:
https://drive.google.com/open?id=1VJmtb-Fx00PQna4yQoYm49C88Bi0hneI  )

fakeroot debian/rules clean

sudo mk0buikd-deps -ir debian/control

DEB-BUILD-OPTIONS=nocheck dpkg-build-package -rfakeroot -b -uc

(This did build the files located here:
https://drive.google.com/open?id=1fV_fURy6c77e7gf6S41lTacM7dFyy7VD   )



Stephen can you modify transaction.scm as follows and let us know the
test output? (Beware the parentheses!)

modified   gnucash/report/standard-reports/transaction.scm
@@ -1119,7 +1119,8 @@ be excluded from periodic reporting.")
   (if transaction-row?
(gnc:make-html-table-cell/markup
    "date-cell"
-  (qof-print-date
(xaccTransGetDate (xaccSplitGetParent split
+  (let ((date (xaccTransGetDate
(xaccSplitGetParent split
+    (gnc:pk 'date date
'qof-print-date (qof-print-date date
   ""

     (add-if (column-uses? 'reconciled-date)



Hmm.  I was back on v3.4 with this test.  I'll try again with maint
checked out.


d0.0005 t1.824: ('date 1576407540 'qof-print-date 12/15/19)
[pass] line:647, test: dual amount column, with original currency headers
[pass] line:651, test: dual amount column, grand totals available
[fail] line:654, test: dual amount column, first transaction correct
transaction.scm/display options
  -> expected: ("01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
"$103.00")
  -> obtained: ("01/03/19" "$103 income" "Root.Asset.Bank" "$103.00"
"$103.00")
d0.1090 t1.933: ('date -46860 'qof-print-date 12/31/69)



On 21/1/19 7:00 am, John Ralls wrote:

On Jan 20, 2019, at 1:24 PM, Stephen M. Butler  wrote:

Started clean this morning by recloning the git repository.  Made much
further progress but ended up with some test failures.  Here are my
steps:

1.  sudo rm -rf gnucash

2.  git clone https://github.com/Gnucash/gnucash

3. cd gnucash

4.  git checkout -b debian

5.  cp -r ../debian .

  Here is the contents of that directory -- copied to Google
Drive:


https://drive.google.com/open?id=1VJmtb-Fx00PQna4yQoYm49C88Bi0hneI


6.  git add debian

7. git commit

  Done on my "debian" branch

8. fakeroot debian/rules clean

9.  sudo mk-build-deps -ir debian/control

10. dpkg-buildpackage -rfakeroot -b -uc

Note:  This usually failed right up front.  This time went for
nearly 10
minutes.

End testing: Jan 20 12:49 PST
+ exit 2
debian/rules:68: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/home/steve/Projects/GnuCash/gnucash'
debian/rules:23: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2


Here are the contents of ./.build/Testing/Temporary/*
https://drive.google.com/open?id=1_0gRAd-ymP1cEYM3pyPnvzeHI7-SSWMS

The file you want to look at for test failures is LastTest.log. You
can search for "Test Failed".

This time the test failure is in
gnucash/report/standard-reports/test/test-transacti

Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

2019-01-23 Thread Christopher Lam
Directed towards Adrien- how should the budgeting reporting options look 
like?


Budget has start-date and num(periods)

Budget-report-date has its own start-date and end-date -- they should be 
removed?


I don't use the budgeting tools myself.

(ytd-budget.scm from years back seems to be a good report)

On 23/1/19 11:37 pm, Adrien Monteleone wrote:

This means the date range for the report (default is start & end of current 
accounting period) does not match the budget.

For example, I opened a chart for the 2018 budget and got a blank page.

When I changed the date range to start & end of previous year, I got charts for 
my selected accounts with budget and actual bars.

Regards,
Adrien


On Jan 23, 2019, at 8:54 AM, Lorrie Laskey  wrote:

Hi all,

Any idea why the bar chart is not displaying. The tab that opens is blank.
___
gnucash-user mailing list
gnucash-u...@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-u...@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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Test failure

2019-01-24 Thread Christopher Lam

Stephen this bug is in 3.4 and was fixed in commit 95bee405c

Could you try "git revert e31f4c3f9" as a test for your "31/12/70" 
test-transaction errors?


On 24/1/19 3:05 am, Stephen M. Butler wrote:

Found this patch on the debian version for 3.4

Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
From: Maxim Cournoyer 
Date: Wed, 2 Jan 2019 14:46:28 -0500
Subject: tests: Fix a test failure in test-transaction.scm.

With the New Year upon us, a test which was hard-coded to use 2018 now
failed.

Fixes issue #797008 (see:
https://bugs.gnucash.org/show_bug.cgi?id=797008).

* gnucash/report/standard-reports/test/test-transaction.scm:
(trep-tests): Use the current year in the test string instead of a
static one.

--- a/gnucash/report/standard-reports/test/test-transaction.scm
+++ b/gnucash/report/standard-reports/test/test-transaction.scm
@@ -4,8 +4,9 @@
  (use-modules (gnucash report standard-reports transaction))
  (use-modules (gnucash report stylesheets))
  (use-modules (gnucash report report-system))
  (use-modules (gnucash report report-system test test-extras))
+(use-modules (srfi srfi-19))
  (use-modules (srfi srfi-64))
  (use-modules (gnucash engine test srfi64-extras))
  (use-modules (sxml simple))
  (use-modules (sxml xpath))
@@ -642,18 +643,20 @@
    (set-option! options "General" "Common Currency" #t)
    (set-option! options "General" "Show original currency amount" #t)
    (set-option! options "Sorting" "Primary Key" 'date)
    (set-option! options "Sorting" "Primary Subtotal for Date Key" 'none)
-  (let* ((sxml (options->sxml options "dual columns")))
+  (let* ((sxml (options->sxml options "dual columns"))
+     (current-year (date->string (current-date) "~y")))
  (test-equal "dual amount column, with original currency headers"
    (list "Date" "Num" "Description" "Memo/Notes" "Account"
  "Debit (USD)" "Credit (USD)" "Debit" "Credit")
    (get-row-col sxml 0 #f))
  (test-equal "dual amount column, grand totals available"
    (list "Grand Total" "$2,280.00" "$2,280.00")
    (get-row-col sxml -1 #f))
  (test-equal "dual amount column, first transaction correct"
-  (list "01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
"$103.00")
+  (list (string-append "01/03/" current-year) "$103 income"
+        "Root.Asset.Bank" "$103.00" "$103.00")
    (get-row-col sxml 1 #f)))
    )
  
  (test-end "display options")




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

2019-01-24 Thread Christopher Lam
Perhaps you can beta-test the budget-barchart, with the report start/end 
dates options removed.


This also includes chartJS preview ;-)

https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart

On 24/1/19 1:42 am, Adrien Monteleone wrote:

Good question — I think the budget reports are fine, it seems to be the chart 
that is the odd one out.

As it is currently, for all of the budget reports, you choose the budget you 
want to report on and the range is determined accordingly. You can’t set it 
independently. I have no problem with this. I can’t see why someone would want 
to select a budget to report or chart, but want GC to use transactions from out 
of the budget period. (well, for comparing performance, sure, but it doesn’t 
work that way anyway, the Transaction Report is better suited there - see below)

But for the chart, you can choose, as in my example, last year’s budget (or 
anything other than current year) but the default date window is for this year, 
which would render no data. Since you can select the budget and date range 
separately, you can easily end up with either no results, incomplete results, 
or possibly non-sensical results.

For consistency, the chart should probably pull the date range from the budget 
choice like the reports do and not offer the options to set the range 
independently.

-

Now, if the reports and charts allowed you to independently select a budget and 
date-range for comparison of budget vs. actual (of the chosen period) that 
would be much more versatile. As it presently stands, you have to copy or re-do 
your budget each year/quarter. But if you could report a static budget against 
variable periods, you could have budgets based on something other than dates. 
(such as different scenarios, regardless of the period)

Making the change that direction would not remove the ability to produce and 
analyze budget performance on a period basis though. If that route is chosen, 
I’d suggest some sort of default report/chart page to explain what options need 
to be chosen to get a desired result. (similar to how some other reports tell 
you that you need to select some accounts or certain options, rather than just 
dumping you to a blank page. Note, this would be a good improvement for any 
report/chart that requires setting options to get a usable result or non-blank 
page.)

I’m not sure how difficult it would be to have the reports and chart look for 
budgeted amounts statically but actual performance based on a separately 
specified range. This might also necessitate some change to the budget options 
where you would assign values for a generic period without regard to a specific 
year.

While that all might be nice, the easiest thing to fix right now, I think would 
be to pattern the General tab of the budget chart similar to the various budget 
reports.

Regards,
Adrien


On Jan 23, 2019, at 10:14 AM, Christopher Lam  wrote:

Directed towards Adrien- how should the budgeting reporting options look like?

Budget has start-date and num(periods)

Budget-report-date has its own start-date and end-date -- they should be 
removed?

I don't use the budgeting tools myself.

(ytd-budget.scm from years back seems to be a good report)

On 23/1/19 11:37 pm, Adrien Monteleone wrote:

This means the date range for the report (default is start & end of current 
accounting period) does not match the budget.

For example, I opened a chart for the 2018 budget and got a blank page.

When I changed the date range to start & end of previous year, I got charts for 
my selected accounts with budget and actual bars.

Regards,
Adrien



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [GNC] New Budget Bar Chart Not Displaying

2019-01-24 Thread Christopher Lam

Best build entire branch because of new chartjs dependencies

On 24/1/19 7:35 pm, Adrien Monteleone wrote:

I haven’t built from git yet. (no time like the present) Do I build the entire 
branch or can I just dl and build the report?

Regards,
Adrien


On Jan 24, 2019, at 5:09 AM, Christopher Lam  wrote:

Perhaps you can beta-test the budget-barchart, with the report start/end dates 
options removed.

This also includes chartJS preview ;-)

https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart

On 24/1/19 1:42 am, Adrien Monteleone wrote:

Good question — I think the budget reports are fine, it seems to be the chart 
that is the odd one out.

As it is currently, for all of the budget reports, you choose the budget you 
want to report on and the range is determined accordingly. You can’t set it 
independently. I have no problem with this. I can’t see why someone would want 
to select a budget to report or chart, but want GC to use transactions from out 
of the budget period. (well, for comparing performance, sure, but it doesn’t 
work that way anyway, the Transaction Report is better suited there - see below)

But for the chart, you can choose, as in my example, last year’s budget (or 
anything other than current year) but the default date window is for this year, 
which would render no data. Since you can select the budget and date range 
separately, you can easily end up with either no results, incomplete results, 
or possibly non-sensical results.

For consistency, the chart should probably pull the date range from the budget 
choice like the reports do and not offer the options to set the range 
independently.

-

Now, if the reports and charts allowed you to independently select a budget and 
date-range for comparison of budget vs. actual (of the chosen period) that 
would be much more versatile. As it presently stands, you have to copy or re-do 
your budget each year/quarter. But if you could report a static budget against 
variable periods, you could have budgets based on something other than dates. 
(such as different scenarios, regardless of the period)

Making the change that direction would not remove the ability to produce and 
analyze budget performance on a period basis though. If that route is chosen, 
I’d suggest some sort of default report/chart page to explain what options need 
to be chosen to get a desired result. (similar to how some other reports tell 
you that you need to select some accounts or certain options, rather than just 
dumping you to a blank page. Note, this would be a good improvement for any 
report/chart that requires setting options to get a usable result or non-blank 
page.)

I’m not sure how difficult it would be to have the reports and chart look for 
budgeted amounts statically but actual performance based on a separately 
specified range. This might also necessitate some change to the budget options 
where you would assign values for a generic period without regard to a specific 
year.

While that all might be nice, the easiest thing to fix right now, I think would 
be to pattern the General tab of the budget chart similar to the various budget 
reports.

Regards,
Adrien


On Jan 23, 2019, at 10:14 AM, Christopher Lam  wrote:

Directed towards Adrien- how should the budgeting reporting options look like?

Budget has start-date and num(periods)

Budget-report-date has its own start-date and end-date -- they should be 
removed?

I don't use the budgeting tools myself.

(ytd-budget.scm from years back seems to be a good report)

On 23/1/19 11:37 pm, Adrien Monteleone wrote:

This means the date range for the report (default is start & end of current 
accounting period) does not match the budget.

For example, I opened a chart for the 2018 budget and got a blank page.

When I changed the date range to start & end of previous year, I got charts for 
my selected accounts with budget and actual bars.

Regards,
Adrien


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Test failure

2019-01-24 Thread Christopher Lam

Because e31f4c3f9 is causing errors on my build as well in different ways.

PS e31f4c3f9 must not be reverted for your packaging - please be patient 
while a proper fix is pending.


On 25/1/19 3:48 am, Stephen M. Butler wrote:

On 1/24/19 2:32 AM, Christopher Lam wrote:

Stephen this bug is in 3.4 and was fixed in commit 95bee405c

Could you try "git revert e31f4c3f9" as a test for your "31/12/70"
test-transaction errors?


That worked.  Thank you.  BTW, how did you find that it was fixed?  I
ask, because there is another one:

-rw-r--r-- 1 steve steve 461 Jan 23 14:16
test--skip-test-stress-options.patch

  cat test*
Last-Update: 2018-10-02
Forwarded: not-needed
Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=796877
Author: Dmitry Smirnov 
Description: skip broken test

--- a/gnucash/report/standard-reports/test/CMakeLists.txt
+++ b/gnucash/report/standard-reports/test/CMakeLists.txt
@@ -13,9 +13,8 @@
    test-income-gst.scm
  )
  
  set(scm_test_with_textual_ports_SOURCES

-    test-stress-options.scm
  )
  
  set(GUILE_DEPENDS

    scm-gnc-module

==

Any way I can search and see if this patch is already in maint?



On 24/1/19 3:05 am, Stephen M. Butler wrote:

Found this patch on the debian version for 3.4

Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
From: Maxim Cournoyer 
Date: Wed, 2 Jan 2019 14:46:28 -0500
Subject: tests: Fix a test failure in test-transaction.scm.

With the New Year upon us, a test which was hard-coded to use 2018 now
failed.

Fixes issue #797008 (see:
https://bugs.gnucash.org/show_bug.cgi?id=797008).

* gnucash/report/standard-reports/test/test-transaction.scm:
(trep-tests): Use the current year in the test string instead of a
static one.

--- a/gnucash/report/standard-reports/test/test-transaction.scm
+++ b/gnucash/report/standard-reports/test/test-transaction.scm
@@ -4,8 +4,9 @@
   (use-modules (gnucash report standard-reports transaction))
   (use-modules (gnucash report stylesheets))
   (use-modules (gnucash report report-system))
   (use-modules (gnucash report report-system test test-extras))
+(use-modules (srfi srfi-19))
   (use-modules (srfi srfi-64))
   (use-modules (gnucash engine test srfi64-extras))
   (use-modules (sxml simple))
   (use-modules (sxml xpath))
@@ -642,18 +643,20 @@
     (set-option! options "General" "Common Currency" #t)
     (set-option! options "General" "Show original currency
amount" #t)
     (set-option! options "Sorting" "Primary Key" 'date)
     (set-option! options "Sorting" "Primary Subtotal for Date
Key" 'none)
-  (let* ((sxml (options->sxml options "dual columns")))
+  (let* ((sxml (options->sxml options "dual columns"))
+     (current-year (date->string (current-date) "~y")))
   (test-equal "dual amount column, with original currency
headers"
     (list "Date" "Num" "Description" "Memo/Notes" "Account"
   "Debit (USD)" "Credit (USD)" "Debit" "Credit")
     (get-row-col sxml 0 #f))
   (test-equal "dual amount column, grand totals available"
     (list "Grand Total" "$2,280.00" "$2,280.00")
     (get-row-col sxml -1 #f))
   (test-equal "dual amount column, first transaction correct"
-  (list "01/03/18" "$103 income" "Root.Asset.Bank" "$103.00"
"$103.00")
+  (list (string-append "01/03/" current-year) "$103 income"
+        "Root.Asset.Bank" "$103.00" "$103.00")
     (get-row-col sxml 1 #f)))
     )
     (test-end "display options")



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Test failure

2019-01-24 Thread Christopher Lam
Revert is a git terminology, not a gnucash one. Welcome to version control.

Please remember this revert is reverting a buggy code with a previous buggy
code, so, cannot be consisted safe to package; best wait until the clever
devs can find a proper fix for gnc-date.

On Fri., 25 Jan. 2019, 05:46 Stephen M. Butler  OH!  Light bulb on!
> OK.  I understand what you said earlier.  I'll put the patches back into
> the packaging.
>
> Thanks for clearing that up.
>
> --Steve
>
> PS Looking in manual for 'revert' command.
>
>
>
> On 1/24/19 1:06 PM, Christopher Lam wrote:
> > Because e31f4c3f9 is causing errors on my build as well in different
> > ways.
> >
> > PS e31f4c3f9 must not be reverted for your packaging - please be
> > patient while a proper fix is pending.
> >
> > On 25/1/19 3:48 am, Stephen M. Butler wrote:
> >> On 1/24/19 2:32 AM, Christopher Lam wrote:
> >>> Stephen this bug is in 3.4 and was fixed in commit 95bee405c
> >>>
> >>> Could you try "git revert e31f4c3f9" as a test for your "31/12/70"
> >>> test-transaction errors?
> >>
> >> That worked.  Thank you.  BTW, how did you find that it was fixed?  I
> >> ask, because there is another one: 01/24/2019
> >>
> >> -rw-r--r-- 1 steve steve 461 Jan 23 14:16
> >> test--skip-test-stress-options.patch
> >>
> >>   cat test*
> >> Last-Update: 2018-10-02
> >> Forwarded: not-needed
> >> Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=796877
> >> Author: Dmitry Smirnov 
> >> Description: skip broken test
> >>
> >> --- a/gnucash/report/standard-reports/test/CMakeLists.txt
> >> +++ b/gnucash/report/standard-reports/test/CMakeLists.txt
> >> @@ -13,9 +13,8 @@
> >> test-income-gst.scm
> >>   )
> >> set(scm_test_with_textual_ports_SOURCES
> >> -test-stress-options.scm
> >>   )
> >> set(GUILE_DEPENDS
> >> scm-gnc-module
> >>
> >> ==
> >>
> >> Any way I can search and see if this patch is already in maint?
> >>
> >>
> >>> On 24/1/19 3:05 am, Stephen M. Butler wrote:
> >>>> Found this patch on the debian version for 3.4
> >>>>
> >>>> Origin: upstream, https://bugs.gnucash.org/attachment.cgi?id=373094
> >>>> Bug-Upstream: https://bugs.gnucash.org/show_bug.cgi?id=797008
> >>>> Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918057
> >>>> From: Maxim Cournoyer 
> >>>> Date: Wed, 2 Jan 2019 14:46:28 -0500
> >>>> Subject: tests: Fix a test failure in test-transaction.scm.
> >>>>
> >>>> With the New Year upon us, a test which was hard-coded to use 2018 now
> >>>> failed.
> >>>>
> >>>> Fixes issue #797008 (see:
> >>>> https://bugs.gnucash.org/show_bug.cgi?id=797008).
> >>>>
> >>>> * gnucash/report/standard-reports/test/test-transaction.scm:
> >>>> (trep-tests): Use the current year in the test string instead of a
> >>>> static one.
> >>>>
> >>>> --- a/gnucash/report/standard-reports/test/test-transaction.scm
> >>>> +++ b/gnucash/report/standard-reports/test/test-transaction.scm
> >>>> @@ -4,8 +4,9 @@
> >>>>(use-modules (gnucash report standard-reports transaction))
> >>>>(use-modules (gnucash report stylesheets))
> >>>>(use-modules (gnucash report report-system))
> >>>>(use-modules (gnucash report report-system test test-extras))
> >>>> +(use-modules (srfi srfi-19))
> >>>>(use-modules (srfi srfi-64))
> >>>>(use-modules (gnucash engine test srfi64-extras))
> >>>>(use-modules (sxml simple))
> >>>>(use-modules (sxml xpath))
> >>>> @@ -642,18 +643,20 @@
> >>>>  (set-option! options "General" "Common Currency" #t)
> >>>>  (set-option! options "General" "Show original currency
> >>>> amount" #t)
> >>>>  (set-option! options "Sorting" "Primary Key" 'date)
> >>>>  (set-option! options "Sorting" "Primary Subtotal for Date
> >>>> Key" 'none)
> >>>> -  (let* ((sxml (options->sxml options "dual columns")))
> >>>> +  (let

Re: [GNC-dev] Test failure

2019-01-26 Thread Christopher Lam
Another experiment. Try prefix your build with "TZ=UTC " on current maint.

Eg if using ninja, it'll be "TZ=UTC ninja check"

On Fri., 25 Jan. 2019, 11:52 Stephen M. Butler  On 1/24/19 7:36 PM, Christopher Lam wrote:
> > Revert is a git terminology, not a gnucash one. Welcome to version
> > control.
>
> That's the manual to which I referred.  It meant something else to my
> mind when I first saw your post.  But, after further thought, my
> previous thought was faulty.
>
>
> My first boss after college would draw a picture to describe the
> difference between a bug and a feature.
>
> I can't draw so a word will have to do (at less than a thousand words)!
>
> BUG:  draw stick figure.
>
>
> FEATURE:  Add pants, tie, gloves, shoes and a top hat.
>
>
> MORAL:  A feature is a bug all dressed up and ready to go out.
>
> >
> > Please remember this revert is reverting a buggy code with a previous
> > buggy code, so, cannot be consisted safe to package; best wait until
> > the clever devs can find a proper fix for gnc-date.
> >
> > On Fri., 25 Jan. 2019, 05:46 Stephen M. Butler  > <mailto:kg...@arrl.net> wrote:
> >
> > OH!  Light bulb on!
> > OK.  I understand what you said earlier.  I'll put the patches
> > back into
> > the packaging.
> >
> > Thanks for clearing that up.
> >
> > --Steve
> >
> > PS Looking in manual for 'revert' command.
> >
>
> --
> 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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Test failure

2019-01-26 Thread Christopher Lam
Thank you Stephen for your results.

It would seem that the test-transaction failure is caused by a faulty
libicu-dev whereas my failure caused by some other issue related to Time
zones.

C

On Sun., 27 Jan. 2019, 09:55 Stephen M. Butler  On 1/26/19 3:13 AM, Christopher Lam wrote:
> > Another experiment. Try prefix your build with "TZ=UTC " on current
> > maint.
> >
> > Eg if using ninja, it'll be "TZ=UTC ninja check"
>
>
> TZ=UTC dpkg- -rfakeroot -b -uc
>
> 
>
> End testing: Jan 27 01:47 UTC
> + exit 2
> debian/rules:65: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 2
> make[1]: Leaving directory '/home/steve/Projects/GnuCash/gnucash'
> debian/rules:24: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
>
> Same error -- Test 109 that fails.
>
>
> This is with the patches for 3.4.  I verified before Sabbath that 3.4
> builds and passes the tests.  Tried your test first thing this evening
> after git checkout maint and git pull.  I am at 3.4-43-g84d1c3645 which
> builds but doesn't pass the tests.  So, I could build turning off the
> test step.
>
> However, Friday I was learning more about git bisect to see if I could
> figure out which patch caused the tests to start failing.  However, a
> couple of items got in the way:  1--time;  2--some commits don't build.
> That messed me up a bit.  So, I may start over again with the bisect
> (just for my own edification) and see what happens.  Maybe this time
> I'll do a git describe each time and take notes so I'll be a little more
> cognizant of what I'm learning.  <>
>
>
> --Steve (in the dark)
>
> >
> > On Fri., 25 Jan. 2019, 11:52 Stephen M. Butler  > <mailto:kg...@arrl.net> wrote:
> >
> > On 1/24/19 7:36 PM, Christopher Lam wrote:
> > > Revert is a git terminology, not a gnucash one. Welcome to version
> > > control.
> >
> > That's the manual to which I referred.  It meant something else to my
> > mind when I first saw your post.  But, after further thought, my
> > previous thought was faulty.
> >
> >
> > My first boss after college would draw a picture to describe the
> > difference between a bug and a feature.
> >
> > I can't draw so a word will have to do (at less than a thousand
> > words)!
> >
> > BUG:  draw stick figure.
> >
> >
> > FEATURE:  Add pants, tie, gloves, shoes and a top hat.
> >
> >
> > MORAL:  A feature is a bug all dressed up and ready to go out.
> >
> > >
> > > Please remember this revert is reverting a buggy code with a
> > previous
> > > buggy code, so, cannot be consisted safe to package; best wait
> until
> > > the clever devs can find a proper fix for gnc-date.
> > >
> > > On Fri., 25 Jan. 2019, 05:46 Stephen M. Butler  > <mailto:kg...@arrl.net>
> > > <mailto:kg...@arrl.net <mailto:kg...@arrl.net>> wrote:
> > >
> > > OH!  Light bulb on!
> > > OK.  I understand what you said earlier.  I'll put the patches
> > > back into
> > > the packaging.
> > >
> > > Thanks for clearing that up.
> > >
> > > --Steve
> > >
> > > PS Looking in manual for 'revert' command.
> > >
> >
> > --
> > Stephen M Butler, PMP, PSM
> > stephen.m.butle...@gmail.com <mailto:stephen.m.butle...@gmail.com>
> > kg...@arrl.net <mailto:kg...@arrl.net>
> > 253-350-0166
> > ---
> > GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
> >
> >
>
> --
> 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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Test failure

2019-01-26 Thread Christopher Lam
Stephen please spend some CPU burning time on my chartJS branch which 
needs beta testing?


$git clone 
https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart



On 27/1/19 2:52 pm, Stephen M. Butler wrote:

On 1/26/19 10:29 PM, John Ralls wrote:

Stephen,

By all means learn about git bisect, it's an extremely useful troubleshooting 
tool. But don't exercise yourself too much about this particular failure, Chris 
and I know exactly what commit caused it and that the underlying cause is a bug 
in ICU (International Components for Unicode, http://site.icu-project.org/) 
versions 57-62.

I figured the devs were way ahead of me.  And I'm burning the CPU this
evening finding that I can't compile 3.4-21 thru (I'm guessing) 3.4-38.
I'm up to 3.4-29 at this point and already know that -37 and -38 don't
compile on my box.  But -39, -40, and -43 do.  Don't know about -41 and
-42 (and probably won't check them).

Busy day tomorrow so I doubt the cpu will even get warmed up!  It's
pushing 11 pm so I'll call it quits on this exercise.

Thanks for the details.

--Steve


I had thought that the problem was confined to 1969, but tonight got 
https://bugs.gnucash.org/show_bug.cgi?id=797067 which makes me think that it's 
every year, so more testing needed.

Regards,
John Ralls



On Jan 26, 2019, at 5:55 PM, Stephen M. Butler  wrote:

On 1/26/19 3:13 AM, Christopher Lam wrote:

Another experiment. Try prefix your build with "TZ=UTC " on current
maint.

Eg if using ninja, it'll be "TZ=UTC ninja check"

TZ=UTC dpkg- -rfakeroot -b -uc



End testing: Jan 27 01:47 UTC
+ exit 2
debian/rules:65: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/home/steve/Projects/GnuCash/gnucash'
debian/rules:24: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

Same error -- Test 109 that fails.


This is with the patches for 3.4.  I verified before Sabbath that 3.4
builds and passes the tests.  Tried your test first thing this evening
after git checkout maint and git pull.  I am at 3.4-43-g84d1c3645 which
builds but doesn't pass the tests.  So, I could build turning off the
test step.

However, Friday I was learning more about git bisect to see if I could
figure out which patch caused the tests to start failing.  However, a
couple of items got in the way:  1--time;  2--some commits don't build.
That messed me up a bit.  So, I may start over again with the bisect
(just for my own edification) and see what happens.  Maybe this time
I'll do a git describe each time and take notes so I'll be a little more
cognizant of what I'm learning.  <>


--Steve (in the dark)


On Fri., 25 Jan. 2019, 11:52 Stephen M. Butler mailto:kg...@arrl.net> wrote:

On 1/24/19 7:36 PM, Christopher Lam wrote:

Revert is a git terminology, not a gnucash one. Welcome to version
control.

That's the manual to which I referred.  It meant something else to my
mind when I first saw your post.  But, after further thought, my
previous thought was faulty.


My first boss after college would draw a picture to describe the
difference between a bug and a feature.

I can't draw so a word will have to do (at less than a thousand
words)!

BUG:  draw stick figure.


FEATURE:  Add pants, tie, gloves, shoes and a top hat.


MORAL:  A feature is a bug all dressed up and ready to go out.


Please remember this revert is reverting a buggy code with a

previous

buggy code, so, cannot be consisted safe to package; best wait until
the clever devs can find a proper fix for gnc-date.

On Fri., 25 Jan. 2019, 05:46 Stephen M. Butler 
<mailto:kg...@arrl.net>

<mailto:kg...@arrl.net <mailto:kg...@arrl.net>> wrote:

  OH!  Light bulb on!
  OK.  I understand what you said earlier.  I'll put the patches
  back into
  the packaging.

  Thanks for clearing that up.

  --Steve

  PS Looking in manual for 'revert' command.


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



--
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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Test failure

2019-01-26 Thread Christopher Lam

Ok my bad

May be safer to reuse your own gnucash repository

 * cd gnucash
 * git remote add chris https://github.com/christopherlam/gnucash.git
 * git fetch --all
 * git checkout chris/maint-chartjs-budget-barchart
 * dpkg etc

and to revert to main branch:

 * git checkout maint



On 27/1/19 3:04 pm, Stephen M. Butler wrote:

On 1/26/19 10:54 PM, Christopher Lam wrote:

Stephen please spend some CPU burning time on my chartJS branch which
needs beta testing?

$git clone
https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart


Thought I'd start this while headed toward some z's.  Too tired to
figure out what happened.

  git clone
https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart
Cloning into 'maint-chartjs-budget-barchart'...
fatal: repository
'https://github.com/christopherlam/gnucash/tree/maint-chartjs-budget-barchart/'
not found


--Steve



On 27/1/19 2:52 pm, Stephen M. Butler wrote:

On 1/26/19 10:29 PM, John Ralls wrote:

Stephen,

By all means learn about git bisect, it's an extremely useful
troubleshooting tool. But don't exercise yourself too much about
this particular failure, Chris and I know exactly what commit caused
it and that the underlying cause is a bug in ICU (International
Components for Unicode, http://site.icu-project.org/) versions 57-62.

I figured the devs were way ahead of me.  And I'm burning the CPU this
evening finding that I can't compile 3.4-21 thru (I'm guessing) 3.4-38.
I'm up to 3.4-29 at this point and already know that -37 and -38 don't
compile on my box.  But -39, -40, and -43 do.  Don't know about -41 and
-42 (and probably won't check them).

Busy day tomorrow so I doubt the cpu will even get warmed up!  It's
pushing 11 pm so I'll call it quits on this exercise.

Thanks for the details.

--Steve


I had thought that the problem was confined to 1969, but tonight got
https://bugs.gnucash.org/show_bug.cgi?id=797067 which makes me think
that it's every year, so more testing needed.

Regards,
John Ralls



On Jan 26, 2019, at 5:55 PM, Stephen M. Butler  wrote:

On 1/26/19 3:13 AM, Christopher Lam wrote:

Another experiment. Try prefix your build with "TZ=UTC " on current
maint.

Eg if using ninja, it'll be "TZ=UTC ninja check"

TZ=UTC dpkg- -rfakeroot -b -uc



End testing: Jan 27 01:47 UTC
+ exit 2
debian/rules:65: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 2
make[1]: Leaving directory '/home/steve/Projects/GnuCash/gnucash'
debian/rules:24: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

Same error -- Test 109 that fails.


This is with the patches for 3.4.  I verified before Sabbath that 3.4
builds and passes the tests.  Tried your test first thing this evening
after git checkout maint and git pull.  I am at 3.4-43-g84d1c3645
which
builds but doesn't pass the tests.  So, I could build turning off the
test step.

However, Friday I was learning more about git bisect to see if I could
figure out which patch caused the tests to start failing.  However, a
couple of items got in the way:  1--time;  2--some commits don't
build.
That messed me up a bit.  So, I may start over again with the bisect
(just for my own edification) and see what happens.  Maybe this time
I'll do a git describe each time and take notes so I'll be a little
more
cognizant of what I'm learning.  <>


--Steve (in the dark)


On Fri., 25 Jan. 2019, 11:52 Stephen M. Butler mailto:kg...@arrl.net> wrote:

     On 1/24/19 7:36 PM, Christopher Lam wrote:

Revert is a git terminology, not a gnucash one. Welcome to version
control.

     That's the manual to which I referred.  It meant something
else to my
     mind when I first saw your post.  But, after further thought, my
     previous thought was faulty.


     My first boss after college would draw a picture to describe the
     difference between a bug and a feature.

     I can't draw so a word will have to do (at less than a thousand
     words)!

     BUG:  draw stick figure.


     FEATURE:  Add pants, tie, gloves, shoes and a top hat.


     MORAL:  A feature is a bug all dressed up and ready to go out.


Please remember this revert is reverting a buggy code with a

     previous

buggy code, so, cannot be consisted safe to package; best wait until
the clever devs can find a proper fix for gnc-date.

On Fri., 25 Jan. 2019, 05:46 Stephen M. Butler 
     <mailto:kg...@arrl.net>

<mailto:kg...@arrl.net <mailto:kg...@arrl.net>> wrote:

   OH!  Light bulb on!
   OK.  I understand what you said earlier.  I'll put the patches
   back into
   the packaging.

   Thanks for clearing that up.

   --Steve

   PS Looking in manual for 'revert' command.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Pie Chart

2019-01-27 Thread Christopher Lam

Erm.

None of these...

All feedback below relates to UI / styling.

Mainly need beta-testing the new charting infrastructure, upgraded from 
jqplot to chartJS. Is there any noticeable change? Any bugs? Notice 
interactivity -- try clicking on chart, and compare behaviour with 
previous jqplot-based charts. Also notice linecharts changed from x/y to 
category/amount which will be neater.


C

On 28/1/19 6:22 am, Stephen M. Butler wrote:

Not sure which pie you wanted me to review.  I picked the Asset one for
first blush look.

1.  The Account tab scroll bar color is the same as the background color
for the selected accounts.  Makes it impossible to see the scroll bar
until moved to a non-selected set of accounts.  (Two screen shots
attached).  I haven't setup any color scheme so am using the defaults.

2.  For personal books, I have setup the "company name" as "The Butler
Family".  It didn't show on the title.  For the Balance Sheet report, I
have it setup as:


   Balance Sheet


 The Butler Family


   12/31/2019

3.  Not sure I like the default end-date to be the end of the accounting
period.  Not sure which one I prefer though:

             Today -- most times I select that.

             End Prior Month -- I think most accountants would want that
most of the time.

4.  Which brings me to a topic not specific to any of these reports.  I
know you can save a configuration.  But, then you have to remember to go
to the saved select to pick what you had previously saved.

Enhancement Request:  Make a way that the user can change the defaults
for a report and have those saved so they become the new defaults and
are picked up whenever the report is selected again.

I have been toying with doing the saved reports a different way.

A.  Tie the saved configuration to the base report (maybe via the
reports GUID).

B.  Allow multiple configurations for the report to be saved with each
having a configuration specific name/title/id or whatever.  One of which
is "Default".

C.  Allow user to update the configurations and save back over the top
of a specific named configuration.

D.  Multiple reports could each have the same configuration name -- but
would be different due to the report GUID (or whatever used to identify
the report).

E.  When report is first selected, get the "Default" configuration and
use that.  If no "Default" and there are saved configurations, then list
the saved configurations for that report and let the user pick one to be
used.  If no saved, then use the factory default.


I haven't looked at the current saved configurations to see how they are
setup so I may be totally out of line here.  My vague thoughts are this
could be an XML backend with the report ID being the major selected, the
config name the second selection, and then each set option would have
its ID/Value pairs listed.

I've even thought so far as if there were ID/Value pairs not listed but
being used by the report, it would walk back up the configuration Tree
looking at "Default" and then the factory settings to resolve a missing
value.  So far, I only see three levels to this tree:   Factory,
"Default", and "Named" config.

But, you didn't ask me for that!  What, in particular, would you like me
to review?



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Pie Chart

2019-01-27 Thread Christopher Lam
You could try creating a local build via ninja (documented in wiki). Thanks
for beta testing.

On Mon., 28 Jan. 2019, 06:43 Stephen M. Butler  Oh.
>
> Confession.  I don't look at pie, bar, graph, etc charts.  So, I'd need
> both versions installed and switch back and forth.
>
> How do I get  both  versions available?  Without uninstalling one and
> installing the other every time I wanted to compare the results!
>
> I might be the wrong guy for this job!
>
> --Steve
>
>
> On 1/27/19 2:29 PM, Christopher Lam wrote:
> > Erm.
> >
> > None of these...
> >
> > All feedback below relates to UI / styling.
> >
> > Mainly need beta-testing the new charting infrastructure, upgraded
> > from jqplot to chartJS. Is there any noticeable change? Any bugs?
> > Notice interactivity -- try clicking on chart, and compare behaviour
> > with previous jqplot-based charts. Also notice linecharts changed from
> > x/y to category/amount which will be neater.
> >
> > C
> >
> > On 28/1/19 6:22 am, Stephen M. Butler wrote:
> >> Not sure which pie you wanted me to review.  I picked the Asset one for
> >> first blush look.
> >>
> >> 1.  The Account tab scroll bar color is the same as the background color
> >> for the selected accounts.  Makes it impossible to see the scroll bar
> >> until moved to a non-selected set of accounts.  (Two screen shots
> >> attached).  I haven't setup any color scheme so am using the defaults.
> >>
> >> 2.  For personal books, I have setup the "company name" as "The Butler
> >> Family".  It didn't show on the title.  For the Balance Sheet report, I
> >> have it setup as:
> >>
> >>
> >>Balance Sheet
> >>
> >>
> >>  The Butler Family
> >>
> >>
> >>12/31/2019
> >>
> >> 3.  Not sure I like the default end-date to be the end of the accounting
> >> period.  Not sure which one I prefer though:
> >>
> >>  Today -- most times I select that.
> >>
> >>  End Prior Month -- I think most accountants would want that
> >> most of the time.
> >>
> >> 4.  Which brings me to a topic not specific to any of these reports.  I
> >> know you can save a configuration.  But, then you have to remember to go
> >> to the saved select to pick what you had previously saved.
> >>
> >> Enhancement Request:  Make a way that the user can change the defaults
> >> for a report and have those saved so they become the new defaults and
> >> are picked up whenever the report is selected again.
> >>
> >> I have been toying with doing the saved reports a different way.
> >>
> >> A.  Tie the saved configuration to the base report (maybe via the
> >> reports GUID).
> >>
> >> B.  Allow multiple configurations for the report to be saved with each
> >> having a configuration specific name/title/id or whatever.  One of which
> >> is "Default".
> >>
> >> C.  Allow user to update the configurations and save back over the top
> >> of a specific named configuration.
> >>
> >> D.  Multiple reports could each have the same configuration name -- but
> >> would be different due to the report GUID (or whatever used to identify
> >> the report).
> >>
> >> E.  When report is first selected, get the "Default" configuration and
> >> use that.  If no "Default" and there are saved configurations, then list
> >> the saved configurations for that report and let the user pick one to be
> >> used.  If no saved, then use the factory default.
> >>
> >>
> >> I haven't looked at the current saved configurations to see how they are
> >> setup so I may be totally out of line here.  My vague thoughts are this
> >> could be an XML backend with the report ID being the major selected, the
> >> config name the second selection, and then each set option would have
> >> its ID/Value pairs listed.
> >>
> >> I've even thought so far as if there were ID/Value pairs not listed but
> >> being used by the report, it would walk back up the configuration Tree
> >> looking at "Default" and then the factory settings to resolve a missing
> >> value.  So far, I only see three levels to this tree:   Factory,
> >> "Default", and "Named" config.
> >>
> >> But, you didn't ask me for that!  What, in particular, would you like me
> >> to review?
> >>
> >>
> >
>
> --
> 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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Pie Chart

2019-01-29 Thread Christopher Lam
p.s. from your screenshots, it would seem that the charts are working well.

Hint: new features added, and old features resurrected:
- clicky links from pie/line/bar graphs to drill down into
sub-charts,sub-reports, or register (this was disabled >10yrs ago?)
- fixed formatting amounts/axes, labelling currencies, etc
- budget barchart removed restrictive date selection (because budgets
already have their own dates)
- internally a much cleaner approach
- some animation

otherwise most/all charts should be working exactly as they previously
were, and should be nearly 100% compatible with the saved-reports in 3.x
(except budget barchart)

feedback required: any unexpected changes, compatibility issues with
previous jqplot charts.

On Mon, 28 Jan 2019 at 14:42, Christopher Lam 
wrote:

> You could try creating a local build via ninja (documented in wiki).
> Thanks for beta testing.
>
> On Mon., 28 Jan. 2019, 06:43 Stephen M. Butler 
>> Oh.
>>
>> Confession.  I don't look at pie, bar, graph, etc charts.  So, I'd need
>> both versions installed and switch back and forth.
>>
>> How do I get  both  versions available?  Without uninstalling one and
>> installing the other every time I wanted to compare the results!
>>
>> I might be the wrong guy for this job!
>>
>> --Steve
>>
>>
>> On 1/27/19 2:29 PM, Christopher Lam wrote:
>> > Erm.
>> >
>> > None of these...
>> >
>> > All feedback below relates to UI / styling.
>> >
>> > Mainly need beta-testing the new charting infrastructure, upgraded
>> > from jqplot to chartJS. Is there any noticeable change? Any bugs?
>> > Notice interactivity -- try clicking on chart, and compare behaviour
>> > with previous jqplot-based charts. Also notice linecharts changed from
>> > x/y to category/amount which will be neater.
>> >
>> > C
>> >
>> > On 28/1/19 6:22 am, Stephen M. Butler wrote:
>> >> Not sure which pie you wanted me to review.  I picked the Asset one for
>> >> first blush look.
>> >>
>> >> 1.  The Account tab scroll bar color is the same as the background
>> color
>> >> for the selected accounts.  Makes it impossible to see the scroll bar
>> >> until moved to a non-selected set of accounts.  (Two screen shots
>> >> attached).  I haven't setup any color scheme so am using the defaults.
>> >>
>> >> 2.  For personal books, I have setup the "company name" as "The Butler
>> >> Family".  It didn't show on the title.  For the Balance Sheet report, I
>> >> have it setup as:
>> >>
>> >>
>> >>Balance Sheet
>> >>
>> >>
>> >>  The Butler Family
>> >>
>> >>
>> >>12/31/2019
>> >>
>> >> 3.  Not sure I like the default end-date to be the end of the
>> accounting
>> >> period.  Not sure which one I prefer though:
>> >>
>> >>  Today -- most times I select that.
>> >>
>> >>  End Prior Month -- I think most accountants would want
>> that
>> >> most of the time.
>> >>
>> >> 4.  Which brings me to a topic not specific to any of these reports.  I
>> >> know you can save a configuration.  But, then you have to remember to
>> go
>> >> to the saved select to pick what you had previously saved.
>> >>
>> >> Enhancement Request:  Make a way that the user can change the defaults
>> >> for a report and have those saved so they become the new defaults and
>> >> are picked up whenever the report is selected again.
>> >>
>> >> I have been toying with doing the saved reports a different way.
>> >>
>> >> A.  Tie the saved configuration to the base report (maybe via the
>> >> reports GUID).
>> >>
>> >> B.  Allow multiple configurations for the report to be saved with each
>> >> having a configuration specific name/title/id or whatever.  One of
>> which
>> >> is "Default".
>> >>
>> >> C.  Allow user to update the configurations and save back over the top
>> >> of a specific named configuration.
>> >>
>> >> D.  Multiple reports could each have the same configuration name -- but
>> >> would be different due to the report GUID (or whatever used to identify
>> >> the report).
>> >>
>> >> E.  When report is first selected, ge

Re: [GNC-dev] Pie Chart

2019-01-29 Thread Christopher Lam
Hello

On Wed, 30 Jan 2019 at 09:31, Stephen M. Butler  wrote:

> So far, my only negative is with the Average balance chart.  It's too
> tall and I lose the captions at the bottom (I maybe see 1 or 2 pixels of
> them).  When I scroll down then I lose the chart title at the top.  I am
> running 1920x1080 (16:9)
>

Agree - this is caused by *all* charts default to use 100% page size; I
think they should be reduced to 80%, with no (IMHO) negative consequences.

> Hint: new features added, and old features resurrected:
> > - clicky links from pie/line/bar graphs to drill down into
> > sub-charts,sub-reports, or register (this was disabled >10yrs ago?)
>
> SMB:  I don't think I made it to the register.  Just saw the
> non-selected sections expand to fill the pie.
>

Try: Asset/Income/Expense/Liability Chart and keep drilling down.
I think the Income/Expense over time may be modified to launch the
Transaction Report highlighting relevant period. TBD tonight :)


> SMB:  At least you have the end-of-year set correctly.  origin/maint
> 3.4-50 has a problem.  Separate email.
>

This end-of-year is the exact same bug currently affecting maint. My branch
currently reverts the offending commit, so, cannot be considered safe to
ship, but is adequate for testing. Thank you for feedback!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Pie Chart

2019-01-31 Thread Christopher Lam
Thanks for feedback.

Most of these issues are not caused by reports but rather webkit/UI issues
:) I haven't found way to trigger report drill-down without an intermediate
"Load" anchor.

Try refreshing my branch. Latest developments: the yAxis amounts are now
formatted correctly according to locale; US users see "$1,000.00" "€1,000.00
*"* whereas some EU users wil see "1.000,00 $" "1.000,00 €*"*. These things
matter in an internationally focussed program :)

On Thu, 31 Jan 2019 at 09:56, Stephen M. Butler  wrote:

> Took me awhile to figure out how to drill down.  Double clicking didn't
> do it.  I finally noticed the small print in the upper left corner that
> I eventually determined said "load".  Clicking that took me to the child
> accounts of the one originally clicked.  However, there was no "unload"
> to go back up a level.  Only path was deeper.
>
> Once at the deepest account, the transaction window did open and it was
> easy to close that -- but still no method to back out to the original
> chart (that I could determine).
>
> I wonder if there is something more intuitive than the small print
> "load" to do a drill down.
>
> OK.  Accidentally found the "back" option under the right click.  Only
> found it because I was thinking that a double click would be a natural
> go deeper signal -- so what would be a corresponding "go back" signal?
> Double right click??  Tried that and found that right click did bring up
> the option menu to navigate back.
>
> So then started playing with the options on the right click.  Found that
> forward worked the same as "load" but only until at the lowest account.
> Had to left click and then click on "load" to get the transaction
> listing.  To be consistent, the Forward menu item should also work in
> that case and bring up the transaction details.
>
> I tried the "Inspect Element" item and decided I didn't want to know
> what that was about!  <>
>
> Hmm.  Forward isn't consistent.  Only available if you have previously
> gone down a level by clicking on load.
>
> So you have to left click on the area of interest then left click on
> load and only then will the Forward/Back items on the right click be
> available.  That's awkward.
>
> How about a double left click automatically goes down on the area
> clicked or always allow a Forward if the user right clicks on the area.
> In that case go deeper on the area on which the left click happened.  Or
> allow both methods.  I'm thinking the "load" in the upper left is
> cumbersome and rather not have it.
>
> Never could figure out when the "stop" item is available.
>
> --Steve
>
> On 1/29/19 7:36 PM, Christopher Lam wrote:
> > Hello
> >
> > On Wed, 30 Jan 2019 at 09:31, Stephen M. Butler  > <mailto:kg...@arrl.net>> wrote:
> >
> > So far, my only negative is with the Average balance chart.  It's too
> > tall and I lose the captions at the bottom (I maybe see 1 or 2
> > pixels of
> > them).  When I scroll down then I lose the chart title at the
> > top.  I am
> > running 1920x1080 (16:9)
> >
> >
> > Agree - this is caused by *all* charts default to use 100% page size;
> > I think they should be reduced to 80%, with no (IMHO) negative
> > consequences.
> >
> > > Hint: new features added, and old features resurrected:
> > > - clicky links from pie/line/bar graphs to drill down into
> > > sub-charts,sub-reports, or register (this was disabled >10yrs ago?)
> >
> > SMB:  I don't think I made it to the register.  Just saw the
> > non-selected sections expand to fill the pie.
> >
> >
> > Try: Asset/Income/Expense/Liability Chart and keep drilling down.
> > I think the Income/Expense over time may be modified to launch the
> > Transaction Report highlighting relevant period. TBD tonight :)
> >
> >
> > SMB:  At least you have the end-of-year set correctly.  origin/maint
> > 3.4-50 has a problem.  Separate email.
> >
> >
> > This end-of-year is the exact same bug currently affecting maint. My
> > branch currently reverts the offending commit, so, cannot be
> > considered safe to ship, but is adequate for testing. Thank you for
> > feedback!
>
>
> --
> 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-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Pie Chart

2019-01-31 Thread Christopher Lam
Also latest developments will modify budget bar chart to specify budget
periods rather than absolute dates, similar to budget.scm :-)

On Thu., 31 Jan. 2019, 22:05 Christopher Lam  Thanks for feedback.
>
> Most of these issues are not caused by reports but rather webkit/UI issues
> :) I haven't found way to trigger report drill-down without an intermediate
> "Load" anchor.
>
> Try refreshing my branch. Latest developments: the yAxis amounts are now
> formatted correctly according to locale; US users see "$1,000.00" "€1,000.00
> *"* whereas some EU users wil see "1.000,00 $" "1.000,00 €*"*. These
> things matter in an internationally focussed program :)
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] Pie Chart

2019-02-01 Thread Christopher Lam




Most of these issues are not caused by reports but rather webkit/UI
issues :) I haven't found way to trigger report drill-down without an
intermediate "Load" anchor.

Hopefully you can request an enhancement from them.


It's an internal webkit issue and too difficult to fix. I think the 
intermediate "Load" button is a safe approach for now.


Try refreshing -- I've increased visibility of this button. I do not 
think it will be straightforward to skip the 2-step drilldown for now.


Will need feedback on various links between reports -- although the 
links "work", I'm still not 100% sure the links make sense.


C

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


[GNC-dev] Further feedback

2019-02-03 Thread Christopher Lam

Hi Stephen

If possible I'd be grateful if you would check my branch 
maint-scheme-progress


 * cd gnucash
 * git fetch --all
 * git checkout chris/maint-scheme-progress
 * dpkg etc (note there will be gnc-date error - ignore)

Main issues for feedback:

 * Reconciliation report modified header hopefully is satisfactory

Thank you, your (and house accountant) feedback *very* much appreciated!

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


  1   2   3   4   >