Openerp 6.1 Download

Recently at, we've been setting up several new instances of OpenERP for customers. Our server operating system of choice is Ubuntu 10.04 LTS. Installing OpenERP isn't really that hard, but having seen several other 'How Tos' online describing various methods where none seemed to do the whole thing in what I consider to be 'the right way', I thought I'd explain how we do it.

• Openerp 6.1 All In One Download
• Openerp Server 6.1 Download
• Openerp 6.1 Download Windows 7
• Openerp Gtk Client 6.1 Download

• Official download page of Odoo for Windows, Linux, Sources,.Deb Both Community and Enterprise versions.
• Extracting strings¶. Once strings have been marked for translation, they need to be extracted into POT files, from which most translation tools can build a database. This can be done via the provided gentranslations.sh. It can be called either as gentranslations.sh-a or by providing two parameters, a path to the addons and the complete path in which to put the extracted POT file.

• Apps
  Websites

  Sales

  • Point of Sale

  Operations

  • Human Resources New
  • Manufacturing

  Productivity Tools

  • Communication
  • Marketing New

>>>>> Work in progress <<<<<<<<<<<

A service consists of:* A contract with a start and an ending, manual or automatic renewal within

a period of notice

• An object, an instance of an product with certain attributes like serialnumber, spatials and a type or model that potentially also can holdmethods and communicate with other systems (web service to implement,start and stop a service)
• Other child contracts (it seems to be blocked)

Its possible to create reccuring invoices for a service. A contract can consistof pre paid parts and expended resources during the period.

Please log in to comment on this module

• The author can leave a single reply to each comment.
• This section is meant to ask simple questions or leave a rating. Every report of a problem experienced while using the module should be addressed to the author directly (refer to the following point).
• If you want to start a discussion with the author, please use the developer contact information. They can usually be found in the description.

Released:

Fast OpenERP migration framework

Project description

Warning

ReminderThis tool is complex and highly experimental and is distributed in the hopethat it might be useful, but WITHOUT ANY WARRANTY of FITNESS FOR APARTICULAR PURPOSE. In particular, if you're using OpenERP for your company,you should consider purchasing an OpenERP Enterprise contract that will provideyou with the best and riskless migration path for your database and customdevelopments.

Contents

• Installation
• Mapping file
• Overall migration process
• Contribute
• Changes

This tool has been developped with these initial goals in mind, in thispriority order:

• Merging 2 different OpenERP databases into a single multicompany db
• Migrating from OpenERP 6.1 to 7.0
• Migrating data from a legacy business application (Access, Delphi, etc.)
• Migrating from Dolibarr to OpenERP

The principle of this tool is to export CSV data from an old application (onlyOpenERP for now), then to process CSV files in order to import them into afreshly installed OpenERP database. This is a completely different strategythan the in-place migration of OpenERP or OpenUpgrade and allows to start overfrom a clean database, while keeping history. Import and export are done withthe PostgreSQL-specific COPY command, and results in extremely fast exports andimports. Combined with a pure in-memory Python csv processing, this tool canoften achieve overall migration rates over 2000 lines/sec.

Installation

This tool only works with Python 2.7!

With Buildout

If you're using Buildout, you may add this tool in a new part like this:

Then, don't forget to add the migration section in the parts of the[buildout] section. After relaunching bin/buildout, the migratescript will appear in the bin directory of the buildout.

Starting from the version 1.7 of the OpenERP buildout recipe You may also installthis tool directly in your [openerp] part, just by adding:

Usage

This tool offers a single migrate script:

You can list the available default mapping files:

You should specify the source and target DBs, a selection of the source tablesto migrate, and the mapping files to use. The tool then takes care ofselecting the dependant tables:

If you want to inspect the temporary CSV files created, use the --keepcsvoption. They will be stored in a temporary directory under the currentdirectory.

This script won't actually write anything in the target database unless youspecify the -w option to commit the transaction at the end.

The most important part of the migration process is the YML mapping file, whichdescribes how to handle data, table by table and column by column. A defaultmapping file is provided and is being used as a real mapping for a migrationconsisting in migrating two 6.1 databases into a single 7.0 multicompanydatabase. You can mix the default 6.1 to 7.0 file provided, and augment itwith other custom yml files, they will be merged.

Internals

This tool was very loosely inspired from:

• the external_referential OpenERP module
• the OpenUpgrade project
• Talend Open Studio

The different internal steps are:

• Exporting CSV from the old database
• Transforming CSV to match the target database
• Detect data existing in the target DB with discriminators
• Postprocessing CSV files to fix foreign keys
• Reinjecting into OpenERP
• Updating possible pre-existing data with incoming data

The processing of CSV files is done using a mapping file written in Yaml.Initial versions of the mapping file have been written with the help of theOpenUpgrade analysis files.

Mapping file

You should keep in mind that this migration tool is only dealing with databasetables and columns: the OpenERP fields are unknown to it. Each table,each line, each cell of the source database is handled independently and themapping file tells what to do with the current cell. This leads to limitationsand this tool won't be able to handle extremely complex migration. But itis powerful enough to allow to simultaneously merge and migrate two 6.1databases into a 7.0 multicompany database.

For a real-life example, you can have a look at the OpenERP 6.1 to 7.0 mappingfile provided in the mappings directory of this tool.

Copying data

The most simple and basic YML statement for a column mapping is the following:

It tells that, if the OpenERP module is installed in the targetdatabase, the column1 of the table1 from the source DB should be copiedto the column2 of the table2 in the target DB.

The __copy__ instruction can even be omitted and the previous statement isequivalent to this one:

Internally, this statement is actually converted to a Python dict:

And the whole yml file is converted to a large mapping dict whose leafs arestatements or functions which are able to process data.

Copying all columns of a table

Openerp 6.1 All In One Download

If your target table has the same structure as the source table, you can avoidspecifying one mapping statement for each column and use a wildcard:

It means: copy all the columns of table1 from the source db to table1 in thetarget db. This kind of mapping is often used as a starting point when sourceand table structures are similar. You can then add mapping statements forspecific columns to override this wildcard.

Copying all columns to a different table

If the source table has only been renamed, you can copy all the columns of thesource table1 to the target table2:

Copying everything

If the source and target db have exactly the same structure and you just wantto transfer data, you may use a global wildcard (but we have not had theopportunity to try this one for real yet):

It means: copy all tables to the target database without processing. It mayseem unuseful compared to a bare dump and restore, but remind that this way youcan append data to the target DB, not only replace it. In that case you shouldtake care of existing data, if the table has constraints (see discriminatorsbelow)

Splitting one source line to several tables (table splitting)

For a single source line coming from a source table, you can feed data inseveral target tables. This can be done just by putting several target lineslike this:

It means: for each column1 in the table1 of the source DB, create twotarget lines: one for table2 and one for table3.

During the processing of the current line, other mapping statementscan feed the same target lines. Take this example:

In this case, data in the table1 will be directed to table2 andtable3. You can then add more lines to handle all the columns of table1

However in the example above, there is a conflict since two source cells are directedto the same target cell (table2.column2). In this scenario, there is no way topredict which one will be used (because the mapping is a Python dict and a dict is notordered). You should avoid this kind of conflicts.

In case of an OpenERP 6.1 to 7.0 migration, this kind of mapping is actuallyused to migrate one source res_users line to three different lines: one inres_users + one in res_partner + one in mail_alias. See the defaultmapping for a real example.

Data moved to another table (table merging)

When input lines must move to a different table, you want the foreign keyspointing to them to be kept so that they point to the new table aftermigration, you should use the __moved__ statement.

The only current situation in OpenERP is for the res_partner_address datamoving to the res_partner table:

This statement must be accompanied with a __fk__ statement for all theforeign keys pointing to the moved table (See the __fk__ chapter).

Not migrating a column

If you want to get rid of a specific column in a table, use the __forget__statement:

This statement is useful if you defined a wildcard, to prevent from migrating aspecific column.

Transforming data with Python code

Instead of just copying data with the __copy__ statement, you can use anyPython code. The Python code should be written in a literal Yaml block and isexecuted as is, as a function body, so that you have to insert a returnstatement somewhere.

Example from the mail module:

It means the type column of the mail_message table will be filled with'email' strings, whatever data the source column had.

The eventual signature of the function constructed using the Python code block is

It means that in the function body you can access the full source_row,which is a dict containing all the keys (column names) and values of thecurrent line being processed. But keep in mind that at this time, you aredealing with one specific cell of this line, and you should return the valuethat will be inserted in the corresponding cell of the target table. This canbe used to aggregate data from two source cells into a target cell:

You can also access the target_rows beeing filled during the processing ofthe line, so that data coming from a source cell can influence several cells inthe target lines, or even different target tables. Here is an example:

Note that in the example above, the Python code spans on several lines, and youshould define a Yaml literal block using |. The example above eventuallymeans: append firstname to name coming from the table1, and put itin the display_name cell of the target table1 and table2. Thetarget name cell will contain a copy of the source name cell.

If the target line is not supposed to have the same id as the source line,you can create a new id with the newid() function. This function returns adifferent value at each call and is responsible of incrementing the id. Hereis an example:

Each res_users line will generate a new res_partner line with a newid, while the res_usersid will be the same as the source. (Actually itwill not be the same, because an offset is applied to all ids).

Feeding a new column

If a target column should contain data but has no equivalent in the sourcetable, you can use ‘_' as a substitute to the not existing source column name:

Merging with existing data

When data is inserted in the target table, you may want to merge it withexisting data.

Imagine the target res_users table already contains anadmin account, and you don't want to duplicate this account by migratingdata from the source res_users table. In this case you should tell themapping how to recognize existing data. This is done by replacing thesource column name with the __discriminator__ statement, and by providing alist of column names that will be used to recognize existing data:

Using this statement, you can install a new OpenERP database with its adminaccount, and merge all existing accounts with data coming from the sourcetable. The login column will be used to match data. The preexisting adminaccount won't be duplicated but will be updated with the admin account fromthe source table.

Another use case in a multicompany scenario is to merge partners existing inthe target database, but keep them separate for the two companies:

Openerp Server 6.1 Download

Foreign keys without constraints

The first step of the migration is to automatically detect all the foreign keysof the source and target tables. Sometimes, OpenERP defines foreign keyswithout constraints. This mainly happens with related fields withstore=True, which create a column of integers without constraints. If youdon't want to __forget__ such columns, you have to tell the mapping whatthe target of the foreign key is, like in the real example below:

Here is another example for the crm_lead table, which may contain a fieldcoming from a __moved__ table. Imagine you want the partner_id field ofthe CRM leads in OpenERP 7.0 to come from the partner_address_id field ofthe same table in OpenERP 6.1. The new field is a foreign key tores_partner, while the old one was pointing to res_partner_address. Youcan tell this with the following statement:

However you should also not forget to forget the partner_id field, or you willhave a conflict an mix data badly if you used a wildcard for the table:

Reference fields

Sometimes columns define a dynamic reference id to another table, just like aforeign key, except that the name of the table is actually stored in anothercolumn.

In the example above, since the res_id is not a real foreign key, its valuewon't be fixed to correspond to the target database. In that case you shoulduse the __ref__ statement, followed by the name of the column holding thetable or model name. This statement assumes the model-to-table transformationof OpenERP is used (replacing ‘.' with ‘_'):

Handle cyclic dependant tables

During the last step, the migrated CSV files are imported one by one. Sometables depend on other tables through foreign key constraints, and suchdependencies sometimes happen to be cyclic. In that case, there is no way toimport tables because they all depend on another one. One solution is to__forget__ the column, which is rarely desirable because you lose data. Tobe able to keep such data, you should use the __defer__ statement, so thatthe column will be updated after all the data is imported:

running SQL requests during migration

In case the wanted migration is too complex to be handled by regularstatements, you can run SQL queries on both the source and target database.This should be used in limited cases because the queries will be executed foreach source cell for which the mapping defines it, and the migration may beslowed down, unless you limit the queries with manual caching. (See theworkflow migration in the mapping).

A simple sql() function is available in the mapping file, and has the following signature:

Here is an example:

Field size limit

When running migration, you may encounter a csv.Error: field larger thanfield limit. This is due to the csv module limiting the csv field size to128k by default. The default value has been increased to 20MB. If this is notenough for your migration, you can increase the limit by inserting a directcall to csv.field_size_limit().

For example:

Overall migration process

Migrating need several steps described below. If you need, you can easily writea small script to automate this full process.

Before migration

The different steps before migration are the following. All of them areimportant for the migration to be successful and should be done on the target db:

• Create a clean target database without demo data, using the latest migrated code
• Install the expected modules
• Rename the target company so that its name exactly match the company in the source database
• Remove the company of all internal sequences by running the following SQL:update ir_sequence set company_id=NULL;. This will allow to remove duplicate after migration.

Migration

The migration consists in running the migrate script by selecting thecorrect options. If the data in the target database are not the one you expect,you must adapt the options and the mapping file to obtain what you want.

Here is a real example

After migration

The migrate script alone may not be sufficient for your database to beclean and usable. You may have to handle additional corrections. Please testyour instance thoroughly! Since version 0.6 you shouldn't have to manually fixthe internal sequences, as they are now handled by the mapping file. You mayjust clean them up to remove duplicates (from the menuSettings/Technical/Sequences&Identifiers/Sequences). However one of therequired remaining fixes consists in dropping some parent_left andparent_right columns. Here is the example with the accounting module:

You might also need to force a recalculation of new or changed related fieldsthat are persisted in the database (store=True). Here is an example withthe account_report_company module:

At the end, you should run a final global update of the database.If you're using the buildout recipe it should look like this:

Understanding errors

The most difficult part of using this tool is to understand the errors duringthe processing, as it requires a deep knowledge of how it internally works.Most errors generally come from an erroneous mapping file. Errors can happenduring the processing of the CSV files, but the most difficult ones come fromthe last import step, because some tables may fail to be imported. In thiscase, you should carefully look at the logging messages at the end, and try tounderstand the constraint errors or why tables cannot be imported. You alsoshould use the --keepcsv option, and inspect the intermediate CSV files tounderstand the problem. By using this option, you will end up with a directorycontaining five CSV files for each table.

For instance, for the res_partner table you will find these files:

• res_partner.csv is the original data exported from the sourcedatabase
• res_partner.target.csv contains data after the first processing withthe mapping file, but wrong foreign keys
• res_partner.target2.csv contains final data with fixed foreign keys,that will eventually be imported at the end
• res_partner.update.csv contains data which have been detected asexisting in the target database, with wrong foreign keys.
• res_partner.update2.csv contains the final existing data with fixedforeign keys, that will be used to update the target table after import.

If you're going into trouble during the import step with foreign key errors,please have a look at this log, as it contains most of the commonencountered issues to solve:https://bitbucket.org/anybox/anybox.migration.openerp/issue/3/foreign-key-constraints

Contribute

Authors and contributors

• Christophe Combelles
• Florent Jouatte
• Guy-Clovis Nzouendjou
• Stéphane Bidoul

Code repository and bug tracker

See here: https://bitbucket.org/anybox/anybox.migration.openerp

Please don't hesitate to give us feedback, report bugs or contribute the mapping fileson Bitbucket.

Changes

0.9 (2013-12-31)

• cleaned up and added missing tables
• Many mapping improvements, fixes and cleanup
• Added mapping for HR migration

0.8 (2013-09-30)

• restored mapping for users/company assignment
• improved message migration

0.7 (2013-09-24)

• Fixed CRM migration
• Migrate email_template
• Migrate email_message
• Support references with __ref__ statements
• Fixed and improved the mapping
• Increased the default csv field size limit to 20MB

0.6 (2013-08-24)

• Migrate ir_sequence without needing post-migration script
• Fixed workflow instance and workitem migration
• Major performance improvement (x3) in case of db merging
• Fixed unwanted merging due to bad offset of foreign key discriminators
• Break some dependency loops and other mapping improvements

0.5 (2013-08-02)

• Fixed foreign keys pointing to a __moved__ table with existing data
• Updated doc

0.4 (2013-07-28)

• Fixed migration of leads and purchase orders
• simplified __moved__ statement handling
• improved workflow migration
• migrate employees and expenses
• set suppliers as companies by default
• how to install in a buildout
• updated doc

0.3 (2013-07-11)

• Lots of improvements for the 6.1 to 7.0 migration
• Fixed a bug during import due to bad quoting
• Allow m2o to m2m migration without custom code
• Added mapping for project, crm and auth_ldap modules
• Fixed move lines
• Allow to request the source db as well
• Improved documentation
• Migration of running workflows

Project details

Release historyRelease notifications | RSS feed

0.9

0.8

Openerp 6.1 Download Windows 7

0.7

0.6

0.5

0.4

Migrating need several steps described below. If you need, you can easily writea small script to automate this full process.

Before migration

The different steps before migration are the following. All of them areimportant for the migration to be successful and should be done on the target db:

• Create a clean target database without demo data, using the latest migrated code
• Install the expected modules
• Rename the target company so that its name exactly match the company in the source database
• Remove the company of all internal sequences by running the following SQL:update ir_sequence set company_id=NULL;. This will allow to remove duplicate after migration.

Migration

The migration consists in running the migrate script by selecting thecorrect options. If the data in the target database are not the one you expect,you must adapt the options and the mapping file to obtain what you want.

Here is a real example

After migration

The migrate script alone may not be sufficient for your database to beclean and usable. You may have to handle additional corrections. Please testyour instance thoroughly! Since version 0.6 you shouldn't have to manually fixthe internal sequences, as they are now handled by the mapping file. You mayjust clean them up to remove duplicates (from the menuSettings/Technical/Sequences&Identifiers/Sequences). However one of therequired remaining fixes consists in dropping some parent_left andparent_right columns. Here is the example with the accounting module:

You might also need to force a recalculation of new or changed related fieldsthat are persisted in the database (store=True). Here is an example withthe account_report_company module:

At the end, you should run a final global update of the database.If you're using the buildout recipe it should look like this:

Understanding errors

The most difficult part of using this tool is to understand the errors duringthe processing, as it requires a deep knowledge of how it internally works.Most errors generally come from an erroneous mapping file. Errors can happenduring the processing of the CSV files, but the most difficult ones come fromthe last import step, because some tables may fail to be imported. In thiscase, you should carefully look at the logging messages at the end, and try tounderstand the constraint errors or why tables cannot be imported. You alsoshould use the --keepcsv option, and inspect the intermediate CSV files tounderstand the problem. By using this option, you will end up with a directorycontaining five CSV files for each table.

For instance, for the res_partner table you will find these files:

• res_partner.csv is the original data exported from the sourcedatabase
• res_partner.target.csv contains data after the first processing withthe mapping file, but wrong foreign keys
• res_partner.target2.csv contains final data with fixed foreign keys,that will eventually be imported at the end
• res_partner.update.csv contains data which have been detected asexisting in the target database, with wrong foreign keys.
• res_partner.update2.csv contains the final existing data with fixedforeign keys, that will be used to update the target table after import.

If you're going into trouble during the import step with foreign key errors,please have a look at this log, as it contains most of the commonencountered issues to solve:https://bitbucket.org/anybox/anybox.migration.openerp/issue/3/foreign-key-constraints

Contribute

Authors and contributors

• Christophe Combelles
• Florent Jouatte
• Guy-Clovis Nzouendjou
• Stéphane Bidoul

Code repository and bug tracker

See here: https://bitbucket.org/anybox/anybox.migration.openerp

Please don't hesitate to give us feedback, report bugs or contribute the mapping fileson Bitbucket.

Changes

0.9 (2013-12-31)

• cleaned up and added missing tables
• Many mapping improvements, fixes and cleanup
• Added mapping for HR migration

0.8 (2013-09-30)

• restored mapping for users/company assignment
• improved message migration

0.7 (2013-09-24)

• Fixed CRM migration
• Migrate email_template
• Migrate email_message
• Support references with __ref__ statements
• Fixed and improved the mapping
• Increased the default csv field size limit to 20MB

0.6 (2013-08-24)

• Migrate ir_sequence without needing post-migration script
• Fixed workflow instance and workitem migration
• Major performance improvement (x3) in case of db merging
• Fixed unwanted merging due to bad offset of foreign key discriminators
• Break some dependency loops and other mapping improvements

0.5 (2013-08-02)

• Fixed foreign keys pointing to a __moved__ table with existing data
• Updated doc

0.4 (2013-07-28)

• Fixed migration of leads and purchase orders
• simplified __moved__ statement handling
• improved workflow migration
• migrate employees and expenses
• set suppliers as companies by default
• how to install in a buildout
• updated doc

0.3 (2013-07-11)

• Lots of improvements for the 6.1 to 7.0 migration
• Fixed a bug during import due to bad quoting
• Allow m2o to m2m migration without custom code
• Added mapping for project, crm and auth_ldap modules
• Fixed move lines
• Allow to request the source db as well
• Improved documentation
• Migration of running workflows

Project details

Release historyRelease notifications | RSS feed

0.9

0.8

Openerp 6.1 Download Windows 7

0.7

0.6

0.5

0.4

0.3

Openerp Gtk Client 6.1 Download

0.2

0.1

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Hashes for anybox.migration.openerp-0.9.tar.gz