Upload
others
View
13
Download
0
Embed Size (px)
Citation preview
Eduardo Basalo Peña
Ana Romero Ibáñez
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
Aplicación Web CRM (Customer Relationship Management) sobre la plataforma Odoo
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: [email protected]
Aplicación Web CRM (Customer Relationship Management) sobre laplataforma Odoo, trabajo fin de grado
de Eduardo Basalo Peña, dirigido por Ana Romero Ibáñez (publicado por la Universidad deLa 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 los
titulares del copyright.
Facultad de Ciencias, Estudios Agroalimentarios e Informática
TRABAJO FIN DE GRADO
Grado en Ingeniería Informática
Aplicación Web CRM ('Customer Relationship Management') sobre la plataforma Odoo
Alumno:
Eduardo Basalo Peña
Tutores:
Ana Romero Ibáñez
Logroño, julio, 2015
Página 2 de 129
Página 3 de 129
Índice
Índice ....................................................................................................................................................... 3
Resumen .................................................................................................................................................. 5
Abstract .................................................................................................................................................... 5
1. Introducción ......................................................................................................................................... 6
1.1. Contexto ........................................................................................................................................ 6
1.2. Definiciones iniciales básicas .......................................................................................................... 6
1.3. Motivación del TFG ........................................................................................................................ 7
2. Documento de objetivos del proyecto (DOP) ........................................................................................ 8
2.1. Objetivos ....................................................................................................................................... 8
2.2. Antecedentes ................................................................................................................................. 8
2.3. Entregables .................................................................................................................................... 8
2.4. Personal implicado ......................................................................................................................... 9
2.5. Metodología de desarrollo de software ......................................................................................... 9
2.6. Estimación de riesgos ..................................................................................................................... 9
2.7. Estructura del Desglose del Trabajo (EDT) .................................................................................... 10
2.8. Planificación temporal ................................................................................................................. 12
3. Análisis ............................................................................................................................................... 14
3.1. Roles ............................................................................................................................................ 14
3.2. Especificación de requisitos ......................................................................................................... 14
3.3. Principales diagramas de casos de uso ......................................................................................... 17
3.4. Diagramas de actividades............................................................................................................. 24
4. Diseño de la aplicación ....................................................................................................................... 26
4.1. Arquitectura de Odoo y su framework ......................................................................................... 26
4.2. Arquitectura de mi módulo CRM .................................................................................................. 28
4.3. Diagrama de clases ...................................................................................................................... 28
4.4. Diagrama de base de datos .......................................................................................................... 33
4.5. Prototipos de la aplicación ........................................................................................................... 34
5. Construcción de la aplicación .............................................................................................................. 34
5.1 Funcionamiento interno de Odoo ................................................................................................. 34
5.2. Herramientas, tecnologías y lenguajes usados ............................................................................. 35
5.3. Estructura de directorios del módulo CRM ................................................................................... 35
5.4. Creación y normalización de la base de datos .............................................................................. 37
5.5. Proceso de implementación del módulo ...................................................................................... 38
5.6. Cargar datos en la BD ................................................................................................................... 54
5.7. Evaluación de requisitos de la aplicación cumplidos e incumplidos .............................................. 55
6. Pruebas .............................................................................................................................................. 55
Página 4 de 129
7. Conclusiones....................................................................................................................................... 58
8. Bibliografía ......................................................................................................................................... 59
ANEXOS .................................................................................................................................................. 60
Anexo I: Actas de las reuniones .............................................................................................................. 61
Anexo II. Descripción Estructura de Desglose del Trabajo (EDT) .............................................................. 75
Anexo III. Diagrama de Gantt .................................................................................................................. 80
Anexo IV: Diagramas de casos de uso completos .................................................................................... 81
Anexo V. Diagrama de bases de datos .................................................................................................... 86
Anexo VI. Glosario ................................................................................................................................ 102
Anexo VII. Manual de instalación de Odoo ........................................................................................... 104
Anexo VIII. Manual de instalación del CRM ........................................................................................... 108
Anexo IX. Manual de uso del CRM ........................................................................................................ 109
Página 5 de 129
Resumen
Este Trabajo Fin de Grado (en adelante TFG) tiene como fin el desarrollo de una aplicación web que
contenga las funcionalidades básicas de un software CRM ('Customer Relationship Management' – Gestor
de la Relación con Clientes), pero que funcione como un módulo dentro de la plataforma Odoo, el cual
consiste en un software online ERP ('Enterprise Resource Planning' – Sistema de Planificación de Recursos
Empresariales) que funciona en cualquier navegador web.
Como paso previo será necesario realizar un estudio sobre cómo programar este módulo CRM para que
funcione sobre la plataforma Odoo, con las herramientas que ésta proporciona a los programadores.
El CRM a desarrollar será elaborado para la empresa SDI Soluciones Informáticas (en adelante SDI), y el
objetivo es que permita la gestión de la relación que ésta mantiene con sus clientes, con una aplicación
sencilla de manejar y que sustituya a los medios y programas software que vienen usando hasta ahora
para esta misión.
Abstract
The goal of this Degree Final Project consists of a web application which allows to accomplish the tasks in
a CRM (Customer Relationship Management) software.
This web app will have to work like a module into a web online ERP (Enterprise Resource Planning) named
Odoo.
As a preliminary step, a study on the necessary technological tools for programming on Odoo will be
necessary.
This CRM software will be developed for the company 'SDI Soluciones Informáticas', and the main
objective is that it allows to manage the relationships with its clients every day, by using a plain application
easy to use and replacing the software tools utilized until now to carry out this task.
Página 6 de 129
1. Introducción
1.1. Contexto
-- Modificación tema TFG --
Inicialmente, la aplicación a construir iba a ser realizada como una aplicación web independiente
desarrollada bajo las tecnologías que el alumno considerara necesarias, y sin necesidad de formar parte
de otra aplicación padre, en este caso Odoo.
En cambio, justo antes de comenzar con la planificación y desarrollo del TFG surgió la posibilidad por parte
de SDI (empresa que encarga este Proyecto) de desarrollar la aplicación bajo la plataforma Odoo.
-- Aclaraciones iniciales--
A largo de este viaje para realizar este TFG iré desarrollando una aplicación web que cumplirá las
funcionalidades más básicas que permite realizar un software CRM, es decir, una aplicación informática
que permite gestionar las principales tareas que son llevadas a cabo para la gestión de los clientes de una
empresa.
Lo peculiar de esta aplicación es que no va a funcionar por sí misma directamente en un navegador web,
sino que lo hará dentro de la plataforma Odoo, un ERP que funciona bajo cualquier navegador de forma
online, y que permite gestionar todos los procesos de negocio presentes en cualquier empresa de
cualquier sector.
-- Cliente --
Dicho módulo CRM es solicitado por la empresa SDI Soluciones Informáticas, para la cual será
desarrollado, personalizado y entregado.
SDI Soluciones Informáticas es una empresa ubicada en La Rioja que lleva veinticinco años ofreciendo
servicios informáticos a las empresas. Entre ellos, sus principales productos se basan en software de tipo
ERP adaptado a cada sector empresarial concreto (agricultura, calzado, etc), y servicios de soporte y
mantenimiento para sus clientes para dicho software.
No sólo se encarga de desarrollar software propio adaptado a cada sector empresarial, sino que también
adquieren licencias de otras aplicaciones relacionadas con el software ERP, de las que también ofrecen
servicios de soporte y mantenimiento a sus clientes.
Por otra parte, ofrecen tipos de servicios software diferentes centrados en la movilidad, como Mobility
Pen, aplicaciones para móviles, tabletas y PDA, páginas web, etc.
1.2. Definiciones iniciales básicas
¿Qué es un CRM?
CRM ('Customer Relationship Management' – Gestión de la relación con clientes) no es sólo un software
que ayuda a la gestión de clientes, CRM es la sigla que se utiliza para definir una estrategia de negocio
enfocada al cliente, en la que el objetivo es reunir la mayor cantidad posible de información sobre los
clientes para generar relaciones a largo plazo y aumentar así su grado de satisfacción.
Todo esto es posible gracias a sistemas software que permitan gestionar de forma masiva y automatizada
la información de los clientes y las operaciones y tareas comerciales relacionadas con ellos.
Página 7 de 129
Un sistema CRM informático, es aquel que da apoyo a la gestión automatizada de las relaciones con los
clientes, a la venta y al marketing.
Aunque un CRM puede entenderse como una aplicación informática externa a un software ERP (existen
empresas funcionando con CRM y sin un software de gestión integral ERP), ésta tiene todo su sentido si
se encuentra integrada con un ERP que gestione las labores de la empresa, y ponga a disposición los datos
de los clientes a otro tipo de módulos de software usados en otras áreas de la compañía, como
contabilidad, facturación, etc.
¿Qué es Odoo?
Es un completo ERP (sistema de planificación de recursos empresariales) producido por la empresa belga
Odoo S.A, publicado bajo licencia de código abierto, y que funciona completamente online desde
cualquier navegador web.
En realidad, se podría considerar a Odoo como un conjunto de aplicaciones o módulos completamente
integrados que permiten escalar la aplicación e ir construyendo una solución a medida de las necesidades
del negocio.
Odoo es un ERP con estructura modular. ¿Qué quiere decir esto?.
Odoo es una plataforma formada por varias aplicaciones, donde cada una de ellas representa un módulo.
La nomenclatura aplicación o módulo significa lo mismo, solamente que Odoo usa la nomenclatura de
módulo en vez de aplicación. Un módulo puede ser cualquier aplicación, por pequeña que sea, que aporte
una nueva funcionalidad dentro de Odoo.
Por ejemplo, el CRM realizado para este TFG es un módulo que forma parte de Odoo.
1.3. Motivación del TFG
– Motivación para SDI –
Hasta este momento, SDI utilizaba otro software CRM llamado VTiger.
El problema es que dicho software no cumple sus expectativas en cuanto a funcionalidades y rendimiento
ofrecido.
Por otra parte, SDI planea en el futuro integrar todos los procesos de su empresa dentro de la plataforma
Odoo fabricando aplicaciones o módulos a medida para cada función: un módulo para facturación, otro
para ventas, etc.
De esta manera, necesita que el CRM también sea incluido dentro de Odoo como otro módulo más, de
forma que pueda interactuar con el resto de módulos comentados anteriormente.
– Mi motivación –
Sin duda, la única motivación que me llevó a elegir este TFG fue una posible oferta laboral en SDI para un
puesto de trabajo relacionado con el desarrollo sobre Odoo.
Aunque el desarrollo de aplicaciones web me gusta, hubiera preferido hacer una aplicación web
independiente y no basándome en un framework de programación como el ofrecido por Odoo, que limita
demasiado el ámbito de aprendizaje, ya que este framework no vale para nada si salimos del entorno
Odoo. Sólo se usa para realizar aplicaciones o módulos dentro del ERP Odoo.
Página 8 de 129
2. Documento de objetivos del proyecto (DOP)
2.1. Objetivos
El objetivo de este TFG se basa en desarrollar una aplicación web de tipo CRM en forma de módulo para
la plataforma Odoo, y que sólo funcionará dentro de ella.
Básicamente, la aplicación permitirá registrar a los empleados de SDI del departamento comercial y
marketing las principales tareas que realizan sobre sus clientes durante el día a día, de una forma
centralizada y con cualquier navegador, prescindiendo de cualquier herramienta externa si así lo desean.
Las tareas tienen que ver con el registro de empresas, oportunidades de venta, productos, presupuestos,
tareas a realizar por los comerciales y empleados de marketing (demos, visitas, reuniones y llamadas a
clientes) y campañas de marketing.
Respetando las tareas anteriormente nombradas, SDI me ofrece total libertad para añadir al CRM las
funcionalidades que crea conveniente e intentar mejorar las que demanda, ya que éste no será utilizable
por el cliente, sino que solamente servirá para mostrar algunas de las posibilidades que ofrece Odoo para
la programación de módulos dentro de esta plataforma ERP.
2.2. Antecedentes
Hasta ahora, el proceso de gestión de clientes en SDI es el siguiente:
SDI usa un CRM de código abierto llamado VTiger que funciona en cualquier navegador, pero a sus empleados no le gusta su manejo ni sus funcionalidades. Al final, sólo lo acaba usando una persona que se encarga de introducir todos los datos que le dan los comerciales.
Los comerciales en SDI no usan VTiger. Gestionan a sus clientes con otros medios:
o Libreta o cuaderno de papel.
o Google Calendar para crear citas, reuniones y tareas para sus clientes y empresas.
o Plataforma de correo electrónico para estar en contacto con éstos y pasar la información recolectada a la administradora de VTiger en SDI.
o Cualquier otro recurso software que consideren útil.
Por tanto, podemos extraer dos conclusiones:
Aunque disponen de un software CRM online y ejecutable desde un navegador web, sólo una única persona lo usa realmente.
Hay una gran disparidad en lo que respecta a herramientas usadas, con lo que la gestión, recolección y registro de información de empresas y clientes está desorganizada y descentralizada.
2.3. Entregables
Memoria del TFG.
Manual para instalar Odoo, así como el módulo CRM dentro de Odoo.
Manual de usuario.
Código fuente de la aplicación.
Todos los ficheros necesarios para el funcionamiento del CRM.
Aplicación final: módulo CRM sobre Odoo.
Cabe destacar que la aplicación final no funcionará por sí sola, sino que necesitará de la
instalación previa de la plataforma Odoo, que se detallará en uno de los Anexos.
Página 9 de 129
2.4. Personal implicado
Tutora del TFG: Ana Romero Ibáñez
Cliente: SDI Soluciones Informáticas
Proyectante o persona que realiza este TFG: Eduardo Basalo Peña
2.5. Metodología de desarrollo de software
Al comienzo del TFG me planteé varias alternativas de metodologías de desarrollo de software: la
metodología iterativa e incremental, en espiral, en cascada o algún tipo de metodología ágil.
Tras valorar estas diferentes metodologías, pude comprobar que, excepto la metodología en cascada,
todas las demás me exigían ir desarrollando prototipos funcionales de la aplicación cada cierto intervalo
de tiempo. En mi caso, esto era una tarea imposible dado mi nulo nivel de conocimiento inicial en todo lo
concerniente a programación de aplicaciones en Odoo, así como la escasa documentación y ayuda
encontrada.
Por ello, la mejor metodología para mi caso tiene que ser la metodología de desarrollo en cascada, puesto
que me ofrece la ventaja de no tener que realizar prototipos de la aplicación y poder presentarla
terminada al cliente al final del proceso.
A pesar de los riesgos que conlleva en cuanto a la inflexibilidad de esta metodología de retroceder a una
fase anterior y de no poder reevaluar los requisitos, es mi única opción para ir ganando tiempo en lo
concerniente a toda la fase previa de estudio que voy a necesitar.
2.6. Estimación de riesgos
-- Tipos de riesgos --
A pesar de haber elegido una metodología en cascada, creo que es conveniente identificar los posibles
riesgos que pueda encontrarme durante el TFG, así como sus posibles soluciones.
1. Errores en la gestión del TFG:
Probabilidad: Alta
Momento en el que ocurre: a lo largo de todo el TFG
Plan de contingencia: consultar mis dudas a mi tutora del TFG
2. Errores en la interpretación de requisitos:
Probabilidad: Alta
Momento en el que ocurre: al comienzo del TFG durante la etapa de captura de requisitos, aunque se puede dar a lo largo de toda la fase de análisis si no se detectan a tiempo las incongruencias de los requisitos estipulados.
Plan de contingencia: consultar al comienzo del TFG todas las dudas de requisitos al cliente. Si no es posible hacerlo en este período, hacerlo antes de llegar a la fase de diseño de la aplicación.
3. Nulo conocimiento de las tecnologías informáticas necesarias:
Probabilidad: Muy Alta
Momento en el que ocurre: al comienzo del TFG
Plan de contingencia: intentar aprender lo más básico inicialmente, e ir adquiriendo más conocimientos a medida que se van haciendo pequeñas pruebas programando algún módulo en Odoo a modo de test.
Página 10 de 129
4. Escasa documentación relativa al framework:
Probabilidad: Extremadamente Alta
Momento en el que ocurre: al comiendo del TFG, aunque puede darse en la fase de implementación.
Plan de contingencia: intentar recopilar la mayor parte de ayuda posible en Internet y en el foro oficial de Odoo. Por otra parte, leer de principio a fin el libro de Daniel Reis ('Odoo Development Essentials').
5. Problemas del entorno de desarrollo:
Probabilidad: Media
Momento en el que ocurre: al comienzo del TFG.
Plan de contingencia: intentar aprender el manejo básico de comandos en la terminal de Linux en una fase temprana, y usar Ubuntu como Sistema Operativo único durante el desarrollo del TFG para ir ganando conocimientos.
6. Errores en la estimación de fechas y planificación:
Probabilidad: Muy Alta
Momento en el que ocurre: al comienzo del TFG.
Plan de contingencia: intentar reaccionar en una fase temprana antes de seguir el proceso, y saber reasignar prioridades y estimación de tiempos, algo difícil de conseguir partiendo de un nulo conocimiento de las tecnologías a emplear.
2.7. Estructura del Desglose del Trabajo (EDT)
Se adjunta en la siguiente página.
El esquema detallado del EDT donde se describe con detalle cada tarea se encuentra en el Anexo II.
Página 11 de 129
Página 12 de 129
2.8. Planificación temporal
– Duración oficial –
Según el plan de estudios de la titulación Grado en Ingeniería Informática, el TFG debe constar de un total
de 300 horas para su realización.
No obstante, esta cifra puede verse disminuida o incrementada si el intervalo de diferencia no es amplio.
– Nueva planificación –
En principio, mi intención era acabar la aplicación antes del 20 de junio de 2015 y poder depositarlo en la
convocatoria de junio de la asignatura Trabajo Fin de Grado de la titulación Grado en Ingeniería
Informática.
Debido a que la fase de formación en lo que respecta al framework de programación usado en la
plataforma Odoo ha llevado bastante más tiempo de lo previsto, y las dificultades encontradas a la hora
de programar mi módulo CRM debido a la escasa documentación, he tenido que aumentar el plazo de
entrega de la aplicación hasta el 27 de Julio de 2015.
– Planificación de las tareas del EDT –
En la siguiente tabla muestro el tiempo estimado necesario y real para la realización de cada una de las
tareas del EDT.
La tabla recoge los tiempos teniendo en cuenta la replanificación mencionada en el apartado anterior.
Tarea EDT Estimación inicial
(en horas)
Tiempo trabajo empleado (en horas)
Desviación (en horas)
1. Gestión del TFG 39,3 70,3 + 31
1.1. Seguimiento del TFG 8 11,5 + 3,5
1.1.1. Reuniones 6 8,5 + 2,5
1.1.2. Gestión de cambios 1 2 + 1
1.1.3. Control de calidad 1 1 0
1.2. Elección herramientas gestión TFG 1 1 0
1.3. Generación del DOP 2 2 0
1.4. Creación EDT 1 1,5 + 0,5
1.5. Planificación temporal inicial 1 1 0
1.6. Replanificación temporal 1 1 0
1.7. Memoria TFG 22 48 + 26
1.7.1. Estudio previo 1 2 + 1
1.7.2. Estructuración memoria 1 2 + 1
1.7.3. Redacción memoria 19 42 + 23
1.7.4. Revisión memoria 1 2 + 1
1.8. Defensa TFG 3,3 4,3 + 1
1.8.1. Creación presentación 2 3 + 1
1.8.2. Preparación defensa 1 1 0
1.8.3. Defensa ante Tribunal 0,3 0,3 0
2. Formación 91 136 + 45
Página 13 de 129
Tarea EDT Estimación inicial
(en horas)
Tiempo trabajo empleado (en horas)
Desviación (en horas)
2.1. Búsqueda documentación Odoo 5 10 + 5
2.2. Instalación Odoo 1 4 + 3
2.3. Estudio Python 15 30 + 15
2.4. Lectura preliminar documentación oficial Odoo 15 5 - 10
2.5. Lectura libro 'Odoo Development Essentials'
40 55 + 15
2.6. Relectura documentación oficial Odoo 10 25 + 15
2.7. Recopilación de documentación encontrada sobre Odoo 5 7 + 2
3. Análisis 32 35 + 3
3.1. Análisis de requisitos del cliente 5 5 0
3.2. Análisis de requisitos del proyectante 5 6 + 1
3.3. Reasignación de requisitos (priorización) 1 1 0
3.4. Diagramas UML 20 21 + 1
3.4.1. Diagramas de casos de uso 5 10 + 5
3.4.2. Diagramas de actividades 5 5 0
3.5. Revisión fase de análisis 1 2 + 1
4. Diseño 34 32 - 2
4.1. Estudio arquitectura del sistema Odoo 1 3 + 2
4.2. Arquitectura del módulo CRM 2 2 0
4.3. Diseño clases ORM 12 15 + 3
4.4. Diagramas UML 6 6 0
4.4.1. Diagramas de clases 6 6 0
4.5. Diagramas base de datos 2 2 0
4.6 Creación de prototipos de la interfaz 8 3 - 5
4.7. Revisión fase de diseño 3 1 - 2
5. Construcción 80 73,5 - 6,5
5.1 Tecnologías utilizadas 4 0,5 - 3,5
5.2. Parametrización e implementación clases ORM 10 20 + 10
5.3. Implementación lógica de modelos 35 30 - 5
5.4. Construcción acciones automatizadas 5 2 - 3
5.5. Creación estructura de menús 1 1 0
5.6. Implementación de vistas 20 15 - 5
5.7. Revisión fase construcción 5 5 0
6. Pruebas 20 20 0
6.1. Elección método de pruebas 0,5 0,5 0
6.2. Diseño pruebas 5 5 0
6.3. Ejecución pruebas 5 5 0
6.4. Corrección errores en código fuente 9,5 9,5 0
7. Manuales 3 4,5 + 1,5
7.1. Manual de instalación módulo CRM Odoo 1 1,5 + 0,5
Página 14 de 129
Tarea EDT Estimación inicial
(en horas)
Tiempo trabajo empleado (en horas)
Desviación (en horas)
7.2. Manual de usuario 2 3 + 1
TIEMPO TOTAL 299,3 371,3 + 72
Diagrama de Gantt
El diagrama de Gantt con la distribución temporal de las tareas del anterior EDT aparece en el Anexo III.
3. Análisis
Esta sección tiene como objetivo analizar y documentar todos los requisitos funcionales y no funcionales
requeridos por SDI y aquellos ideados por el proyectante, obteniendo la especificación formal de
requisitos.
Así mismo, esta sección contendrá los diagramas de casos de uso principales, dejando el resto para el
Anexo IV.
Además, incluirá los diagramas de actividades en aquellos casos de uso que considere necesario.
3.1. Roles
La aplicación sólo distinguirá el rol Administrador que tendrá acceso a todas las funcionalidades de ésta.
3.2. Especificación de requisitos
Esta sección recoge tanto los requisitos funcionales como no funcionales demandados por SDI, así como
los ideados por el alumno o responsable de este TFG.
Requisitos funcionales
Descripción requisito funcional Propuesto por
Registro de información de empresas, tanto clientes como no clientes SDI
Registro de las tareas realizadas por un comercial: elaboración de presupuestos y programación de llamadas, visitas, demos y reuniones (citas).
SDI
Asignación de tareas para sí mismo y/o para otros usuarios SDI
Registrar el estado en el que se encuentra cada tarea: realizada, planeada, etc SDI
Conocer a qué cliente o empresa está asociada cada tarea SDI
Registro histórico de tareas realizadas sobre una empresa o cliente SDI
Ver presupuestos pasados a una empresa SDI
Sistema de alertas/avisos: cuando se crea una tarea enviar una aviso a un comercial, bien sea dentro de la aplicación o por email
SDI
Interfaz gráfica en modo calendario para registrar tareas SDI
Control de permisos en el calendario para que cada usuario sólo pueda ver determinadas tareas registradas
SDI
Registro de campañas de marketing SDI
Histórico de campañas de marketing realizadas SDI
Ver número de veces que se ha contactado con una empresa SDI
Página 15 de 129
Descripción requisito funcional Propuesto por
A partir de una llamada realizada a una empresa, tener la posibilidad de:
Poder completar o actualizar información de la empresa desde la misma vista de la interfaz gráfica desde donde se registra la llamada.
Poder asociar una tarea a un comercial desde la misma vista de la interfaz gráfica desde donde se registra la llamada.
SDI
Posibilidad de filtrar llamadas: hechas o por realizar SDI
Envío de emails de forma masiva SDI
Registro de oportunidades de venta SDI
Categorización de oportunidades según interés de la empresa SDI
Registrar el estado y fase en el que se encuentra cada oportunidad: ganada, perdida, etc SDI
Obtener oportunidades registradas para una empresa SDI
Eliminador de empresas registradas duplicadas SDI
Filtros sobre empresas. Obtener un listado de empresas y clientes según diferentes filtros SDI
Interfaz gráfica adaptable a móviles SDI
Logger dentro del CRM que permita registrar operaciones hechas sobre los datos Alumno
Respecto a todo lo relacionado con empresas:
Registro de diferentes sedes u oficinas en lugares diferentes para una misma empresa, tipos de empresas y zonas empresariales.
Acceder a las campañas de marketing, presupuestos, oportunidades, citas y llamadas asociadas a una empresa desde su formulario.
Ver y crear contactos desde el formulario de una empresa.
Posibilidad de asignar comerciales o un grupo de comerciales responsables de la empresa desde el formulario de ésta.
Ver productos software adquiridos por una empresa desde su formulario.
Poder aplicar diferentes filtros predefinidos de búsqueda de empresas.
Eliminar empresas duplicadas.
Posibilidad de fusionar varias empresas en una.
Alumno
Gestor de contactos de empresa:
Poder crear, ver, editar y borrar contactos para una empresa.
Posibilidad de asignar comerciales o un grupo de comerciales responsables para un contacto de empresa.
Poder aplicar diferentes filtros predefinidos de búsqueda de contactos.
Alumno
Gestor de oportunidades de venta:
Poder crear, editar, ver y eliminar oportunidades de venta.
Creación de fases. Cada oportunidad debe pertenecer a una fase, y se puede cambiar de una a otra.
Cambiar el estado de una oportunidad.
Marcar oportunidad como ganada o perdida.
Poder asignar un origen a una oportunidad (una llamada y/o presupuesto), y poder ver la cita, la llamada y el presupuesto asociados a una oportunidad.
Poder asignar una campaña de marketing a una oportunidad.
Posibilidad de poder registrar una llamada o cita asociada desde el formulario de una oportunidad, y ver el número de citas asociadas.
Posibilidad de aplicar filtros predefinidos de búsqueda de oportunidades.
Alumno
Gestor de campañas de marketing:
Crear, ver, editar y eliminar campañas de marketing.
Poder cambiar de estado a una campaña: activa, inactiva, etc.
Poder asociar a una campaña los productos software que se quiere promocionar en ella.
Desde el formulario de una campaña, poder ver las oportunidades de venta, llamadas, citas y presupuestos asociados a dicha campaña.
Poder enviar un email desde el formulario de una campaña.
Alumno
Respecto a todo lo relacionado con citas con empresas: Alumno
Página 16 de 129
Descripción requisito funcional Propuesto por
Posibilidad de asociar una campaña de marketing a la cita, y los productos que en ella se quiere promocionar o enseñar.
Poder convertir una cita a oportunidad: se debe crear una oportunidad para cada empresa asistente a la cita.
Ver oportunidades asociadas a una cita desde su formulario.
Poder enviar email a los asistentes a una cita desde su formulario.
Posibilidad de aplicar filtros predefinidos de búsqueda de citas.
Respecto a todo lo relacionado con llamadas:
Programar llamadas de forma masiva: poder seleccionar una o varias empresas y registrar una llamada para cada una de ellas en una fecha determinada, con un intervalo de tiempo de separación entre cada llamada.
Programar llamada rápida: posibilidad de crear una llamada rápida a partir de otra llamada con sus mismos datos (excepto la fecha).
Ver la campaña de marketing de origen de la llamada (desde el formulario de empresa).
Poder registrar productos promocionados en una llamada.
Posibilidad de asignar el contacto de la empresa a la que se llama.
Cambiar el estado de una llamada: cancelada, realizada, etc.
Tener disponible una vista en forma de calendario para ver y filtrar llamadas según su responsable.
Convertir una llamada a una oportunidad de venta, y ver la oportunidad asociada desde el formulario de la llamada.
Posibilidad de aplicar filtros predefinidos de búsqueda de llamadas
Alumno
Gestor de presupuestos:
Poder crear, ver, editar y eliminar presupuestos asociados a una empresa.
Poder crear, ver, editar y eliminar líneas a un presupuesto. Cada línea tiene un producto presupuestado.
Posibilidad de cambiar el estado a un presupuesto: aceptado, rechazado, etc.
Ver el importe total de un presupuesto, así como el de todos los presupuestos registrados.
Convertir un presupuesto a una oportunidad de venta, y ver su oportunidad asociada desde su formulario.
Desde el formulario de un presupuesto, ver el número de veces que el presupuesto se ha rechazado.
Crear fichero PDF que contenga la información principal del presupuesto.
Poder enviar un email desde el formulario de un presupuesto.
Alumno
Gestor de comerciales (trabajadores del departamento comercial):
Posibilidad de crear, ver, editar y eliminar comerciales.
Poder acceder o ver las oportunidades, llamadas, citas y presupuestos asociados al comercial.
Alumno
Gestor de productos:
Poder ver, crear, editar y eliminar productos de diferentes tipos: software, servicio de mantenimiento de software y servicio de soporte de software.
Posibilidad de poder crear, ver, editar y eliminar diferentes tipos de subscripciones: subscripciones a producto software, a un servicio de mantenimiento o a un servicio de soporte. Una subscripción indica que el producto se adquiere con una licencia temporal.
Registrar el precio e impuesto del producto, así como el cálculo automático del precio total con impuestos.
Asignar varios usuarios o un grupo de usuarios responsables del servicio de mantenimiento o soporte.
Poder cambiar el estado de un producto: disponible, descatalogado, etc.
Alumno
Creación de acciones automatizadas para realizar los siguientes fines:
Cuando una oportunidad pase a tener el estado llamado 'frio' o pase a estar en una fase cuya probabilidad sea 0%, se cambiará el estado del presupuesto asociado a esta oportunidad a ‘rechazado’.
Al asociar a una oportunidad un presupuesto, se deberá registrar también que este presupuesto está asociado a esta oportunidad.
Al eliminar en una oportunidad su presupuesto asociado, se deberá eliminar también la
Alumno
Página 17 de 129
Descripción requisito funcional Propuesto por
asociación de este presupuesto con esta oportunidad.
Si una oportunidad pasa a estar en una fase con probabilidad de 100%, el estado de su presupuesto asociado pasará a ser 'aceptado'.
Al asociar a una oportunidad una llamada, se deberá registrar también que esta llamada está asociada a esta oportunidad.
Al borrar la llamada asociada a una oportunidad, se deberá eliminar la oportunidad que tiene asociada esta llamada.
Creación de restricciones o validaciones de datos adecuadas en cada formulario de la aplicación donde se permita introducir datos.
Alumno
Pequeño sistema de mensajería integrado dentro de la aplicación. Alumno
Requisitos no funcionales
Respecto a los requisitos funcionales no se podría decir que el cliente exigiera formalmente ninguno, tan
solo nombró que le gustaría que el CRM a desarrollar funcionara más rápidamente y que estuviera más
adaptado a él que el que vienen usando hasta ahora: VTiger.
3.3. Principales diagramas de casos de uso
A continuación mostraré los diagramas de casos de uso correspondientes a funcionalidades de la
aplicación que me gustaría destacar, o a aquellas que tienen un nivel de complejidad mayor en su
ejecución.
Todos aquellos diagramas de casos de uso que considere más simples o de menor importancia se verán
relegados a formar parte del Anexo IV.
A continuación presentaré los casos de uso más destacados relacionados con las acciones que se pueden
realizar sobre una empresa en la aplicación.
Ahora procederé a elaborar una tabla de especificación de caso de uso para cada uno de los casos de usos
más relevantes del anterior diagrama.
Caso de uso Fusionar empresas
Actores Administrador
Precondiciones - El usuario se identifica y autentica.
- El usuario debe elegir una serie de empresas.
Postcondiciones A la empresa elegida como empresa destino se le asigna la información de todas las demás empresas seleccionadas.
Página 18 de 129
Información se refiere a cualquier campo que se pueda introducir en el formulario de creación de empresa, y a las campañas de marketing, presupuestos, oportunidades, reuniones, demos, visitas y llamadas asociadas a una empresa.
Flujo básico 1. El usuario selecciona la lista de empresas a fusionar
2. El sistema presenta un asistente.
3. El usuario elige la empresa de destino a la que irán a parar los datos de las demás empresas.
4. El sistema hace que la información de las demás empresas pase a formar parte de la empresa de destino (incluido sus contactos, oportunidades, presupuestos, llamadas, reuniones, visitas y demos). En aquel campo de empresa donde sólo se pueda especificar un solo valor, la empresa de destino recibirá en ese campo el valor de la primera empresa seleccionada, siempre que la empresa de destino no tenga ya un valor previo propio en ese campo.
Por ejemplo, una empresa puede tener un campo email. La empresa A no tiene ningún valor en ese campo. Dicha empresa se fusiona con la empresa B y C. Ambas tienen un email. Si la empresa B ocupa el primer lugar en la selección, la empresa A adquirirá el email de la empresa B, no de la C. En aquel campo de empresa donde ésta puede almacenar varios valores (por ejemplo, una empresa puede tener varias oportunidades), la empresa de destino conservará sus valores y añadirá los valores de las demás empresas en ese campo.
Por ejemplo, si la empresa A tiene 2 oportunidades, y se asocia con la empresa B y C que tienen 1 oportunidad cada una, la empresa de destino A tendrá después de la fusión 4 oportunidades asociadas.
5. Las empresas que no son la empresa elegida como destino anteriormente, son borradas de la base de datos.
Flujo alternativo 2a. El usuario puede cancelar la fusión de empresas.
2b. El usuario puede reelegir las empresas a fusionar.
Caso de uso Eliminar empresas duplicadas
Actores Administrador
Precondiciones El usuario se identifica y autentica.
Postcondiciones Si existen empresas con valores duplicados en el campo seleccionado por el usuario, se procede a ejecutar el procedimiento del anterior caso de uso de fusión de empresas, produciendo el mismo resultado.
Flujo básico 1. El usuario debe elegir la opción de menú para eliminar empresas duplicadas.
2. El sistema presenta un asistente.
3. El usuario elige los campos (email o nombre de empresa) por los que se buscará empresas duplicadas.
4. Si el usuario selecciona sólo un campo, el sistema busca empresas que tengan el mismo valor en ese campo.
Si el usuario elije los dos campos, el sistema busca empresas que tengan el mismo valor en los dos campos, no sólo en uno de ellos.
5. El usuario puede confirmar la acción de eliminación eligiendo la opción de paso por paso o eliminación automática.
5.1. En el primer caso:
5.1.1. El sistema muestra las empresas que ha encontrado duplicadas según los campos elegidos.
5.1.2 El usuario elige la empresa que quiere conservar (empresa de destino) y que adquiera los datos de las demás empresas duplicadas.
5.1.3 El sistema realiza la misma fusión de empresas explicada en el diagrama de caso de uso anterior.
5.2. En el segundo caso:
Página 19 de 129
5.2.1. El sistema realiza la eliminación sin mostrar las empresas duplicadas encontradas.
La empresa de destino que se conserva y que adquiere los datos de las empresas duplicadas es la primera empresa duplicada que ha encontrado el Sistema.
Flujo alternativo 2a. El usuario puede cancelar la fusión de empresas o reelegir las empresas a fusionar.
En el siguiente diagrama de casos de uso se podrá ver los casos de uso más relevantes relacionados con
todo lo relacionado con campañas de marketing de la aplicación.
A continuación muestro el diagrama de casos de usos relacionado con lo concerniente a citas concertadas
con clientes. Con citas me refiero a reuniones, visitas o demos realizadas para una o varias empresas.
A continuación, la explicación del caso de uso de mayor complejidad del anterior diagrama.
Caso de uso Convertir cita a oportunidad
Actores Administrador
Precondiciones El usuario debe haber creado una cita previamente y haberla seleccionado
Postcondiciones Se registrará una oportunidad para cada empresa asistente a la cita
Flujo básico 1. El usuario pincha en el botón indicado en el formulario para convertir la cita a oportunidad.
2. El sistema creará una oportunidad diferente para cada empresa asistente a la cita. Cada una de estas oportunidades tendrá registrada la información de cada empresa, y tendrá como origen la cita desde la que se realizó la conversión.
Página 20 de 129
3. El sistema registrará las oportunidades que acaba de crear a la cita para que el usuario pueda verlas desde el formulario de dicha cita.
Flujo alternativo 2a. Si la probabilidad de éxito asociada a la cita es menor del 25%, el sistema mostrará un mensaje de advertencia y la conversión no se realizará.
2b. El sistema sólo convertirá la oportunidad para aquellas empresas asistentes a la cita que no tienen asociada esta oportunidad anteriormente, es decir, que si el usuario no introduce nuevos asistentes, el proceso de conversión no se llevará a cabo.
Ahora expondré los principales casos de uso de las principales funcionalidades relacionadas con las
llamadas a empresas, y explicaré con detalle los más complicados.
Caso de uso Programar llamadas de forma masiva
Actores Administrador
Precondiciones El usuario deberá seleccionar al menos una empresa de un listado de empresas
Postcondiciones Se registrará una llamada para cada empresa seleccionada en una fecha determinada
Flujo básico 1. El usuario elije al menos una empresa de un listado de empresas.
2. El sistema mostrará un asistente donde el usuario debe seleccionar obligatoriamente las empresas paras las que quiere programar una llamada, la fecha de ésta y un intervalo de tiempo en minutos.
3. El usuario introduce estos datos.
4. El sistema creará, para cada empresa elegida, una llamada en la fecha indicada. La hora de cada llamada será calculada sumando el intervalo introducido a la hora de la llamada programada anteriormente. La hora base se toma de la fecha que ha elegido el usuario.
5. El sistema mostrará una vista con todas las llamadas registradas.
Flujo alternativo 2a. El usuario puede seleccionar una campaña de marketing, y todas las empresas asociadas a esta campaña se agregarán a la lista de empresas para las que programar llamadas.
2b. El usuario puede añadir o eliminar empresas de la lista de empresas para las que crear llamadas.
2c. Si el usuario introduce una fecha pasada o un intervalo negativo, el sistema le avisará mediante un mensaje e interrumpirá la operación.
2d. El usuario puede cancelar la operación y cerrar la ventana emergente.
Caso de uso Convertir llamada a oportunidad
Actores Administrador
Precondiciones El usuario debe haber creado una llamada previamente y haberla seleccionado
Postcondiciones Se creará una oportunidad asociada a la llamada
Página 21 de 129
Flujo básico 1. El usuario elije una llamada registrada y pincha en un botón para realizar la conversión.
2. El sistema creará una oportunidad nueva asociada a esta llamada como su origen. Ciertos datos que tenía registrados la llamada serán también registrados en la oportunidad creada.
Flujo alternativo 2a. El sistema impedirá al usuario convertir a oportunidad una llamada que fue convertida previamente y tiene una oportunidad ya asociada.
2a. El sistema sólo permitirá al usuario convertir una llamada en estado confirmado o realizado. En caso de que la llamada no se encuentre en uno de estos dos estados, el sistema deberá ocultar el botón para convertir la llamada.
A continuación mostraré los principales casos de uso relacionados con todo lo referente a la funcionalidad
de presupuestos que maneja la aplicación, y la explicación de los más complicados.
Caso de uso Crear líneas presupuesto
Actores Administrador
Precondiciones El usuario debe crear un nuevo presupuesto y elegir un producto por cada línea
Postcondiciones Se creará líneas de presupuesto
Flujo básico 1. El usuario debe crear un nuevo presupuesto.
2. El usuario podrá elegir varios productos por cada presupuesto.
Para añadir cada producto deberá crear una línea del presupuesto.
3. Para añadir líneas se abrirá una ventana emergente donde podrá elegir el tipo de producto, el producto en sí y un descuento opcional.
4. El sistema sólo permitirá añadir un producto por línea.
5. El sistema calculará el importe por línea teniendo en cuenta el producto y el descuento elegido por el usuario.
6. El sistema calculará el importe total del presupuesto sumando el importe de todas las líneas añadidas.
Flujo alternativo 4a. En caso de que el usuario elija varios productos por línea, el sistema le avisará mediante un mensaje por pantalla, e impedirá la creación de la línea.
6a. El sistema detectará que se ha añadido un mismo producto en dos líneas diferentes, e informará al usuario con un mensaje por pantalla indicándolo e impidiendo que guarde el presupuesto
Página 22 de 129
Caso de uso Convertir presupuesto a oportunidad
Actores Administrador
Precondiciones El usuario debe haber creado un nuevo presupuesto previamente y haberlo seleccionado
Postcondiciones Se creará una oportunidad asociada al presupuesto
Flujo básico 1. El usuario elije un presupuesto y hace clic en un botón para convertirlo a oportunidad.
2. El sistema creará automáticamente una oportunidad pasando los datos del presupuesto a la oportunidad, y asociando ésta al presupuesto convertido.
Flujo alternativo 2a. El sistema avisará al usuario con un mensaje e impedirá la conversión en los siguientes casos:
- Si ya existe una oportunidad asociada al presupuesto porque éste fue convertido previamente.
- Si la probabilidad de éxito asignada al presupuesto es menor del 25%.
- Si el presupuesto está en estado ‘en seguimiento’. En este caso, el usuario deberá pasar su estado a ‘aceptado’ antes de realizar la conversión.
Caso de uso Cambiar estado presupuesto
Actores Administrador
Precondiciones El usuario debe haber seleccionado un presupuesto
Postcondiciones El estado del presupuesto se ve modificado
Flujo básico 1. El usuario elige un presupuesto.
2. El usuario elige el estado al que quiere pasar el presupuesto.
3. Dependiendo del estado elegido el sistema hará varias tareas adicionales:
3.1 Si el estado es aceptado:
- El sistema comprobará si el presupuesto tiene una oportunidad asociada. Si es así, cambiará el estado de ésta a ‘inminente’ y su fase a una fase de oportunidad que tenga como probabilidad asignada el 100%.
- Además, convertirá en cliente a la empresa asignada al presupuesto, le añadirá éste a su lista de presupuestos y asociará a la lista de productos que posee la empresa los productos que figuren en el presupuesto.
3.2 SI el estado es rechazado:
- El sistema incrementará en uno el número de veces que el presupuesto ha sido rechazado.
- El sistema comprobará si el presupuesto tiene una oportunidad asociada, y en caso afirmativo modificará el estado de ésta a ‘frio’ y la pasará a una fase de oportunidad que tenga como probabilidad asignada el 0%.
3.3. Si el estado es represupuestado:
- El sistema incrementará en uno el número de veces que el presupuesto ha sido represupuestado.
4. El sistema cambiará el estado del presupuesto al elegido por el usuario.
Flujo alternativo 2a. Si el presupuesto se encuentra en estado ‘aceptado’, el usuario no podrá elegir un nuevo estado.
A continuación mostraré los casos de uso más relevantes en todo lo que concierne a oportunidades de
venta, o simplemente llamadas oportunidades, y explicaré aquellos que conlleven mayor dificultad.
Página 23 de 129
Caso de uso Marcar oportunidad como ganada o perdida
Actores Administrador
Precondiciones El usuario debe haber seleccionado una oportunidad
Postcondiciones La oportunidad cambia de fase según sea marcada como ganada o perdida
Flujo básico 1. El usuario selecciona una oportunidad y entra en la ficha de edición de la oportunidad.
2. Hace clic en un botón que le permite marcar la oportunidad como ganada, o en otro botón para marcar la oportunidad como perdida.
2.1. En el primer caso:
2.1.1. El sistema asigna a la oportunidad la primera fase de oportunidad existente que tenga una probabilidad del 100 %.
2.1.2. Si la oportunidad tenía un presupuesto asociado, el sistema asigna el estado ‘aceptado’ a dicho presupuesto.
2.2. En el segundo caso:
2.2.1. El sistema asigna a la oportunidad la primera fase de oportunidad existente que tenga una probabilidad del 0 %.
2.2.2. Si la oportunidad tenía un presupuesto asociado, el sistema asigna el estado ‘rechazado’ a dicho presupuesto.
3. El sistema cambia la probabilidad de éxito de la oportunidad, a la probabilidad que tuviera la fase que le ha sido asignada, 100 % en caso de que la oportunidad sea marcada como ganada, y 0 % en caso de que la oportunidad sea marcada como perdida.
Flujo alternativo 2.1.1.a. En caso de que el usuario quiera marcar la oportunidad como ganada, y no exista definida una fase con probabilidad del 100 %, el sistema mostrará un mensaje al usuario informándole de que debe crear previamente una fase de oportunidad con una probabilidad del 100 %.
2.1.2.a. En caso de que el usuario quiera marcar la oportunidad como perdida, y no exista definida una fase con probabilidad del 0 %, el sistema mostrará un mensaje al usuario informándole de que debe crear previamente una fase de oportunidad con una probabilidad del 0 %.
Caso de uso Modificar el origen de la oportunidad
Actores Administrador
Precondiciones El usuario debe haber seleccionado una oportunidad
Postcondiciones La oportunidad tendrá asignada una única tarea de origen, y adicionalmente un presupuesto asociado.
Flujo básico 1. El usuario selecciona una oportunidad ya registrada o crea una nueva.
Página 24 de 129
2. El usuario selecciona de que tarea proviene la oportunidad (llamada, reunión, demo, visita).
3. En caso de seleccionar como origen una llamada, el usuario puede asignar una llamada de origen para la oportunidad.
4. El usuario puede adicionalmente asignar un presupuesto asociado a la oportunidad como origen adicional.
Flujo alternativo 3a. En caso de seleccionar otro origen diferente a una llamada, el usuario no puede asignar una demo, reunión o visita a la oportunidad. Para ello tendrá que ir a la ficha de uno de estos elementos, y convertirlo a oportunidad desde allí.
3b. Si ya existe registrada otra llamada asociada con la oportunidad, el sistema elimina la asociación entre ésta y la vieja llamada, y asocia como origen la nueva llamada.
3c. Si el usuario elimina la llamada origen previamente registrada en la oportunidad y no introduce otra nueva, el sistema eliminará de dicha llamada la asociación con la oportunidad.
4a. Si el usuario borra un presupuesto guardado previamente como asociado de la oportunidad, el sistema eliminará la asociación entre éstos.
4b. Si el usuario modifica el presupuesto asociado a una oportunidad por otro nuevo presupuesto, el sistema borrará la asociación entre el viejo presupuesto asignado y la oportunidad.
3.4. Diagramas de actividades
A continuación expondré algunos diagramas de actividades en aquellos casos de usos cuyo flujo de
ejecución sea más complicado de entender.
Diagrama de actividades – Caso de uso “Eliminar empresas duplicadas”
Página 25 de 129
Diagrama de actividades – Caso de uso “Cambiar estado presupuesto”
Diagrama de actividades – Caso de uso “Marcar oportunidad como ganada o perdida”
Página 26 de 129
Diagrama de actividades -- Caso de uso “Programar llamadas de forma masiva”
4. Diseño de la aplicación
En este apartado trataré los siguientes aspectos:
Arquitectura de la plataforma Odoo
Arquitectura del módulo CRM a desarrollar
Diagramas de clases
Diagrama de base de datos
Prototipos principales de la interfaz gráfica de la aplicación
4.1. Arquitectura de Odoo y su framework
Para construir la arquitectura de mi aplicación es imprescindible conocer brevemente cómo es la
arquitectura de Odoo y cómo funciona su framework.
Tipos de módulos
Primeramente hay que distinguir entre lo que Odoo llama módulos ‘front-end’ y ‘backend’.
Los módulos ‘front-end’ es lo que comúnmente llamamos aplicaciones web, y es con lo que un usuario
interactúa desde un navegador web. Un ejemplo muy claro es una tienda web online.
Los módulos ‘backend’ también pueden ser considerados aplicaciones web porque técnicamente
funcionan de la misma manera que éstas. La diferencia es más conceptual. Un módulo ‘backend’ se podría
considerar como una aplicación web que es usada por los responsables de dicha aplicación, no por los
usuarios normales.
El CRM que estoy desarrollando pertenece a la categoría de módulos ‘backend’ en Odoo.
Tipo de arquitectura, patrones de diseño y el framework de Odoo
Odoo posee una arquitectura de tres capas: una capa para el cliente Odoo, otra capa para el servidor
Odoo y otra para la conexión y manejo de la BD.
Página 27 de 129
Además sigue el patrón de diseño ‘MVC’ (Modelo-Vista-Controlador), con lo que separa la parte que
maneja la vista de la que maneja la lógica la aplicación, usando como intermediario un controlador que
captura las peticiones del cliente y las comunica al modelo, y que entrega al cliente las respuestas
fabricadas por el modelo.
La peculiaridad es que los módulos de Odoo de tipo ‘backend’ manejan de forma diferente este patrón.
Al implementar un módulo de este tipo, el programador no puede fabricar su controlador para recibir las
peticiones del cliente, procesarlas, comunicárselas al modelo de la aplicación, y entregar las respuestas
de éste al cliente.
En el caso de estos módulos, Odoo proporciona su propio controlador. Este controlador forma parte del
núcleo de Odoo.
El núcleo de Odoo, programado en lenguaje Python, es el que dota de toda la funcionalidad necesaria a
más bajo nivel para que todo funcione, incluidos los módulos programados para Odoo.
El framework de Odoo, que proporciona todas las herramientas necesarias para la construcción de
módulos en Odoo, también forma parte de este núcleo.
Los módulos ‘backend’ son construidos usando todas las funcionalidades que proporciona este
framework. Sin duda, una de las más importantes es el ORM que nos permite comunicarnos con la BD
¿Qué es un ORM?
ORM son las siglas en ingles de ‘Object Relational Mapping’, en español “mapeo de objetos a bases de
datos”.
ORM es una técnica de programación para convertir datos entre el lenguaje de programación orientado
a objetos utilizado y el sistema de base de datos relacional usado en el desarrollo de nuestra aplicación
sin que el programador tenga que usar SQL para manejar la BD.
El ORM de Odoo
Odoo proporciona su propio ORM que permite manejar los datos de la base de datos con una API propia.
Esta API nos dice cómo hacer las operaciones sobre la BD, así como la manera de definir las columnas de
cada tabla de la BD usando su propia sintaxis.
Para usar esta API debemos utilizar el lenguaje Python.
Modelos en Odoo y ORM
A continuación se describirán algunos conceptos técnicos del ORM de Odoo. Puede no tener sentido
describirlos en la fase de diseño, pero es necesario conocerlos de antemano para poder diseñar la
arquitectura de nuestra aplicación, así como los diagramas de clases de ésta y los diagramas de la base de
datos, ya que van a estar totalmente relacionados y ser dependientes.
Odoo maneja el término modelo, que a partir de ahora nombraré en varias ocasiones.
Un modelo no es más que una clase programada en Python que corresponderá a una tabla de la BD. Por
ejemplo:
class Company(models.Model):
_name = 'res.partner'
_inherit = ['res.partner', 'mail.thread']
_description = 'Empresa'
En el ejemplo anterior estamos definiendo una clase llamada Company que se mapeará en la BD en forma
de una tabla de nombre 'res_partner'. Vemos que el nombre de tabla corresponde al atributo '_name' de
la clase separando los puntos por guiones bajos.
Página 28 de 129
El ORM de Odoo permitirá que definamos como atributos (formalmente llamados campos en Odoo) de
esta clase las columnas que formarán parte de la tabla correspondiente a ésta, así como las relaciones
mantenidas con otros modelos, o lo que es lo mismo, la relación mantenida con otras tablas de la BD.
4.2. Arquitectura de mi módulo CRM
Como Odoo, mi aplicación también debe seguir el patrón MVC.
El problema es que Odoo no permite desarrollar la parte del controlador en mi aplicación ya que mi
módulo es de tipo 'backend', lo cual no me da la posibilidad de manejar las peticiones del cliente ni
tampoco las respuestas entregadas por el modelo de mi aplicación.
Lo que si podré separar es la parte del modelo y la parte de las vistas.
El modelo
En primera instancia, tengo que aclarar lo que supone el modelo en mi módulo CRM.
El modelo va a contener tanto la lógica de la aplicación como la lógica del tratamiento de datos de la BD.
Hay que recordar lo anteriormente explicado. Estoy trabajando con un ORM, lo que hace que no tenga
que crear una capa extra para ejecutar sentencias SQL sobre la BD y mapear tipos de datos de la BD a
objetos de mi aplicación.
Simplemente, dentro de cada modelo podré usar los métodos que la API del ORM de Odoo me ofrece
para interactuar con la BD.
El modelo de mi aplicación sigue el paradigma orientado a objetos, y estará compuesto por clases
(modelos en la jerga de Odoo) que contienen la lógica de la aplicación y el tratamiento de datos de la BD.
Las vistas
Mi aplicación contendrá otra parte adicional para el tratamiento de vistas, que estarán implementadas
en lenguaje especial de tipo XML.
Aunque en realidad existe independencia entre las vistas y el modelo, las vistas usan cierta lógica de datos
para poder crear el enlace con el modelo al que están atadas.
4.3. Diagrama de clases
Tipos de los atributos o campos de las clases
El ORM de Odoo contempla sus propios tipos de datos simples en los campos que definamos en cada
modelo: Char, Boolean, Integer, Float, Text, Selection, Html, Date, DateTime.
Antes de seguir con el resto de tipos de campos, hay que pararse a explicar el concepto de lo que Odoo
llama 'recordset'.
Formalmente un recordset es una colección de record. Un record es el equivalente a un objeto de un
modelo o clase en concreto. Por tanto, podríamos decir que un recordset es una colección de instancias
de objetos de una clase.
La peculiaridad es que Odoo añade a nuestros objetos atributos y métodos que nosotros no hemos
definido, ya que nuestros modelos los heredan de una clase que representa la clase padre para todos los
modelos que definamos.
Pensando en el concepto de base de datos y tablas, un recordset es un conjunto de filas, y un record es
una fila de la tabla.
Dicho esto, pasemos a hablar de los campos que podemos definir en nuestro modelo y que relacionan
unos modelos con otros.
Página 29 de 129
Many2one: nos permite establecer relación entre un modelo A y un campo de un modelo B. Por ejemplo, una empresa puede estar relacionada con 0 o 1 grupo de comerciales responsables, o un grupo de comerciales responsables puede estar relacionado con 0 o 1 empresa.
class Empresa():
_name = 'modelo_empresa' presupuesto = fields.Many2one('modelo_grupo_comerciales')
class GrupoComerciales():
_name = 'modelo_ grupo_comerciales'
empresa = fields.Many2one('modelo_empresa')
En este ejemplo, la relación es en ambos sentidos. Una empresa está relacionada con un grupo,
y un grupo con una empresa.
No es obligatorio crear el campo Many2one en ambos modelos.
Many2many: nos permite establecer una relación de tipo muchos a muchos entre un modelo A y un campo de otro modelo. Por ejemplo, una empresa puede estar relacionada con muchos comerciales, y un comercial puede estar relacionado con muchas empresas.
class Empresa():
_name = 'modelo_empresa' comerciales = fields.Many2many('modelo_comerciales')
class Comercial(): _name = 'modelo_comerciales'
empresa = fields.Many2one('modelo_empresa')
One2many: nos permite relacionar dos modelos A y B, de forma que si A tiene un campo de tipo One2many, el modelo A podrá estar relacionado con 0 o muchos objetos del tipo del modelo B, pero un objeto del modelo B sólo podrá estar relacionado con 0 ó 1 objeto del modelo A.
class A():
_name = 'modelo_empresa' comerciales = fields.One2many('modelo_presupuestos', 'empresa')
class B(): _name = 'modelo_presupuestos'
empresa = fields.Many2one('modelo_empresa')
Página 30 de 129
Parte 1 Diagrama de clases
El siguiente diagrama se centra en la clase 'Empresa' y en sus relaciones con las demás clases.
Página 31 de 129
Parte 2 Diagrama de clases
El diagrama anterior se centra en la clase ‘CampañaMarketing’ y todas las clases con las que se relaciona.
El siguiente diagrama se centrará en la clase 'Oportunidad' y en todas las clases con las que se relaciona.
Página 32 de 129
Parte 3 Diagrama de clases
Parte 4 Diagrama de clases
El diagrama anterior se centra en todas aquellas clases relacionadas con productos y servicios, y sus
relaciones entre ellas.
Página 33 de 129
Parte 5 Diagrama de clases
El siguiente diagrama se centra en clases que heredan de tarea (que también representan tareas de
diferentes tipos), y en todo lo relacionado a presupuestos.
4.4. Diagrama de base de datos
Por la gran cantidad de tablas y relaciones de la BD, adjunto los diagramas de base de datos en el Anexo
V de la memoria para su mejor visibilidad.
En realidad, los diagramas de clases y de base de datos son parecidos (aunque no iguales) ya que el uso
de un ORM hace que cada modelo se mapee a una tabla.
La explicación de porqué son diferentes es que, como dije antes, Odoo añade a nuestros modelos
atributos que no hemos definido nosotros. Muchos de estos atributos se relacionan con otros modelos o
clases que forman parte del núcleo de Odoo (porque son de tipo Many2one, Many2many o One2many),
lo que traducido a jerga de BD quiere decir que las tablas de nuestros modelos tendrán nuevas relaciones
con otras tablas que Odoo define por sí mismo.
Además, los campos de tipo Many2many se mapean a una tabla extra que relaciona dos tablas, una
corresponde a un modelo y otra corresponde al otro modelo con el que éste se relaciona.
Página 34 de 129
4.5. Prototipos de la aplicación
Al final de la fase de diseño de la arquitectura de mi aplicación decidí no diseñar prototipos para ésta por
dos motivos:
1) No disponía de los suficientes conocimientos técnicos en su momento, y no los iba a disponer hasta el
final del ciclo del TFG. Por este motivo, creí conveniente ir diseñándolas poco a poco, viendo por pantalla
como se iban renderizando.
Hacer prototipos no me hubiera servido de nada porque no sabía qué componentes podían incluir las
vistas, ni cómo se usaban.
2) Odoo sólo permite diseñar plenamente la vista de tipo formulario. Hacer prototipos de formularios,
cuyo aspecto iba a ser parecido entre todos ellos, me pareció una pérdida de tiempo.
5. Construcción de la aplicación
En este apartado de la memoria trataré los siguientes puntos:
Explicación del funcionamiento de Odoo desde un punto de vista técnico, ampliando los conceptos que escribí en el apartado anterior de esta memoria.
Explicar las herramientas usadas para la elaboración del módulo CRM.
Ver estructura de directorios de la aplicación donde está almacenado todo el código fuente.
Explicar el proceso de implementación de este módulo.
Aclarar el proceso para la implementación de las vistas de la interfaz gráfica.
Capturas de la interfaz gráfica de las principales vistas de la aplicación.
Dejar constancia de qué requisitos de la aplicación han sido satisfechos y cuáles no.
5.1 Funcionamiento interno de Odoo
Antes de implementar un módulo para Odoo creo que es necesario conocer cómo funciona internamente
esta plataforma.
Como se ve en la ilustración anterior, Odoo consiste en tres componentes básicos:
Un servidor con un SGBD PostgreSQL que contiene todos los datos: datos de cada modelo de cada módulo instalado, el código de las vistas, datos de configuración del propio Odoo, etc.
Un servidor que puede funcionar en local o en cualquier proveedor de hosting online. Este componente es el que contiene el núcleo de Odoo. El núcleo de Odoo está programado en Python y es lo que hace que todo funcione. Una capa de este servidor está destinada a
Página 35 de 129
comunicarse con el SGBD PostgreSQL a través del motor del ORM que Odoo incorpora. Otra capa está destinada a comunicarse con el cliente web Odoo que se ejecuta en el navegador del usuario.
El tercer componente consiste en una completa aplicación JavaScript que se ejecuta en el navegador del usuario para que el usuario pueda usar Odoo sin instalar ninguna aplicación.
El framework de Odoo
Odoo proporciona un completo framework con toda una serie de técnicas y herramientas para la
programación de un módulo dentro de esta plataforma.
Este framework nos proporciona todas las herramientas tanto como para construir la lógica de
tratamiento de datos de nuestro módulo, así como su interfaz gráfica, sin tener que preocuparnos de
tratar con el controlador de la aplicación para manejar peticiones desde el navegador del usuario.
El componente más importante es el ORM, que nos ofrece una API orientada a objetos para manejar la
BD sin usar SQL.
5.2. Herramientas, tecnologías y lenguajes usados
Éstas son las herramientas y librerías usadas para el desarrollo técnico e implementación de la aplicación:
Odoo: plataforma Odoo instalada en el servidor local proporcionado por ésta.
SGBD y PgAdmin III: PostgreSQL.
DbVisualizer: herramienta para ver gráficamente las relaciones entre diferentes tablas de una BD.
Entorno virtual de ejecución Python: virtualenv entorno virtual para tener Odoo aislado del resto del sistema usando sus propias librerías y sin compartirlas con ningún otro proyecto o desarrollo en Python que se esté realizando al mismo tiempo.
Sistema operativo: Ubuntu
IDE de programación: PyCharm
Librería Python 'validate_email' para validar emails
Git y github: para descargar los repositorios de código fuente de Odoo alojados en Github.
wkhtmltopdf: conjunto de utilidades para crear ficheros PDF.
Navegador web: Google Chrome
En tercer lugar, los lenguajes de programación o metalenguajes usados han sido los siguientes:
Python para el desarrollo de la lógica de datos de cada modelo o clase del CRM.
Lenguaje de tipo XML propio de Odoo para fabricar vistas de tipo formulario, tablas, calendario o gráficas (gráficos de barras, de sectores, etc).
Qweb, lenguaje de plantillas propio de Odoo para realizar plantillas que se transformarán a lenguaje HTML.
HTML y CSS para construir ciertos elementos de los formularios.
5.3. Estructura de directorios del módulo CRM
En este apartado mostraré cómo están estructurados físicamente los directorios de la aplicación, así como
los tipos de ficheros que contiene cada uno de ellos.
Página 36 de 129
Fichero __openerp__.py: es un fichero que debe incluir cualquier módulo de Odoo. Debe llamarse de esta manera obligatoriamente y debe estar situado en el directorio raíz. Básicamente contiene los siguientes elementos:
o Nombre del módulo.
o Descripción.
o Autor.
o Categoría donde será ubicado dentro de la plataforma Odoo.
o Si puede ser instalado por el usuario.
o De qué otros módulos depende: los módulos indicados en este campo se instalarán antes de instalar el propio módulo, si no están ya instalados en Odoo.
o Los nombres de los ficheros que contienen los datos a cargar en la BD en el momento de la instalación del módulo.
o Los nombres de los ficheros que contienen las vistas de la aplicación.
o Otros nombres de ficheros que contienen otro tipo de funcionalidad a añadir en la aplicación: acciones automatizadas, acciones ejecutadas cada cierto intervalo de tiempo, creación de informes en PDF o HTML, plantillas en lenguaje Qweb, flujos de ejecución de la vida de un objeto de un modelo, etc:
Fichero __init__.py: debe llamarse así y debe estar situado en el directorio raíz. En este fichero se debe importar con la sentencia Python 'import' todos los ficheros .py donde estén recogidas todas las clases Python que representan a los modelos de nuestro módulo.
Directorio data: este directorio contiene los ficheros que permiten precargar de datos las tablas de nuestro módulo al momento de su instalación. No es necesario que sea llamado de esta manera, sólo es una convención de organización de directorios recomendada por Odoo. Son ficheros de tipo XML que contienen una serie de elementos. Cada elemento especificará qué valor tendrá cada campo de un modelo determinado, lo que se traduce en el valor que tendrá cada columna de una fila de la tabla correspondiente a este modelo. Existen dos tipos de ficheros XML para este propósito:
o Los que contienen datos para cargar en modo demo. Son datos que se usan para mostrar una demostración del módulo con datos falsos, simplemente para poder interactuar con ellos.
o Los que contienen datos que deben formar parte de la BD de forma predeterminada desde que se instala el módulo en Odoo. Por ejemplo, registrar tipos de empresa para un modelo ‘Empresa’.
helpers: es un directorio que contiene un fichero Python con métodos de ayuda que pueden ser usados en cualquier otro fichero Python de la aplicación. Por ejemplo, contiene una función para validar un DNI. Es necesario que todo directorio que se cree tenga un fichero llamado __init__.py. Esto no es propio de Odoo, es una obligatoriedad en Python. Ficheros contenidos: helpers.py
models: contiene todas las clases Python que representan a cada modelo del módulo. Cada clase es un modelo. Debe contener obligatoriamente un fichero llamado __init__.py donde importemos con la sentencia 'import' de Python todos los ficheros Python que contiene este directorio. No es
Página 37 de 129
necesario que este directorio se llame así, sólo es una convención en Odoo. Ficheros contenidos: __init__.py, company.py, marketing.py, opportunity.py, person.py, phonecall.py, product.py, quote.py, salesperson.py, service.py, software.py, task.py, task_event.py, wizard_phonecalls.py
security: contiene los ficheros XML que se usan para establecer reglas de acceso y control a cada grupo de usuarios de la aplicación. En mi caso no contiene nada puesto que mi módulo no maneja ningún tipo de permisos. No es necesario que este directorio se llame así, sólo es una convención en Odoo.
server_and_automated_actions: No es un directorio obligatorio en Odoo. Es un directorio creado por mí para introducir los ficheros XML que contienen acciones automatizadas, es decir, acciones que se realizarán de forma automática sobre el módulo bajo ciertas condiciones y sin intervención del usuario, como por ejemplo, modificar el estado de un presupuesto asociado a una oportunidad de venta cuando se crea o actualiza cualquier tipo información de esta oportunidad, y se dan ciertas condiciones, como que la oportunidad esté en una fase llamada ‘Ganada’.
Ficheros contenidos: server_automated_actions.xml
static: contendría todos los ficheros que el servidor de Odoo enviará al navegador del usuario. Entre ellos se encuentran las imágenes, archivos JavaScript, CSS o HTML, es decir, todos aquellos ficheros estáticos. El directorio debe recibir este nombre obligatoriamente.
views: contiene todos los ficheros XML que son necesarios para crear las vistas. No es necesario que el directorio reciba este nombre.
Ficheros contenidos: company_views.xml, marketing_views.xml, opportunity_views.xml, product_views.xml, quote_report.xml, quote_views.xml, salesperson_view.xml, service_views.xml, task_event.xml, task_views.xml, wizard_phonecall_scheduler.xml.
workflows: son ficheros en XML que permiten ejecutar acciones a lo largo de la vida de un record. Se usan sobre todo cuando el usuario pincha en un botón para cambiar el estado de un record, por ejemplo, para cambiar el estado de un presupuesto de rechazado a aceptado. Cuando sucede esta transición se puede determinar qué método Python ejecutar, y qué condiciones deben darse para que se ejecute.
Explicaré esto más adelante en la memoria. Ficheros contenidos: workflow_marketing_campaing.xml, workflow_quote.xml, workflow_service.xml, workflow_software.xml, workflow_phonecall.xml, workflow_opportunity.xml, workflow_event.xml
5.4. Creación y normalización de la base de datos
Al estar usando un ORM no es necesario que nos tengamos que encargar de crear las tablas de la BD. Su
tarea es hacer el trabajo sucio por nosotros, evitando que tengamos que tratar con SQL para crear tablas
o realizar operaciones de consulta, inserción, actualización o borrado.
Además, el ORM se encarga de crear para cada modelo, en su tabla correspondiente, las claves primarias
(siempre una columna 'id' con valor autoincremental), las claves foráneas a partir de los campos
Many2one, One2many y Many2many definidos, los índices para hacer búsquedas más eficientes, las
restricciones de cada tabla indicadas en cada modelo, así como las tablas extras que se crean a partir de
los campos Many2many.
Normalización
Tan sólo puedo asegurar que la BD está en primera forma normal ya que todos los atributos de todas las
tablas son monovaluados.
Página 38 de 129
No podría hacer cumplir las restantes formas normales ya que no puedo descomponer las tablas que
forman parte de la BD de mi aplicación. Esto es debido al uso de un ORM, que crea y maneja
automáticamente la BD sin intervención del programador.
Yo creo los atributos de cada clase. Para esta clase se crea una tabla, y cada atributo es una columna. El
ORM de Odoo espera encontrar esta estructura de tablas. Si descompusiera estas tablas en otras para
alcanzar otras formas normales, el ORM se encontraría con una estructura de tablas desconocida y la
aplicación no funcionaría.
5.5. Proceso de implementación del módulo
Fase inicial
Instalación
Lo primero que hay que hacer es instalar Odoo.
Existen formas automáticas de instalarla mediante un instalador en Windows, o mediante un paquete en
Ubuntu.
Yo he trabajado desde Ubuntu, pero no he elegido la opción de instalarlo automáticamente, ya que esta
manera no permite tener actualizado Odoo, a menos que Odoo saque un paquete nuevo con otra versión.
Además, he instalado Odoo usando un entorno virtual Python usando la herramienta llamada virtualenv.
Un entorno virtual no es más que un directorio dentro del sistema operativo que posee sus propias
librerías Python instaladas y aisladas de las demás librerías Python instaladas globalmente en el sistema
operativo.
Si se elige instalar Odoo manualmente, hay que instalar previamente el SGBD PostgreSQL. En Ubuntu es
tan sencillo como ejecutar un comando en la consola de comandos.
Por otra parte, Odoo necesita que se instalen numerosas dependencias o librerías para que funcione
correctamente. La página oficial de Odoo indica cómo hacerlo, así que no creo que sea conveniente
repetirlo en esta memoria.
Ir al sitio web https://www.odoo.com/documentation/8.0/setup/install.html#setup-install-source para
más información.
Ejecución del servidor de Odoo y de su cliente web
Al ejecutar un fichero llamado odoo.py se ejecuta el servidor de Odoo en modo local, y se le puede pasar
varios parámetros. Por ejemplo, para indicar qué base de datos usar, dónde está el directorio donde está
tu módulo alojado para que Odoo pueda detectarlo, etc.
odoo.py --addons-path=addons,../mymodules –d test
En primer lugar hay que crear la BD. Podemos crearla de dos maneras:
Creándola directamente con PostgreSQL o
desde una interfaz gráfica que Odoo provee al arrancar el servidor y al que se puede acceder introduciendo la siguiente URL en el navegador: http://localhost:8069/web/database/manager
Arrancar el servidor de Odoo
Cuando ejecutamos el comando anterior, lo que está sucediendo es que se está arrancando y pasando a
ejecutar el servidor de Odoo.
En mi caso, estoy ejecutando este servidor de modo local en mi ordenador, pero se podría ejecutar dentro
de cualquier servidor web.
Arrancar el cliente de Odoo
Para arrancar el cliente Odoo en nuestro navegador, se necesita acceder a la siguiente URL cuando se
ejecuta en modo local: http://localhost:8069/
Página 39 de 129
Como se ve, el servidor opera en el puerto 8069, pero esto puede ser modificado.
Si tuviéramos instalado Odoo en un servidor web la parte 'localhost' de la URL cambiaría.
Implementación de la lógica de la aplicación
El modelo
Una vez tenemos instalado Odoo y podemos hacerlo funcionar, ya se puede empezar con el desarrollo de
la aplicación.
Lo primero que hay que aclarar es que cuando hablamos de módulo en Odoo, estamos hablando de algo
equivalente a una aplicación. Y cuando hablamos de modelo estamos hablando de una clase en Python.
Un módulo está formado por muchos ficheros. Ya los vimos anteriormente en el apartado donde mostré
la estructura de directorios. Entre estos ficheros están los modelos.
Cada modelo representa dos cosas. Una entidad en la lógica de nuestra aplicación (por ejemplo, una
Empresa), pero también representa una tabla en la BD.
Yo debo usar la API del ORM de Odoo en Python para trabajar con la BD, y el ORM se encarga de consultar
la BD, ejecutar lo que nosotros le hayamos pedido con cualquier método de la API, y devolvernos el
resultado en forma de objetos Python para poder interactuar con ellos en nuestra clase.
Cada objeto ya contiene la información extraída de la BD de cada fila y cada columna, pero la tiene
encapsulada en forma de atributos de este objeto.
Una vez hemos identificado los atributos de nuestro modelo (nuestra clase) ya podemos ir creándolos
siguiendo la sintaxis que el ORM impone.
Si queremos que nuestro modelo (clase) sea mapeado a una tabla en la BD tenemos que hacer que herede
de la clase base 'Model', que está alojada en un fichero llamado 'models'.
# -*- coding: utf-8 -*- from openerp import api, fields, models, exceptions class Company(models.Model): Previamente tenemos que importar el fichero .py 'models' que se encuentra en el paquete llamado
'openerp'.
* Un paquete es una nomenclatura de Python, y no es más que un directorio donde se encuentra alojados
uno o varios ficheros .py.
Con esto, la clase Company será mapeada a una tabla, es decir, se creará una tabla en la BD que contenga
todos los atributos definidos en esta clase.
Es importante destacar que en ninguna de las clases que creemos se verá ningún tipo de constructor que
permita construir objetos. Esto no es necesario ya que es una tarea que el ORM hace por nosotros.
Es muy importante definir un nombre único para nuestro modelo de entre todos los modelos de nuestro
módulo.
class Company(models.Model): _name = 'res.partner' Siempre que quiera referirme a mi modelo lo haré mediante el valor definido en '_name'.
Por convención, cada modelo que creemos puede ir en un fichero .py diferente, o podemos implementar
modelos relacionados en el mismo fichero.
Yo, por ejemplo, tengo un fichero llamado 'company.py' donde tengo creados varios modelos
relacionados con una empresa.
Identificando relaciones de herencia
El framework de Odoo permite definir relaciones de herencia entre modelos al igual que lo haríamos en
una aplicación orientada a objetos normal.
Odoo ofrece dos tipos de herencias de clases:
Página 40 de 129
Herencia clásica: un modelo hereda de otro todos sus campos y métodos, pero el ORM crea un nuevo modelo, es decir, crea una nueva tabla en la BD con los mismos campos.
Herencia por extensión: un modelo hereda todos los atributos y métodos de otro, con lo que podemos reaprovechar todo su código. La diferencia es que el ORM no crea una nueva tabla para el modelo que hereda.
1) Respecto al tratamiento de productos en el módulo, diferencio entre dos tipos de productos:
- Producto software.
- Servicios.
Todos ellos tienen características y comportamiento común. Es por ello, que Odoo ofrece la posibilidad
de crear modelos abstractos.
class Product(models.AbstractModel): _name = 'sdicrm.product' Un modelo abstracto hereda de la clase AbstractModel en vez de la clase Model, lo que hace que para
este modelo no se cree una tabla en la BD.
En este ejemplo, el modelo 'Product' no tendría una tabla en la BD.
Así, los dos modelos que nombré antes heredan de este modelo 'Product' mediante la siguiente notación:
class Software(models.Model): _name = 'sdicrm.product.software' _inherit = 'sdicrm.product' El campo _inherit sirve para heredar de cualquier modelo, no sólo de un modelo abstracto.
class ServiceGeneric(models.Model): _name = 'sdicrm.product.service' _inherit = 'sdicrm.product'
2) Tengo más relaciones de este tipo. Por ejemplo, en los modelos involucrados en la subscripción de
productos (un cliente puede comprar un software por subscripción por unos meses, o puede adquirir un
servicio de mantenimiento o soporte por un tiempo).
class ProductSubscription(models.AbstractModel): _name = 'sdicrm.product.subscription' _description = 'Subscripcion_Producto' class MaintenanceSoftwareSubscription(models.Model): _name = 'sdicrm.maintenance.subscription' _inherit = 'sdicrm.product.subscription' class SupportSoftwareSubscription(models.Model): _name = 'sdicrm.support.software.subscription' _inherit = 'sdicrm.product.subscription'
3) Otra relación de este tipo se da entre el modelo Tarea que es abstracto, y Presupuesto, Cita y Llamada.
Todos éstos son tareas.
class TaskForCompany(models.AbstractModel): _name = 'sdicrm.task' _description = 'Tarea' class Quote(models.Model): _name = 'sdicrm.quote' _inherit = 'sdicrm.task' class PhoneCall(models.Model): _name = 'crm.phonecall' _inherit = 'sdicrm.task' class TaskEvent(models.Model): """
TaskEvent representa a las tareas de tipo demo, visita y reunión
Página 41 de 129
"""
_name = 'calendar.event' _inherit = 'sdicrm.task'
Por otra parte, Odoo ofrece una clase base con varios atributos y métodos que representa a una empresa.
Yo también tengo una clase Empresa, por lo que quiero aportar mis nuevos campos y métodos. Pero no
quiero herencia normal porque si no tendría dos tablas Empresas en la BD. Mediante herencia por
extensión, amplío la clase Empresa de Odoo con nuevos atributos y métodos, pero al final los datos
estarán en la misma tabla.
class Company(models.Model): _name = 'res.partner' _inherit = 'res.partner' * El modelo 'res.partner' es el modelo base de Empresa que proporciona Odoo.
Los campos o atributos del modelo
Como hice el diagrama de clases pensando desde el principio en cómo funciona el ORM de Odoo, y qué
relaciones se crean al usar campos de tipo 'Many2one', 'Many2many' y 'One2many', no he tenido que
hacer ningún trabajo extra para trasladar todos los atributos del diagrama al modelo correspondiente
implementándolos en Python.
Solamente hay que seguir la sintaxis definida por el ORM.
Esta imagen contiene un trozo de código de la clase Company. Como se puede observar, cada tipo de
campo tiene un tipo definido (del que ya hablé en el apartado Diseño de esta memoria): Char, Integer,
Selection, Float, Text, Html, Boolean, Date, Datetime, Many2one, Many2many y One2many.
Estos tres últimos tipos son los campos llamados 'related fields' que conforman relaciones entre clases.
Cada tipo de campo del modelo puede ser definido con una serie de parámetros. Hay una serie de
parámetros comunes a todos los campos, pero otros son específicos.
Con el diagrama de clases en la mano, lo primero que hice fue ir creando las clases e ir definiendo las
relaciones entre ellas con campos de tipo 'related fields'.
Por ejemplo, si un presupuesto puede contener una o varias líneas, pero una línea sólo puede pertenecer
a un presupuesto, entonces uso un campo One2many en el modelo Presupuesto, y un campo Many2one
en el modelo LineaPresupuesto:
Página 42 de 129
class Quote(models.Model): _name = 'sdicrm.quote' line_ids = fields.One2many('sdicrm.quote.line', 'quote_id', required=True) class QuoteLine(models.Model): _name = 'sdicrm.quote.line' _description = 'Linea_Presupuesto' quote_id = fields.Many2one('sdicrm.quote', string='Presupuesto', help='Presupuesto asociado')
De esta manera seguí con este proceso, por cada clase en el diagrama de clases resolviendo cada relación
hacia un campo de tipo 'related field'.
El segundo paso era definir todos aquellos atributos de tipos simples en cada modelo.
Una vez hecho esto, tenía que pensar qué campos de cada modelo iban a ser de sólo lectura o lectura-
escritura, es decir, a cuáles podía cambiar su valor.
date_accept = fields.Datetime(string='Fecha de aceptación', help='Fecha en la que se acepta el presupuesto', readonly=True) Para ello, se usa el parámetro readonly igual a True o False.
Después, tenía que definir aquellos campos en los que obligatoriamente se debe introducir un valor, lo
que en jerga de BD se traduce como 'NOT NULL'.
line_ids = fields.One2many('sdicrm.quote.line', 'quote_id', string='Líneas del presupuesto', required=True) Para ello, se usa el parámetro required igual a True o False.
Seguidamente, hay que pensar el valor por defecto que tendrán algunos campos de los modelos.
tax = fields.Integer(string='Impuesto (en %)', default=21, required=True) Para ello, se usa el parámetro default asignándole un valor o una función que puede devolver un valor.
En este ejemplo, el impuesto de un producto tendrá como valor por defecto un 21 %.
NOTA:
Hay que pensar que estos tres atributos usados en los campos también van a provocar su efecto en las
vistas, ya que un atributo readonly provoca que ese campo en el formulario no pueda ser modificado,
required provoca que el usuario se vea obligado a introducir un dato en el campo del formulario, y default
hace que aparezca el valor por defecto en el control del formulario asignado a ese campo.
El tercer paso respecto a los campos del modelo es identificar aquellos que van a ser calculados, es decir,
que su valor va a ser calculado a partir de una función.
Por ejemplo, el modelo Empresa (Company) tiene un campo definido para saber a cuántas campañas de
marketing está asociada la empresa. Esto no es algo que pueda saberlo de antemano, hay que calcularlo.
def _compute_num_marketing_campaigns(self): self.marketing_campaigns_count = \ self.env['sdicrm.marketing.campaign'].search_count([('company_ids', 'in', self.id)]) marketing_campaigns_count = fields.Integer(string='Num campañas marketing asociadas', compute='_compute_num_marketing_campaigns') Para ello, se usa el parámetro compute dentro del campo definido y se le asigna el nombre de la función
que calculará su valor.
ondelete
Una tarea que tuve que hacer constantemente sobre los tipos de campos Many2one fue usar el parámetro
'ondelete'.
category_id = fields.Many2one('sdicrm.software.category', string='Categoría de software', required=True, ondelete='restrict') ondelete puede tomar los valores 'restrict', 'set null' o 'cascade'.
Página 43 de 129
Su comportamiento corresponde a lo que ocurre cuando en una tabla se borra una fila que está
referenciada por una clave foránea de otra tabla. Lo mismo que en SQL.
En el ejemplo de arriba, este campo está dentro del modelo ‘Software’, y su atributo ondelete hace que
cuando se borre de la BD una fila con una categoría de software referenciada por otra fila de la tabla
correspondiente al modelo Software, se impida la eliminación de la categoría.
constrains y _sql_constraints
Después, tuve que pensar en las restricciones impuestas en cada modelo. Con restricciones me refiero a
que no se permita escribir un valor en un campo si se da tal condición.
Estas restricciones son usadas al introducir datos en un formulario, pero también se usan si desde el
método de un modelo en Python intento escribir un valor en un campo que tiene una restricción.
@api.one @api.constrains('date_closed') def _check_date_closed(self): if self.date_closed and self.date_closed < self.create_date: raise exceptions.ValidationError('La fecha de cierre no puede ser menor que la de creación de la ' 'oportunidad') Para definir una restricción sobre un campo uso el decorador @api.contrains con un parámetro que indica
el campo al que afecta la restricción.
Este decorador va encima del método que comprueba si se cumple la restricción al asignar un valor a este
campo.
Si no se cumple, se debe lanzar una excepción que provocará la interrupción de la asignación, y mostrará
al usuario un mensaje.
Lo importante de estas restricciones es que se ejecutan del lado del servidor, por lo tanto, son mucho más
seguras que las típicas restricciones que se suelen programar en JavaScript para validar formularios.
Por último, existen otro tipo de restricciones que también definí en mis modelos. Este tipo de restricciones
son diferentes puesto que son restricciones propias del SGBD PostgreSQL, y por tanto, el ORM de Odoo
las guarda en la BD.
_sql_constraints = [ ('opportunity_unique_quote', 'UNIQUE(quote_id)', 'No puede haber dos oportunidades asociadas al mismo presupuesto') En este ejemplo de restricción del modelo Oportunidad, se implementa una restricción de tipo UNIQUE
sobre el campo 'quote_id' del modelo Oportunidad.
Se puede usar cualquier tipo de restricción de PostgreSQL.
La lógica de negocio del modelo
Una vez hechos todos estos procesos sobre los campos en los que se crea necesarios llevarlos a cabo, ya
podría pasar a implementar todos los métodos propios de la lógica de negocio en cada modelo, usando
el lenguaje Python para la lógica de negocio, y el API del ORM de Odoo, usando también Python, para la
lógica de la BD.
Página 44 de 129
En la imagen de arriba se observa cómo es la estructura de cualquier método de la lógica de los modelos.
En todos los métodos de nuestro modelo debemos poner el parámetro self. Esto es algo típico de Python,
y viene a representar el propio objeto instanciado que invoca al método. Es similar al this de Java.
La diferencia en Odoo es que self representa un recordset de un modelo en concreto (un conjunto de
objetos). Por ejemplo, en el método anterior, self representa un conjunto de presupuestos formado por
cero, uno o ningún presupuesto, porque se encuentra implementado dentro del modelo Quote.
Cargar vistas desde un método
El paso posterior es algo muy común en los métodos de la lógica, y es hacer que se cargue una vista
determinada de un modelo cuando acaba de ejecutarse el método. Yo lo he hecho en varios métodos.
Por ejemplo, en el modelo Company, existe un método que se activa cuando el usuario pulsa en un botón.
Este método busca campañas de marketing de una empresa y lanza una acción para que se cargue una
vista.
@api.multi def see_marketing_campaigns_company(self): self.ensure_one() marketing_campaigns_company = self.env['sdicrm.marketing.campaign'].search([('company_ids', 'in', self.id)]) if len(marketing_campaigns_company) > 0: return { "type": "ir.actions.act_window", "res_model": "sdicrm.marketing.campaign", "view_mode": "tree,form", "domain": "[('company_ids', 'in', active_id)]", "target": "current", } return False
domain
Otro elemento que he usado bastante en mi módulo es determinar que un campo de un modelo sólo
pueda contener ciertos valores.
@api.model def _get_domain_maintenance_users(self): return [('groups_id', 'in', self.env.ref('sdicrm.group_maintenance_users').id)] maintenance_users_ids = fields.Many2many('res.users', string='Usuarios responsables',
Página 45 de 129
help='Usuarios responsables de este mantenimiento', domain=_get_domain_maintenance_users) En este ejemplo de arriba, se ve como el campo 'maintenance_users_ids' tiene un atributo llamado
'domain'. Este atributo debe tener como valor un tipo especial llamado 'domain'.
Un domain es una lista de tuplas, donde cada tupla impone una condición de búsqueda. En el caso
anterior, el domain para el campo ' maintenance_users_ids' es devuelto por un método.
Este método hace que en este campo sólo pueda tener los valores correspondientes a usuarios que
formen parte del grupo de nombre 'sdicrm.group_maintenance_users'.
También he usado el domain en un campo aplicado directamente.
software_id = fields.Many2one('sdicrm.product.software', string='Software', required=True, help='Software al que se presta este servicio de mantenimiento', domain=[('has_maintenance', '=', True)]) En este ejemplo, este campo sólo tendrá los productos software que tengan servicio de mantenimiento.
Otros elementos del CRM
Una vez tengo la lógica de la aplicación, puedo desarrollar otras funcionalidades que no se programan en
lenguaje Python.
En concreto hay tres que quiero destacar, los llamados workflows, las acciones automatizadas y los
wizards o asistentes.
Workflows
Un workflow marca la evolución de un record u objeto a lo largo de su vida.
Yo he usado los workflows básicamente para ir cambiando un record a lo largo de su vida.
Lo he utilizado en los modelos Opportunity, Quote, Software, ServiceMaintenance, ServiceSupport,
PhoneCall, MarketingCampaign, y Event (reunión, demo, visita, etc).
Un workflow está formado por nodos y transiciones (como un grafo). Las transiciones se disparan cuando
se genera un evento en la aplicación. Este evento hace que el objeto pase a otro nodo diferente donde se
ejecuta una acción.
En mi módulo, las transiciones siempre se activan cuando el usuario pulsa en un botón.
Me gustaría explicar brevemente cómo está realizado el workflow del modelo Quote(Presupuesto) de mi
módulo CRM. Primero declaro el workflow.
<?xml version="1.0" encoding="utf-8"?> <openerp> <data> <!-- Workflow Quote State -->
<record id="sdicrm_wkf_quote" model="workflow"> <field name="name">sdicrm workflow quote</field> <field name="osv">sdicrm.quote</field> <field name="on_create">True</field> </record> … </data> </openerp>
Después hay que definir las transiciones y los nodos. Por ejemplo, aquí muestro una transición que se
dispara cuando recibe una señal. Esta señal la recibe cuando el usuario pincha en un botón.
<!-- Transitions --> <!-- From pendiente_envio to en_seguimiento -->
<record id="pendiente_to_segumiento" model="workflow.transition"> <field name="act_from" ref="state_pendiente_envio"/> <field name="act_to" ref="state_en_seguimiento"/> <field name="signal">state_to_en_seguimiento</field> </record>
Página 46 de 129
En este ejemplo, la transición se dispara cuando alguien pincha en un botón en la interfaz que envía la
señal 'state_to_en_seguimiento'.
En este caso, el record (un presupuesto concreto) pasa del nodo 'state_pendiente_envio' al nodo
'state_en_seguimiento'.
El nodo de destino se implementa de la siguiente manera:
<record id="state_en_seguimiento" model="workflow.activity"> <field name="wkf_id" ref="sdicrm_wkf_quote"/> <field name="name">presupuesto_en_seguimiento</field> <field name="kind">function</field> <field name="action">state_to_en_seguimiento()</field> </record> Cuando el record llega a este nodo se ejecuta el método ‘state_to_en_seguimiento’ en Python de la clase
Quote.
La gran desventaja de los workflows es que no pueden ser usados haciendo referencia a un modelo
abstracto.
En mi caso, fue un gran problema porque no pude aplicarlo al modelo Product, que es abstracto y que es
el padre de otros modelos como Software y SoftwareSupport.
De esta manera, tuve que programar varios workflows iguales para cada modelo.
Acciones automatizadas
Otro elemento muy interesante de Odoo es el poder ejecutar acciones automatizadas que se ejecutan
cuando sucede algún tipo de evento. En mi módulo he creado cuatro acciones automatizadas:
Una para cambiar el estado a 'rechazado' del presupuesto asociado a una oportunidad cuando ésta pase al estado frío o pase a una fase cuya probabilidad sea 0, y que se ejecuta cuando se crea o actualiza una oportunidad.
Otra acción que hace que, cuando se crea o actualiza una oportunidad, y a ésta se le asocia un presupuesto, se asocie también a este presupuesto dicha oportunidad. Además hace que, si al crear o actualizar la oportunidad, a ésta se le quita el presupuesto asociado, a este presupuesto le elimina esta oportunidad asociada.
Otra acción que se ejecuta también cuando se crea o actualiza una oportunidad, y hace que si la oportunidad pasa a una fase con probabilidad 100% su presupuesto asociado pase al estado aceptado.
Otra acción que se ejecuta al crear o actualiza una oportunidad, y hace que cuando se asocie una llamada a la oportunidad, también se asocie la oportunidad a la llamada. Además hace que si se borra en una oportunidad su llamada asociada, también se borre de la llamada esa oportunidad con la que estaba asociada.
El siguiente código muestra a modo de ejemplo cómo se implementa una acción automatizada en XML:
<?xml version="1.0" encoding="utf-8"?> <openerp> <data> <record id="sdicrm_opp_quote_rechazado_act_server" model="ir.actions.server"> <field name="name">Presupuesto de opportunity a rechazado</field> <field name="model_id" ref="crm.model_crm_lead"/> <field name="state">code</field> <field name="type">ir.actions.server</field> <field name="condition">object.stage_id.probability==0</field> <field name="code"> object.quote_to_rechazado() </field> </record> <record id="sdicrm_opp_quote_rechazado_auto_action" model="base.action.rule"> <field name="name">sdicrm_opp_quote_rechazado</field> <field name="model_id" ref="crm.model_crm_lead" /> <field name="kind">on_create_or_write</field> <field name="server_action_ids" eval="[(6, 0, [ref('sdicrm_opp_quote_rechazado_act_server')])]" /> </record>
Página 47 de 129
Wizard
Otro de los elementos que he usado es lo que se conoce como 'wizard'.
Wizard es un asistente que permite que el usuario ejecute una serie de acciones en un formulario en una
ventana emergente.
Yo lo he usado para que el usuario pueda programar llamadas a empresas de forma masiva cada cierto
intervalo de tiempo.
Un wizard no es más que otro modelo más implementado en Python que tiene asociado una vista de tipo
formulario.
La única diferencia con un modelo normal es que un modelo wizard hereda de la clase
'models.TransientModel'.
Implementación de las vistas
Después de haber realizado los anteriores pasos llega el momento de implementar las vistas.
Dentro de los módulos de tipo 'backend', Odoo nos proporciona principalmente cinco tipos de vistas:
formulario, tabla (llamado list o tree), calendario, tablero kanban y gráficos.
De todas estas vistas, las que realmente podemos diseñar realmente son los formularios.
Las demás siempre van a tener casi el mismo aspecto visual, exceptuando levemente la vista kanban que
va a permitir modificarla ligeramente.
Página 48 de 129
Como se ve en la imagen de arriba, Odoo te da un contenedor con una barra lateral donde sí hay que
construir los menús, también la barra superior negra donde también se puede crear menús, y botones,
barras de búsqueda, etcétera. No hay que crear ningún elemento gráfico.
Asociación vista-modelo
Es importante aclarar que cada vista está asociada a un modelo, por lo tanto, sólo puede mostrar los
campos definidos en la clase Python de este modelo, no los campos de otro modelo.
Mostrar la vista de un modelo
Antes de nada hay que crear los menús del módulo usando XML.
<menuitem id="sdicrm_marketing_campaign_menu" name="Campañas de Marketing" parent="sdicrm_marketing_menu" action="sdicrm_marketing_campaign_action"/> Este menú sirve para acceder a las campañas de marketing.
Tiene asociada una acción que determina qué hacer al hacer clic en este menú, y un menú padre ('parent')
del que cuelga. Esa acción es la que permite lanzar las vistas, y también se implementa en XML.
<record id="sdicrm_marketing_campaign_action" model="ir.actions.act_window"> <field name="name">Campañas de Marketing</field> <field name="type">ir.actions.act_window</field> <field name="res_model">sdicrm.marketing.campaign</field> <field name="view_mode">tree,form</field> <field name="help" type="html"> <p class="oe_view_nocontent_create"> <h1>Campañas de Marketing</h1> </p> <p>No has creado ninguna campaña de marketing</p> </field> </record> Esta acción está asociada a un modelo en concreto, aquí al modelo cuyo nombre es
'sdicrm.marketing.campaign' ('res_model'), y permite lanzar las vistas de tipo tree y form ('view_mode').
La que va en primer lugar es la que se muestra primero. A la segunda se puede acceder a través de un
botón que Odoo crea.
Odoo crea automáticamente un pequeño botón para cargar cada tipo de
vista
Menús de mi módulo CRM
El menú raíz de mi módulo es Ventas situado en la barra negra superior.
En la sección lateral voy creando toda la estructura de menús tal y como he comentado antes con esa
sintaxis especial en XML.
Los menús pueden tener menús padres, pero sólo los menús que no tienen hijos pueden abrir vistas.
Página 49 de 129
¿Cómo implementar las vistas?
Depende del tipo de vista.
Si se quiere construir una vista de tipo formulario hay que usar una serie de etiquetas y atributos en XML,
pero también puede ser usado HTML y CSS.
El formulario es la vista principal pues es la que permite crear y editar elementos, además de ver toda su
información.
Es el tipo de vista al que más atención he prestado pues mi módulo CRM exigía la introducción de muchos
datos para muchos modelos diferentes.
Las vistas pueden implementarse en muchos ficheros .xml. Lo aconsejable es una vista por modelo aunque
si los modelos son muy simples pueden ir en el mismo fichero xml.
Nota 1: si queremos que el valor de un campo de un record de un modelo aparezca en una vista, siempre
debemos indicar esta etiqueta: <field name="nombre_campo">
Nota 2: en cada vista definida siempre hay que decir a qué modelo corresponde mediante la siguiente
etiqueta XML dentro de la definición de la vista: <field name="model">nombre del modelo</field>
Formularios
En el siguiente ejemplo muestro el código de una vista de tipo formulario para ver cómo es su estructura
general.
<record id="wizard_phonecalss_view_form" model="ir.ui.view"> <field name="name">Scheduler Form view</field> <field name="model">sdicrm.wizard_phonecalls_scheduler</field> <field name="arch" type="xml"> <form> <label for="company_ids" /> <field name="company_ids"/> <label for="marketing_campaign" /> <field name="marketing_campaign"/> <button string="Obtener empresas de campaña" type="object" name="get_companies_from_campaign" /> <group> <group> <field name="day_time"/> </group> <group> <field name="interval"/> </group>
Página 50 de 129
</group> <footer> <button type="object" name="schedule_phone_calls" string="Programar llamadas" class="oe_highlight" /> <button special="cancel" string="Cancel"/> </footer> </form> </field> </record>
Una funcionalidad visual que he usado en varias vistas de varios modelos es lo que muestra la siguiente
imagen.
Esta barra permite cambiar el estado de un record, en este caso el estado de un producto software. Esto
está totalmente ligado al tema de workflows que expliqué antes. Cuando pincho en un botón de esta
barra, se envía una señal al workflow para que se dispare una transición y se ejecute una serie de acciones,
por ejemplo, cambiar el estado del objeto.
Otro aspecto a destacar en la vista de formularios es un elemento que aparece en su pie.
Es un elemento que hace una función de sistema de mensajería dentro de cada formulario, de modo que
los usuarios pueden dejar mensajes para que otros los vean, seguir los cambios que se produzcan en los
campos de un formulario de una instancia en concreto, etc.
Esto es algo que yo no he programado ni diseñado la vista.
Para hacer uso de esto tan sólo debo hacer tres cosas:
Que mi módulo dependa del módulo incorporado por Odoo llamado 'mail.thread'. Para ello, debo incorporar esta dependencia al fichero '__openerp__.py' de mi proyecto.
Hacer que cada modelo (clase en Python) herede del modelo 'mail.thread': _inherit = 'mail.thread'
Incluir cuatro líneas de código en la vista del formulario:
<div class="oe_chatter"> <field name="message_follower_ids" widget="mail_followers"/> <field name="message_ids" widget="mail_thread"/> </div>
Tree
El segundo tipo de vista de la que hablar es el del tipo list o tree. Es la vista que menos personalización
permite (es muy complicado modificarla). También se define con XML, pero no permite usar HTML ni CSS.
Esta vista está compuesta de filas y columnas. Cada fila corresponde a un record de un modelo, lo que se
traduce a una fila en la tabla del modelo en la BD. Esta es su estructura general.
<record id="sdicrm_marketing_campaign_view_tree" model="ir.ui.view"> <field name="name">sdicrm_marketing_campaign_view_tree</field> <field name="model">sdicrm.marketing.campaign</field> <field name="arch" type="xml"> <tree default_order="type_id,state desc"> <field name="name"/>
Página 51 de 129
<field name="state"/> <field name="type_id"/> <field name="priority"/> <field name="date_start"/> </tree> </field> </record>
Este trozo de código se convierte en la siguiente vista:
Tablero Kanban
Hay dos tipos de vista kanban, una organizada por columnas y otra mediante una cuadrícula.
En este tipo de vista, Odoo ya construye las columnas y todo el contenedor. Lo que yo puedo hacer es
decir a qué campo se corresponde la columna.
Página 52 de 129
Lo que sí debo diseñar es cada uno de los rectángulos que se ven en la imagen. Para ello, puedo usar
Qweb, HTML y CSS.
Qweb es un lenguaje de tipo XML que permite crear plantillas que luego se transforman a HTML.
Calendario
La vista de tipo calendario es prácticamente impersonalizable visualmente de forma fácil. Mis
conocimientos y la nula documentación sobre este tema han hecho que haya sido incapaz.
Para el modelo 'Oportunidad' definir esta vista sería tan fácil como escribir las siguientes líneas:
<record model="ir.ui.view" id="crm_case_calendar_view_leads"> <field name="name">Calendario-Oportunidades</field> <field name="model">sdicrm.opportunity</field> <field name="arch" type="xml"> <calendar string="Oportunidades"
Página 53 de 129
date_start="date_action" color="user_id"> <field name="name"/> </calendar> </field> </record> Se indica usando la etiqueta <calendar> con los atributos 'date_start' para decirle en qué fecha debe estar
situado el registro en el calendario, y 'color' para saber cómo se colorea cada registro en cada día del
calendario. La fecha de comienzo tiene que ser un campo de tipo fecha en el modelo al que se refiere la
vista, y color se refiere a que Odoo dará un color diferente a cada registro en el calendario según un campo
del modelo.
Gráficos
Generar un gráfico es muy sencillo. Todo el proceso de dibujado del gráfico y la interacción con este tipo
de vista la hace Odoo.
Por ejemplo, para hacer un grafo de tipo barras (type="bar") para el modelo Oportunidad, sólo tengo usar
el siguiente fragmento de código.
<record model="ir.ui.view" id="crm_case_graph_view_leads"> <field name="name">Opportunities</field> <field name="model"> sdicrm.opportunity </field> <field name="arch" type="xml"> <graph string="Opportunities" type="bar"> <field name="stage_id" type="row"/> <field name="planned_revenue" type="measure"/> </graph> </field> </record> <field name="stage_id" type="row"/> hace que el eje horizontal del gráfico esté representado por el
campo 'stage_id' del modelo 'Oportunidad', y el eje vertical viene dado por otro campo llamado
'planned_revenue'.
La representación sería la siguiente.
Los otros tipos de gráficos se definen de la misma manera, por este motivo no voy a mostrarlos.
Filtros y agrupaciones
Se usan para filtrar o agrupar resultados en las vistas.
Por ejemplo, en la vista de tipo tree donde aparece el listado de contactos de empresa, sólo quiero
mostrar los contactos de las empresas que son clientes pero agrupados por empresa.
Página 54 de 129
Los filtros y agrupaciones se construyen mediante XML. Por ejemplo, el filtro anterior sería así:
<record id="view_res_partner_filter" model="ir.ui.view"> <field name="name">res.partner.select</field> <field name="model">res.partner</field> <field name="arch" type="xml"> <search string="Search Company"> <filter string="Companies" name="type_company" domain="[('is_company','=',1)]"/> <filter string="Company" context="{'group_by': 'parent_id'}"/> </search> </field> </record>
onchange – detectar cambios introducidos en el formulario
A la par que vamos construyendo las vistas tenemos la posibilidad de elegir qué pasa cuando cambia el
valor de un campo en el formulario. Yo he usado este comportamiento en muchos de mis formularios.
Para ello, hay que ir al fichero Python donde está definido el modelo de este campo y crear un método
como éste:
@api.multi @api.onchange('company_id', 'contact_id') def _onchange_company(self): if self.company_id: domain = {'domain': {'contact_id': [('parent_id', '=', self.company_id.id)]}} return domain Este método pertenece al modelo 'Tarea' y provoca que cuando el usuario en el formulario cambie el valor
del control asignado al campo 'company_id' o al campo 'contact_id', se ejecute este método, que hace
que sólo se muestren los contactos de la empresa seleccionada.
5.6. Cargar datos en la BD
La precarga de datos en la BD se hace mediante ficheros XML donde se indica un <record> para cada fila
de una tabla de un modelo concreto. Cada <field> indica el valor dado a cada campo del modelo.
<openerp> <data> <record model="crm.case.stage" id="sdicrm_stage_1"> <field name="name">1_Contacto-No_presupuesto</field> <field name="case_default">1</field> <field name="probability">25</field> <field name="on_change">1</field> <field name="sequence">2</field>
Página 55 de 129
<field name="type">both</field> </record> … </data> </openerp>
5.7. Evaluación de requisitos de la aplicación cumplidos e incumplidos
Los siguientes requisitos son los únicos requisitos de la aplicación planteados en la fase inicial de este TFG
que no se han podido llevar a cabo con éxito:
Interfaz gráfica adaptada a móviles (propuesto por el cliente).
Sistema de alertas o avisos a los comerciales dentro de Odoo o mediante email (propuesto por el cliente).
Control de permisos de usuarios en la vista de tipo calendario donde se visualizan las tareas.
Logger dentro de Odoo que permita registrar las operaciones realizadas sobre los datos.
6. Pruebas
Pruebas unitarias
El proceso de pruebas seguido está basado en pequeñas pruebas ejecutadas aisladamente cada vez que
se añadía una funcionalidad nueva.
Prueba 1
Nombre tarea Cargar vistas
Proceso Comprobar que todas las vistas definidas en todos los modelos se cargan correctamente al elegir cada menú del módulo.
Test pasado Sí
Prueba 2
Nombre tarea Validaciones en los formularios
Descripción Comprobar que todas las restricciones impuestas en el código Python de todos los modelos se ejecutan al guardar datos en todos los formularios, que se muestran los mensajes de advertencia correspondientes por pantalla y que se interrumpe la acción de guardar datos en un formulario.
Test pasado Sí
Prueba 3
Nombre tarea Creación y edición en formulario
Descripción Comprobar que la creación y edición de datos en todos los formularios de cada modelo se realiza correctamente.
Test pasado Sí
Prueba 4
Nombre tarea Precargar datos
Descripción Comprobar que todos los datos a cargar desde ficheros XML se guardan correctamente en la tabla de la BD correspondiente, y que estos datos se ven reflejados en la interfaz gráfica.
Test pasado Sí
Prueba 5
Nombre tarea Smart buttons en vista formulario de Empresa
Página 56 de 129
Descripción - Comprobar que en el formulario de Empresa aparecen unos botones con un número cada uno que corresponda al número de campañas de marketing, presupuestos, reuniones y llamadas asociadas a la empresa.
- Ver que al hacer clic en el botón correspondiente se abre una vista en la que se puede ver la lista de campañas de marketing, presupuestos, reuniones y llamadas asociadas a la empresa.
Test pasado Sí
Prueba 6
Nombre tarea Envío emails
Descripción Comprobar que se envía un email correctamente al destinatario al usar el asistente de envío de emails que aparece al pinchar en algunos botones de la interfaz gráfica repartidos por algunos formularios.
Test pasado Sí
Prueba 7
Nombre tarea Smart button oportunidad en formulario de campaña de marketing
Descripción - Comprobar que en el formulario de una campaña de marketing aparece un botón con un número que representa el número de oportunidades que tienen como origen esta campaña.
- Ver que al hacer clic en este botón podemos acceder al listado de oportunidades asociadas a la campaña, y comprobar que esas oportunidades pertenecen a dicha campaña.
Test pasado Sí
Prueba 8
Nombre tarea Llamadas, citas y presupuestos asociados a una campaña de marketing
Descripción Comprobar que en el formulario de una campaña de marketing aparece:
- Un listado con la información de las llamadas asociadas a la campaña.
- Un listado con la información de las demos, reuniones y visitas asociadas a la campaña.
- Un listado con la información de los presupuestos asociados a la campaña.
Test pasado Sí
Prueba 9
Nombre tarea Cambiar el estado en todos los formularios que lo permita
Descripción Comprobar que podemos cambiar el estado pinchando en los botones que aparecen en la parte superior de todos los formularios que tienen barra de estados.
Test pasado Sí
Prueba 10
Nombre tarea Oportunidad ganada / perdida
Descripción - Comprobar que pinchando en el botón 'Marcar ganado' del formulario de una oportunidad registrada, ésta pasa a una fase de oportunidad que tenga asignada una probabilidad del 100 %, y ver si al hacer lo anterior, la probabilidad de éxito de la oportunidad es del 100 %.
- Comprobar que pinchando en el botón 'Marcar perdido’ del formulario de una oportunidad registrada, ésta pasa a una fase de oportunidad que tenga asignada una probabilidad del 0 %, y ver si al hacer lo anterior, la probabilidad de éxito de la oportunidad es del 0 %.
Test pasado Sí
Prueba 11
Nombre tarea Comprobación de dominios en campos de tipo Many2one en los formularios
Descripción Comprobar que en los formularios donde aparece un campo de tipo Many2one, se aplica correctamente el dominio que tuviera aplicado, y sólo muestra como asignable a ese campo los valores que el dominio permita.
Página 57 de 129
Test pasado Sí
Prueba 12
Nombre tarea Oportunidad perdida – presupuesto rechazado
Descripción Comprobar que si marco una oportunidad como perdida, su presupuesto asociado (si lo tiene) pasa a tener un estado llamado rechazado.
Test pasado Sí
Prueba 13
Nombre tarea Borrar/Actualizar presupuesto llamada asociada a oportunidad
Descripción - Comprobar si al eliminar un presupuesto o llamada asociada en una oportunidad, también se borra en el presupuesto o llamada la asociación con esta oportunidad.
- Comprobar si al cambiar a una oportunidad su llamada o presupuesto asociado, la llamada o el presupuesto previamente asociado ha perdido su conexión con ésta
Test pasado Sí
Prueba 14
Nombre tarea Filtros y grupos
Descripción Comprobar que los filtros y las agrupaciones definidas para los diferentes modelos funcionan correctamente, y filtran y agrupan los datos correspondientes
Test pasado Sí
Prueba 15
Nombre tarea Convertir llamada/cita/presupuesto a oportunidad
Descripción Convertir uno de estos elementos a una oportunidad, y que dicha oportunidad quede guardada en la BD.
Ciertos datos que provienen de ellos deben ser registrados en la oportunidad.
En la oportunidad creada debe grabarse automáticamente la llamada de la que procede. Comprobar que esto se cumple.
Test pasado Sí
Prueba 16
Nombre tarea Programador de llamadas
Descripción - Comprobar que el asistente de llamadas crea llamadas para una serie de empresas elegidas, en una fecha base y con un intervalo de tiempo de x minutos entre cada una de ellas.
- Comprobar que se ha creado una llamada para cada empresa, y que cada llamada está separada de la anterior por el intervalo de x minutos elegido anteriormente.
Test pasado Sí
Prueba 17
Nombre tarea Cambiar estado a un presupuesto
Descripción - Comprobar que se puede cambiar el estado de un presupuesto.
- Comprobar que una vez el estado es 'rechazado' ya no puede volver a cambiar dicho estado.
- Comprobar que si el estado pasa a ser 'represupuestado' se incrementa en uno el número de veces que el presupuesto ha sido represupuestado.
- Comprobar que si el presupuesto pasa al estado 'aceptado' ya no puede cambiarse más veces su estado.
- Comprobar que cuando se cambie el estado a 'aceptado' se cambia la fecha de aceptación del presupuesto al día actual, se cambia su oportunidad asociada (si la tiene) a un estado 'inminente' y a una fase con probabilidad de éxito del 100 %, se convierte a la empresa en cliente si no lo era antes, se asocia el presupuesto en esta empresa, y se asocia los productos adquiridos en el presupuesto a esta empresa.
- Comprobar que si el estado cambia a 'rechazado' se registra como fecha de rechazo el día actual, se incrementa en uno el número de veces que ha sido rechazado el
Página 58 de 129
presupuesto, y se cambia su oportunidad asociada (si la tiene) al estado 'frio' y a una fase con probabilidad de éxito del 100%
Test pasado Sí
Prueba 18
Nombre tarea Imprimir informe presupuesto
Descripción - Comprobar que se crea el informe en formato pdf correctamente, y que en él figuran los datos de nuestra empresa, los datos del cliente, el importe total, y una tabla con una fila por cada línea del presupuesto.
Test pasado Sí
Prueba 19
Nombre tarea Fusionar empresas
Descripción - Comprobar que al fusionar varias empresas, toda su información (contactos, responsables, grupos de usuarios responsables, citas, demos, reuniones, llamadas, presupuestos y oportunidades) pasa a formar parte de la empresa elegida como destino.
Test pasado Sí
Prueba 20
Nombre tarea Eliminar empresas duplicadas
Descripción - Comprobar que al eliminar empresas duplicadas se eliminan las empresas duplicadas encontradas por nombre o email, o por los dos, y toda su información pasa a formar parte de la empresa de destino elegida.
Test pasado Sí
Pruebas de integración
Una vez terminadas las pruebas unitarias de forma aislada y después de su desarrollo, se prueban todas
ellas de forma conjunta al acabar la aplicación por completo para saber si existen conflictos entre
diferentes operaciones ejecutadas.
Puedo concluir que las pruebas son un éxito, que no existen interferencia entre las operaciones, que no
se produce ningún fallo en la integridad y consistencia de los datos, que la aplicación sigue funcionando
correctamente y la BD no queda corrupta.
7. Conclusiones
En este apartado procederé a explicar mis reflexiones una vez acabado este TFG.
En cuanto a conocimientos adquiridos puedo decir que he aprendido a manejar con cierta soltura la
programación de aplicaciones en Odoo. Aun así, creo que no es algo positivo porque esto no me sirve de
nada fuera del entorno de Odoo.
En cuanto a nivel de planificación del TFG, podría decir que no ha sido bueno, ya que hice una mala
estimación de fechas, y no supe reaccionar a tiempo ante los problemas surgidos.
Tuve que enfrentarme a una replanificación de tiempos dados los problemas encontrados en el
aprendizaje de programación sobre Odoo.
A mi favor sólo puedo decir que el proceso de formación ha sido duro debido a la nula documentación y
ayuda encontrada.
Aun así, el resultado ha sido satisfactorio porque creo haber desarrollado una aplicación de calidad en el
poco tiempo que tenía.
Los requisitos del cliente han sido satisfechos sobradamente y la aplicación funciona correctamente en
todas sus funcionalidades.
De todas formas, pasado el tiempo, creo que hice mal al aceptar este proyecto ya que no valoré los riesgos
inherentes a tener que enfrentarme a una etapa de formación tan costosa en tan poco tiempo.
Página 59 de 129
8. Bibliografía
Libros
Daniel Reis, Abril 2015. Odoo Development Essentials. Packt Publishing Ltd.
Recursos web
Documentación oficial para desarrolladores de Odoo: https://www.odoo.com/documentation/8.0
Foro oficial de ayuda sobre Odoo: https://www.odoo.com/es_ES/forum/help-1
Presentaciones sobre Odoo: http://es.slideshare.net/openobject https://www.odoo.com/es_ES/slides/public-channel-1
Foro de usuarios de Odoo en español: https://groups.google.com/forum/#!forum/openerp-spain-users
Sección dedicada a Odoo en el foro stackoverflow.com: http://stackoverflow.com/questions/tagged/odoo
Documentación sobre la versión 7 del framework de Odoo: https://doc.odoo.com
Documentación sobre la versión 6 del framework de Odoo: https://doc.odoo.com/6.1
Vídeos sobre funcionamiento de Odoo y programación con su framework: https://www.youtube.es
Estructura de la base de datos del núcleo de Odoo: http://useopenerp.com/v8 https://fossies.org/dox/odoo-8.0.0/index.html
Cómo instalar Odoo en Ubuntu: http://www.theopensourcerer.com/2014/09/how-to-install-openerp-odoo-8-on-ubuntu-server-14-04-lts/
Documentación oficial de Python: https://docs.python.org/2.7
Youtube – Video tutorial sobre programación orientada a objetos en Python: https://www.youtube.com/watch?v=qsHEAW6wqks&list=PLEtcGQaT56cj70Vl_C1qfUinyMELunL-N
Manual de Python entregado por el cliente
Documentación oficial del SGBD PostgreSQL: http://www.postgresql.org/docs/9.3/static
Otro tipo de documentación
Apuntes adquiridos durante mis estudios en las titulaciones Ingeniería Técnica en Informática de Gestión y Grado en Ingeniería Informática en la Universidad de La Rioja.
Página 60 de 129
ANEXOS
Página 61 de 129
Anexo I: Actas de las reuniones
ACTA 1
Lugar Día: 12-02-2015
Oficina Logroño SDI Soluciones Informáticas Avda. Zaragoza 7, 26006, Logroño (La Rioja)
Hora de comienzo: 12:00 h
Duración: 1 hora
Convocada por Eduardo Basalo Peña
Convocados Eduardo Basalo Peña
José Víctor Gómez (director de proyectos en SDI)
Myriam García (directora del departamento comercial y de marketing en SDI)
Algún comercial del departamento comercial
Asistentes Eduardo Basalo Peña
José Víctor Gómez
Myriam García
No asistentes Comerciales del departamento comercial
Directora de la reunión Myriam García
Apuntador Eduardo Basalo Peña
Orden del día
Explicar los procedimientos y plazos del TFG.
Exponer los objetivos principales del CRM a desarrollar.
Desarrollar la manera con la que SDI trabaja con sus clientes y todos los procesos involucrados en esta tarea.
Explicar las características principales que ofrece Odoo.
Puntos tratados
Eduardo Basalo expone:
o Las principales características de Odoo.
o Qué conocimientos posee acerca de lo que supone un CRM.
o Procedimiento y plazos respecto al TFG.
Myriam García expone:
o Sus conocimientos acerca de lo que es un CRM.
o Procedimiento que sigue SDI en lo que respecta a todos los aspectos concernientes al trato con
clientes, a la manera cómo vienen trabajando hasta ahora y las herramientas software que usan
para tal cometido.
o Principales funcionalidades que desea que el CRM a desarrollar incorpore.
Página 62 de 129
José Víctor Gómez expone:
o Su experiencia en cuanto a su trato con clientes, y actúa de intermediario en lo que respecta a
aspectos técnicos entre Eduardo y Myriam.
Asuntos acordados
Desarrollar un CRM a medida con las funcionalidades expuestas a lo largo de esta memoria.
Acordar sucesivas comunicaciones y reuniones (sin fecha determinada) para resolver dudas, ver cómo trabaja hasta ahora el departamento comercial y observar cómo funciona el software CRM que viene usando SDI hasta ahora: VTiger.
Myriam García deberá enviar por email a Eduardo Basalo toda la información que necesita para parametrizar el CRM, así como las funcionalidades que desea aprovechar de VTiger y las que realmente quiere añadir al CRM a desarrollar en Odoo.
Acordar envío de emails entre Eduardo y Myriam para resolver dudas.
Myriam aclara que más adelante estará de baja por maternidad, así que ella ya no podrá ser la intermediaria entre SDI y Eduardo.
Próxima reunión No acordada
Página 63 de 129
ACTA 2
Lugar Día: 27-02-2015
Universidad de La Rioja Hora de comienzo: 17:00 h
Duración: 1 hora
Convocada por Eduardo Basalo Peña
Convocados Eduardo Basalo Peña
Ana Romero Ibáñez (tutora del TFG)
Asistentes Eduardo Basalo Peña
Ana Romero Ibáñez
No asistentes
Director de la reunión Eduardo Basalo Peña
Apuntador Eduardo Basalo Peña
Orden del día
Explicar lo acordado en la reunión correspondiente al Acta 1.
Puntos tratados
Eduardo Basalo expone:
o Explicar lo acordado en la reunión correspondiente al Acta 1.
o Principales objetivos del CRM a desarrollar.
o Sus dudas en cuanto a qué metodología de desarrollo de software elegir.
o Dificultades técnicas encontradas hasta la fecha en lo que se refiere al funcionamiento de Odoo, y
las tecnologías y lenguajes que necesita aprender para llevar a cabo el TFG.
o Proceso a seguir a partir del momento de esta reunión.
Ana Romero expone:
o El procedimiento a seguir para el desarrollo del TFG en cuanto a gestión y metodología.
o Metodologías de desarrollo de software más adecuadas al tipo de TFG.
Asuntos acordados
Continuar con el desarrollo del TFG.
Intercambiar emails para resolver las dudas que vayan surgiendo.
Acordar próxima reunión (sin fecha determinada) para mostrar el avance.
Próxima reunión No acordada
Página 64 de 129
ACTA 3
Lugar Día: 23-04-2015
Universidad de La Rioja Hora de comienzo: 17:00 h
Duración: 1 hora
Convocada por Ana Romero Ibáñez
Convocados Eduardo Basalo Peña
Ana Romero Ibáñez
Asistentes Eduardo Basalo Peña
Ana Romero Ibáñez
No asistentes
Director de la reunión Eduardo Basalo Peña
Apuntador Eduardo Basalo Peña
Orden del día
Mostrar el avance en el TFG.
Mostrar el funcionamiento de Odoo.
Mostrar el módulo de prueba de Odoo desarrollado por Eduardo, basado en una aplicación cuya funcionalidad está basada en organizar tareas por hacer.
Explicar los nuevos objetivos del CRM a desarrollar, acordados entre Eduardo y SDI.
Exponer las dificultades encontradas por Eduardo en cuanto al desarrollo técnico del CRM y Odoo, y la escasa documentación técnica para desarrolladores existente para su consecución.
Puntos tratados
Eduardo Basalo expone:
o El avance en el TFG hasta el momento actual.
o Dificultades técnicas encontradas para desarrollar el CRM sobre Odoo, sobre todo debido a la
escasa documentación encontrada y a la dificultad del framework que Odoo ofrece para
programar módulos.
o Planteamiento de reducción de funcionalidades a incorporar en el CRM debido al punto anterior.
o Mostrar el funcionamiento de Odoo, así como el módulo de prueba que Eduardo ha realizado,
cuya funcionalidad se basa en servir de aplicación para organizar tareas por hacer.
o Proceso a seguir a partir del momento de esta reunión.
Ana Romero expone:
o Posibilidad de reconducir los objetivos del TFG, centrándose más en el estudio del desarrollo de
módulos para Odoo, que en la calidad del producto software a desarrollar.
o Metodología más adecuada a seguir a partir del momento actual.
o Puntos principales que debe incorporar la memoria.
Página 65 de 129
Asuntos acordados
o Acotar las funcionalidades del CRM a desarrollar debido a los problemas técnicos encontrados. o Centrarse más en el estudio del framework de Odoo para poder llevar a cabo los objetivos
planteados. o Reconducir el rumbo del TFG dadas las dificultades técnicas encontradas. o Seguir con el estudio del framework de Odoo. o Seguir en comunicación vía email para resolver las dudas sobre los problemas que vayan
surgiendo. o Plantear una nueva reunión (sin fecha determinada) con SDI para explicar las dificultades que
Eduardo ha encontrado hasta ahora.
Próxima reunión No acordada
Página 66 de 129
ACTA 4
Lugar Día: 29-04-2015
Oficina Logroño SDI Soluciones Informáticas Avda. Zaragoza 7, 26006, Logroño (La Rioja)
Hora de comienzo: 10:00 h
Duración: 1 hora
Convocada por Eduardo Basalo Peña
Convocados Eduardo Basalo Peña
José Víctor Gómez
Asistentes Eduardo Basalo Peña
José Víctor Gómez
Pablo García (empleado de SDI en su oficina de Calahorra), vía telefónica
No asistentes
Director de la reunión Eduardo Basalo Peña
Apuntador Eduardo Basalo Peña
Orden del día
Mostrar el avance en el TFG.
Mostrar el funcionamiento de Odoo.
Mostrar el módulo de prueba de Odoo desarrollado por Eduardo, basado en una aplicación cuya funcionalidad está basada en organizar tareas por hacer.
Exponer las dificultades encontradas por Eduardo en cuanto al desarrollo técnico del CRM y Odoo, y la escasa documentación técnica para desarrolladores existente.
Exposición de nuevos objetivos, recomendando reducción de funcionalidades en el CRM a desarrollar.
Intercambio de ideas y conocimientos técnicos sobre el framework de Odoo.
Planteamiento de la reconducción del rumbo del TFG dadas las dificultades técnicas encontradas.
Puntos tratados
Eduardo Basalo expone:
o El avance en el TFG hasta el momento actual.
o El funcionamiento de Odoo, así como del módulo que Eduardo ha realizado, basado en una
aplicación para registrar tareas por hacer dentro de Odoo.
o Los conocimientos técnicos adquiridos acerca del framework de Odoo.
o Dificultades técnicas encontradas para desarrollar el CRM sobre Odoo, sobre todo debido a la
escasa documentación encontrada y la dificultad del framework que Odoo ofrece para programar
módulos.
o Planteamiento de reducción de funcionalidades a incorporar en el CRM debido al punto anterior.
o Proceso a seguir a partir del momento de esta reunión.
José Víctor Gómez expone:
o Propuesta de reconducir el TFG, reduciendo drásticamente las funcionalidades del CRM a
Página 67 de 129
desarrollar.
o Comprensión de las dificultades encontradas por Eduardo en el estudio para la programación de
módulos sobre Odoo.
o La situación actual de SDI respecto a Odoo, cuáles son sus planes de futuro y el estudio que hasta
ahora han realizado sobre esta plataforma ERP.
Pablo expone:
o Los conocimientos sobre el funcionamiento de Odoo.
o Comentar que todavía no ha estudiado nada acerca del framework de Odoo, con lo que no puede
prestar ayuda técnica a Eduardo.
Asuntos acordados
Acotar las funcionalidades del CRM a desarrollar debido a los problemas técnicos encontrados.
José Víctor Gómez da total libertad a Eduardo para redefinir los requisitos del CRM, y le comenta que SDI no exigirá ningún tipo de resultado en la calidad final del software.
Centrarse más en el estudio del framework de Odoo para poder llevar a cabo los objetivos replanteados.
Seguir con el estudio de este framework.
Seguir en comunicación vía email para resolver las dudas sobre los problemas que vayan surgiendo.
Plantear una nueva reunión (sin fecha determinada) para mostrar el avance y mostrar el progreso en la adquisición de los conocimientos técnicos necesarios.
Próxima reunión No acordada
Página 68 de 129
ACTA 5
Lugar Día: 3-06-2015
Oficina Calahorra SDI Soluciones Informáticas C/ Cavas 35-37, Calahorra (La Rioja)
Hora de comienzo: 10:30 h
Duración: 1 hora
Convocada por José Víctor Gómez
Convocados Eduardo Basalo Peña
José Víctor Gómez
Pablo García
Asistentes Eduardo Basalo Peña
José Víctor Gómez
Varios empleados de SDI en Calahorra involucrados en Odoo, entre ellos África Méndez, administradora del CRM Vtiger que SDI venía usando hasta ahora
No asistentes Pablo García
Director de la reunión José Víctor Gómez
Apuntador Eduardo Basalo Peña
Orden del día
Mostrar el funcionamiento de Odoo.
Exponer las dificultades encontradas por Eduardo en cuanto al desarrollo técnico del CRM y Odoo, y la
escasa documentación técnica para desarrolladores existente.
Intercambio de ideas y conocimientos técnicos sobre el framework de Odoo con Pablo García.
Puntos tratados
Eduardo Basalo expone:
o Intercambio de ideas sobre las dudas surgidas en el manejo de un CRM con África.
o El funcionamiento de Odoo a los empleados de SDI en Calahorra.
o Los conocimientos técnicos adquiridos acerca del framework de Odoo.
o Dificultades técnicas encontradas para desarrollar el CRM sobre Odoo, sobre todo debido a la
escasa documentación encontrada y la dificultad del framework que Odoo ofrece para programar
módulos.
o Intercambio de ideas con los desarrolladores de software involucrados en Odoo en SDI Calahorra.
Empleados SDI en Calahorra (excepto África Méndez) exponen:
o Modo de trabajo general en SDI.
o Sus conocimientos funcionales sobre el manejo de Odoo.
o Sus conocimientos técnicos adquiridos sobre el manejo del framework de Odoo.
o Las dificultades técnicas que han encontrado hasta ahora.
Página 69 de 129
África Méndez expone:
o La manera de trabajar con VTiger mediante una pequeña demo.
o Resuelve las dudas de Eduardo en cuanto a la manera con la que SDI trabaja en lo que respecta al
trato con clientes.
o Resuelve las dudas de Eduardo en cuanto a la manera en que ella trabaja con el CRM VTiger.
o Las funcionalidades que desearía conservar de VTiger, así como las que le gustaría incorporar o
mejorar.
Asuntos acordados
Seguir con el estudio del framework de Odoo.
Avanzar con el desarrollo de funcionalidades en el CRM a desarrollar a medida que los conocimientos técnicos sobre programación en Odoo aumenten.
Dotar a Eduardo de acceso online a VTiger desde cualquier ubicación geográfica.
África enviará a Eduardo toda la documentación que obra en su poder acerca del manejo de VTiger, así como de los datos que necesitaría registrar de cada entidad (empresas, clientes, oportunidades, tareas de comerciales, etc).
Seguir en comunicación vía email con África para resolver las dudas en todo lo que concierne al manejo de VTiger y modo de trabajar en SDI con sus clientes.
Seguir en comunicación vía email con José Víctor para resolver las dudas que vayan surgiendo.
Plantear una nueva reunión (sin fecha determinada) para mostrar el avance del TFG y mostrar el progreso en la adquisición de los conocimientos técnicos necesarios.
Próxima reunión No acordada
Página 70 de 129
ACTA 6
Lugar Día: 29-06-2015
Universidad de La Rioja Hora de comienzo: 17:30 h
Duración: 1 hora y 30 minutos
Convocados Eduardo Basalo Peña
Ana Romero Ibáñez
Convocada por Ana Romero Ibáñez
Asistentes Eduardo Basalo Peña
Ana Romero Ibáñez
No asistentes
Director de la reunión Eduardo Basalo Peña
Apuntador Eduardo Basalo Peña
Orden del día
Mostrar el progreso del TFG.
Mostrar una demo del CRM desarrollado hasta el momento.
Dudas respecto a la gestión del TFG y el desarrollo de la memoria de éste.
Acordar la planificación final del TFG hasta el momento de su depósito.
Puntos tratados
Eduardo Basalo expone:
o Dudas relacionadas con la gestión del TFG: metodología, plazos, planificación restante, diagramas
de Gantt y UML, etc.
o Dudas sobre la elaboración de la memoria del TFG.
o Una demo mostrando el CRM sobre Odoo desarrollado hasta el momento.
o Expone que hasta ahora ha realizado una versión del CRM que usa tanto el framework de
OpenERP de la versión 7, así como el framework de la versión 8 de Odoo, ya que de esta manera
ha podido encontrar en Internet mayor cantidad de respuestas a sus dudas técnicas, debido a que
existe mayor información sobre la versión 7 del framework que sobre la versión 8.
o Plantea incorporar nuevas funcionalidades al CRM si tiene el tiempo necesario antes del depósito:
Tratamiento de productos.
Presupuestos a clientes.
Creación de campañas de marketing.
o Plantea suprimir las funcionalidades desarrolladas sobre el CRM que en el momento actual no
funcionan correctamente.
o Su planificación restante del TFG hasta el momento del depósito.
Ana Romero expone:
Página 71 de 129
o Resuelve las dudas de Eduardo respecto a la gestión del TFG, así como de la memoria.
o Expone la planificación final del TFG hasta el momento del depósito.
Asuntos acordados
Seguir mejorando el CRM hasta que las fechas de entrega lo permitan.
Desarrollar la memoria del TFG.
Acordar que la fecha máxima para mostrar a Ana la memoria terminada debe ser el 17 de julio.
Acordar también que el 17 de julio, el software CRM debería estar casi terminado para mostrar la demo definitiva a Ana Romero.
Seguir en contacto con Ana vía email para resolver las dudas surgidas en el desarrollo de la elaboración de la memoria.
Próxima reunión Entre el 16 y 20 de Julio
Página 72 de 129
ACTA 7
Lugar Día: 17-07-2015
Universidad de La Rioja Hora de comienzo: 11:00 h
Duración: 1 hora
Convocados Eduardo Basalo Peña
Ana Romero Ibáñez
Convocada por Eduardo Basalo Peña
Asistentes Eduardo Basalo Peña
Ana Romero Ibáñez
No asistentes
Director de la reunión Eduardo Basalo Peña
Apuntador Eduardo Basalo Peña
Orden del día
Mostrar una demo de la versión final de la aplicación
Puntos tratados
Eduardo Basalo expone:
o Muestra de una demo de la versión final de la aplicación.
Ana Romero expone:
o Reclamación de entrega de la memoria del TFG antes del día 20 de julio de 2015.
Asuntos acordados
Entrega de la memoria del TFG antes del día 20 de julio de 2015 para su posterior corrección antes del depósito del TFG.
Posible próxima reunión para discutir las posibles correcciones de la memoria. Es posible que la reunión sea sustituida por comunicaciones por email.
Próxima reunión No acordada
Página 73 de 129
ACTA 8
Lugar Día: 21-07-2015
Oficina Logroño SDI Soluciones Informáticas Avda. Zaragoza 7, 26006, Logroño (La Rioja)
Hora de comienzo: 10:15 h
Duración: 1 hora
Convocados Eduardo Basalo Peña
José Víctor Gómez
Convocada por Eduardo Basalo Peña
Asistentes Eduardo Basalo Peña
José Víctor Gómez
No asistentes
Director de la reunión Eduardo Basalo Peña
Apuntador Eduardo Basalo Peña
Orden del día
Mostrar una demo de la versión final de la aplicación
Puntos tratados
Eduardo Basalo expone:
o Muestra de una demo de la versión final de la aplicación.
José Víctor Gómez expone:
o Da su visto bueno a la aplicación.
Asuntos acordados
Mantener comunicado a José Víctor sobre la evolución del depósito del TFG, así como de si finalmente Eduardo consigue obtener la titulación de graduado en Ingeniería Informática.
Próxima reunión No acordada
Página 74 de 129
ACTA 9
Lugar Día: 24-02-2015
Universidad de La Rioja Hora de comienzo: 10:15 h
Duración: 45 minutos
Convocada por Ana Romero Ibáñez
Convocados Eduardo Basalo Peña
Ana Romero Ibáñez
Asistentes Eduardo Basalo Peña
Ana Romero Ibáñez
No asistentes
Directora de la reunión Ana Romero Ibáñez
Apuntador Eduardo Basalo Peña
Orden del día
Explicaciones de fallos cometidos en la redacción de la memoria
Puntos tratados
Ana Romero expone:
o Los principales fallos cometidos por el alumno en la redacción de la memoria del TFG
o Las correcciones que éste debe acometer en ella
Asuntos acordados
Eduardo Basalo Peña deberá corregir los fallos cometidos en la memoria del TFG y entregarla corregida antes del lunes a su tutora
Próxima reunión No acordada
Página 75 de 129
Anexo II. Descripción Estructura de Desglose del Trabajo (EDT)
TFG CRM Odoo
Descripción tarea
1. Gestión del TFG
1.1. Seguimiento del TFG Conjunto de tareas para controlar su avance y cumplimiento de requisitos.
1.1.1. Reuniones Encuentros periódicos entre alumno y tutor del TFG, y entre el alumno y SDI (cliente).
1.1.2. Gestión de cambios Control para reelaborar la planificación y gestión del TFG frente a problemas imprevistos como cambio del alcance o agotamiento de plazos de entrega.
1.1.3. Control de calidad Revisión periódica de la correcta evolución del TFG, de su gestión y del cumplimiento de requisitos de la aplicación.
1.2. Elección herramientas gestión TFG Estudio previo para elección y manejo de herramientas necesarias para la realización de tareas propias de gestión de un TFG, como por ejemplo, software para realizar diagramas UML, diagramas de bases de datos o prototipos de la interfaz.
1.3. Generación del DOP Estudio previo para conocer en qué consiste un DOP y su posterior redacción.
1.4. Creación EDT Estudio previo para saber en qué consiste un EDT y su posterior realización para la descomposición de las tareas de las que consta este TFG.
1.5. Planificación temporal inicial Estimación temporal de los plazos para conseguir la realización de cada una de las partes de las que consta el EDT. Realización de diagramas de Gantt.
1.6. Replanificación temporal Reestimación temporal de los plazos de realización de tareas del EDT debido a dos motivos:
Mala estimación de tiempo para la fase de formación. Necesario más tiempo
Dificultades técnicas encontradas para el desarrollo de la aplicación sobre Odoo. Debido a esto, se hace necesario replanificar el TFG cambiando la fecha tope de entrega. El fin del
Página 76 de 129
primer plazo de entrega era el día 20 de junio de 2015, y se hace necesario usar el segundo plazo que termina el día 27 de julio de 2015.
1.7. Memoria TFG Elaboración de la memoria del TFG.
1.7.1. Estudio previo Estudio previo a la redacción de la memoria para conocer qué secciones y contenido debe tener. Incluye estudio de otros Proyectos Fin de Carrera o Trabajos Fin de Grado.
1.7.2. Estructuración memoria En base al estudio previo, análisis de los apartados que debe constar esta memoria, además del contenido que se debe incluir en cada uno de ellos.
1.7.3. Redacción memoria Incluye la redacción de la memoria, así como el aprendizaje de las herramientas usadas para su redacción.
1.7.4. Revisión memoria Corrección de posibles fallos tanto de su estructura o contenido, o errores gramaticales cometidos.
1.8. Defensa TFG Incluye todas las tareas necesarias para elaborar y preparar la defensa del TFG frente al Tribunal de Evaluación.
1.8.1. Creación presentación Creación de la presentación para la defensa del TFG ante el Tribunal. Incluye la elección y aprendizaje de las herramientas software necesarias para la elaboración de dicha presentación.
1.8.2. Preparación defensa Preparación de la presentación oral de defensa del TFG ante el Tribunal.
1.8.3. Defensa ante Tribunal Exposición ante el Tribunal de Evaluación de la presentación del TFG.
2. Formación
2.1. Búsqueda documentación Odoo Investigación y recopilación de todos los recursos en Internet disponibles para conocer todo acerca de Odoo: qué es, cómo se instala o maneja, documentación para desarrolladores, foros, guías, libros y en general cualquier ayuda que se necesite.
2.2. Instalación Odoo Investigación de todos los recursos disponibles en Internet para saber cómo instalar Odoo tanto en Windows como en Linux, así como las mejores maneras de instalación.
2.3. Estudio Python Formación en Python, sobre todo en lo que respecta a programación orientada a objetos.
Página 77 de 129
2.4. Lectura preliminar documentación oficial Odoo Lectura inicial de toda la documentación en la página web oficial de Odoo, sobre todo documentación para desarrolladores pero también toda aquella necesaria para el manejo de esta plataforma ERP.
2.5. Lectura libro 'Odoo Development Essentials'
Lectura al completo del libro 'Odoo Development Essentials' para saber cómo desarrollar módulos para Odoo.
2.6. Relectura documentación oficial Odoo Lectura de forma más detenida de la documentación para desarrolladores de la web oficial de Odoo.
2.7. Recopilación de documentación encontrada sobre Odoo
Recopilación de todos los recursos encontrados en Internet, no presentes en la documentación oficial, para el desarrollo de módulos dentro de Odoo.
3. Análisis
3.1. Análisis de requisitos del cliente Estudio de los requisitos funcionales de la aplicación planteados por el cliente. Análisis de la viabilidad de los requisitos anteriores. Elección de los requisitos que son factibles de realizar.
3.2. Análisis de requisitos del proyectante Estudio de los requisitos funcionales de la aplicación sugeridos por el proyectante. Análisis de la viabilidad de los requisitos anteriores. Elección de los requisitos que son factibles de realizar.
3.3. Reasignación de requisitos (priorización) Realizar un filtrado de los requisitos funcionales acordados en una fase anterior, desechando aquellos que exigen una complejidad elevada en cuanto que el proyectante no puede llevarlos a cabo dado sus conocimientos técnicos de Odoo.
3.4. Diagramas UML Incluye la elaboración de todos aquellos diagramas UML que sirvan para que proyectante y cliente conozcan mejor los requisitos del CRM a desarrollar.
3.4.1. Diagramas de casos de uso Elaboración de diagramas que expliquen las funciones que cada usuario de la aplicación puede realizar en ella.
3.4.2. Diagramas de actividad Elaboración de diagramas para mostrar el flujo de acciones que el usuario realiza sobre la aplicación. Sólo se elaborarán diagramas para explicar el flujo en los casos de uso que sean más complicados de entender.
3.5. Revisión fase de análisis Revisión de la calidad de los entregables producidos durante la fase de análisis.
Página 78 de 129
4. Diseño
4.1. Estudio arquitectura del sistema Odoo Descripción de cuál es la arquitectura interna del sistema Odoo, así como de su framework y los módulos que pueden ser programados con él.
4.2. Arquitectura del módulo CRM Descripción de la arquitectura interna del módulo CRM. Necesario para comprender los diagramas de clases UML a desarrollar.
4.3. Diseño clases ORM Descripción de los modelos (clases) que forman parte del módulo CRM, así como su relación con el framework que Odoo posee, y su enlace con la base de datos.
4.4. Diagramas UML Elaboración de diagramas UML que modelen el diseño del CRM.
4.4.1. Diagramas de clases Elaboración de diagramas de clases que modelen la composición de los modelos (clases) que componen el CRM, así como de las relaciones entre ellas.
4.5. Diagramas base de datos Elaboración de los diagramas de bases de datos resultantes del mapeo realizado por el ORM.
4.6 Creación de prototipos de la interfaz Si se considera necesario, elaboración de los prototipos de la interfaz gráfica de la aplicación.
4.7. Revisión fase de diseño Revisión de la calidad de los entregables producidos durante la fase de desarrollo para iniciar la fase de implementación de la aplicación.
5. Construcción
5.1 Tecnologías utilizadas Descripción de las tecnologías, lenguajes, herramientas y librerías usadas para el desarrollo del CRM.
5.2. Parametrización e implementación clases ORM Parametrización de la aplicación, es decir, creación de todos los datos que contendrá cada entidad, modelo o clase de la aplicación.
5.3. Implementación lógica de modelos Creación de todos los métodos necesarios para dotar de lógica de negocio a cada modelo de la aplicación.
5.4. Construcción acciones automatizadas Creación de acciones automatizadas para que la aplicación reaccione de forma automática a ciertos eventos bajo una serie de condiciones.
5.5. Creación estructura de menús Creación de la estructura de menús.
Página 79 de 129
5.6. Implementación de vistas Implementación de los prototipos de la interfaz gráfica.
5.7. Revisión fase construcción Revisión de la calidad de los entregables producidos durante la fase de construcción.
6. Pruebas
6.1. Elección método de pruebas Estudio de las alternativas para testear la aplicación, bien sea de forma manual o automatizada.
6.2. Diseño pruebas Elaboración de los posibles casos de prueba.
6.3. Ejecución pruebas Ejecución de los casos de prueba.
6.4. Corrección errores en código fuente Corrección de errores en el código fuente de la aplicación frente a los casos de prueba fallidos.
7. Manuales
7.1. Manual de instalación módulo CRM Odoo Elaboración del manual de instalación tanto de Odoo como del módulo CRM.
7.2. Manual de usuario Elaboración del manual de usuario de la aplicación.
Página 80 de 129
Anexo III. Diagrama de Gantt
Página 81 de 129
Anexo IV: Diagramas de casos de uso completos
1. Diagramas de uso con las funcionalidades relacionadas con la gestión de empresas
2. Diagrama de uso con las funcionalidades relacionadas con la gestión de campañas de marketing
Página 82 de 129
3. Diagrama de uso con las funcionalidades relacionadas con la gestión de llamadas
4. Diagrama de uso con las funcionalidades relacionadas con la gestión de reuniones, visitas y demos
Página 83 de 129
5. Diagrama de uso con las funcionalidades relacionadas con la gestión de presupuestos
6. Diagrama de uso con las funcionalidades relacionadas con la gestión de oportunidades
Página 84 de 129
7. Diagrama de uso con las funcionalidades relacionadas con la gestión de productos.
8. Diagrama de uso con las funcionalidades relacionadas con el sistema de mensajería
Página 85 de 129
NOTA:
El diagrama anterior está dentro de uno de los Anexos de la memoria porque el 99 % de la funcionalidad
descrita en él ya viene incorporada en Odoo.
Como programador, sólo he tenido que realizar dos cosas para disfrutar de un sistema de mensajería
dentro de mi aplicación:
Cada modelo de mi módulo en el que quisiera disponer de las funcionalidades de este sistema de mensajería debe heredar de una clase proporcionada por el núcleo de Odoo.
En cada vista de cada uno de los modelos en los que quisiera disponer de las funcionalidades de este sistema de mensajería, debo introducir cuatro líneas de código dentro de la vista de tipo formulario.
A continuación resumo las principales funcionalidades descritas en el anterior diagrama de casos de uso:
El usuario puede crear grupos dentro del sistema de mensajería y unirse a ellos.
El usuario puede enviar un mensaje a cualquier grupo en los que esté suscrito.
El usuario tiene un buzón de mensajes donde almacenar los mensajes que le han enviado el resto de usuarios, o los que ha marcado como favoritos.
Cada formulario de instancia de cada entidad en la aplicación (por ejemplo una empresa ya registrada) incorpora una sección al pie de éste que permite ver los cambios que ha experimentado esta instancia (empresa) en los valores de sus campos desde que ésta se creó, y dejar mensajes para que puedan verlos los seguidores de esta instancia o sólo él de forma privada.
El usuario que cree la instancia podrá añadir seguidores a ésta, de modo que cada uno de ellos tenga permiso para poder ver los cambios de cada instancia.
9. Diagrama de uso con las funcionalidades relacionadas con la gestión de comerciales
Página 86 de 129
Anexo V. Diagrama de bases de datos
IMPORTANTE:
La tabla llamada res_partner corresponde al modelo Empresa.
La tabla llamada crm_phonecall corresponde al modelo Llamada.
La tabla llamada calendar_event corresponde al modelo que representa las reuniones, demos y visitas.
La tabla llamada crm_lead corresponde al modelo Oportunidad.
Ya expliqué anteriormente en esta memoria que el usar un ORM hace que todos los atributos simples de
cada clase vayan a ser mapeados a una columna en la tabla. La clase se convertirá en una tabla y cada uno
de sus campos simples en una columna.
La clave está en saber cómo se mapean las relaciones entre clases. Aquí entran en juego los atributos de
tipo Many2one, Many2many y One2many de cada una de ellas.
Un atributo' a' de tipo Many2one de un modelo (clase) 'A' relacionada con un modelo B se mapea como una columna en la tabla 'A' que es una clave foránea hacia el modelo B con el que está relacionado este atributo. Esta columna es una clave foránea hacia la clave principal de la tabla a la columna 'id' (clave principal) de la tabla a la que se mapea el modelo B.
Un atributo 'a' de tipo Many2many de un modelo (clase) 'A' que está relacionado con un modelo 'B', se mapea como una tabla adicional que relaciona este modelo 'A' con el modelo 'B'. Esta tabla está formada por dos columnas, la primera es una clave foránea hacia la tabla 'B' y la segunda una clave foránea hacia la tabla 'A'.
Un atributo 'a' de tipo One2many de un modelo 'A' está relacionado con el modelo 'B'. La tabla del modelo 'B' tendrá una clave foránea hacia la tabla del modelo A, pero no a la inversa.
Página 87 de 129
Diagrama 1. Se centra en las relaciones de la tabla 'calendar_event', asociada a demos, reuniones y visitas en la aplicación.
Página 88 de 129
Diagrama 2. Se centra en las relaciones de la tabla 'crm_lead' que
corresponde a las oportunidades en la aplicación
Página 89 de 129
Diagrama 3. Se centra en las relaciones de la tabla 'crm_phonecall' correspondiente a las llamadas en la aplicación
Página 90 de 129
Diagrama 4. Se centra en las relaciones de la tabla 'sdicrm_company' que representa a las empresas en la aplicación
Página 91 de 129
Diagrama 5. Se centra en las relaciones de la tabla 'sdicrm_marketing_campaign que representa a las campañas de marketing en la aplicación
Página 92 de 129
Diagrama 6. Se centra en las relaciones de las tablas relacionadas con productos en la aplicación
Página 93 de 129
Diagrama 7. Se centra en las relaciones de la tabla 'sdicrm_quote' que representa a los presupuestos en la aplicación.
Página 94 de 129
A continuación muestro la estructura de columnas y tipos de las principales tablas de la aplicación,
básicamente todas excepto las que sirven para asociar dos tablas con una relación muchos a muchos.
Sólo muestro las columnas y tipos. Las relaciones están recogidas en los diagramas anteriores.
ACLARACIONES INICIALES:
Hay que tener en cuenta que algunas columnas en las tablas siguientes son introducidas automáticamente
por Odoo, no figuran definidas como campos en mis modelos (clases Python) de la aplicación.
Esto se debe a dos motivos: el primero ya lo expliqué anteriormente en esta memoria, y se debe a que
cualquier modelo definido en Odoo hereda de un modelo padre. Mis módulos heredan los campos de
éste, y estos campos son mapeados a columnas en la tabla que corresponde a mi modelo.
El segundo motivo es que en mi CRM hago uso de modelos ya existentes en Odoo, que ya poseen sus
tablas. En el caso de mi modelo ‘Company’, se da el caso de que hereda de un modelo ya existente en
Odoo llamado ‘res_partner’ que también representa una compañía. La herencia se hace por extensión (ya
se explicó en la memoria). Debido a este tipo de herencia, el ORM de Odoo mapea los campos de mi
modelo ‘Company’ en nuevas columnas de la tabla ‘res_partner’, así no tengo dos tablas diferentes para
representar una empresa.
Tabla 'res_partner': corresponde a lo que sería Empresa.
Página 95 de 129
Tabla 'sdicrm_company_type': representa un tipo de empresa.
Tabla 'sdicrm_company_affiliation': representa un nombre de afiliado a una empresa.
Tabla 'sdicrm_company_sector': representa un sector empresarial
Tabla 'sdicrm_company_locationoffice': representa una sede de una compañía, con dirección, teléfono
y email.
Tabla 'sdicrm_company_zone': representa un nombre de zona donde una empresa puede operar.
Tabla 'sdicrm_company_maker': representa una empresa fabricante de un producto.
Tabla 'sdicrm_contact_maker: representa una persona que actúa de contacto de la anterior tabla.
Tabla 'sdicrm_company_email': permite guardar varios emails para cada empresa.
Tabla 'sdicrm_company_source_lead': representa un nombre que indica cómo se conoció la empresa
(una base de datos, una conferencia, etc).
Página 96 de 129
Tabla 'calendar_event': representa a lo que yo he llamado en mi aplicación cita (demo, reunión o visita
con un cliente).
Es una tabla que ya incorpora Odoo con sus propias columnas, y que yo he aprovechado para añadir las
mías. Yo no las añado manualmente, lo hace el ORM a partir de los atributos que yo defino en mi modelo
correspondiente a esta tabla en Python (ver explicación al comienzo de la página 95).
Tabla 'sdicrm_marketing_campaign': representa a una campaña de marketing.
Tabla 'sdicrm_marketing_campaing_type': representa a un tipo de campaña de marketing.
Página 97 de 129
Tabla 'crm_lead': representa a una oportunidad.
Es una tabla que ya incorpora Odoo con su propias columnas, y que yo he aprovechado para añadir las
mías. Yo no las añado manualmente, lo hace el ORM a partir de los atributos que yo defino en mi modelo
Oportunidad en Python (ver explicación al comienzo de la página 95).
Tabla 'crm_case_stage': representa a una fase donde se puede categorizar una oportunidad.
Página 98 de 129
Tabla 'crm_phonecall': representa una llamada.
Es una tabla que ya incorpora Odoo con su propias columnas, y que yo he aprovechado para añadir las
mías. Yo no las añado manualmente, lo hace el ORM a partir de los atributos que yo defino en mi modelo
Llamada en Python (ver explicación al comienzo de la página 95).
Página 99 de 129
Tabla 'sdicrm_quote': representa a un presupuesto.
Tabla 'sdicrm_quote_line': representa a una línea de un presupuesto.
Tabla 'sdicrm_product_software': representa a un producto de tipo software
Tabla 'sdicrm_software_category': representa una categoría de software
Tabla 'sdicrm_software_subscription': representa una subscripción a un producto software. Es la
modalidad de compra de software por subscripción.
Página 100 de 129
Tabla 'sdicrm_software_support': representa a un servicio de tipo soporte de software, es decir, soporte
prestado a un software determinado.
Tabla 'sdicrm_support_software_subscription': representa una subscripción a un servicio de soporte
determinado. En vez de adquirir un servicio de soporte perpetuo, el cliente adquiere un servicio de
soporte durante x meses.
Página 101 de 129
Tabla 'sdicrm_software_maintenance': representa a un servicio de tipo mantenimiento de software, es
decir, mantenimiento prestado a un software determinado.
Tabla 'sdicrm_ maintenance_subscription': representa una subscripción a un servicio de mantenimiento
determinado. En vez de adquirir un servicio de mantenimiento perpetuo, el cliente adquiere un servicio
de mantenimiento durante x meses.
Tabla 'sdicrm_ salesperson': representa un comercial de la empresa que usa el CRM.
Página 102 de 129
Anexo VI. Glosario
ERP
Son las siglas en inglés de 'Enterprise Resource Planning', sistemas de planificación de recursos
empresariales en español.
En realidad es una estrategia empresarial para gestionar todos los procesos de negocio involucrados en
una empresa.
Aunque lo normal es que cuando se dice 'ERP' se asocie a un software que permite gestionar de forma
automatizada todos los procesos empresariales dentro de una compañía.
MVC
Es un patrón clásico del diseño web que está formado por tres niveles:
El Modelo representa la información con la que trabaja la aplicación, es decir, su lógica de negocio.
La Vista transforma el modelo en una página web que permite al usuario interactuar con ella.
El Controlador se encarga de procesar las interacciones del usuario y realiza los cambios apropiados en el modelo o en la vista.
SQL
SQL son las siglas de ‘Structured Query Language’ (Lenguaje estructurado de consultas) y se usa para
realizar operaciones con una base de datos de tipo relacional.
HTML
HTML, siglas de HyperText Markup Language (lenguaje de marcas de hipertexto), hace referencia al
lenguaje de marcado para la elaboración de páginas web.
API
Son las siglas de 'Application Programming Interface' en inglés, o interfaz de programación de aplicaciones
en español, y es el conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación
orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de
abstracción.
SGBD
Son las siglas de Sistema de gestión de base de datos o en inglés 'Database Management System' (DBMS),
y es una agrupación de programas que sirven para definir, construir y manipular una base de datos.
ORM
ORM son las siglas en inglés de 'Object-relational Mapping' o mapeo de objetos a bases de datos en
español.
Es una interfaz que traduce la lógica de los objetos a la lógica relacional para acceder a la base de datos
como si fuera orientada a objetos.
Un ORM consiste en una serie de objetos que permiten acceder a los datos y que contienen en su interior
cierta lógica de negocio.
Una de las ventajas de utilizar estas capas de abstracción de objetos/relacional es que evita utilizar una
sintaxis específica de un sistema de bases de datos concreto. Esta capa transforma automáticamente las
llamadas a los objetos en consultas SQL optimizadas para el sistema gestor de bases de datos que se está
utilizando en cada momento.
La capa de abstracción utilizada encapsula toda la lógica de los datos. El resto de la aplicación no tiene
que preocuparse por las consultas SQL.
JSON
JSON es un formato de texto para intercambio de datos, tal como XML, sólo que mucho más liviano. JSON
está construido en dos estructuras:
Página 103 de 129
- Una colección de pares nombre/valor: Objeto.
- Una lista de Valores ordenada: Colecciones.
RPC
La Llamada a Procedimiento Remoto (RPC) (del inglés, ‘Remote Procedure Call’) es un protocolo que
permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse
por las comunicaciones entre ambos.
JSON-RPC
Es un protocolo de llamada a procedimiento remoto que gestiona los datos a enviar y recibir del servidor
en formato JSON y que usa HTTP como protocolo de transmisión de mensajes.
XML-RPC
XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP
como protocolo de transmisión de mensajes.
JQuery
jQuery es una biblioteca de JavaScript, creada inicialmente por John Resig, que permite simplificar la
manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar
animaciones y agregar interacción con la técnica AJAX a páginas web.
Qweb
Es un motor de plantillas usado en el framework de Odoo que permite generar fragmentos y páginas en
HTML a partir de un lenguaje especial de tipo XML.
Git
Git es un sistema de control de versiones distribuido cuyo objetivo es el de permitir mantener una gran
cantidad de código a una gran cantidad de programadores eficientemente.
GitHub
GitHub es una plataforma de desarrollo colaborativo para alojar proyectos de forma online utilizando el
sistema de control de versiones Git.
Página 104 de 129
Anexo VII. Manual de instalación de Odoo
Este Anexo recoge un pequeño manual para la instalación de Odoo en un sistema operativo Linux Ubuntu.
Paso 1.
Crear un usuario odoo en Ubuntu y establecer su contraseña de ‘login’.
Podemos usar el usuario con el que estemos autenticados en Ubuntu. En este caso, se puede omitir los
pasos 1 y 2.
Para crear el usuario ejecutar el siguiente comando en la consola de comandos del Sistema Operativo:
sudo adduser --system --home=/opt/odoo --group odoo
Paso 2.
Autenticarse con el usuario odoo
sudo su - odoo -s /bin/bash
Si se quiere ejecutar Odoo desde la consola de comandos, antes siempre es necesario autenticarse como
el usuario de Ubuntu odoo con el comando anterior.
Paso 3.
Instalar el SGDB PostgreSQL mediante el siguiente comando:
sudo apt-get install postgresql
Paso 4.
Crear un usuario en postgreSQL y darle una contraseña mediante los siguientes comandos:
sudo su - postgres
createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt odoo
Después, salir de la sesión del usuario odoo en la shell con el siguiente comando:
exit
Si no queremos usar el usuario odoo de Ubuntu, podemos crear un superusuario en PostgreSQL con el
usuario con el que estemos autenticados en Ubuntu. En ese caso, para crear dicho superusuario, debemos
ejecutar el siguiente comando:
sudo su - postgres -c "createuser -s $USER"
Paso 5.
Instalar git en Ubuntu mediante sl siguiente comando:
sudo apt-get install git
Paso 6.
Descargar desde github el repositorio de Odoo donde está su código fuente en nuestro directorio creado
anteriormente: /home/odoo/odoo-dev. Ejecutar lo siguientes comandos:
sudo su - odoo -s /bin/bash
mkdir odoo_server
cd odoo_server
git clone https://www.github.com/odoo/odoo --depth 1 --branch 8.0 --single-branch .
Paso 7.
Crear un entorno virtual Python con virtualenv, y posteriormente instalar dependencias de Odoo en este
entorno virtual.
Para crear el entorno virtual ejecutar este comando:
virtualenv venv_oddo
Página 105 de 129
Activamos el entorno virtual:
source venv_oddo/bin/activate
Descargar el fichero requirements.txt que contiene las dependencias que Odoo necesita de la URL que
indica el siguiente comando:
wget https://raw.githubusercontent.com/odoo/odoo/8.0/requirements.txt
Después, instalar con pip las dependencias necesarias usando el fichero requirements.txt.
Previamente es necesario instalar algunos paquetes en Ubuntu necesarios para instalar las dependencias
de este fichero. Para ello, ejecutar estos comandos. Cada uno instala una librería o componente usado
por Odoo.
sudo apt-get install python-dev
sudo apt-get install postgresql-server-dev-9.3
sudo apt-get install libxml2-dev
sudo apt-get install libxslt1-dev
sudo apt-get install libevent-dev
sudo apt-get install libsasl2-dev
sudo apt-get install libldap2-dev
Además, para usar la librería python Pyllow que Odoo utiliza, es necesario instalar en Ubuntu los
siguientes paquetes (hacerlo con un usuario en Ubuntu que pueda ejecutar sudo, es decir, que tenga
permisos de root). El usuario odoo que creamos al principio del tutorial no puede usar sudo, así que hay
que abrir otra consola de comandos en Ubuntu e instalar los siguientes paquetes desde ahí):
sudo apt-get install libjpeg8-dev libjpeg-turbo8 libjpeg8 libjpeg-dev libjpeg-turbo8-dev libfreetype6-dev
libfreetype6 zlib1g zlib1g-dev libpng12-dev libpng12-0
Si no hacemos esto, no podremos crear una base de datos en Odoo.
Seguidamente instalamos las dependencias de Odoo desde el fichero requirements.txt.
pip install -r requirements.txt
Hay que instalar también otras dependencias necesarias para algunos módulos de Odoo. Para ello,
ejecutar estos dos comandos:
pip install python-geoip
pip install pycups
Este último comando pip (pip install pycups) dará un error porque hay que instalar previamente el
paquete en Ubuntu libcups2-dev:
sudo apt-get install libcups2-dev
Ahora, desactivar el entorno virtual en el que estamos:
deactivate
Paso 8.
Después, hay que Instalar wkhtmltopdf en Ubuntu.
Lo primero es descargar el paquete .deb necesario para su instalación de la siguiente URL (en este caso es
para Ubuntu 14.04 de 32 bits):
http://downloads.sourceforge.net/project/wkhtmltopdf/0.12.2.1/wkhtmltox-0.12.2.1_linux-trusty-
i386.deb
Ejecutar el siguiente comando para su instalación:
sudo dpkg -i /home/eduardo/Downloads/wkhtmltox-0.12.2.1_linux-trusty-i386.deb
Página 106 de 129
Dará un error porque falta instalar un paquete en Ubuntu del que wkhtmltopdf depende: xfonts-75dpi.
Ejecutar el siguiente comando para satisfacer dependencias:
sudo apt-get install -f
Seguidamente ejecutar los siguientes comandos para volver a intentar la instalación de wkhtmltopdf:
sudo dpkg -i /home/eduardo/Downloads/wkhtmltox-0.12.2.1_linux-trusty-i386.deb
sudo cp /usr/local/bin/wkhtmltopdf /usr/bin
sudo cp /usr/local/bin/wkhtmltoimage /usr/bin
Paso 9.
Instalar el compilador CSS Less CSS via nodejs.
Previamente es necesario instalar nodejs y npm:
curl -sL https://deb.nodesource.com/setup_0.12 | sudo bash -
sudo apt-get install -y nodejs
Este último comando instala tanto nodejs como npm.
Después, instalar los paquetes de nodejs llamados less y less-plugin-clean-css:
sudo npm install -g less less-plugin-clean-css
Paso 10.
Ahora toca establecer la configuración inicial del fichero de configuración de Odoo llamado
odoo-server.conf.
Lo primero que hacer es salir de la sesión del usuario odoo de Ubuntu con este comando:
exit
Después, copiamos este fichero de configuración a su ubicación correcta y le damos los permisos
necesarios. Para ello, ejecutar los siguientes comandos:
sudo cp /opt/odoo/odoo_server/debian/openerp-server.conf /etc/odoo-server.conf
sudo chown odoo: /etc/odoo-server.conf
sudo chmod 640 /etc/odoo-server.conf
Con un editor de textos modificar el fichero /etc/odoo-server.conf.
Cambiar la línea 'db_password = False' (sin comillas) por 'db_password = odooroot' (sin comillas).
odooroot es la contraseña de conexión a postgresql que usamos al crear nuestro usuario en postgresql.
Cambiar el valor de 'addons_path = /usr/lib/python2.7/dist-packages/openerp/addons' por 'addons_path
= /opt/odoo/odoo_server/addons'.
El valor de addons_path indica la ruta al directorio donde se guardan los módulos que trae por defecto
odoo.
Podemos indicar varias rutas separadas por comas:
'addons_path = /home/odoo/odoo-dev/odoo/addons,/home/odoo/odoo-dev/misaddons,...' para indicar
varias directorios donde existan módulos.
Añadir la siguiente línea:
logfile = /var/log/odoo/odoo-server.log
odoo-server.log será el fichero donde odoo guardará sus logs.
¡IMPORTANTE!: hay que crear el directorio odoo dentro de /var/log/ antes de ejecutar odoo, sino los
mensajes de logs del sistema se escribirán en la consola de comandos. Para ello, ejecutar estos comandos:
sudo mkdir /var/log/odoo
sudo chown odoo:root /var/log/odoo
Página 107 de 129
Ahora mismo ya podríamos ejecutar Odoo desde la consola de comandos.
Como estamos usando un entorno virtual de Python, antes de ejecutar el servidor de Odoo tenemos que
activar dicho entorno virtual. Esto debe realizarse siempre antes de ejecutar Odoo en la consola de
comandos.
Para activar el entorno virtual, primero debemos autenticarnos con nuestro usuario odoo de Ubuntu, si
no lo estamos ya:
sudo su - odoo -s /bin/bash
Ahora activar el entorno virtual:
source odoo_server/venv_oddo/bin/activate
Y ahora, ya podemos ejecutar el servidor Odoo con el siguiente comando. Primero nos movemos al
directorio donde está el fichero que vamos a ejecutar.
cd odoo_server
Ahora ya podemos lanzar Odoo con este comando:
./openerp-server
o con este otro comando:
./odoo.py
Podemos probar el cliente de Odoo en nuestro navegador con la URL: http://127.0.0.1:8069/
En la consola de comandos podemos parar el servidor Odoo pulsando Ctrl+C.
IMPORTANTE:
Si no hemos configurado un fichero de configuración para Odoo, también podemos ejecutarlo indicando
en un comando una serie de argumentos. El comando más general para lanzar Odoo es el siguiente:
./odoo.py –addons-path=addons,../mis-addons –d test
donde el argumento –addons-path indica los directorios (separados por comas) donde tenemos alojados
los módulos que queramos que Odoo detecte, y donde el argumento –d indica el nombre de la BD que
queremos que Odoo use.
Página 108 de 129
Anexo VIII. Manual de instalación del CRM
Arrancar el servidor de Odoo. Ver Anexo VII.
Iniciar Odoo en el navegador. Ver Anexo VII.
Autenticarse con el nombre de usuario y contraseña en Odoo.
Una vez autenticados, hacer clic en el menú 'Configuración' de la barra superior de menús.
En la barra de búsqueda de la esquina superior derecha escribir el texto sdicrm.
Aparecerá un icono con la aplicación.
Pulsar en el icono Instalar a lado del icono.
Página 109 de 129
Anexo IX. Manual de uso del CRM
Acceso
El punto de entrada de la aplicación es la pantalla de login, a la que se accede mediante la siguiente URL
en el navegador web.: http://localhost:8069/web
Una vez introducido el nombre de la base de datos con la que se quiere trabajar, el login (o correo
electrónico) y la contraseña, podemos ver entrar dentro de Odoo.
Menús e interfaz principal
Al módulo CRM se accede desde el menú Ventas situado en la barra superior de color negro en la interfaz.
Una vez se hace clic en él aparecen en la barra lateral una serie de menús y submenús.
Iremos visitando cada menú a lo largo del manual para conocer qué funcionalidades
podemos ejecutar desde cada uno de ellos.
Página 110 de 129
La interfaz principal del CRM nada más hace clic en el menú es ventas es una vista donde aparece un
listado de empresas registradas en el sistema que son clientes.
A partir de aquí, vamos a ir recorriendo cada menú de los que aparecen en la barra lateral para descubrir
qué podemos hacer con cada uno de ellos.
Menú Clientes
Este menú se encuentra dentro del primer menú de la barra lateral llamado Ventas.
Hay que aclarar que este menú abre el mismo tipo de vistas que el menú llamado Empresas en la barra
lateral de la interfaz principal, con la diferencia de que el menú clientes sólo nos muestra las empresas
que son clientes y los contactos de estas empresas, y el otro nos muestra todas las empresas y sus
contactos, sean clientes nuestros o no.
Si hacemos clic en él, lo primero que vemos es una vista con las empresas registradas que ya son clientes.
En la imagen anterior puede verse el aspecto de esta vista.
En ella, puede apreciarse como el área está dividida en pequeños rectángulos.
Cada rectángulo muestra varios elementos de información:
Una pequeña imagen de la empresa.
Su nombre.
Nombres de etiquetas que sirven para clasificar a la empresa.
La ciudad y país donde está ubicada, su dirección de email y la web de la empresa. Tanto la dirección de email como la web son links que permiten abrir el gestor de correo o una nueva página en el navegador web.
Página 111 de 129
El número de oportunidades de venta que tiene registradas y el de reuniones o citas en las que figura como asistente. Cada uno de estos dos elementos es un enlace que nos permite acceder a la información de las oportunidades o de las citas respectivamente.
En la parte superior derecha de la ventana se muestra una serie de botones.
Estos botones aparecerán en cada menú que visitemos. Cada uno de ellos abre una vista en la interfaz de
un tipo determinado.
El primer icono que aparece en la imagen de arriba permite abrir una vista que puede ser de dos tipos.
Una vista como la que hemos visto antes, u otro tipo de vista que tiene la forma de un tablero kanban.
Hablaremos de esta vista más adelante. De momento sólo hay que saber que este es su aspecto.
El segundo icono nos permite acceder a una vista donde se muestra información de algún tipo organizada
por filas y columnas.
Por ejemplo, esta es la vista de este tipo que se muestra estando situados en el menú Clientes.
Página 112 de 129
En esta vista podemos ver un listado de todas las empresas registradas que sean clientes. Cada fila
representa a un cliente, y cada columna a un dato de éste, por ejemplo, email.
El tercer icono disponible corresponde a una vista que muestra un formulario.
Estando en el menú Clientes nos aparece un formulario donde podemos crear, ver o editar los datos de
una empresa o cliente.
En este formulario podemos introducir los datos de nueva empresa o editar los que ya posee.
Dentro de cada formulario en el CRM aparecerán una serie campos en color azul. Es obligatorio introducir
datos dentro de este tipo de campos para poder guardar los cambios realizados.
Página 113 de 129
Dentro del formulario de un cliente o empresa debemos introducir los datos que consideremos
necesarios, pero es importante destacar los siguientes campos del formulario, ya que tienen un
comportamiento especial.
En realidad el siguiente campo aparece en otros formularios del CRM, pero aprovechamos para explicarlo
ya que ha aparecido por primera vez.
Esta componente no es más que una imagen, en este caso, el logo de la empresa.
Si pinchamos con el cursor del ratón sobre el icono del lápiz podemos, o bien asignar una imagen, o
cambiar la ya existente. Si pinchamos en el icono de la papelera podemos eliminar la imagen.
Otro campo interesante de este formulario es el que nos permite añadir nuevas etiquetas para categorizar
a la empresa, todas las que queramos.
Podemos crear una nueva etiqueta escribiendo su nombre directamente desde esta componente del
formulario.
También tenemos la posibilidad de elegir etiquetas existentes pinchando en el icono de flecha hacia
debajo de esta componente. Aparecerá un pequeño listado de etiquetas. Podemos buscar más etiquetas
si pinchamos en la opción 'Buscar más…' que aparece en este listado. Si lo hacemos nos aparece un listado
de etiquetas donde podemos elegir las que queramos para añadir a la empresa.
También podremos buscar etiquetas desde la barra de búsqueda o crear una nueva.
Aprovechamos este formulario de empresa para hablar de un tipo de componente que aparece
habitualmente en los formularios del CRM.
Es básicamente un combobox donde podemos elegir un valor de un desplegable. Pero no es un simple
listado de valores, sino que es un combobox dinámico.
Podemos ver este tipo de componente en el campo 'Zona' del formulario de empresa.
Página 114 de 129
Si pinchamos en el icono de la flecha aparece un desplegable donde podemos elegir un tipo de valor. Pero
además, al igual que antes, podemos crear un nuevo valor o buscar uno ya existente en una tabla como
la que vimos en la componente anterior.
Otra cosa interesante a nombrar en este tipo de campos es el icono que aparece a lado de él. Si hacemos
clic en este icono, podemos acceder a un formulario donde podemos ver toda la información referida al
valor que acabamos de elegir en el combobox.
Otro apartado muy común dentro de los formularios es una zona donde se muestra una serie de pestañas.
Cada pestaña puede contener más componentes del formulario.
En el caso de la imagen de arriba corresponde a una pestaña donde nos aparece el listado de productos
software adquiridos por una empresa. En este listado también podemos añadir productos a mano.
El comportamiento de esta pestaña es dinámico, puesto que aparecerá en él cada nuevo producto que
figure en los presupuestos hechos para la empresa y que hayan sido aceptados.
Otro tipo de componente que se repite a lo largo de los formularios del CRM son unos botones que
aparecen en la parte superior derecha.
En el caso del formulario de cliente o empresa tenemos cinco botones:
Estos botones nos permiten, en primer lugar, ver el número de campañas de marketing, presupuestos,
oportunidades, reuniones y llamadas asociadas a la empresa o cliente.
En segundo lugar, si pinchamos en alguno de ellos accederemos a una vista donde podremos ver la
información relativa a cada botón.
Página 115 de 129
Por ejemplo, sin pinchamos en el botón 'Presupuestos' accederemos a una vista donde podremos ver los
presupuestos realizados para esta empresa.
Otro tipo de elemento que aparece en la parte inferior de casi todos los formularios del CRM, es un área
que permite escribir mensajes para que otros usuarios de la aplicación que accedan a ese formulario
puedan verlos. Para poder ver estos mensajes el usuario tiene que hacerse seguidor del formulario.
Para ello, tiene que pulsar en el botón Seguir.
El usuario que haya creado los datos del formulario puede añadir seguidores a dicho formulario.
Si volvemos a la vista de tipo listado de empresas tenemos disponibles dos funcionalidades más.
Fusionar empresas
Podemos elegir dos o más empresas para fusionar en una sola, la empresa que elijamos como destino.
Esta empresa será la única que se conservará, las otras serán borradas. Todos los elementos que poseían
las otras empresas, como oportunidades, llamadas, citas o presupuestos serán añadidos a la empresa de
destino.
Para acceder a esta opción tenemos que seleccionar varias empresas o clientes en la vista de tipo lista.
Una vez hecho esto, pulsamos un botón con el nombre 'Más…' en la parte superior.
En este botón pinchamos en la opción 'Fusión automática'.
Nos aparecerá un formulario en una ventana flotante.
Página 116 de 129
En este formulario nos aparecen las empresas elegidas anteriormente. Podemos borrar o añadir nuevas
empresas para fusionar.
Por último, debemos seleccionar cualquier empresa registrada que queremos que sea la empresa que
adquiera todos los elementos de las demás. La elegimos en el campo 'Contacto de destino'.
Una vez hecho esto, pulsamos en el botón 'Combinar selección' y la fusión se producirá.
Programar llamadas
Otra opción que tenemos en el botón 'Más…' del que hablamos antes es un programador de llamadas
(‘Scheduler Phone Calls’), con el que podremos registrar varias llamadas para una empresa en un solo
paso.
Una vez elijamos varias empresas del listado de empresas y pinchemos en esta opción, aparecerá un
formulario en una ventana flotante.
En este formulario ya nos aparecen las empresas elegidas en el paso anterior, aunque podemos eliminar
y añadir las que queramos.
Además debemos introducir una fecha con día, horas y minutos, y un intervalo de tiempo en minutos.
Para cada empresa seleccionada se creará una llamada en el día elegido separada de la anterior por el
intervalo en minutos elegido.
Además, dentro de este formulario tenemos la opción de elegir una campaña de marketing. Una vez
elijamos una campaña de marketing, todas las empresas adheridas a esta campaña aparecerán en dicho
formulario, borrando las que se hubieran añadido previamente.
Duplicar empresa
Desde el formulario de una empresa, tenemos la opción de poder duplicar una empresa con los mismos
datos exceptuando el nombre.
Para acceder a esta opción tenemos que seleccionar la opción 'Duplicar' en el botón 'Más…'.
Página 117 de 129
Menú Oportunidades
El menú Oportunidades, situado en la barra de menús lateral, bajo el menú Ventas, nos permite registrar,
ver y editar las oportunidades de venta asociadas a cada empresa.
Al pinchar en este menú, tenemos disponibles dos nuevos tipos de vistas, una vista de tipo calendario y
otra donde podemos ver gráficos.
En la parte superior derecha de la pantalla han aparecido dos nuevos iconos de vistas.
El primero de ellos nos permite visualizar una serie de gráficos. El segundo nos muestra un calendario.
Vista kanban en oportunidades
Si accedemos a esta vista en el menú de oportunidades nos encontramos con un panel tipo 'kanban'
donde podemos ver las oportunidades organizadas por fases.
Cada oportunidad se visualiza en forma de rectángulo o viñeta donde podemos ver algunos de sus datos,
como una descripción, el importe de dinero que se espera ganar con esta oportunidad, el nombre de la
empresa, la fecha de la acción siguiente a realizar y una breve descripción de ésta, y la prioridad.
Además de estos datos, podemos pinchar en el icono de flecha de una viñeta, donde nos aparecerán una
serie de opciones.
Desde este menú de opciones podemos editar la información de la oportunidad accediendo a su
formulario, borrarla, enviar un correo mediante un asistente, programar una llamada asociada a esta
oportunidad o programar una cita o reunión asociada a la oportunidad.
Página 118 de 129
Podemos arrastrar una viñeta a otra columna. Cada columna representa una fase para clasificar las
oportunidades.
Cada columna tiene asignada una probabilidad de éxito, al igual que las oportunidades. Cuando
cambiamos de columna una oportunidad, ésta adquirirá como probabilidad de éxito la de la columna a la
que cambia.
Podemos crear nuevas fases desde el tablero 'kanban' pinchando en la opción 'Añadir una nueva
columna', situada en la parte superior de éste. Al hacerlo, se abrirá un nuevo formulario para la creación
de la fase, donde podemos introducir el nombre que aparecerá en la columna del 'kanban', si esta fase
aparecerá replegada en el tablero, una probabilidad de éxito para ésta y la opción de elegir si se quiere
que se cambie la probabilidad de todas las oportunidades movidas a esta fase a la probabilidad que tenga
asignada dicha fase.
Lista de oportunidades
Podemos ver el listado de oportunidades registradas organizadas por filas y columnas. Cada columna se
refiere a un tipo de dato de la oportunidad.
Formulario oportunidades
Si accedemos a la vista de oportunidades, además de poder crear o editar una oportunidad, tenemos
algunos elementos que es necesario explicar.
Podemos marcar una oportunidad como ganada o como perdida.
Si hacemos lo primero cambiaremos la oportunidad a una fase que tenga una probabilidad del 100 %. Si
hacemos lo segundo la pasaremos a una fase con probabilidad del 0 %.
Tenemos disponibles otros dos botones dentro del formulario de una oportunidad.
Nos permiten programar una llamada o a una cita asociada a la empresa desde el mismo formulario de
oportunidad. Al pinchar en cada uno de ellos accederemos a una vista donde podremos introducir los
datos de la llamada o de la cita.
Página 119 de 129
Dentro del formulario de una oportunidad tenemos la posibilidad de asignar una campaña de marketing
de origen, un presupuesto asociado a la oportunidad o una llamada que actúa como origen de dónde
proviene dicha oportunidad.
Vista de gráficos
Podemos también ver varios tipos de gráficos si activamos la vista correspondiente dentro de
oportunidades.
En este tipo de vista podemos observar varios tipos de gráficos (barras, sectores y líneas) para visualizar
de forma más sencilla una comparativa de datos de oportunidades.
Vista calendario
Por último, podemos ver las oportunidades ubicadas en un calendario, donde además podemos
seleccionar que queremos ver sólo las oportunidades asignadas a un determinado usuario.
Página 120 de 129
Las oportunidades aparecerán clasificadas en el día donde se producirá la acción siguiente a ejecutar para
la oportunidad, y se mostrará su descripción y la empresa que tienen asignada.
Menú Gestor Empresas-Clientes
En la barra lateral de la interfaz principal tenemos otra serie de menús.
El menú Empresas tiene la misma funcionalidad que el menú Clientes explicado al principio del manual.
La única diferencia es que con este menú podremos acceder a la información de todas las empresas
registradas, no sólo las que son clientes.
El menú Opciones Empresa contiene menús para crear y ver ciertos tipos de datos asociados a una
empresa. Estos datos también los podemos crear desde el formulario de la empresa al crearla o editarla.
Menú 'Sectores empresas': permite crear, ver y editar sectores de empresa. A cada sector se le puede asignar un nombre y un sector padre si se desea.
Menú 'Localizaciones empresas': permite crear, ver y editar localizaciones para una empresa, lo que equivaldría a la sede u oficina de una compañía. Cada compañía puede tener registradas varias sedes.
Menú 'Tipos de empresas': permite crear, ver y editar tipos de empresas. Cada tipo sólo consistirá en un nombre.
Menú 'Zonas de empresa': permite crear, ver y editar zonas de empresa. Cada zona sólo consistirá en un nombre de zona.
Página 121 de 129
Menú Emails de empresas': permite crear, ver y editar emails asignados a una empresa. El usuario podrá asignar a una empresa una dirección de email. Cada empresa podrá tener varias direcciones de email diferentes.
Menú 'Asociados': permite crear, ver y editar asociados o afiliados. Un asociado simplemente consistirá en un nombre.
Menú 'Origen empresas': permite crear, ver y editar orígenes de empresa. Cada origen sólo consistirá en un nombre.
Menú contactos
Este menú situado en la barra lateral de la aplicación, nos permite ver el listado de contactos de cada
empresa registrados en la aplicación, además de crear nuevos contactos o editar la información que ya
contienen.
Menú Comerciales
Este menú está situado en la barra lateral de menús de la aplicación, y nos permite ver un listado de los
comerciales registrados en la aplicación, así como crear nuevos o editar la información de los ya
existentes.
Página 122 de 129
Cuando creemos o editemos un comercial en el formulario, debemos obligatoriamente asignarle un
usuario con el que se autenticará en la aplicación o elegir uno ya existente.
Desde este formulario tenemos disponibles unos botones que nos permiten ver el número de
oportunidades, llamadas, presupuestos o citas asociadas a este comercial.
Además, podemos pinchar en cualquiera de estos botones y podremos acceder al listado de cada uno de
estos elementos.
Menú Productos
Este menú situado en la barra lateral de menús permite acceder a una serie de submenús para gestionar
productos.
Menú 'Empresas Desarrolladoras': nos permite ver, crear y editar empresas fabricantes de software, que
luego podremos asignar a un producto software que creemos.
Menús 'Gestor de Software' y 'Gestor de servicios':
Podemos crear seis tipos de productos: software, subscripciones de software, servicio de mantenimiento
de software, subscripción a un servicio de mantenimiento, servicio de soporte de software y suscripción
a un servicio de soporte de software.
Menú 'Productos de Software'
Dentro del formulario de creación de producto software, cabe destacar que tendremos una sección
encima del formulario donde podremos elegir el estado en el que se encuentra el producto a través de
unos botones.
Página 123 de 129
Reseñar que no se podrá cambiar el estado cuando este sea igual a 'Descatalogado'.
Menú 'Subscripciones Software'
Nos permite ver, crear y editar subscripciones software, es decir, una modalidad de compra de un
producto con una licencia temporal, válida durante un período de ciertos meses.
Cada subscripción deberá ir asociada obligatoriamente a un producto.
Menús 'Mantenimiento Software' y 'Soporte Software'
En estos menús podremos ver, crear y editar los servicios de mantenimiento y de soporte prestados para
un software determinado y para una empresa en concreto.
En el caso de servicio de mantenimiento sólo podremos escoger los productos software que tengan
disponible servicio de mantenimiento.
En el caso de servicio de soporte sólo podremos escoger los productos software que tengan disponible
servicio de soporte.
En ambos casos, es obligatorio especificar a qué empresa se le prestará el servicio.
Menú Tareas
Desde este menú podremos desarrollar todas las acciones relativas a tareas que se suelen hacer en el
departamento comercial de una empresa.
Este tipo de tareas son: llamadas, citas (demos, reuniones o visitas) y realización de presupuestos.
Página 124 de 129
Menú Llamadas registradas
Este menú tendrá disponible tres tipos de vistas para interactuar con llamadas: una lista de llamadas
registradas, el típico formulario y un calendario desde donde ver y registrar llamadas.
Listado de llamadas
Desde este listado podremos ver las llamadas registradas.
Además, podremos crear y editar llamadas rápidamente directamente sobre la misma tabla.
Así mismo, cada fila cuenta con tres botones desde donde se puede crear una llamada rápidamente, una
cita o convertir la llamada a oportunidad.
El convertir a oportunidad provocará que se cree una oportunidad asociada a esta llamada.
Formulario de llamadas
Desde este formulario podemos editar la información básica de la llamada, y además asignar a ésta una
campaña de marketing de la que proviene, y una oportunidad asociada.
Al igual que en la vista del listado, también podremos convertir la llamada a una oportunidad, o programar
una llamada o cita con los botones situados en la parte superior derecha.
Así mismo, podremos cambiar el estado de la llamada pinchando en las opciones de estado en la parte
superior del formulario.
Página 125 de 129
Calendario de llamadas
Nos permite ver las llamadas registradas por el día en que se crearon.
Además, en la parte lateral podemos filtrar las llamadas realizadas por un determinado usuario, su
responsable.
Así mismo, si pinchamos en un día del calendario podremos crear una llamada rápidamente dándole sólo
un nombre.
Menú Calendario
Al igual que con las llamadas tendremos disponibles las vistas de calendario, listado y formulario.
Formulario
A parte de poder ver, crear y editar citas desde el formulario tenemos disponibles otra serie de
funcionalidades.
Al igual que con las llamadas, podremos cambiar el estado a una cita desde la barra de estado situada en
la parte superior.
Por otra parte, será obligatorio elegir los contactos o empresas asistentes a la cita.
Cuando guardemos la cita o cambiemos sus asistentes, dentro del formulario tendremos un listado donde
figuran todos estos asistentes junto a un botón que permitirá enviar automáticamente un email a cada
uno de ellos para que acepte o decline la invitación a la cita.
Página 126 de 129
Podremos usar unos botones para confirmar, cancelar o dejar en indeterminada la asistencia de la
empresa a la cita.
Por otra parte, desde el formulario de una llamada podremos convertir la cita a una oportunidad
(pinchando en el botón ‘Convertir a oportunidad’, lo que provocará que se cree una oportunidad asociada
a dicha cita para cada uno de los asistentes.
Menú Presupuestos
Desde este menú podremos ver, crear o editar presupuestos. Tendremos disponibles las vistas de tipo
lista y formulario.
Formulario
Además de poder ver y editar los datos de un presupuesto, hay que destacar varias funcionalidades.
En primer lugar, sería obligatorio indicar la empresa para la que se realiza el presupuesto.
Así mismo, desde la parte superior del formulario podremos cambiar el estado de un presupuesto. Cuando
el estado sea igual 'Rechazado' ya no podremos cambiar de estado.
Desde el formulario de presupuesto también podremos crear las líneas que va a tener un presupuesto. Se
deberá añadir sólo un producto por línea.
Página 127 de 129
Al crear una línea aparecerá un formulario que nos permitirá elegir el tipo de producto y la empresa.
Además, automáticamente nos mostrará el precio que tiene ese producto.
Desde el formulario de producto podemos ver todas las líneas añadidas, acceder a la información de cada
una de ellas, y ver el total del presupuesto.
Por último, desde el formulario de presupuesto podremos convertir éste a una oportunidad (con el botón
‘Convertir a oportunidad’), lo que provocará que se cree una oportunidad y que ambos queden asociados
el uno con el otro.
Menú Campañas de Marketing
Desde este menú situado en la barra lateral de menús, podemos ver todas las campañas registradas, así
como crear y editar los datos de una campaña de marketing.
Desde el formulario de una campaña, aparte de editar y ver todos sus tipos de datos asociados, podemos
ver el número de oportunidades que tienen como origen dicha campaña, así como acceder a la
información de estas oportunidades a través de un botón (‘Oportunidades’) situado en la parte superior
derecha.
Página 128 de 129
Podremos componer y enviar un email con el botón 'Enviar email', y podremos cambiar el estado de la
campaña haciendo clic en la barra de estados situada en la parte superior.
Por otra parte, desde el formulario podremos ver todas las llamadas, citas o presupuestos asociados a la
campaña, eligiendo las pestañas correspondientes situadas en la parte inferior del formulario.
Menú Deduplicar contactos
Este menú nos permitirá eliminar empresas o contactos de empresas que estén duplicados, bien por su
email o por su nombre.
Al pinchar en este menú nos aparecerá un asistente que nos permitirá especificar porque campo
queremos encontrar duplicados.
Así mismo, podremos realizar el proceso viendo las empresas o contactos duplicados encontrados, y
eligiendo la empresa o contacto donde se fusionarán las/los demás, o también podremos dejar que el
sistema los elimine y haga la fusión automáticamente, eligiendo éste la empresa de destino de dicha
fusión.
Filtros y agrupaciones
En todos los tipos de vistas de la aplicación excepto en la vista de tipo formulario, podemos aplicar filtros
predefinidos de búsqueda y agrupaciones.
Un filtro nos permite que obtengamos los registros de una determinada entidad que cumplan una o varias
condiciones. Por ejemplo, podríamos tener un filtro que nos permitiera ver solamente las empresas que
son clientes.
Página 129 de 129
Las agrupaciones nos permiten ver los registros de una determinada entidad agrupados por un
determinado criterio ya predefinido. Por ejemplo, podríamos ver los contactos de una empresa agrupados
por la empresa a la que pertenecen.
Se puede acceder a los filtros y agrupaciones definidos pinchando en el icono de una flecha hacia abajo
que se encuentra en la barra de búsqueda en la parte superior de la vista en la que nos encontremos.