josemmo
Posibilidad de especificar el valor calculado del importe total de la línea (totalAmountWithoutTax)
Actualmente, estoy usando este parche para evitar problemas de decimales con precisión sin limitar al realizar el cálculo de $quantity * $unitPriceWithoutTax, de esta forma se puede mantener el cálculo precio, y añadir la posibilidad de realizar nosotros el redondeo previamente.
src/FacturaeItem.php
17a18
> private $totalAmountWithoutTax = null;
110c111
< $totalAmountWithoutTax = $quantity * $unitPriceWithoutTax;
---
> $totalAmountWithoutTax = ( $this->totalAmountWithoutTax === null ? $quantity * $unitPriceWithoutTax : $this->totalAmountWithoutTax );
No sé si esto tiene implicaciones en el schema 3.2, ya que en el 'Item/GrossAmount' => ['min'=>6, 'max'=>6], sin embargo tampoco se limita en código.
Rogaría que se incluyese como mejora.
Saludos.
Hola @xkrambler,
Facturae-PHP implementa dos modos de precisión para hacer el redondeo de decimales. No se si esto soluciona tu problema.
Gracias por la respuesta, y más de tu parte @josemmo.
Inicialmente usaba este tipo de redondeo, pero también afecta al cálculo de IVA, por lo que en algunos casos se daban rechazos de factura por un decimal en contabilidad, por eso he propuesto esta sencilla forma, que permite que se usen los mismos decimales que los presentados al usuario en cada línea.
Por ejemplo para algunas empresas uso 2 decimales, en otras 4, y la verdad es que tras ver el código original fué la única forma que se me ocurrió de darle soporte, quizás haya una forma de implementarlo mejor, se me ocurre poder modificar en el esquema "'Item/GrossAmount' => ['min'=>6, 'max'=>6]," a otros valores, pero falta aplicarlo en FacturaeItem previo cálculo de los impuestos.
Agradecer el gran trabajo que has hecho, y en lo que pueda ayudar dímelo.
La matriz de decimales (lo de "Item/GrossAmount") no se puede modificar, esas reglas vienen dadas por la especificación. Si se trata de un problema de Facturae-PHP en el cálculo de totales, lo mejor sería dar con el fallo para arreglarlo en vez de aplicar un parche.
Al margen de lo anterior, no entiendo muy bien el fallo en cuestión ni la solución propuesta. Aunque se apliquen los cambios que propones, el redondeo de $totalAmountWithoutTax se sigue haciendo después para ambos modos de redondeo.
Además, teniendo en cuenta que ni $quantity ni $unitPriceWithoutTax son redondeados por la librería para el cálculo total de la línea de producto, no es necesario un $totalAmountWithoutTax personalizado porque ya se puede controlar su valor.
El caso es que ese redondeo que hace después ya no interesa, ya que los impuestos pueden variar dependiendo de si se hace el redondeo antes, por eso creo que sería interesante aplicar ese redondeo antes del cálculo de impuestos, y por eso comenté qué parche estoy usando actualmente.
De hecho creo que es erróneo que se haga el redondeo después de haber hecho cálculos con esa cantidad, imaginemos que se quisiese partiendo de la versión redondeada de totalAmountWithoutTax volver a calcular los impuestos... no sería posible, ya que el redondeo se hace a posteriori.
Siento si no me explico bien, como he comentado, tampoco sé las implicaciones que pueden surgir, si bien especificar totalAmountWithoutTax tampoco me parece correcto, si me parecería correcto aplicar el redondeo según el esquema que esté seleccionado antes del cálculo de impuestos.
Hola @xkrambler,
¿Podrías pasar por aquí el código en PHP que utilizas para generar una de las facturas que te da este problema? Junto con los valores que consideres son correctos.
Perdona @josemmo , intentaré preparar un ejemplo sencillo que sea expresivo, siento la demora, estoy hasta el cuello.