Created attachment 373945 [details]
customer report

*** Bug 798059 has been marked as a duplicate of this bug. ***

Bug 797977 was closed because the reporter was asking that GnuCash report links that hadn't been made in the database.

Please attach the same report run from the older version of GnuCash that you think was correct. Since you're on a Mac you can easily have as many versions of GnuCash.app as you like as long as you rename them or keep them in separate folders.

Hello John
thanks for getting back, please find attached the same customer report from 3.11 (since last time, we included an additional invoice, so please ignore the last entry on the list)

Created attachment 373946 [details]
Customer Report 3.11

Can you click on the 40.80 eur cell, open the AR register, and expand the transaction to all splits, and paste screenshot?

ok, I am attaching A/R account specific entry for 4.2, also checked same entry in 3.11 and it is identical as well as A/P entries when invoice was produced (Invoice number 539) as all the same for 4.2 and 3.11.

Created attachment 373948 [details]
A/R 40.80 4.11

Created attachment 373949 [details]
A/P 40.80 4.11

this is actually where it takes me when I click on the 40.80 link, in A/P not in A/R

So there are two transactions on 29/07/16 the first one with invoices and the second one with payments? How did these transactions get created? What's the meaning of these transactions?

one transaction on 29/07 which is payment, the other one on 20/07 is an invoice. Invoice for created from invoicing and payment was created after opening invoice and apply payment to it

also by doing this check on both the A/R (ΕΙΣΠΡΑΚΤΕΟΙ ΛΟΓΑΡΙΑΣΜΟΙ) and the A/P (ΦΠΑ) entries, they are identical in both 3.11 and 4. 
So, if I am not really missing something, it seems that this is a bug when creating the individual customer reports. 
Once again, when I perform total customer report (customer summary), the balances are correct, but only when I do individual customer report, it seems that the report is missing links to specific entries between customers and some invoices assigned to them and provides this awkward outcome with partial payments (which are not really payments but part of the missing linked invoice) assigned to my A/P account (ΦΠΑ) but no entry to my A/R account (ΕΙΣΠΡΑΚΤΕΟΙ ΛΟΓΑΡΙΑΣΜΟΙ) on the customer report (the invoice is missing altogether in the A/R account). 
The invoice 539 for example has a total of 210,80 euro assigned to my A/R account properly, 170 of which is assigned to my income account for selling the product and 40.80 Euro of which is the 24% VAT assigned to the A/P ΦΠΑ account but it is assigned as a payment and not as part of the invoice. 
The invoice altogether seems not to be linked to the specific customer when I use the Customer Report, so 
a. an entry of 40.80 Euro seems as a payment to my A/P ΦΠΑ account and 
b. when we processed the payment on 29/07/2016 as of 210,80 Euro, it shows up as a payment in the second ACCOUNT:ΕΙΣΠΡΑΚΤΕΟΙ ΛΟΓΑΡΙΑΣΜΟΙ.
Hope it is clear now, let me know

You may have found an edge case that the customer report cannot handle.

Would you mind creating a new book in English with the exact same transactions for 29/07/2016 and attaching here?

One aspect of this problem is that you have used the account type A/P (Accounts Payable) for your VAT account. However A/P account type is reserved specifically for posting bills and their payments. The VAT account should have been of type Liability.
It's unfortunate GnuCash has no means to protect against this, though to be honest I'm not sure  it could.

Next the new Customer report does interpret account types differently from the old one. On the positive side this means the report is now able to display all AR accounts for a customer (for example when you have invoices in different currencies). Unfortunately that now is more sensitive to improper account type usage.

I'm not sure what the best solution is. I would suggest to fix the account type. However there was a recent change that prevents accounts with existing splits to change types (to prevent data loss). I don't recall whether that was done in 3.x or 4.x.

@chris I have not looked at the internals of the new report here. But I do wonder why the A/P entries are split out. In principle the report should list only accounts that are used as posted-to accounts for this customer, or in other words accounts that have lots for this customer in them. It looks like currently it lists all business accounts with splits related to this customer in them.
In this particular case, I wouldn't expect lots in the ΦΠΑ account (the A/P one) for this particular customer. It is not the posted-to account for this invoice.

i will try to do both but, to be completely honest, i do not
believe any of these are the problem, like i said the specific invoice for example is not showing up in the customer report at all in any account, so seems that the update lost the link between the customer and the invoice when performing the customer report function. this is just an example but it is similar with other customers and invoices. also my vat account is an a/p account as vat is not paid upfront, at least in the greek taxation system, we file a report to tax office at end of every month and based on balances then we pay vat, so the payment is not performed up front, so to my understanding it is an account to be paid after tax report filling. also not sure cause i do not have that in front of me, but the vat a/p account belongs to a liability account holder that also has other a/p accounts as to providers, loans, etc etc (will verify when i get back to my computer)

There is some confusion here. For an accountant an "Account Payable" is an account holding amounts that still have to be paid. This is a specific form of liability. For technical and historical reasons gnucash uses that same term to refer to account types to be used solely as post-to accounts for bills and vendor payments. Any other accounting use of "Account Payable" should be set up as a Liability account or you will confuse gnucash. Your situation is only one illustration of that. You are free to name your account "VAT/Account Payable" or anything you like, but the type should be "Liability" as gnucash currently works.

As for the "missing" invoice: it does show up, but is interpreted completely backwards by the current implementation. The report shows only the VAT entry of your invoice in the ΦΠΑ account. That's the bug. It should not list it there at all because the invoice was not posted to that account. It just happens to be another business type account that the report code came across first. Once an invoice is processed (even poorly like here) it will be ignored during the processing of subsequent accounts, which is why it won't show in your A/R account further down.

(In reply to Geert Janssens from comment #14)
> 
> @chris I have not looked at the internals of the new report here. But I do
> wonder why the A/P entries are split out. In principle the report should
> list only accounts that are used as posted-to accounts for this customer, or
> in other words accounts that have lots for this customer in them. It looks
> like currently it lists all business accounts with splits related to this
> customer in them.
> In this particular case, I wouldn't expect lots in the ΦΠΑ account (the A/P
> one) for this particular customer. It is not the posted-to account for this
> invoice.

Incredibly insightful analysis here. I'll see how to modify the split searching strategy to find these lots. You're right the current strategy finds all apar account splits whose owner matches the option

btw it'll be very useful to have a sample datafile modelling your unusual (i.e. atypical of most gnucash business users) model.

I cannot test without an appropriate datafile. Try this patch

modified   gnucash/report/reports/standard/new-owner-report.scm
@@ -764,6 +764,9 @@
        'attribute (list "cellpadding" 4))
       table)
 
