INFORMATION SYSTEMS have played an increasingly visible role for several years in improving the competitiveness of business. More than just tools for handling repetitive tasks, these are used to guide and advance all of a company’s daily activities. Today, integrated management software is very often the key source of significant competitive advantage.

En algunas ocasiones necesitamos ejecutar informes extremadamente pesados contra una instalación de Open(Tiny)ERP. Las buenas noticias son que en la próxima versión la parte más pesada de estos informes (sobre todo contables y de información sobre stocks) será agilizada notablemente mediante nuevos algoritmos de consulta en la base de datos. La mala noticia es que todavía estamos en la versión 4.2.2. y que algunos de estos informes pueden tardar un tiempo en ejecutarse e incluso dar un error de Timeout en el servidor.

El problema de fondo es que por defecto el lanzamiento de informes desde el cliente espera a que la ejecución del informe termine y presentarlo en pantalla. Durante este tiempo el cliente queda "frito", y si llegamos al fatídico Timeout nos quedamos en ascuas. Lo cierto es que el servidor continua trabajando y elabora el informe.... pero no tenemos forma de recuperarlo....¡diantre!

Hay varias estrategias para resolver este problema. Una de ellas consiste en lanzar un nuevo servidor de OpenERP contra la base de datos original en un equipo potente y ocioso y lanzar el informe contra ese servidor. A mí me ha funcionado razonablemente bien ya que en estas condiciones es más difícil llegar a ver que el período de gracia "caduca".

Otra opción consiste en ampliar el tiempo de espera del cliente lo suficiente (linea 69 del fichero bin/modules/action/main.py), reemplazando los 200 intentos/segundos por un número más alto.

Pero hay otra solución que es la que voy a exponer aquí. Consiste en hacer uso del XML-RPC y lanzar el informe y su recuperación desde un programa externo para almacenarlo en un fichero de nuestro sistema de archivos.

Pongo aquí código de ejemplo y paso a comentarlo a continuación:

import xmlrpclib
import base64

sock = xmlrpclib.ServerProxy('http://localhost:8069/xmlrpc/report')
id_informe = sock.report('terp', 3, 'password', 'module.report.name', [ids])
resultado = {'state':False}
while not resultado['state']:
resultado = sock.report_get('terp', 3, 'password', id_informe)
cadena_pdf = resultado['result']
cadena_pdf = base64.decodestring(cadena_pdf)
fichero_pdf = open('/tmp/fichero.pdf','w')
fichero_pdf.write(cadena_pdf)
fichero_pdf.close()

Las lineas fundamentales son donde se lanza la ejecución del informe (sock.report) donde terp es la base de datos, 3 es el id del usuario admin (podría ser otro usuario), password su contraseña, module.report.name es el nombre interno del informe e ids son los identificadores de los registros para los que lanzar el informe. Así por ejemplo, si fuesemos a lanzar como informe la factura con id 1, esta línea sería:

id_informe = sock.report('terp', 3, 'admin', 'account.invoice', [1])

A continuación se inicia un bucle que comprueba si la variable state devuelta por el método report_get es verdadera. Mientras el informe se está calculando, el valor de dicha variable es False. Podríamos incorporar una línea haciendo que el programa espere 1 o más segundos antes de volver a lanzar la petición.

Al final el informe se escribe en el fichero /tmp/fichero.pdf desde donde podremos recuperarlo.

Continuamos con el post anterior viendo algunos campos relativos a la configuracón de impuestos:

• Impuestos hijos OpenERP permite definir impuestos hijos, algo así como impuestos sobre impuestos. Obsérvese que no es lo mismo definir dos impuestos simultáneos sobre una misma actividad que establecer los impuestos hijos. Cuando se calculan los impuestos hijos se toma la cuota del impuesto padre como base de sus hijos.
  
• Tax on childs traducido como Impuesto depende de sus hijos . Si activamos esta casilla, el impuesto padre no generará lineas de impuestos automáticamente y se calcularán sus hijos como si éste sí se hubiese calculado.
  

• Código de cálculo En algunas ocasiones el cálculo del importe de un impuesto no es porcentual o de una cantidad fija sino que responde a una forma de cálculo más compleja. Es posible incorporar esta forma de cálculo en OpenERP sin necesidad de crear nuevos módulos o cambiar el código fuente de la aplicación. Para ello tendríamos que escribir una pequeña función en Python que nos calculara el importe del impuesto. Para ello podemos utilizar los siguientes objetos y variables: address es un objeto de tipo address con la dirección de facturación si ésta existe, partner idem hacia la empresa (cliente o proveedor) actual, product al producto y price_unit una variable con el valor del precio correspondiente
  

Este sistema de cálculo de impuestos es bastante flexible y permite la configuración de complejos sistemas impositivos y la posiblidad de adaptarlo a las necesidades de cada país. Lo ideal es contar con módulos de localización que permitan empezar a trabajar "sin pensar demasiado", pero es bueno saber que los módulos existen.

Por ejemplo, el módulo l10n_ES_vat define el sistema de recargos de equivalencia incluyendo los campos en empresas y productos pero no ha necesitado de manipulación en el módulo de cálculo de impuestos: sencillamente utiliza la flexibilidad del módulo estándar para definir el comportamiento del recargo ya que tanto la empresa (partner) como el producto (product) son directamente accesibles desde la definición del impuesto. ¡Qué sencillas on las cosas cuando están bien definidas!

Siguiendo con esta serie de posts sobre la contabilidad en OpenERP vamos a continuar viendo como configurar los impuestos (IVA).

Si estamos en España podemos utilizar el módulo l10n_ES_vat que se puede encontrar de momento en tinyerp-community.googlecode.com. Esperamos que en próximas fechas se pueda encontrar también en alguna rama en launchpad.

Dicho módulo, desarrollado por Alberto García y ZikzakMedia, configura el sistema para poder trabajar con un regimen de IVA español y añade además los recargos de equivalencia en clientes y productos (no a todos los productos se les debe aplicar el recargo). El módulo configura una serie de cuentas y códigos de impuestos a modo de ejemplo, de modo que podemos utilizarlos directamente o modificarlos a nuestro gusto.

Vamos a ver ésto con un poco más de detalle. En el menú de Configuración podemos ver 3 apartados: Impuestos, Códigos de Impuestos y Arbol de los Impuestos.



En la primera opción es donde configuramos los impuestos propiamente dichos, en la segunda donde cramos los códigos donde ir totalizando los importes de la base y de la cuota y la última nos muestra en un cuadro resumen los distintos impuestos que tenemos configurado. Existe también la opción de menú Informe Impuestos que nos muestra los totales acumulados (base y cuota) acumulados por período actual y por ejercicio fiscal y en el menú de Informes el wizard de Informes de Impuestos nos permite imprimir ésta información para cualquier período y ejercicio. Esta información nos puede ser de gran utilidad a la hora de confeccionar la declaración IVA si tenemos bien configurados los códigos de las bases imponibles y cuotas.



Vamos a ver un ejemplo concreto: el IVA repercutido al 16%.



Veamos el significado de algunos campos:

• Tipo impuesto. El valor por defecto es porcentaje si bien el campo permite los valores fijo, nada y código python. El valor fijo podría utilizarse para tasas, cánones, etc. mientras que el código python nos permite escribir un pequeño programa para calcular el importe del impuesto en el caso de que fuera necesario. El cálculo del impuesto lo programaríamos en la pestaña Cálculo Especial en la sección Código aplicable. Normalmente ésto no será necesario.
• Tipo aplicable. Lo normal será dejar el tipo en Verdadero, pero yay veces que la aplicabilidad de un impuesto depende de factores externos, etc. Por ejemplo, el recargo de equivalencia se aplica a determinados clientes (que tienen ese régimen de IVA) pero no a todos los productos (el reglamento del IVA describe cuáles sí y cuales no). En ese caso, podemos indicar en Tipo Aplicable la opción código python y escribir un método que defina la aplicabilidad o no del impuesto. En el caso de recargo de equivalencia la aplicabilidad es verdadera si tanto la empresa cliente como el producto tienen definida la variable recargo de equivalencia como verdadera.
  

....continuará......

OpenERP tiene un sistema de control de necesidades de productos basado en una entidad clave denominada aprovisionamientos o procurements en inglés.

El sistema de aprovisionamientos estandariza la solicitud de necesidades de materiales (e incluso servicios) de forma que se pueda proceder de forma conjunta y coherente a su suministro. El sistema de planificación (pedidos de compra a proveedores, ordenes de fabricación, etc. ) centralizan sus necesidades mediante aprovisionamientos, por lo que constituyen estos una pieza clave de cualquier empresa con necesidades de control de stocks (esto es... ¡casi todas!).

Para comprender bien como funciona el sistema vamos a definir los campos que componen un aprovisionamiento. En mensajes posteriores explicaremos cómo se generan éstos y cómo actua el planificador para generar las correspondientes ordenes de compra, etc.



Campos:

• Nombre('name') Como en todas las entidades de OpenERP, los aprovisionamientos tienen un nombre. Si el aprovisionamiento ha sido generado automáticamente por el sistema el nombre lo compone utilizando una secuencia numérica.
• Origen('origin') Es un campo meramente informativo. Permite indicar si el aprovisionamiento surgen desde un pedido de cliente, una orden de producción, etc.
  
• Prioridad('priority'): Actualmente la prioridad asignada a un aprovisionamiento no tiene efectos prácticos desde el punto de vista del programa. Puede servir en el caso de realizarse aprovisionamientos manuales para indicar la urgencia de la misma, pero en cualquier caso será alguien quien valore la prioridad definitivamente.
• Fecha Compromiso, o fecha planeada('date_planned'). Es un campo obligatorio y MUY importante. La fecha de compromiso del aprovisionamiento indica cuando debe hacerse efectivo dicho aprovisionamiento. Una vez que la fecha de compromiso está definida el planificador la utilizará para calcular cuando tiene que realizar los pedidos, fabricaciones, etc. para cumplir con esa fecha dados una serie de parámetros (plazos de entrega, margenes de seguridad, etc.).
• Fecha de cierre('date_close'). Fecha de cierre del aprovisionamiento. Es un campo informativo.
• Producto('product_id'). Producto que debemos aprovisionar
• Cantidad('product_qty'). Cantidad de producto a aprovisionar
• Unidad de Medida('product_uom'). Unidad de medida a la que se refiere la cantidad anterior.
• Reserva('move_id') Es un enlace al movimientos de almacén que ha generado el aprovisionamiento.
• Localización('location_id'). Localización sobre la que se debe realizar el aprovisionamiento.
  
• Método de aprovisionamiento('procure_method'). Este campo es extremadamente importante. Cuendo un producto se abastece desde el almacén (stock), cada vez que vamos a necesitar de éste producto se genera un aprovisionamiento con método Desde el stock o 'make to stock'. Estos aprovisionamientos se satisfacen una vez que se asigna la mercancía. Si no hubiese stock suficiente, el sistema deberá generar un aprovisionamiento Bajo pedido o 'make to order', para poder lanzar las órdenes de compra o producción más adelante.
• Orden de compra('purchase_id'). Si tenemos instalado el módulo de compras, éste añade el campo de orden de compra a los aprovisionamientos. Este campo no es visible por defecto y para verlo hay que añadirlo manualmente a la vista.
• Propiedades('property_ids'). En el caso de estar usando propiedades de productos, en este campo se recogerían las propiedades del aprovisionamiento.
• Ultimo Error('message'). La generación y procesamiento de aprovisionamientos suele hacerse de forma automatizada. Los fallos que se produzcan tratando de realizar o procesar un aprovisionamiento se muestran en este campo. Por ejemplo, cuando el aprovisionamiento debe generar un pedido de compra y el producto no tiene asignado un proveedor.
• Estado('state'). Puede tomar los valores de borrador('draft'), confirmado('confirmed'), en excepción('exception'), ejecutándose('running'), cancelado('cancel'), o hecho('done')

En nuevos post veremos como generar aprovisionamientos manualmente y su integración con el circuito de compras y como funciona el planificador.

We continue our ergonomy improvement process. Here are the latest news:

We have a completly reviewed our wizards to help users to configure their OpenERP system. We have wizards for all profiles: association mgt, auction houses, crm only, accounting company, services mgt, manufacturing industries. Here are two screenshots:


After the new date widget, released a few days ago, we implemented a new widget in the GTK and Web application: progressbar. They are available in form and in tree views. Here is how it looks like in sale orders list.



We put Question Mark at the left of labels for fields that have a tooltip.

We made some layout modifications in GTK:

1. We moved the tab position of all notebooks to top by default in the GTK application. The idea is to be compliant with the web client and allow a better to rendering of views where you put some data above the notebook, see attachment for example of the new product form.
2. Grey background for toolbar to emphasize it
3. Separator and O2M titles in Bold

We are reviewing all views according to the one we made with products, bellow. Note that with the new attrs feature, all fields related to Weights are readonly because we selected a product of type service. (it changes dynamicly if you change the type of the product).



We are looking for ideas to improve the current internal request system of OpenERP. Please fill in a blueprint on launchpad if you have good suggestions. Any other suggestion is welcome too :)

Hello,

We made some changes in modules that will be delivered with the next version. Some modules where in addons (automatically included in the main package) and will be set as extra_addons (to download separetly): multi_company_account, product_extended, product_variant, productivity_analysis, purchase_discount, sale_category, sale_rebate, sandwich, travel

The following module will be in the base distribution (addons) instead of extra_addons: account_analytic_plans, account_balance,, account_budget_crossover, account_date_check, account_invoice_layout, account_reporting, association_vertical, auction, base_contact,, base_module_record, base_report_creator, base_report_designer, board_association, board_auction, board_crm_configuration, board_document, crm_configuration, crm_profiling, crm_vertical, event, google_map, hr_holidays, idea, membership, mrp_jit, mrp_operations, point_of_sale, profile_association, profile_auction, profile_crm, project_gtd, project_retro_planning, project_timesheet, purchase_analytic_plans, sale_analytic_plans, sale_crm, sale_journal, invoice_payment_tab, project_mrp, stock_back_order, stock_invoice_directly

The base modules are growing mainly because we are adding new profiles by default, which are association management, crm profile and auction profile.

A quick note to list some changes made in the framework in the trunk version:


1. To import big files, you can use the option -P when running the server:
tinyerp-server.py -Pa.pickle -dtrunk -i module
It will commit every 100 lines to not slow down the system when importing very big files. If it crash in a big .CSV or .XML file, you can rerun the query above and it will continue after the crash. Very practical to make tests on big imports and fix problems in your initial data.

2. Properties
Properties are not anymore added automatically in views. You have to inherit forms and add the properties in the form like any other field. The tag in views does no exist anymore. I changed all addons module, but you will probably have to modify your own module in this direction.

3. Nested Trees
For objects with tree structure, you can define _parent_store='M2NFIELD' on the object. It will compute parent_left and parent_right automatically so that you can compute on a whole tree in one SQL query instead of doing very slow recursion algorythms. More infos here:
http://www.intelligententerprise.com/001020/celko.jhtml

Use this to speed up all computations on tree structure. For instance, to compute the recursive debit and recursive credit of the account having a parent_left=3,parent_left=22 and all his childs, you can do that in only one query: select sum(l.debit),sum(l.credit) from account_move_line l left join account_account a on (a.id=l.account_id) where a.parent_left>=3 and a.parent_left22;

4. Function fields
Sometimes it's interresting to compute several function fields using one call and not one call per field. For instance, for speed improvement, we should be able to compute fields debit,credit and balance at the same time (same SQL query), which was impossible before. Now, we can do that with the multi argument on fields.function. So several functions fields will be computed at once if they share the same multi argument value. Check how debit,credit and balance are computed with only one function in addons/account.py

Lots of improvements have been made on OpenERP to improve the ergonomy of both our Web and GTK client. Here is a small post on the latest one: date, time and datetime widgets improvement.


In the trunk branch of the GTK client, these new widgets uses masks that are set according to the locale of the connected user. Thanks to these masks, the user better knows how to encode these fields and can not encode something false. You don't have to write the separator character, OpenERP does it for you.

You can also fill in only a part of the widget and OpenERP completes automatically the rest of the field according to the current date and time.


But the best new feature of this widget is the ability to use operations on the date. That will be very helpful for accounting entries encoding or planning. (thanks Camp2Camp for having suggested and worked on this feature). When you press '-', '+' or '=', the system enter in the operation mode and what you write appears on the right until you press tab, enter or escape.


Some examples of operations:

• +2w : adds 2 weeks to the selected date
• = : set to current date/time
• =12w : set to monday from the 12th week of the year
• -3d : decrease selected date from 3 days
• - : clear the date field
• +3m : adds 3 months to the selected date
  

As said in my previous post, now it's possible to place addons outside the bin directory. To achieve this I have implemented few helper function in addons module to get the actual path of the module or other resources (files especially).

For example, if you want to locate your_addon/report/some.xslt irrespective of where the addons is located, you should use addons.get_module_resource function instead of hard coding the filepath.

import addons
myfile = addons.get_module_resource('your_addon', 'report/some.xslt')

One more important change in tools.file_open, though transparent is worth to check. Here is the docstring of the modified method...

def file_open(name, mode="r", subdir='addons', pathinfo=False):
    """Open a file from the Tiny ERP root, using a subdir folder.

    >>> file_open('hr/report/timesheer.xsl')
    >>> file_open('addons/hr/report/timesheet.xsl')
    >>> file_open('../../base/report/rml_template.xsl', subdir='addons/hr/report', pathinfo=True)

    @param name: name of the file
    @param mode: file open mode
    @param subdir: subdirectory
    @param pathinfo: if True returns tupple (fileobject, filepath)

    @return: fileobject if pathinfo is False else (fileobject, filepath)

Please change you modules accordingly to make them compatible with the new custom addons path...

Both subversion and subclipse cache usernames and passwords. Sometimes it is necessary to manually change the authentication information, e.g. to clear the password after it has changed, or occasionally, to update the username.

Anyone that uses subclipse (the subversion client for eclipse) that has needed to change the username or password for a stored repository, knows that there is no obvious way to do this. Luckily, I ran across this post. Unfortunately, it left some important details out.

If subclipse is setup to use JavaHL (which it is by default: check in Preferences > Team > SVN > SVN interface), then the passwords are stored in the same location as if the command-line svn tool was used. For unix-based systems (or using the command-line tool under cygwin), this is in ~/.subversion/auth/svn.simple. On windows it is in c:\Documents and Settings\[username]\Application Data\subversion\auth\svn.simple. It looks like there is one file per repository in this directory (the filename is a long hexadecimal number). This file contains your username and password.
On the other hand, if subclipse is configured to use the JavaSVN adapter, the .keyring file mentioned in the post appears to be located in the eclipse directory (not the workspace, the actually directory where the eclipse executable is found) under configuration/org.eclipse.core.runtime/.keyring. This is a binary file and hence must be deleted.

A few complaints: (1) I don’t like the fact my password is stored plaintext in a location where others frequently have at least read access to (this is especially true in Windows) (2) if the keyring is stored in the Eclipse directory that means all users share the same authentication information. That means someone else on the computer could access my subversion repositories as me!

This seems like a huge security whole.

The documentation of OpenERP is one of our biggest priorities. We currently have the best documentation amongst all open source ERP but it's not enough and I am sure we can do much more better.

We already invested a lot in writing documentation and the result is not as good as we were expected: the software is growing very quickly and writers have lots of difficulties to track changes and write quality documents.

Writing a Good Documentation is Complex


For Years, we have try to make a community based documentation on a wiki where everyone contribute. With OpenERP, we have a strong community but, after years, the community documentation does not reaches our expectations:

• Deprecated compared to new versions of the software,
• Original authors do no maintains what they write / contribute,
• Seems like if we assembled different pieces of unrelated documentations,
• Sometimes contributions comes from people that do not understand perfectly the software,
• Not end-user oriented,
• Some wants to write in English, others in French, Spanish, eso.
• Some have experience only in food industries, others services companies, others manufacturing, eso.

We also tried to make documentations written by our own developpers. The idea was that each time a developer finish a module, he writes the documentation about it in the wiki. It did not work too because:

• Developers have lots of priorities and sometimes a hurry customer is more important than writting the documentation in the wiki,
• Writting a good documentation on a part of the software can easily take 100 hours, most of the developers do not have such a time,
• Some developers do not like to write documentation so the work does not reaches a very high level of quality,
• Most of the time, a developer develop a module for one customer only, so the documentation will be oriented based on one case only.
• A good documentation has to be written by functionnal people that have a strong experience on how they use a particular module in production,

Having said that, we decided to review the way we will write and maintain futur documentations about OpenERP and OpenObject.

The New Process

I had a look at the open source software with the best documentations. Most of these documentations have been fully written in one try by only one or two people / author. After that, the community improved the content with small improvements from here to there.

So I think we'd better have to focus our ressources on some good individuals rather than a global community. But writting a complete documentation (or a complete chapter) can take a long time (we took about 200 hours to write the OpenERP book in french, 280 pages). So we need incentives as to motivate these contributors / authors.

So, we decided to manage all documentations about OpenERP through real books. We will setup a real editing chain with the following actors:

• The editors: will work with authors to review the quality of the book and will distribute in a range of countries through webshops and real bookstores. The editor also define authors contracts and the graphical charts and style. He will manage the collections (set of books).
• The authors: everyone can write his own chapter(s) and propose them to the editor. The editor will make a selection of chapters to publish complete books.
• Re-Readers: will re-read books before publication and work with the editor to achieve a high level of quality.
• Translators: will translate a particular book to their mother tongue based on the english version.
  

Editors will be different according to the coutries. For all french countries, we already contracted our preceeding books with Eyrolles. For the english version, we will create our own edition company as to keep the rights on the text to be able to publish it online for free.

Now, we have our incentives for authors and translators:

• Getting a monthly revenue through author rights based on monthly sales,
• Being published in bookstores with our worldwide distribution channel.

Having established that, this should leverage individuals effort and promote contributions on writing good documentation. As people will be published and paid for their good work, this should promote new authors and translators.

Books are sold in bookstores in different countries and languages, this allow us to remunerate the full edition chain through author rights. It will help us to motivate authors and translators to write more chapters, and improve existing ones.

We had to find a good middle point between selling through bookstores to remunerate authors and publishing online to provide a free version. So, most of our books (depending on the contract we have with the editor in the related country), will be published online some months after their official publication.

Our goal is to create lots of different books for different domains: technical books, marketing management, services companies management, openerp for accountants, ...

Books writing will be our main documentation process. At each new version of OpenERP, we will release new versions of the different books. The editor will organise this and will get revenues for this.

In addition to this, we use a community wiki for all others documentations that are not directly related to the software or for documentations that are "per module". For our main knowledge management system, we use Launchpad Answers, where you can ask questions or reply answers.

Current Status

Lots of things have to be set up to be efficient in this editing chain. As a proof of concept, we wrote the first book with Eyrolles: OpenERP, pour une gestion d'entreprise efficace et intégrée. It was a great success, they expected to sell their printed stock in 18 months and they had to reprint after only 2 months !

This book is already translated to english and some chapters are being added. We plan to release it within maximum 2 months, at the same time of the next OpenERP major version (5.0). We also find translators to translate it in 6 others languages. We are looking for editors in countries we don't have a distribution chanel yet.

Some others books have started being written or are in the pipeline:

• OpenObject: build or customize application quickly, without developments
• Office Productivity: Business Intelligence, Document Management System, Email Integration, Word/Excel plugins, ...
• Pre-Sales & Marketing: based on our new CRM and direct marketing modules

These very firsts books allowed us to setup the rules for clean and systematic processes: defining stylesheet and guidelines, reviewing process, role of the editor, contracts for author rights, findind printing and distribution channels, ...

So the next phases are:

1. Release the english book
2. Create the edition company and hire people within it
3. Define all the processes in details
4. Translate the english book and contracts with authors/translators
5. Work on futur books

The Role of The Community

This documentation writing and maintaining process tends to emphatize individuals efforts from authors and translators. This does not means we think the community is less important for writting documentations. The community remains very important for different reasons:

• The community provides authors and translators because everyone can request to be an author for one or several chapters, no need to write a full book.
• The editor needs readers that will review the book before his official release.
• These readers will be choosed amongst the different contributors in the community.

To improve the quality of books versions after versions, we will extensively work on erratas in the wiki. Community will be able to propose improvement through the errata section.

You can get detailed information about the process in the wiki.

Contact

Contact me if you are interested to contribute in one of these aspects: being an author, being a translator, setting an edition company, ...

We had some requests to improve the speed of OpenERP in the accounting system so that it can easily work with more than one million of entries.

So we did some improvements in the trunk, to speed up the computing process. Here are the result of computations in the current trunk, it's about 20 times faster than the current stable version.

Computing 539k entries, spread in 915 accounts and 24 open periods:

---

Number of accounts: 915
Number of account.move.line: 539096
Computing Balance for Root: 5.83 sec
Computing Debit, Credit and Balance for Root: 5.82 sec
Computing Balance for all accounts at once: 7.07 sec
Computing Debit, Credit and Balance for all accounts: 7.31 sec
Avg computing Debit, Credit and Balance for one account: 0.22 sec

1078k entries with half reconciled, filtering on non reconciled:

---

Number of accounts: 915
Number of account.move.line: 539096
Computing Balance for Root: 9.72 sec
Computing Debit, Credit and Balance for Root: 9.73 sec
Computing Balance for all accounts at once: 11.17 sec
Computing Debit, Credit and Balance for all accounts: 11.19 sec
Avg computing Debit, Credit and Balance for one account: 0.37 sec

1078k entries (=1 million), no filter:

---

Number of accounts: 915
Number of account.move.line: 1078192
Computing Balance for Root: 29.56 sec
Computing Debit, Credit and Balance for Root: 29.07 sec
Computing Balance for all accounts at once: 30.70 sec
Computing Debit, Credit and Balance for all accounts: 30.59 sec
Avg computing Debit, Credit and Balance for one account: 0.67 sec

It has been tested on my personal laptop: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz. This is the time without any pre-computation, cache or stored values. Some partners made modules that pre-computes some data (for instance balance by account/period/state) to speed up this process.

This trunk version does more computation than the stable one because we compute the recursive debit and credit for each account ! Means the debit of an account is equal to his debit+debit of all his childs.

On this new version, you can note:

• computing only the debit of an account or the debit+credit+balance is the same computation time !
• computing the root account or computing all the accounts (including the root) takes nearly the same time !
• I don't understand why, with postgresql, when I double the number of entry, it takes more than double of the time. I still have to investigate.

I find another way to win some seconds in some cases but did not had the time to implement it yet.

The conclusion:

With the new system, all data can be computed for all accounts in one query if the report is well structured. As we don't use pre-computed data, you can use any filter available in the indexes without decreasing performance. So the slowest report for 500k entries will take 7.31 seconds to compute the whole report. On a professionnal server with a tweaked postgresql, I suppose you can decrease this up to 2 seconds for 500k and 10 seconds for a complete report with one million of entries. This is quite fast and the delay is acceptable for a report that computes on all entries.

For browsing the account chart in the tree, it's acceptable too. The first one is slow (up to 10 seconds for the first node with one million of entries) but all others are quite fast. We plan to improve speed of loading the account chart by storing some values like the balance by account, so that it's immeditate, either with very big databases.

It's commited in the trunk on launchpad.

We plan to do the same review and work on the stock management system and production system.

Hello,

I created a subreddit for OpenERP. I think it is very interresting, because you can get all posts talking about OpenERP.

Don't hesitate to contribute and submit your own links


Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print False
False
>>> False=True
>>> print False
True
>>> False == True
True
>>>


Can you explain me why 'False' can to be 'True' ?

False is not defined as a keyword but as global variable.

But in Python 3, it will become a keyword !

What is OpenID?



Why OpenID?



How Do I Create an OpenID?


Example: https://ddprajapati.myopenid.com/

Last week, I told you about the new domain notation. After a little peer reviewing, it appears that this notation is not as good as it seems. The inability to negate an expression (and not just a leaf) is more problematic that I have imagined. Thus, after a tiny discussion with Fabien, we decided to implement a (nearly) true polish notation for the domains. From now, the domains look more like the older ones that in the last week notation. This means there is no more extra parenthesis.
In addition of the classic leafs, you can add operators.

« Wait... what do you name leafs? »
A leaf, is a tuple of 3 elements composed of:

1. a field name
2. an operator (as string)
   
3. a value

Example:

('active', '=', True)
('foo', '!=', 'bar')
('id', 'in', [7, 13, 42, 666])
('id', '=', False)
('name', 'like', 'tiny')


« And which operators are allowed? »
Like the last week notation, the AND ('&') and OR ('|') operators are allowed . Unlike the last week notation, the arity of these operators is fixed to 2.
And yes, the one you have all been waiting for is now in: The NOT ('!') operator. This one has an arity of 1.
For compatibility with existing domains, the AND operator is applied by default.

« So, what looks like this new new notation? »
Some examples:

['&', ('active', '=', True), ('value', '!=', 'foo')]
['|', ('active', '=', True), ('state', 'in', ['open', 'draft'])
['&', ('active', '=', True), '|', '!', ('state', '=', 'closed'), ('state', '=', 'draft')]
['|', '|', ('state', '=', 'open'), ('state', '=', 'closed'), ('state', '=', 'draft')]
['!', '&', '!', ('id', 'in', [42, 666]), ('active', '=', False)]


PS: Tanks to Najlâa and Olivier for the review.

This morning, I was needed to iterate trough a list from the end to the start and getting the index in addition to the value.

For getting the index, it's easy: we use the builtin function enumerate.
>>> a = ['a', 'b', 'c']
>>> it = enumerate(a)
>>> it
<enumerate object at ...>
>>> it.next()
(0, 'a')
>>> it.next()
(1, 'b')


For iterate in the other sens, it's also easy; there is the builtin function reversed.
>>> a = ['a', 'b', 'c']
>>> it = reversed(a)
>>> it
<listreverseiterator object at ...>
>>> it.next()
'c'
>>> it.next()
'b'


Therefore, getting the index with the element in the reverse order would be easy as the combination of the two functions:
>>> a = ['a', 'b', 'c']
>>> it = reversed(enumerate(a))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument to reversed() must be a sequence


Argh! We must transform the enumerate object to a list before passing it to reversed:
>>> a = ['a', 'b', 'c']
>>> it = reversed(list(enumerate(a)))
>>> it.next()
(2, 'c')


It works.
Yes, it works, but there is a problem. It's not evident for everybody but this technique isn't optimized. First we create an iterator object with enumerate, then we convert this object to a list before recreate another iterator object. With a tiny list of three elements like in my examples it's not a pain, but with big lists, it consume a lot of memory by doing a copy of the initial list with the indexes.

The solution is no more complicated but don't use the method enumerated. We simulate his behavior with the method izip from the itertools module and the method xrange. Both methods create iterator, which is our goal.
The itertools.izip method take n iterators in parameters and yield the m^th element of each iterator. Example
>>> from itertools import izip
>>> a = ['a', 'b', 'c']
>>> b = ['d', 'e', 'f']
>>> it = izip(a, b)
>>> it.next()
('a', 'd')
>>> it.next()
('b', 'e')


Thus, we can rewrite the enumerate method like this:
>>> a = ['a', 'b', 'c']
>>> it = izip(xrange(len(a)), a)
>>> it.next()
(0, 'a')
>>> it.next()
(1, 'b')


Now, to reverse the order we just reverse all the izip arguments
>>> a = ['a', 'b', 'c']
>>> it = izip(xrange(len(a)-1, -1, -1), reversed(a))
>>> it.next()
(2, 'c')
>>> it.next()
(1, 'b')


To finish we hide this behind a lambda to have a more readable code...
>>> reverse_enumerate = lambda l: izip(xrange(len(l)-1, -1, -1), reversed(l))
>>> a = ['a', 'b', 'c']
>>> it = reverse_enumerate(a)
>>> it.next()
(2, c)


This simple code has been implemented into openobject-server with the revision 964.

As a reminder OpenERP has three available clients you can use depending on your needs:

• The Official GTK Applicative Client
• The Official Web Client
• KTiny : A quite new but promising one based on QT

Here is a news I rely from NAN-Tic about the new features of KTiny:

Although they haven't made an official release yet, application stability and features are progressing steadily. Here are some of the features you can find in trunk in the subversion repository (note: I hope they will join us and use launchpad for the developments of KTiny) :

• Stylesheets: style your application however you like or put your customer's logo everywhere Wink
• Full text search
• Store client behaviour settings in the server, on a per role basis. Some of the settings include: number of preloaded rows in list views, possibility of loading rows on demand on those views, that means no more LIMIT / OFFSET with reasonable performance (though it has the drawback of not being able to sort by function fields)., Configuring tabs positions, Show/hide system tray icon,Show/hide toolbar

• Store application state information. This means it remembers (per user) column order and width and the sorted column in tree views, and sliders width in forms (dashboards typically).
• Faster form loading by use of a client cache.
• System tray icon with a popup menu giving access to most frequent actions.
• New charts with better design and faster loading (hbar still missing though).
• New (very preliminar/proof of concept) calendar view.
• New web widget that allows embedding maps in contacts, for example.
• Indexable attachment information, including OCRing images.
• Extensible attachments window
• Right clicking in an attachment allows opening with default desktop application or open image (if it's an image, of course).
• Context menu actions for setting current date / time for those widgets.
• Input of formulas in numeric integer/float fields

Note that it's still a development version so it has some known issues but give it a try! We're open to comments and contributions!

You can see some screenshots at http://www.nan-tic.com

PS: Take a look at the shortcuts dialog, you'll find some useful tricks there!

---

We also advanced a lot on the GTK client, some new features:

• Improved binary widget
• Improved ergonomy in editable lists
• Web Browser widget (thanks to Eduard Carreras i Nadal)
• Configurable launcher per application type
• Attachment visible
• Preformated date format

El motor de contabilidad de OpenERP (módulo account) utiliza una serie de entidades para manejar el control de fechas de la información contable. Vamos a describirlas y a establecer algunas posibles estrategias al respecto. En concreto hablaremos de fechas, períodos y ejercicios fiscales.

Ejercicios Fiscales

La información contable se clasifica alrededor de los ejercicios fiscales. Normalmente el ejercicio fiscal activo está almacenado en la información de "contexto". No obstante, si se desea consultar información en otros ejercicios fiscales podemos acudir al wizard "Charts fo Accounts" del menú "Charts" y elegir el ejercicio fiscal a mostrar.



Fechas

OpenERP incorpora varias fechas en los apuntes contables (account.move.line):

• Fecha efectiva: es la fecha del apunte.
  
• Fecha de creación
  
• Fecha de madurez o vencimiento: En el caso de tratarse de una cuenta a cobrar o a pagar.

En las versiones pasadas de TinyERP era posible tener apuntes con distinta fecha dentro del mismo asiento. Si bien este comportamiento no era un bug sino una decisión de diseño en el último Community Developer's Day se decidió imponer la restricción de que todos los apuntes pertenecientes a un movimiento tengan la misma fecha efectiva. Esto equivale prácticamente a decir que es el asiento contable quien tiene fecha y no cada apunte individual, si bien por comodidad se mantendrá la fecha efectiva a nivel del apunte.

Otras decisiones que se tomaron al respecto es que todos los apuntes del mismo asiento compartan ejercicio fiscal (obvio) y período. La fecha efectiva de un asiento o apunte deberá forzosamente pertenecer al ejercicio fiscal correspondiente (no puedo tener apuntes de 2007 o 2009 en el ejercicio de 2008). Sin embargo si que podré tener apuntes en períodos cuya fecha no corresponde. Ej: tener un asiento con fecha de Enero en el período de Febrero. Más adelante veremos porqué ésto se decidió así.

Períodos

Los períodos son la pieza fundamental en el manejo de tiempos y controles de escrituras en OpenERP.

Cuando creamos un nuevo ejercicio fiscal el programa nos propone dividirlo en períodos mensuales (12) o trimestrales (4). La decisión no es trivial ya que dependiendo de qué tipo de información vayamos a solicitar de nuestra aplicación será más conveniente crear períodos más o menos largos.

En principio, deberíamos crearlos con la misma periodicidad con la que generamos nuestra información contable. En muchas empresas la información es trimestral y en otras es mensual. En muchas empresas se presentan informes mensuales pero trimestralmente es cuando se realizan inventarios, se presentan liquidaciones de impuestos (IVA) etc. OpenERP está diseñado para poder solicitar información contable a nivel de períodos (o de fin de período) más que a nivel de fechas. Por defecto no puedo solicitar un estado de cuentas a 14 de marzo, sino que tengo que acudir a fechas de final de período (31 de Marzo en este caso). Existen extensiones y módulos que permiten calcular informes en fechas concretas pero no están dentro de la distribución oficial (por lo menos de momento).

Los períodos pueden cerrarse. En el momento que un período está cerrado no puede realizarse ningún apunte sobre el mismo. Esta funcionalidad está bien para las declaraciones de impuestos: cierro un período, liquido el impuesto y no permito la inserción de nuevos asientos o facturas en el período liquidado. ¿Que hacemos si llega una factura de proveedor correspondiente a un ejercicio cerrado?. El programa nos permite contabilizarla en su fecha real, pero en un período distinto al que le correspondería. De esta manera evitamos que se nos traspapelen facturas y todo queda declarado.

Un truco...

¿Pero que pasa con el último período?. Claro.... si cerramos el 31 de diciembre el último período del año.... ¿cómo hacemos los asientos correspondientes a regularizaciones, ajustes, cierre, etc.? Es frecuente que el cierre de año se produzca varios meses después de terminado... Para ello, se puede crear un período número 13, con fecha de inicio y final el 31 de diciembre donde realizaremos todos estos asientos. El 31 de diciembre pertenecerá a 2 períodos: el normal (que se tomará por defecto mientras no esté cerrado) y el "extra" para ajustes y regularizaciones.