Tue, 30 Dec 2014 11:04:15 +0100Merge back from main
RM packaging bot <staff.rm@openbravo.com> [Tue, 30 Dec 2014 11:04:15 +0100] rev 25647
Merge back from main

Mon, 22 Dec 2014 16:41:58 +0000Added signature for changeset 53cc6ea75bb1
RM packaging bot <staff.rm@openbravo.com> [Mon, 22 Dec 2014 16:41:58 +0000] rev 25646
Added signature for changeset 53cc6ea75bb1

Mon, 22 Dec 2014 16:41:58 +0000Added tag 3.0PR14Q4 for changeset ed3565630685
RM packaging bot <staff.rm@openbravo.com> [Mon, 22 Dec 2014 16:41:58 +0000] rev 25645
Added tag 3.0PR14Q4 for changeset ed3565630685

Mon, 22 Dec 2014 16:41:58 +0000Update AD_MODULE version to 3.0PR14Q4 3.0PR14Q4
RM packaging bot <staff.rm@openbravo.com> [Mon, 22 Dec 2014 16:41:58 +0000] rev 25644
Update AD_MODULE version to 3.0PR14Q4

Wed, 17 Dec 2014 17:14:25 +0100fixed bug 28386: keep selected item when reopening FK drop down
Asier Lostalé <asier.lostale@openbravo.com> [Wed, 17 Dec 2014 17:14:25 +0100] rev 25643
fixed bug 28386: keep selected item when reopening FK drop down

Tue, 16 Dec 2014 14:57:28 +0100fixed bug 28386: FK filter dropdown hides elements when it's reopened
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 16 Dec 2014 14:57:28 +0100] rev 25642
fixed bug 28386: FK filter dropdown hides elements when it's reopened

When a FK filter drop down was reopened after having selected an element, it
only displayed that element in the list.

Few things have been fixed:
* When requesting datasource for FK drop down, the same criteria used in the
grid is used, but removing that drop down criterion. This was not properly
done for direct FK selection
* == element before the identifier was some times removed
* When reopening a drop down having an element selected, the criteria was changed
from equals with FK value to iEquals with identifier value

Mon, 01 Dec 2014 16:50:51 +0100Fixes bug 28308 LandedCost Accounting should always be created in the same order
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 01 Dec 2014 16:50:51 +0100] rev 25641
Fixes bug 28308 LandedCost Accounting should always be created in the same order

In order to help JUnit tests assert landed cost accounting, an orderBy clause has been added when creating Landed Cost Accounting lines, to be created always in the same order

Mon, 01 Dec 2014 16:54:02 +0100Fixes bug 28266 ParentCostAdjustmentLine should always be assigned in the same order
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 01 Dec 2014 16:54:02 +0100] rev 25640
Fixes bug 28266 ParentCostAdjustmentLine should always be assigned in the same order

In order to help JUnit tests assert Cost Adjustment lines, an orderBy clause has been added when assigning the field "Parent Cost Adjustment Line" to follow always the same order

Mon, 01 Dec 2014 16:55:05 +0100Related to Issue 28148 Cost Adjustment Lines created ordered by trxprocessdate
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 01 Dec 2014 16:55:05 +0100] rev 25639
Related to Issue 28148 Cost Adjustment Lines created ordered by trxprocessdate

In order to help JUnit tests assert Cost Adjustment lines, an orderBy clause has been added when creating cost adjustment lines of type Landed Cost to follow always the same order

Fri, 05 Dec 2014 14:11:17 +0100Related to bug 28286 LandedCostLineAmt should always be created in the same order
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 05 Dec 2014 14:11:17 +0100] rev 25638
Related to bug 28286 LandedCostLineAmt should always be created in the same order

The field in the order by clause must appear in the group by clause to prevent fail in Postgresql 8.4

Mon, 01 Dec 2014 16:49:43 +0100Fixes bug 28286 LandedCostLineAmt should always be created in the same order
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 01 Dec 2014 16:49:43 +0100] rev 25637
Fixes bug 28286 LandedCostLineAmt should always be created in the same order

In order to help JUnit tests assert landed cost, an orderBy clause has been added when creating Landed Cost Receipt Line Amount lines, to be always created in the same order.

Thu, 11 Dec 2014 14:13:06 +0100Fixes bug 28387 BillofMaterialsAccounting should always be created in the same order
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 11 Dec 2014 14:13:06 +0100] rev 25636
Fixes bug 28387 BillofMaterialsAccounting should always be created in the same order

In order to help JUnit tests assert Bill of Materials Production accounting, an orderBy clause has been added when creating Bill of Materials Production Accounting lines, to be created always in the same order

