FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Cita:
Cita:
Una cosita interesante es que en el artículo 11 (registros de anulación, cuando el 10 es para los registros normales) no hay un equivalente a la ñ. Entonces las anulaciones no están encadenadas por construcción (sigue de aplicación el 8.2 b que manda encadenar). Supongo que es por qué estos registros pueden ir opcionalmente mezclados con los normales en algunos sistemas (cuando los abonos se consideran como una forma más de factura). |
#2
|
||||
|
||||
Cita:
Cuando habla de esto: Artículo 9.Generación del registro de facturación de alta Se está refiriendo no a tu factura en BD, sino que ese "registro de facturación de alta" es el elemento que tú debes generar (XML, JSON,...) y que será enviado a la AEAT. Ese registro/fichero sí que va firmado, lleva encadenamiento, hash,... Por eso luego habla de: Artículo 11.Generación y contenido del registro de facturación de anulación Lo mismo. Eso se refiere al XML/JSON que tú debes generar y envias cuando anulas una factura. En tu sistema la información de anulación no tiene porqué tener TODA la información que ahí se detalla. Piensa que tú para una anulación en tu sistema es posible que sólo necesites el ID de la factura inicial y FECHA de aulación y lo que ahí te pide es todo lo que se detalla en el artículo 11. Eso te está indicando que NO SE REFIERE a tu registro de BD, sino al "registro que envías". Aquí deja claro que "el registro de facturación" NO ES tu registro de la Base de Datos, que tú puedes guardarlo como te convenga, sino a los ficheros que tú generas y envias a la administración: Asimismo, los registros de facturación de alta y de anulación a que se refieren los mencionados artículos deberán ser firmados electrónicamente. Esta firma electrónica no será obligatoria para los sistemas informáticos que realicen la remisión de todos los registros de facturación a la Agencia Estatal de Administración Tributaria según lo indicado en los artículos 15 y 16 de este Reglamento
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#3
|
|||
|
|||
El tema de garantizar los eventos es para mi el tema más complicado que nos han dejado ypodemos ir exponiendo ideas para no perdernos en generar infinitos datos intratables.
Hay que tener en cuenta: -Estructura de los eventos para guardar en una base de datos -Modo de garantizar la inviolabilidad de los registros. -Que datos son propensos de grabar, ya que es tontería guardar la marcacion de las facturas, anulaciones etc ya que ya está guardada por otro lado y ya en si es un evento. Por ejemplo: ¿Una empresa externa a la que le enviemos los eventos por webservice puede ser garantía de inviolabilidad? Generar xmls o json firmados de miles de eventos va a tener una ocupación tremenda y manejar la petición de datos a través de esos ficheros firmados no es muy práctica, y generar una bd paralela para pedir los datos no es garantía de nada. Vamos a intentar ser pragmáticos y buscar entre todos soluciones para esta problemática. Me parece absurdo este paso que dejan una puerta abierta a que cada uno decida que es un evento. Deslizar un dedo por la pantalla es un evento de mouse. Pulsar un producto y después eliminarlo es un evento más lógico de grabar. Fichar una entrada o salida de usuario por tener un módulo en el mismo software de facturación para el control horario, también es un evento, pero no es competencia de hacienda, ya que ese evento puede ser de un usuario que no factura, un limpiador, un cocinero. Pienso que falta regulación y va a crear una laguna que para los informáticos se va a traducir en intranquilidad. Última edición por ermendalenda fecha: 23-02-2022 a las 21:06:14. Razón: Por errores |
#4
|
|||
|
|||
No creo equivocarme.
Hablo siempre de los registros de facturación de alta o de anulación, colectivamente llamados registros de facturación en el reglamento (¿hay más tipos posible?) No creo que el formato de estos registros siga descrito en el reglamento más allá de ser una compilación de varios datos (art.8) o elemento de información (art. 9-11). De hecho, creo que la forma puede variar según las operaciones que se realizan. Lo que se pide es que la compilación siga siempre integre e inalterable, y que se pudiera demostrar. Dentro de las operaciones está subir los registros a Hacienda (art. 15.1). Esta vía soluciona efectivamente gran parte del problema (art. 16.2 dice que «cumplen por diseño» el 8.2), elimina la firma digital, quedando en practica solo el tema de la huella, arreglar el 10.1 ñ (datos de la factura anterior), generar el QR y, last but not least, la log, ya que todas las demás cosas deben existir en cualquier sistema de facturación actualmente conforme; además evidentemente de empezar con una base claramente limpia (dónde no se puede trastear con los datos, dónde las facturas se graban de una sola vez etc.) En tal caso, la DFÚ (última página) promete un O.M. que definirá (apartados a, c, d, e y g) la huella, la forma de dichos registros cuando se suben y un largo etc. Dicho de otra manera, falta mucho para entrar en detalle. Por ejemplo, yo leía que la huella, parte del registro descrito en el artículo 10, está sometida al art. 8.1 b y por tanto debe ser generado en el momento de la emisión de la factura, un momento que veo distintamente anterior a la subida del registro a Hacienda. Pero es cierto que tu lectura, que se genere la huella solo en el momento de subir los datos, actuando directamente sobre el registro en la forma que se envía a Hacienda, se puede defender. Sin embargo, yo me planteaba sobre todo en el caso opuesto, cuando no se suben los registros a Hacienda, que para mi es lo más probable en un primer tiempo, es decir, antes que los informáticos de Hacienda hayan puesto en marcho el nuevo sistema y que se haya estabilizado las especificaciones de la O.M. Última edición por antoine0 fecha: 23-02-2022 a las 21:39:28. Razón: Olvidado elementos prometidos en la O.M. |
#5
|
|||
|
|||
Os veo muy pesimistas... Dos cosas que me daban miedo y con las que me quedo más tranquilo:
|
#6
|
|||
|
|||
Cita:
|
#7
|
||||
|
||||
A ver... una idea tontuna que me pasa por la cabeza.
Según quiero entender lo que quieren es que el fichero donde se guardan los eventos no se pueda manipular pero no dicen cómo hacerlo ni con qué técnicas. ¿Sería una tontería ir metiendo registros con los textos encriptados en una tabla y luego poner un visor desde el programa para verlo o exportarlo? De esta manera los datos no se podrían tocar pero si visualizar y sería algo relativamente fácil de implementar. Por otro lado, el tema de enviar los datos creo que no es obligatorio, ¿no?. Saludos.
__________________
Be water my friend. |
#8
|
||||
|
||||
Cita:
Los datos no son obligatorio que los envíe el contribuyente, pero entiendo que si es obligatorio que el programa permita realizar el envío. Ya que hacienda le puede solicitar las facturas para una inspección, y eso habrá que hacerlo en el formato que defina hacienda o eso me ha parecido entender. De todas formas creo que lo mejor es esperar a que hacienda (que somos todos) empiece a sacar cosas. Aunque se puede ir adelantando algo. |
#9
|
||||
|
||||
Cita:
Cita:
Hasta yo esperaría en un par de años una consulta vinculante que efectivamente lo prohíba. Cita:
Un compañero mío me hizo remarcar que el objetivo de todo eso es dar a Hacienda un acceso directo a los datos de facturación de las empresas (mismo objetivo general que el S.I.I.) Leyendo el reglamento con esta visión, hay dos vías: si se suben los registros o se usa la aplicación web de Hacienda, pues los datos de las facturas están en un fichero que gestiona Hacienda, se puede analizar por todos los lados sin demora, objetivo conseguido. En el otro caso, hay varias provisiones en el texto que demuestran el objetivo de Hacienda: las más claras son el art. 14 de la pág. 16, y pág. 12 art. 8.2 a), 4ª alinea (subrayo yo): Cita:
|
#10
|
|||
|
|||
Cita:
De mi punto de vista, esto va a generar un MONTÓN de trabajo para las empresas que se dedican a este negocio, ya que básicamente todo las empresas españolas deben actualizarse, en un espacio de tiempo breve. Es cierto que hay otras opciones como ir a por el cloud que serán seguramente privilegiadas e incentivadas (con los multimillonarios fondos europeos y la «digitalización»), pero quedará mucho pastel para repartirse. Hasta el punto que, si no se demora el proyecto, creo que dentro de varios meses es posible que veamos una «crisis» cuando el calendario apretará un poco más y empezará a escasear los informáticos, con la consecuente subida de los precios para las empresas que no se habrán asegurado en tiempo, y entonces un aluvión de dinero para las empresas de informática (y también después un bajón cuando la bonanza se acabará y otra crisis para 2026 debida al crecimiento brutal pero corto, pero esto será otra cosa). ¡Y también más dinero para los informáticos! O siga, un nuevo efecto Euro, aunque en menor escala. Para las empresas de desarrollo, incluso las pequeñas, ahora es el momento de contratar y formar personal nuevo para poder hacer frente a la subida el año que viene; efectivamente es una inversión, entonces no es productivo a (muy) corto plazo. Pero los que se dedican a esto deben saber a veces invertir para ¡recoger más ganancias más tarde! |
#11
|
||||
|
||||
Cita:
Hay que esperar, por ahora con lo que hay no se puede hacer nada en la práctica. He intentar hacer algo ahora creo que puede generar una pérdida de tiempo después. Hay que esperar a que definan y concreten protocolos, formatos de fichero, documentación, ejemplos, entornos de pruebas,...y todo lo necesario para poder implementar esto dentro de las distintas aplicaciones. En cuanto al tiempo, si es necesario ampliarán plazos como han hecho en el pais vasco. Los colegios profesionales y las asociaciones empresariales, presionaron para que así fuera. Pueden multar a un 2% de las empresas si no llegan a plazo, pero no pueden multar al 30% de las empresas si los plazos no han sido los adecuados. Paciencia, paciencia, paciencia,...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#12
|
|||
|
|||
Hola buenas,
He estado leyendo el borrador de la ley y algunos artículos de blogs al respecto. Por ahora, llego a la conclusión que es más fregado de lo que parece, o más fregao que el Ticket BAI. Yo entiendo que no sólo afecta a los sistemas de facturación sino a la gestión empresarial en general: Cita:
Cita:
Cita:
Lo que veo complicado que pasará con las aplicaciones open source. ¿Quién se responsabiliza? A ver si la AEAT abre un buzón de consultas, como se hizo en el País Vasco con Ticket BAI. |
#13
|
|||
|
|||
Y añade cando tengan que empezar a meter números de series de facturas, rectificativas, rectificativas de simplificadas, recapitulativas, sustitutivas, recapitulativas de simplificadas. Divertisimo
|
#14
|
||||
|
||||
Cita:
¿Cual era el sistema de facturación anterior en esa empresa? El sistema que tuvieran anteriormente será el que se tenga que adaptar. Si no tenían (y las hacían con excel, por ejemplo) pues la AEAT se supone que pondrá a disposición de los usuarios una aplicación gratuíta para hacer esas facturas que antes hacían "manualmente". Esa aplicación está pensada para "pocas" facturas. Si el número es grande, pues tendran que adquirir una app. de facturación y en ese caso, tal vez tengas que adaptar la tuya para comunicarte con ella.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#15
|
|||
|
|||
Cita:
|
#16
|
|||
|
|||
Cita:
A) hacer facturas B) enlazar con un software que cumpla con la normativa. Y luego tu sistema, aunque no sea de facturación, también tendrá que cumplir con el tema de la trazabilidad, legibilidad, eventos y todo el rollo eso. Claro, porque podría darse el caso que un sujeto facture una parte de proyectos y los otros no y los borre, o por el tema de la trazabilidad de las operaciones facturadas...la verdad, no sé. Cita:
Y hoy he leído que en Europa quieren unificar el formato de las facturas electrónicas Se juntará el trabajo. |
#17
|
|||
|
|||
Cita:
Nota 2: es un borrador; pueden mejorar la redacción de algunos puntos. Veo que el nombre del futuro reglamento habla de los «sistemas [...] que soporten los procesos de facturación de empresarios y profesionales». Por tanto el ámbito no debería extenderse más allá de la «facturación» incluyendo su «soporte» (dos términos potencialmente amplios, como lo notas). Y cómo es normal en una ley, el primer artículo define el objeto, es decir qué se entiende por «facturación». Legalmente, todo lo que no entre dentro de esto no tiene que verse afectado por este reglamento. Y no veo cómo alguien puede obligar una app que gestiona pedidos (por ejemplo, Google Calendar) a entrar en el ámbito del reglamento. Cita:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
|