Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[espinete]

Olvidé la segunda consideración, que eran dos

Más bien es una duda. Veo que si subo una factura que es "Parcialmente correcta", ya consta como enviada, así que la única opción para corregirla es "anularla/subsanarla". ¿Es correcto?

Por ejemplo, envié una factura en la que "el importe total no coincide con la suma de las cuotas, importes, etc." (o algo así). La aceptó. Parcialmente, pero la aceptó.

En estos casos entiendo que lo mejor es evitar que se dé el caso. Pero si se diera, la única opción que queda ahora sería anularla y enviar una nueva? con otro número o con el mismo que tenía la incorrecta?

En los casos en los que simplemente la respuesta es "Incorrecta", simplemente con corregir lo que falle y volver a enviarla de nuevo es suficiente, no? Cuando da "incorrecto" a Hacienda no le consta como subida aún.

[pablog2k]

Empezado por espinete

Olvidé la segunda consideración, que eran dos

Más bien es una duda. Veo que si subo una factura que es "Parcialmente correcta", ya consta como enviada, así que la única opción para corregirla es "anularla/subsanarla". ¿Es correcto?

Por ejemplo, envié una factura en la que "el importe total no coincide con la suma de las cuotas, importes, etc." (o algo así). La aceptó. Parcialmente, pero la aceptó.

En estos casos entiendo que lo mejor es evitar que se dé el caso. Pero si se diera, la única opción que queda ahora sería anularla y enviar una nueva? con otro número o con el mismo que tenía la incorrecta?

En los casos en los que simplemente la respuesta es "Incorrecta", simplemente con corregir lo que falle y volver a enviarla de nuevo es suficiente, no? Cuando da "incorrecto" a Hacienda no le consta como subida aún.

exacto, si no consta como subida, se sube de nuevo. Si da Aceptada con errores ,se corrige la propia factura y se sube como subsanación

[espinete]

Empezado por pablog2k

exacto, si no consta como subida, se sube de nuevo. Si da Aceptada con errores ,se corrige la propia factura y se sube como subsanación

A ver si no me estoy liando...

Factura "Correcta" (sin errores/avisos):
- Consta como enviada
- No se podrá volver a subir porque Hacienda dirá que está duplicada
- No hay que hacer nada. Guardamos el registro, lo marcamos como "aceptado/enviado", ya tendremos el QR, etc.

Factura "Parcialmente Correcta":
- Consta como enviada
- No se podrá volver a subir de forma "normal". Hay que subirla como "subsanación".
- Habría que marcarla como "subida pero con errores" para evitar que se vuelva a subir como factura normal y exigir que sea una subsanación

Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

¿Es más o menos eso? Es que con lo de anular, subsanar, corregir, resubir, etc. todavía no me aclaro del todo cuándo se hace una cosa y cuándo otra. Será cuestión de hacer muchas pruebas e ir "aprendiendo" según vea los resultados.

[pablog2k]

correcto en todo lo que has dicho.
Anular realmente es dar una factura como errónea , que es cuando según la ley no puedes hacer una rectificativa para arreglar.

[rci]

Empezado por espinete

A ver si no me estoy liando...

Factura "Correcta" (sin errores/avisos):
- Consta como enviada
- No se podrá volver a subir porque Hacienda dirá que está duplicada
- No hay que hacer nada. Guardamos el registro, lo marcamos como "aceptado/enviado", ya tendremos el QR, etc.

Factura "Parcialmente Correcta":
- Consta como enviada
- No se podrá volver a subir de forma "normal". Hay que subirla como "subsanación".
- Habría que marcarla como "subida pero con errores" para evitar que se vuelva a subir como factura normal y exigir que sea una subsanación

Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

¿Es más o menos eso? Es que con lo de anular, subsanar, corregir, resubir, etc. todavía no me aclaro del todo cuándo se hace una cosa y cuándo otra. Será cuestión de hacer muchas pruebas e ir "aprendiendo" según vea los resultados.

Yo tengo una duda sobre el caso "incorrecta".
Entiendo que si al enviar hay algún error en la conexión, en los servidores de AEAT, ... con volver a intentar el envío ya se soluciona porque la factura ya está bien.
Pero en el caso que AEAT contesta y rechaza, es porque o tienes mal el XML o hay algún error no aceptable en la factura y debes corregirlo.
Bien pues aquí tengo la duda, en teoría, una factura no la puedes modificar no?
Si es un error del programa que ha generado mal el xml pues supongo que modificas el programa urgentemente para que genere bien el xml y lo vuelves a enviar.
Pero si lo que está mal son los datos de la factura?
Ya se, no tendría que permitir que un usuario guarde una factura con datos mal pero... y si pasa?
Creo que no puedo permitir al usuario modificar la factura para cambiar alguna información incorrecta... no?

O me estoy liando?

Muchas gracias!

[rci]

Empezado por Franche

Entonces si envio una factura y me devuelve un error , por ejemplo con el NIF del cliente, ¿puedo editar la factura, guardarla y volver a enviar ?

Empezado por bmfranky

Si, pero has de volver a enviarla codificando alta por rechazo.

bmfranky estás seguro?

Alguien piensa que NO se puede modificar una factura una vez salvada? Creia que era la base de la ley anti fraude pero a lo mejor me confundo.

Por aquí venia mi duda en un post anterior que quedó sin respuesta:

Empezado por rci

Yo tengo una duda sobre el caso "incorrecta".
Entiendo que si al enviar hay algún error en la conexión, en los servidores de AEAT, ... con volver a intentar el envío ya se soluciona porque la factura ya está bien.
Pero en el caso que AEAT contesta y rechaza, es porque o tienes mal el XML o hay algún error no aceptable en la factura y debes corregirlo.
Bien pues aquí tengo la duda, en teoría, una factura no la puedes modificar no?
Si es un error del programa que ha generado mal el xml pues supongo que modificas el programa urgentemente para que genere bien el xml y lo vuelves a enviar.
Pero si lo que está mal son los datos de la factura?
Ya se, no tendría que permitir que un usuario guarde una factura con datos mal pero... y si pasa?
Creo que no puedo permitir al usuario modificar la factura para cambiar alguna información incorrecta... no?

O me estoy liando?

Muchas gracias!

MUCHAS GRACIAS !

[bmfranky]

Empezado por rci

bmfranky estás seguro?

Alguien piensa que NO se puede modificar una factura una vez salvada? Creia que era la base de la ley anti fraude pero a lo mejor me confundo.

Por aquí venia mi duda en un post anterior que quedó sin respuesta:




MUCHAS GRACIAS !

ALTA POR RECHAZO
· Al ta por recha zo del regi s tro de fa ctura ci ón de a lta
i ni cia l (y que, por tanto, no exis te a ún en l a AEAT).


· Es l a s ubs a na ción de da tos de un regi s tro de
fa ctura ci ón de a l ta i ni ci a l, cua ndo no s e exi ge l a
emis i ón de una fa ctura rectifica tiva (u otro
meca ni s mo contempl a do en el Regl a mento de
Fa ctura ci ón).


· <Subs a na ci on>=S
· <Recha zoPrevi o>=X · VERI*FACTU


· La cla ve úni ca del regis tro de fa ctura ci ón no
debe exi s tir previa mente en la AEAT.


· El a lta previ a del regis tro de fa ctura ción fue
recha za da .


Alta del regis tro de fa ctura ci ón con los
nuevos da to

Interpreto que seria este caso.

[Delphier]

Os lo pongo , Por si le sirve a alguien como Idea o como ayuda.


El componente Requiere Delphi 12 , me baso en enviar XML preparados previamente almacenados con un certificado también almacenado en el software.

Bàsicamente le cargamos el certificado , el password un XML y lo enviamos.

unit VerifactuHTTPRIO;

interface

uses
  System.SysUtils,
  System.Classes,
  Soap.Rio,
  Dialogs,
  Xml.XMLDoc,
  Xml.XMLIntf,
  Soap.SOAPHTTPClient,
  Soap.SOAPHTTPTrans;



type

  TBeforeExecuteEvent = procedure(const MethodName: string; SOAPRequest: TStream) of object;
  TAfterExecuteEvent  = procedure(const MethodName: string; SOAPResponse: TStream) of object;

  TVerifactuHTTPRIO = class(THTTPRIO)


  private
    { Private declarations }
    FCertificate    : TMemoryStream;
    FCertPassword   : String;
    FXMLRequest     : TStringList;
    FXMLResponse    : TStringList;
    FOnAfterExecute : TAfterExecuteEvent;
    FOnBeforeExecute: TBeforeExecuteEvent;
    function StreamToString(aStream: TStream): string;
  protected
    { Protected declarations }
    procedure DoAfterExecute(const MethodName: string; Response: TStream); override;
    procedure DoBeforeExecute(const MethodName: string; Request: TStream); override;
  public
    { Public declarations }
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
  published
    { Published declarations }
    property OnAfterExecute: TAfterExecuteEvent read FOnAfterExecute write FOnAfterExecute;
    property OnBeforeExecute: TBeforeExecuteEvent read FOnBeforeExecute write FOnBeforeExecute;
    property Certificate   : TMemoryStream  read FCertificate write FCertificate;
    property CertPassword  : String  read FCertPassword write FCertPassword;
    property XMLRequest    : TStringList  read FXMLRequest write FXMLRequest;
    property XMLResponse   : TStringList  read FXMLResponse write FXMLResponse;

  end;

procedure Register;

implementation


constructor TVerifactuHTTPRIO.Create(AOwner: TComponent);
Begin
  Inherited Create(Aowner);

  FCertificate := TMemoryStream.Create;
  FXMLRequest  := TStringList.Create;
  FXMLResponse := TStringList.Create;

End;

destructor TVerifactuHTTPRIO.Destroy;
begin

  FCertificate.Free;
  FXMLRequest.Free;
  FXMLResponse.Free;

  inherited;
end;


procedure TVerifactuHTTPRIO.DoBeforeExecute(const MethodName: string; Request: TStream);
begin

  // Si hay XMLRequest la enviamos
  if FXMLRequest.Count > 0 then
  Begin
     Request.Position := 0; // Importante
     FXMLRequest.SaveToStream(Request);
  End;


  // Cetificado
  HTTPWebNode.ClientCertificate.Stream   := Certificate;
  HTTPWebNode.ClientCertificate.Password := CertPassword;


  if Assigned(FOnBeforeExecute) then
  begin
    FOnBeforeExecute(MethodName, Request);
    Request.Position := 0;
  end;

end;

procedure TVerifactuHTTPRIO.DoAfterExecute(const MethodName: string; Response: TStream);
var RespuestaXML : String;
begin

  // Asignamos la respuesta y Maquillamos XML
  RespuestaXML := StreamToString(Response);

  RespuestaXML := Xml.XMLDoc.FormatXMLData(RespuestaXML);

  FXMLResponse.Text := RespuestaXML;


  if Assigned(FOnAfterExecute) then
  begin
    FOnAfterExecute(MethodName, Response);
    Response.Position := 0;
  end;

end;


function TVerifactuHTTPRIO.StreamToString(aStream: TStream): string;
var
  SS: TStringStream;
begin
  if aStream <> nil then
  begin
    SS := TStringStream.Create('');
    try
      SS.CopyFrom(aStream, 0);
      Result := SS.DataString;
    finally
      SS.Free;
    end;
  end else
  begin
    Result := '';
  end;
end;


procedure Register;
begin
  RegisterComponents('Componentes Verifactu', [TVerifactuHTTPRIO]);
end;

end.

Como Usar:

procedure TFormSoap.Button2Click(Sender: TObject);
var direccion_envio : String;
begin


direccion_envio := 'https://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP';

// Cargar el certificado
VerifactuRIO.Certificate.LoadFromFile('MiCertificado.pfx');
VerifactuRIO.CertPassword := '1234';


// Cargar el XMl  enviar , de fichero o de texto
VerifactuRIO.XMLRequest.LoadFromFile('XML_Envio_Verifactu.xml');

// Llamada
GetsfPortTypeVerifactu(False, direccion_envio, VerifactuRIO).RegFactuSistemaFacturacion(nil);

// Aquí tenemnos la respues
VerifactuRIO.XMLResponse.Text;

end;

Un Saludo

[espinete]

Empezado por espinete

Factura "Correcta" (sin errores/avisos):
- Consta como enviada
- No se podrá volver a subir porque Hacienda dirá que está duplicada
- No hay que hacer nada. Guardamos el registro, lo marcamos como "aceptado/enviado", ya tendremos el QR, etc.

Factura "Parcialmente Correcta":
- Consta como enviada
- No se podrá volver a subir de forma "normal". Hay que subirla como "subsanación".
- Habría que marcarla como "subida pero con errores" para evitar que se vuelva a subir como factura normal y exigir que sea una subsanación

Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

Volviendo a este tema, que me sigue generando alguna duda...

¿Cómo sabemos si una factura "Parcialmente Correcta", que se ha aceptado con errores/avisos, se debe subsanar/anular o rectificar? ¿No sería MÁGICO que la propia AEAT devolviera un campo indicando "se requiere subsanación" o "se requiere rectificativa"? Vamos, yo lo veo.

Pero como no lo van a hacer... ¿Cómo sabemos cómo actuar? ¿Teniendo una lista de las decenas de errores posibles y según cada caso, actuar en consecuencia, viendo qué error es en cada caso, etc.?

Porque queda claro que las facturas NO pueden modificarse (para eso estaba la ley antifraude, no?) Hay que rectificarlas.
Entonces... ¿en qué casos concretos se debe hacer una "subsanación" y no una rectificativa?

¿Podría ser algo así:

- Rectificativas: si cambia el importe de la factura, datos fiscales, algún dato erróneo, etc. (en definitiva, contenido de la factura incorrecto)
- Subsanación: error al generar el XML o el envío, no relacionado con el contenido de la factura (error en la huella, encadenamiento, algún dato mal informado...)

¿Es correcto?

¿Aparte de rectificativa y subsanación, hay algo más?

[sglorka]

Empezado por espinete

Volviendo a este tema, que me sigue generando alguna duda...

¿Cómo sabemos si una factura "Parcialmente Correcta", que se ha aceptado con errores/avisos, se debe subsanar/anular o rectificar? ¿No sería MÁGICO que la propia AEAT devolviera un campo indicando "se requiere subsanación" o "se requiere rectificativa"? Vamos, yo lo veo.

Pero como no lo van a hacer... ¿Cómo sabemos cómo actuar? ¿Teniendo una lista de las decenas de errores posibles y según cada caso, actuar en consecuencia, viendo qué error es en cada caso, etc.?

Porque queda claro que las facturas NO pueden modificarse (para eso estaba la ley antifraude, no?) Hay que rectificarlas.
Entonces... ¿en qué casos concretos se debe hacer una "subsanación" y no una rectificativa?

¿Podría ser algo así:

- Rectificativas: si cambia el importe de la factura, datos fiscales, algún dato erróneo, etc. (en definitiva, contenido de la factura incorrecto)
- Subsanación: error al generar el XML o el envío, no relacionado con el contenido de la factura (error en la huella, encadenamiento, algún dato mal informado...)

¿Es correcto?

¿Aparte de rectificativa y subsanación, hay algo más?

Por aportar algo más.

Factura "Correcta" (sin errores/avisos):
- Consta como enviada
- No se podrá volver a subir porque Hacienda dirá que está duplicada
- No hay que hacer nada. Guardamos el registro, lo marcamos como "aceptado/enviado", ya tendremos el QR, etc.

Se puede seguir emitiendo subsanaciones a posteriori, por ejemplo, te das cuenta de que el Régimen tributario lo habías enviado mal.

Factura "Parcialmente Correcta":
- Consta como enviada
- No se podrá volver a subir de forma "normal". Hay que subirla como "subsanación".
- Habría que marcarla como "subida pero con errores" para evitar que se vuelva a subir como factura normal y exigir que sea una subsanación
Correcto

Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

No puedes volver a subirla, debes emitir una "Subsanación x Rechazo Previo" siempre y cuando te venga un código de error dentro del objeto respuesta (la Aeat la recibió y la rechazó.). Si este objeto viene vacío, indica que la Aeat no la ha recibido y por ende, no la ha rechazado, entonces sí debes de reenviar pero en orden cronológico de generación de registros, o sea, antes un fallo de comunicaciones debes parar los envíos, no puedes permitir mandar un primer registro, te fallan las comunicaciones en el segundo y sigues intentándolo y sí, te entra el tercero.

Para saber si se debe emitir una Rectificativa o una Subsanación, yo estoy agrupando los códigos de error en tres bloques, un bloque donde seguro que es una rectificativa (errores desde el 1162 al 1170 y otros errores donde se referencia el Nif del destinatario), otro en que seguro que es una subsanación (la mayoría) y un tercero donde ambas opciones podrían ser válidas, por ejemplo, Nif no censado se puede arreglar con una rectificativa poniendo bien su Nif o con una subsanación, añadiendo la clave IdOtro con indicación de No Censado.

[espinete]

Empezado por sglorka

Factura "Incorrecta":
- NO consta como enviada
- Habría que marcarla como "Error" para saber que podemos volver a intentarlo
- Podemos arreglar lo que sea que haya dado error y volver a subirla, hasta que devuelva "Correcta" o "Parcialmente correcta"

No puedes volver a subirla, debes emitir una "Subsanación x Rechazo Previo" siempre y cuando te venga un código de error dentro del objeto respuesta (la Aeat la recibió y la rechazó.). Si este objeto viene vacío, indica que la Aeat no la ha recibido y por ende, no la ha rechazado, entonces sí debes de reenviar pero en orden cronológico de generación de registros, o sea, antes un fallo de comunicaciones debes parar los envíos, no puedes permitir mandar un primer registro, te fallan las comunicaciones en el segundo y sigues intentándolo y sí, te entra el tercero.

En este último caso, en efecto habría que saber si fue un error "en el envío" o si efectivamente fue rechazada por Hacienda (la recibió pero la rechazó).
Si el error es en el envío, obviamente habría que reintentar el envío. Si fue rechazada por Hacienda (está enviada pero la rechazó por algún error), habría que enviar subsanación.

Correcto?

Hay que hacer muchas pruebas de todo tipo para entender el funcionamiento al 100%, y aún así seguro que algún caso concreto se me escapa...

Empezado por sglorka

Para saber si se debe emitir una Rectificativa o una Subsanación, yo estoy agrupando los códigos de error en tres bloques, un bloque donde seguro que es una rectificativa (errores desde el 1162 al 1170 y otros errores donde se referencia el Nif del destinatario), otro en que seguro que es una subsanación (la mayoría) y un tercero donde ambas opciones podrían ser válidas, por ejemplo, Nif no censado se puede arreglar con una rectificativa poniendo bien su Nif o con una subsanación, añadiendo la clave IdOtro con indicación de No Censado.

Creo que es la mejor (o única) forma de hacerlo, y mostrar un mensaje en pantalla al usuario para que sepa lo que tiene que hacer y por qué. Con TicketBAI olvidamos esta parte y no hacían más que llamarnos para preguntar "qué hacemos ahora". Y luego nosotros a rebanarnos el coco, primero intentando averiguar qué hicieron y después para decirles cómo corregir cada caso.

Sin duda lo mejor es dejarlo todo masticadito a los usuarios para evitarnos dolores de cabeza más tarde.

[bmfranky]

Empezado por espinete

En este último caso, en efecto habría que saber si fue un error "en el envío" o si efectivamente fue rechazada por Hacienda (la recibió pero la rechazó).
Si el error es en el envío, obviamente habría que reintentar el envío. Si fue rechazada por Hacienda (está enviada pero la rechazó por algún error), habría que enviar subsanación.

Correcto?

Hay que hacer muchas pruebas de todo tipo para entender el funcionamiento al 100%, y aún así seguro que algún caso concreto se me escapa...



Creo que es la mejor (o única) forma de hacerlo, y mostrar un mensaje en pantalla al usuario para que sepa lo que tiene que hacer y por qué. Con TicketBAI olvidamos esta parte y no hacían más que llamarnos para preguntar "qué hacemos ahora". Y luego nosotros a rebanarnos el coco, primero intentando averiguar qué hicieron y después para decirles cómo corregir cada caso.

Sin duda lo mejor es dejarlo todo masticadito a los usuarios para evitarnos dolores de cabeza más tarde.

Hola, buenos dias, ya lo he comentado con anterioridad, pero si solucionas la incidencia y reenvias, sin marcar que es reenviada tras rechazo (Subsanacion), ni nada, la acepta ok, sin mas, no se si sera que no lo estan controlando al ser el servidor de prueba, o realmente no lo estan teniendo en cuenta de ninguna forma, no se creo que el servidor tendria que tenerlo en cuenta y responder algo asi como aceeptada la "Reparacion " o parecido, para saber que lo han tenido en cuenta...

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

Empezado por espinete

Veo que si subo una factura que es "Parcialmente correcta", ya consta como enviada, así que la única opción para corregirla es "anularla/subsanarla". ¿Es correcto?

Si.
Lo suyo sería subsanarla, la ley de facturación estipula sólo una causas por las que se puede "anular" una factura (se pueden buscar).

Empezado por espinete

En estos casos entiendo que lo mejor es evitar que se dé el caso. Pero si se diera, la única opción que queda ahora sería anularla y enviar una nueva? con otro número o con el mismo que tenía la incorrecta?

Yo creo que mandas una subsanación, que una modificación de la factura original.

Empezado por espinete

En los casos en los que simplemente la respuesta es "Incorrecta", simplemente con corregir lo que falle y volver a enviarla de nuevo es suficiente, no? Cuando da "incorrecto" a Hacienda no le consta como subida aún.

Correcto.