Thu, 18 Jun 2015 21:51:53 +0530Fixes Issue 30167:Inactive products can be selected in Create Lines process
Atul Gaware <atul.gaware@openbravo.com> [Thu, 18 Jun 2015 21:51:53 +0530] rev 27015
Fixes Issue 30167:Inactive products can be selected in Create Lines process
of Purchase Order window

Added a isactive check in the where clause of the view to load only active
products.

Mon, 22 Jun 2015 20:24:40 +0200Related to issue 30108: Add a modulescript to update created clients
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 22 Jun 2015 20:24:40 +0200] rev 27014
Related to issue 30108: Add a modulescript to update created clients

A new modulescript has been added in order to activate the "Show in Header" flag, to clients with "Central Maintenance" flag activated, for "AR Receipt" and "AP Payment" documents and "Business Partner" accounting dimension, in Client - Dimensions tab.

Fri, 05 Jun 2015 10:37:14 +0200Fixes issue 30108: BP not shown in Payment In/Out Header in F&B client
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 05 Jun 2015 10:37:14 +0200] rev 27013
Fixes issue 30108: BP not shown in Payment In/Out Header in F&B client

Set ismandatory = Y to "Business Partner" accounting dimension for "AP Payment" and "AR Receipt" documents in FIN_Payment table in Dimension Mapping window.
Set show in header = Y to "Business Partner" accounting dimension for "AP Payment" and "AR Receipt" documents in Client window - Dimension tab in F&B client.

Tue, 23 Jun 2015 10:14:39 +0200Fixes issue 30222: delete popup is not hidden under some circumstances
Inigo Sanchez <inigo.sanchez@openbravo.com> [Tue, 23 Jun 2015 10:14:39 +0200] rev 27012
Fixes issue 30222: delete popup is not hidden under some circumstances

The problem was that if two or more records were selected and deleted, the records were deleted properly but the "Deleting..." popup is not hidden.
The user will not be able to interact with the window until he refreshes it. This happends when in a grid that contains a tree grid view

This happened when a grid contains a treegrid and this one is not open first. In that case this element "view.treeGrid.data.handleUpdate" has not been created yet.

To avoid the problem, it has added a condition that checks whether the properties have been started correctly and thus, if the properties can be accessed.

Mon, 22 Jun 2015 13:51:28 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 22 Jun 2015 13:51:28 +0000] rev 27011
CI: merge back from main

Mon, 22 Jun 2015 13:35:27 +0000CI: update AD_MODULE to version 27007
RM packaging bot <staff.rm@openbravo.com> [Mon, 22 Jun 2015 13:35:27 +0000] rev 27010
CI: update AD_MODULE to version 27007

Tue, 16 Jun 2015 20:02:44 +0200Fixes issue 30184: Wrong commission amount
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 16 Jun 2015 20:02:44 +0200] rev 27009
Fixes issue 30184: Wrong commission amount

In case of Basis Status = "Fully paid documents", select query should not have distinct clause, as each line will be retrieved as percentage of invoice line amount.

Mon, 22 Jun 2015 11:24:40 +0200Fixes issue 30216: DatabaseVersionCheck should use commons.lang.StringUtils
Carlos Aristu <carlos.aristu@openbravo.com> [Mon, 22 Jun 2015 11:24:40 +0200] rev 27008
Fixes issue 30216: DatabaseVersionCheck should use commons.lang.StringUtils

Mon, 22 Jun 2015 09:18:27 +0200Merge back from main
RM packaging bot <staff.rm@openbravo.com> [Mon, 22 Jun 2015 09:18:27 +0200] rev 27007
Merge back from main

Mon, 22 Jun 2015 06:25:14 +0000Merge temporary head for 3.0PR15Q2.2
RM packaging bot <staff.rm@openbravo.com> [Mon, 22 Jun 2015 06:25:14 +0000] rev 27006
Merge temporary head for 3.0PR15Q2.2

Thu, 18 Jun 2015 08:47:55 +0000Added signature for changeset bd0e758ae44e
RM packaging bot <staff.rm@openbravo.com> [Thu, 18 Jun 2015 08:47:55 +0000] rev 27005
Added signature for changeset bd0e758ae44e

Thu, 18 Jun 2015 08:47:54 +0000Added tag 3.0PR15Q2.2 for changeset a28a880b5aeb
RM packaging bot <staff.rm@openbravo.com> [Thu, 18 Jun 2015 08:47:54 +0000] rev 27004
Added tag 3.0PR15Q2.2 for changeset a28a880b5aeb

Thu, 18 Jun 2015 08:47:54 +0000Update AD_MODULE version to 3.0PR15Q2.2 3.0PR15Q2.2
RM packaging bot <staff.rm@openbravo.com> [Thu, 18 Jun 2015 08:47:54 +0000] rev 27003
Update AD_MODULE version to 3.0PR15Q2.2

Wed, 17 Jun 2015 14:27:39 +0200Related to issue 30019: Backout changeset c7f004f2815d
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 17 Jun 2015 14:27:39 +0200] rev 27002
Related to issue 30019: Backout changeset c7f004f2815d

Wed, 17 Jun 2015 14:25:28 +0200Related to issue 30098: Backout changeset 49877fccad05
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 17 Jun 2015 14:25:28 +0200] rev 27001
Related to issue 30098: Backout changeset 49877fccad05

Tue, 16 Jun 2015 18:06:36 +0200Related to issue 30090: displayed value should be set in fk fields
Carlos Aristu <carlos.aristu@openbravo.com> [Tue, 16 Jun 2015 18:06:36 +0200] rev 27000
Related to issue 30090: displayed value should be set in fk fields

When the default value of a foreign key field in a new record does not exist already in the grid data, the display value can not be recovered in the setEditValue() method.
In order to ensure the display value is updated to reflect the new edit-value for this field, the display value is now explicitly set.
Also, we send null ROW_ID to avoid the edit values be overriden by the FIC response

Fri, 12 Jun 2015 12:49:18 +0200Related to issue 30121: code review improvements
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Fri, 12 Jun 2015 12:49:18 +0200] rev 26999
Related to issue 30121: code review improvements

The invoice's payment schedules and payment monitor is only updated when all the payment schedule details are paid.

This changeset covers the scenario where an order is partially paid. Before this change, the invoice's payment schedules and payment monitor were wrongly updated considering that the payment schedule was fully paid when any of its payment schedule details was paid. That asumption may be wrong in some scenarios, for example when the order is associated to one or more payment schedule details not yet paid (isinvoicepaid=N) and at least one already paid.

Wed, 10 Jun 2015 13:09:56 +0200Fixed issue 30121: Payment plan is updating wrong in some circumstances
Jorge Garcia <jorge.garcia@openbravo.com> [Wed, 10 Jun 2015 13:09:56 +0200] rev 26998
Fixed issue 30121: Payment plan is updating wrong in some circumstances

Payment plan is updating wrong if Payment Method is set as Automatic Receipt
and a sales order is partially paid.

The problem was that the function duplicates the value of the received amount
created in the Complete process of the invoice, because the function searches
all the payment details of the payment plan that has an invoice paid
(invoicepaid column).

The solution is to search those payment details that are not pre-paid and then
update the payment plan.

Now, the values are filled correctly.

Fri, 12 Jun 2015 12:05:42 +0200Related to issue 30115: code review improvements
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Fri, 12 Jun 2015 12:05:42 +0200] rev 26997
Related to issue 30115: 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 30115: 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 26996
Fixed issue 30115: 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 30139: Error when generating credit and adding a negative line
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 10 Jun 2015 16:55:01 +0200] rev 26995
Fixes issue 30139: 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 17:14:48 +0200Fixes issue 30113: Critical bug with decimals only in PostgreSQL 9.3
Carlos Aristu <carlos.aristu@openbravo.com> [Wed, 10 Jun 2015 17:14:48 +0200] rev 26994
Fixes issue 30113: 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.
In 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:22:04 +0200Fixes issue 30090: Select Payments Pick&Edit window is not working properly
Carlos Aristu <carlos.aristu@openbravo.com> [Wed, 10 Jun 2015 10:22:04 +0200] rev 26993
Fixes issue 30090: 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 30098: BP current balance not properly updated
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 04 Jun 2015 17:47:14 +0200] rev 26992
Fixes issue 30098: 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 30104: updated copyright
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Thu, 04 Jun 2015 17:02:09 +0200] rev 26991
Related to issue 30104: updated copyright

Tue, 02 Jun 2015 09:06:32 +0200Fixed issue 30104: Completed quantity in the Work Requirement is not updated
Jorge Garcia <jorge.garcia@openbravo.com> [Tue, 02 Jun 2015 09:06:32 +0200] rev 26990
Fixed issue 30104: 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 30063: 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 26989
Fixes issue 30063: 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 13:02:49 +0200Fixes issue 30019: Payment schedule amount incorrectly calculated.
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 28 May 2015 13:02:49 +0200] rev 26988
Fixes issue 30019: 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.

Tue, 26 May 2015 18:20:34 +0200Fixed bug 30010: Error in Requisition To Order window
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Tue, 26 May 2015 18:20:34 +0200] rev 26987
Fixed bug 30010: Error in Requisition To Order window

When creating a purchase order from the Requisition To Order window, an error was raised when lines[i].quantityorder is empty.
Now the SQL query returns quantityorder = 0 when it's null. Then, when inserting the purchase order line, the process inserts "" if quantityorder = 0

Wed, 20 May 2015 14:06:47 +0200Fixes issue 29980: NPE in Add Payment process request
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 20 May 2015 14:06:47 +0200] rev 26986
Fixes issue 29980: NPE in Add Payment process request

When selecting a business partner with the magnifying glass in Add Payment process request, which does not match to the type of the document (a Vendor when the type is Received In); the payment method of the business partner was null and when accessing to its id, a NPE was raised.
Now, if payment method is null will be checked.