OpenERP 6.1 Release Notes

1. OpenERP v6.1 - Release Notes
Table of contents
OpenERP v6.1 - Release Notes
Table of contents
Introduction
Usability Improvements
Objective: making ERP affordable for small businesses
Install, Test and Start Using: No Configuration
A smarter “welcome page”
Ready-to-use, using the new many2one fields
Best practices by default
The Setup Cookbook
The configuration panel
Example 1: Configure the company
Example 2: Setting Up Your Invoicing Methods
Example 3: Create new users
Import Your Initial Data
Automated import and sync from other applications
A smart Import tool for end-users
Easier to Use
Reviewed tooltips
Document status at a glance with the new status progress bar
Simplification of complex screens
Easier to Learn
Books
Drive your Sales & Marketing Activities with OpenERP
Integrate your Logistic Processes with OpenERP
Streamline your Manufacturing Processes with OpenERP
Buzzy ERP: Social, Viral & Mobile
Be Social: Collaborate with Partners
Share your documents easily
Embed content in your website
Improved Email Integration
Automated Email notifications by default
OpenERP Mobile: access everywhere
New Modules
Touchscreen Point-of-Sale
Generic Payroll Engine
Assets
Portal
The New Web Interface Revolution
Challenges & Objectives
New and Improved Features
Fast like a rocket !
The New Kanban View: Everything at a Glance
Customizable Dashboards
Simple and reusable advanced filters.
Dynamic Gantt Charts

2. Technical Improvements
Modularity
New architecture, not reinventing the wheel
New debugging facilities
Framework Improvements (technical)
Speed improvements in the framework (OpenERP kernel)
Multi-thread for scheduled operations
WSGI - Web Service Gateway Interface
Unaccent searches
Proper UTC storage of date and time values
Streamlined addons and web addons management (Embedded)
Business Applications Improvements
Projects & Tasks: Improved productivity
CRM: Improve your sales productivity
Simple and fast access to your tasks - Todos based on tasks in CRM
HR Recruitment: improved screens
Accounting & Finance
Invoicing Methods
Contract management based on analytic accounts
Delivery Price Management
New Outlook Plugin
Cleaning & Maturity (technical)
Improved tests and testing tools
Manual & automated testing made easy: RunBot
Improved Test Coverage: 65% and counting
Community feedback, bugfixes & small features
Improving developers’ life
Objects Instantiation & definition
Simplified field declaration
Developer mode
YAML Tests Improvements

3. Introduction
OpenERP 6.1 includes countless contributions from partners and community members, for which we are
very grateful: bug reports and bug corrections, translations, suggestions, new features, etc.
The release brings strong usability improvements, new features and a lot of framework cleanup (core
engine and web interface).
Our focus has been to make OpenERP easier and faster to deploy and configure than ever, and to
improve and cleanup the underlying code base (mainly the core framework and web interface). The biggest
challenge was certainly the complete rewrite of the web interface from scratch using a better architecture,
and leveraging state-of-the-art web technologies. It was a 70+ man-months job which we achieved in less
than 8 months with a team of 9 developers.
As usual, all our developments are released under the open source AGPL licence.
Enjoy your first look at OpenERP 6.1! We are looking forward to your feedback and impressions!

4. Usability Improvements
Objective: making ERP affordable for small businesses
We want OpenERP v6.1 to be easier to install, to configure and to use. For years, full featured ERPs
have been only accessible by large enterprises with big budgets. We think we can change the market with
OpenERP and provide all the features necessary to be a comprehensive ERP solution, while keeping the
software easy to use with affordable implementation costs.
In order to design robust software, our usability experts organized user testing sessions with lambda users
to identify what could be simplified in OpenERP. For the v6.1, we wanted new users to be able to test the
software without having to configure anything. OpenERP is now ready to use out-of-the-box and the
configuration wizards can be optionally launched afterwards. A new user can create their first sales order in
two clicks after the installation!
Install, Test and Start Using: No Configuration
A smarter “welcome page”
In order to speed up the startup process, we sped up the installation of a new database: 2x faster than
V6.0 for local installation and 2 seconds for OpenERP Online (Test here: http://www.openerp.com/online/).
After having created your initial database, you are directly logged into the application. The initial welcome
page reminds you of your credentials to connect to OpenERP later and helps you quickly select the
application you want to install and test first. In only one click, you install the first application and then
are redirected to the related dashboard. You can directly use the application: there is no configuration
required1 (*) and a 'best practice' setup has been defined by default for every application.
1depending on the modules you install, there is only one configuration wizard which is still required,: it's the
chart of account selection according to your country. If you install a module based on accounting, you will
have to answer its wizard.

5. Improved dashboards to guide new users
One click after the installation, you are redirected to the dashboard of the application you want to test. The
first menu and dashboard you see is the one of the application you are interested in. It's easier to discover
OpenERP in this way, versus evaluating an entire ERP application at the start.
Our goal was for a new user to be able to start immediately start to enter a document (sales order, invoice,
task, ...) after the installation. We noticed during our usability testing sessions that new users do not detect
the menu immediately. In 6.1 there is now a “create” button on every dashboard section so that it's clear
where to click to start creating a document.
Ready-to-use, using the new many2one fields

6. Two clicks after the installation new users can start
creating their first document (e.g. a sales order). But there
are no customers or products registered in the database
yet. So, it was important to be able to easily create, on-the-
fly, a new customer or a product directly from a sales
order.
Most of the beta tests we organized emphasized the same
difficulties as lambda users on the use of many2one
relation fields. So, we completely redesigned the relation
field to now look like a selection box. We also added auto-
completion, quick-create and a “more...” option to
open the search window.
These new features allow new users to create their first
sales order by creating the partner and the product on-the-
fly, simply by entering the name of the customer in the customer field. Of course, in order to allow this, we
had to do a lot of small improvements on main OpenERP documents:
● when you create a partner, it automatically creates an address by default
● when you create a product with only a name, it correctly sets most of the fields: related taxes,
category, income/expense accounts, ...
Best practices by default
Our testing sessions with lambda users showed that it's much easier for new users to adapt to a pre-
existing configuration than to configure OpenERP from scratch. In order to be usable out-of-the-box,
OpenERP v6.1 comes with best practices configured by default at the installation.
Here are some examples of pre-configured environment:
● if you install CRM, sales stages are setup by
default following the 'solutions selling' methodology,
● if you install HR periodic evaluations, a generic
employee evaluation form is provided with
questions we made by working with human
resources experts. This is great as most of the
small companies do not even have a periodic
evaluation form for their employees.
● if you install Accounting, default payment terms are
defined out-of-the-box so that you can use them
immediately
These default configurations enable users to: start using
OpenERP without having to configure anything; utilize best
practices even at a small company level; simplify the
configuration process as it's easier to adapt a few
elements than to configure everything from scratch.
The Setup Cookbook

7. The configuration panel
Once you are ready to fine-tune OpenERP to your own needs, you can access the configuration panel from
the administration menu. This panel is a cookbook of all the steps you must follow to configure the system
according to the modules you installed. A progress bar gives you the status of the overall configuration
process.
All the configuration wizards have been reviewed for v6.1 in order to be more business oriented. In total,
we developed 39 configuration steps to cover all standard modules. Below, you will find three examples of
these configuration wizards.
Example 1: Configure the company
The wizard to configure the company in v6.0 looks like the above screenshot:
Using the old wizard new users may encounter several difficulties:
● the setup of the company and the logo is on the same screen, but someone who configures the
company may not have the logo at the right size on hand. So, we split this wizard into two steps:
configure the company then upload your logo,
● the report header and footer are used to enter bank account data for your customer to use for
issuing payments, VAT numbers, etc... This was a big problem in the past: frequently OpenERP
online customers forgot to enter their VAT number in this space and noticed it only after having
printed the first invoice. Unfortunately, they could not update the configuration and reprint the

8. invoice with the correct information, as reprinted invoices always appear like the original print (Note:
this is a legal requirement in several countries)
The new configuration screen looks like this:
Overview of the improvements:
● There is no wizard anymore, simply the normal company definition form, so that users can easily
modify it at a later point-in-time;
● We have added new fields for the VAT and other references;
● The bank account data comes directly from the bank account configuration wizard (that creates
journals, accounts,...);
● All parameters of the company are configured from this screen, entering information in the various
tabs.
Example 2: Setting Up Your Invoicing Methods
The screenshot below shows the wizard used in v6.0 to configure the invoicing method. This wizard sets
the default invoicing method used on sales orders.
A new configuration wizard (shown above) has been introduced to help setup your system according to
your invoicing needs: invoice based on sales orders, deliveries, project tasks, timesheets, contracts, etc
Example 3: Create new users

9. We made numerous improvements in the user definition form in v6.1. The major enhancement was to the
access rights configuration. Instead of assigning a list of groups to users, we created a dynamic view that
represents all the applications. It's now more intuitive, administrators just have to activate the applications
they want to give a user access to. Then, they can specify her role in this application (manager, user ...).
Groups are configured by default, which means that most users don't even have to understand
the concept of group. In the simplified view of OpenERP, we hid everything related to groups. The
administrator can simply grant application access to users without having to understand the underlying
group-based access management.
On a technical point of view, the group system of OpenERP did not change between v6.0 and v6.1, and
its flexibility is still present for those who still need to fine-tune it. We have simply introduced a more user-
friendly interface to manage them. The only small change is that there is now a notion of group inheritance
(e.g. a sales manager is automatically a sales user by default).
Import Your Initial Data
Automated import and sync from other applications
One of the most complex activities when setting up a new ERP system is the importing of data from older
legacy applications. In order to help new customers get started very quickly, we developed new automated
import tools for the following applications: SugarCRM, google calendar. Those import tools are based on
import_base a module that ease the creation of import tools for any applications.
When you use this feature, OpenERP automatically downloads all information from the third-party software
into your new OpenERP instance. You can launch the wizard several times to update OpenERP with
any recent modifications in your third-party applications. The wizard also proposes to support frequent
synchronizations via an automatically scheduled background task.

10. A smart Import tool for end-users
For companies that have to import data from other applications, we enhanced a lot the import wizard to be
easier to use. Below is a screenshot of the new CSV import feature.
With this new import wizard, users select the CSV file they want to load into OpenERP, and using a new
preview mode, identify how to map data to OpenERP fields. Users are provided with a sample view of data
and the mappings directly below the selected fields.
The export data wizard has also been reworked so that users can export any list of records, modify the
data using familiar spreadsheet applications (e.g. to cleanse the data) and re-import the data back into
OpenERP again. OpenERP will automatically detect which records should be created as new and which
records should be updated.
Easier to Use
Reviewed tooltips
OpenERP received a lot of feedback from our training sessions, our OpenERP online customers and our
Launchpad contributors on areas and concepts that were not easy to understand in OpenERP. We used
this feedback to refine terms, documentation and tooltips that needed to be improved for better clarity. We
reviewed many of the tips displayed on the top of screens, tooltips on fields and terminology within the
application.
Also some terms have been renamed to better match the concept or the wording used in the industry. For
example: The terms "Real &Virtual stock" have been replaced by "Quantity On Hand & Forecast Quantity"
Document status at a glance with the new status progress bar
It is often difficult for new users to understand the business flow of each document. As an example, the
status of a warehouse picking list goes through: 1.Draft, 2.Confirmed, 3.Available, 4.Done. In our user
tests, many of the users thought the picking list was completed when the status was Confirmed.
We believe every document flow must be understood very clearly, and as easy to follow as the typical
steps you go through when buying products on a well-designed e-commerce website. In order to help users

11. understand where they are in the lifecycle/process-step of a document, and identify the previous and next
steps, we replaced the usual status field by a progress bar that shows all steps and highlights the current
one. The examples below show what it looks like for pickling list that is ready to process and a sales order
in exception.
Simplification of complex screens
Our usability experts reviewed the most complex screens of OpenERP to make them easier to use. We
cannot detail all the screens here but just to give you an example, we show the delivery grid configuration
below.
Defining carriers, delivery methods, delivery grids and delivery grid rules was quite complex in v6. We
need this complexity to handle all the possible cost computation on the delivery orders (based on weight,
free based on a maximum amount, by country, by region...). In v6.1, we made a simplified version of the
delivery grid for companies that have basic needs. From this screen, the user can activate all the rules and
get all the features of the v6 screen.
Easier to Learn
Books
A lot of effort was made to make OpenERP easier to use and more affordable to integrate. But we know
enterprise management can require very complex flows and some users will still face some difficulties
integrating OpenERP into their IT topology. That's why we worked on a new series of six (6) books for end-
users, that cover most of the management and business activities in OpenERP.
● Drive your Sales & Marketing Activities with OpenERP
● Integrate your Logistic Processes with OpenERP
● Streamline your Manufacturing Processes with OpenERP
● Open Source Accounting with OpenERP
You can purchase these books on Amazon or through our online store:
● http://www.openerp.com/catalog/150
We also updated our online documentation on: http://doc.openerp.com
Certified Training Partners

12. With this release, companies now have a software solution that is complete and simple to use, and have
books to learn by themselves at their own pace. But an ERP in the end is still an ERP: it's quite complex
because companies have complex business processes and needs. In order to train more people on
OpenERP, we launched the Certified Training Partner program with our main OpenERP partners, to
have established OpenERP certified training centers all around the world. Finally, you don't have to go to
Belgium anymore to get quality OpenERP training!
In the past 5 months of 2011, we have opened 16 new training centers worldwide in coordination with
OpenERP partners.

13. Buzzy ERP: Social, Viral & Mobile
Be Social: Collaborate with Partners
The relationship between people changed a few years ago with services like facebook, google+ or twitter.
Individuals are now strongly connected to each other, and can share information very quickly, collaborate
on projects and organize events just in a few clicks. We think the next generation of management software
should allow companies to work online in a collaborative way with their partners, customers and suppliers.
We improved OpenERP v6.1 to enable companies to better collaborate and communicate together:
● when you work with resellers, they can check the current availability of your stocks levels online,
order products, control invoices and deliveries, etc... They can easily be up-to-date and informed
with everything you do and all your information can be directly integrated in their own management
software,
● when companies send an invoice to customers, the customer can directly import it as a supplier
invoice in their accounting system instead of recording it manually, and then just validate it. The
customer can also pay the invoices online,
● when you work on a project with business partners, everyone can work off the same list of tasks,
and you can share documents related to the project, etc.
● when you need to buy supplies, services or goods, you just create a request for quotation in
OpenERP and confirm it. Your supplier can receive an email with the PO requesting them to provide
a quote for what you need.
Share your documents easily
When you are viewing a list of filtered documents, you can press the share icon ( ) to share these
documents with anyone. When you do that, OpenERP asks for the email addresses and whether you wish
to grant the recipient read-only or a read-write access.
As an example, this feature allows you to:
● grant read-only access to your calendar when
someone wants to have a meeting with you
● grant access for the tasks of a project to a customer,
so that both of you can easily collaborate on a project,
● export invoices to your customers or suppliers and
allowing them to reprint them and track their status,
● give visibility on your product and stock levels to your resellers,
● export support tickets and timesheets so that your customers can control what has been done, ...
Users who want to benefit from this feature should install the “share” module.
Embed content in your website
Any part of the OpenERP web client can be embedded in a website, or another application, by simply
inserting a small javascript code snippet provided by OpenERP. This allows companies to easily:
● insert contacts form into a website which is directly connected to OpenERP,
● export statistics or graphs in a portal or in your website, etc.
This feature is also part of the “share” module.

14. --- screenshot one ---
Improved Email Integration
In version 6.0, several modules provided email capabilities within OpenERP, with most of them using their
own way of storing and representing emails: incoming emails (mail_gateway), marketing campaigns email
and email templates, emails sent from CRM documents (Leads/Opportunities), etc. This was somewhat
confusing to many users.
In v6.1, email integration has been unified into a single and improved email subsystem. All email-integrated
modules now use it and share the same storage and features, including:
● per-database configuration of outgoing and incoming mail servers
● a configurable mail delivery agent, scheduled to deliver pending emails in batch
● a clean and simple framework (API) to send emails
● a common editor for composing emails
● an option for using email templates for auto generated emails in the composition assistant
● no duplication of email attachments
● indexing of email content
● integration with mail clients like Thunderbird and Outlook (you can easily push emails from your
inbox into the system and attach them to existing documents or create new ones)
--- screenshot of emails displayed on the partner form ---
Automated Email notifications by default
The main business workflows now automatically send email notification upon confirmation by default:
● confirming a sales order will send an email to the customer to acknowledge the order,
● confirming a purchase order will send an email to the supplier with the content of the order,
● when an invoice is validated, an email is sent to the customer/supplier with links to see the invoice
or even pay it online (we reduced our customer aged balances by ten days at OpenERP SA since
we setup this feature in production)
Technically, these notifications are also enabling the EDI process, as they carry the unique EDI identifier
that can be used to automatically retrieve and import the document into another system. The simplest way
to perform an EDI import is to open the Online Preview of the document and look at the “ Import” options
detailed on the right side-bar. This is explained in more details in the next section.
Here is a sample email notification for a new Customer Invoice:

15. Online Preview of exchanged documents by default
When a document is sent to customers or suppliers, thanks to the automated notification they receive a link
(e.g. View Invoice) to preview the document online, review it, and possibly confirm the EDI import of the
document in their own system. Below is an example of a customer invoice:

16. From this screen, customers can:
● print the document
● pay online (for invoices and prepaid sales orders)
● import the document into their own ERP or management software (the actual EDI import)
To push a document into a recipient’s own management software, they have three (3) alternatives:
1. If they already use OpenERP, providing the link the destination OpenERP instance is all that is
required. For example, a customer invoice will be instantly imported as a draft supplier invoice into
the target database.
2. If recipients use a third-party management software, the document is provided in a modern
and simple electronic format (JSON) to make importing it very quick and easy. We expect that
community users will quickly develop additional connectors to import OpenERP documents into 3rd
party specific systems.
3. It’s also possible to create a new OpenERP Online instance in one click, with the document already
imported into it. This is helpful for those who would like to test-drive OpenERP.
We also hope to introduce soon an automated EDI integration gateway, where new documents created
for your customers and suppliers in your OpenERP instance would automatically be imported into their
own OpenERP instances, after having established a connection between them. This capability will really
open a new era of productivity between companies and allow them to cost-effectively connect, exchange
information, and work together.
OpenERP Mobile: access everywhere
OpenERP v6.1 includes an interface to access OpenERP from mobile devices. Currently it only allows
read-only mode, but you can access all your data from the mobile web interface. It's based on the JQuery
Mobile framework, and is provide in the form of a web client addon. You can access the mobile UI from the
a special /mobile landing page. For example use this URL: http://localhost:8069/mobile

17. New Modules
Touchscreen Point-of-Sale
The new touchscreen OpenERP Point of Sale interface:
● is a web client module
● works offline if you have no internet connection to the server and/or you restart the browser
● synchronizes automatically with the OpenERP server when the connection is available
● works on any touchscreen device like an ipod, ipad or any tablet pc.
The current features are:
● selectable products through barcode reader, browsing categories, or text search
● multiple tickets can be recorded at the same time
● multiple payment methods allowed

18. As it is a web client module, it’s very easy to extend the Point of Sale module to add new features or extend
current ones (credit card payments, restaurant tables management, ...)
You can get more information about this module here: http://www.openerp.com/products/pos
Generic Payroll Engine
This new module includes a generic payroll engine that handles everything required to compute paychecks,
the taxes to pay, etc. The following concepts are managed:
● salary rules: are used to compute data like allowances, deductions, net, taxes, contribution
registers, etc
● salary structure: define a set of rules usually applied to a category of employee
● contribution registers: organizations to whom the company or the employee have to pay taxes
● employee and contract: includes everything required to compute the wages and paycheck of the
employee.
● paycheck: used to compute the payroll for an employee for one month. It includes the input data
like the number of working days (that is computed automatically from the holidays management
module), the commissions, the advances, ...
This payroll engine is fully customizable around the concept of rules so that it's easy to create localizations
for different countries. The initial payroll localization we developed are for Belgium and India, and one is
already being written for France by French community members.

19. Assets
OpenERP v6.1 includes a complete asset management module. Its features are:
● support for multiple depreciation methods: linear, progressive, … ;
● generation of the depreciation board as graph or a grid ;

20. ● automatic generation of periodic accounting entries.
Portal
The portal module allows administrators to easily create customized access for your customers and
suppliers to various documents in order to collaborate efficiently. Based on the new sharing capabilities,
you can design custom portals in a few clicks by selecting which resources and what access rights you
want to provide to your partners.
The above picture is a screenshot of the partner portal we provide to official OpenERP partners. From this
portal they can track their support tickets, ask for a database migration and follow the migration progress,
check the status of the leads we forwarded to them, etc... We also developed a way to easily contact or
give access to several partners to the portal and to manage the logins you give to your partners.
Learn more here: http://www.openerp.com/partner-portal

21. The New Web Interface Revolution
Challenges & Objectives
For v6.1, we decided to start the development of a web interface from scratch with a new architecture. The
v6 web client proved too complex to maintain and to improve we thought it was the right time for a complete
re-architecture. Our objectives were to:
● build a strong framework for building web applications on top of OpenERP, leveraging the builtin
features of OpenERP
● primarily leverage javascript instead of a mix between Python and javascript
● use existing libraries from the javascript ecosystem (jquery and plugins, dhtmlx, ...)
● allow any part of the web client to be embedded in external websites or sharable
● allow other webservices or widgets to be ebbded into OpenERP (google maps, ...)
This was a big challenge for us. It was a 70+ man-months effort and we wanted it to be ready for v6.1. We
had to release this new web user interface in only 8 months using a team of 9 developers. The result is
quite amazing and we’re very pleased:
● it has more features than v6.0, with fewer lines of code
● it's faster than the v6 client, and even faster than the GTK client for most operations
● developing new modules is much easier with this new client than before
● many hard-to-solve glitches from the previous version are now gone
New and Improved Features
Fast like a rocket !
Significant effort has been made to speed up the OpenERP web client and it's much faster than the
previous version. The web client is based on a client-side javascript rich application, with minimal
lightweight data requests sent to the web server. This reduces communication traffic and network
overhead.
The New Kanban View: Everything at a Glance
In order to improve the end user productivity, we developed a drag & drop kanban view for some
documents. This new view allows users to easily reorganize their records (tasks, opportunities,
recruitment, ...) while allowing them to maintain a global overview.

22. Below you’ll find the XML code of the new kanban view displayed above:
<?xml version="1.0"?>
<kanban>
<templates>
<t t-name="kanban-box">
<div class="oe_employee_vignette">
<div class="oe_employee_image">
<a type="edit"><img t-att-src="kanban_image('hr.employee', 'photo', record.id.value)" class="oe_employee_picture"/></
a>
</div><div class="oe_employee_details">
<h4>
<a type="edit"><field name="name"/> (<field name="login"/>)</a>
</h4>
<ul>
<li t-if="record.job_id.raw_value"><field name="job_id"/></li>
<li t-if="record.work_location.raw_value"><field name="work_location"/></li>
<li t-if="record.work_phone.raw_value">Tel: <field name="work_phone"/></li>
<li t-if="record.mobile_phone.raw_value">Mobile: <field name="mobile_phone"/></li>
<li t-if="record.work_email.raw_value"><a t-attf-href="mailto:#{record.work_email.value}"><field
name="work_email"/></a></li>
</ul>
</div>
</div>
<script> $('.oe_employee_picture').load(function() { if($(this).width() &gt; $(this).height()) {
$(this).addClass('oe_employee_picture_wide') } }); </script>
</t>
</templates>

23. </kanban>
Customizable Dashboards
Dashboards of each application are now fully customizable directly from the user interface. You can change
the layout of the dashboard (1, 2, or 3 columns), insert or remove some info (lists, graphs, ...) using your
custom filters, rename or drag & drop the elements.
Simple and reusable advanced filters.
The new web client allows you to create, use and store complex filter expressions like:
● sales analysis grouped by countries on:
○ sales with order date between March and May 2011 AND
○ having a product in the category "computers" OR
○ having a product = 'iPad'
● AND the order concerns customers in one of the countries in Europe
Filter expressions use normal fields and not only character fields, which is more convenient to create
expressions based on dates or relationship fields. If you save a filter and reuse it later, the filter appears
in the same way so that you can easily modify it for different needs.
Dynamic Gantt Charts
Gantt view has been completely replaced by dhtmlx Gantt widget. Gantt supports filtering and grouping
through buttons of the search window. We added constraints between the parent and children elements but
you can move the whole group by using shift drag & drop. We also added progress bar inside an element

24. of a Gantt chart and dependencies between elements.
Technical Improvements
Modularity
OpenERP addons are now automatically also web addons. They may easily extend the user interface by
defining new widgets or extending already existing widgets. An inheritance system similar to the one used
in python is available at Javascript level. They may also define new views or new types of client-specific
actions.
With this approach one can easily enhance the user experience of any functional addons.
To get inspiration, have a look at the web-enabled modules that are part of the standard distribution: pad,
point_of_sale, share, edi...
In fact, the new web interface is simply a set of such addons, all named web_* and located in the openerp-
web project. The modular architecture is used to split the major features in separate modules.
New architecture, not reinventing the wheel
The Javascript ecosystem is growing very fast, and the new web interface tries to leverage a lot of existing
open source Javascript components by using external open source libraries like jQuery, many jQuery
plugins, DHTMLX, Raphael and other libraries such as underscore.
New debugging facilities
The new web client comes with enhanced debugging capabilities. Not only is it able to leverage the existing
Javascript debugging tools of modern browsers, but it also includes new and enhanced developer utilities.
Because it is now a fully-fledged Javascript application running in your browser, the 6.1 web client can
be easily introspected using your preferred browser’s developer tools. You can set live breakpoints, step
through any function or event-handler, watch the data loading requests as they are sent to the server and
their response, etc.

25. In additional to generic Javascript and Web debugging tools, OpenERP 6.1 also features a debug mode
with developer tooltips on every field, and a very handy debug menu giving one-click access to edit the
current action or view. Have a look at improving developer’s lifes for more details!

26. Framework Improvements (technical)
Speed improvements in the framework (OpenERP kernel)
The cache implementation used for frequently called model methods has been rewritten. It is now simpler
and faster.
We have put a lot of effort to change the osv_memory (now called TransientModel) implementation. It is
now a special case of the normal osv (now called Model) class. This means it is actually stored in database
just like a regular Model, but will be deleted automatically (after some amount of time, or after some
number of records have been created). This approach provides a lot of benefits:
● only one underlying code, easier to understand and maintain
● the same constraints associated with a regular Model are enforceable, e.g. foreign keys
● better performance (the previous code was not performance-tuned)
● the server is almost completely stateless (there are still some caches)
The Web Service Gateway Interface (WSGI) layer makes it possible to run the OpenERP server as an
application served through a WSGI-compliant web server. Together with the almost stateless nature
of the OpenERP server, this means the WSGI-compliant web server can run multiple processes of the
application: you can finally make use of all those CPU cores! For instance, using Gunicorn, it becomes
straightforward to maintain, say, 4 concurrent processes to handle requests. Gunicorn will monitor the
processes and fork them as needed. It can also kill a process after a number of requests have been
handled, preventing possible memory leaks to affect the system. (As the cache mentioned above are
seldom written, a simple strategy is to kill a worker process whenever the cache has to be invalidated.)
Several things have also been done to shorten database creation time. Instead of using the full power
of the framework when loading the translations, we can directly write in database (we don’t expect
ir_translations to be inherited in a meaningful way at database initialization time). Another improvement
is to cache (i.e. dump and restore) the resulting database. This is something we already tried on the
OpenERP Online and works pretty well.
We did the performance tests on a database having a number of sales orders.
● installation of a new database in English
● installation of a new database with a language pack
● second installation of a new database
● loading a partner form from the web client
● reading 1000 orders at once
● reading 100x 10 sales orders
Multi-thread for scheduled operations
Each background job operation (cron tasks) is now launched its own separate thread so that they can
be launched in parallel. This avoids having long running processes like the MRP scheduler make other
cron jobs wait for a long time. The implementation is safe for load-balanced servers running on different
machines: each job will only run once every time it is scheduled, even if multiple processes are running.
WSGI - Web Service Gateway Interface

27. The service layer of OpenERP server has been modified to be compliant with the Web Service Gateway
Interface (WSGI). Using WSGI makes it possible to run the server as WSGI application, using any WSGI-
conforming web server. We also have made room to accommodate a future JSON-RPC transport, in
addition to the existing XML-RPC one.
Unaccent searches
The OpenERP Server can use the unaccent PostgreSQL contrib module (or actually any installed function
named “unaccent”) to perform search operations ignoring accented characters. The server must be started
with the --unaccent flag if you want to activate this feature.
Proper UTC storage of date and time values
In earlier OpenERP versions, date and time computation were performed in the local timezone of the
machine on which the OpenERP server was running. This had a number of drawbacks, such as preventing
an easy relocation of the OpenERP, and possible issues with timezones using Daylight Saving Time
(timestamps in Daylight Saving Time areas may sometimes refer to two different instants in time - requiring
very careful handling for all date and time computations).
OpenERP 6.1 introduces the best practice of always handling date and time information on the server-side
as UTC timestamps - safe for storage and properly unambiguous. Conversions of date and time values into
the user's timezone are only done at the very last moment when they are displayed, mainly in the clients.
This implies a certain number of important consequences that developers should be aware of:
● At server level (framework and addons):
○ The OpenERP server forces the Python timezone to UTC as soon as it starts. This means all
datetime-aware Python libraries will always use UTC timestamps by default. The server also
exchanges UTC date and time values with the clients.
○ The only case where the user-defined timezone is used on the server side is for printing
reports, because that implies rendering a final value to display to the user.
○ Addons code should only ever deal with pure UTC date and time values
● At database level:
○ Date and time values are exclusively stored in the database as UTC using the "timestamp
without timezone" type, in order to prevent any sort of timezone conversions by the database
engine. The database is normally never used to generate new timestamp values (e.g. with
now() ), this is done in Python. If the current time is ever needed in a database query for
comparison purposes, now() at time zone ‘UTC’ must be used instead. This has the nice
property of not depending at all on the configuration of the timezone of the database.
● At client level:
○ Due to the limited native timezone capabilities of Javascript, the 6.1 web client cannot
use the "Timezone" that is set in the user preferences, and always renders value in the
local timezone of the browser (usually the timezone of the operating system). The same
timezone is of course used also for picking date and times in date widgets.
○ The desktop client (GTK) will render date and time values according to the "Timezone"
configured in the user preferences. If no timezone is selected, it will render values in the
server-side timezone: UTC. The local timezone of the operating system is used when
picking date and time values in date widgets.
Based on the above rules, it is obviously critical to properly set each user’s timezone, and equally
important to have it match the operating system timezone, in order to get the expected results in
OpenERP 6.1.

28. Streamlined addons and web addons management
(Embedded)
One of the advantages of the new web interface architecture and the server WSGI capabilities is that it
becomes trivial to embed the web interface as a WSGI service running in the same process as the regular
OpenERP server. There is no need to manage a separate “web” process anymore, even though it is still
possible to do it thanks to the built-in server integrated in the “web” project.
Here is a little bit of explanation on how this works.
In order to deploy OpenERP from the source, you will usually use the three main OpenERP projects:
● the server project, hosted at repository lp:openobject-server/6.1 (post-release URL)
● the web interface project, hosted at repository lp:openerp-web/6.1 (post-release URL)
● the functional addons project, hosted at repository lp:openobject-addons/6.1 (post-release URL)
You can download the tarball that contains all three repositories in a single package or download the three
repositories separately. When all projects are packaged together what happens is simple: the contents of
the functional addons and web addons (the web interface is simply a series a web addons) are all merged
together inside the addons subdirectory that is located inside the openerp/addons directory of the main
server project. They all appear as a unique list of OpenERP modules, core, web and functional ones mixed.
In that configuration, running the complete OpenERP service is as simple as starting the openerp-server
program at the root of the package, without any special configuration (except of course the database
parameters).
If instead of you'd like to keep the various repositories separated (for example in a development
environment), you must ensure to pass the required --addons-path command-line parameters to indicate
where your functional and web addons are located or to set it equivalently in the configuration file. A typical
invocation would be:
./server/6.1/openerp-server --addons-path=addons/6.1,web/6.1/addons
(Watch out, the web addons are located in the addons subdirectory fo the web project)
Developers may also find it convenient to use our all-in-one Makefile that helps you download the source
code branches right from the repository, setting up the directory layout and --addons-path for you.
Here is how you can use it from the command line (after installing Bazaar, our source version control
system):
$ bzr cat -d lp:~openerp-dev/openerp-tools/trunk setup.sh | sh
$ make help # << Read the available commands
$ make init-trunk # << Fetch the trunk projects
$ make server # << Start OpenERP Server with embedded Web
Finally, it is still possible to run the web interface as a separate process (e,g, for debugging purposes),
using the openerp-web program located at the root of the web project. You should however know that
some of the web capabilities might be restricted, and in particular you should be sure that all regular
addons which include a web part are visible to the openerp-web process, otherwise their web part will be
unavailable. You can do this by copying them or creating a symbolic link inside the addons subdirectory.

