Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[espinete]

Empezado por adolphsys

- La "Ley Antifraude" (VeriFactu) es el TicketBAI de la AEAT. Si ya tenemos la aplicación hecha para TicketBAI, cuando se publique el reglamento VeriFactu se desarrolla en la misma línea como "cuarta hacienda foral", o quinta si contamos con Navarra, que al final no se sabe si irá por TicketBAI o VeriFactu, esta es otra...

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

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

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