S I S T E M AS DE GE S T I N E M P RE S ARI AL

1.IdentificacindesistemasERPCRMysolucionesBI

Las empresas necesitan, para una ptima gestin empresarial, un soporte

informtico adecuado a las necesidades de la empresa. Por este motivo hay en el
mercado diversos programas informticos: gestin comercial, compraventa,
facturacin, contabilidad, nminas, produccin, relacin con los clientes ...
muchos de ellos englobados en paquetes que se distribuyen como unidades o de
forma modular.

Los sistemas ERP, del ingls Enterprise Resource Planning , conocidos

ampliamente como sistemas de planificacin de recursos empresariales, aunque el
TERMCAT (centro de terminologa de la lengua catalana) traduce el trmino ERP
como software de gestin integrada, son sistemas que integran o pretenden
integrar todos los datos y procesos de una organizacin en un sistema unificado.
Esta definicin puede llevar a confundir los ERP con los paquetes comerciales que
engloban varios programas. Es importante conocer la frontera entre ambos tipos
de productos.

Los sistemas CRM, del ingls Customer Relationship Management , conocidos

como sistemas de gestin de la relacin con los clientes, son sistemas que dan
soporte a la gestin de las relaciones con los clientes, a la venta y al marketing.

Las soluciones BI, del ingls Business Intelligence , conocidas como soluciones de
inteligencia de negocio o soluciones de inteligencia empresarial, son un conjunto
de herramientas destinadas a facilitar datos a los dirigentes empresariales,
obtenidas a partir de las datos de los sistemas ERP-CRM, con el objetivo de
ayudar a la toma de decisiones. El abanico de soluciones BI es amplio: desde
herramientas de elaboracin de informes hasta sofisticadas herramientas de
gestin de cubos OLAP.

Antes de entrar en la instalacin, configuracin, explotacin y adecuacin de

sistemas ERP-CRM y soluciones BI, nos conviene conocer:

1. Los tipos de licenciamiento actuales.

2. Los tipos de despliegue (implantaciones) actuales y requerimientos asociados.
3. Las funcionalidades normalmente proporcionados por las aplicaciones ERP /
CRM / BI.
4. Los principales productos existentes en el mercado.

1.1.Licenciasdesoftware

En el mercado actual encontramos un gran nmero de aplicaciones que pueden

tener utilidad en las empresas. Todas ellas van acompaadas de un determinado
tener utilidad en las empresas. Todas ellas van acompaadas de un determinado
tipo de licencia. Por otra parte, ha proliferado una gran nmero de tipos de
licencias de software. En consecuencia, es necesario poder reconocer la licencia
que acompaa cada software y sus implicaciones.

Una licencia de software es la autorizacin o permiso concedido

por los autores del software para poder utilizar, bajo unos
derechos y deberes.

Debido a que los derechos y deberes que los autores pueden asignar a sus obras
son de diversos tipos, han aparecido un gran nmero de tipos de licencias que,
bsicamente, podemos clasificar en dos grandes grupos: software propietario y
software libre.

Por software libre (free software ) entendemos aquel que

respeta la libertad total del usuario sobre el producto adquirido.
Por software privativo entendemos todo software que no sea
libre.

Nuestro objetivo no es conocer la evolucin que han tenido los conceptos software
libre y software privativo , sino conocer los conceptos existentes y utilizados en el
momento actual.

Software privativo
Hay bastante controversia en cuanto a la
nomenclatura de software propietario. As, otros
trminos que se utilizan son software propietario,
software esclavo, software cerrado, software
privado y software no libre. El motivo de la
controversia radica en las connotaciones de los
diversos vocablos.

En cuanto al software libre, es necesario saber que, segn la Free Software

Foundation, un software es libre cuando garantiza las cuatro libertades siguientes
(enumeradas a partir del valor cero):

1. Libertad de utilizar el programa para cualquier propsito.

2. Libertad de estudiar el funcionamiento del programa, modificndolo y
adaptndolo a nuevos requerimientos.
3. Libertad de distribuir copias del programa.
4. Libertad de mejorar el programa y hacer pblicas las mejoras, de modo que
toda la comunidad se beneficie.

La Free Software Foundation es una organizacin

 creada en octubre de 1985 por Richard Stallman y
otros promotores del software libre, para difundir
este movimiento.

Ante esta definicin, cualquier software que viole alguna de las cuatro libertades
anteriores pasa a ser software privativo.

A menudo, el concepto software libre se confunde con software gratuito y / o con

cdigo abierto y los tres conceptos son diferentes, a pesar de tener puntos en
comn.

LogotipodeSoftware
Libre

La confusin entre software libre y software gratuito viene dada por la

ambigedad de la palabra free en la lengua inglesa, donde tiene doble
significado: libertad y gratuidad. Ciertamente, la mayora de software libre suele
ser gratuito, pero esto no es obligatorio. Puede haber software libre no gratuito y
software gratuito no libre. El concepto ingls a utilizar para hacer referencia al
software gratuito (sea o no libre) es freeware .

La confusin entre software libre y cdigo abierto ( open source ) es simple de

explicar, ya que el software libre, para garantizar las libertades 1 y 3, obliga a tener
acceso al cdigo del software, es decir, el software libre tiene el cdigo abierto.
Pero detrs de las palabras software libre y cdigo abierto hay dos movimientos
bien diferenciados desde el punto de vista filosfico.

LogotipodeOpen
SourceInitiative

La utilizacin del concepto de cdigo abierto apareci por primera vez en 1998,
cuando algunos usuarios del movimiento por el software libre lo utilizaron para
sustituir el nombre software libre debido a la ambigedad del trmino free en la
lengua inglesa. Pero para algunos seguidores del movimiento por el software libre
la sustitucin no se consider adecuada ya que se perda el sentido tico y moral
implcito en la palabra libertad utilizado en la definicin del software libre. As se
produjo una escisin del movimiento por el software libre, apareciendo la Open
Source Initiative, fundada por Bruce Perens y Eric S. Raymond.

La iniciativa por el cdigo abierto exige que la distribucin del software de cdigo
abierto debe verificar el siguiente declogo:

1. Libre redistribucin: el software debe poder ser regalado o vendido

libremente.
 libremente.
2. Cdigo fuente: el cdigo fuente debe estar incluido o debe poder obtenerse
libremente.
3. Trabajos derivados: la redistribucin de modificaciones debe estar permitida.
4. Integridad del cdigo fuente del autor: las licencias pueden requerir que las
modificaciones sean redistribuidas slo como parches.
5. Sin discriminacin de personas o grupos: no se puede dejar a nadie fuera.
6. Sin discriminacin de reas de iniciativa: no se puede restringir a que haga
uso del programa en un campo especfico de actividad. Por ejemplo, no se
puede impedir que el programa sea utilizado en un negocio o que se utilice
para la investigacin gentica.
7. Distribucin de la licencia: se debe aplicar los mismos derechos a todos que
reciba el programa.
8. La licencia no debe ser especfica de un producto: el programa no se puede
licenciar slo como parte de una distribucin mayor.
9. La licencia no debe restringir otro software: la licencia no puede obligar a que
algn otro software que sea distribuido con el software abierto deba tambin
ser de cdigo abierto.
10. La licencia debe ser tecnolgicamente neutral: la aceptacin de la licencia no
puede basarse en una tecnologa o un estilo de interfaz. Por ejemplo, no se
puede requerir la aceptacin de la licencia a travs de un clic de ratn o de
ninguna forma especfica del medio de soporte del software.
El declogo del cdigo abierto es compatible con las cuatro libertades del software
libre y, desde un punto de vista prctico, ambos movimientos son equivalentes,
pero son totalmente incompatibles desde un punto de vista filosfico.

Para los defensores del cdigo abierto, el hecho de tener acceso total al cdigo
fuente del software es una cuestin prctica que posibilita que el software
evolucione, se desarrolle y mejore a una alta velocidad, ms alta que la que se
puede alcanzar en los procesos convencionales de desarrollo de software. Para los
defensores del cdigo abierto libertades esgrimidas por el software libre no tienen
importancia, el objetivo es, nicamente, tener acceso al cdigo para conseguir un
cdigo mejor. En consecuencia, por el movimiento del cdigo abierto, el cdigo
cerrado nunca podr ser mejor que el cdigo abierto.

Para los defensores del software libre lo que importa es la defensa de las
libertades, el acceso al cdigo es consecuencia de las libertades 1 y 3 y la calidad
del cdigo cerrado no tiene porque ser inferior a la del cdigo abierto.

Figura 1.1. Diferentes categoras del software

La distincin de los conceptos software libre , software propietario y cdigo
abierto es el primer paso para categorizar un software, pero nos falta conocer ms
conceptos utilizados actualmente. La figura 1 .1 , original de Chao-Kuei y
posteriormente actualizada por otros, sita las diferentes categoras del software,
que nos hace falta identificar:

1. Software de dominio pblico: software que no est protegido con copyright.

El copyright refleja la posesin del derecho de explotacin y, por tanto, slo
puede hacerse constar el titular o cesionario de ese derecho.
2. Software copyleft (copia permitida): las licencias copyleft son aquellas que
ejercen los autores del software, amparados en la legislacin de copyright,
para permitir la libre distribucin de copias y versiones modificadas de una
determinada obra. La mayora de las licencias copyleft exigen que los
derechos concedidos se mantengan en las versiones modificadas del
producto.
3. Software bajo GPL : la licencia GPL (Licencia Pblica General de GNU) es
una licencia creada por la Free Software Foundation, orientada a proteger la
libre distribucin, modificacin y uso del software, de modo que el software
cubierto por esta licencia es software libre y queda protegido de cualquier
intento de apropiacin que restrinjan las libertades del software libre. La
formulacin de GPL es tanto restrictiva que impide que el software bajo esta
licencia pueda ser integrado en software propietario.
4. Software bajo licencias laxas o permisivas: las licencias laxas o permisivas son
licencias de software libre flexibles respecto a la distribucin, de modo que el
software pueda ser redistribuido como software libre o privativo. Son licencias
sin copyleft, ya que consideran que el trabajo derivado no tiene porque
mantener el mismo rgimen de derechos de autor que el original. Esto da
total libertad a quien recibe el software para desarrollar cualquier producto
derivado, y le permite elegir entre el amplio abanico de licencias existentes.
Desde el punto de vista de los usuarios, sin embargo, estas licencias se pueden
considerar como una restriccin a las libertades que defiende el software libre.
Ejemplos de licencias de este tipo son las licencias BSD y MIT .
5. Software de prueba ( shareware ): las licencias shareware autorizan la
utilizacin de un programa para que el usuario lo evale y posteriormente lo
adquiera. Este software suele tener unas limitaciones, ya sea en el tiempo de
utilizacin o en las funcionalidades permitidas.

1.2.Tiposdedesarrolloyrequerimientosasociados

Tradicionalmente, las aplicaciones ERP / CRM / BI han sido alojadas en las

instalaciones de las organizaciones compradoras de las licencias de la aplicacin,
desarrollo conocido mayoritariamente como on-premise y, en menor grado, como
in-house . Pero eso est cambiando.
in-house . Pero eso est cambiando.

La historia de los tipos de despliegue de las aplicaciones de gestin empresarial ha

ido ligada a la evolucin que ha tenido la tecnologa. En estos momentos podemos
decir que estamos entrando en una nueva poca: la poca de la informtica en
nube ( cloud computing ) y con ella, varios modelos de desarrollo (IaaS, PaaS y
SaaS) que se impondrn o convivirn con el modelo tradicional on-premise .

Para saber dnde estamos nos conviene, en un primer lugar, conocer los tipos de
desarrollo que ha habido a lo largo de la historia y, para poder llevar a cabo
despliegues en el momento actual, necesitamos poder distinguir los
requerimientos asociados.

1.2.1.Desdelosmainframeshastaelcloudcomputing
En la primera poca (la dcada de los 60 y los 70) las aplicaciones residan en
grandes ordenadores ( mainframes ) ubicados en las dependencias de la
organizacin y los usuarios disponan de terminales (pantallas sin memoria ni
capacidad de proceso) conectadas con el ordenador central.

La segunda poca llega en la dcada de los 80, con la eclosin de los ordenadores
personales. Las aplicaciones empresariales fueron adoptando la arquitectura de
dos capas (cliente-servidor), en las que sigue existiendo el ordenador central
(servidor-uno o varios-) que contiene las bases de datos y en la que la terminal del
anterior poca queda sustituida por el ordenador personal que, al disponer de
memoria y capacidad de proceso, incorpora las aplicaciones a ejecutar. La
arquitectura cliente-servidor tropieza pronto con el problema del mantenimiento
de las aplicaciones, ya que cada vez que la lgica de negocio cambia o evoluciona
necesario actualizar la aplicacin en todos los ordenadores personales clientes.

Por este motivo, se adopta pronto la arquitectura de tres capas (presentacin-

negocio-datos) ilustrada en la figura 1 .2 , en la que los clientes tienen aplicaciones
sencillas que nicamente presentan los datos suministrados por uno o varios
servidores de aplicaciones, contenedores de la capa de negocio, que confeccionan
aquellos datos a partir de la informacin suministrada por los servidores de la
capa de datos.

Figura 1.2. Arquitectura de tres capas

La tercera poca se inicia a mediados de la dcada de los 90, coincidiendo con el

La tercera poca se inicia a mediados de la dcada de los 90, coincidiendo con el
boom de Internet y va acompaada de la continua mejora del ancho de banda.
Las aplicaciones empresariales buscan mecanismos para facilitar la conexin de
los rganos de mando de las empresas desde ubicaciones remotas. Esto hace que
proliferen softwares que, aprovechando Internet, facilitan la conectividad remota
y abren en los dispositivos remotos (porttiles y PDAs) sesiones cliente contra el
servidor de aplicaciones. Seguro que uno de los softwares ms conocidos es el
escritorio remoto del sistema operativo Microsoft Windows. Pero estos softwares
presentan un problema: hay que tener instalado en el dispositivo remoto el
software adecuado para poder establecer la conexin y esto no siempre es factible.
Ahora bien, sin miedo a equivocarnos, cul es el software que tienen hoy en da
todos los dispositivos que se conectan a Internet, sea cual sea el sistema operativo
utilizado (Windows, Linux, Mac, iOS, Android ...)? Un navegador, verdad? En
consecuencia, se trata de conseguir que a travs del navegador podamos ejecutar
las aplicaciones empresariales.

Durante la primera dcada del siglo XXI, an dentro de la tercera poca, las
aplicaciones empresariales se van acomodando a la nueva situacin tecnolgica y
facilitan soluciones accesibles desde los navegadores web. La arquitectura de tres
capas sigue siendo vlida para la nueva situacin. Simplemente hay que aadir
un servidor web ante el (los) servidor (es) de aplicaciones para permitir la
conexin desde los navegadores. Los clientes tradicionales pueden seguir
existiendo y se comunican directamente con el (los) servidor (es) de aplicaciones.
La figura 1 .3 ilustra la situacin.

En esta nueva arquitectura hay desavenencias sobre la capa donde ubicar el

servidor web. Hay autores que, debido al hecho de que el servidor web
simplemente se encarga de confeccionar las pginas que se visualizan en el
navegador, lo consideran como parte de la capa de presentacin. Otros, como que
es un servidor de aplicaciones, el juntan con los servidores de aplicaciones donde
se encuentra la capa de negocio. Por ltimo, hay autores que hablan de
arquitectura de cuatro capas, destinando una capa especficamente al servidor
web.

La arquitectura de cuatro capas (aplicaciones empresariales que permiten el

acceso web) es de extrema actualidad. Las aplicaciones que no incorporan esta
funcionalidad estn abocadas a la desaparicin. Pueden sobrevivir debido al coste
que supone un cambio total de software pero difcilmente podrn ampliar su
cuota de mercado.

Figura 1.3. Arquitectura de tres (o cuatro) capas para web

Finalmente, nos encontramos en el futuro que ya es presente: la cuarta poca. La
computacin en nube ( cloud computing ) es un sistema de almacenamiento y
uso de recursos informticos basado en el servicio en red, que consiste en ofrecer
al usuario un espacio virtual, generalmente en Internet, en los que puede disponer
de las versiones ms actualizadas de hardware y software.

Hay tres modelos de cloud:

1. Infraestructura como servicio (IaaS, de Infrastructure as a Service ),

en el que el usuario contrata nicamente las infraestructuras tecnolgicas
(capacidad de proceso, de almacenamiento y / o de comunicaciones) sobre
las que instala sus plataformas ( sistemas operativos) y aplicaciones. El
usuario tiene el control total sobre las plataformas y aplicaciones, pero no
tiene ningn control sobre las infraestructuras.
2. Plataforma como servicio (PaaS, de Platform as a Service ), en el que el
usuario contrata un servicio que le permite alojar y desarrollar sus propias
aplicaciones (ya sean desarrollos propios o licencias adquiridas) en una
plataforma que dispone de herramientas de desarrollo para que el usuario
pueda elaborar una solucin, en este modelo, el proveedor ofrece el uso de su
plataforma que a su vez se encuentra alojada en infraestructuras, de su
propiedad o ajena. El usuario no tiene ningn control sobre la plataforma ni
sobre la infraestructura pero mantiene el control total sobre sus aplicaciones.
3. Software como servicio (SaaS, de Software as a Service ), en el que el
usuario contrata la utilizacin de unas determinadas aplicaciones sobre las
que nicamente puede ejercer acciones de configuracin y parametrizacin
permitidas por el proveedor. El usuario no tiene ningn control sobre la
aplicacin, la plataforma y la infraestructura.
Los modelos IaaS y PaaS ya hace tiempo que se estn utilizando (desde que el
ancho de banda lo ha hecho posible) y el modelo SaaS tambin en aplicaciones
vinculadas a Internet, como por ejemplo el correo electrnico. En cambio, hasta
hace bien poco (hacia el ao 2010) no han comenzado a aparecer aplicaciones
empresariales (ERP / CRM / BI) bajo el modelo SaaS.

No debemos confundir tener una aplicacin empresarial en la nube, de la que

nosotros hemos adquirido licencias pero hemos optado por tenerla instalada en
Internet (modelo IaaS o PaaS) en lugar de tenerla en nuestra casa ( on- premise
), con contratar la utilizacin de una aplicacin que alguien tiene alojada en la
nube (modelo SaaS) y por la que no debemos adquirir ninguna licencia sino
nicamente prestaciones (nmero de usuarios y funcionalidades).

Entre los beneficios del modelo SaaS, hay que considerar:

 Integracin comprobada de los servicios en red.
Prestacin de servicios a nivel mundial.
Ninguna necesidad de inversin en hardware.
Implementacin rpida y sin riesgos. La puesta en marcha slo precisa de la
configuracin y parametrizacin permitida por el proveedor.
Actualizaciones automticas rpidas y seguras.
Uso eficiente de la energa, ante la energa requerida para el funcionamiento
de una infraestructura on-premise .

Entre los inconvenientes del modelo SaaS, hay que considerar:

Dependencia de los proveedores de servicios.

Disponibilidad de la aplicacin ligada a la disponibilidad de Internet.
Miedo a sustraccin o robo de los datos "sensibles" del negocio, ya que no
residen en las instalaciones de las empresas.
Peligro de monopolios referentes a los servicios facilitados por los
proveedores.
Imposibilidad de personalizar la aplicacin, fuera de la configuracin y
parametrizacin permitida por el proveedor.
Actualizaciones peridicas que pueden incidir de manera negativa en el
aprendizaje de los usuarios de orientacin no tecnolgica.
Existencia de focos de inseguridad en los canales a recorrer para llegar a la
informacin, si no se utilizan protocolos seguros (HTTPS) para no disminuir
la velocidad de acceso.
Posible degradacin en los servicios suministrados por el proveedor ante el
aumento de clientes.

Parece que el modelo SaaS es una tendencia de futuro, sobre todo para pequeas
y medianas empresas que no disponen de recursos informticos adecuados para
poder responder al reto de adquirir licencias de una aplicacin empresarial (ERP
/ CRM / BI) y proceder a su instalacin / configuracin / personalizacin (ya sea
bajo modelo on-premise o bajo modelos IaaS / PaaS). Entonces, adentrarnos en
la implementacin, explotacin y adecuacin de los sistemas de gestin
empresarial parece una incongruencia, verdad? Tomemos nosotros por el lado
positivo: nos conviene introducirnos en los sistemas de gestin empresarial para
poder asesorar a las pequeas y medianas empresas que nos pidan consejo y para
llevar a cabo un correcto desarrollo en aquellas organizaciones para opten por los
modelos donde -premise o IaaS / PaaS.

1.2.2.Requerimientosparaundespliegue
Los despliegues de aplicaciones empresariales hoy en da pueden tener lugar bajo
dos modelos: on-premise (en casa del comprador de las licencias) o IaaS / PaaS
(dos modalidades de cloud). En cualquier caso, debemos pensar que la aplicacin
empresarial est desarrollada bajo la arquitectura web de tres capas y, por tanto,
es necesario disponer de:

Servidor de aplicaciones.
 Servidor de aplicaciones.
Servidor web, que posiblemente compartir hardware con el servidor de
aplicaciones.
Servidor de datos (SGBD) que muy posiblemente ser un SGBD relacional u
objeto-relacional.

Para atender a estas necesidades, hay que evaluar qu necesitamos y qu tenemos.

Esta tarea, sin embargo, escapa de las capacidades de un desarrollador de
software y son tareas para encomendar a consultores y administradores de
sistemas. Pero, es posible que nos toque hacerlo en una PYME que nos haya
pedido consejo y no haya consultores ni administradores de sistemas. En un caso
as, ser necesario:

Identificar los requerimientos directos de hardware (bsicamente RAM, CPU

y capacidad de disco duro) especificados por el software de gestin
empresarial que se ha de instalar, teniendo en cuenta la conveniencia o no de
virtualizar los servidores.
Identificar el SGBD con el que puede trabajar el software que se ha de
instalar. Algunas veces, un mismo software de gestin empresarial permite
utilizar diferentes SGBD, situacin en la que hay que analizar cul de ellos es
mejor en funcin de las necesidades de la empresa y de su coste, teniendo en
cuenta que hay muy potentes con versiones gratuitas. As, por ejemplo, una
tienda de bicicletas que adquiera un ERP para llevar la gestin informatizada
de los circuitos compraventa, inventario y contabilidad es posible que tenga
suficiente con un SGBD ofimtico como Microsoft Access, mientras que un
supermercado, con el mismo ERP , es posible que no tenga suficiente con un
SGBD ofimtico y precise uno de mayor potencia.
Identificar los requerimientos indirectos de hardware a partir de los
requerimientos de maquinaria propios del SGBD escogido.
Identificar mecanismos idneos para efectuar copias de seguridad de los
datos que permitan la recuperacin segn las necesidades de disponibilidad
de la organizacin. Todo el software de gestin empresarial debe ir
acompaado de un mecanismo de recuperacin adecuado que hay que testar
peridicamente. En una organizacin con disponibilidad 24 7 (es decir, que
no puede parar en ningn momento) habr que prever una estrategia de
copias de seguridad en caliente y esto repercutir en la eleccin del SGBD. En
cambio, en una organizacin que se detenga unas horas al da, podemos
prever una estrategia de copias de seguridad en fro. En cualquier caso
(copias en caliente o en fro), hay que pensar en la necesidad o no de
disponer de un sistema de copias que permita, ante una catstrofe, la
recuperacin de todos los movimientos efectuados desde la ltima copia de
seguridad hasta el momento de la catstrofe. Es decir, si la ltima copia de
seguridad (en caliente o en fro) es de las 0.00h de la noche anterior ya las
11.30 se produce una catstrofe que nos obliga a tirar de la copia de la noche
anterior, podemos asumir que perdido todos los movimientos efectuados
desde la noche anterior hasta el momento de la catstrofe? Los grandes
SGBD permiten activar mecanismos de registro diario ( log en ingls) que
almacenan cronolgicamente en un fichero las operaciones de procesamiento
de datos efectuadas en la base de datos, de modo que ante una cada del
sistema y de la ltima copia de seguridad, permiten restablecer todos los
movimientos efectuados en el sistema.
Identificar mecanismos para recuperar el sistema informtico ante un error
de hardware. Ante un mal funcionamiento de cualquier pieza de hardware
 de hardware. Ante un mal funcionamiento de cualquier pieza de hardware
(placa base, memoria, procesador o disco duro), aunque tengamos
contratado un servicio de mantenimiento, podemos asumir tener el sistema
parado? Hay ocasiones en que es posible (tienda de informtica, en la que si
hacemos alguna venta podemos anotar a mano) y ocasiones en que no es
posible (se imaginan una tienda en lnea de Internet en la que falla el sistema
informtico y debe estar parada unas horas?). En el caso de que no sea
posible una parada de horas, cul es la mejor solucin? Hoy en da la
utilizacin de servidores NAS para el almacenamiento con funcionalidades
RAID activadas conjuntamente con la virtualizacin de los servidores es,
posiblemente, la mejor solucin. Hay sistemas que permiten tener los
servidores virtualizados en un servidor de virtualizacin que cabe en un lpiz
ptico (es decir, puede no ser en un disco duro) de modo que, ante una
parada de la mquina (problema de placa base, procesador o memoria)
podemos utilizar el lpiz ptico para poner en marcha rpidamente el
servidor de virtualizacin en cualquier otra mquina (aunque tenga menos
prestaciones). Adems, un problema en el almacenamiento en el servidor
NAS queda cubierto por las funcionalidades RAID activadas, por lo que la
recuperacin puede ser muy rpida.

1.3.SistemasERP

Los sistemas ERP, del ingls Enterprise Resource Planning , conocidos

ampliamente como sistemas de planificacin de recursos empresariales , son
sistemas que integran o pretenden integrar todos los datos y procesos de una
organizacin en un sistema unificado.

As pues, segn la definicin anterior, un ERP debe permitir la gestin de la

