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 25694
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 25693
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 25692
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 25691
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 25690
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 25689
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 25688
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 25687
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 25686
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 25685
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.