Category Archives: Principal

A lack of seriousness in the framework evolution for some time?

Hi everyone,

It’s been a while since I didn’t post here. Since last summer period has been very busy for me because of the end of my studies and various works.

As some of you have heard me say, I claim to be a “functional consultant”, that is to say:

-Able to understand and gather the needs of the user company
-With this understanding and that of the main modules of OpenERP, I’m supposed to find the most sustainable way to develop a feature before sending the specification to the development.
-I am able to do basic developments, such as adding a new field, adapting a view, a right access, correct translation …. Anything that is supported by the framework as it is supposed to manage the most common needs of the ERPs. This allows to submit the interface to the customer early in the project which is a highly effective asset to save time on the project.
-I am not able to make pure Python development. I am still able to read and sometimes make minor corrections.

Why I am making this definition of functional consultant? Because I think anyone who has business expertise, can become a functional consultant on OpenERP, it will just take time.

This is possible because from the beginning, OpenERP has established the framework OpenObject that manages database objects, menus, views, access rights, etc. … Making feasible to just anyone to make key changes on the ERP’s process. This has always been the main strengh of OpenERP! Ease of access to code features

Ok Yannick, we already know all this, what do you mean?

I mean that I feel since the relocation of development teams in India this spirit has greatly lost.

I’ll show you an example that I was literally stunned the day I saw that, without finding the time to talk about it before today.
Here is the code for the statistical analysis of invoices:

def init(self, cr):
        tools.drop_view_if_exists(cr, 'account_invoice_report')
        cr.execute("""
            create or replace view account_invoice_report as (
                 select min(ail.id) as id,
                    ai.date_invoice as date,
                    to_char(ai.date_invoice, 'YYYY') as year,
                    to_char(ai.date_invoice, 'MM') as month,
                    to_char(ai.date_invoice, 'YYYY-MM-DD') as day,
                    ail.product_id,
                    ai.partner_id as partner_id,
                    ai.payment_term as payment_term,
                    ai.period_id as period_id,
                    (case when u.uom_type not in ('reference') then
                        (select name from product_uom where uom_type='reference' and active and category_id=u.category_id LIMIT 1)
                    else
                        u.name
                    end) as uom_name,
                    ai.currency_id as currency_id,
                    ai.journal_id as journal_id,
                    ai.fiscal_position as fiscal_position,
                    ai.user_id as user_id,
                    ai.company_id as company_id,
                    count(ail.*) as nbr,
                    ai.type as type,
                    ai.state,
                    pt.categ_id,
                    ai.date_due as date_due,
                    ai.address_contact_id as address_contact_id,
                    ai.address_invoice_id as address_invoice_id,
                    ai.account_id as account_id,
                    ai.partner_bank_id as partner_bank_id,
                    sum(case when ai.type in ('out_refund','in_invoice') then
                         ail.quantity / u.factor * -1
                        else
                         ail.quantity / u.factor
                        end) as product_qty,
                    sum(case when ai.type in ('out_refund','in_invoice') then
                         ail.quantity*ail.price_unit * -1
                        else
                         ail.quantity*ail.price_unit
                        end) / cr.rate as price_total,
                    sum(case when ai.type in ('out_refund','in_invoice') then
                         ai.amount_total * -1
                        else
                         ai.amount_total
                         end) / (CASE WHEN
                              (select count(l.id) from account_invoice_line as l
                               left join account_invoice as a ON (a.id=l.invoice_id)
                               where a.id=ai.id) <> 0
                            THEN
                              (select count(l.id) from account_invoice_line as l
                               left join account_invoice as a ON (a.id=l.invoice_id)
                               where a.id=ai.id)
                            ELSE 1
                            END) / cr.rate as price_total_tax,
                    (case when ai.type in ('out_refund','in_invoice') then
                      sum(ail.quantity*ail.price_unit*-1)
                    else
                      sum(ail.quantity*ail.price_unit)
                    end) / (CASE WHEN
                         (case when ai.type in ('out_refund','in_invoice')
                          then sum(ail.quantity/u.factor*-1)
                          else sum(ail.quantity/u.factor) end) <> 0
                       THEN
                         (case when ai.type in ('out_refund','in_invoice')
                          then sum(ail.quantity/u.factor*-1)
                          else sum(ail.quantity/u.factor) end)
                       ELSE 1
                       END)
                     / cr.rate as price_average,

                    cr.rate as currency_rate,
                    sum((select extract(epoch from avg(date_trunc('day',aml.date_created)-date_trunc('day',l.create_date)))/(24*60*60)::decimal(16,2)
                        from account_move_line as aml
                        left join account_invoice as a ON (a.move_id=aml.move_id)
                        left join account_invoice_line as l ON (a.id=l.invoice_id)
                        where a.id=ai.id)) as delay_to_pay,
                    sum((select extract(epoch from avg(date_trunc('day',a.date_due)-date_trunc('day',a.date_invoice)))/(24*60*60)::decimal(16,2)
                        from account_move_line as aml
                        left join account_invoice as a ON (a.move_id=aml.move_id)
                        left join account_invoice_line as l ON (a.id=l.invoice_id)
                        where a.id=ai.id)) as due_delay,
                    (case when ai.type in ('out_refund','in_invoice') then
                      ai.residual * -1
                    else
                      ai.residual
                    end)/ (CASE WHEN
                        (select count(l.id) from account_invoice_line as l
                         left join account_invoice as a ON (a.id=l.invoice_id)
                         where a.id=ai.id) <> 0
                       THEN
                        (select count(l.id) from account_invoice_line as l
                         left join account_invoice as a ON (a.id=l.invoice_id)
                         where a.id=ai.id)
                       ELSE 1
                       END) / cr.rate as residual
                from account_invoice_line as ail
                left join account_invoice as ai ON (ai.id=ail.invoice_id)
                left join product_template pt on (pt.id=ail.product_id)
                left join product_uom u on (u.id=ail.uos_id),
                res_currency_rate cr
                where cr.id in (select id from res_currency_rate cr2  where (cr2.currency_id = ai.currency_id)
                and ((ai.date_invoice is not null and cr.name <= ai.date_invoice) or (ai.date_invoice is null and cr.name <= NOW())) limit 1)
                group by ail.product_id,
                    ai.date_invoice,
                    ai.id,
                    cr.rate,
                    to_char(ai.date_invoice, 'YYYY'),
                    to_char(ai.date_invoice, 'MM'),
                    to_char(ai.date_invoice, 'YYYY-MM-DD'),
                    ai.partner_id,
                    ai.payment_term,
                    ai.period_id,
                    u.name,
                    ai.currency_id,
                    ai.journal_id,
                    ai.fiscal_position,
                    ai.user_id,
                    ai.company_id,
                    ai.type,
                    ai.state,
                    pt.categ_id,
                    ai.date_due,
                    ai.address_contact_id,
                    ai.address_invoice_id,
                    ai.account_id,
                    ai.partner_bank_id,
                    ai.residual,
                    ai.amount_total,
                    u.uom_type,
                    u.category_id
            )
        """)

134 lines of pure SQL query, just to create a statistical analysis …

Ok then it may be necessary, but it is in the framework we should find this code, not in one of the functional modules! Here we should just tell him that’s the name of the object, these are the fields to be analyzed and go on. I do not recognize any of the OpenERP code usually ultra-simple, this code just look like it was done without any forethought.What effect? What happen if me, a simple functional consultant,  I just want to add an additional field to analyze? Or create a new statistical analysis on another object?  I can’t, and so I have to send this to developers who will rewrite theses 134lines (which is a problem even worse, I come back).In recent years it seems there was no serious efforts in the framework improvement. Ok then I support 300% web client, payroll and even the POS. But I begin to see big problems in the future for OpenERP that could collapse on its foundation, that is to say the framework.

To be clear, I’m not saying that OpenERP is poorly written, it is not “pythonic” or another. I do not have the skills for that and others are already doing it (dedication to the Tryton people which I am sure must enjoy this post …).
What I mean is that the functional should be able to change a lot more features than now on OpenERP.

What happens when one places an order from one status to another, such as sending an email, can add a module in a configuration wizard, or transfer the value of the field that you just created in sale.order to his account.invoice etc. …
There are still lots of things we can do, manage by OpenObject even more prominent roles in the ERP so we limit the amount of Python code to a minimum.

Moreover, I think this will be a good way to limit the amount of code that is laid each day by the Indian teams. I am sorry to say this but a lot of places I sometimes feel, pardon the expression, they just “pissed code” as if they were paid to the line. I am very concerned that this is a big risk and that eventually we could  no longer maintain the software later.
Crop development teams in OpenObject developments is probably the easier way to make sure there is only one way to make the work done, the simpliest and the better. This will eventually be able to more easily maintain the software or especially deep module redesign.

And moreover for some features they are already managed by OpenObject. For example creating a new invoice with the values ​​of a purchase order via ir.actions.server. Unfortunately, as certified module not use it, nobody uses these features …

In short, let me be clear on what I suggest: First, rewrite all the modules so they use ir.actions.server or an equivalent system. Then continue to improve the framework until the Python code in the modules is reduced to a minimum.

I am sure that most readers will rebel against this idea, too much work, you should leave some functions in python to have more flexibility etc. … No worries, I just try to start the debate and I  just hope it will lead to interesting conclusions.

I would however point the finger on one last problem, I think the worst, and that can be solved just by extending features of OpenObject.

Take a Partner A highly experienced and top contributors. He developed a module that is widely used by other community members.

In his module, he created a field in X and sale.order account.invoice, and he made sure that its value is passed to its sale.order account.invoice.

Here is the code he had to do:

    def _make_invoice(self, cr, uid, order, lines, context=None):
        journal_obj = self.pool.get('account.journal')
        inv_obj = self.pool.get('account.invoice')
        obj_invoice_line = self.pool.get('account.invoice.line')
        if context is None:
            context = {}

        journal_ids = journal_obj.search(cr, uid, [('type', '=', 'sale'), ('company_id', '=', order.company_id.id)], limit=1)
        if not journal_ids:
            raise osv.except_osv(_('Error !'),
                _('There is no sales journal defined for this company: "%s" (id:%d)') % (order.company_id.name, order.company_id.id))
        a = order.partner_id.property_account_receivable.id
        pay_term = order.payment_term and order.payment_term.id or False
        invoiced_sale_line_ids = self.pool.get('sale.order.line').search(cr, uid, [('order_id', '=', order.id), ('invoiced', '=', True)], context=context)
        from_line_invoice_ids = []
        for invoiced_sale_line_id in self.pool.get('sale.order.line').browse(cr, uid, invoiced_sale_line_ids, context=context):
            for invoice_line_id in invoiced_sale_line_id.invoice_lines:
                if invoice_line_id.invoice_id.id not in from_line_invoice_ids:
                    from_line_invoice_ids.append(invoice_line_id.invoice_id.id)
        for preinv in order.invoice_ids:
            if preinv.state not in ('cancel',) and preinv.id not in from_line_invoice_ids:
                for preline in preinv.invoice_line:
                    inv_line_id = obj_invoice_line.copy(cr, uid, preline.id, {'invoice_id': False, 'price_unit': -preline.price_unit})
                    lines.append(inv_line_id)
        inv = {
            'name': order.client_order_ref or '',
            'origin': order.name,
            'type': 'out_invoice',
            'reference': order.client_order_ref or order.name,
            'account_id': a,
            'partner_id': order.partner_id.id,
            'journal_id': journal_ids[0],
            'address_invoice_id': order.partner_invoice_id.id,
            'address_contact_id': order.partner_order_id.id,
            'invoice_line': [(6, 0, lines)],
            'currency_id': order.pricelist_id.currency_id.id,
            'comment': order.note,
            'payment_term': pay_term,
            'fiscal_position': order.fiscal_position.id or order.partner_id.property_account_position.id,
            'date_invoice': context.get('date_invoice',False),
            'company_id': order.company_id.id,
            'user_id': order.user_id and order.user_id.id or False,
            'champ_x': order.champ_x
        }
        inv.update(self._inv_get(cr, uid, order))
        inv_id = inv_obj.create(cr, uid, inv, context=context)
        data = inv_obj.onchange_payment_term_date_invoice(cr, uid, [inv_id], pay_term, time.strftime('%Y-%m-%d'))
        if data.get('value', False):
            inv_obj.write(cr, uid, [inv_id], data['value'], context=context)
        inv_obj.button_compute(cr, uid, [inv_id])
        return inv_id
50 lines, when in fact the only line that he really coded is in red here. And yet we were lucky, the original function could have been much longer.
As it is not possible via the module to insert the code directly, he had to copy and paste the entire function to add this little line.And the real problem happens. No chance the OpenERP devs change after the original function and other functions elsewhere, so that the former causes a bug now. Our partner A must now repeat the copy and paste of the original function if it does not want his module to be considered buggy.This forces our partner to monitor all its modules, just to check that OpenERP SA didn’t modify the original function. And since the functions are becoming longer, the risk of the bugs are all the more. Finally, the ultimate case, imagine if a partner created a module B that inherits from the function module A … What I mean by that is that it is the entire ecosystem of community modules that is unstable due to this overuse of Python functions that are not AT ALL suitable for a modular system as OpenERP.

I think we’re right into it today, we see that more and more quality modules arrive on OpenERP, but they are buggy as soon as OpenERP SA made changes in the functions of certified modules, which themselves become increasingly long and complex.

We must at all costs find another solution for module developers to avoid having to copy the original function when they just want to add some details as a field to be transferred. And for me the only viable solution, as it is clear that we can not do that directly in the Python code, is to extend the OpenObject capabilities.

Thank you for taking the reading. I express my personal conviction, which is somewhat isolated. I am not a developer, so if I may say big shit, please tell me in comments.

My point of view about the OpenERP relicensing

Hello everybody,

I will now tell you about the subject of the last week: The addition of an exception in the OpenERP AGPL license, potentially allowing to avoid the redistribution of source code through the purchase of an OpenERP Enterprise version.

So like everyone else in the community, instantly I was shocked:

-We create some kind of a dual license, which is our worst fear: SugarCRM, Pentaho, Magento, etc … most of the popular business free software also have in parallel an enterprise version which means that not all efforts are made to improve the free version and often even limiting the efforts of the community. This is one of the main power of OpenERP now than not falling into this trap and it’s a very, very bad news to see that begin to rears its ugly head.
Ok so we are assured that the Enterprise version has nothing to do with the other double licenses, that all the modules continue to be dismissed AGPL, don’t act I return to it later in this post. Nevertheless, the name is very scary.

-We can also read the fact we can, against some good cash, purchase the right not to redistribute the source code. No really need to be a fan of conspiracy theories to immediately imagine arrangements between OpenERP SA and large companies to make some breaches against the GPL’s garantees and thus those protecting the community and users.

This is what comes to mind when OpenERP SA presented its new offer, and that is why the debates have been particularly virulent last week about this. I myself began to fear that a significant part of the community begins to turn to Tryton.
But when we analyze in detail the offer, we realize that it is not necessarily so bad thoughts, to understand where I’m going let me go into detail *GPL license.

The first license *GPL , I will move quickly on it because it was never used by OpenERP, and also the least restrictive is the LGPL. It is used primarily when the license of software needs to be compatible with proprietary code while being able to protect by the GPL guarantees the software itself.

The GPL is the basic license approved by FSF and one of the most restrictive. Sometimes excess according to some people because you can not use GPL software with other proprietary code. You have an obligation to redistribute the source code if you make a modification to the software, but however you can create an extension as an OpenERP module without having to publish as you use it privately. OpenERP remained long in GPL V2 and then in GPL V3 when this version was released.

Still, the GPL failed to give guarantees with the SaaS. You could take for example the OpenERP code, create useful modules, and on that basis make an SaaS offer without having to publish the source code of your modules. I call that an opportunistic SaaS offer obviously wrong in light of the spirit of free software.
This is to compensate for this scenario that the FSF has created the AGPL license. The principle is simple: You can request the source code of any software you use, even if it is used across the network. Note the size difference between the GPL and the AGPL: If we place ourselves in business context, this means that even employees or partners with limited access to the ERP can request the source code of the company’s OpenERP, including modules developed specifically for it and only used privately.

OpenERP is licensed under the AGPL since last year. It was obviously necessary to avoid opportunistic SaaS offers I mentioned and that could appear very quickly. Imagine you take the code OpenERP, develop a vertical integration, for example services companies and sell all without having to redistribute your work. I can imagine how these opportunists could appear in a few years on the back of OpenERP so it was obviously a necessity.

And so now OpenERP SA receives requests from companies wishing to protect their private modules (which can often reflect a unique way of working to the company and does not want to give to the competition). On which OpenERP SA meets today with the AGPL exception.
This exception says that if the client company pays the enterprise version, it may not give the source code of its modules to private users but must make if it distributes copies (especially if he tries to sell them) returning immediately under the terms of the classic AGPL. For me it is neither more nor less than selling the right to use the GPL instead of the AGPL.

And for once I will not plant a knife in the back OpenERP SA: I agree with them. For me, both GPL and AGPL protect the interests of the community, with the exception of opportunistic SaaS offers for GPL. I see no problem in allowing the companies to use private module, it’s fully in the spirit of free software, it has been like that throughout the GPL period of OpenERP and I would even say that simply forbid it as the AGPL actually unserve the interests of OpenERP and community.

But where I find really interesting the choice of OpenERP SA is that they have managed to find an economic model (the fact to charge companies that want to protect their internal working methods), equal (not all companies will need such protection, and those who need it can pay for it) and especially with the only difference between the paying and non-paying users is … just impose even more restrictive license about the free software guarantees, via the AGPL license for non-paying users. Users who pay will have a GPL equivalent already properly protecting the interests of the community and non-paying users whose the only restriction is to be forced to publish the source code for its employees and partners … It’s brilliant, just brilliant.

Since I started on OpenERP, I feared that OpenERP SA is finally forced to adopt a dual license in order to survive, I have seen throughout the period struggle to come to find a viable business model but respectful of the community. When this exception appeared, I thought, like many others, they had mainly started throwing in the towel and move to a dual license, however, finally … it seems on the contrary they have actually managed to find the economic model they were looking for. Personally I therefore support the idea, and I think it is incredibly original.

Now consider the various scenarios:

1) The case where an unscrupulous company is developing a module and then tries to sell it without redistribute the source code. This case should in my view not be possible without violating the spirit of free software.

2) The case where a client company wants to develop a module for internal use only. The company should have the opportunity, so free or paid, to retain full intellectual property of the module without publish it to its employees and partners. This does not violate the spirit of free software.

3) The case where a client company wants access to a module. It is my opinion that is respected the spirit of free software if he has free access to the source code for all modules developed by the publisher, by an integrator which bases its services above and those used in a SaaS offering. They did not necessarily have access to a module only used internally in another company.

4) The case where an unscrupulous company develops a module for an SaaS offer based on it without having to redistribute the source code. This case should in my view not be possible without violating the spirit of free software.

OpenERP under GPL licence:

1) Case impossible without violating the license

2) Possible case without license violation

3) The client company has no access to modules of an unscrupulous SaaS offer.

4) Possible case without license violation

OpenERP under AGPL licence:

1) Case impossible without violating the license

2) Case impossible without violating the license

3) The client company has successfully access to all modules.

4) Case impossible without violating the license

OpenERP under AGPL + exception. The company which is mentioned in the case purchased the enterprise version.

1) Case impossible without violating the license

2) Possible case without license violation

3) 4) I’m not sure … I’m looking at the text of the exception, what OpenERP SA offers to the users with the Enterprise version is the right not to redistribute the source code to users over network, without any other restriction. That’s too close to the GPL to prevent opportunistic SaaS offers to appear, they would then just buy the Enterprise version … OpenERP SA needs to be much more explicit on this point, and explicitly specify that the exemption is void if access to ERP is paid in any way (I think of SaaS opportunistic offer as well as to a company that would charge an option to its clients for accessing their invoices on the ERP of the company, in this case the code must also be redistributed).

Moreover, there are two problems with the implementation of this license, I’ll just mention them quickly:

-There are still many people in the community, holding some copyright on the code of OpenERP, who refuse to allow the transition to the new license. In response OpenERP SA wants to rewrite their contribution which is obviously an insult. I find this regrettable, even if ultimately the idea seems good OpenERP SA wanted to push through and the result is climbing. OpenERP SA MUST NOT rewrite these contributions, they have tended to be too closed in on themselves which is not healthy for a free software (I have already sufficiently expressed my opinion on the fact OpenERP SA should make a much better use of the community contributions). I encourage everyone to talk responsibly about the subject, if there is a reluctance on the side of the community, suggest and ask for guarantees.

-Some community members have highlighted the fact that the modules AGPL is not compatible with AGPL + Exception. It would be obviously a huge problem, but my limited legal skills do not allow me to make more comments on the subject.

In conclusion, my opinion is that I support the new license, provided that the opportunistic SaaS offer is explicitly banned from the exception, and congratulations to OpenERP SA for finding this business model.

PS: I invite you to read this excellent post on the same subject: http://www.qmuxs.com/version2beta/2011/a-new-openerp-product-and-license/.

New resources available for OpenERP: Process and Training Plans

Greetings,

There’s definitely a lot of things happening this month, and not just the V6 which begin to come. Here at Synerpgy, there is no less than three new important process that was modeled and two training plans now freely available on our website.

Thus, we can include :

About training plans, the entire accounting training plan is now available on the site. Moreover, the first part (development through graphical interface) of the technical training plan is also available. I hope these training plans can help people who can’t or don’t want to pay for training.

Unfortunately, and as usual, these resources are only in French, sorry for the english-speaking people. If someone want to translate, feel free.

All these documents are licensed as Creative Commons by-sa, do not hesitate to use it as long as you meet the conditions of the license. See you later!

Release of the first process OpenERP: Sales Management

Greetings,

In order to keep improving our services and our customers’s satisfaction, we continue to refine our various working papers that we publish as usual.

The document published today is a BPMN diagram of sales process OpenERP’s. These diagrams, which I call “generic processes” are our working basis when we work with the customer during the study phase. Beware that these diagrams are only in French, cause of a leak of time. Feels free to translate it if you want.

Then, according to this diagram, we can adapt the document thanks to customer’s comments and thus shape very precisely the future operation of the client company under OpenERP. Thus, we can more easily identify during the study phase of the main points that the client wants to see revised at this time an adequate vision of the future operation of his company.

For now, only the sales process is modeled, as well as mini-processes of creation of partners and products. I think it was also about one of the most complex processes, because it is the central process, the one which is connected to virtually everyone else.
I hope to release other processes quickly (we need them) including the billing process, the manufacturing-stock-purchase process, the project-analytic accounting process, CRM processes and finally Magento synchronization process. I hope (probably foolishly) release them before the end of the month, so keep an eye on the site.

I finally point out that the goal of the “generic processes” is completeness. When we work with the customer, the main purpose is is to simplify the process and not the opposite. Processes by sector will be created later on this basis so as to refine the matching between the processes and pave the way for other types of performances.

As usual, all our documents are available under CC by-sa license, so feel free to use them, modify them if necessary and to send us your improvements. Especially if Tiny would come to use them for the futures versions, would be great, otherwise you can rely on us to keep them updated.
We will be careful about just one thing: the respect for the assignment clause. Please do not remove our name, it’s still a lot of work that is done and that’s the bare minimum we can ask.

You can find diagrams here : http://www.synerpgy.fr/processus

See you soon, I’ll prepare another surprise for the next few days.

Improvement suggestion about access right in OpenERP

Greetings,

I’d like to share with you some thoughts that I had about support of access rights in OpenERP, and how I think it should be improved.

Access rights in OpenERP are already well implemented, in particular by:
-To set access rights on various menus, or at the level of the action on which they are linked.
-To set access rights on the object itself, with the right read / write / creation / deletion.
-To define the rights to the fields themselves, either at views or at the object level.
-To define the segmentation between records with access rules which I think are already very powerful.

These tools allow to deal with a lot of situations where access rights are needed, for example if we want to prohibit access to an object, block a specific menu, act on a particular field or allow access to only some records of an object (some of the partners, for example).

But there is a case not covered, and I think that business needs are such that this case could be very fast blocker. This case is the dual read / write access rights.

It is found in objects, but not in the fields or at the level of access rules.
Thus, if we put a right in a field, then this field disappears from the user interface who does not have the rights even if we wanted him to keep right on reading the field while the manager has the right to write.
Similarly, if for example a user does not qualify for access rules to access a record partner, then he can not even see the record.

However, case where a company needs to give read access to the largest number to information while only few people can change it is very common.
For example, imagine the case where salesmen have access to specifications of sales management. Today, everyone has write access to the quotation of all salesmen, whereas normally they should have write access to their quotations, and read about others because they can have a call with a customer of another salesman and need to consult the offer that was made.

I propose to replace the many2many access rights on elements views, fields on models and access rules by two many2many, one with groups with the read rights and the other with groups with write rights to the field or record.

Of course, the principle of accumulation of rights that prevail in the OpenERP system also applies here.
If the user is a member of one or more groups with the right reading, it will have the right read. (I should note that the read right is not sufficient to activate the buttons workflow of the record, for example to confirm an order of sale)
If he is a member of a group with the right reading and another with the right write which applied to the same field or record, then he will have the right to write.
If he is not a member of any group having at least the right read, the field will not appear on the screen.

This is really the only criticism I can make to the current access right system. With this correction, I think there will be no situation where the access right system will not be able to cope.

I already sent my comments to Tiny, let’s see what they think. In the meantime, feel free to respond in the comments.

Launch of new website Synerpgy

Hello everyone,

It is with pleasure that I announce the launch of the new company website Synerpgy: www.synerpgy.fr.

We intend to expose our work and our skills, and this new website is a great step forward to achieve this. Now, all of our internal documents will be published on the site, starting soon with our mindmap of OpenERP modules, our installation procedure OpenERP and our first training plans, technical and accounting .

Note that the entire site is licensed under Creative Common by-sa. We are passionate by free software, and we ensure this consistency to the end.

Finally, articles from our blogs or from community OpenERP will be aggregated on the site, the aim of making it also an information website about the community of OpenERP.

Technically, the CMS WordPress has been replaced by a CMS Drupal which has much more functionality we need. These include among others the management of RSS feeds with powerful display functions, the management of contributions before publication by an administrator, LDAP connector … etc. All with incredible flexibility and integrated modules to each other, it is really the CMS that we recommend for projects websites at least ambitious.

The website has taken a long time and that is why there has been only few post recently.

See you soon.

Blueprint for an improvement of promotion rule at OpenERP

