Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

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

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

[[email protected]]

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.

[Franche]

Tengo que cuando vas a guardar una factura te da a elegir si FINALIZARLA (con lo cual ya no podrás modificar, aunque actualmente todavía dejo modificar) o guardarla en BORRADOR (aqui te deja hacer todo, incluso eliminarla) que cuando ya sepas que es correcta entonces te da la opción de FINALIZAR. Es lo que me dices de PREFACTURA, es lo mismo.

[seccion_31]

Programa demostracion alta-anulacion facturas verifactu, que incluye un simulador de respuesta muy basico.

El programa con fines educativos, permite añadir y anular desde archivos excel facturas, enviarlos a la AEAT ó simular un envio.

La direccion de descarga esta en:

https://github.com/seccion31/verifactu-delphi-demo

Espero que este medianamente correcto y sirva de guia a los mas despistados, entre los que me incluyo.

Cualquier correccion y sugerencia seran bienvenidos.

[Casimiro Noteví]

[CarlosArjonomia]

Hola, ¿Navarra queda en un limbo con esto de verifactu?

[jlmoli_67]

Buenas.


Me podriais aclarar si este planteamiento es correcto, por favor?. Vuelvo a estar muy liado


tenemos una factura de 1000 Euros + 210 Euros de IVA. Por un error en la misma, necesitamos hacer una rectificación, siendo el importe correcto 800 Euros + 168 de IVA:

• Emitimos primero una factura ordinaria en negativo de -1000 Euros (y -210), es decir, la factura original pero en negativo.
• Emitimos una nueva factura ordinaria de 800 (+168) .
• En este caso no se rellenan los datos “base rectificada”, “cuota rectificada” y las estadisticas a nivel de articulos e inventario cuadrarian, etc.

gracias por vuestra ayuda.

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

Empezado por seccion_31

Programa demostracion alta-anulacion facturas verifactu, que incluye un simulador de respuesta muy basico.
El programa con fines educativos, permite añadir y anular desde archivos excel facturas, enviarlos a la AEAT ó simular un envio.

La direccion de descarga esta en:
https://github.com/seccion31/verifactu-delphi-demo

Espero que este medianamente correcto y sirva de guia a los mas despistados, entre los que me incluyo.

Gracias por el aporte [seccion31].
Subo el proyecto al FTP del club, junto a un fichero TXT con una pequeña descripción y el link a github (original).
https://terawiki.clubdelphi.com/Otro...go-proyectos_/

Actualizo también el segundo mensaje del hilo, donde iremos recopilando códigos útiles.

[[newtron]]

Empezado por seccion_31

Programa demostracion alta-anulacion facturas verifactu, que incluye un simulador de respuesta muy basico.

El programa con fines educativos, permite añadir y anular desde archivos excel facturas, enviarlos a la AEAT ó simular un envio.

La direccion de descarga esta en:

https://github.com/seccion31/verifactu-delphi-demo

Espero que este medianamente correcto y sirva de guia a los mas despistados, entre los que me incluyo.

Cualquier correccion y sugerencia seran bienvenidos.

Gracias compañero.

[ermendalenda]

Hay una revisión de la imagen del QR.
No esperes nada bueno.
Sigue quedándose donde dijeron y además presionan un poco más con el mensaje de inmediatez.
Si un cliente pasa el QR, antes decían que aún no se ha subido y que lo intenten un poco más tarde, ahora lo han cambiado por aún no lo han subido por que han podido tener una incidencia puntual.
Una vueltecita más de tuerca jeje.