diseño de software de talleres con odoo · diseño de software de talleres con odoo, trabajo fin...

Óscar Soto Ochoa

Francisco José García Izquierdo

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2017-2018

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Diseño de software de talleres con Odoo

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2018

publicaciones.unirioja.esE-mail: [email protected]

Diseño de software de talleres con Odoo, trabajo fin de grado de Óscar Soto Ochoa,dirigido por Francisco José García Izquierdo (publicado por la Universidad de La Rioja), se

difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.

Facultad de Ciencia y Tecnología

TRABAJO FIN DE GRADO

Grado en Ingeniería Informática

Diseño de Software de Gestión de Talleres con

Odoo

Realizado por:

Óscar Soto Ochoa

Tutorizado por:

Francisco José García Izquierdo

Logroño, Julio 2018

PÁG. 2

PÁG. 3

Agradecimientos.

Quisiera agradecer, en primer lugar, a mi tutor del Trabajo de Fin de Grado, Don Francisco José García Izquierdo, quien me ha guiado y confiado en mí durante toda esta andadura, ayudándome ante cualquier duda que tuviera. En segundo lugar,

A la empresa SDi Soluciones Informáticas SL, por proponerme y confiarme la realización de este trabajo, proporcionándome, a su vez, los recursos necesarios para su realización, así como a la formación recibida en la plataforma Odoo. A mi tutor de Prácticas, Don José Víctor Gómez Pérez (CTO de SDi), al director del Departamento SDiCloud, Don Javier García Panach, y al Sr. Darío Lodeiros Vázquez, consultor Odoo.

A mis compañeros de trabajo, por hacer mi experiencia agradable y hacerme sentir como uno más.

A mis compañeros de carrera, con los que tantos momentos he compartido, y que han convertido esta etapa de mi vida en un bonito recuerdo.

Y, por último, y no por ello menos importante, a mis familiares y amigos, cuyo apoyo y paciencia han hecho posible que hoy esté escribiendo estos agradecimientos.

__

PÁG. 4

Índice

Summary ................................................................................................................................................. 6

1. Introducción .................................................................................................................................... 7

1.1 Contexto .................................................................................................................................. 7

1.2 Metodología ............................................................................................................................ 7

1.3 Sprint 0. Planificación .............................................................................................................. 8

1.3.1 Subproyectos .................................................................................................................. 8

1.4 Historias de usuario ................................................................................................................ 9

1.4.1 Organización temporal .................................................................................................. 10

1.4.2 Plan de pruebas............................................................................................................. 10

2. Subproyecto: Gestor de Talleres (SDi Car-Workshop) .................................................................. 11

2.1 Análisis .................................................................................................................................. 11

2.1.1 Requisitos Funcionales .................................................................................................. 11

2.1.2 Requisitos no funcionales ............................................................................................. 12

2.2 Diseño ................................................................................................................................... 13

2.2.1 Diseño de la base de datos ........................................................................................... 13

2.2.2 Odoo y su framework .................................................................................................... 13

2.2.3 Diseño de los modelos .................................................................................................. 14

2.2.4 Diseño de la interfaz gráfica .......................................................................................... 19

2.3 Implementación .................................................................................................................... 24

2.3.1 Diseño y creación de una OR (Historia de Usuario 1.1). ............................................... 24

2.3.2 Registro de Horas (Historia de Usuario 1.3). ................................................................. 26

2.3.3 Pizarra Kanban OR (Historia de Usuario 1.4). ............................................................... 27

2.3.4 Relación Cliente y vehículo (Historia de Usuario 1.6). .................................................. 30

2.3.5 Calendario OR (Historia de Usuario 1.7). ...................................................................... 31

2.3.6 Facturación (Historia de Usuario 1.8). .......................................................................... 32

PÁG. 5

2.3.7 Ejemplo de código no reutilizable: Implementación del Asistente para facturar un Presupuesto. ................................................................................................................................. 33

2.3.8 Informes (Historia de Usuario 1.9 y 1.10). .................................................................... 34

2.3.9 Internalización (Historia de Usuario 1.11). ................................................................... 36

2.4 Pruebas ................................................................................................................................. 38

3. Subproyecto: Catálogo de Neumáticos (SDi Tire Catalogue) ........................................................ 39

3.1 Análisis .................................................................................................................................. 39

3.1.1 Requisitos funcionales .................................................................................................. 39

3.1.2 Requisitos no funcionales ............................................................................................. 40

3.2 Diseño ................................................................................................................................... 40

3.2.1 Diseño de la base de datos ........................................................................................... 40

3.2.2 Diseño de los modelos .................................................................................................. 40

3.2.3 Diseño de la interfaz gráfica .......................................................................................... 41

3.3 Implementación .................................................................................................................... 41

3.3.1 Extender la clase Producto para añadir los atributos de un Neumático (Historia de Usuario 2.1). .................................................................................................................................. 41

3.3.2 Implementar un asistente para la búsqueda de Neumáticos (Historia de Usuario 2.3). ……………………………………………………………………………………………………………………………….. 43

3.3.3 Visualizar Neumáticos Kanban (Historia de Usuario 2.2). ............................................ 44

3.4 Pruebas ................................................................................................................................. 45

4. Seguimiento y Control .................................................................................................................. 46

4.1 Alcance y objetivos alcanzados. ............................................................................................ 46

4.2 Tiempo de ejecución real y desviaciones .............................................................................. 46

5. Conclusiones ................................................................................................................................. 48

5.1 Personal ................................................................................................................................ 48

5.2 Técnico .................................................................................................................................. 49

5.3 Lecciones Aprendidas (LLAA) ................................................................................................ 50

5.4 Mejoras a Futuro. .................................................................................................................. 50

6. Bibliografía .................................................................................................................................... 51

7. Anexos ........................................................................................................................................... 52

7.1 Anexo Historias de Usuario ................................................................................................... 52

7.2 Anexo Actas de Reuniones. ................................................................................................... 56

7.3 Anexo Tabla de tiempos para el Despliegue. ........................................................................ 60

7.3.1 Despliegue SDi Talleres ................................................................................................. 60

PÁG. 6

Resumen

La realización de este proyecto ha sido propuesta por la empresa SDi Soluciones Informáticas S.L. con el objetivo de desarrollar una aplicación vertical (software definido para un único mercado) de gestión de talleres mecánicos, para la plataforma Odoo. Por lo tanto, en este proyecto, se llevará a cabo un módulo capaz de organizar, de manera fácil e intuitiva, la entrada de vehículos en el taller, la gestión de clientes, proveedores y vehículos.

La idea es obtener, de manera visual, el número de vehículos en taller, los que están por venir, y un registro de las reparaciones que se le han realizado a dicho vehículo.

Para realizar este trabajo se usarán tanto varios conocimientos adquiridos durante la realización del Grado en Ingeniería Informática como algunas de las técnicas aprendidas durante la estancia en prácticas de empresa (cómo desarrollar un módulo para Odoo). El trabajo se ha realizado usando Python como lenguaje principal.

Summary

The realization of this project has been proposed by SDi Soluciones Informáticas Ltd. with the objective of developing a vertical application (software defined for a single market) for the management of mechanical workshops, for the Odoo platform.

Therefore, in this project, I will carry out a module which is capable of easily and intuitively organizing the entry of vehicles in the workshop, the management of customers, suppliers and vehicles.

The idea is to visually obtain the number of vehicles in the workshop, those that are to come, and a record of the repairs made to such vehicles.

To carry out this task, I will use both the knowledge acquired during the Degree in Computer Engineering and some of the techniques learned during the internship (how to develop a module for Odoo) The task has been done mainly using Python language.

PÁG. 7

1. Introducción

1.1 Contexto La principal motivación del presente trabajo es la necesidad de actualizar la familia de productos de Gestión basados en software de escritorio realizados en FoxPro, de la empresa SDi Soluciones, por un software más actual basado en Cloud. Para ello, la tecnología elegida es Odoo.

El cliente, SDi Soluciones Informáticas, es una empresa ubicada en La Rioja que lleva treinta años ofreciendo servicios informáticos a las empresas. Entre ellos, sus principales productos se basan en software de tipo ERP1 adaptado a cada sector empresarial concreto (agricultura, calzado, etc.), y servicios de soporte y mantenimiento para sus clientes para dicho software.

La plataforma web Odoo (también conocido como OpenERP) es un ERP, que se desarrolló en 2005, como una alternativa de código abierto a otros ERP privativos. Odoo es modular, lo que significa que hay una aplicación principal y se pueden desarrollar módulos para extender su funcionalidad. La mayoría de sus módulos tienen licencia AGPL y es posible su modificación de forma íntegra manteniendo dicha licencia.

A partir de 20112, en su versión 6, ya es, en su totalidad, cliente web. Su lenguaje principal es Python, pero también se apoya en JavaScript para aspectos estéticos, y en PostgreSQL como su SGBD.

El objetivo de este proyecto es crear un vertical (en uno o varios módulos de Odoo), para la gestión íntegra de un taller mecánico. Para ello, el vertical ofrecerá al usuario, llevar un seguimiento de los vehículos que entran al taller, su diagnosis y reparación, además de poder estimar tiempos, y guardar información sobre los propios vehículos, los clientes y los proveedores.

1.2 Metodología He decidido realizar el proyecto utilizando metodología ágil "SCRUM” por los siguientes motivos:

El primero y principal, es porque está siendo implantada en el departamento al que he sido asignado.

Además, es un proyecto con algunos rasgos bien definidos, pero cuenta con aspectos (diseño, nuevas funcionalidades) que tienen un carácter más variable.

1 ERP: Enterprise Resource Planning. Gestor de Recursos Empresariales. https://es.wikipedia.org/wiki/Sistema_de_planificación_de_recursos_empresariales 2Odoo, Wikipedia: https://es.wikipedia.org/wiki/Odoo

PÁG. 8

Quiero mantener una comunicación constante con el cliente, al integrarlo en el equipo de trabajo para obtener un producto mejor adaptado a las necesidades de éste.

Quiero aprender y profundizar en el uso de metodologías ágiles.

Dicha metodología ha sido adaptada para la empresa SDi, a la que me referiré, a partir de ahora, como SCRUM/SDi. El flujo de trabajo es el mismo que para SCRUM, con algunas diferencias:

Product Manager es el CTO de la Empresa, Don José Víctor Gómez Pérez. Product Owner. Es el jefe más directo a ti, define el Product Backlog. En mi caso, el directivo

del Departamento de SDiCloud, Don Javier García Panach. Scrum Master. Es el consultor que nos está enseñando a manejar dicha metodología y, en el

futuro, lo será el jefe de Departamento de SDiCloud (que también puede ser el Product Owner).

Team Developer. Está pensado que en cada proyecto trabajen un máximo de dos personas siendo una de éstas el responsable de su continuidad. En mi caso, sólo estoy yo.

No se realizarán daily scrum meetings, pero sí se hará un “Sprint planning meeting”, todos los viernes, de forma regular, sustituyendo, de esta forma, las daily meetings diarias por una única de forma semanal. Dicha reunión no es un sprint planning meeting de forma ortodoxa, pero sí sirve para ver cómo van los progresos y definir el Sprint Backlog en caso de que no estuviera definido (el sprint son 3 semanas).

Los sprints durarán tres semanas. Se realizará un sprint review al final del sprint (cada tres semanas), con el Product Owner. Se realiza una sprint retrospective, una vez al mes, con el Product Owner y el Product Manager

(o, en su defecto, con todas las partes implicadas). Para este proyecto no se van a definir pruebas automatizadas con integración continua. En un

futuro se realizarán con Travis CI.

1.3 Sprint 0. Planificación Como es habitual en las tecnologías ágiles, el primer sprint, o sprint 0, sirve para recoger la definición y planificación del proyecto.

1.3.1 Subproyectos Para desarrollar la Pila de Producto (Product BackLog), tal como se indica en la guía oficial de SCRUM3, usaremos historias de usuario. Para desarrollar dichas historias de usuario, las separaremos en dos subproyectos, claramente definidos, que estarán en módulos distintos.

ID SP1 Nombre SDi Car Workshop Descripción Es el módulo principal. Tiene como objetivo ofrecer la gestión mínima, pero integral,

de un taller mecánico. Contiene los menús, las áreas de trabajo, las órdenes de reparación a realizar, el registro de los vehículos, etc.

ID SP2 Nombre SDi Tire Catalogue Descripción Es el módulo que implementará la funcionalidad relacionada con el catálogo de

neumáticos. Contiene los menús del catálogo y el buscador para filtrar.

3Guía oficial de SCRUM: https://www.scrum.org/resources/scrum-guide

PÁG. 9

Para las historias de usuario de los próximos sprints, utilizaré la técnica MoSCoW4 para elegir la importancia.

1.4 Historias de usuario Identifico inicialmente las siguientes historias de usuario:

ID Nombre Coste (h) Valor Dependencias H1.1 Diseño y creación de una OR 24 M H1.5 H1.2 Alertas pre-Itv 20 M - H1.3 Registro de Horas 17 S H1.1 H1.4 Pizarra Kanban OR 17 M H1.1 H1.5 Registrar clientes, vehículos, proveedores 7 C H1.5 H1.6 Ver relación cliente y vehículos 17 S H1.5 H1.7 Calendario tareas 17 S H1.1 H1.8 Facturación 23 M H1.1, H1.5 H1.9 Informes 23 M H.11, H1.5, H1.8 H1.10 Informes Detalle 23 M H.11, H1.5, H1.8, H1.9 H1.11 Internalización 23 S Todas H2.1 Definir artículo neumático 23 M - H2.2 Kanban neumáticos 23 M H2.1 H2.3 Filtrar neumáticos 23 M H2.1, H2.2

Tabla 1. Resumen Historias de Usuario.

Adjunto en el Anexo 6.1 las historias de usuario en formato post-it con la información ampliada.

La pila de producto inicial tiene la siguiente forma:

Sprint ID Nombre Valor Dependencias Coste (h) Planificación -- -- -- 20 1 H1.1 Diseño y creación de una OR M H1.5 24 78

H1.5 Registrar clientes, vehículos, proveedores

M - 20

H1.3 Registro de Horas S H1.1 17 H1.4 Pizarra Kanban OR M H1.1 17

2 H1.2 Alertas pre-iTV C H1.5 7 64 H1.6 Ver relación cliente y vehículos S H1.5 17 H1.7 Calendario tareas S H1.1 17 H1.8 Facturación M H1.1, H1.5 23

3 H2.1 Definir artículo neumático M - 23 69 H2.2 Kanban neumáticos M H2.1 23 H2.3 Filtrar neumáticos M H2.1, H2.2 23

4 H1.9 Informes M H.11, H1.5, H1.8

23 69

H1.10 Informes Detalle M H.11, H1.5, H1.8, H1.9

23

H1.11 Internalización S Todas 23 Total 300

Tabla 2. Pila de Producto

4MoSCoW: Must have, Should have, Could have, Won’t have. Explicado más adelante.

PÁG. 10

Con la anterior tabla tenemos la pila inicial del proyecto, el número de sprints, las historias de usuario, importancia, dependencias y coste.

Aplicando la técnica MoSCoW, agrupamos las historias de usuario por importancia:

M (Must): H1.1, H1.5, H1.4, H1.8, H2.1, H2.2, H2.3, H1.9, H1.10, H1.11 S (Should): H1.3, H1.6, H1.7, H1.11 C (Could): H1.2 W (Won’t):

1.4.1 Organización temporal Los Sprints serán inicialmente de 3 semanas de duración, pero pueden cambiar según se desarrolle el proyecto. Si hay cambios, se reflejarán al final de cada sprint, y se reordenará la pila de producto.

Habrá un total previsto de 4 Sprints, de 3 semanas cada uno, un total de 12 semanas, repartidas durante los meses de: enero, febrero, marzo y abril.

1.4.2 Plan de pruebas Realizaré pruebas al final de cada sprint. Las pruebas que realizaré son:

Pruebas unitarias. Pruebas de integración.

PÁG. 11

2. Subproyecto: Gestor de Talleres (SDi Car-Workshop)

2.1 Análisis 2.1.1 Requisitos Funcionales Se desarrollará un módulo back-end para la plataforma Odoo, que permita la gestión y planificación, ("un vertical") de entrada, de clientes en un taller mecánico de reparación de vehículos. De esta forma, se podrá llevar un seguimiento de los servicios realizados al coche (del cliente). Y ofrecer una forma fácil de planificar el número de servicios que se pueden realizar a la vez.

Ofreciendo vistas Kanban con los servicios a realizar, organizadas por áreas, el taller tendrá, de forma visual, la información necesaria para optimizar el número de servicios teniendo en cuenta: la estimación en horas del servicio, el espacio del taller y el número de operarios.

Por lo tanto, el objetivo del módulo es mostrar una pizarra Kanban, en función del área elegida, de las reparaciones (servicios) que se están realizando en el taller (cada etiqueta Kanban representará una reparación), las que están en espera, y las que ya están finalizadas; así como una colección de herramientas para: el seguimiento de una reparación (servicio), registrar usuarios, modelos de coche, productos y una forma de facturar dichos servicios.

Las áreas. Por defecto, se diseñará una única área general llamada "reparaciones y revisiones", en esta área estarán los servicios relacionados con la manipulación del coche por motivos funcionales. Pero un taller concreto puede definir otras áreas como, por ejemplo, "chapa y pintura" para organizar los servicios relacionados con aspectos estéticos a aplicar a un vehículo.

La vista Kanban mostrará un conjunto de etiquetas Kanban; éstas a su vez tendrán la siguiente información: una foto del vehículo, un título orientativo, el cliente, el identificador del coche, la fecha de entrega y una nube de tags que servirán para indicar la índole del servicio (iTV, pinchazo ruedas, cambio de aceite...).

La etiqueta Kanban, a su vez, se podrá mostrar de forma ampliada añadiendo nueva información. Se pretende mostrar, en una nueva página, la información concreta del servicio. Esta información será la siguiente: foto del vehículo, título orientativo, identificador del cliente, identificador del coche, identificador del operario principal al que está asignado, fecha de entrega del coche, fecha de recogida del coche (fecha límite), nube de tags orientativos, un texto descriptivo de la reparación, así como una lista donde registrar los materiales empleados y otra lista donde registrar los cambios que se le han hecho al vehículo, cuánto se ha tardado, y qué operario lo ha realizado.

PÁG. 12

Como es propio de las etiquetas Kanban, tendrá un estado que indique el proceso de la reparación (o servicio); dicho estado podrá tener los siguientes valores: "en espera", "en proceso", “recogida cliente" (el coche está en taller a la espera de ser recogido por el cliente).

Se ha optado por eliminar el estado “finalizado” para simplificar los estados y hacer más simple el diseño de la pizarra Kanban en el flujo de trabajo.

Flujo de Trabajo El flujo de trabajo propuesto para la utilización de dicho módulo vertical es la siguiente: Con la entrada de un nuevo cliente al taller, nos dirigimos al Área específica en función de los servicios que nos pide el cliente, por lo general, "reparaciones y revisiones":

Vista Kanban del área, crear nueva tarea, registramos al cliente, registramos el vehículo, registramos el modelo del vehículo en caso de no tenerlo, añadimos un título apropiado y registramos la diagnosis inicial realizada por el cliente.

Figura 1. Flujo de trabajo

Por defecto, esta nueva tarea tendrá el estado "en espera". Más adelante, en función del momento, dicha tarea se le asignará a un operario que registrará el material empleado y la mano de obra, y cambiará el estado de la tarea de "en espera" a "en proceso". Una vez terminado el servicio, el operario cambiará el estado de "en proceso" a "recogida cliente" para indicar que ya está terminada la tarea y el vehículo puede ser recogido.

Aclaraciones: El cliente, SDi Soluciones, ya tiene una idea preconcebida de cómo debe ser el diseño, a grandes rasgos, de las vistas que interactúan en el flujo principal de trabajo. Por eso mismo las incluyo en el apartado de Análisis con la Figura 1.

2.1.2 Requisitos no funcionales El módulo deberá ser compatible para la versión 11.0 de Odoo. Deberá funcionar y visualizarse correctamente en las versiones más recientes de los navegadores modernos, sólo en ordenador, independientemente del sistema operativo.

Para proteger la seguridad de los datos de los usuarios, se usarán los distintos métodos de seguridad que implementa Odoo, garantizando que los datos personales sólo sean visibles por las personas autorizadas.

Al tratarse de un módulo de Odoo, debe cumplir con las siguientes guidelines:

El módulo debe estar completamente en inglés, excepto las traducciones.

Los archivos .py deben cumplir con las guidelines PEP 8. El módulo debe cumplir con la organización de archivos propia de Odoo. Además, el módulo debe poder ofrecerse completamente en idioma español.

PÁG. 13

Por último, la plataforma Odoo 11.0 precisa de:

Versión de Python 3.5 Servidor PostgreSQL versión 12.394

Además de todo lo anterior, se desea que la plataforma web tenga un comportamiento Responsive5, ya que es posible que se use tanto desde ordenadores convencionales como desde tablets.

2.2 Diseño Diseñaremos un módulo back-end para la plataforma Odoo 11.0.

2.2.1 Diseño de la base de datos Hay que aclarar que no es aconsejable manejar la BD sin utilizar la plataforma Odoo. Esta plataforma mapea los modelos diseñados en Python en función de cómo lo hayamos especificado, para todo ello, Odoo proporciona un ORM.

Por tanto, Odoo crea una tabla por modelo y una columna por campo (con algunas excepciones). Explico dicho mapeado en el punto 2.2.3 Diseño de los modelos.

2.2.2 Odoo y su framework Para entender el proyecto, es necesario conocer primero cómo funciona el framework de Odoo.

El ORM de Odoo ORM (Object Relational Mapping) es una técnica de programación que tiene como objetivo convertir datos entre el lenguaje de programación orientado a objetos y el sistema de base de datos relacional usado, en nuestro caso, Python y PostgreSQL.

Odoo proporciona su ORM, que podemos usar mediante la API asociada. Esta API nos permite realizar operaciones sobre la BD, así como la forma de diseñar las tablas y columnas. También nos da el dialecto propio de Odoo con el que poder crear objetos, modificarlos en BD, realizar herencias, etc.

MVC en Odoo Odoo usa una arquitectura MVC (Modelo Vista Controlador).

La capa modelo es definida por Python, cuyos datos son guardados en una BD de PostgreSQL. El mapeo es gestionado automáticamente con el framework, el mecanismo que lo hace posible es el ORM.

Aunque no hay ningún documento oficial que lo diga, Odoo está Orientado a Prototipos, no está Orientado a Objetos, como podríamos esperar desde un principio. Este punto ya lo veremos más adelante, a la hora de diseñar los modelos.

La capa vista describe la interfaz de usuario. Dichas vistas son definidas por archivos XML. Odoo cuenta con el motor de plantillas QWeb. Estas vistas son usadas por el framework del cliente web para generar las vistas HTML.

La capa controladora. En este punto hay que concretar que el concepto de controlador difiere de los tipos de controladores que podemos encontrar en Odoo. Hay que diferenciar dos tipos de controlador:

Actions. Los actions se pueden definir tanto en XML como mediante funciones Python que devuelvan un diccionario. Este tipo de controlador es lo más parecido que tenemos en otras arquitecturas MVC. Dentro de los actions hay varios tipos; el más común es el tipo

5 Un diseño Responsive, es aquel que está preparado para adaptarse a las características físicas del dispositivo con el que se usa.

PÁG. 14

action.window, que nos permite indicar a qué vista ir, de qué modelo y aplicar un determinado contexto.

“Controladores de modelo”. Estos últimos se definen dentro del modelo en Python como una función de Python más, pero usando decoradores (herramientas) del ORM. El más común es el decorador @api.onchange(‘campo’), el cual hará que se ejecute la función que hemos definido debajo, cuando el campo de una vista cambie de valor. Estas funciones que declaramos en Python con los decoradores @api.decorador son traducidos por el ORM de Odoo como funciones JavaScript que se agregarán a la vista del modelo. De esta forma, podemos definir funciones lógicas que actuarán en la página que estemos viendo.

2.2.3 Diseño de los modelos Tipos de atributos en el ORM de Odoo Como ya hemos mencionado para el diseño de clases, es necesario utilizar el ORM que Odoo nos proporciona para poder definir la persistencia en la BD. Los tipos de campos proporcionados por el ORM de Odoo son los siguientes:

Tipos básicos: Char, Boolean, Integer, Float, Text, Selection, Html, Date y DateTime Campos Relacionados:

o Relational: Campo que obtiene su valor de otra tabla. o Many2one: En OO sería un campo de tipo objeto de una clase concreta. En BD se refleja

como un campo de clave foránea. o One2many: Para poder definirlo es necesario que en la otra tabla haya un campo

Many2one. En OO es un Array de objetos. o Many2many En OO es un Array de objetos. En BD nos crea una 3º tabla como en las

relaciones N:M

Los modelos Una de las buenas prácticas, a la hora de realizar un módulo en Odoo, es crear un archivo por clase (modelo) y los archivos de las clases que heredamos deben empezar por inherit_modulo_modelo.py. Además, es necesario que esté todo en inglés, nombres de clases, variables, comentarios….

En la lógica de negocio de nuestro módulo, hemos tenido que diseñar los siguientes modelos:

Nombre de la clase (Python) Archivo Módulo Repair repair.py Nuestro módulo (CarWorkshop) MaterialLine material_line.py Nuestro módulo (CarWorkshop) ResPartner inherit_res_partner.py Res Project inhetir_project_project.py Project Task -- Project Vehicle inherit_fleet_vehicle.py Fleet SaleOrder -- Sale SaleOrderLine Inherit_sale_order_line.py Sale

Tabla 3. Modelos, sus nombres y archivo

Los modelos Cliente/Proveedor (ResPartner), Proyecto (Project), Vehículo (Vehicle) y Línea de pedido (SaleOrderLine) ya están definidos dentro de distintos módulos de Odoo, pero es necesario ampliar sus atributos.

PÁG. 15

Los modelos Tarea (Task) y Pedido (SaleOrder) los utilizaremos tal como vienen en el núcleo6 de Odoo.

Para poder entender un poco mejor cómo se debe hacer esto en Odoo, me dispongo a explicar la Herencia y la sobreescritura de campos y funciones.

Herencia en Odoo Como podemos ver desde la Documentación Oficial de Odoo7, tenemos tres tipos de Herencia. Odoo las llama de la siguiente forma:

Figura 2. Herencia en Odoo

1. Herencia Clásica: Con este tipo de herencia extendemos la clase padre de la que heredamos. La clase hija, se llama igual que la clase padre (de ahí el extender al padre), tendremos los campos del padre, su funcionalidad, vistas y la persistencia se produce en la misma tabla; además, podemos añadir o redefinir campos y funciones. En resumen, con ella estamos cambiando la clase padre. Este tipo de herencias son necesarias para poder modificar los módulos de la OCA8 sin modificar sus archivos directamente. Está permitida la herencia múltiple.

2. Herencia de Prototipado: Es el tipo de herencia que podemos encontrar al usar lenguajes OO como Java. Heredamos del padre sin modificarlo, indicamos un nuevo nombre de clase. Esta clase heredará del padre los campos y la funcionalidad, pero se almacenará en una tabla distinta respecto al padre y no se heredan las vistas. Está permitida la herencia múltiple

3. Herencia por Delegación: Es la herencia más difícil de explicar y puede no llegar a verse como una herencia en sí. La herencia se delega en un campo de tipo Many2one que va a tener la clase

6 Núcleo (o Core): Es la funcionalidad que nos aporta el Framework, que estamos utilizando, de base sin añadir ninguna librería extra. 7Herencia Odoo https://www.odoo.com/documentation/11.0/reference/orm.html#inheritance-and-extension 8 OCA. Odoo Community Association. Más información en https://odoo-community.org

PÁG. 16

hija, hereda los campos de la clase padre, en el momento de ejecución, pero se almacenan en la tabla de la clase padre, y sólo podemos obtener la funcionalidad del padre mediante el campo de tipo objeto. Además, no heredamos las vistas del padre y está permitido la herencia múltiple.

Aparte del tipo de herencia que Odoo nos proporciona con su ORM, tenemos la herencia por Python. Para implementar una clase reconocible por Odoo, ésta debe heredar de una de las dos clases padre posible:

