CURL para Gipuzkoa
 

Buenos días a todos,


¿alguien ha usado el programa CURL desde linea de comandos para enviar las facturas a Gipuzkoa ?


Si fuera así, ¿ podría poner un ejemplo del mismo ?


Gracias

Buenos días
 

Hola a todos.

Llevo ya un tiempo con el tema de Batuz, y creía estar volviéndome loco yo solo hasta que he encontrado este foro y he visto que somos muchos así. :D
Qué locura.

He desarrollado todo el sistema de TBai y de LROE para Vizcaya (ya hice los mismo desde el 2015 para la aplicación BILA), y hasta ahora solamente están disponibles las operaciones con Ingresos y Gastos, Bienes de Inversión y Agrupaciones de Bienes. El resto de epígrafes (Cobros, Pagos, RECC...) no están todavía expuestos)

En Guipuzcoa, estoy teniendo un problema que no se me ha dado en Vizcaya.

El error que me está dando es que no puede validar las referencias URI de la firma:
Básicamente: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Certificate1" failed to verify. Reference URI="#SignedProperties-1909873269" failed to verify"

Y es que no entiendo cómo pueden tener diferentes criterios de validación de firma. En Vizcaya la misma firma es válida, pero no en Guipuzcoa.

¿A alguien más le ha ocurrido, y puede echarme una mano a qué puede ser debido?

Gracias a todos.
Saludos.

A mí me daba un error similar, <Descripcion>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Signature-d4d0ea3e-5409-4a0a-b5dd-f7c339abd340-SignedProperties" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Descripcion>, y es debido a que el valor CN del campo de firma IssuerName contiene un acento. Poniendo otro certificado funciono correctamente.


Envié un mensaje a la hacienda de Gipuzkoa y no me han respondido.

Revisa páginas anteriores del foro, hay más usuarios que lo han usado y han puesto ejemplos.


Aquí tienes algunos, aunque hay más...


