This is the documentation for older versions of Odoo (formerly OpenERP).

See the new Odoo user documentation.

See the new Odoo technical documentation.

Поддержка и обслуживание

Когда вы действительно начнете использовать вашу ERP, тогда вы начнете получать возврат ваших вложений. Поэтому соображения обслуживания и поддержки являются критическими с точки зрения успеха в долгосрочном смысле.

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

  • Цель обслуживания -- обеспечить чтобы сама система продолжала функционировать, как надо. Это включает обновления и модернизации системы, дающие вам доступ к новейшей имеющейся функциональности.

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 время от времени меняет свою стратегию поддержки. Во время написания данного текста предлагался договор на обслуживание, обеспечиваемое либо напрямую от себя до конечного пользователя, либо обслуживание через партнеров, что гарантирует быструю починку любого сбоя, обнаруженного в обслуживаемом коде. Хотя вы можете ожидать, что такие заплатки с течением времени станут доступны всем пользователям кода, обслуживание гарантирует быструю реакцию. И вы скорее получите поддержку перехода на новые обновления.

Если вы не предусматриваете предупредительного обслуживания, стоимость миграции после нескольких лет эксплуатации может стать значительной. Если вы допустите, чтобы специальные модули, которые вы разработали, сильно устарели, вам может в конечном итоге понадобиться новая разработка по вашим спецификациям.

Обновления и модернизации

There are four sources of code change for Open ERP:

  • патчи, изготовленные компанией Tiny для исправления ошибок: после проверки эти патчи не должны вызывать каких-либо вторичных эффектов,

  • небольшие обновления, которые собирают исправления ошибок вместе в один пакет, и обычно сопровождаются изменением номера версии, например с 5.0.0 на 5.0.1,

  • модернизации, которые объединяют и исправление ошибок, и расширения функциональности в важном выпуске, например с 5.0.3 на 5.2.0.

  • новые функции, обычно выпускаемые в виде новых модулей.

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.

Команда обслуживания также отвечает за регулярные обновления вашего программного обеспечения.

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 .

После того, как компания Tiny выпускает новую обновленную версию, ваша реакция должна быть осторожной. Если вы полностью удовлетворены существующей системой, самым лучшим решением будет не трогать новую версию. Если вы хотите получить доступ к новой функциональности, предоставляемый модернизированной версией, вам надо провести деликатную операцию. Большинство модернизаций требует переноса ваших данных, потому что ваши баз данных до и после модернизации могут немного отличаться.

Миграция на новую версию

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's minor module changes).

New stable versions of Open ERP sometimes require operations that aren't 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 doc/migrate of the Open ERP server.

Изменения между версиями 4 и 5 сделали процесс миграции труднее, чем ранее, так что возникла существенная задержка в обеспечении помощи в переносе и больше ручной работы, чем обычно.

Процедура переноса выглядит следующим образом:

  1. Make a backup of the database from the old version of Open ERP

  2. Остановите сервер, на котором выполняется старая версия

  3. Start the script called pre.py for the versions you're moving between.

  4. Запустите новую версию сервера с командой --update=all

  5. Остановите сервер, на котором выполняется новая версия

  6. Запустите скрипт, который называется post.py для версий, между которыми производится миграция

  7. Запустите новую версию сервера и проведите ее тестирование

A migration is never an easy process. It may be that your system doesn't 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.

Аналогично вам необходимо позаботиться, чтобы эта миграция не изменила ошибочно какие-либо настройки, которые были проделаны ранее. Структура главного меню может измениться без правильной записи изменений. Так что вы можете обнаружить, что сделанные вами предположения были неверны, когда позже загружаете данные, записанные при помощи модуля записи.