29. Business Applications Improvements
Projects & Tasks: Improved productivity
The new kanban view is the default one to manage your CRM/ Applicants/Task/Issues pipe. This view is
a group of boxes organised into a workflow stage. Each box can be dragged&dropped in next stages of the
pre established workflow policy. For each record, you can edit, define a color, change status, ...
The most important characteristic is that in one simple view you have the necessary information of what's
on your pipe.
In the case of Project management, it’s quickly visible which are your tasks, what is the status of the task
and what you are required to do. It really helps collaboration and productivity. Once you are done with one
task you can just move it to completed or done, according to what you and your team have set-up.
CRM: Improve your sales productivity
Salesmen will love this new view in their CRM. It’s so much easier to see where you stand with each
opportunity. You no longer have to scroll through lines and lines, check and filter; just look for the status
you are interested in. Want to review your lost opportunities, not a problem, just check the column of “Lost”.
Additionally, just drag and drop an opportunity when you’ve done negotiating and it’s won.

30. Simple and fast access to your tasks - Todos based on tasks in CRM
OpenERP developed a to-do application in the CRM that enables salesmen to link their opportunities to a
light task list. This application enables salesmen to have a simple to do list that is pre-filtered on their
own tasks. They continue managing their opportunities as usual and are also able to create a to-do list
directly in the opportunity itself.
We give you the freedom to install it only if you want, as the application does not get installed by default.
So, just access the configuration and install from the features of the CRM selecting "To Do list". After
installing it, an extra tab will appear in your Sales module, called "My Tasks". The good news is that it's
available both on the GTK and the webclient.
Now picture this: a salesman can create a new task in the "My Tasks" menu entry in the CRM. In this list,
he can see all his to do things, the timing, and even the context. This list is exactly the same as the one you
have in Project management. This means that all recorded tasks in the system from project management
or opportunities are grouped in the same view. From this list, the user can see his own tasks, the ones he
directly created and the ones that have been assigned to him. This gives him quick access to all things he
has to do today, this week this month or in the long term.

