Pues al final me has ayudado mucho....lo he echado todo abajo y he empezado haciendo exactamente la misma factura que para un cliente nacional + el idotro y me ha entrado perfectamente.


Dejo el código por si a alguien lo puede necesitar...ejemplo de una factura a un bar/tienda de extranjeros no comunitarios



Muchas gracias de nuevo, compi.

Extranjero sin NIF
 

Sólo por curiosidad, si la caja de KAS no la exportas a China sino que la vendes a un bar propiedad de un extranjero, yo me pregunto: al ejercer una actividad económica, ¿ese extranjero no tiene un NIF/NIE?
En todos los registros fiscales que recuerde se dejan 9 posiciones para el identificador, que sí o sí tiene que ser un NIF. Si ese extranjero tiene un asalariado y le practica retención tendrá que presentar el modelo 110/111 o equivalente, y en él no puede indicar su identificador chino.

Lanzo esa reflexión al aire.

Supongo que en ese caso al tener un nif tendré que enviarlo con IDTYPE = 2.

Zuzendu - MODIFICAR
 

Hola,
¿Hay alguna forma de forzar el estado RECIBIDO con errores de una factura para probar a enviar un fichero de modificación?
He probado algunas cosas para forzarlo pero siempre me da estado RECHAZADO (01)

Gracias por adelantado

Es posible que haya un malentendido. Lo que quería decir es que, si no estoy muy equivocado, el propietario del bar, extranjero o no, si ejerce una actividad tiene que tener un NIF/NIE español, en cuyo caso el identificador sería el 01 y no tendrías que indicar el código de país.
El tipo de identificador 02 sería para un NIF intracomunitario, que no es el caso.

El NIF ("02") es solo para Europa. Lo van a intentar validar y si es una empresa No-EU, va a petar.

En su momento hice pruebas con un NIF de UK (comprobado en la web oficial VAT de UK), y daba error:

<IDOtro>
<CodigoPais>GB</CodigoPais>
<IDType>02</IDType>
<ID>GB246005436</ID>
</IDOtro>

Cuando les pregunté, me dijeron esto:

"La salida de Reino Unido de la Unión Europea una vez finalizado el período transitorio supone, entre otras cuestiones, que los flujos de mercancías entre España y Reino Unido dejarán de tener la consideración de operaciones intracomunitarias, y en consecuencia, no correspondería utilizar el NIF IVA para identificar al destinatario."

En resumen, NO puedes usar "02" para identificar a destinatarios que no sean intracomunitarios.

PD: Este ID de GB lo cogí de Internet, no corresponde a ninguna operación nuestra.

Prueba a dejar las líneas sin descripcion, creo recordar que daba error, pero la aceptaba.

Sí, perdón. Me lié.

Buenas,

Prueba a enviar una fecha de expedición futura a la actual.

Zuzendu -Modificar
 

Muchas gracias por la ayuda a los 2.
He probado como dice Neftali (quitando el contenido del tag DescripcionFactura) y he recibido Estado: 00 con código: 016

Saludos!

Alava - Primera factura
 

Estoy haciendo pruebas de primera factura para la hacienda de Alava concretamente.

La respuesta que me llega:
¿Es normal que la primera factura devuelva este aviso o hay alguna forma de evitarlo?

La estructura que lleva mi primera factura omite el nodo

Correcto.
Extraído de la documentación:

Existen determinados casos justificados en los que no es posible realizar elencadenamiento con la factura anterior, entre otros:

• Cuando se emite la primera factura de un dispositivo nuevo.
• Cuando se emite la primera factura de la persona contribuyente.
• Cuando se produce la rotura de un dispositivo y hay que sustituirlo por otro.

Alava - Primera factura
 

Perfecto! es lo que había leído pero era por saber si hacíais algo diferente para evitarlo :)
Gracias!

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:

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 :)

Firma y envío en PHP (problema certificados)
 

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?

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:

Saludos.

005: El fichero ya se ha recibido anteriormente.
 

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

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.

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.

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.

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" :D

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

:rolleyes:

Gracias Irreo. Sí, de acuerdo con lo que dices. Pero la cuestión es que se hizo esa rectificativa (tipo Sustitutiva con la misma serie y número que la factura que se intentaba rectificar), se generó el QR de la rectificativa y no se puede enviar a la Diputación porque, obviamente, dicen que esa factura ya les consta, pero la que les consta es la inicial que se intentaba rectificar. Como no es posible modificarla (porque ya se generó el IDTBAI), la solución que se me ocurre es eliminarla (anular la rectificativa mal emitida) para hacer una como debe ser: con su serie y número independiente... ¿Sería ese el proceso? Entiendo que sí porque se trata de eliminar una factura con su QR ya generado y su IDTBAI

Gracias por el apoyo al resolver estas dudas

Gracis espinete. Sí, de acuerdo, es así, pero como ya no es posible modificar la rectificativa mal emitida (con la misma serie y número...) ya que se generó su IDTBAI, lo solución entiendo que sería eliminarla (anularla) y crear una nueva bien hecha (con serie y número independiente) ¿Crees que debería ser así? ¿Cómo si no? porque esa rectificativa que tal y como está no va a recibir la Diputación, no debería constar ¿No?

Creo que tienes algunos conceptos algo erróneos.

Una cosa es CORREGIR una factura que ha sido rechazada, y otra RECTIFICAR una factura.

En el primer caso, estás reenviando una factura ya enviada previamente, pero con datos correctos (bien sean del XML, o datos de la factura, que ocasionaron un rechazo).

En el segundo caso, estás emitiendo una NUEVA factura, rectificando una factura previa, bien porque ha habido una devolución, se cambian datos del cliente, se corrigen importes erróneos, hacienda la ha aceptado pero ha dado algún aviso, etc...

Dicho esto, sigo sin entender por qué insistes en lo de sustitutiva con el mismo número y serie.

Si es sustitutiva, es una factura rectificativa, y por lo tanto lleva su serie y su número.

Es decir, no tienes que anular nada.... si lo que quieres es sustituir esa factura, simplemente emite una nueva factura, rectificativa por sustitución, haciendo referencia a ella.

Umm, creo que no nos entendemos. Esta es la situación.

1.- Factura creada, imprimida y enviada a la Diputación sin problemas.

2.- Después se detecta un error. Se hace rectificativa de esa primera factura, pero la rectificativa se hace mal (se asigna la misma serie y el mismo número y la misma fecha). Se genera el fichero XML de esta factura rectificativa y se intenta enviar a la Diputación pero, obivamente, la Diputación la rechaza porque dice que esa factura ya la tiene.

En este punto hay una factura emitida (la segunda, que es la rectificativa) pero que no puedo corregir (porque ya se ha emitido el fichero TicketBAI) y que tampoco puedo enviar a la Diputación (porque no la acepta). Se me ocurre como única solución eliminarla/anularla y crear una nueva rectificativa bien hecha. Me gustaría confirmar con vosotros si este proceder es correcto o, de lo contrario ¿Cómo me deshago de la factura rectificativa mal creada en el paso 2?

Entiendo que la factura rectificativa que enviaste con mismo nº de factura ha tenido que ser rechazada, porque esa factura ya estaba comunicada. Es decir, a Hacienda no le consta este último envío. Tienes que proceder como te han comentado los compañeros, con una nueva factura rectificativa (y revisar tu sistema para que no te deje crear una factura con una serie y número ya existente :p).

Vale, ahora SÍ te he entendido, perdona por el lío :)

Por un lado, yo diría que Hacienda no ha registrado ninguna factura nueva.

Al haberle enviado una factura con un emisor + serie + número ya existente, te devuelve el error "005" y listo.

Es decir, la anulación procedería si hay una factura que exista (por ejemplo un intento de rectificación con su número y serie, pero que finalmente no procede y quieres anular)

En tu caso, entiendo que no habrá sido así, me extraña que hayan creado OTRA factura nueva (por mucho que hayas enviado de tipo rectificativa) con el mismo número y serie, para el mismo emisor.

Entra a la sede electrónica por confirmarlo.

Flipante, pero bueno, hoy en día ya no me sorprende nada.

Me preocupa eso de que el cliente final tendrá que aceptar, posteriormente al primer envío, el dispositivo en su "zona de clientes" de la diputación que corresponda. Y me preocupa porque no veo yo a los clientes haciendo eso.
Tenemos clientes que ni siquiera sabían que les hacía falta un certificado, y mucho menos cómo se instala, etc. Pero bueno, es lo que toca: a ponerse las pilas a la fuerza. Y esto solo en Pais Vasco. Cuando empiece el Veri*Factu ese en toda España lo vamos a pasar genial :o

Ahora tenemos clientes enviando facturas reales a entorno de pruebas, luego al entorno real, luego otra vez al de pruebas... Un disparate que es difícil de explicar y de entender, y luego en vez de llamar a Hacienda, nos llaman a nosotros cuando han hecho algo raro, como si fuéramos asesores fiscales, contables o trabajáramos en Hacienda :rolleyes:

Voy a hacer pruebas con certificado de dispositivo y puede que al final optemos por permitir ambas cosas, a elección del cliente. Mientras esté todo bien explicado para que los clientes no se líen, no debería haber problema ;)

Si te informas por ahí y ves que el certificado de dispositivo no es algo que vaya a desaparecer próximamente, yo optaría por ese modelo (esta mañana he estado mirando un poco en plan rápido pero no he visto nada, supongo que lo mejor sería preguntarles directamente a los técnicos).

Respecto a lo de la Sede Electrónica.... creo que es algo a lo que se tendrán que ir acostumbrando las empresas. Al fin y al cabo, es ahí donde se ve qué facturas hay OK, qué facturas han dado errores, qué facturas están rectificadas, si computan o no, etc....

Además, a nosotros por ejemplo nos envían un informe semanal con los errores que han ido saliendo (aunque hayan sido corregidos).

Supongo que poco a poco están llevando a que esté todo digitalizado, y al final esas facturas y contabilidad "en papel" desaparecerán.

Error certificado
 

Hablando de certificados...
¿Os está dando a vosotros también error: Certificado remitente debe estar homologado y no revocado y no caducado (más de un mes) en los envíos a Gipuzkoa?

Me esta dando esto desde 4:35 de hoy cuando mi certificado no caduca hasta el año que viene y llevamos trabajando igual meses...

Acabamos de emitir la primera factura de hoy, y en principio ha salido bien sin problemas (Gipuzkoa).

Colaboradores sociales de TicketBAI
 

Vale, creo que es un problema mio.

Aprovecho para preguntaros otra cosa.
Nos han dicho desde Hacienda que podemos firmar facturas de nuestros clientes con nuestro certificado si nos registramos como "Colaboradores sociales de TicketBAI" (si no tendriamos que hacerlo con el el certificado de cada cliente).

¿Alguno sabe como registrarse en esto (enlace o pasos a seguir...)?

No sé si te refieres a esto (chapa + formulario para rellenar):

https://egoitza.gipuzkoa.eus/gao-bog...4/c2007007.htm

Muchas gracias por la ayuda.
He conseguido mas información por parte de los técnicos de hacienda que comparto por aquí por si a alguien le viene bien:

Es necesario el alta como Colaboradores Sociales de TicketBAI para poder hacer envíos de otros NIFs emisores utilizando vuestro certificado. Para ello, hay que rellenar el impreso:
(espero que se vean las URLs)
https://www.gipuzkoa.eus/documents/2...d-b08a04a4dba6

Y enviadlo mediante Registro Electrónico a la Secretaría Técnica del Departamento de Hacienda Y Finanzas de la Diputación Foral de Gipuzkoa.
https://egoitza.gipuzkoa.eus/WAS/COR...ma=C&app=00001


Este es un procedimiento válido para Gipuzkoa. Para el resto de haciendas habrá que hacer algo similar me imagino

Casualmente a nosotros nos está dando hoy un error similar con un certificado renovado esta misma semana (caduca en 2026):

"certificado remitente no válido para emisor factura"

Tras varios intentos seguidos, se envía sin problema.

No sé si serán fallos puntuales de los servidores de Gipuzkoa o qué.

Gracias a ambos. Sí, el proceder es el comentado. Confirmo que también me lo han dicho así en la Diputación. Lo de la revisión del sistema para bloquear la posibilidad de cambio de serie ya estaba haciéndose mientras preguntaba esto, claro ||-||. Muchas gracias :)