Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[Sistel]

Empezado por rci

Hola Sistel, como lo haces?
En cada venta, antes de salvarla (y por lo tanto antes de generar TicketBAI / VeriFactu), compruebas si el numero de identificación introducido es correcto contactando con el webservice?
y si contesta que no es correcto muestras un error y no permites salvar hasta que hayan introducido un NIF correcto?

Muchas gracias

Hola,

Efectivamente, para las facturas con destinatario, se conecta al webservice de la AEAT y comprueba si el NIF y nombre son correctos.
Si no lo son, doy mensaje de error y no dejo emitir esa factura.

Saludos

[Sistel]

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

¿Y si se "cae" la conexión a Internet no se emiten facturas?
Creo que eso no debería ser así. Debes poder emitir aunque no tengas conexión.

Hola,

Mi sistema es una API en la nube.
Si no hay conexión a Internet, no puedes facturar (lo mismo que si se te va la luz).
Para garantizar conexión permanente a Internet, siempre se puede utilizar un router 4G de backup que conmuta automáticamente y saca el tráfico por la red de telefonía móvil si se cae la conexión por la fibra.
Y con un SAI ya bordas la instalación.

Saludos

[jguarda]

acaso pretenden que cada ticket que emita un bar, tienda de calzado, peluqueria... etc, se vayan pidiendo los DNI a todo dios ...

[rci]

Empezado por jguarda

acaso pretenden que cada ticket que emita un bar, tienda de calzado, peluqueria... etc, se vayan pidiendo los DNI a todo dios ...

No, en ese caso pueden ser facturas simplificadas, sin identificar el destinatario.
Pero si quieres emitir una factura completa, los datos del destinatario (incluido el DNI) tienen que constar y ser correctos

[Sistel]

Empezado por rci

Imagino que en ese caso el programa de Sistel cruza los dedos para que sea correcto y permite salvar.

Hola,

Hoy por hoy las redes de fibra y 4G son muy estables.
En los más de 2 años que llevamos dando servicio TicketBAI a casi 300 usuarios (principalmente comercios, bares y restaurantes) las incidencias por corte de conexión han sido anecdóticas.
Y la ventaja de tener todo centralizado, guardado y a salvo del usuario en servidores de Internet ... no tiene precio.

Saludos

[Sistel]

Empezado por rci

No, en ese caso pueden ser facturas simplificadas, sin identificar el destinatario.
Pero si quieres emitir una factura completa, los datos del destinatario (incluido el DNI) tienen que constar y ser correctos

Lo mismo que ahora.
La única diferencia que hasta ahora se hacía en papel y con Verifactu se hará también electrónico.
Pero la normativa de facturación es la misma de siempre.

[Galahad]

Empezado por pablog2k

si que está validando lo de la huella ... lo que pasa es que te la da aceptada con errores:
ejemplo:
registro con huella mal:

Código PHP:

<tikR:EstadoRegistro>AceptadoConErrores</tikR:EstadoRegistro>

<tikR:CodigoErrorRegistro>2000</tikR:CodigoErrorRegistro> 


registro con huella bien:

Código PHP:

<tikR:EstadoRegistro>Correcto</tikR:EstadoRegistro> 


como comenté, para poder arreglar las huellas de todos los documentos, tienes que empezar por el primero que esté mal, e ir subiendolo como subsanacion

perdón , a ver si sobre esto me podeís ayudar.
me acepta las facturas, pero con con errores por el tema de la firma, si realmente las está validando, no lo entiendo.

<tikR:RespuestaLinea>
<tikR:IDFactura>
<tik:IDEmisorFactura>XXXXXXX</tik:IDEmisorFactura>
<tik:NumSerieFactura>0F240006</tik:NumSerieFactura>
<tik:FechaExpedicionFactura>22-01-2024</tik:FechaExpedicionFactura>
</tikR:IDFactura>
<tikR:EstadoRegistro>AceptadoConErrores</tikR:EstadoRegistro>
<tikR:CodigoErrorRegistro>2000</tikR:CodigoErrorRegistro>
<tikRescripcionErrorRegistro>El cálculo de la huella suministrada es incorrecta. Datos de entrada cálculo huella: IDEmisorFactura=XXXXXXX&NumSerieFactura=0F240006&FechaExpedicionFactura=22-01-2024&TipoFactura=F1&CuotaTotal=420.00&ImporteTotal=2420.00&Huella=&FechaHoraHusoGenRegistro=2024-10-03T16:15:03+02:00 Huella calculada: A8925885A65EB9F41DEEFAEBF9971DB688DC8F92D35B38ACACD34318FEEF3104</tikRescripcionErrorRegistro>

</tikR:RespuestaLinea>

estoy creando la huella con :

Código Delphi [-]
 Result := THashSHA2.GetHashString(CadenaVerifactu,THashSHA2.TSHA2Version.SHA256);

pensaba enviar está consulta a la aeat,,, ¿ la dirección correcta de soporte para estas consultas seria : catentidades@correo.aeat.es ?, ¿ o hay alguna específica para soporte informático a verifactu ?

[rci]

Empezado por Galahad

pensaba enviar está consulta a la aeat,,, ¿ la dirección correcta de soporte para estas consultas seria : catentidades@correo.aeat.es ?, ¿ o hay alguna específica para soporte informático a verifactu ?

Mejor aquí:

verifactu@correo.aeat.es

Saludos

[[newtron]]

Gracias a todos por vuestras respuestas.


Parece claro que es un problema de windows 7 con TLS 1.2, yo lo tengo activado como me comentáis y no funciona. Voy a probar a meter un parche de seguridad que me recomienda mi ultimo gran amigo (chatgpt) y os comento para tenerlo claro.


Saludos.

[bmfranky]

Si, ya te comentaba que en el 7 habia que aplicar un parche.

[[newtron]]

Empezado por bmfranky

Si, ya te comentaba que en el 7 habia que aplicar un parche.

Cierto... voy a ello.

[jguarda]

supongo que el envío a veri*factu de facturas (simplificadas), habrá que meterlo en un tThread distinto al hilo principal xq sino el terminal se quedará tostado hasta que termine el envio y recepción del resultado. Creo que esto es un problema tanto para el cliente como para nosotros. Si alguien quiere su ticket inmediato después de haber por ejemplo comprado algo en una tienda, el de la tienda tiene que pasar esto inmediatamente a veri*factu, por lo que se van a liar una colas de gente en ciertos negocios tremendas, amen de los cuelgues por falta de comunicación en la hacienda publica, y se me ocurren otro montón de situaciones, en donde veo inviable esto que pretenden.


Imaginemos alguien, que decide quitar internet de su negocio, pero quiere usar su sistema informático para dar un ticket al cliente. Hacienda le pagará el internet para que emita sus tickes a veri*factu, o le multará, en fin ... no se



al final, libreta y boligrafo y el que quiera factura ya se le mandara por carta postal, jejej

[sglorka]

Leo varios post referidos a, qué hacer cuando rechazan una factura o la aceptan parcialmente, y veo que la mayoría de los post no son correctos y puede llegar a confusión este galimatías. En mi opinión y con el Reglamento de Facturación vigente y el Reglamento Verifactu, si te rechazan una factura y tienes contenido en la propiedad Respuestalinea del objeto Respuesta donde se especifica el motivo del rechazo, significa que la Aeat ha logrado parsear el registro enviado, situación distinta a la ocurrida cuando el servicio de la Aeat no ha podido hacerlo porque está fuera de línea, no tenemos Internet o nuestro modelo Xml no es correcto. En estos casos se recibe un objeto Respuesta con todas sus propiedades a Nothing o Null pero con la propiedad EstadoDeEnvio = Incorrecto. Sólo en este caso podremos reenviar el paquete de nuevo, ya que la Aeat no tiene nada registrado de este paquete.

Si recibimos contenido en la propiedad Respuestalinea del objeto Respuesta, sea lo que sea, ya no podrás volver a reenviar los registros que contenía dicho paquete, hayan venido Incorrectos o Parcialmente Correctos.
Disponemos de herramientas para solventar este caso.

La primera es subsanar el registro creando un Nuevo registro de Subsanación y olvidándote del registro rechazado, sólo puede corregir datos que no impliquen la emisión de una factura rectificativa, por ejemplo errores en fecha de operación, régimen tributario, la huella generada....Puedes generar un Alta por rechazo previo o un Alta por Subsanación sin rechazo previo según sea el caso

Y la segunda es nuestra querida amiga la Factura Rectificativa. Si nos rechazan una factura porque el tipo impositivo no existe, te tienes que olvidar de ese registro de facturación y emitir una factura rectificativa por sustitución haciendo referencia a esa factura rechazada para corregir ese error. Quedará un hueco en las facturas que tiene la Aeat (nos ha rechazado la factura) pero eso es normal ya que NO PODEMOS modificar facturas para arreglarlas. Haciendo referencia a dicha factura a través de la rectificación justificamos en la Aeat la existencia de ese hueco.

[pablog2k]

Empezado por jguarda

supongo que el envío a veri*factu de facturas (simplificadas), habrá que meterlo en un tThread distinto al hilo principal xq sino el terminal se quedará tostado hasta que termine el envio y recepción del resultado. Creo que esto es un problema tanto para el cliente como para nosotros. Si alguien quiere su ticket inmediato después de haber por ejemplo comprado algo en una tienda, el de la tienda tiene que pasar esto inmediatamente a veri*factu, por lo que se van a liar una colas de gente en ciertos negocios tremendas, amen de los cuelgues por falta de comunicación en la hacienda publica, y se me ocurren otro montón de situaciones, en donde veo inviable esto que pretenden.


Imaginemos alguien, que decide quitar internet de su negocio, pero quiere usar su sistema informático para dar un ticket al cliente. Hacienda le pagará el internet para que emita sus tickes a veri*factu, o le multará, en fin ... no se



al final, libreta y boligrafo y el que quiera factura ya se le mandara por carta postal, jejej

hola , el proceso de generar el ticket, con el QR, es independiente a subir ese ticket a verifactu. De hecho, si tienes un corte de internet en un comercio, puedes (y debes)seguir emitiendo tickets sin problemas, y si el cliente se queja de que el QR no lleva a ningún sitio, le dices que estás sin internet y que a lo largo del día estará operativo el QR.
A mi tambien me parece inviable lo que pretenden hacer, pero porque no creo que estén preparados para recibir tantisima información de todos los comercios enviando registros. El modelo que pretenden implantar ya está operativo en el pais vasco, y desde este foro te pueden comentar compañeros que al final se ha implantado y la gente a tenido que pasar por el aro

[pablog2k]

Empezado por Galahad

perdón , a ver si sobre esto me podeís ayudar.
me acepta las facturas, pero con con errores por el tema de la firma, si realmente las está validando, no lo entiendo.



estoy creando la huella con :

Código Delphi [-]
 Result := THashSHA2.GetHashString(CadenaVerifactu,THashSHA2.TSHA2Version.SHA256);

pensaba enviar está consulta a la aeat,,, ¿ la dirección correcta de soporte para estas consultas seria : catentidades@correo.aeat.es ?, ¿ o hay alguna específica para soporte informático a verifactu ?

hola , en la pagina 1 de este hilo tienes un ejemplo de como crear el hash, utiliza una de las librerías que incorpora DelphiXE8 creo, incluso la puedes generar como DLL por si tienes versiones mas antiguas de delphi

[Sistel]

Empezado por pablog2k

hola , el proceso de generar el ticket, con el QR, es independiente a subir ese ticket a verifactu. De hecho, si tienes un corte de internet en un comercio, puedes (y debes)seguir emitiendo tickets sin problemas, y si el cliente se queja de que el QR no lleva a ningún sitio, le dices que estás sin internet y que a lo largo del día estará operativo el QR.
A mi tambien me parece inviable lo que pretenden hacer, pero porque no creo que estén preparados para recibir tantisima información de todos los comercios enviando registros. El modelo que pretenden implantar ya está operativo en el pais vasco, y desde este foro te pueden comentar compañeros que al final se ha implantado y la gente a tenido que pasar por el aro

Hola,

Efectivamente, aquí, en el País Vasco, TicketBAI (que viene a ser, prácticamente, lo mismo que Verifactu) lleva ya varios años funcionando.
Al principio, la gente se echaba las manos a la cabeza con los posibles problemas: cortes, lentitud y demás.
Pero se ha comprobado que no: todo funciona, en general, sin problemas.

Hoy por hoy, no hay problemas en ningún sitio para tener Internet (por fibra, por 3G/4G, por satélite o combinados)

Y respecto a lo que leí sobre si Hacienda va a pagar la conexión a Internet necesaria en todos los comercios y negocios que emitan factura:
En el País Vasco, las Haciendas Forales permiten una deducción extraordinaria del 30% del importe de la implantación de TicketBAI (ordenadores, TPVs, impresoras, software, implantación, formación, ...)
(Si le le suma la deducción del IVA y la reducción por gasto del Impuesto de Sociedades o del IRPF, el coste final de la implantación es mínimo)
Muchos comercios han aprovechado esta oferta para actualizar sus equipos informáticos.
Aparte, la Hacienda Foral de Bizkaia también concede otra deducción del Impuesto de Sociedades o del IRPF si se entra voluntariamente en el sistema antes de la fecha que corresponda.
A las Haciendas les merece la pena casi regalar todos los costes a cambio de tener información instantánea de las facturas emitidas que ya no podrán ser objeto de fraude (borrado o manipulación antes de la declaración de IVAs)
No sé si al final la AEAT también permitirá deducciones especiales por los gastos de implantación de Verifactu.

Respecto al tema de la posible lentitud con la comprobación del NIF y nombre del destinatario (utilizando el webservice de AEAT) + los envíos de los datos de la factura a Hacienda:
Nos ha sorprendido lo bien que va.
Nuestro sistema, por ejemplo, recibe (en un servidor en la nube) los datos de la factura a emitir, hace las verificaciones, grabaciones, creación del XML, firma del XML, cálculo del código TBAI y del código QR retorno de todos los datos al comercio y envío (encolado) a Hacienda en unos 150-200 milisegundos de media.
La verdad es que no tenemos prácticamente nunca problemas de saturación.

Está claro que cuando la mayoría de los países de la UE ya tienen en marcha un sistema similar a Verifactu, es que se puede.

Saludos.

[antoine0]

Empezado por newtron

Parece claro que es un problema de windows 7 con TLS 1.2, yo lo tengo activado como me comentáis y no funciona. Voy a probar a meter un parche de seguridad que me recomienda mi ultimo gran amigo (chatgpt) y os comento para tenerlo claro.

https://learn.microsoft.com/es-es/me...tls-1-2-client

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

Empezado por jguarda

supongo que el envío a veri*factu de facturas (simplificadas), habrá que meterlo en un tThread distinto al hilo principal xq sino el terminal se quedará tostado hasta que termine el envio y recepción del resultado. Creo que esto es un problema tanto para el cliente como para nosotros. Si alguien quiere su ticket inmediato después de haber por ejemplo comprado algo en una tienda, el de la tienda tiene que pasar esto inmediatamente a veri*factu, por lo que se van a liar una colas de gente en ciertos negocios tremendas, amen de los cuelgues por falta de comunicación en la hacienda publica, y se me ocurren otro montón de situaciones, en donde veo inviable esto que pretenden.

Empezado por pablog2k

hola , el proceso de generar el ticket, con el QR, es independiente a subir ese ticket a verifactu. De hecho, si tienes un corte de internet en un comercio, puedes (y debes)seguir emitiendo tickets sin problemas, y si el cliente se queja de que el QR no lleva a ningún sitio, le dices que estás sin internet y que a lo largo del día estará operativo el QR.

[pablog2k] ya lo ha dicho.
Ambos procesos DEBEN ser independientes (generación y envío).
Lo lógico es montar una cola de envío que vaya enviando las facturas "a medida que pueda".
Si "se cae" internet, pues cuando vuelva las enviará todas.
Ya sea con un thread independiente, un programa independiente, un servicio,....

[David M]

Buenas,

Han vuelto a publicar novedades:
https://www.agenciatributaria.es/AEA...olladores.html

Saludos,
David M.

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

Publicado esta madrugada (04/10/2024)

VERI*FACTU - Actualización de documentación en sistemas VERI*FACTU: Se ha publicado una nueva versión de la documentación asociada a los sistemas VERI*FACTU:

- Diseño de registro (0.14.4), con nuevo campo RefExterna y modificaciones en bloque RemisionRequerimiento y actualización en listas de claves de régimen. Se actualizan los esquemas XSD en consonancia.
- Documento de Validaciones y errores (0.9.0), con modificaciones asociadas a cambios en tipos de impuesto y claves de régimen, además de incluir un enlace al listado de códigos de error. Los cambios se muestran resaltados en amarillo, se encuentran pendientes de publicación en el entorno de Pruebas Externas. Se estima que estarán disponibles en las próximas semanas.
- Documento de Especificaciones técnicas del código QR (0.4.5), con modificaciones en los mensajes para sistemas que emitan facturas no verifacables y códigos de error.

Ante cualquier duda/sugerencia y/o falta de corrección sobre la nueva información publicada, se recuerda el buzón de consultas técnicas de VERI*FACTU:
verifactu@correo.aeat.es


Actualizo el mensaje#1 y el FTP