|
Cita:
Pues no hace falta :D:D |
Cita:
|
Cita:
(preproducción) |
Cita:
Hemos recibido varias llamadas de usuarios al respecto, y les decimos que vuelvan a intentarlo más adelante. !!!:-| OJO: Incluso nos ha ocurrido en un cliente que ha enviado la factura, el programa se ha tirado un minuto esperando respuesta y se ha desconectado (examinado en los logs). Hacienda tenía la factura pero no ha enviado el OK (ni error, ni nada) así que nos encontramos con una factura subida que puede comprobarse con lectura de QR, y sin embargo en modo local consta como no registrada. Evidentemente no puede reenviarse porque Hacienda ya tiene ese número registrado. Suponemos que este problema está motivado por la inestabilidad del servicio, pero igual es mucho suponer, y en producción puede pasar lo mismo... :( Saludos, |
Cita:
Estoy preparando una API en PHP Una pregunta para Sistel, El fichero json que envías a la API viene a ser el xml completo previo a la firma del mismo o es una conjunto pequeño de datos con los que generar el xml (código empresa, código cliente, fecha, etc) Estoy optando por esto último pero así la API resulta menos "genérica" y mas "personalizada" Gracias |
Cita:
El fichero JSON que se envía a mi API contiene sólo los datos básicos: - Identificación del emisor - Datos del destinatario (si lo hay, como en el caso de factura completa) - Tipo de factura y características esenciales - Líneas de detalle (nombres de productos, importes unitarios, cantidades, descuentos, tipo de IVA, ...) No se envían ni serie, ni número ni fecha de factura ni datos económicos ni total. La API se encarga de: - Verificar los datos que le llegan - Recabar los datos de la última factura (de ese tipo) del emisor desde la base de datos - Crear líneas de detalles adicionales si hay descuentos globales en la factura - Calcular datos económicos como bases, cuotas de IVA, totales, ... - Asignar serie, número y fecha de factura - Crear el XML - Firmar el XML - Comprobar la validez del XML firmado (con el esquema XSD) - Grabar los datos de la factura, los detalles y los importes en la base de datos - Devolver un JSON con todos los datos calculados (bases, cuotas, totales, líneas de detalle), serie, número y fecha de la factura y códigos TBAI y QR - Enviar a la correspondiente Hacienda Foral el XML TicketBAI y registrar el envío en la base de datos. Opté porque la API lo haga todo y retorne todo lo necesario para crear el documento de la factura. No puedo confiar en que llegue, del emisor, el total correcto o el número de factura o fecha correcta. Prefiero que eso lo genere mi API. Saludos |
Una ayudita
Buenas a todos, tengo un pequeño dolor de muelas:
Estoy intentando parsear la respuesta de Batuz a objeto y con el 140 perfecto, pero el 240 no hay manera, he descargado los últimos XSDs publicados por Bizkaia y he regenerado la clase varias veces pero en todos los casos me peta diciendo: "No se esperaba <LROEPJ240FacturasEmitidasConSGAltaRespuesta xmlns='https://www.batu etc..." La clase parece haberse generado bien y el XML de respuesta tiene buena pinta así que no sé que más hacer ¿Habéis tenido algún problema similar? Gracias y buen finde! :) |
Cita:
¿El error que obtienes, te da ejecutando algún código (dices que la generación parace correcta)? Puedes poner el código. |
Cita:
El XSD es el siguiente: "LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaRespuesta_V1_0_1.xsd", que a su vez depende de "batuz_Enumerados.xsd", "batuz_TiposBasicos.xsd" y "batuz_TiposComplejos.xsd" El comando que empleo para generarlo es: (En la consola para desarrolladores de visual studio) Código:
"/c LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaRespuesta_V1_0_1.xsd batuz_TiposComplejos.xsd batuz_Enumerados.xsd batuz_TiposBasicos.xsd /namespace:TicketBaiBatuzAlta240Respuesta"Código:
LROEPJ240FacturasEmitidasConSGAltaRespuesta batuz240RespuestaAlta = new LROEPJ240FacturasEmitidasConSGAltaRespuesta();Gracias de antemano ^\||/ |
Cita:
En mi caso VisualStudio sólo lo uso para visualizar los XSD. A ver si alguien que importe ficheros te puede dar más información. |
Han enviado de Gipuzkoa el siguiente mensaje :
Cita:
|
Cita:
|
Warning en la verificación de la firma
Después de una breve pero intensa travesía por el desierto (menos desierto gracias a este foro y a las experiencias expuestas aquí por muchos usuarios), he podido subir al entorno de pruebas de Alava mi primera factura sin errores. Yuhuuuuu.
Por el camino he descubierto que es importante el orden de los nodos y que algunos datos supuestamente opcionales son en realidad obliggatorios pero afortunadamente nada que un ensayo y error pueda subsanar. Ahora lo que estoy intentando procesar son los warnings. Vale que son sólo advertencias pero hay uno que me gustaría saber a qué se puede deber. Se trata delç 008, Error de verificación de firma Estoy usando una versión trial (de momento) de SecureBlackBox y andaba un poco preocupado porque sólo genera dos digest (en vez de tres como en algún ejemplo publicado en las webs oficiales) en el xml pero supongo que si fuera por algo así o que estuviese algo mal, en realidad se lanzaría un error. Entiendo que el warning se puede referir a que el certificado no está registrado en el sistema o que estoy usando un certificado de firma de software para la generación del xml en mi entorno test y que igual puede que no sea lo que espera el sistema. Cualquier orientación será bien recibida. Muchas gracias ;) |
Cita:
|
Cita:
|
Cita:
También creo que en algun momento nos ha dado por estar utilizando HASH anticuados. Revisa aquí (hacia el final del mensaje), que estés usando los correctos. |
Cita:
Al final era un problema del propio certificado que estaba usando para la firma. He montado uno de la FNMT y el warning ha desaparecido. También se ha solucionado otro problema que tenía en Guipuzcoa (esta vez sí generaba un error y no warning) que no me permitía cargar facturas en su entorno de pruebas. Lo documento aquí por si puede ayudar a alguien ya que era un mensaje bastante marciano: Error 008 - No se pudo seleccionar ninguna política de validación para poder validar - (13517) Vamos, que mejor tener un certificado decente para el entorno de test de la aplicación y no usar cualquier cosa que se tenga a mano :D Llegados a este punto y como ya se ha indicado en el hilo en varias ocasiones, hubiera sido interesante no tener que pegarse con cada una de las administraciones por separado porque es un poco cachondeo que cada vez que encaras a una, hay que volver a revisar todo el desarrollo porque unos verifican unas cosas y otros parece que otras. Ya soltada la llorera :cool: quería ver si alguien me puede orientar un poco porque creo que ésto no recuerdo haberlo visto en el hilo. De momento, puedo subir facturas al entorno de pruebas de Alava y consultarlas con el QR (bueno, en realidad me pone factura en tramitación con lo que entiendo que va todo bien) y también puedo subir a Guipuzcoa peeeero, el QR parece que se me resiste. Y es que me da error para todos ellos, como si no localizara la factura que he subido. En concreto: "No se ha podido determinar el estado de la factura" Por si era un problema del propio QR (cosa que no creo porque me funciona para Alava, pero a saber), me he centrado en el servicio de consultas que se encuentra en https://tbai.egoitza.gipuzkoa.eus/qr...Identificativo para el entorno real y en https://tbai.prep.gipuzkoa.eus/qr/buscarIdentificativo para el test. Si consulto cualquier factura subida, obtengo el error "Identificativo TicketBAI incorrecto o no recibido" Es el mismo que se obtiene si usamos el identificador TBAI de ejemplo (TBAI-44619360G-261020-EzyQEMtxw37Gm-161) del manual técnico de Guipuzcoa (https://egoitza.gipuzkoa.eus/gao-bog...4/c2007008.htm) en el buscador https://tbai.egoitza.gipuzkoa.eus/qr...Identificativo. No sé si tarda algo de tiempo en procesar las subidas y es normal o estoy haciendo algo mal. Ojo que yo las búsquedas las estoy haciendo sobre https://tbai.prep.gipuzkoa.eus/qr/buscarIdentificativo Y un identificador que uso de mis facturas de pruebas es: TBAI-00034567K-050521-t10axqihshiud-253 ¿Alguna idea / consejo de cómo seguir? Muchas gracias :) |
Cita:
Con un TBAI como este: TBAI-B05430756-090622-eSWaZJBwQXg3T-179 Me está generando esta URL: Código PHP:
Con un TBAI como este: TBAI-B05430756-090622-hbb3Fx1O8EYtK-033 Me está generando esta URL: Código PHP:
¿Puedes poner el TBAI y la URL completa que te está generando? |
Líneas de factura con más de un tipo de IVA
Buenos días.
Llevo unos meses tratando de adaptar un programa de gestión para que pueda emitir facturas con los requisitos de TBAI. Estoy siguiendo el modelo de la Agencia Foral de Vizcaya. En mi caso, la factura puede llevar más de un tipo de IVA. Concretamente, cada línea puede llevar un tipo distinto. Por ejemplo, unas pueden ser al 10% de IVA y otras al 21%. Esto es habitual, por ejemplo, en comercios como las farmacias. El tema es que no sé cómo especificar esto en el fichero XML. Más abajo pongo un fragmento del código genérico del fichero XML. Por cada línea de factura, ¿he de crear una instancia del nodo <TipoDesglose>? Código:
<Factura>Si hay que repetir algún otro nodo, ¿cuál sería? Si no, ¿de qué modo puedo especificar los distintos tipos de IVA, así como el importe de cada uno? Gracias de antemano. |
Cita:
Estaba preparando varias facturas para detallar con ejemplos lo que pasaba y en mitad de todo, se me ha encendido la bombilla y tras varios días cabezoneando he dado con el problema. La verdad es que como el soft generaba el id TBAI y era tan sencillo de producir que ni se me había ocurrido compararlo con el que se recibe desde la diputación tras la carga de la factura. El caso es que había una pequeña diferencia que obviamente estropeaba todo el sistema. Era imposible que pudiese funcionar aunque el mensaje de Alava de "factura en tránsito" tampoco ayudaba a darse uno cuenta que en realidad no había tránsito ni nada :D Por cierto, gracias por la url de pruebas de Alava (pruebas-ticketbai.araba.eus/tbai/qrtbai) porque no la he visto referenciada en ningún documento y estaba haciendo los test contra la real y así nunca hubiera funcionado aunque hubiese dado con el problema del identificador. Al final no hay mal que por bien no venga como se suele decir :o |
| La franja horaria es GMT +2. Ahora son las 08:29:52. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
