Almacenar los importes de un CFDI timbrado, igual que el XML

[RigoFlores]

Ahora mismo se almacenan con 3 decimales, y eso genera un sin fin de errores. Casi diario hablan por lo mismo. Lo que se ocupa es que los mismos importes que se van en el XML timbrado, sean idénticos a los que se almacenan en la BD. Cuando eso sucede, el saldo disponible es -0.00 (eso indica que hay una diferencia, y si es mayor a 0.005, lo redondea hacia arriba, generando un centavo de diferencia y con ello el error resultante)

Aquí un ejemplo:

[jccastillo0007]

pasame los datos de ese caso.. para replicarlo.. el tema es que en la base de datos se guardan como double, y no puedo forzar decimales... mas bien algo pasa en la conversión o cuando se arma el total...

Con un caso como el de arriba específico, podría validar cuál es el verdadero problema

[RigoFlores]

Básicamente cualquier factura que se almacena con 3 decimales, tiene ese problema. Lo que tengo que decir es que modifiquen manualmente a 2 decimales, y que chequen que la suma corresponda al importe pagado, pero eso es una chinga.

[RigoFlores]

El issue, lo que pide es que el dato que se va al XML, se almacene idéntico en la BD. Al XML se van 2 decimales, entonces no importaría que sea double en la BD, porque los 2 decimales no tienen por que agregar un valor mas en el tercer decimal.

[jccastillo0007]

ok, hice algunos cambios y validaciones, puedes checar en el new efacturat.

Voy a dar de baja PRU... solo para que estes usando el new efacturat y ver que todo este bien

[RigoFlores]

El efecto de si quedó o no, se observa en CxC, Ingresar Cobro. Y sigue mostrando 3 decimales. Checa en el nuevo server, con la cuenta TCM, factura 44

[jccastillo0007]

pero necesitamos generar una nueva factura... asi lo hiciste? las facturas anteriores no fueron alteradas

[RigoFlores]

si revisas la factura fe44, la generé ayer, una vez que reportaste que lo checara.... chiaaaa