Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

[bmfranky]

pues ya nos vas contando, pero siendo dos tiendas, personalmente, asignaria dos series distintas y que encadene cada una por su cuenta, te evitas el tener que consultar por el numero de factura a asignar, otra cosa es que sincronices estocaje, y salvaguardes las facturas en otro servidor.
Pero las facturas, mas simple dos series distintas, o almenos ai lo veo yo...

[antoine0]

Empezado por bmfranky

pues ya nos vas contando, pero siendo dos tiendas, personalmente, asignaria dos series distintas y que encadene cada una por su cuenta, te evitas el tener que consultar por el numero de factura a asignar, otra cosa es que sincronices estocaje, y salvaguardes las facturas en otro servidor.
Pero las facturas, mas simple dos series distintas, o almenos ai lo veo yo...

Creo que el problema no es si debes usar dos series (doy por sentado que sí), pero si puedes usar dos cadenas (considerando que son dos SIF distintos).

Si se puede usar dos cadenas en tal caso, el desarrollo es relativamente sencillo, cada uno en su casa. Habrá dos números de instalación distintos, dos declaraciones responsables etc. Y por supuesto un solo código.

Si está prohibido hacerlo, hay que crear un punto centralizado de encadenamiento (que puede ser repartido entre los dos centros) y la complejidad aumenta bastante.

[rci]

Empezado por rci

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



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

Muchas gracias!

Me han contestado de verifactu a la pregunta sobre el encadenamiento de un mismo obligado tributario que utiliza la misma base de datos pero replicada en dos tiendas

Buenos días: 

En este caso con dos instalaciones físicas con interconexión consideramos que la mejor opción es que manejen dos SIF distintos, aunque sea el mismo obligado tributario. 
Con cualquier dato que se modifique del SIF, como puede ser el NumeroInstalacion, provoca que sea un SIF distinto por lo que cada uno debe tener su encadenamiento propio.

Gracias a todos por las aportaciones!

[keno_71]

me surge una duda, visto los comentarios anteriores, si cambia el número de instalación es porque ha cambiado la versión entiendo ¿no?, ¿en qué punto tenemos distinto número de instalación y misma versión?

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