Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Os dejo aquí los ejemplos de ficheros VERIFACTU vs FACTURAE, que le he cambiado algun error a los ficheros de facturae equivalentes a los de verifactu
y aqui os dejo un validador y visualizador de la facturae
https://face.gob.es/es/facturas/vali...lizar-facturas

[Delphier]

Empezado por edari

Una duda me surge


Los clientes que están sujetos al SII no están obligados a pasar por Veri*factu. Hasta aquí correcto, pero nuestro SIF tiene que cumplir alguna de las obligaciones de los no veri*factu p.e. la de conservación etc...?

La misma duda que surgió a mí , pero yo diría que según la ley hay que hacerlo, ya que el software debe cunplir la ley , incluso yo tengo usuarios en el SII y otros que no , incluso que envían al SII desde otro software de contabilidad SAP donde previamente les he pasado la información de facturas, por lo que me veré obligado a montar todo el sistema de reg¡stro VERIFACTU para que el software cumpla.

[CarlosR]

Empezado por ermendalenda

aqui el detalle de los nodos

No había visto esto.



Gracias de nuevo.

[javipes]

Hola a todos.
Estoy ya implementando con wsdl V0.11.5 y me encuentro con que al importar la wsdl correspondiente me aparece la definicion del dato FFechaHoraHusoGenRegistro: TXSDateTime;
Al utilizarlo segun la definicion de Soap.XSBuiltIns me genera un valor 2024-04-10T11:38:56.000Z , cosa que se separa ligeramente del formato indicado.
Lo he resuelto incluyendo al principio de la unit SistemaFacturacion una redefinicion: type TXSDateTime=string; y el valor lo he formateado adecuadamente segun el formato indicado: AAAA-MM-DDThh:nn:ss+0x:00 la x varia entre 0, 1 2 segun corresponda. En principio está resuelto para la generacion del xml.
La pregunta es ¿esto solo me ha ocurrido a mi, o es que he utilizado un importacion incorrecta del wsdl?
He importado (desde Studio 10.1 Berlin)
https://prewww2.aeat.es/static_files...cturacion.wsdl

y utilizo la opcion
Porcess only WSDL Binding extensions por the SOAP 1.2 Protocol

[CarlosR]

Empezado por javipes

Hola a todos.
Estoy ya implementando con wsdl V0.11.5 y me encuentro con que al importar la wsdl correspondiente me aparece la definicion del dato FFechaHoraHusoGenRegistro: TXSDateTime;
Al utilizarlo segun la definicion de Soap.XSBuiltIns me genera un valor 2024-04-10T11:38:56.000Z , cosa que se separa ligeramente del formato indicado.
Lo he resuelto incluyendo al principio de la unit SistemaFacturacion una redefinicion: type TXSDateTime=string; y el valor lo he formateado adecuadamente segun el formato indicado: AAAA-MM-DDThh:nn:ss+0x:00 la x varia entre 0, 1 2 segun corresponda. En principio está resuelto para la generacion del xml.
La pregunta es ¿esto solo me ha ocurrido a mi, o es que he utilizado un importacion incorrecta del wsdl?
He importado (desde Studio 10.1 Berlin)
...aeat/tikeV1.0/... /SistemaFacturacion.wsdl (no me deja poner la url entera)
y utilizo la opcion
Porcess only WSDL Binding extensions por the SOAP 1.2 Protocol

Al importarlo en Embarcadero Studio Enterprise con el compilador C++ builder 11 no genera ese mismo nombre de campo. La importación al framework del wsdl se hizo en modo automático.

De todos modos, no creo que sea difícil hacer un conversor a string.


Si usa sql server para generar datos y por si le sirve de ayuda le paso una simple instrucción :


print SubString(convert(varchar(14),getdate(),112),7,2) + '-' + SubString(convert(varchar(14),getdate(),112),5,2) + '-' + SubString(convert(varchar(14),getdate(),112),1,4)+' ' + SubString(convert(varchar(14),getdate(),114),1,8)+'+0'+TRIM(STR(datediff(hour,getutcdate(),getdate() )))+':00'


Le generará el diferencial transformado entre la fecha utc y la fecha real de su sistema. Todo en uno !


Saludos.

[ermendalenda]

Empezado por CarlosR

No había visto esto.



Gracias de nuevo.

De nada. Para eso estamos

[javipes]

Sí, si eso lo tengo codificado, sin problemas:

Código Delphi [-]
function DTHuso(Valor: TdateTime):string;
begin
  Result := FormatDateTime('yyyy-mm-ddThh:nn:ss',Valor)+HusoHorario(Valor);
end;

Y HusoHorario me devuelve ese diferencial que indicas, solo que yo devuelvo en HusoHorario '+00:00' '+01:00' o '+02:00'

Yo realmente preguntaba si al importar el wsdl el dato FechaHoraHusoGenRegistro se habia importado como TXSDateTime
en cuyo caso la asignacion al dato sería algo así:

....FechaHoraHusoGenRegistro:=DateTimeToXSDateTime(Fecha); --> aaaa-mm-ddThh:nn:ss:ddddZ p
pero no sale el HusoHorario
por ello, he redefinido dicho tipo como un string (podría ser como un dato TextMax25Type o similar)



con la redefinicion planteada le asigno
....FechaHoraHusoGenRegistro:=DTHuso(Fecha); --> aaaa-mm-ddThh:nn:ss+0x:00

(normalmente la fecha será el timedateactual, now() pero quería preparar una funcion)

[CarlosR]

Empezado por javipes

Sí, si eso lo tengo codificado, sin problemas:
Código Delphi [-]function DTHuso(Valor: TdateTime):string; begin Result := FormatDateTime('yyyy-mm-ddThh:nn:ss',Valor)+HusoHorario(Valor); end;

Y HusoHorario me devuelve ese diferencial que indicas, solo que yo devuelvo en HusoHorario '+00:00' '+01:00' o '+02:00'

Yo realmente preguntaba si al importar el wsdl el dato FechaHoraHusoGenRegistro se habia importado como TXSDateTime
en cuyo caso la asignacion al dato sería algo así:

....FechaHoraHusoGenRegistro:=DateTimeToXSDateTime(Fecha); --> aaaa-mm-ddThh:nn:ss:ddddZ p
pero no sale el HusoHorario
por ello, he redefinido dicho tipo como un string (podría ser como un dato TextMax25Type o similar)



con la redefinicion planteada le asigno
....FechaHoraHusoGenRegistro:=DTHuso(Fecha); --> aaaa-mm-ddThh:nn:ss+0x:00

(normalmente la fecha será el timedateactual, now() pero quería preparar una funcion)

De todas formas personalmente trato ese dato como un texto. Actualmente estoy cambiando el modelo creado con el wsdl a un modelo manual, "todo hecho a pelo". A menos que vea algo insalvable lo dejaré manual.
Me da mucha mas libertad para actuar y para las actualizaciones. Ayer tomé la decisión y ya casi lo tengo terminado. Voy a probar de una manera local y ver que genera. (Respetando el código actual por si acaso)



Un consejo si me lo permite, preste mucha atención a la fechahora actual y la la fechahora dtc. No vaya a sacar esto de cada terminal si tiene un modelo de soft centralizado. Podría ocurrir que si una máquina no está en hora generaría un registro que no esté ordenado por fechahora y eso daría errores en la AEAT.
Mejor dejar que el sistema centralizado ofrezca tales datos si es que así lo ha concebido.


Un saludo.

[ermendalenda]

Recordáis si en el webinar dijeron algo, de nuevo, de tener que recomprobar los encadenamientos de los últimos 5 registros al generar cada factura? No recuerdo que lo repitieran no?. Es que es un lastre.

[edari]

Buenas,


Los que trabajáis con el programa en local tenéis pensado hacer algún tipo de control sobre el certificado? Estado del mismo? Fecha de caducidad?

[Delphier]

Empezado por edari

Buenas,


Los que trabajáis con el programa en local tenéis pensado hacer algún tipo de control sobre el certificado? Estado del mismo? Fecha de caducidad?

Pues dependerá de lo que contesten los de verifactu a esto

"
Hola

Se sabe ya si cuando una empresa que no haga envíos, tenga algún problema con el certificado, por temas de caducidad, técnicos , etc.. tiene que cerrar la tienda y enviar a los trabajadores a casa , hasta solucionar el problema técnico o puede seguir haciendo tiquets sin firmar hasta la solución?

Muchas Gracias.
Saludos
"

[javipes]

Empezado por CarlosR

De todas formas personalmente trato ese dato como un texto. Actualmente estoy cambiando el modelo creado con el wsdl a un modelo manual, "todo hecho a pelo". A menos que vea algo insalvable lo dejaré manual.
Me da mucha mas libertad para actuar y para las actualizaciones. Ayer tomé la decisión y ya casi lo tengo terminado. Voy a probar de una manera local y ver que genera. (Respetando el código actual por si acaso)



Un consejo si me lo permite, preste mucha atención a la fechahora actual y la la fechahora dtc. No vaya a sacar esto de cada terminal si tiene un modelo de soft centralizado. Podría ocurrir que si una máquina no está en hora generaría un registro que no esté ordenado por fechahora y eso daría errores en la AEAT.
Mejor dejar que el sistema centralizado ofrezca tales datos si es que así lo ha concebido.


Un saludo.

Muchas gracias por la indicación, CarlosR, pero de momento todos los clientes utilizan un servidor centralizado al que se conectan por escritorio remoto y cada uno , en su perfil ejecuta la aplicacion. Todos tienen la misma hora del sistema, que es la del servidor, y se actualiza segun el huso horario actual. (horario verano/ horario invierno)

[ermendalenda]

Empezado por Delphier

Pues dependerá de lo que contesten los de verifactu a esto

"
Hola

Se sabe ya si cuando una empresa que no haga envíos, tenga algún problema con el certificado, por temas de caducidad, técnicos , etc.. tiene que cerrar la tienda y enviar a los trabajadores a casa , hasta solucionar el problema técnico o puede seguir haciendo tiquets sin firmar hasta la solución?

Muchas Gracias.
Saludos
"

Hola yo tengo un control para fecha ey coincidencia del dentificador (cif,nif) con el del certificado.
Lo que pasa es que lo tengo en php, instalado en local, y un servicio de php corriendo en el mismo ordenador al que le hago la llamada con curl y me devuelve todo lo que quiera del contenido del certififado, fecha caducidad, empresa, nombre e incluso cuando está cercana la fecha de caducidad mando un email al que creo el certificado (asesoria...)para avisarlo, ya que el mismo certificado contiene el email.
Lo que hay que tener en cuenta es que si pides de nuevo el certificado el que tengas instalado ya no vale, y puede haber un periodo que no puedas usarlo pero se quedarán los envíos en standby.
En sitios muy delicados tienen 2 certificados para ticketbai, uno de izempe y otro normal con fechas distintas y van cambiando cuando se acerca la fecha o intenta con uno y si no con el otro

[Delphier]

Empezado por Delphier

Pues dependerá de lo que contesten los de verifactu a esto

"
Hola

Se sabe ya si cuando una empresa que no haga envíos, tenga algún problema con el certificado, por temas de caducidad, técnicos , etc.. tiene que cerrar la tienda y enviar a los trabajadores a casa , hasta solucionar el problema técnico o puede seguir haciendo tiquets sin firmar hasta la solución?

Muchas Gracias.
Saludos
"

Pues mala suerte

Respuesta de la AEAT

Buenos días:
El desarrollo normativo(*) a que se refiere su consulta aún no está completado y se encuentra en fase de estudio y elaboración definitiva. Por ello, sería aventurado adelantarle alguna respuesta con el riesgo de que esta cambiara tras la publicación oficial en el BOE de la orden ministerial y en la Sede electrónica de la AEAT de la documentación que completará dicha orden. Además, es muy probable que la lectura de dicha documentación oficial pudiera responder total o parcialmente su consulta. Por lo tanto, le emplazamos a que espere a dicho momento en el que podrá disponer de toda la información oficial necesaria. Si entonces aún siguiera teniendo dudas, por favor, remítanoslas por esta misma vía.

En cualquier caso, ya hemos tomado nota de sus consultas y se tendrán en cuenta para su estudio y, en su caso, incorporación a la documentación final del proyecto.

Muchas gracias por contactar con la AEAT.

(*) Artículos 29.2.j) y 201 bis de la Ley 58/2003, de 17 de diciembre, General Tributaria, y Real Decreto 1007/2023, de 5 de diciembre, por el que se aprueba el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación. La orden ministerial que desarrollará el RD 1007/2023, publicada en enero de 2024 en el portal del Ministerio de Hacienda para dar cumplimiento a su trámite de audiencia e información pública, está en fase de estudio y elaboración definitiva, así como la documentación que completará dicha orden y que estará disponible en la Sede electrónica de la AEAT tras la aprobación y publicación oficial de la orden ministerial.


Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email: verifactu@correo.aeat.es

[ermendalenda]

No creo que den un periodo de gracia en el que puedas seguir enviando con el certificado caducado o revocado, eso es difícil de controlar correctamente. Dejarán un periodo de gracia sin envíos y cuando lo soluciones envias marcando (I)ncidencia=S y si detectan que se repite mucho en el tiempo te enviarán avisos.

[Delphier]

Empezado por ermendalenda

No creo que den un periodo de gracia en el que puedas seguir enviando con el certificado caducado o revocado, eso es difícil de controlar correctamente. Dejarán un periodo de gracia sin envíos y cuando lo soluciones envias marcando (I)ncidencia=S y si detectan que se repite mucho en el tiempo te enviarán avisos.

No , si yo les he preguntado para los usuarios que decidan no enviar por el motivo que sea , funcionamiento NO*VERIFACTU , hay que darles un poco de guerra por mail , que comparado con la guerra que nos dan a nosotros no es nada.

A ver que nos cuentan al final...

[jlmoli_67]

Buenas, señores

Este procedimiento en .net devuelve la fecha de caducidad y el nombre y dni del titular de un certificado pfx para poder dar el aviso pertinente antes de que dicho certificado caduque. La renovacion creo que se puede solicitar dos meses antes de su caducidad
( por si a alguien le viene bien )

Imports System.Security.Cryptography.X509Certificates

*******************************

 Dim pfxFile As String = "c:\documentos\certificado.pfx"
        Dim password As String = "xxxxxxxxxx"
        Dim cert As New X509Certificate2(pfxFile, password)
        Dim caducidad As DateTime = cert.NotAfter
        Dim Nombre_y_dni As String = cert.GetNameInfo(X509NameType.SimpleName, False)

        MsgBox("Fecha de caducidad del certificado: " & caducidad.ToString())
        MsgBox("Fecha de caducidad del certificado: " & Nombre_y_dni.ToString())

[ermendalenda]

Empezado por Delphier

No , si yo les he preguntado para los usuarios que decidan no enviar por el motivo que sea , funcionamiento NO*VERIFACTU , hay que darles un poco de guerra por mail , que comparado con la guerra que nos dan a nosotros no es nada.

A ver que nos cuentan al final...

Hola. Ya, es que es lioso y un problemón, a ellos les da igual, si se dan cuenta de que hay problemas en un comercio fijo que le dan a un boton y te mandan un requerimiento o una inspeccion , el que no puedas firmar el xml no evita el encadenamiento y generación del qr, con lo cual puedes seguir vendiendo, tendras que poner el.mensaje visible en todos los terminales de que hay problemas ir genetando los eventos de la incidencia y después cuando tengas el certificado, tendrás que: registra el nuevo certificado para firmar, hacer las firmas, eventos de las regeneraciones/firmas etc, etc. Mejor VERIFACTU que no VERIFACTU, vaya lio hay que montar, el que quiera no verifactu va a tener que tener un informático a su disposición bastante a menudo.

[CarlosR]

Empezado por ermendalenda

Hola. Ya, es que es lioso y un problemón, a ellos les da igual, si se dan cuenta de que hay problemas en un comercio fijo que le dan a un boton y te mandan un requerimiento o una inspeccion , el que no puedas firmar el xml no evita el encadenamiento y generación del qr, con lo cual puedes seguir vendiendo, tendras que poner el.mensaje visible en todos los terminales de que hay problemas ir genetando los eventos de la incidencia y después cuando tengas el certificado, tendrás que: registra el nuevo certificado para firmar, hacer las firmas, eventos de las regeneraciones/firmas etc, etc. Mejor VERIFACTU que no VERIFACTU, vaya lio hay que montar, el que quiera no verifactu va a tener que tener un informático a su disposición bastante a menudo.

Pregunto, ¿ no le sería mas fácil tener una tabla en donde tienes el certificado, la fecha de expiración, el número de serie y el pass y todo ello cifrado ?
Y del registro de certificado en vigencia hacer uso para la certificación del xml. Con el campo fecha expiración ya podrá tener el control de si está activo o no. Salvo que lo revoquen antes.

Otra cuestión es como se certifica el xml. Tengo dudas sobre esto. Si está puesto en ello le agradecería un par de consejos. Supongo que se hará igual que la factura electrónica.



Estoy en esa misma tesitura, no tengo claro si al final cerraré mi soft a solo veri*factu o lo dejaré dual. Si lo dejo para los dos tendré que tener todos los requisitos de no veri*factu. Lo decidiré el último día. Hay que hablar con abogados que sepan lo que se hacen.
Tendrá que esperar a que la AEAT saque la documentación. Para ellos es un trámite nada mas, para cualquier desarrollador es un rompecabezas. Ya no solo por el código sino también por las actualizaciones.


Un saludo.

[ermendalenda]

Empezado por CarlosR

Pregunto, ¿ no le sería mas fácil tener una tabla en donde tienes el certificado, la fecha de expiración, el número de serie y el pass y todo ello cifrado ?
Y del registro de certificado en vigencia hacer uso para la certificación del xml. Con el campo fecha expiración ya podrá tener el control de si está activo o no. Salvo que lo revoquen antes.

Un saludo.

Es buena idea, a veces nos complicamos más de la cuenta, yo
lo hago así por que me aseguro que el contenido es correcto, pero si se hace metodicamente, como dices, también está perfecto.
Lo que yo hago es:
-1 Consulto el fichero del certificado y extraigo los datos que necesito de comprobación: fecha caducidad, busco el nif, email...
-2. (que esto si lo podrias hacer por que en la tabla no puedes verlo) Para asegurarme que no está revocado hago una consulta de mi nif al webservice de la aeat de consultas de nifs, que me devolveria el cliente y nombre, sí es todo correcto, o el estado del certificado, si está revocado o caducado.

Empezado por CarlosR

Otra cuestión es como se certifica el xml. Tengo dudas sobre esto. Si está puesto en ello le agradecería un par de consejos. Supongo que se hará igual que la factura electrónica.

supongo que refieres a la firma, aun hay poca documentacion sobre ello, solo que va a ser Xades y el schema(esquema), el metodo es bastante similiar a las firmas de de facturae usando el mismo esquema esquema: http://www.w3.org/2000/09/xmldsig#
pero hay otros campos que hay que tener en cuenta en las firmas que no van a coincidir por ejemplo la signPolicy(Política de firma) que contiene 3 campos :
-Name
-url
-digest(hash)
que en facturae son:

"name" => "Politica de Firma FacturaE v3.1",
    "url" => "http://www.facturae.es/politica_de_firma_formato_facturae/politica_de_firma_formato_facturae_v3_1.pdf",
    "digest" => "Ohixl6upD6av8N7pEvDABhEL6hM="

No se si usas el programa gratuito de firma autofirma o autofirmacommandline.exe, pero ojo con esto, ya que si necesitas rapidez en las firmas, esto no te sirve y tendrás que buscar un metodo alternativo de firmas que tardan una media de 0.10segundos en firmar un xml el autofirma te puede tardar una media de 2 a 4 segundos y en la primera firma (cuando arrancas el ordenador) hasta 12 segundos.

Empezado por CarlosR

Estoy en esa misma tesitura, no tengo claro si al final cerraré mi soft a solo veri*factu o lo dejaré dual. Si lo dejo para los dos tendré que tener todos los requisitos de no veri*factu. Lo decidiré el último día. Hay que hablar con abogados que sepan lo que se hacen.
Tendrá que esperar a que la AEAT saque la documentación. Para ellos es un trámite nada mas, para cualquier desarrollador es un rompecabezas. Ya no solo por el código sino también por las actualizaciones.

Los abogados te van a ayudar poco, ya que la problematica software de facturación.informatica no la van a conocer como tú, y si contratas a una empresa que te diga que puntos debes tener en cuenta te van a cobrar una pasta y te van a asustar más de la cuenta. Coje todo los conocimientos que puedas entre asesores fiscales, este foro y los reglamentos de facturación...