FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#2721
|
||||
|
||||
Perfecto, así que esta es la famosa memoria completamente de relleno que había leído por mensajes anteriores jeje Gracias!
Un saludo |
#2722
|
||||
|
||||
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! |
#2723
|
|||
|
|||
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.
Última edición por ermendalenda fecha: 07-02-2022 a las 13:40:41. |
#2724
|
||||
|
||||
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)
|
#2725
|
|||
|
|||
Cita:
Código:
tbai_invoice_number: 220041 tbai_previous_invoice_number: 220040 tbai_status: emitido tbai_invoice_date: 2022-02-03 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. |
#2726
|
||||
|
||||
Cita:
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#2727
|
||||
|
||||
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! Última edición por b4aronDeLaBirr4 fecha: 07-02-2022 a las 14:18:36. Razón: Información actualizada |
#2728
|
||||
|
||||
[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]
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#2729
|
|||
|
|||
Cita:
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. Última edición por ermendalenda fecha: 07-02-2022 a las 20:49:11. |
#2730
|
||||
|
||||
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... |
#2731
|
|||
|
|||
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 |
#2732
|
||||
|
||||
Pienso lo mismo, facturar no puede dejar de hacerse. Gracias!
|
#2733
|
||||
|
||||
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! Última edición por b4aronDeLaBirr4 fecha: 08-02-2022 a las 10:59:27. Razón: Nueva información |
#2734
|
|||
|
|||
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: Código:
eus-bizkaia-n3-data = { "con": "LROE", "apa": "1.1", "inte": { "nif": "número de identificación fiscal", "nrs": "nombre o Razón social", "ap1": "primer apellido", "ap2": "segundo apellido" }, "drs": { "mode": "140/240", "ejer": "ejercicio" } } 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) |
#2735
|
||||
|
||||
Cita:
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) |
#2736
|
|||
|
|||
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 |
#2737
|
||||
|
||||
Cita:
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...). Cita:
Los 1..N nodos que van en base64, dentro del XML del Libro que luego comprimes. Cita:
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]
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#2738
|
|||
|
|||
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. |
#2739
|
|||
|
|||
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....
Última edición por pablog2k fecha: 08-02-2022 a las 13:55:19. Razón: añadir cosas |
#2740
|
|||
|
|||
Cita:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice | newtron | Internet | 3587 | Hace 4 Semanas 14:11:07 |
Como utilizar la ayuda del nuevo Sistema Operativo | gluglu | Humor | 3 | 24-09-2007 09:39:05 |
Aplicacion Agencia De Viajes | ArdiIIa | Varios | 9 | 20-01-2007 16:49:53 |
El Vasco Aguirre | Al González | La Taberna | 5 | 26-05-2006 09:22:28 |
Microsoft ha lanzado su nuevo sistema operativo | DarkByte | Humor | 0 | 25-01-2004 09:21:14 |
|