Fixes issue
33752: Can be closed an order with reserved stock
If the stock was reserved and the associated goods shipment voided, the order was raising an error when trying to close it.
When reservations are retrieved, C_ORDER_POST1 trigger doesn't takes into account the status of previously released reservations.
To make this validation works homogeneously just like is now in other areas where this validation is executed (C_ORDER_POST1, M_INOUT_CREATE, M_INOUT_POST, M_RESERVATION_POST) the query that retrieves the count of reservations of the line also takes into account those lines with status different than 'CL'.
Also validates that is created a new reservation for the line only if doesn't exists any reservation for it.
Related to issue
33629: Code review improvements
Group by bp.id and bp.name instead of by bp to avoid errors in Oracle.
fixed bug
33629: slow order/invoice grid population in Add Payment Description
In evironments with big volumes it was slow because it performed a Seq Scan
on FIN_Payment_ScheduleDetail table.
It has been fixed for the cases when BP is preset by:
- Removing left joins to get BP from order/invoice to retrieve it directly
from FIN_Payment_ScheduleDetail
- Adding an index on FIN_Payment_ScheduleDetail.BP so that previous query
does not require of a Seq Scan
Fixes issue
33909. Add null check on closeSession
On some very specific scenarios it is possible to execute 2 commitAndClose or
rollbacks on the same SessionHandler instance. As both methods calls the
setSession(null) and closeSession() methods a NPE is thrown on the second
execution.
fixes issue
33900: Wrong decimal default value having ',' as decimal separator
When using a decimal value as default for a numeric column, this very same value is a String passed to the createFromClassicString of NumberUIDefinition which is used by the FIC to retrieve the column value. The default values are part of the code, so in case of decimal values, they must me defined as a valid Java decimal number. But the createFromClassicString expects a value formatted according to the Format.xml file.
For this reason, now the decimal default values are formatted properly. Although this value will be converted again in the createFromClassicString, this is the cleanest solution because for the rest of the flows within the FIC, the createFromClassicString method receives a value formatted according to the to the Format.xml file.