Mon, 26 Oct 2015 07:50:16 +0000Added signature for changeset 9755d00af209
RM packaging bot <staff.rm@openbravo.com> [Mon, 26 Oct 2015 07:50:16 +0000] rev 27672
Added signature for changeset 9755d00af209

Mon, 26 Oct 2015 07:50:16 +0000Added tag 3.0PR15Q3.2 for changeset 9320a67a9ef1
RM packaging bot <staff.rm@openbravo.com> [Mon, 26 Oct 2015 07:50:16 +0000] rev 27671
Added tag 3.0PR15Q3.2 for changeset 9320a67a9ef1

Mon, 26 Oct 2015 07:50:16 +0000Update AD_MODULE version to 3.0PR15Q3.2 3.0PR15Q3.2
RM packaging bot <staff.rm@openbravo.com> [Mon, 26 Oct 2015 07:50:16 +0000] rev 27670
Update AD_MODULE version to 3.0PR15Q3.2

Thu, 22 Oct 2015 18:28:21 +0200fixes issue 31225: Toolbar disappears under some circumnstances
Carlos Aristu <carlos.aristu@openbravo.com> [Thu, 22 Oct 2015 18:28:21 +0200] rev 27669
fixes issue 31225: Toolbar disappears under some circumnstances

Mon, 19 Oct 2015 12:38:32 +0200Fixed bug 31168: Copy Version process in Process Plan window is not working in Oracle
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Mon, 19 Oct 2015 12:38:32 +0200] rev 27668
Fixed bug 31168: Copy Version process in Process Plan window is not working in Oracle

Ad_Sequence_Doc is a stored procedure that returns the next sequence number using an "out" parameter. The CallStoredProcedure.call() used to call that procedure doesn't currently support parameters of type "out", creating an exception in Oracle only (and not in PostgreSQL because the procedure is declared as a function returning the value).

Instead of calling the procedure using CallStoredProcedure.call(), we use Utility.getDocumentNo() method instead, which is a more standard way to get the next sequence no. from Java, and supports Oracle procedures with "out" parameters.

Besides the class has been modified to properly show an error message in the UI in case an exception is raised, which is something not working before neither.

Thu, 15 Oct 2015 10:04:13 +0200Related with issue 31055: The condition has been changed.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Thu, 15 Oct 2015 10:04:13 +0200] rev 27667
Related with issue 31055: The condition has been changed.

The if condition which handles the invalidation of the value maps cache has been modified for getting the correct behaviour.

Wed, 14 Oct 2015 15:45:22 +0200Fixed issue 31055: Create a new record in a form was not working fine.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Wed, 14 Oct 2015 15:45:22 +0200] rev 27666
Fixed issue 31055: Create a new record in a form was not working fine.

The problem was that, if you create a new record in form view, and after fulfilling the form, you
click in the create a new record in a form button without previously saving the firstly created record,
it was not working fine. In Goods Movements lines tab, for example, the value of the product chosen in
the first record was shown. That wasn't correct, the product should be empty.

The problem was in the "ob-standard-view-datasource.js" the value map cache was being invalidated.

To fix this, some clases have been changed.
In the "ob-standard-view.js" in the "newDocument" function the parameters the isNewDocument parameter
has been added and it is set to true.
This parameter is passed to the request for being able to take it in the class "ob-standard-view-datasource.js"
and to use it in the logic that invalidates the value map cache.
Now, if this parameter is set to true, the value map cache is not invalidated.

Mon, 28 Sep 2015 18:10:02 +0200iFixes Issue 31049. Return Material flow should not be included
David Miguelez <david.miguelez@openbravo.com> [Mon, 28 Sep 2015 18:10:02 +0200] rev 27665
iFixes Issue 31049. Return Material flow should not be included
in Price Correction Process.
Also, make sure every Transaction that goes through this process
is set to no longer check Price Correction.

Fri, 02 Oct 2015 12:39:49 +0200Fixed bug 31022: hidden fields in several windows related to acct. dimensions
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Fri, 02 Oct 2015 12:39:49 +0200] rev 27664
Fixed bug 31022: hidden fields in several windows related to acct. dimensions

The display logic of some fields driven by the accounting dimension display logic utility was not working fine when the auxiliary input "DOCBASETYPE" (used by to calculate the acct. dimension display logic) was null.
This auxiliary input has a hardcoded value in some windows, however in other windows it is gotten from the DB using the selected document type. In the latter scenario, when the document type field is blank, the "DOCBASETYPE" auxiliary input was null, so the system was unable to detect the right configuration, thus hiding the fields.

The regression is caused by issue #29767. The business partner and organization fields were configured to use the accounting dimension display logic utility in the following windows:
* Sales Order
* Purchase Order
* Sales Invoice
* Purchase Invoice
* Payment In (not affected as it has a hardcoded "DOCBASETYPE")
* Payment Out (not affected as it has a hardcoded "DOCBASETYPE")

The fix improves the SQL for getting the "DOCBASETYPE" auxiliary input in the affected windows, so in case the document type is null, a generic value (the most commonly used) is returned depending on the window:
* Sales Order: SOO
* Purchase Order: POO
* Sales Invoice: ARI
* Purchase Invoice: API

Fri, 02 Oct 2015 12:24:48 +0200Fixes issue 31023: Credit consumed although payment not completed
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 02 Oct 2015 12:24:48 +0200] rev 27663
Fixes issue 31023: Credit consumed although payment not completed

When consuming a credit with a currency different than Business Partner's currency, an error is shown but credit was also consumed, which was wrong.
Now, this check will be also done before consuming credit in AddPaymentActionHandler addCredit method, as it was done in FIN_PaymentProcess doProcessPayment method.