Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[afxe]

Según Newton. Hacienda respondió

Para un determinado obligado tributario, el sistema informático producirá una única cadena de registros de facturación, es decir, todos los registros de facturación generados por un mismo sistema informático deberán formar parte de la misma cadena. Si hay varios terminales o dispositivos de facturación pertenecientes al mismo sistema informático, todos ellos deberán generar registros que se integrarán en la única cadena existente para dicho sistema informático"

Eso creo que impide que existan terminales que envíen de forma independiente. Mi idea: Pienso que los terminales generarán prefecturas (por poner un nombre) y se irán encolando en un sistema que procederá a la “facturación” con todo lo que impliqque (generación del xml, encadenado, huella, envio, QR…). Si el sistema es ágil el cliente saldrá por la puerta con su factura verificable… si se produce una sobrecarga o una avería o desconexión de la central, se le podrá poner un QR para que en breve pueda descargarse en el móvil su factura verifactu, o reclamarla posteriormente. Tengo cadenas de supermercados y te aseguro que me cuelgan si se crean colas en las cajas por culpa de tener que esperar por esta normativa… varias están en SII, pero me han pedido cumplir con el verifactu también, y otras varias están fuera del SII…. Es lógico que la entrega de mercancía o prestación de servicio pueda ser en fecha y hora diferente a la de su fiscalización. Y la fiscalización será secuencial, ordenada, inmediata, fehaciente y bla, bla, bla….

[ermendalenda]

Empezado por afxe

Según Newton. Hacienda respondió



Eso creo que impide que existan terminales que envíen de forma independiente. Mi idea: Pienso que los terminales generarán prefecturas (por poner un nombre) y se irán encolando en un sistema que procederá a la “facturación” con todo lo que impliqque (generación del xml, encadenado, huella, envio, QR…). Si el sistema es ágil el cliente saldrá por la puerta con su factura verificable… si se produce una sobrecarga o una avería o desconexión de la central, se le podrá poner un QR para que en breve pueda descargarse en el móvil su factura verifactu, o reclamarla posteriormente. Tengo cadenas de supermercados y te aseguro que me cuelgan si se crean colas en las cajas por culpa de tener que esperar por esta normativa… varias están en SII, pero me han pedido cumplir con el verifactu también, y otras varias están fuera del SII…. Es lógico que la entrega de mercancía o prestación de servicio pueda ser en fecha y hora diferente a la de su fiscalización. Y la fiscalización será secuencial, ordenada, inmediata, fehaciente y bla, bla, bla….

Bueno, según lo que cada uno interprete por cada sistema informático.
Si tienes 4 tpvs en un supermercado y cada uno tiene sus series independiente, posiblemente te acepten cada tpv como un sistema independiente, quizás tengas que reformular la pregunta para que sean más claros.

[afxe]

Empezado por ermendalenda

Bueno, según lo que cada uno interprete por cada sistema informático.
Si tienes 4 tpvs en un supermercado y cada uno tiene sus series independiente, posiblemente te acepten cada tpv como un sistema independiente, quizás tengas que reformular la pregunta para que sean más claros.

No sé... creo que la frase "Para un determinado obligado tributario, el sistema informático producirá una única cadena de registros de facturación" no deja lugar a dudas, el obligado tributario no es cada TPV o PDA de un negocio, seguramente se refiere a un CIF/NIF. Creo que si te dan la posibilidad de empezar tantas cadenas de facturación desde cero como uno quiera no tendría mucho sentido encadenar la factura, incluso se podría llegar a la paradoja de tener tantas series de facturación como facturas, y ya no sería necesario encadenar.

Otra discusión que tenemos es si el envío debe ser inmediato a la emisión de la factura o puedo hacerlo en momentos más propicios... Según el desarrollo técnico del sistema Verifactu dice que tras cada comunicación recibiremos instrucciones de cuando o cuantos registros tendremos que comunicar la siguiente vez, pero no sé si nosotros podemos decidir también la cantidad de registros y establecer ciclos periódicos de comunicación. Varios de mi equipo piensan que debemos ir almacenando los XML y proceder al envío en los tiempos de poca actividad... incluso en la madrugada del día siguiente. Creo haber leído que para que sea Verifactu no se debe demorar más de 60 minutos, pero no sé donde lo vi ni la veracidad que pueda tener.

[antoine0]

Empezado por afxe

No sé... creo que la frase "Para un determinado obligado tributario, el sistema informático producirá una única cadena de registros de facturación" no deja lugar a dudas, el obligado tributario no es cada TPV o PDA de un negocio, seguramente se refiere a un CIF/NIF.

Esta leyendo como si fuese escrito "Para un determinado obligado tributario, el único sistema informático..." Pero esto no está escrito en ningún lugar. Y la respuesta a sglorka contempla claramente la posibilidad de tener más de un SIF para una determinada empresa (NIF).

Creo que si te dan la posibilidad de empezar tantas cadenas de facturación desde cero como uno quiera no tendría mucho sentido encadenar la factura, incluso se podría llegar a la paradoja de tener tantas series de facturación como facturas, y ya no sería necesario encadenar.

Aquí vendrá el inspector diciéndote que hay abuso, y será multa por mala fe. Hay lógica de tener varios SIF por tener varios TPV, ya que son varios ordenadores. No veo tanta lógica en poner varios SIF para un mismo NIF corriendo en un mismo servidor, aunque sería para dos departamentos distintos con dos jefes muy celosos.

Otra discusión que tenemos es si el envío debe ser inmediato a la emisión de la factura o puedo hacerlo en momentos más propicios... Según el desarrollo técnico del sistema Verifactu dice que tras cada comunicación recibiremos instrucciones de cuando o cuantos registros tendremos que comunicar la siguiente vez, pero no sé si nosotros podemos decidir también la cantidad de registros y establecer ciclos periódicos de comunicación.

El sistema (n,t) te ponen límite por debajo en número de registros (n) y en el tiempo de demora (t). Entiendo que no hay límite por encima para el tiempo de demora (para n hay un límite de 10.000 registros). El único lugar dónde veo una restricción está en el artículo 16.1 del RDL (la énfasis es mía):

[...] para remitir efectivamente por medios electrónicos a la Agencia Estatal de Administración Tributaria de forma continuada, segura, correcta, íntegra, automática, consecutiva, instantánea y fehaciente todos los registros de facturación generados [...]

Es cierto que si el sistema de AEAT ha caído o la conexión a internet de la zona está fuera de servicio por motivos externos, no veo muy bien por qué te multen por no cumplir esta instantaneidad, aunque siga definida como "en menos de 60 minutos".
Pero para ponerlo de otra forma, no sé si es posible tener un sistema dónde la presentación al sistema Veri*factura siga suspendida al uso de certificados de usuario, dado que son certificados cuyo acceso no es (o no debería ser) posible si aquel usuario no esté presente: se podrían dar casos dónde no hay ningún usuario habilitado disponible y por tanto no sería posible remitir la información al sitio Veri*Factu, por ejemplo hasta la mañana siguiente. Evidentemente si hay posibilidad o amenaza de sanción en tal caso, habrán empresas dónde la obligación de presencia del usuario se diluirá (tipo instalación de certificados en varios cuentas de usuarios, o comunicación de contraseñas) y al final será una menor seguridad del sistema...

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

Empezado por afxe

...
(1) Pienso que los terminales generarán prefecturas (por poner un nombre) y se irán encolando en un sistema que procederá a la “facturación” con todo lo que implique (generación del xml, encadenado, huella, envio, QR…).
(2) Si el sistema es ágil el cliente saldrá por la puerta con su factura verificable…
(3) Si se produce una sobrecarga o una avería o desconexión de la central, se le podrá poner un QR para que en breve pueda descargarse en el móvil su factura verifactu, o reclamarla posteriormente.

