Archive for December, 2008

Dokeos Latinoamérica (ahora BeezNest Latino) y Dokeos Bélgica

December 30, 2008 Leave a comment

En este mes de Diciembre 2008, he tomado la oportunidad de pasar por Bélgica para las fiestas, para organisar reuniones con varios grupos profesionales y Atomiumcomunautarios acerca de Dokeos u otros sistemas de software libre.

El resultado es bastante bueno: mientras Dokeos Latinoamérica esta creciendo un poco demasiado rápido (6 nuevos empleados en los últimos 4 meses), y por eso la calidad de su servicio ha bajado, se siente ahora que llegamos a un punto donde todos encuentran su celeridad de cruce y contribua de manera eficiente al desarrollo y al soporte a clientes de Dokeos.

Hablamos entonces de solidificar el grupo de colaboradores activos de Dokeos, dando un rostro común frente al mundo de las grandes empresas, y de los planes geniales para 2009 (pero no puedo hablar de ellos, son sorpresas).

Nuestra propia actividad siendo siempre a más de 60% sobre Dokeos mismo, nos aseguramos un nivel de especialización muy alto.

Categories: eventos, proyectos, Spanish

Dokeos en Moquegua CICIS 2008

Del 17 al 21 de Noviembre se llevo a cabo en Moquegua el VI Congreso Internacional de Computacion Informatica y Sistemas de la Universidad Jose Carlos Mariategui, donde uno de los temas principales fue el software libre, donde estuvieron ponentes como Richard Stallman, El día Jueves 20 participé como ponente en represetación de Yannick para dar la conferencia “Dokeos una Herramienta de E-Learning en Software Libre”, la ponencia resultó una novedad interesante para los asistentes.

Categories: Uncategorized

Dokeos outbeats Moodle's activity (for now)

December 30, 2008 Leave a comment

I’ve been asked to provide and article about the Dokeos community progress a few days ago, so I wrote a base and we finally get this piece of news on the Dokeos main page.

The activity of Dokeos has truly increased lately, for 3 reasons. Partly due to an increased activity in the Dokeos 2.0 development. Partly due to the integration in our team of 3 new community developers from around Europe (including Bulgary). Partly, also, because Dokeos Latinoamérica integrated 3 new developers to the team as well, who have been working full-time on Dokeos 1.8.6 for a month now.

All these put together give us that nice little chart (generated by Ohloh) growing past the activity of Moodle (which had been hovering far above us for quite a while). It is too soon yet to see a permanent change in behaviour for Moodle, but I sure am happy to see that we are gaining momentum. I think 2008 is the year I’ve worked the most on Dokeos in my whole professional life (OK, there’s only 5 years of such life so far…), and I think this chart is only the beginning of a long-term tendancy. I’m happy to see everybody’s combined efforts are finally showing up in projects statistics.

Categories: Development, English

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.

Installing OpenERP 5 from Bazaar

December 23, 2008 1 comment

This installation procedure is valid for the development version of OpenERP 5.0.0 (December 2008)

$> mkdir ~/openerp/unstable/5.0 -p
$> cd ~/openerp/unstable/5.0
$> bzr clone lp:~openerp/openobject-server/trunk server
$> bzr clone lp:~openerp/openobject-client/trunk client
$> bzr clone lp:~openerp/openobject-addons/trunk addons
$> bzr clone lp:~openerp/openobject-client-web/trunk client-web
$> cd server/bin/addons
$> ln -s ../../../addons/* .

Starting the server can then be done like this:

cd ..
./ –db_port=5432

…or any other database name (–database=…) and port

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.

Dokeos 1.8.6 alpha released

December 17, 2008 2 comments

This is an unstable release intended to help developers and dokeos fans to try out the new features of Dokeos 1.8.6 from a simple packaged version. This IS NOT to be used as a start for a production installation. No excuse will be accepted in exchange of community support if you *did* install a 1.8.6 Alpha and started using it in production. If you do that, you are on your own. You’ve been warned.

On the other side, we invite you to try out the package for fresh installs as well as for upgrades from test 1.8.5 installs or backup copies of production installs.
To see what this new version has to offer, please see the documentation/changelog.html file inside your packaged Dokeos 1.8.6 alpha.

You can download it here:

Categories: Development, English

Dokeos en Colombia (Bogota y Cali) (by BeezNest)

December 11, 2008 1 comment

Parte del equipo de Dokeos Latinoamérica estuvo presente en Colombia los 28,29 y 30 de Noviembre del 2008:

Dokeos Latinoamérica, con la participación de Yannick Warnier y Michela Mosquera, tuvo dos presentaciones en dos partes del país:


El sábado 28 se realizó la primera conferencia, gracias a la ponencia del Ing. Yannick Warnier y gracias a la organización de la  Universidad Santiago de Cali, donde se llevo a cabo el “II Congreso Internacional de conocimiento libre, desarrollo local, regional y economía solidaria”. Este importante evento se realizó en la cálida ciudad de Cali los días 26, 27 y 28 de Noviembre del 2008, en el cual participaron más de 650 personas entre alumnos, profesores y ponentes internacionales de España, Uruguay, Brasil, Costa Rica, E.E.U.U, Colombia, Perú y Bélgica todos interesados e involucrados en el software libre.

Fue una interesante e importante experiencia para el equipo de Dokeos Latinoamérica estar presentes en el evento no solo por los temas y debates del Software Libre, sino también porque la Universidad organizadora del congreso: la Universidad Santiago de Cali, tiene implementado Dokeos como herramienta fundamental para el desarrollo del aprendizaje para sus alumnos.

Conversando con el Director de Gestión Tecnológica e Internacionalización, el Ing. Fernando Giraldo Montero, quién nos enseño todas las instalaciones de la Universidad y el gran potencial de programadores aficionados a Dokeos, nos comentó que la plataforma esta usada hasta la fecha por 10000 estudiantes.

Ubucon-colombia 2008

“La segunda presentación de Dokeos en Colombia se realizó en la ciudad de Bogotá el día 29 de Noviembre, donde Dokeos fue parte del evento de Ubuntu – Colombia, que presentó el “Ubucon Colombia” en las instalaciones de la Universidad de San Buenaventura, donde según la información y colaboración del Ing. Andrés Felipe, hubo más de 400 personas inscritas y fueron parte en todo el “Ubucon Colombia”, ubicados en los diferentes auditorios de conferencias y talleres.

“Ubucon Colombia” fue un evento en el cual se llevaron a cabo una serie de conferencias y talleres referentes al FLOSS: “Free/Libre Open-Source Software”, enfocadas a tecnologías y herramientas libres con Ubuntu. No pudo faltar Dokeos, una plataforma e-learning Open-Source, usada bajo Ubuntu por la gran mayoría de sus desarrolladores.

Para Dokeos Latinoamérica fue una experiencia motivadora porque permitió abrir nuevas puertas, por su gente amable, generosa y la alegría contajiante de Colombia que fácilmente nos invita a regresar.

Cabe mencionar también que el mismo sábado 29 de Noviembre, tuvimos una reunión interesante con miembros activos de OLCP Colombia donde se trato del uso de Dokeos para el proyecto OLPC, de la piratería por grandes empresas de la licencia GPL y de mejoras posibles de Dokeos.

El equipo de Dokeos Latinoamérica quiere aprovechar en agradecer a todos las personas que, gentilmente, con su apoyo, gestión y colaboración, hizo posible que Dokeos se presente en Colombia y que el equipo de Dokeos se sienta en familia, Gracias!

Moving SCORM API from XAJAX to jQuery

December 8, 2008 2 comments

Yesterday I finished a 20 hours job of moving the SCORM API in Dokeos 1.8.6 from XAJAX to jQuery. The problem with XAJAX is that version 0.5 represents an important change in comparison to version 0.2, that version 0.5 is the only one implementing synchronous AJAX calls, and that upgrading was obviously going to take me some time (possibly very long).

We also decided to go with jQuery uniformally in Dokeos 1.8 and 2.0, so I decided, following a suggestion by Eric Marguin, to move it to jQuery.

The problem there is that, if jQuery allows you to execute GET/POST requests easily, the documentation isn’t clear as to how to pass array variables to the resulting PHP script. So I had to implement a array-serializer of my own. The result looks something like this ugly piece of code:

params += ‘lid=’+lms_lp_id+’&uid=’+lms_user_id+’&vid=’+lms_view_id;
params += ‘&iid=’+lms_item_id;
obj_string = ”;
for (i in item_objectives){
obj_string += ‘&objectives[‘+i+’]=’;
obj_temp = ‘[‘;
for (j in item_objectives[i]) {
obj_temp += item_objectives[i][j]+’,’;
obj_temp = obj_temp.substr(0,(obj_temp.length-2)) + ‘]’;
obj_string += encodeURIComponent(obj_temp);
params += obj_string;
type: “GET”,
data: params,
url: “lp_ajax_save_objectives.php”,
dataType: “script”,
async: false

Where item_objectives is an indexed array.

All in all, the implementation seems to work much better than the previous one (because the async: false param allows me to set the AJAX query as synchronous), but I still want to test it a little more before integrating it into Dokeos.

For the curious about the changes applied, they can be seen in an SVN branch:

Error reporting disappeared in PHP5 when using error_reporting "E_ALL" in VirtualHost

December 6, 2008 Leave a comment

It has been my understanding, since a few years back, that setting

php_admin_value error_reporting “E_ALL”

inside my Apache’s VirtualHost configuration actually permitted to set the error reporting to all types of error.

Recently, upgrading Ubuntu from 8.04 to 8.10 (I don’t know exactly which versions of PHP5 that actually meant), several of our team have seen their error reporting disappear…

I first thought this was related to XDebug, installed on all our computers, but disabling it didn’t fix anything.

After 2 hours of searching for pretty much any topic related to this, we (Daniel, Marco and I) decided to search for “php_admin_value” and related error reporting discussions, and found a post somewhere stating that Apache didn’t know of PHP’s constants when inside the VirtualHost, so we couldn’t use E_ALL nor “E_ALL” (which is a string) as PHP needed the *value* of the constant. The suggest value was something like 2047, but looking at the error_reporting syntax on the PHP website, we discovered that E_ALL is actually equivalent to 6143… Who would have guessed…

Well, believe it or not, for a problem that lasted more than a week preventing us to properly develop our code at full speed, this little change fixed the whole stuff.

So if you are going to use php_admin_value to set your error reporting to report all errors, we recommend you do it the right way from the beginning:

php_admin_value error_reporting 6143

This is such a tricky life…

%d bloggers like this: