FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Buff, yo veo 2 cosas complicadillas para según que tipo de negocio:
Será obligatorio tener preparado el software para el envío inmediato de las facturas antes o la vez de su generación, espero que no sea obligatorio por que en sistemas lentos o con comunicación lenta (por ejemplo zonas con router de datos por 3g-4g) los clientes se pueden cabrear por una espera indeterminada de varios segundos, si además le añadimos un sistema de facturación centralizado con varios dispositivos generando facturas a la vez y hay que enviarlos en oden fifo.. Buff Por otro lado el tema de las logs garantizado inviolabilidad etc, que eso nos lo dejan a nosotros, claro ahora en sistemas que no contemplen esa automatización en sus bases de datos búscate la vida y rompete la cabeza y que lo que hagas este dentro de los parámetros que ellos piensan que son inviolables. Por que yo puedo pensar que enviarle los datos a un webservice firmado puede ser suficiente, pero me pongo a pensar la de los logs que se generan según lo que piden y son muchísimos más datos que las facturas. Los routers van a Petar del calentón y me veo un sin vivir todo el día acojonados con las averias |
#2
|
|||
|
|||
Cita:
Última edición por antoine0 fecha: 22-02-2022 a las 20:23:06. Razón: Había olvidado la aplicación web :( |
#3
|
||||
|
||||
Así ojeando por encima y habiendo desarrollado TicketBAI (hacienda del país vasco) veo que la idea es bastante parecida; Han cogido ideas imagino. Veo lo siguiente:
"permitiendo, en su caso, la simultánea o posterior remisión de la información de los mismos a la Administración tributaria" => En el pais vasco ya está previsto que la fatura se envíe en cuanto se genera o durante un periodo posterior (lo antes posible dice la documentación). Es decir, no es condicionante para generar la factura. Se puede crear una cola (con un proceso externo) que va realizando los envíos. "los obligados tributarios remitan inmediatamente a la Administración tributaria, de forma automática y segura por medios electrónicos, todos los registros de facturación generados en sus sistemas informáticos" => Cada ticket/factura que se genere hay que enviarla. En el caso del pais vasco, para personas/autónompos/miniempresas que generan pocas facturas al mes, ellos proveen un sistema para poder introducirlas manualmente. Pero esto sólo sirve para quien genere 5/10 facturas al mes. "la estandarización de formatos de los registros de facturación, se deberá incluir: código «QR» => Igual. En cada factura que se emite, debe incluir QR con la información. Ese QR (hay un punto más adelante que lo explica) el usuario puede leerlo (con el móvil, por ejemplo) y le debe llevar a una web con los datos de su factura. Así se asegura de que se ha enviado y de que es igual que la que él tiene en papel (o en su ticket). Algo así, para que os hagáis una idea: "La integridad e inalterabilidad de los datos registrados se asegurará utilizando cualquier proceso técnico fiable que garantice el carácter fidedigno y completo de los registros de facturación desde que hayan sido grabados en el sistema informático" => Entiendo que habrá que utilizar certificado/firma con todo lo que se envíe (JSON/XML/...). "La trazabilidad de los registros de facturación, que deberán estar encadenados de manera que pueda verificarse su rastro siguiendo su secuencia de creación desde el primero al último." => Todos los registros/facturas, deben incluir una parte de la firma de la factura anterior (encadenamiento), de esta forma te aseguras de que "no desaparecen facturas". Eso trae bastantes problemas técnicos (por experiencia). Si por lo que sea no puedes encadenar con la anterior hay que poder justificar porqué. Algo así como justificar los huecos en la facturación. Generación del registro de facturación de alta Generación y contenido del registro de facturación de anulación. => Se prevee alta, modificación y anulación de facturas (que no es lo mismo que rectificativas). "El receptor de la factura, ya sea empresario o consumidor final, podrá proporcionar de forma voluntaria determinada información de la misma a la Agencia Estatal de Administración Tributaria facilitando el código identificativo de carácter alfanumérico o mediante la lectura del código «QR»" => El que recibe la factura puede remitirla también a la AEAT. Es decir se pueden enviar facturas de compra (en el País vasco también). cosa que a la AEAT le facilita mucho el trabajo de "vigilancia", porque así puede "cuadrar" las que recibe de compra con las que recibe de Venta. Y si no "cuadran" pues multa al canto... "LaAgenciaEstataldeAdministraciónTributariafacilitaráunarutaespecíficaensusede electrónica o a través de la aplicación que al efecto ponga a su disposición para recibir dicha información. El acceso a la sede electrónica o a la aplicación mostrará los datos del código identificativo de carácter alfanumérico o del código «QR» en formato legible" => La web que he mencionado anteriormente, donde escaneado el código de la factura/ticket en papel, obtienes info de la factura generada. Como ejemplo, os muestro el QR de una factura generada para Guipuzcoa: Si lo escaneáis, devuelveeste texto: h_t_t_p_s://pruebas-ticketbai.araba.eus/tbai/qrtbai/?id=TBAI-B05430756-150222-BDM2BLewRizLS-007&s=SG&nf=3&i=36.00&cr=009 link: https://pruebas-ticketbai.araba.eus/...i=36.00&cr=009 Que es un link con los datos de la factura
__________________
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. Última edición por Neftali [Germán.Estévez] fecha: 23-02-2022 a las 10:50:00. |
#4
|
||||
|
||||
Yo creo que lo suyo sería ir creando y manteniendo una lista de "especificaciones mínimas" que consensuemos entre todos y que deberían de tener nuestros programas para cumplir la dichosa normativa esta porque hay cosas que a mi no me quedan claras.
Por otro lado parece ser que todo esta movida va enfocada a las operaciones de venta por lo que entiendo que no hay mucho que hacer en compras, pedidos, traspasos, etc. Yo de momento solo me he leido el documento por encima para hacerme una idea de "lo gordo" pero habrá que ir demenuzando así que, si os parece, me atrevo a comenzar la lista con algo que está meridianamente claro (si me equivoco me rectificáis): ********************************** LISTA DE ESPECIFICACIONES MÍNIMAS - Control e identificación de usuarios al acceder al programa. Este usuario se incluirá en todos los registros de operaciones de venta e igualmente se llevará un "registro de eventos" de cuando accede, las operaciones de venta que hace y cuando abandona el programa. ********************************** Esto lo podemos ir copiando/pegando/ampliando y rectificando según vayamos entendiendo. Para empezar ahora mi pregunta es: este "registro de eventos" cómo crearlo y manejarlo. Saludos
__________________
Be water my friend. Última edición por Neftali [Germán.Estévez] fecha: 23-02-2022 a las 15:45:29. |
#5
|
|||
|
|||
Cita:
Pero lo citado no se refiere a eso; se refiere a los mecanismos dentro de la aplicación (o de la base de datos). Y aunque se pueden usar firmas electrónicos para cada registro grabado, no creo que sea siempre necesario, sobre todo por dos razones: 1, en términos de CPU, no sale gratis la firma electrónica; y 2, para firmar de forma completamente automática, la clave privada debe ser bajo el control del proceso automatizado, la cual cosa crea un potencial agujero de seguridad; qué atrae más complejidad, lo contrario del efecto buscado. Imaginad la diferencia en termino de código y de debug entre:Yo sé con cuál de los dos prefiero lidiar |
#6
|
||||
|
||||
Cita:
los datos de facturación, éstos queden protegidos contra cualquier acción que comprometa la exactitud, autenticidad y completitud de los datos almacenados, de manera que ninguno de los datos registrados pueda ser alterado, ni por el propio sistema informático, ni por el usuario ni por ningún dispositivo, sistema o programa informático o electrónico externo. El sistema informático no dispondrá de ninguna funcionalidad que permita, de forma presencial o remota, alterar u ocultar los datos originales previamente registrados. Tienes razón, esto se refiere a los mecanismos desde tu aplicación (ya he dicho que lo había leído rápido), pero debería bastar con algo básico; No creo que haya que usar firmas ni hashes dentro del propio programa (a lo más si lo deseas, puedes encriptar BD, aunque poersonalmente no me gusta si no es estrictamente obligatorio). 1) Tu aplicación no debe permitir hacer "cosas raras" (B) 2) Una vez modificados los datos y enviados, tu aplicación no debe permitoir modificarlos. 3) Debes proteger el acceso a la Base de Datos (SGBD) con usuario/contraseña, de forma que nadie desde fuera pueda acceder a los datos y cambiarlos. Con eso te aseguras esa integridad e inalterabilidad.
__________________
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. |
#7
|
|||
|
|||
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). |
#8
|
||||
|
||||
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. |
|
|
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 |
|