IRC logs of #tryton for Thursday, 2011-10-13

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/!