Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

Empezado por keys

Yo no veo que las facturas de anulación tengan encadenamiento. Yo interpreto que el campo EncadenamientoFacturaAnterior de la anulación se refiere a lo mismo que tiene la factura original.

Pues yo estaba pensando más o menos lo mismo.
Una anulación NO ES UNA FACTURA como tal, sino que es una operación sobre una factura anterior.

Una anulación no tiene SERIE (por lo dicho anteriormente). Por lo tanto cuando habla de EncadenamientoFacturaAnterior, que incluye NumSerieFacturaAnterior, me hace pensar que son datos de la original que estamos anulando, no de la anterior anulación.
En concreto dice: Nº Serie+Nº Factura que identifica a la factura anterior; No tiene sentido que hable de la anterior anulación (creo).

Esto coincide con lo que se hace en TicketBAI.

[ermendalenda]

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

Pues yo estaba pensando más o menos lo mismo.
Una anulación NO ES UNA FACTURA como tal, sino que es una operación sobre una factura anterior.

Una anulación no tiene SERIE (por lo dicho anteriormente). Por lo tanto cuando habla de EncadenamientoFacturaAnterior, que incluye NumSerieFacturaAnterior, me hace pensar que son datos de la original que estamos anulando, no de la anterior anulación.
En concreto dice: Nº Serie+Nº Factura que identifica a la factura anterior; No tiene sentido que hable de la anterior anulación (creo).

Esto coincide con lo que se hace en TicketBAI.

Se produce una anomalia meter 2 veces el mismo dato, en fin tendrán que aclararlo

[nuevo1234]

Empezado por ermendalenda

Se produce una anomalia meter 2 veces el mismo dato, en fin tendrán que aclararlo

Parece q se quiere encadenar las anulaciones con la anterior como cualquier otra factura.

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

Empezado por nuevo1234

Parece q se quiere encadenar las anulaciones con la anterior como cualquier otra factura.

El encadenamiento incluye esto:



Este encadenamiento, a priori, no puede referirse a la anterior "anulación", porque la "anulación" no incluye ni serie ni número.

Los campos serie y número de factura de una anulación (según la documentación) son los de la "factura anulada".

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

De todas formas, al igual que en TicketBAI, a medida que vayan contestando dudas y si sacan un "Preguntas/Respuestas frecuentes" iremos aclarando estas cosas.
En algún momento también (que no lo he visto hasta ahora) habilitarán un buzón o una dirección de correo para poder enviar dudas.

[afxe]

De acuerdo con Neftali. Actualmente mi ERP y mi Contabilidad están en ejecutables y bases de datos diferentes. Una vez emitida una factura, se duplica la información con relevancia fiscal en la contabilidad. El usuario no puede "borrar" facturas, pero puede marcarla como "Anulada" (se queda el registro de la factura pero sin peso logístico, financiero, estadístico ni fiscal). Al marcar una factura como anulada el registro queda, aunque en el sistema contable esa factura sí se borra físicamente del libro de IVA, por que a efectos fiscales deja de existir.
Imagino que el que las altas y las anulaciones se hagan con mensajes diferentes es relativo a esto. Una anulación lanza una marca contra la factura originalmente subida para que esa misma factura conste como NO-VALIDA, pero realmente no se está emitiendo una "Factura Rectificativa".

Hablando de Facturas Rectificativas, el modelo diferencia entre dos tipos de rectificaciones: Por sustitución o por diferencia... Creo entender que :

a) Por sustitución creo que se refiere a emitir una factura nueva (nueva serie, numero, fecha, importe....) que sustituye a una factura previamente enviada, con lo cual sería un proceso equivalente a lanzar una anulación de la primera, y una nueva alta de la segunda, pero en un sólo paso... ¿Lo entendéis así?. El cliente que recibe la factura sustitutiva debería destruir y/o borrar la primera y declarar sólo la segunda... pero corremos el riesgo de que el cliente mande a su gestor las dos facturas (tendrán numeración diferente, y las facturas recibidas no se transmiten a Hacienda)

b) Por Rectificación... se refiere a que emito una nueva factura con importe que se suma o resta a la factura anterior. Es decir, las típicas facturas de devolución de mercancía, o abonos por error en precios, cambio de titular... las dos facturas quedan como válidas y el cliente abonará y registrará ambas facturas.

Otra cosa: El envío por bloques... parece ser que cada vez que envías un registro de factura, Hacienda te dirá cuando y cuantas facturas tienes que enviar en la siguiente comunicación, y normalmente será: Una sola factura y en el momento que se haga.... aunque te pueden decir que envíes hasta 1000 facturas o las que hayas generado en un máximo de 2 horas.... y tendrás que atenerte a suministrar el siguiente XML como lo piden, (aclaran que lo normal será el envío de cada factura individualmente). Esto quitaría el problema de los encadenamientos en caso de facturas rechazadas, ya que se podría parar de enviar facturas cuando una no cuela. ¿pero hasta cuando puedo parar el servicio de envío? En los clientes que tengo que están sujetos al SII no paran de tener problemas con NIF mal identificados... sobre todo si las altas de los clientes las hacen los propios clientes vía web, hay muchos reacios a meter datos identificativos válidos.. o comerciales que crean clientes en sistemas móviles, y ponen el NIF, CIF, NIE como le parecen (sin la letra, números cambiados, demasiado largos o cortos...) Luego toca a los administrativos localizar y rectificar ese datos para poder subirlas al SII, pero a veces tardan hasta 3 y 4 días en arreglar una factura que tenga un error de este tipo. Puede ser este fallo, o cualquier otro... si una factura está mal, parará el envío de las siguientes hasta que no esté bien, pues no se puede generar la huella para la siguiente factura.... ¿Esto entendéis que debe ser así?.

Ultima cosa en cuanto al SII: Se supone que un SIF debe obligatoriamente enviar las facturas, es decir, no puedo tener un programa de TPV en un cash o supermercado que esté emitiendo facturas (simplificadas o no) y que de forma asíncrona (o síncrona) las envíe a un servidor que cuando le parece, proceda a subir estas facturas a Hacienda. Bastaría que un TPV lo desconecten de la red para que esas facturas no vayan a ningún lado. (Aclaro que en nuestro sistema, los TPV tienen capacidad de funcionar autónomamente tanto en datos como en suministro eléctrico, por si hay un apagón, caída de red, avería del servidor o actualizaciones de sistema, los lineales de supermercados puedan seguir facturando y cobrando a los clientes).

En un modelo normal (por lo menos para mí) cada cierto tiempo preestablecido (segundos, minutos u horas), los TPV vuelcan la información capturada al ERP y sincronizan sus datos maestros (artículos, precios y ofertas). Al final del día se produce el volcado de toda la facturas recogidas en el ERP a la base de datos contable. Al día siguiente, las facturas contabilizadas el día anterior se envían al SII a través de otro programa que está en un puesto de trabajo con Firma Digital instalada (no lo puede hacer cualquiera), y quedan pendientes las facturas con error para ser subsanadas y subidas a la mayor brevedad.

Ahora se supone que el envío lo tiene que hacer cada TPV en cuanto se genera la factura, a no ser que estés sujeto al SII, entonces podrás configurar los TPV para que no hagan envío y sigan el método normal para el SII... ¿no da pie esto a que se pueda configurar qué TPV envían facturas y cuales no? Yo no podría certificar ante hacienda que con mi programa es imposible hacer facturas que no se declaren, ya que incluso el no enviar las facturas puede deberse a fallos de hardware o de las propias comunicaciones (tener el puesto desconectado de la red y actualizar los datos con un pendrive).

[ermendalenda]

Empezado por afxe

De acuerdo con Neftali. Actualmente mi ERP y mi Contabilidad están en ejecutables y bases de datos diferentes. Una vez emitida una factura, se duplica la información con relevancia fiscal en la contabilidad. El usuario no puede "borrar" facturas, pero puede marcarla como "Anulada" (se queda el registro de la factura pero sin peso logístico, financiero, estadístico ni fiscal). Al marcar una factura como anulada el registro queda, aunque en el sistema contable esa factura sí se borra físicamente del libro de IVA, por que a efectos fiscales deja de existir.
Imagino que el que las altas y las anulaciones se hagan con mensajes diferentes es relativo a esto. Una anulación lanza una marca contra la factura originalmente subida para que esa misma factura conste como NO-VALIDA, pero realmente no se está emitiendo una "Factura Rectificativa".

Hablando de Facturas Rectificativas, el modelo diferencia entre dos tipos de rectificaciones: Por sustitución o por diferencia... Creo entender que :

a) Por sustitución creo que se refiere a emitir una factura nueva (nueva serie, numero, fecha, importe....) que sustituye a una factura previamente enviada, con lo cual sería un proceso equivalente a lanzar una anulación de la primera, y una nueva alta de la segunda, pero en un sólo paso... ¿Lo entendéis así?. El cliente que recibe la factura sustitutiva debería destruir y/o borrar la primera y declarar sólo la segunda... pero corremos el riesgo de que el cliente mande a su gestor las dos facturas (tendrán numeración diferente, y las facturas recibidas no se transmiten a Hacienda)

b) Por Rectificación... se refiere a que emito una nueva factura con importe que se suma o resta a la factura anterior. Es decir, las típicas facturas de devolución de mercancía, o abonos por error en precios, cambio de titular... las dos facturas quedan como válidas y el cliente abonará y registrará ambas facturas.

Otra cosa: El envío por bloques... parece ser que cada vez que envías un registro de factura, Hacienda te dirá cuando y cuantas facturas tienes que enviar en la siguiente comunicación, y normalmente será: Una sola factura y en el momento que se haga.... aunque te pueden decir que envíes hasta 1000 facturas o las que hayas generado en un máximo de 2 horas.... y tendrás que atenerte a suministrar el siguiente XML como lo piden, (aclaran que lo normal será el envío de cada factura individualmente). Esto quitaría el problema de los encadenamientos en caso de facturas rechazadas, ya que se podría parar de enviar facturas cuando una no cuela. ¿pero hasta cuando puedo parar el servicio de envío? En los clientes que tengo que están sujetos al SII no paran de tener problemas con NIF mal identificados... sobre todo si las altas de los clientes las hacen los propios clientes vía web, hay muchos reacios a meter datos identificativos válidos.. o comerciales que crean clientes en sistemas móviles, y ponen el NIF, CIF, NIE como le parecen (sin la letra, números cambiados, demasiado largos o cortos...) Luego toca a los administrativos localizar y rectificar ese datos para poder subirlas al SII, pero a veces tardan hasta 3 y 4 días en arreglar una factura que tenga un error de este tipo. Puede ser este fallo, o cualquier otro... si una factura está mal, parará el envío de las siguientes hasta que no esté bien, pues no se puede generar la huella para la siguiente factura.... ¿Esto entendéis que debe ser así?.

Ultima cosa en cuanto al SII: Se supone que un SIF debe obligatoriamente enviar las facturas, es decir, no puedo tener un programa de TPV en un cash o supermercado que esté emitiendo facturas (simplificadas o no) y que de forma asíncrona (o síncrona) las envíe a un servidor que cuando le parece, proceda a subir estas facturas a Hacienda. Bastaría que un TPV lo desconecten de la red para que esas facturas no vayan a ningún lado. (Aclaro que en nuestro sistema, los TPV tienen capacidad de funcionar autónomamente tanto en datos como en suministro eléctrico, por si hay un apagón, caída de red, avería del servidor o actualizaciones de sistema, los lineales de supermercados puedan seguir facturando y cobrando a los clientes).

En un modelo normal (por lo menos para mí) cada cierto tiempo preestablecido (segundos, minutos u horas), los TPV vuelcan la información capturada al ERP y sincronizan sus datos maestros (artículos, precios y ofertas). Al final del día se produce el volcado de toda la facturas recogidas en el ERP a la base de datos contable. Al día siguiente, las facturas contabilizadas el día anterior se envían al SII a través de otro programa que está en un puesto de trabajo con Firma Digital instalada (no lo puede hacer cualquiera), y quedan pendientes las facturas con error para ser subsanadas y subidas a la mayor brevedad.

Ahora se supone que el envío lo tiene que hacer cada TPV en cuanto se genera la factura, a no ser que estés sujeto al SII, entonces podrás configurar los TPV para que no hagan envío y sigan el método normal para el SII... ¿no da pie esto a que se pueda configurar qué TPV envían facturas y cuales no? Yo no podría certificar ante hacienda que con mi programa es imposible hacer facturas que no se declaren, ya que incluso el no enviar las facturas puede deberse a fallos de hardware o de las propias comunicaciones (tener el puesto desconectado de la red y actualizar los datos con un pendrive).

*lo de las rectif8caciones por sustitución o por diferencias es como dices, y por ello a mi me gusta más por diferencias,.

si una factura está mal, parará el envío de las siguientes hasta que no esté bien, pues no se puede generar la huella para la siguiente factura.... ¿Esto entendéis que debe ser así?.

No creo, ya que imagínate que estas en el escenario de envío de varias y te da error una intermedia.
Lo lógico, como en ticketbai, es que sigas enviando, aún con el encadenamiento roto, arregles y envíes la defectuosa cuando esté arreglada indicando en el último campo<incidencia>S</incidencia>
Pero queda la duda de si se envia encadenando de nuevo con la última enviada, que supongo que sí.
Lo de desconectar un tpv da igual, emitidas un qr que culaquier cliente qur lo escanea da la alarma de que no se ha enviado.

[antoine0]

Empezado por afxe

Actualmente mi ERP y mi Contabilidad están en ejecutables y bases de datos diferentes. Una vez emitida una factura, se duplica la información con relevancia fiscal en la contabilidad. El usuario no puede "borrar" facturas, pero puede marcarla como "Anulada" (se queda el registro de la factura pero sin peso logístico, financiero, estadístico ni fiscal). Al marcar una factura como anulada el registro queda, aunque en el sistema contable esa factura sí se borra físicamente del libro de IVA, por que a efectos fiscales deja de existir.

Me parece un buen diseño; supongo que registrarás al causante de la anulación, con fecha y hora del evento de anulación, independientemente de los demás datos. Solo una precisión: la anulación puede (no es habitual) ser pasada en contabilidad con una fecha distinta, y por tanto puede teóricamente estar en un periodo de liquidación de IVA distinto al periodo de la factura inicial; esto está correctamente reflejado en el esquema de anulación en Excel o el .XSD, donde además de la referencia de la factura (ID emisor, número de serie y de factura, fecha de emisión inicial), la única información (fuera de todo ligado al S.I.F.) es el periodo de liquidación y une referencia externa opcional.

[antoine0]

Empezado por afxe

En los clientes que tengo que están sujetos al SII no paran de tener problemas con NIF mal identificados... sobre todo si las altas de los clientes las hacen los propios clientes vía web, hay muchos reacios a meter datos identificativos válidos.. o comerciales que crean clientes en sistemas móviles, y ponen el NIF, CIF, NIE como le parecen (sin la letra, números cambiados, demasiado largos o cortos...) Luego toca a los administrativos localizar y rectificar ese datos para poder subirlas al SII, pero a veces tardan hasta 3 y 4 días en arreglar una factura que tenga un error de este tipo. Puede ser este fallo, o cualquier otro... si una factura está mal, parará el envío de las siguientes hasta que no esté bien, pues no se puede generar la huella para la siguiente factura.... ¿Esto entendéis que debe ser así?

Aquí no tardemos 3 o 4 días (pero a veces 2) y tenemos exactamente los mismos problemas; además hay que ver que el problema a veces no es siempre responsabilidad del cliente, pero sí de la administración con su peculiar forma de registrar los nombres de los sujetos (y además no aceptar correcciones). En la historia del S.I.I., ha aparecido un código de ID (el 07) para un caso un poco similar, dar de alta temporalmente un NIF español «no censado», para poner subsanarlo ulteriormente; pero claro, en el S.I.I se admiten correcciones de errores...
Y sí, he llegado a la misma conclusión que tú: un error de NIF bloquearía toda el proceso.
Me he planteado la idea de hacer un control online del NIF (o del NIF-IVA) en el momento de generar el registro (hablando S.I.F.), pero no he llegado hasta concretizarlo. Además, si parece posible hacerlo dentro de los tiempos impartidos para el S.I.I. que van en días, parece más complejo posible hacerlo en vivo cuando tienes que emitir un ticket para el cliente que está enfrente de tu TPV...

Creo que ésta será una muy buena pregunta frecuente.

[ermendalenda]

Empezado por antoine0

Aquí no tardemos 3 o 4 días (pero a veces 2) y tenemos exactamente los mismos problemas; además hay que ver que el problema a veces no es siempre responsabilidad del cliente, pero sí de la administración con su peculiar forma de registrar los nombres de los sujetos (y además no aceptar correcciones). En la historia del S.I.I., ha aparecido un código de ID (el 07) para un caso un poco similar, dar de alta temporalmente un NIF español «no censado», para poner subsanarlo ulteriormente; pero claro, en el S.I.I se admiten correcciones de errores...
Y sí, he llegado a la misma conclusión que tú: un error de NIF bloquearía toda el proceso.
Me he planteado la idea de hacer un control online del NIF (o del NIF-IVA) en el momento de generar el registro (hablando S.I.F.), pero no he llegado hasta concretizarlo. Además, si parece posible hacerlo dentro de los tiempos impartidos para el S.I.I. que van en días, parece más complejo posible hacerlo en vivo cuando tienes que emitir un ticket para el cliente que está enfrente de tu TPV...

Creo que ésta será una muy buena pregunta frecuente.

De esta parte no os preocupeis ya le dediqué tiempo por que tenia la misma inquietud. Tengo un control para los identificadores nifs/cifs/nies internacionales...l
que verifica con 2 servicios RES gratuitos de respuesta inmediata, que el cif corresponde con el nombre, que es correcto y que no ha sido revocado., que ya os pasaré cuando pasen un poco estas fechas veraniegas que me tienen liadisimo. A ver si podemos avanzar en generar en unos xmls de ejemplo.

[antoine0]

Empezado por afxe

Hablando de Facturas Rectificativas, el modelo diferencia entre dos tipos de rectificaciones: Por sustitución o por diferencia... Creo entender que :
a) Por sustitución creo que se refiere a emitir una factura nueva (nueva serie, numero, fecha, importe....) que sustituye a una factura previamente enviada, con lo cual sería un proceso equivalente a lanzar una anulación de la primera, y una nueva alta de la segunda, pero en un sólo paso... ¿Lo entendéis así?. El cliente que recibe la factura sustitutiva debería destruir y/o borrar la primera y declarar sólo la segunda... pero corremos el riesgo de que el cliente mande a su gestor las dos facturas (tendrán numeración diferente, y las facturas recibidas no se transmiten a Hacienda)
b) Por Rectificación... se refiere a que emito una nueva factura con importe que se suma o resta a la factura anterior. Es decir, las típicas facturas de devolución de mercancía, o abonos por error en precios, cambio de titular... las dos facturas quedan como válidas y el cliente abonará y registrará ambas facturas.

En el caso a), en el SII hay dos opciones: en la opción 1 tu informas en el campo ImporteRectificacion de la base y cuota de la factura original; en la opción 2 hay una factura suplementaria (tipo F1) de abono que cancela completamente la factura inicial; y la factura rectificada se parece a una factura normal, solo que tiene un campo ImporteRectificacion a 0.
En la opción 2 me parece claro que la factura inicial va ligada con la de abono en la contabilidad del cliente: o las dos o ninguna. Para mí es de todas las opciones (S o I) la más clara.
Con la opción 1 me parece menos evidente, creo que depende si el sistema del cliente sabe interpretar los ImporteRectificacion como bases y cuotas negativas: si sabe, puede quedarse la factura inicial; si no sabe, tiene que dar de baja (o decidir de no registrar) la factura inicial. En cualquier caso, si el cliente, o mejor dicho la gestoría del cliente, decide guardar los dos en paralelo, o incluso deducir dos veces las cuotas... bueno ya creo que es su problema, ¿no?

En el caso b), por diferencias, es más limpio: claramente las dos facturas deben ser registradas; y no hay ningún ImporteRectificacion que viene a complicar las cosas. Solo que no veo a qué piensas por «cambio de titular». Y no estoy seguro que todos los casos pueden tratarse con este modo.