The CSV format for complex database structures

421 that the connection between a PC client and the two servers is cor- rectly secured. You can configure Open ERP to use the HTTPS protocol, which provides security for data transfer Note: HTTPS The HTTPS protocol Secured Hyper Text Transfer Protocol is the standard HTTP protocol secured by using the SSL Secure Socket Layer or TLS Transport Layer Security security protocols. It allows a user to verify her identify to the site to which she wants access, using a certificate of authentication. It also guarantees the integrity and confidentiality of the data sent between the user and the server. It can, optionally, provide highly secure client authentication by using a numbered certificate. The default HTTPS port is 443. You could also use the PostgreSQL database directly to backup and restore data on the server, depending on access rights and the availability of passwords for the server.

28.3 User training

Two types of training are provided by the Tiny company and its partners: • Technical training in Open ERP: the objective of this intensive training is to enable you to develop your own modules by modifying and adapting the existing ones. It covers the creation of new objects, menus, reports and workflows, and also of interfaces with external software. It lasts for five days and is designed for IT people • User training: this enables you to be productive as rapidly as possible in the use of Open ERP. All of the modules there are detailed with concrete examples and different exercises. For the sake of realism the training uses data for a fictitious company. This training also lasts for five days. It is designed for those responsible for an ERP project, who will then be capable of training employees internally. Tiny’s training calendar is available on the official Open ERP site at http:www.openerp.comservicestraining-schedule . The training is delivered in either French or English depending on the course. Both Tiny, the creators of Open ERP, and the Open ERP partners can also provide customized training. This, although more expensive, is focused on your own needs. Your training needs depend on the type of deployment you have chosen. If you have opted for a SaaS development, technical training is not very useful. In summary, you should arrange both user training and self-paced training perhaps based on this book series if you can. Technical training is strongly advised if you see yourselves developing your own modules. Although it is not obligatory it gives you quite a time advantage in any serious Open ERP engagement.

28.4 Support and maintenance

It is when you actually use your ERP that you will obtain value from your investment. For that reason maintenance and support are critical for your long term success. • Support aims to ensure that end users get the maximum productivity from their use of Open ERP by responding to their questions on the use of the system. Support can be technical or functional. • Maintenance aims to ensure that the system itself continues to function as required. It includes system upgrades, which give you access to the latest functionality available. Some partners offer preventative maintenance. This makes sure that all the specific developments for your system are revised and tested for each new version so that they remain compatible with the base Open ERP. Tiny themselves have changed their support strategy from time to time. At the time of writing they propose a maintenance contract supplied either direct to the end user or through partners that guarantees a quick fix to any faults discovered in the covered code. Although you can expect these fixes to become available to all users of the 422 code in time, maintenance guarantees quick attention. And you are likely to get quicker migration support to new upgrades. If you have not anticipated your needs with a preventive maintenance contract, the costs of migration after a few years can become significant. If special modules that you developed have been allowed to become too old you may eventually need a new development according to your specifications.

28.4.1 Updates and Upgrades

There are four sources of code change for Open ERP: • patches supplied by Tiny to correct faults: after validation these patches should not cause any secondary effects, • minor updates, which gather the fault corrections together in one package, and are generally announced with a modification of the version number, such as from 6.0.0 to 6.0.1, • upgrades, which bundle both the fault corrections and the improvements to the functionality in a major release such as from 6.0.3 to 6.2.0. • new functions generally released in the form of new modules. You should establish a procedure with your supplier to define how to respond to changes in the Open ERP code. For simple updates your maintenance team will evaluate the patches to determine if they are beneficial to the use of your Open ERP. These patches should be tested on an offline instance of Open ERP before being installed in your live production version. The maintenance team would also take charge of regular updates to the software. Patches and updates can only be installed if you have the necessary access to the Open ERP server. You must first install the patch or update and then restart the server using the command line: -update=all . Once Tiny has released a new upgraded version your response should be a cautious one. If you are perfectly satisfied with the existing system it would be best to not touch the new version. If you want to have access to the new functionality supplied by an upgraded version, you have a delicate operation to carry out. Most upgrades require your data to be migrated because the databases before and after the upgrade can be a little different.

28.4.2 Version Migration

Open ERP has a system to manage migrations semi-automatically. To update specific modules, or the whole database, you only need to start the server with the argument:–update=NAME_OF_MODULE or -update=all that is minor module changes. New stable versions of Open ERP sometimes require operations that are not provided in the automated migration. Tiny, the creator and maintainer of Open ERP, has a policy of supporting migration from all official stable releases to the latest. Scripts are provided for each new release of a stable version. These carry out the upgrade from the previous major version to the new major version. Managers responsible for the migration between two versions of Open ERP will find the documentation and the necessary scripts in the directory docmigrate of the Open ERP server. The changes between version 4 and 5 made the migration process more difficult than in the past so there was a greater delay in the provision of migration assistance and more manual work than usual. The procedure for migrating runs like this: 1. Make a backup of the database from the old version of Open ERP 2. Stop the server running the old version 3. Start the script called pre.py for the versions you are moving between. 4. Start the new version of the server using the option –update=all 423 5. Stop the server running the new version. 6. Start the script called post.py for the versions you are moving between. 7. Start the new version of the server and test it. A migration is never an easy process. It may be that your system does not function as it did before or that something requires new developments in the functionality of the modules that have already been installed. So you should only move to a new version if you have a real need and should engage a competent partner to help if the version that you use differs greatly from the basic version of Open ERP. Similarly you should take care that this migration does not incorrectly change any setting that has already been made. The main menu structure might have been modified in place without proper recording of the changes. So you could find that you are making the wrong assumptions about that structure when later loading data that was recorded with the Module Recorder.