model.Model Con ella heredamos una serie de atributos que se utilizan como metadatos y la mayor diferencia con la siguiente clase es que ésta tiene persistencia con la BD.

model.TransientModel Con esta clase no se creará una tabla ni tendrá persistencia en BD. Se utiliza principalmente para la implementación de Wizards, interfaz de tipo asistente.

Con la intención de aclarar aún más este punto, voy a poner un ejemplo de cómo se implementaría la extensión de una clase ya existente en el núcleo de Odoo utilizando la herencia clásica (que es la que voy a utilizar a excepción, como luego indicaré, de la herencia por delegación de SaleOrder y Repair).

Para el ejemplo, utilizo la clase StockMove, a la cual sólo hay que agregar un campo de tipo Many2one para indicar la relación con las líneas de material que tiene la Orden de Reparación.

from odoo import api, fields, models, _ class StockMove(models.Model): _inherit = 'stock.move' car_work_repair_id = fields.Many2one('car_workshop.repair')

Ahora el modelo StockMove (el que ya existía en el núcleo de Odoo) tiene un nuevo campo de tipo booleano Many2one con nombre car_work_repair_id. Este nuevo campo hará que en la BD se modifique la tabla 'stock.move' agregando una nueva columna “car_work_repair_id” de tipo char, y que sea clave foránea de la tabla “car_workshop.repair” implementado en PosgreSQL.

Como vemos en el ejemplo, los modelos de Odoo tienen dos nombres de clase:

1. El nombre de la clase Python, en el ejemplo, es StockMove 2. El nombre de la clase Odoo, que es stock.move, el cual siempre está formado por

'modulo.nombre'.

El nombre de la clase Python es casi irrelevante; se le nombra cuando queremos llamar a métodos de la clase padre Model y para nada más. Ejemplo: super(StockMove, self).create(vals)

El nombre que realmente interesa es el de la clase Odoo, stock.move; es el nombre que le pondrá a la nueva tabla que se generará en la BD y con la que se mapearán los objetos de dicha clase.

Además, con este nombre, podemos declarar un campo de tipo stock.move:

fields.Many2one('stock.move') o construirlo: self.env["stock.move"].create(vals)

Diagramas UML para el diseño del módulo SDi Car Workshop Para reflejar el diseño de las clases, voy a utilizar diagramas UML.

Para explicar el siguiente diagrama, vamos a repasar primero los módulos que utilizaremos directamente del núcleo de Odoo:

PÁG. 17

Fleet (Flota). Este módulo ha sido diseñado, por Odoo SA., para proporcionar una estructura a las empresas que, para su trabajo, tienen una flota de vehículos, así mismo, tiene campos relacionados con el valor monetario del vehículo y la posible venta de éste. En nuestro caso, lo queremos para reutilizar las clases que nos da: vehículo, modelo y marca; así como una amplia colección de modelos y marcas (datos) de coches ya predefinidos.

Sale (Venta). Este módulo proporciona, al conjunto del ERP, una serie de clases y funcionalidades relacionadas con la gestión de presupuestos. También quiero decir que, a un presupuesto aceptado por el cliente, se le llama “pedido de venta”.

Account Invoicing (Gestión de facturas). Cuando un presupuesto está aceptado, es un pedido de venta; se crea una factura asociada a este pedido. El módulo Account Invoicing proporciona las clases y lógica necesarias para realizar este punto y realizar el cobro de dicha factura.

Project (Proyectos). Este módulo proporciona, entre otras cosas, las clases de Project y Task, las cuales las vamos a usar para reutilizar su funcionalidad, ya que una orden de reparación se comportará, a aspectos prácticos, como una tarea de un proyecto concreto. Stock (Inventario). Este módulo proporciona la lógica necesaria para la gestión del stock de los productos. En nuestro caso, lo necesitamos para la clase StockMove, con el cual realizaremos el consumo de materiales, así como el consumo de los productos facturados. Los productos pueden ser de tres tipos:

o Consumible. El producto tiene un stock, pero no se va a llevar un seguimiento de éste o una traza. Ej. tornillos, tuercas, productos a granel.

o Servicio. El producto es un servicio que realiza un empleado. Ej: dos horas de mano de obra por reparar un grifo.

o Almacenable. Se le hace un seguimiento y una traza a dicho producto.

Como podemos ver en el diagrama siguiente, tenemos clases en las que no he puesto ningún campo o método: ResPartner, Task, SaleOrder y Model. Estas clases sí tienen campos y métodos, pero las utilizo sin aportar ninguna nueva funcionalidad ni campo a las mismas. Las utilizo tal y como vienen en el núcleo de Odoo. Por lo que he decidido, por simplicidad, no incluir sus características en el diagrama.

También quiero indicar que las clases Project, Vehicle, SaleOrderLine y StockMove tienen métodos y más campos, pero como ya he indicado, en el diagrama, sólo incluyo los campos o funcionalidad que voy a agregar a las clases ya existentes en el núcleo de Odoo. Con esto quiero aclarar que las únicas clases que son nuevas, y, por consiguiente, no están en el núcleo son: Repair y MaterialLine.

PÁG. 18

Diagrama 1. Diagrama de clases UML

Me gustaría aclarar que, a pesar de la cantidad de lógica de negocio que podemos tomar de los módulos del núcleo de Odoo, la dificultad de este TFG radica precisamente en adaptar dichos módulos a nuestras necesidades e implementar la funcionalidad que necesitemos (sin que ésta rompa el resto de los módulos).

Los modelos de Car Workshop Repair Es la clase principal; representa una Orden de Reparación (OR) y une las funcionalidades de un presupuesto (SaleOrder) y de una tarea (Task).

La clase Repair tiene como campos: un cliente, un vehículo, un campo proyecto, para reflejar a que área pertenece (si es una reparación o un “tuneado” …), un campo tarea, para poder reutilizar toda la funcionalidad del modelo Task; una lista de materiales, para llevar un histórico de los materiales que se usan en la OR y, por último, heredará por delegación, un objeto presupuesto para poder facturar la orden de reparación. Quiero indicar que el campo cliente lo hereda del modelo SaleOrder, tal como se refleja en el diagrama.

ResPartner Es el modelo que usa Odoo para representar los Clientes y Proveedores. Un ResPartner puede ser tanto cliente como proveedor. En nuestro caso lo utilizamos para reflejar el cliente de la OR.

Vehicle Nos da entre otras cosas, la clase vehículo. Éste a su vez tiene asociado las clases vehicle.model y vehicle.brand, que, aunque no están en el diagrama, también los necesitaremos para indicar de qué tipo, modelo y marca es el vehículo.

PÁG. 19

Project Utilizaremos el modelo Project, proporcionado por el módulo Project, para representar las áreas: “Revisiones y Reparaciones”, “Chapa y pintura” …

Task Un proyecto está compuesto por tareas. Utilizaremos esta clase para reutilizar su funcionalidad, ya que son los “post-it” de la pizarra Kanban.

SaleOrder Es el presupuesto asociado a la OR.

SaleOrderLine Son las líneas del pedido que están en el presupuesto.

MaterialLine Es una clase nueva, “parecida” a SaleOrderLine, pero sin la parte de facturación. Utilizaremos esta clase para llevar un seguimiento de los materiales que se utilizan en la OR, pero que no se quieren facturar al cliente. Ejemplo: bridas, tornillos, tuercas...

StockMove Es el modelo que usa Odoo para representar los movimientos de almacén. Estos movimientos de almacenes se realizan al consumir un producto.

2.2.4 Diseño de la interfaz gráfica Odoo ofrece una interfaz gráfica predeterminada. Con dicha interfaz podemos acceder al back-end de Odoo e instalar los módulos de forma gráfica, acceder a la configuración y usar los módulos instalados de la parte back-end.

Como hemos mencionado antes, Odoo es un ERP/CRM, por lo que tenemos que repasar los conceptos de horizontalidad y verticalidad de un módulo.

Un módulo de carácter “vertical” tiene una funcionalidad: que sólo se centra en un área del sector, en nuestro caso, el módulo se centra en la funcionalidad de un taller de vehículos. Un módulo de carácter “horizontal” tendría una funcionalidad más transversal.

En nuestro caso, tendremos un conjunto de módulos “verticales” y un menú “horizontal”, que agrupa a todos ellos.

Por lo tanto, en la propia interfaz gráfica de Odoo, se diferencian tres partes claras.

1. El menú Horizontal. Es el menú donde están disponibles todos los módulos “verticales”. Ej: Calendario, Ventas, Facturación Inventario, Taller Mecánico, etc.

En la figura 3. Recuadro de líneas gruesas rojas.

2. El menú Vertical. Cada módulo del menú horizontal, al ser seleccionado, desplegará un menú vertical donde está la funcionalidad asociada a ese sector concreto. Ej: El módulo de Ventas tiene, en su menú vertical, los apartados de: Pedidos, Facturación, Catálogo, Informes, pero no tendrá un apartado de Partes de Hora o HHRR.

En la figura 3. Recuadro de líneas y puntos naranjas.

PÁG. 20

3. La Vista. Es la parte que Odoo nos deja editar con mayor libertad, y en la que mostramos la información pertinente. En Odoo existen tipos concretos de vistas. Ej: Formulario, Calendario, Kanban, Lista… En la figura 3. Recuadro de puntos verde.

Figura 3. Marco de trabajo y vista.

La OCA dispone de un módulo, web_responsive9 que cambia el diseño de la interfaz gráfica por uno con diseño Responsive. Con este módulo se diferencian mucho mejor los menús Horizontales y Verticales.

Menú Horizontal:

Figura 4. Menú Horizontal

9 OCA Web Responsive: https://github.com/OCA/web/tree/11.0/web_responsive

PÁG. 21

Menú Vertical del módulo Sales:

Figura 5. Menú Vertical del módulo Sales.

Remarcar que, en este punto, horizontalidad y verticalidad son conceptos.

Odoo divide las vistas en función de su cometido. Los tipos de vista más comunes son:

Lista (Tree). Muestra los objetos que tenemos en forma de lista. Kanban. Muestra los objetos en forma de post-it. Hay otro modo que es pizarra Kanban que

ordena dichos post-it en columnas. Formulario (Form). Muestra la ficha del objeto. Nos sirve para añadir información de un nuevo

objeto o editar dicho objeto. Búsqueda (Search). Esta vista comparte espacio con las vistas lista y Kanban y sirve para buscar

un conjunto de modelos en función de una lista de parámetros concretos.

Un modelo tiene asociado un conjunto de vistas. Al ser un ERP, no tiene mucho sentido mostrar información que no esté asociada a ningún registro con la BD. Así, podemos definir varias vistas de un mismo tipo, para un modelo, y mostrar una u otra dependiendo de circunstancias de la ejecución. Siempre se mostrará la vista que tenga más prioridad, salvo que se indique lo contrario. La prioridad se asigna mediante un valor numérico, de modo que la mayor prioridad es el 1 y la menor el 99. Por defecto, todas las vistas tienen prioridad 15, podemos bajar (más prioridad) o subir (menos prioridad) el indicador de prioridad definiéndolo con un campo opcional al definir la vista. Así podemos definir la vista que se mostrará por defecto.

Si quisiéramos utilizar una vista que tuviera menos prioridad, tendríamos que indicarlo manualmente en el controlador haciendo referencia a su identificador.

En el siguiente ejemplo indico que cuando se pulse en el campo vehículo del formulario, nos dirija a la vista de tipo formulario que he diseñado para vehículo (con id 'form_view_ref'), en vez de la que tenga mayor prioridad.

<field name="vehicle_id" context="{'form_view_ref': car-workshop.car-workshop_fleet_vehicle_view_form'}/>

En el campo contexto indico que la referencia a la vista formulario del objeto vehicle_id sea la que he definido, y no la vista con mayor prioridad.

El contexto es el conjunto de datos que rodean a self en un momento preciso. Se define como un diccionario de Python.

Como ya he mencionado anteriormente (MVC en Odoo), Odoo tiene su propio motor de plantillas, al que llama QWeb, que utiliza un elemento llamado “<record></record>” para el diseño de las interfaces de usuario.

PÁG. 22

Un record es un registro en la BD de un modelo concreto, por lo que Odoo mapea las vistas, los controladores actions, los datos que queremos precargar, en la BD al instalar o actualizar el módulo.

Una buena práctica es tener un archivo xml por modelo e incluir ahí sus vistas. Para diseñar las vistas tenemos que añadir nuestros récords en el archivo XML como el siguiente ejemplo:

<?xml version="1.0" encoding="utf-8"?> <odoo> <data> <record id="id de la vista form" model="ir.ui.view"> <field name="name">modulo.modelo.form</field> <field name="model">modulo.modelo</field> <field name="priority ">15</field> <field name="arch" type="xml"> <form> <field name="campo 1 del modelo"/> <field name="campo 2 del modelo"/> <field name="campo 3 del modelo"/> </form> </field> </record> <record id="id de la vista tree" model="ir.ui.view"> <field name="name">modulo.modelo.tree</field> <field name="model">modulo.mismo_modelo</field> <field name="arch" type="xml"> <tree> <field name="campo 1 del modelo"/> <field name="campo 2 del modelo"/> <field name="campo 3 del modelo"/> </tree> </field> </record> <record> Cualquier otra vista: vista Kanban, vista Lista, vista Calendario… </record> </data> </odoo>

Ejemplo 1. Diseñar vistas.

Estudiemos el anterior ejemplo. La primera línea es la que indica qué es un fichero xml.

A continuación, tenemos los elementos <odoo><data></data></odoo>; es la estructura establecida por Odoo (a partir de la versión 8.0) para definir la información. Dentro podemos diseñar tanto vistas, como controladores, información de pruebas, plantillas de correo, plantillas para informes, etc.

Las vistas de tipo Formulario, Kanban, Lista, Calendario, Gráfica, Pivot tienen una estructura común. Se crea un record, se indica un id único, un nombre descriptivo, y se indica a qué modelo pertenece con la nomenclatura “modulo.modelo” y, opcionalmente, se indica la prioridad. Luego, dentro del elemento field con el atributo nombre = “arch” se especifica el tipo, y se indica los elementos a mostrar. <field name="arch" type="xml"><form>…</form></field>

PÁG. 23

En función del tipo de campo, Odoo ya está preparado para visualizarlo de una forma concreta.

