Reenvío de facturas el Entorno de Pruebas SIN especificar Subsanación
 

He empezado a hacer pruebas con el envío de subsanaciones de facturas, previamente rechazadas, aceptadas o aceptadas con errores, y me he dado cuenta de que he podido enviar una misma factura las veces que me de la gana hasta que Hacienda la acepta, SIN tener que indicar en ningún momento 'Subsanacion' = "S" y 'RechazoPrevio'="X".

Esto es normal? O es que Hacienda por ahora no está controlando eso? o son ellos los que se encargan de comprobarlo todo una vez reciban el registro correcto?

Que ya puestos, podría ser así: si yo envío una factura 2 veces, la segunda vez que la envíe deberían tomarla como una "subsanación" sin que yo tenga que decirles nada, pero bueno. O al menos no se me ocurre un motivo por el que no se pueda automatizar eso.
Otra cosa son las rectificativas, que sí habría que indicar a qué factura rectifica. Pero una subsanación, que no es más que la MISMA factura corregida, no veo la necesidad de tener que dárselo todo masticado.

Pero bueno, al lío... ¿Es normal que pueda enviar la misma factura (previamente rechazada) varias veces, sin tener que indicar "Subsanación = S"?

Y otra pregunta...

¿Cual es la forma correcta de indicar los campos Subsanación y RechazoPrevio? He visto algunos ejemplos pero ninguno con Subsanación=S RechazoPrevio=S. Siempre llevan X

- Factura previamente "Rechazada": Subsanación = S y RechazoPrevio = X ¿Por qué "X" y no "S"?
- Factura "Aceptada con Errores": Subsanación = S y ¿RechazoPrevio = N o S?
- Factura "Aceptada" pero nosotros mismos nos hemos dado cuenta de que requiere subsanación: Subsanación = S y ¿RechazoPrevio = N?

Pues eso. Siento sacar este tema otra vez, pero no me queda claro ni siquiera con el post de la respuesta "oficial" de Hacienda sobre este tema.

Te diria que la factura no esta en su sistema por tanto factura nueva. te la rechaza de nuevo por el motivo que sea.

Por lo que entendi en el hilo del componente para D7:

La huella de esa factura, en su nuevo envio debera cambiar si has enviado otras despues, y por la nueva hora de envio. En este caso Subsanación = S y RechazoPrevio = X (porque no esta en su sistema). En algun momento la factura pasara y quedara ahi con esos marcadadores, para indicar que tuvistes problemas.

Saludos

Si no especificas que es una subsanación entienden que la estás reenviando y, si ya existe, te dará un error de factura duplicada. Si lleva la marca de subsanación se la tragará sin problemas.


Entiendo que si la factura ha sido previamente rechazada tendrás que marcar lo de "rechazo previo" y si no no. Y si ya la has enviado en alguna ocasión siempre marcarla como subsanación.


De una forma o de otra cuidadín con eso de subsanar facturas que lo habitual es que lo que haya que hacer es rectificarla, no subsanarla. Subsanarla solamente cuando cambie algo que no afecte a la ley de facturación que serán pocas cosas.


Saludos.

Claro, pero la factura pudo haber sido rechazada, aceptada o aceptada con errores. ¿Por qué entonces hay tres opciones para RechazoPrevio (S, N y X)?

Si, estoy haciéndolo solo con aquellas facturas que durante el desarrollo me han dado error. Entiendo que una vez esté todo pulido, a nivel de programación, y todos los escenarios estén previstos, no se debería tener que subsanar ninguna factura.

Bueno... esto pone en la documentación:





Saludos.

Entiendo por lo tanto, que en la lista de códigos de error posibles, el primer bloque (del 4102 al 4138 y del 3500 al 3503) el ENVÍO es rechazado completamente. Hacienda no tiene constancia alguna de la factura, y en ese caso debemos arreglar lo que esté mal y reenviarla como factura normal (no subsanación).

El segundo bloque que "rechaza la factura o bien el envío completo si el error está en la cabecera" (del 1100 al 1281 y del 3000 al 3003) es el que no me queda claro. Supongo que dependerá de si es rechazada completamente o aceptada con errores? Veo errores ahí que no tienen por qué requerir una rectificativa. La mayoría son errores "nuestros" (de programación) que deberíamos evitar que ocurran. No me queda claro si aquí hay que subsanar o reenviar como alta normal, imagino que según haya sido rechazada o aceptada con errores.

El último bloque (del 2000 al 2007) aceptan la factura pero deben ser "subsanados". Sin embargo, algunos de esos errores (como este: El campo ImporteTotal tiene un valor incorrecto para el valor de los campos BaseImponibleOimporteNoSujeto, CuotaRepercutida y CuotaRecargoEquivalencia suministrados) no sé hasta qué punto se deberían aceptar. Bajo mi punto de vista, no deberían aceptar una factura si los importes no cuadran, pero bueno.

Lo dicho, tengo dudas con qué se debe hacer con cada bloque. Agradezco que hayan elaborado el listado de errores, pero que lo podían haber dejado todo más claro también es un hecho.
Mañana empezaré a hacer pruebas de varios tipos a ver si a base de probar lo voy entendiendo mejor.

Yo creo que no es así. El que te rechacen la factura no significa que puedas corregirla y volver a enviarla como "nueva". Para la aeat "Factura hecha=Factura sagrada que no se puede corregir" a no ser que sea por algo distinto a la ley de facturación. Yo creo (es mi opinión) que una factura que te rechacen la mayoría de las veces tendrás que hacer una rectificativa. Tienes que tener en cuenta que la aeat aunque te rechace una factura "sabe" que se las intentado subir con unas características y no sé eso qué repercusiones puede tener en el futuro. Yo por mi parte de momento no doy ni opción a subsanar, factura que se rechaza directamente se sustituye con otra correcta.


Saludos.

Entiendo entonces que solo vas a permitir "rectificar", sea el error o el tipo de modificación que sea.

Está claro que esa opción da menos dolores de cabeza, pero no sé si es del todo correcto (aunque aceptado, y no te pueden prohibir hacerlo).

Mi intención es permitir subsanar solo algunas facturas que hayan sido rechazadas. Dependiendo del error que sea. Si luego el cliente prefiere rectificar, pues que rectifique, pero al menos con algunos códigos de error creo que sí es preferible subsanar. ¿Por qué?

- Subsanar no requiere hacer otra factura nueva (rectificativa). Se envía la MISMA, corregida/modificada, simplemente indicando que es una subsanación. Menos trabajo para el cliente, sobre todo en errores que hayan sido por algún despiste.

Mi duda (y creo que la de muchos) es no saber exactamente cuándo se debe/puede subsanar y cuándo no. Por mucho que la AEAT te diga "depende de si afecta al RF o al ROF o al RIFIRAFE", me tienen un poco cansado con tanto tecnicismo que te obligue a leerlo todo uno a uno.

No sé. Haré pruebas estos días y ya veré qué hago. Por lo pronto creo que me voy a decantar por no permitir nunca modificar una factura y requerir hacer siempre rectificativa, pese a quien le pese, porque lo de modificar facturas creo que ya debería estar prohibido desde la Ley Antifraude, y nuestro software ya no lo permite. Paso de permitirlo "según el caso".

Ese es también mi planteamiento, ante cualquier error en una factura, rectificativa completa al canto y factura completa nueva, estoy mareado ya de tanto "si esto o lo otro", porque me da la sensación de que siempre se me va a colar algún escenario y me van a poder "pillar" en algún error y me voy a comer el marrón.... Es muchiiiisimo más simple de programar y asegurar la trazabilidad sin el menor tipo de duda, al menos esa es mi opinión. ¿Es ilegal el planteamiento?

No creo que sea ilegal. No está prohibido que tu hagas rectificativa siempre que quieras modificar algo, sea lo que sea. Como si me da por rectificar una factura 7 veces porque me divierte. Eso es problema mío siempre que lo haga bien.

El único inconveniente que veo es precisamente ese, que hay que hacer otra factura (o incluso dos) dependiendo de si es por Diferencias o por Sustitución.
Por no hablar de que si en la rectificativas también te equivocas, pues tendrás que hacer otra rectificativa más, y así sucesivamente hasta que des con la tecla. Sin embargo con una subsanación solo tienes que modificar la original.

Lo que no tiene sentido es la comedera de coco para saber cuándo debo hacer una cosa u otra. Redactan la normativa a su manera y lo que provocan es que cada persona lo interprete a su manera. Después como consecuencia te encuentras programas que hacen una cosa y otros que hacen otra, o clientes finales que hacen lo que les da la gana.

Hoy haré pruebas de subsanación. Si no me convence o lo veo más complicado de lo normal, me paso a rectificativas para todo y punto.

El problema con estas cosas es que el usuario "normal" no tiene ni idea de leyes ni normativas de facturación ni de nada por lo que hay que intentar poner las cosas de forma simple para que no pueden meter demasiado la pata. Si (por ejemplo) les dejas subsanar y se dan cuenta de que si se equivocan de cif (por ejemplo) lo corrigen, lo envían como subsanación y cuela lo van a hacer por norma y es incorrecto por lo que yo tomé la determinación de no dejar subsanar nada, siempre rectificativas. Aparte de por lo que comento porque los casos subsanables serán mínimos o ninguno.

Si, se supone (si no añaden mas casos) que los errores subsanables se deberían poder controlar previo al envía de la factura y si esta bien hecho nunca darse ningún caso, nosotros tampoco dejamos subsanar a los clientes, me parece la mejor forma la verdad.

Qué pasaría si la AEAT me RECHAZA completamente una factura (por ejemplo, la número 50), por el motivo que sea. Se supone que Hacienda no ha recibido nada (bueno, sabe que algo se rechazó, pero NO tiene la factura 50 registrada porque había errores).

¿Puedo hacer una rectificativa que rectifica a la factura 50, aunque Hacienda NO tenga ninguna factura 50?

Supongo que estos serían los (pocos) casos en los que la factura original se puede modificar y enviar subsanación, no?

Es que me acaba de surgir la duda al empezar a hacer pruebas. Si la 50 se rechazó (xml mal formado, o cualquier otro error que produzca un rechazo completo), no sé si es posible rectificar esa factura.

Entiendo que no debemos mezclar las facturas con los registros de facturación. Un RF (rechazado o no) se podrá subsanar, lo de rectificar queda para las facturas.

ALTA POR RECHAZO · Alta por rechazo del registro de facturación de alta inicial (y que, por tanto, no existe aún en la AEAT). · Es la subsanación de datos de un registro de facturación de alta inicial, cuando no se exige la emisión de una factura rectificativa (u otro mecanismo contemplado en el Reglamento de Facturación). · <Subsanacion>=S · <RechazoPrevio>=X · VERI*FACTU · La clave única del registro de facturación no debe existir previamente en la AEAT. · El alta previa del registro de facturación fue rechazada. Alta del registro de facturación con los nuevos datos.

En tu caso yo entiendo que procedería esto. EDIT: Nada olvidaos que esto es solo para el primer registro de todos.

Por lo tanto, la opción de permitir SOLO hacer rectificativas, y no subsanar (que es de lo que estamos hablando en este hilo), no sería una opción en este caso, no?

Otro caso que también creo que no se puede arreglar con una rectificativa: el problema de los NIFs válidos pero NO CENSADOS. En este caso concreto, en los que el NIF es válido, real, etc. pero Hacienda dice que no está censado (aún), hay que enviar la factura indicando IDOtro = 07 (no censado), y eso no se podrá hacer con una rectificativa.

Por lo tanto, creo que no todo se puede arreglar con "rectificativas": Algunas cosas van a requerir sí o sí una subsanación.

Efectivamente el caso del censo debe ser con subsanación, o bien puedes consultar el NIF antes del envío y enviarlo directamente como IDotro

Este caso puedes ahorrártelo antes de mandar la factura, hay un WS que te dice si un dni esta o no censado, eso si tienes que tener certificado real para probarlo, no vale con el de pruebas.

Me pareció haber leído que el webservice de validación de NIF puede decirte que el NIF es válido pero, aún así, Hacienda puede responderte con el error "1110 El NIF no está identificado en el censo de la AEAT" en algunos casos.

Yo uso ese webservice para comprobar el NIF antes de hacer el envío a VeriFactu. Si el webservice me dice que el nif no es correcto, no permito emitir/enviar la factura, hasta que el usuario lo compruebe.

Pero en el caso de que el webservice lo de por válido, pero la AEAT devuelva ese error, entonces no queda otro remedio que hacer subsanación, porque no puedo saber si me va a dar el error hasta que no haga el envío.

En definitiva, que sí habrá casos en los que sí o sí hay que "subsanar".

Eso sería anulación sin registro previo
Subsanacion son casos muy excepcionales que no este el error en el nodo de registrofacturacion

Ese error es no subsanable, que yo sepa solo puedes subsanar del 2000 al 2007, no confundir el error 1110 con el 2001.

¿Por qué debería anular una factura correcta, que tiene un nif correcto, pero que la AEAT no tiene actualizado en su censo?
¿Qué hago entonces, le pido al cliente otro nif distinto?

¿No se puede enviar como subsanación, esta vez poniendo IDOtro = 07 (no censado)?

A ver, la aeat no puede tener un tío en ventanilla esperando a comprobar que ese cif, aunque no esté censado sea válido, por tanto,, veo lógico que te lo rechace con ese aviso de que no está, y ya lo envías por otro cauce, no me había fijado en el 07 No censado, pero si existe estupendo. Así que por lógica de los controles de flujo de escenarios similares, en los que rechazan una factura por algún motivo, lo lógico es anularla sin registro previo y remitirla de la forma que piensas que está bien.
Anulas sin registro previo y emites de nuevo como no censado

Confirmado lo que quería decir en el primer post de este hilo: una factura enviada y "rechazada", la puedo reenviar sin problema tras corregir el error.

Es decir... La he podido reenviar, tras corregir el error, SIN especificar en ningún sitio que era una subsanación, ni RechazoPrevio ni nada.

¿Es porque no han habilitado esa comprobación en el entorno de pruebas? ¿las facturas rechazadas se pueden simplemente reenviar y punto? ¿O es que ellos ya se encargarán de quedarse "con la última, que es la buena"?

Esta es la prueba que he hecho:
- Envío una factura normal pero me salto un campo adrede
- Me devuelve "Error1100: Valor o tipo incorrecto del campo".
- Queda marcada como "Error".

Según el listado de errores, se trata de un error "que provoca el rechazo de la factura (o de la petición completa si el error está en la cabecera)".

He vuelto a añadir el campo que faltaba, le he dado a enviar y se envía y se acepta sin avisos.

¿Es normal?

Luego he hecho esta otra prueba:
- Factura con un error forzado en las cuotas, total, etc.
- me devuelve el error 2005 o 2006, que supuestamente es SUBSANABLE según el listado de errores
- La factura la "acepta con avisos"
- Propongo por lo tanto "subsanación"
- Corrijo el error y le doy a "enviar como subsanación"
- Me dice "Error 3000 Registro duplicado"

Así que ya no sé si tomarme unos días libres o qué, la verdad.

¿has puesto Subsanación a "S"? Porque a mí ese caso me lo subsana correctamente


Saludos!

Si no recuerdo mal (ya no estoy en la oficina):

Subsanación S
Rechazo previo X

Mañana lo confirmo y pruebo otra vez

Si el error es estructural te dejan mandarlo de nuevo. El hecho de que lo mandes de nuevo arreglado no está dentro de lo que te piden. En error estructural tendrás que mandarlo como subsanacion sin registro previo.
En el caso de las cuotas erróneas, tampoco es coreecto una subsanacion, tienes que hacer una rectificativa.
El hecho de que te acepte no quiero decir que ya vaya a misa lo dicen muy claro, los envíos están sujetos a verificaciones posteriores
Saludos

Probaré mañana a enviarlo como Subsanación=S y RechazoPrevio=N.
Ahora bien... ¿no es confuso, y poco intuitivo, que la "rechacen" pero que tenga que poner RechazoPrevio=N?

En el listado de errores, el error 2005 aparece en el bloque de "deben ser subsanados". ¿O es que ahí la palabra "subsanados" no significa que requiera una "subsanación"?

Lo de "lo dicen muy claro", vamos de dejarlo ahí...

Esto es lo que dice Hacienda:

Ya podrían haberse currado mejor los bloques de error y ponernos las cosas un pelín más fáciles de entender. Creo que no pido tanto.
Teniendo en cuenta que el RF es el XML (fallo estructural, por ejemplo), entiendo que es el caso b), y por lo tanto, requiere subsanación. Pero sin embargo, yo la he reenviado directamente, tras corregir el error, sin indicar subsanación ni nada.

En mi segundo ejemplo, error 2005, la factura es "aceptada con errores". De verdad que me cuesta entender por qué se debe rectificar y no subsanar. Voy a terminar por no subsanar nada y solo permitir rectificativas y punto.

Perdona Rechazoprevio=X
Te había dicho N
Respecto a la frase debe ser subsanado no se refieren a subsanacion, tal y como comentas, la subsanacion abarca a todos los casos y sobreentendiendo que sabes que tipo de subsanacion tienes que aplicar en cada caso.
Lo de que están sujetas a verificaciones posteriores, si no recuerdo mal, viene en las respuestas a los envíos correctos

me he leido el hilo y me gustaria resumir (gracias por las intervenciones). no se si entendi bien:

Lista de errores:

https://prewww2.aeat.es/static_files...res.properties

De 4102 a 4138 error estructural se vuelve a enviar el registro encadenando con el que toque.

De 1100 a 1281 error en valores, se vuelve a enviar el registro encadenando con el que toque, (¿sin indicar nada?)

De 3000 a 3003 ¿?

De 2000 a 2007 subsanable, de nue vo respetando el encadenamiento.

Un error de DNI, entre 1100 y 1281, corregir el dni, colocar como no censado y reenviar. sin mas, encadenando con el anterior.

¿Esto quedaria asi?

Saludos !

nota: leyendo el archivo, no dice que el resto no puedan ser subsanados, viene a decir que de 2000 a 2007 deben ser subsanados (por que el registro fue aceptado), pero no que el resto no debe ser marcado como subsanado.

Ya podrían haber elegido otra palabrita que no prestara a confusión, pero no. Decidieron usar "subsanar" PEEEERO, ojo, no refiriéndose a "subsanación" sino a lo que el programador interprete que debe hacer :rolleyes:

Pues si no me equivoco, en varios hilos hay muchos de nosotros que están tomando ese bloque de errores como errores "subsanables".

Hice la consulta a Hacienda, comentándoles el lío que hay para decidir qué errores del listado son sujetos a subsanación y cuales a rectificación. Llevo esperando desde el viernes pasado a que me respondan.
A ver si con suerte se dan cuenta de la confusión que conlleva y nos dan una pista, cosa que dudo mucho.

Ojalá entre todos podamos ir completando esta información. Hay gente que ha dicho que hacen rectificativas para todo, y creo que no es correcto (aunque Hacienda se las traga).

Confirmado lo de ayer.

Factura #257 enviada y "aceptada con errores". El error concreto fue el "2005: Campo ImporteTotal tiene un valor incorrecto".
(Forcé ese error indicando que la factura estaba exenta sin estarlo realmente, o algo así, no recuerdo cómo exactamente).
La factura le consta a Hacienda (me aparece si hago una Consulta de los envíos realizados este mes)

La envío como Subsanación, indicando:
<Subsanacion>S</Subsanacion>
<RechazoPrevio>X</RechazoPrevio>

Me devuelve "Error 3000: Registro de facturación duplicado".

Así que en este caso, entiendo (no queda otra), que se debe hacer una Rectificativa. Pero menuda forma de darse cuenta, a base de prueba/error con cada caso posible y no por intuición.

De verdad que no entiendo cómo pudieron elaborar un sistema de esta forma: factura enviada, aceptada pero con errores -> ¿subsanación indicando rechazo previo? Pues no, rectificativa.

¿Será que solo las facturas con rechazo total se pueden subsanar? O tampoco?

Yo entiendo que si te la han aceptado con errores debes de marcar en rechazoprevio N

efectivamente

yo creo que la mayoria son subsanables, al menos asi lo entendi del hilo del componente, la cuestion es si estan en verifactu o no, pero puedo estar muy equivocado.

un error de estructura de nif no existente, etc..., queda en el registro de la aplicacion como enviado, rechazado, se vuelve a enviar corregido con otra huella cronologica distinta y una manera de documentarlo es subsanar, con rechazo previo o no. Eso entendi

otra cosa son errores de facturacion. ahi tendriamos las rectificativas, sustitutivas, etc...

Saludos !


Nota: si no estuviera permitido subsanar lo logico seria que rechazara la factura enviada y punto. Es algo basico.

Correcto.

Resumiendo (al menos para este caso, con error 2005):
- Envío factura con Error 2005 (factura exenta pero sin embargo el total no coincidía, adrede, con lo que debería ser)
- Es "aceptada con errores". Se entiende, por lo tanto, que NO ha sido rechazada, así que NO hay RechazoPrevio
- La reenvío como Subsanación = S
- No pongo nada en RechazoPrevio (por defecto es "N")

La acepta y queda enviada, feliz y contenta.

Ahora bien, que también se pueda rectificar... pues supongo que se la tragará. Igual que se traga también un abono en negativo para "anularla" y volver a hacer otra nueva bien hecha.

Entiendo entonces que si una factura es aceptada, aunque sea con errores, se puede subsanar pero SIN rechazo previo, porque no fue rechazada, sino aceptada con errores.

Ahora solo hace falta que nos pongamos todos de acuerdo, porque ya te digo que en estas últimas semanas he leído un montón de interpretaciones distintas en el foro.
Y ojo, que esto es solo para el error 2005. El problema está en saber con qué errores se puede subsanar y con cuales rectificar.

Volviendo a este tema, he estado haciendo más pruebas con registros "Rechazados" o "Aceptados con errores", a ver cómo se comporta el sistema y decidir qué hacer con cada caso.

Caso 1: Registro "Incorrecto"
- Hago una factura que tenga algún problema. En concreto, error 1111: El campo CodigoPais es obligatorio cuando IDType es distinto de 02
- Creo el RF y lo envío
- Hacienda devuelve "Incorrecto" y el error. Es decir, la rechaza.

Aquí debería hacer una subsanación: nuevo RF indicando Subsanacion = S + RechazoPrevio = X

Pero lo cierto es que la puedo volver a enviar sin indicar subsanación, etc. Me la acepta como Correcta.
Entiendo que Hacienda dice "ok, esta factura no la tengo, entiendo que es nueva".
O eso, o por ahora están ignorando esta validación.

Caso 2: Registro "AceptadoConErrores"
- Hago una factura que tenga algún error que se acepte con errores (por ejemplo, el 2005)
- Creo el RF y lo envío
- Hacienda devuelve "AceptadoConErrores". La acepta, y le consta, pero hay algo "revisable".

Corrijo el error y la envío como Subsanación = S RechazoPrevio = N
La acepta. Todos contentos.

Llegados a este punto, la verdad es que me estoy planteando seriamente exigir siempre rectificativas y punto. Es un lío considerar todas las opciones y encima que sea lo más intuitivo posibles para los usuarios.

Yo estoy de acuerdo. Por otro lado ahora mismo cuela casi todo como subsanación cuando no debe de ser correcto. Como la mayoría de las veces serán temas que habrá que generar una rectificativa, para los muy pocos casos en los que se pueda subsanar casi que es mejor obligar a rectificar.


Saludos.

Pero entonces estarías incumpliendo el reglamento, si emites un nuevo RF de Alta Nueva cada vez que te rechazan la factura, da que pensar que estás permitiendo modificar tu factura en el SIF tantas veces como quieras hasta que te la Acepte hacienda. El reglamento te insta a que si ha surgido un rechazo, lo tenga que solucionar mediante una subsanación o una rectificación posterior. En teoría, SÓLO, debería haber un Registro de facturación de alta nueva por cada factura. Ten encuenta que, qunque te rechacen el registro, no sabes con qué información de control se están quedando ellos.

Si, eso está claro. Lo que quiero decir es que aunque no indiques "Subsanación = S", te la aceptan, y no deberían. Deberían requerir indicar "subsanación = S", pero no lo están haciendo.
Obviamente mi intención es enviarla como subsanación, pero haciendo pruebas me pareció raro que las aceptaran sin indicarlo.

Vamos, que siendo tan tiquismiquis con todo lo demás, me parece raro que con esto se lo estén saltando, al menos por ahora.