![]() |
Gracias Sistel pero en la propia pagina de Izenpe en el apartado de Certificados TicketBAI, te pone que los certificados para persona física son: "tarjeta física de Izenpe o Bakq (en la nube)".
Y luego si vas al apartado Tarjeta Virtual en el apartado ciudadania, explica que: "Tarjeta virtual es un ligero software que se instala en su ordenador con el que podrá identificarse en cualquier sede electrónica u oficina virtual que permita el uso de certificados digitales. De este modo tarjeta virtual funciona igual que cualquier otro certificado permitiendo el uso de certificados en la nube en cualquier trámite y servicio." El usuario llamo para preguntar y le respondieron que era problema del programa , que debía admitirlo. Así que para mi desgracia me parece que es valido y tengo que lidiar con el. Aún así también les he enviado yo la consulta y estoy esperando respuesta, pero doy por hecho que es valido. |
Cita:
Me he limitado a poner la información de los tipos de certificados admitidos por TicketBAI (según su normativa) Desconocía que Bakq tuviese consideración de certificado digital a efectos de TicketBAI. Pero si Izenpe te dice que sí ... pues así será. Saludos |
Facturas Rectificativas
Buenos días a tod@s;
Tengo una duda respecto a las Facturas Rectificativas, a ver si me podéis ayudar. Supongamos que tenemos una Factura con serie "A", que queremos rectificar. Ahora mismo, lo que hacemos, es realizar un Abono de la factura de la serie A, pero con signo negativo (-A) Y por último, generamos una factura definitiva, con los datos que debería de haber tenido la factura inicial (Serie R) Es decir: A ====> -A =====> R A la hora del envío a Batuz, y cumplimentar el bloque de datos de Rectificativa (FacturaRectificativaType) , ¿dónde se tienen que cumplimentar dichos datos, ¿En la factura con serie "-A"? ¿O en la factura de la serie "R"? ¿O en ambas, haciendo referencia a la original? Porque a priori, la factura "-A", que también habría que remitir a Batuz, está rectificando lo que había en la de la serie A, pero en definitiva la factura de la serie R, es la factura que rectifica la original. ¿Podéis indicarme cómo lo estáis haciendo? Muchas gracias. Un saludo |
Cita:
Hay dos formas de registrar una factura rectificativa por sustitución. Una forma es informando de los datos a rectificar y los datos rectificados (sin emitir ninguna factura negativa) La otra forma es emitiendo una factura negativa (de la misma serie) y a continuación una rectificativa sin datos a rectificar, sólo con datos rectificados. Lo tienes explicado en la pregunta 48 de https://www.batuz.eus/es/preguntas-f...egunta_7398227 Saludos |
Cita:
|
Cita:
Sólamente tendría que poner los datos de la rectificativa en la nueva que se genere, en signo positivo. La que tiene signo negativo, no se considera rectificativa y es una factura normal, sin datos de referencia a la factura original. |
Cita:
Saludos. |
Curl
Cita:
|
De vuelta por aquí tras un impas :cool:
Me estoy empezando a meter con el tema del Zuzendu (Alava) y tengo algunas dudas Sabéis si hay por algún sitio ejemplo de los xml (subsansar, modificar y anulación)? Lo de tirar del XSD para "sacar" el fichero nunca se me dió bien... Los ficheros Zuzendu de Alava y Guipúzcoa son iguales? Tiene pinta de que sí pero quiero estar seguro Cuando tenga preparar los ficheros para subirlos sería con un "curl" más o menos configurado como lo hacemos para subir las facturas? ¿Qué diferencia hay entre el fichero anular una factura desde el Zuzendu de anulación (-<T:SubsanacionAnulacionTicketBAI xmlns:T="urn:ticketbai:zuzendu-baja">) y anularla desde el xml de anulación que ofrecía el propio Ticket bai (<T:AnulaTicketBai xmlns:T="urn:ticketbai:anulacion">)? Gracias de nuevo |
Cita:
(Es lo que me dice la lógica, si no es así comentadlo) |
Cita:
Mersi de primeras |
Errores Envios
Hola buenas tardes.
Estoy desarrollando el módulo ticketbai para usarlo en varias aplicaciones, conseguí hacerlo funcionar el sábado, y desde ayer ya no funciona con los archivos firmados desde autofirma, y ya no entiendo por donde viene los tiros, este es el mensaje que les he mandado a batuz y sus respuestas. --------------------------------------------------- Hola buenas. Hace unos días atrás las respuestas fueron correctas, pero ahora aparece errores de políticas de firmas, adjunto más abajo el mensaje de respuesta tanto de cabecera como xml: CABECERA HTTP: Código:
HTTP/1.1 200 OKCódigo:
<?xml version="1.0" encoding="UTF-8" standalone="true"?>------------------------------------------- Kaixo, Cuando se devuelve el error "Todos los registros incluidos en la petición son incorrectos", significa que el fichero enviado se ha podido procesar y todos los registros incluidos en el mismo son incorrectos. Para poder saber el estado concreto de cada uno de las anotaciones enviadas, el sistema devuelve un fichero de respuesta. En ese fichero se indica, por cada anotación enviada, su estado (correcto, aceptado con errores o incorrecto), y, en caso de no ser correcto, se devuelve el código y descripción del error que se ha producido para dicha anotación. Os recordamos que la aplicación cliente debe recuperar la respuesta proporcionada por el servicio, es decir, el fichero de respuesta y realizar un tratamiento de la misma, incluyendo la gestión de los errores. El detalle sobre cómo recoger el fichero de respuesta está disponible en el capítulo "6.2.2 Cuerpo de la respuesta" del documento "Especificaciones del envío masivo del LROE" que encontrareis en el apartado "Documentación técnica" de la web de Batuz Hemos revisado la petición que nos habéis indicado. El error que está devolviendo en el fichero de respuesta es: "La firma no cumple los requisitos de la política de firma TicketBAI.(EPES: N ALGORITMO: rsa-sha512:2048 POLITICA: N CERTIFICADO_ADMITIDO: S )" El error que os está devolviendo indica que la firma no es de tipo Xades-EPES y que la política de firma no ha sido correctamente definida. Toda la información relativa a la validación de la firma está disponible la web de Batuz, concretamente en el "Capítulo 3. Validación de la firma electrónica" del documento "Especificaciones funcionales y técnicas del sistema TicketBAI" ubicado en el apartado "Documentación técnica". Agur bat, ----------------------------------------- Hola buenas. Los archivos se firman con el Autofirma 1.7.2 con la siguiente sintaxis de líneas de comandos: Código:
autofirmaCommandLine sign -format xades -xml -i C:\TicketBAI\Facturas\Ventas\Factura_Venta_FA_000001.XML -o C:\TicketBAI\Facturas\Ventas\Factura_Venta_FA_000001.XSIG -store pkcs12:"CERTIFICADO.p12" -password "111111" -filter "ALATZ APARICIO DIAZ" -config "format=XAdES Enveloped\npolicyIdentifier=\npolicyIdent ifierHash=Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=\npolicyIdentifierHashAlgorithm=\npolicyQualifier="Código:
<?xml version="1.0" encoding="UTF-8"?><T:TicketBai xmlns:T="urn:ticketbai:emision">Saludos. Hasta aquí el intercambio de correos, por lo visto estos es un cachondeo :mad::mad::mad: |
Certificado de dispositivo en servidor compartido
Hola,
en primer lugar muchas gracias a este foro por la información que se ha publicado en él. Gracias, gracias, gracias. En segundo lugar, una duda sobre el certificado de dispositivo. Tengo desarrollada una aplicación de facturación en PHP. Está alojada en un servidor compartido (en GoDaddy). A la hora de pedir el certificado de dispositivo, no puedo acceder a ningún número de serie del servidor. ¿A alguien le ha sucedido algo parecido? ¿Cómo lo habéis resuelto? Muchas gracias. Un saludo. Nessie. |
Cita:
En todo caso tiene pinta de permisos. Cuando haces un php que te funciona en un lado y en otro no, suele ser eso. |
Código:
autofirmaCommandLine sign -format xades -xml -i C:\TicketBAI\Facturas\Ventas\Factura_Venta_FA_000001.XML -o C:\TicketBAI\Facturas\Ventas\Factura_Venta_FA_000001.XSIG -store pkcs12:"CERTIFICADO.p12" -password "111111" -filter "ALATZ APARICIO DIAZ" -config "format=XAdES Enveloped\npolicyIdentifier=\npolicyIdent ifierHash=Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=\npolicyIdentifierHashAlgorithm=\npolicyQualifier="* En filter es mas seguro poner -filter subject.contains: CIF/NIF/NIE * Para la ubicacion del certificado te aconsejo el path completo * No se si es necesario pero yo pongo otros datos que no has puesto: ejemplo \npolicyIdentifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf etc Prueba así: Cita:
|
Cita:
Ojo porque me parece que lo que estás empleando es lo que TicketBAI llama "Arquitecturas con firma en servidor". Y, en esos casos, no es válido emplear certificado de dispositivo. Saludos |
Cita:
Hola Ermendalenda. Gracias por la respuesta. No me extraña que no entendieras bien la pregunta: estaba muy mal redactada. La reformulo aquí: El sistema de facturación que desarrollo es una aplicación web desarrollada en PHP. Desde el ordenador cliente se genera la factura. Esa factura se envía al servidor. En el servidor se firma, se genera el XML, se guarda y se envía a hacienda. Por lo tanto, entiendo que el certificado para realizar la firma ha de estar físicamente en el servidor. Quiero usar un certificado de dispositivo. Voy a la web Izenpe para obtener un certificado de dispositivo. En Izenpe me piden el fabricante y el número de serie del dispositivo desde donde se van a emitir/firmar las facturas. Al estar la aplicación alojada en un servidor compartido (un hosting en GoDaddy), no puedo acceder a esa información. Leo en el Anexo III (p.7) de la documentación de Diputación de Gipuzkoa: 4.2.2 Arquitecturas con firma en servidor Se podrá firmar con: certificado de persona física, certificado de representante de entidad, sello de empresa, certificado de autónomo-autónoma o certificado de dispositivo. ¿Hay alguien en la misma tesitura? ¿Alguien está usando un certificado de dispositivo en un servidor compartirdo? Muchas gracias. Buen día. Nessie. |
Cita:
Hola, Sistel, gracias por la respuesta. Leo en el Anexo III (p.7) de la documentación de Diputación de Gipuzkoa: 4.2.2 Arquitecturas con firma en servidor [...] Se podrá firmar con: certificado de persona física, certificado de representante de entidad, sello de empresa, certificado de autónomo-autónoma o certificado de dispositivo. Gracias. Un saludo. Nessie. |
Hola a todos.
Tengo una duda sobre los suplidos. En teoria en hacienda dicen que no es objeto de TBAI, es decir no hay que enviarlos. ¿Que estáis haciendo vosotros?, los estáis enviando como operaciones no sujetas o no los estáis enviando. |
Cita:
*Pide el certificado de dispositivo del equipo que hace la llamada. *Aloja un php en el servidor mandale el xml y el certificado de dispostivo de cada equipo local(que puede estar alojado en una carpeta en vez de enviarlo en cada llamada), al enviar la llamada tienes que especificar con que certificado firrmar. Des esta forrma estas usando un servicio externo pero en realidad estas firmando con tu dispositivo. Por otro lado si quieres asegurarte un pelín más: *La llamada al php que te devuelva el xml firmado y desde el equipo local haces el envio y guarda en el que quieras, mientras puedas dar acceso.. Saludos |
| La franja horaria es GMT +2. Ahora son las 22:31:02. |
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