Si es de tipo Booleano mostrará un Check:

Python: rating = fields.Boolean(string="Rating visible in Website") QWeb: <field name= "rating "/>

Visualización: Ejemplo 2. Definir y mostrar un campo booleano.

En algunos casos es posible cambiar el aspecto por defecto. Por ejemplo, este campo Selection que muestra las posibilidades con elementos radio.

Python: privacy_visibility = fields.Selection("Privacy ",[ [1, "On invitarion only "], [2, "Visible by all employees "], [3, "Visible by following customers "]]) QWeb: <field name="privacy_visibility" widget="radio"/>

Visualización:

Ejemplo 3. Definir y mostrar un campo selection con radio.

Si es de tipo Date mostrará un calendario.

Python: date_order = fields.Datetime("Fecha de pedido") QWeb: <field name=" date_order "/>

Visualización: Ejemplo 4. Definir y mostrar un campo HTML.

PÁG. 24

Si es de tipo HTML mostrará un recuadro de texto enriquecido.

Python: description = fields.HTML() QWeb: <field name="description"/> Visualización:

Ejemplo 5. Definir y mostrar un campo HTML.

Esto conlleva que podemos tener preparado un módulo funcional y listo para usar en poco tiempo. Por el contrario, si quisiéramos personalizar la forma de visualizar los campos de otra manera, tendríamos que investigar la forma de hacerlo.

2.3 Implementación A continuación, me dispongo a explicar los pasos seguidos para implementar cada una de las Historias de Usuario definidas en la etapa de Análisis. Ver tabla 2, Pila de Producto.

En cada punto muestro un extracto del código empleado para dicho propósito. No obstante, está disponible todo el código desde mi cuenta personal de GitHub con perfil oscars8a y en el perfil de la organización de SDi Soluciones Informáticas https://github.com/SDIsl

2.3.1 Diseño y creación de una OR (Historia de Usuario 1.1). Como desgloso en el Anexo “Guía de Uso”. La vista formulario de la Orden de Reparación es la siguiente:

PÁG. 25

Figura 6. Formulario de la OR.

En el propio anexo, explico para qué sirve cada recuadro.

Como ya he explicado en el diseño, el modelo Repair, (la Orden de Reparación) hereda por delegación de SaleOrder (tendrá un campo delegado de la clase SaleOrder). Además, tiene un campo de la clase Task.

Como estos dos campos representan datos que están, a su vez, en sus propias tablas en la BD, es necesario, para mantener la consistencia que, si queremos borrar una OR, primero borraremos el Presupuesto y la Tarea asociadas a dicha OR. Para ello, tengo que sobre-escribir el método para borrar, llamado unlink.

# -*- coding: utf-8 -*- from odoo import api, fields, models, SUPERUSER_ID, _ from odoo.exceptions import UserError class Repair(models.Model): _name = 'car_workshop.repair' _inherit = ['mail.thread', 'mail.activity.mixin', 'portal.mixin'] _order = 'id desc' vehicle_id = fields.Many2one(comodel_name="fleet.vehicle",

string="Vehicle", required=True, ) image_client_vehicle =fields.Binary(

PÁG. 26

related='vehicle_id.image_client_vehicle', store=True, ) name = fields.Char(default="",required=True) repair_title = fields.Char() finished_stage = fields.Boolean("Finished") material_line_ids = fields.One2many(

comodel_name="car_workshop.material_line", inverse_name="repair_id", string="Material Lines", auto_join=True)

sale_order_id = fields.Many2one('sale.order', delegate=True, required=True, ondelete='restrict')

project_task_id = fields.Many2one('project.task', required=True, ondelete='restrict')

@api.multi def unlink(self): # Solo se pueden borrar task y sale asociados si primero se borra

# el repair con el que están asociados. for repair in self: if repair.state not in ('draft', 'cancel'): raise UserError(_(

'You can not delete a sent quotation or a sale order! Try to cancel it before.'))

task_records = self.env["project.task"].search([ ('id', '=', repair.project_task_id.id)])

sale_records = self.env["sale.order"].search([ ('id', '=', repair.sale_order_id.id)])

super(Repair, repair).unlink() for record in task_records: record.unlink() for record in sale_records: record.unlink() return True

2.3.2 Registro de Horas (Historia de Usuario 1.3). Reutilizo el módulo Timesheets, Partes de Hora. Dicho módulo añade la funcionalidad para registrar los trabajos a las tareas (clase Task). Como tengo un objeto tarea dentro de nuestra clase Repair, utilizo los atributos de dicho campo.

Para ello añado el siguiente código dentro de la implementación de la vista formulario de nuestra Orden de Reparación (Repair), concretamente dentro del elemento <notebook>… </notebook> de la vista formulario:

<page string="Work"> <group> <group> <field name="planned_hours" widget="float_time"/> </group> <group> <field name="progress" widget="progressbar"/> </group> </group> <field name="timesheet_ids" context="{'default_project_id': project_id}"> <tree editable="bottom" string="Timesheet Activities" default_order="date"> <field name="name"/> <field name="user_id" invisible="1"/> <field name="employee_id" required="1"/> <field name="date"/>

PÁG. 27

<field name="unit_amount" string="Duration" widget="float_time"/> <field name="project_id" invisible="1"/> </tree> </field> <group> <group class="oe_subtotal_footer oe_right" name="project_hours"> <field name="effective_hours" widget="float_time"/> <field name="children_hours" widget="float_time" attrs="{'invisible' : [('children_hours', '=', 0.0)]}"/> <field name="total_hours_spent" widget="float_time" class="oe_subtotal_footer_separator" attrs="{'invisible' : [('children_hours', '=', 0.0)]}"/> <field name="remaining_hours" widget="float_time" class="oe_subtotal_footer_separator" readonly="1"/> </group> </group> </page>

Figura 7. Partes de Hora.

2.3.3 Pizarra Kanban OR (Historia de Usuario 1.4). Odoo permite definir vistas Kanban por columnas. Recordamos que, en Odoo, una vista Kanban del modelo es listar todos los objetos de ese modelo, que haya en la BD, en forma de etiquetas. Para definir una vista Kanban por columnas, hay que especificar una serie de atributos.

Figura 8. Tipos de vista Kanban.

En la vista Kanban hay que especificar el campo por el cual se definen las columnas, dicho campo tiene que ser de tipo Many2one (debe tener varios posibles valores).

PÁG. 28

<kanban default_group_by="stage_id" class="o_res_partner_kanban"quick_create="true">…</Kanban> Con el atributo default_group_by="stage_id". Uso el campo stage_id. A dicho campo le doy los valores: “En espera”, “En proceso” y “Recogida cliente”.

Defino la vista Kanban. He acortado la vista para explicar sus partes. 

<record id="car-workshop_repair_view_kanban" model="ir.ui.view"> <field name="name">car-workshop.repair.kanban</field> <field name="model">car_workshop.repair</field> <field name="arch" type="xml"> <kanban default_group_by="stage_id" class="o_res_partner_kanban" quick_create="true"> <field name="campo que necesito 1"/> <field name="colors"/> <templates> <t t-name="kanban-box"> <div t-attf-class="oe_kanban_global_click"> <div class="o_kanban_image"> <field name="previsualizo campo"/> </div> <div class="oe_kanban_details"> <strong class="o_kanban_record_title"> <field name="previsualizo campo"/> </strong> <small class="o_kanban_record_subtitle text-muted"> <field name="previsualizo campo"/> </small> <div class="o_kanban_record_bottom"> <div class="oe_kanban_bottom_left"> <field name="previsualizo campo"/> </div> <div class="oe_kanban_bottom_right"> <field name="previsualizo campo"/> </div> </div> </div> <div class="oe_clear"/> </div> </t> </templates> </kanban> </field> </record>

La vista Kanban es la más compleja y versátil de Odoo. Acepta gran cantidad de etiquetas HTML y siempre las definiremos como en el ejemplo anterior. Para ello explico sus bloques.

1. Odoo te obliga a listar primero los campos que vas a mostrar o utilizar. Por ello, antes de la etiqueta <templates>, menciono los campos.

PÁG. 29

2. El elemento <templates> indica a Odoo que utilizaremos el motor de plantillas QWeb. Dentro de esta etiqueta, Odoo acepta etiquetas HTML y permite construir directivas10.

Las directivas en QWeb son un conjunto de etiquetas para implementar la lógica de la vista. Podemos compararlo con JSTL para Java EE.

3. El elemento <t t-name="kanban-box"> es el cuerpo de las etiquetas Kanban. 4. La clase que añadimos a <div t-attf-class="oe_kanban_global_click"> indica a Odoo que al

hacer click nos dirige a la vista formulario del modelo. 5. Los distintos div son las posiciones de la etiqueta para personalizarla.

De esta forma, Odoo sólo mostraría las columnas que tienen elementos. Si no existiera ninguna Orden de Reparación con el estado “En espera”, no se mostraría dicha columna. Por ello, es necesario añadir al campo stage_id el siguiente atributo dentro del modelo Python.

Con el atributo group_expand le indicamos que en la vista Kanban si agrupamos por el campo stage_id, muestre todas las columnas.

stage_id = fields.Many2one(group_expand='_read_group_stage_ids') @api.model def _read_group_stage_ids(self, stages, domain, order): search_domain = [('id', 'in', stages.ids)] if 'default_project_id' in self.env.context: search_domain = ['|', ('project_ids', '=', self.env.context['default_project_id'])] + search_domain stage_ids = stages._search(search_domain, order=order, access_rights_uid=SUPERUSER_ID) return stages.browse(stage_ids)

Figura 9. Vista Kanban de las Ordenes de Reparación.

10 Directivas con el Motor de plantillas QWeb: https://www.odoo.com/documentation/11.0/reference/qweb.html

PÁG. 30

2.3.4 Relación Cliente y vehículo (Historia de Usuario 1.6). Un vehículo siempre va a pertenecer a un cliente y un cliente siempre va a tener uno o más vehículos.

Figura 10. Formulario OR. Vehículo/Cliente

Por ello, es interesante añadir a la vista formulario de Orden de Reparación, el siguiente comportamiento:

Al seleccionar un vehículo, se rellenará automáticamente el cliente asociado. Al seleccionar un cliente:

o Si el cliente sólo tiene un vehículo, completamos el campo “vehículo” con dicho vehículo.

o Si el cliente tiene varios coches, filtra el campo, “vehículo”, dejando sólo los vehículos del cliente:

Si el campo vehículo está ya rellenado (porque el empleado del taller puso un vehículo, pero se ha equivocado y decide buscar por cliente) comprueba que el vehículo pertenece al cliente, si no es el caso, vacía el campo vehículo.

Para ello, hay que definir dos onchange: uno para el campo cliente y otro, para el campo vehículo.

Un onchange, como ya mencioné en el apartado MVC en Odoo, “Controladores de Modelo”, es un decorador que se le añade a la función Python para indicar que queremos que se ejecute dicha función, si se cambia el valor del campo asociado en la vista. En nuestro caso vehicle_id.

@api.multi @api.onchange('vehicle_id') def _onchange_vehicle_id(self): if self.vehicle_id: if self.vehicle_id.customer_id: self.partner_id = self.vehicle_id.customer_id

@api.onchange('partner_id') def onchange_partner_id(self): vehicles_list = self.env['fleet.vehicle'].search( [('customer_id.id', '=', self.partner_id.id)]) vehicles_count = len(vehicles_list) if vehicles_count == 1: self.vehicle_id = vehicles_list[0] elif vehicles_count > 1: if self.vehicle_id and self.vehicle_id.customer_id.id != self.partner_id.id: self.vehicle_id = False

Para filtrar el campo vehículo por los vehículos del cliente seleccionado, lo indicamos en el atributo dominio.

<field name="vehicle_id" domain="[('customer_id','=?',partner_id),]"/>

PÁG. 31

Figura 11. Filtrar vehículos por cliente.

2.3.5 Calendario OR (Historia de Usuario 1.7). Para implementar una vista Calendario, Odoo dispone de la vista Calendar.

En nuestro caso, será la vista de tipo Calendar para el objeto car_workshop.repair. Con esta vista, visualizaremos todas las OR en un calendario. Para ello, es necesario indicar una fecha de inicio (cuándo se inicia la OR) y una duración (por cuánto tiempo se prorroga), utilizando los elementos del Registro de Horas, tenemos dichos campos.

Código XML. Definir vista Calendario:

 <record id="car-workshop_repair_view_calendar" model="ir.ui.view"> <field name="name">car-workshop.repair.calendar</field> <field name="model">car_workshop.repair</field> <field name="arch" type="xml"> <calendar string="Repairs" date_start="date_start" date_delay="planned_hours" color="partner_id"> <field name="name"/> </calendar> </field> </record>

El resultado es el siguiente:

Figura 12. Vista calendario de las Órdenes de Reparación.

PÁG. 32

2.3.6 Facturación (Historia de Usuario 1.8). Una Orden de Reparación tiene un Presupuesto asociado (SaleOrder) y dicho presupuesto hay que facturarlo para cobrar a un cliente.

Odoo cuenta con un modelo de Factura (Account Invoice). Dicho modelo lo tenemos en los módulos de Ventas (ventas a clientes) y en el de Compras (compras a proveedores).

Podemos crear una factura directamente, indicando el cliente y las líneas de producto a facturar, pero tanto Odoo como la Lógica de Negocio de un ERP, lo habitual es seguir el flujo de venta desde el Presupuesto a la propia Factura.

Figura 13. Flujo de facturación.

Como nuestra Orden de Reparación hereda por Delegación un objeto Presupuesto (SaleOrder) tenemos la funcionalidad necesaria, a través del objeto delegado, para el flujo normal de una Venta.

El único inconveniente es que los botones de las vistas en Odoo sólo pueden llamar a las funciones del modelo de la vista, pero no a funciones más profundas, es decir, funciones que pertenezcan a campos (que sean objetos) del modelo. Para soslayar esta limitación, tenemos que definir una función que llame a la función del objeto interno.

En nuestro caso, el campo sale_order_id es el objeto que recibimos de Presupuesto con la Herencia por Delegación, ya mencionada. Si desde la vista de Repair quisiéramos usar la función action_done del campo sale_order_id (para bloquear un Presupuesto), deberíamos hacer lo siguiente:

@api.multi

def action_done(self):

return self.sale_order_id.action_done() Código XML para la definición del elemento botón que llamará a la anterior función:

<button name="action_done" type="object" string="Lock" states="sale help="If the sale is locked, you can not modify it anymore. However, you will still be able to invoice or deliver."/>

Nota: “Bloquear un presupuesto” es una acción común en la Lógica de Negocio en el entorno comercial Ventas/Compras. Dicha acción lo que hace es que no se pueda modificar las condiciones del presupuesto actual. Quedaría “congelado” a la espera de que comercial y cliente lleguen a un acuerdo.

PÁG. 33

La funcionalidad relacionada con el Presupuesto (SaleOrder) y su posterior facturación que es aportada por el campo sale_order_id de Repair es la siguiente:

Enviar Presupuesto por Correo. Confirmar venta. Cancelar. Bloquear. Convertir a Presupuesto. Crear Factura

De las anteriores, he tenido que modificar la función “Crear Factura”.

Para crear una factura, Odoo tiene implementado en la vista de formulario del objeto SaleOrder el botón “Crear Factura”. Dicho botón llama a un asistente para elegir el modo de facturación.

En la siguiente sección explico cómo y por qué no puedo reutilizar dicho asistente desde mi formulario de Orden de Reparación para facturar el presupuesto que sí tengo asociado.

2.3.7 Ejemplo de código no reutilizable: Implementación del Asistente para facturar un Presupuesto.

Esta sección es un ejemplo de alguna funcionalidad que trae Odoo que no es reutilizable. Como indico en el apartado anterior, el formulario asociado por Odoo a Presupuesto (SaleOrder) llama a un asistente para crear una Factura.

El problema está en que dicho asistente espera ser llamado únicamente desde el propio formulario de Presupuesto, pero no desde ningún otro formulario, aunque dicho formulario tenga un campo de tipo SaleOrder (Presupuesto).

La problemática es que dentro de la función que se ejecuta al aceptar el asistente, (ver figura 14. Asistente de facturación) self es una referencia a la clase SaleOrder, cuando en mi caso necesitaría que fuese una referencia a la clase Repair (Nota: esta explicación es una simplificación, ya que la complejidad de la cláusula self en Python excede el propósito de esta memoria).

Por ejemplo, dentro del método original del asistente, la información la saca en este punto:

sale_objs = self.env['sale.order'].browse(self._context.get('active_ids',[]))

Como self._context.get('active_ids',[]), en ese momento, es una instancia de tipo 'car_workshop.repair' los ids que obtiene la función son erróneos.

El objeto implícito self guarda la información del contexto además de almacenar un objeto del modelo que estamos visualizando con la información. Esto significa que guarda el id del objeto u objetos (en el caso de ver una vista Lista o Kanban) que estamos previsualizando.

En nuestro caso, self guarda en el atributo 'active_ids' un objeto de tipo Reparación con un id concreto, que no es el mismo id que tiene el presupuesto, en el campo sale_order_id.

La solución pasa por copiar la función, crearnos un nuevo asistente con la función y cambiar lo que necesitemos.

Nota: Un asistente es un conjunto compuesto por:

Un modelo Python, que hereda de models.TransientModel. Debe tener una función implementada que será la que dé sentido a dicho asistente.

PÁG. 34

Una vista formulario, asociada al modelo anterior, está compuesta como mínimo por dos botones: uno, para aceptar (llamará a la función del modelo) y otra, para cancelar (Odoo trae consigo la funcionalidad “Cancelar”, que cerrará el asistente).

Para solventar el problema he definido un nuevo wizard en el cual obtengo las SaleOrder asociadas a la Orden de Reparación.

Tal como vemos en el siguiente fragmento de código, el objeto sale_orders es el Presupuesto asociado a la Orden de Reparación:

@api.multi def create_invoices_for_carworkshop(self): repair_objs = self.env['car_workshop.repair'].browse( self._context.get('active_ids',[])) active_sales = [] for repair in repair_objs: active_sales.append(repair.sale_order_id.id) sale_orders = self.env['sale.order'].browse(active_sales)

El asistente es el siguiente:

Figura 14. Asistente de facturación.

2.3.8 Informes (Historia de Usuario 1.9 y 1.10). Poder entregar Informes es parte fundamental de cualquier ERP; además de definir un informe, es necesario poder traducirlo al idioma del cliente.

Para hacer esto, he necesitado realizar dos partes:

1º Definir el Informe: Al igual que con las vistas, en Odoo podemos construir Informes asociados a un modelo. Para ello el primer paso es definir el registro del informe, asociando a éste un identificador. Odoo necesita almacenar cada elemento que definimos (vistas, informes, datos de demostración…) en la BD. De esta forma, a la hora de renderizar y mostrar la información, utilizará el informe que tenga asociado el id asociado al modelo.

En el siguiente texto defino el informe de la Hoja de Admisión. Dicho informe sirve al taller para demostrar por qué tiene el coche del cliente en el taller, y no es un vehículo obtenido ilegalmente.

PÁG. 35

Los elementos del Informe son:

El id para identificar el informe y un nombre descriptivo. El modelo del cual sacaremos la información.

En la documentación de Odoo nos indican que, si tenemos la necesidad de realizar un Informe que no está asociado a ningún modelo en concreto, utilicemos un modelo “auxiliar” 11que aúna los modelos que necesitemos, definiendo campos Many2one de dichos modelos en el modelo auxiliar.

El campo report-type indica el resultado. El tipo "qweb-html" nos muestra una página web con la previsualización del informe. El tipo "qweb-pdf" te descarga automáticamente un pdf con el informe.

<?xml version="1.0" encoding="utf-8"?> <odoo> <data> <report id="action_report_admission_sheet" string="Admission Sheet" model="car_workshop.repair" report_type="qweb-html" file="car-workshop.report_admission_sheet" name="car-workshop.report_admission_sheet" print_report_name="'Hoja de Admisión - %s' % (object.name)" /> </data> </odoo>

2º Implementar una plantilla para el informe: Dichas plantillas se definen con el lenguaje de plantillas QWeb.

Primero, tengo que definir una plantilla principal; dicha plantilla es a la que llamamos en el punto anterior. Con esta plantilla indico, con el atributo t-lang="doc.partner_id.lang", que el idioma del informe sea el del cliente.

 <template id="report_admission_sheet"> <t t-call="web.html_container"> <t t-foreach="docs" t-as="doc"> <t t-call="car-workshop.report_admission_sheet_document" t-lang="doc.partner_id.lang"/> </t> </t> </template>

Dentro de la anterior plantilla principal, llamo a la plantilla que define el aspecto visual del informe ("car-workshop.report_admission_sheet_document"). Dentro de los elementos <template>, QWeb nos permite utilizar etiquetas HTML tradicionales.

El resultado del Informe de Admisión es el siguiente:

11 Modelo auxiliar : https://www.odoo.com/documentation/11.0/reference/reports.html#custom-reports

PÁG. 36

Figura 15. Informe Hoja de Admisión.

Para traducir el informe y disponerlo en varios idiomas, hay que realizar los pasos explicados en el siguiente apartado Internalización. Ya que el texto del informe aparecerá en el archivo .po que exportemos.

2.3.9 Internalización (Historia de Usuario 1.11). Uno de los puntos fuertes de Odoo es su sistema de internalización. Para ello proporciona la forma de importar y exportar archivos Poedit (.po).

Poedit también cuenta con un editor de archivos .po, libre, abierto y multiplataforma, usado para el proceso de localización. Está construido con wxWidgets, con licencia MIT.

El funcionamiento de Poedit es el siguiente:

Los archivos .po son una tabla donde se encuentra la frase original y la frase traducida. Ver figura 17, “Añadiendo Traducciones”.

Tenemos que importar un archivo .po por localización y lo nombraremos en función de ésta. Ejemplo: para la localización española, es.po o es_ES.po.

Dichos archivos los importamos, de forma visual, desde los Ajustes de nuestra instancia de Odoo.

Estos archivos los elabora Odoo, listando todas las frases que encuentra dentro de las etiquetas <field name="arch" type="xml"></field> y dentro de las etiquetas <template></template>, así como en el modelo Python, el atributo “string” de los campos que hemos definido.

PÁG. 37

Ya teniendo el archivo, lo abrimos con el editor de texto de Poedit y añadimos la traducción e importamos el archivo con los cambios.

Los pasos a seguir son los siguientes:

1. Activamos el idioma Spanish/Español desde Settings/Languages 2. Exportamos el archivo Poedit desde /Settings/“Import/Export”/Export Translation. Se

descargará un fichero “es.po”. 3. Utilizando el editor de texto de Poedit, añadimos las traducciones. 4. Importamos el archivo Poedit “es.po”. 5. Actualizamos el Idioma Spanish/Español

Figura 16. Exportando localización española.

Figura 17. Añadiendo traducciones.

PÁG. 38

Figura 18. Importando traducciones.

2.4 Pruebas A continuación, expongo las pruebas que he realizado para comprobar la funcionalidad del módulo.

Dichas pruebas consisten en realizar manualmente, lo indicado en la siguiente tabla, tal como lo haría un empleado. Esto significa que tengo que ir al navegador, abrir una instancia de Odoo, ir al menú clientes, darle al botón Crear y rellenar los datos del formulario, para la prueba “Registrar un cliente”.

Dichas operaciones están descritas en la Guía de Uso entregada en los anexos.

Para realizarlas, la empresa, SDi Soluciones Informáticas, me ha proporcionado un servidor en el cual he implementado una instancia de Odoo en producción.

Prueba Resultado Registrar un cliente ✔ Registrar un vehículo ✔ Registrar un producto ✔ Registrar una orden de reparación ✔ Ciclo Presupuestar/Imprimir/facturar una orden de reparación ✔ Internalización ❌

Tabla 4. Pruebas para el módulo SDi Car Workshop.

Internalización. La prueba consistía en comprobar que no había ninguna descripción en inglés y, por lo tanto, el programa estuviera 100% en castellano. No ha resultado, ya que muchas expresiones siguen estando en inglés, aunque esto se soluciona actualizando los archivos de traducción.

PÁG. 39

3. Subproyecto: Catálogo de Neumáticos (SDi Tire Catalogue)

3.1 Análisis 3.1.1 Requisitos funcionales Se desarrollará un módulo back-end para la plataforma Odoo, que permita el visionado de los productos categorizados como “neumáticos”, además del propio registro de productos añadiendo las características propias de los neumáticos, y un buscador que pueda filtrar dichos neumáticos según los requisitos de la búsqueda. Este módulo amplía la funcionalidad del módulo base “SDi Car Workshop”, y se indicará como dependiente de éste.

La clase Producto Odoo dentro de sus módulos base, nos proporciona la clase Producto, que está dentro del módulo Product (product.product). Para poder añadir los campos propios de un neumático, vamos a extender esta clase, como ya he explicado en el apartado de herencia con Odoo.

No nos planteamos hacer una nueva clase para neumático ya que esto nos obligaría a adaptar toda la funcionalidad relacionada con los productos; esto, en la práctica, supone en su mayoría, toda la funcionalidad que nos facilita Odoo: Ventas, Compras, Facturación, Inventario… por lo que es necesario extender la clase product.product.

Los nuevos campos que vamos a añadir son los necesarios para almacenar la información relacionada con un neumático. Para determinar dichos campos y valores me he basado en los disponibles en la página web de venta de neumáticos FeuVert. Los valores y atributos opcionales son una aproximación a los que se necesitarían en la mayoría de los casos.

Los campos y valores son los siguientes:

Un campo booleano, que indique que sí es un neumático, o no. Campo Selection, que represente la anchura de las ruedas, con los valores desde 145 a 245

mm, de 10 en 10 milímetros. Campo Selection, que represente la altura de las ruedas, con valores desde 40 a 75mm, de 5

en 5 milímetros. Campo Selection, que represente el diámetro de las ruedas, con los valores desde 13 a 17

milímetros. Campo Selection, que represente la temporada de las ruedas: Invierno, verano o toda la

temporada.

PÁG. 40

Campo Many2one, que represente la marca de los neumáticos. Será necesario diseñar y desarrollar la clase “Marca Neumático”.

La Clase Marca Neumático Ésta sólo tendrá nombre e imagen del logo de la marca. Será accesible desde el módulo y se podrá crear nuevos registros de marca y editarlas.

El catálogo y la búsqueda El catálogo sólo será una vista Kanban de los productos que tengan activo el campo neumático.

Además, antes de acceder al catálogo, saltará un asistente para indicar el filtrado, indicando los valores de los anteriores campos.

3.1.2 Requisitos no funcionales Es necesario que esté instalado el módulo SDi Car Workshop previamente. Además, al ser un módulo de Odoo deberá ser compatible para la versión 11.0. y cumplir con los requisitos no funcionales especificados en el subproyecto “SDi Car Workshop”.

Es necesario indicar que este módulo no puede menoscabar la funcionalidad del subproyecto anterior, en caso de que haya conflictos entre el módulo SDi Car Workshop y éste, tendrá preferencia a la hora de solucionar dichos conflictos el módulo principal SDi Car Workshop. Por ejemplo: Desinstalar el módulo SDi Tire Catalogue no puede afectar a la funcionalidad del módulo anterior.

3.2 Diseño 3.2.1 Diseño de la base de datos Como hemos mencionado en el Subproyecto 1, la BD es controlada por el ORM de Odoo y nosotros como desarrolladores sólo tenemos que definir las vistas y los modelos.

3.2.2 Diseño de los modelos Diagrama UML

Diagrama 2. Diagrama UML de los modelos del módulo Tire Catalogue

PÁG. 41

Los modelos de SDi Tire Catalogue Nombre de la clase (Python) Archivo Módulo Product inherit_product_product.py Product TireBrand tirebrand.py -- TireWizard tire_wizard.py --

Tabla 5. Modelos del módulo SDi Tire Catalogue

Product Es el modelo que usa Odoo para representar un producto. Para indicar que dicho producto es un neumático, utilizaremos un campo booleano; si es verdadero, mostraremos, en la vista, los demás campos propios de un neumático: anchura, altura, diámetro, diámetro, marca, tipo.

TireBrand Marca de neumático, basándonos en VehicleBrand, sólo guardaremos el nombre y el logotipo de la marca.

TireWizard Es el modelo que utilizaremos para realizar el asistente, tiene los mismos campos que un neumático y los valores que le demos en el asistente será por los que filtre.

3.2.3 Diseño de la interfaz gráfica Como ya hemos explicado, para la implementación de la interfaz gráfica, hay que utilizar el lenguaje de plantillas de Odoo, QWeb.

3.3 Implementación A continuación, explico cómo he realizado esta segunda parte del Proyecto.

Al igual que en la primera parte expongo la implementación de las Historias de Usuario que he definido para el Subproyecto 2, mediante los siguientes extractos de código.

3.3.1 Extender la clase Producto para añadir los atributos de un Neumático (Historia de Usuario 2.1).

Tal como he explicado anteriormente, extiendo la clase ya existente de Producto utilizando la Herencia Clásica, añadiendo los nuevos campos: anchura, altura, diámetro, temporada y marca.

En esta primera versión, tal como he explicado en el análisis, he optado por definir valores estáticos para los campos de tipo Selection, pero es un punto a tener en cuenta a la hora de mejorar este módulo.

from odoo import api, fields, models,_ class Tire(models.Model): _inherit = 'product.product' is_a_tire = fields.Boolean(string="It's a tire?", ) widthSelection = [] for x in range(145, 255, 10): widthSelection.append((str(x), str(x))) heightSelection = [] for x in range(40, 80, 5): heightSelection.append((str(x), str(x)))

PÁG. 42

diameterSelection = [] for x in range(13, 18): diameterSelection.append((str(x), str(x))) width = fields.Selection(string="Width", selection=widthSelection, required=False, ) height = fields.Selection(string="Height", selection=heightSelection, required=False, ) diameter = fields.Selection(string="Diameter", selection=diameterSelection, required=False, ) brand_id = fields.Many2one(comodel_name="tire_catalog.tire_brand", string="Brand", required=False, ) season = fields.Selection(string="Season", selection=[('summer', 'Summer'), ('winter', 'Winter'), ('allseason', 'All season')], required=False, )

Una vez que añadimos nuevos campos al modelo de Producto, cabe preguntarse qué ocurre con las vistas ya definidas del modelo Producto que, en un principio, no reflejan los nuevos campos (ya que dichos campos los he añadido yo).

Para ello, Odoo nos permite utilizar la tecnología XPath12, la cual consiste en que busca el elemento donde queremos incrustar el nuevo código y, utilizando el atributo “position”, podemos determinar dónde localizar los nuevos elementos.

<record id="product_template_form_view" model="ir.ui.view"> <field name="name">product.template.common.form</field> <field name="model">product.product</field> <field name="inherit_id" ref="product.product_normal_form_view"/> <field name="arch" type="xml"> <xpath expr="//div[@name='options']" position="inside"> <div> <field name="is_a_tire"/> <label for="is_a_tire?"/> </div> </xpath> <xpath expr="//page[@name='general_information']"position="after"> <page string="Tire Attributes" attrs="{'invisible':[ ('is_a_tire','=',False)]}" name="tire_attributes"> <group> <field name="width"/> <field name="height"/> <field name="diameter"/> </group> <group> <field name="brand_id"/> <field name="season"/> </group> </page>

12 Xpath: https://www.w3schools.com/xml/xpath_intro.asp

PÁG. 43

</xpath> </field> </record>

Hemos añadido el campo check para determinar si el artículo es un neumático. Cuando éste se marca, se vuelve accesible la pestaña Atributos de Neumático.

Figura 19. Artículo Neumático.

3.3.2 Implementar un asistente para la búsqueda de Neumáticos (Historia de Usuario 2.3). Al implementar el asistente definimos la clase Python que herede de models.TransientModel; como ya hemos mencionado, los objetos que se creen con una clase TransientModel, no se persisten en BD.

Figura 20. Asistente para la Búsqueda de Neumáticos.

El botón de Búsqueda ejecutará la función create_request definida en el modelo.

La función create_request se encarga de obtener los datos seleccionados y devolver la vista resultante. En Odoo podemos definir un controlador desde Python, por medio de un diccionario compatible con JSON. En este caso, el controlador resultante es una vista del modelo product.product de los tipos Kanban, form, tree y search con el contexto y el dominio seleccionados.

PÁG. 44

@api.multi def create_request(self): domain = [("is_a_tire","=",True)] context = {} if self.width: context["search_default_width"] = self.width if self.height: context["search_default_height"] = self.height if self.diameter: context["search_default_diameter"] = self.diameter if self.brand_id: context["search_default_brand_id"] = self.brand_id.id if self.season is not False: context["search_default_season"] = self.season return { "name": "Tires", "type": "ir.actions.act_window", "res_model": "product.product", "views": [[False,"kanban"],[False, "form"],[False, "tree"], [False, "search"]], "context": context, "domain": domain, "target": "main", }

Al definir que los parámetros se guarden en el contexto, se filtrarán los resultados, utilizando la caja de búsqueda. De esta forma, el usuario puede cambiar dichos parámetros posteriormente.

Por otra parte, hemos añadido al dominio que el producto tenga el check “es neumático” marcado, filtrando así por artículos que sean neumático.

Figura 21. Filtrado Neumático.

3.3.3 Visualizar Neumáticos Kanban (Historia de Usuario 2.2). El resultado de la búsqueda es la visualización de los neumáticos en vista Kanban.

Como los neumáticos no dejan de ser Productos, estoy mostrando la vista Kanban del modelo Product, en la cual los productos a mostrar han sido filtrados por la búsqueda de neumáticos realizada con el asistente, en el punto anterior.

Figura 22. Vista Kanban de neumáticos.

PÁG. 45

3.4 Pruebas Al igual que en el apartado de pruebas 2.4, he realizado las siguientes pruebas manualmente tal como haría un empleado.

Para ello he utilizado la instancia de Odoo que tengo en el servidor.

Las pruebas están definidas en la Guía de Uso, tal como indico en el apartado de pruebas anterior.

Pruebas Resultados Registrar un neumático ✔ Editar un neumático ✔ Hacer búsqueda con el filtro ✔ Desinstalar el módulo y ver que no afecta a los productos creados. ✔

Tabla 6. Pruebas para el módulo SDi Tire Catalogue.

La prueba “Desinstalar el módulo” no está definido en la Guía de Uso.

Dicha prueba consiste en, una vez instalados los dos módulos y registrar neumáticos, desinstalar el módulo SDi Tire Catalogue y comprobar la consistencia de la BD. En concreto, observar el estado de los productos registrados como neumáticos.

Nota: Recuerdo que un neumático no es más que un producto al que se le han añadido campos referentes a los neumáticos.

El resultado es que persisten los productos registrados como neumáticos con la diferencia de que se han eliminado los campos que añadía el módulo SDi Tire Catalogue.

Dicho resultado es aceptable, ya que lo que nos interesa es el producto junto con el nombre y el precio persista en el sistema, pues éste puede estar reflejado en alguna venta.

PÁG. 46

4. Seguimiento y Control

4.1 Alcance y objetivos alcanzados. Con la realización de este proyecto se han alcanzado el 92,86% de las historias de usuario propuestas en el apartado de análisis, de forma satisfactoria.

Al finalizarlo, se ha obtenido un conjunto de módulos para la plataforma Odoo 11.0, que permite al usuario:

Registrar Clientes y Proveedores, tal como se hace normalmente en Odoo. Registrar Productos, tal como se hace normalmente en Odoo. Registrar productos, indicando que son neumáticos y añadiendo sus propiedades (altura,

anchura, diámetro, marca y tipo), con SDi Tire Catalogue. Registrar marcas de neumáticos, con SDi Tire Catalogue. Buscar con un filtrado los neumáticos que cumplan las condiciones deseadas, con SDi Tire

Catalogue. Registrar vehículos, tal y como se hace con el módulo de Fleet. Registrar modelos y marcas, tal y como se hace con el módulo de Fleet. Registrar una Orden de Reparación, organizadas en áreas. Visualizar en una pizarra Kanban las órdenes de reparación. Módulo parcialmente en inglés y castellano.

Al concluir el proyecto, se han creado los siguientes entregables:

- Módulo para la Gestión de Talleres. - Módulo Catálogo de Neumáticos. - Módulo Cambios estéticos. - Memoria del Proyecto. - Anexo. Actas de Reuniones. - Anexo. Tabla de tiempos para el Despliegue. - Anexo. Guía de Uso.

4.2 Tiempo de ejecución real y desviaciones El alcance del proyecto, así como su pila, cambiaron durante el desarrollo. El principal motivo ha sido el tener que adaptarme a una nueva tecnología, comprender su funcionamiento y limitaciones, además de una serie de cambios en el diseño, concretamente, en el formulario de la Orden de Reparación, que se han ido añadiendo a cada sprint.

PÁG. 47

Por otra parte, me han solicitado la realización de una Guía de Uso y un Informe de Despliegue. Al no estar en la planificación inicial, he decidido añadirlo en un 5º Sprint de una semana.

En la siguiente tabla, podemos ver las desviaciones en cuestión.

Sprint ID Nombre Coste Inicial(h) Coste real (h) Desviación (h) Planificación 20 20 0 1 H1.1 Diseño y creación de

una OR

24 78

30

70

6

8 H1.5 Registrar clientes,

vehículos, proveedores

20

25

5

H1.3 Registro de Horas 17 5 12 H1.4 Pizarra Kanban OR 17 10 7

2 H1.2 Alertas pre-iTV 7

64

0

85

7

21 H1.6 Ver relación cliente y

vehículos 17 20 3

H1.7 Calendario tareas 17 5 12 H1.8 Facturación 23 50 27 H1.1 Diseño y creación de

una OR - 20

20

3 H2.1 Definir artículo neumático

23

69

20

65

3

4 H2.2 Kanban neumáticos 23

5

18

H2.3 Filtrar neumáticos 23 20 7 H1.1 Diseño y creación de

una OR - 20

20

4 H1.9 Informes 23

69

25

75

2

6

H1.10 Informes Detalle 23 25 2

H1.11 Internalización 23 25

2

5 Guía de Usuario y Despliegue.

-- -- 15 -- --

TOTAL 300 330 30 Tabla 7. Pila final. Desviación

PÁG. 48

5. Conclusiones

5.1 Personal Mi mayor interés, en la realización de este Trabajo de Fin de Grado, era aprender las tecnologías suficientes vinculadas a los Servicios en la Nube (SaaS13), un sector que me parece muy interesante por el mero hecho de tener un servicio sin tener que preocuparme desde dónde lo realice, qué Sistema Operativo use, o no tener que instalar ninguna aplicación en el dispositivo a excepción del navegador.

Odoo es una plataforma para instanciar dichos servicios en la Nube por lo que estoy contento con la experiencia, aunque el mundo ERP no es precisamente emocionante.

Además, hay que tener en cuenta sus limitaciones, y el grave error de no tener un motor de plantillas que te permita utilizar lenguajes de marcado estandarizados, como HTML.

Por otra parte, me ha parecido muy difícil entrar en el mundo ERP, teniendo en cuenta que hay una Lógica de Negocio bastante compleja y extensa, relacionada con los negocios y que es necesario conocerla para poder entender lo que estás implementando.

Este último punto se agrava con el hecho de que Odoo te da mucha funcionalidad y Lógica de Negocio ya implementada, que en un principio desconocía, por lo que modificar dicha funcionalidad es una tarea titánica, aunque es el precio a pagar si quieres utilizar funcionalidad ya implementada. Lo mismo pasaría con Prestashop o Wordpress.

Sin olvidarme de que, además, tengo que realizar una aplicación genérica (un vertical) que sirva para todos los negocios.

No todo el mundo gestiona los recursos de la misma forma. Un taller pequeño puede que no realice presupuestos, sino que utilice un trato verbal con el cliente y la factura ni la imprima, o puede que sea una empresa más grande que necesite un mayor control de sus ingresos y gastos.

13Software como servicio: https://es.wikipedia.org/wiki/Software_como_servicio

PÁG. 49

5.2 Técnico Tal como hemos visto anteriormente, Odoo proporciona mucha funcionalidad desde el principio. Esto supone que, en poco tiempo, podemos tener un ERP funcionando.

Teniendo en cuenta que es una plataforma Open Source (y que, por tanto, no hay que pagar por licencia) podemos ofrecer el producto de forma más competitiva comparado con la competencia.

De esta forma, Odoo pretende ser el ERP Open Source capaz de competir con otros ERP privativos como SAP o SalesForce.

Figura 23. Odoo líder ERP Open Source.

Por otra parte, el tener tanto código implica aprender la plataforma, especializarse y aceptar sus limitaciones.

Las limitaciones que he encontrado al utilizar la plataforma Odoo, se basan en mi propia experiencia y, por lo tanto, es posible que se puedan solventar, aunque lo desconozca.

Dichas limitaciones son las siguientes:

1. Se realiza Data Pull. Las vistas cogen la información del controlador, tal como se realiza en el modelo 1 de la arquitectura de Aplicaciones Web, y no Data Push, como se hace la arquitectura MVC convencional. Por ese motivo, me ha resultado un poco más complicado de utilizar que lo que estaba acostumbrado.

2. Un modelo por Vista. Cada vista depende de un modelo del cual cogerá los datos. Se pueden diseñar distintos tipos de vista para dicho modelo. Pero si quisieramos hacer una vista con información estática o de distintos modelos, tendríamos que investigar el diseño de Plantillas con QWeb.

3. La función @api.onchage en el Modelo. Odoo permite definir funciones que se ejecutarán cuando el valor de un elemento concreto cambie. Dicha función se realizaría tradicionalmente con JavaScript desde la vista del formulario. Pero Odoo no deja de forma sencilla definir funciones JS. A cambio, nos deja definir dichas funciones en Python con el decorador @api.onchage. El problema viene, cuando quieres tener dos vistas distintas de un mismo modelo y quieres que el onchage definido en dicho modelo, sólo se active en una sola vista.

4. Funciones poco reutilizables. Como he indicado anteriormente, con el ejemplo “Implementación del asistente para facturar presupuesto”, hay veces que por la naturaleza del propio framework de Odoo, no está pensado para que la función pueda ser llamada desde otros puntos.

PÁG. 50

Por otra parte, Odoo tiene las siguientes ventajas:

