![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
#81
|
|||
|
|||
|
Cita:
También me sorprendió. |
|
#82
|
|||
|
|||
|
Cita:
|
|
#83
|
|||
|
|||
|
Cita:
Tampoco hay que añadir a las facturas el campo hora, las facturas siguen como hasta ahora y sólo llevan fecha de expedición. Son los registros de facturación los que se les añade la hora y huso horario en que fueron generados para poder controlar si los registros se están mandando a su debido tiempo. Fíjense que el reglamento sólo afecta a programas que realicen facturas (esto ya me informé con los de Veri*Factu por mail), pero si tienes un programa que sólo sirve para contabilidad no te va a afectar. Lo único que han dicho para estos software es que impidan llevar contabilidad "B". He visto algunos software de contabilidad que obligan a hacer contraapuntes cada vez que te equivocas. Tener esa información banal es un engorro para la persona que lleve contabilidad, cada vez que saque un extracto de una cuenta va a querer cortarse las venas porque le va a costar llevar un seguimiento. Lo lógico es que el programa contable permita editar los apuntes a menos que hayan sido ya enviados al SII o se hayan declarado impuestos. Última edición por razorxxx fecha: 27-11-2024 a las 09:40:37. |
|
#84
|
|||
|
|||
|
Cita:
Lee la ley antifraude |
|
#85
|
|||
|
|||
|
Incluso para los que están pensando en incluir "Prefacturas", en las respuestas que dan del seminario del día 28, te dicen que deben configurar "un todo" con las facturas definitivas:
P: 162,"Va poder existir facturas de tipo de borrador que no sean validas y de esa manera, hasta que no se validad la factura borrrador no genera un numero correcto de facturacion y por lo tanto se podra subir a VeriFactu. ¿esto se podra hacer?",Ramon Sanchez,'-,,10/28/2024 13:54:17,, " R: Mientras no se genere un registro de facturación real no se puede remitir la información a la AEAT. Solo se deben remitir registros correspondientes a facturas emitidas. // En este sentido, es preciso recalcar que el artículo 29.2.j) de la Ley General Tributaria, introducido mediante la Ley 11/2021, de 9 de julio, conocida de forma abreviada como ""de medidas de prevención y lucha contra el fraude fiscal"", contiene obligaciones generales que afectan a los fabricantes y a los usuarios de cualesquiera sistemas y programas informáticos o electrónicos que soporten los procesos de gestión de quienes desarrollen actividades económicas. Esas obligaciones exigen genéricamente que dichos sistemas y programas garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, sin que cualquier registro informático pueda desaparecer o ser alterado sin que quede la debida anotación de ello en los sistemas mismos. En consideración a lo anterior, debe entenderse que, más allá de lo que establece el Real decreto 1007/2023, existe una obligación de tipo genérico y que no necesita desarrollo reglamentario por la que cualquier sistema informático de gestión, entre los que deben incluirse los sistemas que generan albaranes, facturas proformas o borradores, debe conservar los registros generados, aun cuando estos lleguen convertirse habitualmente en una factura. Por ello, no sería legal y sería susceptible de sanción, el uso de sistemas que generen documentos preparatorios de facturas o de facturas simplificadas, sin que el sistema informático mismo disponga de elementos de control para la conservación de tales documentos preparatorios de forma debidamente vinculada a las facturas o a los registros de facturación que finalmente se emitan o, en defecto de factura, de forma que queden registrados y conservados en el sistema. " |
|
#86
|
|||
|
|||
|
Cita:
Una cosa por ejemplo es que hayas hecho una rutina de desarrollo y que alguien te corrija o te proponga otra manera mejor de hacerlo, pero en el contexto en que estamos metidos en este hilo, afirmar cosas de la normativa que ni siquiera aparecen en ella y que nadie de Veri*Factu te ha resuelto por mail al final lo que hace es sembrar mayor incertidumbre y dudas. Siempre por impulsividad es más fácil largar lo que se te pasaba por la cabeza en ese momento sin pararte a pensar las repercusiones, pero aquí no estamos lanzando mensajes al aire: una "cagada" importante puede provocarnos sanciones de la AEAT como para cerrarnos el kiosko. |
|
#87
|
|||
|
|||
|
Volvemos a lo mismo. ¿Qué fraude estoy cometiendo si emito documentos que no tienen ninguna validez fiscal?
|
|
#88
|
||||
|
||||
|
Cita:
Tal vez eso pase en otros foros, pero no creo que sea el caso de este y en este contexto Veri*factu). Coincido en que hay cosas que no se ajustan a la "realidad" definitiva, pero aquí la mayoría somos programadores y no tenemos conocimientos amplios de facturación (de la Ley de Facturación). Entiendo que los errores que se comenten (que cometemos) son por desconocimiento y entre todos podemos corregirlos. No creo que nadie esté propagando en este foro "desinformación y noticias fake", que para eso estamos nosotros los moderadores/administradores. Y si se producen, tengo el dedo flojo... ![]() ![]() ![]()
__________________
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. |
|
#89
|
|||
|
|||
|
Cita:
|
|
#90
|
|||
|
|||
|
Yo entiendo que la regulación de los SIF's está definida reglamentariamente por la orden ministerial, a la hora de emitir una factura, que indica cómo debemos actuar y qué procesos posteriores debemos seguir cuando emitimos una factura.
Los documentos intermedios que hemos utilizados para generar esta factura no están reglamentados en esta orden ministerial ya que no son documentos fiscalmente válidos. La Ley 11/2021 en su artículo 29.2.j hace referencia a esta regulación siempre refiriéndose a los "Registros" y nunca a documentos como la factura, el albarán, la prefactura, etc. Estos registros son lo que estamos obligados a emitir cunado se genera una factura. Por otro lado, el artículo 201.bis de esta misma Ley, dice literalmente Apartado 1 define como infracción tributaria grave la fabricación, producción y comercialización de sistemas y programas informáticos o electrónicos que: a) permitan llevar contabilidades distintas en los términos del artículo 200.1.d) de esta Ley; b) permitan no reflejar, total o parcialmente, la anotación de transacciones realizadas; c) permitan registrar transacciones distintas a las anotaciones realizadas; d) permitan alterar transacciones ya registradas incumpliendo la normativa aplicable; e) no cumplan con las especificaciones técnicas que garanticen la integridad, conservación, accesibilidad, legibilidad, trazabilidad e inalterabilidad de los registros, así como su legibilidad por parte de los órganos competentes de la Administración Tributaria, en los términos del artículo 29.2.j) de esta Ley; f) no se certifiquen, estando obligado a ello por disposición reglamentaria, los sistemas fabricados, producidos o comercializados los puntos e) y f) son los que regula la orden ministerial (Verifactu), pero no existe desarrollo normativo para los puntos a), b), c) y d) que son los susceptibles de aplicar a estos documentos intermedios que utilizamos para llegar hasta una factura. El apartado a) sería aplicable a los programas de contabilidad, impidiendo que pudiéramos tener la misma empresa definida con dos contabilidades distintas. O sea, para un mismo obligado tributario y año fiscal sólo podría existir una entrada en el programa. El apartado b) impide que tengamos series de facturas ocultas que no registren la realidad de las ventas. El apartado c) impide que podamos generar ventas de forma aleatoria que sustituyan a las realizadas realmente. El apartado d) impide que podamos alterar facturas ya emitidas sustrayendo alguna línea o modificando cantidades. Entiendo que para poder cumplir con los puntos a, b, c y d, sería necesario que los documentos intermedios siempre quedaran enlazados a la factura final para poder "trazar" la creación de un documento sin ningún género de dudas. Estos documentos intermedios pueden ser alterados hasta la creación de la factura final donde quedarían bloqueados y conservados. Yo personalmente, no los eliminaría aunque no hayan llegado a convertirse en factura para mantener una consecutividad en los contadores. Optaría por abonarlos con líneas en negativo dentro del mismo documento hasta dejarlo a cero. Hay un caso claro que refleja esta necesidad, cuando se emite una prefactura a una mesa en el ámbito de la hostelería. Si dicha prefactura se la enviamos a la mesa al cliente y paga sobre la marcha, podemos no convertirla en factura cuando nos llegue al tpv, con lo que hemos generado una venta que no se va a subir a Verifactu. |
|
#91
|
|||
|
|||
|
Cita:
El movimiento bancario va desligado a la emisión de la factura o de su RF correspondiente, por lo que si al final el cliente se echa para atrás y decide no pagar por el bien o servicio, tendrás que hacer una rectificativa o abono y generar su correspondiente RF. |
|
#92
|
|||
|
|||
|
Cita:
El pago del total del documento o de una parte del mismo te obliga a generar una factura en ese momento aunque no se haya ejecutado el servicio y por lo tanto debes generar tu RF. Si no se produce el pago pero sí se ha producido la venta y el destinatario es un cliente particular, la factura y su RF se emiten en el mismo momento de la venta por Ley. Si el destinatario es empresa o profesional, tienes hasta el día 15 del mes siguiente para emitir la factura y por tanto, su RF |
|
#93
|
||||
|
||||
|
Siento retomar este tema tan tarde pero estoy releyendo post antiguos y he topado con este y la verdad que sigo con la duda. Que habría que hacer si tenemos opciones para generar borradores o proformas o albaranes previos a una factura, habría que guardar cada uno de ellos aunque no hubieran acabado en factura?? Podría eliminar el que me diera la gana ya que no es un documento fiscal???
Un saludo.
__________________
La religión es personal e intransferible. |
|
#94
|
|||
|
|||
|
Prefactura
Cita:
A la AEAT no le importan otros documentos no oficiales. Puedes crear un contador temporal de algo que se llame prefactura, borrador de factura, o simplemente "una hoja de apuntes". Por ende puedes agrupar los albaranes en ese documento temporal y posteriormente al crear la factura ya no los necesitarás. Esto viene bien para recapitulativas y agrupar o desagrupar albaranes antes de que exista el documento factura. Recuerda que las facturas deben ir ordenadas por fecha de documento, número de documento y por fechahora creacion de registro. Lo que hagas con esos documentos temporales es asunto tuyo. Si tu soft solo hace facturas de TPV no vas a necesitar (no se me ocurre otra forma) ningún sistema de temporalidad para agrupar albaranes. Otra cuestión bien distinta es un archivo temporal de albaranes. El albarán por si mismo es un documento de transición a la factura pero no se puede modificar una vez expedido. Sus números deben ser correlativos en la serie que hayan sido emitidos y no puede faltar ninguno. Cerrado el albarán y expedido al cliente no se puede volver a modificar. Y en cuanto a que un albarán no termine en factura, mejor me reservo el comentario. Espero haberte sido útil con mi respuesta. Un saludo. |
|
#95
|
|||
|
|||
|
Cita:
|
|
#96
|
||||
|
||||
|
gracias por la respuesta ^^
__________________
La religión es personal e intransferible. |
|
#97
|
|||
|
|||
|
Buenas, os pongo en situación, un cliente tiene un programa hecho por ellos pero no van a realizar la programación del veri*factu, despues de tener varias reuniones nos comentan si pueden mandarnos los datos del albaran a nuestro SIF (que tambien lo tienen) y desde alli seguir para facturar y enviar al Veri*factu, la duda que tiene mi jefa es si puede haber en dos SIF distintos el mismo albarán aunque solo se facture en uno de ellos, si se incumple alguna ley, ahí ya me pilla y no se la respuesta, jaja.
|
|
#98
|
|||
|
|||
|
Cita:
Aún no han publicado ejemplos de declaraciones responsables, pero puedes ir preguntándole al correo de verifactu. |
|
#99
|
|||
|
|||
|
Bueno, entonces ellos que son los que hicieron el programa que no va a facturar tendran que hacer su DR correspondiente y nosotros como no, del nuestro que si enviara al SIF. De todas formas se le va a proponer que entren en el SII porque van a poder seguir con el SIF propio haciendo todo como hasta ahora (que tienen muchas cosas particulares que se han ido diseñando) y luego desde el nuestro podran enviar al SII las facturas ya que tienen una importación de facturas que estan usando para incorporar sus facturas a nuestra contabilidad.
Gracias por la respuesta @ermendalenda |
|
#100
|
|||
|
|||
|
Cita:
La DR se la tienes que dar tu, ellos tienen que habilitar el acceso en su software a esa DR y la que ellos hagan En el caso de ellos yo pondría en la DR principal, como se comporta el SIF, aue solo es para albaranes , pedidos etc, y que se usa el componente o servicio para generar las facturas y su envío a verifactu y unasegunda DR con vuestra DR. Yo lo tengo más o menos así en una instalación. Un. Botón en la que se abre un pdf con las 2 DR |
![]() |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Consulta QR Verifactu | JoseLeeTo | Envío de registros y sus respuestas | 11 | 02-12-2025 19:44:09 |
| Cumplir VeriFactu | xevi | General/Noticias | 2 | 04-11-2024 12:12:40 |
| verifactu | jguarda | Internet | 1 | 03-10-2024 17:48:17 |
| Tabla de Facturas vs Detalles de Facturas | magnu9 | Conexión con bases de datos | 9 | 27-07-2007 17:27:37 |
| Campos calculados, facturas y detalles de facturas. | Letty | Conexión con bases de datos | 7 | 07-11-2003 11:19:44 |
|