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
Akretion France, David BEAL
- 25/08/2020 17:08:12
Hi Peter,

Again, I think you should give a try to https://github.com/shopinvader/odoo-pim and product_attribute_set
to populate specific data on your products. It avoids creating all combinations of attributes even if some variant cases do not exist.

These modules will join OCA in next month and are carefully maintained by several integrators.

Regards


David BEAL - akretion.com
Consultant
Odoo Intégration / Développement


Le mar. 25 août 2020 à 16:52, Peter Hahn <peter.hahn@initos.com> a écrit :
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