24-09-2026, 12:35 AM
Perfecto, entendido. Gracias por aclarármelo. Y genial que podáis añadir la fecha de última modificación a la ficha de producto en la próxima versión.
Respecto al tema de los lotes, ahora que me comentas que el campo de fecha necesita obligatoriamente una fecha válida, quizá podría plantearse de otra manera, sin cambiar el funcionamiento actual de los lotes.
La idea sería mantener todo como está ahora y añadir simplemente una pequeña opción junto a Fec. Caducidad, por ejemplo una casilla de verificación:☑
Que aparezca activada por defecto, de manera que para cualquier usuario que utilice los lotes con fechas de caducidad el funcionamiento siga siendo exactamente el mismo.
Pero cuando un usuario quiera utilizar el lote únicamente para asociar otro código de barras al producto, podría desmarcar esa casilla. En ese caso, la fecha podría seguir apareciendo y guardándose como hasta ahora, pero quedaría indicado que esa fecha no debe considerarse como fecha de caducidad ni mostrarse posteriormente en el terminal de venta o en el ticket.
Por ejemplo, en un lote normal:
Cód. barras: xxx
Núm. Lote: xxxx
Fec. Caducidad: ☑ 01/01/2028
Y en el caso de utilizar el lote únicamente para asociar un código de barras adicional:
Cód. barras: xxx
Núm. Lote: xxxx
Fec. Caducidad: ☐ 01/01/2028
En este segundo caso, la fecha seguiría existiendo porque el campo la necesita obligatoriamente, pero al estar desmarcada la opción de Fec.Caducidad, esa fecha no tendría que aparecer en el terminal de venta ni en el ticket cuando se venda el producto.
De esta forma, se podría seguir utilizando el sistema de lotes para reconocer ese segundo código de barras sin que una fecha que realmente no corresponde a una caducidad pueda aparecer posteriormente al cliente.
Además, al estar la opción activada por defecto, para los usuarios que sí trabajan con fechas de caducidad no cambiaría prácticamente nada del funcionamiento actual. Solamente habría que desactivarla en aquellos casos en los que el lote se utilice para otros fines, como este caso de los códigos de barras adicionales.
No sé si técnicamente sería sencillo de implementar de esta forma, pero creo que podría ser una solución bastante limpia y flexible, manteniendo la lógica actual de los lotes y aprovechando el campo de fecha que ya existe.
Te lo comento simplemente como idea, por si ves que puede encajar bien y no supone demasiado cambio a nivel interno.
Respecto al tema de los lotes, ahora que me comentas que el campo de fecha necesita obligatoriamente una fecha válida, quizá podría plantearse de otra manera, sin cambiar el funcionamiento actual de los lotes.
La idea sería mantener todo como está ahora y añadir simplemente una pequeña opción junto a Fec. Caducidad, por ejemplo una casilla de verificación:☑
Que aparezca activada por defecto, de manera que para cualquier usuario que utilice los lotes con fechas de caducidad el funcionamiento siga siendo exactamente el mismo.
Pero cuando un usuario quiera utilizar el lote únicamente para asociar otro código de barras al producto, podría desmarcar esa casilla. En ese caso, la fecha podría seguir apareciendo y guardándose como hasta ahora, pero quedaría indicado que esa fecha no debe considerarse como fecha de caducidad ni mostrarse posteriormente en el terminal de venta o en el ticket.
Por ejemplo, en un lote normal:
Cód. barras: xxx
Núm. Lote: xxxx
Fec. Caducidad: ☑ 01/01/2028
Y en el caso de utilizar el lote únicamente para asociar un código de barras adicional:
Cód. barras: xxx
Núm. Lote: xxxx
Fec. Caducidad: ☐ 01/01/2028
En este segundo caso, la fecha seguiría existiendo porque el campo la necesita obligatoriamente, pero al estar desmarcada la opción de Fec.Caducidad, esa fecha no tendría que aparecer en el terminal de venta ni en el ticket cuando se venda el producto.
De esta forma, se podría seguir utilizando el sistema de lotes para reconocer ese segundo código de barras sin que una fecha que realmente no corresponde a una caducidad pueda aparecer posteriormente al cliente.
Además, al estar la opción activada por defecto, para los usuarios que sí trabajan con fechas de caducidad no cambiaría prácticamente nada del funcionamiento actual. Solamente habría que desactivarla en aquellos casos en los que el lote se utilice para otros fines, como este caso de los códigos de barras adicionales.
No sé si técnicamente sería sencillo de implementar de esta forma, pero creo que podría ser una solución bastante limpia y flexible, manteniendo la lógica actual de los lotes y aprovechando el campo de fecha que ya existe.
Te lo comento simplemente como idea, por si ves que puede encajar bien y no supone demasiado cambio a nivel interno.