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