FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
|
Herramientas | Buscar en Tema | Desplegado |
#3061
|
||||
|
||||
Cita:
Revisa que sean las mismas que tú tienes y que sean corectas.
__________________
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. |
#3062
|
||||
|
||||
Hola a todas.
Deciros que hacienda de bizkaia ya ha habilitado el envio de los suplidos/provisiones en el 140 de producción. Por otra parte ayer me dieron dos tickets con el codigo QR de Bizkaia, uno en una panaderia y otro en una farmacia. Los dos estaban mal, uno solo contenía el TBAI, no la dirección de hacienda y otro un número que no se veía que era. Por si estais por aqui. |
#3063
|
|||
|
|||
No sé si os ha llegado esta noticia https://www.elcorreo.com/economia/bi...212421-nt.html
Al final nos piden a nosotros que hagamos el trabajo pero ellos siempre lo retrasan. |
#3064
|
|||
|
|||
Cita:
Hola, me han contestado de Gipuzkoa. Lo pongo aquí por si a alguien le sirve de ayuda. En pruebas, al utilizar un certificado de dispositivo, hay que mandarles un mail para registrar el dispositivo. En las operaciones de ANULACION, controlan que el dispositivo este registrado. Un saludo. RESPUESTA DE HACIENDA GIPUZKOA: ----------------------------------------------------------------------------- Egun on, buenos días Esto ocurre porque el control en la Anulación de facturas es más restrictivo que en el Alta de facturas. Para solucionar este error en el entorno de pruebas, deben enviar un correo a este mismo buzón indicando que quieren registrar un dispositivo. Anoten los siguientes datos en el mensaje:
|
#3065
|
|||
|
|||
Email nuevo enviado por Alava
Cita:
|
#3066
|
|||
|
|||
Cita:
Está claro que lo importante para el cliente es seguir facturando independientemente de si tiene o no conexión en ese momento para el envío de las facturas así que nuestro software genera el xml, lo firma, genera el identificador, el QR e imprime. Y luego ya añade el xml a una cola y trata de enviarlo cuando pueda. La única excepción a este comportamiento es si detectamos que el certificado de firma ha caducado. En ese caso, sabiendo que la factura va a ser rechazada (porque va a ser rechazada por el servicio, ¿verdad? - no tengo medios para probar ésto, la verdad - ), no le dejo facturar e imprimir, es decir, activamos una restricción para que el software continúe emitiendo facturas (y así el cliente puede seguir operando) pero sin la posibilidad de impresión (así no habrá facturas sin identificador TBAI ni QR por el mundo). Luego, cuando actualicen el certificado, podrán generar todos esos xml sobre las facturas no impresas, firmarlas y enviarlas. Creo que es una solución interesante que no me parece que rompa el reglamento y además es lo único que se nos ha ocurrido para evitar posibles errores a la hora de subir la factura. Se admiten otras ideas Bueno dicho ésto, el tema de la gestión de los errores me trae por la calle de la amargura. ¿Qué pasa si tengo tres facturas en cola (F1, F2, F3) y la primera (F1) es rechazada por cualquier motivo?. ¿Entiendo que el resto no se pueden subir hasta que suba esa primera que actúa como un "tapón", verdad?. Si la subsanación de esa factura para que sea "aceptada" por el servidor tbai implica hacer cambios en la misma, habría que volver a firmarla y se iría a tomar por saco el encadenamiento con el resto de las facturas posteriores (F2 y F3) y cambiaría el identificador TBAI y el QR de esas facturas que ya están impresas y con los clientes finales. Vamos un problemón. ¿Cómo lo estáis enfocando vosotros?. Necesito otras visiones porque me pongo cardíaco. Otra cosa es que la factura sea aceptada y luego el servicio ya te devuelva advertencias o errores que habrá que subsanar entiendo que con Zuzendu, pero eso ya es otra guerra que irá después de ésta. Las cosas secuencialmente y paso a paso Muchas gracias. |
#3067
|
|||
|
|||
Ostras, precisamente estaba dándole vueltas justo a este tema en mi mensaje anterior
Por lo que entiendo, TODO lo enviado ya no se puede tocar, sea aceptado o rechazado por lo que no se pueden generar "tapones" en el envío de ficheros y el encadenamiento de todas las facturas no tendrá ningún problema porque esas facturas nunca se va a poder modificar. ¿Esto es así en TODAS las diputaciones o sólo en Alava? Lo digo porque parece que cada uno hace la guerra por su cuenta. Y pregunto, si la factura TBAI ha sido rechazada por ejemplo, por un certificado inválido o porque se ha consignado mal el has de la política de firma, por ejemplo, Zuzendu va a "tragar" siempre porque no se firma digitalmente. Otra cosa es que tengamos fallos en el esquema o no se haya consignado algún campo obligatorio ... En el "Listado de validaciones y errores del fichero de ALTA TicketBAI" de Alava, pone lo siguiente: Cita:
Cuando hablan de la firma de la factura original, entiendo que se refieren al nodo <SignatureValueFirmaFactura> que va con los 100 primeros caracteres de la forma, ¿no? |
#3068
|
||||
|
||||
Cita:
Segun eso, te admitirán las facturas, pero te darán un mensaje de aviso y un tiempo prudencial (unos días) para que instales los nuevos certificados. Cita:
Esa "factura" de la que nos has generado XML, firmado,... es modificable. Justo esa situación es la que no quieren. Según dicen, las facturas deben enviarse "lo antes posible". Si te pasas 2 días generando facturas, sin firmar, sin encadenar,... y al cabo de 2 días (cuando tienes los certificados) las envías todas juntas no creo que les haga mucha gracia. Yo creo que debrías generar las facturas, el XML, firmarlas, enviarlas, generar los "encadenamientos correlativos" (aunque las rechaze) y luego cuando tengas los certificados correctos enviarlas de nuevo corregidas o con los métodos alternativos que proveen las diferentes diputaciones.
__________________
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. |
#3069
|
||||
|
||||
Cita:
Son cosas distintas. Ellos tendrán las tres facturas encadenadas de forma correcta, pero la F1 será rechazada. Más adelante ya enviarás la F1 de nuevo por los métodos alternativos (ZUZENDU) o otros libros en el caso de BATUZ. (2) Los servicios de modificación (tipo ZUZENDU) o los envíos en otros libros en BATUZ se suelen hacer sin firma, justo para no tener problemas con los encadenamientos. La factura original ya está firmada, encadenada y almacenada y la "subsanación" será enviar una serie de datos "extra" para corregir la original, pero esos envíos de subsanación no van firmados ni llevan encadenamiento. (para que te hagas una idea) (3) Hay advertencias que no necesariamente te obligan a reenviar. Algunos son avisos. Por ejemplo, el comentado anteriormente del certificado. Te pueden avisar de que el certificado está caducado, pero te las aceptan. El aviso te sirve para corregir el error, pero no debes enviarla de nuevo, porque la factura es si es correcta (sólo falla el certificado).
__________________
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. |
#3070
|
|||
|
|||
Cita:
Con ésto claro, lo que tiene más sentido, como bien comentas en el otro post, es generar siempre el xml, firmarlo y enviarlo aunque sepas que puede que haya algo mal (como la caducidad del certificado) porque luego ya lo corregirás con Zuzendu. |
#3071
|
|||
|
|||
Cita:
Como muy bien te indica nuestro colega Neftali, en ningún caso debes hacer eso. Es lo que TicketBAI intenta evitar: que se puedan emitir facturas sin firmar y encadenar (que podrían ser borradas) Ten en cuenta que, actualmente, es obligatorio SIEMPRE imprimir ticket de cualquier venta. Tengo noticias de inspectores de Hacienda Foral de Bizkaia que se han colocado en la puerta de un comercio e iban preguntando a los clientes que salían si les habían dado ticket. Si no les dan, ya sabes: Entran, se identifican y abren expediente. Hay que imprimir siempre el ticket de la venta aunque el cliente no lo coja y vaya a la papelera. Y eso ahora, antes de TicketBAI .... así que figúrate cuando TicketBAI sea obligatorio. Saludos |
#3072
|
|||
|
|||
Cita:
Y un tema ya por curiosidad. Imaginemos que el certificado está caducado. Aún así se firma con él la factura y luego se envío. En la fase de recepción será rechazada (es una de las cosas que se comprueban) aunque como ya he aprendido, queda registrada en su sistema a la espera de una subsanación a través de Zuzendu en Gipuzkoa y Araba (y de LROE en Bizkaia aunque ya tendré que mirar cómo se hace eso). El problema es que, si es tema del certificado de firma y con Zuzendu no hay que firmar nada, ese error no se podría subsanar de ninguna manera, o al menos no se me ocurre cómo. |
#3073
|
|||
|
|||
Cita:
Los servicios Zuzendu son para corregir los datos de las facturas, no los ficheros XML TicketBAI firmados. Si el fichero está mal, pues lo está y punto. No se puede corregir. Mediante Zuzendu, lo que haces es corregir los datos de esa factura (NIFs, bases imponibles, cuotas de IVA, ...) para que Hacienda Foral se quede tranquila y la considere como si hubiese llegado bien el XML firmado. Saludos |
#3074
|
|||
|
|||
Hola a todos!
Ya tenía todos los servicios funcionando, aun que ningun cliente quería estar en la fase de pruebas, y ahora les entran los nervios... Lo dejé todo tal cual a fecha Diciembre de 2021 El único cambio ha sido la subsanación de fallos(zuzendu)? |
#3075
|
||||
|
||||
Revisa se tengas actualizadas las políticas de firma:
https://www.clubdelphi.com/foros/sho...97&postcount=1 (a mitad del mensaje) Los HASH de las políticas de firma (que si han cambiado): https://www.clubdelphi.com/foros/sho...97&postcount=1 (debajo de las URL's)
__________________
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. |
#3076
|
|||
|
|||
Sobre Certificados...help!
Hola a toda la gente que colabora en este mágnífico foro.
Estamos en fase de pruebas enviando XML de alta y anulación en Álava y Guipuzkoa. Necesitamos que alguien nos aclare de qué forma podemos usar un certificado "genérico" para integrarlo en nuestro software y que sirva para todas nuestros clientes. Soporte de TBAI nunca nos dejan nada claro, hablan de certificado de usuario, de autónomo, de dispositivo....y siempre nos remiten a los certificados de test IZENPE. Lo cierto que es agradeceríamos si alguien nos arroja algo de luz en este sentido, he leído algunos post comentando sobre certificados de software que se compran como los de ksoftware.net * ¿serían la solución que andamos buscando? * ¿es posible integrar nuestro certificado de empresa usando el parámetro<Factura emitida por tercero o destinatario> = T (Tercero) y sería correcto? en ese caso, ¿deben firmar nuestros clientes un consentimiento por enviar sus tickets firmados con nuestro certificado? ¡muchas gracias a todos! |
#3077
|
|||
|
|||
Cita:
Si quieres usar un mismo certificado digital para todos tus clientes, el método más adecuado es el que comentas: marcar el nodo <EmitidaPorTercerosODestinatario> con el valor T Eso te permitirá usar, por ejemplo, tu certificado para firmar los ficheros XML. Aunque para enviarlos (recuerda que se precisa certificado para ese envío) debes seguir el procedimiento de autorización que exige cada Hacienda Foral. Entra en cada una de ellas y sigue el procedimiento que indiquen en su web. Y lo lógico es que pidas a todos tus clientes que firmen un documento de autorización de que tú emitirás, firmarás y enviarás sus facturas en su nombre. También es recomendable que tengas, al menos, 2 certificados (por ejemplo, uno de FNMT y otro de IZENPE) con distintas fechas de caducidad. Cuando solicitas renovar un certificado, queda revocado el anterior, por lo que ya no podrás utilizarlo hasta que no tengas instalado el nuevo. Cambiando de certificado, antes de solicitar la renovación del que venías utilizando, puedes seguir trabajando con el otro hasta que consigas el nuevo. Saludos. |
#3078
|
|||
|
|||
Hora última factura
Buenas tardes,
tengo una duda sobre la hora de grabación, ejemplo; Emito una factura (numero 1) con hora de expedicion 14:00:00 Se actualiza la hora del sistema unos segundos por algún problema con la pila a las 13:59:45 Emito Factura numero 2 a las 13:59:55. Sabeis si en los casos de no tener el orden cronologico de fecha expedicion exacto da alguna incidencia el sistema de recepcion de tiquetbai? |
#3079
|
|||
|
|||
Error Envio Bizkaia
Hola,
Estoy haciendo pruebas de envíos de facturas a Bizkaia y todo iba bien hasta el miércoles que decidí enviar un paquete con 270 facturas. Al intentar el envío me dio el siguiente mensaje de Chilkat (parecido, este es del envío de prueba de hoy para ver si funcionaba). ChilkatLog: ReadResponseHeader: DllDate: May 28 2021 ChilkatVersion: 9.5.0.87 UnlockPrefix: XXXXXXXXXXXXXXXXX Architecture: Little Endian; 32-bit Language: ActiveX VerboseLogging: 0 Failed to read beginning of SSL/TLS record. b: 0 dbSize: 0 nReadNBytes: 0 idleTimeoutMs: 30000 Failed to receive more TLS application data. tlsApp: Socket operation timeout. elapsedMs: Elapsed time: 31281 millisec Failed. --ReadResponseHeader --ChilkatLog También he probado con paquetes mas pequeños y ha realizar consultas. Todo el rato lo mismo Socket operation timeout. ¿Sabe alguien si está pasando algo en el servidor de pruebas de Bizkaia? Les he enviado a los de Soporte de TicketBAI (Bizkaia) y todavía no me han contestado. ¿Alguna idea de que puede estar pasando? Saludos y muchas gracias, Joselu |
#3080
|
|||
|
|||
Solucionado
Cita:
Muchas gracias, Joselu |
Herramientas | Buscar en Tema |
Desplegado | |
|
|
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 | 20-08-2024 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 |
|