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

[rcarteaga]

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

No se de qué puede ser, pero haría una prueba con Insomnia/PostMan (por ejemplo) para ver si es un problema de tu programa o con Insomnia también te pasa.

• Si con Insomnia/Postman lo recibes bien, es problema tuyo.
• Si con estos programa lo recibes vacío, puede ser tema de conexiones, FireWall, políticas de grupo, seguridad,...

Revisa este mensaje para ver cómo puedes hacer las llamadas (similar en Postman):

Gracias. Lo probaré

[lsubirana]

Por si os sirve de ayuda con todo este tema del hash que provoca error en los envíos.

Nosotros lo hemos sufrido esta pasada semana y hemos detectado el problema siguiente: a día de hoy, el documento sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_1.pdf que consta en la propia web de Batuz proporciona un hash 66ecabe920a35a8775616852f1800fb7570fa85b1b9ba71a369c6ad8623ee694 que en Base64 pasa a Zuyr6SCjWod1YWhS8YAPt1cPqFsbm6caNpxq2GI+5pQ=

Este hash no correcto respecto a las validaciones, ya que espera el K2baIY0fk8jbkPHkffk5F5C46O5VuzDwH21dAovjVRs=

Parece que el problema se ha originado en la propia subida del documento a la web, ya que ha modificado el documento incluyendo algunos metadatos que han alterado el hash
Consultado al servicio técnico han comentado que lo han visto recientemente y que ya están realizando cambios para solucionar esta situación.

[sglorka]

Empezado por keys

Para hacer una intracomunitaria no puedes usar un idtype 4. tienes que usar un 2.

<IDOtro>
<CodigoPais>FR</CodigoPais>
<IDType>02</IDType>
<ID>FR27383706397</ID>
</IDOtro>

Tengo entendido que para que se pueda emitir como operación intracomunitaria y por lo tanto, operación exenta, el identificador del destinatario informado con la clave 02 (Nif-Iva) FR27383706397 debe ser un ROI (registro de operador intracomunitario) válido, y que además, el emisor de la factura también tiene que tener su ROI. En caso contrario, debes emitir la operación como sujeta y NO exenta S1 con el Iva español y el IDType con el valor 04 por ejemplo.
Tenéis constancia de que esto sea así.

[Noe277]

Empezado por sglorka

Tengo entendido que para que se pueda emitir como operación intracomunitaria y por lo tanto, operación exenta, el identificador del destinatario informado con la clave 02 (Nif-Iva) FR27383706397 debe ser un ROI (registro de operador intracomunitario) válido, y que además, el emisor de la factura también tiene que tener su ROI. En caso contrario, debes emitir la operación como sujeta y NO exenta S1 con el Iva español y el IDType con el valor 04 por ejemplo.
Tenéis constancia de que esto sea así.

Si. Si uno de los dos Emisor o Receptor no esta inscrito en el ROI se aplica IVA del pais de origen. En este caso iva español y IDType = 04.
Si los dos están en el ROI exento en la venta y inversión de sujeto pasivo en la compra.

Otro caso es si estoy acogido al régimen de comercio electrónico. En este caso solo puedo vender a usuarios finales y se aplicaría iva del pais de destino (iva francés) y yo esto poniendo IDType = 04.

[sglorka]

Empezado por Noe277

Si. Si uno de los dos Emisor o Receptor no esta inscrito en el ROI se aplica IVA del pais de origen. En este caso iva español y IDType = 04.
Si los dos están en el ROI exento en la venta y inversión de sujeto pasivo en la compra.

Otro caso es si estoy acogido al régimen de comercio electrónico. En este caso solo puedo vender a usuarios finales y se aplicaría iva del pais de destino (iva francés) y yo esto poniendo IDType = 04.

Gracias por el aporte.
De todas formas, ¿ sabes si el sistema te rechaza el registro si lo envías como nif-iva (clave 02 y exenta ) y dicho nif-iva no está registrado en el ROI ?

[Noe277]

Empezado por sglorka

Gracias por el aporte.
De todas formas, ¿ sabes si el sistema te rechaza el registro si lo envías como nif-iva (clave 02 y exenta ) y dicho nif-iva no está registrado en el ROI ?

