Facturas electrónicas [España]

[nincillo]

Empezado por newtron

Hola a tod@s.


Viendo que este asunto no prosperaba y que necesitaba resolverlo le encargué el proyecto a alguien que sabe más que nosotros y que domina varias herramientas de programación.


Había que resolver dos problemas, primero el de firmar el fichero XML en tiempo de ejecución, cosa que estaba complicada sin componentes externos porque desde Delphi no conocemos a nadie que haya sido capaz de hacerlo así que se ha desarrollado una dll en .NET que hace la función de firmado y que se llama desde el proyecto Delphi. Posteriormente había que hacer la llamada al webservice firmada con el protocolo X.509, cosa que tampoco sabíamos resolver y que tampoco ha sido fácil de desarrollar.


Resumiendo, aquí os adjunto un ejemplo operativo que hace las funciones más habituales de llamadas al webservice de FACE, firma y envía ficheros XML, consulta de facturas, consulta de unidades y alguna cosa más que no he probado porque en principio tampoco voy a necesitar. Por supuesto también se pueden usar sus funciones para solamente firmar un fichero XML para enviarlo por otros medios.



Está compilado en Delphi Berlín e imagino que funcionará igualmente en Tokyo, para que funcione en versiones anteriores posiblemente habría que hacer algunos retoques.



Aunque lo pongo en un LEEME.TXT lo único que hay que hacer es tener instalada y registrada la dll de CAPICOM (no incluida) y posteriormente ejecutar el fichero REGISTER.BAT para registrar la dll que se usa para la firma.


Link para la descarga.



Saludos y que aproveche.

Edito:

Se me olvidaba comentar dos temas:

1º Para poder enviar facturas a FACE hay que estar dado de alta como proveedor. Si quieres usar los wsdl de prueba hay que estar dado de alta por el entorno de pruebas y si quieres usar los de producción hay que darse de alta también en producción. Si no me equivoco, el entorno de pruebas es https://se-face.redsara.es/es/login

2º El programa que adjunto tiene los WSDL del entorno de pruebas, para pasar al de producción solo hay que cambiar en el objeto HTTPRIO el wsdl, puerto y servicio.

Hola.

Estoy intentando poner en marcha el intercambio de información con la sede electrónica de Facturae utilizando D2007 y poco a poco, partiendo del ejemplo que compartió en su momento newtron (muchas gracias por hacerlo) voy consiguiendo hacer casi "todo".

Actualmente, si las peticiones las hago utilizando los certificados instalados en el sistema, la petición se envía y la respuesta se recibe. Sin embargo, si la petición la intento hacer utilizando un certificado que está en fichero del disco duro, la petición no se llega a lanzar ya que me salta el siguiente error: 'wsu' es un espacio de nombres sin declarar. Línea 2, posición 327.

Si la contraseña que pongo no es la correcta, me salta el mensaje de que no es correcta, con lo cual el chequeo de la contraseña lo hace correctamente, pero cuando luego "entiendo" que intenta montar el Xml, algún problema problema hay.

Entonces me he conseguido montar en entorno de pruebas con una versión de delphi más moderna para probar el ejemplo tal cual se publicó en su momento, y me he encontrado que presenta el mismo problema. Al firmar con el certificado del sistema lo hace correctamente, pero si se intenta firmar con el certificado en fichero, sale el mismo mensaje de error.

A ver si alquilen me puede "iluminar".

Gracias y un saludo.

[ermendalenda]

Un pelin más cerca de la otra obligación
Factura electrónica.
Si el moderador piensa que es mejor abrir otro hilo sin problema
https://www.boe.es/eli/es/l/2022/09/28/18

[elcharlie]

Empezado por nincillo

Si selecciono el certificado que tengo dado de alta como integrador y pongo el programa "apuntando" a las url de prueba y le pido por ejemplo "SolicitarUnidades" me responde correctamente. (correcto)

Si con el mismo certificado, apunto al entorno real, me da error de que no estoy dado de alta (correcto también)

El problema viene cuando hago las prueba de envío con el certificado de "proveedor", no de "integrador". En ese caso me da error tanto en el entorno de pruebas como en el real.

Es como si hiciera falta también dar de alta o activar algo para poder hacer envíos mediante webservice con el certificado de proveedor...

Les he mandado una consulta, pero de momento no me han contestado...

Hola, Tengo la misma duda, ¿Te han contestado algo? Me toca ahora integrar el envío de la factura a FACE y me estaba planteando la misma duda.

[ermendalenda]

Empezado por elcharlie

Hola, Tengo la misma duda, ¿Te han contestado algo? Me toca ahora integrar el envío de la factura a FACE y me estaba planteando la misma duda.

