Mon, 23 Mar 2015 11:22:35 +0100Fixed bug 29207 Payment Out is registered as "BP Deposit" transaction
Sandra Huguet <sandra.huguet@openbravo.com> [Mon, 23 Mar 2015 11:22:35 +0100] rev 26465
Fixed bug 29207 Payment Out is registered as "BP Deposit" transaction

In FIN_TransactionProcess.java set the correct value depending on
the type of transaction
Fix aprm_gen_paymentschedule_inv function in order to have the
same behavior on all automatic processes

Tue, 24 Feb 2015 18:56:03 +0100related to issue 29021, related to issue 29051, related to issue 29052
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 24 Feb 2015 18:56:03 +0100] rev 26464
related to issue 29021, related to issue 29051, related to issue 29052

improve the error message

Mon, 23 Mar 2015 13:11:06 +0100related to 29299 update Copyright
Sandra Huguet <sandra.huguet@openbravo.com> [Mon, 23 Mar 2015 13:11:06 +0100] rev 26463
related to 29299 update Copyright

Mon, 16 Mar 2015 17:07:49 +0100Fixes bug 29299: Payment method in add payment does not display inactive values
Unai Martirena <unai.martirena@openbravo.com> [Mon, 16 Mar 2015 17:07:49 +0100] rev 26462
Fixes bug 29299: Payment method in add payment does not display inactive values

The whereClause of fin_payment_method combo in add payment has been changed to not display never payment methods that are inactive.

Also the default values of Add Payment window that are opened from all windows has been changed to not set as default a Payment Method that is inactive, even if it is marked as default in the financial account or if is the default payment method of the Business Partner.

A change has also been done in OB.APRM.AddPayment.paymentMethodMulticurrency javascript function. In Add Payment window, while clearing Payment Method combo manually, the Financial Account was also being cleared. This was causing a problem when opening from Financial Account, because in this case novalues were displayed on both combos any more. It has been fixed to not to clear the Financial Account combo in this case as always is going to be the same, so it is no necessary to clear it.

Thu, 12 Mar 2015 10:13:51 +0100Fixes bug 29249: Transactions created in Match Statement are created processed
Unai Martirena <unai.martirena@openbravo.com> [Thu, 12 Mar 2015 10:13:51 +0100] rev 26461
Fixes bug 29249: Transactions created in Match Statement are created processed

On Reconciliation Refactor process and new function was added to process transactions in APRM_MatchingUtility class, replacing the old processTransaction in MatchTransaction servlet. In the new method, the way in which the database stored procedure was being invoked was wrong, so It has been changed in order to work as it was doing in the old method.

Fri, 20 Mar 2015 09:32:09 +0100related to issue 29146
Sandra Huguet <sandra.huguet@openbravo.com> [Fri, 20 Mar 2015 09:32:09 +0100] rev 26460
related to issue 29146

Thu, 12 Mar 2015 10:59:13 +0100Fixed bug 29149 improve performance in UpdatePaymentPlan modulescript
Sandra Huguet <sandra.huguet@openbravo.com> [Thu, 12 Mar 2015 10:59:13 +0100] rev 26459
Fixed bug 29149 improve performance in UpdatePaymentPlan modulescript

Wed, 18 Mar 2015 18:30:39 +0100Related to bug 29264: Delete obaprmAllRecordsSelectedByUser in OrderInvoice Load
Unai Martirena <unai.martirena@openbravo.com> [Wed, 18 Mar 2015 18:30:39 +0100] rev 26458
Related to bug 29264: Delete obaprmAllRecordsSelectedByUser in OrderInvoice Load

While executing invalidateCache() function to reload OrderInvoice grid it internally calls to 'OB.APRM.AddPayment.deselectAllRecords' overriden method that sets obaprmAllRecordsSelectedByUser property to true. This property is only needed when manually the select/unselect all checkbox is clicked.

This was causing on certain scenarios that methods to update totals were not being called:
* OB.APRM.AddPayment.updateInvOrderTotal(view.theForm, orderInvoice);
* OB.APRM.AddPayment.updateActualExpected(view.theForm);
* OB.APRM.AddPayment.updateDifference(view.theForm);

So, in order to avoid this in OrderInvoiceOnLoad function, if the property 'obaprmAllRecordsSelectedByUser' exists, it will be deleted.

Wed, 18 Mar 2015 17:17:38 +0100related to issue 29146
Sandra Huguet <sandra.huguet@openbravo.com> [Wed, 18 Mar 2015 17:17:38 +0100] rev 26457
related to issue 29146

the validation only has to be considered when overpayment combo is visible

Mon, 16 Mar 2015 16:35:31 +0100Related to issue 29291: Update copyright
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 16 Mar 2015 16:35:31 +0100] rev 26456
Related to issue 29291: Update copyright

Mon, 16 Mar 2015 00:07:30 +0530Fixes Issue 29291:The sales order is not taking into account the unit price of
Atul Gaware <atul.gaware@openbravo.com> [Mon, 16 Mar 2015 00:07:30 +0530] rev 26455
Fixes Issue 29291:The sales order is not taking into account the unit price of
the product when is 0

Corner case regression, when ever unit price is set to zero in the price list

Wed, 18 Mar 2015 09:08:59 +0100fixed bug 29324: attachment download of different records at once fails
Asier Lostalé <asier.lostale@openbravo.com> [Wed, 18 Mar 2015 09:08:59 +0100] rev 26454
fixed bug 29324: attachment download of different records at once fails

It generated an invalid zip file.

The problem was it tried to find the attachment directory based on the whole
list of ids to download instead of splitting it.

Tue, 17 Mar 2015 19:07:29 +0100Fixed bug 29146: Used credit is not correct under certain circumstances
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 17 Mar 2015 19:07:29 +0100] rev 26453
Fixed bug 29146: Used credit is not correct under certain circumstances

Mon, 16 Mar 2015 19:26:32 +0100Fixes bug 29293: valueMap & value of combo item are properly set in P&E window
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 19:26:32 +0100] rev 26452
Fixes bug 29293: valueMap & value of combo item are properly set in P&E window

There were two problems:
- The valueMap of the fk combo item was not being set because after the combo refactor the FIC does not return the fk combo entries. To fix this, the valueMap is built manually based on the selected option.
- The value of the combo item was being set before defining its valueMap. When this happened no display value was shown in the combo. To fix this, the value is reset just after defining the valueMap.

Mon, 16 Mar 2015 17:22:59 +0100Related with issue 29293: Checks if the okButton exists to prevent error in log
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 16 Mar 2015 17:22:59 +0100] rev 26451
Related with issue 29293: Checks if the okButton exists to prevent error in log

Mon, 16 Mar 2015 18:39:38 +0100Related to issue 29301: Update copyright
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 16 Mar 2015 18:39:38 +0100] rev 26450
Related to issue 29301: Update copyright

Tue, 10 Mar 2015 13:58:57 +0100Fixes issue 29301
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Tue, 10 Mar 2015 13:58:57 +0100] rev 26449
Fixes issue 29301
Cannot complete a goods receipt with a line without attribute set value if it has a related prereservation.
Added coalesce when inserting to get default value

Fri, 13 Mar 2015 13:00:24 +0100Fixes bug 29264 Improved performance select/deselect all records in OrderInv grid
Unai Martirena <unai.martirena@openbravo.com> [Fri, 13 Mar 2015 13:00:24 +0100] rev 26448
Fixes bug 29264 Improved performance select/deselect all records in OrderInv grid

Thu, 12 Mar 2015 16:50:48 +0100Fixed bug 29207 Payment Out is registered as "BP Deposit" transaction
Sandra Huguet <sandra.huguet@openbravo.com> [Thu, 12 Mar 2015 16:50:48 +0100] rev 26447
Fixed bug 29207 Payment Out is registered as "BP Deposit" transaction

In FIN_TransactionProcess.java set the correct value depending on
the type of transaction

Thu, 12 Mar 2015 12:00:30 +0100Fixes issue 29253: 0 can be used to filter numeric columns
Augusto Mauch <augusto.mauch@openbravo.com> [Thu, 12 Mar 2015 12:00:30 +0100] rev 26446
Fixes issue 29253: 0 can be used to filter numeric columns

In this changeset [1] this code was added to the OBNumberItem.parseValueExpressions function:

ret = this.Super('parseValueExpressions', [value, fieldName, operator]);
+
+ // if operator is not supported remove it
+ if (!this.validOperators.contains(ret.operator)) {
+ ret.operator = '';
+ ret.value = '';
+ this.setValue('');
+ }
if (ret && ret.start) {
ret.start = this.convertToTypedValue(ret.start);
}

The problem is that if the provided value is 0, this.Super('parseValueExpressions', [value, fieldName, operator]) will return undefined. This happens because of a bug in smartclient's implementation of the
parseValueExpressions function. This code is placed at the beginning of that function:

if (!value) value = this.getValue();
if (!value) return;
if (!isc.isA.String(value)) value += "";

If the provided value is 0, the value will be taken from this.getValue(). The returned value will again be evaluated to false, so the function will not return any value. Right after that, there is a comman
d to convert the provided value to String.

To fix this, in the call to this.Super('parseValueExpressions'), the string representation of the number will be passed instead of its numerical value. This way smartclient will accept the value and will n
ot return undefined. Smartclient was already converting the passed values to String, so there is no risk there.

The value passed to the OBNumberItem.parseValueExpressions is not modified to prevent unexpected consequences. A copy of it is converted to string and passed to the this.Super('parseValueExpressions') func
tion.

[1] https://code.openbravo.com/erp/devel/pi/rev/d9ce373c75dad51598fb943d75e4d8e56f1d56eb

Wed, 11 Mar 2015 13:23:31 +0100Related to issue 29250: Added a clear inside the loop
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 11 Mar 2015 13:23:31 +0100] rev 26445
Related to issue 29250: Added a clear inside the loop

Added a clear inside the loop to avoid performance problems

Wed, 11 Mar 2015 11:48:22 +0530Fixes Issue 29250:It is not possible to change currency in header tab in G/L Journal
Atul Gaware <atul.gaware@openbravo.com> [Wed, 11 Mar 2015 11:48:22 +0530] rev 26444
Fixes Issue 29250:It is not possible to change currency in header tab in G/L Journal

As there is trigger mutating error, updation of gl journal line currency and
currency rate is moved to a event handler from gl_journal_trg trigger.

Tue, 10 Mar 2015 16:04:26 +0100Related to issue 29148
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 10 Mar 2015 16:04:26 +0100] rev 26443
Related to issue 29148

If total selected amount is less than bank statement line amount,
the actual payment should be the bank statement line amount
and the difference should be consider overpayment.

Tue, 10 Mar 2015 13:01:12 +0100fixed bug 29217: can't prevent filtering FK by identifier from Grid Configuration
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 10 Mar 2015 13:01:12 +0100] rev 26442
fixed bug 29217: can't prevent filtering FK by identifier from Grid Configuration

It was not possible to prevent filtering FKs by identifier using Grid Configuration
because the js code added to ensure backwards compatibility for manual datasources
was trying to find this property in an incorrect place which was undefined, causing
a js exception which prevented the flow to continue.

Tue, 10 Mar 2015 12:20:08 +0100Fixes issue 29214: Filtering multiple products work in Return from/to P&E
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 10 Mar 2015 12:20:08 +0100] rev 26441
Fixes issue 29214: Filtering multiple products work in Return from/to P&E

The problem was that the HQL WHERE clause built by the AdvancedQueryBuilder was not proper, as it where using join aliases that where not present in the FROM clause. This happened when the AdvancedQueryBuilder was used in the HQLDataSourceService class, because that class uses the WHERE clause returned by the AdvancedQueryBuilder, and the HQL FROM clause defined in the application dictionary. The resulting HQL query was like this:

SELECT iol.id as id, ...
FROM OrderLine AS ol LEFT JOIN ol.salesOrder AS o
WHERE ...
AND (( join_0.id = :alias_0 or join_0.id = :alias_1 ) )

The first two lines are built using the HQL transformers based on the HQL defined in the application dictionary, and the last two lines are built using the AdvancedQueryBuilder. The WHERE clause uses a join alias (join_0) that is not defined in the FROM clause

The new join alias was created in the resolveJoins method, that was invoked when the criteria contained an OR operator. To fix this issue, a new flag, creatingJoinsInWhereClauseIsPrevented, has been added. If this flag is true, instead of creating a new join alias for the where clause, the clause will be built using the entity main alias and the property name. As for now this new flag is only set to true in the HqlDataSourceService class.

Tue, 10 Mar 2015 11:11:51 +0100Related to issue 29199
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Tue, 10 Mar 2015 11:11:51 +0100] rev 26440
Related to issue 29199
Problem with generated classes

Fri, 06 Mar 2015 08:10:31 +0100fixed issue 29155: added log on table recreation when updating database
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 06 Mar 2015 08:10:31 +0100] rev 26439
fixed issue 29155: added log on table recreation when updating database

Thu, 26 Feb 2015 15:29:20 +0100Fixes bug 29194: Division by zero error managed in Costing Background.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 26 Feb 2015 15:29:20 +0100] rev 26438
Fixes bug 29194: Division by zero error managed in Costing Background.

Under certain circumnstance a division by zero error was happening in Cost Adjustments process inside Costing Background (when calculating backdated adjustments of a transaction of movementqty zero). This problem has been managed by being sure that this division will not happen again. If the movementqty of the transaction is zero, the cost of the full transaction will be zero as well.

Tue, 17 Feb 2015 17:25:49 +0100Fixes Bug 29193: Cost properly calculated for orphan lines in Cost Adjustments
Unai Martirena <unai.martirena@openbravo.com> [Tue, 17 Feb 2015 17:25:49 +0100] rev 26437
Fixes Bug 29193: Cost properly calculated for orphan lines in Cost Adjustments

The process was failing for orphan lines because it was trying to get the cost from a Purchase Price or an Standard Cost, and there is none. Before checking those two, the process now tries to find an Average Cost for that product on the movement date of the orphan line, and if it founds it assigns to the transaction.

Mon, 09 Mar 2015 17:43:39 +0100Fixed bug 29148 It is not possible to create PaymentOut from "match statement"
Sandra Huguet <sandra.huguet@openbravo.com> [Mon, 09 Mar 2015 17:43:39 +0100] rev 26436
Fixed bug 29148 It is not possible to create PaymentOut from "match statement"

It is not possible to create Payment Out from "match statement" using
a G/L item.