El nif-iva lo validan y tiene que ir con 02. Si esta mal o el pais no lo as metido bien te salta error. Hay un WS para poder validar el NIVA.

http://ec.europa.eu/taxation_customs...atService.wsdl

[sglorka]

Empezado por Noe277

El nif-iva lo validan y tiene que ir con 02. Si esta mal o el pais no lo as metido bien te salta error. Hay un WS para poder validar el NIVA.

http://ec.europa.eu/taxation_customs...atService.wsdl

Gracias Noe277.

[ermendalenda]

Buenas tardes. Hace mucho que no escribo por aquí. Un saludo.
Tenía una pregunta:
Os parece excesivo un tiempo de envío medio de 10 minutos desde la generación del xml?
Como lo veis, es importante para mi, gracias.

[skatologiko]

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

Nosotros desde el principio hemos tenido que hacer algo diferente para Guipuzkoa.
Pasamos a codificación ANSI antes de enviar, porque si o hacemos según la documentación nos daban los avisos.

No pasa nada si el TicketBAI no lleva caracteres extraños, pero si los lleva nos daba problemas.

Muchas gracias por contestar. Hemos probado ahora a enviar con codificación ANSI, pero nos dicen los técnicos lo siguiente:

Les adjuntamos el fichero recibido para esa factura, para que vean que sigue sufriendo modificación durante el envío.

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

Empezado por ermendalenda

Tenía una pregunta:
Os parece excesivo un tiempo de envío medio de 10 minutos desde la generación del xml?
Como lo veis, es importante para mi, gracias.

Se supone que cada administración tiene la potestad de definir ese tiempo, pero en la documentación se habla de "lo antes posible".
Por ejemplo, en este documento de Guipuzcoa se dice literalmente:
En el caso de Gipuzkoa, el envío de los ficheros TicketBAI debe llevarse a cabo de modo simultáneo a la expedición de la factura o justificante y online.

En este, que es el de Álava más de lo mismo:
En el caso de Álava, el envío de los ficheros TicketBAI debe llevarse a cabo de modo inmediato a la expedición de la factura o justificante, y online.

La norma es "lo antes posible".
No se si 10 minutos es "simultáneo"

[edejuan]

Hola,

El envío en pruebas, por lo menos en Gipuzkoa, ha empezado a devolverme 'error en el certificado' (aunque no estaba caducado ...).
He descargado los de producción del enlace de abajo, y probado con uno de ellos y ya me ha vuelto a enviar:


https://www.izenpe.eus/descarga-de-c...doctecnica/es/


por si a alguien le ha pasado también, lo mismo el que yo utilizaba era muy antiguo.


Saludos.

[yasmNote]

Buenos días,
No sé si alguien ha usado un certificado de la entidad CAMEFIRMA para firmar el xml y enviarlo a la diputacion de BIZKAIA. Resulta que esto que os voy a decir solo ocurre en el ENTORNO DE PRUEBAS, ya que en producción no deben de hacer algunas comprobaciones de los certificados.

Cuando envío la factura el error que me devuelve es "B4_2000070 - La firma no cumple los requisitos de la política de firma TicketBAI.(SigningCertificate incorrecto)"
La parte de la firma del xml es la siguiente, no entiendo qué puede estar dando error, además les escribes a ellos y tampoco saben... no sé si alguien sabrá que es lo que está mal. Teniendo en cuenta que el CertDigest lo calculo igual para los cert de izenpe y fmnt y nunca da error, entiendo que el error esta en <xades:IssuerSerial> pero he probado 8000 combinaciones y sigue dando el mismo error.... a ver si a alguien se le ocurre qué puede ser.

<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<dsigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsigestValue>YO+2VZh1MuO4HD31wKKHcVKNc2Ozk33Adg/i490YUvw=</dsigestValue>
</xades:CertDigest>
<xades:IssuerSerial>
<ds:X509IssuerName>CN=AC CAMERFIRMA FOR NATURAL PERSONS - 2016, O=AC CAMERFIRMA S.A., OID.2.5.4.97=VATES-A82743287, serialNumber=A82743287, OU=AC CAMERFIRMA FOR NATURAL PERSONS - 2016, OU=https://www.camerfirma.com/address, ST=MADRID, L=MADRID, C=ES</ds:X509IssuerName>
<ds:X509SerialNumber>744616219437521186074</ds:X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
<xades:SignaturePolicyIdentifier>
<xades:SignaturePolicyId>
<xades:SigPolicyId>
<xades:Identifier>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_1.pdf</xades:Identifier>
<xadesescription>Politica de firma TicketBAI 1.1</xadesescription>
</xades:SigPolicyId>
<xades:SigPolicyHash>
<dsigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsigestValue>K2baIY0fk8jbkPHkffk5F5C46O5VuzDwH21dAovjVRs=</dsigestValue>
</xades:SigPolicyHash>
<xades:SigPolicyQualifiers>
<xades:SigPolicyQualifier>
<xades:SPURI>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_1.pdf</xades:SPURI>
</xades:SigPolicyQualifier>
</xades:SigPolicyQualifiers>
</xades:SignaturePolicyId>
</xades:SignaturePolicyIdentifier>

[YellowStone]

Empezado por yasmNote

Buenos días,
No sé si alguien ha usado un certificado de la entidad CAMEFIRMA para firmar el xml. Resulta que esto que os voy a decir solo ocurre en el ENTORNO DE PRUEBAS, ya que en producción no deben de hacer algunas comprobaciones de los certificados.

Cuando envío la factura el error que me devuelve es "B4_2000070 - La firma no cumple los requisitos de la política de firma TicketBAI.(SigningCertificate incorrecto)"
La parte de la firma del xml es la siguiente, no entiendo qué puede estar dando error, además les escribes a ellos y tampoco saben... no sé si alguien sabrá que es lo que está mal. Teniendo en cuenta que el CertDigest lo calculo igual para los cert de izenpe y fmnt y nunca da error, entiendo que el error esta en <xades:IssuerSerial> pero he probado 8000 combinaciones y sigue dando el mismo error.... a ver si a alguien se le ocurre qué puede ser.

<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<dsigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsigestValue>YO+2VZh1MuO4HD31wKKHcVKNc2Ozk33Adg/i490YUvw=</dsigestValue>
</xades:CertDigest>
<xades:IssuerSerial>
<ds:X509IssuerName>CN=AC CAMERFIRMA FOR NATURAL PERSONS - 2016, O=AC CAMERFIRMA S.A., OID.2.5.4.97=VATES-A82743287, serialNumber=A82743287, OU=AC CAMERFIRMA FOR NATURAL PERSONS - 2016, OU=https://www.camerfirma.com/address, ST=MADRID, L=MADRID, C=ES</ds:X509IssuerName>
<ds:X509SerialNumber>744616219437521186074</ds:X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
<xades:SignaturePolicyIdentifier>
<xades:SignaturePolicyId>
<xades:SigPolicyId>
<xades:Identifier>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_1.pdf</xades:Identifier>
<xadesescription>Politica de firma TicketBAI 1.1</xadesescription>
</xades:SigPolicyId>
<xades:SigPolicyHash>
<dsigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<dsigestValue>K2baIY0fk8jbkPHkffk5F5C46O5VuzDwH21dAovjVRs=</dsigestValue>
</xades:SigPolicyHash>
<xades:SigPolicyQualifiers>
<xades:SigPolicyQualifier>
<xades:SPURI>https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_1.pdf</xades:SPURI>
</xades:SigPolicyQualifier>
</xades:SigPolicyQualifiers>
</xades:SignaturePolicyId>
</xades:SignaturePolicyIdentifier>

No sé si estoy en lo cierto, pero creo recordar que para BATUZ tienes que utilizar en pruebas los certificados que ellos te proporcionan.

[yasmNote]

Empezado por YellowStone

No sé si estoy en lo cierto, pero creo recordar que para BATUZ tienes que utilizar en pruebas los certificados que ellos te proporcionan.

No ya no, ahora puedes hacer pruebas con cualquier certificado, de hecho he hecho pruebas con certificados izenpe o fmnt de otras empresas y sin problemas, solo es con los de CAMEFIRMA....

[Noe277]

Yo pongo
<dsigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>

