Thu, 14 May 2015 17:24:16 +0200Fixes issue 29889 & Fixes issue 29887: Error in Price Correction Background
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 14 May 2015 17:24:16 +0200] rev 26697
Fixes issue 29889 & Fixes issue 29887: Error in Price Correction Background

IsCostCalculated will not be considered to set CheckPriceDifference flag, when completing an invoice.
Instead, when running Price Correction Background, transactions will be filtered by IsCostCalculated to avoid calculate price differences in transactions where cost has not been calculated.

Fri, 15 May 2015 12:01:31 +0200Fixes issue 29899: False positives in GLJournalAccountingCheck validation
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Fri, 15 May 2015 12:01:31 +0200] rev 26696
Fixes issue 29899: False positives in GLJournalAccountingCheck validation
Missing ad_table_id constraint ends up in wrong validation when there are old records using numeric values for ids.

Thu, 14 May 2015 17:12:18 +0200Related to bu 29891: Adjust costing tests to the new behavior
Unai Martirena <unai.martirena@openbravo.com> [Thu, 14 May 2015 17:12:18 +0200] rev 26695
Related to bu 29891: Adjust costing tests to the new behavior

Thu, 14 May 2015 17:11:31 +0200Fixes bug 29891: Total Movement qty fixed in costing tab with backdated trx
Unai Martirena <unai.martirena@openbravo.com> [Thu, 14 May 2015 17:11:31 +0200] rev 26694
Fixes bug 29891: Total Movement qty fixed in costing tab with backdated trx

While working with cost adjustments, on certain cases the existing Costing records changes. This can happen because the cost has been recalculated due to backdated transactions, price adjustments, manual cost corrections, etc. In all this cases the 'Total Movement Quantity' field was not being correctly updated.
This field has to store the current stock of the product on that moment. So, each time the costing record is updated it is being checked if this value changes, and if it has changed the current stock is set.

Mon, 11 May 2015 10:53:02 +0200Fixes bug 29838: Prevents unlimited datasource requests when filtering the grid
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 11 May 2015 10:53:02 +0200] rev 26693
Fixes bug 29838: Prevents unlimited datasource requests when filtering the grid

The problem was that the logic to check that if a datasource request was triggered by scrolling up in a grid that did not have its initial rows loaded (see [1]) did not work well when the user filtered the grid after having scrolled down the grid till loading its second page. This caused the totalRows property of the grid to be miscalculated, and this triggered the undefinite amount of datasource requests.

The logic to check if the request was triggered by scrolling up has been changed. Now, instead of checking low-level smartclient properties like lastScrollTop, we check if there are rows loaded in the positions just after the page that was just received. Only in that case we want to prevent resetting the totalRows property of the ResultSet with the value returned by the datasource.

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

Fri, 08 May 2015 14:02:09 +0200Fixed bug 29827: Open/Close Period Control shows calendars associated to organizations
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Fri, 08 May 2015 14:02:09 +0200] rev 26692
Fixed bug 29827: Open/Close Period Control shows calendars associated to organizations

The Open/Close Period Control window was showing all the periods available at the C_Period table.
The target of this window is to open/close periods in fiscal calendars, so it should only show periods belonging to a fiscal calendar linked to an organization set as ready.

The fix has 2 parts:
1. Added a hql where clause to include only periods belonging to a fiscal calendar linked to an organization set as ready.
2. The hql filter clause was wrong because it was filtering by the c_period.ad_org_id. Instead it should be filtering by the organization linked to the calendar's periods

Thu, 07 May 2015 12:11:39 +0200Fixed bug 29808: Impossible to create several calendars for the same organization
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Thu, 07 May 2015 12:11:39 +0200] rev 26691
Fixed bug 29808: Impossible to create several calendars for the same organization

Two pieces of code were affected by this bug:
PeriodEventHandler.java: EntityPersistenceEventObserver in charge of checking overlap in manual inserts/updates (or any java process) in c_period table
C_YEARPERIODS: db function associated to the create periods process inside the Fiscal Calendar | Year tab. It also verifies the periods don't overlap other periods.

The fix consists in checking that there is no date overlap per calendar. Before this fix the calendar wasn't taken into account, so it was not possible to define several calendars for the same organization with the same periods.

Mon, 11 May 2015 10:15:38 +0200Fixes bug 29836: Avoid creating unnecessary backdated adjustments.
Unai Martirena <unai.martirena@openbravo.com> [Mon, 11 May 2015 10:15:38 +0200] rev 26690
Fixes bug 29836: Avoid creating unnecessary backdated adjustments.

The problem was happening when costing precision was different from standard precision. When calculating the expected cost of a transaction to know if an adjustment is necessary to be created, it has to be rounded to standard precision because the amounts always have to be created in standard precision. In this case, while comparing expected cost with actual cost from database, as in database values are rounded to standard precision, and expected cost was being rounded to cost precission, an adjustment was being created with the difference, that corresponds just to the precision lost, and finally an adjustment of Zero amount was being created.

Wed, 06 May 2015 11:09:24 +0200Fixed bug 29780 The done button appears disabled when it should not
Sandra Huguet <sandra.huguet@openbravo.com> [Wed, 06 May 2015 11:09:24 +0200] rev 26689
Fixed bug 29780 The done button appears disabled when it should not

null parameter when it should be the view in recalcDisplayLogicOrReadOnlyLogic
call in updateDifference function

Thu, 21 May 2015 09:19:25 +0000Merge temporary head for 3.0PR15Q1.4
RM packaging bot <staff.rm@openbravo.com> [Thu, 21 May 2015 09:19:25 +0000] rev 26688
Merge temporary head for 3.0PR15Q1.4