1. Coste 0€ por licencia. Esto implica pago por servicio y/o contratación de soporte, lo que le hace más competitivo.

2. Modular. La plataforma de Odoo está compuesto por módulos, lo que supone tener sólo lo necesario.

3. Internalización. Odoo nos asegura poder internalizar cualquier modulo. 4. Open Source desde el principio. Las tecnologías principales empleadas tienen licencias Open

Source: a. PostgreSQL: PostgreSQL License. b. Python: Python Software Foundation License. c. Poedit: MIT License

Esto quiere decir que nuestros desarrollos no dependen de las decisiones que puedan tomar grandes corporaciones.

5. Una comunidad activa. La ya mencionada OCA, Odoo Community Association, tiene una amplia colección de repositorios que aseguran la continuidad de Odoo como proyecto Open Source. Una asociación española, la AEO, Asociación Española de ODOO, es una asociación de carácter nacional que cuenta con el apoyo de 31 empresas españolas, entre ellas SDi Soluciones S.L.

5.3 Lecciones Aprendidas (LLAA) TITULO: Tan importante es el manejo de las Tecnologías, como el Contexto del Cliente.

RESUMEN: Como Informáticos, es importante conocer los lenguajes y tecnologías empleadas.

Pero, si no te molestas en comprender el vocabulario y contexto de nuestro cliente, es sumamente difícil poder programar una aplicación de calidad.

Por lo tanto, antes de ponerse a programar una funcionalidad es aconsejable estudiar cuál es el contexto en el que se mueve el cliente.

Ejemplo: ¿Qué es un Presupuesto?, ¿Qué es un Pedido de Venta?, ¿Qué es un Albarán?, Etc.

5.4 Mejoras a Futuro. Actualmente en el módulo SDi Tire Catalogue, los atributos asociados a los neumáticos se han añadido de forma estática. Esto quiere decir que no podemos añadir nuevos valores a los Selection, y hace que no sea escalable con el tiempo, por lo que es necesario definir una o varias clases para gestionar dichos atributos y pueda ser escalable.

Dichos campos podrían ser únicamente textuales y que el empleado añadiera los valores, pero preferimos disponer de valores por defecto ya que las medidas de un neumático están estandarizadas. Y pensamos que es mejor disponer de valores predefinidos para que el empleado pueda seleccionarlos sin posibilidad de equivocarse.

PÁG. 51

6. Bibliografía

ORM ODOO: https://www.odoo.com/documentation/11.0/reference/orm.html AEO, Asociación Española de ODOO: https://www.aeodoo.org Explicación de Self:

https://pythontips.com/2013/08/07/the-self-variable-in-python-explained/ Página Web de compra y comparación de Neumáticos FeuVert:

https://www.feuvert.es/neumaticos Odoo líder ERP Open Source: https://www.odoo.com/es_ES/ Poedit, Wikipedia/ Licencia. https://es.wikipedia.org/wiki/Poedit Licencia Python. https://es.wikipedia.org/wiki/Python Licencia PostgreSQL: https://es.wikipedia.org/wiki/PostgreSQL

PÁG. 52

7. Anexos

7.1 Anexo Historias de Usuario A continuación, desgrano las historias de usuario del punto 0.3.2

ID H1.1 Nombre Diseño y creación del modelo “Orden de Reparación” Descripción Como usuario quiero poder tener de forma digital una orden de reparación. Y

poder editarla. Coste 24 Valor M Dependencias H1.5 Condiciones de Satisfacción

Debe guardar todos los aspectos relevantes de una Orden de Reparación común.

ID H1.2 Nombre Programar alertas Descripción Como usuario quiero poder programar alertas para que me avisen si está próximo

que un vehículo tenga que pasar la iTV. Coste 7 Valor C Dependencias H1.5 Condiciones de Satisfacción

Indicando la fecha de la última revisión de iTV del vehículo tiene que generar una alerta.

ID H1.3 Nombre Registro de horas Descripción Como jefe quiero poder llevar un registro de lo que tardan los operarios al realizar

una tarea en un vehículo concreto. Coste 17 Valor S Dependencias H1.1 Condiciones de Satisfacción

Debe guardar el número de horas, el empleado y el concepto de esas horas.

PÁG. 53

ID H1.4 Nombre Pizarra Kanban Descripción Como usuario quiero poder ver todas las órdenes de reparación que tengo en

taller, de forma gráfica y vistosa. Coste 17 Valor M Dependencias H1.1 Condiciones de Satisfacción

Mostrar de forma “Pizarra Kanban” las ordenes de reparación. Cada etiqueta (la Orden de reparación) debe mostrar la información más

relevante: cliente, vehículo, fecha del día que entró, fecha estimada y una imagen del vehículo.

ID H1.5 Nombre Registrar clientes, vehículos, modelos, proveedores Descripción Como usuario quiero poder guardar información general de los clientes, vehículos y

proveedores. Coste 20 Valor M Dependencias Condiciones de Satisfacción

Debe guardar la información más relevante de cada modelo.

ID H1.6 Nombre Ver coches y clientes Descripción Como usuario quiero ver los coches que tiene un cliente. Y ver de qué cliente es un

vehículo concreto. Coste 17 Valor S Dependencias H1.5 Condiciones de Satisfacción

Desde cliente quiero ver todos los vehículos que tiene registrados. Desde un vehículo quiero saber a qué cliente pertenece.

ID H1.7 Nombre Calendario tareas Descripción Como usuario quiero tener un calendario con las ordenes de reparación, tanto

pendientes como en proceso. Coste 17 Valor S Dependencias H1.1 Condiciones de Satisfacción

Tener un calendario con las ordenes de reparación como evento.

PÁG. 54

ID H1.8 Nombre Presupuesto y Facturación Descripción Como usuario quiero poder presupuestar y facturar al cliente. Y poder rectificar

dicho presupuesto o factura (en función de la orden de reparación). Coste 23 Valor M Dependencias H1.1, H1.5 Condiciones de Satisfacción

Sacar un presupuesto a partir de la Orden de Reparación. Facturar dicho presupuesto.

ID H1.9 Nombre Informes Descripción Como usuario quiero poder imprimir informes. Entre ellos, la hoja de admisión,

orden de reparación, presupuesto y factura. Coste 23 Valor M Dependencias H1.1, H1.8, H1.5 Condiciones de Satisfacción

Poder imprimir en formato PDF.

ID H1.10 Nombre Informes Detalle Descripción Como usuario quiero poder personalizar los informes con el logo e información de

mi empresa. Coste 23 Valor M Dependencias H1.1, H1.5, H1.8, H1.9 Condiciones de Satisfacción

Personalizar los informes añadiendo el logo y la información de mi empresa (nombre, dirección, teléfono de contacto).

ID H1.11 Nombre Internalización Descripción Como usuario quiero poder cambiar el idioma de la aplicación de forma íntegra. Coste 23 Valor S Dependencias Todas las anteriores. Condiciones de Satisfacción

Poder tener la aplicación en completo inglés. Poder tener la aplicación en completo castellano.

PÁG. 55

7.1.1 Para el subproyecto 2, SDi Tire Catalogue: Identifico las siguientes historias de usuario:

ID H2.1 Nombre Definir artículos de tipo Neumático Descripción Como usuario quiero poder guardar productos de tipo neumático. Coste 23 Valor M Dependencias Condiciones de Satisfacción

Deben guardar, al menos, los atributos: Anchura Altura Diámetro Marca Temporada (verano, invierno, todas las temporadas)

ID H2.2 Nombre Kanban Neumáticos Descripción Como usuario quiero poder mostrar los productos de tipo neumático como un

"catálogo". Coste 23 Valor M Dependencias H2.1 Condiciones de Satisfacción

Mostrar imagen y nombre de cada producto de forma ordenada.

ID H2.3 Nombre Filtrar neumáticos Descripción Como usuario quiero poder filtrar en el catálogo por uno o varios atributos (de

neumático) específicos. Coste 23 Valor M Dependencias H2.1, H2.2 Condiciones de Satisfacción

Filtrar el catálogo en función de los atributos especificados.

PÁG. 56

7.2 Anexo Actas de Reuniones.

Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Viernes, 2 de marzo de 2018 Lugar Centro Científico Tecnológico

Hora inicio 17:00 Hora finalización 17:30

Asistentes Francisco José García Izquierdo Óscar Soto Ochoa

Orden del día Análisis Inicial. Documentos relacionados Memoria del TFG v1

Acuerdos Adoptados en la 1º Reunión Responsable Realizar un Análisis Inicial explicando la idea general del Trabajo para tener, a grandes rasgos, los requisitos exigidos por la empresa SDi Soluciones.

Óscar Soto Ochoa

Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Miércoles, 7 de marzo de 2018 Lugar Centro Científico Tecnológico



Orden del día Subproyecto 1 SDi Car Workshop Requisitos funcionales Requisitos no funcionales

Documentos relacionados Memoria del TFG v2

Acuerdos Adoptados en la 2º Reunión Responsable Redactar los requisitos funcionales y no funcionales, no indicándolos en forma de lista, como en un principio, sino en una forma más textual y explicativa.

Óscar Soto

Revisión de los cambios acordados en el punto anterior. Francisco García

Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Jueves, 19 de abril de 2018 Lugar Centro Científico Tecnológico



Orden del día Resumen. Sumario. Contexto. Metodologías empleadas.


PÁG. 57

Acuerdos Adoptados en la 3º Reunión Responsable Redactar los puntos: Resumen, Sumario, Contexto y Metodología empleada hasta la fecha, plasmando en el último punto la adaptación realizada por la empresa con respecto a la metodología SCRUM.

Óscar Soto


Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Miércoles, 9 de mayo de 2018 Lugar Centro Científico Tecnológico



Orden del día Planificación Historias de Usuario Pila de Producto Subproyecto 1 SDi Car Workshop Diseño Inicial


Acuerdos Adoptados en la 4º Reunión Responsable Redactar la planificación prevista para la realización del trabajo. Como la metodología elegida es SCRUM es necesario plasmar las Historias de Usuario y la Pila de producto. En el diseño inicial se tiene que indicar la naturaleza del framework empleado, Odoo.

Óscar Soto


Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Martes, 22 de mayo de 2018 Lugar Centro Científico Tecnológico



Orden del día Subproyecto 1 SDi Car Workshop Diseño Implementación Inicial Subproyecto 2 SDi Tire Catalogue Requisitos Funcionales Requisitos no Funcionales Diseño Implementación Inicial


PÁG. 58

Acuerdos Adoptados en la 5º Reunión Responsable Redactar el Diseño del 1º subproyecto, y la implementación de éste. Para ello, es necesario tener en cuenta los puntos más importantes de cada historia de usuario. Redactar Los requisitos funcionales y no funcionales del 2º subproyecto, así como el Diseño e implementación realizada hasta el momento.

Óscar Soto


Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Martes, 12 de junio de 2018 Lugar Centro Científico Tecnológico



Orden del día Redefinir del Subproyecto 1 SDi Car Workshop: Diseño Implementación Redefinir: Seguimiento y Control


Acuerdos Adoptados en la 6º Reunión Responsable Se ha acordado cambiar el tipo de redacción al ser ésta demasiado coloquial para este documento. Los puntos por revisar son: Diseño e Implementación del 1º subproyecto y el apartado Seguimiento y Control.

Óscar Soto


Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Martes, 26 de junio de 2018 Lugar Centro Científico Tecnológico



Orden del día Implementación subproyecto Car Workshop Implementación subproyecto Tire Catalogue Seguimiento y Control


Acuerdos Adoptados en la 7º Reunión Responsable Se ha acordado rebajar la cantidad de código incluido en el apartado de implementación de cada subproyecto, y dotarlo de una mayor descripción para su entendimiento. Además, incluir una tabla de desviación de tiempos en el apartado Seguimiento y Control.

Óscar Soto


PÁG. 59

Proyecto Diseño de Software de Gestión de Talleres con Odoo Fecha Lunes, 9 de Julio de 2018 Lugar Centro Científico Tecnológico



Orden del día Implementación subproyecto Tire Catalogue Seguimiento y Control Conclusiones Agradecimientos Formato


Acuerdos Adoptados en la 8º Reunión Responsable Se ha acordado ajustar el código incluido en el apartado de implementación, además de dotarlo de mayor descripción. Incluir en el anexo, las actas de reunión realizadas durante todo el proceso, teniendo en cuenta, para ello, los mensajes intercambiados y la documentación enviada. Además, añadir un apartado de Agradecimientos y Conclusiones. Por último, revisar formato y presentación del documento al igual que la redacción del mismo.

Óscar Soto


PÁG. 60

7.3 Anexo Tabla de tiempos para el Despliegue. 7.3.1 Despliegue SDi Talleres Informe de Tiempos y despliegue para el vertical SDi Talleres.

Dicho informe es una aproximación del tiempo que se necesita para el despliegue del vertical de talleres en un nuevo cliente.

A continuación, se dispone en forma de tabla los puntos a realizar para el despliegue del vertical, SDi Talleres, en el cliente.

A realizar Tiempo Independiente Dominio/ Hosting Solicitud Dominio -- ✔ Solicitud de Servidor en OVH -- ✔ Backups Amazon S3 -- ✔ Preparar Entorno de Instalación Instalar Git 0-5 min Instalar Docker 5-10 min Instalar Docker-Compose 0-5 min Instalar Odoo/Scaffolding 10-15 min Configuración 10-15 min Instalar Módulos Previos l10n_es 5-10 min ✔ web_responsive 0-5 min ✔ l10n_es_toponyms y Actualizar nombres GeoNames 5-45 min ✔ Instalar Vertical SDi Talleres SDi Car Workshop 0-5 min SDi Tire Catalog 0-5 min SDi Aesthetic Changes 0-5 min Configuración Parametrización 5-15 min Crear Usuarios -- Formación --

*Los pasos independientes son aquellos que no tenemos la opción de agilizar.

Estimación de Tiempos:

Tiempo Optimista 40 min Tiempo Pesimista 140 min

Tiempo más probable 60 min Técnica PERT (tO + 4tM + tP) / 6 = 90 min

Podemos estimar que tardaremos 90 minutos, en implantar el vertical de Talleres en un nuevo cliente, sin miedo a equivocarnos.

GUÍA DE USO. SDI TALLERES Óscar Soto Ochoa

Para el módulo SDi Car Workshop y SDi Tire Catalog

Por Óscar Soto Ochoa.

Nota*. Esta es una guía provisional para el vertical de talleres. Es posible que algunas

imágenes no coinciden.

Índice

¿Qué podemos hacer? 3

Paso a paso… 3

Registrar clientes 4

Registrar Productos y Neumáticos 5

Registrar Marcas de Neumáticos 6

Búsqueda de un neumático 6

Registrar Vehículos, Modelos y Marcas 7

Registrar una Orden de Reparación 9

Pizarra Kanban 10

Registrar Ord. Reparación (Nuevo cliente) 10

Registrar Ord. Reparación (Cliente existente) 13

Todo lo que podemos hacer en la Ord. de Reparación 14

Migas de pan Y botonera de Crear, Editar, Guardar y Descartar. 15

Botones relacionados con el presupuesto y la facturación. 16

Diagrama de Estado de la reparación. 16

Título, Imagen, Señalizador y Favorito. 17

SmartButtons Facturas, Imprimir Informes, Finalizar la OR. 17

Información Cliente, Vehículo, Responsable, Área. 18

Fecha de entrada, de entrega estimada,Tags… 19

Descripción. 19

Presupuesto, Materiales, Trabajos y Otra Información 19

Presupuesto 20

Materiales 20

Trabajos 21

Otra Información 21

Historial de Cambios. 22

¿Qué podemos hacer?

1. Registrar Clientes y Proveedores. Tal como se hace normalmente en Odoo.

2. Registrar Productos. Tal como se hace normalmente en Odoo.

3. Registrar productos indicando que son neumáticos y añadiendo sus propiedades

(altura, anchura, diámetro, marca y tipo). Con SDi Tire Catalog*

4. Registrar marcas de neumáticos. Con SDi Tire Catalog*

5. Buscar con un filtrado los neumáticos que cumplan las condiciones deseadas. Con

SDi Tire Catalog*

6. Registrar vehículos. Tal como se hace con el módulo de Fleet.

7. Registrar modelos y marcas. Tal como se hace con el módulo de Fleet.

8. Registrar una Orden de Reparación, organizadas en áreas.

9. Visualizar en una pizarra kanban las órdenes de reparación.

10. Módulo completamente en inglés y Castellano. En proceso*

Paso a paso…

Acceder al vertical de talleres. Desde el icono → Taller de reparación

Registrar clientes

Nos dirimos a:

Si escribimos el CP. en el tercer campo de la Dirección, “Location completion”, nos auto-

rellenará los siguientes campos: Ciudad, Comunidad autónoma, CP, País.

Registrar Productos y Neumáticos

Nos dirigimos a:

La diferencia entre un producto cualquiera y un neumático es que tiene la casilla de ¿Es un

neumático marcada? Además de los atributos propios de un neumático.

.

Registrar Marcas de Neumáticos

Nos dirigimos a:

Búsqueda de un neumático

Nos dirigimos a:

Esto hará que aparezca un asistente para realizar la búsqueda. El resultado será una vista

kanban de productos, que sean de tipo neumático y que cumplan lo especificado.

Dichos filtros se añaden en la caja de búsqueda, por lo que es posible quitar filtros o añadir

filtros a mano.

Registrar Vehículos, Modelos y Marcas

Para añadir vehículos. Nos dirigimos a:

Para añadir marcas y modelos de vehículos. Nos dirigimos a:

Añadir una marca:

Añadir un modelo, en menú anterior:

Registrar una Orden de Reparación

Para añadir una Orden de Reparación nos dirigimos al menú Área seleccionamos el área,

en concreto “Reparaciones y Revisiones” y en la pizarra kanban creamos la Orden

Reparación.

Pizarra Kanban

Para mostrar la pizarra kanban nos dirigimos al menú Área seleccionamos el área, en

concreto “Reparaciones y Revisiones”. Con ella podemos ver de un solo vistazo las órdenes

de reparación y en qué estado se encuentran: “en espera”, “en proceso” y para recoger por

el cliente.

Registrar Ord. Reparación (Nuevo cliente)

Desde el equipo de SDiCloud proponemos los siguientes pasos para registrar una

incidencia de un nuevo cliente.

Los pasos son los siguientes:

1. Creamos una reparación desde el menú Áreas/área.

2. Desplegamos la pestaña Cliente y elegimos “Crear y editar...”

3. Indicamos Nombre, CP, Móvil y correo electrónico.

4. Desplegamos Vehículo y seleccionamos “Crear y editar...”

5. Introducimos el Modelo/Marca y Matrícula. Nos podemos fijar que ya tenemos

seleccionado el cliente.

Paso a paso:


2. Desplegamos la pestaña Cliente y elegimos “Crear y editar...”

3. Indicamos Nombre, CP, Móvil y correo electrónico.

4. Desplegamos Vehículo y seleccionamos “Crear y editar...”

5. Introducimos el Modelo/Marca y Matrícula. Nos podemos fijar que ya tenemos

seleccionado el cliente.

Registrar Ord. Reparación (Cliente existente)

Este circuito está pensado para un cliente habitual que ya tiene sus vehículos registrados.

En el caso de que el cliente trajera un vehículo no registrado ir al punto 4. del apartado

anterior.

Los pasos son los siguientes:


2. Seleccionamos el vehículo. Consejo podemo ir escribiendo la marca, modelo o matrícula

e irán apareciendo sugerencias en el campo. Al seleccionar el vehículo se rellenará el

campo cliente automáticamente.

3. Rellenar el resto de campos que veamos necesarios: Título, Fecha de Entrega,

Descripción, añadir servicios o materiales en el presupuesto.

Paso a paso:


2. Seleccionamos el vehículo. Consejo podemo ir escribiendo la marca, modelo o

matrícula e irán apareciendo sugerencias en el campo. Al seleccionar el vehículo se

rellenará el campo cliente automáticamente.

3. Rellenar el resto de campos que veamos necesarios: Título, Fecha de Entrega,

Descripción, añadir servicios o materiales en el presupuesto.

Todo lo que podemos hacer en la Ord. de

Reparación

La Orden de Reparación es el elemento fundamental del vertical de Talleres. Con él vamos

a registrar lo que se ha realizado al vehículo de un cliente, que se le presupuesta, los

materiales utilizados

Para poder explicar con más detalle todo lo que podemos realizar en la Orden de

Reparación he separado la funcionalidad en bloques.

Empezando a contar de arriba a abajo y de izquierda a derecha tenemos los siguientes 9

bloques.

Lo primero de todo tenemos el menú principal del módulo de talleres.

1. Migas de pan Y botonera de Crear, Editar, Guardar y Descartar.

2. Botones relacionados con el presupuesto y la facturación.

3. Diagrama de Estado de la reparación.

4. Título, Imagen, Señalizador y Favorito.

5. SmartButtons Facturas, Imprimir Informes, Finalizar la OR.

6. Información Cliente, Vehículo, Responsable, Área.

7. Información con respecto a fecha de entrada y la fecha de entrega estimada, una

nube de tags y si renuncia al presupuesto inicial o si recoge las piezas

8. Descripción.

9. Funcionalidad asociada a: Presupuesto, Materiales usados, Trabajos e Información

adicional.

Migas de pan Y botonera de Crear, Editar, Guardar y

Descartar.

Las Migas de Pan es un concepto software que consiste en una traza de las ventanas que

hemos ido recorriendo. Sirve para saltar a un punto anterior directamente.

En Odoo siempre tendrémos una pareja de botones, en la vista Formulario para aplicar,

guardar o descartar la información incluida en el formulario.

Botones relacionados con el presupuesto y la facturación.

Los botones que podemos encontrar son:

● Confirmar presupuesto.

● Enviar Presupuesto por Correo.

● Cancelar, Presupuesto.

● Bloquear, Presupuesto.

● Crear Factura.

● Convertir a presupuesto. Si cancelamos el Presupuesto podemos reabrir dicho

presupuesto. Ésto supondrá un nuevo presupuesto que tendremos que confirmar,

facturar, etc.

Siguiendo la Lógica de Negocio de Odoo tenemos que no podremos crear una Factura

hasta que no confirmamos el Presupuesto.

Diagrama de Estado de la reparación.

Una Orden de Reparación tiene los siguientes posibles estados:

● En espera. El vehículo se encuentra en taller. Se ha creado la Incidencia pero aún

no ha sido atendida por ningún mecánico.

● En Proceso. El vehículo está siendo atendido por uno o varios mecánicos. La

incidencia no se ha resuelto.

● Recogida cliente. La Incidencia se ha solventado. El vehículo está listo para ser

recogido por el cliente.

Podemos visualizar y modificar el estado de la OR haciendo clic en el propio estado.

Título, Imagen, Señalizador y Favorito.

En este bloque tenemos para rellenar:

● Un título descriptivo de la Incidencia.

● La imagen se autogenera al seleccionar el vehículo. Si no se tuvieramos una imagen

del vehículo se seleccionaría la Marca del vehículo.

● Señalizador de estado. Podemos indicar si la incidencia está bloqueada, en rojo. Ej

falta por llegar una pieza. O si está lista para revisión, en verde. Ej: Un encargado de

comprobar que está todo bien antes de llamar al cliente.

● Favoritos. Podemos destacar la OR, indicando como favorita dicha OR.

Estos cambios se reflejarán en la vista Kanban.

SmartButtons Facturas, Imprimir Informes, Finalizar la OR.

Podemos realizar uno, o varios, pedidos de compra a un proveedor para las piezas no

disponibles. Para ello, pulsando en compras, nos sale la lista de pedido de compra en

relación con la Orden de Reparación, en la que nos encontrábamos.

Creando un nuevo pedido de compra entramos en el Circuito de Compra diseñado por

Odoo.

Una vez creada la Factura nos aparecerá un SmartButton indicando el número de facturas

asociadas a la OR y cuando hagamos click nos dirigirá a la factura en el caso de tener una

única o una vista kanban con las facturas.

Podemos previsualizar o imprimir en PDF los informes de Hoja de Admisión y Presupuesto.

Podemos previsualizar o imprimir en PDF el informe de Factura desde la factura asociada a

la OR.

Podemos finalizar la OR con el botón Activo.

Información Cliente, Vehículo, Responsable, Área.

En este punto tenemos que indicar el cliente, vehículo y área de trabajo. El responsable es

un dato opcional.

El área de trabajo se autorellena al crear una OR desde un área concreta.

Al seleccionar el campo vehículo, nos mostrará una lista de los vehículos registrados.

Podemos seleccionarlo o escribir por marca, modelo o matrícula.

Al seleccionar el vehículo se rellenará automáticamente el cliente. Tambíen podemos crear

un vehículo, como tenemos explicado en el punto Registrar Ord. Reparación (Nuevo

cliente).

Si seleccionamos primero por el cliente, nos mostrará una lista de los clientes registrados.

Al seleccionar un cliente, si éste solo tiene un vehículo se rellenará el campo cliente

automáticamente. En el caso de que cliente tenga varios vehículos, el campo vehículo

mostrará una lista filtrada de los vehículos, del cliente, disponibles.

Fecha de entrada, de entrega estimada,Tags…

En este apartado tenemos la siguiente información:

● Fecha de Entrada. Se autocompleta al guardar por primera vez la OR.

● Fecha de Entrega. Es la fecha prevista o límite pactada con el cliente.

● Etiquetas. Nube de tags para describir el carácter de la OR.

● Renuncia resupuesto. El cliente renuncia a un presupuesto previo.

● Recoge piezas. El cliente recoge las piezas defectuosas sustituidas.

Estos cambios se reflejarán en la vista Kanban de las OR.

Descripción.

En este apartado podemos dejar constancia del análisis inicial del cliente o la problemática

de la propia Incidencia.

Presupuesto, Materiales, Trabajos y Otra Información

Este punto es el más complejo e importante, está compuesto por cuatro apartados que

explicaremos uno por uno.

● Presupuesto. Los productos y servicios que vamos a facturar al cliente.

● Materiales. Los materiales que vamos a necesitar durante los trabajos.

● Trabajos. Historial de los trabajos realizados para resolver la Incidencia.

● Otra Información. Información asociada al Presupuesto.

Presupuesto

Es un listado de líneas de pedido, las cuales pueden ser: Servicios, consumibles o

productos almacenables.

Al añadir un elemento podemos buscar un producto concreto o crearlo sobre la marcha. Al

escribir el producto y cambiar a descripción se rellenará el resto de campos con valores por

defecto.

Recalcar que los productos de esta pestaña no se consumen, “no se gastan”. Para

consumir dicho producto iremos al apartado Materiales.

Materiales

La pestaña materiales. En ella se va a listar todos los materiales (y productos) utilizados en

la OR. Cada vez que añadimos un producto en el apartado de presupuesto, se añadirá

automáticamente una línea de material. Además podemos añadir materiales que no se le

van a presupuestar al cliente pero sí queremos llevar un seguimiento de Stock.

Para indicar que hemos gastado este material tenemos que pulsar en de esta forma

consumiremos el material (y el producto).

Aclaración: Un producto que a su vez está en la lista de materiales representa el mismo

artículo y sólo se consume una única vez.

También, de carácter opcional, podemos añadir al presupuesto una línea de material que en

un principio no se quería presupuestar al cliente. Para ello tenemos que pulsar en . De

esta forma se añadirá en las líneas de presupuesto. También será necesario indicar que

queremos consumir el artículo.

Trabajos

La pestaña trabajos. En este apartado podemos ir registrando los trabajos que vamos

realizando al vehículo en relación con la OR.

Para ello sólo tenemos que añadir un nuevo trabajo, describir la operación, indicar qué

operario y el tiempo tardado, la fecha se completa automáticamente.

También podemos estimar un tiempo determinado y ver, con porcentajes cómo vamos

consumiendo dicho tiempo.

Otra Información

Pestaña Otra Información. Es información asociada al presupuesto. Se completa la

información automáticamente al guardar la Orden de reparación.

Entre otros tenemos el presupuesto asociado y el estado de dicho presupuesto.

Historial de Cambios.

Odoo proporciona un sistema para llevar los cambios en una OR concreta.

También proporciona la posibilidad de Enviar mensaje, Poner una nota o Planificar una

actividad.

diseño de software de talleres con odoo · diseño de software de talleres con odoo, trabajo fin...

Documents