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,