Краудфандинг для разработки российских модулей OpenERP

Всем привет!

Недавно OpenERP запустила кампанию краудфандинга (сбора народных средств) на разработку POS системы, которая бы работала с OpenERP www.indiegogo.com/projects/opensource-your-shop/x/5382204

проект оказался удачным и собрал нужную сумму и даже чуть больше. В связи с чем у нас возникла идея сделать краудфандинг и для России — чтобы можно быть скинуться на разработку нужных всем модулей и быстро сделать их. Как альтернатива сайту indiegogo.com для России мы выбрали сайт planeta.ru и разместили на нем первый проект. Пока он засекречен, пусть это будет сюрпризом :) Сейчас он находится на стадии одобрения администрацией сайта planeta.ru и скоро они должны его активировать, тогда я непременно сообщу здесь о запуске.

Сейчас пишу чтобы узнать ваше мнение насчет такой модели разработки с помощью краудфандинга — как вы думаете, станет ли она популярной и рабочей в нашем российском сообществе OpenERP? Нужно ли это лично вам, хотели бы вы поучаствовать? Видите ли вы преимущества в таком подходе?

Обмен мнениями и идеями приветствуется в комментариях!

OpenERP на рекламном производстве

Итак, пришли к выводу, что есть необходимость внедрения ERP системы на нашем предприятии, чтобы все сотрудники работали в единой информационной базе, каждый заказ отслеживался от отдела продаж и до сдачи заказчику, и чтобы можно было оперативно контролировать работу любого звена. В то же время, выбор особо не велик, если не сказать, что его нет вообще — лично мне привычнее всего Microsoft Dynamics Nav, но при его цене внедрения около 3 000 000 рублей, позиционирование в качестве ERP для малого и среднего бизнеса выглядит как издевательство, ну для среднего ещё ладно, но не для малого (по количеству сотрудников), у SAP всё ещё грустнее. Впрочем у западных компаний вообще очень специфическое представление о доступности их продукта.

Если говорить про российские разработки, то возникает впечатление что или большинство продуктов написаны в 90-х годах и давно заброшены или же, что скорее всего, программы созданы программистами, которые очень далеки от управления предприятием и соответственно пишут исходя из какой-то, одной им ведомой логики (впрочем, надо сказать, что программисты всегда так пишут, если им дать волю или не дать конкретного задания). Правда есть такая программа, как Галактика-экспресс, но, честно говоря, западным системам она очень уступает, хотя, её я рассматриваю как запасной вариант.

Отдельно хочу сказать про 1С, конечно это не ERP
Читать дальше →

ERP с открытым кодом: какую систему выбрать? OpenERP - правильный выбор!

Недавно столкнулся с необходимостью выбора платформы для разработки WEB решения для клиента.

Решил подойти чуть более чем «берем-то-что-ближе-лежит» — обозрел (постарался) наиболее популярные отчуждаемые бесплатные EPR системы с открытым кодом. Решил поделиться здесь — может, пригодится.

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

OpenERP и related поля

В официальной документации очень мало написано про то, как использовать поля типа related.
Прототип в официальной документации и его описание:

Sometimes you need to refer to the relation of a relation. For example, supposing you have objects: City -> State -> Country, and you need to refer to the Country from a City, you can define a field as below in the City object:
'country_id': fields.related(
    'state_id',
    'country_id',
    type="many2one",
    relation="res.country",
    string="Country",
    store=False)

Where:
— The first set of parameters are the chain of reference fields to follow, with the desired field at the end.
— type is the type of that desired field.
— Use relation if the desired field is still some kind of reference. relation is the table to look up that reference in.

Но как показывает практика этого описания недостаточно.
Есть, например, два класса invoce и contract.

class invoice(osv.osv):
    _name = "invoice"
    _columns = {
        'name_invoice': fields.char('Name'),
        'date_invoice': fields.datetime('Date')
        #'invoice_line': fields.one2many(....)
        #..... Список других полей .....
    }

class contract(osv.osv):
    _name = "contract"
    _columns = {
        'name_contract': fields.char('Name'),
        'date_contract': fields.datetime('Date')
        #..... Список других полей .....
    }

Нам необходимо, что бы пи создании новой записи в invoice происходила запись полей date_invoice и name_invoice в поля date_contract и name_contract объекта contract.

Для этого описываем дополнительные поля в классе invoice:
'name_lnk': fields.related('name_invoice', 'name_contract', type="char", relation="contract", string="Name")
'date_lnk': fields.related('date_invoice', 'date_contract', type="datetime", relation="contract", string="Date")

Теперь автоматически при создании invoice будет делаться запись в contract.

Вообще, лучше описать прототип так:
'country_id': fields.related(
    <поле_источника>,
    <поле_приёмника>,
    type=<тип_поля>,
    relation=<модель_приёмника>,
    string=<строковое_описание>,
    store=False)


Аргумент store служит для сохранения значений в базе:
Если True — данные сохраняются в базе данных
Если False — то это просто поле-функция, без сохранения данных в БД

Решение проблемы с иерархическим списком (деревом)

Нам нужно было сделать иерархический список по спецификациям, при разработке столкнулись с такой проблемой:
если в списке есть элемент, относящийся к разным спецификациям, и у него есть дочерние элементы, то при клике на него открываются дочерние элементы только первого элемента с подобным названием, который в списке. Причина — строки для скрытия/открытия в структуре DOM имеют одинаковые id и действие срабатывает для первых найденных.
Решение было найдено путём изменения функции hook_row_click, которая находится в файле addons/web/static/src/js/view_tree.js

Код для переопределения функции:
openerp.open_products_mrp = function(instance) {
    var module = instance.web;
    var QWeb = instance.web.qweb;


    module.TreeView = module.TreeView.extend({
    hook_row_click: function () {
        var self = this;
        this.$el.delegate('.treeview-td span, .treeview-tr span', 'click', function (e) {
            e.stopImmediatePropagation();
            self.activate($(this).closest('tr').data('id'));
        });

        this.$el.delegate('.treeview-tr', 'click', function () {
            var is_loaded = 0,
                $this = $(this),
                record_id = $this.data('id'),
                record = self.records[record_id],
                children_ids = record[self.children_field];

                if (!$this.parent().hasClass('oe_open')) {
                    self.getdata(record_id, children_ids, $this.parent());
                }
                else{
                    var datalevel = parseInt($this.parent().attr('data-level'));
                    $($this.parent().nextAll('tr')).each(function() {
                        datalevel_this = parseInt($(this).attr('data-level'));
                        if(datalevel_this>datalevel){
                            $(this).remove();
                        }
                        else return false;
                    });
                    $this.parent().removeClass();
                }
        });
    },
    getdata: function (id, children_ids, curr_node) {
        var self = this;

        self.dataset.read_ids(children_ids, this.fields_list()).done(function(records) {
            _(records).each(function (record) {
                self.records[record.id] = record;
            });

            if (curr_node) {
                var $curr_node = $(curr_node);
            } else {
                var $curr_node = self.$el.find('#treerow_' + id);
            }

            var children_rows = QWeb.render('TreeView.rows', {
                'records': records,
                'children_field': self.children_field,
                'fields_view': self.fields_view.arch.children,
                'fields': self.fields,
                'level': $curr_node.data('level') || 0,
                'render': instance.web.format_value,
                'color_for': self.color_for
            });

            if ($curr_node.length) {
                $curr_node.addClass('oe_open');
                $curr_node.after(children_rows);
            } else {
                self.$el.find('tbody').html(children_rows);
            }
        });
    }
    });

};


UPD: готовый модуль для версии 7.0 доступен по адресу openerp-russia.ru/download/tt_mrp_bom_tree_view.tar.gz

Форум дал дуба

Форум OpenERP перешёл в новый формат. Плоский и англоязычный — подобный блогам. Довольно скоро число вопросов превысит разумные нормы, вопросы будут дублироваться (но несколько различаться по форме), поиск быстро станет кошмаром.
Формат форума предполагает древовидную структуру — формат блога — плоскую.
Эта новация лично мне не по душе.

OpenERP 7.0 Примечания к релизу, часть 2: Продуктивность пользователя, громадный прыжок вперед

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

Мы провели сотни тестирований работы пользователей чтобы измерить и подтвердить эти улучшения. Это значительное достижение OpenERP 7.0 в этой области.

В среднем все процесы (например закупка → получение, создание и продление контрактов, настройка продуктов, и т.д.) совершается на 38% быстрее в OpenERP 7.0 чем в OpenERP 6.1;

Мы протестировали полную цепочку продаж с обычными пользователями, кто никогда не использовал OpenERP. Они начали с пустой базы, без информации или установленных модулей. Мы попросили их создать предложение, отправить его клиенту, конвертировать его в заказ продаж, доставить до клиента, выставить счет и зарегистрировать платеж. В среднем, этим новым пользователям понадобилось 6 минут для выполнения полной цепочки продаж;
Полное настройка системы под себя занимает в среднем 21 минуту для новых пользователей которые никогда не использовали OpenERP. Только продвинутые пользователи успешно выполнили эту же задачу в OpenERP 6.1.

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

OpenERP 7.0 Примечания к релизу, часть 1: Вступление

Первый прорыв OpenERP, достигнутый в версии 7.0, это избавление от сложности, присущей каждой полноценной ERP. Это позволяет снизить время внедрения и сократить издержки, снизить порог вхождения для новых пользователей, и сделать ERP доступной для каждой компании. Это факт, что пользователь, который никогда не использовал OpenERP, может без всяких тренировок, выполнить простой набор операций таких как создание заказа на продажу, доставка и выставление счета клиенту, и регистрация платежа, менее чем за 7 минут. Это несомненное достижение, которым мы гордимся больше всего.

С версией 7.0, OpenERP переключается с ERP на набор интегрированных бизнес-приложений. До сих пор, мир был разделен на ERP (все-в-одном) и лучшие в своем классе приложения. С версией 7.0, OpenERP комбинирует ключевые преимущества обособленных приложений (легких в использовании, быстрых в развертывании, отлично настраевымых, ...) с интеграцией и возможностью использования только той части ERP которая вам нужна. Это позволяет компаниям быстро развернуть один или два модуля с очень низкой стоимостью и постепенно увеличивать масштабы.

OpenERP 7.0 это не просто лучшая и легчайшая в использовании система. Она также вносит много улучшений в существующие возможности и добавляет несколько новых возможностей которые могут расширить масштаб тех сфер бизнеса, которые могут быть покрыты OpenERP. Интеграция с социальными сетями, адреса эл. почты для каждого объекта, интеграция с Google документами и LinkedIn, новое управление контрактами, новое управление событиями, новый интерфейс для розничных продаж (для кассира), новая адресная книга, новое управление транспортом,… это только несколько из множества внесенных улучшений в OpenERP 7.0.