Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[adolphsys]

Empezado por espinete

Bueno, al menos entiendo que VeriFactu, que es a lo que yo me refería con la "nueva factura electrónica" que entrará en vigor en 2023-2024-2025, es como el TicketBAI para toda España, con su CódigoQR, etc. ¿Es así?

Todavía no he empezado a leer la documentación y no sí si ya hay entorno de pruebas, etc. porque cuando lo anunciaron estaba bastante agobiado ya con TicketBAI como para meterme con otra cosa, pero si me confirmas que efectivamente es muy parecido a TicketBAI, entonces me relajo un poco más

Si, por lo que sabemos hasta ahora (en líneas generales) VeriFactu será similar a TicketBAI.

Aún no han publicado el entorno de pruebas, por ahora tenemos esto https://www.agenciatributaria.es/AEA...ERI_FACTU.html

[espinete]

Buenas...

He importado el WSDL publicado en la documentación de Verifactu (//prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SistemaFacturacion.wsdl) en Delphi, pero no puedo compilar porque en el archivo SistemaFacturacion.pas generado hay strings de más de 255 caracteres.

Supongo que tiene fácil solución, pero quería saber si es que se ha importado mal o incluso si merece la pena empezar a hacer ya algo de desarrollo o es mejor esperar.

Por lo que veo, está publicado el wsdl para poder generar el XML, así como el diseño de alta y anulación.
Lo que no veo son las URLs de envío para el alta y anulación de facturas, e información técnica para generar el QR, etc. como sí había para el TicketBAI.

¿O es que sigue todo muy verde aún?

Gracias

[keys]

Empezado por espinete

Buenas...

He importado el WSDL publicado en la documentación de Verifactu (//prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SistemaFacturacion.wsdl) en Delphi, pero no puedo compilar porque en el archivo SistemaFacturacion.pas generado hay strings de más de 255 caracteres.

Supongo que tiene fácil solución, pero quería saber si es que se ha importado mal o incluso si merece la pena empezar a hacer ya algo de desarrollo o es mejor esperar.

Por lo que veo, está publicado el wsdl para poder generar el XML, así como el diseño de alta y anulación.
Lo que no veo son las URLs de envío para el alta y anulación de facturas, e información técnica para generar el QR, etc. como sí había para el TicketBAI.

¿O es que sigue todo muy verde aún?

Gracias

De momento todod esta muy verde. No hay servidores ni nada solo los ficheros.

[espinete]

Gracias, Keys.

Tengo un cliente que me acaba de decir que su asesor contable le ha pedido ya todas las facturas "para empezar a subir los ficheros a Hacienda" por la entrada en vigor de VeriFactu y la Ley Antifraude, y ya no sé cual de los tres está más loco, si yo, mi cliente o su contable.

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

Empezado por espinete

Tengo un cliente que me acaba de decir que su asesor contable le ha pedido ya todas las facturas "para empezar a subir los ficheros a Hacienda" por la entrada en vigor de VeriFactu y la Ley Antifraude

Pero si no hay ni dónde subirlas...

[[newtron]]

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

Pero si no hay ni dónde subirlas...

Yo creo que las va a "subir" a lo alto de la estantería.

Edito: Pero que yo me entere.... ¿este hilo es de Facturas electrónicas o de Verifactu?

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

Empezado por newtron

Edito: Pero que yo me entere.... ¿este hilo es de Facturas electrónicas o de Verifactu?

No me he dado cuenta, tienes razón.
Hilo equivocado.

[espinete]

Empezado por newtron

Edito: Pero que yo me entere.... ¿este hilo es de Facturas electrónicas o de Verifactu?

Yo sigo sin entender la diferencia, la verdad.

Facturas electrónicas: facturae, face, sii o incluso un pdf firmado con certificado, si nos ponemos técnicos...
Verifactu: Evolución de la Ley Antifraude: Impresión de QR en ticket/factura + envío a Hacienda (aún sin urls de envío ni entorno de pruebas). Muy similar (presumiblemente) a TicketBAI.

He leído en algunos artículos que he encontrado online (suelen ser blogs de asesorías fiscales o de empresas de software) que Canarias y País Vasco estarán excluidas (entiendo que lo esté País Vasco porque ya tienen TicketBAI, pero Canarias?). Sin embargo no he encontrado nada oficial que indique eso.
También hay un lío de fechas para la entrada en vigor.

Incluso tengo amigos en otras empresas de software que dicen que debe ser la empresa de software de facturación la que suba a un espacio web propio todas las facturas para que los clientes puedan leerlas.

Ya me estoy volviendo medio loco...

[ermendalenda]

Empezado por espinete

Buenas...

He importado el WSDL publicado en la documentación de Verifactu (//prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SistemaFacturacion.wsdl) en Delphi, pero no puedo compilar porque en el archivo SistemaFacturacion.pas generado hay strings de más de 255 caracteres.

Supongo que tiene fácil solución, pero quería saber si es que se ha importado mal o incluso si merece la pena empezar a hacer ya algo de desarrollo o es mejor esperar.

Por lo que veo, está publicado el wsdl para poder generar el XML, así como el diseño de alta y anulación.
Lo que no veo son las URLs de envío para el alta y anulación de facturas, e información técnica para generar el QR, etc. como sí había para el TicketBAI.

¿O es que sigue todo muy verde aún?

Gracias

Hola, ya puse el xsd y algun ejemplo de xml.
De hecho ya he enviado al correo de verifactu 7 facturas encadenadas de distintos tipos y me han contestado, tenía un fallo en un campo en las recapitulativas, por lo demás me han dado el "ok".me han dicho que los encadenamientos oks etc.. que aparentemente todo ok por que aún no hacen la comprobación exhaustiva. Ya queda en ti lo que quieras adelantar, pero yo prácticamente ya tengo verifactu preparado a falta del QR y de la url de envío.

[ermendalenda]

Hola de nuevo, en los ejemplos que he enviado a Verifactu e incluido 1 anulación y me han hecho la picha un lio o se la han hecho ellos, yo pienso que como aún no ienen moontado el sistema de comprobaciones lo han hecho a mano y se han podido liar.
Explico a ver que pensais:

1. Emito 1 factura simplificada.
2. Emito 1 factura recapitulativa de esa simplificada(con los datos del cliente)
3. Me doy cuenta, antes de darsela al cliente, que me he equivocado de cliente.
4. Anulo LA RECAPITULATIVA.
5. Vuelvo a emitir recapitulativa, con el siguiente número dde serie de las recapitulativas, de la factura simplificada del paso 1.

Ellos me dicen que los encadenamientos ok y tal pero me dan una advertencia:

"Es importante destacar que el hecho de generar una factura sustitutiva o rectiuficativa no requiere de a anulación del registro de facturación de alta correspondiente a la factura original..."

(ESO YA LO SÉ)

"...Los registros de facturación de alta solo se deben anular si hubiera un error en sus datos, Hay diversos escenarios que requieren la anulación de un registro de facturación de alta. `pr ej. cuando algún dato contenido en el registro sea erroneo..."

No conviene confundir estos escenarios de anulación con los casos en los que se emite una nueva factura que rectitica o sustituye a la anterio. En estos casos, no hace falta anular el registro de alta original pues no hay ningún error. Es decir, si el reglamento de Facturación admite la emissión de una nueva factura rectificativa, el sistema informático e facturación debera generar un nuevo registro de facturación de alta correspondiente a la nueva factura, pero no es necesario anular la nueva factura.

Claro, ahora estoy liado, si le hago caso al mensaje, tendria que hacer una ¿RECTIFICATIVA DE UNA RECAPITULATIVA? por datoss del cliente incorrecto, que cosa mas rara.
¿Que pensais?, ¿es un error de ellos o mio?

Saludos

[antoine0]

Empezado por ermendalenda

Hola de nuevo, en los ejemplos que he enviado a Verifactu e incluido 1 anulación y me han hecho la picha un lio o se la han hecho ellos, yo pienso que como aún no ienen moontado el sistema de comprobaciones lo han hecho a mano y se han podido liar.
Explico a ver que pensais:

1. Emito 1 factura simplificada.
2. Emito 1 factura recapitulativa de esa simplificada(con los datos del cliente)
3. Me doy cuenta, antes de darsela al cliente, que me he equivocado de cliente.
4. Anulo LA RECAPITULATIVA.
5. Vuelvo a emitir recapitulativa, con el siguiente número dde serie de las recapitulativas, de la factura simplificada del paso 1.

Ellos me dicen que los encadenamientos ok y tal pero me dan una advertencia:
[...]

Claro, ahora estoy liado, si le hago caso al mensaje, tendria que hacer una ¿RECTIFICATIVA DE UNA RECAPITULATIVA? por datoss del cliente incorrecto, que cosa mas rara.
¿Que pensais?, ¿es un error de ellos o mio?

Creo que hay cosas distintas, que no se debe confundir (y hablo en general, creo que @ermendalenda lo tiene claro).
Una cosa es un registro de anulación, dentro del S.I.F.
Otra cosa son cancelaciones de facturas, es decir entidades (líneas del SGBDR si se prefiere) de la tabla Facturas que van en sentido contrario, para cancelar una factura anterior.

El primero se da si tu empiezas a emitir una factura (entonces por ejemplo le das un número), luego te das cuenta que hay algún problema, normalmente de índole informático, y no se debe tener en cuenta lo ocurrido. Entonces si ya has grabado el registro en el SIF, debes marcarlo como Deleted. Esto se hace con un registro de anulación. Todo ocurre como si dicha factura no ha existido nunca (pero el número está quemado).

El segundo se da cuando hay una razón de negocio para cancelar una factura. Debe tener un efecto contable, en sentido contrario a las factura que cancela. Esta cancelación se debe informar con un registro de alta. Y también tendrá su proprio número de factura.

Ahora bien, en el 4º de la lista arriba, pueden darse cualquiera de los dos casos. La diferencia realmente es si la factura emitida en 2 ha sido registrada formalmente en sistemas externos al S.I.F., o se ha quedado «estancada» dentro del propio SIF. Esto solo lo puede saber él que opera el S.I.F. Entonces las dos operativas deben ser aceptadas por el sistema Veri*Factu; y también deben ser contempladas en el sistema; entonces sí, es posible que, dependiendo de la operativa y visto el marco del reglamento de facturación, se pueden dar el caso de «rectificativas de recapitulativas».
Solo que no es el caso aquí (si sigo el ejemplo descrito). Y esto no lo puede determinar Hacienda.
En cualquier caso, no creo que haya error tuyo.
Entonces la advertencia, aunque entiendo la intención (advertir de la 2ª opción), me parece mal formulada para no decir un poco engañosa, al insinuar que la anulación en 4 no procede.
Creo que valdría la pena alzar el caso a los de Hacienda, a ver si pueden mejorar el mensaje.

Otra posibilidad sería de obligar a documentar un poco las razones para anular un registro (añadiendo a las especificaciones; un trabajo para Hacienda); si los casos contemplados son suficientemente estrechos, quedaría claro a los desarrolladores que los registros de anulación no sirven para cancelaciones de facturas, y no haría falta emitir ¡ninguna advertencia! Ahora bien, este es ¡mi opinión!

[ermendalenda]

Empezado por antoine0

Creo que hay cosas distintas, que no se debe confundir (y hablo en general, creo que @ermendalenda lo tiene claro).
Una cosa es un registro de anulación, dentro del S.I.F.
Otra cosa son cancelaciones de facturas, es decir entidades (líneas del SGBDR si se prefiere) de la tabla Facturas que van en sentido contrario, para cancelar una factura anterior.

El primero se da si tu empiezas a emitir una factura (entonces por ejemplo le das un número), luego te das cuenta que hay algún problema, normalmente de índole informático, y no se debe tener en cuenta lo ocurrido. Entonces si ya has grabado el registro en el SIF, debes marcarlo como Deleted. Esto se hace con un registro de anulación. Todo ocurre como si dicha factura no ha existido nunca (pero el número está quemado).

El segundo se da cuando hay una razón de negocio para cancelar una factura. Debe tener un efecto contable, en sentido contrario a las factura que cancela. Esta cancelación se debe informar con un registro de alta. Y también tendrá su proprio número de factura.

Ahora bien, en el 4º de la lista arriba, pueden darse cualquiera de los dos casos. La diferencia realmente es si la factura emitida en 2 ha sido registrada formalmente en sistemas externos al S.I.F., o se ha quedado «estancada» dentro del propio SIF. Esto solo lo puede saber él que opera el S.I.F. Entonces las dos operativas deben ser aceptadas por el sistema Veri*Factu; y también deben ser contempladas en el sistema; entonces sí, es posible que, dependiendo de la operativa y visto el marco del reglamento de facturación, se pueden dar el caso de «rectificativas de recapitulativas».
Solo que no es el caso aquí (si sigo el ejemplo descrito). Y esto no lo puede determinar Hacienda.
En cualquier caso, no creo que haya error tuyo.
Entonces la advertencia, aunque entiendo la intención (advertir de la 2ª opción), me parece mal formulada para no decir un poco engañosa, al insinuar que la anulación en 4 no procede.
Creo que valdría la pena alzar el caso a los de Hacienda, a ver si pueden mejorar el mensaje.

Otra posibilidad sería de obligar a documentar un poco las razones para anular un registro (añadiendo a las especificaciones; un trabajo para Hacienda); si los casos contemplados son suficientemente estrechos, quedaría claro a los desarrolladores que los registros de anulación no sirven para cancelaciones de facturas, y no haría falta emitir ¡ninguna advertencia! Ahora bien, este es ¡mi opinión!

Gracias,les he remitido la pregunta con los pasos y que me digan si hay fallo donde está, supongo que habrá una respuesta clara. Ya os diré.

[afxe]

Empezado por ermendalenda

Gracias,les he remitido la pregunta con los pasos y que me digan si hay fallo donde está, supongo que habrá una respuesta clara. Ya os diré.

¿Dónde o quién te están respondiendo estas preguntas? ¿Hay abierto ya algún portal de dudas y aclaraciones?

[afxe]

Empezado por ermendalenda

Gracias,les he remitido la pregunta con los pasos y que me digan si hay fallo donde está, supongo que habrá una respuesta clara. Ya os diré.

(duplicado)

[afxe]

En el caso que está exponiendo Ermendalenda... creo que hay un error de concepto (o el error lo tengo yo... y me pondré el capirote de burro de la clase )

(a partir de ahora, entiéndase Ticket = Factura simplificada)

Creo que al SIF no hay que enviar las facturas recapitulativas tal y como se hace en el SII, sino que hay que enviar los tickets que agrupa dicha factura.

El tema de las facturas recapitulativas tenía entendido que era para agrupar un conjunto de tickets de manera que se generara un único movimiento contable/fiscal por dichas operaciones... por ejemplo, el lineal de caja de un supermercado... Cada lineal va generando tickets consecutivos con su serie (facturas simplificadas, a "cliente contado") y al final del día se genera una factura recapitulativa con el resumen de esos tickets (normalmente con una serie para las recapitulativas). Si un cliente solicita factura una vez que el ticket ha sido emitido, se genera un ticket en negativo (en la serie correspondiente) seguido de una factura normal, usualmente con otra serie diferente a la de los tickets y a la de las facturas recapitulativas. De manera que en el SII, un dato especial que sólo está en las recapitulativas es NumSerieFacturaEmisor y NumSerieFacturaEmisorResumenFin donde se indica el intervalo de facturación de los tickets, pero no cada ticket. En contabilidad sólo aparece una factura recapitulativa indicando el intervalo... pero en el libro de IVA no aparece nada de los tickets emitidos. En la estructura del SIF, en ningún sitio consta este intervalo, porque se supone que lo que estamos obligados a enviar es cada ticket individualmente, y no la factura a fin de día.

Si esto es correcto, una factura recapitulativa no puede tener rectificación... si uno de los tickets que contiene tiene un error, debo hacer un ticket en negativo y un ticket positivo que serán recapitulados en la facturación de ese día.

Espero no estar estar en una equivocación y provocaros un dolor de cabeza innecesario.

[ermendalenda]

Empezado por afxe

En el caso que está exponiendo Ermendalenda... creo que hay un error de concepto (o el error lo tengo yo... y me pondré el capirote de burro de la clase )

(a partir de ahora, entiéndase Ticket = Factura simplificada)

Creo que al SIF no hay que enviar las facturas recapitulativas tal y como se hace en el SII, sino que hay que enviar los tickets que agrupa dicha factura.

El tema de las facturas recapitulativas tenía entendido que era para agrupar un conjunto de tickets de manera que se generara un único movimiento contable/fiscal por dichas operaciones... por ejemplo, el lineal de caja de un supermercado... Cada lineal va generando tickets consecutivos con su serie (facturas simplificadas, a "cliente contado") y al final del día se genera una factura recapitulativa con el resumen de esos tickets (normalmente con una serie para las recapitulativas). Si un cliente solicita factura una vez que el ticket ha sido emitido, se genera un ticket en negativo (en la serie correspondiente) seguido de una factura normal, usualmente con otra serie diferente a la de los tickets y a la de las facturas recapitulativas. De manera que en el SII, un dato especial que sólo está en las recapitulativas es NumSerieFacturaEmisor y NumSerieFacturaEmisorResumenFin donde se indica el intervalo de facturación de los tickets, pero no cada ticket. En contabilidad sólo aparece una factura recapitulativa indicando el intervalo... pero en el libro de IVA no aparece nada de los tickets emitidos. En la estructura del SIF, en ningún sitio consta este intervalo, porque se supone que lo que estamos obligados a enviar es cada ticket individualmente, y no la factura a fin de día.

Si esto es correcto, una factura recapitulativa no puede tener rectificación... si uno de los tickets que contiene tiene un error, debo hacer un ticket en negativo y un ticket positivo que serán recapitulados en la facturación de ese día.

Espero no estar estar en una equivocación y provocaros un dolor de cabeza innecesario.

Hola. No te he entendido muy bien. Pero en el artículo 13 página 17 del reglamento de facturación de 2012 verás que la factura recapitulativa puede incluir cualquier tiqiet del mismo periodo. Por supuesto cuando se haga una recapitulativa hay que generar el verifactu y en caso dd ticketbai igual.
Saludos

[ermendalenda]

Empezado por afxe

En el caso que está exponiendo Ermendalenda... creo que hay un error de concepto (o el error lo tengo yo... y me pondré el capirote de burro de la clase )

(a partir de ahora, entiéndase Ticket = Factura simplificada)

Creo que al SIF no hay que enviar las facturas recapitulativas tal y como se hace en el SII, sino que hay que enviar los tickets que agrupa dicha factura.

El tema de las facturas recapitulativas tenía entendido que era para agrupar un conjunto de tickets de manera que se generara un único movimiento contable/fiscal por dichas operaciones... por ejemplo, el lineal de caja de un supermercado... Cada lineal va generando tickets consecutivos con su serie (facturas simplificadas, a "cliente contado") y al final del día se genera una factura recapitulativa con el resumen de esos tickets (normalmente con una serie para las recapitulativas). Si un cliente solicita factura una vez que el ticket ha sido emitido, se genera un ticket en negativo (en la serie correspondiente) seguido de una factura normal, usualmente con otra serie diferente a la de los tickets y a la de las facturas recapitulativas. De manera que en el SII, un dato especial que sólo está en las recapitulativas es NumSerieFacturaEmisor y NumSerieFacturaEmisorResumenFin donde se indica el intervalo de facturación de los tickets, pero no cada ticket. En contabilidad sólo aparece una factura recapitulativa indicando el intervalo... pero en el libro de IVA no aparece nada de los tickets emitidos. En la estructura del SIF, en ningún sitio consta este intervalo, porque se supone que lo que estamos obligados a enviar es cada ticket individualmente, y no la factura a fin de día.

Si esto es correcto, una factura recapitulativa no puede tener rectificación... si uno de los tickets que contiene tiene un error, debo hacer un ticket en negativo y un ticket positivo que serán recapitulados en la facturación de ese día.

Espero no estar estar en una equivocación y provocaros un dolor de cabeza innecesario.

Creo que eso de hacer una recapitulativa sin clientes no es demasiado valido., y eso de hacer una negativa y una positiva para hacer la factura del cliente es jugársela, sobre todo como cambié el periodo impositivo, ya que vos a hacer una rectificativa sin uno dd los conceptos aceptados, precios erróneos, tipo impositivo erróneo...

[antoine0]

Me ha costado un poco ponerme las ideas en su sitio, sobre todo por problema de vocabulario. Espero que el resultado siga legible.

Empezado por afxe

Creo que al SIF no hay que enviar las facturas recapitulativas tal y como se hace en el SII, sino que hay que enviar los tickets que agrupa dicha factura.

Sí. Y es un rollo para los que hasta la fecha usan tickets en papel pre-numerados, ya no se podrá usar, deberán informatizarse. €€€

El tema de las facturas recapitulativas tenía entendido que era para agrupar un conjunto de tickets

«Factura recapitulativa» es un nombre engañoso.
No es el único caso de aplicación.
El [artículo 13](https://www.boe.es/buscar/act.php?id...2012-14696#a13) del reglamento que describe las facturas recapitulativas es más general. Incluye por ejemplo el caso de una obra, dónde el constructor al final del mes te pasa una factura de un montón de cosas, que a menudo tienen poco en común. Es la práctica (de las empresas y/o de los programas) que usa esta figura de las recapitulativas para implementar el caso de agrupar los tickets para gestionarlo confortablemente en contabilidad.

De hecho, en el SII, la descripción de R4 es Asiento resumen de facturas; no habla de factura recapitulativa.

Si esto es correcto, una factura recapitulativa no puede tener rectificación

Si nos referimos al asiento resumen, no se puede rectificar como factura (las facturas recapitulativas del reglamento sí se pueden rectificar). El reglamento está claro sobre los casos de rectificación ([artículo 15](https://www.boe.es/buscar/act.php?id...2012-14696#a15)), y no me parece que se pudiera aplicar a esta «factura técnica».

si uno de los tickets que contiene tiene un error, debo hacer un ticket en negativo y un ticket positivo

Cierto (si así es tu manera de generar una rectificación). Se trata de rectificar la factura que esté mal. Al menos, el «ticket en negativo» tendrá la consideración de rectificativa, y serie distinta.

[...] que serán recapitulados en la facturación de ese día.

Del día de la rectificación. Y supongo que deberán estar en dos recapitulativas distintas, cada una en su propia serie. (Creo.)
Entonces, la recapitulativa «de los errores», realmente es también ¡una clase de rectificativa! (a [parte de] la o las recapitulativas de los tickets iniciales). Aunque en práctica no será registrado como tal.

En el SII me parece claro que han decidido no indagar en esta materia, y consideran que estas recapitulativas de tickets rectificados son asientos resumen (F4) igual que los demás.

Pero todo esto no tiene nada que ver con el ejemplo de Ermendalenda

Empezado por ermendalenda

1. Emito 1 factura simplificada.
2. Emito 1 factura recapitulativa de esa simplificada(con los datos del cliente)
3. Me doy cuenta, antes de darsela al cliente, que me he equivocado de cliente.
4. Anulo LA RECAPITULATIVA.
5. Vuelvo a emitir recapitulativa, con el siguiente número de serie de las recapitulativas, de la factura simplificada del paso 1.

(el énfasis es mío).
No se trata de una recapitulativa, al menos no es un asiento resumen que es lo consideras. Se trata de una sustitutiva, o canje como las llaman en el reglamento de facturación (último parágrafo del artículo 15.6, que explicita que no son rectificativas). En el SII tienen su proprio código, F3. Y creo que se pueden rectificar, claro que sí.