Tue, 27 Jan 2015 17:19:36 +0100Fixed bug 28780: Return to Vendor fails when unit price is zero or empty
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 27 Jan 2015 17:19:36 +0100] rev 25835
Fixed bug 28780: Return to Vendor fails when unit price is zero or empty

after refactoring, when Unit Price is empty in the pick&edit
in SRMOPickEditLines.java class UnitPrice value comes as empty string,
before refactoring this value was null.

Wed, 28 Jan 2015 17:37:00 +0100Related to issue 28755: Fix copyright
Unai Martirena <unai.martirena@openbravo.com> [Wed, 28 Jan 2015 17:37:00 +0100] rev 25834
Related to issue 28755: Fix copyright

Tue, 27 Jan 2015 13:16:28 +0100Fixed bug 28755 It is impossible leaving credit when adding a payment in match statement
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 27 Jan 2015 13:16:28 +0100] rev 25833
Fixed bug 28755 It is impossible leaving credit when adding a payment in match statement

Properly default value in actual payment field when add payment popup
runs from match statement.

Disabled "+" button and "magnifying glass" when line record is
linked to a transaction.

Fri, 23 Jan 2015 12:21:36 +0100Fixed issue 28722: Not possible to create invoiced receipts for customers created in WebPOS
Aaron Calero <aaron.calero@openbravo.com> [Fri, 23 Jan 2015 12:21:36 +0100] rev 25832
Fixed issue 28722: Not possible to create invoiced receipts for customers created in WebPOS

Modified the event handler used to set the BP currency to work not only on update events, but on save events too.
Now when BPs are saved from the POS, the currency is automatically assigned to these business partners and they can be used to generate invoices.

Mon, 26 Jan 2015 13:13:50 +0100Fixed issue 28766: Updated the list of recommended browsers:
David Baz Fayos <david.baz@openbravo.com> [Mon, 26 Jan 2015 13:13:50 +0100] rev 25831
Fixed issue 28766: Updated the list of recommended browsers:
Mozilla Firefox 31 (latest ESR)
Google Chrome: 40
Internet Explorer: 11
Apple Safari: 8

Thu, 22 Jan 2015 11:14:24 +0100fixed bug 28720: callouts incorrectly set big non integer numbers
Asier Lostalé <asier.lostale@openbravo.com> [Thu, 22 Jan 2015 11:14:24 +0100] rev 25830
fixed bug 28720: callouts incorrectly set big non integer numbers

When a big non integer number was set by a callout, decimal separator was removed
resulting in a different number, ie. 10200500.45 resulted in 1020050045.00.

The problem was in the OB.Utilities.Number.ScientificToDecimal JavaScript function
which wrongly assumed scientific exponent always added zeroes to coefficient, which
is not true in this case where exponent determines where the decimal separator is
inserted in the coefficient.

Fri, 16 Jan 2015 12:56:53 +0100Fixes bug 28643: Currency now is setted correctly in Transaction tab.
Unai Martirena <unai.martirena@openbravo.com> [Fri, 16 Jan 2015 12:56:53 +0100] rev 25829
Fixes bug 28643: Currency now is setted correctly in Transaction tab.

Default value assigned to Currency column in transaction tab, that was not done during Transaction tab refactor project.

Thu, 15 Jan 2015 18:16:20 +0100Fixed bug 28632 created colour status field in open/close period control
Sandra Huguet <sandra.huguet@openbravo.com> [Thu, 15 Jan 2015 18:16:20 +0100] rev 25828
Fixed bug 28632 created colour status field in open/close period control

created colour status field in open/close period control that
was deleted by mistake in a project merge

Mon, 19 Jan 2015 14:42:57 +0100Fixed issue 28623: Window's behaviour changes when creating a new record.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Mon, 19 Jan 2015 14:42:57 +0100] rev 25827
Fixed issue 28623: Window's behaviour changes when creating a new record.

When a window is opened using the "quick create new" widget, the same window in the recent views layout
does not allow to create a new record (the green small button for creating a new record, which should be
by the window name, disappears).

