Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[rci]

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

Por lo que yo se, el encadenamiento va por NIF/CIF y para todas las operaciones (alta, anulación y subsanación), osea que diría que la respuesta es que no puedes distinguir entre TPVs que tengan el mismo NIF.

Y distinguir por series se puede?

Por ejemplo nuestro programa tiene contadores distintos para facturas simplificadas, para facturas contado y para facturas de albaranes.
Nosotros de momento estamos encadenando las facturas de cada contador.
Si se crea la factura simplificada FS3, la encadenamos con la FS2 creada anteriormente.
Si después se crea la factura contado CO8, la encadenamos con la CO7 y no con la FS3
Ya lo hacemos de esta forma para TicketBAI y no hemos tenido ninguna queja pero en VeriFactu no se si será un problema...
De momento los envíos que hacemos no se queja pero por lo que he leído tampoco valida el encadenamiento...

Que opináis?

Muchas gracias

[pablog2k]

yo creo que el encadenamiento lo van a tratar como ticketbai (sería lo lógico).
Si está justificado que tengas que usar series separadas, ejemplo, tengo 2 tiendas físicas, y la base de datos es física, pues es imposible encadenar una con otra, así que cada tpv me lleva una serie y cada serie lleva un encadenamiento.
Ahora bien, si tienes todo montado en el mismo sitio, o base de datos online (web etc), pues no puedes hacer encadenamientos por series distintas, tendrás que meter todo en el mismo encadenamiento

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

Empezado por rci

Y distinguir por series se puede?

Creo que tampoco.
Nosotros tenemos SERIES distintas, pero tenemos que obviarlas al generar el encadenamiento.

[rci]

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

Creo que tampoco.
Nosotros tenemos SERIES distintas, pero tenemos que obviarlas al generar el encadenamiento.

Muchas gracias Neftali y pablog2k por vuestras respuestas.

Leyendo la normativa creo que tenéis razón, pero voy a enviar una consulta por si a caso

Tan contento que estaba yo utilizando el mismo sistema que para TicketBAI

Gracias

[keno_71]

Empezado por rci

Muchas gracias Neftali y pablog2k por vuestras respuestas.

Leyendo la normativa creo que tenéis razón, pero voy a enviar una consulta por si a caso

Tan contento que estaba yo utilizando el mismo sistema que para TicketBAI

Gracias

rci cuando te conteste Hacienda por favor si es posible coméntala por aquí, estoy en el mismo caso y me gustaría aclarar eso. Gracias!

[rci]

Empezado por keno_71

rci cuando te conteste Hacienda por favor si es posible coméntala por aquí, estoy en el mismo caso y me gustaría aclarar eso. Gracias!

Ya me han contestado y teniais razon

No su planteamiento no es válido.
El encadenamiento debe ser siempre cronológico, ni por series ni por ningún otro criterio que no sea el cronológico de generación de los registros. El encadenamiento sigue el orden secuencial cronológico de la generación de registros de facturación (tanto de alta como de anulación), por lo que cualquier registro nuevo tiene que ir encadenado al registro de facturación inmediatamente anterior.

Si el SIF, por ejemplo, fuera utilizado por distintos Obligados Tributarios, entonces debe existir una cadena por cada NIF del Obligado. Y esta cadena siempre se formará en orden de creación de los registros (sean de alta o de anulación, es independiente). Es decir, el encadenamiento debe ser por SIF y obligado tributario (y siempre realizarse en orden cronológico de creación).

Y sobre si devuelve error o no el encadenamiento, sepan que actualmente no validamos el encadenamiento de los registros (ni si se trata del primer envío o no).

Voy a contestarles con una nueva pregunta porque algunos de nuestros clientes tienen mas de una tienda y tienen dos bases de datos (una en cada sede) y con una réplica de SQL Server, para que la información sea la misma en las dos tiendas, pero permitir que sigan trabajando cuando haya eventuales problemas de comunicación entre ellas.

Pero claro, el envío de datos entre una base de datos y la otra (con la réplica) no es inmediato. por lo tanto no podemos encadenar las facturas de una tienda con las de la otra. A ver que me dicen. Ya os contaré.

Muchas gracias

[bmfranky]

Empezado por rci

Ya me han contestado y teniais razon


Voy a contestarles con una nueva pregunta porque algunos de nuestros clientes tienen mas de una tienda y tienen dos bases de datos (una en cada sede) y con una réplica de SQL Server, para que la información sea la misma en las dos tiendas, pero permitir que sigan trabajando cuando haya eventuales problemas de comunicación entre ellas.

Pero claro, el envío de datos entre una base de datos y la otra (con la réplica) no es inmediato. por lo tanto no podemos encadenar las facturas de una tienda con las de la otra. A ver que me dicen. Ya os contaré.

Muchas gracias

Hola, a mi me contestaron que el encadenamiento es por cada sif(programa) y cif, osea que si teneis varios programas, el encadenamiento es distinto, o usais la misma serie de facturas, para una tienda y la otra?
Por ejemplo pedis a la base de datos central el numero de factura /ticket antes de emitirlo?

[rci]

Empezado por bmfranky

Hola, a mi me contestaron que el encadenamiento es por cada sif(programa) y cif, osea que si teneis varios programas, el encadenamiento es distinto, o usais la misma serie de facturas, para una tienda y la otra?
Por ejemplo pedis a la base de datos central el numero de factura /ticket antes de emitirlo?

Hola bmfranky, si, el programa es el mismo y la base de datos es la "misma" pero realmente son dos que se van replicando.

Usamos series distintas para cada tienda porque antes de emitir la factura se consulta el numero que toca en la base de datos, pero al estar replicada, debemos consultar contadores distintos por no solaparse.

Les he expuesto esto mismo y me han contestado que lo tienen que consultar a los responsables

Tenga en cuenta que a la hora de desarrollar los sistemas informáticos de facturación (SIF), existen diversas y variadas arquitecturas.
Vamos a escalar su consulta a los responsables, por si nos pueden indicar alguna respuesta concreta y para que se tenga en cuenta de cara a la redacción de las preguntas frecuentes que se publicarán en la sede, donde se tratarán ampliamente este tipo de cuestiones (sistemas con varias sedes o terminales).
Cuando tengamos algún tipo de contestación, se la transmitimos.

Creo que antes de cambiar nada voy a esperar si me contestan algo.

Muchas gracias!

[antoniomarquezc]

Hola.
Nuestras aplicaciones van a funcionar solamente en modo VERIFACTU, con subida inmediata.
En las aplicaciones se va a ir generando un "registro de facturación" que irá registrando las altas y modificaciones y que será el que se irá subiendo a la AEAT.
Estoy ya subiendo y procesando las respuestas y almacenando en dicho registro los datos de estado, fecha, etc... y los CSV que envía la AEAT.

Mi duda es que no sé si los ficheros XML que utilizo para enviar y los ficheros XML de respuesta, es necesario conservarlos.

[richidemola]

Empezado por rci

Ya me han contestado y teniais razon


Voy a contestarles con una nueva pregunta porque algunos de nuestros clientes tienen mas de una tienda y tienen dos bases de datos (una en cada sede) y con una réplica de SQL Server, para que la información sea la misma en las dos tiendas, pero permitir que sigan trabajando cuando haya eventuales problemas de comunicación entre ellas.

Pero claro, el envío de datos entre una base de datos y la otra (con la réplica) no es inmediato. por lo tanto no podemos encadenar las facturas de una tienda con las de la otra. A ver que me dicen. Ya os contaré.

Muchas gracias

Entonces entiendo que, si yo genero una factura ordinaria y luego una factura simplificada, la simplificada debe encadenarse con la ordinaria que fue la última que se emitió antes de generar la simplificada no?

Es decir, que no tengo que encadenar las facturas ordinarias entre si y las facturas simplificadas entre si, que aunque vayan en series distintas y sean distintos tipos de factura, se encadenan siempre la última factura que se emita con la anterior emitida independientemente de que tipo de factura y serie lleve.

Estoy en lo cierto?

[bmfranky]

Empezado por richidemola

Entonces entiendo que, si yo genero una factura ordinaria y luego una factura simplificada, la simplificada debe encadenarse con la ordinaria que fue la última que se emitió antes de generar la simplificada no?

Es decir, que no tengo que encadenar las facturas ordinarias entre si y las facturas simplificadas entre si, que aunque vayan en series distintas y sean distintos tipos de factura, se encadenan siempre la última factura que se emita con la anterior emitida independientemente de que tipo de factura y serie lleve.

Estoy en lo cierto?

Os pego la respuesta a esa consula a los responsables.

Buenos días:

El número de factura o serie podrán seguir estableciéndolo de la forma que ustedes convengan sin problema. El encadenamiento debe ser con el registro de facturación inmediatamente anterior, por orden cronológico de generación de registros de facturación en el SIF. Por lo tanto, siguiendo su ejemplo, sería FREP 001 -> FR 166 -> FR 167 -> FREP002/2024.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: [email protected]

Cada programa a de gestionar su propio encadenamiento, ademas de como contestaban a utro post anterior cada sif deve de encadenar sin saltos de facturacion a saber si facturo sobre 3 series/numeroacion aunque sean alternas siempre tengo que enviar las numeraciones correlativas a cada serie.

[pesadillator]

Buenas, he empezado a crear el código para probar verifactu.
He rellenado los datos de la factura en una variable de tipo RegistroFacturacionAltaType, pero luego para enviarlo se tiene que rellenar un tipo RegFactuSistemaFacturacion.
¿Como creo este ultimo tipo y agrego la factura?