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: [24490] Re: Odoo POS and Technische Sicherheitseinrichtung (TSE)

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

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