GNOME Bugzilla – Bug 144243
[PATCH] Non-Standard Balance Sheet
Last modified: 2018-06-29 20:44:03 UTC
<headache>Geesh... this Bugzilla is such a headache...</> Reports -> Assets & Liabilities -> Balance Sheet (1) The Balance Sheet generated is in "report form" (one column). There is no way to generate an "account form" (two column) balance sheet. The Balance Sheet should be renamed "Report form Balance Sheet". (2) The balance sheet includes Profits & Losses for a specific period and lists a start date in its heading. This is non-standard accounting practice. A patch to fix these bugs will be attached. (Provided, of course, I can ever figure out how to get to that page!)
Created attachment 28651 [details] [review] diff of balance-sheet.scm and report-form-balance-sheet.scm, and standard-reports.scm This patch patches two files: Creates report-form-balance-sheet.scm from balance-sheet.scm. The new file is an improved and renamed version of balance-sheet.scm. Modifies standard-reports.scm to reflect the new name. Please float this patch upstream. (I do not know how to CVS.)
1) there is no "upstream", this is as upstream as you get 2) depending on the changes necessary, you should probably combine both reports into a single source file and just register two reports (or make the report style an option) 3) I've changed the summary to include 'patch' While I agree that including the period start-date is non-standard, I feel that there is a real need to report that date somewhere in the report. The title is one option. Another option would be the Profit line that's auto-computed. IMHO either way is ok, but it should be there so you see the feedback of the setting in the report itself.
> IMHO Unfortunately, personal opinion does not matter much in GAP. :) I have consulted an accountant on this, and he agrees that, while it is acceptable to include an "Unrealized Profits/Losses" in a balance sheet (to account for changes in market value), Profit/Loss has no place on the balance sheet. I have *removed* the start date from the options panel. THERE IS NO LONGER any "start date" for the balance sheet (as it should be). While the new balance sheet report still has some errors (misaligned rows & columns, etc.), I do believe it better reflects GAP.
Sorry, but I wont apply this.. If you don't have a start date then your equity computation is incorrect. See bug #113196 for the previous discussion on this topic.
> If you don't have a start date then your equity computation is incorrect. This is not true. By taking the start date to be (cons 0 0) [forever ago], any profits/losses outstanding (i.e., in unclosed temporary accounts) will be accumulated into equity. From the patched source... ------------- ;; sum any retained earnings (set! neg-retained-earnings (accountlist-get-comm-balance-at-date income-expense-accounts forever-ago date-tp)) ------------- From the disucssion in bug #113196: > I'm balking because currently a Balance Sheet is a snapshot at a > period in time -- it has no idea about accounting periods. Indeed, it ... > ------- Additional Comment #25 From Shinichi Sakata 2003-06-20 10:10 ------- > > I have just started using version 1.8.4. I am afraid that the changes > made to the balance sheet does not seem to fix the problem. The confirms the problem. my patch fixes this problem. Despite having a cool user name, linuxcpa does not know how to bridge the gap between the accounting and software. I know over two dozen computer languages and am an accounting student. I can tell you that the balance sheet *should not* reflect net income _and I am telling you how to fix it_. But, since my word alone will probably not convince you, here's something by way of explanation... Typically, at the end of each accounting period, an accountant will "close the books" by rolling into the equity account (directly or indirectly), three things: income, expenses, and draws (or investments). Thus, at the begining of every GAP accounting period, all income, expense, and draw accounts should be zero. GnuCash, however, should not assume that this is the case (much to the point of the above cited bug), and be robust enough to account for income/expense/draws from a previous period. By taking the sum of all income, expense, and equity accounts (drawing is an equity account with debit balance), all retained earnings ever accrued should be properly reflected in the Balance Sheet. If you need to demonstrate this for yourself, apply my patch, and try some examples yourself. Btw, you are right about combining the two report formats into one. I really should have an option "Balance sheet format: Account/Report", and have the source generate the report as requested. This will have to wait, however, until I learn more about gnc:html-acct-table*. If you'd like to tell me a bit about how GnuCash generates account tables (their options, and how to add columns to the right), I'm a willing student. :)
> > I have just started using version 1.8.4. I am afraid that the changes > > made to the balance sheet does not seem to fix the problem. The > > confirms the problem. my patch fixes this problem. That's because the change made it into 1.8.5, not 1.8.4. Take a look at what it was doing in the original 1.8.x releases. Shouldn't the P&L and Balance Sheet produce the same change in equity? According to my accounting book they should.
> Take a look at what it was doing in the original 1.8.x releases. Shouldn't the > P&L and Balance Sheet produce the same change in equity? According to my ...I don't have access to a 1.8.4 GnuCash, but I've read the other bug thread. The relationship between equity, net profit, and draws is one which many people have trouble expressing. My accounting professor is a certified CPA and has been teaching accounting for 25 years. Yet, on three separate occasions, he was asked to clarify this issue and could not. He kept on talking and talking about the issue, but never answered anybody's questions. I think accountants are so used to adjusting Equity that they take it for granted. This, combined with a technical language barrier, make it very difficult for *anyone* to explain. The Balance Sheet gets its ending capital figure from the Statement of Owner's Equity, which combines information from the P&L Statement and Trial Balance. Basically pre-closing Equity + Profits - Draws = post-closing Equity. It's the post-closing Equity which should be reported on the balance sheet. That means that all income/expense/draw accounts should be zeroed** during its computation. This **zeroing is done by "imagining" that all these accounts were properly closed prior to generating the report. This is done mathematically by summing-up any outstanding balances in these accounts. Technically, there shouldn't even be a "Retained Earnings" line. Rather, the retained earnings should be automagically rolled into the Equity figure. I'll make that change when I get around to it.... Bottom line is: P&L *affects* the ending equity but is not shown on the BS. That's what the P&L report is for.
Right... And in order to "imagine" that the income/expense accounts were properly closed prior to generating the report, you need to know the beginning of the period. Go pull down the 1.8.0 release of the balance sheet out of CVS and see the difference.
> Go pull down the 1.8.0 release of the balance sheet out of CVS and see the cf. above, I don't know how to CVS. Care to teach? > Right... And in order to "imagine" that the income/expense accounts were > properly closed prior to generating the report, you need to know the beginning > of the period. This is not true. The balance sheet *has* no period associated with it. The balance sheet is a snapshot of your A = L + E *at a specific time*. What you're probably thinking about as "the period" could be one of two things: (1) You could be thinking of the begining of the current accounting period (fiscal year). (2) You could be thinking of the period of time between when the accounts were last closed (zeroed) and when the Balance Sheet is drawn up. It could be that someone's been using GnuCash in a non-sandard way for five years and has *never* closed-out his accounts a la GAP. In this case, knowing the previous (1) period wouldn't help because his balance sheet from the previous period would also be incorrect. In that case, you could argue that knowing the previous (2) period would be needed... that is, you'd have to accumulate all income/expense/draw transactions since the last time his temporary accounts were zeroed (to use the computer term :). But there is an important feature to note here: The sum of any one set of transactions equaling zero, plus a second set of transactions is equal to the total of the second set of transactions. You seek the second set of transactions. I'm telling you it's equivalent to the second set + 0. Mathematically... T1 + T2 + T3 ... Tn = 0. T(n+1) + T(n+2) + T(n+3) ... Tm = Q. T1 + T2 + T3 ... Tm = Q. To calculate your closing Equity, it's sufficient to sum all income, expense, and draws/investments from forever-ago (cons 0 0) to the statement date.
> > Go pull down the 1.8.0 release of the balance sheet out of CVS and see the > > cf. above, I don't know how to CVS. Care to teach? man cvs See the "CVS Access" page on www.gnucash.org See the "Browse Source" page on www.gnucash.org Take a look at gnucash/src/report/standard-reports/balance-sheet.scm > It could be that someone's been using GnuCash in a non-sandard way for five > years and has *never* closed-out his accounts a la GAP. Gnucash doesn't have a feature to "close accounts a la GAP" so in effect EVERYONE is using gnucash is a "non-sandard[sic] way".... I've been re-reading the discussion in bug #113196 and I think the key here is this statement: "Net equity would be correct, but net income does not adjust itself to reflect a year spanning from July 1 of the prior year to June 30 of the current year." Perhaps the right fix would've been to remove the "net income" lines completely from the report and just leave "net equity" as the balance(equity) + balance(income) - balance(expense) ??? However, linuxcpa has a point about this, where he states: > You can do that, but gnucash will not be as useful as Quickbooks. It > is useful to show net income on the balance sheet as a component of > equity. You'll see that in that other bug I was quite hesitant to make the change that you're now asking me to revert. See http://bugzilla.gnome.org/show_bug.cgi?id=113196#c15 for my previous view. The key question is: if we want to actually report the change in equity between the previous balance sheet and the current balance sheet we need to know when the last balance sheet was run. *THAT* is the "start date" in the current report.
Are you trying to be difficult? Or do you honestly not get this...? Forget what linuxcpa said... forget about prior versions of GnuCash. I'm trying to fix GnuCash to produce accurate accounting reports. I have the greatest respect for someone who is willing to donate their time to maintaining & improving free software. And I'm greatful for your willingness and ability to contribute. However, I don't think you know enough about accounting to be making such claims as these.... > The key question is: if we want to actually report the change in equity between > the previous balance sheet and the current balance sheet we need to know when > the last balance sheet was run. *THAT* is the "start date" in the current report. Here's a little more info on year-end statements: Income Statement This is the first, and easiest, statement to prepare. It looks like this: Income Statement My Company For Year ended May 31, 2004 <--- covers an entire acct'g period Income Fees $400 Sales 120 Total income ---- $530 Expenses Rent $1000 Utilities 200 Total expenses ----$1200 Net Loss $670 <-- would be "Profit" if positive ---- You do this first, because you copy the "Net Profit/Loss" to the statement of owner's equity: Equity Statement Company Name For Year Ended May 31, 2004 <--- same period (start/end) as P&L Begining Equity $9000 Less Net Loss 670 Less Draws 2000 Unrealized Gains 0 ------------------ ---- Ending Equity $6330 New we know the closing equity for FY Apr. 1, 2003--equity on Apr. 1, 2004. I know, I know... this could be done other ways... but this is the sequence of steps that accountants use to prepare statements. Now, take the ending equity and plug it into a balance sheet. Balance Sheet [...note left column total = right column total] Company Name May 31, 2004 <--- for a specific instant in time exactly @ FY end Assets Liabilities Cash $16328 MIT Bookstore $999 Car 1000 Student Loan 9999 ---- ---- Total Assets $17328 Total Liabilities $10998 [from Equity Stmt.] ---> Equity 6330 ----- Total Liabilities & Equity $17328 Income for a given period is reflected in your Income Statement (aka P&L). Any change in equity is reflected in your Equity Statement (aka Statement of Owner's Equity). The balance of your assets, liabilities, and equity is shown in your Balance Sheet (aka Statement of Financial Condition). These are the reports, how they are generated, and what they show accountants. This is how it's done. Yes, you could compile all this information, complete with pie graphs and projections, into one mammoth report... but I'm not writing the Mother God Report. I'm trying to create a Balance Sheet which I can take to a board meeting and look normal. :) So, to answer your question... changes in equity are reported on a different report... the Equity Statement. Hope that helps.
> Are you trying to be difficult? Or do you honestly not get this...? > > Forget what linuxcpa said... forget about prior versions of GnuCash. > > I'm trying to fix GnuCash to produce accurate accounting reports. I do get it, and I am not trying to be difficult. Indeed, I've got my copy of FAP sitting right here next to me. However, I am also trying to make gnucash do as much as it can for as many people as possible. Note that Gnucash has no Equity Statement report. Right now that is combined with the balance sheet, mostly, somewhat, which is probably the root cause of this issue. Perhaps if that were fixed then we could make everyone happy (although linuxcpa would need to run an extra report to get the change in equity properly reported to him). > Btw, you are right about combining the two report formats into one. I really > should have an option "Balance sheet format: Account/Report", and have the > source generate the report as requested. This will have to wait, however, > until I learn more about gnc:html-acct-table*. If you'd like to tell me a bit > about how GnuCash generates account tables (their options, and how to add > columns to the right), I'm a willing student. :) The sources are in src/report/report-system/html-utilities.scm -- there is some documentation above the function definitions. If you have specific questions I can try to answer them (although #gnucash on irc.gnome.org is probably a more appropriate forum for that discussion, or even the gnucash-devel mailing list). Unfortunately I'm not the most familiar with that piece of code. I do thank you for continuing with this discussion on this bug. I'm just trying to make gnucash be as useful as possible to as many people as possible. Just reverting the code to previous behavior (which is essentially what you're asking) would be IMHO a step backwards. HOWEVER -- a step to the *side* is perfectly reasonable.
When I first reported this bug, my primary concern was to get the balance sheet in balance whilst not overwhealming Derrik. :-) Looks like we might be ready to add more features. Just some comments on the comments: :-) There are two ways an accounting package can apply dates to reports - set the date globally or set the date on the report level. If its set globally, my suggestion is to set it based upon what the user says is the month and day of the year end and use the system year to define the year end. When I reported this bug, one problem was that GNUCash assumed a calander year end. I don't know if that is the case any more. Right now GNUCash does not appear to use a global year end date that effects all of the various reports, automatically. As a result, year end dates have to be specified on the balance sheet if the end user wants to include an equity report in his balance sheet. Its not completely accurate to say that displaying an equity statement in a balance sheet is correct or incorrect - its more accurate to say that it is correct to have both options available. ;-) >(1) The Balance Sheet generated is in "report form" (one column). >There is no way to generate an "account form" (two column) balance sheet. >The Balance Sheet should be renamed "Report form Balance Sheet". > Although I would say that "account form" balance sheets are not common, it is not correct to say it is improper to include this as a report option. If its useful for Phil, I gather that it will be useful for other people too. I would not rename the standard report however. My suggestions: 1. Give the user the option to set the global year end date or to manually specify the appropriate dates when the reports are run. Most of the time, users will want to run reports on odd years as well. 2. Add the ability to run a two column balance sheet and call it exactly as Phil has named it. It makes no difference to me if this is an option or a separate report. 3. Keep the Balance Sheet name the same. 4. Create two display options for the Balance Sheet, one with, _and_ one without the detail of the equity statement displayed. >2) The balance sheet includes Profits & Losses for a specific period and >lists a start date in its heading. This is non-standard accounting practice. > In its purist form, a Balance sheet only includes a single amount that represents equity, and one component of equity is - retained earnings - net profit and loss from day one * at a point in time* - However, some people find the inclusion of the equity statement useful. My suggestions: 1. Only display the year end date at the top of the Balance Sheet 2. Display the period dates on the line that reads "profit and loss" - example 1/1/2000 - 12/31/2000. > > It could be that someone's been using GnuCash in a non-sandard way for five > > years and has *never* closed-out his accounts a la GAP. Typically, a program feature that requires the user to "close the books" is less flexible then having the program be able to "close the books" as needed when reports are run. If the user wants to run a report on a time period in which all activity has been posted to retained earnings, they won't be able to do so. However, if the program is able to calculate retained earnings on the fly, this flexibility will not be lost. >These are the reports, how they are generated, and what they show accountants. >This is how it's done. Yes, you could compile all this information, complete >with pie graphs and projections, into one mammoth report... but I'm not writing >the Mother God Report. I'm trying to create a Balance Sheet which I can take >to a board meeting and look normal. :) Options are good....one man's treasure is another man's trash... :-) > The key question is: if we want to actually report the change in equity > between the previous balance sheet and the current balance sheet we need to > know when the last balance sheet was run. *THAT* is the "start date" in the > current report. Or to put it another way... The key question is: if we want to actually report the change in equity between the previous balance sheet and the current balance sheet we need to know when the fiscal year begins. *THAT* is the "start date" in the current report. >Despite having a cool user name, linuxcpa does not know how to bridge >the gap between the accounting and software. I know over two dozen >computer languages and am an accounting student. I can tell you that >the balance sheet *should not* reflect net income _and I am telling you >how to fix it_. Gee thanks Shinichi.... LOL :-)
Ok, discuss, discuss... PROPOSE! I propose the following: (1) The balance sheet report be left named "Balance Sheet". (2) It have an Account Form/Report Form option. (3) It takes only one date: a statement date. (4) It has an option for the company name, and defaults to the name in the book properties. (5) A separate Equity Statement be created (if not already present). This, of course, would have two dates: start and end, which default to (today - 1 year) and today, respectively. (6) A Cashflow report be created. This, too, would have a start and end date, as in (5). (7) A Grand Unified Standard Report(TM) be created which lets you plop 1, 2, 3, or all 4 of these standard reports down on the same sheet. Would this make everyone happy?
(1) ok. (2) ok (3) ok (4) I suspect this is challenging to do, I don't know if you have access to the current book when the default report options are created. I still maintain that it should use the value from the book data (File -> Properties) and not provide an entry in the report options. (5) yes, this needs to be created. Dates should default the same way that all the other reports default. (6) we already have a cash flow report. (7) this sounds like a multicolumn report -- Or I suppose it could be one report that pulls in from everything. Certainly sounds good to me.
Ok. Following the (misleading) advice on this system and the GnuCash homepage, I took the time to learn CVS in order to contribute to this project. I spent hour upon hour writing and refining Scheme code.... too many hours to even try to count. I'm just about to submit my changes... And find out that, to submit a patch, I can't use CVS. What!!? How am I supposed to contribute my code? The GnuCash homepage (and certain other developers, here, to remain nameless :) makes it sound like a simple deal. Instead of doing a CVS commit or diff, they ask you to mail a patch to a mailing list. But, before you can do that, they make you download, build, and install some hokey utility (makepatch) to do it. As if patch wasn't enough to make a patch...???? But because all that's doable, they needed to add another complication to the mix: makepatch requires two copies of your source tree. Baahh! Isn't that one reasons why people began using version control system? Well, now that I know how to CVS checkout, I can get another copy. It's a pain in the a#$ of an inconvenience... but if it works, it'll be worth the (EXTRA, unnecessary) effort. So I checked out another gnucash and ran the dinky makepatch... and find that somebody else has modified the CVS while I was working on it. I thought CVS was supposed to account for this, too? If we have to fish out other peoples' changes... let's just go back to using patch. What's the point to using CVS, if you're not going to *use* it? Just on the off chance that I'm missing something really obvious... could anyone enlighten me as to how <SYNONYM>on this green Earth</SYNONYM> to push files in the reverse (upstream) direction? Yours Truly, Disgruntled (otherwise wouldbe happy to contribute to GnuCash) coder
Uhh, "cvs diff -u" is just fine to submit a patch... The only time it doesn't work is when you want to add files to the repository, at which time you kind of need something to help you with that. That's what make-gnucash-patch is supposed to help with. But honestly, 90% of the time you don't need it. Where are the references to make-gnucash-patch? I'll go fix them to make it more clear about this. :)
Ok, documentation bug. :) GnuCash homepage -> How To Help (under General Information) Select "I am a programmer". Click "source code" for the CVS page. This page tells you how to use cvs commands to access GnuCash CVS. **It should also tell how to use the "cvs diff -u" *AND* make-gnucash-patch commands.** (Otherwise, users will be left with changes and not know how to contribute them!) As I want to add files to CVS, it sounds like I'll have to use make-gnucash-patch. I'll look into that. <crossing fingers...>
> This page tells you how to use cvs commands to access GnuCash CVS. > **It should also tell how to use the "cvs diff -u" *AND* make-gnucash-patch > commands.** (Otherwise, users will be left with changes and not know how > to contribute them!) The page you describe clearly says: "Note, however, that if you wish to contribute patches and updates to GnuCash, it is strongly recommended that you learn and use CVS". I do not believe it's our job to explain how to do that. You do realize that "man cvs" works just fine.... Also, make-gnucash-patch is all described in the README.patches file in the sources. I'll update that file to make it more clear that "cvs diff -u" is ok for changes to existing files.
> You do realize that "man cvs" works just fine.... "man cvs" is actually misleading. It tells you to use "cvs commit" to commit changes and "cvs add" to add files to your local copy of the repository. But the gnucash cvs is read-only. Hrumph. My point: If documentation is going to describe how to do something, it should describe *completely* how to do it. Giving some one instructions Besides, make-gnucash-patch doesn't seem to work, either. It's still reversing recent changes made in CVS. How am I supposed to The contribution documentation is *woefully* inadequate. I am *certain* of this. :)
> "man cvs" is actually misleading. It tells you to use "cvs commit" > to commit changes and "cvs add" to add files to your local copy of > the repository. But the gnucash cvs is read-only. Hrumph. No it's not, you're just looking for the wrong thing. "man cvs" is quite clear on how to obtain diffs between your code and the cvs repository. > It's still reversing recent changes made in CVS. "cvs update" in both trees. > The contribution documentation is *woefully* inadequate. > I am *certain* of this. :) You're the first person out of dozens of contributors to think this. I've already updated README.patches for you.
> You do realize that "man cvs" works just fine.... "man cvs" is actually misleading. It tells you to use "cvs commit" to commit changes and "cvs add" to add files to your local copy of the repository. But the gnucash cvs is read-only. Hrumph. My point: If documentation is going to describe how to do something, it should describe *completely* how to do it. Giving some one instructions how to load a gun but not how to use it can get people into a lot of trouble. (like not being able to commit CVS changes...) The GnuCash "I wanna program GnuCash" page should be updated to reflect current, complete, and accurate information on contributing to GnuCash. That's why it's there. :) Besides, make-gnucash-patch doesn't seem to work, either. It's still reversing recent changes made in CVS. How am I supposed to get a diff/makepatch/make-gnucash-patch/ insert-favorite-tool-here of my copy against the CVS I checked-out? (checkout gnucash on 2004.06.17) I read the cvs man page, but it doesn't say what format it uses for date options. Furthermore, the option to check out sources as-of a certain date doesn't seem to be in the "cvs -H checkout" documentation. So I don't even know what switch I would use if I knew the date format. The contribution documentation is *woefully* inadequate. I am *certain* of this. :)
*sigh* No, Phil, it's not appropriate for the GnuCash documentation to teach you how to use CVS; there'd just be too many copies of that if every project had to reiterate it. Also, I'd argue that bugzilla comments are an inadequate way of requesting that advice. [`cvs -H checkout` does list -D as the correct option for retreiving the files as of a certain date.] `make-gnucash-patch` might be broken, I'm not sure. `cvs update` will update any changes made to the tree since you've checked it out, incorporating those changes with yours [as per the CVS manpage] If you have checked out and modified the sources then executing `cvs diff -u` will do what you want, as per the man page: [[[ diff [-kl] [rcsdiff_options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...] Requires: working directory, repository. Changes: nothing. You can compare your working files with revisions in the source repository, with the `cvs diff' command. If you don't specify a particular revision, your files are compared with the revisions they were based on. You can also [...] ]]]
To make this easy: why don't you just attach "cvs diff -u" and then attach the new file?
Created attachment 28986 [details] [review] Patch to update Balance Sheet report, add Equity Report, and add misellaneous html utilities and functions. This patch adds: html-acct-table.scm, equity-statement.scm. Modifies: balance-sheet.scm, several files under report-system/, and make-gnucash-patch.in.
ok, this damned bugzilla just deleted all my comments.... I don't really care to know how to use CVS--just how to get my changes into *GnuCash's* repository (which only uses CVS for distribution). *my* version of cvs will not permit you to add files using diff, does *not* specify what the date options mean, and does not describe what a "revision" is. Neither does it specify what format "Month DD, YYYY"/YYYYMMDD/etc. dates take. As it turns out, "info cvs" provides much better documentation. My point is that, if the GnuCash docs are going to tell people how to use CVS, they should do it *completely* or *not at all*. If you don't want to "teach" people how to use CVS, then just say "get the source from our anonymous CVS server at.... the password is guest, we use these tags..., the repository is read-only, and use gnucash-make-patch to submit patches to gnucash-patches@gnucash.org." and omit the command-line tutorials. (Just like it omits instructions on sending e-mail to the patch list.) At the very least, IMHO, every project which uses CVS should contain reference to "info cvs". In the case of GnuCash, I beleive it should also post caveats that "cvs commit/add/diff" will not work on their repository.
I just looked at the patch. WOW, nice job! I've got a few comments and concerns (all minor!!!!): 1) makepatch should have been built to your perl specification, so it should have found your perl. You shouldn't have had to do anything to get it to run -- most likely a makefile problem, so I'll fix it. 2) You have this patch, which isn't really necessary: - '())) + (list))) these are equivalent constructs. 3) Note that changing the option names in a report causes a non-backwards-compatible (and non-forwards compatible) change, so saved (or open) reports wont work across the change. This is also true about changing option pages. Granted, this is in HEAD, not 1.8, so it's not a HUGH deal (especially since saved reports wont be recovered across the 1.8 -> 2.0 upgrade), but just something to keep in mind if you decide to back-port to 1.8. It's also an issue if people try to pop back-and-forth between HEAD and 1.8, but I think I'll make a small change to fix that when I commit this code. 4) you ask: I'm not sure if I got (_ ) vs (N_ ) right. (What are they?) These are translation functions. N_ marks a string s.t. it will get put into the translation database and translated later (it's an immediate no-op), whereas (_ ) both adds the string to the trans-db AND returns the translated string. But overall, Nice job! :)
Oh, you also left out the Makefile changes to get your new files installed...
Commited to CVS (HEAD, not 1.8) I'll mark this as fixed and close the bug. Thanks.
*** Bug 154419 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=144243. Please update any external references or bookmarks.