produccin (si la organizacin incorpora procesos productivos), la gestin
completa de los circuitos de compraventa (logstica, distribucin, inventario y
facturacin) y la gestin financiera. Pueden incorporar tambin, en muchas
ocasiones, una gestin de recursos humanos. En la actualidad, muchos de ellos
incorporan una gestin de CRM (gestin de la relacin con los clientes).

Nuestro objetivo es instalar el ERP y configurarlo, parametrizarlo o adecuarlo a

las necesidades de la organizacin. Para poder abordar con garantas este objetivo
necesitamos conocer previamente como son los ERP, de la misma manera que un
mecnico de coches, antes de introducirse en la mecnica, debe conocer cmo es
un automvil.

1.3.1.RequerimientosparaserERP
En el mercado existen muchas aplicaciones de gestin empresarial y no todas ellas
pueden ser consideradas un ERP; son simplemente aplicaciones de gestin y hay
diferencias fundamentales entre las aplicaciones de gestin y los ERP, a pesar del
intento de muchas empresas, mediante estrategias de marketing, de intentar
vender sus productos con la denominacin ERP para obtener un valor agregado a
sus productos sin incrementar su funcionalidad.

Hay tres caractersticas fundamentales que definen un ERP:

Es un sistema integral : la propia definicin de ERP indica que es una

 Es un sistema integral : la propia definicin de ERP indica que es una
aplicacin que integra en un nico sistema todos los procesos de negocio de
la empresa, as mantiene los datos de una forma centralizada. Esto implica
que la informacin no puede estar duplicada y que slo se introduce una
nica vez. Esta definicin descarta:

Programas basados en mltiples aplicaciones (en ocasiones denominadas

suite ) independientes o modulares que duplican la informacin (a pesar
del enlacen automticamente).
Programas que no centralizan la informacin en una nica base de
datos.
Programas que no almacenan los datos en un SGBD sino que utilizan
sistemas gestores de ficheros, anteriores a los SGBD.

Es un sistema modular : un ERP se compone de varios mdulos donde

cada mdulo se centra en un rea de negocios de la empresa. Normalmente
los ERP tienen un mdulos troncales (bsicos) que se adquieren con la
compra del ERP (gestin de compraventa, control de inventario,
contabilidad) y otros mdulos que se adquieren segn las necesidades de la
organizacin ( gestin de proyectos, gestin de campaas, gestin de
terminales punto de venta, comercio electrnico, produccin por fases,
trazabilidad, gestin de la calidad, gestin de la cadena de suministro ...). Es
muy posible que una empresa que no necesite utilizar, en un inicio, todos los
mdulos que facilita el ERP, pero es importante saber que el ERP los
contempla, de cara a posibles necesidades de futuro. En caso de que sea
necesaria su utilizacin, la organizacin no se ver abocada a un cambio de
software en las reas donde ya estaba utilizando el ERP.
Es un sistema adaptable : no hay dos empresas iguales y, por ello, los
ERP deben permitir la adaptacin a necesidades diversas, objetivo que se
logra a travs de la configuracin y parametrizacin de los procesos
empresariales. Incluso algunos ERP disponen de herramientas de desarrollo
integrados que permiten desarrollar procesos de acuerdo a las necesidades de
cada empresa.

1.3.2.FuncionalidadesdelossistemasERP
Un ERP integra en un nico sistema todos los procesos de negocio de la empresa:
compraventa, produccin, contabilidad ... Para una persona que nunca haya
tenido contacto con un ERP o con una aplicacin de gestin empresarial, qu
quiere decir esto? Seguro que, si no se ha interaccionado nunca con un ERP o
aplicacin de gestin, se har cuesta arriba entender qu quiere decir "integra en
un nico sistema todos los procesos de negocio".

Es importante presentar, en un lenguaje comprensible para personas no formadas

en la rama administrativa-comercial, las funcionalidades que suelen facilitar los
programas de gestin empresarial. Y ya que estos materiales estn dirigidos a
informticos, utilizaremos palabras de la jerga informtica.

El software de gestin empresarial suele estar presentado en apartados (mens)

que se corresponden bastante a los mdulos instalados. Adems, siempre hay
unos apartados bsicos, existentes independientemente de los mdulos instalados.

Administracinoconfiguracin
Administracinoconfiguracin
El apartado de administracin o configuracin es bsico y es una opcin a la que
slo tienen acceso los usuarios administradores del producto y desde la que se
debe poder:

Definir los datos de la organizacin (nombre, razn social, domicilio fiscal,

NIF ...)
Configurar los parmetros de funcionamiento que permita el software de
acuerdo con los requerimientos de la organizacin.
Definir el esquema de seguridad (usuarios, grupos de usuarios / roles y
permisos de acceso de las diferentes opciones del software a los usuarios /
roles).

El proceso de instalacin suele crear un usuario administrador que es el que luego

podr definir todo el esquema de seguridad y tambin un conjunto de roles
predefinidos.

Ficherosmaestros:tercerosyproductos
En las aplicaciones informticas el concepto de fichero maestro se utiliza para
hacer referencia a un conjunto de registros correspondientes a un aspecto
importante dentro de la aplicacin. As, por ejemplo, en una aplicacin de gestin
podramos hablar del fichero maestro de clientes, proveedores, vendedores,
productos, plan de cuentas y pedidos, albaranes o facturas de compra o venta.
Por otra parte, se sigue utilizando la palabra archivo, proveniente de la poca en
que los datos se almacenaban en sistemas gestores de ficheros, aunque hoy en da
los datos se almacenen en SGBD.

Tradicionalmente, en el software de gestin empresarial cuando se habla de

ficheros maestros nos referimos a las entidades cliente, proveedores y productos,
que existen por s mismas y por las que se facilita un formulario de
mantenimiento, que normalmente se denomina ficha del cliente, proveedor o
producto, desde donde gestionar los correspondientes registros. El resto de
entidades, a nivel informtico, como por ejemplo pedidos, albaranes y facturas, no
se suelen incorporar en el paquete de los ficheros maestros, porque sus registros
no existen por s mismos, sino que necesitan la existencia de otras entidades, como
los clientes, los proveedores y los productos.

ltimamente hay una tendencia a englobar clientes y proveedores en una entidad

llamada terceros o interlocutores comerciales. Esto es debido a que un cliente de
la organizacin puede ser a la vez proveedor y, en consecuencia, sus datos
deberan estar duplicadas en ambos ficheros.

El concepto tercer es ms genrico y engloba todos los entes con los que la
empresa puede mantener una relacin: clientes, proveedores, empleados, bancos
y cualquier otro tipo de ente que pueda aparecer. De esta manera, si un empleado
pasa a ser, en un momento dado, el cliente no tendr informacin duplicada en el
sistema.

El mantenimiento de terceros suele ser un programa que contiene una pantalla

principal que recoge los datos principales del tercer (nombre, NIF, domicilio,
telfono, correo electrnico ...) y unas casillas de verificacin para marcarlo como
cliente, proveedor, empleado , banco, etc. Segn la forma que tenga activadas las
diferentes casillas de verificacin, se activan diferentes pantallas para informar de
los datos necesarios, es decir, si el tercero es marcado como cliente, se activa una
pantalla con los datos especficos del tercero cuando acta como cliente (tarifa
asignada, domicilios de envo y de facturacin, descuentos especiales ...) y de
manera similar si el tercero es marcado como proveedor o como empleado, etc.

El archivo de artculos o productos es el otro fichero maestro fundamental en el

software de gestin empresarial. Qu entendemos por producto? Desde el punto
de vista del software de gestin empresarial, dentro del fichero de productos
entra:

Todo lo que la empresa vende (bien o servicio) y que haya sido adquirido o
producido por la empresa.
Todo lo que la empresa adquiere para poder satisfacer las necesidades de
produccin (materias primas).

En ocasiones, algunas organizaciones tambin introducen en el archivo de

productos los conceptos de gasto (electricidad, agua, alquileres ...) ya que utilizan
el circuito de compra del ERP para introducir este tipo de gasto en la aplicacin
contable.

Observamos que hay tipos de productos por los que interesar llevar un inventario
y otros por los que el inventario no tiene sentido (servicios, gastos ...). Por tanto, la
ficha de un artculo o producto suele incorporar una casilla de verificacin
conforme el artculo es o no es inventariable.

Los artculos suelen clasificar, para poder obtener estadsticas de compra, venta y
/ o produccin de forma agrupada. As, es muy normal ver cmo los ERP utilizan
conceptos como: categora de producto, familia de producto, grupo de producto,
etc.

Los artculos tambin suelen tener una casilla de verificacin para ser marcados
como artculo de compra, artculo de venta, artculo de consumo en fabricacin o
artculo de produccin. Segn tenga activadas las diferentes casillas de
verificacin, se activan diferentes pantallas para informar de los datos
correspondientes.

Otra caracterstica muy importante y que no todos los ERP permiten es el poder
gestionar el artculo bajo diferentes tipos de unidades. As, por ejemplo, es posible
que compremos el artculo en litros y el vendamos en kilos o que el tipo de unidad
a utilizar est en funcin del cliente, en el caso de venta, o del proveedor, en el
caso de compra.

Las existencias mnimas y mximas que se desean tener un producto en el

almacn es tambin un dato fundamental. Por un lado, en artculos con mucha
rotacin puede interesar garantizar una existencia mnima, para poder efectuar
un servicio rpido en caso de venta o utilizacin en caso de produccin (materia
de consumo en procesos de fabricacin). Y, por otra parte, puede interesar tener
asignada una existencia mxima a cubrir en el caso de que el stock del artculo
sea inferior a la existencia mnima. Es muy interesante que el ERP tenga
mecanismos de alerta para detectar los productos que, debido a un movimiento
mecanismos de alerta para detectar los productos que, debido a un movimiento
de salida (venta, consumo de fabricacin, regularizacin), pasan a tener un stock
inferior a la existencia mnima indicada, as avisa al responsable para que inicie el
proceso de reposicin que corresponda (comprarlo o fabricarlo), el hecho de que
el artculo tenga asignada una existencia mxima, puede servir para indicar la
cantidad a reponer.

Un buen ERP debera permitir gestionar

existencias de los artculos en varios almacenes e
indicar existencias mnimas y mximas para cada
almacn.

Muchos ERP tambin contemplan, a ttulo informativo a la ficha del producto, las
cantidades pendientes de recepcin (pedidos de compra), las cantidades
pendientes de servir (pedidos de venta), las cantidades pendientes de consumir
(en orden de fabricacin donde el producto intervenga como materia prima) y las
cantidades pendientes de fabricar (cuando se trata de un producto que fabrican).
Estas cantidades, que nunca son modificables por el usuario y que, en caso de
existir, son slo de visualizacin, son redundantes ya que sus valores son
calculables a partir de pedidos de compra, pedidos de venta y rdenes de
fabricacin, pero su clculo es costoso (implicara hacer un recorrido por todos los
pedidos de compraventa y rdenes de fabricacin) y, por ello, es posible que el
ERP las contemple a la ficha de producto y las actualice de forma automtica en
los procesos de gestin los circuitos de compraventa y fabricacin.

Si nuestra organizacin gestiona productos perecederos, es necesario que el ERP

facilite un control de lotes, con fechas de caducidad. Esto implica que para cada
producto perecedero que tenemos en existencia, es necesario saber los lotes
afectados, la fecha de caducidad y el nmero de unidades de cada lote. Asimismo,
hay que mantener la trazabilidad, controlando los proveedores y los clientes
implicados en la compraventa de los productos perecederos.

Un tema similar a la gestin de lotes, pero sin fecha de caducidad ni necesidad de

saber la existencia de cada lote, es la gestin de nmeros de serie, necesaria segn
el tipo de producto que se comercialice. Los ERP deben facilitar tambin esta
gestin.

Cdigosdeproductodelosclientesoproveedores
La relacin comercial que se tiene con los clientes o proveedores suele ser la
compraventa de productos del catlogo, pero seguro que la codificacin y
denominacin de los productos no tiene nada que ver con la codificacin y
denominacin de los mismos productos por el cliente o proveedor. En muchas
ocasiones, aunque no siempre, se hace necesario, en la documentacin que se
intercambia con el cliente o proveedor, incluir la codificacin y denominacin del
producto para el cliente o proveedor.

Esto implica que el ERP debe facilitar la posibilidad de introducir, para los
clientes o proveedores que interese, la codificacin y denominacin de los artculos
que nos compra o vende. Normalmente los ERP facilitan dos programas tal como
muestra la figura 1 .4 .
muestra la figura 1 .4 .

Figura 1.4. Pantallas facilitados por ERP para relacionar

nuestra codificacin de artculos con la codificacin de los
proveedores o clientes

Tablasbsicas
Las tablas bsicas son archivos de pocos registros y con poca volatilidad (se
modifican muy poco) que contienen definiciones codificadas de conceptos a
utilizar en muchos de los programas de la ERP.

Algunos ejemplos de tablas bsicas son pases, provincias, tipo de clientes, tipos de
proveedores, zonas, idiomas, familias de productos, grupos de familias,
almacenes, unidades de medida, formas de pago, tipo de envo, tipo de pedidos,
series de facturacin, formatos de impresin, fabricantes, tipos de materias, etc.

La tabla de grupos de familias de productos

permite tener dos niveles de catalogacin de
productos.

Los contenidos de estas tablas, adems de ser utilizados en los diversos procesos
informticos del ERP (mantenimientos de ficheros maestros, circuitos de
compraventa, procesos de fabricacin ...) pueden ser bsicos a la hora de obtener
resultados en los procesos de inteligencia de negocio, ya que son utilizados para
hacer agrupaciones.

Compras
El apartado de compras comprende los programas necesarios para cubrir el
circuito de compras: tarifas de proveedor, pedidos a proveedor, recepcin de
mercanca y entrada de factura de proveedor.

En referencia a las tarifas de proveedor, en muchas ocasiones los proveedores

comunican sus tarifas y por ello interesa tenerlas introducidas en el sistema
comunican sus tarifas y por ello interesa tenerlas introducidas en el sistema
informtico. Esto supone, en principio, un gran trabajo de introduccin de datos
y ERP pueden facilitar mecanismos para automatizar la introduccin de las
tarifas de proveedor. Asimismo, el mdulo de tarifas de proveedor debera poder
contemplar:

Tarifas y / o descuentos especiales en un intervalo de fechas (ofertas).

Tarifas y / o descuentos especiales en funcin de la cantidad de producto,
definido segn un escalado (a mayor cantidad, menor precio neto o mayor
descuento).

La gestin de pedidos a proveedores es un programa que permitir introducir en

el sistema informtico un pedido a proveedor para, una vez introducida, hacerla
llegar al proveedor. La tecnologa nos permite, hoy en da, una vez el pedido ha
sido registrada, enviarla por correo electrnico o por fax al proveedor, sin
necesidad de llegar a imprimir en papel. El ERP, en el proceso de generacin del
pedido de compra, suele proponer, por defecto, los valores que tenemos pactados
con el proveedor y que residen en su ficha (mantenimiento de terceros - pestaa
de proveedores) y el usuario simplemente los deber validar.

Hay que tener en cuenta que el programa de gestin de pedidos a proveedores

modifica el campo cantidad pendiente de recibir de la ficha de los productos que
intervienen en el pedido, en el caso de que la ficha de producto contemple este
campo (algunos ERP lo contemplan ).

La recepcin de la mercanca es un programa que permitir introducir en el

sistema informtico la mercanca que llega a nuestras instalaciones, lo que queda
registrado en un documento llamado normalmente albarn de compra y que debe
quedar asociado al documento que acompaa a la mercanca (albarn de venta
del proveedor). El programa debe ser suficientemente verstil para permitir:

Recepcionar slo una parte de la mercanca que haba sido pedida en un

pedido de compra (ya que puede que el proveedor no enve todo lo que se
haba pedido) y efectuar el cierre del pedido aunque no haya servido toda la
cantidad pedida o dejar el pedido parcialmente servida.
Recepcionar mercanca que haya sido pedida en diferentes pedidos de
compra (al mismo proveedor, claro) y que el proveedor la sirve en una misma
entrega.
Recepcionar mercanca que no haya sido solicitada en un pedido de compra,
esta situacin no es muy comn y el usuario que efecta la entrada debera
tener un protocolo de actuacin en este caso-alguien debera autorizar.
Localizar cualquier recepcin de mercanca efectuada a partir del
identificador del documento que la acompaaba.

Hay que tener en cuenta que el programa de recepcin de mercanca modifica el

stock de los productos afectados en el almacn donde se est produciendo la
entrada y tambin modifica el campo cantidad pendiente de recibir de la ficha de
los productos recepcionados que provenan de el pedido, en caso de que la ficha
del producto contemple este campo (algunos ERP lo contemplan).

La entrada de facturas de proveedores es un programa que debe permitir, de

forma muy rpida, introducir una factura de proveedor en el sistema informtico.
forma muy rpida, introducir una factura de proveedor en el sistema informtico.
Debe ser suficientemente verstil para permitir:

Introducir una factura de gastos o de inmovilizado sin necesidad de haber

introducido ningn albarn previo.
Introducir una factura de compra correspondiente a uno o varios albaranes
de compra (del mismo proveedor, claro) ya introducidos en el sistema
informtico.
Recibir facturas electrnicas.

Ventas
Este apartado comprende los programas necesarios para cubrir el circuito de
ventas: tarifas a clientes, ofertas a clientes, pedidos de clientes, entrega de
mercanca y facturacin.

En referencia a las tarifas de clientes, el programa debera poder contemplar:

Tarifas y / o descuentos especiales en un intervalo de fechas (ofertas).

Tarifas y / o descuentos especiales en funcin de la cantidad de producto,
definido segn un escalado (a mayor cantidad, menor precio neto o mayor
descuento).

La gestin de ofertas a cliente es un programa que permitir introducir en el

sistema informtico una oferta a cliente para, una vez introducida y registrada,
hacerla llegar al cliente (va correo electrnico o por fax).

La gestin de pedidos de clientes es un programa que permitir introducir en el

sistema informtico un pedido de cliente que puede haber llegado por diversos
canales: telfono, fax, correo electrnico, formulario de una pgina web ... y que
puede responder a una oferta previamente enviada al cliente.

En ocasiones, tanto para las ofertas como para los pedidos, los clientes pueden
solicitar la generacin de la llamada factura proforma.

Factura proforma
Una factura proforma es un documento basado en
una oferta comercial con la indicacin exacta que
tendr la factura final. No tiene ningn valor
contable ni como justificante; se utiliza
principalmente en comercio internacional para
obtener licencias de importacin, por apertura de
crditos documentarios o para envos de muestras
comerciales. Suele incluir la fecha mxima de
validez.

A la hora de introducir el pedido de venta, el ERP suele proponer, por defecto, los
valores que se tienen pactados con el cliente, que se encuentran a su ficha (
mantenimiento de terceros - pestaa de clientes ). El usuario simplemente los
deber validar.

Hay que tener en cuenta que el programa de gestin de pedidos de cliente

Hay que tener en cuenta que el programa de gestin de pedidos de cliente
modifica el campo cantidad pendiente de servir de la ficha de los productos que
intervienen en el pedido, en caso de que la ficha de producto contemple este
campo (algunos ERP lo contemplan) .

Si el pedido del cliente se ha recibido por telfono y no ha quedado constancia

documental en nuestra organizacin es altamente recomendable enviar una copia
(por fax o correo electrnico) al cliente para solicitar le su conformidad escrita .
En cambio, si el pedido del cliente se ha recibido con un documento del cliente, es
necesario registrarse en nuestra pedido el identificador de pedido del cliente para
facilitar su localizacin ante cualquier incidencia.

La entrega de la mercanca es un programa que debe permitir generar las salidas

de material hacia clientes, para dar respuesta a los requerimientos de los pedidos.
Normalmente el sistema, a partir de las fechas de entrega existentes en los
pedidos de cliente y de las existencias en el almacn afectado, propone una
preparacin de pedidos ( picking , en ingls) a servir, generando un informe que
contempla todo lo que se puede servir y tambin lo que no se puede servir. A
partir de ah, algn responsable toma las decisiones que sean necesarias y el
sistema debe permitir, finalmente, generar las salidas decididas. Cada salida debe
ir acompaada del correspondiente albarn de salida, tambin llamado albarn
de venta y, si el puerto lo realiza una agencia de transporte, es muy usual generar
un albarn de agencia (se debe tener presente que el albarn de venta contiene
una relacin detallada de los productos-valorada o no-y la agencia de transporte
no tiene porque ser conocedora, sino que slo necesita saber el nmero de
paquetes, el peso y el volumen).

El programa de entrega de mercanca modifica el stock de los productos

afectados en el almacn donde se est produciendo la salida y tambin modifica el
campo cantidad pendiente de servir de la ficha de los productos entregados que
provenan del pedido, en caso de que la ficha del producto contemple este campo
(algunos ERP lo contemplan).

El proceso de facturacin es un programa que debe permitir, de forma muy

rpida, la generacin de las facturas a cliente, ya sea a partir del pedido o del
albarn de entrega. Hay ERP que obligan, para poder generar una factura, a
disponer de un albarn de entrega de la mercanca. Esto supone un dolor de
cabeza, ya que en ocasiones la factura hay que generar una vez el pedido de
cliente ha sido aceptada, independientemente de si la mercanca ha sido o no
entregada. As pues, el proceso de facturacin debe ser suficientemente verstil
para permitir:

Generar la factura a partir del pedido con la obligatoriedad o no de haber

servido la mercanca (que debe poder ser una caracterstica de la empresa
para todos los clientes o configurable a nivel de cliente o tipo de cliente o
tipologa de pedido, etc).
Generar factura por pedido o poder agrupar varios pedidos en una factura o
generar factura por una parte de un pedido (las partes servidas, por
ejemplo).
Generar las facturas que superen un determinado importe, ya que en
ocasiones no sale a cuenta, por los gastos de cobro asociadas a una factura
(giros bancarios, por ejemplo), generar facturas de importe inferior a una
 (giros bancarios, por ejemplo), generar facturas de importe inferior a una
determinada cantidad y es mejor esperar a que el cliente efecte ms gasto
para agrupar en una sola factura varios pedidos del cliente.
Contemplar varios periodos de facturacin (diario, semanal, quincenal,
mensual ...) ya que hay organizaciones que pactan con cada cliente, los
periodos de facturacin.
Generar facturas electrnicas.

Fabricacin
Un ERP, por definicin, debe permitir la gestin integrada de todas las reas de la
empresa y en caso de que la empresa tenga procesos de fabricacin del ERP debe
contemplar su gestin.

Los procesos de fabricacin son diferentes en los distintos sectores productivos y,

en consecuencia, se hace difcil disponer de un mdulo de fabricacin que se
adapte a todos. Por este motivo, los fabricantes de ERP suelen facilitar soluciones
especficas para cada sector. A modo de ejemplo:

Sector de la moda, ya sea textil o calzado, donde es imperativo poder

gestionar parmetros como temporadas, tallas o colores.
Sector de la alimentacin, donde es imprescindible la trazabilidad y el control
de lotes en todas las fases de produccin.
Sector de fabricacin de maquinaria.
Sector de artes grficas.

No es nuestro objetivo entrar en los procesos de fabricacin especficos de cada

sector. Sin embargo, podemos introducir los conceptos vinculados a un proceso de
fabricacin bsico consistente en la obtencin de un producto a partir de una
serie de componentes, que pueden ser adquiridos a proveedores como materia
prima o bien ser fabricados previamente a la empresa. Los conceptos que hay que
conocer son lista de materiales, hoja de ruta y orden de fabricacin.

Una lista de materiales ( bom en ingls, de bill of materials ),

consiste en una lista de los componentes necesarios para la
obtencin del producto final.

En los componentes podemos incorporar:

Artculos definidos en el fichero maestro de productos, que pueden ser

materias primas que adquirimos a proveedores o productos obtenidos en
procesos de fabricacin internos.
Mano de obra de los operarios.

Los componentes que forman la lista van acompaados de las cantidades

necesarias para la fabricacin de una determinada cantidad de producto final. En
el caso de que los componentes aparezcan en cantidades muy pequeas, las
cantidades se basan en la fabricacin de una cantidad superior a la unidad. La
tabla 1 .1 muestra dos ejemplos de listas de materiales: una basada en 1 unidad de
producto final y la otra basada en 100 unidades de producto final.

Las listas de materiales de la tabla 1 .1 son muy simples; en realidad las listas de
materiales suelen incorporar ms datos, como por ejemplo:

El cdigo de cada componente, que debera ser obligatorio, ya que la

descripcin puede no ser suficiente para identificar el producto.
La posibilidad de indicar, para cada componente, si la cantidad necesaria es
fija o es proporcional a la cantidad de producto final (hay que pensar que en
ocasiones, por una determinada fabricacin, puede ser necesaria una mano
de obra de preparacin o unos materiales de preparacin, la cantidad no
depende de la cantidad de producto a fabricar).

Tabla 1.1. Ejemplos de listas de materiales (bom)

Producto: Ordenador X Quant.: 1u. Producto: Abono CKT Quant.: 100 Kg.
Componente Quant. Componente Quant.
Fuente de alimentacin A 1 u. TPF-II Granular G-900 69 Kg.
Procesador B 1 u. Carbonato sdico denso 30 Kg.
Disipador C 1 u. Detergal G4 Blue 1 Kg.
Placa base D 1 u. Horas operario cat. 3 0,3 h.
Memoria RAM E 2 u.
Disco duro SATA F 1 u.
DVD G 1 u.
Cable SATA 1 u.
Caja H 1 u.
Tornillos Y 20 u.
Mano de obra montador 0,75 h.
Monitor J 1 u.
Teclado K 1 u.
Ratn L 1 u.
Cable alimentacin 2 u.

Un hoja de ruta ( rate routing en ingls) incorpora las

diferentes fases de fabricacin de un producto, con las secciones
o zonas de la fbrica que participan en cada fase y con las
operaciones de produccin a efectuar en cada fase.

Un orden de fabricacin es la concrecin de una fabricacin

de un producto, con la cantidad de producto a fabricar, la fecha
de fabricacin y la lnea de produccin a emplear.

Para gestionar las rdenes de fabricacin suele haber tres procesos:

 Planificacin del orden, momento en que se introduce en el sistema la
cantidad, la fecha y la lnea de produccin previstas. Este proceso debera
comprobar, a partir de las fechas de entrega de los pedidos de compraventa
pendientes de recepcin o entrega y de las fechas de las rdenes de
fabricacin planificadas o en ejecucin, la previsin de existencias de los
componentes de la orden planificada, avisando de las posibles roturas de
stock.
Lanzamiento del orden, momento en el que se reservan las cantidades
necesarias para proceder a la fabricacin de la orden. Si la orden haba sido
planificada, cambia su estado de planificada a lanzada.
Regularizacin de la orden, momento en el que se informa al sistema de la
cantidad final de producto producido (que puede ser distinto del indicado en
la planificacin o lanzamiento) as como las cantidades finales de productos
consumidos (que pueden ser diferentes los previstos en la planificacin o
lanzamiento) y horas de operario empleadas.

Servicios
Hay organizaciones en las que su negocio est basado en los servicios, como por
ejemplo, los servicios de atencin tcnica (SAT), los servicios de consultora, los
servicios de gestora, etc.

En estas situaciones, las empresas necesitan disponer de un mdulo de servicios

que les permita:

Definir el servicio con las diferentes fases, las horas de operario de cada fase
(con la asignacin del operario concreto o simplemente de la categora de
operario que deber llevar a cabo la fase) y, en su caso, los materiales
necesarios.
Efectuar un seguimiento de las horas y materiales empleados en cada fase.
En los servicios de larga duracin, hay que poder controlar el coste del
servicio en cada momento, a fin de detectar posibles desviaciones respecto a
los costes previstos inicialmente.

Contabilidadyfinanzas
La presentacin de las funcionalidades bsicas de los ERP que hacen referencia a
ficheros maestros, mesas de apoyo, compras, ventas, produccin y servicios puede
llevarse a cabo utilizando un lenguaje no muy tcnico.

En Internet se pueden encontrar muchos

materiales introductorios referentes a contabilidad.
En los anexos de la web encontrar el apartado
"Dnde adquirir conocimientos de gestin
empresarial?" Con alguna recomendacin.

El mdulo de contabilidad y finanzas ya no es tan fcil de introducir si no se

tienen conocimientos al respecto y no es el objetivo de este material introducirlo.
Los tcnicos informticos programadores que tengan que adecuar un ERP a las
necesidades de la empresa, desarrollndose mdulos especficos o utilizando
herramientas BI para obtener informacin para los responsables de la empresa,
deben tener unos conocimientos mnimos de contabilidad y finanzas para poder
deben tener unos conocimientos mnimos de contabilidad y finanzas para poder
dar respuesta a las necesidades que surjan en este mbito.

Una vez conocida la teora de las principales

funcionalidades que deberamos encontrar en un
ERP, conviene tener un primer contacto con los
ERP actuales. En los anexos de la web encontrar el
apartado "Actualidad del software de gestin
empresarial" que presenta los principales ERP del
mercado con enlaces a vdeos en los que se muestra
el funcionamiento.

1.3.3.LaleyendadelaimplantacindelosERP
"If it s not broken, don't fijo it" dicen los anglosajones, en una frase que podra
traducirse a si funciona, no lo toques y que en el mbito de la implantacin de
ERP suele sentir muy a menudo .

Las empresas le tienen miedo, por no decir pnico, a un cambio en su software de

gestin empresarial, sea o no ERP, y no les falta razn, ya que se oye hablar
mucho de experiencias negativas.

Las 10 razones que aparecen constantemente como provocadoras de los fracasos

de las implantaciones de ERP son:

1. Los procesos de negocio de la organizacin no han sido bien definidos.

2. La implantacin ha sido ms larga de lo que se haba planificado.
3. Los costes de la implantacin han sido ms altos de los planificados.
4. Las actividades previas a la implantacin fueron deficientes.
5. El personal de la organizacin no est capacitado.
6. La previsin de utilizacin fue demasiado ambiciosa.
7. No ha habido una metodologa clara de implantacin.
8. La recepcin de informacin o requerimientos por parte de los usuarios no
fue completa.
9. No ha habido el apoyo adecuado por parte de los responsables de la
organizacin.
10. No se han gestionado adecuadamente las relaciones interpersonales.
La implantacin de un ERP en una organizacin sobrepasa las responsabilidades
de los tcnicos que efectan la implantacin tcnica del ERP y los programadores
que lo adaptan a las necesidades de la organizacin, pero tcnicos y
programadores se encontrarn en medio de implantaciones y es conveniente que
tengan conocimiento de las buenas prcticas.

El anlisis de los problemas que provocan el fracaso de la implantacin de un

ERP ayuda a definir los puntos a tener en cuenta para conseguir una buena
implantacin. Hay numerosos estudios al respecto y, aunque todos quieren lo
mismo (conseguir una buena implantacin), no todos definen el mismo nmero
de puntos a tener en cuenta.
Como la palabra declogo , aparte de indicar 10 puntos, connota un conjunto de
puntos bsicos para el desarrollo de una actividad, intentaremos recoger en un
declogo dirigido a los dirigentes de la organizacin donde implantar un ERP los
puntos clave a tener en cuenta:

1. Empezar a trabajar con tiempo . En el momento en que se empieza a

intuir que el software actual tiene deficiencias que no se pueden solucionar y
que pueden derivar en problemas graves, es necesario poner manos a la obra
y comenzar la bsqueda de un nuevo software. Esto implica analizar las
operaciones de la organizacin, la informacin que se gestiona y los sistemas
de informacin existentes, con los puntos fuertes y los puntos dbiles,
documentando todo el proceso. Es altamente recomendable que este proceso
se realice por alguien externo a la empresa, ya que la experiencia dice que el
da a da no facilita que este estudio lo desarrolle gente interna.
2. Elegir el ERP adecuado a la organizacin. Para ello, hay que buscar
bien en el mercado y escuchar todas las opciones posibles, tanto las de
software propietario como las de cdigo abierto. La organizacin que quiere
adquirir un ERP es especialista en su negocio y no puede pretender serlo en
ERP y, por lo tanto, debe confiar directamente en los distribuidores o en el
equipo que haya efectuado el estudio del punto anterior. Conviene evaluar,
como mnimo, tres softwares alternativos, exigiendo una demostracin
especfica para nuestro negocio y, para cada software y si es factible, conviene
evaluar dos distribuidores distintos, valorando el equipo humano y el
despliegue de medios que utilizan en la implantacin. Es interesante
considerar la posibilidad de mantener los servicios del equipo externo que
haya desarrollado el punto anterior en todo el proceso para que sirva de
interlocutor entre la organizacin y los distribuidores.
3. Exprimir al mximo la fase de trato comercial . En esta fase, la
empresa candidata a implantar el ERP tiene total disponibilidad. Una vez
firmado el contrato, a pesar de que el trato siga siendo correcto, se ajustan a
lo firmado y, en consecuencia, es necesario haber dedicado mucho tiempo a
comprobar que las funcionalidades del programa se ajusten a nuestros
requerimientos. En caso de detectar funciones esenciales no soportadas es
altamente recomendable buscar otro software que se adecue mejor. Hay que
tener en cuenta que las adaptaciones en un ERP son muy costosas y no
siempre factibles y, por tanto, es fundamental la eleccin del ERP adecuado.
4. Repasar muy bien el contrato, en especial el alcance del trabajo .
La empresa implantadora suele ser implacable a la hora de facturar cualquier
cosa no prevista en el contrato y siempre tienen la sartn por el mango, ya
que son los nicos que saben la verdad de lo que hay delante. Por eso hay que
volver a comentar que es muy interesante mantener los servicios del equipo
externo que ha participado en el punto 1 como interlocutor entre la
organizacin y la empresa implantadora. El trabajo a desarrollar debe
incorporar, con mucho detalle, los procesos de formacin de personal, punto
muy importante para conseguir el xito de la implantacin.
5. Antes de firmar, hay que asegurarse de que la solucin adquirida
cubre el 100% de los requerimientos . De hecho, esto es consecuencia
de lo comentado en el punto 3, pero en ocasiones hay funcionalidades
cubiertas por mdulos que se comercializan a ambos, claro, nadie nos ha
engaado porque el ERP lo cubre a travs de un mdulo adicional, el
problema aparece si no forma parte del software adquirido. En especial, hay
que tener muy en cuenta el apartado relativo a la inteligencia de negocio (BI)
 que tener muy en cuenta el apartado relativo a la inteligencia de negocio (BI)
para poder acceder a la informacin y generar informes y cuadros de mando.
6. Diseo adecuado del hardware necesario . La plataforma de
hardware sobre la que debe basarse el funcionamiento informtico de la
empresa es suficientemente importante como para dedicarle un estudio
especfico y valorar todas las soluciones. Los departamentos de sistemas de las
empresas a veces pueden ser recelosos al cambio y sentirse incmodos con
nuevas plataformas que no dominan. Esto no debera ser un problema si el
cambio de plataforma debe suponer un ahorro importante y fiabilidad y
rendimiento iguales o mejores.
7. Solvencia del proceso de implementacin: equipo y metodologa .
Hay que conocer la solvencia del equipo que llevar a cabo la implantacin:
quin formar el equipo y cuntas implantaciones del software han efectuado
en empresas del mismo sector o con funcionalidades similares. Asimismo es
fundamental conocer la planificacin y metodologa que se seguir y asumirla
para conseguir el xito en el menor tiempo posible.
8. Mnimas modificaciones al programa . Ya hemos indicado antes que
deben ser las mnimas indispensables y, en ocasiones, es preferible, si es
posible, cambiar la operativa de la empresa para adecuarla al funcionamiento
del nuevo software, antes de que empearse en unas modificaciones que
pueden provocar problemas de rendimiento y, incluso, problemas con las
actualizaciones del software.
9. Mxima atencin a los usua-a-rios . Una implantacin de ERP puede
suponer un choque por los usuarios, que debern cambiar de pantallas y, en
muchos casos, la forma de hacer las cosas. Por tanto, hay que conseguir la
mxima colaboracin de los usuarios, habindoles hecho participar en los
procesos de preimplantacin (anlisis de las operaciones que se efectan e
informacin que se gestiona y anlisis de los productos candidatos). Una vez
iniciada la implantacin, deben recibir la formacin y acompaamiento
adecuados.
10. Dedicacin directiva a la implantacin ta-cin . Durante el proceso de
implantacin, la empresa debe destinar al proyecto recursos de primer nivel
en trminos de tiempo de la alta direccin. Es esencial un gerente de proyecto
de primera lnea directiva, con capacidad analtica, visin de negocio,
resolutivo y con interlocucin en todas las reas funcionales de la empresa. Es
imprescindible la disponibilidad de la direccin general para la adopcin de
decisiones que le deben llegar masticadas y, en consecuencia, es muy
conveniente el apoyo de recursos externos independientes que aporten
experiencia y apoyo (los que habamos comentado en el punto 1 del declogo
y que deberan acompaarnos en todo el proceso).
Este declogo est dirigido a los dirigentes de la organizacin en la que se ha de
implantar el ERP. El tcnico informtico que est leyendo estos materiales no
acostumbrar a ser dirigente de la organizacin, pero conviene que sea conocedor
ya que:

Puede formar parte del departamento TIC de la organizacin donde

implantar el ERP.
Puede formar parte de un equipo de implantacin del ERP.
En pequeas empresas, puede haberse convertido en el jefe del departamento
TIC y puede tener que erigirse en el responsable interno de la implantacin.

Ntese que los puntos del declogo se pueden agrupar en tres fases:
Ntese que los puntos del declogo se pueden agrupar en tres fases:

1. Anlisis
2. Planteamiento y diseo
3. Implantacin
Una vez que tenemos el ERP implantado y en funcionamiento con total xito
hay que pasar a una cuarta fase:
4. Postimplantacin
Las necesidades de las empresas evolucionan constantemente y los ERP tambin
lo hacen. En consecuencia, a la organizacin que ha implantado un ERP le
conviene ir actualizndolo a partir de las actualizaciones que facilita el fabricante.
Esto normalmente se articula a partir de contratos de soporte o mantenimiento
postimplantacin con la empresa que ha efectuado la implantacin.

El contrato de soporte o mantenimiento, de pago peridico, puede incorporar:

Conjunto de horas de apoyo a precio cero o reducido.

Por las horas que sobrepasen el conjunto anterior, descuento sobre el precio
de venta.
Acceso a los parches y actualizaciones del ERP facilitados por el fabricante.
Procesos de instalacin de parches y actualizaciones a precios especiales.

1.3.4.LosERPalasPYME
Hasta hace unos aos, los grandes fabricantes de ERP dirigan sus productos a
grandes empresas y el mercado de las PYME quedaba para fabricantes de
aplicaciones de gestin (muchas veces suite ) que cubran las necesidades de la
empresa sin que su producto pudiera ser catalogado como un ERP. De hecho al
hablar de un ERP se tiende a pensar en un sistema desarrollado para la gran
empresa y con un coste excesivo para la PYME, tanto en lo econmico del
producto como en el de implantacin.

Esta situacin se ha visto alterada en los ltimos aos, en el que los grandes
fabricantes de ERP han dirigido su mirada hacia las PYME y los ofrecen versiones
de sus productos.

Consulte el apartado "ERP a las PYME" de los

anexos de la web.

1.4.SistemasCRMysolucionesBI,complementosdelos
ERP?

Recordemos las definiciones de sistemas ERP, sistemas CRM y soluciones BI.

Los sistemas ERP, como software de gestin integrada, integran todos los
datos y procesos de una organizacin en un sistema unificado.
Los sistemas CRM apoyan la gestin de las relaciones con los clientes, a la
venta y al marketing.
 venta y al marketing.
Las soluciones BI son herramientas destinadas a facilitar datos a los
dirigentes empresariales, obtenidas a partir de los datos de los sistemas ERP-
CRM, con el objetivo de facilitar la toma de decisiones.

Segn la definicin de ERP, estos sistemas integran todos los datos y procesos de
la organizacin y, en consecuencia, deben incorporar la gestin de las relaciones
con los clientes (CRM) y podran incorporar herramientas de inteligencia de
negocio . Por lo tanto, una organizacin con ERP no debera plantearse la
implantacin de CRM y de soluciones BI.

La mayora de ERP actuales incorporan un mdulo de CRM que en algunos casos

forma parte de la base del ERP y en otras es un mdulo optativo. Entonces, por
qu existen sistemas CRM que se comercializan independientemente de los ERP?
Quien los adquiere? Encontramos la respuesta en el hecho de que:

Hay sistemas CRM que quizs facilitan ms funcionalidades que el mdulo

CRM incorporado por el ERP y la organizacin precisa de estas
funcionalidades.
Hay empresas que en lugar de tener ERP disponen de varios programas de
gestin empresarial y les conviene poder adquirir un CRM.

La implantacin de un CRM independiente del software de gestin conlleva tener

datos duplicados en los dos sistemas (clientes, ofertas, pedidos, ventas, producto
...) y, para minimizar la duplicidad de la entrada de datos y las incoherencias, se
establecen conexiones con la base de datos del ERP o software de gestin para
alimentar la base de datos del sistema CRM.

En cuanto a las soluciones BI, los ERP actuales tambin incorporan herramientas
que permiten obtener informes para analizar y que suelen formar parte de la base
del ERP. Pero para segn qu tipo de informe o anlisis a efectuar es posible que
el mdulo BI integrado en el ERP todava no facilite la adecuada funcionalidad,
aunque muy probablemente los ERP irn evolucionando en la lnea de la solucin
total. As pues, actualmente es bastante usual adquirir una solucin BI para
obtener resultados complementarios a la informacin que facilita el ERP.

Hay soluciones BI que trabajan directamente con la base de datos del software de
gestin comercial, pero en muchas ocasiones se utiliza un almacn de datos (data
warehouse) donde previamente se ha volcado los datos a analizar, en un formato
inteligente para facilitar los anlisis previstos. As, por ejemplo, para analizar las
ventas efectuadas por tipo de producto y tipo de clientes en los diferentes meses
comparando los ltimos tres aos, obtendr unos resultados ms rpidos si se
dispone de los importes de venta agrupados por tipo de producto, tipo de cliente y
meses y aos, en lugar de tener que efectuar estas agrupaciones cada vez que se
quiere ejecutar el anlisis comparativo. Ciertamente, el hecho de trabajar con
almacenes de datos implica redundancia de datos ya que su contenido es
calculable a partir de los datos existentes en la base de datos del software de
gestin comercial, pero el ahorro de proceso de datos es tan grande, que est
ampliamente justificado.

Por todo ello se puede responder afirmativamente a la pregunta que encabeza este
apartado: los sistemas CRM y las soluciones BI son compaeros de viaje de los
apartado: los sistemas CRM y las soluciones BI son compaeros de viaje de los
ERP.

1.4.1.FuncionalidadesdelossistemasCRM
El acrnimo CRM utiliza indistintamente, para dos conceptos:

1. CRM como estrategia de negocio de la organizacin focalizada en el cliente,

consistente en centrar los esfuerzos en el conocimiento de los clientes,
detectando sus necesidades con el objetivo de aumentar su grado de
satisfaccin, de incrementar la fidelidad al organizacin y de incrementar la
rentabilidad o beneficios del cliente a la organizacin.
2. CRM como sistema informtico ideado para que la organizacin pueda
administrar todos los aspectos vinculados con la gestin de sus clientes, de
modo que un sistema CRM puede incluir todo, desde tecnologa para recoger
datos de las llamadas telefnicas del rea de ventas hasta sitios web donde los
clientes tengan acceso a nuestros productos (y quede constancia de las visitas
y del que han hecho), incorporando toda la informacin proveniente del
circuito de venta del software de gestin empresarial.
Nuestro objetivo es conocer el CRM como aplicacin informtica, que debe
permitir alcanzar la estrategia CRM adoptada por la organizacin. Normalmente,
en un sistema CRM se encuentran los siguientes mdulos:

1. Mdulo de clientes : permite introducir los clientes de la organizacin. Si

el CRM forma parte del ERP el mdulo de clientes coincide con el mdulo del
ERP y, como mucho, incorpora ms campos propios de la gestin del CRM,
pero no se produce ninguna duplicidad de datos. En caso de un sistema
CRM independiente, la situacin ms usual es que la organizacin ya
disponga de un software de gestin empresarial (sea o no ERP) desde donde
se efectan las ventas a clientes y, en consecuencia, este mdulo supone una
duplicidad de datos, necesaria para poder ejecutar las funcionalidades que
aporta el CRM. En estas situaciones, para minimizar la posibilidad de errores
y mantener al da los archivos de clientes de ambos programas (gestin
comercial y CRM), acuerda gestionar los clientes siempre a travs de uno de
los dos programas y se implementa un traspaso de informacin hacia la base
de datos del otro software, que se debera ejecutar en tiempo real y, en el peor
de los casos, automatizar su ejecucin a intervalos regulares.
2. Mdulo de clientes potenciales : permite introducir las personas u
organizaciones que representan alguna oportunidad de ser futuros clientes.
3. Mdulo de contactos : permite gestionar las personas u organizaciones
asociadas a un cliente (real o potencial) con las que la organizacin se
comunica con la intencin de generar una oportunidad de negocio con el
cliente.
4. Mdulo de productos : permite gestionar los artculos susceptibles de ser
vendidos. De la misma manera que con el mdulo de clientes, en el caso de
un sistema CRM independiente se produce una duplicidad con los productos
de la aplicacin de gestin empresarial de la empresa.
5. Mdulo de apoyo : debe permitir recoger todos los contactos entre la
organizacin y los clientes (reales o potenciales), sea cual sea el canal por el
que se establezcan (telefnico, correo electrnico, fax, visita comercial, stand
de una feria , visita identificada en el sitio web ...), registrando los detalles del
contacto y las posibles acciones pendientes de ejecutar a raz del contacto,
con la fecha, el responsable y el contenido.
 con la fecha, el responsable y el contenido.
6. Mdulo de informes y grficos : para ayudar a la organizacin a obtener
informes personalizados, para ayudar a tomar decisiones oportunas de
negocio. Este mdulo no deja de ser una solucin BI para el CRM.
Los CRM independientes aportan, tambin, los mdulos que facilitan las acciones
propias del software de gestin comercial y que son necesarias de controlar para
poder tener toda la informacin en torno a los clientes. Por ello, la lista de
mdulos anteriores se puede ver ampliada con:

1. Mdulo de ofrecidas .
2. Mdulo de gestin de pedidos de venta .
3. Mdulo de gestin de rdenes de libre ra-mente .
4. Mdulo de fac-ti-ra-cin .
En caso de tener implantado un sistema de gestin empresarial, de la misma
manera que con los clientes y los artculos, hay que alimentar la base de datos del
CRM con la informacin bsica de ofertas, pedidos, envos y facturas realizadas a
travs del sistema de gestin empresarial, para disponer en el CRM de toda la
informacin y poder obtener informes adecuados.

As pues, para no vernos obligados a tener duplicidad de datos en el ERP y el

CRM, se impone que los ERP incorporen el mdulo de CRM.

En los anexos de la web encontrar el apartado

"Toma de contacto con sistemas CRM" que nos da a
conocer algunos de los productos CRM ms
utilizados y hay presentaciones que nos muestran
las principales funcionalidades de un CRM.

1.4.2.FuncionalidadesdelassolucionesBI
Los sistemas ERP, CRM, HRM ( Human Resource Management ) son algunos de
los innumerables tipos de aplicaciones implantadas en las empresas, que se
encuentran, en muchas ocasiones, en plataformas diferentes. A todas estas se
suman los documentos impresos, archivos de diversas herramientas ofimticas,
etc. lo que convierte la organizacin en un mar de informacin en el cual es difcil
de encontrar aquella que es determinante a la hora de tomar decisiones para el
negocio. A veces, peor que no tener informacin es tener mucha.

La inteligencia de negocio (BI) se adentra en la informacin de la

organizacin con el objetivo de generar escenarios, pronsticos e
informes que son suministrados a los responsables de la toma de
decisiones.

Una aproximacin de las reas ms comunes donde se aplican las tcnicas de la

inteligencia de negocio son:
 Ventas: anlisis de ventas, deteccin de clientes importantes, anlisis de
productos y tipos de productos, anlisis de mercados, pronsticos y
proyecciones.
Marketing : segmentacin y anlisis de clientes, seguimiento de los nuevos
productos.
Finanzas : anlisis de gastos, rotacin de cartera, razones financieras.
Fabricacin : productividad de las lneas de fabricacin, anlisis de
residuos, anlisis de calidad, rotacin de stock, partes crticas.

Por otra parte, en las organizaciones suele existir una jerarqua que determina el
tipo de acciones que se realizan dentro de ella y, en consecuencia, el tipo de
decisiones que se deben tomar. Tradicionalmente se han establecido tres niveles
jerrquicos:

1. Estratgico , en el que la directiva decide el camino que debe seguir la

organizacin.
2. Tctico , en el que la gerencia organiza y planifica las diversas reas de la
empresa conjuntamente con los correspondientes jefes (marketing, ventas,
finanzas, fabricacin).
3. Operativo , en el quals'executen las operaciones cotidianas de la
organizacin (diarias y rutinarias): operaciones de los circuitos de
compraventa y fabricacin y operaciones contables y financieras.
Estos modelo tradicional de tres niveles se ha visto ampliado ltimamente por la
llegada de las TIC, con un cuarto nivel que se ubica entre el tctico y el operativo,
llamado el nivel del conocimiento , en el que ubicamos todos los profesionales
que aaden valor a la empresa por medio de sus habilidades en las TIC.

Los diferentes niveles, que tambin podramos llamar roles, tienen diferentes
necesidades de acceso a los datos (el director general no tiene porque conocer
cmo se introduce en el sistema una oferta a cliente y en cambio s puede
necesitar conocer si se est alcanzando los objetivos de ventas para el ejercicio
actual, mientras que la situacin es totalmente inversa para un auxiliar
administrativo del departamento comercial). Los actores de todos los niveles
necesitan informes, pero la complejidad de elaboracin es muy diferente (el
auxiliar del departamento comercial puede necesitar un simple listado de las
ofertas diarias, mientras que el director general necesita grficas que pueda
visualizar desde diferentes dimensiones) . Por tanto, se necesitan herramientas
informticas para elaborar informes adecuados para todos los niveles y la
complejidad de las herramientas es muy diferente segn el nivel al que deben
servir.

Figura 1.5. Correspondencia entre los niveles de la

empresa y los tipos de sistemas de gestin de la
informacin
La figura 1 .5 muestra la correspondencia entre los niveles jerrquicos de
organizacin de una empresa y los tipos de sistemas de gestin de la informacin
normalmente empleados, teniendo en cuenta las necesidades de informacin de
cada nivel. El contenido de la figura 1 .5 no debe tomarse al pie de la letra, es
decir, los actores de los niveles estratgico y tctico pueden utilizar informes
facilitados por los sistemas OLTP y los actores del nivel del conocimiento pueden
tambin utilizar algn informe proporcionado para las herramientas BI externas
a los sistemas OLTP.

La figura 1 .5 incorpora conceptos (OLTP, data mining, data warehouse ) que

debemos reconocer junto con otros que estn vinculados al mundo BI: ETL,
OLAP, KPI, data mart, dashboard y cubos multidimensionales.

Una herramienta BI debe ser capaz de reunir informacin dispersa por toda la
compaa y, incluso, de distintas fuentes, a fin de proporcionar a los
departamentos la accesibilidad, poder y flexibilidad necesarios para analizar la
informacin. La figura 1 .6 muestra todos los componentes que pueden intervenir
en una solucin BI. La parte izquierda de la figura muestra los diversos orgenes
de datos de donde puede provenir la informacin que la solucin BI reunir en el
repositorio de la solucin.

Figura 1.6. Componentes de una solucin BI completa

OLTP es el acrnimo ingls de Proceso de Transacciones En Lnea (

OnLine Transaction Processing ) para hacer referencia a los sistemas que
facilitan y administran aplicaciones transaccionales, como es el caso de los ERP-
CRM en los que continuamente se efectan transacciones.

El repositorio de la solucin BI es el lugar centralizado donde la solucin BI

almacena los datos recogidos de los diversos orgenes de datos, principalmente de
sistemas OLTP. En el repositorio de una solucin BI podemos distinguir dos tipos
sistemas OLTP. En el repositorio de una solucin BI podemos distinguir dos tipos
de componentes: data warehouse (siempre presente) y cubos multidimensionales
(presentes si la solucin BI facilita el anlisis OLAP).

Un data warehouse (almacn de datos) es una base de datos destinada a

contener una coleccin de datos orientada a un determinado mbito (empresa,
organizacin, materia ...), integrada, no voltil y variable en el tiempo, que debe
servir de base para la aplicacin de herramientas analticas con el objetivo de
obtener informacin til para la toma de decisiones. Es decir:

Orientada a un mbito: los datos contenidos estn organizadas de

manera que todos los elementos relativos a un mismo evento del mundo real
quedan relacionados.
Integrada: contiene los datos de todos los orgenes de datos posibles, de
forma consistente.
No voltil: la informacin introducida no se modifica ni elimina, es
informacin de slo lectura que se mantiene para futuras consultas.
Variable en el tiempo: los cambios producidos en los datos a lo largo del
tiempo quedan registrados para que los informes puedan reflejar las
variaciones.

Uno de los principal problemas a la hora de implementar un data warehouse ,

radica en que los datos a integrar, al provenir de orgenes diversos, presentan
inconsistencias en formato y codificacin y esto implica la necesidad de disear
un proceso de filtrado, reestructuracin de los datos y eliminacin de
inconsistencias antes de ser almacenadas en el data warehouse. Este proceso es
conocido como ETL , acrnimo de Extract, Transform and Load .

La tabla 1 .2 muestra las principales diferencias entre las bases de datos de los
sistemas OLTP, dedicadas a las operaciones del da a da, y un data warehouse ,
dedicado a concentrar informacin completamente orientada al anlisis.

Tabla 1.2. Comparacin entre las BD de los sistemas OLTP y data

warehouse
BD de sistemas OLTP Data warehouse
Datos operacionales Datos del negocio relevantes para informacin
Orientada a las aplicaciones Orientado al analista
Datos actuales Datos actuales + datos histricos
Datos al detalle Datos resumidos con cierto detalle
Cambia constantemente Estable

El data warehouse puede estar organizado en data marts . Un data mart

(escaparate de datos) es un subconjunto de datos del data warehouse ,
correspondiente a una unidad de negocio (rea) de la organizacin. Tiene el
objetivo de solucionar la problemtica de anlisis de la correspondiente rea.

Un data warehouse se puede considerar como la coleccin de data marts

implementados en las diferentes reas de negocio de la organizacin.

Las soluciones BI aportan herramientas analticas y la potencia de una solucin

Las soluciones BI aportan herramientas analticas y la potencia de una solucin
BI se mide a partir del nmero de herramientas analticas que facilita y de la
potencia de cada una de ellas.

Hoy en da las herramientas analticas se tipifican en: query & reporting, data
mining, KPI y anlisis OLAP .

Las herramientas query & reporting (consultas e informes) son las

tradicionales herramientas que permiten disear y ejecutar consultas sobre una
base de datos y formatear el resultado en informes. La figura 1 .6 muestra que
estas herramientas se aplican sobre las bases de datos de los sistemas OLTP y
sobre el data warehouse y data marts .

La mayora de sistemas OLTP (ERP, CRP ...) facilitan herramientas query &
reporting de fcil aprendizaje que un usuario aventajado puede utilizar para
disear los informes que necesita y que no estn predefinidos en el sistema.

Query & reporting ofimtico

Las bases de datos ofimticas utilizan en muchas
ocasiones como herramientas query & reporting de
los sistemas OLTP y data warehouse, a travs de la
conexin ODBC con las BD del sistema OLTP o
data warehouse.

Las herramientas data mining (minera de datos) son herramientas de alto nivel
que sobrepasan el objetivo de este material. A ttulo informativo hay que saber que
la minera de datos consiste en la extraccin no trivial de informacin que reside
de manera implcita en los datos, que era previamente desconocida y que puede
resultar til para algn proceso. En otras palabras, la minera de datos prepara,
sondea y explora los datos para obtener informacin oculta en ellas.

OLAP es el acrnimo ingls de Proceso Analtico en Lnea ( OnLine

Analytical Processing ) para hacer referencia a los sistemas que almacenan
grandes cantidades de datos resumidos obtenidos a partir de sistemas OLTP, con
el objetivo de efectuar consultas.

El concepto OLAP va muy ligado al concepto data warehouse y en ocasiones se

confunden. La diferencia radica en que data warehouse es un trmino que se
utiliza para hacer referencia a los datos y OLAP es un concepto que se utiliza para
hacer referencia a las herramientas disponibles para evaluar y analizar los datos
de los data warehouse .

Al hablar de anlisis OLAP aparecen los cubos multidimensionales o cubos OLAP

o hipercubo. Un cubo multidimensional es una representacin matricial (N
dimensiones) de los datos planas representadas va filas y columnas en una tabla
relacional, utilizado en el anlisis OLAP.

Ejemplo simplificado de construccin de data

warehouse y hipercubo
 La base de datos de un ERP (suponemos BD relacional) seguramente tiene una
tabla donde se registran las ventas que se efectan. Supongamos el siguiente
diseo:

VENTA (# Cliente, # Producto, # Fecha, Cantidad, PreuUnitari)

ON {Cliente} REFERENCIA CLIENTE
Y {Producto} REFERENCIA PRODUCTO

Los diseadores del data warehouse han decidido que a nivel de anlisis no
interesa mantener el cliente, ni el producto ni la fecha pero s se necesita
incorporar el tipo de cliente, la familia de producto y el mes y ao en que se ha
efectuado las ventas. Por tanto, en el data warehouse se ha diseado la siguiente
tabla, que agrupa las cantidades y la media de los precios de venta:

VENDA_DW (# TipCli, # FAMPRO, # MesAny, SumQuantitat,

AVGPreu)

El proceso ETL que rellena la tabla VENDA_DWse preocupa de buscar todas las
ventas del perodo que corresponda, agrupndolas por tipo de cliente, familia de
producto y mes o ao, sumando las cantidades de producto vendidas y
calculando la media de los precios aplicados .

Con este diseo, dentro del data warehouse se ha perdido la informacin de

detalle de cliente, producto y fecha de venta. Es decir, se ha disminuido la
granularidad y, en consecuencia, el anlisis basado en el data warehouse podr
dar resultados a nivel de tipo de producto, tipo de clientes e intervalos mensuales,
pero no a nivel de cliente, de producto y de fecha de venta. Si en el data
warehouse se hubiera decidido almacenar los datos en una estructura similar a la
de la mesa VENTAde nuestro ERP, la herramienta de anlisis tendra mayores
posibilidades analticas, ya que podra analizar los datos a nivel de detalle y
tambin los niveles del resumen que facilita VENDA_DWpero para ello es necesario
ms espacio en el data warehouse .

En terminologa de BI, la mesa VENTAes una tabla de hechos (registra los hechos
que se han producido) y la tabla VENDA_DWes una tabla agregada de hechos. Los
anlisis a nivel resumen ejecutarn ms rpidamente si disponemos en el data
warehouse de tablas agregadas de hechos adecuadas al resumen que hay que
analizar. No es nada sencillo decidir qu datos se almacenan en el data
warehouse y con qu nivel de granularidad.

Los datos de la tabla VENDA_DWnos permiten construir varios cubos

muldimensionals, en los que los atributos para analizar se representan en los
diversos ejes (dimensiones) del cubo.

As, si queremos analizar la cantidad de ventas por tipo de producto, tipo de

cliente y meses, podemos construir el cubo tridimensional de la figura 1 .7 .
Observamos que en el punto vaparecer el valor correspondiente a la cantidad de
venta del tipo de producto tpefectuada por clientes del tipo tcen el mes m.

Figura 1.7. Ejemplo de cubo OLAP tridimensional

Es muy comn que la informacin del data warehouse se estructure en cubos
multimensionals, ya que estos preparan la informacin para responder a
consultas dinmicas con un buen rendimiento (tiempo de respuesta). Los cubos
multidimensionales no son, sin embargo, las nicas estructuras de datos que
utilizan los data warehouse.

Para facilitar el diseo de consultas OLAP, debido a que el lenguaje SQL obligaba
a escribir consultas complejas, se cre el lenguaje MDX ( Multidimensional
Expressions ) que est pensado especficamente para efectuar consultas sobre
cubos OLAP y, por tanto, las consultas son mucho ms simples que las
correspondientes en el lenguaje SQL . El lenguaje MDX ha sido acogido por la
mayora de proveedores de herramientas OLAP.

Para finalizar con la percepcin de los conceptos ms utilizados alrededor de las

soluciones BI, aparecidos todos ellos en la figura 1 .6 , nos falta presentar los
dashboards y los KPI.

KPI es el acrnimo ingls de Indicadores Claves de Desempeo ( Key

Performance Indicators ) para hacer referencia a mtricas utilizadas para
cuantificar los objetivos que reflejan el rendimiento de una organizacin y que
generalmente se recogen en su plan estratgico.

En los anexos de la web encontrar el apartado

"Toma de contacto con soluciones BI" que nos da a
conocer algunos de los productos BI ms utilizados
y nos facilita presentaciones que nos muestran las
principales funcionalidades de una solucin BI.

Los responsables de la organizacin tienen por dogma que "no se puede mejorar
lo que no se puede medir". En consecuencia, la organizacin define el conjunto de
KPI importantes para su evolucin y para hacer un correcto seguimiento se hace
necesario disponer de cuadros de mando o dashboards .

Un dashboard es un tipo de interfaz interactiva de usuario, diseada para

proporcionar al usuario informacin especfica relativa al estado de la empresa,
representada normalmente a travs de indicadores clave de desempeo (KPI) y
enlaces a informes relevantes. Existen seales visuales, grficos y controles de
proceso que centran la atencin del usuario en las tendencias, cambios y
excepciones importantes.

Debemos imaginar un dashboard como un gran tablero de la organizacin,

donde hay indicadores (como el tablero de un vehculo) que muestran la realidad
de las diferentes reas de negocio. Imaginemos que cuando un valor de un
indicador baja por debajo de un lmite normal, se enciende una luz de alerta que
indica que hay que poner atencin y, si se excede de un valor tolerable, no slo se
enciende la luz sino que adems lo indica mediante una seal auditiva.
 S I S T E M AS DE GE S T I N E M P RE S ARI AL

2.ImplantacintcnicadesistemasERPCRM:
OpenERP

Cuando se habla de sistemas ERP-CRM la palabra implantacin suele utilizar

para hacer referencia al proceso global que tiene como objetivo final la puesta en
marcha de un nuevo sistema ERP-CRM a la organizacin. Este proceso tiene
varias fases: anlisis de requerimientos, estudio de posibles soluciones, decisin
para un producto, instalacin y configuracin, migracin de datos-en su caso-,
formacin de los usuarios y ejecucin de adaptaciones-en su caso- . Una
implantacin entendida as es un proceso muy complejo que debe estar dirigido
por profesionales especialistas (consultores).

Por implantacin tcnica de sistemas ERP-CRM entendemos el subproceso con

las siguientes operaciones imprescindibles:

1. Instalacin del software, en un determinado hardware y sistema operativo,

siguiendo las prescripciones del fabricante.
2. Instalacin de mdulos adicionales que correspondan, segn requerimientos.
3. Configuracin del software, segn las posibilidades de que se faciliten, para
adecuarlo a los requerimientos de la organizacin.
4. Verificacin del correcto funcionamiento, segn requerimientos.
5. Documentacin de las operaciones realizadas e incidencias aparecidas, con
su resolucin.
La lista de operaciones anteriores se puede ver ampliada con dos operaciones:

1. Migracin de datos del software de gestin empresarial existente hacia el

nuevo software, si as est contemplado en el proyecto de implantacin del
nuevo software.
2. En caso de que el software que instalamos incorpore un mecanismo de
salvaguarda de los datos, puesta en marcha y verificacin de la correcta
recuperacin de los datos en el caso de haber ocurrido un desastre.
Para ejecutar estas operaciones puede ser necesaria la ayuda de dos perfiles
profesionales diferentes al nuestro y que en muchas ocasiones recaen en un
mismo profesional:

1. El administrador del sistema, en caso de que sea necesario efectuar algunos

ajustes a nivel de sistema operativo.
2. El administrador del sistema gestor de base de datos, en el caso de que
nuestro software tenga que conectar con un SGBD corporativo, ya instalado o
que haya que instalar.
Todo proceso de implantacin tcnica de un ERP-CRM consta de las operaciones
anteriores. En las diversas combinaciones posibles de sistema ERP-CRM con
sistema operativo y con sistema gestor de bases de datos, intervienen tantas
sistema operativo y con sistema gestor de bases de datos, intervienen tantas
variables que cada combinacin necesitara su propio aprendizaje. Es decir, a
diferencia del proceso de aprender a conducir, que nos sirve casi para cualquier
coche, la implantacin tcnica de un sistema ERP-CRM no es estndar y, por
tanto, un implantador necesita el aprendizaje concreto para cada combinacin
posible. Por otra parte, la experiencia acumulada de un implantador en diversas
situaciones ayuda que cada nueva situacin necesite de un aprendizaje ms corto.

LogotipodeOpenERP

Ya que no podemos pretender adentrarnos en la implantacin tcnica de

cualquier sistema ERP-CRM en cualquiera de las plataformas soportadas
(sistema operativo + SGBD), nos centraremos en un producto y en la
implantacin pondremos en prctica todas las operaciones. El producto elegido
ha sido el sistema ERP-CRM de cdigo abierto OpenERP.

El OpenERP es un sistema ERP-CRM de cdigo abierto con licencia AGPL,

conocido previamente como TinyERP.

Licencia AGPL
La licencia AGPL es una licencia copyleft derivada
de la GPL de GNU que incorpora una clusula que
aade la obligacin de distribuir el cdigo fuente
del software cuando ste se utilice para dar
servicios sobre una red (por ejemplo, en
aplicaciones web).

Las caractersticas bsicas que deberamos tener en cuenta a la hora de evaluar un

sistema ERP-CRM y los valores para el sistema OpenERP son:

Licencia:

AGPLv3 (versin 6) o AGPL + Private User.

GPLv3 (versin 5).

Desarrollos posibles:

On-premise bajo los SO: Linux y Windows (dos versiones: Community-

gratuita-y Enterprise ) .
SaaS.

Arquitectura. Cliente-servidor con tres capas claramente diferenciadas:

La base de datos en el SGBD PostgreSQL, que slo contiene datos y no

contiene ninguna lgica de negocio (es decir, no incorpora funciones,
procedimientos o disparadores).
El servidor OpenERP que contiene toda la lgica de negocio con un
ncleo base y una estructura que permite ir aadiendo mdulos segn
las necesidades de la organizacin. OpenERP facilita una larga lista de
mdulos que se puede ampliar con el diseo de mdulos propios para
 mdulos que se puede ampliar con el diseo de mdulos propios para
dar cobertura a las necesidades de la organizacin.
La capa de los clientes, con varias posibilidades: cliente web, accesible
desde cualquier navegador, cliente GTK, para instalar en cada mquina
que quiera utilizarlo y clientes para desarrollar que se conecten con los
protocolos XML - RPC o Net- RPC .

Sistema operativo:

Servidor sobre Windows o Linux.

Cliente GTK sobre Windows, Linux o Mac.

SGBD: PostgreSQL (el hecho de que la BD no contenga ninguna lgica de

negocio hace pensar que debera ser fcil la sustitucin de PostgreSQL por
otro SGBD).
Coste (agosto 2012)

Versin Enterprise:

1-10 usuarios 1950 / ao

10-25 usuarios: 3,950 / ao
25-70 usuarios: 9,950 / ao
ms usuarios: consultar.

Versin SaaS: 39 cada usuario / mes

Respecto las funcionalidades segn las versiones:

La versin Enterprise (de pago):

Licencia AGPL o AGPL + Private Use.

Incorpora soporte.
Incorpora migraciones ilimitadas (cuando se cambia de versin).
Incorpora parches ilimitados (para subsanar los errores detectados).
Permite disear mdulos privados (de los que no se est obligado a
facilitar el cdigo fuente).
Facilita alertas de seguridad

La versin Community (gratuita):

No incorpora soporte.
No incorpora migraciones.
No incorpora parches.
No permite disear mdulos privados (por lo tanto, estaremos obligados
a facilitar el cdigo fuente de los mdulos que desarrollamos).

La versin SaaS (de pago):

Incorpora el alojamiento a cargo de OpenERP.

Efecta las copias de seguridad.
Incorpora migraciones.
 Incorpora mantenimiento.
No permite tener mdulos privados.
No permite tener mdulos de la comunidad.

En cuanto a los clientes suministrados por OpenERP 6.1:

Cliente web, que permite la conexin va protocolo HTTP desde cualquier

navegador.
Cliente GTK, que se ha de instalar en cada mquina desde donde se quiera
acceder a OpenERP.

La versin 7 de OpenERP no facilita el cliente GTK

y nicamente se puede utilizar el cliente web.

Ya que todas las mquinas actuales incorporan un navegador, es til la existencia

del cliente web, ya que facilita el uso del OpenERP desde cualquier mquina, sin
tener que proceder a instalar ningn software. Sin embargo, los usuarios
acostumbrados al cliente GTK son reacios al cambio hacia el cliente web para que
se pierden los atajos de teclado.

El cliente GTK se basa en el proyecto GTK + ( www.

gtk. org ), un conjunto de herramientas
multiplataforma para la creacin de interfaces de
usuario, bajo licencia GNU LGPL .

Para llegar a ser capaces de efectuar instalaciones reales del OpenERP hay que
empezar realizando implantaciones del OpenERP en un sistema cercano en el que
nos movemos con facilidad.

Ya que el servidor OpenERP puede instalarse sobre

Windows y Linux hay que decidirse por uno de los
dos. Se elige Windows por ser el sistema ms
conocido por los usuarios.

Por otra parte, antes de planificar el aprendizaje, es altamente recomendable

conocer las posibilidades de instalacin que facilita el producto. Por este motivo,
hay que hacer una visita a la pgina web oficial de OpenERP ( www. OpenERP.
como ) y observar las diversas distribuciones que facilita (a fecha de agosto de
2012), recogidas en la tabla 2 .1 , mesa 2 .2 y tabla 2 .3 .

Tabla 2.1. Distribuciones de OpenERP disponibles

en agosto de 2012 para OpenERP 6.1
Plataforma Materiales facilidades
Windows Auto-Installer Release Notes (html)
Todo en One (. exe)
GTK Cliente (. exe)
 Sources Release Notes (html)
Todo en One (. tar.gz)
GTK Cliente (. tar.gz)
Debian / Ubuntu Todo en One (. Deb)

Tabla 2.2. Distribuciones de OpenERP disponibles

en agosto de 2012 para OpenERP 6.0
Plataforma Materiales facilidades
Windows Auto-Installer Todo en One (. Exe)
Server (. exe)
GTK Cliente (. exe)
Web Client (. exe)
Sources Server (tar.gz)
Cliente (tar.gz)
Web Client (tar.gz)
Debian / Ubuntu Server (. Deb)
GTK Cliente (. deb)
MacOS X GTK Cliente (. Dmg)

Tabla 2.3. Distribuciones de OpenERP disponibles

en agosto de 2012 para OpenERP 5.0.14
Plataforma Materiales facilidades
Windows Auto-Installer Todo en One
Server
GTK Cliente
Web Cliente
Sources Server (tar.gz)
GTK Cliente (tar.gz)
Web Client (tar.gz)

Las distribuciones Todo en One (todo en uno) incorporan todas las piezas
imprescindibles para poder instalar un servidor OpenERP, incluyendo, incluso,
una versin del SGBD PostgreSQL. Como se supone que no somos expertos en
instalacin y configuracin del SGBD PostgreSQL y ya que nos facilita la
distribucin Todo en Uno que incluye la instalacin de una versin de
PostgreSQL, la lgica nos dice que empezamos para instalar esta distribucin en
un sistema operativo conocido (Windows).

El itinerario de pasos a seguir con el objetivo final de tener los conocimientos

adecuados para poder efectuar implantaciones tcnicas de OpenERP es:

1. Instalar OpenERP Todo en Uno en el SO Windows.

2. Instalar el cliente GTK de OpenERP en SO Windows.
3. Distinguir los tipos de usuarios existentes en torno a un servidor OpenERP.
4. Adquirir conocimientos bsicos del servidor PostgreSQL.
5. Instalar OpenERP en SO Windows conectando con un SGBD PostgreSQL
existente.
6. Gestionar empresas con OpenERP.
 6. Gestionar empresas con OpenERP.
7. Conocer el funcionamiento de los clientes web y GTK.
8. Instalar mdulos segn las necesidades de la organizacin.
9. Instalar OpenERP en sistemas operativos Linux.

2.1.InstalacindeOpenERPTodoenUnoenelSOWindows

Las distribuciones Todo en One incorporan todas las piezas necesarias para la
instalacin de un servidor OpenERP y, en ocasiones, tambin el cliente GTK. Pero
no todas las distribuciones Todo en One incorporan las mismas piezas.

As, si ejecutamos la instalacin de la distribucin Todo en Uno de la versin 6.0

aparece la pantalla de la figura 2 .1 , en la que observamos que nos permite
instalar el servidor OpenERP, el cliente GTK, el cliente web y el SGBD PostgreSQL.
La opcin PostgreSQL Database estar inactiva si el instalador detecta la
existencia de un servidor PostgreSQL en la mquina.

En cambio, la instalacin Todo en Uno de la versin 6.1, slo incorpora el servidor

OpenERP (que incluye el navegador) y una versin del SGBD PostgreSQL. Es
decir, no permite la no instalacin del cliente web y no facilita la instalacin del
cliente GTK. Cabe recordar que la versin 7.0 de OpenERP elimina el cliente GTK.

Figura 2.1. Pantalla de eleccin de componentes del

instalador Todo en Uno de OpenERP 6.0 para Windows

La barra superior azul de la figura 2 .1 nos da tambin una informacin

importante. Destaca que se trata de la versin 6.0-subversin del 9 de marzo del
2012. Esto es importante tenerlo presente, porque OpenERP publica
peridicamente una nueva versin de la versin vigente y en la web de OpenERP
slo se puede descargar la ltima. De hecho, el proceso de descarga facilita un
archivo con nombre OpenERP-allinone-setup-6. 1-latest. Exe y slo podremos
saber de qu subversin se trata cuando comenzamos la instalacin.
Instalamos una versin concreta Todo en One Community para Windows (versin
6.1-YYYYMMDD-RELEASE) y tambin el correspondiente cliente GTK. Si proceda
a descargar la ltima versin de ambos productos e inicie la instalacin, ver que
hay una versin ms nueva.

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye las versiones de
los programas a los que hacemos referencia en
estos materiales.

Figura 2.2. Pantalla de eleccin de componentes del

instalador Todo en Uno de OpenERP 6.1 para Windows

Iniciamos la instalacin. Despus de seleccionar el idioma del proceso de

instalacin (ingls o francs) y aceptar los trminos de la licencia, se nos permite
seleccionar el tipo de instalacin, como se muestra en la figura 2 .2 .

El proceso propone la instalacin Todo en Uno con los componentes OpenERP

Server (que incorpora el servidor OpenERP y el cliente web) y PostgreSQL
Database (necesario si no disponemos ya de un servidor PostgreSQL instalado.
En esta primera instalacin instalacin, mantendremos los dos componentes (no
podemos tener un SGBD PostgreSQL instalado en la mquina).

Procedemos, pues, con la instalacin de los dos componentes y de inmediato se

nos facilita la pantalla de configuracin para la conexin PostgreSQL , con unos
valores por defecto, como muestra la figura 2 .3 .

Figura 2.3. Pantalla de configuracin para conectividad

con el servidor PostgreSQL del instalador de OpenERP
En estos momentos ira muy bien tener unos mnimos conocimientos de
administracin de SGBD y, en su defecto, de conectividad con SGBD. Lo mnimo
que debemos saber es que la mayora de conexiones a efectuar contra un SGBD
utilizan el protocolo TCP / IP y, en consecuencia, necesitamos conocer:

El nombre o direccin IP de la mquina donde est instalado el SGBD.

El puerto TCP por el que est escuchando el SGBD.
El usuario y la contrasea del usuario autorizado a establecer conexin.

Como el proceso Todo en Uno instala el servidor PostgreSQL en la misma

mquina donde instalamos el servidor OpenERP, ya es correcto mantener
localhost como valor por Hostname . En cuanto al puerto ( 5432 ), hay que saber
que este es el puerto TCP por el que normalmente escucha un servidor PostgreSQL
y, por tanto, mantendremos el valor. En cuanto el usuario ( openpg ) que
propone el proceso de instalacin, hay que saber que este ser el superusuario del
SGBD PostgreSQL que estamos instalando. Puede dejar al usuario que propone el
proceso, pero tambin puede cambiarlo segn sus preferencias. Nosotros lo
cambiamos y le asignamos IOC , con contrasea iocioc . Esta informacin es
crtica y, por tanto, hay que tenerla anotada en un lugar seguro.

Una vez hecho esto, se nos permite indicar el directorio de instalacin y

procedemos. Despus de unos minutos, el proceso finaliza. El propio proceso, en
la ltima pantalla, nos facilita una casilla de verificacin llamada Start OpenERP
para empezar a trabajar con OpenERP inmediatamente, a travs de una conexin
HTTP . Si mantiene la opcin activada y finalice el proceso, ver cmo se abre el
navegador que tenga por defecto e intenta conectarse a la URL localhost:
8069/web/webclient / como muestra la figura 2 .4 . Fijmonos que el servidor web
que instala OpenERP 6.1 escucha por el puerto 8069. En cambio, el servidor
OpenERP de la versin 6.0 escucha por el puerto 8080.

Si miramos el panel de control de los servicios del sistema operativo, hay

observaremos dos servicios, puestos en marcha y con inicio automtico (es decir,
se ponen en marcha de forma automtica cuando se pone en marcha la
mquina):

PostgreSQL for OpenERP

OpenERP Server 6.1
En el rbol de programas de Windows, observamos los submens:

OpenERP Server 6.1-YYYYMMDD-RELEASE, con un enlace hacia la pgina

web que intenta conectar con el cliente web.
PostgreSQL 8.3, con varias opciones para configurar y administrar el SGBD
PostgreSQL.

En la carpeta del sistema de archivos donde se ha instalado OpenERP

(posiblemente C: \ Archivos de programa \ OpenERP 6.1-YYYYMMDD-
RELEASE ), encontramos dos carpetas:

PostgreSQL , que contiene todo lo que hace referencia al servidor PostgreSQL.

Server , que contiene todo lo que hace referencia al servidor OpenERP
(cliente web incluido).

Figura 2.4. Pantalla inicial del cliente web de OpenERP

Llegados aqu, si tuviramos ya instalada alguna empresa, la seleccionaramos en

el campo que OpenERP llama Database y podramos utilizar un usuario
autorizado (por la empresa en cuestin) para iniciar la gestin dentro del ERP.

En estos momentos no tenemos ninguna empresa ( Database segn

nomenclatura de OpenERP) creada y, por tanto, no podemos an entrar. Desde
esta pantalla disponemos del enlace Manage Databases en la parte inferior, para
gestionar empresas: crear, eliminar, hacer copia de seguridad y restaurar desde
copia de seguridad, acciones que tambin podremos ejecutar desde el cliente GTK.

Desde otra mquina de la red podemos intentar utilizar cualquier navegador para
trabajar con el cliente web de OpenERP. Slo habr que cambiar la palabra
localhost de la URL por el nombre o direccin IP de la mquina donde tenemos el
servidor OpenERP instalado.
2.2.InstalacindelclienteGTKdeOpenERPenelSO
Windows

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye las versiones de
los programas a los que hacemos referencia en
estos materiales.

La instalacin del cliente GTK 6.1-YYYYMMDD en cualquier mquina Windows

desde donde queramos acceder al servidor OpenERP (que puede residir o no en la
misma mquina), una vez aceptados los trminos de la licencia, nos permite
seleccionar el directorio de instalacin y en pocos segundos la instalacin finaliza.

Podemos observar que la instalacin ha generado el submen OpenERP GTK

Cliente 6.1 al rbol de programas de Windows con un enlace al cliente GTK por el
que tambin tendremos posiblemente un acceso al escritorio.

Al poner en marcha el cliente GTK, este mira si la propia mquina hay un servidor
OpenERP socket :/ / localhost: 8070. Si no lo encuentra, nos muestra
la pantalla de la figura 2 .5 .

Figura 2.5. Pantalla del cliente GTK de OpenERP

indicando que no puede conectar con el servidor OpenERP

Fijmonos en que el idioma que utiliza es el cataln, que es el idioma de entrada

predeterminado que tena activado la mquina Windows cuando hemos
procedido a la instalacin del cliente.

Si el servidor lo tenemos en otra mquina, deberemos proceder a pulsar el botn

Cambiar y cambiar la palabra localhost por el nombre o direccin IP de la
mquina donde tenemos el servidor OpenERP instalado. Una vez hemos indicado
la ubicacin del servidor, el cliente GTK hay busca una empresa. Si el servidor lo
tenemos en la misma mquina, como que el cliente GTK encuentra el servidor,
pasa directamente a buscar una empresa.

Tanto si el servidor est en la misma mquina como si es en una mquina remota,

si el cliente no detecta ninguna empresa en el servidor (base de datos segn
si el cliente no detecta ninguna empresa en el servidor (base de datos segn
nomenclatura OpenERP), informa del hecho con la pantalla de la figura 2 .6 .

Figura 2.6. Pantalla del cliente GTK de OpenERP

indicando que no detecta ninguna empresa en el servidor
OpenERP

En estos momentos no tenemos ninguna empresa creada y, por tanto, no

podemos entrar todava. El propio cliente GTK facilita la opcin de men Archivo
| Base de datos para gestionar empresas: crear, eliminar, hacer copia de
seguridad y restaurar desde copia de seguridad, acciones que tambin podremos
ejecutar desde cliente web.

2.3.UsuariosentornoaunservidorOpenERP

Antes de proceder a gestionar empresas es conveniente entender los tres tipos de

usuarios existentes en torno a un servidor OpenERP:

1. Usuario del servidor PostgreSQL con privilegio de creacin de

bases de datos: es el usuario de PostgreSQL que utiliza el servidor
OpenERP para crear y eliminar empresas (bases de datos) en el servidor
PostgreSQL. Una empresa de OpenERP se corresponde con una base de
datos dentro del servidor PostgreSQL.

En caso de que el servidor PostgreSQL haya sido instalado por el

procedimiento de instalacin de OpenERP, el proceso propone el usuario
openpg (contrasea openpgpwd ) como superusuario del servidor
PostgreSQL, pero se puede decidir cualquier pareja (usuario-contrasea
).
En caso de que el servidor PostgresSQL haya sido instalado de manera
independiente al procedimiento de instalacin de OpenERP, dispondr
de un superusuario y deberamos poder utilizar este (siempre que no se
llame postgres , ya que por cuestiones de seguridad OpenERP no permite
este nombre de usuario) o cualquier otro con autorizacin para crear
bases de datos para que lo utilice el OpenERP para crear y eliminar
empresas (bases de datos) en el servidor PostgreSQL.
El usuario del servidor PostgreSQL con autorizacin para crear bases de
datos y su contrasea deben residir, respectivamente, en las entradas
db_usery db_passworddel fichero OpenERP-server. conf ubicado en
camOnResideixOpenERP / Server / server . Si en compruebe el
contenido se ver el usuario IOC y la contrasea iocioc que habamos
 contenido se ver el usuario IOC y la contrasea iocioc que habamos
indicado en el proceso de instalacin.

2. Usuario administrador del servidor OpenERP: es un usuario nico

del servidor OpenERP, que es lo que puede crear y eliminar las empresas. No
tiene nombre y nicamente tiene contrasea. La contrasea inicial del
usuario administrador de cualquier servidor OpenERP es admin y el proceso
de instalacin del servidor OpenERP no facilita el cambio. Los clientes web y
GTK facilitan la opcin de cambio de contrasea. Esta contrasea est
almacenada en la entrada admin_passwddel fichero OpenERP-server. conf
que se encuentra en camOnResideixOpenERP / Server / server . En caso de
cambiar la contrasea accediendo directamente al archivo de configuracin,
ser necesario reiniciar el servidor OpenERP. El cambio de la contrasea
desde el cliente GTK efecta desde la opcin Archivo | Base de datos |
Contrasea del administrador . El cambio de la contrasea desde el cliente
web se efecta desde la opcin Manage Databases de la pgina inicial,
subopcin Password.
3. Usuarios de cada empresa creada en el servidor OpenERP: el
proceso de creacin de una empresa viene dado con un usuario
administrador, de nombre admin, por el que debemos introducir la
contrasea durante el proceso de creacin de la base de datos. El usuario
admin de cada empresa tiene todos los privilegios y, una vez conectado a la
empresa, puede crear usuarios, grupos de privilegios sobre los objetos de
OpenERP (terceros, productos, pedidos, albaranes, facturas ...) y asignar
usuarios a los varios grupos de privilegios. En caso de perder la contrasea
del usuario admin , un usuario administrador del servidor PostgreSQL puede
recuperarla consultando directamente la base de datos, a travs de las
herramientas de acceso que el servidor PostgreSQL facilita.
El proceso de creacin de una empresa permite cargar unos datos de
demostracin y, en tal situacin, tambin incorpora un usuario de nombre demo y
contrasea demo . Este usuario no existe en la creacin de una empresa vaca.

2.4.ConocimientosbsicosdelservidorPostgreSQL

PostgreSQL ( www. postgresql. org ) es un SGBD relacional distribuido bajo

licencia BSD, desarrollado por PostgreSQL Global Development Group.

En 17-08-2012 la versin de PostgreSQL vigente es

la 9.1.5, mientras que el servidor PostgreSQL que
instala el OpenERP es la versin 8.3.4 de 22-09-
2008.

Nosotros, como implantadores tcnicos de ERP, debemos ser conocedores de la

estructura de la base de datos por si tenemos que desarrollar mdulos que
complementen la funcionalidad que facilita el ERP.

Como la base de datos se encuentra implementada en un SGBD concreto, nos

conviene conocer las herramientas bsicas de que disponemos para movernos con
facilidad dentro del SGBD. La mayora de SGBD actuales facilitan dos tipos de
herramientas para acceder a las bases de datos y facilitar la gestin:
herramientas para acceder a las bases de datos y facilitar la gestin:

Herramientas grficas y / o consolas textuales: basadas en la arquitectura

cliente-servidor, obligan a instalar la herramienta en la mquina desde la que
se quiere acceder al SGBD, que puede residir en una mquina remota.
Herramientas grficas web: permiten el acceso desde navegadores y, por
tanto, evitan el tener que instalar ningn software cliente.

Para acceder a PostgreSQL disponemos de muchas herramientas. Entre ellas, hay

que conocer la existencia de:

Herramienta grfica pgAdminIII, con arquitectura cliente-servidor

Consola textual psql, con arquitectura cliente-servidor
Herramienta grfica phpPgAdmin, con servidor web (necesita PHP )

2.4.1.QuincorporaelservidorPostgreSQLqueinstalaOpenERP?
La versin All-In-One de OpenERP 6.1 incorpora la instalacin de la versin 8.3.4
del servidor PostgreSQL y de un conjunto de herramientas bsicas para su
gestin.

Si echamos un vistazo al rbol de programas del sistema operativo Windows

encontraremos la opcin de men denominada PostgreSQL 8.3 que contiene:

1. El men Documentation , que incorpora informacin diversa que hace

referencia al servidor PostgreSQL y la herramienta pgAdmin.
2. La herramienta grfica pgAdmin.
3. La opcin Start service que permite poner en marcha el servidor PostgreSQL
sin tener que ir al panel de control de servicios del sistema operativo.
4. La opcin Stop service que permite detener el servidor PostgreSQL sin tener
que ir al panel de control de servicios del sistema operativo.
5. La opcin Command Prompt que abre una consola de sistema y nos sita en
el directorio donde estn los programas ejecutables de PostgreSQL, por si hay
que utilizar alguno, destinados habitualmente a los administradores de
PostgreSQL.
6. El men Configuration Files que facilita la edicin de tres archivos de
configuracin de PostgreSQL: pg_hba.conf, pg_ident.conf y postgresql. conf.
La edicin del contenido de estos archivos es una tarea propia de los
administradores del SGBD ya ellos les dejaremos con una excepcin, ya que
nos puede convenir establecer conexin con el servidor PostgreSQL desde
mquinas remotas y para conseguirlo deberemos retocar algunos parmetros
de configuracin.

2.4.2.HerramientapgAdmin
La herramienta pgAdmin es una de las herramientas ms habituales de utilizar
para acceder a un servidor PostgreSQL (local o remoto) y se puede instalar en
cualquier mquina. La podemos descargar de la pgina oficial ( www. pgadmin.
org ) y es tan habitual que el OpenERP la incorpora en la instalacin del servidor
PostgreSQL que facilita.

Al poner en marcha cualquier versin de pgAdmin, aparece una pantalla como la

Al poner en marcha cualquier versin de pgAdmin, aparece una pantalla como la
de la figura 2 .7 .

La parte izquierda de la pantalla principal de pgAdmin est destinada a

incorporar todos los servidores PostgreSQL a los que queremos acceder a esta
herramienta, ya sean en la propia mquina o en mquinas remotas. Cabe
comentar que en una misma mquina pueden coexistir varios servidores
PostgreSQL, con la precaucin que deben escuchar para diferentes puertos.

Figura 2.7. Pantalla principal de la herramienta pgAdmin

para administrar servidores PostgreSQL

La figura 2 .7 , que corresponde a la herramienta pgAdmin que instala el

OpenERP, nos permite observar que pgAdmin ya tiene registrado el servidor
PostgreSQL instalado para OpenERP en la mquina y lo vemos acompaado de
una cruz roja que indica que no estamos conectados. Para establecer conexin y
poder gestionar su contenido hay situarnos encima y pulsar con doble clic del
ratn. Aparecer la ventana de dilogo para establecer conexin similar a la que
muestra la figura 2 .8 .

Figura 2.8. Ventana de dilogo de pgAdmin para

establecer conexin con una base de datos

Observamos que la ventana de dilogo de la figura 2 .8 nos indica que nos

estamos a punto de conectarse con el usuario IOC que habamos indicado como
estamos a punto de conectarse con el usuario IOC que habamos indicado como
superusuario del servidor PostgreSQL en el proceso de instalacin. Si no haba
cambiado, se le propondrn al usuario openpg .

La propuesta de usuario IOC la efecta para que el proceso de instalacin ha

registrado esta conexin dentro pgAdmin con el usuario IOC a las propiedades de
la conexin. Si nos situamos sobre la conexin PostgreSQL for OpenERP (
localhost: 5432 ) y pulsamos el botn secundario del ratn, podremos acceder a
las propiedades, tal como muestra la figura 2 .9 .

Figura 2.9. Ventana de propiedades de una conexin a

servidor PostgreSQL en pgAdmin

Observamos que en esta pgina de propiedades podremos cambiar el usuario por

defecto y tambin podremos grabar la contrasea, una vez conectados, para evitar
tener que introducirla cada vez que accedemos al servidor PostgreSQL.

Hay que tener mucho cuidado a la hora de dejar las contraseas registradas, eso
slo debera hacerse en mquinas de las que tenemos la seguridad de que slo
tendrn acceso los usuarios que, a la vez, deban tener acceso a los servidores
PostgreSQL registrados en pgAdmin.

Contraseas

Las contraseas registradas desde pgAdmin se encuentran en el fichero pgpass.

Conf ubicado dentro de una carpeta llamada PostgreSQL que se encuentra dentro
del perfil del usuario que ha creado las conexiones ya la mquina cliente desde la
que se ejecuta pgAdmin . Esta ubicacin depende de la versin del SO. En el caso
de Win7:
 ... \ Users \ nombredeusuario \ AppData \ Roaming \ postgresql

Es importante tenerlo presente, porque el resto de herramientas de PostgreSQL

instaladas en el sistema utilizan el mismo archivo para registrar o comprobar las
contraseas. En consecuencia, si un usuario ha registrado una conexin desde
pgAdmin con un usuario y la correspondiente contrasea, el resto de herramientas
de PostgreSQL no le exigirn introducir la contrasea para establecer conexin con
el servidor y utilizarn el usuario por el que existe la contrasea registrada.

Una vez establecida la conexin contra un servidor PostgreSQL (en nuestro caso
con la versin de pgAdmin que ha instalado OpenERP), la parte izquierda de la
pantalla de pgAdmin nos muestra el contenido del servidor PostgreSQL ( figura 2
.10 ).

Figura 2.10. Pantalla de pgAdmin con una conexin

abierta con una base de datos

Hay que recordar que esta herramienta est destinada a todo tipo de usuarios
informticos, sean o no administradores de bases de datos. Lo que bsicamente
hay que saber de estos herramienta es:

Un servidor PostgreSQL puede tener muchos usuarios . La imagen

nos muestra slo un usuario, de nombre IOC, que es el superusuario del
servidor PostgreSQL. Si nos situamos encima y pulsamos el botn secundario
del ratn para ir a sus propiedades, observaremos que tiene privilegios totales.
De momento no es necesario crear nuevos usuarios, pero cuando el ERP se
pone en ejecucin en una organizacin, sta puede tener usuarios finales que
deseen poder efectuar consultas contra las bases de datos y, en este caso, los
tendremos que facilitar un usuario con los privilegios de lectura adecuados
(pero nunca de escritura) a las bases de datos y tablas o vistas que
correspondan. No debemos confundir los usuarios del SGBD con los usuarios
del ERP. Los usuarios del ERP estn almacenados en tablas propias del ERP
y el ERP utiliza un usuario de PostgreSQL ( IOC en este caso) para acceder a
la BD de la empresa.
Un servidor PostgreSQL puede tener varias bases de datos, pero
 Un servidor PostgreSQL puede tener varias bases de datos, pero
como mnimo debe tener una. La figura 2 .10 muestra la existencia de
una base de datos de nombre postgres . En muchas ocasiones, la primera
base de datos que se instala se llama postgres, pero podra tener cualquier
otro nombre. El proceso de instalacin de OpenERP ha seguido la costumbre
de llamar postgres la primera base de datos del servidor. Esta primera base
de datos es especial en el sentido de que es la base de datos de mantenimiento
del servidor y nunca podr ser eliminada. De hecho, si intentamos eliminarla
todo situndonos encima y pulsando la tecla "Supr" nos aparecer un
mensaje informando que es la base de datos de mantenimiento y no puede ser
eliminada. Si nos situamos sobre el nodo raz del servidor al que estamos
conectados y observamos las propiedades en la parte derecha de la pantalla
veremos que postgres es la Maintenance database . Observamos que la base
de datos postgres tiene por propietario el usuario IOC. Esto quiere decir que
ha sido el usuario IOC quien lo ha creado. Ahora mismo no observamos
ninguna otra base de datos para que el servidor se acaba de instalar y an no
hemos creado ninguna empresa. A medida que vamos creando empresas irn
apareciendo las correspondientes bases de datos en el servidor PostgreSQL.
Cada base de datos tendr sus usuarios para gestionar la empresa desde
OpenERP; estos usuarios no sern usuarios de PostgreSQL y, por tanto, no
podrn utilizar ninguna herramienta como pgAdmin para acceder a las bases
de datos directamente.
Una base de datos PostgreSQL est compartimentada en
esquemas . Como mnimo hay un esquema de nombre pblico , los
contenidos son accesibles para todos los usuarios que tengan acceso a la base
de datos. Un esquema contiene todo aquello que en otros SGBD es el
contenido de una base de datos: dominios, tablas, vistas, funciones,
secuencias y disparadores. A pesar de que una base de datos PostgreSQL
pueda estar compartimentada en esquemas, en muchas ocasiones se utiliza
nicamente el esquema pblico . Este es el caso de las bases de datos que crea
OpenERP. Cada empresa se corresponde con una base de datos que tiene
toda la informacin dentro de la nica clase de nombre pblico .
Si pensamos utilizar pgAdmin para ejecutar sentencias DML ( insert,
update, delete) hay que saber que est configurada con el
comportamiento autocommit donde, es decir, cualquier operacin de
modificacin de datos sobre la base de datos es automticamente validada sin
que el usuario haya efectuar commity, por tanto, no es posible invocar un
rollback. En caso de querer cambiar este comportamiento hay que utilizar
la gestin de transacciones con las instrucciones begin, commity
rollback:

begin;
<instruccions SQL-DML>
<finalitzaci de la transaccin con commit o rollback>

2.4.3.ConfigurarPostgreSQLparaadmitirconexionesremotas
El servidor PostgreSQL que instala OpenERP (y tambin la mayora de
instalaciones de servidores PostgreSQL) estn configuradas para admitir
nicamente conexiones locales desde la mquina donde se aloja el servidor.

As, tanto si utilizan el cliente OpenERP web como el cliente GTK, stos se
conectan con el servidor OpenERP que reside en la misma mquina que el
conectan con el servidor OpenERP que reside en la misma mquina que el
servidor PostgreSQL y, por tanto, las conexiones siempre se efectan en local, lo
que significa que no es necesario tener configurado el servidor PostgreSQL para
que admita conexiones remotas.

Es muy posible, sin embargo, que queramos acceder directamente a las bases de
datos del servidor PostgreSQL desde otras herramientas clientes, como por
ejemplo:

Una instalacin pgAdmin ubicada en una mquina remota.

Una aplicacin que se quiere conectar a travs de ODBC.

Para conseguirlo necesitamos retocar algunos parmetros de configuracin del

servidor PostgreSQL y, para entender la utilidad de cada uno, hay que intentar la
conexin remota, ver los errores que se producen e ir aplicando las soluciones que
correspondan hasta lograr la conectividad. Necesitamos, por tanto, una
aplicacin instalada remotamente que quiera conectar con el servidor PostgreSQL.
Podemos utilizar la herramienta pgAdmin instalada en otra mquina de la red
(descargue la pgina oficial www. pgadmin. org ).

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye las versiones de
los programas a los que hacemos referencia en
estos materiales.

La instalacin de la herramienta pgAdmin es muy simple. El paquete de

distribucin no incluye todos los lenguajes pero, una vez instalado, se pueden
aadir siguiendo las instrucciones indicadas en la pgina web de pgAdmin.

Una vez instalada la herramienta pgAdmin en una mquina diferente de la que

contiene el SGBD, intentamos la gestin del servidor PostgreSQL desde este
pgAdmin. Lo primero que tenemos que hacer es registrar un servidor a travs de
la opcin File | Add Server . Nos aparece la pantalla de propiedades de la
conexin en la que necesitamos introducir:

1. Name : debe ser un nombre informativo del servidor PostgreSQL con el que
establecemos la conexin.
2. Host : debe contener el nombre o la IP de la mquina que contiene el servidor
PostgreSQL.
3. Puerto : nos propone 5432 que es el puerto por el que suelen escuchar los
servidores PostgreSQL.
4. MaintenanceDB : nos propone postgres y es la base de datos a la que
intentar conectarse.
5. Username : hay que indicar un usuario de PostgreSQL, en nuestro caso, IOC
o openpg si cuando instalamos OpenERP no tuvimos cambiarlo.
6. Password : hay que indicar la contrasea del usuario indicado en username .
Una vez introducidos estos valores, pulsamos OK para lograr la conexin y
aparece un mensaje de error similar al de la figura 2 .11 . El mensaje dice que la
direccin IP 10. 200. 180. 207 (suponemos que es la direccin IP de la mquina
donde reside el servidor PostgreSQL) y por el puerto 5432 no se encuentra ningn
servidor en ejecucin que acepte conexiones TCP / IP. Tambin nos recomienda
que revisemos si tenemos configurada correctamente la red ( VPN / tneles SSH /
firewall ).

Suponiendo que tenemos la red correctamente configurada, leemos el siguiente

prrafo en el que se nos dice que por razones de seguridad, PostgreSQL no
escucha para todas las direcciones IP de la mquina que contiene el servidor. Es
decir, el servidor PostgreSQL escucha slo por la direccin 127. 0. 0. 1 y, si
queremos que escuche por otras direcciones IP propias, hay que configurarlo.
Pensamos que un servidor puede tener varias direcciones IP y nos puede interesar
que las conexiones contra un servidor PostgreSQL slo se efecten por unas
direcciones IP determinadas.

Figura 2.11. Pantalla de error de pgAdmin cuando no

puede conectarse con un servidor

Para conseguir que el servidor PostgreSQL escuche por unas determinadas

direcciones IP hay que retocar, en el fichero de configuracin postgresql. Conf, el
parmetro listen_addresses. Veremos que el parmetro est configurado de
la forma:

# Listen_addresses = 'localhost'
# What IP address (es) to listen on;
# Comma-separated list of addresses;
# (Change requires restart)

Eliminamos el smbolo #del inicio que indica que el parmetro est comentado y,
a la palabra localhost aadimos, separadas por comas, las direcciones IP de la
mquina por las que queremos que el servidor PostgreSQL d respuesta. O,
simplemente, dejamos un asterisco para indicar que escuche por todas las
direcciones IP que tenga definidas.

Una vez registrado el cambio en el fitxerpostgresql. Conf, necesitamos reiniciar el

servidor PostgreSQL y volver a intentar la conexin. Nos aparece un nuevo error,
servidor PostgreSQL y volver a intentar la conexin. Nos aparece un nuevo error,
como muestra la figura 2 .

El mensaje de la figura 2 informa que en el fichero pg_hba.conf no se encuentra

una entrada para la mquina 10. 200. 1. 207 (suponemos que es la direccin de la
mquina cliente que est intentando la conexin) a la base de datos postgres por
el usuario IOC . Es decir, que el usuario IOC no tiene autorizacin para conectar
con la base de datos postgres desde la mquina 10. 200. 1. 207.

Figura 2.12. Pantalla de error de pgAdmin cuando el

servidor PostgreSQL rechaza la conexin

El fichero pg_hba.conf es un fichero que controla la autenticacin de los clientes

que se conectan al servidor PostgreSQL. Para una explicacin detallada de todas
las posibilidades que facilita este archivo, busque pg_hba.conf dentro de la
documentacin de PostgreSQL. De forma muy simplificada, necesitamos saber
que este archivo contiene lneas cada una de las cuales corresponde a un permiso
de autenticacin. Inicialmente viene configurado como:

# TYPE DATABASE USER CIDR-ADDRESS METHOD

# IPv4 local connections:

host all all 127.0.0.1/32 md5
# IPv6 local connections:
# Host all all :: 1/128 md5

Fijmonos con la nica lnea no comentada, que permite el acceso a todas las
bases de datos de cualquier usuario conectado a la propia mquina (127. 0. 0.
1/32) y que utiliza una contrasea encriptada con el mtodo md5 .

La nomenclatura CIDR-address 127. 0. 0. 1/32 se puede sustituir por la

nomenclatura que indica la direccin y la mscara en dos columnas:

host all all 127.0.0.1 255.255.255.255 md5

Para permitir el acceso a cualquier usuario desde la mquina con IP 10. 200. 1.
Para permitir el acceso a cualquier usuario desde la mquina con IP 10. 200. 1.
207, aadiramos una nueva lnea (debajo de la existente inicialmente):

host all all 10.200.1.207 255.255.255.255 md5

o equivalentemente:

host all all 10.200.1.207/32 md5

Para permitir el acceso a cualquier usuario desde cualquier mquina 10.200.xx,

aadiramos:

host all all 10.200.0.0 255.255.0.0 md5

o equivalentemente:

host all all 10.200.0.0/16 md5

La columna METHOD permite mltiples posibilidades. Entre ellas, la posibilidad

de prohibir la conexin (valor reject ). Hay que tener en cuenta que:

El servidor PostrgreSQL carga el contenido del archivo pg_hba.conf en

memoria cuando se pone en marcha y, por tanto, habr reiniciarlo ante
cualquier modificacin de este archivo.
Cuando se intenta autenticar una conexin, la evaluacin sigue el orden de
las diversas entradas existentes en pg_hba.conf y aplica la primera entrada
con la que se consigue una coincidencia. Como ejemplo, si la entrada 10
restringe la conexin para una IP XXX concreta pero en una entrada
anterior a la 10 se concede acceso por la IP XXX, la conexin ser
autenticada sin ningn problema.

2.4.4.ConsolatextualparagestionarunservidorPostgreSQL
El SGBD PostgreSQL facilita una consola textual (aplicacin de nombre psql)
para permitir efectuar un gran nmero de operaciones sobre el servidor. El
servidor PostgreSQL que instala el OpenERP para Windows no instala esta
consola ya que incorpora la herramienta pgAdmin y considera que ya es
suficiente.

En cambio, la instalacin especfica de la herramienta pgAdmin (descargada

desde la pgina oficial de esta herramienta: www. pgadmin. org ), s que
incorpora la consola psql, de la misma manera que lo hace la instalacin
instalacin de cualquier servidor PostgreSQL.

Suponiendo que hemos instalado la herramienta pgAdmin en una mquina

cualquiera, podremos comprobar el funcionamiento de la consola psql. As pues,
nos situamos en una consola de sistema y nos situamos en la subcarpeta donde
hemos instalado la herramienta pgAdmin. Comprobamos que reside el programa
psql. Exe (en Linux llamara psql). Intentamos ejecutarlo sin ningn parmetro.
Nos encontramos el error similar a:
 C: \ Program Files (x86) \ pgAdmin III.14> psql
psql: could not connect to server: Connection Refused
Is the server running on host "localhost" (:: 1) and
accepting TCP / IP connections on puerto 5432?

La herramienta psql intenta buscar un servidor PostgreSQL a la propia mquina

escuchando por el puerto 5432 y al no encontrarlo nos muestra el error anterior.

La herramienta psql admite muchos parmetros, que podemos conocer

ejecutando psql-ho psql - help. Para utilizar esta herramienta para
conectarnos con un servidor PostgreSQL, necesitamos utilizar los parmetros:

-H, para indicar el servidor PostgreSQL al que nos queremos conectar.

-P, para indicar el puerto (5432 si no se indica).
-Uno, para indicar un usuario del servidor PostgreSQL (si no se indica, coge
el usuario que tiene abierta la sesin en el sistema operativo).
-D, para indicar el nombre de la base de datos a la que nos queremos
conectar (si no se indica, intenta conectar con una base de datos de nombre
igual al del usuario indicado en el parmetro -U).

As, para conectar a un servidor residente en la mquina con IP 10. 200. 180. 207,
con usuario IOC y en la base de datos postgres , escribiremos la siguiente
instruccin y la herramienta nos pedir la contrasea:

C: \ ...> psql-h 10200180207-U IOC-d postgres

Password for user IOC:
psql (9.1.4, server 8.3.4)
WARNING: psql version 9.1, server version 8.3.
Some psql features might not work.
WARNING: Console code page (850) different from Windows code page (1252) 8-bit characters
Type "help" for help.

postgres = #

Fijmonos que:

Informa que la herramienta psql es de la versin 9.1.4 mientras que nos

estamos conectando a un servidor PostgreSQL 8.3. Por tanto, puede haber
alguna funcionalidad que no se ejecute correctamente.
Informa que el cdigo de pgina de la consola DOS (850) es diferente del
cdigo de pgina de Windows (1252). Esto provoca que caracteres especiales
como las vocales acentuadas, el smbolo y similares, bien registrados en la
base de datos, no se vean correctamente en la consola DOS y que los
caracteres especiales correctamente introducidos desde la consola DOS
queden mal registrados en la base de datos, de modo que cuando los
consultamos desde una herramienta como pgAdmin, son errneos. La
solucin a este inconveniente consiste, como indica la documentacin de psql
para los usuarios de Windows, cambiar el cdigo de pgina de la consola
DOS antes de poner en marcha la consola textual psql, ejecutando chcp 1252 ,
y cambiar la fuente de la consola a lucidez Console .
Informa que podemos teclear helppara conseguir ayuda. Si lo hacemos,
veremos que la orden \ qpermite abandonar la consola textual de
 veremos que la orden \ qpermite abandonar la consola textual de
PostgreSQL y volver a la consola del sistema operativo; veremos tambin que
la orden \ hinforma sobre las rdenes SQL que podemos ejecutar y que la
orden \?informa sobre las rdenes propias de la consola psql.
El prompt ha cambiado a postgres = #que nos informa de la base de
datos a la que estamos conectados.

La ejecucin de la orden \?dentro de la consola psql nos permite conocer que la

orden \ dtmuestra todas las tablas de la base de datos y que la orden \ d,
seguida de un nombre de tabla, permite obtener la descripcin detallada de la
estructura de la tabla. As, por ejemplo, para conocer las tablas de la base de datos
a la que estamos conectados, ejecutamos:

postgres = # \ dt;
No relations found.

La respuesta del servidor es que no se encuentra ninguna tabla, ya que en este

momento, la base de datos postgres no contiene ninguna.

Si tuviera alguna mesa podramos, con \ deconocer la descripcin de su

estructura y ejecutar instrucciones SQL (finalizadas con el smbolo ";"). Asimismo,
podemos proceder a crear tablas, vistas ... es decir, ejecutar cualquiera de las
instrucciones SQL . Si se quiere practicar, hay que crear una base de datos
especfica para las pruebas y no ensuciar nunca las bases de datos que crea
OpenERP ni la base de datos de mantenimiento postgres .

Para abandonar la consola textual y volver a la consola del sistema, escribiremos:

postgres = # \ q

Cuando se utiliza la consola psql debe tenerse en cuenta que est configurada con
el comportamiento autocommit donde, es decir, cualquier operacin de
modificacin de datos sobre la base de datos es automticamente validada sin que
el usuario tenga que efectuar "commit" y, en consecuencia, no es posible invocar
un rollback. En caso de querer cambiar este comportamiento, hay que ejecutar
la instruccin de psql siguiente, indicando la palabra AUTOCOMMITen
maysculas:

\ Septiembre AUTOCOMMIT OFF

Otra posibilidad de desactivar el comportamiento de validacin automtica, es

utilizar la gestin de transacciones con las instrucciones begin, commity
rollback:

begin;
<instruccions SQL-DML>
<finalitzaci de la transaccin con commit o rollback>

2.5.InstalacindeOpenERPenelSOWindowsutilizandoun
SGBDPostgreSQLyainstalado
SGBDPostgreSQLyainstalado

Es importante saber cmo instalar un servidor OpenERP en el sistema operativo

Windows aprovechando un servidor PostgreSQL ya instalado y, incluso, en una
mquina diferente de la mquina donde queremos instalar el servidor OpenERP.

Para ello, necesitamos tener un servidor PostgreSQL instalado en una mquina

(Windows o Linux). Proponemos que, en caso de ser una mquina Windows, sea
diferente de la mquina en la que instalaremos el servidor OpenERP. Si no tiene
conocimientos avanzados de PostgreSQL, se aconseja instalar la ltima versin
para Windows que se puede descargar de www. postgresql. org . Nosotros
instalaremos la versin 9.1.5.

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye las versiones de
los programas a los que hacemos referencia en
estos materiales.

La instalacin de un servidor PostgreSQL en Windows es muy simple y slo hay

que tener en cuenta:

1. Indicar el directorio donde queremos instalar el servidor PostgreSQL.

2. Indicar el directorio donde queremos que residan los datos (normalmente la
subcarpeta fecha de la carpeta de instalacin del servidor).
3. Indicar la contrasea por superusuario del servidor PostgreSQL, que en este
caso se denomina obligatoriamente postgres . Se recomienda anotar la
contrasea asignada.
4. Indicar el puerto por el que escuchar el servidor PostgreSQL que estamos
instalando (normalmente 5432 aunque habra que indicar otro puerto si ya
hubiera algn servidor PostgreSQL instalado y escuchando por este puerto).
Al finalizar el proceso, se nos facilita la posibilidad de poner en marcha la
aplicacin Stack Builder para instalar herramientas y conectores que podamos
necesitar. En este caso n'avortarem la ejecucin.

Una vez instalado el servidor PostgreSQL deberemos configurarlo para que

admita conexiones remotas y por eso necesitamos saber que los archivos de
configuracin postgresql. Conf y pg_hba.conf que se deben retocar residen en el
directorio donde se ha instalado los datos del servidor PostgreSQL.

Podemos comprobar el funcionamiento correcto y la conectividad del nuevo

servidor PostgreSQL intentando la conexin desde la herramienta pgAdmin
instalada en cualquier otra mquina. En caso de que se utilice la herramienta
pgAdmin que instala el OpenERP, observar que la conexin con el servidor se
establece pero que hay problemas para manejar las bases de datos, esto es debido
a que la herramienta pgAdmin suministrada por OpenERP es demasiado antigua
para gestionar servidores PostgreSQL actuales.

Una vez disponemos de un servidor PostgreSQL instalado (versin 9.1.5), la

instalacin del servidor OpenERP a partir de la versin All-In-One 6.1-
instalacin del servidor OpenERP a partir de la versin All-In-One 6.1-
YYYYMMDD es idntica a la instalacin completa con la nica diferencia que no
marcaremos la opcin de instalar el servidor PostgreSQL y que en la pantalla de
configuracin de la conectividad con el servidor PostgreSQL indicaremos los datos
que correspondan:

Hostname : la direccin IP de la mquina que contiene el servidor

PostgreSQL.
Puerto : el puerto por el que escucha el servidor PostgreSQL (5432
normalmente).
Username : un usuario del servidor PostgreSQL con el rol 'puede crear bases
de datos' .
Password : la contrasea del usuario indicado en username .

OpenERP no permite que el usuario de PostgreSQL que se utiliza para mantener

la conexin con el servidor PostgreSQL llame postgres . En caso de intentarlo, el
servidor OpenERP no se pondr en marcha; parecer que el correspondiente
servicio se ponga en marcha pero si procedemos a actualizar (F5) la lista de los
servicios, observaremos como el servidor no est en ejecucin.

Para crear un usuario en el servidor PostgreSQL, podemos:

Utilizar la herramienta pgAdmin para conectarnos con un superusuario

(posiblemente postgres ) y una vez conectados, navegar hasta el nodo Login
Roles en el que, con el botn secundario del ratn, podemos proceder a la
creacin de un nuevo usuario, indicando:

Role name: el nombre que interese ( IOC , por ejemplo).

Password: lo que se quiera ( iocioc , por ejemplo).
Role privileges: Can create database objects

Utilizar la herramienta psql para conectarnos con un superusuario

(posiblemente postgres ) y una vez conectados proceder a la creacin del
nuevo usuario con la sentencia SQL de PostgreSQL que corresponda.

Una vez tenemos el nuevo usuario creado en el servidor PostgreSQL podemos

instalar el servidor OpenERP. Cuando finalizamos la instalacin, tendremos que
hacer los mismos retoques de configuracin que efectuamos en la instalacin
completa, en los ficheros OpenERP-server. Conf. Una vez registrados los cambios
que corresponda, es necesario reiniciar el servidor OpenERP (en el panel de
control de los servicios del sistema).

2.6.GestindeempresasenOpenERP

La creacin y eliminacin de empresas en OpenERP efecta desde cualquiera de

los dos clientes (web y GTK).

En el cliente web, desde la pantalla de inicio, por la opcin Manage Databases ,

tal como muestra la figura 2 .

Figura 2.13. Pantalla inicial del cliente web de OpenERP

 con el enlace que permite gestionar empresas

Desde el cliente GTK, por la opcin Archivo | Bases de datos , tal como muestra la
figura 2 .

Figura 2.14. Pantalla inicial del cliente GTK de OpenERP

con la opcin que permite gestionar empresas

2.6.5.Creacindeempresas
Para crear una nueva empresa (base de datos, segn terminologa OpenERP), sea
cual sea el cliente de OpenERP que utilizamos, tendremos que introducir:

Contrasea para el Super de OpenERP: si no se cambia, es admin .

El nombre de la empresa (base de datos): no tiene porque ser la razn
social, sino un nombre que identifique, en el OpenERP, la empresa a la hora
de entrar. Este ser el nombre de la base de datos dentro del servidor
PostgreSQL.
 PostgreSQL.

El nombre de la base de datos no permite caracteres especiales ni

espacios en blanco. nicamente caracteres normales y el guin bajo. En
este caso lo llamamos Em-sa_IOC .
El cliente GTK no distingue entre maysculas y minsculas y crea la base
de datos con el nombre en minsculas. En cambio, el cliente web s
mantiene las maysculas.

Marca para la carga de datos de demostracin: en una instalacin

para gestionar una empresa esta opcin nunca se activa, pero a nosotros nos
interesa activarla para poder disponer de una empresa con datos (clientes,
productos, proveedores ...) y poder empezar a probar el funcionamiento de
OpenERP.
El idioma por defecto cuando el usuario administrador ( admin )
se conecte: posteriormente se puede cambiar.
Contrasea para el usuario administrador ( admin ) de la
empresa que estamos creando: hay que recordar que el proceso de
creacin de una empresa crea la empresa con el usuario admin y la
contrasea de obligada introduccin en el momento de creacin. Tambin
crear un usuario de nombre demo y contrasea demo en caso de cargar los
datos de demostracin.

As pues, seleccione el idioma que se crea oportuno, asigne la contrasea para el

usuario admin de la nueva base de datos y procede a ejecutar la creacin. El
proceso puede durar unos minutos.

Una vez finalizado, si entramos en la empresa desde el cliente web con el usuario
admin nos aparece una pantalla como la de la figura 2 , con una nica pestaa,
Configuracin , y una lista de los mdulos que podemos instalar en la pantalla.

Figura 2.15. Pantalla inicial desde el cliente web cuando

se conecta con una empresa como usuario admin

La entrada desde el cliente GTK parece diferente pero es totalmente equivalente,

ya que nos muestra el contenido del men Configuracin idntico al que vemos
desde el cliente web si elegimos la pestaa Configuracin . La figura 2 nos
muestra la pantalla del cliente GTK.
 Figura 2.16. Pantalla inicial desde el cliente GTK cuando
nos conectamos con una empresa como usuario admin

Observamos que tanto en el cliente web como en el cliente GTK hay una zona de
atajos para contener las opciones ms habituales y, en este momento, nicamente
existe la opcin Clientes . Si la seleccionamos desde cualquiera de los dos clientes
veremos que nuestra empresa ya tiene una serie de socios de negocios
introducidos (OpenERP los llama Clientes ). La figura 2 nos muestra la
visualizacin de los clientes desde el cliente GTK.

Figura 2.17. Visualizacin de los clientes que carga

OpenERP en crear una empresa, si as se le indica

La figura 2 muestra el contenido de la opcin de men denominada Clientes pero

en su interior se observa unos botones para seleccionar clientes o proveedores o
bien ambos. La nomenclatura que utiliza OpenERP no parece suficientemente
adecuada ya que bajo la opcin Clientes se gestionan todas aquellas entidades con
las que podemos hacer negocios. Sera ms adecuada la nomenclatura que
utilizan otros ERPs: Socios de negocio (Business partners) o Terceros o
Interlocutores comerciales .

Si cerramos la conexin (desde el cliente web con el enlace Logout de la parte

Si cerramos la conexin (desde el cliente web con el enlace Logout de la parte
superior derecha de la pantalla o bien con el cliente GTK desde la opcin de men
Archivo | Desconectar ) y procedemos a entrar como usuario demo con
contrasea demo , veremos que la conexin se establece pero que no hay ninguna
opcin de men ni atajo disponible.

La creacin de una empresa implica la aparicin, en el servidor PostgreSQL, de

una base de datos con el nombre indicado en el proceso de creacin. As, si
utilizamos pgAdmin para acceder al servidor PostgreSQL, hay observaremos la
aparicin de la base de datos de nombre Empresa_IOC , como muestra la figura
2.

Figura 2.18. Visualizacin de la base de datos

correspondiente a la empresa Empresa_IOC de OpenERP

Si observamos el contenido de la base de datos Empresa_IOC veremos que

contiene 107 tablas y 86 secuencias, dentro del esquema pblico . Fijmonos en
que no hay ninguna funcin ni ningn disparador definidos, es decir, toda la
lgica de negocio reside en el servidor OpenERP.

Observamos tambin que el propietario de la base de datos es el superusuario de

PostgreSQL que utiliza el servidor OpenERP para conectarse con el servidor
PostgreSQL.

Situndonos sobre una mesa y pulsando el botn secundario del ratn podemos
ejecutar varias acciones: crear nuevas tablas, eliminar la tabla, ver el contenido de
la tabla, etc.

La manipulacin de las estructuras de datos (tablas, secuencias,

disparadores, vistas, funciones ...) de una base de datos de un
ERP nunca se debera efectuar, a no ser que seguimos un
protocolo claramente definido por el fabricante del ERP.

El inters que tiene el acceso directo a la base de datos se basa en:

 Recuperar nombres y contraseas de los usuarios de OpenERP. Para ello,
slo hay que situarnos encima de la mesa res_users , pulsar el botn
secundario del ratn y elegir Ver Datos . All veremos los usuarios de
OpenERP de la empresa con sus contraseas.
Definir consultas (vistas) para que los usuarios de la organizacin puedan
ejecutar y obtener datos con una estructura que puede que no facilita el ERP.
Disear y ejecutar algn proceso de actualizacin de los datos almacenados,
para solucionar posibles errores producidos por una manipulacin errnea
del ERP. Esto slo es factible si se tiene un conocimiento profundo de la
estructura de la base de datos del ERP y el fabricante del ERP nunca se har
responsable de la coherencia de los datos almacenados si se manipulan los
datos desde fuera el ERP.

2.6.6.Eliminacindeempresas
La eliminacin de una empresa implica la eliminacin de la correspondiente base
de datos y se puede efectuar desde cualquiera de los dos clientes (web y GTK):

1. Desde el cliente web, ejecutando la opcin Manage Databases de la pgina

inicial.
2. Desde el cliente GTK, desde la opcin Archivo | Base de datos .
Para poder eliminar una base de datos de un servidor OpenERP tendremos que
indicar la contrasea del Super Administrador del servidor OpenERP ( admin , si
no se ha cambiado) y no puede haber ninguna conexin abierta contra la base de
datos (si fuera , la eliminacin no se llevara a cabo).

2.7.IniciacinbsicaaOpenERP

El proceso de creacin de una empresa en OpenERP crea la base de datos en el

servidor PostgreSQL, con el usuario admin (y el usuario demo si se ha cargado los
datos de demostracin) y crea las tablas y las secuencias necesarias para la gestin
del ERP. Algunas de las tablas contendrn informacin en caso de que en el
proceso de creacin se haya indicado la carga de datos de demostracin.

OpenERP 6.1 instala 107 mesas y 86 secuencias en

la base de datos en el proceso de creacin de una
empresa.

La creacin de una empresa instala nicamente el mdulo Base de OpenERP que

incorpora, como se puede ver en la figura 2 , la opcin de men Configuracin y
un acceso directo a una ficha bsica de Socios de negocios ( Clientes segn
nomenclatura OpenERP pero que en realidad incluye las entidades con las que se
hace negocios y que, por tanto, pueden ser clientes o proveedores).

Figura 2.19. Opciones posibles en una empresa de

OpenERP recin creada
La figura 2 muestra las opciones posibles en una empresa recin creada. Vemos la
opcin de men Configuracin que contiene varias opciones de configuracin (
Mdulos, Configuracin, Compaas, Usuarios, Traducciones, Garanta ) y el
atajo Clientes . Fijmonos en que la mayora de opciones son en cataln, pero
encontramos algunas palabras en ingls ( Sequences & Identifiers ...). OpenERP
se desarrolla en ingls y permite incorporar traducciones a diferentes idiomas,
pero en ocasiones estas traducciones no son completas o no evolucionan tan
rpidamente como evoluciona el ERP y cuando una opcin de la aplicacin no
tiene definida la traduccin en el idioma activo, OpenERP muestra la versin
inglesa.

La figura 2 muestra muchas opciones en cataln porque en el proceso de creacin

de la empresa hemos asignado el idioma cataln al usuario admin . Debido a este
hecho, la empresa creada dispone de dos idiomas cargados: ingls y cataln.
Cualquiera de los usuarios de la empresa puede fijar el idioma que desee, de entre
los idiomas cargados en la empresa, en sus preferencias.

Llegados aqu, para poder utilizar significativamente el OpenERP necesitamos

saber:

Como incorporar idiomas y cmo un usuario puede elegir el idioma

preferente.
Cmo funcionan las interfaces web y GTK.
Como configurar los datos bsicos de una empresa (compaas, nombre,
logo, etc).
Cmo incorporar los mdulos que sean necesarios para la organizacin.
Cmo crear usuarios y asignarles a ellos privilegios de acceso.

2.7.7.Incorporacindeidiomas
La incorporacin de idiomas en una empresa OpenERP es muy simple y se puede
ejecutar desde cualquiera de los clientes OpenERP, cuando se establece conexin
con el usuario admin y se navega hasta la opcin Configuracin | Traducciones |
Carga una traduccin oficial .
La ejecucin de esta opcin facilita una pantalla como la de la figura 2 , que
contiene el desplegable idioma que nos permite escoger uno de los idiomas que
incorpora OpenERP.

Figura 2.20. Pantalla de OpenERP para cargar un nuevo

idioma a la empresa activa

Una vez seleccionada y ejecutada la carga, cualquier usuario puede seleccionar el

nuevo idioma como preferente, que se puede llevar a cabo:

En el cliente GTK, por la opcin Usuario | Preferencias . Hay que cerrar el

men y volver a abrir para ver las opciones en el nuevo idioma.
El cliente web, por el botn Preferencias de la parte superior derecha de la
pgina. En este caso, el cambio hacia el nuevo idioma es automtico.

2.7.8.IniciacinalasinterfaceswebyGTK
Para llevar a cabo la implantacin tcnica del OpenERP es altamente
recomendable conocer el funcionamiento de las interfaces web y GTK facilitados
por OpenERP.

Para ello, adems de dedicar tiempo y aplicar la intuicin que seguro tenemos
desarrollada gracias a haber utilizado una gran cantidad de software,
utilizaremos algunos de los materiales existentes en la web.

En los anexos de la web encontrar el apartado

"Iniciacin a las interfaces web y GTK de
OpenERP" que facilita algunos enlaces a materiales
existentes destinados a iniciarnos en los clientes
web y GTK suministrados por OpenERP.

El servidor OpenERP 6.1 instalados en el SO Windows con PostgreSQL 9.1

presentan un problema: las imgenes (iconos, logo de compaa, imgenes de
productos, etc.) No se visualizan. El proceso de incorporacin de cualquier
imagen funciona perfectamente pero, una vez incorporada, OpenERP (cliente
imagen funciona perfectamente pero, una vez incorporada, OpenERP (cliente
web y GTK) no la visualiza. La solucin es efectuar un cambio en la configuracin
del servidor PostgreSQL 9.1, concretamente en el archivo postgresql. Conf donde
hay que sustituir la lnea:

# Bytea_output = 'hex' # hex, escape

por:

bytea_output = escape '# hex, escape

y posteriormente es necesario reiniciar el servidor PostgreSQL y el servidor

OpenERP.

2.7.9.Configuracinbsicadeunaempresa
El proceso de creacin de una empresa no pide ningn dato de la empresa y, por
tanto, corresponde hacer a posteriori el proceso de configuracin. Este proceso se
puede llevar a cabo a travs de cualquiera de los clientes OpenERP, estableciendo
conexin con el usuario admin y navegando hasta la opcin Configuracin |
Compaas | Compaas .

La ejecucin de esta opcin muestra la pantalla de la figura 2 , en la que podemos

observar la existencia de una nica compaa o empresa, con nombre Your
Company pero con la posibilidad de crear ms compaas.

OpenERP permite que una empresa est estructurada en muchas compaas, lo

que se denomina gestin multicompanyia.

Figura 2.21. Pantalla de configuracin de los datos de la

empresa y sus compaas

La utilizacin de varias compaas en una empresa est justificada en un entorno

con varias organizaciones que trabajan de forma independiente (clientes o
proveedores propios, productos propios, almacenes propios, plan contable propio,
etc.) Pero que estn bajo el cobijo de una organizacin madre, que puede querer
etc.) Pero que estn bajo el cobijo de una organizacin madre, que puede querer
ver, en un determinado momento, los resultados globales.

La gestin multicompanyia se encuentra en empresas grandes (puede haber

PYMES con gran implantacin en las que esta situacin tambin sea normal).
OpenERP no limita la estructura multicompanyia a dos niveles, sino que permite
ms niveles.

Si trabajamos en un entorno multicompanyia, deberemos tener en cuenta:

En gestionar los usuarios de la empresa, habr que indicar las compaas a

las que tiene acceso el usuario. Hay que tener claro que la asignacin de una
compaa a un usuario implica el acceso de este usuario a las operaciones de
la compaa y de las compaas hijas.
Cuando se gestionen los terceros ( Clientes de OpenERP), hay que asignar
cada socio (cliente o proveedor) a la compaa que corresponda. Hay que
tener claro que la asignacin de un tercero a una compaa implica el acceso
desde cualquier compaa hija a la compaa a la cual est asignado.

Ejemplo de una instalacin OpenERP con

multicompanyia

Supongamos que la multinacional X tiene varias empresas en diversos estados: X-

Espaa, X-Francia, X-Blgica ... OpenERP permite, en este caso, crear la empresa
X y dentro de ella crear tantas compaas como nmero de pases en los que se
encuentra implantada. Para ello, se deben ir creando compaas (X-Espaa, X-
Francia, X-Blgica) y cada compaa debe asignarse como empresa matriz (segn
la figura 2 ), la empresa X ( que no deja de ser una compaa). De esta manera se
consigue una estructura jerrquica de dos niveles con la compaa X como raz y
las compaas X-Espaa, X-Blgica y X-Francia como hijas de la raz.
Supongamos que X-Espaa tiene dos sucursales fiscalmente independientes en
Euskadi y Catalua. OpenERP permite crear las compaas X-Esp-Euskadi y X-
Esp-Catalua asignndoles X-Espaa como empresa matriz, de modo que
podemos conseguir una estructura multicompanyia de tres niveles como muestra
la figura 2 .
Si a un usuario se le asigna la compaa X-Espaa, tendr acceso a las operaciones
efectuadas desde X-Espaa y tambin en las operaciones de X-Esp-Catalua y X-
Esp-Euskadi, mientras que no tendr acceso a las operaciones de X-Francia ni de
X-Blgida ni de X.

Si un tercero la asignamos a X-Esp-Catalua, podr ser gestionado por los

usuarios con acceso a las compaas X, X-Espaa y X-Esp-Catalua, pero en
cambio no podr ser gestionado por los usuarios que slo tengan acceso a X
Francia o X-Blgica o X-Esp-Euskadi.

La visualizacin jerrquica de la figura 2 es factible, por el usuario admin desde

Configuracin | Compaas | rbol de la compaa , opcin que aparece si se ha
activado la casilla Usability | Multi companies de la pestaa Permisos de acceso
de la ficha el usuario admin ( figura 2 ), accesible desde Configuracin |
Usuarios | Usuarios .

Figura 2.22. Visualizacin jerrquica de las compaas

 existentes en la empresa

Figura 2.23. Casilla de la ficha de usuario para permitir la

visualizacin jerrquica de las compaas de la empresa

Cada compaa puede tener su propio plan contable y se puede, si se desea,

vincular a un tercer plan contable para efectuar una consolidacin de las diversas
compaas.

OpenERP permite establecer valores por defecto en campos de formularios

diferentes para cada compaa, de modo que cuando un usuario utiliza el
formulario, los valores que se le presentan son los que corresponden a la
compaa con la que est trabajando el usuario.

Hay que tener claro, sin embargo, que cada compaa (incluida la compaa
madre) debe ser convenientemente configurada. La figura 2 muestra la vista del
formulario de la compaa madre (inicialmente llamada Your compaero ) una
vez configurada con los datos del IOC.

Aparte de los datos que muestra la figura 2 , hay que tener en cuenta:
Aparte de los datos que muestra la figura 2 , hay que tener en cuenta:

La pestaa Configuracin del formulario, que permite configurar la moneda

base de la compaa ( en nuestro caso)
El botn Set Bank Accounts que nos remite a un formulario donde podemos
dar de alta las cuentas bancarias de nuestra compaa.

Fijmonos que el campo Pro-Vin-cia est vaco. Si pulsamos la lupa que la

acompaa, podremos constatar que nuestra empresa no contiene las provincias
de Espaa de la misma manera que tampoco contiene muchos de los datos
necesarios para la gestin de una empresa espaola. Podemos ir incorporando los
datos a medida que las necesitamos, pero no es una prctica aconsejable. Los
grupos de trabajo de OpenERP los diversos pases han desarrollado mdulos de
localizacin especficos de cada pas que incorporan la mayora de datos
especficos bsicas para la gestin de empresas. Por tanto, tendremos que instalar
el mdulo de localizacin espaola. De momento, dejamos el campo provincia en
blanco.

Figura 2.24. Ejemplo de configuracin de los datos de

una compaa de la empresa

El botn de previsualizacin Header nos permite generar un informe que

muestra cmo se visualizar la informacin introducida en los diversos
documentos que genere OpenERP. Si lo ejecute puede observar que la cabecera (
figura 2 ) y el pie ( figura 2 ) muestran la informacin introducida en el
formulario acompaada de unos ttulos en lengua inglesa que no han sido
traducidos al idioma activo (cataln). Un usuario que tenga activada la casilla
Usability | Extended view de la pestaa Permisos de acceso de su ficha ( figura 2
), tiene acceso a modificar la plantilla (cabecera y pie) de los informes.

Figura 2.25. Ejemplo de la cabecera de la documentacin

generada por OpenERP
 generada por OpenERP

Figura 2.26. Ejemplo del pie de la documentacin

generada por OpenERP

2.7.10.Instalacindemdulos
El OpenERP, una vez instalado, presenta una funcionalidad muy limitada, ya que
nicamente facilita la posibilidad de introducir los socios de negocios y con una
funcionalidad muy bsica (por ejemplo, obliga a que un contacto de socio de
negocios tenga una direccin en concreto y no permite vincular un contacto a
varias direcciones o una direccin a varios contactos).

La funcionalidad tan limitada de OpenERP en la instalacin es causada por el

hecho de que este ERP es totalmente modular y espera que cada organizacin
instale nicamente las funcionalidades (mdulos) requeridas, para evitar tener un
ERP con muchas opciones no utilizadas.

Cuando hablamos de mdulos instalables, debemos distinguir:

Mdulos oficiales que facilita OpenERP y que el proceso de instalacin deja

en el sistema de archivos de la mquina donde se ha instalado el servidor
OpenERP. Entre estos hay que diferenciar los mdulos que corresponden a
aplicaciones enteras.
Mdulos no oficiales, desarrollados por la comunidad OpenERP y que
podemos descargarnos de la web. En este caso, para hacerlos instalables
habr dejarlos en la misma ubicacin donde residen los mdulos oficiales
suministrados por OpenERP y ejecutar un pequeo proceso que los aada a
la lista de mdulos instalables.
Mdulos diseados por nosotros y que vamos a instalar de la misma manera
que los mdulos no oficiales descargados de la web.

Instalacindemdulosoficiales
Para ejemplificar la instalacin de un mdulo oficial, instalaremos el mdulo
base_contact para aumentar la funcionalidad a nivel de los contactos de nuestros
socios de negocios.

Entra en la ficha de cualquier cliente o proveedor y observe la pestaa General

que incluye los diversos contactos del socio de negocios con la direccin postal de
cada contacto. La figura 2 muestra, por el cliente Agrolait , los datos del contacto
Silvie lite (direccin postal, telfono, mvil, fax, etc). La misma pestaa nos
informa que estamos visualizando el primero de un total de tres contactos que
tenemos para este cliente.

Supongamos que por el tipo de negocio de nuestra organizacin es bastante

comn que una misma persona pueda ser contacto de varios socios de negocios.
comn que una misma persona pueda ser contacto de varios socios de negocios.
En esta situacin, deberamos dar de alta la misma persona como contacto en
diferentes socios y no tendramos manera de, dada una persona de alta,
introducir sus datos personales (nicas) y sus datos profesionales (diferentes para
cada socio de negocio).

El mdulo base_contact independiza la definicin de los contactos de la

definicin de los socios de negocio, de manera que, una vez instalado el mdulo,
dispondremos de una opcin de men para dar de alta los contactos, con sus
datos personales (nicas ) y podremos asignar a uno oa varios socios de negocios,
indicando los datos especficos del contacto para cada socio.

Figura 2.27. Formulario Clientes en su estado inicial, en

el que cada contacto slo puede tener una direccin

Ejemplo de la utilidad de la instalacin del mdulo

base_contact

Supongamos que el Sr.. Pepe Gotera es un asesor de empresas y presta sus

servicios de asesora a la empresa Agrolait ya la empresa Axelor. Supongamos que
disponemos de datos personales del Sr.. Pepe Gotera (foto, telfono, mvil) y
tambin disponemos de datos especficos cuando acta como asesor de cada
empresa. OpenERP en su estado inicial no nos permite introducir los datos
personales del Sr.. Pepe Gotera, deberamos dar de alta el Sr. Pepe Gotera de cada
una de las dos empresas y no tendramos manera de saber que el mismo Sr.. Pepe
Gotera es contacto de varios socios de negocios. La instalacin del mdulo
base_contact nos solucionar el problema.

Antes de instalar-lo, damos acceso al mdulo de ventas en su estado inicial al

usuario admin , lo que conseguimos asignando el valor User o Manager en el
campo Application | Sales Management de la pestaa Permisos de acceso de su
ficha, accesible desde Configuracin | Usuarios | Usuarios . Una vez activada
esta opcin, si refrescamos el men, observaremos la aparicin del men Ventas
con algunas opciones. Hemos activado esta opcin para constatar que la
instalacin del mdulo base_contact provocar la aparicin de ms opciones en
este men.
Para instalar un mdulo de OpenERP, el usuario admin dispone de la opcin
Configuracin | Mdulos | Mdulos , que facilita la lista de todos los mdulos
instalables. La figura 2 muestra la lista que aparece al ejecutar esta opcin.
Podemos observar los botones Apps y Extra , con el primero de ellos seleccionado.
Ntese que en esta situacin, la lista contiene 19 mdulos. Si desmarcamos el
botn Apps y seleccionamos el botn Extra , el contenido de la lista de mdulos
cambia y pasamos a tener 184 mdulos distintos de los 19 anteriores. Si
seleccionamos ambos botones de la lista de mdulos incorpora 203 mdulos.

Recuerde que al entrar con el cliente web, OpenERP nos muestra una pantalla
inicial con una lista de mdulos a instalar. Tenga en cuenta que esa lista contiene
19 mdulos, que se corresponden con los mdulos Apps de la lista de mdulos
instalables.

Figura 2.28. Lista de mdulos Apps oficiales de OpenERP

6.1

OpenERP clasifica los mdulos oficiales (203 en la versin 6.1) entre Apps ,
correspondientes a mdulos que por s solos pueden considerarse como
aplicaciones (gestin de ventas, gestin de compras, CRM, MRP, recursos
humanos ...) y Extra , correspondientes mdulos que aaden funcionalidades
extras.

El mdulo base_-con-tacto es un mdulo extra. Nos situamos encima y por

instalar-lo que tenemos dos posibilidades:

1. Con vista de lista hay que utilizar el botn Install que hay en la columna de
ms a la derecha.
2. Con vista de formulario se debe pulsar el botn Install .
La vista formulario nos facilita informacin que puede ser de nuestro inters:

En la pestaa Mdulo : informacin sobre las funcionalidades que facilita el

mdulo que queremos instalar y las implicaciones en los datos ya existentes.
En la pestaa Dependencias : la lista de mdulos de los que depende y su
estado de instalacin.
 estado de instalacin.

En el caso del mdulo base_contact , observamos que depende de dos mdulos:

1. Mdulo base , ya instalado.

2. Mdulo pro-ce , no instalado.
El hecho de que haya mdulos no instalados no debe preocuparse, ya que si
ponemos en marcha la instalacin, OpenERP encargar de instalar los.

Figura 2.29. Pantalla que informa de

los mdulos a instalar o actualizar
cuando se instala un mdulo

Pulsando el botn Install para nuestro mdulo aparece la pantalla de la figura 2 ,

que nos informa de todos los mdulos que se instalarn o actualizarn. Vemos el
mdulo que queremos instalar ( base_contact ), el mdulo dependiendo process y
otros mdulos que alguna dependencia deben tener pero que no nos ha sido
informada en el mdulo base_contact ni en el mdulo process . La pantalla nos
informa que la actualizacin puede tardar algunos minutos y nos facilita dos
botones:

1. Actu-a-liza : para ejecutar la actualizacin.

2. Cancelar : para cancelar la actualizacin.
En estos momentos podramos proceder a Actualizar , pero en otras ocasiones
nos interesar Cancelar la accin porque quizs queremos instalar ms mdulos y
queremos que la actualizacin (que puede necesitar alterar la estructura de tablas
en la base de datos y ejecutar procesos de reforma de datos) se efecte en un solo
proceso para minimizar el tiempo de ejecucin. Tambin es posible que queramos
Cancelar la accin porque, verdaderamente, queremos no llevar a cabo la
instalacin que habamos iniciado. De momento, empezamos con Cancelar.

Una vez cancelada la actualizacin, todos los mdulos que haban sido
seleccionados para ser instalado o actualizados continan en estado de ser
instalados o actualizados, lo que se puede observar en la columna Estado de la
lista de mdulos.
Si la cancelacin es motivada porque, verdaderamente, queremos olvidarnos de la
instalacin, hay que ir a los mdulos que han quedado con la marca Para ser
instalado , entrar en la vista formulario y pulsar el botn Cancelar instalacin .

Si la cancelacin ha sido motivada porque queremos ejecutar la actualizacin ms

tarde, necesitamos saber cmo ponerla en marcha en el momento que nos
convenga. Para conseguirlo, hay que dar ms permisos al usuario admin ya que, a
pesar de ser administrador, tal como lo configura el proceso de instalacin de
OpenERP, no tiene acceso a esta opcin.

Para que el usuario admin pueda poner en marcha el proceso de actualizacin de

mdulos cuando lo crea conveniente, debe tener activada la casilla Usability |
Extended view de la pestaa Permisos de acceso de su ficha ( figura 2 ), accesible
desde Configuracin | Usuarios | Usuarios .

Figura 2.30. Casilla de la ficha de usuario para permitir la

visin de opciones de men no visibles normalmente

Una vez activada la casilla Extended View y despus de refrescar el men de

OpenERP, veremos como el usuario admin tiene acceso a ms opciones en el
men Configuracin . Concretamente nos interesa la opcin Configuracin |
Mens | Aplica actualizaciones programadas , que provoca la aparicin de la
pantalla de la figura 2 , que incluye todas las instalaciones y / o actualizaciones
pendientes de ejecutar y que podemos poner en marcha pulsando el botn
Actualiza . El pulsamos y esperamos a la finalizacin.

Mientras se est llevando a cabo un proceso de actualizacin no debera haber

ningn usuario conectado a la empresa que se est actualizando.

Cuando se finaliza la actualizacin, aparece la pantalla de la figura 2 , que nos

permite iniciar la configuracin automtica vinculada a los mdulos instalados
(no siempre los mdulos instalados llevan un proceso de configuracin asociado,
pero esta pantalla aparece siempre). Pulsando el botn Start configuration no
vemos nada, debido a que los mdulos instalados no llevan ningn proceso de
configuracin automtico.
configuracin automtico.

Figura 2.31. Pantalla que aparece despus de la

instalacin de mdulos y que permite iniciar el
proceso de configuracin

Una vez instalado el mdulo base_contact , refrescamos el men y observamos:

En el men Ventas hay ms opciones de las que haba antes de la instalacin.

Concretamente observamos las opciones Contactos y Direcciones .
Los contactos previos en cada socio de negocio ya no son actualizables desde
el formulario de los socios de negocios y son accesibles para la nueva opcin
Contactos .
El formulario del socios de negocios slo permite asignar contactos
previamente dados de alta por la nueva opcin Contactos .

Ejemplo de introduccin de un contacto comn a varios

terceros

Para introducir el Sr. Pepe Gotera como asesor para las empresas Agrolait y
Axelor, daremos de alta el contacto usando el formulario maestro-detalle de la
nueva opcin Contactos . En la zona de detalle damos de alta las dos empresas de
las cuales es asesor con los datos profesionales de contacto correspondientes, tal
como muestra la figura 2 .
Podemos comprobar que la informacin introducida por el formulario maestro
detalle de la opcin Contactos que facilita el mdulo base_contact , es accesible
desde el formulario de gestin de los socios de negocios. En efecto, si consultamos
los clientes Agrolait y Axelor veremos el Sr. Pepe Gotera como asesor.

Una vez conocido el proceso a seguir para instalar los mdulos, si suponemos que
nuestra organizacin compra y vende y necesita llevar la contabilidad, parece
lgico proceder a instalar los mdulos oficiales:

Sales Mana-ge-mente , para la gestin de ventas.

Purchase Management , para la gestin de compras.
Customer Relationship Management (CRM).
Accounting and Finance , para dar acceso al usuario admin al mdulo de
contabilidad, para poder administrar y dar accesos a otros usuarios.
 eInvoicing & Payments , para gestionar la facturacin electrnica y todo tipo
de pagos (cheques, tarjetas bancarias, efectivo ...).

Figura 2.32. Ejemplo de alta de contacto con varios

cargos en diferentes empresas

Tenga en cuenta que todos estos mdulos son los considerados Apps para
OpenERP. Puede, si lo desea, instalar el resto de mdulos Apps facilitados por
OpenERP.

Si proceda a instalar, como mnimo, los mdulos indicados anteriormente, si

cuando aparece la pantalla de la figura 2 pulse el botn Start Configuration se
pone en marcha un proceso de configuracin, Configuracin de la aplicacin de
contabilidad.

Para una correcta configuracin de la aplicacin de contabilidad, convendra

tener conocimientos de contabilidad.

La primera pantalla del proceso de configuracin de la aplicacin de contabilidad

( figura 2 ) nos pide:

Resumen de cuentas : nos propone Generic Chart of Accounts , pero se

trata de elegir el plan contable correspondiente al pas al que pertenece la
empresa. El plan propuesto (genrico) se utilizara en caso de no disponer del
plan de cuentas especfico para el pas. Si abrimos el desplegable, vemos que
OpenERP incorpora varios planes contables ya nosotros nos interesa escoger
el llamado Spanish Charts of Accounts (PGCE 2008) que corresponde al Plan
General Contable Espaol de 2008 (actualmente vigente).
Fechas inicial y final del ejercicio fiscal : OpenERP nos propone como
ejercicio fiscal del ao natural correspondiente a la fecha actual. La mayora
de empresas tienen como ejercicio fiscal del ao natural, pero debemos saber
que hay excepciones y, por ejemplo, para una empresa de carcter agrcola, el
ao fiscal podra ir desde el 1 de septiembre de un ao hasta el 31 de agosto
del ao siguiente.
 del ao siguiente.
Periodos : el ao fiscal se divide en perodos contables que pueden ser
meses o trimestres. Es muy usual trabajar con perodos mensuales.

Figura 2.33. Primera pantalla del proceso de

configuracin de la aplicacin de contabilidad

Una vez rellenados los campos de la pantalla de la figura 2 , procedemos a pulsar

el botn Configurar para que contine con el proceso. La siguiente pantalla que
aparece ( figura 2 ) nos permite tomar ms decisiones en cuanto a la generacin
del plan contable:

Figura 2.34. Segunda pantalla del proceso de

configuracin de la aplicacin de contabilidad

1. Nmero de dgitos a utilizar por el plan de cuentas : nos propone el

valor 6. Si pretendemos trabajar con un plan de cuentas muy detallado quizs
nos interesa trabajar con un valor ms alto (8 o 10), ya que dispondremos de
ms dgitos que nos permitirn especificar ms conceptos (un concepto = una
cuenta contable). Nosotros dejamos el valor 6.
2. Plantilla del plan contable : si desplegamos la lista de este campo vemos
que el OpenERP nos facilita dos opciones: Plantilla PGCE 2008 completo y
Plantilla PGCE 2008 PYMES . El PCGE del 2008 clasifica las cuentas
contables en 9 grupos, de los cuales los grupos 8 y 9 no son obligatorios para
las PYMES. Por este motivo se facilitan dos plantillas: PGCE completo y
PGCE para PYMES. Nosotros escogeremos el de las PYMES.
3. Impuestos de venta y de compra por defecto : hay que indicar los
impuestos de venta y de compra que ms habitualmente utiliza nuestra
empresa. Si desplegamos las listas de valores posibles, observamos que la
versin que instalamos no incorpora los nuevos tipos impositivos que entrarn
en vigor en Espaa el 1 de septiembre de 2012 (21% por el tipo normal y 10%
por el tipo reducido). Vemos los tipos impositivos vlidos hasta el 31 de agosto
de 2012 (18% y 8% respectivamente) y tambin los tipos impositivos vlidos
antes del 30 de junio de 2009 (16% y 7%). Estos ltimos no se pueden
eliminar por si el ERP contiene informacin de ejercicios fiscales anteriores.
Desde el desplegable para seleccionar el tipo de IVA tenemos la posibilidad, si
tenemos conocimientos claros de contabilidad, de definir toda la informacin
necesaria para dar respuesta a los requerimientos impositivos que entrarn en
vigor el 1 de septiembre de 2012. Pero en caso de no tener los conocimientos de
contabilidad necesarios y de no disponer de un consultor, hay que confiar que en
las prximas versiones de OpenERP ya estarn los nuevos tipos impositivos.

Si no podemos esperar, hay que tener en cuenta que all donde tiene fuerza el
OpenERP suele haber un equipo de trabajo que desarrolla mdulos especficos
para adaptar el OpenERP a las leyes ya las necesidades de la zona: son los
llamados mdulos de localizacin y, en nuestro caso, tenemos la Spanish
Localization Team que es el responsable del mdulo Spanish Charts of Accounts
(PGCE 2008) y que, a finales del mes de agosto, seguro que ya ha actualizado el
mdulo con la incorporacin de los nuevos tipos impositivos.

Tenemos tres opciones:

1. Poner a definir los nuevos tipos de impuestos. Esta opcin ya la hemos

descartado por falta de conocimientos contables e implicaciones dentro del
ERP.
2. Continuar el proceso de configuracin de la aplicacin contable, asignando
los tipos impositivos actuales (agosto de 2012) para, posteriormente,
actualizar el mdulo Spanish Charts of Accounts (PGCE 2008) con los
materiales que haya suministrado la Spanish Localization Team y, finalmente
, cambiar manualmente los tipos de IVA y las cuentas contables
correspondientes a IVA repercutido y soportado.
3. Abortar el proceso de configuracin de la aplicacin contable para actualizar
el mdulo Spanish Charts of Accounts (PGCE 2008) y, finalmente, reiniciar
el proceso de configuracin de la aplicacin contable.
En el momento actual disponemos de una versin actualizada del mdulo
Spanish Charts of Accounts y, por tanto, la opcin 3 es la ms cmoda.
Abortamos, el proceso de configuracin para proceder a la actualizacin del
mdulo Spanish Charts of Accounts (PCGE 2008) .

Hemos abortado el proceso de configuracin de la aplicacin de contabilidad,

pero los mdulos se han instalado. Si refrescamos el men, apreciamos muchas
ms opciones: Ventas , Compras , Almacn , Contabilidad y Configuracin .

Si echamos un vistazo a la lista de mdulos instalados (sea Apps o Extra ),

encontraremos el mdulo Spanish Charts of Accounts (PCGE 2008) , bajo el
nombre l10n_es . En OpenERP, todos los mdulos de localizacin tienen el prefijo
l10n_ seguido de las siglas del pas y, si es necesario, un sufijo para distinguir
varios mdulos de localizacin de un mismo pas. Si miramos la lista de mdulos
no instalados, veremos una larga lista de mdulos con el prefijo l10n_ .

Busque Internacionalizacin y Localizacin en la

Wikipedia para conocer el significado de los
prefijos numernims l10n_ y i18n_ .
Cmo podemos conseguir una versin actualizada de un mdulo? Hay dos
caminos:

1. Visitar la pgina web oficial de complementos ( add-ons ) de OpenERP (

apps. OpenERP. como ) para ver si hay la actualizacin deseada.
2. Visitar la pgina de los desarrolladores del mdulo, para ver si hay alguna
versin disponible que an no ha sido subida a la web oficial de
complementos de OpenERP. En el caso de la Spanish Localization Team , la
pgina es https:// launchpad. net / OpenERP-spain y para descargar los
mdulos se necesita la herramienta Bazaar .

Figura 2.35. Contenido del mdulo l10n_es en la pgina

de complementos de OpenERP a finales de agosto del 2012

El camino fcil y cmodo es buscar el mdulo en la web oficial de complementos

de OpenERP. As pues, buscamos el mdulo l10n_es y encontramos ( figura 2 ):

3 versiones del mdulo para la versin 6.0 de OpenERP.

1 versin del mdulo para la versin 6.1 de OpenERP, con fecha de 23-08-
2012 (actual) ubicada en el repositorio "lp: openerp-spain/6.1" (rama 6.1 del
proyecto ubicado en https:// launchpad. net / OpenERP-spain )

La pgina no muestra ninguna informacin referente a la incorporacin de los

nuevos tipos impositivos, pero el autor de estos materiales est suscrito al Google
Group OpenERP-spain donde sigue las aventuras y desventuras de los usuarios y
desarrolladores de OpenERP - Spain y, por tanto , est casi seguro de que el
mdulo l10n_es del 23-08-2012 ya incorpora los nuevos tipos impositivos.
Bajamos hacernos este mdulo e instalamos-lo.

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye el fichero
l10n_es_20120823.zip correspondiente al mdulo
que queremos actualizar.

Para actualizar un mdulo de nombre xxx instalado en el OpenERP, hay que

seguir el siguiente proceso:

1. Sustituir la carpeta xxx existente en el directorio camOnResideixOpenERP /

Server / server / OpenERP / addons para la carpeta de idntico nombre
correspondiente a la nueva versin del mdulo a actualizar.
 correspondiente a la nueva versin del mdulo a actualizar.
2. Desde cualquier cliente de OpenERP, conectado con usuario admin , ir a la
lista de mdulos instalados, situarse a actualizar con vistas de formulario y
pulsar el botn Upgrade. Aparece una ventana ( figura 2 ) que nos avisa de
que el mdulo est en situacin de ser actualizado y procedemos a ejecutar la
actualizacin.
En el caso que nos ocupa, despus de actualizar el mdulo l10n_es , nos interesa
volver a poner en marcha el proceso de configuracin de la aplicacin de
contabilidad, lo que conseguimos va la opcin Contabilidad | Configuracin |
Contabilidad financiera | Configuracin financiera para una nueva compaa
(hay que tener instalado el mdulo Accounting and Finance ). El proceso vuelve a
empezar con la pantalla de la figura 2 , que rellenamos convenientemente y
contina con la pantalla de la figura 2 , donde ya podemos asignar los tipos
impositivos del 21% como valores por defecto para las ventas y las compras, si este
es el caso. Continuamos con el proceso y la configuracin de la aplicacin
contable finaliza.

Una vez instalados los mdulos de ventas, compras, almacenamiento,

contabilidad y CRM, si hacemos una visita a la base de datos, veremos que de las
107 mesas y 86 secuencias iniciales hemos pasado a 385 mesas, 335 secuencias y
20 vistas.

Figura 2.36. Pantalla que informa de

la actualizacin de un mdulo ya
instalado

Instalacindemdulosnooficiales
Los mdulos oficiales de OpenERP que vienen incluidos en la distribucin del
ERP cubren una gran cantidad de necesidades. Pero la diversidad de normativas
entre los diferentes estados y las particularidades de funcionamiento de los
diversos sectores productivos en los que podemos utilizar el ERP provocan que los
mdulos incluidos en la distribucin del ERP no sean suficientes y, en
consecuencia, la comunidad de OpenERP va produciendo mdulos que nos
pueden ser tiles.

La pgina web oficial de complementos ( add-ons ) de OpenERP ( apps.

OpenERP. como ) es el lugar donde tenemos que ir, inicialmente, a buscar los
mdulos. Si no lo encontramos o estamos buscando una versin beta, podemos ir
a la plataforma de software colaborativo que utilizan los desarrolladores de la
comunidad OpenERP.

La comunidad de desarrolladores de OpenERP

suele tener varios proyectos abiertos a la
plataforma de software colaborativo launchpad (
launchpad. neto ), desde donde tambin podemos
descargarnos mdulos con la herramienta Bazaar.

Los primeros mdulos no oficiales que nos pueden interesar de instalar en un

OpenERP que se utilice en el Estado espaol, son aquellos que nos faciliten una
mejor gestin diaria del ERP y que generen la documentacin necesaria segn la
normativa vigente . Segn esto, nos interesara disponer de:

Mdulo que introdujera las provincias de Espaa y alguna funcionalidad a

nivel de cdigos postales y municipios.
Mdulo (s) que permitieran generar las diversas declaraciones para la
Agencia Tributaria.

La implantacin de OpenERP en Espaa es importante y esto ha provocado que

muchas de las empresas implantadoras hayan desarrollado mdulos de
localizacin que dan solucin a las necesidades presentadas. Como ejemplo
podemos instalar un mdulo que introduzca las provincias de Espaa junto con
los municipios y los cdigos postales ( l10n_es_toponyms ) desarrollado por
Zikzakmedia, SL

Localizamos el mdulo l10n_es_toponyms en la pgina web oficial de

componentes de OpenERP y nos descargamos la versin correspondiente a la
versin 6.1 de OpenERP.

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye una versin del
archivo l10n_es_toponyms.zip correspondiente al
mdulo Topnimos de Espaa que queremos
actualizar.

Para incorporar un mdulo de nombre xxx a un servidor OpenERP e instalar, es

necesario seguir el siguiente proceso:

1. Aadir la carpeta xxx contenedora del nuevo mdulo, en el directorio

camOnResideixOpenERP / Server / server / OpenERP / addons . Se puede
dejar el archivo . zip descargado, pero nunca pueden coexistir un archivo .
zip y una carpeta de igual nombre.
2. Desde cualquier cliente, conectado como usuario admin , ejecutar la opcin
Configuracin | Mdulos | Actualizar lista de mdulos , con el que
conseguimos incorporar el nuevo mdulo de la lista de mdulos instalables
del servidor OpenERP.
 3. Ejecutar el proceso de instalacin como cualquiera de los mdulos que
incorpora OpenERP.
Procedemos, siguiendo estos pasos, la instalacin del mdulo Topnimos de
Espaa . Fijmonos en la informacin que acompaa al mdulo:

Traduce el nombre de pas Spain por Espaa.

Aade las 52 provincias actuales de Espaa con posibilidad de elegir la
versin oficial de los nombres, la castellana o ambas (Lleida, Girona, etc).
Proporciona un asistente (hay que ejecutar manualmente despus de la
instalacin) para dar de alta a los municipios y provincias por defecto
asociados a los 15.839 cdigos postales de Espaa.
Permite rellenar automticamente los campos ciudad y provincia de los
contactos en el formulario de socios de negocios a partir del cdigo postal.
Los datos han sido obtenidos de los datos pblicos del Instituto Nacional de
Estadstica (INE).

Al finalizar la instalacin, siguiendo la informacin del mdulo, hay un proceso

de configuracin que no se ejecuta automticamente. Para ello vamos a
Configuracin | Configuracin | Asistentes de configuracin | Asistentes de
configuracin y escogeremos Configuracin de los topnimos de Espaa . El
ejecutamos con las opciones por defecto que nos propone.

El proceso de configuracin de los topnimos de Espaa es un proceso que se

ejecuta en segundo plano y que, como bien avisa, puede tardar bastante tiempo.
Como es en segundo plano, la manera de saber que ha finalizado es cuando en la
lista de los asistentes de configuracin aparece con el estado de realizado .
Mientras se est ejecutando, el OpenERP se puede utilizar, pero no apreciaremos
la existencia de las provincias ni del rellenado automtico de los campos ciudad y
provincia en los formularios indicados hasta que el asistente haya finalizado.

Una vez finalizado, podemos comprobar su utilidad:

Al configurar los datos de nuestra empresa (IOC) no habamos asignado la

provincia para que no las tenamos introducidas. Ahora ya podremos
asignarla.
Cuando se introduce el cdigo postal en el formulario de socios de negocios,
se facilita automticamente el municipio y la provincia (que se pueden
modificar). Hay que tener cuidado con posibles errores en municipios muy
pequeos que comparten un mismo cdigo postal.

2.7.11.Gestindelaseguridadenunaempresa:usuariosygruposdeprivilegios
El proceso de creacin de una empresa de OpenERP genera un usuario
administrador, de nombre admin , con una contrasea obligatoria en el momento
de creacin de la empresa. El administrador tiene todos los privilegios sobre la
empresa y puede crear usuarios, grupos de privilegios sobre los objetos de la
empresa (terceros, productos, pedidos, albaranes, facturas ...) y asignar usuarios a
los diversos grupos de privilegios.

Si la empresa incorpora datos de demostracin, se genera tambin el usuario de

nombre demo y contrasea demo y, en este caso, la instalacin del mdulo
nombre demo y contrasea demo y, en este caso, la instalacin del mdulo
Recursos Humanos (hr) incorpora una serie de empleados que, a la vez, son
usuarios de la empresa de OpenERP (pueden abrir una conexin).

Figura 2.37. Formulario para gestionar un usuario de

OpenERP

Abra sesin en una empresa con datos de demostracin y con el mdulo Recursos
Humanos (hr) instalado. Vaya a Configuracin | Usuarios | Usuarios. Obsrvese
que adems del usuario Administrador y el usuario Demo User , hay una serie de
usuarios. Consulte su cualquiera de ellos. Ver que su ficha contiene una cabecera
con su nombre real, el nombre de usuario para establecer conexin y un espacio
para asignarle una nueva contrasea y tres pestaas ( Usuario , Permisos de
acceso y Compaas permitidas ) como muestra la figura 2 .

La pestaa Usuarios contiene campos para introducir informacin diversa, como

el idioma, la zona horaria, la compaa de trabajo por defecto, el departamento,
la accin inicial que se debe ejecutar cuando el usuario abre sesin en OpenERP y
el correo electrnico.

La pestaa Compaas permitidas por donde se puede asignar, en una

instalacin multicompanyia, las compaas que el usuario puede manejar.

La pestaa Permisos de acceso , visible en la figura 2 , contiene tres apartados:

Application , Usability y Otro . El apartado Usability contiene un conjunto de
casillas de verificacin para facilitar al usuario diversas funcionalidades. El
apartado Application muestra, por cada uno de los mdulos app de OpenERP
instalados en la empresa, un apartado con una lista desplegable con varias
posibilidades, especficas de cada app . As, la figura 2 muestra las aplicaciones
Sales Management, Project Management, Warehouse Management, Accounting
& Finance, Purchase Management, Human Resources y Administracin , que
corresponden a seis mdulos app instalados ms el apartado Administracin (
Configuracin ) para administrar el OpenERP . Cada uno de estos apartados
contiene unos determinados conjuntos de permisos, llamados grupos de
privilegios, de los que tendremos que asignar alguno al usuario que haya de poder
utilizar el mdulo.

Normalmente, cada mdulo de OpenERP incorpora la definicin de un entorno

de seguridad bsico que incluye la definicin de la aplicacin y sus grupos de
privilegios (uno como mnimo). Cuando se instala el mdulo, su entorno de
seguridad queda instalado en la empresa y se visualiza en el apartado Application
de la pestaa Permisos de acceso .

Figura 2.38. Lista de grupos de privilegios de una

empresa de OpenERP

El apartado Otro de la pestaa Permisos de acceso , engloba grupos de privilegios

que se pueden definir sin asignarlos a una aplicacin en concreto.

La definicin del entorno de seguridad se puede consultar y / o modificar y / o

ampliar por la opcin Configuracin | Usuarios | Grupos , que facilita la lista de
todas las aplicaciones con sus grupos de privilegios, como muestra la figura 2 . La
nomenclatura utilizada ( Applicaci | Grupo de privilegios ) permite distinguir,
con rapidez, los diversos grupos de privilegios de cada aplicacin.

Si selecciona cualquiera de los grupos de privilegios definidos abrir un

formulario como el de la figura 2 que contiene varias pestaas, para las cuales
podemos consultar y / o gestionar, entre otros:

Los usuarios que tienen concedido el grupo de privilegios.

Los grupos de privilegios que se heredan en caso de tener asignado el grupo
actual.
Mens a los que da acceso el hecho de tener asignado el grupo actual.
Conjunto de permisos de acceso (lectura, escritura, creacin y eliminacin)
sobre cada uno de los objetos definidos en el mdulo.
Figura 2.39. Formulario de consulta / gestin de grupos
de privilegios de OpenERP
La modificacin de los grupos de privilegios existentes y la creacin de nuevos
grupos de privilegios es tarea destinada a experimentados administradores de
OpenERP.

2.8.InstalacindeOpenERPenLinux

La instalacin de OpenERP en el sistema operativo Linux no es difcil, una vez

conocemos el proceso de instalacin y configuracin de un servidor OpenERP en
el sistema operativo Windows y sabemos movernos en un SGBD PostgreSQL,
aunque que tiene sus puntos delicados. Hay que tener unas buenas nociones del
sistema operativo Linux.

Podemos encarar la instalacin de un servidor OpenERP en un sistema Linux de

varias maneras:

1. Instalando el (los) paquete (s) correspondientes al servidor OpenERP que

suministra, en su caso, la distribucin de Linux que tengamos instalada.
2. Instalando el (los) paquete (s) especficos suministrados por OpenERP en su
web de descargas, en caso de que correspondan a la distribucin de Linux
que tengamos instalada.
3. Instalando los cdigos fuente suministrados por OpenERP.
Llevaremos a la prctica las diversas instalaciones en el sistema operativo Linux
Ubuntu 12.04 LTS ( Long Term Soporte ) aunque la instalacin de los paquetes
suministrados por la distribucin de Linux Ubuntu 4.12 LTS puede ser
ligeramente diferente a la que efectuaremos aqu, basada en el paquete para
Ubuntu suministrado por OpenERP (versin 6.1-YYYYMMDD).

2.8.12.InstalacinUbuntuatravsdepaquetes
El sistema operativo Linux Ubuntu incorpora, desde la versin 9.04, la instalacin
optativa de un servidor OpenERP. La tabla 2 muestra, por las diversas versiones
de Ubuntu, la versin de servidor de OpenERP incorporada.
 Tabla 2.4. Versiones de servidor OpenERP
incorporado en las distribuciones de Ubuntu
Versin Ubuntu Versin OpenERP
09:04 Jaunty Jakalope 5.0.0
09:10 Karmic Koala 5.0.5
4.10 LTS Lucid Lynx 5.0.6
10:10 Maverick Meerkat 5.0.14
11:10 Oneiric Ocelot 5.0.15
4.12 LTS Precise Pangolin 6.1.1 (Octubre de 2012)

El proceso de instalacin de un servidor OpenERP a partir de los paquetes

suministrados por la distribucin de Ubuntu puede diferir segn la versin. As,
por ejemplo, el centro de software de la versin 4.12 de Ubuntu, en el mes de
octubre de 2012, facilita dos versiones de OpenERP, como muestra la figura 2 .

La instalacin de la versin openerp6.1-core est pensada para una instalacin

del servidor OpenERP que no incorpore la instalacin de un servidor PostgreSQL.
En cambio, la versin openerp6.1-hoja corresponde a la instalacin conjunta de
un servidor OpenERP y un servidor PostgreSQL.

Figura 2.40. Versiones de servidor de OpenERP

suministradas por Ubuntu 4.12 LTS

OpenERP, en su pgina de descargas, facilita el paquete de instalacin para

Debian / Ubuntu, bajo el nombre openerp_6.1-latest-1_all.deb . Instalamos una
versin concreta para Debian (versin 6.1-YYYYMMDD-RELEASE). Si proceda a
descargar la ltima versin de ambos productos e inicie la instalacin, ver que
hay una versin ms nueva.

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye una versin
concreta para Debian / Ubuntu.

El paquete suministrado por OpenERP, a pesar de llevar el sufijo _all , contiene

nicamente el servidor OpenERP y la tendremos que configurar para trabajar con
un servidor PostgreSQL existente (puede instalar un servidor PostgreSQL en la
mquina Ubuntu o conectar con un servidor PostgreSQL instalado instalado en
otra mquina).

Una vez instalado el servidor OpenERP, comprobamos:

Una vez instalado el servidor OpenERP, comprobamos:

En la carpeta / etc / init.d donde residen los guiones para gestionar los
servicios, ha aparecido el guin OpenERP . Si lo ejecutamos sin indicar
ninguna opcin, nos informa de las posibles opciones de gestin:

root @ Ubuntu :/ etc / init.d #. / OpenERP

Usage: OpenERP-server {start | stop | restart | force-reload}

Observamos si hay algn proceso con nombre OpenERP en marcha, lo que

podemos conseguir con la instruccin:

root @ Ubuntu :/ etc / init.d # ps aux | grep OpenERP

Fijmonos en que aparece una lnea con un contenido similar a:

/ Usr / bin / python / usr / bin / OpenERP-server

- Config = / etc / OpenERP / OpenERP-server.conf
- Logfile = / var / log / OpenERP-server.log

La lnea anterior nos dice que hay un programa Python en ejecucin.

Concretamente:

Ejecucin del programa / usr / bin / OpenERP-server

Usar la configuracin del fichero / etc / OpenERP / OpenERP-
server.conf
Registrar las incidencias en el fichero / var / log / OpenERP-
server.log

Observamos que tenemos el servidor Ubuntu escuchando los puertos

habituales de OpenERP (8069 por el protocolo XML - RPC y 8070 por el
protocolo NET- RPC ):

root @ Ubuntu :/ home / alumno # netstat-ano | more

Active Internet connections (servers and established)
Proto rec-Q Send-Q Local Address Foreign Address State Timer
...
tcp 0 0 0.0.0.0:8069 0.0.0.0: * LISTEN off (0.00/0/0)
tcp 0 0 0.0.0.0:8070 0.0.0.0: * LISTEN off (0.00/0/0)
...

Si intentamos la conexin desde un cliente web o GTK, observaremos que

aparecen mensajes de errores evidentes ya que no tenemos el servidor
OpenERP conectado con un servidor PostgreSQL. El servidor OpenERP que
hemos instalado intenta conectar con un servidor PostgreSQL en la misma
mquina.

Necesitamos configurar adecuadamente el servidor OpenERP instalado,

indicndole el servidor PostgreSQL con el que se ha de conectar y el usuario-
contrasea correspondientes. Para ello, seguiremos los siguientes pasos:

1. Paremos el servidor OpenERP encendido y que queremos reconfigurar:

root @ Ubuntu :/ etc / init.d #. / OpenERP stop

 root @ Ubuntu :/ etc / init.d #. / OpenERP stop
Stopping OpenERP-server: OpenERP-server.

Podemos asegurarnos de que se ha detenido comprobando que ya no hay ningn

proceso que contenga el nombre OpenERP encendido.

2. Editamos el fichero de configuracin / etc / OpenERP / OpenERP-server. conf.

Su contenido es similar al de la versin para el SO Windows:

[Options]
; This is the password that allows database operations:
; Admin_passwd = admin
db_host = False
db_port = False
db_user = OpenERP
db_password = False

Nuestro conocimiento del servidor OpenERP en SO Windows nos lleva a intuir

que debemos modificar el contenido con:

[Options]
; This is the password that allows database operations:
admin_passwd = ContrasenyaPerUsuariAdminDeOpenERP
db_host = MaquinaOnResideixServidorPostgreSQL
db_port = PortPerOnEscoltaServidorPosrgreSQL
db_user = UsuariDePostgreSQL
db_password = ContrasenyaDelUsuariDePostgreSQL

Cambie los parmetros para conectar con cualquiera de los servidores PostgreSQL
que tenga instalados (sean en sistema Linux o en sistema Windows). Recuerde
que el usuario que utiliza OpenERP para conectar con PostgreSQL debe tener el
rol Puede crear bases de datos .

3. Arrancamos de nuevo el servidor OpenERP:

root @ Ubuntu :/ etc / init.d #. / OpenERP-server start

Starting OpenERP-server: OpenERP-server.

Recordemos que la orden ps aux | grep OpenERPnos permite ver si tenemos

algn proceso iniciado que contenga el nombre OpenERP . Es recomendable
tambin echar un vistazo al fichero log donde queda constancia de si el arranque
es correcta o detecta algn problema. Hay que tener presente que el servicio
puede quedar encendido pero con errores que no permitan la utilizacin de
OpenERP.

4. Comprobamos la conexin con los clientes web y GTK (desde SO Windows).

En cuanto al cliente GTK para Linux hay que tener en cuenta que:

La distribucin 4.12 LTS de Ubuntu no facilita ningn paquete de instalacin

para el cliente GTK.
La web de descarga de OpenERP no facilita ningn paquete de instalacin
del cliente GTK para la versin 6.1 (mientras que s existe para OpenERP 6.0),
pero s que facilita los cdigos fuente del cliente GTK.
En consecuencia, la nica manera de tener un cliente GTK en Linux para
OpenERP 6.1 es instalar a partir de los cdigos fuente.

2.8.13.InstalacinUbuntuatravsdecdigosfuente
OpenERP facilita en la web de descarga el cdigo fuente para el servidor
OpenERP y para el cliente GTK. Veremos, a continuacin, cmo proceder para
lograr la instalacin, Ubuntu 4.12 LTS, de un servidor OpenERP 6.1 y de un
cliente GTK.

En los anexos de la web encontrar el apartado

"Recursos de software" que incluye una versin de
los cdigos fuente del servidor OpenERP 6.1 y del
cliente GTK, para ser instalados en cualquier
sistema operativo.

InstalacindelservidorOpenERP
Para instalar un servidor OpenERP a partir de los cdigos fuente descargados de
la web de descarga de OpenERP (archivo de nombre similar a OpenERP-6. 1-
YYYYMMDD-RELEASE. Tar. Gz) seguimos el siguiente proceso:

1. Descomprimimos el contenido del archivo, normalmente en la carpeta opt del

servidor Linux:

root :/ opt # tar-xzf OpenERP-6.1-YYYYMMDD-RELEASE.tar.gz

root :/ opt # ls
OpenERP-6.1-YYYYMMDD-RELEASE
root :/ opt #

2. En el directorio / opt/openerp-6.1-YYYYMMDD-RELEASE/install
encontramos el fichero OpenERP-server. conf que tendremos que retocar
convenientemente. En la versin 6.1.1 de OpenERP el contenido es similar al de la
versin para el SO Windows:

[Options]
; This is the password that allows database operations:
; Admin_passwd = admin
db_host = False
db_port = False
db_user = OpenERP
db_password = False

Nuestro conocimiento del servidor OpenERP en SO Windows nos lleva a intuir

que debemos modificar el contenido con:

[Options]
; This is the password that allows database operations:
admin_passwd = ContrasenyaPerUsuariAdminDeOpenERP
db_host = MaquinaOnResideixServidorPostgreSQL
db_port = PortPerOnEscoltaServidorPosrgreSQL
db_user = UsuariDePostgreSQL
db_password = ContrasenyaDelUsuariDePostgreSQL
Cambie los parmetros para conectar con cualquiera de los servidores PostgreSQL
que tenga instalados (sean en sistema Linux o en sistema Windows). Recuerde
que el usuario que utiliza OpenERP para conectar con PostgreSQL debe tener el
rol Puede crear bases de datos .

3. En el directorio / opt/openerp-6.1-YYYYMMDD-RELEASE encontramos el

archivo README que contiene varias instrucciones. En particular, nos interesa la
parte final, referente a los requisitos de sistema, que detalla los paquetes que
necesitamos tener instalados en el servidor Linux para el correcto funcionamiento
del servidor OpenERP. Necesitamos, pues, efectuar la instalacin de todos los
paquetes:

apt-get install paquet1 paquet2 paquet3 ...

4. En el directorio / opt/openerp-6.1-YYYYMMDD-RELEASE encontramos el

ejecutable OpenERP-server que es el programa para poner en marcha el servidor.
La ejecucin de este programa, acompaado de la opcin -help, nos informa de
las diversas posibilidades que facilita. Nos interesa conocer la opcin -cpara
indicar el nombre de archivo de configuracin que incluye los datos de
conectividad con el servidor PostgreSQL y la contrasea del usuario
administrador del servidor OpenERP. As, para poner el servidor en marcha,
podemos ejecutar (como usuario administrador diferente del usuario root ) y
desde la carpeta raz donde hemos instalado el software:

. / OpenERP-server-c. / Install / OpenERP-server.conf

El servidor muestra unas lneas similares a:

INFO? OpenERP: OpenERP version 6.1-YYYYMMDD-RELEASE

INFO? OpenERP: addons paths: / opt/openerp-6.1-YYYYMMDD-RELEASE/openerp/addons
INFO? OpenERP: database hostname: 10200190207
INFO? OpenERP: database puerto: 5432
INFO? OpenERP: database user: pepito
INFO? openerp.service.netrpc_server: starting NET-RPC service donde 0.0.0.0:8070
INFO? openerp.netsvc: Starting 1 services
INFO? openerp.addons.web: embedded modo
INFO? openerp.wsgi.core: HTTP service (werkzeug) running on 0.0.0.0:8069
INFO? OpenERP: OpenERP server is running, waiting for connections ...

Fijmonos en la ltima lnea que informa que el servidor OpenERP est en

ejecucin y est esperando conexiones. Para detener la ejecucin del proceso
podemos ejecutar la combinacin de teclas CTRL + C. La terminal donde hemos
puesto en marcha el servidor queda ocupada hasta la finalizacin.

Si se quiere poner en marcha el servidor OpenERP en segundo plano,

escribiremos:

. / OpenERP-server-c. / Install / OpenERP-server.conf &

En este caso aparecen las mismas lneas informativas y parece que el proceso
quede esperando, pero pulsando return aparece parece el prompt del sistema.
quede esperando, pero pulsando return aparece parece el prompt del sistema.

5. Comprobamos la conexin con los clientes web y GTK (desde el SO Windows).

Para entornos de produccin es aconsejable disponer de un guin que permita

poner en marcha, detener y reiniciar el servidor OpenERP con comodidad, guin
que debe residir dentro / etc / init.d .

Edicin de guiones
La edicin de guiones para gestionar los servicios y
la instalacin de estos guiones de forma que la
puesta en marcha y parada de los servicios sea
automtica es tarea de los administradores del
sistema operativo.

InstalacindelclienteGTK
Para instalar un cliente GTK a partir de los cdigos fuente descargados de la web
de descarga de OpenERP (archivo de nombre similar a OpenERP-cliente-6. 1-
YYYYMMDD-RELEASE. Tar. Gz), seguimos el siguiente proceso :

1. Descomprimimos el contenido del archivo, normalmente en la carpeta opt del

servidor Linux:

root :/ opt # tar-xzf OpenERP-cliente-6.1-YYYYMMDD-RELEASE.tar.gz

root :/ opt # ls
OpenERP-6.1-YYYYMMDD-RELEASE
OpenERP-cliente-6.1-YYYYMMDD-RELEASE

2. En el directorio / opt/openerp-client-6.1-YYYYMMDD-RELEASE/bin
encontramos el programa Python OpenERP-cliente. py que es el programa a
ejecutar para poner en marcha el cliente GTK. El paquete de fuentes del cliente
GTK no facilita informacin sobre los requerimientos de paquetes a tener
instalados en el servidor Linux. La instalacin de los paquetes indicados en la
instalacin del servidor OpenERP es suficiente para la correcta ejecucin del
cliente GTK.

3. Comprobamos que el cliente GTK funciona para conectarse con cualquier

servidor OpenERP, ya sea sobre un servidor de Windows como sobre un servidor
de Linux.