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 27004
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 27003
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 27002
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 27001
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 27000
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 26999
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 26998
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 26997
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 26996
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 26995
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.