|
Sincronizacion Hora Fecha
Una cosa que acabo de pensar, si el usuario final fuerza un cambio de hora/fecha en el equipo, por ejemplo para marcar alguna factura que se le habia quedado atras,etc...
LA LIA PARDA Me pongo a buscar pero si alguien tiene un webservice para agregar al programa de sincronizador de hora/fecha, ya que la de windows todos los cuñados saben desactivarla. Esto se hace eterno.:( |
Cita:
Creo que no hay nada que te impida hacerlo así; es decir, tal y como se hace en Gipuzkoa: Generar XML, firmarlo, generar QR y subir la factura. Lo único que cambia es que en vez de subir únciamente el fichero, has de empaquetarlo dentro de otro xml tal y como dices. Pero también se puede subir un bloque de ellos; el plazo para ello depende del tipo de empresa, creo que hasta tres meses... pero no tienes que esperar, con independencia del tipo de empresa puedes ir subiendo uno a uno cada vez que se genere; eso creo, al menos. |
Respuesta de Gipuzkoa
Cita:
Buenas, os envío la respuesta de Gipuzkoa, que es la única que ha contestado de momento. Viene a decir lo mismo que ya me habéis contestado vosotros. Cita:
|
[quote=edari;543543]En Vizcaya,creo por lo que entiendo, tienes que subir no un fichero xml con cada factura si no un fichero "resumen" con las facturas que quieras subir, pasadas a base64 y cada factura "incluida" dentro del campo <TicketBai> de este ejemplo
Buenos días, Por lo que a mí me dieron a entender, en Vizcaya se puede enviar perfectamente un XML por factura o en bloque. En Guipuzcoa y Alava hay que hacerlo obligatoriamente de forma inmediata y una por una. Pero no creo que en Vizcaya haya limitación a enviar en bloques, sino que admite también una por una. Pero ya tengo un follón en la cabeza que no sé de qué va cada cosa, y puedo estar equivocado. :confused: ¿Alguien me puede sacar de dudas? Muchas gracias de antemano. Un saludo |
Pequeña dudilla
Hola señores, buenos días, tengo una duda que probablemente ya haya sido resuelta pero que no he sabido localizar en el foro, así que si me estoy repitiendo pido disculpas.
Veréis, estoy a tiro piedra del lanzamiento y por ello ando verificando que todas las URLs reales sean correctas, mi duda surge con las direcciones QR, concretamente con: Cita:
Cita:
|
Cita:
Buenos días... Por decir algo! Por que tienen que complicarnos tanto? :( Entonces de que sirve el QR?? si no lo van a poder comprobar no funcionará hasta que subas el fichero? y pueden pasar 3 meses como comentais... |
008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada
Hola de nuevo señoras y señores,
lo primero de todo muchas gracias por toda la información subida a este foro, con mención especial a bilbur por todo el tema del firmador en php, que me ha venido genial. Y precisamente al utilizar este firmador me da una serie de fallos a la hora de dar de altas facturas que quisiera corregir. A la hora de enviar las facturas me da el siguiente aviso. 008 El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#xmldsig-ea406c2f-bf64-e988-ed62-0b8afb482297-signedprops" failed to verify. [src/xml2signatureobj.cpp(315)] y comprobando el xml con la herramienta de chillkat, me dice lo siguiente: Signature Verified 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 valid. Reference 3 digest is valid. Qué casualmente coincide con el mismo campo de la respuesta de Gipuzkoa. Supongo que viene dado por el valor de la variable, Código PHP:
Código PHP:
Supongo que tendré que modificar este XMLTools y generar un valor de digest válido, la cosa es que no sé cual. Un saludo y gracias de antemano. |
Cita:
Eso ya se ha hablado por aquí y efectivamente...mientras no subas esos ficheros no se pueden comprobar el QR El chiste se cuenta solo :mad: |
Respuesta de Bizkaia
Cita:
Hola, he recibido la respuesta de Bizkaia, en este caso entiendo que dan la opción de seguir facturando y imprimiendo sin el QR ni identificativo TBAI: Cita:
|
Cita:
He revisado de nuevo de arriba a abajo el foro y he encontrado el error. (Otra cosa es solucionarlo) El error viene en concreto de un campo dentro de la firma Código:
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>Supongo que tendré que encontrar la manera de codificarlo de manera correcta en php, ya que tengo puesto el visual studio code a ISO 8859-1 y ticketbai lo requiere en utf-8. Si corregís esta tílde a la hora de pasarlo a chillkat no os da ningún error y los 3 digest son válidos. Un saludo y espero que sirva a los nuevos que venís con esto. |
Respuesta de Araba
Cita:
Buenas tardes, me han contestado de Araba, la respuesta es muy parecida a la de Gipuzkoa. Cita:
|
Bueno ya tengo mi propia función para leer la hora y fecha actual y actualizar el equipo antes de cada factura de un webservice.
La única cosa que me falta en temas de verificación es un script php para saber la fecha de caducidad del certificado y ya redondeamos. Decidme por favor que sabéis como sacar la fecha. Gracias y saludos |
Buenas.
¿Cómo evitar que al subir un código al foro, sustituya donde pone :D por un smile? Por ejemplo en xades:Digest ? |
Cita:
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName> Chilkat valid en los 3 digest y sin errores al enviar. Es extraño lo que dices, ya somos muchos los que lo usamos y hubiera dado más problemas. Lo único que veo diferente es que entre la "," y "OU" (", OU=CERES") tienes 2 espacios, no creo que sea problema. Tienes el XML con esta cabecera? <?xml version="1.0" encoding="UTF-8"?> |
Cita:
|
Cita:
|
Certificado para firma de código
Buenos días estimados contribuyentes, estoy en proceso de adquirir el certificado de firma de código tanto del ejecutable como para el del instalable (.msi) y tengo cierto lio de cual y donde adquirirlo, podéis compartir vuestra experiencia.
En otro orden de cosas ayer recibí un email de Guipuzkoa con recomendaciones y errores habituales, el la última línea indicaban que pronto publicaran la especificaciones de ZUZENDU :cool::cool: a dos meses vista de la puesta en marcha me parece una tomadura de pelo ....:(:( |
Cita:
https://sectigostore.com/page/cheap-...af6705f30498c5 |
Muchas gracias compañero^\||/^\||/^\||/
|
Cita:
Quizás no me expresé del todo bien. Efectivamente el firmador es una maravilla y funciona correctamente. El caso es que yo tengo puesto mi editor de textos y los datos que obtengo en la base de datos en ISO8859-1 y el envío los requiere siempre en UTF-8. Entonces cuando hay tildes se me transforman a caracteres extraños (Pasa lo mismo si en cualquier campo como el nombre lleva alguna tilde). Y pues cuando lo visualizo y lo paso a chillkat o lo envío para ticketbai Gipuzkoa , los errores de la firma venían derivados de esos caracteres extraños por la codificación derivadas de las tildes. Resumiendo, problemas de derivados de codifcación. Lo único me ha surgido una duda nueva a ver si alguien me la puede responder. ¿La variable digest dentro del nuevo array POLITICA_FIRMA_ALAVA como lo puedo calcular? Un saludo y mil gracias de nuevo de verdad, sin este foro no podría estar tirando este proyecto hacia delante. |
Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente (no es por ser un sobrao, pero genero las url de los QR de las otras diputaciones de la misma manera, y no tengo problemas), pero por si acaso, ¿habéis probado vosotros si os funciona bien? |
Cita:
Mismo caso que tú v\||/ |
Cita:
|
Cita:
El problema está en pedir que la etiqueta <ImporteTotal> venga con el impuesto incluido y luego seguramente validan que la suma de los "importes totales" sea igual al importe de la factura, y eso es un error (creo que por parte de ellos, Álava en este caso, porque la misma factura con los mismos importes Guipúzcoa la da por válida). No se puede sacar el IVA por cada línea de la factura, porque el IVA se debe calcular sobre el importe final de la factura, y no línea a línea, porque por los redondeos va a descuadrar si o si en muchos casos. ¿Qué hacemos? ¿Metemos una línea de detalle con el posible descuadre del centimillo? |
Cita:
Teniendoo en cuenta que no sé php y he probado con este comando $certIssuer = str_replace("ó", "o", $certIssuer); pero no entiendo por que no funciona, mientras alguien diga por que no va y si siempre vas a firmar con ese tipo de certificados puedes forzar y cambiar esto en el firmador.php: $certIssuer = implode(', ', array_reverse($certIssuer)); por: $certIssuer='CN=AC Representacion, OU=CERES, O=FNMT-RCM, C=ES'; |
Cita:
a mi tampoco me va, mismo error |
Cita:
Yo también probé eso ayer, pero tiene que llevar tilde para que al enviar el XML a Gipuzkoa te lo reconozca de la FNMT. Si quieres que el primero te vaya tendrás que hacer un utf8_decode ó un utf8_encode, dependiendo de en que codificación te encuentres. Pero que de verdad, está ya solucionado con lo que escribí esta mañana no te preocupes. Era el tema de la codificación de mis datos, que no estaban en UTF8. |
Consultado en Araba hace dos semanas
Cita:
Yo lo consulté y esto me respondieon : Buenos días Jordi Hemos revisado el contenido de su fichero y los importes son correctos. El error se está dando en las líneas en las que el importe es menor de 1 euro. Al trabajar con importes pequeños y despreciar los decimales se ha provocado esta situación. Vamos a solucionarlo en breve. Cuando lo hayamos solucionado se lo comunicaremos. Gracias por su colaboración Un saludo |
Estoy mirando el resto de ficheros del LROE y se me caen los pantalones abajo :confused:
modelo 240. altas Facturas recibidas altas Intracomunitarias altas Cobros altas Pagos altas Importes superiores a 6000 euros (y creo que no me afectan más) Entiendo que estos ficheros no hay que hacer transformarlos en base64 si no que se generan directamente, se comprimen y se suben (en mi caso con el curl) desde ya la gestión contable de nuestros programas. En el zip de ejemplos que tiene Batuz no veo ejemplos de estos. Están en algún otro sitio? Gracias |
Cita:
|
Pregunta tonta sobre el encadenamiento en Bizkaia
Hola a todos/as...
Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba. Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas? Lo explico mejor... En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo? Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas"). Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así. Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no? Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc. ¿Cómo lo hacéis vosotros? |
Cita:
|
Cita:
|
Cita:
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"? Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una". |
Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo
https://pruebas-ticketbai.araba.eus/...2537.70&cr=017 Yo no consigo que me de 017. No se sobre que lo estan aplicando. |
Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.
Cita:
|
Buenas tardes;
A la hora de dar de alta en Alava, desde hace unos días, a la URL: https://pruebas-ticketbai.araba.eus/...I/v1/facturas/ .... me devuelve siempre como "Rechazado", con el error: "El servicio de recepcion no esta disponible. Repita la operacion mas tarde" ¿Os ocurre a todos lo mismo con Alava? ¿Están caídos los servidores? ¿Se conoce alguna fecha donde se restaurarán? Muchas gracias de antemano. Un saludo. |
Cita:
|
Cita:
La url de pruebas para los códigos QR en Álava es esta, según la guía de pruebas: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/ Pero también falla. |
C# .Net envio TBAI desde un servicio => certificados
Buenas tardes, nuestra aplicación está desarrollada en c# .Net y para el envío a las diputaciones forales utilizamos System.Net.HttpWebRequest
Nuestra idea es que las facturas se vayan enviando desde un servicio desatendido, que esté funcionando en el servidor. Ya lo tenemos implementado y dentro del entorno de desarrollo funciona correctamente. El problema lo tenemos cuando lo ejecutamos como servicio, que arranca con el usuario del sistema local (System). En ese caso las diputaciones nos contestan con una excepción (cada una con un mensaje distinto) pero que indica que no ha encontrado el certificado de cliente para el envío. Hemos visto que HttpWebRequest para envar a TicketBAI debe tener el certificado en el almacén de certificados del usuario (instalado en el navegador) y además debemos indicar que certificado del almacén se utilizará para el envio añadiendolo en la propiedad ClientCertificates del HttpWebRequest. Por ejemplo: Código:
var httpWebRequest = HttpWebRequest.CreateHttp(url);Alguien que trabaje con .Net y utilice un servicio de windows para el envío nos puede echar un cable por favor?:confused: Muchas gracias!! |
| La franja horaria es GMT +2. Ahora son las 12:14:48. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi