FiveTech Software tech support forums

Posted: **Fri Aug 02, 2024 9:59 am**

Xevi wrote: 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

Posted: **Fri Aug 02, 2024 4:21 pm**

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

Posted: **Fri Aug 02, 2024 5:19 pm**

FiveWiDi wrote: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

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

/*
    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

Posted: **Fri Aug 02, 2024 5:40 pm**

Xevi wrote: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

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

/*
    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

/* *********************************************************************************** */
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
/* *********************************************************************************** */

Posted: **Sun Aug 04, 2024 6:36 am**

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.

Posted: **Sun Aug 04, 2024 6:19 pm**

FiveWiDi wrote: 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

FiveWiDi wrote: 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

FiveWiDi wrote: 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.

Xevi wrote: 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

Posted: **Sun Aug 04, 2024 7:25 pm**

Xevi wrote: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.

Posted: **Sun Aug 04, 2024 7:38 pm**

Xevi wrote: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.

Posted: **Mon Aug 05, 2024 6:21 am**

FiveWiDi wrote: 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,

Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.

Posted: **Tue Aug 06, 2024 8:50 am**

t= 60
Se hace un primer envio y hasta pasado t entonces no se puede volver a enviar
Pero y si en la espera se han impreso mas ? Las tiene que mandar el usuario. Pero y si se le olvida, entonces ya no seria envio "inmediato". Entonces, parece que tiene que haber un demonio enviador dando vueltas aunque tu sistema tenga un solo usuario con un pc en un rincon de una fabrica

Posted: **Tue Aug 06, 2024 10:12 pm**

VictorCasajuana wrote:Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.

Gracias Víctor, pero no es el caso.

La factura y la operación tendran fecha de emisión día 1 de mes, pero hoy en día la envían 4 días antes.

No se... en las pruebas veremos que responde Hacienda (Verifactu).

Muchas gracias,

Posted: **Tue Aug 06, 2024 10:51 pm**

paquitohm wrote:t= 60
Se hace un primer envio y hasta pasado t entonces no se puede volver a enviar
Pero y si en la espera se han impreso mas ? Las tiene que mandar el usuario. Pero y si se le olvida, entonces ya no seria envio "inmediato". Entonces, parece que tiene que haber un demonio enviador dando vueltas aunque tu sistema tenga un solo usuario con un pc en un rincon de una fabrica

Ahí está la cosa; lo puedes enviar más tarde si te lo dice Hacienda, pero y si lo decides tu?

El tema del demonio, yo le meteré un TIMER que avise si hay envíos pendientes, y que el usuario le de al botón. De paso el TIMER tendrá en cuenta el 'retardo' que nos haya indicado Verifactu en el último envío.

Este desarrollo parecía relativamente sencillo, pero debe contemplar situaciones que no se pueden dejar que se resuelvan a mano, la 'liarían parda' los usuarios.

Por ejemplo debe haber un historial de xml enviados que se relacionen con las facturas que en ellos se tratan, no es una relación 1 factura a 1 xml. Siempre es bueno tener información de lo que se ha hecho.
Si en un envío hay un error se debe volver a enviar con los datos erróneos del primer envío corregidos (eso he entendido), por tanto una misma factura puede aparecer en 'n' xml diferentes. Por cierto ese envío de la corrección, cuando debe hacerse? Antes de la siguiente factura? Cuando tengamos tiempo de resolver el error?

Otra cuestión. Asi como contemplar y establecer un procedimiento para tratar esos 'retardos' en el envío del xml, momento en el cual puedes tener 1 o varios xml pendientes de enviar; entonces que hago? Me _ todos y hago uno solo? los envío uno detrás de otro con su respectivo 'retardo'? Y me planto en el cierre de la oficina con varios xml pendientes de enviar?
Creo que estableceré un estado 'EnColaVF' y cuando se pueda enviar el xml, en ese momento lo creo con todo lo pendiente y lo envío.

Ese 'retardo' a final de mes (trimestre/año) puede ser considerable.

Muchas gracias,

Posted: **Wed Aug 07, 2024 9:25 am**

Hola,

FiveWiDi wrote: Ahí está la cosa; lo puedes enviar más tarde si te lo dice Hacienda, pero y si lo decides tu?

No entiendo bien a qué te refieres
Entiendo que hay que enviar inmediatamente en cuanto permita el flujo de la infraestructura de la agencia

FiveWiDi wrote: El tema del demonio, yo le meteré un TIMER que avise si hay envíos pendientes, y que el usuario le de al botón. De paso el TIMER tendrá en cuenta el 'retardo' que nos haya indicado Verifactu en el último envío.

No recuerdo si al final t=60 iba a ser fijo o iba a venir como tag en la respuesta. En todo caso parece que tenemos que trabajar con t variables.
Si, como comentas habrá que usarlo. Estoy pensando en que el timer, si hay pendiente de envio y el flujo está ok, hará una llamada automatica al ejecutable con un parametro ProgramaMio /ENVIA_VERIFACTU y así simulo multitarea y tambien impido que el usuario pueda cerrar el programa bruscamente durante el envio

FiveWiDi wrote: Este desarrollo parecía relativamente sencillo, pero debe contemplar situaciones que no se pueden dejar que se resuelvan a mano, la 'liarían parda' los usuarios.

Así es. Esto complica el proceso de facturacion pero lo peor es que lo limita y obliga a ir a rectificativas

FiveWiDi wrote: Por ejemplo debe haber un historial de xml enviados que se relacionen con las facturas que en ellos se tratan, no es una relación 1 factura a 1 xml. Siempre es bueno tener información de lo que se ha hecho.

Buena idea.
En mi programa tengo ya un log para el proceso automatico de contabilizacion de facturas y un log para el proceso de generacion-impresion de facturas. Tambien tengo un log para el tema del TicketBAI donde se relacionan los pasos que se hacen. Se trataria de incorporar al log el .xml donde "viaja" la factura o incluso, por cada registro en la tabla facturas_ventas se puede crear un campo donde indique el .xml desde el que se envió la fra.

FiveWiDi wrote: Si en un envío hay un error se debe volver a enviar con los datos erróneos del primer envío corregidos (eso he entendido), por tanto una misma factura puede aparecer en 'n' xml diferentes. Por cierto ese envío de la corrección, cuando debe hacerse? Antes de la siguiente factura? Cuando tengamos tiempo de resolver el error?

Hasta donde yo sé Verifactu no permite modificaciones: Altas y Anulaciones solamente. Modificaciones, si no son Anulaciones, se habrán de hacer con nueva factura a través de Rectificativa.

FiveWiDi wrote: Otra cuestión. Asi como contemplar y establecer un procedimiento para tratar esos 'retardos' en el envío del xml, momento en el cual puedes tener 1 o varios xml pendientes de enviar; entonces que hago? Me _ todos y hago uno solo? los envío uno detrás de otro con su respectivo 'retardo'? Y me planto en el cierre de la oficina con varios xml pendientes de enviar?
Creo que estableceré un estado 'EnColaVF' y cuando se pueda enviar el xml, en ese momento lo creo con todo lo pendiente y lo envío.

Ese 'retardo' a final de mes (trimestre/año) puede ser considerable.

Si, lo que comentas parece lo mejor: El .xml se genera justo cuando se puede enviar y no antes, es decir, la "cola" ha de ser de envios pendientes (facturas) y no de .xml(s)

Salu2

Posted: **Wed Aug 07, 2024 9:40 am**

una opción buena para los fallos de envío es tener una cola FIFO de los XML que se han generado y cada vez que se genere uno nuevo, pues se mete en la cola y se procesa, así te aseguras la secuencialidad de los envíos. Esto, mejorable por supuesto con los timers que indicáis para que sea más transparente al usuario.

Posted: **Wed Aug 07, 2024 9:47 am**

FiveWiDi wrote:
VictorCasajuana wrote:Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.
Gracias Víctor, pero no es el caso.

La factura y la operación tendran fecha de emisión día 1 de mes, pero hoy en día la envían 4 días antes.

No se... en las pruebas veremos que responde Hacienda (Verifactu).

Muchas gracias,

Revisando las preguntas y respuestas: https://www.agenciatributaria.es/static ... ifactu.pdf cuando se pregunta si la fecha de la factura no es la del día en que se genera, te remiten a la fecha de operación. No obstante, supongo que cuando saldrá el reglamento definitivo habrá muchas preguntas sobre esta fecha, ya que suele ser una práctica habitual en algunos sectores que no sea la del día que se emite la factura.
Queda poco margen ya para que publiquen el reglamento y se pueda cumplir el la fecha 1-7-25 teniendo en cuenta los 9 meses de plazo.

FiveTech Software tech support forums

España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos

Re: España: Normativa sancionadora sistemas informáticos