Foros Club Delphi
Página 82 de 114 « Primero < 3272798081 82 83848592 > Último »
Mostrar 40 mensajes desde este tema en una página

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Internet (https://www.clubdelphi.com/foros/forumdisplay.php?f=3)
-   -   TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco (https://www.clubdelphi.com/foros/showthread.php?t=94264)

Sistel 17-08-2022 10:28:55
Cita:
Empezado por Ja Mon (Mensaje 547962)
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 17-08-2022 13:19:20
Cita:
Empezado por Ja Mon (Mensaje 547962)
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 17-08-2022 13:55:01
Cita:
Empezado por ermendalenda (Mensaje 547966)
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 17-08-2022 14:01:01
Cita:
Empezado por ermendalenda (Mensaje 547966)
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 17-08-2022 15:19:01
Cita:
Empezado por Ja Mon (Mensaje 547968)
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 18-08-2022 09:15:33
Cita:
Empezado por Ja Mon (Mensaje 547962)
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 18-08-2022 09:21:28
Cita:
Empezado por Ja Mon (Mensaje 547968)
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 18-08-2022 09:27:19
Cita:
Empezado por ermendalenda (Mensaje 547966)
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 19-08-2022 12:34:32
Cita:
Empezado por trumbolt (Mensaje 547978)
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 22-08-2022 11:08:24
Araba - Certificado remitente incorrecto (revocado o no homologado) y Consultas
 
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 22-08-2022 12:25:36
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 22-08-2022 12:29:59
Cita:
Empezado por GorkaB (Mensaje 548001)
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 22-08-2022 12:43:17
Cita:
Empezado por Ja Mon (Mensaje 548002)
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 22-08-2022 12:43:51
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 23-08-2022 09:48:01
Cita:
Empezado por Ja Mon (Mensaje 548002)
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 23-08-2022 09:51:04
Cita:
Empezado por GorkaB (Mensaje 548001)
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 26-08-2022 09:55:40
Iae
 
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 26-08-2022 11:40:20
Cita:
Empezado por Noe277 (Mensaje 548058)
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 31-08-2022 12:36:48
Duda Código País
 
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 31-08-2022 13:02:19
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

Irreo 01-09-2022 10:14:56
Buenos días a todos,

Ando redactando la memoria para Gipuzkoa, y repasando en mi código el tema del encadenamiento, a la hora de redactar cómo funciona, me han entrado algunas dudas sobre si lo que tengo montado se puede considerar correcto.

En la documentación mencionan que en Gipuzkoa la comunicación debe ser "inmediata". Pero claro, no estoy seguro qué consideran ellos inmediato... :rolleyes:

El sistema que tengo montado (todavía en fase de pruebas) funciona así:

Infraestructura:
- Servidor con un API propio, que viene a ser un "proxy" entre las personas que crean las facturas, y Hacienda.
- Tiendas físicas con software Windows para venta y emisión de tickets.

Servidor:
- Se recibe un JSON con una factura.
- Se crea un registro en la BBDD con todos los datos.
- Se firma y se guarda todo.
- Si es nueva factura queda marcada como "pendiente de enviar", y si es una corregida se guarda como "a reenviar"

Cronjob que se está ejecutando constantemente en el servidor:
- Cada 10 segundos, y en orden de creación de factura, se lee una factura de la tabla anterior y se envía.
- Si es una factura sin intento de envío previo, obtengo el XML ya firmado que estaba guardado.
- Si es una factura a corregir, genero de nuevo el XML a partir de los datos de la factura, que no va firmado.

Con esto me aseguro de que el encadenamiento esté siempre bien. Es decir, aunque una factura sea rechazada, ya se considera como "factura anterior" para el encadenamiento.
Y al haber solo un hilo del sistema dedicado al envío de facturas, con los 10 segundos de margen se evitan situaciones donde dos envíos se pisan entre ellos, si el primero por ejemplo tarda varios segundos.

Otro de los motivos de tener esto así, es poder emitir el ticket con el QR incluso aunque todavía no hayamos comunicado con Hacienda.

Es decir:
- Un cliente compra un producto en la tienda.
- El software del ordenador envía los datos a nuestro API, y le entrega el QR y TBAI.
- La factura todavía no sabemos si tiene el XML incorrecto, si va a ser rechazada o aceptada, pero entiendo que me da igual.
- El cliente se va con su ticket.
- En los segundos siguientes a haberse guardado la factura, ya se va a enviar a Hacienda mediante el cronjob.

¿Mi preocupación?
Que por lo que sea, se generen muchas facturas en algún momento, y en lugar de tardar de 1 a 9 segundos en estar funcional el QR, tarde 50 segundos por ejemplo... o más.

¿Debe ser inmediato.... inmediato?

¿Sabéis algo de si el inspector que hace verificaciones presenciales crea una factura e intenta leer el QR en el mismísimo instante?

Gracias!
Saludos.

workTeam 01-09-2022 10:28:54
Buenas! Estoy haciendo pruebas de envío a Bizkaia y me devuelve un 408.
¿Alguien haciendo pruebas con la misma respuesta? ¿Sabéis si está caído?

Muchas gracias

espinete 01-09-2022 13:27:43
Hola de nuevo a todos/as...

Después de varios meses con la aplicación rulando para varios clientes, en entorno de pruebas y en producción, ha habido algunas incidencias y me gustaría saber cómo lo hacéis vosotros...

La primera duda es con la "anulación y reenvío" de facturas, que creo que no se puede o no se debe hacer. Algunos clientes "anulan" una factura (envían una "anulación") y luego intentan reenviar la misma factura de nuevo. ¿Eso se puede hacer? ¿No habría que generar una nueva factura en vez de enviar la misma?

VIMASAN 01-09-2022 15:40:36
Buenas tardes, gracias por tu rápida respuesta.

Me cuadran todos los casos, menos el de certificado de residencia, este caso es el tipo de identificación 05 y según las especificaciones no puede llevar ES. ¿También sería PT?



Gracias.

Sistel 01-09-2022 16:18:30
Cita:
Empezado por Irreo (Mensaje 548151)
Buenos días a todos,

Ando redactando la memoria para Gipuzkoa, y repasando en mi código el tema del encadenamiento, a la hora de redactar cómo funciona, me han entrado algunas dudas sobre si lo que tengo montado se puede considerar correcto.

En la documentación mencionan que en Gipuzkoa la comunicación debe ser "inmediata". Pero claro, no estoy seguro qué consideran ellos inmediato... :rolleyes:

El sistema que tengo montado (todavía en fase de pruebas) funciona así:

Infraestructura:
- Servidor con un API propio, que viene a ser un "proxy" entre las personas que crean las facturas, y Hacienda.
- Tiendas físicas con software Windows para venta y emisión de tickets.

Servidor:
- Se recibe un JSON con una factura.
- Se crea un registro en la BBDD con todos los datos.
- Se firma y se guarda todo.
- Si es nueva factura queda marcada como "pendiente de enviar", y si es una corregida se guarda como "a reenviar"

Cronjob que se está ejecutando constantemente en el servidor:
- Cada 10 segundos, y en orden de creación de factura, se lee una factura de la tabla anterior y se envía.
- Si es una factura sin intento de envío previo, obtengo el XML ya firmado que estaba guardado.
- Si es una factura a corregir, genero de nuevo el XML a partir de los datos de la factura, que no va firmado.

Con esto me aseguro de que el encadenamiento esté siempre bien. Es decir, aunque una factura sea rechazada, ya se considera como "factura anterior" para el encadenamiento.
Y al haber solo un hilo del sistema dedicado al envío de facturas, con los 10 segundos de margen se evitan situaciones donde dos envíos se pisan entre ellos, si el primero por ejemplo tarda varios segundos.

Otro de los motivos de tener esto así, es poder emitir el ticket con el QR incluso aunque todavía no hayamos comunicado con Hacienda.

Es decir:
- Un cliente compra un producto en la tienda.
- El software del ordenador envía los datos a nuestro API, y le entrega el QR y TBAI.
- La factura todavía no sabemos si tiene el XML incorrecto, si va a ser rechazada o aceptada, pero entiendo que me da igual.
- El cliente se va con su ticket.
- En los segundos siguientes a haberse guardado la factura, ya se va a enviar a Hacienda mediante el cronjob.

¿Mi preocupación?
Que por lo que sea, se generen muchas facturas en algún momento, y en lugar de tardar de 1 a 9 segundos en estar funcional el QR, tarde 50 segundos por ejemplo... o más.

¿Debe ser inmediato.... inmediato?

¿Sabéis algo de si el inspector que hace verificaciones presenciales crea una factura e intenta leer el QR en el mismísimo instante?

Gracias!
Saludos.
Hola,

Parece correcto.
Aunque tienes que tener en cuenta algunos matices:

- Cuando dices "Se recibe un JSON con una factura", no es del todo correcto.
Deberías decir "Se recibe un JSON con los datos para emitir la factura", ya que la factura no existe hasta que no se emite, que es en el momento que se crea y firma el XML.

Y, por supuesto, es totalmente correcto que, a partir del tener el XML firmado obtengas el código TBAI y el código QR y los imprimas en el documento de la factura (independientemente de que aún no se haya enviado a Hacienda)

El término "envío inmediato" no supone ir a la velocidad de la luz.
Al igual que tú, yo lanzo un cronjob (yo lo hago cada minuto). Y se encarga de enviar cada una de los XML firmados que aún no se han enviado.
Yo entiendo que 1 minuto es inmediato.

Respecto al tema de la Verificación Presencial, entiendo que si un inspector se persona en el domicilio desde el que se emiten las facturas, puede solicitar ver el resultado que muestra el botón de "Verificación Presencial" (o como se quiera llamar en la aplicación), pero no creo que un inspector pueda tocar nada y, menos aún, emitir una factura.
Entiendo que podría solicitar ver una factura y escanear, con su smartphone el código QR para comprobar el estado y datos en la web de Hacienda Foral.

Saludos

Sistel 01-09-2022 16:22:07
Cita:
Empezado por espinete (Mensaje 548158)
Hola de nuevo a todos/as...

Después de varios meses con la aplicación rulando para varios clientes, en entorno de pruebas y en producción, ha habido algunas incidencias y me gustaría saber cómo lo hacéis vosotros...

La primera duda es con la "anulación y reenvío" de facturas, que creo que no se puede o no se debe hacer. Algunos clientes "anulan" una factura (envían una "anulación") y luego intentan reenviar la misma factura de nuevo. ¿Eso se puede hacer? ¿No habría que generar una nueva factura en vez de enviar la misma?
Hola,

Efectivamente, tras anular una factura, se puede emitir otra, pero será una nueva y con un nuevo número de factura y nueva fecha-hora de emisión. Pero nunca se puede emitir la misma factura (que ha quedado anulada a efectos fiscales)

Saludos

Irreo 01-09-2022 16:43:31
Buenas Sistel,

Muchas gracias por la respuesta.

Vamos respondiendo:

Cita:
Empezado por Sistel (Mensaje 548161)
Deberías decir "Se recibe un JSON con los datos para emitir la factura", ya que la factura no existe hasta que no se emite, que es en el momento que se crea y firma el XML.
Entiendo lo que dices, pero en nuestro caso no es así :)

Tenemos por un lado un servidor con un SQLServer, y por otro lado un Access VBA en Windows que es el punto de venta de las tiendas físicas.

Para poder realizar cualquier venta hace falta conexión a Internet ya que todo el tema de stock, pedidos, etc. se visualizan en la tienda, pero se sincroniza con la central, donde está el servidor.

Hasta ahora sólo se generaban pedidos con sus líneas. Ahora, en el momento de realizar una venta, es el propio SQL Server el que obtiene el "próximo número de factura", y guarda una nueva factura con sus líneas en la base de datos central.

Después de esto, se envía a este API nuestro el JSON con todo. Ten en cuenta que tenemos dos CIF, y la intención es que toda la facturación esté centralizada (antes iba con tablas separadas), de forma que cada vez que se genera una nueva factura, con su numeración correspondiente, se envíe a nuestro API para obtener TBAI, QR....

Cita:
Empezado por Sistel (Mensaje 548161)
Respecto al tema de la Verificación Presencial, entiendo que si un inspector se persona en el domicilio desde el que se emiten las facturas, puede solicitar ver el resultado que muestra el botón de "Verificación Presencial" (o como se quiera llamar en la aplicación), pero no creo que un inspector pueda tocar nada y, menos aún, emitir una factura.
Entiendo que podría solicitar ver una factura y escanear, con su smartphone el código QR para comprobar el estado y datos en la web de Hacienda Foral.
Con esto tengo mis dudas. En la documentación se menciona:

Cita:
(...) el personal inspector podrá verificar el correcto funcionamiento del software de
facturación y podrá requerir la aportación de los ficheros TBAI generados tanto en el proceso de verificación
como aquellos que el contribuyente tiene la obligación de conservar, (...)
Con esto entiendo que pueden realizar algún tipo de prueba que genere ficheros TBAI.

De todas formas, sobre esto he preguntado hace un rato a Hacienda, porque tenemos varias tiendas físicas (sin oficina ni responsables), y no sé exactamente cómo puede ser una visita de un inspector... como si entra al Fnac y le pide a una de las cajeras ficheros TBAI...

De todas formas tiene pinta que será como dices, irán a la dirección que sea el domicilio fiscal. Y aquí de nuevo me quedo bloqueado, porque es una de las tiendas.. aunque creo que una de las jefas suele andar por allá, así que ya pensaremos algo :D

En cualquier caso, con lo que me respondan informo aquí, por si le sirve a alguien.

Cita:
Empezado por Sistel (Mensaje 548161)
El término "envío inmediato" no supone ir a la velocidad de la luz.
Al igual que tú, yo lanzo un cronjob (yo lo hago cada minuto). Y se encarga de enviar cada una de los XML firmados que aún no se han enviado.
Yo entiendo que 1 minuto es inmediato.
Con esto ya me quedo más tranquilo. Aunque sí que es cierto que en mi caso el cron no es solo para las facturas que se hayan quedado sin enviar, sino para todas las que se van generando. Según las recibe el API, la guarda en la tabla marcada como "PTE", y en el siguiente ciclo se intenta enviar cualquiera que esté PTE, una por una.

Saludos!

thinkows 06-09-2022 10:24:37
Certificados de firma de código
 
Buenos días, alguno de vosotros ha utilizado o utiliza Comodo Code Signing, para firmar los ejecutables i/o instaladores de una aplicación de escritorio Windows, para ticketbai ?

Tengo una cotización de LeaderSSL de certificado de organización a 196€ por tres años.

Que os parece, alguna alternativa ?

Gracias de antemano.

amontes 06-09-2022 17:03:12
Zuzendu Guipuzkoa
 
Hola a todos!

Estoy pegandome con el servicio Zuzendu tanto de modificación (modificar/Subsanar) como la baja de Zuzendu, y siempre me lo rechazan con el error "Fichero no cumple el esquema XSD. El elemento principal debe ser SubsanacionModificacionTicketBAI." y "Fichero no cumple el esquema XSD. El elemento principal debe ser AnulaTicketBai.", ¿alguien ha tenido este problema? He revisado el XML con el XSD y lo veo todo correcto...

Código:
<?xml version="1.0" encoding="UTF-8"?>
<T:AnulaTicketBai xmlns:T="urn:ticketbai:zuzendu-baja">
  <Cabecera>
    <IDVersion>1.2</IDVersion>
  </Cabecera>
  <IDFactura>
    <Emisor>
      <NIF>XXXXXXXXXX</NIF>
      <ApellidosNombreRazonSocial>XXXXXXXXXXXXXXXX</ApellidosNombreRazonSocial>
    </Emisor>
    <CabeceraFactura>
      <SerieFactura>V-FAC1</SerieFactura>
      <NumFactura>XXXXXX</NumFactura>
      <FechaExpedicionFactura>12/01/22</FechaExpedicionFactura>
    </CabeceraFactura>
  </IDFactura>
  <HuellaTBAI>
    <Software>
      <LicenciaTBAI>TBAIGIPRE00000000XXX</LicenciaTBAI>
      <EntidadDesarrolladora>
        <NIF>XXXXXXXXX</NIF>
      </EntidadDesarrolladora>
      <Nombre>XXXXXXXXX</Nombre>
      <Version>1.0</Version>
    </Software>
  </HuellaTBAI>
  <SignatureValueFirmaAnulacion>yWMDh71bZ+4ZU9XXXe28HqrJY9QEUB3qsVwJrmxXYQUeKFBAFygZrO0RnPc7WUvQxTXSUi1+n6BAXotZsXGf5rgHxIq84JK0tPgs</SignatureValueFirmaAnulacion>
</T:AnulaTicketBai>

Irreo 07-09-2022 08:21:23
@amontes:

T:AnulaTicketBai es el servicio de anulación.

Si miras el XML de ejemplo de Hacienda, el servicio Zuzendu para bajas es así:

T:SubsanacionAnulacionTicketBAI

A ver si con eso se te soluciona...

Por otro lado, la fecha en este formato creo que no es correcta: 12/01/22

Debería ser 12-01-2022.

Saludos.

Ramon88 09-09-2022 10:58:36
Termina de surgirme algo que la verdad no pensé...


Un cliente empezó en Julio, y ha intentado anular una factura que realizó en Febrero (Vamos, no esta subida y no hay datos de ella)
Que pongo en:


Código:
<CabeceraFactura>
  <SerieFactura>XXX</SerieFactura>
  <NumFactura>XXX</NumFactura>
  <FechaExpedicionFactura>XXX</FechaExpedicionFactura>
 </CabeceraFactura>

Alguna idea?

keys 09-09-2022 11:05:47
Cita:
Empezado por Ramon88 (Mensaje 548236)
Termina de surgirme algo que la verdad no pensé...


Un cliente empezó en Julio, y ha intentado anular una factura que realizó en Febrero (Vamos, no esta subida y no hay datos de ella)
Que pongo en:


Código:
<CabeceraFactura>
  <SerieFactura>XXX</SerieFactura>
  <NumFactura>XXX</NumFactura>
  <FechaExpedicionFactura>XXX</FechaExpedicionFactura>
 </CabeceraFactura>

Alguna idea?
Solo se pueden anular facturas que esten en el sistema.

Neftali [Germán.Estévez] 09-09-2022 11:06:41
Cita:
Empezado por Ramon88 (Mensaje 548236)
Termina de surgirme algo que la verdad no pensé...

Un cliente empezó en Julio, y ha intentado anular una factura que realizó en Febrero (Vamos, no esta subida y no hay datos de ella)
Que pongo en:


Código:
<CabeceraFactura>
  <SerieFactura>XXX</SerieFactura>
  <NumFactura>XXX</NumFactura>
  <FechaExpedicionFactura>XXX</FechaExpedicionFactura>
 </CabeceraFactura>
Alguna idea?
Para las facturas que no están en TickeBAI no debes enviar nada. No están en el sistema y por tanto no hay que hacer referencia a ellas para nada.
Digamos que tu sistema sólo debe entrar en el circuito de TicketBAI, para aquellas facturas posteriores a la fecha de alta de tu cliente en TBAI.

Ramon88 09-09-2022 11:54:02
Perfecto! gracias!!!!

Irreo 13-09-2022 08:32:14
Buenas,

Continuando a lo de la verificación presencial del otro día, desde Hacienda me han respondido esto:

Cita:
Buenos días,

El software debe guardar los ficheros TBAI originales enviados a Hacienda, por lo que si un inspector solicita ver dichas facturas, debéis poder facilitarle dichas facturas (ya sea con una utilidad del software o mostrando directamente la carpeta o BBDD donde se guardan los ficheros).

Además, se le debe facilitar la comprobación tanto del funcionamiento del software como del código.
Nuestro software es un API que va a estar en un servidor... ¿ahora resulta que le tengo que enseñar los ficheros PHP?

De todas formas, en las múltiples consultas que he enviado a Hacienda, a veces recibo respuestas muy escuetas, poco agradables, o bien copy-paste de documentos que ya he leído... y otras veces explicaciones más elaboradas y con un tono más amable. Es bastante frustrante. Son varias las veces que he tenido que responder otra vez porque no me han aclarado nada.

¿Alguien sabe algo sobre esto del código fuente?

De todo lo que he ido leyendo desde meses atrás, tengo el recuerdo que esto es para software de escritorio, ¿puede ser?

Al final, nosotros por un lado tenemos la programación en Visual Basic de la aplicación local, y luego el API en sí, que es el software que vamos a registrar.

Gracias!

keys 13-09-2022 08:37:46
Cita:
Empezado por Irreo (Mensaje 548254)
Buenas,

Continuando a lo de la verificación presencial del otro día, desde Hacienda me han respondido esto:



Nuestro software es un API que va a estar en un servidor... ¿ahora resulta que le tengo que enseñar los ficheros PHP?

De todas formas, en las múltiples consultas que he enviado a Hacienda, a veces recibo respuestas muy escuetas, poco agradables, o bien copy-paste de documentos que ya he leído... y otras veces explicaciones más elaboradas y con un tono más amable. Es bastante frustrante. Son varias las veces que he tenido que responder otra vez porque no me han aclarado nada.

¿Alguien sabe algo sobre esto del código fuente?

De todo lo que he ido leyendo desde meses atrás, tengo el recuerdo que esto es para software de escritorio, ¿puede ser?

Al final, nosotros por un lado tenemos la programación en Visual Basic de la aplicación local, y luego el API en sí, que es el software que vamos a registrar.

Gracias!
Me imagino que lo del código fuente es para casos extremos. No creo que te venga un inspector de hacienda y te diga que le enseñes el código :cool:. Lo que si hay que proporcionar un mecanismo para que pueda consultar los xml y la aplicación es responsable de almacenarlos.

Lo del software de escritorio es que los ejecutables tienes que estar firmados.

Un Saludo.

Sistel 13-09-2022 09:09:23
Hola Irreo,

Hacienda te dice:
Cita:
...Además, se le debe facilitar la comprobación tanto del funcionamiento del software como del código...
No dice que debas enseñarle el código (que por otro lado al inspector le sonaría a esquema de una central de fusión nuclear) sino "el funcionamiento ... del código"

Si se le hace, en vivo y en directo, una alta de factura, una anulación o una verificación presencial, ya aplaudirá con las orejas.

Saludos

Sistel 13-09-2022 09:18:37
Hola Irreo,

Cita:
De todas formas, en las múltiples consultas que he enviado a Hacienda, a veces recibo respuestas muy escuetas, poco agradables, o bien copy-paste de documentos que ya he leído... y otras veces explicaciones más elaboradas y con un tono más amable. Es bastante frustrante. Son varias las veces que he tenido que responder otra vez porque no me han aclarado nada.
Efectivamente, hay veces que te responden con explicaciones satisfactorias que demuestran que, al otro lado, tienes a un experto en el tema.
Pero otras veces la consulta le cae a un pardillo que echa balones fuera de la forma más burda posible, contestando con cosas sin relación con la consulta.
Es triste, pero es así.

Y lo que es una lástima es que no haya un servicio telefónico (atendido por personal técnico) que permita consultas-respuestas rápidas.
Ayer, sin ir más lejos, se estaban bloqueando los envíos que hace mi aplicación al entorno de pruebas de Gipuzkoa, con mensajes simples del servidor.
Tuve que hacerles una consulta por email para que al cabo de un tiempo me contestaran que sí, que no se habían dado cuenta de que el servicio del entorno de pruebas se les había caído.

Saludos

Irreo 13-09-2022 09:28:58
Gracias a todos por las respuestas.

Cita:
Empezado por keys (Mensaje 548256)
Me imagino que lo del código fuente es para casos extremos. No creo que te venga un inspector de hacienda y te diga que le enseñes el código :cool:. Lo que si hay que proporcionar un mecanismo para que pueda consultar los xml y la aplicación es responsable de almacenarlos.

Lo del software de escritorio es que los ejecutables tienes que estar firmados.

Un Saludo.
Tienes razón, seguramente lo que me sonaba de software de escritorio era lo de la firma, que en nuestro caso no aplica.

Cita:
Empezado por Sistel (Mensaje 548258)
Hola Irreo,

Hacienda te dice:

No dice que debas enseñarle el código (que por otro lado al inspector le sonaría a esquema de una central de fusión nuclear) sino "el funcionamiento ... del código"

Si se le hace, en vivo y en directo, una alta de factura, una anulación o una verificación presencial, ya aplaudirá con las orejas.

Saludos
Pues espero que tengas razón :D


En un email me comentaron que la pantalla de "verificación" bastaba con que simplemente sea una especie "Acerca de.." con la info del software, número de serie etc...

Pero como para las pruebas ya tengo desarrollada una pantalla un poco más avanzada, además de eso, les voy a poner un listado de facturas y que en cada una puedan ver el registro de comunicación con hacienda, respuestas HTTP, acceso al XML firmado, etc...

En mi caso tengo la preocupación de que al ser un software para uso propio, van a andar con lupa, y se me haya pasado por alto alguna cosa importante... Es decir, no es lo mismo que un API desarrollada por una empresa de software, que es usada por decenas, o quizás cientos de comercios.

En fin, que me queda un mes para dejar esto funcionando, y ya me están viniendo los sudores :|

Irreo 13-09-2022 09:33:16
Cita:
Empezado por Sistel (Mensaje 548259)
Hola Irreo,
Ayer, sin ir más lejos, se estaban bloqueando los envíos que hace mi aplicación al entorno de pruebas de Gipuzkoa, con mensajes simples del servidor.
Tuve que hacerles una consulta por email para que al cabo de un tiempo me contestaran que sí, que no se habían dado cuenta de que el servicio del entorno de pruebas se les había caído.

Saludos
Sí, justo ayer sobre las 8 y pico empecé a hacer pruebas de facturas, y me llegaba un 503.

Me vino bien para simular caídas en real, estuve haciendo varias facturas, alguna rectificativa... y sobre las 10 y pico se restableció y se enviaron todas bien, con el encadenamiento correcto.

Aunque eso sí, a las 9 y pico tuve que parar el cron que procesa la cola, porque me estaba llegando un email cada 10 segundos de "servicio no disponible" :rolleyes:


La franja horaria es GMT +2. Ahora son las 01:59:00.
Página 82 de 114 « Primero < 3272798081 82 83848592 > Último »
Mostrar 40 mensajes desde este tema en una página

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi