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

[Sistel]

Empezado por Ja Mon

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

Hola Ja Mon,

Las facturas deben ser consecutivas en número, fecha y hora.
Yo considero 2 estados:
- Recopilación de datos para la factura (no considero aún emitida la factura)
- Emisión de la factura: asignación de nº de factura (siguiente a la última emitida), fecha y hora y creación y firma del XML

Si la asignación de nº de factura, fecha y hora y creación del XML y firma lo haces en servidor, te olvidas del problema de que haya varios puestos diferentes creando facturas y no sean consecutivas.

Saludos

[ermendalenda]

Empezado por Ja Mon

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

No.puedes asignat el número por adelantado.
La tecnica normal es jugar con el bloqueo del numerador ir generando la factura temporalmente y cuando aceptes coger el nuevo número por orden correlativo, si esta bloqueado el numerador dejarlo en bucle reintentado el tiempo que consideres lógico y que bloquee el primero que pueda.

[Ja Mon]

Empezado por ermendalenda

No.puedes asignat el número por adelantado.
La tecnica normal es jugar con el bloqueo del numerador ir generando la factura temporalmente y cuando aceptes coger el nuevo número por orden correlativo, si esta bloqueado el numerador dejarlo en bucle reintentado el tiempo que consideres lógico y que bloquee el primero que pueda.

Lo que he hecho ahora ha sido configurar el programa para que se pueda crear un número temporal. Este número es un número negativo correlativo en la serie y el ejercicio de forma que puedo tener varios documentos temporales.

Luego, he creado un procedimiento en la base de datos que busca en el ejercicio y la serie el último número positivo creado más 1. De esta forma, evito los problemas del uso de un numerador.
Cuando vaya a imprimir, crear xml, etc., ejecuto el procedimiento que le cambiará el número negativo por el nuevo positivo correlativo y sustituirá la fecha y hora por la del sistema.

Ahora crearé un registro con los datos de la factura firmada que se usará para el encadenamiento de la próxima.


Muchas gracias a los dos, poco a poco voy resolviendo las dudas.

[Ja Mon]

Empezado por ermendalenda

No.puedes asignat el número por adelantado.
La tecnica normal es jugar con el bloqueo del numerador ir generando la factura temporalmente y cuando aceptes coger el nuevo número por orden correlativo, si esta bloqueado el numerador dejarlo en bucle reintentado el tiempo que consideres lógico y que bloquee el primero que pueda.

Lo que he hecho ahora ha sido configurar el programa para que se pueda crear un número temporal. Este número es un número negativo correlativo en la serie y el ejercicio de forma que puedo tener varios documentos temporales.

Luego, he creado un procedimiento en la base de datos que busca en el ejercicio y la serie el último número positivo creado más 1. De esta forma, evito los problemas del uso de un numerador.
Cuando vaya a imprimir, crear xml, etc., ejecuto el procedimiento que le cambiará el número negativo por el nuevo positivo correlativo y sustituirá la fecha y hora por la del sistema.

Ahora crearé un registro con los datos de la factura firmada que se usará para el encadenamiento de la próxima.


Otra duda:
Cuando se imprime la factura se imprimen los vencimientos con su fecha. Una vez firmada, si el cliente desea cambiar la fecha de los vencimientos, dividirlos en varios, etc. Puede hacerlo pero, si sacamos un duplicado de la factura ¿los vencimientos nuevos (fechas e importes) que se imprimen deben ser los originales o pueden ser los nuevos? Si son los originales, habrá que buscar el fichero (pdf, o lo que sea) que se creó en su día e imprimirlo en vez de usar el metodo de impresión habitual...



Muchas gracias a los dos, poco a poco voy resolviendo las dudas.

[ermendalenda]

Empezado por Ja Mon

Lo que he hecho ahora ha sido configurar el programa para que se pueda crear un número temporal. Este número es un número negativo correlativo en la serie y el ejercicio de forma que puedo tener varios documentos temporales.

Luego, he creado un procedimiento en la base de datos que busca en el ejercicio y la serie el último número positivo creado más 1. De esta forma, evito los problemas del uso de un numerador.
Cuando vaya a imprimir, crear xml, etc., ejecuto el procedimiento que le cambiará el número negativo por el nuevo positivo correlativo y sustituirá la fecha y hora por la del sistema.

Ahora crearé un registro con los datos de la factura firmada que se usará para el encadenamiento de la próxima.


Otra duda:
Cuando se imprime la factura se imprimen los vencimientos con su fecha. Una vez firmada, si el cliente desea cambiar la fecha de los vencimientos, dividirlos en varios, etc. Puede hacerlo pero, si sacamos un duplicado de la factura ¿los vencimientos nuevos (fechas e importes) que se imprimen deben ser los originales o pueden ser los nuevos? Si son los originales, habrá que buscar el fichero (pdf, o lo que sea) que se creó en su día e imprimirlo en vez de usar el metodo de impresión habitual...



Muchas gracias a los dos, poco a poco voy resolviendo las dudas.

Que yosepa los vencimientos no tienen que ver con ticketbai, puedes cambiar datos que no afecten a los datos solicitados em el xml, y tanpoco puedes generar de nuevo el xml..si tienes que hacer alguna modificación que afecte al xml, cliente, importe,ivas... tienes que crear una anulación o un xml de rectif8cacion según proceda.

[trumbolt]

Empezado por Ja Mon

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

El problema que veo con tu acercamiento es que parece un parche añadido a tu sistema en vez de una solución integrada sobretodo pensando que esto no va a ser sólo para el Pais Vasco sino que vamos camino de tenerlo en todo el territorio nacional.

Por lo que veo, diferencias entre emitir la factura (supongo que en tu programa) y firmar el xml. En realidad, tu programa no debería considerar que se ha emitido una factura si no se ha generado el XML y firmado. En mi software, tras grabar la factura físicamente en la bbdd, por así decirlo, se genera el XML y se firma y si no se puede por alguna razón (fallo de certificado, ...), se cancela la transacción y la factura deja de existir internamente. Es la manera de asegurar un encadenamiento correcto. Luego ya esos XML firmados tienes que hacerlos llegar a Hacienda, en mi caso con un servicio de cola de envío independiente al software principal.

[trumbolt]

Empezado por Ja Mon

Otra duda:
Cuando se imprime la factura se imprimen los vencimientos con su fecha. Una vez firmada, si el cliente desea cambiar la fecha de los vencimientos, dividirlos en varios, etc. Puede hacerlo pero, si sacamos un duplicado de la factura ¿los vencimientos nuevos (fechas e importes) que se imprimen deben ser los originales o pueden ser los nuevos? Si son los originales, habrá que buscar el fichero (pdf, o lo que sea) que se creó en su día e imprimirlo en vez de usar el metodo de impresión habitual...

Esa info no va en el XML de TicketBAI así que supongo que se puede modificar sin problema. Otra cosa son aquellos datos que si que van referenciados como importes, ivas, titular, etc ...

[trumbolt]

Empezado por ermendalenda

No.puedes asignat el número por adelantado.
La tecnica normal es jugar con el bloqueo del numerador ir generando la factura temporalmente y cuando aceptes coger el nuevo número por orden correlativo, si esta bloqueado el numerador dejarlo en bucle reintentado el tiempo que consideres lógico y que bloquee el primero que pueda.

Algo así hacemos nosotros. La primera estación que empieza a emitir una factura digamos que bloquea el contador de facturas y no lo libera hasta que queda finalizada la firma del XML. Si otra fuese a facturar justo en ese momento, queda en espera a que el contador si libere (mirando con las pruebas es cuestión de 1 segundo o así) y toma el control para facturar él. Esto lógicamente en entornos en donde las estaciones de trabajo funcionen con la misma serie. En otros donde cada PC factura con la suya propia y sin interrelación con el resto, no es necesario esperar ya que el encadenamiento sólo afectaría a sus facturas. Ideal para entornos como restaurantes o tiendas con varios TPVs trabajando a destajo ...

[Ja Mon]

Empezado por trumbolt

El problema que veo con tu acercamiento es que parece un parche añadido a tu sistema en vez de una solución integrada sobretodo pensando que esto no va a ser sólo para el Pais Vasco sino que vamos camino de tenerlo en todo el territorio nacional.

Por lo que veo, diferencias entre emitir la factura (supongo que en tu programa) y firmar el xml. En realidad, tu programa no debería considerar que se ha emitido una factura si no se ha generado el XML y firmado. En mi software, tras grabar la factura físicamente en la bbdd, por así decirlo, se genera el XML y se firma y si no se puede por alguna razón (fallo de certificado, ...), se cancela la transacción y la factura deja de existir internamente. Es la manera de asegurar un encadenamiento correcto. Luego ya esos XML firmados tienes que hacerlos llegar a Hacienda, en mi caso con un servicio de cola de envío independiente al software principal.

Tienes razón y, como me indicaba Sistel, lo que hago ahora es crear facturas temporales que se pueden eliminar en cualquier momento. Solo cuando el usuario imprime, exporta o envía por correo electrónico se asigna un número, fecha y hora definitivos Luego, otro proceso en el servidor se encarga de gestionar la cola de los xml que le van llegando.
Creo que desde el principio tenía confusión sobre crear, emitir, imprimir, expedir... Ahora todo es lo mismo.

[GorkaB]

Buenas,

A ver si alguien me puede echar un cable por favor. No he tenido problemas de envío a Bizkaia ni a Gipuzkoa pero al enviar a Araba la respuesta siempre es "Certificado remitente incorrecto (revocado o no homologado)".

He probado con certificados activos de producción de izenpe siguiendo las indicaciones del servicio de asistencia de Araba y no hay manera. No sé lo que estoy haciendo mal y ellos tampoco parece ser.

Envío el xml firmado con cURL:

Código PHP:

curl_setopt($soap_do, CURLOPT_URL, 'https...no tengo permiso para poner enlaces ... pruebas-ticketbai.araba.eus/TicketBAI/v1/facturas/');
curl_setopt($soap_do, CURLOPT_CONNECTTIMEOUT, 500);
curl_setopt($soap_do, CURLOPT_TIMEOUT, 500);
curl_setopt($soap_do, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($soap_do, CURLOPT_HEADER, 1);
curl_setopt($soap_do, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($soap_do, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($soap_do, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($soap_do, CURLOPT_USERAGENT, 'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)');
curl_setopt($soap_do, CURLOPT_POST, 1);
curl_setopt($soap_do, CURLOPT_SSLCERT, $this->url_cert);
curl_setopt($soap_do, CURLOPT_SSLKEY, $this->url_key);
curl_setopt($soap_do, CURLOPT_POSTFIELDS, $xml_firmado);
curl_setopt($soap_do, CURLOPT_HTTPHEADER, array("Content-Type: application/xml","charset=UTF-8"); 


Por otro lado: ¿Alguien sabe si es posible hacer consultas en Gipuzkoa y Araba como en Bizkaia?


Muchas gracias de antemano

[Ja Mon]

Hola.
¿Es obligatorio en Guipuzcoa rellenar el dato NumSerieDispositivo? En el esquema no está en rojo y si es obligatorio ¿de donde lo sacais?

[GorkaB]

Empezado por GorkaB

Buenas,

A ver si alguien me puede echar un cable por favor. No he tenido problemas de envío a Bizkaia ni a Gipuzkoa pero al enviar a Araba la respuesta siempre es "Certificado remitente incorrecto (revocado o no homologado)".

He probado con certificados activos de producción de izenpe siguiendo las indicaciones del servicio de asistencia de Araba y no hay manera. No sé lo que estoy haciendo mal y ellos tampoco parece ser.

Envío el xml firmado con cURL:

Código PHP:

curl_setopt($soap_do, CURLOPT_URL, 'https...no tengo permiso para poner enlaces ... pruebas-ticketbai.araba.eus/TicketBAI/v1/facturas/');
curl_setopt($soap_do, CURLOPT_CONNECTTIMEOUT, 500);
curl_setopt($soap_do, CURLOPT_TIMEOUT, 500);
curl_setopt($soap_do, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($soap_do, CURLOPT_HEADER, 1);
curl_setopt($soap_do, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($soap_do, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($soap_do, CURLOPT_SSL_VERIFYHOST, 0);
curl_setopt($soap_do, CURLOPT_USERAGENT, 'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)');
curl_setopt($soap_do, CURLOPT_POST, 1);
curl_setopt($soap_do, CURLOPT_SSLCERT, $this->url_cert);
curl_setopt($soap_do, CURLOPT_SSLKEY, $this->url_key);
curl_setopt($soap_do, CURLOPT_POSTFIELDS, $xml_firmado);
curl_setopt($soap_do, CURLOPT_HTTPHEADER, array("Content-Type: application/xml","charset=UTF-8"); 


Por otro lado: ¿Alguien sabe si es posible hacer consultas en Gipuzkoa y Araba como en Bizkaia?


Muchas gracias de antemano

Me respondo a mi mismo porque era un fallo en mi programación. Estaba firmando con el certificado correcto pero enviando con el certificado incorrecto.


Queda pendiente el tema de las consultas que creo que no se puede.
Gracias de nuevo

[GorkaB]

Empezado por Ja Mon

Hola.
¿Es obligatorio en Guipuzcoa rellenar el dato NumSerieDispositivo? En el esquema no está en rojo y si es obligatorio ¿de donde lo sacais?

En nuestro caso el usuario conecta a través de cualquier dispositivo,
El número de serie que hemos puesto es el que identifica a nuestro servidor que es el que realmente se comunica con las diferentes haciendas y cumple con sus criterios: Alfanumérico (30).
Diría que no es obligatorio, al menos en nuestro caso.

[Noe277]

El numero de serie del dispositivo lo sacas si utilizas certificados de dispositivo. Se pueden solicitar gratuitamente en izenpe. Claro esta si es a nivel de equipos físicos si lo tienes hecho en servidor es otra historia

[trumbolt]

Empezado por Ja Mon

Hola.
¿Es obligatorio en Guipuzcoa rellenar el dato NumSerieDispositivo? En el esquema no está en rojo y si es obligatorio ¿de donde lo sacais?

Hasta donde yo sé, es un dato opcional. Teóricamente identifica la estación que ha emitido la factura. Supongo que de momento es opcional porque tampoco definen cómo obtener dicho número o de cuál se trataría (serial de la bios, del disco, algún tipo de algoritmo estilo windows que combine mac, hdd, tarjeta gráfica, ...) y lógicamente, la obtención de cualquiera de ellos es diferente dependiendo del sistema de programación empleado ...

[trumbolt]

Empezado por GorkaB

Por otro lado: ¿Alguien sabe si es posible hacer consultas en Gipuzkoa y Araba como en Bizkaia?


Muchas gracias de antemano

Que yo sepa no. Al menos nunca he encontrado ningún documento que comente dicha posibilidad. Hay que tner en cuenta que Vizcaya se ha montado su propia película con el tema del LROE que poco tiene que ver (menos la inclusión de las facturas en los libros) con el digamos, "estandar TicketBAI"

[Noe277]

Buenas,

En batuz en el 140 hay que mandar con las facturas los epígrafes de la actividad de cada una. ¿Alguien sabe si son distintos respecto a los epígrafes del estado o son otros códigos?
No encuentro una lista como tal.

[Sistel]

Empezado por Noe277

Buenas,

En batuz en el 140 hay que mandar con las facturas los epígrafes de la actividad de cada una. ¿Alguien sabe si son distintos respecto a los epígrafes del estado o son otros códigos?
No encuentro una lista como tal.

Hola Noe277,

Sí, los epígrafes (IAEs) son los mismos para todo el Estado.
Aunque Hacienda de Bizkaia suele añadirles un "1 " delante.

Para saber sus epígrafes, lo mejor es que el obligado tributario (autónomo o empresa que emite las facturas) entre en Hacienda Foral, con su certificado digital y se descargue un certificado de sus IAEs dados de alta.

Saludos

[VIMASAN]

Buenos días, soy nuevo en el foro y a estas alturas nos ha surgido una duda que nos inquieta, por favor, ¿alguien sabe cómo actuar?

Hay un control 1168 - El valor del "CodigoPais" solo puede ser 'ES' cuando el IDType sea ·03· Relacionado con la información de los destinatarios.

Dependiendo del tipo de identificación hay que enviar el “código del País”. Existen estos 5 tipos

02 - NIF
03 - PASAPORTE
04 - DOCUMENTO OFICIAL EXPEDIDO POR EL PAIS DE RESIDENCIA
05 - CERTIFICADO DE RESIDENCIA
06 - OTRO DOCUMENTO PROBATORIO

Para los dos primeros está claro, pero para los otros tres tenemos la duda: Si el cliente, por ejemplo, tiene un tipo de identificación 05 – CERTIFICADO DE RESIDENCIA y tiene Nacionalidad = Portuguesa pero su dirección está en España, por lo tanto el País de residencia = España. Entendiendo el país de residencia como parte de la dirección del cliente en España.

¿Qué hay que enviar en el “código país”? ¿La Nacionalidad o el País de residencia? Si se envía el país de residencia saltará el mensaje 1168.

Gracias por las respuestas.

[[duilioisola]]

Si reside en España, tendrá que identificarse con un NIE (Número de Identificación de Extranjero).
Tiene el mismo formato que el NIF.
De lo contrario no puede residir en España y habría que tratarlo como portugués.

En todo caso, el campo "CodigoPais" hace referenica al documento.

Si reside en España, tendrá un NIE y se lo tratara como español
<NIF>: NNNNN

Si presenta un NIF-IVA (IVA Intracomunitario)
<IDOtro>

<CodigoPais>: PT
<IDType>: 02
<ID>: PTNNNNNNNNN

Si presenta un pasaporte portugués
<IDOtro>

<CodigoPais>: PT
<IDType>: 03
<ID>: NNNNN

Si presenta un Documento nacional de identidad portugués
<IDOtro>

<CodigoPais>: PT
<IDType>: 04
<ID>: NNNNN

En el caso del cerificado de residencia, entiendo que lo expide España, por lo que debería ser:
<IDOtro>

<CodigoPais>: ES
<IDType>: 05
<ID>: NNNNN