[Javier Ader]

Buenas. Estoy estundiando un poco toda la logica de descuentos (no termino de tomarle la mano…), pero creo que hay un bug (en 10.09), no se si lo habran visto para el nuevo release (o si es un bug, despues de todo….).
La clase DiscountableDocumentLine da una definición por defecto de getTotalAmt() incorrecta:

Code:

public BigDecimal getTotalAmt() {
return getTaxedAmount(getPrice()).multiply(getQty());
}

El total de linea la retorna simplemente como el precio unitario acutal (que puede haber sufrido descuentos) por la cantidad de la linea; el tema es que getPrice() por definicion debe retornar el precio unitario actual SIN impuestos (y posiblemente descuento de linea) , mientras getTotalAmt debe retornar el total de linea CON impuestos (y posiblemente descuentos de lineas).
Quiero decir, esa definición debe ser incorrecta; o no se deberia dar (y dejar que la implementen las subaclases) o modificarla para dar el resultado esperado.

Las subclases de DiscountableDocumentLine:
-DiscountableOrderProductWrapper no pareceria tener problemas, porque redefine este metodo y retorna un monto que incluye impuestos (esto es,desde el tpv los calculos se van a hacer bien).
pero

-DiscountableMOrderLineWrapper no, y ademos creo que comete otros dos errores:

define
getPrice() como MOrderLine.this.getPriceActual(); el cual NO necesariamente no tiene incluido el impuesto (esto es, getPrice() retorna lo esperado solo si la lista de precios que se usa no incluye impuestos). getPrice “debe” retornar el precio unitario neto (a lo sumo teniendo en cuenta los descuentos de linea)
getPriceList() idem (MOrderLine.this.getPriceList(); nuevamente puede o no incluir impuestos)

Bajo esta situación, creo que por esta combinación de bugs, el resultado de aplicación a descuentos anda bien, pero solo cuando se usa lista de precios tiene impuestos incluidos (ahi entre el getPrice y el getTotalAmt en DiscountableDocumentLine terminan generando el valor correcto, al menos para getTotalAmt…. los demas usao de getPrice, posiblemente lleven a otros problemas…). Si la lista de precios no incluye impuestos, getPrice() retorna el monto correcto, pero getTotalAmt() no.

(lo siguiente es algo mas general y no debe traer muchos problemas…)
getQty() (esto creo que es un error generalizado o al menos creo que tiene otra semantica, pero no grave) retorna MOrderLine.this.getQtyEntered(). A mi entender deberia retornar MOrderLine.this.getQtyOrdered() (lo mismo que MInvoiceLine lo que debe importar es qtyInvoiced, no qtyEntered). Las “cantidades entradas” en todos los documentos son solo “informativas”; tiene importancia solo cuando el usuario usa otra unidad de medida que la especificada por el producto; en ese caso se usa esta cantidad y el algoritmo de conversión de Unidad elegida a Unidad de Producto para calcular la cantidad del producto en su unidad base (esta unidad, es la que, pienso, se usa implicitamente en stock). Por ej, en MordrLine, qtyOrdered es la cantidad real en unidad de medida “base” de producto; qtyEntered es la cantidad ordenada, pero en la unidad especificada en la linea (si la unidad especificada en la linea y la unidad base del producto es la misma entonces qtyEntered = qtyOrdered; es por eso que si no se usan mas de una medida por produto no pasa nada, pero conceptualmente creo que incorrecto). Siguiendo la misma lógica el precio de un producto esta implícitamente relacionado a la unidad “base” del mismo.

Saludos

[Javier Ader]

ok, el primer bug no es tal… No me di cuenta que estaba llamando a la función getTaxedAmmount (aunque esta ultima función debería siempre aplicar la multiplicación, ya que deberia ser siempre llamdo con montos sin impuestos)…. igual, el tema de getPrice(), creo que sigue estando mal; esto siempre debería retornar un monto unitario sin impuestos, al menos según su declaración.

[Autor]

Entradas