+     ((null? (xaccSplitGetLot (car splits)))
+      (lp printed? odd-row? (cdr splits) invalid-splits total debit credit tax sale))
+
      ;; not an invoice/payment. skip transaction.
      ((not (or (txn-is-invoice? (xaccSplitGetParent (car splits)))
                (txn-is-payment? (xaccSplitGetParent (car splits)))))

hello again, just to clarify, do you need me to upload the entire file with my account structure? A lot of private info on that so not sure whether I could do it. 

I could create a simplified version of it and upload if you think that this is sufficient, otherwise let me know. I am setting up a simplified version in English anyhow to test what you recommended with only this one customer and this one transaction. More on this soon.

With respect to the comment on proper accounting, you are correct, I am not an accountant, we have a very small business and we are doing this internally just to keep track of payments customers etc etc, still to me it does make sense that VAT should be an Account Payable as you do not pay this upfront, even though you are correct that it is a liability based on proper accounting. 
The overall structure is, I believe, quite straight forward, I have 5 account holders, one for Assets, one for Expenses, one for Income, one for Equity and one for Liabilities. 
Assets has banks, cash, and A/R.
Expenses has general account expenses and product expenses
Income has income based on products sold accounts
Equity has two accounts as equity from initial contribution of the 2 major business persons and
Liability has two additional holders, one for long term liabilities and one for short term liabilities (as LIABILITY accounts) and within them there are the A/P as I described before (either VAT or A/P to providers etc etc)

With respect to the patch, how do I run this exactly a Mac (terminal?) ? could you please explain?

@aris this patch is not sufficient. to ease testing i'll supply the whole amended new-owner-report.scm -- you'll need to dig deep into GnuCash.app. a simplified datafile in English would be perfect.

I figured it out in contents/Resources/share/guile/site/2.2/gnucash/reports/standard/ (could not find report/reports/, found the file, amended the recommendation but now Gnucash is not opening, after changing back app opens just fine

Created attachment 373951 [details]
patch report

tried again, now app opened and report zeroed everything on the VAT account, see attached

Created attachment 373952 [details]
gnucash sample file

this is the sample file, same problem when I run it on 3.11 I get a proper customer report, when I run on 4.2 again invoices are somehow misplaced/miscalculated etc. Also, I just noticed that on 3.11 when running customer report, you have to define the account, which is not the same in 4.2

Created attachment 373953 [details]
customer report on sample file 3.11

Created attachment 373954 [details]
customer report sample 4.2

Created attachment 373955 [details]
sample data file

uploading data file again, hopefully in correct process this time as uncompressed and in application/xml list form, apologies for mistake, hopefully this is correct

(In reply to Aris from comment #20)
> With respect to the comment on proper accounting, you are correct, I am not
> an accountant, we have a very small business and we are doing this
> internally just to keep track of payments customers etc etc, still to me it
> does make sense that VAT should be an Account Payable as you do not pay this
> upfront, even though you are correct that it is a liability based on proper
> accounting. 

<snip>

I never meant to suggest your understanding of accounting is wrong. I am trying to clarify GnuCash reserves accounts of *type* "Accounts Payable" or "Accounts Receivable" solely for use as post-to accounts for invoices/bills and their payments. If you use it for anything else, that will invalidate gnucash' assumptions and you will see odd behaviour. You could argue that is a bug, but you could also argue it's a design decision made a long time ago when this was not an issue. The chance this design decision will be revisited is pretty low. It's a big effort for little gain.

So if you want to use gnucash, it's safer to use it as it was intended, regardless whether that exactly matches your understanding of accounting. I repeat that your oddity is not the only one you risk running into.

And again: if you do prefer to have an account named "Accounts Payable" for your VAT, simply create one with that *name*, but make it of type *Liability" to avoid potential violations against the gnucash internal assumption. Just don't use the *type* "Accounts Payable" unless for accounts you will post invoices/bills to. I do the same here in Belgium and that works just fine.

A short update, I did exactly the same entries and included a new account as liability instead of A/P for VAT account, and now the customer report output is as it should be (it does not however indicate the account name from where it is actually retrieving the information). 
I also completely understand the design decision, still I am reading through your own comment#14 which states that the customer report should be generated from the account invoices are being posted to ie the A/R account and not the other accounts, so not sure if this is entirely related just to the design decision then.
 
The question now is whether I can somehow upgrade to 4.2 with the improper handling of the account for that VAT? I have already setup a new account for VAT as liability to record VAT from now on but not sure how to handle the past open invoices or customer reports, and we do have to send customer reports from time to time to our customers.
Any easy fix/patch or something I could do to change this momentarily and till I guess all other open invoices are paid for or till I transfer new invoices to the new VAT account?

And even though I have not said it thus far, I appreciate all your input and help in this

(In reply to Aris from comment #29)
> A short update, I did exactly the same entries and included a new account as
> liability instead of A/P for VAT account, and now the customer report output
> is as it should be (it does not however indicate the account name from where
> it is actually retrieving the information). 

Thanks for confirming that.

> I also completely understand the design decision, still I am reading through
> your own comment#14 which states that the customer report should be
> generated from the account invoices are being posted to ie the A/R account
> and not the other accounts, so not sure if this is entirely related just to
> the design decision then.
> 
As the report works correctly if you stay within the restrictions imposed by that design decision, I'm inclined to say that yes, this is entirely related to the design decision.

That's not to say this is your own fault however! It's a usability bug that users can end up in this situation. Ideally GnuCash should  prevent users from using these accounts for anything other than posting invoices and payments to. GnuCash doesn't unfortunately and to be honest I have unwittingly exploited this "feature" in a distant past. I got away with it back then, where you on the other hand ran into issues.

Note my comment 14 was the result of thinking this through *after* reading your bug. I now think we should be able to change the customer report such that it's no longer vulnerable to going outside of the original design decision restrictions. And I'm sure chris is working on that as we speak.
I have no idea if we will be able to do the same for the rest of the code.

Back to your more pressing question: what to do with the current invoices. Unfortunately there are not that many options: you could unpost each invoice, change the VAT account and repost the invoice. The unfortunate side effect of unposting is that linked payments are not remembered so after reposting you also have to reapply the payment. On a linux system you could try to script this in python. That is however not supported on MacOS.

I still feel the report code is ok, and the vat apar accounts changed to asset/liability is the best approach. Modifying the report code may induce side effects elsewhere.

Would deleting the apar vat accounts and sending all vat splits to an asset/liability account be acceptable gjanssens?

(In reply to Christopher Lam from comment #31)
> I still feel the report code is ok, and the vat apar accounts changed to
> asset/liability is the best approach. Modifying the report code may induce
> side effects elsewhere.
> 
> Would deleting the apar vat accounts and sending all vat splits to an
> asset/liability account be acceptable gjanssens?

Unfortunately that's not an option. Invoice transactions are read-only, and will prevent deletion of the account. The only way to achieve this is to manually change each invoice.

ok. so seems there is no other way and both options are not really an option for me, we are talking about thousands of invoices and payments, we have been using the software since 2011 or so, so probably i will stick to using the previous version and when i find time restructure everything on new version with open balances for customers etc etc (i was thinking whether this would “wash away” somehow with the additional VAT liability account i have created but do no think this will be the case)

on another note and fully respecting the long term decision making and years of thinking, some food for thought

a. i am not sure how it serves for customer report to go looking into a/p accounts. customers are supposed to pay and not get paid so it would make sense to me that customer report goes searching only for invoices posted on a/r accounts and only the total of the invoices irrespective of splits, as you mention, and as a matter of fact not even be concerned about any splits on the invoices in general (probably this is the result of some long term decision but i have not encountered the need for such a thing in the years i have used the program)


b. it seems that customer summary on the other hand is not following the same process or decision as it reports the sums properly by probably searching on the a/r accounts and the total of the invoices

c. in continuation to b, also the total open balances at the bottom of each reported account on the customer report seems to report open balances properly and not in agreement with the sum of the individual entries on the customer report

again just food for thought, if something else comes in mind please let me know and enjoy new year’s eve

(In reply to Aris from comment #33)
> ok. so seems there is no other way and both options are not really an option
> for me, we are talking about thousands of invoices and payments, we have
> been using the software since 2011 or so, so probably i will stick to using
> the previous version and when i find time restructure everything on new
> version with open balances for customers etc etc (i was thinking whether
> this would “wash away” somehow with the additional VAT liability account i
> have created but do no think this will be the case)

I was afraid you would already have a longer history. There is one other option that requires manipulating your data file directly. The only thing to change is the account type of your ΦΠΑ account from "Accounts Receivable" to "Liability". I have thought this through some more and I can't see any reason this would cause an issue. Obviously this should be tried on a copy of your data first to double check and to have a safe fallback in case of errors or mistakes.

> 
> on another note and fully respecting the long term decision making and years
> of thinking, some food for thought
> 
> a. i am not sure how it serves for customer report to go looking into a/p
> accounts.

A fair point and I was pondering this myself as well earlier today. Just restricting the search to AR accounts for customers and AP accounts for vendors should solve your particular issue as well. It does not prevent issues in case of improper use of additional A/R accounts though, which is a variation of what you ran into. So a wider solution would be best.

(In reply to Christopher Lam from comment #31)
> I still feel the report code is ok, and the vat apar accounts changed to
> asset/liability is the best approach. Modifying the report code may induce
> side effects elsewhere.

What kind of side effects are you thinking of ?

As I understand business lots are how relations between invoices and payments are defined in gnucash. And as a customer report is all about these relations it only makes sense to me to start from there. It's the most accurate info you can have.

@Aris here's a stopgap to prevent searching in AP for customer -- this is not entirely satisfactory because it'll also find cases whereby customer splits are incorrectly in another AR account:

modified   gnucash/report/reports/standard/new-owner-report.scm
@@ -1032,7 +1032,13 @@ invoices and amounts.")))))
     (gnc:option-value
      (gnc:lookup-option options section name)))
 
-  (let* ((accounts (filter (compose xaccAccountIsAPARType xaccAccountGetType)
+  (let* ((owner-descr (owner-string type))
+         (owner (opt-val owner-page owner-descr))
+         (acct-type (if (eqv? (gncOwnerGetType (gncOwnerGetEndOwner owner))
+                              GNC-OWNER-CUSTOMER)
+                        ACCT-TYPE-RECEIVABLE ACCT-TYPE-PAYABLE))
+         (accounts (filter (lambda (acc)
+                             (eqv? (xaccAccountGetType acc) acct-type))
                            (gnc-account-get-descendants-sorted
                             (gnc-get-current-root-account))))
          (start-date (gnc:time64-start-day-time
@@ -1047,21 +1053,14 @@ invoices and amounts.")))))
          (link-option
           (gnc:option-value
            (gnc:lookup-option options "Display Columns" linked-txns-header)))
-         (owner-descr (owner-string type))
          (date-type (opt-val gnc:pagename-general optname-date-driver))
-         (owner (opt-val owner-page owner-descr))
          (payable? (memv (gncOwnerGetType (gncOwnerGetEndOwner owner))
                          (list GNC-OWNER-VENDOR GNC-OWNER-EMPLOYEE)))
          (query (qof-query-create-for-splits))
          (document (gnc:make-html-document))
          (table (gnc:make-html-table))
          (section-headings (make-section-heading-list used-columns owner-descr))
-         (headings (make-heading-list
-                    used-columns link-option
-                    (if (eqv? (gncOwnerGetType (gncOwnerGetEndOwner owner))
-                              GNC-OWNER-CUSTOMER)
-                        ACCT-TYPE-RECEIVABLE
-                        ACCT-TYPE-PAYABLE)))
+         (headings (make-heading-list used-columns link-option acct-type))
          (report-title (string-append (G_ owner-descr) " " (G_ "Report"))))
 
Modification of XML file should be straightforward:

From
<act:name>1_VAT_Accounts Payable</act:name>
<act:id type="guid">701b73f6cfc441fab9d89a840525ec18</act:id>
<act:type>PAYABLE</act:type>

To
<act:name>1_VAT_Accounts Payable</act:name>
<act:id type="guid">701b73f6cfc441fab9d89a840525ec18</act:id>
<act:type>LIABILITY</act:type>

@gjanssens - will need to think some more; the current strategy to find splits from unique transactions in all APAR accounts was working well so far. A different strategy to find all splits with lots from APAR accounts seems more exact.

(In reply to Aris from comment #33)
> 
> on another note and fully respecting the long term decision making and years
> of thinking, some food for thought
> 
> a. i am not sure how it serves for customer report to go looking into a/p
> accounts. 

Because usually there's only one ap and one ar account and it didn't make sense to request it as an option. Moreover if the user has >1 AR account then selecting it is a chore.

Question: if you record the VAT splits in an APAR account, do you also use business features (invoices & bills) to fulfill your VAT obligations? I hope not... You should then be able to modify the datafile manually as described above.

Created attachment 373956 [details]
try this patch

Addendum the last comment is a good candidate for this fix because it'll still scan all apar accounts but will no longer skip splits in the 2nd APAR account. Please verify and deeper back asap.

Created attachment 373959 [details]
new customer report

good morning and happy new year. attached the new report, seems to be working properly now for the A/R account but stills shows also the A/P (ΦΠΑ) on top.

and just to be on the same page, I only applied the latest patch from 373956 (comment 38)

also, if I understand this correctly, I need to apply the XML change by itself to change the A/P account to a LIABILITY correct? (comment 36 had quite a few suggestions and not sure if I need both to modify the new-owner-report.scm file and the XML file modification to change the account to a LIABILITY account)

(In reply to Aris from comment #41)
> and just to be on the same page, I only applied the latest patch from 373956
> (comment 38)
> 
> also, if I understand this correctly, I need to apply the XML change by
> itself to change the A/P account to a LIABILITY correct? (comment 36 had
> quite a few suggestions and not sure if I need both to modify the
> new-owner-report.scm file and the XML file modification to change the
> account to a LIABILITY account)

Correct: The modification to new-owner-report will *slightly* improve handling of your particular (unexpected) account structure; this does not aim to handle your use case.

In simple terms, if splits from different APAR accounts were attached to the the same transaction, it will show all of them in the respective account sections.

You'd need to modify the XML directly to change the VAT account type, in addition to the new-owner-report changes. Don't forget to backup. Remember the VAT-on-sales account is usually handled as straightforward liability; you wouldn't have used A/Payable business features onto the VAT splits. 

With that, the report will be amended as above.

fixed for 4.5

IMHO -- Customer Report should never look at AP, and Vendor report should never look at AR.

(In reply to Derek Atkins from comment #44)
> IMHO -- Customer Report should never look at AP, and Vendor report should
> never look at AR.

What account searching rules would you suggest for employee or job reports? This gets hairy quickly.

(In reply to Christopher Lam from comment #45)
> (In reply to Derek Atkins from comment #44)
> > IMHO -- Customer Report should never look at AP, and Vendor report should
> > never look at AR.
> 
> What account searching rules would you suggest for employee or job reports?
> This gets hairy quickly.

Not hairy at all.  Each type looks at exactly one type.  Never would you look in both AR and AP.

Employee:  AP
Job:  Based on the underlying owner type

Created attachment 373963 [details]
Final Customer Report

Hello all, just for the record, I am attaching final report after making all modifications as suggested which now looks all proper and also made the xml changes and seems to have been able to switch the account to liability, so I will now be monitoring a bit that there are no side effects (so far all looks great).

Thanks for all the help, much appreciated, only note is that in some entries on the customer report (as the payment on 16/02/2018) seem a bit odd in terms of spacing in between this specific entry and the next one on the report.

I run the customer report again with links on and realised that the spacing relates to the number of invoices linked to the specific payment, most probably one line per invoice is added to the payment, for example payment on 16/02/2018 was applied to 4 invoices so 4 lines have been added to this entry

Well just run the report again but chose a different starting date (ie from date) instead of start of accounting period, and received a wrong output after all. Attaching an example shortly on this, but obviously something went wrong, could you please check again if there is something else missing in the modification of the scm file?

Created attachment 373964 [details]
CustomerReport New From Date

opening balance as of 01/12/2020 (-1083,76) is wrong and obviously Period Totals and Total Credit balance is wrong (should be 502,20 as stated on the bottom)

Don't forget to attach a sample data file that illustrates bug in English.

Created attachment 373965 [details]
Customer Report 311 New From Date

I have and it is the exact same customer I have been using so far, when I change the From Date field it seems that the customer report is now miscalculating the opening balance. Please see attached the exact same report from same customer and 3.11

hello again, I am working on the sample simplified xml I sent you in English and need a couple of things cause it seems that I cannot revert back with a clean initial scm file that comes with 4.2 ( I somehow messed up the files). 
I downloaded latest version 4.4, are there any changes here or should I apply the patches as in 4.2? 
Also, I think I lost track of what I applied where, there are quite a few patches as in comment#19 comment#36 and comment#38. Should I apply all of them?
Please let me know and I will send you back the customer report from the simplified example in English

Created attachment 373967 [details]
xml example more invoices

attaching xml example file which might be easier to verify the new issue on this

I included more invoices on customer1 in accordance with my customer and without changing the A/P to LIABILITY on this one. When I run this on 3.11 and select From Date 01/12/2020 to 31/12/2020 it works fine, when I use the 4.2 or 4.4 for that matter I get wrong Open Balance as described before etc etc.

Like I said, I lost a bit track of which patches I applied and where, so it would be useful to have an update on which patches I need to apply to a clean version of the scm file from 4.2 (or 4.4 for that matter)

Thanks again

The current best starting point is the maint version.

https://github.com/Gnucash/gnucash/blob/f2c4f80d3905ad7e04a72077fc6e6b65ba2eef89/gnucash/report/reports/standard/new-owner-report.scm

I'll look into this when I can find the time.

Ok. Last change. I think this fixes it perfectly:

modified   gnucash/report/reports/standard/new-owner-report.scm
@@ -790,6 +790,7 @@
      ((< (xaccTransGetDate (xaccSplitGetParent (car splits))) start-date)
       (let* ((txn (xaccSplitGetParent (car splits)))
              (value (AP-negate (xaccTransGetAccountAmount txn acc))))
+        (hash-set! seen-txns txn #t)
         (lp printed? odd-row? (cdr splits) invalid-splits (+ total value)
             debit credit tax sale)))

ok great will try this tomorrow when back in the office

just to be on same page here, apply only this patch to a clean version of 4.2 (or i guess 4.4 for that matter since i could not find a difference in between the two version on this), and forget about the previous suggested patches correct?

Uh no sorry apply to current cutting-edge at https://github.com/Gnucash/gnucash/blob/maint/gnucash/report/reports/standard/new-owner-report.scm

So does the final amendment work or not?

hi, took me a while, I tried both 4.2 and 4.4 and seems to work fine. (Also changed xml file to LIABILITY for the VAT account)
The only issue that remains is that of formatting in payments showing up on the report. When a payment is applied to a single invoice then only one line appears on the report corresponding to the payment, however, when a payment is applied to multiple invoices then the specific payment entry on the report extends kind of awkward to adding multiple spacing lines and the number of lines correspond to the number of invoices. See attachment 373963 [details] as an example.

Payment on 16/02/2018 for example has 4 or 5 lines on the report (not in front of me now to tell exact number) that are associated to the payment being applied to 4 or 5 different invoices

Pushed calculation fix.

The payment has multiple lines because it's showing the memos from the associated invoices. The invoices having no memos do not preclude them from being included. To change this behaviour will lead to invalid behaviour elsewhere so I won't change it.

how to you remove memos from invoices then? 
cause this can get really "ugly", sending an example on next post, but similar behaviour was not the same in 3.11 for example and reports did not created this Hugh gaps between payments in the report

Created attachment 373972 [details]
report 42

if you need me to send you also the same exact report from 3.11 to see how nicely it looks on 3.11, please let me know

Ok the last one was a major ugliness. Pushed fix in latest maint. Check Comment 59 again.

great thanks seems to be working fine, appreciate all the help