[GNC] Report - Income Statement - Layout problem
Carl-Kensaku HERBORT
it at digiene.ch
Wed Mar 23 11:26:23 EDT 2022
Hello,
Yes, I know GnuCash is an open-source volunteer effort, hence all the
thank you, and answering sometimes to the same questions several times
from different people. It's normal in a volunteer project.
I am myself a long-time grateful and enthusiastic open-source software
user and IRL helper (you won't find me in many forums answering
questions but I am doing it in the physical world).
But, I don't think users should be sorry or ashamed to have some level
of expectation that a software will work when it comes to a core, basic
and widely used/needed function (even if it is an open-source volunteer
project). For most SMEs (at least in my country), the whole point and
sole purpose of an accounting software is to produce two reports: Income
Statement and Balance Sheet (non-multicolumn). It is a legal requirement
for most SMEs for the tax declaration and other formalities.
It didn't work out in GnuCash (so far). No problem, no hard feelings and
certainly no blame: it is a wonderful piece of software. And I am happy
if it gets solved sometime in the future by some hard-working generous
programmers giving their free time.
But I will not feel sorry or ashamed to just have expectations.
On the other hand, I am really sorry if that hurt your feelings, that
wasn't the intent. My apologies.
Again, thank you all so much for all your help.
Best regards
--
Carl-Kensaku HERBORT
DIGIENE
Case postale
CH-1002 Lausanne
Suisse
+41 (0) 21 320 22 66
Le 23.03.22 à 15:21, Christopher Lam a écrit :
> Please be aware that GnuCash is a volunteer effort. In so many (20+)
> years of users there have been no complaints about this particular
> layout issue in the Income Statement. A fresh pair of eyes, however,
> found this genuine layout issue. The Multicolumn Income Statement report
> in the Experimental menu may be more suitable; it is much more capable
> and has a more conventional layout.
>
> Meanwhile, now that this is now known, and Adrien has kindly found the
> root cause, it is likely that the developers will be able to fix the
> Income Statement.
>
> On Wed, 23 Mar 2022 at 13:49, Carl-Kensaku HERBORT <it at digiene.ch
> <mailto:it at digiene.ch>> wrote:
>
> Hello,
>
> Thanks to everyone for your help and time.
>
> It is a shame that it is so complicated to make the Income Statement
> report look normal, like the Balance Sheet report, which also has two
> sections (Assets and Liabilities) that have no problem at all.
>
> I already have to use two separate software: an ERP/CRM for invoicing
> and daily accounting and GnuCash for heavier monthly/yearly accounting,
> mainly to produce the Income Statement Report and Balance Sheet report
> (or so was my plan). I didn't know that GnuCash was not made for that
> and that a third software (or SCHEME/HTML coding & modifications) was
> needed just to get even basic reports that all SME business need.
>
> I guess there is a first for everything: I am giving up.
>
> Again, thanks a lot to everyone who took on their free time to
> answer my
> questions.
>
> Have a nice day
>
> Best regards
>
> --
> Carl-Kensaku HERBORT
> DIGIENE
> Case postale
> CH-1002 Lausanne
> Suisse
>
> +41 (0) 21 320 22 66
>
> Le 22.03.22 à 05:24, Adrien Monteleone a écrit :
> > I stand corrected, this can happen regardless of the depth
> preference.
> >
> > The issue is entirely caused (best I can tell) by using separate
> tables
> > for the Income & Expense sections.
> >
> > Since the browser will adjust the label column to fit the
> content, if
> > those content widths differ, you'll see misalignment.
> >
> > In my case, due to some long account names, my Income section was
> > slightly wider than the Expense section despite being depth
> limited to
> > 4. (the reverse of the OP's image and what I found at depth > 4)
> >
> > The quickest solution is simply to put the Income & Expense
> sections in
> > one HTML table element. This will cause the browser to size all
> 1st <td>
> > elements on each row to the same maximum to fit the widest content.
> > (effectively sizing the first column all the same)
> >
> > There might be a complication with the ordering since there is a
> report
> > option to turn off 'default Income section first' in the report.
> >
> > One small additional issue, is that this approach provides no
> spacing
> > between sections.
> >
> > This can be solved by adding:
> >
> > <tr><!--presentation hack to provide spacing between P&L sections-->
> > <td>
> >
> > </td>
> > </tr>
> >
> > after the first section's total row. (this generates a blank
> table row
> > with content height as a visual spacer, which can be adjusted with a
> > font-size declaration if desired.)
> >
> > I don't like that approach, but it is quick and easy. (the report
> HTML
> > is full of presentation hacks, and one such hack, possibly
> causing this
> > problem, is the use of being inserted as an account label
> > indention mechanism rather than generating additional columns.)
> >
> > I'm not sure of the table semantics with this approach either.
> >
> > Technically, the report is a single entity, so perhaps a single
> table is
> > better in that regard even though each section has its own subtotal.
> >
> > I did play with adding cell padding-right to the first label-cell
> and it
> > worked, but that requires some calculation based on which column
> will
> > end up wider, and very likely a magic number or two for
> refinement, so
> > that's likely out as a solution.
> >
> > It might also be possible to calculate and add em-based
> padding-left to
> > the account label cells, (rather than multiple entities)
> but that
> > doesn't really solve the variable overall column-width problem.
> (it just
> > changes how the indention is accomplished)
> >
> > Fixed-width would very likely be a mess too. (and still have to be
> > calculated, and that might break on a per-browser basis)
> >
> > There might still be an out playing with box-sizing and/or display
> > properties but I don't really see any magic happening since the
> widths
> > are calculated independently.
> >
> > One final stretch might be to play with the size of the
> containers of
> > the two tables, but I seriously doubt it as that affects overflow
> > usually, not expanding something smaller.
> >
> > Regards,
> > Adrien
> >
> > On 3/21/22 9:47 PM, Adrien Monteleone wrote:
> >> For me, this only happens at depths 5,6, & ALL.
> >
> > _______________________________________________
> > gnucash-user mailing list
> > gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org>
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> <https://lists.gnucash.org/mailman/listinfo/gnucash-user>
> > If you are using Nabble or Gmane, please see
> > https://wiki.gnucash.org/wiki/Mailing_Lists
> <https://wiki.gnucash.org/wiki/Mailing_Lists> for more information.
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org <mailto:gnucash-user at gnucash.org>
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> <https://lists.gnucash.org/mailman/listinfo/gnucash-user>
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists
> <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.
>
More information about the gnucash-user
mailing list