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

chat.freenode.net #tryton log beginning Thu Oct 13 00:00:02 CEST 2011
cedklooks like nobody has not yet started to translate http://hg.tryton.org/trytond/rev/e1026997a2dd00:26
marcosdmyrhi06:59
marcosdmyrhas tryton a way to handle variants for products ¿?07:00
plantianthere is a some internal functionality that is not really exposted, but it does not allow pricing for different variants as far as i know07:01
plantianmarcosdmyr: more people might have better info in a few hours, it is a not as active time right now07:02
plantianmarcosdmyr: 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?07:03
marcosdmyrgreat, pricing for different variants is just what i was looking for...07:03
plantianmarcosdmyr: Are you a developer or just want to use Tryton ?07:05
marcosdmyri want to use tryton. i think i could develop, but im not developing at the moment...07:08
plantianoh yeah, I guess I just meant are you a programmer07:08
marcosdmyryep07:09
plantianI 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.py07:10
marcosdmyrim looking for an erp. i was trying openerp a few days ago. now is tryton turn...07:10
plantianmarcosdmyr: oh cool, did try connecting to the demo ?07:14
marcosdmyryes07:14
marcosdmyrplantian: i should get my server to try your class...07:23
marcosdmyri am too late with my implementation. i have to decide about the erp in the next days...07:28
plantianmarcosdmyr: 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 demos07:35
plantianmarcosdmyr: 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 maintainable07:35
marcosdmyrok plantian07:36
marcosdmyrthanks07:36
marcosdmyrmaybe i will ask again in some hours...07:37
plantianmarcosdmyr: feel free to ask me more questiosn whenever i'm online and more people from Europe will be coming online in the next few hours07:37
plantianyeah sounds good07:37
marcosdmyrreally thanks plantian07:38
marcosdmyrwhere are you from plantian ¿?07:41
plantianmarcosdmyr: California, USA07:41
plantianyou?07:41
marcosdmyrBahía Blanca, Buenos Aires, Argentina07:42
plantiancool07:48
marcosdmyrplantian: do you know argentina ¿?07:49
plantianmarcosdmyr: I know it is in South America but not a lot of specifics.07:53
marcosdmyryou are right ¡! :P07:54
hoRnplantian: hi - looks good - started a similar module, but yours looks better08:00
plantianhoRn: 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.08:01
hoRnplantian: 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.product08:03
plantianhoRn: You mean product.template and product.product ?08:04
hoRnplation: yes08:04
plantianhoRn: But it does not have pricing per variant, and all the modifiers would have to be added to all products.08:05
hoRnplantian: thats whi I like your solution08:05
hoRnplantian: looks more flexible08:06
plantianOh 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.08:06
plantianLike two paths for the wizard: create variants for freshly created product family and update variants for product family with existing products connected to it08:07
marcosdmyrupdate variants is a good idea...08:08
plantianmarcosdmyr: Yeah does it come up though ?08:08
plantianI guess adding an option to an existing attribute is much more likely which fit in there too.08:09
plantian*fits08:09
hoRnplantian marcosdmyr: I can contribute something, because I need a solution for a client who sells clothes - he needs variants08:10
hoRnmarcosdmyr: welcome to tryton - have friends in BA08:10
marcosdmyrgreat hoRn ¡!08:10
hoRnmarcosdmyr: the client I'm talking about is a bunch of argentinians ;)08:11
marcosdmyrwhere are you hoRn ¿?08:11
hoRnmarcosdmyr: germany - but I kow them since I lived in spain years ago - now thsi are friends and clients08:13
marcosdmyri think i can contribute. but i will need some days to see more things about tryton...08:13
hoRnmarcosdmyr: river or boca - that's is the question for a cooperation :-D08:14
marcosdmyrja ja ja08:15
hoRnmarcosdmyr: Leipzig, Germany08:16
hoRnmarcosdmyr: oops - wrong chat08:16
marcosdmyrolimpo from bahia blanca and san lorenzco08:17
marcosdmyr*san lorenzo08:17
hoRnplantian: why you think you need to remove the attributes and create a new family when you want to update?08:18
plantianhoRn: The wizard logic becomes very ambiguous.08:19
plantianDo existing variant product fields get replaced?  Do you show both fields with a checkbox to replace?08:20
hoRnplantian: one moment - I saw your model first time. Neeed to read it again ...08:24
plantianThis problem isn't obvious because I haven't uploaded the wizard because it is conceptually unfinished.08:25
hoRnplantian: 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?08:31
plantianhoRn: Base price is 15.00 but attribute option might add 5.00 or might be 1.5% or something.08:34
plantianhoRn: I think maybe there would be a strategy that could be selected: replace, add, multiply08:35
marcosdmyrwhy the idea of a base price ¿? i think many times it is not practical...08:36
hoRnplantian: yes - because our experience is, that computed values of price-variants don't fit the reality08:36
hoRnplantian: the price is always xx.90 - for marketing reasons08:37
plantianhoRn: well maybe formula would be better, I don't know, maybe its premature flexibility08:38
plantianIt 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.08:39
plantianThese are used to compute initial price but then user customizes this before creating product where the list price is REALLY set.08:40
hoRnplantian: yes - now I understand better.08:40
marcosdmyri missed :P08:41
plantianmarcosdmyr: 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 price08:44
plantianIt seems like this problem has been solved about a billion times though, maybe there is some good information about it.08:46
plantianAlthough business practices information on the internet seemed terrible when I was reading about MRP.08:46
plantianI really only need the model myself to store my products.08:46
hoRnplantian: yes - MRP does not fit all usecases08:49
plantianevery business has different terms and many times they were conflicting08:49
marcosdmyri 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...08:50
marcosdmyrmaybe this is a natural way when the company is producing products08:50
plantianmarcosdmyr: in that case base could just be price and all options can be zero or whichever08:51
plantianuser would have final say on actual price of each variant08:51
plantianoh 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 forever08:51
plantianmarcosdmyr: you said each variant has different price though right?08:52
marcosdmyrplantian: yes08:52
plantiani guess you mean there is no real pattern though08:52
hoRnplantian 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 variants08:52
hoRnfinally different prices are the exception08:54
marcosdmyrhoRn: if we talk for example about clothes, do you really need to have a base price and prices per attributes ¿?08:54
hoRnmarcosdmyr: no - this is the exception08:54
plantiani 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)08:55
hoRnplantian: so you have diffrent prices for sure08:55
hoRnplantian: but your model is good for that - its posible to leave the pricemodifier unchanged08:57
plantian hoRn: i think i would just set price on each size and leave base price at 009:00
plantiankind of like what you said, only one attribute would set price, other attribute does not affect it09:00
plantiani guess really it doesn't matter, they could just be entered everytime09:01
hoRnplantian: 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?09:02
hoRnplantian: for sure you decided this with reason ...09:04
marcosdmyrwhat about discriminating produced products and products from another partner ¿? it would be really a headache :P09:05
plantianhoRn: 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 attributes09:05
hoRnplantian: ok09:06
plantianin order to have priced variants you would also have to add list price to product.product09:06
plantiani'm not sure the original design decision of product.template, maybe cedk or bech would have some more insight09:07
hoRnplantian: 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 name09:11
plantianyeah 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.product09:12
plantianactually that looks okay09:13
plantianthese type of things quickly go over my head because erp is complicated09:13
hoRnplantian: yes09:14
hoRnplantian: for me as well09:14
marcosdmyrplantian, hoRn : i have to sleep09:23
marcosdmyrreally thanks to you09:23
plantianmarcosdmyr: no problem, talk to you later this week maybe09:25
hoRnmarcosdmyr: buenas noches09:25
-!- ciupicri(~ciupicri@unaffiliated/ciupicri) has joined #tryton18:11
sisalphttp://www.eguens.com/v2/comptabilite/cours/tva-intracommunautaire.php19:11
cedksisalp: why is it 19.6%19:15
sisalpsorry I should have posted it in the private area since this is only about our current discussion19:16
sisalphttp://mister.compta.free.fr/Syntheses/Le%20coin%20des%20BAC/La%20comptabilisation%20des%20factures%20d%27achat%20intracommunautaire.pdf22:09
cedksisalp: it seems to confirm what we talked about22:12
cedksisalp: I have updated the account_be also because I think I did not understand correctly the intracom rules22:15
cedksisalp: also I think we said that we don't implement "immobilisation"22:16
cedksisalp: we just need to tax code now22:27

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!