Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: Best model for selling unique products (used machines)
Re: [24490] Re: Odoo POS and Technische Sicherheitseinrichtung (TSE)
Re: Best model for selling unique products (used machines)
by
Data Dance s.r.o., Radovan Skolnik
Hello, those odoo-pim modules look very useful to me. I need to use something similar to (product_)attribute_set but until now I was focused on base_custom_info/ product_custom_info. This seems very similar to these in my opinion. If anybody's familiar with both is there any significant difference that should be taken into account? Side-questin: all the modules in 13.0 branch are marked as non-installable. Are they not ready yet? Thank you for great effort. Really appreciated. Best regards Radovan Skolnik On utorok 25. augusta 2020 17:12:14 CEST David Beal wrote: > Hi Peter, > Again, I think you should give a try to > https://github.com/shopinvader/odoo-pim [1] 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 [2] Consultant > Odoo Intégration / Développement > Le mar. 25 août 2020 à 16:52, Peter Hahn < peter.hahn@initos.com [3] > 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/produ > > ct_template.py [4] [1] -- Yoshi Tashiro > > > > On Mon, Aug 24, 2020 at 11:12 PM Frederik Kramer < > > frederik.kramer@initos.com [5] [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 [6] [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 [7] [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 [8] [5] > >> > >> Einfach. Digital. Wachsen. > >> -- Odoo Ready Partner -- Website > >> Kontakt > >> Impressum > >> Datenschutz > >> > >> > >> > >> © 2019 dygytally.de [9] [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 > >>> [10] [7]>>> > >>> [1] > >>> > >>> https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > >>> [11] [8]>>> > >>> [2] > >>> > >>>> and in pending migration > >>>> > >>>> https://github.com/OCA/sale-workflow/pull/1144 [12] [9] [3] > >>>> > >>>> Note that sale_order_lot_selection in v12 and v13 are different, > >>> > >>> consider the v12 one > >>> > >>>> Best regards > >>>> > >>>> > >>>> > >>>> David BEAL - akretion.com [13] [10] [4] Consultant > >>>> > >>>> Odoo Intégration / Développement > >>>> > >>>> Le ven. 21 août 2020 à 15:36, Peter Hahn < peter.hahn@initos.com [14] > >>>> [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 [15] > >>>> [12] > >>> > >>> [6] > >>> > >>>> Post to: mailto: contributors@odoo-community.org [16] [13] [7] > >>>> > >>>> Unsubscribe: https://odoo-community.org/groups?unsubscribe [17] [14] > >>>> [8] > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> > >>>> Mailing-List: https://odoo-community.org/groups/contributors-15 [18] > >>>> [15] > >>> > >>> [9] > >>> > >>>> Post to: mailto: contributors@odoo-community.org [19] [16] > >>>> > >>>> Unsubscribe: https://odoo-community.org/groups?unsubscribe [20] [17] > >>>> [10] > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> [1] > >>>> > >>> https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > >>> [21] [18]>>> > >>>> [2] > >>>> > >>> https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > >>> [22] [19]>>> > >>>> [3] https://github.com/OCA/sale-workflow/pull/1144 [23] [20] > >>>> > >>>> [4] http://akretion.com [24] [21] > >>>> > >>>> [5] mailto: peter.hahn@initos.com [25] [22] > >>>> > >>>> [6] https://odoo-community.org/groups/contributors-15 [26] [23] > >>>> > >>>> [7] mailto: contributors@odoo-community.org [27] [24] > >>>> > >>>> [8] https://odoo-community.org/groups?unsubscribe [28] [25] > >>>> > >>>> [9] https://odoo-community.org/groups/contributors-15 [29] [26] > >>>> > >>>> [10] https://odoo-community.org/groups?unsubscribe [30] [27] > >>> > >>> _______________________________________________ > >>> Mailing-List: https://odoo-community.org/groups/contributors-15 [31] > >>> [28] > >>> Post to: mailto: contributors@odoo-community.org [32] [29] > >>> Unsubscribe: https://odoo-community.org/groups?unsubscribe [33] [30] > >> > >> _______________________________________________ > >> Mailing-List: https://odoo-community.org/groups/contributors-15 [34] > >> [31] > >> Post to: mailto: contributors@odoo-community.org [35] [32] > >> Unsubscribe: https://odoo-community.org/groups?unsubscribe [36] [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 [37] [34] > > Web: www.initos.com [38] [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 [39] [36] > > Post to: mailto: contributors@odoo-community.org [40] [37] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [41] [38] > > > > > > _______________________________________________ > > Mailing-List: https://odoo-community.org/groups/contributors-15 [42] [39] > > Post to: mailto: contributors@odoo-community.org [43] > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [44] [40] > > > > > > > > [1] > > https://github.com/qrtl/sst-custom/blob/11.0/product_ext_sst/models/produ > > ct_template.py [45] [2] mailto: frederik.kramer@initos.com [46] > > [3] http://dygytally.de [47] > > [4] http://dygytally.de [48] > > [5] http://dygytally.de [49] > > [6] http://dygytally.de [50] > > [7] > > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > > [51] [8] > > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > > [52] [9] https://github.com/OCA/sale-workflow/pull/1144 [53] > > [10] http://akretion.com [54] > > [11] mailto: peter.hahn@initos.com [55] > > [12] https://odoo-community.org/groups/contributors-15 [56] > > [13] mailto: contributors@odoo-community.org [57] > > [14] https://odoo-community.org/groups?unsubscribe [58] > > [15] https://odoo-community.org/groups/contributors-15 [59] > > [16] mailto: contributors@odoo-community.org [60] > > [17] https://odoo-community.org/groups?unsubscribe [61] > > [18] > > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > > [62] [19] > > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > > [63] [20] https://github.com/OCA/sale-workflow/pull/1144 [64] > > [21] http://akretion.com [65] > > [22] mailto: peter.hahn@initos.com [66] > > [23] https://odoo-community.org/groups/contributors-15 [67] > > [24] mailto: contributors@odoo-community.org [68] > > [25] https://odoo-community.org/groups?unsubscribe [69] > > [26] https://odoo-community.org/groups/contributors-15 [70] > > [27] https://odoo-community.org/groups?unsubscribe [71] > > [28] https://odoo-community.org/groups/contributors-15 [72] > > [29] mailto: contributors@odoo-community.org [73] > > [30] https://odoo-community.org/groups?unsubscribe [74] > > [31] https://odoo-community.org/groups/contributors-15 [75] > > [32] mailto: contributors@odoo-community.org [76] > > [33] https://odoo-community.org/groups?unsubscribe [77] > > [34] mailto: frederik.kramer@initos.com [78] > > [35] http://www.initos.com [79] > > [36] https://odoo-community.org/groups/contributors-15 [80] > > [37] mailto: contributors@odoo-community.org [81] > > [38] https://odoo-community.org/groups?unsubscribe [82] > > [39] https://odoo-community.org/groups/contributors-15 [83] > > [40] https://odoo-community.org/groups?unsubscribe [84] > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [85] > Post to: mailto: contributors@odoo-community.org [86] > Unsubscribe: https://odoo-community.org/groups?unsubscribe [87] > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [88] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [89] > > > > [1] https://github.com/shopinvader/odoo-pim > [2] http://akretion.com > [3] mailto:peter.hahn@initos.com > [4] > https://github.com/qrtl/sst-custom/blob/11.0/product_ext_sst/models/product > _template.py [5] mailto:frederik.kramer@initos.com > [6] http://dygytally.de > [7] http://dygytally.de > [8] http://dygytally.de > [9] http://dygytally.de > [10] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > [11] > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > [12] https://github.com/OCA/sale-workflow/pull/1144 > [13] http://akretion.com > [14] mailto:peter.hahn@initos.com > [15] https://odoo-community.org/groups/contributors-15 > [16] mailto:contributors@odoo-community.org > [17] https://odoo-community.org/groups?unsubscribe > [18] https://odoo-community.org/groups/contributors-15 > [19] mailto:contributors@odoo-community.org > [20] https://odoo-community.org/groups?unsubscribe > [21] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > [22] > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > [23] https://github.com/OCA/sale-workflow/pull/1144 > [24] http://akretion.com > [25] mailto:peter.hahn@initos.com > [26] https://odoo-community.org/groups/contributors-15 > [27] mailto:contributors@odoo-community.org > [28] https://odoo-community.org/groups?unsubscribe > [29] https://odoo-community.org/groups/contributors-15 > [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] https://odoo-community.org/groups/contributors-15 > [35] mailto:contributors@odoo-community.org > [36] https://odoo-community.org/groups?unsubscribe > [37] mailto:frederik.kramer@initos.com > [38] http://www.initos.com > [39] https://odoo-community.org/groups/contributors-15 > [40] mailto:contributors@odoo-community.org > [41] https://odoo-community.org/groups?unsubscribe > [42] https://odoo-community.org/groups/contributors-15 > [43] mailto:contributors@odoo-community.org > [44] https://odoo-community.org/groups?unsubscribe > [45] > https://github.com/qrtl/sst-custom/blob/11.0/product_ext_sst/models/product > _template.py [46] mailto:frederik.kramer@initos.com > [47] http://dygytally.de > [48] http://dygytally.de > [49] http://dygytally.de > [50] http://dygytally.de > [51] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > [52] > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > [53] https://github.com/OCA/sale-workflow/pull/1144 > [54] http://akretion.com > [55] mailto:peter.hahn@initos.com > [56] https://odoo-community.org/groups/contributors-15 > [57] mailto:contributors@odoo-community.org > [58] https://odoo-community.org/groups?unsubscribe > [59] https://odoo-community.org/groups/contributors-15 > [60] mailto:contributors@odoo-community.org > [61] https://odoo-community.org/groups?unsubscribe > [62] https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > [63] > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > [64] https://github.com/OCA/sale-workflow/pull/1144 > [65] http://akretion.com > [66] mailto:peter.hahn@initos.com > [67] https://odoo-community.org/groups/contributors-15 > [68] mailto:contributors@odoo-community.org > [69] https://odoo-community.org/groups?unsubscribe > [70] https://odoo-community.org/groups/contributors-15 > [71] https://odoo-community.org/groups?unsubscribe > [72] https://odoo-community.org/groups/contributors-15 > [73] mailto:contributors@odoo-community.org > [74] https://odoo-community.org/groups?unsubscribe > [75] https://odoo-community.org/groups/contributors-15 > [76] mailto:contributors@odoo-community.org > [77] https://odoo-community.org/groups?unsubscribe > [78] mailto:frederik.kramer@initos.com > [79] http://www.initos.com > [80] https://odoo-community.org/groups/contributors-15 > [81] mailto:contributors@odoo-community.org > [82] https://odoo-community.org/groups?unsubscribe > [83] https://odoo-community.org/groups/contributors-15 > [84] https://odoo-community.org/groups?unsubscribe > [85] https://odoo-community.org/groups/contributors-15 > [86] mailto:contributors@odoo-community.org > [87] https://odoo-community.org/groups?unsubscribe > [88] https://odoo-community.org/groups/contributors-15 > [89] https://odoo-community.org/groups?unsubscribe
Reference
-
Best model for selling unique products (used machines)
byInitOS GmbH, Pete Hahn-
Re: Best model for selling unique products (used machines)
byAxel Mendoza -
Re: Best model for selling unique products (used machines)
byInitOS GmbH, Frederik Kramer -
Re: Best model for selling unique products (used machines)
byMoaHub, Graeme Gellatly -
Re: Best model for selling unique products (used machines)
byInitOS GmbH, Pete Hahn -
Re: Best model for selling unique products (used machines)
byAcsone SA/NV, Denis Roussel -
Re: Best model for selling unique products (used machines)
byQuartile Limited., Yoshi Tashiro.- 26/08/2020 04:10:09 - 0 -
Re: Best model for selling unique products (used machines)
byMoaHub, Graeme Gellatly -
Re: Best model for selling unique products (used machines)
byMoaHub, Graeme Gellatly -
Re: Best model for selling unique products (used machines)
byData Dance s.r.o., Radovan Skolnik