Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[edari]

Empezado por espinete

Completamente de acuerdo con todo, pero especialmente con esto:

"Yo recuerdo una época en la que el 80% del trabajo de mi empresa no era para cumplir los requisitos de la administración (y lo que nos queda)"

Llevo meses pensando lo mismo. Como si no tuviéramos otros proyectos, trabajo, etc. que hacer en la empresa...

Es una puñetada porque los clientes no saben valorar lo que "cuesta" todo esto solo ven que tu ritmo habitual de evolución del software ha cambiado significativamente

[Logan05]

Buenos días,

soy programador en una muy pequeña empresa, y me veo en el trance de tener que actualizar varias aplicaciones de facturación desarrolladas hace años en vb6, a medida para pequeños comercios locales....

Buscando y buscando he dado con este foro, que aunque no sea de vb6, me parece magnífico, así que he seguido todo el hilo y me está aclarando muchos conceptos, pero como novato en relaciones con la AEAT, soy todo dudas y no se muy bien por donde meterle mano.

Por ejemplo, se supone que tienes que mandarle un XML a hacienda de forma inmediata (máximo 2 horas) de cada factura simplificada o no que hagas, eso puede ser igual 3, que 30, o que 300 XML en un día, pero por otra parte leo que hay que agruparlos en bloques de al menos 1000, pero ¿cómo leches voy a agruparlos si sólo genero 30 en un día? en los negocios pequeñitos no hay tantísimo movimiento, pero por otra parte, si todos, desde toda España, los mandamos uno a uno ¿no va a fliparlo el servidor de la AEAT?.

Aunque he estado viendo cosas para usar servicios web SOAP desde vb6, estoy dando mis primeros pasos para intentar comunicarme con el entorno de pruebas del SII para luego pasar a VERIFACTU, es mi primera experiencia con este tema, así que, en fin, os agradeceré cualquier indicación, idea, guía, ejemplo, manual, lo que sea, porque lo que he encontrado es todo con HTTP y supongo que ahora deberá ser con HTTPS.

Muchísimas GRACIAS de antemano, e intentaré aportar lo que pueda.

[keno_71]

Hola Logan, tienes que enviar cada x tiempo o x facturas lo que pase antes, esto te lo comunicará la aeat. En el SII tienes plataformas de pruebas para probar ya la conexión con la AEAT, de todas formas se supone que cuando aprueben el OM o quizás días más tarde activaran la plataforma de pruebas de verifactu y habrá 9 meses para llevarlo a cabo. Ahí ya podrás hacer pruebas en verifactu y ya creo que podremos ir resolviendo dudas y es cuando este foro se volverá estresante :-)

Bienvenido y has llegado al mejor foro que hay

[CarlosR]

Empezado por newtron

Buenas.


Estoy intentando aclararme un poco cómo hacer lo de la firma del registro pero no lo veo. El compañero Jesusggc puso amablemente un ejemplo en vb pero no acabo de ver la luz.


¿Hay que generar un fichero XML en disco para firmarlo? ¿No se puede hacer en memoria? ¿Alguien le ha dado ya solución a esto en Delphi?


Gracias y un saludo.

Edito: Estoy viendo que hace algunas semanas el colega Delphier puso a disposición una dll para esto precisamente. Haré pruebas con ello pero si alguien le ha dado alguna otra solución se admiten ideas.

Que yo sepa no hay que firmar veri*factu. Solo has de usar un certificado digital para enviar datos a la AEAT.
Lo que sí hay que firmar es el xml donde esté instalado un soft dual o No veri*factu. Al igual que los eventos.

[Logan05]

Empezado por keno_71

Hola Logan, tienes que enviar cada x tiempo o x facturas lo que pase antes, esto te lo comunicará la aeat. En el SII tienes plataformas de pruebas para probar ya la conexión con la AEAT, de todas formas se supone que cuando aprueben el OM o quizás días más tarde activaran la plataforma de pruebas de verifactu y habrá 9 meses para llevarlo a cabo. Ahí ya podrás hacer pruebas en verifactu y ya creo que podremos ir resolviendo dudas y es cuando este foro se volverá estresante :-)

Bienvenido y has llegado al mejor foro que hay

Muchas gracias por la info y la bienvenida , entonces seguiré leyendo y preparándome para el "parto"

[CarlosR]

Empezado por CarlosR

Que yo sepa no hay que firmar veri*factu. Solo has de usar un certificado digital para enviar datos a la AEAT.
Lo que sí hay que firmar es el xml donde esté instalado un soft dual o No veri*factu. Al igual que los eventos.

Por cierto, a colación de comentarios anteriores, ¿ importa el soft o solo importa la rutina de validación con la AEAT ?
Considero importante recordar que el propio soft debe identificar cuántas empresas están acogidas a veri*factu de forma visible. También debe haber un "contrato" con el cliente que determine a qué modelo de veri*factu se acoge. Al mismo tiempo se debe identificar datos tales como el productor (nombre,nif,número de instalación, etc.) y que eso se debe identificar en la comunicación con la AEAT.
Al mismo tiempo se debe recordar que el soft debe ser capaz de identificar fallos de coherencia entre lo que se envia a la AEAT y lo que realmente tiene archivado. Todo esto en el modelo solo verifactu. En el modelo NO verifacto ni te cuento.
Mi pregunta sería...¿cómo puedo dar validez a mis datos de gestión si no coinciden con mis datos del registro enviado a la AEAT ?
¿ Mi soft se puede validar a partir de lo que hay enviado a la AEAT ?
Desde un punto de vista procedimental considero que la forma de alimentar el registro de envíos a la AEAT sería igualmente de eficaz se use el protocolo de comunicación que se use.
Pero desde un punto de vista legal, ¿ Son mis datos consistentes ? ¿ Puedo garantizar que lo que se envía se ha registrado en mi gestión ?
¿ Puedo GARANTIZAR que mi sistema de gestión mantiene datos coherentes con lo enviado ?
Por ello creo que alimentar los envíos con CSV/XLSX podría generar inconsistencias. Modelo que permitiría al cliente final hacer "apaños" jugando con la credibilidad del productor de soft.
Me reitero, sería objeto de una consulta legal mas allá de lo que se pudiera representar en este foro, pero creo que sería contraproducente para el programador.
Atte,


Un saludo.

[Franche]

Contestación de AEAT :
El reglamento aprobado por el Real Decreto 1007/2023, de 5 de diciembre, no hace sino especificar ciertos requisitos que deben cumplir los sistemas informáticos de facturación para evitar o reducir y detectar la posible realización de fraude en los procesos de facturación mediante su uso, de acuerdo con lo que impone el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, introducido por la Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal. En este sentido, deben seguir permitiendo realizar las operaciones de facturación legalmente admitidas, del tipo que sean, pero realizando el correspondiente registro "seguro" de las mismas.

En cualquier caso, todo esto es independiente de la debida diligencia con la que han de proceder los empresarios y profesionales a la hora de realizar adecuadamente los procesos de facturación, siguiendo -entre otras- las normas establecidas en el reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: verifactu@correo.aeat.es

[xamminf]

Empezado por edari

Es una puñetada porque los clientes no saben valorar lo que "cuesta" todo esto solo ven que tu ritmo habitual de evolución del software ha cambiado significativamente

Y como si adaptando el programa a Verifactu ya no hubiera que adaptar y crear nuevos interfaces que vendrán y no pararán.
Estamos como los agricultores, más papeles para sacar un tomate del huerto que papeles para...

[sglorka]

Empezado por Franche

Contestación de AEAT :
El reglamento aprobado por el Real Decreto 1007/2023, de 5 de diciembre, no hace sino especificar ciertos requisitos que deben cumplir los sistemas informáticos de facturación para evitar o reducir y detectar la posible realización de fraude en los procesos de facturación mediante su uso, de acuerdo con lo que impone el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, introducido por la Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal. En este sentido, deben seguir permitiendo realizar las operaciones de facturación legalmente admitidas, del tipo que sean, pero realizando el correspondiente registro "seguro" de las mismas.

En cualquier caso, todo esto es independiente de la debida diligencia con la que han de proceder los empresarios y profesionales a la hora de realizar adecuadamente los procesos de facturación, siguiendo -entre otras- las normas establecidas en el reglamento por el que se regulan las obligaciones de facturación, aprobado por el Real Decreto 1619/2012, de 30 de noviembre.

Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: verifactu@correo.aeat.es

Podrías poner la pregunta que habías hecho para recibir esta respuesta ??
Gaacias

[Franche]

Esta es la pregunta :

Buenos días,

Querría hacerles llegar el malestar de los clientes de nuestro software al no poder editar una factura una vez guardada. Si todo va a funcionar con rectificativas, y teniendo en cuenta que también se comenten errores incluso en las rectificativas va a ser un auténtico lio y así nos lo plantean. ¿porqué no dejan modificar facturas y una vez esté correcta entonces que la puedas sincronizar? , es decir, que te de la opción a no sincronizar en tiempo real y eso si, una vez sincronizada está claro que quedará totalmente bloqueada para que no se pueda manipular.
La cantidad de casos a la hora de facturar llega a ser una barbaridad y cada vez es más complejo facturar de la forma que ustedes plantean con el nuevo reglamento, ruego lo tengan en cuenta porque la carga que estamos sufriendo los desarrolladores a la hora de atender e incluso de formar a todos los usuarios es insoportable, hay semanas completas que no podemos avanzar y ni siquiera trabajar, solo nos dedicamos a tranquilizar a los usuarios que algunos incluso nos amenazan con dejar nuestro software porque así no pueden trabajar.

Gracias.

[CarlosR]

Empezado por Franche

Esta es la pregunta :

Buenos días,

Querría hacerles llegar el malestar de los clientes de nuestro software al no poder editar una factura una vez guardada. Si todo va a funcionar con rectificativas, y teniendo en cuenta que también se comenten errores incluso en las rectificativas va a ser un auténtico lio y así nos lo plantean. ¿porqué no dejan modificar facturas y una vez esté correcta entonces que la puedas sincronizar? , es decir, que te de la opción a no sincronizar en tiempo real y eso si, una vez sincronizada está claro que quedará totalmente bloqueada para que no se pueda manipular.
La cantidad de casos a la hora de facturar llega a ser una barbaridad y cada vez es más complejo facturar de la forma que ustedes plantean con el nuevo reglamento, ruego lo tengan en cuenta porque la carga que estamos sufriendo los desarrolladores a la hora de atender e incluso de formar a todos los usuarios es insoportable, hay semanas completas que no podemos avanzar y ni siquiera trabajar, solo nos dedicamos a tranquilizar a los usuarios que algunos incluso nos amenazan con dejar nuestro software porque así no pueden trabajar.

Gracias.

¿ Por qué no prueba a utilizar un tipo documento intermedio denominado PREFACTURA ?
En las recapitulativas es indispensable.
Cuando tenga la prefactura lista entonces cierre el documento y genere factura y todos los encadenamientos.
La prefactura no se podrá usar para el cliente, es un documento temporal.



¿ No seria mas provechoso ?


Saludos.

[ermendalenda]

Empezado por CarlosR

Por cierto, a colación de comentarios anteriores, ¿ importa el soft o solo importa la rutina de validación con la AEAT ?
Considero importante recordar que el propio soft debe identificar cuántas empresas están acogidas a veri*factu de forma visible. También debe haber un "contrato" con el cliente que determine a qué modelo de veri*factu se acoge. Al mismo tiempo se debe identificar datos tales como el productor (nombre,nif,número de instalación, etc.) y que eso se debe identificar en la comunicación con la AEAT.
Al mismo tiempo se debe recordar que el soft debe ser capaz de identificar fallos de coherencia entre lo que se envia a la AEAT y lo que realmente tiene archivado. Todo esto en el modelo solo verifactu. En el modelo NO verifacto ni te cuento.
Mi pregunta sería...¿cómo puedo dar validez a mis datos de gestión si no coinciden con mis datos del registro enviado a la AEAT ?
¿ Mi soft se puede validar a partir de lo que hay enviado a la AEAT ?
Desde un punto de vista procedimental considero que la forma de alimentar el registro de envíos a la AEAT sería igualmente de eficaz se use el protocolo de comunicación que se use.
Pero desde un punto de vista legal, ¿ Son mis datos consistentes ? ¿ Puedo garantizar que lo que se envía se ha registrado en mi gestión ?
¿ Puedo GARANTIZAR que mi sistema de gestión mantiene datos coherentes con lo enviado ?
Por ello creo que alimentar los envíos con CSV/XLSX podría generar inconsistencias. Modelo que permitiría al cliente final hacer "apaños" jugando con la credibilidad del productor de soft.
Me reitero, sería objeto de una consulta legal mas allá de lo que se pudiera representar en este foro, pero creo que sería contraproducente para el programador.
Atte,


Un saludo.

Si alimentas tu software con datos externos es aconsejable que una de 2: el contador de facturas, fecha y hora de expedicióny emisión lo lleves desde el software, o más complicado, que detectes las inconsistencias en saltos de numersdores y orden cronológico. Si te sirve, mi software se alimenta de 2 formas, una de ellas es por odbc y género mi propio numerador y en mi bd pongo como referencia el numerador de donde me alimento para tener el enlace. De es6a forma he eliminado todas las inconsistencias con verifactu y cumplo a rajatabla, ya que realmente cuando emito es cuando genero el xml, todo lo demás son temporales.

[ermendalenda]

Empezado por Logan05

Buenos días,

soy programador en una muy pequeña empresa, y me veo en el trance de tener que actualizar varias aplicaciones de facturación desarrolladas hace años en vb6, a medida para pequeños comercios locales....

Buscando y buscando he dado con este foro, que aunque no sea de vb6, me parece magnífico, así que he seguido todo el hilo y me está aclarando muchos conceptos, pero como novato en relaciones con la AEAT, soy todo dudas y no se muy bien por donde meterle mano.

Por ejemplo, se supone que tienes que mandarle un XML a hacienda de forma inmediata (máximo 2 horas) de cada factura simplificada o no que hagas, eso puede ser igual 3, que 30, o que 300 XML en un día, pero por otra parte leo que hay que agruparlos en bloques de al menos 1000, pero ¿cómo leches voy a agruparlos si sólo genero 30 en un día? en los negocios pequeñitos no hay tantísimo movimiento, pero por otra parte, si todos, desde toda España, los mandamos uno a uno ¿no va a fliparlo el servidor de la AEAT?.

Aunque he estado viendo cosas para usar servicios web SOAP desde vb6, estoy dando mis primeros pasos para intentar comunicarme con el entorno de pruebas del SII para luego pasar a VERIFACTU, es mi primera experiencia con este tema, así que, en fin, os agradeceré cualquier indicación, idea, guía, ejemplo, manual, lo que sea, porque lo que he encontrado es todo con HTTP y supongo que ahora deberá ser con HTTPS.

Muchísimas GRACIAS de antemano, e intentaré aportar lo que pueda.

Por un lado tienes suerte, de haber encontrado este foro, yo tengo la facturación en vb5/6 y tela de curro, lo único que no pienso hacer es el envío final que lo he subcontratado, pero todo lo demás, generar xmls, QR, cálculo de hash, pdfs con Qrs incrustado, en vb5 y verás cuando te metas en facturae...Una tremenda currada hacerlo en este lenguaje, pero posible, si tu software no es muy extenso te facilitará mucho, el mio es que tiene varias formas de facturar y es para volverse loco.

[CarlosR]

Empezado por ermendalenda

Si alimentas tu software con datos externos es aconsejable que una de 2: el contador de facturas, fecha y hora de expedicióny emisión lo lleves desde el software, o más complicado, que detectes las inconsistencias en saltos de numersdores y orden cronológico. Si te sirve, mi software se alimenta de 2 formas, una de ellas es por odbc y género mi propio numerador y en mi bd pongo como referencia el numerador de donde me alimento para tener el enlace. De es6a forma he eliminado todas las inconsistencias con verifactu y cumplo a rajatabla, ya que realmente cuando emito es cuando genero el xml, todo lo demás son temporales.

Debe ser verano, a veces siento que el sudor del camino no acompasa al agua fresca que espera en el riachuelo.
Vuelvo a reiterar lo que he explicado y doy fe de que funciona en primera persona :


Un documento de prefactura es un documento temporal, con su fecha temporal, con su contador temporal. Si se elimina o se sacan albaranes no importa, es un espacio de trabajo. No se le puede expedir a ningún cliente porque no es una factura. Es un espacio de trabajo. Cuando se valide se convertirá en una factura con todas las circunstancias. Tendrá su fecha, su fecha-hora de generación de registro, su encadenamiento, etc.etc.
Es sólo una sugerencia y doy fe de que funciona perfectamente.
Cada cual haga como mejor le convenga.



Un saludo a todos.

[frrr@grupo3rs.c]

Una prefactura puede ser una opcion si la ejecutamos de 1 en 1. Pero la mayoria de mis clientes meten albaranes y facturan al cabo de 15 días o 30 días. En este caso es inviable la prefactura.

[pablog2k]

Empezado por CarlosR

¿ Por qué no prueba a utilizar un tipo documento intermedio denominado PREFACTURA ?
En las recapitulativas es indispensable.
Cuando tenga la prefactura lista entonces cierre el documento y genere factura y todos los encadenamientos.
La prefactura no se podrá usar para el cliente, es un documento temporal.



¿ No seria mas provechoso ?


Saludos.

Nosotros usamos algo parecido. No es que lo llamemos prefactura, es que tenemos un botoncito en la factura que dice 'finalizar factura'. Este proceso es el que se encarga de generar los registros de iva, rellenar las tablas para los modelos de hacienda, generar el asiento contable , SII / Ticketbai / futuro verifactu, ...etc
Hasta que no le das a ese botoncito, la factura no está 'completa' digamos.
El usuario final (en teoría) revisa que esté todo bien en la factura (precios, cliente, descuentos, productos....) y si está todo correcto, le dan al botoncito y damos la factura por finalizada

[edari]

Varios de nuestros clientes de TicketBai sirven la mercancía con un documento de albarán, si hay alguna corrección se hace sin problema y cuando está todo correcto "cierran" esos albaranes, se facturan, se suben a Ticket Bai y se manda a los clientes por mail

[CarlosR]

Empezado por pablog2k

Nosotros usamos algo parecido. No es que lo llamemos prefactura, es que tenemos un botoncito en la factura que dice 'finalizar factura'. Este proceso es el que se encarga de generar los registros de iva, rellenar las tablas para los modelos de hacienda, generar el asiento contable , SII / Ticketbai / futuro verifactu, ...etc
Hasta que no le das a ese botoncito, la factura no está 'completa' digamos.
El usuario final (en teoría) revisa que esté todo bien en la factura (precios, cliente, descuentos, productos....) y si está todo correcto, le dan al botoncito y damos la factura por finalizada

Justamente es ahí donde se necesita una prefactura o cualquier otro nominativo que signifique lo mismo.
Es en las facturas recapitulativas. ¿ Por qué ? Porque las facturas deben ir ordenadas consecutivamente tanto por fecha-hora de creación así como por fecha de documento y por número de factura.

Si se hace una tirada de facturación no podrá contabilizar una antes que otra. No podrá sacar un albarán para meterlo en otra o incorporar un albarán que se haya quedado fuera de la factura. Por si alguien lo ignora, un albarán una vez listado o enviado por email no se puede modificar. Si el cliente le pide su factura no podrá contabilizarla antes que una que tenga el número anterior. Eso no ocurre en la factura de contado.

De otro modos la fecha-hora del registro (algo tan importante para la aeat y su encadenamiento) quedaría desfasada.

En realidad ni siquiera serviría cambiarle el tipo de documento así como se contabilice porque el registro tiene una fecha-hora de creación. De ahí que en mi caso haya optado por tener un documento temporal de trabajo.
Cuando se cierra se crea un documento de factura con su código,fecha,serie, fecha-hora correspondiente y ordenado eliminando el documento temporal.

No sigo mas con este tema. Solo fue una sugerencia por si alguien se ha perdido en este paso y puedo ayudarle en algo.

Un saludo.