España: Normativa sancionadora sistemas informáticos

[quim]

Es fácil cuando se sabe hacer, claro está

Evidentemente es fácil si se conoce, disculpa por si me he expresado de forma prepotente ...

Me referia a lo 'relativamente' fácil que resulta implementar cualquier cosa en harbour, respecto por ejemplo a Java

Saludos

[paquitohm]

No por dios, quim, no hay nada que disculpar, sólo faltaba...
Quise decir que cuando las cosas se estudian, entonces se conocen y entonces se saben hacer y resultan fáciles. Es evidente que tú ya has hecho el camino que otros deberíamos hacer también.

Agradezco nuevamente este y todos tus aportes que tanto benefician a la comunidad y por los cuales siempre te estaremos agradecidos

[paquitohm]

Esta autorización parece que es necesaria para el tema de las autofacturas que comentábamos el otro día ¿ Que vas a hacer/ imprimir facturas en nombre de un tercero ? Pues entonces te toca también enviarlas a la agencia y para eso se hace necesaria una autorización

https://sede.agenciatributaria.gob.es/s ... quidac.pdf

[FiveWiDi]

Hola a todos,

Sabéis si hay novedades respecto de la orden ministerial? (A ver si me he despistado)

Y sobre cambios 'técnicos'?

Es que estoy trabajando en ello (modificar los DBF, validaciones internas, el XML, ...)

Veo algo que no encuentro justificación que esté donde está en la estructura del XML.

Hay un grupo de datos que hace referencia al 'sistema informático', no es un poco absurdo que esté con cada grupo de datos de la factura?
Para mi lo lógico sería que estuviera al mismo nivel que los TAG 'RegistroFacturación' y 'DatosControl', y no que pertenezca al 'RegistroFacturación'.

Por eso pregunto si han habido cambios recientemente.

Muchas gracias,

[paquitohm]

Buenos días,

Hola a todos,

Sabéis si hay novedades respecto de la orden ministerial? (A ver si me he despistado)

Y sobre cambios 'técnicos'?

Hasta donde yo sé nada hay de la O.M. aunque si todo entra en vigor el 1/7/25, no debería tardar muchos meses, salvo retrasos oficiales

Es que estoy trabajando en ello (modificar los DBF, validaciones internas, el XML, ...)

¿ Qué tipo de cambios estás haciendo en los DBF ? ¿ Qué validaciones ? Pregunto por ayudarte porque no hacen falta tantos cambios como supusimos al principio que había que hacer

Veo algo que no encuentro justificación que esté donde está en la estructura del XML.
Hay un grupo de datos que hace referencia al 'sistema informático', no es un poco absurdo que esté con cada grupo de datos de la factura?
Para mi lo lógico sería que estuviera al mismo nivel que los TAG 'RegistroFacturación' y 'DatosControl', y no que pertenezca al 'RegistroFacturación'.

TicketBai tiene la estructura que tu comentas.
Sospecho que esa estructura tiene el sentido de que haya sistemas "enviadores" de facturas producidas por varios SIF, asi un envio podria constar de muchas facturas impresas por varios SIF distintos

Salu2

[Xevi]

Hola,
¿ Alguien tiene implementada el hash 256 de la huella en harbour ?
 [/code]

Paquito, en harbour es muy fácil (como en casi todo) ...

Code: Select all  Expand view

//-----------------------------------------------------------------------------//
// Especificaciones de huella o hash
//-----------------------------------------------------------------------------//
// Algoritmo: SHA-256
// Codificación: UTF-8
// Formato de salida será:
//    - En sistema hexadecimal.
//    - En mayúsculas.
// Se validará la huella o hash en el servicio de remisión de registros de facturación.
// En caso de error, se marcará como “Aceptada con errores” y se deberá proceder a su revisión.
//-----------------------------------------------------------------------------//
function hb_Huella()

   local c := ""
   local h := {=>}

   h['Nif']                      := "B1234567"
   h['NumSerieFacturaEmisor']    := "AB-123456"
   h['FechaExpedicionFactura']   := hb_dtoc( date(), "dd-mm-yyyy" )
   h['TipoRegistroSIF']          := "01"
   h['TipoFactura']              := "F1"
   h['CuotaTotal']               := ltrim( str(261.61, 12, 2) )
   h['ImporteTotal']             := ltrim( str(1507.36, 12, 2) )
   h['HuellaRegistroAnterior']   := "ZmY2MDgxMzc2ZWIyMTI4ZDFiMDMyMDlkMTAyNmQ4ZDVmZGExMWJkYWRiMThjZTNkYjE4ODExZDg3MDUwZTNjMQ=="
   h['FechaHoraHusoGenRegistro'] := hb_TtoS( hb_datetime() )

   hb_heval( h, {|k,v,i| c += v} ) // | key, value, index |

return hb_base64Encode( hb_sha256(c) )
 

Quim,

Harbour nos lo pone ¿fácil???, jejeje.
Le daré una vuelta a ver si cambio por lo que tengo hecho.

Code: Select all  Expand view

   cUtcTime := iTime()['datetime']
   cUtcTime := Left( cUtcTime, 19 ) + Right( cUtcTime, 6 ) //2024-01-01T19:20:35+01:00
   h['TextHuella'] := "IDEmisorFactura=" + AllTrim(AppData:cNifEmpresa) + "&NumSerieFactura=" + AllTrim(cNumFac) + "&FechaExpedicionFactura=" + StrTran( h['cDataFactura'], "/", "-" ) + "&TipoFactura=F1&CuotaTotal=" + AllTrim(Str( h['nIva1']+h['nIva2']+h['nIva3'], 15, 2 )) + "&ImporteTotal=" + AllTrim(Str( h['nBase0']-h['nDte0'] + h['nBase1']-h['nDte1'] + h['nBase2']-h['nDte2'] + h['nBase3']-h['nDte3'], 15, 2 )) + "&Huella=" + "3C464DAF61ACB827C65FDA19F352A4E3BDC2 C640E9E9FC4CC058073F38F12F60" + "&FechaHoraHusoGenRegistro=" + cUtcTime
   h['Huella'] := Upper(HB_SHA256( h['TextHuella'] ))
 

No se porque le antepones hb_base64Encode()... ¿?¿?

Debes de añadir un Upper() al retorno del valor.
Además... debería de conformar la huella TODO el texto 'informativo' de cada campo a generar la huella...

Editado...
Acabo de mirar el documento para la generación de la huella...
Es como comento.

https://www.agenciatributaria.es/static ... istros.pdf
Apartado 6. Ejemplos

[FiveWiDi]

¿ Qué tipo de cambios estás haciendo en los DBF ? ¿ Qué validaciones ? Pregunto por ayudarte porque no hacen falta tantos cambios como supusimos al principio que había que hacer

He añadido el campo huella y de envío a Verifactu al DBF de las facturas y al de su detalle.
A partir del 01/07/2025 no permitiré las bajas y modificaciones de facturas ya enviadas a Verifactu, hasta esa fecha (o hasta que empiece a utilizar Verifactu) aparecerá un mensaje indicando que no debe hacerlo, pero bajo su responsabilidad podrá hacerlo.
Está el tema de enlazar facturas anterior-posterior, aún le estoy dando vueltas; creo que guiarme por el número de factura.... leí algo de que no tienen por que existir facturas correlativas, por tanto puede faltar la factura 'anterior'.
Si es así deberé establecer el binomio anterior-siguiente en el momento de recepción 'Ok' de Verifactu.
Hasta la recepción del 'Ok' de Verifactu soy libre de hacer lo que quiera mientras no se entregue la factura al cliente.

TicketBai tiene la estructura que tu comentas.
Sospecho que esa estructura tiene el sentido de que haya sistemas "enviadores" de facturas producidas por varios SIF, asi un envio podria constar de muchas facturas impresas por varios SIF distintos

Entiendo.
Les será útil a las empresas que den servicio de envío a Verifactu y en un solo paquete envíen información de varios de sus clientes.

Curiosidad.
Si un obligado tributario está acogido a Verifactu, en sus XML enviará sólo la factura del momento, cierto?
Ya que la emisión, envío a Verifactu, entrega al cliente, debe ser por este orden, cierto?

Duda.
He leído que no hay problema en enviar facturas a Verifactu con fecha emisión anterior a la de su envío a Verifactu.
Ahora bien, se de una persona que envía las facturas de alquiler días antes de la fecha factura (envío el dia 28 de mes, fecha factura día 1 del mes siguiente) . De esto no he encontrado nada. Si las envía a Verifactu... Qué ocurrirá?

Muchas gracias,

[FiveWiDi]

Debes de añadir un Upper() al retorno del valor.
https://www.agenciatributaria.es/static ... istros.pdf
Apartado 6. Ejemplos

Además yo forzaré a guardar los datos/campos que intervienen en la huella directamente en mayúsculas y así se enviaran en el XML a Verifactu, ya que Hacienda dice:
"Cuando en una remisión de un sistema «VERI*FACTU» la huella informada no coincida con el cálculo realizado por la AEAT, el registro de facturación se marcará como “Aceptado con errores”"
Es decir con los datos que recibirán de nuestro XML calcularan ellos la huella y deberá coincidir con la nuestra.
Si sólo y siempre los tengo en mayúsculas, siempre podré obtener de nuevo la huella y coincidirá con lo que envié a Hacienda; si permito modificar la letra del NIF (de mayúsculas a minúsculas por ejemplo) ya no podría volver a obtener la misma huella inicial.

Muchas gracias

[FiveWiDi]

Hola,

Pregunta:
¿Que van a poner Ustedes en el TAG 'OperacionExenta'?
A 29/04/2024 este TAG es obligatorio.

Muchas gracias,

Editado:
¿Cómo consigo esto?
DateTime. Formato: YYYY-MM-DDThh:mm:ssTZD (ej: 2024-01-01T19:20:30+01:00)

Muchas gracias

[Xevi]

Hola,
Editado:
¿Cómo consigo esto?
DateTime. Formato: YYYY-MM-DDThh:mm:ssTZD (ej: 2024-01-01T19:20:30+01:00)

Muchas gracias

To lo hago de esta manera...
cUtcTime := iTime()['datetime']
cUtcTime := Left( cUtcTime, 19 ) + Right( cUtcTime, 6 ) //2024-01-01T19:20:35+01:00

donde...

Code: Select all  Expand view

//------------------------------------------------------------------------------

/*
    itime.prg
    Compilar:
    hbmk2 itime.prg hbtip.hbc
*/
#require "hbtip"
#include "C:\Xailer\harbour\contrib\hbtip\tip.ch"

Static FUNCTION iTime()
  LOCAL cUrl, nLen, oUrl, cError := "", oClient, cData, hData, i



   cUrl := "http://worldtimeapi.org/api/timezone/Europe/Madrid/"
   IF Empty( oUrl := TUrl():New( cUrl ) )
      cError:= "URL Invalida"
   Else
      oClient := TIPClientHTTP():New( oUrl )


      IF oClient:Open()
         cData := oClient:ReadAll()
         oClient:close()


         nLen   := HB_JsonDecode( cData , @hData )

         IF nLen>0
            LogDebug( "Fecha y hora :" , hData["datetime"] )
            LogDebug( "Todos los datos:" )

            FOR EACH i IN hData
               LogDebug( i:__enumKey() + ":", i )
            NEXT

         Else
             cError:= "No se encontraron datos"

         Endif


      Else
         cError:="No se pudo conectar. "
         IF !Empty( oClient:cReply )
            cError += oClient:cReply
         ENDIF
      EndIF

   EndIf
   If !cError==""
       LogDebug( cError )
   Endif

   oUrl := NIL
   oClient := NIL

/*
#2: Fecha y hora : 2024-06-14T18:26:31.759068+02:00
#3: Todos los datos:
#4: abbreviation: CEST
#5: client_ip: 85.56.18.251
#6: datetime: 2024-06-14T18:26:31.759068+02:00
#7: day_of_week: 5
#8: day_of_year: 166
#9: dst: .T.
#10: dst_from: 2024-03-31T01:00:00+00:00
#11: dst_offset: 3600
#12: dst_until: 2024-10-27T01:00:00+00:00
#13: raw_offset: 3600
#14: timezone: Europe/Madrid
#15: unixtime: 1718382391
#16: utc_datetime: 2024-06-14T16:26:31.759068+00:00
#17: utc_offset: +02:00
#18: week_number: 24
*/

Return hData
 

[FiveWiDi]

To lo hago de esta manera...
cUtcTime := iTime()['datetime']
cUtcTime := Left( cUtcTime, 19 ) + Right( cUtcTime, 6 ) //2024-01-01T19:20:35+01:00

donde...

Code: Select all  Expand view

//------------------------------------------------------------------------------

/*
    itime.prg
    Compilar:
    hbmk2 itime.prg hbtip.hbc
*/
#require "hbtip"
#include "C:\-\harbour\contrib\hbtip\tip.ch"

Static FUNCTION iTime()
  LOCAL cUrl, nLen, oUrl, cError := "", oClient, cData, hData, i



   cUrl := "http://worldtimeapi.org/api/timezone/Europe/Madrid/"
   IF Empty( oUrl := TUrl():New( cUrl ) )
      cError:= "URL Invalida"
   Else
      oClient := TIPClientHTTP():New( oUrl )


      IF oClient:Open()
         cData := oClient:ReadAll()
         oClient:close()


         nLen   := HB_JsonDecode( cData , @hData )

         IF nLen>0
            LogDebug( "Fecha y hora :" , hData["datetime"] )
            LogDebug( "Todos los datos:" )

            FOR EACH i IN hData
               LogDebug( i:__enumKey() + ":", i )
            NEXT

         Else
             cError:= "No se encontraron datos"

         Endif


      Else
         cError:="No se pudo conectar. "
         IF !Empty( oClient:cReply )
            cError += oClient:cReply
         ENDIF
      EndIF

   EndIf
   If !cError==""
       LogDebug( cError )
   Endif

   oUrl := NIL
   oClient := NIL

/*
#2: Fecha y hora : 2024-06-14T18:26:31.759068+02:00
#3: Todos los datos:
#4: abbreviation: CEST
#5: client_ip: 85.56.18.251
#6: datetime: 2024-06-14T18:26:31.759068+02:00
#7: day_of_week: 5
#8: day_of_year: 166
#9: dst: .T.
#10: dst_from: 2024-03-31T01:00:00+00:00
#11: dst_offset: 3600
#12: dst_until: 2024-10-27T01:00:00+00:00
#13: raw_offset: 3600
#14: timezone: Europe/Madrid
#15: unixtime: 1718382391
#16: utc_datetime: 2024-06-14T16:26:31.759068+00:00
#17: utc_offset: +02:00
#18: week_number: 24
*/

Return hData
 

Gràcies Xevi,

Esta función entiendo que es para obtener la fecha del momento.

Yo tengo un campo Fecha Alta y otro Hora Alta (de hace años) en todos los registros (mi DateTime podríamos decir).

No sé si hay una función que permita pasarle estos valores y que devuelva el formato deseado, si no lo haré a mano.
De hecho creo que tengo una función para detectar horario de verano en España, voy a ver si la encuentro.

Muchas gracias igualmente, tomo nota.

Editado:
Para los brutos como yo creo que estas 2 funciones pueden servir:

Code: Select all  Expand view

/* *********************************************************************************** */
FUNCTION FechaHoraHuso( dDate, cTime )

Local cDataHoraHuso := ""

cDataHoraHuso := hb_dtoc( dDate, "yyyy-mm-dd" )
cDataHoraHuso := cDataHoraHuso + "T" + cTime
cDataHoraHuso := cDataHoraHuso + If( lHorariestiu( dDate ), "+02:00", "+01:00" )

Return cDataHoraHuso
/* *********************************************************************************** */
/* *********************************************************************************** */
FUNCTION lHorariestiu( dDate ) // HorarioDeVerano Si-No
Local lRespuesta := .F.
Local dDateInicEstiu := Date()
Local dDateFinEstiu  := Date()

DEFAULT dDate  := Date()

dDateInicEstiu := CToD("31/03/" + Str(Year(dDate), 4, 0) )
dDateFinEstiu  := CToD("31/10/" + Str(Year(dDate), 4, 0) )

//Dow() -> 7 = Dissabte, 1 = Diumenge, 2 = Dilluns, ...

While Dow( dDateInicEstiu ) <> 7
    dDateInicEstiu := dDateInicEstiu - 1
End
While Dow( dDateFinEstiu ) <> 7
    dDateFinEstiu := dDateFinEstiu - 1
End

If dDateInicEstiu < dDate .and. dDate < dDateFinEstiu
    lRespuesta := .T.
EndIf

Return lRespuesta
/* *********************************************************************************** */

[Xevi]

Carlos

Como bien dices, esta función es para obtener la FechaHoraUsoHorario al momento, que según el reglamento de la ley, es la que se requerirá.
Una cosa es la fecha factura, fecha emisión... esa no debe llevar la hora, pero la fecha de grabación del registro, esa fecha SI, es la fecha/hora/usohorario "actual" al momento de general el registro/envío.
Es lo que he entendido y por mas que me repaso el reglamento no veo la opción de poder mandar esa fecha-uso-horario "manipulada".
Además, en la función "bruta" que mencionas, para las facturas que se generen el último domingo de marzo o Octubre, de 2:00:00 a 2:59:59, es imposible que puedas discriminar el huso horario.

[paquitohm]

Está el tema de enlazar facturas anterior-posterior, aún le estoy dando vueltas; creo que guiarme por el número de factura.... leí algo de que no tienen por que existir facturas correlativas, por tanto puede faltar la factura 'anterior'.
Si es así deberé establecer el binomio anterior-siguiente en el momento de recepción 'Ok' de Verifactu.
Hasta la recepción del 'Ok' de Verifactu soy libre de hacer lo que quiera mientras no se entregue la factura al cliente.

Al menos en Ticketbai la anterior ha de ser la factura ultima que se generó que puede ser de la misma u otra serie, salvo en el primer envio, en cuyo caso el campo factura anterior irá vacio

Curiosidad.
Si un obligado tributario está acogido a Verifactu, en sus XML enviará sólo la factura del momento, cierto?
Ya que la emisión, envío a Verifactu, entrega al cliente, debe ser por este orden, cierto?

El envio tras la emision ha de ser inmediato, salvo que haya algun problema y entonces habria que justificarlo

Duda.
He leído que no hay problema en enviar facturas a Verifactu con fecha emisión anterior a la de su envío a Verifactu.
Ahora bien, se de una persona que envía las facturas de alquiler días antes de la fecha factura (envío el dia 28 de mes, fecha factura día 1 del mes siguiente) . De esto no he encontrado nada. Si las envía a Verifactu... Qué ocurrirá?

Veo dificil que eso se pueda hacer. Entiendo que hay que respetar el orden numero de factura-fecha de expedicion. No puede ser que la factura 10 tenga fecha anterior a la 9.
No lo sé con seguridad pero entiendo que las facturas han de ser enviadas inmediatamente y sólo si hubiera habido algun problema en el envio se podria entender que la fecha de emision sea anterior a la del envio. Esta es una respuesta de la agencia:

Pregunta: Me gustaría que aclararáis el tema del tiempo entre la confección y el envio a Verifactu. Lo veo de vital importancia dado que el SII es bastante más indulgente y permite mucha más maniobra de correción rapida de errores.
Respuesta: Salvo por incidencia puntual, la remisón debería hacerse tras la emisión de la factura, dentro del margen establecido por el control de flujo.

Además yo forzaré a guardar los datos/campos que intervienen en la huella directamente en mayúsculas y así se enviaran en el XML a Verifactu, ya que Hacienda dice:
"Cuando en una remisión de un sistema «VERI*FACTU» la huella informada no coincida con el cálculo realizado por la AEAT, el registro de facturación se marcará como “Aceptado con errores”"
Es decir con los datos que recibirán de nuestro XML calcularan ellos la huella y deberá coincidir con la nuestra.
Si sólo y siempre los tengo en mayúsculas, siempre podré obtener de nuevo la huella y coincidirá con lo que envié a Hacienda; si permito modificar la letra del NIF (de mayúsculas a minúsculas por ejemplo) ya no podría volver a obtener la misma huella inicial.

Muy buena la apostilla

[FiveWiDi]

Carlos
Además, en la función "bruta" que mencionas, para las facturas que se generen el último domingo de marzo o Octubre, de 2:00:00 a 2:59:59, es imposible que puedas discriminar el huso horario.

Cap problema!!!

Todo dios hace mantenimiento de sus aplicaciones cuando lo cree pertinente.
Yo lo programaré desde las 23:59:59 del último sábado de marzo y octubre, a las 03:00:00 del domingo siguiente.

[FiveWiDi]

Carlos

Como bien dices, esta función es para obtener la FechaHoraUsoHorario al momento, que según el reglamento de la ley, es la que se requerirá.
Una cosa es la fecha factura, fecha emisión... esa no debe llevar la hora, pero la fecha de grabación del registro, esa fecha SI, es la fecha/hora/usohorario "actual" al momento de general el registro/envío.

Bueno ahí creo que empezaremos a hablar del '_ de los ángeles'.
Verifactu puede obligarte a esperar 'n' minutos hasta el siguiente envío, debo dejar de crear los xml hasta el momento del envío? Debo crear un solo xml con todo lo que tenga que enviar? No puedo entregar las facturas a los clientes? (Editado: Si que puedo)
Yo le meteré la FechaHoraUsoHorario del momento de creación del xml, en las pruebas veremos que me dicen. En las pruebas es el momento de hacer burradas para ver qué 'come' el sistema.

Nota: no me deja poner la palabra 'pexo' (con 's')!!! En fin.