TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[Sanduzelai]

Empezado por Irreo

Hombre, si es un software para clientes, y quieres dejarlo lo más pulido posible por evitar preguntas una y otra vez, no envíes el bloque de encadenamiento.

En la primera factura yo envié el bloque "HuellaTBAI" sin encadenamiento, solamente el bloque "Software", y no me ha dado ningún aviso.

Básicamente lo que hago es, si el dispositivo ha emitido una factura anteriormente, la pongo, si no, nada.

Si, es lo que he hecho. Mando este bloque con los datos correctos pero aun así me ha dado ese aviso:

Código PHP:

<HuellaTBAI>
    <Software>
      <LicenciaTBAI>xxx</LicenciaTBAI>
      <EntidadDesarrolladora>
        <NIF>xxx</NIF>
      </EntidadDesarrolladora>
      <Nombre>xxx</Nombre>
      <Version>xxx</Version>
    </Software>
  </HuellaTBAI> 


[Irreo]

Empezado por Sanduzelai

Si, es lo que he hecho. Mando este bloque con los datos correctos pero aun así me ha dado ese aviso

Ah, pues igual es cosa de esa delegación... yo he trabajado solo con Gipuzkoa, y por el momento no me ha salido nada.

Será que son más tikismikis

[espinete]

Buenas.

Siento hablar de PHP aquí, pero estoy partiendo del código de Bilbur para firmar y enviar en PHP y estoy atascado con los certificados.

Con tanto tipo de certificado (.pem, .pfx, .cer, .crt...), privatekey, publickey, etc. ya me estoy volviendo loco.

- Para firmar el XML uso el código de Bilbur, que necesita un archivo .PFX o .P12 y la contraseña.
- Pero para el envío (CURL) se necesitan archivos .PEM, o al menos yo no he conseguido enviar con el .PFX o .P12

Ahora mismo puedo firmar y enviar con PHP, salvo por esta peculiaridad. Además, no veo viable tener que almacenar las contraseñas de los certificados.

Sé que es posible convertir desde .PFX/.P12 a .PEM, y generar lo que haga falta, pero eso exigiría que el usuario suba el archivo en formato .PFX para yo poder hacer el resto y generar los .PEM en el servidor.
Pero creo que el .PFX es exclusivo de Windows, por lo que los usuarios con Mac o Linux solo tendrán .CER o .PEM, y con estos no puedo firmar.

Actualmente lo que hago es precisamente eso: permito al usuario subir su certificado en .PFX o .P12 y genero los .PEM y .CER necesarios, pero sigo necesitando el .P12/.PFX y la contraseña para firmar.

¿Alguien ha conseguido firmar el XML solo con .PEM?

[Irreo]

Empezado por espinete

Buenas.

Siento hablar de PHP aquí, pero estoy partiendo del código de Bilbur para firmar y enviar en PHP y estoy atascado con los certificados.

Con tanto tipo de certificado (.pem, .pfx, .cer, .crt...), privatekey, publickey, etc. ya me estoy volviendo loco.

- Para firmar el XML uso el código de Bilbur, que necesita un archivo .PFX o .P12 y la contraseña.
- Pero para el envío (CURL) se necesitan archivos .PEM, o al menos yo no he conseguido enviar con el .PFX o .P12

Ahora mismo puedo firmar y enviar con PHP, salvo por esta peculiaridad. Además, no veo viable tener que almacenar las contraseñas de los certificados.

Sé que es posible convertir desde .PFX/.P12 a .PEM, y generar lo que haga falta, pero eso exigiría que el usuario suba el archivo en formato .PFX para yo poder hacer el resto y generar los .PEM en el servidor.
Pero creo que el .PFX es exclusivo de Windows, por lo que los usuarios con Mac o Linux solo tendrán .CER o .PEM, y con estos no puedo firmar.

Actualmente lo que hago es precisamente eso: permito al usuario subir su certificado en .PFX o .P12 y genero los .PEM y .CER necesarios, pero sigo necesitando el .P12/.PFX y la contraseña para firmar.

¿Alguien ha conseguido firmar el XML solo con .PEM?

Buenas,

Por lo que comentas, me da la sensación de que tienes alguna plataforma donde la gente se suscribe, y las facturas salen desde vuestra plataforma.

Si es así, ¿por qué no utilizas un certificado único de dispositivo?

[espinete]

Pues la verdad es que no lo había considerado.

Me centré en hacer lo que ya tenía hecho en Delphi para pasarlo a PHP tal cual, y me había olvidado completamente de esa posibilidad.

O sea... que puedo firmar todo (XML y envío) con un solo "certificado de dispositivo"?

Tengo que investigar más sobre esto, porque hasta ahora no me lo había ni planteado y no sé si a estas alturas va a ser más complicado o más fácil cambiar.

[Irreo]

Empezado por espinete

Pues la verdad es que no lo había considerado.

Me centré en hacer lo que ya tenía hecho en Delphi para pasarlo a PHP tal cual, y me había olvidado completamente de esa posibilidad.

O sea... que puedo firmar todo (XML y envío) con un solo "certificado de dispositivo"?

Tengo que investigar más sobre esto, porque hasta ahora no me lo había ni planteado y no sé si a estas alturas va a ser más complicado o más fácil cambiar.

Puedes emitir desde un dispositivo para varios CIF. Lo único, después de la primera emisión, la empresa en cuestión tiene que ir a su Sede Electrónica, al área de "registro de dispositivos", y aceptarlo como válido (esto quizás es así siempre, pero lo comento por si acaso).

Te cito del FAQ de Izenpe:
¿Puedo usar un mismo dispositivo para facturar distintas empresas? ¿en ese caso debo tener certificados distintos?
Si, puedes tener un dispositivo que facture para varias entidades diferentes. Se deberá vincular dicho dispositivo y su certificado con cada uno de los obligados tributarios en la Hacienda Foral correspondiente.

( https://www.izenpe.eus/faqs/pregunta...cnempresas/es/ )

Nosotros tenemos un software desarrollado para uso propio, pero emite para tres CIF diferentes (nuestros).

Todo lo hacemos con el mismo certificado de dispositivo de Izenpe (gratuito, 10 años).

- Firma: Usando el firmador que mencionas, con el fichero P12/PFX.
- Conexión con Hacienda para enviar: El mismo certificado, convertido a PEM por mí mismo en el propio servidor.

Para la firma no tiene misterio, es meter los valores de certificado y contraseña.

Para el envío, por si te sirve, hago un "file_get_contents" con un Context, donde cargo el certificado:

Código PHP:

                     $opts = array(
                            "ssl" => array(
                                "local_cert" => $appConfig["certificate"],
                                "passphrase" => $appConfig["certificate_password"],
                                "allow_self_signed"    => true,
                                "cafile" => $appConfig["certificate"],
                                "capath" => $appConfig["base_path"],
                                "verify_peer" => false
                            ),
                            "http" => array (
                                "method" => "POST",
                                "ignore_errors" => true,
                                "timeout" => 9, // Por ahora 9 segundos porque el proceso se ejecuta cada 10 segundos
                                "header" =>
                                "Accept-language: es\r\n".
                                "Content-type: application/xml;charset=UTF-8\r\n",
                                "content" => $xmlSent
                            )
                        );

                        $context = stream_context_create($opts);

                        $haciendaResult = file_get_contents($apiService, false, $context); 


Saludos.

[unomasmas]

Este es un asunto más bien fiscal... Esta es la situación:

1.- Envío factura a Gipuzkoa (Serie A. Nº 22. Fecha 8/11/2022).
2.- Hago rectificativa de esa factura (Serie A. Nº 22. Fecha 8/11/2022). Misma serie, mismo número, misma fecha.
3.- Genero código QR, la imprimo pero al enviarla la Diputación no la acepta. dice que "005: El fichero ya se ha recibido anteriormente."

Obviamente hay un error en la serie y número, pero la factura ya está emitida, así que ¿Qué solución hay? ¿Anularla y generar la rectificativa como debiera ser, con su serie independiente y el número que corresponda? No hay otra opción ¿No?

Muchas gracias

[espinete]

Empezado por Irreo

Puedes emitir desde un dispositivo para varios CIF. Lo único, después de la primera emisión, la empresa en cuestión tiene que ir a su Sede Electrónica, al área de "registro de dispositivos", y aceptarlo como válido (esto quizás es así siempre, pero lo comento por si acaso).

Nosotros tenemos un software desarrollado para uso propio, pero emite para tres CIF diferentes (nuestros).

Todo lo hacemos con el mismo certificado de dispositivo de Izenpe (gratuito, 10 años).

Gracias, Irreo.

Nosotros estamos desarrollando un software de facturación en la nube, alojado en Azure (no es un servidor, sino un Web App Service). No creo que haya forma de obtener un número de serie o algo parecido, aunque ahora mismo eso no me preocupa.

Lo que me confunde un poco es que en los primeros mensajes del hilo se comentaba que el "certificado de dispositivo" lo iban a terminar quitando, y que todo se podía hacer con un certificado normal de empresa, de persona física, de representante... o el que sea.

En nuestro software de escritorio sí usamos el certificado propio de cada usuario para firmar y enviar. Obviamente está instalado en su equipo. No usamos un certificado nuestro (fabricante) ni de dispositivo.

Si compro (u obtengo gratis ese de Izenpe) un "certificado de dispositivo", y lo subo al servidor... ¿puedo usar ese .pfx (o .cer, .pem o como sea) para firmar y para enviar, aunque el Emisor sean CIFs y Razones Sociales diferentes? Entiendo que nuestros clientes tendrían que validar o "aceptar" ese certificado en el portal de la hacienda correspondiente para permitir firmar/enviar en su nombre?

De todas formas, preguntaré a Gipuzkoa y demás para que me aclaren las peculiaridades de este método, y sobre todo, qué debe hacer el usuario final, que luego las preguntas me las harán a mi.