Perfecto, así que esta es la famosa memoria completamente de relleno que había leído por mensajes anteriores jeje Gracias!

Un saludo

Encadenamiento
 

Buenas!

Por curiosidad, ¿qué enfoque le habéis dado al tratamiento del encadenamiento en las facturas? Independientemente del lenguaje de programación utilizado. ¿Un campo en la base de datos que apunte a la anterior? ¿Algún matiz más?

A seguir con el lunes!

Una tablita en la base de datos con un campo numérico (continuo en número y cronologicamente) independiente de la serie y número de factura y que contenga varios campos, entre ellos, la serie, número, fecha y firma de la última factura y otros campos iguales con la anterior. Teniendo en cuenta que no arrastre firmas de anulaciones. Casa nueva factura solo tengo que mirar el registro del último número de la tabla y si tengo varios dispositivos en el mismo equipo( tabletsequipos que graban en Red...) previamente pongo un bloqueo antes de hacer todos los procesos para evitar que se solapen. El resto de dispositivos que se encuentren el bloqueo se quedan en bucle esperando que se levante el bloqueo.

Y en esa tabla contemplas solo aquellas facturas notificadas? O también contemplas los intentos, las fallidas y lo más peculiar, aquellas que no se han mandado pero que ya has firmado y todo (imaginemos el clásico caso del internet caído puntualmente)

Yo estoy haciendo un plugin de WordPress el cual guarda los siguientes campos por cada factura generada:

Al recibir un nuevo pedido hago una consulta a la tabla de facturas para devolver la última factura generada. De ahí obtengo el tbai_previous_invoice_number. Hay que decir que en otra tabla tengo el número plano autoincremental ya que una factura puede componerse por letras y números y la suma no la podría asegurar al 100%.

Sumo uno al autoincremental y guardo el tbai_invoice_number ya formateado y la fecha actual en tbai_invoice_date.

Seguidamente emito el xml firmado a la diputación y según la respuesta asigno el estado en tbai_status.

Con estos datos guardados en bbdd es verdad que necesito abrir el anterior xml para el tema del encadenamiento, y para evitar esto seguramente pueda guardar estos datos en bbdd. Pero bueno doy por hecho que no se van a eliminar los xmls y que los archivos existen en el sistema.

Nosotros algo similar.

Nosotros sólo generamos encadenamiento cuando la factura ha sido notificada. Si no se notifica (por lo que sea) se deshace todo mediante transacciones y no queda rastro.

Sí, más o menos lo que estoy planteando es tener una tabla de IntentosNotificacion que apunte a la factura, tenga el contenido de la petición de envío, el contenido de la respuesta de esa petición (esto en formato BLOB quizá), el estado (existiendo Notificado, No notificado, Fallido... previamente definidos) o algo del estilo. Luego en lo que es la tabla factura, apuntar a la anterior en caso de realizar una emisión correctamente y como cada factura tendría un campo BLOB con su XML firmado y eso, podría tener acceso a los 100 primeros caracteres del campo SignatureValue de la factura anterior (que es lo que se pide, básicamente).

Es que estoy planteando la estructura primero, y quiero que sea lo más genérica posible para poder implementar cualquier sistema de notificación, como el SII, por eso ando full documentación jeje gracias!

[OFFTOPIC]
Buenas a todos.

Me vais a permitir una licencia con este hilo (será la única, lo prometo ;)).
Soy consciente de que muchos de los que visitáis este grupo accedéis a él directamente, sin pasar por otras zonas del ClubDelphi.

Os animo a que visitéis el enlace del banner que hay en la parte superior de la página.



Explica todo lo necesario para conocer nuestro grupo de Teaming. Os pediría que le dedicarais un minuto.
A partir de ahí, si alguien se anima será bienvenido.

Gracias.

[/OFFTOPIC]

Sí una factura no puede enviarse, las facturas siguientes se quedan en espera y me manda una incidencia por correo, se supone que los envíos KO serán en breve culpas denuestro software y acabarán desapareciendo. Si hay un KO se vuelve a reintentar cada minuto, tengo pendiente de añadir un límite de xmls sin enviar configurable y que se bloquee o de bastante por saco al usuario como para que avise a soporte, esto aun lo estoy pensando, se aceptan ideas.

En la tabla tb guardo registro de envío a un servidor externo nuestro al que envío el xml firmado, sin firmar y un pdf de la factura.
Esa tabla la leo continuamente con un software en segundo plano que no afecta a la facturación, cuando voy a generar la factura hago otras conprobrobaciones, fecha y hora de sistema, que no haya problemas con el firmador... Que son errores más graves que provocarían un bloqueo para no seguir facturando.

Buenos días!

Ya veo... tiene sentido... Yo también tengo que pensar el tema de las facturas que no se han podido mandar, tendré que comentarlo en la oficina a ver si alguien viene con alguna idea fresca. Pero una posibilidad es, si no se trata de un error puntual permitir volver a mandar y si no se ha podido tampoco, a la cola. Porque no se pueden enviar más facturas hasta que se haya mandado aquella que no se ha podido mandar, ¿verdad?

Otra posibilidad, aunque de objeto de estudio es, si la factura F1 no se ha podido mandar y mandamos la F2, consultamos si hay facturas pendientes de mandar primero, si no se puede pues cuando se emita F3, lo mismo, funcionando a lo FIFO, pero no sé si será demasiada consulta. Además, queda contemplar aquel momento en el que el problema del servidor se extienda sobre el tiempo y no sé si proponer un proceso automático al final de la jornada con esa misma cola. Lo que no quiero es dejar al cliente sin servicio. Se agradecen ideas, comentarios...

Hola,

Para mí, lo importante es que se pueda seguir facturando en cualquier caso y contra viento y marea.
Se van generando los XML, se van firmando, se van generando los códigos TBAI y QR y se van imprimiendo las facturas.

El tema del envío a la Hacienda Foral correspondiente creo que no es tan vital.
Pero no puedo dejar parado el TPV de una panadería, por ejemplo, porque no funcione el servicio de recepción de facturas de Hacienda Foral o porque haya un problema de Internet.

Los ficheros XML firmados se van poniendo en cola y un cronjob los va enviando a medida que se puede.
Si luego Hacienda Foral sale con cualquier mensaje de error de que no traga con la factura, ya es cuestión de LROE facturas emitidas sin software garante en Bizkaia, Zuzendu en Gipuzkoa o Alavazendu (o como le quieran llamar cuando lo inventen) en Álava.

Saludos

Pienso lo mismo, facturar no puede dejar de hacerse. Gracias!

Zuzendu
 

Sigo poniéndome al día con todo lo que el cuerpo me permite y veo lo de Zuzendu que en un pasado se habló... Pero ahora: "Este anexo ha sido modificado por el anexo I de la Orden Foral 40/2022, de 25 de enero, por la que se sustituyen los anexos I y III de la Orden Foral 16/2022, de 18 de enero, por la que se regulan los requisitos de los servicios, el procedimiento, y las especificaciones técnicas y funcionales para la subsanación de los ficheros TicketBAI.", es decir, algo bastante reciente. ¿Esto solo afecta a Gipuzkoa? Por los mensajes del foro, no parece que esté en funcionamiento, ¿no? y esto... ¿Afecta de manera directa al actual envío de facturas de Gipuzkoa o es más algo adicional?

También leo Asimismo, cuando el fichero de alta TicketBAI o el fichero de subsanación del
fichero de alta TicketBAI ha sido recibido sin errores y, sin embargo, el
contribuyente considera necesario modificar la información que contiene el
mismo, siempre y cuando no se trate de una causa que exija la emisión de una
factura rectificativa, se podrá generar un fichero de modificación que será
enviado a través del servicio zuzendu.

¿Qué caso real es este?

Saludos!

Dudas con Batuz
 

Buenos días, estoy implementado el desarrollo de ticketbai con batuz, y me surgen unas dudas, a ver si he entendido bien todo:
-se envía el modelo 140 (o 240), y en la cabecera se monta un json tal que asi:
luego en el cuerpo del mensaje,se envía un zip con el propio ticketbai,pero convertido a base64, y se utiliza esta estructura:
https://www.batuz.eus/fitxategiak/ba...ion_V1_0_2.xsd

-Es correcto lo que digo??
-Puedo enviar mas de una factura a la vez en el cuerpo del mensaje? varios registros metidos en el zip
-Puedo ir haciendo anotaciones en el modelo 140/240 siempre que quiera?o se hace todo a la vez? (yo creo debe de ser que puedes ir haciendo anotaciones conforme haces las facturas de ticketbai)