31. This feature is based on the "Getting Things Done" methodology. It is a way to organize and manage
tasks following the timing and the context of the "resolution of the task". It is for this reason that by
installing this application, a new menu tab is added also in project management.
HR Recruitment: improved screens
We’ve come with a solution for the Recruitment department as well. You don’t have to memorize all
your applicants or go around with a pile of paper with notes and remarks about your applicants, just use
OpenERP. With the kanban view set in place for recruitment, managers and HR can follow the hiring
process and easily change status, according to the decision they take.
Accounting & Finance
The handling of multi-currency cases has been greatly improved in OpenERP, thanks to the contribution
and financing from Camptocamp and Canonical.
● We now have automatic journal entries related to the currency exchange differences at each
reconciliation. The account voucher module has also been reviewed in depth to ease the treatment
of such transactions. This allows you to efficiently manage your customer/supplier accounts in a
foreign currency.
● We have also added a report that briefly shows the unrealized gain or loss linked to a currency. For
example, it could show you the money you'd earn or lose if every invoice you made was paid at
today's rate.
● Finally, the account followup module has also been improved in order to efficiently manage multi-
currency situations: it does not sum “apples with oranges“ and shows all journal entries distinctly per
currency.
Localizations modules:
The system that installs all the elements of a Chart of Accounts (COA) template has been refactored in
order to allow easier extension of its feature coverage. It has also been enhanced and you can now define
a chart template that completes another one. This is very useful if, at installation time, you want to offer a
choice between the classic "Chart of Accounts" or the "Chart of Account for Food industry'. In v6.0, even if
the Food industry COA had 2 new accounts and 1 new tax in comparison to the classic COA, you had to
define the whole common structure twice. Now you can just define the Food COA as an extension of the
classic COA and if you choose it during the installation process, accounts, taxes and tax grids of both will

32. be installed.
Invoicing Methods
You can now choose in only one wizard what is your invoicing policy. In the configuration overview,
configure your invoicing method in the Sales Management section. As before, specify if you invoice on
Sales Orders or on deliveries, in order to define the default method. A new characteristic is that in the same
wizard, you choose if you charge delivery fees.
If you are not a reseller, but a service company and you invoice on timesheet or task work, you can also
choose these options in this wizard. If you choose to invoice on time work, decide if you invoice per day or
per hours worked.
All these options install the right modules so that you can directly use them or configure them according to
your need.
Contract management based on analytic accounts
Since version 4.2 of OpenERP, we use the analytic accounts to manage, invoice and control customer
contracts. This is a great feature of OpenERP but analytic accounts were not easy to understand for
lambda users. In version 6.1, we introduced the concept of contract based on analytic accounts.
Now, you have the following features in order to help you manage your contracts:
● a menu called "Sales / Contracts to renew" that lists all contracts that should be renewed because
the number of hours / days limit is overpassed (like prepaid support contract) or the end date is
passed (like annual contract)
● when a contract should be closed or renewed, OpenERP sets it automatically in pending state so
that you get warning when people work on this contract (from timesheets)
● once a week, an email is automatically sent to salesmen responsible of the contracts to renew
requesting them to contact the customer to renew or close the contracts and change the state
accordingly.

33. Delivery Price Management
Delivery pricelists are easier to use and there is now a simplified dashboard that helps you create a sales
order much easier, due to the limited requirements you have in your delivery methods.
In your invoicing method (sales policy), you can choose to charge delivery cost to your customer. The
feature can be installed from this option. Then, you can define your delivery method either from your
configuration panel in Settings or from the Warehouse configuration.
How to define delivery methods and pricing:
1) Create a carrier and a product (the carrier is the shipping company, e.g. UPS and the product represents
a particular shipping service from this carrier, e.g. International freight)
2) Specify the cost
3) Choose "Free if more than" if relevant. This means that the delivery price will not be taken into account if
the order total is higher than this amount.
You’re done!
You may also assign a specific delivery method to a customer, to reuse it for each order.
The advanced mode gives you access to the more detailed pricelist grid, similarly to the 6.0 version.

34. New Outlook Plugin
The Outlook plugin of OpenERP 6.0 did not support all Outlook versions. This was partially due to the
technology it was built on (Python), rather than using one of the native Microsoft technologies. For 6.1 the
plugin has been redeveloped from scratch using Microsoft’s .NET technology, in order to get maximum
compatibility with all versions of Outlook (including Outlook 2010, and Outlooks systems connected to
Exchange servers)
The new Outlook plugin is:
● easier to install (no more external dependencies)
● more compatible with various Outlook versions
● faster and better integrated with Outlook

35. Cleaning & Maturity (technical)
Improved tests and testing tools
Manual & automated testing made easy: RunBot
In order to help our development process, we have created a dedicated continuous integration server
called RunBot that monitors every change made on our development branches. This helps execute the
concept of continuous integration testing. Every individual change by any developer (i.e. each commit) is
automatically deployed in a virtual test environment and verified through the following operations:
● A fresh OpenERP server is installed with the modified code, and two databases are created (one
without modules and one with all modules installed). This OpenERP instance is then accessible
online for a few hours, so that anyone can connect and test the modified code live. For example this
lets you double-check a bug correction immediately without even downloading the patch!
● Our automated test suite is of course executed during the installation of the two databases to verify
that no bug has been introduced. The test detailed results can be viewed on the runbot summary
page, and the cell corresponding to that commit turns green or red according to the result.
● The code coverage of our test suite is recorded during the execution of the tests, and the detailed
result are available on RunBot too (see also Code Coverage)
The RunBot summary page gives at a glance a summary of all our development activity, with direct links to
view the related code branches, access the details of each commit, the related bug report, view the number
of pending merge proposals (contributed patches) for each branch, and much more:
You can access our Runbot online at http://runbot.openerp.com
Improved Test Coverage: 65% and counting
In v6.0 we started to integrate a large number of test scenarios in OpenERP, approximately 150 individual
scenarios totaling more than 1800 test steps across all modules. This represented a fair coverage of about
50% percent of all the code.
One of the important goals of the R&D Teams for v6.1 was to continue improving the quality and coverage
of these test scenarios, providing a very valuable tool to make testing simple and cheap for everyone, and
a safety net for developing new features without impacting existing ones.
Test coverage does not of course guarantee the absence of bugs, but a reasonable coverage is very
helpful for preventing regressions.

36. The idea in v6.1 was to improve existing tests to make them shorter and more effective, simulating as fully
as possible a series of real interactions with a user. New features of course came with the corresponding
test scenarios as well.
The net result is a test suite comprising 200 individual scenarios, representing about 1900 test steps, and
covering an impressive 65% of the whole codebase!
The code coverage statistics are available in real-time on RunBot.
Community feedback, bugfixes & small features
In 2011, we handled more than 4200 bugs reports and wishlist requests, which represents more than
20 bug reports on average every working day. This represents a lot of feedback and resulted in many
discussions (more than 250 emails every day) with the community in order to find the best way to improve
the software. The community feedback is very important for OpenERP and allows the software to grow and
mature so rapidly. In order to handle this constant feedback we had to assigned on average four full time
developers to review and respond to Launchpad feedback.
On average we found that 58% percent of the feedback was valid, and resulted in a corresponding
action by our R&D teams (the rest being mostly questions rather than valid bugs or useful suggestions).
Improvement suggestions (i.e. Wishlist) amount for 10% of all feedback, which means 48% of Launchpad
bug reports are handed to a developer directly after validation.
On our Feedback platform, we also received more than 300 suggestions in 2011, out of which dozens have
been implemented.
We have setup monitoring dashboards to control performance in the handling of the main sources of
community feedback, via Launchpad bugs and merge proposals. These Community feedback statistics are
available in real-time on this spreadsheet.
Our goal is to qualify all launchpad bug reports within a few days (not fix them, but validate them) and
review merge proposals within two weeks. We have been quite efficient at managing bug reportson
Launchpad in 2011, but there’s a lot of room for improvement in merge proposals review.
OpenERP R&D teams have to follow the same process as community contributors (i.e. making merge
proposals, to be peer-reviewed and finally approved or rejected by team leaders).
In 2011, we have reviewed more than 2200 such merge proposals, created both by the community
and by OpenERP developers for their daily work (one bugfix or one feature = 1 merge proposal).
In the same interval, more than 2500 branches based on the official project branches have been
created.

37. Improving developers’ life
Objects Instantiation & definition
As of v6.1, model objects are instantiated automatically as a two-pass process. You do not need to
explicitly invoke the model constructor and you don't need to split model classes in two to break circular
references.
In v6.0, we used to write the following code:
class res_groups(osv.osv):
_name = 'res.groups'
_columns = {
'name': fields.char('Name'),
}
res_groups()
class res_users(osv.osv):
_name = 'res.users'
_columns = {
'name': fields.char('Name'),
'group_ids': fields.many2many('Groups', 'res.groups'),
}
res_users()
class res_groups2(osv.osv):
_inherit= 'res.groups'
_columns = {
'user_ids': fields.many2many('Users', 'res.users'),
}
res_groups2()
As of 6.1, this code can be reduced to:
class res_groups(osv.osv):
_name = 'res.groups'
_columns = {
'name': fields.char('Name'),
'user_ids': fields.many2many('Users', 'res.users'),
}
class res_users(osv.osv):
_name = 'res.users'
_columns = {
'name': fields.char('Name'),
'group_ids': fields.many2many('Groups', 'res.groups'),
}
Simplified field declaration
As of 6.1, many2many fields do not require the explicit specification of the relation table and the two relation
columns. All of those can now be omitted, and the system will provide default values based on the name of
the two endpoints, alphanumerically sorted. For instance, we can now use the following minimal definition:
class res_users(osv.osv):
_columns = {
‘group_ids’ = fields.many2many(‘res.groups’, string=’Groups’)
}
Based on the above, the system would automatically use the following default names:
● the relation table will be named ‘res_groups_res_users_rel (‘res_groups’ < ‘res_users’)
● the source foreign key column will be named ‘res_users_id’
● the destination foreign key column will be named ‘res_groups_id’

38. This will work symetrically from any endpoint of the relationship, so these can still be declared on any of the
two endpoints, or on both. Matching foreign key constraints will also be properly created.
On additional benefit of this feature may not be obvious: this makes many-to-many fields inheritable
through the existing OpenERP inheritance mechanism, because the system will automatically use
appropriate names in inheriting classes, avoid ID conflicts and foreign key issues. And of course this works
for the new TransientModel and AbstractModel classes which replace the former “osv_memory”, as well as
for all regular “Model” (osv.osv) classes.
Note: this new automatic naming system only works for one single symmetrical many-to-many relationship
between the source and destination models. For multiple many-to-many relationships between the same
models and for relationships where source and destination models are the same, non-conflicting names
(rel, id1, id2) should still be provided explicitly when declaring the fields, in order to avoid conflicts.
Developer mode
The 6.1 web interface features a developer mode, providing additional tools for developers. The debug
mode is turned on globally by simply appending a ‘debug’ parameter to the OpenERP URL or by clicking
activate developer mode from the about dialog.
As an example, if your current OpenERP URL is http://oe.acme.org/web/webclient/home#id=123 ,
you can enable debug mode by connecting to http://oe.acme.org/web/webclient/home?debug instead.
Watch out for the hash mark (#) in the address, which separates the URL from the “fragment identifier” (a
bookmark within the page). You should not add anything after that hash mark, in fact it’s easier to delete it
and everything that follows, before adding the debug parameter to the URL.
Once in debug mode, you’ll notice that every field has an enhanced tooltip that gives the technical
description of all its properties. You should also spot a new debugging menu that will appear next to the
main title of every view, as shown in the screenshot below. This menu gives you one-click access to
several developer tools, such as an editor for the action that opened this view, an editor for the views that
are currently displayed, direct links to customize the object model or its workflow, etc. A real life-saver!
We also encourage you to explore the Javascript debugging tools of your browser (Firebug for Firefox,
built-in developer tools for Chrome/Safari and Internet Explorer) and particularly the Javascript console and
request/network monitoring panel, as they will provide valuable insight on the internals of the OpenERP
interface and its communication with the OpenERP Server.

39. YAML Tests Improvements
OpenERP implements automated tests in every module to guarantee the stability of the code. A simple
example of a test scenario would be:
● I create a purchase order with 5 PCE (units) of product PC1
● I verify that the purchase order total is 5*450+300 EUR
● I validate the purchase order
● I check that a draft invoice has been generated with 5*450 EUR
The main file format used to develop tests scenarios is YAML. You just need to add a .YML file in a
module to ship a fully automated test scenario that will be executed at each installation of your module on a
demo database. The above scenario would be implemented like this:
-
I create a purchase order for Asus with 5 PCE of PC1, and 1 PCE of PC2
-
!record {model: purchase.order, id: purchase_new}:
partner_id: base.res_partner_asus
order_line:
- product_id: product.product_product_pc1
product_qty: 5.0
- product_id: product.product_product_pc2
Every YAML file is composed of a set of operations separated by a line containing a dash character
(-). If you write a line of text without a particular expression, OpenERP will consider it as a comment to be
displayed when the test is running.
The tag "!record" allows to create an OpenERP object. Since the v6.1 (in trunk), you just need to pass the
fields you want to write as if you recorded them in the user interface. OpenERP will automatically simulate
the default_get and on_change calls to retrieve other fields: shipping address, product unit of measure, etc.
The above code creates a purchase order with two lines.

40. The great advantage of this feature is that it tests and executes all these methods on the purchase.order
and purchase.order.line object: default_get, fields_get, fields_view_get, onchange_warehouse_id,
onchange_partner_id, onchange_product_id.
In your YAML file, you can also add assertions to check the values of a record. These assertion can be
Python code (using unittests) or YAML assert tag.
-
I test that the purchase order total is 5*450+300 EUR = 2550 EUR
-
!assert {model: purchase.order, id: purchase_new}
- amount_total: 2550.0
- state: draft
And you can also use any python code to perform your tests.
-
I validate the purchase order and I check that a draft invoice has been generated
-
!python: {model: purchase.order}
self.validate(cr, uid, ref('purchase_new'))
po = self.browse(cr, uid, ref('purchase_new'))
assert len(po.invoice_ids)==1, "You should have one invoice related to this PO"
That's it!
In order to continuously test the evolution of OpenERP, every commit made by a developer is fully
tested against thousands of tests that are provided in OpenERP by default. See RunBot.