Veri*factu y 'router' para facturae
 

Buenos días,

A ver si me echan una mano de como encarar esta situacicón.

Cliente con SIF adaptado a Veri*factu. Ok

Resulta que de vez en cuando factura al ayuntamiento -->> Facturae por ser organismo oficial.

Pues bien, este señor coge la factura que ha generado con el SIF y la introduce (duplica, toda a mano como un 'excel'/'Olivetti') en un portal que genera factura electrónica y va a parar al ayuntamiento.

Este portal tiene la posibilidad de usar Veri*factu.

¿Cómo gestionarían Ustedes este caso?
Por que entiendo que en enero este portal lo forzará a usar Veri*factu.

¿Podria generar el SIF una proforma y continuar operativamente como hasta ahora?

Yo había pensado y enviar a Veri*factu con series diferentes, unas por el SIF y las otras por el portal de la factura electrónica; y que previamente las del organismo oficial se generaran en el SIF como proformas.

(yo en un mes no me empapo de Facturae y que no falle).

A ver....
El programa gratuito de Facturae aún puedes usarlo y existe un campo donde puedes insertar el texto contenido del QR, que habrás tenido que emitir con un software acorde al reglamento, con lo cual (antes tendrías que asegurarte de que no se considera una doble emisión/expedición quizas usando "Duplicado") lees el código QR con un lector y el texto resultante lo pegas en el campo "Literales legales"(bicheando un poco por las pestañas), pero le tienes que añadir al final esto ---> &formato=json
Con lo cual quedaria algo así:
Https://....ValidarQR?.....importe=200.25&formato=json
Para más solidez, inserta el pdf de la factura con su QR.
Por supuesto tiene que xoincidir todo, productos,importes, cuotas y numero y srrie de factura
Claro ésto es manual, lo apropiado es que tengas un SIF que te genere el xml de Facturae.

Hola, imagino que el cliente el SIF que usa no puede generar el xml de la factura para firmarla y luego subirla por el portal Face, ¿verdad?
Yo tengo un cliente que le ocurre lo mismo, antes de activar el verifactu, generaba la factura y luego la subía con el facturae. Ahora tendrá que hacer lo que te comento, genera el xml y firmado lo sube al portal.
En eso no creo que sea problema, por que todo lo esta generando ya tu SIF, también incluye un adjunto en pdf con la factura y el QR.
Un saludo.

Como bien dices el portal "tiene la posibilidad".
Es posible que el envío se pueda configurar, deberías preguntarlo.
Hay situaciones en las que 2 programas interactúan y sólo uno de ellos debe enviar a veri*factu.

El QR no vale solo en wl PDF, tal y como indica el reglanento hay que incluir el texto con el parametro json para las facturas electrónicas.

Hola, garcías, viendo como lo exporta el facturae y buscando en las pestañas he encontrado que añade esto:
Entiendo entonces, que si al xml firmado que se genera desde el SIF, se le añade esto, ya se podría subir al face sin problemas, o tendría que añadir algo más.

Muchas gracias.

Claro, entiendo que te refieres al xml firmado en formato Facturae y no al de Verifactu, y teniendo en cuenta lo que hemos hablado, hay que subirla/conservarla en el formato verifactu por un lado y a face por otro, teniendo que coincidir en el contenido con lo que generas...


Puedes elegir meterlo en el nodo de LegalRerence como has puesto o de esta otra forma:

Incluso estoy pensando meterlo en los 2, dado como actuan los organismos y cada uno lo va a pedir de una forma u otra y te quitas que te la pidan de nuevo.

Hola, como siempre, gracias.
Imagino que el del verifactu, te refieres al que se manda al sistema con todo los datos del registro de facturación.

Lo que quiero es, desde mi SIF, que el cliente genere y firme el XML y ese XML firmado lo suba el cliente al Face, con eso ya no tendría que importar la factura en el facturae o que el cliente metiera a mano esa factura de nueva en el facturae.
Entonces, mi duda es esa, si añado a ese XML, lo que me comentas, no me importa añadir las dos cosas que me comentas, ¿ya sería correcta para poder subir al face o tengo que informar de algún dato más?

No se si tengo que añadir algo más.
Muchas gracias.

Sí, estaría completo, pero te aconsejo la primera opción si puedes lo mejor por supuesto para evitar errores:
Generar el xml (facturae) a la par del xml de Verifactu, con eso no tienes que poner duplicado ni historias, e incluyendole los nodos que te comento, y sin problema que lo firmen y/o envien posteriormente. Ya si va firnado desde tu SIF por supuesto mejor,

Hola, no me acabo de aclarar, no se si lo que tengo que añadir es al formato xml del facturae el xml que he generado con el verifactu añadiendo lo que me comentas o simplemente al xml en formato facturae le puedo añadir directamente los dos nuevos nodos como me dices.

Luego, le pregunto al chatgpt y me dice que tengo que usar un nodo que sea como este:
Menudo lio, gracias.

Vaya por delante mi agradecimiento, este foro es una joya.

A ver que me hago la pE&/a un lío.

Entiendo que:
1-debo generar el XML de Veri*factu; en ese momento obtengo la huella y el QR.
2-debo generar el XML del formato Facturae y añadirle a este XML el nodo de... '<AdditionalData>' ? El de '<LegalLiterals>' ? Ambos?
3-Enviar cada uno donde corresponda.

Jjaja, chatgpt tiene un lio temendo y te entremezcla UBL, FACE, VERIFACTU... y cuando piensas que esta bien la ha liado con los prefijos, cabeceras...ni lo intentes.


Basta con añadirle al xml de facturae los 2 nodos que te comento, pero si adicionalmente le quieres añadir el pdf o xml de verifactu se lo puedes añadir, pero como adjunto.

1.Correcto
2, Correcta cualquiera de las 3 opciones
3 Correcto,

Nota: La huella no hay que añadirla a la factura electronica, solo el QR

Ok, muchas gracias.

Perfecto, muchas gracias.

Hay que ver el lado positivo, tengo el 50% desarrollado y funcionando (Veri*factu y su envío); y lo que es más importante plan B para el otro 50% (1).

>>Nota: La huella no hay que añadirla a la factura electronica, solo el QR
Si, si. Esto lo tenia claro, la huella 'interviene' en el QR y en Veri*factu.

(1) Tendré un numerador para proformas para Organismos Oficiales y se emitirá proforma desde el SIF, nunca factura; y en el portal www se emitirá la factura electrónica (con otra serie). Me dará respiro para mirarme Facturae.

Pues bien, suerte

Nada, la primera consulta es gratis.
:D

Buenas, ayer hice la consulta para ver lo que dicen los del verifactu y esta fue la respuesta:
Buenos días:

En el caso de las facturas electrónicas que se emiten a la Administración Pública, el procedimiento continúa siendo el mismo, es decir, deben emitirse en formato Facturae y enviarse a través del punto general de entrada FACE, conforme a la normativa vigente de contratación pública.

No obstante, cuando entre en vigor la obligación del sistema VERI*FACTU, el registro de facturación correspondiente a esa factura también deberá generarse en su sistema de facturación (o en la aplicación gratuita de la AEAT, si opta por utilizarla), para su remisión a la AEAT, de acuerdo con lo previsto en el Reglamento de Requisitos de los Sistemas Informáticos de Facturación (RRSIF).

Por tanto:

· Deberá seguir remitiendo la factura electrónica en formato Facturae por FACE, como hasta ahora.

· Además, deberá generar y remitir el registro de facturación VERI*FACTU a la AEAT.

· La factura no se envía desde la AEAT al cliente o destinatario, sino que la AEAT únicamente recibe y registra la información del registro de facturación.


En resumen, el envío a FACE y la generación del registro VERI*FACTU son obligaciones complementarias y compatibles, cada una con su finalidad específica. No obstante, una vez se publique el reglamento del futuro proyecto de factura electrónica obligatoria (B2B) se espera que la aplicación de facturación de la AEAT incorpore nuevas funcionalidades para adaptarse a este nuevo reglamento.

Haremos lo que dice ermendalenda, añadir esa información al XML en formato FACE para que no pongan ningún impedimento.

Tiene sentido. Una cosa es la factura electrónica y otra es VeriFactu. De hecho VeriFactu no incluye las líneas de la factura (los conceptos, productos, etc.), solo el total, el emisor y el receptor.

Sin embargo FacturaE sí es una factura electrónica "per se", con todos los datos, conceptos, líneas, precios, etc. así que ambas cosas no pueden ser excluyentes.

Si, si. Todo esto lo tengo muy claro.

Pero el caso es:
- cliente que usa un SIF para generar sus facturas y enviar a Veri*factu.
- además, usa un portal (p.e. b2brouter) para generar y enviar la factura electrónica (sólo las que son para organismos oficiales); y este portal tiene la posibilidad (que en enero quizás sea una obligación) de enviar a Veri*factu.

La cuestión es como compatibilizar estos 2 'entornos'.

Ya por fin no estoy solo con esto de Efactura vs Verifactu
Paralelamente les estoy enviando incompatibilidades y con suerte algunas cositas allanarán el camino

Nosotros tenemos numerosos clientes que envían las facturas desde hace varios años a organismos oficiales a través del portal FACE. Pero entiendo que eso es un añadido. Nuestros clientes tienen que enviar ahora todas las facturas de venta a la AEAT (Verifactu) sean o no expedidas a organismos oficiales. Y además, las que sean de organismos oficiales, tendrán que enviarlas también por FACE. Yo creo que una cosa no quita la otra. Quizá tu programa debería que tener la posibilidad de crear esa factura en formato FACTURAE para facilitarle la vida al cliente y que no la tenga que crear a mano. Es decir, no por tener que enviar por FACE una factura van a tener que dejar de enviarla a la AEAT. Creo que es esto lo que planteas. Es más, nuestros clientes de Ticketbai hacen exactamente eso. Envian todas las facturas a la agencia vasca correspondiente, y además, si es para organismo oficial, pues a traves de FACE o del portal que sea.

Si, si. Mi programa debería generar Facturae pero no lo hace y como sólo tengo 33 días, pues estoy buscando una alternativa mientras desarrollo Facturae.

Justo, nosotros igual, son cosas independientes, al que le toque enviara a VeriFactu (si no esta en el SII) y tambien las facturas que corresponda al FACE.

Importante, que me olvidaba.
Si no quereis tener algún problema con el xml de Facturae al agregar el QR, teneis que ponerlo en codigo URI,
teneis que cambiar:
Si teneis algún caracter más de los traducibles a uri, pues lo mismo.

Buff, lo del facturae ni lo estamos mirando, tenemos lo que en su día hacía falta y actualmente funciona. Esto que comentas de agregar el QR :confused: , pero me anoto lo del código URI para al que le toque ponerse con ello lo tenga en cuenta. Graciassss.

Aclaro una cosa de Face.
Si un O.T. hace todo manual o no está obligado a hacer facturas por el regimen que le toca, pero tambien emite por Face (ejemplo un jardinero) no tiene que emitir a la vez esa factura de Face a Verifactu, Face no implica una obligaciom addixional al reglamento.
Pero no confundsmos, si un emisor hace facturas por SIF no puede hacer parte manualmente, ni basta con enviarla a Face.

Un emisor no puede tener una serie de facturas en un SIF=>Veri*factu, y otra manual (no afectada Veri*factu)?

Me temo que no, eso le han contestado a un asesor.
Cada dia nuevas restricciones conocidas

No entiendo bien, en una empresa se puede tener una serie que envia a VeriFactu y otra serie excluida. Nosotros tenemos asi clientes porque la serie excluida son facturas que mandan desde otro software, solo quieren contabilizarlas, eso ya lo pregunte en su día y nos respondieron que era correcto.

Bueno, no lo has entendido bien no, no habla de un SIF en concreto, habla de que si emites facturas y envias 1 a Verifactu ya todas tienene que estar por el reglamento, Verifactu o No-Verifactu, da igual que lo hagas por un SIF o 20.000 SIF's, la otra cuestión a la que te refieres es otra duda planteada sobre la importación de facturas de un SIF a otro SIF,


Pero a mi si se me plantean otras dudas:
En el párrafo que he puesto hablan de si una actividad está haciendolo por un SIF todos están sujetos al reglamento, con lo cual ahora me rompe ciertos esquemas de lógica y me llena de ambiguedades:
1. Una autónomo con 2 actividades, una en R.E. y otra en Regimen Normal (01). La de régimen normal usa un SIF, entonces obliga a la otra actividad a hacerlo?
2.Un autónomo emite recibos(numerados) en una libreta a mano y cuando le piden una factura la mete en el SIF de la web. ¿que pasa ahora con los recibos? se pueden considerar facturas simplificadas manuales y ahora tiene que tener un SIF?.

Nota:
Joder, no hay párrafo, juraria que he subido una imagen, a ver donde la he subido...

Lo pongo de nuevo, a ver ahora,
Parte de la Contestacion a un asesor sibre face vs verifactu

Nosotros tenemos clientes que emiten sus facturas normales por una serie concreta y envían a Verifactu, hasta ahí Ok. Pero luego hay alguno que tiene algún cliente que le hace autofactura. Para que nuestro cliente pueda contabilizar esa factura le habilitamos una serie para "Autofacturas Recibidas" donde ahí no hace ningún tipo de envío y además la puede modificar, ya que en ese caso concreto la responsabilidad de remisión, custodia e inalterabilidad recae sobre el destinatario. ¿Estamos haciéndolo mal?

Hola, cuando dices "destinatario" supongo que te refieres al que la emite, no?
En ese caso entiendo que hay 2 responsabilidades, tu cliente no queda exento de que se haga bien o mal, la que hace el envio/emite la autofactura tiene la responsabilidad de cumplir con los requisitos tecnicos, sí, pero la responsabilidad de que esa factura cunpla con el resto
Que se emita y realmente cumpla con verifactu también es responsabilidad de tú cliente
Que sea correcta respecto a ROF,LIVA, el iva bien aplicado, fechas.. etc...

Que en el software haya una serie especifica de autofacturas emitidas por otro a nombre de tu cliente, la lógica me lleva a que no debe haber problema, pero pueden haber particularidades que conviene preguntar:
-puedes reimprimirla desde tu software? generando el documento desde el mismo, dandole formato de factura? Creo que no otra cosa es que guardes el pdf o documento y muestres eso.
-identificar claramente las series, por que no se en que te afecta la parte del reglamento que dice que ante una inspeccion le muestres solo los datos afectados tributariamente, con lo cual una buena explicacion que no deje lugar a dudas dn la aplicacion..