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

[bilbur]

Empezado por keys

El problema es que ese tipo de iva es un iva no sujeto y como envies una factura con importe cero y con iva no sujeto TBAI da error. A nosotros ya se nos planteo el caso y nos contestaron con lo que he puesto antes. Si el importe es cero y no hay base imponible hay que generar un recibo y no una factura.

Sólo se puede incluir en una factura que tenga otros conceptos con base imponible a iva.

Para complicarlo más:
Factura emitida base imponible cero

<Factura>
<CabeceraFactura>
<SerieFactura>FV</SerieFactura>
<NumFactura>005864</NumFactura>
<FechaExpedicionFactura>04-05-2021</FechaExpedicionFactura>
<HoraExpedicionFactura>18:48:34</HoraExpedicionFactura>
<FacturaEmitidaSustitucionSimplificada>N</FacturaEmitidaSustitucionSimplificada>
</CabeceraFactura>
<DatosFactura>
<FechaOperacion>04-05-2021</FechaOperacion>
<DescripcionFactura>FACTURA DE VENTA</DescripcionFactura>
<ImporteTotalFactura>0.00</ImporteTotalFactura>
<Claves>
<IDClave>
<ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia>
</IDClave>
</Claves>
</DatosFactura>
<TipoDesglose>
<DesgloseFactura>
<Sujeta>
<NoExenta>
<DetalleNoExenta>
<TipoNoExenta>S1</TipoNoExenta>
<DesgloseIVA>
<DetalleIVA>
<BaseImponible>0.00</BaseImponible>
<TipoImpositivo>4.00</TipoImpositivo>
<CuotaImpuesto>0.00</CuotaImpuesto>
</DetalleIVA>
</DesgloseIVA>
</DetalleNoExenta>
</NoExenta>
</Sujeta>
</DesgloseFactura>
</TipoDesglose>
</Factura>

Respuesta TBAI BIZ

<Registro>
<Identificador>
<IDFactura>
<SerieFactura>FV</SerieFactura>
<NumFactura>005864</NumFactura>
<FechaExpedicionFactura>04-05-2021</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Correcto</EstadoRegistro>
</SituacionRegistro>
 </Registro>

Parece ser que SI se pueden enviar facturas con base imponible, cuotas y total cero
He probado con facturas simplificadas total cero

<Registro>
<Identificador>
<IDFactura>
<SerieFactura>SV</SerieFactura>
<NumFactura>000444</NumFactura>
<FechaExpedicionFactura>04-05-2021</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Correcto</EstadoRegistro>
</SituacionRegistro>
</Registro>

También correcto en TBAi BIZ


Es posible que no tenga que ver con vuestra casuística, las pruebas son venta de bienes, no prestaciones de servicios.


Un saludo

[keys]

Hola.

Una factura con base 0 si puedes mandar. Lo que no puedes mandar es una factura con solo una línea de no sujeta. Que es como se envía un suplido.

[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 ñáéüç...

[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