![]() |
Cita:
También me sorprendió. |
Cita:
|
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. |
Cita:
Lee la ley antifraude |
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. " |
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. |
Cita:
|
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... :D:D ![]() |
Cita:
|
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. |
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. |
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 |
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. |
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. |
Cita:
|
gracias por la respuesta ^^
|
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.
|
Cita:
Aún no han publicado ejemplos de declaraciones responsables, pero puedes ir preguntándole al correo de verifactu. |
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 |
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 |
Ok, si al final no quieren entrar al SII haremos eso. Gracias.
|
buenas de nuevo,
cito web de la AEAT: Cita:
|
Cita:
Pufffffffffffffffffffffffffffffffffff..... pues esto si que es una movida y gorda. |
Cita:
O sea, yo interpreto que se guarden y vinculen los pedidos, albaranes, presupuestos y facturas proformas o que de alguna forma se puedan posteriormente estar vinculados demostrando la trazabilidad,pero descarcanndo el vínculo con los pedidos y proformas no facturadas ya que no necesariamente se convierte en una faxtura y cuando se convierte puede que se cargue de nuevo se modifique total o parcialmente y después se facture. Digamos que sí, que tengas algo pero no te obsesiones. Si hacen una inspección y ven que hay algo gordo entonces tiraran de esto pero no van a ir a por esos vínculos por que sí. Depende tambien de lo cabreado que esté el inspector, no olvidemos que son humanos y tienen esas cartas, si las quieren usar.. |
No olvidemos que lo que está reglamentado tecnicamentw es verifactu, ahí si hay que ser estrictos el resto de la normativa la reglamentais " tecnicamente" cada uno como podáis, si lo haceis bien o mal es muy discutible, por ejemplo con decir que si quiere que haya una trazabilidad de los pedidos en un rango de fechas hay que ponerse a sacar y cruzar datos cuando se pidan y cuadrarlo manualmente. Y que te van a decir
|
Hola, estamos en las mismas, lo que no quieren es que como no podemos hacer facturas y luego modificarlas, nos dediquemos a hacer proformas, y borrarlas, porque ya sabéis que los autónomos y empresarios , somos unos estafadores que nos dedicamos a facturar 1000€ al cliente y presentar 10€ a hacienda.
Lo siento pero es que me pilla de cerca una insinuación así y ya empiezo a estar harto de ello, ya hace años que una vez guardada una proforma, si permito modificarla mientras no este facturada, a partir de ahí no permito su modificación y nunca permito borrarlas, así que garantizo la trazabilidad, cuando facturo una proforma, la señalo como facturada y le asigno en una tabla de la base de datos la factura resultante, imagino que con los albaranes haréis lo mismo. |
Un poco de cordura, por favor.
Cita:
¿ Qué es lo que no quiere nuestra "amiga" la AEAT ? ¿ No quiere que usemos archivos temporales para crear documentos ? Es decir todos los archivos temporales que se crean en una B.D. hasta que finalmente se generan los registros definitivos de la factura van a ser cuantificados por alguien ? ¿ Estmos locos ? La AEAT querrá ver que los albaranes una vez emitidos no se modifiquen. Pero ¿ quieren ver si añadimos una línea, salimos a comer y añadimos 3 mas después ? Lo que les importa es que no se pueda modificar una factura expedida (o recibida si es autofactura). De toda la vida NO SE PUEDE modifica un albarán emitido ni una factura emitida. Los procesos que use cada programa para generar la factura a la AEAT se la repampinfla, para comenzar porque son procesos temporales a partir de los cuales los procedimientos crean el documento. Si queremos ser puristas tampoco se pueden modificar las reservas de material (compra o venta), Eso sí, una vez finalizadas. ¿ O vamos a tener detrás un inspector para ver como hacemos una propuesta de pedido ? Ya sería de coña. Otra cuestión bien distinta es el uso que se den a esos archivos temporales. Si creas un documento y le llamas factura tendrás un problema. También si lo haces con un excell, lo expides y posteriormente lo modificas. Justo eso es lo que quiere corregir la AEAT con su vigilancia y su código de barras verificable. Quiero recordar que el proceso correcto es generación de albarán y posterior emisión al finalizar la creación. Seguido de una factura o bien recapitulativa en su momento o bien una factura en el momento. Y no hay mas. La prefactura es un momento de aglutinación de albaranes temporal y solo para recapitulativas. A partir de la creación de la factura ya no hay temporales, no existen. ¿ Para qué deberían existir ? Imagina que deseas crear una factura, creas el temporal para la factura, posteriormente eliges no hacerla, borras el temporal. Al igual que la vida misma los temporales nacen, crecen y desaparecen. Por eso son temporales. Hay temporales para generación de cartera y cálculo de vencimientos, temporales para creación de cabeceras, de pie de documento, contables, etc. ¿ Vamos a archivarlos todos ? ¿ Para qué ? Si el contador de temporal no importa a nadie, tal vez ni siquiera tenga ni contador sino un código dependiente de un conexto. En síntesis, no creo que la AEAT se refiera a archivar los pasos que ocasionan la generación de un registro. Atte. Un programador mas en la lucha por subsistir ante adversidades tributarias. :D |
Ojalá sea como comentas, no le veo sentido almacenar lo temporal / borrador una vez convertido en factura.
Pero la cita en la web de la AEAT menciona documentos preparatorios como borradores, prefacturas... https://sede.agenciatributaria.gob.e...00dc381e0aRCRD |
Es que si nos ponemos tiquismiquis hasta un word o un excel valdría como programa informático de pre-facturación y no por ello te van a hacer guardar cada word que generes no vaya a ser...
Entiendo que los tiros van mas hacia si implementas un generador de pro-formas, albaranes etc. en tu programa ahí si que tendríamos que guardar los mismos. Pero igualmente me parece un poco chorrada y algo que no van a poder controlar. |
Reseña de la AEAT
Cita:
La reseña creo que dice que hay que guardarlos pero no entiendo por qué habría que hacerlo. Personalmente me implica pocos cambios en el soft pero me parece absurdo. Imagina que haces recapitulativas. Estás en prefactura, terminas una y generas la factura correspondiente, pendiente de insertar en contabilidad y de enviar al SIF. Tanto la prefactura como la factura van a ser siempre idénticas. Lo único que me parece razonable es que se limite el listado o el envio por email de una prefactura para evitar suspicacias. ¿ Qué ocurre cuando la AEAT NO admite la factura porque contiene errores ? Recuperas la prefactura a partir de la factura, corriges los errores y vuelves a generar la factura que ocupará su lugar original. Sin perder de vista los hash que en cada proceso se generan nuevos y sin perder la cadena. Pero repito, van a ser idénticas siempre. Atte, |
Cita:
Título: BORRADORES DE FACTURA, “PRE-FACTURAS”, FACTURAS PROFORMA, ALBARANES, FACTURAS DE PRUEBA… https://www.agenciatributaria.es/sta...rolladores.pdf |
que cachondos, pretenden que las facturas de pruebas o para formación también las subamos y luego las anulemos.... :D
|
Bajo mi punto de vista han perdido un poco el norte con estos dos temas. Lo de conservar las "prefacturas" es una ridiculez como dice el compañero es un estado previo del documento no un documento en si con lo que no tiene sentido su conservación. Y lo de las DEMOS ya es la flipada total, si ya cuesta que la gente instale una demo imagina q le exija el certificado y le digas que va a mandar cosas a la AEAT. :confused::confused:
Creo que la AEAT deberia pensar en hacer una nueva reunión con los desarrolladores pq se les está llendo la pinza con todo. |
Buenos días:
Ayer envié la siguiente consulta a [email protected]: En el documento 'ACLARACIONES A DUDAS DE DESARROLLADORES' publicado con fecha 05/05/2025, en la cuestión nº 11 "BORRADORES DE FACTURA, “PRE-FACTURAS”, FACTURAS PROFORMA, ALBARANES, FACTURAS DE PRUEBA", se incluye en la explicación el concepto de "FACTURA PROFORMA", que en la realidad diaria se asemeja más a un PRESUPUESTO, en el sentido de que pueden confeccionarse gran número de ellos, pero al final ser aceptados muy pocos por parte de los clientes, por lo que nunca estarán enlazados a un pedido, albarán y mucho menos una factura. En nuestro SIF, la introducción de un Presupuesto, Proforma o Pedido, son opcionales, siendo únicamente obligatoria la introducción de un Albarán de Entrega, que al facturarse, quedará ligado a esa factura, y desde ese momento, dicho albarán, no podrá ser modificado ni borrado. Así mismo, si se introduce un Presupuesto o Proforma, puede ser convertido en un Pedido, o directamente en un Albarán, y un Pedido puede ser convertido en Albarán, que como he explicado en el párrafo anterior, es el único documento obligatorio para la confección de una factura posteriormente. Incluso si se ha llegado a introducir un Pedido, es posible que, el cliente termine por cancelar toda la operación, y por tanto no generará ni albarán ni la posterior factura. En esta situación, lo habitual es borrar ese o esos pedidos, para evitar confusiones. Teniendo en cuenta todo esto, sería correcta la posibilidad de borrar los Presupuestos, Proformas y Pedidos descartados ? Hoy me han contestado lo habitual últimamente: Buenos días: Remitimos su consulta a los responsables para su valoración. En cuanto tengamos cualquier novedad le informaremos. Si me llegan a contestar ya os diré. Un saludo. |
Cita:
*Vamos , cualquier tipo de presupuesto, lo llames , pre-factura, presupuesto, pro forma, etc..., que puedas imprimir para pasarle al cliente y según ellos, luego modificar para facturar y pagar menos impuestos, sin entregarle al cliente final la factura definitiva, empiezo a estar un poco molesto con el tema, se nota?? :mad: **Ojo, no me refiero a ningún partido ni pollas en vinagre, me refiero a hacienda y demás sistemas contables y de recaudación...:cool::cool: |
A mí lo que más me molesta es que con la redacción que han dado a la Ley, se han quitado el muerto de tener que demostrar que defraudas, y nos lo han pasado a nosotros, los desarrolladores.
Lo que no sé hasta que punto sería correcto porque en jurisprudencia, la carga de la prueba siempre corresponde a quien denuncia, en este caso sería la Agencia Tributaria. Recordar que es sancionable "la mera tenencia de un programa que no cumpla la Ley Antifraude", lo que en la práctica supone que, incluso si a un cliente le instalas un SIF certificado y correcto, pero le dejas instalado el anterior que no cumple la Ley, podrían sancionarle. "Cortita y al pie" como dicen los futboleros. |
Presupuestos y proformas
Cita:
Los únicos documentos que la Ley Gral de Facturación indica que deben ser consecutivos en su número de documento y serie y que deben ir ordenados por fecha son los albaranes y las facturas. Las facturas es evidente que ellos lo pueden saber a partir de los registros de facturación, (330, consulta del registro de los libros contables, etc). Los albaranes se pueden solicitar en un caso de inspección (poco frecuente pero ya he visto alguno). Entre otras cuestiones porque generalmente en las propias facturas se suele indicar el número de albarán y la fecha. Con respecto a las reservas de material (pedidos) que yo sepa no hay ninguna ley con carácter vinculante y que si los eliminas pueden incurrir en infracción. He visto que en muy contadas ocasiones algún subinspector preguntó por ello insitu, en casa del cliente. Pero sin mayor trascendencia. Los pedidos se pueden anular, servir, devolver, volver a crear, etc. Aunque se consideran documentos - contrato de compra y venta. Pero nada indica que has servido un pedido a menos que desencadene en un alblarán. En el caso de las proformas y presupuestos, es papel mojado. Los creas, los borras, los modificas, etc.etc y si quieres los inventas. Es mas, tengo la impresión de que forman parte de los datos a los que la AEAT no debe tener acceso. Aunque nunca se sabe a la vista de lo que estamos hablando aquí. Personalmente no le voy a dar mas vueltas, si quieren que no se eliminen las prefacturas no hay problema, se les marca un status de ya procesadas y ahí siguen, sin mas. Una cosa es que queden vinculadas y otra que se encadenen como las facturas. De ello no hay constancia. De momento. Un saludo. |
Van cambiando, hace unos meses dijeron que la ley sólo afectaba a las facturas, puesto que era lo que estaba regulado en el reglamento, ahora esto.
|
Una pregunta, hablando de proformas, nosotros lo único que tenemos es la opción de facturar los albaranes o sacar un impreso (sin guardar nada) con la anotación de PROFORMA. ¿Tendriamos que guardar esa "PROFORMA" fisicamente?
|
Cita:
|
| La franja horaria es GMT +2. Ahora son las 13:23:14. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi