Decimales en Precio Unitario v3.3

[ca.software]

Hola que tal espero me puedan orientar con el siguiente problema derivado de las limitantes de usar solo 2 decimales en precio unitario.

Ejercicio:

5000 tornillos a 1.20 (con IVA incluido) daría como resultado $6,000.00

Sin embargo al hacer el desglose

Precio unitario sin IVA= 1.03

5000 X 1.03 = 5150.00 X 16% = 824 + = 5974.00 Lo cual no coinciden con los 6000.00

Alguien sabe como se podra solventar esto... de igual forma si le aumento a 1.04 se pasa..

5000 X 1.04 = 5200 X 16% = 832 + = 6032.00


Info. Adicional:
6000 / 1.16 = 5172.413793 / 5000 =1.03448275862
ó
1.20/ 1.16 = 1.03448275862

el problema será en las cantidades grandes que se presenten y limitando el precio unitario a 2 decimales.

No quiero ni imaginar cuántos clientes brincaran por este detalle..

[s3cr3to]

En una hoja de calculo es posible lograrlo: usando un "redondeo" automático a 4 decimales, y manualmente capturando todos a 2 decimales.

CalculoRedondeoAuto_o2Decimales.png (38.78 KiB) Visto 7865 veces

O como mi Maestro de Álgebra Madaleno dice:
"El orden de los factores si altera el producto".

Ahhh pero estoy seguro que tarde o temprano te toparas con alguno donde no funcionara al 100% en especial al usar tipos de cambio.

[ca.software]

Sin título.png (92.79 KiB) Visto 7858 veces

[gilberto]

Buenas noches amigo.
yo tengo mi sistema que le pongo el precio unitario 1.034482 cantidad 5000 y me manda un resultado
de ValorUnitario 1.03 Importe 5172.41 Traslado Importe 827.59 TotalImpuestosTrasladados 827.59
SubTotal 5172.41 Total 6000.00
A qui el detalle de mi sistema es que me deja poner 6 decimales pero a la hora que se
hace la formula arroja 2 decimal.
Y si me timbro.
Inténtalo si tu estas creando el sistema.
Si no comentalo al proveedor del sistema o al ing. en Sistemas que te habilite 6 decimales
Suerte.

[Dado]

Hice la prueba, timbro correctamente !!

Creo que hay un concepto que debemos revisar ya que los PAC SI ACEPTAN MAS DE DOS DECIMALES en los importes

Como valor unitario de los tornillos tengo 1.0345 y lo timbro sin problema, asi que como dice @gilberto, programalo o pide a tu programador que habilite mas decimales

[ca.software]

Hola de nuevo, muchas gracias a todos por sus comentarios, y en efecto, si tomamos más de 2 decimales no tenemos ningún problema, sin embargo, el pac que manejo es Finkok, y sólo permite ingresar 2 decimales si le pongo mas ya me manda un error.

Validando el xml que me muestran de prueba me da lo siguiente..

validacion cfdi.PNG (4.86 KiB) Visto 7834 veces

AHORA, sin embargo acabo de descargar de nuevo la guia de llenado y ahi si indica que se pueden poner hasta 6 decimales, yo estaba tomando como referencia una guía que descargue hace como un mes y creo que volvieron a actualizar (Estos cambian como cal&%"zon de Pu&/&"ta) perdon por la expresión..

preciounitario.PNG (67.99 KiB) Visto 7834 veces

creo que ahi esta mi confusión.. sin embargo voy a verificar con el PAC porque no acepta más decimales en PU.

Gracias, por sus comentario, a ver que me dicen..

[ca.software]

De nueva cuenta otra contradicción de acuerdo con el anexo 20.

"Validaciones adicionales a realizar por el proveedor"

validaciones.PNG (43.56 KiB) Visto 7828 veces

Entonces ya no sé si es chana o juana..

Porque será que el SAT está acostumbrado a hacer todo mal ó solo es mi idea.

[Dado]

Creo que lo mas importante es lo que apliquen los PAC

Al final lo que uno quiere es timbrar su CFDI y si el PAC se pone sus moños entonces no queda mas que reclamarle

[s3cr3to]

De nueva cuenta otra contradicción de acuerdo con el anexo 20.

No debes de basarte solo en el Anexo 20... el archivo tdCFDI.xsd, indica 6 decimales:

Código: Seleccionar todo

<xs:simpleType name="t_Importe"><xs:annotation><xs:documentation>Tipo definido para expresar importes numéricos con fracción hasta seis decimales. El valor se redondea de acuerdo con el número de decimales que soporta la moneda.  No se permiten valores negativos.</xs:documentation></xs:annotation><xs:restriction base="xs:decimal"><xs:fractionDigits value="6"/><xs:minInclusive value="0.000000"/><xs:pattern value="[0-9]{1,18}(.[0-9]{1,6})?"/><xs:whiteSpace value="collapse"/></xs:restriction></xs:simpleType>

Lo siguiente no lo digo yo, nos lo dijo un C.P/Asesor con acercamientos constantes con sat-an en un pequeño seminario.
Hay que recordar que el Anexo 20 no ha sido actualizado y varios xsd han sido modificados en Mayo, luego esta el documento de "guía de llenado" entonces el orden de prioridad para seguir las "pseudo-reglas del sat" se usa este orden:
1) Anexo 20 *
2) XSD *
3) RMF*
4) Guia de llenado*
* Recordar que cuando estas luego son actualizadas, tienen mayor prioridad la de fecha mas reciente.
** y se me olvidaba, también está la "MatrizDeErrores_CFDI_v33.xls" que nos aplica a los emisores y PACs.

Luego te topas con algunos PACs que por la saturación de trabajo no actualizan las plataformas de prueba, o simplemente no le pasan el memo al programador, y luego los usuarios tenemos que lidiar con los errores del chamucho, del pac + programador, y los propios.

[gilberto]

Amigo.....
Yo Timbro con finkok.
Pregunto
Tu eres el programador de tu sistema de facturación.
Estas usando la plataforma de facturación de finkok.
Cual la de paga o la gratuita.
Estas usando las DLL de finkok.
Estas usando el WEBSERVICE DE FINKOK.
Por mi parte yo soy el programador de mi propio sistema.
Utilizo tanto el webservice y las dll dependiendo de tipo de sistema, tengo barios.
En el campo precio unitario lo tengo habilitado para 6 decimales y el calculo lo tira
el sistema de acuerdo como lo programes.

ejemplos
can = 5000
precio = 1.03
subtotal = 5150
iva = 824
total = 5974

el mismo pero...... sin redondear a dos dígitos asi lo rechaza el PAC cualquiera
can = 5000.00
precio = 1.034482
subtotal = 5172.41
iva = 827.5856
total = 5999.9956

el mismo redondeando a dos dígitos es como lo quiere el PAC ya sea fulano o sutano
can = 5000.00
precio = 1.03
subtotal = 5172.41
iva = 827.59
total = 6000.00

Estos cálculos son en tu maquina por tu sistema, cuando viajan al pac tu sistema
los tiene que redondear a dos decimales.

Y que nos estamos dando cuenta DADO que el PAC no realiza la operación aritmética solo
comprueba las sumas de subtotal de impuestos y que den el total.
Eso lo compruebo en mi sistema también.

mi sistema hace los calculos y los redondea pero......
tambien lo dejo manipulable por si no lo pasa el PAC osea que puedo correjirlo en la caratula
antes de volverlo a mandar al PAC una centecima que por lo regular es lo que nos da error.
esos errores que ya se eatan haciendo famosos.
Y timbran
Ejemplo: 5,000.00 ya con iva automatico con la maquina.
can = 1
precio = 4310.34
subtotal = 4310.34
iva = 689.65
total = 4999.99
El mismo ejemplo alterando una decima el iva en la caratula antes de timbrar
can = 1
precio = 4310.34
subtotal = 4310.34
iva = 689.66
total = 5000.00
Y milagro como barita majica si lo timbro.
Ratifico que el pac no realiza la operacion aritmetica.
ni saca senos ni cosenos jajajaja este fue chiste....