Imaginaos que se ponen de acuerdo Ministerio de Economía y Transformación Digital con Hacienda y para la factura electrónica amplían el XML de Verifactu a los campos que faltan y los entornos de prieba y prodccuion sean los mismos que los de Verifactu.no sé, lo mismo estamos currando de más.

[ermendalenda]

Buenas de nuevo.
Estoy dándole vueltas al procedimiento desee que me pieennuna factura electrónica, independientemente de cual sea el reglamento, mínimo pedirán datos normales eel cliente + datos DIR3.
Teniendo en cuenta esto veo una gran complicación para puestos de facturación rápidas, por ejemplo en tiendas de ventas al por menor en los que esa gestión se hace inviablemQue os parece la idea de que se le envíe un correo con un enlace al cliente para que :
1. Sirva como autorización expresa
2. Rellene el formulario con todos los dato para generar la factura.
3. Devuelva el error al mismo cliente en caso de que la comunicación sea fallida por datos incorrectos
4. En caso de repetición de cliente ya están guardados los datos
5.posibilidad de que el vendedor pueda reenviar una factura electronica o pueda revocar la autorización a petición del cliente.

Creo que de esta forma liberamos la carga y responsabilidad de los comercios. Pero no se a efectos legales y si esta dentro de los límites.
Como lo veis?

[antoine0]

Empezado por ermendalenda

Que os parece la idea de que se le envíe un correo con un enlace al cliente para que :
1. Sirva como autorización expresa
2. Rellene el formulario con todos los dato para generar la factura.
3. Devuelva el error al mismo cliente en caso de que la comunicación sea fallida por datos incorrectos
4. En caso de repetición de cliente ya están guardados los datos
5.posibilidad de que el vendedor pueda reenviar una factura electronica o pueda revocar la autorización a petición del cliente.

Creo que de esta forma liberamos la carga y responsabilidad de los comercios. Pero no se a efectos legales y si esta dentro de los límites.
Como lo veis?

Primero me parece que la casuística es la típica de las tiendas, hipermercados y demás, cuando el cliente autónomo quiere factura en lugar de ticket.
En la practica veo dos maneras de hacerlo:

1. o vas a algún mostrador (o directo en el programa del cajero) y tienen un proceso para registrarte (suelen usar tu NIF como clave) y luego emiten la factura de sustitución.
2. o te conectes a alguna web donde tu haces el mismo proceso creando una «cuenta», das tu datos, entres el número del tique y te sacas la factura; y la tienda no paga el cajero, ni lo forma

En mi practica, odio a la segunda manera y prefiero la primera, pero no me dan la elección.
Del punto de vista de la seguridad de datos, supongo que se da un número seudo-aleatorio al tique (o ligado al tique, por ejemplo impreso en él) para evitar que alguien pueda traerse una factura sin haber comprado la mercancía. No sé si usando la fecha-hora sería suficiente. Tampoco sé si se puede (o se debe) evitar que alguien recoge un tique en el suelo. Pero me imagino que ya está estudiado.
Y estos sistemas deben ser legales sí o sí.
Con la factura electrónica la segunda opción será fundamente la misma. En el caso de la primera, si las facturas electrónicas se ponen a disposición directamente del proveedor al cliente (y no pasan por un punto central, como ocurre en demás países o con FACe) supongo que pedirán una dirección de correo electrónico, o pedirán que el cliente se conecte después a alguna web con un certificado ligado a su NIF, o lo que les ocurre a los redactores de los ministerios. Aquí no sabe nadie dónde estarán las lindes...

Luego la idea del link por correo electrónico supone que el comerciante debe pedir su correo electrónico al cliente (y al cliente puede ser que no le hace gracia, por ejemplo si no quiere recibir «comunicación» de «promociones») y luego no equivocarse a la hora de entrarlo en el sistema. Creo que dar a conocer una dirección web (mi caso 2) resulta más o menos igual en la gestión cliente y bastante menos posibilidades de error a nivel informático; pero se pierde el vinculo...

[ermendalenda]

Empezado por antoine0

Primero me parece que la casuística es la típica de las tiendas, hipermercados y demás, cuando el cliente autónomo quiere factura en lugar de ticket.
En la practica veo dos maneras de hacerlo:

1. o vas a algún mostrador (o directo en el programa del cajero) y tienen un proceso para registrarte (suelen usar tu NIF como clave) y luego emiten la factura de sustitución.
2. o te conectes a alguna web donde tu haces el mismo proceso creando una «cuenta», das tu datos, entres el número del tique y te sacas la factura; y la tienda no paga el cajero, ni lo forma

En mi practica, odio a la segunda manera y prefiero la primera, pero no me dan la elección.
Del punto de vista de la seguridad de datos, supongo que se da un número seudo-aleatorio al tique (o ligado al tique, por ejemplo impreso en él) para evitar que alguien pueda traerse una factura sin haber comprado la mercancía. No sé si usando la fecha-hora sería suficiente. Tampoco sé si se puede (o se debe) evitar que alguien recoge un tique en el suelo. Pero me imagino que ya está estudiado.
Y estos sistemas deben ser legales sí o sí.
Con la factura electrónica la segunda opción será fundamente la misma. En el caso de la primera, si las facturas electrónicas se ponen a disposición directamente del proveedor al cliente (y no pasan por un punto central, como ocurre en demás países o con FACe) supongo que pedirán una dirección de correo electrónico, o pedirán que el cliente se conecte después a alguna web con un certificado ligado a su NIF, o lo que les ocurre a los redactores de los ministerios. Aquí no sabe nadie dónde estarán las lindes...

Luego la idea del link por correo electrónico supone que el comerciante debe pedir su correo electrónico al cliente (y al cliente puede ser que no le hace gracia, por ejemplo si no quiere recibir «comunicación» de «promociones») y luego no equivocarse a la hora de entrarlo en el sistema. Creo que dar a conocer una dirección web (mi caso 2) resulta más o menos igual en la gestión cliente y bastante menos posibilidades de error a nivel informático; pero se pierde el vinculo...

Bueno. Me refiero a algo intermedio la factura la generamos con los datos principales, da igual de a
Sustitucion, ordinaria o de canje con los datos esenciales cif, nombre dirección... e incluso un pdf con la factura ordinaria, pero para solicitar la factura electrónica se le envía un formulario con los datos ya introducidos por el vendedor y el número de factura asignada a un correo del mismo cliente, a falta de rellenar los fatos necesarios para la factura electronica , con lo cual no da lugar a poder emitir algo que no es y ya aprovechamos para, si el cliente quiere, guardar esos datos.

[ermendalenda]

Os dejo un enlace interesante que da la idea de por donde van los tiros de por donde podemos ir tirando con lo de la nueva ley de factura electronica que ha salido recientemente en el BOE sobre creacion y crecimiento de empresas (BOE de Septiembre de 2022)

Este enlace tiene la parte mas interesante en las páginas 7 y 8 en los que hace referencia de usar la red de Face/Faceb2b como nodo común de los proveedoress de servicios de factura electronica:
https://administracionelectronica.go...dComunidad=201

Teniendo en cuenta que ya han pasado 3 años desde este acuerdo pueden haber repensado el tema y como os decia, no me extraña que se use como base Veri*Factu y los campos que faltan para realizar la factura electronica: DIR, Productos y servicios, pero que finalmente vayan a la redsara de Faceb2b. Son conjeturas mías, ¿que pensais vosotros?

Este es el enlace de la web de PAE donde esta ubicada la información: https://administracionelectronica.go.../documentacion

[elcharlie]

Buenas a tod@s, ¿sabe alguien si hay algún ejemplo de envío con SecureBlackBox?
Estoy intentando de todo y me da error de cabecera.

[Neftali [Germán.Estévez]]

En este otro hilo (sobre TicketBAI) hay varios ejemplos de envío con SecureBlackBox.
El tema es diferente, pero tal vez si miras el código te de alguna ayuda o pista para resolverlo.

En el segundo mensaje del hilo, hay referencias a códigos y ejemplos de envío con diferentes componentes.
Ahí encontrarás algunos de firma y envío con los SecureBlackBox.

NOTA: por favor no mezcles mensajes entre hilos.

[ermendalenda]

Estoy haciendo todo esto en php como el firmador.php de ticketbai, pero un php para cada utilidad de face y faceb2 sin pagar nada de apis:.
Firmador.php
Envio_face_faceb2b.php (con la creación del soap)
Servicios_face_faceb2b.php (cambios de estado, consultas, anulaciones...)
Tanto para staging(pruebas) como producción
De modo que se pueda ejecutar con órdenes sencillas curl y devuelva el resultado en un archivo y así poderlo usar desde cualquier lenguaje
Vaya currada

[elcharlie]

Empezado por Neftali [Germán.Estévez]

En este otro hilo (sobre TicketBAI) hay varios ejemplos de envío con SecureBlackBox.
El tema es diferente, pero tal vez si miras el código te de alguna ayuda o pista para resolverlo.

En el segundo mensaje del hilo, hay referencias a códigos y ejemplos de envío con diferentes componentes.
Ahí encontrarás algunos de firma y envío con los SecureBlackBox.

NOTA: por favor no mezcles mensajes entre hilos.

Gracias Germán, pero el envío de Facturas Electronicas a Face es completamente distinto al de los del TicketBai, de ahí mi pregunta,
por otro lado perdona si me he equivocado de hilo, pero he dado por hecho que seria en este, Facturas Electronicas.
No obstante, muchas gracias por info, y de nuevo mis disculpas.

[Neftali [Germán.Estévez]]

Empezado por elcharlie

pero el envío de Facturas Electronicas a Face es completamente distinto al de los del TicketBai, de ahí mi pregunta

Si, se que es diferente, pero pensé que te podía dar pistas de las propiedades a la hora de configurar los componentes.

Empezado por elcharlie

por otro lado perdona si me he equivocado de hilo, pero he dado por hecho que seria en este, Facturas Electronicas.

Para nada, este es el hilo correcto.
Me refería a que si preguntabas algo en el foro de TicketBAI referente al envío, que intentaras no mezclar.

[nuevo1234]

Verifactu y facturae son dos cosas diferentes? Tienen alguna relación?
Perdón por mi desconocimiento. Pero con tantas novedades me pierdo

[ermendalenda]

Empezado por nuevo1234

Verifactu y facturae son dos cosas diferentes? Tienen alguna relación?
Perdón por mi desconocimiento. Pero con tantas novedad, de foema similar al siis me pierdo

Sí, son diferentes , Verifactu es una normativa que te obliga a generar unos ficheros xmls que puedes enviarlo a la aeat (como el sii) o conservarlos firmados ante posibles requerimientos de la aeat.
La factura electronica es el intercambio de facturas entre un proveedor y un cliente, también esttructurada.
Relación habrá si un cliente te pide una factura electrónica, seguramente hebras que ponerle el código generado con verifactu en algún campo de la factura electrónica.

[[newtron]]

Hola a tod@s.

Por si a alguien le sirve, aquí tenéis un buen resumen del tema de la facturación electrónica con plazos concretos de entrada en vigor.

Saludos.

[keys]

Gracias.

Me hace gracia lo siguiente :

Para ello, las soluciones tecnológicas y plataformas ofrecidas por empresas
proveedoras de facturación electrónica, deberán garantizar la gratuidad de las
mismas.

Con un par.

[[newtron]]

Pues si, la verdad es que no me cuadra mucho ese párrafo. Quiero entender que al cliente que solicite una factura electrónica a su proveedor no se le cobre por emitirsela.

Saludos.

[Casimiro Notevi]

Empezado por keys

Me hace gracia lo siguiente :
Con un par.

Pues nada, que habiliten una renta vitalicia para "informáticos".

[espinete]

Hola a tod@s...

Entre la "Ley Antifraude", FacturaE (face, faceb2b), SII, TicketBAI y la "nueva factura electrónica" de la que se está hablando ahora, ya tengo la cabeza que no me da para más. A ver si me lo podéis aclarar, si es que es posible aclararlo...

La "Ley Antifraude" exigía a las aplicaciones de facturación a cumplir una serie de requisitos: no permitir borrar o modificar facturas, exigir hacer rectificativas, que si la integridad de los datos, accesibilidad, blablabla.
FacturaE lleva con nosotros varios años ya, así como el SII (que ya de por sí, encima algunas comunidades autónomas tienen sus diferencias).
Luego País Vasco decidió ir por su cuenta y sacó el TicketBAI, adelantándose al resto.
Y ahora anuncuan la "Factura Electrónica", entiendo que para 2024-2025 (o a saber si se retrasa).

Entiendo que esta factura electrónica nueva es la evolución lógica de la "Ley Antifraude" y una copia del TicketBAI, pero para toda España. Pero... ¿qué pasará con todo lo demás? (face, sii, ticketbai...)? ¿País Vasco seguirá por su lado? ¿Se sabe algo de otras comunidades?

Me parece MUY FUERTE lo de "...las soluciones tecnológicas y plataformas ofrecidas por empresas proveedoras de facturación electrónica, deberán garantizar la gratuidad de las mismas...". ¿Peeerdooonaaa? ¿Pero esta gente se cree que trabajamos para ellos o qué?

En fin, que me gustaría saber qué es cada cosa, y hay que centrarse únicamente en desarrollar la "nueva factura electrónica", porque tengo la cabeza hecha un lío.
Actualmente nuestro software ya es compatible con FacturaE, SII y TicketBAI. Entiendo (espero) que esta nueva factura electrónica se parezca más al TicketBAI, que bastantes dolores de cabeza nos supuso en su momento a todos.

Ya podría Hacienda enrollarse con las empresas de software y habilitarnos un periodo con una reducción de impuestos, por las molestias