Archives
Contributors
-
Re: Projects - send one invoice per customer
Hi Daniel, on latest releases, the grouping is done when you create invoices from list view, and select the orders previously, in this case the invoice it's grouped by partner. On Thu, 2020-09-03 at 10:12 +0000, Andrew Dyson - Hotmail wrote: > We have used the same one, you can set if the client/customer wants a > single or individual invoices. You have to greate the draft invoices > first if I recall as we used it on recurring contracts. But it is > certainly a good module > Andy > On 03/09/2020 11:07, Florent Cayré wrote: > > Hello Daniel, > > for this purpose (but with invoices generated by multiple > > contracts), we use > > https://github.com/OCA/account-invoicing/tree/10.0/account_invoice_merge > > (also ported to 12.0 although I haven't tried it yet). > > > > Hope this helps, > > -- > > > > Florent Cayré > > Co-fondateur de Commown > > https://commown.coop > > > > > > > > Le 03/09/2020 à 11:27, Daniel Reis a écrit : > > > Hello Contributors, > > > > > > I have a requirement that, as far as i can see, there are no OCA > > > modules > > > available to help with. > > > > > > We are billing time on projects. > > > Out of the box, Odoo is capable of generating one invoices for > > > each project. > > > > > > I would like to be able to send out invoices by customer. > > > So if a customer has two active projects, he would get a single > > > invoice > > > for both of them. > > > > > > Any suggestions? > > > > > > Thanks > > > Daniel Reis > > > Open Source Integrators Europe > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe -- Mihai Fekete NextERP Romania S.R.L. 600B, Peciu Nou, Romania E-mail: feketemihai@nexterp.ro Telefon: 0788-749989 Website: https://nexterp.ro id="-x-evo-selection-start-marker">
by Mihai Fekete - 12:21 - 3 Sep 2020 -
Re: Projects - send one invoice per customer
We have used the same one, you can set if the client/customer wants a single or individual invoices. You have to greate the draft invoices first if I recall as we used it on recurring contracts. But it is certainly a good module
Andy
On 03/09/2020 11:07, Florent Cayré wrote:
Hello Daniel,
for this purpose (but with invoices generated by multiple contracts), we use https://github.com/OCA/account-invoicing/tree/10.0/account_invoice_merge (also ported to 12.0 although I haven't tried it yet).
Le 03/09/2020 à 11:27, Daniel Reis a écrit :
Hello Contributors, I have a requirement that, as far as i can see, there are no OCA modules available to help with. We are billing time on projects. Out of the box, Odoo is capable of generating one invoices for each project. I would like to be able to send out invoices by customer. So if a customer has two active projects, he would get a single invoice for both of them. Any suggestions? Thanks Daniel Reis Open Source Integrators Europe
_______________________________________________
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
by Andy Dyson - 12:11 - 3 Sep 2020 -
Re: Projects - send one invoice per customer
Hello Daniel,
for this purpose (but with invoices generated by multiple contracts), we use https://github.com/OCA/account-invoicing/tree/10.0/account_invoice_merge (also ported to 12.0 although I haven't tried it yet).
Le 03/09/2020 à 11:27, Daniel Reis a écrit :
Hello Contributors, I have a requirement that, as far as i can see, there are no OCA modules available to help with. We are billing time on projects. Out of the box, Odoo is capable of generating one invoices for each project. I would like to be able to send out invoices by customer. So if a customer has two active projects, he would get a single invoice for both of them. Any suggestions? Thanks Daniel Reis Open Source Integrators Europe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Florent Cayré - 12:06 - 3 Sep 2020 -
Projects - send one invoice per customer
Hello Contributors, I have a requirement that, as far as i can see, there are no OCA modules available to help with. We are billing time on projects. Out of the box, Odoo is capable of generating one invoices for each project. I would like to be able to send out invoices by customer. So if a customer has two active projects, he would get a single invoice for both of them. Any suggestions? Thanks Daniel Reis Open Source Integrators Europe
by Daniel Reis - 11:26 - 3 Sep 2020 -
OCA Virtual Booth at Odoo Experience - please help
Hello OCA Contributors,
Thank you again to the people who have reached out and said they can help over the OCA Days 2020 Online in regards to hosting etc. I'm working towards getting a bit of a timetable together for this as we have more talks confirmed. We can still take more so if this interests you please get in touch.
What we do need before this is help at the OCA Virtual Booth at the Odoo Experience. Like we normally ask at the physical event we need people to help being on the stand.The virtual booth is open both days of Odoo Experience:Rebecca- Wednesday Sept 30th - 4 pm to 10 pm (CEST)
- Thursday Oct 1st - 3:30 pm to 10 pm (CEST)
Even just an hour of your time would be amazing. We will need a few people to be online at once to help out and create the sense of community.I've set up a roster here, if you could please fill in your name, email address and company that would be great.Alternatively, you can reply on this list or to events AT odoo-community.org
Also, if you haven't sent in your talk proposal for OCA Days yet, just a reminder you have till the 15th of September to get this through.
Thanking you in advance.
Warm regards,--Rebecca GellatlyGeneral SecretaryOdoo Community Association
by Rebecca Gellatly - 03:50 - 3 Sep 2020 -
Re: problem building runbot
Oh I actually had this error on a normal build. Not being a technical wiz or caring about 20 secons of extra buold time I just added python-ldap to my apt dependencies to get the needed things Then it installed fine, including the pyldap.On Wed, 2 Sep 2020, 4:47 am Stéphane Bidoul, <stephane.bidoul@acsone.eu> wrote:This setuptools bug seems relevant: https://github.com/pypa/setuptools/issues/2357We can try if this workaround fixes the problem: https://github.com/OCA/maintainer-quality-tools/pull/675On Tue, Sep 1, 2020 at 5:37 PM Rémi CAZENAVE - Le Filament <remi@le-filament.com> wrote:Dear contributors,
I am not sure if this is related but I am struggling for a few hours with an issue related to setuptools version 50.0.0 since they are overriding stdlib (https://setuptools.readthedocs.io/en/latest/history.html) and they recommend to not use deprecated distutils anymore (https://setuptools.readthedocs.io/en/latest/distutils-legacy.html).
distutils.version are still in use in ir_action_reports.py (https://github.com/odoo/odoo/blob/master/odoo/addons/base/models/ir_actions_report.py) causing my latest Docker Odoo not to start.
So far I have been able to revert to setuptools installed by Debian Stretch (33.1.1), however I am not sure this is the best way (setuptools in latest version being installed when running pip install requirements.txt, because required by pyldap and reportlab).
Let me know if some of you encounter a similar issue ?
Thank you,
Best Regards,
Rémi CAZENAVE
------
SCOP LE FILAMENT
06.87.23.26.04
remi@le-filament.comLe 01/09/2020 à 17:02, Mario Riva a écrit :
Dear Alexandre,
The crash happens when trying build the module pyldap == 2.4.28 which is a dependency of core Odoo 12.0. I'm puzzled, but I can't help much more than this today.
Thanks for your help!
Mario_______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 09:51 - 2 Sep 2020 -
Re: problem building runbot
This setuptools bug seems relevant: https://github.com/pypa/setuptools/issues/2357We can try if this workaround fixes the problem: https://github.com/OCA/maintainer-quality-tools/pull/675On Tue, Sep 1, 2020 at 5:37 PM Rémi CAZENAVE - Le Filament <remi@le-filament.com> wrote:Dear contributors,
I am not sure if this is related but I am struggling for a few hours with an issue related to setuptools version 50.0.0 since they are overriding stdlib (https://setuptools.readthedocs.io/en/latest/history.html) and they recommend to not use deprecated distutils anymore (https://setuptools.readthedocs.io/en/latest/distutils-legacy.html).
distutils.version are still in use in ir_action_reports.py (https://github.com/odoo/odoo/blob/master/odoo/addons/base/models/ir_actions_report.py) causing my latest Docker Odoo not to start.
So far I have been able to revert to setuptools installed by Debian Stretch (33.1.1), however I am not sure this is the best way (setuptools in latest version being installed when running pip install requirements.txt, because required by pyldap and reportlab).
Let me know if some of you encounter a similar issue ?
Thank you,
Best Regards,
Rémi CAZENAVE
------
SCOP LE FILAMENT
06.87.23.26.04
remi@le-filament.comLe 01/09/2020 à 17:02, Mario Riva a écrit :
Dear Alexandre,
The crash happens when trying build the module pyldap == 2.4.28 which is a dependency of core Odoo 12.0. I'm puzzled, but I can't help much more than this today.
Thanks for your help!
Mario_______________________________________________
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
by Stéphane Bidoul - 06:45 - 1 Sep 2020 -
Re: problem building runbot
Dear contributors,
I am not sure if this is related but I am struggling for a few hours with an issue related to setuptools version 50.0.0 since they are overriding stdlib (https://setuptools.readthedocs.io/en/latest/history.html) and they recommend to not use deprecated distutils anymore (https://setuptools.readthedocs.io/en/latest/distutils-legacy.html).
distutils.version are still in use in ir_action_reports.py (https://github.com/odoo/odoo/blob/master/odoo/addons/base/models/ir_actions_report.py) causing my latest Docker Odoo not to start.
So far I have been able to revert to setuptools installed by Debian Stretch (33.1.1), however I am not sure this is the best way (setuptools in latest version being installed when running pip install requirements.txt, because required by pyldap and reportlab).
Let me know if some of you encounter a similar issue ?
Thank you,
Best Regards,
Rémi CAZENAVE
------
SCOP LE FILAMENT
06.87.23.26.04
remi@le-filament.comLe 01/09/2020 à 17:02, Mario Riva a écrit :
Dear Alexandre,
The crash happens when trying build the module pyldap == 2.4.28 which is a dependency of core Odoo 12.0. I'm puzzled, but I can't help much more than this today.
Thanks for your help!
Mario_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Rémi Cazenave - 05:36 - 1 Sep 2020 -
Re: problem building runbot
Dear Alexandre,
The crash happens when trying build the module pyldap == 2.4.28 which is a dependency of core Odoo 12.0. I'm puzzled, but I can't help much more than this today.Thanks for your help!Mario
by Mario Riva - 05:01 - 1 Sep 2020 -
Re: problem building runbot
Hello, The logs are there, but they show the compilation of the docker image failed https://runbot1-2.odoo-community.org/runbot/static/build/3437578-1852-d4f5d8/logs/job_10_test_base.txt The crash happens when trying build the module pyldap == 2.4.28 which is a dependency of core Odoo 12.0. I'm puzzled, but I can't help much more than this today. Alexandre On 01/09/2020 16:26, Mario Riva wrote: > Hi everyone, > > I'm having some problems with a build ( > https://runbot.odoo-community.org/runbot/build/3437578 ) that failed in > the last 2 days. > Logs give me "404 not found" page. > > What should I do? > > Thanks, > Mario > > > -- > > Mario Riva > > takobi.online | Facebook > | Linkedin > | Youtube > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > -- Alexandre Fayolle Chef de Projet Tel : +33 4 58 48 20 30 Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
by Alexandre Fayolle - 04:51 - 1 Sep 2020 -
Re: problem building runbot
I'm giving this a look. On 01/09/2020 16:26, Mario Riva wrote: > Hi everyone, > > I'm having some problems with a build ( > https://runbot.odoo-community.org/runbot/build/3437578 ) that failed in > the last 2 days. > Logs give me "404 not found" page. > > What should I do? > > Thanks, > Mario > > > -- > > Mario Riva > > takobi.online | Facebook > | Linkedin > | Youtube > > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > -- Alexandre Fayolle Chef de Projet Tel : +33 4 58 48 20 30 Camptocamp France SAS 18 rue du Lac Saint André 73 370 Le Bourget-du-Lac France http://www.camptocamp.com
by Alexandre Fayolle - 04:36 - 1 Sep 2020 -
problem building runbot
Hi everyone,I'm having some problems with a build ( https://runbot.odoo-community.org/runbot/build/3437578 ) that failed in the last 2 days.Logs give me "404 not found" page.What should I do?Thanks,Mario
by Mario Riva - 04:25 - 1 Sep 2020 -
Re: Robust renaming in code
I "forbid" (not real forbidding, but persuasion) to do this in my customers, as the maintenance cost for such a whim doesn't worth it IMO. They adapt to current nomenclature easily when you involve serious (but real) costs about that.Anyway, if you still want do it, it depends on what to rename:- Fields: override `string` attribute of the field.- Menus: XML with the original XML-ID, but for translations, you need to add a i18n_extra folder.- Hardcoded string in reports: XML inheritance, replacing contents (which is also very bad for compatibility, but reduced if using a lower priority - 9999 or so-).Regards.
by Pedro M. Baeza - 11:41 - 31 Aug 2020 -
Re: Best model for selling unique products (used machines)
I would like to add these thoughts to the discussion:An individual product stored in a warehouse(stock.location) should be treated individually using Serial Number traceability(stock.production.lot) like has been discussed here in this thread...But an individual product that it's not in a good condition due to its use or it have been pulled of from the Warehouse to start it's useful life should be treated like an Asset(asset.asset) with a depreciation model and their own features to individually differentiate it from the generic products that keep their New or Good Condition State inside the Warehouse. For example all the used machinery, cars, buildings or Assets in general have individual values of measures like years of usage, year of the release, KMs or Miles traveled... that change from Unit to Unit affecting also the price of the Asset due to the sum of all the depreciations or valuations that applySo you should be using asset.asset too in combination with product.product and stock.production.lotHope this helpOn Wed, Aug 26, 2020 at 4:06 PM Frederik Kramer <frederik.kramer@initos.com> wrote:
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Axel Mendoza - 12:06 - 27 Aug 2020 -
Re: Best model for selling unique products (used machines)
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
by Frederik Kramer - 11:06 - 26 Aug 2020 -
Re: Best model for selling unique products (used machines)
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
by Graeme Gellatly - 10:41 - 26 Aug 2020
