Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[nincillo]

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

Bueno yo creo que las 2 pueden ser buenas. Cada uno deberá decidir para su programa cual es mejor.
Creo que ambas tienen ventajas/inconvenientes.

Hasta donde yo entiendo (y quizás lo entienda mal). Por un lado está la generación del xml correspondiente a la factura, con su hash y demás, y por otro lado está el envío de dichos xml a hacienda.

Si estoy en lo correcto, quizás la generación del xml sería por parte del equipo que genera la factura y que la dejaría en una carpeta "común" y por otro lado está el programa dedicado al envío de dichos ficheros xml a Hacienda, que no tiene por que hacerlo en tiempo real, ya que según he leído por ahí, la propia hacienda puede marcar el ritmo de envío y el número de facturas a enviar en cada envío.

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

La otra opción que he pensado es con algún sistema de flags, que cada vez que algún equipo equipo genere una factura, un programa en el servidor genere todos los xml de las facturas que se hayan generado desde la última vez o algo así...

Y la facturación en bloque de fin de mes, que se pueden generar cientos de facturas en un momento... En fin... Poco a poco...

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

Empezado por nincillo

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente,
...
Y la facturación en bloque de fin de mes, que se pueden generar cientos de facturas en un momento... En fin...

Bueno, pero de eso no le podemos "echar la culpa" a VERI*FACTU, esos problemas ya los tenemos ahora...

[ermendalenda]

Empezado por nincillo

Hasta donde yo entiendo (y quizás lo entienda mal). Por un lado está la generación del xml correspondiente a la factura, con su hash y demás, y por otro lado está el envío de dichos xml a hacienda.

Si estoy en lo correcto, quizás la generación del xml sería por parte del equipo que genera la factura y que la dejaría en una carpeta "común" y por otro lado está el programa dedicado al envío de dichos ficheros xml a Hacienda, que no tiene por que hacerlo en tiempo real, ya que según he leído por ahí, la propia hacienda puede marcar el ritmo de envío y el número de facturas a enviar en cada envío.

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

La otra opción que he pensado es con algún sistema de flags, que cada vez que algún equipo equipo genere una factura, un programa en el servidor genere todos los xml de las facturas que se hayan generado desde la última vez o algo así...

Y la facturación en bloque de fin de mes, que se pueden generar cientos de facturas en un momento... En fin... Poco a poco...

Hay que hacerlo en fifo, 2 equipos con la misma serie, inevitablemente leen el siguiente njnero de factura en orden cronológico, por tanto da igual quien lo genere que tendrá un orden cronológico, lo que sí se ve es que el envío tiene que ser común para la misma serie.
Yo por ejemplo eso no voy a tener problemas por qur para distintos tpvs tengo números de serie diferente y si hay algún dispositivo más enganchado al tpv(una.pda por ejemplo o un cajón de cobro automatico, o incluso otro tpv satelite) leen y escriben en el mismo sitio, controlando bien los índices únicos no existe problemas.

[antoine0]

Empezado por nincillo

Per la verdad es que cuando te pones a pensar que puede haber varios equipos a la vez facturando con la misma serie, buff, la posibilidad de combinaciones es grande. Si se da el caso de que estén facturando simultáneamente, quizás el primer equipo aún no generó del todo el xml, y el segundo equipo está intentando leer información del xml que aún no se generó o no del todo... En fin...

Es un problema clásico de cola, con un recurso único. Cuando cualquier programa (de varios) está listo para encadenar (es decir, XML del registro generado hasta la parte EncadenamientoRegistroAnterior), se pone en cola para obtener esta información. Él que está en cabeza de la cola entra en sección crítica (mútex), recupera la información del último registro (ID, huella y hora de generación), recupera la hora actual, acaba de completar el XML, calcula su huella, graba el registro ya completado con su DatosControl (la firma se podrá actualizar más tarde, y evidentemente las incidencias también), este registro pasa a ser el último, y puede salir de la sección crítica, liberando para el siguiente en la cola.

El tema de los números de nueva factura pueden gestionarse de la misma manera, es decir atribulándose dentro de la sección crítica; pero no tengo claro si es un requisito imprescindible de los sistemas de facturación que los registros de factura tipo S0 sigan encadenados en orden estrictamente ascendente de número de factura en cada serie (muy posible que me he perdido algo aquí). Obviamente es muy preferible, pero creo que se puede haber circunstancias como las que describes que hacen que los números pueden resultar desordenados a veces, en caso de incidencia en la generación del registro después de haber obtenido un número de futura factura. Y desde luego, dado que el número de factura está mezclado con el número de serie en el campo IDFactura, no veo como Hacienda puede automatizar un control de este requisito.

[ermendalenda]

Empezado por antoine0

Es un problema clásico de cola, con un recurso único. Cuando cualquier programa (de varios) está listo para encadenar (es decir, XML del registro generado hasta la parte EncadenamientoRegistroAnterior), se pone en cola para obtener esta información. Él que está en cabeza de la cola entra en sección crítica (mútex), recupera la información del último registro (ID, huella y hora de generación), recupera la hora actual, acaba de completar el XML, calcula su huella, graba el registro ya completado con su DatosControl (la firma se podrá actualizar más tarde, y evidentemente las incidencias también), este registro pasa a ser el último, y puede salir de la sección crítica, liberando para el siguiente en la cola.

El tema de los números de nueva factura pueden gestionarse de la misma manera, es decir atribulándose dentro de la sección crítica; pero no tengo claro si es un requisito imprescindible de los sistemas de facturación que los registros de factura tipo S0 sigan encadenados en orden estrictamente ascendente de número de factura en cada serie (muy posible que me he perdido algo aquí). Obviamente es muy preferible, pero creo que se puede haber circunstancias como las que describes que hacen que los números pueden resultar desordenados a veces, en caso de incidencia en la generación del registro después de haber obtenido un número de futura factura. Y desde luego, dado que el número de factura está mezclado con el número de serie en el campo IDFactura, no veo como Hacienda puede automatizar un control de este requisito.

Sanción por facturas no correlativas
La sanción por emitir facturas que no guardan correlación y seguimiento numérico se considera una falta leve según Hacienda y por la que tendrías que pagar llegados al caso unos 150€ por cada factura que no se haya emitido correlativamente.
Una de las reglas básicas es que deben llevar un orden numérico y cronológico sin saltos y sin vueltas atrás en el orden de tiempo.
Que sancionen o no, antes dependía del inspector, a partir de ahora no sabemos.

[antoine0]

Empezado por ermendalenda

Sanción por facturas no correlativas
La sanción por emitir facturas que no guardan correlación y seguimiento numérico se considera una falta leve según Hacienda y por la que tendrías que pagar llegados al caso unos 150€ por cada factura que no se haya emitido correlativamente.
Una de las reglas básicas es que deben llevar un orden numérico y cronológico sin saltos y sin vueltas atrás en el orden de tiempo.

Ya. El problema es saber dónde está la norma de tiempo. Hasta ahora, era claro que la norma era la fecha (día) indicada en la factura; y es lo que sigue diciendo el artículo 6.1 b del reglamento de facturación. Todas las facturas de un mismo día deben tener un número superior a las de los días anteriores, sin salto.
Implícitamente, le estas sustituyendo como norma de tiempo la fecha-hora (con ±1 minuto de precisión) del registro S0 de la factura dentro del sistema de facturación. Esta fecha-hora solo se puede ver si se mira el registro S0; no hay que perder de vista que este registro S0 puede ser «mejorado» por un registro S1 ulterior, que será el registro al cual está ligado la factura real.

Hay otro tema relacionado con las fechas que no tengo claro: ¿es correcto emitir una factura que lleva fecha (el día impreso) distinto a la fecha del registro?
El reglamento 2007/23 dice (artículo 9) que un registro debe ser generado simultáneamente o inmediatamente anterior a la expedición; por tanto parece decir que fechas distintas no son posibles, solo se pueden expedir facturas llevando fecha de expedición de hoy.
Sin embargo, en muchos pequeños comercios veo a gente que hacen sus facturas cuando tiene tiempo de hacerlo, por ejemplo los finales de semana, y ponen como fecha a menudo la de final del mes; ¿tendrán que cambiar de costumbre?
Al mismo tiempo, veo a una empresa nacional de telecomunicación que emite sus facturas con 7 días de antelación (hoy emiten las facturas con fecha 19/1/2024); cierto que están en el S.I.I. (y no sé en qué día reporten en SII, supongo que dentro de 7 días) entonces no veré un QR, pero la práctica no para de sorprenderme.

[sglorka]

Empezado por antoine0

Ya. El problema es saber dónde está la norma de tiempo. Hasta ahora, era claro que la norma era la fecha (día) indicada en la factura; y es lo que sigue diciendo el artículo 6.1 b del reglamento de facturación. Todas las facturas de un mismo día deben tener un número superior a las de los días anteriores, sin salto.
Implícitamente, le estas sustituyendo como norma de tiempo la fecha-hora (con ±1 minuto de precisión) del registro S0 de la factura dentro del sistema de facturación. Esta fecha-hora solo se puede ver si se mira el registro S0; no hay que perder de vista que este registro S0 puede ser «mejorado» por un registro S1 ulterior, que será el registro al cual está ligado la factura real.

Hay otro tema relacionado con las fechas que no tengo claro: ¿es correcto emitir una factura que lleva fecha (el día impreso) distinto a la fecha del registro?
El reglamento 2007/23 dice (artículo 9) que un registro debe ser generado simultáneamente o inmediatamente anterior a la expedición; por tanto parece decir que fechas distintas no son posibles, solo se pueden expedir facturas llevando fecha de expedición de hoy.
Sin embargo, en muchos pequeños comercios veo a gente que hacen sus facturas cuando tiene tiempo de hacerlo, por ejemplo los finales de semana, y ponen como fecha a menudo la de final del mes; ¿tendrán que cambiar de costumbre?
Al mismo tiempo, veo a una empresa nacional de telecomunicación que emite sus facturas con 7 días de antelación (hoy emiten las facturas con fecha 19/1/2024); cierto que están en el S.I.I. (y no sé en qué día reporten en SII, supongo que dentro de 7 días) entonces no veré un QR, pero la práctica no para de sorprenderme.

Sí, se pueden emitir facturas que tenga fecha de emisión distinta de la fecha de registro. El caso más claro es la factura rectificativa por sustitución. Si se emite una factura con error en la fecha de expedición se puede emitir una rectificativa por sustitución con la fecha de expedición correcta, y en este caso, obviamente tendrías fechas diferentes de emisión y registro

Otro caso muy común es emitir facturas un viernes con fecha del lunes (ya que la empresa no trabaja los fines de semana) para adelantar trabajo y que el lunes salgan los repartidores temprano.

[antoine0]

Empezado por sglorka

Sí, se pueden emitir facturas que tenga fecha de emisión distinta de la fecha de registro. El caso más claro es la factura rectificativa por sustitución. Si se emite una factura con error en la fecha de expedición se puede emitir una rectificativa por sustitución con la fecha de expedición correcta, y en este caso, obviamente tendrías fechas diferentes de emisión y registro

Estoy leyendo el reglamento de facturación y no veo esta opción de cambiar la fecha de expedición con una rectificativa.
Entiendo que si has expedido una factura con una fecha incorrecta, puedes emitir una rectificativa por sustitución para subsanar el error. Pero creo qué la fecha de expedición de esta rectificativa será la fecha efectiva que se realice la rectificación, no la fecha que debería haber sido puesta en la factura inicial.

Concretamente en el reglamento, el artículo 15.5 dice que la factura rectificativa deberá cumplir los mismos requisitos que cualquier factura; y no he visto nada que hable de fechas de expedición distinta de la fecha en la cual se expide una factura. (Otras cosas distintas son la fecha de devengo del IVA, o sea la fecha o el periodo de liquidación; y evidentemente está también la fecha de operación, que es un campo distinto y va por sus propias normas, y en el caso de la rectificativa aquí pondría la fecha de la operación inicial; pero estas fechas no son parte de los identificadores de una factura).

Por tanto no veo como una factura en un SIF puede llevar una fecha de expedición que difiere de la fecha del registro S0.

NOTA IMPORTANTE: Igual que Neftali tampoco soy experto en temas legales así que por favor si alguien ve que esto, o el anterior, es incorrecto que lo comente.

[sglorka]

Empezado por antoine0

Estoy leyendo el reglamento de facturación y no veo esta opción de cambiar la fecha de expedición con una rectificativa.
Entiendo que si has expedido una factura con una fecha incorrecta, puedes emitir una rectificativa por sustitución para subsanar el error. Pero creo qué la fecha de expedición de esta rectificativa será la fecha efectiva que se realice la rectificación, no la fecha que debería haber sido puesta en la factura inicial.

Concretamente en el reglamento, el artículo 15.5 dice que la factura rectificativa deberá cumplir los mismos requisitos que cualquier factura; y no he visto nada que hable de fechas de expedición distinta de la fecha en la cual se expide una factura. (Otras cosas distintas son la fecha de devengo del IVA, o sea la fecha o el periodo de liquidación; y evidentemente está también la fecha de operación, que es un campo distinto y va por sus propias normas, y en el caso de la rectificativa aquí pondría la fecha de la operación inicial; pero estas fechas no son parte de los identificadores de una factura).

Por tanto no veo como una factura en un SIF puede llevar una fecha de expedición que difiere de la fecha del registro S0.

NOTA IMPORTANTE: Igual que Neftali tampoco soy experto en temas legales así que por favor si alguien ve que esto, o el anterior, es incorrecto que lo comente.

No vas a encontrar en el reglamento exactamente lo que buscas. El reglamento te dice muy claro lo que debes hacer en ciertas circunstancias y en otras lo deja a tu interpretación siempre y cuando no vulneres el reglamento. ¿ Dice el reglamento que la fecha de expedición de una factura tiene que ser la misma que el día en que la expides ?. No los vas a encontrar por que no lo dice. Pero sí dice lo siguiente:

Reglamento de facturación
Artículo 11. Plazo para la expedición de las facturas.
1. Las facturas deberán ser expedidas en el momento de realizarse la operación.
No obstante, cuando el destinatario de la operación sea un empresario o profesional que actúe como tal, las facturas deberán expedirse antes del día 16 del mes siguiente a aquél en que se haya producido el devengo del Impuesto correspondiente a la citada operación.

O sea, yo puede ir realizando notas de entrega a un cliente empresario durante el mes de marzo y después emitirle una factura resumen de esas operaciones antes del 16 de abril. Como debo respetar la numeración correlativa y las fechas de expedición de forma ascendente, estando a día 16 de abril emito una factura resumen de operaciones con fecha 17 de abril (no tengo facturas emitidas después del 16 de abril ). Le envío la factura al cliente y me responde al día siguiente reclamándome que la fecha de factura es errónea. Ahora ¿Cómo lo soluciono? ¿ Emito una rectificativa con fecha 17 de abril, día en el que estoy ? no debería por que sigo sin resolver el problema.
Lo que debo hacer es emitir una rectificativa por sustitución con fecha de emisión 16 de abril, para corregir la factura errónea.

En resumen, hay que respetar la cronología NumeroFactura-FechaExpedición pero como pueden haber errores, se debe poder rectificarlos, es lo que subyace en el reglamento cuando crea la factura rectificativa, eso si, sin intentar torcerlo. Si yo sé que no tengo facturas emitidas hoy ni las voy a emitir. ¿ qué problema hay en emitirlas hoy con fecha del día siguiente?

Te adjunto link de consulta vinculante realizada a la administración donde se recoge el caso de la emisión de una factura rectificativa por error en fecha de expedición.
https://www.iberley.es/resoluciones/...4-2022-1538919

[ermendalenda]

Empezado por antoine0

Ya. El problema es saber dónde está la norma de tiempo. Hasta ahora, era claro que la norma era la fecha (día) indicada en la factura; y es lo que sigue diciendo el artículo 6.1 b del reglamento de facturación. Todas las facturas de un mismo día deben tener un número superior a las de los días anteriores, sin salto.
Implícitamente, le estas sustituyendo como norma de tiempo la fecha-hora (con ±1 minuto de precisión) del registro S0 de la factura dentro del sistema de facturación. Esta fecha-hora solo se puede ver si se mira el registro S0; no hay que perder de vista que este registro S0 puede ser «mejorado» por un registro S1 ulterior, que será el registro al cual está ligado la factura real.

Hay otro tema relacionado con las fechas que no tengo claro: ¿es correcto emitir una factura que lleva fecha (el día impreso) distinto a la fecha del registro?
El reglamento 2007/23 dice (artículo 9) que un registro debe ser generado simultáneamente o inmediatamente anterior a la expedición; por tanto parece decir que fechas distintas no son posibles, solo se pueden expedir facturas llevando fecha de expedición de hoy.
Sin embargo, en muchos pequeños comercios veo a gente que hacen sus facturas cuando tiene tiempo de hacerlo, por ejemplo los finales de semana, y ponen como fecha a menudo la de final del mes; ¿tendrán que cambiar de costumbre?
Al mismo tiempo, veo a una empresa nacional de telecomunicación que emite sus facturas con 7 días de antelación (hoy emiten las facturas con fecha 19/1/2024); cierto que están en el S.I.I. (y no sé en qué día reporten en SII, supongo que dentro de 7 días) entonces no veré un QR, pero la práctica no para de sorprenderme.

La fecha de emisión de la factura debe ser la misma fecha de la prestación de servicio o entrega de mercancía, según el caso, también se puede dar el caso de las entregas a cuenta para un servicio, que tengo entendido que hay que emitir también una factura y ya después descontarla en la factura total. Sobre los reglamentos de facturación yo ya le daba carpetazo para los temas específicos, el reglamento verifactu es claro diciendo que este reglamento está por encima de cualquier otro reglamento existente, a ver uqe nos cuenta cuando cierren el proyecto.