|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|defect||[Openbravo ERP] 09. Financial management||major||always||2014-11-20 12:39||2015-05-27 13:44|
|Priority||normal||Resolution||no change required||Fixed in Version|
|Status||closed||Fix in branch||Fixed in SCM revision|
|OS||Linux 64 bit||Database||PostgreSQL||Java version||1.6.0_45|
|OS Version||Ubuntu 14.10||Database version||9.3.5||Ant version||1.8.4|
|Product Version||SCM revision||ae2b41d1cc2e 3.0PR14Q2.6|
|Review Assigned To||pramakrishnan|
|Regression level||Production - Confirmed Stable|
|Regression introduced in release||3.0PR14Q2|
|Regression introduced by commit||https://code.openbravo.com/erp/devel/pi/rev/f7078a85289e6c61918f567b28d2df3fe17ddb47 [^]|
|Triggers an Emergency Pack||No|
0028236: Payment schedule amount incorrectly calculated when adding a payment from reconcile window to a sales order
|Description||Payment schedule amount incorrectly calculated when adding a payment from financial account reconcile window to a sales order|
|Steps To Reproduce||- Create a sales order from "F&B España - Región Norte" org to BP "Alimentos y Supermercados, S.A" for 1,000 and book it.|
- Go to the Financial Account "Cuenta de Banco"
- Click on tab "Imported Bank Statement"
- Click on new, give it a name, and go to "Bank Statement Lines" tab.
- Click on new, give it a reference, choose "Alimentos y Supermercados, S.A" business partner, set amount in to 1,000.
- Click on save and process, and Match Statement.
- Click on "+" icon to create a transaction.
- Click on Add Payment In/Out
- Choose transaction type "Orders", set the amount to 1,000.
- Select just the 1,000 order created in the previous step.
- Click on process, and choose "Process Received payment/s and deposit", and click on Ok.
- Go to the sales order, and realize that payment schedule record says:
Expected Amount: 1,000
Received Amount: 2,000
|Proposed Solution||- fin_payment_schedule record is not correctly updated when running the described steps.|
- fin_payment_schedule_detail records are ok. The issue is when updating the fin_payment_schedule record.
- Please notice that if you click on "Add Transaction" in Financial Account window, bug is not reproduced, only if AddTransaction servlet is invoqued from the automatic reconcile window.
|Tags||No tags attached.|
|Attached Files||Fix28236.diff [^] (31,356 bytes) 2014-12-04 07:44 [Show Content]|
Furthermore, if you delete the conciliation and transaction in financial account, and try to re-open the sales order, the "Related payments" error is shown, when is it false: the payment was deleted, but:
1- Due to the issue, instead of received amount=1,000 outstanding=0; the result was received amount=2,000 outstanding=-1,000
2- When deleting the payment in, then the information in the payment plan tab of the sales order is: received amount=1,000 outstanding=0. But the number of payments column says "0", and actually, the payment plan detail tab is empty.
This means that, in order to fix this issue, it's required a module script that updates all this amounts, as there is no way (through UI) to fix this :(
In FIN_AddPayment.java, at line 1127, this line:
sets the incorrect amount, as the paymentSchedule.PaidAmount value is already updated with the amount of the payment that is being created.
Following the example in steps to reproduce. When arriving this point, the values are:
paymentSchedule.getPaidAmount() <= 1,000
amount <= 1,000
This way, the paid amount that is set is 2,000 and not 1,000.
This line was set in the 3.0RC2 tagged changeset, so there is not the problem. It seems, this function is, now, called twice during the process, or something like that.
After a deeper research, here you have my two cents:
- Fin_PaymentProcess class (in line 409) calls FIN_AddPayment.updatePaymentScheduleAmounts which actually updates the paid amount of the fin_payment_schedule record.
- Afterwards, in line 447, OBDal.getInstance().flush() persists these changes.
- Once the execuction is over, and servlet finishes completely the execution, then PaidStatusEventHandler class is invoked and onUpdate function executed. As psd.isInvoicePaid() is true, then FIN_Utility.updatePaymentAmounts function is run again, duplicating the paid amount.
I've gone as further as I can. I'm not used at all to this new functionality in OB of EntityPersistenceEventObserver objects.
This one task I do several times per week, and it was always working fine. I've upgraded from MP20 to PR14Q2.6, and now this issue is faced. It seems to be related to the changes done in the windows of the advanced payables and receivables module.
Thanks in advance for your help!!
|Issue not reproducible in PI. Attached fix for Q3 version.|
|Module script needs to be modified for performance reasons.|
|Issue not reproducible in PI. Attached fix for Q3 version.|
|Reopened to attach updated patch|
One question. Has the module-script been included in PI?
|2014-11-20 12:39||txasu||New Issue|
|2014-11-20 12:39||txasu||Assigned To||=> adrianromero|
|2014-11-20 17:44||txasu||Note Added: 0071857|
|2014-11-20 18:08||txasu||Note Added: 0071858|
|2014-11-20 20:14||txasu||Note Added: 0071859|
|2014-11-20 20:44||txasu||Note Added: 0071860|
|2014-11-21 10:45||Sandrahuguet||Assigned To||adrianromero => pramakrishnan|
|2014-11-21 10:51||Sandrahuguet||Regression level||=> Production - Confirmed Stable|
|2014-11-21 11:28||pramakrishnan||Status||new => scheduled|
|2014-11-21 11:28||pramakrishnan||fix_in_branch||=> pi|
|2014-11-21 11:58||Sandrahuguet||Project||Modules => Openbravo ERP|
|2014-11-21 11:59||Sandrahuguet||Modules||=> Core|
|2014-11-21 11:59||Sandrahuguet||Triggers an Emergency Pack||=> No|
|2014-11-21 11:59||Sandrahuguet||Category||Advanced Payments => 09. Financial management|
|2014-11-21 11:59||Sandrahuguet||fix_in_branch||pi =>|
|2014-11-27 12:28||Sandrahuguet||Regression date||=> 2014-04-03|
|2014-11-27 12:28||Sandrahuguet||Regression introduced in release||=> 3.0PR14Q2|
|2014-11-27 12:28||Sandrahuguet||Regression introduced by commit||=> https://code.openbravo.com/erp/devel/pi/rev/f7078a85289e6c61918f567b28d2df3fe17ddb47 [^]|
|2014-11-27 12:42||pramakrishnan||File Added: Issue28236.diff|
|2014-11-27 12:47||pramakrishnan||Review Assigned To||=> pramakrishnan|
|2014-11-27 12:47||pramakrishnan||Note Added: 0072062|
|2014-11-27 12:47||pramakrishnan||Status||scheduled => closed|
|2014-11-27 12:47||pramakrishnan||Resolution||open => no change required|
|2014-11-27 12:47||pramakrishnan||Fixed in Version||=> pi|
|2014-11-27 13:06||pramakrishnan||Note Added: 0072064|
|2014-11-27 13:06||pramakrishnan||Status||closed => new|
|2014-11-27 13:06||pramakrishnan||Resolution||no change required => open|
|2014-11-27 13:06||pramakrishnan||Fixed in Version||pi =>|
|2014-11-27 13:14||pramakrishnan||File Deleted: Issue28236.diff|
|2014-12-01 11:46||pramakrishnan||File Added: Issue28236.diff|
|2014-12-01 11:46||pramakrishnan||Note Added: 0072181|
|2014-12-01 11:46||pramakrishnan||Status||new => closed|
|2014-12-01 11:46||pramakrishnan||Resolution||open => no change required|
|2014-12-04 07:44||pramakrishnan||Note Added: 0072272|
|2014-12-04 07:44||pramakrishnan||Status||closed => new|
|2014-12-04 07:44||pramakrishnan||Resolution||no change required => open|
|2014-12-04 07:44||pramakrishnan||File Deleted: Issue28236.diff|
|2014-12-04 07:44||pramakrishnan||File Added: Fix28236.diff|
|2014-12-04 07:45||pramakrishnan||Status||new => closed|
|2014-12-04 07:45||pramakrishnan||Resolution||open => no change required|
|2014-12-05 12:52||txasu||Note Added: 0072309|
|2015-05-26 18:29||aferraz||Relationship added||has duplicate 0030007|
|2015-05-27 13:44||aferraz||Relationship added||causes 0029389|
|2015-06-12 14:11||vmromanos||Relationship added||blocks 0030170|
|Copyright © 2000 - 2009 MantisBT Group|