[14.0][FIX] l10n_es_pos: offline simplified number #2582
Conversation
|
@AntoniRomera @omar7r revisad por favor, ya que vosotros fuisteis los validadores del anterior PR. El pre-commit ahora lo soluciono actualizando la plantilla de copier. |
|
👍 LGTM |
In 2967122 the behavior of the simplified sequence was change to gather via rpc for each ticket validation. For the case of offline the planned fallback was to set the unique ID given by Odoo. This change fallbacks to the former behavior for that case allowing to obtain the proper sequence even offline. The main drawback will be that concurrent users in the same session could collide their sequence numbers if they happen to be offline. Anyway, that would be easily fixed just by separating such cashiers in separate configs. As a solution to that, a different technique should be used (longpoll for multi sessions or something like that)
chienandalu
force-pushed
the
14.0-fix-l10n_es_pos-offline
branch
from
fa3f118 to
6e0bbec
Compare
|
Esta solución no nos parece válida para casos en los que hay un solo punto de venta y varias tablet realizando pedidos. Por ejemplo en un restaurante en el que tienen un punto de venta y hay varios camareros realizando pedidos, en caso de que se fuera la conexión de internet se repetirían los números. Si además está implementado TicketBAI este es un gran problema ya que hay que enviar las facturas simplificadas en el momento que vuelva la conexión. Proponemos una solución tipo Odoo Core, en la que agrega una subsecuencia por dispositivo que accede al punto de venta. En el caso de la localización española tal vez sería interesante asignar a cada empleado (hr.employee) un código único que se utilice para formar la secuencia de las facturas simplificadas de la siguiente manera |
|
Esta solución es para cumplir con TicketBAI según nos ha reportado @anajuaristi, así que es igual de inválida la anterior por ello. @anajuaristi puedes explicar el por qué? |
|
Nuestro caso concreto es que tienen un único equipo por tienda. Por lo tanto la solución de @pedrobaeza nos es válida ya que tal y como está ahora, si pierden la conexión, la secuencia de tickets se pierde y hay efectos laterales graves. |
There was a problem hiding this comment.
Yo no puedo aceptar un cambio que me rompe una implantación en un restaurante en producción, utilizando la concurrencia de accesos a una misma caja, algo de serie en Odoo 14.0 y posteriores, y que en estos casos es muy habitual, y de forma online, no es una casuística al perder conexión. Además si fuera una restaurante vasco, necesitaría Ticketbai también, entonces si soluciona una cosa y rompe otra no vale.
|
@omar7r no es concurrencia de usuarios. El problema no son los usuarios. No es tema del ticketbai, es del pos. Estamos intentando dar con una solución genérica en la creación de números de ticket correlativos y en fecha. Actualmente el pos, si pierde la conexión es posible que pierda esta secuencia y es cuando viene el problema. Nos ha saltado a nosotros porque ticketbai verifica esta secuencia de numeración en los tickets. |
Si el empleado al entrar en otro equipo vuelve a escoger su empleado al acceder al punto de venta funcionaría bien (dando por hecho que ha cerrado el punto de venta en el primer equipo). La única manera de que esta solución no funcione es que en dos equipos se seleccione el mismo empleado, pero esto ya es un error de usuario y no un error que sucede cada vez que se pierde la conexión. |
|
Bueno, el problema es que la secuencia es distinta online/offline, y de eso se queja el TicketBAI según dice @anajuaristi Por qué es distinta esa secuencia y no puede ser la misma? |
|
@pedrobaeza ese es el tema. Sí. Que cuando es offline, se pone a numerar los tickets con una secuencia genérica. No sigue la propia del TPV |
|
Pero con esta "solución" surge otro problema, y es que se van a intentar enviar a TicketBAI facturas simplificadas con misma secuencia y numeración, y eso tampoco lo permite TicketBAI. |
|
Pero por qué se utiliza la misma sesión a la vez por dos personas? Por qué no se crean dos configuraciones? |
|
Porque en muchos restaurantes hay una sola caja y varias personas que interfieren en ella con diferentes dispositivos. |
|
En mi opinión, la modificación anterior es la que rompe la funcionalidad ya existente y no debería haber pasado para contemplar un caso de uso que quizá debería resolverse de otro modo. Aparte de que la opción de usar la secuencia nativa cuando se pasa al offline rompe la serie de la factura simplificada completamente. |
|
Bueno, mi compañero @chienandalu puede decir al respecto más que conoce el PoS en profundidad, pero diría que no sería problema. Solo veo la cuenta de efectivo como posible fricción, pero para eso podría ser el método de pago. |
|
En un restaurante sólo hay una caja por lo general y todos los camareros tienen que ver el estado de todas las mesas abiertas, ¿qué otro camino hay?, Odoo añadió el longpolling al TPV para sincronizar distintos dispositivos conectados a la misma sesión del TPV para esto |
Precisamente en el commit lo menciono:
|
|
Efectivamente, habrá que sincronizar la secuencia vía longpolling, pero no romper lo anterior que había e ir hacia otra secuencia que no tiene nada que ver. |
|
Propongo mergear este PR para al menos evitar dar a las facturas simplificadas una secuencia completamente diferente, pero a la vez abrir un issue en el que podamos discutir una solución para el tema que estamos comentando aquí. ¿Os parece? |
|
No, el PR se puede aplicar igualmente sin merge, para quien lo necesite, pero si puede romper implantaciones en una versión estable de largo recorrido no lo veo mergeable. |
|
Omar, ahora mismo estás pensando únicamente en tu caso de uso. Para la mayoría, ni una cosa ni la otra le afecta (bien por estar siempre online, o bien por no tener ese caso), pero lo cierto es que el PR anterior lo fusionamos de buena fe ya en mitad de la vida de la versión estable de v14, y aplicaría la misma cuestión que ahora tú aplicas como bloqueable. Hemos descubierto este problema bloqueante y se podría sin más hacer revert al anterior commit antes del PR, pero en cambio este PR mejora la situación del anterior PR y lo vuelve a dejar sin la problemática de cambio de secuencia, así que debería fusionarse. |
|
Ahora mismo sí, en ese y otro que son dos dependientes con una sóla caja, igual que todos pensamos en nuestros proyectos. En su momento no había esta necesidad y en un issue se planteó el problema (no lo hicimo nosotros) antes de hacer nada y se enlazó un epígrafe del BOE (no lo hicimo nosotros) y se autorizó el cambio, aunque la verdad es que estaba algo cogido con pinzas y se hizo la corrección para solucionarlo (no lo hicimo nosotros) y por útimo, se aprobó, que se pudo hacer mejor, seguramente, pero igual que este PR, por lo que no soy sólo yo, nosotros descubrimos ese issue tras toparnos con el problema. Esto no busca la estabilidad, busca una solución raṕida y sin tener a favor a todo el mundo, por lo que si se quiere parchear, se puede aplicar el PR a mano, sin ningún problema. |
|
No estoy de acuerdo: como está ahora mismo, no es estable, y el parche rápido es lo que hay puesto, ¿o acaso es correcto que salgan secuencias distintas según tengas offline/online? Si queréis que esto no se fusione, debe plantearse el código correcto con longpolling. Podemos esperar un tiempo prudencial para que se implemente sin fusionar, pero si no hace ese trabajo, hay que volver a lo que había antes o fusionar este pull request. Siempre podéis hacer freeze de vuestra rama para que no entren los nuevos cambios si queréis preservar el comportamiento actual. |
|
No es estable para Ticketbai (que es algo nuevo), si es estable para todo lo demás porque lo aceptamos bajo un epígrafe del BOE y no se ha dicho algo que lo contrarie. Yo lo aceptaría si solucionara ambos problemas, pero sino no, es un parche que le arregla el día a unos y se lo fastidia a otros, no es algo estable que se pueda mergear en mi opinión y por eso me opongo. |
Buenas, ahora he cogido el PR, en todo momento decis de un problema con TicketBAI, pero podrias indicar cual es el problema, o en la documentacion de TicketBAI la comprobacion de numeracion que estais hablando como se hace, si hay un Issue o algo, simplemente ponedlo y lo leere |
|
Hola, @AntoniRomera el problema es que en Ticketbai hay que imprimir un qr en el ticket con el número de factura simplificada y cuando se envía a la agencia foral, lleva una trazabilidad entre ese número y el anterior, para controlar que no haya huecos, por lo que no pueden ser de secuencias distintas, sino falla. Y esto tiene que hacerse tanto online como offline porque el cliente puede leer ese qr y comprobar si se ha declarado y con el offline, cambia la serie. Hemos probado el PR y aunque se resuelve al buscar siempre la última secuencia en backend si hay conexión, el problema que había que si estás en la misma sesión online con dos dispositivos se repetían los números en todos los casos. No se resuelve cuando estás offline, si están offline sigue utilizando el comportamiento anterior al commit de @AntoniRomera por lo que mientras no vuelva la conexión, todas las sesiones están poniendo los mismos números, ya que los cogen del último guardado en el navegador, por lo que acabamos con repetidos de nuevo, con lo cual, no vale para esta casuística, tampoco para TicketBAI si se usa el TPV de esta forma, que es una forma oficial y normal en hostelería y con posibilidad de uso en tiendas con una sola caja, pero dos dependientes por ejemplo. La única opción que vemos viable en todas las casuísticas, también offline, es la que proponía @ao-landoo, si se trabaja en dos dispositivos contra la misma sesión de TPV, en teoría el cajero de cada dispositivo es distinto, por lo que si cada cajero dentro de una sesión tuviera una secuencia independiente, no habría problema, ya sea online u offline, cada una continuaría numerando de forma correcta. Lo malo es que obliga a tener la gestión de cajeros activa, por lo que podría ser algo opcional usar esa funcionalidad o la actual, que como ya dije, se hizo bajo un epígrafe del BOE (#2047 (comment)) que no se ha desmentido, por lo que por ahora la considero correcta y no un error. Ya sea componiéndola como el dijo Aritz o de otra forma, habría que lograr que cada dispositivo numere de forma independiente y desconectada, y que sea parametrizable y opcional, en la configuración de la sesión del TPV, numerar de esta forma o de la forma actual. Por ejemplo, un check "Secuencia por empleado" que sólo sea visible si se marca la opción de "Empleados Autorizados" |
Me da a mí que eso fue una interpretación muy libre de la ley, porque además las secuencias de Odoo da valores únicos pero no necesariamente consecutivos: https://github.com/odoo/odoo/blob/14.0/addons/point_of_sale/static/src/js/models.js#L2932-L2947 Podemos llegar a tener la siguiente secuencia para un solo punto de venta:
Se va la red y se coge el identificador único de Odoo:
Vuelve la red y volvemos a la secuencia normal:
Por lo que sea, recarga el punto de venta:
Se va de nuevo la red:
Vuelve de nuevo:
Resultado:
|
Una solución a plantear después de tu demostración seria la siguiente: {OFFLINE-SEQUENCE}-{dispositivo}-{fecha y hora que entra en la sesion deJS}-0001 Cada vez que se salga de la sesión de JS se empieza de 0 ya que no hay manera de controlar las secuencias offline. A ver que os parece. Y para el tema del TicketBAI yo creo que se tiene que agrupar por secuencia y luego por fecha para que se haga de manera correcta. En ningún momento la ley exige una secuencia única por caja, solo que se tiene que agrupar correctamente al tener mas de una A todo esto, el comentario que indicas que es un interpretación libre de la ley, si es así, todas las interpretaciones lo son. Y segundo es una solución para un mercado que nunca tenéis en cuenta que es la restauración (no decir que no contemplar el IVA incluido en OCA si es un problema con la ley, ya que es una imposición legal en venta a cliente final), que en cualquier sitio te piden una sola caja pero varios punto de venta y ya no decir si se añade la gestión de camareros. Siguiendo tu ejemplo el resultado tendría que ser: TIENDA-22-00001 12345-123-1234 ya que aún siendo la misma caja, tenemos secuencias diferentes. Como puedes observar en la normativa: https://sede.agenciatributaria.gob.es/Sede/iva/facturacion-registro/facturacion-iva.html |
|
Coincido con @chienandalu, el cambio 2967122 debería echarse atrás como propone este PR porque fue un paso en la dirección incorrecta: la forma de conseguir que no haya conflictos en las numeraciones de las facturas no es requerir que el sistema funcione online sino generar los números de ticket siempre como si estuviéramos offline, es decir, con secuencias independientes para cada punto de venta. Como dice @anajuaristi no es un problema de ticketbai, ticketbai sólo hace que salga a la superficie (los duplicados son un problema idependientemente de ticketbai). La forma natural de conseguir esto es tener una configuración de TPV por dispositivo, cada uno con su secuencia. Si no se toman medidas específicas tener la misma sesión del TPV abierta en varios dispositivos es receta para el desastre: el contador de facturas simplificadas se define en l10n_es_pos y es el mismo para todas las sesiones del TPV. Con una configuración creativa del contador como la que @AntoniRomera parece que se podría solucionar el problema. Tiene el punto positivo de que no requiere ningún desarrollo, únicamente configurar el punto de venta de acuerdo a estos parámetros. Volveríamos a un estado en que el TPV puede funcionar 100% offline y no se rompería nada. Hace poco me encontré con una numeración de este estilo y aunque personalmente no me gusta me aseguran que es fiscalmente correcta. Sería mejor, en mi opinión, vincular la numeración al dispositivo (de manera que no tengamos tantas series como dispositvo*día del año sino tantas series como dispositivos) pero esto no creo que sea posible en la implementación actual. |
No sé muy bien de dónde sacas el dispositivo. Pero siguiendo este mismo razonamiento, ni siquiera sería necesario pasar a una secuencia distinta offline, ya que la secuencia de FS podría llegar a incorporarlo y correr independientemente en cada uno; claro, que serían necesarias varias secuencias y complicaría enormemente el sistema. En cualquier caso, opino que seguirán siendo trucos para eludir implementar la verdadera solución a un problema esencialmente técnico |
Y me puedes decir cual es la verdadera solución (teniendo en cuenta como funciona la restauración).
El tema del dispositivo, solo seria añadir una pequeña configuración al JS (Tal como se hizo en el shopfloor de WMS, creo que ahi le dicen API Key).
Y realmente en ningún momento habéis comentado, ni habéis intentando llegar a una solución que pueda incluir las dos posturas, como seria añadir un check de configuración que indique si se necesita una secuencia de FS offline, si estuviera marcado pues se usaría y en el caso de solo tener un terminal de venta como es la mayoría de vuestros casos, lo dejáis desmarcado y ya estaría. |
|
La secuencia siempre tiene que ser offline y no se pueden compartir los contadores. Es decir, siempre se deben generar los números de factura sin comunicación con el servidor garantizando unicidad. Esto es imprescindible para evitar duplicados. En nuestro caso para que se cumpla lo que hacemos es: un contador por POS y una sesión abierta por pos POS. Pero realmente da igual, abrir la misma sesión varias veces o no es irrelevante siempre que lo de arriba se cumpla. Por otro lado, si lo de arriba no se cumple, es sólo cuestión de tiempo tener problemas con tickets. |
|
Hemos estado pensando (@gelo-landoo y yo) cómo dar una solución válida en todos los casos planteados. Proponemos establecer secuencias por dispositivo. A continuación explicamos la solución encontrada: Necesidad.Cubrir el requerimiento legal de secuencias de facturas simplificadas del POS en el caso de que los dispositivos se queden sin conexión. Solución.Configuración general módulo POS. Registro y secuencia de dispositivos. Nuevo modelo llamado POS Device (pos.device) donde se establecerán los diferentes dispositivos.
Crear vista lista con opción de creación sobre ella. Contendrá los campos:
Configuración del Punto de Venta Nuevo campo Many2many relacionado a POS Device (pos.device). Si se queda en blanco se utilizan todos los dispositivos. Si no, se muestran solamente los seleccionados. Apertura de sesión Función JS para mostrar ventana de selección de dispositivo nada más cargar los datos para el inicio de la sesión. Cierre de sesión Función JS para que al cerrar la sesión con el dispositivo se desbloquee el mismo. Se agradecería la participación y el debate sobre la propuesta. Gracias. |
|
Antes de entrar en los detalles de la propuesta @ao-landoo tengo algunas dudas acerca de la propia necesidad. Para mí la necesidad realmente se reduce a asegurar de que nunca se comparten contadores entre distintos navegadores. Hoy por hoy nosotros lo hacemos así (a mano) para evitar problemas: nada de abrir el mismo pos.config dos veces. A veces se nos cuela alguien, y entonces, en efecto, hay problemas. Esto me lleva a la pregunta: ¿cuál es la necesidad de abrir el mismo pos.config múltiples veces? Un dispositivo físico <-> un pos.config y no hay problema con los contadores. Incluso se puede usar el mismo usuario para todas las sesiones. Sencillamente no veo el caso de uso. Odoo apunta en esta dirección ya que no permite abrir el mismo pos.config con distintos usuarios; sí que permite abrirlo varias veces con el mismo usuario pero en mi opinión esto sencillamente es una limitación de la implementación (identificar un usuario en Odoo es muy fácil, identificar un dispositivo en particular no tanto). Bajo la premisa anterior, es suficiente con asociar un pos.config a un dispositivo (dispositivo == navegador) dado de manera que una vez que se abra desde mi dispositivo ya no se pueda abrir desde el tuyo (hasta cerrar sesión o liberar a mano). Esto nos lleva a cómo conseguir esto. Yo haría lo siguiente. Lo primero es identificar cada dispositivo siempre. Sólo necesitamos esto dentro del contexto de POS. Para ello generaríamos en JS un etiqueta en forma de UUID para cada dispositivo y lo guardaríamos en el local storage. Al abrir la sesión de punto de venta el navegador comunicaría este UUID al servidor. Aquí podrían pasar tres cosas: En cuanto a cómo implementar esto sería como sigue: Adicionalmente se podría permitir editar el nombre del dispositivo de manera que en vez de usar UUID el usuario pueda indicar BARRA01, BARRA01, CAMARERO01, CAMARERO02 o lo que se oportuno. Creo que esto sería más sencillo de implementar, más sencillo de usar y más robusto; no hace falta gestión de dispositivos (más allá de cambiarles el nombre si fuera necesario); los dispositivos nuevos funcionan sin más; sería "transparente" en muchos casos; no se comparten nunca los contadores bajo ninguna condición. |
|
Hola, Caso de uso:Un restaurante donde hay una única caja central con un POS físico, donde se introduce el dinero en efectivo y se cuadra la caja al final de sesión. Propuesta de trabajoSe abre la sesión del POS con un usuario llamado POS 1 genérico. Con nuestra propuesta, identificando los dispositivos al iniciar sesión, cada dispositivo llevará su secuencia y no habrá ningún problema en cubrir este caso de uso y otros más simples. En cuanto a la necesidad de identificar dispositivos, ya es algo que Odoo usa con las impresoras, con lo que no creemos que vayamos en contra del flujo normal de Odoo. Gracias por la aportación y a ver si podemos lograr un punto de acuerdo. |
|
Gracias por las aportaciones!, no había visto esto hasta ahora. Desde mi punto de vista la propuesta de @ao-landoo y @gelo-landoo solucionarían un flujo de trabajo que actualmente no esta resuelto en Odoo teniendo en cuenta la legislación española. La mayoria de restaurantes y empresas que tienen PDA en tiendas, es justamente lo que se necesita, una caja y multiples PDA´s trabajando sobre la misma sesión. Seguramente por eso Odoo paso a un numero de ticket basado en UUID que garantiza numeros únicos sin llevar secuencia. Según lo que proponéis habría que cambiar el funcionamiento del POS principal también para que la lógica de la secuencia sea interna y que aunque se quede sin conexion no coja la numeración original de Odoo no?. S2 y gracias por el curro, si necesitais ayuda con algo podemos dedicar tiempo. |
|
Hola @Mat-moran , |
Me refería a aplicar los cambio propuestos por @chienandalu + @ao-landoo ya que si solo se aplica lo propuesto por @ao-landoo seguiríamos teniendo problemas con el funcionamiento actual. ¿Es esa la idea? |
Es la idea |
|
@Mat-moran @ao-landoo, que la secuencias sean offline es necesario, el commit que en este pr @chienandalu quiere revertir no debió ser aceptado en primer lugar. |
|
Hola, |
|
Hemos creado el PR #2812 con la solución propuesta por @gelo-landoo en el último mensaje |
|
Entiendo que hay otro PR, pero este FIX está corriendo en algunas instancias en PROD OJO a la migración a v16: #2615 |
El otro PR incluye el commit de este PR. El resto de cambios que se incluyen son opcionales, se activan solamente si se activa un checkbox en ajustes. |
El cambio 2967122 cambió el comportamiento de la secuencia de factura simplificada para obtener el número via
rpcen cada ticket. En caso de que el punto de venta estuvise sin conexión, se contemplaba que el valor fuese el de la secuencia única de Odoo, lo cual es algo incongruente.Este cambio retorna al comportamiento anterior para los casos en los que no haya conexión, corriendo la secuencia en el lado del cliente hasta que la conexión vuelva y los pedidos pendientes se sincronicen.
La principal desventaja es que usuarios concurrentes sobre una misma sesión podrían solapar sus secuencias. En cualquier caso, sería deseable evitar esta situación añadiendo tantas configuraciones de punto de venta como puestos en los que se vaya a operar.
cc @Tecnativa