Thu, 04 Dec 2014 12:12:34 +0100Related to Issue 28113: Revert a change on issue 28115.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 04 Dec 2014 12:12:34 +0100] rev 25617
Related to Issue 28113: Revert a change on issue 28115.

In this cases the net unit price is the cost of the transaction

Fri, 05 Dec 2014 08:51:10 +0100Fixes bug 28230 Null Pointer Exception is raised when trying to post a goods receipt
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Fri, 05 Dec 2014 08:51:10 +0100] rev 25616
Fixes bug 28230 Null Pointer Exception is raised when trying to post a goods receipt

When a goods receipt with a product of type Service, which has a cost of type Standard, is posted, the DocInOut class calls the getStandardCost method from CostingUtils class with the currency of the current organization. If the organization has no currency, the client's currency will be used. Otherwise, a null pointer exception will be raised.

Thu, 04 Dec 2014 13:09:42 +0100Fixes Issue 28234: Check in Costing Rule Validation that the org has Currency.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 04 Dec 2014 13:09:42 +0100] rev 25615
Fixes Issue 28234: Check in Costing Rule Validation that the org has Currency.

If the organization has no currency defined, the costing process will use the currency defined in the client. This could be wrong if the currency for the transactions of this organization should be different that the currency of the client, so before validating a costing rule the organization of it should have a currency defined.

Thu, 04 Dec 2014 16:58:28 +0100Related to Issue 28238: Clear Goods Shipment Lines when changing Goods Shipment.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 04 Dec 2014 16:58:28 +0100] rev 25614
Related to Issue 28238: Clear Goods Shipment Lines when changing Goods Shipment.

A callout has been implemented in Goods Shipment field.

Thu, 04 Dec 2014 11:31:24 +0100Fixes Issue 28238: Cost Adjustment of Landed Cost type properly created.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 04 Dec 2014 11:31:24 +0100] rev 25613
Fixes Issue 28238: Cost Adjustment of Landed Cost type properly created.

Receipt tab of Landed Cost has been designed to work in the following way:
* either a Goods Receipt header is selected in 'Goods Receipt' field -> this option implies that specified landed cost are distributed among all Goods Receipt lines.
* or a Goods Receipt header is selected in Goods Receipt field and a Goods Receipt line 'of the very same Goods Receipt' is selected in the field 'Goods Receipt Line' -> this option implies that specified landed cost are distribute just for the Goods receipt line selected.
Above behaviour implies that Goods Receipt lines field lists only goods receipt lines of the goods receipt selected in Goods Receipt field. In order to do this a where clause has been added in Goods Receipt Lines selector to only display lines of the selected header, if no header is selected, no lines would be displayed.

Tue, 09 Dec 2014 18:59:11 +0100Fixed bug 28362 c_invoice_post creates unnecesary contentions
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 09 Dec 2014 18:59:11 +0100] rev 25612
Fixed bug 28362 c_invoice_post creates unnecesary contentions

Avoiding the join with m_pricelist and c_doctype contentions are solved

Tue, 09 Dec 2014 18:55:38 +0100Fixed bug 28360 c_order_post creates unnecesary contentions
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 09 Dec 2014 18:55:38 +0100] rev 25611
Fixed bug 28360 c_order_post creates unnecesary contentions

Avoiding the join with m_pricelist the m_pricelist contention is solved

For update sentence is deleted in c_orderline selects because the
c_orderline is bloqued with the main select and is redundant and
causes unnecessary contentions.

Tue, 25 Nov 2014 12:08:01 +0100Fixed issue 28242: Load grid even with inconsistent default view info
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 25 Nov 2014 12:08:01 +0100] rev 25610
Fixed issue 28242: Load grid even with inconsistent default view info

Before the previous changeset was applied, it was possible to have a preference that specified that a certain grid had a default saved view, but that the referenced default saved view did not actually exists. When this happened the grid was not loaded until the user pressed the Refresh button.

To fix this, now the inconsistent default view info is detected and the grid is loaded once it is detected that the default view does not actually exists.

Tue, 25 Nov 2014 11:51:55 +0100Related with issue 28242: Delete preference along with window personalization
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 25 Nov 2014 11:51:55 +0100] rev 25609
Related with issue 28242: Delete preference along with window personalization

