I used the Process Payment feature to process a payment for a customer from 2018. (it was entered as a 'pre-payment' or not assigned to an invoice, to be assigned later - I'm correcting a different workflow) But I errantly committed the payment too quickly and didn't realize the year defaulted to 2019. When trying to use the Edit Payment function by right-clicking the payment transaction (in any relevant register) while I was able to edit the year in the date field, the result was that the year did not change. I had to delete the payment and start over. Expected Behavior: Editing any information via the Edit Payment function should 'stick'.
Follow up: Editing the date in a register works, but I thought it would be better to do so via the Edit Payment function. I don't know if this register edit is 'taken notice of' by the business features. Though it appears from a Customer Report that the change is recognized and a fresh Process Payment window shows the proper date on the pre-payment now. While there is an obvious and simple method available, I still think it should work from the Edit Payment window, especially considering the admonitions not to manually edit business related transactions.
Adrien - if you're running latest maint you'll find new aging+owner reports in the experimental submenu. From my understanding: - owner-report (both current and beta ones) take the txn-date for labelling the rows - owner-report takes invoice posting/due date for the aging-table - aging-report takes invoice posting/due date for the aging-table So, I think this bug should really be: - edit-payment should/shouldn't modify the txn date as part of its code? It currently doesn't.
Patch? modified gnucash/gnome/dialog-payment.c @@ -990,6 +990,8 @@ gnc_payment_ok_cb (G_GNUC_UNUSED GtkWidget *widget, gpointer data) gncOwnerApplyPaymentSecs (&pw->owner, &(pw->tx_info->txn), selected_lots, pw->post_acct, pw->xfer_acct, pw->amount_tot, exch, t, memo, num, auto_pay); + + xaccTransSetDatePostedSecs (pw->tx_info->txn, t); } gnc_resume_gui_refresh ();
Close. The data handling of this transaction is handled in gncOwnerCreatePaymentLotSecs but was only done for newly created transactions. I have now changed it to do so for pre-existing transactions as well. Will be fixed for 3.8
Hmmm... This is fixed as per the original issue, but the fix has created another as part of the same process. I just tested changing date with the Edit Payment function and changed a payment I made today, to tomorrow. (just as a test) While the date was correctly changed, some of my splits were altered incorrectly. Admittedly, this wasn't a simple one:one payment of a vendor bill. The payment was for one bill and partial for the next. Additionally, as this was a cash payment, I recorded the actual amount tendered on as a credit, then added splits for cash and coin change as additional debits. The resulting transaction removed my cash account and replaced it with Imbalance +$1. It also removed both cash change and coin change splits, and added them to the amount of the partial payment accordingly. Ideally, changing the date should *only* change the date. It seems some code for re-calculating the payment is also being fired.
Sorry, Comment 5 is concerning 3.906 on MacOS 10.15.5 (Catalina).
(In reply to Adrien from comment #5) > Ideally, changing the date should *only* change the date. It seems some code > for re-calculating the payment is also being fired. Ideally yes. However the process payment dialog can only model what it can display atm. The process payment dialog doesn't support having multiple payment splits. So if you try to edit such a payment transaction it will discard what it can't handle. I *thought* I had set up warning dialogs to warn the user in case such a situation would arise, but perhaps I missed a few scenarios. Note I doubt this is caused by the particular fix for this bug. Can you run this same test on gnucash 3.7 ? It would obviously still fail to change the date, but I'd be interested to know whether it also messes up the additional splits.
Adrien, can you either run the test Geert asked for or close the bug as fixed?
