Краудфандинг для разработки российских модулей 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 перешёл в новый формат. Плоский и англоязычный — подобный блогам. Довольно скоро число вопросов превысит разумные нормы, вопросы будут дублироваться (но несколько различаться по форме), поиск быстро станет кошмаром.
Формат форума предполагает древовидную структуру — формат блога — плоскую.
Эта новация лично мне не по душе.