|
Cita:
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 |
Cita:
|
Cita:
|
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? |
Cita:
En la practica veo dos maneras de hacerlo:
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... |
Cita:
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 |
Cita:
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. |
Cita:
Cita:
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 |
Cita:
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 : Cita:
|
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. |
Cita:
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: |
| La franja horaria es GMT +2. Ahora son las 15:44:43. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi