Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Lo de ls excell que comentáis es factible, es una entrada de datos como otra cualquiera. El programa que lea esas Excel y genere los xmls es que tiene q7e cumplir verifactu
La entrada de datos es algo independien6e, 0uede ser json, excell, xml, una fuente de datos odbc...eso no influye en nada.

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

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

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

[antoine0]

Empezado por ermendalenda

Lo de ls excell que comentáis es factible, es una entrada de datos como otra cualquiera. El programa que lea esas Excel y genere los xmls es que tiene q7e cumplir verifactu

Parece una interesante idea (aunque lo veo bien solo para Veri*factu).
Sin embargo, suponiendo que la factura se imprime desde Excel (cosa que podía tener sentido hace años), ahora al dicho Excel se lo tiene que añadir el QR...

Y por supuesto, debe ir en la cabecera, impreso como primero de la fila &c.

[seccion_31]

buenos dias !

he propuesto un software de ejemplo, que lea registros desde una excel, tipo asi:


OPERACIÓN NUMSERIEFACTURA FECHA FACTURA DESCRIPCION OPERACIÓN CLIENTE CLIENTE NIF TIPONIF CODPAIS BASE IMP TOTAL IVA1 REQ1
ALTA F240001 21/01/2024 VENTA MERCADERIAS CLIENTE1 NIFCLI1 02 ES 1000 1121 21 1000
ALTA F240002 22/01/2024 VENTA MERCADERIAS CLIENTE2 NIFCLI2 02 ES 2000 2420 21 2000


Para abstraer del programa de ejemplo de la interacción con un modelo de base de datos propia, nada mas. solo a modo de ejemplo.


Estoy con el alta (en su modo mas simple) y el envio de los registros con el certificado digital instalado, via HTTPRIO. Luego hare la baja.

Si alguien quiere colaborar que me escriba en privado y se lo enviare antes de publicarlo (calculo que durante la semana que viene) y asi hacerlo mas completo y con menos errores.


Me he quedado algo obsoleto, ... pero no hace falta firmar nada ¿no? en el SII no firmo nada, y los envio a la AEAT (HTTPRIO) y listo.

Saludos !

[[newtron]]

Empezado por seccion_31

buenos dias !

he propuesto un software de ejemplo, que lea registros desde una excel, tipo asi:


OPERACIÓN NUMSERIEFACTURA FECHA FACTURA DESCRIPCION OPERACIÓN CLIENTE CLIENTE NIF TIPONIF CODPAIS BASE IMP TOTAL IVA1 REQ1
ALTA F240001 21/01/2024 VENTA MERCADERIAS CLIENTE1 NIFCLI1 02 ES 1000 1121 21 1000
ALTA F240002 22/01/2024 VENTA MERCADERIAS CLIENTE2 NIFCLI2 02 ES 2000 2420 21 2000


Para abstraer del programa de ejemplo de la interacción con un modelo de base de datos propia, nada mas. solo a modo de ejemplo.


Estoy con el alta (en su modo mas simple) y el envio de los registros con el certificado digital instalado, via HTTPRIO. Luego hare la baja.

Si alguien quiere colaborar que me escriba en privado y se lo enviare antes de publicarlo (calculo que durante la semana que viene) y asi hacerlo mas completo y con menos errores.


Me he quedado algo obsoleto, ... pero no hace falta firmar nada ¿no? en el SII no firmo nada, y los envio a la AEAT (HTTPRIO) y listo.

Saludos !

Yo estoy trabajando en algo parecido pero con ciertas diferencias.


Uno de mis problemas (tengo muchos ) es que tengo un montón de programas personalizados y que todos entrarán en VeriFactu por lo que tendré que adaptarlos. Lo que se me ha ocurrido es preparar un programa genérico para el envío a VeriFactu que esté atento a una carpeta determinada y en esa carpeta ir poniendo ficheros .csv, uno por cada factura, con los datos de la misma y que se encargue de ir enviándolos según van "cayendo" en la carpeta. De esta manera en los distintos programas lo "único" que tendré que hacer es generar esos ficheros con una estructura determinada. Y digo lo "único" porque hay bastantes modificaciones que hacer para manejar datos que hasta ahora no hago como el tipo de documento de identificación, tipo de operación, etc.



Se admiten ideas.


Saludos.

[seccion_31]

Esa idea tambien la barajo yo. En principio lo ideal seria que ese programa, tomara la lista de facturas con un mínimo tratamiento, y las convierta a verifactu.

Por otro lado, me gustaria haber visto ya, ese programa que dicen los de la AEAT que van a crear para los que facturen "poco", quizas haya una importacion de ese tipo.


(Si quieres colaborar en este programa ejemplo me escribes un privado). Como digo limitado a alta y anulacion, entre el lunes o martes lo podre enviar a quien me lo pida. Pero, si fueramos varios podriamos hacerlo crecer en condiciones.

Saludos !

Empezado por newtron

Yo estoy trabajando en algo parecido pero con ciertas diferencias.


Uno de mis problemas (tengo muchos ) es que tengo un montón de programas personalizados y que todos entrarán en VeriFactu por lo que tendré que adaptarlos. Lo que se me ha ocurrido es preparar un programa genérico para el envío a VeriFactu que esté atento a una carpeta determinada y en esa carpeta ir poniendo ficheros .csv, uno por cada factura, con los datos de la misma y que se encargue de ir enviándolos según van "cayendo" en la carpeta. De esta manera en los distintos programas lo "único" que tendré que hacer es generar esos ficheros con una estructura determinada. Y digo lo "único" porque hay bastantes modificaciones que hacer para manejar datos que hasta ahora no hago como el tipo de documento de identificación, tipo de operación, etc.



Se admiten ideas.


Saludos.

[edari]

Desde este humilde hilo quiero agradecer al gobierno su abnegada labor de seguir joribiando a las empresas de software con sus ocurrencias



Te pegas el susto cuando oyes que a partir de julio quitan el IVA del aceite y lo pasan al 0% y dices bueno, todo controlado...que cambien el tipo de iva, que regeneren los documentos si los tenía grabados con una fecha anterior...lo de siempre, sin problema.


Y llegamos a ayer cuando nos sorprenden con que se van a inventar UN IVA NUEVO DEL 2% para el ACEITE DESDE OCTUBRE HASTA FINAL DE AÑO que pasará al 4%. Lo que mayormente viene a decir que ahora una factura puedes tener 6 tipos de iva diferentes!!!


Pues nada genial todo!! Como total las empresas de España imprimen facturas con un rollo de ticket sin fin..qué mas problema hay en que sean 6 o 16 bases imponibles diferentes !!!


Y dices bueno...lo cambio en el formato de facturas de Verifactu que tenemos que preparar todos...meeccc error...quién garantiza que vamos a tener la orden ministerial antes de septiembre y aun con eso que tengas tiempo a preparar todo tu software para Verifactu o que no quieres los clientes no quieran ser los primeros en entrar por el aro...


Pues nada, agradecido por darnos un trabajo que no va a valer más que para 3 meses


Lo mejor de todo es que harás todos los cambios que tu software necesita y luego en septiembre volverán a pensar otra cosa.


Me cawen to


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)

[Franche]

Pues tienes razón, esperemos que amplíen los plazos y lo atrasen todo lo máximo porque esta gentuza no tienen en cuenta que tenemos que dejar de trabajar para nuestros clientes para trabajar para ellos y gratis, al menos que no den 9 meses a los desarrolladores y al menos que den un año. Porque van a ir saliendo dudas y casos que ellos ni los saben ni se les ha ocurrido plantear (funcionariado vago), lo único que deberían haber hecho es consultar con desarrolladores de empresas pequeñas porque los desarrolladores de empresas grandes ni fu ni fa.
No dudar en escribir siempre aquí con todas estas cosas a ver si entre todos les hacemos entrar en razón de todo lo que significa este cambio y van aceptando algunas cosas que son de cajón: [email protected]

Por ejemplo a mis clientes cuando le dices que NO pueden modificar una factura se les va la cabeza y realmente tienen razón, ¿porqué no puedo modificar una factura si la acabo de guardar y he visto un error? eso sí una vez sincronizada con la AEAT o impresa o enviada por mail se bloquea automaticamente, pero mientras ¿porque no puedo editarla? ¿estoy defraudando por eso? , al final tendrán más facturas rectificativas que ordinarias.