Новость за 9 апреля 2012 года с официального блога OpenERP
Мы собираемся разработать значительные усовершенствования структуры для версии 7.0, ожидаемой в сентябре 2012. Эти усовершенствования позволят OpenERP быть более модульным, быть более легким для изучения новыми разработчиками, разработав модуль с меньшим количеством линий кода и более pythonic.

Наши первые тесты позволили нам уменьшать простой модуль («идея») от 300 линий кода к 200 линиям (на 33 % меньше). Мы также значительно сократили количество методов алгоритмов, чтобы изучение было более понятным, более независимым и общим. Это понизит кривую обучения для новых разработчиков.

Среди всех усовершенствований самые важные:
Читать дальше →

UPD: уже имеется модуль локализации для версии 7.0 а также печатные формы. Кому интересно — пишите в комментариях. Сейчас можно помочь сделать формы на QWeb для версии 8.0 а также улучшить модуль локализации. Текст ниже уже не актуален, в данный момент разработка ведется на GitHub: https://github.com/odoo-russia/odoo-russia

Было решено создать свободный модуль локализации для России, и добиться включения его в официальный дистрибутив.

Что для этого требуется вы можете прочитать в оригинале тут: doc.openerp.com/v6.1/contribute/15_guidelines/l10n_guidelines.html
Перевод на русский язык тут: codup.com/sistemi/svobodnie/openerp/rukovodstva/132-rukovodstvo-po-lokalizacii.html

В результате создана команда OpenERP Russian Localization Team: https://launchpad.net/~openerp-l10n-ru

В ней создана ветка l10n_ru, которая привязана к проекту openobject-addons. Все как по правилам на этой странице.

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

Когда посчитаем что локализация выполнена, пошлем запрос на слияние с транком.
Читать дальше →

Пакет универсален и сильно масштабируем — от ИП до корпораций. Поэтому в переводе нужно выбирать возможно универсальные варианты.
customer — наиболее универсально — покупатель, но это может быть клиент при постоянных закупках партий товаров или же заказчик какого-либо продукта производства или какого-либо проекта. В зависимости от модуля переводы различны.
stock — запас, но никак не склад (warehouse). Запас может находиться даже на разных континентах и даже не на ваших складах и вам его может не хватать в конкретном расположении при общей сумме покрывающей многократно заказанное.
Названия подразделений, отделов и прочее не имеют смысла в случае ИП. Как вы будете называть в этом случае начальника отдела кадров? И наоборот, если это корпорация, то уже не группа или отдел, а департамент.
product — это не ТМЦ. Это продукт, возможно и продукт отходов жизнедеятельности с отрицательной стоимостью, который нужно утилизировать (га...).
company — компания, предприятие, организация? Всё зависит от масштаба и принадлежности (частное, государственное).
Особое место занимает понятие ID. Это идентификатор объекта. Это номер, но с возможным префиксом и инфиксом. Для его использования (особенно в заголовках таблиц) я бы использовал *№* (номер в погонах). На этом самом ID построена вся логика пакета. Его предлагали переводить как артикул, но это мелковато. ID присваивается продукту, действию, счёту, налогу, событию, форме, шаблону формы и в конце концов полю формы. Да всему.
В связи со сказанным, конкретика переводов весьма не желательна. Можно создать несколько вариантов перевода в зависимости от масштабов компании (да и не компании в данном случае, а предприятии, организации и т.д.).

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

Судя по вопросам в форуме у новичков есть трудности с пристройкой перевода.
Здесь важно понять механику. Дело в том, что из модулей перевод берётся только 1 раз — при создании БД и записывается в БД вместе с данными. На лету поменять перевод не получится. И на одном сервере могут находиться несколько БД с разными переводами! Выход в создании новой базы или перезапуске сервера с использованием строкового параметра обновления БД (используйте --help для получения списка параметров).
На форуме дали подсказку и скорее всего сработает самый простой вариант: после копирования файлов перевода в действующий пакет с созданной БД загружаем из пакета (не из инета) официальный перевод с установленной галкой замены терминов, перезапускаем сервер и всё. Этот шаг в связи с косяками разработчиков всё равно обязателен для чистого перевода всех пунктов меню.
Мои файлы переводов соответствуют структуре каталогов системы и могут быть установлены простым копированием каталогов (Server и Client) с заменой файлов. Но учтите, что для Linux сначала нужно установить правильного владельца каталогов и файлов (через chown) и, может быть права доступа (в разных Linux по разному).
GTK-клиент скорее всего можно корректировать на лету (но только клиент, не модули пакета). Дело в том, что этот клиент использует и .po и транслированный файл .mo.

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

Возможно вы обратили внимание на то, что в файлах .po в английских названиях пунктов меню присутствует символ подчёркивания. Причём в различных позициях английского слова (и в начале, и в середине слова, но не в конце). Это признак того, что следующий за ним символ будет выделен цветом или размером и будет использоваться в качестве «горячей» клавиши.
Я пока (до стабилизации перевода) эту возможность не использовал, поскольку очень легко получить пересечение и неоднозначность.
Но такая возможность есть и в будущем её нужно обязательно прикрутить.

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

Встала примерно следующая задача настройки OpenERP.
На почту приходят заявки от клиентов по определённой форме. Пример тела сообщения:

Имя: Иванов
Фамилия: Иван
Отчество: Иванович
Год рождения: 1978
Ваш уровень образования: Неоконченное высшее
Город: Томск
Контактный телефон: +100500
E-mail: [email protected]

Так как все письма присылают по похожей форме, было бы удобно, чтобы в системе автоматически создавался кандидат с данными, полученными из письма. Основные поля: ФИО, телефон, почта.

Читать дальше →

Хочу представить модуль для интеграции OpenERP и Pentaho. Pentaho — один из самый лучших BI с открытым источником.

Прямая ссылка где вы можете найти и инструкцию и модуль:

https://github.com/richard-willowit/Pentaho-reports-for-OpenERP

Этот проект предоставлен как модуль для OpenERP, который интегрирует его с Pentaho отчетами. Конечные пользователи OpenERP могут проектировать отчеты, используя Pentaho дизайнер отчетов 3.9 (инструкция, по установке: http://bit.ly/L4wPoC), установка /доступ к ним изнутри интерфейса OpenERP.
Читать дальше →

Перевод оригинальной статьи

Что такое Yaml?

YAML — человечески-удобочитаемый формат последовательность данных, который берет концепцию от языков программирования, таких как C,Perl, и Питон, и идеи от XML и формата данных электронной почты… YAML доступен как формат данных OpenERP начиная от OpenERP 6.0, и имеет следующие преимущества:

— Дружественный пользовательский Формат как альтернатива текущему формату данных XML.

— Та же система, для загрузки данных или тестирования, интегрированная в модули.

— Построенный в OpenERP так, чтобы Вы могли разрабатыват сложные тесты Питона.

— Более простой для не разработчика, чтобы написать функциональные тесты.

Как написать Yaml тест?
Читать дальше →

Привожу перевод статьи с кратким но достаточно полным описанием создания модуля в OpenERP. Так как не достаточно владею терминологией программирования — перевел как получилось. Если есть какие либо поправки к переводу, прошу писать — не стесняйтесь :)

Перевод оригинальной статьи

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

Состав модуля

Модуль может содержать следующие элементы:

бизнес объекты: объявленные как классы Питона, с расширением osv.osv класс OpenObject

данные: виды, меню, технологические процессы, демонстрационные данные и т.д.

мастера: интерактивные формы

отчеты: RML (формат XML), шаблоны МАКО или OpenOffice отчеты, объедененные с любым видом коммерческой информации, с созданием HTML, ODT или PDF отчетами.

Структура модуля

Модуль создаются в пределах директории server\openerp\addons
Читать дальше →

Перевод оригинальной статьи

WebDAV (Вэб распределение создание документов и управление версиями) является открытым, опубликован в стандартной сборке, и позволяет редактировать документы на отдаленном веб-сервере.

WebDAV поддерживает следующие функции:
Читать дальше →