![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
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. |
|
#2
|
|||
|
|||
|
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. |
|
#3
|
|||
|
|||
|
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 |
|
#4
|
||||
|
||||
|
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. |
|
#5
|
|||
|
|||
|
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. |
|
#6
|
|||
|
|||
|
Cita:
|
|
#7
|
||||
|
||||
|
gracias por la respuesta ^^
__________________
La religión es personal e intransferible. |
|
#8
|
|||
|
|||
|
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.
|
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
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 |
|