chat.freenode.net #tryton log beginning Thu Oct 13 00:00:02 CEST 2011 | ||
2011-10-13 00:26 <cedk> looks like nobody has not yet started to translate http://hg.tryton.org/trytond/rev/e1026997a2dd | ||
2011-10-13 06:59 <marcosdmyr> hi | ||
2011-10-13 07:00 <marcosdmyr> has tryton a way to handle variants for products ¿? | ||
2011-10-13 07:01 <plantian> there is a some internal functionality that is not really exposted, but it does not allow pricing for different variants as far as i know | ||
2011-10-13 07:02 <plantian> marcosdmyr: more people might have better info in a few hours, it is a not as active time right now | ||
2011-10-13 07:03 <plantian> marcosdmyr: I started on a prototype but it can be rather complicated to handle variants. Do you need the price to be set per variant ? And different inventory per variant? | ||
2011-10-13 07:03 <marcosdmyr> great, pricing for different variants is just what i was looking for... | ||
2011-10-13 07:05 <plantian> marcosdmyr: Are you a developer or just want to use Tryton ? | ||
2011-10-13 07:08 <marcosdmyr> i want to use tryton. i think i could develop, but im not developing at the moment... | ||
2011-10-13 07:08 <plantian> oh yeah, I guess I just meant are you a programmer | ||
2011-10-13 07:09 <marcosdmyr> yep | ||
2011-10-13 07:10 <plantian> I guess when I said prototype that probably should have been "rough idea", here is what I was thinking for the model: https://bitbucket.org/ianjosephwilson/product_family/src/40e9a82754d4/family.py | ||
2011-10-13 07:10 <marcosdmyr> im looking for an erp. i was trying openerp a few days ago. now is tryton turn... | ||
2011-10-13 07:14 <plantian> marcosdmyr: oh cool, did try connecting to the demo ? | ||
2011-10-13 07:14 <marcosdmyr> yes | ||
2011-10-13 07:23 <marcosdmyr> plantian: i should get my server to try your class... | ||
2011-10-13 07:28 <marcosdmyr> i am too late with my implementation. i have to decide about the erp in the next days... | ||
2011-10-13 07:35 <plantian> marcosdmyr: yeah that is pretty short notice for a very big commitment, maybe you should try implementing a module yourself on both erps in addition to checking out the demos | ||
2011-10-13 07:35 <plantian> marcosdmyr: my code is not even a prototype really yet, it will take a while for such an idea to be useful to the end user because a wizard and gui must be made and i'm not sure if this way of making variants with be maintainable | ||
2011-10-13 07:36 <marcosdmyr> ok plantian | ||
2011-10-13 07:36 <marcosdmyr> thanks | ||
2011-10-13 07:37 <marcosdmyr> maybe i will ask again in some hours... | ||
2011-10-13 07:37 <plantian> marcosdmyr: feel free to ask me more questiosn whenever i'm online and more people from Europe will be coming online in the next few hours | ||
2011-10-13 07:37 <plantian> yeah sounds good | ||
2011-10-13 07:38 <marcosdmyr> really thanks plantian | ||
2011-10-13 07:41 <marcosdmyr> where are you from plantian ¿? | ||
2011-10-13 07:41 <plantian> marcosdmyr: California, USA | ||
2011-10-13 07:41 <plantian> you? | ||
2011-10-13 07:42 <marcosdmyr> Bahía Blanca, Buenos Aires, Argentina | ||
2011-10-13 07:48 <plantian> cool | ||
2011-10-13 07:49 <marcosdmyr> plantian: do you know argentina ¿? | ||
2011-10-13 07:53 <plantian> marcosdmyr: I know it is in South America but not a lot of specifics. | ||
2011-10-13 07:54 <marcosdmyr> you are right ¡! :P | ||
2011-10-13 08:00 <hoRn> plantian: hi - looks good - started a similar module, but yours looks better | ||
2011-10-13 08:01 <plantian> hoRn: I was thinking you would create a family with attributes, then you would click on a Create Variants button to start a wziard. Then then would create a list of computed values in the spreadsheet type widget. You could then add or remove variant products and customize them. When finished you would click Create Products to create the products that would remain linked back to the family. | ||
2011-10-13 08:03 <hoRn> plantian: yes - we have such a model in our shopsoftware. but for tryton I though more in reuse of the design of product.product and product.product | ||
2011-10-13 08:04 <plantian> hoRn: You mean product.template and product.product ? | ||
2011-10-13 08:04 <hoRn> plation: yes | ||
2011-10-13 08:05 <plantian> hoRn: But it does not have pricing per variant, and all the modifiers would have to be added to all products. | ||
2011-10-13 08:05 <hoRn> plantian: thats whi I like your solution | ||
2011-10-13 08:06 <hoRn> plantian: looks more flexible | ||
2011-10-13 08:06 <plantian> Oh yeah, right, ha great. I had considered something to update the variants but I'm not sure if it is better to just remove them all and start a new family if you need to add or remove attributes. | ||
2011-10-13 08:07 <plantian> Like two paths for the wizard: create variants for freshly created product family and update variants for product family with existing products connected to it | ||
2011-10-13 08:08 <marcosdmyr> update variants is a good idea... | ||
2011-10-13 08:08 <plantian> marcosdmyr: Yeah does it come up though ? | ||
2011-10-13 08:09 <plantian> I guess adding an option to an existing attribute is much more likely which fit in there too. | ||
2011-10-13 08:09 <plantian> *fits | ||
2011-10-13 08:10 <hoRn> plantian marcosdmyr: I can contribute something, because I need a solution for a client who sells clothes - he needs variants | ||
2011-10-13 08:10 <hoRn> marcosdmyr: welcome to tryton - have friends in BA | ||
2011-10-13 08:10 <marcosdmyr> great hoRn ¡! | ||
2011-10-13 08:11 <hoRn> marcosdmyr: the client I'm talking about is a bunch of argentinians ;) | ||
2011-10-13 08:11 <marcosdmyr> where are you hoRn ¿? | ||
2011-10-13 08:13 <hoRn> marcosdmyr: germany - but I kow them since I lived in spain years ago - now thsi are friends and clients | ||
2011-10-13 08:13 <marcosdmyr> i think i can contribute. but i will need some days to see more things about tryton... | ||
2011-10-13 08:14 <hoRn> marcosdmyr: river or boca - that's is the question for a cooperation :-D | ||
2011-10-13 08:15 <marcosdmyr> ja ja ja | ||
2011-10-13 08:16 <hoRn> marcosdmyr: Leipzig, Germany | ||
2011-10-13 08:16 <hoRn> marcosdmyr: oops - wrong chat | ||
2011-10-13 08:17 <marcosdmyr> olimpo from bahia blanca and san lorenzco | ||
2011-10-13 08:17 <marcosdmyr> *san lorenzo | ||
2011-10-13 08:18 <hoRn> plantian: why you think you need to remove the attributes and create a new family when you want to update? | ||
2011-10-13 08:19 <plantian> hoRn: The wizard logic becomes very ambiguous. | ||
2011-10-13 08:20 <plantian> Do existing variant product fields get replaced? Do you show both fields with a checkbox to replace? | ||
2011-10-13 08:24 <hoRn> plantian: one moment - I saw your model first time. Neeed to read it again ... | ||
2011-10-13 08:25 <plantian> This problem isn't obvious because I haven't uploaded the wizard because it is conceptually unfinished. | ||
2011-10-13 08:31 <hoRn> plantian: some low level questions: don't understand list_price_modifier and cost_price_modifier - why this isn't a absolute value, that replace the prices of the template? | ||
2011-10-13 08:34 <plantian> hoRn: Base price is 15.00 but attribute option might add 5.00 or might be 1.5% or something. | ||
2011-10-13 08:35 <plantian> hoRn: I think maybe there would be a strategy that could be selected: replace, add, multiply | ||
2011-10-13 08:36 <marcosdmyr> why the idea of a base price ¿? i think many times it is not practical... | ||
2011-10-13 08:36 <hoRn> plantian: yes - because our experience is, that computed values of price-variants don't fit the reality | ||
2011-10-13 08:37 <hoRn> plantian: the price is always xx.90 - for marketing reasons | ||
2011-10-13 08:38 <plantian> hoRn: well maybe formula would be better, I don't know, maybe its premature flexibility | ||
2011-10-13 08:39 <plantian> It does not really make sense then to have any prices really because if there are 2 attributes then replacement doesn't make sense. For example Color and Size. | ||
2011-10-13 08:40 <plantian> These are used to compute initial price but then user customizes this before creating product where the list price is REALLY set. | ||
2011-10-13 08:40 <hoRn> plantian: yes - now I understand better. | ||
2011-10-13 08:41 <marcosdmyr> i missed :P | ||
2011-10-13 08:44 <plantian> marcosdmyr: base price is modified by each attribute option, like base price for shirt + size modifier for small + color modifier for red = draft price of this variant which will be reviewed by user before creating product with actual price | ||
2011-10-13 08:46 <plantian> It seems like this problem has been solved about a billion times though, maybe there is some good information about it. | ||
2011-10-13 08:46 <plantian> Although business practices information on the internet seemed terrible when I was reading about MRP. | ||
2011-10-13 08:46 <plantian> I really only need the model myself to store my products. | ||
2011-10-13 08:49 <hoRn> plantian: yes - MRP does not fit all usecases | ||
2011-10-13 08:49 <plantian> every business has different terms and many times they were conflicting | ||
2011-10-13 08:50 <marcosdmyr> i understand that, and i saw this way in openerp. at that time i thought the same. maybe it does not seem a good way for me becouse ni my case, there is no interest in discriminating a base and the price per attribute... | ||
2011-10-13 08:50 <marcosdmyr> maybe this is a natural way when the company is producing products | ||
2011-10-13 08:51 <plantian> marcosdmyr: in that case base could just be price and all options can be zero or whichever | ||
2011-10-13 08:51 <plantian> user would have final say on actual price of each variant | ||
2011-10-13 08:51 <plantian> oh yeah, i don't want to stray the conversation with MRP that was just an exmaple of bad internet information, if this family thing goes near a bom it will be ruined for forever | ||
2011-10-13 08:52 <plantian> marcosdmyr: you said each variant has different price though right? | ||
2011-10-13 08:52 <marcosdmyr> plantian: yes | ||
2011-10-13 08:52 <plantian> i guess you mean there is no real pattern though | ||
2011-10-13 08:52 <hoRn> plantian marcosdmyr: of what kind of products we are talking about? in my case clothes. there are a lot of variants of the product himself but less pricing variants | ||
2011-10-13 08:54 <hoRn> finally different prices are the exception | ||
2011-10-13 08:54 <marcosdmyr> hoRn: if we talk for example about clothes, do you really need to have a base price and prices per attributes ¿? | ||
2011-10-13 08:54 <hoRn> marcosdmyr: no - this is the exception | ||
2011-10-13 08:55 <plantian> i have plants, like the green leafy kind, with different sizes and different levels of rooted-ness(which aren't salable but are for inventory tracking) | ||
2011-10-13 08:55 <hoRn> plantian: so you have diffrent prices for sure | ||
2011-10-13 08:57 <hoRn> plantian: but your model is good for that - its posible to leave the pricemodifier unchanged | ||
2011-10-13 09:00 <plantian> hoRn: i think i would just set price on each size and leave base price at 0 | ||
2011-10-13 09:00 <plantian> kind of like what you said, only one attribute would set price, other attribute does not affect it | ||
2011-10-13 09:01 <plantian> i guess really it doesn't matter, they could just be entered everytime | ||
2011-10-13 09:02 <hoRn> plantian: the only I'm thinking when I reading your code: the family looks very similar to product.template - why not extend this - what are the counterargument? | ||
2011-10-13 09:04 <hoRn> plantian: for sure you decided this with reason ... | ||
2011-10-13 09:05 <marcosdmyr> what about discriminating produced products and products from another partner ¿? it would be really a headache :P | ||
2011-10-13 09:05 <plantian> hoRn: it just pollutes products with a lot of things which are not physical products at all and as more products are extended their object properties have to mesh with the family object properties as well when family doesn't need all the extra attributes | ||
2011-10-13 09:06 <hoRn> plantian: ok | ||
2011-10-13 09:06 <plantian> in order to have priced variants you would also have to add list price to product.product | ||
2011-10-13 09:07 <plantian> i'm not sure the original design decision of product.template, maybe cedk or bech would have some more insight | ||
2011-10-13 09:11 <hoRn> plantian: yes - I thought for things we are talking about - but I think right now each product generates a new template. so the use of template isn't really taht, what is suggested by name | ||
2011-10-13 09:12 <plantian> yeah right, i think it didn't quite work out as planned, i'm not sure if it would be possible to track things such as inventory either by product.product | ||
2011-10-13 09:13 <plantian> actually that looks okay | ||
2011-10-13 09:13 <plantian> these type of things quickly go over my head because erp is complicated | ||
2011-10-13 09:14 <hoRn> plantian: yes | ||
2011-10-13 09:14 <hoRn> plantian: for me as well | ||
2011-10-13 09:23 <marcosdmyr> plantian, hoRn : i have to sleep | ||
2011-10-13 09:23 <marcosdmyr> really thanks to you | ||
2011-10-13 09:25 <plantian> marcosdmyr: no problem, talk to you later this week maybe | ||
2011-10-13 09:25 <hoRn> marcosdmyr: buenas noches | ||
2011-10-13 18:11 -!- ciupicri(~ciupicri@unaffiliated/ciupicri) has joined #tryton | ||
2011-10-13 19:11 <sisalp> http://www.eguens.com/v2/comptabilite/cours/tva-intracommunautaire.php | ||
2011-10-13 19:15 <cedk> sisalp: why is it 19.6% | ||
2011-10-13 19:16 <sisalp> sorry I should have posted it in the private area since this is only about our current discussion | ||
2011-10-13 22:09 <sisalp> http://mister.compta.free.fr/Syntheses/Le%20coin%20des%20BAC/La%20comptabilisation%20des%20factures%20d%27achat%20intracommunautaire.pdf | ||
2011-10-13 22:12 <cedk> sisalp: it seems to confirm what we talked about | ||
2011-10-13 22:15 <cedk> sisalp: I have updated the account_be also because I think I did not understand correctly the intracom rules | ||
2011-10-13 22:16 <cedk> sisalp: also I think we said that we don't implement "immobilisation" | ||
2011-10-13 22:27 <cedk> sisalp: we just need to tax code now |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!