Porque desarrollar un colector de códigos de barras propio?
Meses atras desarrollé un colector de código de barras para un cliente. En una primera instancia del proyecto, el colector había sido subestimado. Siempre se estimó que se podía utilizar el scaner provisto por Odoo Enterprise pero este no se adecuó (por diferentes motivos) a las necesidades de la empresa. También se probó utilizar un scanner desarrollado por un prominente partner europeo pero tampoco se adecuada a las necesidades del proyecto. Y por último se probó migrando un módulo de scaner de OCA, pero no fue buena la experiencia. Se necesitaba hacer un desarrollo propio porque ninguno de los colectores se adecuadaba a las necesidades de la empresa.
Otro punto a tener en cuenta son las necesidades propias de la empresa. Las aplicaciones de colectores de códigos de barra proveen una solución que es genérica. Al igual que los formularios que brinda Odoo para ingresar las transferencias o los pagos. Las pantallas para ingresos de transferencias son bastante genéricas, cuando uno necesita procesar decenas de operaciones diarias tarde o temprano ocurren errores (de movida no se hacen las validaciones necesarias). Y no son ágiles para el usuario final. Es por ello que las mismas deben ser automatizadas y la mejor manera de automatizar dichas operaciones es mediante el uso de códigos de barras.
Ahora; muchas empresas necesitan personalizar sus procesos de transferencias a sus necesidades (por ejemplo validar que en los ingresos los nros de serie pertenezcan a un packing list). Y con ello la operación de sus colectores. No solo la distribuidora para la que hice el desarrollo, sino tambien una metalurgica, dos fabricantes de electrónica y un fabricante de ropas (a los que conozco).
La importancia de saber Javascript y OWL
Para desarrollar el colector si o si se necesitó trabajar con Javascript. Un colector es un desarrollo front-end (es impensable hacerlo como módulo de back-end debido a la mala experiencia que van a tener los usuarios). Para ello uno necesita tener experiencia con Javascript. No ser un experto (no me considero uno) pero si tener una buena experiencia trabajando con Javascript.
Y para resolver los problemas de reactividad (fundamental para la experiencia del usuario) la tecnología utilizada para el desarrollo de scanner fue OWL para el front-end. Cuando uno trabaja pickeando códigos de barra se necesita una interface agil que se refresque instantaneamente y que sea reactiva. No es recomendable estar constantemente refrescando la pantalla para actualizar los datos. La reactividad de OWL promete eso, y lo cumple.
Aprender a desarrollar con OWL lleva un tiempo pero es algo que se puede hacer. Pero viniendo de Python como es mi caso, trabajar con Javascript es como caminar en un campo minado. Es muy trabajoso. Debe tenerlo en cuenta para el desarrollo.
Hablemos del back-end
Yo diría que en horas de desarrollo, el 35% o 40% del tiempo se pasó trabajando con el front-end trabajando con Javascript y OWL (de vuelta, es fundamental saber bien Javascript). Ahora el resto del tiempo uno lo pasa desarrollando con el ORM de Odoo las operaciones para que las transferencias se realicen de manera correcta.
Por varios motivos; el más importante es evitar el stock negativo. Es fundamental trabajar con un desarrollador experimentado para que se realicen correctamente los movimientos en los modelos stock.move.line, y que se actualicen los paquetes y números de serie de forma correcta. Si eso se realiza bien, se van a evitar los errores de stock negativo. Sino, tarde o temprano se van a llevar sorpresas desagradables.
Hablemos del hardware
El cliente decidió usar una configuración de hardware para el colector muy barata y funcional. El cliente les dió a sus empleados del almacen tabletas Android (las Amazon Fire para ser más exactos) conectadas a una pistola lectora de código de barras mediante Bluetooth. Esa combinación es barata y hasta ahora funciona sin problemas. Si se rompe... reponerla es un problema sencillo y económico. Con esas tabletas más algunos adicionales para caminar con la tableta por todo el depósito, bastó.
Tiempos de desarrollo
Fueron tres meses. El desarrollo comenzó a mediados de diciembre y se puso en producción el primero de marzo. Fue un desarrollo part-time. Y el resultado fue bueno, no hubieron grandes problemas cuando se puso en producción. Esos problemas se resolvieron de forma rápida. Y la operación del cliente tiene un promedio de 20 o 30 números de serie por entrega (las entregas son en dos pasos), tienen más de 1000 SKUs y se realizan entre 50 y 100 operaciones diarias. Tambien manejan paquetes.