Hola a todos.
Sería bueno que no mezclemos temas dentro de un hilo de discusión (en este caso facturae dentro de este hilo de LeyAntifraude).

Más que nada porque ya llevamos 30 páginas de mensajes y me consta que luego cuando los usuarios quieren buscar información les cuesta y se pierden. Más aun si además les liamos con temas similares y con mensajes que son de otro tema.

Hay varios hilos de Facturae y si es necesario creamos otro, pero os pediría que me ayudarais en mantener este hilo un poco "organizado" ;)

Gracias por todos vuestros los aportes y por vuestra colaboración en esto. ^\||/

Ya tenemos los diseños de registro de alta/anulación en formato Excel, en la documentación de desarrolladores de la AEAT
**EDITO*** Ya veo que están en la primera página :o

Vale, pues listo.

1) He movido los mensajes de este hilo referentes a Facturae a otro hilo específico del tema:
https://www.clubdelphi.com/foros/sho...d.php?p=498479

2) El otio hilo lo he dejado "fijado" en el mismo foro que estos de "LeyAntifraude" y "TicketBAI" para que sea fácil acceder a él.

3) Al inicio del hilo he añaddo una pequeña explicación y links a otros mensajes que van sobre el mismo tema.

A los que os interese podéis suscribiros a ese hilo sobre Facturae, para empezar a recibir notificaciones y si la creciendo intentaremos hacer lo mismo que en este; Ir añadiendo en el primer mensaje los enlaces de interés y "cosas importantes" para que sea más fácil encontrarlas.

Gracias a todos por la comprensión/colaboración.

Hola a todos. En la página web de desarrolladores de la AEAT https://www.agenciatributaria.es/AEA...olladores.html convocan a una reunión para presentar novedades, No creo que desarrollen mucho ya que para este tema le reservan 10 minutos.


11:35 – 11:45 h. Estado del Proyecto Sistemas Informáticos de Facturación
Virgilio Postigo Cubo
S.G. Adjunto de Declaraciones Fiscales e Informativas - S.G. de Aplicaciones

Gracias keys

Gracias por el aviso.

Al final dice que las novedades se publicarán en la página de desarrolladores (para los que no puedan asistir):
https://www.agenciatributaria.es/AEA...olladores.html
Y si hay algo interesante los que podáis (o podamos) asistir ya lo comentaremos por aqui.

Un saludo.

A mi me gustaría preguntar sobre la factura electronica, Ya que sobre verifactu ya más o menos sabemos de qué va, factura electronica:
¿Se va a estar obligados a emitir una factura electrónica en el formato que solicite el cliente o habrá un formato común? Y si es común será una contin7acion de verifactu o un formato facturae?. Casi seguro no podré asistir pero agradecería que alguno formule la pregunta. Saludos y gracias

Gracias por avisar!

Ala, jajajaja sincronizacion
https://www.groupseres.com/webinar-l...ource=hs_email

Ya sabes, los informáticos tenemos el don de la ubicuidad :D

Video explicativo de obligaciones factura electrónica en la nueva ley,:https://r.news.b2brouter.net/mk/cl/f...sgxI1iIaJhgmPM

Si llevan razón no tiene mucho sentido dedicarle tiempo a fsce ni faceb2b

Hola a todos.

En la reunión no han comentado nada nuevo. Se ha limitado a poner una serie de diapositivas sobre lo que ya sabemos todos y se ha comentado en este foro. Han comentado que esperan que la ley salga el mes de noviembre o de diciembre 0 ...........:D

En breve pondrán toda la presentación en la pagina web de desarrolladores.

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

Gracias por la información de que no hay información nueva. ;):D:D

Efectivamente.

Para los que no han perdido el tiempo como nosotros :confused:... cuando cuelguen el vídeo empezad a echarle un vistazo los últimos 15 minutos.

Se han pegado un tostón de 1:45h explicando mejoras de modelos informativos que no tienen nada que ver con Verifactu, FacturaE, etc.

El chat estaba calentito con la ley crea y crece, y antifraude... pero no han publicado respuestas claro.

Primero disculpas si no es el lugar adecuado, espero lo mueva el moderador.

Información relativa al kit digital.

¿Vale la pena entrar en el tema?
¿Nos podemos encontrar problemas para cobrar nuestro trabajo?, ¿o es el cliente quien tiene que lidiar con la administración?.

Pros y contras.

Saludos.

Yo sí crearía otro tema para KIT DIGITAL.
Creo que no temnemos ninguno para ello. Si lo haces ya elimino yo este de aquí, si a ti no te deja.

Se ha publicado el PDF con el resumen del seminario del 25/10/22 (como dijo "Keys" nada nuevo a destacar para el tema de VERI*FACTU):

https://www.agenciatributaria.es/sta...tubre_2022.pdf

Bueno, al menos entiendo que VeriFactu, que es a lo que yo me refería con la "nueva factura electrónica" que entrará en vigor en 2023-2024-2025, es como el TicketBAI para toda España, con su CódigoQR, etc. ¿Es así?

Todavía no he empezado a leer la documentación y no sí si ya hay entorno de pruebas, etc. porque cuando lo anunciaron estaba bastante agobiado ya con TicketBAI como para meterme con otra cosa, pero si me confirmas que efectivamente es muy parecido a TicketBAI, entonces me relajo un poco más :)

Si, por lo que sabemos hasta ahora (en líneas generales) VeriFactu será similar a TicketBAI.

Aún no han publicado el entorno de pruebas, por ahora tenemos esto https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Buenas...

He importado el WSDL publicado en la documentación de Verifactu (//prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SistemaFacturacion.wsdl) en Delphi, pero no puedo compilar porque en el archivo SistemaFacturacion.pas generado hay strings de más de 255 caracteres.

Supongo que tiene fácil solución, pero quería saber si es que se ha importado mal o incluso si merece la pena empezar a hacer ya algo de desarrollo o es mejor esperar.

Por lo que veo, está publicado el wsdl para poder generar el XML, así como el diseño de alta y anulación.
Lo que no veo son las URLs de envío para el alta y anulación de facturas, e información técnica para generar el QR, etc. como sí había para el TicketBAI.

¿O es que sigue todo muy verde aún?

Gracias

De momento todod esta muy verde. No hay servidores ni nada solo los ficheros.

Gracias, Keys.

Tengo un cliente que me acaba de decir que su asesor contable le ha pedido ya todas las facturas "para empezar a subir los ficheros a Hacienda" por la entrada en vigor de VeriFactu y la Ley Antifraude, y ya no sé cual de los tres está más loco, si yo, mi cliente o su contable.

Pero si no hay ni dónde subirlas... :eek::eek::eek::D:D:D

Yo creo que las va a "subir" a lo alto de la estantería. :D:D:D

Edito: Pero que yo me entere.... ¿este hilo es de Facturas electrónicas o de Verifactu?

No me he dado cuenta, tienes razón.
Hilo equivocado.

Yo sigo sin entender la diferencia, la verdad.

Facturas electrónicas: facturae, face, sii o incluso un pdf firmado con certificado, si nos ponemos técnicos...
Verifactu: Evolución de la Ley Antifraude: Impresión de QR en ticket/factura + envío a Hacienda (aún sin urls de envío ni entorno de pruebas). Muy similar (presumiblemente) a TicketBAI.

He leído en algunos artículos que he encontrado online (suelen ser blogs de asesorías fiscales o de empresas de software) que Canarias y País Vasco estarán excluidas (entiendo que lo esté País Vasco porque ya tienen TicketBAI, pero Canarias?). Sin embargo no he encontrado nada oficial que indique eso.
También hay un lío de fechas para la entrada en vigor.

Incluso tengo amigos en otras empresas de software que dicen que debe ser la empresa de software de facturación la que suba a un espacio web propio todas las facturas para que los clientes puedan leerlas.

Ya me estoy volviendo medio loco...

La LeyAntifraude lo que hace es asegurar que una vez generada la factura se guarda de forma que no se pueda modificar (de ahí los temas de firma, encadenamiento,...).
Inicialmente hay 2 opciones o formas de trabajar para las faturas:

• Veri*Factu OFF, que significa que las faturas NO se envían, las guardarlas tú, hasta que hacienda te las requiera, si es necesario. En este caso te puede solicitar, por ejemplo, "las facturas de 1 mes" y habrá que ver cómo se las tienes que dar.
• Veri*Factu ON, que significa que (de forma similar a como se hace en TBAI) las facturas se deben enviar a hacienda inmediatamente después de generarlas.

Lo normal es que más adelante, la opción 2 (envío inmediato) sea la obligatoria, pero haciendo así, simplificas inicialmente el desarrollo (sepuede hacer en 2 fases), escalas la puesta en marcha (no todos optarán por la opción 2 inicialmente), das más tiempo a las empresas a implementar el segundo (que es más complejo),...



Que debas almacenarlas tú si, que debas implementar los mecanismos para que el cliente pueda leerlas no lo he leído ni visto en ningún sitio. No tiene sentido. Para eso, activa Veri*factu (es decir, envíaselas a hacienda) y ellos se encargan de eso.

Disculpa, pero sigo sin entender esta parte. ¿A quién te refieres con que tengo que almacenarlas "yo"? Supongo que te refieres al cliente (usuario del software), no yo como empresa desarrolladora del software.

Perdona, pero entre "cliente", "cliente final" y "nosotros" como empresa de software no entendí bien lo que quieres decir.

Perdón, me refiero al poseedor del software, al cliente.
La empresa desarrolladora no tiene que almacenar facturas de sus clientes. Sólo nos faltaba eso... :eek::eek::D

Hola, ya puse el xsd y algun ejemplo de xml.
De hecho ya he enviado al correo de verifactu 7 facturas encadenadas de distintos tipos y me han contestado, tenía un fallo en un campo en las recapitulativas, por lo demás me han dado el "ok".me han dicho que los encadenamientos oks etc.. que aparentemente todo ok por que aún no hacen la comprobación exhaustiva. Ya queda en ti lo que quieras adelantar, pero yo prácticamente ya tengo verifactu preparado a falta del QR y de la url de envío.

Duda Anulación
 

Hola de nuevo, en los ejemplos que he enviado a Verifactu e incluido 1 anulación y me han hecho la picha un lio o se la han hecho ellos, yo pienso que como aún no ienen moontado el sistema de comprobaciones lo han hecho a mano y se han podido liar.
Explico a ver que pensais:

1. Emito 1 factura simplificada.
2. Emito 1 factura recapitulativa de esa simplificada(con los datos del cliente)
3. Me doy cuenta, antes de darsela al cliente, que me he equivocado de cliente.
4. Anulo LA RECAPITULATIVA.
5. Vuelvo a emitir recapitulativa, con el siguiente número dde serie de las recapitulativas, de la factura simplificada del paso 1.

Ellos me dicen que los encadenamientos ok y tal pero me dan una advertencia:

(ESO YA LO SÉ)
Claro, ahora estoy liado, si le hago caso al mensaje, tendria que hacer una ¿RECTIFICATIVA DE UNA RECAPITULATIVA? por datoss del cliente incorrecto, que cosa mas rara.
¿Que pensais?, ¿es un error de ellos o mio?

Saludos

Si no me equivoco el software tiene que estar preparado para el envío envíes o no precisamente para eso, para que si no envías datos y te requieren información puedas enviarla directamente así que al programa le da igual lo que decidas si enviar o no, siempre tendrá que estar preparado para enviar.

Por otro lado también creo que las empresas que están en el SII están exentas de este rollo del verifactu.

Saludos.

Ya me has perdido a mí. Este hilo es de VeriFactu. La nota/broma de @espinete hacía referencia explicita a VeriFactu. No me parece que haya de momento posibilidad de subir facturas a VeriFactu (aparte del entorno de pruebas de la versión 0.1, que para nada tiene que interesar a un asesor fiscal), así que tu reacción me parece de lo más legitimo.

¿Dónde piensas está la equivocación?

Es hilo es efectívamente de LeyAntifraude/Veri*factu.

Ahora en ningún sitio, porque ya he movido el mensaje.
Inicialmente este mensaje estaba en el hilo de Factura electrónica, por eso el comentario.

Lo veo de manera distinta, visto desde una empresa que opera. Creo que las dos opciones están por quedarse tiempo. Las grandes empresas con desarrolladores internos, CPD etc. se van a quedar en opción 1, al mínimo para garantizar el máximo de confidencialidad (caso extremo sería las compañías extranjeras, que puede que no se fíen tanto del Estado español). A no ser que a las pocas años esta opción se esfuma dentro de una opción 0 que no has mencionado: estar acogido al S.I.I., que de lo que hemos leído hasta la fecha ¿permitiría? evitar completamente la obligación de tener un S.I.F. tal como lo define el proyecto de RDL de febrero.

Después de leeros aquí, tengo más certezas que la mayoría de las PyMEs y la mayoría de los desarrolladores independientes van a ir a por la 2ª, que probablemente es también la opción preferida por Hacienda por el momento (a ver cómo quedará cuando la ley evolucionará más rápidamente que la capacidad de respuesta de los desarrolladores de Veri*factu). Concretamente para un desarrollador, me parece más lógico ir directamente por la opción 2. Y no creo que siga más complejo: cierto que hay que gestionar el envío inmediato y luego dibujar e imprimir el QR en casi tiempo real (con las relaciones que implican con el hardware); pero Hacienda está equilibrando las cosas en no reclamar en copión 2 firmar todos los registros en el momento de emitir la factura (también en casi tiempo real, y no sabemos exactamente los requisitos para el sellado de tiempo que va detrás); y creo que el esfuerzo de desarrollo es comparable. Además los que ya han pagado el peaje TBAI llevan cierta ventaja.

Aquí si creo que tus amigos se han equivocado de hilo. Lo de subir las facturas a algún espacio web privado tiene sentido para la casuística de las facturas electrónicas (para que los pobres clientes finales sin recursos pueden leerlas), pero no veo por ningún lado dónde esto tiene que algo que ver con el tema Veri*factu y tener un sistema informático de facturación conforme a intentos de fraude, dónde a todas luces sería justificado utilizar un espacio web público (como TBAI o VeriFactu).

Correcto, la opción 2 es la más viable para las empor3sas grandes, no veo que de confidencialidad puede haber en enviar las bases e impuestos, de todas formas hay que hacerlo, si no por un lado por otro. Sobre todo en empresas que tengan franquicias, piensa que la central de franquicias quiere el mínimo de problemas en la gestión de datos de sus franquiciados que suelen usar los softwares impuestos por el franquiciador y ante requerimientos posteriores de hacienda por estar acogido a la opción 1 se puede complicar. Con la opción 2 puedes tener complicaciones en el desarrollo pero una vez corregido los bugs te quitas de problemas.
Por otro lado las firmas con certificados(opcion 1) tb tiene la complejidad del mantenimiento de dichos certificados. Y para la opción 2, como lucho te pedirán el certificado para pedir la @clave o para enviar con dicho certificado, q7e si te caduca te devolverá un error y se queda en cola hasta que cambies/renueves el certificado, que xomo he dicho si tienes que firmar con certificado en el instante de emitir el tiquet para hacer el encadenamiento puedes tener un gran problema.

Creo que hay cosas distintas, que no se debe confundir (y hablo en general, creo que @ermendalenda lo tiene claro).
Una cosa es un registro de anulación, dentro del S.I.F.
Otra cosa son cancelaciones de facturas, es decir entidades (líneas del SGBDR si se prefiere) de la tabla Facturas que van en sentido contrario, para cancelar una factura anterior.

El primero se da si tu empiezas a emitir una factura (entonces por ejemplo le das un número), luego te das cuenta que hay algún problema, normalmente de índole informático, y no se debe tener en cuenta lo ocurrido. Entonces si ya has grabado el registro en el SIF, debes marcarlo como Deleted. Esto se hace con un registro de anulación. Todo ocurre como si dicha factura no ha existido nunca (pero el número está quemado).

El segundo se da cuando hay una razón de negocio para cancelar una factura. Debe tener un efecto contable, en sentido contrario a las factura que cancela. Esta cancelación se debe informar con un registro de alta. Y también tendrá su proprio número de factura.

Ahora bien, en el 4º de la lista arriba, pueden darse cualquiera de los dos casos. La diferencia realmente es si la factura emitida en 2 ha sido registrada formalmente en sistemas externos al S.I.F., o se ha quedado «estancada» dentro del propio SIF. Esto solo lo puede saber él que opera el S.I.F. Entonces las dos operativas deben ser aceptadas por el sistema Veri*Factu; y también deben ser contempladas en el sistema; entonces sí, es posible que, dependiendo de la operativa y visto el marco del reglamento de facturación, se pueden dar el caso de «rectificativas de recapitulativas».
Solo que no es el caso aquí (si sigo el ejemplo descrito). Y esto no lo puede determinar Hacienda.
En cualquier caso, no creo que haya error tuyo.
Entonces la advertencia, aunque entiendo la intención (advertir de la 2ª opción), me parece mal formulada para no decir un poco engañosa, al insinuar que la anulación en 4 no procede.
Creo que valdría la pena alzar el caso a los de Hacienda, a ver si pueden mejorar el mensaje.

Otra posibilidad sería de obligar a documentar un poco las razones para anular un registro (añadiendo a las especificaciones; un trabajo para Hacienda); si los casos contemplados son suficientemente estrechos, quedaría claro a los desarrolladores que los registros de anulación no sirven para cancelaciones de facturas, y no haría falta emitir ¡ninguna advertencia! Ahora bien, este es ¡mi opinión! :cool: