Acabo de comprobar que en Gipuzkoa ya no hace falta sustituir tampoco el símbolo + por %2B en la url del QR.
Lo admite directamente en la URL.

Hacer y deshacer...

Correcto.


Gracias.

Gracias por tu respuesta. Efectivamente, yo lo cargo de un fichero, pero también lo tengo en el almacén y seguramente por eso me funciona. No hay nada como leer (pero no lo había hecho). ¡Qué curioso! Intento ayudarte y me ayudas tú a mi. Gracias.

Supongo que es debido a que los métodos de System.Net.Http.HttpClient son asíncronos; me parece haber leído que la comunicación con los servicios de las Diputaciones ha de ser síncrono. Lo dejo aquí pero no estoy muy seguro de esto, así que corregidme si no estoy en lo cierto. Gracias

Suerte con esa nueva vía!

Pues sí, has de conservarlo no solo hasta que lo envíes sino siempre (al menos, quizás, mientras dure la obligación de conservar las facturas, pienso yo) y en ese sentido sí puede considerarse que es una locura teniendo en cuenta que ya se lo enviaste a ellos...

Y en Vizcaya todavía se multiplica el número de fichero a las otras dos Haciendas (1 por factura).



En Vizcaya está


- El xml de la factura firmada (por no hablar del inicial que está sin firmar)
- El xml de la factura firmada convertido a Base64
- el XML resumen (o como se llame) con todas las facturas que vas a subir empaquetadas en Base64
- El fichero comprimido



:eek:


Yo de momento crearé una carpeta por \empresa\ejercicio\mes y luego una \exporta (para la que subo) y otra \importa (para las respuestas).

Hola misteradrian,

Hace tiempo hice una comparativa de precios de Sello de Empresa:.
Sello de empresa Izenpe: 288,55 € - 3 años : 96,18 €/año
Sello de empresa FNMT: 360 €/año

Saludos

C# .Net envio TBAI desde un servicio => certificados # SOLUCIÓNADO #
 

Hola, gracias unomasmas y a todos los que me han contestado.


Al final he conseguido enviar TicketBAI desde nuestra aplicación de consola arancándola como servicio de Windows y con el usuario System.
Lo que he hecho es añadir el certificado al almacén de certificados del usuario desde el mismo programa justo antes de enviar y funciona!
Es la única forma que he encontrado para añadir el certificado al almacén de certificados del usuario System, porque creo que no se puede iniciar sesión en windows con ese usuario y por lo tanto no lo puedo añadir desde el navegador como en los otros usuarios normales.


Muchas gracias!

Para comprobar que el servicio esta funcionando correctamente, mandaré esto en el XML:



Creeis necesario que lo firme? no verdad?
Comprobaré que me devuelve codigo 200 para seguir y mandar ya el xml.

Hola de nuevo, releyendo y releyendo de nuevo todos los posts, he visto que el problema de que no cargue el certificado al enviar el XML a hacienda está en que hay que indicarle el protocolo de seguridad TLS12.

Código Delphi [-]
NetHTTPClient1.SecureProtocols := [THTTPSecureProtocol.TLS12];

Si no se especifica, no pasa por el evento NetHTTPClient1NeedClientCertificate, que es donde se carga el certificado. El problema es que la propiedad SecureProtocols no está en la versión Delphi XE8 que es la que utilizo. Actualizar Delphi a una versión posterior, por ahora no es una opción que pueda hacer. ¿Alguna sugerencia? ¿Cómo podría solucionarlo?

Muchas gracias!

¿Es necesario guardar todo esto?
Nosotros solamente guardamos el fichero firmado ticketBAI, comprimido dentro de un campo de la base de datos.
Las respuestas no las guardamos, solamente si se ha enviado correctamente o no y el error si es el caso.
Para batuz, a partir del fichero firmado ticketBAI siempre podemos volver a generar los otros...

¿Lo estamos haciendo mal?:confused:

Yo envío únicamente , por supuesto sin firmar, y recibo HTTP 200 cuando el servicio está activo.

Esto me suscita una duda que espero me pueda aclarar alguien:
Si se comprime un fichero XML firmado, al descomprimirse, la firma sigue siendo válida?
Gracias.

El único fichero que hay que guardar es el xml firmado y lógicamente al comprimir/descomprimir el fichero no cambia.

Gracias por la respuesta y la sugerencia anterior.
Mi base de datos es ISO-8859-1 y tenía mis dudas si, al grabar un XML firmado y después recuperarlo, éste seguiría siendo válido por el cambio de codificación.
Supongo que la mejor opción para grabar los XMLs firmados en la base de datos es comprimidos en un campo BLOB binario: me evito problemas de codificación y ahorro espacio.

Muchas gracias Keys

Creo que lo único necesario es el XML firmado de cada factura (a efectos de inspecciones).
Nosotros tampoco guardamos ni los envíos (BATUZ), ni las respuestas, ni lo generado en pasos intermedios.

Muchas gracias Neftali

A mi así me da error, Si no pongo esta parte me da error:

Hay algo que no veo claro, estoy preguntándolo pero no me contestan.


Subes una factura, da Rechazada, ese número de factura, no esta en su sistema, pero tu ya lo has utilizado. En el caso de facturas simplificadas estas deben ser correlativas tambien. No puedes seguir subiendo facturas por que ya da error de encadenamiento.



¿Como actuas en este caso?

Correcto, gran problema. O dejan un margen de fallos y se fuerza manualmente la siguiente o vamos a tener muchas incidencias y vamos a necesitar una línea 24h 365 días a la semana.

Así es como lo entiendo yo: El rechazo puede ser por varios motivos. A grandes rasgos:

1) Error del certificado usado para la conexión. Códigos 1 y 7 de Gipuzkoa. Solución: Cambiar el certificado e intentar subir nuevamente el mismo fichero de alta Ticket-BAI.
2) Error por problemas en el propio fichero Ticket-BAI (Rechazado para subsanar). Son los códigos de error 2, 3, 4 y 17 de Gipuzkoa. En Gipuzkoa se usará el servicio Zuzendu (cuando nos lo abran) para subsanarlos. En Álava supongo que sea similar. En Bizkaia, creo que habría que enviar la factura nuevamente con las oportunas correcciones en el modelo sin software garante.
3) Los otros códigos de rechazo que quedan de Gipuzkoa (5: Factura ya registrada y 6: Servicio no disponible) se explican por sí mismos.
4) Los errores de validación de negocio: En Gipuzkoa se solventarán enviando un fichero de modificación a Zuzendu o haciendo una factura rectificativa, según cada caso. En Araba supongo que igual. En Bizkaia, sigo entendiendo que lo que en Gipuzkoa se hace a través de Zuzendu, aquí será con la emisión de la factura siguiendo las especificaciones para software no garante...

Si da rechazada tienes que corregirla y volverla a enviar. Ya que la factura la has emitido. A parte tu sistema debería controlar para que no de rechazada nunca ;).

Por cierto mas noticias.

https://www.diariovasco.com/economia...192954-nt.html
https://www.gipuzkoa.eus/es/-/sei-hi...epea-gipuzkoak

Era esperable, pero nos han hecho sudar. Me gustaría saber, eso sí, qué habra pesado más en la decisión: La fragilidad del sistema o la bronca de la ciudadanía ante la inminente puesta en marcha sin poder hacer pruebas adecuadamente...

FAQ de una Hacienda Foral:
8.9 ¿Qué hay que hacer si la anotación del fichero TicketBai ha sido rechazada
al enviarse a Hacienda?

Si la anotación del fichero TicketBAI ha sido rechazada al enviarse a Hacienda por incumplimiento de esquema o de validaciones, debe operarse del siguiente modo:

En todo caso, la información de la operación debe remitirse, superando las correspondientes validaciones. Si hay información que no puede llegar por incumplimiento de las validaciones, debe llegar la información más relevante.

Si hay que modificar alguno de los contenidos de la factura a que se refiere el artículo 15 del Reglamento de facturación: Se deberá generar además una factura rectificativa, generando el fichero TicketBAI correspondiente y remitiendo la información.

Cuando se trate de una operación incorrecta (casos excluidos de poder emitir una factura rectificativa) deberá realizarse además una anulación de la operación original y, si procede, deberá generarse una nueva factura, generando un fichero TicketBAI.

Hola Sistel,
he estado preguntando a varias empresas y
muchas me ofrecen lo mismo por 100 € el año.
Aunque claro no sabemos si esos certificados funcionan para este tema de TicketBAI, a pesar de tener la misma extensión.

Pero tienes razón la más barata sigue siendo Izenpe.
Un saludo y gracias por la info.

Sisi, eso de que tu sistema debe de controlar que nunca de rechazada es muy bonito. Pero hay muchas maneras de que un cliente final pueda ''liarla''.

Fallo salida en Curl
 

Hola buenos dias,haber si alguien me puede echar un cable a cerca del envio del LROE.


Resulta que realizo el envio de los ficheros comprimidos con cURL, algo tal que así
pero me encuentro con el siguiente error

el envio del fichero llega a realizarse, al menos lo veo en el portal de batuz, pero no logro que los resultados se me lleven al fichero comprimido que le indico, de tal manera que no tengo manera de comprobar que se ha enviado correctamente y que no.


Algún alma caritativa sabria indicarme que hago mal.

No entiendo muy bien, cuando da rechazada, su sistema no guarda el fichero, por lo que no puedes anular esa factura por que en su sistema no existe.


Resumiendo:
Cuando de rechazada paralizamos la subida de facturas, hasta que nos llame el cliente para ver que coj... ha pasado, solucionarlo, subirla de nuevo manualmente, subir las demas facturas que hayan realizado mientras teniamos una rechazada y ya seguir con la marcha habitual...

INCREIBLE pero cierto! Al cliente final le va a suponer un aumento de 150€ decían? serán mensuales...

Yo creo que aunque una se rechace, puedes y debes seguir facturando, seguir generando ficheros TBAI y seguir enviando las siguientes. La primera dará "posible error de encadenamiento" porque todavía no habrán recibido la anterior.
Pero cuando puedas enviar la que se ha rechazado, con zuzendu (subsanar o modificar) para Araba y Gipuzkoa, o vía la opción... sin software garante... de bizkaia, ese "posible" error de encadenamiento ya no será real porque ya estará enviada la que se rechazo, por lo tanto entiendo y espero que esto no sea un problema de inspecciones para el obligado tributario.


El tema está en cuando salga zuzendu... como lo podremos hacer, porque yo no acabo de imaginarme como corregiremos cada caso de rechazo... coger el xml original rechazado y corregir el xml "a mano" para cada caso :eek:


Como muy bien ha dicho Keys, la clave seria que no se produjeran rechazos que requieran modificación del xml y posterior envío por la otra vía (sin firmar)


Nosotros queremos coger las validaciones de negocio publicadas en cada diputación foral y antes de salvar la venta y por lo tanto antes de crear el fichero ticketBAI, pasar nosotros esas validaciones y si no se cumplen informar al usuario que lo corrija en la venta, porque si no se corrige será una factura rechazada.
Esa es la idea pero .... es complicado :(


Corregidme por favor si me equivoco en algún punto.



Muchas gracias

Yo lo que interpreto es que la factura rechazada sí queda registrada en el sistema, pendiente de corrección, de forma que la siguiente factura que envíes, en mi opinión, debería apuntar a la rechazada como factura anterior. Por eso esperan que:
- Corrijas esa factura original
- Una vez corregida, la anules o emitas otra rectificativa, según el caso.

Solucionado
 

Ya esta resuelto el problema :).
Resulta que "--output" lo he sustituido por ">" y ha funcionado a la perfección.

Esto me dicen:

O sea, si lo he entendido bien, aparate del Zuzendu está por publicar otro procedimiento ?

"En el caso de que la factura no fuese correcta con un error material en la misma, el procedimiento para dicho caso está todavía por publicar." :D:D

De ahí el aplazamiento .... nos vamos a extinguir pronto :cool::cool:

Factura simplificada cualificada y destinatario no nacional => TipoDesglose?
 

Hola, si tenemos una factura simplificada cualificada (con los datos del destinatario) y el destinatario no es nacional, como informais el desglose? a nivel de operación o de factura?

Yo pienso que el desglose tiene que ser a nivel de operación porque el destinatario no es nacional, si lo hago de esta forma Araba y Gipuzkoa lo aceptan sin errores pero Bizkaia da el siguiente error:
B4_2000027
TipoDesglose: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando sea una factura completa y el destinatario sea extranjero (IDOtro o NIF que empiece por N). En cualquier otro caso, el desglose ha de ser a nivel de factura.

Parece ser que hay alguna incompatibilidad entre factura simplificada y desglose por tipo de operación para Batuz.

Envié un correo a las tres agencias preguntando y de Araba me contestaron:
De Bizkaia me contestaron:
De Gipuzkoa no me han contestado y pregunté hace un mes... Deben estar muy ocupados :rolleyes:


En fin, ¿tengo que hacer otra particularidad dependiendo de la diputación foral?


Muchas gracias


Saludos

QR -> URL encoding y CRC
 

Hola, he estado haciendo pruebas al generar la ruta para el QR y al final creo que Araba funciona de una forma y Bizkaia y Gipuzkoa de otra.


Estaba haciendo pruebas de QR para Araba y en un caso me contestó lo de "parámetros incorrectos". El identificador TBAI de esa factura tiene una barra /
En mi proceso para generar el QR hacia URL encoding de los valores para construir la URL y después generaba el CRC.

Para Bizkaia y Gipuzkoa esto es correcto y funciona. Pero para Araba no, pregunté y me contestaron que el CRC lo tengo que calcular antes del URL encoding.
Si lo hago de esta forma ya funciona pero claro... preferiria hacerlo siempre igual :o


Probando probando también vi que si no hago URL encoding en ningún momento, y no sustituyo la barra por %2F también funciona y funciona haciendo lo mismo para las tres diputaciones, lo cual me gusta, pero claro, en la documentación dice que tenemos que hacer el encoding y supongo que habrá algún otro carácter que no sea aceptado en una URL y falle si no lo recodifico.


Volví a preguntar a Araba y me contestaron:


Vosotros estais filtrando los valores que pasamos como parámetros en la URL del QR o no? Antes y después de generar el QR dependiendo de la diputación?:p



Muchas gracias y disculpad por tantas preguntas


Saludos

Muy excepcional, eso quisieran y quisieramos.

Eso es una putada de hilera de grabación.


En ello estamos cuando programamos,



Esto menos mal que me lo he hecho.



Únicamente creo que no es la palabra correcta, eso se usa para cuando hay que hacer algo rápido y sencillo.



Ah, sin prisa, estaremos pendientes, no tenemos nada que hacer

Acceder a los datos del certificado del emisor
 

Buenas tardes, estamos intentando hacer las máximas validaciones previas posibles antes de generar la factura y habíamos pensado en comparar los datos del certificado digital con los datos que proporciona el usuario sobre el obligado tributario. Así comprobar que los datos del emisor de la factura coinciden con el certificado digital que utilizamos tanto para firmar como para enviar. Básicamente comprobar que el NIF y la razón social coinciden.
Pero los datos que hay dentro del certificado no los estamos obteniendo de forma clara... no vemos un campo donde haya el NIF y otro con la razón social... hay varias propiedades de texto con múltiples datos dentro...
A parte es diferente para cada certificado, si es de persona física, si es de representante .... :confused:


¿Vosotros hacéis esta comprobación?
¿Alguien sabe cómo obtener el NIF y la razón social de forma clara de dentro de un certificado?

Utilizamos C#, ya tenemos el certificado en un objeto de tipo X509Certificate2

Muchas gracias y buen fin de semana!

Tendrá que ser así porque hoy me han dicho en Araba hablando de los ficheros XSD de que disponemos para la validación previa (ticketBaiV1-2.xsd) que "básicamente son validaciones de estructura y formato. Las validaciones funcionales las vais a tener que implementar vosotros". Por validaciones funcionales se refiere a las validaciones que generan un error de negocio...

Sobre el servicio Zuzendu, se tratará de enviar un fichero XML (creo recordar que sin necesidad de firma) con las correcciones (subsanaciones o modificaciones) que haya que hacer.

¿Cómo lo has hecho? ¿Podemos tener los pasos que has dado (o directamente el código)? Gracias