![]() |
Cita:
|
Cita:
Batuz = Fichero_TicketBAI [1..N] incrustado en LROE => Bizkaia TicketBAI = Fichero_TicketBAI [1] => Guipuzkoa y Árava |
Cita:
Tal como dice [keys] como es algo nuevo, se supone que en la reunión lo explicarán y publicarán los esquemas y ejemplos. NOTA: Los más listos, los de Álava, que están esperando que los demás se den de cabezazos contra las paredes hasta que lo tengan claro y luego entrar ellos (al menos espero que aprovechen la "experiencia" de los ortros 2). |
Esperemos que en Alava se inspiren en lo que tienen en Guipuzkoa, asi no habra que hacer muchos cambios
|
Cita:
He preguntado directamente a Álava sobre su implantación, y me reponden lo siguiente: En la Disposición Transitoria Única se establece el calendario previsto de implantación que, conforme a lo dispuesto en el punto 3, la Diputada Foral de Hacienda, Finanzas y Presupuestos podrá modificar mediante la oportuna Orden Foral. 01/01/2022 voluntario 01/04/2022 asesorías 01/07/2022 actividades profesionales y farmacias 01/10/2022 el resto de contribuyentes Saludos |
Cita:
Las especificaciones indican que la firma debe ser de tipo EPES y en vuestro caso la firma que incluís es de tipo BES. Hasta donde yo se la diferencia entre una firma BES y una EPES es justamente la introducción de la información contenida en esos parámetros. Sigo mirándolo, si encuentro algo lo compartiré por aquí. |
Cita:
Cita:
Bueno, recordad que estamos todos en formación testudo, dicho de otra manera somos una piña, si encuentro alguna solución os la podré por aquí, venga ánimo a todos. |
Cita:
En una pelea de gallos es fácil distinguir a cada uno. El de Bizkaia lleva un gallo. El de Gipuzkoa lleva un pato. Y el de Álava es el que apuesta por el pato. Saludos y perdón por el inciso, pero no he podido aguantarme :D |
Cita:
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ó. |
Cita:
Ese NIF no es español. Creo que debes detallarlo así: <Destinatarios> <IDDestinatario> <IDOtro> <IDType>04 (o el que corresponda)</IDType> <ID>NL855820627B01</ID> </IDOtro> <ApellidosNombreRazonSocial>ITX MERKEN B.V.</ApellidosNombreRazonSocial> </IDDestinatario> </Destinatarios> Valores posibles para IDType: 02 NIF-IVA. 03 Pasaporte. 04 Documento oficial de identificación expedido por el país o territorio de residencia. 05 Certificado de residencia. 06 Otro documento probatorio. |
Enviar Alta a Gipuzkoa (en pruebas)
Tengo problemas para subir el fichero de alta TicketBAI al entorno de pruebas de Gipuzkoa. No entiendo muy bien qué está ocurriendo. Estoy haciendo el script en C#. En los diferentes métodos que he empleado me ocurren dos tipos de problema:
[Problema 1:] Código:
<ResultadosValidacion>Código:
string urlconexion = "h t t p s://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta";IRestResponse es un contenedor de RestSharp que recoge la respuesta del servidor. certificate es una instancia de la clase X509Certificate2 de System.Security.Cryptography.X509Certificates [Problema 2:] Código:
<ResultadosValidacion>Código:
string urlconexion = "h t t p s://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta";certificate es igualmente una instancia de la clase X509Certificate2 de System.Security.Cryptography.X509Certificates Me imagino que en este segundo caso el problema puede estar en la manipulación del fichero (por haberlo subido como stream) pero no veo cómo comprobarlo. Si alguien me pudiera echar una mano se lo agradecería tanto como el tiempo que llevo tratando de encontrar una solución (un mogollón). Gracias ya por haberme leido. |
Buenas!
Yo también estoy desarrollando la solución en C# así que a ver si algo te puedo ayudar... En primer lugar, si podrías postear el fichero XML que envías y que también me dijeras qué certificado estás usando. Cabe recordar que el orden de los elementos en el XML es importante que sea acorde al XSD y que la petición de alta al servicio la estés realizando con el certificado también (además de firmar con él), aunque veo que sí, podrías probar en POSTMAN previamente o algo. Yo hice esto para ir descartando estos errores, te lo recomiendo. Por cierto, cómo estás firmando el XML? (Esto ya porque a mí me interesa ver otras opciones jeje) Un saludo. |
Cita:
Lo digo por compararlo con otros. También puedes comprar tú mismo la estructura del que estás enviando con algunos de los ejemplos que hay en los mensajes del foro o los que te puedes descargar, a ver si te estás olvidando algún nodo (ya no sólo de los datos, sino de las firmas,...) En cuanto al segundo, si revisas mensajes anteriores ya hemos hablado de él también. El certificado debe ser válido (de producción por decirelo así), no valen certificados de prueba. ¿Qué tipo de certificado estás utilizando? También puedes escribirles un mail con el fichero que estás enviando y los errores que te dan; Para el primer caso te dirán qué te falta y para el segundo caso, te darán de alta el certificado (si es necesario) y lo asociarán a los datos que estás usando para el envío (NIF / RAZON SOCIAL). |
Cita:
|
Cita:
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. |
Cita:
Cita:
Código:
<?xml version="1.0" encoding="utf-8"?>Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Código:
public void FirmaDoc()Cita:
Cita:
Código:
<ResultadosValidacion> |
Firma XML
Cita:
Código PHP:
|
Cita:
No hice nada especial: Incluí la dll como referencia (directamente, sin NuGet) y también sus dependencias (BouncyCastle.Crypto y Microsoft.Xades) y simplemente con el método que pasé antes firma sin problemas. Es posible que tu librería no se corresponda con la versión .Net con la que apunta. Yo uso Net Framework 4.5 y la versión 2.1.0.0 de la librería. Por lo demás, confirmo que con el cambio de certificado funcionó bien la subida. Sólo dió una advertencia pero la tienen documentada: "Factura recibida pero resultado indica: 010 posible error de encadenamiento. Si se trata de la primera factura enviada por un sistema de facturación, es normal recibir este mensaje. Si se produce este aviso solo en la primera factura, es correcto. Esa primera factura generará un aviso informativo relativo a posible encadenamiento incorrecto (esto es normal) y ya las facturas sucesivas ya no darán ningún aviso, al ir correctamente encadenadas. Si se produce en las facturas sucesivas, revisar que se encadena de acuerdo a las especificaciones" |
Y ese dll me lo podrías pasar? o dejarme el enlace? Porque me imagino que te refieras a esta librería no?
|
Cita:
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). Cita:
|
Cita:
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 :mad: . En fin, tema resuelto, espero que os pueda resultar útil a alguno y no perdáis tanto tiempo como yo. |
Cita:
|
Respecto al borrado y manipulación de ficheros TBAI
¿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).
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? |
Cita:
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. |
Hola,
Me ha llegado información sobre la II Feria TicketBAI organizada por la Cámara de Gipuzkoa. Os anexo el documento PDF. Saludos |
^\||/^\||/^\||/^\||/
Gracias. No se si la cosa está para muchas ferias hora...:o:o |
Presentación y duda con el Error 008
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 |
Cita:
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 ([email protected]). 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 |
Cita:
Para participar, envíe un correo electrónico a [email protected] y escriba " Sesión informativa para desarrolladores " sobre el tema . |
Cita:
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." |
Cita:
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. |
Cita:
|
Cita:
|
Cita:
https://www.gipuzkoa.eus/es/web/ogas...formazio-saioa Saludos |
Alguno ha recibido información de la reunión, les mandé correo para participar y no tengo noticias
|
Cita:
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! |
Cita:
El envío lo estoy realizando de esta forma pero no encuentro que se cambie la codificación... Código:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(serviceUri);Gracias! |
Cita:
|
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. |
Cita:
|
| La franja horaria es GMT +2. Ahora son las 13:25:33. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi