Fri, 12 Jun 2015 12:05:42 +0200Related to issue 30116: code review improvements
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Fri, 12 Jun 2015 12:05:42 +0200] rev 26965
Related to issue 30116: code review improvements
Reduced useless query complexity to update outstanding amount.
It's only necessary to check fin_payment_detail_id is null (not associated payment) or isinvoicepaid='N' (associated payment but in a non paid yet status)

Wed, 10 Jun 2015 10:52:18 +0200Fixed issue 30116: Outstanding amount of sales order payment plan is not updated
Jorge Garcia <jorge.garcia@openbravo.com> [Wed, 10 Jun 2015 10:52:18 +0200] rev 26964
Fixed issue 30116: Outstanding amount of sales order payment plan is not updated

The problem was that the outstanding amount of sales order payment plan is not
updated when payment method is set as automatic receipt.

Before the commit which introduces this regression, the function checked the
status of the payment. With the changes, the function checks if the payment
schedule detail is paid.

The problem was in the update of the payment plan of the sales order,
specifically in WHERE clause for outstanding amount.

Now, the where clause works as expected, and the outstanding amount is updated
properly.

Wed, 10 Jun 2015 16:55:01 +0200Fixes issue 30140: Error when generating credit and adding a negative line
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 10 Jun 2015 16:55:01 +0200] rev 26963
Fixes issue 30140: Error when generating credit and adding a negative line

Add Payment was raising an error if credit used was greater than total amount.
Now, this comprobation will only be done if some record has been selected in Credit To Use grid.

Wed, 10 Jun 2015 10:32:27 +0200Fixes issue 30114: Critical bug with decimals only in PostgreSQL 9.3
Carlos Aristu <carlos.aristu@openbravo.com> [Wed, 10 Jun 2015 10:32:27 +0200] rev 26962
Fixes issue 30114: Critical bug with decimals only in PostgreSQL 9.3

A new build validation has been added. This way, when executing update.database the result returned by the to_number() procedure is evaluated.
n case it does not return the expected result, the task will fail, showing a message with the link to the documentation.

Wed, 10 Jun 2015 10:18:39 +0200Fixes issue 30091: Select Payments Pick&Edit window is not working properly
Carlos Aristu <carlos.aristu@openbravo.com> [Wed, 10 Jun 2015 10:18:39 +0200] rev 26961
Fixes issue 30091: Select Payments Pick&Edit window is not working properly

When selecting a record in a P&E grid, the request done to the FIC was not using the correct mode. Now, when selecting a record, the request is properly done using the EDIT mode.

Thu, 04 Jun 2015 17:47:14 +0200Fixes issue 30099: BP current balance not properly updated
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 04 Jun 2015 17:47:14 +0200] rev 26960
Fixes issue 30099: BP current balance not properly updated

Change condition in FIN_PaymentProcess to take into account when the paymend does not have order nor invoice related (when it only has a g/l item, when we are genereting credit or when we are refunding amount).

Thu, 04 Jun 2015 17:02:09 +0200Related to issue 30105: updated copyright
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Thu, 04 Jun 2015 17:02:09 +0200] rev 26959
Related to issue 30105: updated copyright

Tue, 02 Jun 2015 09:06:32 +0200Fixed issue 30105: Completed quantity in the Work Requirement is not updated
Jorge Garcia <jorge.garcia@openbravo.com> [Tue, 02 Jun 2015 09:06:32 +0200] rev 26958
Fixed issue 30105: Completed quantity in the Work Requirement is not updated

Completed quantity in the Work Requirement is not updated under some
circumstances.

The problem was that the ma_workeffort_validate wasn't updated the UPDATED
column of the ma_wrpahse table and you can save even if the line had changed in
the work effort window.

The solution is to update the column with the actual date. Now, when you try to
save it, a error appears in the grid and the save is canceled.

Thu, 04 Jun 2015 14:54:06 +0200Fixes issue 30064: Grid is properly loaded after refreshing with a selected row
Augusto Mauch <augusto.mauch@openbravo.com> [Thu, 04 Jun 2015 14:54:06 +0200] rev 26957
Fixes issue 30064: Grid is properly loaded after refreshing with a selected row

The problem was caused by this code (the this attribute is a ResultSet), which is contained in the fetchRemoteData function:

} else if (this.grid.refreshingWithSelectedRecord) {
// if the grid was refreshed with a record selected, use the range that contained that record
// instead of using targetRecordId to improve the performance
startRow = this.grid.selectedRecordInitInterval;
endRow = this.grid.selectedRecordEndInterval;
}

If the grid is refreshed while one of its records is selected, then the startRow and endRow will be set so that the requested page contains the selected record. The problem was that the ResultSet.localData attribute was not being properly set, as at this points it was expected to contain the 'loading' value for all the rows that are being requested. As a result of this the localData attribute became malformed when the response was processed, and this caused the grid to misbehave.

To fix this, the localData is configured to wait for the proper records:

this.localData = [];
this.setRangeLoading(startRow, endRow);

Thu, 28 May 2015 12:33:42 +0200Fixes issue 30020: Payment schedule amount incorrectly calculated.
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 28 May 2015 12:33:42 +0200] rev 26956
Fixes issue 30020: Payment schedule amount incorrectly calculated.

Payment schedule amount incorrectly calculated when adding a payment from reconcile window to a sales order.
FIN_TransactionProcess and PaidStatusEventHandler have been changed in order to set invoicepaid=true only when FIN_PaymentScheduleDetail has a related InvoicePaymentSchedule.
FIN_PaymentProcess.java has also been changed, in order to check invoicePaidAmounts only if FIN_PaymentScheduleDetail has a related InvoicePaymentSchedule.
In case of a payment to a order without an invoice, updatePaymentAmounts will be called only once.
Name of preference in UpdatePaymentPlan modulescript has been update to run it again and fix wrong data created by the issue.