1. Mailing Lists
  2. Contributors
  3. Re: Best model for selling unique products (used machines)

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

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

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

Avatar

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

by
InitOS GmbH, Pete Hahn
- 25/08/2020 16:48:42 
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

>

Reference