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

[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 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

Creo que el problema está en que la rectificativa tiene que tener otro número, no el mismo.

Las rectificativas van en otra serie, y con otra numeración.

Otra cosa es que hagas una factura nueva, en negativo, en la MISMA serie, y luego la factura corregida, también con otro número, en la misma serie.

Pero dos facturas con el mismo número en la misma serie, te dará error.

[Irreo]

Empezado por 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

1- Una factura aceptada, con o sin errores, NO se debe reenviar. Sólo se puede rectificar.

2- Una factura rectificativa DEBE llevar su propia serie, sí o sí.

3- Las facturas rectificadas NO se anulan, precisamente por esto se rectifica.

Si la factura tenía un error en los importes, puedes hacer una rectificación por diferencias (p.e. si era de 500€ y debía ser de 400, emites una rectificativa por diferencias con importe -100€)

En cualquier caso también puedes hacer una sustitutiva, emitiendo la factura tal cuál debía haber sido, lo que básicamente "anula" la factura original, porque hace que la factura original deje de computar.

[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.

[Irreo]

Empezado por espinete

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.

Sobre el número de serie: Inicialmente teníamos un servidor Cloud escalable en un hosting, que estaba montado sobre una VMWare.

Hay número de serie, pero como bien dices no es válido porque es una especie de VM 0f h3 A0 hA........ etc... Hablé con los del hosting y me dijeron que en algunas situaciones podría cambiar (un reescalado de servidor, cambio de software...)

Cuando les pregunté a los de Hacienda, me diijeron que el número de serie me lo podía inventar si quería, siempre y cuando se usase el mismo tanto para la solicitud del certificado, como en el registro del software, emisión de facturas, etc...

Así que durante la fase de pruebas, mi número de serie era "CLOUD-01"

Más adelante cambiamos a un servidor dedicado así que ahora sí utilizo el número de serie original.

Respecto a lo que comentas de varias empresas, sí. Como te dije, al final es el dispositivo el que emite las facturas, y estás autorizado a enviar en nombre de diferentes CIFs, siempre y cuando ellos lo acepten luego.

Y suerte si hablas con ellos. Precisamente sobre esto les llamé por teléfono en su día porque quería confirmarlo antes de dar de alta todo, y la conversación más o menos fue:

- Izenpe: Pero... no no... a ver, el certificado tiene que estar a nombre del emisor...
- Pero a ver, en la web pone que se puede usar un certificado de dispositivo, y que el certificado lo puedo emitir a mi nombre...
- Pero si es a tu nombre, no puedes emitir facturas de la empresa...
- Vamos a ver... esto lo pone en vuestra web... se puede usar un certificado identificativo de persona física, o bien de dispositivo, que según pone en el FAQ lo puede solicitar el desarrollador del software, o incluso uno de vuestra oficina.. y luego se vincula con la empresa, y es esto lo que no sé cómo se hace, o cuándo...
- Pero eso en qué web lo has visto?
- En la vuestra......
- A ver.. dime dónde....
(entramos)
- Yo: Entonces, ves lo que te digo? Si tengo un certificado de dispositivo, puedo emitir sin problema a diferentes CIF? Pidiendo YO el certificado con mi BAQ personal?
- Ehh... pues... sí, lo que pone ahí.... ehh...
- Ya... yo llamaba porque pensaba que me podrías aclarar mejor..
- Mira... es una pregunta tan compleja, que mejor escribe un formulario de contacto, y ya analizamos el caso, blabla.....