Op maandag 30 december 2024 22:45:09 Midden-Europese standaardtijd schreef Jim DeLaHunt: > > When you assign payment to the invoice, the existing transaction will > > be overwritten with an entry in the account payable, and the split > > will apply automatically in the AP. > > This certainly matches what I observe in my GnuCash book, but it > certainly is not what I want to happen. Can you point me to further > documentation about what GnuCash intends to do when I assign a > transaction as payment? Or, can you point me to which parts of the code > I should read? >
The payment management logic in the business features is limited in what it can do. Basically it can only handle pre-existing transactions with a single split outside of the AR or AP accounts. If there are more it will choose one (using some very simple heuristics) and discard the others. It will also discard the pre-existing AR or AP splits and replace them with whatever you select in the payment dialog (though it will use the AR or AP splits to pre-select documents and pre-payments in the payment window if it can). The use case this was written for is the most simple case of importing payment data from your bank account and later linking this with one or more invoices. The use case of payment charges was never considered unfortunately. It's been a while so I have to think really hard why I chose to discard all splits except that one - or more precisely why I chose not to change that behavior when I was working on the business code. I believe the reason is the payment window has no way to visualize multiple non AR/AP splits so it can not reliably display such a pre-existing transaction. What it can represent is any AR/AP split that links to an invoice or pre-/overpayment from the selected customer and one transfer split (the "bank" account split). Every aspect of it can also be modified: which invoices are being (partially or over-)paid, what is the total amount of the payment, and what is the transfer account. Having more than one transfer split would result in a incomplete and possibly misleading representation of the transaction in the current payment window and would lead to ambiguity when making changes. For example the value in the Payment field, should that represent the invoice amount being paid (meaning the sum of the money you actually received and the service charge) or just the amount of money you received ? What if you need to change that value for some reason, would that change reflect only a change in money received or also an increase in service charge ? So would that affect the amount of invoice being paid for or not ? As the service charge is not visible in the dialog, you can't disambiguate that. To avoid this ambiguity I chose to only work with a single non-AR/AP split. In hindsight it would have been much nicer to warn the user about this. I know the code does in some scenarios, but this one was seemingly skipped. To really support your use case, the gui should be extended to be able to show all non-AR/ AP splits. I did consider that, but it was more work than I could do at the time. > This also does not match what I took from the documentation. The GnuCash > > manual, section 7.6. "Process Invoice Payment", says: > > There is an alternative way of assigning a payment to (one or more) > > invoices where the payment transaction already exists…. This can best > > be done starting from the asset account register holding the imported > > payment transaction (like your bank account). In that account, select > > the payment, right-click ([two-finger]-click for |macOS|) and choose > > *Assign as payment...*. The payment window will pop-up, partly filled > > in with the information from the transaction. Fill in the missing > > information like the proper customer and invoice to complete the payment. > > This does not mention that the payment transaction will get rewritten, > and splits will get discarded. > True, though it doesn't mention all data from the existing transaction will be kept either :( I agree this could do with a better warning. > It occurs to me that one workaround is that I enter the payment > transaction as if there were no service charges. Then I assign the > transaction as payment for the invoice, letting GnuCash rewrite it. Then > I modify the transaction to add the service charge and reduce the amount > deposited in my bank account. > That is probably the easiest way to work around this. A slight variation is to enter the payment transaction with only the amount you really received, then assign the transaction as partial payment (the exact same process as in your suggestion, only with a lower payment amount) and then afterwards add the service charge and increase the AR split amount to match your invoice total. > Also, you advise: > > You should create your three-split transactions in your invoice… > > I am a bit surprised by this. Do you mean that I should I should list > the service charge from my payment processor as a credit in the invoice, > where the customer will see it? It seems to me that my customer won't > care, and does not need to know, details about the terms and feed of my > payment processor. > I agree that's not what you would want. > Implicit answers to my questions: > > Q1. Is this the expected behaviour? > > Apparently "yes". Yes. I explained above why that is so - a technical limitation as a result of design choices from the past. > > > Q2. What does the "Assign as payment" of a payment transaction to an > > invoice actually do? The GnuCash manual, section 7.6. "Process > > Invoice Payment", says what steps to take to perform an assignment, _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