Creo que estás equivocado en el proceso. Me baso en lo que sabemos de ticketBAI y lo que sabemos hasta ahora.
(1) Tu sistema debe generar una factura REAL que el cliente debe llevarse cuando salga de la tienda, supermercado, peluquería,...
Los 2 procesos que hay que separar son:
* La generación de la factura, con encadenamiento y QR (en el ticket). TODO esto debe y puede hacerse sin conexión a Internet.
* El envío, que puede hacerse en ese momento o más tarde, dependiendo del sistema, de las comunicaciones, de internet o de lo que sea. Para eso sí puedes montar una cola.
NOTA: En el caso de ticketBAI la AEAT especifica expresamente que el sistema DEBE poder facturar sin conexión.

(2) El cliente DEBE irse con un ticket REAL y ese es el ticket definitivo (nada de una prefactura, borrador,...).

(3) Si es como TicketBAI como parece, el ticket del cliente DEBE llevar el QR. Con ese QR el cliente puede comprobar su factura y además asegura que esa factura ya no se modifica, ya que lleva las medidas de seguridad correspondiente (encadenamiento de la factura anterior).
Si la factura no se ha podido subir en ese momento (porque la tienda se ha quedado sin internet, por ejemplo) el ticket lleva el QR igualmente con la información de la factura (que ya debe estar generada en tu sistema -y no modificable-). Entiendo que si tú esa factura la subes al día siguiente (porque se te roto el router) el cliente podrá consultarla

Empezado por ermendalenda

Bueno, según lo que cada uno interprete por cada sistema informático.
Si tienes 4 tpvs en un supermercado y cada uno tiene sus series independiente, posiblemente te acepten cada tpv como un sistema independiente, quizás tengas que reformular la pregunta para que sean más claros.

Yo lo veo por ahí también.
Pienso también en empresas con delegaciones, donde lo habitual son series distintas, aunque la facturación se hace por 1 sólo ente.
Sería limitar cómo debes tú facturar (más restrictivo que la ley de facturación).

Empezado por afxe

(1) No sé... creo que la frase "Para un determinado obligado tributario, el sistema informático producirá una única cadena de registros de facturación" no deja lugar a dudas, el obligado tributario no es cada TPV o PDA de un negocio, seguramente se refiere a un CIF/NIF.

(2) Creo que si te dan la posibilidad de empezar tantas cadenas de facturación desde cero como uno quiera no tendría mucho sentido encadenar la factura, incluso se podría llegar a la paradoja de tener tantas series de facturación como facturas, y ya no sería necesario encadenar.

(1) El "Corte Inglés" tiene un único CIF, pero no creo que puedas obligar a todos los establecimientos/TPV/Delegaciones a enviar con la misma serie.
(2) Basándome también en TicketBAI, hay unas normas para crear una nueva serie. Esto que describes no se puede hacer. Y en todo caso la creación hay que justificarla (por ejemplo al empezar un nuevo ejercicio).

[pablog2k]

muy de acuerdo con Nefta en todo lo comentado, sería lo más lógico que se hiciera todo intentando parecerse a lo que ya está hecho con ticketbai

[ermendalenda]

No es práctico que vayan encadenados por cif, tu mismo tienes la preocupación de las colas.
Lo de que mandes antes de 1 hora no lo has interpretado bien. Dice que si tienes problemas con la comunicacion tiene que haber un intento cada hora mínimo, ya mandas cuando se pueda.
Ninguna empresa va a tener un servicio de atención tan inmediato ante una incidencia, las 24h del dia los 365 dias del año.
Cada sistema SIF será un identificador, y en cada identificador tendras una serie para los tiquets y/o facturas, para rectificaivas. Ejemplo que yo uso
Comercio numero 44
Serie tiquets (1)


tpv 1
Serie: 44.1.1
Nº Factura : xxx

tpv 2
Serie: 44.2.1
Nº Factura : xxx

tpv 3
Serie: 44.3.1
Nº Factura : xxx

Cada tpv con su numerador y su blockchain de la huella.

No te compliques de verdad.

[antoine0]

Empezado por pablog2k

muy de acuerdo con Nefta en todo lo comentado, sería lo más lógico que se hiciera todo intentando parecerse a lo que ya está hecho con ticketbai

También de acuerdo. Por algo han dado como identificado "tike" a la aplicación Veri*factu (//prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/SistemaFacturacion.wsdl)

[sglorka]

Empezado por afxe

Según Newton. Hacienda respondió



Eso creo que impide que existan terminales que envíen de forma independiente. Mi idea: Pienso que los terminales generarán prefecturas (por poner un nombre) y se irán encolando en un sistema que procederá a la “facturación” con todo lo que impliqque (generación del xml, encadenado, huella, envio, QR…). Si el sistema es ágil el cliente saldrá por la puerta con su factura verificable… si se produce una sobrecarga o una avería o desconexión de la central, se le podrá poner un QR para que en breve pueda descargarse en el móvil su factura verifactu, o reclamarla posteriormente. Tengo cadenas de supermercados y te aseguro que me cuelgan si se crean colas en las cajas por culpa de tener que esperar por esta normativa… varias están en SII, pero me han pedido cumplir con el verifactu también, y otras varias están fuera del SII…. Es lógico que la entrega de mercancía o prestación de servicio pueda ser en fecha y hora diferente a la de su fiscalización. Y la fiscalización será secuencial, ordenada, inmediata, fehaciente y bla, bla, bla….

Te copia la consulta que le hice al correo de Verifactu y su respuesta

"Buenos días.
Adjunto hilo de conversación relativo a la última comunicación mantenida para aclarar un concepto importante.
El SFC (sistema de facturación central) genera su propia línea de registros de facturación, generando un encadenamiento exclusivamente, de los registros de facturación que se generan en este sistema informático.
El Tpv, deslocalizado geográficamente, es independiente del sistema de facturación central y genera su propia línea de registros de facturación, generando un encadenamiento exclusivo de los registros de facturación que éste genera.
Tenemos por tanto, dos líneas de registros de facturación independientes pertenecientes al mismo obligado tributario que van a ser enviadas al Aeat. Se entiende por tanto, que no habrá problemas con la trazabilidad de los registros ya que cada línea de facturación se identifica con el Código de identificación del sistema informático que la ha generado.
Hago este planteamiento porque puede ocurrir que el tpv envíe un registro de alta de facturación creado por él a la Aeat y seguidamente, el sistema de facturación central envíe otro registro de facturación distinto creado por él. Obviamente, no existe encadenamiento entre estos dos registros, aunque sí existirá encadenamiento entre cada registro enviado y su anterior cuando ambos registros fueron generados por el mismo SIF.
Espero haber sido claro en mi exposión"

Su Respuesta

"Si lo que se está consultando es que dos SIF distintos (de un mismo contribuyente) pueden generar sendas cadenas de facturación distintas (cada uno la suya) con los registros de facturación correspondientes a las facturas (distintas) por ellos expedidas y que, por tanto, los registros de facturación de las facturas de un mismo contribuyente pueden estar repartidos entre ellos, solo estando encadenados entre sí los que pertenezcan a un mismo SIF y no los de un SIF con respecto al otro SIF: sí es correcto el planteamiento.

Esto es lógico porque el encadenamiento se realiza a nivel de SIF, no a nivel de contribuyente (solo estarían encadenados todos los registros de facturación de un contribuyente cuando tuviera un solo SIF que los generara).
Lo que no sería coherente es que dos SIF distintos enviaran el mismo registro a la AEAT (en el ejemplo propuesto, que el SFC y el TPV envíen información del mismo registro de facturación)."

[ermendalenda]

Empezado por sglorka

Te copia la consulta que le hice al correo de Verifactu y su respuesta

"Buenos días.
Adjunto hilo de conversación relativo a la última comunicación mantenida para aclarar un concepto importante.
El SFC (sistema de facturación central) genera su propia línea de registros de facturación, generando un encadenamiento exclusivamente, de los registros de facturación que se generan en este sistema informático.
El Tpv, deslocalizado geográficamente, es independiente del sistema de facturación central y genera su propia línea de registros de facturación, generando un encadenamiento exclusivo de los registros de facturación que éste genera.
Tenemos por tanto, dos líneas de registros de facturación independientes pertenecientes al mismo obligado tributario que van a ser enviadas al Aeat. Se entiende por tanto, que no habrá problemas con la trazabilidad de los registros ya que cada línea de facturación se identifica con el Código de identificación del sistema informático que la ha generado.
Hago este planteamiento porque puede ocurrir que el tpv envíe un registro de alta de facturación creado por él a la Aeat y seguidamente, el sistema de facturación central envíe otro registro de facturación distinto creado por él. Obviamente, no existe encadenamiento entre estos dos registros, aunque sí existirá encadenamiento entre cada registro enviado y su anterior cuando ambos registros fueron generados por el mismo SIF.
Espero haber sido claro en mi exposión"

Su Respuesta

"Si lo que se está consultando es que dos SIF distintos (de un mismo contribuyente) pueden generar sendas cadenas de facturación distintas (cada uno la suya) con los registros de facturación correspondientes a las facturas (distintas) por ellos expedidas y que, por tanto, los registros de facturación de las facturas de un mismo contribuyente pueden estar repartidos entre ellos, solo estando encadenados entre sí los que pertenezcan a un mismo SIF y no los de un SIF con respecto al otro SIF: sí es correcto el planteamiento.

Esto es lógico porque el encadenamiento se realiza a nivel de SIF, no a nivel de contribuyente (solo estarían encadenados todos los registros de facturación de un contribuyente cuando tuviera un solo SIF que los generara).
Lo que no sería coherente es que dos SIF distintos enviaran el mismo registro a la AEAT (en el ejemplo propuesto, que el SFC y el TPV envíen información del mismo registro de facturación)."

Claro, es lo lógico,.a nivel de tpv.
No puedes poner colas de espera para recuperar contador y huella anterior a un contribuyente por ejemplo con 100 centros y un total de 300tpvs que tienen un software de escritorio, imagina que se bloquea el registro de nuneracion por que un tpv ha dado problemas, o que no haya conexión a internet o a la vpn de la empresa por un bloqueo del router... mil cosas. Cada tpv su cadena , al menos en los programas de escritorio igual que ticketbai.

[_Io]

Hola, buenas tardes.

Me estoy liando y tengo la cabeza a punto de reventar

¿Qué diferencia hay entre el XML de la factura (la que se guarda y calcula el HASH) y el XML de alta (el que se envía a la AEAT ?

Siento ser tan Pesado

Muchas Gracias.

[nincillo]

Empezado por _Io

Hola, buenas tardes.

Me estoy liando y tengo la cabeza a punto de reventar

¿Qué diferencia hay entre el XML de la factura (la que se guarda y calcula el HASH) y el XML de alta (el que se envía a la AEAT ?

Siento ser tan Pesado

Muchas Gracias.

Hasta donde yo voy entendiendo, el xml de la factura lo vas generando cada vez que facturas, calculando su hash, etc.
Luego, cuando cada x tiempo vas haciendo los envíos, lo que hace es cargar y ficheros xml de facturas y los envías de una sola vez a hacienda. El x y el y puede variar según las necesidades que te marque hacienda en cada momento.

Aprovechando. ¿Conseguiste avanzar algo con lo que comentabas en tu post anterior de generar el xml partiendo de los xsd?.

Un saludo y espero que los que ya lo tienen más avanzando nos confirmen o corrijan.

[_Io]

Buenas dias.

Todavía no puedo poner enlaces, tengo el usuario limitado.

nincillo
Hasta donde yo voy entendiendo, el xml de la factura lo vas generando cada vez que facturas, calculando su hash, etc.
Luego, cuando cada x tiempo vas haciendo los envíos, lo que hace es cargar y ficheros xml de facturas y los envías de una sola vez a hacienda. El x y el y puede variar según las necesidades que te marque hacienda en cada momento.


Esto más o menos lo tengo claro.
Es la estructura de cada archivo xml. El compañero Maska10, te contestó sobre la posible diferencia en el postpost #961, página 49, que elarchivo de la factura iba sin el nodo cabecera y el archivo que se manda si la lleva, pero no he visto ningún ejemplo.

nincillo
¿Conseguiste avanzar algo con lo que comentabas en tu post anterior de generar el xml partiendo de los xsd?.


Tengo problemas y no avanzo.

Saludos.

Saludos.