Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

[sglorka]

Respecto de crear un programa intermedio que reciba facturas integradas en ficheros, Excel, Csv, etc provenientes de terminales de facturación para, posteriormente, generar la estructura en Xml y enviar a Verifactu, les recuerdo que, el Real decreto 1007/2023 por el que se rige el reglamento que establece los requisitos a adoptar por los sistemas de facturación dice en su Artículo 9:

Artículo 9. Generación del registro de facturación de alta.
Los sistemas informáticos de facturación que sean utilizados por los obligados
tributarios a que se refiere el artículo 3 de este Reglamento, deberán generar
automáticamente un registro de facturación de alta de forma simultánea o
inmediatamente anterior a la expedición de cada factura

[bmfranky]

Empezado por sglorka

Respecto de crear un programa intermedio que reciba facturas integradas en ficheros, Excel, Csv, etc provenientes de terminales de facturación para, posteriormente, generar la estructura en Xml y enviar a Verifactu, les recuerdo que, el Real decreto 1007/2023 por el que se rige el reglamento que establece los requisitos a adoptar por los sistemas de facturación dice en su Artículo 9:

Artículo 9. Generación del registro de facturación de alta.
Los sistemas informáticos de facturación que sean utilizados por los obligados
tributarios a que se refiere el artículo 3 de este Reglamento, deberán generar
automáticamente un registro de facturación de alta de forma simultánea o
inmediatamente anterior a la expedición de cada factura

Una cosa, mi programa , genera visual mente la factura y la previsualiza en pantalla, personalmente no considero la factura como definitiva hasta que le doy a la opcion de guardar, asi si veo que me he confundido , vuelvo atras, modifico lo que sea y vuelvo a previsualizar, o si es de una venta y el cliente decide que no quiere el articulo, la elimino.
Este forma de proceder, considerais que seria en contra de dicho articulo?

[sglorka]

Empezado por bmfranky

Una cosa, mi programa , genera visual mente la factura y la previsualiza en pantalla, personalmente no considero la factura como definitiva hasta que le doy a la opcion de guardar, asi si veo que me he confundido , vuelvo atras, modifico lo que sea y vuelvo a previsualizar, o si es de una venta y el cliente decide que no quiere el articulo, la elimino.
Este forma de proceder, considerais que seria en contra de dicho articulo?

Si has movido el contador general de facturas para poder previsualizar ese documento, y por lo tanto, dicho documento está provisto de un número válido de factura y haces cambios a demanda... irías en contra de ese artículo. Si eres capaz de generar previamente una prefactura, con su numeración de prefactura, y al final de todas las modificaciones, pulsa sobre "Emitir Factura" y generas en ese mismo momento el registro de facturación, estarías cumpliendo dicho artículo.

[bmfranky]

Empezado por sglorka

Si has movido el contador general de facturas para poder previsualizar ese documento, y por lo tanto, dicho documento está provisto de un número válido de factura y haces cambios a demanda... irías en contra de ese artículo. Si eres capaz de generar previamente una prefactura, con su numeración de prefactura, y al final de todas las modificaciones, pulsa sobre "Emitir Factura" y generas en ese mismo momento el registro de facturación, estarías cumpliendo dicho artículo.

Gracias por la respuesta, no uso contador externo, uso la funcion de auto incremento de la base de datos, que solo incrementa si gravo definitivamente la factura, consulto el numero a asignar previa consulta a la misma.
Entonces , lo mejor es crear 2 visualizaciones una con la numeracion de Proforma , por ejemplo y otra con la numeracion final asignada a la misma puesto que el modulo de vista previa, es el mismo que permite imprimir y exportar la factura.

[antoine0]

Empezado por bmfranky

uso la funcion de auto incremento de la base de datos

No estoy contestando a la pregunta inicial, pero... no estoy seguro que usar la función de auto-numeración siga una buena idea.
Sobre todo, porqué haciéndolo de esta manera, solo puedes tener una única serie de facturas. Y me temo que esto no es sostenible (por lo menos, las facturas rectificativas deben ir en su propia serie).

[ermendalenda]

Hola, he leído en un post anterior que un albarán no se puede modificar una vez enviado o impreso.
Es la primera vez que oigo eso, lo mismo está en alguna normativa que desconozco, me ggustaría saber la referencia a esa norma. Por que no me cuadranpor lógica, no digo que no sea así, pero un albarán carece de valor tributario hasta que sea convertido y emitida la factura, entonces si ya se queda bloqueado.
Una cosa es que el albarán o nota de entrega sirva de justificante de la entrega de mercancía, pero en la mayoría de las empresas hay correcciones posteriores, normalmente por errores detectados posteriormente por el receptor y entonces se produce un acuerdo mutuo. Es raro que se aplique a un albarán las mismas restricciones que una factura después de su emisión, aunque no lo descarto, ya sé que para una trazabilidad es mejor emitir las correcciones en albaranes nuevos, pero el 99,99% lo hace sobre el mismo albarán.

[bmfranky]

Empezado por antoine0

No estoy contestando a la pregunta inicial, pero... no estoy seguro que usar la función de auto-numeración siga una buena idea.
Sobre todo, porqué haciéndolo de esta manera, solo puedes tener una única serie de facturas. Y me temo que esto no es sostenible (por lo menos, las facturas rectificativas deben ir en su propia serie).

Si, tene razon, pero la tabla de la base de datos, por lo menos en mi caso , no es la misma, por lo que cada numeracion no interfiere con las otras, a saver las facturas de reparacion en una tabla, las de venta , en otra, las proforma en otra, ahora las rectificativas, pues iran en otra...
Ademas lo que se me ha ocurrido en mi caso es crear una tabla de la base de datos unica para el encadenamiento de hash del verifactu, como solo puedo trabajar con un tipo de factura a la vez, puesto que no dejo ejecutar dos instancias del programa al mismo tiemo, no hay problema, al acabar la factura se encadena con la anterior que esta indizada en la tabla de verifactu, indistintamente del tipo de factura que fuera.