aplicación web crm (customer relationship management) sobre

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

de 129

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

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

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.

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.

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.

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.

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.

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.

de 129

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

de 129


(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

de 129


(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

de 129


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

de 129


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

de 129


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.

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


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:

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


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.

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


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


Precondiciones El usuario debe haber creado una llamada previamente y haberla seleccionado

Postcondiciones Se creará una oportunidad asociada a la llamada

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


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

de 129

Caso de uso Convertir presupuesto a oportunidad


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


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.

de 129

Caso de uso Marcar oportunidad como ganada o perdida


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


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.

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”

de 129

Diagrama de actividades – Caso de uso “Cambiar estado presupuesto”

Diagrama de actividades – Caso de uso “Marcar oportunidad como ganada o perdida”

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.

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.

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.

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'


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'


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.

de 129


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.

de 129



El diagrama anterior se centra en todas aquellas clases relacionadas con productos y servicios, y sus

relaciones entre ellas.

de 129


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.

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

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.

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

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.

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/

https://www.odoo.com/documentation/8.0/setup/install.html#setup-install-source

http://localhost:8069/web/database/manager

http://localhost:8069/

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:

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

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:

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'.

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.

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',

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> 

<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.

 

<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>

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>

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.

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.

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>

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"/>

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.

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"

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.

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>

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

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.

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

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.

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.

https://www.odoo.com/documentation/8.0

https://www.odoo.com/es_ES/forum/help-1

http://es.slideshare.net/openobject

https://www.odoo.com/es_ES/slides/public-channel-1

https://groups.google.com/forum/#!forum/openerp-spain-users

http://stackoverflow.com/questions/tagged/odoo

https://doc.odoo.com/

https://doc.odoo.com/6.1

https://www.youtube.es/

http://useopenerp.com/v8

https://fossies.org/dox/odoo-8.0.0/index.html

http://www.theopensourcerer.com/2014/09/how-to-install-openerp-odoo-8-on-ubuntu-server-14-04-lts/

http://www.theopensourcerer.com/2014/09/how-to-install-openerp-odoo-8-on-ubuntu-server-14-04-lts/

https://docs.python.org/2.7

https://www.youtube.com/watch?v=qsHEAW6wqks&list=PLEtcGQaT56cj70Vl_C1qfUinyMELunL-N

https://www.youtube.com/watch?v=qsHEAW6wqks&list=PLEtcGQaT56cj70Vl_C1qfUinyMELunL-N

http://www.postgresql.org/docs/9.3/static

de 129

ANEXOS

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.

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

de 129

ACTA 2

Lugar Día: 27-02-2015

Universidad de La Rioja Hora de comienzo: 17:00 h

Duración: 1 hora



Ana Romero Ibáñez (tutora del TFG)


Ana Romero Ibáñez

No asistentes

Director de la reunión Eduardo Basalo Peña


Orden del día

Explicar lo acordado en la reunión correspondiente al Acta 1.

Puntos tratados


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.


de 129

ACTA 3

Lugar Día: 23-04-2015


Duración: 1 hora

Convocada por Ana Romero Ibáñez


Ana Romero Ibáñez


Ana Romero Ibáñez

No asistentes



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


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.


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.

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.


de 129

ACTA 4

Lugar Día: 29-04-2015



Duración: 1 hora






Pablo García (empleado de SDI en su oficina de Calahorra), vía telefónica

No asistentes



Orden del día

Mostrar el avance en el TFG.


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


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.


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 Propuesta de reconducir el TFG, reduciendo drásticamente las funcionalidades del CRM a

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.


de 129

ACTA 5

Lugar Día: 3-06-2015

Oficina Calahorra SDI Soluciones Informáticas C/ Cavas 35-37, Calahorra (La Rioja)


Duración: 1 hora

Convocada por José Víctor Gómez



Pablo García



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


Orden del día


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


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.


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.

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.


de 129

ACTA 6

Lugar Día: 29-06-2015


Duración: 1 hora y 30 minutos


Ana Romero Ibáñez



Ana Romero Ibáñez

No asistentes



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


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:

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

de 129

ACTA 7

Lugar Día: 17-07-2015


Duración: 1 hora


Ana Romero Ibáñez



Ana Romero Ibáñez

No asistentes



Orden del día

Mostrar una demo de la versión final de la aplicación

Puntos tratados


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.


de 129

ACTA 8

Lugar Día: 21-07-2015



Duración: 1 hora






No asistentes



Orden del día

Mostrar una demo de la versión final de la aplicación

Puntos tratados


o Muestra de una demo de la versión final de la aplicación.


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.


de 129

ACTA 9

Lugar Día: 24-02-2015


Duración: 45 minutos



Ana Romero Ibáñez


Ana Romero Ibáñez

No asistentes

Directora de la reunión Ana Romero Ibáñez


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


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

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.

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.

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.

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.

de 129

Anexo III. Diagrama de Gantt

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

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

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

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

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

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.

de 129

Diagrama 1. Se centra en las relaciones de la tabla 'calendar_event', asociada a demos, reuniones y visitas en la aplicación.

de 129

Diagrama 2. Se centra en las relaciones de la tabla 'crm_lead' que

corresponde a las oportunidades en la aplicación

de 129

Diagrama 3. Se centra en las relaciones de la tabla 'crm_phonecall' correspondiente a las llamadas en la aplicación

de 129

Diagrama 4. Se centra en las relaciones de la tabla 'sdicrm_company' que representa a las empresas en la aplicación

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

de 129

Diagrama 6. Se centra en las relaciones de las tablas relacionadas con productos en la aplicación

de 129

Diagrama 7. Se centra en las relaciones de la tabla 'sdicrm_quote' que representa a los presupuestos en la aplicación.

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.

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).

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.

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


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.

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


Llamada en Python (ver explicación al comienzo de la página 95).

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.

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.

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.

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:

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.

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:


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

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

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

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:


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.

http://127.0.0.1:8069/

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.

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.

http://localhost:8069/web

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.

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.

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.

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.

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.

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.

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…'.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

aplicación web crm (customer relationship management) sobre

Documents