Sharoon Thomas, who has done the very good poweremail and magentoerpconnect module, seems now to be interesting by an improvement of the promotion rule at OpenERP.

I done an analysis for him, especially with a comparison with the really powerful rule engine at Magento. Conclusion seem that OpenERP has good engine for product-based rule, but nothing for a shopping cart based rule. It should be a really good improvement.

Here my analysis :

Improvement of the promotion rule in OpenERP

Introduction

The goal is to improve the promotion rule tool in OpenERP. Magento has a great system for this purpose, so we’ll make a comparison with it.

Modules that already exist

A quick search in the module list show the module that might be useful :

1)discount_campaign

The goal of this module is to manage a refund system. It might be useful if for example we want to give a 5% discount if a customer buy more than 50 product A in 2009.

At least, this is my comprehension, as there is no real description. The idea is good, but I think the module should still be improved.

2)product_pricelist_discount_and_tax

This module improve management of tax at pricelist and do some control. According to me, it’s certainly a module that should be merge with the core module product, but it don’t implement a very new functionality, except management of visible discount and the possibility to specify if tax included or not.

3)sale_target_discount

This module improve the usability of the sales management by allowing to specify directly the price with the discount.

Comparison with Magento

Catalog Price Rule

The Catalog Price Rule at Magento manage the rule which are product-based. Each rule can be apply on each customer group.

At OpenERP, each Partner can have several Partner, so the way to implement the promotion are different. A meta-rule call listprice is define and possess several rule in it, we can also define an availability period. Next, we define what listprice apply to a Partner.

About the Conditions, on Magento, each field (attribute) of the product can be used as a base for a rule, so that we can use name, category but also price, tax etc… This base is next compare (equal, greater, lesser etc…) to a value or a list defined.

On OpenERP, we are limited to only a product or a category of product.

About the Action, Magento can only apply a fix or percentage amount of discount on the price.

OpenERP can apply a fix or percentage amount but also with rounding method and verification of the margin, on the sell price but also the buy price or even another list price.

Conclusion :

At the catalog price rule, Magento and OpenERP are equivalent even if Magento can base the conditions on all field of the product.

So this is the only improvement I suggest, to base condition on all field of product.product and product.template but I think the needing is limited.

Shopping Cart Price Rule

As the Catalog Price Rule, Shoping Cart Price Rule can be applied to customer group, so if an improvement will be done here, I suggest to do it in the listprice of OpenERP.

Magento has also here management of coupon. It’s perhaps the voucher in OpenERP, I don’t know.

We can define the total number of use or the per customer use of a coupon. It’s an interesting function, but I suggest to create a separated module for it, if it’s not already exist.

About Conditions, Magento can do a lot of things :

Attribute combination : It is a condition that will control each field of each product on the cart. For example, if no product contain a price greater than 100€, so the condition is true. Really interesting and no equivalent in OpenERP.

Product subselection : The condition will see if the total amount or quantity of only product that match some subconditions are equial/greater/lesser than a certain number. For example, if between the products that are bought, there are for more than 100€ of product that are considered out-dated (not ever produced), so the condition is true. Really interesting and no equivalent in OpenERP.

If any of the subtotal, quantity total, weight, payment method etc… Equal to a certain value, then condition are true. Basic, but it is still a leak in OpenERP.

About action :

We can apply a fixed or percentage amount of discount per product, or for the whole cart. We can also apply a “Buy Y have X free” rule or free shipping. All of this apply on each product or product that are determined by conditions bases on their field.

Conclusion : None of all of these exist in OpenERP, there is no Shopping Cart Price Rule functionality. At the contrary, the Magento one was just really powerful, just perfect.

I really suggest to implement a module that will implement it the same way as Magento, even by copying the way it is implemented.

Conclusion

It seams that finally conclusion was easy to find, Magento show us the way of the functionality, we should just implement as in Magento.

For the moment I don’t push far further the analysis, feel free to contact me if you need more help.