[Javier Ader]

Buenas. Ok, este tipo de bug ya lo deben conocer en general ya que he visto varias partes de código que lo solucionan. Igual la idea es que bajo java algo como BigDecimal(“1.0”).equals(BigDecimal(“1”)) es falso (internamente los bigdecimal son representando como pares [numero entero, escala] por ej 1.0 se [10,1] y 1 es [1,0]; para Java dos Bigdecimal solo son “equals” si estos pares ordenados lo son).

Bueno, como me lo encontré una vez más hice una búsqueda en Eclipse para encontrar todos los llamados a estos métodos y encontré los siguientes (creo que son todos los relacionados a BigDeciaml.equals()):

Code:

openXpertya.model.MMPCOrder.afterSave(boolean, boolean)
***org.openXpertya.model.CalloutTimeExpense.amount(Properties, int, MTab, MField, Object)
openXpertya.model.MMPCOrderBOMLine.beforeSave(boolean)
***org.openXpertya.model.MJournalLine.beforeSave(boolean)
org.openXpertya.process.RetencionIIBB.calculateAmount()
org.openXpertya.mfg.process.MRP.calculatePlan(int, MProduct, BigDecimal, Timestamp, Timestamp)
org.openXpertya.model.MBoletaDeposito.checkLines()
org.openXpertya.model.MUOMConversion.convert(int, int, BigDecimal, boolean)
org.openXpertya.model.MConversionRate.convert(Properties, BigDecimal, int, int, Timestamp, int, int, int)
org.openXpertya.model.MUOMConversion.convert(Properties, int, int, BigDecimal)
org.openXpertya.model.MUOMConversion.convertProductFrom(Properties, int, int, BigDecimal)
org.openXpertya.model.MUOMConversion.convertProductTo(Properties, int, int, BigDecimal)
org.openXpertya.mfg.process.RollupBillOfMaterial.getCostLL(String, int, int, int, int, int, int)
org.openXpertya.acct.ProductInfo.getPOCost(MAcctSchema)
org.openXpertya.acct.ProductInfo.getPriceList(MAcctSchema, boolean)
org.openXpertya.acct.ProductInfo.getProductItemCost(MAcctSchema, String)
org.openXpertya.model.MAsset.getQty()
org.openXpertya.report.FinReport.hideLinesWithZero()
org.openXpertya.acct.Matcher.match()
openXpertya.model.CalloutOrder.qtyBatch(Properties, int, MTab, MField, Object)
org.openXpertya.acct.DocLine_Invoice.setAmount(BigDecimal, BigDecimal, BigDecimal)
org.openXpertya.acct.ProductInfo.updateCosts(MAcctSchema, boolean, int, int, int) -3 veces
org.openXpertya.acct.ProductInfo.updateCosts(MAcctSchema, boolean) -3 veces
org.openXpertya.apps.search.InfoProductAttribute.updateStatusLabel()

Todos estos métodos tiene pontencialmente un bug (algunos los verifique ) por usar “equals” en vez de “compareTo”. Los que tienen *** de prefijo son incluso peor ya que para solucionar el tema del equals setean previamente las escalas de los dos operandos (método setScale) pero lo hacen sin tener en cuenta que este método, como lo están llamando, potencialmente dispara una excepción (por ej, setear la escala a 2 al numero 10.001 dispara una excepción).

[Federico Cristina]

Javier,

Gracias por el aporte. Justamente, fixes como éstos están en nuestra lista de pendientes.

Haciendo un repaso por las clases donde encontraste el bug, noto que – salvo un caso – el resto son errores arrastrados de versiones muy antiguas del framework. Supongo que no deben incidir demasiado en el uso general de la aplicación ya que por el momento no recuerdo incidencias relacionadas con este tema.

Saludos!!
Federico

[Javier Ader]

Si, la mayoría es código relativamente viejo (y probablemente muchos no esten en uso). Lo que si vi mucho de esto en la parte relacionada con la contabilidad; fijate que todo esto vino porque me puse a mirar como se contabilizaba una factura y creo que el equals que me incito a buscar todos los demas estaba en
org.openXpertya.acct.DocLine_Invoice.setAmount(BigDecimal, BigDecimal, BigDecimal)

Un método que se llama cada vez que se contabiliza un factura.
Otro creo que debe estar relacionado con el bug que por lo menos estaba hasta la versión anterior que ocurria cuando uno cargaba asientos contables de manera manual. Casi seguro que era este:
org.openXpertya.model.MJournalLine.beforeSave(boolean)

Bueno, y otros relacionados con el “costing”.

Hay muchos otros “equals” (en realidad Eclise me busco todas las llamadas a Object.equals…), pero en general se dan entre referencias “object” o con respecto a una Strings (o.equeal(“algo”)). Esos, salvo que justo las instancias en tiempo de ejecución vengan a ser BigDecimal, no deben traer problemas.

[Autor]

Entradas