Asunción de responsabilidades

[Decanato]

Buenos días a todos, soy muy nuevo en el foro y quiero aprovechar para saludaros a todos y felicitaros (y agradeceros) la gran dedicación y aportes que realizáis y que sirven de enorme ayuda. Sé perfectamente lo justos que solemos ir de tiempo y el hecho de que dediquéis parte del vuestro en este foro que tanta luz arroja sobre los temas que nos afectan. Yo programo en VB Net, y en la medida de lo posible intentaré aportar mi granito de arena en lo que pueda.

Aprovecho este hilo para lanzar una reflexión que llevo rondando después de leerme las 174 páginas del hilo general VeriFactu... He podido comprobar que en ese hilo se ha tratado hasta la extenuación (y es de agradecer porque me ha aclarado muchas dudas) los aspectos de la causística de cada tipo de factura, de cuándo se tiene que utilizar una u otra, de cuándo se debe hacer una anulación, cuando una rectificativa por diferencia o por sustitución... Y efectivamente es para preocuparse desde el punto de vista de que imagino que lo hacemos desde la base de saber con lo variopintos de nuestros clientes y temiendo que "metan la pata"... A mi también me entraron sudores a medida que leía el hilo, la verdad, pero he llegado a la conclusión de que quizás, e igual me equivoco, pretendemos asumir unas competencias y responsabilidades que no nos corresponden, y que tendrían que corresponder al asesor fiscal de cada uno de nuestros clientes, y a los que sin darnos cuenta casi estamos eximiendo de sus responsabilidades, por las que cobran y nosotros no...

A donde quiero llegar es que yo no me puedo plantear "enseñar a facturar o a interpretar el reglamento" a mis clientes, para eso y para cada caso que se les presente tendrán el consejo de su asesor... Mi cometido (y responsabilidad) debe ser que en el programa pueda hacer cada cosa que dice el reglamento, pero no me puedo responsabilizar de que en lugar de una anulación haga una rectificativa, y así se lo voy a trasladar a mis clientes... Me centraré en que puedan hacer las cosas y que se comunique con la AEAT de forma correcta y que si no se comunica sepan qué hacer en el programa para esas salvedades, y lo pondré lo más cómodo posible y ágil que pueda, pero sin intentar guiarlos a caminos concretos que no me corresponden, porque además entiendo que si así lo hiciese si que estoy asumiendo la responsabilidad de los errores del reglamento en los que puedan incurrir.

En fin, para ser mi primer mensaje os he metido un buen ladrillo, pero bueno, era una reflexión que quería hacer. Encantado de compartir espacio virtual y a vuestra disposición para lo que esté en mi mano.

[Casimiro Noteví]

[dec]

Hola a todos,

Empezado por Decanato

A donde quiero llegar es que yo no me puedo plantear "enseñar a facturar o a interpretar el reglamento" a mis clientes, para eso y para cada caso que se les presente tendrán el consejo de su asesor...

Primero que todo, ¡bienvenido!

Sobre lo que has comentado, me parece que llevas no poca razón, si bien he citado lo anterior, porque, se me ocurre, que, tal vez un programa puede tal vez ir más allá de hacer "lo necesario", siempre como una característica del programa y con el coste oportuno, por supuesto.

Yo soy autónomo y utilizo desde el principio la aplicación que ofrece Cuentica, que, me permito enlazar, porque, lo digo muy sinceramente, me parece una aplicación extraordinaria, con un coste asumible, y que, me ofrece todo lo necesario para desarrollar mi actividad sin demasiadas dificultadas.

Después de la publicidad (que no lo es, o sea, yo sólo soy un cliente contento con Cuentica), el caso es que una aplicación así viene a este hilo, como veremos ahora. Esta aplicación ofrece varias modalidades de uso. Una de ellas es "la simple facturación" y un buen número de otras cosas, como, la creación de archivos que nos sirven / ayudan para presentar los modelos necesarios con los datos requeridos ante Hacienda.

Pues bien, el caso es que, como digo, esta aplicación ofrece también un servicio de asesoría legal, es decir, detrás del software hay también asesores, que, pueden resolver nuestras dudas, aconsejarnos, etc., etc. Por supuesto, huelga decir que esto implica un coste: uno paga por Cuentica o por Cuentica +asesoramiento, etc., etc. Uno paga según lo que necesite en un momento dado.

Lo dicho hasta ahora implica que nosotros siempre podemos hacer algo parecido, siempre que nos sea posible, y, como servicio de valor añadido para nuestros clientes: lo dicho, habrá entonces la posibilidad de clientes que sólo quieran una determinada parte del programa o que quieran además asesoramiento legal, etc., por supuesto, siempre que nosotros podamos y queramos ofrecer dichos servicios añadidos.

Pero... ahora es cuando llego a lo que realmente quería decir. Siendo cierto que nuestro software puede limitarse a "dejar hacer cosas", siempre se pueden hacer cosas tal que comprobaciones que se puedan realizar con los datos que se tienen. Qué sé yo, por poner el ejemplo más básico que se me ocurre, nuestro software puede ofrecer la "gestión de clientes", con el fin de que nuestro cliente, cuando quiera hacer una factura, no tenga que indicar los datos de un cliente una y otra vez.

Lo anterior suena muy simple y sencillo y nuestro software probablemente ya implemente algo así, pero, lo que quiero decir es que eso es sólo un ejemplo de "añadido". La idea es que un software puede ser "mejor que otro" si dicho software es capaz de decirle al cliente, por ejemplo, cuando detecte que se está haciendo una factura para un cliente en Canarias, que, dicha factura no lleva "IVA", sino que lleva o puede llevar otro tipo de impuesto, etc.

Y el etcétera es tan largo como se nos pueda ocurrir. Yo lo que espero es que se entienda lo que trato de transmitir. Que, si bien es cierto que nuestro software "hace facturas", lo cierto es que, dado que tiene acceso a multitud de datos y "sabe" no pocas cosas, puede ofrecer mucho más valor utilizando ese conocimiento y esos datos, puede ir mucho más allá de hacer facturas, incluso sin entrar en lo que se trataría ya de un asesoramiento legal puro y duro.

O sea, estoy hablando de que el software sea tan "inteligente" como sea posible, sin asumir ninguna responsabilidad legal por nuestra parte. El software acaso permita hacer cosas mal, si el cliente se empeña en ello... pero, hasta donde sea posible, yo consideraría un software más inteligente si al menos es capaz de decirle al cliente: "Oiga, esto que está usted haciendo no es del todo correcto, ¿está usted seguro de continuar? Sino está seguro, por favor, consulte a su / nuestro asesor..."...

[CarlosR]

Se ha tratado hasta la saciedad el tema verifactu, eso es cierto. Pero personalmente y a estas alturas todavía me quedan algunas dudas (todas relacionadas con solo verifactu) :


- Qué hacer cuando se rompa la cadena de verifactu ? Puede darse el caso de un error de programación,
de comunicación remota, de caida del sistema, etc. Se deberia generar un evento indicándolo pero no
pueden dejar de vender y cerrar la puerta hasta que un informático les atienda. Aunque se les avise a todos.

- Varias empresas están acogidas al SIF verifactu y son de los mismos propietarios, todas centralizadas
en un equipo común. Deben tener distinto código de instalación ?

- En verifactu, pueden pedir la remisión de registros por un requerimiento ? Pueden pedir la remisión
de eventos ? Debe haber un sistema de exportación de registros del sif de forma local ante una
inspección ?

- Hay que dar de baja las facturas inventadas remitidas en prueba ? Cómo consigo yo los códigos y series
de tales facturas para darlas de baja ? (por lo visto lo que hay es que guardar el registro)

- Las prefacturas y las facturas deben tener el mismo número ? Si es así se cargan la factura recapitulativa.
Justamente he creado la prefactura para que mientras no se validan se pueda usar cualquier número y
luego se creen números consecutivos a la hora de validarlas. Preguntas y respuestas, pag. 13


Un saludo a tod@s.

[gcqZW]

Te respondo algunas.

Qué hacer cuando se rompa la cadena de verifactu ?

Incidencia, reúnes todas las facturas que hayas generado mientras no hayas podido enviarlas y en el momento que vuelvas a poder enviar las envías todas en bloque marcando incidencia a "S".

En verifactu, pueden pedir la remisión de registros por un requerimiento ?

No, solo en No Verifactu.

Hay que dar de baja las facturas inventadas remitidas en prueba ? Cómo consigo yo los códigos y series
de tales facturas para darlas de baja ?

No que yo sepa, pero si quisieras podrías hacer una consulta para sacar todas las facturas que hayas mandado de pruebas y generar registros de anulación.

Las otras no lo tengo muy claro sorry.

[Jarogo08]

Empezado por CarlosR

- Qué hacer cuando se rompa la cadena de verifactu ? Puede darse el caso de un error de programación,
de comunicación remota, de caida del sistema, etc. Se deberia generar un evento indicándolo pero no
pueden dejar de vender y cerrar la puerta hasta que un informático les atienda. Aunque se les avise a todos.

No sé a que te refieres a que se rompa la cadena Verifactu. Lo que te contestó gcqZW tienes que hacerlo si las facturas tienen más de 240 segundos (por ejemplo si estuviste sin internet unas horas). Otra cosa es que el encadenamiento entre las facturas esté mal (no sé si eso esa lo que le llamas "romper la cadena Verifactu"). En ese caso tendrías que mandar subsanaciones

Empezado por CarlosR

- Varias empresas están acogidas al SIF verifactu y son de los mismos propietarios, todas centralizadas
en un equipo común. Deben tener distinto código de instalación ?

Si te refieres a que el cliente tiene un único programa instalado pero que admite multiempresa, cada una de esas empresas tiene que tener un número distinto de instalación y por tanto encadenamientos separados

Empezado por CarlosR

- En verifactu, pueden pedir la remisión de registros por un requerimiento ? Pueden pedir la remisión
de eventos ? Debe haber un sistema de exportación de registros del sif de forma local ante una
inspección ?

Como dijo gcqZW, entiendo que eso es solo en modo NO Verifactu

Empezado por CarlosR

- Hay que dar de baja las facturas inventadas remitidas en prueba ? Cómo consigo yo los códigos y series
de tales facturas para darlas de baja ? (por lo visto lo que hay es que guardar el registro)

Tendrás que anularlas. El usuario tendrá que saber si la factura que hizo fue una prueba o fue real (recomiendan usar una serie distinta para las pruebas).

Empezado por CarlosR

- Las prefacturas y las facturas deben tener el mismo número ?

Entiendo que no, o al menos yo no lo hago. La prefactura puede no validarse y por tanto ya tendrás distintos registros en prefacturas y facturas

[CarlosR]

Empezado por Jarogo08

No sé a que te refieres a que se rompa la cadena Verifactu. Lo que te contestó gcqZW tienes que hacerlo si las facturas tienen más de 240 segundos (por ejemplo si estuviste sin internet unas horas). Otra cosa es que el encadenamiento entre las facturas esté mal (no sé si eso esa lo que le llamas "romper la cadena Verifactu"). En ese caso tendrías que mandar subsanaciones

La tabla que contiene los encadenamientos del sif puede sufrir problemas. Por ejemplo de programación. Una ciscunstancia con la que no cuentas y no puede generar bien el encadenamiento. No vas a parar el funcionamiento de la empresa. En este caso queda roto. La AEAT indica que hay que avisar a todas las terminales y que debe estar la cadena bien. Yo pregunto, ¿ en espera del informático ? Imagino que habrá que tirar de eventos voluntarios y justificarlo. Esa era mi duda.


Si te refieres a que el cliente tiene un único programa instalado pero que admite multiempresa, cada una de esas empresas tiene que tener un número distinto de instalación y por tanto encadenamientos separados

Yo entiendo que aquí hay que meter lo que la AEAT llama dispositivo de facturación. La máquina física es la misma, es un dispositivo de facturación. Eso si, los registros de sif deben ser por empresa individuales. Sigo con la duda.


Como dijo gcqZW, entiendo que eso es solo en modo NO Verifactu

En cuanto al registro de eventos y enviar requerimientos son dos matices distintos. Los eventos son de obligado emisión en NO Verifactu y optativos en verifactu. No tengo claro si los requerimientos se harán por parte de la aeat. Entiendo que no, pero no estoy seguro. En cuanto a exportar datos del registro a ficheros externos, legibles y ordenados es algo que no veo muy bien la diferencia entre NO Verifactu y solo verifactu. Yo entiendo que no hay que exportar, pero en la documentación no lo dejan muy claro, es algo ambiguo.


Tendrás que anularlas. El usuario tendrá que saber si la factura que hizo fue una prueba o fue real (recomiendan usar una serie distinta para las pruebas).

Vale, me parece muy bien. Pero, donde consigo la información de todo lo que envié de pruebas ? Aquí se hacen cientos y miles de pruebas, Desde cero, anulando, volviendo a comenzar, facturas exportación e intracomunitarias, etc,etc. Nadie avisó de que las habría que anular por lo que no sé qué documentos son.

Imagino que no tendrá mayor relevancia porque fueron enviadas a la url de pruebas y para eso estará. Otra cosa es que ahora digan que hay que guardar los registros aunque fuesen de pruebas. En fin, lo veo algo muy difuso.
Todo lo de pruebas es pruebas, inventado, no real.



Entiendo que no, o al menos yo no lo hago. La prefactura puede no validarse y por tanto ya tendrás distintos registros en prefacturas y facturas

Yo leí hace nada que toda factura debe ir vinculada a la prefactura que la creó y que no debe desaparecer la prefactura. Hasta verifactu yo no usaba documentos temporales para crear la factura. Se iban contabilizando a medida que se terminaban de confeccionar. El orden lo tenía en el registro de facturas. Ahora es distinto, la aeat necesita que las facturas sean correlativas para enviárselas tanto por número como por ffecha. En las facturas de contado no hay ningún problema. Pero las o la serie de recapitulativas es distinto. Para poder enviárselas ordenadas he creado la prefactura. Un documento temporal, Así como se van terminando se van contabilizando y toma el siguiente número que le corresponde en la facturación independientemente del número que tenga la prefactura. Si la prefactura y la factura deben tener el mismo número ya no sirve de anda la prefactura. Es mas, con esto se cargarían la facturación recapitulativa. Ya le lanzado algunas consultas a diversos lugares a ver que me contestan.




Gracias por las respuestas.

[Jarogo08]

Empezado por CarlosR

Yo leí hace nada que toda factura debe ir vinculada a la prefactura que la creó y que no debe desaparecer la prefactura. Hasta verifactu yo no usaba documentos temporales para crear la factura. Se iban contabilizando a medida que se terminaban de confeccionar. El orden lo tenía en el registro de facturas. Ahora es distinto, la aeat necesita que las facturas sean correlativas para enviárselas tanto por número como por ffecha. En las facturas de contado no hay ningún problema. Pero las o la serie de recapitulativas es distinto. Para poder enviárselas ordenadas he creado la prefactura. Un documento temporal, Así como se van terminando se van contabilizando y toma el siguiente número que le corresponde en la facturación independientemente del número que tenga la prefactura. Si la prefactura y la factura deben tener el mismo número ya no sirve de anda la prefactura. Es mas, con esto se cargarían la facturación recapitulativa. Ya le lanzado algunas consultas a diversos lugares a ver que me contestan.

Gracias por las respuestas.

Sí sí... la prefactura queda vinculada a la factura y no permito borrarla. Pero lo que preguntabas era si debían de tener el mismo número. Yo puedo tener la prefactura 2 vinculada a la factura 1

Saludos

[CarlosR]

Empezado por Jarogo08

Sí sí... la prefactura queda vinculada a la factura y no permito borrarla. Pero lo que preguntabas era si debían de tener el mismo número. Yo puedo tener la prefactura 2 vinculada a la factura 1

Saludos

OK. Gracias

[edari]

Empezado por Jarogo08

Tendrás que anularlas. El usuario tendrá que saber si la factura que hizo fue una prueba o fue real (recomiendan usar una serie distinta para las pruebas).

Cuando se comenta que hay que borrar las facturas en pruebas nuestras o las realizadas durante el proceso de formación a nuestros clientes, entiendo que no se tienen que anular "inmediatamente" después de subir cada una a la AEAT sino que se tendrán que anular todas juntas al terminar las "pruebas"...


Es correcto?


Gracias

[CarlosR]

Empezado por edari

Cuando se comenta que hay que borrar las facturas en pruebas nuestras o las realizadas durante el proceso de formación a nuestros clientes, entiendo que no se tienen que anular "inmediatamente" después de subir cada una a la AEAT sino que se tendrán que anular todas juntas al terminar las "pruebas"...


Es correcto?


Gracias

Yo no sé ya que pruebas hicimos dentro de los miles de pruebas, todas inventadas por supuesto.
No sé si la AEAT tiene una consulta para poder darlas de baja. Debería tener un espacio para dar de baja todas las pruebas para los desarrolladores. No es lícito decir esto después de haber enviado datos erróneos, inventados y en muchos casos duplicados y con el hash en muchos casos sin encadenar. Para eso son las pruebas no ?


Un saludo.

[bmfranky]

Empezado por CarlosR

Yo no sé ya que pruebas hicimos dentro de los miles de pruebas, todas inventadas por supuesto.
No sé si la AEAT tiene una consulta para poder darlas de baja. Debería tener un espacio para dar de baja todas las pruebas para los desarrolladores. No es lícito decir esto después de haber enviado datos erróneos, inventados y en muchos casos duplicados y con el hash en muchos casos sin encadenar. Para eso son las pruebas no ?


Un saludo.

Hola, yo creo que lo de anular las pruebas , se refiere una vez en producción, a partir del 1 de enero del año que viene(Aunque creo que seria en julio de este año), solo se "debe" enviar a los endpoints de producción, entonces , si envías una factura de pruebas,(Recomendada una serie especial), has de anularla para que la AEAT, no la tenga en cuenta, lo que envíes a los de preproducción, no te preocupes, no existen cara el funcionamiento normal de un negocio.
Aunque de todas formas, el anularlos seria un buen ejercicio, para implementar las opciones de búsqueda y anulación de un registro.

[CarlosR]

Empezado por bmfranky

Hola, yo creo que lo de anular las pruebas , se refiere una vez en producción, a partir del 1 de enero del año que viene(Aunque creo que seria en julio de este año), solo se "debe" enviar a los endpoints de producción, entonces , si envías una factura de pruebas,(Recomendada una serie especial), has de anularla para que la AEAT, no la tenga en cuenta, lo que envíes a los de preproducción, no te preocupes, no existen cara el funcionamiento normal de un negocio.
Aunque de todas formas, el anularlos seria un buen ejercicio, para implementar las opciones de búsqueda y anulación de un registro.

Tiene toda la pinta, sí.



Gracias.

[CarlosR]

- Qué hacer cuando se rompa la cadena de verifactu ? Puede darse el caso de un error de programación, de comunicación remota, de caida del sistema, etc. Se deberia generar un evento indicándolo pero no pueden dejar de vender y cerrar la puerta hasta que un informático les atienda. Aunque se les avise a todos.
Respuesta. Mandar como incidencia


- Varias empresas están acogidas al SIF verifactu y son de los mismos propietarios, todas centralizadas en un equipo común. Deben tener distinto código de instalación ?

Respuesta. En principio sería el mismo sin problema

- En verifactu, pueden pedir la remisión de registros por un requerimiento ?
Respuesta.En principio no es necesario ya que estarías enviando todo a los servidores de AEAT . De todos modos estaría bien guardar los registros remitidos.


- Pueden pedir la remisión de eventos ?
Respuesta.En la opción verifactu los eventos no obligatorios


- Debe haber un sistema de exportación de registros del sif de forma local ante una inspección ?
Respuesta.En principio no es necesario ya que estarías enviando todo a los servidores de AEAT


- Hay que dar de baja las facturas inventadas remitidas en prueba ?
Respuesta.Si, por lo que sacaron de faq si sería así.



- Cómo consigo yo los códigos y series de tales facturas para darlas de baja ?
Respuesta.puedes realizar la consulta de lo remitido filtrando por obligado via WS o via web


- Las prefacturas y las facturas deben tener el mismo número ? Si es así se cargan la factura recapitulativa.
Justamente he creado la prefactura para que mientras no se validan se pueda usar cualquier número y luego se creen números consecutivos a la hora de validarlas. Preguntas y respuestas, pag. 13



Respuesta.en principio no tendría xq tener el mismo numero


- Que calificación de operación llevan las facturas que sale todo a 0, por ejemplo imponibles, ivas para un regalo, un cambio..


Respuesta.podría ser una n1 o si es exenta, depende del caso.


<sum1etalleDesglose>
<sum1:ClaveRegimen>01</sum1:ClaveRegimen>
<sum1:CalificacionOperacion>N1</sum1:CalificacionOperacion>
<sum1:BaseImponibleOimporteNoSujeto>100</sum1:BaseImponibleOimporteNoSujeto>
</sum1etalleDesglose>




Por si alguien está interesado en estas respuestas las reflejo aquí.
Un saludo.

[Jarogo08]

Empezado por bmfranky

Hola, yo creo que lo de anular las pruebas , se refiere una vez en producción, a partir del 1 de enero del año que viene(Aunque creo que seria en julio de este año), solo se "debe" enviar a los endpoints de producción, entonces , si envías una factura de pruebas,(Recomendada una serie especial), has de anularla para que la AEAT, no la tenga en cuenta, lo que envíes a los de preproducción, no te preocupes, no existen cara el funcionamiento normal de un negocio.
Aunque de todas formas, el anularlos seria un buen ejercicio, para implementar las opciones de búsqueda y anulación de un registro.

A ver... que igual me lié yo!

Todo lo que mandaste al entorno de pruebas no hay que borrarlo / anularlo, digo yo! para eso es un entorno de pruebas

Yo pensé que preguntabas una vez que estés ya enviando en real, al entorno real. Si haces una prueba (para explicarle al cliente como se factura por ejemplo) y la factura no es buena ahí es donde habrá que anularla.

[edari]

Por si sirve a alguien


Yo la semana pasada asistí a un Webinar en el que uno de los participantes era uno de los "responsables" de la AEAT con Verifactu y se refería claramente a que cuando estemos montando un entorno de pruebas en casa de nuestros clientes para darles la formación cada vez que se subiera una factura a Verifactu inmediatamente se anularan


También recomendó que en la impresión de esas pruebas poner una marca siempre una "marca de agua" para que se vea claramente que son pruebas y con la obligatoriedad de mantener los xml, aunque la norma diga que no estamos obligados a conservar los xml (en modo Verifactu), que vamos, que mejor que los guardemos por si acaso...

[Faneka]

Cuando se refiere al entorno de pruebas en el clienet supongo que quieren decir pruebas en el entorno de producción, allí si que dicen de anular las facturas una vez enviadas. Yo he creado una serie para que todo lo que se meta en ella al generar la factura se envia a veri*factu y luego se anula automáticamente, que es como aconsejaban para que el cliente no tenga que estar luego anulandolas por su cuenta.

[Decanato]

Como tenga que anular yo toda la chasca que he mandado al entorno de pruebas no me iba a quedar vida

[Faneka]

Empezado por Decanato

Como tenga que anular yo toda la chasca que he mandado al entorno de pruebas no me iba a quedar vida

Jaja. Ya os digo que en pruebas no hay que anular nada, solo faltaba eso, es igual que en el SII, nunca hubo que anular las facturas enviadas.

En las Faqs, la pregunta 11 tiene una parte que habla de ello

A este respecto, y aunque puede implementarse de diversas formas, si se desea
poder probar el SIF, deberá ser con el certificado electrónico cualificado válido y
admitido instalado (porque, si no es así, el SIF no puede estar operativo y ser usado).
Desde ese momento, el usuario puede ya expedir facturas con él, que siempre serán
"reales" (con su QR tributario, y cuyos RF de alta son remitidos a la AEAT) pero, en este
caso, al ser expedidas con la intención de hacer pruebas (y no corresponderse con
bienes entregados o servicios prestados), la normativa contempla que para las facturas
expedidas que no sean tales, siempre y cuando no diga otra cosa el reglamento de
obligaciones de facturación, aprobado por el Real Decreto 1619/2012, deberá
procederse a la inmediata posterior anulación de ellas (para que no cuenten como
facturas reales), por lo que luego deberían siempre ser anuladas por el usuario,
remitiéndose entonces automáticamente a la AEAT el debido RF de anulación (sin
perjuicio de que, además, el usuario "describa" esas facturas con algún texto que las
califique "de pruebas").
Para facilitar esta operativa "de pruebas (o de formación) del SIF" y hacer más
cómoda, tranquila y segura su realización por parte del usuario (evitando descuidos u
olvidos), el SIF podría ofrecer una funcionalidad de "facturar en pruebas (o formación)"
ya preparada para que haga todo esto automáticamente: dejar al usuario expedir
5 de mayo de 2025 21
facturas "reales" (con QR y remitido su RF de alta a la AEAT) pero "para
pruebas/formación" (que deberá poder distinguir, por ejemplo, con numeración en
una serie especial de tipo PRU 25 XXXX), describirlas visible y claramente como "de
pruebas" y asegurarse de que siempre serán anuladas (con remisión de RF de
anulación a la AEAT) una vez terminadas dichas pruebas o formación. De esta manera,
el usuario se despreocupa, lográndose así el objetivo de poder probar el SIF (o enseñar
su funcionamiento), ya que después se "arregla" oficialmente todo lo hecho en
pruebas/formación, a la vez que se actúa cumpliendo con el RD 1007/2023, y siempre
de forma transparente, ya que se deja el rastro que explica toda la operativa llevada a
cabo

[CarlosR]

Empezado por Faneka

Jaja. Ya os digo que en pruebas no hay que anular nada, solo faltaba eso, es igual que en el SII, nunca hubo que anular las facturas enviadas.

En las Faqs, la pregunta 11 tiene una parte que habla de ello

A este respecto, y aunque puede implementarse de diversas formas, si se desea
poder probar el SIF, deberá ser con el certificado electrónico cualificado válido y
admitido instalado (porque, si no es así, el SIF no puede estar operativo y ser usado).
Desde ese momento, el usuario puede ya expedir facturas con él, que siempre serán
"reales" (con su QR tributario, y cuyos RF de alta son remitidos a la AEAT) pero, en este
caso, al ser expedidas con la intención de hacer pruebas (y no corresponderse con
bienes entregados o servicios prestados), la normativa contempla que para las facturas
expedidas que no sean tales, siempre y cuando no diga otra cosa el reglamento de
obligaciones de facturación, aprobado por el Real Decreto 1619/2012, deberá
procederse a la inmediata posterior anulación de ellas (para que no cuenten como
facturas reales), por lo que luego deberían siempre ser anuladas por el usuario,
remitiéndose entonces automáticamente a la AEAT el debido RF de anulación (sin
perjuicio de que, además, el usuario "describa" esas facturas con algún texto que las
califique "de pruebas").
Para facilitar esta operativa "de pruebas (o de formación) del SIF" y hacer más
cómoda, tranquila y segura su realización por parte del usuario (evitando descuidos u
olvidos), el SIF podría ofrecer una funcionalidad de "facturar en pruebas (o formación)"
ya preparada para que haga todo esto automáticamente: dejar al usuario expedir
5 de mayo de 2025 21
facturas "reales" (con QR y remitido su RF de alta a la AEAT) pero "para
pruebas/formación" (que deberá poder distinguir, por ejemplo, con numeración en
una serie especial de tipo PRU 25 XXXX), describirlas visible y claramente como "de
pruebas" y asegurarse de que siempre serán anuladas (con remisión de RF de
anulación a la AEAT) una vez terminadas dichas pruebas o formación. De esta manera,
el usuario se despreocupa, lográndose así el objetivo de poder probar el SIF (o enseñar
su funcionamiento), ya que después se "arregla" oficialmente todo lo hecho en
pruebas/formación, a la vez que se actúa cumpliendo con el RD 1007/2023, y siempre
de forma transparente, ya que se deja el rastro que explica toda la operativa llevada a
cabo

Mejor así. Ya bastante trabajo es hacer todo el desarrollo que conllevan estas nuevas leyes.
Y lo que nos espera estos próximos años !
Un saludo.