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.

Crea y crece
 

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

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.

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?

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.

Acuerdos Foro Factura Electrónica 2019
 

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

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.

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.

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

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.

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

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.

Verifactu y facturae
 

Verifactu y facturae son dos cosas diferentes? Tienen alguna relación?
Perdón por mi desconocimiento. Pero con tantas novedades 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.

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.

Gracias.

Me hace gracia lo siguiente :

Con un par.

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.

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

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

Creo que es un problema de redacción, espero que lo sea.
A los que hacen estos textos no les iría mal hacer un curso de escritura, volver a la secundaria o algo para aprender a redactar. (O que Google incluya en su traductor: lenguaje oficial :D )

Hola espinete, la "Ley Antifraude" y la factura electrónica son asuntos distintos, en mi opinión:

- La "Ley Antifraude" (VeriFactu) es el TicketBAI de la AEAT. Si ya tenemos la aplicación hecha para TicketBAI, cuando se publique el reglamento VeriFactu se desarrolla en la misma línea como "cuarta hacienda foral", o quinta si contamos con Navarra, que al final no se sabe si irá por TicketBAI o VeriFactu, esta es otra...
- FACE sigue siendo lo mismo: si prestamos un servicio al Ayuntamiento de Madrid éste espera que le envíes un XML FacturaE firmado mediante FACE, si no, no te pagará la factura.
- Si el servicio lo prestamos a una Administración Pública del País Vasco, tendremos que cumplir con la normativa TicketBAI y además generar el XML firmado.
- Con el SII también vamos a convivir, en este caso presentamos los datos de facturas de venta, y también de compra a la AEAT con un margen de 4 días.
- Se nos olvidaba el FACeB2B, una extensión de FACE que permite facturar a subcontratistas especificando la obra del contratista en el XML, y algunas cosas más...
...

Un follón, no cabe duda, pero lamentablemente esto ha llegado para quedarse.

Desde mi punto de vista se están refiriendo a los protocolos de comunicación entre plataformas: si la empresa A usa B2BRouter para emitir facturas electrónicas a la empresa B que las recibe por EDICOM, dichas plataformas se tendrán que poner de acuerdo en cuanto a la interconexión e interoperabilidad, cuyo reglamento además está pendiente de publicar (Artículo 2 bis, Apartado 10, Ley 18/2022, de 28 de septiembre).

Normativa 1: Verifactu es similar a tickebai para enviar a hacienda
Normativa 2: factura electrónica, es el conjunto de las facturas electrónicas que existen(las que cumplen nomrat8vas), , facturae, People...,, es la obligación de enviar y recibir facturas a y desde proveedores... puede intervenir organos como el ministerio de economía y hacienda si hay o detecta morosidad excesiva.
Son 2 normativas y las 2 serán obligatorias, la gratuidad se refiere a que debe estar disponible para el receptor de la factura por los x años que esté vigente según ley, 4 ó 5 años creo.

Gracias habrá que empaparse y apeovechar la poca información que hay de momento.

Hola...

Necesito obtener el listado de administraciones públicas y sus correspondientes "órgano gestor", "unidad tramitadora", "oficina contable", etc.

En Delphi lo tengo hecho, pero necesito ahora hacerlo en PHP y nunca he trabajado con WSDL desde PHP.

Sé que existe una API REST para obtener las entidades acogidas a DIRe (Directorio de Entidades), pero creo que no es lo mismo. Necesito obtener las administraciones públicas, y solo encuentro la opción WSDL:
://administracionelectronica.gob.es/ctt/face/descargas

¿No existe API REST para obtener ese listado?

Me respondo a mi mismo...

(y acabo de darme cuenta que quien abrió este hilo hace ya 7 años fui yo!! :eek:)

Solo existe el SOAP, así que hay que currarse la creación del XML, la firma, etc. en PHP "a mano" (o usar alguna librería de FacturaE que lo haga).

Aclaro (a mi mismo también) que una cosa es DIRe y otra DIR3. Esta gente poniendo nombres son lo más.

Disculpen por postear sobre PHP, pero como en los hilos de ticketBai hay también algo de código php, lo pregunté aquí.

Hola a todos,
Expongo aquí alguna información de como va el temita de la facturación electrónica a falta de que se publiquen los requerimientos técnicos y nos compliquen la vida.
Al parecer, a diferencia de otros países como Italia, en España no va existir (...de momento) una plataforma única donde enviar y recibir las facturas electrónicas, se ha
optado por la vía de lo privado, de modo que cada empresa (o autónomo) deberá elegir una plataforma privada de las que ya existen (como por ejemplo Edicom) o de las
que seguro se crearan nuevas, a esa plataforma privada es a la que se enviarán y de la que se recibirán las facturas a cliente o de proveedores.
"La gratuidad" a la que se refiere la ley es a la interconectividad entre las plataformas, o sea, que la empresa contrata con una sola plataforma y esa plataforma es la que se encarga de conectarse con otras para enviar la factura a los clientes o recibirla de proveedores, independientemente de la plataforma que tenga contratada cada uno.
En cuanto a los formatos de la factura todavía no está claro, cuantos ni cuales serán admitidos, supongo que se publicará alguno con los datos mínimo, en principio la idea es admitir todos los formatos estándar internacionales Edifac , el propio del facturae a administraciones públicas, etc. Es de suponer que como cada plataforma opera con el suyo, admitirán varios formatos.(???)
En definitiva nos tocará pagar a todas las empresas las plataformas privadas y a nosotros como programadores pelearnos con sus formatos y sus enlaces. Espero que al ser privadas por lo menos que sean agiles a la hora de poner servidores de prueba.
De todas formas esto parece que va muy lento para el grueso de empresas será obligatorio en 2025 así que recomiendo no agobiarnos de momento.

Pero..., disculpa mi ignorancia, pq todavia no me he metido con el tema. Pero no se supone que con FACE B2B, es ahí donde tendremos que enviar y recibir las facturas?, y ademas de forma gratuita? Pq siempre he pensado que para eso habian habilitado ese portal...

Pero vamos a ver una cosa...

¿Cómo que varios formatos? ¿Cómo que varias plataformas?

O sea, que la empresa de software debe encargarse de elegir una plataforma donde subir las facturas y permitir consultarlas (el alojamiento en la nube cuesta dinero)? Y además, probablemente, hacer que el software debe ser compatible con todos los formatos posibles?

No les sirvió Ticketbai como ejemplo, pese a sus problemas iniciales?

No se supone que FacturaE, FACe, SII deberían haber servido para algo?

Vamos a seguir siendo el país de los PARCHES?

Pues qué quereis que os diga. Dentro de mi ignorancia de cómo está la cosa en la actualidad dudo que obliguen a TODO EL MUNDO a asociarse con una plataforma para el tema de las facturas electrónicas. Eso vale dinero y yo en particular no lo veo necesario. En teoría la ley obligará a emitir y recibir facturas electrónicas. Muchos de nosotros ya emitimos facturas con formato "facturae" sin mayor problema y recibirlas tampoco debería de serlo porque no deja de ser un fichero XML y en internet hay lectores de facturas electrónicas. ¿Para qué queremos entonces una plataforma?

Saludos.

Se puede esperar que si una empresa (cliente) utiliza más de un formato de intercambio, la plataforma le hace pagar más cuotas. Por tanto, para una empresa (pequeña) dada, al final opera siempre con un solo formato. Y para un desarrollador ocurre un poco lo mismo: elige a una plataforma de referencia, y a un formato; no hacerlo significaría suportar un suplemento de gasto y tiempo que no se puede facturar.

De hecho es una de las razones que hace que el mundo de las plataformas quedará reducido a unas pocas al paso del tiempo; que ¿serán las que han sabido atraer a los desarrolladores?

Me encontró en este posición; y he tenido la sorpresa que para usar la plataforma de pruebas, había que pagar un segundo contrato, como si fuese una segunda empresa.
Es cierto que usaba un contrato baratísimo, y que había otras formas de contrato más premium que incluyan el acceso a la plataforma de pruebas; y un desarrollador independiente debe optar al tipo de contrato que le será más adaptado; que será distinto del contrato de su cliente... (= más gasto o más facturación, según cómo se mira).
Aparte de ser más agiles, hay que recordar que las empresas privadas no suelen regalar medios o funcionalidades.
Hay dos vertientes: emitir facturas, y recibirlas. Lo de emitir sería en 2025 para muchas empresas. Pero de lo que he leído hasta la fecha, las que la empresa reciben serán electrónicas si así lo decide el emisor. En 2023 si el emisor es grande empresa.
Es cierto que las plataformas pueden aliviar el tema para las muchas empresas que manejan un número reducido de facturas, lo pondrán en PDF y con eso se apaña mucha gente. Pero si la empresa quiere ir un poco más lejos y recuperar los datos que están incorporadas en la factura electrónica, es decir modo ERP en lugar de ser una sencilla contabilidad, deberán lidiar con la API y el formato propuesto por la plataforma (después de haber pasado por caja). ¡Ya!

Creo que a esto ya ha respondido espinete:
Aunque estoy consciente que lo de «nosotros» y «queremos» tiene matices que pueden ser variopintas :rolleyes:

Sobre FaceB2B...
 

TENIA ENTENDIDO: que el FaceB2B es una plataforma suministrada por la AEAT para la remisión de facturas entre empresas que subcontraten con las Administraciones... pero que quedaría abierto para que cualquier empresa pueda usarla como plataforma de emisión y recepción de facturas. El formato electrónico es parecido al que generamos para el FACE.GOB.ES pero posiblemente haya que meter cambios... primero porque las empresas privadas tienen un identificador DIRe, mientras las administraciones públicas tienen 3 identificadores: Órgano Gestor, Unidad Tramitadora y Órgano Contable. Para Obtener un identificador DIRe sólo tienes que registrarte con un certificado válido, luego puedes de darte de alta en FACEB2B sin problemas como "Cliente".

¿Y programas y los desarrolladores? Para que nuestro software pueda automatizar el envío de facturas, creo que podemos darnos de alta en esa plataforma como ESF: Empresas de Servicios de Facturación, para lo cual nos tenemos que registrar y obtener un permiso, también solicitando un DIRe, con nuestro certificado, y rellenando un cuestionario... entonces, si nos aceptan, apareceremos en su bonito listado de ESF asociadas al FACEB2B. A partir de ahí, las empresas que tengan plataformas como el FACEB2B (voxtel, ingram, edicom...), están obligadas a comunicarse entre ellas (incluido el FACEB2B) para suministrar al consumidor final una factura en formato electrónico standard, cuando éste lo solicite... y si terceras plataformas incorporan facturas electrónicas de otros clientes, también están obligados a comunicarse con el FaceB2B para que los receptores puedan solicitar sus facturas a través de este único canal....

Imaginaros si para consultar las facturas de un proveedor tuviéramos que ir mendigando en todas las plataformas a ver si hay algo para mí !!!

Espero no estar equivocado, por lo que les pido que si alguien consigue darse de alta como ESF exponga su experiencia y confirme la metodología que he expuesto... estamos saturados de trabajo y nos queda unas semanas para que nosotros podamos abordar este tema.

WEBINAR: Factura electrónica obligatoria
 

Hola dejo enlace de webinar donde explican un poco el tema de la facturación electronica,
realizado por EDICOM, en colaboración con el Ministerio de Asuntos Económicos y Transformación Digital,
es un poco simple y aburrido pero adelanta como será el tema de las plataformas.
https://www.youtube.com/watch?v=YOuCOu2URTM

Muy interesante.

En el minuto 16:20 habla de comunicar los "Estado de la Factura", para mí ha sido una novedad.

Muchas Gracias

Gracias a ti compañero por la info. ^\||/

Pues eso pensaba yo también, he dejado un enlace a webinar que te puede ser interesante, donde explican un poco lo que nos viene.
espero que al final los precios sean económicos o estén subvencionados o terminen poniendo una plataforma gratuita.

Ok, le echare un vistazo cuando pueda, gracias por la info.

Alguna novedad con la publicación del reglamento?