PFC Fernando Vazquez Novoa Marcadores

UNIVERSIDAD DE VIGO
Escuela Técnica Superior de Ingeniería de Minas de Vigo
Departament o de Ingeniería de Rec ursos Nat urales y Medio Ambiente
PROYECTO FIN DE CARRERA
IMPLA NTACIÓN DE UN E RP DE CÓDIGO AB IERTO EN LA ASOCIA CIÓN CLÚS TER DA

XEOTE RMIA GALEGA
Autor: Fernando V ázquez Novoa
Dirección: Rafael Barrionuevo Giménez
Vigo, Junio de 2014

AUTORIZACIÓN PRESENTACIÓN PROYECTO FIN DE CARRERA
Vigo, 7 de Mayo de 2014
El director D. Rafael Barrionuevo Giménez del proyecto fin de carrera elaborado

por D. Fernando Vázquez Novoa y de título: “IMPLANTACIÓN DE UN ERP DE
CÓDIGO ABIERTO EN LA ASOCIACIÓN CLÚSTER DA XEOTERMIA GALEGA”,
autorizo al autor para que proceda a su presentación y lectura pública.
ABSTRACT
An operating study of the Open Source ERP OpenERP from a user perspective,
configuration and module development has been performed in this final project.
Subsequently, the knowledge gained from the study has been applied to
implement it in the Asociación Clúster da Xeotermia Galega (ACLUXEGA).The
methodology consisted of the following steps: analysis, design, development,
implementation and start up.
Finally, a process cost analysis has been done.
RESUMEN
En este proyecto se ha llevado a cabo un estudio del funcionamiento del ERP

de código abierto OpenERP, desde la perspectiva de usuario, configuración y
desarrollo de módulos.
Posteriormente se han aplicado estos conocimientos en la implantación del
mismo en la Asociación Clúster da Xeotermia Galega (ACLUXEGA) siguiendo una
metodología consistente en los siguientes pasos: análisis, diseño, desarrollo,
implementación y puesta en marcha.
Para finalizar se ha realizado un análisis de costes del proceso.
PALABRAS CLAVE:
-ERP
- OpenERP
-PostgreSQL
- Virtualización
-Asociación
CÓDIGOS UNESCO DE CLASIFICACIÓN: 3308/99 5306/02

AGRADECIMIENTOS
En primer lugar quisiera agradecer a mi tutor Dr. Rafael Barrionuevo Giménez por
su ayuda, tiempo y paciencia durante este proyecto, ha conseguido transformar mi
incredulidad en realidad, confiando en que podía llevar a cabo lo que me propusiese.
Me gustaría expresar mi agradecimiento a la Asociación Clúster da Xeotermia
Galega, por haberme permitido llevar a cabo la implantación, y en especial a su
directora Belén Sío y a Manuel Castro, por su tiempo, su ayuda, conocimientos y una
convivencia inmejorable durante los últimos meses.
También a Félix Queiruga y a Ángel por su asesoramiento y ayudarme a entender
un poco mejor una pequeña parte de ese mundo para mí tan desconocido como es el
de la informática.
Quisiera acordarme también de aquellas personas que creyeron en el niño que
quería llegar a las estrellas, entre ellas Any, siempre en mi mente.
Finalmente, y ya para terminar, habría sido muchísimo más difícil, sino imposible,
llegar hasta aquí sin la ayuda de mis compañeros de carrera a lo largo de estos años,
muchas horas de biblioteca, de cafetería y de estudio en las mesas de los pasillos.
ÍNDICE
1.INTRODUCCIÓN 1
1.1.Objetivos 3
2.ERP 7
2.1.Definición 7
2.2.Beneficios 8
2.3.Características 11
2.4.Arquitectura 12
2.4.1.Perspectiva funcional 12
2.4.2.Perspectiva técnica 14
2.5.Historia y evolución 16
2.6.Diferencia entre CRM y ERP 21
2.7.Ventajas e inconvenientes en la implantación de un ERP 23
2.7.1.Ventajas 23
2.7.2.Inconvenientes 25
2.8.Tipos de ERP 26
2.8.1.Adaptabilidad 26
2.8.2.Propiedad de la licencia 27
2.8.2.1 Software propietario 27
2.8.2.2 Software libre 29
2.8.2.2.1 Alimentación económica de los ERP Opensource 31
2.8.2.3 Software SaaS 32
2.9.Costes de un ERP 33
2.9.1.Costes principales 34
2.9.2.Costes ocultos 35
2.9.3.Aplicación: Niveles de costes 36
2.10.Falsos mitos de los ERP 37
3.VIRTUALIZACIÓN DE SISTEMAS 39
3.1.Definición y tipos de máquinas virtuales 41
3.2.Creación de una máquina virtual 41
3.3.Utilización en el proyecto 45
4 .ESTUDIO DE OPENERP 49
4.1. Introducción 51
4.2. Descripción de OpenERP 51
4.3. Instalación 54
4.4. Descripción de módulos 57
4.5. Funcionamiento de OpenERP 58
4.5.1. Crear bases de datos 58
4.5.2. Instalar módulos 59
4.5.3 .Crear usuario y cambio de contraseña 59
4.5.4. Configuración de permisos 60
4.5.5 .Importar exportar datos 63
4.5.5.1. Exportar 63
4.5.5. 2 .Importar 64
4.6. Personalización de módulos 66
4.7. Modo gráfico 67
4.8. Programación 74
4.8.1.Introducción 74
4.8.2 Licencia 77
4.8.3 Sistema de archivos básicos 78
4.8.3.1 Archivo __init__.py 79
4.8.3.2. Archivo __openerp__.py 79
4.8.3.3. Archivo modulo_ejemplo.py 80
4.8.3.3.1 Atributos predeterminados 80
4.8.3.3.2 Campos básicos y relacionales 81
4.8.3.3.2.1 Campos básicos 81
4.8.3.3.2.2 Campos relacionales 83
4.8.3.3.3 Ejemplo 83
4.8.3.4 Archivo modulo_ejemplo.xml 86
4.8.3.4.1 Elementos de diseño 87
4.8.3.4.2 Menús 87
4.8.3.4.3 Vista kanban 88
4.8.3.4.4 Vista lista 88
4.8.3.4. 5 Vista formulario 89
4.8.3.4.6 Acción y resto de objetos 90
4.8.4 Instalación del módulo propio 91
5.ASOCIACIÓN CLÚSTER DA XEOTERMIA GALEGA ( ACLUXEGA) 95

5.1 Geotermia 97
5.2 La asociación 98
5.2 Objetivos 99
5.4 Actividades 100
5.5 Estructura de la asociación 104
6. IMPLANTAR OPENERP 107

6.1 Descripción del proceso 109
6.2 Análisis 111
6.3 Diseño 113
6.3.1 ACLUXEGA_GENERAL 114
6.3.1.1 Módulos básicos 116
6.3.1.1.1 Mensajería 116
6.3.1.1.2 Project 116
6.3.1.1.3 Contabilidad 117
6.3.1.1.4 Recursos humanos 117
6.3.1.1.5 Encuestas 118
6.3.1.1.6 Eventos 119
6.3.1.1.7 Informes 119
6.3.1.2 Módulos propios 119
6.3.1.2.1 Lista de correos 119
6.3.1.2.2 Asociados 121
6.3.1.2.3. Legislación 125
6.3.1.2.4 Subvenciones 127
6.3.1.2.5 Geotermia 128
6.3.2 CURSO_NOMBRE 133
6.3.2.1.2 Project 135
6.3.2.1.4 Recursos humano 135
6.3.2.1.5 Encuestas 135
6.3.2.1.6 Informes 135
6.3.2.2 Módulo propio: CURSO 135
6.3.3 CONGRESO_NOMBRE 139
6.3.3.1.2 Project 141
6.3.3.1.4 Recursos humanos 141
6.3.3.1.5 Encuestas 141
6.3.3.1.6 Informes 141
6.3.3.2 Módulo propio: CONGRESO 141
6.4 Desarrollo de módulos 146
6.5 Implementación 148
6.5.1 Instalación del software 149
6.5.2 Formación de los empleados 153
6.5.3 Migración de datos 154
6.5.4 Periodo de pruebas 155
6.6 Puesta en marcha 155
7. ANÁLISIS DE COSTES DE OPENERP 157

7.1 Infraestructura técnica 160
7.2 Software 161
7.3 Servicios de consultoría, desarrollo implantación y mantenimiento 161
7.3.1 Análisis 162
7.3.2 Diseño y desarrollo 162
7.3.3 Implementación 163
7.3.3.1 Instalación del software 163
7.3.3.2 Formación del personal 164
7.3.3.3 Migración 164
7.3.3.4 Periodo de pruebas 165
7.4 Resumen de costes 166
8. CONCLUSIONES 169
9. BIBLIOGRAFÍA 173
ANEXOS
ANEXO I: Instalar OpenERP 7.0 en Ubuntu 12.04 LTS 179
ANEXO II: Guía descriptiva de módulos básicos de OpenERP 189
ANEXO III: Módulos programados 301
ANEXO IV: Tutorial OpenERP ACLUXEGA 591
1. INTRODUCCIÓN.
1. INTRODUCCIÓN
1. INTRODUCCIÓN
En la actualidad y dado el vertiginoso ritmo de evolución de la tecnología,

especialmente en el campo de las comunicaciones, estar al día es una clave que se
convierte en indispensable para sobrevivir en el ámbito empresarial. La fluidez en el
intercambio de información entre las distintas partes de la empresa juega un papel
fundamental para la toma de decisiones. Desde esta perspectiva, los nuevos sistemas
de gestión empresarial (ERP, siglas de Enterprise Resource Planing) apuestan por la
utilización de herramientas que permitan conectar los distintos departamentos a través
de los datos derivados desde sus correspondientes actividades con el objetivo de
obtener una visión global de la situación de la empresa. A pesar de las ventajas de
estas prácticas de gestión, su aplicación en las pymes es escasa. Esta característica
se debe fundamentalmente a las limitaciones de recursos de las empresas de reducido
tamaño así como a su falta de motivación a modificar su gestión tradicional.
El punto de vista del cliente se puede definir como el siguiente: empresas que
buscan el mínimo gasto en costes y la máxima productividad de una manera eficiente.
Es por esta razón que existe una gran demanda por parte del cliente de la solución
que ofrece el ERP para poder tener un mejor control de la productividad y organización
de la empresa.
Desde el punto de vista de la empresa desarrolladora del ERP, existe una gran
demanda del software que implemente una solución adaptada y particularizada a cada
una de las empresas anteriormente mencionadas. Es por esto, que la empresa
desarrolladora del ERP necesita tener una buena metodología de implantación de este
software, de manera que este proceso se convierta en un mecanismo semiautomático,
ahorrando costes en tiempo y dinero.
Para ello es necesario saber con exactitud cuáles son las necesidades del
cliente con el fin de saber qué módulos del ERP instalar y cómo adaptarlos para que
se integren en totalidad con el funcionamiento de la empresa cliente. Por tanto parece
lógico pensar que tenga que haber profesionales de todos los ámbitos formados en
cuanto a la parte de consultoría de estos sistemas.
En entornos propios de esta titulación como la minería, obra civil, medio

ambiente o energías renovables, un ingeniero de minas puede aportar una visión más
global a la par que técnica a este proceso. Ello es fundamental en el estudio de las
necesidades del cliente ya que es muy costoso en términos de tiempo y dinero dado
que se requiere de un grado de detalle y exactitud muy elevado sobre c ómo funciona
la empresa-cliente. Esto no siempre resulta trivial de conseguir ya sea por falta de
comunicación entre la empresa desarrolladora del ERP y el cliente, por falta de
entendimiento entre ellos o por cualquier otro factor. La consecuencia de una mala
comunicación o una escasez de ésta y la extracción errónea de las necesidades del
cliente implica una pérdida de tiempo y, por consiguiente, de dinero tanto para la
empresa como lo implanta como para el cliente.
3
1. INTRODUCCIÓN
1.1 Objetivos.
Para llevar a cabo este proyecto fin de carrera se plantean los siguientes 4
objetivos:
- Estudio sobre los sistemas de planificación de recursos empresariales,

aplicación y costes.
- Estudio de un ERP de código abierto, OpenERP.
- Implantación de OpenERP en un entorno empresarial, “Asociación Clúster da
Xeotermia Galega”(ACLUXEGA) , estableciendo una metodología para llevar a
cabo el proceso.
- Aplicar la virtualización de sistemas como herramienta para llevar a cabo esa
tarea.
4
2. ERP.
2. ERP
2. ERP
2.1 Definición
Un ERP es un sistema integral de gestión empresarial que está diseñado para

modelar y automatizar la mayoría de procesos en la empresa (área de finanzas,
comercial, logística, producción, etc.). Su misión es facilitar la planificación de todos
los recursos de la empresa.
Lo más destacable de un ERP es que unifica y ordena toda la información de la

empresa en un solo lugar, de este modo cualquier suceso queda a la vista de forma
inmediata, posibilitando la toma de decisiones de forma más rápida y segura,
acortando los ciclos productivos. Con un ERP se tendrá la empresa bajo control y se
incrementará la calidad de nuestros servicios y productos.
La implantación de un ERP conlleva la eliminación de barreras ínter

departamentales, la información fluye por toda la empresa eliminando la improvisación
por falta de información.
Los ERP (Enterprise Resource Planning) son una evolución de los sistemas
MRP, los cuales estaban enfocados únicamente a la planificación de materiales y
capacidades productivas. Los ERP disponen de herramientas para efectuar la
planificación de los trabajos en planta. Esta planificación se efectúa enfrentando los
requerimientos de materiales y capacidad de los productos a fabricar contra las
existencias y capacidades sin asignar. Los ERP más completos ofrecen módulos para
planificar a capacidad finita.
Los ERP son el núcleo de otras aplicaciones como pueden ser el CRM
(Gestión de las relaciones con los clientes), Data Mining (Conversión de datos en
información útil), etc.
Los sistemas ERP unifican información de las diferentes áreas (finanzas,

recursos humanos, ventas, manufacturación, etc,) de la empresa en un solo lugar,
haciendo más fácil la toma de decisiones dentro de la empresa. El software ERP
planea y automatiza muchos procesos con la meta de integrar información a lo largo
de la empresa y elimina los complejos enlaces entre los sistemas de las diferentes
áreas del negocio
La implementación de los ERPs no es fácil, se requiere de un largo período de

implementación, además de integrar varios factores que conlleven al éxito de la puesta
en marcha. Todas las áreas de la empresa juegan un papel importante, desde la alta
dirección hasta el departamento de Tecnologías de Información. Es importante que los
usuarios estén convencidos de los beneficios que se obtendrán con los ERPs, pues
esto facilitará la implementación en la empresa.
Los sistemas ERP son sistemas de gestión de información que integran y

automatizan muchas de las prácticas de negocio asociadas con los aspectos
operativos o productivos de la empresa. Estos sistemas integran bajo el mismo
paraguas todo el software que necesita una empresa para el correcto funcionamiento
de su sistema de negocio. Se pretende que “la información esté disponible para todo el
mundo todo el tiempo”. Para ello, los sistemas ERP mantienen todas las operaciones y
procesos de la empresa bajo una misma base de datos compartida. Los ERP permiten
a las empresas evaluar, controlar y gestionar más fácilmente su negocio en todos los
ámbitos. A su vez, permiten agilizar los diferentes tipos de trabajo de cada usuario,
7
2. ERP
reduciendo en tiempo real las tareas repetitivas y permitiendo el aumento de la

comunicación entre todas las áreas que integran la empresa. También son conocidos
como sistemas integrales de empresa o sistemas integrados de gestión. Los ERP
tienen entre sus objetivos principales el satisfacer las diferentes necesidades de
información de la empresa para conseguir que los gestores empresariales dispongan
de un soporte para tomar decisiones y controlar el cumplimiento de objetivos.
Los ERP se consideran software integrado en contraposición con el software a

medida diseñado para un cliente en particular. Esto significa que cuando se adquiere
un ERP, se obtiene una versión estándar del producto final, el cual no está diseñado
para la empresa concreta que lo compra. Por tanto, se deben realizar modificaciones y
parametrizaciones para adaptarlo, aunque también debe existir una adaptación de la
empresa a ese ERP.
Un aspecto importante a entender cuando se plantea la adquisición de un ERP

es que éstos no pueden ser usados simplemente instalando el programa desde un CD
en la empresa. Se precisarán los servicios de una empresa distribuidora o equipo de
profesionales para que realicen la implantación. El tiempo requerido para esta tarea
varía según el sistema, los módulos implementados, el tamaño de la empresa y las
necesidades concretas.
Para que un sistema sea considerado de tipo ERP debe cumplir

necesariamente tres características: ser integrales, modulares y adaptables.
Figura 2. 1 Características ERP.
2.2 Beneficios de un ERP
Durante la implantación se van a ir definiendo todos los procesos en la

empresa, el cambio fundamental va a consistir en que en todos ellos existirá un
elemento común, el ERP. Es por ello que se va a aplanar la organización. Muchas de
las gestiones de los responsables pueden ser ahora gestionadas por el ERP; por
ejemplo, el responsable de existencias deberá definir la política en el ERP, y el ERP
seguirá esa política facilitando que otras personas puedan efectuar la gestión de
propuestas de compra sin su intervención. Ello va a permitir, que, de forma casi
8
2. ERP
invisible, las personas responsables puedan recuperar tiempo para otras gestiones.
También conlleva un mayor rigor y seguridad en todas las gestiones.
Esta sistematización, lleva a una simplicidad abrumadora en el funcionamiento

de la empresa, de modo que, las empresas, suelen preguntarse cómo pudieron
sobrevivir en tiempos pasados sin un sistema ERP.
Una vez implantado, va a ser mucho más fácil obtener un certificado de

calidad, puesto que los procesos básicos van a estar definidos.
El ERP va a permitir afrontar con éxito la tendencia de reducción de plazos de

entrega con cantidades cada vez menores. Algunos clientes, una vez implantado el
ERP, han podido incrementar en más del 30% la producción manteniendo los costes
fijos.
Un ERP es también un recolector de datos, estos datos, con el tiempo, tienen

un valor incalculable si se tratan adecuadamente. Pensemos, por ejemplo, en la
información que nos pueden facilitar los fichajes de los operarios de planta. Al pasar el
tiempo vamos a poder conocer con total exactitud cuánto tiempo se emplea en realizar
cada operación de cada producto, ello nos va a permitir evaluar cuales son las
operaciones que nos están consumiendo más recursos y evaluar con certeza una
hipotética inversión.
Como se va a disponer de toda la información, se podrá adoptar una actitud

pro-activa y adelantarnos a las necesidades de materiales o capacidad productiva
(horas hombre o máquina).
A continuación se enumeran 7 de los beneficios más importantes:
Beneficio 1: Ahorro a largo plazo.
Uno de los mayores beneficios es el ahorro. De su definición más básica

entendemos que una solución de este tipo gestiona el negocio, los procesos, los
bienes materiales o inmateriales, los recursos humanos o los clientes. Es una gestión
más eficiente, lo que normalmente lleva a un ahorro, aunque sin olvidar, que a largo
plazo.
Beneficio 2: Toma de decisiones.
Se dice que un software de este tipo es una decisión estratégica. Facilita la

toma de decisiones porque se tiene toda la toma de datos en una. Por ejemplo un
ERP puede traer un cuadro de mandos, como si de un coche se tratara con la
información de cómo marcha la empresa en este preciso momento. Al tener los datos
siempre disponibles de todos los departamentos y una planificación bien definida
dentro del sistema es lógico que se puedan tomar las decisiones importantes con más
facilidad.
Beneficio 3: Calidad o relación con el cliente.
Una correcta implantación de un ERP permite responder ante el cliente en un

tiempo muchísimo más reducido. Ofrece una trazabilidad mucho más rápida. Además
existe la posibilidad de incorporar el modulo de CRM (Customer Relationship
Management) a nuestra aplicación lo que nos hará aun más eficientes a la hora de
relación con los clientes.
9
2. ERP
Beneficio 4: Seguridad.
La información crucial de la empresa estará debidamente protegida en dos

sentidos. En el sentido del robo de información o acceso desautorizado a ella así como
la seguridad de los datos. Todas las soluciones que existen incorporan distintos
niveles de acceso o autorización. Por otro lado la información estará centralizada y con
copias de seguridad programadas automáticamente para prevenir cualquier fallo. En el
caso de soluciones en la nube la seguridad de los datos es incluso mayor al estar
replicados en distintos lugares.
Beneficio 5. Productividad de los empleados.
Quizás es el beneficio más evidente y lógico de implantación de un ERP,

además se deriva de la propia definición. Un sistema ERP optimiza la gestión de
procesos por consiguiente aumenta la productividad de los empleados. Se eliminan los
trabajos duplicados, se elimina la información redundante o se automatizan los
procesos. Por ejemplo imagínese que se implementa la validación de un campo que
supone el peso total de la mercancía para un camión. Un error aquí puede ser crucial
en el negocio de una empresa, al vehículo simplemente lo pueden parar en la frontera.
Pero con una simple validación en el formulario se evita un enorme problema.
Beneficio 6. Estandariza la organización.
Cuando toda la plantilla de distintos departamentos trabaja con el mismo programa,

esta aplicación les obliga a ser más "estándar" o más ordenados. Les ayuda a
reflexionar sobre los procesos o la manera de trabajar de cada departamento lo que
lleva a la reflexión sobre el proceso y la consiguiente mejora. Básicamente ayuda a
definir las buenas prácticas dentro de la plantilla de la empresa.
Beneficio 7. Impulsa a crecer ordenadamente.
Normalmente todas las empresas quieren crecer a corto o largo plazo. Un

sistema ERP posibilita un crecimiento mucho más ordenado y menos doloroso. De
hecho un crecimiento puede llegar a ser muy traumático para una empresa ya que
genera tensiones en toda la estructura. Al tener la visibilidad de la imagen de una
empresa en un preciso momento en una pantalla, se puede determinar más fácilmente
donde está el punto flojo en la estructura de la empresa que imposibilita el crecimiento
o que hay que reforzar. Aquí realmente nos apoyamos en el punto número 2, en la
mejora de la toma de decisiones en una empresa.
En 2002 Shanks y Seddon realizaron un trabajo que presentaba un modelo de

dimensiones de los beneficios de los sistemas ERP. Debido a la relevancia de este
estudio, que queda reflejado en las citas de muchos otros autores en referencia a este
trabajo sintetizaremos a continuación estas dimensiones. Propusieron cinco
dimensiones de beneficios: operacional, gestión, estratégica, infraestructura de
tecnologías de información, y organizacional:
1. Dimensión operacional.
Las actividades operacionales involucran los procesos diarios de adquisición y

consumo de recursos. Como estas actividades se repiten periódicamente, la
automatización de ellas a través de tecnología de información permite mejorar en
forma dramática estos procesos. Proponen cinco subdimensiones de esta dimensión
en relación a los sistemas ERP: 1) reducción de coste; 2) reducción del tiempo de
10
2. ERP
ciclo; 3) mejoras en la productividad; 4) mejora de la calidad; y 5) mejora del servicio al

cliente.
2. Dimensión gestión.
Las actividades de gestión involucran la distribución y control de los recursos de la

empresa. Los sistemas ERP proporcionan un conjunto de beneficios para estas
actividades, asociados tanto a la centralización de toda la información en una sola
base de datos como a sus características de registro en tiempo real de las
transacciones del negocio. Para esta dimensión se proponen tres beneficios: 1)
mejoras en la gestión de recursos; 2) mejoras en la toma de decisiones y en la
planificación; y 3) mejoras en el control del rendimiento.
3. Dimensión estratégica.
Las tecnologías de información en complemento con otros recursos pueden ser

fuente de ventajas competitivas. Para esta dimensión se proponen seis beneficios: 1)
apoyo al crecimiento de la empresa; 2) apoyo a las alianzas entre empresas; 3)
construcción de innovaciones de negocio; 4) construcción de un liderazgo en coste; 5)
generación de diferenciación de producto; y 6) construcción de enlaces externos (con
clientes y proveedores).
4. Dimensión infraestructura de tecnologías de información.
Los sistemas ERP no se asocian directamente con inversión en infraestructura de

tecnologías de información, como pueden ser las redes de telecomunicaciones y los
servidores centrales, sin embargo, esta tecnología provee una infraestructura
consistente en una arquitectura de aplicaciones estándar e integrada. Esta mejora en
infraestructura se ve reflejada en los siguientes beneficios: 1) construcción de
flexibilidad de negocio tanto actual como para futuros cambios; 2) reducción de los
costes de tecnologías de información; y 3) incremento de capacidades de la
infraestructura de tecnologías de información.
5. Dimensión organizacional.
Los beneficios organizacionales surgen del uso de un sistema ERP en términos de

focalización, aprendizaje y ejecución de las estrategias seleccionadas por la
organización. Se proponen cuatro beneficios: 1) cambios en los patrones de trabajo; 2)
facilitar el aprendizaje organizacional; 3) enriquecimiento del puesto de trabajo; 4)
construcción de una visión compartida.
2.3 Características.
Existen características que distinguen a un sistema ERP del software

empresarial de gestión usado históricamente por la microempresa.
Las tres características esenciales de un sistema ERP son:
- Integridad: Los ERP permiten controlar los diferentes procesos de la

compañía bajo la óptica de que todos los departamentos de una empresa se
relacionan entre sí, es decir, que el resultado de un proceso es punto de inicio del
siguiente. Por ejemplo, si un cliente hace un pedido esto representa que se crea una
orden de venta que desencadena el proceso de producción, de control de inventarios,
11
2. ERP
de planificación de distribución del producto, de cobro, y sus respectivos movimientos

contables. Si la empresa no usa un ERP y son soluciones departamentales no
integradas las que controlan todos los procesos mencionados, la información se
duplica y crece el margen de contaminación en ésta. Con un ERP, el usuario
simplemente captura el pedido y el sistema se encarga de todo lo demás, por lo que la
información no se manipula y se encuentra protegida.
- Modularidad: Los ERP se convierten en una herramienta que puede instalarse

de acuerdo con los requerimientos del cliente. Según se precisen de unas u otras
funcionalidades concretas se determinarán los módulos necesarios. Por ejemplo, si
una microempresa tiene la contabilidad externalizada no necesitará un módulo de
contabilidad en su ERP.
- Adaptabilidad: Los ERP pueden adaptarse a la idiosincrasia de cada

empresa. Esto se logra por medio de la configuración o parametrización de los
procesos de acuerdo con las salidas que se necesiten de cada uno.
Otras características propias de los sistemas ERP son:
- Procesar todas las transacciones que se producen en todos los departamentos

de la empresa.
- Tener un papel clave en la medición de resultados de la empresa al disponer
de toda la información de todas las transacciones de la empresa.
- Realizar un seguimiento, medir e informar de la evolución de los
acontecimientos sucedidos en la empresa u organización.
- Dar soporte a las funciones básicas del negocio o actividad.
- El sistema debe responder en caso que se produzcan cambios significativos en
los procesos y en las necesidades de información de la empresa.
- Debe permitir recoger la información de diferentes ubicaciones, procesarla y
ofrecerla a los distintos departamentos y usuarios.
- Debe ofrecer una alta adaptabilidad a la situación particular de cada empresa.
En algunos casos, incluso se ofrece al usuario final la utilización del código
fuente, pudiendo con ello realizar las modificaciones y adaptaciones a medida
de cada empresa.
- Deben tener la capacidad y facilidad para ser utilizados por diferentes usuarios
de diferentes áreas funcionales.
- Debe soportar el sistema de información dando todo el apoyo necesario para
que éste funcione y sea eficaz.
- El sistema ERP debe basarse en una única base de datos que permita
integridad, consistencia e integración de los mismos, permitiendo disponer de
los diferentes módulos interconectados y actualizados.
2.4 Arquitectura
2.4.1. Perspectiva funcional.
Desde una perspectiva funcional, debemos indicar que los sistemas ERP están
diseñados de forma modular. Cada uno de estos módulos o aplicaciones, tiene una
función específica. Cada organización determina que módulos necesita utilizar al
momento de implantar el ERP.
12
2. ERP
Figura 2. 2 Anatomía de un sistema ERP.
En la figura se puede observar el concepto de modularidad de un sistema ERP.

Apreciamos en la parte central una base de datos que trabaja en dos direcciones,
captando la información que proviene de distintas aplicaciones y entregando desde
sus repositorios la información que estas aplicaciones necesitan para apoyar las
diversas funciones de la empresa.
En relación a los módulos o aplicaciones, se puede indicar que, primero y más

cerca de los proveedores, las aplicaciones financieras, de manufactura, de inventario y
abastecimiento sirven a los trabajadores y administradores de tipo back-office. Un back
office (trastienda de la oficina) es la parte de las empresas donde tienen lugar las
tareas destinadas a gestionar la propia empresa y con las cuales el cliente no necesita
contacto directo. Por ejemplo: el departamento de informática y comunicaciones que
hace que funcionen los ordenadores, redes y teléfonos, el departamento de recursos
humanos, el de contabilidad, etc.
Más cercana a los clientes un segundo grupo de aplicaciones de ventas,

entrega y servicio apoyan tanto a las fuerzas de venta como a los representantes del
servicio al cliente y comerciales. Adicionalmente, los dos grupos de aplicaciones
nombradas se integran con las aplicaciones de gestión de recursos humanos y las
aplicaciones de reportes a gerentes y directivos. La integración entre todas las
aplicaciones se realiza por intermedio de los datos contenidos en los repositorios de la
13
2. ERP
base de datos. Esta integración permite que los datos sean ingresados en un solo
lugar y toda la información relacionada con éstos sea actualizada automáticamente.
Específicamente, las funciones de los sistemas ERP se pueden clasificar en

cuatro grandes grupos, dependiendo de los procesos de negocios que apoyen:
procesos de manufactura, procesos financieros y contables, procesos de ventas y
marketing, y procesos de recursos humanos. A continuación describiremos cada uno
de ellos:
- El grupo procesos de manufactura incluye aplicaciones que apoyan gestión

de inventario, compras, planificación de producción, y manutención de planta y
equipamiento.
- El grupo de procesos financieros y contables incluye aplicaciones que apoyan

las actividades asociadas tanto a cuentas a pagar como a cuentas a cobrar, y además
las relacionadas con gestión y presupuesto de flujos financieros, contabilidad de
costes de producción, contabilidad del activo fijo o inmovilizado, contabilidad general y
generación de informes financieros.
- El grupo de procesos de ventas y marketing incluye aplicaciones para

procesamiento de órdenes de venta, generación de listas de precios, distribución, y
facturación de productos y/o servicios, además de incorporar herramientas para
gestión y planificación de ventas.
- Por último, el grupo de procesos de recursos humanos incluye aplicaciones

que apoyan registro del personal, control de tiempos, cálculo de remuneraciones,
planificación y desarrollo del personal, contabilización de beneficios, seguimiento de
aplicaciones en los procesos de reclutamiento, e informes de gastos de viajes.
2.4.2. Perspectiva técnica.
Desde una perspectiva técnica, los sistemas ERP actuales están diseñados y
construidos utilizando dos elementos técnicos, una arquitectura cliente/servidor para
su operación, y una base de datos relacional que es un conjunto de una o más tablas
estructuradas en registros (líneas) y campos (columnas), que se vinculan entre sí por
un campo en común y que es la encargada de organizar todos los datos necesarios
para soportar las funcionalidades antes comentadas.
La arquitectura cliente/servidor es una configuración descentralizada que se

basa en un servidor que entrega servicios a un conjunto de clientes. El PC servidor
está especializado en ciertos servicios, por ejemplo en l a entrega de datos desde un
repositorio. Cada cliente pedirá los servicios al servidor cuando no puedan realizarlos
por sí mismos. La comunicación entre los clientes y el servidor se realiza por red en
los ERP de arquitectura Offline, y vía internet en los ERP de arquitectura Online. El
usuario interactúa solo con la porción del cliente en la aplicación, que generalmente
consiste en la interface de usuario, el proceso de captura de datos, la consulta a la
base de datos y la obtención de informes. El servidor realiza las funciones de fondo no
visibles por los usuarios, como la administración de los dispositivos periféricos y el
control de acceso a las bases de datos compartidas. La división exacta de las tareas
entre clientes y servidores depende de los requerimientos de las aplicaciones,
requerimientos de procesamiento, el número de usuarios y los recursos disponibles.
14
2. ERP
Figura 2. 3 Arquitectura cliente servidor.
Como observamos en la ilustración, que sintetiza la arquitectura

cliente/servidor, “n” clientes se comunican con un servidor cuando desean acceder a
los datos incorporados en un gran repositorio controlado por este último. La figura
presenta la configuración más simple de cliente/servidor, aunque es posible que exista
más de un servidor, cada uno de ellos especializado en un servicio, tales como
impresión, acceso a Internet, seguridad, etc.
Las bases de datos relacionales son un estándar en el actual desarrollo de

sistemas de información para la empresa y su denominación deriva del uso de un
modelo específico para organizar los datos. Una base de datos se puede definir como
una colección de datos organizada para dar servicio eficiente a muchas aplicaciones al
centralizar los datos y minimizar aquellos que son redundantes (Laudon, 2004). Para
crear y mantener una base de datos y permitir que las aplicaciones accedan a los
datos en ésta debe existir un Sistema Gestor de Bases de Datos(SGBD) que son un
tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el
usuario y las aplicaciones que la utilizan.
Existen distintos modos de organizar la información y representar las relaciones

entre los datos en una base de datos. Los sistemas gestores de bases de datos
utilizan con mayor frecuencia el modelo relacional, en este modelo se representan
todos los datos en la base de datos como sencillas tablas de dos dimensiones
llamadas relaciones. Las tablas son semejantes a una planilla Excel, donde cada
columna representa un atributo y cada fila una ocurrencia del dato. En la siguiente
ilustración se representa una base de datos que contiene datos sobre DNI, edad y
sexo de alumnos de una universidad organizada en una tabla. El sistema gestor de
base de datos controla esta organización y responde los requerimientos de cada una
de las aplicaciones (matrícula, pagos, etc.) que desean revisar, actualizar o eliminar
los datos almacenados en la base de datos.
15
2. ERP
Figura 2. 4 Bases de datos en sistemas ERP.
Algunas de las bases de datos más conocidas y utilizadas en los sistemas ERP
son:
- Oracle
- PostgreSQL
- MySQL
- SqlServer
2.5 Historia y evolución.
Los antecedentes de los ERP datan de la Segunda Guerra Mundial, cuando el

gobierno estadounidense empleó programas especializados que se ejecutaban en los
enormes y complejos ordenadores recién surgidos en el principio de la década de los
años 40 para controlar la logística u organización de sus unidades en acciones bélicas.
Estas soluciones tecnológicas, conocidas como los primeros sistemas para la

planeación de requerimiento de materiales (Material Requirements Planning Systems
o MRP Systems), son el antecedente histórico más remoto de los actuales ERP, los
cuales integraban las actividades de producción y compras.
Para el final de los años 50, los sistemas MRP brincaron las trincheras del
ejército para hallar cabida en los sectores productivos en especial de los Estados
Unidos de América. Las compañías que los adoptaron se dieron cuenta de que estos
sistemas les permitían llevar un control de diversas actividades como control de
inventario, facturación, y pago y administración de nómina.
De forma paralela, la evolución de la computación favoreció el crecimiento de

estos sistemas en cuanto al número de empresas que optaban por ellos. Claro que
16
2. ERP
estos ordenadores eran muy rudimentarios pero contaban con la capacidad de

almacenamiento y recuperación de datos que facilitaban procesar transacciones, es
decir, manejar información y canalizarla de manera apropiada a aquellas áreas que, al
integrarla, podían ejecutar acciones mucho más rápidas.
En las décadas de los años 60 y 70, los sistemas MRP evolucionaron para
ayudar a las empresas a reducir los niveles de inventario de los materiales que
usaban, ya que al planear sus requerimientos de insumos con base en lo que
realmente les demandaban, los costes se reducían, ya que se compraba sólo lo
necesario.
Para la década de los años 80 estas soluciones tecnológicas pasaron a usar

otras siglas: MRP II o planeación de los recursos de manufactura (Manufacturing
Resource Planning). Su alcance fue distinto: permitían atender factores relacionados
con la planeación de las capacidades de manufactura; un MRP II, a diferencia de los
sistemas previos, reconocía que las empresas padecían interrupciones en la
operación, cambios súbitos y limitaciones en recursos que iban más allá de la
disponibilidad de materiales.
Así, a principios de los años 90, había dos posiciones en el escenario de

soluciones tecnológicas para empresas: por un lado los MRP y por otro los MRP II.
Pero el mundo había cambiado y estas soluciones nacidas en los ambientes de
manufactura ya eran insuficientes para un mercado donde había organizaciones de
todo tipo: de servicios, financieras, comerciales, entre otras, que también necesitaban
una solución para controlar sus procesos y, en consecuencia, ser más competitivas.
MRP-II fue ampliado aun más para abarcar áreas como Ingeniería, Finanzas,
Recursos Humanos, Gestión de Proyectos, etc.; es decir la totalidad de las funciones
desarrolladas dentro de una empresa. Fue esta evolución lo que introdujo el concepto
ERP.
A continuación se puede observar gráficamente la evolución del ERP:
Figura 2. 5 Historia de los ERP.
17
2. ERP
Desde finales de la década de los noventa, los proveedores de planificación de

los recursos empresariales (ERP) que originalmente atendían las necesidades de las
empresas de fabricación han aumentado poco a poco su funcionalidad con el
propósito de cubrir los sectores de la industria que no se dedican a la fabricación. En
el 2000, cuando disminuyeron las implementaciones de ERP para la industria de
fabricación, los proveedores de ERP de primer nivel, como SAP y Oracle, ya se
estaban esforzando por comercializar sus soluciones integradas en los mercados
verticales orientados a los servicios -como asistencia sanitaria, gobierno, educación
superior, banca, seguros, etc.- que parecían más prometedores.
Actualmente, los proveedores de ERP adoptan una actitud agresiva al

comercializar sus funciones orientadas a los proyectos y específicas para la industria
de servicios. A diferencia de las mejores soluciones, estos sistemas ofrecen un
sistema de soporte maduro y completamente integrado que se desarrolló
originalmente para las industrias de fabricación. Por consiguiente, podríamos
preguntarnos ¿ERP para servicios es una categoría nueva? ¿O simplemente es “ERP
sin la fabricación”?
La respuesta a esas preguntas puede variar dependiendo de quién sea el

proveedor. Por un lado, los proveedores de ERP afirman que ERP para servicios es
una categoría de software bien desarrollada que se ha adaptado a las industrias de
servicios que atiende. Por otro lado, los proveedores de las mejores soluciones para
los segmentos verticales de servicios (como servicios profesionales, asistencia
sanitaria, gobierno y servicios financieros) se dedican a promover su experiencia en la
industria y las soluciones verticales que diseñan desde cero para dichas industrias de
servicios. Por consiguiente, las empresas que atienden las industrias de servicios
deben enfrentar el reto de determinar qué proveedores se adaptan mejor a sus
requisitos funcionales.
Definición de ERP para servicios.
La diferencia principal entre la funcionalidad de las mejores aplicaciones para

servicios y la ERP para servicios es el soporte. Las aplicaciones de ERP para servicios
ofrecen una funcionalidad completa para los componentes tanto de las transacciones
(o las operaciones) como los que se orientan a los proyectos de las empresas de
servicios. Pero por lo general, las mejores aplicaciones de servicios tratan únicamente
la funcionalidad específica de la industria. Algunos proveedores incluyen una parte de
soporte, pero otros únicamente entregan una funcionalidad vertical que se comunica
con los demás sistemas ERP o los conjuntos financieros. Así, existen dos categorías
de proveedores para empresas de servicios:
1. Los proveedores de las mejores soluciones para servicios. Soluciones como

Changepoint de Compuware y OpenAir PSA, se enfocan principalmente en
empresas de servicios profesionales y se comercializan en el mercado de las
pequeñas y medianas empresas (PYME). Sus ofertas pueden ser muy
variadas, y los proveedores tienden a enfocarse en ciertos segmentos
verticales clave del mercado. Los modelos de negocios varían de un proveedor
a otro y pueden ofrecer a los clientes software como servicio y modelos de
licencias.
2. Los proveedores de ERP para servicios. Por lo general, estos proveedores
ofrecen ERP tradicional que contiene la funcionalidad completa de soporte.
Dan a sus clientes funciones completas para las operaciones y las
18
2. ERP
transacciones, por lo tanto, sus productos tienen una aplicación más amplia.
Además de la funcionalidad orientada a los proyectos que ciertos proveedores,
como Epicor y Deltek, les ofrecen a las empresas de servicios profesionales,
los proveedores de ERP para servicios, como Lawson en el sector de la
asistencia sanitaria y Unit 4 Agresso en el sector público, proporcionan una
funcionalidad operativa completamente integrada para aquellas empresas que
no trabajan por proyecto.
La estrategia de ERP para servicios.
Las empresas que decidan evaluar soluciones para la industria de servicios, deben
identificar su estrategia específica del negocio. Las empresas de servicios más
pequeñas generalmente prefieren las mejores soluciones porque tienen un precio
bastante abordable (por lo general se ofrecen mediante un modelo de proveedor de
servicios de aplicación [ASP]) y pueden integrarse fácilmente con la infraestructura de
tecnología de la información (TI) existente. Normalmente, las empresas de servicios
más pequeñas cuentan con un conjunto financiero de proveedores como Microsoft o
Sage, que usan como componente de soporte, así que buscan una solución específica
para la industria que les proporcione la funcionalidad que necesitan para automatizar
completamente sus procesos. Si bien la inversión inicial que implica esta opción es
menor, el nivel de integración entre estos sistemas varía de una aplicación a otra
(incluyendo el nivel de mapeo de los campos, el uso del procesamiento en tiempo real
y el uso de procesamiento en lotes). Asimismo, la integración lista para usarse que
ofrecen los proveedores, casi siempre se limita a cierto número de sistemas
financieros, conjuntos de gestión de las relaciones con los clientes (CRM) y
herramientas de gestión de proyectos. Por consiguiente, los usuarios finales deben
tener extremo cuidado al identificar la solución que mejor se adapta a sus
necesidades.
Cuando se trata de empresas que buscan una solución integrada, los proveedores
de ERP han extendido su oferta para que abarque una funcionalidad centrada en los
productos y específica para la industria, aunada a capacidades maduras de soporte.
Pero estos proveedores siguen enfrentándose al reto de ofrecer las mejores
capacidades específicas de la industria, ya que muchos de sus productos se
desarrollaron en fechas posteriores (y en mucho caso se agregaron a la arquitectura
ERP que crearon para la industria de fabricación). Si bien estos sistemas tienden a
presentar menos problemas de integración, no es muy probable que sean muchos los
proveedores que ofrezcan la misma amplitud de funcionalidad que ofrecen los
proveedores de las mejores soluciones. No obstante, los proveedores de ERP son, por
lo general, mejores para ofrecer capacidades financieras y contables, además de que
tienen más experiencia en el servicio del mercado medio y el mercado empresarial.
ERP para servicios: más allá de la fabricación.
La ERP para empresas de servicios puede dividirse en dos categorías: empresas

orientadas a los proyectos y empresas de transacciones u operaciones.
Las empresas orientadas a los proyectos pertenecen al ámbito de automatización

de servicios profesionales (PSA) y requieren los componentes típicos del negocio que
ofrecen las soluciones PSA, tales como capacidades de gestión amplia del tiempo,
reportes de gastos, planificación de los recursos, gestión de carteras y gestión de
proyectos. Algunos de los proveedores que atienden este segmento son Oracle y SAP
19
2. ERP
en el mercado empresarial; Epicor, Deltek y Compuware en el mercado medio y

QuickArrow y OpenAir en el mercado de PYME alojadas.
Sin embargo, la ERP para empresas de servicios requiere una funcionalidad para
llevar a cabo operaciones y transacciones puras. Los mercados verticales, como
asistencia sanitaria, educación superior, gobierno, servicios financieros, hotelería y
organizaciones sin fines de lucro, entran en la categoría de ERP para servicios, ya que
los servicios que ofrecen son principalmente operaciones y transacciones (aunque a
veces estas industrias exigen funcionalidad orientada a los proyectos). Estos
mercados demandan funcionalidad de soporte estándar (como los módulos de
recursos humanos [RRHH] y finanzas) para establecer una interfaz con sus
necesidades específicas para la industria. Por consiguiente, varios proveedores de
ERP han desarrollado sistemas integrados que ofrecen soluciones de punta a punta a
varios mercados verticales. Existen varios ejemplos de industrias de servicio que están
en crecimiento y que son el blanco de los grandes proveedores de ERP.
1. Asistencia sanitaria. Los proveedores están ofreciendo funcionalidad específica

para la industria de gestión de pacientes, portales de asistencia sanitaria y
gestión de documentos clínicos o médicos. Algunos proveedores que ofrecen
soluciones específicas para asistencia sanitaria son SAP, Oracle y Lawson.
2. Sector público. Son varios los proveedores de ERP que ofrecen funcionalidad
específica para la industria de gestión de propiedades, gestión de activos,
gestión de servicios o instalaciones y gestión de las relaciones con la
ciudadanía. El mercado vertical gubernamental ha atraído a los principales
proveedores de ERP, como SAP y Oracle, así como a otros más pequeños,
como Hansen , Unit 4 Agresso y CGI Momentum .
3. Servicios financieros. Los proveedores ofrecen sistemas centrales de banca y
seguros, gestión del capital humano (HCM) y abastecimiento. Algunos de los
proveedores dedicados a este mercado son Epicor, Apptricity y Oracle.
Las empresas de servicios que estén buscando funcionalidad en su segmento

vertical específico deben estar conscientes de que ha habido un cambio en el mercado
del software para servicios. En los últimos años, muchos proveedores de las mejores
soluciones se han consolidado, como ha sucedido en el mercado de PSA, donde
proveedores como Compuware y Evolve han dejado de enfocarse en este campo. Así,
los usuarios deben decidir entre proveedores pequeños de PSA que tienen
experiencia en la industria o proveedores grandes de ERP que ofrecen una
funcionalidad más amplia para las empresas de servicios. Antes de seleccionar un
proveedor, las empresas deben identificar los requisitos funcionales que son más
relevantes para su negocio, para así poder evaluar con precisión las soluciones que
tienen a su disponibilidad.
Las empresas que busquen el eslabón perdido entre su sistema financiero y sus
requisitos específicos para la industria, deben pensar en los proveedores de las
mejores soluciones que tengan mucha experiencia en su segmento vertical del
mercado. En la mayoría de los casos, estos proveedores cuentan con productos que
se integran con los sistemas dispares y consolidan satisfactoriamente los procesos de
negocios de las empresas de servicios. Los usuarios que busquen reemplazar o
actualizar sus sistemas actuales, deben pensar en recurrir a los proveedores de ERP,
ya que pueden ser ellos quienes les proporcionen la funcionalidad específica de la
industria que requieren, dentro de un sistema completamente integrado. Asimismo, a
medida que los proveedores de ERP sigan aumentando su participación en el
mercado de servicios, los proveedores grandes de ERP desarrollarán funciones
específicas para la industria más fuerte y generarán un panorama más competitivo en
20
2. ERP
el mercado de ERP para servicios. Por consiguiente, el sector de servicios debe

esperar una mayor consolidación entre los proveedores de las mejores soluciones y
los grandes proveedores de ERP que poco a poco van dominando el espacio.
2.6 Diferencias entre un CRM y un ERP
ERP y CRM son dos términos que muy a menudo se vinculan a algunos
conceptos donde los límites que incluyen cada uno no están tan claros. Esto puede
hacer que sea difícil para una persona sin conocimientos técnicos comprender con
claridad estos conceptos.
En términos simples, ERP y CRM son muy similares, pero diseñados para
diferentes propósitos. Ambos son aplicaciones que permiten a los empleados
compartir información y coordinar toda la organización además de dar acceso a los
ejecutivos a los informes y pronósticos basados en los datos recogidos en estos
sistemas.
En principio, las empresas sólo pueden crecer sus ganancias en dos formas:
Aumentar las ventas o reducir los costos. Estas pueden ser consideradas como dos
fuerzas opuestas, lo que requiere dos estrategias completamente diferentes.
Por esta razón, tiene sentido para las organizaciones gestionar estas dos fuerzas
por separado, es decir:
 Los clientes y las ventas se pueden gestionar a través de un sistema de

Customer Relationship Management (CRM)
 Los empleados y la productividad pueden ser manejados a través de un
sistema de planificación de recursos empresariales (ERP)
Customer Relationship Management (CRM).
La mayoría de las empresas nuevas o en crecimiento son tan sencillas que no

necesitan un sistema integrado para gestionar su flujo de trabajo. Para ellos, el
verdadero reto es conseguir los primeros clientes y probar el modelo de negocio.
Sin embargo, debido a que la adquisición de clientes es un centro de costos desde

el principio (pocas empresas no tienen vendedores), no hay duda que el valor que se
obtiene al tener un único sistema que combina marketing, ventas, gestión de contactos
y soporte al cliente es sumamente importante. Además, cuando se combinan estas
áreas de la empresa en un único sistema es posible tener una visión de alto nivel
sobre el progreso de sus actividades de marketing y localizar las áreas de mejora.
Un buen CRM también debe ayudar a pronosticar los ingresos mediante el

seguimiento de los avances de cada oportunidad. Muchos sistemas de CRM
modernos incluso ofrecen funciones de marketing y automatización de ventas, como el
seguimiento de oportunidades, presupuestos y facturas de forma automática.
Reduciendo de esta forma la cantidad de trabajo que nunca es poca en una empresa
nueva o pequeña.
El CRM no es un Software, es una idea o estrategia a seguir en la empresa

apoyada por un cierto sistema o aplicación. En principio cualquier gestor de correos
puede servir como un primitivo software CRM. La problemática del CRM es simple,
dado un producto que se vende a los clientes se añade cierta garantía o valor añadido
al mismo ofreciendo soporte o lo que sea necesario, para ser mejor que la
21
2. ERP
competencia. El CRM de hecho suele estar vinculado al departamento de calidad, que

conforme crezca la empresa adquiere un papel cada vez más importante. Dentro de
una empresa son multitud de funciones como telemarketing, atención telefónica,
garantía de producto, e-commerce, sitio web... etc. El modulo CRM dentro del sistema
ERP es solo una pequeña porción de la idea general de Customer Relationship
Management. De hecho a veces el CRM está presente sin estar incluido. Con un ERP
por ejemplo podrían gestionar las reclamaciones de los clientes, las devoluciones del
producto, la facturación total para cada uno, la extensión de la garantía, el portal web,
ficha técnica del producto y mucho más dada la facilidad para obtener la trazabilidad.
Todo ello sirve para tener una respuesta eficiente y rápida a la hora de atender
cualquier necesidad.
Planificación de recursos empresariales (ERP).
Una vez que la compañía ha alcanzado cierta masa crítica, llegan a un punto
donde la reducción de costos se convierte en una forma eficaz de generar ingresos(Es
más fácil de reducir costos en un 5% más que para aumentar las ventas en un
5%).Otro de los retos presentados por el crecimiento es la falta de organización que
puede conducir a costosos errores y la insatisfacción de los clientes. Mantener un
cliente antiguo es 5 veces más fácil que conseguir uno nuevo.
Este suele ser el momento en que una empresa va a empezar a buscar un sistema
ERP.
El Software ERP ha estado en el mercado durante bastante tiempo ya aunque por

lo general se asocia a la grandes empresas un sistema ERP también puede ser una
ventaja competitiva en la PyME.
Por lo general los ERP se han centrado estrictamente en las áreas operativas de la
empresa, tales como Finanzas, Recursos Humanos, Producción y Gestión de Pedidos.
Entre las ventajas de un ERP podemos encontrar:
 Los sistemas ERP ayudan a estandarizar los procesos de negocio, asegurando

que la información sigue siendo estructurada y útil. Esto es crítico cuando se
tiene 5 departamentos diferentes – cada uno con 10 empleados - y todos los
datos de generación de negocios.
 Gracias al uso de un ERP, los empleados de la organización puede encontrar,

almacenar y compartir información desde un repositorio centralizado. Esto
asegura que los procesos de flujo de trabajo más eficiente y con menos
errores, al tiempo que elimina la necesidad de transferir, volver a entrar o datos
duplicados.
 Para los ejecutivos un sistema ERP puede dar una visión clara de la situación
de la organización, y apoyar en la localización de oportunidades para la mejora
en la eficiencia y la productividad. Aquí es donde el valor real de ERP puede
verse.
22
2. ERP
A pesar de que los sistemas ERP – en el sentido tradicional del término – han sido
utilizados en el contexto de procesos operativos internos, los sistemas modernos
también han cruzado a otras áreas, tales como los que tradicionalmente cubiertas por
un sistema de CRM.
Conclusión.
Un CRM es una aplicación que permite la gestión comercial, de marketing y

atención al cliente. Aunque siempre es posible agregar módulos a ad-hoc
generalmente cubre estos aspectos. Y un ERP se encuentra orientado hacia áreas
operativas de la empresa, tales como Finanzas, Recursos Humanos, Producción.
Es decir que pese a que son sistemas similares están diseñados para distintos
fines. Cuando usar un CRM o un ERP dependerá principalmente del grado de
madurez de la empresa, sus operaciones y los beneficios que puede obtener en cada
caso respectivamente.
Por otra parte un ERP puede no tener un modulo CRM, pero si actuar como tal en
su conjunto (CRM no es software, es política de gestión de relación con los clientes). A
la hora de elegir uno, hay que considerar las ventajas que ofrece uno u otro a la hora
de gestionar la relación con los clientes existentes o que valor añadido puede ofrecer.
La trazabilidad por ejemplo puede mejorar la garantía y calidad del producto.
2.7 Ventajas e inconvenientes de los sistemas ERP
El tener un sistema ERP implantado dentro de la organización no significa que

la empresa ya tenga el futuro asegurado. Es necesario ver las ventajas y desventajas
de los distintos paquetes de Software que mejor se adapten a las necesidades de la
empresa.
La cultura de la organización será un factor clave para el éxito de la

implantación. Se debe conocer cómo involucrar al personal de la empresa y evitar que
exista una resistencia al cambio que indudablemente sufrirá la organización.
Entre los factores de éxito del mismo se pueden citar: la mejora de los
procesos, involucramiento del personal, capacitación, cultura, aceptación y selección
adecuada, etc.; pero la clave está en el compromiso y la dedicación que merece una
inversión de este tipo, que puede llevar a la empresa a la operatividad y eficiencia
financiera o a la quiebra.
Antes de implantar un ERP, es importante que la empresa considere los

beneficios que desea obtener para su organización para que sean base de los
requerimientos para la implantación del nuevo sistema.
2.7.1 Ventajas
- Acceso a información fiable. Este beneficio se logra por:
 El uso de una base de datos común.

 La consistencia y exactitud de los datos.
 Las mejoras en los informes del sistema.
23
2. ERP
- Evita redundancia de datos y operaciones: Como los distintos módulos del

sistema ERP acceden en tiempo real a la misma base de datos central, se evitan dos
cosas:
 Los registros duplicados o múltiples de los mismos datos en el sistema.

 La duplicación de las operaciones por falta de actualización del registro sobre
ellas.
- Reducción del tiempo de ciclo y de entrega. Este beneficio se logra, por una
parte, al minimizar el proceso de recuperación, y por otra, al realizar informes sobre los
retrasos de producción o entrega.
- Reducción de costos. Esta reducción se debe tanto a la economía de tiempo,

como a las mejoras en el control y en el análisis de las decisiones empresariales.
-Fácil adaptabilidad. Los sistemas ERP se pueden modificar a través de la

redefinición de sus distintos procesos de negocio, esto hace fácil que se adapte y
reestructure para satisfacer los nuevos requerimientos.
-Mejoras en “escalabilidad”. Debido a un diseño modular y estructurado los

sistemas ERP permiten realizar adiciones de funciones para aumentar o escalar la
solución inicial.
- Mejoras en el mantenimiento. La existencia de un contrato a largo plazo de

mantenimiento con el proveedor, como parte de la adquisición de sistema ERP, hace
que mejore el proceso de mantener el sistema de información al día de los avances
tecnológicos y de gestión.
- Alcance fuera de la organización. Los módulos de extensión de los sistemas

ERP como son los CRM (Customer Relationship Management - Gestión de la relación
con el cliente), y los SCM (Supply Chain Management - Gestión de la cadena de
abastecimiento) hacen que la organización se integre con clientes y proveedores,
fuera de los límites tradicionales de la empresa.
- Comercio electrónico y e-business. Por una parte esto es posible debido a que la
infraestructura tecnológica de los sistemas ERP soportan procesos en Internet, lo que
es básico para el comercio electrónico, y por otra parte, a que la adopción de los
sistemas ERP desarrolla una cultura de colaboración entre negocios.
A las ya señaladas se le pueden añadir las siguientes:
- Tener un flujo eficiente de información y transaccional íntegro a través de las

diferentes áreas de la empresa, unidades de negocio y áreas geográficas hace que se
tengan beneficios aún mayores, sobre todo en cuestión de tiempos y acceso a la
información.
- Los procesos de planificación estratégica, manejo de recursos humanos,

optimización de recursos, reducción de costos y capacidad de atención a clientes y
proveedores se ven beneficiados, en tiempo y costo, por el manejo de sistemas
integrados de este tipo.
- Se optimizan los procesos empresariales y se incrementa la capacidad de

proporcionar información confiable y en tiempo real.
24
2. ERP
-Mejoras en cuanto al servicio al cliente y atención de los mismos, Así como mayor
competitividad conforme haya cambios en el medio.
2.7.2 Inconvenientes
Las principales limitaciones y obstáculos importantes que puede suponer la

existencia de un ERP en una empresa son los siguientes:
- La implantación de un sistema ERP implica no solo enormes cambios en la

infraestructura de tecnologías de información de la organización, sino también implica
dramáticos cambios en los procesos de negocio, en la estructura y en cultura de la
empresa. Las organizaciones que no entiendan que deben realizar un proceso de
implantación del sistema ERP que considere todos estos cambios tendrán problemas
en su implantación o no alcanzarán altos niveles de integración entre procesos de
negocios y funciones de la empresa.
- Superación del análisis costo/beneficio. Los costos de un sistema ERP son

altos, se realizan por adelantado, son muy visibles, y muy a menudo son cobrados
políticamente. En cambio, los beneficios casi invariablemente no pueden ser
cuantificados al comienzo de un proyecto, y estos solo serán visibles cuando el
sistema comience a operar, y quizás, un tiempo después de ello.
- La inflexibilidad del sistema ERP. Tanto la tendencia a ser sistemas

complejos, y por ende, difíciles de dominar totalmente, como la existencia de pocas
personas a nivel mundial con experiencia en su instalación y mantenimiento,
contribuyen a que un sistema ERP pueda transformarse en inflexible. Es más, si
consideramos que este tipo de software está profundamente interrelacionado con los
procesos de negocios de la empresa, cuando una compañía necesite realizar grandes
cambios en su organización deberá imperiosamente modificar el sistema ERP, pero
esta modificación puede ser tan dificultosa como realizar los cambios en los viejos
sistemas de información que fueron reemplazados por el ERP.
- Alcanzar beneficios estratégicos. Si una organización adopta procesos de

negocio que nacen de los modelos genéricos que proporciona el proveedor del
sistema ERP puede dejar de utilizar aquellos procesos de negocios únicos que han
sido fuente de sus ventajas sobre la competencia. Asimismo, para algunas
organizaciones la centralización de la coordinación y la toma de decisiones promovida
por los sistemas ERP puede no ser la mejor forma de operar. Algunas empresas
claramente no necesitan el nivel de integración que proporcionan los sistemas ERP.
- El éxito depende en las habilidades y la experiencia de la fuerza de trabajo,

incluyendo la educación y como hacer que el sistema trabaje correctamente. Muchas
compañías reducen costos reduciendo entrenamientos. Los propietarios de pequeñas
empresas están menos capacitados, lo que significa que el manejo del sistema ERP
es operado por personal que no está capacitado para el manejo del mismo.
Hay que prestar atención a los costes indirectos. Los vendedores del ERP
pueden cargar sumas de dinero para la renovación de sus licencias anuales, que no
está relacionado con el tamaño del ERP de la compañía o sus ganancias. Además,
Una vez que el sistema esté establecido, los costos de los cambios son muy altos
(reduciendo la flexibilidad y las estrategias de control).
25
2. ERP
-Los ERP son vistos como sistemas muy rígidos, y difíciles de adaptar al flujo
específico de los trabajadores y el proceso de negocios de algunas compañías.
-Alguna información está organizada en módulos de manera muy compleja, lo

cual lo hace poco práctico, y poco funcional el navegar entre varias opciones del
sistema. Para reducir esta limitación hay que capacitar más al personal en cuanto al
uso del sistema, organización de los datos y obtención de la información.
-Existe dificultad para integrar la información de otros sistemas independientes,

o bien que están en otra ubicación geográfica. Esto se da más frecuentemente con
empresas que tienen unidades distribuidas en otras localidades, o bien que manejen
varios proveedores.
- No existe flexibilidad en cuanto a la personalización y elaboración de algunos

reportes necesarios por la empresa para la obtención de información. Lo cual debería
ser independiente del área de sistemas. Sobre todo hay que considerar que sea la
información requerida, en un formato adecuado y oportunamente.
Otros puntos negativos de la implantación de un ERP son:
 Cambio de personal, las compañías pueden emplear administradores que no

están capacitados para el manejo del sistema ERP de la compañía,
proponiendo cambios en las prácticas de los negocios que no están
sincronizados con el sistema.
 Los sistemas pueden ser difíciles de usar.
 Una vez que el sistema esté establecido, los costos de los cambios son muy
altos (reduciendo la flexibilidad y las estrategias de control).
 La resistencia en compartir la información interna entre departamentos puede
reducir la eficiencia del software.
 Hay problemas frecuentes de compatibilidad con algunos de los sistemas
utilizados anteriormente en la empresa.
 Los sistemas pueden estar saturados relativamente a las necesidades del
consumidor.
2.8 Tipos de ERP.
Hay múltiples clases de clasificaciones de ERP que los dividen en diferentes

tipos atendiendo a diferentes criterios. Para este proyecto se ha optado por definir dos,
la que clasifica según la adaptabilidad y la que lo hace en función de la propiedad.
2.8.1 Adaptabilidad.
En general hay que elegir entre dos aproximaciones diferentes para un ERP. El
software a medida o solución estándar. La primera aproximación significa que se va a
desarrollar un programa a medida, prácticamente de cero y la segunda es que ya está
desarrollado y simplemente hay que adaptarlo. A veces podría ser difícil decidirse,
pero existen un dicho muy usado en la ingeniería del software: "No reinventes la
rueda". Si ya existe una solución ya parecida funcionando en empresas de
competencia y les va bien con ella, sería muy recomendable o al menos hay que
tenerla de referencia.
26
2. ERP
2.8.1.1 Software a medida.
Es un sistema creado específicamente para la empresa, prácticamente de cero.

El desarrollo e implantación es muchísimo más largo que una solución estándar.
Además es mucho más costoso y conlleva más peligro. Sin embargo tiene una ventaja
muy grande, la aplicación resultante será adaptada perfectamente al negocio. Por
ejemplo en una solución a medida normalmente el 90% de las opciones serán
prescindibles, nunca se usarán. Pero como se ha dicho es peligroso por varias
razones, una de ellas es que suceda cualquier problema con la consultora informática
que ha desarrollado la aplicación. Una solución a medida provoca dependencia con
una determinada empresa y eso conlleva cierto peligro. Quizás por ello hay que fijarse
especialmente en la solidez de esta.
2.8.1. 2 Solución estándar o modular.
Muchas PYMES por ejemplo eligen esta solución ya que simplemente no

pueden permitirse una solución a medida. Estas aplicaciones son mucho más baratas
y más rápidas de implantar. Se puede pedir tantos módulos como se necesiten, por
eso se llaman modulares o por paquetes. Por ejemplo se puede pedir modulo de
almacén, compra, pedidos, facturación, CRM… etc. Si alguna vez la consultora
informática desaparece o se rompe el acuerdo de mantenimiento, siempre se podrá
encontrar otra, ya que es una aplicación estándar. Normalmente existe una compañía
grande detrás que ofrece un soporte general y otras más pequeñas que realizan las
implantaciones, mantenimiento o adaptaciones.
Habitualmente es muy difícil elegir una aplicación concreta para el negocio por
coste o simplemente por los requisitos, en este caso todas las aplicaciones son
diferentes, todos los comerciales intentan vender su producto. Por lo que elegir una
aplicación estándar es complicado.
Dentro de las soluciones estándar existen aplicaciones generalistas o

verticales.
Un ERP vertical normalmente está orientado o desarrollado para un sector

específico. Por ejemplo existen soluciones orientadas a un tipo de negocio en sí. En
España existe software desarrollado especialmente diseñado para la gestión de
almazaras o bodegas. Son soluciones recomendables, pero quizás muy cerradas al
crecimiento. De todas formas es interesante tenerlos en cuenta.
Las soluciones generalistas básicamente son para empresa “general”,

simplemente hay que adaptarlos al negocio muchísimo más, no están pensadas para
algo especifico.
En resumen las aplicaciones a medida son mejores, más caras y más lentas
además de la dependencia a la empresa en mayor medida. Las aplicaciones
modulares son más baratas, más rápidas de implantar pero más difíciles de elegir.
2.8.2 Propiedad de la licencia.
2.8.2.1. Software Propietario.
Los sistemas propietarios son aquellos que requieren del pago de una licencia
para poder ser utilizados. Esta licencia se suele pagar por número de puestos
27
2. ERP
operativos y puede llegar a representar un 50% de la implantación total del sistema.

De esta forma, el precio total suele encarecerse llegando en algunos casos a cotas
que la microempresa difícilmente puede asumir si no tenemos en cuenta las
posibilidades de financiación. Existen sistemas ERP propietario que pertenecen a
grandes desarrolladoras de software como Sage, SAP o Microsoft y otros creados por
pequeñas empresas como Solmicro y Deister. Los primeros suelen disponer de un
producto maduro, sólido, y con mayor soporte .Los segundos suelen estar más
especializados en un sector concreto. Se debe tener precaución en el segundo caso
ya que se dependerá de una empresa que tiene mayores probabilidades de ser
absorbida o desaparecer que una gran corporación.
Ventajas ERP propietario.
- Control de calidad. Las compañías productoras de software propietario por lo

general tienen departamentos de control de calidad que llevan a cabo muchas pruebas
sobre el software que producen.
- Recursos a la investigación. Se destina una parte importante de los recursos

a la investigación sobre los usos del producto.
-Personal altamente capacitado. Se tienen contratados algunos programadores

muy capaces y con mucha experiencia.
-Uso común por los usuarios. El software propietario de marca conocida ha

sido usado por muchas personas y es relativamente fácil encontrar a alguien que lo
sepa usar. Y no sólo eso, también dispones de miles de testeadores diarios del
software, lo que conlleva una ágil forma de encontrar problemas en el software y de
solucionarlos.
-Software para aplicaciones muy específicas. Existe software propietario

diseñado para sectores muy específicos que no existen en ningún otro lado más que
en la compañía que lo produce.
- Difusión de publicaciones acerca del uso y aplicación del software. Existe

gran cantidad de publicaciones, ampliamente difundidas, que documentan y facilitan el
uso de las tecnologías que proveen las compañías de software propietario, aunque el
número de publicaciones orientadas al software libre va en aumento.
Inconvenientes ERP propietario.
- Cursos de aprendizaje costosos. Es difícil aprender a utilizar eficientemente el

software propietario sin haber asistido a costosos cursos de capacitación.
- Secreto del código fuente. El funcionamiento del software propietario es un

secreto que guarda celosamente la compañía que lo produce. En muchos casos
resulta peligrosa la utilización de un componente que es como una caja negra, cuyo
funcionamiento se desconoce y cuyos resultados son impredecibles. En otros casos es
imposible encontrar la causa de un resultado erróneo, producido por un componente
cuyo funcionamiento se desconoce.
- Soporte técnico ineficiente. En la mayoría de los casos el soporte técnico es

insuficiente o tarda demasiado tiempo en ofrecer una respuesta satisfactoria.
28
2. ERP
- Ilegal o costosa la adaptación de un módulo del software a necesidades

particulares. Es ilegal extender una pieza de software propietario para adaptarla a las
necesidades particulares de un problema específico. En caso de que sea vitalmente
necesaria tal modificación, es necesario pagar una elevada suma de dinero a la
compañía fabricante, para que sea esta quien lleve a cabo la modificación a su propio
ritmo de trabajo y sujeto a su calendario de proyectos.
- Derecho exclusivo de innovación. La innovación es derecho exclusivo de la

compañía fabricante. Si alguien tiene una idea innovadora con respecto a una
aplicación propietaria, tiene que elegir entre venderle la idea a la compañía dueña de
la aplicación o escribir desde cero su propia versión de una aplicación equivalente,
para una vez logrado esto poder aplicar su idea innovadora.
- Ilegalidad de copias sin licencia para el efecto. Es ilegal hacer copias del
software propietario sin antes haber contratado las licencias necesarias.
- Imposibilidad de compartir. Si una empresa tiene funcionando exitosamente

un sistema dependiente de tecnología propietaria no lo puede compartir con otras
empresas a menos que cada una de éstas contrate todas las licencias necesarias.
- Quedar sin soporte técnico. Si la compañía fabricante del software propietario

se va a la banca rota el soporte técnico desaparece, la posibilidad de en un futuro
tener versiones mejoradas de dicho software desaparece y la posibilidad de corregir
los errores de dicho software también desaparece. Los clientes que contrataron
licencias para el uso de ese software quedan completamente abandonados a su
propia suerte.
-Descontinuación de una línea de software. Si una compañía fabricante de

software es comprada por otra más poderosa, es probable que esa línea de software
quede descontinuada y nunca más en la vida vuelva a tener una modificación.
- Dependencia a proveedores. En la mayoría de los casos el gobierno se hace

dependiente de un solo proveedor.
-Nulidad de desarrollo tecnológico de la industria nacional, respecto de la extranjera

(las aplicaciones de consumo masivo se desarrollan en otros países).
2.8.2.2. Software Libre.
Una buena alternativa a los ERP propietario son los sistemas ERP Opensource
o de software libre. Aunque se tiende a pensar: “si es libre es gratis”, esto no es del
todo cierto, así como no es cierto tampoco que todo software Opensource esté hecho
por un grupo de gente sin ánimo de lucro. Las empresas desarrolladoras de este tipo
de sistemas suelen tener una comunidad de “partners” que ofrecen servicios de
implantación, configuración, parametrización y formación de usuarios en sus
aplicaciones ERP. Además, ofrecen para nuevos partners o clientes que desean
implantar la solución de forma independiente (en su propia empresa, por ejemplo),
unos cursos de entrenamiento o capacitación. Sin estas opciones es muy difícil llevar a
cabo la configuración, parametrización e implantación del sistema, ya que podemos
estar mucho tiempo averiguando su funcionamiento interno, pues suelen ser muy
complicados de modificar/adaptar.
Además, usando aplicaciones de código abierto, se asegura un buen servicio,

ya que si la empresa proveedora del software no da un buen trato al cliente, éste
29
2. ERP
puede elegir que otra empresa le dé el soporte sin cambiar de aplicación. En cambio,
con aplicaciones propietarias, se depende del proveedor, que puede subir los precios
cuando y cuanto quiera o no hacer las modificaciones que le pidas, porque conoce que
cambiar el sistema de información en tu negocio acarrearía unos costes desorbitados.
Los proyectos Opensource se basan en la entrega y garantía de libertades al

usuario final. El Software Libre es el que da:
 Libertad para usar el programa para cualquier actividad.

 Libertad para el acceso y la modificación del código.
 Libertad para la libre distribución de la aplicación, modificado o no.
Ventajas
-Se tiene una licencia. Siempre será mejor usar un producto Opensource a usar
uno propietario pirateado.
-Se tiene el código fuente. Siempre puede modificarse y adaptarlo a las

necesidades. Incluso se puede reparar errores que se detecten, incluir parches
realizados por otros usuarios, modificarlo para que se ejecute en otro sistema
operativo, o para que interactué con otra base de datos, etc.
-Se puede obtener soporte de los desarrolladores o de cualquier empresa o

persona que ofrezca confianza y tenga la formación adecuada.
Inconvenientes
- Puede estar sin terminar. De hecho, muchos proyectos Opensource se

caracterizan por no ofrecer todas las funcionalidades que oferta el software propietario.
Poco a poco, los proyectos se van completando, pero es evidente que muchos tienen
aún trabajo que hacer.
- Puede cambiar la licencia, por ejemplo a una cerrada, motivado por la falta de
beneficios.
- Costes ocultos. Resulta muy difícil, por la propia complejidad de estos

proyectos, entender la arquitectura de los mismos si no se recibe formación.
Igualmente, es muy complicado implantar una de estas soluciones sin la formación por
parte del desarrollador. Así pues resulta necesario pagar la formación, en lugar de la
licencia. Aunque en el software propietario hay que pagar las dos, ya que los usuarios
requieren formación. También hay que plantearse el coste de la interoperabilidad con
otras aplicaciones, propietarias o no, que tengamos funcionando.
- Falta de responsabilidad. El software Opensource se suele entregar sin

garantía de ningún tipo. Por lo tanto, es necesario tener buenas referencias del
software que estemos implantando, para reducir la posibilidad de problemas. Además,
siempre se puede contratar un servicio de mantenimiento que, si bien garantiza el
software, permite solucionar la mayor parte de los problemas.
30
2. ERP
2.8.2.2.1 Alimentación económica de los ERP Opensource.
A pesar de que el software es gratuito si existe un beneficio de la aplicación.
Subvenciones.
Muchos proyectos están subvencionados por diferentes estamentos. Por

ejemplo, en el caso del ERP de software libre Openxpertya, el proyecto está
subvencionado desde su comienzo por el principado de Asturias y ministerio de
FYCYT (Fundación para el Fomento en Asturias de la Investigación Científica). Otro
ejemplo es Openbravo. Éste proyecto, el más descargado en sourceforge en 2006,
está subvencionado por SODENA (Sociedad de Desarrollo De Navarra).
Cursos de entrenamiento o capacitación.
Normalmente los ERP de software libre, ponen a disposición unos cursos de

entrenamiento o capacitación. Estos cursos se utilizan para enseñar la herramienta en
aspectos funcionales, técnicos, etc.; para desarrolladores o usuarios que quieran
implementar el ERP.
Certificación de partners.
Para que la comunidad vaya creciendo, se va creando una red de partners. Los
partners suelen ser empresas que, bajo la colaboración conjunta de toda la red,
realizan la implantación de la herramienta y otros servicios derivados de ello. Los
partners, por su condición de serlo, pagan una cantidad económica de la cual se
beneficia toda la comunidad. A cambio, tiene derecho a las mejoras y actualizaciones
de la herramienta que la red de partners vaya desarrollando.
Soporte.
En algunos proyectos existe la posibilidad de obtener soporte. Éste soporte

suele comprarse por un determinado tiempo, en horas, para consultas sobre la
herramienta.
Documentación.
Otros proyectos crean documentación, tal como manuales de usuario, de

desarrolladores, etc.; y no los comparten libremente. Para obtenerlos hay que
comprarlos.
Roles que se encargan de realizar las tareas anteriores.
Para llevar a cabo todas estas tareas y otras, los desarrolladores o empresas
dedicadas a ello pueden adoptar diferentes roles como los que siguen:
-Implantadores: Instalan el software, lo parametrizan, migran los datos del

sistema anterior, forman a los usuarios, posiblemente mejoran los procesos de
negocio, realizan el mantenimiento correctivo y evolutivo del aplicativo una vez
instalado, etc. Aquí nos podemos encontrar a empresas consultoras o integradoras de
sistemas.
31
2. ERP
-Productores: Compañías que desarrollan un software y lo liberan, cobrando

por añadir personalizaciones o mejoras, y formar a otras para que puedan instalar el
aplicativo.
-Mejoradores: Particulares o compañías que se dedican a mejorar y

personalizar el aplicativo para adaptarlo a la empresa cliente.
-Integradores: Empresas que a partir de módulos independientes entre sí

consiguen juntarlos y ofrecer un paquete como solución completa. Por ejemplo, se
coge el módulo financiero del ERP A se integra con el aplicativo CRM B, con el módulo
de gestión de almacenes y distribución de C y obtienes un ERP completo. La empresa
cobra por ofrecerte el paquete de instalación integrada.
-Servicios de soporte o help-desk: desde el puro soporte técnico hasta soporte

funcional a los usuarios del sistema de gestión.
-Formadores: A profesionales, demandantes de empleo o a usuarios finales; en

cursos, seminarios, libros, etc.
Conviene aclarar que estos roles no son excluyentes entre sí.
2.8.2.3. Software Saas.
SaaS es un acrónimo que significa Software as a Service. Consiste en facilitar

gratuitamente las licencias del software, pero cobrar el mantenimiento, alojamiento de
archivos, acceso o otros servicios. Algo muy parecido por ejemplo al renting de
cualquier tipo. Vulgarmente se podría llamar “alquiler”.
En cuestión de desembolso económico, no hay que realizar ningún esfuerzo

inicial grande para empezar. El coste inicial en servidores y licencias es cero. Así
como tampoco hay que actualizar maquinas cliente ya que generalmente este tipo de
solución funciona en el navegador. A día de hoy las soluciones SaaS son realidad
sobre todo en países fuertemente desarrollados como Estados Unidos o Japón. Por
llamarlo de algún modo es el futuro de cualquier software. Por ejemplo Google
funciona como una gran aplicación SaaS donde está el correo, alojamiento,
herramientas office, calendario... etc.
En los últimos 4 o 5 años, el concepto de "la nube" o "cloud" ha contribuido de

una forma espectacular al desarrollo de este tipo de soluciones. Las compañías como
Google y sobre todo Amazon te alquilan una porción en su inmensa red de servidores
por un precio tan bajo que ronda céntimos por 1Gb. Esto ha permitido a numerosas
compañías grandes o pequeñas a acceder a estos servicios por precios ridículos y
reducir sus costes considerablemente y aumentar la flexibilidad.
Ventajas.
El alquiler de Software de estas dimensiones tiene grandes ventajas
-Infraestructuras y equipo humano. Se eliminan los servidores de la oficina con

el consiguiente beneficio de espacio, reducción de la factura de la luz, personal técnico
encargado de mantenerlo, el problema de constantes actualizaciones de hardware y
software, cuelgues... etc.
32
2. ERP
-Seguridad y Fiabilidad. Los datos teóricamente estarán más seguros y 24

horas accesibles. Aunque esto último depende mucho de la compañía proveedora de
servicio. Pero una pérdida de datos es algo realmente complicado e improbable ya que
los servidores que los tienen tendrán unas políticas de seguridad y de mantenimiento
mucho más rigurosas que en cualquier oficina. Si se trata de la nube, es altamente
improbable la caída de servicio o cualquier pérdida de información. Por poner un
ejemplo es difícil concebir que www.google.es deje de funcionar.
-Flexibilidad de costes. El coste se reduce a corto plazo. La inversión inicial

normalmente es 0 y después cada mes se paga una cuota dependiendo del número
de usuarios, módulos, servicios, potencia... etc. Un ERP en modo SaaS es igual de
personalizable y configurable como otro cualquiera. Al no existir una gran inversión
inicial cualquier compañía grande o pequeña puede permitir un software ERP. Sobre
los costes a largo plazo es discutible, yo diría que aun así un alquiler saldría más
barato que la compra. Ya que aunque compres e implantes cualquier software ERP,
posteriormente hay que contratar el mantenimiento y soporte que suele ser mucho
dinero.
-Acceso sin límites. Con alquiler de un ERP el acceso se puede realizar desde
cualquier lugar del mundo, a cualquier hora y desde cualquier terminal, mientras exista
una conexión a Internet. Las soluciones tradicionales son mucho más limitadas.
Con todas estas ventajas el ERP en modo alquiler crecerá año tras año hasta
superar las soluciones clásicas de ERP. De momento son soluciones que están
enfocados a pequeñas y medianas empresas y que no se alejen mucho del estándar.
Para soluciones más complejas a día de hoy aun se requiere un ERP más
personalizable, pero es algo discutible. También es cierto que los grandes como
Oracle, Microsoft o SAP mediante adquisiciones estratégicas están migrando sus
soluciones a sistemas SaaS.
Inconvenientes.
En España curiosamente la red es de muy baja calidad, sobre todo gracias a la

poca inversión de las compañías telefónicas. Por ello las soluciones SaaS muchas
veces están fuera de lugar. Para una solución de este tipo una empresa debe contar
con un ancho de banda lo suficientemente grande para poder trabajar cómodamente
en la nube. Las PYMES en España aun no tienen acceso a Internet de calidad. En
otros países del área Europeo el panorama es diferente, como por ejemplo Irlanda que
invirtió mucho en infraestructuras de tecnología las últimas décadas y por ello las
grandes compañías como Google, Facebook, Amazon e incluso el propio Inditex estén
ahí. No es solo por los bajos impuestos, aunque desde luego también influye.
2.9 Costes de un ERP
El coste de un ERP suele ser uno de los factores más importantes en la

determinación de la decisión de muchas empresas, sobre todo cuando hablamos de
empresas de baja capitalización. Creemos que no debería darse tanta importancia a
este factor dada la coyuntura actual de facilidad de crédito y posibles subvenciones.
Aunque lo que debería ser realmente importante es que el sistema cubra
correctamente tanto las necesidades técnicas como las funcionales, es innegable que
el coste es y seguirá siendo un factor decisivo.
En este apartado se explican los costes principales de un ERP según su tipo

para luego ver un listado de costes ocultos relacionados con éstos.
33
2. ERP
2.9.1 Costes principales.
2.9.1.1 Infraestructura Técnica.
Los avances en infraestructura técnica están haciendo viables proyectos que

en el pasado representaban un coste demasiado elevado. El precio del hardware se
ha abaratado y las tecnologías que eran factibles antiguamente en grandes
corporaciones son hoy en día incluso aplicables a la pequeña empresa. Hay que ir con
cuidado en no caer en el error de realizar un mal dimensionamiento técnico pues
podría echar abajo el resto de trabajos asociados a la implantación del sistema ERP.
Costes asociados: hardware, red, comunicaciones, análisis de las necesidades,

reasignaciones y reutilizaciones, petición y seguimiento de ofertas con proveedores,
coste de comunicaciones coste de seguridad, contratos de mantenimiento.
2.9.1.2 Software.
Los costes del Software son marcados por los fabricantes estando íntimamente
ligados a los proveedores de servicios. Mucha gente del sector piensa que en el futuro
el coste de las licencias será nulo siendo los beneficios de las empresas distribuidoras
los servicios proporcionados.
Costes asociados: módulos propios del software, licencia, elección del

software, costes de actualización.
2.9.1.3 Servicios.
Un proyecto de implantación se realiza por un equipo de trabajo formado por

personal de la compañía distribuidora. En los costes de servicios se engloban costes
de consultoría, incorporados en la primera fase de estudio previo. Costes de
personalizaciones, incluyendo la reprogramación o adaptación del sistema a una forma
de trabajar concreta determinada por la empresa cliente. Los costes de implantación
son aquellos surgidos desde el momento en que se empieza a instalar el sistema
hasta el correcto funcionamiento de este. Posteriormente surgen los costes de
formación, enfocados a dar los conocimientos mínimos a los usuarios finales del
sistema para evitar una pérdida de productividad y posibles errores durante las
primeras semanas de contacto con el sistema. Una vez se ha hecho la formación, en
caso de haberla requerido, aparecen los costes de mantenimiento, costes que suelen
englobar tanto un soporte telefónico que incluyen un determinado número de horas de
un técnico en caso de requerirlo y actualizaciones del sistema en futuras versiones.
Estas actualizaciones pueden, en algunos casos, ser realizadas directamente por el
cliente aunque la empresa distribuidora suele recomendar hacer implantación de la
actualización, coste que no estará incluido en el mantenimiento. En caso de haber
realizado personalizaciones existen probabilidades de que las actualizaciones las
machaquen por lo que es recomendable que sea la empresa distribuidora la
encargada de realizar la tarea de seleccionar las partes a modificar.
Puesto que históricamente el precio de los servicios ha sido un coste

habitualmente variable al alza las empresas distribuidoras de ERP tienen en la
actualidad la tendencia a crear presupuestos cerrados para sus clientes para evitar
desconfianzas. Es necesario que en estos casos la empresa cliente se esfuerce en
determinar con mucho detalle todas las funcionalidades y particularidades que
34
2. ERP
necesitará pues cualquier cambio no reflejado en el documento del proyecto tendrá un

coste añadido.
Costes asociados: servicios de consultaría y organización, nuevos desarrollos,

implantación, formación y mantenimiento, etc.
Figura 2. 6 Distribución de costes ERP.
Figura 2. 7 Costes ERP por tipo de servicio.
2.9.2 Costes ocultos.
En muchos casos se acusa a las empresas distribuidoras de tener costes

ocultos que no se ven hasta el momento de realizar la implantación. Aunque esto varía
según el tipo de empresa, se concuerda que los costes usualmente olvidados o no
estimados son:
-Capacitación/Formación: Los trabajadores deben aprender todo un nuevo

conjunto de procesos y no sólo una simple nueva interfaz de software.
-Integración y prueba: Integración de la conexión entre el sistema ERP con

otras aplicaciones de software empresarial.
35
2. ERP
-Migración de datos de registros de clientes y empresas entre otros,

considerando que muchos datos suelen mostrarse como corruptos al efectuar su
transferencia.
- Análisis de los datos: Los datos del ERP, generalmente, tienen que estar
cruzados con datos externos. Actualizar los datos en una gran empresa es muy difícil,
es pues necesario efectuar un programa interno que haga la actualización diaria al fin
del día.
-Consultoría: Para evitar que la planificación falle, la solución en grandes

empresas es contratar una consultora que lidere el equipo en el proceso de
implantación del ERP.
-Sustitución: Mantener el personal especializado en la empresa cuesta mucho

dinero.
- Depresión post ERP: Algunas empresas, ya sea por no estar habituadas a las
nuevas funcionalidades del ERP, por no conseguir cambiar sus antiguos métodos de
trabajo, o por no tener la noción de los logros provenientes del ERP, acaban
abandonando el proyecto de implantación antes de ser finalizado.
Son éstos los costes que más hay que vigilar pues no suelen comentarse
inicialmente o se les suele dar la suficiente importancia. Aún siendo algunos costes
indirectos es importante ser consciente de todos ellos para evitar futuras sorpresas.
2.9.3 Aplicación: Niveles de costes.
Nivel 1. ERP enfocado a pequeña y mediana empresa, PYME. Desde 0 a 20.000

euros.
El coste podría ser 0 si se ve desde el punto de vista económico, aunque desde

luego esto sería muy difícil de conseguir.
 De 0 a 500 euros. Las soluciones software ERP que se pueden encontrar por
este precio que se podrían considerar gratuitas son aquellas donde se
reutilizan antiguos servidores y en general se intenta hacer todo por uno
mismo. Se realiza la adaptación, la formación y el volcado de datos. Es la
propia empresa la que realiza toda la tarea de implantación para ahorrar una
consultora informática. Para ello se necesitan ciertos conocimientos
informáticos y mucha paciencia. Posiblemente son proyectos viables para
empresas de nueva formación y que no tienen ningún software ERP.
 De 500 a 5000 euros. Existen soluciones bastante económicas de alquiler o
muy verticales que enfocados a ciertas empresas pueden tener un coste
bastante contenido. Las mismas soluciones ERP de software libre podrían
costar una cantidad parecida con implantación profesional y cierta formación.
Son soluciones perfectas para pequeñas y medianas empresas que quieren
gastarse algo de dinero.
 De 5000 a 20.000. En este tramo ya se puede acceder a muchas soluciones
profesionales con formación e implantación por parte de una consultora de un
software ERP de cierto renombre nacional. Por ejemplo el A3 ERP rondaría
ese precio. Aunque este último más cerca de los 20.000 que de los 5.000
euros.
36
2. ERP
Como se puede apreciar estos precios son bastante relativos y depende mucho del
sector de la empresa. Las tres opciones son perfectamente validas para algunas
pequeñas y medianas empresas que quiere acceder a un ERP. El precio no es un
buen criterio a la hora de elegir un ERP y incluso la opción de 0 euros puede ser
perfectamente válida. Cuanto más caro no significa mejor, se puede acabar con un
software complejo en el que no se utilicen ni la mitad de cosas.
Nivel 2. Soluciones ERP profesionales para PYMES. De 20.000 a 100.000 euros.
Este nivel, más profesional es el que permite acceder a las grandes soluciones
ERP de marcas SAGE, Navision, SAP Business One, Expertis... etc. Es aquí donde se
mueven la mayoría de las medianas empresas. El precio depende muchísimo de la
cantidad de licencias del software que se vayan a necesitar, de los módulos
requeridos, de las adaptaciones a realizar y de la formación. Por ejemplo si son 5
personas y se van a utilizar 2 módulos es muy probable que no se pase de los
30.000€. En cambio si son 20 personas y se va a utilizar de todo y además de ello hay
que realizar muchos cambios la cifra se acercara a los 100.000 €. Quizás por ello es
crítico simplificar al máximo el proceso de la empresa así como los usuarios que va a
tener acceso al sistema ERP para que el presupuesto del proveedor sea lo más
ajustado posible.
Aquí aunque habrá que estar involucrado al máximo todo el trabajo vendrá
hecho. Darán formación, soporte, realizaran todos los cambios especificados en el
presupuesto, implantarán el sistema, configurarán las máquinas cliente... etc. Esta
opción es perfecta para medianas empresas que saben perfectamente los beneficios
que ofrece un ERP y no quieren arriesgar.
Aún así hay que tener precaución, pues con este tipo de soluciones existe un
contrato de mantenimiento que suele ser una cantidad anual nada despreciable.
Normalmente el mantenimiento, futuros cambios, soporte, actualizaciones superan con
creces el coste inicial del proyecto durante la vida útil del mismo
Nivel 3. Soluciones para grandes empresas y multinacionales.
En este punto resulta complejo nombrar ninguna cantidad ya que no la hay. Tal
y como la mayoría de los datos apuntan el mejor es SAP, seguido de soluciones de
desarrollo propio. El precio dependerá del número de usuarios concurrentes que
acceden al sistema al mismo tiempo, de la infraestructura y otros factores. Pero desde
luego son soluciones que alcanzan importantes costes para cualquier empresa de
gran tamaño. Por algo la empresa SAP esta en el top 10 de los fabricantes de software
del mundo, detrás de Microsoft, IBM y Oracle.
2.10 Falsos mitos sobre ERP.
Existen ciertos mitos sobre el Software ERP, sobre los cuales sería importante
reflexionar, aunque se podría definir o unir junto a reglas imprescindibles que se
deberían de conocer a la hora de elegir o implantar un ERP. Estos criterios no son
absolutos, ni siempre son objetivos, pero se incluyen en este proyecto porque además
son muy interesantes.
- Cuanto más caro mejor. No tiene porque ni debe ser así. El precio no es el
principal criterio a la hora de elegir un ERP. Quizás sea mejor un ERP simple y
barato, pero que a su vez resuelva toda la problemática de la empresa y que sea lo
suficientemente escalable. Por el otro lado se puede tener un producto caro, complejo
37
2. ERP
y en el cual la mitad de las funciones no se vayan a utilizar. Es muy importante

entender que el precio no es un criterio clave y se encontrarán unas diferencias de
precio abismales entre un producto y otro.
- Los ERPs de las multinacionales son mejores. Es un mito complicado pero

probablemente sea cierto, aunque siempre con grandes excepciones. Un ejemplo
son las soluciones verticales enfocadas a cierto tipo de empresa. Ahora mismo el
mercado mundial está repartido entre 3 o 4 compañías. El SAP, soluciones de
Microsoft y Oracle. Entre grandes empresas el rey indiscutible es SAP que
aproximadamente tendrá un 90% de mercado. En las PYMES es más complicado,
pero a día de hoy posiblemente más del 80% ya está repartido entre estas marcas
-Los ERPs son solo para empresas grandes. Es totalmente falso. La

complejidad del negocio no depende del tamaño de la empresa. Para empresas
pequeñas y medianas hay soluciones muy económicas e incluso se podría encontrar
los gratuitos. Siempre y cuando haya personal cualificado para entender cómo
funcionan los ERPs Open Source y sepan adaptarlo y posteriormente formar al
personal. Es mejor tener un ERP limitado y sin soporte a no tenerlo. Además existe
software ERP en alquiler o SaaS. Es importante tener software ERP eficiente en
cualquier empresa, sea pequeña o mediana para saber en todo momento los costes y
beneficios para trazar un plan en base a estos datos.
- Los ERPs son complicados. La palabra idónea seria laborioso. Hay

soluciones ERPs complejas que requieren mucho tiempo de adaptación y formación.
Pero por regla general un Sistema ERP debe ser simple intuitivo, lo que no significa
que no tiene que haber un curso de formación.
-La implantación es un largo proceso. La implantación realmente es un proceso

muy corto. Lo que sí es un proceso largo es la adaptación del ERP, la formación del
personal, la toma de requisitos para una correcta implantación y en general todo el
proceso de recogida de datos y casos de uso de una empresa. La puesta en marcha
es cuestión de días. El elemento clave en cualquier proyecto ERP es la complejidad
del negocio de la empresa seguido de la calidad o experiencia del proveedor del
software. Como curiosidad en las universidades enseñan normalmente una curva de la
bañera de cualquier proyecto Software, una explicación perfectamente adaptable a
software ERP. Al principio habrá muchos fallos hasta que se llegue a una zona de
tranquilidad, para dentro de unos años volver a empezar de nuevo.
- El software ERP es caro. No es cierto. El software ERP correctamente

escogido para la empresa ahorra dinero. Una de sus funciones o beneficios es
convertir una empresa en un proceso de negocio estandarizado y eficiente y tener en
todo momento una visión general de recursos. En pocas palabras ahorra tiempo y
dinero. Además hay soluciones gratuitas o en alquiler, perfectas para entender para
que sirve el software de estas características.
38
3. VIRTUALIZACIÓN DE
SISTEMAS.
3. VIRTUALIZACIÓN DE SISTEMAS
3. Virtualización de sistemas.
3.1 Definición y tipos de máquinas virtuales
Una máquina virtual es un programa informático que crea un entorno virtual

entre el sistema operativo y el hardware para que el usuario final pueda ejecutar
aplicaciones en una máquina abstracta. Por decirlo de manera más sencilla, una
máquina virtual es una aplicación que simula el funcionamiento de una máquina real
sobre la que se pueden instalar sistemas operativos, aplicaciones, navegar de forma
segura, imprimir desde alguna aplicación, usar los dispositivos USB, etc.
Las máquinas virtuales se pueden clasificar en tres grandes categorías según su

funcionalidad y su grado de equivalencia a una verdadera máquina.
 Máquinas virtuales software: este tipo de máquinas virtuales se sitúan por

encima del sistema operativo y tratan de aislar a las aplicaciones del entorno
sobre el que se ejecutan. Proporcionan una capa entre las aplicaciones y el
sistema operativo que captura todas las llamadas al sistema y las traduce al
sistema concreto de ejecución. La máquina virtual de Java o la máquina virtual
del entorno .NET son dos claros ejemplos de máquinas virtuales software.
 Entornos virtuales: este tipo de máquinas se crean para ejecutar

directamente aplicaciones que necesitan un entorno determinado de ejecución
sobre otro entorno totalmente diferente.
 Máquinas virtuales de sistema, también llamadas máquinas virtuales de

hardware, permiten a la máquina física subyacente multiplicarse entre varias
máquinas virtuales, cada una ejecutando su propio sistema operativo. A la
capa de software que permite la virtualización se la llama monitor de máquina
virtual o hypervisor. Un monitor de máquina virtual puede ejecutarse o bien
directamente sobre el hardware o bien sobre un sistema operativo ("host
operating system"). Este tipo de aplicaciones tratan de emular directamente el
hardware. Las llamadas al hardware del sistema operativo instalado serán
capturadas y convertidas en llamadas al sistema del hardware emulado. En
general, la emulación del hardware recibe el nombre de virtualización. Al
emularse directamente el hardware, el usuario tiene la impresión de que la
máquina sobre la que está trabajando es totalmente independiente.
Uno de los inconvenientes de las máquinas virtuales es que agregan gran

complejidad al sistema en tiempo de ejecución. Esto tiene como efecto la ralentización
del sistema, es decir, el programa no alcanzará la misma velocidad de ejecución que si
se instalase directamente en el sistema operativo "anfitrión" (host) o directamente
sobre la plataforma de hardware. Sin embargo, a menudo la flexibilidad que ofrecen
compensa esta pérdida de eficiencia.
3.2 Creación de una máquina virtual.
En este apartado se detalla cómo crear una máquina virtual. Al final del mismo
el resultado será un ordenador con sistema operativo de base (Anfitrión) Windows con
un sistema huésped Ubuntu, de tal forma que al tener encendida la máquina virtual
podrá operarse con ambos al mismo tiempo y de manera independiente. Y todo ello
41
con la ventaja de que ambas pueden estar comunicadas entre sí para la compartición
de archivos o el reenvío de puertos.
Oracle VM VirtualBox es un software de virtualización para arquitecturas

x86/amd64, creado originalmente por la empresa alemana innotek GmbH.
Actualmente es desarrollado por Oracle Corporation como parte de su familia de
productos de virtualización. Por medio de esta aplicación es posible instalar sistemas
operativos adicionales, conocidos como «sistemas invitados», dentro de otro sistema
operativo «anfitrión», cada uno con su propio ambiente virtual.
El primer paso para crearla por tanto es acudir a la página web

www.virtualbox.org para descargarse el software, se pincha el apartado “downloads” y
en pantalla aparecerá el enlace para la descarga, tal y como se indica en la figura.
Figura 3. 1 Descarga de VirtualBox.
En cuanto a la versión no hay que preocuparse, ya que se está actualizando

constantemente.
Una vez instalado Virtualbox el paso siguiente es crear la máquina virtual e

instalarle el sistema operativo. Para ello hay que descargárselo antes. Este ejemplo se
va a hacer con el sistema operativo Ubuntu 12.04.LTS y puede descargarse de forma
gratuita desde la página www.ubuntu.com .
Lo primero que hay que hacer es seleccionar el nombre y el sistema operativo.
42
Figura 3. 2 Elección de sistema operativo.
Hay que tener cuidado seleccionar la versión correcta. Por ejemplo, si se desea
instalar la versión 12.04 LTS para 64 bits habrá que seleccionar que la máquina virtual
tiene esas características, porque si no cuando se quiere instalar el nuevo sistema
operativo, este aporta el siguiente error por considerar que el propio equipo no las
cumple:
This kernel requires an x86-64 CPU, but only detects an i686 CPU, unable to boot
A continuación hay que seleccionar la memoria RAM a asignar. Hay que tener
en cuenta que la memoria que se va a utilizar para la máquina virtual es parte de la
memoria de la máquina real y si se elige demasiada el rendimiento tanto de la
máquina real como la virtual se verán ralentizados. VirtualBox recomienda en este
caso utilizar 512 MB pero esa cantidad puede aumentarse si las características del
equipo lo permiten o si así se desea. De todas formas, una vez creada la máquina este
valor puede cambiarse.
A continuación se decide si crear una máquina nueva o utilizar una ya

existente.
Figura 3. 3 Elección de crear o utilizar archivo existente.
43
En este caso se decide crear un disco duro virtual ahora .Por tanto lo siguiente
es seleccionar si el nuevo archivo de unidad de disco duro virtual debería crecer según
se use (reserva dinámica) o si debería ser creado con su tamaño máximo (tamaño
fijo).
Un archivo de unidad de disco duro reservado dinámicamente solo usará

espacio en el disco físico a medida que se llena (hasta el máximo tamaño fijo), aunque
no se reducirá de nuevo automáticamente cuando el espacio en él se libere.
Un archivo de unidad de disco duro de tamaño fijo lleva crearlo entorno a 10

minutos puede pero normalmente es más rápido al usarlo.
Figura 3. 4 Proceso de creación de la máquina virt ual.
Una vez creada la máquina virtual lo que se tiene al iniciarla es equivalente a

un ordenador formateado al que habrá que instalar el sistema operativo. En este caso
se selecciona el archivo descargado y siguen las instrucciones.
Figura 3. 5 Instalación de Ubunt u.
44
Durante la instalación se irá configurando con diversos apartados, idioma,

contraseña, etc. Además también es recomendable instalar las “guest aditions” desde
el apartado dispositivos de la máquina virtual.
El resultado final sería el siguiente:
Figura 3. 6 Resultado final.
Como puede apreciarse en la imagen, no hay mayor inconveniente en tener

varias máquinas creadas a la vez. Dónde sí puede surgir un problema es si están
encendidas a la vez, ya que cada una funcionará como un ordenador independiente
con el consiguiente reparto de recursos.
Una de las virtudes más importantes de la virtualización también es que el

archivo de la máquina virtual no tiene por qué estar en el propio equipo, puede estar
en un dispositivo externo como un pen drive o un disco duro portátil. La única
diferencia en la creación es que hay que crearla desde un archivo existente. Si no
estaba creada antes, cuando se selecciona donde guardarla se hace en la ubicación
deseada.
Al tener el archivo en un dispositivo portátil, este puede abrirse desde cualquier

ordenador que pueda abrir una máquina virtual, facilitando por tanto la portabilidad del
sistema junto con los programas en él instalados y toda la información.
3.3 Utilización en el proyecto.
En este proyecto la virtualización ha supuesto un factor importante que ha

reportado numerosos conocimientos desde el punto de vista didáctico y práctico.
Gracias a esta herramienta, por ejemplo se ha podido tener instalado

OpenERP tanto en Windows como en Ubuntu y sobre todo aprender a hacerlo. Como
se verá en el apartado 4 de este mismo proyecto la instalación en Windows es directa,
pero en Ubuntu requiere de una serie de pasos detallada en el ANEXO I.Cuando se
está ante un sistema operativo desconocido es muy fácil equivocarse y cometer
errores. Con la virtualización uno puede tener una copia de su máquina, y en caso de
45
cometer el típico error de principiante trabajar con la seguridad de que conserva todo
lo anterior.
La versión elegida para este proyecto de OpenERP es la 7, sin embargo esta

es relativamente reciente, de 2012 por lo que en muchas plataformas y muchos
tutoriales están creados para la anterior, la 6.1. Por tanto y para tener una visión más
global del funcionamiento del programa lo que se ha hecho es instalarla en una
máquina virtual, ya que no se pueden tener ambas a la vez en el mismo sistema
operativo, puesto que hay conflicto con la base de datos PostgreSQL.
En la imagen siguiente se ofrece una captura de pantalla en la cual hay un

sistema anfitrión Windows 7 y tres máquinas virtuales abiertas al mismo tiempo, dos
de ellas con Windows XP y otra de Ubuntu 12.04 LTS. Tanto en la de Ubuntu, como
en la XP que está de fondo se tiene la versión 7 de OpenERP y en la otra la 6.1 del
mismo.
Figura 3. 7 Tres máquinas virt uales con dos SO distintos y con distintas versiones de
OpenERP.
Desde un punto de vista práctico y sin pretender entrar en detalles que se

verán en apartados posteriores, puede entenderse perfectamente la cantidad de
utilidades que ofrece la virtualización a la hora de implantar un sistema de gestión tan
complejo como este.
Permite durante la fase de análisis y desarrollo, mientras se están diseñando

las bases de datos y los módulos, poder utilizar el programa desde los ordenadores
del cliente, pero sin tener realmente el programa instalado aún. Además y
especialmente gracias a la facilidad de la portabilidad se puede seguir trabajando aún
sin estar en la propia oficina en que se está implantando, sin tener que recurrir a
46
duplicidades de información. .
Por los mismos motivos también facilita la formación en la utilización del

programa, ya que crear bases de datos innecesarias o instalar módulos inapropiados
no supone ningún tipo de problema. En caso de no poder disponer de este sistema lo
que habría que hacer es recurrir a salas piloto en las cuales se tiene uno o varios
equipos disponibles solo para esta función, con el consiguiente perjuicio económico y
de recursos.
También sirve, para que cuando se han creado módulos personalizados poder
comprobar si funciona en ambas versiones. En este proyecto se ha trabajado desde
un principio con la versión 7 con lo que ello no ha representado un problema. Pero a
modo general, una empresa que ya tuviese instalado en programa en su versión 6.1
puede comprobar si funciona en la nueva versión o si hay que adaptarlo, porque
siempre puede haber ciertos conflictos con las vistas o los campos relacionales,
facilitando por tanto la migración de una versión a otra.
En las siguientes imágenes se ve un ejemplo del mismo módulo, de creación

propia para este proyecto, en ambas versiones del programa.
Figura 3. 8 Módulo “lista de correos” OpenERP versión 6.1.
Figura 3. 9 Módulo “lista de correos” OpenERP versión 7.
47
48
4. ESTUDIO DE
OPENERP.
4. ESTUDIO DE OPENERP
4. ESTUDIO DE OPENERP.
4.1 Introducción
Habitualmente, cuando se hace un proyecto fin de carrera de este tipo, lo que

se hace es evaluar las distintas opciones de ERP de distintas marcas que ofrecen las
consultorías y ver cuál es la más adecuada para adaptar a la empresa. Esto aporta
una visión muy interesante ya que permite tener un conocimiento global de las
distintas opciones que se aportan en el mercado, además de los que aporta el estudio
detallado de la estructura y de todos los procesos de la compañía.
Sin embargo lo que se ha hecho en este caso es hacer un estudio del un ERP
en concreto, que permita no solo tener un conocimiento detallado del funcionamiento
como cliente del mismo, si no que permita a nivel desarrollador asumir las mayores
funciones posibles.
Como se ha descrito en apartados anteriores, la implantación de un ERP de

software libre solo es gratuita si te tiene al personal con los conocimientos adecuados
para poder hacerlo, lo cual no es habitual puesto que quien dispone de ellos, en la
mayoría de los casos, trabajará para una consultoría que se dedique a este fin.
Aunque resulte paradójico, cuando uno busca en internet información técnica,

resulta más complicado obtener la básica que la más compleja, puesto que la primera
se supone que se adquiere o en las facultades o bien en cursos de formación. Por
supuesto hay excepciones, con el inconveniente de que suele estar dispersa y en
muchas ocasiones solamente disponible en inglés.
En los siguientes apartados y anexos se aporta la información básica sobre la

mayoría de los aspectos de OpenERP, incluyendo una descripción detallada de los
módulos, el funcionamiento como cliente y como desarrollar módulos propios,
empezando con una descripción general del programa y finalizando con la aplicación
en una asociación en el apartado 6 de este proyecto.
4.2 Descripción de OpenERP.
OpenERP es un completo sistema de gestión empresarial (ERP) de código

abierto que cubre las necesidades de las áreas de contabilidad, finanzas, ventas,
RRHH, compras, proyectos y almacén entre otras.
Los módulos base de OpenERP pueden gestionar una empresa de manera

estándar en todos sus departamentos y además, con la parametrización adecuada,
puede llegar a personalizar todos los flujos de trabajo. Además, en estos momentos
existen más de 2000 módulos específicos, desarrollados tanto por OpenERP S.A
como por la comunidad que cubren distintas áreas de actividad y pueden completar a
los módulos oficiales.
OpenERP añade en la mayor parte de sus áreas herramientas de análisis y

generación de informes, con lo que la gestión y visualización de la información se
simplifica. Además del módulo de informes por defecto, puede utilizar Webkit Report,
para la creación de informes multiplataforma, con Html y Css3. También existen
51
motores de informes basados en Open/LibreOffice (Aeroo), Pentaho y Jasper

Reports. Las posibilidades de esta combinación son casi ilimitadas.
Las modificaciones y adaptaciones de código a las necesidades de las

empresas se pueden realizar en forma ágil. Por ejemplo: flujos de trabajo (workflows)
editables, informes personalizados, control de productos y vistas. Permite un
desarrollo rápido de nuevos módulos y herencia de los ya existentes.
Es un sistema de código abierto, que cumple las 4 libertades del software libre,
basado en estándares abiertos y desarrollado con plataformas libres. Además, posee
una importante comunidad de desarrolladores que están constantemente ampliando y
mejorando el proyecto (amplia documentación, foros, cvs, listas de correo, desarrollo
comunitario y traducciones en Launchpad, etc.).
Se ofrece bajo licencia AGPL, por lo que no se abonan licencias de

adquisición, sólo se paga por los costes de integración y adaptación a las necesidades
de su empresa.
OpenERP permite la gestión dinámica de los distintos procesos de negocio de

manera gráfica e intuitiva, gracias a su potente sistema de generación de flujos de
trabajo. El sistema brinda la posibilidad de editar y modificar flujos de trabajo
directamente desde la pantalla.
La arquitectura del sistema OpenERP es cliente – servidor, lo que permite que

todos los usuarios trabajen sobre el mismo repositorio de datos. Esto tiene la ventaja
de que toda la información está disponible y sincronizada en todo momento además
de que descarga la mayor parte del trabajo de procesamiento de datos de las
máquinas cliente (donde trabajan efectivamente los usuarios). El intercambio de datos
entre el servidor y el cliente puede realizarse mediente XML-RPC, Net-RPC y/o
JSON.
Figura 4. 1 Arquitectura OpenERP.
Dentro de la construcción misma del software se hace un uso intensivo de

flujos de trabajo (modelo workflow) que se pueden integrar con sus distintos módulos.
52
El programa es Software Libre liberado bajo licencia GPL, lo que le confiere varias
ventajas:
 Coste cero de licencias.
 Gran variedad de documentación extensiva en la red.
 Flexibilidad en la implementación.
 Fácil personalización de la aplicación e integración con módulos propios.
 Amplia posibilidad de desarrollos futuros.
 Corrección rápida y eficiente de bugs.
 Código limpio, lo que implica gran estabilidad del sistema.
 Actualizaciones frecuentes disponibles de manera gratuita, continuidad

segura del proyecto.
 Integración nativa con otras plataformas y librerías de software libre.
 Traducción y localización a más de 120 países e idiomas.
Es un software multiplataforma: funciona sobre Linux y Windows, y la interfaz de

usuario está construida sobre Web. El cliente web permite utilizar OpenERP desde
cualquier navegador, ya sea en un ordenador de sobremesa, portátil o tablet, y desde
cualquier lugar del mundo. Sólo se necesita una conexión a Internet. Además,
dispone de una vista web simplificada, pero con todas las funcionalidades de la vista
completa, adaptada a pantallas de smartphones. Las limitaciones físicas o de
hardware no serán un impedimento nunca más para utilizar su ERP.
Emplea Postgresql como sistema de gestión de bases de datos y su lenguaje de

programación principal es Python.
A continuación se describen algunas de las características que tanto

www.openerp.com como las consultoras consideran fundamentales a la hora de elegir
OpenERP:
- Libertad: OpenERP como producto no “pertenece” a ninguno de sus

distribuidores, tiene libertad para elegir si necesita de alguna consultora para su
implantación o lo puede realizar uno mismo con unos conocimientos mínimos.
- Filosofía Open: puede contratar únicamente lo que necesite. Lo habitual es

necesitar ayuda en el proceso de implantación, pero muchas empresas ya disponen
de software parecido por lo que os posible que solo necesite instalación de algún
módulo o simplemente soporte técnico.
- Código abierto: al ser software libre, se puede disponer del código para realizar
cualquier mejora sobre los módulos ya existentes, o crear uno nuevo adaptado a sus
necesidades.
53
- Conectividad con otros productos: Visualización de informes en Adobe PDF,

importación/exportación con Microsoft Office, u Open Office, Google Maps, Mozilla
Thunderbird, osCommerce, Magento, Joomla, y otros muchos, con la posibilidad de
conexión con casi cualquier tecnología.
- Flexibilidad: Permite personalizar el interfaz del usuario, y gestionar sus procesos

de negocio.
- Gratuito: aunque resulte difícil de creer, OpenERP es un producto que no tiene

coste de licencias. No hay que pagar por usarlo en más puestos de trabajo o renovar
las costosas licencias anualmente. Ese dinero puede aprovecharSE para otras
mejoras informáticas o en otros departamentos.
- Multiplataforma: El sistema puede ser utilizado en ordenadores con distintos

sistemas operativos tales como GNU/Linux, Mac OS X, Microsoft Windows. Dispone
además de un interfaz web para poder ser usado en distintos dispositivos como tablet,
pda, smartphone, ipad, y todo aquel que sea capaz de utilizar un navegador.
- OpenObject: dispone de un API abierto para desarrollo rápido de aplicaciones

administrativas.
- Variedad: OpenERP es un sistema en crecimiento que cuenta actualmente con

más de 1000 módulos liberados que se pueden combinar para construir casi cualquier
tipo de aplicación administrativa.
- PostgreSQL, el motor de base de datos de OpenERP es un potente desarrollo

libre dirigido por una comunidad de desarrolladores y organizaciones comerciales que
cuenta con clientes como Skype, Sony Online, Departamento de Trabajo de U.S.A,
IMDb , etc.
- Fácil migración: la herramienta oficial importa y exporta datos en formato .csv

para que resulte más sencillo seguir trabajando con los datos de los sistemas actuales.
4.3 Instalación.
Este sistema de planificación empresarial es distribuido a nivel mundial por la

empresa OpenERP a través de su web www.openerp.com, aunque poseen filiales en
todo el mundo, la española se corresponde con OpenERP Spain c on su web
www.openerpspain.com .
Figura 4. 2 Logo de OpenE RP Spain.
Lo más recomendable y para descargarse la versión más actual es acudir a la

primera aunque está en inglés. En el momento de empezar este proyecto la última
versión que ofrecía esta página era la versión 7, mientras que en la era española la
6.1. aunque actualmente sí está disponible. Si en el problema que uno piensa a la hora
54
de instalarlo desde la primera es en el idioma, eso no es un problema, OpenERP está

traducido a muchos idiomas y constantemente las traducciones se van mejorando, de
hecho para hacerse una idea está traducido también al gallego a pesar de que la
calidad de la traducción deja un poco que desear.
La versión de OpenERP que se ha instalado y estudiado para este proyecto ha

sido la 7 aunque como se ha mencionado en el punto de máquinas virtuales también
se han hecho pruebas con la 6.1. ya principios de este año ha salido la 8 aunque
todavía está en desarrollo por parte de los partners.
Puede instalarse tanto en Windows, como en Ubuntu como en Mac. La

instalación en Ubuntu requiere además de unos conocimientos básicos de este
sistema operativo, de una serie de pasos y scripts. En este proyecto se ha empleado
Windows como sistema de referencia por lo que a continuación se detalla en una serie
de breves pasos de cómo hacer aquí la instalación. Para ver como se hace en Ubuntu
se adjunta el ANEXO I tal y como se ha mencionado ya en el apartado de
virtualización.
Para descargarlo en Windows se acude a la página www.openerp.com en su

pestaña “Download” y en el apartado de Windows. Lo primero que pedirá serán los
datos de registro, puede hacerse sin ningún tipo de problema y de forma gratuita. Por
lo que sí que se establece un precio es si se desea soporte e instalarlo en la nube,
sería instalarlo como servicio (SaaS) pero en este caso se hará sobre un servidor
propio, es decir el propio ordenador.
Se descarga el archivo (79 MB aprox) y se instala como la mayoría de los

programas, pulsando “ejecutar” y “siguiente” cuando sea el caso.
Figura 4. 3 Instalación OpenERP.
El formato de instalación es “All in one” con lo cual de manera automática ya

contiene todos los componentes, incluyendo la base de datos PostgreSQL. Es en este
punto donde puede haber conflicto con una versión anterior, en caso de que aún siga
instalada, con lo que es conveniente tener la precaución de que previamente todo esta
correcto.
55
Figura 4. 4 Instalación de la bas e de datos.
Se pulsa siguiente y ya queda todo instalado. Para acceder al programa habrá

que hacerlo a través del puerto correspondiente del ordenador y esto se hace
escribiendo en el navegador (Explorer, Chrome, Firefox) lo siguiente:
localhost:8069
Y ya se puede acceder. Si se tienen varios ordenadores en red lo que habrá

que hacer es introducir en el navegador la IP del ordenador en que esté instalado
(debe estar encendido) seguido de dos puntos y el nombre del puerto al que se
accede 8069, tal que así:
192.168.0.4:8069
En cualquiera de los casos lo primero que se abre es una pantalla como la

siguiente para crear la primera base de datos, en ella se definirá el nombre de la base
de datos y la contraseña de un primer usuario que será el administrador (admin),
además de la traducción que se quiera cargar.
Figura 4. 5 Creación de la primera base de datos.
Una vez creada aparecerá la siguiente pantalla para introducir el nombre y la

clave para acceder y proceder a la instalación de los módulos correspondientes.
56
Figura 4. 6 Acceso OpenERP.
4.4 Descripción de módulos de OpenERP.
Tal y como se han definido en los tipos de ERP, OpenERP es un software de

tipo modular. Para conocer los módulos se ha buscado en la bibliografía tanto en las
páginas oficiales como en todo tipo de blogs. Las descripciones que hacen son más
desde el punto de vista comercial que del de mostrar directa y detalladamente los
módulos del programa.
Por tanto lo que se ha hecho ha sido instalar todos los módulos básicos y
elaborar una guía descriptiva con todos ellos que se incluye como ANEXO II. La
metodología simple, aunque laboriosa, consistió en acceder objeto a objeto de la
herramienta realizando capturas de pantalla para comprobar su funcionamiento,
creando datos ficticios en los casos necesarios.
Los módulos descargables de OpenERP no aparecen como tal, sino que se

establecen repartidos en aplicaciones las cuales van completando un mismo módulo o
varios de ellos. El objetivo es no instalar más de lo necesario para poder simplificar al
máximo la organización de la información.
A continuación se establecen las definiciones básicas para poder entender la

guía y el propio sistema de gestión empresarial.
Objeto: Son los que forman la estructura principal de OpenERP. Modelos en

los cuales se establecen los campos con sus diferentes tipos. Una entidad propia que
como conjunto forma parte de un módulo o una aplicación. Mediante un campo
relación dentro de la pantalla en que se ve un objeto podrá haber otros objetos.
Sucede esto, por ejemplo con los one2many.
Campo: Los objetos en OpenERP contienen campos los cuales permiten

introducir datos en la base . Hay dos tipos de campos, los básicos y los relacionales,
los básicos solos sirven para introducir datos básicos y los relacionales permiten
establecer relaciones entre los objetos. Los campos estarán definidos por un nombre
“real” y por uno “descriptivo” que será el que realmente se visualice. Esta distinción es
importante ya que a la hora de importar/exportar los datos será el nombre “real” el que
aparezca.
57
Menú: Es un conjunto de objetos, servirá como división para visualizarlos

mejor.
Vista: Las vistas describen como es mostrado cada objeto, como y donde es
dibujado cada uno. Hay 6 tipos de vista distintos en esta versión: Kanban, Lista,
Formulario, Calendario, Gantt y Gráfico. No es necesario que un objeto las tenga
todas, pero al menos si la vista Lista o árbol, que será de la que se puedan importar
los datos y la vista Formulario que será en la que se cubran manualmente los datos.
Módulo: Es el conjunto de objetos, campos, menús, vistas y aplicaciones si es

el caso. En esta guía se describen precisamente estos, al menos en su configuración
más básica y sin perjuicio de la instalación de más componentes que los completen.
4.5 Funcionamiento de OpenERP.
En este apartado se explicará el funcionamiento de OpenERP desde el punto

de vista del usuario, de un modo general, no específico en cada módulo que es en lo
que se centra la guía descriptiva.
4.5.1 Crear bases de datos.
En un principio al instalar el programa ya está una creada. Si se desea crear

otra desde la pantalla inicial se pulsa “gestionar bases de datos”.
Figura 4. 7 Acceder a crear base de datos.
Siguiendo las instrucciones de pantalla se crea una nueva base de datos con el
nuevo nombre y la traducción que corresponda, en este caso español. Desde este
apartado también se podrán borrar o duplicar bases de datos. Se hace exactamente
igual que para crear la primera.
Lo normal será tener un diseño previo del número de bases de datos

necesarios para la compañía, con los módulos que correspondan a cada una.
58
4.5.2 Instalación de módulos.
Como se ha explicado antes los módulos se instalan mediante aplicaciones.

Para instalar uno completo se acude a la guía y se instalan las que correspondan a
ese en concreto.
Figura 4. 8 Instalación de aplicaciones.
Por ejemplo para instalar al completo el módulo de recursos humanos será

necesario instalar las aplicaciones Employee directory, Recruitment Process,
Timesheets, Leave Management, Expense Management y Employee apraxails. Al
instalar estas aplicaciones queda definido también el módulo Encuestas.
4.5.3 Creación de usuarios y cambio de contraseña.
Se crearan usuarios del OpenERP desde el apartado de

“Configuración/Usuarios”. No se debe confundir a los usuarios con los empleados,
pueden ser los mismos, pero no todos los empleados tienen por qué ser usuarios.
Para cambiar la contraseña una vez creado el usuario aparece la ventana

“más” y desde ahí se puede cambiar las contraseñas además, de por ejemplo, asignar
tareas.
Figura 4. 9 Creación de usuario.
59
4.5.4 Configuración de permisos.
Aunque para utilizar OpenERP de manera habitual no es recomendable, para

configurarlo es imprescindible tener activadas las “características técnicas” del usuario.
Se activan desde la pantalla anterior pero en la pestaña “Permisos de acceso”. Desde
esta misma también se configurarán los permisos a los módulos básicos de OpenERP,
aunque no a los módulos propios que se hayan creado.
Figura 4. 10 Permisos y características técnicas.
Para configurar los permisos de los módulos propios, o para configurar de una
forma más exacta los permisos de un usuario habrá que hacerlo desde el objeto
grupos, que es el que aparece, una vez han sido activadas las características técnicas,
encima de usuarios. (Nota: Aunque pueda parecer una obviedad, hay que tener
cuidado de que el usuario en que se han activado las características técnicas sea con
el que se está trabajando, en caso contrario habría que cerrar sesión e iniciarla con
dicho usuario).
Pero para llegar a este paso previamente habrá que conocer el nombre del
objeto a asignar permisos. No el nombre que se ve, el cual puede ser una traducción o
no coincidir exactamente, si no el nombre con el que está programado Eso puede
hacerse de dos formas, viéndolo en el archivo programado, algo que no es muy
recomendable sin los conocimientos suficientes o activando el modo desarrollador.
Esto se hace en la pestaña que se abre a la derecha, en la misma de cerrar sesión
pulsando “Acerca de OpenERP” y en la ventana. A efectos prácticos de uso normal
solo se activará este modo para realizar esta tarea y para las modificaciones en modo
gráfico.
60
Figura 4. 11 Activación del modo desarrollador.
Con este modo activado se podrán hacer múltiples tareas, pero la más
importante será conocer el nombre de los objetos. En la vista formulario, bastará con
ponerse encima de un campo y ahí se especifica el nombre del campo y del objeto.
Por ejemplo para conocer el nombre del objeto Empleados se pone el cursor encim a
de cualquiera de los campos y se ve en el recuadro. Tal y como puede apreciarse en
la imagen el nombre del objeto “empleados” es “hr.employee”.
Figura 4. 12 Nombre de los objetos en modo desarrollador.
Ahora que se sabe ver el nombre se acude al objeto anteriormente mencionado

Grupos. Habrá que crear un grupo y dentro de este una aplicación y a partir de ahí
moviéndose por las pestañas se seleccionan los permisos de acceso. También es
posible hacerlo desde un grupo que ya esté creado, como por ejemplo el “compartir”.
61
Figura 4. 13 Crear un grupo.
En “permisos de acceso” será donde haya que poner el nombre del objeto, en
este caso para poner un ejemplo se ha elegido el del modulo propio “curso.ficha”
aunque al introducirlo ya pone automáticamente “Ficha”. En principio habrá que ir
objeto a objeto, no podrá seleccionarse un módulo completo. Esto presenta como
inconveniente lo laborioso que resulta, pero por otra parte la ventaja de poder
configurar los permisos de “leer”, ”escribir”, ”crear” y “eliminar” según convenga.
Figura 4. 14 Asignación de permisos.
Además no será necesario crear un grupo por cada módulo, pueden insertarse
objetos de cualquier parte y así hacerlo todo de una vez.
Como recomendación se evitará el uso de acentos en el nombre de los

objetos, en la programación ya no los tiene y para evitar un posible error mejor
evitarlos.
Este es el resultado, en vez de verse el módulo completo solo se ve el objeto

compartido.
62
Figura 4. 15 Resultado de la aplicación de permisos.
4.5.5 Exportar-Importar datos.
En primer lugar habrá que asegurarse de que en “configuración/configuraciones

generales” está activada la casilla de importar-exportar. Esto solo podrá hacerlo el
administrador.
Fig 4.14 Configuraciones generales.
4.5.5.1. Exportar.
Solo se podrán exportar datos de la vista “lista” o de las vista “gráficos”. Se

seleccionarán las entradas a exportar y se pulsará la tecla “más” y dentro de ella
“exportar”. En formato podrá exportarse como CSV, archivo separado por comas o en
Excel. Preferentemente se utlizará Excel. Se agregan los campos a importar y se
pulsa “exportar a fichero” y será mejor abrirlo que guardarlo.
63
Figura 4. 16 Exportar campos.
El resultado es el que se ve en la imagen a continuación. El campo ID que es

propio de la estructura de OpenERP.
Figura 4. 17 Datos exportados.
4.5.5.2. Importar datos.
Aunque lo habitual será introducir a través de la vista formulario los datos a

mano, también puede darse el caso, especialmente al iniciar la base de datos, de
querer introducirlos directamente con el Excel. Habrá que conocer primeramente el
nombre de los campos, el nombre con el cual han sido programados. Ello puede
hacerse como se ha visto anter iormente activando el modo desarrollador o lo más
práctico que es exportar el último valor y partiendo de ese archivo copiar los datos en
esa estructura, tal y como se ve en la imagen anterior. También podrán hacerse
plantillas para no tener que buscarlos cada vez.
64
Figura 4. 18 Documento a importar.
El archivo habrá que guardarlo como “CSV (delimitado por comas)” y será el
que se importe.
Figura 4. 19 Guardar archivo delimitado por comas.
Cuando se importe habrá que tener cuidado con las opciones de importación
porque si no puede dar lugar a errores. Se utilizarán las que aparecen en la imagen
donde habrá que seleccionar en codificación “Windows 1252” y en separador “punto y
coma”.
65
Figura 4. 20 Importación de documento.
Finalmente este es el resultado:
Figura 4. 21 Resultado de documento importado.
4.6 Personalización de OpenERP.
Hay dos formas de personalizar OpenERP, programando o en modo gráfico.

Ambas tienen sus ventajas, sus inconvenientes y su practicidad. Las modificaciones
en modo gráfico solo sirven para la base de datos en que se está trabajando, mientras
que las programadas se extienden a todas las bases de datos, puesto que implica un
cambio en la estructura del programa. Cuando se habla de modo gráfico, se entiende
que es directamente desde OpenERP a través de los menús de configuración.
Es por tanto fundamental saber que se quiere modificar y para qué antes de
hacer cualquier cambio. A priori el modo gráfico puede parecer el más sencillo, pero
solo para pequeños cambios, cuando se trata de cosas importantes no solo llevará
más tiempo si no que quedará peor, por tanto compensa programar.
Para crear un módulo personalizado hay que programar, desde un punto de

vista didáctico puede hacerse en modo gráfico para aprender y familiarizarse con los
conceptos ya que el entorno es más amigable, aún así para hacerlo muy simple
66
porque cuando se busca agrupar campos por ejemplo se complica. Para hacer
modificaciones que vayan a utilizarse siempre también será mejor hacerlo
programando, esto puede hacerse directamente sobre los módulos de OpenERP o
creando propios que los agreguen, lo cual será más recomendable.
El modo gráfico puede compensar para pequeñas modificaciones, como por

ejemplo para hacer asignar a un objeto varios menús, de tal manera que en dos
módulos distintos aparezca el mismo objeto, una simple cuestión de practicidad. En
este proyecto solo se ha utilizado para eso, como se verá más adelante para incluir el
objeto “Empleados” dentro del menú de “Organización” en el módulo personalizado
“congreso”.
4.7 Modo gráfico.
Ahora se explicará con una breve serie de pasos como crear objetos dentro del
menú de un módulo existente, análogamente también el cómo hacer para que formen
un módulo propio en el paso 4.
El objetivo es insertar el objeto “rutas” dentro del módulo flota con un menú
propio.
1. Se parte de tener activadas las características técnicas en el usuario y

activado el modo desarrollador. En el apartado 4.5.4 de este mismo proyecto se
detalla cómo llevar a cabo esa operación.
Inicialmente el módulo flotas contiene los siguientes elementos:
Figura 4. 22 Constitución del módulo Flota.
2. Lo que hay que tener claro desde el principio es la estructura que se va a

crear, a continuación se indica la lista de los menús y campos a introducir para ir paso
a paso. Los elementos se escriben con “x_nombre del campo” aunque para
visualizarlos se le ponga el que se quiera.
67
Flota
x_menurutas
x_rutas
campo x_codigo
campo x_nombre
campo x_salida
campo x_llegada
campo x_distancia
campo x_paradas
campo x_indicencias
3. Al haber activado las características técnicas surge en el menú de

configuración el menú Técnico, se entra en estructura de la base de datos y se pulsa
crear. Hay que tener muy claro que todo lo que se cree a partir de ahora va de menor
rango a mayor rango, para no cometer errores.
Figura 4. 23 Detalle del menú de configuración.
Un detalle que hay que tener claro es que el nombre del modelo no tiene nada
que ver con el nombre de los menús que surjan a partir de él. Ahora se pulsa en crear
menú.
68
Figura 4. 24 Creación de menús. Modo gráfico.
4. Ese nombre que se le ha puesto es el del rango más bajo, el nombre con el
que se verá al objeto. Ahora se pulsa el menú padre y crear para crear el menú que
aparece en violeta, que en este caso será “Menú Rutas” y a su vez a este habrá que
asignarte otro menú padre que será el nombre de uno de los módulos existentes o si
se quisiese crear un módulo sería en este punto donde se crearía, del mismo modo.
En este caso se le asignará a al existente “Flota”.
Figura 4. 25 Asignación de menú a módulo.
5. Se pulsa guardar y crear menú y se vuelve al apartado 3. Desde aquí mismo

pueden crearse los campos asignados al objeto a crear. En los campos se definirán
69
las propiedades que tengan, tipo de campo, si es obligatorio, tamaño, con cual se
relacionan, si pertenecen a un grupo etc.
Figura 4. 26 Creación de campos personalizados.
Figura 4. 27 Resultado de la creación de los campos.
70
6. Se pulsa guardar se actualiza el navegador, se pulsa crear y este es el

resultado:
Figura 4. 28 Resultado de la creación del objeto.
7. Para añadir más elementos debajo del menú rutas se crea un nuevo objeto,
por ejemplo, Mis camiones con un menú camiones y ya no se crearían los menús
padre, se asignaría directamente el menú rutas. Esto puede hacerse desde objetos ya
creados, para tener el mismo objeto en dos módulos distintos.
Figura 4. 29 Asignación de menú a objeto.
Figura 4. 30 Creación del objeto “Camiones”.
71
Por tanto:
Figura 4. 31 Resultado de añadir el objeto.
8. Para hacer modificaciones en los modelos. Configuración/Técnico/Estructura

de la base de datos/ Modelo y en el buscador se pone el nombre del objeto que se
quiera modificar.
Figura 4. 32 Búsqueda de modelo.
Se pulsa editar.
9. Se pueden agregar campos de distintos tipos. Por ejemplo en el modelo mis

camiones puedo agregar un campo con la fecha en que se compró.
Figura 4. 33 Agregar campo fecha.
72
Figura 4. 34 Resultado de agregar el campo fecha.
10. Para crear las vistas y que aparezcan todos los campos del formulario en
la vista lista hay que ir a Configuración/interfaz de usuario/vistas/crear.
Figura 4. 35 Crear vista.
Donde pone field name= “name” hay que sustituirlo por los campos que se
quiere que aparezcan.
73
Figura 4. 36 Modificar vista.
De este modo ahora en el apartado creado aparecerán todos los campos:
Figura 4. 37 Resultado de modificar la vista.
4.8 Programación.
4.8.1 Introducción.
En los apartados siguientes se explicará como programar un módulo

personalizado desde un punto de vista absolutamente práctico, sin entrar en exceso
en definiciones de programación ya que sobre estas hay múltiples ejemplos en la
bibliografía. Además se tendrán en cuenta solo aquellos conceptos utilizados para este
proyecto, con lo cual, no quiere decir que no haya más, pero sencillamente no se han
empleado.
Se ha elaborado un módulo ejemplo que sirva como modelo para una

aplicación práctica.
OpenERP es un programa Cliente/Servidor basado en Python .Consta de un

cliente OpenERP-Client y un servidor OpenERP-Server mientras que la
74
persistencia de datos está proporcionada por la base de datos relacional

PostgreSQL.
Fig 4.33 Estructura de OpenERP
OpenERP utiliza el protocolo XML-RPC o NET-RPC para la comunicación entre

cliente y servidor. También dispone de un cliente web para generar la interfaz gráfica
del usuario como una página web y así poder usar OpenERP desde un navegador
web.
Una vez instalado, OpenERP tiene una estructura modular permitiendo añadir
módulos según vaya siendo necesario.
OpenERP funciona sobre un entorno de desarrollo o framework llamado

OpenObject.Este framework permite el desarrollo rápido de aplicaciones (RAD - Rapid
Application development).
OpenObject es un entorno de desarrollo rápido de aplicaciones de gestión orien

tado a objetos en Python usando base de datos PostgreSQL. Sus componentes son:
●ORM (Object Relational Mapping): Mapeo de bases de datos relacionales a objet

os Python.
● Arquitectura MVC (Modelo Vista Controlador).
● Sistema de flujos de trabajo o workflows.
● Diseñador de informes o reports (OpenOffice, JasperReports, ...).
● Herramientas BI (Business Intelligence) y OLAP cube engine.
● Clientes Gtk, Koo (KDE) y Web.
OpenERP utiliza el patrón de arquitectura de software Modelo Vista Controlador.
75
Se trata de un patrón de arquitectura de software que separa los datos y la lógica

de negocio de una aplicación de la interfaz de usuario y el módulo encargado de
gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de
tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un
lado define componentes para la representación de la información, y por otro lado para
la interacción del usuario. Este patrón de diseño se basa en las ideas de reutilización
de código y la separación de conceptos, características que buscan facilitar la tarea de
desarrollo de aplicaciones y su posterior mantenimiento.
De manera genérica, los componentes de MVC se podrían definir como sigue:
 El Modelo: Es la representación de la información con la cual el sistema opera,

por lo tanto gestiona todos los accesos a dicha información, tanto consultas
como actualizaciones, implementando también los privilegios de acceso que se
hayan descrito en las especificaciones de la aplicación (lógica de negocio).
Envía a la 'vista' aquella parte de la información que en cada momento se le
solicita para que sea mostrada (típicamente a un usuario). Las peticiones de
acceso o manipulación de información llegan al 'modelo' a través del
‘controlador’.
 El Controlador: Responde a eventos (usualmente acciones del usuario) e

invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la
información (por ejemplo, editar un documento o un registro en una base de
datos). También puede enviar comandos a su 'vista' asociada si se solicita un
cambio en la forma en que se presenta de 'modelo' (por ejemplo,
desplazamiento o scroll por un documento o por los diferentes registros de una
base de datos), por tanto se podría decir que el 'controlador' hace de
intermediario entre la 'vista' y el 'modelo' (véase Middleware).
 La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato

adecuado para interactuar (usualmente la interfaz de usuario) por tanto
requiere de dicho 'modelo' la información que debe representar como salida.
Fig 4.34 Modelo- Vista- Controlador
76
4.8.2 Licencia.
La mayoría de los módulos de OpenERP son lanzados bajo la licencia AGPL y

algunas partes utilizan una derivada de la Mozilla Public License. Como consecuencia
directa, OpenERP no requiere ninguna tasa para ser utilizado, a diferencia de los
líderes del mercado. Eso también implica que, mientras que se respeten los términos
de la licencia, la modificación directa del programa es posible.
La licencia pública general de Affero (en inglés, Affero General Public License,
también Affero GPL o AGPL) es una licencia copyleft derivada de la Licencia Pública
General de GNU diseñada específicamente para asegurar la cooperación con la
comunidad en el caso de software que corra en servidores de red. La Affero GPL es
íntegramente una GNU GPL con una cláusula nueva que añade la obligación de
distribuir el software si éste se ejecuta para ofrecer servicios a través de una red de
ordenadores.
Usar la GPL de GNU exige que todas las versiones mejoradas que se
publiquen sean software libre. Esto significa que el programador no correrá el riesgo
de tener que competir con una versión modificada privativa de su propio trabajo.
Un aspecto crucial del software libre es que los usuarios tienen la libertad de
cooperar. Es absolutamente esencial que a los usuarios que deseen ayudarse entre sí
se les permita compartir sus correcciones de errores y mejoras con otros usuarios.
Algunos han propuesto licencias alternativas a la GPL que requerirían que las
versiones modificadas fueran supervisadas por el autor original. Mientras el autor
original permaneciera atento a las necesidades de mantenimiento, esto podría
funcionar bien en la práctica; pero si el autor deja de hacerlo (en mayor o menor
medida) para dedicarse a otras tareas o no atiende a las necesidades de todos los
usuarios, el procedimiento fracasa. Dejando a un lado los problemas prácticos, este
planteamiento no permite a los usuarios ayudarse entre s í.
En ocasiones, el control de las versiones modificadas se propone como un

medio para evitar la confusión entre las diferentes versiones hechas por los usuarios,
aunque en la práctica, esta confusión no supone mayor problema. Se han hecho
muchas versiones de Emacs independientes del proyecto GNU, pero los usuarios son
capaces de distinguirlas. La GPL exige al autor de una versión que ponga su nombre
en ella, con el objeto de distinguirla de otras versiones y para proteger la reputación de
otros responsables del mantenimiento del programa.
La GPL no obliga a publicar el programa modificado, ni ninguna parte del

mismo. El programador es libre de hacer versiones modificadas y usarlas en privado,
sin tener nunca que hacerlas públicas. Esto es aplicable también a organizaciones
(empresas incluidas); una organización puede hacer una versión modificada y usarla
internamente sin hacerla pública fuera de la organización.
Pero si publica de alguna manera la versión modificada, la GPL le exige que

ponga a disposición de los usuarios el código fuente modificado, bajo la GPL. Así
pues, la GPL le autoriza a publicar el programa modificado de determinadas maneras
y no de otras; pero la decisión de publicarlo o no depende del que programa.
77
Como se verá en el módulo ejemplo la licencia de OpenERP tiene forma de

“comentario” y va “pegada” en los archivos python tal que así:
################################################################# #############
# OpenERP, Open Source Management Solution
# Copyright (C) 2004-2010 Tiny SPRL (<http://tiny.be>).
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Affero General Public License as
# published by the Free Software Foundation, either version 3 of the
# License, or (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the imp lied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Affero General Public License for more details.
# You should have received a copy of the GNU Affero General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
##############################################################################
4.8. 3 Sistema de archivos básicos.
Para crear un módulo, lo primero que hay que hacer es crear una carpeta con
su nombre, que será pegada en el directorio “addons” de la instalación de OpenERP,
en una instalación habitual estaría aquí:
C:\Archivos de programa\OpenERP 7.0-20131001- 231052\Server\server\openerp\addons
Cada carpeta que contiene un módulo contiene, como mínimo, cuatro archivos:
__init__.py
__openerp__.py
modulo_ejemplo.py
modulo_ejemplo.xml
78
Como se puede observar por las extensiones habrá que crear tres archivos
python y uno XML. Para hacerlo, en este proyecto se ha utilizado el editor de texto
“Notepad++” que permite abrir los archivos en formato texto sin cambiarles la
extensión, además de proporcionar herramientas que facilitan la programación. A
efectos prácticos, lo que habrá que hacer será adaptar el código a las necesidades
que se quieran cubrir.
4.8.3.1 Archivo __init__.py
El archivo __init__.py sirve para importar los otros archivos .py que tenga el
módulo, en otras palabras sirve para cargarlo. A continuación se adjunta la sintaxis
pero sin la licencia que iría en medio de las dos líneas:
# -*- coding: utf-8 -*-
import modulo_ejemplo
4.8.3.2 Archivo __openerp__.py

El archivo __openerp__.py contiene un diccionario que describe todos los
archivos que se utilizan en la implementación de un modulo. Donde:
name : Nombre del módulo.
version: Versión del modulo.
description: Una descripción del modulo.
autor: Persona o entidad que desarrollo el modulo.
website: Sitio web de la entidad que desarrollo el modulo.
license: Tipo de licencia del módulo.
depends: Lista de módulos de los cuales depende el modulo, el módulo base

es el más usado puesto que en él se definen los datos necesarios para implementar
las vistas, reportes…etc.
update_xml: Lista de los archivos XML que se cargaran con la instalación del
modulo.
instalable: Determina si un modulo es instalable o no (True o False).
79
Por tanto la programación del módulo ejemplo:
# -*- coding: utf-8 -*-
"name" : "Módulo ejemplo",
"version" : "0.1",
"author" : "Fernando Vazquez Novoa",
"website" : "http://ambiental.uvigo.es",
"category" : "Unknown",
"description": """Módulo ejemplo de programación de módulos """,
'data': [],
'depends' : ['base'],
'update_xml': ["modulo_ejemplo.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'installable': True,
'active': False,
4.8. 3.3 Archivo modulo_ejemplo.py.

El archivo modulo_ejemplo.py será el que contenga los objetos que
componen un modulo en la vista y en la base de datos, estos objetos tienen atributos
predeterminados los cuales son usados e interpretados por Open ERP.
4.8.3.3.1 Atributos predeterminados.
Aunque hay más, estos son los más básicos y los que se han empleado para
este proyecto:
_name: Este atributo es requerido y pone nombre al objeto creado.El nombre

estará compuesto por el nombre del módulo (en el cual “_” representa el espacio) tras
un punto y el del objeto.
_description: Es el nombre con el que realmente se ve el objeto.
_rec_name: Nombre del campo que se usa para recursos de búsqueda. A

efectos prácticos, cuando se utiliza un campo many2one que establece una relación
80
muchos a uno, es decir cuando se va a ver un campo de un objeto que contiene

varios, es el campo que se muestra.
_columns: Este atributo es requerido, en el se definen los campos que se

crean en la tabla de la base de datos y las vistas
4.8.3.3.2 Campos básicos y relacionales.
Los objetos en Open ERP contienen campos los cuales permiten introducir
datos en la base de datos, estos campos van definidos en el atributo columns. Hay dos
tipos de campos, los básicos y los relacionales, los básicos solos sirven para introducir
datos básicos y los relacionales (ver tipos de relación) permiten establecer relaciones
entre los objetos.
4.8.3.3.2.1 Campos básicos.
Boolean: El tipo de dato lógico o booleano es aquel que puede representar

valores de lógica binaria, esto es 2 valores, valores que normalmente representan
falso o verdadero. Por decirlo en otras palabras es en el que se hace una “marca”.
Sintaxis:
fields.boolean('Field Name' [, Optional Parameters]),
integer: Un tipo de dato entero en computación es un tipo de dato que puede

representar un subconjunto finito de los números enteros. El número mayor que puede
representar depende del tamaño del espacio usado por el dato y la posibilidad (o no)
de representar números negativos. Los tipos de dato entero disponibles y su tamaño
dependen del lenguaje de programación usado así como la arquitectura en cuestión.
Sintaxis:
fields.integer('Field Name' [, Optional Parameters]),
float: El tipo de dato real es un tipo de dato en programas informáticos que

representa la aproximación de un número real.
Al igual que los números enteros, el tipo real está limitado superior e
inferiormente según la cantidad de memoria que haya disponible para almacenarlo.
Otro elemento importante a tener en cuenta en este tipo de datos es la precisión con
que pueden representar número con decimales (cuantos decimales se pueden
representar), esta característica también está directamente relacionada con la cantidad
de memoria disponible para almacenar un valor real.
Sintaxis:
fields.float('Field Name' [, Optional Parameters]),
81
Char: Una cadena de longitud limitada. Es el campo más común y al menos en

este proyecto el más utilizado, no supone restricciones en cuanto a la utilización de los
caracteres, solo en cuanto a la longitud de su cadenaEl parámetro tamaño requerido
determina su tamaño.
Sintaxis:
fields.char('Field Name',size=n [,Optional Parameters]), #

donde ''n'' es un integer, el número de caracteres.
text: Un campo de texto sin límite de longitud.
Sintaxis:
fields.text('Field Name' [, Optional Parameters]),
date: Permite seleccionar en un calendario una fecha.
Sintaxis:
fields.date('Field Name' [, Optional Parameters]),
datetime: Permite almacenar la fecha y la hora del día en el mismo campo.
Sintaxis:
fields.datetime('Field Name' [, Optional Parameters]),
binary: A efectos prácticos será aquel desde el cual puedan insertarse una
imagen o un archivo de todo tipo.
Sintaxis:
fields.binary('Field Name' [, Optional Parameters]),
Cuando se trate de una imagen además habrá que poner en la vista formulario:
widget='image'
Cuando se trate de un archivo, en la vista lista o árbol:
widget='url'
selection: Un campo que permite al usuario hacer una selección entre varios
valores predefinidos.
Sintaxis:
fields.selection((('n','Unconfirmed'),
('c','Confirmed')),'Field Name' [, Optional Parameters]),
82
4.8.3.3.2.2 Campos relacionales.
many2one: Asocia este objeto a un objeto primario a través de este campo.

Por ejemplo si en un campo se quiere introducir el nombre de un cliente y ya hay una
lista de clientes, se selecciona de esa lista. Poniendo el atributo _rec_name en el
objeto se selecciona que campo se quiere que se vea.
Sintaxis:
fields.many2one( 'other.object.name', 'Field Name',optional

parameters)
one2many: Es el campo con la sintaxis más compleja de este proyecto. Es el

que expresa una relación uno a muchos entre dos objetos. Además del propio campo
será necesario que haya un campo many2one en el otro objeto con el que tenga
relación, aunque no se vaya a utilizar, de hecho puede incluso “borrarse” en la vista de
tal manera que ni siquiera aparezca. En resumen lo que permite este campo es crear
listas dentro de un objeto.
Sintaxis:
fields.one2many('other.object.name', 'Nombre campo relación', 'Nombre de
este campo', optional parameters)
fields.many2one( 'other.object.name', 'Nombre de este campo ',optional

parameters)
El “Nombre campo relación” debe ser igual que el “Nombre de este

campo”.
4.8.3.3.3 Ejemplo.
A continuación la programación de los objetos, se establece el objeto principal,

el objeto al que esta asociado el campo many2one y un tercer objeto al que está
asociado el campo one2many. Una vez esté instalado el módulo, este último no estará
en el menú de objetos, formará parte del “objeto”.
# -*- coding: utf-8 -*-
from osv import osv, fields
class modulo_ejemplo_objeto(osv.osv):
_name = 'modulo_ejemplo.objeto'
_description = 'Objeto'
_columns = {
'image': fields.binary("Imagen", help="Seleccionar imagen aqui"),
83
'cadena': fields.char('Campo char', size=200, required=True),
'boleano': fields.boolean('Campo boleano', required=False),
'numerico': fields.integer('Campo integer/número entero',

required=False),
'float': fields.float('Campo float, número con decimales',

required=False),
'fecha': fields.date('Fecha', required=False),
'fechayhora': fields.datetime('Fecha y hora', required=False),
'seleccion': fields.selection((('uno','UNO'),('dos','DOS')),'Campo
selección', required=False),
'relacion_id':
fields.many2one('modulo_ejemplo.objetorelacion','Campo relación'),
'archivo': fields.binary("Archivo o documento", help="Permite

insertar un archivo"),
'relacionlista_ids':
fields.one2many('modulo_ejemplo.objetorelacionlista','name_id','Ejempl
o de one2many',help="Se obliga a crear many2one"),
'textouno': fields.text('Campo texto uno', required=False),
'textodos': fields.text('campo de texto dos', required=False),
'texto3': fields.text('Campo de texto 3', required=False),
'cadenados': fields.char('Campo char', size=200, required=False),
'texto4': fields.text('Campo de texto 4', required=False),
modulo_ejemplo_objeto()
class modulo_ejemplo_objetorelacion(osv.osv):
_name = 'modulo_ejemplo.objetorelacion'
_description = 'Objeto relacion'
_rac_name='name'
_columns = {
'name': fields.char('Campo que se va a ver ',size=200,

required=True),
84
'otro': fields.char('Otro campo',size=200, required=False),
'otrocampomas': fields.text('Otro campo distinto',

required=False),
modulo_ejemplo_objetorelacion()
class modulo_ejemplo_objetorelacionlista(osv.osv):
_name = 'modulo_ejemplo.objetorelacionlista'
_description = 'Objeto one2many'
_columns = {
'name_id': fields.many2one('modulo_ejemplo.objeto','Many2one
obligado',help="obligado por one2many, no necesario aparezca en
vista"),
'campouno': fields.char('Campo 1',size=200, required=False),
'campodos': fields.char('Campo 2',size=200, required=False),
'campotres': fields.char('Campo 3',size=200, required=False),
'campocuatro': fields.char('Campo 4',size=200, required=False),
'otrocampomas': fields.text('Otro campo distinto',

required=False),
modulo_ejemplo_objetorelacionlista()
85
4.8.3.4 Archivo modulo_ejemplo.xml.
El cuarto archivo, tal y como indica su extensión es en formato XML, por tanto se
trata de un lenguaje de programación distinto. El archivo puede abrirse desde
cualquier explorador de internet (Explorer, Chrome, Firefox…) y su función dentro de
OpenERP es la de estructurar las vistas. Tendrá tres componentes principales, los
menús, las vistas y las acciones.
Los menús se colocan en dos sitios, al principio del archivo el que corresponde el
nombre del módulo y a los menús y al final de cada acción de cada objeto,
incluyéndose en este último el orden en que se quiere que aparezcan. El tag que
creado crea la entrada en el menú y el vinculo de la acción es <menuitem />.
En cuanto a las vistas, como se ha visto anteriormente en esta versión se dispone

de hasta 6 distintas, aunque en la práctica solo el módulo “Proyect” en su objeto
“Tareas” contará con todas ellas a la vez.Tres son las más comunes y son las que se
han programado en este proyecto.
- La vista Kanban es la utilizada para facilitar la identificación, consta de una

imagen, un campo principal y dos secundarios, debajo de la imagen.
- La vista árbol (tree) refleja los objetos como una lista, es desde la cual se
pueden importar y exportar los archivos en Excel o CSV.
- La vista formulario (form) es aquella en la que se introducen manualmente los
datos.
El tag con el atributo model=”ir.ui.view”, que contiene la definición de la vista es

<record>
Las acciones se sitúan justo después de las vistas de cada objeto y en ellas se
determinará entre otras cosas el nombre que aparecerá en el menú. También en ellas
se establecerá el orden que tienen las vistas, no teniendo que coincidir por tanto con el
orden en que están programadas. El tag correspondiente es <record>.
El archivo modulo_ejemplo.xml será el único que no contenga la licencia y estará

delimitado por la siguiente estructura:
<?xml version="1.0" encoding="UTF-8"?>
<openerp>
<data>
</data>
</openerp>
86
4.8.3.4.1 Elementos de diseño.
Los elementos de diseño, no confundir con los atributos de los campos se

utilizan para mejorar las vistas, poniendo en orden los campos, agrupándolos etc. Se
utilizan en la vista formulario que es en la cual se escriben los datos. A continuación se
describirán los elementos de diseño empleados para este proyecto.
<group>… </group> Permite agrupar los elementos en columnas. Con el

atributo string se le puede poner un nombre, que apar ecerá en violeta encima. En
ocasiones se utiliza el atributo “colsplan” para el número de filas y el “col” para el de
columnas.
<separator string="etiqueta" colspan="4"/> Agrega una línea de

separación en el formato. El atributo string define la etiqueta del separador y el atributo
“colspan” define su tamaño.
<newline/> Sirve para forzar un cambio de línea.
<label string="Etiqueta"/> Es una casilla con texto que no se puede

modificar.
Placeholder. Se escribe después del nombre de un campo. Es el texto que

aparece dentro del campo para una pequeña descripción y que cuando se escribe en
el campo desaparece automáticamente. Su sintaxis:
<field name="descripción" placeholder= "Para hacer una

descripción..."/>
Libreta: Permite distribuir los campos de la vista en diferentes pestañas, las

libretas pueden tener una o varias páginas. Se utilizará el atributo “colspan” para que
estén todas en la misma fila y no aparezcan en varias, esto se hace poniendle el
número de páginas. La sintaxis es la siguiente:
<notebook colspan="4">
<page string="Página 1">
</page>
</notebook>
4.8.3.4.2 Menús.
Como se ha escrito se escriben al principio y después de las acciones. Para

respetar el orden, en la parte de las mismas se incluirá el menú correspondiente. La
explicación a que en el primero esté como secuencia 90 es que es el nombre del
módulo y se supone que nunca se crearán tantos objetos.
87
<openerp>
<data>
<menuitem name="Módulo ejemplo" id="moduloejemplo" sequence="90"/>
<menuitem name="Menú propio" id="moduloejemplo_menupropio"

parent="moduloejemplo"/>
4.8.3.4.3 Vista Kanban.
Como se puede ver a continuación “cadena” es el nombre del campo principal, que
en la vista aparecerá en violeta y “relación_id” junto con “boleano” los dos secundarios.
<record model="ir.ui.view" id="custom_objeto_kanban_view">

<field name="name">modulo_ejemplo.objeto.kanban</field>
<field name="model">modulo_ejemplo.objeto</field>
<field name="type">kanban</field>
<field name="arch" type="xml">
<kanban>

<field name="cadena" />
<field name="image" />
<templates>
<t t-name="kanban-box">
<div class="oe_product_vignette">
<a type="open">
<img class="oe_kanban_image"
t-att-src="kanban_image('modulo_ejemplo.objeto',
'image', record.id.value)" />
</a>
<div class="oe_product_desc">
<h4>
<a type="edit">
<field name="cadena"></field>
</a>
</h4>
<ul>
<li><field name="relacion_id"></field> </li>
<li><field name="boleano"></field> </li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
4.8.3.4.4 Vista lista o árbol.
Representa los campos en forma de lista. Tanto en esta vista como en la formulario
no es obligatorio que estén todos los campos, de hecho el campo imagen ni siquiera
puede verse en este tipo de vista, y el campo texto si es muy extenso no queda bien.
Sin embargo, el nombre de los campos que se ponga debe existir en el archivo que
define las propiedades de los objetos, es uno de los errores más comunes. Será la
88
vista desde la cual se puedan hacer búsquedas y se pueda importar y exportar los
datos. Ejemplo:
<record model="ir.ui.view" id="modulo_ejemplo_objeto_tree">

<field name="name">modulo_ejemplo.objeto.tree</field>
<field name="type">tree</field>
<tree string="objeto">
<field name="cadena"/>
<field name="boleano"/>
<field name="numerico"/>
<field name="float"/>
<field name="fecha"/>
<field name="fechayhora"/>
<field name="seleccion"/>
<field name="relacion_id"/>
<field name="archivo" widget='url'/>
</tree>
</field>
</record>
4.8.3.4.5 Vista formulario.
Es aquella en la cual se introducen los datos de forma manual, es en la que se

emplean los elementos de diseño. Ejemplo:
<record model="ir.ui.view" id="modulo_ejemplo.objeto_form">

<field name="name">modulo_ejemplo.objeto.form</field>
<field name="type">form</field>
<form string="objeto">
<group string="Nombre de grupo">
<field name="image" widget='image' />
<field name="cadena"/>
<field name="boleano"/>
<field name="numerico"/>
<field name="float"/>
</group>
<group>
<field name="fechayhora"/>
<field name="seleccion"/>
<field name="relacion_id"/>
<field name="archivo"/>
<label string="Elemento de la vista para tener un texto"/>
</group>
<newline/>
<group colspan="2" col="1">
<field name="relacionlista_ids"/>
</group>
<newline/>
<separator string="Libreta" colspan="4"/>
<field name="textouno" placeholder= "Para hacer una descripción..."/>
</group>
</page>
<page string="Página dos">
<field name="textodos" placeholder= "o poner lo que quiera..."/>
89
</group>
</page>
<field name="cadenados" placeholder="aqui tambien se puede..."/>
<field name="texto3" placeholder="distintos tipos de campos"/>
</group>
</page>
<field name="texto4"/>
</group>
</page>
</notebook>
</form>
</field>
</record>
4.8.3.4.6 Acción y resto de objetos.
La acción es la que determina si los objetos aparecen o no aparecen, si un

elemento tiene vistas y no tiene acción no aparecerá en el menú. En el ejemplo que se
está poniendo, como el objeto “modulo_ejemplo.objetorelacionlista” va con una
relación “one2many” al principal, ya no se ha definido la acción, por tanto el elemento
no se aprecia por separado.
En el menú que va justo después se define el menú padre. El objeto principal

tiene como “parent” el menú, por tanto irá jerárquicamente bajo el. Con los demás
objetos lo habitual es que suceda lo mismo, a uno u otro menú, pero también se puede
poner como “parent” al objeto principal que es lo que se ha hecho en este ejemplo.
A continuación se describe la acción para el primer objeto y el resto de los

componentes del archivo, que incluye a los otros dos objetos.
<record id="modulo_ejemplo_objetorelacion_action" model="ir.actions.act_window">

<field name="name">Objeto relacion</field>
<field name="res_model">modulo_ejemplo.objetorelacion</field>
<field name="view_type">form</field>
<field name="view_mode">tree,form</field>
</record>
<menuitem action="modulo_ejemplo_objetorelacion_action"
id="modulo_ejemplo_objetorelacion_menu" sequence="2"
parent="modulo_ejemplo_objeto_menu"/>
<record model="ir.ui.view" id="modulo_ejemplo_objetorelacionlista_tree">

<field name="name">modulo_ejemplo.objetorelacionlista.tree</field>
<field name="model">modulo_ejemplo.objetorelacionlista</field>
<tree string="objetorelacionlista">
<field name="campouno"/>
<field name="campodos"/>
<field name="campotres"/>
<field name="campocuatro"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="modulo_ejemplo_objetorelacionlista_form">
90
<field name="name">modulo_ejemplo.objetorelacionlista.form</field>
<field name="model">modulo_ejemplo.objetorelacionlista</field>
<form string="objetorelacionlista">
<field name="campouno"/>
<field name="campodos"/>
<field name="campotres"/>
<field name="campocuatro"/>
<newline/>
<field name="otrocampomas" placeholder= "newline..."/>
</group>
</form>
</field>
</record>
</data>
</openerp>
4.8.4 Instalación de módulo propio.
Para la instalación del módulo propio habrá que pegar la carpeta que contiene
los módulos dentro del directorio “addons” habitualmente en una ruta como está:
C:\Archivos de programa\OpenERP 7.0-20131001- 231052\Server\server\openerp\addons
El paso siguiente es reiniciar el servidor y eso se hace buscando en el menú de

inicio “Servicios” abriéndose una ventana como la que se muestra a continuación en la
que habrá que buscar “OpenERP” y pulsar “reiniciar”.
Figura 4. 38 Reiniciar el servidor.
Es entonces el momento de ir a OpenERP a la base de datos que se quiera

instalar. Habrá que tener activadas las “características técnicas” y actualizar la lista de
módulos.
91
Figura 4. 39 Actualizar lista de módulos.
Dentro del menú “módulos instalados” se busca por el nombre del módulo, en
este caso “ejemplo”.
Figura 4. 40 Instalación del módulo personalizado.
Se pulsa instalar y ya queda instalado el módulo ejemplo y ya queda instalado.
Figura 4. 41 Módulo instalado.
Figura 4. 42 Vista formulario.
92
Figura 4. 43 Vista lista.
Figura 4. 44 Vista Kanban.
Si se vuelve a ir a “módulos instalados” y se pulsa sobre el módulo se ve las

propiedades de este, que están definidas en los archivos que se han creado.
Figura 4. 45 Propiedades del módulo creado.
93
94
5. ACLUXEGA.
5. ASOCIACIÓN CLÚSTER DA XEOTERMIA GALEGA (ACLUXEGA)
5. ASOCIACIÓN CLÚSTER DA XEOTERMIA GALEGA (ACLUXEGA).
5.1 Geotermia.
La energía geotérmica es la energía almacenada en forma de calor por debajo

de la superficie sólida de la Tierra. Se renueva como consecuencia del flujo de calor
geotérmico, que asciende desde el interior del planeta y de la radiación solar que
calienta la superficie del suelo.
Por recursos geotérmicos se comprende a la energía térmica que puede ser

razonablemente extraída del terreno a costes competitivos con otras formas de
energía y ser aprovechado por el hombre de forma técnica y económicamente viable.
El objetivo de la geotermia es el aprovechamiento de esa energía calorífica del

interior de la tierra, y se clasifica en función de la temperatura del fluido geotermal que
determina sus usos y aplicaciones.
Las tecnologías de aprovechamiento de los recursos geotérmicos dependen

del nivel térmico disponible y del tipo de fluido existente en el yacimiento.
Cuando la temperatura de yacimiento es inferior a 100-150ºC, sus principales

aplicaciones son térmicas, en los sectores industrial, servicios y residencial pudiendo
hacerse un aprovechamiento directo o a través de bombas de calor geotérmicas.
La estructura del uso directo de la energía geotérmica, a nivel mundial, se

distribuye en dos ámbitos claramente diferenciados: sector servicios residencial, con
un 64% del total, y sector industrial que cubre el 36% restante. El uso directo del calor
de origen geotérmico en el mundo es difícil de determinar, pues existen muchos y muy
diversos usos éstos son a veces pequeños y están localizados en áreas remotas.
además, aunque el uso se pueda estimar, los valores de flujo y las temperaturas del
agua generalmente no se conocen y tampoco existe información sobre ello; por estas
razones, la capacidad y el uso directo de la energía calórica únicamente pueden ser
evaluados con una cierta aproximación.
A diferencia de los yacimientos asociados a usos directos, los recursos de baja

entalpia o geotermia somera, con una temperatura del fluido inferior a los 30ºC y
vinculados a aprovechamientos para bombas de calor geotérmicas (BCG), no es
viable el transporte de la energía geotérmica a gran distancia, relegando sus
aplicaciones principalmente a uso residencial al demandar niveles térmicos
relativamente bajos.
En realidad, en el caso de la energía geotérmica de muy baja temperatura, no

hace falta hablar de un “yacimiento de energía geotérmica” ya que cualquier punto de
la corteza terrestre puede ser empleado como fuente de energía al estar su
temperatura normalmente por debajo de los 25ºC a las profundidades objetivo para
este tipo de aprovechamientos.
El sistema geotérmico de calefacción/refrigeración, o energía geotérmica de

muy baja temperatura, aprovecha la estabilidad térmica de la tierra a profundidades
que van desde 2 m hasta 150 m, generalmente. Se diferencia de la energía
geotérmica convencional de agua caliente, extraída a profundidades que pueden llegar
hasta los 5 km, en el hecho de que trabaja a temperaturas del terreno entre 0 y 20°C,
según la latitud de los países ( del orden de 15°C para España).
97
La climatización se realiza aprovechando la diferencia de temperatura entre el

subsuelo y el ambiente, a través de un colector instalado bajo tierra, que aprovecha en
invierno la temperatura más alta del suelo para calefacción y en verano, la temperatura
más baja del subsuelo para refrigeración.
La clave de la eficiencia de este sistema reside en el aprovechamiento de la

energía acumulada en el subsuelo de manera constante y estable de forma que la
energía eléctrica consumida por el sistema de bomba de calor resulta inferior que en
un sistema convencional condensado o evaporado frente a otra fuente o sumidero de
calor (por ejemplo, el aire exterior).
5.2 La asociación.
La Asociación Clúster da Xeotermia Galega (ACLUXEGA) nace en el año 2010 con

el objetivo de aglutinar a todas las empresas gallegas dedicadas al mercado de la
geotermia, dentro de una zona geográfica y con unos retos comunes, para potenciar el
conocimiento y utilización de esta fuente de energía renovable en Galicia y España.
La Asociación, que en la actualidad cuenta con más de cuarenta socios, entre ellos
un Centro Tecnológico, la Escuela de Ingeniería de Minas de Vigo y seis Socios
Institucionales; se orienta al desarrollo de una estrategia conjunta de sus miembros,
centrada en la calidad, la formación y la concienciación sobre la geotermia y aspira a
convertirse en una referencia en el mercado geotérmico gallego y nacional.
La puesta en valor de las posibilidades de desarrollo de esta tecnología en Galicia,

aplicando los protocolos de calidad de ACLUXEGA, permite crear un marco de
referencia nacional para la promoción de la geotermia en España, ya que Galicia
forma parte de un espacio geológico de gran adaptación a la tecnología geotérmica.
Ante las diversas técnicas y sistemas de trabajo existentes, ACLUXEGA busca la

homogenización de las distintas fases del proceso de los servicios geotérmicos. El
clúster trata de consolidar una base profesional capacitada así como un tejido
industrial competente que pueda fomentar e instalar esta tecnología con los mejores
estándares de calidad.
Además también trabaja en el fomento y la difusión del conocimiento de la energía

geotérmica entre la opinión pública, a través de todo tipo de actividades, porque tal y
como ellos mismos manifiestan la energía geotérmica es una de las energías más
eficientes actualmente:
- Se trata de una energía limpia y renovable que aprovecha el calor del subsuelo
para climatizar de forma ecológica.
- Presenta importantes ventajas respecto a otros sistemas de climatización
renovables, ya que es uno de los pocos sistemas que permite obtener
refrigeración, calefacción y agua caliente sanitaria con la misma instalación.
- Se puede utilizar tanto en grandes instalaciones como en viviendas
unifamiliares. Una instalación geotérmica permite ahorrar hasta un 75% en la
factura energética y permite reducir las emisiones de CO₂.
98
- Se utiliza en numerosos países del centro de Europa, desde hace más de 40

años, como una de las principales fuentes de energía térmica, pero en España
su implantación está siendo más lenta, aunque hoy en día, existen numerosos
edificios que ya cuentan con esta forma de energía.
En sus cuatro años de existencia, ha logrado dar pasos importantes para el

desarrollo del sector en Galicia. A través del desarrollo de diferentes acciones
recogidas en su plan estratégico, el clúster ha conseguido que la energía geotérmica
sea valorada en Galicia y que el sector gallego empiece a posicionarse como referente
en calidad y efectividad.
Dentro de los principales proyectos del Clúster, destacan varias iniciativas que
forman parte de las acciones encaminadas a conseguir los objetivos de su plan
estratégico y que son parte de su filosofía básica, entre otras acciones, cabe resaltar
que han desarrollado un completo curso de formación “Instalacións Xeotérmicas de
Climatización con Bomba de Calor” cuya segunda edición se ha impartido con éxito en
el año 2013 en colaboración con la Escuela de Minas de la Universidad de Vigo a
través de la Plataforma de Teleformación (FaiTIC) de la propia Universidad, contando
con la participación de alumnos de otras partes de España, así como también de otros
países. De igual modo, la creación del Sello de calidad ACLUXEGA, pionero en
España y en Europa, que garantiza el rendimiento estacional y los mejores estándares
de calidad en la instalación y desarrollo de proyectos geotérmicos de muy baja
temperatura en la Edificación, la creación del Sello de Calidad en Perforación, etc.
Así mismo, han participado con empeño en el grupo de trabajo de AENOR que ha
cumplido el objetivo de desarrollar una norma UNE Española de referencia, así como
con la Xunta de Galicia, donde se han involucrado en el desarrollo de las dos
instrucciones de referencia para la geotermia en el ámbito de Galicia. En la primera, se
establecen los requisitos para la consideración de la energía geotérmica como
renovable, adelantando la trasposición de la Directiva Europea 2009/28/CE 28 en
nuestra Comunidad Autónoma, y en la segunda, estableciendo los requisitos para la
legalización de los sondeos de captación geotérmica simplificando los trámites
necesarios de manera notable.
5.3 Objetivos
ACLUXEGA tiene 4 objetivos principales que guían toda su trayectoria hasta el

momento, es decir, todas las actividades que realiza tienen que ver con uno o más de
los objetivos que se citan a continuación:
1.- Posicionar a Galicia como referente a nivel nacional.
La puesta en valor de las posibilidades de desarrollo de esta tecnología en

Galicia, aplicando los protocolos de calidad de ACLUXEGA, permitirá crear un marco
de referencia nacional para la promoción de la geotermia en España.
99
Dentro de este objetivo podemos situar todo el trabajo de los profesionales de

Galicia en el Comité de AENOR para el desarrollo de una norma UNE, trabajo que se
detalla en un apartado posterior y las participación en APPA y GEOPLAT.
2.- Normalizar los sistemas geotérmicos y capacitar a la base industrial.
Ante las diversas técnicas y sistemas de trabajo existentes, ACLUXEGA busca

la homogenización de las distintas fases del proceso de cálculo, prospección,
instalación y mantenimiento de los servicios geotérmicos. Se trata de consolidar una
base profesional capacitada para ofrecer los mejores estándares de calidad en la
instalación y desarrollo de proyectos geotérmicos para la edificación en Galicia.
Dentro de este objetivo ACLUXEGA ha puesto en marcha en el año 2013 la

MARCA DE CALIDAD COLECTIVA – SELLO DE CALIDAD ACLUXEGA , además de
crear un nuevo Grupo de Trabajo de Marca de Calidad en Perforación que ya ha
elaborado el REGLAMENTO DEL SELLO DE CALIDAD EN PERFORACIÓN,
desarrollado a petición del las empresas de sondeos del clúster.
3.- Fomentar el crecimiento del mercado y 4.- Potenciar el conocimiento de la

geotermia.
Fortalecer su sector a través de campañas de concienciación, formación y

estudios de mercado y pretende trasladar a la opinión pública las ventajas de esta
forma de energía que lleva más de 40 años aplicándose con éxito en Europa.
Dentro de estos objetivos se enmarca la asistencia a diversas Jornadas para el

fomento y sensibilización sobre la geotermia y nuestras actividades, la publicación del
Manual de Climatización Geotérmica – ACLUXEGA presentado también en el año
2013, la creación del Grupo de Trabajo del II Congreso Internacional de Geotermia y el
trabajo desarrollado para diseñar los nuevos cursos de formación que impartirá
ACLUXEGA.
En definitiva, desde ACLUXEGA se quiere contribuir a una correcta difusión de

las características y de los beneficios de la Geotermia a través de proponer la mejora
de la calidad y eficiencia energética de las instalaciones realizadas en Galicia. De esta
manera se intenta conseguir que las instalaciones que se realicen generen unas
expectativas reales y que satisfagan a los clientes.
5.4 Actividades
A lo largo de estos 4 años ACLUXEGA ha realizado múltiples actividades en

diferentes ámbitos. A continuación se hace una descripción de la naturaleza de los
distintos tipos de las mismas.
a. Reuniones:
En la asociación se realizan dos tipos de reuniones internas y externas.
Las reuniones internas son de dos tipos, las referidas a las de junta
directiva y asamblea general, que suelen comprender varias fechas al año. El
100
otro tipo son las reuniones de coordinación de grupos de trabajo que en el

último año han sido más de veinte.
Las reuniones externas son las más numerosas y se suceden a lo largo

del mes con frecuencia, en ellas se incluyen entidades de todo tipo tanto
público como privado. Además de con otros clústers y asociaciones abarcan
campos tan amplios como universidades, partidos políticos, empresas de todo
tipo, centros tecnológicos, cámaras de comercio, fundaciones, confederaciones
de empresarios, puertos, etc. Dentro de este grupo se incluyen también las
relacionadas con la administración, ayuntamientos, Consellerías etc.
b. Grupos de trabajo:
Son conjunto de personas asignadas o autoasignadas, de acuerdo a

sus habilidades, conocimientos y competencias específicas (profesionales o
expertos), para cumplir una determinada meta bajo la conducción de un
coordinador.
El sentimiento de pertenencia al grupo y el alto o bajo nivel de

satisfacción es lo común, aunque su productividad está limitada por la
combinación de interrelaciones sociales, existentes dentro de la organización
para lo cual existe un Reglamento de Régimen Interior de los
Grupo/Comisiones de Trabajo para establecer todo lo dicho anteriormente ya
que normalmente las personas se renuevan en este tipo de grupos cada cierto
tiempo.
Se gestiona la posibilidad de integración de los socios en los grupos de

trabajo ya creados así como la de proponer nuevos grupos de trabajo de
interés.
Los grupos existentes actualmente son: Sello de Calidad Instalaciones,

Sello de Calidad Perforación, II Congreso de ACLUXEGA (Comité Organizador
y Comité Técnico), Formación, Documentación, Normativo – Legislativo.
c. Asociados. Estudio Interno Asociados:
Se elabora con el objetivo de ofrecer mejores servicios a los asociados.

Para ello se plantean una serie de cuestiones para una mejor clasificación de
las empresas del clúster por actividades, proyectos e intereses que puedan
servir para la realización de próximas actividades del clúster, y en relación con
esto, la colaboración con otras organizaciones empresariales que forman parte
del sector de las renovables.
d. Manual de Climatización Geotérmica:

La publicación del Manual de Climatización Geotérmica, entra de lleno
en las líneas principales de trabajo de la Asociación, como la información,
difusión, formación y capacitación sobre geotermia, y su única pretensión, es
revertir y aportar el capital de conocimiento de las empresas que forman parte
101
de ACLUXEGA a la base industrial, y a todas aquellas empresas y personas,

que están interesadas en implementar este tipo de tecnología, fomentando, a
su vez, las buenas prácticas.
Con la publicación del Manual se pretende mejorar, perfeccionar y llegar

a los estándares de calidad más altos y a los mayores niveles de eficiencia
energética en el ámbito de la geotermia.
Actualmente el grupo de trabajo se mantiene activo para la confección

de una nueva edición, con la clara intención de mejorarlo y ampliarlo con el
tiempo.
e. Organización de actividades formativas y eventos.
Se encuentran dentro del objetivo de capacitación a la base profesional.

ACLUXEGA tiene convenios con la Universidad de Vigo para utilizar su
plataforma web “FaiTIC” así como el uso de las instalaciones de la Escuela de
Ingeniería de Minas para las clases presenciales.
Se han organizado dos ediciones del curso “Instalaciones Geotérmicas
de Climatización con Bomba de Calor”, del que se está preparando una tercera
edición para septiembre, cuyos objetivos son capacitar para el diseño del
proceso de instalaciones geotérmicas con bomba de calor, adquirir
conocimientos generales sobre geotermia e instalaciones geotérmicas, conocer
la situación actual y futura de la geotermia somera, así como desarrollar
conocimientos técnicos y específicos de la geotermia somera además de poder
reconocer aspectos normativos y de marketing relativos a la geotermia somera.
Del mismo modo este junio se impartirá el “Curso de aplicación práctica

de marketing para la venta de sistemas energéticos renovables” por primera
vez y con visos de continuidad en siguientes ediciones.
En cuanto a eventos de carácter divulgativo y formativo en 2010 se

organizó el “I congreso da Xeotermia de Galicia” del que este junio se celebrará
una segunda edición organizado con la Cámara de Comercio de Pontevedra
llamado “I Expo Congreso Nacional sobre Geotermia. II Congreso ACLUXEGA:
Eficiencia Energética y Reactivación”.
f. Información.
ACLUXEGA proporciona a sus asociados la actualidad en lo referente a

la geotermia y a otras energías renovables así como sobre subvenciones,
ayudas, licitaciones, disposiciones normativas de interés. También se informa
de cuestiones puntuales de interés para un asociado o un grupo de asociados,
tramitaciones, gestiones, etc.
g. Fomento de la presencia y visibilidad de ACLUXEGA y los asociados.
ACLUXEGA ha realizado un constante seguimiento de los medios de

comunicación, tratando de tener la mayor difusión posible de sus
reivindicaciones en las convocatorias de subvenciones de la Xunta, así como
publicitando el Manual y la formación. También se ha participado en la
negociación de precios especiales para anuncios de asociados del clúster, etc.
102
Además cuenta con una actualizada página web (www.acluxega.com) en la

cual además de las últimas novedades en cuanto a geotermia se ofrece para
los asociados:
- Mapa de Asociados por provincias.

- Listado según naturaleza de los asociados (fundadores, regulares,
colaboradores, colectivos, de honor, institucionales).
- Difusión específica de las empresas que forman parte de los Sellos de
Calidad ACLUXEGA (instalaciones y perforación).
Cada asociado puede incluir el logo de ACLUXEGA en su página web, como

“Miembro de ACLUXEGA”.
Figura 5. 1 Portada de la página web.
103
h. Convenios con otros Clústeres y Asociaciones:
Desde ACLUXEGA se están desarrollando diferentes convenios de

colaboración con otros Clústeres de Galicia de energías renovables, como son
CLUERGAL y AGAEN (Firma 05/06/2013). Cuyos puntos fundamentales son los
siguientes: relación dinámica entre clúster del sector energético, cooperación
empresarial, internacionalización y apertura exterior, vigilancia tecnológica, I+D+i,
marco institucional, legislativo y normalización, formación, etc.
Se ha previsto como una de las primeras actividades conjuntas la realización,

en el año 2014, de encuentros entre las empresas de los tres clústeres, como
acción de partida, así como el mantenimiento de reuniones de coordinación, entre
otras cuestiones, para optimizar temas de organización de las tres entidades y
planificarlas posibles colaboraciones durante el año.
También con asociaciones de instaladores entre las que se encuentra

FONCALOR (con la pretensión de su ampliación a todas las asociaciones de
instaladores de Galicia), para aprovechar y generar cuantas iniciativas o
propuestas sean necesarias para el desarrollo de nuestro sector.
Así mismo han establecido convenios de colaboración con el IGAPE,

realizando dos planes de formación para la concesión de dos Ingenieros de Minas
como Becarios durante el periodo de un año, y la concesión por parte de la
Universidad de Vigo (FUVI) de dos estudiantes en prácticas, por un total de 6
meses. En total han tenido a lo largo de estos meses 4 becarios.
Se mantiene activa la colaboración con APPA en apoyo a diversos

comunicados con otras organizaciones para la defensa de las energías
renovables, también con GEOPLAT en temas de formación.
5.5 Estructura de la asociación.
Como asociación que es ACLUXEGA está formada por una Asamblea General
con los socios regulares, colaboradores y colectivos que a su vez elige a una Junta
Directiva entre los socios. Es importante decir que los representantes de las empresas
son habitualmente sus máximos cargos directivos, secretarios generales, gerentes,
CEO (chief executive officer) o presidentes.
Los procedimientos mediante los cuales se regulan las acciones de la misma

se recogen en los estatutos de la asociación. En ellos aparecen reflejados las normas
que por acuerdo se establecen para el correcto funcionamiento del organismo,
abarcando campos como la finalidad de la asociación, los tipos de socios, las
admisiones, los derechos, las obligaciones etc. de los mismos, así como lo
concerniente al gobierno de la asociación, las competencias de la junta directiva, la
periodicidad de las elecciones, el derecho a voto etc.
La Junta Directiva está compuesta por un Presidente, un Vicepresidente, un

secretario general, un tesorero y un número de vocales entre uno y cinco. A su vez la
junta directiva designará a la Dirección General la cual es el órgano ejecutivo para la
dirección, organización y gestión de las actividades de la asociación, así como de
todas aquellas competencias delegables que permitan sus estatutos.
104
La Dirección General está actualmente compuesta por la directora, un becario

del Plan Re-Acciona del IGAPE (Ingeniero de Minas) y un becario de la universidad
(Estudiante de Ingeniería de Minas). Desde la misma se coordinan también los Grupos
de Trabajo, los cuales han quedado definidos ya en el punto anterior.
Actualmente tiene su sede y dirección general en una oficina el centro de la

ciudad de Vigo, aunque las reuniones de Junta Directiva y Asamblea General se
realizan habitualmente en distintos salones de actos en Santiago de Compostela.
A continuación se muestra el organigrama de la estructura de la asociación:
Asamblea General
Junta
directiva
Presidente
Vicepresidente Secretario Tesorero Vocal 1 Vocal 2 Vocal n
Dirección
general
Grupo Grupo
trabajo 1 trabajo n
Becario Plan Re-Acciona
Becario Universidad
Figura 5. 2 Organigrama de la asociación.
105
106
6.IMPLANTAR
OPENERP.
6. IMPLANTAR OPENERP
6. IMPLANTAR OPENERP.
Este proyecto se ha aplicado en la dirección general, la cual cuenta con una

oficina en la ciudad de Vigo, provincia de Pontevedra, en la calle Velázquez Moreno nº
9 .Tal y como se ha visto, consta de una directora y dos becarios. El becario del plan
Re-Acciona permanece durante todo un año, mientras que el de la universidad está
durante 3 meses. Por tanto, salvo una, son varias personas las que anualmente
desarrollan las mismas funciones en esta entidad.
Así, además de la gestión y coordinación de todas las actividades del Clúster,

tanto desde el punto de vista del planificador de proyectos como contable, surge la
necesidad de llevar a cabo una homogeneización de los procesos de tal manera que
sean los nuevos integrantes de la plantilla los que se adapten a estos y no al revés.
Para ello y ante la oportunidad que representa para ambos, ACLUXEGA

decidió contar como becario con el alumno de la universidad que estaba llevando a
cabo este proyecto, con el objetivo de compatibilizar ambas funciones.
De este modo la implantación de este ERP entra dentro de la categoría que se

ha visto en el apartado “2.9.3 Aplicación de niveles de costes” de Nivel 1 llevada a
cabo de manera interna por parte de la empresa. No se contrata a una consultoría
externa pero los miembros de la dirección general deben aportar tiempo de sus
funciones para esta labor no generando un gasto pero si consumiendo tiempo.
En cuanto a la duración del proceso y tal y como se ha visto a lo largo de este

proyecto, debido a que cada institución tiene su propio ecosistema de actuación, no
existe un período genérico para llevarlo a cabo, en este caso han sido 6 meses. No
obstante, hay que tener en cuenta que como los conocimientos del alumno tanto en lo
que concierne a la asociación como al propio OpenERP aumentan conforme el tiempo
pasa, la implantación conlleva mejores resultados conforme este es mayor. Es
relevante mencionar también que el becario trabaja a media jornada (4 horas) cuando
en los próximos puntos se mencionen periodos de tiempo como días o semanas.
6.1. Descripción del proceso.
Para realizar una implantación de un ERP en una asociación se deben realizar

una serie de pasos fundamentales que aborden la problemática de la tecnología de
acuerdo a las necesidades de la misma. Se ha de aclarar que no existe un método
común para implantarlo, ya que cada situación variará dependiendo de los objetivos,
de la empresa, del sector o de las personas que vayan a utilizarlo.
Para implantar este ERP se han completado los siguientes pasos:
Análisis.
Es el primer paso y se trata de la investigación necesaria para entender los

aspectos implicados en la gestión. En esta etapa se debe definir la situación actual en
la interacción con los asociados, estudiantes, servicios, procesos, comunicación, etc.
así como su relación con los distintos departamentos de la organización, las
109
herramientas tecnológicas que se utilizan para dichas interacciones y la estrategia de

planificación que se desea desarrollar.
Después de realizar esta investigación se deben definir las pautas sobre las
que funcionará el ERP y estas abordarán temas como la estrategia a seguir en las
distintas interacciones empresa/herramienta, necesidades de interacción del ERP con
otras herramientas y los condicionantes del proyecto de implementación como
objetivos, infraestructura necesaria, indicadores a medir, responsables, etc.
Diseño.
Es el proceso mediante el que se definen las características que tendrá el ERP

y los objetivos que deberá cumplir tanto técnicos como funcionales. En esta etapa se
han diseñado las bases de datos, los módulos básicos de OpenERP a utilizar y los
propios que habrá que crear y las modificaciones gráficas que pudieran resultar
pertinentes.
Desarrollo.
Se trata de la programación de los módulos propios que se han diseñado,

incluyendo todas las pruebas que se llevan a cabo para obtener los objetos tal y como
se habían previsto.
Implementación.
Después de realizar la investigación y el diseño de las características del ERP

se procede a la implementación de la tecnología. Se trata de algo mucho más
complejo que en la implementación de cualquier otro tipo de software, ya que los
resultados del mismo no se obtienen al momento y el proceso de adaptación suele ser
lento. Por ello, en esta fase, se vuelve muy importante el proceso de comunicación y
formación para que toda la organización se conciencie de la importancia de su uso y
de la responsabilidad de todos los departamentos en su utilización.
Puesta en marcha.
Después de cumplir los pasos anteriores la asociación debe comenzar a utilizar

la nueva tecnología. Para ello, surgirán inconvenientes por lo que se debe monitorizar
su desarrollo y solventar los posibles errores que surjan en el camino.
Algo muy importante a tener en cuenta es que estas etapas se llevan a cabo en
la mayoría casos a la vez. Como el conocimiento en la propia asociación aumenta con
el tiempo, mientras se está diseñando un módulo se están analizando otras partes. Así
mismo a medida que las habilidades del alumno programando mejoran se produce una
mejora en el diseño de los objetos. Además durante la implementación lo normal es
que se corrijan pequeños detalles, o bien aquellos que la en teoría quedan bien pero a
la hora de llevarlos a la práctica no resultan efectivos, o con sugerencias de los
usuarios que ayudan a mejorarlo, por ello se establece un periodo de pruebas.
110
6.2. Análisis.
En los anteriores apartados se ha descrito quienes son los componentes de

ACLUXEGA, que objetivos tienen, como se estructuran y que actividades que se
realizan.
En este punto habrá que estudiar cómo se lleva a cabo esta labor, conocer el
funcionamiento interno hasta el más mínimo detalle, carpeta a carpeta, archivo a
archivo. Será necesario analizar los proyectos pasados y presentes para poder
establecer una estructura de OpenERP que permita llevar a cabo de manera más
rápida y eficiente los mismos procesos o similares en el futuro.
Actualmente no existe en OpenERP una estructura para asociaciones sin

ánimo de lucro u ONGs por tanto habrá que hacer una adaptación de la parte de
PYMES en cuanto a contabilidad y CRM.
Para ello tal y como se ha visto en un ERP es fundamental conocer a quien se

le compra (proveedores) a quien se le vende (clientes) y quien lleva a cabo esta labor
(la propia empresa, recursos humanos). Ver imagen 2.2 Anatomía de un sistema ERP.
El objetivo es establecer que módulos se adaptan al Clúster y cuales hay que crear
para adaptar OpenERP a sus necesidades.
En consecuencia, lo primero que hay que preguntarse es, siendo esta una
asociación sin ánimo de lucro ¿Vende algo? Y si vende algo ¿A quién se lo vende?
ACLUXEGA es una asociación compuesta por empresas, instituciones y

personas individuales con un interés común muy claro, la Geotermia, tal como su
mismo nombre indica. Como se ha visto, la energía geotérmica es aquella que puede
obtenerse mediante el aprovechamiento del calor del interior de la tierra. Es una
energía renovable que se emplea para la obtención de electricidad y calefacción,
disminuyendo la dependencia energética de los combustibles fósiles.
El fomento de esta energía lleva a cabo una labor social de protección del
medio ambiente puesto que contribuye a disminuir el CO 2 emitido a la atmósfera y con
ello minimizar el impacto del efecto invernadero. Por tanto puede considerarse que es
la sociedad la que recibe los beneficios de la labor de asociaciones como esta.
En la práctica, para llevar a cabo este fin, ACLUXEGA proporciona servicios.

Ahora bien, si se facilitan servicios a los asociados ¿Se puede considerar a estos
como clientes? Hay que tener en cuenta que son ellos quienes gobiernan la asociación
¿Son acaso empleados de la misma, cuando sin embargo, pagan por formar parte de
ella?
Por otra parte ACLUXEGA organiza cursos, jornadas formativas, conferencias

y congresos para alumnos y profesionales de este u otros sectores relacionados
¿Pueden considerarse a estos como clientes? Y en el caso de los cursos ¿Pueden
tratarse a los profesores como proveedores? Teniendo en cuenta además que
habitualmente estos son socios, con la consiguiente duda de si considerarlos clientes y
a la vez empleados. A su vez, ¿No es acaso la propia ACLUXEGA un proveedor de un
111
curso puesto que organiza desde la contratación de los profesores, la gestión de la

formación bonificada y hasta la entrega de diplomas a los alumnos?
Como puede apreciarse, de un análisis grosso modo se desprenden más

incógnitas que respuestas, ahí es donde entra en juego la implicación de los
integrantes de la dirección general encabezada por su directora en el proyecto.
Por tanto habrá que proceder al análisis del material de la asociación. Para ello
a este alumno se le han facilitado, previo compromiso de no divulgación, todos los
archivos de la misma. En este caso el sistema actual de compartición es Dropbox, que
será a partir del cual haya que realizar la migración.
Lo que se ha hecho es una copia de todos los archivos y se han ido agrupando
en carpetas y por tipos de archivo, Word, Pdf o Excel. OpenERP permite la inserción y
extracción de datos en este último formato, con lo cual será en este en el que haya
que centrarse a la hora de pensar en módulos propios, ya que los otros pueden ser
fácilmente incorporados tanto en el módulo “Project” como a través de “notas” o en los
foros de “Mensajes”.
Un factor fundamental a tener en cuenta es la contabilidad. En ACLUXEGA

existe un Régimen contable general gestionado por una asesoría. Por la estructura de
la asociación, para poder emplear los fondos será necesaria la firma de dos de los
miembros de la Junta Directiva.
Sin embargo, resulta evidente que la Dirección General necesita cierto control
sobre el dinero ya que será una de las encargadas de la obtención de fondos y de la
organización de actividades, por tanto de ver cuánto se puede gastar. Para ello lo que
si pueden es acceder a los registros del banco, para, por ejemplo , corroborar que los
socios estén al día en cuanto al pago de sus cuotas, o si se han cobrado las
subvenciónes que se esperaban.
En cuanto a los pagos hay dos tipos. Para las sumas altas estos se realizarán
por transferencia bancaria, por tanto con la firma de los directivos, y el efectivo de caja
para pequeños pagos como material de oficina o transportes de la directora a juntas,
estas cantidades serán adelantadas por la misma y reintegradas por ejemplo en su
sueldo como dietas.
A la hora de realizar cursos con formación bonificada la Fundación tripartita

exige una contabilidad propia para estos, aunque luego haya que enviar una copia al
contable para que la incluya en la contabilidad general. Algo similar sucede con los
foros y congresos, ya que lo común será realizarlos con otras instituciones como otros
Clústers o Cámaras de comercio, por ejemplo.
A tener en cuenta también en el aspecto de la contabilidad es la previsión de

ingresos y gastos en los meses siguientes, para comprobar si a asociación puede
seguir sosteniéndose económicamente.
A efectos de OpenERP la conclusión es que serán necesarias tres tipos de

bases de datos. Una base de datos general, que en teoría será única. Una base de
datos para cursos, con una estructura definida aunque adaptable gráficamente, de tal
manera que cada vez que se quiera organizar un curso se instale una base de datos
112
de este tipo. Y la tercera de congresos, en la que sucederá lo mismo, para cada uno
de ellos se creará una nueva base de datos.
El objetivo de que haya varias y no estén todas en la general es tener las

contabilidades separadas, así como los contactos, puesto que los alumnos de un
curso lógicamente no serán los mismos que los de ediciones anteriores, pero tampoco
tendrán porque coincidir con los de otros cursos. Lo mismo sucede en la organización
de congresos. En la parte que a proyectos se refiere, el que tanto para los cursos
como para congresos estén por separado, facilita el tener una visión global desde la
base de datos general sin producir una saturación que podría resultar perjudicial.
Por otra parte, además de la gestión de proyectos y servicios es muy

importante conocer a los asociados, a los cuales se representa para que obtengan los
mejores beneficios de la gestión. Ello se hace mediante la realización de encuestas.
Estas permiten por ejemplo conocer que el total de las empresas de la asociación
factura al año más de 360 millones de euros generando 1200 empleos. Además
permiten saber el ámbito de actuación, a nivel gallego, estatal e internacional. De este
modo, en la Asamblea General realizada durante este proyecto se ha aprobado la
ampliación del Clúster al resto de España, con la posibilidad incluso de establecer
sedes fuera de Galicia. Hay que recordar que, en la actualidad, este es el único
Clúster de geotermia de España.
6.3. Diseño.
Esta etapa consecuencia de la de análisis, está íntimamente ligada con la de

desarrollo. Cuando se diseña un objeto, se programa y se comprueba si es lo que se
desea, si lo es se da por bueno el resultado y si no se sigue desarrollando hasta que
sea lo suficientemente satisfactorio. En los puntos en que se explican los módulos
propios y se enseña una imagen del objeto, esto es lógicamente después de haber
sido desarrollados.
A la hora de diseñar las bases de datos es necesario definir la anatom ía propia

que tendrá el OpenERP de la asociación. Para ello se ha estructurado tal y como se
indica en la Figura 6.1.
113
Recursos
humanos
Gestión de
Encuestas proyectos
ACLUXEGA
OpenERP
Contabilidad Eventos
Datos Cursos
asociación congresos
Figura 6. 1 Anatomía de OpenE RP de A CLUXEGA.
Tal y como se ha llegado a concluir con el análisis será necesario diseñar 3

bases de datos. Para saber que módulos básicos de OpenERP se adaptan mejor a las
necesidades de la asociación, se acude a la Guía descriptiva de módulos básicos de
OpenERP ANEXO II que se ha creado durante este estudio de OpenERP.
Figura 6. 2 Bases de datos creadas para OpenE RP.
A continuación se explicarán en detalle las tres bases de datos con los motivos
que han llevado a instalar unos módulos u otros, así como con una descripción
detallada de los que han sido creados.
6.3.1 ACLUXEGA_GENERAL.
Se establece esta como la base de datos principal de la asociación, lo normal

será que haya sido instalada una sola vez y salvo que suceda algún tipo de problema
no sea necesario crear otra similar. Debe abarcar todas las áreas de trabajo posibles
114
presentes y futuras, pero así mismo hay que evitar la instalación de módulos que no
sean necesarios, pues lo que se pretende es un acceso más eficiente a la información.
Como se ha mencionado anteriormente las aplicaciones, salvo las propias, no

coincidirán con los módulos a instalar, en la imagen siguiente se detallan las instaladas
para esta base de datos, describiendo después cada uno de los módulos. Puede
llamar la atención, que a pesar de que OpenERP cuenta con la aplicación del CRM se
ha decidido no instalarla esto es porque con ella se instala parte del módulo de
“Ventas” que no resulta necesario. Aún así tal y como se ha visto en el apartado 2.6 de
este mismo proyecto que no contenga específicamente esta aplicación no significa que
en conjunto no cumpla dichas funciones.
Figura 6. 3 Aplicaciones instaladas ACLUXE GA_GE NERA L
115
Figura 6. 4 Módulos instalados ACLUXEGA_GENE RAL.
6.3.1.1 Módulos básicos.
6.3.1.1.1 Mensajería.
Este módulo se instala por defecto una vez se instale cualquier aplicación
básica. Puede completarse con las aplicaciones “Calendario” “Contactos” y “Notas”. En
su bandeja de entrada aparecen reflejados los mensajes del resto de usuarios, así
como si han creado algún proyecto o han compartido algún tipo de documento. Puede
configurarse también para enviar mensajes de correo electrónico con Mozilla
Thunderbird aunque en este caso no se ha considerado necesario hacerlo.
La parte de grupos resulta muy útil de cara a compartir los documentos de

manera ordenada, además se podrá decidir a quién se le comparten.
6.3.1.1.2 Project.
En una asociación cuyo software más complejo es el Microsoft Office sin incluir
el Microsoft Project, este módulo es el más importante d e todos. Está basado
precisamente en este mismo.
La planificación actual se lleva cabo en una agenda de papel, y en muchas

ocasiones cada vez que se quiere conocer cuando es cada actividad hay que buscar
el archivo y dentro del la ficha donde lo ponga. Esto además de no permitir una visión
global, ocupa espacio y dificulta mucho el que el resto de miembros estén al corriente
de las mismas.
Figura 6. 5 Proyectos.
Este módulo permitirá crear tareas para un proyecto, asignárselas a un usuario

o varios y dentro de cada una de ellas escribir comentarios e insertar documentos. Sin
una planificación adecuada uno no es consciente de todas las tareas que llega a
116
llevar a cabo, y además perdería en muchas ocasiones más tiempo explicándoselas a

alguien con detalle que realizándolas.
Figura 6. 6 Tareas
La vista Gantt además permite visualizar mejor en el tiempo la consecución de

las mismas, tal y como sucede con el Microsoft Project.
Figura 6. 7 Vista Gantt de las tareas.
Con este módulo se mejora la planificación permitiendo además del ahorro de

tiempo correspondiente, el poder delegar las tareas, con lo que en este caso la
directora dispone de más tiempo para seguir planificando procesos. Esto es muy
importante de este modo, cuando la responsable se encuentra en reuniones fuera de
la sede puede dejar todo el trabajo perfectamente definido, y como se verá en la parte
de implementación, incluso a través de internet podrá seguir asignando tareas.
6.3.1.1.3 Contabilidad.
Este módulo es junto con el de proyectos el más importante. Además está

presente en otros objetos, en el de la propia compañía, en el de los empleados, es el
módulo más complejo de OpenERP. Por tanto será el que requiera un mayor tiempo a
la hora de implantarlo ya que habrá que ir poco a poco familiarizándose con el mismo
para ver las posibilidades que puede llegar a ofrecer, puesto que en ocasiones no
siempre lo más complejo resulta ser lo más útil.
6.3.1.1.4 Recursos humanos.
Para esta base de datos, al contrario que para las otras dos, se han instalado
todas las aplicaciones correspondientes a este módulo. Como se ha visto, la dirección
general de ACLUXEGA además de por la directora está compuesta por dos becarios.
Ello requiere que aproximadamente cada 6 meses haya que llevar a cabo un proceso
de selección. Además interesa también conservar la información precisamente sobre
los que abandonan el puesto, ya que esto no sucede porque no se considere a la
117
persona apta para el puesto sino que está condicionada por la beca o los convenios
correspondientes.
También hay que tener en cuenta que se trata de un Clúster, por tanto son
muchos los curriculums que llegan con la intención de ser enviados a las empresas,
algo que actualmente se hace, pero que en el futuro se espera poder coordinar mejor.
Un detalle importante a tener en cuenta con respecto a OpenERP es que no

todos los que estén como empleados tendrán que ser usuarios del sistema, podrá
serlo quien así se considere y del mismo modo al revés y esto es importante para la
parte de encuestas.
Tendrá relación con el módulo contabilidad, puesto que desde el se podrán

gestionar los gastos de los empleados, que como se ha visto resulta muy importante
dada la estructura de ACLUXEGA a la hora de administrar la caja.
Figura 6. 8 Relación Recursos humanos con Cont abilidad
6.3.1.1.5 Encuestas.
Este módulo va ligado al de recursos humanos, no es posible su instalación sin

él. Sin embargo quien responderá a la encuesta serán los usuarios de OpenERP que
no necesariamente deben estar como empleados.
Es más, posiblemente la mayor aplicación práctica que tiene es la de realizar

las encuestas a los asociados. Se les asigna un usuario con una clave, se configuran
los permisos de tal modo que solo puedan ver este módulo y basta con que accedan
desde un enlace en un área privada de la página web de ACLUXEGA.
118
Figura 6. 9 Vista de Encuestas para una empresa.
En ningún caso podrían ver ni el resto de módulos, ni en este mismo las

respuestas de otros miembros. Por tanto este módulo se convierte en uno de los de
mayor potencial en cuanto a usuarios ya que abarcaría a todos los socios.
6.3.1.1.6 Eventos.
Es un módulo que podría considerarse secundario, porque el Project podría

abarcar sus funciones. Sin embargo pensando en un usuario con clave para cada
socio, podría servir tal y como se ha visto en el caso de las encuestas para compartir
eventos. Estos permisos los regulan los usuarios principales y serán ellos los que
deban considerar si es oportuno o no y si deciden hacerlo. Precisamente ante una
saturación del de proyectos podría servir como complemento.
6.3.1.1.7 Informes.
Es un módulo generado automáticamente por OpenERP y funciona tal y como

viene en la Guía. Resultan interesantes la parte de las encuestas y la de los proyectos
así como la de contabilidad en este caso. Permite ver gráficas, comparar estadísticas y
extraerlas en formato Excel, png o PDF según sea el caso.
6.3.1.2 Módulos propios.
Se ha decidido crear 5 módulos propios para esta base de datos con el objetivo
inicial de adaptar OpenERP a la asociación. Sin embargo, para el alumno que realiza
este proyecto, el no conocer la ubicación de los archivos le ha llevado a tener que
preguntar dónde estaba cierta información básica y no toda se encontraba fácil ni
intuitivamente como podría parecer lógico. Por ello ha habido que diseñar los módulos
y los objetos partiendo de cero. De esta manera y con el OpenERP abierto con dos
“clicks” de ratón, uno en el módulo y otro en el objeto se puede acceder a cualquier
dato importante y con un tercero a los detalles.
6.3.1.2.1 Lista de correos.
En ACLUXEGA constantemente se están buscando contactos de empresas

relacionadas con la geotermia y la eficiencia energética así como con la arquitectura y
las ingenierías en general. El objetivo de ello es la promoción y difusión del Clúster en
toda España. Se les envía información general sobre la asociación, sobre las
actividades que se realizan, del manual de climatización energética, de cursos,
119
congresos, jornadas, etc. Es a partir de este punto donde se produce un primer

contacto que en múltiples ocasiones genera frutos para ambas partes.
Este módulo ha sido el primero que se ha creado, directamente a partir de un

archivo Excel y de lo que se trata es de una base de datos de correos electrónicos.
Está dividido en 21 objetos y son todos absolutamente iguales, el objetivo es dividirlos
por tipos.
Figura 6. 10 Menú de “Lista de correos”.
Como vista se le han creado las dos básicas, la lista y la formulario. No

contienen ningún elemento de diseño y a efectos didácticos sirve para mostrar la
evolución en la mejora del diseño y programación.
120
Figura 6. 11 Lista de correos
6.3.1.2.2 Asociados.
Tal y como su mismo nombre indica este módulo se ha creado para el acceso a la
información de los socios.
Figura 6. 12 Menú Asociados.
121
Junta directiva.
En este objeto se tiene la información de los miembros de la junta directiva.

Tiene como vistas la kanban, en la cual los campos que se ven son el cargo, el
nombre y el nombre de la empresa, vista lista y vista formulario.
Figura 6. 13 Junta directiva.
Grupos de trabajo.
Este menú en realidad está formado por dos objetos ya que dentro del de
grupos de trabajo se encuentra en una relación one2many el objeto miembrosgt.
Contiene las vistas kanban, lista y formulario. Es el destinado a contener la
información de los distintos grupos de trabajo. Se puede elaborar una lista con la
información de los distintos miembros. Una vez creado este, bastará con pinchar
encima en la lista para que aparezca la información con otra vista formulario.
Figura 6. 14 Grupos de trabajo
Para crear un nuevo miembro de grupo de trabajo se pulsa en “añadir

elemento” y aparece la pantalla que se ve en la imagen a continuación. Una vez
creado, para verlo de este modo bastará con pulsar encima y aparecerá.
122
Figura 6. 15 Miembro de grupo.
Lista asociados.
Tal y como su nombre indica es una lista de socios, que son más de 40
actualmente, por tanto se ha creado una vista kanban con los campos del nombre de
la empresa, su correo electrónico y su web. Esta vista la completan una vista lista y
una vista formulario. En esta última se ha creado una notebook con dos páginas para
indicar si el socio tiene el sello de calidad ACLUXEGA de perforación y/o el de
instalador que incluye a ambos. Para ello se han empleado campos con relación
many2one con los correspondientes en la parte inferior del menú, de tal modo que
cuando se cubra en el de un socio ya quede el objeto creado. El campo obligatorio es
el que se ha elegido para que aparezca en el campo relación.
Figura 6. 16 Lista asociados.
El diseño de los objetos de “alta en sello”,”concesión sello” y “denegado” es

igual, por lo que ya no se indica un ejemplo.
123
Figura 6. 17 Alta en sello.
Figura 6. 18 Concesión sello.
Figura 6. 19 Denegado.
Clasificación empresas.
Este objeto se ha creado a partir de un Excel basado en una encuesta y sirve

para tener una visión rápida del ámbito de las empresas del Clúster.
124
Figura 6. 20 Clasificación empresas.
Altas, Bajas, Variaciones, Otros.
Tienen los mismos campos, coincidentes, salvo detalles como la imagen, con el
de la Lista asociados, y sirven para esos registros que no están dentro de esa
categoría o bien porque aún no han completado el proceso de incorporación o porque
se hayan dado de baja.
Figura 6. 21 Altas, Bajas, Variaciones, Otros.
Menú contacto.
Son 6 objetos, iguales, que no los mismos, a los de lista de correos. Se ha

creado este menú al completo como lista de contactos de importancia, aunque no
sean socios. Si por la razón que fuere no fuese necesario este menú o sus objetos
siempre pueden “eliminarse” en modo gráfico y recuperarse del mismo modo si hiciese
falta.
6.3.1.2.3 Legislación.
Una de los servicios de ACLUXEGA es mantener al día a los asociados de toda

la legislación sobre geotermia o energías renovables, así como la concesión de
licitaciones o salidas de obra pública a concurso que pudiera afectarles. Por ello se ha
creado este módulo con el objetivo de tenerla recopilada y clasificada, al menos desde
un punto de vista accesible, no se pretende que sea esto una recopilación de
documentos del BOE. Para ello podría emplearse tanto el Project como el objeto
Alertas enviadas dentro del módulo propio Geotermia.
125
Figura 6. 22 Menú Legislación.
En este módulo todos los objetos son iguales, salvo los de las comunidades
autónomas, porque habrá que indicar en cual y para facilitar esta labor además de una
imagen se ha configurado con una vista kanban. Que todos los objetos sean iguales,
siempre y cuando no se repita la información no es malo, lo que se pretende es tenerla
lo más organizada posible.
Figura 6. 23 Legislación: objeto genérico.
126
Figura 6. 24 Legislación: Comunidad autónoma.
6.3.1.2.4 Subvenciones.
Por tratarse de un tipo de energía renovable y eficiente es habitual que se concedan
subvenciones tanto a las empresas como a los usuarios para llevar a cabo las
instalaciones. Lo cual es motivo de interés por ambos motivos para los asociados y por
tanto uno de los trabajos más habituales será indagar en las páginas oficiales de las
distintas administraciones en la búsqueda de las novedades en este aspecto.
Con el objetivo de tenerlas recopiladas y fácilmente accesibles y que todos los que
realicen esta labor de búsqueda se centren en los mismos aspectos se ha creado este
módulo.
Figura 6. 25 Menú Subvenciones.
127
Hasta el punto llega esta estandarización que todos los objetos son iguales en
diseño, solo variarán los del menú de subvenciones estatales puesto que en ellos se
ha considerado oportuno la vista kanban, para diferenciar entre comunidades
autónomas.
Figura 6. 26 Objetos Menú Subvenciones estatales.
Figura 6. 27 Resto de objetos de Subvenciones
6.3.1.2.5 Geotermia.
Quizás lo que menos represente el contenido de este módulo sea precisamente
su nombre. Ha sido el último que se ha creado y se ha hecho a partir del menú
Comunicación y promoción del módulo de Congresos. La utilidad de este módulo es la
de incluir todo aquello que no encaja en los otros o para aquel conjunto de objetos que
por ser pocos se vuelva desproporcionado crear todo un módulo entero. Por decirlo de
128
otro modo, cuando se necesite crear un nuevo objeto y no encaje con los demás, no
será necesario programar un módulo entero, del mismo modo puede insertarse
gráficamente el que se desee.
En este módulo por tanto todos los objetos serán distintos.
Figura 6. 28 Menú Geotermia
Alertas.
Se trata de un objeto para recopilar aquellos lugares de internet donde se ha

suscrito a las “Alertas de Google”. Las Alertas de Google son mensajes de correo
electrónico que se reciben cuando Google encuentra nuevos resultados (por ejemplo,
páginas web, artículos de periódico o blogs) que coinciden con un término de
búsqueda que se asigna.
En este objeto se ha configurado con vista kanban puesto que servirá para
distinguir la de las distintas comunidades autónomas, o entre instituciones.
Figura 6. 29 Alertas.
Alertas enviadas.
Sirve para recopilar las que se le envían a los socios, tanto Alertas de Google
como licitaciones o subvenciones. Se emplea por primera y única vez en los módulos
personalizados de esta base de datos el campo binario de insertar un documento de
cualquier tipo. Solo habrá que saber sencillamente con que programa se abre
después.
129
Figura 6. 30 Alertas enviadas.
Preguntas y respuestas.
A través de correo electrónico en muchas ocasiones gente que ve la página

web o conoce a la asociación por otros medios realiza preguntas técnicas sobre
instalaciones geotérmicas y desde ACLUXEGA, sean asociados o no, se trata, en la
medida de lo posible, de responderlas. Lo que no puede el Clúster es recomendar a un
asociado u otro, en todo caso la información que se proporcionará si piden
recomendación será la de todos.
Por ello se ha creado este objeto, para tener una recopilación de las preguntas
y respuestas más frecuentes.
Figura 6. 31 Preguntas y respuestas.
Medios.
Este objeto se ha creado para tener recopilada la información sobre los medios
de comunicación. Se tiene un campo relación many2one con el objeto siguiente
contactos. Se ha creado con vista kanban para que sea más fácil su identificación.
130
Figura 6. 32 Medios.
Figura 6. 33 Contactos.
Web propia.
La asociación tiene su propia página web www.acluxega.com y aunque los

artículos y el contenido si se gestionan desde la dirección general, quien pone el
contenido en ella es una empresa externa, la encargada del mantenimiento de los
equipos informáticos.
Este objeto puede servir para escribir el contenido y después proporcionárselo

a dicha empresa. Posiblemente esta función pueda llevarse a cabo desde el Project,
con la diferencia de que mediante permisos y la asignación de un usuario del
OpenERP a esa empresa externa si está en este objeto podría realizarse la
compartición de forma directa.
Figura 6. 34 Web propia.
131
Publicidad.
Sirve para gestionar los anuncios que se lleven a cabo en los diversos medios,
de hecho tiene un campo relación many2one con este objeto. Permite un registro del
presupuesto y se ha programado de tal modo que puedan guardarse aquí hasta 3
imágenes.
Figura 6. 35 Publicidad.
Noticias generadas.
Servirá este objeto para tener una recopilación de las noticias generadas en los
medios, sin tener que crear un archivo en Word para cada una. Ayuda a que estén
ordenadas y pudiendo insertar imágenes se puede añadir un escaneo si fuera en
prensa escrita. Se evita con crear archivos innecesarios.
Figura 6. 36 Noticias generadas.
Imágenes.
Es un objeto que permite poner imágenes como su propio nombre indica. Se

pueden poner 10 cada vez con la fecha e información sobre las mismas. Es como un
álbum de fotos. La utilidad se reviste precisamente en que nunca se sabe donde
132
guardarlas, porque lo habitual es que vayan asociadas a una actividad específica y al

final acaban tan dispersas que cuando se necesitan nunca aparecen y de este modo
están todas en el mismo directorio.
Figura 6. 37 Imágenes (figura recortada, serían 10 en total).
6.3.2 CURSO_NOMBREDELCURSO.
Esta base de datos ha sido motivada por el curso “Instalaciones Geotérmicas

de Climatización con Bomba de Calor”, del cual ya se han realizado dos ediciones y se
prepara una tercera para septiembre y por el curso “Aplicación práctica de marketing
para la venta de sistemas energéticos renovables” que se ha organizado desde el
comienzo durante el transcurso de este proyecto.
Al contrario que la anterior esta no es una base de datos estática que haya que
instalar siempre del mismo modo. Se propone una genérica con las mayores
prestaciones posibles, pero sin resultar excesivas, que podrá adecuarse a las
circunstancias. Si por ejemplo, con la base de datos general se considera que puede
planificarse no sería necesario instalar el Proyect. Del mismo modo si se tratase de
una conferencia o jornadas gratuitas podría excluirse el de Contabilidad.
Pero es precisamente este el de contabilidad el que motiva esta base de datos.

Como se ha visto, para poder realizar la Formación bonificada será necesario contar
con una contabilidad propia para el curso, al margen de que posteriormente se refleje
en el Régimen contable general.
También el que un curso o una conferencia pueda ser organizado con otra
institución, esta base de datos podría ser utilizada por ambas, facilitando la
comunicación y la compartición de archivos.
133
A continuación se muestran las aplicaciones instaladas, su resultado en cuanto

a módulos y una descripción de estos.
Figura 6. 38 Aplicaciones instaladas para CURSO_NOMB REDE LCURSO.
Quedando como resultado una vez instalados tal y como se muestra en la

figura:
Figura 6. 39 Módulos instalados CURSO_NOMBRE DELCURSO.
Este módulo se instala por defecto, es el mismo que se ha visto en el anterior,

con la excepción de que no se ha instalado el de Notas.
134
6.3.2.1.2. Project.
Si en la base de datos ACLUXEGA_GENERAL se consiguiese plan ificar quizás

este módulo sobraría. Sin embargo y pensando en los cursos que se crean desde un
inicio el hacerlo en esa puede llegar a resultar cargante. Además si el curso o las
jornadas se llevan a cabo con otra organización este módulo se convierte en esencial
para la asignación de tareas y compartición de archivos entre ambas, evitando el uso
excesivo del correo electrónico o las llamadas telefónicas.
6.3.2.1.3. Contabilidad.
Tal y como se ha dicho este módulo se convierte en fundamental en un curso

en el cual haya que tener una contabilidad propia y en innecesario cuando la misma
sea llevada a cabo por otro de los organizadores o las jornadas sean gratuitas.
En este caso, lo clientes serán los alumnos, bien modo particular o a través de
su empresa y los proveedores serán los profesores y la propia ACLUXEGA o los que
hayan intervenido en su gestión.
Este módulo no resulta de especial importancia en esta base de datos. Se

instala solo si se desea realizar encuestas a los alumnos, ya que no puede instalarse
el otro sin este. Aún así se puede tener aquí a los profesores y creando un menú
gráficamente de este objeto dentro del módulo propio Curso incorporarlo borrando el
creado para tal función.
Sirve para hacer las encuestas a los alumnos, con el objetivo de ir mejorando
progresivamente el curso en siguientes ediciones. Por tanto con él se ahorra papel si
las encuestas se realizan de este modo o si son enviadas, se evita saturar la bandeja
de correo electrónico. Teniendo en cuenta que en alguno de los cursos hay hasta 80
alumnos y si el curso fuese organizado por varias instituciones, este módulo hace que
la base de datos tenga un potencial de uso de cerca de 100 usuarios.
6.3.2.1.5 Informes.
Instalado por defecto, cumple las mismas funciones que el de la base

ACLUXEGA_GENERAL.
6.3.2.2. Módulo propio: CURSO.
Este módulo se ha creado para disponer de toda la información del curso o el

evento, como adaptación de los archivos existentes de las ediciones anteriores. El
nombre de Curso pretende ser genérico pudiendo este adaptarse gráficamente a
Jornadas, Conferencia o lo que se considere oportuno.
135
Figura 6. 40 Menú Curs o.
Este módulo podrá ser susceptible de cambios en modo gráfico para adaptarlo
a los distintos eventos. Si se llega a instalar el de recursos humanos quizás sería
recomendable borrar gráficamente el menú “tutores” e introducir en él el de
“empleados”, tal y como se explica en el ANEXO IV. Las combinaciones son múltiples
y serán los usuarios los que finalmente puedan decidir cuales emplear.
Ficha.
Tal y como su mismo nombre indica sirve para definir los campos a cubrir en
una ficha de un curso. Porque la otra opción evidente es coger la de un curso anterior
y modificarla, pero al final hay varias versiones de la misma y comprobar cuál es la
más actual puede llegar a convertirse en todo un problema. De todos modos se tiene
el campo binario para poder guardar aquí un documento, la versión más actualizada,
por tanto, de la misma.
136
Figura 6. 41 Ficha del curso.
Calendario y fechas.
Este menú está compuesto por dos objetos, ambos iguales y a priori podría
parecer que sería conveniente integrarlos dentro de la ficha. Sin embargo no es tarea
sencilla establecer la fecha en la que llevar a cabo un curso. El objetivo es que haya la
mayor cantidad de alumnos posibles y para ello habrá que estudiar qué fechas les
conviene más, por ejemplo en el caso de los universitarios con su calendario de
exámenes. Así mismo también habrá que tener en cuenta las de disponibilidad de
profesores o en el caso de clases presenciales de la del local.
Figura 6. 42 Periodo de matrícula y de docencia.
Lista preinscritos.
Tal y como su mismo nombre indica servirá para tener una lista con los alumnos
preinscritos, se parecerá a la de matriculados para poder importar mejor los datos.
Figura 6. 43 Lista preinscritos.
137
Lista matriculados.
No es realmente un objeto puesto que está compuesto por tres. Además del
Lista matriculados contiene mediante dos campos relacionales one2many los objetos
Asistencia y Evaluación.
Figura 6. 44 Lista matric ulados.
Figura 6. 45 Asistencia.
Figura 6. 46 E valuación.
Lista bajas.
Este objeto es exactamente igual que el de Lista preinscritos y su función está

claramente definida por su nombre, registrar a los alumnos que se han dado de baja.
138
Formación bonificada.
Sirve para tener en un apartado a parte a los de la formación bonificada, en el

Lista preinscritos se indica, pero no se visualiza tan bien como en este. Si se ha
creado, aunque pudiera parecer repetitivo, es porque el archivo Excel aparte existe y
se utiliza con frecuencia.
Figura 6. 47 Ficha alumnos.
Tutores.
Permite tener la información sobre los profesores, tal y como se ha visto puede
sustituirse por el de “empleados” de Recursos humanos, pero por si no se instalase
este módulo, este objeto cumpliría las funciones.
Figura 6. 48 Tutores.
6.3.3 CONGRESO_NOMBRE.
Durante los meses que se ha llevado a cabo este proyecto en ACLUXEGA se

ha estado organizando junto con la Cámara de comercio de Pontevedra el “I Expo
Congreso Nacional sobre Geotermia. II Congreso ACLUXEGA: Eficiencia Energética y
Reactivación” a realizar el 12 y 13 de junio de este 2014. Se ha decidido aprovechar
esta oportunidad para crear una base de datos tipo para organizar un congreso.
Este ha sido la última de todas las que se han diseñado, y por tanto en la que
más conocimientos acumulados se tenían, por lo que a medida que se iba realizando
se iban mejorando todas las demás. Del mismo modo para llevarla a cabo se ha
tomado como referencia la base CURSO_NOMBREDELCURSO.
139
Las aplicaciones instaladas han sido las siguientes y el resultado a

continuación:
Figura 6. 49 Aplicaciones CONGRESO_NOMBRE.
Figura 6. 50 Base de dat os CONGRESO_NOMB RE.
Este módulo se instala por defecto, es el mismo que se ha visto en el anterior,

con la excepción de que no se ha instalado el de Notas. Dado que en un congreso lo
normal es que haya más organizadores, este módulo toma una mayor importancia,
140
puesto que contantemente se estarán creando proyectos y subiendo archivos, con lo

que las notificaciones se hacen imprescindibles.
6.3.3.1.2. Project.
En la organización de un congreso este módulo es sin lugar a dudas el eje

central, la gestión de proyectos con la cantidad de tareas que hay que realizar se
facilita en gran medida con él. A lo largo de este proyecto ya se han comentado sus
múltiples ventajas, con lo cual a ellas se remite este apartado.
6.3.3.1.3. Contabilidad.
La gestión de la contabilidad en un congreso en el cual intervengan varias

entidades es algo muy importante y complejo que hay que negociar. Él quien realiza
los gastos, las fuentes de financiación o las subvenciones condicionarán en gran
medida la calidad de los ponentes e instituciones participantes.
Desde un punto de vista de la formación de los usuarios, no sería

recomendable que si la contabilidad no la lleva a cabo ACLUXEGA instalar este
módulo para compartir. Así como el Project presenta una “usabilidad” más intuitiva, no
es el caso de este que requiere ciertos conocimientos prácticos y su empleo puede
llegar a convertirse más en un inconveniente que en una ventaja.
Resulta evidente que en un congreso habrá que contratar personal. Aunque los
organizadores y colaboradores lleven a sus propios empleados, será necesario
contratar azafatos/as, camareros/ras, o incluso intérpretes, No se ha instalado el
módulo al completo, porque es un evento que solo requiere dos días y por ejemplo los
partes de ausencias carecerían de toda lógica.
En este caso y dada la cantidad de asistentes que puede llegar a tener un

congreso desde un punto de vista logístico podría llegar a complicar más que a facilitar
la utilización de este módulo. Sin embargo, para encuestas internas con las otras
organizaciones o incluso a los empleados puede llegar a resultar interesante. En todo
caso si se considera innecesario puede “eliminarse” en modo gráfico.
6.3.3.1.6 Informes.
Instalado por defecto, cumple las mismas funciones que el de la base

ACLUXEGA_GENERAL.
6.3.3.2. Módulo propio: CONGRESO.
Tanto este módulo como el de Curso tienen un nombre genérico siendo

perfectamente adaptables para eventos intermedios como jornadas o conferencias. La
utilización de uno u otro dependerá de las necesidades del momento.
141
Figura 6. 51 Menú Congreso.
A continuación se realizará una descripción de los objetos y los motivos por los
que se han creado. En el caso del menú “Comunicación y promoción” como el mismo
del módulo propio Geotermia está basado en este ya no se incluyen las imágenes.
Ficha.
Sirve para tener la ficha técnica del congreso. Aunque los campos cambian
como se puede apreciar, el diseño está basado en el de la de ficha del curso.
142
Figura 6. 52 Ficha del congreso.
Programa.
Aunque como puede apreciarse, en el objeto anterior ya se tiene como campo

de texto, se ha decidido crear este objeto basándolo en un Excel ya existente. La
particularidad que tiene es que su diseño solo tiene lógica en la vista lista, pues se
trata de una sucesión de acontecimientos.
Figura 6. 53 Programa.
Organizadores.
Sirve para tener recopilada la información relevante del resto de entidades que
organizan el congreso. Se ha configurado con vista kanban para facilitar la
identificación.
143
Figura 6. 54 Organizadores.
Entidades colaboradoras.
Serán las encargadas de colaborar con la promoción y difusión del congreso.

La vista kanban se convierte en imprescindible para su diferenciación.
Figura 6. 55 Entidades colaboradoras.
Patrocinadores.
El patrocinio es el convenio entre una persona, física o jurídica y otra con el fin
de que éste presente la marca o el producto que desea promover la empresa
patrocinadora. A la primera se la suele llamar patrocinador y a la segunda patrocinado.
El patrocinador suele buscar un posicionamiento concreto de los mismos asociándolo
a una actividad de cierto prestigio. Por su parte, el patrocinado recibe de la firma
patrocinadora una contraprestación, normalmente económica o en material. El diseño
es exactamente el mismo que el del objeto anterior.
Empleados.
Puesto que está instalado el módulo de recurso humanos, gráficamente se ha

insertado el menú de empleados del mismo, como es el mismo objeto, la información
está en dos sitios distintos pero sin repetirse.
Presentador.
Aquí se reflejará la información de los presentadores y moderadores de las

distintas conferencias o mesas redondas. Se ha diseñado con vista kanban.
144
Figura 6. 56 Presentador.
Ponentes.
Servirá para reflejar toda la información relativa a los ponentes. El diseño es

exactamente el mismo que el de Presentador.
Expositores.
Para la información relativa a los expositores del congreso. El diseño es exactamente

el mismo que el de Organizadores.
Participantes.
Servirá para tener la información de los asistentes al congreso, ya sean socios,

profesionales del sector o estudiantes. Se compone de dos objetos, preinscritos y
matriculados pero el diseño es exactamente el mismo.
Figura 6. 57 Participantes.
Medios.
Dentro de un congreso es fundamental la comunicación y promoción y para ello

será imprescindible ponerse en contacto con el mayor número de medios de
comunicación posible.
Contactos.
Para ello el profesional que lleve a cabo esta labor tratará de contactar
preferentemente con la misma gente dentro del mismo medio.
145
Web propia.
En el mundo actual es imprescindible disponer o bien de una página web para

el congreso o de un blog en el cual poner la información así como las direcciones de
contacto para aquellos interesados en participar. Servirá también como promoción de
los patrocinadores y colaboradores.
Para el congreso en que se ha basado esta base de datos la dirección es:
http://congresonacionaldegeotermia.wordpress.com/
Publicidad.
Aquí podrán registrarse los anuncios publicados en prensa, así como el

presupuesto para los mismos.
Noticias generadas.
Para almacenar y tener un archivo con las noticias que va generando el congreso.
Imágenes.
Como archivo de las fotografías que se realicen durante todo el congreso, que
podrán utilizarse, por ejemplo, para promocionar el siguiente.
6.4. Desarrollo de módulos.
La explicación de cómo se desarrollan los módulos de OpenERP aparece

reflejada a lo largo del apartado “4. Estudio de OpenERP” de este mismo proyecto,
este se explicará cómo se ha llevado a cabo este proceso para la implantación y se
entrará más en detalle en algunos aspectos. La programación al completo de los
módulos propios para este proyecto se muestra reflejada en el ANEXO III.
Una vez se tiene un diseño preliminar de los módulos y objetos se procede a su

programación. Esta fase va íntimamente ligada a la anterior, y aunque se desarrolla
obviamente después de diseñar, también habrá que tener presente lo que se puede
desarrollar para ver como diseñarlo.
Tanto para el diseño como para el desarrollo, lo que se ha hecho es acudir al

objeto básico de OpenERP que más se aproxime a lo que se quiere hacer, abrir su
archivo dentro de la carpeta “addons” y al tratarse de software de código abierto poder
acceder a su código y tratar de copiar la estructura deseada. Pero esto no resulta tan
sencillo, la programación de OpenERP está hecha por profesionales y alcanzar ese
nivel supera en mucho los objetivos de este proyecto. Aún así esta búsqueda y
comparación ha servido para no alcanzar un nivel como para poder reescribir el
archivo y manipularlo, pero si para comprender lo que estaba hecho y con un lenguaje
más simple programar cosas similares. Por poner un símil lingüístico sería como decir
que uno tiene un nivel medio para hablar inglés y sin embargo alto en comprensión
porque lo que no sabe lo entiende por el contexto.
146
Por tanto, para llevar a cabo el proceso de desarrollo, en primer lugar se hace
uno preliminar con los conocimientos que se tienen y se va investigando, sino en
OpenERP directamente, en la bibliografía, hasta alcanzar lo que se quiere obtener. Un
ejemplo de esto ha sido cuando teniendo los módulos programados con las vistas lista
y formulario se ha querido utilizar también la kanban. Para ello además de tener que
aprender cómo realizar esa estructura fue necesario previamente indagar en como
poder insertar una imagen. Para darse una idea de esta evolución basta con comparar
el objeto “Lista de correos” (Figura 6.11) con los más complejos “Grupos de trabajo”
(Figura 6.14) o “Ficha del curso” (Figura 6.41).
Tal y como se ha visto en la fase de diseño muchos de los objetos tienen el

mismo, sin embargo en OpenERP no puede haber dos objetos iguales, al menos no
en cuanto al nombre, cada uno de ellos es una entidad propia. Para llevar a cabo este
Proyecto Fin de Carrera se han creado los 7 módulos que se han descrito,
conteniendo un total de 107 objetos compuestos por 8857 líneas de programación,
2545 en python y 6312 en xml.
Cuando se desarrolla un módulo y se instala como se ha visto, lo normal no es

que funcione perfectamente a la primera, comúnmente dará errores y habrá que
revisar una y otra vez el código para comprobar donde está el error. Esto es un factor
relevante, especialmente en cuanto al tiempo, puesto que en muchas ocasiones
encontrar un error por mínimo que sea puede llevar más tiempo que desarrollar el
propio módulo.
Hay multitud de tipos de errores que se pueden cometer, tantos que sería
prácticamente imposible describirlos todos. En muchas ocasiones los errores son
siempre los mismos y revisando se encuentran fácil. A continuación se detalla una lista
con los errores más comunes:
- Error de formato. Un archivo xml además de poder abrirse con el “Notepad

++” si su estructura es correcta también puede abrirse con un explorador, el error
comúnmente es poner espacios donde no debería haberlos.
- En el xml también es común no cerrar lo que se abre, por ejemplo escribir así
la estructura <group>… <group> cuando debería estarlo así <group>… </group>.
Para tener una idea del cuidado que hay que tener basta con tener en cuenta que el
archivo que menos líneas de xml tiene es curso.xlm con 739 y con un solo error de
este tipo ya no funciona.
Sobre estos dos errores, en las vistas hay que decir que cuando se instala el
módulo, OpenERP abre una ventana en la que generalmente aparece la línea en que
está el error, el problema surge cuando hay más de uno-
-Que el archivo xml no se corresponda con el python es sin duda alguna el más
problemático de todos y en la mayoría de los casos es siempre por lo mismo, no haber
escrito correctamente el nombre de los objetos o los campos. Como se ha dicho, no es
obligatorio que en las vistas aparezca todo lo de los objetos, pero lo que si debe estar
correcto. Por ejemplo escribir “direccion” en un sitio y “direcion” en otro, siempre es
más fácil pensar que el error es más complejo y no tan sencillo. A veces cuando se
147
copian los objetos porque el diseño es igual y basta con cambiar solo el nombre es
muy común que alguno siempre se olvide.
-Tal y como se ha visto el nombre de un objeto no es el mismo el que se

programa que el que se lee. Cuando se programa un objeto no permite tener acento
gráfico ni siquiera en la descripción, algo que si sucede con el nombre de los menús y
de los módulos. Este alumno cree que posiblemente ello de deba a problemas con la
traducción, e insertando el archivo con traducción o haciéndolo gráficamente el
problema se soluciona.
- Escribir correctamente la sintaxis de los campos. Esto sucede sobre todo

cuando se están probando campos nuevos. El problema surge realmente con que
quizás uno piense que el error está en la parte nueva y probablemente sea así, pero
en muchas ocasiones la realidad es que se trata de uno de los errores anteriores.
Pero no en todos los casos los errores son tan de base que el módulo no
puede instalarse, en muchas ocasiones se trata simplemente de errores en las vistas
como en una acción que no se ha puesto, algún objeto repetido y sencillamente o una
vista kanban que está mal y lo que ocurre es que en esos casos concretos no
funcionan pero si el resto del módulo.
En muchas ocasiones lo que suele suceder y esto no sería estrictamente un

error es que los campos no se muestran donde se quiere. Eso es debido a los
elementos de diseño, que habrá que combinarlos de la forma adecuada. Esto se hace
probando, cambiando e instalando una y otra vez el módulo hasta llegar a obtener el
resultado deseado.
Para llevar a cabo la fase de desarrollo de los módulos ha sido muy importante
la utilización de máquinas virtuales. Ello ha permitido efectuar todas esas pruebas
que se mencionaban en los ordenadores de la asociación sin ningún tipo de riesgo
para los mismos. De hecho algunas de las máquinas se han visto dañadas por tratar
de descargar algunos módulos de OpenERP no de la página oficial sino de otras
fuentes, que aunque en ocasiones resultan muy útiles, en otras son más que
perjudiciales.
Además también ha permitido crear varias bases de datos, mostrar el resultado

a los usuarios a ver si era el satisfactorio y sobre todo también la posibilidad de poder
trasladarla y no tener que realizar todo el trabajo en la oficina del Clúster.
6.5. Implementación.
El paso siguiente después de realizar la investigación y el diseño de las

características del ERP es proceder a la implementación de la tecnología. Se trata de
algo mucho más complejo que en la implementación de cualquier otro tipo de software,
ya que los resultados del mismo no se obtienen al momento y el proceso de
adaptación suele ser lento. Por ello, en esta fase, se vuelve muy importante el proceso
de comunicación y formación para que toda la organización se conciencie de la
importancia de su uso y de la responsabilidad de todos en su utilización.
148
Se trata por tanto del proceso más largo que habrá que llevar a cabo en varias
etapas como son la de instalación del software, la formación del personal, la migración
de datos a la nueva tecnología y un periodo de pruebas.
6.5.1 Instalación del software.
Una vez se tienen diseñadas las bases de datos, desarrollados los módulos
propios correspondientes y se considera el momento adecuado se procede a la
instalación de OpenERP. Para ello es fundamental tener definida la estructura de los
equipos y las conexiones de red, se ha empleado una arquitectura cliente-servidor tal y
como se explica en el apartado “2.4.2. Perspectiva técnica” de este mismo proyecto.
Se ha aprovechado la existente que se utilizaba para la impresora y se ha mejorado
mediante carpetas compartidas, siendo el resultado que muestra el router el que se
puede ver en la siguiente figura:
Figura 6. 58 Arquitectura cliente-servidor ACLUXEGA.
En este caso no se ha invertido en nuevos equipos, se tienen 3 con Windows 7,

Intel Pentium CPU G850 dos de ellos con 2GB de RAM y uno con 4 que es donde se
ha realizado la instalación. Este hecho no es incompatible en absoluto con que pueda
seguir utilizando su ordenador de manera habitual, sencillamente es donde va a estar
la base de datos con toda la información.
Se procede por tanto a la instalación de OpenERP en el ordenador servidor o

tal y como aparece nombrado en la imagen anterior “computer”. Este procedimiento se
lleva a cabo tal y como se ha visto en el apartado “4.3 Instalación”.
Llegado este punto, la cuestión es cómo acceder a OpenERP desde los 3

ordenadores y al mismo tiempo y su respuesta es muy sencilla, introduciendo en el
navegador la dirección IP del servidor. Lo que se pretende es acceder al puerto 8069
de la máquina, desde la misma bastará con escribir desde cualquier navegador de
internet (explorer,Firefox, Chrome) la siguiente dirección localhost:8069. Para
acceder desde los otros lo que habrá es que introducir la IP del servidor, esta puede
verse accediendo a la configuración del router, que es la indicada en la Figura 6.58
escribiendo en el navegador 192.168.0.1 y esto puede hacerse desde cualquiera de
los ordenadores. Desde el servidor para ver su propia IP se va a incio se escribe cmd
y en la consola que se abre se escribe ipconfig y se consulta la IPtal y como se ve en
la siguiente figura:
149
Figura 6. 59 IP del servidor.
Por tanto para poder acceder a OpenERP desde el resto de los ordenadores
conectados a la red habrá que introducir en el navegador 192.168.0.6:8069 y para que
sea siempre la misma esta IP se ha hecho fija para que siempre sea esa la que hay
que introducir.
El router de un ordenador tiene dos IP la interna para la propia red y la externa.

Conociendo la externa y tal y como sucede con la interna si se pone a continuación el
nombre del puerto podría accederse a OpenERP desde internet y con todas las
posibilidades que ello conlleva. Para conocerla lo que se hace es ir a determinadas
páginas web, que al ser pública, muestran la IP externa del router al que está
conectado el equipo, de este modo en ACLUXEGA este es el resultado en la página
www.whatsmyip.com :
Figura 6. 60 IP externa ACLUXEGA.
Pero la IP externa lo es de toda la red, con lo cual los 3 ordenadores de

ACLUXEGA tienen la misma. Para que desde el exterior se pueda acceder a un
ordenador concreto y a un puerto en particular lo que habrá que hacer es abrir ese
puerto en el router. Esto se hace desde el router y su acceso es tal y como sea visto
introduciendo 192.168.0.1 en un navegador, introduciendo la clave de acceso y
cambiando la configuración.
El resultado final es que desde una red externa e introduciendo en cualquier

navegador la dirección http: 213.60.133.135:8069 y siempre y cuando el servidor esté
encendido se puede acceder al OpenERP de ACLUXEGA desde cualquier parte del
mundo, tal y como si uno se conectase a una página web. Las consecuencias de este
hecho y su relevancia son inmediatas, las posibilidades así como las posibilidades en
150
cuanto a usuarios de OpenERP se multiplican. En apartados anteriores ya se han ido

adelantando.
En la base de datos general, se podrá tener como usuarios a todos los

asociados pudiendo realizar las encuestas desde el propio programa, informándoles
también de los eventos si así se desea y permitiéndoles que vean solo lo que se
quiera, así mismo se puede dar acceso a la junta directiva al Project o a cualquier tipo
de información con los módulos propios. Del mismo modo podría compartirse
información con cada uno de los grupos de trabajo o sus miembros, agilizando la
comunicación entre ellos y la coordinación de ACLUXEGA, incluso pudiendo
contemplarse la posibilidad de crear una base de datos con su propio Project y sus
datos. Lo mismo ocurriría en la base de datos de CONGRESOS, la coordinación con
otras instituciones para su organización se vería enteramente reforzada, disminuyendo
llamadas telefónicas y facilitando el intercambio de documentos, as í como la
planificación de las tareas. En cuanto a los CURSOS se abre de este modo la
posibilidad de realizar las encuestas directamente a los alumnos y profesores y con
estos últimos la planificación y el intercambio de documentación.
Desde otro punto de vista y gracias también a la gran adaptabilidad de

OpenERP, gracias a la conexión a internet los usuarios pueden conectarse desde una
táblet o incluso desde un teléfono móvil.
Figura 6. 61 OpenERP de A CLUXEGA desde un móvil.
Siendo incluso posible crear un acceso directo desde el propio escritorio del
teléfono.
151
Figura 6. 62 Acceso directo OpenERP.
Sin embargo, este método de conexión a red externa presenta un problema y

es que esa IP es dinámica. Para que la IP externa sea fija habrá que abonar una serie
de costes, pero salvo que se reinicie el router esta no cambiará. Por ello y para facilitar
el acceso a los usuarios lo que se ha hecho es poner el enlace en la página web de
ACLUXEGA, de tal modo que periódicamente se irá revisando para que sea la
correcta. Como medida de seguridad y para tener mayor privacidad, este enlace se ha
puesto en un área privada con la cual hay que tener clave para el acceso, además de
las propias de OpenERP.
Figura 6. 63 Área privada www.acluxega.com.
152
6.5.2. Formación de los empleados.
Ante todo cambio, los componentes de una organización sienten cierto rechazo
por desconocimiento o por dificultad a la hora de adaptarlo. Resultan indiferentes los
beneficios que se puedan esperar ya que, como mínimo, siempre se generarán ciertas
dudas. Lo primordial para solventar esta barrera es desarrollar un proceso de
comunicación y formación para que todos los empleados se adapten a la nueva forma
de realizar sus tareas. Esto es lo que se conoce como gestionar la oposición interna al
cambio.
Para ello se ha llevado a cabo un plan de formación consistente en cuatro

fases, concepto de ERP, funcionamiento de OpenERP, configuración de OpenERP y
desarrollo de OpenERP.
En primer lugar los usuarios deben tener unos conocimientos básicos que
consisten en saber que es un Enterprise Resource Planing (ERP), para que sirve, que
ventajas presenta frente a otro software y de qué manera puede facilitar su labor. Para
ello también será importante en esta fase que conozcan como se va a llevar a cabo el
proceso, las cuatro fases de implantación, con el objeto de que faciliten sus
conocimientos para el diseño de los módulos. La documentación que se les ha
entregado para facilitar la formación en estos aspectos ha sido el segundo apartado de
este proyecto “2.ERP”. Esta fase hay que llevarla a cabo incluso antes del análisis
aunque manteniéndola de forma continua para solucionar las dudas que vayan
surgiendo.
Una vez OpenERP está instalado en la red, con las bases de datos y módulos
personalizados creados lo que hay es que enseñarles a los usuarios como funciona
OpenERP. En cuanto a los módulos creados, como han colaborado al hacerlo ya
están al tanto, donde habrá que llevar a cabo sendas explicaciones será a la hora de
explicarles el funcionamiento de módulos como el Project, Contabilidad o Encuestas.
Para ello se han impartido clases teóricas de varias horas de duración, aprovechando
los periodos de menor carga de trabajo, como por ejemplo semana santa y que el que
las imparte es parte del propio personal con lo que está a disposición en cualquier
momento para en una hora suelta das las explicaciones necesarias. Esta formación se
ha llevado a cabo también de forma continua durante la migración, a lo largo de varios
meses.
Cuando los usuarios disponen ya de ciertos conocimientos sobre la estructura

de OpenERP y su funcionamiento y además comprenden todas las utilidades y
facilidades que este software de gestión presenta se enseña la configuración. Esta es
una parte importante puesto que es en la que se explica cómo se configuran los
permisos, como crear bases de datos y que módulos instalar en ellas e incluso como
modificar gráficamente los módulos de OpenERP para adaptarlos a las necesidades
dependiendo de las circunstancias. La formación en este caso ha consistido en clases
teóricas apoyadas en un tutorial creado y personalizado para ACLUXEGA para tal
efecto, que se adjunta en el ANEXO IV.
La última fase de formación y que se situaría cerca de la puesta en marcha o

una vez iniciada esta sería la de desarrollo. Se trata de que los usuarios puedan llevar
a cabo el mantenimiento por sí mismos de los módulos personalizados de OpenERP,
que puedan programarlos y modificarlos incorporando nuevos campos, objetos e
incluso módulos. Dada la complejidad y tiempo que esto supone no se han impartido
clases teóricas en un principio, se les ha facilitado el apartado de este proyecto
153
“4.Estudio de OpenERP” en el que como se ha visto con detalle se explica cómo llevar
a cabo esta labor.
Para llevar a cabo la formación ha sido imprescindible nuevamente el empleo

de la virtualización en prácticamente todas las fases. Así se pudieron crear proyectos
ficticios, usuarios que no existen o facturas impagadas, así como bases de datos de
todo tipo. Gracias a esta herramienta los usuarios pueden experimentar todo lo que
quien sin temor a equivocarse y sin que afecte a las bases de datos que se utilizarán
realmente. Para ello en el ordenador becario que está realizando la implantación ha
instalado la máquina virtual con reenvío de puertos de tal manera que pudiese acceder
directamente desde el puerto 8169 de su propio ordenador. De este modo los otros
dos componentes, incluyendo el de la directora (servidor), pueden acceder
introduciendo la IP seguida del puerto, convirtiéndose la máquina virtual en este caso
en el servidor de pruebas.
6.5.3. Migración de datos.
La migración de todos los datos de la asociación es una labor compleja y lenta,

posiblemente, no la que lleve más pero sí la que se extienda más tiempo en todo el
proceso. Mezclada con ella va como se ha visto parte de la formación de los usuarios.
Para llevar a cabo este proceso hay que tener claro que OpenERP se ha
adaptado a ACLUXEGA, pero esta también debe adaptarse a las bases de datos
creadas. El migrar los datos del disco duro y Dropbox es una labor progresiva que
debe empezarse por las partes más sencillas.
Como se ha visto, se pueden importar directamente los archivos Excel

convirtiéndolos a CSV, y además los módulos propios son los más sencillos y los más
conocidos por los usuarios, por lo que será por estos por los que se empiece. En
algunos casos la importación será directa, pero en otros en los que precisamente se
han creado objetos porque la información estaba dispersa habrá que introducir los
manualmente. Para poner documentos en pdf y Word en este caso pueden emplearse
los foros del módulo Mensajes, para complementar el contenido de los propios. Será
en este paso donde se prueben realmente los módulos creados, si los campos son
correctos, si falta algo, si compensa una vista kanban o sobra, es donde se realizan
los últimos retoques.
Posteriormente y dado que la dirección general solo consta de 3 miembros se

vuelcan además de los datos de la empresa los de recursos humanos, la información
propia de cada uno de ellos así como de los anteriores que han pasado.
El siguiente paso es introducir los datos en el Project y dado que no se estaba

utilizando el programa Microsoft Project algunos ni tan siquiera están digitalizados, y el
resto de los datos están dispersos en carpetas. Será en este momento en el que más
papel se sustituya precisamente con planificación de proyectos y la toma de notas.
El último y más complejo de todos es el de contabilidad ya que además se

relaciona con el de recursos humanos en cuanto al plano de gastos personales y la
migración debe hacerla una sola persona que es la que tiene los datos en este
sentido, que es la directora.
Ya que hay más de una base lo hay que hacer es el traslado de datos de la
manera más sencilla y ordenada posible, empezando por ejemplo con la contabilidad
de los cursos y no con la general, con el objetivo de irse familiarizando con el módulo.
154
6.5.4. Periodo de pruebas.
Se establece un periodo de pruebas de tres meses antes de considerar

definitivamente el arranque. Se trata de la parte de mayor duración pero que permitirá
ver como se realiza al menos una vez todas las tareas con OpenERP. Sirve para
corregir pequeños errores u olvidos, además una vez que los usuarios conocen y
trabajan con el programa hacen propuestas de mejora, que pueden diseñarse y
desarrollarse durante este periodo.
Se trata de un periodo muy importante ya que hay que tener en cuenta que, a
partir de la puesta en marcha, OpenERP será una parte fundamental en la
organización y gestión de la asociación, con lo que es fundamental que todo funcione
correctamente y que los usuarios se encuentren cómodos.
6.6. Puesta en marcha.
Después de cumplir los pasos anteriores la asociación debe comenzar a utilizar

la nueva tecnología que ya ha ido incorporando poco a poco y progresivamente
mediante la implantación, proceso de 6 meses de duración.
La puesta en marcha del OpenERP de ACLUXEGA se va a considerar el 1 de

agosto de 2014, fecha en que termina el convenio de esta con la Universidad de Vigo
para llevar a cabo las prácticas y el PFC.
155
156
7.ANÁLISIS DE
COSTES DE OPENERP
EN ACLUXEGA.
7. ANÁLISIS DE COSTES DE OPENERP EN ACLUXEGA
7. ANÁLISIS DE COSTES DE OPENERP EN ACLUXEGA.
A lo largo de los apartados anteriores de este PFC se ha hecho una exposición

detallada de los sistemas de planificación de recursos empresariales ERP a nivel
general y de OpenERP a nivel particular. En este apartado se tratará el análisis de los
costes que ha supuesto para la Asociación Clúster da Xeotermia Galega del mismo.
En primer lugar hay que tener presente la clasificación de producto que se ha

instalado. Atendiendo a la clasificación descrita en el apartado “2.8.1 Adaptabilidad”
OpenERP se trata de una solución estándar o modular. Desde la “2.8.2 Propiedad de
la licencia” está considerado como software libre.
Desde el punto de vista de los costes y tal y como se detalla en el apartado

“2.9.3 Aplicación: Niveles de costes” entra dentro de la categoría de Nivel 1 enfocado a
pequeña y mediana empresa que sitúa el rango de inversión entre 0 y 500 Euros. Es
en este punto donde se debe tener en cuenta la diferencia entre costes y gastos. Para
ACLUXEGA el gasto de haber llevado a cabo la implantación de este proyecto, dado
que lo ha hecho directamente con los miembros de su dirección general ha sido 0 €.
Sin embargo, precisamente el hecho de haber sido llevado a cabo por los
recursos de la empresa supone un coste, un coste en tiempo, en el cual podrían haber
estado llevando a cabo otras labores, es lo que se conoce como costes de oportunidad
y será sobre ellos sobre los que se lleve a cabo el análisis mediante una comparación
con los costes que habría supuesto contar con los servicios de un ente externo, como
una consultoría para la implantación de OpenERP.
Para ello se profundizará más en los conceptos descritos en el apartado “2.9

Costes de un ERP”. Para hacerse una idea, a media que se vallan sucediendo los
datos particulares de la influencia de estos en el resultado global, a continuación se
describe en la siguiente tabla de manera aproximada el desglose del coste total de
una implantación.
Costes de implantación de un ERP

Concepto Coste medio Rango
Consultoría 30% 20%-60%
Hardware/infraestructura 25% 0%-50%
Equipo de implementación 15% 5%-20%
Entrenamiento y formación 15% 10%-20%
Software 15% 10%-20%
Tabla 7. 1 Costes de implantación de un ERP.
159
Los costes principales de un hacen referencia a la infraestructura técnica

(hardware, red, comunicaciones), al coste del software (licencias, módulos
personalizados) y a los de servicios de consultoría, desarrollo, implantación y
mantenimiento. La distribución de costes general se describe en la siguiente gráfica:
10%
Infraestructura técnica
30%
Sofware
60%
Servicios
Gráfico 7. 1 Distribución de costes.
Los costes ocultos, tal y como se ha visto, tienen que ver con la dedicación
necesaria por parte de los recursos de la compañía. En este caso como precisamente
la implantación es llevada a cabo por uno de sus miembros, se convierten en la
mayoría de los costes a considerar formando parte, por tanto, de los principales.
En los puntos siguientes se detallarán los costes en función del tiempo, habrá
que tener en cuenta que toda esta labor se ha llevado a cabo sin desatender el trabajo
diario de la asociación, incluso por parte del alumno que además de implantar
OpenERP cumplirá con sus funciones de becario de universidad.
La duración de la jornada diaria de la directora y del otro becario (Becario

PARA) es de 8 horas, sin embargo, la del alumno es de 4 en la oficina,
independientemente de que dedique más tiempo por su cuenta por tratarse de su
PFC, por tanto será a esta media jornada a la que estén referidos los porcentajes de
tiempo de coste que se mencionen.
7.1 Infraestructura técnica.
Para la infraestructura técnica habrá que evaluar los costes además de en

personal en cuanto a hardware, red y comunicaciones.
En cuanto a hardware se dispone de 3 ordenadores, no siendo necesaria la

adquisición de otro que funcione como servidor puesto que se empleará uno de ellos
con la doble función de cliente y servidor al ser instalado en el OpenERP junto con la
base de datos PosgreSQL.
Para minimizar los tiempos de configuración de la red esta se ha llevado a

cabo en una tarde fuera del turno de trabajo del Becario PRA, por tanto el tiempo
empleado puede considerarse como una jornada completa para el Becario
universidad y de forma indirecta el 25% del tiempo que la directora se ha visto
afectada de poder utilizar su equipo.
160
Gráfico 7. 2 Tiempo red.
En cuanto a los costes relativos a las comunicaciones, en este caso habría que
tener en cuenta la factura de internet y así como la de la luz y el alquiler de las
instalaciones, pero como no ha sido necesario estar más horas de las habituales en un
día normal, pueden repercutirse sobre el tiempo dedicado a la instalación.
7.2 Software.
El coste del software va ligado al proveedor del servicio. Por tanto y ya que lo
que se va a instalar es OpenERP versión 7 que es software libre, no tiene coste de
licencias. Además también se instalará el software de virtualización Oracle VM
VirtualBox y el Notepad ++ para llevar a cabo del desarrollo de módulos, ambos
descargables legalmente de forma totalmente gratuita.
7.3 Servicios de consultoría, implantación y mantenimiento.
La teoría dice que un proyecto de implantación es llevado a cabo por un equipo

de trabajo formado por recursos de la compañía y recursos del proveedor de servicios.
En este caso y por tratase de un PFC en el cual el alumno además forma parte de la
institución, se asumen ambos papeles.
En el apartado 4 de este proyecto se ha explicado el funcionamiento,

configuración y desarrollo de OpenERP, en el 5 la labor llevada a cabo con su
organización interna de la Asociación Clúster da Xeotermia Galega y en el 6 como se
ha llevado a cabo la implantación del software en la dirección general de la misma.
Para ello ha sido necesario seguir una metodología mediante la cual se ha

dividido el proceso en 5 etapas, análisis, diseño, desarrollo, implementación y puesta
en marcha. A continuación se tratará de estimar y aproximar en la medida de lo
posible el tiempo que ha llevado cada una de ellas a los distintos miembros de la
oficina, teniendo en cuenta que en ningún momento se han realizado horas extras por
parte de ninguno y tratando de minimizar el impacto en las tareas habituales para los
mismos.
En cuanto a los costes proporcionales propios de una oficina imputables a este

proyecto como son el alquiler, la factura del teléfono e internet, la limpieza o la
papelería, se va a considerar que se diluyen en el transcursos de los meses. Por
ejemplo, el dedicar 1 hora de internet o 2 va a suponer el mismo coste, dado que ya se
161
iba a producir en el funcionamiento normal, o en cuanto a la luz también, puesto que

gracias a la virtualización, no se ha necesitado ningún equipo a mayores.
7.3.1. Análisis.
Como se ha visto la fase de análisis ha sido la primera y realmente se ha

extendido a lo largo de todo el proyecto, para llevar a cabo aquellas modificaciones o
ampliaciones que se considerasen necesarias, especialmente durante la parte de
implementación.
Para el que realiza este PFC ha sido necesario emplear todo su tiempo en este
proceso, pero dado que cumple la doble función de implantador/becario y también ello
sería parte de esa función, se va a considerar la mitad del tiempo. Lo mismo sucede
con la dedicación de la directora y el otro becario a este, por una parte al explicarle el
funcionamiento de la asociación le ayudará además de al análisis a desarrollar mejor
sus tareas.
Para simplificar los cálculos se va a imputar el tiempo de una semana, aunque

como se ha podido comprobar ha llevado más, por lo que se repercutirá un mayor
porcentaje de tiempo en esta que realmente sería en las siguientes.
Gráfico 7. 3 Tiempo análisis.
7.3.2. Diseño y desarrollo .
Para los costes se tienen en cuenta las dos fases porque tal y como se ha
explicado han ido alterándose una con la otra desarrollándose lo que se diseña. Sin
embargo la parte de desarrollo de módulos propios solo afecta al tiempo del becario de
universidad, mientras que los otros dos integrantes colaboran con sus conocimientos y
opiniones al diseño. El tiempo que va a considerarse como referencia estimada de
duración en esta fase serán 6 semanas, repercutiendo en los porcentajes de tiempo
una mayor cantidad correspondiente a las modificaciones surgidas durante la parte de
implementación.
162
Gráfico 7. 4 Tiempo diseño y desarrollo.
7.3.3. Implementación.
Es la fase que más tiempo lleva de todas, si se ha considerado para el proceso

de implantación de OpenERP aproximadamente 6 meses desde el análisis hasta la
puesta en marcha, esta etapa abarcaría algo más de 4.
Posiblemente podría haberse llevado a cabo en menos tiempo, pero puesto

que se lleva a cabo por el propio personal puede realizarse de manera progresiva en
los momentos en que haya menos trabajo que hacer, aprovechando puentes y
periodos habitualmente vacacionales en las empresas en que la asociación tiene
menos trabajo que hacer.
Este hecho supone una de las mayores ventajas que tiene el implantar un
software como este, como no hay que abonar licencias, no importa que la implantación
dure 6 meses, un año o los que sean, disminuyendo la dedicación necesaria por parte
de los miembros de la asociación y por tanto los costes de oportunidad.
7.3.3.1 Instalación del software.
Esta es una etapa importante aunque en realidad de duración bastante corta

puesto que instalar OpenERP y descargar las bases de datos a penas supone un par
de horas. Tal y como se ha visto se ha instalado en el ordenador de la directora, y en
él hay que instalar los módulos propios, el resto pueden instalarse desde otro de los
ordenadores de la red. El tiempo como referencia en este caso es, por tanto un día.
Gráfico 7. 5 Tiempo instalación.
163
7.3.3.2 Formación del personal.
Es una de las etapas más importantes de la implantación de un ERP y

habitualmente las consultorías la llevan a cabo de manera presencial u online. Como
se ha visto hay 4 etapas de formación. La formación la llevará a cabo en este caso el
alumno/becario con la ventaja de poder realizar una formación continua e instantánea,
facilitando el contacto y la contestación de dudas a medida que vayan surgiendo.
En la primera etapa en la cual se aportan los conocimientos generales acerca

de lo que es un ERP el tiempo ha sido insignificante, además al aportar como
documentación el apartado 2 de este proyecto, pueden ir leyéndoselo en cualquier
momento, sin perjuicio de tiempo en la actividad de sus trabajos.
En cuanto a la formación de utilización de OpenERP se ha impartido una clase

de dos horas, aprovechando la baja de actividad durante la Semana Santa. Del mismo
modo para la parte de configuración el puente de mayo con otra jornada de dos horas.
Sin embargo para esta última tal y como se ha indicado se ha elaborado un tutorial
personalizado que se ha realizado en la asociación puesto que contiene capturas de
pantalla de los sistemas, repercutiendo en tiempo en el formador. Además también ha
habido que preparar la máquina virtual para llevar a cabo este proceso.
Para la formación en cuanto a desarrollo de módulos para llevar a cabo el

mantenimiento, al facilitarse el apartado 4 de este proyecto, no repercute en el tiempo.
Podría repercutir el querer realizar un módulo, pero eso ya sería parte de la fase de
mantenimiento, que sería después de la puesta en marcha, por tanto fuera del alcance
de este proyecto.
Tomando como referencia de tiempo una semana, el tiempo proporcional de

formación quedaría tal que así:
Gráfico 7. 6 Tiempos de formación.
7.3.3.3 Migración.
Tal y como se ha descrito, el proceso de migración es un periodo complejo que

se alarga de manera notoria en el tiempo. Aún así no es que lleve tiempo introducir los
datos, hay que ir poco a poco con los datos que ya hay y hay que ir inc orporando los
que vayan surgiendo. Estrictamente, estos últimos no se pueden considerar
imputables a la migración de datos de un sistema al otro por lo que en tiempo no será
necesario tenerlo en cuenta.
164
En la migración se considera que intervienen los tres usuarios, el becario de

universidad, porque no deja de ser una etapa de copiar y pegar datos, el becario PRA
en menor medida puesto que estará dedicándose a generar la información, más que a
incorporar la antigua y la directora puesto que a ella corresponde la parte de
contabilidad, la de mayor complejidad.
El periodo que se va a considerar es de unas dos semanas aproximadamente,

para contabilizar las horas, aunque en la práctica se alargue más en el tiempo.
Gráfico 7. 7 Tiempos de migración.
7.3.3.4 Periodo de pruebas.
Para hacer los cálculos horarios de una forma que reflejasen de la mejor
manera posible la incidencia en el tiempo, se han adjudicado horas a mayores, que se
corresponderían con las de este período. Ello ha sido así porque resultaría complicado
establecer de una manera realista el tiempo en corrección de errores y mejoras.
En cuanto a lo que costes horarios se refleja podría considerarse este periodo

con un factor de corrección, que aunque dura tres meses se va a contabilizar como
uno solo, puesto que los otros dos servirán para el seguimiento y comprobación de
funcionamiento.
7.4 Resumen de costes.
En los apartados anteriores se ha hecho una estimación de los costes en

función de los porcentajes de tiempo dedicados por parte de cada uno de los
integrantes de la dirección general de ACLUXEGA. En la siguiente tabla se especifican
las fechas y las horas dedicadas por parte de cada uno en cada una de las distintas
fases, donde la columna Horas total fase se refiere a la suma de las horas que trabaja
en cada fase en base al turno del alumno (4 horas) y en la columna Horas totales
jornada completa se especifican las horas teniendo en cuenta que en realidad la
directora y el otro becario trabajan a jornada completa (8 horas).
165
Resumen horario de costes de OpenERP

Becario Plan Becario Horas dedicadas Horas total Horas totales
Fase/Puesto Directora Re-Acciona Universidad totales fase jornada completa Fechas
Infraestructura técnica 1 0 4 5 12 20 7 de Marzo
Análisis 6 3 10 19 60 100 20-24 de Enero
Diseño y desarrollo 30 18 90 138 360 600 27 Enero-7 Marzo
Instalación software 0,5 0 2 2,5 8 12 10 de Marzo
Formación 4 4 8 16 60 100 15,16 Abril-2 Mayo
Migración 10 5 10 25 120 160 17 Marzo-4 Abril
Pruebas 80 240 7 Abril-31 Julio
Puesta en marcha 1 de Agosto
Total 41,5 30 124 205,5 700 1232
Tabla 7. 2 Resumen horario de costes.
Con los resultados de esta tabla se puede establecer el porcentaje de tiempo

dedicado por cada uno a la implantación del ERP.
Directora Becario Plan Re-Acciona Becario Universidad
21%
64%
15%
Gráfico 7. 8 Porc entaje de tiempo dedicado cada uno.
En función del horario del becario de universidad (4horas/jornada) la incidencia

total en tiempo de la implantación ha sido:
Horas dedicadas totales Horas total f ase
23%
77%
Gráfico 7. 9 Incidencia en tiempo parcial.
Si se considera, en cambio el tiempo total de horas que permanecen los

miembros de la dirección general en la oficina, dos a jornada completa y uno a media
el resultado final es el siguiente:
166
Horas dedicadas totales Horas totales jornada completa
14%
86%
Gráfico 7. 10 Incidencia total en porcentaje de horas.
Si lo que se quiere es dar una cifra del coste de OpenERP en dinero bastaría
con multiplicar el número de horas dedicado por cada uno de los integrantes de la
dirección general por la proporción de salario más gastos asociados a la seguridad
social.
Sin pretender a entrar a publicar los mismos y mediante estimaciones al alza, y

teniendo en cuenta que el becario de universidad no percibe remuneración por llevar a
cabo su labor puede estimarse que la cantidad asciende aproximadamente a 650 € a
repartir en los 4 meses, incluyendo el proceso íntegro de formación.
Ese resultado no parece muy relevante si se tiene en cuenta que la persona

que más tiempo ha dedicado no percibe salario. Sin embargo, lo que se estaban
analizando aquí, tal y como se ha explicado al principio, son también los costes
ocultos. Por tanto, si una empresa externa fuese la que realizase la implantación,
estos costes habría que sumarlos a la cantidad que esta última nos presupuestase.
Aún teniendo en cuenta el más rebuscado de los casos de que se quisiese

considerar el coste, recibiendo un sueldo por llevar a cabo este PFC el alumno, y
equiparándolo al de la mismísima directora, el coste final rondaría los 2000 €. No
obstante, aún habría que considerar entonces que si el proceso lo hubiese llevado a
cabo un miembro de la asociación con conocimientos tales para obtener ese salario,
los tiempos se reducirían de manera considerable, por lo que esta cifra también lo
haría.
Por realizar una comparación y teniendo en cuenta los pocos datos que
facilitan al respecto las empresas, llevar a cabo una implantación profesional del tipo
de la de este PFC supondría entre costes de soporte y formación entorno a 6000 €
más los costes ocultos anteriormente mencionados, por tanto rondando el coste total
los 7000 €.
167
168
8. CONCLUSIONES.
8.CONCLUSIONES.
8. CONCLUSIONES.
Durante la elaboración de este proyecto se ha llevado a cabo una importante

labor de documentación que permite comprender en detalle los sistemas de
planificación de recursos empresariales (ERP).
En cuanto a OpenERP, puesto que se trata de software libre, las empresas

partner obtienen beneficios precisamente de que conocen el software y llevan a cabo
labores de consultoría para facilitar su implantación, incluyendo los cursos de
formación. No es que la extensa comunidad de OpenERP no quiera colaborar en
mejorar el programa o ayudar a los usuarios que así se lo pidan a través de sus foros
o plataformas, lo que ocurre es que estos son para profesionales, y lo que realmente
cuesta es encontrar la información más básica.
La consecuencia de esto, es que la información para empezar por uno mismo

es escasa. Por tanto en este proyecto se ha elaborado un estudio sobre el
funcionamiento de OpenERP. Además también se ha conseguido llevar a cabo
modificaciones en modo gráfico y crear módulos mediante programación. Tal y como
se han redactado los apartados de este proyecto se describen en detalle todos los
procesos de cómo llevar a cabo todas las tareas que sean realizado, desde como
programar un módulo hasta como llevar a cabo la implementación para conectar
OpenERP a internet.
La implantación en la Asociación Clúster da Xeotermia Galega ha sido un éxito.

En este momento cuentan con un sistema de planificación de recursos empresariales
que aporta una base que le permitirá crecer estructuralmente cuanto desee. Bien sea
aumentado el número de ordenadores en la propia sede o en caso de abrir nuevas a lo
largo de España. El poder acceder a su información desde cualquier punto del mundo
y desde cualquier dispositivo con conexión a internet incrementa exponencialmente las
funciones que OpenERP puede desempeñar.
Por ejemplo, desde este momento cuando realicen una encuesta a sus
usuarios no dependerán de un servidor de correo electrónico externo o de la
posibilidad de equivocarse de dirección mientras se trata con información confidencial.
Por otra parte, cuando se lleve a cabo la organización de un evento de grandes
dimensiones con otra organización, tal como un congreso, este sistema que permite
proyectar las tareas con su documentación y compartirlas en tiempo real sin depender
de llamadas de teléfono que en ocasiones no se pueden atender, o correos
electrónicos que saturen la bandeja de entrada, mejorando notablemente la
coordinación y agilizando los procesos.
Y no menos importante es la estructura de OpenERP. Se ha llevado a cabo la

creación de 7 módulos totalmente adaptados a ACLUXEGA habiendo colaborado los
usuarios, de tal manera que la migración se ha visto enormemente facilitada y además
el entorno de trabajo no es desconocido para ellos puesto quela estructura es similar a
la de sus archivos Excel o Word con los que trabajan.
Se les ha facilitado la formación tanto de manera general sobre los ERP, como
a nivel usuario, configurador y desarrollador de OpenERP de tal forma que una vez
171
8.CONCLUSIONES.
finalizado el proyecto cuentan con información suficiente como para realizar el

mantenimiento por sí mismos.
Tal y como se describía en la fase de análisis, ACLUXEGA es una asociación

compuesta por empresas, instituciones y personas individuales con un interés común
muy claro: la Geotermia, tal y como su mismo nombre indica. La energía geotérmica
es aquella que puede obtenerse mediante el aprovechamiento del calor del interior de
la tierra. Es una energía renovable que se emplea para la obtención de electricidad y
calefacción, disminuyendo la dependencia energética de los combustibles fósiles.
El fomento de esta energía lleva a cabo una labor social de protección del
medio ambiente puesto que contribuye a disminuir el CO 2 emitido a la atmósfera y con
ello minimizar el impacto del efecto invernadero. Por tanto puede considerarse que es
la sociedad la que recibe los beneficios de la labor de asociaciones como esta y en
consecuencia de este PFC.
172
9. BIBLIOGRAFÍA.
9.BIBLIOGRAFÍA
9.BIBLIOGRAFÍA.
Bibliografía Online:
http://www.monografias.com
www.adpime.com
http://www.tuerp.com
http://www.yourerpsoftware.com
http://www.technologyevaluation.com/es
http://www.vgsglobal.com/es
http://observatorioredesempresariales.wordpress.com
http://www.e-global.es
http://es.wikipedia.org
http://recursostic.educacion.es
http://es.answers.yahoo.com
http://www.expertosdecomputadoras.com
http://www.theopensourcerer.com
http://openerp-co.blogspot.com.es
http://openerpspain.com
http://www.gnu.org
http://help.openerp.com
https://doc.openerp.com
http://www.openerpsite.com
http://www.recercat.net
http://fccea.unicauca.edu.co/old/erp.htm
http://geekland.hol.es/integrar-maquina-virtual-en-una-red-local
www.whatsmyip.org
www.avanzosc.com
175
9.BIBLIOGRAFÍA
Documentación:
Elección de un ERP: Criterios y costes de implantación de un ERP- Miguel Ángel

Ortuño.
“Protocolos de actuación para la implantación de tecnologías eficientes y renovables

en la rehabilitación de edificios” eHabilita. 2012.
Memorias años 2011, 2012, 2013 de ACLUXEGA
Documentación “Curso comercio electrónico y comunity management” Grupo Femxa

2013.
176
ANEXOS.
ANEXO I
Instalar OpenERP v7 en Ubuntu
12.04 LTS
ANEXO I: Instalar OpenERP 7.0 en Ubuntu 12.04 LTS
Instalar OpenERP 7.0 en Ubuntu 12.04 LTS
Aunque podría instalarse directamente descargando el archivo de este modo no se

tendrá control sobre lo instalado y se verán restringida la flexibilidad para modificar y
customizar, por lo que se procederá a una instalación en modo manual.
Paso 1. Crear un usuario del sistema para ejecutar OpenERP.
Lo primero que haremos es crear un usuario del sistema, en Ubuntu un usuario del
sistema es diferente a un usuario normal, por lo tanto no aparecerá en las opciones de
acceso (login) cuando se arranque el sistema, ni podrá usarse en la terminal o
consola. El objetivo en este paso es tener un usuario del sistema que ejecute
OpenERP, para ello le asignamos el directorio en el que instalaremos luego OpenERP,
en este caso /opt/openerp, si no existe el directorio, este será creado
automáticamente. Si decide utilizar un directorio diferente tenga en cuenta que deberá
ajustar algunas instrucciones de esta guía para que se adapten a su propio contexto.
sudo adduser --system --home=/opt/openerp --group openerp
Paso 2. Instalar y configurar el servidor de base de datos PostgreSQL
Se instala el servidor PostgreSQL con el siguiente comando:
sudo apt-get install postgresql
Se pasa a trabajar con el usuario postgres para tener los privilegios necesarios para
configurar la base de datos:
sudo su – postgres
Se crea un nuevo usuario de la base de datos. Este será el usuario que se asignará
en la configuración de conexión a la base de datos del servidor OpenERP, tendrá
permisos para crear y borrar bases de datos. En este paso habrá que asignar una
contraseña que se necesitará más adelante:
createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt openerp

Enter password for new role: ********
Enter it again: ********
Finalmente se sale del usuario postgres:
exit
Paso3. Instalar librerías Python requeridas por el servidor OpenERP
Con el siguiente comando se instalan todas las librerías necesarias (dependencias)

para el correcto funcionamiento del servidor OpenERP:
sudo apt-get install python-dateutil python-docutils python-feedparser python-gdata \

python-jinja2 python-ldap python-libxslt1 python-lxml python-mako python-mock python-
181
openid \
python-psycopg2 python-psutil python-pybabel python-pychart python-pydot python-pyparsing
\
python-reportlab python-simplejson python-tz python-unittest2 python-vatnumber python-
vobject \
python-webdav python-werkzeug python-xlwt python-yaml python-zsi
Paso 4. Instalar el servidor OpenERP
Se utilizará wget para descargar los archivos al directorio. Hay que estar seguro de
que se trata de la última versión de la aplicación para proceder por este sistema, en
caso contrario habría que acudir a www.openerp.com y descargárselos.
wget http://nightly.openerp.com/7.0/nightly/src/openerp-7.0-
latest.tar.gz
Para instalarlo se entra al directorio que se ha creado en el Paso 1y después se

descomprime.
cd /opt/openerp
sudo tar xvf ~/openerp-7.0-latest.tar.gz
Si la carpeta queda con un nombre como openerp-7.0-20130117-134423 se le cambia

a server de tal manera que la ruta del servidor quede así: /opt/openerp/server/.
Se asignan permisos para el directorio, al usuario y grupo creados en el Paso 1:
sudo chown -R openerp: *
sudo cp -a openerp-7.0 server
Paso 5: Configurar el servidor OpenERP
Copiamos el archivo openerp-server.conf que se encuentra en

/opt/openerp/server/install a la carpeta /etc/ y le asignamos los permisos adecuados:
sudo cp /opt/openerp/server/install/openerp-server.conf /etc/

sudo chown openerp: /etc/openerp-server.conf
sudo chmod 640 /etc/openerp-server.conf
Las instrucciones anteriores asignan la propiedad del archivo con permisos de

escritura al grupo y usuario openerp, y con permisos de solo lectura a los usuarios
openerp y root.
Se modifica el archivo openerp-server.conf para suministrarle la contraseña de la base

de datos:
sudo nano /etc/openerp-server.conf
182
En la línea db_password = False cambiamos False por la contraseña que se ha

elegido en el Paso 2.
Se sdiciona una línea en el archivo openerp-server.conf para indicarle a OpenERP

donde escribir el archivo del log:
logfile = /var/log/openerp/openerp-server.log
La configuración está lista, es hora de probar si todo anda bien:
sudo su - openerp -s /bin/bash

/opt/openerp/server/openerp-server
El resultado de la anterior instrucción es el despliegue de varias líneas en la consola

como las siguientes:
2013-03-30 23:15:07,282 8753 INFO ? openerp: OpenERP version 7.0-20130117-134423
2013-03-30 23:15:07,283 8753 INFO ? openerp: addons paths: /opt/openerp/70/openerp/addons
2013-03-30 23:15:07,283 8753 INFO ? openerp: database hostname: localhost
2013-03-30 23:15:07,283 8753 INFO ? openerp: database port: 5432
2013-03-30 23:15:07,283 8753 INFO ? openerp: database user: openerp
2013-03-30 23:15:16,432 8753 INFO ? openerp.service.netrpc_server: starting NET-RPC

service on 0.0.0.0:8270
2013-03-30 23:15:16,435 8753 INFO ? openerp: OpenERP server is running, waiting for
connections...
2013-03-30 23:15:16,447 8753 INFO ? openerp.service.wsgi_server: HTTP service (werkzeug)

running on 0.0.0.0:8269
Para detener la ejecución del servidor OpenERP presionamos simultáneamente las

teclas CTRL y C.
Para salir del usuario openerp se escribe exit.
Paso 6: Lanzar OpenERP al arranque del sistema
Se hará que OpenERP sea lanzado como un servicio de Ubuntu 12.04, es decir que
se inicie y detenga automáticamente cuando se arranque o apague el sistema.
Para ello se crea un archivo con nombre openerp-server y se ubica en el

directorio /etc/init.d/, se edita el archivo:
#!/bin/sh
### BEGIN INIT INFO
183
# Provides: openerp-server
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Should-Start: $network
# Should-Stop: $network
# Default-Start: 2345
# Default-Stop: 016
# Short-Description: Enterprise Resource Management software
# Description: Open ERP is a complete ERP and CRM software.
### END INIT INFO
PATH=/bin:/sbin:/usr/bin
DAEMON=/opt/openerp/server/openerp-server
NAME=openerp-server
DESC=openerp-server
# Specify the user name (Default: openerp).
USER=openerp
# Specify an alternate config file (Default: /etc/openerp-server.conf).
CONFIGFILE="/etc/openerp-server.conf"
# pidfile
PIDFILE=/var/run/$NAME.pid
# Additional options that are passed to the Daemon.
DAEMON_OPTS="-c $CONFIGFILE"
[ -x $DAEMON ] || exit 0
184
[ -f $CONFIGFILE ] || exit 0
checkpid() {
[ -f $PIDFILE ] || return 1
pid=`cat $PIDFILE`
[ -d /proc/$pid ] && return 0
return 1
case "${1}" in
start)
echo -n "Starting ${DESC}: "
start-stop-daemon --start --quiet --pidfile ${PIDFILE} \
--chuid ${USER} --background --make-pidfile \
--exec ${DAEMON} -- ${DAEMON_OPTS}
echo "${NAME}."
;;
stop)
echo -n "Stopping ${DESC}: "
start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
--oknodo
echo "${NAME}."
;;
185
restart|force-reload)
echo -n "Restarting ${DESC}: "
start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
--oknodo
sleep 1
start-stop-daemon --start --quiet --pidfile ${PIDFILE} \
--chuid ${USER} --background --make-pidfile \
--exec ${DAEMON} -- ${DAEMON_OPTS}
echo "${NAME}."
;;
*)
N=/etc/init.d/${NAME}
echo "Usage: ${NAME} {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
Se asigna el archivo al usuario root y se hace ejecutable:
sudo chmod 755 /etc/init.d/openerp-server

sudo chown root: /etc/init.d/openerp-server
Se crea el directorio con los permisos correspondientes para el archivo log de acuerdo
a la configuración realizada en el Paso 6:
186
sudo mkdir /var/log/openerp

sudo chown openerp:root /var/log/openerp
Finalmente sea automatiza el lanzamiento de OpenERP con el arranque del sistema:
sudo update-rc.d openerp-server defaults
Paso 7: Probar el servidor OpenERP
Se inicia el servidor OpenERP:
sudo /etc/init.d/openerp-server start
Ahora se abre un navegador y en la barra de direcciones se escribe:
http://localhost:8069
Para detener el servidor:
sudo /etc/init.d/openerp-server stop
Paso 8: Automatizar encendido y apagado de OpenERP
Si todo funciona correctamente el paso final es hacer el script de inicio y parada

automática con el servidor Ubuntu. Para hacerlo, de este modo:
sudo update-rc.d openerp-server defaults
You can now try rebooting you server if you like. OpenERP should be running
by the time you log back in.
Ahora se puede probar a reiniciar el servidor. OpenERP deberá estar en ejecución

para cuando vuelva a entrar.
Si el tipo ps aux | grep openerp se debería ver una línea similar a esta:
openerp 1491 0.1 10.6 207132 53596 ? Sl 22:23 0:02 python /opt/openerp/server/openerp-server
-c /etc/openerp-server.conf
Que muestra que el servidor está funcionando.
187
188
ANEXO II
Guía descriptiva de módulos básicos
Índice
Introducción
1 .Mensajería
2. Ventas
3. Terminal punto de venta
4. Proyecto (Project)
5. Contabilidad
6. Compras (Purchases)
7. Almacén
8. Fabricación (Manufacturing)
9. Recursos humanos
10. Comidas
11. Flota
12. Eventos
13. Encuestas (Tools)
14 .Informes
15. Configuración
Configuración: características técnicas
Botón de la derecha:Usuario
Inicio: Crear distintas bases de datos

ANEXO II: Guía descriptiva de módulos básicos de OpenERP
Introducción
La presente guía descriptiva se elabora con el objeto de dar a conocer los

módulos básicos del programa OpenERP con el fin de tener un conocimiento previo
de los mismos, además servirá para ayudar a decidir cuáles de ellos se adaptan mejor
a las necesidades de la empresa para proceder a su instalación.
Los módulos descargables de OpenERP no aparecen como tal, sino que se

establecen repartidos en aplicaciones las cuales van completando un mismo módulo o
varios de ellos. El objetivo es no instalar más de lo necesario para poder simplificar al
máximo la organización de la información.
A continuación se establecen las definiciones básicas para poder entender esta

guía y el propio sistema de gestión empresarial.
Objeto: Son los que forman la estructura principal de OpenERP. Modelos en

los cuales se establecen los campos con sus diferentes tipos. Una entidad propia que
como conjunto forma parte de un módulo o una aplicación.

introducir datos en la base de datos. Hay dos tipos de campos, los básicos y los
relacionales, los básicos solos sirven para introducir datos básicos y los relacionales
permiten establecer relaciones entre los objetos. Los campos estarán definidos por un
nombre “real” y por uno “descriptivo” que será el que realmente se visualice, en
ocasiones ni siquiera aparece el descriptivo por tratarse de un campo de texto, por
ejemplo en el interior del cual se inserta un “placeholder” es decir una descripción que
desaparece en cuanto se empieza a escribir por encima. Esta distinción es importante
ya que a la hora de importar/exportar los datos será el nombre “real” el que aparezca.

mejor.
dibujado cada uno. Hay 6 tipos de vista distintos que se irán visualizando a lo largo de
la guía: Kanban, Lista, Formulario, Calendario, Gantt y Gráfico . No es necesario que
un objeto las tenga todas, pero al menos si la vista Lista o arbol, que será de la que se
puedan importar los datos y la vista Formulario que será en la que se cubran
manualmente los datos.

194
1. Mensajería
Este módulo, al igual que el de informes aparece automáticamente al

instalar cualquier aplicación. Solo que solo lo hace en su forma más
básica incluyendo la parte de mensajería y de mis grupos. Cuando se
instala la aplicación CRM se inserta el objeto calendario que permite la
planificación de reuniones. También se instala con el parte del módulo
Ventas en el cual se incluyen los objetos de clientes, iniciativas,
oportunidades, así como los de llamadas telefónicas y la configuración
de los equipos de ventas. Automáticamente quedan instaladas así
mismo las aplicaciones Social Network y Calendar. Para el objeto
Contactos habrá que instalar la aplicación Adress book. Para el objeto
Notas habrá que instalar la aplicación Notes.
1.1 Mensajería
- La bandeja de entrada permite además de leer los menajes recibidos

redactarlos. Se pueden enviar mensajes tanto a los usuarios de Open
ERP individualmente o por grupos. Se podrá así mismo adjuntar en
ellos archivos en diversos formatos, pdf, docx,xml,pptx,etc. Cada vez
que se envía un correo electrónico queda automáticamente guardado
el contacto. También aparecerán notificaciones de los proyectos creados.
- En Para mi aparecen los mensajes recibidos.
-En Por realizar aparecen aquellos mensajes así marcados.
-En archivados aparecen los mensajes enviados y toda aquello que se realice en la compañía
facturas, presupuestos, proyectos, etc.
1.2 Organizador
Sirve para organizar las reuniones. Se dispone de vistas Calendario y Gantt para facilitar la
visualización. Estos objetos estarán en constante interacción con los de otros módulos,
especialmente en lo que a campos relacionales se refiere, a la hora de bucar a un cliente, a un
proveedor, o a un empleado de la propia empresa.
195
1.2.1 Calendario
En calendario hay 4 posibles vistas (parte superior derecha de la pantalla).
En la vista calendario pulsando 2 veces se crea una reunión.
196
Si en las vistas lista, formulario o Gantt se da a crear aparece lo mismo. El resto de funciones
son para modificar las reuniones. En la pestaña opciones puede ponerse si la reunión es
pública o privada y en la de invitaciones a un contacto o puede crearse.
1.2.2. Contactos
Esta herramienta permite gestionar los contactos, crear nuevos o a partir de los ya existentes a
partir de los correos electrónicos. Por defecto aparecen el administrador, tu compañía y un
usuario de la plantilla. Mediante los cursores de la parte superior derecha puede pasarse de un
usuario a otro. En la parte de reuniones nos remite al calendario. La de llamadas permite ver el
registro de estas. El apartado de oportunidades es el mismo que el del apartado 2.1.3
Oportunidades en Ventas. Interactúa también el apartado de presupuestos y pedidos con el
de 2.1.4 Presupuestos en Ventas.
En el menú de la parte inferior, además de las notas, en el caso del usuario “nuestra
compañía” aparecerían también los contactos. El de ventas y compras e historial será similar
para todos, mientras que el de contabilidad solo será visible para quien se considere, en un
principio pondrá que para la empresa matriz.para ver la parte de Contabilidad y Terminal
Punto de Venta habrá que tener instalados los módulos correspondientes.
197
198
En cada uno de los contactos puede marcarse que se está siguiendo. Ello permitirá tener más
información de primera mano en apartados sucesivos.
1.2.3. Notas
Permite agregar notas y notificarlas a los contactos.
1.3 Mis grupos
Permite la gestión de la información con conjuntos de personas. Desde la creación de noticias

para toda la compañía a solo para determinados grupos en ella. Permite interaccionar e invitar
a que interaccionen así como crear grupos de debate, dentro de la propia compañía o con los
clientes
199
2. Ventas
Al instalar la aplicación Sales management se inserta parte del

módulo de Ventas y parte del módulo de Contabilidad. Queda
automáticamente también instalada la aplicación eInvoicing &
Payments. Se instala también con la aplicación Issue Tracker.En el
apartado de ventas se instauran los objetos clientes, presupuestos,
pedidos de ventas y productos, como ya se ha visto, para que
aparezcan el resto de los objetos habrá que contar con la aplicación
CRM. En el apartado de contabilidad quedan definidas las facturas de
cliente, rectificativas, recibo de ventas, pagos de cliente, clientes y sus
correspondientes objetos relativos a los proveedores.
2.1 Ventas
2.1.1. Clientes
La creación de un cliente es exactamente igual a como se hace en la de un contacto, pero solo

se considerarán como clientes a los que estén en este apartado o en el de clientes de
contabilidad, que son el mismo.
2.1.2 Iniciativas
En una iniciativa puede ponerse toda la información que aparece en la imagen, información
sobre la compañía, sobre el cliente, el registro de llamadas y puede seleccionarse también
quien es el comercial así como la prioridad que esta tenga. Una vez guardada una iniciativa
puede convertirse en oportunidad.
200
2.1.3 Oportunidades
Como se ha visto pueden crearse oportunidades convirtiendo iniciativas y también puede

hacerse del modo que ahora va a indicarse desde el apartado de contactos, el procedimiento
es exactamente el mismo.
Una vez pulsada la opción de crear se abre la siguiente ventana:
Una vez guardada hay cuatro posibles vistas para el tratamiento de las oportunidades. A
continuación se muestra una imagen de la vista Gantt. Como puede apreciarse está dividida en
columnas. Pueden añadirse, suprimirse y editarse. Las propue stas creadas pueden moverse de
unas a otras con tan solo arrastrarlas con el ratón.
201
La vista Lista muestra todas las oportunidades en forma de lista. La vista formulario es igual a
la de creación, permite convertir la oportunidad en un presupuesto, que se explica en el
apartado siguiente. Las otras dos vistas son una en forma de gráfico y otra en forma de
calendario.
2.1.4 Presupuestos
En el apartado de presupuestos y pedidos además de crearlo puede enviarse por correo

electrónico, imprimirse, confirmar la venta o cancelarse. Es importante tener cuidado en
cuanto a la parte de cancelar, que la hay en los diferentes apartados porque automáticamente
se cancela el pedido aunque solo quisiéramos volver atrás.
202
Cuando se selecciona el cliente puede enviarse a un cliente nuevo o automáticamente crear

uno. Cuando se da a añadir elemento se crea una Línea del pedido.
Una vez el pedido se ha enviado, se marca, una vez se ha vendido se marca también. Desde
este momento la venta pasa al apartado siguiente Pedido de ventas será allí donde haya que
buscarla cuando quiera volverse a ella. En la lista de presupuestos solo se almacenarán los no
confirmados aún.
2.1.5 Pedido de ventas
Una vez el pedido está realizado se puede ver el orden de entrega, crear una factura o
cancelar el pedido. Si se pulsa en ver orden de entrega:
203
Como puede apreciarse en Estado aparece esperando disponibilidad, los posibles estados son:
Puede modificarse de dos maneras, de manera automática pulsando en forzar disponibilidad o

en comprobar disponibilidad.
Puede crearse una factura sobre el pedido completo, sobre un porcentaje, sobre un precio fijo
(depósito) o sobre algunas líneas del pedido. También pueden hacerse facturas desde el
apartado 5.1.1 Facturas de cliente
204
Una vez se ha hecho esto, en ver factura puede pagarse la factura o reintegrar la factura. En
ver orden de entrega se entrega el producto. Pueden devolverse también. Una vez la factura
está pagada, se considera el pedido como realizado.
Este es un proceso que se hace por etapas. La imagen anterior es la vista de formulario, pero
en la vista lista aparecen las ventas con los detalles de los distintos momentos del pedido.
2.2 Llamadas telefónicas
En este apartado se podrán ver, crear y editar las llamadas registradas y las planificadas, así
como crear contactos. También tiene la opción de conversión a oportunidad en la vista
formulario.
2.3 Productos
Este apartado que aquí se describe en detalle está presente también en el apartado3.2
Productos de TPV en el de compras 6.4.2 Productos , en el del almacén 7.5.2 Productos y en
el de fabricación 8.3.2 Productos.
205
Lo primero es crear el producto. En lista de materiales puede seleccionarse una o crearse.

Cuando se crea un nuevo material se hace a base de productos existentes o creando nuevos
productos. Es decir, si queremos un producto final tendremos que tener registradas como
productos sus distintas partes. Esto puede aclararse para no dar lugar a confusión en las
opciones de categoría y de descripción del producto.
Si se pulsa en pedir abastecimiento aparecerá el siguiente apartado, aunque habrá que

seleccionar previamente al proveedor (5.2.5 Proveedores).
206
Si se accede a puntos de pedidos:
Una vez el producto está guardado en el submenú inferior aparecen las siguientes opciones de
información:
207
208
2.4
209
Configuración: Equipo de ventas
Viene creado por defecto el de departamento de ventas. Tiene diferentes opciones en cuanto
a quien es el jefe del equipo, crearle un código y agregar a los miembros del equipo.
Los miembros del equipo han de estar creados previamente ( 15.4 Usuarios) pues a pesar de
que existe la opción de crearlos finalmente da error.
210
3. Terminal Punto de venta
Para instalar este módulo habrá que hacerlo con la aplicación

Point of sale automáticamente se instalará el Sales management
y eInvoicing & Payments y la correspondiente parte de
contabilidad asociada a los mismos. También el Warehouse
Management correspondiente al módulo 7. Almacén.
3.1 Operaciones diarias
Este apartado contiene “la caja registradora”. Está diseñado para

ratón y pantallas táctiles.
3.1.1 Su sesión
Una vez iniciada la sesión nos encontramos en el siguiente

marco. Como puede apreciarse aparecen los productos que se
tienen creados. En la parte superior derecha hay un buscador. En
la parte inferior hay un teclado.
-Con la tecla Ctd. Marcada se introduce la cantidad.

-Con la tecla Desc. Se introduce el descuento.
-Con la tecla Precio el precio unitario.
Se pulsa en efectivo para introducir la cantidad de dinero aportado y e indica la vuelta
al cliente. Una vez se ha validado la operación permite crear un tiquet para su
impresión para el cliente.
211
Para otra compra se pulsa siguiente pedido.

Para cerrar la caja se pulsa en cerrar. Se
puede volver a la misma sesión simplemente
volviendo a pulsar en comenzar venta. Si se
da a cerrar sesión aparece el siguiente menú.
En el puede continuarse con la caja, indicar si
se extrae o se introduce dinero o validar y
contabilizar el cierre.
212
3.1.2 Todas las sesiones
En este apartado pueden verse las sesiones activas. Habrá una para cada persona que maneje
la caja. Tanto para crear una sesión como para manejarla habrá de hacerlo cada usuario de
forma individual. Como se ve en la imagen aparecen las sesiones activas y las que han sido
cerradas y contabilizadas.
Si se pulsa en cualquiera de ellos abre el extracto bancario.
Si se pulsa en apuntes contables aparecen los registros de pago y cobro.
3.1.3 Pedidos
Inicialmente aparecerá la lista con todos los pedidos que se llevan, así como del de las cajas, en
el caso de estar contabilizadas directamente entera y si no pedido a pedido a pedido.
213
NOTA: Es importante tener cuidado al crear un pedido, de que conste como pagado, porque
en ese caso no dejará contabilizar la caja ni por tanto cerrarla.
3.2 Productos
- El apartado categorías de los productos parece el destinado precisamente a crearlas, pero

realmente el programa las crea pero no resultan efectivas. Una categoría se crea cuando al
crear un producto se selecciona la categoría, si no existe se crea.
- El apartado de productos es exactamente el mismo que el del apartado 2.3 Productos en el

que vienen explicados tanto este punto como el anterior. También aparece en los apartados
de compras 6.4.2 Productos , almacén 7.5.2 Productos y en el de fabricación 8.3.2 Productos
3.3 Configuración TPV
3.3.1 Terminal Punto de Venta
Este es el apartado donde se crea para el programa el Terminal del punto de Venta. Puede
estar en tres estados, activo, inactivo o descatalogado. Pueden ponerse los métodos de pago.
214
3.3.2 Formas de Pago
Pueden tenerse distintas formas de pago, el menú que se despliega al crear una es el que
sigue:
215
Al agregar tipos de cuentas permitidas:
Al agregar cuentas permitidas:
216
217
4. Proyecto
Para tener este módulo completo habrá que instalar dos aplicaciones, Project e Issue Tracker.
Son solo 3 objetos pero que llegan a constar de las 6 vistas en el caso del objeto tareas. Este
módulo está prácticamente relacionado con todos los demás para facilitar la gestión y
coordinación, en las siguientes imágenes se especifican algunas de las interacciones. Se trata
probablemente del módulo más importante de OpenERP.
218
Si pulsamos en tareas:
Las incidencias funcionan de manera análoga a las tareas. Así un proyecto estará compuesto
por su información general, sus tareas y sus incidencias. Una vez creados los proyectos
aparecerán en la bandeja de entrada de la siguiente manera:
Si se pulsa directamente sobre cada uno de ellos aparecerán las tareas o las incidencias
correspondientes. Véase que también hay un desplegable para marcar las realizadas y las
canceladas. Si marcamos en la primera por ejemplo:
219
Y así quedan reflejadas en este caso las dos tareas y la incidencia, que podrán editarse
pulsando directamente sobre ellas. Si sin embargo lo que se quiere es editar el proyecto de
forma general habrá que ir a la vista lista, marcar el proyecto a editar e ir a la vista formulario.
Por otra parte, no será necesario que la aplicación Issue Tracker esté instalada, en este caso
únicamente desaparecerían las incidencias.
OpenERP también permite insertar comentarios y documentos dentro de una tarea, como
nota o como mensaje.
220
Pulsando la vista lista aparecen así y se pueden descargar.
Algo muy a tener en cuenta y que puede resultar de mucha utilidad es la vista Gantt ya que
ayuda notablemente en la planificación de las tareas. Por ejemplo en el caso de este mismo
proyecto:
Teniendo como vista Gantt:
221
5. Contabilidad
Este módulo está relacionado con los de ventas, presupuestos y

almacén y sin embargo es el único de ellos que puede instalarse sin
depender de ninguno de ellos. Es sin duda alguna el módulo más
completo y complejo del ERP, pidiendo ya de inicio para su instalación
que se defina el plan contable y el año fiscal. Se instala con la aplicación
Acounting and Finance.
5.1 Clientes
5.1.1 Facturas de cliente
Podrá crearse una factura desde este apartado o desde 2.1.5 Pedido de
ventas en su parte correspondiente.
222
Una vez validada aparecerá el siguiente cuadro con las opciones de enviarla, pagarla o
reintegrarla. Podrá imprimirse también utilizando como cabecera los datos relativos a l a
empresa que se definen en la parte de compañía, donde está el logo.
5.1.2 Facturas rectificativas de cliente
Una factura rectificativa es un documento que abona una factura total o parcialmente. En
lugar de crear una factura rectificativa manualmente, puede generarla directamente desde la
misma factura origen en la opción de reintegrar factura.
223
5.1.3 Recibo de ventas
Cuando un recibo de venta es confirmado, puede grabar el pago de cliente relacionado.
224
5.1.4 Pagos de cliente
Aparecerán los que ya estén contabilizados en otros apartados y podrán crearse nuevos.
5.1.5 Clientes
Se crearán exactamente igual que un contacto solo que se considerarán solo como clientes a
los que estén en este punto o en el de clientes en el apartado de ventas.
5.2 Proveedores
5.2.1 Facturas de proveedor
Puede controlar la factura de su proveedor según lo que compró o recibió. OpenERP también
puede generar borradores de facturas automáticamente a partir de pedidos o recibos de
compra.
225
5.2.2 Facturas rectificativas de proveedor
En lugar de crear la factura rectificativa de proveedor manualmente, puede generarla y

conciliarla directamente desde la factura de proveedor relacionada. El modelo se parece a la
factura rectificativa de cliente, pero no es exactamente igual.
226
5.2.3 Recibos de compras
Cuando se confirma un recibo de compra, puede registrar el pago de proveedor relacionado

con este recibo de compra.
227
5.2.4 Pagos a proveedores
OpenERP le ayuda a gestionar fácilmente los pagos que hace y los saldos pendientes que
necesita pagar a sus proveedores.
5.2.5 Proveedores
OpenERP le ayuda a gestionar todas las actividades relacionadas con los proveedores:
discusiones, historial de oportunidades de negocio, documentos, etc. Este apartado también
aparece en el de Compras.
En los apartados en que mande seleccionar un proveedor, si no está entre los existentes el
programa aporta la opción de crearlos de manera instantánea.
228
En el menú lateral puede crearse una factura del proveedor y puede solicitarse un presupuesto
en pedidos de compra. La solicitud de presupuesto (SdP) es el primer paso en el flujo de
compras. Una vez convertida en un pedido de compra, será capaz de gestionar la recepción de
los productos y la factura de proveedor.
229
5.3 Banco y caja
5.3.1 Extractos bancarios
Un extracto bancario es un resumen de todas las transacciones bancarias ocurridas en un

periodo de tiempo en una cuenta bancaria. Debería recibirlo periódicamente de su banco.
OpenERP le permite conciliar una línea del extracto directamente con las facturas de compra o
venta relacionadas. Si se pulsa crear:
230
Si se pulsa importar facturas permite agregar facturas existentes o incluso crearlas:
5.3.2 Registro de caja
Aquí constarán los registros de las cajas. Desde el apartado 3. Terminal Punto de venta estos
datos no aparecen. Podrá accederse a los existentes o crear nuevos.
231
Un ejemplo de una existente:
232
233
5.4 Asientos contables
En el apartado de asientos contables aparecerán todos los del ejercicio en que se esté. En la
vista formulario podrán verse los detalles de cada uno. Un ejemplo:
5.5 Planes contables
5.5.1 Plan contable
234
Para crear uno nuevo, se hará desde esta ventana en vista formulario. Si se pulsa sobre cada
uno de los registros se accede a los apuntes contables.
5.5.2 Tabla de impuestos
Al igual que en el apartado anterior pulsando sobre cada uno se accede a los puntos contables
y en vista formulario para editar y crear.
5.6 Procesamiento periódico
5.6.1 Asientos borrador. Asentar asientos
235
5.6.2 Conciliación
5.6.3 Asientos recurrentes
Un asiento recurrente ocurre en un plazo recurrente desde una fecha específica, por ejemplo
correspondiendo con la firma de un contrato con un empleado, un cliente o un proveedor.
Puede crear dichas entradas para automatizar las entradas en el sistema.
236
5.6.4 Fin de periodo
237
5.7 Informe
5.7.1 Informes legales
5.7.1.1 Informes contables
238
5.7.1.2 Diarios
239
Pulsando agregar puede añadirse uno existente o crearlo. Si se pulsa en crear:
En el siguiente apartado, diarios, ocurrirá lo mismo.
También compartirán formato entre sí los diarios generales y el diario centralizado:
240
241
5.7.2 Informes genéricos
5.7.2.1 Empresas
242
5.7.2.2Informe impuestos
5.8 Configuración
5.8.1 Periodos
5.8.1.1 Ejercicios fiscales
243
5.8.1.2 Periodos
5.8.2 Diarios
244
5.8.3 Cuentas
5.8.3.1 Configurar sus cuentas bancarias
Configure las cuentas bancarias de su compañía y seleccione las que deben aparecer al pie del
informe. Si usa la aplicación de contabilidad de OpenERP, los diarios y las cuentas serán
creados automáticamente en base a esta información.
Tal y como se ve en la parte inferior puede seleccionarse un diario de contabilidad o crearse. A

la hora de seleccionar el banco puede hacerse con uno ya registrado o “crearlo”:
245
5.8.3.2 Cuentas
5.8.3.3 Plantillas
5.8.3.3.1 Cuentas
246
Al añadir un impuesto:
Por defecto Open ERP tiene 4674 plantillas de cuentas, aún así pueden crearse las que se
deseen:
247
5.8.3.3.2 Impuestos
248
5.8.4 Impuestos
249
5.8.5Informes financieros
250
5.8.6 Varios. Plazos de pago
251
6. Compras (Purchases)
Este módulo se puede instalar desde varias aplicaciones.

Principalmente la aplicación Purchase management que además
instala también la aplicación Warehouse management
correspondiente al 7. Almacén. También aparece instalada
cuando se instala la 8.Fabricación mediante la aplicación MRP.
6.1 Compras
6.1.1 Presupuestos
Puede crear una petición de presupuesto cuando quiera

obtener productos de un proveedor pero la compra todavía no
se haya confirmado. Utilice asimismo este menú para revisar las
peticiones de compra creadas automáticamente en base a sus
reglas de logística (stock mínimo, obtener bajo pedido, etc).
Puede convertir la petición en una compra una vez el pedido se
haya confirmado. Si utiliza la interfaz extendida (desde las
Preferencias de Usuario), puede elegir la forma de controlar sus facturas de proveedor:
basadas en pedido, basadas en recepciones o codificación manual.
El presupuesto contiene el historial de la discusión/negociación que tiene con su proveedor.

Una vez confirmada, la solicitud de presupuesto se convierte en un pedido de compra.
La mayoría de propuestas de pedidos de compra se crean automáticamente por OpenERP

basadas en las necesidades de inventario.
252
6.1.2 Pedidos de compra
Use este menú para buscar sus pedidos de compra por referencias, proveedor, productos, etc.
Para cada pedido de venta, puede controlar la discusión relativa con el proveedor, controlar
los productos recibidos y controlar las facturas de proveedor.
6.1.3 Proveedores (Suppliers)
El apartado es el mismo que aparece en la parte de contabilidad 5.2.5 Proveedores.
6.2 Productos entrantes
6.2.1 Albaranes de entrada
Los albaranes de entrada es la lista de todos los pedidos que recibirá de sus proveedores. Un
albarán de entrada contiene una lista de productos a ser recibidos de acuerdo con el pedido de
compra original.
253
6.2.2 Productos a recibir
Aquí puede recibir productos individuales, no importa de qué pedido de compra o de qué
albarán provengan. Encontrará la lista de todos los productos que está esperando. Una vez
recibido un pedido, puede realizar un filtro basado en el nombre del proveedor o la referencia
del pedido de venta. Puede confirmar entonces todos los productos recibidos usando los
botones a la derecha de cada línea.
6.3 Control de facturas
6.3.1 Sobre facturas borrador
Use este menú para controlar las facturas a ser recibidas de sus proveedores. OpenERP genera
facturas borrados de los pedidos de venta o recepciones, dependiendo de su configuración.
Una vez recibe una factura de proveedor, puede casarla con la factura en borrador y validarla.
254
6.3.2 En las líneas de pedido de compra
Aquí puede seguir todas las líneas de los pedidos de compra cuya facturación sea "Basada en
las líneas de pedido de compra", y para las cuales aún no ha recibido factura de proveedor.
Puede generar facturas de compra borrador basadas en las líneas de esta lista.
6.3.3 En envíos entrantes
Aquí puede seguir el rastro a todas las recepciones de producto de los pedidos de compra
cuando la facturación está "Basada en recepciones", y para las que no ha recibido una factura
de proveedor aún. Puede generar una factura de proveedor basada en estas recepciones.
255
6.4 Productos
6.4.1 Productos por categoría
6.4.2 Productos
El apartado es el mismo que el 2.3 Productos y en para distinguir que productos son los que
se compran de los que se venden basta con marcarlo en la casilla correspondiente. También
aparece en el apartado de TPV 3.2 Productos y en el de almacén 7.5.2 Productos y en el de
fabricación 8.3.2 Productos
256
7. Almacén
Este módulo se instala desde la apliación Warehouse

Management que instaura también su correspondiente parte
de contabilidad. Este módulo se crea también cuando se
instala el módulo 3.Terminal punto de venta el 6.Compras o
8.Fabricación.
7.1 Recibir/Enviar por pedidos
7.1.1 Albaranes de entrada
257
7.1.2 Albaranes de salida
7.2 Recibir/ Enviar productos
7.2.1 Productos a recibir
Aquí puede recibir productos individuales, no importa de qué pedido de compra o de qué
albarán provengan. Encontrará la lista de todos los productos que está esperando. Una vez
recibido un pedido, puede realizar un filtro basado en el nombre del proveedor o l a referencia
del pedido de venta. Puede confirmar entonces todos los productos recibidos usando los
botones a la derecha de cada línea. Es el mismo apartado de compras que 6.2.2 Productos a
recibir.
7.2.2 Productos a enviar
Puede encontrar en esta lista todos los productos que tiene que entregar a sus clientes. Puede
procesar las entregas directamente usando los botones a la derecha de cada línea. Puede
filtrar los productos a entregar por cliente, producto o pedido de venta (usando el campo
'Origen').
258
7.3 Control inventario. Inventarios físicos
Los inventarios periódicos se usan para contar el nº de productos disponible por ubicación.
Puede usar uno al año cuando se realice el inventario general o siempre que lo necesite, para
adaptar el nivel actual de inventario de un producto.
7.4 Planificaciones
7.4.1 Ejecutar planificaciones
259
7.4.2 Excepciones abastecimiento
7.5 Productos
Es el mismo apartado que aparece en Compras en 6.4.1 Productos por categoría
7.5.2 Productos
Es el mismo apartado que se encuentra en las secciones de Ventas 2.3 Productos y en los
apartados 3.2 Productos de TPV y en el de compras 6.4.2 Productos y en el de fabricación
8.3.2 Productos
7.6 Configuración. Reglas de abastecimiento.
Puede definir sus reglas de stock mínimo, para que OpenERP cree órdenes de producción en
borrador o solicitudes de presupuesto de forma automática de acuerdo a los niveles de stock.
Una vez que el stock virtual de un producto (= stock real menos todos los pedidos de venta
confirmados y todas las reservas) está por debajo de la cantidad mínima, OpenERP generará
una petición de abastecimiento para incrementar el stock hasta la cantidad máxima.
260
261
8. Fabricación
Se instala este módulo con la aplicación MPR. Además con la

misma se instala su parte correspondiente de contabilidad, el
módulo 6. Compras y el módulo 7.Almacén.
8.1 Órdenes de producción
Una orden de fabricación, basada en una lista de materiales,

consumirá materias primas y producirá productos finalizados.
Las órdenes de fabricación son propuestas usualmente de

manera automática basadas en los requisitos del cliente o
reglas automáticas como la regla de stock mínimo.
8.2 Planificación de la orden
Este apartado remite a un calendario sobre el cual al pulsar en una fecha abre el apartado de
crear la orden de producción.
8.3 Productos
8.3.1 Lista de materiales
Permite crear una lista con los materiales y su descripción. Estas listas se hacen para formar
parte de un producto, con lo que pueden crearse a partir del apartado de productos.
8.3.2 Productos
Es el mismo apartado que se encuentra en las secciones de Ventas 2.3 Productos y en los
apartados 3.2 Productos de TPV, en el de compras 6.4.2 Productos y en 7.5.2 Productos.
262
8.4. Configuración Lista de materiales.
Mientras que en el apartado de lista de materiales aparece el producto con su material aquí
aparecen todos. Si un sub-producto se usa en varios productos puede ser útil crear su propia
LdM.Sin embargo, si no quiere órdenes de fabricación separadas para este subproducto,
seleccione “conjuntos/fantasma” como tipo de LdM. Si una LdM fantasma se usa para un
producto raíz, será vendido y entregado como un conjunto de componentes, en lugar de ser
fabricado.
263
9. Recursos humanos
Para instalarlo al completo será necesario instalar las aplicaciones

Employee directory, Recruitment Process, Timesheets, Leave
Management, Expense Management y Employee apraxails. Al instalar
estas aplicaciones queda definido también el módulo 13.Encuestas.
9.1 Empleados
9.2 Reclutamiento. Solicitudes
OpenERP le permite administrar los solicitantes en el proceso de

reclutamiento, y seguir todas las operaciones: reuniones, entrevistas,
etc.
Si establece la pasarela de correo, los solicitantes y sus CVs adjuntos serán creados
automáticamente cuando se envíe un correo a la dirección indicada (por ejemplo,
solicitudes@tucompañia.com). Si instala el módulo de administración de documentos, todos
los CVs serán indexados automáticamente, para que pueda buscar fácilmente en todo su
contenido.
264
9.3 Seguimiento de tiempo
9.3.1 Mi hoja de servicios actual
265
9.3.2 Partes de horas a validar
Debe registrar los partes de horas cada día y confirmarlos al final de la semana. Una vez el
parte de horas esté confirmado, debe ser validado por un responsable.
Los partes de horas también pueden ser facturados a los clientes, dependiendo de la
configuración del contrato relativo a cada proyecto.
9.3.3 Actividades del parte de horas
Puede registrar y hacer un seguimiento de sus horas de trabajo por proyecto a diario. Todo
tiempo invertido en un proyecto generará un coste asociado en el contrato/cuenta analítica y
puede ser facturado si es preciso.
9.4 Gastos
OpenERP se asegurará que se sigue todo el proceso: la hoja de gastos es validada por el
responsable, al empleado se le reembolsa sus gastos, y algunos gastos pueden ser re-
facturados a los clientes.
266
9.5Ausencias
9.5.1 Peticiones de ausencia
Una vez grabada su petición, se enviará a su supervisor para que la valide. Asegúrese de poner
el tipo de ausencia correcta (recuperación, vacaciones, enfermedad) y el número exacto de
días.
9.5.2 Peticiones de ausencia a aprobar
Una vez creada la petición pasa a este apartado en que el responsable decidirá si la aprueba o
no.
267
9.5.3 Peticiones de asignación
9.5.4 Peticiones de asignación a aprobar
Una vez creada la petición pasa a este apartado en que el responsable decidirá si la aprueba o
no.
9.5.5 Resumen de ausencias
Aquí quedarán registradas tanto las ausencias como las asignaciones.
9.6 Evaluación
9.6.1 Evaluaciones
Cada empleado debe tener asignado un plan de evaluación. Cada plan define la frecuencia y la
forma en la que se administran las evaluaciones personales. Podrá definir pasos y adjuntar
entrevistas a cada paso. OpenERP gestiona todo tipo de evaluaciones: de abajo a arriba, de
arriba a abajo, auto-evaluaciones y evaluaciones finales por el responsable.
Puede crearse, o hacerse con el plan que trae por defecto.
268
Al añadir un elemento se abre la ventana de crear formulario de evaluación, ver apartado

13.Encuestas.
269
9.6.2 Petición de entrevista
Las peticiones de entrevista se generan normalmente automáticamente por OpenERP de

acuerdo al plan de evaluación del empleado. Cada usuario recibe automáticamente correos
electrónicos y peticiones para evaluar a sus compañeros periódicamente.
9.7 Configuración
9.7.1 Puestos de trabajo
Los puestos de trabajo se usan para definir puestos y sus requisitos. Puede seguir el número de
empleados que tiene por puesto de trabajo y su evolución de acuerdo a lo que tiene planeado
para el futuro.
Puede adjuntar una encuesta a un puesto de trabajo. Será usada en el proceso de

reclutamiento para evaluar a los solicitantes de dicho puesto.
9.7.2 Departamentos
La estructura de departamentos de OpenERP se usa para administrar por departamentos

todos los documentos relacionados con los empleados: gastos, partes de hora, ausencias y
vacaciones, reclutamientos, etc.
270
9.7.3 Tipos de ausencia
9.7.4 Categorías de gasto
Es el mismo apartado que crear un producto, solo que en la calificación se le considera gasto.
9.7.5 Plan de evaluación
Aquí se crea directamente el plan de evaluación que se trata en el apartado 9.6.1 Evaluaciones.
271
10. Comidas
Este módulo permite gestionar el comedor de la empresa en

caso de haberlo, es un módulo complementario que en la
mayoría de las ocasiones no será necesario instalar. Se procede
con la aplicación Lunch orders.
10.1 Comidas
10.1.1 Nuevo pedido
10.1.2 Pedidos previos
Un pedido de comida se define con el usuario solicitante, la fecha y las líneas de pedido. Cada
línea de pedido corresponde a un producto, comentarios adicionales y un precio. Antes de
seleccionar sus líneas de pedido, no olvide leer las advertencias mostradas en el área rojiza.
10.1.3 Su cuenta de comida
Objeto destinado a hacer una descripción de cada una de las comidas, incluyendo la fecha el
nombre del usuario y el importe.
272
10.2 Pedidos administrativos
10.2.1 Pedidos de hoy por proveedor
10.2.2 Pedidos por proveedor
10.3 Movimientos de caja administrativos
10.3.1 Cuentas de control
10.3.2 Pagos de los empleados
Aquí puede ver los pagos de los empleados. Un pago es un movimiento de caja del empleado a
la compañía.
10.4 Configuración
10.4.1Productos
Un producto se define por su nombre, su categoría, su precio y su proveedor.
273
10.4.2 Categorías de producto
Aquí puede encontrar cada categoría de comida para los productos.
10.4.3 Alertas
Las alertas se usan para avisar a los empleados de posibles incidencias relacionadas con los
pedidos de comida. Para crear una alerta de comida debe definir su recurrencia: el intervalo de
tiempo durante el que las alertas deben ejecutarse y el mensaje a mostrar.
Ejemplo:
- Recurrencia: Semanal. Lunes.
- Intervalo de tiempo: de 7:00 a 23:59
- Mensaje: "Los lunes no se incluirá pescado en el menú"
274
11. Flota
Se instala con la aplicación Fleet management.
11.1 Vehículos
Podrá gestionar su flota siguiendo los contratos, servicios,

costes fijos y recurrentes, odómetros y registros de
combustible asociados a cada vehículo.
OpenERP le avisará cuando los servicios o el contrato

tengan que ser renovados.
275
11.2 Contratos de vehículos
Gestione todos sus contratos (leasing, seguros, etc.) con sus servicios y costes relacionados.
OpenERP le avisará automáticamente cuando algún contrato deba ser renovado.
Cada contrato (por ejemplo: leasing) puede incluir varios servicios ( reparación, seguro,
mantenimiento periódico...).
276
11.3 Odómetro de los vehículos
Aquí puede añadir varias entradas de odómetros para todos los vehículos. Puede también
mostrar los valores de odómetro para un vehículo en particular usando el campo de búsqueda.
11.4 Registro de combustible de los vehículos
Aquí puede añadir entradas de reabastecimiento de combustible para todos los vehículos.
Puede también filtrar los registros de un vehículo en particular usando el campo de búsqueda.
11.5 Registro de los servicios de los vehículos
OpenERP le ayuda a seguir todos los servicios realizados en su vehículo. Los servicios pueden
ser de muchos tipos: reparaciones ocasionales, mantenimiento, fijos, etc.
277
11.6 Costes del vehículo
11.7 Estado del vehículo
Puede personalizar los estados disponibles para seguir la evolución de cada vehículo. Por
ejemplo: Activo, siendo reparado, vendido, etc.
278
12. Eventos
OpenERP le ayuda a planificar y organizar eficientemente sus

eventos: seguir la pista de sus suscripciones y participaciones,
automatizar los correos electrónicos de confirmación, tickets de
venta, etc. Se instala con la aplicación Events organisation.
279
13. Encuestas
13.1 Encuestas
Este apartado está íntimamente relacionado con el 9.6.1

Evaluaciones en recursos humanos de cara a la evaluación del
personal y a las entrevistas. Se instala con la aplicación
Employee Appraisals, que también instalará parte del citado
módulo de recursos humanos, también se instala con la
Recruitment Proccess.
OpenERP por defecto trae tres que están totalmente en inglés incluso en su versión en
castellano. Job survey que es una encuesta sobre el empleo, Self-appraisal que es un
cuestionario de autoevaluación y Employee opinión que trata sobre las opiniones del
empleados. Además de cómo ejemplo pueden servir como modelo para crear las propias.
280
13.2 Solicitudes de encuesta
13.3 Páginas encuesta
281
14 Informes
Se corresponde con la vista gráficos en todos aquellos apartados en que esté

presente. Como puede verse pulsando en la gráfica en la flecha aparece un
menú de opciones. En la de mostrar datos se abre una nueva ventana que
permite exportar los datos en formato CSV para abrir con Excel o su
equivalente en Openoficce además de impresiones en PDF.
Este apartado es por tanto prácticamente gráfico, y salvo estos a penas se

puede cambiar nada que no haya sido proporcionado desde su apartado
correspondiente. A continuación se proporcionarán un par de ejemplos de la
exportación y datos y se mostrarán solo aquellos apartados en los que haya
algo a editar.
No será necesaria la instalación de una aplicación específica, al igual que el de

mensajes aparece por defecto al instalar cualquier otro.
14.1 Tableros
14.1.1 Mi tablero
Para añadir su primer informe al tablero, vaya a cualquier menú, cambie a

vista lista o gráfico y pulse 'Añadir al tablero' en las opciones de búsqueda
extendidas.
Puede filtrar y agrupar datos usando las opciones de búsqueda antes de

insertarlo en el tablero.
14.1.2 CRM
282
14.1.3 Ventas
14.3 Encuestas
283
14.9 Recursos humanos
14.9.3 Parte de horas del empleado
14.9.8 Informes
284
14.10 Terminal Punto de Venta
14.10.2 Detalles de ventas
285
15 Configuración
Algo muy importante a la hora de la configuración del OpenERP es

tener activada la casilla de características técnicas para el usuario
correspondiente. Es necesario casi para todos los procesos de
edición o modificación. También es importante salientar que
aunque el resto de usuarios puedan hacer cambios en muchos
casos solo el administrador puede efectuarlos.
15.1 Módulos
Podrán instalarse estos módulos que son los básicos o seguir buscando, hay más de 1500,
aunque la mayoría se corresponden con las adaptaciones a los diferentes idiomas y dialectos.
En muchos casos habrá que estar registrado para poder descargarse los módulos.En ocasiones
serán de pago, en otras gratuitos y cobrarán el mantenimiento, pero es una opción
deshabilitable.
286
15.2 Configuración
15.2.1 Ventas (Sales)
15.2.2 Compras
287
15.2.3 Almacén
15.2.4 Manufacturas
15.2.5 Proyectos
288
15.2.6 Contabilidad
15.2.7 Recursos humanos
289
15.2.8 Configuraciones generales
Configurar servidores de correo saliente:
Configurar la pasarela de correo electrónico entrante:
290
15.3 Compañías
Esta configuración es importante ya que será la que aparezca en los infores y en las facturas.
Puede accederse a este menú directamente pulsando en la casilla de la izquierda en que se
indica el “logo “ de la empresa.
291
15.4 Usuarios
En este apartado se crearán los usuarios del OpenERP. Estos podrán corresponder o no con los
empleados de la misma. Los permisos de acceso se configuran para los módulos de OpenERP,
los permisos de los propios habrá que configurarlos en el apartado grupos, y habrá que hacerlo
objeto a objeto.
A continuación se muestra la ventana de permisos de acceso, imprescindible activar la casilla

de características técnicas si se pretenden hacer cambios en el ERP. En cuanto se pulse y se
actualice el navegador se verán múltiples menús ocultos de configuración en todos los
módulos, incluyendo en este mismo.
292
Para introducir la contraseña, una vez el contacto ha sido guardado, en la vista lista se
selecciona el usuario, se pulsa la tecla más y en ella cambiar contraseña.
15.5 Cargar una traducción
Permite cargar una traducción de OpenERP. Aún así la traducción no es completa ni siquiera en
un idioma como el castellano. En el menú de preferencias del usuario podrá cambiarse el
idioma.
15.6 Técnico
Para tener acceso a este menú será necesario tener marcado

características técnicas en los permisos de acceso de cada
usuario.
No es recomendable utilizar este menú si no se tiene un dominio

claro del programa. No se utilizará a nivel usuario. Tan solo en el
caso de hacerlo a través de tutoriales, algunos de los cuales se
adjuntan en apartados posteriores.
A través de “estructura de la base de datos” podrán crearse en

modo gráfico, módulos, menús y objetos
293
Configuración: características técnicas

Los apartados que se van a mencionar a continuación solo aparecen en el caso de que en la
configuración del usuario esté marcada la casilla de características técnicas. Podrá apreciarse
que se incrementan algunos campos en los diferentes módulos. No será recomendable
manipular muchos de ellos sin conocimientos previos ya que pueden afectar al resto del
programa.
1.2.4 Categorías
2. Ventas
En este apartado en la mayoría de los casos los objetos pueden crearse desde la
opción crear cada vez que se necesite uno. A continuación se detallarán aquellos
que aporten algo diferente a una mera enumeración.
294
2.4.2 Segmentación de contactos
Cree categorías específicas que puede asignar a sus contactos para administrar mejor sus
interacciones con ellos. La herramienta de segmentación es capaz de asignar categorías a los
contactos de acuerdo a los criterios que establezca.
- El resto de las categorías que siguen lo están en forma de enumeración como el siguiente
ejemplo por lo que ya no se seguirán describiendo.
295
Botón de la derecha:Usuario
Está justo al lado del de los mensajes, es una de las partes más importantes del ERP, desde
aquí por ejemplo es desde donde se cierra sesión. Al pulsarlo se abre el siguiente menú
desplegable:
Al pulsar Mi cuenta OpenERP. Com redirecciona a la página de esta web en la cual se pedirá
que se registre. Salvo que se tengan los conocimientos necesarios será evitable está opción.
296
Pulsando Acerca de OpenERP se abre la ventana para activar el modo desarrollador.
Es importante y añade al ERP nuevos apartados en los cuales habrá que tener cuidado en su
utilización y será mejor hacerlo para casos concretos. Es especialmente útil para conocer el
nombre de los objetos. Una vez está activado basta con poner el ratón encima de un campo
para que aparezca la información sobre este.
297
Lo que se puede apreciar en un primer lugar al lado de la mayoría de los apartados es que se
despliega la siguiente ventana al lado del nombre de cada uno, con una interrogación al lado
que abrirá un nuevo menú.
Este desplegable es el mismo en todos los módulos y en todos los campos.
Pulsando ayuda el programa redirige a la siguiente dirección http://help.openerp.com/ques tions/

que es un foro en inglés de ayuda.
298
Inicio: Crear distintas bases de datos
Es lo primero que aparece cuando se accede al OpenERP. El usuario introduce su nombre y su

clave y accede. Como se puede ver en la parte superior derecha de la imagen se abre un
desplegable con la base de datos a la que se puede uno conectar. Podrá crearse una nueva
base de datos pulsando donde indica la flecha amarilla en gestionar bases de datos. Cuando
pida la contraseña maestra esta es por defecto “admin”. En las figuras siguientes se muestran
todas las opciones.
299
300
ANEXO III
MÓDULOS
PROGRAMADOS
ANEXO III: MÓDULOS PROGRAMADOS
1. Lista de correos.
Archivo __init__.py
# -*- coding: utf-8 -*-
##############################################################################
# but WITHOUT ANY WARRANTY; without even the implied warranty of
##############################################################################
import lista_correos
Archivo __openerp__.py
# -*- coding: utf-8 -*-
##############################################################################
303
##############################################################################
"name" : "Lista de correos",
"version" : "0.1",
"description": """ """,
'data': [],
'update_xml': ["lista_correos.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'active': False,
304
Archivo lista_correos.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
class lista_correos_listageneral(osv.osv):
_name = 'lista_correos.listageneral'
_description = 'Lista general'
_columns = {
'email': fields.char('E-mail', size=200, required=True),
'fuente': fields.char('Fuente', size=200, required=False),
'empresa': fields.char('Empresa', size=64, required=False),
'poblacion': fields.char('Población', size=200, required=False),
'provincia': fields.char('Provincia', size=200, required=False),
305
'telefono': fields.char('Teléfono', size=200, required=False),
'cif': fields.char('C.I.F.', size=200, required=False),
'direccion': fields.char('Dirección', size=200, required=False),
'cp': fields.char('C.P.', size=11, required=False),
'actividad': fields.char('Acitvidad', size=200, required=False),
lista_correos_listageneral()
class lista_correos_bajas(osv.osv):
_name = 'lista_correos.bajas'
_description = 'Bajas'
_columns = {
'actividad': fields.char('Acitvidad', size=200, required=False),
lista_correos_bajas()
class lista_correos_ingenierias(osv.osv):
_name = 'lista_correos.ingenierias'
_description = 'Ingenierias'
_columns = {
306
lista_correos_ingenierias()
class lista_correos_instaladoras(osv.osv):
_name = 'lista_correos.instaladoras'
_description = 'Instaladoras'
_columns = {
lista_correos_instaladoras()
class lista_correos_sondeos(osv.osv):
_name = 'lista_correos.sondeos'
_description = 'Sondeos'
307
_columns = {
lista_correos_sondeos()
class lista_correos_distribuidoras(osv.osv):
_name = 'lista_correos.distribuidoras'
_description = 'Distribuidoras'
_columns = {
lista_correos_distribuidoras()
class lista_correos_arquitectura(osv.osv):
308
_name = 'lista_correos.arquitectura'
_description = 'Arquitectura'
_columns = {
lista_correos_arquitectura()
class lista_correos_sudamerica(osv.osv):
_name = 'lista_correos.sudamerica'
_description = 'Sudamerica'
_columns = {
lista_correos_sudamerica()
309
class lista_correos_otras(osv.osv):
_name = 'lista_correos.otras'
_description = 'Otras'
_columns = {
'poblacion': fields.char('Población', size=200, requ ired=False),
lista_correos_otras()
class lista_correos_agenciasenergia(osv.osv):
_name = 'lista_correos.agenciasenergia'
_description = 'Agencias de energia'
_columns = {
310
lista_correos_agenciasenergia()
class lista_correos_asociaciones(osv.osv):
_name = 'lista_correos.asociaciones'
_description = 'Asociaciones'
_columns = {
lista_correos_asociaciones()
class lista_correos_colegiosprofesionales(osv.osv):
_name = 'lista_correos.colegiosprofesionales'
_description = 'Colegios profesionales'
_columns = {
311
lista_correos_colegiosprofesionales()
class lista_correos_universidad(osv.osv):
_name = 'lista_correos.universidad'
_description = 'Universidad'
_columns = {
class lista_correos_otrosa(osv.osv):
_name = 'lista_correos.otrosa'
_description = 'Otra'
_columns = {
312
lista_correos_otrosa()
class lista_correos_galicia(osv.osv):
_name = 'lista_correos.galicia'
_description = 'Galicia'
_columns = {
'cp': fields.char('C.P.', size=11, required=Fal se),
lista_correos_galicia()
class lista_correos_estatal(osv.osv):
_name = 'lista_correos.estatal'
_description = 'Estatal'
_columns = {
313
lista_correos_estatal()
class lista_correos_extranjero(osv.osv):
_name = 'lista_correos.extranjero'
_description = 'Extranjero'
_columns = {
lista_correos_extranjero()
class lista_correos_especializados(osv.osv):
_name = 'lista_correos.especializados'
_description = 'Especializados'
_columns = {
314
lista_correos_especializados()
class lista_correos_online(osv. osv):
_name = 'lista_correos.online'
_description = 'Online'
_columns = {
lista_correos_online()
class lista_correos_otross(osv.osv):
_name = 'lista_correos.otross'
_description = 'Otro'
_columns = {
315
'cif': fields.char('C.I.F.', size=200, required =False),
lista_correos_otross()
class lista_correos_personas(osv.osv):
_name = 'lista_correos.personas'
_description = 'Personas'
_columns = {
lista_correos_personas()
class lista_correos_otros(osv.osv):
_name = 'lista_correos.otros'
_description = 'Otros'
_columns = {
316
'direccion': fields.char('Dirección', size =200, required=False),
lista_correos_otros()
Archivo lista_correos.xml
<openerp>
<data>
<menuitem name="Lista de correos" id="lista_correos" sequence="90"/>
<menuitem name="Lista general" id="lista_correos_listageneral"

parent="lista_correos"/>
<menuitem name="Tipos de empresa" id="lista_correos_tiposempresa"

parent="lista_correos" />
<menuitem name="Instituciones" id="lista_correos_instituciones"

<menuitem name="Medios de comunicacion" id="lista_correos_mcomunicacion"

<menuitem name="Prescriptores" id="lista_correos_prescriptores"

<record model="ir.ui.view" id="lista_correos_listageneral_tree">
<field name="name">lista_correos.listageneral.tree</field>
<field name="model">lista_correos.listageneral</field>
317
<tree string="listageneral">
<field name="email"/>
<field name="fuente"/>
<field name="empresa"/>
<field name="poblacion"/>
<field name="provincia"/>
<field name="telefono"/>
<field name="cif"/>
<field name="direccion"/>
<field name="cp"/>
<field name="actividad"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_listageneral_form">
<field name="name">lista_correos.listageneral.form</field>
<field name="model">lista_correos.listageneral</field>
<form string="listageneral">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
318
</record>
<record id="lista_correos_listageneral_action"
model="ir.actions.act_window">
<field name="name">Lista general</field>
<field name="res_model">lista_correos.listageneral</field>
</record>
<menuitem action="lista_correos_listageneral_action"
id="lista_correos_listageneral_menu" sequence="1"
parent="lista_correos_listageneral"/>
<record model="ir.ui.view" id="lista_correos_bajas_tree">
<field name="name">lista_correos.bajas.tree</field>
<field name="model">lista_correos.bajas</field>
<tree string="bajas">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
319
<record model="ir.ui.view" id="lista_correos_bajas_form">
<field name="name">lista_correos.bajas.f orm</field>
<field name="model">lista_correos.bajas</field>
<form string="listageneral">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_bajas_action" model="ir.actions.act_window">
<field name="name">Bajas</field>
<field name="res_model">lista_correos.bajas</field>
</record>
<menuitem action="lista_correos_bajas_action"
id="lista_correos_bajas_menu" sequence="2"
parent="lista_correos_listageneral"/>
<record model="ir.ui.view" id="lista_correos_ingenierias_tree">
<field name="name">lista_correos.ingenierias.tree</field>
<field name="model">lista_correos.ingenierias</field>
320
<tree string="ingenierias">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_ingenierias_form">
<field name="name">lista_correos.ingenierias.form</field>
<field name="model">lista_correos.ingenierias</field>
<form string="ingenierias">
<field name="cif"/>
<field name="cp"/>
</form>
321
</field>
</record>
<record id="lista_correos_ingenierias_action"
<field name="name">Ingenierias</field>
<field name="res_model">lista_correos.ingenierias</field>
</record>
<menuitem action="lista_correos_ingenierias_action"
id="lista_correos_ingenierias_menu" sequence="3"
parent="lista_correos_tiposempresa"/>
<record model="ir.ui.view" id="lista_correos_instaladoras_tree">
<field name="name">lista_correos.instaladoras.tree</field>
<field name="model">lista_correos.instaladoras</field>
<tree string="instaladoras">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
322
<record model="ir.ui.view" id="lista_correos_instaladoras_form">
<field name="name">lista_correos.instaladoras.form</field>
<field name="model">lista_correos.instaladoras</fi eld>
<form string="instaladoras">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_instaladoras_action"
<field name="name">Instaladoras</field>
<field name="res_model">lista_correos.instaladoras</field>
</record>
<menuitem action="lista_correos_instaladoras_action"
id="lista_correos_instaladoras_menu" sequence="4"
<record model="ir.ui.view" id="lista_correos_sondeos_tree">
<field name="name">lista_correos.sondeos.tree</field>
<field name="model">lista_correos.sondeos</field>
323
<tree string="sondeos">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_sondeos_form">
<field name="name">lista_correos.sondeos.form</field>
<field name="model">lista_correos.sondeos</field>
<form string="sondeos">
<field name="cif"/>
<field name="cp"/>
</form>
324
</field>
</record>
<record id="lista_correos_sondeos_action" model="ir.actions.act_window">
<field name="name">Sondeos</field>
<field name="res_model">lista_correos.sondeos</field>
</record>
<menuitem action="lista_correos_sondeos_action"
id="lista_correos_sondeos_menu" sequence="5"
<record model="ir.ui.view" id="lista_correos_distribuidoras_tree">
<field name="name">lista_correos.distribuidoras.tree</field>
<field name="model">lista_correos.distribuidoras</field>
<tree string="distribuidoras">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
325
<record model="ir.ui.view" id="lista_correos_distribuidoras_form">
<field name="name">lista_correos.distribuidoras.form</field>
<field name="model">lista_correos.distribuidoras</field>
<form string="distribuidoras">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_distribuidoras_action"
<field name="name">Distribuidoras</field>
<field name="res_model">lista_correos.distribuidoras</field>
</record>
<menuitem action="lista_correos_distribuidoras_action"
id="lista_correos_distribuidoras_menu" sequence="6"
<record model="ir.ui.view" id="lista_correos_arquitectura_tree">
<field name="name">lista_correos.arquitectura.tree</field>
<field name="model">lista_correos.arquitectura</field>
326
<tree string="arquitectura">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_arquitectura_form">
<field name="name">lista_correos.arquitectura.form</field>
<field name="model">lista_correos.arquitectura</field>
<form string="arquitectura">
<field name="cif"/>
<field name="cp"/>
</form>
327
</field>
</record>
<record id="lista_correos_arquitectura_action"
<field name="name">Arquitectura</field>
<field name="res_model">lista_correos.arquitectura</field>
</record>
<menuitem action="lista_correos_arquitectura_action"
id="lista_correos_arquitectura_menu" sequence="7"
<record model="ir.ui.view" id="lista_correos_sudamerica_tree">
<field name="name">lista_correos.sudamerica.tree</field>
<field name="model">lista_correos.sudamerica</field>
<tree string="sudamerica">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
328
<record model="ir.ui.view" id="lista_correos_sudamerica_form">
<field name="name">lista_correos.sudamerica.form</field>
<field name="model">lista_correos.sudamerica</field>
<form string="sudamerica">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_sudamerica_action"
<field name="name">Sudamerica</field>
<field name="res_model">lista_correos.sudamerica</field>
</record>
<menuitem action="lista_correos_sudamerica_action"
id="lista_correos_sudamerica_menu" sequence="8"
<record model="ir.ui.view" id="lista_correos_otras_tree">
<field name="name">lista_correos.otras.tree</field>
<field name="model">lista_correos.otras</field>
329
<tree string="otras">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_otras_form">
<field name="name">lista_correos.otras.form</field>
<field name="model">lista_correos.otras</field>
<form string="otras">
<field name="cif"/>
<field name="cp"/>
</form>
330
</field>
</record>
<record id="lista_correos_otras_action" model="ir.actions.act_window">
<field name="name">Otras</field>
<field name="res_model">lista_correos.otras</field>
</record>
<menuitem action="lista_correos_otras_action"
id="lista_correos_otras_menu" sequence="9"
<record model="ir.ui.view" id="lista_correos_agenciasenergia_tree">
<field name="name">lista_correos.agenciasenergia.tree</field>
<field name="model">lista_correos.agenciasenergia</field>
<tree string="agenciasenergia">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
331
<record model="ir.ui.view" id="lista_correos_agenciasenergia_form">
<field name="name">lista_correos.agenciasenergia.form</field>
<field name="model">lista_correos.agenciasenergia</field>
<form string="agenciasenergia">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_agenciasenergia_action"
<field name="name">Agencias de energia</field>
<field name="res_model">lista_correos.listageneral</field>
</record>
<menuitem action="lista_correos_agenciasenergia_action"
id="lista_correos_agenciasenergia_menu" sequence="10"
parent="lista_correos_instituciones"/>
<record model="ir.ui.view" id="lista_correos_asociaciones_tree">
<field name="name">lista_correos.asociaciones.tree</field>
<field name="model">lista_correos.asociaciones</field>
332
<tree string="asociaciones">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_asociaciones_form">
<field name="name">lista_correos.asociaciones.form</field>
<field name="model">lista_correos.asociaciones</field>
<form string="asociaciones">
<field name="cif"/>
<field name="cp"/>
</form>
333
</field>
</record>
<record id="lista_correos_asociaciones_action"
<field name="name">Asociaciones</field>
<field name="res_model">lista_correos.asociaciones</field>
</record>
<menuitem action="lista_correos_asociaciones_action"
id="lista_correos_asociaciones_menu" sequence="11"
<record model="ir.ui.view" id="lista_correos_colegiosprofesionales_tree">
<field name="name">lista_correos.colegiosprofesionales.tree</field>
<field name="model">lista_correos.colegiosprofesionales</field>
<tree string="colegiosprofesionales">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
334
<record model="ir.ui.view" id="lista_correos_colegiosprofesionales_form">
<field name="name">lista_correos.colegiosprofesionales.form</field>
<field name="model">lista_correos.colegiosprofesionales</field>
<form string="colegiosprofesionales">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_colegiosprofesionales_action"
<field name="name">Colegios profesionales</field>
<field name="res_model">lista_correos.colegiosprofesionales</field>
</record>
<menuitem action="lista_correos_colegiosprofesionales_action"
id="lista_correos_colegiosprofesionales_menu" sequence="12"
<record model="ir.ui.view" id="lista_correos_otrosa_tree">
<field name="name">lista_correos.otrosa.tree</field>
335
<field name="model">lista_correos.otrosa</field>
<tree string="otrosa">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_otrosa_form">
<field name="name">lista_correos.otrosa.form</field>
<field name="model">lista_correos.otrosa</field>
<form string="otrosa">
<field name="cif"/>
<field name="cp"/>
336
</form>
</field>
</record>
<record id="lista_correos_otrosa_action" model="ir.actions.act_window">
<field name="name">Otra</field>
<field name="res_model">lista_correos.otrosa</field>
</record>
<menuitem action="lista_correos_otrosa_action"
id="lista_correos_otrosa_menu" sequence="13"
<record model="ir.ui.view" id="lista_correos_galicia_tree">
<field name="name">lista_correos.galicia.tree</fie ld>
<field name="model">lista_correos.galicia</field>
<tree string="galicia">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
337
<record model="ir.ui.view" id="lista_correos_galicia_form">
<field name="name">lista_correos.galicia.form</field>
<field name="model">lista_correos.galicia</field>
<form string="galicia">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_galicia_action" model="ir.actions.act_window">
<field name="name">Galicia</field>
<field name="res_model">lista_correos.galicia</field>
</record>
<menuitem action="lista_correos_galicia_action"
id="lista_correos_galicia_menu" sequence="14"
parent="lista_correos_mcomunicacion"/>
<record model="ir.ui.view" id="lista_correos_estatal_tree">
<field name="name">lista_correos.estatal.tree</field>
338
<field name="model">lista_correos.estatal</field>
<tree string="estatal">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_estatal_form">
<field name="name">lista_correos.estatal.form</field>
<field name="model">lista_correos.estatal</field>
<form string="estatal">
<field name="cif"/>
<field name="cp"/>
339
</form>
</field>
</record>
<record id="lista_correos_estatal_action" model="ir.actions.act_window">
<field name="name">Estatal</field>
<field name="res_model">lista_correos.estatal</field>
</record>
<menuitem action="lista_correos_estatal_action"
id="lista_correos_estatal_menu" sequence="15"
<record model="ir.ui.view" id="lista_correos_extranjero_tree">
<field name="name">lista_correos.extranjero.tree</field>
<field name="model">lista_correos.extranjero</field>
<tree string="extranjero">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
340
<record model="ir.ui.view" id="lista_correos_extranjero_form">
<field name="name">lista_correos.extranjero.form</field>
<field name="model">lista_correos.extranjero</field>
<form string="extranjero">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_extranjero_action"
<field name="name">Extranjero</field>
<field name="res_model">lista_correos.extranjero</field>
</record>
<menuitem action="lista_correos_extranjero_action"
id="lista_correos_extranjero_menu" sequence="16"
<record model="ir.ui.view" id="lista_correos_especializados_tree">
<field name="name">lista_correos.especializados.tree</field>
341
<field name="model">lista_correos.especializados</field>
<tree string="especializados">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_especializados_form">
<field name="name">lista_correos.especializados.form</field>
<field name="model">lista_correos.especializados</field>
<form string="especializados">
<field name="cif"/>
<field name="cp"/>
342
</form>
</field>
</record>
<record id="lista_correos_especializados_action"
<field name="name">Especializados</field>
<field name="res_model">lista_correos.especializados</field>
</record>
<menuitem action="lista_correos_especializados_action"
id="lista_correos_especializados_menu" sequence="17"
<record model="ir.ui.view" id="lista_correos_online_tree">
<field name="name">lista_correos.online.tree</field>
<field name="model">lista_correos.online</field>
<tree string="online">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
343
<record model="ir.ui.view" id="lista_correos_online_form">
<field name="name">lista_correos.online.form</field>
<field name="model">lista_correos.online</field>
<form string="online">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_online_action" model="ir.actions.act_window">
<field name="name">Online</field>
<field name="res_model">lista_correos.online</field>
</record>
<menuitem action="lista_correos_online_action"
id="lista_correos_online_menu" sequence="18"
<record model="ir.ui.view" id="lista_correos_otross_tree">
<field name="name">lista_corre os.otross.tree</field>
344
<field name="model">lista_correos.otross</field>
<tree string="otross">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_otross_form">
<field name="name">lista_correos.otross.form</field>
<field name="model">lista_correos.otross</field>
<form string="otross">
<field name="cif"/>
<field name="cp"/>
345
</form>
</field>
</record>
<record id="lista_correos_otross_action" model="ir.actions.act_window">
<field name="name">Otro</field>
<field name="res_model">lista_correos.otros</field>
</record>
<menuitem action="lista_correos_otross_action"
id="lista_correos_otross_menu" sequence="19"
<record model="ir.ui.view" id="lista_correos_personas_tree">
<field name="name">lista_correos.personas.tree</field>
<field name="model">lista_correos.personas</field>
<tree string="personas">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
346
<record model="ir.ui.view" id="lista_correos_personas_form">
<field name="name">lista_correos.personas.form</field>
<field name="model">lista_correos.personas</field>
<form string="personas">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="lista_correos_personas_action" model="ir.actions.act_window">
<field name="name">Personas</field>
<field name="res_model">lista_correos.personas</field>
</record>
<menuitem action="lista_correos_personas_action"
id="lista_correos_personas_menu" sequence="20"
parent="lista_correos_prescriptores"/>
<record model="ir.ui.view" id="lista_correos_otros_tree">
<field name="name">lista_correos.otros.tree</field>
347
<field name="model">lista_correos.otros</field>
<tree string="otros">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="lista_correos_otros_form">
<field name="name">lista_correos.otros.form</field>
<field name="model">lista_correos.otros</field>
<form string="otros">
<field name="cif"/>
<field name="cp"/>
348
</form>
</field>
</record>
<record id="lista_correos_otros_action" model="ir.actions.act_window">
<field name="name">Otros</field>
<field name="res_model">lista_correos.otros</field>
</record>
<menuitem action="lista_correos_otros_action"
id="lista_correos_otros_menu" sequence="21"
parent="lista_correos_prescriptores"/>
</data>
</openerp>
349
2. Asociados.
Archivo __init__.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
import asociados
# -*- coding: utf-8 -*-
##############################################################################
350
##############################################################################
"name" : "Asociados",
"version" : "0.1",
"description": """ Módulo para ACLUXEGA para introducir los datos de la

asociación """,
'data': [],
'update_xml': ["asociados.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'active': False,
351
Archivo asociados.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
class asociados_juntadirectiva(osv.osv):
_name = 'asociados.juntadirectiva'
_description = 'Junta directiva'
_columns = {
'cargo': fields.char('Cargo', size=200, required=True),
'nombre': fields.char('Nombre', size=200, required=True),
'telefonoempresa': fields.char('Telf empresa', size=200, required=False),
352
'movil': fields.char('Móvil', size=200, required=False),
'email': fields.char('EMail', size=200, required=False),
'informacion': fields.text('Informacion', required=False),
asociados_juntadirectiva()
class asociados_grupos(osv.osv):
_name = 'asociados.grupos'
_description = 'Grupos de trabajo'
_rac_name='name'
_columns = {
'name': fields.char('Nombre grupo', size=200, required=True),
'coordinador': fields.char('coordinador/a', size=200, required=False),
'correo': fields.char('Correo', size=200, required=False),
'miembrosdelgrupo_id':
fields.one2many('asociados.miembrosgt','name_id','Miembros del grupo'),
'informacion': fields.text('Información', required=False),
asociados_grupos()
class asociados_miembrosgt(osv.osv):
_name = 'asociados.miembrosgt'
_description = 'Miembros gt'
_columns = {
'image': fields.binary("Imagen", help="Seleccio nar imagen aqui"),
'name_id': fields.many2one('asociados.grupos','Grupo', ),
'nombre': fields.char('Nombre', size=150, required=False),
353
'telefonoempresa': fields.char('Telf empresa', size=20, required=False),
'movil': fields.char('Móvil', size=20, required=False),
'email': fields.char('EMail', size=100, required=False),
asociados_miembrosgt()
class asociados_lista(osv.osv):
_name = 'asociados.lista'
_description = 'Lista asociados'
_columns = {
'image': fields.binary("Logo", help="Seleccionar imagen aqui"),
'nombrecliente': fields.char('Nombre', size=200, required=True),
'codigo': fields.char('Código', size=200, required=False),
'numero': fields.char('Número', size=64, required=False),
'fax': fields.char('FAX', size=200, required=False),
'email': fields.char('EMAIL', size=200, required=False),
'contacto': fields.char('Contacto', size=200, required=False),
'web': fields.char('WEB', size=200, required=False),
'altaensello_id': fields.many2one('asociados.altaensello','Alta en sello',

help='Alta en sello calidad instaladoras'),
'concesionsello_id': fields.many2one('asociados.concesionsello','Concesión
sello', help='Sello concedido o no'),
'denegadas_id': fields.many2one('asoc iados.denegadas','Denegado',

help='Sello denegado y motivos'),
354
'altaenselloper_id': fields.many2one('asociados.altaenselloper','Alta en
sello', help='Alta en sello calidad perforación'),
'concesionselloper_id':
fields.many2one('asociados.concesionselloper','Concesión sello', help='Sello
concedido o no'),
'denegadasper_id': fields.many2one('asociados.denegadasper','Denegado',
help='Sello denegado y motivos'),
asociados_lista()
class asociados_clasificacion(osv.osv):
_name = 'asociados.clasificacion'
_description = 'Clasificacion empresas'
_columns = {
'nombre': fields.char('Nombre',size=200, required=True),
'distribuidora': fields.boolean('Distribuidora', required=False),
'ingenieria': fields.boolean('Ingeniería', required=False),
'instaladora': fields.boolean('Instaladora', required=False),
'sondeos': fields.boolean('Sondeos', required=False),
'institucionales': fields.boolean('Institucionales', required=False),
'arquitectura': fields.boolean('Arquitectura', required=False),
'otrasactividades': fields.text('Otras actividades', required=False),
asociados_clasificacion()
class asociados_altas(osv.osv):
_name = 'asociados.altas'
_description = 'Altas'
_columns = {
355
asociados_altas()
class asociados_bajas(osv.osv):
_name = 'asociados.bajas'
_description = 'Bajas'
_columns = {
356
asociados_bajas()
class asociados_variaciones(osv.osv):
_name = 'asociados.variaciones'
_description = 'Variaciones'
_columns = {
asociados_variaciones()
class asociados_otros(osv.osv):
_name = 'asociados.otros'
_description = 'Otros'
_columns = {
357
asociados_otros()
class asociados_ingenierias(osv.osv):
_name = 'asociados.ingenierias'
_description = 'Ingenierias'
_columns = {
asociados_ingenierias()
class asociados_instaladoras(osv.osv):
358
_name = 'asociados.instaladoras'
_description = 'Instaladoras'
_columns = {
asociados_instaladoras()
class asociados_sondeos(osv.osv):
_name = 'asociados.sondeos'
_description = 'Sondeos'
_columns = {
asociados_sondeos()
359
class asociados_distribuidoras(osv.osv):
_name = 'asociados.distribuidoras'
_description = 'Distribuidoras'
_columns = {
asociados_distribuidoras()
class asociados_institucionales(osv.osv):
_name = 'asociados.institucionales'
_description = 'Institucionales'
_columns = {
360
asociados_institucionales()
class asociados_arquitectura(osv.osv):
_name = 'asociados.arquitectura'
_description = 'Arquitectura'
_columns = {
'telefono': fields.char('Teléfon o', size=200, required=False),
asociados_arquitectura()
class asociados_otras(osv.osv):
_name = 'asociados.otras'
_columns = {
361
asociados_otras()
class asociados_altaensello(osv.osv):
_name = 'asociados.altaensello'
_description = 'Alta en sello'
_rac_name='name'
_columns = {
'name': fields.char('Nº entrada', size=200, required=True),
'fechaentrada': fields.date('Fecha entrada', required=False),
'lugarauditoria': fields.char('Lugar auditoría', size=200,

required=False),
'fechaauditoria': fields.datetime('Fecha auditoría', required=False),
'aprobada': fields.boolean('¿Aprobada?', required=False),
'observaciones': fields.text('observaciones', required=False),
asociados_altaensello()
class asociados_concesionsello(osv.osv):
_name = 'asociados.concesionsello'
_description = 'Concesion sello'
_rac_name='name'
_columns = {
'name': fields.char('Nº registro', size=200, required=True),
'fecha': fields.date('Fecha concesión', required=False),
'observaciones': fields.text('Observaciones', required=False) ,
362
asociados_concesionsello()
class asociados_denegadas(osv.osv):
_name = 'asociados.denegadas'
_description = 'Denegadas'
_rac_name='name'
_columns = {
'pendienterevision': fields.boolean('¿Pendiente revisión?',

required=False),
'plazo': fields.char('Plazo de revisión', size=200, required=False),
'observaciones': fields.text('Observaciones', required=False),
asociados_denegadas()
class asociados_altaenselloper(osv.osv):
_name = 'asociados.altaenselloper'
_description = 'Alta en sello'
_rac_name='name'
_columns = {
'name': fields.char('Nº entrada', size=200, req uired=True),
'fechaentrada': fields.date('Fecha entrada', required=False),
'lugarauditoria': fields.char('Lugar auditoría', size=200,

required=False),
'fechaauditoria': fields.datetime('Fecha auditoría', required=False),
'aprobada': fields.boolean('¿Aprobada?', required=False),
'observaciones': fields.text('observaciones', required=False),
asociados_altaenselloper()
363
class asociados_concesionselloper(osv.osv):
_name = 'asociados.concesionselloper'
_description = 'Concesion sello'
_rac_name='name'
_columns = {
'name': fields.char('Nº registro', size=200, required=True),
'fecha': fields.date('Fecha concesión', required=False),
asociados_concesionselloper()
class asociados_denegadasper(osv.osv):
_name = 'asociados.denegadasper'
_description = 'Denegadas'
_rac_name='name'
_columns = {
'pendienterevision': fields.boolean('¿Pendiente revisión?',

required=False),
'plazo': fields.char('Plazo de revisión', size=200, required=False),
asociados_denegadasper()
364
Archivo asociados.xml
<openerp>
<data>
<menuitem name="Asociados" id="asociados" sequence="90"/>
<menuitem name="Organización" id="asociados_organizacion"

parent="asociados"/>
<menuitem name="Información" id="asociados_informacion"

parent="asociados"/>
<menuitem name="Contacto" id="asociados_contacto" parent="asociados" />
<menuitem name="Sello calidad instaladores"

id="asociados_selloinstaladores" parent="asociados" />
<menuitem name="Sello calidad perforación" id="asociados_selloperforacion"

parent="asociados" />
<record model="ir.ui.view" id="custom_juntadirectiva_kanban_view">
<field name="name">asociados.juntadirectiva.kanban</field>
<field name="model">asociados.juntadirectiva</field>
<kanban>
<field name="cargo" />
<templates>
<a type="open">
t-att-
src="kanban_image('asociados.juntadirectiva', 'image', record.id.value)" />
</a>
<h4>
365
<a type="edit">
<field name="cargo"></field>
</a>
</h4>
<ul>
<li><field name="nombre"></field>
</li>
<li><field name="empresa"></field>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="asociados_juntadirectiva_tree">
<field name="name">asociados.juntadirectiva.tree</field>
<tree string="juntadirectiva">
<field name="cargo"/>
<field name="nombre"/>
<field name="telefonoempresa"/>
<field name="movil"/>
</tree>
</field>
</record>
366
<record model="ir.ui.view" id="asociados_juntadirectiva_form">
<field name="name">asociados.juntadirectiva.form</field>
<form string="juntadirectiva">
<group string="Ficha">
<field name="cargo"/>
</group>
<group>
</group>
<newline/>
<field name="informacion" placeholder= "información adicional..."/>
</group>
</form>
</field>
</record>
<record id="asociados_juntadirectiva_action"
<field name="name">Junta directiva</field>
<field name="res_model">asociados.juntadirectiva</field>
<field name="view_mode">kanban,tree,form</field>
</record>
367
<menuitem action="asociados_juntadirectiva_action"
id="asociados_juntadirectiva_menu" sequence="1"
parent="asociados_organizacion"/>
<record model="ir.ui.view" id="custom_grupos_kanban_view">
<field name="name">asociados.grupos.kanban</field>
<field name="model">asociados.grupos</field>
<kanban>
<field name="name" />
<templates>
<a type="open">
t-att-
src="kanban_image('asociados.grupos', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
<field name="name"></field>
</a>
</h4>
<ul>
<li><field name="coordinador"></field>
</li>
<li><field name="telefono"></field>
</li>
</ul>
</div>
</div>
368
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="asociados_grupos_tree">
<field name="name">asociados.grupos.tree</field>
<tree string="grupos">
<field name="name"/>
<field name="coordinador"/>
<field name="correo"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_grupos_form">
<field name="name">asociados.grupos.form</field>
<form string="grupos">
<group string="Ficha">
<field name="coordinador"/>
</group>
<group>
369
<field name="correo"/>
</group>
<newline/>
<field name="miembrosdelgrupo_id"/>
</group>
<newline/>
<field name="informacion" placeholder= "reuniones, decisiones,más

información,etc..."/>
</group>
</form>
</field>
</record>
<record id="asociados_grupos_action" model="ir.actions.act_window">
<field name="name">Grupos de trabajo</field>
<field name="res_model">asociados.grupos</field>
</record>
<menuitem action="asociados_grupos_action" id="asociados_grupos_menu"

sequence="2" parent="asociados_organizacion"/>
<record model="ir.ui.view" id="asociados_miembrosgt_tree">
<field name="name">asociados.miembrosgt.tree</field>
<field name="model">asociados.miembrosgt</field>
<tree string="miembrosgt">
370
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_miembrosgt_form">
<field name="name">asociados.miembrosgt.form</field>
<field name="model">asociados.miembrosgt</field>
<form string="miembrosgt">
<group string="Miembro de grupo">
<field name="name_id"/>
</group>
<group>
</group>
<newline/>
<field name="informacion" placeholder= "información adicional..."/>
</group>
</form>
</field>
</record>
371
<record model="ir.ui.view" id="custom_module_kanban_view">
<field name="name">asociados.lista.kanban</field>
<field name="model">asociados.lista</field>
<kanban>
<field name="nombrecliente" />
<templates>
<a type="open">
t-att-
src="kanban_image('asociados.lista', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
<field
name="nombrecliente"></field>
</a>
</h4>
<ul>
<li><field name="email"></field> </li>
<li><field name="web"></field> </li>
</ul>
</div>
</div>
</t>
</templates>
372
</kanban>
</field>
</record>
<record model="ir.ui.view" id="asociados_lista_tree">
<field name="name">asociados.lista.tree</field>
<tree string="lista">
<field name="nombrecliente"/>
<field name="codigo"/>
<field name="numero"/>
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="contacto"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_lista_form">
<field name="name">asociados.lista.form</field>
<form string="lista">
373
<group string="Datos">
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="web"/>
</group>
<group string="Sello de calidad">
<page string="Instaladores">
<field name="altaensello_id"/>
<field name="concesionsello_id"/>
<field name="denegadas_id"/>
</group>
</page>
<page string="Perforación">
<field name="altaenselloper_id"/>
<field name="concesionselloper_id"/>
<field name="denegadasper_id"/>
</group>
</page>
374
</notebook>
</group>
</form>
</field>
</record>
<record id="asociados_lista_action" model="ir.actions.act_window">
<field name="name">Lista asociados</field>
<field name="res_model">asociados.lista</field>
</record>
<menuitem action="asociados_lista_action" id="asociados_lista_menu"

sequence="4" parent="asociados_informacion"/>
<record model="ir.ui.view" id="asociados_clasificacion_tree">
<field name="name">asociados.clasificacion.tree</field>
<field name="model">asociados.clasificacion</field>
<tree string="clasificacion">
<field name="distribuidora"/>
<field name="ingenieria"/>
<field name="instaladora"/>
<field name="sondeos"/>
<field name="institucionales"/>
<field name="arquitectura"/>
<field name="otrasactividades"/>
</tree>
</field>
</record>
375
<record model="ir.ui.view" id="asociados_clasificacion_form">
<field name="name">asociados.clasificacion.form</field>
<field name="model">asociados.clasificacion</field>
<form string="clasificacion">
<field name="distribuidora"/>
<field name="ingenieria"/>
<field name="instaladora"/>
<field name="sondeos"/>
<field name="institucionales"/>
<field name="arquitectura"/>
<newline/>
<field name="otrasactividades" placeholder= "Otras

actividades..."/>
</group>
</form>
</field>
</record>
<record id="asociados_clasificacion_action" model="ir.actions.act_window">
<field name="name">Clasificacion empresas</field>
<field name="res_model">asociados.clasificacion</field>
</record>
<menuitem action="asociados_clasificacion_action"
id="asociados_clasificacion_menu" sequence="5"
parent="asociados_informacion"/>
376
<record model="ir.ui.view" id="asociados_altas_tree">
<field name="name">asociados.altas.tree</field>
<field name="model">asociados.altas</field>
<tree string="altas">
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_altas_form">
<field name="name">asociados.altas.form</field>
<field name="model">asociados.altas</field>
<form string="altas">
377
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="web"/>
</form>
</field>
</record>
<record id="asociados_altas_action" model="ir.actions.act_window">
<field name="name">Altas</field>
<field name="res_model">asociados.altas</field>
</record>
<menuitem action="asociados_altas_action" id="asociados_altas_menu"

<record model="ir.ui.view" id="asociados_bajas_tree">
<field name="name">asociados.bajas.tree</field>
<field name="model">asociados.bajas</field>
<tree string="bajas">
378
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_bajas_form">
<field name="name">asociados.bajas.form</field>
<field name="model">asociados. bajas</field>
<form string="bajas">
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
379
<field name="web"/>
</form>
</field>
</record>
<record id="asociados_bajas_action" model="ir.actions.act_window">
<field name="name">Bajas</field>
<field name="res_model">asociados.bajas< /field>
</record>
<menuitem action="asociados_bajas_action" id="asociados_bajas_menu"

<record model="ir.ui.view" id="asociados_variaciones_tree">
<field name="name">asociados.variaciones.tree</field>
<field name="model">asociados.variaciones</field>
<tree string="variaciones">
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
380
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_variaciones_form">
<field name="name">asociados.variaciones.form</field>
<field name="model">asociados.variaciones</field>
<form string="variaciones">
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="web"/>
</form>
</field>
</record>
<record id="asociados_variaciones_action" model="ir.actions.act_window">
<field name="name">Variaciones</field>
<field name="res_model">asociados.variaciones</field>
381
</record>
<menuitem action="asociados_variaciones_action"
id="asociados_variaciones_menu" sequence="8" parent="asociados_informacion"/>
<record model="ir.ui.view" id="asociados_otros_tree">
<field name="name">asociados.otros.tree</field>
<field name="model">asociados.otros</field>
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_otros_form">
<field name="name">asociados.otros.form</field>
<field name="model">asociados.otros</field>
382
<field name="cp"/>
<field name="cif"/>
<field name="fax"/>
<field name="web"/>
</form>
</field>
</record>
<record id="asociados_otros_action" model="ir.actions.act_window">
<field name="res_model">asociados.otros</field>
</record>
<menuitem action="asociados_otros_action" id="asociados_otros_menu"

sequence="9" parent="asociados_ informacion"/>
<record model="ir.ui.view" id="asociados_ingenierias_tree">
<field name="name">asociados.ingenierias.tree</field>
<field name="model">asociados.ingenierias</field>
383
<tree string="ingenierias">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_ingenierias_form">
<field name="name">asociados.ingenierias.form</field>
<field name="model">asociados.ingenierias</field>
<form string="ingenierias">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
384
</record>
<record id="asociados_ingenierias_action" model="ir.actions.act_window">
<field name="name">Ingenierias</field>
<field name="res_model">asociados.ingenierias</field>
</record>
<menuitem action="asociados_ingenierias_action"
id="asociados_ingenierias_menu" sequence="10" parent="asociados_contacto"/>
<record model="ir.ui.view" id="asociados_instaladoras_tree">
<field name="name">asociados.instaladoras.tree</field>
<field name="model">asociados.instaladoras</field>
<tree string="instaladoras">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_instaladoras_form">
<field name="name">asociados.instaladoras.form</field>
385
<field name="model">asociados.instaladoras</field>
<form string="instaladoras">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="asociados_instaladoras_action" model="ir.actions.act_window">
<field name="name">Instaladoras</field>
<field name="res_model">asociados.instaladoras</field>
</record>
<menuitem action="asociados_instaladoras_action"
id="asociados_instaladoras_menu" sequence="11" parent="asociados_contacto"/>
<record model="ir.ui.view" id="asociados_sondeos_tree">
<field name="name">asociados.sondeos.tree</field>
<field name="model">asociados.sondeos</field>
<tree string="sondeos">
386
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_sondeos_form">
<field name="name">asociados.sondeos.form</field>
<field name="model">asociados.sondeos</field>
<form string="sondeos">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
387
<record id="asociados_sondeos_action" model="ir.actions.act_window">
<field name="name">Sondeos</field>
<field name="res_model">asociados.sondeos</field>
</record>
<menuitem action="asociados_sondeos_action" id="asociados_sondeos_menu"

sequence="12" parent="asociados_contacto"/>
<record model="ir.ui.view" id="asociados_distribuidoras_tree">
<field name="name">asociados.distribuidoras.tree</field>
<field name="model">asociados.distribuidoras</field>
<tree string="distribuidoras">
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_distribuidoras_form">
<field name="name">asociados.distribuidoras.form</field>
<field name="model">asociados.distribuidoras</field>
388
<form string="distribuidoras">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="asociados_distribuidoras_action"
<field name="name">Distribuidoras</field>
<field name="res_model">asociados.distribuidoras</field>
</record>
<menuitem action="asociados_distribuidoras_action"
id="asociados_distribuidoras_menu" sequence="13" parent="asociados_contacto"/>
<record model="ir.ui.view" id="asociados_arquitectura_tree">
<field name="name">asociados.arquitectura.tree</field>
<field name="model">asociados.arquitectura</field>
<tree string="arquitectura">
389
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_arquitectura_form">
<field name="name">asociados.arquitectura.form</field>
<field name="model">asociados.arquitectura</field>
<form string="arquitectura">
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="asociados_arquitectura_action" model="ir.actions.act_window">
390
<field name="name">Arquitectura</field>
<field name="res_model">asociados.arquitectura</field>
</record>
<menuitem action="asociados_arquitectura_action"
id="asociados_arquitectura_menu" sequence="14" parent="asociados_contacto"/>
<record model="ir.ui.view" id="asociados_otras_tree">
<field name="name">asociados.otras.tree</field>
<field name="model">asociados.otras</field>
<field name="cif"/>
<field name="cp"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_otras_form">
<field name="name">asociados.otras.form</field>
<field name="model">asociados.otras</field>
391
<field name="cif"/>
<field name="cp"/>
</form>
</field>
</record>
<record id="asociados_otras_action" model="ir.actions.act_window">
<field name="res_model">asociados.otras</field>
</record>
<menuitem action="asociados_otras_action" id="asociados_otras_menu"

sequence="15" parent="asociados_contacto"/>
<record model="ir.ui.view" id="asociados_altaensello_tree">
<field name="name">asociados.altaensello.tree</field>
<field name="model">asociados.altaensello</field>
<tree string="altaensello">
<field name="fechaentrada"/>
<field name="lugarauditoria"/>
392
<field name="fechaauditoria"/>
<field name="aprobada"/>
<field name="observaciones"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_altaensello_form">
<field name="name">asociados.altaensello.form</field>
<field name="model">asociados.altaensello</field>
<form string="altaensello">
</form>
</field>
</record>
<record id="asociados_altaensello_action" model="ir.actions.act_window">
<field name="name">Alta en sello</field>
<field name="res_model">asociados.altaensello</field>
</record>
<menuitem action="asociados_altaensello_action"
id="asociados_altaensello_menu" sequence="16"
parent="asociados_selloinstaladores"/>
393
<record model="ir.ui.view" id="asociados_concesionsello_tree">
<field name="name">asociados.concesionsello.tree</field>
<field name="model">asociados.concesionsello</field>
<tree string="concesionsello">
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_concesionsello_form">
<field name="name">asociados.concesionsello.form</field>
<field name="model">asociados.concesionsello</field>
<form string="concesionsello">
</form>
</field>
</record>
<record id="asociados_concesionsello_action"
<field name="name">Concesion sello</field>
<field name="res_model">asociados.concesionsello</field>
394
</record>
<menuitem action="asociados_concesionsello_action"
id="asociados_concesionsello_menu" sequence="17"
<record model="ir.ui.view" id="asociados_denegadas_tree">
<field name="name">asociados.denegadas.tree</field>
<field name="model">asociados.denegadas</field>
<tree string="denegadas">
<field name="pendienterevision"/>
<field name="plazo"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_denegadas_form">
<field name="name">asociados.denegadas.form</field>
<field name="model">asociados.denegadas</field>
<form string="denegadas">
395
</form>
</field>
</record>
<record id="asociados_denegadas_action" model="ir.actions.act_window">
<field name="name">Denegadas</field>
<field name="res_model">asociados.denegadas</field>
</record>
<menuitem action="asociados_denegadas_action"
id="asociados_denegadas_menu" sequence="18"
<record model="ir.ui.view" id="asociados_altaenselloper_tree">
<field name="name">asociados.altaenselloper.tree</field>
<field name="model">asociados.altaenselloper</field>
<tree string="altaenselloper">
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_altaenselloper_form">
396
<field name="name">asociados.altaenselloper.form</field>
<field name="model">asociados.altaenselloper</field>
<form string="altaenselloper">
</form>
</field>
</record>
<record id="asociados_altaenselloper_action"
<field name="name">Alta en sello</field>
<field name="res_model">asociados.altaenselloper</field>
</record>
<menuitem action="asociados_altaenselloper_action"
id="asociados_altaenselloper_menu" sequence="19"
parent="asociados_selloperforacion"/>
<record model="ir.ui.view" id="asociados_concesionselloper_tree">
<field name="name">asociados.concesionselloper.tree</field>
<field name="model">asociados.concesionselloper</field>
<tree string="concesionselloper">
397
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_concesionselloper_form">
<field name="name">asociados.concesionselloper.form</field>
<field name="model">asociados.concesionselloper</field>
<form string="concesionselloper">
</form>
</field>
</record>
<record id="asociados_concesionselloper_action"
<field name="name">Concesion sello</field>
<field name="res_model">asociados.concesionselloper</field>
</record>
<menuitem action="asociados_concesionselloper_action"
id="asociados_concesionselloper_menu" sequence="20"
<record model="ir.ui.view" id="asociados_denegadasper_tree">
398
<field name="name">asociados.denegadasper.tree</field>
<field name="model">asociados.deneg adasper</field>
<tree string="denegadasper">
</tree>
</field>
</record>
<record model="ir.ui.view" id="asociados_denegadasper_form">
<field name="name">asociados.denegadasper.form</field>
<field name="model">asociados.denegadasper</field>
<form string="denegadasper">
</form>
</field>
</record>
<record id="asociados_denegadasper_action" model="ir.actions.act_window">
<field name="name">Denegadas</field>
<field name="res_model">asociados.denegadasper</field>
399
</record>
<menuitem action="asociados_denegadasper_action"
id="asociados_denegadasper_menu" sequence="21"
</data>
</openerp>
400
3. Legislación.
Archivo __init__.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
import legislación
# -*- coding: utf-8 -*-
##############################################################################
401
##############################################################################
"name" : "Legislación",
"version" : "0.1",
"description": """Módulo con el objetivo de recopilar legislación,creado en

ACLUXEGA """,
'data': [],
'update_xml': ["legislacion.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'active': False,
402
Archivo legislacion.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
class legislacion_galicia(osv.osv):
_name = 'legislacion.galicia'
_columns = {
'directiva': fields.char('Directiva', size=400, required=True),
'modificada': fields.boolean('Modificada', required=False),
'nuevadirectiva': fields.char('Nueva', size=400, required=False),
'derogada': fields.boolean('Derogada', required=False),
403
'resumen': fields.text('Resumen', required=False),
'contenido': fields.text('Contenido', required=False),
legislacion_galicia()
class legislacion_comunidadautonoma(osv.osv):
_name = 'legislacion.comunidadautonoma'
_description = 'Comunidad autonoma'
_columns = {
'image': fields.binary("Bandera", help="Seleccionar imagen aqui"),
'comunidad': fields.char('Comunidad', size=200, required=True),
legislacion_comunidadautonoma()
class legislacion_estado(osv.osv):
_name = 'legislacion.estado'
_description = 'Estado'
_columns = {
404
legislacion_estado()
class legislacion_unioneuropea(osv.osv):
_name = 'legislacion.unioneuropea'
_description = 'Union Europea'
_columns = {
legislacion_unioneuropea()
class legislacion_galiciaer(osv.osv):
_name = 'legislacion.galiciaer'
_columns = {
405
legislacion_galiciaer()
class legislacion_comunidadautonomaer(osv.osv):
_name = 'legislacion.comunidadautonomaer'
_description = 'Comunidad autonomaer'
_columns = {
legislacion_comunidadautonomaer()
class legislacion_estadoer(osv.osv):
_name = 'legislacion.estadoer'
_columns = {
406
legislacion_estadoer()
class legislacion_unioneuropeaer(osv.osv):
_name = 'legislacion.unioneuropeaer'
_columns = {
legislacion_unioneuropeaer()
class legislacion_galiciaot(osv.osv):
_name = 'legislacion.galiciaot'
_columns = {
407
legislacion_galiciaot()
class legislacion_comunidadautonomaot(osv.osv):
_name = 'legislacion.comunidadautonomaot'
_description = 'Comunidad autonoma'
_columns = {
legislacion_comunidadautonomaot()
class legislacion_estadoot(osv.osv):
_name = 'legislacion.estadoot'
_columns = {
408
legislacion_estadoot()
class legislacion_unioneuropeaot(osv.osv):
_name = 'legislacion.unioneuropeaot'
_columns = {
legislacion_unioneuropeaot()
Archivo legislacion.xml
<openerp>
<data>
<menuitem name="Legislación" id="legislacion_menu" sequence="90"/>
<menuitem name="Geotermia" id="geotermia_menu" parent="legislacion_menu"/>
<menuitem name="Energías renovables" id="energiasrenovables_menu"

parent="legislacion_menu"/>
<menuitem name="Varias" id="varias_menu" parent="legislacion_menu"/>
<record model="ir.ui.view" id="legislacion_galicia_tree">
<field name="name">legislacion.galicia.tree</field>
<field name="model">legislacion.galicia</field>
<tree string="galicia">
<field name="directiva"/>
409
<field name="modificada"/>
<field name="derogada"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_galicia_form">
<field name="name">legislacion.galicia.form</field>
<field name="model">legislacion.galicia</field>
<form string="galicia">
<group>
<field name="nuevadirectiva" placeholder="Directiva que modifica o

sustituye..."/>
</group>
<group>
</group>
<newline/>
<separator string="Normativa" colspan="4"/>
<page string="Resumen">
<field name="resumen"/>
</group>
</page>
<page string="Contenido">
410
<field name="contenido"/>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_galicia_action" model="ir.actions.act_window">
<field name="res_model">legislacion.galicia</field>
</record>
<menuitem action="legislacion_galicia_action"
id="legislacion_galicia_menu" sequence="1" parent="geotermia_menu"/>
<record model="ir.ui.view" id="custom_comunidad_kanban_view">
<field name="name">legislacion.comunidadautonoma.kanban</field>
<field name="model">legislacion.comunidadautonoma</field>
<kanban>
<field name="comunidad" />
<templates>
<a type="open">
411
t-att-
src="kanban_image('legislacion.comunidadautonoma', 'image', record.id.value)"
/>
</a>
<h4>
<a type="edit">
<field name="comunidad"></field>
</a>
</h4>
<ul>
<li><field name="directiva"></field>
</li>
<li><field name="fuente"></field>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="legislacion_comunidadautonoma_tree">
<field name="name">legislacion.comunidadautonoma.tree</field>
<tree string="comunidadautonoma">
<field name="comunidad"/>
412
</tree>
</field>
</record>
<record model="ir.ui.view" id="legisl acion_comunidadautonoma_form">
<field name="name">legislacion.comunidadautonoma.form</field>
<form string="comunidadautonoma">
<group>

sustituye..."/>
</group>
<group>
</group>
<newline/>
</group>
</page>
413
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_comunidadautonoma_action"
<field name="name">Comunidad autonoma</field>
<field name="res_model">legislacion.comunidadautonoma</field>
</record>
<menuitem action="legislacion_comunidadautonoma_action"
id="legislacion_comunidadautonoma_menu" sequence="2" parent="geotermia_menu"/>
<record model="ir.ui.view" id="legislacion_estado_tree">
<field name="name">legislacion.estado.tree</field>
<field name="model">legislacion.estado</field>
<tree string="estado">
</tree>
</field>
</record>
414
<record model="ir.ui.view" id="legislacion_estado_form">
<field name="name">legislacion.estado.form</field>
<field name="model">legislacion.estado</field>
<form string="estado">
<group>

sustituye..."/>
</group>
<group>
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
415
<record id="legislacion_estado_action" model="ir.actions.act_window">
<field name="name">Estado</field>
<field name="res_model">legislacion.estado</field>
</record>
<menuitem action="legislacion_estado_action" id="legislacion_estado_menu"

sequence="3" parent="geotermia_menu"/>
<record model="ir.ui.view" id="legislacion_unioneuropea_tree">
<field name="name">legislacion.unioneuropea.tree</field>
<field name="model">legislacion.unioneuropea</field>
<tree string="unioneuropea">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_unioneuropea_form">
<field name="name">legislacion.unioneuropea.form</field>
<field name="model">legislacion.unioneuropea</field>
<form string="unioneuropea">
<group>
416

sustituye..."/>
</group>
<group>
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_unioneur opea_action"

<field name="name">Union europea</field>
<field name="res_model">legislacion.unioneuropea</field>
</record>
417
<menuitem action="legislacion_unioneuropea_action"
id="legislacion_unioneuropea_menu" sequence="4" parent="geotermia_menu"/>
<record model="ir.ui.view" id="legislacion_galiciaer_tree">
<field name="name">legislacion.galiciaer.tree</field>
<field name="model">legislacion.galiciaer</field>
<tree string="galiciaer">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_galiciaer_form">
<field name="name">legislacion.galiciaer.form</field>
<field name="model">legislacion.galiciaer</field>
<form string="galiciaer">
<group>

sustituye..."/>
</group>
<group>
418
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_galiciaer_action" model="ir.actions.act_window">
<field name="res_model">legislacion.galiciaer</field>
</record>
<menuitem action="legislacion_galiciaer_action"
id="legislacion_galiciaer_menu" sequence="5"
parent="energiasrenovables_menu"/>
<record model="ir.ui.view" id="custom_autonoma_kanban_view">
<field name="name">legislacion.comunidadautonomaer.kanban</field>
<field name="model">legislacion.comunidadautonomaer</field>
419
<kanban>
<templates>
<a type="open">
t-att-
src="kanban_image('legislacion.comunidadautonomaer', 'image',
record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
420
<record model="ir.ui.view" id="legislacion_comunidadautonomaer_tree">
<field name="name">legislacion.comunidadautonomaer.tree</field>
<tree string="comunidadautonomaer">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_comunidadautonomaer_form">
<field name="name">legislacion.comunidadautonomaer.form</field>
<form string="comunidadautonomaer">
<group>

sustituye..."/>
</group>
<group>
421
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_comunidadautonomaer_action"
<field name="res_model">legislacion.comunidadautonomaer</field>
</record>
<menuitem action="legislacion_comunidadautonomaer_action"
id="legislacion_comunidadautonomaer_menu" sequence="6"
<record model="ir.ui.view" id="legislacion_estadoer_tree">
<field name="name">legislacion.estadoer.tree</field>
<field name="model">legislacion.estadoer</field>
422
<tree string="estadoer">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_estadoer_form">
<field name="name">legislacion.estadoer.form</field>
<field name="model">legislacion.estadoer</field>
<form string="estadoer">
<group>

sustituye..."/>
</group>
<group>
</group>
<newline/>
423
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_estadoer_action" model="ir.actions.act_window">
<field name="res_model">legislacion.estadoer</field>
</record>
<menuitem action="legislacion_estadoer_action"
id="legislacion_estadoer_menu" sequence="7" parent="energiasrenovables_menu"/>
<record model="ir.ui.view" id="legislacion_unioneuropeaer_tree">
<field name="name">legislacion.unioneuropeaer.tree</field>
<field name="model">legislacion.unioneuropeaer</field>
<tree string="unioneuropeaer">
</tree>
424
</field>
</record>
<record model="ir.ui.view" id="legislacion_unioneuropeaer_form">
<field name="name">legislacion.unioneuropeaer.form</field>
<field name="model">legislacion.unioneuropeaer</field>
<form string="unioneuropeaer">
<group>

sustituye..."/>
</group>
<group>
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
425
</form>
</field>
</record>
<record id="legislacion_unioneuropeaer_action"
<field name="res_model">legislacion.unioneuropeaer</field>
</record>
<menuitem action="legislacion_unioneuropeaer_action"
id="legislacion_unioneuropeaer_menu" sequence="8"
<record model="ir.ui.view" id="legislacion_galiciaot_tree">
<field name="name">legislacion.galiciaot.tree</field>
<field name="model">legislacion.galiciaot</field>
<tree string="galiciaot">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_galiciaot_form">
<field name="name">legislacion.galiciaot.form</field>
<field name="model">legislacion.galiciaot</field>
426
<form string="galiciaot">
<group>

sustituye..."/>
</group>
<group>
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_galiciaot_action" model="ir.actions.act_window">
<field name="res_model">legislacion.galiciaot</field>
427
</record>
<menuitem action="legislacion_galiciaot_action"
id="legislacion_galiciaot_menu" sequence="9" parent="varias_menu"/>
<record model="ir.ui.view" id="custom_module_kanban_view">
<field name="name">legislacion.comunidadautonomaot.kanban</field>
<field name="model">legislacion.comunidadautonomaot</field>
<kanban>
<templates>
<a type="open">
t-att-
src="kanban_image('legislacion.comunidadautonomaot', 'image',
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
428
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="legislacion_comunidadautonomaot_tree">
<field name="name">legislacion.comunidadautonomaot.tree</field>
<tree string="comunidadautonomaot">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_comunidadautonomaot_form">
<field name="name">legislacion.comunidadautonomaot.form</field>
<form string="comunidadautonomaot">
<group>
429

sustituye..."/>
</group>
<group>
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_comunidadautonomaot_action"
<field name="res_model">legislacion.comunidadautonomaot</field>
430
<field name="view_mode">kanban,tree,form </field>
</record>
<menuitem action="legislacion_comunidadautonomaot_action"
id="legislacion_comunidadautonomaot_menu" sequence="10" parent="varias_menu"/>
<record model="ir.ui.view" id="legislacion_estadoot_tree">
<field name="name">legislacion.estadoot.tree</field>
<field name="model">legislacion.estadoot</field>
<tree string="estadoot">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_estadoot_form">
<field name="name">legislacion.estadoot.form</field>
<field name="model">legislacion.estadoot</field>
<form string="estadoot">
<group>

sustituye..."/>
</group>
431
<group>
</group>
<newline/>
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_estadoot_acti on" model="ir.actions.act_window">
<field name="res_model">legislacion.estadoot</field>
</record>
<menuitem action="legislacion_estadoot_action"
id="legislacion_estadoot_menu" sequence="11" parent="varias_menu"/>
<record model="ir.ui.view" id="legislacion_unioneuropeaot_tree">
432
<field name="name">legislacion.unioneuropeaot.tree</field>
<field name="model">legislacion.unioneuropeaot</field>
<tree string="unioneuropeaot">
</tree>
</field>
</record>
<record model="ir.ui.view" id="legislacion_unioneuropeaot_form">
<field name="name">legislacion.unioneuropeaot.form</field>
<field name="model">legislacion.unioneuropeaot</field>
<form string="unioneuropeaot">
<group>

sustituye..."/>
</group>
<group>
</group>
<newline/>
433
</group>
</page>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="legislacion_uni oneuropeaot_action"

<field name="res_model">legislacion.unioneuropeaot</field>
</record>
<menuitem action="legislacion_unioneuropeaot_action"
id="legislacion_unioneuropeaot_menu" sequence="12" parent="varias_menu"/>
</data>
</openerp>
434
4. Subvenciones.
Archivo __init__.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
import subvenciones
# -*- coding: utf-8 -*-
##############################################################################
435
##############################################################################
"name" : "Subvenciones",
"version" : "0.1",
"author" : "Fernando vazquez Novoa",
"description": """Modulo para acluxega de subvenciones """,
'data': [],
'update_xml': ["subvenciones.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'active': False,
436
Archivo subvenciones.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
class subvenciones_geotermia(osv.osv):
_name = 'subvenciones.geotermia'
_description = 'Geotermia'
_columns = {
'lugar': fields.char('Lugar', size=200, required=True),
'fecha': fields.date('Fecha', size=200, required=False),
'institucion': fields.char('Institución', size=200, required= False),
'privada': fields.boolean('¿Privada?', required=False),
437
'nboletin': fields.char('Nº boletín', size=200, required=False),
'nombre': fields.char('Orden/Directiva', size=400, required=False),
'nombreuno': fields.char('Ord', size=400, required=False),
'nombredos': fields.char('Ord', size=400, required=False),
'beneficiarios': fields.text('Información', size=400, required=False),
'fondostotales': fields.char('Fondos totales', size=400, required=False),
'fondossubvencionados': fields.char('Fondos subvencionados', size=400,

required=False),
'fondosaportados': fields.char('Fondos aportados', size=400,

required=False),
'fondosgeotermia': fields.char('Fondos a geotermia', size=400,

required=False),
'inversionreal': fields.char('Inversión real', size=400, required=False),
'otrosimportes': fields.char('Otros importes', size=400, required=False),
subvenciones_geotermia()
class subvenciones_renovables(osv.osv):
_name = 'subvenciones.renovables'
_description = 'Renovables'
_columns = {
'institucion': fields.char('Institución', size=200, required=False),
438

required=False),

required=False),

required=False),
subvenciones_renovables()
class subvenciones_energia(osv.osv):
_name = 'subvenciones.energia'
_description = 'Energia'
_columns = {

required=False),

required=False),
'fondosgeotermia': fields.char('Fondo s a geotermia', size=400,

required=False),
439
subvenciones_energia()
class subvenciones_otras(osv.osv):
_name = 'subvenciones.otras'
_columns = {
'lugar': fields.char('Lugar', size=200, require d=True),

required=False),

required=False),

required=False),
subvenciones_otras()
440
class subvenciones_unioneuropea(osv.osv):
_name = 'subvenciones.unioneuropea'
_description = 'Union europea'
_columns = {
'tipo': fields.char('Tipo', size=200, required=False),

required=False),

required=False),

required=False),
'resumen': fields.text('Resumen', req uired=False),
subvenciones_unioneuropea()
class subvenciones_otra(osv.osv):
_name = 'subvenciones.otra'
_columns = {
441
'nombreuno': fields.char('', size=400, required=False),
'nombredos': fields.char('', size=400, required=False),
'beneficiarios': fields.text('', size=400, required=False),

required=False),

required=False),

required=False),
'resumen': fields.text('', required=False),
subvenciones_otra()
class subvenciones_cursos(osv.osv):
_name = 'subvenciones.cursos'
_description = 'Cursos'
_columns = {
'nombreuno': fields.char('Ord', size=400, requi red=False),
442

required=False),

required=False),

required=False),
subvenciones_cursos()
class subvenciones_congresos(osv.osv):
_name = 'subvenciones.congresos'
_description = 'Congresos'
_columns = {

required=False),

required=False),
443

required=False),
subvenciones_congresos()
class subvenciones_material(osv.osv):
_name = 'subvenciones.material'
_description = 'Material'
_columns = {

required=False),

required=False),

required=False),
444
subvenciones_material()
class subvenciones_difusion(osv.osv):
_name = 'subvenciones.difusion'
_description = 'Difusion'
_columns = {

required=False),

required=False),
'fondosgeotermia': fields.char('Fondo s a geotermia', size=400,

required=False),
subvenciones_difusion()
class subvenciones_personal(osv.osv):
_name = 'subvenciones.personal'
_description = 'Personal'
445
_columns = {

required=False),

required=False),

required=False),
subvenciones_personal()
class subvenciones_otros(osv.osv):
_name = 'subvenciones.otros'
_columns = {
446

required=False),

required=False),

required=False),
subvenciones_otros()
class subvenciones_pedidas(osv.osv):
_name = 'subvenciones.pedidas'
_description = 'Pedidas'
_columns = {
447

required=False),

required=False),

required=False),
subvenciones_pedidas()
class subvenciones_aceptadaspendientes(osv.osv):
_name = 'subvenciones.aceptadaspendientes'
_description = 'Aceptadas pendientes'
_columns = {

required=False),

required=False),

required=False),
448
subvenciones_aceptadaspendientes()
class subvenciones_recibidas(osv.osv):
_name = 'subvenciones.recibidas'
_description = 'Recibidas'
_columns = {
'beneficiarios': fields.text('Información', size=400, required=Fal se),

required=False),

required=False),

required=False),
subvenciones_recibidas()
449
class subvenciones_otro(osv.osv):
_name = 'subvenciones.otro'
_columns = {

required=False),

required=False),

required=False),
subvenciones_otro()
450
Archivo subvenciones.xml
<openerp>
<data>
<menuitem name="Subvenciones" id="subvenciones" sequence="90"/>
<menuitem name="Subvenciones estatales"

id="subvenciones_subvenciones_estatales" parent="subvenciones"/>
<menuitem name="Subvenciones extranjeras"

id="subvenciones_subvenciones_extranjeras" parent="subvenciones" />
<menuitem name="Ayudas y becas" id="subvenciones_ayudasybecas"

parent="subvenciones" />
<menuitem name="Subenciones interes"

id="subvenciones_subvenciones_interes" parent="subvenciones" />
<record model="ir.ui.view" id="custom_geotermia_kanban_view">
<field name="name">subvenciones.geotermia.kanban</field>
<field name="model">subvenciones.geotermia</field>
<kanban>
<field name="lugar" />
<templates>
<a type="open">
t-att-
src="kanban_image('subvenciones.geotermia', 'i mage', record.id.value)" />
</a>
<h4>
<a type="edit">
451
<field name="lugar"></field>
</a>
</h4>
<ul>
<li><field name="fecha"></field> </li>
<li><field name="institucion"></field>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_geotermia_tree">
<field name="name">subvenciones.geotermia.tree</field>
<tree string="geotermia">
<field name="lugar"/>
<field name="institucion"/>
<field name="privada"/>
<field name="nboletin"/>
<field name="beneficiarios"/>
<field name="fondostotales"/>
<field name="fondossubvencionados"/>
<field name="fondosaportados"/>
<field name="fondosgeotermia"/>
452
<field name="inversionreal"/>
<field name="otrosimportes"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_geotermia_form">
<field name="name">subvenciones.geotermia.form</field>
<form string="geotermia">
<group string="Entidad">
<field name="image" widget='image'/>
<field name="nombreuno"/>
<field name="nombredos"/>
<field name="beneficiarios" placeholder= "beneficiarios..."/>
</group>
<group string="Cuantías">
</group>
453
<newline/>
<group string="Resumen" colspan="2" col="1">
</group>
</form>
</field>
</record>
<record id="subvenciones_geotermia_action" model="ir.actions.act_window">
<field name="name">Geotermia</field>
<field name="res_model">subvenciones.geotermia</field>
</record>
<menuitem action="subvenciones_geotermia_action"
id="subvenciones_geotermia_menu" sequence="1"
parent="subvenciones_subvenciones_estatales"/>
<record model="ir.ui.view" id="custom_renovables_kanban_view">
<field name="name">subvenciones.renovables.kanban</field>
<field name="model">subvenciones.renovables</field>
<kanban>
<templates>
<a type="open">
454
t-att-
src="kanban_image('subvenciones.renovables', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_renovables_tree">
<field name="name">subvenciones.renovables.tree</field>
<tree string="renovables">
455
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_renovables_form">
<field name="name">subvenciones.renovables.form</field>
<form string="renovables">
</group>
456
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_renovables_action" model="ir.actions.act_window">
<field name="name">Renovables</field>
<field name="res_model">subvenciones.renovables</field>
</record>
<menuitem action="subvenciones_renovables_action"
id="subvenciones_renovables_menu" sequence="2"
<record model="ir.ui.view" id="custom_energia_kanban_view">
<field name="name">subvenciones.energia.kanban</field>
<field name="model">subvenciones.energia</field>
<kanban>
457
<templates>
<a type="open">
t-att-
src="kanban_image('subvenciones.energia', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_energia_tree">
<field name="name">subvenciones.energia.tree</field>
458
<tree string="energia">
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_energia_form">
<field name="name">subvenciones.energia.form</field>
<form string="energia">
459
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_energia_action" model="ir.actions.act_window">
<field name="name">Energia</field>
<field name="res_model">subvenciones.energia</field>
</record>
<menuitem action="subvenciones_energia_action"
id="subvenciones_energia_menu" sequence="3"
<record model="ir.ui.view" id="custom_otras_kanban_view">
<field name="name">subvenciones.otras.kanban </field>
460
<field name="model">subvenciones.otras</field>
<kanban>
<templates>
<a type="open">
t-att-
src="kanban_image('subvenciones.otras', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
461
<record model="ir.ui.view" id="subvenciones_otras_tree">
<field name="name">subvenciones.otras.tree</field>
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_otras_form">
<field name="name">subvenciones.otras.form</field>
462
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_otras_action" model="ir.actions.act_window">
<field name="res_model">subvenciones.otras</field>
</record>
463
<menuitem action="subvenciones_otras_action" id="subvenciones_otras_menu"

sequence="4" parent="subvenciones_subvenciones_estatales"/>
<record model="ir.ui.view" id="subvenciones_unioneuropea_tree">
<field name="name">subvenciones.unioneuropea.tree</field>
<field name="model">subvenciones.unioneuropea</field>
<tree string="unioneuropea">
<field name="tipo"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_unioneuropea_form">
<field name="name">subvenciones.unioneuropea.form</field>
<field name="model">subvenciones.unioneuropea</field>
464
<form string="unioneuropea">
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_unioneuropea_action"
<field name="res_model">subvenciones.unioneuropea</field>
465
</record>
<menuitem action="subvenciones_unioneuropea_action"
id="subvenciones_unioneuropea_menu" sequence="5"
parent="subvenciones_subvenciones_extranjeras"/>
<record model="ir.ui.view" id="subvenciones_otra_tree">
<field name="name">subvenciones.otra.tree</field>
<field name="model">subvenciones.otra</field>
<tree string="otra">
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_otra_form">
466
<field name="name">subvenciones.otra.form</field>
<field name="model">subvenciones.otra</field>
<form string="otra">
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
467
<record id="subvenciones_otra_action" model="ir.actions.act_window">
<field name="name">Otra</field>
<field name="res_model">subvenciones.otra</field>
</record>
<menuitem action="subvenciones_otra_action" id="subvenciones_otra_menu"

sequence="6" parent="subvenciones_subvenciones_extranjeras"/>
<record model="ir.ui.view" id="subvenciones_cursos_tree">
<field name="name">subvenciones.cursos.tree</field >
<field name="model">subvenciones.cursos</field>
<tree string="cursos">
</tree>
</field>
468
</record>
<record model="ir.ui.view" id="subvenciones_cursos_form">
<field name="name">subvenciones.cursos.form</field>
<field name="model">subvenciones.cursos</field>
<form string="cursos">
</group>
</group>
<newline/>
</group>
469
</form>
</field>
</record>
<record id="subvenciones_cursos_action" model="ir.actions.act_window">
<field name="name">Cursos</field>
<field name="res_model">subvenciones.cursos</field>
</record>
<menuitem action="subvenciones_cursos_action"
id="subvenciones_cursos_menu" sequence="7"
parent="subvenciones_ayudasybecas"/>
<record model="ir.ui.view" id="subvenciones_congresos_tree">
<field name="name">subvenciones.congresos.tree</field>
<field name="model">subvenciones.congresos</field>
<tree string="congresos">
470
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_congresos_form">
<field name="name">subvenciones.congresos.form</field>
<field name="model">subvenciones.congresos</field>
<form string="congresos">
</group>
</group>
471
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_congresos_action" model="ir.actions.act_window">
<field name="name">Congresos</field>
<field name="res_model">subvenciones.congresos</field>
<field name="view_mode">tree,f orm</field>
</record>
<menuitem action="subvenciones_congresos_action"
id="subvenciones_congresos_menu" sequence="8"
<record model="ir.ui.view" id="subvenciones_material_tree">
<field name="name">subvenciones.material.tree</field>
<field name="model">subvenciones.material</field>
<tree string="material">
472
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_material_form">
<field name="name">subvenciones.material.form</field>
<field name="model">subvenciones.material</field>
<form string="material">
</group>
473
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_material_action" model="ir.actions.act_window">
<field name="name">Material</field>
<field name="res_model">subvenciones.material</field>
</record>
<menuitem action="subvenciones_material_action"
id="subvenciones_material_menu" sequence="9"
<record model="ir.ui.view" id="subvenciones_difusion_tree">
<field name="name">subvenciones.difusion.tree</field>
<field name="model">subvenciones.difusion</field>
<tree string="difusion">
474
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_difusion_form">
<field name="name">subvenciones.difusion.form</field>
<field name="model">subvenciones.difusion</field>
<form string="difusion">
</group>
475
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_difusion_action" model="ir.actions.act_window">
<field name="name">Difusion</field>
<field name="res_model">subvenciones.difusion</field>
</record>
<menuitem action="subvenciones_difusion_action"
id="subvenciones_difusion_menu" sequence="10"
<record model="ir.ui.view" id="subvenciones_personal_tree">
<field name="name">subvenciones.personal.tree</field>
<field name="model">subvenciones.personal</field>
<tree string="personal">
476
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_personal_form">
<field name="name">subvenciones.personal.form</field>
<field name="model">subvenciones.personal</field>
<form string="personal">
477
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_personal_action" model="ir.actions.act_window">
<field name="name">Personal</field>
<field name="res_model">subvenciones.personal</field>
</record>
<menuitem action="subvenciones_personal_action"
id="subvenciones_personal_menu" sequence="11"
<record model="ir.ui.view" id="subvenciones_otros_tree">
<field name="name">subvenciones.otros.tree</field>
478
<field name="model">subvenciones.otros</field>
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_otros_form">
<field name="name">subvenciones.otros.form</field>
<field name="model">subvenciones.otros</field>
479
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_ot ros_action" model="ir.actions.act_window">
<field name="res_model">subvenciones.otros</field>
</record>
<menuitem action="subvenciones_otros_action" id="subvenciones_otros_menu"

sequence="12" parent="subvenciones_ayudasybecas"/>
480
<record model="ir.ui.view" id="subvenciones_pedidas_tree">
<field name="name">subvenciones.pedidas.tree</field>
<field name="model">subvenciones.pedidas</field>
<tree string="pedidas">
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvencione s_pedidas_form">
<field name="name">subvenciones.pedidas.form</field>
<field name="model">subvenciones.pedidas</field>
<form string="pedidas">
481
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_pedidas_action" model="ir.actions.act_window">
<field name="name">Pedidas</field>
<field name="res_model">subvenciones.pedidas</field>
482
</record>
<menuitem action="subvenciones_pedidas_action"
id="subvenciones_pedidas_menu" sequence="13"
parent="subvenciones_subvenciones_interes"/>
<record model="ir.ui.view" id="subvenciones_aceptadaspendientes_tree">
<field name="name">subvenciones.aceptadaspendientes.tree</field>
<field name="model">subvenciones.aceptadaspendientes</field>
<tree string="aceptadaspendientes">
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_aceptadaspendientes_form">
<field name="name">subvenciones.aceptadaspendientes.form</field>
<field name="model">subvenciones.aceptadaspendientes</field>
483
<form string="aceptadaspendientes">
</group>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="subvenciones_aceptadaspendientes_action"
484
<field name="name">Aceptadas pendientes</field>
<field name="res_model">subvenciones.aceptadaspendientes</field>
</record>
<menuitem action="subvenciones_aceptadaspendientes_action"
id="subvenciones_aceptadaspendientes_menu" sequence="14"
<record model="ir.ui.view" id="subvenciones_recibidas_tree">
<field name="name">subvenciones.recibidas.tree</field>
<field name="model">subvenciones.recibidas</field>
<tree string="recibidas">
</tree>
</field>
</record>
485
<record model="ir.ui.view" id="subvenciones_recibidas_form">
<field name="name">subvenciones.recibidas.form</field>
<field name="model">subvenciones.recibidas</field>
<form string="recibidas">
</group>
</group>
<newline/>
</group>
</form>
</field>
486
</record>
<record id="subvenciones_recibidas_action" model="ir.actions.act_window">
<field name="name">Recibidas</field>
<field name="res_model">subvenciones.recibidas</field>
</record>
<menuitem action="subvenciones_recibidas_action"
id="subvenciones_recibidas_menu" sequence="15"
<record model="ir.ui.view" id="subvenciones_otro_tree">
<field name="name">subvenciones.otro.tree</field>
<field name="model">subvenciones.otro</field>
<tree string="otro">
487
</tree>
</field>
</record>
<record model="ir.ui.view" id="subvenciones_otro_form">
<field name="name">subvenciones.otro.form</field>
<field name="model">subvenciones.otro</field>
<form string="otro">
<field name="beneficiarios" placeholder= "benefic iarios..."/>
</group>
</group>
<newline/>
488
</group>
</form>
</field>
</record>
<record id="subvenciones_otro_action" model="ir.actions.act_window">
<field name="name">otro</field>
<field name="res_model">subvenciones.otro</field>
</record>
<menuitem action="subvenciones_otro_action" id="subvenciones_otro_menu"

sequence="16" parent="subvenciones_subvenciones_interes"/>
</data>
</openerp>
489
5. Geotermia.
Archivo __init__.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
import geotermia
# -*- coding: utf-8 -*-
##############################################################################
490
# This program is distribute d in the hope that it will be useful,
##############################################################################
"name" : "Geotermia",
"version" : "0.1",
"description": """Módulo en el que se recojerá información variada de todo

tipo del ámbito de la geotermia """,
'data': [],
'update_xml': ["geotermia.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'active': False,
491
Archivo geotermia.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
class geotermia_preguntasyrespuestas(osv.osv):
_name = 'geotermia.preguntasyrespuestas'
_description = 'Preguntas y respuestas'
_columns = {
'fecha': fields.date('Fecha', required=False),
'autorpreg': fields.char('Autor pregunta', size=300, required=False),
'autorresp': fields.char('Autor respuesta', size=300, required=False),
'pregunta': fields.text('Pregunta', required=False),
'respuesta': fields.text('Respuesta', required=False),
492
geotermia_preguntasyrespuestas()
class geotermia_medios(osv.osv):
_name = 'geotermia.medios'
_description = 'Medios'
_rac_name='medio'
_columns = {
'medio': fields.char('Medio', size=200, required=True),
'web': fields.char('Web', size=300, required=False),
'galicia': fields.boolean('Galicia', required=False),
'estatal': fields.boolean('Estatal', required=False),
'estranjero': fields.boolean('Estranjero', required=False),
'especializados': fields.boolean('especializados', required=False),
'online': fields.boolean('online', required=False),
'contacto': fields.many2one('geotermia.contactos','Contacto'),
geotermia_medios()
class geotermia_contactos(osv.osv):
_name = 'geotermia.contactos'
_description = 'Contactos'
_rac_name='name'
_columns = {
'name': fields.char('Nombre', size=200, required=True),
'medio': fields.many2one('geotermia.medios','Medio'),
493
geotermia_contactos()
class geotermia_webpropia(osv.osv):
_name = 'geotermia.webpropia'
_description = 'Web propia'
_columns = {
'titulo': fields.char('Título', size=200, required=True),
'enlace': fields.char('Enlace', size=300, required=False),
geotermia_webpropia()
class geotermia_publicidad(osv.osv):
_name = 'geotermia.publicidad'
_description = 'Publicidad'
_columns = {
'fecha': fields.date('Fecha'),
'image1': fields.binary("Imagen", help="Seleccionar imagen aqui"),
'presupuesto': fields.text('Presupuesto', required=False),
494
geotermia_publicidad()
class geotermia_noticiasgen(osv.osv):
_name = 'geotermia.noticiasgen'
_description = 'Noticias generadas'
_columns = {
geotermia_noticiasgen()
class geotermia_imagenes(osv.osv):
_name = 'geotermia.imagenes'
_description = 'Imagenes'
_columns = {
'evento': fields.char('Enlace', size=200, required=False),
495
'image': fields.binary("Imagen", help="Seleccionar imagen aqu i"),
geotermia_imagenes()
class geotermia_alertas(osv.osv):
_name = 'geotermia.alertas'
_description = 'Alertas'
_columns = {
'permite': fields.boolean('Permite suscripción', required=False),
'permitealertas': fields.boolean('Permite alertas', required=False),
'llegan': fields.boolean('¿Llegan?', required=False),
'alertasempleadas': fields.text('Alertas empleadas', required=False),
496
geotermia_alertas()
class geotermia_alertasenviadas(osv.osv):
_name = 'geotermia.alertasenviadas'
_description = 'Alertas enviadas'
_columns = {
'ficha': fields.binary("Ficha/documento", help="Ficha adjunta"),
'abrir': fields.char("Abrir con", size=400, required=False),
'titulo': fields.char('Título', size=400, required=False),
geotermia_alertasenviadas()
Archivo geotermia.xml
<openerp>
<data>
<menuitem name="Geotermia" id="geotermia" sequence="90"/>
<menuitem name="Alertas de correo" id="geotermia_alertasdecorreo"

parent="geotermia"/>
<menuitem name="Preguntas técnicas" id="geoterm ia_preguntastecnicas"

<menuitem name="Comunicación y promoción" id="geotermia_comunicacion"

<record model="ir.ui.view" id="custom_alertas_kanban_view">
<field name="name">geotermia.alertas.kanban</field>
<field name="model">geotermia.alertas</field>
497
<kanban>
<templates>
<a type="open">
t-att-
src="kanban_image('geotermia.alertas', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
<li><field name="permite"></field>
</li>
<li><field
name="permitealertas"></field> </li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
498
<record model="ir.ui.view" id="geotermia_alertas_tree">
<field name="name">geotermia.alertas.tree</field>
<tree string="alertas">
<field name="permite"/>
<field name="permitealertas"/>
<field name="llegan"/>
<field name="alertasempleadas"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="geotermia_alertas_form">
<field name="name">geotermia.alertas.form</field>
<form string="alertas">
<group>
<field name="permite"/>
<field name="permitealertas"/>
<field name="llegan"/>
</group>
<group string="Empleadas" colspan="2" col="1">
<field name="alertasempleadas"/>
</group>
</form>
499
</field>
</record>
<record id="geotermia_alertas_action" model="ir.actions.act_window">
<field name="name">Alertas</field>
<field name="res_model">geotermia.alertas</field>
</record>
<menuitem action="geotermia_alertas_action" id="geotermia_alertas_menu"

sequence="6" parent="geotermia_alertasdecorreo"/>
<record model="ir.ui.view" id="geotermia_alertasenviadas_tree">
<field name="name">geotermia.alertasenviadas.tree</field>
<field name="model">geotermia.alertasenviadas</field>
<tree string="alertasenviadas">
<field name="ficha" widget='url'/>
<field name="abrir"/>
<field name="titulo"/>
<field name="informacion"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="geotermia_alertasenviadas_form">
<field name="name">geotermia.alertasenviadas.form</field>
<field name="model">geotermia.alertasenviadas</field>
500
<form string="alertasenviadas">
<group>
<field name="tipo" placeholder= "anuncio,licitación,obra..."/>
<field name="ficha" />
<field name="abrir" placeholder= "indicar pdf,word..."/>
</group>
<newline/>
<group string="Información" colspan="2" col="1">
</group>
</form>
</field>
</record>
<record id="geotermia_alertasenviadas_action"
<field name="name">Alertas enviadas</field>
<field name="res_model">geotermia.alertasenviadas</field>
</record>
<menuitem action="geotermia_alertasenviadas_action"
id="geotermia_alertasenviadas_menu" sequence="7"
parent="geotermia_alertasdecorreo"/>
<record model="ir.ui.view" id="geotermia_preguntasyrespuestas_tree">
<field name="name">geotermia.preguntasyrespuestas.tree</field>
<field name="model">geotermia.preguntasyrespuestas</field>
<tree string="preguntasyrespuestas">
501
<field name="autorpreg"/>
<field name="autorresp"/>
<field name="pregunta"/>
<field name="respuesta"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="geotermia_preguntasyrespuestas_form">
<field name="name">geotermia.preguntasyrespuestas.form</fie ld>
<field name="model">geotermia.preguntasyrespuestas</field>
<form string="preguntasyrespuestas">
<field name="autorpreg"/>
<field name="autorresp"/>
<newline/>
<page string="Pregunta">
<field name="pregunta" placeholder= "Pregunta...."/>
</group>
</page>
<page string="Respuesta">
<field name="respuesta" placeholder= "Respuesta..."/>
</group>
</page>
</notebook>
</form>
</field>
502
</record>
<record id="geotermia_preguntasyrespuestas_action"
<field name="name">Preguntas y respuestas</field>
<field name="res_model">geotermia.preguntasyrespuestas</field>
</record>
<menuitem action="geotermia_preguntasyrespuestas_action"
id="geotermia_preguntasyrespuestas_menu" sequence="9"
parent="geotermia_preguntastecnicas"/>
<record model="ir.ui.view" id="custom_medios_kanban_view">
<field name="name">geotermia.medios.kanban</field>
<field name="model">geotermia.medios</field>
<kanban>
<field name="medio" />
<templates>
<a type="open">
t-att-
src="kanban_image('geotermia.medios', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
503
<field name="medio"></field>
</a>
</h4>
<ul>
<li><field name="contacto"></field>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="geotermia_medios_tree">
<field name="name">geotermia.medios.tree</field>
<tree string="medios">
<field name="medio"/>
<field name="web"/>
<field name="galicia"/>
<field name="estatal"/>
<field name="estranjero"/>
<field name="especializados"/>
<field name="online"/>
</tree>
</field>
</record>
504
<record model="ir.ui.view" id="geotermia_medios_form">
<field name="name">geotermia.medios.form</field>
<form string="medios">
<group>
<field name="web"/>
</group>
<group>
</group>
<newline/>
<field name="informacion" placeholder= "información

adicional..."/>
</group>
</form>
</field>
</record>
<record id="geotermia_medios_action" model="ir.actions.act_window">
<field name="name">Medios</field>
<field name="res_model">geotermia.medios</field>
</record>
505
<menuitem action="geotermia_medios_action" id="geotermia_medios_menu"

sequence="10" parent="geotermia_comunicacion"/>
<record model="ir.ui.view" id="geotermia_contactos_tree">
<field name="name">geotermia.contactos.tree</field>
<field name="model">geotermia.contactos</field>
<tree string="contactos">
</tree>
</field>
</record>
<record model="ir.ui.view" id="geotermia_contactos_form">
<field name="name">geotermia.contactos.form</field>
<field name="model">geotermia.contactos</field>
<form string="contactos">
</form>
</field>
</record>
<record id="geotermia_contactos_action" model="ir.actions.act_window">
506
<field name="name">Contactos</field>
<field name="res_model">geotermia.contactos</field>
</record>
<menuitem action="geotermia_contactos_action"
id="geotermia_contactos_menu" sequence="11" parent="geotermia_comunicacion"/>
<record model="ir.ui.view" id="geotermia_webpropia_tree">
<field name="name">geotermia.webpropia.tree</field>
<field name="model">geotermia.webpropia</field>
<tree string="webpropia">
<field name="enlace"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="geotermia_webpropia_form">
<field name="name">geotermia.webpropia.form</field>
<field name="model">geotermia.webpropia</field>
<form string="webpropia">
<group>
</group>
507
<newline/>
<field name="informacion" placeholder= "Publicación o

resumen..."/>
</group>
</form>
</field>
</record>
<record id="geotermia_webpropia_action" model="ir.actions.act_window">
<field name="name">Web propia</field>
<field name="res_model">geotermia.webpropia</field>
</record>
<menuitem action="geotermia_webpropia_action"
id="geotermia_webpropia_menu" sequence="12" parent="geotermia_comunicacion"/>
<record model="ir.ui.view" id="geotermia_publicidad_tree">
<field name="name">geotermia.publicidad.tree</field>
<field name="model">geotermia.publicidad</field>
<tree string="publicidad">
</tree>
</field>
</record>
508
<record model="ir.ui.view" id="geotermia_publicidad_form">
<field name="name">geotermia.publicidad.form</field>
<field name="model">geotermia.publicidad</field>
<form string="publicidad">
<newline/>
<page string="Presupuesto">
<field name="presupuesto" placeholder= "Precios y gastos

previstos..."/>
</group>
</page>
<field name="informacion" placeholder= "Contenido de la

publicidad"/>
</group>
</page>
</notebook>
<newline/>
<field name="image1" widget='image' />
</group>
</form>
</field>
</record>
509
<record id="geotermia_publicidad_action" model="ir.actions.act_window">
<field name="name">Publicidad</field>
<field name="res_model">geotermia.publicidad</field>
</record>
<menuitem action="geotermia_publicidad_action"
id="geotermia_publicidad_menu" sequence="13" parent="geotermia_comunicacion"/>
<record model="ir.ui.view" id="geotermia_noticiasgen_tree">
<field name="name">geotermia.noticiasgen.tree</field>
<field name="model">geotermia.noticiasgen</field>
<tree string="noticiasgen">
</tree>
</field>
</record>
<record model="ir.ui.view" id="geotermia_noticiasgen_form">
<field name="name">geotermia.noticiasgen.form</field>
<field name="model">geotermia.noticiasgen</field>
<form string="noticiasgen">
510
<newline/>

resumen..."/>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="geotermia_noticiasgen_action" model="ir.actions.act_window">
<field name="name">Noticias generadas</field>
<field name="res_model">geotermia.noticiasgen</field>
</record>
<menuitem action="geotermia_noticiasgen_action"
id="geotermia_noticiasgen_menu" sequence="14"
parent="geotermia_comunicacion"/>
<record model="ir.ui.view" id="geotermia_imagenes_tree">
<field name="name">geotermia.imagenes.tree</field>
<field name="model">geotermia.imagenes</field>
<tree string="imagenes">
<field name="evento"/>
511
</tree>
</field>
</record>
<record model="ir.ui.view" id="geotermia_imagenes_form">
<field name="name">geotermia.imagenes.form</field>
<field name="model">geotermia.imagenes</field>
<form string="imagenes">
<newline/>

resumen..."/>
</group>
<newline/>
512
</group>
</form>
</field>
</record>
<record id="geotermia_imagenes_action" model="ir.actions.act_window">
<field name="name">Imagenes</field>
<field name="res_model">geotermia.imagenes</field>
</record>
<menuitem action="geotermia_imagenes_action" id="geotermia_imagenes_menu"

sequence="15" parent="geotermia_comunicacion"/>
</data>
</openerp>
513
6. Curso.
Archivo __init__.py
# -*- coding: utf-8 -*-
##############################################################################
############################################################# #################
import curso
# -*- coding: utf-8 -*-
##############################################################################
514
##############################################################################
"name" : "Curso",
"version" : "0.1",
"description": """Módulo para la organización de cursos, creado en ACLUXEGA

""",
'data': [],
'update_xml': ["curso.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'active': False,
515
Archivo curso.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
class curso_ficha(osv.osv):
_name = 'curso.ficha'
_description = 'Ficha'
_columns = {
'modalidad': fields.char('Modalidad', size=200, required=False),
'objetivo': fields.char('Objetivo', size=200, required=False),
516
'entidadesorganizadoras': fields.char('Entidades organizadoras', size=200,

required=False),
'coordinadores': fields.char('Coordin adores', size=200, required=False),
'destinatarios': fields.char('destinatarios', size=200, required=False),
'extension': fields.char('Extensión', size=200, required=False),
'plazas': fields.char('Plazas', size=200, required=False),
'ficha': fields.binary("Ficha del curso", help="Ficha adjunta"),
'creditos': fields.text('Créditos', required=False),
'programa': fields.text('Programa', required=False),
'condicionesacceso': fields.text('Condiciones', required=False),
'sistemaevaluacion': fields.text('Evaluación', required=False),
'materiales': fields.text('Materiales', required=False),
'metododepago': fields.text('Pago', required=False),
'metodologia': fields.text('Metodología', required=False),
curso_ficha()
class curso_periododematricula(osv.osv):
_name = 'curso.periododematricula'
_description = 'Periodo de matricula'
_columns = {
'desde': fields.datetime('Desde', required=True),
'hasta': fields.datetime('Hasta', required=True),
'observaciones': fields.text('Observaciones', size=300, required=False),
curso_periododematricula()
517
class curso_periododedocencia(osv.osv):
_name = 'curso.periododedocencia'
_description = 'Periodo de docencia'
_columns = {
'desde': fields.datetime('Desde', required=True),
'hasta': fields.datetime('Hasta', required=True),
'observaciones': fields.text('Observaciones', size=300, required=False),
curso_periododedocencia()
class curso_listapreinscritos(osv.osv):
_name = 'curso.listapreinscritos'
_description = 'Lista preinscritos'
_columns = {
'dni': fields.char('DNI', size=20, required=False),
'direccioncompleta': fields.char('Dirección completa', size=250,

required=False),
'pais': fields.char('País', size=20, required=False),
'tlf': fields.char('Teléfono', size=20, required=False),
'colectivo': fields.char('Colectivo', size=200, required=False),
'ntrabajadores': fields.char('Nº Trabajadores', size=50, required=False),
'acluxega': fields.boolean('Acluxega', required=False),
'bonificada': fields.boolean('Bonificada', required=False),
'etiquetas': fields.boolean('Etiquetas', required=False),
'pago': fields.char('Pago', size=200, required=False),
518
curso_listapreinscritos()
class curso_listamatriculados(o sv.osv):
_name = 'curso.listamatriculados'
_description = 'Lista matriculados'
_rac_name='name'
_columns = {

required=False),
'ciudad': fields.char('Ciudad', size=200, required=False),
'bonificada': fields.boolean('Bonificada', required=False),
'entregadomanual': fields.boolean('¿Entregado manual?', required=False),
'asistencia_id': fields.one2many('curso.asistencia','name_id','Asistencia
al curso'),
'evaluacion_id':
fields.one2many('curso.evaluacion','name_id','Evaluación'),
'total': fields.char('Evaluación total', size=200, required=False),
curso_listamatriculados()
519
class curso_asistencia(osv.osv):
_name = 'curso.asistencia'
_description = 'Asistencia'
_columns = {
'name_id': fields.many2one('curso.listamatriculados','Nombre', ),
'jornada': fields.char('Jornada', size=100, required=False),
'asistio': fields.boolean('Asistió', required=False),
curso_asistencia()
class curso_evaluacion(osv.osv):
_name = 'curso.evaluacion'
_description = 'Evaluacion'
_columns = {
'name_id': fields.many2one('curso.listamatriculados','Nombre', ),
'tema': fields.char('Tema', size=100, required=False),
'nota': fields.char('Nota', size=20, required=False),
curso_evaluacion()
class curso_listabajas(osv.osv):
_name = 'curso.listabajas'
_description = 'Lista bajas'
_columns = {

required=False),
520
'bonificada': fields.boolean('Bonificada', required=False ),
'etiquetas': fields.boolean('Etiquetas', size=200, required=False),
curso_listabajas()
class curso_fichaalumnos(osv.osv):
_name = 'curso.fichaalumnos'
_description = 'Ficha alumnos'
_columns = {

required=False),
521
'entregadomanual': fields.boolean('¿Entregado manual?', required=False),
curso_fichaalumnos()
class curso_tutores(osv.osv):
_name = 'curso.tutores'
_description = 'Tutores'
_columns = {
'modulo': fields.char('Módulo', size=200, required=False),
'disponibilidaddiayhoras': fields.text('Días y horas', required=False),
'tutoriasdiayhoras': fields.text('Días y horas', required=False),
'horasclasediayhoras': fields.text('Días y horas', required=False),
curso_tutores()
Archivo curso.xml
<openerp>
<data>
<menuitem name="Curso" id="curso" sequence="90"/>
<menuitem name="Ficha del curso" id="curso_fichadelcurso" parent="curso"/>
<menuitem name="Calendario y fechas" id="curso_calendarioyfecha"

parent="curso" />
522
<menuitem name="Alumnos" id="curso_alumnos" parent="curso" />
<menuitem name="Formacion bonificada" id="curso_formacionbonificada"

parent="curso" />
<menuitem name="Profesorado" id="curso_profesorado" parent="curso" />
<record model="ir.ui.view" id="curso_ficha_tree">
<field name="name">curso.ficha.tree</field>
<field name="model">curso.ficha</field>
<tree string="ficha">
<field name="modalidad"/>
<field name="objetivo"/>
<field name="entidadesorganizadoras"/>
<field name="coordinadores"/>
<field name="destinatarios"/>
<field name="extension"/>
<field name="plazas"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_ficha_form">
<field name="name">curso.ficha.form</field>
<field name="model">curso.ficha</field>
<form string="ficha">
523
<field name="modalidad"/>
<field name="objetivo"/>
<field name="entidadesorganizadoras"/>
<field name="coordinadores"/>
<field name="destinatarios"/>
<field name="extension"/>
<field name="plazas"/>
<page string="Créditos">
<field name="creditos" placeholder= "Creditos de libre

eleccion, ECTS..."/>
</group>
</page>
<page string="Programa">
<field name="programa" placeholder= "Introduzca el temario

del curso"/>
</group>
</page>
<page string="Materiales">
<field name="materiales" placeholder="Materiales a

emplear..."/>
</group>
</page>
<page string="Condiciones acceso">
524
<field name="condicionesacceso" placeholder="condiciones de

acceso al curso"/>
</group>
</page>
<page string="Sistema evaluación">
<field name="sistemaevaluacion" placeholder="Formacion

continua, examenes, valoracion asistencia..."/>
</group>
</page>
<page string="Método de pago">
<field name="metododepago" placeholder="Precios asociados,

no asociados, universitarios..."/>
</group>
</page>
<page string="Metodología">
<field name="metodologia"/>
</group>
</page>
<page string="Observaciones">
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="curso_ficha_action" model="ir.actions.act_window">
<field name="name">Ficha</field>
<field name="res_model">curso.ficha</field>
525
</record>
<menuitem action="curso_ficha_action" id="curso_ficha_menu" sequence="1"

parent="curso_fichadelcurso"/>
<record model="ir.ui.view" id="curso_periododematricula_tree">
<field name="name">curso.periododematricula.tree</field>
<field name="model">curso.periododematricula</field>
<tree string="periododematricula">
<field name="desde"/>
<field name="hasta"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_periododematricula_form">
<field name="name">curso.periododematricula.form</field>
<field name="model">curso.periododematricula</field>
<form string="periododematricula">
</form>
</field>
</record>
526
<record id="curso_periododematricula_action"
<field name="name">Periodo de matricula</field>
<field name="res_model">curso.periododematricula</field>
</record>
<menuitem action="curso_periododematricula_action"
id="curso_periododematricula_menu" sequence="2"
parent="curso_calendarioyfecha"/>
<record model="ir.ui.view" id="curso_periododedocencia_tree">
<field name="name">curso.periododedocencia.tree</field>
<field name="model">curso.periododedocencia</field>
<tree string="periododedocencia">
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_periododedocencia_form">
<field name="name">curso.periododedocencia.form</field>
<field name="model">curso.periododedocencia</field>
<form string="periododedocencia">
527
</form>
</field>
</record>
<record id="curso_periododedocencia_action" model="ir.actions.act_window">
<field name="name">Periodo de docencia</field>
<field name="res_model">curso.periododedocencia</field>
</record>
<menuitem action="curso_periododedocencia_action"
id="curso_periododedocencia_menu" sequence="3"
parent="curso_calendarioyfecha"/>
<record model="ir.ui.view" id="curso_listapreinscritos_tree">
<field name="name">curso.listapreinscritos.tree</field>
<field name="model">curso.listapreinscritos</field>
<tree string="listapreinscritos">
<field name="dni"/>
<field name="direccioncompleta"/>
<field name="pais"/>
<field name="tlf"/>
<field name="colectivo"/>
<field name="cif"/>
<field name="ntrabajadores"/>
<field name="acluxega"/>
528
<field name="bonificada"/>
<field name="etiquetas"/>
<field name="pago"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_listapreinscritos_form">
<field name="name">curso.listapreinscritos.form</field>
<field name="model">curso.listapreinscritos</field>
<form string="listapreinscritos">
<group string="Datos personales">
<field name="dni"/>
<field name="tlf"/>
</group>
<group string=" Datos profesionales">
<field name="cif"/>
</group>
529
</form>
</field>
</record>
<record id="curso_listapreinscritos_action" model="ir.actions.act_window">
<field name="name">Lista preinscritos</field>
<field name="res_model">curso.listapreinscritos</field>
</record>
<menuitem action="curso_listapreinscritos_action"
id="curso_listapreinscritos_menu" sequence="4" parent="curso_alumnos"/>
<record model="ir.ui.view" id="curso_listamatriculados_tree">
<field name="name">curso.listamatriculados.tree</field>
<field name="model">curso.listamatriculados</field>
<tree string="listamatriculados">
<field name="dni"/>
<field name="cp"/>
<field name="ciudad"/>
<field name="tlf"/>
<field name="cif"/>
530
<field name="entregadomanual"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_listamatriculados_form">
<field name="name">curso.listamatriculados.form</field>
<field name="model">curso.listamatriculados</field>
<form string="listamatriculados">
<field name="dni"/>
<field name="cp"/>
<field name="tlf"/>
</group>
<field name="cif"/>
531
</group>
<newline/>
<notebook>
<page string="Asistencia">
<field name="asistencia_id"/>
</group>
</page>
</notebook>
<notebook>
<page string="Evaluación">
<field name="total"/>
<field name="evaluacion_id"/>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="curso_listamatriculados_action" model="ir.actions.act_window">
<field name="name">Lista matriculados</field>
<field name="res_model">curso.listamatriculados</field>
</record>
532
<menuitem action="curso_listamatriculados_action"
id="curso_listamatriculados_menu" sequence="5" parent="curso_alumnos"/>
<record model="ir.ui.view" id="curso_asistencia_tree">
<field name="name">curso.asistencia.tree</field>
<field name="model">curso.asistencia</field>
<tree string="asistencia">
<field name="jornada"/>
<field name="asistio"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_asistencia_form">
<field name="name">curso.asistencia.form</field>
<field name="model">curso.asistencia</field>
<form string="asistencia">
<field name="jornada"/>
<field name="asistio"/>
</form>
</field>
</record>
<record model="ir.ui.view" id="curso_evaluacion_tree">
<field name="name">curso.evaluacion.tree</field>
<field name="model">curso.evaluacion</field>
<tree string="evaluacion">
533
<field name="tema"/>
<field name="nota"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_evaluacion_form">
<field name="name">curso.evaluacion.form</field>
<field name="model">curso.evaluacion</field>
<form string="evaluacion">
<field name="tema"/>
<field name="nota"/>
</form>
</field>
</record>
<record model="ir.ui.view" id="curso_listabajas_tree">
<field name="name">curso.listabajas.tree</field>
<field name="model">curso.listabajas</field>
<tree string="listabajas">
<field name="dni"/>
<field name="cp"/>
534
<field name="tlf"/>
<field name="cif"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_listabajas_form">
<field name="name">curso.listabajas.form</field>
<field name="model">curso.listabajas</field>
<form string="listabajas">
<field name="dni"/>
<field name="cp"/>
<field name="tlf"/>
</group>
<group string="Datos profesionales">
535
<field name="cif"/>
</group>
</form>
</field>
</record>
<record id="curso_listabajas_action" model="ir.actions.act_window">
<field name="name">Lista bajas</field>
<field name="res_model">curso.listabajas</field>
</record>
<menuitem action="curso_listabajas_action" id="curso_listabajas_menu"

sequence="7" parent="curso_alumnos"/>
<record model="ir.ui.view" id="curso_fichaalumnos_tree">
<field name="name">curso.fichaalumnos.tree</field>
<field name="model">curso.fichaalumnos</field>
<tree string="fichaalumnos">
<field name="dni"/>
536
<field name="cp"/>
<field name="tlf"/>
<field name="cif"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_fichaalumnos_form">
<field name="name">curso.fichaalumnos.form</field>
<field name="model">curso.fichaalumnos</field>
<form string="fichaalumnos">
<field name="dni"/>
<field name="cp"/>
<field name="tlf"/>
</group>
537
<group string="Datos profesionales">
<field name="cif"/>
</group>
</form>
</field>
</record>
<record id="curso_fichaalumnos_action" model="ir.actions.act_window">
<field name="name">Ficha alumnos</field>
<field name="res_model">curso.fichaalumnos</field>
</record>
<menuitem action="curso_fichaalumnos_action" id="curso_fichaalumnos_menu"

sequence="9" parent="curso_formacionbonificada"/>
<record model="ir.ui.view" id="curso_ tutores_tree">
<field name="name">curso.tutores.tree</field>
<field name="model">curso.tutores</field>
<tree string="tutores">
<field name="dni"/>
<field name="tlf"/>
538
<field name="modulo"/>
<field name="disponibilidaddiayhoras"/>
<field name="tutoriasdiayhoras"/>
<field name="horasclasediayhoras"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="curso_tutores_form">
<field name="name">curso.tutores.form</field>
<field name="model">curso.tutores</field>
<form string="tutores">
<field name="dni"/>
<field name="tlf"/>
<field name="modulo"/>
</group>
<group string="Horarios">
<notebook>
<page string="Disponibilidad">
<field name="disponibilidaddiayhoras"/>
</group>
</page>
<page string="Tutorías">
<field name="tutoriasdiayhoras"/>
539
</group>
</page>
<page string="Horarios clase">
<field name="horasclasediayhoras"/>
</group>
</page>
</notebook>
</group>
</form>
</field>
</record>
<record id="curso_tutores_action" model="ir.actions.act_window">
<field name="name">Tutores</field>
<field name="res_model">curso.tutores</field>
</record>
<menuitem action="curso_tutores_action" id="curso_tutores_menu"

sequence="10" parent="curso_profesorado"/>
</data>
</openerp>
540
7. Congreso.
# -*- coding: utf-8 -*-
##############################################################################
# You should have received a copy of the GN U Affero General Public License
##############################################################################
import congreso
# -*- coding: utf-8 -*-
##############################################################################
541
##############################################################################
"name" : "Congreso",
"version" : "0.1",
"description": """Módulo modelo para organización de un congreso,creado en

ACLUXEGA con motivo de la I Expo Congreso Nacional sobre Geotermia """,
'data': [],
'update_xml': ["congreso.xml"],
'init_xml' : [ ],
'demo_xml' : [ ],
'active': False,
542
Archivo congreso.py
# -*- coding: utf-8 -*-
##############################################################################
##############################################################################
class congreso_ficha(osv.osv):
_name = 'congreso.ficha'
_description = 'Ficha'
_columns = {
'subtitulo': fields.char('Subtitulo', size=200, required=False),
'fechauno': fields.date('Desde', required=False),
'fechados': fields.date('Hasta', required=False),
543
'sede': fields.char('Sede', size=200, required=False),
'secretariatecnica': fields.char('Secretaría técnica', size=200,

required=False),
'ficha': fields.binary("Ficha del congreso", help="Ficha adjunta"),
'presentacion': fields.text('Presentación', required=False),
'objetivos': fields.text('Objetivos', required=False),
'comites': fields.text('Comités', required=False),
'inscripciones': fields.text('Inscripciones', required=False),
'creditos': fields.text('Créditos', required=False),
'exposicion': fields.text('Exposición', required=False),
'patrocinadores': fields.text('Patrocinadores', required=False),
'programa': fields.text('Programa', required=False),
congreso_ficha()
class congreso_programa(osv.osv):
_name = 'congreso.programa'
_description = 'programa'
_columns = {
'desde': fields.float('Desde'),
'hasta': fields.float('Hasta'),
'actividad': fields.char('Actividad', size=200, required=True),
'ponente': fields.char('Ponente', size=450, required=False),
congreso_programa()
class congreso_organizadores(osv.osv):
544
_name = 'congreso.organizadores'
_description = 'Organizadores'
_columns = {
'contacto': fields.char('Persona contacto', size=200, required=False),
'direccion': fields.char('Direccion', size=200, required=False),
'email': fields.char('Email', size=200, required=False),
congreso_organizadores()
class congreso_entidadescolaboradoras(osv.osv):
_name = 'congreso.entidadescolaboradoras'
_description = 'Entidades colaboradoras'
_columns = {
'informacion': fields.char('Información', size=600,required=False),
545
congreso_entidadescolaboradoras()
class congreso_patrocinadores(osv.osv):
_name = 'congreso.patrocinadores'
_description = 'Patrocinadores'
_columns = {
'informacion': fields.char('Información', size=600, required=False),
congreso_patrocinadores()
class congreso_presentador(osv.osv):
_name = 'congreso.presentador'
_description = 'Presentador'
_columns = {
546
congreso_presentador()
class congreso_ponentes(osv.osv):
_name = 'congreso.ponentes'
_description = 'Ponentes'
_columns = {
congreso_ponentes()
class congreso_expositores(osv.osv):
_name = 'congreso.expositores'
_description = 'Expositores'
_columns = {
547
congreso_expositores()
class congreso_listapreinscritos(osv.osv):
_name = 'congreso.listapreinscritos'
_description = 'Lista preinscritos'
_columns = {

required=False),
'estudiante': fields.boolean('Estudiante', required=False),
'entidad': fields.boolean('Entidad/empresa', required=False),
'pago': fields.boolean('pago', required=False),
'cantidad': fields.char('Cantidad', size=200, required=False),
548
congreso_listapreinscritos()
class congreso_listamatriculados(osv.osv):
_name = 'congreso.listamatriculados'
_description = 'Lista matriculados'
_columns = {

required=False),
'estudiante': fields.boolean('Estudiante', required=False),
'entidad': fields.boolean('Entidad/empresa', required=False),
'pago': fields.boolean('pago', required=False),
'cantidad': fields.char('Cantidad', size=200, required=False),
congreso_listamatriculados()
class congreso_medios(osv.osv):
549
_name = 'congreso.medios'
_description = 'Medios'
_rac_name='name'
_columns = {
'name': fields.char('Medio', size=200, required=True),
'galicia': fields.boolean('Galicia', required=False),
'estatal': fields.boolean('Estatal', required=False),
'estranjero': fields.boolean('Extranjero', required=False),
'especializados': fields.boolean('especializados', required=False),
'online': fields.boolean('online', required=False),
'contacto': fields.many2one('congreso.contactos','Contacto'),
congreso_medios()
class congreso_contactos(osv.osv):
_name = 'congreso.contactos'
_description = 'Contactos'
_rac_name='name'
_columns = {
'medio': fields.many2one('congreso.medios','Medio'),
congreso_contactos()
550
class congreso_webpropia(osv.osv):
_name = 'congreso.webpropia'
_description = 'Web propia'
_columns = {
'titulo': fields.char('Título', size=200, required=True),
congreso_webpropia()
class congreso_publicidad(osv.osv):
_name = 'congreso.publicidad'
_description = 'Publicidad'
_columns = {
'presupuesto': fields.text('Presupuesto', required=False),
congreso_publicidad()
class congreso_noticiasgen(osv.osv):
551
_name = 'congreso.noticiasgen'
_description = 'Noticias generadas'
_columns = {
congreso_noticiasgen()
class congreso_imagenes(osv.osv):
_name = 'congreso.imagenes'
_description = 'Imagenes'
_columns = {
'evento': fields.char('Enlace', size=200, required=False),
552
congreso_imagenes()
Archivo congreso.xml
<openerp>
<data>
<menuitem name="Congreso" id="congreso" sequence="90"/>
<menuitem name="Ficha técnica" id="congreso_fichatecnica"

parent="congreso"/>
<menuitem name="Organización" id="congreso_organizacion"

parent="congreso"/>
<menuitem name="Ponencias" id="congreso_ponencias" parent="congreso"/>
<menuitem name="Participantes" id="congreso_participantes"

parent="congreso"/>
<menuitem name="Comunicación y promoción" id="congreso_comunicacion"

parent="congreso"/>
<record model="ir.ui.view" id="congreso_ficha_tree">
<field name="name">congreso.ficha.tree</field>
<field name="model">congreso.ficha</field>
553
<tree string="ficha">
<field name="subtitulo"/>
<field name="fechauno"/>
<field name="fechados"/>
<field name="sede"/>
<field name="secretariatecnica"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_ficha_form">
<field name="name">congreso.ficha.form</field>
<field name="model">congreso.ficha</field>
<form string="ficha">
<group string="Ficha técnica">
<field name="subtitulo"/>
<field name="sede"/>
<field name="secretariatecnica"/>
</group>
<group string="Fecha">
<field name="fechauno"/>
<field name="fechados"/>
554
</group>
<separator string="Información general" colspan="4"/>
<page string="Presentación">
<field name="presentacion" placeholder= "Presentación,

organizadores, participantes..."/>
</group>
</page>
<page string="Objetivos">
<field name="objetivos" placeholder=

"Difusión,experiencias,conocimientos, resultados..."/>
</group>
</page>
<page string="Comités">
<field name="comites" placeholder="Comité organizador,comité

tecnico..."/>
</group>
</page>
<page string="Inscripciones">
<field name="inscripciones" placeholder="Lugar,

precio,descuentos..."/>
</group>
</page>
<page string="Créditos universitarios">
<field name="creditos" placeholder="Creditos de libre

eleccion, ECTS..."/>
</group>
</page>
<page string="Exposición">
555
<field name="exposicion" placeholder="Información general,

sede, zonas de exhibiciones..."/>
</group>
</page>
<page string="Patrocinadores">
<field name="patrocinadores" placeholder="Patrocinadores,

colaboradores..."/>
</group>
</page>
<page string="Programa">
<field name="programa" placeholder="Programa del

congreso..."/>
</group>
</page>
<page string="Observaciones">
<field name="observaciones" placeholder="Información

general, sede, zonas de exhibiciones..."/>
</group>
</page>
</notebook>
</form>
</field>
</record>
<record id="congreso_ficha_action" model="ir.actions.act_window">
<field name="name">Ficha</field>
<field name="res_model">congreso.ficha</field>
</record>
556
<menuitem action="congreso_ficha_action" id="congreso_ficha_menu"

sequence="1" parent="congreso_fichatecnica"/>
<record model="ir.ui.view" id="congreso_programa_tree">
<field name="name">congreso.programa.tree</field>
<field name="model">congreso.programa</field>
<tree string="programa">
<field name="ponente"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_programa_form">
<field name="name">congreso.programa.form</field>
<field name="model">congreso.programa</field>
<form string="programa">
<field name="desde" widget="float_time"/>
<field name="hasta" widget="float_time"/>
<field name="ponente"/>
</form>
</field>
</record>
<record id="congreso_programa_action" model="ir.actions.act_window">
<field name="name">Programa</field>
557
<field name="res_model">congreso.programa</field>
</record>
<menuitem action="congreso_programa_action" id="congreso_programa_menu"

sequence="2" parent="congreso_fichatecnica"/>
<record model="ir.ui.view" id="custom_organizadores_kanban_view">
<field name="name">congreso.organizadores.kanban</field>
<field name="model">congreso.organizadores</field>
<kanban>
<field name="nombre" />
<templates>
<a type="open">
t-att-
src="kanban_image('congreso.organizadores', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
<field name="nombre"></field>
</a>
</h4>
<ul>
</li>
558
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="congreso_organizadores_tree">
<field name="name">congreso.organizadores.tree</field>
<tree string="organizadores">
<field name="cif"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_organizadores_form">
<field name="name">congreso.organizadores.form</field>
<form string="organizadores">
559
<group>
</group>
<group>
<field name="cif"/>
<field name="web"/>
</group>
<newline/>

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_organizadores_action" model="ir.actions.act_window">
<field name="name">Organizadores</field>
<field name="res_model">congreso.organizadores</field>
</record>
<menuitem action="congreso_organizadores_action"
id="congreso_organizadores_menu" sequence="3" parent="congreso_organizacion"/>
<record model="ir.ui.view" id="custom_entidadescolaboradoras_kanban_view">
<field name="name">congreso.entidadescolaboradoras.kanban</field>
560
<field name="model">congreso.entidadescolaboradoras</field>
<kanban>
<templates>
<a type="open">
t-att-
src="kanban_image('congreso.entidadescolaboradoras', 'image',
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
561
<record model="ir.ui.view" id="congreso_entidadescolaboradoras_tree">
<field name="name">congreso.entidadescolaboradoras.tree</field>
<tree string="entidadescolaboradoras">
<field name="cif"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_entidadescolaboradoras_form">
<field name="name">congreso.entidadescolaboradoras.form</field>
<form string="entidadescolaboradoras">
<group>
</group>
<group>
<field name="cif"/>
562
<field name="web"/>
</group>
<newline/>

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_entidadescolaboradoras_action"
<field name="name">Entidades colaboradoras</field>
<field name="res_model">congreso.entidadescolaboradoras</field>
</record>
<menuitem action="congreso_entidadescolaboradoras_action"
id="congreso_entidadescolaboradoras_menu" sequence="4"
parent="congreso_organizacion"/>
<record model="ir.ui.view" id="custom_patrocinadores_kanban_view">
<field name="name">congreso.patrocinadores.kanban</field>
<field name="model">congreso.patrocinadores</field>
<kanban>
<templates>
563
<a type="open">
t-att-
src="kanban_image('congreso.patrocinadores', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="congreso_patrocinadores_tree">
<field name="name">congreso.patrocinadores.tree</field>
<tree string="patrocinadores">
564
<field name="cif"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_patrocinadores_form">
<field name="name">congreso.patrocinadores.form</field>
<form string="patrocinadores">
<group>
</group>
<group>
<field name="cif"/>
<field name="web"/>
</group>
<newline/>

adicional..."/>
</group>
</form>
565
</field>
</record>
<record id="congreso_patrocinadores_action" model="ir.actions.act_window">
<field name="name">Patrocinadores</field>
<field name="res_model">congreso.patrocinadores</field>
</record>
<menuitem action="congreso_patrocinadores_action"
id="congreso_patrocinadores_menu" sequence="5"
parent="congreso_organizacion"/>
<record model="ir.ui.view" id="custom_presentador_kanban_view">
<field name="name">congreso.presentador.kanban</field>
<field name="model">congreso.presentador</field>
<kanban>
<templates>
<a type="open">
t-att-
src="kanban_image('congreso.presentador', 'image', record.id.value)" />
</a>
<h4>
566
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="congreso_presentador_tree">
<field name="name">congreso.presentador.tree</field>
<tree string="presentador">
<field name="cif"/>
<field name="web"/>
</tree>
</field>
</record>
567
<record model="ir.ui.view" id="congreso_presentador_form">
<field name="name">congreso.presentador.form</field>
<form string="presentador">
<group>
</group>
<group>
<field name="cif"/>
<field name="web"/>
</group>
<newline/>

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_presentador_action" model="ir.actions.act_window">
<field name="name">Presentador</field>
<field name="res_model">congreso.presentador</field>
</record>
568
<menuitem action="congreso_presentador_action"
id="congreso_presentador_menu" sequence="7" parent="congreso_ponencias"/>
<record model="ir.ui.view" id="custom_ponentes_kanban_view">
<field name="name">congreso.ponentes.kanban</field>
<field name="model">congreso.ponentes</field>
<kanban>
<templates>
<a type="open">
t-att-
src="kanban_image('congreso.ponentes', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
569
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="congreso_ponentes_tree">
<field name="name">congreso.ponentes.tree</field>
<tree string="ponentes">
<field name="cif"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_ponentes_form">
<field name="name">congreso.ponentes.form</field>
<form string="ponentes">
<group>
570
</group>
<group>
<field name="cif"/>
<field name="web"/>
</group>
<newline/>

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_ponentes_action" model="ir.actions.act_window">
<field name="name">Ponentes</field>
<field name="res_model">congreso.ponentes</field>
</record>
<menuitem action="congreso_ponentes_action" id="congreso_ponentes_menu"

sequence="8" parent="congreso_ponencias"/>
<record model="ir.ui.view" id="custom_expositores_kanban_view">
<field name="name">congreso.expositores.kanban</field>
<field name="model">congreso.expositores</field>
<kanban>
571
<templates>
<a type="open">
t-att-
src="kanban_image('congreso.expositores', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
</record>
<record model="ir.ui.view" id="congreso_expositores_tree">
<field name="name">congreso.expositores.tree</field>
572
<tree string="expositores">
<field name="cif"/>
<field name="web"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_expositores_form">
<field name="name">congreso.expositores.form</field>
<form string="expositores">
<group>
</group>
<group>
<field name="cif"/>
<field name="web"/>
</group>
<newline/>
573

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_expositores_action" model="ir.actions.act_window">
<field name="name">Expositores</field>
<field name="res_model">congreso.expositores</field>
</record>
<menuitem action="congreso_expositores_action"
id="congreso_expositores_menu" sequence="9" parent="congreso_ponencias"/>
<record model="ir.ui.view" id="congreso_listapreinscritos_tree">
<field name="name">congreso.listapreinscritos.tree</field>
<field name="model">congreso.listapreinscritos</field>
<tree string="listapreinscritos">
<field name="dni"/>
<field name="tlf"/>
574
<field name="cif"/>
<field name="estudiante"/>
<field name="entidad"/>
<field name="cantidad"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_listapreinscritos_form">
<field name="name">congreso.listapreinscritos.form</field>
<field name="model">congreso.listapreinscritos</field>
<form string="listapreinscritos">
<field name="dni"/>
<field name="tlf"/>
</group>
<field name="cif"/>
575
<field name="cantidad" placeholder= "cantidad..."/>
</group>
<newline/>

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_listapreinscritos_action"
<field name="name">Lista preinscritos</field>
<field name="res_model">congreso.listapreinscritos</field>
</record>
<menuitem action="congreso_listapreinscritos_action"
id="congreso_listapreinscritos_menu" sequence="10"
parent="congreso_participantes"/>
<record model="ir.ui.view" id="congreso_listamatriculados_tree">
<field name="name">congreso.listamatriculados.tree</field>
<field name="model">congreso.listamatriculados</field>
<tree string="listamatriculados">
<field name="dni"/>
576
<field name="tlf"/>
<field name="cif"/>
<field name="cantidad"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_listamatriculados_form">
<field name="name">congreso.listamatriculados.form</field>
<field name="model">congreso.listamatriculados</field>
<form string="listamatriculados">
<field name="dni"/>
<field name="tlf"/>
577
</group>
<field name="cif"/>
<field name="cantidad" placeholder= "cantidad..."/>
</group>
<newline/>

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_listamatriculados_action"
<field name="name">Lista matriculados</field>
<field name="res_model">congreso.listamatriculados</field>
</record>
<menuitem action="congreso_listamatriculados_action"
id="congreso_listamatriculados_menu" sequence="11"
parent="congreso_participantes"/>
<record model="ir.ui.view" id="custom_medios_kanban_view">
578
<field name="name">congreso.medios.kanban</field>
<field name="model">congreso.medios</field>
<kanban>
<field name="name" />
<templates>
<a type="open">
t-att-
src="kanban_image('congreso.medios', 'image', record.id.value)" />
</a>
<h4>
<a type="edit">
<field name="name"></field>
</a>
</h4>
<ul>
</li>
</ul>
</div>
</div>
</t>
</templates>
</kanban>
</field>
579
</record>
<record model="ir.ui.view" id="congreso_medios_tree">
<field name="name">congreso.medios.tree</field>
<tree string="medios">
<field name="web"/>
<field name="estatal"/>
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_medios_form">
<field name="name">congreso.medios.form</field>
<form string="medios">
<group>
<field name="web"/>
</group>
<group>
580
</group>
<newline/>

adicional..."/>
</group>
</form>
</field>
</record>
<record id="congreso_medios_action" model="ir.actions.act_window">
<field name="name">Medios</field>
<field name="res_model">congreso.medios</field>
</record>
<menuitem action="congreso_medios_action" id="congre so_medios_menu"

sequence="12" parent="congreso_comunicacion"/>
<record model="ir.ui.view" id="congreso_contactos_tree">
<field name="name">congreso.contactos.tree</field>
<field name="model">congreso.contactos</field>
<tree string="contactos">
581
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_contactos_form">
<field name="name">congreso.contactos.form</field>
<field name="model">congreso.contactos</field>
<form string="contactos">
</form>
</field>
</record>
<record id="congreso_contactos_action" model="ir.actions.act_window">
<field name="name">Contactos</field>
<field name="res_model">congreso.contactos</field>
</record>
<menuitem action="congreso_contactos_action" id="congreso_contactos_menu"

<record model="ir.ui.view" id="congreso_webpropia_tree">
<field name="name">congreso.webpropia.tree</f ield>
<field name="model">congreso.webpropia</field>
582
<tree string="webpropia">
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_webpropia_form">
<field name="name">congreso.webpropia.form</field>
<field name="model">congreso.webpropia</field>
<form string="webpropia">
<group>
</group>
<newline/>

resumen..."/>
</group>
</form>
</field>
</record>
<record id="congreso_webpropia_action" model="ir.actions.act_window">
<field name="name">Web propia</field>
<field name="res_model">congreso.webpropia</field>
583
</record>
<menuitem action="congreso_webpropia_action" id="congreso_webpropia_menu"

<record model="ir.ui.view" id="congreso_publicidad_tree">
<field name="name">congreso.publicidad.tree</field>
<field name="model">congreso.publicidad</field>
<tree string="publicidad">
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_publicidad_form">
<field name="name">congreso.publicidad.form</field>
<field name="model">congreso.publicidad</field>
<form string="publicidad">
<newline/>
<page string="Presupuesto">
584
<field name="presupuesto" placeholder= "Precios y gastos

previstos..."/>
</group>
</page>
<field name="informacion" placeholder= "Contenido de la

publicidad"/>
</group>
</page>
</notebook>
<newline/>
</group>
</form>
</field>
</record>
<record id="congreso_publicidad_action" model="ir.actions.act_window">
<field name="name">Publicidad</field>
<field name="res_model">congreso.publicidad</field>
</record>
<menuitem action="congreso_publicidad_action"
id="congreso_publicidad_menu" sequence="15" parent="congreso_comunicacion"/>
<record model="ir.ui.view" id="congreso_noticiasgen_tree">
<field name="name">congreso.noticiasgen.tree</field>
<field name="model">congreso.noticiasgen</field>
585
<tree string="noticiasgen">
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_noticiasgen_form">
<field name="name">congreso.noticiasgen.form</field>
<field name="model">congreso.noticiasgen</field>
<form string="noticiasgen">
<newline/>

resumen..."/>
</group>
<newline/>
</group>
</form>
</field>
586
</record>
<record id="congreso_noticiasgen_action" model="ir.actions.act_window">
<field name="name">Noticias generadas</field>
<field name="res_model">congreso.noticiasgen</field>
</record>
<menuitem action="congreso_noticiasgen_act ion"

id="congreso_noticiasgen_menu" sequence="16" parent="congreso_comunicacion"/>
<record model="ir.ui.view" id="congreso_imagenes_tree">
<field name="name">congreso.imagenes.tree</field>
<field name="model">congreso.imagenes</field>
<tree string="imagenes">
</tree>
</field>
</record>
<record model="ir.ui.view" id="congreso_imagenes_form">
<field name="name">congreso.imagenes.form</field>
<field name="model">congreso.imagenes</field>
<form string="imagenes">
587
<newline/>

resumen..."/>
</group>
<newline/>
</group>
</form>
</field>
</record>
<record id="congreso_imagenes_action" model="ir.actions.act_window">
588
<field name="name">Imagenes</field>
<field name="res_model">congreso.imagenes</field>
</record>
<menuitem action="congreso_imagenes_action" id="congreso_imagenes_menu"

</data>
</openerp>
589
590
ANEXO IV
Tutorial OpenERP ACLUXEGA
Tutorial Openerp Acluxega
1. Definiciones, acceso, IP.
2. Crear, eliminar, duplicar base de datos.
3. Bases de datos y módulos propios adaptados a Acluxega.
4. Modificaciones en los menús. Modo gráfico.
4.1. Eliminar menú.
5. Crear usuarios y cambio de claves.
6. Permisos
7. Importar-exportar datos
7.1. Exportar
7.2 Importar datos
Autor: Fernando Vázquez Novoa
novooa@gmail.com
ANEXO IV: TUTORIAL OPENERP ACLUXEGA
1. Definiciones, acceso, IP
Primeramente se definen unos cuantos conceptos a los cuales se hará

referencia a lo largo del tutorial.
Servidor/Anfitrión: En este caso es el ordenador de Belén, en el está

instalado Openerp y el resto de los usuarios solo podrán acceder al programa si el de
ella está encendido y con la sesión iniciada.
Para acceder desde el ordenador de Belén habrá que escribir en el explorador

de internet que se prefiera “localhost:8069”. Para acceder desde los otros de la red
local habrá que escribir la ip del ordenador de ella seguida de dos puntos y el nombre
del puerto 8069 tal que así “192.168.0.6:8069”. Actualmente la IP es fija, con lo cual
será siempre la misma.
Para consultar la IP desde su ordenador se va a inicio, se escribe cmd y en la

consola se escribe “ipconfig” dando como resultado la siguiente imagen que es donde
se ve la IP.
Figura 1.IP del ordenador servidor
Otra forma más fácil y que puede hacerse desde los otros dos ordenadores
directamente es escribir no la Ip del ordenador, si no la del router, la cual es
“192.168.0.1” con lo que se abrirá la pantalla siguiente en la que aparecen las IPs de
todos los equipos conectados. El de Belén es el que considera como “computer”.
595
Figura 2. IP de todos los ordenadores
Objeto: Son los que forman la estructura principal de OpenERP. Son los
modelos en los cuales se establecen los campos con sus diferentes tipos. Son una
entidad propia que como conjunto forman parte de un módulo o una aplicación.
Mediante un campo relación dentro de la pantalla en que se ve un objeto podrá haber
otros objetos. Sucede esto ,por ejemplo con los one2many.

introducir datos en la base de datos. Hay dos tipos de campos, los básicos y los
relacionales, los básicos solos sirven para introducir datos básicos y los relacionales
permiten establecer relaciones entre los objetos. Los campos estarán definidos por un
nombre “real” y por uno “descriptivo” que será el que realmente se visualice, en
ocasiones ni siquiera aparece el descriptivo por tratarse de un campo de texto, por
ejemplo en el interior del cual se inserta un “placeholder” es decir una descripción que
desaparece en cuanto se empieza a escribir por encima. Esta distinción es importante
ya que a la hora de importar/exportar los datos será el nombre “real” el que aparezca.

mejor.
dibujado cada uno. Hay 6 tipos de vista distintos que se irán visualizando a lo largo de
la guía: Kanban, Lista, Formulario, Calendario, Gantt y Gráfico . No es necesario que
un objeto las tenga todas, pero al menos si la vista Lista o arbol, que será de la que se
puedan importar los datos y la vista Formulario que será en la que se cubran
manualmente los datos.

596
2. Crear, eliminar, duplicar base de datos.
En un principio al instalar el programa ya está una creada. Si se desea crear

otra desde la pantalla inicial se pulsa “gestionar bases de datos”.
Figura 3. Acce so crear base de datos
Siguiendo las instrucciones de pantalla se crea una nueva base de datos con el
nuevo nombre y la traducción que corresponda, en este caso español. Desde este
apartado también se podrán borrar o duplicar bases de datos.
Figura 4. Crear base de datos.
Para eliminar una base de datos pedirá la contraseña maestra, en el caso de

una nueva como se ve ya aparece por defecto. La contraseña maestra es “admin”.
Habrá que cambiar esta contraseña maestra, ya que al estar el ERP conectado a
internet, cualquiera podría manipularlo.
597
3. Bases de datos y módulos propios adaptados a Acluxega.
Se van a crear en un principio tres bases de datos una base de datos general
llamada “ACLUXEGA”, una base para los cursos llamada “curso_nombre” y otra para
los congresos “congreso”. Se accederá a ellas desde la pantalla inicial.
En el caso de los módulos de Openerp se instalaran desde configuración,

mediante aplicaciones. Cada aplicación corresponde a distintas partes de módulos.
Para instalar un modulo propio es necesario que el usuario tenga activadas las
“características técnicas”. Si la base de datos es nueva no están activadas. Se hac e
desde:
“configuración/usuarios/administrator(o nombre si se crea uno)/permisos de acceso”
Se pulsa actualizar en el navegador y se continúa.
En el caso de los módulos propios creados y personalizados pueden darse dos

casos:
-Que el que los ha creado (en este caso Fernando) los haya insertado en el
sistema y estén listos para instalar. En ese caso, que será el habitual, bastará con ir al
apartado “Módulos instalados” y escribir el nombre del módulo y pulsar instalar. Por
ejemplo en la imagen “curso”.
Figura 5. Instalar módulo personalizado.
-Que el que los ha creado los comparta a través de la carpeta compartida o de

correo electrónico. En la carpeta “Fernando” hay un acceso directo a “addons” se
pegan los módulos y se reinicia el servidor. Se hace en la carpeta servicios,
buscando Openerp y pulsando reiniciar.
Figura 6. Reiniciar el servidor.
598
A continuación se abre Openerp desde el sistema habitual como se ha

explicado anteriormente. Se pulsa en “actualizar lista de módulos” y después desde
módulos instalados se repite el proceso anterior buscando el módulo. Para que
aparezca este menú habrá que tener activadas las características técnicas del usuario.
Esto se hace en “configuración/usuarios”, se selecciona el usuario y se activa la
pestaña.
Figura 7. Activar característica s técnica s.
Se pulsa actualizar y como se puede comprobar en todos los módulos se

pueden ver nuevos objetos que se utilizan para configurar.
Figura 8. Característica s técnica s activada s.
599
A continuación se detallan los módulos y aplicaciones a instalar para las dos

bases de datos creadas en un principio.
Base de datos general: ACLUXEGA_GENERAL
Aplicaciones instaladas
- -Events organisation .
- - Calendar.
- -Adress book.
- -Project Management (Gestión de proyectos).
- -Acounting and finance (Contabilidad y finanzas).
- Employee Directory (Directorio de empleados).
- Recriuitment Process(Proceso de selección ).
- Notes.
- Timesheets.(Partes de tiempo .)
- Leave management.(Gestión de ausencias ).
- Expense management.(Gestión de gastos ).
- Employee apraisals.(Evaluación de empleados ).
Aplicaciones que se instalan con estas:
- Social Network
- Elvoincing & paiments
Módulos propios creados
- Lista de correos.
- Asociados.
- Legislación
- Subvenciones
- Geotermia
600
Figura 9. Módulos a instalar “ACLUX EGA_GENERAL”
Base datos cursos: CURSO_NOMBRECURSO
-Events organisation.
- Calendar.
-Adress book.
-Project Management.
-Acounting and finance.
-Recriuitment Process.
- Cursos
601
Figura 10. Módulos a instalar “CURSO_NOMBRECURSO”.
Base datos congreso: CONGRESO_NOMBRE
-Events organisation .
- Calendar.
-Adress book.
-Project Management.
-Acounting and finance
-Recriuitment Process.
- congreso
602
Figura 11. Módulos a instalar “CONGRESO_NOMBRECONGRES O”.
603
4. Modificaciones en los menús. Modo gráfico.
Esto es muy útil para enlazar en un módulo objetos de otro módulo. Al hacerse
en modo gráfico habrá que hacerlo cada vez que se cree una nueva base de datos.
Se hace por comodidad.
Tal y como están diseñadas las bases de datos en principio solo se plantean
dos modificaciones y ambas en el mismo objeto. En la base de datos del “curso” lo que
se hará será enlazar “Empleados” del módulo de recursos humanos, con el módulo
personalizado “curso” añadiendo el menú “Profesorado”. En la base de datos de
“congreso” se enlazará el mismo menú, pero esta vez dentro del menú
“organizadores”.A continuación se explica cómo hacer el primero de los cambios, ya
que el segundo va implícito en el mismo.
En primer lugar habrá que conocer el nombre del objeto que se quiere cambiar.
En este caso se trata del “hr.employee”, pero si no se conociese, para hacerlo hay que
activar el modo desarrollador y verlo.Esto se hace en la pestaña que se abre a la
derecha, en la misma de cerrar sesión pulsando “Acerca de openerp” y en la ventana.
A efectos prácticos de uso normal solo se activará este modo para realizar esta tarea o
la de configurar permisos.
Figura 12. Modo desarrollador.
Con este modo activado se podrán hacer múltiples tareas, pero la más
importante será conocer el nombre de los objetos. En la vista formulario, bastará con
ponerse encima de un campo y ahí se especifica el nombre del campo y del objeto.
604
Figura 13. Comprobación del nombre de un objeto.
Como puede apreciarse el nombre del objeto “empleados” es “hr.employee”.
A continuación se va al objeto “Modelos” situado en

“Configuración/Técnico/Estructura de la base de datos” y se busca el nombre del
objeto que se quiere poner en otro lugar también.
Figura 14. Selección de un objeto.
Se entra y en la parte inferior se pulsa crear menú.
Figura 15.Estructura del objeto.
605
En este caso se puede crear un menú o utilizar uno existente. Se utilizará uno
existente en el caso, por ejemplo, del módulo “congreso” en el cual se quiere insertar
dentro de “organización”.se pulsa buscar y el resultado es tal que este:
Figura 16. Enlazar con menú existente.
Hay que tener en cuenta que como el objeto es el mismo y lo único que varía
es el menú por tanto todas las modificaciones en uno se reproducen en el otro.
Sin embargo, también se puede, dentro de un módulo crear un menú. En la

barra de selección de menú padre anterior se pulsa “crear un menú”.
Figura 17. Creación de menú padre.
Si en “menú padre” en vez de seleccionar el módulo existente “Curso” se

pulsase crear, se estaría creando un nuevo módulo en modo gráfico. En este caso se
ha seleccionado uno existente, quedando así:
606
Figura 18. Creación de menú profesore s.
Tal y como se puede apreciar en el resultado aunque se le haya llamado

“profesores” sigue siendo el mismo objeto que “Empleados” y todo lo que se ponga en
uno afecta al otro. Este es el resultado:
Figura 19. Resultado de la modificación en modo gráfico.
4.1. Eliminar menú.
Si lo que se quiere es eliminar un menú se acude al directorio

“configuración/interfaz de usuario/ Elementos menú” y seleccionando el módulo en que
se quieran modificar se pulsa editar.
607
Figura 20. Elementos menú
No es necesario eliminar el menú al completo, dentro de cada uno de ellos

puede accederse a los menús de los objetos y borrar uno en particular.
608
5. Crear usuarios y cambio de claves.
Se crearan usuarios del OpenERP desde el apartado de “Configuración /

Usuarios”. No se debe confundir a los usuarios con los empleados, pueden ser los
mismos, pero no todos los empleados tienen por qué ser usuarios.
Para cambiar la contraseña una vez creado el usuario aparece una ventana
“más” y desde ahí se puede cambiar las contraseñas además, de por ejemplo, asignar
tareas.
Figura 21. Creación de usuario.
609
6. Permisos
Lo más recomendable primero es activar el modo desarrollador para conocer

los campos y objetos. También será necesario tener activadas las características
técnicas para que aparezcan todos los menús.
Para facilitar la labor en la siguiente lista se adjuntan los nombres de los

objetos de los módulos que será más común instalar, curso y congreso.
Objetos
Curso Congreso
curso.ficha congreso.ficha
curso.periododematricula congreso.programa
curso.periododedocencia congreso.organizadores
curso.listapreinscritos congreso.entidadescolaboradoras
curso.listamatriculados congreso.patrocinadores
curso.asistencia congreso.presentador
curso.evaluacion congreso.ponentes
curso.listabajas congreso.expositores
curso.fichaalumnos congreso.listapreinscritos
curso.tutores congreso.listamatriculados
congreso.medios
congreso.contactos
congreso.webpropia
congreso.publicidad
congreso.noticiasgen
congreso.imagenes
Durante la creación del usuario en “permisos de acceso” se configurarán a que

módulos y objetos tiene acceso. En este apartado no se incluyen los módulos propios
que habrá que configurar en el objeto “grupos”, dentro del mismo menú. Tampoco se
podrán de aquellos que se hayan modificado.
Habrá que crear un grupo y dentro de este una aplicación y a partir de ahí
moviéndose por las pestañas se seleccionan los permisos de acceso. Los módulos
que ya han quedado instalados se ha seleccionado la aplicación “compartir” con
nombre “usuario” o”usuariodos” para separar en función del número de objetos. Por
ejemplo en la base de datos “ACLUXEGA _GENERAL” se han dado los permisos para
“Lista de correos” y “asociados” al nombre “usuarios” y los otros tres a “usuariodos”
610
Figura 22. Configurar grupo.
En “permisos de acceso” será donde haya que poner el nombre del objeto, en
este caso es “curso.ficha” aunque al introducirlo ya pone automáticamente “Ficha”. En
principio habrá que ir objeto a objeto, no podrá seleccionarse un módulo completo.
Esto presenta como inconveniente lo laborioso que resulta, pero por otra parte la
ventaja de poder compartir las partes que interesen.
Figura 23. Permisos
Además no será necesario crear un grupo por cada módulo, pueden insertarse
objetos de cualquier parte y así hacerlo todo de una vez.
Como recomendación se evitará el uso de acentos en el nombre de los

objetos, en la programación ya no los tiene y para evitar un posible error mejor
evitarlos.
611
Este es el resultado, en vez de verse el módulo completo solo se ve el objeto

compartido.
Figura 24 Resultado de la asignación de permisos.
612
7. Importar-exportar datos.
En primer lugar habrá que asegurarse de que en

“configuración/configuraciones generales” está activada la casilla de importar-exportar.
Esto solo podrá hacerlo el administrador, Belén en este caso.
Figura 25. Configuracione s generales.
7.1. Exportar.
Solo se podrán exportar datos de la vista “lista” o de las vistas de gráficos. Se

seleccionarán las entradas a exportar y se pulsará la tecla “más” y dentro de ella
“exportar”. En formato podrá exportarse como CSV, archivo separado por comas o en
Excel. Preferentemente se utlizará Excel. Se agregan los campos a importar y se
pulsa “exportar a fichero” y será mejor abrirlo que guardarlo.
Figura 26.Exportar.
613
El resultado es el que se ve en la imagen a continuación. Resaltar el campo ID

que es propio de la estructura de Openerp y que servirá para introducir los datos.
Figura 27. Exportar Excel.
7.2 Importar datos.
Aunque lo habitual será introducir a través de la vista formulario los datos a

mano, también puede darse el caso, especialmente al iniciar la base de datos, de
querer introducirlos directamente con el Excel. Habrá que conocer primeramente el
nombre de los campos, el nombre con el cual han sido programados. Ello puede
hacerse como se ha visto anteriormente activando el modo desarrollador o lo más
práctico que es exportar el último valor y partiendo de ese archivo copiar los datos en
esa estructura, tal y como se ve en la imagen anterior. También podrán hacerse
plantillas para no tener que buscarlas cada vez. En el caso de los módulos propios ya
están hechas.
Figura 28. Importar.
El archivo habrá que guardarlo como “CSV (delimitado por comas)” y será el
que se importe.
614
Figura 29. Guardar como CSV.
Cuando se importe habrá que tener cuidado con las opciones de importación
porque si no puede dar lugar a errores. Se utilizarán las que aparecen en la imagen
donde habrá que seleccionar en codificación “Windows 1252” y en separador “punto y
coma”.
Figura 30. Importación en OpenERP.
Finalmente este es el resultado:
Figura 31. Resultado de la importación.
615

PFC Fernando Vazquez Novoa Marcadores

Cargado por

Copyright:

Formatos disponibles

PFC Fernando Vazquez Novoa Marcadores

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PFC Fernando Vazquez Novoa Marcadores

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE VIGO

Escuela Técnica Superior de Ingeniería de Minas de Vigo

Departament o de Ingeniería de Rec ursos Nat urales y Medio Ambiente

PROYECTO FIN DE CARRERA

IMPLA NTACIÓN DE UN E RP DE CÓDIGO AB IERTO EN LA ASOCIA CIÓN CLÚS TER DA

Autor: Fernando V ázquez Novoa

Dirección: Rafael Barrionuevo Giménez

Vigo, Junio de 2014

Vigo, 7 de Mayo de 2014

El director D. Rafael Barrionuevo Giménez del proyecto fin de carrera elaborado

En este proyecto se ha llevado a cabo un estudio del funcionamiento del ERP

CÓDIGOS UNESCO DE CLASIFICACIÓN: 3308/99 5306/02

5.ASOCIACIÓN CLÚSTER DA XEOTERMIA GALEGA ( ACLUXEGA) 95

6. IMPLANTAR OPENERP 107

7. ANÁLISIS DE COSTES DE OPENERP 157

En la actualidad y dado el vertiginoso ritmo de evolución de la tecnología,

En entornos propios de esta titulación como la minería, obra civil, medio

- Estudio sobre los sistemas de planificación de recursos empresariales,

Un ERP es un sistema integral de gestión empresarial que está diseñado para

Lo más destacable de un ERP es que unifica y ordena toda la información de la

La implantación de un ERP conlleva la eliminación de barreras ínter

Los sistemas ERP unifican información de las diferentes áreas (finanzas,

La implementación de los ERPs no es fácil, se requiere de un largo período de

Los sistemas ERP son sistemas de gestión de información que integran y

reduciendo en tiempo real las tareas repetitivas y permitiendo el aumento de la

Los ERP se consideran software integrado en contraposición con el software a

Un aspecto importante a entender cuando se plantea la adquisición de un ERP

Para que un sistema sea considerado de tipo ERP debe cumplir

Figura 2. 1 Características ERP.

2.2 Beneficios de un ERP

Durante la implantación se van a ir definiendo todos los procesos en la

Esta sistematización, lleva a una simplicidad abrumadora en el funcionamiento

Una vez implantado, va a ser mucho más fácil obtener un certificado de

El ERP va a permitir afrontar con éxito la tendencia de reducción de plazos de

Un ERP es también un recolector de datos, estos datos, con el tiempo, tienen

Como se va a disponer de toda la información, se podrá adoptar una actitud

A continuación se enumeran 7 de los beneficios más importantes:

Beneficio 1: Ahorro a largo plazo.

Uno de los mayores beneficios es el ahorro. De su definición más básica

Beneficio 2: Toma de decisiones.

Se dice que un software de este tipo es una decisión estratégica. Facilita la

Beneficio 3: Calidad o relación con el cliente.

Una correcta implantación de un ERP permite responder ante el cliente en un

La información crucial de la empresa estará debidamente protegida en dos

Beneficio 5. Productividad de los empleados.

Quizás es el beneficio más evidente y lógico de implantación de un ERP,

Beneficio 6. Estandariza la organización.

Cuando toda la plantilla de distintos departamentos trabaja con el mismo programa,

Beneficio 7. Impulsa a crecer ordenadamente.

Normalmente todas las empresas quieren crecer a corto o largo plazo. Un

En 2002 Shanks y Seddon realizaron un trabajo que presentaba un modelo de

Las actividades operacionales involucran los procesos diarios de adquisición y

ciclo; 3) mejoras en la productividad; 4) mejora de la calidad; y 5) mejora del servicio al

Las actividades de gestión involucran la distribución y control de los recursos de la

Las tecnologías de información en complemento con otros recursos pueden ser

4. Dimensión infraestructura de tecnologías de información.

Los sistemas ERP no se asocian directamente con inversión en infraestructura de

Los beneficios organizacionales surgen del uso de un sistema ERP en términos de

Existen características que distinguen a un sistema ERP del software

Las tres características esenciales de un sistema ERP son: