Decimales en Precio Unitario v3.3

Y para empezar Que es una Factura Electronica? Como empiezo? Necesito Autorizacion? Que medios hay para Facturar Electronicamente? estos y todos los temas de iniciacion deberan estar aqui
Avatar de Usuario
acanas
Mensajes: 477
Registrado: Mar Ene 11, 2011 4:18 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor acanas » Mar Sep 12, 2017 1:21 pm

Agregaría que para cualquier base de cálculo de impuestos esta debe ser antes de impuestos pero después de descuentos aplicados.
Zyphersoft Development

Victor Marroquin
Mensajes: 58
Registrado: Mar Jul 25, 2017 12:45 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor Victor Marroquin » Mar Sep 12, 2017 3:39 pm

BUEN DIA
YO YA LOGRE TIMBRAR EN MODO PREUBAS PARA GASOLINERA, AHI DEJO UN EJEMPLO

ESPERO TE SEA DE AYUDA,
SALUDOS!
Adjuntos
F_49198.xml
(4.02 KiB) Descargado 403 veces

alsadi
Mensajes: 9
Registrado: Lun Sep 04, 2017 4:24 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor alsadi » Vie Sep 15, 2017 1:52 pm

Muchas gracias por sus comentarios
ya lo solucione, efectivamente estaba mal mi campo base en inpuestos
alli debe ir el precio sin ieps ni iva (yo no lo sabia solo le quitaba al iva)
saludos

Avatar de Usuario
acanas
Mensajes: 477
Registrado: Mar Ene 11, 2011 4:18 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor acanas » Vie Sep 15, 2017 2:12 pm

Por cierto no me queda muy claro el criterio para los redondeos ya que no especifica si es aritmético o financiero y me causa un poco de dudas que pueda estar propenso el código ha tener errores de validación pero decidí usar redondeo financiero en vez de truncar. Según la documentación prácticamente los campos de totales son los que deben estar redondeados a 2 fracciones algo así como "valor = round (valor,2)" .

Actualmente estoy tratando de seguir esta regla de redondeo a 2 fracciones para estos atributos:

Comprobante.Total, Comprobante.SubTotal, Comprobante.Descuento Redondeados a 2 fracciones.

En Conceptos:
Importe Redondeado a 2 Fracciones.

En Impuestos Traslados/Retenciones de los Conceptos:
Comprobante.Concepto.Impuestos.Traslado:
Importe: Redondeado a 2 Fracciones.

El resto de los atributos requeridos para determinar totales los estoy dejando tal cual a 6 fracciones tales como: Cantidad, Base, ValorUnitario.

No me convence mucho que el SAT deje a 2 decimales los totales ya que así como se pueden perder 1 centavo a favor del Fisco como a favor del contribuyente pero bueno ya para finalizar es correcto redondear en vez de truncar 2 decimales?

Saludos.
Zyphersoft Development

Hugo Galindo
Mensajes: 140
Registrado: Lun Nov 23, 2015 8:46 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor Hugo Galindo » Vie Sep 15, 2017 2:37 pm

acanas escribió:Por cierto no me queda muy claro el criterio para los redondeos ya que no especifica si es aritmético o financiero y me causa un poco de dudas que pueda estar propenso el código ha tener errores de validación pero decidí usar redondeo financiero en vez de truncar. Según la documentación prácticamente los campos de totales son los que deben estar redondeados a 2 fracciones algo así como "valor = round (valor,2)" .

...

El resto de los atributos requeridos para determinar totales los estoy dejando tal cual a 6 fracciones tales como: Cantidad, Base, ValorUnitario.

No me convence mucho que el SAT deje a 2 decimales los totales ya que así como se pueden perder 1 centavo a favor del Fisco como a favor del contribuyente pero bueno ya para finalizar es correcto redondear en vez de truncar 2 decimales?

Saludos.


En la información publicada en el DOF el SAT marca límites inferior y superior para las cantidades. Lo normal es que esos límites permitan que ya sea que redondees hacia arriba o hacia abajo (trunques) de todas formas quede dentro del margen. Así que tu puedes decidir qué tipo de redondeo deseas manejar (Tendrás que hacer algunas pruebas con el PAC para ver que te lo acepte, porque recientemente detecté que el PAC de respaldo estaba calculando mal estos límites, al menos en un ejemplo que publicaron).

En cuanto al valor unitario. En el DOF dice que debe ser a dos decimales (para MXN) lo cual hace que para facturas por un importe grande pueda generar un error de varios pesos en el total, ya no centavos. En su guía el SAT ya quitó donde decía que debía restringirse a los decimales de la moneda y los PAC lo están aceptando con más decimales, el único problema es que todavía no hay ningún documento oficial que indique el cambio, y seguro no faltará algún contador contreras (de esos que abundan) que dirá que tiene que ser a dos decimales.

Saludos.

alsadi
Mensajes: 9
Registrado: Lun Sep 04, 2017 4:24 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor alsadi » Vie Sep 15, 2017 5:16 pm

en mi experiencia tienen razon los pacs dan margen de una decima arriba o abajo
si te sale mas verifica que todas las cantidades tengan la misma cantidad de decimales,
yo decidí truncar la 2 decimales

Avatar de Usuario
acanas
Mensajes: 477
Registrado: Mar Ene 11, 2011 4:18 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor acanas » Vie Sep 15, 2017 10:37 pm

alsadi escribió:en mi experiencia tienen razon los pacs dan margen de una decima arriba o abajo
si te sale mas verifica que todas las cantidades tengan la misma cantidad de decimales,
yo decidí truncar la 2 decimales

De hecho es lo que me estoy dando cuenta, implementé las formulas para determinar los limite inferior y superior de un importe de un concepto en base ValorUnitario y Cantidad y el resultado del intervalo no me convenció demasiado en cambio me parece más real jugar entre la diferencia mínima que puede existir que es 1 centavo.

Por ejemplo si tengo los siguientes valores:
Cantidad =1.00 ValorUnitario=6.989960

El Limite inferior sería truncando los primeros 2 fracciones quedando: 6.98
El límite superior sería redondeado de acuerdo a la cantidad de decimales soportada por la moneda, en este caso pesos MXN serían 2: Math.Round(6.989960,2) = 6.99

Cualquier valor que este en ese intervalo de 6.98 y 6.99 debería ser válido.
Zyphersoft Development

Avatar de Usuario
acanas
Mensajes: 477
Registrado: Mar Ene 11, 2011 4:18 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor acanas » Lun Sep 18, 2017 2:16 pm

De hecho al decir generoso en el rango de limite inferior y superior es porque por pura casualidad mientras depuraba de errores lo de los redondeos me salió un error donde el PAC prácticamente me estaba dando 3 centavos de rango de tolerancia lo cual si bien es bueno se me hace muy complasciente.
Zyphersoft Development

Avatar de Usuario
Dado
Mensajes: 15824
Registrado: Mar Jul 06, 2010 8:56 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor Dado » Mar Sep 19, 2017 3:51 am

Debido a lo comun del error por parte de los PAC en que mencionan que los subtotales, importes, totales, etc no coinciden nos hemos puesto a la tarea de agregar esta validacion en nuestro validador ValidaCFD para ayudarles a identificar el problema

[Actualizacion]
La version liberada fue la 170919, pueden descargar esta version visitando www.validacfd.com

Se recomienda capturar en el menu de opciones una Tolerancia de 0.004
ADDENDAS? VALIDACION? CODIGO PARA PROGRAMAR TU PROPIA SOLUCION? TODO LO TENEMOS EN WWW.VALIDACFD.COM VISITANOS !!

Avatar de Usuario
Dado
Mensajes: 15824
Registrado: Mar Jul 06, 2010 8:56 pm

Re: Decimales en Precio Unitario v3.3

Mensajepor Dado » Mar Oct 24, 2017 12:42 pm

Para unificar este problema tan comun abri un nuevo tema aqui
ADDENDAS? VALIDACION? CODIGO PARA PROGRAMAR TU PROPIA SOLUCION? TODO LO TENEMOS EN WWW.VALIDACFD.COM VISITANOS !!


Volver a “Iniciando con la Factura Electronica”

¿Quién está conectado?

Usuarios navegando por este Foro: Google [Bot] y 11 invitados