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, Frederik Kramer
- 26/08/2020 23:01:19 
Hi Graeme, 

Peter and me had a intense discussion on the matter today again.
Probably none of the solutions (purely thought) is really it. 

We deal with instances of technical machinery (agricultural machinery
to be precise). Almost always there is a base product but then there is
a set of attributes (each of which may be boolean, text, integer
sometimes in a configurable list). So its much like the use case in e-
Commerce (hat odoo-pim and Akretion adressed). However, each of these
instances also has a unique serial number at a certain point. This
serial number (just like a car) is the unique identifier with which the
concrete machine is recognizable not only by our customer but also by
the manufacturer and diverse other organisations (including the state).
So theoretically its valid to extend stock.production.lot or
product.product to store the additional information there. We were
almost changing our minds from the inital solution
(stock.production.lot) to product.product but that the fact that we
really have trouble having a clean UI for spare parts (w/o) serial
number and without massive attribute sets renders this solution
cumbersome. So we no probably go for extending product.product with an
addtional and specific model that is just beeing used and filled if the
concrete product is a machinery and not for intance a nut or a nail or
whatever. Certainly this also comes with drawbacks but probaly less
then extending either of the aforemetioned models directly.

Best Frederik
 

Am Mittwoch, den 26.08.2020, 20:42 +0000 schrieb Graeme Gellatly:

> Your main issue is this.

> 

> If I sell lots of the same product in different states with a

> reasonably high inventory turnover - then I'd use lots. The reason

> is, plenty can go wrong using products, like imagine the work in

> activating, deactivating, creating a new product each time,

> stocktakes and maintenance. You end up with 100's of items with very

> similar descriptions, some are in stock some aren't.  If a user picks

> the wrong one, it actually sucks changing everything like the sale,

> picking etc, whereas for lots it is generally easily editable. 

> 

> If I sell few products or always different makes/models, then using

> product, deaactivating and all the other work on the item list

> maintenance side might be worth it and easier than the work in

> maintaining lots.  You just duplicate, update description etc and

> hope noone makes a mistake with accounts, categories, duplicate

> references etc.

> 

> To me lots are completely natural, as a lot is a specific

> identifiable instance of a product, but if you are treating products

> as essentially the lot anyway then there is no point.

> 

> On Wed, Aug 26, 2020 at 8:12 PM Peter Hahn <peter.hahn@initos.com>

> wrote:

> > Dear all, thanks for all the input.

> > 

> > Am 26.08.20 um 09:52 schrieb Roussel, Denis:

> > 

> > 

> > > From my point of view and from near experience of customer of

> > ours, we advise as some said to not change too much the Odoo base

> > objects purpose as, along project life, you'll need to twist all

> > the Odoo flows to adapt to your changes. 

> > 

> > That’s interesting, because that’s the main thing I am thinking

> > about:

> > Which approach will break the most/need the most customization?

> > 

> > What flows do you think of exactly?

> > 

> > In my use case I only intend to add informative information to the

> > products, so my current impression is, that using products will

> > give me

> > all the flows I need out of the box, while `stock.production.lot`

> > will

> > be at least a bit cumbersome in the UI for users and need

> > customizations

> > to make it work as expected for the user. (E.g. I think one would

> > expect

> > the sold machine (lot) named on the invoice)

> > 

> > 

> > 

> > > As Graeme said, the lots are the good place to extend

> > modelization for one product instance.

> > Ok. This seams to be somewhat common sence among the list.

> > 

> > 

> > Ok. I think I don’t need to bother you anymore but just make a

> > decision.

> > 

> > So to get to more concrete question:

> > What could be possibly go wrong using product.product?

> > What do you expect to break?

> > 

> > The only thing I can think off that would be strange is, if they

> > one day

> > decide to sell something completly different things too. Than all

> > the

> > machine specific information won’t make much sense.

> > _______________________________________________

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

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

> > Unsubscribe: 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

-- 
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
Web:   www.initos.com
        
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

Reference