Created attachment 373528 [details] Sample file The Customer Report (beta) period totals line includes debits and credits from the prior period, presumably because they roll into the opening balance. Calendar 2019 report: https://i.imgur.com/fpygmoc.png Credits of $100 and debits of $300 for a closing 2019 balance of $(200.00) credit. Calendar 2020 report: https://i.imgur.com/jfSKQnv.png There's no activity in the current year, and yet the period totals still reflect $100 and $300 that make up the opening balance, instead of $0. ==== Also, aren't the column headers reversed? The $100 is a debit entry (left side) for an increase in accounts receivable, and the $300 is a credit entry for a decrease in accounts receivable. The "total credit" line label of $(200.00) is correct, since I owe my customer $200 (credit balance AR).
Yes agreed. I was mostly concerned in ensuring the Balance b/f did carry over from the old APAR entries and never cared to check Debit/Credit totals. Will see how to fix tonight. Also yes agreed.... I'm carried the labels from old reports. Please confirm with me whether Dr/Cr labels have to be switched for all Customer Vendor Employee report, or only Customer Report?
> Please confirm with me whether Dr/Cr labels have to be switched for all Customer Vendor Employee report, or only Customer Report? Customer report ties to Accounts Receivable, which is a debit (left hand side) account, therefore any increases to the AR (e.g. new sales invoice issued to the customer) is a debit entry. Collections from customers is a credit (reduces the amounts still to be collected from the customer). Vendor report ties to Accounts Payable, which is a credit (right hand side) account, therefore any increases to the AP (e.g. new bill owing received from a vendor) is a credit entry. Payments to vendors is a debit (reduces AP balance). I've never used the Employee report. Making a quick example, it looks like a report used to pay employee expense claims? If so then it should be treated like AP, meaning new expense reports filed by an employee increases the amount owing, which is a credit balance. Payments to employees is a debit (reduces amounts outstanding to be paid to the employee).
Created attachment 373529 [details] fixes. don't accumulate dr/cr totals unless printed, show AP amounts in correct cr/dr column should work.
of course, the silly bug is the headers should be "Debits" "Credits" but at least the L/R placement should be fixed with patch. Fixing the headers will mean renaming a whole lot of variables carried over from old owner reports.
The last comment I can offer prior to completing the merge is whether we should adopt strong accounting practices at all here. It would be way easier for a newbie to see the headers "Increase"/"Decrease" relating to invoicing vs paying, with invoicing for customers and vendors both on the left and paying on the right. What do others think?
Follow whatever the user has set as global preference for "Use Formal Accounting labels". If set to false you can probably use more informal labels. However the "Increase/Decrease" headers probably beg the question: what is being increased/decreased ?
(In reply to Geert Janssens from comment #6) > Follow whatever the user has set as global preference for "Use Formal > Accounting labels". If set to false you can probably use more informal > labels. However the "Increase/Decrease" headers probably beg the question: > what is being increased/decreased ? The 'debt'. Either from the customer pov in Customer Reports, or mine in the Vendor report. My proposal ensures the format is easier for noobs to grasp. Date Type Increase Decrease Balance .... Invoice/Bill $200 $200 .... Invoice/Bill $40 $240 .... Payment $200 $40 =-=-=-=-=-=-=-=-=-=-=-= CDB-Man's rigorous accounting will mean ensuring that all Dr/Cr=left/right? Date Type Debit Credit Balance .... Invoice $200 $200 .... Invoice $40 $240 .... Payment $200 $40 and Date Type Debit Credit Balance .... Bill $80 $80 .... Bill $30 $110 .... Payment $100 $10 =-=-=-=-=-=-=-=-=-=-=-=- The second one is more correct, but less readable (IMHO). I can certainly follow global preference if you like.
Considering this further, I'd be *very* keen to remove the individual Display options for Debit & Credit -- it makes no sense to show only 1 column. If we really need option to toggle visiblility, we'd replace with Display/Amount. (Note the Display/Balance option currently shows Amount rather than Balance in tooltip and I'll fix this when we reach agreement on above). So, questions: 1) do we want to enforce Dr/Cr where customer invoices are Dr (left) and vendor bills are Cr (right), or do we simplify to Increase/Decrease debt as I described in #c7? 2) do we want an option to show/hide the Dr/Cr amount? 3) filtering options -- 'invoices unpaid', 'invoices paid', 'payments only', 'unattached payments' ???
1. I agree with Geert that it should follow the user's Formal accounting labels preference. New invoices are debits (left), and new vendor bills are credits (right). Just like how you find DR/CR confusing for the non-finance person, having increase/decrease would be confusing for someone that is finance/accounting literate. 2. Not sure what you mean by "show/hide". 2a. Displaying only debits vs only credits does have a use. If for example I wanted to copy the data to Excel, I may want to analyze only DR or CR activity, such as doing some manual analysis on aging, or putting into Excel form a customer's list of outstanding invoices. I don't think we need to over-engineer simplicity by collapsing the debit and credit display checkboxes into a single checkbox. 3. Filtering options would be pretty cool. > CDB-Man's rigorous accounting will mean ensuring that all Dr/Cr=left/right? > > Date Type Debit Credit Balance > .... Invoice $200 $200 > .... Invoice $40 $240 > .... Payment $200 $40 > > and > > Date Type Debit Credit Balance > .... Bill $80 $80 > .... Bill $30 $110 > .... Payment $100 $10 ======== This is correct, yes.
Created attachment 373531 [details] fix Dr/Cr headers & totals No filtering done yet. Please throw ideas here :)
Ok pushed changes, should be satisfactory. Global prefs will effect dr/cr headers.
Pls review changes +/- close bug. Or if filtering is desirable please file new bug.
(In reply to CDB-Man from comment #9) > 2. Not sure what you mean by "show/hide". > 2a. Displaying only debits vs only credits does have a use. If for example > I wanted to copy the data to Excel, I may want to analyze only DR or CR > activity, such as doing some manual analysis on aging, or putting into Excel > form a customer's list of outstanding invoices. I don't think we need to > over-engineer simplicity by collapsing the debit and credit display > checkboxes into a single checkbox. > IMO you could equally argue that having separate buttons for debit and credit is over-engineering for flexibility. For your particular use case, if you want to copy to Excel for further processing, it's a trivial operation in Excel to remove the unwanted other column there. I actually don't see the need to do so inside gnucash already.
The subtotals for debit and credit now accurately only reflect current year transactions. The labels of debit credit are correct for customer and vendor reports. @Geert: well, given that by default we have flags for each column, I don't see why we treat debit/credit differently, and combine these to a single flag instead of per-column flags. You're right that doing it within GNUcash is probably excessive; I only provided that as a hypothetical.
This was tested using maint build: > gnucash-3.8-2020-01-25-git-3.8b-89-ga9d51dd9e+.setup.exe
