Archives
Contributors
-
Re: how to create the POS image to install on posbox??
AndreasHi Robert,The official way would be the script here:
https://github.com/odoo/odoo/tree/13.0/addons/point_of_sale/tools/posboxThe official documentation for this i think doesn't help much in building it.regards,Hi there Is there a way, script, documentation on how to create the raspberry iso image to be burnt on the sd-card of the pos box? thanks robert
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Andreas Perhab - 03:41 - 26 Aug 2020 -
Re: Best module combination for maintenance of sold equipment
Hi, you can check out the OCA fieldservice modules. It's very extensive, much more than the enterprise version and does have a module for the connection between maintenance equipment and customer locations. You can also add inventory and labor to fieldservice orders and invoice them.On Wed, 26 Aug 2020, 6:57 am Radovan Skolnik, <radovan@skolnik.info> wrote:Hello, we are a company that designs, sells, installs and maintains professional kitchen equipment (big cooking machines, ovens, washing machines, ...) for hotels, restaurants, canteens, ... We are currently in process of deploying Odoo and I am struggling a bit with the maintenance part of the scenario. The most common scenario is we do the design, purchase the equipment from manufacturer, sell it to customer and do provide in-warranty and out-of-warranty on-demand maintenance. Sometimes we also have an agreement for periodic preventive maintenance. So far we have been experimenting with Field Service Management (Enterprise version) as a way to track and plan the on-demand maintenance. This however has no notion of customer's equipment that would somehow be linked to sold products. On the other hand it has support for creating offers/inoices for spare parts/work/... I have been checking Maintenance module that has support for on-demand and cyclical maintenance and also allows for definition of equipment and locations. But that one is meant for "internal" equipment and locations (not customer's) and also it is not linked in any way with sold products. No support (AFAICT) for offers/invoices. To make things even more complicated we sometimes support equipment that we didn't sell or sold in the past (before Odoo) so there is no record of that in our system and we need to put it there. We want/need to track the record of maintenance task done in the past. Now in the process of deploying the solution I became a bit of Odoo developer so I can develop some simpler modules and I also did some migrations of OCA modules. So I could develop some integration of needed. What would be your suggestion for this scenario? I guess this is not so non-standard thing. Any help/suggestion is welcome. Best regards Radovan Skolnik
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Patrick Wilson - 03:35 - 26 Aug 2020 -
Best module combination for maintenance of sold equipment
Hello, we are a company that designs, sells, installs and maintains professional kitchen equipment (big cooking machines, ovens, washing machines, ...) for hotels, restaurants, canteens, ... We are currently in process of deploying Odoo and I am struggling a bit with the maintenance part of the scenario. The most common scenario is we do the design, purchase the equipment from manufacturer, sell it to customer and do provide in-warranty and out-of-warranty on-demand maintenance. Sometimes we also have an agreement for periodic preventive maintenance. So far we have been experimenting with Field Service Management (Enterprise version) as a way to track and plan the on-demand maintenance. This however has no notion of customer's equipment that would somehow be linked to sold products. On the other hand it has support for creating offers/inoices for spare parts/work/... I have been checking Maintenance module that has support for on-demand and cyclical maintenance and also allows for definition of equipment and locations. But that one is meant for "internal" equipment and locations (not customer's) and also it is not linked in any way with sold products. No support (AFAICT) for offers/invoices. To make things even more complicated we sometimes support equipment that we didn't sell or sold in the past (before Odoo) so there is no record of that in our system and we need to put it there. We want/need to track the record of maintenance task done in the past. Now in the process of deploying the solution I became a bit of Odoo developer so I can develop some simpler modules and I also did some migrations of OCA modules. So I could develop some integration of needed. What would be your suggestion for this scenario? I guess this is not so non-standard thing. Any help/suggestion is welcome. Best regards Radovan Skolnik
by Radovan Skolnik - 02:56 - 26 Aug 2020 -
Re: Best model for selling unique products (used machines)
Dear all,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. As Graeme said, the lots are the good place to extend modelization for one product instance.As David said, product_attribute can be useful if you want to add fields easily to products, but you need to keep in mind that this is only for fields that are not implied in business flows. They should be used only for informative purposes.My two centsOn Wed, Aug 26, 2020 at 4:12 AM Yoshi Tashiro <tashiro@quartile.co> wrote:Just remembered one major reason we took the approach of customizing product.template was because each item had to be published on eCommerce. I imagine it'd take a lot of effort to make it work with eCommerce if you use stock.production.lot. The approach of attribute_set looks interesting.--Yoshi TashiroOn Wed, Aug 26, 2020 at 7:01 AM Graeme Gellatly <gdgellatly@gmail.com> wrote:Actually, I remembered list price of product used in pricing is a functional field anyway, so it is just updating that function. Using lots, you could probably do the whole requirement in less than 200 lines of customisation, maybe a lot less.On Wed, Aug 26, 2020 at 9:55 AM Graeme Gellatly <gdgellatly@gmail.com> wrote:Hi,We've had this requirement for years, except to make matters worse 95% of them also need to be manufactured and each item is also made up of multiple unique items. And in general they all have unique prices. So need to deal with BoM's, Manufacturing etc as well.Its not too hard using production lots. In fact it would suck not using them I think. Things like doing a stocktake (which unique item is it) would be impossible otherwise, warehouse pickings, changing an order and the item maintenance also.For this requirement I would almost definitely use production lots, because then it is real simple. OCA Modules already exist to put the lot on the SO Line. e.g. https://github.com/OCA/sale-workflow/tree/13.0/sale_order_lot_selectionYour statement that lots are about traceability after stock operations is somewhat only partly correct. Of course the usual way is through a receipt or manufacturing operation, but I doubt you are taking sale orders for items that you 1. Don't know the condition of, 2. Don't have. But if so, then it is easy anyway, you can just create one. In any case, it is at the point where you know the condition of the itme that you create the lot.You then just need to add effectively a List Price field to lots and update the pricing rules of product.pricelist to use this price if lot is set.Anything else is just noise, you could add fields to lots like product attributes values if you chose, a text field for description, update the SO document to print extended info from that.Easy.On Wed, Aug 26, 2020 at 8:07 AM Radovan Skolnik <radovan@skolnik.info> wrote: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
_______________________________________________
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
--__________________________________________
Denis Roussel
Software Engineer
Acsone SA, Succursale de Liège (Val Benoît)
Tel : +32 2 888 31 49
Fax : +32 2 888 31 59
Gsm : +32 472 22 00 57Acsone sa/nv
Boulevard de la Woluwe 56 Woluwedal | B-1200 Brussels | BelgiumQuai Banning, 6 (Val Benoît) | B-4000 Liège | Belgium
Zone Industrielle 22 | L-8287 Kehlen | Luxembourg
by Denis Roussel - 09:51 - 26 Aug 2020 -
Management of chatter with channels
Hi Community, In V11CE, I’m wondering how community members manage changes to the followers on particular objects over extended periods of time. In my organisation, we have a considerable number of objects (Projects, Tasks, Opportunities) that run for long periods of time (some several years) with team members coming and going, and consequently, changes to the lists of followers for each object being required. Currently that’s a time consuming task of going through each of these objects, removing and adding followers as I go. I understand that channels can be added to the list of followers, and that members can be added/removed to the channel, but the problem with that is that messages sent via the channels don’t land in the channel members inboxes (the place where they’re most likely to see messages). Instead, they need to proactively go to the channel and look for new messages. Is there some module or alternative way to get channel messages ‘mirrored’ to the inboxes of channel members, or is there some other way that the community is managing this scenario? We currently handle all of our internal communication in Odoo, rather than via email, but that could be changed if there was good reason. I’m also interested to know if management of chatter has improved in later versions? Thanks in advance, Bill Ennals Operations Co-ordinator Reverse Garbage Qld Co-op Ltd.
by bill - 06:06 - 26 Aug 2020 -
Re: Best model for selling unique products (used machines)
Just remembered one major reason we took the approach of customizing product.template was because each item had to be published on eCommerce. I imagine it'd take a lot of effort to make it work with eCommerce if you use stock.production.lot. The approach of attribute_set looks interesting.--Yoshi TashiroOn Wed, Aug 26, 2020 at 7:01 AM Graeme Gellatly <gdgellatly@gmail.com> wrote:Actually, I remembered list price of product used in pricing is a functional field anyway, so it is just updating that function. Using lots, you could probably do the whole requirement in less than 200 lines of customisation, maybe a lot less.On Wed, Aug 26, 2020 at 9:55 AM Graeme Gellatly <gdgellatly@gmail.com> wrote:Hi,We've had this requirement for years, except to make matters worse 95% of them also need to be manufactured and each item is also made up of multiple unique items. And in general they all have unique prices. So need to deal with BoM's, Manufacturing etc as well.Its not too hard using production lots. In fact it would suck not using them I think. Things like doing a stocktake (which unique item is it) would be impossible otherwise, warehouse pickings, changing an order and the item maintenance also.For this requirement I would almost definitely use production lots, because then it is real simple. OCA Modules already exist to put the lot on the SO Line. e.g. https://github.com/OCA/sale-workflow/tree/13.0/sale_order_lot_selectionYour statement that lots are about traceability after stock operations is somewhat only partly correct. Of course the usual way is through a receipt or manufacturing operation, but I doubt you are taking sale orders for items that you 1. Don't know the condition of, 2. Don't have. But if so, then it is easy anyway, you can just create one. In any case, it is at the point where you know the condition of the itme that you create the lot.You then just need to add effectively a List Price field to lots and update the pricing rules of product.pricelist to use this price if lot is set.Anything else is just noise, you could add fields to lots like product attributes values if you chose, a text field for description, update the SO document to print extended info from that.Easy.On Wed, Aug 26, 2020 at 8:07 AM Radovan Skolnik <radovan@skolnik.info> wrote: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
_______________________________________________
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 Yoshi Tashiro. - 04:10 - 26 Aug 2020 -
Re: Best model for selling unique products (used machines)
Actually, I remembered list price of product used in pricing is a functional field anyway, so it is just updating that function. Using lots, you could probably do the whole requirement in less than 200 lines of customisation, maybe a lot less.On Wed, Aug 26, 2020 at 9:55 AM Graeme Gellatly <gdgellatly@gmail.com> wrote:Hi,We've had this requirement for years, except to make matters worse 95% of them also need to be manufactured and each item is also made up of multiple unique items. And in general they all have unique prices. So need to deal with BoM's, Manufacturing etc as well.Its not too hard using production lots. In fact it would suck not using them I think. Things like doing a stocktake (which unique item is it) would be impossible otherwise, warehouse pickings, changing an order and the item maintenance also.For this requirement I would almost definitely use production lots, because then it is real simple. OCA Modules already exist to put the lot on the SO Line. e.g. https://github.com/OCA/sale-workflow/tree/13.0/sale_order_lot_selectionYour statement that lots are about traceability after stock operations is somewhat only partly correct. Of course the usual way is through a receipt or manufacturing operation, but I doubt you are taking sale orders for items that you 1. Don't know the condition of, 2. Don't have. But if so, then it is easy anyway, you can just create one. In any case, it is at the point where you know the condition of the itme that you create the lot.You then just need to add effectively a List Price field to lots and update the pricing rules of product.pricelist to use this price if lot is set.Anything else is just noise, you could add fields to lots like product attributes values if you chose, a text field for description, update the SO document to print extended info from that.Easy.On Wed, Aug 26, 2020 at 8:07 AM Radovan Skolnik <radovan@skolnik.info> wrote: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
_______________________________________________
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 - 12:00 - 26 Aug 2020 -
Re: Best model for selling unique products (used machines)
Hi,We've had this requirement for years, except to make matters worse 95% of them also need to be manufactured and each item is also made up of multiple unique items. And in general they all have unique prices. So need to deal with BoM's, Manufacturing etc as well.Its not too hard using production lots. In fact it would suck not using them I think. Things like doing a stocktake (which unique item is it) would be impossible otherwise, warehouse pickings, changing an order and the item maintenance also.For this requirement I would almost definitely use production lots, because then it is real simple. OCA Modules already exist to put the lot on the SO Line. e.g. https://github.com/OCA/sale-workflow/tree/13.0/sale_order_lot_selectionYour statement that lots are about traceability after stock operations is somewhat only partly correct. Of course the usual way is through a receipt or manufacturing operation, but I doubt you are taking sale orders for items that you 1. Don't know the condition of, 2. Don't have. But if so, then it is easy anyway, you can just create one. In any case, it is at the point where you know the condition of the itme that you create the lot.You then just need to add effectively a List Price field to lots and update the pricing rules of product.pricelist to use this price if lot is set.Anything else is just noise, you could add fields to lots like product attributes values if you chose, a text field for description, update the SO document to print extended info from that.Easy.On Wed, Aug 26, 2020 at 8:07 AM Radovan Skolnik <radovan@skolnik.info> wrote:
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
_______________________________________________
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 - 11:56 - 25 Aug 2020 -
Re: Best model for selling unique products (used machines)
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
by Radovan Skolnik - 10:06 - 25 Aug 2020 -
Re: [24490] Re: Odoo POS and Technische Sicherheitseinrichtung (TSE)
Thanks Thorsten and FrederikProbably in the short term the Epson is a good approach. Frederik, do you have more information on the Fiskaly integration? Seems like a good approach too.Regards,JordiEl mar., 25 ago. 2020 10:47, Frederik Kramer <frederik.kramer@initos.com> escribió:Hi Jordi, yes that's a big issue in Germany. We are working on an odoo implementation already. There are mostly hardware implementations of TSEs (such as the Epson one Thorsten mentioned) and Software ones like Fiskaly which we are working on. Most probably we will soon realize a python SDK together with Fiskaly that can be used to interact with the Fiskaly Cloud TSE. This in turn will be then used in an appropriate Odoo Module. So before doing something yourself feel free to ping me (and of course everybody else that is interested in the topic and has customers in Germany) and we can see how you can join the effort in the most efficient way Cheers Frederik Am Dienstag, den 25.08.2020, 06:12 +0000 schrieb Jordi Ballester Alomar: > Dear OCA contributors, > > Have you heard of the german new regulation for POS called > "Technische Sicherheitseinrichtung" (TSE)? > > There's an old thread about this in this mailing list > https://odoo-community.org/groups/germany-18/germany-151053. > > > Regards, > -- > Jordi Ballester Alomar > CEO & Founder | ForgeFlow > (+34) 629530707 | jordi.ballester@forgeflow.com | > https://www.forgeflow.com > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > https://www.linkedin.com/in/jordiballesteralomar > _______________________________________________ > 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 Jordi Ballester Alomar - 08:36 - 25 Aug 2020 -
Re: Best model for selling unique products (used machines)
Hi Peter,Again, I think you should give a try to https://github.com/shopinvader/odoo-pim and product_attribute_setto 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.ConsultantOdoo Intégration / DéveloppementLe 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
by David BEAL - 05:09 - 25 Aug 2020 -
[24490] Re: Odoo POS and Technische Sicherheitseinrichtung (TSE)
Hi Jordi, yes that's a big issue in Germany. We are working on an odoo implementation already. There are mostly hardware implementations of TSEs (such as the Epson one Thorsten mentioned) and Software ones like Fiskaly which we are working on. Most probably we will soon realize a python SDK together with Fiskaly that can be used to interact with the Fiskaly Cloud TSE. This in turn will be then used in an appropriate Odoo Module. So before doing something yourself feel free to ping me (and of course everybody else that is interested in the topic and has customers in Germany) and we can see how you can join the effort in the most efficient way Cheers Frederik Am Dienstag, den 25.08.2020, 06:12 +0000 schrieb Jordi Ballester Alomar: > Dear OCA contributors, > > Have you heard of the german new regulation for POS called > "Technische Sicherheitseinrichtung" (TSE)? > > There's an old thread about this in this mailing list > https://odoo-community.org/groups/germany-18/germany-151053. > > > Regards, > -- > Jordi Ballester Alomar > CEO & Founder | ForgeFlow > (+34) 629530707 | jordi.ballester@forgeflow.com | > https://www.forgeflow.com > Twitter: https://twitter.com/jordibforgeflow | Linkedin: > https://www.linkedin.com/in/jordiballesteralomar > _______________________________________________ > 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 - 10:45 - 25 Aug 2020 -
Re: Odoo POS and Technische Sicherheitseinrichtung (TSE)
Hello Jordi,in the meantime there are some EPSON POS printers available, capable to fulfill your mentioned requirements, for example the TM-m30F.For some prior existing EPSON POS printers there are upgrade kits available.As far as i know there is at the moment no software solution (Odoo module).Best regardsThorsten Vocks
openBIG.org
Dipl. Kaufmann (FH)
Porscheweg 4-6
49661 Cloppenburg
Phone: +49 4471 8409000
Fax: +49 4471 84090009
Mail: thorsten.vocks@openbig.org
Am Di., 25. Aug. 2020 um 08:12 Uhr schrieb Jordi Ballester Alomar <jordi.ballester@forgeflow.com>:Dear OCA contributors,Have you heard of the german new regulation for POS called "Technische Sicherheitseinrichtung" (TSE)?There's an old thread about this in this mailing list https://odoo-community.org/groups/germany-18/germany-151053.Regards,--Jordi Ballester AlomarCEO & Founder | ForgeFlow(+34) 629530707 | jordi.ballester@forgeflow.com | https://www.forgeflow.comTwitter: https://twitter.com/jordibforgeflow | Linkedin: https://www.linkedin.com/in/jordiballesteralomar_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Thorsten Vocks - 10:26 - 25 Aug 2020 -
Odoo POS and Technische Sicherheitseinrichtung (TSE)
Dear OCA contributors,Have you heard of the german new regulation for POS called "Technische Sicherheitseinrichtung" (TSE)?There's an old thread about this in this mailing list https://odoo-community.org/groups/germany-18/germany-151053.Regards,--Jordi Ballester AlomarCEO & Founder | ForgeFlow(+34) 629530707 | jordi.ballester@forgeflow.com | https://www.forgeflow.comTwitter: https://twitter.com/jordibforgeflow | Linkedin: https://www.linkedin.com/in/jordiballesteralomar
by Jordi Ballester Alomar - 08:11 - 25 Aug 2020 -
Re: Best model for selling unique products (used machines)
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--Yoshi TashiroOn Mon, Aug 24, 2020 at 11:12 PM Frederik Kramer <frederik.kramer@initos.com> 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: > 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 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 > Einfach. Digital. Wachsen. > -- Odoo Ready Partner -- Website > Kontakt > Impressum > Datenschutz > > > > © 2019 dygytally.de > 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 > > [1] > > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > > [2] > > > > > and in pending migration > > > > > https://github.com/OCA/sale-workflow/pull/1144 [3] > > > > > Note that sale_order_lot_selection in v12 and v13 are different, > > consider the v12 one > > > > > Best regards > > > > > > > > > > David BEAL - akretion.com [4] Consultant > > > > > Odoo Intégration / Développement > > > > > Le ven. 21 août 2020 à 15:36, Peter Hahn < peter.hahn@initos.com > > [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 > > [6] > > > > > Post to: mailto: contributors@odoo-community.org [7] > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [8] > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mailing-List: https://odoo-community.org/groups/contributors-15 > > [9] > > > > > Post to: mailto:contributors@odoo-community.org > > > > > Unsubscribe: https://odoo-community.org/groups?unsubscribe [10] > > > > > > > > > > > > > > > > > > > > [1] > > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_selection > > > > > [2] > > https://github.com/OCA/sale-workflow/tree/12.0/sale_order_lot_generator > > > > > [3] https://github.com/OCA/sale-workflow/pull/1144 > > > > > [4] http://akretion.com > > > > > [5] mailto:peter.hahn@initos.com > > > > > [6] https://odoo-community.org/groups/contributors-15 > > > > > [7] mailto:contributors@odoo-community.org > > > > > [8] https://odoo-community.org/groups?unsubscribe > > > > > [9] https://odoo-community.org/groups/contributors-15 > > > > > [10] 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 -- 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 Yoshi Tashiro. - 05:01 - 24 Aug 2020