![]() |
![]() |
| 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
|
||||
|
||||
|
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. |
|
#2
|
|||
|
|||
|
Cita:
|
|
#3
|
|||
|
|||
|
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. |
|
#4
|
|||
|
|||
|
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. |
|
#5
|
|||
|
|||
|
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 |
|
#6
|
||||
|
||||
|
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. |
|
#7
|
|||
|
|||
|
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. |
|
#8
|
|||
|
|||
|
Cita:
|
![]() |
| 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 |
|