Contributors mailing list archives

contributors@odoo-community.org

Avatar

RE: Best model for selling unique products (used machines)

by
johan
- 25/08/2020 18:19:07

Dear,

 

You will always have to choose between a simple implementation or (a lot of ) customization.

A simple way is to use standard Odoo and adapt the description field on the sales order line to hold a big amount of text. People can than bring in all the info in this field. Of course, the field will be filled different by different people. But when you sell / buy 5 machines/m then this is perhaps the best way. For sure when the machines have not so much in common. Eventually you can attach a standard fill in document with the order / offer with a more structured description.

When you want, you could also make relation field on the sales line to a new model ‘machine’. Here you can record a lot of common attributes, that can be filled in a pop up screen. With a ‘Type’ field and inheritance you can even customize for differ types of machinery ( welding / milling / sawing / CNC / …. ). But of course, the more specific you go, the more labor it will cost to build your solution. For a big company that sells or buys 100e machines/m this can be worth the effort, for a small one….

 

With kind regards,

 

Van Hirtum Johan  

 

Van: Peter Hahn [mailto:peter.hahn@initos.com]
Verzonden: dinsdag 25 augustus 2020 16:52
Aan: Contributors
Onderwerp: Re: Best model for selling unique products (used machines)

 

Thanks.

 

I think the main problem with Odoo at this point is that there is no

*true* inherance possible like in C++ or other languages.

 

Normaly you would have some basic interface for things you could put in

a sale order line and call that a product. And it would be possible to

inherit from this to have very specific things that all have the basic

property in common that you could put them on a sale order line.

 

In Odoo inherance is extension of the base class in most cases. (I know

I can inherit without exending the base – but then I can’t use the base

interface anymore at places where the base is expected)

 

Ideally I would like to have something completly new, like a

`used.machine` model and just add interface to be used as a product.

 

Adding everything I need to describe a machine to `product.product` via

customization seams somehow as wrong as to `stock.production.lot`

eighter, after all.

 

Hmm.

 

 

 

 

Am 24.08.20 um 17:02 schrieb Yoshi Tashiro:

 

> We extended the product template model for a similar requirement (reuse business handling a lot of home electronic products).  We did not go for the option of using stock.production.lot for the same reasons as Peter raises.  We haven't had a major issue pertaining to this decision.

 

> Here is part of what we did if that gives some idea:  https://github.com/qrtl/sst-custom/blob/11.0/product_ext_sst/models/product_template.py [1]          --  Yoshi Tashiro

 

> 

 

> On Mon, Aug 24, 2020 at 11:12 PM Frederik Kramer < frederik.kramer@initos.com [2] > wrote:

 

> Hi Bettina,

 

> thanks for this insight. Obviously my PM heart agrees. By doing such

 

> project we should also ask the rather business oriented questions on

 

> what may happen next in the mind of the customer and also give a

 

> helping hand and ideas on conceiving this future.

 

> Nevertheless if you boil it down to engineering practise it is often

 

> relatively cumbersome to start out with a "simple" solution, because

 

> simple in case of Odoo (from a business perspective) means "using" a

 

> standard from the OCA (which is usually well elaborated on overall and

 

> very generic needs and integrated with lots of other modules) or doing

 

> exactly what you need (now or for the near future).

 

> If you one uses the OCA standard this is simple as it doesn't require

 

> you to reinvent something and is also desireable from the

 

> standardization point of view, but it comes with a certain payload

 

> (maintaining the code and all its dependencies also for the 80% of the

 

> functionality included you never or seldomly need). On the other just

 

> adding what you need is easy as it doesn't involve too much development

 

> (and therefore budget discussion with the customer) but often evolves

 

> into something that becomes more and more like the original OCA

 

> standard after N interations (obviously not desireable as this is a

 

> waste of resources as well).

 

> One of the problems that developers often have is that the OCA / Odoo

 

> standard in the first place looks like something that you need to have

 

> a PhD for to understand in its entirety.

 

> As far as i understood Peter he is just questioning (with regard to

 

> CRM) if it would really be desireable to use stock.production.lot and

 

> make that work with the typical sale.order object or rather use

 

> product.product and extend it (obviously loosing complexity trough

 

> depence but also information such as traceability in stock moves).

 

