Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por ermendalenda

En el camppnde encadenamiento de cada factura enviada tienes que poner efectivamente el número de la anterior, pero las 2 anulaciones 3 y 4 carecen de número de factura, los números 3 y 4 son num3r9s correlativos que has puesto por seguir un orden, pero no es el número que piden. El encadenamiento tampoco es el número de factura que se anula eso es otro campo, en principio veo esos 2 errores de blockchain, el de las anulaciones y el de las repeticiones de envíos. Esperemos que lo aclaren

Efectivamente, los números de registros del 1 al 6 no son números de facturas; estos son, respectivamente, 22012, 22013, 22012, 22013, 22014 y 22015; las referencias a anteriores serían estos números, junto con el NIF del emisor, sus fechas, aquí 14/7, y sus respectivas huellas.
Resulta entonces en mi ejemplo que el registro 4 lleva el mismo número de factura que el registro 2, también mismo emisor, y también misma fecha de emisión de la factura; pero no la misma huella.
Realmente para realizar el encadenamiento, con solo la huella es suficiente (asumiendo que SHA256 es una función de hash perfecta). Las demás informaciones sobran, o mejor dicho son redundantes (y sabemos que estas redundancias ayudan y mucho al rendimiento).

Si resulta confuso, me parece hasta lógico, dado que en un diseño inicial, no había encadenamiento de los registros de anulación, esto se ha añadido en un segundo tiempo. No sé por qué, pero puedo ver dos razones:

• hay una posibilidad de fraude anulando registros, por ejemplo en relación con problemas con el sistema de llevar estos registros a Hacienda
• en practicas habituales, los registros de anulación serían mezclados con los registros de alta (por ejemplo tal como se ve si se mira empezando desde la contabilidad); sería por tanto el resultado del retorno de los editores de software

[keys]

Empezado por antoine0

Efectivamente, los números de registros del 1 al 6 no son números de facturas; estos son, respectivamente, 22012, 22013, 22012, 22013, 22014 y 22015; las referencias a anteriores serían estos números, junto con el NIF del emisor, sus fechas, aquí 14/7, y sus respectivas huellas.
Resulta entonces en mi ejemplo que el registro 4 lleva el mismo número de factura que el registro 2, también mismo emisor, y también misma fecha de emisión de la factura; pero no la misma huella.
Realmente para realizar el encadenamiento, con solo la huella es suficiente (asumiendo que SHA256 es una función de hash perfecta). Las demás informaciones sobran, o mejor dicho son redundantes (y sabemos que estas redundancias ayudan y mucho al rendimiento).

Si resulta confuso, me parece hasta lógico, dado que en un diseño inicial, no había encadenamiento de los registros de anulación, esto se ha añadido en un segundo tiempo. No sé por qué, pero puedo ver dos razones:

• hay una posibilidad de fraude anulando registros, por ejemplo en relación con problemas con el sistema de llevar estos registros a Hacienda
• en practicas habituales, los registros de anulación serían mezclados con los registros de alta (por ejemplo tal como se ve si se mira empezando desde la contabilidad); sería por tanto el resultado del retorno de los editores de software

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.

Factura 1
Factura 2 -->Factura anterior es la 1
Factura 3 -->Factura anterior es la 2
Anulo Factura 2 --> Sin encadenamiento Pongo los datos de la factura 2
Factura 4 -->Factura anterior es la 3

Sino es una locura. El tiempo lo dirá

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

[antoine0]

Empezado por keys

Yo no veo que las facturas de anulación tengan encadenamiento.

Presentación del 21/6 (qué has anunciado, gracias por ello), página 12/15

Registro de facturación de anulación (artículo 11.2):
> Se incluye el encadenamiento de huellas sobre el registro de facturación anterior, sea este de alta o de anulación.

Son los registros, sigan de alta o de anulación, que se encadenan.
De hecho, en mi experiencia del SII, he llegado (a mi gran sorpresa) a la conclusión que para una misma factura inicial en mi sistema, podía tener más de 2 registros en el S.I.I.

1. el primero es siempre una alta, tipo A0 en S.I.I.
2. aquí puedo tener que hacer una corrección de forma, con un registro tipo A1
3. luego digamos que hay que dar el registro de baja, por ejemplo porqué hay equivocación en la contrapartida: nuevo registro, esta vez de anulación («baja» en S.I.I.)
4. luego doy de alta nuevamente la factura, con la contrapartida corregida; otra vez un registro de tipo A1

No hay equivalente a los registros de tipo A1 en el nuevo reglamento; pero tengo la sensación que los «registros de alta» pueden ser más de uno para un determinado número de factura (dentro de una serie), con la condición que el número de registros de anulación (para el mismo número de factura) siga el mismo o uno menos; dicho de otra forma, no he visto aún que no se pudiera resucitar una factura después de ser anulada; o siga, que se pudiera efectivamente modificar el contenido de una factura (remplazando UPDATE por DELETE más INSERT).
Y estoy leyendo el preámbulo (no normativo) del proyecto de reglamento de febrero dice, página 12:

Cualquier necesidad de rectificación o anulación de los datos registrados deberá ser realizada mediante al menos un registro de facturación adicional posterior, de forma que se conserven inalterables los datos originalmente registrados

Pero ahora estoy seguramente estirando demasiado el hilo de las suposiciones.

Y sí, choca con mis ideas predeterminadas sobre cómo construir una facturación; pero de la misma manera choca el hecho que el respecto a ciertas condiciones de forma (importes, determinación de la contrapartida) preexiste a la obtención de un nuevo número de factura: yo siempre he programado la reservación del número de factura antes de validar el detalle de los importes; y esto lo tengo que cambiar sí o sí...

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

Empezado por antoine0

Presentación del 21/6 (qué has anunciado, gracias por ello), página 12/15

El problema es que ellos mismos se están liando con los términos y las cosas que explican (y nos están liando a nosotros).
(1) En este texto habla de "Registro de facturación anterior" y eso sí puede ser un alta o anulación. Entiendo que registro de facturación es la información que enviamos. Ese "registro" sí se puede encadenar con el anterior enviado.

(2) Pero en el Excel de "AnexoAnulacion_VERIFACTU(1).xlsx" habla de:
HuellaFacturaAnterior => Huella de la factura anterior
Y está claro que una anulación NO ES una factura.

Con lo que hay en un sitio se entiende una cosa y con lo que hay en el otro, otra.

[ermendalenda]

Si esto es verdad que se les haya pasado me da repelús la de bugs que pueden tener en el backend con los controles y eso no dudéis que somos los betaprobadores

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

Empezado por ermendalenda

... y eso no dudéis que somos los betaprobadores

Eso los que hemos hecho TicketBAI ya lo tenemos asumido (que lo vamos a ser...)
Y además "sin cobrar"... (de hacienda me refiero)

[antoine0]

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

Pero en el Excel de "AnexoAnulacion_VERIFACTU(1).xlsx" habla de:
HuellaFacturaAnterior => Huella de la factura anterior
Y está claro que una anulación NO ES una factura.

Tienes razón, a todas luces es incorrecto.
Creo que esto es un defecto de forma del Excel. Estamos en 0.1, hay aún un montón de errores para subsanar. Pero está claro que ésta molesta más que otras.

[sglorka]

Buenas tardes.
Me gustaría presentar una situación para ver si hay consenso en la resolución de la misma. Si se anula una factura emitida mediante la emisión de una factura ordinaria en negativo (nota de crédito), esto está permitido por la agencia tributaria en ciertos casos, ¿ Deberíamos crear un registro de anulación de la factura emitida además de crear el registro de la nueva factura negativa?
¿ Podríamos estar duplicando dicha anulación ?
Mi pensamiento es que no informamos el registro de anulación y si informamos el registro de de factura de abono.

Esto también puede ocurrir en una factura emitida con tipos impositivos erróneos. El proceso es emitir una nota de crédito (factura ordinaria en negativo) y emitir una factura rectificativa x sustitución corrigiendo la primera factura. En este caso informaríamos de ambos registros pero no haríamos mención a ningún registro de anulación

Espero haber sido claro en mi exposición.
Saludos

[ermendalenda]

Empezado por sglorka

Buenas tardes.
Me gustaría presentar una situación para ver si hay consenso en la resolución de la misma. Si se anula una factura emitida mediante la emisión de una factura ordinaria en negativo (nota de crédito), esto está permitido por la agencia tributaria en ciertos casos, ¿ Deberíamos crear un registro de anulación de la factura emitida además de crear el registro de la nueva factura negativa?
¿ Podríamos estar duplicando dicha anulación ?
Mi pensamiento es que no informamos el registro de anulación y si informamos el registro de de factura de abono.

Esto también puede ocurrir en una factura emitida con tipos impositivos erróneos. El proceso es emitir una nota de crédito (factura ordinaria en negativo) y emitir una factura rectificativa x sustitución corrigiendo la primera factura. En este caso informaríamos de ambos registros pero no haríamos mención a ningún registro de anulación

Espero haber sido claro en mi exposición.
Saludos

Vaya lio.
No entiendo muy bien los procedimientos si puedes poner un ejemplo...
Para mi una Nota de crédito es prácticamente lo mismo que una rectifcatiiva, la diferencia es que la nota de crédito siempre son negativos y tiene que hacerse dentro del periodo impositivo y la rectif8cativa se puede hacer en positivo o negativo dependiendo de lo que quieras arreglar y ademas puedes hacerla despues de declarar el iva de la factura rectificada, .en ambos casow hay que indicar sobre qué factura vas a rectificar pero en el caso ee la rectificativa debes usar una serie diferente a la de la factura. El hecho de uses ambas a la vez para hacer una rectificacion no lo entiendo. Que no digo que no sea posible, pero no he entendido en qué escenario puede ocurrir.
En el caso de Verifactu no he visto ningún campo para las notas de créditos, lo mismo es bu3na idea hacerlo todo con rectificativas

[sglorka]

Empezado por ermendalenda

Vaya lio.
No entiendo muy bien los procedimientos si puedes poner un ejemplo...
Para mi una Nota de crédito es prácticamente lo mismo que una rectifcatiiva, la diferencia es que la nota de crédito siempre son negativos y tiene que hacerse dentro del periodo impositivo y la rectif8cativa se puede hacer en positivo o negativo dependiendo de lo que quieras arreglar y ademas puedes hacerla despues de declarar el iva de la factura rectificada, .en ambos casos hay que indicar sobre qué factura vas a rectificar y en ambos casos debes usar una serie diferente a la de la factura. El hecho de uses ambas a la vez para hacer una rectificacion no lo entiendo. Que no digo que no sea posible, pero no he entendido en qué escenario puede ocurrir.

Me explico.
La nota de crédito es lo mismo que una factura ordinaria, lleva la misma serie y su numeración sigue la de la siguiente factura emitida. Como bien dices, se usa para anular una factura emitida en la que todavía no se ha liquidado el iva, pero cuando dicha operación que anula se refiere a una factura con el destinatario erróneo por ejemplo o porque la venta no llegó a su finalización o porque te rechazaron los productos por algún motivo. Solo en estos casos se permite anular una factura emitida mediante una nota de crédito (factura ordinaria en negativo con la mención de Nota de Crédito). Puedes ver esto en la consulta vinculante de la agencia tributaria número V0611-11. No pongo el enlace porque parece que no lo tengo permitido

Sitos en este caso concreto, tendríamos que registrar la emisión de dicha factura de crédito (que anula la factura inicial), pero mi pregunta es : ¿ Además hay que informar con un registro, la anulación la factura inicial ?

Si la agencia tributaria utiliza los registros que vamos a enviar como herramienta para la declaración del IVA (como ocurre en el SII) encontraría un registro de anulación y un registro de nota de crédito en negativo contra una misma factura.

[ermendalenda]

Empezado por sglorka

Me explico.
La nota de crédito es lo mismo que una factura ordinaria, lleva la misma serie y su numeración sigue la de la siguiente factura emitida. Como bien dices, se usa para anular una factura emitida en la que todavía no se ha liquidado el iva, pero cuando dicha operación que anula se refiere a una factura con el destinatario erróneo por ejemplo o porque la venta no llegó a su finalización o porque te rechazaron los productos por algún motivo. Solo en estos casos se permite anular una factura emitida mediante una nota de crédito (factura ordinaria en negativo con la mención de Nota de Crédito). Puedes ver esto en la consulta vinculante de la agencia tributaria número V0611-11. No pongo el enlace porque parece que no lo tengo permitido

Sitos en este caso concreto, tendríamos que registrar la emisión de dicha factura de crédito (que anula la factura inicial), pero mi pregunta es : ¿ Además hay que informar con un registro, la anulación la factura inicial ?

Si la agencia tributaria utiliza los registros que vamos a enviar como herramienta para la declaración del IVA (como ocurre en el SII) encontraría un registro de anulación y un registro de nota de crédito en negativo contra una misma factura.

A ver, como te he comentado, en verifactuz de momento en la versión inicial no se ven notas de créditos, otra cosa es que permitan hacer facturas negativas en la misma serie, que seguramente sí, pero quedaría informar sobre qué factura se anula...mmm..lo que eata claro es que no tienes que informar de la rectificacion y de la anulacion], la anulación ya se puede hacer directamente con el criterio que comentas y no harua falta enviar notas de créditos, por tanto, si necesitas por contabilidad, tener el registro en negativo podrías crear una serie distinta en la que puedas meter esos negativos, o sea un documento interno.
No se si me explico, o sea, no debes enviar duplicidades, anular y rectificacion o nota de crédito.
.

[antoine0]

Empezado por sglorka

Si se anula una factura emitida mediante la emisión de una factura ordinaria en negativo (nota de crédito), esto está permitido por la agencia tributaria en ciertos casos,
¿ Deberíamos crear un registro de anulación de la factura emitida además de crear el registro de la nueva factura negativa?

Deber creo que no: no creo que siga correcto para el caso de una nota de crédito real, es decir emitida por un motivo operacional (devolución, error de cliente) varios días antes, reportada, supuestamente en circulación etc.
Otra pregunta es si ¿Podríamos?
Ahora bien, es difícil ver la diferencia con una nota de crédito «interna» emitida para corregir un error de entrada, dónde las dos facturas se quedan en casa, nadie más que tú, tu contable y tu controlador fiscal se enteren (y esas sí que se pueden anular). Pero en tal caso, hay que anular la primera factura, y también anular la nota de crédito. De no hacerlo, la balance contable no saldrá equilibrada.

¿ Podríamos estar duplicando dicha anulación ?

Duplicar una anulación no parece posible: está previsto un campo de respuesta en el servicio web que se llama CSVRegistroDuplicado, cuya descripción es «Código seguro de verificación del registro ya existente en el sistema. Solo se suministra este campo en dos casos:
En la respuesta de la operación de alta: Si el registro enviado es rechazado por estar duplicado.
En la respuesta de la operación de baja: Si el registro enviado es rechazado porque ya está dado de baja.»
Yo diría que no se esperan duplicaciones...

Mi pensamiento es que no informamos el registro de anulación y si informamos el registro de de factura de abono.

Contablemente y a efecto de IVA las dos facturas se compensan; pero para eso, hace falta que las dos sigan en el mismo estado; no puede haber una marcada «anulada» y la otra marcada «válida». Por tanto, si informas del registro de la factura de abono / nota de crédito sin informar de su inmediata anulación, no hay que anular la factura inicial.

[sglorka]

Gracias por tu comentario.

Entonces podemos estar en un escenario en que no sería necesario anular facturas. Si tenemos un error en los tipos impositivos, fecha de expedición, numeración, etc. podríamos emitir una factura ordinaria en negativo y posteriormente una rectificativa x sustitución que corrige la primera, como indica la consulta vinculante V0902-22 que podemos ver en Iberley fechada en este año. Este procedimiento es más natural ya que entregar un solo documento rectificativo al cliente final podría generar errores al contabilizar dos veces las misma operación, en cambio, con este procedimiento enviamos ambas facturas (la factura de abono y la rectificativa).
En este escenario, entiendo que no debemos informar el registro de anulación, mantenemos la factura inicial como emitida y enviamos dos registros, la factura que abona y la rectificativa.
¿ Podemos estar de acuerdo en este aspecto ?
Saludos

[ermendalenda]

Empezado por sglorka

Gracias por tu comentario.

Entonces podemos estar en un escenario en que no sería necesario anular facturas. Si tenemos un error en los tipos impositivos, fecha de expedición, numeración, etc. podríamos emitir una factura ordinaria en negativo y posteriormente una rectificativa x sustitución que corrige la primera, como indica la consulta vinculante V0902-22 que podemos ver en Iberley fechada en este año. Este procedimiento es más natural ya que entregar un solo documento rectificativo al cliente final podría generar errores al contabilizar dos veces las misma operación, en cambio, con este procedimiento enviamos ambas facturas (la factura de abono y la rectificativa).
En este escenario, entiendo que no debemos informar el registro de anulación, mantenemos la factura inicial como emitida y enviamos dos registros, la factura que abona y la rectificativa.
¿ Podemos estar de acuerdo en este aspecto ?
Saludos

Esto es un poco lioso y lo mejor es que hagas una consulta no vinculante a la aeatbpara que te contesten rápido, yo uso pocas veces las anulaciones y la parte de devoluciones anterior a 2013 se permitían las facturas de abono, pero tengo un gran lío con las notas de crédito en ese aspecto, te puedo confirnar que Las facturas de abono hacían referencia a los documentos que se emitían como consecuencia de una devolución. A partir del 1 de enero del 2013, cuando entra en vigor el nuevo reglamento de facturación, este es reemplazado por la factura rectificativa negativa.