y luego

<xadesataObjectFormat ObjectReference="#Reference-ec3fd5c8-0fd6-4296-b316-dbd2d9e10546">
<xades:ObjectIdentifier>
<xades:Identifier>urnid:1.2.840.10003.5.109.10</xades:Identifier>
<xadesescription/>
</xades:ObjectIdentifier>
<xades:MimeType>text/xml</xades:MimeType>
<xades:Encoding>UTF-8</xades:Encoding>
</xadesataObjectFormat>

No se si tendrá que ver pero sino ami me daba el mismo error que ati

[yasmNote]

Empezado por Noe277

Yo pongo
<dsigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>

y luego

<xadesataObjectFormat ObjectReference="#Reference-ec3fd5c8-0fd6-4296-b316-dbd2d9e10546">
<xades:ObjectIdentifier>
<xades:Identifier>urnid:1.2.840.10003.5.109.10</xades:Identifier>
<xadesescription/>
</xades:ObjectIdentifier>
<xades:MimeType>text/xml</xades:MimeType>
<xades:Encoding>UTF-8</xades:Encoding>
</xadesataObjectFormat>

No se si tendrá que ver pero sino ami me daba el mismo error que ati

Pero la primera parte en la docu pone que hay que usar el cifrado en sha256 porque además, con otros certificados eso lo tengo tal cual y no da error. Y la segunda parte la de mi archivo es igual que la que has puesto.

[espinete]

Me surge una duda a raíz de un problema de envío con un cliente.

En las facturas se debe incluir los 100 primeros caracteres de la factura anterior.

Con las siguientes condiciones:
- De la serie que sea (la anterior puede ser de una serie distinta. solo se necesita la factura enviada anterior a la actual, sea de la serie que sea)
- Deben ser facturas que consten como "enviadas", obviamente. Que no hayan dado Error (rechazadas)

Pero me surge una duda... ¿qué ocurre con las Anuladas? ¿esas constan como "Enviadas"?

Es decir, a la hora de buscar cual fue la factura enviada anterior... ¿debo tener en cuenta también las anuladas? ¿O solo las enviadas sin error y sin anular?

Hasta ahora no me había surgido la duda. Se ve que lo de anular facturas no es tan común...

[keys]

Empezado por espinete

Me surge una duda a raíz de un problema de envío con un cliente.

En las facturas se debe incluir los 100 primeros caracteres de la factura anterior.

Con las siguientes condiciones:
- De la serie que sea (la anterior puede ser de una serie distinta. solo se necesita la factura enviada anterior a la actual, sea de la serie que sea)
- Deben ser facturas que consten como "enviadas", obviamente. Que no hayan dado Error (rechazadas)

Pero me surge una duda... ¿qué ocurre con las Anuladas? ¿esas constan como "Enviadas"?

Es decir, a la hora de buscar cual fue la factura enviada anterior... ¿debo tener en cuenta también las anuladas? ¿O solo las enviadas sin error y sin anular?

Hasta ahora no me había surgido la duda. Se ve que lo de anular facturas no es tan común...

Hay que cogerlo de la factura generada anteriormente, ya este anulada o no. De hecho se puede anular la factura después de haber enviado la siguiente.

Como tu dices lo de anular facturas no debería ser muy común.

[espinete]

Gracias Keys.

No solo eso, es que creó la factura con importe cero (????) añadiendo un artículo con el importe de la factura en negativo (?????), la envió y la anuló (??????).

El problema es que cuando pasan estas cosas raras que hace la gente porque se pone a probar cosas, es un lío arreglarlo y no sé ni por donde empezar

Pero bueno, al menos en el registro que tengo se guarda todo lo que se hace y poco a poco averiguamos lo que hay que hacer.

[rci]

Empezado por espinete

- Deben ser facturas que consten como "enviadas", obviamente. Que no hayan dado Error (rechazadas)

Este punto no lo veo muy claro... aunque no esté enviada también cuenta no?

Como dice Keys, "Hay que cogerlo de la factura generada anteriormente" y yo añado "independientemente de si está enviada o no y de si se ha rechazado o no".

Es una opinión y puede que me equivoque pero nosotros lo hacemos de esta forma.