TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[keys]

Hola a todos.

Nuestra aplicación no deja camiar la fecha de emisión de las facturas, coge la fecha del sistema y no se puede cambiar, ya que en teoria eso es lo que dice hacienda. Pero nos hemos encontrado con algunos listillos que lo que hacen es cambiar la fecha del sistema para hacer una factura anterior a la fecha del día. No se si os habrá pasado a alguno.

¿Alguien conoce algún servicio de internet que devuelva la fecha/hora del día?

[Sistel]

Empezado por keys

Hola a todos.

Nuestra aplicación no deja camiar la fecha de emisión de las facturas, coge la fecha del sistema y no se puede cambiar, ya que en teoria eso es lo que dice hacienda. Pero nos hemos encontrado con algunos listillos que lo que hacen es cambiar la fecha del sistema para hacer una factura anterior a la fecha del día. No se si os habrá pasado a alguno.

¿Alguien conoce algún servicio de internet que devuelva la fecha/hora del día?

Hola keys,

Puedes utilizar el servicio NTP (en UDP puerto 123).
Por ejemplo, para España, los servidores es.pool.ntp.org

Saludos

[Neftali [Germán.Estévez]]

Aquí, en este hilo hemos hablado del tema:
https://www.clubdelphi.com/foros/showthread.php?t=1502


Nosotros en algunos casos lo que hacemos es cogerlo del servidor de Base de Datos, no del equipo local.
No se si esta opción la puedes aplicar a tu sistema.

Código SQL [-]
select GETDATE()

[PepCat]

También hay la opción de obtener la fecha y hora oficial de Sede Electrónica de la Fábrica Nacional de Moneda y Timbre - Real Casa de la Moneda

https://www.sede.fnmt.gob.es/delegate/fechaoficial?nocache

que devuelve la fecha en JSON:

{
	"millis": 1644571217305
}

y se puede convertir en TDateTime con

Código Delphi [-]

uses System.DateUtils;

function jsDateToDelphiDate(millis: int64): TDateTime;
begin
    var UnixSeconds: Integer := Round(millis / MSecsPerSec);
    Result := UnixToDateTime(UnixSeconds, False);
end;

[thinkows]

Cachondos no, lo siguiente :


Buenos días,

Con el ánimo de seguir colaborando con los desarrolladores de software TicketBAI y de cara a mejorar la calidad de los datos que nos envían, les hacemos llegar un documento donde se recogen algunos errores frecuentes y una serie de recomendaciones para subsanar los mismos.

Cualquier sugerencia o aportación no duden en trasladárnosla.

Un saludo.

[keys]

Gracias por lo de la Fecha/Hora.

Ahora tengo otra cosa que no se si os ha pasado. A la hora de firmar los xml, pedimos al usuario que seleccione el certificado para firmarlo. Este se firma correctamente con ese certificado (ya que es valido para firmar). Pero luego a la hora de enviarlo a hacienda, lo rechaza por que el certificado de firma no es válido (Es de dispositivo y no esta dado de alta en hacienda, el certificado es de otra persona, etc....).

Hemos mandado una sugerencia a hacienda para que pongan un servicio web para indicar si un certificado es válido para una persona/empresa en concreto. Pero sólo responden con buenas palabras, pero na de na. ¿se os ocurre alguna otra forma?

[Sistel]

Empezado por thinkows

Cachondos no, lo siguiente :


Buenos días,

Con el ánimo de seguir colaborando con los desarrolladores de software TicketBAI y de cara a mejorar la calidad de los datos que nos envían, les hacemos llegar un documento donde se recogen algunos errores frecuentes y una serie de recomendaciones para subsanar los mismos.

Cualquier sugerencia o aportación no duden en trasladárnosla.

Un saludo.

Hola thinkows y resto de colegas sufridores.

Acabo de contestar el email pidiendo que publiquen una aclaración:

Hola,

Gracias por la información.

Como sugerencia, en la página 3 del documento enviado, donde indica:
- ImporteTotal de línea debe ir siempre con IVA (salvo si es exenta o no sujeta)
Debería indicar:
- ImporteTotal de línea debe ir siempre con IVA (y RE en caso de llevarlo) (salvo si es exenta o no sujeta)
A raíz de una consulta que hicimos a Álava y a Gipuzkoa, cada una de las dos administraciones respondió de forma diferente sobre si ese campo de ImporteTotal de la línea de detalle debe o no incluir el RE (en el caso de que el destinatario esté en dicho régimen).
Álava nos indicó que sí debía ir incluído (aunque en la tabla de estructura de TicketBAI no se indica).
Gipuzkoa nos indicó que no debía ir incluído.
Posteriormente, Gipuzkoa rectificó su criterio y nos lo comunicó, en posterior email.

Por ello, sería de gran interés para todos los desarrolladores de software garante TicketBAI que en el documento de recomendaciones que nos han enviado se rectificase el texto indicado.

Y que también se tenga en cuenta la rectificación en próximas versiones de la tabla de la estructura del fichero TicketBAI.

Un cordial saludo

Saludos

[Sistel]

Empezado por keys

...Pero sólo responden con buenas palabras, pero na de na. ¿se os ocurre alguna otra forma?

¿Tal vez apostándose en la puerta e increpando a los responsables?

La verdad es que ante las decisiones unilaterales, absurdas y a traición que van tomando sin consultar lo más mínimo a los perjudicados (desarrolladores de software garante) no podemos ejercer ningún tipo de presión.

Nos ignoran olímpicamente y no nos queda más que aguantar.

[keys]

Empezado por Sistel

¿Tal vez apostándose en la puerta e increpando a los responsables?

La verdad es que ante las decisiones unilaterales, absurdas y a traición que van tomando sin consultar lo más mínimo a los perjudicados (desarrolladores de software garante) no podemos ejercer ningún tipo de presión.

Nos ignoran olímpicamente y no nos queda más que aguantar.

Cuando decia si se os ocurre otra forma, es la de como comprobar los certificados no como comunicarnos con hacienda. Ya que creo que de eso ya estamos todos de acuerdo de como hacerlo

[tejano]

Empezado por keys

Cuando decia si se os ocurre otra forma, es la de como comprobar los certificados no como comunicarnos con hacienda. Ya que creo que de eso ya estamos todos de acuerdo de como hacerlo

Hola Keys, yo tengo metido en la Base de datos el usuario y certificado que puede usar, de forma que no puede utilizar otro.

Esto sería un tema del admisnitrador del sistema, de forma que si se equivoca el administrador del sistema en poner un usuario u otro creo que ya no es competencia nuestra.

Espero que te sirve la idea.

Saludos

[keys]

Empezado por tejano

Hola Keys, yo tengo metido en la Base de datos el usuario y certificado que puede usar, de forma que no puede utilizar otro.

Esto sería un tema del admisnitrador del sistema, de forma que si se equivoca el administrador del sistema en poner un usuario u otro creo que ya no es competencia nuestra.

Espero que te sirve la idea.

Saludos

Gracias, más o menos estamos haciendo lo mismo. Pero claro hasta que no hace el envío no sabemos si el certificado con el que firma es correcto o no para hacienda.

[ermendalenda]

Por si os viene bien la información.
Problema con un cliente y me he enterado a las 2 semanas. Le pongo última actualización a mediados de diciembre y hace un Par de semanas tiene corte de luz y el equipo le pregunta si quiere continuar el arranque o restaurar.
El cliente sin saber realmente lo que está haciendo, a él le parece bien, por que en su casa le ha pasado y se arregló, restaura y como aparentemente sigue funcionando bien pues sigue adelante, hasta que como estoy haciendo seguimiento miro el xml y veo algo raro... Joder vaya tela.
Veo el mismo fallo que tenía y al mirar la versión que grabó en el xml tb veo que es la anterior.
Vaya tela. No se cuantas cosas nos va a pasar. Deberíamos hacer un manual de posibles incidencias no contempladas. Vaya desastre.

[Sistel]

Empezado por keys

Gracias, más o menos estamos haciendo lo mismo. Pero claro hasta que no hace el envío no sabemos si el certificado con el que firma es correcto o no para hacienda.

Hola keys,

El tema de utilizar certificados del cliente tiene sus problemas:
- Tienes acceso a dicho certificado por lo que podrías utilizarlo de forma fraudulenta (por ejemplo, para hacer "gestiones bancarias" en su nombre)
- Si el certificado es revocado, por cualquier razón, tú no te enteras.
- Cuando solicita renovación del certificado, se le revoca antes de tener el nuevo.
- Tienes que vigilar que esté en vigor cada vez que va a hacer una nueva factura o un nuevo envío
- ...

Yo en lugar de utilizar el certificado digital del cliente, utilizo para firmar los XML del cliente un certificado digital mío (que controlo en mi propio servidor).
Marco el campo EmitidaPorTercerosODestinatario como S y solucionado.
Y para enviar los XML también utilizo mi certificado.
Por supuesto, antes el cliente tiene que firmar un acuerdo por el que me autoriza a crear, firmar y enviar las facturas a Hacienda Foral en su nombre.
Y registro la representación en la correspondiente Hacienda Foral.

Y juego con dos certificados (FNMT e Izenpe).
Cuando tengo que renovar el que estoy utilizando, lo cambio por el otro mientras estoy haciendo dicha renovación (con su correspondiente revocación del antiguo)

Saludos

[ermendalenda]

Empezado por keys

Gracias, más o menos estamos haciendo lo mismo. Pero claro hasta que no hace el envío no sabemos si el certificado con el que firma es correcto o no para hacienda.

Hay formas de probarlo

[keys]

Empezado por ermendalenda

Hay formas de probarlo

Cuales? Me tienes en ascuas?

[keys]

Empezado por Sistel

Hola keys,

El tema de utilizar certificados del cliente tiene sus problemas:
- Tienes acceso a dicho certificado por lo que podrías utilizarlo de forma fraudulenta (por ejemplo, para hacer "gestiones bancarias" en su nombre)
- Si el certificado es revocado, por cualquier razón, tú no te enteras.
- Cuando solicita renovación del certificado, se le revoca antes de tener el nuevo.
- Tienes que vigilar que esté en vigor cada vez que va a hacer una nueva factura o un nuevo envío
- ...

Yo en lugar de utilizar el certificado digital del cliente, utilizo para firmar los XML del cliente un certificado digital mío (que controlo en mi propio servidor).
Marco el campo EmitidaPorTercerosODestinatario como S y solucionado.
Y para enviar los XML también utilizo mi certificado.
Por supuesto, antes el cliente tiene que firmar un acuerdo por el que me autoriza a crear, firmar y enviar las facturas a Hacienda Foral en su nombre.
Y registro la representación en la correspondiente Hacienda Foral.

Y juego con dos certificados (FNMT e Izenpe).
Cuando tengo que renovar el que estoy utilizando, lo cambio por el otro mientras estoy haciendo dicha renovación (con su correspondiente revocación del antiguo)

Saludos

Buena solución, pero para nosotros que se trata de intalaciones en los equipos del cliente (con muchas instalaciones), sería un poco complicado.

[Sistel]

Hola,

Os comenté, hace unos días, que les escribí a TicketBAI de Álava a raíz de su último email con recomendaciones sobre el software:

...
Como sugerencia, en la página 3 del documento enviado, donde indica:
- ImporteTotal de línea debe ir siempre con IVA (salvo si es exenta o no sujeta)
Debería indicar:
- ImporteTotal de línea debe ir siempre con IVA (y RE en caso de llevarlo) (salvo si es exenta o no sujeta)
A raíz de una consulta que hicimos a Álava y a Gipuzkoa, cada una de las dos administraciones respondió de forma diferente sobre si ese campo de ImporteTotal de la línea de detalle debe o no incluir el RE (en el caso de que el destinatario esté en dicho régimen).
Álava nos indicó que sí debía ir incluído (aunque en la tabla de estructura de TicketBAI no se indica).
Gipuzkoa nos indicó que no debía ir incluído.
Posteriormente, Gipuzkoa rectificó su criterio y nos lo comunicó, en posterior email.

Por ello, sería de gran interés para todos los desarrolladores de software garante TicketBAI que en el documento de recomendaciones que nos han enviado se rectificase el texto indicado.

Y que también se tenga en cuenta la rectificación en próximas versiones de la tabla de la estructura del fichero TicketBAI.

Me acaban de contestar:

Hemos revisado lo que nos indicas y lo vamos a corregir lo antes posible para volverlo a publicar lo antes posible.
Muchas gracias por su aportación y tener el detalle de comunicárnoslo.

Esperemos ver pronto esas, y otras, rectificaciones.

Saludos

[nuevo1234]

Hola a todos,

Me ha parecido leer en el foro que se debe pasar el fichero XML a base 64 anter de firmar. Aparece eso publicado en algún sitio?? o es solo una recomendación para evitar problemas con los caracteres "raros".

Entiendo que si es una obligación hacerlo así debe estar claramente puublicado para que pase las validaciones de la firma al presentar el fichero.

Gracias de antemano. Es que la firma me preocupa bastante.

[Neftali [Germán.Estévez]]

Empezado por nuevo1234

Me ha parecido leer en el foro que se debe pasar el fichero XML a base 64 anter de firmar. Aparece eso publicado en algún sitio?? o es solo una recomendación para evitar problemas con los caracteres "raros".
Entiendo que si es una obligación hacerlo así debe estar claramente puublicado para que pase las validaciones de la firma al presentar el fichero.

Sí hay que hacerlo así en el caso de Vizcaya. En Álava y Guipuzcoa no hay que pasar a base64.
Aquí tienes los pasos (resumen comprimido) para Vizcaya en el caso de los libro 140/240.En la documentación está explicado.
Documento_ Batuz_LROE_Especificaciones_Envío_Masivo_V1_0_7.pdf

[Sistel]

Empezado por nuevo1234

Hola a todos,

Me ha parecido leer en el foro que se debe pasar el fichero XML a base 64 anter de firmar. Aparece eso publicado en algún sitio?? o es solo una recomendación para evitar problemas con los caracteres "raros".

Entiendo que si es una obligación hacerlo así debe estar claramente puublicado para que pase las validaciones de la firma al presentar el fichero.

Gracias de antemano. Es que la firma me preocupa bastante.

Hola nuevo1234,

Como muy bien te ha explicado nuestro colega Neftali [Germán.Estévez], hay que pasarlo sólo a base64 en el caso del envío a Bizkaia.
Pero ojo, siempre hay que firmar previamente el XML (igual para las 3 provincias)

Saludos