Thu, 18 Dec 2014 14:33:34 +0100[Costing]Related to issue 28333 Data needed in demodata for CostAdjustment test
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 18 Dec 2014 14:33:34 +0100] rev 25635
[Costing]Related to issue 28333 Data needed in demodata for CostAdjustment test

Thu, 18 Dec 2014 14:18:27 +0100[Costing]Related to issue 28333 Data needed in demodata for CostAdjustment test
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Thu, 18 Dec 2014 14:18:27 +0100] rev 25634
[Costing]Related to issue 28333 Data needed in demodata for CostAdjustment test

Enable M_LandedCost, M_LC_Cost and M_LC_Type tables in sampledata dataset

Tue, 16 Dec 2014 13:10:41 +0100[Costing] Fixes issue 28333: Data needed in demodata for CostAdjustment test
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 16 Dec 2014 13:10:41 +0100] rev 25633
[Costing] Fixes issue 28333: Data needed in demodata for CostAdjustment test

Thu, 18 Dec 2014 13:29:41 +0100Fixes Issue 28450: Costing Migration Process does not fail any more.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 18 Dec 2014 13:29:41 +0100] rev 25632
Fixes Issue 28450: Costing Migration Process does not fail any more.

In the function insertTrxCosts() in CostingMigrationProcess.java while inserting m_transaction_cost records the column dateacct is filled in the following way:
* If the transaction is a goods shipment line, with the accounting date of the Shipment.
* If the transaction is not a goods shipment line, with the movement date of the transaction.

Wed, 17 Dec 2014 18:33:43 +0100Fixes Bug 28441:Validate Costing Rule doesn't fail if there prev transactions.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 17 Dec 2014 18:33:43 +0100] rev 25631
Fixes Bug 28441:Validate Costing Rule doesn't fail if there prev transactions.

The process was failing while trying to create Transaction Cost records in initializeOldTrx and updateInventoriesCostAndProcessInitInventories processes. It was not setting any value to accounting date column, which is mandatory. This column has been populated in the following way: If the related transaction is a shipment the accounting date of the shipment is assigned, if not, the movement date of the transaction will be assigned.

Wed, 17 Dec 2014 16:22:29 +0100Fixes bug 28401:Initialized All Trx process not uses movement date.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 17 Dec 2014 16:22:29 +0100] rev 25630
Fixes bug 28401:Initialized All Trx process not uses movement date.

Initialize Old Transaction process inside Validate Costing Rule process should filter by Movement Date of Transactions instead of Transaction Process Date

Fri, 19 Dec 2014 15:07:05 +0100Related to issue 28289: Improve @FixBackdateFromBeforeStartingDate@ message
Unai Martirena <unai.martirena@openbravo.com> [Fri, 19 Dec 2014 15:07:05 +0100] rev 25629
Related to issue 28289: Improve @FixBackdateFromBeforeStartingDate@ message

Fri, 19 Dec 2014 13:15:14 +0100Related to bug 28289:Do @FixBackdateFromBeforeStartingDate@ later in the process.
Unai Martirena <unai.martirena@openbravo.com> [Fri, 19 Dec 2014 13:15:14 +0100] rev 25628
Related to bug 28289:Do @FixBackdateFromBeforeStartingDate@ later in the process.

Check the validation at the end of the Costing Rule Validation process when fixbackdated from and starting date are being initialized.
Also update the error message displayed.

Wed, 17 Dec 2014 21:45:17 +0100Related to issue 28289: Little code review
Unai Martirena <unai.martirena@openbravo.com> [Wed, 17 Dec 2014 21:45:17 +0100] rev 25627
Related to issue 28289: Little code review

Wed, 17 Dec 2014 13:56:07 +0100Fixes Bug 28289: Manage null start and fix backdated from dates in Costing Rule.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 17 Dec 2014 13:56:07 +0100] rev 25626
Fixes Bug 28289: Manage null start and fix backdated from dates in Costing Rule.

Several things have been implemented in this changeset:
* A new Process Definition called 'Validate Costing Rule' has been created that replaces the old Process with the same name. This has been done to be able to use the new capabilities that these new kind of processes offer, like validations before executing the process and the posibility to show a confirmation popup. The new process action handler calls the old process java class, so all existing modules that may call or extend the old class they will continue working.
* The CostingRuleEventHandler has been removed, because it was doing a wrong validation and the fix backdated from date is managed in the CostingRuleProcess.
* 2 new functions have been created in CostingUtils ('getCostingRuleStartingDate' and 'getCostingRuleFixBackdatedFrom') that they return '01/01/1900' as costing rule Starting Date or Fix Backdated From when these are null. This has been done because in some places when these dates are null the application was giving an error. So, every time these dates are retrieved, these functions will be called.
* A validation has been added before executing the new Action Handler 'Validate Costing Rule' that shows a popup when transactions without cost calculated are found in closed periods. It asks for confirmation to proceed or the option to cancel.

Tue, 09 Dec 2014 10:03:20 +0100Fixes Bug 28289:Add Starting Date and Fix Backdated From allways to Costing Rule
Unai Martirena <unai.martirena@openbravo.com> [Tue, 09 Dec 2014 10:03:20 +0100] rev 25625
Fixes Bug 28289:Add Starting Date and Fix Backdated From allways to Costing Rule

Modify CostingRuleEventHandler.java to allways set an Starting Date and Fix Backdated From to a Costing Rule if it has not been added manually. Take as Starting Date the Starting Date of the first period that is opened. Set the same date as Fix Backdated From.

Fri, 05 Dec 2014 08:33:57 +0100Related to Issue 28301: Fix on updateBDCostingTimeRange function.
Unai Martirena <unai.martirena@openbravo.com> [Fri, 05 Dec 2014 08:33:57 +0100] rev 25624
Related to Issue 28301: Fix on updateBDCostingTimeRange function.

If the movement date of the inventory transaction related to current costing record is before the movement date of the inventory transaction related to backdated costing record, then the backdated costing record would be the current costing record. In other case the current costing record would remain as current costing record.

Thu, 04 Dec 2014 11:37:10 +0100Fixes Issue 28301: Cost is properly calculated after two backdated transactions.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 04 Dec 2014 11:37:10 +0100] rev 25623
Fixes Issue 28301: Cost is properly calculated after two backdated transactions.

The problem was in updateBDCostingTimeRange function. While updating the backdated average costing time, if a previous costing record was found, the future ending date was assigned to backdated costing record, not to the current costing, leaving as current costing the backdated costing record, and this is wrong.

Fri, 19 Dec 2014 12:01:16 +0100Related to bug 28389: If is no diff in match LCC leave LCC amount as matchedAmt
Unai Martirena <unai.martirena@openbravo.com> [Fri, 19 Dec 2014 12:01:16 +0100] rev 25622
Related to bug 28389: If is no diff in match LCC leave LCC amount as matchedAmt

Thu, 18 Dec 2014 18:36:08 +0100Related to Issue 28389: Fixed Posting of LC Cost with Invoice Line
Unai Martirena <unai.martirena@openbravo.com> [Thu, 18 Dec 2014 18:36:08 +0100] rev 25621
Related to Issue 28389: Fixed Posting of LC Cost with Invoice Line

While processing a Landed Cost with an Invoice in a Landed Cost Cost it, if the invoice has an exchange rate different from the system, a new Cost Adjustment is created with that difference between the rates. But this difference it was not taking into account while setting the matched amount in Landed Cost Cost, so the Post process it was not working well.

Tue, 16 Dec 2014 18:34:37 +0100fixed issue 28389: the difference amount is calculated adding the amount of all lines
Miguel A. Alsasua <miguel.alsasua@openbravo.com> [Tue, 16 Dec 2014 18:34:37 +0100] rev 25620
fixed issue 28389: the difference amount is calculated adding the amount of all lines

the difference amount between the cost amount and matched amount was wrong calculated when there was more than one line in landed cost cost tab

Thu, 04 Dec 2014 12:20:59 +0100Fixes issue 28192: Net Unit Price now is properly calculated.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 04 Dec 2014 12:20:59 +0100] rev 25619
Fixes issue 28192: Net Unit Price now is properly calculated.

In order to calculate the Net Unit Price, the adjustments of the transaction are used, but it was not being used the signMultiplier of the transaction, and needs to be used.

Wed, 10 Dec 2014 14:09:54 +0100Fixes Issue 28157: Landed Cost takes into account exchange rate at invoice level
Unai Martirena <unai.martirena@openbravo.com> [Wed, 10 Dec 2014 14:09:54 +0100] rev 25618
Fixes Issue 28157: Landed Cost takes into account exchange rate at invoice level

If an exchange rate different from the System is added in Purchase Invoice and this Invoice is matched in a Landed Cost, a new record will be created in 'Matched Amount' tab under 'Landed Cost Cost' tab of 'Landed Cost' window. This new record will have the new flag of 'Is Conversion Matching' as true, and the amount will be the difference obtained from using the Invoice exchange rate compared to the one of the System.
This will create a new Cost Adjustment of source 'Landed Cost' with the same amount.