OpenERP v6.

1 - Release Notes
Table of contents
OpenERP v6.1 - (DRAFT) 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 Follow the status of the documents with the new 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 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 Running openerp from the repositories 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

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!

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.

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

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-thefly, 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 autocompletion, 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-thefly, 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 preexisting 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

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

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

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 userfriendly 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.

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 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 endusers, 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

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.

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.

--- 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:

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:

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 recipients 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. Its 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

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

As it is a web client module, its 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.

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 ;

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

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 were 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.

Below youll 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>

</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 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 openerpweb 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 browsers 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.

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 developers lifes for more details!

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 dont 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

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 users timezone, and equally important to have it match the operating system timezone, in order to get the expected results in OpenERP 6.1.

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 insid5e the addons subdirectory.

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, its 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. Its 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 youve done negotiating and its won.

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. 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

Weve come with a solution for the Recruitment department as well. You dont 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 multicurrency 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 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 resseller, 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.

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. Youre 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.

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 Microsofts .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

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.

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 theres 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.

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 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 its easier to delete it and everything that follows, before adding the debug parameter to the URL. Once in debug mode, youll 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.

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. 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.