Facturas electrónicas [España]

[nincillo]

Empezado por newtron

Buenas.

Yo creo que el certificado da igual, la diferencia es atacar a las urls de prueba o a las de producción.

Saludos.

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

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