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

[jsanznub]

Empezado por sEngine

No se como lo teneis puesto pero yo lo tengo asi al crear la firma y me funciona (uso el autofirma). Teneis puesto lo de format?

y segun google

XAdES-BES. Forma básica que simplemente cumple los requisitos legales de la Directiva para firma electrónica avanzada
XAdES-EPES. Es un XAdES-BES al que se le incorpora información sobre la política de firma, como pudiera ser aquella información sobre el certificado empleado y la CA que lo emitió.

Gracias por la respuesta sEngine, no me soluciono el problema directamente pero me ha ayudado a encontrarlo. Firme el documento con autofirma y puede comprobar que la única diferencia real con el fichero que firmaba yo estaba en un elemento del xml.

Yo tenía (edito los enlace para poder publicar):

<xades:QualifyingProperties xmlns:xades="uri.etsi.org/01903/v1.3.2/XAdES.xsd" xmlns:ds="w3.org/2000/09/xmldsig#" .....

y en el resultado de autofirma era:

<xades:QualifyingProperties xmlns:xades="uri.etsi.org/01903/v1.3.2#" xmlns:ds="w3.org/2000/09/xmldsig#".....

Esa definición diferente del namespace de xades estaba provocando que Bizkaia rechazará el fichero porque no consideraba que fuera una firma EPES sino BES . En fin, tema resuelto, espero que os pueda resultar útil a alguno y no perdáis tanto tiempo como yo.

[unomasmas]

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

Así a primeras, echo en falta el bloque de <Software> que está vacío (tal vez porque lo has eliminado para que se vean los datos).

Sí, ahí van las etiquetas de código y nif... Lo eliminé para ocultar los datos... Gracias Neftali [Germán] . Me imagino que con lo tocho de mi respuesta (reconozco que con tanta cita se hace un poco difícil de seguir) no viste que tanto tú como b4aronDeLaBirr4 supisteis ponerme en la pista de la solución al problema: tanto la firma como la conexión parece que es necesario hacerla con el certificado con el que te das de alta en el servicio. A partir de ahí ya funcionó todo. Pude haberme ahorrado poner el fichero que intentaba enviar y también te hubiera ahorrado que perdieras el tiempo revisándolo pero lo hice más que nada para tener un ejemplo completo (bueno, sin las etiquetas de software, pero estas no debieran ser un problema para nadie por lo simples que son) y porque me lo habíais pedido... Te/os lo agradezco nuevamente

[CMB]

¿Alguien ha analizado los aspectos legales? He encontrado una situación que me parece bastante peligrosa, y está en la normativa de las 3 diputaciones. Ver por ejemplo apartado 3b del artículo 133 bis de la Norma Foral del Impuesto de Sociedades de Gipuzkoa, y especialmente el apartado c donde definen lo que ellos consideran que significa "intervenir" (el mismo texto o muy parecido está en el artículo análogo del IRPF, o en los de las demás diputaciones).

• c)   Cuando el contribuyente haya desarrollado el software y a su vez haya cometido la infracción prevista en la letra b) del apartado 1 anterior, ésta se sancionará según lo dispuesto en la letra a) de este apartado.
  A los efectos de este apartado, se considerará que una persona o entidad ha intervenido en la destrucción, borrado o manipulación a que se refiere la letra b) del apartado 1 anterior, entre otros supuestos, cuando:
  • - Haya alterado el sistema informático o software, archivos o ficheros informáticos.
  • - Haya tenido o tenga, de alguna forma, el control sobre el sistema informático o software, archivos o ficheros informáticos.
  • - Disponga o ponga a disposición de otras personas o entidades, sistemas, medios o métodos para las citadas destrucción, borrado o manipulación.
  • - Haya dictado, facilitado o mostrado instrucciones para las citadas destrucción, borrado o manipulación.
  • - Realice una acción u omisión que, aunque por sí sola no tenga entidad suficiente para ser considerada destrucción, borrado o manipulación, se trate de una acción u omisión que forma parte de dicho proceso y que, unida a la actuación u omisión de otras personas o entidades, conlleva las citadas destrucción, borrado o manipulación.

Resulta que si...

• El software es una aplicación que se ejecuta en el ordenador del usuario, y en consecuencia los datos están bajo el control del usuario final.
• El usuario por su cuenta logra borrar o manipular los ficheros TBAI.
• La administración considera que la entidad desarrolladora del software no ha hecho lo suficiente para impedírselo (omisión).

entonces se sancionará a la entidad desarrolladora con una multa de 40.000€.

A mi me parece que el redactor de esta ley no se da cuenta de como funciona un ordenador. Si el software está en un ordenador controlado por el usuario y los ficheros también, en última instancia es el usuario quien tiene el control de dichos ficheros. ¿Cómo vamos a impedirle que los modifique?

Naturalmente se podrían adoptar medidas para dificultarlo. Por ejemplo se podrían cifrar los ficheros, o firmar y verificarlos cada vez que abrimos el programa. ¿Pero son suficientes? Siempre se pueden hacer más cosas. Y un usuario con suficientes conocimientos y recursos puede saltárselas. La normativa no nos dice claramente qué medidas debemos adoptar, por lo que hagámos lo que hagámos estaremos en riesgo.

Por no hablar, naturalmente, de la posibilidad de que el usuario directamente desinstale el programa y borre todos los ficheros. ¿Como vamos a impedir esto?

[Galaxian]

Empezado por CMB

¿Alguien ha analizado los aspectos legales? He encontrado una situación que me parece bastante peligrosa, y está en la normativa de las 3 diputaciones. Ver por ejemplo apartado 3b del artículo 133 bis de la Norma Foral del Impuesto de Sociedades de Gipuzkoa, y especialmente el apartado c donde definen lo que ellos consideran que significa "intervenir" (el mismo texto o muy parecido está en el artículo análogo del IRPF, o en los de las demás diputaciones).

• c)   Cuando el contribuyente haya desarrollado el software y a su vez haya cometido la infracción prevista en la letra b) del apartado 1 anterior, ésta se sancionará según lo dispuesto en la letra a) de este apartado.
  A los efectos de este apartado, se considerará que una persona o entidad ha intervenido en la destrucción, borrado o manipulación a que se refiere la letra b) del apartado 1 anterior, entre otros supuestos, cuando:
  • - Haya alterado el sistema informático o software, archivos o ficheros informáticos.
  • - Haya tenido o tenga, de alguna forma, el control sobre el sistema informático o software, archivos o ficheros informáticos.
  • - Disponga o ponga a disposición de otras personas o entidades, sistemas, medios o métodos para las citadas destrucción, borrado o manipulación.
  • - Haya dictado, facilitado o mostrado instrucciones para las citadas destrucción, borrado o manipulación.
  • - Realice una acción u omisión que, aunque por sí sola no tenga entidad suficiente para ser considerada destrucción, borrado o manipulación, se trate de una acción u omisión que forma parte de dicho proceso y que, unida a la actuación u omisión de otras personas o entidades, conlleva las citadas destrucción, borrado o manipulación.

Resulta que si...

• El software es una aplicación que se ejecuta en el ordenador del usuario, y en consecuencia los datos están bajo el control del usuario final.
• El usuario por su cuenta logra borrar o manipular los ficheros TBAI.
• La administración considera que la entidad desarrolladora del software no ha hecho lo suficiente para impedírselo (omisión).

entonces se sancionará a la entidad desarrolladora con una multa de 40.000€.

A mi me parece que el redactor de esta ley no se da cuenta de como funciona un ordenador. Si el software está en un ordenador controlado por el usuario y los ficheros también, en última instancia es el usuario quien tiene el control de dichos ficheros. ¿Cómo vamos a impedirle que los modifique?

Naturalmente se podrían adoptar medidas para dificultarlo. Por ejemplo se podrían cifrar los ficheros, o firmar y verificarlos cada vez que abrimos el programa. ¿Pero son suficientes? Siempre se pueden hacer más cosas. Y un usuario con suficientes conocimientos y recursos puede saltárselas. La normativa no nos dice claramente qué medidas debemos adoptar, por lo que hagámos lo que hagámos estaremos en riesgo.

Por no hablar, naturalmente, de la posibilidad de que el usuario directamente desinstale el programa y borre todos los ficheros. ¿Como vamos a impedir esto?

Una normativa parecida rige desde hace años a nivel nacional. Aún así, hicimos una consulta sobre la posibilidad de cifrar los ficheros TBAI, pero nos dijeron que estos tienen que estar a la disposición de los inspectores que, eventualmente, necesitaran consultarlos.

De todos modos la cosa no es tan grave porque solo sancionarán a las empresas cuyos programas tengan herramientas específicas para alterar o borrar los datos. Es decir, que si aún lo hacéis, se acabó lo de permitir modificar o borrar facturas emitidas aunque los usuarios digan que "la tengo en la mano y aún no se la he dado al cliente". En esos casos rectificativa al canto, pues puede llegar a ser considerado falsedad en documento público... y a nosotros cómplices. Casi nada.

[Sistel]

Hola,

Me ha llegado información sobre la II Feria TicketBAI organizada por la Cámara de Gipuzkoa.
Os anexo el documento PDF.

Saludos

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

Gracias.
No se si la cosa está para muchas ferias hora...

[e.jaume]

Buenas a tod@s,
Este foro me ha servido de gran ayuda para completar el desarrollo de envío de facturas a ticketBAI en Gipuzkoa, os agradezco a todos el esfuerzo y la dedicación, muchas gracias.
Me he animado a escribir porque tengo una duda relacionada con el envío de facturas. He llegado a este punto donde no se qué mas probar, y es que no consigo salir del bucle de este error:
"El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)"
La factura se envío en utf-8, he comprobado con el Tortoise y no se modifica durante el proceso de firma, la empresa no contiene caracteres raros...etc.
Programo en C# y utilizo la librería FirmaXadesNet45
La verdad que no se por dónde más tirar, cualquier ayuda os lo agradezco.


P.D: Perdón por la pregunta de la que ya se ha hablado mucho y también he leído todas las páginas del foro y he probado casi de todo XD

[Sistel]

Empezado por e.jaume

Buenas a tod@s,
Este foro me ha servido de gran ayuda para completar el desarrollo de envío de facturas a ticketBAI en Gipuzkoa, os agradezco a todos el esfuerzo y la dedicación, muchas gracias.
Me he animado a escribir porque tengo una duda relacionada con el envío de facturas. He llegado a este punto donde no se qué mas probar, y es que no consigo salir del bucle de este error:
"El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)"
La factura se envío en utf-8, he comprobado con el Tortoise y no se modifica durante el proceso de firma, la empresa no contiene caracteres raros...etc.
Programo en C# y utilizo la librería FirmaXadesNet45
La verdad que no se por dónde más tirar, cualquier ayuda os lo agradezco.


P.D: Perdón por la pregunta de la que ya se ha hablado mucho y también he leído todas las páginas del foro y he probado casi de todo XD

Hola e.jaume,

Si ya has probado todo lo que se ha comentado sobre ese error, y sigues igual, mi recomendación es que contactes con Hacienda Foral de Gipuzkoa (ticketbaikontsultak@gipuzkoa.eus).
En el título del email pones: “Pruebas TicketBAI en PRE: Nombre Empresa”
Y pones como categoría del tema: "Errores en envío de facturas"
Les envías los datos de lo que estás enviando y el error y ellos te dirán a qué puede ser debido.

Saludos

[jaiser]

Empezado por Sistel

Hola,

Acabo de recibir email de la Diputación Foral de Gipuzkoa.



Será el jueves 29 de julio de 13:00 h a 14:30 h

Saludos

Hola, como te puedes apuntar a la sesión informativa? hay algún enlace?, Me autocontesto ya he visto en la web que hay un correo para apuntarse.

Para participar, envíe un correo electrónico a ticketbaikontsultak@gipuzkoa.eus y escriba " Sesión informativa para desarrolladores " sobre el tema .

[unomasmas]

Empezado por JoseLeeTo

Buenas. Yo también estoy con C#, aunque no utilizo RestSharp, sino HttpClient. En el caso del problema 2, tiene pinta de que el nombre del emisor de la factura, no coincide con el del certificado, y así tiene que ser.
El certificado tiene que ser el del propio obligado tributario, que tiene que coincidir con el emisor de la factura.

Perdona JoseLeeTo, no vi tu respuesta hasta hoy. Es un poco lioso que en un único tema tengamos todas las conversaciones. Gracias por tu aporte; ya lo tengo comprobado y, efectivamente, ese era el problema. Con RestSharp no he podido solucionarlo pero funciona perfectamente con HttpClient así que...

Ahora estoy intendo la conexión con Bizkaia (https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena); por lo pronto no consigo ni conectar: "Anulada la solicitud: No se puede crear un canal seguro SSL/TLS."

[unomasmas]

Empezado por JoseLeeTo

Buenas!;

Desde la Subdirección General de Estrategia Tecnológica queremos invitarles a una sesión informativa dirigida a todas aquellas personas o entidades que estén desarrollando softwares garantes para cumplir con las nuevas obligaciones tributarias establecidas por las diputaciones forales.


Los temas que se tratarán en dicha sesión informativa son los siguientes:

1. Nuevo servicio Rest ZUZENDU para subsanar y modificar.
2. Listado de validaciones síncronas y asíncronas.
3. Claves del encadenamiento.
4. Recomendaciones para evitar errores y avisos.
5. Claves TicketBAI.
6. Certificados electrónicos.

Consideramos que los temas a tratar son de gran interés para el correcto desarrollo de sus respectivos softwares.


¿Alguien ha hecho o conoce algo al respecto?

Saludos y Gracias.

Que yo sepa, hasta ahora es tal y como dices: Sólo alta y anulación. Pero en esa reunión parece que se va abordar la posibilidad de modificaicón. ¿Tienes más info sobre la reunión? ¿Dónde es? ¿Algún enlace? Gracias.

[aflores1]

Empezado por unomasmas

Perdona JoseLeeTo, no vi tu respuesta hasta hoy. Es un poco lioso que en un único tema tengamos todas las conversaciones. Gracias por tu aporte; ya lo tengo comprobado y, efectivamente, ese era el problema. Con RestSharp no he podido solucionarlo pero funciona perfectamente con HttpClient así que...

Ahora estoy intendo la conexión con Bizkaia (h t t p s ://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena); por lo pronto no consigo ni conectar: "Anulada la solicitud: No se puede crear un canal seguro SSL/TLS."

Agrega esto en tu codigo:

Código Delphi [-]
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

[unomasmas]

Empezado por Eric Mtz

Veréis, el señor "rci" antes de irse de vacaciones me informó de que se pueden hacer consultas referentes a envíos específicos dentro del sistema, concretamente se deben de indicar los siguientes campos:
El caso es que rellené los datos y he recibido una respuesta tronchante:

Cita: En el entorno de pruebas del sistema de envíos masivos del LROE los datos del interesado y del presentador que se envían en las peticiones al servicio web deben existir en el sistema, ya que se validan. No se deben utilizar razones sociales o nombres y apellidos ficticios ya que se valida tanto el NIF como la razón social, para el caso de la persona jurídica y el nombre y apellidos para la persona física.

Pregunta estúpida, para que COÑO queremos un entorno de pruebas si únicamente aceptan datos reales!?!?!?!?!?!?, además, esto contrasta con Gipuzkoa donde debes de solicitar incluso una licencia ficticia que te lo facilitan ellos para el propio entorno de pruebas. Es como que uno te ayuda y el otro te da un bofetazo con la mano abierta y con los anillos puestos... Bueno pues eso, ahí queda documentado por si alguien pasa por algo parecido.!

Gracias por tu aporte. No sé si me está pasando algo pareceido: "Anulada la solicitud: No se puede crear un canal seguro SSL / TLS.". Según la respueseta que te han dado, necesariamente tienes que estar registrado en Bizcaia como contribuyente ¿no? ¿Lo entiendo mal?

[Sistel]

Empezado por unomasmas

Que yo sepa, hasta ahora es tal y como dices: Sólo alta y anulación. Pero en esa reunión parece que se va abordar la posibilidad de modificaicón. ¿Tienes más info sobre la reunión? ¿Dónde es? ¿Algún enlace? Gracias.

Hola unomasmas,

https://www.gipuzkoa.eus/es/web/ogas...formazio-saioa

Saludos

[aflores1]

Alguno ha recibido información de la reunión, les mandé correo para participar y no tengo noticias

[e.jaume]

Empezado por Sistel

Hola e.jaume,

Si ya has probado todo lo que se ha comentado sobre ese error, y sigues igual, mi recomendación es que contactes con Hacienda Foral de Gipuzkoa (ticketbaikontsultak@gipuzkoa.eus).
En el título del email pones: “Pruebas TicketBAI en PRE: Nombre Empresa”
Y pones como categoría del tema: "Errores en envío de facturas"
Les envías los datos de lo que estás enviando y el error y ellos te dirán a qué puede ser debido.

Saludos

Gracias Sistel! Les envié varios correos el viernes, aún estoy esperando respuesta, supongo que tardarán en contestar debido a las vacaciones.
Como tampoco puedo compartir código por el foro, poco más puedo hacer. A ver si en la sesión informativa pueden aclarar ese punto. ¿Habéis encontrado algún ejemplo que sea bastante claro de cómo montar una firma XAdES Enveloped en C#?

un saludo!

[e.jaume]

Empezado por Sistel

Hola e.jaume,

Si ya has probado todo lo que se ha comentado sobre ese error, y sigues igual, mi recomendación es que contactes con Hacienda Foral de Gipuzkoa (ticketbaikontsultak@gipuzkoa.eus).
En el título del email pones: “Pruebas TicketBAI en PRE: Nombre Empresa”
Y pones como categoría del tema: "Errores en envío de facturas"
Les envías los datos de lo que estás enviando y el error y ellos te dirán a qué puede ser debido.

Saludos

Hola! al final sí que me han respondido hoy. Me han dicho que es por la codificación, en alguna parte se está realizando la modificación de los caracteres que tienen tilde.
El envío lo estoy realizando de esta forma pero no encuentro que se cambie la codificación...

            HttpWebRequest request = (HttpWebRequest)WebRequest.Create(serviceUri);

            byte[] bytes = Encoding.UTF8.GetBytes(comunicacionXml);

            request.ContentType = "application/xml;charset=utf-8";
            request.ContentLength = bytes.Length;
            request.Method = WebRequestMethods.Http.Post;
            request.ClientCertificates.Add(certs);

            Stream requestStream = null;

            try
            {                
                requestStream = request.GetRequestStream();
                requestStream.Write(bytes, 0, bytes.Length);
                requestStream.Flush();
            }
            finally
            {
                if (requestStream != null)
                {
                    requestStream.Close();
                }
            }

            HttpWebResponse response = (HttpWebResponse)request.GetResponse();

¿Se le ocurre alguien alguna idea por disparatada que sea?

Gracias!

[adolphsys]

Empezado por aflores1

Alguno ha recibido información de la reunión, les mandé correo para participar y no tengo noticias

El miércoles, cuando recibí el correo, confirmé la asistencia pero por ahora tampoco he recibido confirmación.

[jaiser]

Hola!

Tengo una duda sobre la anulación y su contabilización. Si se envia un ticket bai con una factura hay que enviar un ticket bai de anulación y no se puede reutilizar dicho número de factura. No se si está factura al estar anulada no hay que contabilizarla ni enviarla al SII? Habría huecos entonces en la númeración de las facturas en la contabilidad y en el sii. He llamado a guipuzkoa y me han dicho que NO se contabiliza NI se envia al sii, pero no se si realmente es asi, me entran dudas sobre los huecos. Lo más normal será hacer una rectificativa pero en algún caso habrá que preveer el poder anular.

[jaiser]

Empezado por adolphsys

El miércoles, cuando recibí el correo, confirmé la asistencia pero por ahora tampoco he recibido confirmación.

Hola, yo les envie ayer un email y tampoco me han contestado