![]() |
Yo lo bueno que tenemos es que el tema de "sucesos" es para cualquier fichero, si lo activo cualquier modificación que sufra un registro se queda registrado en un bd donde indica quien lo hizo, la hora, si fue alta, baja, modificación, que se modifico si es el caso. Yo creo que con eso lo tendría cubierto. Luego hay un formulario donde puedes filtrar y ver que se hizo en unas fechas en cualquier sitio.
|
Cita:
|
Cita:
En la primera versión vamos a hacer algo similar a lo que comentas. Guardar algo de información de la Prefactura cuando se hace alguna de las 4 operaciones (Alta, modificación, borrado y Facturar). |
Cita:
Creéis que con un comentario general, así: Cita:
|
Pero veo que hay algo que se nos escapa, si estamos hablando de generar "registros", para gestionar las vida de un albarán por que "emana del espíritu de la norma:confused:" tendremos que asegurar, como indica dicho espíritu, la trazabilidad mediante encadenamiento de los registros que arroja dicho documento, la integridad e inalterabilidad mediante funciones hash o firmado electrónico, la conservación de dichos registros, la legibilidad y la accesibilidad. ¿ O estoy yo exagerando ?
|
Cita:
|
Cita:
Lo que nosotros entendemos (o queremos entender) es que no se puede modificar una vez que se expida. ¿que significa expedir un albarán? Según creemos sería facturarlo ¿que significa expedir un borrador de factura o prefactura? Según creemos sería validarla y convertirla en factura. En nuestro programa tenemos albaranes, que se convierten en borradores de factura y luego si se validan se genera la factura definitiva. El borrador lo puedes eliminar porque es precisamente para eso, si detectas que algo está mal poder darle para atrás, modificar el albarán y volver a generarlo. Y una vez que le des el OK lo validas y aparece la factura final (que ésta sí que no se puede modificar). En este momento, cuando aparece la factura, es cuando el albarán y el borrador están expedidos, y a partir de ese momento no se pueden modificar: no puedes tocar ni borrar ese albarán asociado a la factura porque está expedido y no puedes tocar ni borrar ese borrador asociado a la factura porque está expedido. Nosotros lo vemos así, pero bueno... es nuestra interpretación: los documentos anteriores asociados a la factura no se pueden tocar. Pero cuando estén asociados a la factura. Si no existe factura, no están asociados / expedidos. |
Cita:
En cuanto a numeración de facturas, a mi me respondieron en su día que lo que vale es el momento en que se genera el RF de una factura, que entonces la FechaEmision es igual a la FechaHoraHusoGenRegistro. Por ejemplo, yo puedo tener la factura 5 que finalicé después de la 10: la numeración no va correlativa, pero sí la fecha-hora del RF con su correspondiente factura. |
Bueno, aparte de la ley antifraude, hay que tener en cuenta que un albaran es un documento mercantil (nota de entrega) y que si se modifica y el receptor tiene copia del albarán con otra mercancía podría haber un problema.
Una anotación a boligrafo en el mismo albarán para indicar que hay cosas incorrectas y modificar informatucamente y posteriormente el albarán puede estar bien si está en la copia del cliente y del emisor para poder modificarlo, aunque creo que es más viable crear un albarán de rectificacion, así nos lo piden algunos clientes, supongo que por hacer una contabilidad al día más fácil. |
Cita:
|
Documentos preparatorios
Expongo la Consulta realizada a Verifactu y su respuesta
Buenas tardes. Respecto del documento de aclaraciones para los desarrolladores, y en concreto, a las menciones sobre los documentos preparatorios para la emisión de una factura, albaranes, prefacturas, etc. el espíritu que emana de la norma, "no se produzcan alteraciones ni omisiones de los que no quede constancia en el sistema" me pregunto si las afirmaciones que paso a describirles cumplen con dicha idea. 1.- La utilización de cualquier documento preparatorio previo a la factura, albarán, presupuesto, proforma, prefactura, etc, te obliga a mantenerlos en tu sistema, pero se pueden modificar hasta el momento de emitir la factura definitiva, en ese momento, quedan indefectiblemente unidos a la factura emitida y no se pueden modificar. ( ver párrafo …. De la misma forma, hasta ese momento, cualquier alteración que se produzca en ese registro, previo al RF, sería perfectamente lícita…) 2.- Cuando estos registros preparatorios, como el albarán o prefactura, no lleguen a su estado final, convertirse en factura, éstos deben permanecer en el sistema. (Ver párrafo … A lo anterior hay que añadir, no obstante, la exigencia de conservación de los registros preparatorios siempre que estos no acaben siendo finalmente validados en forma de factura (por ejemplo, resulta obligado conservar los registros de facturas proformas emitidos)… 3.-Si los quisiera anular, emitiré un documento de abono de dicho registro preparatorio. Ver párrafo … (salvo que la alteración se produzca por medio de un registro posterior, que también deberá quedar anotado en el sistema). En resumen, se puede editar cualquier documento preparatorio hasta el momento de la expedición de la factura. Una vez expedida la factura, se deben mantener inalterables en el sistema todos los documentos relacionados con dicha expedición. Los documentos preparatorios que no hayan llegado a su finalización en forma de factura hay que mantenerlos y en su caso, emitir abono de documento que quedará registrado Gracias por su tiempo Respuesta de Verifactu Buenos días: Lo expuesto parece ajustarse y ser conforme con lo indicado en la aclaración/FAQ a desarrolladores nº 11 «BORRADORES DE FACTURA, “PRE-FACTURAS”, FACTURAS PROFORMA, ALBARANES, FACTURAS DE PRUEBA…"» del documento "Preguntas frecuentes de empresas de desarrollo (actualizado 16-05-2025)" publicado -y actualizado recientemente- en la web de desarrolladores de la AEAT. Atentamente, Atención al Usuario Departamento de Informática Tributaria Email: [email protected] |
Perfecto, no se han explayado mucho en la respuesta pero confirman lo que se intuía.
Lo que se deduce al final es que un albarán creado no se puede eliminar, esto seguro que les gusta a los clientes, no poder eliminar, xD. El tema que ahora caigo es que si el albaran no se factura y se hace otro de abono como dicen vamos a tener dos albaranes pendientes de facturarm que me van a salir como pendientes junto con los "buenos" cuando el cliente vaya a facturar, va tocar marcarlos de alguna forma para que no salgan pendientes. |
Aqui os dejo un parrafo de la FAQ de desarrolladores de Verifactu, en la que subrayo lo más importante que nos preocupa, que tengo que conservar que no sean facturas y que pueden afectar en proformas, presupuestos, albaranes, pedidos...
Cita:
-En parte veo un alivio, ya que no se aprecia que estén obligando a que cualquier evento(por ejemplo mientras estamos generando un pedido y borramos una linea), sea necesario crear una log, otra cosa es que por control interno lo tengamos. Lo que si veo es que una vez validado ese pretiquet/pedido/comanda/prefactura/albaran..., y si no se materializa en factura, lo tengamos que conservar. Observo que la modificación de lineas de pretiquets, prefacturas, albaranes, pedidos...puede ser un tema de interpretación de la norma, ya que puedes considerar que un pretiquet, prefactura... puede tener un proceso de validación y hasta que no se valide puede interpretarse que no llega a materializarse en registros y por tanto me lleva a la pregunta ¿En que momento un pretiquet es validado?, por que simplemente pueden estar consultando precios. Atendiendo a mi estructura de programaque tiene varios modos de trabajo parametrizables considero lo siguiente: -Modo de trabajo 1: para enviar preparación del pedido es necesario previo pago. Por tanto no veo necesario guardar nada aparte, auqneu mientras se este generando el pedido se borren/añadan productos/servicios. -Modo de trabajo 2: se envia preparacion del pedido y se paga posteriormente(al servir pedido). En este caso puede existir un impago, este caso es el que considero "peligroso", ya que se puede estar cobrando sin facturar, aqui si veo necesaria la conservación. ¿Que límite interpretais cada uno? Abro debate!!! |
Cita:
Si hay pedido, hay factura. No tiene nada que ver ni con su pago ni su entrega. Ha habido operación comercial, debe haber factura. |
A ver... es que esto se puede interpretar de varias formas:
Código PHP:
Yo puedo entender que si se valida como factura no necesito conservar la proforma previa (por ejemplo). Esto tiene su sentido porque es posible que una proforma "desaparezca" sin convertirse en factura por lo que se estarían dejando ventas sin declarar. Igualmente según esto una proforma no convertida en factura habría que mantenerla y una que se ha convertido en factura puede borrarse. Yo en mi caso dejo registro de TODO lo que se hace, mejor pecar por exceso que por defecto en esto. Y finalizando estoy totalmente seguro de que habrá sectores en los que se haga la operación de venta y se cobre con una proforma y de esa proforma nunca se hará factura (por ejemplo esto lleva pasando en hostelería desde hace mucho) por lo que esas proformas se deberían de quedar en el sistema. Saludos. |
Cita:
1. El camarero te da la cuenta en pretiquet/proforma y no te dá la factura(practica habitual que es incorrecta pero ya te digo que he observado este comportamiento en infinidad de comercios hosteleros y finalmente cobran la cuenta). 2.al estar todo de cara al publico somos mas observadores pero con errores en la observación. 3. Errores frecuentes en marcaje en mesas incorrectas. 4. Es el gremio que más simpas tiene, despues los super, centros comerciales.. 5. Tiene mas numero de transacciones respecto a otros gremios y hay momentos de gram estres, con lo cual la posibilidad de error aumentam. 6. En muchisimos casos van por estimacion objetiva, así que da igual lo que factures y si no te dan tiquet. 7. El sector hostelero tiene un peso de mas del 12% en España, asi que fijate el numero de facturas que se pueden emitir, y si hay empresarios fraudulentoa, ya te digo que puwde ser gran numero, pero el porcentaje seguro que es menor que en infinidad de otros negocios. Deberias ser mas observador co. Otro tipo de negocios, hay constantes noticias de los gremios a los que pillan. Y no me gusta acusar a ninguno aunque he visto cosas extrañas ppr que ni siquiera se a que regimen están. Se puede dejar esos juicios para la AEAT que para eso le pagamos. No te digo que hace mucjos años era practica mas habitual, pero han hecho mucjas abatidas y en hosteleria ya se ha castigado mucho. |
Cita:
Bueno... cada uno tendrá su experiencia. Yo te puedo decir que en los restaurantes/bares donde consumo (que no son clientes míos porque yo no contemplo de momento el famoso "preticket") me dan un documento...pago sobre ese documento y me dan el cambio junto con el mismo "preticket". Eso te puedo asegurar que es en una proporción de 1/10. Sin embargo vas a cualquier otro tipo de comercio y ese invento del "preticket" no se conoce, compras y te dan una factura simplificada. |
Cita:
Mira, solo tienes que pensar una cosa, si eso fuera así y como está el mundo de la hostelería, cualquier camarero que esté descontento en el trabajo(y como sabes hay miles y denuncian cualquier cosa) acabaría denunciando la práctica, ¿crees realmente que los empresarios se arriesgan a esto?. El hecho de que el camarero, tras realizar el cobro, entregue el pre-ticket en lugar del ticket final constituye una mala praxis. No responde necesariamente a una intención de fraude, sino más bien a la rapidez con la que se desarrolla su trabajo y las operaciones de cobro. Aun cuando el empresario lo recalque, resulta difícil lograr que esta práctica se corrija de forma efectiva. Te lo digo con conocimiento de causa de muchisimos años. |
Cita:
Buenos días compañero. Efectivamente el comentario venía al tema de los documentos "pre" factura, que en este caso la mayoría de las veces no se entrega la factura correspondiente y que, a mi entender, debería de entregarse por norma porque otra cosa es sospechosa. No es mi intención criticar ni mucho menos demonizar el gremio, solo comento la realidad de lo que pasa. No vamos a entrar en polémica sobre este asunto en este hilo así que seguiremos con nuestras ñapas de Verifactu :rolleyes:. Saludos. |
Cita:
De todas formas ya la AEAT debe tener su propia vigilancia basada en las ventas ubicavion, njnero de empleados... de cada comercio y si se les sale de las cuotas que esperam seguro que actuan. |
Cita:
*Ojo, que soy mecánico, y me he puesto primero, pero estoy hasta el cielo de que me acusen , gente que ni me conoce de trabajar en negro, por eso lo comento, no para hacer sangre ni nada de eso, simplemente para poneros en causa, fácilmente puedo hacer 4/5 veces mas pro-formas al mes que facturas y de las pro-formas o presupuestos como queráis decirlo me aceptan un 2/3 por ciento,(El cliente, cliente no pide presupuesto, pide que le repares el coche), así que podéis imaginar lo que parece, que hago las reparaciones que presupuesto, pero no las presento, en fin lo dicho cada gremio tenemos una "Cruz"..., yo personalmente, no borro las pro-forma, se facturen o no, simplemente marco las facturadas, por control interno. Un saludo y haya paz... |
Cita:
|
Cita:
TipoUsoPosibleMultiOT="S" IndicadorMultiplesOT="S" |
Cita:
|
Chicos, chicas y chiques.
Hay novedades en la respuestas dd las proformas/pedidos/albaranes/prefacturas en cuanto a trazabilidad, para bien... sigo preguntando y os comento. |
Cita:
Para bien nuestro ? |
Miedo me da, jaja. Ya contaras.
|
Cita:
|
Cita:
Uh.... qué intriga... :rolleyes: |
Lo siento, falsa alarma, aclarado. Sigue todo igual. Trazabilidad por un tubo.
Me habian hablado de que los documentos preparatorios para hacer la factura se podian modificar sin crear trazabiliidad y en principio parecia que era todo , albaranes...pedidos, y por ultimo que si un documento preparaorio no acababa en factura, tambien abono y trazabilidad, así que peor de ño que estabamos. Doxumen4o preparatorio=prefactura, no hablaban de albaranes ni proformas...todo esto trazabilidad Vamos a peor |
Cita:
Pos nada....nuestrogozoenunpozo. :mad: |
Cita:
Por cierto no se si alguien mas ha solicitado ser Colaborador Social. Nosotros mandamos la solicitud firmada hace un mes y seguimos a la espera de la firma de hacienda. Según dicen esta correcto pero se lo tienen que pasar a la directora general de la agencia tributaria y tiene muchos para firmar ¿?. Cita:
|
Chicos, sigo discutiendo con verifactu la poca claridad respecto a la aplicación/interpretación de las reglas de la ley antifraude respecro a pedidos/albaranes. Estamos ahora rebatiendo que son documentos preparatorios y sus rstados.
Sigo en ello a ver que conseguimos, al menos aclarar. |
Cita:
La interpretación que estais haciendo de los albaranes seria esta, cierto? |
Cita:
Pues, como en tantas cosas con la aeat, no creo que nadie tenga claro el tema. Yo en particular he optado por llevar una trazabilidad de todo, es decir, se introduce un albarán (vale), se modifica (se queda un registro de esa modificación), se anula (se queda un registro de la anulación), que no se anula y se factura (pues se acabó el tema porque ya no se puede modificar nada). Imagino que cada uno le habrá dado su solución pero al final lo que parece que está claro es que, en caso de inspección, le puedas mostrar al amable señor agente de la aeat de turno el recorrido que han tenido los documentos hasta generar la factura y por supuesto esa factura ya no se podrá modificar. Saludos. |
Yo el caso del albarán lo veo claro... al facturarlo ya no se puede modificar. Se lo compro, pero con matices... igual que en la factura puedes tocar por ejemplo las condiciones de pago o unas observaciones, en los albaranes supongo que también se podrán tocar algunos campos (siempre que no sean unidades, precios, importes, cliente, etc). Lo igualaría a la factura, no puedes tocar ningún dato que vaya en el registro de facturación.
Ahora, si nos vamos al pedido, la cosa ya se complica: yo puedo tener un pedido de 10 líneas en las que hoy sirvo 5 y por tanto genero un albarán con sólo esas 5. Ese albarán lo facturo y tanto el albarán como la factura no se pueden tocar. ¿Pero el pedido? Aún tengo otras 5 líneas pendientes que voy a servir la semana que viene. O el cliente me dice que borre o añada algo de lo que tiene pendiente. O que me pidió 5 unidades pero al final que sean sólo 3. Ese pedido no está finalizado, y por tanto (al menos en nuestro programa) podemos seguir modificándolo. Una vez que esté completamente servido ya se bloquea, pero mientras... Y en las ofertas, más de lo mismo No sé.. que quieran tener controlados los albaranes facturados y las facturas me parece bien, pero cualquier otro documento no le veo ningún sentido :confused: |
Yo teniendo en cuenta que...
1. un albarán NO es un documento de pago 2. un albarán es solo un informe para el transportista. Dice qué productos van en el furgón desde A hasta B. Quien lo use para otra cosa estará haciendo algo raro, pero el albarán es solo eso 3. un albarán puede tener errores, faltan productos, se rompen durante el transporte, el comprador no los acepta, vuelven al almacén, etc. 4. un albarán puede "facturarse" varias veces (primero una parte, luego otros 10 productos, etc. a medida que van llegando al almacén) 5. los albaranes no tienen por qué indicar los precios de los productos ni los totales, etc. No es obligatorio. Es solo un "registro de entrega" o de transporte 6. La Guardia Civil cuando registra una furgoneta, lo que le pide al transportista es el albarán. Y lo único que va a comprobar es que lo que dice el albarán es lo que lleva en el furgón. Para eso es, no para otra cosa En definitiva, que quieran controlar los albaranes es una locura. Se han venido arriba sin tener ni idea. Ojo, es mi punto de vista. Que le hayan dado tanta importancia a los albaranes, pero sin embargo las compras/gastos no se registren ni se envíen a VeriFactu, me parece un sinsentido mayor. |
Cita:
|
Cita:
No es por legalidad es por la logística. Pero para hacer la factura finalmente hay que valorarlos, en definitiva estamos en las mismas |
Cita:
|
| La franja horaria es GMT +2. Ahora son las 04:25:17. |
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