Quién me mandará a mi a meterme en camisas de once varas....
A ver, la operación con la que se inició esta discusión fue un rechazo de una factura donde te habías equivocado en el Nif o el tipo de Iva. En este caso no procede la rectificación por diferencia ya que el sentido de esta rectificación es complementar otra factura anterior y que sigue siendo válida, pero nunca sustituirla como deberías de hacer después de un rechazo.
La operación que habías sugerido fue F1, -R1, F1. esto es una sustitución de la primera factura F1 por otra F1 que no es rectificativa y por lo tanto que no cumple el reglamento. Sólo en las rectificaciones por diferencia, la Rx es la segunda y última de ese proceso.

¿Seguro que te has leído bien la respuesta a la pregunta ¿Cómo registra el emisor una factura rectificativa por sustitución “S”? ?

Vale, ese caso es cuando la rectificación es por sustitución. Como ponía más arriba, nosotros sólo contemplamos rectificaciones por diferencias. Todo aclarado entonces#:-)#

Se puede hacer solo rectificativas por diferencias?

sglorka parece que dice que no se puede hacer una rectificativa por diferencias para este caso.

Nosotros de momento también solo tenemos implementado rectificativas por diferencias pero viendo los comentarios en foros, estábamos empezando a preparar las rectificativas por sustitución pero ... si lo podemos evitar mejor :p

La ley exige rectificativa por sustitución en algunos casos? o puede ser siempre por diferencias (aunque también sea rechazada la factura negativa porque sigue teniendo mal el dato X)

Muchas gracias

Según entendemos nosotros, la ley no exige hacer de una manera o de otra una rectificativa, de ahí que hagamos siempre por diferencias.

El problema que planteamos aquí es hacer la rectificativa de una factura que no se subió porque dio error, ya que quedarían esos saltos de contadores. A ver si nos contestan de una santa vez

Aquí hay algo que deberíamos tener claro, si hay un error en una factura bien el Nif o algún tipo de Iva, o tenemos que modificar un precio o se devuelve mercancía o se aplica un rapell de descuento a posteriori,
o cualquiera de las circunstancias que puedan ocurrir, haya sido rechazada o no la factura, el reglamento es muy claro al respecto, se debe emitir una factura rectificativa para que el cliente la registre en su sistema, no podemos entregarle al cliente otra factura que corrige la anterior y que no sea Rectificativa ( si no ya me dirás para que sirve una factura rectificativa ).
Por ello, existen ambos tipos de rectificación, por diferencia siempre entregas la factura rectificativa al cliente con la modificación que complementa la anetrior, y la de sustitución siempre es la que entregas al cliente con los datos corregidos, si estás en dos pasos, no es necesario enviar el abono previo

Es coreecto, las rectificativas por diferencias no siempre valen.
Y claro que pueden sancionar, está en el reglamento de facturación de 2012, si le hechas un vistazo.
Las rectificativas spor diferencias tienen acotados los escenarios e los que se pueden emitir y no valen por ejemplo para corregir clientes ni errores en los tipos impositivos, si emites una factua mal con un iva equivocado y emites una por diferencias con el iva en negativo, también mal, tendrás 2 facturas mal, si emites una rectificativa por diferencias para anular una factura por un cliente erróneo es equivalente a emitir un abono y la ley te obliga a que si emites un abono por ese concepto tienes que emitir una rectificativa por sustitución.
Os aconsejo que lo hagáis bien, pero no os agobies hay muchísimas aplicaciones que actualmente hacen barbaridades y si al menos hacéis rectificativas indicando a qué factura rectifica de momento no creo que se os caiga el pelo, pero cuando empiecen a necesitar pasta tiraran de todo esto seguro y si hay una inspección por otras causas les suma. Depende también del inspector, como en todo

No encuentro donde dice que se tiene que usar un tipo de rectificativa o el otro.
Me parece que el Reglamento de Facturación no establece una norma imperativa que obligue a utilizar exclusivamente una factura rectificativa por sustitución o una por diferencias en función del tipo de error cometido.

Nos podéis pasar el enlace y el apartado donde lo indica por favor?

Muchas gracias

Buenas, no explícitamente, pero esto solo se puede hacer con las de sustitución, así que no te queda otra.

El reglamento no dicta una norma específica pero si dicta un procedimiento concreto, si los datos del cliente son erróneos debes emitir una factura rectificativa donde figuren los datos correctos. Si esto lo haces por diferencia, emitiendo una -Rx (con los datos mal) y posteriormente una Fx (con los datos corregidos) ¿ Dónde está la factura rectificativa con los datos correctos como indica el reglamento ?

No se supone que si es por diferencia se realiza todo en un mismo paso, o sea Fx con datos del cliente mal, Rx con únicamente los datos corregidos y ya. Que yo sepa las rectificativas por diferencias son siempre en un paso no????

Rectificativa por diferencias no creo que sea correcta para solventar datos mal del cliente. Más bien es para cambios en importes.

Lo he buscado y por lo encontrado es lo que tenía pensado.
Una factura rectificativa por diferencias se usa para corregir errores en la base imponible, cantidades o cuotas de IVA en una factura ya emitida, sin que se produzcan cambios en los datos del emisor o receptor. Este tipo de factura se utiliza cuando hay una modificación en el importe de la factura original, pero no en los datos básicos.

De todas formas , es todo lo mismo interpretación, puesto que no es lo mismo que al crear la factura pusieras mal algún dato, del destinatario, que errar el destinatario al que iba la factura.
Si erras algún dato, pues es normal y no creo que el cliente final ponga el grito en el cielo si le explicas porque le entregas una RX, en vez de una factura normal,pero si erras el destinatario completo, veo mas factible,anular la factura completa, puesto que no debió existir, como dice la norma R4 en negativo (¿Por diferencias?, Es un abono.) y emitir una factura normal nueva al cliente correcto, no una rectificativa, que le va a sonar a rayos...
No creéis que seria lo mas lógico?

Esto ponen en la FAQ's respecto a errores en la identificación, mas lógico es, lo que no dejan muy claro es donde ponen el límite en el que sería mejor anular o rectificar.

Estamos pasando una batería de pruebas con el tema este de facturas emitidas con algún dato incorrecto. Puedes enviar una "subsanación sin rechazo previo" de cualquier factura, cambiando CIF e importes. Siempre la acepta como correctas y sustituye a la anterior, incluso varias modificaciones de la misma factura... si esto es así, no le veo sentido a las facturas rectificativas por sustitución, realmente puedes modificar una factura las veces que quieras y enviar subsanaciones de la misma. Simplemente hay que guardar los datos de cada envío realizado incluyendo la huella. Luego puedo listar el Log de envíos de una factura, con los datos que tenía cada vez que se ha enviado. (Ojo, para hacer una comprobación de huellas tienes que tener en cuenta los envíos de este log, no la factura final)

Obviamente, es una prueba, no va a ser un modus operandi... pero está bien saber que se pueden modificar facturas sin tener que liarla parda con rectificativas, sustitutivas y "refanfinflativas".

Hola
Una cosa es que no la rechacen y otra cosa es que sea válida y posteriormente te llegue una notificación.
Esto es como cuando haces la declaración de la renta, en un principio está todo coreecto pero puede haber verificaciones posteriores, además es algo que ya se ha consultado varias veces y no, no se puede subsanar lo que sea objeto de rectificativas, aunque te la acepte.

Buenas en el tema de validar los NIF, mirar que me ha pasado. Cuando he dado un nif incorrecto de un cliente me ha devuelto IDENTIFICADO cuando no tiene nada que ver. Entiendo que ya no me puedo fiar de la respuesta del WS de Calidad de Datos Identificativos para esto que comentas. :mad:

Archivo Adjunto 4267

Podeis hacer la prueba...

Efectivamente, te devuelve otro nif y otro nombre :eek:

Acabo de hacer la prueba y ocurre lo que comentas.
El NIF que has escrito para comprobar no es incorrecto, es un NIF válido, por ese motivo te ha contestado IDENTIFICADO.
Que no es el NIF de la empresa a la que estas facturando? puede ser. Ha dado la casualidad que has escrito un nif que existe.
Como es una empresa persona jurídica, en el webservice no se comprueba la razón social, solo el NIF.
En la respuesta a parte de si está identificado o no, te contestan con la razón social correcta, y en este caso, con lo que imagino que seria un nuevo NIF para la empresa que antes tenia el NIF que has escrito.
Si cuando tu SIF hace la verificación, a parte de leer si está identificado o no, también compruebas los otros campos, puedes hacer alguna acción si no son iguales, como por ejemplo informar al usuario de los datos de la respuesta y que el decida.
Además si envías un registro de facturación con los datos que has escrito para validar, el registro es aceptado.
Si el usuario no hace caso de tu mensaje y lo acepta todo, pues hará una factura con un NIF que no es el de su cliente y cuando el cliente lo vea y se queje, tendrá que hacer una factura rectificativa...

Esperemos que ocurra poco

El nif que responde empieza por E y el que he consultado por B no tienen nada que ver. Vamos entonces para que hacen un Servicio de Calidad de Datos Identificativos si al final responde lo que le viene en gana... Yo no lo veo correcto eso deben de arreglarlo.

Simplemente el CIF, es el mismo, pero han cambiado de tipo de sociedad, si pasa de SA a SL te pasan la letra de A a B, creo recordar, pero el Cif es el mismo, eso ya lo tratamos , puse incluso una captura de la descripción de lo que significan las letras, por eso para verificar la estructura de un Cif, no se tiene en cuenta la letra inicial.
Yo en la función que valida el Nif/Cif, devuelvo y muestro en pantalla , los datos que rezan en la AEAT, para que el usuario este sabedor y actúe al respecto.

Creo q más que el usuario actue al respecto. Sería mejor un WS que devuelva información correcta a una sencilla consulta. Es mi opinión. Si le pregunto a una calculadora si 2+2 son 4 no me puede decir que SI que 3+3 son 6

La verdad es que no es así exactamente , usted le ha preguntado si el CIF, está en vigor y él le ha dicho sí está activo pero tenga en cuenta que ha cambiado su nombre por este y ahora su CIF es este.

Si haces una búsqueda en internet, la empresa ALTRETEX SL, figura como "EXTINGUIDA".

Posiblemente, la Empresa y CIF que te devuelve la consulta, será quien se ha hecho cargo de ella.

El asunto está en que el WS tiene que comparar la totalidad o parte de la Razón Social con el NIF y devolver una respuesta en función de esa dupla. Esto es porque no sabe si en el SIF el usuario se equivocó en el NIF o en la Razón Social.

En todo SIF deberían hacerse varias comprobaciones antes de generar los RF, de esa manera reducimos al mínimo los errores devueltos por el sistema y evitamos tener que corregir los mismos para volver a mandarlos:

1. Comprobar en el servicio de cotejo si el NIF+Razón Social del destinatario están en estado IDENTIFICADO. Si lo está, marcarlo en la base de datos como IDENTIFICADO y actualizar los datos a los devueltos por la AEAT, y no volver a preguntar por ese destinatario en el futuro. Antes de poner el SIF en funcionamiento, el NIF y Razón Social del obligado tributario (OT) que expide los RF deben ser los registrados en la AEAT.
2. Realizar la validación de errores, siguiendo el documento de validaciones y errores publicado por la AEAT.
3. Generar hash en función del último RF del OT.
4. Generar el RF con los datos ya validados de la factura en el punto 2 y con el hash del punto 3.

Si alguna de las funciones anteriores falla, el SIF no puede marcar la factura como finalizada (emitida) y deberá avisar al usuario de errores por si algunos de ellos está de su mano corregir o si debe reintentarlo más tarde.
Si no falla ninguna, ya se puede imprimir la factura con su código QR.

Posteriormente, un subproceso debe enviar los RF agrupados generados desde el último envío y enviarlos siguiendo el control de flujo que especifica la AEAT (el control de flujo es por SIF y por OT, esto obliga a guardar en algún sitio los tiempos devueltos por el Webservice de cada OT y ejecutar los envíos en dichos tiempos):
1. Agrupo los RF de un mismo OT y los envío tras cumplirse el tiempo devuelto en el anterior envío, o bien los envío sobre la marcha si se han acumulado 1000 registros o si es el primer envío.
2. Gestionar la respuesta para ver si algún RF dio error. Si alguno dio error, debe comunicarlo de alguna forma al SIF principal para que el usuario corrija los datos erróneos de la factura.
3. Para el que tuvo error, una vez corregida la factura se generará otro RF de tipo Alta por rechazo o por subsanación.
4. Para el que no tuvo error, siempre conviene llevar un registro interno de los envíos aunque sólo sea para justificarlo al usuario del SIF, pero al ya estar en manos de la AEAT puedes considerar borrarlo.

Esto es más o menos lo que mi empresa va a hacer con sus SIF. Si estoy equivocado o falta añadir algo, por favor corríjanme y así ganamos todos.

A nivel de SIF, en los contadores de factura no pueden existir saltos porque ya no se pueden borrar facturas. A nivel de RF, los saltos tampoco existirán porque se generan en función del último RF generado por cada obligado tributario. Si hubieron errores en los RF, tendrás que acudir al alta/baja por rechazo o por subsanación, pero de nuevo no se producirán saltos, pues el nuevo que vas a subir contiene la huella del último generado por el SIF.

¿Y si usamos siempre rectificativas por sustitución, incluso aunque sólo cambien los importes, sería válido? En algunas webs hablan de que sería una praxis correcta, por ejemplo aquí: https://getquipu.com/blog/factura-re...20la%20factura.

En nuestro programa no tendríamos problemas, el salto quedaría en la AEAT. Y además en 2 series: la normal y la rectificativa. Y eso es lo que estamos esperando a que nos contesten para ver si es OK o le podrían poner pegas

Aqui antes teniamos solo por diferencias, es lo que esta para el SII, cuando cogi yo el tema del Veri*Factu añadi el poder hacer de las dos formas (diferencias, sustitución), así dependiendo el problema que hubiese puede seleccionar la oportuna.
Supongo que no debe haber problema por usas siempre por sustitución.

Si no se registró el RF en la AEAT, ellos no tienen el registro. Si tu SIF tiene el registro y ellos no, tendrás que seguir reintentando su envío. ¿Te refieres al caso de si generas un RF de una rectificativa y la AEAT todavía no tiene el de la factura original?

No, me refiero a que si yo creo una factura con el CIF incorrecto (por ejemplo porque puse mal la letra, o un número) cuando envíe ese registro me dará error por el CIF. Si luego creo una factura rectificativa para corregir esa, al subirla también me dará error (el mismo). Si luego creo la factura correcta, está sí subirá sin error. Pero quedará algo así:

en mi programa habrá 3 facturas:
Factura 1 -> con el cif mal
Factura R-1 -> la rectificativa, también con el cif mal
Factura 2 -> correcta

en la AEAT sólo habrá 1:
Factura 2 -> correcta

La factura 1 para ellos no existe, y ahí es donde hay un salto de contadores. Y cuando suba la R-2 (otra rectificativa) pasará lo mismo: para ellos no existirá la R-1

Estamos implementando ahora el control de si el CIF es incorrecto ya no generemos la factura / ticket para evitar esto. Pero deberían dejar muy claro como proceder ante este caso.
Le pregunté hace más de un mes y le insistí 2 veces más y sigo sin la respuesta. En fin... :mad:

- Factura 1 no se puede marcar como finalizada o emitida por tener mal el NIF, por lo tanto no se registra ningún RF en el SIF y por tanto tampoco en AEAT. El destinatario debe cotejarse en el momento de finalizar la factura a no ser que ya haya sido cotejado antes. Es bueno que crees un campo llamemos "IDENTIFICADO" o algo así en tu tabla de clientes y aquel que ya haya sido cotejado lo marcas con una S por ejemplo.
- Factura R-1 tampoco la puedes registrar por la misma razón que lo anterior, por tanto tampoco se registra ningún RF en el SIF y por tanto tampoco en AEAT.
- Factura 2 no tiene sentido hacerla si las dos anteriores han fallado al finalizarse.

¿donde dice que no puedes crear una factura si el CIF es incorrecto? ¿puedes controlarlo, debes controlarlo o es obligatorio controlarlo?
¿que sentido tiene entonces que controlen por ejemplo el error 1123-El formato del NIF es incorrecto.?

No lo dice en ningún sitio y por lo tanto no es obligatorio, pero es una manera de reducir errores a la mínima expresión, lo mismo que las validaciones del Documento de Validaciones de la AEAT. Si no las implementas, te arriesgas a que el RF se rechace, y el usuario tenga que hacer modificaciones a base de rectificativas, porque en el SIF estará generado el RF pero en la AEAT no. Es entonces cuando la casuística que planteabas se puede dar, ya veremos qué respuesta te dan los de verifactu.

En el caso del SII no había tanto problema con los errores de este tipo, porque ante un error podías corregir la factura en tu programa, anularla en la plataforma y volverla a subir, sin tener que lidiar con los RF.

de la FAQ:

Cita:

En el probable caso de que el RF generado de la “factura errónea” fuera rechazado por la AEAT (lo que podría servir para que el usua rio se percatara del error cometido), ese RF rechazado no figuraría jamás en los sistemas de la AEAT (aunque constaría un rechazo).

Aquí veo que segunlo que haya pasado, podrias hacer un registro de subsanación, pero ante la probabilidad de que ya se haya entregado al cliente, no deberian existir 2 facturas del mimos numero con diferentes CIFs, aunque uno fuera erroneo, en otro lugar de la faq, dice que las subsanaciones se realizaran si son datos que no figuran en la factura fisica

Cita:

Si los errores detectados tras la emisión NO están contemplados en el ROF, pero afectan a campos del registro de facturación ( RF) generado al emitir la factura (que, digamos, “no se ven” en la factura impresa, es decir, son campos “internos”, como ciertas codificaciones tributarias), se debe corregir la factura original (esos datos “internos” de la misma) y se debe generar un RF de alta de subsanación de esa factura donde conste ya la nueva información que proceda. Estos casos deberían ser MUY POCO FRECUENTES.

El tema es que esta situación no la tienen bien cerrada, aquí os dejo como lo podeis plantear al correo de verifactu los interesados que no tengan bien cerrado lo de los clientes o esten preocupados que les pueda pasar:
-El problema radica en una factura que se ha emitido erroneamente con un CIF, erroneo o que dicho CIF ya no es valido, con lo cual nos encontramos:
1. Que, teoricamente, no se puede anular por que ya se ha enviado al cliente, a pesar de estar erroneo el cif,
2.No se puede subsanar por que son datos visibles y afectan al RF.
3.Se supone que hay una operativa definida para rectificar que es: un abono al cliente erroneo y una reemision al correcto
4.Si hacemos la operativa normal, abono y reemision, ahora tendriamos 2 registros, el inicial y el de abono, que no se pueden enviar por que vuelven a dar error, ni admiten subsanación, ni anulación.

¿Cual seria la operativa mas acertada?
Anulacion
Subsanacion
Abono y reemision (aunque no les llegue la original y el abono?)
....?





Pero por otro lado tenemos esto, con lo cual al final es subsanacion, vaya lio.

Yo optaría por enviar un abono y una rectificativa por sustitución, aunque tenga dos registros rechazados en Verifactu, nuestra obligación es cumplir con el ROF, si Verifactu no es capaz de gestionar correctamente este escenario es su problema no el nuestro.

En el último párrafo les falto poner la coletilla que siempre ponen y que éste se ha olvidado, "... cuando no sea necesario emitir una rectificativa... "

Cita:
Si el RF generado de la “factura errónea” fuera rechazado por la AEAT (lo que podría servir para que el usuario se percatara del error cometido), habría que corregir la factura original y generar un RF de alta de subsanación , sin registro
previo en la AEAT (ya que el RF “original” fue rechazado y no existe en la AEAT).
Por lo tanto, este RF de alta de subsanación deberá llevar una codificación
especial en ciertos campos ('Subsanacion' = "S" y 'RechazoPrevio'="X"),

No hagas la rectificación así cuando estamos hablando del mismo cliente pero con un dato de Cif mal. Se ha escrito sobre esto cientos de veces.

https://petete.tributos.hacienda.gob...sulta=V0706-19

"cuando el procedimiento de rectificación de una factura se realice mediante la emisión de dos facturas en los términos previstos en el párrafo anterior, deberá considerarse como factura ordinaria la primera que se expida con signo negativo, incluso por el importe total de la factura previamente expedida, y como rectificativa la que se expida conteniendo correctamente los datos que se documentan en la misma tras la rectificación."

Hola
Otra cosa que hay que tener en cuenta es que aunque te devuelva identificado te puede devolver otra letra por que haya cambiado de tipo de sociedad o por que simplemente el usuario o el cliente lo hayan dado mal, por ejemplo de A28000... a B28000... o de B28000 a A28000... u otra letra.
Aunque parezca raro se me han dado casos y además si te fijas en los algoritmos de cálculo para los cifs es el mismo resultado para ambos sin cambiar el número aunque cambie la letra.
En ese caso como te digo tiens que coger el identificador que te devuelve la aeat y/o informar al operador de que no es el mismo.

Pero ¿y cuando se trate de otro cliente? es decir, me he equivocado de cliente al hacer la factura ¿sería correcto en este caso que al hacer F1 al cliente A, y darme cuenta de que no era ese cliente, entonces hacer -R4 al cliente A y +F1 al cliente B?

Entiendo que B no tiene porqué saber nada de mis errores con A, ni tengo que darle una factura que dice que rectifica a tal y cual por tal motivo, esa información SI es relevante en el caso de que sea el mismo cliente porque va a tener tres documentos y se entiende lo que ha pasado, pero para nada le veo el sentido en el caso de que sean clientes distintos.... es al cliente A al que le tengo que dar la R4 que explica la F1 que le he dado antes equivocadamente (y la compensa), y al cliente B le doy su F1 y tan contentos.

¿Estoy totalmente equivocado?

Gracias!!

Yo lo veo correcto como.lo planteas
Al cliente A
-R4
o
-F1=abono(yo he optado por esta)
Y nueva F1 al correcto

Y si no la has entregado aún Anulación
Y si además el cliente A es erroneo en la aeat, anulación también, he considerado esta anulación, que creo que es válida, ya que esa factura al ser rechazada es una factura incorrecta ya sea estructuralmente(por nif mal generado) o por que sea un nif inválido para la aeat, por lo tanto es no declarabe y es papel mojado.

Por eso he puesto "cuando estamos hablando del mismo cliente pero con un dato de Cif mal"

Si resulta que al primer cliente no iba esa factura, debes emitir un Abono (-F1, ya que no se encuentra entre los casos de emisión obligatoria de una factura rectificativa ) y para el segundo cliente que sí es correcto una F1