FP Dam m10 Material Paper

Informàtica i comunicacions
Sistemes de gestió
empresarial
CFGS.DAM.M10/0.13
Desenvolupament d’aplicacions multiplataforma
Generalitat de Catalunya
Departament d’Ensenyament
Aquesta col·lecció ha estat dissenyada i coordinada des de l’Institut Obert de Catalunya.
Coordinació de continguts
Joan Carles Pérez Vázquez
Redacció de continguts
Isidre Guixà Miranda
Primera edició: Setembre 2013

© Departament d’Ensenyament
Dipòsit legal: B. 15218-2013
Llicenciat Creative Commons BY-NC-SA. (Reconeixement-No comercial-Compartir amb la mateixa llicència 3.0 Espanya).
Podeu veure el text legal complet a
http://creativecommons.org/licenses/by-nc-sa/3.0/es/legalcode.ca
Desenvolupament d’aplicacions multiplataforma 5 Sistemes de gestió empresarial
Introducció
Avui dia molta part de la competitivitat d’una empresa passa per tenir optimitzats i
integrats els seus fluxos/processos interns i les seves relacions comercials externes,
per aconseguir objectius bàsics com son les millores de la productivitat, la qualitat,
el servei al client i la reducció de costos. Les organitzacions necessiten integració
interna i col·laboració externa per augmentar les oportunitats de sobreviure en un
mercat global, cada cop més competitiu.
Aquesta és la raó de la cerca d’un sistema que permeti assolir totes les necessitats
del negoci, des de el control de les operacions financeres i la generació d’informes,
les relacions i vendes amb els clients, la planificació i programació de la producció,
fins al control d’inventari i costos. En l’actualitat, les organitzacions busquen
implementar sistemes que els permeti controlar totes les àrea del negoci, de
forma integral. Així, amb un sistema integrat, tota l’empresa, els seus sistemes
i processos, es centralitzen i integren per al benefici de tota l’organització.
Com a conseqüència de tot aquest sistema integrat l’organització ha de veure com
es generaren millors resultats, sempre que s’implanti el programari adequadament,
oferint com a benefici el control i la monitorització de les operacions, l’eficiència
administrativa, una productivitat més adequada, un servei al client més eficient,
estalvi de costos i recolzament més fiable per a la pressa de decisions.
En aquest sentit, els sistemes ERP, de l’anglès Enterprise Resource Planning,
coneguts àmpliament com a sistemes de planificació de recursos empresarials o
sistemes de gestió empresarial, són sistemes que integren o pretenen integrar totes
les dades i processos d’una organització en un sistema unificat.
Aquest mòdul té com a finalitat inicial l’aproximació conceptual al món dels
sistemes de gestió empresarial i la seva implantació a l’empresa.
Al començament de la unitat “Sistemes ERP. Implantació”, i des de un punt
de vista teòric, s’examinen els diferents tipus de llicenciament de programaris
ERP-CRM i els diferents tipus de desplegament de programari. També es veurà
què són els sistemes ERP-CRM i les solucions BI i s’identifiquen els principals
productes existents en l’actualitat. D’altra banda, s’identifiquen els punts a tenir
en compte en la implantació tècnica d’un sistema ERP-CRM. A continuació es fa
la instal·lació i configuració d’un ERP-CRM, en concret el programari OpenERP.
L’altra gran finalitat d’aquest mòdul és l’explotació i adequació dels sistemes de
gestió empresarial desenvolupant components específics segons les necessitats i
requeriments plantejats.
En la unitat “Sistemes ERP. Explotació i adequació”, s’estudia el desenvolupament
de nous mòduls que es puguin integrar al sistema, amb el programari i llenguatges
específics. A continuació, aprendrem a ampliar i modificar mòduls existents,
traduccions idiomàtiques, aspectes relatius a la seguretat, dissenyar i modificar
informes
Els continguts d’aquest mòdul tenen una orientació bàsicament professionalitza-
dora, es proposa una formació pràctica i aplicable amb l’objectiu que l’alumnat
aprengui a saber fer. Un cop llegits detingudament els continguts de cada apartat,
cal realitzar les activitats i els exercicis d’autoavaluació per tal de posar en pràctica
i comprovar l’assoliment dels coneixements adquirits. I, sobretot en les unitats
referides a l’explotació i adequació dels sistemes ERP, és molt important la
pràctica, en els propis ordinadors, dels exemples que es descriuen en el material
docent.
Resultats d’aprenentatge
En finalitzar aquest mòdul l’alumne/a:

Sistemes ERP-CRM. Implantació
1. Identifica sistemes de planificació de recursos empresarials i de gestió de

relacions amb clients (ERP-CRM) reconeixent les seves característiques i
verificant la configuració del sistema informàtic.
2. Implanta sistemes ERP-CRM interpretant la documentació tècnica i identi-

ficant les diferents opcions i mòduls.
Sistemes ERP-CRM. Explotació i adequació
1. Realitza operacions de gestió i consulta de la informació seguint les especi-

ficacions de disseny i utilitzant les eines proporcionades pels sistemes ERP-
CRM i solucions d’intel·ligència de negocis (BI).
2. Adapta sistemes ERP-CRM identificant els requeriments d’un supòsit em-

presarial i utilitzant les eines proporcionades pels mateixos.
3. Desenvolupa components per a un sistema ERP-CRM analitzant i utilitzant

el llenguatge de programació incorporat.
Continguts
Unitat 1
1. Identificació de sistemes ERP-CRM i solucions BI
2. Implantació tècnica de sistemes ERP-CRM: OpenERP
Sistemes ERP-CRM. Explotació i adequació
Unitat 2
Sistemes ERP-CRM. Explotació i adequació - I
1. Explotació i adequació. OpenERP: el model
2. OpenERP: la vista i el controlador
Unitat 3
Sistemes ERP-CRM. Explotació i adequació - II
1. OpenERP: desenvolupament avançat
2. Reporting & BI
Sistemes ERP-CRM.
Implantació
Sistemes de gestió empresarial

Sistemes de gestió empresarial Sistemes ERP-CRM. Implantació
Índex
Introducció 5
Resultats d’aprenentatge 7
1 Identificació de sistemes ERP-CRM i solucions BI 9

1.1 Llicències de programari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Tipus de desplegament i requeriments associats . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2.1 Des dels mainframes fins al cloud computing . . . . . . . . . . . . . . . . . . . . . . 13
1.2.2 Requeriments per a un desplegament . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Sistemes ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1 Requeriments per ser ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.2 Funcionalitats dels sistemes ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.3 La llegenda de la implantació dels ERP . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.3.4 Els ERP a les PIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4 Sistemes CRM i solucions BI, complements dels ERP? . . . . . . . . . . . . . . . . . . . . . 35
1.4.1 Funcionalitats dels sistemes CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4.2 Funcionalitats de les solucions BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2 Implantació tècnica de sistemes ERP-CRM: OpenERP 45

2.1 Instal·lació d’OpenERP All-In-One en el SO Windows . . . . . . . . . . . . . . . . . . . . . 49
2.2 Instal·lació del client GTK de OpenERP en el SO Windows . . . . . . . . . . . . . . . . . . . 53
2.3 Usuaris al voltant d’un servidor OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.4 Coneixements bàsics del servidor PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.4.1 Què incorpora el servidor PostgreSQL que instal·la OpenERP? . . . . . . . . . . . . 56
2.4.2 Eina pgAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.3 Configurar PostgreSQL per admetre connexions remotes . . . . . . . . . . . . . . . . 61
2.4.4 Consola textual per gestionar un servidor PostgreSQL . . . . . . . . . . . . . . . . . 65
2.5 Instal·lació d’OpenERP en el SO Windows utilitzant un SGBD PostgreSQL ja instal·lat . . . . 67
2.6 Gestió d’empreses en OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.6.1 Creació d’empreses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.6.2 Eliminació d’empreses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.7 Iniciació bàsica a OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.7.1 Incorporació d’idiomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.7.2 Iniciació a les interfícies web i GTK . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.7.3 Configuració bàsica d’una empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.7.4 Instal·lació de mòduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.7.5 Gestió de la seguretat en una empresa: usuaris i grups de privilegis . . . . . . . . . . 93
2.8 Instal·lació d’OpenERP a Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.8.1 Instal·lació a Ubuntu a través de paquets . . . . . . . . . . . . . . . . . . . . . . . . . 97
2.8.2 Instal·lació a Ubuntu a través de codis font . . . . . . . . . . . . . . . . . . . . . . . 100
Sistemes de gestió empresarial 5 Sistemes ERP-CRM. Implantació
Introducció
Les empreses necessiten, per a una òptima gestió empresarial, un suport informàtic
adequat a les seves necessitats. Per aquest motiu hi ha en el mercat diversos
programes informàtics: gestió comercial, compravenda, facturació, comptabilitat,
nòmines, producció, relació amb els clients... molts d’ells englobats en paquets
que es distribueixen a unitats o de forma modular. El conjunt de programes que
una empresa utilitza per acompanyar la seva gestió diària constitueixen el seu
sistema de gestió empresarial.
Els primers sistemes de gestió empresarial van aparèixer amb el naixement de la

informàtica, ja que un dels seus camps d’aplicació era el suport a la gestió de
l’empresa. L’evolució per una banda de les tecnologies de la informació i, per
l’altra, de la gestió de processos en les empreses, ens ha portat al moment actual
en el qual es considera que els sistemes informàtics de gestió empresarial òptims
per a una empresa són els anomenats sistemes ERP, de manera que podem trobar-
nos amb la contradicció que el sistema informàtic de gestió d’una empresa es basi
en un conjunt d’aplicacions que faciliten un funcionament complet i correcte i, en
canvi, es consideri no òptim segons els cànons actuals, per no complir els requisits
d’un sistema ERP.
La primera part del títol de la unitat formativa (sistemes ERP-CRM) introdueix el

concepte de sistemes ERP i, també, el concepte de sistemes CRM. Els mots ERP i
CRM corresponen a acrònims de l’anglès àmpliament utilitzats en la informàtica.
Així, el mot ERP correspon a l’acrònim anglès d’Enterprise Resource Planning
(planificació de recursos empresarials) i el mot CRM correspon a l’acrònim anglès
de Customer Relationship Management (gestió de la relació amb els clients).
Per una banda tenim els sistemes ERP que engloben o pretenen englobar totes
les dades i processos d’una organització en un sistema integrat. Per altra banda,
tenim els sistemes CRM ideats per donar suport a la gestió de les relacions amb
els clients, a la venda i al màrqueting. Si ens fixem en la definició dels sistemes
ERP, la gestió que faciliten els sistemes CRM hauria d’estar inclosa en els sistemes
ERP i la realitat és que la majoria dels actuals ERP incorporen una gestió completa
CRM. Però també és veritat que encara hi ha moltes PIME que no tenen implantat
un ERP o que tenen un ERP no actual i que, per elles, la implantació d’un sistema
CRM pot portar a una millora substancial de la seva gestió. Per això és important
conèixer també els sistemes CRM actuals.
La segona part del títol de la unitat formativa (implantació) porta a dues interpre-
tacions. Una, d’abast molt ampli, que fa referència a tot el procés d’implantació
d’un sistema ERP-CRM, dirigit per experts consultors. L’altre, d’abast més reduït,
es refereix a la instal·lació, configuració i posada en marxa d’un sistema ERP-
CRM, que podríem anomenar implantació tècnica del sistema ERP-CRM. El
mot implantació en el títol d’aquesta unitat formativa fa referència a la segona
interpretació.
Així doncs, la unitat formativa “Sistemes ERP-CRM. Implantació” contempla

dues grans temàtiques: el coneixement dels sistemes ERP-CRM i la implantació
tècnica dels sistemes ERP-CRM i, en conseqüència, s’ha dividit en dos apartats.
En l’apartat “Identificació de sistemes ERP-CRM i solucions BI” es presenten els

sistemes ERP-CRM i les solucions BI. Pel que fa als sistemes ERP, veurem els
requeriments per tal que un programari de gestió pugui ser considerat ERP, les
funcionalitats facilitades pels sistemes ERP, la classificació actual dels sistemes
ERP — tenint en compte els tipus de llicència i els tipus de desplegament—,
la problemàtica de la implantació dels sistemes ERP i la situació dels ERP a
les PIME, amb una visió dels principals productes actuals. Quant als sistemes
CRM, farem una presentació de les seves funcionalitats i una ullada als principals
productes actuals.
El mot BI correspon a l’acrònim anglès de Business Intelligence (intel·ligència

de negoci). Les solucions BI són eines destinades a facilitar dades als dirigents
empresarials, obtingudes a partir de les dades dels sistemes ERP-CRM, amb
l’objectiu d’ajudar la presa de decisions. Els sistemes ERP-CRM incorporen cada
vegada més solucions BI, però encara hi ha moltes PIME que no tenen implantat
un ERP-CRM o que tenen un ERP-CRM no actual i que la utilització de solucions
BI independents els pot ser molt convenient, és per això que s’inclouen en aquesta
unitat formativa.
L’apartat “Implantació tècnica de sistemes ERP-CRM: OpenERP” ens endinsa,

com el seu nom indica, en què cal tenir en compte, de forma genèrica, per efectuar
una implantació tècnica d’un sistema ERP-CRM. Com que no hi ha dos sistemes
ERP-CRM en els quals el procés d’implantació tècnica sigui igual, posarem en
pràctica el procés en el sistema ERP de codi obert OpenERP.
Per tal d’assolir un bon aprenentatge cal estudiar els continguts en l’ordre indicat,
sense saltar-se cap apartat i, quan es fa referència a algun annex del web, adreçar-
s’hi i estudiar-lo. En els materials web trobareu molts vídeos referents a sistemes
ERP-CRM i solucions BI; visualitzeu-los per fer-vos una idea dels productes que
hi ha en el mercat. Una vegada estudiats els continguts del material paper i del
material web, desenvolupeu les activitats web.
Què us sembla? Comencem!

En finalitzar aquesta unitat l’alumne/a:
1. Identifica sistemes de planificació de recursos empresarials i de gestió de rela-

cions amb clients (ERP-CRM) reconeixent les seves característiques i verificant
la configuració del sistema informàtic.
• Reconeix els diferents sistemes ERP-CRM que hi ha al mercat.
• Compara sistemes ERP-CRM en funció de les seves característiques i

requisits.
• Reconeix els magatzems de dades (data warehouse) acoblables i/o incorpo-

rats als diferents sistemes ERP-CRM.
• Identifica el sistema operatiu adequat a cada sistema ERP-CRM.
• Identifica el sistema gestor de dades adequat a cada sistema ERP-CRM.
• Verifica les configuracions del sistema operatiu i del gestor de dades per
garantir la funcionalitat de l’ERP-CRM.
• Documenta les operacions realitzades.
• Documenta les incidències produïdes durant el procés.
2. Implanta sistemes ERP-CRM interpretant la documentació tècnica i identificant

les diferents opcions i mòduls.
• Identifica els diferents tipus de llicència.
• Identifica els mòduls que componen el ERP-CRM.
• Realitza instal·lacions monoestació.
• Realitza instal·lacions client/servidor.
• Configura els mòduls instal·lats.
• Realitza instal·lacions adaptades a les necessitats plantejades en diferents

supòsits.
• Instal·la i configura, si hi ha possibilitat, algun magatzem de dades adequat

al sistema ERP-CRM.
• Comprova l’ERP-CRM.
• Documenta les operacions realitzades i les incidències.

1. Identificació de sistemes ERP-CRM i solucions BI
Les empreses necessiten, per a una òptima gestió empresarial, un suport informàtic
adequat a les necessitats de l’empresa. Per aquest motiu hi ha en el mercat diversos
programes informàtics: gestió comercial, compravenda, facturació, comptabilitat,
nòmines, producció, relació amb els clients... molts d’ells englobats en paquets
que es distribueixen com a unitats o de forma modular.
Els sistemes ERP, de l’anglès Enterprise Resource Planning, coneguts àmpli-

ament com a sistemes de planificació de recursos empresarials, tot i que el
TERMCAT (centre de terminologia de la llengua catalana) tradueix el terme
ERP com a programari de gestió integrada, són sistemes que integren o pretenen
integrar totes les dades i processos d’una organització en un sistema unificat.
Aquesta definició pot portar a confondre els ERP amb els paquets comercials que
engloben diversos programes. És important conèixer la frontera entre ambdós
tipus de productes.
Els sistemes CRM, de l’anglès Customer Relationship Management, coneguts

com a sistemes de gestió de la relació amb els clients, són sistemes que donen
suport a la gestió de les relacions amb els clients, a la venda i al màrqueting.
Les solucions BI, de l’anglès Business Intelligence, conegudes com a solucions

d’intel·ligència de negoci o solucions d’intel·ligència empresarial, són un conjunt
d’eines destinades a facilitar dades als dirigents empresarials, obtingudes a partir
de les dades dels sistemes ERP-CRM, amb l’objectiu d’ajudar a la presa de decisi-
ons. El ventall de solucions BI és ampli: des d’eines d’elaboració d’informes fins
a sofisticades eines de gestió de cubs OLAP.
Abans d’entrar en la instal·lació, configuració, explotació i adequació de sistemes

ERP-CRM i solucions BI, ens convé conèixer:
1. Els tipus de llicenciament actuals.
2. Els tipus de desplegament (implantacions) actuals i requeriments associats.
3. Les funcionalitats normalment proporcionades per les aplicacions

ERP/CRM/BI.
4. Els principals productes existents en el mercat.
1.1 Llicències de programari
En el mercat actual trobem un gran nombre d’aplicacions que poden tenir utilitat
a les empreses. Totes elles van acompanyades d’un determinat tipus de llicència.
Per altra banda, ha proliferat una gran nombre de tipus de llicències de programari.
En conseqüència, ens cal poder reconèixer la llicència que acompanya cada
programari i les seves implicacions.
Una llicència de programari és l’autorització o permís concedit pels autors

del programari per poder-lo utilitzar, sota uns drets i deures.
A causa que els drets i deures que els autors poden assignar a les seves obres són de
diversos tipus, han aparegut un gran nombre de tipus de llicències que, bàsicament,
podem classificar en dos grans grups: programari privatiu i programari lliure.
Per programari lliure (free software) entenem aquell programari que

respecta la llibertat total de l’usuari sobre el producte adquirit. Per
programari privatiu entenem tot programari que no sigui lliure.
El nostre objectiu no és conèixer l’evolució que han tingut els conceptes progra-
mari lliure i programari privatiu, sinó conèixer els conceptes existents i utilitzats
Programari privatiu
en el moment actual.
Hi ha força controvèrsia pel que
fa a la nomenclatura de Pel que fa al programari lliure, ens cal saber que, segons la Free Software
programari privatiu. Així, altres
termes que s’utilitzen són Foundation, un programari és lliure quan garanteix les quatre llibertats següents
programari propietari,
programari esclau, programari (enumerades a partir del valor zero):
tancat, programari privat i
programari no lliure. El motiu de
la controvèrsia radica en les
connotacions dels diversos mots. 1. Llibertat d’utilitzar el programa per a qualsevol propòsit.
2. Llibertat d’estudiar el funcionament del programa, modificant-lo i adaptant-

lo a nous requeriments.
3. Llibertat de distribuir còpies del programa.
4. Llibertat de millorar el programa i fer públiques les millores, de manera que

tota la comunitat se’n beneficiï.
La Free Software
Foundation és una
organització creada
l’octubre de 1985 per
Richard Stallman i altres Davant d’aquesta definició, qualsevol programari que violi alguna de les quatre
promotors del programari
lliure, per difondre aquest
llibertats anteriors passa a ser programari privatiu.
moviment.
Sovint, el concepte programari lliure es confon amb programari gratuït i/o amb
codi obert i els tres conceptes són diferents, malgrat tenir punts en comú.
La confusió entre programari lliure i programari gratuït ve donada per l’ambigüitat

Logotip de Free Software Foundation del mot free en la llengua anglesa, on té doble significat: llibertat i gratuïtat.
Certament, la majoria de programari lliure acostuma a ser gratuït, però això no
és obligatori. Hi pot haver programari lliure no gratuït i programari gratuït no
lliure. El concepte anglès a utilitzar per fer referència al programari gratuït (sigui
o no lliure) és freeware.
La confusió entre programari lliure i codi obert (open source) és simple d’explicar,
ja que el programari lliure, per tal de garantir les llibertats 1 i 3, obliga a tenir accés
al codi del programari, és a dir, el programari lliure té el codi obert. Però darrere
dels mots programari lliure i codi obert hi ha dos moviments ben diferenciats des
del punt de vista filosòfic.
La utilització del concepte de codi obert va aparèixer per primera vegada l’any
1998, quan alguns usuaris del moviment pel programari lliure el van utilitzar per
substituir el nom programari lliure a causa de l’ambigüitat del terme free en la
llengua anglesa. Però per alguns seguidors del moviment pel programari lliure
la substitució no es va considerar adequada ja que es perdia el sentit ètic i moral
implícit en el mot llibertat utilitzat en la definició del programari lliure. Així es
va produir una escissió del moviment pel programari lliure, apareixent la Open
Source Initiative, fundada per Bruce Perens i Eric S. Raymond.
La iniciativa pel codi obert exigeix que la distribució del programari de codi obert Logotip de Open Source Initiative
ha de verificar el següent decàleg:
1. Lliure redistribució: el programari ha de poder ser regalat o venut lliure-

ment.
2. Codi font: el codi font ha d’estar inclòs o s’ha de poder obtenir lliurement.
3. Treballs derivats: la redistribució de modificacions ha d’estar permesa.
4. Integritat del codi font de l’autor: les llicències poden requerir que les
modificacions siguin redistribuïdes només com a pegats.
5. Sense discriminació de persones o grups: no es pot deixar ningú a fora.
6. Sense discriminació d’àrees d’iniciativa: no es pot restringir a ningú que

faci ús del programa en un camp específic d’activitat. Per exemple, no es
pot impedir que el programa sigui utilitzat en un negoci o que s’utilitzi per
a la investigació genètica.
7. Distribució de la llicència: s’ha d’aplicar els mateixos drets a tothom que

rebi el programa.
8. La llicència no ha de ser específica d’un producte: el programa no es pot

llicenciar només com a part d’una distribució major.
9. La llicència no ha de restringir cap altre programari: la llicència no pot

obligar que algun altre programari que sigui distribuït amb el programari
obert hagi de ser també de codi obert.
10. La llicència ha de ser tecnològicament neutral: l’acceptació de la llicència

no es pot basar en una tecnologia o un estil d’interfície. Per exemple, no es
pot requerir l’acceptació de la llicència a través d’un clic de ratolí o de cap
forma específica del mitjà de suport del programari.
El decàleg del codi obert és compatible amb les quatre llibertats del programari
lliure i, des d’un punt de vista pràctic, ambdós moviments són equivalents, però
són totalment incompatibles des d’un punt de vista filosòfic.
Pels defensors del codi obert, el fet de tenir accés total al codi font del programari
és una qüestió pràctica que possibilita que el programari evolucioni, es desenvolu-
pi i millori a una alta velocitat, més alta que la que es pot assolir en els processos
convencionals de desenvolupament de programari. Pels defensors del codi obert

les llibertats esgrimides pel programari lliure no tenen importància; l’objectiu és,
únicament, tenir accés al codi per tal d’assolir un codi millor. En conseqüència,
pel moviment del codi obert, el codi tancat mai podrà ser millor que el codi obert.
Pels defensors del programari lliure allò que importa és la defensa de les llibertats;
l’accés al codi és conseqüència de les llibertats 1 i 3 i la qualitat del codi tancat
no té perquè ser inferior a la del codi obert.
Fig u ra 1 . 1 . Diferents categories del programari
La distinció dels conceptes programari lliure, programari privatiu i codi obert és

el primer pas per categoritzar un programari, però ens manca conèixer més con-
ceptes utilitzats actualment. La figura 1.1, original de Chao-Kuei i posteriorment
actualitzada per altres, situa les diferents categories del programari, que ens cal
identificar:
1. Programari de domini públic: programari que no està protegit amb copy-

right. El copyright reflecteix la possessió del dret d’explotació i, per tant,
només el pot fer constar el titular o cessionari d’aquest dret.
2. Programari sota copyleft (còpia permesa): les llicències copyleft són aque-
lles que exerceixen els autors del programari, emparats en la legislació de
copyright, per permetre la lliure distribució de còpies i versions modificades
d’una determinada obra. La majoria de les llicències copyleft exigeixen que
els drets concedits es mantinguin en les versions modificades del producte.
3. Programari sota GPL: la llicència GPL (Llicència Pública General de GNU)

és una llicència creada per la Free Software Foundation, orientada a protegir
la lliure distribució, modificació i utilització del programari, de manera
que el programari cobert per aquesta llicència és programari lliure i queda
protegit de qualsevol intent d’apropiació que restringeixi les llibertats del
programari lliure. La formulació de GPL és tant restrictiva que impedeix
que el programari sota aquesta llicència pugui ser integrat en programari
privatiu.
4. Programari sota llicències laxes o permissives: les llicències laxes o per-

missives són llicències de programari lliure flexibles respecte la distribució,
de manera que el programari pugui ser redistribuït com a programari
lliure o privatiu. Són llicències sense copyleft, ja que consideren que el
treball derivat no té perquè mantenir el mateix règim de drets d’autor que
l’original. Això dóna total llibertat a qui rep el programari per desenvolupar-
ne qualsevol producte derivat, i li permet escollir entre l’ampli ventall de
llicències existents. Des del punt de vista dels usuaris, però, aquestes
llicències es poden considerar com una restricció a les llibertats que defensa
el programari lliure. Exemples de llicències d’aquest tipus són les llicències
BSD i MIT.
5. Programari de prova (shareware): les llicències shareware autoritzen la

utilització d’un programa per tal que l’usuari l’avaluï i posteriorment
l’adquireixi. Aquest programari acostuma a tenir unes limitacions, ja sigui
en el temps d’utilització o en les funcionalitats permeses.
1.2 Tipus de desplegament i requeriments associats
Tradicionalment, les aplicacions ERP/CRM/BI han estat allotjades a les ins-

tal·lacions de les organitzacions compradores de les llicències de l’aplicació,
desplegament conegut majoritàriament com a on-premise i, en menor grau, com
a in-house. Però això està canviant.
La història dels tipus de desplegament de les aplicacions de gestió empresarial ha

anat lligada a l’evolució que ha tingut la tecnologia. En aquests moments podem
dir que estem entrant en una nova època: l’època de la informàtica en núvol (cloud
computing) i amb ella, diversos models de desplegament (IaaS, PaaS i SaaS) que
s’imposaran o conviuran amb el model tradicional on-premise.
Per saber on som ens convé, en un primer lloc, conèixer els tipus de desplegament
que hi ha hagut al llarg de la història i, per poder dur a terme desplegaments en el
moment actual, ens cal poder distingir els requeriments associats.
1.2.1 Des dels mainframes fins al cloud computing
En la primera època (la dècada dels 60 i dels 70) les aplicacions residien en
grans ordinadors (mainframes) ubicats en les dependències de l’organització i els
usuaris disposaven de terminals (pantalles sense memòria ni capacitat de procés)
connectades amb l’ordinador central.
La segona època arriba en la dècada dels 80, amb l’eclosió dels ordinadors
personals. Les aplicacions empresarials van anar adoptant l’arquitectura de dues
capes (client-servidor), en les quals continua existint l’ordinador central (servidor
–un o diversos–) que conté les bases de dades i en la qual la terminal de l’anterior
època queda substituïda per l’ordinador personal que, en disposar de memòria i

capacitat de procés, incorpora les aplicacions a executar. L’arquitectura client-
servidor ensopega aviat amb el problema del manteniment de les aplicacions,
ja que cada vegada que la lògica de negoci canvia o evoluciona cal actualitzar
l’aplicació en tots els ordinadors personals clients.
Per aquest motiu, s’adopta ben aviat l’arquitectura de tres capes (presentació-
negoci-dades) il·lustrada a la figura 1.2, en la qual els clients tenen aplicacions
senzilles que únicament presenten les dades subministrades per un o diversos
servidors d’aplicacions, contenidors de la capa de negoci, que confeccionen
aquelles dades a partir de la informació subministrada pels servidors de la capa de
dades.
Fig ur a 1 . 2 . Arquitectura de tres capes
La tercera època s’inicia a mitjans de la dècada dels 90, coincidint amb el

boom d’Internet i va acompanyada de la contínua millora de l’ample de banda.
Les aplicacions empresarials cerquen mecanismes per facilitar la connexió dels
òrgans de comandament de les empreses des d’ubicacions remotes. Això fa que
proliferin programaris que, aprofitant Internet, faciliten la connectivitat remota
i obren en els dispositius remots (portàtils i PDAs) sessions client contra el
servidor d’aplicacions. De ben segur que un dels programaris més coneguts
és l’escriptori remot del sistema operatiu Microsoft Windows. Però aquests
programaris presenten un problema: cal tenir instal·lat en el dispositiu remot el
programari adequat per poder establir la connexió i això no sempre és factible. Ara
bé, sense por a equivocar-nos, quin és el programari que tenen avui en dia tots els
dispositius que es connecten a Internet, sigui quin sigui el sistema operatiu utilitzat
(Windows, Linux, Mac, iOS, Android...)? Un navegador, oi? En conseqüència, es
tracta d’aconseguir que a través del navegador puguem executar les aplicacions
empresarials.
Durant la primera dècada del segle XXI, encara dins la tercera època, les apli-
cacions empresarials es van acomodant a la nova situació tecnològica i faciliten
solucions accessibles des dels navegadors web. L’arquitectura de tres capes
continua sent vàlida per a la nova situació. Simplement cal afegir un servidor
web davant el(s) servidor(s) d’aplicacions per permetre la connexió des dels
navegadors. Els clients tradicionals poden continuar existint i es comuniquen

directament amb el(s) servidor(s) d’aplicacions. La figura 1.3 n’il·lustra la
situació.
En aquesta nova arquitectura hi ha desavinences sobre la capa on ubicar el

servidor web. Hi ha autors que, a causa del fet que el servidor web simplement
s’encarrega de confeccionar les pàgines que es visualitzen en el navegador, el
consideren com a part de la capa de presentació. D’altres, com que és un servidor
d’aplicacions, l’ajunten amb els servidors d’aplicacions on hi ha la capa de negoci.
Per últim, hi ha autors que parlen d’arquitectura de quatre capes, destinant una
capa específicament al servidor web.
L’arquitectura de quatre capes (aplicacions empresarials que permeten l’accés

web) és d’extrema actualitat. Les aplicacions que no incorporen aquesta funci-
onalitat estan abocades a la desaparició. Poden sobreviure a causa del cost que
suposa un canvi total de programari però difícilment podran ampliar la seva quota
de mercat.
Fi gu ra 1 .3. Arquitectura de tres (o quatre) capes per a web
Finalment, ens trobem en el futur que ja és present: la quarta època. La informàtica

en núvol (cloud computing) és un sistema d’emmagatzematge i ús de recursos
informàtics basat en el servei en xarxa, que consisteix en oferir a l’usuari un
espai virtual, generalment a Internet, en què pot disposar de les versions més
actualitzades de maquinari i programari.
Hi ha tres models d’informàtica en núvol:
1. Infraestructura com a servei (IaaS, de Infraestructure as a Service),

en el qual l’usuari contracta únicament les infraestructures tecnològiques

(capacitat de procés, d’emmagatzematge i/o de comunicacions) sobre les
quals hi instal·la les seves plataformes (sistemes operatius) i aplicacions.
L’usuari té el control total sobre les plataformes i aplicacions, però no té
cap control sobre les infraestructures.
2. Plataforma com a servei (PaaS, de Platform as a Service), en el qual

l’usuari contracta un servei que li permet allotjar i desenvolupar les seves
pròpies aplicacions (ja siguin desenvolupaments propis o llicències adqui-
rides) en una plataforma que disposa d’eines de desenvolupament per tal
que l’usuari pugui elaborar una solució; en aquest model, el proveïdor
ofereix l’ús de la seva plataforma que a la vegada es troba allotjada en
infraestructures, de la seva propietat o d’altri. L’usuari no té cap control
sobre la plataforma ni sobre la infraestructura però manté el control total
sobre les seves aplicacions.
3. Programari com a servei (SaaS, de Software as a Service), en el qual l’usu-

ari contracta la utilització d’unes determinades aplicacions sobre les quals
únicament pot exercir accions de configuració i parametrització permeses
pel proveïdor. L’usuari no té cap control sobre l’aplicació, la plataforma i
la infraestructura.
Els models IaaS i PaaS ja fa temps que s’estan utilitzant (des que l’ample de banda
ho ha fet possible) i el model SaaS també en aplicacions vinculades a Internet, com
per exemple el correu electrònic. En canvi, fins fa ben poc (cap a l’any 2010) no
han començat a aparèixer aplicacions empresarials (ERP/CRM/BI) sota el model
SaaS.
No hem de confondre tenir una aplicació empresarial en el núvol, de la qual

nosaltres n’hem adquirit llicències però hem optat per tenir-la instal·lada a Internet
(model IaaS o PaaS) enlloc de tenir-la a casa nostra (on-premise), amb contractar
la utilització d’una aplicació que algú té allotjada en el núvol (model SaaS) i per la
qual no hem d’adquirir cap llicència sinó únicament prestacions (nombre d’usuaris
i funcionalitats).
Entre els beneficis del model SaaS, cal considerar:
• Integració comprovada dels serveis en xarxa.
• Prestació de serveis a nivell mundial.
• Cap necessitat d’inversió en maquinari.
• Implementació ràpida i sense riscos. La posada en marxa només precisa de

la configuració i parametrització permesa pel proveïdor.
• Actualitzacions automàtiques ràpides i segures.
• Ús eficient de l’energia, davant l’energia requerida pel funcionament d’una

infraestructura on-premise.
Entre els inconvenients del model SaaS, cal considerar:

• Dependència dels proveïdors de serveis.
• Disponibilitat de l’aplicació lligada a la disponibilitat d’Internet.
• Por a sostracció o robatori de les dades “sensibles” del negoci, ja que no

resideixen a les instal·lacions de les empreses.
• Perill de monopolis referents als serveis facilitats pels proveïdors.
• Impossibilitat de personalitzar l’aplicació, fora de la configuració i parame-

trització permesa pel proveïdor.
• Actualitzacions periòdiques que poden incidir de manera negativa en l’apre-

nentatge dels usuaris d’orientació no tecnològica.
• Existència de focus d’inseguretat en els canals a recórrer per arribar a la

informació, si no s’utilitzen protocols segurs (HTTPS) per no disminuir la
velocitat d’accés.
• Possible degradació en els serveis subministrats pel proveïdor davant l’aug-

ment de clients.
Sembla que el model SaaS és una tendència de futur, sobretot per petites i mitjanes
empreses que no disposen de recursos informàtics adequats per poder respondre al
repte d’adquirir llicències d’una aplicació empresarial (ERP/CRM/BI) i procedir
a la seva instal·lació/configuració/personalització (ja sigui sota model on-premise
o sota models IaaS/PaaS). Llavors, endinsar-nos en la implementació, explotació
i adequació dels sistemes de gestió empresarial sembla una incongruència, oi?
Prenguem-nos-ho per la banda positiva: ens convé introduir-nos en els sistemes
de gestió empresarial per poder assessorar a les petites i mitjanes empreses que
ens demanin consell i per dur a terme un correcte desplegament en aquelles
organitzacions per optin pels models on-premise o IaaS/PaaS.
1.2.2 Requeriments per a un desplegament
Els desplegaments d’aplicacions empresarials avui en dia poden tenir lloc sota
dos models: on-premise (a casa del comprador de les llicències) o IaaS/PaaS
(dues modalitats d’informàtica en núvol). En qualsevol cas, hem de pensar que
l’aplicació empresarial està desenvolupada sota l’arquitectura web de tres capes i,
per tant, cal disposar de:
• Servidor d’aplicacions.
• Servidor web, que possiblement compartirà maquinari amb el servidor

d’aplicacions.
• Servidor de dades (SGBD) que molt possiblement serà un SGBD relacional

o objecte-relacional.
Per atendre a aquestes necessitats, cal avaluar què necessitem i què tenim. Aquesta
tasca, però, s’escapa de les capacitats d’un desenvolupador de programari i són
tasques per encomanar a consultors i administradors de sistemes. Però, és possible
que ens toqui fer-ho en una PIME que ens hagi demanat consell i no hi hagi
consultors ni administradors de sistemes. En un cas així, caldrà:
• Identificar els requeriments directes de maquinari (bàsicament RAM, CPU i

capacitat de disc dur) especificats pel programari de gestió empresarial que
s’ha d’instal·lar, tenint en compte la conveniència o no de virtualitzar els
servidors.
• Identificar l’SGBD amb el que pot treballar el programari que s’ha d’ins-
tal·lar. Algunes vegades, un mateix programari de gestió empresarial
permet utilitzar diferents SGBD, situació en la qual cal analitzar quin d’ells
és millor en funció de les necessitats de l’empresa i del seu cost, tenint
en compte que n’hi ha de molt potents amb versions gratuïtes. Així,
per exemple, una botiga de bicicletes que adquireixi un ERP per dur la
gestió informatitzada dels circuits compravenda, inventari i comptabilitat
és possible que en tingui prou amb un SGBD ofimàtic, com ara Microsoft
Access, mentre que un supermercat, amb el mateix ERP, és possible que no
en tingui prou amb un SGBD ofimàtic i en precisi un de major potència.
• Identificar els requeriments indirectes de maquinari a partir dels requeri-

ments de maquinària propis de l’SGBD escollit.
• Identificar mecanismes idonis per a efectuar còpies de seguretat de les

dades que permetin la recuperació segons les necessitats de disponibilitat de
l’organització. Tot programari de gestió empresarial ha d’anar acompanyat
d’un mecanisme de recuperació adequat que cal testar periòdicament. En
una organització amb disponibilitat 24x7 (és a dir, que no pot aturar en cap
moment) caldrà preveure una estratègia de còpies de seguretat en calent
i això repercutirà en l’elecció de l’SGBD. En canvi, en una organització
que s’aturi unes hores al dia, podem preveure una estratègia de còpies
de seguretat en fred. En qualsevol cas (còpies en calent o en fred), cal
pensar en la necessitat o no de disposar d’un sistema de còpies que permeti,
davant d’una catàstrofe, la recuperació de tots els moviments efectuats des
de la darrera còpia de seguretat fins al moment de la catàstrofe. És a dir,
si la darrera còpia de seguretat (en calent o en fred) és de les 0.00h de
la nit anterior i a les 11.30h es produeix una catàstrofe que ens obliga a
tibar de la còpia de la nit anterior, podem assumir haver perdut tots els
moviments efectuats des de la nit anterior fins al moment de la catàstrofe?
Els grans SGBD permeten activar mecanismes de registre diari (log en
anglès) que emmagatzemen cronològicament en un fitxer les operacions de
processament de dades efectuades a la base de dades, de manera que davant
una caiguda del sistema i de la darrera còpia de seguretat, permeten restablir
tots els moviments efectuats en el sistema.
• Identificar mecanismes per recuperar el sistema informàtic davant un error

de maquinari. Davant un mal funcionament de qualsevol peça de maquinari
(placa base, memòria, processador o disc dur), tot i que tinguem contractat
un servei de manteniment, podem assumir tenir el sistema aturat? Hi ha
ocasions en què és possible (botiga d’informàtica, en la qual si fem alguna

venda podem anotar-la a mà) i ocasions en què no és possible (us imagineu
una botiga en línia d’Internet en la qual falla el sistema informàtic i ha d’estar
aturada unes hores?). En el cas que no sigui possible una aturada d’hores,
quina és la millor solució? Avui en dia la utilització de servidors NAS per a
l’emmagatzematge amb funcionalitats RAID activades conjuntament amb
la virtualització dels servidors és, possiblement, la millor solució. Hi ha
sistemes que permeten tenir els servidors virtualitzats en un servidor de
virtualització que cap en un llapis òptic (és a dir, pot no ser en un disc dur)
de manera que, davant una aturada de la màquina (problema de placa base,
processador o memòria) podem utilitzar el llapis òptic per posar en marxa
ràpidament el servidor de virtualització en qualsevol altra màquina (encara
que tingui menys prestacions). A més, un problema en l’emmagatzematge
en el servidor NAS queda cobert per les funcionalitats RAID activades, de
manera que la recuperació pot ser molt ràpida.
1.3 Sistemes ERP
Els sistemes ERP, de l’anglès Enterprise Resource Planning, coneguts àmplia-

ment com a sistemes de planificació de recursos empresarials, són sistemes que
integren o pretenen integrar totes les dades i processos d’una organització en un
sistema unificat.
Així doncs, segons la definició anterior, un ERP ha de permetre la gestió de la

producció (si l’organització incorpora processos productius), la gestió completa
dels circuits de compravenda (logística, distribució, inventari i facturació) i la
gestió financera. Poden incorporar també, en moltes ocasions, una gestió de
recursos humans. En l’actualitat, molts d’ells incorporen una gestió de CRM
(gestió de la relació amb els clients).
El nostre objectiu és instal·lar l’ERP i configurar-lo, parametritzar-lo o adequar-

lo a les necessitats de l’organització. Per poder abordar amb garanties aquest
objectiu ens cal conèixer prèviament com són els ERP, de la mateixa manera que
un mecànic de cotxes, abans d’introduir-se en la mecànica, ha de conèixer com és
un automòbil.
1.3.1 Requeriments per ser ERP
En el mercat hi ha moltes aplicacions de gestió empresarial i no totes elles

poden ser considerades un ERP; són simplement aplicacions de gestió i hi ha
diferències fonamentals entre les aplicacions de gestió i els ERP, malgrat l’intent
de moltes empreses, mitjançant estratègies de màrqueting, d’intentar vendre els
seus productes amb la denominació ERP per tal d’obtenir un valor agregat als
seus productes sense incrementar la seva funcionalitat.
Hi ha tres característiques fonamentals que defineixen un ERP:
• És un sistema integral: la pròpia definició d’ERP indica que és una

aplicació que integra en un únic sistema tots els processos de negoci de
l’empresa, així manté les dades d’una forma centralitzada. Això implica
que la informació no pot estar duplicada i que només s’introdueix una única
vegada. Aquesta definició descarta:
– Programes basats en múltiples aplicacions (en ocasions denominades

suite) independents o modulars que dupliquen la informació (malgrat
l’enllacin automàticament).
– Programes que no centralitzen la informació en una única base de
dades.
– Programes que no emmagatzemen les dades en un SGBD sinó que
utilitzen sistemes gestors de fitxers, anteriors als SGBD.
• És un sistema modular: un ERP es compon de diversos mòduls on cada

mòdul es centra en una àrea de negocis de l’empresa. Normalment els
ERP tenen un mòduls troncals (bàsics) que s’adquireixen amb la compra de
l’ERP (gestió de compravenda, control d’inventari, comptabilitat) i d’altres
mòduls que s’adquireixen segons les necessitats de l’organització (gestió de
projectes, gestió de campanyes, gestió de terminals punt de venda, comerç
electrònic, producció per fases, traçabilitat, gestió de la qualitat, gestió de
la cadena de subministrament...). És molt possible que una empresa no
necessiti utilitzar, en un inici, tots els mòduls que facilita l’ERP, però és
important saber que l’ERP els contempla, de cara a possibles necessitats de
futur. En cas que sigui necessària la seva utilització, l’organització no es
veurà abocada a un canvi de programari en les àrees on ja estava utilitzant
l’ERP.
• És un sistema adaptable: no hi ha dues empreses iguals i, per això, els ERP

han de permetre l’adaptació a necessitats diverses, objectiu que s’assoleix
a través de la configuració i parametrització dels processos empresarials.
Fins i tot alguns ERP disposen d’eines de desenvolupament integrats que
permeten desenvolupar processos d’acord a les necessitats de cada empresa.
1.3.2 Funcionalitats dels sistemes ERP
Un ERP integra en un únic sistema tots els processos de negoci de l’empresa:

compravenda, producció, comptabilitat... Per una persona que mai hagi tingut
contacte amb un ERP o amb una aplicació de gestió empresarial, què vol dir això?
Ben segur que, si no s’ha interaccionat mai amb un ERP o aplicació de gestió,
s’ha de fer costa amunt entendre què vol dir “integra en un únic sistema tots els
processos de negoci”.
És important presentar, en un llenguatge entenedor per a persones no formades

en la branca administrativa-comercial, les funcionalitats que acostumen a facilitar
els programes de gestió empresarial. I ja que aquests materials estan adreçats a

informàtics, utilitzarem mots de l’argot informàtic.
El programari de gestió empresarial acostuma a estar presentat en apartats (menús)

que es corresponen bastant als mòduls instal·lats. A més, sempre hi ha uns apartats
bàsics, existents independentment dels mòduls instal·lats.
Administració o configuració
L’apartat d’administració o configuració és bàsic i és una opció a la qual només

tenen accés els usuaris administradors del producte i des de la qual s’ha de poder:
• Definir les dades de l’organització (nom, raó social, domicili fiscal, NIF...)
• Configurar els paràmetres de funcionament que permeti el programari

d’acord amb els requeriments de l’organització.
• Definir l’esquema de seguretat (usuaris, grups d’usuaris/rols i permisos

d’accés de les diferents opcions del programari als usuaris/rols).
El procés d’instal·lació acostuma a crear un usuari administrador que és el que

després podrà definir tot l’esquema de seguretat i també un conjunt de rols
predefinits.
Fitxers mestres: tercers i productes
En les aplicacions informàtiques el concepte de fitxer mestre s’utilitza per fer

referència a un conjunt de registres corresponents a un aspecte important dins
l’aplicació. Així, per exemple, en una aplicació de gestió podríem parlar del fitxer
mestre de clients, proveïdors, venedors, productes, pla de comptes i comandes,
albarans o factures de compra o venda. Per altra banda, es continua utilitzant el
mot fitxer, provinent de l’època en què les dades s’emmagatzemaven en sistemes
gestors de fitxers, malgrat que avui en dia les dades s’emmagatzemin en SGBD.
Tradicionalment, en el programari de gestió empresarial quan es parla de fitxers

mestres ens referim a les entitats client, proveïdors i productes, que existeixen
per si mateixes i per les quals es facilita un formulari de manteniment, que
normalment s’anomena fitxa del client, proveïdor o producte, des d’on gestionar
els corresponents registres. La resta d’entitats, a nivell informàtic, com per
exemple comandes, albarans i factures, no s’acostumen a incorporar en el paquet
dels fitxers mestres, perquè els seus registres no existeixen per si mateixos, sinó
que necessiten l’existència d’altres entitats, com els clients, els proveïdors i els
productes.
Darrerament hi ha ha una tendència a englobar clients i proveïdors en una entitat

anomenada tercers o interlocutors comercials. Això és a causa que un client de
l’organització pot ser a la vegada proveïdor i, en conseqüència, les seves dades
haurien d’estar duplicades en ambdós fitxers.
El concepte tercer és més genèric i engloba tots els ens amb els quals l’empresa
pot mantenir una relació: clients, proveïdors, empleats, bancs i qualsevol altre
tipus d’ens que pugui aparèixer. D’aquesta manera, si un empleat passa a ser, en
un moment donat, client no tindrà informació duplicada en el sistema.
El manteniment de tercers acostuma a ser un programa que conté una pantalla

principal que recull les dades principals del tercer (nom, NIF, domicili, telèfon,
correu electrònic...) i unes caselles de verificació per marcar-lo com a client,
proveïdor, empleat, banc, etc. Segons la manera que tingui activades les diferents
caselles de verificació, s’activen diferents pantalles per informar de les dades
necessàries, és a dir, si el tercer és marcat com a client, s’activa una pantalla
amb les dades específiques del tercer quan actua com a client (tarifa assignada,
domicilis d’enviament i de facturació, descomptes especials...) i de manera similar
si el tercer és marcat com a proveïdor o com a empleat, etc.
El fitxer d’articles o productes és l’altre fitxer mestre fonamental en el programari

de gestió empresarial. Què entenem per producte? Des del punt de vista del
programari de gestió empresarial, dins el fitxer de productes hi entra:
• Tot allò que l’empresa ven (bé o servei) i que hagi estat adquirit o produït
per l’empresa.
• Tot allò que l’empresa adquireix per poder satisfer les necessitats de
producció (primeres matèries).
En ocasions, algunes organitzacions també introdueixen en el fitxer de productes

els conceptes de despesa (electricitat, aigua, lloguers...) ja que utilitzen el circuit
de compra de l’ERP per introduir aquest tipus de despesa en l’aplicació comptable.
Observem que hi ha tipus de productes pels quals interessarà portar un inventari

i d’altres pels quals l’inventari no té sentit (serveis, despeses...). Per tant, la fitxa
d’un article o producte acostuma a incorporar una casella de verificació conforme
l’article és o no és inventariable.
Els articles s’acostumen a classificar, per poder obtenir estadístiques de compra,

venda i/o producció de forma agrupada. Així, és molt normal veure com els
ERP utilitzen conceptes com: categoria de producte, família de producte, grup
de producte, etc.
Els articles també acostumen a tenir una casella de verificació per ser marcats
com a article de compra, article de venda, article de consum en fabricació o bé
article de producció. Segons tingui activades les diferents caselles de verificació,
s’activen diferents pantalles per informar de les dades corresponents.
Una altra característica molt important i que no tots els ERP permeten és el poder
gestionar l’article sota diferents tipus d’unitats. Així, per exemple, és possible
que comprem l’article en litres i el venguem en quilos o que el tipus d’unitat a
utilitzar estigui en funció del client, en el cas de venda, o del proveïdor, en el cas
de compra.
Les existències mínimes i màximes que es desitgen tenir d’un producte al ma-
gatzem és també una dada fonamental. Per una banda, en articles amb molta
rotació pot interessar garantir una existència mínima, per tal de poder efectuar un
servei ràpid en cas de venda o utilització en cas de producció (matèria de consum
en processos de fabricació). I, per altra banda, pot interessar tenir assignada
una existència màxima a cobrir en el cas que l’estoc de l’article sigui inferior a
l’existència mínima. És molt interessant que l’ERP tingui mecanismes d’alerta
per detectar els productes que, a causa d’un moviment de sortida (venda, consum
de fabricació, regularització), passen a tenir un estoc inferior a l’existència mínima
indicada, així s’avisa al responsable per tal que iniciï el procés de reposició
que pertoqui (comprar-lo o fabricar-lo); el fet que l’article tingui assignada una
existència màxima, pot servir per indicar la quantitat a reposar. Un bon ERP hauria de
permetre gestionar
existències dels articles en
Molts ERP també contemplen, a títol informatiu a la fitxa del producte, les diversos magatzems i
indicar existències mínimes
quantitats pendents de recepció (comandes de compra), les quantitats pendents i màximes per a cada
magatzem.
de servir (comandes de venda), les quantitats pendents de consumir (en ordre
de fabricació on el producte intervingui com a primera matèria) i les quantitats
pendents de fabricar (quan es tracta d’un producte que fabriquen). Aquestes
quantitats, que mai són modificables per l’usuari i que, en cas d’existir, són només
de visualització, són redundants ja que els seus valors són calculables a partir de
comandes de compra, comandes de venda i ordres de fabricació, però el seu càlcul
és costós (implicaria fer un recorregut per totes les comandes de compravenda i
ordres de fabricació) i, per això, és possible que l’ERP les contempli a la fitxa
de producte i les actualitzi de forma automàtica en els processos de gestió dels
circuits de compravenda i fabricació.
Si la nostra organització gestiona productes peribles, cal que l’ERP faciliti un

control de lots, amb dates de caducitat. Això implica que per cada producte
perible que tenim en existència, cal saber els lots afectats, llur data de caducitat i el
nombre d’unitats de cada lot. Així mateix, cal mantenir la traçabilitat, controlant
els proveïdors i els clients implicats en la compravenda dels productes peribles.
Un tema similar a la gestió de lots, però sense data de caducitat ni necessitat de

saber l’existència de cada lot, és la gestió de números de sèrie, necessària segons
el tipus de producte que es comercialitzi. Els ERP han de facilitar també aquesta
gestió.
Codis de producte dels clients o proveïdors
La relació comercial que es té amb els clients o proveïdors acostuma a ser

la compravenda de productes del catàleg, però ben segur que la codificació i
denominació dels productes no té res a veure amb la codificació i denominació
dels mateixos productes pel client o proveïdor. En moltes ocasions, encara que
no sempre, es fa necessari, en la documentació que s’intercanvia amb el client
o proveïdor, incloure la codificació i denominació del producte per al client o
proveïdor.
Això implica que l’ERP ha de facilitar la possibilitat d’introduir, per als clients o
proveïdors que interessi, la codificació i denominació dels articles que ens compra
o ven. Normalment els ERP faciliten dos programes tal com mostra la figura 1.4.
F igu r a 1. 4 . Pantalles facilitades pels ERP per relacionar la nostra codificació d’articles amb la codificació
dels proveïdors o clients
Taules bàsiques
Les taules bàsiques són fitxers de pocs registres i amb poca volatilitat (es modi-
fiquen molt poc) que contenen definicions codificades de conceptes a utilitzar en
molts dels programes de l’ERP.
Alguns exemples de taules bàsiques són països, províncies, tipus de clients,

tipus de proveïdors, zones, idiomes, famílies de productes, grups de famílies,
magatzems, unitats de mesura, formes de pagament, tipus d’enviament, tipus de
comandes, sèries de facturació, formats d’impressió, fabricants, tipus de matèries,
La taula de grups de
famílies de productes etc.
permet tenir dos nivells de
catalogació de productes.
Els continguts d’aquestes taules, a banda de ser utilitzats en els diversos processos
informàtics de l’ERP (manteniments de fitxers mestres, circuits de compravenda,
processos de fabricació...) poden ser bàsics a l’hora d’obtenir resultats en els
processos d’intel·ligència de negoci, ja que són utilitzats per fer agrupacions.
Compres
L’apartat de compres comprèn els programes necessaris per cobrir el circuit de

compres: tarifes de proveïdor, comandes a proveïdor, recepció de mercaderia i
entrada de factura de proveïdor.
En referència a les tarifes de proveïdor, en moltes ocasions els proveïdors comu-

niquen les seves tarifes i per això interessa tenir-les introduïdes en el sistema
informàtic. Això suposa, en principi, una gran feina d’introducció de dades i

els ERP poden facilitar mecanismes per automatitzar la introducció de les tarifes
de proveïdor. Així mateix, el mòdul de tarifes de proveïdor hauria de poder
contemplar:
• Tarifes i/o descomptes especials en un interval de dates (ofertes).
• Tarifes i/o descomptes especials en funció de la quantitat de producte, definit

segons un escalat (a més quantitat, menor preu net o major descompte).
La gestió de comandes a proveïdors és un programa que ha de permetre introduir

en el sistema informàtic una comanda a proveïdor per tal de, una vegada introduïda,
fer-la arribar al proveïdor. La tecnologia ens permet, avui en dia, una vegada
la comanda ha estat enregistrada, enviar-la per correu electrònic o per fax al
proveïdor, sense necessitat d’arribar-la a imprimir en paper. L’ERP, en el procés de
generació de la comanda de compra, acostuma a proposar, per defecte, els valors
que tenim pactats amb el proveïdor i que resideixen a la seva fitxa (manteniment
de tercers – pestanya de proveïdors) i l’usuari simplement els haurà de validar.
S’ha de tenir en compte que el programa de gestió de comandes a proveïdors

modifica el camp quantitat pendent de rebre de la fitxa dels productes que
intervenen a la comanda, en el cas que la fitxa de producte contempli aquest camp
(alguns ERP el contemplen).
La recepció de la mercaderia és un programa que ha de permetre introduir en el

sistema informàtic la mercaderia que arriba a les nostres instal·lacions, fet que
queda registrat en un document anomenat, normalment, albarà de compra i que
ha de quedar associat al document que acompanya la mercaderia (albarà de venda
del proveïdor). El programa ha de ser suficientment versàtil per permetre:
• Recepcionar només una part de la mercaderia que havia estat demanada en

una comanda de compra (ja que pot ser que el proveïdor no enviï tot el que
s’havia demanat) i efectuar el tancament de la comanda malgrat no s’hagi
servit tota la quantitat demanada o deixar la comanda parcialment servida.
• Recepcionar mercaderia que hagi estat demanada en diferents comandes de

compra (al mateix proveïdor, és clar) i que el proveïdor la serveix en un
mateix lliurament.
• Recepcionar mercaderia que no hagi estat demanada en una comanda

de compra; aquesta situació no és gaire comuna i l’usuari que efectua
l’entrada hauria de tenir un protocol d’actuació en aquest cas –algú l’hauria
d’autoritzar.
• Localitzar qualsevol recepció de mercaderia efectuada a partir de l’identifi-

cador del document que l’acompanyava.
S’ha de tenir en compte que el programa de recepció de mercaderia modifica

l’estoc dels productes afectats en el magatzem on s’està produint l’entrada i també
modifica el camp quantitat pendent de rebre de la fitxa dels productes recepcionats
que provenien de la comanda, en cas que la fitxa del producte contempli aquest
camp (alguns ERP el contemplen).
L’entrada de factures de proveïdors és un programa que ha de permetre, de forma

molt ràpida, introduir una factura de proveïdor en el sistema informàtic. Ha de ser
suficientment versàtil per permetre:
• Introduir una factura de despeses o d’immobilitzat sense necessitat d’haver

introduït cap albarà previ.
• Introduir una factura de compra corresponent a un o diversos albarans de

compra (del mateix proveïdor, és clar) ja introduïts en el sistema informàtic.
• Rebre factures electròniques.
Vendes
Aquest apartat comprèn els programes necessaris per cobrir el circuit de vendes:
tarifes a clients, ofertes a clients, comandes de clients, lliurament de mercaderia i
facturació.
En referència a les tarifes de clients, el programa hauria de poder contemplar:
• Tarifes i/o descomptes especials en un interval de dates (ofertes).
• Tarifes i/o descomptes especials en funció de la quantitat de producte, definit

segons un escalat (a més quantitat, menor preu net o major descompte).
La gestió d’ofertes a client és un programa que ha de permetre introduir en

el sistema informàtic una oferta a client per tal de, una vegada introduïda i
enregistrada, fer-la arribar al client (via correu electrònic o per fax).
La gestió de comandes de clients és un programa que ha de permetre introduir

en el sistema informàtic una comanda de client que pot haver arribat per diversos
canals: telèfon, fax, correu electrònic, formulari d’una pàgina web... i que pot
respondre a una oferta prèviament enviada al client.
Factura proforma En ocasions, tant per les ofertes com per les comandes, els clients poden demanar
Una factura proforma és un
document basat en una oferta
la generació de l’anomenada factura proforma.
comercial amb la indicació
exacta que tindrà la factura final.
No té cap valor comptable ni A l’hora d’introduir la comanda de venda, l’ERP acostuma a proposar, per defecte,
com a justificant; s’utilitza
principalment en comerç
els valors que es tenen pactats amb el client, que es troben a la seva fitxa
internacional per obtenir
llicències d’importació, per
(manteniment de tercers – pestanya de clients). L’usuari simplement els haurà
obertura de crèdits documentaris de validar.
o per enviaments de mostres
comercials. Acostuma a incloure
la data màxima de validesa. S’ha de tenir en compte que el programa de gestió de comandes de client modifica
el camp quantitat pendent de servir de la fitxa dels productes que intervenen a la
comanda, en cas que la fitxa de producte contempli aquest camp (alguns ERP el
contemplen).
Si la comanda del client s’ha rebut per telèfon i no n’ha quedat constància
documental en la nostra organització és altament recomanable enviar-ne una còpia
(per fax o correu electrònic) al client per sol·licitar-li la seva conformitat escrita.
En canvi, si la comanda del client s’ha rebut amb un document del client, cal
registrar a la nostra comanda l’identificador de comanda del client per facilitar-ne
la localització davant de qualsevol incidència.
El lliurament de la mercaderia és un programa que ha de permetre generar les

sortides de material cap a clients, per donar resposta als requeriments de les
comandes. Normalment el sistema, a partir de les dates de lliurament existents
a les comandes de client i de les existències en el magatzem afectat, proposa una
preparació de comandes (picking, en anglès) a servir, tot generant un informe que
contempla tot el que es pot servir i també allò que no es pot servir. A partir d’aquí,
algun responsable pren les decisions que calguin i el sistema ha de permetre,
finalment, generar les sortides decidides. Cada sortida ha d’anar acompanyada
del corresponent albarà de sortida, també anomenat albarà de venda i, si el port el
realitza una agència de transport, és molt usual generar un albarà d’agència (s’ha
de tenir present que l’albarà de venda conté una relació detallada dels productes
–valorada o no– i l’agència de transport no té perquè ser-ne coneixedora, sinó que
només li cal saber el nombre de paquets, el pes i el volum).
El programa de lliurament de mercaderia modifica l’estoc dels productes afectats

en el magatzem on s’està produint la sortida i també modifica el camp quantitat
pendent de servir de la fitxa dels productes lliurats que provenien de la comanda,
en cas que la fitxa del producte contempli aquest camp (alguns ERP el contem-
plen).
El procés de facturació és un programa que ha de permetre, de forma molt ràpida,

la generació de les factures a client, ja sigui a partir de la comanda o de l’albarà
de lliurament. Hi ha ERP que obliguen, per poder generar una factura, a disposar
d’un albarà de lliurament de la mercaderia. Això suposa un mal de cap, ja que
en ocasions la factura cal generar-la una vegada la comanda de client ha estat
acceptada, independentment de si la mercaderia ha estat o no lliurada. Així doncs,
el procés de facturació ha de ser suficientment versàtil per permetre:
• Generar la factura a partir de la comanda amb la obligatorietat o no d’haver

servit la mercaderia (fet que ha de poder ser una característica de l’empresa
per a tots els clients o configurable a nivell de client o tipologia de client o
tipologia de comanda, etc).
• Generar factura per comanda o poder agrupar diverses comandes en una

factura o generar factura per una part d’una comanda (les parts servides,
per exemple).
• Generar les factures que superin un determinat import, ja que en ocasions no

surt a compte, per les despeses de cobrament associades a una factura (girs
bancaris, per exemple), generar factures d’import inferior a una determinada
quantitat i és millor esperar que el client efectuï més despesa per agrupar en
una sola factura diverses comandes del client.
• Contemplar diversos períodes de facturació (diari, setmanal, quinzenal,

mensual...) ja que hi ha organitzacions que pacten, amb cada client, els

períodes de facturació.
• Generar factures electròniques.
Fabricació
Un ERP, per definició, ha de permetre la gestió integrada de totes les àrees de

l’empresa i en cas que l’empresa tingui processos de fabricació l’ERP n’ha de
contemplar la seva gestió.
Els processos de fabricació són diferents en els diversos sectors productius i, en

conseqüència, es fa difícil disposar d’un mòdul de fabricació que s’adapti a tots.
Per aquest motiu, els fabricants d’ERP acostumen a facilitar solucions específiques
per a cada sector. A tall d’exemple:
• Sector de la moda, ja sigui tèxtil o calçat, on és imperatiu poder gestionar

paràmetres com temporades, talles o colors.
• Sector de l’alimentació, on és imprescindible la traçabilitat i el control de

lots en totes les fases de producció.
• Sector de fabricació de maquinària.
• Sector d’arts gràfiques.
No és el nostre objectiu entrar en els processos de fabricació específics de cada

sector. Podem, però, introduir els conceptes vinculats a un procés de fabricació
bàsic consistent en l’obtenció d’un producte a partir d’un seguit de components,
que poden ser adquirits a proveïdors com a primera matèria o bé ser fabricats
prèviament a l’empresa. Els conceptes que cal conèixer són llista de materials,
full de ruta i ordre de fabricació.
Una llista de materials (bom en anglès, de bill of materials), consisteix en

una llista dels components necessaris per a l’obtenció del producte final.
En els components podem incorporar:
• Articles definits en el fitxer mestre de productes, que poden ser primeres

matèries que adquirim a proveïdors o productes obtinguts en processos de
fabricació interns.
• Mà d’obra dels operaris.
Els components que formen la llista van acompanyats de les quantitats necessàries
per a la fabricació d’una determinada quantitat de producte final. En el cas que
els components apareguin en quantitats molt petites, les quantitats es basen en la
fabricació d’una quantitat superior a la unitat. La taula 1.1 mostra dos exemples
de llistes de materials: una basada en 1 unitat de producte final i l’altra basada en

100 unitats de producte final.
Les llistes de materials de la taula 1.1 són molt simples; en realitat les llistes de
materials acostumen a incorporar més dades, com per exemple:
• El codi de cada component, que hauria de ser obligatori, ja que la descripció

pot no ser suficient per identificar el producte.
• La possibilitat d’indicar, per a cada component, si la quantitat necessària

és fixa o és proporcional a la quantitat de producte final (cal pensar que en
ocasions, per una determinada fabricació, pot ser necessària una mà d’obra
de preparació o uns materials de preparació, la quantitat dels quals no depèn
de la quantitat de producte a fabricar).
Taul a 1. 1. Exemples de llistes de materials (bom)
Producte: Ordinador X Quant.: 1u. Producte: Adob CKT Quant.: 100 Kg.
Component Quant. Component Quant.
Font d’alimentació A 1 u. TPF-II Granular G-900 69 Kg.
Processador B 1 u. Carbonat sòdic dens 30 Kg.
Dissipador C 1 u. Detergal G4 Blue 1 Kg.
Placa base D 1 u. Hores operari cat. 3 0,3 h.
Memòria RAM E 2 u.
Disc dur SATA F 1 u.
DVD G 1 u.
Cable disc SATA 1 u.
Caixa H 1 u.
Cargols I 20 u.
Mà d’obra muntador 0,75 h.
Monitor J 1 u.
Teclat K 1 u.
Ratolí L 1 u.
Cable alimentació 2 u.
Un full de ruta (rate routing en anglès) incorpora les diferents fases

de fabricació d’un producte, amb les seccions o zones de la fàbrica que
participen a cada fase i amb les operacions de producció a efectuar a cada
fase.
Un ordre de fabricació és la concreció d’una fabricació d’un producte, amb

la quantitat de producte a fabricar, la data de fabricació i la línia de producció
a emprar.
Per gestionar les ordres de fabricació hi acostuma a haver tres processos:

• Planificació de l’ordre, moment en què s’introdueix en el sistema la quanti-

tat, la data i la línia de producció previstes. Aquest procés hauria de com-
provar, a partir de les dates de lliurament de les comandes de compravenda
pendents de recepció o lliurament i de les dates de les ordres de fabricació
planificades o en execució, la previsió d’existències dels components de
l’ordre planificada, avisant de les possibles ruptures d’estoc.
• Llançament de l’ordre, moment en el qual es reserven les quantitats necessà-

ries per procedir a la fabricació de l’ordre. Si l’ordre havia estat planificada,
canvia el seu estat de planificada a llançada.
• Regularització de l’ordre, moment en el qual s’informa al sistema de la

quantitat final de producte produït (que pot ser diferent de l’indicat en
la planificació o llançament) així com les quantitats finals de productes
consumits (que poden ser diferents dels previstos en la planificació o
llançament) i hores d’operari emprades.
Serveis
Hi ha organitzacions en les quals el seu negoci està basat en els serveis, com per
exemple, els serveis d’atenció tècnica (SAT), els serveis de consultoria, els serveis
de gestoria, etc.
En aquestes situacions, les empreses necessiten disposar d’un mòdul de serveis

que els permeti:
• Definir el servei amb les diferents fases, les hores d’operari de cada fase
(amb l’assignació de l’operari concret o simplement de la categoria d’ope-
rari que haurà de dur a terme la fase) i, si s’escau, els materials necessaris.
• Efectuar un seguiment de les hores i materials emprats a cada fase.
• En els serveis de llarga durada, cal poder controlar el cost del servei a
cada moment, per tal de detectar possibles desviacions respecte els costos
previstos inicialment.
A Internet es poden trobar
molts materials
introductoris referents a
comptabilitat. Als annexos Comptabilitat i finances
del web trobareu l’apartat
“On adquirir coneixements
de gestió empresarial?”
amb alguna recomanació. La presentació de les funcionalitats bàsiques dels ERP que fan referència a fitxers
mestres, taules de suport, compres, vendes, producció i serveis es pot dur a terme
Una vegada coneguda la utilitzant un llenguatge no gaire tècnic.
teoria de les principals
funcionalitats que ens
hauríem de trobar en un El mòdul de comptabilitat i finances ja no és tan fàcil d’introduir si no es tenen
ERP, convé tenir un primer
contacte amb els ERP coneixements al respecte i no és l’objectiu d’aquest material introduir-lo. Els
actuals. Als annexos del
web trobareu l’apartat tècnics informàtics programadors que hagin d’adequar un ERP a les necessitats
“Actualitat del programari
de gestió empresarial” de l’empresa, desenvolupant-hi mòduls específics o utilitzant eines BI per obtenir
que presenta els
principals ERP del mercat informació per als responsables de l’empresa, han de tenir uns coneixements
amb enllaços a vídeos en
els quals se’n mostra el mínims de comptabilitat i finances per poder donar resposta a les necessitats que
funcionament. sorgeixin en aquest àmbit.
1.3.3 La llegenda de la implantació dels ERP
“If it’s not broken, don’t fix it” diuen els anglosaxons, en una frase que podria
traduir-se a si funciona, no ho toquis i que en l’àmbit de la implantació d’ERP
s’acostuma a sentir molt sovint.
Les empreses li tenen por, per no dir pànic, a un canvi en el seu programari de
gestió empresarial, sigui o no ERP, i no els falta raó, ja que se sent parlar molt
d’experiències negatives.
Les 10 raons que apareixen constantment com a provocadores dels fracassos de

les implantacions d’ERP són:
1. Els processos de negoci de l’organització no han estat ben definits.
2. La implantació ha estat més llarga del que s’havia planificat.
3. Els costos de la implantació han estat més alts dels planificats.
4. Les activitats prèvies a la implantació van ser deficients.
5. El personal de l’organització no està capacitat.
6. La previsió d’utilització va ser massa ambiciosa.
7. No hi ha hagut una metodologia clara d’implantació.
8. La recepció d’informació o requeriments per part dels usuaris no va ser

completa.
9. No hi ha hagut el suport adequat per part dels responsables de l’organització.
10. No s’han gestionat adequadament les relacions interpersonals.
La implantació d’un ERP en una organització sobrepassa les responsabilitats

dels tècnics que efectuen la implantació tècnica de l’ERP i dels programadors
que l’adapten a les necessitats de l’organització, però tècnics i programadors es
trobaran enmig d’implantacions i és convenient que tinguin coneixement de les
bones pràctiques.
L’anàlisi dels problemes que provoquen el fracàs de la implantació d’un ERP ajuda
a definir els punts a tenir en compte per aconseguir una bona implantació. Hi ha
nombrosos estudis al respecte i, encara que tots volen el mateix (aconseguir una
bona implantació), no tots defineixen el mateix nombre de punts a tenir en compte.
Com que el mot decàleg, a banda d’indicar 10 punts, connota un conjunt de punts
bàsics per al desenvolupament d’una activitat, intentarem recollir en un decàleg
adreçat als dirigents de l’organització on implantar un ERP els punts clau a tenir
en compte:
1. Començar a treballar amb temps. En el moment en què es comença a

intuir que el programari actual té deficiències que no es poden solucionar i
que poden derivar en problemes greus, cal posar fil a l’agulla i començar
la cerca d’un nou programari. Això implica analitzar les operacions de
l’organització, la informació que es gestiona i els sistemes d’informació
existents, amb els punts forts i els punts febles, documentant tot el procés.
És altament recomanable que aquest procés l’efectuï algú extern a l’empresa,
ja que l’experiència diu que el dia a dia no facilita que aquest estudi el
desenvolupi gent interna.
2. Escollir l’ERP adequat a l’organització. Per fer-ho, cal cercar bé en

el mercat i escoltar totes les opcions possibles, tant les de programari
propietari com les de codi obert. L’organització que vol adquirir un ERP
és especialista en el seu negoci i no pot pretendre ser-ho en ERP i, per tant,
ha de confiar directament en els distribuïdors o en l’equip que hagi efectuat
l’estudi del punt anterior. Convé avaluar, com a mínim, tres programaris
alternatius, exigint una demostració específica per al nostre negoci i, per a
cada programari i si és factible, convé avaluar dos distribuïdors diferents,
valorant l’equip humà i el desplegament de medis que utilitzen en la
implantació. És interessant considerar la possibilitat de mantenir els serveis
de l’equip extern que hagi desenvolupat el punt anterior en tot el procés per
tal que serveixi d’interlocutor entre l’organització i els distribuïdors.
3. Esprémer al màxim la fase de tracte comercial. En aquesta fase, l’empre-

sa candidata a implantar l’ERP té total disponibilitat. Una vegada signat el
contracte, malgrat que el tracte continuï sent correcte, s’ajusten a allò que
s’ha signat i, en conseqüència, cal haver dedicat molt de temps a comprovar
que les funcionalitats del programa s’ajustin als nostres requeriments. En
cas de detectar funcions essencials no suportades és altament recomanable
cercar un altre programari que s’hi adeqüi millor. Cal tenir en compte que
les adaptacions en un ERP són molt costoses i no sempre factibles i, per tant,
és fonamental l’elecció de l’ERP adequat.
4. Repassar molt bé el contracte, en especial l’abast del treball. L’empresa

implantadora acostuma a ser implacable a l’hora de facturar qualsevol cosa
no prevista en el contracte i sempre tenen la paella pel mànec, ja que són
els únics que saben la veritat del que hi ha al davant. Per això cal tornar a
comentar que és molt interessant mantenir els serveis de l’equip extern que
ha participat en el punt 1 com a interlocutor entre l’organització i l’empresa
implantadora. El treball a desenvolupar ha d’incorporar, amb molt detall,
els processos de formació de personal, punt molt important per aconseguir
l’èxit de la implantació.
5. Abans de signar, cal assegurar-se que la solució adquirida cobreix

el 100% dels requeriments. De fet, això és conseqüència del que s’ha
comentat en el punt 3, però en ocasions hi ha funcionalitats cobertes per
mòduls que es comercialitzen a banda i, és clar, ningú no ens ha enganyat
perquè l’ERP ho cobreix a través d’un mòdul addicional; el problema
apareix si no forma part del programari adquirit. En especial, cal tenir molt
en compte l’apartat relatiu a la intel·ligència de negoci (BI) per tal de poder

accedir a la informació i generar informes i quadres de comandament.
6. Disseny adequat del maquinari necessari. La plataforma de maquinari

sobre la qual s’ha de basar el funcionament informàtic de l’empresa és
suficientment important com per dedicar-hi un estudi específic i valorar
totes les solucions. Els departaments de sistemes de les empreses a vegades
poden ser recelosos al canvi i sentir-se incòmodes amb noves plataformes
que no dominen. Això no hauria de ser un problema si el canvi de plataforma
ha de suposar un estalvi important i fiabilitat i rendiment iguals o millors.
7. Solvència del procés d’implementació: equip i metodologia. Cal conèi-

xer la solvència de l’equip que durà a terme la implantació: qui formarà
l’equip i quantes implantacions del programari han efectuat en empreses
del mateix sector o amb funcionalitats similars. Així mateix és fonamental
conèixer la planificació i metodologia que es seguirà i assumir-la per tal
d’aconseguir l’èxit en el menor temps possible.
8. Mínimes modificacions al programa. Ja hem indicat abans que han

de ser les mínimes indispensables i, en ocasions, és preferible, si és
possible, canviar l’operativa de l’empresa per adequar-la al funcionament
del nou programari, abans que entossudir-se en unes modificacions que
poden provocar problemes de rendiment i, fins i tot, problemes amb les
actualitzacions del programari.
9. Màxima atenció als usuaris. Una implantació d’ERP pot suposar un xoc
pels usuaris, que hauran de canviar de pantalles i, en molts casos, la forma
de fer les coses. Per tant, cal aconseguir la màxima col·laboració dels
usuaris, havent-los fet participar en els processos de preimplantació (anàlisi
de les operacions que s’efectuen i informació que es gestiona i anàlisi dels
productes candidats). Una vegada iniciada la implantació, han de rebre la
formació i acompanyament adequats.
10. Dedicació directiva a la implantació. Durant el procés d’implantació,

l’empresa ha de destinar al projecte recursos de primer nivell en termes
de temps de l’alta direcció. És essencial un gerent de projecte de primera
línia directiva, amb capacitat analítica, visió de negoci, resolutiu i amb
interlocució en totes les àrees funcionals de l’empresa. És imprescindible
la disponibilitat de la direcció general per l’adopció de decisions que li
han d’arribar mastegades i, en conseqüència, és molt convenient el suport
de recursos externs independents que aportin experiència i suport (els que
havíem comentat en el punt 1 del decàleg i que haurien d’acompanyar-nos
en tot el procés).
Aquest decàleg està adreçat als dirigents de l’organització en la qual s’ha d’implan-
tar l’ERP. El tècnic informàtic que està llegint aquests materials no acostumarà a
ser dirigent de l’organització, però convé que en sigui coneixedor ja que:
• Pot formar part del departament TIC de l’organització on implantar l’ERP.
• Pot formar part d’un equip d’implantació de l’ERP.

• En petites empreses, pot haver esdevingut el cap del departament TIC i pot
haver d’erigir-se en el responsable intern de la implantació.
Fixem-nos que els punts del decàleg es poden agrupar en tres fases:
1. Anàlisi
2. Plantejament i disseny
3. Implantació
Un cop tenim l’ERP implantat i en funcionament amb total èxit cal passar
a una quarta fase:
4. Postimplantació
Les necessitats de les empreses evolucionen constantment i els ERP també ho

fan. En conseqüència, a l’organització que ha implantat un ERP li convé anar
actualitzant-lo a partir de les actualitzacions que facilita el fabricant. Això nor-
malment s’articula a partir de contractes de suport o manteniment postimplantació
amb l’empresa que ha efectuat la implantació.
El contracte de suport o manteniment, de pagament periòdic, pot incorporar:
• Conjunt d’hores de suport a preu zero o reduït.
• Per les hores que sobrepassin el conjunt anterior, descompte sobre el preu
de venda.
• Accés als pegats i actualitzacions de l’ERP facilitats pel fabricant.
• Processos d’instal·lació de pegats i actualitzacions a preus especials.
1.3.4 Els ERP a les PIME
Fins fa uns anys, els grans fabricants d’ERP dirigien els seus productes a grans
empreses i el mercat de les PIME quedava per a fabricants d’aplicacions de gestió
(moltes vegades suite) que cobrien les necessitats de l’empresa sense que el seu
producte pogués ser catalogat com un ERP. De fet en parlar d’un ERP es tendeix
a pensar en un sistema desenvolupat per a la gran empresa i amb un cost excessiu
Consulteu l’apartat “Els per a la PIME, tant en l’econòmic del producte com en el d’implantació.
ERP a les PIME” dels
annexos del web.
Aquesta situació s’ha vist alterada en els darrers anys, en el quals els grans
fabricants d’ERP han dirigit la seva mirada cap a les PIME i els ofereixen versions
dels seus productes.
1.4 Sistemes CRM i solucions BI, complements dels ERP?
Recordem les definicions de sistemes ERP, sistemes CRM i solucions BI.
• Els sistemes ERP, com a programari de gestió integrada, integren totes les
dades i processos d’una organització en un sistema unificat.
• Els sistemes CRM donen suport a la gestió de les relacions amb els clients,
a la venda i al màrqueting.
• Les solucions BI són eines destinades a facilitar dades als dirigents em-
presarials, obtingudes a partir de les dades dels sistemes ERP-CRM, amb
l’objectiu de facilitar la presa de decisions.
Segons la definició d’ERP, aquests sistemes integren totes les dades i processos de
l’organització i, en conseqüència, han d’incorporar la gestió de les relacions amb
els clients (CRM) i podrien incorporar eines d’intel·ligència de negoci. Per tant,
una organització amb ERP no s’hauria de plantejar la implantació de CRM i de
solucions BI.
La majoria d’ERP actuals incorporen un mòdul de CRM que en alguns casos

forma part de la base de l’ERP i en altres és un mòdul optatiu. Llavors, per què
existeixen sistemes CRM que es comercialitzen independentment dels ERP? Qui
els adquireix? Trobem la resposta en el fet que:
• Hi ha sistemes CRM que potser faciliten més funcionalitats que el mòdul

CRM incorporat per l’ERP i l’organització precisa d’aquestes funcionali-
tats.
• Hi ha empreses que en lloc de tenir ERP disposen de diversos programes de

gestió empresarial i els convé poder adquirir un CRM.
La implantació d’un CRM independent del programari de gestió comporta tenir

dades duplicades en els dos sistemes (clients, ofertes, comandes, vendes, produc-
te...) i, per minimitzar la duplicitat de l’entrada de dades i les incoherències,
s’estableixen connexions amb la base de dades de l’ERP o del programari de gestió
per tal d’alimentar la base de dades del sistema CRM.
Pel que fa a les solucions BI, els ERP actuals també incorporen eines que permeten
obtenir informes per analitzar i que acostumen a formar part de la base de l’ERP.
Però per segons quin tipus d’informe o anàlisi a efectuar és possible que el mòdul
BI integrat a l’ERP encara no en faciliti l’adequada funcionalitat, tot i que molt
probablement els ERP aniran evolucionant en la línia de la solució total. Així
doncs, actualment és força usual adquirir una solució BI per obtenir resultats
complementaris a la informació que facilita l’ERP.
Hi ha solucions BI que treballen directament amb la base de dades del programari

de gestió comercial, però en moltes ocasions s’utilitza un magatzem de dades
(data warehouse) on prèviament s’ha bolcat les dades a analitzar, en un format

intel·ligent per facilitar les anàlisis previstes. Així, per exemple, per analitzar les
vendes efectuades per tipus de producte i tipus de clients en els diferents mesos
comparant els darrers tres anys, s’obtindrà uns resultat més ràpids si es disposa
dels imports de venda agrupats per tipus de producte, tipus de client i mesos
i anys, en lloc d’haver d’efectuar aquestes agrupacions cada vegada que es vol
executar l’anàlisi comparativa. Certament, el fet de treballar amb magatzems de
dades implica redundància de dades ja que el seu contingut és calculable a partir
de les dades existents en la base de dades del programari de gestió comercial, però
l’estalvi de procés de dades és tan gran, que està àmpliament justificat.
Per tot això es pot respondre afirmativament a la pregunta que encapçala aquest
apartat: els sistemes CRM i les solucions BI són companys de viatge dels ERP.
1.4.1 Funcionalitats dels sistemes CRM
L’acrònim CRM s’utilitza indistintament, per a dos conceptes:
1. CRM com a estratègia de negoci de l’organització focalitzada en el client,

consistent en centrar els esforços en el coneixement dels clients, detectant
les seves necessitats amb l’objectiu d’augmentar el seu grau de satisfacció,
d’incrementar la fidelitat a l’organització i d’incrementar la rendibilitat o
beneficis del client a l’organització.
2. CRM com a sistema informàtic ideat perquè l’organització pugui adminis-

trar tots els aspectes vinculats amb la gestió dels seus clients, de manera que
un sistema CRM pot incloure de tot, des de tecnologia per recollir dades de
les trucades telefòniques de l’àrea de vendes fins a llocs web on els clients
tinguin accés als nostres productes (i quedi constància de les visites i del que
hi han fet), incorporant-hi tota la informació provinent del circuit de venda
del programari de gestió empresarial.
El nostre objectiu és conèixer el CRM com a aplicació informàtica, que ha de

permetre assolir l’estratègia CRM adoptada per l’organització. Normalment, en
un sistema CRM hi trobem els següents mòduls:
1. Mòdul de clients: permet introduir els clients de l’organització. Si el CRM

forma part de l’ERP el mòdul de clients coincideix amb el mòdul de l’ERP
i, com a molt, incorpora més camps propis de la gestió del CRM, però no es
produeix cap duplicitat de dades. En cas d’un sistema CRM independent, la
situació més usual és que l’organització ja disposi d’un programari de gestió
empresarial (sigui o no ERP) des d’on s’efectuen les vendes a clients i, en
conseqüència, aquest mòdul suposa una duplicitat de dades, necessària per
poder executar les funcionalitats que aporta el CRM. En aquestes situacions,
per minimitzar la possibilitat d’errors i mantenir al dia els fitxers de clients
d’ambdós programaris (gestió comercial i CRM), s’acorda gestionar els
clients sempre a través d’un dels dos programaris i s’implementa un traspàs

d’informació cap a la base de dades de l’altre programari, que s’hauria
d’executar en temps real i, en el pitjor dels casos, automatitzar-ne l’execució
a intervals regulars.
2. Mòdul de clients potencials: permet introduir les persones o organitzaci-

ons que representen alguna oportunitat de ser futurs clients.
3. Mòdul de contactes: permet gestionar les persones o organitzacions

associades a un client (real o potencial) amb les quals l’organització es
comunica amb la intenció de generar una oportunitat de negoci amb el
client.
4. Mòdul de productes: permet gestionar els articles susceptibles de ser

venuts. De la mateixa manera que amb el mòdul de clients, en el cas d’un
sistema CRM independent es produeix una duplicitat amb els productes de
l’aplicació de gestió empresarial de l’empresa.
5. Mòdul de suport: ha de permetre recollir tots els contactes entre l’or-

ganització i els clients (reals o potencials), sigui quin sigui el canal pel
qual s’estableixin (telefònic, correu electrònic, fax, visita comercial, estand
d’una fira, visita identificada al lloc web...), tot enregistrant els detalls del
contacte i les possibles accions pendents d’executar arran del contacte, amb
la data, el responsable i el contingut.
6. Mòdul d’informes i gràfics: per ajudar l’organització a obtenir informes

personalitzats, per ajudar a prendre decisions oportunes de negoci. Aquest
mòdul no deixa de ser una solució BI per al CRM.
Els CRM independents aporten, també, els mòduls que faciliten les accions
pròpies del programari de gestió comercial i que són necessàries de controlar per
poder tenir tota la informació al voltant dels clients. Per això, la llista de mòduls
anteriors es pot veure ampliada amb:
1. Mòdul d’ofertes.
2. Mòdul de gestió de comandes de venda.
3. Mòdul de gestió d’ordres de lliurament.
4. Mòdul de facturació.
En cas de tenir implantat un sistema de gestió empresarial, de la mateixa manera

Als annexos del web
que amb els clients i els articles, cal alimentar la base de dades del CRM amb la trobareu l’apartat “Presa
de contacte amb sistemes
informació bàsica d’ofertes, comandes, enviaments i factures efectuades a través CRM” que ens dóna a
del sistema de gestió empresarial, per tal de disposar en el CRM de tota la conèixer alguns dels
productes CRM més
informació i poder obtenir informes adequats. utilitzats i hi ha
presentacions que ens
mostren les principals
Així doncs, per no veure’ns obligats a tenir duplicitat de dades a l’ERP i al CRM, funcionalitats d’un CRM.
s’imposa que els ERP incorporin el mòdul de CRM.

1.4.2 Funcionalitats de les solucions BI
Els sistemes ERP, CRM, HRM (Human Resource Management) són alguns dels
innumerables tipus d’aplicacions implantades a les empreses, que es troben, en
moltes ocasions, en plataformes diferents. A totes aquestes se sumen els docu-
ments impresos, arxius de diverses eines ofimàtiques, etc. cosa que converteix
l’organització en un mar d’informació en el qual és difícil de trobar aquella que és
determinant a l’hora de prendre decisions per al negoci. A vegades, pitjor que no
tenir informació és tenir-ne molta.
La intel·ligència de negoci (BI) s’endinsa en la informació de l’organització

amb l’objectiu de generar escenaris, pronòstics i informes que són
subministrats als responsables de la presa de decisions.
Una aproximació de les àrees més comunes on s’apliquen les tècniques de la

intel·ligència de negoci són:
• Vendes: anàlisi de vendes, detecció de clients importants, anàlisi de

productes i tipus de productes, anàlisi de mercats, pronòstics i projeccions.
• Màrqueting: segmentació i anàlisi de clients, seguiment dels nous produc-

tes.
• Finances: anàlisi de despeses, rotació de cartera, raons financeres.
• Fabricació: productivitat de les línies de fabricació, anàlisi de residus,

anàlisi de qualitat, rotació d’estoc, parts crítiques.
Per altra banda, en les organitzacions acostuma a existir una jerarquia que
determina el tipus d’accions que es realitzen dins d’ella i, en conseqüència, el tipus
de decisions que s’han de prendre. Tradicionalment s’han establert tres nivells
jeràrquics:
1. Estratègic, en el qual la directiva decideix el camí que ha de seguir

l’organització.
2. Tàctic, en el qual la gerència organitza i planifica les diverses àrees de

l’empresa conjuntament amb els corresponents caps (màrqueting, vendes,
finances, fabricació).
3. Operatiu, en el quals’executen les operacions quotidianes de l’organització

(diàries i rutinàries): operacions dels circuits de compravenda i fabricació i
operacions comptables i financeres.
Aquests model tradicional de tres nivells s’ha vist ampliat darrerament per l’arriba-
da de les TIC, amb un quart nivell que s’ubica entre el tàctic i l’operatiu, anomenat
el nivell del coneixement, en el qual ubiquem tots els professionals que afegeixen
valor a l’empresa per mitjà de les seves habilitats en les TIC.
Els diferents nivells, que també podríem anomenar rols, tenen diferents necessitats
d’accés a les dades (el director general no té perquè conèixer com s’introdueix en
el sistema una oferta a client i en canvi sí que pot necessitar conèixer si s’està
assolint els objectius de vendes per a l’exercici actual, mentre que la situació és
totalment inversa per a un auxiliar administratiu del departament comercial). Els
actors de tots els nivells necessiten informes, però la complexitat d’elaboració
és molt diferent (l’auxiliar del departament comercial pot necessitar un simple
llistat de les ofertes diàries, mentre que el director general necessita gràfiques
que pugui visualitzar des de diferents dimensions). Per tant, es necessiten eines
informàtiques per elaborar informes adequats per a tots els nivells i la complexitat
de les eines és molt diferent segons el nivell al qual han de servir.
F igur a 1.5 . Correspondència entre els nivells de l’empresa i els tipus de sistemes de gestió de la
informació
La figura 1.5 mostra la correspondència entre els nivells jeràrquics d’organització

d’una empresa i els tipus de sistemes de gestió de la informació normalment
emprats, tenint en compte les necessitats d’informació de cada nivell. El contingut
de la figura 1.5 no s’ha de prendre al peu de la lletra; és a dir, els actors dels nivells
estratègic i tàctic poden utilitzar informes facilitats pels sistemes OLTP i els actors
del nivell del coneixement poden també utilitzar algun informe proporcionat per
les eines BI externes als sistemes OLTP.
La figura 1.5 incorpora conceptes (OLTP, data mining, data warehouse) que hem
de reconèixer juntament amb d’altres que estan vinculats al món BI: ETL, OLAP,
KPI, data mart, dashboard i cubs multidimensionals.
Una eina BI ha de ser capaç de reunir informació dispersa per tota la companyia i,
fins i tot, de diferents fonts, per tal de proporcionar als departaments l’accessibili-
tat, poder i flexibilitat necessaris per analitzar la informació. La figura 1.6 mostra
tots els components que poden intervenir en una solució BI. La part esquerra de
la figura mostra els diversos orígens de dades d’on pot provenir la informació que
la solució BI reunirà en el repositori de la solució.
F igu r a 1. 6 . Components d’una solució BI completa
OLTP és l’acrònim anglès de Procés de Transaccions En Línia (OnLine

Transaction Processing) per fer referència als sistemes que faciliten i administren
aplicacions transaccionals, com és el cas dels ERP-CRM en els quals contínua-
ment s’efectuen transaccions.
El repositori de la solució BI és el lloc centralitzat on la solució BI emmagatzema

les dades recollides dels diversos orígens de dades, principalment de sistemes
OLTP. En el repositori d’una solució BI hi podem distingir dos tipus de compo-
nents: data warehouse (sempre present) i cubs multidimensionals (presents si la
solució BI facilita l’anàlisi OLAP).
Un data warehouse (magatzem de dades) és una base de dades destinada a contenir

una col·lecció de dades orientada a un determinat àmbit (empresa, organització,
matèria...), integrada, no volàtil i variable en el temps, que ha de servir de base
per a l’aplicació d’eines analítiques amb l’objectiu d’obtenir informació útil per a
la presa de decisions. És a dir:
• Orientada a un àmbit: les dades contingudes estan organitzades de manera

que tots els elements relatius a un mateix esdeveniment del món real queden
relacionats.
• Integrada: conté les dades de tots els orígens de dades possibles, de forma
consistent.
• No volàtil: la informació introduïda no es modifica ni elimina, és informa-

ció de només lectura que es manté per a futures consultes.
• Variable en el temps: els canvis produïts en les dades al llarg del temps hi
queden registrats per tal que els informes puguin reflectir les variacions.
Un dels principal problemes a l’hora d’implementar un data warehouse, radica en

què les dades a integrar, en provenir d’orígens diversos, presenten inconsistències
en format i codificació i això implica la necessitat de dissenyar un procés de

filtrat, reestructuració de les dades i eliminació d’inconsistències abans de ser
emmagatzemades en el data warehouse. Aquest procés és conegut com a ETL,
acrònim de Extract, Transform and Load.
La taula 1.2 mostra les principals diferències entre les bases de dades dels sistemes
OLTP, dedicades a les operacions del dia a dia, i un data warehouse, dedicat a
concentrar informació completament orientada a l’anàlisi.
Taul a 1. 2. Comparació entre les BD dels sistemes OLTP i els data warehouse
BD de sistemes OLTP Data warehouse
Dades operacionals Dades del negoci rellevants per informació
Orientada a les aplicacions Orientat a l’analista
Dades actuals Dades actuals + dades històriques
Dades al detall Dades resumides amb cert detall
Canvia constantment Estable
El data warehouse pot estar organitzat en data marts. Un data mart (aparador de
dades) és un subconjunt de dades del data warehouse, corresponent a una unitat
de negoci (àrea) de l’organització. Té l’objectiu de solucionar la problemàtica
d’anàlisi de la corresponent àrea.
Un data warehouse es pot considerar com la col·lecció de data marts implementats

en les diferents àrees de negoci de l’organització.
Les solucions BI aporten eines analítiques i la potència d’una solució BI es mesura

a partir del nombre d’eines analítiques que facilita i de la potència de cadascuna
d’elles.
Avui en dia les eines analítiques es tipifiquen en: query&reporting, data mining,
KPI i anàlisi OLAP.
Les eines query&reporting (consultes i informes) són les tradicionals eines que
permeten dissenyar i executar consultes sobre una base de dades i formatar el
resultat en informes. La figura 1.6 mostra que aquestes eines s’apliquen sobre
les bases de dades del sistemes OLTP i sobre el data warehouse i data marts.
La majoria de sistemes OLTP (ERP, CRP...) faciliten eines query&reporting de

fàcil aprenentatge que un usuari avantatjat pot utilitzar per dissenyar els informes
que necessita i que no estan predefinits en el sistema. Query&reporting ofimàtic
Les bases de dades ofimàtiques
s’utilitzen en moltes ocasions
Les eines data mining (mineria de dades) són eines d’alt nivell que sobrepassen com a eines query&reporting
dels sistemes OLTP i data
l’objectiu d’aquest material. A títol informatiu cal saber que la mineria de dades warehouse, a través de la
consisteix en l’extracció no trivial d’informació que resideix de manera implícita connexió ODBC amb les BD del
sistema OLTP o data warehouse.
en les dades, que era prèviament desconeguda i que pot resultar útil per algun
procés. En altres paraules, la mineria de dades prepara, sondeja i explora les dades
per obtenir informació oculta en elles.
OLAP és l’acrònim anglès de Procés Analític en Línia (OnLine Analytical

Processing) per fer referència als sistemes que emmagatzemen grans quantitats de
dades resumides obtingudes a partir de sistemes OLTP, amb l’objectiu d’efectuar-

ne consultes.
El concepte OLAP va molt lligat al concepte data warehouse i en ocasions es

confonen. La diferència radica en què data warehouse és un terme que s’utilitza
per fer referència a les dades i OLAP és un concepte que s’utilitza per fer referència
a les eines disponibles per avaluar i analitzar les dades dels data warehouse.
En parlar d’anàlisi OLAP apareixen els cubs multidimensionals o cubs OLAP

o hipercubs. Un cub multidimensional és una representació matricial (N
dimensions) de les dades planes representades via files i columnes en una taula
relacional, utilitzat en l’anàlisi OLAP.
Exemple simplificat de construcció de data warehouse i hipercub
La base de dades d’un ERP (suposem BD relacional) segurament té una taula on

s’enregistren les vendes que s’efectuen. Suposem el disseny següent:
1 VENDA (#Client, #Producte, #Data, Quantitat, PreuUnitari)

2 ON {Client} REFERENCIA CLIENT
3 I {Producte} REFERENCIA PRODUCTE
Els dissenyadors del data warehouse han decidit que a nivell d’anàlisi no interessa mantenir
el client, ni el producte ni la data però sí que es necessita incorporar el tipus de client, la
família de producte i el mes i any en què s’ha efectuat les vendes. Per tant, en el data
warehouse s’ha dissenyat la taula següent, que agrupa les quantitats i la mitjana dels preus
de venda:
1 VENDA_DW(#TipCli, #FamPro, #MesAny, SumQuantitat,

2 AVGPreu)
El procés ETL que emplena la taula VENDA_DW es preocupa de cercar totes les
vendes del període que correspongui, agrupant-les per tipus de client, família de
producte i mes o any, tot sumant les quantitats de producte venudes i calculant la
mitjana dels preus aplicats.
Amb aquest disseny, dins el data warehouse s’ha perdut la informació de detall
de client, producte i data de venda. És a dir, s’ha disminuït la granularitat i, en
conseqüència, l’anàlisi basada en el data warehouse podrà donar resultats a nivell
de tipus de producte, tipus de clients i intervals mensuals, però no pas a nivell de
client, de producte i de data de venda. Si en el data warehouse s’hagués decidit
emmagatzemar les dades en una estructura similar a la de la taula VENDA del nostre
ERP, l’eina d’anàlisi tindria majors possibilitats analítiques, ja que podria analitzar
les dades a nivell de detall i també als nivells del resum que facilita VENDA_DW però
per fer això és necessari més espai en el data warehouse.
En terminologia de BI, la taula VENDA és una taula de fets (enregistra els fets que
s’han produït) i la taula VENDA_DW és una taula agregada de fets. Les anàlisis a
nivell resum s’executaran més ràpidament si disposem en el data warehouse de
taules agregades de fets adequades al resum que cal analitzar. No és gens senzill
decidir quines dades s’emmagatzemen en el data warehouse i amb quin nivell de
granularitat.
Les dades de la taula VENDA_DW ens permeten construir diversos cubs muldimen-
sionals, en els quals els atributs per analitzar es representen en els diversos eixos
(dimensions) del cub.
Així, si volem analitzar la quantitat de vendes per tipus de producte, tipus de client
i mesos, podem construir el cub tridimensional de la figura 1.7. Observem que en
el punt v hi haurà el valor corresponent a la quantitat de venda del tipus de producte
tp efectuada per clients del tipus tc en el mes m.
F ig ur a 1. 7. Exemple de cub OLAP tridimensional
És molt comú que la informació del data warehouse s’estructuri en cubs multi-
mensionals, ja que aquests preparen la informació per respondre a consultes dinà-
miques amb un bon rendiment (temps de resposta). Els cubs multidimensionals
no són, però, les úniques estructures de dades que utilitzen els data warehouse.
Per tal de facilitar el disseny de consultes OLAP, a causa que el llenguatge

SQL obligava a escriure consultes complexes, es va crear el llenguatge MDX
(MultiDimensional Expressions) que està pensat específicament per a efectuar
consultes sobre cubs OLAP i, per tant, les consultes són molt més simples que
les corresponents en el llenguatge SQL. El llenguatge MDX ha estat acollit per la
majoria de proveïdors d’eines OLAP.
Per finalitzar amb la percepció dels conceptes més utilitzats al voltant de les solu-
cions BI, apareguts tots ells en la figura 1.6, ens manca presentar els dashboards
i els KPI.
KPI és l’acrònim anglès d’Indicadors Claus d’Acompliment (Key Performance

Indicators) per fer referència a mètriques utilitzades per quantificar els objectius
que reflecteixen el rendiment d’una organització i que generalment es recullen en
el seu pla estratègic. Als annexos del web
trobareu l’apartat “Presa
de contacte amb
Els responsables de l’organització tenen per dogma que “no es pot millorar allò solucions BI” que ens
dóna a conèixer alguns
que no es pot mesurar”. En conseqüència, l’organització defineix el conjunt de dels productes BI més
utilitzats i ens facilita
KPI importants per a la seva evolució i per fer-ne un correcte seguiment es fa presentacions que ens
mostren les principals
necessari disposar de quadres de comandament o dashboards. funcionalitats d’una
solució BI.
Un dashboard és un tipus d’interfície interactiva d’usuari, dissenyada per propor-

cionar a l’usuari informació específica relativa a l’estat de l’empresa, representada
normalment a través d’indicadors clau d’acompliment (KPI) i enllaços a informes
rellevants. Existeixen senyals visuals, gràfics i controls de procés que centren
l’atenció de l’usuari en les tendències, canvis i excepcions importants.
Hem d’imaginar un dashboard com un gran tauler de l’organització, on hi ha

indicadors (com el tauler d’un vehicle) que mostren la realitat de les diferents
àrees de negoci. Imaginem que quan un valor d’un indicador baixa per sota d’un
límit normal, s’encén una llum d’alerta que indica que cal posar-hi atenció i, si
s’excedeix d’un valor tolerable, no només s’encén la llum sinó que a més ho indica
mitjançant un senyal auditiu.
2. Implantació tècnica de sistemes ERP-CRM: OpenERP
Quan es parla de sistemes ERP-CRM el mot implantació s’acostuma a utilitzar

per fer referència al procés global que té com a objectiu final la posada en marxa
d’un nou sistema ERP-CRM a l’organització. Aquest procés té diverses fases:
anàlisi de requeriments, estudi de possibles solucions, decisió per un producte,
instal·lació i configuració, migració de dades –si s’escau–, formació dels usuaris
i execució d’adaptacions –si s’escau–. Una implantació entesa així és un procés
molt complex que ha d’estar dirigit per professionals especialistes (consultors).
Per implantació tècnica de sistemes ERP-CRM entenem el subprocés amb les

següents operacions imprescindibles:
1. Instal·lació del programari, en un determinat maquinari i sistema operatiu,

seguint les prescripcions del fabricant.
2. Instal·lació de mòduls addicionals que corresponguin, segons requeriments.
3. Configuració del programari, segons les possibilitats que es facilitin, per

adequar-lo als requeriments de l’organització.
4. Verificació del correcte funcionament, segons requeriments.
5. Documentació de les operacions realitzades i incidències aparegudes, amb

la seva resolució.
La llista d’operacions anteriors es pot veure ampliada amb dues operacions més:
1. Migració de dades del programari de gestió empresarial existent cap al nou

programari, si així està contemplat en el projecte d’implantació del nou
programari.
2. En cas que el programari que instal·lem incorpori un mecanisme de salva-

guarda de les dades, posada en marxa i verificació de la correcta recuperació
de les dades en el cas d’haver ocorregut un desastre.
Per executar aquestes operacions pot ser necessari l’ajut de dos perfils professio-
nals diferents al nostre i que en moltes ocasions recauen en un mateix professional:
1. L’administrador del sistema, en el cas que calgui efectuar alguna configura-

ció a nivell de sistema operatiu.
2. L’administrador del sistema gestor de base de dades, en el cas que el nostre

programari hagi de connectar amb un SGBD corporatiu, ja instal·lat o que
calgui instal·lar.
Tot procés d’implantació tècnica d’un ERP-CRM consta de les operacions anteri-
ors. En les diverses combinacions possibles de sistema ERP-CRM amb sistema
operatiu i amb sistema gestor de bases de dades, hi intervenen tantes variables
que cada combinació necessitaria el seu propi aprenentatge. És a dir, a diferència
del procés d’aprendre a conduir, que ens serveix gairebé per a qualsevol cotxe,
la implantació tècnica d’un sistema ERP-CRM no és estàndard i, per tant, un
implantador necessita l’aprenentatge concret per a cada combinació possible. Per
altra banda, l’experiència acumulada d’un implantador en diverses situacions
ajuda que cada nova situació necessiti d’un aprenentatge més curt.
Ja que no podem pretendre endinsar-nos en la implantació tècnica de qualsevol

sistema ERP-CRM en qualsevol de les plataformes suportades (sistema operatiu +
Logotip d’OpenERP SGBD), ens centrarem en un producte i en la implantació hi posarem en pràctica
totes les operacions. El producte escollit ha estat el sistema ERP-CRM de codi
obert OpenERP.
L’OpenERP és un sistema ERP-CRM de codi obert amb llicència AGPL, conegut

Llicència AGPL
prèviament com a TinyERP.
La llicència AGPL és una
llicència copyleft derivada de la Les característiques bàsiques que hauríem de tenir en compte a l’hora d’avaluar
GPL de GNU que incorpora una
clàusula que afegeix l’obligació un sistema ERP-CRM i els valors per al sistema OpenERP són:
de distribuir el codi font del
programari quan aquest s’utilitzi
per donar serveis sobre una
xarxa (per exemple, en • Llicència:
aplicacions web).
– AGPLv3 (versió 6) o AGPL+Private User.

– GPLv3 (versió 5).
• Desplegaments possibles:
– On-premise sota els SO: Linux i Windows (dues versions: Commu-

nity–gratuïta– i Enterprise).
– SaaS.
• Arquitectura. Client-servidor amb tres capes clarament diferenciades:
– La base de dades en l’SGBD PostgreSQL, que només conté dades

i no conté cap lògica de negoci (és a dir, no incorpora funcions,
procediments o disparadors).
– El servidor OpenERP que conté tota la lògica de negoci amb un
nucli base i una estructura que permet anar afegint mòduls segons
les necessitats de l’organització. OpenERP facilita una llarga llista de
mòduls que es pot ampliar amb el disseny de mòduls propis per donar
cobertura a les necessitats de l’organització.
– La capa dels clients, amb diverses possibilitats: client web, accessible
des de qualsevol navegador, client GTK, per instal·lar a cada màquina
que vulgui utilitzar-lo i clients per desenvolupar que es connectin amb
els protocols XML-RPC o Net-RPC.
• Sistema operatiu:
– Servidor sobre Windows o Linux.

– Client GTK sobre Windows, Linux o Mac.
• SGBD: PostgreSQL (el fet que la BD no contingui cap lògica de negoci

fa pensar que hauria de ser fàcil la substitució de PostgreSQL per un altre
SGBD).
• Cost (agost 2012)
– Versió Enterprise:
∗ 1-10 usuaris 1.950 A
C / any
∗ 10-25 usuaris: 3.950 A
C / any
∗ 25-70 usuaris: 9.950 A
C / any
∗ més usuaris: consultar.
– Versió SaaS: 39 A
C cada usuari/mes
Respecte les funcionalitats segons les versions:
• La versió Enterprise (de pagament):
– Llicència AGPL o AGPL + Private Use.

– Incorpora suport.
– Incorpora migracions il·limitades (quan es canvia de versió).
– Incorpora pegats il·limitats (per solucionar els errors detectats).
– Permet dissenyar mòduls privats (dels quals no s’està obligat a facilitar
el codi font).
– Facilita alertes de seguretat
• La versió Community (gratuïta):
– No incorpora suport.
– No incorpora migracions.
– No incorpora pegats.
– No permet dissenyar mòduls privats (per tant, estarem obligats a
facilitar el codi font dels mòduls que desenvolupem).
• La versió SaaS (de pagament):
– Incorpora l’allotjament a càrrec d’OpenERP.

– Efectua les còpies de seguretat.
– Incorpora migracions.
– Incorpora manteniment.
– No permet tenir mòduls privats.
– No permet tenir mòduls de la comunitat.
La versió 7 d’OpenERP no
facilita el client GTK i
únicament es pot utilitzar el
Pel que fa als clients subministrats per OpenERP 6.1: client web.
• Client web, que permet la connexió via protocol HTTP des de qualsevol
navegador.
• Client GTK, que s’ha d’instal·lar a cada màquina des d’on es vulgui accedir
a OpenERP.
Ja que totes les màquines actuals incorporen algun navegador, és útil l’existència
del client web, ja que facilita l’ús de l’OpenERP des de qualsevol màquina, sense
haver de procedir a instal·lar-hi cap programari. No obstant això, els usuaris
acostumats al client GTK són reticents al canvi cap al client web perquè es perden
El client GTK es basa en les dreceres de teclat.
el projecte GTK+
(www.gtk.org), un conjunt
d’eines multiplataforma Per tal d’arribar a ser capaços d’efectuar instal·lacions reals de l’OpenERP cal
per a la creació
d’interfícies d’usuari, sota començar realitzant implantacions de l’OpenERP en un sistema proper en el qual
llicència GNU LGPL.
ens moguem amb facilitat.
Ja que el servidor OpenERP
pot instal·lar-se sobre
Windows i Linux cal Per altra banda, abans de planificar l’aprenentatge, és altament recomanable
decidir-se per un dels dos.
S’escull Windows per ser el
conèixer les possibilitats d’instal·lació que facilita el producte. Per aquest motiu,
sistema més conegut pels
usuaris.
cal fer una visita a la pàgina web oficial d’OpenERP (www.openerp.com) i
observar les diverses distribucions que facilita (a data d’agost del 2012), recollides
a la taula 2.1, taula 2.2 i taula 2.3.
Taul a 2. 1. Distribucions d’OpenERP disponibles l’agost del 2012 per OpenERP 6.1
Plataforma Materials facilitats
Windows Auto-Installer Release Notes (html)

All-In-One (.exe)
GTK Client (.exe)
Sources Release Notes (html)

All-In-One (.tar.gz)
GTK Client (.tar.gz)
Debian/Ubuntu All-In-One (.deb)
Taul a 2. 2. Distribucions d’OpenERP disponibles l’agost del 2012 per OpenERP 6.0
Windows Auto-Installer All-In-One (.exe)

Server (.exe)
GTK Client (.exe)
Web Client (.exe)
Sources Server (tar.gz)

Client (tar.gz)
Web Client (tar.gz)
Debian/Ubuntu Server (.deb)

GTK Client (.deb)
MacOS X GTK Client (.dmg)
Taul a 2. 3. Distribucions d’OpenERP disponibles l’agost del 2012 per OpenERP 5.0.14
Windows Auto-Installer All-In-One

Server
GTK Client
Web Client
Tau l a 2.3 (continuació)
Sources Server (tar.gz)

GTK Client (tar.gz)
Web Client (tar.gz)
Les distribucions All-In-One (tot en un) incorporen totes les peces imprescindibles
per poder instal·lar un servidor OpenERP, incloent, fins i tot, una versió de l’SGBD
PostgreSQL. Com que se suposa que no som experts en instal·lació i configuració
de l’SGBD PostgreSQL i ja que se’ns facilita la distribució All-In-One que inclou
la instal·lació d’una versió de PostgreSQL, la lògica ens diu que comencem per
instal·lar aquesta distribució en un sistema operatiu conegut (Windows).
L’itinerari de passos a seguir amb l’objectiu final de tenir els coneixements

adequats per poder efectuar implantacions tècniques d’OpenERP és:
1. Instal·lar OpenERP All-In-One en el SO Windows.
2. Instal·lar el client GTK d’OpenERP en SO Windows.
3. Distingir els tipus d’usuaris existents al voltant d’un servidor OpenERP.
4. Adquirir coneixements bàsics del servidor PostgreSQL.
5. Instal·lar OpenERP en SO Windows connectant amb un SGBD PostgreSQL

existent.
6. Gestionar empreses amb OpenERP.
7. Conèixer el funcionament dels clients web i GTK.
8. Instal·lar mòduls segons les necessitats de l’organització.
9. Instal·lar OpenERP en sistemes operatius Linux.
2.1 Instal·lació d’OpenERP All-In-One en el SO Windows
Les distribucions All-In-One incorporen totes les peces necessàries per la ins-
tal·lació d’un servidor OpenERP i, en ocasions, també el client GTK. Però no
totes les distribucions All-In-One incorporen les mateixes peces.
Així, si executem la instal·lació de la distribució All-In-One de la versió 6.0 ens

apareix la pantalla de la figura 2.1, en la qual observem que ens permet instal·lar
el servidor OpenERP, el client GTK, el client web i l’SGBD PostgreSQL. L’opció
PostgreSQL Database estarà inactiva si l’instal·lador detecta l’existència d’un
servidor PostgreSQL a la màquina.
En canvi, la instal·lació All-In-One de la versió 6.1, només incorpora el servidor

OpenERP (que inclou el client web) i una versió de l’SGBD PostgreSQL. És a
dir, no permet la no instal·lació del client web i no facilita la instal·lació del client
GTK. Cal recordar que la versió 7.0 d’OpenERP elimina el client GTK.
F igu ra 2 .1 . Pantalla d’elecció de components de l’instal·lador All-In-One

d’OpenERP 6.0 per a Windows
La barra superior blava de la figura 2.1 ens dóna també una informació important.
Destaca que es tracta de la versió 6.0–subversió del 9 de març del 2012. Això
és important tenir-ho present, perquè OpenERP publica periòdicament una nova
versió de la versió vigent i al web d’OpenERP només es pot descarregar la darrera.
De fet, el procés de descàrrega facilita un arxiu amb nom openerp-allinone-setup-
6.1-latest.exe i només podrem saber de quina subversió es tracta quan comencem
la instal·lació.
Instal·lem una versió concreta All-In-One Community per a Windows (versió

6.1-YYYYMMDD-RELEASE) i també el corresponent client GTK. Si procediu
a descarregar-vos la darrera versió d’ambdós productes i inicieu la instal·lació,
Als annexos del web veureu que disposeu d’una versió més nova.
trobareu l’apartat
“Recursos de programari”
que inclou les versions F igu ra 2 .2 . Pantalla d’elecció de components de l’instal·lador All-In-One
dels programes als quals d’OpenERP 6.1 per a Windows
fem referència en aquests
materials.
Iniciem la instal·lació. Després de seleccionar l’idioma del procés d’instal·lació

(anglès o francès) i acceptar els termes de la llicència, se’ns permet seleccionar el
tipus d’instal·lació, com es mostra en la figura 2.2.
El procés proposa la instal·lació All-In-One amb els components OpenERP Server

(que incorpora el servidor OpenERP i el client web) i PostgreSQL Database
(necessari si no disposem ja d’un servidor PostgreSQL instal·lat. En aquesta
primera instal·lació, mantindrem els dos components (no podem tenir un SGBD
PostgreSQL instal·lat a la màquina).
Procedim, doncs, amb la instal·lació dels dos components i immediatament se’ns

facilita la pantalla de configuració per la connexió PostgreSQL, amb uns valors
per defecte, com mostra la figura 2.3.
F igur a 2. 3 . Pantalla de configuració per connectivitat amb servidor

PostgreSQL de l’instal·lador d’OpenERP
En aquests moments aniria molt bé tenir uns mínims coneixements d’administra-

ció de SGBD i, en el seu defecte, de connectivitat amb SGBD. El mínim que hem
de saber és que la majoria de connexions a efectuar contra un SGBD utilitzen el
protocol TCP/IP i, en conseqüència, necessitem conèixer:
• El nom o adreça IP de la màquina on hi ha instal·lat l’SGBD.
• El port TCP pel qual està escoltant l’SGBD.
• L’usuari i la contrasenya de l’usuari autoritzat a establir connexió.
Com que el procés All-In-One instal·la el servidor PostgreSQL a la mateixa

màquina on instal·lem el servidor OpenERP, ja és correcte mantenir localhost com
a valor per Hostname. Pel que fa al port (5432), cal saber que aquest és el port TCP
pel qual normalment escolta un servidor PostgreSQL i, per tant, en mantindrem
el valor. Pel que fa l’usuari (openpg) que proposa el procés d’instal·lació, cal
saber que aquest serà el superusuari de l’SGBD PostgreSQL que estem instal·lant.
Podeu deixar l’usuari que proposa el procés, però també podeu canviar-lo segons
les vostres preferències. Nosaltres el canviem i li assignem ioc, amb contrasenya
iocioc. Aquesta informació és crítica i, per tant, cal tenir-la anotada en un lloc ben
segur.
Un cop fet això, se’ns permet indicar el directori d’instal·lació i procedim. Després
d’uns minuts, el procés finalitza. El propi procés, en la darrera pantalla, ens facilita
una casella de verificació anomenada Start OpenERP per començar a treballar amb
OpenERP immediatament, a través d’una connexió HTTP. Si manteniu l’opció
activada i finalitzeu el procés, veureu com s’obre el navegador que tingueu per
defecte i intenta connectar a la URL localhost:8069/web/webclient/ com mostra
la figura 2.4. Fixem-nos que el servidor web que instal·la OpenERP 6.1 escolta
pel port 8069. En canvi, el servidor OpenERP de la versió 6.0 escolta pel port
8080.
Si mirem el panell de control dels serveis del sistema operatiu, hi observarem

dos serveis, engegats i amb inici automàtic (és a dir, es posen en marxa de forma
automàtica quan s’engega la màquina):
• PostgreSQL for OpenERP
• OpenERP Server 6.1
A l’arbre de programes de Windows, hi observem els submenús:
• OpenERP Server 6.1-YYYYMMDD-RELEASE, amb un enllaç cap a la

pàgina web que intenta connectar amb el client web.
• PostgreSQL 8.3, amb diverses opcions per configurar i administrar l’SGBD

PostgreSQL.
A la carpeta del sistema d’arxius on s’ha instal·lat OpenERP (possiblement

C:\Archivos de programa\OpenERP 6.1-YYYYMMDD-RELEASE), hi trobem dues
carpetes:
• PostgreSQL, que conté tot el que fa referència al servidor PostgreSQL.
• Server, que conté tot el que fa referència al servidor OpenERP (client web
inclòs).
F igur a 2. 4. Pantalla inicial del client web d’OpenERP
Arribats aquí, si tinguéssim ja instal·lada alguna empresa, la seleccionaríem en el

camp que OpenERP anomena Database i podríem utilitzar un usuari autoritzat
(per l’empresa en qüestió) per iniciar la gestió dins l’ERP.
En aquests moments no tenim cap empresa (Database segons nomenclatura

d’OpenERP) creada i, per tant, no podem encara entrar. Des d’aquesta pantalla
disposem de l’enllaç Manage Databases a la part inferior, per gestionar empreses:
crear-ne, eliminar-ne, fer-ne còpia de seguretat i restaurar-ne des de còpia de
seguretat, accions que també podrem executar des del client GTK.
Des d’una altra màquina de la xarxa podem provar d’utilitzar qualsevol navegador
per treballar amb el client web d’OpenERP. Només caldrà canviar la paraula
localhost de la URL pel nom o adreça IP de la màquina on tenim el servidor
OpenERP instal·lat.
2.2 Instal·lació del client GTK de OpenERP en el SO Windows

Als annexos del web
La instal·lació del client GTK 6.1-YYYYMMDD en qualsevol màquina Windows que inclou les versions
dels programes als quals
des d’on vulguem accedir al servidor OpenERP (que pot residir o no a la mateixa fem referència en aquests
materials.
màquina), un cop acceptats els termes de la llicència, ens permet seleccionar el
directori d’instal·lació i en pocs segons la instal·lació finalitza.
Podem observar que la instal·lació ha generat el submenú OpenERP GTK Client

6.1 a l’arbre de programes de Windows amb un enllaç al client GTK pel qual també
tindrem possiblement un accés a l’escriptori.
En posar en marxa el client GTK, aquest mira si a la pròpia màquina hi ha un

servidor OpenERP socket://localhost:8070. Si no el troba, ens mostra la
pantalla de la figura 2.5.
F igu ra 2 .5 . Pantalla del client GTK d’OpenERP indicant que no pot

connectar amb el servidor OpenERP
Fixem-nos que l’idioma que utilitza és el català, que és l’idioma d’entrada

predeterminat que tenia activat la màquina Windows quan hem procedit a la
instal·lació del client.
Si el servidor el tenim en una altra màquina, haurem de procedir a prémer el

botó Canvia i canviar la paraula localhost pel nom o adreça IP de la màquina
on tenim el servidor OpenERP instal·lat. Una vegada hem indicat la ubicació del
servidor, el client GTK hi cerca una empresa. Si el servidor el tenim a la mateixa
màquina, com que el client GTK troba el servidor, passa directament a cercar-hi
una empresa.
Tant si el servidor és a la mateixa màquina com si és en una màquina remota, si el

client no detecta cap empresa en el servidor (base de dades segons nomenclatura
OpenERP), informa del fet amb la pantalla de la figura 2.6.
F igu ra 2 .6 . Pantalla del client GTK d’OpenERP indicant que no detecta

cap empresa en el servidor OpenERP
En aquests moments no tenim cap empresa creada i, per tant, no podem entrar
encara. El propi client GTK facilita l’opció de menú Fitxer | Base de dades per
gestionar empreses: crear-ne, eliminar-ne, fer-ne còpia de seguretat i restaurar-ne
des de còpia de seguretat, accions que també podrem executar des del client web.
2.3 Usuaris al voltant d’un servidor OpenERP
Abans de procedir a gestionar empreses és convenient entendre els tres tipus

d’usuaris existents al voltant d’un servidor OpenERP:
1. Usuari del servidor PostgreSQL amb privilegi de creació de bases de

dades: és l’usuari de PostgreSQL que utilitza el servidor OpenERP per
crear i eliminar empreses (bases de dades) dins el servidor PostgreSQL. Una
empresa d’OpenERP es correspon amb una base de dades dins el servidor
PostgreSQL.
• En cas que el servidor PostgreSQL hagi estat instal·lat pel procediment

d’instal·lació d’OpenERP, el procés proposa l’usuari openpg (contra-
senya openpgpwd) com a superusuari del servidor PostgreSQL, però
es pot decidir qualsevol parella (usuari-contrasenya).
• En cas que el servidor PostgresSQL hagi estat instal·lat de manera
independent al procediment d’instal·lació d’OpenERP, disposarà d’un
superusuari i hauríem de poder utilitzar aquest (sempre que no s’ano-
meni postgres, ja que per qüestions de seguretat OpenERP no permet
aquest nom d’usuari) o qualsevol altre amb autorització per crear bases
de dades per tal que l’utilitzi l’OpenERP per crear i eliminar empreses
(bases de dades) dins el servidor PostgreSQL.
• L’usuari del servidor PostgreSQL amb autorització per crear bases
de dades i la seva contrasenya han de residir, respectivament, en
les entrades db_user i db_password del fitxer openerp-server.conf
ubicat a camíOnResideixOpenERP/Server/server. Si en comproveu el
contingut hi veureu l’usuari ioc i la contrasenya iocioc que havíem
indicat en el procés d’instal·lació.
2. Usuari administrador del servidor OpenERP: és un usuari únic del ser-

vidor OpenERP, que és el que pot crear i eliminar les empreses. No té nom i
únicament té contrasenya. La contrasenya inicial de l’usuari administrador
de qualsevol servidor OpenERP és admin i el procés d’instal·lació del
servidor OpenERP no en facilita el canvi. Els clients web i GTK faciliten
l’opció de canvi de contrasenya. Aquesta contrasenya està emmagatzemada
a l’entrada admin_passwd del fitxer openerp-server.conf que es troba a
camíOnResideixOpenERP/Server/server. En cas de canviar la contrasenya
accedint directament al fitxer de configuració, caldrà reiniciar el servidor
OpenERP. El canvi de la contrasenya des del client GTK s’efectua des de
l’opció Fitxer | Base de dades | Contrasenya de l’administrador. El canvi de
la contrasenya des del client web s’efectua des de l’opció Manage Databases
de la pàgina inicial, subopció Password.
3. Usuaris de cada empresa creada en el servidor OpenERP: el procés

de creació d’una empresa ve donat amb un usuari administrador, de nom
admin, pel qual hem d’introduir la contrasenya durant el procés de creació
de la base de dades. L’usuari admin de cada empresa té tots els privilegis
i, una vegada connectat a l’empresa, pot crear usuaris, grups de privilegis

sobre els objectes d’OpenERP (tercers, productes, comandes, albarans,
factures...) i assignar usuaris als diversos grups de privilegis. En cas
de perdre la contrasenya de l’usuari admin, un usuari administrador del
servidor PostgreSQL pot recuperar-la tot consultant-la directament la base
de dades, a través de les eines d’accés que el servidor PostgreSQL facilita.
El procés de creació d’una empresa permet carregar unes dades de demostració

i, en tal situació, també hi incorpora un usuari de nom demo i contrasenya demo.
Aquest usuari no existeix en la creació d’una empresa buida.
2.4 Coneixements bàsics del servidor PostgreSQL
PostgreSQL (www.postgresql.org) és un SGBD relacional distribuït sota llicència

En 17-08-2012 la versió de BSD, desenvolupat per PostgreSQL Global Development Group.
PostgreSQL vigent és la
9.1.5, mentre que el
servidor PostgreSQL que Nosaltres, com a implantadors tècnics d’ERP, hem de ser coneixedors de l’estruc-
instal·la l’OpenERP és la
versió 8.3.4 de 22-09-2008. tura de la base de dades per si hem de desenvolupar mòduls que complementin la
funcionalitat que facilita l’ERP.
Com que la base de dades es troba implementada en un SGBD concret, ens convé
conèixer les eines bàsiques de què disposem per moure’ns amb facilitat dins de
l’SGBD. La majoria d’SGBD actuals faciliten dos tipus d’eines per accedir a les
bases de dades i facilitar la gestió:
• Eines gràfiques i/o consoles textuals: basades en l’arquitectura client-

servidor, obliguen a instal·lar l’eina a la màquina des de la qual es vol accedir
a l’SGBD, que pot residir en una màquina remota.
• Eines gràfiques web: permeten l’accés des de navegadors i, per tant, eviten
el fet d’haver d’instal·lar cap programari client.
Per accedir a PostgreSQL disposem de moltes eines. Entre elles, cal conèixer
l’existència de:
• Eina gràfica pgAdminIII, amb arquitectura client-servidor
• Consola textual psql, amb arquitectura client-servidor
• Eina gràfica phpPgAdmin, amb servidor web (necessita PHP)
2.4.1 Què incorpora el servidor PostgreSQL que instal·la OpenERP?
La versió All-In-One d’OpenERP 6.1 incorpora la instal·lació de la versió 8.3.4

del servidor PostgreSQL i d’un conjunt d’eines bàsiques per a la seva gestió.
Si fem una ullada a l’arbre de programes del sistema operatiu Windows hi trobarem
la opció de menú anomenada PostgreSQL 8.3 que conté:
1. El menú Documentation, que incorpora informació diversa que fa referència

al servidor PostgreSQL i a l’eina pgAdmin.
2. L’eina gràfica pgAdmin.
3. L’opció Start service que permet posar en marxa el servidor PostgreSQL

sense haver d’anar al panell de control de serveis del sistema operatiu.
4. L’opció Stop service que permet aturar el servidor PostgreSQL sense haver
d’anar al panell de control de serveis del sistema operatiu.
5. L’opció Command Prompt que obre una consola de sistema i ens situa en
el directori on hi ha els programes executables de PostgreSQL, per si cal
utilitzar-ne algun, destinats habitualment als administradors de PostgreSQL.
6. El menú Configuration Files que facilita l’edició de tres fitxers de configura-

ció de PostgreSQL: pg_hba.conf, pg_ident.conf i postgresql.conf. L’edició
del contingut d’aquests fitxers és una tasca pròpia dels administradors de
l’SGBD i a ells els la deixarem amb una excepció, ja que ens pot convenir
establir connexió amb el servidor PostgreSQL des de màquines remotes i
per aconseguir-ho haurem de retocar alguns paràmetres de configuració.
2.4.2 Eina pgAdmin
L’eina pgAdmin és una de les eines més habituals d’utilitzar per accedir a un
servidor PostgreSQL (local o remot) i es pot instal·lar a qualsevol màquina.
La podem baixar de la pàgina oficial (www.pgadmin.org) i és tan habitual que
l’OpenERP la incorpora en la instal·lació del servidor PostgreSQL que facilita.
En posar en marxa qualsevol versió de pgAdmin, apareix una pantalla com la de

la figura 2.7.
La part esquerra de la pantalla principal de pgAdmin està destinada a incorporar

tots els servidors PostgreSQL als quals volem accedir amb aquesta eina, ja siguin
a la pròpia màquina o en màquines remotes. Cal comentar que en una mateixa
màquina hi poden coexistir diversos servidors PostgreSQL, amb la precaució que
han d’escoltar per diferents ports.
F igu r a 2. 7 . Pantalla principal de l’eina pgAdmin per administrar servidors PostgreSQL
La figura 2.7, que correspon a l’eina pgAdmin que instal·la l’OpenERP, ens
permet observar que pgAdmin ja té registrat el servidor PostgreSQL instal·lat per
OpenERP a la màquina i el veiem acompanyat d’una creu vermella que indica que
no hi estem connectats. Per establir connexió i poder gestionar el seu contingut
cal situar-nos al damunt i prémer amb doble clic del ratolí. Apareixerà la finestra
de diàleg per establir connexió similar a la que mostra la figura 2.8.
F ig ura 2 . 8 . Finestra de diàleg de pgAdmin per establir

connexió amb una base de dades
Observem que la finestra de diàleg de la figura 2.8 ens indica que ens estem a
punt de connectar-nos amb l’usuari ioc que havíem indicat com a superusuari
del servidor PostgreSQL en el procés d’instal·lació. Si no s’havia canviat, us
proposarà l’usuari openpg.
La proposta d’usuari ioc l’efectua perquè el procés d’instal·lació ha registrat

aquesta connexió dins pgAdmin amb l’usuari ioc a les propietats de la connexió.
Si ens situem damunt la connexió PostgreSQL for OpenERP (localhost:5432) i

premem el botó secundari del ratolí, podrem accedir a les propietats, tal com
mostra la figura 2.9.
Fig ur a 2 . 9 . Finestra de propietats d’una connexió a

servidor PostgreSQL en pgAdmin
Observem que en aquesta pàgina de propietats podrem canviar l’usuari per defecte
i també podrem enregistrar la contrasenya, una vegada connectats, per evitar haver
d’introduir-la cada vegada que accedim al servidor PostgreSQL.
S’ha d’anar amb molt de compte a l’hora de deixar les contrasenyes enregistrades;
això només s’hauria de fer en màquines de les quals tenim la seguretat que només
hi tindran accés usuaris que, a la vegada, hagin de tenir accés als servidors
PostgreSQL enregistrats en pgAdmin.
Contrasenyes
Les contrasenyes enregistrades des de pgAdmin es troben en el fitxer pgpass.conf ubicat

dins d’una carpeta anomenada PostgreSQL que es troba dins del perfil de l’usuari que
ha creat les connexions i a la màquina client des de la qual s’executa pgAdmin. Aquesta
ubicació depèn de la versió del SO. En el cas de Win7:
1 ...\users\nomUsuari\AppData\Roaming\postgresql
És important tenir-ho present, perquè la resta d’eines de PostgreSQL instal·lades en

el sistema utilitzen el mateix arxiu per registrar o comprovar les contrasenyes. En
conseqüència, si un usuari ha registrat una connexió des de pgAdmin amb un usuari i
la corresponent contrasenya, la resta d’eines de PostgreSQL no li exigiran introduir la
contrasenya per establir connexió amb el servidor i utilitzaran l’usuari pel qual hi ha la
contrasenya registrada.
Una vegada establerta la connexió contra un servidor PostgreSQL (en el nostre

cas amb la versió de pgAdmin que ha instal·lat OpenERP), la part esquerra de
la pantalla de pgAdmin ens mostra el contingut del servidor PostgreSQL (figura
2.10).
F igu r a 2. 1 0 . Pantalla de pgAdmin amb una connexió oberta amb una base de dades
Cal recordar que aquesta eina està destinada a tot tipus d’usuaris informàtics,
siguin o no administradors de bases de dades. Allò que bàsicament cal saber
d’aquests eina és:
• Un servidor PostgreSQL pot tenir molts usuaris. La imatge ens mostra

només un usuari, de nom ioc, que és el superusuari del servidor PostgreSQL.
Si ens hi situem al damunt i premem el botó secundari del ratolí per anar
a les seves propietats, observarem que té privilegis totals. De moment no
ens cal crear nous usuaris, però quan l’ERP es posa en execució en una
organització, aquesta pot tenir usuaris finals que vulguin poder efectuar
consultes contra les bases de dades i, en aquest cas, els haurem de facilitar
un usuari amb els privilegis de lectura adequats (però mai d’escriptura) a
les bases de dades i taules o vistes que corresponguin. No hem de confondre
els usuaris de l’SGBD amb els usuaris de l’ERP. Els usuaris de l’ERP estan
emmagatzemats en taules pròpies de l’ERP i l’ERP utilitza un usuari de
PostgreSQL (ioc en aquest cas) per accedir a la BD de l’empresa.
• Un servidor PostgreSQL pot tenir diverses bases de dades, però com

a mínim n’ha de tenir una. La figura 2.10 mostra l’existència d’una
base de dades de nom postgres. En moltes ocasions, la primera base de
dades que s’instal·la s’anomena postgres, però podria tenir qualsevol altre
nom. El procés d’instal·lació d’OpenERP ha seguit el costum d’anomenar
postgres la primera base de dades del servidor. Aquesta primera base de
dades és especial en el sentit que és la base de dades de manteniment
del servidor i mai podrà ser eliminada. De fet, si intentem eliminar-la tot
situant-nos al damunt i prement la tecla “Supr” ens apareixerà un missatge
informant que és la base de dades de manteniment i no pot ser eliminada.

Si ens situem damunt el node arrel del servidor al qual estem connectats i
observem les propietats a la part dreta de la pantalla veurem que postgres
és la Maintenance database. Observem que la base de dades postgres té
per propietari l’usuari ioc. Això vol dir que ha estat l’usuari ioc qui l’ha
creat. Ara mateix no observem cap altra base de dades perquè el servidor
s’acaba d’instal·lar i encara no hem creat cap empresa. A mesura que
anem creant empreses aniran apareixent les corresponents bases de dades
en el servidor PostgreSQL. Cada base de dades tindrà els seus usuaris per
gestionar l’empresa des d’OpenERP; aquests usuaris no seran usuaris de
PostgreSQL i, per tant, no podran utilitzar cap eina com a pgAdmin per
accedir a les bases de dades directament.
• Una base de dades de PostgreSQL està compartimentada en esquemes.

Com a mínim hi ha un esquema de nom public, els continguts del qual
són accessibles per a tots els usuaris que tinguin accés a la base de dades.
Un esquema conté tot allò que en altres SGBD és el contingut d’una
base de dades: dominis, taules, vistes, funcions, seqüències i disparadors.
Malgrat que una base de dades de PostgreSQL pugui estar compartimentada
en esquemes, en moltes ocasions s’utilitza únicament l’esquema public.
Aquest és el cas de les bases de dades que crea OpenERP. Cada empresa
es correspon amb una base de dades que té tota la informació dins l’únic
esquema de nom public.
• Si pensem utilitzar pgAdmin per executar sentències DML (insert,

update, delete) cal saber que està configurada amb el comportament
autocommit on, és a dir, qualsevol operació de modificació de dades
sobre la base de dades és automàticament validada sense que l’usuari hagi
d’efectuar commit i, per tant, no és possible invocar un rollback. En cas
de voler canviar aquest comportament cal utilitzar la gestió de transaccions
amb les instruccions begin, commit i rollback:
1 begin;
2 <instruccions SQL−DML>
3 <finalització de la transacció amb commit o rollback>
2.4.3 Configurar PostgreSQL per admetre connexions remotes
El servidor PostgreSQL que instal·la OpenERP (i també la majoria d’instal·lacions

de servidors PostgreSQL) estan configurades per admetre únicament connexions
locals des de la màquina on s’allotja el servidor.
Així, tant si utilitzen el client OpenERP web com el client GTK, aquests es
connecten amb el servidor OpenERP que resideix a la mateixa màquina que el
servidor PostgreSQL i, per tant, les connexions sempre s’efectuen en local, cosa
que vol dir que no cal tenir configurat el servidor PostgreSQL per tal que admeti
connexions remotes.
És molt possible, però, que vulguem accedir directament a les bases de dades del
servidor PostgreSQL des d’altres eines clients, com per exemple:
• Una instal·lació pgAdmin ubicada en una màquina remota.
• Una aplicació que es vol connectar a través d’ODBC.
Per aconseguir-ho ens cal retocar alguns paràmetres de configuració del servidor
PostgreSQL i, per entendre la utilitat de cadascun, cal intentar la connexió remota,
veure els errors que es produeixen i anar aplicant les solucions que pertoquin
fins aconseguir la connectivitat. Ens cal, per tant, una aplicació instal·lada
remotament que vulgui connectar amb el servidor PostgreSQL. Podem utilitzar
l’eina pgAdmin instal·lada en una altra màquina de la xarxa (baixeu-la de la pàgina
Als annexos del web oficial www.pgadmin.org).
que inclou les versions La instal·lació de l’eina pgAdmin és molt simple. El paquet de distribució no
fem referència en aquests inclou tots els llenguatges però, una vegada instal·lat, es poden afegir seguint les
materials.
instruccions indicades a la pàgina web de pgAdmin.
Una vegada instal·lada l’eina pgAdmin en una màquina diferent de la que conté
l’SGBD, intentem la gestió del servidor PostgreSQL des d’aquest pgAdmin. El
primer que hem de fer és enregistrar un servidor a través de l’opció File | Add
Server. Ens apareix la pantalla de propietats de la connexió en la qual ens cal
introduir:
1. Name: ha de ser un nom informatiu del servidor PostgreSQL amb el qual

establim la connexió.
2. Host: ha de contenir el nom o la IP de la màquina que conté el servidor

PostgreSQL.
3. Port: ens proposa 5432 que és el port pel qual acostumen a escoltar els
servidors PostgreSQL.
4. MaintenanceDB: ens proposa postgres i és la base de dades a la qual

intentarà connectar.
5. Username: cal indicar un usuari de PostgreSQL; en el nostre cas, ioc o

openpgsi quan vam instal·lar OpenERP no vam canviar-lo.
6. Password: cal indicar la contrasenya de l’usuari indicat a username.
Una vegada introduïts aquests valors, premem OK per aconseguir la connexió

i ens apareix un missatge d’error similar al de la figura 2.11. El missatge diu
que a l’adreça IP 10.200.180.207 (suposem que és l’adreça IP de la màquina
on resideix el servidor PostgreSQL) i pel port 5432 no es troba cap servidor en
execució que accepti connexions TCP/IP. També ens recomana que revisem si
tenim correctament configurada la xarxa (VPN / túnels SSH / firewall).
Suposant que tenim la xarxa correctament configurada, llegim el següent paràgraf

en el qual se’ns diu que per raons de seguretat, PostgreSQL no escolta per totes les
adreces IP de la màquina que conté el servidor. És a dir, el servidor PostgreSQL

escolta només per l’adreça 127.0.0.1 i, si volem que escolti per altres adreces
IP pròpies, cal configurar-lo. Pensem que un servidor pot tenir diverses adreces
IP i ens pot interessar que les connexions contra un servidor PostgreSQL només
s’efectuïn per unes adreces IP determinades.
F igur a 2 . 1 1. Pantalla d’error de pgAdmin quan no pot connectar amb

un servidor
Per aconseguir que el servidor PostgreSQL escolti per unes determinades adre-
ces IP cal retocar, en el fitxer de configuració postgresql.conf, el paràmetre
listen_addresses. Veurem que el paràmetre està configurat de la forma:
1 #listen_addresses = ’localhost’
2 # what IP address(es) to listen on;
3 # comma−separated list of addresses;
4 # (change requires restart)
Eliminem el símbol # de l’inici que indica que el paràmetre està comentat i, a la

paraula localhost hi afegim, separades per comes, les adreces IP de la màquina
per les quals volem que el servidor PostgreSQL doni resposta. O, simplement,
hi deixem un asterisc per indicar que escolti per totes les adreces IP que tingui
definides.
Una vegada enregistrat el canvi en el fitxerpostgresql.conf, ens cal reiniciar el

servidor PostgreSQL i tornar a intentar la connexió. Ens apareix un nou error,
com mostra la figura 2.12.
El missatge de la figura 2.12 informa que en el fitxer pg_hba.conf no es troba una

entrada per a la màquina 10.200.1.207 (suposem que és l’adreça de la màquina
client que està intentant la connexió) a la base de dades postgres per l’usuari ioc.
És a dir, que l’usuari ioc no té autorització per connectar amb la base de dades
postgres des de la màquina 10.200.1.207.
F igu ra 2. 1 2 . Pantalla d’error de pgAdmin quan el servidor PostgreSQL

refusa la connexió
El fitxer pg_hba.conf és un fitxer que controla l’autenticació dels clients que

es connecten al servidor PostgreSQL. Per una explicació detallada de totes les
possibilitats que facilita aquest fitxer, cerqueu pg_hba.conf dins la documentació
de PostgreSQL. De forma molt simplificada, ens cal saber que aquest fitxer conté
línies cada una de les quals correspon a un permís d’autenticació. Inicialment ve
configurat com:
1 # TYPE DATABASE USER CIDR−ADDRESS METHOD

2
3 # IPv4 local connections:
4 host all all 127.0.0.1/32 md5
5 # IPv6 local connections:
6 #host all all ::1/128 md5
Fixem-nos amb l’única línia no comentada, que permet l’accés a totes les bases
de dades de qualsevol usuari connectat a la pròpia màquina (127.0.0.1/32) i que
utilitza una contrasenya encriptada amb el mètode md5.
La nomenclatura CIDR-address 127.0.0.1/32 es pot substituir per la nomenclatura

que indica l’adreça i la màscara en dues columnes:
1 host all all 127.0.0.1 255.255.255.255 md5
Per permetre l’accés a qualsevol usuari des de la màquina amb IP 10.200.1.207,

afegiríem una nova línia (sota l’existent inicialment):
1 host all all 10.200.1.207 255.255.255.255 md5
o equivalentment:
1 host all all 10.200.1.207/32 md5
Per permetre l’accés a qualsevol usuari des de qualsevol màquina 10.200.x.x,

afegiríem:
1 host all all 10.200.0.0 255.255.0.0 md5
o equivalentment:
1 host all all 10.200.0.0/16 md5
La columna METHOD permet múltiples possibilitats. Entre elles, la possibilitat

de prohibir la connexió (valor reject). Cal tenir en compte que:
• El servidor PostrgreSQL carrega el contingut de l’arxiu pg_hba.conf a la

memòria quan es posa en marxa i, per tant, caldrà reiniciar-lo davant de
qualsevol modificació d’aquest arxiu.
• Quan s’intenta autenticar una connexió, l’avaluació segueix l’ordre de les

diverses entrades existents a pg_hba.conf i s’aplica la primera entrada amb
la qual s’aconsegueix una coincidència. Com a exemple, si l’entrada 10
restringeix la connexió per una IP XXX concreta però en una entrada
anterior a la 10 es concedeix accés per la IP XXX, la connexió serà
autenticada sense cap problema.
2.4.4 Consola textual per gestionar un servidor PostgreSQL
L’SGBD PostgreSQL facilita una consola textual (aplicació de nom psql) per
permetre efectuar un gran nombre d’operacions sobre el servidor. El servidor
PostgreSQL que instal·la l’OpenERP per a Windows no instal·la aquesta consola
ja que incorpora l’eina pgAdmin i considera que ja és suficient.
En canvi, la instal·lació específica de l’eina pgAdmin (descarregada des de la

pàgina oficial d’aquesta eina: www.pgadmin.org), sí que incorpora la consola psql,
de la mateixa manera que ho fa la instal·lació de qualsevol servidor PostgreSQL.
Suposant que hem instal·lat l’eina pgAdmin en una màquina qualsevol, podrem
comprovar el funcionament de la consola psql. Així doncs, ens situem en una
consola de sistema i ens situem a la subcarpeta on hem instal·lat l’eina pgAdmin.
Comprovem que hi resideix el programa psql.exe (en Linux s’anomenaria psql).
Intentem executar-lo sense cap paràmetre. Ens trobem l’error similar a:
1 C:\Program Files (x86)\pgAdmin III\1.14>psql

2 psql: could not connect to server: Connection refused
3 Is the server running on host "localhost" (::1) and
4 accepting TCP/IP connections on port 5432?
L’eina psql intenta cercar un servidor PostgreSQL a la pròpia màquina escoltant

pel port 5432 i en no trobar-lo ens mostra l’error anterior.
L’eina psql admet molts paràmetres, que podem conèixer executant psql -h
o psql –-help. Per utilitzar aquesta eina per connectar-nos amb un servidor
PostgreSQL, ens cal utilitzar els paràmetres:
• -h, per indicar el servidor PostgreSQL al qual ens volem connectar.
• -p, per indicar el port (5432 si no s’indica).
• -U, per indicar un usuari del servidor PostgreSQL (si no s’indica, agafa
l’usuari que té oberta la sessió en el sistema operatiu).
• -d, per indicar el nom de la base de dades a la qual ens volem connectar
(si no s’indica, intenta connectar amb una base de dades de nom igual al de
l’usuari indicat en el paràmetre -U).
Així, per connectar-nos a un servidor resident a la màquina amb IP

10.200.180.207, amb usuari ioc i a la base de dades postgres, escriurem la següent
instrucció i l’eina ens demanarà la contrasenya:
1 C:\...>psql −h 10.200.180.207 −U ioc −d postgres

2 Password for user ioc:
3 psql (9.1.4, server 8.3.4)
4 WARNING: psql version 9.1, server version 8.3.
5 Some psql features might not work.
6 WARNING: Console code page (850) differs from Windows code page (1252) 8−bit
characters might not work correctly. See psql reference page "Notes for
Windows users" for details.
7 Type "help" for help.
8
9 postgres=#
Fixem-nos que:
• Informa que l’eina psql és de la versió 9.1.4 mentre que ens estem connec-
tant a un servidor PostgreSQL 8.3. Per tant, hi pot haver alguna funcionalitat
que no s’executi correctament.
• Informa que el codi de pàgina de la consola DOS (850) és diferent del codi
de pàgina de Windows (1252). Això provoca que caràcters especials com les
vocals accentuades, el símbol ç i similars, ben enregistrats a la base de dades,
no es vegin correctament a la consola DOS i que els caràcters especials
correctament introduïts des de la consola DOS quedin mal enregistrats a
la base de dades, de manera que quan els consultem des d’una eina com
pgAdmin, són erronis. La solució a aquest inconvenient consisteix, com
indica la documentació de psql per als usuaris de Windows, a canviar el codi
de pàgina de la consola DOS abans de posar en marxa la consola textual psql,
tot executant chcp 1252, i a canviar la font de la consola a Lucide Console.
• Informa que podem teclejar help per aconseguir ajuda. Si ho fem, veurem
que l’ordre \q permet abandonar la consola textual de PostgreSQL i tornar a
la consola del sistema operatiu; veurem també que l’ordre \h informa sobre
les ordres SQL que podem executar i que l’ordre \? informa sobre les ordres
pròpies de la consola psql.
• El prompt ha canviat a postgres=# que ens informa de la base de dades a

la qual estem connectats.
L’execució de l’ordre \? dins la consola psql ens permet conèixer que l’ordre \dt
mostra totes les taules de la base de dades i que l’ordre \d, seguida d’un nom de
taula, permet obtenir la descripció detallada de l’estructura de la taula. Així, per
exemple, per conèixer les taules de la base de dades a la que estem connectats,
executem:
1 postgres=# \dt;
2 No relations found.
La resposta del servidor és que no es troba cap taula, ja que en aquest moment, la
base de dades postgres no en conté cap.
Si tingués alguna taula podríem, amb \d conèixer la descripció de la seva

estructura i executar instruccions SQL (finalitzades amb el símbol ”;”). Així
mateix, podem procedir a crear taules, vistes... és a dir, a executar qualsevol de les
instruccions SQL. Si es vol practicar, cal crear una base de dades específica per a
les proves i no embrutar mai les bases de dades que crea OpenERP ni la base de
dades de manteniment postgres.
Per abandonar la consola textual i tornar a la consola del sistema, escriurem:
1 postgres=# \q
Quan s’utilitza la consola psql s’ha de tenir en compte que està configurada amb
el comportament autocommit on, és a dir, qualsevol operació de modificació
de dades sobre la base de dades és automàticament validada sense que l’usuari
hagi d’efectuar “commit” i, en conseqüència, no és possible invocar un rollback.
En cas de voler canviar aquest comportament, cal executar la instrucció de psql
següent, indicant la paraula AUTOCOMMIT en majúscules:
1 \set AUTOCOMMIT OFF
Una altra possibilitat de desactivar el comportament de validació automàtica, és

utilitzar la gestió de transaccions amb les instruccions begin, commit i rollback:
1 begin;
2 <instruccions SQL−DML>
3 <finalització de la transacció amb commit o rollback>
2.5 Instal·lació d’OpenERP en el SO Windows utilitzant un SGBD

PostgreSQL ja instal·lat
És important saber com instal·lar un servidor OpenERP en el sistema operatiu

Windows tot aprofitant un servidor PostgreSQL ja instal·lat i, fins i tot, en una
màquina diferent de la màquina on volem instal·lar el servidor OpenERP.
Per això, necessitem tenir un servidor PostgreSQL instal·lat en una màquina

(Windows o Linux). Proposem que, en cas de ser una màquina Windows, sigui
diferent de la màquina en la qual instal·larem el servidor OpenERP. Si no teniu

coneixements avançats de PostgreSQL, s’aconsella que instal·leu la darrera versió
per a Windows que us podeu descarregar de www.postgresql.org. Nosaltres
Als annexos del web instal·larem la versió 9.1.5.
que inclou les versions La instal·lació d’un servidor PostgreSQL a Windows és molt simple i només cal
fem referència en aquests tenir en compte:
materials.
1. Indicar el directori on volem instal·lar el servidor PostgreSQL.
2. Indicar el directori on volem que resideixin les dades (normalment la

subcarpeta data de la carpeta d’instal·lació del servidor).
3. Indicar la contrasenya pel superusuari del servidor PostgreSQL, que en

aquest cas s’anomena obligatòriament postgres. Es recomana anotar la
contrasenya assignada.
4. Indicar el port pel qual escoltarà el servidor PostgreSQL que estem ins-
tal·lant (normalment 5432 tot i que caldria indicar un altre port si ja hi
hagués algun servidor PostgreSQL instal·lat i escoltant per aquest port).
En finalitzar el procés, se’ns facilita la possibilitat de posar en marxa l’aplicació

Stack Builder per instal·lar eines i connectors que puguem necessitar. En aquest
cas n’avortarem l’execució.
Una vegada instal·lat el servidor PostgreSQL haurem de configurar-lo per tal que
admeti connexions remotes i per això ens cal saber que els fitxers de configuració
postgresql.conf i pg_hba.conf que s’han de retocar resideixen en el directori on
s’ha instal·lat les dades del servidor PostgreSQL.
Podem comprovar el funcionament correcte i la connectivitat del nou servidor

PostgreSQL intentant la connexió des de l’eina pgAdmin instal·lada a qualsevol
altra màquina. En cas que s’utilitzi l’eina pgAdmin que instal·la l’OpenERP,
observareu que la connexió amb el servidor s’estableix però que hi ha problemes
per gestionar les bases de dades; això és a causa que l’eina pgAdmin subministrada
per OpenERP és massa antiga per gestionar servidors PostgreSQL actuals.
Una vegada disposem d’un servidor PostgreSQL instal·lat (versió 9.1.5), la ins-
tal·lació del servidor OpenERP a partir de la versió All-In-One 6.1-YYYYMMDD
és idèntica a la instal·lació completa amb l’única diferència que no marcarem
l’opció d’instal·lar el servidor PostgreSQL i que a la pantalla de configuració de la
connectivitat amb el servidor PostgreSQL hi indicarem les dades que pertoquin:
• Hostname: l’adreça IP de la màquina que conté el servidor PostgreSQL.
• Port: el port pel qual escolta el servidor PostgreSQL (5432 normalment).
• Username: un usuari del servidor PostgreSQL amb el rol ‘pot crear bases
de dades’.
• Password: la contrasenya de l’usuari indicat a username.

OpenERP no permet que l’usuari de PostgreSQL que s’utilitza per mantenir la

connexió amb el servidor PostgreSQL s’anomeni postgres. En cas d’intentar-ho,
el servidor OpenERP no es posarà en marxa; semblarà que el corresponent servei
s’engegui però si procedim a actualitzar (F5) la llista dels serveis, observarem com
el servidor no està en execució.
Per crear un usuari en el servidor PostgreSQL, podem:
• Utilitzar l’eina pgAdmin per connectar-nos amb un superusuari (possible-

ment postgres) i una vegada connectats, navegar fins el node Login Roles en
el qual, amb el botó secundari del ratolí, podem procedir a la creació d’un
nou usuari, tot indicant:
– Role name: el nom que interessi (ioc, per exemple).
– Password: el que es vulgui (iocioc, per exemple).
– Role privileges: Can create database objects
• Utilitzar l’eina psql per connectar-nos amb un superusuari (possiblement

postgres) i una vegada connectats procedir a la creació del nou usuari amb
la sentència SQL de PostgreSQL que correspongui.
Una vegada tenim el nou usuari creat en el servidor PostgreSQL podem instal·lar
el servidor OpenERP. Quan finalitzem la instal·lació, haurem de fer els mateixos
retocs de configuració que vam efectuar en la instal·lació completa, en els fitxers
openerp-server.conf. Una vegada enregistrats els canvis que correspongui, cal
reiniciar el servidor OpenERP (en el panell de control dels serveis del sistema).
2.6 Gestió d’empreses en OpenERP
La creació i eliminació d’empreses en OpenERP s’efectua des de qualsevol dels

dos clients (web i GTK).
En el client web, des de la pantalla inicial, per l’opció Manage Databases, tal com
mostra la figura 2.13.
F igu ra 2 .1 3 . Pantalla inicial del client web d’OpenERP amb l’enllaç que
permet gestionar empreses
Des del client GTK, per l’opció Fitxer | Bases de dades, tal com mostra la figura
2.14.
Fig u ra 2. 14 . Pantalla inicial del client GTK d’OpenERP amb l’opció que permet
gestionar empreses
2.6.1 Creació d’empreses
Per crear una nova empresa (base de dades, segons terminologia OpenERP), sigui
quin sigui el client d’OpenERP que utilitzem, haurem d’introduir:
• Contrasenya del superadministrador d’OpenERP: si no es canvia, és

admin.
• El nom de l’empresa (base de dades): no té perquè ser la raó social, sinó

un nom que identifiqui, dins l’OpenERP, l’empresa a l’hora d’entrar. Aquest

serà el nom de la base de dades dins el servidor PostgreSQL.
– El nom de la base de dades no permet caràcters especials ni espais

en blanc. Únicament caràcters normals i el guió baix. En aquest cas
l’anomenem Empresa_IOC.
– El client GTK no distingeix entre majúscules i minúscules i crea la
base de dades amb el nom en minúscules. En canvi, el client web sí
que manté les majúscules.
• Marca per la càrrega de dades de demostració: en una instal·lació per

gestionar una empresa aquesta opció mai s’activa, però a nosaltres ens
interessa activar-la per poder disposar d’una empresa amb dades (clients,
productes, proveïdors...) i poder començar a provar el funcionament
d’OpenERP.
• L’idioma per defecte quan l’usuari administrador (admin) es connecti:

posteriorment es pot canviar.
• Contrasenya per l’usuari administrador (admin) de l’empresa que

estem creant: cal recordar que el procés de creació d’una empresa crea
l’empresa amb l’usuari admin i una contrasenya d’obligada introducció en
el moment de creació. També crearà un usuari de nom demo i contrasenya
demo en cas de carregar les dades de demostració.
Així doncs, seleccioneu l’idioma que cregueu oportú, assigneu la contrasenya per
l’usuari admin de la nova base de dades i procediu a executar la creació. El procés
pot durar uns minuts.
Una vegada finalitzat, si entrem a l’empresa des del client web amb l’usuari
admin ens apareix una pantalla com la de la figura 2.15, amb una única pestanya,
Configuració, i una llista dels mòduls que podem instal·lar a la pantalla.
Fi g ura 2.1 5 . Pantalla inicial des del client web quan es connecta amb una empresa
com a usuari admin
L’entrada des del client GTK sembla diferent però és totalment equivalent, ja que
ens mostra el contingut del menú Configuració idèntic al que veiem des del client
web si escollim la pestanya Configuració. La figura 2.16 ens mostra la pantalla
del client GTK.
Fig u ra 2 . 16 . Pantalla inicial des del client GTK quan ens connectem amb una empresa
com a usuari admin
Observem que tant en el client web com en el client GTK hi ha una zona de
dreceres per contenir les opcions més habituals i, en aquest moment, únicament
hi ha l’opció Clients. Si la seleccionem des de qualsevol dels dos clients veurem
que la nostra empresa ja té un seguit de socis de negocis introduïts (OpenERP els
anomena Clients). La figura 2.17 ens mostra la visualització dels clients des del
client GTK.
F igu r a 2 . 17 . Visualització dels clients que carrega OpenERP en crear una empresa, si així se li indica
La figura 2.17 mostra el contingut de l’opció de menú anomenada Clients però en

el seu interior hi observem uns botons per seleccionar clients o proveïdors o bé
ambdós. La nomenclatura que utilitza OpenERP no sembla prou adequada ja que
sota l’opció Clients es gestionen totes aquelles entitats amb les quals podem fer
negocis. Seria més adequada la nomenclatura que utilitzen altres ERPs: Socis de
negoci (Business partners) o Tercers o Interlocutors comercials.
Si tanquem la connexió (des del client web amb l’enllaç Logout de la part superior
dreta de la pantalla o bé amb el client GTK des de l’opció de menú Fitxer |
Desconnecta) i procedim a entrar com a usuari demo amb contrasenya demo,
veurem que la connexió s’estableix però que no hi ha cap opció de menú ni drecera
disponible.
La creació d’una empresa implica l’aparició, en el servidor PostgreSQL, d’una

base de dades amb el nom indicat en el procés de creació. Així, si utilitzem
pgAdmin per accedir al servidor PostgreSQL, hi observarem l’aparició de la base
de dades de nom Empresa_IOC, com mostra la figura 2.18.
Fig u ra 2. 18 . Visualització de la base de dades corresponent a l’empresa Empresa_IOC d’OpenERP
Si observem el contingut de la base de dades Empresa_IOC veurem que conté 107

taules i 86 seqüències, dins l’esquema public. Fixem-nos que no hi ha cap funció
ni cap disparador definits, és a dir, tota la lògica de negoci resideix en el servidor
OpenERP.
Observem, també, que el propietari de la base de dades és el superusuari de

PostgreSQL que utilitza el servidor OpenERP per connectar-se amb el servidor
PostgreSQL.
Situant-nos damunt una taula i prement el botó secundari del ratolí podem executar
diverses accions: crear noves taules, eliminar la taula, veure el contingut de la
taula, etc.
La manipulació de les estructures de dades (taules, seqüències, disparadors,

vistes, funcions...) d’una base de dades d’un ERP mai s’hauria d’efectuar, a
no ser que seguim un protocol clarament definit pel fabricant de l’ERP.
L’interès que té l’accés directe a la base de dades es basa en:
• Recuperar noms i contrasenyes dels usuaris d’OpenERP. Per aconseguir-ho,

només cal situar-nos damunt la taula res_users, prémer el botó secundari
del ratolí i escollir Ver Datos. Allí hi veurem els usuaris d’OpenERP de
l’empresa amb les seves contrasenyes.
• Definir consultes (vistes) per tal que usuaris de l’organització puguin

executar-les i obtenir dades amb una estructura que potser no facilita l’ERP.
• Dissenyar i executar algun procés d’actualització de les dades emmagatze-

mades, per solucionar possibles errors produïts per una manipulació errònia
de l’ERP. Això només és factible si es té un coneixement profund de
l’estructura de la base de dades de l’ERP i el fabricant de l’ERP mai es farà
responsable de la coherència de les dades emmagatzemades si es manipulen
les dades des de fora de l’ERP.
2.6.2 Eliminació d’empreses
L’eliminació d’una empresa implica l’eliminació de la corresponent base de dades

i es pot efectuar des de qualsevol dels dos clients (web i GTK):
1. Des del client web, executant l’opció Manage Databases de la pàgina inicial.
2. Des del client GTK, des de l’opció Fitxer | Base de dades.
Per poder eliminar una base de dades d’un servidor OpenERP haurem d’indicar
la contrasenya del superadministrador del servidor OpenERP (admin, si no s’ha
canviat) i no hi pot haver cap connexió oberta contra la base de dades (si hi fos,
l’eliminació no es duria a terme).
2.7 Iniciació bàsica a OpenERP
El procés de creació d’una empresa a OpenERP crea la base de dades en el servidor

PostgreSQL, amb l’usuari admin (i l’usuari demo si s’ha carregat les dades de
OpenERP 6.1 instal·la 107 demostració) i hi crea les taules i les seqüències necessàries per a la gestió de
taules i 86 seqüències a la
base de dades en el procés l’ERP. Algunes de les taules contindran informació en cas que en el procés de
de creació d’una empresa.
creació s’hagi indicat la càrrega de dades de demostració.
La creació d’una empresa instal·la únicament el mòdul Base d’OpenERP que

incorpora, com es pot veure a la figura 2.19, l’opció de menú Configuració i
una drecera a una fitxa bàsica de Socis de negocis (Clients segons nomenclatura
OpenERP però que en realitat inclou les entitats amb les quals es fa negocis i que,
per tant, poden ser clients o proveïdors).
Fi g ura 2 .19 . Opcions possibles en una empresa d’OpenERP acabada de crear
La figura 2.19 mostra les opcions possibles en una empresa acabada de crear. Hi
veiem l’opció de menú Configuració que conté diverses opcions de configuració
(Mòduls, Configuració, Companyies, Usuaris, Traduccions, Garantia) i la drecera
Clients. Fixem-nos que la majoria d’opcions són en català, però hi trobem algunes
paraules en anglès (Sequences&Identifiers...). OpenERP es desenvolupa en anglès
i permet incorporar traduccions a diferents idiomes, però en ocasions aquestes
traduccions no són completes o no evolucionen tant ràpidament com evoluciona
l’ERP i quan una opció de l’aplicació no té definida la traducció en l’idioma actiu,
OpenERP en mostra la versió anglesa.
La figura 2.19 mostra moltes opcions en català perquè en el procés de creació

de l’empresa hem assignat l’idioma català a l’usuari admin. A causa d’aquest fet,
l’empresa creada disposa de dos idiomes carregats: anglès i català. Qualsevol dels
usuaris de l’empresa pot fixar l’idioma que desitgi, d’entre els idiomes carregats
a l’empresa, en les seves preferències.
Arribats aquí, per poder utilitzar significativament l’OpenERP ens cal saber:
• Com incorporar idiomes i com un usuari pot escollir l’idioma preferent.
• Com funcionen les interfícies web i GTK.
• Com configurar les dades bàsiques d’una empresa (companyies, nom, logo,
etc).
• Com incorporar els mòduls que siguin necessaris per a l’organització.
• Com crear usuaris i assignar-los-hi privilegis d’accés.

2.7.1 Incorporació d’idiomes
La incorporació d’idiomes en una empresa OpenERP és molt simple i es pot

executar des de qualsevol dels clients OpenERP, quan s’estableix connexió amb
l’usuari admin i es navega fins l’opció Configuració | Traduccions | Càrrega una
traducció oficial.
L’execució d’aquesta opció facilita una pantalla com la de la figura 2.20, que
conté el desplegable idioma que ens permet escollir un dels idiomes que incorpora
OpenERP.
Fig u ra 2 . 2 0 . Pantalla d’OpenERP per carregar un nou idioma a l’empresa activa
Una vegada seleccionada i executada la càrrega, qualsevol usuari pot seleccionar

el nou idioma com a preferent, fet que es pot dur a terme:
• En el client GTK, per l’opció Usuari | Preferències. Cal tancar el menú i

tornar-lo a obrir per veure les opcions en el nou idioma.
• El client web, pel botó Preferències de la part superior dreta de la pàgina.

En aquest cas, el canvi cap al nou idioma és automàtic.
2.7.2 Iniciació a les interfícies web i GTK
Als annexos del web

trobareu l’apartat Per dur a terme la implantació tècnica de l’OpenERP és altament recomanable
“Iniciació a les interfícies
web i GTK d’OpenERP” conèixer el funcionament de les interfícies web i GTK facilitades per OpenERP.
que facilita alguns
enllaços a materials
existents destinats a Per aconseguir-ho, a banda de dedicar-hi temps i aplicar la intuïció que de
iniciar-nos en els clients
web i GTK subministrats ben segur tenim desenvolupada gràcies a haver utilitzat una gran quantitat de
per OpenERP.
programaris, utilitzarem alguns dels materials existents al web.
El servidors OpenERP 6.1 instal·lats en el SO Windows amb PostgreSQL 9.1

presenten un problema: les imatges (icones, logo de companyia, imatges de
productes, etc.) no es visualitzen. El procés d’incorporació de qualsevol imatge
funciona perfectament però, una vegada incorporada, OpenERP (client web i
GTK) no la visualitza. La solució és efectuar un canvi en la configuració
del servidor PostgreSQL 9.1, concretament en el fitxer postgresql.conf on cal
substituir la línia:
1 #bytea_output = ’hex’ # hex, escape
per:
1 bytea_output = ’escape’ # hex, escape
i posteriorment cal reiniciar el servidor PostgreSQL i el servidor OpenERP.
2.7.3 Configuració bàsica d’una empresa
El procés de creació d’una empresa no demana cap dada de l’empresa i, per tant,
pertoca fer a posteriori el procés de configuració. Aquest procés es pot dur a terme
a través de qualsevol dels clients OpenERP, establint connexió amb l’usuari admin
i navegant fins l’opció Configuració | Companyies | Companyies.
L’execució d’aquesta opció mostra la pantalla de la figura 2.21, en la qual podem

observar l’existència d’una única companyia o empresa, amb nom Your Company
però amb la possibilitat de crear més companyies.
OpenERP permet que una empresa estigui estructurada en moltes companyies, fet
que s’anomena gestió multicompanyia.
Fi g ura 2 .2 1 . Pantalla de configuració de les dades de l’empresa i les seves companyies

La utilització de diverses companyies en una empresa està justificada en un

entorn amb diverses organitzacions que treballen de forma independent (clients
o proveïdors propis, productes propis, magatzems propis, pla comptable propi,
etc.) però que estan sota l’aixopluc d’una organització mare, que pot voler veure,
en un determinat moment, els resultats globals.
La gestió multicompanyia es troba en empreses grans (hi pot haver PIMES amb
gran implantació en les quals aquesta situació també sigui normal). OpenERP no
limita l’estructura multicompanyia a dos nivells, sinó que permet més nivells.
Si treballem en un entorn multicompanyia, haurem de tenir en compte:
• En gestionar els usuaris de l’empresa, haurem d’indicar les companyies a

les quals té accés l’usuari. Cal tenir clar que l’assignació d’una companyia
a un usuari implica l’accés d’aquest usuari a les operacions de la companyia
i de les companyies filles.
• Quan es gestionin els tercers (Clients d’OpenERP), cal assignar cada soci
(client o proveïdor) a la companyia que correspongui. S’ha de tenir clar que
l’assignació d’un tercer a una companyia implica l’accés des de qualsevol
companyia filla a la companyia a la qual està assignat.
Exemple d’una instal·lació OpenERP amb multicompanyia
Suposem que la multinacional X té diverses empreses en diversos estats: X-Espanya,

X-França, X-Bèlgica... OpenERP permet, en aquest cas, crear l’empresa X i dins d’ella
crear-hi tantes companyies com nombre de països en els quals es troba implantada. Per
aconseguir-ho, s’han d’anar creant companyies (X-Espanya, X-França, X-Bèlgica) i a cada
companyia s’ha d’assignar com a empresa matriu (segons la figura 2.21), l’empresa X
(que no deixa de ser una companyia). D’aquesta manera s’aconsegueix una estructura
jeràrquica de dos nivells amb la companyia X com a arrel i les companyies X-Espanya,
X-Bèlgica i X-França com a filles de l’arrel.
Suposem que X-Espanya té dues sucursals fiscalment independents a Euskadi i a

Catalunya. OpenERP permet crear les companyies X-Esp-Euskadi i X-Esp-Catalunya
assignant-los X-Espanya com a empresa matriu, de manera que podem aconseguir una
estructura multicompanyia de tres nivells com mostra la figura 2.22.
Si a un usuari li assignem la companyia X-Espanya, tindrà accés a les operacions

efectuades des d’X-Espanya i també a les operacions d’X-Esp-Catalunya i X-Esp-Euskadi,
mentre que no tindrà accés a les operacions d’X-França ni d’X-Bèlgida ni d’X.
Si un tercer l’assignem a X-Esp-Catalunya, podrà ser gestionat pels usuaris amb accés a
les companyies X, X-Espanya i X-Esp-Catalunya, però en canvi no podrà ser gestionat pels
usuaris que només tinguin accés a X-França o X-Bèlgica o X-Esp-Euskadi.
La visualització jeràrquica de la figura 2.22 és factible, per l’usuari admin des de

Configuració | Companyies | Arbre de la companyia, opció que apareix si s’ha
activat la casella Usability | Multi companies de la pestanya Permisos d’accés de
la fitxa de l’usuari admin (figura 2.23), accessible des de Configuració | Usuaris |
Usuaris.
Fi gura 2 .22 . Visualització jeràrquica de les companyies existents a l’empresa
Fi gura 2. 2 3 . Casella de la fitxa d’usuari per permetre la visualització jeràrquica de les

companyies de l’empresa
Cada companyia pot tenir el seu propi pla comptable i es pot, si es desitja, vincular
a un tercer pla comptable per tal d’efectuar una consolidació de les diverses
companyies.
OpenERP permet establir valors per defecte en camps de formularis diferents per a
cada companyia, de manera que quan un usuari utilitza el formulari, els valors que
se li presenten són els que corresponen a la companyia amb la qual està treballant
l’usuari.
Cal tenir clar, però, que cada companyia (inclosa la companyia mare) ha de ser
convenientment configurada. La figura 2.24 mostra la vista del formulari de la
companyia mare (inicialment anomenada Your company) una vegada configurada
amb les dades de l’IOC.
A banda de les dades que mostra la figura 2.24, cal tenir en compte:
• La pestanya Configuració del formulari, que permet configurar la moneda

base de la companyia (A
C en el nostre cas)
• El botó Set Bank Accounts que ens remet a un formulari on podem donar
d’alta els comptes bancaris de la nostra companyia.
Fixem-nos que el camp Província està buit. Si premem la lupa que l’acompanya,
podrem constatar que la nostra empresa no conté les províncies de l’estat espanyol
de la mateixa manera que tampoc conté moltes de les dades necessàries per
a la gestió d’una empresa espanyola. Podem anar incorporant les dades a
mesura que les necessitem, però no és una pràctica aconsellable. Els grups de
treball d’OpenERP dels diversos països han desenvolupat mòduls de localització
específics de cada país que incorporen la majoria de dades específiques bàsiques
per a la gestió d’empreses. Per tant, ens caldrà instal·lar el mòdul de localització
espanyola. De moment, però, deixem el camp província en blanc.
Fig u ra 2 . 2 4 . Exemple de configuració de les dades d’una companyia de l’empresa
El botó Preview Header ens permet generar un informe que mostra com es visualit-
zarà la informació introduïda en els diversos documents que generi OpenERP. Si
l’executeu podreu observar que la capçalera (figura 2.25) i el peu (figura 2.26)
mostren la informació introduïda en el formulari acompanyada d’uns títols en
llengua anglesa que no han estat traduïts a l’idioma actiu (català). Un usuari
que tingui activada la casella Usability | Extended view de la pestanya Permisos
d’accés de la seva fitxa (figura 2.30), té accés a modificar la plantilla (capçalera i
peu) dels informes.
Fi gura 2 .25 . Exemple de la capçalera de la documentació generada per OpenERP
Fi gura 2 .26 . Exemple del peu de la documentació generada per OpenERP
2.7.4 Instal·lació de mòduls
L’OpenERP, una vegada instal·lat, presenta una funcionalitat molt limitada, ja

que únicament facilita la possibilitat d’introduir els socis de negocis i amb una
funcionalitat molt bàsica (per exemple, obliga que un contacte de soci de negocis
tingui una adreça en concret i no permet vincular un contacte a diverses adreces o
una adreça a diversos contactes).
La funcionalitat tan limitada d’OpenERP en la instal·lació és causada pel fet que

aquest ERP és totalment modular i espera que cada organització instal·li únicament
les funcionalitats (mòduls) requerides, per evitar tenir un ERP amb moltes opcions
no utilitzades.
Quan parlem de mòduls instal·lables, hem de distingir:
• Mòduls oficials que facilita OpenERP i que el procés d’instal·lació deixa en

el sistema d’arxius de la màquina on s’ha instal·lat el servidor OpenERP.
Entre aquests cal diferenciar els mòduls que corresponen a aplicacions
senceres.
• Mòduls no oficials, desenvolupats per la comunitat OpenERP i que podem

descarregar-nos del web. En aquest cas, per a fer-los instal·lables caldrà
deixar-los a la mateixa ubicació on resideixen els mòduls oficials subminis-
trats per OpenERP i executar un petit procés que els afegeixi a la llista de
mòduls instal·lables.
• Mòduls dissenyats per nosaltres i que instal·larem de la mateixa manera que

els mòduls no oficials descarregats del web.
Instal·lació de mòduls oficials
Per exemplificar la instal·lació d’un mòdul oficial, instal·larem el mòdul ba-

se_contact per augmentar la funcionalitat a nivell dels contactes dels nostres socis
de negocis.
Entreu a la fitxa de qualsevol client o proveïdor i observeu la pestanya General

que inclou els diversos contactes del soci de negocis amb l’adreça postal de cada
contacte. La figura 2.27 mostra, pel client Agrolait, les dades del contacte Silvie
Lelitre (adreça postal, telèfon, mòbil, fax, etc). La mateixa pestanya ens informa
que estem visualitzant el primer d’un total de tres contactes que tenim per aquest
client.
Suposem que pel tipus de negoci de la nostra organització és força comú que
una mateixa persona pugui ser contacte de diversos socis de negocis. En aquesta
situació, hauríem de donar d’alta la mateixa persona com a contacte en diferents
socis i no tindríem manera de, donada una persona d’alta, introduir les seves dades
personals (úniques) i les seves dades professionals (diferents per a cada soci de
negoci).
El mòdul base_contact independitza la definició dels contactes de la definició

dels socis de negoci, de manera que, una vegada instal·lat el mòdul, disposarem
d’una opció de menú per donar d’alta els contactes, amb les seves dades personals
(úniques) i podrem assignar-los a un o a diversos socis de negocis, indicant les
dades específiques del contacte per a cada soci.
F igu r a 2. 27 . Formulari Clients en el seu estat inicial, en el qual cada contacte només pot tenir una
adreça
Exemple de la utilitat de la instal·lació del mòdul base_contact
Suposem que el Sr. Pepe Gotera és un assessor d’empreses i presta els seus serveis
d’assessoria a l’empresa Agrolait i a l’empresa Axelor. Suposem que disposem de dades
personals del Sr. Pepe Gotera (foto, telèfon, mòbil) i que també disposem de dades
específiques quan actua com a assessor de cada empresa. OpenERP en el seu estat
inicial no ens permet introduir les dades personals del Sr. Pepe Gotera, hauríem de donar
d’alta el Sr. Pepe Gotera de cada una de les dues empreses i no tindríem manera de saber
que el mateix Sr. Pepe Gotera és contacte de diversos socis de negocis. La instal·lació del
mòdul base_contact ens solucionarà el problema.
Abans d’instal·lar-lo, donem accés al mòdul de vendes en el seu estat inicial a

l’usuari admin, fet que aconseguim assignant el valor User o Manager en el camp
Application | Sales Management de la pestanya Permisos d’accés de la seva fitxa,

accessible des de Configuració | Usuaris | Usuaris. Una vegada activada aquesta
opció, si refresquem el menú, observarem l’aparició del menúVendes amb algunes
opcions. Hem activat aquesta opció per constatar que la instal·lació del mòdul
base_contact provocarà l’aparició de més opcions en aquest menú.
Per instal·lar un mòdul d’OpenERP, l’usuari admin disposa de l’opció Configura-

ció | Mòduls | Mòduls, que facilita la llista de tots els mòduls instal·lables. La
figura 2.28 mostra la llista que apareix en executar aquesta opció. Hi podem
observar els botons Apps i Extra, amb el primer d’ells seleccionat. Fixem-nos
que en aquesta situació, la llista conté 19 mòduls. Si desmarquem el botó Apps
i seleccionem el botó Extra, el contingut de la llista de mòduls canvia i passem
a tenir 184 mòduls diferents dels 19 anteriors. Si seleccionem ambdós botons la
llista de mòduls incorpora 203 mòduls.
Recordeu que en entrar amb el client web, OpenERP ens mostra una pantalla
inicial amb una llista de mòduls a instal·lar. Fixeu-vos que aquella llista conté
19 mòduls, que es corresponen amb els mòduls Apps de la llista de mòduls
instal·lables.
Fig u ra 2. 28 . Llista de mòduls Apps oficials d’OpenERP 6.1
OpenERP classifica els mòduls oficials (203 en la versió 6.1) entre Apps, corres-
ponents a mòduls que per si sols es poden considerar com a aplicacions (gestió de
vendes, gestió de compres, CRM, MRP, recursos humans...) i Extra, corresponents
a mòduls que afegeixen funcionalitats extres.
El mòdul base_contact és un mòdul extra. Ens hi situem damunt i per instal·lar-lo

disposem de dues possibilitats:
1. Amb vista de llista cal utilitzar el botó Install que hi ha a la columna de més
a la dreta.
2. Amb vista de formulari cal prémer el botó Install.
La vista formulari ens facilita informació que pot ser del nostre interès:
• A la pestanya Mòdul: informació sobre les funcionalitats que facilita el

mòdul que volem instal·lar i les implicacions en les dades ja existents.
• A la pestanya Dependències: la llista de mòduls dels quals depèn i el seu

estat d’instal·lació.
En el cas del mòdul base_contact, observem que depèn de dos mòduls:
1. Mòdul base, ja instal·lat.
2. Mòdul process, no instal·lat.
El fet que hi hagi mòduls no instal·lats no ens ha de preocupar, ja que si posem en

marxa la instal·lació, OpenERP s’encarregarà d’instal·lar-los.
F ig ura 2. 2 9 . Pantalla que informa dels

mòduls a instal·lar o actualitzar quan s’ins-
tal·la un mòdul
Si premem el botó Install per al nostre mòdul ens apareix la pantalla de la figura
2.29, que ens informa de tots els mòduls que s’instal·laran o actualitzaran. Hi
veiem el mòdul que volem instal·lar (base_contact), el mòdul depenent process
i d’altres mòduls que alguna dependència deuen tenir però que no ens ha estat
informada en el mòdul base_contact ni en el mòdul process. La pantalla ens
informa que l’actualització pot trigar alguns minuts i ens facilita dos botons:
1. Actualitza: per executar l’actualització.
2. Cancel·la: per cancel·lar l’actualització.

En aquests moments podríem procedir a Actualitzar, però en altres ocasions ens

interessarà Cancel·lar l’acció perquè potser volem instal·lar més mòduls i volem
que l’actualització (que pot necessitar alterar l’estructura de taules dins la base
de dades i executar processos de reforma de dades) s’efectuï en un sol procés
per minimitzar el temps d’execució. També és possible que vulguem Cancel·lar
l’acció perquè, veritablement, volem no dur a terme la instal·lació que havíem
iniciat. De moment, comencem amb Cancel·lar.
Una vegada cancel·lada l’actualització, tots els mòduls que havien estat selec-
cionats per ser instal·lat o actualitzats continuen en estat de ser instal·lats o
actualitzats, fet que es pot observar a la columna Estat de la llista de mòduls.
Si la cancel·lació és motivada perquè, veritablement, volem oblidar-nos de la

instal·lació, cal anar als mòduls que han quedat amb la marca Per ser instal·lat,
entrar a la vista formulari i prémer el botó Cancel·la la instal·lació.
Si la cancel·lació ha estat motivada perquè volem executar l’actualització més

tard, necessitem saber com posar-la en marxa en el moment que ens convingui.
Per aconseguir-ho, s’han de donar més permisos a l’usuari admin ja que, tot i ser
administrador, tal com el configura el procés d’instal·lació d’OpenERP, no té accés
a aquesta opció.
Per tal que l’usuari admin pugui engegar el procés d’actualització de mòduls quan
ho cregui convenient, ha de tenir activada la casella Usability | Extended view
de la pestanya Permisos d’accés de la seva fitxa (figura 2.30), accessible des de
Configuració | Usuaris | Usuaris.
Fi gura 2.3 0 . Casella de la fitxa d’usuari per permetre la visió d’opcions de menú no
visibles normalment
Una vegada activada la casella Extended View i després de refrescar el menú

d’OpenERP, veurem com l’usuari admin té accés a més opcions en el menú
Configuració. Concretament ens interessa l’opció Configuració | Menús | Aplica
actualitzacions programades, que provoca l’aparició de la pantalla de la figura
2.29, que inclou totes les instal·lacions i/o actualitzacions pendents d’executar i
que podem posar en marxa prement el botó Actualitza. El premem i esperem a la
finalització.
Mentre s’està duent a terme un procés d’actualització no hi hauria d’haver cap

usuari connectat a l’empresa que s’està actualitzant.
Quan es finalitza l’actualització, apareix la pantalla de la figura 2.31, que ens

permet iniciar la configuració automàtica vinculada als mòduls instal·lats (no
sempre els mòduls instal·lats porten un procés de configuració associat, però
aquesta pantalla apareix sempre). Si premem el botó Start configuration no
veiem res, a causa que els mòduls instal·lats no porten cap procés de configuració
automàtic.
F i g ura 2 .3 1 . Pantalla que apareix després de la ins-
tal·lació de mòduls i que permet iniciar el procés de confi-
guració
Una vegada instal·lat el mòdul base_contact, refresquem el menú i observem:
• En el menú Vendes hi ha més opcions de les que hi havia abans de la

instal·lació. Concretament hi observem les opcions Contactes i Adreces.
• Els contactes previs en cada soci de negoci ja no són actualitzables des del
formulari dels socis de negocis i són accessibles per la nova opció Contactes.
• El formulari del socis de negocis només permet assignar contactes prèvia-

ment donats d’alta per la nova opció Contactes.
Exemple d’introducció d’un contacte comú a diversos tercers
Per introduir el Sr. Pepe Gotera com a assessor per les empreses Agrolait i Axelor, donarem
d’alta el contacte utilitzant el formulari mestre-detall de la nova opció Contactes. A la
zona de detall donem d’alta les dues empreses de les quals és assessor amb les dades
professionals de contacte corresponents, tal com mostra la figura 2.32.
Podem comprovar que la informació introduïda pel formulari mestre detall de la opció
Contactes que facilita el mòdul base_contact, és accessible des del formulari de gestió
dels socis de negocis. En efecte, si consultem els clients Agrolait i Axelor hi veurem el Sr.
Pepe Gotera com a assessor.
Una vegada conegut el procés a seguir per instal·lar els mòduls, si suposem que la
nostra organització compra i ven i necessita portar la comptabilitat, sembla lògic
procedir a instal·lar els mòduls oficials següents:
• Sales Management, per a la gestió de vendes.
• Purchase Management, per a la gestió de compres.
• Customer Relationship Management (CRM).
• Accounting and Finance, per donar accés a l’usuari admin al mòdul de

comptabilitat, per tal de poder-lo administrar i donar accessos a altres
usuaris.
• eInvoicing & Payments, per gestionar la facturació electrònica i tot tipus de

pagaments (xecs, targes bancàries, efectiu...).
F igur a 2. 3 2 . Exemple d’alta de contacte amb diversos càrrecs en diferents

empreses
Fixeu-vos que tots aquests mòduls són dels considerats Apps per OpenERP. Podeu,
si ho desitgeu, instal·lar la resta de mòduls Apps facilitats per OpenERP.
Si procediu a instal·lar, com a mínim, els mòduls indicats anteriorment, si quan

apareix la pantalla de la figura 2.31 premeu el botó Start Configuration es posa en
marxa un procés de configuració, Configuració de l’aplicació de comptabilitat.
Per a una correcta configuració de l’aplicació de comptabilitat, convindria tenir

coneixements de comptabilitat.
La primera pantalla del procés de configuració de l’aplicació de comptabilitat

(figura 2.33) ens demana:
• Resum de comptes: ens proposa Generic Chart of Accounts, però es tracta

d’escollir el pla comptable corresponent al país al què pertany l’empresa. El
pla proposat (genèric) s’utilitzaria en cas de no disposar del pla de comptes
específic pel país. Si obrim el desplegable, veiem que OpenERP incorpora
diversos plans comptables i a nosaltres ens interessa escollir l’anomenat
Spanish Charts of Accounts (PGCE 2008) que correspon al Pla General

Comptable Espanyol del 2008 (actualment vigent).
• Dates inicial i final de l’exercici fiscal: OpenERP ens proposa com a

exercici fiscal l’any natural corresponent a la data actual. La majoria
d’empreses tenen com a exercici fiscal l’any natural, però hem de saber que
hi ha excepcions i, per exemple, per una empresa de caire agrícola, l’any
fiscal podria anar des de l’1 de setembre d’un any fins el 31 d’agost de l’any
següent.
• Períodes: l’any fiscal es divideix en períodes comptables que poden ser

mesos o trimestres. És molt usual treballar amb períodes mensuals.
F igu r a 2. 3 3 . Primera pantalla del procés de configuració de l’aplicació de comptabilitat
Una vegada emplenats els camps de la pantalla de la figura 2.33, procedim

a prémer el botó Configura per tal que continuï amb el procés. La següent
pantalla que apareix (figura 2.34) ens permet prendre més decisions pel que fa
a la generació del pla comptable:
F igu r a 2. 3 4 . Segona pantalla del procés de configuració de l’aplicació de comptabilitat
1. Número de dígits a utilitzar pel pla de comptes: ens proposa el valor 6. Si

pretenem treballar amb un pla de comptes molt detallat potser ens interessa
treballar amb un valor més alt (8 o 10), ja que disposarem de més dígits
que ens permetran especificar més conceptes (un concepte = un compte
comptable). Nosaltres hi deixem el valor 6.
2. Plantilla del pla comptable: si despleguem la llista d’aquest camp veiem

que l’OpenERP ens facilita dues opcions: Plantilla PGCE 2008 completo
i Plantilla PGCE 2008 PIMES. El PCGE del 2008 classifica les comptes
comptables en 9 grups, dels quals els grups 8 i 9 no són obligatoris per
les PIMES. Per aquest motiu es faciliten dues plantilles: PGCE complet i
PGCE per PIMES. Nosaltres escollirem el de les PIMES.
3. Impostos de venda i de compra per defecte: cal indicar els impostos

de venda i de compra que més habitualment utilitza la nostra empresa.
Si despleguem les llistes de valors possibles, observem que la versió que
instal·lem no incorpora els nous tipus impositius que entren en vigor a
Espanya l’1 de setembre del 2012 (21% pel tipus normal i 10% pel tipus
reduït). Hi veiem els tipus impositius vàlids fins el 31 d’agost del 2012
(18% i 8% respectivament) i també els tipus impositius vàlids abans del 30
de juny del 2009 (16% i 7%). Aquests últims no es poden eliminar per si
l’ERP conté informació d’exercicis fiscals anteriors.
Des del desplegable per seleccionar el tipus d’IVA tenim la possibilitat, si tenim
coneixements clars de comptabilitat, de definir tota la informació necessària per
donar resposta als requeriments impositius que entren en vigor l’1 de setembre del
2012. Però en cas de no tenir els coneixements de comptabilitat necessaris i de no
disposar d’un consultor, cal confiar que en les properes versions d’OpenERP ja hi
haurà els nous tipus impositius.
Si no podem esperar, cal tenir en compte que allà on té força l’OpenERP hi

acostuma a haver un equip de treball que desenvolupa mòduls específics per
adaptar l’OpenERP a les lleis i a les necessitats de la zona: són els anomenats
mòduls de localització i, en el nostre cas, tenim l’Spanish Localization Team que
és el responsable del mòdul Spanish Charts of Accounts (PGCE 2008) i que, a les
acaballes del mes d’agost, segur que ja ha actualitzat el mòdul amb la incorporació
dels nous tipus impositius.
Tenim tres opcions:
1. Posar-nos a definir els nous tipus d’impostos. Aquesta opció ja l’hem

descartada per manca de coneixements comptables i implicacions dins
l’ERP.
2. Continuar el procés de configuració de l’aplicació comptable, assignant els

tipus impositius actuals (agost del 2012) per, posteriorment, actualitzar el
mòdul Spanish Charts of Accounts (PGCE 2008) amb els materials que hagi
subministrat l’Spanish Localization Team i, finalment, canviar manualment
els tipus d’IVA i els comptes comptables corresponents als IVA repercutit i
suportat.
3. Avortar el procés de configuració de l’aplicació comptable per actualitzar

el mòdul Spanish Charts of Accounts (PGCE 2008) i, finalment, reiniciar el
procés de configuració de l’aplicació comptable.
En el moment actual disposem d’una versió actualitzada del mòdul Spanish Charts
of Accounts i, per tant, l’opció 3 és la més còmoda. Avortem, el procés de
configuració per procedir a l’actualització del mòdul Spanish Charts of Accounts

(PCGE 2008).
Hem avortat el procés de configuració de l’aplicació de comptabilitat, però els

mòduls s’han instal·lat. Si refresquem el menú, hi apreciem moltes més opcions:
Vendes, Compres, Magatzem, Comptabilitat i Configuració.
Si fem una ullada a la llista de mòduls instal·lats (sigui Apps o Extra), hi trobarem
el mòdul Spanish Charts of Accounts (PCGE 2008), sota el nom l10n_es. En
OpenERP, tots els mòduls de localització tenen el prefix l10n_seguit de les sigles
del país i, si cal, un sufix per distingir diversos mòduls de localització d’un mateix
país. Si mirem la llista de mòduls no instal·lats, veurem una llarga llista de mòduls
Cerqueu amb el prefix l10n_.
Internacionalització i
Localització a la
Viquipèdia per conèixer el Com podem aconseguir una versió actualitzada d’un mòdul? Hi ha dos camins:
significat dels prefixos
numerònims l10n_ i i18n_.
1. Visitar la pàgina web oficial de complements (add-ons) d’OpenERP

(apps.openerp.com) per veure si hi ha l’actualització desitjada.
2. Visitar la pàgina dels desenvolupadors del mòdul, per veure si hi ha

alguna versió disponible que encara no ha estat pujada al web oficial de
complements d’OpenERP. En el cas de l’Spanish Localization Team, la
pàgina és https://launchpad.net/openerp-spain i per descarregar els mòduls
es necessita l’eina Bazaar.
F igu r a 2 . 3 5. Contingut del mòdul l10n_es en la pàgina de complements d’OpenERP a finals d’agost
del 2012
El camí fàcil i còmode és cercar el mòdul al web oficial de complements

d’OpenERP. Així doncs, hi cerquem el mòdul l10n_es i en trobem (figura 2.35):
• 3 versions del mòdul per la versió 6.0 d’OpenERP.
• 1 versió del mòdul per la versió 6.1 d’OpenERP, amb data de 23-08-2012
(actual) ubicada en el repositori “lp:openerp-spain/6.1” (branca 6.1 del
projecte ubicat a https://launchpad.net/openerp-spain)
La pàgina no mostra cap informació referent a la incorporació dels nous tipus

impositius, però l’autor d’aquests materials està subscrit al Google Group openerp-
spain on segueix les aventures i desventures dels usuaris i desenvolupadors
d’OpenERP – Spain i, per tant, està gairebé segur que el mòdul l10n_es del 23-08-
2012 ja incorpora els nous tipus impositius. Baixem-nos aquest mòdul i instal·lem-
lo. Als annexos del web
Per actualitzar un mòdul de nom xxx instal·lat a l’OpenERP, cal seguir el següent que inclou el fitxer
l10n_es_20120823.zip
procés: corresponent al mòdul
que volem actualitzar.
1. Substituir la carpeta xxx existent en el directori camíOnResideixOpenERP/-

Server/server/openerp/addons per la carpeta d’idèntic nom corresponent a
la nova versió del mòdul a actualitzar.
2. Des de qualsevol client d’OpenERP, connectat amb usuari admin, anar a la

llista de mòduls instal·lats, situar-se a actualitzar amb vistes de formulari
i prémer el botó Upgrade. Apareix una finestra (figura 2.36) que ens
avisa que el mòdul està en situació de ser actualitzat i procedim a executar
l’actualització.
En el cas que ens ocupa, després d’actualitzar el mòdul l10n_es, ens interessa
tornar a engegar el procés de configuració de l’aplicació de comptabilitat, fet que
aconseguim via l’opció Comptabilitat | Configuració | Comptabilitat financera
| Configuració financera per una nova companyia (cal tenir instal·lat el mòdul
Accounting and Finance). El procés torna a començar amb la pantalla de la figura
2.33, que emplenem convenientment i continua amb la pantalla de la figura 2.34,
on ja podem assignar els tipus impositius del 21% com a valors per defecte per les
vendes i les compres, si aquest és el cas. Continuem amb el procés i la configuració
de l’aplicació comptable finalitza.
Una vegada instal·lats els mòduls de vendes, compres, emmagatzematge, compta-

bilitat i CRM, si fem una visita a la base de dades, veurem que de les 107 taules i
86 seqüències inicials hem passat a 385 taules, 335 seqüències i 20 vistes.
Fig ur a 2 . 3 6 . Pantalla que informa de

l’actualització d’un mòdul ja instal·lat
Instal·lació de mòduls no oficials
Els mòduls oficials d’OpenERP que vénen inclosos en la distribució de l’ERP

cobreixen una gran quantitat de necessitats. Però la diversitat de normatives
entre els diferents estats i les particularitats de funcionament dels diversos sectors
productius en els quals podem utilitzar l’ERP provoquen que els mòduls inclosos
en la distribució de l’ERP no siguin suficients i, en conseqüència, la comunitat
d’OpenERP va produint mòduls que ens poden ser útils.
La pàgina web oficial de complements (add-ons) d’OpenERP (apps.openerp.com)

és el lloc on hem d’anar, inicialment, a cercar els mòduls. Si no el trobem o estem
cercant una versió beta, podem anar a la plataforma de programari col·laboratiu
La comunitat de que utilitzen els desenvolupadors de la comunitat OpenERP.
desenvolupadors
d’OpenERP acostuma a
tenir diversos projectes Els primers mòduls no oficials que ens poden interessar d’instal·lar en un Ope-
oberts a la plataforma de
programari col·laboratiu nERP que s’utilitzi a l’Estat espanyol, són aquells que ens facilitin una millor gestió
launchpad
(launchpad.net), des d’on diària de l’ERP i que generin la documentació necessària segons la normativa
també podem
descarregar-nos mòduls vigent. Segons això, ens interessaria disposar de:
amb l’eina Bazaar.
• Mòdul que introduís les províncies de l’Estat espanyol i alguna funcionalitat

a nivell de codis postals i municipis.
• Mòdul(s) que permetessin generar les diverses declaracions per a l’Agència

Tributària.
La implantació d’OpenERP a l’Estat espanyol és important i això ha provocat que

moltes de les empreses implantadores hagin desenvolupat mòduls de localització
que donen solució a les necessitats presentades. Com a exemple podem instal·lar
un mòdul que introdueixi les províncies de l’Estat espanyol juntament amb els
municipis i els codis postals (l10n_es_toponyms) desenvolupat per Zikzakmedia,
S.L.
Localitzem el mòdul l10n_es_toponyms a la pàgina web oficial de components

Als annexos del web d’OpenERP i ens descarreguem la versió corresponent a la versió 6.1 d’OpenERP.
que inclou una versió del Per incorporar un mòdul de nom xxx a un servidor OpenERP i instal·lar-lo, cal
fitxer
l10n_es_toponyms.zip seguir el següent procés:
corresponent al mòdul
Topònims de l’Estat
Espanyol que volem
actualitzar. 1. Afegir la carpeta xxx contenidora del nou mòdul, en el directori camíOnRe-
sideixOpenERP/Server/server/openerp/addons. S’hi pot deixar l’arxiu .zip
descarregat, però mai poden coexistir un arxiu .zip i una carpeta d’igual
nom.
2. Des de qualsevol client, connectat com a usuari admin, executar l’opció

Configuració | Mòduls | Actualitza la llista de mòduls, amb el qual aconse-
guim incorporar el nou mòdul a la llista de mòduls instal·lables del servidor
OpenERP.
3. Executar el procés d’instal·lació com qualsevol dels mòduls que incorpora

OpenERP.
Procedim, seguint aquests passos, a la instal·lació del mòdul Topònims de l’Estat

espanyol. Fixem-nos en la informació que acompanya el mòdul:
• Tradueix el nom de país Spain per España.
• Afegeix les 52 províncies actuals de l’Estat espanyol amb possibilitat

d’escollir la versió oficial dels noms, la castellana o ambdues (Lleida,
Girona, etc).
• Proporciona un assistent (cal executar-lo manualment després de la ins-

tal·lació) per donar d’alta els municipis i províncies per defecte associats
als 15.839 codis postals de l’estat espanyol.
Permet emplenar automàticament els camps ciutat i província dels contactes
en el formulari de socis de negocis a partir del codi postal.
• Les dades han estat obtingudes de les dades públiques de l’Institut Nacional
d’Estadística (INE).
En finalitzar la instal·lació, seguint la informació del mòdul, cal un procés de

configuració que no s’executa automàticament. Per això anirem a Configuració |
Configuració | Assistents de configuració | Assistents de configuració i escollirem
Configuració dels topònims de l’estat espanyol. L’executem amb les opcions per
defecte que ens proposa.
El procés de configuració dels topònims de l’estat espanyol és un procés que

s’executa en segon pla i que, com bé avisa, pot trigar força estona. Com que és
en segon pla, la manera de saber que ha finalitzat és quan a la llista dels assistents
de configuració hi apareix amb l’estat de realitzat. Mentre s’està executant,
l’OpenERP es pot utilitzar, però no apreciarem l’existència de les províncies ni
de l’emplenat automàtic dels camps ciutat i província en els formularis indicats
fins que l’assistent hagi finalitzat.
Una vegada finalitzat, podem comprovar-ne la utilitat:
• En configurar les dades de la nostra empresa (IOC) no havíem assignat la

província perquè no les teníem introduïdes. Ara ja podrem assignar-la.
• Quan s’introdueix el codi postal en el formulari de socis de negocis, es faci-

lita automàticament el municipi i la província (que es poden modificar). Cal
anar alerta amb possibles errors en municipis molt petits que comparteixen
un mateix codi postal.
2.7.5 Gestió de la seguretat en una empresa: usuaris i grups de

privilegis
El procés de creació d’una empresa d’OpenERP genera un usuari administrador,

de nom admin, amb una contrasenya obligatòria en el moment de creació de
l’empresa. L’administrador té tots els privilegis sobre l’empresa i pot crear usuaris,
grups de privilegis sobre els objectes de l’empresa (tercers, productes, comandes,
albarans, factures...) i assignar usuaris als diversos grups de privilegis.
Si l’empresa incorpora dades de demostració, es genera també l’usuari de nom

demo i contrasenya demo i, en aquest cas, la instal·lació del mòdul Recursos
Humans (hr) incorpora un seguit d’empleats que, a la vegada, són usuaris de
l’empresa d’OpenERP (poden obrir una connexió).
Fig u ra 2 . 3 7 . Formulari per gestionar un usuari d’OpenERP
Obriu sessió en una empresa amb dades de demostració i amb el mòdul Recursos
Humans (hr) instal·lat. Aneu a Configuració|Usuaris|Usuaris. Observeu que a
més de l’usuari Administrador i l’usuari Demo User, hi ha una sèrie d’usuaris.
Consulteu-ne qualsevol d’ells. Veureu que la seva fitxa conté una capçalera amb
el seu nom real, el nom d’usuari per establir connexió i un espai per assignar-li
una nova contrasenya i tres pestanyes (Usuari, Permisos d’accés i Companyies
permeses) com mostra la figura 2.37.
La pestanya Usuaris conté camps per introduir informació diversa, com l’idioma,
la zona horària, la companyia de treball per defecte, el departament, l’acció inicial
que s’ha d’executar quan l’usuari obre sessió en OpenERP i el correu electrònic.
La pestanya Companyies permeses per on es pot assignar, en una instal·lació

multicompanyia, les companyies que l’usuari pot gestionar.
La pestanya Permisos d’accés, visible a la figura 2.37, conté tres apartats: Ap-
plication, Usability i Altre. L’apartat Usability conté un conjunt de caselles de
verificació per facilitar a l’usuari diverses funcionalitats. L’apartat Application
mostra, per cadascun dels mòduls app d’OpenERP instal·lats a l’empresa, un
apartat amb una llista desplegable amb diverses possibilitats, específiques de cada
app. Així, la figura 2.37 mostra les aplicacions Sales Management, Project Mana-
gement, Warehouse Management, Accounting & Finance, Purchase Management,
Human Resources i Administració, que corresponen a sis mòduls app instal·lats
més l’apartat Administració (Configuració) per administrar l’OpenERP. Cadascun
d’aquests apartats conté uns determinats conjunts de permisos, anomenats grups
de privilegis, dels quals n’haurem d’assignar algun a l’usuari que hagi de poder
utilitzar el mòdul.
Normalment, cada mòdul d’OpenERP incorpora la definició d’un entorn de

seguretat bàsic que inclou la definició de l’aplicació i els seus grups de privilegis
(un com a mínim). Quan s’instal·la el mòdul, el seu entorn de seguretat queda
instal·lat a l’empresa i es visualitza a l’apartat Application de la pestanya Permisos
d’accés.
Fi gura 2 .38 . Llista de grups de privilegis d’una empresa d’OpenERP
L’apartat Altre de la pestanya Permisos d’accés, engloba grups de privilegis que

es poden definir sense assignar-los a una aplicació en concret.
La definició de l’entorn de seguretat es pot consultar i/o modificar i/o ampliar per
l’opció Configuració|Usuaris|Grups, que facilita la llista de totes les aplicacions
amb els seus grups de privilegis, com mostra la figura 2.38. La nomenclatura
utilitzada (Applicació|Grup de privilegis) permet distingir, amb rapidesa, els
diversos grups de privilegis de cada aplicació.
Si seleccioneu qualsevol dels grups de privilegis definits s’obrirà un formulari com

el de la figura 2.39 que conté diverses pestanyes, per les quals podem consultar i/o
gestionar, entre d’altres:
• Els usuaris que tenen concedit el grup de privilegis.
• Els grups de privilegis que s’hereten en cas de tenir assignat el grup actual.
• Menús als quals dóna accés el fet de tenir assignat el grup actual.
• Conjunt de permisos d’accés (lectura, escriptura, creació i eliminació) sobre

cadascun dels objectes definits en el mòdul.
F igu r a 2. 3 9 . Formulari de consulta/gestió de grups de privilegis d’OpenERP
La modificació dels grups de privilegis existents i la creació de nous grups de

privilegis és tasca destinada a experimentats administradors d’OpenERP.
2.8 Instal·lació d’OpenERP a Linux
La instal·lació d’OpenERP en el sistema operatiu Linux no és difícil, una vegada

coneixem el procés d’instal·lació i configuració d’un servidor OpenERP en el
sistema operatiu Windows i sabem moure’ns en un SGBD PostgreSQL, tot i que
té els seus punts delicats. Cal tenir unes bones nocions del sistema operatiu Linux.
Podem encarar la instal·lació d’un servidor OpenERP en un sistema Linux de

diverses maneres:
1. Instal·lant el(s) paquet(s) corresponents al servidor OpenERP que subminis-

tra, si és el cas, la distribució de Linux que tinguem instal·lada.
2. Instal·lant el(s) paquet(s) específics subministrats per OpenERP al seu web

de descàrregues, en cas que corresponguin a la distribució de Linux que
tinguem instal·lada.
3. Instal·lant els codis font subministrats per OpenERP.
Portarem a la pràctica les diverses instal·lacions en el sistema operatiu Linux

Ubuntu 12.04 LTS (Long Term Suport) tot i que la instal·lació dels paquets
subministrats per la distribució de Linux Ubuntu 12.04 LTS pot ser lleugerament
diferent a la que efectuarem aquí, basada en el paquet per a Ubuntu subministrat
per OpenERP (versió 6.1-YYYYMMDD).
2.8.1 Instal·lació a Ubuntu a través de paquets
El sistema operatiu Linux Ubuntu incorpora, des de la versió 9.04, la instal·lació

optativa d’un servidor OpenERP. La taula 2.4 mostra, per les diverses versions
d’Ubuntu, la versió de servidor d’OpenERP incorporada.
Taul a 2. 4. Versions de servidor OpenERP incorporat en les distribucions d’Ubuntu
Versió Ubuntu Versió OpenERP
9.04 Jaunty Jakalope 5.0.0
9.10 Karmic Koala 5.0.5
10.04 LTS Lucid Lynx 5.0.6
10.10 Maverick Meerkat 5.0.14
11.10 Oneiric Ocelot 5.0.15
12.04 LTS Precise Pangolin 6.1.1 (Octubre del 2012)
El procés d’instal·lació d’un servidor OpenERP a partir dels paquets subministrats

per la distribució d’Ubuntu pot diferir segons la versió. Així, per exemple, el
centre de programari de la versió 12.04 d’Ubuntu, en el mes d’octubre del 2012,
facilita dues versions d’OpenERP, com mostra la figura 2.40.
La instal·lació de la versió openerp6.1-core està pensada per una instal·lació del

servidor OpenERP que no incorpori la instal·lació d’un servidor PostgreSQL. En
canvi, la versió openerp6.1-full correspon a la instal·lació conjunta d’un servidor
OpenERP i un servidor PostgreSQL.
F igur a 2 . 4 0. Versions de servidor d’OpenERP subministrades per

Ubuntu 12.04 LTS
OpenERP, a la seva pàgina de descàrregues, facilita el paquet d’instal·lació

per a Debian/Ubuntu, sota el nom openerp_6.1-latest-1_all.deb. Instal·lem una
versió concreta per a Debian (versió 6.1-YYYYMMDD-RELEASE). Si procediu Als annexos del web
a descarregar-vos la darrera versió d’ambdós productes i inicieu la instal·lació, “Recursos de programari”
que inclou una versió
veureu que disposeu d’una versió més nova. concreta per a
Debian/Ubuntu.
El paquet subministrat per OpenERP, tot i portar el sufix _all, conté únicament
el servidor OpenERP i l’haurem de configurar per treballar amb un servidor

PostgreSQL existent (podeu instal·lar un servidor PostgreSQL a la màquina
Ubuntu o connectar amb un servidor PostgreSQL instal·lat en una altra màquina).
Una vegada instal·lat el servidor OpenERP, comprovem:
• A la carpeta /etc/init.d on resideixen els guions per gestionar els serveis, hi

ha aparegut el guió openerp. Si l’executem sense indicar cap opció, ens
informa de les possibles opcions de gestió:
1 root@Ubuntu:/etc/init.d# ./openerp
2 Usage: openerp−server {start|stop|restart|force−reload}
• Observem si hi ha algun procés amb nom openerp en marxa, cosa que

podem aconseguir amb la instrucció:
1 root@Ubuntu:/etc/init.d# ps aux | grep openerp
Fixem-nos que apareix una línia amb un contingut similar a:
1 /usr/bin/python /usr/bin/openerp−server
2 −−config=/etc/openerp/openerp−server.conf
3 −−logfile=/var/log/openerp−server.log
La línia anterior ens diu que hi ha un programa Python en execució. Concretament:
• Execució del programa /usr/bin/openerp-server
• Utilitza la configuració del fitxer /etc/openerp/openerp-server.conf
• Enregistra les incidències en el fitxer /var/log/openerp-server.log
• Observem que tenim el servidor Ubuntu escoltant pels ports habituals

d’OpenERP (8069 pel protocol XML-RPC i 8070 pel protocol NET-RPC):
1 root@Ubuntu:/home/alumne# netstat −ano|more

2 Active Internet connections (servers and established)
3 Proto Recv−Q Send−Q Local Address Foreign Address State Timer
4 ...
5 tcp 0 0 0.0.0.0:8069 0.0.0.0:* LISTEN off (0.00/0/0)
6 tcp 0 0 0.0.0.0:8070 0.0.0.0:* LISTEN off (0.00/0/0)
7 ...
• Si intentem la connexió des d’un client web o GTK, observarem que

apareixen missatges d’errors evidents ja que no tenim el servidor OpenERP
connectat amb un servidor PostgreSQL. El servidor OpenERP que hem
instal·lat intenta connectar amb un servidor PostgreSQL a la mateixa
màquina.
Ens cal configurar adequadament el servidor OpenERP instal·lat, indicant-li

el servidor PostgreSQL amb el qual s’ha de connectar i l’usuari-contrasenya
corresponents. Per aconseguir-ho, seguirem les següents passes:
1. Aturem el servidor OpenERP engegat i que volem reconfigurar:

1 root@Ubuntu:/etc/init.d# ./openerp stop
2 Stopping openerp−server: openerp−server.
Podem assegurar-nos que s’ha aturat comprovant que ja no hi ha cap procés que
contingui el nom openerp engegat.
2. Editem el fitxer de configuració /etc/openerp/openerp-server.conf. El seu

contingut és similar al de la versió per al SO Windows:
1 [options]
2 ; This is the password that allows database operations:
3 ; admin_passwd = admin
4 db_host = False
5 db_port = False
6 db_user = openerp
7 db_password = False
El nostre coneixement del servidor OpenERP en SO Windows ens porta a intuir

que hem de modificar el contingut amb:
1 [options]
3 admin_passwd = ContrasenyaPerUsuariAdminDeOpenERP
4 db_host = MaquinaOnResideixServidorPostgreSQL
5 db_port = PortPerOnEscoltaServidorPosrgreSQL
6 db_user = UsuariDePostgreSQL
7 db_password = ContrasenyaDelUsuariDePostgreSQL
Modifiqueu els paràmetres per connectar amb qualsevol dels servidors Post-
greSQL que tingueu instal·lats (siguin en sistema Linux o en sistema Windows).
Recordeu que l’usuari que utilitza OpenERP per connectar amb PostgreSQL ha
de tenir el rol Pot crear bases de dades.
3. Engeguem de nou el servidor OpenERP:

1 root@Ubuntu:/etc/init.d# ./openerp−server start
2 Starting openerp−server: openerp−server.
Recordem que l’ordre ps aux | grep openerp ens permet veure si tenim algun
procés engegat que contingui el nom openerp. És recomanable també fer una
ullada al fitxer log on queda constància de si l’engegada és correcta o detecta algun
problema. Cal tenir present que el servei pot quedar engegat però amb errors que
no permetin la utilització d’OpenERP.
4. Comprovem la connexió amb els clients web i GTK (des de SO Windows).
Pel que fa al client GTK per a Linux cal tenir en compte que:
• La distribució 12.04 LTS d’Ubuntu no facilita cap paquet d’instal·lació per

al client GTK.
• La web de descàrrega d’OpenERP no facilita cap paquet d’instal·lació del

client GTK per a la versió 6.1 (mentre que sí que existeix per a OpenERP
6.0), però sí que facilita els codis font del client GTK.
En conseqüència, l’única manera de tenir un client GTK a Linux per OpenERP

6.1 és instal·lant-lo a partir dels codis font.
2.8.2 Instal·lació a Ubuntu a través de codis font
OpenERP facilita al web de descàrrega el codi font per al servidor OpenERP i per
al client GTK. Veurem, a continuació, com procedir per aconseguir la instal·lació,
a Ubuntu 12.04 LTS, d’un servidor OpenERP 6.1 i d’un client GTK.
Als annexos del web
que inclou una versió dels
codis font del servidor Instal·lació del servidor OpenERP
OpenERP 6.1 i del client
GTK, per ser instal·lats en
qualsevol sistema
operatiu. Per instal·lar un servidor OpenERP a partir dels codis font descarregats del web
de descàrrega d’OpenERP (fitxer de nom similar a openerp-6.1-YYYYMMDD-
RELEASE.tar.gz) seguim el següent procés:
1. Descomprimim el contingut del fitxer, normalment en la carpeta opt del servidor

Linux:
1 root:/opt# tar −xzf openerp−6.1−YYYYMMDD−RELEASE.tar.gz
2 root:/opt# ls
3 openerp−6.1−YYYYMMDD−RELEASE
4 root:/opt#
2. En el directori /opt/openerp-6.1-YYYYMMDD-RELEASE/install hi trobem el

fitxer openerp-server.conf que haurem de retocar convenientment. A la versió
6.1.1 d’OpenERP el contingut és similar al de la versió per al SO Windows:
1 [options]
3 ; admin_passwd = admin
4 db_host = False
5 db_port = False
6 db_user = openerp
7 db_password = False
El nostre coneixement del servidor OpenERP en SO Windows ens porta a intuir

que hem de modificar el contingut amb:
1 [options]
3 admin_passwd = ContrasenyaPerUsuariAdminDeOpenERP
4 db_host = MaquinaOnResideixServidorPostgreSQL
5 db_port = PortPerOnEscoltaServidorPosrgreSQL
6 db_user = UsuariDePostgreSQL
7 db_password = ContrasenyaDelUsuariDePostgreSQL
Modifiqueu els paràmetres per connectar amb qualsevol dels servidors Post-
greSQL que tingueu instal·lats (siguin en sistema Linux o en sistema Windows).
Recordeu que l’usuari que utilitza OpenERP per a connectar amb PostgreSQL ha
de tenir el rol Pot crear bases de dades.
3. En el directori /opt/openerp-6.1-YYYYMMDD-RELEASE hi trobem el fitxer

README que conté diverses instruccions. En particular, ens interessa la part
final, referent als requeriments de sistema, que detalla els paquets que necessitem
tenir instal·lats en el servidor Linux per al correcte funcionament del servidor
OpenERP. Ens cal, doncs, efectuar la instal·lació de tots els paquets:
1 apt−get install paquet1 paquet2 paquet3 ...
4. En el directori /opt/openerp-6.1-YYYYMMDD-RELEASE hi trobem l’executa-

ble openerp-server que és el programa per posar en marxa el servidor. L’execució
d’aquest programa, acompanyat de l’opció –help, ens informa de les diverses
possibilitats que facilita. Ens interessa conèixer l’opció -c per indicar el nom
de fitxer de configuració que inclou les dades de connectivitat amb el servidor
PostgreSQL i la contrasenya de l’usuari administrador del servidor OpenERP.
Així, per posar el servidor en marxa, podem executar (com a usuari administrador
diferent de l’usuari root) i des de la carpeta arrel on hem instal·lat el programari:
1 ./openerp−server −c ./install/openerp−server.conf
El servidor mostra unes línies similars a:
1 INFO ? openerp: OpenERP version 6.1−YYYYMMDD−RELEASE

2 INFO ? openerp: addons paths: /opt/openerp−6.1−YYYYMMDD−RELEASE/openerp/addons
3 INFO ? openerp: database hostname: 10.200.190.207
4 INFO ? openerp: database port: 5432
5 INFO ? openerp: database user: pepito
6 INFO ? openerp.service.netrpc_server: starting NET−RPC service on 0.0.0.0:8070
7 INFO ? openerp.netsvc: Starting 1 services
8 INFO ? openerp.addons.web: embedded mode
9 INFO ? openerp.wsgi.core: HTTP service (werkzeug) running on 0.0.0.0:8069
10 INFO ? openerp: OpenERP server is running, waiting for connections...
Fixem-nos en la darrera línia que informa que el servidor OpenERP està en

execució i està esperant connexions. Per aturar l’execució del procés podem
executar la combinació de tecles CTRL+C. La terminal on hem posat en marxa el
servidor queda ocupada fins la finalització.
Si es vol posar en marxa el servidor OpenERP en segon pla, escriurem:
1 ./openerp−server −c ./install/openerp−server.conf &
En aquest cas apareixen les mateixes línies informatives i sembla que el procés
quedi esperant, però prement return apareix pareix el prompt del sistema.
5. Comprovem la connexió amb els clients web i GTK (des del SO Windows).
Edició de guions
Per entorns de producció és aconsellable disposar d’un guió que permeti engegar, L’edició de guions per gestionar
aturar i reiniciar el servidor OpenERP amb comoditat, guió que ha de residir dins els serveis i la instal·lació
d’aquests guions de manera que
/etc/init.d. l’engegada i aturada dels serveis
sigui automàtica és tasca dels
administradors del sistema
operatiu.
Instal·lació del client GTK
Per instal·lar un client GTK a partir dels codis font descarregats del web de des-
càrrega d’OpenERP (fitxer de nom similar a openerp-client-6.1-YYYYMMDD-
RELEASE.tar.gz), seguim el següent procés:
1. Descomprimim el contingut del fitxer, normalment en la carpeta opt del servidor

Linux:
1 root:/opt# tar −xzf openerp−client−6.1−YYYYMMDD−RELEASE.tar.gz

2 root:/opt# ls
3 openerp−6.1−YYYYMMDD−RELEASE
4 openerp−client−6.1−YYYYMMDD−RELEASE
2. En el directori /opt/openerp-client-6.1-YYYYMMDD-RELEASE/bin hi trobem

el programa Python openerp-client.py que és el programa a executar per posar en
marxa el client GTK. El paquet de fonts del client GTK no facilita informació sobre
els requeriments de paquets a tenir instal·lats en el servidor Linux. La instal·lació
dels paquets indicats en la instal·lació del servidor OpenERP és suficient per a la
correcta execució del client GTK.
3. Comprovem que el client GTK funciona per connectar-se amb qualsevol

servidor OpenERP, ja sigui sobre un servidor de Windows com sobre un servidor
de Linux.
Sistemes ERP-CRM.
Explotació i adequació - I

Sistemes de gestió empresarial Sistemes ERP-CRM. Explotació i adequació - I
Índex
Introducció 5
1 Explotació i adequació. OpenERP: el model 9

1.1 Explotació i adequació . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 La BD d’OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 Com identificar les taules que contenen determinada informació? . . . . . . . . . . . 13
1.2.2 Com facilitar l’accés de només lectura a la base de dades? . . . . . . . . . . . . . . . 15
1.2.3 Com accedir a PostgreSQL des d’aplicacions clients? . . . . . . . . . . . . . . . . . . 21
1.3 Desenvolupament de mòduls en OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.1 Disseny de mòduls amb Dia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.2 Disseny del model amb Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2 OpenERP: la vista i el controlador 55

2.1 Menús . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2 Vistes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.2.1 Accions window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.2.2 Vistes form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.2.3 Vistes tree (arbre/llista) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.2.4 Vistes calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.2.5 Vistes graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.2.6 Vistes search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.3 Mètodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.3.1 Mètodes ORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.3.2 Mètodes on_change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Sistemes de gestió empresarial 5 Sistemes ERP-CRM. Explotació i adequació - I
Introducció
Una vegada efectuada la implantació tècnica d’un ERP, el programari ja hauria

d’estar en condicions de ser utilitzat per l’organització per donar-ne sortida a les
necessitats. Però això no acostuma a passar, ja que les organitzacions, tot i que en
moltes ocasions s’adapten al màxim a l’ERP, tenen necessitats no suportades per
l’ERP.
Per aquest motiu, per a tots els ERP es necessiten professionals programadors que
siguin capaços d’adequar-los a les necessitats de l’organització. Com que hi ha
un gran ventall d’ERP-CRM i és impossible abastar les tecnologies que cadascun
d’ells utilitza, hem hagut de decidir-nos per un, per dur a la pràctica allò que cal fer
en qualsevol posada en explotació d’un ERP-CRM. El producte escollit ha estat
l’ERP-CRM de codi obert OpenERP, en la seva versió 6.1.
Aquesta unitat està destinada a introduir-nos en l’arquitectura MVC (patró model-

vista-controlador) facilitada pel framework OpenObject en el qual es basa Ope-
nERP i s’ha estructurat en dos apartats.
L’apartat “Explotació i adequació. OpenERP: el model” té un doble objectiu. El

primer, de curta durada, introduir els conceptes bàsics que cal tenir en compte en
un procés d’explotació i adequació. El segon, de llarga durada, introduir-nos en
el disseny del model de dades en OpenObject i la seva implementació en la base
de dades PostgreSQL. Com a preàmbul del segon objectiu, es presenta com és la
base de dades PostgreSQL corresponent a una empresa gestionada per OpenERP
i se’n faciliten diversos mètodes d’accés. Una vegada es conegui la base de dades,
cal endinsar-se en el disseny del model i és adequat iniciar-se amb una eina de
diagramació UML, capaç de generar el codi Python per OpenObject, per passar
posteriorment a descriure directament el model amb el llenguatge Python.
L’altre apartat, “OpenERP: la vista i el controlador”, ens endinsa en el disseny,

via XML, de les diverses vistes que proporciona OpenERP (formularis, llistes,
calendaris, gràfics, menús...) i en el disseny del controlador (mètodes que
implementen la lògica de negoci) a través del llenguatge Python.
Amb tot això no es pot dir que ja s’és expert en OpenERP, ni molt menys. S’està
en disposició de dissenyar mòduls adaptables a un OpenERP estàndard, però
manquen altres funcionalitats facilitades per OpenObject: herència —utilitzada
per a l’adaptació de mòduls existents—, seguretat, càrrega massiva de dades,
desenvolupament d’assistents, generació de traduccions idiomàtiques, disseny
d’informes, disseny de quadres de comandament i altres.
El seguiment d’aquesta unitat pressuposa que l’alumne és coneixedor de:
• La implantació tècnica d’OpenERP. El seu coneixement s’adquireix a la

unitat “Sistemes ERP-CRM. Implantació” del mòdul professional Sistemes
de gestió empresarial.
• El llenguatge XML. El seu coneixement s’adquireix en el mòdul professio-

nal Llenguatges de marques i sistemes de gestió de la informació.
• La programació orientada a objectes. El seu coneixement s’adquireix en les

unitats formatives relatives a programació orientada a objectes del mòdul
professional Programació.
• El llenguatge Python.
Als apartats “Bibliografia” i “Adreces d’interès” del web hi trobareu referències a

materials relacionats amb el llenguatge Python, que us ajudaran a introduir-vos-hi
de manera ràpida si sou coneixedors de la programació orientada a objectes.
Per tal d’assolir un bon aprenentatge cal estudiar els continguts en l’ordre indicat,
sense saltar-se cap apartat. Quan es fa referència a algun annex del web, cal
adreçar-s’hi i estudiar-lo. Una vegada estudiats els continguts del material paper i
del material web, s’han de desenvolupar les activitats web.

• Utilitza eines i llenguatges de consulta i manipulació de dades propor-

cionades pels sistemes ERP-CRM.
• Genera formularis.
• Exporta dades.
• Automatitza les extraccions de dades mitjançant processos.
• Documenta les operacions realitzades i les incidències observades.
2. Desenvolupa components per a un sistema ERP-CRM analitzant i utilitzant

el llenguatge de programació incorporat.
• Reconeix les sentències del llenguatge propi del sistema ERP-CRM.

• Utilitza els elements de programació del llenguatge per crear compo-
nents de manipulació de dades.
• Modifica components programari per afegir noves funcionalitats al
sistema.
• Integra els nous components programari en el sistema ERP-CRM.
• Verifica el correcte funcionament dels components creats.
• Documenta tots els components creats o modificats.
1. Explotació i adequació. OpenERP: el model
L’explotació i adequació de l’ERP d’una organització és una tasca imprescindible,

ja que garanteix que el programari es mantingui en condicions de ser utilitzat per
l’organització per tal de donar sortida a les seves necessitats. Per poder-ho dur a
terme, per una banda cal identificar les necessitats (tasca pròpia de consultors) i,
per una altra, tenir un coneixement profund de l’ERP, tant en les funcionalitats
que facilita (tasca de consultors i implantadors) com en les qüestions tècniques
vinculades a l’ERP (tasca d’analistes i programadors).
La nostra tasca, com a programadors, consistirà en conèixer l’arquitectura de

l’ERP i les eines de desenvolupament que s’han d’utilitzar per poder fer el
vestit a mida que necessita l’organització. El gran ventall d’arquitectures i
d’eines vinculades als ERP fan impossible efectuar un aprenentatge estàndard
d’explotació i adequació d’ERP i, per tant, ens centrarem a clarificar els punts
claus a tenir en compte i els posarem en pràctica sobre la versió 6.1 d’OpenERP.
L’OpenERP és un programari de gestió empresarial desenvolupat sobre el fra-

mework OpenObject de tipus RAD (Rapid Application Development).
La facilitat dels entorns RAD rau en el fet que el desenvolupament d’aplicacions

és molt simple pel programador, de manera que amb poc esforç es pot obtenir
aplicacions d’altes prestacions.
L’OpenObject facilita diversos components que permeten construir l’aplicació:
• La capa ORM (Object Relational Mapping) entre els objectes Python i

la base de dades PostgreSQL. El dissenyador-programador no efectua el
disseny de la base de dades; únicament dissenya classes, per les quals la
capa ORM d’OpenObject n’efectuarà el mapat sobre el SGBD PostgreSQL.
• Una arquitectura MVC (model-vista-controlador) en la qual el model resi-

deix en les dades de les classes dissenyades amb Python, la vista resideix en
els formularis, llistes, calendaris, gràfics... definits en fitxers XML i el con-
trolador resideix en els mètodes, definits en les classes, que proporcionen la
lògica de negoci.
• Un sistema de fluxos de treball o workflows.
• Dissenyadors d’informes.
• Facilitats de traducció de l’aplicació a diversos idiomes.
Tal com es pot observar, són molts els components d’OpenObject a conèixer
per poder adequar l’OpenERP a les necessitats de l’organització, en cas que les
funcionalitats que aporta l’OpenERP, tot i ser moltes, no siguin suficients.
El nostre objectiu és conèixer com es dissenya i s’implementa el model de dades

en OpenObject. Abans, però, aprofundirem en el coneixement de la base de dades
d’una empresa d’OpenERP, amb dues finalitats:
• Conèixer la relació existent entre els seus elements (taules i columnes) i els
elements que observem en qualsevol dels formularis i informes d’OpenERP.
• Saber com accedir a les dades de l’empresa atacant directament la base de

dades.
Una vegada coneguda l’estructura d’una base de dades d’OpenERP, ens podem
endinsar en el disseny del model en OpenERP i ho fem en dues fases:
1. Utilitzem l’eina de diagramació Dia que possibilita la generació de mòduls

complets (model-vista-controlador) a partir d’un diagrama UML i a partir
d’ella ens iniciem en el disseny del model de dades d’OpenERP.
2. Ens endinsem en el disseny del model de dades d’OpenERP utilitzant el

llenguatge Python.
1.1 Explotació i adequació
La gran diversitat de funcionaments de les empreses fa que sigui altament

improbable que un ERP estigui ideat per donar sortida a totes les necessitats
empresarials. Quan es detecta una funcionalitat no coberta per l’ERP, hi ha tres
camins per trobar-hi una solució. Per una banda, es pot adequar l’ERP per donar
resposta a les funcionalitats requerides. Per l’altra, es pot adequar el funcionament
de l’empresa a les funcionalitats facilitades per l’ERP. O bé, un tercer camí basat
en la combinació dels dos camins anteriors.
La detecció de les funcionalitats de l’empresa no suportades per l’ERP que

es vol implantar és una de les tasques principals en el procés de consultoria.
El fet de que l’empresa canviï el seu funcionament per adaptar-se a l’ERP, tot
i semblar molt brusc, és una solució que s’adopta en moltes ocasions, sobretot
quan els consultors són capaços de demostrar als responsables de l’organització
que el nou funcionament té clars avantatges respecte als mètodes emprats en aquell
moment per l’empresa. Cal tenir en compte que, en ocasions, l’empresa pot haver
establert els seus funcionaments –en temps passats– coaccionada per les possi-
bilitats del sistema informàtic vigent en aquell moment, i aquests funcionaments
han esdevingut, amb el pas del temps, maneres de fer fonamentals i intocables en
l’organització. En aquestes ocasions, la mà esquerra dels consultors i implantadors
és fonamental per dur a terme la implantació de l’ERP amb èxit.
Tot i això, no sempre es pot adequar els mètodes de l’empresa a les funcionalitats
facilitades per l’ERP i, en conseqüència, cal adequar l’ERP, fet que pot comportar
la necessitat de desenvolupar mòduls específics que es puguin acoblar a l’ERP i/o

retocar mòduls (formularis i informes) de l’ERP.
En l’adequació d’ERP és fonamental garantir el correcte funcionament de

les adequacions en les futures actualitzacions de l’ERP.
L’adequació d’un ERP a través del desenvolupament de mòduls específics es pot

dur a terme, en principi, amb qualsevol llenguatge de programació i accedint di-
rectament a la base de dades de l’ERP. Fer-ho així, però, comporta inconvenients: Hi ha ERPs que prohibeixen
l’accés a la base de dades
en mode escriptura i
castiguen aquest fet amb la
• Accedir directament a la base de dades implica tenir un coneixement total pèrdua del servei de suport.
de la base de dades i de les relacions existents entre els seus components.

Aquestes relacions poden canviar en una actualització de l’ERP.
• Els mòduls desenvolupats amb un llenguatge de programació forà a l’ERP

impliquen tenir peces fora de l’ERP, a no ser que siguem capaços d’emular
la interfície de l’ERP i d’introduir les noves opcions a l’arbre de menús de
l’ERP.
El retoc de mòduls (formularis i informes) de l’ERP també té inconvenients:
• Només és possible si disposem del codi font de l’ERP (opció vàlida en

programaris de codi obert).
• Els retocs efectuats han de garantir-ne la continuïtat en properes actualitza-

cions de l’ERP sense necessitat de tornar-los a desenvolupar.
Els diversos inconvenients presentats ens porten a la necessitat de conèixer i

utilitzar els mètodes de desenvolupament i/o retoc de mòduls de l’ERP facilitats
pel fabricant. A més, cal efectuar els processos d’actualització de dades (altes,
baixes i modificacions) a través de les regles de negoci de l’ERP, que tenen en
compte totes les implicacions, i mai amb accessos directes a la base de dades.
Cal tenir en compte, també, que en ocasions pot ser convenient accedir a les
dades en mode consulta per a extreure’n informació. En aquests casos, tenint
coneixement de l’estructura de la base de dades, l’accés directe a la base de
dades pot ser adequat, amb la precaució que l’estructura pot canviar en futures
actualitzacions de l’ERP.
Quan l’organització necessita informes que l’ERP no facilita...
Si la necessitat dels informes és puntual, és perfectament lícit desenvolupar-los amb

qualsevol eina, tot accedint directament a la base de dades, i executar-los per aconseguir el
resultat esperat. No tenim cap necessitat d’incorporar-los com a opcions de menú de l’ERP
ni de guardar-los per posteriors execucions. En cas de guardar-los, som conscients que
després d’haver actualitzat l’ERP, pot ser necessari revisar el seu disseny davant possibles
canvis en la base de dades.
Si la necessitat dels informes és periòdica, és lògic desenvolupar-los amb les eines que
faciliti l’ERP, utilitzant les seves regles de negoci, i incorporant-los com a noves opcions de
menú dins l’ERP. En aquest cas, davant una actualització de l’ERP, és molt possible que
les regles de negoci evocades continuïn existint (malgrat que hagi canviat l’estructura de la
base de dades) i, en conseqüència, el nostre informe continuï funcionant.
A vegades, dins de les organitzacions existeixen persones que, possiblement per

mancances de bones solucions BI vinculades a l’ERP, necessiten accedir a la base
de dades per extreure’n informació (mode consulta) i, des de les eines ofimàtiques
que dominen (bases de dades ofimàtiques i fulls de càlcul), desenvolupar informes
i quadres de comandament (dashboards) adequats a les seves necessitats. En
aquest cas, l’accés directe (mode consulta) a la base de dades també és lògic, tot
i que l’usuari ha de ser conscient que els seus muntatges es poden veure afectats
davant d’una actualització de l’ERP.
Aquests raonaments ens porten a les conclusions següents:
• Cal conèixer l’estructura de la base de dades de l’ERP i possibilitar-

hi accessos en mode consulta, per extreure’n informació que pugui ser
gestionada des d’eines externes.
• Cal conèixer la gestió de regles de negoci de l’ERP.
• Cal conèixer les eines recomanades pel fabricant de l’ERP per al desenvo-
lupament i/o retoc de mòduls de l’ERP, fet que pot anar acompanyat del
coneixement de llenguatges de programació.
1.2 La BD d’OpenERP
La gestió d’una empresa pot fer necessari, en un determinat moment, l’accés a

la base de dades de l’ERP per tal d’obtenir informació en un format no facilitat
per l’ERP. Per això, és important conèixer el disseny de la BD (base de dades) de
l’ERP i, en el nostre cas, de l’OpenERP.
En l’OpenERP no hi ha un disseny explícit de la base de dades, sinó que la base de

dades d’una empresa d’OpenERP és el resultat del mapatge del disseny de classes
de l’ERP cap el SGBD PostgreSQL que és el que proporciona la persistència
necessària per als objectes.
En OpenERP el model de dades es descriu i es manipula a través de les

classes i els objectes definits amb el llenguatge Python.
Als annexos del web En conseqüència, l’OpenERP no facilita cap disseny entitat-relació sobre la base
trobareu l’apartat “Eines
per ajudar-nos a conèixer de dades d’una empresa ni tampoc cap diagrama del model relacional. No obstant
la BD d’OpenERP”. Amb
aquestes eines podreu això, si ens interessa disposar d’un model relacional, es troben moltes eines que
obtenir diagrames parcials
relacionals de la base de ens el poden construir a partir de la base de dades implementada en el SGBD
dades d’OpenERP.
PostgreSQL.
1.2.1 Com identificar les taules que contenen determinada

informació?
Si sorgeix la necessitat de detectar la taula o les taules on resideix determinada

informació, és perquè es coneix l’existència d’aquesta informació gestionada
des de l’ERP i, per tant, es coneix algun formulari de l’ERP a través del qual
s’introdueix la informació.
L’OpenERP possibilita, mitjançant els clients web i GTK, recuperar el nom de la

classe Python que defineix la informació que s’introdueix a través d’un formulari
i el nom de la dada membre de la classe corresponent a cada camp del formulari.
Aquesta informació permet arribar a la taula i columna afectades, tenint en compte
dues qüestions:
• El nom de les classes Python d’OpenERP sempre són en minúscula (s’utilit-

za el guió baix per fer llegible els mots compostos) i segueix la nomenclatura
nom_del_modul.nom1.nom2.nom3... en la qual s’utilitza el punt per
indicar un cert nivell de jerarquia. Cada classe Python d’OpenERP és
mapada en una taula de PostgreSQL amb moltes possibilitats que el seu
nom coincideixi amb el nom de la classe, tot substituint els punts per guions
baixos.
• Els noms dels atributs d’una classe Python sempre són en minúscula
(s’utilitza el guió baix per fer llegible els mots compostos). Cada dada
membre d’una classe Python d’OpenERP que sigui persistent (una classe
pot tenir dades membres calculades no persistents) és mapat com un atribut
en la corresponent taula de PostgreSQL amb el mateix nom.
Noms de classes OpenERP i corresponents taules PostgreSQL
La classe Python sale.order d’OpenERP està pensada per descriure la capçalera de les
comandes de venda i la corresponent taula a PostgreSQL és sale_order.
La classe Python sale.order.line d’OpenERP està pensada per descriure les línies de
les comandes de venda i la corresponent taula a PostgreSQL és sale_order_line.
La classe Python sale.order d’OpenERP té una dada membre anomenada data_order i,

en conseqüència, la taula sala_order de PostgreSQL conté l’atribut data_order.
D’aquesta manera, coneixent el nom de la classe i el nom de la dada membre, és

molt possible conèixer el nom de la taula i de la columna corresponents. Es pot
configurar els clients web i GTK per tal que informin del nom de la classe i de la
dada membre en situar el ratolí damunt les etiquetes dels camps dels formularis.
Aquesta opció es configura de la manera següent:
• En el client GTK cal activar l’opció Ajuda | Activa les ajudes del mode de
depuració.
• En el client web de la versió 6.0 no calia activar res i sempre que l’usuari
situava el punter del ratolí damunt les etiquetes del camp, apareixia la
informació d’ajuda, fet que era de gran ajuda per als desenvolupadors però
que confonia als usuaris finals. Per això, la versió 6.1 del client web és
similar al client GTK i cal activar la funcionalitat amb l’opció Activar mode
de desenvolupador de la pantalla de diàleg que apareix en prémer el botó
Quant a de la part superior dreta del client web.
La figura 1.1 mostra la informació que facilita el client GTK en posar el ratolí sobre
l’etiqueta de dos camps del formulari Comandes de Venda. Podem observar-hi
que:
• Per l’etiqueta Data obtenim que es tracta del camp data_order de l’objecte
sale.order i, per tant, si necessitem efectuar una consulta sobre la base de
dades accedint a la data de la comanda, sabem que haurem d’anar al camp
data_order de la taula sale_order de la base de dades de PostgreSQL.
• Per l’etiqueta Tenda tenim molta més informació ja que es tracta del camp
relacional shop_id de l’objecte sale.order que fa referència a la relació
sale.shop. Amb aquesta informació, si necessitem efectuar una consulta
a la base de dades per accedir a la descripció de la botiga corresponent
a la comanda sabem que haurem d’anar al camp shop_id de la taula
sale_order i a través d’aquest camp, establir un join amb la clau primària
de la taula sale_shop.
F igu r a 1 . 1 . Ajuda del mode de depuració que facilita el client GTK en situar el ratolí damunt les etiquetes
dels camps en un formulari
Un client web amb el mode desenvolupador activat no només facilita informació en

posar el ratolí sobre l’etiqueta dels camps del formulari, sinó que, a més, al costat
del títol de qualsevol formulari obert apareix un desplegable, tal com mostra la
figura 1.2, amb diverses opcions que poden ajudar-nos com a desenvolupadors de
mòduls d’OpenERP.
Figur a 1. 2. Ajudes en el client web amb el mode desenvolupador activat
La figura 1.2 mostra com, per defecte, l’opció del desplegable que apareix en tenir
el mode desenvolupador activat és Debug View #... amb un valor al costat del
símbol coixinet que correspon al número identificador de la vista activa. La resta
d’opcions són:
• View Fields que permet obtenir una llista dels camps de la vista actual, amb
els paràmetres corresponents.
• Fields View Get que mostra l’XML generat per la vista actual. Cal tenir en
compte que si la vista s’ha generat a partir de diverses vistes XML heretant
les unes de les altres, aquí se’n mostra el resultat final.
• Manage Views que mostra un llistat de les vistes relacionades amb la vista
actual. Des d’aquest punt es poden crear noves vistes, eliminar-les o editar-
les, encara que és recomanable utilitzar aquesta funcionalitat només per
consultar. Es recomana realitzar les modificacions creant nous mòduls, per
no perdre les modificacions davant actualitzacions de l’ERP.
• Edit TreeView, Edit SearchView, Edit Action i Edit Workflow que serveixen
per accedir a l’edició de les vistes relacionades amb la vista actual.
• Si estem editant un registre (mode formulari) o consultant-lo (mode pàgina),

apareix una nova opció View Log (perm_read) que mostra informació
relativa al registre actual.
1.2.2 Com facilitar l’accés de només lectura a la base de dades?
Les empreses acostumen a tenir, entre els seus responsables, usuaris finals que
poden efectuar consultes no previstes a la base de dades i que, per aconseguir-
ho, poden utilitzar eines gràfiques per elaborar consultes o, fins i tot, si són prou
espavilats, executar consultes SQL des d’una consola d’accés.
L’accés a la base de dades per part d’usuaris finals ha de ser de només lectura.
En aquesta situació, cal facilitar als usuaris que calgui, un usuari per accedir a
l’SGBD PostgreSQL amb els privilegis d’accés, en mode consulta, als objectes
de la base de dades que correspongui. S’aconsella seguir dos passos:
1. Crear els usuaris d’SGBD amb les contrasenyes que corresponguin.
2. Donar els privilegis d’accés adequats als usuaris que corresponguin.
Crear els usuaris d’SGBD amb les contrasenyes que corresponguin
Per tal de crear els usuaris d’SGBD utilitzem una eina d’administració de Post-
greSQL (pgAdmin o la pròpia consola textual psql si ens hi movem amb soltesa).
Hem de connectar-nos al SGBD PostgreSQL amb un usuari amb privilegi de
creació d’usuaris (rol CREATEROLE) de l’SGBD. Amb aquestes dues coses, podem
crear els usuaris d’SGBD amb les contrasenyes que corresponguin.
En una implantació d’OpenERP en la qual cada usuari de l’empresa té un inici

de sessió (login) específic, sembla adequat utilitzar el mateix nom d’usuari
de l’OpenERP per crear un usuari d’accés a l’SGBD. La contrasenya pot ser
inicialment la mateixa, tot i que l’usuari haurà de ser conscient que un canvi de
contrasenya en l’ERP no afectaria a la contrasenya de PostgreSQL ni viceversa.
F igu r a 1. 3 . Pantalla de pgAdmin per crear un nou usuari (Login Role)

La figura 1.3 mostra la pantalla que facilita pgAdmin per crear un nou usuari (botó
secundari del ratolí damunt del node Login Roles de l’Object Browser i seleccionar
l’opció New Login Role).
Distinció entre usuaris, grups d’usuaris i rols en PostgreSQL
L’eina pgAdmin no mostra, per enlloc, els conceptes usuari i grups d’usuaris i en canvi
mostra els termes Login Role i Group Role. Si fem una ullada a la documentació del
llenguatge SQL de PostgreSQL veiem l’existència de les instruccions create user (per a
la creació d’usuaris) i create group (per a la creació de grups d’usuaris).
PostgreSQL utilitzava els conceptes usuaris i grups d’usuaris en versions anteriors a la 8.1,
versió en la qual va substituir aquests conceptes pel concepte de rol amb dues variants (rol
que pot iniciar sessió, Login Role, i rol que no pot iniciar sessió Group Role) i va introduir la
nova instrucció SQL create role. Per mantenir la compatibilitat amb el joc d’instruccions
SQL de les versions anteriors a la 8.1 va mantenir l’existència de les instruccions create
user i create group, de manera que create user equival a la creació d’un Login Role i
create group equival a la creació d’un Group Role.
Donar els privilegis d’accés adequats als usuaris que correspongui
L’eina pgAdmin (la versió 1.8.4 de 8 de juny de 2008 instal·lada per OpenERP 6.1
i la versió 1.14.3 de 1 de juny del 2012) té certes limitacions a l’hora d’assignar
privilegis, ja que no permet l’assignació a Login Role i, en conseqüència, si
utilitzem aquesta versió ens veiem obligats a crear un Group Role al qual assignem
els Login Role i concedim privilegis als Group Role. Un altre funcionament
una mica defectuós en aquestes versions de pgAdmin es troba en el fet que una
vegada creat un Group Role cal situar-se damunt el node de definició del servidor
i refrescar les dades, per tal que els objectes de les diverses bases de dades del
servidor puguin concedir privilegis al nou Group Role.
L’assignació de privilegis s’efectua sobre cada objecte i, a través de pgAdmin,

per donar privilegis a un objecte determinat cal situar-se damunt del nom de
l’objecte, dins l’Object Browser, editar les seves propietats (amb el botó secundari
del ratolí) i anar a la pestanya Privileges. Els privilegis es poden concedir a nivell
de base de dades (per permetre o no l’accés), a nivell d’esquema (per utilitzar-lo i/o
crear-hi objectes), a nivell d’objectes de la base de dades (taules, vistes, funcions,
disparadors...) i fins i tot a nivell de columnes de les taules i vistes. Per donar
privilegis d’accés a columnes, cal situar-se damunt la columna i editar les seves
propietats.
PostgreSQL va incorporar la possibilitat d’assignar privilegis a nivell de columna,

en la versió 8.4. Cal tenir-ho present per si hem instal·lat el servidor PostgreSQL
que incorpora la distribució d’OpenERP, ja que es tracta d’una versió 8.3. La
versió 1.8.4 de l’eina pgAdmin no permet assignar privilegis a nivell de columna,
ja que és coetània de PostgreSQL 8.3. Les versions de pgAdmin coetànies
de servidors PostgreSQL 8.4 o posteriors mostren desactivades les opcions de
concessió de privilegis a nivell de columna si el servidor PostgreSQL no facilita
la funcionalitat. En cas d’haver de donar privilegis a nivell de columna en un
servidor que no facilita la funcionalitat, es pot crear una vista que accedeixi a les
columnes i donar privilegis d’accés a la vista definida.
La figura 1.4 mostra la limitació de pgAdmin per concedir privilegis als Login
Role. Podem observar-hi la concessió de privilegis a nivell de la base de dades
Empresa_IOC i veiem que hi ha dos Login Role creats (ioc i pgotera) i, en canvi,
en el desplegable Role de la pestanya Privileges de la base de dades Empresa_IOC
només apareix el rol public (que es refereix a tothom). Si tinguéssim Group Role
definits, aquests sí que hi apareixerien.
F igu r a 1. 4 . Pantalla de pgAdmin per concedir privilegis d’accés a un base de dades
Per tant, si volem assignar privilegis directament a un usuari (Login Role) haurem
És altament recomanable d’utilitzar la instrucció SQL grant des de la consola textual psql.
fer una ullada a la part de
la documentació de
PostgreSQL referent a Una manera ràpida de veure, des de pgAdmin, els privilegis concedits a un objecte,
l’assignació de privilegis.
La documentació de és situar-nos damunt de l’objecte i veure, a la part dreta de la pantalla, el contingut
PostgreSQL es troba a
www.postgresql.org/docs i
de la propietat ACL (Access Control List), tal com mostra la figura 1.5.
per nosaltres té interès fer
una ullada als capítols 20
(Database Roles) i 5.6 La figura 1.5 mostra el contingut de la llista ACL sobre la base de dades
(Privileges), així com a les
ordres SQL grant, revoke
Empresa_IOC. Podem situar-nos damunt de qualsevol objecte de la base de dades
i create role. (esquema, taula, vista, columna...) i tindrem accés a la llista ACL dels privilegis
concedits sobre aquell objecte.
En el cas de la figura 1.5 observem com la base de dades Empresa_IOC no té

definida la llista ACL i això és un problema, ja que en principi permet l’accés a
qualsevol usuari. Per tal que no hi hagi cap privilegi d’accés, la llista ACL hauria
de mostrar el valor {}. Podem aconseguir-ho si editem les propietats de la base de
dades, naveguem fins la pestanya Privileges i afegim el rol public sense arribar-li
a concedir cap privilegi, de manera que quan enregistrem el canvi, veurem que el
valor d’ACL és {}.
Figur a 1. 5. Propietat ACL sobre una base de dades de PostgreSQL
Un punt molt important a tenir en compte en la gestió de privilegis de PostgreSQL

és conèixer els privilegis existents, de forma automàtica, després de la creació
d’una base de dades. Cal saber que:
• La base de dades es crea amb ACL no definida, fet que permet que qualsevol
usuari del servidor PostgreSQL pugui obrir sessió en aquella base de dades.
• PostgreSQL facilita el rol public que engloba a tots els usuaris de forma
automàtica.
• PostgreSQL facilita, a totes les bases de dades, l’esquema public, propietat

de l’usuari que ha creat la base de dades, i amb privilegis d’ utilització
de l’esquema (usage) i creació d’objectes (create) al rol public (és a
dir, a qualsevol usuari). Així, si observem la propietat ACL de l’esquema
public d’una base de dades creada per l’usuari ioc, veiem el valor
{ioc=UC/ioc, =UC/ioc} que hem de llegir com: l’usuari ioc té privilegis
UC (usage+create) i el rol public (no apareix a l’esquerra del símbol =)
té privilegis UC (usage+create) i que en ambdós casos han estat concedits
per l’usuari ioc (valor que apareix després del símbol /).
Un usuari qualsevol, pel fet de pertànyer al rol public, té accés UC sobre l’esquema
public de qualsevol base de dades. Això implica que pot veure la relació (noms)
de tots els objectes existents a l’esquema (taules, vistes...), veure la descripció de
qualsevol objecte (taules, vistes...) i crear nous objectes dins l’esquema, però no
pot accedir als continguts de les taules ni vistes, a no ser que el propietari d’aquests
objectes li concedixi accés.
En cas que haguem de facilitar accés a la base de dades corresponent a una

empresa de PostgreSQL a nous usuaris i no ens interessi mantenir aquesta situació,
procedirem de la següent manera:
• Definirem el valor de la propietat ACL de la base de dades i indicarem els

usuaris als quals es facilita el privilegi de connexió.
• Modificarem el valor de la propietat ACL de l’esquema public, eliminarem

l’assignació de privilegis al rol public i assignarem la utilització (només
usage) de l’esquema public als usuaris o rols corresponents. Aquesta
acció executada mentre el servidor OpenERP està engegat pot provocar que
OpenERP no pugui connectar amb la base de dades fins que es reiniciï el
servidor OpenERP.
• Assignarem els privilegis (normalment de lectura) als usuaris o rols corres-

ponents sobre els objectes (taules, vistes, columnes...) que interessi.
Exemple d’assignació de privilegis a través d’ordres SQL des de consola psql
Suposem que tenim l’usuari pgotera acabat de crear; per tant, encara no se li ha concedit
cap privilegi. Suposem també que hem eliminat l’accés public a l’esquema public.
Mirem la seqüència d’instruccions SQL, des de la consola psql, per aconseguir que l’usuari
pgotera pugui veure, per les comandes de venda, el número, la data de la comanda i el
nom de la botiga que ha efectuat cada comanda. Suposem que es tracta d’un servidor
PostgreSQL 9.1 resident a la màquina d’IP 10.200.190.207, que ioc és un superusuari i
que la base de dades s’anomena Empresa_IOC.
1 C:\...>psql −Uioc −h10.200.190.207 −dEmpresa_IOC

2 Password for user ioc:
3 ...
Ja hem establert connexió amb l’usuari ioc. Per donar permís de connexió a l’usuari pgotera
cal fer:
1 =# grant connect on database "Empresa_IOC" to pgotera;

2 GRANT
Per donar permisos d’utilització de l’esquema public a l’usuari pgotera (això és necessari
ja que s’ha eliminat l’accés public a l’esquema public):
1 =# grant usage on schema public to pgotera;

2 GRANT
Per donar permís de lectura a la taula sale_shop (botigues) a l’usuari pgotera:
1 =# grant select on table sale_shop to pgotera;

2 GRANT
Per donar permís de lectura a les columnes id (número de comanda), date_order (data
de comanda) i shop_id (identificador de la botiga que ha efectuat la comanda), de la taula
sale_order (comandes), a l’usuari pgotera:
1 =# grant select (id, date_order, shop_id) on

2 −# sale_order to pgotera;
3 GRANT
S’ha decidit donar únicament accés a les tres columnes per fer notar que en ocasions pot
ser necessari donar permís a nivell de columnes perquè hi pot haver altres columnes amb
informació confidencial a les quals no ha de tenir accés l’usuari pgotera. Recordem que
això només és possible a partir de la versió 8.4 de PostgreSQL i, per tant, en versions
anteriors ens veuríem obligats a donar permís d’accés a tota la taula sale_order.
1 =# \q
2
3 C:\...>
Per comprovar que l’usuari pgotera pot obtenir la informació desitjada:
1 C:\...>psql −Upgotera −h10.200.190.207 −dEmpresa_IOC

2 Password for user pgotera:
3 ...
1 =# select so.id as "Comanda",

2 −# so.date_order as "Data",
3 −# ss.name "Botiga"
4 −# from sale_order so, sale_shop ss
5 −# where so.shop_id = ss.id;
L’exemple ens ha mostrat com donar privilegis a nivell de columnes. En un servidor

PostgreSQL anterior a la versió 8.4, en no ser possible l’assignació de privilegis a nivell de
columnes, podríem crear una vista i donar accés a la vista. Vegem com fer-ho. Connectats
com a superusuari per poder crear la vista i donar accés de consulta a l’usuari pgotera:
1 =# create view ioc_sale_order_pgotera as

2 −# select id as "comanda", date_order as "data",
3 −# shop_id as "botiga"
4 −# from sale_order;
5 CREATE VIEW
6 =# grant select on ioc_sale_order_pgotera to pgotera;
7 GRANT
Connectats com a usuari pgotera:
1 => select * from ioc_sale_order_pgotera;

2
3 => select comanda, data, name
4 −> from ioc_sale_order_pgotera, sale_shop
5 −> where botiga = id;
Cal anar amb compte amb la definició de vistes dins l’esquema public, ja que cohabitaran
amb vistes de mòduls de l’OpenERP. En cas de fer-ho és altament recomanable utilitzar
una nomenclatura que ens permeti identificar les vistes afegides que no formen part
de l’OpenERP; així, a l’exemple, fixem-nos que hem utilitzat el prefix ioc_ per a la
vista creada. També és possible crear esquemes diferenciats de l’esquema public que
utilitza PostgreSQL i crear-hi les vistes necessàries, però això ja són conceptes avançats
d’administració de PostgreSQL que no tractarem ara.
1.2.3 Com accedir a PostgreSQL des d’aplicacions clients?
En moltes ocasions serà precís configurar estacions de treball per tal que algunes
aplicacions instal·lades puguin connectar amb l’SGBD PostgreSQL per accedir Als annexos del web
trobareu l’apartat “Accés a
a les dades emmagatzemades. Aquest és el cas de les eines ofimàtiques actuals, SGBD corporatives des
d’eines ofimàtiques” en el
que acostumen a facilitar la connectivitat amb els SGBD a través de connectors qual es mostra com
ODBC o JDBC que cal tenir instal·lats a la màquina des d’on es vol utilitzar l’eina instal·lar i utilitzar
connectors ODBC i JDBC.
ofimàtica.
1.3 Desenvolupament de mòduls en OpenERP
El desenvolupament de mòduls en OpenERP és indispensable per poder adequar

l’OpenERP a les necessitats d’implantació en una organització. Per tal d’aprendre
com desenvolupar mòduls en OpenERP en primer lloc és convenient conèixer
l’eina de diagramació Dia que permet efectuar dissenys UML i per a la qual
existeix un connector (pluggin) que permet generar mòduls d’OpenERP a partir
dels dissenys efectuats amb Dia. Un cop fet això, s’ha d’aprofundir en el disseny
de mòduls, generant-los directament amb la utilització dels llenguatges Python i
Per dissenyar diagrames XML.
amb l’eina Dia, és
convenient tenir uns
coneixements bàsics del
llenguatge UML, de nivell
similar als adquirits en el
mòdul de Programació. Al
web podeu trobar molts
documents introductoris al 1.3.1 Disseny de mòduls amb Dia
llenguatge UML.
Per desenvolupar mòduls Dia és una aplicació gràfica de propòsit general per a la creació de diagrames,
d’OpenERP és necessari
el coneixement del desenvolupada com a part del projecte GNOME. Està construïda de forma
llenguatge Python. Als
annexos de la pàgina web modular, amb diferents paquets de formes per a diferents necessitats.
“Llenguatge Python” amb
recomanacions per a A nosaltres ens interessa aquesta eina per dissenyar els diagrames UML dels
l’aprenentatge.
mòduls OpenERP que volem desenvolupar i generar-ne, posteriorment, el mòdul
per a OpenERP. Per fer això, haurem d’instal·lar Dia amb Python amb l’opció de
Als annexos del web generació de mòduls OpenERP.
“Instal·lació de Dia amb
Phyton (PyDia) a El procés d’instal·lació de Dia amb Python amb l’opció de generació de mòduls
Windows per
desenvolupar mòduls OpenERP incorpora un exemple de diagrama UML desenvolupat amb Dia (arxiu
OpenERP”.
uml_test.dia facilitat per OpenERP) que correspon a un senzill mòdul de gestió
escolar per a OpenERP. Utilitzarem aquest diagrama per iniciar-nos en el disseny
Trobareu el fitxer de mòduls OpenERP mitjançant l’eina de diagramació Dia.
uml_test.dia dins l’apartat
“Diagrames Dia” dels
annexos del web.
Disseny de classes amb Dia
Posem en marxa l’eina Dia i obrim el fitxer uml_test.dia. La figura 1.6 correspon
al disseny UML del diagrama de classes emmagatzemat.
F igu r a 1. 6 . Diagrama UML confeccionat amb l’eina DIA

L’eina Dia permet desenvolupar diversos tipus de diagrama i, com que ens
interessen els diagrames UML, caldrà tenir seleccionada l’opció UML a la caixa
d’eines de la part esquerra de la pantalla de Dia.
L’exemple de la figura 1.6 correspon a un model per gestionar, en una escola que
facilita cursos (en diverses edicions) i disposa de professors, els estudiants dels
diversos cursos. El disseny d’aquest model, tal com veurem, pot no semblar molt
“lògic” i l’hem de considerar com un exemple que ens permet introduir diversos
conceptes bàsics per la generació de mòduls OpenERP amb Dia.
En una situació com la presentada, a l’hora de desenvolupar un diagrama UML, és

molt lògic pensar en un disseny que contingui classes per modelar els conceptes
curs, professor, edicions dels cursos i estudiants... de forma similar al diagrama
uml_test, que contempla:
• Classe school.course, per modelar els cursos que facilita l’escola.
• Classe school.event, per modelar les edicions dels cursos.
• Classe abstracta school.professor, per modelar els professors.
• Plantilla de classe school.student, per modelar els estudiants.
Una primera ullada al diagrama permet introduir els següents conceptes per
mòduls OpenERP:
• Tots els elements d’un diagrama cal escriure’ls en anglès (fins i tot les
etiquetes i els textos informatius). Si ens interessa tenir-lo en català
o castellà, utilitzarem posteriorment les eines de traducció que facilita
OpenERP.
• Totes les classes s’anomenen en minúscules i es recomana incorporar, com

a prefix, el nom del mòdul al qual pertanyen.
• Els noms de mòduls, classes i membres de les classes han de ser escrits en
minúscula amb guions baixos per fer llegibles els noms compostos.
La nomenclatura indicada
Com que els noms de les classes de la figura 1.6 tenen el prefix school, deduïm és la que marca OpenERP i,
com possiblement sabreu,
que es tracta del diagrama d’un mòdul anomenat school. S’aconsella batejar el és diferent de les
nomenclatures
diagrama Dia amb el nom del corresponent mòdul, ja que en el procés de generació recomanades en altres
entorns de POO, com és el
del mòdul a partir del diagrama, Dia proposa el nom del diagrama com a nom del cas del llenguatge Java.
mòdul, tot i que es pot canviar.
En aquests materials
Observem el diagrama de la figura 1.6. Per a la classe school.event del evolucionarem el diagrama
uml_test amb l’objectiu
mòdul school, en tractar-se del model per a les edicions dels cursos potser d’obtenir un mòdul de nom
school i, per coherència,
hagués estat més encertat el nom school.course.event, de forma similar a la utilitzarem noms school##
per les successives versions
nomenclatura utilitzada per OpenERP per a les comandes de venda i les seves de diagrames
desenvolupats.
línies (sale.order i sale.order.line).
A UML, l’estereotip és un
En el diagrama UML de la figura 1.6, school.professor és una classe abstracta mecanisme d’extensibilitat
que permet indicar una
i school.student és una plantilla de classe. A l’hora de generar els mòduls per distinció d’ús de l’objecte
sobre el qual es defineix.
OpenERP, això no té cap efecte i podrien estar dissenyades com a classes normals.
Fixem-nos que cada classe del diagrama de la figura 1.6 incorpora un estereotip
(nom encerclat entre els símbols << >> per sobre del nom de la classe). El procés
de generació de mòduls OpenERP a partir de diagrames Dia interpreta el contingut
del camp estereotip com la jerarquia de menús, dins OpenERP, en la qual ubicar els
formularis generats a partir del diagrama i utilitza el símbol / per separar els diver-
sos nivells. És a dir, segons el diagrama de la figura 1.6, el formulari corresponent
al manteniment dels cursos estarà en una opció de menú anomenada Courses, dins
el submenú Configuration del menú principal Courses (ja que l’estereotip de la
classe school.course és <<Courses/Configuration/Courses>>). La figura
1.7 mostra la jerarquia de menús esperada a partir del diagrama de la figura 1.6.
F igu r a 1. 7 . Jerarquia de menús pel mòdul desenvolupat a partir del diagrama
És aconsellable instal·lar el
mòdul uml_test original
facilitat per OpenERP, per
poder comparar el disseny En el diagrama de la figura 1.6 observem que entre les classes hi ha uns connectors
efectuat mitjançant l’eina
Dia amb el resultat final dins (associacions entre classes) que són únicament de caire informatiu i no tenen cap
OpenERP.
incidència en la generació del mòdul OpenERP. Les relacions entre les classes es
Instal·leu el mòdul defineixen a través d’atributs relacionals dins de cada classe; la facilitat de dia-
uml_test original facilitat
per OpenERP, seguint les gramació d’associacions entre classes que facilita l’eina Dia no és aprofitada pel
indicacions finals de
l’annex “Instal·lació de Dia mòdul uml_dia quan genera els mòduls OpenERP; en conseqüència, la utilització
amb Phyton (PyDia) a
Windows per dels connectors associatius de Dia serveixen, únicament, com a documentació
desenvolupar mòduls
OpenERP”. gràfica.
Cal interpretar les associacions que observem a la figura 1.6 com:
1. Un professor (fletxa de school.professor cap a school.course) pot

impartir diversos cursos.
2. Un curs (fletxa de school.course cap a school.event) pot tenir diverses

edicions.
3. Un curs pot tenir diversos estudiants i un estudiant pot cursar diversos cursos
(fletxa amb doble sentit entre school.course i school.student).
Si seleccionem qualsevol de les associacions del diagrama de la figura 1.6 i

n’editem les propietats, observem que l’eina Dia, per documentar encara més
el diagrama, permet indicar els rols i la multiplicitat. Així, podríem retocar el
diagrama de la figura 1.6 per aconseguir un diagrama més documentat com el de
la figura 1.8.
F ig ur a 1. 8. Diagrama UML amb multiplicitats a les associacions
El diagrama de classes de les figura 1.6 i figura 1.8 mostra únicament la capçalera
de les classes (nom i estereotip) i aquestes classes poden contenir membres (dades
i mètodes). Per visualitzar dades i/o mètodes (atributs i/o operacions, segons
nomenclatura de l’eina Dia) d’una classe, cal seleccionar la classe i editar les seves
propietats (botó secundari del ratolí), i activar les caselles de verificació Atributs
visibles i Operacions visibles. En activar-les per a totes les classes, obtenim la
visualització de la figura 1.9.
Una ullada ràpida al diagrama de la figura 1.9 ens permet afirmar que les seves
classes no incorporen cap operació i únicament contenen atributs. Aprofitarem
les classes d’aquest diagrama per exemplificar els diversos tipus d’atributs de les
classes d’un mòdul OpenERP i com es defineixen en un diagrama dissenyat amb
l’eina Dia.
F ig ur a 1 . 9. Diagrama UML amb la visualització d’atributs i operacions activades
Disseny d’atributs de classe amb Dia
Els atributs de les classes d’un mòdul OpenERP són bàsicament de tres categories:
bàsicsosimples, relacionals i funcionals.
Els atributs simples o bàsics són aquells destinats a contenir un valor concret
(enter, real, booleà, cadena...). Els atributs relacionals són aquells destinats
a representar les relacions entre classes. Els atributs funcionals són uns
camps especials perquè no s’emmagatzemen a la base de dades i es calculen
en temps real a partir d’altres atributs.
Situem-nos en el mòdul del fitxer uml_test.dia i activem la visibilitat d’atributs per

a totes les classes (figura 1.10). Fixem-nos, per exemple, en els vuit atributs de la
classe school.course: set són simples o bàsics ( name, subject, hours_total,
requirements, website, date i note) i un és relacional (prof_id).
F igu r a 1. 1 0 . Diagrama uml_test.dia amb visibilitat de tots els atributs
Atributs simples o bàsics

Un diagrama Dia amb la visualització d’atributs activada mostra per cada atribut
simple, la seqüència d’informació següent:
1. Atribut de visibilitat (+ per públic, - per privat i # per protegit).
2. Nom de l’atribut, seguit del símbol :.
3. Tipus d’atribut (boolean, integer, float, char, text, date, datetime,

binary, selection, reference).
4. Símbol =.
5. Etiqueta pel camp, entre cometes simples, d’obligada existència.
6. Cap o més paràmetres, seguint la sintaxi nom=valor i separats per coma.

Així, la classe school.course del diagrama uml_test.dia té un atribut públic

(símbol +), destinat a emmagatzemar el nom (name) del curs, amb etiqueta Course,
de tipus caràcter (char) de 32 caràcters com a molt (paràmetre size) i amb
obligatorietat de valor (required=’True’). Fixem-nos que la definició del camp
en el diagrama és:
1 +name: char = ’Course’, size=32, required = ’True’
La taula 1.1 presenta, amb detall, els diversos tipus de dades possibles pels atributs
simples o bàsics.
Taul a 1. 1. Tipus de dades pels atributs simples o bàsics en mòduls OpenERP
Nom Què emmagatzema? Observacions
boolean Valors lògics Valors vàlids: True i False
integer Valors enters
float Valors reals Pot anar acompanyat d’un

paràmetre digits destinat a
indicar la precisió i l’escala de
l’atribut. L’escala és el nombre de
dígits després del punt decimal i
la precisió és el nombre total de
dígits significatius (abans i
després del punt decimal). Si el
paràmetre digits no hi és, serà
considerat com un nombre en
punt flotant amb doble precisió.
date Valor data
datetime Valor data i hora en un mateix

camp
char Cadena de longitud limitada És obligatori indicar el paràmetre

size=valor, per indicar la
màxima longitud permesa.
text Cadena de longitud il·limitada
binary Cadena binària
selection Un valor d’una llista de valors En aquest cas, abans del valor de
possibles predefinits l’etiqueta del camp, cal indicar la
llista de valors possibles, com a
seqüència de parelles (valor,
etiqueta):
[(valor1, etiqueta1),
(valor2, etiqueta2)...].
reference Punter cap a un objecte existent Els objectes d’OpenERP que es

en OpenERP poden seleccionar per una
referència es defineixen en el
menú
Settings|Personalització|Objectes
de baix nivell|Sol·licituds|Tipus de
referències en sol·licituds
d’OpenERP.
Com a exemple d’atribut selection podem observar l’atribut contract de la

classe school.professor del diagrama uml_test.dia. Fixem-nos que la llista
conté dos valors (trainee i named) pels quals la visualització des del programa
serà Trainee i Named, a no ser que apliquem un procés de traducció de l’aplicació
(però a nivell de la base de dades, els valors emmagatzemats sempre seran
trainee i named, tot i que pugui semblar més lògic que a la base de dades s’hi
emmagatzemi uns valors més simples com, per exemple, les incials t i n.
La taula 1.2 presenta, amb detall, els paràmetres que poden acompanyar als
atributs, distingint si són obligatoris o optatius i si són comuns o específics d’algun
tipus de dada.
Taul a 1. 2. Paràmetres que poden acompanyar els atributs bàsics
Nom Obligatori Atribut al qual Significat

acompanya
size Sí char Llargada màxima de la

cadena
digits No float Indicar la precisió i

escala en format (p,s).
Veure explicació del
camp float a la taula
1.1.
required No Qualsevol Indicar l’obligatorietat de

l’atribut amb el valor
True. Per defecte, el seu
valor és False.
readonly No Qualsevol Indicar que l’atribut és

de només lectura, amb
el valor True. Per
defecte, el seu valor és
False.
select No Qualsevol Exigir que a nivell de la

base de dades es generi
un índex per aquest
camp per tal d’optimitzar
els processos de
recerca, amb el valor 1.
Per defecte el seu valor
és 0.
help No Qualsevol Indicar el missatge

d’ajuda que OpenERP
visualitza en situar el
ratolí damunt l’etiqueta
del camp. Provoca que
l’etiqueta vagi
acompanyada per un
petit interrogant a
l’extrem superior
esquerre.
translate No char o text Indicar que el valor del

camp pot ser traduït pels
usuaris, amb el valor
True. Per defecte, el seu
valor és False.
En el client web, els camps amb l’atribut translate a True presenten, en mode
edició, una banderola al final de la caixa de text que conté el valor del camp, per
indicar que el camp és traduïble. Prement el ratolí damunt la banderola, s’obre una
pantalla que recull tots els camps traduïbles del formulari i ens permet traduir-los.
Podeu comprovar-ho en el camp Nom del formulari de productes d’OpenERP. En
el client GTK, també hi ha una banderola, però la funcionalitat de traducció no
funciona en la versió 6.1.
La introducció dels diversos valors per definir un atribut simple des de l’eina Dia,
s’efectua des de la pestanya Atributs de les propietats de la classe, seguint els
criteris següents:
• La visibilitat de l’atribut (públic, privat o protegit) s’escull en el camp

Visibilitat.
• El nom de l’atribut s’introdueix a l’apartat Nom.
• El tipus de l’atribut s’introdueix a l’apartat Tipus.
• El nom de l’etiqueta (obligatori i entre cometes simples), seguit de la

seqüència de parelles paràmetre=valor que correspongui, separades per
coma, s’introdueix a l’apartat Valor.
• L’ajuda que acompanya el camp (paràmetre help), s’introdueix a l’apartat

Comentari.
Podeu comprovar l’aplicació dels criteris anteriors tot editant les propietats de
qualsevol dels atributs bàsics de les classes del diagramauml_test. La figura
1.11 mostra la definició de l’atribut name de la classe school.course.
Us heu adonat que, en els paràmetres presentats, no n’hi ha cap que faci referència
a la definició d’un camp identificador de la classe? OpenObject és el framework
sobre el qual està
F ig ur a 1. 11. Exemple de definició d’atribut bàsic de classe de mòdul OpenERP des de Dia desenvolupat OpenERP, de
manera que en parlar de
facilitats de
desenvolupament, ens hem
de referir a l’OpenObject.
Es pot utilitzar OpenObject
per desenvolupar altres
aplicacions que no tinguin
res a veure amb OpenERP.
A OpenObject, cada classe té un atribut identificador, de nom id, generat

automàticament per la capa Object Relational Mapping (ORM) d’OpenObject,
de manera que no s’ha d’indicar en la definició dels atributs de la classe. El valor
de l’atribut id per a cada objecte és generat automàticament per OpenObject i
identificarà l’objecte (el registre a nivell de la base de dades) per sempre més.
Aquest identificador també s’utilitza per relacionar objectes (integritat referencial
a nivell de base de dades).
Llavors, si l’atribut identificador dels objectes d’una classe el genera OpenObject,

com podem definir un camp que identifiqui un objecte tal com estem acostumats
en la majoria d’aplicacions informàtiques? Per exemple, fixem-nos en l’atribut
IDNum de la classe school.student. L’ajuda introduïda diu, textualment: This is

the uniq ID of the student. Com podem aconseguir que IDNum sigui veritablement
identificador? Doncs per això haurem d’utilitzar la restricció d’unicitat que facilita
OpenObject, però que no podem indicar a través de l’eina Dia i ho haurem de fer,
L’atribut IDNum no segueix el més endavant, via el llenguatge Python.
conveni d’estar escrit en
minúscules. Això provoca
que no s’instal·li en
servidors OpenERP en
L’atribut id és, doncs, un atribut especial però no és l’únic. La taula 1.3
plataformes Linux. presenta amb detall els atributs de classe bàsics especials per tenir en compte quan
desenvolupem OpenObject.
Tau la 1.3 . Atributs de classe bàsics especials en OpenObject

Nom Tipus Explicació
id integer Atribut identificador dins la classe utilitzat per

identificar cada objecte (registre a nivell de base
de dades) per sempre més i per establir les
relacions entre objectes de diverses classes
(integritat referencial a nivell de base de dades).
El crea l’eina ORM d’OpenObject i, per tant, no
s’ha d’indicar en dissenyar una classe.
create_date datetime Emmagatzema el moment temporal en què es

crea l’objecte. El crea l’eina ORM.
write_date datetime Emmagatzema el moment temporal de la

darrera modificació de l’objecte. El crea l’eina
ORM.
create_uid integer Emmagatzema l’identificador (id) de l’usuari

que va crear l’objecte. Aquest usuari és un
objecte de la classe res.user (o registre de la
taula res_user). El crea l’eina ORM.
write_uid integer Emmagatzema l’identificador (id) de l’usuari

que ha modificat per darrera vegada l’objecte.
Aquest usuari és un objecte de la classe
res.user (o registre de la taula res_user). El
crea l’eina ORM.
name char És l’atribut que utilitza OpenObject quan ha de

mostrar objectes en una llista desplegable. En
conseqüència, aquest atribut és obligatori en
qualsevol classe C susceptible de ser
referenciada des d’altres classes, ja que en
aquestes caldrà facilitar una llista desplegable
per facilitar la selecció dels objectes de C.
active boolean És un atribut que afegirem a aquelles classes

per les quals interessi poder amagar objectes
en algun moment de la seva vida. Podria servir,
per exemple, per amagar objectes històrics
sense eliminar-los. Un objecte inactiu ja no és
accessible ni apareix per enlloc, fins que es
torni a activar.
state selection És un atribut que afegirem a aquelles classes

per les quals interessi poder definir diversos
estats del cicle de vida d’un objecte.
parent_id integer És un atribut que permet definir estructures

jeràrquiques entre objectes de la mateixa
classe. Acostuma a sorgir com a conseqüència
d’una associació reflexiva en una classe.
Com a exemple de la utilització que fa OpenObject de l’atribut name, podem anar

a consultar la llista de clients d’una empresa, on observarem la columna País, que
mostra el contingut de l’atribut name del país al qual pertany el client. Si anem a
la base de dades a consultar el contingut de la taula res_partner_address (que
conté les adreces dels clients), hi veurem el camp country_id, com a clau forana
de l’atribut id de la taula res.country. A la llista de clients, però, no veiem el
contingut de l’atribut country_id (que és el que relaciona el client amb el país)
sinó el contingut de l’atribut name del país referenciat.
OpenERP té moltes classes que contenen l’atribut active, com per exemple la
classe res.users (taula res_users). Així, per exemple, podeu anar a Settings
/ Usuaris, editar el registre Demo User, desmarcar la casella Actiu per deixar-lo
no actiu i enregistrar el canvi. Podreu observar com el registre Demo User ha
desaparegut de la llista d’usuaris i ja no sortirà mai més fins que el fem actiu. Per
fer actiu un registre inactiu hem d’aconseguir accedir-hi per canviar el valor de
la casella Actiu. Per aconseguir-ho ens hem de valer de la recerca avançada dels
formularis. Per fer-ho cal seleccionar el camp Actiu i indicar que volem veure els
registres que el tenen en valor fals.
Com a exemple d’utilització de l’atribut state, podem fixar-nos en la classe

sale.order corresponent a les comandes de venda. OpenERP hi defineix
l’atribut state de tipus selection amb els següents valors que defineixen els
diferents estats pels quals pot passar una comanda de venda:
1 [(’draft’, ’Quotation’),
2 (’waiting_date’, ’Waiting Schedule’),
3 (’manual’, ’To Invoice’),
4 (’progress’, ’In Progress’),
5 (’shipping_except’, ’Shipping Exception’),
6 (’invoice_except’, ’Invoice Exception’),
7 (’done’, ’Done’),
8 (’cancel’, ’Cancelled’)
9 ]
Un exemple d’utilització de l’atribut parent_id el trobem, en OpenERP, en la

definició dels tercers (clients i proveïdors). Si editem un client/proveïdor, veurem
com a l’apartat Informació General de la pestanya Vendes & Compres, es pot
indicar quina és l’empresa pare que, en cas de tenir valor, és un altre tercer.
Atributs relacionals
Entre les classes d’OpenObject es pot establir tres tipus de relacions, de manera
similar a les relacions entre les entitats en un model entitat-relació per a bases
de dades. Es defineixen via atributs relacionals dins les classes. Tenim, en
conseqüència, tres tipus d’atributs relacionals: molts a un, un a molts, molts
a molts.
Atribut relacional “molts a un” (many2one)
L’atribut relacional “molts a un” (many2one) s’utilitza per representar una relació
cap a una classe pare, de molts a un, és a dir, molts objectes de la classe que conté
l’atribut poden estar relacionats amb un mateix objecte de la classe pare.
En el diagrama uml_test observem molts atributs relacionals many2one. Un

exemple el tenim a la classe school.event, en la qual l’atribut course_id està
destinat a contenir, per a cada objecte de la classe school.event, l’identificador

de l’objecte pare de la classe school.course.
OpenERP mostra els camps many2one acompanyats per una llista per seleccionar
l’objecte de la classe pare. És a dir, en el formulari per gestionar els cursos
(objectes de la classe school.event), el camp course_id, amb etiqueta Course,
estarà acompanyat d’un desplegable per seleccionar el curs que correspongui
d’entre els objectes de la classe school.course). Això obliga que la classe
referenciada pel camp many2one contingui el camp name.
A nivell de la base de dades, els atributs many2one es mapen en atributs dins la

taula corresponent a la classe que els conté, amb restriccions d’integritat referen-
cial cap a l’atribut identificador de la taula referenciada. Així, l’atribut many2one
course_id de la classe school.event del diagrama uml_test.dia, queda mapat
a la taula school_event en el camp course_id amb una restricció d’integritat
referencial cap a l’atribut id de la taula school_course (automàticament creat
per OpenERP).
Per definir un atribut many2one en l’eina Dia, cal crear l’atribut indicant que és
del tipus many2one i a l’espai valor introduir:
1 ’classeReferenciada’,’etiquetaDelCamp’...
Els punts suspensius del final indiquen que es pot utilitzar alguns paràmetres
opcionals. Concretament:
• ondelete: per indicar com actuar quan l’objecte referenciat per l’atribut
sigui eliminat. Valors possibles: cascade, set null. Valor per defecte:
set null.
• required, readonly, select: amb funcionament idèntic als camps no

relacionals.
Podem observar que l’atribut course_id de la classe school.event té com a

valor:
1 ’school.course’,’Course’,required=True
Està acordat, entre els desenvolupadors en OpenERP, anomenar els atributs

many2one amb el nom de la classe a la qual referencien (o darrer nivell) acom-
panyat de _id, com és el cas de l’atribut course_id.
Atribut relacional “un a molts” (one2many)
Un atribut relacional “un a molts” (one2many) s’utilitza per representar una relació
cap a una classe filla, d’un a molts, és a dir, un objecte de la classe que conté
l’atribut pot estar relacionat amb molts objectes de la classe filla.
Tot atribut one2many és complementari d’un atribut many2one que ha d’existir

obligatòriament a la classe filla. Per definir un atribut one2many en l’eina Dia cal
crear l’atribut indicant que és del tipus one2many i a l’espai valor introduir:
1 ’classeReferenciada’,’nomAtributClasseReferenciada’,’etiquetaDelCamp’...
La classe filla (classeReferenciada) ha de contenir l’atribut

nomAtributClasseReferenciada de tipus many2one apuntant a la classe
en la qual hi ha l’atribut one2many.
Els punts suspensius del final indiquen que es pot utilitzar alguns paràmetres
opcionals. Concretament:
• invisible: per impedir que el seu contingut sigui visible en els formularis
corresponents a la classe a la qual pertany el camp. Valors possibles: True,
False. Valor per defecte: False.
• readonly: amb funcionament idèntic als camps no relacionals.

one2many, amb el nom de la classe a la qual referencien (o darrer nivell)
acompanyat de _ids.
En el diagrama uml_dia observem l’atribut course_ids del tipus one2many a la

classe school.professor, amb el següent contingut a l’espai valor:
1 ’school.course’, ’prof_id’, ’Courses’
L’atribut course_ids de la classe school.professor relaciona un profes-

sor amb el conjunt de cursos que imparteix. En conseqüència, la classe
school.course ha de contenir l’atribut prof_id de tipus many2one cap a la
classe school.professor.
L’existència d’un atribut one2many implica l’existència d’un atribut many2one,

però l’existència d’un atribut many2one no implica l’existència d’un atribut
one2many. La definició dels atributs one2many té dos objectius:
• Aconseguir que en les vistes (formularis) que continguin el camp one2many

aparegui una llista dels objectes referenciats (tal com mostra la zona
apuntada per la fletxa de la figura 1.12).
• Facilitar l’accés, quan es desenvolupen mètodes (lògica de negoci) de

la classe que conté el camp one2many, cap als objectes referenciats per
l’objecte sobre el qual s’executi el mètode.
F igu r a 1. 1 2 . Formulari per al manteniment de professors amb un subformulari
El desenvolupament de
mètodes (lògica de
negoci) en OpenERP es
troba a l’apartat El paràmetre invisible=True en un atribut one2many provoca que cap formulari
“OpenERP: la vista i el
controlador” en el qual aparegui l’atribut incorpori la llista dels objectes referenciats. D’aquesta
manera, l’atribut únicament pot servir per facilitar l’accés als objectes referenciats
en els mètodes desenvolupats sobre la classe.
Si observem el diagrama uml_dia original facilitat per OpenERP, podem observar

que l’atribut prof_id de la classe school.course conté, a l’espai valor:
1 ’res.partner’,’Professor’,required=True
La definició de l’atribut prof_id a la classe school.course és errònia, ja que no

apunta a la classe school.professor, sinó a la classe res.partner. El mòdul
Si heu instal·lat el mòdul generat quan es manté aquesta definició té un mal funcionament.
uml_test proporcionat per
OpenERP, podeu comprovar
el mal funcionament si feu la
creació d’un professor i
Per solucionar la situació errònia i aconseguir que l’atribut prof_id de la
intenteu assignar-li cursos i classe school.course sigui complementari de l’atribut course_ids de la classe
des d’un curs intenteu
assignar-li el seu professor. school.professor, haurem de canviar el contingut a l’espai valor de l’atribut
prof_id de la classe school.course, per:
1 ’school.professor’,’Professor’,required=True
La figura 1.12 també ens permet observar l’efecte dels atributs many2one. Ob-
servem que els camps etiquetats per Associated Partner i Private Address van
acompanyats per dues icones: una icona lupa, que permet accedir a la llista dels
objectes de la classe referenciada per aquests camps, i una icona carpeta que
permet accedir a la fitxa de l’objecte referenciat. Si observem els corresponents
atributs dins la classe school.professor veurem que es tracta dels camps
partner_id i address_id, de tipus many2one.
Atribut relacional “molts a molts” (many2many)
L’atribut relacional “molts a molts” (many2many) s’utilitza per representar una

relació de molts a molts entre dos objectes, és a dir, quan cada objecte d’una classe
A pot estar relacionat amb molts objectes d’una classe B i cada objecte d’una
classe B pot estar relacionat amb molts objectes d’una classe A.
Un exemple de relació many2many el trobem entre les classes school.student i

school.course, ja que un estudiant es pot inscriure a molts cursos i en un curs
hi pot haver molts estudiants inscrits.
Per definir un atribut many2many en l’eina Dia cal crear l’atribut en alguna de les
dues classes que relaciona, o en ambdues, indicant el tipus many2many i, a l’espai
valor, introduir:
1 ’classeReferenciada’,’nomTaulaRelacional’,’nomCampFKPropi’,’
nomCampFKAltraClasse’,’etiquetaDelCamp’

many2many, amb un nom (adequat a les dues classes que relaciona) acompanyat
de _ids. Fixem-nos que la definició d’un atribut many2many implica la creació
d’una taula relacional a la base de dades.
En el diagrama uml_dia observem l’atribut subscriptions del tipus many2many

a la classe school.student, amb el següent contingut a l’espai valor:
1 ’school.course’,’course_student_subscription_rel’,’course_id’,’student_id’,’
Subscriptions’
L’atribut subscriptions relaciona la classe school.student (en la qual és

definit) amb la classe school.course, fet que provocarà l’aparició d’una nova
taula a la base de dades, de nom course_student_subscription_rel, que
tindrà l’atribut course_id amb restricció d’integritat referencial cap a la classe
school.student i l’atribut student_id amb restricció d’integritat referencial
cap a la classe school.course.
L’atribut subscriptions presenta algunes anomalies de notació:
• El nom no segueix el conveni, ja que seria bo que el seu nom finalitzés en

_ids.
• El nom de la taula relacional que es generarà a la base de dades seria bo

que comencés amb el prefix school_, de la mateixa manera que la resta de
taules vinculades a aquest mòdul.
• Els noms assignats als tercer i quart paràmetres del contingut de l’espai
valor haurien d’estar a l’inrevés, de manera que course_id fos el nom per
fer referència a la classe school.course i student_id fos el nom per fer
referència a la classe school.student.
Així doncs, seria millor redefinir l’atribut subscriptions, canviant-li el nom per
course_ids i amb el següent contingut a l’espai valor:
1 ’school.course’,’school_student_course_rel’,’student_id’,
2 ’course_id’,’Subscriptions to courses’
Un atribut many2many provoca que l’eina Dia, en generar el formulari per al

manteniment dels objectes de la classe, hi incrusti una zona de tipus llista per
accedir als registres de la classe referenciada per l’atribut many2many. La figura
1.13 mostra com serà el formulari generat per l’eina Dia per al manteniment dels
estudiants. En ella hi observem la zona apuntada per la fletxa, corresponent a la
llista de cursos assignats a l’estudiant indicat a la capçalera del formulari.
Figu r a 1. 13 . Formulari per al manteniment d’estudiants amb els cursos on estan subscrits
Fig ur a 1 . 14 . Formulari per al manteniment de cursos amb els estudiants que hi estan subscrits
En cas que interessi que en el formulari dels cursos hi aparegui una zona de
tipus llista per accedir als estudiants subscrits al curs, caldrà definir un atribut
many2many a la classe school.course, en el qual el nom de la taula relacional i
els noms dels seus camps han de coincidir amb la definició de l’atribut many2many
de la classe school.student. Així, per exemple, podem definir-hi l’atribut
student_ids amb el següent contingut a l’espai valor:
1 ’school.student’,’school_student_course_rel’,’course_id’,’student_id’,’Students
’
La figura 1.14 en mostra el resultat en el formulari de manteniment dels cursos.
Generació de mòdul OpenERP des de Dia
L’eina Dia permet generar, a partir d’un diagrama dissenyat per a un mòdul
OpenERP, el corresponent mòdul per ser instal·lat seguint el procediment habitual. A l’annex “Instal·lació de
Dia amb Phyton (PyDia) a
Windows per
Per aconseguir el mòdul OpenERP, cal haver incorporat a l’eina Dia el guió desenvolupar mòduls
OpenERP” trobareu les
codegen_openerp.py de Python i, en tal situació, l’opció Fitxer | Exportar de indicacions per
aconseguir que Dia pugui
Dia mostra l’opció d’exportació PyDia Code Generation (OpenERP) (*.zip) que generar mòduls OpenERP
per a la seva instal·lació.
és la que hem d’utilitzar per aconseguir el mòdul per ser instal·lat en OpenERP.
En el moment d’exportar un diagrama Dia cap a mòdul OpenERP, l’eina proposa

com a nom de mòdul el mateix nom del diagrama, però es pot decidir el nom que
es desitgi i l’eina genera un fitxer ZIP amb el nom indicat, que no es podrà canviar
de manera simple, ja que en el seu interior es generen continguts que utilitzen el
nom indicat i caldria fer diversos retocs. En conseqüència, el nom indicat en el
moment de la generació és el nom del mòdul que podrà ser instal·lat en OpenERP.
Errors de l’eina Dia o del guió codegen_openerp.py
Entre generació i generació de mòdul OpenERP des de l’eina Dia cal reiniciar l’eina, ja que
sembla que, en algunes ocasions, la generació no parteix de zero, sinó que afegeix el codi
generat al codi de la generació prèvia. Amb motiu de tenir accés a
la història de les diverses
millores incorporades al
Cal generar el mòdul en el mateix directori en el qual es troba el diagrama Dia, ja que del diagrama Dia,
contrari es genera un mòdul buit. corresponents al mòdul
school, afegirem un sufix
numèric _## a les diverses
Cal tenir en compte que el guió codegen_openerp.py, facilitat en el mòdul uml_dia per versions que anem
la versió 5.0 d’OpenERP, no genera correctament l’arbre de menús adequat a la versió generant.
6.1 d’OpenERP. Recordem que el menú en el qual havia d’estar ubicat el manteniment
corresponent a una classe s’indicava en el camp estereotip de les propietats de la Per a poder instal·lar el
mòdul school aquí
classe. En conseqüència, abans d’instal·lar un mòdul generat per Dia amb el guió generat, cal retocar els
codegen_openerp.py de la versió 5.0, en un servidor OpenERP 6.1, caldrà retocar la menús tal com s’indica al
final de l’annex
definició de menús en el mòdul generat. “Instal·lació de Dia amb
Phyton (PyDia), en
Windows, per
Suposant que hem incorporat els diversos retocs indicats fins ara al diagrama desenvolupar mòduls
OpenERP”, utilitzant els
uml_dia original, procedim a enregistrar-lo amb nom school_01.dia i procedim menús indicats en
school_01_menus.txt,
a generar el mòdul school. fitxer ubicat a l’apartat
annexos del web. També
Abans d’instal·lar el nou mòdul school, si a l’empresa on pensem instal·lar- trobareu el mòdul ja
preparat sota el nom
lo hi ha instal·lat el mòdul uml_test cal desinstal·lar-lo, ja que ambdós mò- school_01.zip dins
l’apartat “Mòduls
duls tenen taules coincidents i són incompatibles. Posteriorment, haurem OpenERP” dels annexos
d’establir una connexió amb la base de dades de PostgreSQL i eliminar les del web.
taules generades pel mòdul uml_test: school_professor, school_course,

school_event, school_student i course_student_subscription_rel.
Una vegada instal·lat el nou mòdul school, la base de dades contindrà
les taules: school_professor, school_course, school_course_event,
school_student i school_student_course_rel.
1.3.2 Disseny del model amb Python
L’eina de diagramació Dia, amb l’extensió per generar mòduls per a OpenERP,
facilita el disseny de mòduls per OpenERP. Les possibilitats que permet l’eina Dia
són, però, limitades i, en conseqüència, ens cal aprendre com escriure directament
els mòduls utilitzant els llenguatges Python i XML.
Un mòdul d’OpenERP incorpora, en el seu interior, tots els elements del patró
model-vista-controlador en el qual es basa el desenvolupament d’OpenObject.
L’eina Dia permet definir el model via diagrama UML i l’extensió per generar
mòduls per a OpenERP ens facilita el mòdul que conté:
• El model, definit a través de llenguatge Python, corresponent al diagrama

UML dissenyat.
• Una vista, definida a través del llenguatge XML, generada de forma auto-
màtica.
• Un controlador buit, ja que l’eina Dia no permet dissenyar els mètodes.
El nostre objectiu final és dissenyar mòduls utilitzant directament el llenguatge

En el Technical Memento Python pel model i el controlador, i el llenguatge XML per la vista.
d’OpenERP hi trobareu el
recordatori sobre tot allò
que cal saber respecte el
disseny del model.
Estructura d’un mòdul
Els mòduls d’OpenERP s’ubiquen dins la carpeta addons ubicada en alguna

subcarpeta d’on s’ha instal·lat OpenERP. No podem donar una ubicació concreta
ja que ha anat canviant amb les versions d’OpenERP. Així, per exemple:
• En les versions 5.0 i 6.0 d’OpenERP per a Windows s’ubiquen a:
1 camíOnÉsUbicatOpenERP\Server\addons
• En la versió 6.1 d’OpenERP per a Windows, a:
1 camíOnÉsUbicatOpenERP\Server\server\openerp\addons
Els passos necessaris per a crear un nou mòdul són:
1. Crear la subcarpeta dins la carpeta addons.

2. Crear el fitxer __init__.py, necessari perquè Python consideri que el contin-

gut de la carpeta correspon a un paquet.
3. Crear un arxiu de descripció del mòdul, que s’ha d’anomenar __ope-

nerp__.py. Fins la versió 5.0 s’anomenava __terp__.py i les versions
posteriors continuen admetent aquest nom per qüestions de compatibilitat.
4. Crear els fitxers Python que han de contenir les classes, amb els atributs
i els mètodes. En aquests fitxers es defineix el model i el controlador
(arquitectura MVC).
5. Crear els fitxers XML per la gestió de les dades (vistes, accions, menús,
dades d’exemple...). En aquests fitxers es defineix la vista (arquitectura
MVC).
6. De forma opcional, crear informes, assistents i fluxos de treball, que poden

estar en qualsevol lloc dins la carpeta, però es recomana ubicar-los en
subcarpetes anomenades report, wizard i workflow.
7. De forma opcional, incorporar traduccions i regles de seguretat, que poden

estar en qualsevol lloc dins la carpeta, però es recomana ubicar-les en
subcarpetes anomenades i18n i security.
Nomenclatura d’OpenObject vers nomenclatura POO
OpenObject no utilitza la nomenclatura habitual de POO i no parla de classes i d’objectes.

Així, les instàncies que gestiona (productes, clients, proveïdors. . . ) s’anomenen recursos
(en lloc d’objectes) i l’abstracció o definició de les instàncies s’anomena objecte (en lloc de
classe).
Inicialització del mòdul: fitxer __init__.py
El fitxer __init__.py és executat, com en qualsevol mòdul Python, en el procés

d’inicialització del programa.
En aquest fitxer cal situar tots els imports de fitxers Python que cal carregar per a
l’execució del programa.
Així, si el mòdul conté un fitxer de nom module.py que conté la descripció de les
classes, caldrà incorporar, dins el fitxer __init__.py la instrucció:
1 import module
Observeu el contingut del
fitxer __init__.py de
qualsevol dels mòduls que
incorpora OpenERP o del
Descripció del mòdul: fitxer __openerp__.py mòdul school generat.
Tot mòdul d’OpenERP ha de contenir un fitxer anomenat __openerp__.py (fins la

versió 5.0 s’anomenava __terp__.py) ubicat a l’arrel de la carpeta corresponent
al mòdul. Aquest fitxer ha de tenir format d’un diccionari de Python i és el
responsable de determinar, entre altres coses, el nom, la descripció, els autors,
la llicència, la versió, la categoria, els fitxers XML que seran analitzats durant
l’arrencada del servidor OpenERP i les dependències amb altres mòduls.
Aquest fitxer ha de contenir un diccionari Python amb els següents valors:
• name: el nom del mòdul, en anglès.
• version: la versió del mòdul.
• description: la descripció del mòdul (text).
• author: l’autor del mòdul.
• website: el lloc web de l’autor del mòdul.
• license: la llicència del mòdul (per defecte, la que correspon a la versió

de servidor OpenERP on s’instal·larà el mòdul).
• category: categoria a la qual pertany el mòdul. Text separat per barres /

amb la ruta jeràrquica de les categories.
• depends: llista Python de mòduls dels quals depèn aquest mòdul. El mòdul
base s’acostuma a afegir perquè conté dades utilitzades en vistes, informes...
• init_xml: llista Python de noms de fitxers XML que es carregaran en

iniciar el servidor OpenERP amb l’opció -init=module. Les rutes dels
fitxers han de ser relatives a la carpeta on és el mòdul. En aquesta llista
s’acostuma a posar els fitxers relatius a definició de workflows i les dades a
carregar en el procés d’instal·lació del mòdul.
• update_xml: llista Python de noms de fitxers XML que es carregaran en

iniciar el servidor OpenERP amb l’opció -update=module. Les rutes dels
fitxers han de ser relatives al directori on és el mòdul. En aquesta llista
s’inclouen els fitxers relatius a vistes, informes i assistents.
• demo_xml: llista Python de noms de fitxers XML que es carregaran si s’ha

instal·lat el servidor OpenERP amb dades de demostració o exemple. Les
rutes dels fitxers han de ser relatives al directori on és el mòdul.
• installable: els valors permesos són True o False i determinen si el

mòdul és o no és instal·lable.
• active: els valors permesos són True o False i determinen si el mòdul

serà instal·lat automàticament en el procés de creació de l’empresa. Per
defecte, False.
En Python, els diccionaris
es defineixen entre {} amb
parelles clau:valor
separades per comes; les
llistes entre [] amb valors
separats per comes. Definició d’objectes OpenERP amb Python
Observeu el contingut del

fitxer __openerp__.py de
qualsevol dels mòduls que
El model en OpenERP es descriu a través de classes escrites en Python i
incorpora OpenERP o el
fitxer __terp__.py del
OpenObject s’encarrega de fer-les persistents en el SGBD PostgreSQL.
mòdul school generat per
l’eina Dia. Per definir un objecte (classe) d’OpenERP cal definir una classe de Python
i posteriorment instanciar-la, fet que provoca la creació de l’objecte (classe)
d’OpenERP. La classe ha d’heretar obligatòriament de la classe osv del mòdul
osv.
L’esquelet de la classe Python que permet definir l’objecte OpenERP té la forma:
1 class name_of_the_object (osv.osv):

2 _name = ’name.of.the.object’
3 _columns = {...}
4 ...
5 name_of_the_object()
Les classes Python que permeten definir objectes (classes) d’OpenERP tenen dos
atributs obligatoris i altres opcionals. Els atributs obligatoris són:
• _name: nom de l’objecte (classe) d’OpenERP. Aquest nom s’utilitza de

forma automàtica per generar el nom de la taula de PostgreSQL, i canvia
els punts per guions baixos.
• _columns: diccionari Python amb la declaració de les dades de l’objecte

(classe) d’OpenERP, que passaran a ser les columnes de la taula de Post-
greSQL.
L’aplicació de l’atribut
Els atributs opcionals són: _auto queda palesa en el
disseny d’informes i
quadres de comandament.
• _auto: els valors possibles són True i False. Per defecte True. Determina
si s’ha de generar la taula PostgreSQL a partir de la definició de l’objecte
OpenERP. El valor False s’utilitza per objectes OpenERP no persistents
que es basen en vistes definides en PostgreSQL.
• _constraints: definició de restriccions sobre l’objecte, definides amb

codi Python.
• _sql_constraints: definició de restriccions SQL sobre l’objecte, defini-

des a la corresponent taula de PostgreSQL.
• _defaults: diccionari Python que conté els valors per defecte per les dades
(definides a _columns) de l’objecte (classe) d’OpenERP que ho precisin.
• _inherit: objecte (classe) d’OpenERP del qual hereta l’objecte (classe)

que estem definint.
• _inherits: llista d’objectes (classes) d’OpenERP dels quals hereta l’objec-

te (classe) que estem definint. La llista ha de seguir la sintaxi d’un diccionari
Python de la forma:
1 {’nom_objecte_pare’:’nom_de_camp’,...}
• _log_access: valors possibles True i False. Per defecte, True. Indica si

els accessos d’escriptura als recursos (objectes) han de quedar enregistrats.
En cas afirmatiu, de forma automàtica es creen a la corresponent taula
de PostgreSQL les columnes create_uid, create_date, write_uid i
write_date per enregistrar els accessos d’escriptura.
• _order: nom dels atributs utilitzats per ordenar els resultats dels mètodes
de cerca i lectura. Per defecte, s’utilitza el camp _id generat automàtica-
ment en totes les taules de PostgreSQL corresponents a objectes (classes)
d’OpenERP. Exemples:
1 _order = ’name’
1 _order = ’date_order desc’
• _rec_name: nom de l’atribut de l’objecte (classe) d’OpenERP que conté el

nom informatiu de cada recurs (objecte) concret. Per defecte name.
• _sequence: nom de la seqüència SQL que gestiona els identificadors (con-

tingut del camp _id) pels recursos d’aquest objecte (classe) d’OpenERP.
Per defecte, nomDeLaTaula_id_seq.
• _sql: codi SQL a executar en la creació de l’objecte, en cas que _auto sigui
True.
• _table: nom de la taula SQL si es vol que sigui diferent del nom automàtic
a partir del nom de l’objecte substituint els punts per guions baixos.
Una vegada presentats els possibles atributs de les classes Python dissenyades
per generar objectes (classes) d’OpenERP, ens cal endinsar-nos en els possibles
continguts d’alguns d’aquests atributs.
Tipus de camps
L’atribut _columns de la classe Python que defineix l’objecte (classe) d’OpenERP
ha de contenir un diccionari Python amb la definició dels atributs de l’objecte
d’OpenERP, a partir dels camps (fields) predefinits a la classe osv.
La sintaxi general per definir una columna és la següent:
1 ’nom_camp’:fields.tipus_de_camp(paràmetres)
on tipus_de_camp ha de ser un dels tipus facilitats per la classe osv i el contingut

de paràmetres depèn del tipus del camp.
Hi ha diverses categories de camps:
• Camps simples: boolean, integer, float, char, text, date, datetime,

binary i selection.
• Camps relacionals: many2one, one2many, many2many i related.
• Camps function.
• Camps property.
Els tipus de camps simples i relacionals habituals (many2one, one2many i

many2many) ja ens són familiars a causa de la seva utilització en el disseny de
mòduls amb l’eina de diagramació Dia. Per a tots aquests camps, el contingut
de paràmetres en la crida fields.tipus_de_camp(paràmetres) es correspon
amb el contingut de l’espai valor en la definició de cada atribut de classe mitjançant
l’eina Dia. Exemples d’utilització dels
tipus de camps simples i
relacionals habituals
En aquest punt és convenient observar les classes del fitxer school.py generat (many2one, one2many i
many2many) els podeu
a partir de l’eina Dia. Observem que les classes definides incorporen únicament trobar a l’apartat “Disseny
d’atributs de classe amb
els atributs obligatoris _name i _columns. En la classe Python no hi observem Dia” en aquest document.
cap atribut opcional (valors per defecte, restriccions...) i en l’objecte (classe)
d’OpenERP només apareixen camps simples i relacionals habituals (many2one,
one2may i many2many). Centrem-nos ara en els tipus de camps encara descone-
guts (related, function i property).
Tipus relacional related
Els camps related permeten accedir a un camp d’un altre objecte referenciat des
del propi objecte; és a dir, com si es tractés de camps encadenats.
Com a exemple, suposem que en un mòdul d’OpenERP tenim les classes exem-
plificades en el diagrama UML de la figura 1.15. En un mòdul per a OpenERP, a
la classe City hi haurà un camp relacional many2one cap a la classe State, i a la
classe State hi haurà un camp relacional many2one cap a la classe Country. Un
camp related ens permet accedir des de la classe City a la classe Country via
la classe State.
Figu ra 1 . 1 5. Disseny UML amb dues relacions many2one
La definició d’una columna related ha de seguir la sintaxi:

1 ’nom’: fields.related(’campPontPropi’,’campOnAccedir’,
2 type=’tipusDelCamp’, string=’etiquetaNouCamp’
3 [,store=True/False][,...]),
Els punts suspensius del final indiquen que hi pot haver més paràmetres segons el
tipus del camp. Així, en els camps de tipus many2one, caldrà afegir un paràmetre
relation per indicar el nom de la classe relacionada. El paràmetre store (per
defecte False) permet indicar si el valor accedit ha de quedar enregistrat a la
base de dades (cas clar de redundància) per tal de facilitar una major eficiència
d’OpenERP en els processos de recerca i de lectura. En cas d’activar aquesta
redundància, els valors sempre són mantinguts per OpenERP i mai pels usuaris.
Així, per aconseguir que la classe City de la figura 1.15 pugui accedir a
l’identificador de la classe Country via la classe State, hauríem de tenir:
1 # Dins la classe module.state:
2 _columns: {
3 ...
4 ’country_id’: fields.many2one(’module.country’,’Country’),
5 ...
6 }
7
8 # Dins la classe module.city:
9 _columns: {
10 ...
11 ’state_id’: fields.many2one(’module.state’,’State’),
12 ’country_id’: fields.related(’state_id,’country_id’,
13 type=’many2one’,
14 relation=’module.country’,
15 string=’Country’,store=False),
16 ...
17 }
Un cas real d’utilització el podem observar en el disseny de l’objecte (classe)

res.partner d’OpenERP, on veiem les columnes city, function, subname,
phone, mobile, country i email com a camps related a través del camp
address de la mateixa classe:
1 _columns = {
2 ...
3 ’address’: fields.one2many(’res.partner.address’, ’partner_id’,’Contacts’),
4 ...
5 ’city’: fields.related(’address’, ’city’, type=’char’, string=’City’),
6 ’function’: fields.related(’address’, ’function’, type=’char’,
7 string=’function’),
8 ’subname’: fields.related(’address’, ’name’, type=’char’,
9 string=’Contact Name’),
10 ’phone’: fields.related(’address’, ’phone’, type=’char’, string=’Phone’),
11 ’mobile’: fields.related(’address’, ’mobile’, type=’char’, string=’Mobile’),
12 ’country’: fields.related(’address’, ’country_id’, type=’many2one’,
13 relation=’res.country’,string=’Country’),
14 ’email’: fields.related(’address’, ’email’, type=’char’, size=240,
15 string=’E−mail’),
16 ...
17 }
Exemple d’utilització dels camps related
L’objecte (classe) school.professor del mòdul school que estem millorant

incorpora l’atribut address_id que permet accedir a l’adreça del professor (objecte
res.partner.address).
En executar el formulari de manteniment de professors, apareix el camp Private Address

amb el contingut identificador de l’adreça. Si es vol tenir accés a tota la informació
continguda a l’adreça (carrer, telèfon, correu electrònic...) el formulari permet accedir a
la fitxa de l’adreça.
Imaginem-nos que és important, per a nosaltres, que el telèfon de cada professor es vegi
directament a la fitxa del professor, sense haver d’accedir a la fitxa de l’adreça.
Per aconseguir-ho, com que el telèfon del professor resideix a res.partner.address i ja

accedim a aquest objecte a través del camp address_id, podem definir el següent camp
_related:
1 ’phone’:fields.related(’address_id’,’phone’,type=’char’,size=64,
2 string=’Phone’,store=False,readonly=True),
Podeu efectuar aquesta modificació directament en el programa Python school.py, però no

podreu observar-ne l’efecte per què encara no sabem com afegir camps en els fitxers XML
que proporcionen la vista dels programes. Si efectueu, però, la inserció del nou camp, a
través de l’eina Dia i procediu a generar de nou el mòdul per a OpenERP i actualitzeu el
mòdul instal·lat, podreu veure’n l’efecte.
Podeu aprofitar aquesta actualització per canviar l’arxiu __terp__.py per __openerp__.py i
actualitzar el seu contingut (autor, versió...) Per poder instal·lar el
mòdul school generat cal
retocar els menús tal com
Tipus function s’indica al final de l’annex
“Instal·lació de Dia amb
Python (PyDia) a
Els camps function simulen camps reals però es calculen mitjançant una funció Windows, per
desenvolupar mòduls
Python enlloc d’emmagatzemar-se a la base de dades PostgreSQL. En casos espe- OpenERP”, utilitzant els
menús indicats a
cials, per augmentar la velocitat de consulta d’OpenERP i facilitar les consultes, school_02_menus.txt,
es fan redundants a la base de dades, és a dir, s’emmagatzemen a la base de dades, fitxer ubicat a l’apartat
però sempre són calculats i actualitzats a través de funcions i mai pels usuaris. annexos del web. També
trobareu el mòdul ja
preparat sota el nom
La definició d’una columna function ha de seguir la sintaxi: school_02.zip dins
OpenERP” dels annexos
1 ’nom’: fields.function(fnct, arg=None, fnct_inv=None, fnct_inv_arg=None, del web.
2 type=’Float’, fnct_search=None,
3 string=’etiquetaNouCamp’, store=False,
4 multi=False [,...]),
en la qual:
• Els paràmetres que van acompanyats d’un símbol =Valor no són obligatoris
i el valor indicat és el que es considera en cas de no explicitar el paràmetre.
• type: és el tipus de camp retornat per la funció. Pot ser qualsevol tipus
excepte function. Els punts suspensius del final indiquen que hi pot haver
més paràmetres segons el tipus del camp. Així, en els camps de tipus
’many2one’ caldrà afegir un paràmetre obj per indicar el nom de la classe
relacionada.
• store: per indicar si el camp ha de residir a la taula de la base de dades

(redundància).
• multi: per indicar que el càlcul de la funció s’efectuï per a diversos camps,
a causa que la mateixa funció és invocada en diferents camps (veure, com
exemple, el mòdul auction d’OpenERP).
• fnct: és el mètode que calcula el valor del camp. És un paràmetre

obligatori i ha d’existir abans de declarar el camp funcional. Ha de retor-
nar, obligatòriament, un diccionari de parelles de la forma {id1:valor1,
id2:valor2,...} en el qual id1, id2... han de ser identificadors d’objec-
tes i valor1, valor2... els corresponents valors que han de correspondre
amb el tipus indicat a type. La sintaxi ha de ser:
1 def fnct(self, cr, uid, ids, field_name, arg, context)
• fnct_inv: és un mètode utilitzat per escriure un valor en lloc del camp. La

sintaxi ha de ser:
1 def fnct_inv(obj, cr, uid, id, name, value, fnct_inv_arg, context)
• fnct_search: és el mètode utilitzat per fer recerques per aquest camp. Ha

de retornar la llista de tuples que especifiquin el criteri de cerca a utilitzar
pel mètode search facilitat per OpenObject. La sintaxi ha de ser:
1 def fnct_search(obj, cr, uid, obj, name, args)

Els paràmetres arg i
arg_inv sembla que han de
servir per poder passar
paràmetres a les funcions o Els mòduls d’OpenERP estan plens d’exemples de camps funcionals, però no tots
mètodes fnct i fnct_inv,
però no hi ha documentació són senzills d’entendre en una primera aproximació al tema. Així, per iniciar-
al respecte ni cap mòdul
d’OpenERP (versió 6.1) que nos en els camps funcionals, podem centrar-nos en l’atribut number_of_days del
els utilitzi.
mòdul hr_holidays. Seria interessant que, si no el teniu instal·lat, procedíssiu a
El desenvolupament de instal·lar aquest mòdul, per poder comprovar el que comentarem a continuació.
mètodes (lògica de
negoci) en OpenERP,
necessari per als camps Fixeu-vos en la part de la definició de la classe que ens interessa comentar:
funcionals, es troba a
l’apartat “OpenERP: la
vista i el controlador” 1 class hr_holidays(osv.osv):
2 ...
3 def _compute_number_of_days(self, cr, uid, ids, name, args, context=None):
4 result = {}
5 for h in self.browse(cr, uid, ids, context=context):
6 if h.type==’remove’:
7 result[h.id] = −h.number_of_days_temp
8 else:
9 result[h.id] = h.number_of_days_temp
10 return result
11
12 _columns = {
13 ...
14 ’type’: fields.selection([(’remove’,’Leave Request’),
15 (’add’,’Allocation Request’)],
16 ’Request Type’, required=True,readonly=True, ...),
17 ’number_of_days_temp’: fields.float(’Number of Days’, readonly=True,
18 states={’draft’:[(’readonly’,False)]}),
19 ’number_of_days’: fields.function(_compute_number_of_days,
20 string=’Number of Days’,store=True),
21 ...
22 }
23 ...
El mètode
_compute_number_of_days
crida el mètode browse
facilitat per OpenObject. Fixem-nos que number_of_days és un atribut funcional que, malgrat ser cal-
La llista dels mètodes
facilitats per OpenObject culat mitjançant una funció, el seu resultat resta emmagatzemat a la base de
es troba a l’apartat
“OpenERP: la vista i el dades, a causa de store=True. Podem comprovar, mirant la descripció de
controlador”.
la taula hr_holidays a la taula de PostgreSQL, l’existència de la columna
number_of_days.
Si utilitzeu el mòdul, observareu que permet gestionar, per cada empleat, els
dies d’absència i els dies treballats fora del calendari laboral. Cada recurs
(objecte) de l’objecte (classe) hr.holidays d’OpenERP correspon a un dels dos
tipus possibles (add o remove) segons la definició de l’atribut type. L’atribut
number_of_days_temp conté el nombre de dies afectats, sempre en positiu. En
canvi, l’atribut number_of_days vol contenir el nombre de dies afectats, en
positiu si es tracta de dies de treball addicional, i en negatiu si es tracta de dies
d’absència.
En conseqüència, el camp number_of_days es pot calcular a partir del camp

number_of_days_temp i per això es defineix com un camp funcional, que executa
el mètode _compute_number_of_days definit prèviament.
Observem també que el mètode invocat retorna el diccionari anomenat result

format per una única parella on la clau és l’identificador del recurs sobre el qual
s’executa i el valor és el nombre de dies calculats.
Tipus property
Els camps property són camps dinàmics amb drets d’accés específics, que
permeten contenir diferents valors en funció de la companyia.
Un exemple de funcionament dels camps property el podem veure en els camps

Compte a cobrar i Compte a pagar de l’apartat Comptabilitat de la fitxa dels
tercers, en el qual els valors que proposa OpenERP depenen de la companyia a la
qual pertany l’usuari que està gestionant el tercer. Per a comprovar-ho necessitem
acomplir els següents requeriments:
• Cal tenir més d’una companyia a la nostra empresa. Per exemple, suposem
que a l’empresa que hem anat utilitzant (Empresa_IOC) hi tenim creades
les companyies ESO, BAT i CF dedicades als corresponents estudis.
• Cal tenir instal·lat el mòdul oficial de comptabilitat (Accounting & Finance

– account_accountant) i tenir desplegat el pla comptable a les diverses
companyies.
F igur a 1. 16. Llista de paràmetres (camps property) en una empresa d’OpenERP
Amb els requeriments validats, naveguem fins l’apartat Settings | Configuració |

Paràmetres | Paràmetres de configuració. Allà observem una llista de paràmetres
(són els camps property definits en els mòduls actualment instal·lats). Si els
ordeneu per nom, observareu fàcilment, tal com mostra la figura 1.16, que els
paràmetres property_account_receivable i property_account_payable

es repeteixen quatre vegades, una per cadascuna de les companyies existents.
Si editem qualsevol dels vuit paràmetres observarem (figura 1.17) que el formulari
conté el camp Valor amb un contingut que podem modificar. Podem observar que
el contingut pel camp Valor és idèntic en les quatre companyies per a un mateix
paràmetre, ja que és el valor que el procés de configuració de comptabilitat assigna
(compte comptable 410000 per a proveïdors i compte comptable 430000 per a
clients), però podem modificar-lo per a la companyia que interessi.
F igu r a 1. 1 7 . Assignació de valor a un camp property
Amb aquesta possibilitat de configuració personalitzada per a cada companyia,

OpenERP proposarà, en els camps Compte a cobrar i Compte a pagar de l’apartat
Comptabilitat de la fitxa dels tercers, el valor corresponent a la companyia que
tingui assignat l’usuari que està gestionant el tercer.
A més, per cada tercer al qual, per un d’aquests camps property, s’assigni un
valor diferent del que li pertoca segons la companyia, OpenERP afegeix un nou
registre en el formulari de la figura 1.16, tot indicant a la columna Recurs el nom
de l’objecte que té un valor diferent. Els registres que tenen buida la columna
Recurs són els que contenen el valor per defecte a assignar al camp property.
Una vegada ja coneixem el funcionament dels camps property a nivell d’usuari,

ens pertoca saber com definir-los en una classe d’OpenERP i ho veurem seguint
l’exemple dels camps Compte a Cobrar i Compte a Pagar de la fitxa dels tercers.
Sembla clar que el lloc on hem de cercar aquests camps té a veure amb l’objecte
(classe) res.partner d’OpenERP. Si fem una ullada a aquesta classe, definida
dins el mòdul base d’OpenERP (fitxer res_partner.py) no hi trobarem cap
dels dos camps property indicats. Els camps que cerquem es troben dins
l’objecte res.partner definit dins el mòdul account (fitxer partner.py del
mòdul account) que és una classe derivada de la classe res.partner principal
(l’existent en el mòdul base). Vegem la part corresponent als dos camps
property de la definició d’aquesta classe derivada:
1 class res_partner(osv.osv):
2 _name = ’res.partner’
3 _inherit = ’res.partner’
4 _description = ’Partner’
5 ...
6 _columns = {
7 ...
8 ’property_account_payable’:
9 fields.property(’account.account’, type=’many2one’,
10 relation=’account.account’, string="Account Payable",
11 view_load=True, domain="[(’type’, ’=’, ’payable’)]",
12 help="This account will be used instead of the default
one as the payable account for the current partner",
required=True),
13 ’property_account_receivable’:
14 fields.property(’account.account’, type=’many2one’,
15 relation=’account.account’, string="Account Receivable",
16 view_load=True, domain="[(’type’, ’=’, ’receivable’)]",
17 help="This account will be used instead of the default
one as the receivable account for the current
partner", required=True),
18 ...
19 }
Valors per defecte

La classe Python per definir els objectes d’OpenERP incorpora l’atribut opcional
_defaults que permet la definició dels valors per defecte per un o diversos tipus
de dades simples de l’objecte d’OpenERP.
Els valors per defecte dels camps d’un objecte d’OpenERP es defineixen en un
diccionari de la forma:
1 _defaults = {
2 ’nom_del_camp1’: funció1 o valor1,
3 ’nom_del_camp2’: funció2 o valor2,
4 ...
5 }
Observem que els valors per defecte (sempre corresponents a tipus de dades
simples) poden ser valors estàtics o valors dinàmics resultants de la crida de
funcions que han d’estar declarades amb anterioritat a la definició del diccionari
_defaults.
Les funcions per ser invocades en un valor per defecte dinàmic, han de contenir
obligatòriament 4 paràmetres:
• obj: objecte osv corresponent al recurs que s’està creant.

• cr: cursor de base de dades.
• uid: ID de l’usuari que està donant d’alta el recurs.
• context: el context actual (facilitat pel client).
Els mòduls d’OpenERP estan plens d’exemples d’utilització de valors per defecte.
Així, per exemple, observem els valors per defecte de l’objecte res.users (definit
en el fitxer res_users.py dins el mòdul base) ideat per gestionar els usuaris de
l’empresa gestionada per OpenERP:
1 _defaults = {
2 ’password’ : ’’, ’context_lang’: ’en_US’,
3 ’active’ : True, ’menu_id’: _get_menu,
4 ’company_id’: _get_company, ’company_ids’: _get_companies,
5 ’groups_id’: _get_group, ’menu_tips’: False
6 }
En aquesta definició observem la coexistència de valors estàtics (password,

llenguatge, active i menu_tips) i valors dinàmics (menu_id, company_id,
company_ids i groups_id). Si observeu la definició completa de la clas-
se res.users podreu comprovar com abans de la definició del diccionari
_defaults es troba la definició de diverses funcions, entre les quals hi ha
les quatre funcions invocades des de _defaults (_get_menu, _get_company,
_get_companies i _get_group). Veureu, també, que les quatre funcions tenen
els paràmetres self, cr, uid i context.
En algunes ocasions, la definició d’un valor per defecte estàtic s’efectua amb la
crida a una funció lambda de Python sense paràmetres. La definició dels valors
per defecte estàtics a l’anterior exemple s’hagués pogut efectuar com:
1 _defaults = {
2 ’password’: lambda *a: ’’, ’context_lang’: lambda *a: ’en_US’,
3 ’active’: lambda *a: True, ’menu_id’: _get_menu,
4 ’company_id’: _get_company, ’company_ids’: _get_companies,
5 ’groups_id’: _get_group, ’menu_tips’: lambda *a: False
6 }
Per últim, per no veure’s obligats a crear funcions que només siguin invocades
en un valor _defaults, es pot utilitzar les funcions lambda de Python en el
mateix moment d’efectuar la crida, estalviant-nos la definició de la funció amb
nom. En el següent codi corresponent al diccionari _defaults de la classe
document.directory (fitxer document_directory.py del mòdul document) ob-
servem la definició de dues funcions lambda:
1 _defaults = {
2 ’company_id’: lambda s,cr,uid,c:
3 s.pool.get(’res.company’)._company_default_get(cr, uid, ’document.directory
’, context=c),
4 ’user_id’: lambda self,cr,uid,ctx: uid,
5 ’domain’: ’[]’,
6 ’type’: ’directory’,
7 ’ressource_id’: 0,
8 ’storage_id’: _get_def_storage,
9 ’resource_find_all’: True,
10 }
Exemple d’utilització de l’atribut _defaults
L’objecte (classe) school.professor del mòdul school que estem millorant, incorpora
l’atribut contract que consisteix en una selecció entre dos possibles valors. En el procés
de creació d’un nou professor podem observar que el camp contract apareix sense valor
per defecte. Volem definir que el valor per defecte d’aquest camp sigui trainee.
Així mateix, observem que l’objecte (classe) school.professor no incorpora el camp

especial active que permet ocultar els recursos (objectes) de la classe quan ja no interessi,
sense eliminar-los. Aprofitarem aquest exemple per afegir aquest camp i posar-li el valor 1
(cert) com a valor per defecte.
El codi de la classe school.professor modificada és:
1 class school_professor(osv.osv):
2 """Professors"""
3 _name = ’school.professor’
4 _columns = {
5 ’name’: fields.char(’Professor Name’, size=64,required=True),
6 ’contract’: fields.selection([(’trainee’,’Trainee’),
7 (’named’,’Named’)],’Contract’),
8 ’partner_id’: fields.many2one(’res.partner’,
9 ’Associated Partner’),
10 ’address_id’: fields.many2one(’res.partner.address’,
11 ’Private Address’),
12 ’phone’: fields.related(’address_id’,’phone’, type=’char’,
13 string=’Phone’, store=False,
14 readonly=True),
15 ’hours_available’: fields.integer(’Hours Per Week’),
16 ’course_ids’: fields.one2many(’school.course’, ’prof_id’,
17 ’Courses’),
18 ’active’: fields.boolean(’Active’),
19 }
20 _defaults = {
21 ’contract’: lambda *a: ’trainee’,
22 ’active’: lambda *a: 1,
23 }
24 school_professor()
Observem que en la definició dels valors per defecte, hem utilitzat una funció lambda de
Python, però no hagués estat necessari.
Una vegada actualitzat el mòdul school amb les noves millores, si obrim el formulari de
manteniment de professors observarem que en donar d’alta un professor, en el camp
Contract apareix per defecte el valor Trainee. En canvi, no apareix el nou camp Active,
a causa que no hem modificat encara el formulari XML, però sí que podem veure la seva
existència a la taula school_professor de la base de dades, amb valor True per tots els
professors que ja existien a la taula i també pels nous professors.
Podeu trobar la versió
millorada del mòdul
school a l’arxiu
school_03.zip dins
Restriccions l’apartat “Mòduls
Els objectes (classes) d’OpenERP poden incorporar, de forma opcional, restricci- del web.
ons d’integritat, addicionals a les que es puguin establir sobre la pròpia base de
dades. OpenERP valida aquestes restriccions en les modificacions de dades i, en
cas de violació, OpenERP mostra una pantalla d’error.
Les restriccions d’un objecte d’OpenERP es declaren a la classe Python que

defineix l’objecte amb un atribut _constraints consistent en una llista de tuples,
on cada tuple correspon a una restricció:
1 _constraints = [
2 (nomMètode,’missatgeError’,’llistaNomsCamps’)
3 (nomMètode,’missatgeError’,’llistaNomsCamps’),
4 ...
5 ]
Els tuples corresponents a una restricció venen definits per tres camps:
• nomMètode: és el nom del mètode de l’objecte utilitzat per validar la

restricció. El seu prototipus ha de tenir la forma def _nomMètode (self,
cr, uid, ids) i ha de retornar un valor booleà.
• missatgeError: és el missatge d’error que es mostrarà a l’usuari si la

comprovació falla.
• llistaNomsCamps: és la llista dels noms dels camps que s’afegeixen al

missatge d’error amb l’objectiu d’ajudar a l’usuari a entendre el motiu pel
qual ha fallat la validació de la restricció.
Els mòduls d’OpenERP incorporen validacions _constraints en nombrosos

llocs. Un cas el trobem en la validació dels comptes bancaris segons la normativa
IBAN.
Codis IBAN i BIC
El codi IBAN (International Bank Account Number ) s’utilitza per a identificar a nivell
internacional un compte bancari. Sempre comença per dos caràcters que identifiquen el
país i va seguit d’una seqüència de dígits. En el cas dels comptes bancaris espanyols,
comença per ES i va seguit de 22 dígits, dels quals, els 2 primers són dígits de control
i els altres 20 corresponen al CCC (Codi Compte Client) utilitzat des de molt de temps a
Espanya.
El codi BIC (Bank Identifier Code) serveix per identificar una entitat bancària.
A la xarxa trobareu gran
quantitat de documentació
relativa als codis IBAN i Fixem-nos en el següent fragment de codi de la classe Python res_partner_bank
BIC.
definida en el mòdul base_iban (fitxer base_iban.py):
1 _constraints = [
2 (check_iban, _construct_constraint_msg, ["iban"]),
3 (_check_bank, ’\nPlease define BIC/Swift code on bank for bank type IBAN
Account to make valid payments’, [’bic’])
4 ]
L’anterior atribut _constraints inclou dues restriccions:
• check_iban: aquest és el nom del mètode declarat a la mateixa clas-

se, que s’encarrega de validar el codi IBAN introduït per l’usuari. En
cas que sigui erroni, la restricció informa que l’error es produeix en
el camp iban i afegeix el missatge que retorna la crida al mètode
_construct_constraint_msg (mètode que construeix el missatge ja que
és força complex perquè difereix en cada país).
• _check_bank: aquest és el nom del mètode declarat a la mateixa classe que

s’encarrega de validar el codi BIC introduït per l’usuari (obligatori en cas
que l’usuari hagi indicat que està introduint un codi IBAN). En cas que sigui
erroni, la restricció informa que l’error es produeix en el camp bic i mostra
el missatge d’error que indica la restricció.
Per comprovar el funcionament d’aquestes restriccions, executeu els següents

passos:
1. Obriu el manteniment de clients i situeu-vos en un client qualsevol.
2. Editeu-lo i aneu a la pestanya Comptabilitat (cal tenir instal·lat el mòdul

de comptabilitat). Allà hi veureu una zona de línies anomenada Detalls del
banc destinada a incloure els comptes bancaris del client.
3. Procediu a donar d’alta un compte bancari amb els següents valors:
Tipus de compte de banc: Compte IBAN (del contrari no fa cap verificació)
Número de compte: ES0012341234161234567890
Propietari compte bancari: seleccioneu el client al qui esteu assignant el

compte
Codi d’identificador bancari: introduïu el text Qualsevol
4. Procediu a Desar i Tancar, fet que us portarà de nou a la fitxa del client, on
veureu el compte bancari introduït i procediu a intentar enregistrar el client.
En aquest moment, OpenERP comprova les restriccions introduïdes i, en
aquest cas, com que els codis IBAN i BIC són erronis, apareix la pantalla
d’error de la figura 1.18. Hi observem dos errors: el primer que ens informa
de l’error en validar el camp iban i ens explica com ha de ser el contingut
d’aquest camp. El segon ens informa que s’ha produït un error en validar el
camp bic.
5. Procediu a modificar el valor introduït en el camp iban amb el va-

lor ES7712341234161234567890, que té un format IBAN correcte,
tot i que gairebé segur que no existeix realment un CCC de codi
12341234161234567890. Torneu a intentar enregistrar el client. Observa-
reu que ja només apareix l’error relatiu al camp bic.
Als annexos del web

6. Per solucionar l’error del camp bic cal indicar el valor bic d’una de les que inclou el fitxer
l10n_es_partner_
entitats bancàries donades d’alta a l’empresa activa. Podeu donar d’alta les 20130328.zip
corresponent al mòdul
diverses entitats bancàries a través de l’opció Vendes | Configuració | Llibre- l10_es_partner que
potser voleu instal·lar.
ta d’adreces | Bancs o, si ho preferiu, instal·leu el mòdul l10n_es_partner
(Adaptación de partner para Estado Español) que, entre altres coses, facilita
un assistent (Vendes | Configuració | Llibreta d’adreces | Import Bank Data
Wizard) que afegeix dades de 191 bancs i caixes espanyoles a partir del
registre oficial del Banc d’Espanya. Una vegada indiqueu un codi BIC
existent a l’empresa OpenERP, podreu finalitzar l’enregistrament correcte
del client.
F igu ra 1 . 1 8 . Pantalla d’error d’OpenERP quan els codis IBAN i BIC són
erronis
2. OpenERP: la vista i el controlador
OpenERP és un programari de gestió empresarial desenvolupat sobre el framework

OpenObject de tipus RAD (Rapid Application Development) que facilita una
arquitectura MVC (model-vista-controlador) per als desenvolupaments.
Una vegada es domina el disseny del model de dades d’una aplicació desenvolu-
pada sobre OpenObject, com és el cas d’OpenERP, cal entrar en el coneixement
del disseny de la vista i del controlador.
En les aplicacions desenvolupades sobre el framework OpenObject, el concepte

vista engloba les pantalles que permeten exposar la informació a l’usuari (anome-
nades vistes o views) per a visualitzar-la i/o editar-la, i els menús, que faciliten un
accés organitzat a les vistes. En conseqüència, ens cal aprendre a dissenyar les
vistes (views) i els menús.
En el framework OpenObject el disseny del controlador s’efectua amb el llenguat-

ge Python, tot ampliant les classes Python que defineixen el model de dades, amb
la incorporació de mètodes.
Els menús i vistes dissenyats en arxius XML, en instal·lar-se en una empresa

d’OpenERP, obtenen un identificador numèric dins l’empresa i que OpenERP
utilitza per a la gestió de l’aplicació. Aquest identificador acostuma a ser diferent
a cada empresa, ja que no totes les empreses tenen els mateixos mòduls instal·lats
ni han estat instal·lats en el mateix ordre. A causa que és molt possible que en
la fase de disseny el dissenyador hagi de fer referència a menús i vistes es fa
necessari un identificador XML per a cada vista/menú que el dissenyador pugui
utilitzar. Per això, en la definició XML de menús i vistes s’inclou un identificador
(text) que ha de ser únic dins el mòdul i al qual es pot fer referència des del propi
mòdul a través del seu nom o des de qualsevol altre mòdul m a través de la sintaxi
m.identificador.
2.1 Menús
Les aplicacions desenvolupades amb el framework OpenObject contenen el model,

la vista i el controlador seguint el patró de disseny MVC. Dins la vista s’inclouen
les diverses pantalles que permeten gestionar la informació i els menús que
permeten un accés organitzat a les vistes.
Els menús d’un mòdul OpenObject es dissenyen en arxius XML i han d’estar
referenciats des de l’apartat update_xml del fitxer descriptor del mòdul __ope-
nerp__.py. Els arxius XML acostumen a incorporar les pantalles (views) i els
menús que permeten accedir a les pantalles. Els dos tipus d’elements, però,
podrien residir en fitxers XML específics (un per menús i un per views).
Com a exemple, podem analitzar el mòdul school generat per l’eina Dia, en el
qual observem la presència del fitxer anomenat school_view.xml:
1 "update_xml" : [’school_view.xml’],
Els menús d’OpenObject i les seves opcions han de tenir una declaració similar a:
1 <menuitem id="menuitem_id"
2 name="títol_del_menú"
3 action="action_id"
4 icon="nom_de_icona"
5 web_icon="nom_icona_web"
6 web_icon_hover="nom_icona_web_flotant"
7 parent="menuitem_id"
8 groups="grups_usuaris"
9 sequence="<integer>"
10 />
en la qual els valors específics de cada menú són:
• Atribut id: conté l’identificador XML del menú, únic dins el mòdul.
• Atribut name: conté el títol del menú. Aquest camp és opcional i, si no

s’indica, el menú agafarà el nom de l’acció que executi el menú.
• Atribut action: especifica l’identificador de l’acció que executa el menú

i que ha d’existir en el mòdul. Quan no s’especifica l’acció s’entén que es
tracta de l’arrel d’un menú que conté altres menús i/o opcions. El disseny
de la corresponent acció depèn del tipus d’execució associada (obrir una
finestra, executar un informe, posar en marxa un assistent...).
• Atribut icon: especifica la icona que acompanya al menú en el client GTK.

La icona per defecte és una carpeta. La llista d’icones possibles es pot
consultar en el desplegable Icona del manteniment de menús accessible a
través de Settings | Personalització | Intefície d’usuari | Elements menú.
• Atribut web_icon: especifica la icona que es mostra en el client web, a la

pàgina inicial (Home) .
• Atribut web_icon_hover: especifica la icona que es mostra en el client

web, a la pàgina inicial, en passar el ratolí pel damunt. Acostuma a ser la
versió acolorida de la icona especificada a l’atribut web_icon.
• Atribut parent: especifica l’identificador del menú pare del qual depèn. Si
no es defineix, indica que es tracta d’un menú arrel (menú principal).
• Atribut groups: especifica quin grup d’usuaris pot veure el menú. Si es

desitja introduir més d’un grup, cal separar-lo per comes (per exemple,
groups="admin,user").
• Atribut sequence: és un enter que s’utilitza per ordenar el menú dins l’arbre
de menús, de manera que a major valor, més avall apareix el menú. Aquest
valor no és obligatori i per defecte pren el valor 10. Els menús que tinguin
el mateix valor s’ordenen per moment temporal de creació.
Les icones dels atributs web_icon o web_icon_hover han de residir a la carpeta

del mòdul i el seu nom ha d’anar acompanyat del camí que indiqui la subcarpeta
(normalment images o icons) en la qual resideixen (o sense camí si no es troben
a cap subcarpeta). La versió del mòdul
school de l’arxiu
school_04.zip, que podeu
Accions en OpenObject trobar a l’apartat “Mòduls
Les accions defineixen el comportament del sistema en resposta als esdeveniments del web, incorpora dues
icones student.png i
generats per l’usuari, ja sigui en seleccionar una opció de menú, en prémer un botó, en student-hover.png pels
fer clic damunt un registre... atributs web_icon i
web_icon_hover.
Hi ha diferents tipus d’accions:
• Window: per obrir una finestra.
• Report: per imprimir un informe.
• Wizard: per iniciar un assistent vinculat a un treball o procés.
• Execute: per executar un mètode en el servidor.
• Group: per reunir un conjunt d’accions en un grup.

En el Technical Memento
d’OpenERP disponible a
doc.openerp.com/memento
Exemple de menús en el mòdul school hi trobareu el recordatori
sobre el disseny de
Els menús originals del menú school generats per l’eina Dia per a la versió 5.0 d’OpenERP menús.
no són vàlids per a la versió 6.1 d’OpenERP, de manera que ens veiem obligats a refer-los
segons les normes anteriors. Així, una possibilitat és la següent:
1 <menuitem name="Courses" id="menu_school"/>

2 <menuitem name="Calendar of Courses" id="menu_school_event"
3 action="action_school_course_event" parent="menu_school"/>
4 <menuitem name="Students" id="menu_school_student"
5 action="action_school_student" parent="menu_school"/>
6 <menuitem name="Configuration" id="menu_school_configuration"
7 parent="menu_school"/>
8 <menuitem name="Courses" id="menu_school_course"
9 action="action_school_course"
10 parent="menu_school_configuration"/>
11 <menuitem name="Professors" id="menu_school_professor"
12 action="action_school_professor"
En els elements menuitem anteriors detectem dues definicions de menús i quatre

definicions d’opcions que executen accions. Cap dels dos menús incorpora l’atribut icon i,
en conseqüència, en el client GTK la icona que els acompanya és una carpeta. El menú
principal menu_school tampoc incorpora els atributs web_icon i/o web_icon_hover i, per
tant, el mòdul Courses no va acompanyat de cap icona a la pàgina inicial del client web.
2.2 Vistes
Les vistes d’OpenERP són les pantalles que faciliten l’accés de l’usuari a la infor-
mació, tant per consultar-la com per modificar-la (altes, baixes i modificacions).
OpenObject facilita diversos tipus d’interfícies per facilitar l’accés de l’usuari a

la informació (formularis, llistes, diagrames, gràfics, calendaris, arbres i targetes
kanban) i totes elles són dinàmiques.
Les vistes d’OpenERP són dinàmiques i es construeixen en temps d’execució

a partir de descripcions XML accessibles des del client, fet que en possibilita,
fins i tot, la modificació en temps d’execució.
En cas que una vista es modifiqui en temps d’execució (des del client web
activant el mode de desenvolupament, o des del client GTK, pel menú Settings
| Personalització | Interfície d’usuari | Vistes), simplement cal tancar-la i reobrir-
la per observar els canvis.
La descripció XML per les vistes associades a un objecte (classe) d’OpenERP,

resideix en fitxers XML dins el mòdul corresponent a l’objecte. En cas de
modificació en temps d’execució, el fitxer XML no es modifica i això cal tenir-
ho molt present, ja que qualsevol procés d’actualització del mòdul provocarà la
pèrdua dels canvis efectuats.
Per evitar la pèrdua de les modificacions efectuades a les vistes corresponents

a mòduls susceptibles de ser actualitzats periòdicament (mòduls oficials i extres
de la comunitat), el camí és crear un nou mòdul i definir-hi la nova vista com a
L’herència de vistes es herència de la vista a modificar, tot introduint els canvis en la vista heretada.
troba a l’apartat
“OpenERP:
desenvolupament La descripció de les vistes ha de residir en un fitxer XML que ha d’estar referenciat
avançat”.
des de l’apartat update_xml del fitxer descriptor del mòdul __openerp__.py. Així,
en el mòdul school hi observem la presència del fitxer anomenat school_view.xml
i en el fitxer __openerp__.py hi trobem la línia:
1 "update_xml" : [’school_view.xml’],
vigent del mòdul school a
l’arxiu school_04.zip dins
l’apartat “Mòduls El nom del fitxer XML en el qual resideixen les vistes pot ser qualsevol, però és
del web. altament aconsellable utilitzar alguna combinació en la qual aparegui el nom del
mòdul i quelcom que indiqui el seu contingut (com per exemple el mot view).
La declaració d’un vista ha de ser similar a:
1 <record model="ir.ui.view" id="view_id">

2 <field name="name">view.name</field>
3 <field name="model">object_name</field>
4 <field name="type">xxx</field>
5 <!−Valors possibles: tree,form,calendar,search,graph,gantt,kanban−−>
6 <field name="priority" eval="16"/>
7 <field name="arch" type="xml">
8 <!−− view content: <form>, <tree>, <graph>, ... −−>
9 </field>
10 </record>
en el qual els valors específics de cada vista són:
• Element record que conté l’atribut model amb valor ir.ui.view obliga-
tori per a les vistes, i l’atribut id amb l’identificador XML de la vista dins
el mòdul.
• Element field name="name" amb el nom de la vista.

• Element field name="model" amb el nom de l’objecte (classe) d’Ope-

nERP sobre el qual es defineix la vista.
• Element field name="type" amb el tipus de la vista, en el qual els valors

possibles actuals són: tree, form, calendar, search, graph, gantt i
kanban.
• Element field name="priority" amb la prioritat de la vista. Com més

petita, més prioritat. Per defecte: 16.
• Element field name="arch" type="xml" amb l’arquitectura o estructu-

ra de la vista que es defineix mitjançant diverses etiquetes XML. Aquesta
estructura és diferent segons el tipus de vista (tree, form, calendar,
search, graph, gantt, kanban).
Així doncs, cal endinsar-nos en l’estructura dels diversos tipus de vista i en els
mecanismes (accions) que possibiliten a l’usuari la seva execució. En el Technical Memento
hi trobareu el recordatori
sobre el disseny de vistes
i accions.
2.2.1 Accions window
Una vista d’OpenObject entra en execució a partir d’un esdeveniment d’usuari

(seleccionar una opció de menú, prémer un botó...) que està vinculat a una acció
window, responsable de la posada en marxa de la vista.
L’element field name="type" de la declaració d’una vista obliga a definir la

vista amb un dels tipus següents: tree, form, calendar, search, graph, gantt,
kanban. Cal tenir en compte que sota el tipus tree s’aixopluguen dos tipus
diferents: llista jerarquitzada (normalment anomenada arbre -tree-) i llista no
jerarquitzada (normalment anomenada llista -list-). El fet d’utilitzar el mot tree
per fer referència a dos tipus
de vista provoca maldecaps
De la mateixa manera que els menús i les vistes, les accions (no només les window) que OpenObject hagués
pogut evitar.
es declaren en arxius XML que han d’estar referenciats des del fitxer descriptor
del mòdul. A causa que les vistes es posen en marxa a través d’accions i que hi ha
menús que porten associades aquestes accions, és molt comú (però no obligatori)
introduir en el fitxer XML les declaracions en el següent ordre:
• Vistes vinculades a un objecte (acostuma a haver-n’hi diverses).
• Accions que executen vistes (pot ser única i que accioni diverses vistes).
• Menús per facilitar a l’usuari l’execució d’accions.
Exemple de vistes, accions i menús relacionats
Fixem-nos en els següents fragments de vistes, accions i menús, en el mòdul school

(versió school_04) corresponents a l’objecte professor:
1 <record model="ir.ui.view" id="view_school_professor_form">

2 <field name="name">school.professor.form</field>
3 <field name="model">school.professor</field>
4 <field name="type">form</field>

6 ...
7
8 <record model="ir.ui.view" id="view_school_professor_tree">
9 <field name="name">school.professor.tree</field>
11 <field name="type">tree</field>
13 ...
14
15 <record model="ir.actions.act_window"
16 id="action_school_professor">
17 <field name="name">Professors</field>
18 <field name="res_model">school.professor</field>
19 <field name="view_type">form</field>
20 <field name="view_mode">tree,form</field>
21 </record>
22
23 <menuitem name="Professors"
24 id="menu_school_professor" action="action_school_professor"
Hi observem:
• Dues vistes: view_school_professor_form (de tipus form) i view_school_professor_tree

(de tipus tree).
• Una acció: action_school_professor, que no està associada a cap de les dues vistes.
Quina s’executa, doncs, en activar l’acció?
• Un menú: menu_school_professor, associat a l’acció anterior.
En executar, des d’OpenERP, l’opció de menú Professors, observem com apareixen els
professors en format llista (tree) i que la vista formulari (form) també es pot seleccionar.
Els elements field name="view_type" i field name="view_mode" defineixen, quan no

s’explicita la vista a executar (com és el cas), el comportament d’OpenObject per escollir la
vista.
L’exemple anterior serveix per il·lustrar que en OpenObject hi ha certs comporta-

ments per defecte que s’activen quan el programador no els ha explicitat, com és
el cas de l’elecció de la vista a executar quan el programador no la indica.
Abans de presentar com és la declaració d’una acció window és molt convenient

entendre el comportament d’OpenObject en l’elecció i visualització de les possi-
bles vistes sobre un objecte.
OpenObject categoritza totes les vistes (tree, form, calendar, search, graph,
gantt i kanban) en dos grans grups:
• tree per les vistes jeràrquiques, que permeten la visualització de dos tipus
de vistes:
– tree: visualització arbre

– form: visualització formulari
• form per les vistes no jeràrquiques, que permeten la visualització de

diversos tipus de vistes:
– tree: visualització llista

– form: visualització formulari

– calendar: visualització calendari
– graph: visualització gràfic
– gantt: visualització diagrama de gantt
– search: visualització d’una zona de filtres
– kanban: visualització dels recursos com a targetes agrupades sota un
criteri, que poden ser editables i/o arrossegables
En la definició d’una acció window s’ha d’indicar si correspon a una vista

jeràrquica (categoria tree) o una vista no jeràrquica (categoria form) i, una
vegada definida la categoria, cal indicar –en l’ordre que interessi– els tipus de
vista (adequats a la categoria) que permetrà visualitzar. Això s’aconsegueix amb
dos elements que formen part de la definició XML d’una acció window:
• Element field name="view_type" amb una de les dues categories possi-

bles: form o tree.
• Element field name="view_mode" amb una seqüència ordenada dels

tipus de vista que facilita l’acció.
Els valors de view_mode, separats per comes, han de ser coherents amb el valor de
view_type i, a més, el mòdul ha d’incorporar alguna vista per cadascun dels tipus
indicats a la seqüència de view_mode. En cas que per algun tipus de vista dels
indicats a view_mode, hi hagi diverses vistes definides en el mòdul, OpenObject
escollirà la vista més prioritària (element priority de la definició de les vistes).
Exemple de ”view_type” i ”view_mode” en la definició d’accions window
En el mòdul school (versió school_04) observem el següent fragment d’acció window:
2 id="action_school_professor">
3 <field name="name">Professors</field>
4 <field name="res_model">school.professor</field>
6 <field name="view_mode">tree,form</field>
7 </record>
En aquest cas, a causa que view_type té el valor form, l’element view_mode podria
contenir, en principi, qualsevol seqüència ordenada dels valors tree, form, calendar,
search, graph, gantt i kanban. Fixem-nos que la seqüència és "tree,form" i, en
conseqüència, en executar l’acció (manteniment de professors), les dues vistes possibles
són llista i formulari i el manteniment s’obre en vista llista. Si el contingut de view_mode
hagués estat "form, tree" les vistes possibles haguessin estat les mateixes, però el
manteniment s’obriria en mode formulari buit. Per tal que tot funcioni, el mòdul facilita
per a l’objecte school.professor, com a mínim, una vista de tipus form i una vista de
tipus tree no jeràrquica:
• view_school_professor_form per a la vista form
• view_school_professor_tree per a la vista tree no jeràrquica
En el mòdul school (versió school_04) observem el següent fragment d’acció window:

2 id="action_school_course">
3 <field name="name">Courses</field>
4 <field name="res_model">school.course</field>
6 <field name="view_mode">tree,form,calendar</field>
7 </record>
Aquest és un altre cas en el qual view_type té el valor form, però, en canvi, l’element
view_mode conté la seqüència "tree,form,calendar" i, en conseqüència, en executar
l’acció (manteniment de cursos), tenim tres vistes possibles (llista, formulari i calendari) i
el manteniment s’obre en vista llista. Ja que l’acció indica tres vistes possibles, el mòdul
hauria de contenir, com a mínim, una vista de cada tipus, i en aquest cas, l’eina Dia, que
ha generat l’element view_mode amb els tres tipus de vista, només facilita dues vistes:
• view_school_course_form per a la vista form
• view_school_course_tree per a la vista tree no jeràrquica
Dia ha incorporat el tipus de vista calendar a view_mode perquè l’objecte school.course

té un camp date i, en conseqüència, aquest objecte és susceptible de tenir una vista
calendar. Però Dia no ha definit cap vista calendar. En procedir a l’execució des d’un
client (web o GTK), OpenObject intenta generar una vista calendar automàtica en el mateix
instant, però no pot perquè l’objecte school.course no té atributs adequats i mostra l’error
de la figura 2.1.
F ig u ra 2. 1 . Pantalla d’OpenERP en
intentar mostrar una vista Calendar errònia
Dia també ha generat l’acció window action_school_course_event en el mòdul school

(versió school_04) amb valor "tree,form,calendar" per a l’element view_mode sense
proporcionar cap vista de tipus calendar, però en aquest cas OpenObject pot proporcionar
una vista calendar per defecte a partir dels dos camps date existents (date i date_end).
El funcionament, però, no és el desitjable:
• En el client GTK, l’interval de dies d’un recurs school.course.event es visualitza sempre en

color negre i no hi ha cap text que identifiqui el recurs.
• En el client web, l’interval de dies d’un recurs school.course.event només és visible en

passar el ratolí per damunt els dies afectats.
Caldrà, doncs, dissenyar vistes calendar per aconseguir el funcionament desitjat o eliminar
el valor calendar de l’element view_mode.
La declaració d’un acció window ha de ser similar a:
1 <record model="ir.actions.act_window" id="action_id">

2 <field name="name">action.name</field>
3 <field name="view_type">form|tree</field>
4 <field name="view_mode">...</field>
5 <!−− combinació ordenada dels tipus de vista
6 possible, coherent amb el contingut de
7 l’element view_type −−>
8 <field name="view_id" ref="nomVista"/>
9 <field name="search_view_id" ref="nomVistaDeCerca"/>
10 <field name="domain">
11 ["list of 3−tuples (max 250 characters)"]
12 </field>
13 <field name="context">
14 {"context dictionary (max 250 characters)"}
15 </field>
16 <field name="res_model">Open.object</field>
17 <field name="target">new</field>
18 </record>
en la qual els valors específics per a cada acció són:
• Element record que conté l’atribut model amb valor

ir.actions.act_window obligatori per a les accions window i l’atribut
id amb l’identificador XML de l’acció dins el mòdul.
• Element field name="name" amb el nom de l’acció. És obligatori. Els

menús sense name que invoquin l’acció, prenen el name de l’acció com a
name propi.
• Elements view_type i view_mode, estudiats prèviament.
• Element field name="view_id" amb l’atribut ref que ha de contenir el

nom de la vista per mostrar quan s’activa l’acció. En cas que aquest camp
no estigui definit, OpenObject decideix en funció del contingut de l’element
view_mode.
• Element field name="search_view_id" amb l’atribut ref que ha de

contenir el nom de la vista de cerca (capçalera de les pantalles que mostren
una llista de registres, per facilitar-ne el filtrat) per mostrar quan s’activa
l’acció.
• Element res_model amb el nom de l’objecte sobre el qual opera l’acció.
• Element domain amb una llista Python de condicions utilitzada per refinar
els resultats d’una selecció i, en conseqüència, mostrar menys recursos a la
vista. Les condicions de la llista s’enllacen amb una clàusula AND i són
tuples Python de tres valors (’camp’,’condició’,’valor’).
• Element context amb un diccionari contextual que s’utilitzarà a la vista

que s’obri en executar l’acció. Els diccionaris contextuals es declaren com
un diccionari Python. Aquests diccionaris contenen informació de context
a utilitzar, com per exemple l’idioma, la moneda, la tarifa, el magatzem...
• Element target per indicar on s’ha d’obrir la finestra. Valors possibles:

new (en una nova finestra), current (substituint la finestra actual) i inline
(dins la finestra actual).
2.2.2 Vistes form
La vista formulari per a un objecte d’OpenObject consisteix en la correcta

distribució en la pantalla dels camps de l’objecte amb l’objectiu de facilitar-ne
la visualització i/o l’edició d’un recurs.
Les vistes formulari es distingeixen perquè en la seva declaració incorporen:

i l’element arrel de l’XML que defineix l’arquitectura de la vista és form.
Els camps en una vista formulari d’OpenObject sempre estan distribuïts en la

pantalla segons les següents normes:
• Per defecte cada camp va precedit d’una etiqueta que és el seu nom.
• Els camps se situen a la pantalla d’esquerra a dreta i de dalt a baix, segons

l’ordre en què estan declarats en el fitxer XML que descriu la vista.
• Cada pantalla es troba dividida en 4 columnes, cadascuna de les quals

pot contenir una etiqueta o un camp. Ja que cada camp és precedit (per
defecte) per una etiqueta amb el seu nom hi haurà dos camps amb les seves
respectives etiquetes a cada línia de la pantalla.
Com a exemple, considerem el formulari de manteniment de professors del mòdul

school (versió school_04) de la figura 2.2, generat per l’eina Dia. Observem-hi
que:
• Les zones 1 i 2 corresponen a les 4 columnes en les quals es troba dividida

la pantalla.
• Les zones 1 contenen les etiquetes dels camps ubicats a les zones 2.
F igu r a 2. 2 . Exemple de distribució dels camps en un formulari d’OpenERP

OpenObject facilita opcions d’ubicació més avançades. Així, per exemple, la

zona 3 de la figura 2.2 correspon a un camp one2many que ocupa les 4 darreres
columnes de la pantalla (1 per l’etiqueta Courses i les altres 3 per al contingut
del camp). A més, el camp one2many conté un form de tipus llista que visualitza
8 columnes. És molt possible que interessi que el contingut del camp one2many
ocupi les 4 columnes de la pantalla i que l’etiqueta Courses passi a substituir el
nom de la classe school.course. OpenObject ens facilita opcions avançades de
visualització per aconseguir-ho.
OpenObject permet:
• Que un camp pugui ocupar més d’una columna, tot utilitzant l’atribut
colspan.
• Agafar un grup de columnes i dividir-les en les columnes que es desitgi, tot

utilitzant l’etiqueta group i els atributs colspan i col.
• Distribuir els camps d’un objecte en diverses pestanyes, tot utilitzant les
etiquetes notebook i page.
El contingut del fitxer school_view.xml corresponent al formulari de la figura 2.2

(manteniment de professors) és:
1 <record model="ir.ui.view" id="view_school_professor_form">

2 <field name="name">school.professor.form</field>
6 <form string="school.professor">
7 <field name="name" select="1"/>
8 <field name="contract" select="2"/>
9 <field name="partner_id" select="0"/>
10 <field name="address_id" select="0"/>
11 <field name="phone" select="0"/>
12 <field name="hours_available" select="0"/>
13 <field name="course_ids" colspan="4" select="0"/>
14 </form>
15 </field>
16 </record>
En aquest cas, detectar dins el fitxer school_view.xml el registre corresponent a la

vista no ha estat difícil, però en altres casos en els quals hi ha moltes vistes pot ser
més dificultós. En canvi, des del client web, tenint obert el formulari i el mode de
desenvolupament activat, podem demanar d’editar la vista, obtenint el formulari
de la figura 2.3, en la qual observem el nom de la vista i, a més, podem modificar-
la i enregistrar els canvis en el servidor OpenERP. Recordem que els canvis no
queden enregistrats en el fitxer XML del mòdul.
F igu r a 2. 3 . Edició d’una vista d’OpenERP des del client web
Fixem-nos que el contingut XML de l’element arch no és altre que el conjunt de

camps a visualitzar, de l’objecte (classe) d’OpenERP en el qual es basa la vista.
Recordem la definició de l’objecte school.professor (versió school_04):
1 class school_professor(osv.osv):
2 _name = ’school.professor’
3 _columns = {
4 ’name’: fields.char(...),
5 ’contract’: fields.selection(...),
6 ’partner_id’: fields.many2one(...),
7 ’address_id’: fields.many2one(...),
8 ’phone’: fields.related(...),
9 ’hours_available’: fields.integer(...),
10 ’course_ids’: fields.one2many(...),
11 ’active’: fields.boolean(’Active’),
12 }
13 ...
La definició de la classe Python school_professor incorpora el camp active

que no apareix a la vista school.professor.form. Això és a causa que la vista
school.professor.form que estem analitzant va ser generada per l’eina Dia i el
camp active el vam incorporar posteriorment en el codi Python sense modificar
la corresponent vista.
Suposem que volem situar el camp active, que correspon a una casella de
verificació, a la 4a fila del formulari. Simplement l’haurem de situar en 7è lloc dins
l’XML de l’element arch, entre els camps hours_available i course_ids. Si
efectuem la modificació en el fitxer school_view.xml caldrà actualitzar el mòdul;
en canvi, si efectuem la modificació des dels clients web o GTK només cal
recarregar el formulari. Sigui quin sigui el camí, observarem el camp active
amb etiqueta Active a la 4a línia de la pantalla.
En el formulari school.professor.form anterior també podem observar com

el camp one2many de nom course_ids va acompanyat de l’atribut colspan=4
que indica que el camp (conjuntament amb la seva etiqueta Courses) ha d’ocupar
les 4 columnes de la pantalla.
Dins l’estructura del formulari (contingut de l’element field name="arch") hi

pot haver diversos tipus d’elements i aquests elements poden tenir diversos atributs.
La taula 2.1 mostra els atributs comuns als diversos tipus d’elements possibles i la
taula 2.2 mostra els diversos tipus d’elements possibles acompanyats dels atributs
específics de cada tipus d’element.
Taul a 2. 1. Relació d’atributs comuns pels elements de la definició d’una vista form
Atribut Utilització
string Etiqueta de l’element que substitueix l’etiqueta

definida a la classe.
També s’utilitza en els processos de recerca.
nolabel Permet amagar (valor="1") l’etiqueta del camp.
colspan Permet indicar el nombre de columnes que ha de

tenir el camp.
rowspan Permet indicar el nombre de files que ha de tenir el

camp.
col Permet indicar el nombre de columnes en què es

divideix l’espai assignat al camp.
invisible Permet ocultar (valor="1") el camp i la seva etiqueta.
eval Cadena avaluada com a codi Python per obtenir el

valor del camp.
attrs Permet indicar sota quines condicions dinàmiques,

basades en els valors d’altres camps del formulari,
l’element ha de ser readonly i/o invisible i/o
required. Ha de seguir el format:
{’atribut’:[(’nomCamp’,’operador’,’valor’),
(’nomCamp’,’operador’,’valor’)...],...}
on atribut ha de ser readonly o invisible o
required.
Exemples d’utilització de l’atribut attrs en la ubicació dels camps en vistes
En els mòduls d’OpenERP es pot veure la utilització de l’atribut attrs en múltiples

vistes. Per exemple, en la vista Leave Request del mòdul hr_holidays (fitxer
hr_holidays_view.xml):
1 <field name="name"
2 attrs="{’readonly’:[(’state’,’!=’,’draft’),
3 (’state’,’!=’,’confirm’)]}"/>
El camp name serà de només lectura quan el camp state no tingui els valors draft ni
confirm.
1 <field name="category_id"
2 attrs="{’required’:[(’holiday_type’,’=’,’category’)],
3 ’readonly’:[(’state’,’!=’,’draft’)]}"/>
El camp category_id serà obligatori quan el camp holiday_type valgui category i de

només lectura quan el camp state no valgui draft.
Taul a 2. 2. Relació dels elements possibles en la definició d’una vista form
Element Utilització
field Camp per visualitzar, d’entre les columnes definides

a l’objecte (classe) OpenERP en la qual es basa la
vista.
Cada camp porta un giny (widget) associat segons el
tipus de dada del camp. Així, si el camp és de tipus
booleà, el giny és una casella de verificació; si el
camp és de tipus date el giny és un camp formatat
per a data acompanyat d’un calendari per poder
seleccionar la data amb comoditat, com mostra la
figura 2.4.
La taula 2.3 mostra els atributs específics d’aquest
element.
button Giny (widget) en forma de botó per ser premut i que

està associat a determinades accions.
La taula 2.4 mostra els atributs específics d’aquest
element.
separator Línia de separació horitzontal per estructurar vistes,

amb etiqueta opcional.
newline Permet afegir espai en blanc per completar la línia

actual de la vista i saltar a la següent.
label Títol de text lliure en el formulari.
group Permet organitzar els camps en grups amb etiquetes

opcionals. Aporta un requadre al voltant del grup.
notebook Un element notebook és un contenidor de pestanyes,

page definides cadascuna per un element page.
Els atributs específics d’aquest element són:
* name: etiqueta per la pestanya
* position: posició de la pestanya dins el notebook,
amb valors possibles: inside, top, bottom, left i
right.
Taul a 2. 3. Relació d’atributs específics per l’element field en la definició d’un form
Atribut Significat
select 1 per mostrar el camp en cerques normals i 2 per

mostrar el camp només en cerques avançades.
A partir de la versió 6 d’OpenERP, les cerques
avançades han deixat d’existir i, en canvi, els clients
faciliten l’opció de filtres avançats en els quals es pot
escollir qualsevol dels camps del model. Per tant, el
valor 2 és obsolet a partir de la versió 6 d’OpenERP.
La utilització d’aquest atribut queda obsoleta en el
moment en què la versió 6 d’OpenERP facilita les
vistes search.
required Substitueix l’atribut required definit en el model.

1 per tal que el camp sigui obligatori.
readonly Substitueix l’atribut readonly definit en el model.

1 per tal que el camp sigui de només lectura.
default_focus Valor 1 per indicar que aquest camp ha de tenir el

focus en obrir el formulari. Només hi pot haver un
element amb aquest atribut a 1.
password True per ocultar els caràcters que s’introdueixen en

el camp.
context Codi Python per definir un diccionari contextual.
domain Codi Python per definir una llista de tuples amb

condicions per restringir valors, en camps relacionals.
Tau l a 2.3 (continuació)
Atribut Significat
on_change Mètode Python que s’executa en canviar el valor del

camp. S’utilitza per calcular automàticament el valor
d’altres camps quan el camp actual canvia.
groups Llista Python d’identificadors de grups d’usuaris

autoritzats a visualitzar el camp.
widget Giny alternatiu al proporcionat de forma automàtica

segons el tipus del camp. Valors possibles:
* date (figura 2.4)
* float_time (figura 2.5)
* datetime (figura 2.6)
* selection (figura 2.7)
* number (figura 2.8)
* many2one_list (figura 2.9)
* one2many_list (figura 2.10)
* many2many (figura 2.11)
* url (figura 2.12)
* email (figura 2.13)
* image (figura 2.14)
* reference (figura 2.15)
* text_wiki
* text_html
* progressbar (figura 2.16)
Taul a 2. 4. Relació d’atributs específics per l’element button en la definició d’un form
Atribut Significat
type Tipus de botó. Valors possibles:

* workflow (flux de treball, valor per defecte): envia el
senyal (indicat a l’atribut name) al flux de treball del
mòdul.
* object: crida la funció o mètode indicada a l’atribut
name.
* action: executa l’acció indicada a l’atribut name.
name Segons el valor de l’atribut type:

* Senyal del flux de treball
* Nom de la funció o mètode a executar
* Nom de l’acció a executar
special Únicament és operatiu en una finestra emergent

(pop-up) i en cas d’utilitzar-lo en una finestra no
emergent, no és operatiu.
Només té un possible valor: cancel.
És incompatible amb l’atribut type.
confirm Text de missatge de confirmació per quan es prem el

botó.
states Llista d’estats, separats per comes, en els quals el

botó es mostra. Si aquest atribut no apareix, el botó
és sempre visible.
icon Nom d’icona. Per defecte, el botó és textual.

Es pot utilitzar qualsevol de les icones existents a la
subcarpeta web/static/src/img/icons de la
carpeta addons on es troben els mòduls o qualsevol
altra icona indicant la seva ubicació (normalment en
una subcarpeta images o icons dins el mòdul).
default_focus Valor a 1 per indicar que aquest botó ha de tenir el

focus en obrir el formulari. Només hi pot haver un
element amb aquest atribut a 1.
F ig ura 2 .4 . Giny date
F ig ura 2 .5 . Giny float_time
F ig ur a 2 .6 . Giny datetime
F ig ura 2. 7 . Giny selection
Fig ura 2 . 8 . Giny number en el client GTK
F igu ra 2 .9 . Giny many2one_list

Figur a 2. 10. Giny one2many_list
Figur a 2 . 11 . Giny many2many
F igur a 2. 12 . Giny url
Figu r a 2. 1 3 . Giny email
Fig ur a 2 . 1 4. Giny image
Fi gu ra 2 .15 . Giny reference
Figu r a 2. 1 6 . Giny progressbar

Millora de vistes form en el mòdul school
Ens proposem millorar les vistes form del mòdul school vigent (versió school_04).
En totes les vistes canviem el contingut de l’atribut string de l’element arrel de

l’arquitectura de la vista, generat de forma automàtica per l’eina Dia, amb un nom entenedor
–en llengua anglesa–, ja que allà on OpenERP visualitzi la vista i no s’expliciti un títol,
OpenERP utilitzarà el contingut de l’atribut string.
En tots els camps de les vistes form eliminem –per obsolets– els atributs select amb valor
0 o 2. Hi mantenim els atributs select="1" mentre no incorporem cap vista search.
En el formulari de manteniment dels professors:
• Fem visible el camp active en la tercera fila del formulari, a la dreta del camp
hours_avalilable, de manera que els dos camps (active i hours_available) ocupin les
columnes 3 i 4 del formulari.
• Fem desaparèixer l’etiqueta Courses del sotsformulari i afegim un separador, amb etiqueta
Courses, just abans del sotsformulari.
En el formulari de manteniment dels estudiants, fem desaparèixer l’etiqueta Subscriptions

to courses del sotsformulari i afegim un separador, amb etiqueta Subscriptions to courses,
just abans del sotsformulari.
En el formulari de manteniment dels cursos:
• Millorem el camp website de manera que es pugui navegar fins l’adreça que conté.

school a l’arxiu • El sotsformulari amb etiqueta Students el situem en una pestanya Students i afegim una altra
school_05.zip dins pestanya Calendar amb accés a les diverses edicions del curs (cal modificar el model de
OpenERP” dels annexos dades de l’objecte school.course afegint el camp event_ids).
del web.
2.2.3 Vistes tree (arbre/llista)
Les vistes arbre/llista per a un objecte d’OpenObject consisteixen en la distribució

de la pantalla en línies amb l’objectiu de facilitar la visualització i/o l’edició d’un
conjunt de recursos de l’objecte. La majoria de les vistes arbre/llista són de només
visualització, però OpenObject permet fer-les editables.
La vista arbre mostra els recursos de l’objecte seguint una estructura jeràrquica,
mentre que la vista llista mostra els recursos en seqüència, sense cap jerarquia.
En OpenERP tenim una gran quantitat de vista llista com, per exemple, en accedir
a l’accés directe Clients, en el qual se’ns presenta els clients en vista llista.
OpenERP també inclou exemples de vista arbre; un exemple el trobem en accedir a
l’opció de menú Magatzem | Productes | Productes per categoria, com ens mostra
la figura 2.17.
Figur a 2.1 7. Exemple de vista en arbre, amb desplegable per escollir el recurs de primer nivell de la
jerarquia
La vista arbre de la figura 2.17 presenta un desplegable que ens permet escollir
entre les categories de primer nivell (Tots els productes, Productes negociables,
Altres productes). La figura 2.17 mostra la jerarquia de categories per sota de Tots
els productes. En executar l’opció de menú, per a Tots els productes únicament
se’ns presenten les dues categories filles: Privat i Vendible. La categoria Vendible,
com que té categories filles, va precedida d’un símbol en forma de triangle amb
vèrtex cap a la dreta que, en prémer-lo, desplega les categories filles: Complements
d’ordinador i Serveis. I així successivament. L’elecció de qualsevol de les Símbol utilitzat en les vistes arbre
categories, situant-nos al damunt, provoca l’aparició de la llista dels productes

de la categoria seleccionada.
Les vistes arbre/llista es distingeixen perquè en la seva declaració incorporen:
i l’element arrel de l’XML que defineix l’arquitectura de la vista és tree.
La diferència entre les vistes arbre i vistes llista en la declaració radica en

l’existència, en les vistes arbre, del següent element per indicar el camp one2many
que determina la jerarquia:
1 <field name="field_parent">camp_one2many</field>
Les vistes arbre/llista són més simples que les vistes formulari i tenen menys
opcions. De manera similar a les vistes formulari, incorporen en la seva estructura
elements field. La taula 2.5 recull els atributs que poden acompanyar l’element
arrel tree.
Taul a 2. 5. Relació d’atributs per l’element ”tree” en la definició d’un ”tree”
Atribut Significat
colors Llistes de colors definides en un diccionari Python

per tal que les línies es puguin acolorir segons
diferents condicions.
editable En cas d’estar definit, els valors possibles són top i

bottom i permeten editar els registres directament a
la llista, sense necessitat de passar a la vista
formulari. Si el valor és top, els nous registres
s’afegeixen al capdamunt de la llista i si el valor és
bottom, els nous registres s’afegeixen al final.
toolbar Només per a les vistes arbre.

Valor a True per mostrar el nivell superior de la
jerarquia d’objectes amb una barra d’eines lateral.
Exemple d’anàlisi del codi de la vista arbre Productes per categoria
El codi de la vista arbre Productes per categoria (figura 2.17) és:
1 <record id="product_category_tree_view" model="ir.ui.view">

2 <field name="name">product.category.tree</field>
3 <field name="model">product.category</field>
5 <field name="field_parent">child_id</field>
7 <tree toolbar="True" string="Product Categories">
8 <field name="name"/>
9 </tree>
10 </field>
11 </record>
Veiem que l’element field_parent informa que l’arbre es munta a partir de la

jerarquia indicada pel camp child_id. Fixem-nos com és la definició de la classe
product.category:
1 class product_category(osv.osv):
2 ...
3 _name = "product.category"
4 _description = "Product Category"
5 _columns = {
6 ...
7 ’parent_id’:
8 fields.many2one(’product.category’, ’Parent Category’,
9 select=True, ondelete=’cascade’),
10 ’child_id’:
11 fields.one2many(’product.category’, ’parent_id’,
12 string=’Child Categories’),
13 ...
Si modifiquem la vista product_category_tree_view eliminant l’atribut toolbar, cosa que

podem aconseguir ràpidament des del client web, i tornem a demanar l’opció Productes per
categoria, veurem que el desplegable per escollir el recurs de primer nivell de la jerarquia
ha desaparegut (figura 2.18) i directament ens facilita la llista de tots els recursos de primer
nivell.
Figu ra 2. 18. Exemple de vista arbre sense l’atribut ”toolbar”
Exemple d’anàlisi de la vista llista Productes
Quan accedim a Productes (ja sigui amb la drecera o des de l’opció de menú), apareixen
els productes en vista llista. La majoria dels productes apareixen de color negre, però n’hi
ha alguns en vermell i alguns en blau. Això és a causa que s’està utilitzant l’atribut colors
en la definició de l’element tree.
El codi de la vista llista és:
1 <record id="product_product_tree_view"
2 model="ir.ui.view">
3 <field name="name">product.product.tree</field>
4 <field name="model">product.product</field>
6 <field eval="7" name="priority"/>
8 <tree
9 colors="red:virtual_available<0;
10 blue:virtual_available>=0 and
11 state in (’draft’,’end’,’obsolete’);
12 black:virtual_available>=0 and
13 state not in (’draft’,’end’,’obsolete’)"
14 string="Products">
15 <field name="default_code"/>
17 <field name="categ_id" invisible="1"/>
18 <field name="variants"
19 groups="product.group_product_variant"/>
20 <field name="uom_id" string="UoM"/>
21 <field name="type"/>
22 <field name="qty_available"/>
23 <field name="virtual_available"/>
24 <field name="lst_price"/>
25 <field name="price"
26 invisible="not context.get(’pricelist’,False)"/>
27 <field name="standard_price" groups="base.group_extended"/>
28 <field name="state" groups="base.group_extended"/>
29 <field name="company_id"
30 groups="base.group_multi_company"
31 invisible="1"/>
32 </tree>
33 </field>
34 </record>
Observem-hi el contingut de l’atribut colors a l’element tree: es defineix el color que ha de

mostrar el registre en funció dels valors dels camps virtual_available i state.
Si voleu que la llista sigui editable només heu d’afegir l’atribut editable a l’element tree,
amb el valor top o bottom segons vulgueu que els nous registres s’afegeixin per dalt o per
baix. Podeu comprovar-ho, de manera ràpida, modificant la vista des del client web.
Els ginys one2many i many2many emprats en les vistes form mostren la informació
de la vista llista associada als objectes referenciats pels camps one2many i
many2many.
Relació entre els ginys one2many/many2many i les vistes tree
Situem-nos en el mòdul school vigent (school_05) i considerem la vista llista del

calendari de cursos (school.course.event.tree). Aquesta vista mostra quatre columnes:
course_id, date, date_end i name i té l’atribut string="school.course.event".
Fixem-nos en la pestanya Calendar del formulari manteniment de Courses. En aquesta

pestanya s’hi visualitza el camp event_ids que és un camp one2many que referencia la
classe school.course.event. Observem que mostra les quatre columnes i l’etiqueta poc
adequada de la vista school.course.event.tree.
Si modifiquem la vista llista school.course.event.tree (columnes, etiqueta...) els canvis

repercutiran en la visualització de la pestanya Calendar del manteniment de Courses.
Però, i si volem mantenir la vista llista sota una determinada estructura i, en canvi, ens
interessa que en un camp one2many o many2many la visualització sigui diferent?
L’element tree també s’utilitza per modificar l’estructura dels ginys one2many i
many2many en una vista form. Per aconseguir-ho, a l’element field corresponent
al camp one2many o many2many se li ha d’afegir un element fill tree, que haurà
de contenir els elements fields que es vulguin visualitzar en el giny. És a dir,
mentre que el funcionament automàtic dels ginys one2many i many2many mostra
la vista llista associada a l’objecte referit en el camp one2many i many2many, amb
l’element tree podem alterar-la i mostrar aquells camps que interessi i amb les
característiques adequades (ordre, color...).
Cal tenir en compte, també, que si en un element tree explicita una columna
one2many o many2many, OpenERP hi visualitzarà el nombre de recursos (regis-
tres) que en aquell moment estan referenciats.
Exemple de millora de vistes tree en el mòdul school
Ens proposem millorar les vistes tree del mòdul school vigent (versió school_05).
En la vista llista dels professors fem que els professors amb contract ’named’ es
visualitzin de color blau i els professors amb contract ’trainee’ es visualitzin de color
verd.
En el formulari de manteniment dels professors, modifiquem les columnes que es

visualitzen a l’apartat Courses de manera que desaparegui el nom del professor, ja que és
redundant amb la informació de la capçalera del formulari i la columna Note. Ens interessa,
però, que per cada curs aparegui el nombre d’estudiants i el nombre d’edicions.
En el formulari de manteniment dels estudiants modifiquem les columnes que es visualitzen

a l’apartat Subscriptions to courses, de manera que apareguin: Course, Subject, Professor
i Total hours. Ho fem perquè ens sembla que hi ha massa columnes i únicament ens
interessa mostrar-ne les indicades.
millorada del mòdul En el formulari de manteniment dels cursos, a la pestanya Calendar hi eliminem la
school a l’arxiu
school_06.zip dins columna Course, ja que és redundant amb el contingut de la capçalera, eliminem també
l’apartat “Mòduls la inadequada etiqueta que hi apareix i fem que sigui editable. Després afegim els nous
del web.
registres al final.
De la mateixa manera que en un camp one2many o many2many d’una vista

form, la utilització de l’element tree permet explicitar les columnes a visualitzar
(exemples anteriors), ja que si no s’utilitza OpenERP mostra tots els camps dels
objectes referenciats, pot interessar que l’edició en vista form de qualsevol dels
recursos mostrats en un giny one2many rebi algun camp ja emplenat i no sigui
editable.
Com a exemple, fixem-nos que en la situació actual del mòdul school (versió 06)
en editar un professor, l’apartat de detall Courses no és editable a la pròpia graella
i, per tant, quan editem un dels cursos existents o creem un nou curs, se’ns obre la
vista form de manteniment dels cursos, en la qual el camp Professor és editable.
Això suposa un problema greu, ja que si hem arribat a aquest manteniment des de
l’edició d’un professor, és clar que el camp Professor no ha de ser modificable i,
en crear un curs, el camp Professor ja ha d’aparèixer emplenat amb el valor del
professor pel que estem creant els cursos.
La solució es troba en introduir, després de l’element tree que facilita el contingut

de la graella detall del formulari principal, un element form per facilitar el
formulari d’edició corresponent als objectes de la graella. Aquest darrer element
form no ha de contenir el camp que referencia l’objecte del formulari principal i
OpenERP és prou intel·ligent per emplenar aquest camp amb l’identificador que
correspon. El següent esquema visualitza la solució:
1 <record model="ir.ui.view" id=...>

2 ...
5 <form string="Títol">
6 <!−− Camps del formulari principal −−>
7 <field name="xxx" colspan="4" nolabel="1">
8 <!−− xxx és un camp one2many −−>
9 <tree>
10 <!−− Indiquem els camps de la graella −−>
11 </tree>
12 <form>
13 <!−− Indiquem els camps que es desitja que
14 apareguin en editar/crear un recurs de
15 la graella corresponent al camp xxx −−>
16 </form>
17 </field>
18 </form>
19 </field>
20 </record>
Proveu a retocar el manteniment de professors del mòdul school vigent (versió

school_06) de manera que en editar un professor, l’acció de crear un curs o editar
un curs ja assignat mostri un formulari en el qual no aparegui el camp professor i,
en canvi, l’assignació del professor sigui l’adequada. Podeu trobar la versió
school a l’arxiu
school_07.zip dins
del web.
2.2.4 Vistes calendar
Les vistes calendari per a un objecte d’OpenObject són possibles quan l’objecte
conté camps date o datetime que permeten situar cada recurs en un interval de
temps (un dia, un dia-hora o un interval de dies) i faciliten la visualització i/o

l’edició dels recursos dins el seu interval de temps.
La figura 2.19 mostra un exemple de vista calendar visualitzada des del client
GTK corresponent al calendari de cursos (objecte school.course.event) del
mòdul school. Hi podem veure, a la zona esquerra, un giny corresponent al mes
actual (novembre del 2012) amb el dia actual marcat i, a sota, la llista de tots els
recursos de l’objecte school.course.event situats en aquest mes. Fixem-nos
que hi ha tres recursos, amb diferent color i amb una llegenda explicativa. A la part
dreta podem observar com el recurs 1 DAM-M10 Semestre 1 apareix en tots els
dies del mes (a causa que es desenvolupa des del 20 de setembre del 2012 fins el 19
de gener del 2013) mentre que el recurs 5 SI Opcio 1 s’ubica des del 12 fins el 16
de novembre i el recurs 6 SI Opció 2 des del 19 fins el 23 de novembre. La vista
calendari permet editar qualsevol recurs fent doble clic damunt i també permet
l’arrossegament per canviar-los d’ubicació. Així mateix, si el calendari mostra
molts recursos i la visibilitat és difícil, sempre podem seleccionar els recursos que
volem visualitzar a la llista de recursos de la part esquerra.
F igu r a 2. 1 9 . Exemple de vista calendari des del client GTK
La visualització de les vistes calendar des del client web de la versió 6.1
d’OpenERP presenta alguna anomalia, com ara no mostrar, en un mes, els recursos
que s’han iniciat en el mes anterior. Així, per exemple, la visualització de la vista
calendar de la figura ?? des del client web, no mostra el recurs 1 DAM-M10
Semestre 1 ja que s’ha iniciat en un mes anterior. Esperem que aquest bug se
solucioni en posteriors versions.
La figura 2.20 mostra un altre exemple de vista calendar. En aquest cas es tracta
de la vista calendar per a l’objecte school.course que conté una data del curs i,
la vista, situa cada recurs en la seva data. Observem com el recurs SI està ubicat en
el dia 12 de novembre. El recurs DAM-M10, que té com a data el 20 de setembre,
lògicament no apareix en el mes de novembre.
F ig ur a 2. 20. Exemple de vista calendari des del client GTK
Les vistes calendari es distingeixen perquè en la seva declaració incorporen:
1 <field name="type">calendar</field>
L’element arrel de l’XML que defineix l’arquitectura de la vista és calendar i pot

contenir els següents atributs:
• string: per al títol de la vista.
• date_start: que ha de contenir el nom d’un camp datetime o date del

model.
• date_delay: que ha de contenir la llargada en hores de l’interval. Aquest

atribut té preferència sobre l’atribut date_stop.
• date_stop: que ha de contenir el nom d’un camp datetime o date del

model. Aquest atribut és ignorat si existeix l’atribut date_delay.
• day_length: per indicar la durada en hores d’un dia. OpenObject utilitza

aquest valor per calcular la data final a partir del valor de date_delay. Per
defecte, el seu valor és 8 hores.
• color: per indicar el camp del model utilitzat per distingir, amb colors, els
recursos mostrats a la vista.
• mode: per mostrar l’enfoc (dia/setmana/mes) amb el qual s’obre la vista.

Valors possibles: day, week, month. Per defecte, month.
Els elements fills de l’element arrel calendar s’utilitzen per mostrar el seu
contingut dins la barra acolorida que ubica cada recurs dins el calendari.
Exemple de vista calendar en el mòdul school
Ens proposem definir dues vistes calendar en el mòdul school vigent (versió school_07 ).
A l’objecte school.course.event la vista calendar següent:
1 <record model="ir.ui.view"
2 id="view_school_course_event_calendar">
3 <field name="name">school.course.event.calendar
4 </field>
5 <field name="model">school.course.event</field>
6 <field name="type">calendar</field>
8 <calendar color="full_name" date_start="date"
9 date_stop="date_end">
10 <field name="id"/>
11 <field name="course_id"/>
13 </calendar>
14 </field>
15 </record>
Fixem-nos que els elements fills de l’element calendar són els camps id, course_id, name,
i són els camps que es visualitzen, separats per comes, a l’interior de les barres acolorides
que mostren cada recurs dins el calendari. L’atribut color de l’element calendar conté el
camp full_name que pretén mostrar la concatenació dels camps id, nom corresponent
a course_id i name. Per aconseguir-ho, hem hagut d’ampliar el model de l’objecte
school.course.event amb el camp funcional full_name que es basa en el mètode
_full_name definit a la pròpia classe.
1 class school_course_event(osv.osv):
2 def _full_name(self, cr, uid, ids, field_name, arg, context):
3 result = {}
4 for r in self.browse(cr, uid, ids, context=context):
5 result[r.id]=str(r.id)+’\t’+str(r.course_id.name) \
6 +’\t’+r.name
7 return result
8 ...
9 _columns = {
10 ...
11 ’full_name’: fields.function(_full_name,type=’char’,
12 size=60,readonly=’True’,
13 string=’Full name’)
14 }
A l’objecte school.course, la vista calendar següent:
2 id="view_school_course_calendar">
3 <field name="name">school.course.calendar</field>
El disseny de mètodes es 4 <field name="model">school.course</field>
troba al subapartat “Els 5 <field name="type">calendar</field>
mètodes”. 6 <field name="arch" type="xml">
7 <calendar color=’name’ date_start=’date’>
school a l’arxiu 9 <field name="subject"/>
school_08.zip dins 10 </calendar>
11 </field>
del web. 12 </record>
2.2.5 Vistes graph
Les vistes gràfic són un tipus de vista que permeten la visualització de gràfics
construïts a partir de les dades contingudes en els recursos.
La figura 2.21 mostra un gràfic de sectors corresponent a les hores de cadascun

dels cursos respecte el total d’hores dels cursos existents. La figura 2.22 correspon
al mateix càlcul però amb un gràfic de barres.
Fig u ra 2. 21 . Exemple de gràfic de sectors en el client GTK
Les vistes gràfiques es distingeixen perquè en la seva declaració incorporen:
1 <field name="type">graph</field>
L’element arrel de l’XML que defineix l’arquitectura de la vista és graph i pot

contenir els següents atributs:
• string: per al títol de la vista.
• type: per al tipus de gràfic. Per defecte és un gràfic de sectors (figura 2.21).
Cal indicar el valor bar per un gràfic de barres verticals (figura 2.22).
• orientation: per indicar el valor horizontal quan type sigui bar i es

desitgi un gràfic de barres horitzontal.
La definició dels elements fills de l’element arrel graph determina el contingut

del gràfic:
• El primer camp indica el contingut de l’eix X (horitzontal). És obligatori.

• El segon camp indica el contingut de l’eix Y (vertical). És obligatori.
• El tercer camp indica el contingut de l’eix Z en gràfics tridimensionals. És

optatiu.
F igu r a 2. 2 2 . Exemple de gràfic de barres en el client GTK
A cadascun dels camps que determinen els eixos se’ls pot aplicar els atributs
següents:
• group="True", per utilitzar en el segon o tercer camp per tal d’indicar que
cal agrupar els recursos d’igual valor que hi ha en aquest camp. El primer
camp sempre actua amb group="True".
• operator, per indicar l’operador que cal utilitzar per calcular el valor en
la resta dels camps, com a conseqüència de l’agrupació indicada a l’atribut
group. Els operadors permesos són: + (suma), *(producte), **(exponent),
min i max (menor i major valors de la llista de valors de l’agrupació). Per
defecte, actua l’operador +.
La visualització de les vistes graph que utilitzen l’atribut group, des del client
web de la versió 6.1 d’OpenERP, presenta alguna anomalia. Esperem que aquest
bug se solucioni en posteriors versions.
Exemple de vista graph en el mòdul school
Ens proposem definir una vista graph en el mòdul school vigent (versió school_08).
A l’objecte school.course, introduïm la vista següent:

2 id="view_school_course_graph">
3 <field name="name">school.course.graph</field>
4 <field name="model">school.course</field>
7 <graph string="Percentage of hours">
9 <field name="hours_total"/>
10 </graph>
11 </field>
12 </record>
Es tracta d’un gràfic de sectors (bidimensional) en el qual el camp que facilita la llegenda
(eix horitzontal en cas d’un gràfic de barres) és name de l’objecte school.course i el
camp que facilita el valor per calcular els sectors (eix vertical en un gràfic de barres) és
hours_total.
Cal tenir present que l’actual mòdul school permet tenir diversos cursos amb el mateix
nom i que el gràfic anterior agrupa els cursos amb igual name (agrupació automàtica pel
primer field de l’element graph). Si interessa no poder tenir diferents cursos amb igual
nom, cal definir una restricció d’unicitat (_sql_constraint) sobre el camp name de l’objecte
school.course. En canvi, si interessa permetre diferents cursos amb igual nom però
en el gràfic anterior no volem que s’agrupin, caldrà crear un camp function a l’objecte
school.course, que serà la concatenació dels camps id i name, i utilitzar aquest nou camp
en el gràfic en lloc del camp name. Podeu trobar la versió
school a l’arxiu
La manera més eficient per generar gràfics estadístics sobre objectes d’OpenERP school_09.zip dins
és: OpenERP” dels annexos
del web.
1. Crear en OpenERP un objecte estadístic basat en una vista que OpenERP

crea en la base de dades de PostgreSQL.
El disseny d’objectes
2. Crear una vista llista i una vista gràfic sobre l’objecte estadístic. estadístics es troba a
l’apartat “Reporting & BI”
2.2.6 Vistes search
Les vistes search són una nova funcionalitat d’OpenObject des de la versió 6.0
que consisteixen en la possibilitat de personalitzar el panell de cerca en les vistes
no formulari.
Si observem qualsevol de les vistes llista del mòdul school que estem millorant,
veurem que apareix un panell de cerca similar al de la figura 2.23. Hi veiem
un desplegable Filters que ens permet afegir filtres per acotar els registres per
visualitzar i els botons Search per executar la cerca i Clear per netejar els filtres.
Aquesta vista search és la que incorpora OpenObject quan no se n’indica cap,
i incorpora el camp de filtre Professor Name perquè la vista form de la classe
school.professor té el camp name amb l’atribut select="1". OpenERP a
partir de la versió 6.0 té en compte l’atribut select quan el model no incorpora
cap vista search.
F igu r a 2. 2 3 . Vista search per defecte en vistes llista
Un exemple de vista search sofisticada el tenim en el manteniment dels tercers

(partners), tal com mostra la figura 2.24. En cas que s’hagi instal·lat el mòdul
crm, la vista search es veu ampliada amb més filtres, tal com mostra la figura
2.25.
F igu r a 2. 2 4 . Vista search en la llista de tercers (sense instal·lar el mòdul crm)
La vista search de la figura 2.24 conté:
• Els botons Clients i Proveïdors per facilitar el filtre segons el tipus de

tercer. L’usuari els ha de prémer (un o ambdós o cap) segons el filtrat que
li interessi.
• Els camps de filtre Nom, Contactes, País i Venedor. L’usuari ha d’introduir

el valor de filtre.
• Una zona expandible Agrupa per... que mostra el botó Venedor per facilitar
veure els registres resultants dels filtres agrupats per venedor.
• Els elements de la vista search per defecte: Search, Clear i Filters.
F igu r a 2. 2 5 . Vista search en la llista de tercers (amb el mòdul crm instal·lat)
Les vistes search es distingeixen perquè en la seva declaració incorporen:
1 <field name="type">search</field>
L’element arrel de l’XML que defineix l’arquitectura de la vista és search i pot

tenir els següents elements fills:
• group: per agrupar un conjunt de filtres i/o condicions d’agrupament

sota un mateix títol, que s’indica a l’atribut string. No és obligatòria
l’existència del títol. També admet l’atribut expand (valors possibles: 0/1
– per defecte: 1) per indicar si el grup ha d’aparèixer expandit (1) o no (0).
• separator: per situar un separador, amb atribut orientation, que per

defecte és vertical. En una vista search no té sentit el separador
horitzontal. El separador no es visualitza en el client web d’OpenERP 6.1.
• label: per situar una etiqueta.
• field: per situar un camp textual de filtre en el qual l’usuari ha d’escriure

un valor.
• filter: per situar un botó que permet filtrar i/o agrupar sota unes determi-
nades condicions definides en el botó.
• newline: per provocar un salt de línia.
Pel que fa a l’element field, cal saber que:
• En els camps many2one, quan l’usuari comença a escriure un valor,

OpenObject mostra els valors possibles que comencen per aquell valor;
si es vol que el camp incorpori un desplegable, cal utilitzar l’atribut
widget="selection".
• Pot anar acompanyat de l’atribut context.
• OpenObject realment construeix un domini [(’camp’,’=’,’valor’)]

amb el valor introduït en el camp. Es pot alterar l’operador = de la condició
utilitzant l’atribut operator. Així mateix, es pot alterar el domini anterior
per un domini personalitzat, amb l’atribut filter_domain i, en tal cas, indi-
car el domini com una llista Python de condicions, en la qual les condicions
són tuples Python de tres elements: (’camp’,’condició’,’valor’).
La sintaxi de l’element filter és:
1 <filter string="Etiqueta" icon="nomIcona"

2 domain="llistaCondicions"
3 help="missatgeAjuda"
4 context="{’group_by’:’llistaCamps’}/>
en la qual:
• L’atribut icon ha de contenir una de les icones d’OpenERP, de manera

anàloga a l’atribut icon dels elements menuitem.
• L’atribut domain serveix per indicar el filtre i és, com en les accions, una llis-
ta Python de condicions que s’enllacen amb una clàusula AND; les condici-
ons són tuples Python de tres elements: (’camp’,’condició’,’valor’).
• L’atribut context serveix per indicar un context i, amb el valor clau

group_by, per aconseguir agrupar els registres pels camps indicats a
llistaCamps, separats per comes.
L’element filter es pot ubicar com a fill d’un element field per indicar que
el seu filtre s’aplica específicament sobre el camp. En aquest cas, el botó és més
petit i s’adequa a l’altura d’un camp field.
Per finalitzar amb les vistes search recordeu que el nom de la vista search que es
vol utilitzar s’ha d’indicar a l’element search_view_id de l’acció window que
invoca la vista.
Exemple d’anàlisi del codi de la vista search
El codi XML corresponent a la vista search de la figura 2.24 és:
1 <record id="view_res_partner_filter" model="ir.ui.view">

2 <field name="name">res.partner.select</field>
3 <field name="model">res.partner</field>
6 <search string="Search Partner">
7 <group col=’10’ colspan=’4’>
8 <filter string="Customers" name="customer"
9 icon="terp−personal"
10 domain="[(’customer’,’=’,1)]"
11 help="Customer Partners"/>
12 <filter string="Suppliers" name="supplier"
14 domain="[(’supplier’,’=’,1)]"
15 help="Supplier Partners"/>
16 <separator orientation="vertical"/>
17 <field name="name" select="1"/>
18 <field name="address" select="1"/>
19 <field name="country" select="1"/>
20 <field name="user_id" select="1">
21 <filter help="My Partners"
22 icon="terp−personal+"
23 domain="[(’user_id’,’=’,uid)]"/>
24 </field>
25 </group>
26 <newline />
27 <group expand="0" string="Group By...">
28 <filter string="Salesman" icon="terp−personal"
29 domain="[]"
30 context="{’group_by’ : ’user_id’}" />
31 </group>
32 </search>
33 </field>
34 </record>
Fixem-nos que aquesta vista té dos grups, separats per un salt de línia (newline). A la
figura 2.24 observem perfectament el primer grup, format pels botons Clients i Proveïdors i
els camps Nom, Contactes, País, Venedor i un darrer botó enganxat al camp Venedor. Del
segon grup només se’n veu el títol Agrupat per... ja que no està expandit (expand="0").
Situem-nos en el primer grup. Observem que:
• Els dos primers botons es corresponen a dos elements filter. Observem que la condició
del botó Clients és [(’customer’,’=’,1)] i que la condició pel botó Proveïdors és
[(’supplier’,’=’,1)].
• Els quatre camps que vénen a continuació es corresponen a elements field. El camp
user_id, que és de tipus many2one, podria portar l’atribut widget="selection" i llavors
l’usuari visualitzaria una llista desplegable.
• El darrer element, el botó petit, correspon a un element filter, fill del darrer element field,
ja que es tracta d’un filtre sobre el mateix camp user_id.
Situem-nos en el darrer grup. Si l’expandim, veurem que conté un únic botó, que es
correspon amb l’element filter string "Salesman" del codi anterior. Aquest element
no incorpora cap filtre (domain=[]) però en canvi incorpora l’atribut context amb la clau
group_by acompanyada del valor user_id que provoca que, en cas que l’usuari premi el
botó, els socis de negocis apareixeran agrupats per venedor (user_id).
Exemple d’incorporació de vista search en el mòdul school
Ens proposem incorporar una vista search en el mòdul school vigent (versió school_09).
En la vista llista dels professors cal:
• Afegir dos botons de filtre Named i Trainee per seleccionar els professors de cada tipus de
contracte.
• Afegir un camp de filtre Partner per permetre seleccionar els professors associats a un
determinat soci de negocis.
• Afegir un botó de filtre, associat al camp anterior, per permetre seleccionar els professors
associats a la companyia principal d’OpenERP.
• Afegir un camp de filtre per permetre seleccionar els professors la dedicació horària setmanal
(en hores) dels quals estigui per sobre del valor a introduir per l’usuari.
La vista és:
2 id="view_school_professor_search">
3 <field name="name">school.professor.search</field>
7 <search>
8 <group>
9 <filter string="Trainees" name="contract"
11 domain="[(’contract’,’=’,’trainee’)]"/>
12 <filter string="Nameds" name="contract"
14 domain="[(’contract’,’=’,’named’)]"/>
15 <separator orientation="vertical"/>
16 <field name="partner_id">
17 <filter help="Principal Company Professors’s"
18 icon="terp−personal+"
19 domain="[(’partner_id’,’=’,1)]"/>
20 </field>
21 <field name="hours_available"
22 string="Hours per Week >="
23 operator=">="/>
24 </group> Podeu trobar la versió
25 </search> millorada del mòdul
26 </field> school a l’arxiu
school_10.zip dins
27 </record> l’apartat “Mòduls
del web.
Fixeu-vos en el domini [(’partner_id’,’=’,1)] utilitzat per filtrar els professors associats
a la companyia principal d’OpenERP. Aquest filtre funciona perquè la companyia principal
sempre és la primera inserció a res_partner i, en conseqüència, sempre té id=1.
2.3 Mètodes
Per encarar amb garanties el disseny de mètodes en OpenObject es pressuposa uns

coneixements mínims de disseny de mètodes en Python.
La capa ORM d’OpenObject facilita un seguit de mètodes que s’encarreguen del

mapatge entre els objectes Python i les taules de PostgreSQL. Així, disposem de
mètodes per crear, modificar, eliminar i cercar registres a la base de dades. Aquests
mètodes són utilitzats de manera automàtica per OpenObject en l’execució dels
diversos tipus de vista que OpenObject ens permet dissenyar.
En ocasions, però, pot ser necessari alterar l’acció automàtica de cerca – creació
– modificació – eliminació facilitada per OpenObject i, llavors, haurem de sobre-
escriure els corresponents mètodes en les nostres classes.
Com exemple d’aquesta necessitat, podem considerar el cas de la gestió de

comandes de venda (classe sale_order) dins el fitxer sale.py del mòdul sale
d’OpenERP. Si hi fem una ullada, al final de la classe hi trobem el disseny dels
mètodes unlink (eliminar), create (crear) i write(modificar). Cadascun d’ells
executa un seguit de comprovacions i/o accions i, si tot és correcte, invoca la crida
dels corresponents mètodes unlink, create i write de la capa ORM. Així, el
mètode unlink (eliminació de comandes) comprova si les comandes a eliminar
tenen l’estat draft o cancel (estats en els quals l’eliminació és permesa, segons
la lògica de negoci) i si alguna de les comandes no és eliminable genera una
excepció tot avortant l’eliminació; en canvi, si totes són eliminables, procedeix
a l’eliminació tot invocant el mètode unlink subministrat per la capa ORM.
Els programadors en el framework OpenObject hem de conèixer els mètodes

subministrats per la capa ORM i hem de dominar el disseny de mètodes per:
• Poder definir camps funcionals en el disseny del model.
• Poder definir l’acció que cal executar en modificar el contingut d’un field
Als annexos del web hi d’una vista form (atribut on_change del field)
trobareu l’annex
“Depuració de codi Python
en OpenERP”,
imprescindible a l’hora de
desenvolupar mètodes.
• Poder alterar les accions automàtiques de cerca, creació, modificació i
eliminació de recursos.
Una darrera consideració a tenir en compte en l’escriptura de mètodes i funcions

en OpenObject és que els textos de missatges inclosos en mètodes i funcions, per
poder ser traduïbles, han de ser introduïts amb la sintaxi _(’text’) i el fitxer .py
ha de contenir from tools.translate import _ a la capçalera.
2.3.1 Mètodes ORM
La majoria de mètodes ORM que proporciona OpenObject tenen els paràmetres

següents:
• cr: cursor de la base de dades
• uid: identificador de l’usuari que executa el mètode
• ids: llista d’enters amb els identificadors dels recursos als quals s’aplica el
mètode
• context: diccionari Python amb un seguit de paràmetres que poden ser

necessaris en l’execució del mètode, com per exemple: idioma, zona
horària, companyia...
Recordem que OpenObject té, per cada classe Python, un únic objecte en memòria
per gestionar tots els recursos del model associat a la classe. Per això, un mètode
s’invoca sempre sobre l’únic objecte en memòria i rep, a través del paràmetre ids,
la llista dels identificadors dels recursos sobre els quals actuar.
El per què del paràmetre ids en la definició d’un mètode d’OpenObject
Per ajudar a entendre la necessitat del paràmetre ids, obrim la vista tree de professors.
Suposem que tenim diversos professors i n’efectuem una selecció (un o més d’un)
per eliminar-los. En el moment que premem el botó Delete i confirmem l’eliminació,
OpenObject invoca el mètode unlink sobre l’únic objecte school_professor existent en
memòria i li passa la llista dels identificadors dels professors seleccionats, de manera que
el mètode unlink pot eliminar-los.
El paràmetre context és un calaix de sastre ideat per OpenObject per ficar-hi tots
aquells paràmetres que el mètode pot necessitar i que en canvi no s’ha previst en
el prototipus del mètode.
Exemple de contingut dels paràmetres uid, ids i context
Per veure el contingut dels paràmetres uid, ids i context en algun mètode, sobreescrivim
el mètode unlink (eliminació) a la classe school.professor:
1 def unlink(self, cr, uid, ids, context=None):

2 print "Contingut de uid : " + str(uid)
3 print "Llista ids amb ’%d’ valors: " % len(ids)
4 for id in ids:
5 print "\t’%d’" % id
6 print "Diccionari context amb ’%d’ tuples: " % \
7 len(context)
8 for val in context.items():
9 print "\t’%s’" % (val,)
10 return osv.osv.unlink(self, cr, uid, ids, context=context)
Aquest mètode unlink mostra per la consola del sistema el contingut dels paràmetres
uid, ids i context i invoca el mètode unlink de la capa ORM per procedir a l’eliminació.
Observem el contingut en cas que s’hagi seleccionat l’eliminació de 3 professors:
1 Contingut de uid : 1
2 Llista ids amb ’3’ valors:
3 ’16’
4 ’17’
5 ’18’
6 Diccionari context amb ’4’ tuples:
7 ’(’lang’, u’ca_ES’)’
8 ’(’tz’, False)’
9 ’(’uid’, 1)’
10 ’(’section_id’, False)’
L’ uid 1 és l’identificador de l’usuari que està eliminant els professors; els uids dels
professors per eliminar són 16, 17 i 18; el context conté 4 tuples: lang actiu, timezone
activa, uid i section_id.
Alguns dels mètodes ORM més utilitzats són:
• Mètode read
• Mètode name_get
• Mètode browse
• Mètode self.pool.get
• Mètode search
• Mètode create
• Mètode write
En el Technical Memento • Mètode unlink

hi trobareu la relació
completa dels mètodes Mètode read
ORM amb la seva sintaxi i
algun exemple.
read (self, cr, uid, ids, fields=None, context=None)
fields : llista de camps dels quals es vol obtenir el contingut. Per defecte, tots
els camps.
Per cada recurs d’ ids, obté un diccionari de parelles camp:valor corresponent

als camps indicats en el paràmetre fields i retorna una llista amb tots els
diccionaris. Cada diccionari incorpora, encara que no s’hagi explicitat a fields,
la parella id:valor.
Mètode name_get
name_get (self, cr, uid, ids, context=None)
Retorna una llista de tuples (id, valor) amb la representació textual dels
recursos d’ ids. Recordem que la representació textual d’un recurs és, en principi,
el contingut del camp name (camp especial de l’atribut _columns de la classe
Python) o, si està definit, el camp indicat a l’atribut _rec_name de la classe
Python. Quan OpenObject necessita la representació textual d’un recurs, invoca
automàticament el mètode name_get.
En ocasions, pot interessar que la representació textual d’un recurs sigui el resultat
d’un determinat càlcul i llavors caldrà sobreescriure aquest mètode.
Exemple d’utilització dels mètodes read i name_get en el mòdul school
Situem-nos en la versió vigent del mòdul school (versió school_10).
La classe school.student té les columnes idnum, name i surname. Per tant, la

representació textual d’un alumne és el seu nom i això és força adequat, però preferim que
sigui la concatenació de cognom i nom, separats per una coma i un espai. Per aconseguir-
ho cal sobreescriure el mètode name_get a la classe school_student:
1 def name_get (self, cr, uid, ids, context=None):

2 res = []
3 records = self.read(cr, uid, ids, [’name’,’surname’])
4 for r in records:
5 res.append((r[’id’], r[’surname’]+", "+r[’name’]))
6 return res
Fixem-nos que per poder generar la concatenació indicada ens cal per a cada recurs
conèixer el cognom i el nom, i per aconseguir-ho hem utilitzat el mètode read. Observem,
també, que name_get ha de retornar una llista de tuples i, per això, en invocar la funció
append de Python, en el seu interior construïm el tuple (r[’id’],...).
La modificació efectuada a la classe school_student no és visible ja que no hi ha cap vista

en la qual hagi d’aparèixer la representació textual d’un estudiant. Per forçar la utilització
del nou mètode name_get ens plantegem que a la vista tree de l’objecte school.student,
en comptes d’aparèixer les columnes Name i Surname per separat, aparegui una única
columna Full Name. Per aconseguir-ho, cal afegir al model school.student el camp
funcional full_name. Segons la definició dels camps funcionals, la funció que ha d’invocar
un camp funcional ha de tenir un determinat nombre d’arguments, que no són els del
mètode name_get. En conseqüència, cal crear una nova funció _name_get_fnc per utilitzar
en la definició del camp funcional.
1 def _name_get_fnc(self, cr, uid, ids, prop, unknow_none,

2 context):
3 res = self.name_get(cr, uid, ids, context)
4 return dict(res)
A la zona _columns de school.student hi afegim el camp:
1 ’full_name’: fields.function(_name_get_fnc, type=’char’, size=’66

’,
2 string=’Full Name’,readonly=’True’),
A causa que la funció invocada per un camp funcional ha de retornar un diccionari de

parelles id:valor i que la funció name_get retorna una llista de tuples (id, valor), ens
va molt bé utilitzar la funció Python dict que, donada una llista de tuples de parelles, ens
retorna el corresponent diccionari.
Per finalitzar l’exemple, comentar que sembla recomanable afegir l’atribut _order a la
classe school_student per visualitzar els estudiants ordenats per cognom.
Per comprovar la visualització de la columna Full Name en la vista tree de millorada del mòdul
school a l’arxiu
school.student, cal retocar la vista. school_11.zip dins
Mètode browse del web.
browse (self, cr, uid, ids, context = None)
Recupera els recursos de la llista ids com a llista d’objectes sobre els quals és
possible utilitzar la notació de punt per accedir a qualsevol dels seus camps i, en
el cas de camps relacionals, navegar cap als objectes apuntats. Si ids és un únic
recurs (no llista), facilita el corresponent objecte (no llista d’objectes).
Aquest és un mètode fantàstic, a causa de la potència que facilita per poder navegar
entre els objectes mitjançant els camps relacionals.
Com a exemple d’utilització del mètode browse podem revisar el mètode

_full_name de la classe school_course_event del mòdul school.
Mètode self.pool.get
self.pool.get (’nom_objecte’)
Mètode especial que permet obtenir l’objecte Python que gestiona els recursos del
model associat a qualsevol classe.
Aquest mètode és imprescindible quan en el disseny d’un mètode d’una classe,

cal invocar un mètode d’una altra classe. Recordem que OpenObject té un únic
objecte que gestiona tots els recursos del model associat a cada classe. Per tant, en
el contingut d’un mètode s’utilitza self per fer referència a l’objecte que gestiona
els recursos de la classe, però és molt possible que calgui accedir a l’objecte que
gestioni els recursos d’una altra classe i, en tal situació, el mètode self.pool.get
hi facilita l’accés.
Mètode search
search (self, cr, uid, args, offset=0, limit=None, order=None,

context=None, count=False)
• args: llista de tuples especificant criteris de cerca.
• offset: nombre de registres a saltar (opcional).
• limit: màxim nombre de registres a recuperar (opcional).
• order: columnes sobre les quals ordenar el resultat. Per defecte, utilitza les
columnes indicades a l’atribut _order de la definició de la classe Python i,
en el seu defecte, la columna id de tota classe Python.
• count: si té valor True indica que el mètode només ha de retornar el

nombre de registres que coincideixen amb els criteris indicats, en comptes
de recuperar els seus identificadors.
Retorna una llista dels identificadors dels recursos que verifiquen els criteris de
cerca o, si count=True, el nombre de registres.
Les condicions que cal introduir en els criteris de cerca han de verificar:
• Cada condició és un tuple del tipus (’nom_camp’, ’op’, valor) en el

qual op és qualsevol dels operadors binaris següents: =, !=, >, >=, <,
<=, like, ilike, in, not in, child_of. L’operador like diferencia
majúscules de minúscules, mentre que ilike no ho fa.
• La negació d’una condició s’efectua amb l’operador ! davant el tuple.
• La combinació de condicions amb els operadors & (conjunció) i | (disjunció)

s’efectua utilitzant la notació polonesa, també coneguda per notació prefix.
Exemple d’utilització de mètode self.pool.get i mètode search amb condició

complexa
Suposem que en algun lloc (fora de cap mètode de la classe school.professor)

necessitem efectuar una cerca de professors el nom dels quals conté el text Rodríguez
i que tenen contracte named. Escriuríem:
1 prof = self.pool.get(’school.professor’)
2 ids = prof.search(cr,uid,[’&’,(’contract’,’=’,’named’),
3 (’name’,’ilike’,’Rodriguez’)])
Si la cerca s’hagués d’efectuar dins un mètode de la classe school_professor no caldria

la crida a self.pool.get i escriuríem directament:
1 ids = self.search(cr,uid,[’&’,(’contract’,’=’,’named’),
2 (’name’,’ilike’,’Rodriguez’)])
Per obtenir els professors el nom dels quals no contingui el text Rodríguez i que tenen
contracte named, escriuríem:
1 ids = self.search(cr,uid,[’&’,(’contract’,’=’,’named’),
2 ’!’,(’name’,’ilike’,’Rodriguez’)])
Mètode create
create (self, cr, uid, values, context=None)
Crea un nou registre amb els valors especificats en el paràmetre values, de tipus
diccionari. Retorna l’identificador del registre creat.
Mètode write
write (self, cr, uid, ids, values, context=None)
Modifica els registres especificats a la llista ids, amb els valors indicats en el
paràmetre values, de tipus diccionari. Retorna True.
Mètode unlink
unlink (self, cr, uid, ids, context=None)
Elimina els registres especificats a la llista ids. Retorna True.
Els mètodes create, write i unlink són candidats a ser sobreescrits quan interes-
si alterar el seu funcionament habitual. En tal situació, la seva sobreescriptura ha
d’incloure, en algun punt, la crida als mètodes create, write i unlink de la
classe osv.osv. És a dir, la sobreescriptura de qualsevol d’aquests mètodes seria
quelcom similar a:
Hi ha més mètodes ORM

1 def metode (self, cr, uid, ...): interessants de conèixer i
2 ... accions/comprovacions que corresponguin ... que trobareu en el
3 ... crida al mateix mètode de la classe osv.osv ... Technical Memento
4 ... accions/comprovacions que corresponguin ... doc.openerp.com/memento.
5 return ...
2.3.2 Mètodes on_change
Les vistes form faciliten, en els camps editables, l’atribut on_change per indicar
una acció a executar quan l’usuari canvia el valor del camp. El contingut d’aquest
atribut ha de ser la crida a un mètode de la classe, amb els paràmetres que
corresponguin (normalment el nou valor que ha pres el camp i, eventualment,
valors d’altres camps).
El mètode invocat per l’atribut on_change té obligatòriament la sintaxi:
1 def metode (self, cr, uid, ids, paràmetres...)
i ha de retornar, sempre:
1 return {’value’: resultat}
en què resultat ha de ser un diccionari de parelles ’camp’:valor amb els nous

valors dels camps que s’han de veure afectats per l’execució del mètode.
Exemple d’utilització de mètodes on_change en el mòdul school
En el formulari de professors de la versió vigent del mòdul school (versió school_11),

en canviar de professor, el telèfon –camp related– s’actualitza automàticament, però si
editem un professor i li canviem l’adreça, mentre no s’enregistra el canvi, el formulari
presenta la nova adreça però manté el telèfon de l’adreça antiga i això no és lògic. Cal,
doncs, que en canviar el contingut de l’adreça es modifiqui automàticament el contingut
del telèfon i això s’aconsegueix introduint, a la vista form l’atribut on_change en el camp
address_id:
1 <field name="address_id"
2 on_change="address_id_change(address_id)"/>
L’atribut on_change invoca el mètode que hem de tenir a la classe school_professor:
1 def address_id_change (self, cr, uid, ids, address_id):

2 result = {}
3 if address_id:
4 obj = self.pool.get("res.partner.address")
5 address = obj.browse(cr, uid, address_id)
6 result[’phone’] = address.phone
7 else:
8 result[’phone’] = ""
9 return {’value’: result}
Així, en canviar l’adreça del professor, el telèfon canvia automàticament, sense haver
d’esperar a enregistrar el canvi. En cas de deixar el professor sense adreça, el telèfon
hauria de passar a estar en blanc. Aquest és el funcionament correcte des del client GTK,
però en el client web d’OpenERP v.6.1 no funciona.
school a l’arxiu
school_12.zip dins
Per finalitzar amb els mètodes on_change, considerem la següent situació com-
l’apartat “Mòduls plexa. Suposem una vista form A des de la qual s’invoca una altra vista form B en
del web. què un atribut on_change invoca un mètode al qual s’ha de passar algun(s) valor(s)
del formulari B (cap problema) i l’identificador del recurs actiu en el formulari A.
Per solucionar aquesta situació, OpenObject ens facilita la sintaxi parent.id. En
els mòduls OpenERP de la versió 6.1, aquesta situació únicament es presenta en
dos mòduls:
• Vista view_partner_form_inherit del mòdul base_contact (fitxer

base_contact_view.xml)
• Vista view_inventory_form del mòdul stock (arxiu stock_view.xml)

Sistemes ERP-CRM.
Explotació i adequació - II

Sistemes de gestió empresarial Sistemes ERP-CRM. Explotació i adequació - II
Índex
Introducció 5
1 OpenERP: desenvolupament avançat 9

1.1 Herència . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Herència en el model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.2 Herència en la vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.3 Herència en el controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.4 Exemple d’herència . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Definició de la seguretat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Càrrega de dades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Programació d’assistents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5 Traducció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 Reporting & BI 29
2.1 Reporting extern a l’ERP: JasperReports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1 Instal·lació i configuració de JasperReports Server Community 5.0 . . . . . . . . . . . 32
2.1.2 Utilització d’iReport Designer 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2 Reporting en OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.1 Disseny d’informes RML a través d’OpenOffice/LibreOffice . . . . . . . . . . . . . . 44
2.2.2 Disseny d’informes JRXML a través d’iReport Designer . . . . . . . . . . . . . . . . 50
2.3 Solucions BI en OpenERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.3.1 Vistes basades en objectes no persistents . . . . . . . . . . . . . . . . . . . . . . . . 54
2.3.2 Quadres de comandament . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Sistemes de gestió empresarial 5 Sistemes ERP-CRM. Explotació i adequació - II
Introducció
L’explotació i adequació d’un sistema ERP-CRM implica conèixer les eines de

desenvolupament que el propi ERP-CRM proporciona. En el cas d’OpenERP ens
cal conèixer els mecanismes que proporciona el framework OpenObject en el qual
es basa el desenvolupament d’OpenERP.
Una vegada es coneix l’arquitectura MVC del framework OpenObject i se sap

interpretar el model, la vista i el controlador dels mòduls facilitats per OpenERP i
s’és capaç de dissenyar-ne de nous, cal aprofundir en altres mecanismes importants
que facilita OpenObject: herència –utilitzada per l’adaptació de mòduls existents–,
seguretat, càrrega massiva de dades, desenvolupament d’assistents, generació de
traduccions idiomàtiques, disseny d’informes, disseny de quadres de comanda-
ment i altres. Per aconseguir-ho hem estructurat la unitat en dos apartats.
L’apartat “OpenERP: desenvolupament avançat” té com a objectiu conèixer els

mecanismes avançats de disseny que OpenObject proporciona. Així, veurem
com aplicar l’herència en el disseny de model i vistes, com definir polítiques de
seguretat, com preparar càrregues massives de dades, com desenvolupar assistents
d’ajuda a l’usuari i com generar traduccions idiomàtiques.
L’apartat “Reporting & BI” està destinat al disseny d’informes i quadres de

comandament i tindrà dos enfocaments: intern, generant informes i quadres de
comandament que s’integrin en OpenERP, i extern, utilitzant una de les eines
BI que avui en dia té més empenta i que permet generar informes i quadres de
comandament connectant a qualsevol origen de dades.
El disseny d’informes que s’integrin en OpenERP es basa en utilitzar els meca-

nismes existents a OpenObject, ja siguin directament incorporats en el framework
(informes dissenyats amb OpenOffice o LibreOffice) o facilitats per la comunitat
(informes construïts amb el conegut dissenyador d’informes de codi lliure iReport).
Pel que fa als quadres de comandament, OpenERP en possibilita la confecció a
partir de vistes ja existents.
En referència a la utilització d’alguna de les eines BI per generar informes i

quadres de comandament connectant a qualsevol origen de dades i, en particular,
a la base de dades PostgreSQL d’una empresa gestionada per OpenERP, s’ha
escollit la versió comunitària de JasperReportsServer. La causa d’aquesta elecció
radica en el fet que l’eina de disseny dels informes és la mateixa eina iReport
que utilitzarem per dissenyar una tipologia d’informes integrables en OpenERP
i, d’aquesta manera, sumarem esforços. Per desgràcia, el disseny de quadres
de comandament no existeix en la versió comunitària de JasperReports Server,
però l’empresa JasperSoft ens permet instal·lar una versió de prova de la versió
Enterprise, que sí permet el disseny de quadres de comandament, totalment
operativa, per a 30 dies.
El seguiment d’aquesta unitat pressuposa que l’alumne és coneixedor de:
1. La implantació tècnica d’OpenERP. El seu coneixement s’adquireix a la

unitat “Sistemes ERP-CRM. Implantació” del mòdul professional Sistemes
de gestió empresarial.
2. La implementació del patró model-vista-controlador facilitat pel framework

OpenObject, en el que es basa OpenERP. El seu coneixement s’adquireix
a la unitat “Sistemes ERP-CRM. Explotació i adequació – I” del mòdul
professional Sistemes de gestió empresarial.
3. El llenguatge XML. El seu coneixement s’adquireix al mòdul professional

Llenguatges de marques i sistemes de gestió de la informació.
4. La programació orientada a objectes. El seu coneixement s’adquireix al

mòdul professional Programació.
5. El llenguatge Python.
Per tal d’assolir un bon aprenentatge, cal estudiar els continguts en l’ordre indicat,
sense saltar-se cap apartat. Quan es fa referència a algun annex del web, adreçar-
s’hi i estudiar-lo. Una vegada estudiats els continguts del material paper i del
material web, cal desenvolupar les activitats web.

• Utilitza eines i llenguatges de consulta i manipulació de dades propor-

cionades pels sistemes ERP-CRM.
• Genera formularis.
• Genera informes, des del sistema ERP-CRM i des de solucions BI.
• Genera quadres de comandament, des del sistema ERP-CRM i des de
solucions BI.
• Exporta informes.
• Utilitza les funcionalitats d’accés centralitzat que proporcionen les
solucions BI.
2. Adapta sistemes ERP-CRM identificant els requeriments d’un supòsit em-

presarial i utilitzant les eines proporcionades pels mateixos.
• Identifica les possibilitats d’adaptació de l’ERP-CRM.

• Adapta definicions de camps, taules i vistes de la base de dades de
l’ERP-CRM.
• Adapta consultes.
• Adapta interfícies d’entrada de dades i de processos.
• Personalitza informes i quadres de comandament.
• Adapta procediments emmagatzemats de servidor.
• Realitza proves.
1. OpenERP: desenvolupament avançat
L’OpenERP és desenvolupat a partir del framework OpenObject que es basa en

el patró MVC. De manera que, per implementar un nou mòdul en OpenERP, cal
definir-ne el model, la vista i el controlador. Però amb això no n’hi ha prou. El
framework OpenObject és molt potent i facilita mecanismes per aconseguir altres
fites, com ara:
• Adequar mòduls existents i així garantir que les actualitzacions d’aquests

mòduls no destrossin les adequacions desenvolupades, fet que és el resultat
de l’aplicació del mecanisme d’herència.
• Definir una política de seguretat que s’apliqui en el procés d’instal·lació del

mòdul.
• Dissenyar assistents que facilitin l’execució de diversos processos.
• Incorporar dades a un mòdul, ja sigui per facilitar la demostració de les

funcionalitats del mòdul per quan s’ha instal·lat l’empresa amb dades de
demostració, o perquè el mòdul necessita un conjunt de dades bàsiques pel
seu funcionament (per exemple, els diversos tipus d’IVA a aplicar en el
mòdul comptable d’un país).
• Traduir un mòdul a diversos idiomes.
1.1 Herència
El framework OpenObject facilita el mecanisme de l’herència per tal que els

programadors puguin adaptar mòduls existents i garantir a la vegada que les
actualitzacions dels mòduls no destrossin les adequacions desenvolupades.
L’herència es pot aplicar en els tres components del patró MVC:
• En el model: possibilita ampliar les classes existents o dissenyar noves

classes a partir de les existents.
• En la vista: possibilita modificar el comportament de vistes existents o

dissenyar noves vistes.
• En el controlador: possibilita sobreescriure els mètodes existents o

dissenyar-ne de nous.
OpenObject proporciona tres mecanismes d’herència: l’herència de classe, l’he-

rència per prototip i l’herència per delegació. La taula 1.1 presenta els tres tipus i
en presenta les principals diferències, i la figura 1.1 en mostra una representació.
Tau la 1.1 . Mecanismes d’herència facilitats pel framework OpenObject

Mecanisme Característiques Com es defineix
De classe - Herència simple. - S’utilitza l’atribut _inherit en la definició de la

- La classe original queda substituïda per la nova classe Python: _inherit = obj
nova classe. - El nom de la nova classe ha de continuar sent
- Afegeix noves funcionalitats (atributs i/o el mateix que el de la classe original: _name =
mètodes) a la classe original. obj
- Les vistes definides sobre la classe original
continuen funcionant.
- Permet sobreescriure mètodes de la classe
original.
- En PostgreSQL, continua mapada en la
mateixa taula que la classe original, ampliada
amb els nous atributs que pugui incorporar.
Per prototip - Herència simple. - S’utilitza l’atribut _inherit en la definició de la

- Aprofita la definició de la classe original (com nova classe Python: _inherit = obj
si fos un «prototipus»). - Cal indicar el nom de la nova classe: _name =
- La classe original continua existint. nou_nom
- Afegeix noves funcionalitats (atributs i/o
mètodes) a les aportades per la classe original.
- Les vistes definides sobre la classe original no
existeixen (cal dissenyar-les de nou).
- Permet sobreescriure mètodes de la classe
original.
- En PostgreSQL, queda mapada en una nova
taula.
Per delegació - Herència simple o múltiple. - S’utilitza l’atribut _inherits en la definició de

- La nova classe «delega» certs funcionaments la nova classe Python: _inherits = ...
a altres classes que incorpora a l’interior. - Cal indicar el nom de la nova classe: _name =
- Els recursos de la nova classe contenen un nou_nom
recurs de cada classe de la que deriven.
- Les classes base continuen existint.
- Afegeix les funcionalitats pròpies (atributs i/o
mètodes) que correspongui.
- Les vistes definides sobre les classes bases
no existeixen a la nova classe.
- En PostgreSQL, queda mapada en diferents
taules: una taula per als atributs propis, mentre
que els recursos de les classes derivades
resideixen en les taules corresponents a les
dites classes.
Fig u ra 1 . 1 . Mecanismes d’herència facilitats pel framework OpenObject

Per últim, comentar que el fitxer __openerp__.py d’un mòdul que contingui
herència respecte altres mòduls n’haurà d’incloure els noms a l’apartat depends,
per garantir que, en instal·lar el mòdul que hereta, els mòduls dels quals s’hereta
ja estiguin instal·lats o s’instal·lin prèviament.
1.1.1 Herència en el model
El disseny d’un objecte (classe) d’OpenObject heretat és gairebé idèntic al disseny

d’un objecte (classe) d’OpenObject no heretat; únicament hi ha dues diferències:
• Apareix l’atribut _inherit o _inherits per indicar l’objecte (herència

simple) o els objectes (herència múltiple) dels quals deriva el nou objecte.
La sintaxi a seguir és:
1 _inherit = ’nom.objecte.del.que.es.deriva’
2 _inherits = {’nom.objecte1’:’nom_camp_FK1’, ...}
• En cas d’herència simple, el nom (atribut _name) de l’objecte derivat pot

coincidir o no amb el nom de l’objecte pare. També és possible no indicar
l’atribut _name, fet que indica que el nou objecte manté el nom de l’objecte
pare.
L’herència simple (_inherit) amb atribut _name idèntic al de l’objecte pare,

s’anomena herència de classe i en ella el nou objecte substitueix l’objecte pare, tot
i que les vistes sobre l’objecte pare continuen funcionant. Aquest tipus d’herència,
la més habitual, s’utilitza quan es vol afegir dades (_columns) i/o modificar
propietats de dades existents i/o modificar el funcionament d’alguns mètodes. En
cas d’afegir dades, aquestes s’afegeixen a la taula de la base de dades en la qual
estava mapat l’objecte pare.
Exemple d’herència de classe
L’herència de classe la trobem en molts mòduls que afegeixen dades i mètodes a objectes
ja existents, com per exemple, el mòdul comptabilitat (account) que afegix dades i mètodes
a l’objecte res.partner. Fixem-nos en el contingut del mòdul account:
1 class res_partner(osv.osv):
2 _name = ’res.partner’
3 _inherit = ’res.partner’
4 _columns = {
5 ...
6 ’debit_limit’: fields.float(’Payable limit’),
7 ...
Podeu comprovar que la taula res_partner d’una empresa sense el mòdul account
instal·lat no conté el camp debit_limit, que en canvi sí que hi apareix una vegada instal·lat
el mòdul.
OpenERP té molts mòduls que deriven de l’objecte res.partner per afegir-hi

característiques i funcionalitats.
L’herència simple (_inherit) amb atribut _name diferent al de l’objecte pare,

s’anomena herència per prototip i en ella es crea un nou objecte que aglutina les
dades (_columns) i mètodes que tenia l’objecte del qual deriva, juntament amb les
noves dades i mètodes que pugui incorporar el nou objecte. En aquest cas, sempre
es crea una nova taula a la base de dades per mapar el nou objecte.
Exemple d’herència per prototip
L’herència per prototip és difícil de trobar en els mòduls que incorpora OpenERP. Un
exemple el tenim en el mòdul base_calendar en el qual podem observar el mòdul
comptabilitat (account) que afegix dades i mètodes a l’objecte res.partner. Fixem-nos
en el contingut del mòdul account:
1 class res_alarm(osv.osv):
2 _name = ’res.alarm’
3 ...
4 class calendar_alarm(osv.osv):
5 _name = ’calendar.alarm’
6 _inherit = ’res.alarm’
7 ...
En una empresa que tingui el mòdul base_calendar instal·lat podeu comprovar l’existència
de la taula res_alarm amb els camps definits a l’apartat _atributs de la classe res_alarm
i la taula calendar_alarm amb camps idèntics als de la taula res_alarm més els camps
definits a l’apartat _atributs de la classe calendar_alarm.
L’herència múltiple (_inherits) s’anomena herència per delegació i sempre

provoca la creació d’una nova taula a la base de dades. L’objecte derivat ha
d’incloure, per cada derivació, un camp many2one apuntant l’objecte del qual
deriva, amb la propietat ondelete=’cascade’. L’herència per delegació obliga
que cada recurs de l’objecte derivat apunti a un recurs de cadascun dels objectes
dels quals deriva i es pot donar el cas que hi hagi diversos recursos de l’objecte
derivat que apuntin a un mateix recurs per algun dels objectes dels quals deriva.
Exemple d’herència per delegació
L’herència per delegació no és molt utilitzada en els mòduls que incorpora OpenERP. Un
exemple el trobem en el mòdul product en el qual l’objecte product.product deriva per
delegació de l’objecte product.template:
1 class product_template(osv.osv):
2 _name = "product.template"
3 ...
4 class product_product(osv.osv):
5 _name = "product.product"
6 _inherits = {’product.template’: ’product_tmpl_id’}
7 _columns = {
8 ...
9 ’product_tmpl_id’:
10 fields.many2one (’product.template’, ’Product Template’,
11 required=True, ondelete="cascade"),
12 ...
Tot i que _inherits està pensat per possibilitar l’herència múltiple, en aquest cas l’objecte
product.product únicament deriva de l’objecte product.template. A nivell de la base
de dades, la taula product_template conté els camps definits a l’atribut _columns de
l’objecte template.product i la taula product_product conté els camps definits a l’atribut
Trobareu el mòdul
delegation_inheritance _columns de l’objecte product.product, entre els quals hi ha el camp producte_tmpl_id,
dins l’apartat “Mòduls de tipus many2one, utilitzat en la declaració de l’herència a _inherits. Cada recurs de
OpenERP i fitxers
auxiliars” dels annexos del product.product penja obligatòriament d’un recurs de product.template i per un recurs
web. de product.template podem tenir diversos recursos de product.product que hi pengin.
Exemple d’herència múltiple
El mòdul delegation_inheritance defineix l’objecte di.subclass que deriva dels

objectes di.superclass1 i di.superclass2 i facilita dues vistes: tree i form.
Feu una ullada a la definició de les classes i comproveu els següents funcionaments.
La vista tree, que és editable, permet afegir recursos a l’objecte subclass. Fixeu-vos
que les dues primeres columnes corresponen a continguts dels objectes superclass1 i
superclass2 i que per cada registre que afegim a través d’aquesta vista es genera un
registre a cadascuna de les taules: di_subclass, di_superclass1 i di_superclass2, de
manera que el recurs de di_subclass referencia als altres recursos.
La vista form, en canvi, obliga a seleccionar recursos dels objectes superclass1 i

superclass2, i demostra que els recursos dels objectes pare poden ser referenciats per
diversos objectes dels recursos derivats.
1.1.2 Herència en la vista
L’herència de classe possibilita continuar utilitzant les vistes definides sobre

l’objecte pare, però en moltes ocasions interessa disposar d’una versió retocada.
En aquest cas, és molt millor heretar de les vistes existents (per afegir, modificar
o eliminar camps) que no pas reemplaçar-les completament.
El disseny d’una vista heretada és gairebé idèntic al disseny d’una vista no

heretada; únicament cal afegir l’element:
1 <field name="inherit_id" ref="id_xml_vista_pare"/>
En cas que la vista id_xml_vista_pare resideixi en un mòdul diferent del que

estem dissenyant, cal afegir el nom del mòdul al davant:
1 <field name="inherit_id" ref="modul.id_xml_vista_pare"/>
El motor d’herència d’OpenObject, en trobar una vista heretada, processa el

contingut de l’element arch. Per cada fill d’aquest element que tingui algun
atribut, OpenObject cerca a la vista pare una etiqueta amb atributs coincidents
(excepte el de la posició) i, a continuació, combina els camps de la vista pare amb
els de la vista heretada i estableix la posició de les noves etiquetes a partir dels
següents valors:
• inside (per defecte): els valors s’afegeixen “dins” de l’etiqueta.
• after: afegeix el contingut després de l’etiqueta.
• before: afegeix el contingut abans de l’etiqueta.
• replace: reemplaça el contingut de l’etiqueta.

Per a reemplaçar el contingut d’un element camp s’utilitza la següent plantilla:

2 <field name="camp" position="replace">
3 <field name="nou_camp" ... />
4 </field>
5 </field>
Per esborrar un camp d’una vista s’utilitza un element buit amb l’atribut
position="replace":

2 <field name="camp" position="replace"/>
3 </field>
Per afegir camps dins de l’element especificat d’una vista s’utilitzen els valors
inside, after o before. Les següents plantilles mostren com s’inseriria
nou_camp abans i després de camp:

2 <field name="camp" position="before">
3 <field name="nou_camp" .../>
4 </field>
5 </field>

2 <field name="camp" position="after">
3 <field name="nou_camp" .../>
4 </field>
5 </field>
Per efectuar canvis en més d’un lloc, cal combinar les plantilles anteriors dins un
element data:
1 <field name="arch"type="xml">
2 <data>
3 <field name="camp1" position="after">
4 <field name="nou_camp1"/>
5 </field>
6 <field name="camp2" position="replace"/>
7 <field name="camp3" position="before">
8 <field name="nou_camp3"/>
9 </field>
10 </data>
11 </field>
En vistes complexes o heretades d’altres vistes pot ser complicat identificar el

camp a partir del qual aplicar els valors inside, after, before o replace.
Penseu, per exemple, que es podria donar el cas que aparegués un camp amb el
mateix nom en dos llocs diferents de la mateixa vista. Quan això passa es pot
utilitzar l’element xpath per descriure amb exactitud la ruta d’etiquetes XML
fins arribar a l’etiqueta en la qual cal realitzar els canvis.
1.1.3 Herència en el controlador
L’herència en el controlador és un mecanisme conegut, ja que l’apliquem de forma

inconscient quan ens veiem obligats a sobreescriure els mètodes de la capa ORM
d’OpenObject en el disseny de molts mòduls. Funció super()
El llenguatge Python recomana
L’efecte de l’herència en el controlador es manifesta únicament quan cal so- utilitzar la funció super() per
invocar el mètode de la classe
breescriure algun dels mètodes de l’objecte del qual es deriva i per a fer-ho base quan s’està sobreescrivint
en una classe derivada, en lloc
adequadament cal tenir en compte que el mètode sobreescrit en l’objecte derivat: d’utilitzar la sintaxi
nomClasseBase.metode(self...).
• A vegades vol substituir el mètode de l’objecte base sense aprofitar-ne cap

funcionalitat: el mètode de l’objecte derivat no invoca el mètode sobreescrit.
• A vegades vol aprofitar la funcionalitat del mètode de l’objecte base: el

mètode de l’objecte derivat invoca el mètode sobreescrit.
1.1.4 Exemple d’herència
L’organització Empresa_IOC, gestionada amb un OpenERP estàndard amb el

mòdul base_contact activat, té la imperiosa necessitat de poder introduir el color
d’ulls dels contactes dels tercers (partners).
Per aquest motiu, l’equip informàtic d’Empresa_IOC, molt assenyadament, de-

cideix no modificar els mòduls on radica el disseny de l’objecte res.partner
per no perdre les modificacions en qualsevol actualització de l’OpenERP i
dissenya un mòdul particular que implementa el nou requeriment, anomenant-lo
ioc_contact_eye_color. El prefix ioc permet identificar, de manera ràpida,
els mòduls que ha desenvolupat Empresa_IOC per a la seva organització.
En el nou mòdul s’ha decidit incorporar:
• La definició de l’objecte ioc.color per possibilitar la introducció dels

diversos colors d’ulls que poden tenir els contactes dels tercers.
• A la pestanya Informació Extra de la vista form dels contactes, el camp Eye

color per permetre assignar el color d’ulls al contacte.
• A la pestanya General de la vista form dels tercers (clients i/o proveïdors)

el camp Eye color, de només lectura, després del camp Funció (function).
• A més, aprofitarem per tal que el camp Website de la pestanya General de la

vista form dels contactes, possibiliti navegar a l’adreça continguda, fet que
la versió 6.1 d’OpenERP no permet.
Per últim, s’ha decidit que no és necessari incorporar un formulari específic per
donar d’alta els colors ni una opció de menú a l’apartat de configuració, ja que en el
camp que hem afegit en el formulari de contactes, OpenERP facilita un formulari

Trobareu el mòdul automàtic per gestionar els colors (altes, baixes i modificacions).
ioc_contact_eye_color
dins l’apartat “Mòduls
OpenERP i fitxers
auxiliars” dels annexos del
web.
1.2 Definició de la seguretat
L’apartat Settings de qualsevol empresa OpenERP conté dos apartats vinculats

amb la seguretat en OpenERP: Usuaris (amb els subapartats Usuaris i Grups) i
Seguretat (amb els subapartats Regles de registres i Llista de controls d’accés).
Des d’aquests apartats, un usuari d’OpenERP, amb privilegis d’administració
sobre l’empresa (usuari admin o similar) pot definir l’estratègia de seguretat que
correspongui a l’empresa.
Els mòduls que s’instal·len en OpenERP poden incorporar un esquema de segure-

tat que defineix, com a mínim, grups de privilegis sobre els objectes dels mòduls,
objectes que es poden veure a l’apartat Settings | Usuaris | Grups. A la seva vegada,
cada grup de privilegis pot tenir associat un conjunt d’usuaris d’OpenERP. La
figura 1.2 mostra els grups de privilegis que té assignats l’usuari demo d’OpenERP,
que es crea en cas d’instal·lar l’empresa amb dades de demostració.
F igu r a 1. 2 . Grups de privilegis assignats a l’usuari demo d’OpenERP
La figura 1.2 correspon a una sessió de l’usuari admin en la qual podem observar
que hi ha set mòduls instal·lats, corresponents a les pestanyes de la part superior,
més l’opció Settings. Observem com la pestanya Permisos d’accés conté set
apartats a la zona Application, un per cada mòdul instal·lat excepte pel mòdul
School. Les zones Usability i Altre tampoc tenen cap referència al mòdul School.
Si obrim una sessió amb l’usuari demo comprovarem que no li apareix el mòdul
School, tot i estar instal·lat a l’empresa.
En instal·lar un mòdul que no incorpori un sistema de seguretat, aquest mòdul

únicament és accessible per l’usuari admin, encara que l’instal·li un altre usuari
que tingui privilegis de configuració. Llavors, l’usuari admin haurà de crear
manualment els grups de privilegis que cregui adequats sobre els objectes del
mòdul i assignar-los als usuaris que corresponguin.
La majoria de mòduls incorporen un esquema de seguretat que pot ser més o

menys sofisticat. La figura 1.2 ens mostra el grup de privilegis que té assignat
l’usuari demo per a cada mòdul instal·lat (apartats Application). L’apartat Settings
| Usuaris | Grups ens mostra la llista de tots els grups de privilegis definits
per als mòduls instal·lats (figura 1.3). Fixem-nos en la jerarquia existent en
els grups de privilegis definits (categoria/nomGrup). La llista de la figura 1.3
(incompleta) mostra: dos grups de privilegis (Permisos d’accés i Configuració)
sota la categoria Administració (Settings), dos grups de privilegis (User – Own
Leads Only i Manager) sota la categoria Sales Mamangement (mòdul Vendes),
i així successivament. Cadascuna de les categories sota les quals s’aixopluguen
diversos grups de privilegis es corresponen amb els apartats de la zona Application
de la figura 1.2. A la figura 1.2, si despleguem la llista que acompanya la categoria
Sales Management, hi veiem els dos grups de privilegis de la figura 1.3 sota Sales
Management.
F ig ur a 1. 3. Grups de privilegis definits per als mòduls instal·lats en una empresa d’OpenERP
El nostre interès se centra, en aquest moment, en saber com incorporar esquemes

de seguretat en els mòduls que dissenyem, de manera que quan s’instal·lin ja hi
hagi, com a mínim, un grup de privilegis definit, per tal que l’administrador només
hi hagi d’assignar els usuaris.
Un esquema de seguretat bàsic d’un mòdul d’OpenERP es defineix en dos fitxers

que s’acostumen a situar (no és obligatori) en una carpeta anomenada security i
que han de ser referenciats des de l’apartat update_xml del fitxer __openerp__.py
del mòdul. Aquests fitxers són:
• Fitxer XML que conté la definició dels grups (i de forma opcional: usuaris,
menús i regles de negoci assignats a cada grup) que acostuma a anomenar-se
nomModul_security.xml.
• Fitxer CSV que conté els privilegis de cada grup sobre els diferents objectes
del mòdul i que s’anomena obligatòriament ir.model.access.csv. Aquest
fitxer podria ser en format XML (llavors podria tenir qualsevol nom), però,
a causa que la informació que conté es correspon amb el contingut d’una
taula que sempre té el mateix format, és molt més senzill que sigui CSV ja
que es pot emplenar ràpidament amb qualsevol full de càlcul.
El fitxer nomModul_security.xml ha de seguir una plantilla com la següent, que

inclou un element record per cadascuna de les definicions que pot contenir el
fitxer i que serà diferent segons el tipus de definició (grup o usuari, menú, regla
assignada a un grup).
1 <?xml version="1.0" encoding="utf−8"?>

2 <openerp>
3 <data noupdate="1">
4 <record id="idGrup" model="res.groups">
5 <field name="name">nomGrup</field>
6 <field name="category_id" ref="..."/>
7 <field name="implied_ids" eval="..."/>
8 <field name="users" eval="..."/>
9 </record>
10 <record id="idUser" model="res.users">
11 <!−− Crea/Modifica l’usuari "idUser"
12 tot assignant−li grups −−>
13 </record>
14 <record id="idMenu" model="ir.ui.menu">
15 <!−− Crea/Modifica el menú "idMenu"
16 tot assignant−li grups −−>
17 </record>
18 <record id="idRegla" model="ir.rule">
19 <!−− Definició de regles de negoci i assignació
20 a grups i/o companyies −−>
21 </record>
22 </data>
23 </openerp>
L’atribut noupdate de l’element data acostuma a tenir el valor 1 per indicar que
en cas d’actualització de mòdul no s’instal·li l’esquema de seguretat que incorpora
el mòdul, ja que podria sobreescriure l’esquema configurat per l’administrador
de l’empresa, i el valor 0 per tal que s’instal·li sempre, sobreescrivint l’esquema
existent. En cas que hi hagi parts de l’esquema de seguretat que no s’hagin de
sobreescriure i altres que sí, es separen en dos elements data diferents, un amb
noupdate="1" i l’altre amb noupdate="0".
La plantilla anterior incorpora quatre tipus d’element record diferents. Posem

especial atenció amb els que corresponen al model res.groups, que permeten
definir els grups i al model ir.ui.menu, que permet assignar menús a un grup,
cosa que també es pot aconseguir des de la definició de menús. La resta de tipus
d’elements record són complicats per una introducció al disseny d’esquemes de
seguretat en OpenERP.
L’atribut id de l’element record del model res.groups, que ha de ser únic dins
el mòdul, és un identificador XML per al grup, al qual es pot fer referència des
del propi mòdul a través del seu nom o des de qualsevol altre mòdul a través de la
sintaxi nomMòdul.identificador. Els atributs id dels elements record que no
són del model res.groups poden ser nous (provocaran la creació d’un nou recurs)
o existents (provocaran la seva modificació). Si ja existeixen i estan declarats en
altres mòduls, cal introduir el nom del mòdul com a prefix: nomMòdul.idRecurs.
El valor de l’element field amb atribut name="name" és el nom del grup que es
mostra a Settings | Usuaris | Grups.
El valor de l’element field amb atribut name="category_id" és per ubicar el

grup per sota d’una categoria, que ha d’estar definida en el mateix mòdul o en un
altre i que cal indicar a l’atribut ref. Per definir una nova categoria cal utilitzar
l’element:
1 <record id="idCategoria" model="ir.module.category">

2 <field name="name">nomCategoria</field>
3 <field name="description">descripció</field>
4 <field name="sequence">seq</field>
5 </record>
El valor de l’element field amb atribut name="implied_ids" és per indicar que

la pertinença al grup suposa la pertinença automàtica als grups indicats a l’atribut
eval, seguint la sintaxi:
1 eval="[(4,ref(’idGrup1’)),
2 (4,ref(’idGrup2’)),
3 ...
4 ]"
L’escassa documentació
sobre les combinacions
Els grups de privilegis de cadascuna de les categories de l’apartat Application de que OpenObject facilita
per poder assignar
la figura 1.2 tenen definida aquesta relació d’inclusió. Així, a la categoria Sales recursos existents en
relacions one2many o
Management el grup User - All Leads inclou el grup User - Own Leads Only i el many2many es troba, en
OpenERP 6.1, a partir de
grup Manager inclou el grup User - All Leads. S’acostuma a anomenar Manager la línia 3807 del fitxer
pathServer/openerp/osv
el grup de privilegis que conté privilegis totals sobre tots els objectes del mòdul. /orm.py.
Si entre els grups d’una categoria es dóna una relació d’inclusió com A ⊃ B ⊃
C ⊃ ... no existirà mai la necessitat d’assignar a un usuari més d’un grup de
privilegis. En tal situació, OpenERP ubica la categoria a la que pertanyin els grups
de privilegis, a l’apartat Application (figura 1.2) en la posició que indiqui l’atribut
sequence de la categoria. En canvi, si no tots els grups de la categoria estan
relacionats sota una relació d’inclusió com A ⊃ B ⊃ C ⊃ ... OpenERP ubica
la categoria amb tots els seus grups de manera similar a la categoria Usability de
la figura 1.2 que permet assignar diversos grups a un mateix usuari. Així, si els
grups no s’assignen a cap categoria, OpenERP ubica els grups a la zona Altre de
la figura 1.2.
El valor de l’element field amb atribut name="users" és per assignar al grup

un o diversos usuaris dels que es coneix l’identificador XML, seguint la sintaxi:
1 eval="[(4,ref(’idUsuari1’)),
2 (4,ref(’idUsuari2’)),
3 ...
4 ]"
Per exemple, per assignar l’usuari admin a un grup, caldria escriure:
1 eval="[(4, ref(’base.user_root’))]"/>
Fixem-nos que per referir-nos a l’usuari admin, escrivim base.user_root, ja que

l’usuari admin està definit en el mòdul base amb l’identificador user_root.
El fitxer ir.model.access.csv conté la informació dels privilegis assignats a cada

grup sobre la totalitat dels objectes del mòdul. La primera línia conté, obligatòri-
ament, el títol de les columnes:
1 "id","name","model_id:id","group_id:id","perm_read","perm_write","perm_create",
"perm_unlink"
Les següents línies contenen les diverses assignacions de privilegis. Cal saber
que:
• id és un identificador a decidir, que ha de ser únic i que no pot contenir cap

punt.
• name és un nom que descriu el privilegi (pot contenir punts).
• model_id:id és el nom de l’objecte del model sobre el qual s’aplica

el privilegi i ha d’anar precedit, forçosament, pel prefix model_. Si
s’aplica sobre un objecte definit en un altre mòdul, cal utilitzar el prefix
nomMòdul.model_.
• group_id:id és l’identificador del grup de privilegis (definit en el fit-

xerXML previ).
• perm_read, perm_write, perm_create i perm_unlink són valors 0/1

per indicar, respectivament, privilegis de lectura, escriptura, creació i
eliminació sobre l’objecte.
La incorporació de línies en el fitxer ir.model.access.csv és molt fàcil amb la

utilització de LibreOffice Calc.
És fonamental, en la definició dels grups i privilegis, que si es fa referència a

una categoria o grup, aquests hagin estat prèviament definits. Per tant, la inclusió
del fitxer ir.model.access.csv en el fitxer __openerp__.py ha de ser posterior a la
inclusió del fitxer nomModul_security.xml.
A l’apartat “Mòduls
OpenERP i fitxers
Exemple d’utilització d’esquema de seguretat en el mòdul school
web, trobareu la versió 12
del mòdul school a l’arxiu
school_12.zip. Interessa incorporar un esquema de seguretat en el vigent mòdul school (versió school_12)
que creï una categoria de nom School que contingui dos grups de privilegis: Manager, amb
permisos totals sobre tots els objectes del mòdul i Subscriptions, amb permisos adequats
per poder assignar estudiants als cursos. Cal assignar l’usuari admin al grup Manager.
Si instal·leu la versió 13 del mòdul school podreu comprovar com a la llista de categories
sota l’apartat Application de la figura 2 hi apareix la nova categoria School amb dos grups
de privilegis (Manager i Subscriptions). Podreu comprovar que l’usuari admin té assignat
el privilegi Manager i que cap altre usuari té assignat cap privilegi.
Si observeu el contingut de la versió 13 del mòdul school veureu que el fitxer

school_security.xml incorpora la definició de la categoria School amb els dos grups
Manager i Subcriptions. Podeu observar que el grup Manager inclou tots els privilegis del
grup Subscriptions i que, a més, té assignat l’usuari admin.
Assigneu el grup de privilegis Subscriptions a l’usuari demo i procediu a obrir una sessió
amb aquest usuari per efectuar subscripcions d’alumnes als cursos. Observeu que,
d’entrada, només veu els menús que contenen opcions que gestionen objectes als quals té
algun privilegi d’accés: Configuration | Courses amb permís de lectura als cursos i Students
amb permisos per modificar el contingut d’estudiants i assignar-los cursos dels existents
(vegeu les dues darreres línies de privilegis del fitxer ir.model.access.csv). Observeu,
també, que per tal que el grup de privilegis Subscriptions permeti assignar cursos als
estudiants, és necessari facilitar-li permís de lectura sobre els cursos.
school a l’arxiu
school_13.zip dins
OpenERP i fitxers
web.
1.3 Càrrega de dades
A vegades cal poder executar una càrrega massiva de dades en els objectes
d’un mòdul. Algunes d’aquestes ocasions poden ser les migracions de dades
en l’arrencada d’un OpenERP quan se substitueix un sistema informàtic; o bé la
càrrega de dades de demostració quan s’instal·la qualsevol mòdul, si en el procés
de creació de l’empresa es va indicar la càrrega de dades de demostració; i també
la incorporació de dades inicials per al funcionament del mòdul.
En tots els casos és important efectuar la càrrega a través dels mecanismes facilitats
per OpenERP i no intentar, de cap de les maneres, la introducció de dades a través
d’instruccions SQL directes a la base de dades, ja que fent-ho a través d’OpenERP
tindrem la seguretat que la lògica de negoci s’aplica en totes les operacions.
OpenERP permet preparar les dades a carregar en fitxers CSV i en fitxers XML.
La principal diferència entre ambdós mètodes és que un fitxer CSV només permet
la introducció de recursos (registres) d’un mateix objecte (taula), mentre que un
fitxer XML permet la introducció de dades que afecten a diversos objectes (taules).
Pels fitxers CSV, el nom del fitxer ha de coincidir amb el nom de l’objecte (taula)
on s’afegiran/actualitzaran els recursos (registres). La seva primera línia ha de
contenir, obligatòriament, els noms dels camps de cada columna, i les següents
línies han de contenir les dades dels recursos que s’han d’introduir. Un exemple
és el fitxer ir.model.access.csv de la carpeta security dels mòduls que incorporen
un esquema de seguretat.
Els fitxers XML segueixen una plantilla com la següent, en la qual cada element
record conté les dades d’un recurs i el model al qual pertany, podent incorporar
dades de recursos de diversos models.

2 <openerp>
4 <record id="idRecurs" model="nomObjecte">
5 <field name="camp1">valor</field>
7 ...
8 </record>
9 <record id="idRecurs" model="nomObjecte">
12 ...
13 </record>
14 ....
15 </data>
16 </openerp>
L’atribut noupdate de l’element data acostuma a tenir el valor 1 per indicar

que en cas d’actualització del mòdul no es carreguin les dades ja que podria
sobreescriure les dades ja existents, i el valor 0 per tal que s’instal·li sempre,
sobreescrivint les dades existents. En cas que hi hagi parts de la càrrega de dades
que no s’hagin de sobreescriure i altres que sí, se separen amb dos elements data
diferents, un amb noupdate="1" i l’altre amb noupdate="0".
L’atribut id de cada element record que ha de ser únic dins el mòdul, és

un identificador XML per al recurs, al qual es pot fer referència des del propi
mòdul a través del seu nom o des de qualsevol altre mòdul a través de la
sintaxi nomMòdul.identificador. Un exemple d’aquesta utilització el trobem
quan necessitem fer referència, en algun lloc, a l’usuari admin, que escrivim
base.user_root, ja que l’usuari admin està definit en el mòdul base amb
identificador user_root.
Els fitxers amb dades de demostració a carregar (siguin CSV o XML) s’han
d’indicar a l’apartat demo_xml del fitxer __openerp__.py del mòdul. Els fitxers
amb dades a carregar únicament en la instal·lació del mòdul (siguin CSV o XML)
A l’apartat “Mòduls s’han d’indicar a l’apartat init_xml del fitxer __openerp__.py del mòdul.
OpenERP i fitxers
web trobareu el fitxer Exemple de càrrega de dades de demostració en el mòdul school
school_dades.xls.
Interessa incorporar un conjunt de dades de demostració en el vigent mòdul school (versió
school_13) i el cap d’estudis d’un centre educatiu que ens vol ajudar, ens facilita informació
en el fitxer school_dades.xls, que conté:
• Un full de càlcul anomenat Organització, amb tota la informació organitzativa sobre tres
cicles formatius de la família professional d’Informàtica i comunicacions, amb els mòduls de
cada cicle, les seves hores, la seva ubicació a primer o a segon curs, el nom del professor
responsable de cada mòdul, amb el tipus de contracte (nomenat – interí) que assimilarem als
conceptes que admet el camp Contract de l’objecte Professor del mòdul school (named –
trainee). També conté dues columnes Categoria i Subcategoria corresponents al tipus de
matèria dels mòduls, que no hem d’utilitzar.
• El full de càlcul Alumnat que conté les dades dels alumnes matriculats a cadascun dels cicles
indicats en el full de càlcul anterior.
Per practicar els dos tipus de fitxers (CSV i XML) per introduir les dades de demostració,
decidim utilitzar un fitxer XML per a les dades corresponents a cursos (cada mòdul de cada
cicle el considerarem un curs) amb els seus professors i un fitxer CSV per introduir les
dades corresponents als alumnes i als cursos assignats, considerant que un alumne ha de
tenir assignats els cursos corresponents als mòduls del cicle-curs en el qual està matriculat.
En la introducció de professors, decidim que tots ells dediquen 20 hores a la docència i que
tots tenen per Associated Partner la companyia principal de l’empresa (Empresa_IOC).
La introducció de dades en el fitxer XML (professors i cursos) es pot fer manualment, amb
un editor de textos pla, i no té gaire sentit muntar cap procés que, a partir del full de càlcul
Organització generi el fitxer XML. Seria més costós muntar el procés que no pas introduir
manualment les dades. Per aconseguir assignar la companyia principal de l’empresa a
cada professor, anem a cercar al mòdul base, l’identificador XML de la companyia principal,
que resulta ser main_company.
La introducció de dades en el fitxer CSV (estudiants i cursos assignats) és difícil de dur a

terme manualment, a causa del volum d’informació que es genera i, en aquest cas, és més
adequat cercar la manera de generar el fitxer CSV a partir dels fulls de càlcul Organització
i Alumnat facilitats. Qualsevol programador té suficients recursos d’utilització dels fulls de
càlcul per, a partir dels fulls facilitats, aconseguir un fitxer com school_auxiliar.xls, a partir
del qual copiar els valors de les columnes H-L (només els valors, no les fórmules) en un
nou full de càlcul per enregistrar-lo en format CSV.
La versió 14 del mòdul school es correspon a la versió millorada incorporant les dades de
demostració aquí descrites. Per instal·lar-la, procediu prèviament a desinstal·lar la versió
existent i instal·leu-la de nou, no actualitzant, ja que les dades de demostració només es
carreguen en el procés d’instal·lació.
Observeu com, en el fitxer CSV, destinat a incloure els estudiants, s’indica, en una columna
(course_ids:id) el conjunt de cursos que té assignat cada estudiant.
Per últim, cal comentar com seria un fitxer XML per a la inclusió dels estudiants, ja que per
cada estudiant cal introduir el conjunt de cursos assignats. El contingut hauria de seguir la
plantilla:

2 <openerp>
4 <record id="idStudent" model="school.student">
5 <field name="idnum">valor</field>
6 <field name="surname">valor</field>
7 <field name="name">valor</field>
8 <field name="course_ids" eval=
9 "[(4,ref(’idCurs1’)),(4,ref(’idCurs2’)),...]"/>
10 </record>
11 </data>
12 </openerp>
Podeu trobar el fitxer
school_auxiliar.xls i la
versió 14 del mòdul
school (arxiu
school_14.zip) dins
OpenERP i fitxers
1.4 Programació d’assistents web.
Un assistent informàtic (wizard en anglès) és un programa pensat per abreujar o

canalitzar els passos a seguir per dur a terme una tasca o, com a mínim, explicar els
passos detalladament. En moltes ocasions s’utilitza per guiar als usuaris inexperts.
En OpenERP, un assistent és una successió de passos. Cada pas es composa de

diverses accions:
• Mostra un formulari a l’usuari amb alguns botons.
• Recupera la informació introduïda per l’usuari i el botó seleccionat.
• Executa les accions que corresponguin.

• Envia una nova acció al client (formulari, informe...).
Per crear un assistent, cal definir un objecte OpenERP que no es fa persistent en

el SGBD PostgreSQL, fet que s’aconsegueix fent que la classe Python que crea
l’objecte OpenERP derivi de la classe osv.osv_memory en lloc de derivar de la
classe osv.osv. La classe Python es defineix en un fitxer .py i la vista formulari
es defineix en un fitxer XML, de forma similar a les classes que defineixen els
objectes persistents d’OpenERP.
Els fitxers .py i XML corresponents als assistents d’un mòdul s’acostumen a
ubicar en una carpeta anomenada wizard situada dins la carpeta del mòdul. El
fitxer __init__.py del mòdul ha de contenir una sentència import wizard i la
carpeta wizard ha de contenir un fitxer __init__.py amb la sentència import per
al fitxer .py que conté les classes necessàries per a l’assistent. Els fitxers XML
de l’assistent, ubicats normalment dins la carpeta wizard, han de ser referenciats
des de l’apartat update_xml del fitxer __openerp__.py del mòdul.
Ja que els assistents defineixen una seqüència de passos, la classe que en defineix el
model acostuma a tenir el camp especial state, de tipus selection, que permet
definir els diversos estats pels quals passa l’assistent. El contingut d’aquest camp
s’acostuma a utilitzar en la vista formulari per fer visibles i/o invisibles altres
camps en funció del seu valor, de manera que l’usuari té la percepció que hi ha
una successió de pantalles quan, en molts casos, és la mateixa però amb camps
que canvien el seu estat de visibilitat.
Exemple de disseny d’un assistent en el mòdul school
Interessa incorporar uns assistents, en el vigent mòdul school (versió school_14), que
permeti omplir el camp First Date d’alguns cursos existents (o de tots), amb una data
introduïda per l’usuari.
En el menú School | Configuration es vol habilitar una nova opció de menú, de nom Wizards,
que contingui dues opcions:
• Assignació d’una First Date comuna per tots els cursos, que ha de permetre que l’usuari
introdueixi la data a assignar a tots els cursos existents a l’empresa, tinguin o no data
introduïda.
• Assignació d’una First Date comuna per cursos filtrant per nom, que ha de permetre que
l’usuari introdueixi la data a assignar a tots els cursos que el seu nom contingui un determinat
text introduït per l’usuari.
En qualsevol cas, el procés ha de facilitar dos botons: Cancel, per cancel·lar el procés i
Assign, per procedir a l’assignació. En cas d’executar l’assignació, l’assistent ha de mostrar
una pantalla en la qual s’informi del nombre de cursos actualitzats amb un únic botó Close
per tancar l’assistent.
La versió 15 del mòdul school es correspon a la versió millorada incorporant els assistents
indicats. Observeu que conté una carpeta wizard amb els nous fitxers .py i XML.
El fitxer school_manage_course_date.py conté la definició de la classe no persistent

school_manage_course_date que incorpora quatre camps: new_date per recollir la data
que l’usuari vol assignar als cursos; info_updates per mostrar el nombre de cursos
actualitzats; course_name per recollir el text que ha de contenir el nom en el segon assistent
demanat; i el camp state amb dos possibles valors (Init i Done) per distingir l’estat en el
qual es troba el procés. Tot i que es demana dos assistents, com que són molt similars,
ens serveix la mateixa classe school_manage_course_date per ambdós.
La classe school_manage_course_date incorpora dos mètodes:

assign_course_date_all, que actualitza tots els cursos a partir de la data existent
en el camp new_date del formulari, i assign_course_date_name, que actualitza els cursos
el nom dels quals conté el contingut del camp course_name del formulari, amb la data
existent en el camp new_date del formulari.
El fitxer school_manage_course_date_view.xml conté la definició dels menús indicats, amb

les accions corresponents i les dues vistes (una per cada assistent). Les dues vistes es
basen en el model school.manage_course_date i es diferencien en els camps que mostren
(la corresponent al segon assistent, a diferència de la del primer assistent, mostra el camp
course_name) i en el mètode que executa el botó Assign. Fixeu-vos que, per cadascuna
de les vistes, s’aconsegueix l’aparença de dues pantalles diferents, a partir de la visibilitat
i invisibilitat dels diferents camps i botons. La visibilitat es modifica a partir de l’estat en el
qual es troba l’assistent.
El nou menú wizards s’ha assignat únicament al grup d’usuaris group_school_manager.
La versió 15 incorpora, en les vistes, a la part inferior esquerra, el camp state per tal que
puguem veure com canvia el seu valor segons el moment en el qual es troba l’assistent.
En la situació presentada, no té gaire sentit que el camp state sigui visible, però com que
en altres casos sí que en pot tenir, l’hem incorporat per a veure’n la seva utilització, amb
widget="statusbar".
Per últim, una observació important sobre el contingut dels mètodes de la classe
school_manage_course_date invocats pel botó Assign de les dues vistes. Fixeu-vos que
aquests mètodes criden en dues ocasions el mètode write:
• Una, sobre l’objecte course_obj que gestiona els recursos del model school.course,
indicant-li el conjunt de cursos a actualitzar (course_ids) i els camps a modificar (values):
1 values = {’date’:new_date}
2 course_obj.write(cr, uid, course_ids, values)
• L’altra, sobre l’objecte self, és a dir, sobre l’objecte vinculat al formulari actiu, per actualitzar
el contingut dels camps info_udpates i state del formulari i així aconseguir, en el formulari,
la transició de la pantalla en què es demana la nova data (state=’init’) a la pantalla en què
s’informa del nombre de cursos actualitzats (state=’done’):
1 values = {’state’:’done’,’info_updates’:len(course_ids),}
2 self.write(cr, uid, ids, values)
Podeu trobar la versió 15
del mòdul school (arxiu
Persistència del model dels assistents en versions 6.1 i 7.0 d’OpenERP school_15.zip) dins
La documentació d’OpenERP afirma que el model que defineix un assistent, en derivar de OpenERP i fitxers
la classe osv.osv_memory, no es fa persistent a la base de dades, com ha de ser, ja que auxiliars” dels annexos del
web.
no té cap sentit emmagatzemar les dades que l’usuari introdueix en l’assistent.
Les versions 6.1 i 7.0 d’OpenERP, però, fan persistents els models que deriven de la
classe osv.osv_memory i les corresponents taules van enregistrant els valors introduïts pels
usuaris en els assistents, fet que és totalment anòmal. Fins la versió 6.0 el funcionament
era com ho documenta OpenERP. Sembla que és un error de les versions 6.1 i 7.0, ja que
és una persistència mancada de sentit.
1.5 Traducció
OpenERP facilita mecanismes de traducció que permeten obtenir versions idiomà-

tiques de l’aplicació. En la creació d’una empresa en OpenERP, l’administrador
d’OpenERP decideix l’idioma inicial en el qual s’instal·la l’empresa i l’empresa

incorpora, d’entrada, l’idioma seleccionat i l’anglès. Una vegada l’empresa ha
estat creada, l’administrador pot afegir nous idiomes a través de l’opció Settings
| Traduccions | Carrega una traducció oficial. Els usuaris de l’empresa poden
escollir el seu idioma (d’entre els idiomes instal·lats) des de l’opció Preferences
Les traduccions dels que proporciona el client que utilitzen (web o GTK).
mòduls oficials i del client
GTK es mantenen amb
l’eina de traducció L’idioma base d’OpenERP és l’anglès i, per això, es recomana que el desenvolu-
col·laborativa que
proporciona Launchpad: pament s’efectuï en anglès per, posteriorment, traduir el mòdul als idiomes que
translations.launchpad.net
/openobject interessi.
El procés d’instal·lació o actualització d’un mòdul en una empresa, instal·la el

mòdul en els idiomes que l’empresa té activats, sempre que el mòdul incorpori
les corresponents traduccions. Les traduccions que incorpora un mòdul estan
ubicades a la subcarpeta i18n de la carpeta del mòdul i són un conjunt de fitxers
amb extensió .po i nom identificador de l’idioma. Podeu comprovar-ho en
En informàtica s’acostuma a qualsevol dels mòduls oficials que facilita OpenERP.
utilitzar el numerònim i18n
per a la paraula
internationalization a causa
que entre la primera i i la
Les versions 6.x d’OpenERP utilitzen la codificació ISO 639-1
darrera n hi ha 18 caràcters. (ca.wikipedia.org/wiki/ISO_639-1) per als noms dels idiomes, de manera
que el fitxer ca.po correspon a la traducció al català i el fitxer es.po correspon a
la traducció al castellà. Per les variants d’un idioma en funció del país, s’utilitza
la codificació xx_XX on xx correspon al codi de l’idioma i XX correspon al codi
ISO 3166-1 alfa-2 (ca.wikipedia.org/wiki/ISO_3166-1). de manera que el fitxer
es_AR.po correspon a la traducció a l’idioma espanyol d’Argentina i es_ME.po
correspon a la traducció a l’idioma espanyol de Mèxic.
Per procedir a la traducció d’un mòdul que s’hagi elaborat en anglès, cal seguir
els següents passos:
1. Tenir instal·lat, en una empresa, el mòdul a traduir.
2. Extreure, des d’OpenERP, per l’opció Settings | Traduccions | Importa-

Exporta | Exporta traducció, tal com mostra la figura 1.4, tot indicant
l’idioma Anglès (si el mòdul està desenvolupat en anglès, seguint les
recomanacions), el format PO i el mòdul a traduir. L’eina d’extracció permet
seleccionar altres formats, que no ens són interessants i permet exportar
diversos mòduls, cosa que tampoc ens interessa perquè executa l’exportació
en un únic fitxer PO i ens n’interessa un per a cada mòdul.
3. Enregistrar el fitxer resultant amb el nom del mòdul i extensió .pot a la

subcarpeta i18n del mòdul. El fitxer .pot és el fitxer que conté els textos que
OpenERP ha extret del mòdul i que traduirem als idiomes que ens interessi.
4. Per cada idioma al que vulguem traduir el mòdul, s’ha de copiar el fitxer
nomModul.pot a un fitxer isoIdioma.po dins la mateixa carpeta i18n.
5. Traduir el contingut de cada fitxer isoIdioma.po a l’idioma que correspon-

gui.
6. Executar el procés d’actualització del mòdul, que carregarà les traduccions

existents.
Figur a 1. 4. Pantalla d’exportació de textos d’un mòdul per a la seva traducció
Els fitxers .po són fitxers de text pla que es poden editar amb qualsevol editor de
textos. Un expert en fitxers .po podria efectuar la traducció amb qualsevol editor
de textos, però si hem generat l’exportació en un fitxer .po en lloc d’un fitxer
CSV, que és més fàcil d’editar, és perquè hi ha eines de traducció, com Poedit
(www.poedit.net) que gestionen fitxers .po i que faciliten moltes funcionalitats.
Abans de procedir a la traducció de cap mòdul a una llengua, és molt important

tenir una guia d’estil, i més en una aplicació com OpenERP, formada per una
gran quantitat de mòduls i en la qual hi col·laboren nombroses persones. Així, us
recomanem: Podeu consultar la guia
d’estil de Softcatalà a
www.softcatala.org/wiki
/Rebost:Guia_d’estil
_de_Softcatalà, i la guia
d’estil d’OpenERP a
code.google.com/p/tinyerp-
community/wiki/Traduccion
• La guia d’estil de Softcatalà, genèrica per a la traducció al català de _es_ES.
productes informàtics.
• La guia d’estil d’OpenERP, per a la traducció de l’OpenERP al castellà.
Exemple de com traduir les formes verbals
En català, la forma verbal que s’ha d’utilitzar en les situacions en les quals l’usuari s’adreça
a l’ordinador per executar alguna acció (traducció de Cancel, Exit, Close, Assign, Execute...)
és l’imperatiu en segona persona del singular (que correspon al tractament de “tu”, com per
exemple: Cancel·la, Surt, Tanca, Assigna, Executa...), mentre que en castellà és l’infinitiu
(Cancelar, Salir, Cerrar, Asignar, Ejecutar...).
En català, la forma verbal que s’ha d’utilitzar en les situacions en les quals l’ordinador
s’adreça a l’usuari per informar-lo o per fer-li alguna pregunta, és l’imperatiu en segona
persona del plural (que correspon al tractament de “vós”, com per exemple: Seleccioneu,
Voleu, Imprimiu, Assigneu...), mentre que en castellà és l’imperatiu en segona persona del
singular corresponent al tractament de “usted” (Seleccione, Quiere, Imprima, Asigne...).
Amb l’eina Poedit instal·lada, obrim el fitxer .po que interessi i procedim a la seva
traducció. La utilització de l’eina Poedit és molt simple i intuïtiva, com mostra la
figura 1.5.
F igu r a 1. 5 . Interfície del programa Poedit
Entre les funcionalitats que facilita Poedit, cal saber que:
• Permet posar comentaris a cada terme traduït.
• Permet marcar la traducció d’un terme com a difusa quan no n’estem con-
vençuts, de manera que en un altre moment la podem identificar fàcilment.
• Permet saber el punt del mòdul del qual s’ha extret el text, fet que en ocasions
ens pot ajudar a efectuar la traducció del terme en funció del seu context.
• Permet incorporar traduccions d’una nova versió de fitxer .pot al fitxer .po
actual, fet que és molt d’agrair quan es retoca un mòdul pel qual ja hi havia
una traducció efectuada.
del mòdul school,
traduïda al català, en
l’arxiu school_15t.zip, dins L’eina d’extracció de textos d’OpenERP extrau, erròniament, els noms dels
OpenERP i fitxers models que es creen en els fitxers .py, que no hem de traduir.
web.
Exemple de textos extrets per OpenERP que no es poden traduir
Si editeu amb Poedit el fitxer ca.po de l’arxiu school_15t.zip, hi veureu els textos
corresponents als models definits en el mòdul, que no s’ha traduït:
1 school.course
2 school.course.event
3 school.manage.course_date
4 school.professor
5 school.student
Finalment, cal recordar que en l’escriptura de mètodes i funcions en OpenObject,

els textos de missatges inclosos en mètodes i funcions, per poder ser traduïbles
han de ser introduïts amb la sintaxi _(’text’) i el fitxer .py ha de contenir from
tools.translate import _ a la capçalera.
2. Reporting & BI
Les solucions informàtiques per a la gestió comercial (ERP, CRM, HRM...)

incorporen un conjunt predefinit d’informes i quadres de comandament que
acostumen a ser adequats, i potser suficients, per a un nombre important d’or-
ganitzacions. Sempre hi ha, però, organitzacions que necessiten informes i
quadres de comandament diferents dels facilitats per l’aplicació informàtica i
això és també imprescindible quan es dissenyen mòduls que complementen el
programari existent. Així doncs, ens convé disposar d’eines de reporting i
business intelligence (BI) que ens permetin elaborar els informes i quadres de
comandament que l’organització necessiti.
Els programaris de gestió empresarial actuals acostumen a incorporar eines que

faciliten el disseny d’informes i quadres de comandament, integrats en l’aplicació
i elaborats a partir de les dades gestionades pel propi sistema. Podem trobar-nos,
però, en situacions en què calgui accedir a orígens de dades externs, possibilitat
normalment no facilitada per les eines BI del sistema o en casos en els quals el
programari no incorpori eines de reporting i business intelligence. En conseqüèn-
cia, convé conèixer a fons les eines BI que facilita el sistema i les eines BI externes
que complementin i/o substitueixin les del sistema.
2.1 Reporting extern a l’ERP: JasperReports
JasperReports (community.jaspersoft.com/project/jasperreports-library) és un
motor de generació d’informes molt potent, sota llicència LGPL (programari
lliure) proveït per Jaspersoft Corporation i escrit totalment en Java, que presenta
les característiques següents:
• Facilita connectors per un gran nombre d’orígens de dades.
• Permet dirigir els informes cap a pantalla o cap a impressora o cap a fitxer
en múltiples formats (PDF, RTF, XML, XLS, CSV, HTML, XHTML, text,
DOCX o OpenOffice).
• Permet incloure gràfics (de barres, de sectors...) en els informes.
• Permet incloure informes (subinformes) dins altres informes.
• Permet incorporar filtres (paràmetres) en els informes, de manera que en el

moment d’execució l’usuari pot introduir els valors amb què desitja que es
confeccioni l’informe.
• Permet ser incrustat (hostatjat) en aplicacions desenvolupades en diferents

llenguatges, és a dir, des del programa es pot invocar el motor JasperReports
per generar informes. Els llenguatges Java i PHP són un exemple d’aquesta
possibilitat.
Pels programadors té molt
d’interès conèixer un motor
d’informes com
JasperReports que pot ser El motor JasperReports genera l’informe a partir d’un document que conté el
invocat des d’aplicacions
desenvolupades en disseny de l’informe i d’un origen de dades al qual es connecta per anar a cercar
diferents llenguatges.
les dades que bolca a l’informe. Ens convé, doncs, saber elaborar els documents
que contenen el disseny dels informes en el format indicat per JasperReports.
Els documents que contenen el disseny d’un informe per a JasperReports són
fitxers XML amb extensió .jrxml que podrien ser confeccionats amb qualsevol
editor de textos, en cas de ser profunds coneixedors del “llenguatge JRXML”. Per
sort, en el mercat hi ha diferents eines de disseny d’informes per a JasperReports,
que permeten dissenyar els informes des d’una interfície gràfica. Una d’aques-
tes eines és iReport Designer (http://community.jaspersoft.com/project/ireport-
El motor JasperReports designer), proveït per Jaspersoft Corporation.
llegeix el fitxer .jrxml i en fa
una compilació, generant un
fitxer .jasper a partir del L’eina iReport Designer, sota llicència AGPL, facilita una interfície gràfica que
qual genera l’informe
desitjat. L’execució és més permet:
ràpida si es facilita el fitxer
JASPER.
• Dissenyar sofisticats informes que contenen gràfics, imatges, subinformes,

taules i molt més, en formats .jrxml, amb els quals es pot generar el
compilat .jasper.
• Accedir als mateixos orígens de dades que facilita el motor JasperReports

(a través de JDBC, TableModels, JavaBeans, XML, Hibernate, CSV i fonts
personalitzades).
• Generar l’informe (incorpora el motor JasperReports) i publicar-ne el

resultat per pantalla, impressora o en els mateixos formats que facilita el
motor JasperReports (PDF, RTF, XML, XLS, CSV, HTML, XHTML, text,
DOCX o OpenOffice)
Així doncs, disposem d’un motor d’informes (JasperReports) i d’una eina de

disseny d’informes (iReport Designer) des de la qual es poden dissenyar informes
i executar-los. JasperReports i iReport Designer, són útils per a una empresa amb
un sistema de gestió empresarial sempre que l’empresa disposi d’un departament
d’informàtica que desenvolupa programes en llenguatges en els quals es pot
hostatjar el motor d’informes. En cas contrari, el grau d’utilitat baixa en picat,
ja que per executar un informe caldria tenir instal·lat l’iReport Designer, disposar
del disseny de l’informe i dels paràmetres de connexió amb el corresponent origen
de dades i executar l’informe des de l’eina de disseny. És clar que manca una peça:
una aplicació servidora d’informes.
JasperReports Server (http://community.jaspersoft.com/project/jasperreports-

server), proveït per Jaspersoft Corporation, és un servidor d’informes i quadres
de comandament que pot ser executat de forma independent, com un nucli
d’informació per l’organització o incrustat en una aplicació web o mòbil. N’hi ha
dues versions: la professional, de pagament, sota el nom de Jaspersoft 5 Business
Intelligence Suite Enterprise i la comunitària, amb llicència AGPL, sota el nom
de JasperReports Server Community. Ambdues versions faciliten una interfície
web per administrar el servidor i executar els informes i quadres de comandament

allí ubicats. La taula 2.1 recull algunes funcionalitats que diferencien les dues
versions.
Taul a 2. 1. Diferències entre les versions Enterprise i Community de JasperReports Server
Funcionalitat Enterprise Community
Ubicar i executar informes Sí Sí
Definir consultes i vistes Sí Sí
Definir camps de filtre i llistes de Sí Sí

valors
Dissenyar informes Sí No
Dissenyar i executar quadres de Sí No

comandament
Gestionar usuaris, rols i Sí Sí

assignació de privilegis
Gestionar diverses organitzacions Sí No
La terna d’aplicacions formada pel motor d’informes JasperReports,

l’eina de disseny iReport Designer i el servidor JasperReports Server
(Community o Enterprise) pot ser molt útil per a qualsevol organització.
Una empresa que vulgui utilitzar JasperReports Server com a nucli d’informació
en el qual ubicar un conjunt d’informes i quadres de comandament de l’empresa,
amb accés diferenciat segons els usuaris, ha de seguir, com a mínim, els següents
passos:
1. Instal·lar el servidor JasperReports Server (la versió adequada segons les

prestacions requerides) en la màquina que es cregui convenient. No té
perquè ser la mateixa màquina on resideix la base de dades que gestiona
el sistema de gestió empresarial de l’organització, però sí que hauran de ser
visibles per la xarxa, ja que JasperReports Server ha de tenir accés a la base
de dades.
2. Instal·lar iReport Designer en les màquines dels usuaris que hagin de poder
dissenyar informes amb aquesta eina.
3. En el servidor d’informes, crear l’esquema de seguretat (organitzacions, rols

i usuaris) que correspongui i definir els accessos als orígens de dades del
qual s’alimenten els informes.
4. Dissenyar els informes de l’organització amb iReport Designer i pujar-los

al servidor, assignant els permisos d’accés que corresponguin.
5. En el cas de JasperReports Server Enterprise, dissenyar els quadres de

comandament des de la interfície web i assignar-los els permisos d’accés
que corresponguin.
2.1.1 Instal·lació i configuració de JasperReports Server Community

5.0
Ens disposem a instal·lar la versió Community de JasperReports Server en una

màquina Windows per, bàsicament, instal·lar informes basats en la base de dades
d’una empresa d’OpenERP. No hem d’oblidar, però, que podem utilitzar JasperRe-
ports Server per instal·lar informes sobre qualsevol base de dades. JasperReports
Server Community també està disponible per a màquines Linux i Mac.
JasperReports Server necessita, pel seu funcionament, un servidor web Tomcat

i un SGBD PostgreSQL. El paquet d’instal·lació incorpora els dos programaris
(Tomcat i PostgreSQL) i el procés d’instal·lació demana, per cadascun dels
programaris, si es vol que JasperReports n’instal·li la versió incorporada o si es vol
utilitzar una versió ja existent. En cas de voler utilitzar un servidor PostgreSQL
existent, cal que sigui de versió 9.x i que tingui l’usuari de nom postgres com a
superusuari.
Ja que bàsicament utilitzarem JasperReports Server per informes sobre OpenERP i

que les dades de les empreses gestionades per OpenERP resideixen en un servidor
PostgreSQL, és una bona opció instal·lar JasperReports Server a la mateixa
màquina en la qual resideix el servidor PostgreSQL que dóna servei a OpenERP,
per tal d’utilitzar el mateix servidor PostgreSQL. Compte, però, amb la versió de
PostgreSQL, que ha de ser 9.x o superior per a JasperReports Server 5.0. S’ha
de tenir present que la versió de PostgreSQL que instal·la OpenERP 6.1 és la
8.3.4. També es pot indicar al procés d’instal·lació de JasperReports Server que
instal·li l’SGBD PostgreSQL que incorpora en una màquina que ja disposi d’un
PostgreSQL instal·lat, tot indicant-li que escolti per un port diferent del que està
escoltant el PostgreSQL instal·lat.
El procés d’instal·lació segueix els passos següents:
1. Demana si es vol instal·lar el servidor Tomcat incorporat o si es vol utilitzar

un servidor Tomcat existent. Indicarem que instal·li el servidor Tomcat
incorporat.
2. Demana si es vol instal·lar el servidor PostgreSQL incorporat o si es vol uti-

litzar un servidor PostgreSQL existent. Decidirem segons les observacions
anteriors. En cas que decidim utilitzar un PostgreSQL existent, ens informa
que intentarà instal·lar les bases de dades que necessita i en sobreescriurà
qualsevol duplicat. La base de dades que utilitza JasperReports Server
s’anomena jasperserver i la sobreescriuria en cas de trobar-ne una amb el
mateix nom.
3. Demana la configuració dels ports pels quals escoltarà el servidor Tomcat,

proposant els valors 8080 per Tomcat Server Port i 8005 per Tomcat
Shutdown Port. Cal vigilar que no tinguem altres servidors instal·lats que
utilitzin aquests ports. La versió 6.1 d’OpenERP utilitza, si no s’ha indicat
el contrari, els ports 8069 i 8070.
4. En cas que, en el punt 2, haguem decidit utilitzar un PostgreSQL existent,

ens demana:
• El directori en el qual resideixen els programes (subcarpeta bin) de

PostgreSQL (PostgreSQL Binary Directory). En principi, el servidor
PostgreSQL no té perquè residir a la mateixa màquina on estem
instal·lant JasperReports Server, però ha de contenir una còpia de la
carpeta bin del servidor PostgreSQL.
• La IP o nom de la màquina en la qual resideix el servidor PostgreSQL
(127.0.0.1 si és a la mateixa màquina).
• El port pel qual escolta el servidor PostgreSQL (normalment 5432).
• La contrasenya del superusuari postgres del servidor PostgreSQL.
Obligatòriament ha d’existir un superusuari anomenat postgres.
5. En cas que, en el punt 2, haguem decidit instal·lar un nou servidor Post-

greSQL, ens demana el port pel qual ha d’escoltar, proposant 5432. El
servidor PostgreSQL que instal·la té l’usuari postgres com a superusuari
amb contrasenya postgres.
6. Demana si es desitja la instal·lació de bases de dades i informes d’exemple.

En cas afirmatiu, instal·la dues bases de dades anomenades sugarcrm
i foodmart, que serien sobreescrites en cas d’existir (instal·lació en un
PostgreSQL existent). Aconsellem, en una primera instal·lació, respondre
afirmativament, ja que així podrem veure les possibilitats que permeten els
informes dissenyats per JasperReports.
7. Demana si es desitja la instal·lació de l’eina de disseny iReport Designer. Si

volem dissenyar informes des de la mateixa màquina on resideixi JasperRe-
ports Server, és adequat instal·lar-la, tot i que sempre la podrem instal·lar ja
que Jaspersoft Corporation facilita el paquet instal·lador individual d’iRe-
port Designer.
Una vegada executada la instal·lació, podem comprovar que:
• El servidor PostgreSQL (nou o existent) conté la base de dades jasperserver

i, si hem demanat d’instal·lar els exemples, les bases de dades sugarcrm i
foodmart.
• En el panell de control dels serveis de Windows, ha aparegut el servei

jasperreports Tomcat amb tipus d’inici automàtic i, si hem decidit la
instal·lació d’un servidor PostgreSQL, el servei jasperreports PostgreSQL
amb tipus d’inici automàtic.
• En l’arbre de programes de Windows hi trobem les següents opcions:
– Start or Stop Services: amb les opcions per engegar o aturar els serveis
jasperreports instal·lats.
– JasperReports ServerDocumentation: que ens obre una carpeta del
sistema d’arxius en la qual ha instal·lat diversos documents.
– JasperReports Server Login: que porta a la interfície web facilitada

per JasperReport per a tasques administratives i per a execució dels
informes i quadres de comandament ubicats en el servidor
– Jaspersoft Community Website: per navegar al portal de Jaspersoft
Community.
– Jaspersoft Website: per navegar al portal de Jaspersoft Corporation.
– Start iReport Designer: per posar en marxa l’eina iReportDesigner,
en cas d’haver-la instal·lat.
– Uninstall JasperReports Server: per desinstal·lar el programari.
Engeguem els servidors (Tomcat i PostgreSQL) i executem l’opció JasperReports

Server Login que ens obre la interfície web en la pantalla inicial de connexió, tal
com mostra la figura 2.1.
La figura 2.1 ens mostra que la URL http://maquina:port/jasperserver/login.html

porta a la pàgina inicial de JasperReports Server Community, en la qual maquina
correspon a la identificació de la màquina (ip o nom) i port correspon al port pel
qual està escoltant Tomcat.
JasperReports Server admet diversos idiomes i la interfície web es mostra en la

primera llengua de presentació definida en el navegador. Si JasperReports Server
no l’admet, es presenta en llengua anglesa. Cal saber també que els informes
JasperReports Server 5.0 poden estar traduïts en diversos idiomes i JasperReports Server mostrarà l’informe
no admet el català. Podeu
veure la interfície i els en el mateix idioma en què treballi la interfície.
informes en castellà
situant-lo com a primer
idioma de presentació en el
F igu r a 2. 1 . Pantalla inicial de la interfície web de JasperReports Server
navegador.
JasperReports Server Community instal·la tres usuaris: anonymousUser (sense

contrasenya) que no té assignat cap tipus de permís, jasperadmin (contrasenya
jasperadmin) amb permisos totals sobre el servidor i joeuser (contrasenya joeuser)
amb permisos d’usuari final. Obriu sessió amb els usuaris jasperadmin i joeuser
per apreciar les diferents opcions disponibles en cada cas. Llegiu la documentació
que incorpora
JasperReports Server
En aquest moment, com a desenvolupadors d’informes, ens convé fer una ullada Community per obtenir un
coneixement acurat de
als exemples que conté JasperReports Server Community, per fer-nos una idea de totes les seves
possibilitats.
la tipologia d’informes que podem desenvolupar. No entrarem en qüestions pura-
ment administratives (gestió d’usuaris, rols i assignació de privilegis) destinades
als administradors del sistema.
La relació d’informes que un usuari pot executar es troben a l’apartat Library

(Biblioteca), on se’ns presenta una graella dels informes existents, amb les
següents columnes:
• Nom de l’informe.
• Breu descripció de l’informe.
• Tipus, que en el cas de la versió Community sempre és Report, ja que

aquesta versió no permet quadres de comandament.
• Dates de creació i de modificació.
La interfície web de JasperReports Server també facilita l’apartat View | Reposi-

tory amb accés a tots els elements existents en el servidor, organitzats per carpetes
amb diversos continguts. Els elements Report relacionats a l’apartat Library es
poden localitzar en les diferents carpetes del Repository.
Si en el procés d’instal·lació de JasperReports Server hem permès la instal·lació

de bases de dades i informes d’exemple, disposem d’un conjunt d’informes que
ens permeten copsar les possibilitats d’aquest entorn de reporting. És altament
aconsellable efectuar-hi una ullada. Els següents exemples corresponen a un recull
dels que poden ser més interessants per al nostre aprenentatge.
Exemple d’informe: Customers Report
Si executeu aquest informe, que pel títol i la descripció sembla que ha de ser un llistat de
clients, veureu que correspon a un llistat de les comandes de clients, agrupades per client,
amb uns imports sumaritzats a peu de cada client.
En ser un informe de moltes pàgines, a la part superior esquerra de la interfície se’ns facilita
un control per poder moure’ns per les diferents pàgines.
La part superior dreta de la interfície mostra diversos botons, alguns activats i altres
desactivats. Entre els activats, disposem del botó Back que serveix per tirar enrere
(abandonar l’informe) i del botó Export que permet obtenir el llistat en diversos formats
(PDF, Excel, CSV, DOCx, RTF, Flash, ODT, ODS i XLSX).
Exemple d’informe: Employee Accounts
La descripció d’aquest informe ens diu que es tracta d’una llista dels comptes (clients) per
empleat. Amb aquesta informació podem pensar que es tracta d’un llistat similar a l’anterior,
en el qual apareixen els clients de l’empresa agrupats per empleat.
L’execució d’aquest informe ens mostra una pantalla amb el missatge The report is empty.
Bé, podem pensar que la base de dades no té empleats introduïts. Però, a la part superior
dreta de la interfície, observem el botó Options actiu. Si el premem, ens mostra una llista
desplegable dels empleats, amb l’empleat jim seleccionat. Seleccioneu un altre empleat
i executeu de nou el llistat, prement el botó OK sota la llista desplegable. Proveu amb
els empleats jaime i matt. Per cadascun d’aquests empleats es genera el corresponent
informe.
Fixeu-vos en un greu error de disseny per aquest informe: no mostra, per enlloc, la
informació de l’empleat pel qual s’està mostrant la llista de clients. Normalment, a la
capçalera de l’informe s’introdueix informació explicativa sobre el contingut de l’informe,
així com el moment temporal (data i hora) en la qual l’informe ha estat generat.
Exemple d’informe: Employee List
Aquest informe, pel seu nom, sembla que ha de ser un simple llistat dels empleats de
l’empresa i, si l’executeu, veureu que així és.
Fixeu-vos, però, en la darrera columna Accounts, que fa referència als clients que té
cada empleat, visualitzats en l’informe anterior. El valor d’aquesta columna per a cada
empleat és un enllaç anomenat view que, si el premem, ens executa l’informe anterior per
a l’empleat seleccionat. És a dir, JasperReports Server proporciona navegabilitat entre
informes.
Exemple d’informe: Department
La descripció d’aquest informe ens diu que conté input controls (camps de filtre) i per això
és del nostre interès.
En executar-lo, sense aparèixer cap camp de filtre, se’ns mostra una determinada
informació. A la part superior dreta de la interfície observem el botó Options actiu. Si
el premem, s’obre la finestra Input Controls amb tres possibilitats de filtre:
• Sexe: amb una llista multiselecció amb els valors possibles.
• Estat civil: amb dues caselles de selecció.
• Llista desplegable: per seleccionar el departament dels empleats.
Exemple d’informe: Cascading multi select example report
En executar aquest informe, a la part esquerra de la interfície apareix la zona Options que
permet efectuar una selecció en cascada.
En primer lloc apareix una llista multiselecció de països.
En segon lloc, una llista multiselecció d’estats, en la qual només apareixen els estats dels
països seleccionats en l’anterior camp de filtre.
En tercer lloc, una llista desplegable per seleccionar un client, en la qual només apareixen
els clients dels estats seleccionats en l’anterior camp de filtre.
L’informe mostra, pels estats seleccionats, els primers quinze clients incloent-hi el client
indicat en el tercer camp de filtre, malgrat que no estigui entre els primers quinze clients.
2.1.2 Utilització d’iReport Designer 5.0
L’eina iReport Designer és la que utilitzarem per dissenyar informes que posterior-
ment pujarem al servidor JasperReports Server. Aquesta eina pot estar instal·lada
a qualsevol màquina. És una aplicació Java que necessita disposar d’un entorn
JDK de Java per al seu funcionament.
La instal·lació de JasperReports Server facilita la possibilitat d’instal·lar l’iReport

Designer i, a causa que JasperReports Server incorpora un entorn JDK de Java,
l’iReport Designer instal·lat conjuntament amb JasperReports Server funciona
sense necessitat d’instal·lacions complementàries de JDK.
La instal·lació d’iReport Designer independentment de JasperReports Server

obliga a tenir un entorn JDK de Java a la màquina. La instal·lació d’iReport
Designer en una màquina Windows és molt simple i únicament cal seguir les
indicacions. En intentar l’execució de l’iReport Designer no es posa en marxa
(i no apareix cap error) si no troba l’entorn JDK de Java instal·lat. Com que és
possible que en una màquina convisquin diversos entorns JDK de Java, es pot
indicar a iReport Designer la versió a utilitzar, en el paràmetre jdkhome del fitxer
ireport.conf ubicat a la carpeta etc de la ubicació en la qual s’ha instal·lat iReport
Designer. Seguiu les indicacions de
l’annex “Utilització de
l’iReport Designer” per
Una vegada ens hem introduït en la utilització de l’iReport Designer, cal dur a introduir-vos en la
utilització d’aquesta eina.
la pràctica els diversos passos per assolir informes adequats a les necessitats de
l’organització:
1. Definició de Report Datasource per connectar amb la base de dades.
2. Disseny d’informe simple (columnes).
3. Disseny d’informe mestre-detall.
4. Pujada d’informes a un JasperReport Server.
5. Incorporació de filtres a un informe.
Definició de Report Datasource
En qualsevol eina de reporting és necessari definir un origen de dades des d’on

el motor de reporting obté les dades per poder elaborar l’informe. El motor
JasperReport anomena Report Datasource a l’origen de dades i és necessari tenir-
lo definit en l’iReport Designer, en temps de disseny, per poder disenyar l’informe
i, també, en el JasperReport Server, en temps d’execució.
Definició d’un Report Datasource per connectar amb la base de dades Empresa_IOC
del servidor OpenERP
Es desitja utilitzar iReport Designer per obtenir informes sobre la base de dades
Empresa_IOC del servidor OpenERP i, per aquest motiu, ens cal definir, dins l’iReport
Designer, el connector Report Datasource adequat.
Per aconseguir-ho, premem el botó Report Datasources i afegim un nou Datasource

de tipus Database JDBC Connection, ja que l’SGBD d’OpenERP és PostgreSQL i
JasperReports incorpora connector JDBC per connectar amb els SGBD PostgreSQL.
Emplenem els diferents apartats que se’ns demana, com segueix:
• Name: Empresa_IOC o qualsevol nom entenedor.
• JDBC Driver : escollim PostgreSQL.

• JDBC URL: emplenem l’URL de forma adequada segons la plantilla

jdbc:postgresql://maquina:port/nomBD.
• Username - Password: usuari amb accés a la base de dades.
iReport Designer ens permet deixar enregistrada la contrasenya, de manera que no ens la
demani en les successives ocasions en què la necessiti, però ens avisa del perill que hi ha
ja que la contrasenya no queda encriptada. Tot i així, com que no estem en un entorn real
de producció, és aconsellable deixar-la enregistrada ja que del contrari iReport Designer
ens demanarà la contrasenya contínuament.
La pantalla que ens permet introduir aquestes dades, facilita un botó Test per comprovar la
connectivitat del nou Datasource.
Disseny d’un informe simple
En l’aprenentatge del disseny d’informes el més adequat és iniciar-se tot disse-

nyant informes simples, consistents en un conjunt de columnes que contenen la
informació.
Cal tenir present que els diversos informes d’una organització han de seguir la
imatge corporativa (disseny similar, amb logo de l’empresa a la capçalera de
l’informe) i no hem d’oblidar-nos:
• D’introduir a la capçalera les dades referents a la informació que conté

l’informe.
• D’introduir a l’informe (capçalera o peu) la paginació i la data i hora

d’elaboració de l’informe.
Trobareu una possible
solució en el fitxer
professors_PSQL.jrxml
dins l’apartat “Mòduls Disseny d’un informe de professors del mòdul school d’OpenERP
OpenERP i informes” dels
annexos del web. També Volem dissenyar un informe dels professors del mòdul school d’OpenERP, amb les
hi trobareu el logo
LogoIOC.png. següents característiques:
• Columnes: nom, contracte, nombre d’hores que treballa setmanalment, telèfon, correu
electrònic i adreça (carrer, codi postal i ciutat).
• Títol i logotip a la primera pàgina.
• Data i hora d’execució del llistat a la part superior esquerra de cada pàgina.
• Número de pàgina acompanyat del total de pàgines a la part superior dreta de cada pàgina.
• Títols de les columnes, a cada pàgina.
• Professors ordenats per nom.
Per comprovar l’execució de l’informe des d’iReport Designer, heu de tenir seleccionat un
Datasource que apunti a la base de dades d’OpenERP en la qual teniu instal·lat el mòdul
school. A més, el logo de l’informe (fitxer LogoIOC.png) ha de residir a la mateixa carpeta
en la qual estigui ubicat l’informe.
Observeu que l’execució de l’informe provoca la generació d’un fitxer compilat anomenat
nomInforme.jasper.
Pel que fa al disseny de l’informe, fixeu-vos que:
• La sentència SQL en la qual es basa, necessita relacionar les taules school_professor i

res_partner_address amb un outer join, per garantir que apareguin els professors que
no tinguin assignada cap adreça.
• Tot i que iReport Designer permet indicar ordenacions dels registres, és millor indicar la
clàusula ORDER BY a la sentència SQL, ja que del contrari, el motor JasperReports ha
d’esperar a tenir tots els registres que li subministra l’SGBD per efectuar-ne una ordenació
en memòria i posteriorment confeccionar l’informe. En canvi, si l’SGBD facilita els registres ja
ordenats, el motor d’informes pot anar confeccionant l’informe malgrat que no tingui tots els
registres.
Disseny d’un informe mestre-detall
En un informe mestre-detall es mostra informació de dues entitats entre les quals

hi ha establerta una relació 1:N.
En les empreses hi ha una gran quantitat d’informes mestre-detall: comanda

amb les seves línies, client amb les seves comandes, producte amb les seves
compres/vendes...
Les eines de reporting poden facilitar dos mecanismes de disseny per aconseguir
informes mestre-detall:
• Elaborar un únic informe en el qual s’agrupa la informació segons el criteri

que defineix la zona mestra.
• Elaborar informes diferenciats entre la part mestra i la part detall i incloure

l’informe de la part detall com a un subinforme de la part mestra. En aquest
cas, entre els informes cal poder definir una relació que fa de lligam entre
la informació de l’informe mestre i la informació de l’informe detall.
solució a la primera forma
d’obtenir l’informe, en el
Disseny d’un informe mestre-detall de professors amb els cursos que imparteixen, fitxer
pel mòdul school d’OpenERP professor_with_courses_
PSQL_Sencer.jrxml dins
Volem dissenyar un informe mestre-detall de professors amb els cursos que imparteixen, l’apartat “Mòduls
pel mòdul school d’OpenERP, amb les següents característiques: annexos del web. També
hi trobareu el logo
LogoIOC.png.
• Cada professor ha de començar en una nova pàgina i han d’aparèixer ordenats per nom.
• Per a cada professor interessa visualitzar la seva informació personal i la relació de cursos
que imparteix.
• Informació personal d’un professor: nom, contracte, nombre d’hores que treballa
setmanalment, telèfon, correu electrònic i adreça (carrer, codi postal i ciutat).
• Relació de cursos que imparteix: nom, descripció i nombre d’hores.
• Logotip a la capçalera de cada pàgina.
• Data i hora d’execució del llistat a la part inferior esquerra de cada pàgina.
L’informe demanat es pot plantejar de dues formes: una, amb un únic informe que
contingui una sentència SQL que proporcioni les files resultants d’un join entre les taules
school_professor i school_course, de manera que l’informe incorpori la definició d’un
grup per professor; l’altra, amb un informe encarregat de mostrar els professors, que
incorpori un subinforme amb els cursos del professor.
En la solució basada en la sentència join entre les taules school_professor i

school_course, observeu que el camp que defineix el grup ha de ser id de professor i
no pot ser el nom (name), ja que hi podria haver diversos professors amb el mateix nom.
A més, és imprescindible que la consulta contingui order by name, id, ja que iReport
es basa en el canvi de valor pel camp d’agrupament (id) per iniciar un nou grup i, en
conseqüència, cal garantir que el SGBD faciliti els registres a iReport agrupats per id.
Per incorporar un grup en un informe JasperReports, ens situem en el node principal del
report (Report Inspector), premem el botó secundari del ratolí i en el menú contextual
seleccionem l’opció Add Report Group i indiquem qualsevol dels camps que han d’anar en
el grup. Això provoca que apareguin dues bandes (capçalera i peu) pel grup. Hi ubiquem
els camps adequats. Si interessa, en les propietats del grup indiquem que comenci en una
nova pàgina.
En la solució basada en un informe amb subinforme, fixeu-vos que l’informe detall ha

d’incorporar, en la clàusula WHERE de la sentència SQL, el paràmetre $P{Professor}
de tipus integer, creat a la zona Parameters de Report Inspector. L’informe mestre,
en la propietat Parameters del full Properties, de l’objecte Subreport, ha d’emplenar el
paràmetre Professor amb el contingut del camp $F{id}, aconseguint que en l’execució, per
a cada professor, l’informe mestre invoqui l’informe detall amb el valor id del corresponent
professor. Fixeu-vos, també, que el subinforme ha de tenir la propietat Run to bottom
activada, per aconseguir que el subinforme ocupi tota la resta de la pàgina i el següent
professor comenci en una nova pàgina.
solució a la segona forma
d’obtenir l’informe, en els
fitxers
professor_with_courses_
PSQL_Mestre.jrxml i
Pujada d’informes a un JasperReport Server Community
professor_with_courses_
PSQL_Detall.jrxml dins
L’eina iReport Designer, a banda de permetre’ns el disseny de tot tipus d’informes,
annexos del web. També
hi trobareu el logo
ens en permet l’execució. Però en una organització amb molts usuaris cal poder
LogoIOC.png. ubicar els diversos informes en un servidor d’informes i JasperReport Server
Community és una bona opció.
Pujada d’informes generats amb iReport Designer a JasperReport Server Community
Ens interessa pujar els informes de professors de l’empresa Empresa_IOC d’OpenERP,

generats amb iReport Designer, a un servidor JasperReport Community, per ser executats
des d’un navegador per qualsevol usuari que hi tingui accés.
La pujada d’informes a un JasperReports Server es pot efectuar des de la interfície web

que proporciona aquest servidor, però també des de l’eina iReport Designer. Ja que hi
estem treballant, ho farem des d’aquesta eina.
En primer lloc establim connexió amb el servidor JasperReports a través de Finestra |

JasperReports Server Repository creant, si encara no ho hem fet, una connexió amb el
botó Add new server, que ens obre una pantalla per donar d’alta el servidor, introduint:
• ID: nom que ens permeti identificar el servidor, ja que podem tenir connexions establertes
amb diversos servidors.
• JasperReports Server URL: URL adequada segons la plantilla

http://maquina:port/jasperserver/services/repository, en la qual caldria substituir
jasperserver per jasperserver-pro en cas d’un JasperReports Server Enterprise.
• Username - Password: usuari amb privilegis adequats en el servidor (jasperadmin, per

exemple)
Si la connexió s’estableix sense problema, veurem que ens mostra la mateixa informació
que visualitzem des de l’apartat View|Repository de la interfície web. Quan ens situem
damunt del nom del servidor i, premem el botó secundari del ratolí, ens apareix un menú
contextual amb diverses possibilitats, entre les quals ens interessa l’opció Add.
L’opció Add apareix en els menús contextuals de gairebé tots els apartats que conté el
repositori i l’executarem allà on ens interessi afegir elements. En la creació de qualsevol
element, cal assignar-li un identificador (alfanumèric sense espais ni caràcters especials),
un nom i, de forma opcional, una descripció. El nom i la descripció podran canviar en
qualsevol moment, però l’identificador restarà immodificable per sempre més.
Per ser organitzats, el primer que farem és crear una nova carpeta a l’arrel del repositori,
de nom Empresa IOC en el qual ubicarem tots els informes.
En segon lloc, crearem un Datasource que apunti a la base de dades PostgreSQL

d’OpenERP en la qual ha d’anar el motor JasperReports a cercar les dades per
confeccionar els informes. Sembla lògic ubicar aquest Datasource sota el node Data
Sources del repository, tot i que també el podríem crear dins la carpeta Empresa IOC
creada anteriorment. En crear el nou Datasource li hem de donar un nom entenedor
(Empresa IOC) i cal emplenar adequadament el contingut de la pestanya Data Source
Details, en la qual disposem d’un botó Import from iReport per capturar les dades del
Datasource que segurament tenim definit en l’iReport Designer des del qual hem dissenyat
els informes.
Per últim, situats a la carpeta Empresa IOC, procedim a afegir els tres informes, un a un,
assignant-los un ID i un nom. El procés d’agregació d’un informe detecta altres recursos
que utilitza l’informe (imatges i subinformes, per exemple) i en proposa la càrrega a partir
del sistema de fitxers local, pujant-ne una còpia al servidor JasperReports.
Una vegada pujats els informes, ja són accessibles i executables des de la interfície web.
Incorporació de filtres a un informe
En moltes ocasions, els informes dissenyats han de mostrar únicament una part de
la informació que poden mostrar i, per aconseguir-ho, cal afegir filtres en els quals
l’usuari pugui introduir les dades de filtratge just abans de l’execució de l’informe.
Les dades introduïdes per l’usuari en els filtres, s’afegeixen de manera adequada
a la clàusula WHERE de la sentència SQL en la qual es basa l’informe.
La majoria d’entorns de reporting actuals faciliten filtres que permeten:
• Controlar el tipus de dada a introduir per l’usuari.
• Acompanyar el filtre d’un giny adequat al tipus de dada.
• Introduir els valors possibles a introduïr per l’usuari (atòmics o llistes, fixos
o dinàmics, a partir del resultat d’una consulta SQL sobre la base de dades)
Exemple d’informe amb filtres
Volem retocar qualsevol dels dos informes de professors amb els seus cursos, de manera
que en executar-los aparegui una llista multiselecció que mostri els diversos professors i
permeti seleccionar els professors dels quals es vol generar l’informe.
Editem professors_with_courses_PSQL_Sencer.jrxml, hi creem un paràmetre

(pProfessors) de tipus Integer i modifiquem la sentència SQL afegint la clàusula:
1 WHERE school_professor.id = $P{pProfessors}

En comprovar l’execució de l’informe des d’iReport Designer, apareix una pantalla per
tal que introduïm un valor pel paràmetre pProfessors. Si volem veure l’informe d’algun
professor, hem d’introduir el seu identificador dins la taula school_professor de la base
de dades, que podem reconèixer amb qualsevol eina que ens permeti connectar amb un
SGBD PostgreSQL (consola psql o eina pgAdmin, per exemple).
Una vegada hem comprovat la correcta execució des d’iReport Designer, volem pujar-lo
a un servidor JasperReports en el qual, evidentment, no podem pretendre que els usuaris
sàpiguen l’identificador del professor de qui vol obtenir l’informe i, en conseqüència, haurem
de definir un Input control en el servidor, de tipus llista desplegable, que mostri els profesors
de la base de dades.
Així doncs, pugem l’informe al servidor, de la manera habitual i, posteriorment, li afegim

un Input control de tipus Single Select Query, que s’ha d’anomenar igual que el paràmetre
(pProfessors) de l’informe.
El servidor JasperReport permet definir Input controls que puguin ser utilitzats en diversos
informes. D’aquesta manera, pot ser adequat disposar d’una llista desplegable amb els
professors de la base de dades. Per tal que l’usuari pugui escollir-ne un, podríem decidir
crear un Input control genèric; del contrari, la lògica ens porta a crear-lo localment en
l’informe que el necessiti.
La definició d’un Input control (genèric o local) obliga a indicar el tipus de control (hi ha
diverses possibilitats) i les característiques d’obligatorietat, només lectura i visibilitat del
control. A més, hi ha altres característiques per definir, en funció del tipus de control.
En un control Single Select Query, igual que en el nostre exemple, cal definir la Query
Resource (que també pot ser genèrica o local al control), les columnes visibles per a l’usuari
i la columna que cal tenir en compte per emplenar el paràmetre de l’informe. En el nostre
exemple, la Query Resource és una consulta similar a:
1 select id, name from school_professor order by name’’
on la columna a visualitzar és name i la columna de la qual agafar el valor és id.
Una vegada definit l’Input control, ja s’està en condicions d’executar l’informe des de la
interfície web, tal com mostra la figura 2.2.
F igu ra 2 .2 . Filtre de tipus llista desplegable per a un informe

2.2 Reporting en OpenERP
En la versió 6.1 d’OpenERP disposem de dos mecanismes per integrar informes

en els mòduls, cadascun d’ells basat en un motor de reporting específic: Podeu ampliar la
informació sobre el motor
d’informes RLTK de
ReportLab a
www.reportlab.com, sobre
el motor d’informes
• Motor d’informes RLTK de ReportLab (sota llicència BSD –codi obert–) JasperReport de
que permet generar informes en formats PDF. Forma part d’OpenERP Jaspersoft Corporation a
community.jaspersoft.com
com a motor oficial de reporting. RLTK (ReportLab Toolkit), basat en /project/jasperreports-
library) i sobre NaN·tic a
Python, genera informes a partir de plantilles codificades amb el llenguatge www.nan-tic.com/ca/.
RML (Report Markup Language), que és un dialecte d’XML. Per evitar

haver de conèixer el llenguatge RML, OpenERP facilita un connector per
a OpenOffice o LibreOffice, que fa possible dissenyar l’informe des del
processador de textos Writer i obtenir el fitxer RML corresponent.
• Motor d’informes JasperReport de Jaspersoft Corporation, que permet

generar informes en múltiples formats (PDF, RTF, XML, XLS, CSV,
HTML, XHTML, text, DOCX o OpenOffice). Aquesta opció de reporting
no és oficial per OpenERP 6.1 i cal instal·lar el mòdul no oficial Jasper
Reports desenvolupat inicialment per NaN·tic, i recentment constituït en
el projecte Jasper Reports for OpenERP (https://launchpad.net/openobject-
jasper-reports) dins Launchpad. El disseny d’informes JRXML (format
pel motor JasperReports) per a OpenERP s’efectua amb l’eina iReport
Designer.
La majoria de mòduls d’OpenERP van acompanyats de llistats. Així, si tenim el

mòdul de Magatzem instal·lat i naveguem a Magatzem | Productes | Productes,
podem observar que OpenERP ens facilita tres llistats: Llista de preus, Etiquetes
de productes i Previsió nivell d’estoc. Els informes vinculats a un objecte d’O-
penERP (product.product, per exemple) són accessibles, de forma automàtica,
en els formularis vinculats a l’objecte (opció Magatzem | Productes | Productes,
per exemple). En el client web apareixen en el panell lateral dret del navegador i
en el client GTK apareixen en prémer el botó Imprimir de la botonera superior.
Fi g ura 2 .3. Pantalla que mostra els informes existents sobre un objecte d’OpenERP
L’opció Setings | Personalització | Objectes de baix nivell | Accions | Informes

permet gestionar els informes instal·lats a l’empresa activa. Si fem una cerca
dels informes existents sobre l’objecte product.product, veurem que n’hi ha
tres (figura 2.3), com era d’esperar. Hi observem que els tres informes són
de tipus PDF. La columna Nom del servei fa referència al nom de fitxer PDF
que genera OpenERP. Aquesta pantalla permet afegir nous informes, eliminar
informes existents i modificar paràmetres d’execució dels informes existents.
2.2.1 Disseny d’informes RML a través d’OpenOffice/LibreOffice
El disseny d’informes per OpenERP amb OpenOffice o LibreOffice és una manera

ràpida de dissenyar informes que es poden integrar dins OpenERP i que pot dur a
terme qualsevol usuari amb uns mínims coneixements de com està estructurada la
informació a la base de dades d’OpenERP.
Per dissenyar informes per OpenERP amb OpenOffice o LibreOffice, necessiteu

instal·lar a l’empresa d’OpenERP per la que vulgueu dissenyar els informes, el
mòdul OpenOffice Report Designer que ja incorpora la instal·lació d’OpenERP.
La instal·lació d’aquest mòdul és molt ràpida i de seguida mostra una pantalla
informativa sobre els passos que s’han de seguir, en OpenOffice o LibreOffice, per
instal·lar l’extensió que permet dissenyar els informes i se’n facilita la descàrrega
des de la mateixa pantalla.
L’OpenOffice o LibreOffice no té perquè estar instal·lat en la màquina que conté

el servidor OpenERP; només es necessita tenir-lo a les màquines des de les quals
es vol dissenyar informes. Aquestes màquines han de tenir connectivitat amb el
servidor OpenERP.
Instal·leu l’extensió openerp_report_designer.zip facilitada en el procés d’ins-

tal·lació del mòdul OpenOffice Report Designer en l’OpenOffice o LibreOffice
que vulgueu utilitzar. L’extensió funciona en la majoria de versions d’aquests
programaris. Després de reiniciar el Writer, observeu:
• La barra de menús conté la nova opció Open ERP Report amb un conjunt
d’opcions que ens permeten dissenyar els informes.
• Hi ha la nova barra d’eines Open ERP Report. Si en algun moment tanqueu

aquesta barra i la voleu tornar a obrir, en l’opció de barres d’eines de Writer
no la trobareu amb el nom Open ERP Report, sinó amb el nom Complement
seguit d’un número.
Per iniciar el disseny d’un informe, ja sigui nou o, fins i tot, d’un informe instal·lat
en el servidor, el primer que cal fer és establir connexió amb el servidor, fet que
podem assolir amb el primer botó de la barra d’eines o amb l’opció Open ERP
Report | Server parameters. Apareix la pantalla de connexió (figura 2.4) que
intenta connectar amb un servidor a la mateixa màquina. Si el troba, no apareix el
missatge Could not connect to the server!, sinó que la llista desplegable de l’apartat
Database mostra les bases de dades existents en el servidor.
Fig ur a 2 . 4. Pantalla de connexió des de Writer cap a un
servidor OpenERP
Una vegada introduït el valor adequat a l’apartat Server URL, s’estableix connexió
amb el servidor OpenERP i se selecciona la base de dades que correspongui,
indicant un usuari i contrasenya adequats per l’empresa. Si l’empresa selec-
cionada no ha tingut mai una connexió des de Writer, apareixerà l’error de
la figura 2.5, que ens indica que a l’empresa ha d’existir el grup d’usuaris
OpenOfficeReportDesigner, al qual hauran de pertànyer els usuaris de l’em-
presa amb permís per dissenyar informes.
Fig ur a 2 . 5. Error si l’empresa d’OpenERP encara no ha

estat mai accedida des de Writer
Creem, doncs, el grup d’usuaris OpenOfficeReportDesigner i hi assignem els

usuaris que utilitzarem per dissenyar informes (admin, per exemple). En cas
de tenir el grup creat i intentar l’accés amb un usuari no pertanyent al grup,
apareixeria l’error You have not access these Report Designer.
Una vegada tenim establerta una connexió, podem optar per crear un nou informe
(Open ERP Report | Open a new report) o modificar un informe del servidor (Open
ERP Report | Modify Existing Report). En escollir l’opció de modificació, al cap
d’uns segons, ens apareix una pantalla amb tots els informes RML existents en el
servidor i ens permet seleccionar-ne qualsevol, per modificar-lo i, posteriorment,
tornar-lo a enviar al servidor. Abans, però, de modificar-ne cap, ens convé conèixer
l’estructura dels informes RML generats amb Writer i, n’aprendrem tot creant nous
informes.
Disseny d’un informe de professors pel mòdul school d’OpenERP
Volem dissenyar un informe dels professors pel mòdul school d’OpenERP, amb les
següents característiques:
• Imatge corporativa de l’empresa a totes les pàgines.
• Data i hora d’execució del llistat a la part superior dreta.
Per aconseguir-ho, creem un nou informe amb l’opció Open ERP Report | Open a new
report i ens apareix una llista dels objectes existents a l’empresa i seleccionem l’objecte
school.professor (al capdavall de la llista). Amb aquesta acció hem indicat que l’informe
està vinculat a l’objecte school.professor, però no apareix res en pantalla. Aquest vincle
queda a nivell intern i el podem veure a Fitxer | Propietats | Propietats personalitzades |
Informació 4. Observeu, també, en les propietats personalitzades, el servidor OpenERP al
que us connecteu (Informació 1) i l’usuari (Informació 2).
L’acció següent és definir un bucle (opció Open ERP Report | Add a loop) ja que tot informe
es basa en un bucle sobre el recursos de l’objecte que l’usuari seleccionarà en el moment
d’executar l’informe. En executar aquesta opció, ens apareix una pantalla en la qual hem
de seleccionar l’objecte sobre el qual es basa el bucle (school.professor) i el camp sobre
el qual iterarà el bucle, que en aquest cas, és objects (no se’ns facilita altra possibilitat),
com mostra la part esquerra de la figura 2.6. Una vegada escollit objects, en el document
en el qual estem dissenyant l’informe apareix el codi:
1 |−.professor.−|
El text anterior indica un bucle i es correspon a una instrucció de RML. Les instruccions
RML s’escriuen entre dobles claudàtors i el connector instal·lat en Writer ens permet veure
la visualització amb claudàtors tot seleccionant el corresponent botó de la barra d’eines o
amb l’opció Open ERP Report | Conversions Fields -> Brackets. Si ho fem, veurem com el
codi anterior canvia per:
1 [[repeatIn(objects,’professor’)]]
La instrucció anterior indica que s’executarà un procés iteratiu sobre tots els recursos de
l’objecte school.professor (camp Informació 4 de les propietats personalitzades del fitxer
ODT) i la paraula professor és un àlies per referir-nos a cada recurs. Podem, si voleu,
posar un nom més curt, com prof o pr.
A continuació hem de seleccionar els camps que ens interessa obtenir a cada iteració, i això
ho fem amb l’opció Open ERP Report | Add a field que ha de presentar-nos una pantalla
com la part dreta de la figura 2.6, en la qual es facilita la llista dels camps accessibles des
de l’objecte school.professor (triga a facilitar-se, cal tenir paciència) i com que aquest
objecte conté camps many2one, OpenERP facilita els camps accessibles a través dels
objectes referenciats pels camps many2one, fet que ens va molt bé per poder seleccionar
correu electrònic i adreça. Seleccionem els camps:
1 [[ professor.name ]]
2 [[ professor.contract ]]
3 [[ professor.hours_available ]]
4 [[ professor.phone ]]
5 [[ professor.address_id.email ]]
6 [[ professor.address_id.street ]]
7 [[ professor.address_id.zip ]]
8 [[ professor.address_id.city ]]
La selecció dels camps no és obligatori fer-la a través d’Open ERP Report | Add a field i
podem escriure’ls directament tenint en compte la sintaxi a utilitzar.
Per ubicar correctament els camps en columnes d’un llistat, ens cal crear una taula
de 8 columnes i ubicar cada camp en una columna. El camp corresponent al bucle
(|-.professor.-|) també ha d’estar situar dins la taula; si el deixem fora, l’informe

mostrarà cada recurs en una pàgina diferent.
En la solució facilitada, observeu el camp [[time.ctime()]] que mostra la data i hora del
sistema en el moment d’execució de l’informe. Trobareu una possible
F igur a 2. 6. Pantalles de Writer per seleccionar l’objecte sobre el qual s’itera i els camps a visualitzar professors.odt dins
annexos del web.
Per les proves realitzades,

sembla que la pantalla Field
Builder (figura 2.6) només
Una vegada l’informe està dissenyat, podem enviar-lo al servidor, amb l’opció s’emplena si no es té
activada la visualització amb
Open ERP Report | Send to the server i comprovar-ne l’execució. En el moment claudàtors.
d’enviar-lo, apareixerà una pantalla en la qual es demana:
• Report name: per introduir el nom amb el qual l’informe apareixerà en els
clients web i GTK.
• Technical name: corresponent al nom que OpenERP proposarà pel fitxer

PDF que genera la impressió. Writer proposa un nom format pel nom
de l’objecte (school.professor) concatenat amb una tira alfanumèrica
aleatòria.
• Corporate Header: per activar la incorporació automàtica de la imatge

corporativa de l’empresa (capçalera i peu definits per a l’empresa).
• Select Rpt. Type: per seleccionar la sortida del fitxer, que pot ser PDF, ODT
o HTML (normalment PDF).
Després d’enviar l’informe al servidor, podrem comprovar-ne l’aparició en els

clients web i GTK al situar-nos en el formulari Professors. També podrem
observar-ne l’existència a Settings | Personalització | Objectes de baix nivell |
Accions | Informes.
L’informe, una vegada enviat al servidor, hi queda registrat amb un identificador

(taula ir_act_report_xml), que també queda enregistrat a l’apartat Informació
3 de les propietats personalitzades del fitxer ODT, de manera que cada vegada que
s’intenta enviar el fitxer al servidor OpenERP, si el fitxer ja té un identificador
introduït (d’anteriors enviaments), s’intenta substituir el formulari existent amb
igual identificador. Això suposa un problema si un informe (amb un identificador)

es vol enviar a una altra empresa; caldrà eliminar prèviament el contingut del
camp Informació 3 de les propietats personalitzades. De la mateixa manera, en
recuperar un informe d’una empresa d’un servidor OpenERP, el camp Informació
Trobareu una possible 3 queda documentat amb l’identificador de l’informe en l’empresa origen.
professor_with_courses.odt
dins l’apartat “Mòduls Disseny d’un informe mestre-detall de professors amb els cursos que imparteixen,
annexos del web. pel mòdul school d’OpenERP
Volem dissenyar un informe mestre-detall de professors amb els cursos que imparteixen,
pel mòdul school d’OpenERP, amb les següents característiques:
• Cada professor ha de començar en una nova pàgina.
que imparteix.
• Imatge corporativa de l’empresa a cada pàgina.
L’informe demanat es basa en l’objecte school.professor.
Cada professor (bucle [[repeatIn(objects,’professor’)]]) es mostra en una nova

pàgina amb distribució capçalera-línies.
La capçalera incorpora les dades personals del professor:
1 [[ professor.name ]]
2 [[ professor.contract ]]
3 [[ professor.hours_available ]]
4 [[ professor.phone ]]
5 [[ professor.address_id.email ]]
6 [[ professor.address_id.street ]]
7 [[ professor.address_id.zip ]]
8 [[ professor.address_id.city ]]
La zona de línies conté la informació dels cursos que imparteix el professor, basat en
un bucle sobre els recursos accessibles des del camp professor.course_ids. Podem
introduir aquest bucle escrivint [[repeatIn(professor.course_ids,’course_ids’)]] o
executant Open ERP Report | Add a loop, fet que ens mostra tots els camps many2one
i many2many de l’objecte school.professor, camps susceptibles de proporcionar nous
bucles. La línia prèvia a la taula que conté la definició del bucle està formatada amb
lletra de mida 2 (mínim possible en Writer), per tal que ocupi el mínim d’espai possible
en l’informe.
La definició del bucle course_ids ha d’estar abans que la taula que conté els camps
accedits a través de course_ids, i ambdós (bucle i taula) cal ubicar-los en una secció.
En l’exemple que es proposa, s’ha creat una secció anomenada Courses (el nom pot ser
qualsevol, però millor introduir un nom amb significat adequat).
El bucle a través del camp professor.course_ids ens permet incorporar les dades dels
cursos en una taula amb tres columnes:
1 [[ course_ids and course_ids.name]]

2 [[ course_ids and course_ids.subject]]
3 [[ course_ids and course_ids.hours_total]]
OpenERP ens facilita, doncs, a través de Writer, la possibilitat de generar i

instal·lar informes en una empresa. Els informes instal·lats, però, no formen
part de cap mòdul i és molt possible que els desenvolupadors de mòduls vulguin
dissenyar informes que s’instal·lin a l’empresa quan s’instal·la el mòdul. En aquest
cas, els informes cal dissenyar-los en llengua anglesa, com la resta del mòdul, ja
que el mecanisme de traducció d’OpenERP també té en compte els textos dels
informes RML.
Per incorporar un informe dissenyat amb Writer en un mòdul d’OpenERP, cal

seguir els següents passos:
• Obtenir el fitxer RML corresponent, executant l’opció Open ERP Report |

Export to RML des de Writer.
• Ubicar el fitxer RML en una carpeta report (recomanable, no obligatori).

També hi ha el costum de deixar-hi el document ODT a partir del qual s’ha
generat el fitxer RML.
• Dissenyar un fitxer XML que defineix un o diversos informes per al mòdul.

Aquest fitxer es pot ubicar també dins la carpeta report. Ha de ser
referenciat des de l’apartat update_xml del fitxer __openerp__.py del
mòdul. El contingut d’aquest fitxer XML ha de ser com es mostra tot seguit,
amb un element report per a cada informe:

2 <openerp>
3 <data>
4 <report
5 id="identificadorDeInformeDinsElModul"
6 model="objecteOpenErpEnElQueEsBasaElInforme"
7 name="nomDelServei"
8 rml="nomFitxerRMLambElCamiOnEsTroba"
9 <!−− El camí ha d’incloure el nom de la
10 carpeta del mòdul−−>
11 header="True/False"
12 string="nomQueEsVisualitzaEnOpenERP"/>
13 </data>
14 </openerp>
• Instal·lar el mòdul amb el(s) nou(s) informe(s) i actualitzar les traduccions

als diversos idiomes amb els textos que incorporen els informes, per
finalment disposar del mòdul amb els informes traduïts. del mòdul school, que
incorpora els informes
professors.rml i
professor_with_courses.rml,
En moltes ocasions, s’ha d’incloure en l’informe camps calculats que no estan amb la traducció al català,
a l’arxiu school_17.zip,
definits en el model sobre el qual es basa. En aquests casos, la solució resideix dins l’apartat “Mòduls
en definir una classe Python que derivi de report_sxw.rml_parse en la qual annexos del web.
s’incorporen els mètodes que efectuen els càlculs adequats. La nova classe,
com és habitual, ha de residir en un fitxer .py i s’acostuma a ubicar en la No hi ha molta
documentació que faci
carpeta report, fet que provoca la necessitat d’incloure un fitxer __init__.py referència al disseny
d’informes RML a través
dins la carpeta report, amb el contingut import nomFitxer, i d’incorporar la d’OpenOffice/LibreOffice; en
cas de necessitar-la, haureu
instrucció import report en el fitxer __init__.py del mòdul. La versió 17 del de cercar exemples en les
carpetes report dels
mòdul school no incorpora aquest muntatge ja que en els informes elaborats no mòduls que OpenERP
incorpora.
ha estat necessari incorporar cap càlcul.
2.2.2 Disseny d’informes JRXML a través d’iReport Designer
L’empresa NaN·tic (www.nan-tic.com/ca/) va desenvolupar un mòdul per a Ope-

nERP que incorpora el motor de JasperReports i fa possible l’execució i la
integració d’informes JRXML, generats normalment per l’eina de disseny iReport
Designer. En el moment actual el mòdul es troba en el projecte Jasper Reports for
OpenERP (https://launchpad.net/openobject-jasper-reports) dins Launchpad.
En primer lloc cal descarregar de Launchpad el mòdul jasper_reports per a

la versió d’OpenERP que correspongui. En el nostre cas, segons les instruccions
existents a Launchpad:
1 bzr branch lp:openobject−jasper−reports/6.1
El resultat de la descàrrega és la carpeta jasper_reports que correspon al mòdul

Jasper Reports. S’instal·la de manera habitual.
La utilització del motor JasperReports en OpenERP necessita que la màquina en

la qual resideixi el servidor OpenERP tingui instal·lat un entorn JRE de Java.
Els passos per dissenyar un informe JasperReport per a OpenERP són:
1. Executar l’opció Settings | Personalització | Jasper Reports | Crea una

plantilla de dades per obtenir un arxiu XML amb la definició dels camps
de l’objecte sobre el qual es dissenya l’informe i dels objectes per ell
referenciats a través de camps relacionals. OpenERP mostra una pantalla
en la qual hem d’emplenar el camp Model amb l’objecte sobre el qual
es vol dissenyar l’informe i el camp Depth amb el nombre de nivells
de camps relacionals que cal incloure en la plantilla XML. Amb els dos
camps emplenats, premem el botó Create i OpenERP ens genera l’arxiu
template.xml que enregistrem per utilitzar-lo en el següent pas.
2. En l’eina iReport Designer creem un Datasource de tipus XML file data-

source i emplenem les dades tal com mostra la figura 2.7.
3. Creem un informe des d’iReport Designer i emplenem la Report query

tal com mostra la figura 2.8, arrossegant els camps que corresponguin del
panell dret cap al panell inferior, com indica la fletxa.
4. Dissenyem el contingut de l’informe de la manera habitual.
L’informe dissenyat no es pot executar des d’iReport Designer i caldrà integrar-lo

en OpenERP per a comprovar-ne l’execució. Abans d’instal·lar-lo cal efectuar
un retoc manual a l’arxiu JRXML generat per iReport Designer, ja que del
contrari, en executar l’informe apareixeria l’error de la figura 2.9, provocat per
una incompatibilitat entre el mòdul Jasper Reports i els formats JRXML generats
per iReport Designer de versió posterior a 4.5. El retoc consisteix en editar el
fitxer JRXML amb un editor de textos que sàpiga cercar expressions regulars
(per exemple, Notepad++) i eliminar totes les aparicions de l’expressió regular

uuid="\w*-\w*-\w*-\w*-\w*".
F igur a 2 . 7 . Datasource de tipus XML per crear informes JRXML per
OpenERP
Figu ra 2. 8. Generació de camps per un informe JRXML basat en dataxource XML

Fig u ra 2. 9. Error en executar informe JRXML generat amb iReport Designer en

OpenERP
L’error de la figura 2.9 es pot

evitar configurant iReport
Designer per generar els
fitxers JRXML en format 4.5
(opció Eines | Opcions |
Per integrar un informe JRXML en una empresa d’OpenERP, cal utilitzar l’opció
General | Compatibilitat). Settings | Personalització | Jasper Reports | Jasper Reports i crear-hi un nou recurs,
indicant:
• Nom: amb el qual l’informe apareixerà en els clients web i GTK.
• Model: amb el nom de l’objecte d’OpenERP en el qual es basa l’informe.
• Nom del servei: amb el nom que OpenERP ha de proposar pel fitxer que
generi la impressió.
• Sortida Jasper: per seleccionar el format de l’informe (HTML, CSV, XLS,

RTF, ODT, ODS, Text o PDF).
En el nou recurs cal afegir-hi els fitxers necessaris per executar l’informe: fitxer
JRXML de l’informe, fitxers d’imatges inclosos a l’informe, altres fitxers JRXML
incrustats dins l’informe principal... El fitxer principal ha de portar activada la
casella Per defecte.
Una vegada enregistrat l’informe, podrem comprovar la seva aparició en els clients
web i GTK al situar-nos en el formulari que correspon a l’objecte en el qual es basa
l’informe. També podrem observar la seva existència a Settings | Personalització
Trobareu una possible | Objectes de baix nivell | Accions | Informes.
professors.jrxml dins
l’apartat “Mòduls Disseny d’un informe de professors pel mòdul school d’OpenERP
annexos del web. També Volem dissenyar un informe dels professors pel mòdul school d’OpenERP, amb les
hi trobareu la plantilla
professors.xml utilitzada i següents característiques:
el logo LogoIOC.png.
• Títol i logotip a la primera pàgina.
• Data i hora d’execució del llistat a la part superior esquerra de cada pàgina.
• Número de pàgina acompanyat del total de pàgines a la part superior dreta de cada pàgina.
• Títols de les columnes a cada pàgina.
La plantilla XML per obtenir l’informe demanat s’ha generat sobre l’objecte
Trobareu una possible school.professor amb profunditat 2 ja que calia accedir a valors de l’objecte
professor_with_courses res.partner.address apuntat pel camp address_id de school.professor.
.jrxml dins l’apartat
“Mòduls OpenERP i
informes” dels annexos Per obtenir informes Jasper amb estructura mestre-detall, cal utilitzar la definició
del web. També hi
trobareu la plantilla de grups, segons la forma habitual d’iReport Designer, i afegir la següent property
professors.xml utilitzada i
el logo LogoIOC.png. al report (node principal del report | Properties | Properties):
1 Name: OPENERP_RELATIONS
2 Value: [’nomCamp_One2Many_o_Many2Many’]
Disseny d’un informe mestre-detall de professors amb els cursos que imparteixen,
pel mòdul school d’OpenERP
Volem dissenyar un informe mestre-detall de professors amb els cursos que imparteixen,
pel mòdul school d’OpenERP, amb les característiques següents:
• Cada professor ha de començar en una nova pàgina i han d’aparèixer ordenats per nom.
que imparteix.
• Logotip a la capçalera de cada pàgina.
• Data i hora d’execució del llistat a la part inferior esquerra de cada pàgina.
La solució proposada es basa en la plantilla professors.xml generada sobre l’objecte

school.professor amb nivell de profunditat 2, que conté la informació referent als cursos
que imparteix cada professor. L’informe defineix un grup pel camp id de professor i conté
la property :
1 Name: OPENERP_RELATIONS
2 Value: [’course_ids’]
El mòdul Jasper Reports per OpenERP facilita la possibilitat d’instal·lar informes

Jasper en una empresa. Els informes instal·lats, però, no formen part de cap
mòdul i és molt possible que els desenvolupadors de mòduls vulguin dissenyar
informes Jasper que s’instal·lin a l’empresa en instal·lar el mòdul. Per incorporar
un informe Jasper en un mòdul d’OpenERP cal seguir el mateix procediment que
pels informes RML. Els informes JasperReports incorporats en un mòdul no poden
incloure un logo (ja que canvia per a cada organització) i hauríem de trobar la Podeu trobar la versió 18
del mòdul school, que
manera de poder utilitzar una imatge corporativa com en els informes RML. incorpora els informes
professors.jrxml i
professor_with_courses
El mòdul Jasper Reports per OpenERP també facilita la funcionalitat de traducció .jrxml, sense logo, a l’arxiu
school_18.zip, dins
dels informes a diferents idiomes. l’apartat “Mòduls
annexos del web.
Podeu trobar més

informació sobre el mòdul
Jasper Reports per
OpenERP a:
2.3 Solucions BI en OpenERP www.nan-tic.com/es/2009
/jasperreports-ng/.
OpenERP, a banda de les possibilitats de reporting, facilita dues funcionalitats que

podem considerar en el camp del Business Intelligence:
• La definició d’objectes no persistents, basats en vistes de PostgreSQL.
• La definició de quadres de comandament.

2.3.1 Vistes basades en objectes no persistents
OpenObject permet dissenyar objectes no persistents, basats en vistes de Post-

greSQL, que s’acostumen a utilitzar en el desenvolupament de gràfics, informes
estadístics i quadres de comandament. Feu una ullada a la documentació oficial
Podeu consultar la d’OpenObject.
documentació oficial
d’OpenObject a
doc.openerp.com/v6.0/ Disseny de vista basada en un objecte no persistent
developer/4_14_dashboard
/index.html. Volem aconseguir un gràfic que ens mostri el nombre de cursos que desenvolupa cada
professor, en el mòdul school.
incorpora la solució En principi seria lògic pensar que el gràfic s’hauria de poder dissenyar sobre el model
proposada, a l’arxiu school.professor, però això no és possible ja que no hi tenim el nombre de cursos que
school_19.zip, dins
l’apartat “Mòduls un professor desenvolupa.
annexos del web.
Per altra banda, ens adonem que l’objecte school.course conté, per cada recurs, el
professor assignat. Llavors, si el tipus de vista graph proporcionés un operador (per
exemple, count) que permetés recomptar el nombre de registres d’un grup, podríem
escriure quelcom similar a:
2 id="view_school_professor_graph">
3 <field name="name">school.professor.graph</field>
4 <field name="model">school.course</field>
7 <graph string="Number of courses by professor">
8 <field name="prof_id"/>
9 <field name="id" operator="count"/>
10 </graph>
11 </field>
12 </record>
Però no és el cas. Potser en versions futures d’OpenObject hi haurà un operador count, de

la mateixa manera que ara hi ha els operadors min i max.
Una possibilitat és retocar la classe school.professor per afegir-hi un nou camp

nre_cursos, calculat a partir del camp course_ids. Pot ser un bon exercici, però no és
la solució que donarem aquí.
Una altra possibilitat de solució és crear una classe no persistent, basada en una vista de
PostgreSQL, que ens faciliti el càlcul desitjat, i desenvolupar la vista graph sobre la nova
classe.
La solució incorpora la nova classe school_professor_nbr (dins el fitxer school.py) no

persistent, basada en una vista PostgreSQL. Fixeu-vos que la sentència SQL està formada
amb un outerjoin per aconseguir que els possibles professors sense cap curs apareguin
a la vista. Fixeu-vos també, que incorpora un camp id_name que és la concatenació de
l‘id del professor amb el seu nom, per poder escollir aquest camp en la vista graph, ja que
del contrari, si hi hagués dos professors amb el mateix nom, la vista graph els agruparia si
prenguéssim el nom com a primer dels camps de la vista.
La solució també incorpora un parell de vistes (tree i graph) dins el fitxer school_view.xml i
l’acció i opció de menú adequades per poder invocar les vistes. Si voleu, podeu incorporar-
hi vistes search per facilitar les recerques.
Una vegada instal·lat el mòdul, si observeu la BD de PostgreSQL, podreu comprovar

l’existència de la vista school_professor_nbr. Les classes no persistents es poden
utilitzar en el disseny de vistes, informes (Writer o JasperReports) i quadres de
comandament.
2.3.2 Quadres de comandament
OpenERP 6.1 facilita la possibilitat de dissenyar senzills quadres de comandament,

ja sigui a nivell d’usuari, personalitzant el seu OpenERP, o a nivell d’incorporació
en els mòduls per a la seva instal·lació.
Els quadres de comandament d’OpenERP 6.1 es confeccionen integrant qualsevol

de les vistes existents a l’empresa. La versió 6.1 divideix la pantalla en dues zones
(left & right) en les quals es pot anar ubicant diverses vistes:
• En el client web, queden situades, inicialment, una sota l’altra dins la zona
a la qual han estat assignades. L’usuari les pot reubicar amb el mecanisme
drag & drop, i disposa d’un botó reset per tornar a la ubicació original.
• En el client GTK, OpenERP les reubica una al costat de l’altra, dividint la

pantalla en tantes columnes com vistes afegides.
De fet, no s’ubiquen vistes, sinó accions (que han d’existir) que invoquen una o
diverses vistes. En cas que l’acció invoqui diverses vistes (apartat view_mode
amb diverses opcions tree, form, graph...):
• El client GTK mostra, per cada acció, la primera de les vistes que indica
l’apartat view_mode de l’acció i presenta un botó que permet anar alternant
amb les altres vistes definides a l’apartat view_mode.
• El client web mostra, per cada acció, la primera de les vistes que indica
l’apartat view_mode de l’acció i no permet navegar pels diferents tipus de
vista definits a l’apartat view_mode.
Disseny d’un quadre de comandament per part de l’usuari
Suposem que l’usuari vol crear un quadre de comandament que incorpori la vista tree dels
professors i la vista graph del nombre de cursos per professor. Fixem-nos que es tracta de
dues vistes sobre diferents objectes d’OpenERP.
Executem l’opció Settings | Personalització | Informe | Definició taulell per crear un nou
quadre de comandament i emplenem els camps:
• Taulell: amb un nom amb significat, com per exemple, Professorat.
• Vista taulell: en blanc, que crearà una vista amb el mateix nom que l’indicat a Taulell quan
l’enregistrem.
• A la graella Vista taulell: afegim les accions que invoquen les vistes que volem visualitzar, i
n’indiquem la ubicació a l’esquerra o a la dreta de la pantalla.
Per a la vista tree dels professors no tenim cap acció que la invoqui unívocament;
disposem, però, de l’acció Professors (identificador action_school_professor) que
invoca les vistes tree i form, que ens serveix per qualsevol dels dos clients, ja que en
primer lloc està el mode tree. Seleccionem aquesta acció, la ubiquem a la zona esquerra
de la pantalla i per títol introduïm el text que es desitja que aparegui al capdamunt de la
vista (per exemple, Professors).
Per a la vista graph del nombre de cursos per professor tampoc tenim cap acció que invoqui
unívocament aquesta vista, però disposem de l’acció Nombre de cursos per professor
(identificador action_school_professor_nbr) que invoca les vistes tree i graph. Pel client
GTK ens pot servir, perquè aquest client ens permet alternar entre els diferents modes, però
el client web només permet veure la vista tree que està en primera posició i no és el que
interessa. Fem-ho, però, per veure’n el funcionament i posteriorment ja ho retocarem.
Tenim el quadre de comandament definit, però no tenim cap opció de menú per invocar-
lo. La definició del taulell incorpora un botó Crea menú que permet crear una opció
de menú que invoqui el taulell. Només cal indicar el nom de la nova opció (Quadres
de comandament) i seleccionar el menú pare (Escola, si volem que el menú principal
tingui una nova opció de menú Quadres de comandament per incloure tots els quadres
de comandament del mòdul Cursos).
Refresquem el menú i comprovem el funcionament des dels dos clients. Tal com hem
avançat, el client web no permet alternar entre les diferents vistes associades a les accions
invocades.
Per incorporar la vista view_school_professor_nbr_graph cal crear una nova acció, fet
que es pot fer en el mateix punt en el qual es selecciona l’acció a assignar al taulell. Cal
anar a modificar el taulell, eliminar de la graella l’acció Nombre de cursos per professor i
afegir una vista creant una acció que invoqui la vista desitjada.
incorpora una possible
solució, a l’arxiu Disseny d’un quadre de comandament en un mòdul
school_20.zip, dins
l’apartat “Mòduls Es vol incorporar, en el mòdul school, un quadre de comandament que incorpori la vista
tree dels professors i la vista graph del nombre de cursos per professor. Fixem-nos que
annexos del web.
es tracta de dues vistes sobre diferents objectes d’OpenERP.
La definició d’un quadre de comandament consisteix en crear una vista form especial, una
acció que invoqui la vista i una opció de menú que invoqui l’acció.
La vista form és especial perquè es defineix sobre el model board.board, específic per
als quadres de comandament, amb arquitectura específica com podeu comprovar a la
vista board_school_professor_01 de la solució proposada. Aquesta vista form conté
dos elements column (esquerra/dreta) en els quals cal ubicar les diverses accions que
invocaran les vistes que ha de mostrar el quadre de comandament.
Per cada acció que cal incorporar en els elements column, cal tenir en compte que:
• En l’atribut name cal indicar l’identificador numèric de l’acció que s’invoca, que és desconegut
(pot variar a cada instal·lació), però que en sabem el seu identificador XML i per això s’utilitza
la sintaxi "%(id)d" en la qual id és l’identificador XML indicat dins el fitxer XML on resideix
la declaració de l’acció.
• L’atribut view_mode permet canviar l’ordre de visualització de les vistes invocades per l’acció,
cosa que no és possible quan el quadre de comandament es crea manualment des d’un
client.
• L’atribut creatable="true" possibilita que des de la vista es pugui afegir registres, cosa que
no és possible quan el quadre de comandament es crea manualment des d’un client.
• L’atribut domain permet indicar el domini de valors sobre els quals s’executa la vista.

FP Dam m10 Material Paper

Uploaded by

Copyright:

Available Formats

You might also like

FP Dam m10 Material Paper

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FP Dam m10 Material Paper

Uploaded by

Copyright:

Available Formats

Informàtica i comunicacions

Desenvolupament d’aplicacions multiplataforma

Primera edició: Setembre 2013

Podeu veure el text legal complet a

En finalitzar aquest mòdul l’alumne/a:

1. Identifica sistemes de planificació de recursos empresarials i de gestió de

2. Implanta sistemes ERP-CRM interpretant la documentació tècnica i identi-

Sistemes ERP-CRM. Explotació i adequació

1. Realitza operacions de gestió i consulta de la informació seguint les especi-

2. Adapta sistemes ERP-CRM identificant els requeriments d’un supòsit em-

3. Desenvolupa components per a un sistema ERP-CRM analitzant i utilitzant

Sistemes ERP-CRM. Implantació

1. Identificació de sistemes ERP-CRM i solucions BI

2. Implantació tècnica de sistemes ERP-CRM: OpenERP

Sistemes ERP-CRM. Explotació i adequació

1. Explotació i adequació. OpenERP: el model

2. OpenERP: la vista i el controlador

1. OpenERP: desenvolupament avançat

Sistemes de gestió empresarial

1 Identificació de sistemes ERP-CRM i solucions BI 9

2 Implantació tècnica de sistemes ERP-CRM: OpenERP 45

Els primers sistemes de gestió empresarial van aparèixer amb el naixement de la

La primera part del títol de la unitat formativa (sistemes ERP-CRM) introdueix el

Així doncs, la unitat formativa “Sistemes ERP-CRM. Implantació” contempla

En l’apartat “Identificació de sistemes ERP-CRM i solucions BI” es presenten els

El mot BI correspon a l’acrònim anglès de Business Intelligence (intel·ligència

L’apartat “Implantació tècnica de sistemes ERP-CRM: OpenERP” ens endinsa,

Què us sembla? Comencem!

En finalitzar aquesta unitat l’alumne/a:

1. Identifica sistemes de planificació de recursos empresarials i de gestió de rela-

• Reconeix els diferents sistemes ERP-CRM que hi ha al mercat.

• Compara sistemes ERP-CRM en funció de les seves característiques i

• Reconeix els magatzems de dades (data warehouse) acoblables i/o incorpo-

• Identifica el sistema operatiu adequat a cada sistema ERP-CRM.

• Identifica el sistema gestor de dades adequat a cada sistema ERP-CRM.

• Documenta les operacions realitzades.

• Documenta les incidències produïdes durant el procés.

2. Implanta sistemes ERP-CRM interpretant la documentació tècnica i identificant

• Identifica els diferents tipus de llicència.

• Identifica els mòduls que componen el ERP-CRM.

• Realitza instal·lacions monoestació.

• Realitza instal·lacions client/servidor.

• Configura els mòduls instal·lats.

• Realitza instal·lacions adaptades a les necessitats plantejades en diferents

• Instal·la i configura, si hi ha possibilitat, algun magatzem de dades adequat

• Documenta les operacions realitzades i les incidències.

1. Identificació de sistemes ERP-CRM i solucions BI

Els sistemes ERP, de l’anglès Enterprise Resource Planning, coneguts àmpli-

Els sistemes CRM, de l’anglès Customer Relationship Management, coneguts

Les solucions BI, de l’anglès Business Intelligence, conegudes com a solucions

Abans d’entrar en la instal·lació, configuració, explotació i adequació de sistemes

1. Els tipus de llicenciament actuals.

2. Els tipus de desplegament (implantacions) actuals i requeriments associats.

3. Les funcionalitats normalment proporcionades per les aplicacions

4. Els principals productes existents en el mercat.

1.1 Llicències de programari

Una llicència de programari és l’autorització o permís concedit pels autors

Per programari lliure (free software) entenem aquell programari que