ValidaCFD

Hola, si de echo yo soy el propio programador de mi sistema, uso el modo de WebServices, ya he logrado timbrar en la versión 3.3, y he ajustado algunos parámetros para que como dicen, el sistema sea configurable. sin embargo haciendo una de tantas pruebas fué como me encontré con ese detalle de no llegar a los 6 mil cerrados, y me es raro que finkok con la versión 3.3 te haya dejado timbrar, a mí no me lo permitió y fue por ello que inicie este debate.

Incluso me puse en contacto con ellos (Finkok) y en efecto en la versión 3.3 no me permitían más de 2 decimales, sin embargo por los cuestionamientos que aquí mismo hice, me dijeron que lo iban a verificar, puesto que hasta donde ellos tenían, el precio unitario sólo soportaría hasta la cantidad de decimales que soportara la moneda.

Aunque lo más seguro es que si dejen soportar más de 6 decimales, porque de lo contrario nos enfrentariamos a un sin fin de descuadres y pos no sería viable estar haciendo los ajuste manualmente..

Aqui les dejo el validador de finkok, intenten hacer una prueba con más de 2 decimales en PU a ver que les muestra..

http://validador.finkok.com/

Lee lo que te mande.
tu no tienes que enviar el PU con mas de dos decimales
te mando el xml de los 6000.00
espero que muestrees el tuyo para checarlo

gilberto escribió:Lee lo que te mande.
tu no tienes que enviar el PU con mas de dos decimales
te mando el xml de los 6000.00
espero que muestrees el tuyo para checarlo

Si, de hecho como comente, ya puedo generar los xml correctamente, pero si me llamó mucho la atención, porque al dejar en 2 decimales el PU, ya no coinciden los cálculos. Hay clientes que son muy quisquillosos en ese aspecto y ni se diga de los ayuntamientos, que a parte de que pagan cuando quieren, quieren que exactamente cuadren todos los decimales y si por alguna centésima no llegan las rebotan.

Descuento.
Atributo condicional para representar el importe total de los descuentos aplicables antes de impuestos. No se permiten valores negativos. Se debe registrar cuando existan conceptos con descuento.
En tu xml

Hola DADO :

Tengo una duda con el XML que timbraste. Al multiplicar la cantidad 5,000 x el valor unitario 1.0345 nos da como resultado 5,172.50 ¿ Porqué en el campo importe del XML tiene 5,172.41 ?

Alguien que ya tenga un xml ya timbrado en producción con 2 o 3 decimales..

hasta el momento todos los que hemos mostrado son de prueba..

amigo!!!!!!!
no encontraras ningún xml con tres decimales.
la regla lo dice claramente.
Podrás hacer todos tus cálculos con dos , tres y asta 6 decimales en tu aplicación si es que te lo permite, o
en tu calculadora.
Pero antes de mandar los datos al pac los tienes que redondear a dos decimales.

el 29/06/2017 el SAT publico una versión nueva del anexo 20 en el cual ya no se indica que el Valor Unitario debe ser a los decimales que soporta la moneda. Solo menciona lo siguiente


ValorUnitario
Validar Si el TipoDeComprobante es I, E o N, el valor registrado debe ser mayor que cero.

enlace : http://www.sat.gob.mx/informacion_fisca ... 90617.docx

y cual de los dos documentos del Estándar sera el valido? este en Word que nos comentas o el PDF que aun esta en:

http://www.sat.gob.mx/informacion_fisca ... cfdv33.pdf

ese aun no se actualiza. O dependerá del PAC cual quiera tomar?

Jesus Castelo escribió:y cual de los dos documentos del Estándar sera el valido?

De acuerdo a un asesor (no es del sat-an) con información directa del chamuco, más o menos recuerdo que menciono que el orden de menor a mayor obediencia es:

. DOF
. Anexo y documentos tecnicos: xsd...
. RMF
. Guía de llenado

:: Y conforme se actualicen aumenta su obediencia.
Y como la guía es actualizada mas que el DOF o RMF, esta "manda y corrige" burradas previas.

Nos van a traer como loquitos buscando el documento mas reciente todo el tiempo. Hasta los PACs pierden la secuencia y no se actualizan, y esos que están de la mano del chamuco.

Hace falta que el SAT implemente una manera más eficiente de tener un documento actualizado y correcto las 24 horas del día.