Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por nuevo1234

Cuando se guardan deben ir firmados. Entiendo q la firma ya garantiza q no se modifica después. Vendrá el día y la hora en la firma o algo asi

Una firma solo garantiza que el firmante (él que tiene la clave privada del certificado de firma) tenía a mano los datos firmados.
Si después de la (primera) firma, los datos se modifican fuera del poder del firmante, entonces la firma resultará inválida; pero técnicamente los datos modificados se pueden supuestamente firmar de nuevo (nota: es delito hacerlo; también es delito proponer de hacerlo) si lo hace el firmante...

El día o la hora no vienen en la firma; solo se puede añadir una marca (o sello) de tiempo a lo que se está firmando.

Si usas Veri*factu, la firma la realiza efectivamente Hacienda y sus sistema dan la hora y por tanto Hacienda tiene la garantía que los datos no se modifican en el momento de la generación.
Si es otra clase de SIF, el programador puede añadir una marca de tiempo a la hora de firmar; así sí se garantiza que no se modifican después (a no ser que se manipulen las marcas de tiempo; otro probable delito). Pero la marca de tiempo no es una obligación en lo que sabemos ahora de las especificaciones, entre otras cosas porque no hay un sistema de marca de tiempo disponible que resulte de agradecimiento tanto de Hacienda como de todos los grandes productores de software.

[antoine0]

Empezado por sglorka

[aplicar VERI*FACTU] Pero esa decisión es del cliente, no nuestra.

¿Uh? ¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?

Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores.

[sglorka]

Empezado por antoine0

¿Uh? ¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?

Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores.

No entiendo lo que dices

[antoine0]

Empezado por sglorka

¿Nos están pidiendo algún método técnico fiable parecido para los clientes que informan sólo por requerimiento (no Verifactu) de que los registros que vamos a enviarle son los originales generados en el preciso momento de expedir la factura?

Técnicamente, el Reglamento está redactado al revés: dice que los sistemas de Hacienda cumplen al menos las mismas normas (artículos 16.1 y 16.4). Dicho de otra forma, que no se puede pedir a los productores más de lo que ofrece Hacienda (y ya es algo). Entonces no exactamente parecido; de hecho no hay comparación entre los métodos técnicos.

Luego, los artículos 8.2 a y b obligan a usar un «proceso técnico fiable» y a que «Todos los datos registrados deberán encontrarse correctamente fechados, indicando el momento en que se efectúa el registro.» Si por «registros originales» tu entiendes «registros con los datos originalmente grabados», entonces sí, están pidiendo esto (con la excepción de la palabra «parecido»); tanto a Hacienda para la aplicación quien soporta Veri*factu como a cualquier otro proveedor de SIF que usan el método del registro local encadenado y firmado.

[antoine0]

A ver si me explico mejor... (la énfasis es mía)

Empezado por sglorka

Estoy de acuerdo en que lo más sencillo es aplicar VERI*FACTU ya que según reza en el reglamento, se le supondría que se cumple con éste sólo por remitir de forma instantánea y continua los registros. Pero esa decisión es del cliente, no nuestra. Si el cliente decide remitir sus registros sólo por requerimiento, debemos cumplir con los apartados, para eso nos exigen una declaración responsable.

A lo cual he contestado:

Empezado por antoine0

¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?

Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores.

Quiero decir que, al mi entender, un proveedor de SIF puede proponer, y certificar, un sistema que SOLO propone la opción de usar el sistema Veri*factu, sin la posibilidad de desactivar la remisión automática del artículo 15. Sin implementar ni firma, ni archivo de los registro (pero sí de los eventos del 8.3)

La opción la tiene el cliente; pero no dentro del ámbito del programa, sino dentro del ámbito de sus obligaciones de tributación, que es más amplia.
Por ejemplo, en el artículo 15 está escrito «podrán remitir [...] todos los registros de facturación generados por los sistemas informáticos» (mi énfasis); no «generados por [strike]el sistema informático[/strike]».

[sglorka]

Empezado por antoine0

A ver si me explico mejor... (la énfasis es mía)


A lo cual he contestado:


Quiero decir que, al mi entender, un proveedor de SIF puede proponer, y certificar, un sistema que SOLO propone la opción de usar el sistema Veri*factu, sin la posibilidad de desactivar la remisión automática del artículo 15. Sin implementar ni firma, ni archivo de los registro (pero sí de los eventos del 8.3)

La opción la tiene el cliente; pero no dentro del ámbito del programa, sino dentro del ámbito de sus obligaciones de tributación, que es más amplia.
Por ejemplo, en el artículo 15 está escrito «podrán remitir [...] todos los registros de facturación generados por los sistemas informáticos» (mi énfasis); no «generados por [strike]el sistema informático[/strike]».

Ok aclarado. En mi mente estaba que los desarrolladores de SIF deberían tener ambas opciones para ampliar el público objetivo. Pero estoy de acuerdo en que si tu solución desarrolla sólo una de ellas entonces el cliente no puede elegir.

[nuevo1234]

Empezado por sglorka

Ok aclarado. En mi mente estaba que los desarrolladores de SIF deberían tener ambas opciones para ampliar el público objetivo. Pero estoy de acuerdo en que si tu solución desarrolla sólo una de ellas entonces el cliente no puede elegir.

Entonces como proveedores podemos hacer un sistema verifactu, no verifactu o con las dos opciones. Creo que se puede explicar al cliente q un sistema no verifactu complica el tema y puede finalizar con requerimientos. Podían haber definido solo verifactu como sistema único y no enredar mas

[RUBEN_SP]

Yo creo que un SIF Veri*Factu tampoco tiene que cumplir con el Articulo 8.3 ya que al principio del BOE dice textual: "Con ser importantes, los anteriores propósitos encuentran su sentido en un objetivo aún más amplio que desde las organizaciones internacionales (OCDE y Unión Europea) han dado en llamar «cumplimiento tributario por diseño»." y luego refiriéndose al cumplimiento por diseño dice:
"Asimismo, el texto reglamentario prevé la posibilidad de que, voluntariamente, los
obligados tributarios remitan inmediatamente a la Administración tributaria, de forma
automática y segura por medios electrónicos, todos los registros de facturación
generados en sus sistemas informáticos, en cuyo caso se entenderá que esos sistemas
informáticos ya cumplen por diseño los requisitos técnicos anteriormente mencionados."
y luego en el CAPITULO III cuando habla de Sistemas de emisión de facturas verificables dice:
"A los efectos de este Reglamento, se presumirá que los «Sistemas de emisión de facturas verificables» cumplen por diseño los requisitos establecidos en el artículo 8 de este Reglamento, y por lo tanto tampoco les será de aplicación lo dispuesto en el apartado 2 del artículo 14 de este Reglamento."

[sglorka]

Empezado por RUBEN_SP

Yo creo que un SIF Veri*Factu tampoco tiene que cumplir con el Articulo 8.3 ya que al principio del BOE dice textual: "Con ser importantes, los anteriores propósitos encuentran su sentido en un objetivo aún más amplio que desde las organizaciones internacionales (OCDE y Unión Europea) han dado en llamar «cumplimiento tributario por diseño»." y luego refiriéndose al cumplimiento por diseño dice:
"Asimismo, el texto reglamentario prevé la posibilidad de que, voluntariamente, los
obligados tributarios remitan inmediatamente a la Administración tributaria, de forma
automática y segura por medios electrónicos, todos los registros de facturación
generados en sus sistemas informáticos, en cuyo caso se entenderá que esos sistemas
informáticos ya cumplen por diseño los requisitos técnicos anteriormente mencionados."
y luego en el CAPITULO III cuando habla de Sistemas de emisión de facturas verificables dice:
"A los efectos de este Reglamento, se presumirá que los «Sistemas de emisión de facturas verificables» cumplen por diseño los requisitos establecidos en el artículo 8 de este Reglamento, y por lo tanto tampoco les será de aplicación lo dispuesto en el apartado 2 del artículo 14 de este Reglamento."

Cuidado no te fíes. A mí también me pareció entender eso pero fíjate en el punto 1 del Artículo 16
[/i]Aquellos sistemas informáticos indicados en la letra a) del artículo 7 de este
Reglamento que, cumpliendo con todas las obligaciones que impone este Reglamento y
de acuerdo a las especificaciones técnicas que se establezcan[i]

O sea, por un lado dicen que si es VeriFactu no tienes que cumplir pero por otro dice que para ser VeriFactu debes cumplir con todo.

[antoine0]

Empezado por nuevo1234

Entonces como proveedores podemos hacer un sistema verifactu, no verifactu o con las dos opciones. Creo que se puede explicar al cliente q un sistema no verifactu complica el tema y puede finalizar con requerimientos.

Creo que hacer un sistema sin Veri*factu solo tiene sentido si tienes un encargo de hacerlo. Si no conoces los clientes de antemano, me parece imprescindible.

En lugar de «finalizar con requerimientos», que me parece demasiado negativo, yo pondría que la empresa que no quiere Veri*factu se está colgando a si misma una diana enorme a la atención de los inspectores de Hacienda.
Claramente está hecho para ser disuasivo, un poco como el sistema del «criterio de caja» para el IVA: algunas empresas lo necesitan de verdad y no pueden vivir sin él, pero la intención de Hacienda es que se quede marginal.

Podían haber definido solo verifactu como sistema único y no enredar mas

No. Hay muchas empresas que no entran en el ámbito del SII pero son «grandes», es decir suficientemente grandes como para tener informáticos capazos de gestionar un sistema en interno que sabe gestionar esto (o contratar a un desarrollador experimentado que sabrá hacerlo ). Y pueden tener serías razones para no enviar en tiempo real o casi real cada una de sus facturas por Internet al sistema Veri*factu; como por ejemplo si están fuera de cobertura más tiempo que pueden asumir sus clientes, o que no quieren arriesgar que las facturas viajan por HTTPS, o que el número de tiques están en los millones...

[antoine0]

Empezado por RUBEN_SP

Yo creo que un SIF Veri*Factu tampoco tiene que cumplir con el Articulo 8.3 ya que al principio del BOE dice textual [...]
y luego en el CAPITULO III cuando habla de Sistemas de emisión de facturas verificables dice:
"A los efectos de este Reglamento, se presumirá que los «Sistemas de emisión de facturas verificables» cumplen por diseño los requisitos establecidos en el artículo 8 de este Reglamento, y por lo tanto tampoco les será de aplicación lo dispuesto en el apartado 2 del artículo 14 de este Reglamento"

Todo lo que dice antes de DISPONGO no tiene efecto directo para nosotros meros mortales (está para los juristas y los jueces, y también es lectura interesantes para entender).

Luego sobre lo dicho en el artículo 16.2, no sé exactamente cómo leer «se presumirá que [...] cumplen por diseño los requisitos establecidos en el artículo 8».
Si te eximen del sistema de comunicación de los registros (14.2) sin quitarte la consultación en interactivo de los registros y de los eventos (14.1), significa que debes tener en tu programa tales archivos, de registros y de eventos, ¿no? Y el 8.3 solo dice que debe estar un registro de eventos... (y que su contenido y diseño estarán en el futuro O.M.)
Ahora bien, si resulta que el registro de eventos solo registra las operaciones de grabar, firmar, iniciar serie y poco más, es cierto que son las operaciones que se pueden deducir de los registros de Veri*fatu y por tanto efectivamente ya no es realmente necesario un registro de eventos en el programa en casa del cliente (con la condición para cumplir el 14.1 de implementar una interfaz viva de consulta del Veri*factu).

Como ya se ha dicho varias veces, en realidad debemos esperar a leer la O.M. para entender realmente como comérselo.

[antoine0]

Empezado por sglorka

fíjate en el punto 1 del Artículo 16
[/i]Aquellos sistemas informáticos indicados en la letra a) del artículo 7 de este Reglamento que, cumpliendo con todas las obligaciones que impone este Reglamento y de acuerdo a las especificaciones técnicas que se establezcan[i]

En un sistema que va con Veri*factu, en realidad el SIF está compuesto por la reunión de tu programa y del programa Veri*factu de Hacienda con su propia base de datos, su sistema de firma y sello de tiempo con los CSV etc. Lo que dice el 16.2 es que la parte requerida por el artículo 8 está en efecto cumplida por el programa Veri*factu.

[nincillo]

Empezado por iMia

Buenas a todos de nuevo,
los que hemos tenido "la suerte" de implementar el TBAI, volvemos a las andadas...

Estoy empezando a mirar la info que acaba de salir, para ver que podré aprovechar del TBAI y no puedo parsear los xsd del documento principal.

el wsdl sin problemas,

El primer xsd sí,
https://prewww2.aeat.es/static_files...nformacion.xsd


pero el resto no...

https://prewww2.aeat.es/static_files...ministroLR.xsd

ni

https://prewww2.aeat.es/static_files...Suministro.xsd


¿Os ha funcionado a los demás?

¿A qué te refieres de si os está funcionando?

Yo estoy intentando utilizarlos desde Delphi 2007 y me salta un mensaje de errro de Empty Documento cuando hago la llamada para dar de alta una factura.

Gracias.

[nincillo]

Empezado por nincillo

¿A qué te refieres de si os está funcionando?

Yo estoy intentando utilizarlos desde Delphi 2007 y me salta un mensaje de errro de Empty Documento cuando hago la llamada para dar de alta una factura.

Gracias.

Como ya han pasado más de 25 minutos ya no puedo editar el mensaje original, así que sigo en este otro post.

Estoy intentando importar los wsdl desde dos versiones diferentes de Delphi:
+ Delphi 2007, al intentar importarlos me dice: Error [Empty document].
+ Delphi 11, importar me los permite importar, pero luego, al compilar me da error en dos líneas en las que me dice que los literales de tipo string no pueden medir más de 255 caracteres y de ahí no paso.


¿Alguien los ha importado recientemente?. ¿Ha podido sin problema?

Gracias y un saludo.

Edito: He retocado las líneas que se suponen que miden demasiado (no se que implicaciones traerá luego), pero el caso es que al darle a enviar una petición, me dice "URL Pendiente de definir", con lo cual de momento tampoco podemos probar nada por este "lado".

[manelb]

Empezado por nincillo

+ Delphi 11, importar me los permite importar, pero luego, al compilar me da error en dos líneas en las que me dice que los literales de tipo string no pueden medir más de 255 caracteres y de ahí no paso.

En unes pruebas que hice hace un tiempo, recuerdo que me daba ese error de compilación.

Lo que hice en ese momento para continuar con las pruebas fue descomponer la línea en varias cadenas y funcionó. Pude compilar y continuar con mis pruebas.

Código Delphi [-]
'cadena de mas de …….  255 caracteres';

se convirtió en

Código Delphi [-]
'cadena de mas de …'+'….  255 caracteres';

Si nadie ofrece una solución más elegante, a mí me funcionó.

Saludos

[nincillo]

Empezado por manelb

En unes pruebas que hice hace un tiempo, recuerdo que me daba ese error de compilación.

Lo que hice en ese momento para continuar con las pruebas fue descomponer la línea en varias cadenas y funcionó. Pude compilar y continuar con mis pruebas.

Código Delphi [-]
'cadena de mas de …….  255 caracteres';

se convirtió en

Código Delphi [-]
'cadena de mas de …'+'….  255 caracteres';

Si nadie ofrece una solución más elegante, a mí me funcionó.

Saludos

Lo probaré... Gracias.
Pero de momento, pocas pruebas de envío se pueden hacer porque no tienen definida la url. ¿Verdad?.

[nincillo]

Empezado por nincillo

Lo probaré... Gracias.
Pero de momento, pocas pruebas de envío se pueden hacer porque no tienen definida la url. ¿Verdad?.

Me funcionó el "truco" que me sugeriste. Muchas gracias de nuevo.
Ahora he atascado en otro punto.
A ver si alguien me puede ayudar.
Estoy empezando a rellenar los diferentes apartados de la factura antes de enviarla y he atascado al llegar al punto "Desglose", que se supone que es un Array of Detail.

Este es el código que llevo desarrollado hasta ahora.

procedure TForm2.BtnEnvioFacturaClick(Sender: TObject);
var
  regFactura : FacturasEmitidasType;
  result : Array_Of_RespuestaExpedidaType;
  arrayFacturas : Array_Of_FacturasEmitidasType;
  arrayDetalles : array of DetalleType;
  detalle : DetalleType;
begin

  regFactura := FacturasEmitidasType.Create;
  regFactura.DatosControl := DatosControlType.Create;

  regFactura.RegistroFacturacion := RegistroFacturacionType.Create;

    regFactura.RegistroFacturacion.PeriodoLiquidacion := PeriodoLiquidacion.Create;
      regFactura.RegistroFacturacion.PeriodoLiquidacion.Ejercicio := '23';
      regFactura.RegistroFacturacion.PeriodoLiquidacion.Periodo := TipoPeriodoType(1); // Empieza a contar desde 0

    regFactura.RegistroFacturacion.IDFactura := IDFacturaExpedidaType.Create;
      regFactura.RegistroFacturacion.IDFactura.NumSerieFacturaEmisor := '23/123456';
      regFactura.RegistroFacturacion.IDFactura.FechaExpedicionFacturaEmisor := '31/12/23';
      regFactura.RegistroFacturacion.IDFactura.IDEmisorFactura := IDEmisorFactura2.Create;
        regFactura.RegistroFacturacion.IDFactura.IDEmisorFactura.NIF := '3333333';

    regFactura.RegistroFacturacion.DescripcionOperacion := 'vneta de mercaderías';

      regFactura.RegistroFacturacion.Desglose := DesgloseType.Create();

        detalle:= DetalleType.Create;
          detalle.CuotaRepercutida := '100';
          detalle.TipoImpositivo := '21';

        SetLength(arrayDetalles, 1);
        arrayDetalles[0] := detalle;

        regFactura.RegistroFacturacion.Desglose[0] := detalle;

  try
    SetLength(arrayFacturas, 1);
    arrayFacturas[0] := regFactura;
    result := GetsfSOAP(true, '', HTTPRIO1).AltaFactuSistemaFacturacion(arrayFacturas);
  finally
    regFactura.Destroy;
  end;


end;

[javipes]

y si pruebas con

setlength(regfactura.RegistroFacturacion.desglose,1);

antes de hacer

regFactura.RegistroFacturacion.Desglose[0] := DesgloseType.Create();

[nincillo]

Empezado por nincillo

Me funcionó el "truco" que me sugeriste. Muchas gracias de nuevo.
Ahora he atascado en otro punto.
A ver si alguien me puede ayudar.
Estoy empezando a rellenar los diferentes apartados de la factura antes de enviarla y he atascado al llegar al punto "Desglose", que se supone que es un Array of Detail.

Este es el código que llevo desarrollado hasta ahora.

procedure TForm2.BtnEnvioFacturaClick(Sender: TObject);
var
  regFactura : FacturasEmitidasType;
  result : Array_Of_RespuestaExpedidaType;
  arrayFacturas : Array_Of_FacturasEmitidasType;
  arrayDetalles : array of DetalleType;
  detalle : DetalleType;
begin

  regFactura := FacturasEmitidasType.Create;
  regFactura.DatosControl := DatosControlType.Create;

  regFactura.RegistroFacturacion := RegistroFacturacionType.Create;

    regFactura.RegistroFacturacion.PeriodoLiquidacion := PeriodoLiquidacion.Create;
      regFactura.RegistroFacturacion.PeriodoLiquidacion.Ejercicio := '23';
      regFactura.RegistroFacturacion.PeriodoLiquidacion.Periodo := TipoPeriodoType(1); // Empieza a contar desde 0

    regFactura.RegistroFacturacion.IDFactura := IDFacturaExpedidaType.Create;
      regFactura.RegistroFacturacion.IDFactura.NumSerieFacturaEmisor := '23/123456';
      regFactura.RegistroFacturacion.IDFactura.FechaExpedicionFacturaEmisor := '31/12/23';
      regFactura.RegistroFacturacion.IDFactura.IDEmisorFactura := IDEmisorFactura2.Create;
        regFactura.RegistroFacturacion.IDFactura.IDEmisorFactura.NIF := '3333333';

    regFactura.RegistroFacturacion.DescripcionOperacion := 'vneta de mercaderías';

      regFactura.RegistroFacturacion.Desglose := DesgloseType.Create();

        detalle:= DetalleType.Create;
          detalle.CuotaRepercutida := '100';
          detalle.TipoImpositivo := '21';

        SetLength(arrayDetalles, 1);
        arrayDetalles[0] := detalle;

        regFactura.RegistroFacturacion.Desglose[0] := detalle;

  try
    SetLength(arrayFacturas, 1);
    arrayFacturas[0] := regFactura;
    result := GetsfSOAP(true, '', HTTPRIO1).AltaFactuSistemaFacturacion(arrayFacturas);
  finally
    regFactura.Destroy;
  end;


end;

Me respondo a mi mismo por si le puede servir a alguién:

          // <- Rellenos los datos de las diferentes bases DetalleType
            detalle1:= DetalleType.Create;
              detalle1.ClaveRegimen := IdOperacionesTrascendenciaTributariaType._01;                                
              detalle1.CalificacionOperacion := CalificacionOperacionType.S1;                                       
              detalle1.OperacionExenta := OperacionExentaType.E0;                                                      
              detalle1.TipoImpositivo := '21';
              detalle1.BaseImponibleOimporteNoSujeto := '123';
              detalle1.BaseImponibleACoste := '111';                                                                  
              detalle1.CuotaRepercutida := '100';
              detalle1.TipoRecargoEquivalencia := '0';
              detalle1.CuotaRecargoEquivalencia := '0';


            detalle2:= DetalleType.Create;
              detalle2.CuotaRepercutida := '200';
              detalle2.TipoImpositivo := '10';

            // Los añado todos en un array
            SetLength(arrayDetalles, 2);
              arrayDetalles[0] := detalle1;
              arrayDetalles[1] := detalle2;

            // Cargo el array con todas las posibles bases en el apartado Desglose
            regFactura.RegistroFacturacion.Desglose := arrayDetalles; // := deta .Create;

Por favor, ¿alguien que tenga Delphi 2007 podría intentar cargar a día de hoy los WSDL haber si puede o si le da error de "Document Empty"?.

Yo recuerdo haberlos importado hace unos meses sin problema, pero algo han modificado desde entonces que ahora no soy capaz.

Gracias.

[nincillo]

Empezado por javipes

y si pruebas con

setlength(regfactura.RegistroFacturacion.desglose,1);

antes de hacer

regFactura.RegistroFacturacion.Desglose[0] := DesgloseType.Create();

No había visto este mensaje antes de enviar el como lo solucioné.

De todas formas voy a probarlo.

Muchas gracias.