Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[CarlosArjonomia]

Empezado por Mlopez

Sí, a nosotros también se nos da ese caso y efectivamente lo hacemos así por empresa, es decir para cada cif emisor, su primer registro va como "PrimerRegistro" y los siguientes encadenamiento sobre el anterior de esa empresa/cif emisor.

Si una empresa tiene múltiples TPV's con el mismo NIF/CIF. ¿El encadenamiento puede ir referenciado a cada TPV con su nº de factura diferenciado con un prefijo que identifique el TPV?.

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

Empezado por CarlosArjonomia

Si una empresa tiene múltiples TPV's con el mismo NIF/CIF. ¿El encadenamiento puede ir referenciado a cada TPV con su nº de factura diferenciado con un prefijo que identifique el TPV?.

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.

[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

[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?