> This is not only to be answered with the concrete business domain at

 

> hand but also with the opinion of colleagues around the globe that

 

> faced a similar problem in the past.

 

> I personally always tend to go for the "standard" OCA solution but for

 

> instance in terms of "ease of use" for the end user that is rather

 

> seldomly a very good shot in the first place

 

> Thank you very much for your opinion on the matter

 

> Best Frederik

 

> 

 

> Am Montag, den 24.08.2020, 13:26 +0000 schrieb Bettina Pfeifer

 

> dygytally.de [3] :

 

>> Hi Peter,

 

>>

 

 

>> sometimes it helps to imagine what you (your future odoo client) want

 

>> to know after one, two, three ... years of sales. What would you like

 

>> to know about all your sales, the products you sold. Which ones made

 

>> trouble after sales, which ones made your odoo client happy, which

 

>> ones led to more trades, which ones where hard to get and easy to

 

>> sell or vice versa. Which ones need a lot of warehouse space, which

 

>> ones need special care. How do you want to report on the past. What

 

>> decisions should be made for the future.

 

>>

 

 

>> Maybe this helps a bit to decide on your current question. Sometimes

 

>> these questions make the odoo client reveal their true needs.

 

>>

 

 

>> And if you are able to generate the "list" you mention, that might be

 

>> good starting point.

 

>>

 

 

>> And the original serial numbers of the used machines themselves

 

>> should be used, as long as they have one. Otherwise you could create

 

>> an own serial number.

 

>>

 

 

>> In general, why not start as easy as possible, until other

 

>> requirements arise while using odoo.

 

>>

 

 

>> Regards, Bettina

 

>>

 

 

>>

 

 

>>  dygytally.de [4] GmbH

 

>> Margarete-Steiff-Str. 7

 

>> 60438 Frankfurt am Main

 

>>

 

 

>> mobil +49 170 5423 951

 

>> WhatsApp +49 175 1042428

 

>> Tel +49 69 758 44766

 

>> Fax +49 69 758 44767        Geschäftsführerin: Bettina Pfeifer

 

>>

 

 

>> Handelsregister: Frankfurt HRB 106317

 

>>

 

 

>>

 

 

>>  dygytally.de [5]

 

>> Einfach. Digital. Wachsen.

 

>> -- Odoo Ready Partner --    Website

 

>> Kontakt

 

>> Impressum

 

>> Datenschutz

 

>>

 

 

>>

 

 

>>

 

 

>> © 2019  dygytally.de [6]

 

>> Am 24.08.20 um 13:17 schrieb Peter Hahn:

 

>>> Hi David,

 

>>>

 

 

>>> thanks for your suggestion. I didn’t knew the module.

 

>>>

 

 

>>> I’m still not really convinced using serial numbers is the right

 

>>> thing

 

>>> here in general.

 

>>> Sure it would be for smart phones and stuff like this, but I would

 

>>> really like to hear opinions about what problems may arise in case

 

>>> of

 

>>> just using `product.product`.

 

>>>

 

 

>>> At first glance this seams to be way more simple. Especially I

 

>>> think

 

>>> it’s intuitive for the users because in their business mindset they

 

>>> don’t think of _machines_ and _instances of machines_ but just a

 

>>> specific _machine_ from their list.

 

>>>

 

 

>>> Our use case to me looks more like being the base machine a

 

>>> `product.template` and the unique machine a `product.product`.

 

>>>

 

 

>>> However I wouldn’t use all the `product.attribute` machinery for

 

>>> this,

 

>>> of course.

 

>>>

 

 

>>> I hope to hear more opinions from the list about this.

 

>>>

 

 

>>> Thanks. Regards, Peter

 

>>>

 

 

>>>

 

 

>>>

 

 

>>> Am 21.08.20 um 17:02 schrieb David Beal:

 

>>>

 

 

>>>> Hi Peter,

 

>>>

 

 

>>>> Consider these modules

 

>>>

 

 

>>>>

 

 

>>>  https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection [7]

 

>>> [1]

 

>>>  https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator [8]

 

>>> [2]

 

>>>

 

 

>>>> and in pending migration

 

>>>

 

 

>>>>  https://github.com/OCA/sale-workflow/pull/1144 [9] [3]

 

>>>

 

 

>>>> Note that sale_order_lot_selection in v12 and v13 are different,

 

>>> consider the v12 one

 

>>>

 

 

>>>> Best regards

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>> David BEAL -  akretion.com [10] [4] Consultant

 

>>>

 

 

>>>> Odoo Intégration / Développement

 

>>>

 

 

>>>> Le ven. 21 août 2020 à 15:36, Peter Hahn <  peter.hahn@initos.com [11]

 

>>> [5] > a écrit :

 

>>>

 

 

>>>> Hello,

 

>>>

 

 

>>>> I have a hard time to decide which Odoo model to use for selling

 

>>> unique

 

>>>

 

 

>>>> products.

 

>>>

 

 

>>>> The products are used machines. So in general one could think of

 

>>> a

 

>>>

 

 

>>>> generic product with manufacturer and model and a certain

 

>>> instance of it.

 

>>>

 

 

>>>> But since these are used items, they come with a lot of

 

>>> customizations

 

>>>

 

 

>>>> and other instance specific attributes like operation hours etc.

 

>>>

 

 

>>>> So it’s more like the product == instance.

 

>>>

 

 

>>>> We thought about using `product.product` for the brand/model and

 

>>>

 

 

>>>> `stock.production.lot` for the instance, but after some research

 

>>> in the

 

>>>

 

 

>>>> odoo v12 code I'm not sure if this is really the best option.

 

>>>

 

 

>>>> To me it looks like `stock.production.lot` is more about

 

>>> tractability of

 

>>>

 

 

>>>> instance of generic products **after** they have been sold, since

 

>>>

 

 

>>>> `stock.production.lot` is very tightly tied to stock operations.

 

>>>

 

 

>>>> We need to have product instances already during the whole CRM,

 

>>> Quote,

 

>>>

 

 

>>>> SaleOrder process. I don’t see how to easily put

 

>>> `stock.production.lot`

 

>>>

 

 

>>>> on `sale.order.lines`.

 

>>>

 

 

>>>> The other option would be just going for `product.product` and

 

>>> assume

 

>>>

 

 

>>>> product == product instance.

 

>>>

 

 

>>>> I’m not really sure about benefits/drawbacks or maybe

 

>>> other/better

 

>>>

 

 

>>>> approaches.

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>> Please give me your opinions about what model is best to use as a

 

>>> base

 

>>>

 

 

>>>> for selling unique items in odoo.

 

>>>

 

 

>>>> Thanks. Regards, Peter

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>> _______________________________________________

 

>>>

 

 

>>>> Mailing-List:  https://odoo-community.org/groups/contributors-15 [12]

 

>>> [6]

 

>>>

 

 

>>>> Post to: mailto:  contributors@odoo-community.org [13] [7]

 

>>>

 

 

>>>> Unsubscribe:  https://odoo-community.org/groups?unsubscribe [14] [8]

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>> _______________________________________________

 

>>>

 

 

>>>> Mailing-List:  https://odoo-community.org/groups/contributors-15 [15]

 

>>> [9]

 

>>>

 

 

>>>> Post to: mailto: contributors@odoo-community.org [16]

 

>>>

 

 

>>>> Unsubscribe:  https://odoo-community.org/groups?unsubscribe [17] [10]

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>>

 

 

>>>

 

 

>>>> [1]

 

>>>  https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection [18]

 

>>>

 

 

>>>> [2]

 

>>>  https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator [19]

 

>>>

 

 

>>>> [3]  https://github.com/OCA/sale-workflow/pull/1144 [20]

 

>>>

 

 

>>>> [4]  http://akretion.com [21]

 

>>>

 

 

>>>> [5] mailto: peter.hahn@initos.com [22]

 

>>>

 

 

>>>> [6]  https://odoo-community.org/groups/contributors-15 [23]

 

>>>

 

 

>>>> [7] mailto: contributors@odoo-community.org [24]

 

>>>

 

 

>>>> [8]  https://odoo-community.org/groups?unsubscribe [25]

 

>>>

 

 

>>>> [9]  https://odoo-community.org/groups/contributors-15 [26]

 

