Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[JoseLeeTo]

Empezado por antoine0

Primero, a un nivel operacional como son los esquemas, nada está publicado de manera oficial. Solo existen borradores. Con estos se pueden diseñar cositas, pero tienes que estar preparado a cambios. (Por esto este foro está muy tranquilito.)
Un detalle importante: se ha dicho (pero no creo haberlo he visto escrito en un texto oficial) que el esquema para los registros de facturación será el mismo para todos los casos, o siga, que no habrá diferencias entre sistemas veri*factu y no-veri*factu a nivel de registros intercambiados.

Luego, los eventos no tienen que ser almacenados en XML. Y lo mismo ocurre con los registros de factura en un sistema no-veri*factu.
Solo será obligatorio usar XML (con esquemas aún por publicar) para transmitir estos registros en contestación a los futuros requerimientos. Y posiblemente para firmar los registros (este proceso de firma no está definido claramente en la actualidad; al principio era basado sobre el contenido XML, pero se dice que se van a suprimir algunos nodos del contenido a firmar; otro tema abierto).

En este punto hay que preguntarse por qué estás programando un sistema no-veri*factu.
La posibilidad de sistemas no-veri*factu no es la preferida por Hacienda claramente, no hacen nada para que siga la opción por defecto, más bien todo lo contrario.
Creo que esta opción existe para las empresas que tienen ya en casa un sistema de facturación capaz de cumplir los requerimientos de la ley (integridad, trazabilidad, etc.) y que no quieren desarrollar una adaptación a este sistema para comunicar en tiempo casi real las facturas por el canal veri*factu. El caso más obvio son las empresas donde el sistema de facturación no está conectado a Internet.
Estas empresas solo deberán desarrollar una adaptación para firmar los registros de facturación y los de eventos (y almacenar dichas firmas), y otra para comunicar lotes de registros en formato XML bajo requerimientos.
¿Se sabe cómo firmar? No, no está publicado.
Lo de los registros para los requerimientos está un poco más claro (no mucho) porque al menos el contenido se puede deducir de los borradores; pero no es suficientemente preciso para que puedes empezar a programar la generación en XML de estos lotes: tal como lo dices, faltan los esquemas.

Para mi, si tienes resuelto todo lo demás y solo te falta programar la generación en XML de los lotes para enviar a Hacienda, creo que vas muy bien en tu agenda. Solo te queda esperar un poco más a que Hacienda publique su orden ministerial. Y luego ¡tendrás muchos meses para los ensayos! (y adaptarse a posibles cambios de normativa; cf. ticketBAI.)


El envío SOAP se hace en una comunicación segura (https que involucra un certificado.
Pero este certificado no tiene que ser él del obligado tributario: existen casos dónde "colaboradores" pueden presentar registros en nombre de un obligado.

Muchas gracias por la respuesta, Antoine0. Me sirve de mucha ayuda tu respuesta.
No obstante, tengo muchas dudas todavía con respecto al funcionamiento.
En mi caso, todavía no tiene claro mi empresa si será el Cliente el que decida si se acoge a VeriFactu o no, con lo que tengo que abrir ambas posibilidades mientras no me digan lo contrario (doble de curro para mi, obviamente). Tenía entendido que en un sistema NO Verifactu, los XML se guardaban firmados en espera de ser enviados ante un requerimiento de la AEAT, pero ya no me queda nada claro con lo que me comentas de que NO hace falta almacenarlos, sino que como dices solamente se generarán los XML y se firmarán y enviarán en el momento que los requiera hacienda, pero no antes. Tengo bastantes dudas sobre eso. No sé si alguien lo había interpretado como yo ... jejeje

Un saludo y gracias de nuevo.

[Neftali [Germán.Estévez]]

Empezado por JoseLeeTo

Tenía entendido que en un sistema NO Verifactu, los XML se guardaban firmados en espera de ser enviados ante un requerimiento de la AEAT,...

Empezado por JoseLeeTo

... pero ya no me queda nada claro con lo que me comentas de que NO hace falta almacenarlos, sino que como dices solamente se generarán los XML y se firmarán y enviarán en el momento que los requiera hacienda

Yo te diría que es la primera (casi seguro).
Primero, porque para el encadenamiento de facturas te hacen falta datos de la anterior incluyendo la firma (por lo que sabemos de otros sistemas similares). Eso obliga a generar y FIRMAR una factura, que es lo que impide su modificación. Y parte de esa firma es lo que se usa en la siguiente.

Si se hiciera de la segunda forma, podrías generar las facturas e ir modificándolas y generar todos los XML sólo cuando te los solicitara hacienda. De esa forma se generarían todos correctos con la última foto de cada factura.

No se si me explico.

[JoseLeeTo]

Empezado por Neftali [Germán.Estévez]

Yo te diría que es la primera (casi seguro).
Primero, porque para el encadenamiento de facturas te hacen falta datos de la anterior incluyendo la firma (por lo que sabemos de otros sistemas similares). Eso obliga a generar y FIRMAR una factura, que es lo que impide su modificación. Y parte de esa firma es lo que se usa en la siguiente.

Si se hiciera de la segunda forma, podrías generar las facturas e ir modificándolas y generar todos los XML sólo cuando te los solicitara hacienda. De esa forma se generarían todos correctos con la última foto de cada factura.

No se si me explico.

Hola, sí, muchas gracias Neftali [Germán.Estévez]

Es lo que yo tenía entendido. Esperamos a ver que nos comente alguien más a ver qué se interpreta, de si se necesita almacenarlos o no.
Pero yo creo que los XML NO Verifactu, tienen que guardarse firmados, aunque la segunda opción de generarlo según te los requiera Hacienda, quizá también sería factible, ya que en realidad se enviaría lo que hubiese en el último momento como dices, y Hacienda no era conocedora del "primer estado de la factura"... sino que conocerá el último, el que se remita... Pero no sé si eso sería viable o está permitido.

Un saludo

[Franche]

- Si se hiciera de la segunda forma, podrías generar las facturas e ir modificándolas y generar todos los XML sólo cuando te los solicitara hacienda. De esa forma se generarían todos correctos con la última foto de cada factura.

Quizás esté equivocado pero entiendo que la firma no deja de ser una cadena de caracteres especifica que se puede guardar en un campo de la factura, con lo cual siempre podrás regenerar el xml cuando quieras, no haría falta guardar cada xml por si lo requiere hacienda ya que podrás regenerarlos cuando te lo exijan.

Por ejemplo cuando firmas una factura electrónica con el certificado digital :
</ds:SignedInfo>
<ds:SignatureValue Id="Signature-e488077f-3ef5-445a-8ba0-b5ce49a5a2fc-SignatureValue">F5512COqupJ0YPXM70N/CvnX7F6n+8bvupqIxR+AGtLE6RThxzemHMLAYZaj1e6e8xEHoejY1oo3sDyuov/hoAlRjwk/0VJkhx+xsQ3p9xE9N7sTTPUdyRmS/J9kab3sTeVJaOKNkoz+AmpekCRIdv5Zc7SbAIXvhIuqdvUD5DmNZjFrX6fwbmUDQDW/R5erRane/cJhAb9QCVfsNEsZZpITarfhYabe3JgOaqS9XJYHHSsjbnFMLLJWlOZC/QB7t8MEez9cjS9v+rqLuv9GyCoswxuNw==</ds:SignatureValue>
<ds:KeyInfo Id="Signature-e488077f-3ef5-445a-8ba0-b5ce49a5a2fc-KeyInfo">
<ds:X509Data>
<ds:X509Certificate>MIIIyzCCB7OgAwIBAgIQHfcbEeyvXcVlOMY6oDfmbzANBgkqhkiG9w0BAQsFADBNMQswCQYDVQQGEwJF UzERMA8GA1UECgwIRk5NVC14guFNj6IXjDFwB6+f8fYhAsabiqSg3i/5nk3yVH9mF/XzxPAKJ+Fk69oqtT6a7yHMsvSrQ4G7NmJ5mVcm/aSI/KRkpWLQ9TRYtw9tYgEvYPEOdNYHmW/HolveDDAywKQ8A+NAwlENs5aYCTg3bWBZj0BHX5MS9Dv0xkdaw1FfUXnp93YJcAAmqoUd3AuLUCaRcOyNeI=</ds:X509Certificate>
<ds:X509Certificate>MIIG3DCCBMSgAwIBAgIQYcLU1PaprndVkma5ja/WITANBgkqhkiG9w0BAQsFADA7MQswCQYDVQQGEwJFUzERMA8GA1UECgwIRk5NVC1SQ00xGTAXBgNVBAsMEEFDIFJBSVogRk5NVC1 SQ00wHhcNMTUwNjMwMDk1MTUzWhGZubXRyY21jYS9PY3NwUmVzcG9uZGVyMDsGCCsGAQUFBzAChi9odHRwOi8vd3d3LmNlcnQuZm 5tdC5lcy9jZXJ0cy9BQ1JBSVpGTk1UUkNNLmNydDAfBgNVHSMEGDAWgBT3fcX9xOiaG3dkp/UdoMy/h2CabTCB6wYDVR0gBIHjMIHgMIHdBgRVHSAAMIHUMCkGCCsGAQUFBwIBFh1odHRwOi8vd3d3LmNlcnQuZm5tdC5lcy9kcGNzLzCB pgYIKwYBBQUHAgIwgZkMgZZTdWpldG8gYhbWqC6z7KeGyZBTeVIilPhp+xZzJnvFVBjN6s2j7W3+esQkiT4SdY9RN+c3tBuWF54U Nc7YVe6KVTjzkpev9szp6vUNQ+A45i2KGXRLN6/16nA9fujzITRWmX4tOGABo0aL/wBrf3Po89gvZwZRaVQ9Bw/KfEF8eZDhA1MgQKSPJLSXSl58elHGFLUR2CQMGl+mgfPB0qZUUkRG/RYpZLocczAz6pfkxA3Mt3DfIyVtA/YJ0O4ZYpdbH9zdJZI1RQEWmFrMOrEAWmGIG0SmNpARqOPJsTQJomUcvd3EvA7so2LzLJ+Sjj2So=</ds:X509Certificate>
<ds:X509Certificate>MIIFgzCCA2ugAwIBAgIPXZONMGc2yAYdGsdUhGkHMA0GCSqGSIb3DQEBCwUAMDsxCzAJBgNVBAYTAkVT MREwDwYDVQQKDAhGTk1ULVJDTTEZMBcGA1UECwwQQUMgUkFJWiBGTk1ULVJDTTAeFw0wODEwMjkxNTU5NTZaFwpLuHvUBKwrZ1pe bbuCoGRw6IYsMHkCtA+fdZn71uSANA+iW+YJF1DngoABd15jmfZ5nc8OaKveri6E6FO80vFIOiZiaBECEHX5FaZNXzuvO+FB8Txx uBEOb+dY7Ixjp6o7RTUaN8Tvkasq6+yO3m/qZASlaWFot4/nUbQ4mrcFuNLwy+AwF+mWj2zs3gyLp1txyM/1d8iC9djwj2ij3+RvrWWTV3F9yfiD8zYm1kGdNYno/Tq0dwzn+evQoFt9B9kiABdcPUXmsEKvU7ANm5mqwujGSQkBqvjrTcuFqN1W8rB2Vt2lh8kORdOag0wokRqEIr9baRRmW1FMdW4R5 8MD3R++Lj8UGrp1MYp3/RgT408m2ECVAdf4WqslKYIYvuu8wd+RU4riEmViAqhOLUTpPSPaLtrM=</ds:X509Certificate>
</ds:X509Data>
<ds:KeyValue>
<ds:RSAKeyValue>

[Neftali [Germán.Estévez]]

Empezado por Franche

Quizás esté equivocado pero entiendo que la firma no deja de ser una cadena de caracteres especifica que se puede guardar en un campo de la factura, con lo cual siempre podrás regenerar el xml cuando quieras, no haría falta guardar cada xml por si lo requiere hacienda ya que podrás regenerarlos cuando te lo exijan.

Esto viene directamente de las preguntas y respuestas de una de las presentaciones:

"Se recuerda que el registro de facturación debe ser generado inmediatamente antes o simultáneamente a la expedición
de la factura. Quiere eso decir que, si se ha podido imprimir la factura, el registro ya se ha generado y por lo tanto debe
existir y, en el caso de NO VERI*FACTU, conservarse. En el caso de VERI*FACTU, será necesario reintentar la remisión
hasta conseguirlo y marcar el campo "Incidencia" en la remisión del registro de facturación. ..."


La opción de generarlos cuando los pida hacienda no es viable. Los necesitas en el momento de generar la factura y no tendria sentido, porque es justo lo que se quiere, que generes el XML "Registro de facturación" en el momento para encadenarlos y así evitar que a partir de ese momento puedas modificar la factura original.

[ermendalenda]

Hola, he leído en Linkedin un mensaje de que ha habido una ponencia de Javier Hurtado que habla de algo de que están estudiando que los del SII yengan obligación de verifactu o que los de autofacturas sii hagan verifactu.como no se entendía muy bien el mensaje, os pregunto si alguno tenéis noticia de ese congreso/ponencia.
Gracias

[novatico]

Empezado por ermendalenda

Hola, he leído en Linkedin un mensaje de que ha habido una ponencia de Javier Hurtado que habla de algo de que están estudiando que los del SII yengan obligación de verifactu o que los de autofacturas sii hagan verifactu.como no se entendía muy bien el mensaje, os pregunto si alguno tenéis noticia de ese congreso/ponencia.
Gracias

Acabo de hacer un búsqueda de "Javier Hurtado Puerta" que era (sí digo "era") Director del Departamento de Inspección Financiera y Tributaria de la AEAT, y me aparece una publicación en el BOE de 1 de Febrero de 2024, en la que se comunica su cese en dicho cargo. Yo he presenciado varios webinars de él junto con José Borja, Director Informático de la Agencia Estatal de Administración Tributaria, en los que detallaban diferentes aspectos de la Ley Antifraude y Verifactu. No sé si este cese puede tener que ver con los retrasos en la publicación de la OM.

https://www.boe.es/diario_boe/txt.ph...OE-A-2024-2097

[keys]

Yo creo que no https://theobjective.com/economia/20...nchez-montero/

D. E. P.

[JoseLeeTo]

Hola a todos de nuevo.

Cuando se habla de Operación, quiero entender que se está hablando de una Línea de la Factura, ya que en el esquema y dentro de la factura, la calificación de la operación y demás, está dentro del desglose de la misma, donde habría que meter todas las líneas de la factura. ¿Esto es así?.


El caso es que tenía pendiente revisar el tratamiento "diferente" que se hace para Canarias y Ceuta/Melilla.
A la hora de Calificar la Operación (CalificacionOperacionType), y en base al Regimen (ClaveRegimen), existe la opción de establecer una operación como Exenta.

Es decir, ClaveRegimen (de IVA) es Regimen General.... Criterio de Caja.... y en concreto está el elemento "08", que hace relación a IPSI/IGIC

Aquí me entran todas las dudas del mundo, cuando habla de "Operación No Sujeta por Reglas de localización.", que entiendo que será lo que aplique en estos casos.

1. Si el empresario que emite la factura tributa en Canarias, Ceuta o Melilla, ¿existe algún tratamiento distinto con un empresario Peninsular?.
Es decir, a la hora de remitir las facturas, ¿hay que tener en cuenta algo en concreto por el hecho de que el empresario esté en Canarias o no?

2. ¿Existe algún tratamiento especial cuando un empresario está en la península, pero la factura se emite a una persona residente en Canarias, Ceuta o Melilla?
¿Y existe algún tratamiento al revés? (Es decir, empresario en Canarias, Ceuta o Melilla, y el destinatario de la factura es en la península)


Alguien que lo tenga más o menos esto claro, ¿podría poner un breve esquema de cómo interpretar todo esto, con Canarias, Ceuta y/o Melilla, y quizá un pequeño ejemplo de cómo rellenar ClaveRegimen(), CalificacionOperacionType() y posteriormente la Base Imponible, Tipo Impositivo, Cuota Repercutida, etc..... en estos casos?.

3. ¿CalificacionOperacionType() va a ser "N2" siempre que el Empresario tribute en Canarias, Ceuta/Melilla?. ¿Y en este caso sería siempre una OperacionExenta?
¿En este caso, no habría que rellenar TipoImpositivo, Base Imponible, Cuota Repercutida, etc...., aunque sí tuviesen valor?

Muchas gracias de antemano a todos, y disculpad el "caos" que tengo todavía montado en la cabeza.
Un saludo.

[antoine0]

Empezado por JoseLeeTo

En mi caso, todavía no tiene claro mi empresa si será el Cliente el que decida si se acoge a VeriFactu o no, con lo que tengo que abrir ambas posibilidades mientras no me digan lo contrario (doble de curro para mi, obviamente).

Puedes leer toda la hilera de mensajes. Pero para resumir, creo que el consenso aquí es que tu cliente se va a decantar por un sistema Veri*Factu. Por qué, para que se decante para un sistema no-veri*factu, tiene que tener muy buenas razones, con todos las pegas que tienen estos sistemas.

Realmente, Hacienda está poniendo toda la presión que puede, en su comunicación (de momento), para que las cosas pasen por Veri*factu; por tanto la lógica para tu empresa es convencer al cliente de ir por este lado (y menos curro; o menos inversión, si tienes que venderlo a tu jefe; cosas de palabras).
Aparte de los que quieren ir siempre en contra de lo que dice Hacienda o el gobierno, por qué sí (y tienen todo el derecho de opinar así), creo que las únicas empresas que deben considerar no-veri*factu son las que tienen sistemas en casa que son más baratos de adaptar a este modalidad que al Veri*factu; si no, no tiene lógica ir por este lado.
Y esto antes de hablar del suplemento de costes por ser un sistema de facturación compatible no-veri*factu (con más funciones). Qué serán vendidos en menores cantidades, por tanto con menor retorno de las inversión para las empresas de software.

Tenía entendido que en un sistema NO Verifactu, los XML se guardaban firmados en espera de ser enviados ante un requerimiento de la AEAT, pero ya no me queda nada claro con lo que me comentas de que NO hace falta almacenarlos, sino que como dices solamente se generarán los XML y se firmarán y enviarán en el momento que los requiera hacienda, pero no antes.

No me he explicado bien.
Por supuesto debes firmar en el momento de la generación, no en el momento del envío.
Pero una vez firmado, no estás obligado a almacenar los registros con el mismo formato XML que él que se hará el envío bajo requerimiento: puedes almacenar la firma en un lugar, el contenido de los nodos en otros etc. Solo debes estar en capacidad de garantizar que generarás un XML con el formato correcto para que la firma valide, en el momento de cumplir con algun requerimiento.

Dicho esto, si siguen con la necesidad de referirse a múltiplos esquemas XSD (que era lo opción presentada en el primer borrador que estaba), almacenar y luego presentar los registros dentro de un conjunto por el requerimiento será un lío por culpa de los múltiples xmlns: (hay mensajes anteriores que lo expliquen en la práctica). Si solo se necesita un solo espacio de nombres, es mucho más sencillo deconstruir el XML (y también firmar y validar; ganamos todos). Ya veremos... cuándo se publique.