![]() |
Con este Master que estamos haciendo nos va a salir mejor currar de asesor de ticketbai
|
Sigo con el error 400 y no se por donde tirar.
Estoy revisando el Json, y aunque veo algunas diferencias con el que te ponen de ejemplo, probando el suyo de ejemplo tal cual, todo seguido sin "" me da el mismo error. Nose si será eso o que, os pongo mi Json a ver si veis algo raro.
|
Cita:
Yo para comprobar si una estructura JSON está correcta, utilizo Insomnia (al igual que para hacer pruebas de envío). Al pasar tu JSON por Insomnia (quitando la " inicial y la " final) veo que da error. Parece que no le gusta lo de repetir " dos veces en cada sitio donde debería haber una sola " Mira a ver si es eso. Saludos |
Cita:
Para neftali. si accedes asi ¿como le dices luego al componente de firma cual es el certificado? yo lo hago asi.
Solo me queda probar el programa que indica juramisa, aunque el autofirmacommanline funciona bien y probar como solo lectura como dice HerensugeBeltz. Esto lo haré a lo largo de la mañana cuando pueda conectarme con el cliente. Esta claro que es un problema de su ordenador ya que el programa esta corriendo en mas de 100 usuarios y esta funcionando correctamente. Pasar un buen día TicketBAI. :cool: |
Cita:
Gracias por probarlo, yo lo que veo no es que lo repita, es que para cada parte le pone las " " Realmente ese es el contenido de la variable que mando. Pero no entiendo por que no sirve, por que lo tengo funcionando así en varios sitios y funciona. Voy a ver que me invento para cambiarlo. |
Cita:
Nosotros guardamos el HASH del certificado. Con ese procedimiento cargas los certificados disponibles usando la clase TElWinCertStorage. Aquí hay un ejemplo de cómo acceder a esa clase. Está en VB, pero verás que es muy parecido al código que he puesto yo. Desde esa clase puedes acceder a los certificados y obtener elementos de la clase TElX509Certificate. |
nuevo entorno de pruebas Batuz
Buenas tardes, a ver si lo he entendido bien, para utilizar el entorno de pruebas de batuz que se puso en marcha recientemente, a parte ser necesaria una inscripción previa de la empresa desarrolladora, también debemos utilizar los certificados de pruebas y especificar unos datos del obligado tributario ficticios que nos proporcionará batuz.
Por lo tanto no podemos poner nuestro programa a un cliente final nuestro y dejarlo en entorno de pruebas batuz para que envie con su certificado y sus datos de obligado tributario, para ir probando antes de pasar al entorno real a partir del 1 de enero del 2022 (período voluntario) pues si es así pierde toda la gracia ese entorno de pruebas... Es así o me equivoco? Muchas gracias |
Como haceis para coger la respuesta de Bizkaia desde delphi?
La respuesta me da esto y no se como guardarlo en un archivo, ya que siempre me esta diciendo que es un archivo erroneo. He probado con estas opciones
|
Cita:
▪ Licencia TBAI: TBAIBI00000000PRUEBA ▪ NIF entidad desarrolladora: A99800005 ▪ Nombre: SOFTWARE GARANTE TICKETBAI PRUEBA ▪ Versión: 1.0 O sea, te dan estos datos, te dan los certificados que puedes usar y tras la inscripción te indicarán los datos de clientes con los que hacer las pruebas. Todo predefinido ¿No? Si estos datos de clientes se hacen públicos ¿Para qué es necesaria la inscripción? |
La WSDL es https://sarrerak.bizkaia.eus/N3B4000M/aurkezpena, ya no es https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena
Cita:
|
Cita:
Se que han tenido problemas con envíos de prueba a PRODUCCION, imagino que de esta manera pueden filtrar esos errores, aunque hubiera bastado con la Licencia (un único datos), no hacía falta cambiarlos todos y solicitar un segundo registro. Como en muchas otras cosas, me da la impresión de que sólo están pensando en su beneficio y no están pensando en las empresas desarrolladoras. Cita:
Como ya dijeron en su día, el entorno de PREPRODUCCION lo tienen pensado sólo para utilizar en las empresas desarrolladoras. No debería haber ningun cliente real en PRE (al menos es lo que pretenden). |
Cita:
Funcionan las 2. Desde hace unos días ya está de nuevo en marcha el servidor de PREPRODUCCION: https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena NOTA: Para poder utilizarlo hay que hacer esto. Y el de PRODUCCION (que por ahora es "a modo de pruebas") es este: https://sarrerak.bizkaia.eus/N3B4000M/aurkezpena NOTA: Este se cerrará el 10 de Diciembre :(:(:o un lío vamos... |
Cita:
Al final hablando con SecureBlackBox me han dado la siguiente solución. Cita:
Ahora el problema lo tengo a la hora de firmar el fichero con sbxXAdESSigner1.Sign(); que despues de cargarle todos los parametros me sale el siguiente error. Cita:
Un Saludo. |
nuevo entorno de pruebas Batuz
Gracias por las respuestas unomasmas y Neftali
|
Cita:
Ten en cuenta que la respuesta en el caso de Bizkaiano puedes tratarla como texto para recuperarla o guardarla en disco. He visto que usas TStringStream o TStringList. Inténtalo con TStream, porque al utilizar etructuras para strings se producen conversiones no deseadas. Crea un TFileStream y utiliza el Post recogiendo la respuesta en ese objeto, para guardarlo en disco. ![]() |
Cita:
No se si es lo mismo (no creo, pero por si acaso), pero si son certificados que están instalados en la máquina (no como usuario local), hay problemas al acceder a ellos. Necesitas elevación de permisos. |
Sigo con el error y ellos sin contestar, creo que no soy el único que está con el error 400.
Subo las cabeceras por si veis algo raro, no se por donde tirar la verdad. He visto que el Json esta bien formado, lo armo con una funcion de .Net que lo hace solo.
|
Modifico los parámetros que has enviado para iguarlarlos con los mios:
Código PHP:
¿No lo estarás enviando todo como un único JSON? |
Cita:
No, lo que pasa que lo he cogido desde el debug y sale así, pero eso esta bien. Lo que veo distinto es el orden y lo de Accept... voy a ver si me tomo un cafe y sigo probando! :( |
Cita:
Muchas gracias, ya lo he conseguido guardar con esto
|
Cita:
Si pongo la cabacera Accept me da error: El encabezado 'Accept' se debe modificar con la propiedad o metodo adecuados. |
Nosotros los añadimos así:
Y es resultado es este:
|
Validación de la licencia del software garante
Os informamos que a partir del 30 de noviembre se va a habilitar la validación de la licencia en el Entorno real en modo de pruebas (el cual estará disponible hasta el 10 de diciembre de 2021) con el objetivo de que se pueda verificar el correcto funcionamiento de los sistemas de cara a la apertura del Entorno real a partir del 1 de enero de 2022.
Es imprescindible, que de cara al 1 de enero de 2022, tengáis verificados los datos de la licencia a utilizar. Si los datos de la licencia no son correctos, provocará el rechazo de las anotaciones, tanto del alta como de la anulación, del subcapítulo 1.1 del LROE. Cuando hablamos de los datos de la licencia, nos referimos a los datos del Software de facturación incluido en la Huella TicketBAI: Todos los campos deben coincidir EXACTAMENTE con los datos proporcionados en el alta realizada en el Registro de Software Garante. Para identificar el Nombre del software con el que fue dado de alta, basta con revisar el documento de notificación enviado, donde aparece junto con la Licencia TicketBAI otorgada y el NIF de la empresa desarrolladora: |
Buenas, me estoy volviendo loco para añadir todas las líneas de detalle con la librería Chilkat, ya que en Guipuzcoa hay que detallar la factura.
Si utilizo el método UpdatechildContent siempre se me actualiza el mismo IDDetalleFactura ¿Cómo puedo crear diferentes elementos de IDDetalleFactura? He probado con NewChild y NewChild2, pero no cierra el elemento anterior ¿Qué método utilizáis? |
Cita:
Según me han contestado, el problema lo tengo en los [] en el Json. Voy a ver si puedo quitarlos y lo pruebo. Una duda que tengo, cuando subo una anulación, esta no lleva consecutivo, entonces la siguiente factura que subes, tiene que hacer referencia a alguna factura? a la anterior de la anulación? |
Cita:
Ejecutando como administrador pasa lo mismo. Haciendo pruebas tontas he visto que si lo ejecuto desde un programa de pruebas (.exe) funciona correctamente, pero desde una dll que es donde lo tenemos todo metido no. He copiado todo a una carpeta nueva y FUNCIONA, es decir copio y pego toda la carpeta del programa y funciona bien desde una dll. Magia:cool: |
Cita:
|
Cita:
Además no las puedo registrar por que no son registrables. Al final me vale con moverle el programa a otra carpeta. |
Cita:
Mi opinión: La referencia de una nueva factura debe ser a la factura anterior, esté o no anulada. La anulación sólo es un estado fiscal para que Hacienda no considere sus importes a efectos IVA, IRPF, IS, etc. Pero una factura anulada es una factura válida para TicketBAI con su serie, número, fecha y firma como las demás. Aparte de que una factura puede anularse en cualquier momento, aunque haya otras posteriores. Se admiten opiniones alternativas. Saludos |
Cita:
|
Bueno mi error 400 era debido a los '[' ']' del Json... los he quitado y ya no da el error 400.
También puede dar error 400 por el certificado / CIF utilizado, lo digo por si alguien tiene este error 400 sepa por donde pueden ir los tiros. |
Cita:
|
Importante: sobre rectificativas en cambios y devoluciones TPV
Sigo pensando que un cambio o devolución en un punto de venta no debería requerir una rectificativa, sino una simple factura ordinaria (en negativo o positivo según sea cambio, devolución, etc.).
Y para intentar aclararlo al 100%, le he enviado a las tres haciendas forales varios supuestos que creo que no han tenido en cuenta, pero que se dan a diario en miles de comercios minoristas. Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias. Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo: * Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa * Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa ¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa? (No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo). Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso. Publicaré las respuesta que me den las tres haciendas forales (suerte con esto también). Un saludo |
Cita:
|
Cita:
Yo también espero ansioso la respuesta que te den porque es un tema que me interesa (y también a mis clientes) muchísimo. Gracias. Saludos |
Cita:
Si quieres esperar a la escrita te va a tardar varios meses, eso me dijeron en una consulta a la Aeat. |
Cita:
Kaixo, En primer lugar, disculpas por el retraso en contestar. En cuanto a las cuestiones planteadas, responder que Batuz y TicketBai no modifican ni la normativa de IVA ni el reglamento de facturación. Por tanto, los casos en que se puede emitir una factura rectificativa son los mismos que hasta ahora, y serían casos diferentes en los que se permite la anulación de una operación. Recomendamos ver las preguntas frecuentes 19, 20 y 54 en la web https://www.batuz.eus/es/preguntas-frecuentes Sobre la forma de emitir una factura rectificativa, se dan dos opciones: por diferencias o por sustitución. Recomendamos ver las preguntas frecuentes 45 y 47 a 54. También quisiéremos explicar el proceso de funcionamiento de TicketBai y de Batuz, para aclarar que la emisión de una factura, rectificativa o no, no está vinculado a la remisión y a la aceptación o no del envío por Hacienda (no está vinculado a que esté subida y aceptada). ... bla, bla, bla... no pongo más por no aburrir a la audiencia... Conclusión (en mi modesta opinión): Dado que el reglamento de facturación español es del año 2012, y si hasta ahora se hacían abonos (facturas en negativo) para hacer una devolución y Hacienda no se ha metido para nada con usted, siga haciéndolo. Saludos, |
Cita:
Antes de ticketbai, para comprobarlo tenían que levantar inspección, ahora lo tienen a huevo, primero comprueban y a raíz de los datos mandan la inspección, van a tener muy fácil automatizar las inspecciones, me imagino por la mañana un correo automatizado(o una aplicación portable en L que les informe de las inspecciones del día y la ruta a seguir) a los inspectores de zonas por el boot de ticketbai que repasa los datos que no están según normativa. Fácil de hacer y muchos ingresos a las arcas. |
Error en consulta QR
Alguien sabe la diferencia en la url del QR en araba?
Al consultar un QR de facturas admitida devuelve siempre el error "Parámetros incorrectos" Si embargo, este mismo código efectúa la consulta a Gipuzkoa sin problemas La generación del CRC se hace con toda la url previa al parámetro "cr". La url se deja sin la / final, tal y como indica la especificación Tampoco existen caracteres a codificar en ninguno de los ejemplos probados Por ejemplo, los parámetros de una url que da error en el entrono de pruebas de Araba es: id=TBAI-A78648144-210121-qcSwKs6XuYTTq-062&s=01&nf=7684&i=63.26&cr=195 |
Cita:
Prueba con el mismo código de Guipuzkoa y sin quitar la / a la URL. Yo estoy usando esto y funciona sin problemas: Código:
TicketBAIID:TBAI-B05430756-291121-oBvVV+V6VnNb1-158 |
| La franja horaria es GMT +2. Ahora son las 17:02:17. |
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