Exporting Open ERP data to CSV

420 Internal Installation Large and medium-large companies typically install Open ERP using their own internal company resources. They usually prefer to have their own IT service in charge of maintenance. Such companies can do the implementation work themselves internally, or turn to an Open ERP partner who will do the ERP implementation work or assist them with it. Generally companies prefer to adopt an intermediate solution which consists of: 1. Turning the initial implementation over to a partner to limit the risks and delays of integration. That enables them to be managed by experts and obtain a high quality configuration. 2. Taking charge of the simple needs for themselves once the software has been implemented. It is quite a lot more convenient for them to be able to modify the database tables, forms, templates and workflows internally than routinely depend on a supplier. An internal installation will probably prove more costly than an SaaS package or hosted service. Even if you put yourself in charge of it all, you will take quite a bit of time learning how to manage the implementation unless the team already has an experience of Open ERP. This represents a significant risk. However, an internal implementation can be particularly interesting where: • you want to keep your data within your company, • you think you want to modify your software, • you want a specific package of modules, • you would like a very fast response time, • you want the software to be available even if your Internet connection goes down. These factors, and access to the resources needed to handle an implementation and the subsequent maintenance, are the reasons that large and medium-large companies usually do it for themselves, at least partly.

28.2.2 Deployment Procedure

The deployment of a version of Open ERP is quite simple when your server has been configured in your production environment. The security of data will then be a key element. When you have installed the server you should create at least two databases: • a test or development database, in which the users can test the system and familiarize themselves with it, • a production database which will be the one used by the company in daily use. Note: Version numbering Open ERP uses a version numbering model that comprises 3 numbers A.B.C for example 4.2.2 or 5.0.0 where changes in the number A signify a major functional change, changes to number B signify an update that includes a batch of fault fixes and some new functionality, and the number C generally refers to some limited updates or fixes to the existing functionality. The number B is special: if it is an odd number, for example 4.3.2 or 5.1.0 it is for a development version which is not designed for a production environment. The even numbers are for stable versions. If you have prepared a data module for Open ERP that is a module that consists just of data, not altered functionality, you should test it in your development version and check that it does not require any more manual adjustments. If the import runs correctly, it shows that you are ready to load your data in the production database. You can use the Open ERP database backup procedure at different stages of configuration see Installation and Initial Setup . Then if you have made a false step that you cannot recover from you can always return to a prior state. Since your data describes much of your company’s value, take particular care both when you need to transfer it in backups and across your network and when you are managing the super-administrator password. Make sure