FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#3041
|
|||
|
|||
Cita:
1. Especificaciones del código identificativo El código identificativo identifica a la factura o justificante generado mediante la utilización del software garante y asegura su relación con su correspondiente fichero de alta de operación con software garante al que se refiere el artículo 3 de la presente Orden Foral. Tiene una longitud fija de 39 caracteres. El tipo y el tamaño de la fuente del código identificativo deberán ser similares al del resto de la factura o justificante, asegurando su legibilidad por parte de su destinatario o destinataria. El contenido del código identificativo es el siguiente: ─ 4 caracteres de texto fijo en mayúscula: TBAI. ─ 1 carácter “- “como separador. Guion medio. ─ 9 caracteres del NIF de la persona o entidad emisora de la factura o justificante. Debe corresponder con el NIF, según su formato oficial, incluido en el fichero TBAI. ─ 1 carácter “- “como separador. Guion medio. ─ 6 caracteres de la fecha de expedición de la factura o justificante. Debe corresponder con la fecha incluida en el fichero de alta de operación con software garante, en el campo denominado “FechaExpedicionFactura”, en formato DDMMAA, sin separadores internos. Cada uno de los subcampos será rellenado con ceros a la izquierda en caso de ser necesario, de manera que el tamaño de la fecha será siempre 6 números en todos los casos (por ejemplo, 010122 sería uno de enero de 2022). El formato DDMMAA se compone de: DD: día de la expedición de la factura, MM: mes de la expedición de la factura y AA: últimos dos dígitos del año de expedición de la factura. Por ejemplo, para 2021, AA=21. ─ 1 carácter “- “como separador. Guion medio. ─ 13 primeros caracteres de la firma del fichero de alta de operación con software garante, es decir, del campo “SignatureValue” del fichero correspondiente a la factura o justificante. ─ 1 carácter “- “como separador. Guion medio. ─ 3 caracteres que se corresponden con un código de d |
#3042
|
|||
|
|||
Cita:
Buenas, Keys. Pues no te puedo decir si funciona en postproducción, pero acabo de probar a mandar un Suplido del 2022 en desarrollo y va perfecto. |
#3043
|
||||
|
||||
Ese es el problema, lo han añadido en desarrollo, en la pagina web del LROE, pero no en producción para los clientes.
|
#3044
|
||||
|
||||
Hola a todos.
En Bizkaia a la hora de hacer un envío hay definidos unos "Códigos de respuesta HTTP para errores de cliente" como son el Cita:
En HeaderValue[0] retorna solo Keep-Alive |
#3045
|
||||
|
||||
Hola a todos me respondo a mi mismo aunque no estoy seguro ya que no lo puedo probar.
AResponse.StatusCode Creo que es donde retorna esos códigos de error. |
#3046
|
||||
|
||||
Revisa el Headers del Response. Si ahí no hay nada, sólo queda (como tú has dicho) el StatusCode y StatusText.
__________________
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. Última edición por Neftali [Germán.Estévez] fecha: 28-04-2022 a las 08:57:01. |
#3047
|
|||
|
|||
Buenas tardes, una cosilla sin importancia. Para el 2024 comienza un cambio (similar al del efecto 2000) lo conocerán mejor los que eran informáticos en esa fecha.
El cambio es a nivel de criptografía y va a afectar hasta los routers. No será de un día para otro, pero tened previsto que los actuales certificados electrónicos tendrán otros tipos de clave pública y privada, los dni electrónicos etc etc etc. Pero no os asustéis no será de un día para otro Solo lo digo para que no os relajeis. |
#3048
|
|||
|
|||
Hola de nuevo a tod@s
Una duda que me ha surgido y ante la cual no encuentro información. Imaginaros que he hecho una factura Modelo 240 y la he enviado a Hacienda. Ahora resulta que me he dado cuenta de que he cobrado de más y que tengo que hacerle una abono al cliente. hablando con la empresa para la cual estoy adecuando la app, me dice que ellos hacen una factura de abono, es decir con importe negativo. Hasta ahí no hay ningún problema. la duda que me entra es si esto es correcto de cara a seguir con los protocolos de TicketBAI. Es decir, yo puedo emitir esa factura (con importe negativo) a hacienda, igual que hago con una factura normal? Es que a la hora de generar el xml no encuentro nada que me diga si los valores que van en ese xml cambian o no con respecto a una normal. Para anulacion de facturas si que hay ejemplos de xml pero para este caso yo no he encontrado nada. Lo mismo me ocurre con el xml que se genera para el LROE (es decir el envio) Alguien me podría echar un cable? Gracias |
#3049
|
||||
|
||||
Cita:
|
#3050
|
|||
|
|||
Cita:
Cita:
|
#3051
|
||||
|
||||
A mi en Alava me respodieron lo siguiente :
Cita:
Cita:
|
#3052
|
|||
|
|||
Cita:
No tendrá alguien un xml generado de una factura rectificativa por sustitución, para ver como es la estructura de dicho xml verdad? es que me sería de grana ayuda. Muchas gracias |
#3053
|
|||
|
|||
Dos digest en SecureBlackBox
Buenas compañeros,
Aquí otro de los visitantes ocultos recurrentes que ha tenido que registrarse gracias al cachondeo padre que parece ser el sistema de TicketBAI, con especificidades para cada una de las provincias, como si no fuera bastante trabajo el adaptar un software para que cumpla sus requisitos de firma y envío. Veo que no estoy sólo en ello y si bien no arregla nada, las penas compartidas son menos penas, o eso dicen Ya que estoy por aquí, intentaré ser lo más productivo que pueda a la comunidad e intentar aportar tb mi conocimiento a fin de ayudar a quien lo necesite. Y ya de paso, quería agradecer tanto a @keys como a @espinete todo lo que han escrito sobre las SecureBlackBox, la punta de lanza en la que me he apoyado para montar mi desarrollo en C++. Muchas gracias . La verdad es que es una jodienda que no haya apenas ejemplos para la nueva versión 20 y casi todo lo que se encuentra es para la 16. Por cierto, con la SecureBlackBox, únicamente se generan dos digest en el xml pero por lo que me ha parecido entender tras las ¡¡¡ 153 !!! páginas es que tira bien con eso aunque el ejemplo que se puede descargar de Batuz tenga 3, ¿verdad?. Yo de todas formas he escrito a nsoftware para que me orienten sobre cómo se podría agregar uno nuevo (quizás con AddReference() ) si fuera posible. |
#3054
|
|||
|
|||
Una pregunta, estoy intentando enviar tickets de caja a Batuz, y lo hago igual que las facturas normales pero marcando
"<FacturaSimplificada>S</FacturaSimplificada>" y aún sí me pide establecer el Nif del destinatario. ¿cómo hacéis para enviar un ticket del cual no sabemos el nif? |
#3055
|
|||
|
|||
Cita:
Aprovecho para incluir los hashes actualizados porque veo que algunos errores de validación (sobretodo en Batuz) vienen de usar un hash antiguo en la política de firma. Es el problema de usar código de hace unos meses, que uno se confía y resulta que lo han cambiado. Cuando tenga permisos para publicar urls, también las añadiré para tenerlo todo en el mismo sitio ... Código:
Araba Hash: d69VEBc4ED4QbwnDtCA2JESgJiw+rwzfutcaSl5gYvM= Hash en Hex: 77AF55101738103E106F09C3B420362444A0262C3EAF0CDFBAD71A4A5E6062F3 Gipuzkoa Hash: vSe1CH7eAFVkGN0X2Y7Nl9XGUoBnziDA5BGUSsyt8mg= Hash en Hex: BD27B5087EDE00556418DD17D98ECD97D5C6528067CE20C0E411944ACCADF268 Bizkaia Hash: Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es= Hash en Hex: 42ECE7F7CC773CC6D21F06D4CDA8F97F928EA621F4BBC6EF9B06DB6CD90EF44B |
#3056
|
|||
|
|||
Cita:
¿Descubriste al final qué cliente estaba firmando mal?. ¿No te proporcionaron ni el CIF del emisor para que pudieras al menos poder contactar con el cliente y solucionar el problema? Y sobre el tema de la comprobación del CIF, yo el problema que le veo es que si el certificado es de algún tipo de representante registrado en TBAI su CIF no va a coincidir de ninguna manera y será imposible detectar este tipo de problemas. Y ya por curiosidad mía. Siendo un "software garante" que emite facturas rechazadas, ¿puede acarrear algún tipo de sanción sobre el fabricante del programa? |
#3057
|
|||
|
|||
Anulación de facturas en entorno de pruebas
Hola,
al anular facturas en el entorno de pruebas, Gipuzkoa me devuelve siempre el error 13 (Falta aceptar el Registro del Dispositivo remitente. Acceda a la sede electrónica y gestione el dispositivo.). Al estar en el entorno de pruebas, no puedo verificar ningún dispositivo. ¿Habéis tenido algún problema al anular facturas en el entorno de pruebas en Gipuzkoa? ¿Os funciona bien? Un saludo. Gracias. |
#3058
|
|||
|
|||
Cita:
No añadas en el XML el nodo <Destinatarios> Fíjate en https://www.gipuzkoa.eus/documents/2...28/Anexo+I.pdf que está en negro (no es obligatorio en el caso de facturas simplificadas) Eso es todo. Saludos |
#3059
|
|||
|
|||
Cita:
Acabo de hacer una prueba y me la anula correctamente. Lo raro es que te dé error de dispositivo remitente para la anulación y no para la alta. |
#3060
|
||||
|
||||
Los he añadido a la página inicial (mensaje 1) con el resto de datos.
Gracias. Si debes añadir alguna URL, puedes ponerla cambiando (por ejemplo) la parte inicial por h_t_t_p:/_/ (o algo similar) Luego algunos de los moderadores la editamos y la ponemos correctamente.
__________________
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. |
|
|
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 | 3594 | Hace 3 Semanas 20:44:37 |
Como utilizar la ayuda del nuevo Sistema Operativo | gluglu | Humor | 3 | 24-09-2007 10:39:05 |
Aplicacion Agencia De Viajes | ArdiIIa | Varios | 9 | 20-01-2007 17:49:53 |
El Vasco Aguirre | Al González | La Taberna | 5 | 26-05-2006 10:22:28 |
Microsoft ha lanzado su nuevo sistema operativo | DarkByte | Humor | 0 | 25-01-2004 10:21:14 |
|