Muchas gracias por la ayuda (que por cierto,vaya lío,ya podría ser como las otras dos diputaciones... envías el xml y listo)

En principio, ese es el principal objetivo del sistema Batuz, cada factura firmada y demás irá codificada en base64 dentro de cada nodo correspondiente, citando a la documentación:

Generar un fichero XML, que cumple el formato del XSD del alta con facturas software garante, el cual, permite incluir un máximo de 1.000 ficheros TBAI en cada envío. Por cada factura el proceso es el siguiente:
o Codificar el fichero TicketBAI en Base64 e incorporarlo en el nodo “TicketBai” del
subcapítulo correspondiente.
o Completar el resto de datos de cada factura cuando proceda.
▪ Comprimir dicho fichero en formato GZIP.
▪ Incorporar el fichero comprimido en el cuerpo de la petición.

(Página 19 de este doc h_t_t_p_s://www.batuz.eus/fitxategiak/batuz/lroe/Batuz_LROE_Especificaciones_Env%C3%ADo_Masivo_V1_0_8.pdf?hash=35f5f37000e8873a209d53f4d18cc843)

Si el problema es sin Internet o problema del servidor es fácil saberlo, en ese caso se deja en cola y listo, se va usando y punto.
Si se recibe un error hay que tratarlo y ver q se hace. Ejemplo certificado caducado o revocado. En ese caso se corta por lo sano. Si es caducado solo tener en cta el período de gracia. Lo que sí hay que tener una forma de reactivar todo rápido y saltarse todos los bloqueos por cualquier imprevisto

Un XML del libro 140/240, en su interior hay 1..N nodos donde añades el XML del TicketBAI (correspondiente a una factura) codificado en formato base64.
Ese XML resultante (libro 140/240) lo comprimes como gzip y es lo que envías en la petición junto con la cabecera que has puesto.

Resumiendo: Un gzip, que dentro tiene un XML, con 1..N nodos en base64, que corresponden a un XML del TicketBAI (sencillito vamos...).

Si.
Los 1..N nodos que van en base64, dentro del XML del Libro que luego comprimes.

Si, es lo que hacemos algunos de nosotros para intentar "unificar" todo esto.
Porque cada administración se puede permitir hacer lo que quiera (que para eso son funcionarios y lo hacen con nuestro dinero), pero nosotros tenemos que intentar deasarrollar de una manera "óptima" y "estandard".
En nuestro caso intentamos "igualar" dentro de lo posible los tres procesos de envío (las tres administraciones), así que por ahora trabajamos de la misma forma en las tres: Factura que se genera, factura que se envía. Cambiando la mecánica (los builders) del fichero y del envío, pero de esa forma el proceso es compartido para las tres.

[MODO DESAHOGO]
Supongo que pedir que antes de lanzar un proyecto como este, se reunan y se pongan de acuerdo es demasiado pedir...
Para simplificar, para ahorrar trabajo (a ellos y a nosotros), ahorrar dinero (nuestro y de los contribuyentes), simplificar procesos, pruebas, minimizar instalaciones y servicios, minimizar problemas, ahorrar en burocracia, papeleo, organización,.... y tantas y tantas otras cosas.

¿Pa qué? Es mejor hacer cada uno lo que le sale del moño, y que el resto lo sufran...
Funcionarios y Administraciones públicas...
¿Os imagináis que dentro de un año las otras 47 provincias decidieran hacer lo mismo que ellos?
(lo siento por la "chapa", pero estoy muy quemado...)
[/MODO DESAHOGO]

Dudas sobre tiquets con importe cero.
 

Hola,


Hemos adaptado nuestro software para poder enviar tiquets a TIcketBai y la ayuda del foro a sido impagable para ello.
Pero nos surge una duda en los tiquets con importe cero. Por ejemplo una tienda de ropa, compras una prenda, se genera el correspondiente tiquet, se envia a TicketBai, etc.
Dias mas tarde se realiza un cambio de talla de la prenda, en nuestro sistema se genera un tiquet nuevo pero al tener una linea de tiquet en positivo y otra en negativo, se compensan y el total del tiquet es cero.


Como se enviaria esto en el XML? hay que indicar los totales, ivas, etc. a cero?



Saludos y gracias.

gracias por la ayuda Nefta!! y muy de acuerdo contigo, es un verdadero caos todo esto... con lo simple que sería que las 3 diputaciones se pongan de acuerdo...ni que fueran 40 provincias!!! son 3!!! pues cada una con sus cosas distintas... tócate los....

Correcto así de simple, negativo en la cantidad e importe total, el importe unitario siempre en positivo y el total da igual que sea cero o negativo, según reglamento de facturación se admite por cambio si son del mismo tipo impositivo.

Correcto así de simple, negativo en la cantidad del negativo e importe total del negativo tb con signo negativo, las líneas positivas como siempre, el importe unitario siempre en positivo y el total da igual que sea cero o negativo, según reglamento de facturación se admite por cambio si son del mismo tipo impositivos, si son distintos ivas o no se lleva nada a cambio en el mismo tiquet, rectificativa con su serie y numeración

Si alguno está interesado en comercializar su solución de TicketBAI, os aconsejo revisar el foro de trabajo (donde se publican ofertas y demandas) ya que hay alguna referentye a TBAI.
https://clubdelphi.com/foros/showthread.php?t=95444

Os lo pongo aquí porque se que hay muchos que accedéis a este hilo directamente, sin pasar por otras secciones del foro.

Batuz
 

Buenas! Ecuador de la semana ya, ánimo...

Una pregunta, ¿Cómo habéis gestionado la inmensidad de esquemas que existen en el sistema Batuz de Bizkaia? Es decir, en un entorno ya dinámico, en el cual los datos de la factura no son como cuando probamos con datos "picados a mano". Es que estoy viendo la de tipos que hay y demás y gestionar todas esas paramétricas me está dando vértigo. ¿Me estoy excediendo en mi visión sobre ello o es el infierno que aparenta?

Un saludo!

Hola bienvenido.
Muchas horas e ibuprofeno. Ánimo.

¿Se tienen en cuenta las facturas anuladas en el encadenamiento?
 

Según la FAQ sí se tiene en cuenta, es decir,

Factura_F1
Factura_F2 (ENCADENA CON "Factura_F1")
Anulacion Factura_F1 (No lleva encadenamiento, así lo marca el XSD)
Factura F3 (ENCADENA CON LA Anulacion Factura_F1) es decir justo con la anterior, que en este caso, es una anulación

¿Lo veis correcto?

FAQ:
¿Se tienen en cuenta las facturas anuladas para el encadenamiento?
Sí.
La anulación de las facturas se prevé para el supuesto en que por error se emite una
factura sin que se llegue a producir la entrega de bien o prestación de servicio, es decir,
cuando la operación no ha llegado nunca a realizarse y procede su anulación (DGT
V0611/ 11-3-2011).
A efectos del encadenamiento, sin embargo, puede ser que la factura anulada sea la
inmediata anterior puesto que con independencia de que la anulación puede tener lugar
de manera inmediata subsiguiente a la emisión, o en un momento ulterior, el archivo
XML-TicketBAI correspondiente a la factura que devendrá anulada debe ser remitida y
sirve como factura antecedente a efectos del encadenamiento. Además, es posible que
entre la emisión de la factura que luego se anula y la anulación ulterior puede haberse
emitido facturas válidas, por lo que la factura que ulteriormente pueda ser anulada,
puede tener la consideración de factura anterior a efectos del encadenamiento

Hola nuevo1234,

No hay que encadenar ninguna factura a una anulación.
A lo que hay que encadenar cada factura es la anterior factura, aunque esté anulada (no a su anulación).
Así lo entiendo yo.

Saludos.

Factura_F1
Factura_F2 (ENCADENA CON "Factura_F1")
Anulacion Factura_F1 (No lleva encadenamiento, así lo marca el XSD)
Factura F3 (ENCADENA CON Factura_F2)

En verde negrita lo que cambia con respecto a lo que tú piensas

La anulacuión como tal no es una fatura, por lo tanto las facturas que has emitido son estas:

• Factura_F1
• Factura_F2 (ENCADENA CON "Factura_F1")
• Factura F3

Y el encadenamiento es de esas tres facturas.

• Factura_F1, Factura_F2, Factura F3

Nadie ha dicho otra cosa.
Lo que en algún mensaje anterior se ha dicho es que la anulación no se tiene en cuenta para el encadenamiento, pero si la factura anulada.

Certificados de Aplicación
 

Buenas tardes, tengo dudas existenciales acerca de los certificados de aplicación para firmar mis ejecutables e instalador para windows


Comodo Code Signing 90€/año
DigiCert EV Code Signing Certificate 533€/año
DigiCert Code Signing 262€/año
Sectigo Code Signing EV 249€/año

Tenéis experiencia con alguno de ellos? :confused:
Contratáis para 1,2,3 años?


Agradecido de antemano.
Un saludo.

Cancelar facturas Batuz
 

Hola
No tenemos ningún problema para dar de alta una factur aTicketab en Batuz, en el entorno de prueba, pero a la hora de cancelar:
Realizo los mismo pasos para dar de alta y parar cancelar.


1.-TicketBai xml firmar y guardar.
2.- recuperar el xml

$content = file_get_contents(public_path() . '/storage/app/public/' . $invoicesXml->xml_name);

3.- dentro del LROE añado en xml:

$xml .= "<AnulacionTicketBai>" . base64_encode($content) . "</AnulacionTicketBai>";

Y para finalizar lo envió por CURL, pero como os he dicho uso los mismos métodos para dar de alta y no tengo ningún problema

Entorno de pruebas Araba
 

Hola estoy intentando enviar a Araba en pruebas y devuelve error 006 servicio caído, a alguien le pasa igual?

Gracias

Unas preguntas, sobre todo para los que ya tienen experiencia con TicketBAI.


1. ¿De que forma se organiza este sistema para tener en cuenta (por ejemplo) la imposibilidad de enviar los datos si te quedas sin internet, fallo de ordenadores, etc.? ¿Hay que comunicarlo, hay que enviarlo después, ....?
2. ¿De que forma se trata a aquellos obligados tributarios que no tienen un ordenador o tpv físico?, por ejemplo gente que trabaja en mercadillo, muchas veces sin acometida de luz.
3. Parecida a la anterior... ¿de qué forma tratan a los que, por ejemplo, tienen una tienda o negocio en un pueblo de montaña con una comunicación por internet casi nula?.


Gracias!

Lo mismo.

Gracias Germán^\||/^\||/

Generas la factura, la firmas, generas el XML y si es necesario la imprimes.
Enviarla, puedes hacerlo más tarde cuando se restaure la conexión.

No creo que hayan pensado en esas personas.
Antes o después tendrán que usar algún dispositivo móvil con conexión para enviar los tickets.

Segun la documentación debes enviar las facturas "lo antes posible", en esos casos, no se si puedes tener algo más de tiempo. Pero al final debes acabar enviándolas.

Hola ion,

Verifica el xml firmado en https://tools.chilkat.io/xmlDsigVerify

Si te da correcto y te sigue contestando Batuz con ese error, comprueba con qué codificación se te guarda el fichero.

Saludos

Yo registré Comodo Code Signing con https://www.leaderssl.es/?fltr_type=...l-filter-block. Perfecto. No problems.
...Y aquí parece que es todavía más barato: https://www.ssltrust.com/comodo-ssl/...e?currency=EUR

Pagos a cta
 

Para los que les interese, al final he preguntado directamente en hacienda. Lo de los pagos a cta hay que hacer factura del dinero recibido a cuenta de un pedido, el desglose de los tipos impositivos será según los tipos impositivos de artículos o servicios del pedido, y si hay varios tipos impositivos te admiten pagar el IVA como mejor te venga, pero respetando los importes máximos de las sumas de las operaciones según el IVA.
Aunque creo que es mejor desglosarlo de forma proporcional.

LROE error cancelar ticketbai
 

Gracias, he verificado, y el xml no es correco:

Signature is Invalid
Number of Reference Digests = 3
Reference 1 digest is invalid because the computed digest differs from the digest in the XML.
Reference 2 digest is invalid because the computed digest differs from the digest in the XML.
Reference 3 digest is valid.

Uso la clase firmador de Bilbur, dejo el xml por si alguien podria ver el fallo:

Agradecido
 

Muchas garcias compi. ^\||/^\||/