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

[Elyas]

Yo sigo liado con los encadenamientos xDD, cuál de estos supuestos vale y cuál de estos ,no?

Pj.

Sería correcto hacerlo así OPCION A:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazadas (pj por fallo del sistema ticketbai)
3.Registramos la factura 003 y la encadenamos a la última factura recibida en TicketBAI, la 001, recibida
4.Se arregla el error y ahora volvemos a mandar la 002 encadenando a la última factura registrada en ticketbai, la 003.

O hay que hacerlo tal que así OPCIÓN B:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazada (pj por fallo del sistema ticketbai)
3.Registramos la factura 003, encadenando a la 002, obtenemos el warning.
4.Volvemos a enviar la 002 encadenada a la 001.

p.d. me han dichos los de ticketbai que van a sacar pronto nueva versión con opción de subsanar facturas. cómo es posible que a estas alturas metan nuevas funciones posiblemente tan vitales? en fin

[tejano]

Empezado por Elyas

Yo sigo liado con los encadenamientos xDD, cuál de estos supuestos vale y cuál de estos ,no?

Pj.

Sería correcto hacerlo así OPCION A:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazadas (pj por fallo del sistema ticketbai)
3.Registramos la factura 003 y la encadenamos a la última factura recibida en TicketBAI, la 001, recibida
4.Se arregla el error y ahora volvemos a mandar la 002 encadenando a la última factura registrada en ticketbai, la 003.

O hay que hacerlo tal que así OPCIÓN B:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazada (pj por fallo del sistema ticketbai)
3.Registramos la factura 003, encadenando a la 002, obtenemos el warning.
4.Volvemos a enviar la 002 encadenada a la 001.

p.d. me han dichos los de ticketbai que van a sacar pronto nueva versión con opción de subsanar facturas. cómo es posible que a estas alturas metan nuevas funciones posiblemente tan vitales? en fin

Os adjunto respuesta de Batuz con respuesta a las encadenadas. Nosotros tenemos varias delegaciones y cada delegación una serie de factura y no tienen las facturas del resto de delegaciones, por lo que el encadenamiento lo vamos a realizar en base a la serie.

Contestación de Batuz:

El sistema TicketBAI implica que cada factura debe identificar la factura anterior (serie, número, fecha y 100 primeros caracteres de la firma). Aunque en el esquema del fichero TicketBAI estos campos no son obligatorios, esta circunstancia se debe a que existen varias situaciones en los que este requisito no es exigible (p. ej. la primera factura, o en caso de rotura del dispositivo).

El cumplimiento del requisito de encadenamiento depende de la forma de funcionamiento del sistema de facturación:
- Si un mismo dispositivo emite facturas de diferentes series, el requisito de encadenamiento debe identificar la factura anterior expedida, con independencia de la serie (por ejemplo, a una factura de una serie ordinaria le puede preceder una factura rectificativa de otra serie).
- Igualmente, si el sistema de facturación es un sistema centralizado que genera las series y los números de facturación, con independencia del dispositivo que se esté utilizando, el encadenamiento se refiere a la última factura expedida por el sistema.
En concreto, “Haz tu factura” funcionaría como un sistema de facturación “centralizado”, por lo que encadena las facturas independientemente de la serie.
- No obstante, si existen diferentes dispositivos o centros de facturación, los cuales sólo expiden facturas dentro de una serie específica para cada dispositivo o centro, el encadenamiento se produce dentro de cada serie.
Este último parece ser el caso al que se refiere la pregunta planteada.

[Noe277]

Estoy teniendo muchos problemas a la hora de firmar las facturas, ¿Alguien lo ha conseguido en C#?

Empecé adaptando la aplicación que ofrecen en PAe y he logrado firmar XMLs con una estructura muy similar a la que muestran en el ejemplo oficial, no obstante algunas etiquetas como "<DataObjectFormat>" parecen tener algunos campos distintos, (Podría ser un problema) pero en general creo que podría dar el pego.

El caso es que siempre recibo el siguiente error:
"org.apache.axis.types.URI$MalformedURIException: No scheme found in URI"

Lo que no es de extrañar ya que el campo donde se encuentra la URI <xades:Identifier> y los tres de la política de firma no hay donde entenderlos, en cada documento dicen unos valores distintos...

Actualmente la política la genero así:

						<xades:SignaturePolicyIdentifier>
							<xades:SignaturePolicyId>
								<xades:SigPolicyId>
									<xades:Identifier>Politica de firma TicketBAI 1.0</xades:Identifier>
									<xades:Description/>
								</xades:SigPolicyId>
								<xades:SigPolicyHash>
									<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
									<ds:DigestValue>6NrKAm60o7u62FUQwzZew24ra2ve9PRQYwC21AM6In0=</ds:DigestValue>
								</xades:SigPolicyHash>
								<xades:SigPolicyQualifiers>
									<xades:SigPolicyQualifier>
										<xades:SPURI>https://www.gipuzkoa.eus/documents/2456431/12093238/TicketBAI_Pol%C3%ADtica_firma_v_1_0.pdf/3c6e5431-bb1d-34ed-5b26-206aaf085452</xades:SPURI>
									</xades:SigPolicyQualifier>
								</xades:SigPolicyQualifiers>
							</xades:SignaturePolicyId>
						</xades:SignaturePolicyIdentifier>

Algunas preguntas
¿Qué datos insertasteis?, ¿Usasteis algún algoritmo concreto?, ¿Dónde hay documentación medio clara sobre el tema?

En fin, cualquier ayuda es bien recibida, gracias de antemano.

[bilbur]

Empezado por Noe277

Estoy teniendo muchos problemas a la hora de firmar las facturas, ¿Alguien lo ha conseguido en C#?...

El caso es que siempre recibo el siguiente error:
"org.apache.axis.types.URI$MalformedURIException: No scheme found in URI"

En fin, cualquier ayuda es bien recibida, gracias de antemano.

Prueba a quitar los acentos o utiliza otra url


"url" => "https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf",

Suerte

[rci]

Hola, yo también estoy intentando firmar las facturas para tickeBAI en C# y no consigo que me acepten la factura como válida.

<?xml version="1.0" encoding="utf-8"?>
       <ResultadosValidacion>
        <Codigo>008</Codigo>
        <Descripcion>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Signature509508-SignedProperties932727" failed to verify. Reference URI="" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Descripcion>

Alguien ha encontrado algún ejemplo en c# para firmar para TicketBAI? No encuentro nada por internet en c#


Coincido con Noe277 en que la documentación no es suficientemente detallada para firmar los xml.



Cualquier ayuda se agradece!

Muchas gracias!

Empezado por Noe277

Estoy teniendo muchos problemas a la hora de firmar las facturas, ¿Alguien lo ha conseguido en C#?

Empecé adaptando la aplicación que ofrecen en PAe y he logrado firmar XMLs con una estructura muy similar a la que muestran en el ejemplo oficial, no obstante algunas etiquetas como "<DataObjectFormat>" parecen tener algunos campos distintos, (Podría ser un problema) pero en general creo que podría dar el pego.

El caso es que siempre recibo el siguiente error:
"org.apache.axis.types.URI$MalformedURIException: No scheme found in URI"

Lo que no es de extrañar ya que el campo donde se encuentra la URI <xades:Identifier> y los tres de la política de firma no hay donde entenderlos, en cada documento dicen unos valores distintos...

Actualmente la política la genero así:

                        <xades:SignaturePolicyIdentifier>
                            <xades:SignaturePolicyId>
                                <xades:SigPolicyId>
                                    <xades:Identifier>Politica de firma TicketBAI 1.0</xades:Identifier>
                                    <xades:Description/>
                                </xades:SigPolicyId>
                                <xades:SigPolicyHash>
                                    <ds:DigestMethod Algorithm="nopuedoponerenlaces"/>
                                    <ds:DigestValue>6NrKAm60o7u62FUQwzZew24ra2ve9PRQYwC21AM6In0=</ds:DigestValue>
                                </xades:SigPolicyHash>
                                <xades:SigPolicyQualifiers>
                                    <xades:SigPolicyQualifier>
                                        <xades:SPURI>nopuedoponerenlaces</xades:SPURI>
                                    </xades:SigPolicyQualifier>
                                </xades:SigPolicyQualifiers>
                            </xades:SignaturePolicyId>
                        </xades:SignaturePolicyIdentifier>

Algunas preguntas
¿Qué datos insertasteis?, ¿Usasteis algún algoritmo concreto?, ¿Dónde hay documentación medio clara sobre el tema?

En fin, cualquier ayuda es bien recibida, gracias de antemano.

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

Empezado por rci

Hola, yo también estoy intentando firmar las facturas para tickeBAI en C# y no consigo que me acepten la factura como válida.

<Descripcion>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Signature509508-SignedProperties932727" failed to verify. Reference URI="" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Descripcion>

En esta página hemos hablado de ese error:
https://www.clubdelphi.com/foros/sho...d.php?p=540615

Posible que esté relacionado con la codificación.
Revisa además si tienes caracteres extraños en el mensaje (en la razón social, por ejemplo) como ñáéüç...

[bilbur]

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

En esta página hemos hablado de ese error:
https://www.clubdelphi.com/foros/sho...d.php?p=540615

Posible que esté relacionado con la codificación.
Revisa además si tienes caracteres extraños en el mensaje (en la razón social, por ejemplo) como ñáéüç...

En las direcciones que no puedes escribir es posible que tengas acentos en "Política de firma..", en direcciones URI
Elimina los acentos en el xml previo a la firma y también en el firmador que utilices

Espero que sea eso

[sline]

Empezado por bilbur

En las direcciones que no puedes escribir es posible que tengas acentos en "Política de firma..", en direcciones URI
Elimina los acentos en el xml previo a la firma y también en el firmador que utilices

Espero que sea eso

no tengo ningún carácter con tilde en el xml.

[rci]

Hola, gracias por las respuestas bilbur y Neftali


Pues sí que va a ser eso de los acentos... al leer vuestras respuestas he revisado la factura que me daba ese error y he visto que en la dirección del cliente había un acento "ú".
He hecho otra factura exactamente igual pero poniendo la letra sin acento y ya no ha dado el error de la firma.


Lo que no acabo de ver es como solucionarlo porque ya estoy haciendo todo lo que proponéis (creo).
1. Al crear el fichero TicketBAI y guardarlo en disco lo hago en UTF8:

     var encoding = System.Text.Encoding.UTF8;
     FileMgr.Save(Path.Combine(filePath, fileName), xmltbai, encoding, false);

2. Al leer el fichero xml de disco para firmarlo le indico que es UTF8, después de firmar al salvar el xml firmado a disco también:

     XmlWriterSettings settings = new XmlWriterSettings();
     settings.Encoding = new UTF8Encoding();
     using (var writer = XmlWriter.Create(fileName, settings))
     {
           this.Document.Save(writer);
      }

3. Al leer el fichero xml firmado de disco para enviarlo también le indico UTF8:

     using (StreamReader sr = new StreamReader(filePath, Encoding.UTF8))
    {
           string content = sr.ReadToEnd();
           return content;
     }

4. Finalmente para enviar también indico UTF8

   var encoding = Encoding.UTF8;
    byte[] contentBytes = encoding.GetBytes(content);

    HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(url);
    httpWebRequest.AllowAutoRedirect = true;
    httpWebRequest.ClientCertificates.Add(certificate);
    httpWebRequest.Method = "POST";
    httpWebRequest.ContentType = "application/xml";
    httpWebRequest.ContentLength = contentBytes.Length;

    var postStream = httpWebRequest.GetRequestStream();
    postStream.Write(contentBytes, 0, contentBytes.Length);
    postStream.Flush();
    postStream.Close();

De todas formas si hay un acento en el XML antes de firmar, da el error de verificación de la firma.

He enviado correos con los dos ficheros y la dos respuestas al correo de consultas técnicas de Gipuzkoa pero... deben estar colapsados porque hace mucho que no me contestan, creo que llevan más de 2 semanas de retraso en las respuestas T_T


