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

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