Demo con código Verifactu.dll para (delphi 7)

[Matorral]

Buenos dias compañeros. Feliz Verifactu¡¡¡

Tengo una duda (bueno, tengo diez mil dudas pero no quiero abusar).

Mi programa de hostelería emite facturas simplificadas y envía RF por medio del componente verifactuD7.

Cuando quiero rectificar una simplificada hago lo siguiente... (esta es mi duda)

Emito una factura en negativo (importe total en negativo) indicando factura y fecha rectificadas y la envío. El componente la "clasifica" automáticamente como R5 (rectificativas de fras. simplificadas por diferencias).
y luego emito la nueva factura y envío (F2).

Esto es correcto (de cara a Hacienda, claro)?


Yo aun sigo en preproducción, no cerré versión aún.

Gracias¡¡¡¡

[starlet]

Buenas:

Ya tengo el componente bien integrado en mi aplicación y funciona todo según lo esperado excepto las subsanaciones que o no lo entiendo bien o hay algún error.

- Mando una factura con el DNI mal a propósito para que me la rechace la AEAT, cosa que obviamente hace.

- Mando una subsanación con el mismo número de factura, DNI corregido y mismos datos y marco los campos Rechazoprevio y Subsanación a True.

- Me contesta que "No existe el registro de facturación"

- Si la envío sin Rechazoprevio y Subsanación, y con los datos correctos la acepta.

Contestación de la AEAT a este caso:

En el caso de que el registro original sea rechazado, esto implica que no ha sido aceptado en el sistema. Por tanto, aquí es cuando debemos emplear el valor <RechazoPrevio>=X (puede ver más detalles en el documento de diseño de registro, en su hoja "A)Cuadro Operativa Alta").

Por ejemplo, en el caso que nos mencionaba, en el que un registro de facturación ha sido rechazado. Aquí corresponde revisar si el Reglamento de Facturación estipula la emisión de una factura rectificativa y generar su registro de alta inicial. En cambio, si fuese un dato que solo aparece en los registros de facturación, la corrección del error pasaría por generar un registro de "Alta por rechazo" con los valores <Subsanacion>=S y <RechazoPrevio>=X. Puede ver más información en la pregunta 17 del documento de FAQs para desarrolladores.


Qué estoy haciendo mal???.

Saludos,

[mqm]

Si no estamos usando capicom, podemos quitarlo completamente del codigo fuente y eleminar toda referencia al mismo?

[Matorral]

Empezado por mqm

Si no estamos usando capicom, podemos quitarlo completamente del codigo fuente y eleminar toda referencia al mismo?

A mí me está funcionando todo exactamente igual después de eliminarlo (tal y como indicó Seccion_31 en un mensaje anterior).

[Matorral]

Empezado por starlet

Buenas:

Ya tengo el componente bien integrado en mi aplicación y funciona todo según lo esperado excepto las subsanaciones que o no lo entiendo bien o hay algún error.

- Mando una factura con el DNI mal a propósito para que me la rechace la AEAT, cosa que obviamente hace.

- Mando una subsanación con el mismo número de factura, DNI corregido y mismos datos y marco los campos Rechazoprevio y Subsanación a True.

- Me contesta que "No existe el registro de facturación"

- Si la envío sin Rechazoprevio y Subsanación, y con los datos correctos la acepta.

Contestación de la AEAT a este caso:

En el caso de que el registro original sea rechazado, esto implica que no ha sido aceptado en el sistema. Por tanto, aquí es cuando debemos emplear el valor <RechazoPrevio>=X (puede ver más detalles en el documento de diseño de registro, en su hoja "A)Cuadro Operativa Alta").

Por ejemplo, en el caso que nos mencionaba, en el que un registro de facturación ha sido rechazado. Aquí corresponde revisar si el Reglamento de Facturación estipula la emisión de una factura rectificativa y generar su registro de alta inicial. En cambio, si fuese un dato que solo aparece en los registros de facturación, la corrección del error pasaría por generar un registro de "Alta por rechazo" con los valores <Subsanacion>=S y <RechazoPrevio>=X. Puede ver más información en la pregunta 17 del documento de FAQs para desarrolladores.


Qué estoy haciendo mal???.

Saludos,

Buenas Starlet¡¡

Acabo de hacer algo parecido...
Envie una simplificada con importe negativo para provocar el rechazo. (el componente lo marca como R5 y al no especificar la factura a la que rectifica lo rechaza).
Luego corregi la factura y le puse importe positivo y la volvi a enviar con Subsanacion='S' y Rechazoprevio='S' y la volvio a rechazar.

Modifiqué el xml : puse Subsanacion='S' y Rechazoprevio='X' y la envié desde la página de comprobación de XML y la tragó.

(desde esta página ....

https://prewww1.aeat.es/static_files...ws/opciones.js

El problema es que el componente no acepta el valor 'X' en la propiedad rechazoPrevio (es de tipo boolean).

Espero que te ayude.

[Matorral]

Hola starlet¡¡

lo resuelves poniendo...

Código Delphi [-]
  subsanacion:=True;
  rechazoprevioNOExiste:=True;

al poner rechazoprevioNOExiste a True, la unit uVerifactuFuncs le asigna el valor 'X' a rechazoprevio en el XML.

Código Delphi [-]

    if facturaRegistro.subsanacion then
        Factura.RegistroAlta.Subsanacion:=SubsanacionType.S;

    if facturaRegistro.rechazoPrevioExiste then
        Factura.RegistroAlta.RechazoPrevio:=RechazoPrevioType.S;

    if facturaRegistro.rechazoPrevioNoExiste then
        Factura.RegistroAlta.RechazoPrevio:=RechazoPrevioType.X;

[DarkDudae]

La AEAT no acepta facturas cuyo NIF no sea correcto, por eso no les consta en sus bases de datos como subidas.
Lo que nosotros hacemos, es utilizar la característica del componente de comprobar NIF, así no enviamos nunca nada cuyo NIF no haya sido comprobado previamente.

[starlet]

Hola:

Si, eso hago yo y creo que es lo correcto. Lo que tenemos que tener en cuenta es que a veces, ese servicio puede no estar disponible. Yo verifico las letras antes de hacer la consulta a la AEAT, además de.

Lo que quería era probar subsanaciones, y para subsanar hice que me rechazara por ese motivo.

Y en las subsanaciones no sabía como poner X en rechazoprevio y con la explicación de Matorral ya lo veo.

Muchas gracias a todos.

[seccion_31]

Viendo los posts anteriores, me quedo gratamente sorprendido.

Solo me queda desearos a todos un feliz verano !!

[Matorral]

Empezado por seccion_31

Viendo los posts anteriores, me quedo gratamente sorprendido.

Solo me queda desearos a todos un feliz verano !!

Jajaja, tu si que te mereces un Feliz verano Crack¡¡¡

Yo este año estoy castigado sin Verano.

[DarkDudae]

Buenos días compañeros:

He estado haciendo pruebas modificando el componente para "aceptar" un tipo de factura de forma forzada y no automátca (F1, F2, F3, R1, R2, R3, R4, R5). Es una propiedad nueva de tipo string[2] del TRegistroFactura llamada "forzarTipo".

El motivo básicamente era hacer pruebas y ver restricciones de la propia AEAT.

Os comento mis observaciones:

-El componente ahora mismo en todas las facturas simples, para emitir rectificativas usa el tipo R5, lo cual es correcto. Todas las rectificativas son en Importe (no sustitutivas), así que creo que no sería necesario abonar un ticket completo y crear uno nuevo, sino simplemente meter en el ticket y/o factura nueva la línea o líneas eliminadas de la factura que se rectifica. Hasta ahí todo bien. El problema es que es bastante habitual (sobre todo con tickets) que un cliente te diga: "me he equivocado de leche, yo la quería desnatada y la he cogido entera". Y entonces hagas el ticket recfificativo con la leche entera en negativo y luego la línea en positivo de la leche desnatada, que resulta ser más cara que la leche entera. Así que el ticket "rectificativo" es positivo, no negativo. No obstante, el componente decide internamente mediante el importe si lo cataloga como una F2 o como una R5.

De ahí que con esta nueva propiedad, podamos "forzar" la R5 en estos casos (enviando el bloque con la factura rectificada también). Además, confirmo que la AEAT la acepta en los envíos sin problema.

Otro caso es el tema de las facturas simples con cliente identificado. Hacienda las distingue perfectamente de las facturas ordinarias. Por ejemplo en las facturas simples la dirección del cliente no es necesaria que conste en la misma, pero no obstante, es válida (siempre que esté el NIF y el nombre) para que el cliente pueda desgravarse el gasto. Así que intenté enviar una factura como F2 con Destinatario mediante mi modificación del componente (Forzando una F2 en vez de una F1), pero como dato, Hacienda no permite que incorporemos el bloque "Destinatario" para F2 y R5. Así que en estos casos, aunque nuestro software identifique al cliente en el ticket, la factura simple se enviaría sin datos del cliente.

Sigo haciendo pruebas e incorporando estas restricciones a mi modificación. Por supuesto, estas modificaciones en el componente, si lo estima oportuno seccion_31, estarán disponibles para todos si lo ve necesario.

Un saludo y feliz agosto (yo soy también de los que les toca pringar este mes)

[Matorral]

Buenos dias¡¡
Da gusto ver que bien se lo pasa la gente los Domingos¡¡
(yo tambien estaba currando).

Empezado por DarkDudae

Buenos días compañeros:

He estado haciendo pruebas modificando el componente para "aceptar" un tipo de factura de forma forzada y no automátca (F1, F2, F3, R1, R2, R3, R4, R5). Es una propiedad nueva de tipo string[2] del TRegistroFactura llamada "forzarTipo".

El motivo básicamente era hacer pruebas y ver restricciones de la propia AEAT.

Os comento mis observaciones:

-El componente ahora mismo en todas las facturas simples, para emitir rectificativas usa el tipo R5, lo cual es correcto. Todas las rectificativas son en Importe (no sustitutivas), así que creo que no sería necesario abonar un ticket completo y crear uno nuevo, sino simplemente meter en el ticket y/o factura nueva la línea o líneas eliminadas de la factura que se rectifica. Hasta ahí todo bien. El problema es que es bastante habitual (sobre todo con tickets) que un cliente te diga: "me he equivocado de leche, yo la quería desnatada y la he cogido entera". Y entonces hagas el ticket recfificativo con la leche entera en negativo y luego la línea en positivo de la leche desnatada, que resulta ser más cara que la leche entera. Así que el ticket "rectificativo" es positivo, no negativo. No obstante, el componente decide internamente mediante el importe si lo cataloga como una F2 o como una R5.

De ahí que con esta nueva propiedad, podamos "forzar" la R5 en estos casos (enviando el bloque con la factura rectificada también). Además, confirmo que la AEAT la acepta en los envíos sin problema.

Ayer estaba intentando hacer algo parecido a lo de "forzarTipo" (yo le habia llamado "tipoFactura"), porque para rectificar una simplificada hago un abono total y luego hago la "buena". El problema es que el componente me transformaba en R5 el abono (por ser negativa) y la "buena" me la transformaba en F2.
Lo que intento hacer es el abono total como F2 y la "buena" como R5 (identificando la factura original).

Creo que en lugar de "forzar" el tipo de factura con la propiedad "forzarTipo" esto se solucionaría cambiando los

Código Delphi [-]
if facturaRegistro.total<0

por

Código Delphi [-]
if facturaRegistro.facturaRectificada<>''

en uVerifactuFuncs.pas, porque en mi caso siempre identifico la factura rectificada (en la factura rectificativa "la buena")

No se como lo ves, o si se ajusta a lo que tu quieres. (si entendiste el ladrillo que acabo de soltar, jaja).

Otro caso es el tema de las facturas simples con cliente identificado. Hacienda las distingue perfectamente de las facturas ordinarias. Por ejemplo en las facturas simples la dirección del cliente no es necesaria que conste en la misma, pero no obstante, es válida (siempre que esté el NIF y el nombre) para que el cliente pueda desgravarse el gasto. Así que intenté enviar una factura como F2 con Destinatario mediante mi modificación del componente (Forzando una F2 en vez de una F1), pero como dato, Hacienda no permite que incorporemos el bloque "Destinatario" para F2 y R5. Así que en estos casos, aunque nuestro software identifique al cliente en el ticket, la factura simple se enviaría sin datos del cliente.

Yo en este caso "marcaré" las simplificadas con el código del cliente (sin guardar el nif ni el nombre), para luego hacer una completa al final de mes (en principio F1, porque con las F3 solo te deja canjear una simplificada), anulando las simplificadas incluidas en la F1. Bueno, esto es una paja mental que tengo ahora mismo, porque aun no lo tengo hecho, pero mi idea es esa.

Sigo haciendo pruebas e incorporando estas restricciones a mi modificación. Por supuesto, estas modificaciones en el componente, si lo estima oportuno seccion_31, estarán disponibles para todos si lo ve necesario.

Pues entonces me espero, para no tener que recular mis modificaciones en uVerifactuFuncs, jaja.

Un saludo y feliz agosto (yo soy también de los que les toca pringar este mes)

Igualmente a todos¡¡

[DarkDudae]

Lo que comentas de usar:

Código Delphi [-]
if facturaRegistro.facturaRectificada<>''

Es perfectamente válido. Piensa que yo con la propiedad de forzarTipo lo que busco más bien es "buscarle las cosquillas" a lo que acepta o no la AEAT.

Nosotros tenemos muchos clientes a los que identificamos en tickets que van haciendo puntos que les canjean descuentos y demás, a pesar de que luego a final de mes no se les genera factura ordinaria. A ese respecto, esa sería otra de las futuras mejoras del componente, que en las F3 permitan un array de facturas sustituidas, y no solo una.

De todas formas ten cuidado con eso de generar un abono de un ticket completo para emitir el "correcto". La AEAT puede pensar que lo que estás haciendo es una baja de una factura por error total (cosa que permite el sistema bajo ciertos casos). Las rectificaciones por importe (que son las que soporta el componente a día de hoy) no están ideadas para este tipo de operaciones, sino para correcciones puntuales a algunos conceptos de la factura. Lo que estás haciendo sería más bien una factura sustitutiva, que tiene connotaciones totalmente distintas.

Te comento lo que hacemos nosotros por si te "cuadra" con la lógica de tu sistema:

Cuando le damos a Rectificar/Abonar factura, aparecen las líneas de la misma con un checkbox para seleccionar cual o cuales líneas quieres abonar. Eso genera una nueva ventana con esas líneas en negativo precargadas. Luego el usuario puede añadir nuevas líneas o modificar cantidades o lo que sea (como si tuviese un ticket/factura comenzado). Eso va a generar una factura rectificativa real de la original con el importe de la diferencia y los conceptos de la diferencia.

Esto hace que a nivel contable, todo cuadre tanto para tu propio sistema informático como para la AEAT.

[Matorral]

Empezado por DarkDudae

Lo que comentas de usar:

Código Delphi [-]
if facturaRegistro.facturaRectificada<>''

Es perfectamente válido. Piensa que yo con la propiedad de forzarTipo lo que busco más bien es "buscarle las cosquillas" a lo que acepta o no la AEAT.

Nosotros tenemos muchos clientes a los que identificamos en tickets que van haciendo puntos que les canjean descuentos y demás, a pesar de que luego a final de mes no se les genera factura ordinaria. A ese respecto, esa sería otra de las futuras mejoras del componente, que en las F3 permitan un array de facturas sustituidas, y no solo una.

De todas formas ten cuidado con eso de generar un abono de un ticket completo para emitir el "correcto". La AEAT puede pensar que lo que estás haciendo es una baja de una factura por error total (cosa que permite el sistema bajo ciertos casos). Las rectificaciones por importe (que son las que soporta el componente a día de hoy) no están ideadas para este tipo de operaciones, sino para correcciones puntuales a algunos conceptos de la factura. Lo que estás haciendo sería más bien una factura sustitutiva, que tiene connotaciones totalmente distintas.

Te comento lo que hacemos nosotros por si te "cuadra" con la lógica de tu sistema:

Cuando le damos a Rectificar/Abonar factura, aparecen las líneas de la misma con un checkbox para seleccionar cual o cuales líneas quieres abonar. Eso genera una nueva ventana con esas líneas en negativo precargadas. Luego el usuario puede añadir nuevas líneas o modificar cantidades o lo que sea (como si tuviese un ticket/factura comenzado). Eso va a generar una factura rectificativa real de la original con el importe de la diferencia y los conceptos de la diferencia.

Esto hace que a nivel contable, todo cuadre tanto para tu propio sistema informático como para la AEAT.

Pues me acabas de aclarar algo que tenía yo muy enrevesado¡¡¡¡¡

Me pongo a ello.

Un millón de gracias¡¡¡

[seccion_31]

hola !

parece que no nos vamos de veraneo... y estamos hackeando el componente.

La filosofía del componente, era cubrir los casos comunes de la forma mas simple.

Algunas cosas de las que habéis hablado, se pueden solucionar fácil, de echo las facturas sustitutivas iva a ser un array, pero los arrays deben ser de longitudes fijas. ¿de cuantos elementos estaríamos hablando?

por otro lado, crear una R4, R5 con importe positivo creo que se podría hacer de otra forma, por ejemplo actuando sobre: facturaRegistro.facturaRectificada y no creando otra estructura nueva, es decir, automatizamos R5,R4 con importe negativo, o bien mediante el campo facturaRectificada

El objetivo de este comentario es tratar de mantener la simplicidad del componente, queda claro para todos que si rellenamos facturaRegistro.facturaRectificada tenemos una rectificativa. Y asi no solo nos limitariamos por importe negativo.

Son ideas, y creo que deberiamos mantener el componente sin ramales, porque perderemos seguridad.

Saludos !

Y feliz verano. Estoy en mi correo disponible, para ajustar esto.

Tambien visto lo visto habria que pensar en crear documentacion....

[ramherfer]

Me está surgiendo el siguiente problema, y ya no se si solo lo tengo solo yo. Tengo la versión 4.6 del componente.

Tengo la siguiente secuencia de facturas (encadenamientos verificados y correctos en el SIF):

A FR250252 01/08/25 FECHA OP: 01/08/25 Correcto B00000000 02 ES VENTA DE MERCADERIAS 469,42 98,58 568,00 A-5Y3B39LZD7UJBB
A FR250251 01/08/25 FECHA OP: 15/07/25 Correcto P7777777H 02 ES VENTA DE MERCADERIAS Y PRESTACION DE SERVICIOS 1519,80 319,16 1.838,96 A-AXZWAGYR2MBNXX
A FR250250 28/07/25 FECHA OP: 28/07/25 Correcto 19000000V 02 ES VENTA POR PRESTACION DE SERVICIOS 157,19 33,01 190,20 A-DHWF8UZHAY3KTT
A FR250249 28/07/25 FECHA OP: 28/07/25 Correcto.......

En las consultas la factura FR250251 no aparece ni matandome, ni en el periodo 07 ni en el periodo 08, la única diferencia con las otras es que la fecha de operación es la del ultimo albarán que se genero en el mes 07 y puesto como fecha operación en la factura generada el 01/08/2025 con todos los albaranes del mes anterior del cliente. Cotejo la FR250251 en la web (o escaneo el QR) y está en la AEAT.

Si hago una consulta directa en la AEAT tengo que poner Año: 2025 Mes operacion/Expedición: 07 Rango de fechas de expedición inicial 01/08/2025 y final 31/08/2025, entonces la visualiza. Si pongo mes operacion/expedición 08 la maldita ya no me aparece.

Repito en las consultas del componente no me la visualiza ni seleccionando el periodo 07 ni el periodo 08. No se si es un fallo en consultas o el fallo soy yo.
Agradecería si alguien pudiera comprobar si le pasa lo mismo.
Un saludo,

[Matorral]

Empezado por seccion_31

hola !

parece que no nos vamos de veraneo... y estamos hackeando el componente.

La filosofía del componente, era cubrir los casos comunes de la forma mas simple.

Algunas cosas de las que habéis hablado, se pueden solucionar fácil, de echo las facturas sustitutivas iva a ser un array, pero los arrays deben ser de longitudes fijas. ¿de cuantos elementos estaríamos hablando?

Yo tengo clientes (restaurantes) que hacen facturación mensual de los "tickets" de algunos de sus clientes (empresas). Van a comer casi todos los días y al final del mes les hacen una factura agrupando todos los tickets del mes. Yo creo que limitando a 30 fras. simplificadas por cada F3 irían sobraos (es mi opinión).

por otro lado, crear una R4, R5 con importe positivo creo que se podría hacer de otra forma, por ejemplo actuando sobre: facturaRegistro.facturaRectificada y no creando otra estructura nueva, es decir, automatizamos R5,R4 con importe negativo, o bien mediante el campo facturaRectificada

El objetivo de este comentario es tratar de mantener la simplicidad del componente, queda claro para todos que si rellenamos facturaRegistro.facturaRectificada tenemos una rectificativa. Y asi no solo nos limitariamos por importe negativo.

Yo probé a hacer el cambio que me sugirió el compañero DarkDudae para hacer las rectificativas por diferencias ('I'), y cambié en uVerifactuFuncs los

Código Delphi [-]
if facturaRegistro.total <0 then

por

Código Delphi [-]
if facturaRegistro.facturaRectificada<>'' then

y van de cine. Me hace las rectificativas R5 con importes negativos y positivos.

Son ideas, y creo que deberiamos mantener el componente sin ramales, porque perderemos seguridad.

Totalmente de acuerdo¡¡¡¡¡

Saludos !

Y feliz verano. Estoy en mi correo disponible, para ajustar esto.

Gracias¡¡

Tambien visto lo visto habria que pensar en crear documentacion....

Yo me ofrezco voluntario.

[Matorral]

Empezado por ramherfer

Me está surgiendo el siguiente problema, y ya no se si solo lo tengo solo yo. Tengo la versión 4.6 del componente.

Tengo la siguiente secuencia de facturas (encadenamientos verificados y correctos en el SIF):

A FR250252 01/08/25 FECHA OP: 01/08/25 Correcto B00000000 02 ES VENTA DE MERCADERIAS 469,42 98,58 568,00 A-5Y3B39LZD7UJBB
A FR250251 01/08/25 FECHA OP: 15/07/25 Correcto P7777777H 02 ES VENTA DE MERCADERIAS Y PRESTACION DE SERVICIOS 1519,80 319,16 1.838,96 A-AXZWAGYR2MBNXX
A FR250250 28/07/25 FECHA OP: 28/07/25 Correcto 19000000V 02 ES VENTA POR PRESTACION DE SERVICIOS 157,19 33,01 190,20 A-DHWF8UZHAY3KTT
A FR250249 28/07/25 FECHA OP: 28/07/25 Correcto.......

En las consultas la factura FR250251 no aparece ni matandome, ni en el periodo 07 ni en el periodo 08, la única diferencia con las otras es que la fecha de operación es la del ultimo albarán que se genero en el mes 07 y puesto como fecha operación en la factura generada el 01/08/2025 con todos los albaranes del mes anterior del cliente. Cotejo la FR250251 en la web (o escaneo el QR) y está en la AEAT.

Si hago una consulta directa en la AEAT tengo que poner Año: 2025 Mes operacion/Expedición: 07 Rango de fechas de expedición inicial 01/08/2025 y final 31/08/2025, entonces la visualiza. Si pongo mes operacion/expedición 08 la maldita ya no me aparece.

Repito en las consultas del componente no me la visualiza ni seleccionando el periodo 07 ni el periodo 08. No se si es un fallo en consultas o el fallo soy yo.
Agradecería si alguien pudiera comprobar si le pasa lo mismo.
Un saludo,

Pues si, a mi me pasa lo mismo.

Una factura con fecha de expedición 04/08/2025 y fecha de operación 30/07/2025,
En las consultas de la AEAT aparece en el periodo 2025-07 y entre fechas de expedición 01/08/2025 a 31/08/2025, pero en la consulta del componente no aparece.

[Matorral]

Acabo de probar ahora forzando el periodo a 2025 y 07 y fechas 01/08/2025 a 31/08/2025 y sale bien...

Código Delphi [-]
if VeriFactuD7.consulta('2025', '07', numero, desde, hasta, false, resultado) then ...

Asi sale bien

[seccion_31]

Empezado por Matorral

Acabo de probar ahora forzando el periodo a 2025 y 07 y fechas 01/08/2025 a 31/08/2025 y sale bien...

Código Delphi [-]
if VeriFactuD7.consulta('2025', '07', numero, desde, hasta, false, resultado) then ...

Asi sale bien

La AEAT computa las facturas por fecha de operacion, incluso el iva que va a calcular sera por fecha de operacion. (atentos: con lo que ello supone, si cambia el periodo de liquidacion entre expedicion y operacion) La fecha de expedicion NO la utiliza.

Creo que en la consulta ha podido ignorar las fechas y se ha centrado en el periodo, que es el que coincide con la fecha de operacion, la que usa para todo.

Yo diria que la busqueda va bien.

Voy a incluir en la 4.8 la opcion de R5 positivas y el array de facturas sustituidas, y lo que vaya surgiendo de este hilo.

Saludos !