The problem was in the "ob-utilities.js", inside the "{OB.Utilities.openView}" function, the logic for
setting the "singleRecord" value (this is the Edit Only attribute) was wrong. If the value of the
variable singleRecord of that function was undefined or null, as it was in the case of clicking the "quick create new"
widget, that value was set to true and the window became an "edit only" window.That was why the small
green "create new" icon disappeared from the recent views layout.

For fixing this the condition has been removed, so we know that the value of the variable "singleRecord" is not
going to be modified and it will be set correctly.

Wed, 14 Jan 2015 18:44:36 +0100Fixed bug 28618 Added OB.Reservation.QuantityValidate to quantity field
Sandra Huguet <sandra.huguet@openbravo.com> [Wed, 14 Jan 2015 18:44:36 +0100] rev 25826
Fixed bug 28618 Added OB.Reservation.QuantityValidate to quantity field

OB.Reservation.QuantityValidate is missing after after stock
reservation refactor

Wed, 21 Jan 2015 13:29:26 +0530Related to Issue 28591:Removed unwanted code from the modulescript to update
Atul Gaware <atul.gaware@openbravo.com> [Wed, 21 Jan 2015 13:29:26 +0530] rev 25825
Related to Issue 28591:Removed unwanted code from the modulescript to update
payment plan and payment plan details

Tue, 20 Jan 2015 14:57:35 +0530Fixes Issue 28591:Reversing a payment is creating wrong invoice payment plan
Atul Gaware <atul.gaware@openbravo.com> [Tue, 20 Jan 2015 14:57:35 +0530] rev 25824
Fixes Issue 28591:Reversing a payment is creating wrong invoice payment plan
details

Problem is Schedule detail was being updated by payment amount now it is taken
care to update using individual schedule detail amount while creating reverse
payment schedule and payment schedule details. Modulescript to fix errorneous data
consists of update invoice paid, outstanding amt, update payment schedule received
and outstanding amount, update payment credit generated info if in case required.

Mon, 12 Jan 2015 18:07:06 +0100Fixed bug 28560 Cannot modify alternate taxableamt of invoice and order lines
Sandra Huguet <sandra.huguet@openbravo.com> [Mon, 12 Jan 2015 18:07:06 +0100] rev 25823
Fixed bug 28560 Cannot modify alternate taxableamt of invoice and order lines

Backout of commit that caused the regression(27562) and fixed taxable amount for not
stocked bom lines is not calculated in M_EXPLODEBOMNOTSTOCK
and M_INVEXPLODEBOMNOTSTOCK procedures

Fri, 09 Jan 2015 15:18:45 +0100fixed bug 28552: big numbers are changed in some cases
Asier Lostalé <asier.lostale@openbravo.com> [Fri, 09 Jan 2015 15:18:45 +0100] rev 25822
fixed bug 28552: big numbers are changed in some cases

Big numbers are modified in case their scientific notation represntation ends
with zeros, trailing zeros were removed. So, ie., 3.5E10 was changed to 3.5E1
this is: 3.5.

The problem was caused by fix for #26132 which tries to transform scientific to
decimal notation (and then remove trailing zeros, which is correct). But it
expected 3.5E+10 instead of 3.5E10, so in latter case, which is actually used
it didn't do the transformation.

The fix accepts scientific notation with both + and no +.

Thu, 29 Jan 2015 19:04:28 +0100Fixes bug 28814: NPE fixed in Costing Background for a production product
Unai Martirena <unai.martirena@openbravo.com> [Thu, 29 Jan 2015 19:04:28 +0100] rev 25821
Fixes bug 28814: NPE fixed in Costing Background for a production product

When a product is defined as production the costing records created in the system are always for * organization. If a transaction of this product it was creating a backdated cost adjustment, in one place of the code a NPE exception error was happening because a costing record of legal entity org it was being trying to get. This has been fixed always filtering by client instead of organization when the product is of production type.

Tue, 27 Jan 2015 20:10:56 +0100Related to issue 28792: Uncomment a piece of code
Unai Martirena <unai.martirena@openbravo.com> [Tue, 27 Jan 2015 20:10:56 +0100] rev 25820
Related to issue 28792: Uncomment a piece of code

Tue, 27 Jan 2015 20:08:23 +0100Fixes bug 28792: Null Pointer exception now is avoided in Costing Background
Unai Martirena <unai.martirena@openbravo.com> [Tue, 27 Jan 2015 20:08:23 +0100] rev 25819
Fixes bug 28792: Null Pointer exception now is avoided in Costing Background


The problem was in AverageCostAdjustment java process while calling AverageAlgorithm.getProductCost method. While returning null, Null Pointer Exception error was raised.

Tue, 13 Jan 2015 17:52:27 +0100Related to issue 28531 Update Copyright
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 13 Jan 2015 17:52:27 +0100] rev 25818
Related to issue 28531 Update Copyright

Mon, 12 Jan 2015 12:07:15 +0100Fixes bug 28563: Filters in Match LC Costs P&E now are working
Unai Martirena <unai.martirena@openbravo.com> [Mon, 12 Jan 2015 12:07:15 +0100] rev 25817
Fixes bug 28563: Filters in Match LC Costs P&E now are working

This grid has been implemented using an hql query based table. The entity alias field was empty for all this columns, and it is necessary to correct implementation of the filtering, so the left part of the select has been added on all of them.

Tue, 13 Jan 2015 10:50:29 +0100fixed bug 28565: not possible to filter by LineNo field in Match LC Cost
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 13 Jan 2015 10:50:29 +0100] rev 25816
fixed bug 28565: not possible to filter by LineNo field in Match LC Cost

The problem was caused by a reference mistmatch between lineNo property in HQL
table, which was correctly Integer, and the reference for the M_LC_Cost.lineNo
which was Number.

Fixed M_LC_Cost.lineNo to be Integer.

Tue, 13 Jan 2015 09:58:54 +0100fixed bug 28530: can't enter 2nd matched amount in Match LC Costs
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 13 Jan 2015 09:58:54 +0100] rev 25815
fixed bug 28530: can't enter 2nd matched amount in Match LC Costs

When trying to edit the 2nd line in Match LC Costs, UI didn't allow to enter
then matched amount field. After this failure it was needed to reload the
whole page in order make it work again.

The problem was in this situation validation for amount fields is triggered for
all selected records including the new one where the amount is '', it was tried
to be converted to BigDecimal resulting on a JavaScript exception thrown.

Fix check if the amount has a value (or 0) to only sum it in this case.

Wed, 14 Jan 2015 09:39:32 +0100Fixes bug 28554: No error is shown now in oracle creating LC from Goods receipt
Unai Martirena <unai.martirena@openbravo.com> [Wed, 14 Jan 2015 09:39:32 +0100] rev 25814
Fixes bug 28554: No error is shown now in oracle creating LC from Goods receipt

The problem was in 'SELECT PROCESSED INTO v_Processed FROM M_LandedCost WHERE M_landedcost_ID=v_M_LandedCost_ID' statement. If no result is given in the select, in postgres no value is inserted in v_Processed but it works, but in oracle it fails. To fix this an check has been added to execute this statement only when v_M_LandedCost_ID is not null.
An if statement has been added in case v_M_LandedCost_ID is null and v_m_Inout_ID is not (Goods Receipt window), to prevent adding, updating or inserting Landed Cost Cost records when the Goods Receipt is processed.
Finally, in case of updating, the restriction of not being able to change landed cost header has been removed. This was causing problems when launching Cost Background for a Goods Receipt with Landed Cost Cost records, because this process creates the Landed Cost Header and assigns to Landed Cost Cost records.

Thu, 08 Jan 2015 13:08:27 +0100Related to issue 28534: Fix Copyright
Unai Martirena <unai.martirena@openbravo.com> [Thu, 08 Jan 2015 13:08:27 +0100] rev 25813
Related to issue 28534: Fix Copyright

Thu, 08 Jan 2015 12:50:05 +0100Related to Bug 28531: Fix backdated is not correctly set with big amount of data
Unai Martirena <unai.martirena@openbravo.com> [Thu, 08 Jan 2015 12:50:05 +0100] rev 25812
Related to Bug 28531: Fix backdated is not correctly set with big amount of data