When a grid view is saved and set as default two records are added:
- One to the OBUIAPP_UIPersonalization with the description of the view
- One to the Preference table, using the OBUIAPP_DefaultSavedView property, whose value is the ID of the record added to the OBUIAPP_UIPersonalization table

The problem of this issue was that when the a default saved view was removed from the OBUIAPP_UIPersonalization table, its corresponding entry from the Preference table was not removed. This resulted in not making the initial request to load the grid because it was detected that the view had a default saved view (using the preference), and not doing it after loading the window personalization because the view description was removed from OBUIAPP_UIPersonalization.

The first step of the issue, included in this changeset, removes the Preference associated with a default saved view when it is deleted from OBUIAPP_UIPersonalization. This prevents the data from being inconsistent. The second and final step will consist in loading the grid even when the data is inconsistent, to fix the cases where the data is already inconsistent.

Mon, 24 Nov 2014 20:20:57 +0530Fixes Issues 27820:Error when posting Payment/Transaction/Reconciliation
Atul Gaware <atul.gaware@openbravo.com> [Mon, 24 Nov 2014 20:20:57 +0530] rev 25608
Fixes Issues 27820:Error when posting Payment/Transaction/Reconciliation
referencing a cash vat invoice linked to several orders

Issue is a regression due to related fix for issue 26571. Cast Vat lines
were posted as many times the no. of orders linked with cash vat invoices.
So now posting is based on the payment details so the relevant cash vat line
associated with it is posted though it is looped as many times as the no. of
orders linked.

Tue, 23 Dec 2014 09:09:52 -0500Fixed bug 28216: The glitem is not printed when using financial invoice
Fernando Soto <fernando.soto@peoplewalking.com> [Tue, 23 Dec 2014 09:09:52 -0500] rev 25607
Fixed bug 28216: The glitem is not printed when using financial invoice

Modified the report to read the GL Item name.
Used the sugested solution.

Mon, 01 Dec 2014 18:36:51 -0500Fixed bug 28330: IllegalArgumentException error when executing Reset Accounting.
Reinaldo Guerra <reinaldo.guerra@peoplewalking.com> [Mon, 01 Dec 2014 18:36:51 -0500] rev 25606
Fixed bug 28330: IllegalArgumentException error when executing Reset Accounting.

HQL Query when updating order status during reset accounting process, launches an hibernate exception when parsing "Order" keyword. In order to avoid this, ResetAccounting java class was changed to use native SQL Query instead of HQL Query in the logic of restore method.
This changes takes into account all kind of unposteable openbravo entities listed in Reset Accounting window's process. Now it is possible to reset c_order table accounting information successfuly.

Tue, 23 Dec 2014 10:31:52 +0530Fixes Issue 27266: Added isactive='Y' clause while BP Location selection
Atul Gaware <atul.gaware@openbravo.com> [Tue, 23 Dec 2014 10:31:52 +0530] rev 25605
Fixes Issue 27266: Added isactive='Y' clause while BP Location selection

Tue, 21 Oct 2014 17:47:46 +0200Fixes Issue 27266:United States is always selected in Country field
Daniel Ruiz <daniel.ruiz@openbravo.com> [Tue, 21 Oct 2014 17:47:46 +0200] rev 25604
Fixes Issue 27266:United States is always selected in Country field
(Business Partner window, Bank account tab).

Default value shown on country field in Bank account tab (Business Partner
window) is always United States and it should not be in that way.
Now, default value will be the country defined in Location/address tab.
If there are no Locations defined, it will take the country which has isDefault
column set as 'Y'. Finally, if there are several Locations defined for that
Business Partner, the system will take any of them and if there is one record
whose country is set as Default, this one will be shown.

Wed, 24 Dec 2014 10:19:35 -0500Fixed bug 27530: Wrong error message having 2 amortization in Draft status.
Reinaldo Guerra <reinaldo.guerra@peoplewalking.com> [Wed, 24 Dec 2014 10:19:35 -0500] rev 25603
Fixed bug 27530: Wrong error message having 2 amortization in Draft status.

Create amortization process in class named AssetLinearDepreciationMethodProcess was changed to show correctly an error message when retrieving more than one amortization in draft status, for the same organization and range of dates.
Now when trying to create a new amortization, and exists two or more amorizations for the same organization and dates in draft status, a correct message will be shown.

Tue, 23 Dec 2014 18:53:13 +0100Fixed issue 27580 fixed issue to cash vat invoices
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 23 Dec 2014 18:53:13 +0100] rev 25602
Fixed issue 27580 fixed issue to cash vat invoices

Fixed wrong journal entries when you void a cash vat sales invoice
and fixed total prepayment amount

Tue, 16 Dec 2014 23:22:21 +0530Fixes Issue 28329:Sample Data for F&B International Group Client
Atul Gaware <atul.gaware@openbravo.com> [Tue, 16 Dec 2014 23:22:21 +0530] rev 25601
Fixes Issue 28329:Sample Data for F&B International Group Client
for PR15Q1

Thu, 25 Dec 2014 18:49:53 +0530Fixes Issue 27761: Credit of Customer A is consumed fully.
Atul Gaware <atul.gaware@openbravo.com> [Thu, 25 Dec 2014 18:49:53 +0530] rev 25600
Fixes Issue 27761: Credit of Customer A is consumed fully.

A invoice is created for Customer A which consumes all available credit
of Customer A.

Tue, 23 Dec 2014 11:46:18 -0500Fixed bug 28053: Tax is not selected when the business partner is set as exempt.
Reinaldo Guerra <reinaldo.guerra@peoplewalking.com> [Tue, 23 Dec 2014 11:46:18 -0500] rev 25599
Fixed bug 28053: Tax is not selected when the business partner is set as exempt.

The callout applied in sales order line tax selector, now obtains tax rate for the header's organization tree when the business partner is set as Tax Exempt.
The C_GETTAX function was changed to filter tax rates taking into account the order's header organization tree. Now when creating a new order's line for a tax exempt business parter, the tax selector will show records for the correspondent organization tree.

Wed, 24 Dec 2014 13:29:10 +0100Fixed bug 28482: Exchange rate and Converted Amt in Add Payment
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Wed, 24 Dec 2014 13:29:10 +0100] rev 25598
Fixed bug 28482: Exchange rate and Converted Amt in Add Payment

The Exchange rate and Converted amount fields were not properly updated when 2 financial accounts (the first one of them with different currency than the invoice and the second one with the same currency) are selected sequentially into the Add Payment process.

Casue: the conversion rate was wrongly sent back to the JS as a String ("1") instead of using a number. The OB.APRM.AddPayment.paymentMethodMulticurrency function checks the received conversion rate is a number before updating the converted amount. Since the converted amount wasn't a number but a string, the amounts were not updated.
After the fix, the conversion rate is sent back using a integer 1

Tue, 23 Dec 2014 17:12:06 +0100Fixed issue 28376: Copyright year of ERP code for 2015 is not updated.
Naroa Iriarte <naroa.iriarte@openbravo.com> [Tue, 23 Dec 2014 17:12:06 +0100] rev 25597
Fixed issue 28376: Copyright year of ERP code for 2015 is not updated.

Some files have been updated with the proper year.

Wed, 24 Dec 2014 11:11:43 +0100Fixes issue 28379: Value from field is not lost after setting it with a process
Augusto Mauch <augusto.mauch@openbravo.com> [Wed, 24 Dec 2014 11:11:43 +0100] rev 25596
Fixes issue 28379: Value from field is not lost after setting it with a process

This issue was caused from a bug in the OBViewGrid.processFICReturn function. There was some code that meant to save in the grid the value of fields that were not being shown in the grid, and that therefore were not returned by the datasource when the grid was loaded. The faulty condition to check if the value of the field was present in the grid was the following:

if (field && !this.getRecord(rowNum)[field.property]) {

This condition is not proper because it does not check if the field is visible in the grid or not. This condition will evaluate to true if the value of that field is null, even if the field is being shown in the grid. Due to this when the value of the Storage Bin field was erased, its new null value was stored in the list of edited values of the grid, and this value took precedence over the Storage Bin value picked in the process.

To fix this, the condition has been improved to check if the field is actually being shown in the grid.

Wed, 24 Dec 2014 14:36:24 +0530Related to issue 28440: Code review changes
Pandeeswari Ramakrishnan <pandeeswari.ramakrishnan@openbravo.com> [Wed, 24 Dec 2014 14:36:24 +0530] rev 25595
Related to issue 28440: Code review changes

If the 'Cancel' button is clicked, the pop up should be closed irrespective
of mandatory fields are filled or not.

Tue, 23 Dec 2014 13:24:32 +0100Fixed bug 28440 Require at least one value flag for instance atributtes is not working
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 23 Dec 2014 13:24:32 +0100] rev 25594
Fixed bug 28440 Require at least one value flag for instance atributtes is not working

If Require at least one value flag is true Lot/Serial Number/Expiration Date
should be mandatory in Attribute Set selector

Tue, 28 Oct 2014 21:23:23 -0500Fixed bug 27570: The Business Partner should be filled in the Payment Out Lines
Fernando Soto <fernando.soto@peoplewalking.com> [Tue, 28 Oct 2014 21:23:23 -0500] rev 25593
Fixed bug 27570: The Business Partner should be filled in the Payment Out Lines

Modified APRM_GEN_PAYMENTSCHEDULE_INV and APRM_GEN_PAYMENTSCHEDULE_ORD to set the business partner to the payment_schedule_detail.
Also added a Modulescript to correct previously entered data.

Tue, 23 Dec 2014 11:18:30 +0100Related to issue 19728: Do more JS code formatting
David Baz Fayos <david.baz@openbravo.com> [Tue, 23 Dec 2014 11:18:30 +0100] rev 25592
Related to issue 19728: Do more JS code formatting

Tue, 23 Dec 2014 10:00:03 +0100fixed bug 28472: multi requests to datasource in big FK filter drop down
Asier Lostalé <asier.lostale@openbravo.com> [Tue, 23 Dec 2014 10:00:03 +0100] rev 25591
fixed bug 28472: multi requests to datasource in big FK filter drop down

Setting drawAllMaxCells to 0 makes SC to only fetch one page

Mon, 22 Dec 2014 19:14:54 +0100Fixes issue 28432: HQLDataSourceService manages translations properly
Augusto Mauch <augusto.mauch@openbravo.com> [Mon, 22 Dec 2014 19:14:54 +0100] rev 25590
Fixes issue 28432: HQLDataSourceService manages translations properly

There were several problems related with the handling of translatable columns in the HQLDataSourceService class:
- If there was a translation installed, the query done to retrieve some data that contained a translatable column threw an exception. This was because the WHERE constant of the inner query done to retrieve the translated string was being removed. The regex that handled this has been improved so that now only the leading WHERE constant is removed.
- After fixing that the query no longer threw an exception but it did not return the proper results. This happened because the query was not properly built, due to not using the entity alias in the query builder.
- After that, the translated string was not being shown when the filter drop down was populated. This has been fixed by changing the way this information is obtained. Previously only the id and the (not translated) identifier was obtained using the query. Now the whole BaseOBObject is retrieved, and it is used later to obtain its id and its potentially tranlated identifier.

Mon, 22 Dec 2014 19:12:07 +0100Fixes Issue 26511: Display correct error message while deleting the orderline.
Unai Martirena <unai.martirena@openbravo.com> [Mon, 22 Dec 2014 19:12:07 +0100] rev 25589
Fixes Issue 26511: Display correct error message while deleting the orderline.

The problem on this issue is that the trigger is not able to delete the related reservation of the orderline and the given error is displayed. So in this case the error message displayed has been improved to warn the user that needs to remove the reservation manually before deleting the Sales Order Line.

Mon, 22 Dec 2014 18:30:10 +0100Fixes Issue 28417: Warehouse in Return Material Receipt properly filtered.
Unai Martirena <unai.martirena@openbravo.com> [Mon, 22 Dec 2014 18:30:10 +0100] rev 25588
Fixes Issue 28417: Warehouse in Return Material Receipt properly filtered.

The warehouse selector in the Return Material Receipt window is not filtering any more by warehouses on hand. The filter expression on On Hand Warehouse selector has been modified to fix this problem.