También he escrito a Araba preguntando por su entorno de pruebas y me han dicho que lo están desarrollando y que tiene previsto que para septiembre estará operativo :'(


Bueno voy a seguir investigando.


Ya sé que el foro es de Delphi y mi código es c# .net pero bueno, si alguien me puede dar otro consejo lo agradeceré.


Muchas gracias!

Empezado por bilbur

En las direcciones que no puedes escribir es posible que tengas acentos en "Política de firma..", en direcciones URI
Elimina los acentos en el xml previo a la firma y también en el firmador que utilices

Espero que sea eso

[Sistel]

Empezado por Elyas

Yo sigo liado con los encadenamientos xDD, cuál de estos supuestos vale y cuál de estos ,no?

Pj.

Sería correcto hacerlo así OPCION A:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazadas (pj por fallo del sistema ticketbai)
3.Registramos la factura 003 y la encadenamos a la última factura recibida en TicketBAI, la 001, recibida
4.Se arregla el error y ahora volvemos a mandar la 002 encadenando a la última factura registrada en ticketbai, la 003.

O hay que hacerlo tal que así OPCIÓN B:

1.Registramos la factura 001, recibida
2.Registramos la factura 002, rechazada (pj por fallo del sistema ticketbai)
3.Registramos la factura 003, encadenando a la 002, obtenemos el warning.
4.Volvemos a enviar la 002 encadenada a la 001.

p.d. me han dichos los de ticketbai que van a sacar pronto nueva versión con opción de subsanar facturas. cómo es posible que a estas alturas metan nuevas funciones posiblemente tan vitales? en fin

Hola Elyas,

Creo que el encadenamiento de las facturas no tiene nada que ver con su envío.
El encadenamiento es algo secuencial (factura emitida a factura emitida) y que se hace en local.
Que luego al enviarlas a Ticketbai (en Gipuzkoa) o por LROE (en Bizkaia) alguna te la dan como incorrecta, es otro tema.

Si sabes cual ha sido el error, siempre podrás generar una anulación de la factura (también encadenada a la última generada) y enviarla.
Y emitir otra nueva (con número siguiente y encadenada a la anterior, como es normal) que sea correcta.

Si, más adelante, habilitan un mecanismo de corrección de facturas enviadas y que han considerado incorrectas, perfecto.
Pero con el mecanismo actual de anulación creo que tienes el tema resuelto.

Saludos

[Elyas]

Gracias a ambos! se agradece mucho la ayuda!!!!

[Sistel]

Empezado por Sistel

Hola Elyas,

Creo que el encadenamiento de las facturas no tiene nada que ver con su envío.
El encadenamiento es algo secuencial (factura emitida a factura emitida) y que se hace en local.
Que luego al enviarlas a Ticketbai (en Gipuzkoa) o por LROE (en Bizkaia) alguna te la dan como incorrecta, es otro tema.

Si sabes cual ha sido el error, siempre podrás generar una anulación de la factura (también encadenada a la última generada) y enviarla.
Y emitir otra nueva (con número siguiente y encadenada a la anterior, como es normal) que sea correcta.

Si, más adelante, habilitan un mecanismo de corrección de facturas enviadas y que han considerado incorrectas, perfecto.
Pero con el mecanismo actual de anulación creo que tienes el tema resuelto.

Saludos

Hola Elyas,

He releído algo más de la normativa de TicketBAI-LROE y he encontrado otro mecanismo para el caso en que una factura emitida con TicketBAI es rechazada, por incorrecta, cuando se envía, posteriormente, a LROE (Capítulo 1.1 - Facturas emitidas con software garante).
Como la factura no puede volver a emitirse, dan como opción enviar sus datos a LROE en el Capítulo 1.2 Facturas emitidas sin software garante.
Así, cuando Hacienda haga el borrador de la declaración de IVA, tendrá en cuenta todas las facturas emitidas, tanto las que se han transmitido al capítulo 1.1 (las de TicketBAI aceptadas) como las que se han enviado al capítulo 1.2 (las que no se habían aceptado por el capítulo 1.1)

Saludos