* Opción4: Utilizando commandos CURL
(https://www.clubdelphi.com/foros/sho...215&postcount=769)
(https://www.clubdelphi.com/foros/sho...215&postcount=737)
(https://www.clubdelphi.com/foros/sho...215&postcount=746)

Busca en páginas anteriores, ya ha salido ese mensaje.
En nuestro caso estaba generado:
a) Por una mala codificación del fichero ANSI/UTF8 entre la firma y el envío
b) Por caracteres extraños en el fichero (ÑÁÉ,...)

También me suenan problemas con alguna de las firmas, relacionados con esto que está en la documentación. Revisa que lo tienes correcto:

Gracias Germán,

ya había visto este hilo pero son de Bizkaia.

Gracias.

Lo que me extraña, es que en Vizcaya vaya OK, pero en Guipuzcoa no pase ni uno debido a este error.
Tengo la sensación de que es problema suyo (de Guipuzcoa).
Hace 2 días, corrigieron un problema con la TSA que les mencioné, su respuesta básicamente fué que si fallaba, pues que como "no era obligatoria, que no la utilizase". Al final, me reconocieron que tenian un error de configuración en su servidor.

Un poco caótico todo.

Hola, después de encontrar ayuda en páginas anteriores, he probado este código usando curl en líneas de comandos y se envía correctamente :

curl -H "Accept-Encoding: gzip" -H "Content-Encoding: gzip" -H "Content-Type: application/octet-stream" -H "eus-bizkaia-n3-version: 1.0" -H "eus-bizkaia-n3-content-type: application/xml" -H "eus-bizkaia-n3-data: {\"con\": \"LROE\",\"apa\": \"1.1\",\"inte\": {\"nif\": \"NIF\",\"nrs\": \"NOMBRE\"},\"drs\": {\"mode\": \"240\",\"ejer\": \"2021\"}}" --data-binary @FICHERO.gz --cert CERTIFICADO.pem --key CERTIFICADO-KEY.pem -v URL_SERVIDOR_PRUEBA --output RESP_240.gz -D cabecera.txt

Yo lo hago así para Guipuzkoa:

Aquí están los parámetros del curl

Código Delphi [-]
curlCommand := '--data-binary "@' + path_fichero + '\' + nombre_fichero + '" ' +
    ' --cert-type P12 --cert sello_entidad_act.p12:IZDesa2021 ' +  // sello pruebas izenpe
    ' -D "' + PATH_CURL + '\header-dump.txt" ' + // captura del header, aunque no hace falta
    ' -H "Content-Type: application/xml;charset=UTF-8" ' +  
    ' -H "Accept-Encoding: ''gzip''" ' +
    ' -H "Content-Encoding: ''gzip''" ' +
    ' -X POST ' + url;

Ejecución del curl

Código Delphi [-]
 
  ShellExecute(
    'open',
    'cmd',
    '/v:1 /c curl.exe ' + curlCommand +                                 
    ' > "' + pathRespuesta + '"', // guardo la respuesta en fichero para comprobar
    PATH_CURL,
    0
  );

Espero que sea de ayuda

Solucionado.

Trabajo con C#, pero en Delphi entiendo que se puede hacer perfectamente. Efectivamente, tenía que ver con el Charset.

La solución ha sido en añadir en la petición la cabecera : "Content-Type" , "application/xml; charset=utf-8". Por si a alguno le sirve: sería algo así: contenido.Headers.TryAddWithoutValidation("Content-Type" , "application/xml; charset=utf-8";


Espero sirva.
Saludos.

Gracias por contestar.

Posible error de Encadenamiento
 

Buenos días;

Solamente en Guipuzcoa, estoy obteniendo continuamente el aviso: "010 - Posible Error de Encadenamiento". El caso es que la factura la informa como Recibida, aunque me devuelve dicho aviso. En Vizcaya, de nuevo, no obtengo aviso de error de ningún tipo.
Solo en Guipuzcoa.

He revisado el nodo del encadenamiento de la Factura anterior, y a mi parecer, es correcta. ¿A alguien más le ha pasado, o pudiera ser un error de Guipuzcoa al validar dicho dato?

Si no entendí mal, al igual que en Vizcaya, hay que meter en el nodo <SignatureValueFirmaFacturaAnterior> de la nueva factura, los 100 primeros caracteres de la firma de la factura anteriormente emitida.
Por el resto, informar la Serie, Número de Factura y Fecha de Expedición en el formato que se especifica.

A priori concuerdan los datos que estoy informando en esos nodos, pero quisiera preguntar por si acaso fuese algún error de Guipuzcoa a la hora de validarlos, ya que como digo en Vizcaya no hay problema, o tengo que seguir mirando por si algo se me hubiese escapado.

Muchas gracias.
Un saludo.

A nosotros no nos esta devolviendo ese error. Te recomiento que si ya lo has revisado bien y crees que es correcto se lo envíes a la hacienda para que te digan que puede ser.

Un Saludo.

el encadenamiento en batuz no se valida?
 

Buenos días, yo creo que Bizkaia no hace esa comprobación del encadenamiento porque a mi tampoco me da el error y en las pruebas que he hecho tendria que hacerlo.
En Gipuzkoa me ha dado alguna vez pero era porque estaba haciendo pruebas y enviaba las facturas en orden incorrecto, aunque los datos de encadenamiento fueran correctos.
Ahora queria volver a probar Gipuzkoa para contestarte pero no puedo enviar, me da el error "Error en el servidor remoto: (503) Servidor no disponible."


Tu JoseLeeTo puedes enviar sin problema a Gipuzkoa ahora mismo (aunque te de el error de encadenamiento)?


Muchas gracias!

Yo acabo de probar guipuzkoa y no funciona (hace un par de semanas que lo dejé funcionando correctamente). A alguien más le pasa?

A mi tambien me da error 503 y antes me funcionaba, me estaba volviendo loco, supongo que estarán teniendo problemas con el servidor de guipuzkoa

Son unos genios, cada vez lo ponen más fácil...
A todo esto, me acabo de fijar que en la web de Álava pone lo siguiente:


"Su implantación en el Territorio Histórico de Álava se hará de forma gradual, a lo largo de 2022.

Para ayudar en la implantación, en la normativa se van a contemplar beneficios fiscales que incentiven las inversiones que se deban realizar. "


Llevo tiempo sin entrar en Álava, pero visto esto, me da a entender que para Guipuzkoa y Bizkaia si es el 1 enero de 2022. Para Álava sería en algún momento de 2022 aún sin especificar. Es así o ya llevo un follón que no me entero de nada?

A mi hoy también me está fallando.
Da error de firma o error de certificado.
Luego reintentas y acaba aceptándola. :(:(

Hola. A mi me responde, pero algo raro pasa, porque me devuelve error 3n la verificación del certificado remitente.
No se qué estarán haciendo por allí.

Me pasa exactamente lo mismo que a vosotros 2, menos mal, porque me estaba empezando a traumatizar.

Me devuelve todo el rato estos 2 errores:

Error inesperado en la verificación del certificado remitente.

o

que le falta el SignatureValue (lo cual no es cierto)


Paso de volverme las loco hoy, el lunes será otro día...

Confirmo que no furula... Y el suicidio colectivo pa cuando?, éste finde me pilla un poco mal.

Hola Brand,

En Gipuzkoa tampoco será obligatorio el 1 de enero de 2022 para todos los sectores, sino que habrá un calendario por epígrafes de IAE.
En su web, en la sección de preguntas frecuentes dice:

El calendario de implantación obligatoria del sistema TicketBAI va a ser progresivo
desde el 1 de enero de 2022. En esa fecha tendrán la obligación de cumplir el sistema
TicketBAI los profesionales de la gestión tributaria establecidos en el artículo 9 de la
Orden Foral 582/2014. A partir de dicha fecha y con una periodicidad aproximadamente
trimestral se extenderá a nuevos sectores atendiendo a los diferentes epígrafes del IAE.
El calendario de implantación está aprobado en la Disposición Transitoria Primera del
Decreto Foral 32/2020, de 22 de diciembre, por el que se aprueba el Reglamento por el
que se desarrolla la obligación TicketBAI. (BOG 23-12-2020).

Y en el Decreto Foral dice:

Calendario de implantación de la obligación TicketBAI.
1. La obligación TicketBAI será exigible para los contribuyentes en función de la
actividad empresarial, profesional o artística que ejerzan, de acuerdo con lo dispuesto
en el Texto Refundido del Impuesto sobre Actividades Económicas aprobado por el
Decreto Foral Normativo 1/1993 de 20 de abril, con arreglo al siguiente calendario de
implantación:
a) El 1 de enero de 2022, será exigible para los siguientes contribuyentes:
- Los que prestan con habitualidad servicios de gestión en materia tributaria, a los que
se refiere el artículo 9 de la Orden Foral 582/2014, de 5 de noviembre.
- Los que, habiendo optado por cumplir voluntariamente la obligación TicketBAI en 2021
en virtud de la disposición adicional primera, sigan cumpliendo la misma a partir del 1
de enero de 2022.
b) El 1 de marzo de 2022, será exigible para los contribuyentes que ejerzan las
actividades comprendidas en los siguientes epígrafes:
- En la sección 1, los comprendidos entre los grupos 834 y el 849.
- En la sección 2, los comprendidos entre los grupos 011 y el 841.
c) El 1 de mayo de 2022, será exigible para los contribuyentes que ejerzan las
actividades comprendidas en los siguientes epígrafes:
- En la sección 1, los comprendidos entre los grupos 641 y el 665 y entre los grupos 671
y el 687.
- En la sección 2, los comprendidos entre los grupos 851 y el 899.
d) El 1 de octubre de 2022, será exigible para los contribuyentes que ejerzan las
actividades comprendidas en los siguientes epígrafes:
- En la sección 1, los comprendidos entre los grupos 501 y el 508; entre los grupos 691
y el 757; el grupo 833; y entre los grupos 851 y el 999.
e) El 1 de diciembre de 2022, será exigible para los contribuyentes que ejerzan las
actividades comprendidas en los siguientes epígrafes:
- En la sección 1, los comprendidos entre los grupos 011 y el 495; entre los grupos 611
y el 631; y entre los grupos 761 y el 832.
- En la sección 3, los comprendidos entre los grupos 011 y el 059.
f) Desde la fecha en que se opte de forma voluntaria por el cumplimiento de la obligación
TicketBAI en virtud de lo dispuesto en la disposición adicional primera, siempre que
dicha opción se ejercite en 2022.
2. En caso de contribuyentes que ejerzan varias actividades y estas estén encuadradas
en dos o más epígrafes que a su vez tengan una fecha de exigibilidad diferente, la
obligación TicketBAI será exigible para todas ellas cuando lo sea para la primera de las
actividades.
3. El diputado o la diputada foral del Departamento de Hacienda y Finanzas, mediante
orden foral, podrá modificar el calendario previsto en esta disposición transitoria.

Saludos

Gracias Sistel, entonces ya me miraré bien para cuando afecta a los clientes de nuestro ERP

Saludos!

Hola, he vuelto a probar hoy en guipuzkoa y me sigue dando error 503, ¿os pasa igual? ¿no lo han arreglado aun?

Tengo el mismo error. A la segunda funciona

Ojalá fuese tan sencillo como una serie de facturación por cada actividad, pero en el sector en el que me muevo la realidad es bien distinta, ya que la práctica totalidad tiene un mínimo de 3 actividades -empresariales y profesionales para joderlo aún más- mezcladas en el mismo negocio, y eso no hay por donde cogerlo a no ser que el autónomo de marras sea también economista.

De eso nada, y el motivo es tan aplastante que lo van a entender hasta los marcianos: si solo pudiese haber un epígrafe por factura el LROE no aceptaría hasta los 10 que vienen en el XSD.

El que el envío se tenga que hacer en UTF-8 es, precisamente, para que esas cosas no ocurran, y dado que el XML es inmodificable tras la firma, es el software de firma el que tendrá que convertirlo a UTF-8 durante el proceso.

Buenos días y aprovecho para presentarme que es mi primer post.



Llego aquí después de googlear "foro ticketbai" y veo que estamos muchos en la misma situación. Me ha servido todo lo leído pero vamos al lío...


Problema: Certficado + Gipuzkoa



He tenido la suerte de "debutar" con mis primeras pruebas el viernes y después de mucho intentar siempre llegaba al mismo error

05-07-2021 10:50:39 01 Rechazado Baztertua 006 Error inesperado en la verificación del certificado remitente. Ustekabeko errorea bidaltzailearen ziurtagiria egiaztatzean.

Cuando veo que por lo visto el viernes este era un tipo de error "habitual" decidí que no era el mejor día para hacer mi primera prueba de subida y lo dejé para hoy


Por necesidades técnicas lo tengo que subir lanzando un curl desde símbolo de comando. Concretamente hago esto


curl.exe --data-binary @FACTURA...FIRMADA.XML --cert-type P12 --cert micertificado.p12:mipasswordcertificado -H "Content-Type: application/xml;charset=UTF8" -X POST h t t p s : / / tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta -o respuesta.html


El caso es que esta mañana sigo con el error y entiendo que será ya de verdad un problema con mi certificado



Leí en páginas anteriores que izenpe tenía unos certificados de prueba con los que podías hacer un mínimo de cosas y me los bajo para probar con ellos a ver. El tema es que al bajarlos salen 70 certificados diferentes y no sé cual coger para tener un mínimo de fiabilidad....


He probado con estos dos


sello_entidad_rev.p12:IZProd2021
sello_entidad_rev.act:IZProd2021
profesional_sw_rev.p12:IZProd2021


¿Con cual podría probar?


¿Qué hay que tener en cuenta con los certificados que me estoy perdiendo?


Gracias por vuestra ayuda

Buenos días y bienvenido al foro

Siguen igual, pero tal y como han dicho antes, si lo reintentas 2 o 3 veces suele "entrar". No se que tipo de pruebas están haciendo, pero es así.


En las pruebas iniciales creo que sí funcionaban, pero ahora debes utilizar certificado correcto tanto en preproducción como en producción.
Nosotros, por ejemplo, estamos probando con uno de dispositivo y nos va bien.
https://servicios.izenpe.com/ticketb...o;jsessionid=0

De ahí lo bajamos.


El hecho que nuestra empresa esté en Alava y las pruebas sean en la de Guipuzcoa (porque creo que alava no tiene propia) entiendo que no afectará...a efectos de que el certificado "sea válido"


Gracias.

Si.
Pero lo dicho; Esos de pruebas que inicialmente funcionaban, ahora ya no sriven.

Alava como dices por ahora no está activo y se supone que será "equivalente" a lo que estamos enviando a Guipuzkoa.
Es posible que en su momento los certificados haya que darlos de alta también en Alava, como hemos tenido que hacer en las otras dos administraciones.

Firma xml con autofirma en Linux.
 

Hola.
Habéis conseguido firmar por linea de comandos con autofirma en Linux?. Estoy intentándolo con php y el comando exec.
En Windows no hay problema, pero en linux no hay forma de escapar los espacios en el parametro -config.

Siempre me devuelve No se reconoce el parámetro Enveloped, y es porque no se escapar el espacio que hay entre XAdES y Enveloped.

Agradecido de antemano.

Si necesitáis ayuda con la firma en windows solo tenéis que decírmelo.

Envío de Ingresos con Factura en Guipuzcoa
 

Hola de nuevo.

Respecto al error que estaban devolviendo estos días atrás desde Batuz con el problema de los certificados ("Error inesperado en la verificacion del certificado remitente."), aparentemente hoy he podido enviar sin problemas.

En Vizcaya, no he tenido problemas de ningún tipo, ni para los Ingresos con Factura, ni para Gastos, ni para Bienes de Inversión, agrupaciones, operaciones intracomunitarias, etc, es decir, para el LROE.... Pero sí para Guipuzcoa.
Ya les remití una pregunta para poder conocer la razón de por qué cada uno valida los certificados o firmas a su criterio, pero evidentemente, no he obtenido respuesta.

Utilizo un certificado personal de la FNMT, pero claro, el otro día también lo utilizaba y me devolvía ese error que comento.

Desconozco la casuística que están llevando a cabo para la validación de certificados o de la firma, pero desde luego, cada día esto va a ser una película distinta.

A ver con qué nos sorprenden en breve.

Saludos.

Buenas.
Para mi fiscalmente no tiene ningún sentido, las facturas van a una actividad y no puedes mezclar. En el único caso que me parece que esto tenga sentido es cuando se aplica prorrata.

Un saludo.

Piensa en un negocio en el que puedas comprar golosinas y bolígrafos (los hay; en mi sector destino son todos así).

¿Qué haces si, por ejemplo, en una misma operación vendes los dos productos? ¿dos facturas? Si hago eso me quedo sin clientes (algunos llegan a tener hasta 5 actividades).

Ya me funciona el certificado correctamente. Parece que era tema de su servidor. Vaya tela.


Muchas gracias.


Sigo ahora peleándome con la firma etc...

Aprovecho tu oferta para preguntarte una duda.



Estoy firmando desde msdos lanzando esta línea


\autofirma\autofirma\autofirmacommandline sign -certgui -i FICHEROFACTURA.XML -o FICHEROFACTURAFIRMADA.XML -store windows -alias "..." -format xades -xml -config "format=XAdES Enveloped \npolicyIdentifierHash=6NrKAm60o7u62FUQwzZew24ra2ve9PRQYwC21AM6In0= \npolicyIdentifierHashAlgorithm=h t t p s: / / guipuzcoa.eus/ticketbai/sinaduraura


y el comando aparentemente me lo ejecuta bien a la espera de poderlo subir pero se me abre la ventana de diálogo de windows para seleccionar el certififcado y darle aceptar....esto en mi entorno real no será práctico porque un día cualquiera mis clientes pueden imprimir 300 facturas


¿Hay algún parámetro para decirle que no "valide" esa ventana y que el comando se lance directo?


Gracias

respuesta sobre multiples epígrafes
 

Hola, gracias a todos por las respuestas. Ahora he recibido por fin la respuesta sobre los epígrafes, se confirma lo que algunos sospechabamos:(

A continuación el mensaje entero:
Si no lo entiendo mal, implica tener un nuevo campo para cada artículo que indique su epígrafe y esto me parece muy complicado de configurar y mantener y tengo mis dudas que el usuario sepa en cada caso a que epígrafe pertenece el artículo:confused:


En fin...



Saludos

AutoFirmaCommandLine.exe sign -i fichero_a_firmar -o fichero_firmado -store pkcs12:certificado_p12 -password password_certificado -filter certificado_p12

Esto más el resto de parametros -format xades -xml -config "format=XAdES Enveloped \npolicyIdentifier=identificativo \npolicyIdentifierHash=codigo_HASH \npolicyIdentifierHashAlgorithm=http://www.w3.org/2001/04/xmlenc#sha256 \npolicyQualifier=identificativo

Tarda unos 3 sg en firmar cada XML.

Saludos