Thu, 26 Feb 2015 12:52:37 +0100Fixed issue 28819: Include "Accounting" tab in Internal Consumption
Jorge Garcia <jorge.garcia@openbravo.com> [Thu, 26 Feb 2015 12:52:37 +0100] rev 26092
Fixed issue 28819: Include "Accounting" tab in Internal Consumption

It is necessary to include "Accounting" tab in Internal Consumption window.

The accounting tab has been added to the Internal Consumption window and
has been configurated properly.

Now, the Internal Consumption windows shows the Accounting tab.

Wed, 25 Feb 2015 11:13:09 +0100Fixed issue 28917: There is no Processed field in transaction tab
Jorge Garcia <jorge.garcia@openbravo.com> [Wed, 25 Feb 2015 11:13:09 +0100] rev 26091
Fixed issue 28917: There is no Processed field in transaction tab

In the Financial Account window, in the Transactions tab, there is no field
in order to know if a created transaction is processed or not.

The solution is to display the field Processed in the Windows, Tabs and Fields.

Now, the Processed Field is shown in the Transaction tab.

Thu, 26 Feb 2015 19:48:36 +0100Fixes bug 28051: Reserved qty now is correct.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 26 Feb 2015 19:48:36 +0100] rev 26090
Fixes bug 28051: Reserved qty now is correct.

In this issue 3 changes have been done:
[1]: In M_RESERVATION_POST stored procedure, when calling to AD_UPDATE_PINSTANCE an extra parameter has been added ('N'). This has been done to avoid to do a commit when working with Oracle database, because it was causing to behave different in Postgres and Oracle.
[2]: In StockReservationPickAndEditDataSource, when opening Manage Reservations P&E from Sales Order, it retrieves a Reservation related to the Order Line if it exists and it processes. This was failing in Oracle if it was already processed, so a check has been added to avoid this case.
[3]: In ManageReservationActionHandler, when clicking Done in Manage Reservation P&E, it was first reserving what the user was typing in the P&E, and if it was not processed the reservation, it was processing it. As the M_RESERVATION_POST tries always to reserve as much as possible, it was overriding the previously set amounts. In order to prevent this, now first the reservation is being processed and after that the values typed in the UI are being set to the reservation.

Thu, 26 Feb 2015 21:38:33 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Thu, 26 Feb 2015 21:38:33 +0000] rev 26089
CI: merge back from main

Thu, 26 Feb 2015 21:20:29 +0000CI: update AD_MODULE to version 26084
RM packaging bot <staff.rm@openbravo.com> [Thu, 26 Feb 2015 21:20:29 +0000] rev 26088
CI: update AD_MODULE to version 26084

Thu, 26 Feb 2015 15:36:55 +0100Fixes bug 29079: Fixed Costing Background infinite loop.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 26 Feb 2015 15:36:55 +0100] rev 26087
Fixes bug 29079: Fixed Costing Background infinite loop.

Costing Background process, due to Cost Adjustments new implementation, on a certain point of the code, it was not applying correctly a setScale method to round a value of the expected cost. This was causing to have allways a difference between the expected cost and unitcost. Because of this, an adjustment was being created to adjust this difference, and to adjust all related transactions, causing an infinite loop

Thu, 26 Feb 2015 15:29:20 +0100Fixes bug 29076: Division by zero error managed in Costing Background.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 26 Feb 2015 15:29:20 +0100] rev 26086
Fixes bug 29076: Division by zero error managed in Costing Background.

Under certain circumnstance a division by zero error was happening in Cost Adjustments process inside Costing Background (when calculating backdated adjustments of a transaction of movementqty zero). This problem has been managed by being sure that this division will not happen again. If the movementqty of the transaction is zero, the cost of the full transaction will be zero as well.

Thu, 26 Feb 2015 15:23:25 +0100Fixes bug 29080: getStartingDate() method does not fail in Costing Background.
Unai Martirena <unai.martirena@openbravo.com> [Thu, 26 Feb 2015 15:23:25 +0100] rev 26085
Fixes bug 29080: getStartingDate() method does not fail in Costing Background.

An OBQuery is being executed in getStartingDate() method inside AverageAlgorithm. There are 2 parameters in this OBQuery that are not setting properly, 'client' and 'org'. The whereclause is filtering by 'id' of these properties and instead of passing the id of these objects, the object was being passed to the OBQuery. These sometimes works but other times don't, so this has been changed to always setting the id's as parameters.

Thu, 26 Feb 2015 15:56:04 +0100related to issue 29063 update Copyright
Sandra Huguet <sandra.huguet@openbravo.com> [Thu, 26 Feb 2015 15:56:04 +0100] rev 26084
related to issue 29063 update Copyright

Wed, 25 Feb 2015 13:16:20 +0100Fixes bug 29063: Fixed mutating trigger in Oracle.
Unai Martirena <unai.martirena@openbravo.com> [Wed, 25 Feb 2015 13:16:20 +0100] rev 26083
Fixes bug 29063: Fixed mutating trigger in Oracle.

M_RESERVATION_TRG was triggering a mutating trigger error because a select to the m_reservation table was being done on that trigger, that belongs to m_reservation table. That select has been modified to now to join m_reservation table, because it is not necessary.

Wed, 25 Feb 2015 20:21:08 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Wed, 25 Feb 2015 20:21:08 +0000] rev 26082
CI: merge back from main

Wed, 25 Feb 2015 20:03:28 +0000CI: update AD_MODULE to version 26075
RM packaging bot <staff.rm@openbravo.com> [Wed, 25 Feb 2015 20:03:28 +0000] rev 26081
CI: update AD_MODULE to version 26075

Mon, 23 Feb 2015 13:21:01 +0100Fixed bug 28606: Tax Amount field of Invoice Lines should be deprecated
Jorge Garcia <jorge.garcia@openbravo.com> [Mon, 23 Feb 2015 13:21:01 +0100] rev 26080
Fixed bug 28606: Tax Amount field of Invoice Lines should be deprecated

Tax Amount field of Invoice Lines has been deprecated as it is calculated only
when the lines are created manually and if the tax rate is a summary tax rate
the value calculated is not correct. The field is never displayed.

Now the field Development Status from the column taxAmt (c_invoiceline table)
has been changed from 'Ready' to 'Deprecated'.

Tue, 24 Feb 2015 12:47:00 +0100Fixes issue 29016: G/L Journal Header dates are not copied from G/L Journal
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 24 Feb 2015 12:47:00 +0100] rev 26079
Fixes issue 29016: G/L Journal Header dates are not copied from G/L Journal

Defaultvalues of document date and accounting date in G/L Journal Header tab have been modified in order to be copied from G/L Journal Batch tab when the window is G/L Journal. If the window is Simple G/L Journal, document date and accounting date will be setted as current date.

Mon, 23 Feb 2015 18:52:28 +0100Fixes issue 29029: SL_Journal_Period raises a NullPointer Exception
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Mon, 23 Feb 2015 18:52:28 +0100] rev 26078
Fixes issue 29029: SL_Journal_Period raises a NullPointer Exception

AcctSchema will be retrieved only if acctSchemaId is not null (G/L Journal Header tab). In other case (G/L Journal Batch tab) it will not.

Tue, 24 Feb 2015 14:12:20 +0100Fixes issue 29041: Period is not automatically populated in G/L Journal window
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Tue, 24 Feb 2015 14:12:20 +0100] rev 26077
Fixes issue 29041: Period is not automatically populated in G/L Journal window

Defaultvalue from C_Period_ID column in GL_JournalBatch table has been changed to get current date instead of accounting date, which is null when creating a new record.

Wed, 25 Feb 2015 18:18:59 +010028620: Button reference is not displayed properly in parameter windows
Inigo Sanchez <inigo.sanchez@openbravo.com> [Wed, 25 Feb 2015 18:18:59 +0100] rev 26076
28620: Button reference is not displayed properly in parameter windows

Button reference is not displayed properly in parameter windows, currently
in the User Interface a checkbox is drawn (like in the Yes/No reference).

Now, It is already possible to add new buttons to Process Definition by using
the "ButtonList" reference. So, the solution for this issue has been to remove
the "Button" reference from the list of references that can be assigned
for the parameters.

Wed, 25 Feb 2015 14:55:59 +0100Fixes issue 27034
Eduardo Argal Guibert <eduardo.argal@openbravo.com> [Wed, 25 Feb 2015 14:55:59 +0100] rev 26075
Fixes issue 27034
Add From/To Account filters to Journal Entries Report

Wed, 25 Feb 2015 09:53:23 +0100Fixes issue 28979: UpdateCustomerBalance is wrongly calculating CurrentBalance
Alvaro Ferraz <alvaro.ferraz@openbravo.com> [Wed, 25 Feb 2015 09:53:23 +0100] rev 26074
Fixes issue 28979: UpdateCustomerBalance is wrongly calculating CurrentBalance

UpdateCustomerBalance modulescript has been modified in order to get credit for receipts as negative and credit for payments as positive. Also, it now takes into account partial payments.

Wed, 25 Feb 2015 01:00:06 +0100Fixed issue 28857:Minimized view of query-list widgets sort data in the client
Inigo Sanchez <inigo.sanchez@openbravo.com> [Wed, 25 Feb 2015 01:00:06 +0100] rev 26073
Fixed issue 28857:Minimized view of query-list widgets sort data in the client

The problem was that in minimized view, the query-list widgets just sort the data
in the client. So it is only showing the data being displayed locally, instead of
requesting the data to the server.

This happens because "useClientSorting" was not setting properly. This is related
to the change of leaving of calculate total rows to improve performance.

Now, it works properly in minimized and maximized view because it has been setting
properly "useClientSorting" variable. The exceptional case is when the widget is in
minimized view and "ShowAllData" is not active. In this case, it will always make a
request for the data.

Tue, 24 Feb 2015 22:09:13 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Tue, 24 Feb 2015 22:09:13 +0000] rev 26072
CI: merge back from main

Tue, 24 Feb 2015 21:49:34 +0000CI: update AD_MODULE to version 26064
RM packaging bot <staff.rm@openbravo.com> [Tue, 24 Feb 2015 21:49:34 +0000] rev 26071
CI: update AD_MODULE to version 26064

Tue, 24 Feb 2015 22:16:04 +0100Fixes issue 29010: Grid is actually filtered using relative dates
Augusto Mauch <augusto.mauch@openbravo.com> [Tue, 24 Feb 2015 22:16:04 +0100] rev 26070
Fixes issue 29010: Grid is actually filtered using relative dates

The problem was that when a relative date filter was added to the grid and then used in a saved view, the saved view will not apply the relative date filter, but an absolute one. This was caused by this code in the OBViewGrid.convertCriteria function:

if (this.dataSource) {
criteria = this.dataSource.convertRelativeDates(criteria);
}

Every time that a criteria is sent to the backend (i.e. when storing a saved view), the criteria objects that contained relative dates wwere converted to absolute dates. This was done to fix this issue
[1], its problem being that the datasource used to populate the filter drop down did not support relative dates.

The function where that code was placed was too central, the criterias converted should have been only the ones used to populate the filter drop downs, but all the criterias were being converted. To fix this, the code has been adapted and moved to the OBFKFilterTextItem.getPickListFilterCriteria function.
[1] https://issues.openbravo.com/view.php?id=27679

Tue, 24 Feb 2015 19:00:32 +0100Related to bug 29030: Code review.
Unai Martirena <unai.martirena@openbravo.com> [Tue, 24 Feb 2015 19:00:32 +0100] rev 26069
Related to bug 29030: Code review.

Fixed the copyright.
Add a clear on every 100 iterations of bankLinesSR Scrollable Results.

Tue, 24 Feb 2015 18:56:03 +0100related to issue 29021, related to issue 29051, related to issue 29052
Sandra Huguet <sandra.huguet@openbravo.com> [Tue, 24 Feb 2015 18:56:03 +0100] rev 26068
related to issue 29021, related to issue 29051, related to issue 29052

improve the error message

Mon, 23 Feb 2015 17:47:46 +0100Fixes bug 29030: Match Statement does not fail when a line throws an exception
Unai Martirena <unai.martirena@openbravo.com> [Mon, 23 Feb 2015 17:47:46 +0100] rev 26067
Fixes bug 29030: Match Statement does not fail when a line throws an exception

In Matching Algorithm in Match Statement, if a line to be matched fails for any reason (period closed for example) a rollback occurs. This rollback was not being properly managed in Matching Algorithm after the refactor of Match Statement window, so the process was failing instead of skipping that line and going forward. Now it skips and the process finished successfully.

Tue, 24 Feb 2015 12:38:51 +0100Fixes bug 28987: Add payment does not take long to load with lot of credit paym.
Unai Martirena <unai.martirena@openbravo.com> [Tue, 24 Feb 2015 12:38:51 +0100] rev 26066
Fixes bug 28987: Add payment does not take long to load with lot of credit paym.

When opening Add Payment process definition it has to load the default values of the parameters of the process definition. One of this parameters is the credit of the business partner of the payment. The method that calculates this credit calls the method seqnumberpaymentstatus that uses CallStoredProcedure.getInstance().call to call the database function. This method is executed for each credit payment of the customer and on each execution an unnecessary flush was being done, so with lots of credit payments the impact on performance was huge.
A false flag has been added to call process to not to do flush on each execution of the process, so the performance problem is avoided.

Mon, 23 Feb 2015 17:10:34 +0100Fixed issue 29021 It is possible to process Payment Out without set amount
Sandra Huguet <sandra.huguet@openbravo.com> [Mon, 23 Feb 2015 17:10:34 +0100] rev 26065
Fixed issue 29021 It is possible to process Payment Out without set amount

Added a new validation in process button because it is not possible
to add a glitem with both amounts equal to 0.
Added a default value in received in and paid out fields in glitem
grid.

Tue, 24 Feb 2015 12:02:28 +0100Merge back from main
RM packaging bot <staff.rm@openbravo.com> [Tue, 24 Feb 2015 12:02:28 +0100] rev 26064
Merge back from main

Tue, 24 Feb 2015 10:57:12 +0000Merge temporary head for 3.0PR14Q3.7
RM packaging bot <staff.rm@openbravo.com> [Tue, 24 Feb 2015 10:57:12 +0000] rev 26063
Merge temporary head for 3.0PR14Q3.7