Cómo remitir Registros de Facturación que son incorrectos por un error n el algortimo

[austral_es]

Buenos días

Pongamos en el caso de que tenemos un error en nuestro algoritmo por cualquier circunstancia especial que no teníamos contemplada, el registro de facturación que habíamos generado estaba bien pero a la hora de remitir faltaba cualquier dato y la AEAT nos responde con un estado Incorrecto. El registro no ha sido grabado en la AEAT.

Ahora bien, corregimos el error en nuestro algoritmo pero ¿como se vuelve a remitir este registro?, según lo que pienso deberíamos crear un nuevo Registro de facturación y mandarlo con Subsanación "S" y rechazo previo "X", dejando el registro original sin tocar. Es decir subsanación por rechazo de alta.

Otra teoría seria mandar el registro original marcándolo como antes con Subsanación "S" y rechazo previo "X".

¿Vosotros cómo afrontais esto?

[gcqZW]

Esto pone en el documento de validación de errores:

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.

Según entiendo yo tienes que pasarle los mismos datos añadiendo subsanación y rechazo previo, aunque también entiendo que si por algún casual querrías modificar algún dato subsanable lo podrías modificar en ese envio.

[Neftali [Germán.Estévez]]

Empezado por austral_es

a la hora de remitir faltaba cualquier dato y la AEAT nos responde con un estado Incorrecto. El registro no ha sido grabado en la AEAT.

según lo que pienso deberíamos crear un nuevo Registro de facturación y mandarlo con Subsanación "S" y rechazo previo "X", dejando el registro original sin tocar. Es decir subsanación por rechazo de alta.

Otra teoría seria mandar el registro original marcándolo como antes con Subsanación "S" y rechazo previo "X".

Respondiendo por partes según lo que yo creo:

1) Creo que debes generar un nuevo registro de factiuración, porque entre ambos envíos se pueden haber generado otros que ya están encadenados.
2) Debes enviar una Subsanación (que es el mismo registro de alta, pero con la S -registro completo-)
3) Es sin RegistroPrevio
4) Es con RechazoPrevio

(cambio los últimos puntos porque es un lío cuando hay que enviar esas marcas y cómo)

      <sum1:Subsanacion>S</sum1:Subsanacion>
      <sum1:RechazoPrevio>X</sum1:RechazoPrevio>

[gcqZW]

No había tenido en cuenta que podrías haber seguido facturando otros registros mientras tanto, haz caso a neftali.

[[newtron]]

Empezado por Neftali [Germán.Estévez]

Respondiendo por partes según lo que yo creo:

1) Creo que debes generar un nuevo registro de factiuración, p orque entre ambos envíos se pueden haber generado otros que ya están encadenados.
2) Debes enviar una Subsanación (que es el mismo registro de alta, pero con la S -registro completo-)
3) Es sin RegistroPrevio
4) Es con RechazoPrevio

(cambio los últimos puntos porque es un lío cuando hay que enviar esas marcas y cómo)

      <sum1:Subsanacion>S</sum1:Subsanacion>
      <sum1:RechazoPrevio>X</sum1:RechazoPrevio>

¿Cuando hablas de "un nuevo registro de facturación" te refieres a la misma factura que la vuelves a enviar con el encadenamiento actualizado o a una factura rectificativa totalmente nueva? Yo tampoco acabo de aclararme cómo plasmar toda esta ñapa en mi programa.


Gracias y un saludo.

[Neftali [Germán.Estévez]]

Empezado por newtron

¿Cuando hablas de "un nuevo registro de facturación" te refieres a la misma factura que la vuelves a enviar con el encadenamiento actualizado o a una factura rectificativa totalmente nueva? Yo tampoco acabo de aclararme cómo plasmar toda esta ñapa en mi programa.

Son 2 situaciones:
1) Una factura que es correcta, pero que el programa (por un error) la genera mal y la aEAT la rechaza.
2) Una factura que es incorrecta y la aEAT la rechaza.


1) El usuario no puede corregir la factura (porque la factura es si está bien, es el programa que tiene un error); En este caso no tiene sentido que el usuario haga una rectificativa porque la factura a ojos del usuario es correcta.
==> Cuando el programa tenga corregido el error, se se genera un nuevo registro de facturacion y se envía (subsanación, PorRechazo,...)


2) En este caso el usuario si debe generar una rectificativa.
==> Igualmente el programa genera un nuevo registro de facturación y se envía (subsanación, PorRechazo,...)

El resultado es el mismo, pero la forma de actuar no.

No se si me explico...

[[newtron]]

Empezado por Neftali [Germán.Estévez]

Son 2 situaciones:
1) Una factura que es correcta, pero que el programa (por un error) la genera mal y la aEAT la rechaza.
2) Una factura que es incorrecta y la aEAT la rechaza.


1) El usuario no puede corregir la factura (porque la factura es si está bien, es el programa que tiene un error); En este caso no tiene sentido que el usuario haga una rectificativa porque la factura a ojos del usuario es correcta.
==> Cuando el programa tenga corregido el error, se se genera un nuevo registro de facturacion y se envía (subsanación, PorRechazo,...)


2) En este caso el usuario si debe generar una rectificativa.
==> Igualmente el programa genera un nuevo registro de facturación y se envía (subsanación, PorRechazo,...)

El resultado es el mismo, pero la forma de actuar no.

No se si me explico...

Te explicas te explicas... Mi problema está en distinguir un supuesto de otro porque hay bastantes variantes y hay que acotar de forma clara cuando se puede enviar una subsanación sobre la misma factura o cuando hay que hacer una rectificativa.

Edito (no sé si esto debería ir en este hilo o en otro). Si se hace una rectificativa entiendo que la factura rectificada se queda como está y se genera otra supuestamente corregida. Al final se quedan las dos facturas para lo mismo "mareando" por la tabla y eso me dispersa un poco para todo el tema de informes. ¿Qué hacéis? ¿manteneis las dos facturas en la tabla? ¿anulais la rectificada? ¿pasais la rectificada a otro lado para que no estorbe?

[austral_es]

Empezado por newtron

Te explicas te explicas... Mi problema está en distinguir un supuesto de otro porque hay bastantes variantes y hay que acotar de forma clara cuando se puede enviar una subsanación sobre la misma factura o cuando hay que hacer una rectificativa.

Edito (no sé si esto debería ir en este hilo o en otro). Si se hace una rectificativa entiendo que la factura rectificada se queda como está y se genera otra supuestamente corregida. Al final se quedan las dos facturas para lo mismo "mareando" por la tabla y eso me dispersa un poco para todo el tema de informes. ¿Qué hacéis? ¿manteneis las dos facturas en la tabla? ¿anulais la rectificada? ¿pasais la rectificada a otro lado para que no estorbe?

Si te refieres a que en la tabla de Registros de facturación nuestras (no la de la AEAT) nos quedan dos registros de facturación de una misma factura (uno como incorrecto y otro como subsanado y correcto), nosotros hemos creado un campo boolean en la tabla de registros de facturación que indica si es el registro final de la factura o no. En este caso el primer registro (que era el incorrecto) tiene el valor false, y el segundo correcto tiene el valor true.

Así es muy fácil listar para el usuario un solo registro de facturación por factura (con un WHERE RegistroFinal = True)

[delphiGar]

Tanto si ha habido rechazo como si no, si queremos mandar un nuevo registro de la misma factura para bien corregir ( Subsanar ) cualquier cosa o por que lo han rechazado ( Subsanar y RechazoPrevio ) siempre sera un registro de facturacion nuevo, con huellas distintas al original. Contendra la ultima huella valida y la nueva huella generada.

Estos son los tres casos:

Sin Rechazo ( Existe el Registro ):

Subsanacion = S
RechazoPrevio =N

Con rechazo( No existe el Registro ):

Subsanacion = S
RechazoPrevio = X

con rechazo( Existe el Registro ):

Subsanacion = S
RechazoPrevio = S

[austral_es]

Empezado por Neftali [Germán.Estévez]

Respondiendo por partes según lo que yo creo:

1) Creo que debes generar un nuevo registro de factiuración, p orque entre ambos envíos se pueden haber generado otros que ya están encadenados.
2) Debes enviar una Subsanación (que es el mismo registro de alta, pero con la S -registro completo-)
3) Es sin RegistroPrevio
4) Es con RechazoPrevio

(cambio los últimos puntos porque es un lío cuando hay que enviar esas marcas y cómo)

      <sum1:Subsanacion>S</sum1:Subsanacion>
      <sum1:RechazoPrevio>X</sum1:RechazoPrevio>

Muchas gracias a los dos, Neftali, entiendes la diferencia entre Rechazo previo entre "S" y "X", en los dos casos la documentación dice que el registro ha sido rechazado por la AEAT, he hecho pruebas enviando un registro de subsanación y he obtenido:

1) Caso 1, se envía como Subsanación="S" y RechazoPrevio = "S" -> Respuesta: Incorrecta, error 3002 "No existe el registro de facturación."

2) Caso 2, se envía como Subsanación="S" y RechazoPrevio = "X" -> Respuesta: Correcta.

Por tanto, ¿en qué casos habría que enviar un RechazoPrevio = "S"?

Muchas gracias por vuestro tiempo

[gcqZW]

Por tanto, ¿en qué casos habría que enviar un RechazoPrevio = "S"?

ALTA POR RECHAZO DE SUBSANACIÓN, ANULACIÓN POR RECHAZO y ANULACIÓN POR RECHAZO SIN REGISTRO PREVIO.
Basicamente todas las que te rechazan que no sean alta normal o alta por rechazo de subsanacion sin registro previo.

Como no, la respuesta de neftali te lo dejará mas claro.

[Neftali [Germán.Estévez]]

RechazoPrevio=N
=> No ha habido rechazo previo por la AEAT.

RechazoPrevio=S
=>Ha habido rechazo previo por la AEAT.

RechazoPrevio=X
=>Independientemente de si ha habido o no algún rechazo previo por la AEAT, el registro de facturación no existe en la AEAT (registro existente en ese SIF o en algún SIF del obligado tributario y que no se remitió a la AEAT, por ejemplo, al acogerse a Veri*factu desde no Veri*factu). No deberían existir operaciones de alta (N,X), por lo que no se admiten.

[Neftali [Germán.Estévez]]

Sólo hay un caso (que yo sepa) en que el programa debe enviar el mismo registro de facturación original (reenviar el mismo).
Cuando no ha habido comunicación con la AEAT (fallo eléctrico, servicios de la AEAT caídos, error internet,...)

=> En ese caso se vuelve a enviar el mismo Registro de facturación original marcando el envío con INCIDENCIA.