Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por nincillo

Hasta donde yo entiendo (y quizás lo entienda mal). Por un lado está la generación del xml correspondiente a la factura, con su hash y demás, y por otro lado está el envío de dichos xml a hacienda.

Si estoy en lo correcto, quizás la generación del xml sería por parte del equipo que genera la factura y que la dejaría en una carpeta "común" y por otro lado está el programa dedicado al envío de dichos ficheros xml a Hacienda, que no tiene por que hacerlo en tiempo real, ya que según he leído por ahí, la propia hacienda puede marcar el ritmo de envío y el número de facturas a enviar en cada envío.

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

La otra opción que he pensado es con algún sistema de flags, que cada vez que algún equipo equipo genere una factura, un programa en el servidor genere todos los xml de las facturas que se hayan generado desde la última vez o algo así...

Y la facturación en bloque de fin de mes, que se pueden generar cientos de facturas en un momento... En fin... Poco a poco...

Hay que hacerlo en fifo, 2 equipos con la misma serie, inevitablemente leen el siguiente njnero de factura en orden cronológico, por tanto da igual quien lo genere que tendrá un orden cronológico, lo que sí se ve es que el envío tiene que ser común para la misma serie.
Yo por ejemplo eso no voy a tener problemas por qur para distintos tpvs tengo números de serie diferente y si hay algún dispositivo más enganchado al tpv(una.pda por ejemplo o un cajón de cobro automatico, o incluso otro tpv satelite) leen y escriben en el mismo sitio, controlando bien los índices únicos no existe problemas.

[ermendalenda]

Empezado por antoine0

Mmmm.... Empresa grande y ERP, pero no en el S.I.I.... ¿Habrá muchas?

Sí, las hay.

[antoine0]

Empezado por nincillo

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

Es un problema clásico de cola, con un recurso único. Cuando cualquier programa (de varios) está listo para encadenar (es decir, XML del registro generado hasta la parte EncadenamientoRegistroAnterior), se pone en cola para obtener esta información. Él que está en cabeza de la cola entra en sección crítica (mútex), recupera la información del último registro (ID, huella y hora de generación), recupera la hora actual, acaba de completar el XML, calcula su huella, graba el registro ya completado con su DatosControl (la firma se podrá actualizar más tarde, y evidentemente las incidencias también), este registro pasa a ser el último, y puede salir de la sección crítica, liberando para el siguiente en la cola.

El tema de los números de nueva factura pueden gestionarse de la misma manera, es decir atribulándose dentro de la sección crítica; pero no tengo claro si es un requisito imprescindible de los sistemas de facturación que los registros de factura tipo S0 sigan encadenados en orden estrictamente ascendente de número de factura en cada serie (muy posible que me he perdido algo aquí). Obviamente es muy preferible, pero creo que se puede haber circunstancias como las que describes que hacen que los números pueden resultar desordenados a veces, en caso de incidencia en la generación del registro después de haber obtenido un número de futura factura. Y desde luego, dado que el número de factura está mezclado con el número de serie en el campo IDFactura, no veo como Hacienda puede automatizar un control de este requisito.

[sglorka]

Empezado por antoine0

Yo lo haría de una forma un poco distinta:

<AltaFactuSistemaFacturacion xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd"> ... </Cabecera>
<Alta:RegistroAltaFacturas xmlns:Alta="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<LR:RegistroFacturacion xmlns:LR="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<IDFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDEmisorFactura> ....

La idea es que los espacios de nombres Alta y LR aparecen distintos dentro del documento pero en realidad son el mismo esquema. Habrá que probar con la herramienta de Hacienda pero creo que en XML es válido.
Lo he hecho con dos espacios de nombres explícitos para que se entiende mejor, pero supongo que el segundo puede ser el espacio por defecto. Evidentemente hay que ponerlo para que al final lo que aparece en lo que se está enviando a Hacienda siga exactamente lo mismo que lo que se ha usado para calcular la huella y eventualmente firmar.

Se te ocurre cómo incluir esos espacios de nombres con el objeto serialiazer

Dim AltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim serializer As New System.Xml.Serialization.XmlSerializer(GetType(ServicioVeriFactu.AltaFactuSistemaFacturacion))
Dim writer As New System.IO.StreamWriter("RegistroAltaFactura.Xml")

serializer.Serialize(writer, AltaRegistro)
writer.Close()

[antoine0]

Empezado por sglorka

Se te ocurre cómo incluir esos espacios de nombres con el objeto serialiazer

Dim AltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim serializer As New System.Xml.Serialization.XmlSerializer(GetType(ServicioVeriFactu.AltaFactuSistemaFacturacion))
Dim writer As New System.IO.StreamWriter("RegistroAltaFactura.Xml")

serializer.Serialize(writer, AltaRegistro)
writer.Close()

¿Has intentado crear dos objetos del mismo tipo ServicioVeriFactu.AltaFactuSistemaFacturacion?
Algo como

Dim ServicioAltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim RegistroEnSi as ServicioVeriFactu.AltaFactuSistemaFacturacion

... y luego pasar por dos objetos XmlSerializer, uno que escribe dentro del segundo (si se ve mucho que no tengo práctica, concretamente nula con dotNet, es que es así ).

La idea subyacente es que hay que separar las dos partes, de una parte la generación del registro (y su posterior almacenamiento) del envío a Hacienda con el servicio web. El segundo se debe alimentar del resultado del primero, no se debería volver a crear el XML entero porqué, como bien has dicho antes, es problemático volver a generar el mismo contenido que él con cual se calculó la huella.

[ermendalenda]

Empezado por antoine0

Es un problema clásico de cola, con un recurso único. Cuando cualquier programa (de varios) está listo para encadenar (es decir, XML del registro generado hasta la parte EncadenamientoRegistroAnterior), se pone en cola para obtener esta información. Él que está en cabeza de la cola entra en sección crítica (mútex), recupera la información del último registro (ID, huella y hora de generación), recupera la hora actual, acaba de completar el XML, calcula su huella, graba el registro ya completado con su DatosControl (la firma se podrá actualizar más tarde, y evidentemente las incidencias también), este registro pasa a ser el último, y puede salir de la sección crítica, liberando para el siguiente en la cola.

El tema de los números de nueva factura pueden gestionarse de la misma manera, es decir atribulándose dentro de la sección crítica; pero no tengo claro si es un requisito imprescindible de los sistemas de facturación que los registros de factura tipo S0 sigan encadenados en orden estrictamente ascendente de número de factura en cada serie (muy posible que me he perdido algo aquí). Obviamente es muy preferible, pero creo que se puede haber circunstancias como las que describes que hacen que los números pueden resultar desordenados a veces, en caso de incidencia en la generación del registro después de haber obtenido un número de futura factura. Y desde luego, dado que el número de factura está mezclado con el número de serie en el campo IDFactura, no veo como Hacienda puede automatizar un control de este requisito.

Sanción por facturas no correlativas
La sanción por emitir facturas que no guardan correlación y seguimiento numérico se considera una falta leve según Hacienda y por la que tendrías que pagar llegados al caso unos 150€ por cada factura que no se haya emitido correlativamente.
Una de las reglas básicas es que deben llevar un orden numérico y cronológico sin saltos y sin vueltas atrás en el orden de tiempo.
Que sancionen o no, antes dependía del inspector, a partir de ahora no sabemos.

[sglorka]

Empezado por antoine0

¿Has intentado crear dos objetos del mismo tipo ServicioVeriFactu.AltaFactuSistemaFacturacion?
Algo como

Dim ServicioAltaRegistro as ServicioVeriFactu.AltaFactuSistemaFacturacion
Dim RegistroEnSi as ServicioVeriFactu.AltaFactuSistemaFacturacion

... y luego pasar por dos objetos XmlSerializer, uno que escribe dentro del segundo (si se ve mucho que no tengo práctica, concretamente nula con dotNet, es que es así ).

La idea subyacente es que hay que separar las dos partes, de una parte la generación del registro (y su posterior almacenamiento) del envío a Hacienda con el servicio web. El segundo se debe alimentar del resultado del primero, no se debería volver a crear el XML entero porqué, como bien has dicho antes, es problemático volver a generar el mismo contenido que él con cual se calculó la huella.

Se podría crear el registro inicial que se va a almacenar del tipo ServicioVeriFactu.AltaFactuSistemaFacturacion, luego no hay problema al crear el mensaje de envío con todos los registros pendientes ya que se puede extraer de cada registro individual el objeto <Registrofacturación> y añadirlos al mensaje de envío para enviar varios a la vez. Este método si funciona pero lo que me echa para atrás es que en el diseño que proponen DR_Alta CE, que se supone que es para almacenar los registros individuales, exigen que el objeto sea del tipo <FacturaExpedidaType> y no sé si eso puede crear problemas.
En resumen, entiendo que los registros de facturación generados deben almacenarse en Xml bajo la estructura <FacturaExpedidaType> y una vez que los vas a comunicar construyes el objeto ServicioVeriFactu.AltaFactuSistemaFacturacion

[[newtron]]

El tema del orden no debería de ser problema. Aprovechando que todavía no sé cómo aislar el nodo de cada factura para generar el hash lo que estoy barruntando es que al emitir la factura se genere un XML con el nodo de esa factura en alguna carpeta, que haya un programa que esté leyendo esa carpeta y que según vayan entrando vaya leyendo el XML, generando el hash y meterlo en una "pila" donde se irá generando el XML definitivo con su cabecera para enviarlo. Claro, esto obligaría a crear y enviar el XML de forma manual, cosa que no sé si mola mucho.


No sé vosotros cómo lo veis.


Saludos.

[antoine0]

Empezado por ermendalenda

Sanción por facturas no correlativas
La sanción por emitir facturas que no guardan correlación y seguimiento numérico se considera una falta leve según Hacienda y por la que tendrías que pagar llegados al caso unos 150€ por cada factura que no se haya emitido correlativamente.
Una de las reglas básicas es que deben llevar un orden numérico y cronológico sin saltos y sin vueltas atrás en el orden de tiempo.

Ya. El problema es saber dónde está la norma de tiempo. Hasta ahora, era claro que la norma era la fecha (día) indicada en la factura; y es lo que sigue diciendo el artículo 6.1 b del reglamento de facturación. Todas las facturas de un mismo día deben tener un número superior a las de los días anteriores, sin salto.
Implícitamente, le estas sustituyendo como norma de tiempo la fecha-hora (con ±1 minuto de precisión) del registro S0 de la factura dentro del sistema de facturación. Esta fecha-hora solo se puede ver si se mira el registro S0; no hay que perder de vista que este registro S0 puede ser «mejorado» por un registro S1 ulterior, que será el registro al cual está ligado la factura real.

Hay otro tema relacionado con las fechas que no tengo claro: ¿es correcto emitir una factura que lleva fecha (el día impreso) distinto a la fecha del registro?
El reglamento 2007/23 dice (artículo 9) que un registro debe ser generado simultáneamente o inmediatamente anterior a la expedición; por tanto parece decir que fechas distintas no son posibles, solo se pueden expedir facturas llevando fecha de expedición de hoy.
Sin embargo, en muchos pequeños comercios veo a gente que hacen sus facturas cuando tiene tiempo de hacerlo, por ejemplo los finales de semana, y ponen como fecha a menudo la de final del mes; ¿tendrán que cambiar de costumbre?
Al mismo tiempo, veo a una empresa nacional de telecomunicación que emite sus facturas con 7 días de antelación (hoy emiten las facturas con fecha 19/1/2024); cierto que están en el S.I.I. (y no sé en qué día reporten en SII, supongo que dentro de 7 días) entonces no veré un QR, pero la práctica no para de sorprenderme.

[sglorka]

Empezado por antoine0

Ya. El problema es saber dónde está la norma de tiempo. Hasta ahora, era claro que la norma era la fecha (día) indicada en la factura; y es lo que sigue diciendo el artículo 6.1 b del reglamento de facturación. Todas las facturas de un mismo día deben tener un número superior a las de los días anteriores, sin salto.
Implícitamente, le estas sustituyendo como norma de tiempo la fecha-hora (con ±1 minuto de precisión) del registro S0 de la factura dentro del sistema de facturación. Esta fecha-hora solo se puede ver si se mira el registro S0; no hay que perder de vista que este registro S0 puede ser «mejorado» por un registro S1 ulterior, que será el registro al cual está ligado la factura real.

Hay otro tema relacionado con las fechas que no tengo claro: ¿es correcto emitir una factura que lleva fecha (el día impreso) distinto a la fecha del registro?
El reglamento 2007/23 dice (artículo 9) que un registro debe ser generado simultáneamente o inmediatamente anterior a la expedición; por tanto parece decir que fechas distintas no son posibles, solo se pueden expedir facturas llevando fecha de expedición de hoy.
Sin embargo, en muchos pequeños comercios veo a gente que hacen sus facturas cuando tiene tiempo de hacerlo, por ejemplo los finales de semana, y ponen como fecha a menudo la de final del mes; ¿tendrán que cambiar de costumbre?
Al mismo tiempo, veo a una empresa nacional de telecomunicación que emite sus facturas con 7 días de antelación (hoy emiten las facturas con fecha 19/1/2024); cierto que están en el S.I.I. (y no sé en qué día reporten en SII, supongo que dentro de 7 días) entonces no veré un QR, pero la práctica no para de sorprenderme.

Sí, se pueden emitir facturas que tenga fecha de emisión distinta de la fecha de registro. El caso más claro es la factura rectificativa por sustitución. Si se emite una factura con error en la fecha de expedición se puede emitir una rectificativa por sustitución con la fecha de expedición correcta, y en este caso, obviamente tendrías fechas diferentes de emisión y registro

Otro caso muy común es emitir facturas un viernes con fecha del lunes (ya que la empresa no trabaja los fines de semana) para adelantar trabajo y que el lunes salgan los repartidores temprano.

[ermendalenda]

Empezado por antoine0

Ya. El problema es saber dónde está la norma de tiempo. Hasta ahora, era claro que la norma era la fecha (día) indicada en la factura; y es lo que sigue diciendo el artículo 6.1 b del reglamento de facturación. Todas las facturas de un mismo día deben tener un número superior a las de los días anteriores, sin salto.
Implícitamente, le estas sustituyendo como norma de tiempo la fecha-hora (con ±1 minuto de precisión) del registro S0 de la factura dentro del sistema de facturación. Esta fecha-hora solo se puede ver si se mira el registro S0; no hay que perder de vista que este registro S0 puede ser «mejorado» por un registro S1 ulterior, que será el registro al cual está ligado la factura real.

Hay otro tema relacionado con las fechas que no tengo claro: ¿es correcto emitir una factura que lleva fecha (el día impreso) distinto a la fecha del registro?
El reglamento 2007/23 dice (artículo 9) que un registro debe ser generado simultáneamente o inmediatamente anterior a la expedición; por tanto parece decir que fechas distintas no son posibles, solo se pueden expedir facturas llevando fecha de expedición de hoy.
Sin embargo, en muchos pequeños comercios veo a gente que hacen sus facturas cuando tiene tiempo de hacerlo, por ejemplo los finales de semana, y ponen como fecha a menudo la de final del mes; ¿tendrán que cambiar de costumbre?
Al mismo tiempo, veo a una empresa nacional de telecomunicación que emite sus facturas con 7 días de antelación (hoy emiten las facturas con fecha 19/1/2024); cierto que están en el S.I.I. (y no sé en qué día reporten en SII, supongo que dentro de 7 días) entonces no veré un QR, pero la práctica no para de sorprenderme.

La fecha de emisión de la factura debe ser la misma fecha de la prestación de servicio o entrega de mercancía, según el caso, también se puede dar el caso de las entregas a cuenta para un servicio, que tengo entendido que hay que emitir también una factura y ya después descontarla en la factura total. Sobre los reglamentos de facturación yo ya le daba carpetazo para los temas específicos, el reglamento verifactu es claro diciendo que este reglamento está por encima de cualquier otro reglamento existente, a ver uqe nos cuenta cuando cierren el proyecto.

[sglorka]

Empezado por sglorka

Se podría crear el registro inicial que se va a almacenar del tipo ServicioVeriFactu.AltaFactuSistemaFacturacion, luego no hay problema al crear el mensaje de envío con todos los registros pendientes ya que se puede extraer de cada registro individual el objeto <Registrofacturación> y añadirlos al mensaje de envío para enviar varios a la vez. Este método si funciona pero lo que me echa para atrás es que en el diseño que proponen DR_Alta CE, que se supone que es para almacenar los registros individuales, exigen que el objeto sea del tipo <FacturaExpedidaType> y no sé si eso puede crear problemas.
En resumen, entiendo que los registros de facturación generados deben almacenarse en Xml bajo la estructura <FacturaExpedidaType> y una vez que los vas a comunicar construyes el objeto ServicioVeriFactu.AltaFactuSistemaFacturacion

Creo que este problema está resuelto. Si el sistema es VeriFactu, no estamos obligados a almacenar, conservar y exportar los registros de facturación, por lo tanto, se pueden generar de inicio como si lo fuéramos a enviar de 1 en 1 <AltaFactuSistemaFacturacion>. Dependiendo luego del control de flujo, podemos enviarlos de 1 en 1 ó empaquetarlos para su envío según indique la tupla (n,t)

[rkinformatika]

Buenas noches,

Estan disponibles los entornos de prueba? Estoy intentando buscar y no llego a encontrar. Veo en el XSDL (SistemaFacturacion.wsdl) sale address location="xxxxxxxxxx".

<wsdl:service name="sfService">
<!-- Entorno de PRODUCCION -->
<wsdlort name="SistemaFacturacion" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
<!-- Entorno de PRODUCCION para acceso con certificado de sello -->
<wsdlort name="SistemaFacturacionSello" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
<!-- Entorno de PRUEBAS -->
<wsdlort name="SistemaFacturacionPruebas" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
<!-- Entorno de PRUEBAS para acceso con certificado de sello -->
<wsdlort name="SistemaFacturacionPruebasSello" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
</wsdl:service>

¿Eso quiere decir que aun no estan disponibles?

Muchas gracias.

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

[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)."

[sglorka]

Empezado por rkinformatika

Buenas noches,

Estan disponibles los entornos de prueba? Estoy intentando buscar y no llego a encontrar. Veo en el XSDL (SistemaFacturacion.wsdl) sale address location="xxxxxxxxxx".

<wsdl:service name="sfService">
<!-- Entorno de PRODUCCION -->
<wsdlort name="SistemaFacturacion" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
<!-- Entorno de PRODUCCION para acceso con certificado de sello -->
<wsdlort name="SistemaFacturacionSello" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
<!-- Entorno de PRUEBAS -->
<wsdlort name="SistemaFacturacionPruebas" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
<!-- Entorno de PRUEBAS para acceso con certificado de sello -->
<wsdlort name="SistemaFacturacionPruebasSello" binding="sfWdsl:sfBinding">
<soap:address location="xxxxxxxxxx"/>
</wsdlort>
</wsdl:service>

¿Eso quiere decir que aun no estan disponibles?

Muchas gracias.

Aún no están disponibles, se publicarán en la sede electrónica del aeat. Lo pone en la orden ministerial en la Disposición Adicional primera

[rkinformatika]

Empezado por sglorka

Aún no están disponibles, se publicarán en la sede electrónica del aeat. Lo pone en la orden ministerial en la Disposición Adicional primera

Muchas gracias!

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