createCostingRuleInits method inside CostingRuleProcess.java cleares session every 100 records, and if this happens then the reference to current Costing Rule is missed, so the code that sets the fix backdated from is not properly done (rule.setFixbackdatedfrom(startingDate)). To avoid this the Fix Backdated From is set before creating Costing Rule Inventories.

Thu, 08 Jan 2015 12:30:31 +0100Fixes Bug 28534: Fix Backdated From is now displayed properly.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 08 Jan 2015 12:30:31 +0100] rev 25811
Fixes Bug 28534: Fix Backdated From is now displayed properly.

'Fix Backdated From' now is only displayed when 'Backdated Transactions Fixed' is set to Yes.
Also a callout has been added to clear the value in 'Fix Backdated From' when is hidden.

Wed, 07 Jan 2015 19:31:01 +0100Fixes bug 28531: Fix Backdated fails when backdated from is before starting date.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 07 Jan 2015 19:31:01 +0100] rev 25810
Fixes bug 28531: Fix Backdated fails when backdated from is before starting date.

A check has been added to be sure that fix backdated from date is not earlier than starting date of the costing rule.
Also some code has been changed to handle correctly the error messages and return them properly to the user.
Finally the reference of Fix Backdated From Parameter in Fix Backdated Transactions Process Definitio has been changed from Date to DateTime.

Wed, 31 Dec 2014 16:16:00 +0100Fixes Bug 28487: Fixed Null Pointer Exception.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 31 Dec 2014 16:16:00 +0100] rev 25809
Fixes Bug 28487: Fixed Null Pointer Exception.

The problem was that in updateBDCostingTimeRange function inside AverageCostAdjustment class, the code was trying to get the movement date of a Inventory Transaction related to a Costing record. But not all costing have Inventory Transaction, so it was giving a NPE.
Now, if there is a previous Costing record than the one created due to a backdated transaction, this Costing will be shortened till transaction process date, and the new Backdated costing record will start at that moment.
This only happens the first time that a related transaction is found that is not a backdated transaction, because if is done with a backdated transaction time overlap can happen.

Wed, 31 Dec 2014 13:50:58 +0100Fixes bug 28509: Inventory Amt Update now works with negative stock.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 31 Dec 2014 13:50:58 +0100] rev 25808
Fixes bug 28509: Inventory Amt Update now works with negative stock.

In this case the Qty Count and Qty Book have been reverted in the Physical Inventory Lines and negate them to make them positive, maintaining the difference between them to create the same transaction quantity.

Also getInventoryClosingCost function in AverageAlgorithm has been changed to negate the cost obtained from an inventory closing when the movement qty is positive (closing from negative to 0), because the cost obtained was negative, and this is wrong.

Wed, 31 Dec 2014 11:03:15 +0100Fixes bug 28502: Inv Amt Update takes into account Costing Rule warehouse dim
Unai Martirena <unai.martirena@openbravo.com> [Wed, 31 Dec 2014 11:03:15 +0100] rev 25807
Fixes bug 28502: Inv Amt Update takes into account Costing Rule warehouse dim

The problem was that the process was checking if the warehouse in Inventory Amount Update is null or not, and if not, it uses it. This is correct when the Costing Rule is set as Warehouse Dimension, but if is not, it should not use it, and even if the Costing Rule is not set as Warehouse Dimension and the warehouse field is hidden in Inventory Amount Lines, it is filled with the Warehouse set in session value.

Wed, 07 Jan 2015 10:18:24 +0100Fixes bug 28519:OrganizationStructureProvider.initialize should be synchronized
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 07 Jan 2015 10:18:24 +0100] rev 25806
Fixes bug 28519:OrganizationStructureProvider.initialize should be synchronized

The method OrganizationStructureProvider.initialize should be synchronized, because otherwise it could be executed concurrently. The first thing the method does it to check if it the OrganizationStructureProvider has been already initialized, but this is not enough to prevent the concurrent initializations.

One of the consequences of the concurrent initializations is that the three maps used in that method (naturalTreesByOrgID, parentByOrganizationID and childByOrganizationID) can be left in an inconsistent state, resulting in the a 100% CPU usage when trying to access them.