Posts Tagged ‘OpenERP’

Howto install Odoo on Debian 7 64bit

August 1, 2014 3 comments

This is an attempt at shortening the installation time of Odoo (OpenERP 7) on a pristine Linux Debian system. In particular, we’ll execute this procedure on a 2GB RAM VM from Digital Ocean, a recent, cheap and efficiente hosting provider.

First off, you’ll need to install PostgreSQL. This is important, as the Debian package for Odoo does not install nor configure postgresql at all. Note that defining your first users with postgresql is possibly one of the most frustrating thing in the history of computation, so hang in there and follow these steps carefully.

$ sudo apt-get install postgresql
$ sudo su postgres
postgres$ psql
postgres=# CREATE USER odoo WITH PASSWORD 'odoo';
postgres=# CREATE DATABASE odoo OWNER odoo;
postgres=# ALTER USER odoo CREATEDB
postgres=# \q

This last command gets you out of PostgreSQL. Now try to connect as the user you just created:

psql -U odoo -W odoo -h localhost

If you don’t use “-h localhost”, you will probably get an error like this:

psql: FATAL:  Peer authentication failed for user "odoo"

Don’t panic. Locate your /etc/postgresql/9.1/main/pg_hba.conf file, find the “local all all peer” line and change it to “local all all trust”, then reload postgresql:

postgres$ exit
$ sudo vim /etc/postgresql/9.1/main/pg_hba.conf// find and edit the line that says "local     all     all     peer". Change it to "local all all trust", save and exit
$ sudo service postgresql reload

If you know what you’re doing (which is always better), you can leave things as they are (by default) and connect with the “-h localhost”. That’s just fine.

Now you should be able to connect as user “odoo” (see above). We can now install the basic layers of Odoo itself (but first its dependencies):

$ sudo apt-get install python-dateutil python-feedparser python-gdata python-ldap \
    python-libxslt1 python-lxml python-mako python-openid python-psycopg2 \
    python-pybabel python-pychart python-pydot python-pyparsing python-reportlab \
    python-simplejson python-tz python-vatnumber python-vobject python-webdav \
    python-werkzeug python-xlwt python-yaml python-zsi
# wget
# sudo dpkg -i openerp_7.0-latest-1_all.deb

Note that the “\” at the end of each line is only a special character for continuation from one line to another. You can also remove those characters and put all the packages on one single line, this will work as well.

Make sure Odoo is present by asking the options for the command-line executable:

openerp-server -h

It should *not* return a “command not found” error, but rather a large list of possible commands.

The default configuration file for Odoo is /etc/openerp/openerp-server.conf. It is much easier to edit it now and change the settings, and avoid doing it later. The default config file looks like this;

; This is the password that allows database operations:
; admin_passwd = admin
db_host = False
db_port = False
db_user = openerp
db_password = openerp

Change it to something like this:

; This is the password that allows database operations:
admin_passwd = some_kickass_password
db_host = localhost
db_port = 5432
db_user = odoo
db_password = odoo

Now we’ll ask Odoo to install its database so we can start using it. If you used all the default options, then you should be able to start it *just* like that:

sudo service openerp stop
sudo service openerp start

To try it out, connect your browser on localhost (if you installed it on your computer) or to the IP or domain of the server where you installed it, but on port 8069 (the default for Odoo).

This should load the general Odoo installer.

It will ask you for the admin password (some_kickass_password you configured in the config file), then for a database name (whatever you like) and a password (odoo). It will then proceed to create your database for one OpenERP instance. This will take some time, so relax and leave it be for a while. In the end, it will show you the apps section. Choose whichever you like and let it process the database.

The rest is up to you.

If you are wondering what other configuration options can be set, a very good reference is a page on vionblog. It helped me figure out that one central reference point for OpenERP/Odoo options is the /usr/share/pyshared/openerp/tools/ file (do not modify it, just look).

If you want to configure OpenERP to wor on HTTPS, you should follow this guide.

You can also modify Odoo’s CSS style with this guide.

Categories: English, Odoo Tags: ,

OpenERP to become AGPL

November 17, 2009 Leave a comment

Apparently, the next versions of OpenERP will be AGPL. I could not approve this change enough. The current world is crippled by companies (coined as ‘evil’ by Fabien Pinckaers) who use and modify the software for their own customers without ever contributing a bit of code. This actually makes them parasites of GPL software, instead of symbiotic organisms. We had the same type of problem with Dokeos in the past, and decided to go for AGPL with OpenC2C.

A recent discussion with a FSF group in Chile made me realized that I wasn’t really the only one worried about the parasiting of GPL by ethicless companies, and that even large companies (like celular phones companies) were adopting it to avoid the work made for them by third parties to be disowned from them later on.

An interesting development, if you ask me.

Running OpenERP 5.0.3 from sources on Ubuntu 8.10

September 8, 2009 Leave a comment

$ bzr clone lp:openerp

$ cd openerp

$ ./ -r tag:5.0.3 ../5_0_3

$ cd ../5_0_3/

Open one terminal for the server

$ cd server/bin/

(make sure you have a “terp” user on your system, and that you’re logged as this user, and that there is a “terp” database in your PosgtreSQL server)

$ sudo su terp

$ ./ –db_user=terp –db_host=localhost

Open another terminal for the web client

$ cd web/lib/

$ ./

(this will install all the required missing libs)

$ cd ..

$ ./

Go with your browser to http://localhost:8080/. There you are.

Creating the database and all that is complicated. Have a look at this other article to understand the process.

OpenERP 5 – Creating a chart of accounts – first draft

December 27, 2008 8 comments

Following up on our permanent quest to harness the power of OpenERP, this article will consider the specific challenge of building a chart of accounts.

One of the most difficult things in OpenERP when customising it for a specific country is defining the chart of accounts. Well, the most difficult part is actually that there is no documentation on how to do this…

Although I am no expert in designing chart of accounts, I have spent a considerable amount of time trying to figure out  the structure of the modules, and this is the result of my work, both to avoid me looking into this info again in one year time, and to ease the work of others, trying to provide accurate information all along.

The files structure

A chart of accounts is a module. Generally speaking, as it is considered part of the “localization” of OpenERP, it will be named something like “l10n_chart_xx” where “xx” is the two-letters code of your country. Let’s say I want to implement a chart of accounts for Peru. My module will thus be called “l10n_chart_pe”. In order to prepare my module, I will create a local l10n_chart_pe directory, which will contain the files of my module. When completing my module, I’ll just zip the whole directory and import it into OpenERP. is a necessary file. However, it doesn’t have to contain anything. Generally, in other modules, it will contain the module header with information about the license and who to contact. is also a necessary file. This one, though, needs to be filled. It also needs to contain references to other files used inside the same module.

All other files should be referenced in and the files will depend on how far you want to implement your chart of accounts.

This is an example of how the file should look like:

“name” : “Peru”,
“version” : “0.9”,
“author” : “BeezNest Belgium SPRL”,
“category” : “Localisation/Account Charts”,
“depends” : [“account”,”account_report”,”base_vat”,”base_iban”, “account_chart”],
“init_xml” : [],
“demo_xml” : [],
“update_xml” : [‘account_chart.xml’],
“installable”: True

The name tag should contain the name of your module.

The description tag, although not mandatory, should be used to describe the module in a longer sentence

The version tag should contain the version (two digits) which will appear as an extension to the version number of OpenERP this module is installed in.

The author tag should contain the name of the individual author(s) or the company that invested time to build this module.

The category tag should contain a category representing the type of module this is. In this case, Localisation/Account Charts is the category used for all charts of accounts.

The depends tag is very important, and should list the modules necessary to the installation of this module. Generally speaking, you should be good with the proposed list of modules (“account”,”account_report”,”base_vat”,”base_iban”, “account_chart”), but you might want to skip base_vat or base_iban if you don’t plan on using them.

(Definition to be confirmed) The init_xml tag lets you define some data to be added on initialisation of this module’s installation.

(Definition to be confirmed) The demo_xml tag lets you define a set of demo data to go with your module, that will be installed only if the user checks the “Demo data” box in the Module Installation Scheduler screen.

