FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Cita:
Por eso sigo buscando una solución "Técnico/Fiable" que garantice que un registro de facturación en xml es el originalmente creado en su momento. A pensarrrr |
#2
|
||||
|
||||
Cita:
Cita:
Está claro que por un lado están las facturas en nuestro sistema y luego una representación en XML que se firma y se encadena. Esa representación se envía de forma inmediata o por requerimiento a la AEAT. Los XML no se van a poder modificar y para eso ya se especifica el cómo técnicamente en la documentación (firma y encadenamiento). Cuando el párrafo anterior habla de "La integridad e inalterabilidad de los datos registrados..." creo que se refiere a las facturas de nuestros sistema. Para mi tiene lógica, porque son los datos iniciales, a partir de los cuales se genera el XML (y la factura del cliente). Por la propia ley de facturación no se debería poder modificar en un sistema informático una factura ya "generada". Si se pudiera hacer ¿qué pasaría si al cabo de 2 meses un cliente nos pide una copia? Lo mismo con el XML. Para eso ya existen las facturas rectificativas. Ninguna de las 2 se debería modificar. Ni la factura almacenada en nuestro sistema, ni por supuesto el XML.
__________________
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
|
|||
|
|||
Cita:
¿ Nos están pidiendo algún método técnico fiable parecido para los clientes que informan sólo por requerimiento (no Verifactu) de que los registros que vamos a enviarle son los originales generados en el preciso momento de expedir la factura ? |
#4
|
||||
|
||||
Cita:
O al menos no se pueda modificar los campos que afectan al XML. Si el acceso a la Base de Datos está protegido (como debería ser) esa información ya no es modificable.
__________________
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. |
#5
|
|||
|
|||
Cita:
Luego, los artículos 8.2 a y b obligan a usar un «proceso técnico fiable» y a que «Todos los datos registrados deberán encontrarse correctamente fechados, indicando el momento en que se efectúa el registro.» Si por «registros originales» tu entiendes «registros con los datos originalmente grabados», entonces sí, están pidiendo esto (con la excepción de la palabra «parecido»); tanto a Hacienda para la aplicación quien soporta Veri*factu como a cualquier otro proveedor de SIF que usan el método del registro local encadenado y firmado. |
#6
|
|||
|
|||
¿Uh? ¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?
Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores. |
#7
|
|||
|
|||
No entiendo lo que dices
|
#8
|
|||
|
|||
A ver si me explico mejor... (la énfasis es mía)
Cita:
Cita:
La opción la tiene el cliente; pero no dentro del ámbito del programa, sino dentro del ámbito de sus obligaciones de tributación, que es más amplia. Por ejemplo, en el artículo 15 está escrito «podrán remitir [...] todos los registros de facturación generados por los sistemas informáticos» (mi énfasis); no «generados por [strike]el sistema informático[/strike]». Última edición por antoine0 fecha: 14-12-2023 a las 17:53:36. Razón: aclaración sobre «tributación» |
#9
|
|||
|
|||
Cita:
|
#10
|
|||
|
|||
Entonces como proveedores podemos hacer un sistema verifactu, no verifactu o con las dos opciones. Creo que se puede explicar al cliente q un sistema no verifactu complica el tema y puede finalizar con requerimientos. Podían haber definido solo verifactu como sistema único y no enredar mas
|
#11
|
|||
|
|||
Cumplir Articulo 8.3 SIF Veri*Factu
Yo creo que un SIF Veri*Factu tampoco tiene que cumplir con el Articulo 8.3 ya que al principio del BOE dice textual: "Con ser importantes, los anteriores propósitos encuentran su sentido en un objetivo aún más amplio que desde las organizaciones internacionales (OCDE y Unión Europea) han dado en llamar «cumplimiento tributario por diseño»." y luego refiriéndose al cumplimiento por diseño dice:
"Asimismo, el texto reglamentario prevé la posibilidad de que, voluntariamente, 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, en cuyo caso se entenderá que esos sistemas informáticos ya cumplen por diseño los requisitos técnicos anteriormente mencionados." y luego en el CAPITULO III cuando habla de Sistemas de emisión de facturas verificables dice: "A los efectos de este Reglamento, se presumirá que los «Sistemas de emisión de facturas verificables» cumplen por diseño los requisitos establecidos en el artículo 8 de este Reglamento, y por lo tanto tampoco les será de aplicación lo dispuesto en el apartado 2 del artículo 14 de este Reglamento." |
#12
|
|||
|
|||
Cita:
[/i]Aquellos sistemas informáticos indicados en la letra a) del artículo 7 de este Reglamento que, cumpliendo con todas las obligaciones que impone este Reglamento y de acuerdo a las especificaciones técnicas que se establezcan[i] O sea, por un lado dicen que si es VeriFactu no tienes que cumplir pero por otro dice que para ser VeriFactu debes cumplir con todo. |
#13
|
|||
|
|||
Cita:
Luego sobre lo dicho en el artículo 16.2, no sé exactamente cómo leer «se presumirá que [...] cumplen por diseño los requisitos establecidos en el artículo 8». Si te eximen del sistema de comunicación de los registros (14.2) sin quitarte la consultación en interactivo de los registros y de los eventos (14.1), significa que debes tener en tu programa tales archivos, de registros y de eventos, ¿no? Y el 8.3 solo dice que debe estar un registro de eventos... (y que su contenido y diseño estarán en el futuro O.M.) Ahora bien, si resulta que el registro de eventos solo registra las operaciones de grabar, firmar, iniciar serie y poco más, es cierto que son las operaciones que se pueden deducir de los registros de Veri*fatu y por tanto efectivamente ya no es realmente necesario un registro de eventos en el programa en casa del cliente (con la condición para cumplir el 14.1 de implementar una interfaz viva de consulta del Veri*factu). Como ya se ha dicho varias veces, en realidad debemos esperar a leer la O.M. para entender realmente como comérselo. |
#14
|
|||
|
|||
Cita:
En lugar de «finalizar con requerimientos», que me parece demasiado negativo, yo pondría que la empresa que no quiere Veri*factu se está colgando a si misma una diana enorme a la atención de los inspectores de Hacienda. Claramente está hecho para ser disuasivo, un poco como el sistema del «criterio de caja» para el IVA: algunas empresas lo necesitan de verdad y no pueden vivir sin él, pero la intención de Hacienda es que se quede marginal. 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 |
|