>>>

 

 

>>>> [10]  https://odoo-community.org/groups?unsubscribe [27]

 

>>>

 

 

>>>>

 

 

>>> _______________________________________________

 

>>> Mailing-List:  https://odoo-community.org/groups/contributors-15 [28]

 

>>> Post to: mailto: contributors@odoo-community.org [29]

 

>>> Unsubscribe:  https://odoo-community.org/groups?unsubscribe [30]

 

>>>

 

 

>>

 

 

>> _______________________________________________

 

>> Mailing-List:  https://odoo-community.org/groups/contributors-15 [31]

 

>> Post to: mailto: contributors@odoo-community.org [32]

 

>> Unsubscribe:  https://odoo-community.org/groups?unsubscribe [33]

 

> --

 

> Dr.-Ing. Frederik Kramer

 

> Geschäftsführer

 

> initOS GmbH

 

> An der Eisenbahn 1

 

> 21224 Rosengarten

 

> Phone: +49 4105 56156-12

 

> Fax:  +49 4105 56156-10

 

> Mobil: +49 179 3901819

 

> Email:  frederik.kramer@initos.com [34]

 

> Web:  www.initos.com [35]

 

> Geschäftsführung:

 

> Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

 

> Sitz der Gesellschaft: Rosengarten – Klecken

 

> Amtsgericht Tostedt, HRB 205226

 

> Steuer-Nr: 15/200/53247

 

> USt-IdNr.: DE815580155

 

> 

 

> _______________________________________________

 

> Mailing-List: https://odoo-community.org/groups/contributors-15 [36]

 

> Post to: mailto: contributors@odoo-community.org [37]

 

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [38]

 

> 

 

> 

 

> _______________________________________________

 

> Mailing-List: https://odoo-community.org/groups/contributors-15 [39]

 

> Post to: mailto:contributors@odoo-community.org

 

> Unsubscribe: https://odoo-community.org/groups?unsubscribe [40]

 

> 

 

> 

 

> 

 

> [1] https://github.com/qrtl/sst-custom/blob/11.0/product_ext_sst/models/product_template.py

 

> [2] mailto:frederik.kramer@initos.com

 

> [3] http://dygytally.de

 

> [4] http://dygytally.de

 

> [5] http://dygytally.de

 

> [6] http://dygytally.de

 

> [7] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection

 

> [8] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator

 

> [9] https://github.com/OCA/sale-workflow/pull/1144

 

> [10] http://akretion.com

 

> [11] mailto:peter.hahn@initos.com

 

> [12] https://odoo-community.org/groups/contributors-15

 

> [13] mailto:contributors@odoo-community.org

 

> [14] https://odoo-community.org/groups?unsubscribe

 

> [15] https://odoo-community.org/groups/contributors-15

 

> [16] mailto:contributors@odoo-community.org

 

> [17] https://odoo-community.org/groups?unsubscribe

 

> [18] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection

 

> [19] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator

 

> [20] https://github.com/OCA/sale-workflow/pull/1144

 

> [21] http://akretion.com

 

> [22] mailto:peter.hahn@initos.com

 

> [23] https://odoo-community.org/groups/contributors-15

 

> [24] mailto:contributors@odoo-community.org

 

> [25] https://odoo-community.org/groups?unsubscribe

 

> [26] https://odoo-community.org/groups/contributors-15

 

> [27] https://odoo-community.org/groups?unsubscribe

 

> [28] https://odoo-community.org/groups/contributors-15

 

> [29] mailto:contributors@odoo-community.org

 

> [30] https://odoo-community.org/groups?unsubscribe

 

> [31] https://odoo-community.org/groups/contributors-15

 

> [32] mailto:contributors@odoo-community.org

 

> [33] https://odoo-community.org/groups?unsubscribe

 

> [34] mailto:frederik.kramer@initos.com

 

> [35] http://www.initos.com

 

> [36] https://odoo-community.org/groups/contributors-15

 

> [37] mailto:contributors@odoo-community.org

 

> [38] https://odoo-community.org/groups?unsubscribe

 

> [39] https://odoo-community.org/groups/contributors-15

 

> [40] https://odoo-community.org/groups?unsubscribe

 

> 

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

Reference