rectificativas de Fras. simplificadas R5
 

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¡¡¡¡

Eror en las subsanaciones
 

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,

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

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.

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;

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.

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.

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.

;)

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)

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



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

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.

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

Igualmente a todos¡¡

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¡¡¡

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

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,

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


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.


Totalmente de acuerdo¡¡¡¡¡

Gracias¡¡

Yo me ofrezco voluntario.

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.

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 !

en la versión 4.8

sustituyeTicketF3 será un array de 60 posiciones.

si el total de la factura es negativo se colocara como R4 ó R5, o bien si encuentra un valor en el campo facturaRectificada lo cual permitira subir R4, R5 positivas.

¿estamos con alguna cosa mas?

Saludos !


Tengo una documentación empezada luego la busco y te la envío matorral para que le des un vistazo.

Yo siempre condicionaría el uso de R4 y R5 a que el campo de facturaRectificada no esté en blanco, independientemente del importe.

Pueden darse casos de tickets F2 que no sean negativos (la AEAT los acepta).
Se me ocurre por ejemplo el típico caso de préstamos en fianza:

Un restaurante cobra al cliente una paella para llevar, y uno de los conceptos es: "préstamo de paellera: 5€". Luego el cliente al día siguiente la devuelve y le hacen un ticket con -5€ en concepto de devolución de la paellera. Este ticket no sería verdaderamente un rectificación del ticket original. Por otro lado, me consta que hay gente que está metiendo los abonos y devoluciones como simples F1 o F2 en negativo. ¿Es lo más correcto? En mi opinión no, pero puesto que la AEAT acepta estos registros en negativos... será por algo.

Para ese caso es que no queda otra, y menos un domingo de agosto.

si si, la búsqueda en el componente va bien, lo que falla es el filtrado que hacen ellos con el entorno de fechas + periodo, que se hacen la picha un lio. Filtran la fecha de operación por periodo (año+mes) y la fecha de expedición por entorno de fechas (desde y hasta). Esto lo hacen tanto enviando la consulta con el componente, como haciendo la consulta directamente desde la web. Un lio, vamos.


para mi perfecto.

¿entonces que hacemos?

¿anulamos la opcion de R4,R5 si encuentra valor negativo? ¿y la dejamos unicamente para cuando sea una rectificativa real?

Saludos !

Es lo que veo más lógico. A fin de cuentas, si no recuerdo mal los registro R4 y R5 necesitan el bloque de "FacturaRectificada" para que la AEAT los acepte...

(perdona DarkDudae y CarlosArjonomia, antes no os había leído)


Pues parece que es la mejor opción, porque igual que podemos hacer rectificativas con importes positivos, esta bien que podamos hacer F1 o F2 en negativo, por el motivo que sea.

Aunque yo en principio no voy a dejar esa opcion abierta al usuario (la de facturas en negativo).

ok, entonces lo dejamos asi.


¿algun cambio mas?

Hola, este hilo no lo sigo, pero he vusto una cosa que me gustaria comentaros respecto a las f1, f2 en negativos.
Se puede dar el caso que en la misma factura o tiquet se incluyan abonos y postivos, pudiendose dar el caso que el total sea negativo(totlamente legal si todo tiene el mismo tipo impositivo). A raiz de eso ya veis si veis conveniente activarlo o no, pero si lo activais es conveniente que pase el filtro del tipo impositivo.
Aparte las F1 en negativo(abonos) pueden ser necesarios para abonar una factura emitida a un cliente erroneo y en ocasiones hay que remitirsela al cliente equivicado(la de abono)

No entiendo lo que comentas.
Una línea de abono negativa tendrá la misma base que la línea original positiva que rectifica.
Si luego agregas más líneas en positivo podrán tener la misma base o distinta, eso sería indiferente. Simplemente se sumarán los importes de las distintas bases en la nueva factura rectificativa y se emitirá, independientemente de si es positiva o negativa.

Como bien apunta, no puedes abonar un articulo del 10% de iva, con una linea negativa del 21%, porque ahi hacienda pierde.

Yo hubiera dicho lo mismo que funciona bien si la hubiese mostrado en el periodo 07 (por su fecha de operación), pero no la muestra ni en el periodo 07 ni en el periodo 08 por su fecha de expedición. Pero no la muestra de ninguna de las formas. Si haces una prueba te darás cuenta que en el SIF queda una factura perdida en consultas. No creo que eso esté muy bien, pero bueno....

Me di cuenta cuando en consulta directa en la AEAT le indicaba periodo 07 y rango de fechas 01/08/2025 - 31/08/2025.

Siendo así no se si es interesante, obligatorio poner la fecha de operación del último albarán del mes anterior o directamente poner la fecha de operación la misma que la de factura. y que cada factura se visualice en su periodo o fecha de expedición, con lo que busco consejo al respecto. Esto sería lógico cuando el 1 de mes se facturan todos los albaranes de crédito del mes anterior ¿no?

un saludo

Lamentablemente, no puedo probar sin tus datos. ¿Quizas la AEAT la haya archivado mal? ni idea.

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

Hombre es sencillo de probar la aplicación demo si haces una secuencia como la que he planteado al inicio y en una de ellas cambias la fecha de operacion y le pones por ejemplo 15/07/2025 con la fecha de expedición 05/08/2025 veras que en una consulta no te la muestra ni el el periodo 07 ni en el 08.

el tema es el siguiente: y no lo tengo todo aclarado, porque creo se puede mejorar, pero esta es la explicacion.


Objeto de consulta:
Periodo: Periodo de imputacion, es decir periodo de la fecha de OPERACION. (solicitado por el objeto de consulta de la AEAT)

Fechas: son fechas de expedicion, es decir que en el objeto consulta de la AEAT mezcla ambos conceptos. Por un lado te pide el periodo de imputacion (mes de operacion) y por otro fechas de expedicion.

Demo
La demo tiene un problema, saca el periodo de la fecha de expedicion (desde), en cuenta de ir al combo y sacarlo de ahi.

Asi si, modificas la demo y pones el periodo de imputacion correcto y las fechas de expedicion correspondientes, desconectando los eventos que ajustan fechas automaticamente:

sale.

Componente
Funciona bien. Pero habria que ver como mejorarlo.




Saludos !

lo que no veo forma de consultar, sin especificar un rango de fechas de expedicion.

En la web de la AEAT ellos son capaces de lanzar esa consulta solo indicando el periodo de operacion, yo no veo forma,

cuando NO especificas fechas de expedición devuelve nada.

Saludos !

Es interesante el debate que abrís respecto a las consultas en la web de la AEAT. De todas formas no sé si es buena idea usar esa herramienta para por ejemplo, elaborar los modelos 303 de IVA, ya que si eliges una sustitutiva F3 sobre una F2 existente, siguen saliendo ambas.

No es tanto por hacer declaracion, sino por hacer pruebas y comprobaciones lanzando consultas, asi lo veo yo.

Pero en cuanto la expedicion salta del periodo contra la operacion, todo se vuelve un lio importante.

Saludos !

Lo dicho, si alguien sabe como lanzar una consulta sin dar fechas de expedicion que lo postee.

Nota: En la version 4.8 la demo estara modificada para funcionar correctamente.

Y yo tambien lo veo así para meras comprobaciones y poco más.

Claro ayer en el registro SIF se me ocurrió realizar comprobaciones de encadenamiento y comprobar que todo estaba correcto y cual fue mi sorpresa que cuando vi que al consultar una factura cotejada, que podía escanear el QR y comprobarla como correcta, no me aparecia en la utilidad de consultas a los super-cicutas de la AEAT y me saltaba un número en el periodo 08 (me lo hice encima). ¿Tiene importancia?, pues sabiendolo no. Con que el registro de mi SIF esté correcto, para mi es suficiente. Pero puede causar preocupación fundada en los usuarios, ya que pueden consultar y ver que hay saltos de facturas en las consultas a la AEAT. Aunque yo tambien preferiría ver todos los numeritos correlativos entre periodos sin perdidas y sus huellitas encadenadas.

Lo que veo una verdadera putada (con perdón) es poner la fecha de operación del último albarán del mes anterior, con fecha de expedición del mes actual y que se monte este pequeño trifostio a nivel de consulta.

saludos,