(Definition to be confirmed) The update_xml tag lets you define a set of data that need to be added to your system upon upgrade with the current module.

The installable tag (to be set to either True or False without quotes) defines whether this module should let the admins install it or not. Obviously, this will be True in most cases.

As you have seen, the update_xml tag contained only one item: the name of an XML file. This file will contain the real data for the account chart, and is the main topic of the following section.


This file will contain the core of the chart of accounts. Although the chart of accounts itself could be split between several files (one for accounts, one for taxes, one for tax codes and possibly many others), we will define them all in one file here: account_chart.xml. We will take care of indicating a clear comment to separate them. Here is what the file should look like, entries excepted.

<?xml version=”1.0″ encoding=”utf-8″?>
<data noupdate=”True”>

Now, inside the <data> tag, we will put a considerable amount of “record” tags. The first series will be for the types of accounts, the secont for the accounts themselves, the third will contain the tax codes, the next one will contain the taxes themselves, and the final section will contain the definition of a template to use inside OpenERP to define other accounts. Each of the following sections is considered to be included inside this <data> tag. The sections follow one another without any kind of specific splitting other than an XML comment

First section: types of accounts

<!– Account types (account.account.type), based on UK minimal –>

<record model=”account.account.type” id=”account_type_receivable” >
<field name=”name”>Recevible</field>
<field name=”code”>receivable</field>
<field name=”close_method”>unreconciled</field>

<record model=”account.account.type” id=”account_type_payable” >
<field name=”name”>Pagable</field>
<field name=”code”>payable</field>
<field name=”close_method”>unreconciled</field>

<record model=”account.account.type” id=”account_type_view”>
<field name=”name”>Vista</field>
<field name=”code”>view</field>
<field name=”close_method”>none</field>
<record model=”account.account.type” id=”account_type_income” >
<field name=”name”>Ingreso</field>
<field name=”code”>income</field>
<field name=”close_method”>none</field>

<record model=”account.account.type” id=”account_type_expense”>
<field name=”name”>Gastos</field>
<field name=”code”>expense</field>
<field name=”close_method”>none</field>

<record model=”account.account.type” id=”account_type_tax”>
<field name=”name”>Impuestos</field>
<field name=”code”>tax</field>
<field name=”close_method”>unreconciled</field>

<record model=”account.account.type” id=”account_type_cash”>
<field name=”name”>Sencillo</field>
<field name=”code”>cash</field>
<field name=”close_method”>balance</field>
<record model=”account.account.type” id=”account_type_asset”>
<field name=”name”>Activo</field>
<field name=”code”>asset</field>
<field name=”close_method”>balance</field>

<record model=”account.account.type” id=”account_type_equity”>
<field name=”name”>Capital</field>
<field name=”code”>equity</field>
<field name=”close_method”>balance</field>
<record model=”account.account.type” id=”account_type_other”>
<field name=”name”>Others</field>
<field name=”code”>other</field>
<field name=”close_method”>none</field>

What do we find here?

First, we have an XML comment explaining what the next section is. Comments are made using “<!–” and “–>”.

Next, we have the first <record> tag, which has a model and a id attribute. Both these attributes are mandatory. Model defines the object model that this record is going to use, and id serves as a unique ID that will be referenced later on by other records in this file. Inside this <record> tag, we find several <field> tags. These tags define additional properties for the record.

The name tag defines the name to be shown to the user inside the OpenERP interface.

The code tag is a unique code that could be used as a reference in other records.

The close_method tag can be a choice of none, unreconciled, balance. These values will define how this account type will be “closed” at the end of the fiscal year. This requires accounting notions to be set adequately. The example above doesn’t apply these settings correctly.

Second section: the accounts

<record id=”chart0″ model=”account.account.template”>
<field name=”name”>Plan de cuentas</field>
<field name=”code”>0</field>
<field name=”type”>view</field>
<field name=”user_type” ref=”account_type_view”/>
<record id=”chart1″ model=”account.account.template”>
<field name=”code”>1</field>
<field name=”reconcile” eval=”False”/>
<field name=”parent_id” ref=”chart0″/>
<field name=”type”>view</field>
<field name=”user_type” ref=”account_type_view”/>
<field name=”name”>ACTIVO CORRIENTE</field>

<record id=”chart10″ model=”account.account.template”>
<field name=”code”>10</field>
<field name=”reconcile” eval=”False”/>
<field name=”parent_id” ref=”chart1″/>
<field name=”type”>view</field>
<field name=”user_type” ref=”account_type_view”/>
<field name=”name”>CAJA Y BANCO</field>
<record id=”chart12″ model=”account.account.template”>
<field name=”code”>12</field>
<field name=”reconcile” eval=”False”/>
<field name=”parent_id” ref=”chart1″/>
<field name=”type”>view</field>
<field name=”user_type” ref=”account_type_view”/>
<field name=”name”>CLIENTES</field>

<record id=”chart121″ model=”account.account.template”>
<field name=”code”>121</field>
<field name=”reconcile” eval=”False”/>
<field name=”parent_id” ref=”chart12″/>
<field name=”type”>other</field><field name=”user_type” ref=”account_type_other”/>
<field name=”name”>Facturas por cobrar</field>

As you might have seen in this example, there is a certain structure defined. We will try to analyse it in this section.

As for the account types, we have a <record> tag with a model of account.account and a unique ID that will later be used as a reference. This <record> tag contains several <field> tags that generally contain a name (that identifies the element) and a ref or eval attribute (that gives the value of the element).

The name tag defines the name that will appear to the user using the chart of accounts.

The code tag is an idnetifier that will appear to the user as well.

The type tag gives the type of the account. For container accounts, this should be set to view. For other accounts, we have used other in this example, but they could be defined as any of the type codes defined in the first section.

The user_type gives another type of reference to the account type. It should match the record’s id attribute as defined in the type itself, in the same type as the one defined for the type element.

(Definition to be confirmed) The reconcile element defines how this account should be reconciled at the end of the financial year.

The parent_id element defines, in case of a child account (depending on another parent account), the id of the <record> tag that matches the parent.

Third section: the tax codes

Taxes combine VAT (or any variation like IVA, IGV, IVG, TVA, BTW, etc) and any other type of taxes. Defining tax codes is like defining tax types. You have to do it before you define actual taxes.

<!– tax codes –>
<record model=”” id=”vat_code_balance_net”>
<field name=”name”>Tax balance to pay</field>
<field name=”parent_id” eval=”False”/>
<record model=”” id=”vat_code_due_tva”>
<field name=”name”>Tax Due (Tax to pay)</field>
<field name=”parent_id” ref=”vat_code_balance_net”/>
<record model=”” id=”vat_code_payable”>
<field name=”name”>Tax payable</field>
<field name=”parent_id” ref=”vat_code_balance_net”/>

<record model=”” id=”vat_code_base_net”>
<field name=”name”>Tax bases</field>
<record model=”” id=”vat_code_base_due”>
<field name=”name”>Base of taxed sales</field>
<field name=”parent_id” ref=”vat_code_base_net”/>
<record model=”” id=”vat_code_receivable_net”>
<field name=”name”>Base of taxed purchases</field>
<field name=”parent_id” ref=”vat_code_base_net”/>

As you can see, this section is quite simple. There should be the same kind of tax code for pretty much any country with a VAT system (or similar).

Although not mandatory, you can define a parent_id of False for the root element of the tax codes.

Fourth section: the template

Although the template deal is something you can use in the Financial Management menu of OpenERP, it is still a mistery to me. However, the following bit of code seems to do the trick:

<!– template definition –>
<record id=”l10npe_chart_template” model=”account.chart.template”>
<field name=”name”>Peruvian PCNorm</field>
<field name=”account_root_id” ref=”chart0″/>
<field name=”tax_code_root_id” ref=”vat_code_balance_net”/>
<field name=”bank_account_view_id” ref=”chart104″/>
<field name=”property_account_receivable” ref=”chart121″/>
<field name=”property_account_payable” ref=”chart421″/>
<field name=”property_account_expense_categ” ref=”chart601″/>
<field name=”property_account_income_categ” ref=”chart701″/>

Where account_root_id references the root record of the chart of accounts, tax_code_root_id defines the root record of the tax code elements, bank_account_view_id references the account that deals with bank accounts (in this case, 104), property_account_receivable references the account that is linked to customer invoices to be paid, property_account_payable references the account that is linked to suppliers invoices to be paid, property_account_expense_categ references the merchandises ordering account, and finally property_account_income_categ references the merchandises sales.

Fifth section: the taxes

<!– tax codes –>

<record id=”tax1″ model=””>
<field name=”chart_template_id” ref=”l10npe_chart_template”/>
<field name=”name”>Impuesto General a las Ventas</field>
<field name=”amount” eval=”0.170000″/>
<field name=”type”>percent</field>
<field name=”account_collected_id” ref=”chart4011″/>
<field name=”account_paid_id” ref=”chart4011″/>
<field name=”base_code_id” ref=”vat_code_base_due”/>
<field name=”tax_code_id” ref=”vat_code_due_tva”/>
<field name=”ref_base_code_id” ref=”vat_code_receivable_net”/>
<field name=”ref_tax_code_id” ref=”vat_code_payable”/>
<record id=”tax2″ model=””>
<field name=”chart_template_id” ref=”l10npe_chart_template”/>
<field name=”name”>Impuesto a la Renta 6%</field>
<field name=”amount” eval=”0.060000″/>
<field name=”type”>percent</field>
<field name=”account_collected_id” ref=”chart4017″/>
<field name=”account_paid_id” ref=”chart4017″/>
<!– impuesto a la renta – chart88 ? –>

The complexity is a bit more impressive here…

Every tax record has a model (as usual), a name, an amount (which defines the amount of the tax in combination with the type tag), a type (which defines the type of amount implied by the tax), an account_collected_id (which references an account from the chart of accounts which this tax is collected from), an account_paid_id (which references an account from the chart of account which this tax is paid to).

Additionnally, and only for some of the accounts (and this is still a black spot of information for me), you can define a combination of base_code_id, tax_code_id, ref_base_code_id and ref_tax_code_id, which all reference a tax type as defined in the previous section.


Using these sections and this summary explanation, and comparing them with the current charts of accounts, you should be able to build something that works for your own chart of accounts…

There are numerous additional options to define extensions to this chart of accounts, but it is difficult to find any meaningful documentation around the OpenERP website, so if you find some, don’t hesitate t leave a comment.

Uninstalling eTiny.egg

December 23, 2008 Leave a comment

If you ever installed Python’s eTiny module for OpenERP, you might want to remove it to install another version. In this case, the solution is to delete the eTiny module’s directory (in /usr/lib/python2.4/site-packages for example).

cd /usr/lib/python2.4/site-packages/

rm -r eTiny-

vim easy-install.pth

and remove the line importing the eTiny module.

Howto run OpenERP 4.2.3’s latest stable version on Ubuntu

November 2, 2008 2 comments

Following a little bit on my previous article on how to install OpenERP 4.2.0 on Ubuntu, this is an article on how to install the stable branch (but latest development version of this branch) of OpenERP, in version 4.2.3.

The Launchpad project for OpenERP is here:

So basically, downloading OpenERP 4.2.3 is done, at the time of writing these lines, like this:

$> mkdir ~/openerp/stable/4.2 -p
$> cd ~/openerp/stable/4.2
$> bzr clone lp:~openerp/openobject-server/4.2 server
$> bzr clone lp:~openerp/openobject-client/4.2 client
$> bzr clone lp:~openerp/openobject-addons/4.2 addons
$> cd server/bin/addons
$> ln -s ../../../addons/* .

These are the dependencies you might want to check on your system before trying to run the system (for both the client and the server):

sudo apt-get install python python-egenix-mxdatetime python-xml python-lxml python libxml2 python-libxslt1 python-psycopg python-pydot graphviz python-pyparsing python-imaging python-reportlab python-gtk2 python-matplotlib

Starting the server can then be done like this:

cd ..
./ –database=ywarnier –db_port=5433

The port might be a problem (trying to connect to port 5432 if PostgreSQL is actually running on port 5432) depending on the version of PostgreSQL you use, and its configuration, so we’re using the port on the command line here.

Starting the client (from a second terminal) is done by getting into the client/bin directory and executing


If all goes well, you should be able to start using it straight away.

Downloading the web client is done this way:

$> bzr clone lp:~openerp/openobject-client-web/4.2 client-web

You will probably need python-pkg-resources and python-turbogears

$> sudo apt-get install python-pkg-resources python-setuptools python-kid

$> sudo apt-get install python-turbogears

I am splitting these two lines because apparently installing python-turbogears directly causes a failure in the package configuration sequence.

To start the web client, just get into the client-web/ directory and launch

$> sudo ./

If you still have your server running over there, this should do the trick.

Quick-change header for eTiny

eTiny (OpenERP’s web server) shows default header images and style that might not really suit your needs.

OpenERP with default style

OpenERP with default style

Being GPL, you can modify that at will, but you have to know how.

Although it’s probably not the best way to do it, you can easily alter the existing images to show something a little different.

This is all done (on a Debian/Ubuntu server) by changing the files in /usr/lib/python2.4/site-packages/eTiny-1.[0.1.1]-py2.4.egg/tinyerp/static (the part between brackets may vary) to suit your tastes.

The important files are

  • css/style.css
  • images/developped_by.png
  • images/mainmenu_button.png
  • images/openerp_big.png
  • images/openerp_small.png
  • images/sidebar_button_bg.png

So just make a backup, open them, change them and put them back in to get a very light (but refreshing change).

Open ERP using blue style

Open ERP using blue style

OpenERP y el mercado peruano

August 24, 2008 3 comments

Dokeos Latinoamérica esta estudiando ahora la posibilidad de adecuar OpenERP al mercado peruano (a lo menos en la parte del plan contable).

Esto brinda mayores posibilidades para empresas e instituciones peruanas de finalmente tener un sistema ERP de grande tamaño a menor costo que las soluciones Oracle y SAP.

Deberiamos entrar en fase operativa con este sistema en el fin de setiembre. Desde ahí empesaremos a proveer esta solución como uno de nuestros productos principales.

Categories: comercial, proyectos, Spanish Tags: , , ,

Caching in eTiny, OpenERP’s web server

I recently learnt that eTiny, OpenERP’s web server, is actually caching pages when in “production” mode (this mode can be changed in the configuration file which is /etc/etiny-server.cfg if you followed the documentation here).

This means that installing some modules may not have a direct visual effect if you have already seen a page before altering it with the module installation.

To avoid caching, you can either change the eTiny server mode in /etc/etiny-server.cfg (to “development” I guess), or simply restart the eTiny server. This will erase the cache.

Of course, none of these methods is actually acceptable once the server is in production, but at least there is a way… (I suppose a way to clean the cache via a script while the server is running would be good).

OpenERP – Studying, contributing and providing services

Following an internal meeting at BeezNest, we decided to officially provide services for OpenERP before the end of the year, through an official partnership with Tiny SPRL, the company behind the product.

We found a lot of little bugs and usability problems, and submitted our first bug report following the little comment by Stéphane Wirtel, one of our acquaintances (through other channels than OpenERP) and an official employee of Tiny SPRL (as a developer of OpenERP).

However, and although we found these bugs and usability problems, we recognise the potential of the product and, in comparison with Dolibarr, find that it is much more applicable in our business model (highly technical complexity more necessary to large companies).

Arnaud has taught me a little bit how ti use the product (to be able to demonstrate it commercially) and we have a strong lead with a Peruvian company through our sister company Dokeos Latinoamérica, so we’re probably going to start soon on this project and a French company that seemed to have needs going above what Dolibarr has to offer.

We found a little… tricky to get into the commercial technique of Tiny (providing the product for free but obviously keeping a series of modules under non-free or non-open license) but it all makes sense in a way.

There are countless things we would like to implement into OpenERP, including some way to get an external widget log time into the timesheet module, but that will all probably have to wait until a few months from now. Let’s hope for the best.

%d bloggers like this: