Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[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.

[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)