Contributors mailing list archives

contributors@odoo-community.org

Re: New Odoo Product Configurator Module

by
Tecnativa. S. L., Pedro M. Baeza
- 18/03/2016 11:57:08
Paul, another remark: attribute restriction is also implemented by us here: https://github.com/odoomrp/odoomrp-wip/pull/904 (but only as a POC).

Regards.

2016-03-18 12:53 GMT+01:00 Paul Catinean <paulcatinean@gmail.com>:
Thank you for your input Ermin

Regardin POS I have not tested yet and I will have another look at migration to V9. When I tried it during V9 release one could not even define a regular product since the one2many fields were messed up.I feel it will not be difficult to migrate since I migrated the V7 version with the product_variant_multi community module to the new API, new variant standard addon along with a working database while in production.

To be honest my version does not go into manufacturing much it is more a way to generate new variants with attribute restrictions.Thus it will not be changed that much by MRP updates.

While the OdooMRP modules indeed generate variants from the backend they do not employ any sort of attribute restrictions. Meaning you can basically build a new variant with any of the attributes on the product.template with no restrictions, anything goes.

Also it does not allow multiple selection of the same attributes or provide a method of generating variants in a interface with separate steps. While this might not seem like a big issue, choose any online configurator for a car and imagine making a variant with that myriad of options with multiple interdependencies in a single many2many/one2many widget.

To me personally the biggest work in both modules revolved around these restrictions / dependencies. Whether a backend or a frontend configuration interface is used depends on the business needs but that is the core of a configurator. A interface that guides you through the process of customizing your product intuitively with no possibility of making errors. Not just a method of stopping variants from being automatically created and doing it manually.

I have a example of a backend configurator done in a module for my client which as said before uses a bit of "black magic".This is the reason I did not present it from the start since in my opinion it does not meet coding or OCA standards for wide use. Also considering other alternatives for the backend but I digress:


That wizard alone has over 700 lines of code. Started from the order line, you select a configurable product, and the many2one fields are dynamically generated based on the attributes set on the product.template. The domains of the fields are updated as you pick options, as well as readonly toggling both taking the attribute restrictions into consideration.

For my customer the variant creation process contacts a software's API that feeds BOM and Pricing information, allows you to update if you manually wish to do so. After which you can reconfigure the product, update it and when a configuration for a product with the same attributes is made it makes a diff between the database values and API values (boms and prices in this case).This was the next module planned for OCA conversion and release since I believe quite a few manufacturers have the same method.

In ending the product_configurator module handles dependencies (which is a fundamental feature), multiple selections, separate steps and images for intermediate and final configurations. It's the basis for the backend configurator you have just seen and the website configurator alike

While it is considered to be exactly the same as the available modules except "just" the website configurator. The main.py controller in the website module alone has 800 of lines of code.Not adding up other models, javascript etc.

Also both are installable, working in production with little to no problems and doing the job.I have worked very hard on all of them to provide a solution for my customer and succeeded. And the plan was to take it a step further and change it so it would apply for everyone, as far as my customer is concerned nothing is changed and there's no added value from the previous version. Behind the curtains it's a totally different story and a large leap in my opinion

Kind Regards,
Paul


On Thu, Mar 17, 2016 at 10:23 PM, Ermin Trevisan <trevi@twanda.com> wrote:
Of course an integration/enhancement of OdooMRP would be an optimum
solution.

But on the other hand, many parts of OdooMRP are still 7.0, the rest is
8.0. When will/should they be ported? Especially when you think of Odoo
10.0 with a new manufacturing concept?

In this light a solution like this product configurator makes a lot of
sense because it provides a good solution to a badly missed feature in
Odoo e-commerce.
For that money it could be a good way to span a time until version 10
will have widely spread and OdooMRP has evolved accordingly.

But this product configurator must absolutely cover POS also and be
available in very short time also for release 9.0

Just my 2cents


On 16.03.2016 15:38, Levent Karakas wrote:
> Paul, have you checked OdooMRP's product configurator addons?
> (sale_product_variants, sale_product_variants_types,
> product_variants_no_automatic_creation, product_attribute_types,
> product_attribute_types_views, product_attribute_views and so on)
> website_sale part of it doesn't exist (afaik) but it works very nice as
> itself. Completing missing features might be an option for you....
> 


-- 
twanda AG
Ermin Trevisan
Artherstrasse 19
CH-6318 Walchwil
T    +41 41 758 1515
M    +41 79 208 7373
E    trevi@twanda.com
www.twanda.ch
www.twanda.ch/page/restaurant

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe