| chat.freenode.net #tryton log beginning Tue Jan 26 00:00:02 CET 2010 | ||
| 2010-01-26 00:00 <udono> vengfulsquirrel: Having a question to your concept on http://code.google.com/p/tryton/wiki/TrytonMRPIntegration | ||
| 2010-01-26 00:00 <vengfulsquirrel> udono: ? | ||
| 2010-01-26 00:00 <udono> vengfulsquirrel: do you have an idea for disassemble an produced product into its parts? | ||
| 2010-01-26 00:01 <vengfulsquirrel> udono: You mean from an inventory perspective to take a product off the shelf and re-stock it as products for each part? | ||
| 2010-01-26 00:02 <udono> vengfulsquirrel: yes, but ... | ||
| 2010-01-26 00:04 <cedk> sharoon: do you see our comments about the naming? | ||
| 2010-01-26 00:04 <sharoon> is it abt camel case? | ||
| 2010-01-26 00:04 <cedk> sharoon: we think that it should be named sale.opportunity | ||
| 2010-01-26 00:04 <sharoon> oops | ||
| 2010-01-26 00:04 <sharoon> i dint see that comment | ||
| 2010-01-26 00:04 <cedk> sharoon: we think that crm is all concept like erp | ||
| 2010-01-26 00:05 <cedk> sharoon: and so it should not be used as name | ||
| 2010-01-26 00:05 <sharoon> cedk: where was the comment? are there any further additions? | ||
| 2010-01-26 00:05 <sharoon> cedk: agree | ||
| 2010-01-26 00:05 <sharoon> cedk: and should the menu classification change/? | ||
| 2010-01-26 00:05 <udono> vengfulsquirrel: I talked last week to an interest. He told me he is producing products made of a BOM, which are stored. When producing other products, sometimes he takes equipment out of one (exsting and produced) product. Then he use this disassembled part in another product. | ||
| 2010-01-26 00:05 <cedk> sharoon: I said that history functionnality could fully be used | ||
| 2010-01-26 00:06 <cedk> sharoon: classification ? | ||
| 2010-01-26 00:06 <sharoon> cedk: which is why i decided to forget the extra table we thought of having to maintain history | ||
| 2010-01-26 00:06 <sharoon> cedk: the menu now says CRM | ||
| 2010-01-26 00:06 <sharoon> should we hold that or get this Opportunity to Sales? | ||
| 2010-01-26 00:06 <cedk> sharoon: i think you could put into sale | ||
| 2010-01-26 00:07 <sharoon> cedk: that sounds uniform | ||
| 2010-01-26 00:07 <cedk> sharoon: some comments about coding: | ||
| 2010-01-26 00:07 <sharoon> cedk: please, all welcome | ||
| 2010-01-26 00:08 <cedk> space after comma | ||
| 2010-01-26 00:08 <cedk> party_id -> party | ||
| 2010-01-26 00:08 <cedk> we never use _id | ||
| 2010-01-26 00:08 <cedk> it has a better look with browserecords | ||
| 2010-01-26 00:08 <sharoon> got you | ||
| 2010-01-26 00:08 <sharoon> does it append id in the table like django? | ||
| 2010-01-26 00:09 <cedk> sharoon: no | ||
| 2010-01-26 00:09 <cedk> sharoon: I don't know if it is good to have the active domain on party | ||
| 2010-01-26 00:10 <sharoon> cedk: we thought of having active and inactive partners in leads, but only active in the sale etc. but its erring out anyway | ||
| 2010-01-26 00:10 <cedk> sharoon: is the field stage could be named state? We often use state fields | ||
| 2010-01-26 00:10 <vengfulsquirrel> udono: Well I think subassemblies are represented. Does disassembling a product destroy it from inventory? Or do you mean to sort of use the production process in reverse by selecting a bom to disassemble a product to? | ||
| 2010-01-26 00:10 <sharoon> cedk: though it lists the partner it doesnt save at the end | ||
| 2010-01-26 00:10 <sharoon> cedk: agree on stage -> state | ||
| 2010-01-26 00:11 <cedk> sharoon: for selection fields you can put sort=False and remove numbering | ||
| 2010-01-26 00:12 <sharoon> cedk: ok | ||
| 2010-01-26 00:12 <cedk> sharoon: I think probabilty shoud be an float field | ||
| 2010-01-26 00:12 <cedk> sharoon: we could make operation on it | ||
| 2010-01-26 00:12 <cedk> what is change_history ? | ||
| 2010-01-26 00:12 <sharoon> cedk: anyhow we dont allow arbitary values to be entered since its selection? | ||
| 2010-01-26 00:13 <sharoon> cedk: i was told that the history in orm doesnt generate a view | ||
| 2010-01-26 00:13 <cedk> sharoon: you can create a ModelSQL that use a SQL query or even custom it | ||
| 2010-01-26 00:14 <cedk> sharoon: like for the cost price historisation | ||
| 2010-01-26 00:14 <bechamel> udono: isn't it enough to concider the final product as an input that is splitted into several output by a production order ? | ||
| 2010-01-26 00:14 <vengfulsquirrel> udono: If a bom exists for a product that specifies the part then it can be used to produce that product(assuming the part is in inventory), ie. instead of all the materials that were used to create that part. | ||
| 2010-01-26 00:14 <sharoon> cedk: can you point me to an examle | ||
| 2010-01-26 00:14 <sharoon> cedk: ok | ||
| 2010-01-26 00:15 <cedk> sharoon: http://hg.tryton.org/hgwebdir.cgi/modules/product_cost_history/file/06618c2835b3/product.py#l8 | ||
| 2010-01-26 00:15 <sharoon> looking at it :-) | ||
| 2010-01-26 00:15 <cedk> sharoon: for probability, it must be a number between 0 and 100 | ||
| 2010-01-26 00:15 <sharoon> so convert selection to blank float field? | ||
| 2010-01-26 00:16 <cedk> sharoon: I think it will be more powerful than a char field | ||
| 2010-01-26 00:16 <sharoon> agree, but is it possible to limit values or do we use constrain? | ||
| 2010-01-26 00:16 <bechamel> cedk: why ? imo it's easier to select a percentage on a selection | ||
| 2010-01-26 00:16 <cedk> sharoon: because we could later make query like this sum(amount * probability) | ||
| 2010-01-26 00:17 <sharoon> we could also do sum(amount * int(probability)) with current case? | ||
| 2010-01-26 00:17 <cedk> bechamel: you are a mathematician ? | ||
| 2010-01-26 00:17 <cedk> sharoon: I mean in SQL | ||
| 2010-01-26 00:17 <sharoon> k | ||
| 2010-01-26 00:18 <cedk> sharoon: and it suppose that nobody (module) will extend the selection and append a non-mumeric key | ||
| 2010-01-26 00:18 <sharoon> cedk got u | ||
| 2010-01-26 00:19 <cedk> sharoon: I think end_date would be useful | ||
| 2010-01-26 00:19 <bechamel> cedk: yes but before all a lazy user that don't want to leave is mouse using my clicky GUI | ||
| 2010-01-26 00:19 <cedk> sharoon: and perhaps a cancel/lost description | ||
| 2010-01-26 00:20 <sharoon> cedk: end_date filled auto when state in cancel/lost/converted? | ||
| 2010-01-26 00:20 <cedk> bechamel: I think we learn that stay as close as possible to the real type of concept is better | ||
| 2010-01-26 00:20 <cedk> sharoon: yes | ||
| 2010-01-26 00:20 <cedk> sharoon: perhaps with workflow | ||
| 2010-01-26 00:20 <sharoon> got u | ||
| 2010-01-26 00:21 <sharoon> so make field state readonl? | ||
| 2010-01-26 00:21 <cedk> sharoon: always readonly no? | ||
| 2010-01-26 00:21 <sharoon> cedk: yes | ||
| 2010-01-26 00:22 <cedk> sharoon: also double empty line before class | ||
| 2010-01-26 00:22 <sharoon> cedk: ok | ||
| 2010-01-26 00:22 <sharoon> cedk: is there any doc somewhere abt historisation? | ||
| 2010-01-26 00:23 <cedk> sharoon: and for lines, try to use the same string for the fields than his name | ||
| 2010-01-26 00:23 <sharoon> cedk: unclear | ||
| 2010-01-26 00:24 <cedk> sharoon: no doc, it just need to add _history = True to the Model | ||
| 2010-01-26 00:24 <sharoon> cedk: cool | ||
| 2010-01-26 00:24 <sharoon> will look how it works and get back | ||
| 2010-01-26 00:24 <cedk> sharoon: you used as string "Items" for field "lines" | ||
| 2010-01-26 00:24 <sharoon> so finally what abt the probability? selection or Float? | ||
| 2010-01-26 00:24 <cedk> http://hg.tryton.org/hgwebdir.cgi/modules/product_cost_history/file/06618c2835b3/ir.py | ||
| 2010-01-26 00:25 <sharoon> cedk: got you abt lines | ||
| 2010-01-26 00:25 <cedk> sharoon: I'm for a float or integer | ||
| 2010-01-26 00:25 <sharoon> lets stick to int then and validate by a constrain that its between 0 & 100 | ||
| 2010-01-26 00:27 <cedk> sharoon: ok | ||
| 2010-01-26 00:36 <udono> bechamel: I told the interest the same. Just explode the produced product into its parts, and move them into their Standard locations or anywhere, but | ||
| 2010-01-26 00:36 <udono> bechamel: for him it is far from reality. He uses alredy produced products as a kind of stock for other products | ||
| 2010-01-26 00:37 <cedk> udono: so no need to explode anything | ||
| 2010-01-26 00:38 <bechamel> cedk: for integer in the db vs selection in the view, nothing prevent us to do both | ||
| 2010-01-26 00:39 <udono> vengfulsquirrel: if disassembling a product destroy it from inventory I don't know. For me it sounds like using a part from a produced product A and produce product B of it. Product A becomes unproduced and waiting for (end) Production. | ||
| 2010-01-26 00:41 <cedk> udono: of course there is no more product A but a product C | ||
| 2010-01-26 00:42 <udono> cedk: yes, but what happens to the rest of product A? Where are all the parts going to? | ||
| 2010-01-26 00:42 <udono> cedk: vengfulsquirrel: on the other hand, a produced product can be seen as a location with products inside... | ||
| 2010-01-26 00:43 <cedk> udono: the rest of product A is some other products C, D ... | ||
| 2010-01-26 00:44 <cedk> udono: but the explode could be done at a specific level of the bom tree | ||
| 2010-01-26 00:44 <cedk> ACTION go to sleep | ||
| 2010-01-26 00:44 <udono> cedk: dd the rest of product A fall into ts pieces (partial products)? | ||
| 2010-01-26 00:44 <cedk> udono: it must it is no more product A | ||
| 2010-01-26 00:45 <udono> cedk: ok | ||
| 2010-01-26 00:52 <udono> Maybe disassemble of Product A can be done with a wizard. There can be choosen: | ||
| 2010-01-26 00:52 <udono> 1. all part-products of Product A should be stored in their default locations | ||
| 2010-01-26 00:52 <udono> 2. storing all part-products in a new location. The new location can be default named like Product A (disassembled) | ||
| 2010-01-26 00:55 <udono> after this, Product A does no longer exist as Product, but now exist as stock location with the rest of the part-products inside. | ||
| 2010-01-26 00:58 <udono> vengfulsquirrel: what do you think about? | ||
| 2010-01-26 01:01 <vengfulsquirrel> udono: Sorry, had to make food. *Reading* | ||
| 2010-01-26 01:05 <vengfulsquirrel> udono: I think that is abusing stock locations, I think you would just disassemble in parts(other products) and then they could be moved into their default locations. If you need them in production again you would have to assign them from those locations, wherever they might be. I don't think a relationship between the product that they were disassembled from is necessary. A wizard for the disassembly of the product into parts( | ||
| 2010-01-26 01:11 <udono> vengfulsquirrel: your last post ended with " product into parts(" is it right? | ||
| 2010-01-26 01:13 <vengfulsquirrel> uduno: * A wizard for the disassembly of the product into parts(other products) and shipment of the parts into storage seems like it would make sense to me. | ||
| 2010-01-26 01:13 <vengfulsquirrel> Sorry, I can never tell when IRC is going to trim it. | ||
| 2010-01-26 01:14 <udono> vengfulsquirrel: Where do you see stock location abusing, when creating a new ocation on demand for the disassembled stuff? | ||
| 2010-01-26 01:14 <udono> /ocation/location/ | ||
| 2010-01-26 01:15 <vengfulsquirrel> Yes, because then someone would have to delete it eventually, and its not clear exactly "where" that location is. | ||
| 2010-01-26 01:16 <vengfulsquirrel> udono: I don't know, maybe I misunderstood what you meant. | ||
| 2010-01-26 01:16 <udono> vengfulsquirrel: It could be a new location type, which must be inside a storage location. | ||
| 2010-01-26 01:17 <vengfulsquirrel> udono: I guess I don't understand its purpose, why not just put the parts back into storage where they physically end up? | ||
| 2010-01-26 01:18 <vengfulsquirrel> udono: Maybe a more general and permanent area for disassembly would be more appropriate. | ||
| 2010-01-26 01:23 <udono> vengfulsquirrel: The purpose is to produce products for the stock. And quickly produce new products out of the stock and out of parts of another product. When using parts of another product this product disappears (disassembled into parts). This parts can be stored in their default locations _or_ all together in an other (or new) location. | ||
| 2010-01-26 01:24 -!- saxa_(n=sasa@host242-95-static.223-217-b.business.telecomitalia.it) has joined #tryton | ||
| 2010-01-26 01:24 -!- bechamel(n=user@host-85-201-159-186.brutele.be) has joined #tryton | ||
| 2010-01-26 01:26 <udono> vengfulsquirrel: I doesn't mean it make sense to be a generic functionality of disassembling a product... For me it is an specfic addon to the generc disassemble-and-put-parts-into-default-location functionality. | ||
| 2010-01-26 01:26 <vengfulsquirrel> uduno: That seems like the specific need of a certain user but not the general case. Maybe if dissembling was very expensive and the parts were very large. Like say a car junkyard. Although if you disassembled a computer you would most likely place the parts back into their respective bins. | ||
| 2010-01-26 01:27 <vengfulsquirrel> Yes, okay, that's fine. So maybe the developer would extend the dissassemble wizard and generate a new location for certain product types instead of performing the default action which would be returning the parts to their default locations. | ||
| 2010-01-26 01:27 <udono> vengfulsquirrel: yes, car yunkyard is a good example | ||
| 2010-01-26 01:28 <udono> vengfulsquirrel: should I add the disassembly to the MRP concept in the wik? | ||
| 2010-01-26 01:29 <vengfulsquirrel> Yes, I have no idea when this will all be implemented though. Maybe 2020 AD ? | ||
| 2010-01-26 01:30 <vengfulsquirrel> I can add it. | ||
| 2010-01-26 01:30 <udono> vengfulsquirrel: we will see | ||
| 2010-01-26 01:30 <udono> I hope for 2010 :-) | ||
| 2010-01-26 01:32 <vengfulsquirrel> Such a feature does seem simpler to implement than many of the other features. | ||
| 2010-01-26 01:33 <vengfulsquirrel> udono: Actually the user could be allowed to customize the default locations for re-stocking which would provide an opportunity for the user to create a new custom location and replace all the default locations. | ||
| 2010-01-26 01:34 <vengfulsquirrel> udono: For example we could just pre-fill the locations in the lines of the internal shipment or whatever and then the use could customize it and finalize it. | ||
| 2010-01-26 01:35 <vengfulsquirrel> That seems like a better general use case and it would be very easy to extend it to just pre-fill with a new location everytime for certain product types. | ||
| 2010-01-26 01:38 <udono> vengfulsquirrel: yes. We need on BOM level a flag can_diassemled which indicates, that parts in this BOM can or can not be disassembled. | ||
| 2010-01-26 01:41 <vengfulsquirrel> Hmm good point, is that really necessary? | ||
| 2010-01-26 01:41 <vengfulsquirrel> I mean did someone mention they needed that ? | ||
| 2010-01-26 01:41 <udono> vengfulsquirrel: some parts are soldered together. They will never be unsolderd. Components like | ||
| 2010-01-26 01:43 <vengfulsquirrel> Well any bom might allow users to scrap portions of a product and extract other portions, and in that case many of the parts would be "shipped" into a virtual Garbage location for means of tracking. | ||
| 2010-01-26 01:44 <vengfulsquirrel> I guess it might not hurt to have it though, it just might be limiting if it was set and wasn't need for some sort of definitive purpose. I don't see how it would really hurt the implementation too much though and the admin could always go back and set it to True if it was really needed. | ||
| 2010-01-26 01:47 <vengfulsquirrel> Do the website commits show up in tryton-commit as well? | ||
| 2010-01-26 01:47 <udono> yes, Iam talking about tzhe request of an interest. He produce components and put them together to produce an other product. On disassemble the product, he wanted to have the only components and not all the part-products of the components. Because the components stays to be a produced product. | ||
| 2010-01-26 01:49 <vengfulsquirrel> You mean sub-assemblies ? | ||
| 2010-01-26 01:49 <vengfulsquirrel> '''only components and not all the part-products of the components''' | ||
| 2010-01-26 01:49 <udono> yes | ||
| 2010-01-26 01:50 <udono> subassemblies and produced products made of other produced products in storage | ||
| 2010-01-26 01:51 <vengfulsquirrel> Yes, that could most likely be customized by either picking a different BOM(since many BOMs can exist for 1 product) or by somehow pruning the BOM with the wizard somehow. | ||
| 2010-01-26 01:52 <udono> is subassembly the same as a product produced of other products or is it the same as a 'component'? | ||
| 2010-01-26 01:52 <vengfulsquirrel> udono: Since a bom is really just many single level boms connected into a tree, your client would want to stop at bom higher in the tree rather than disassembling the product entirely into the leaves of the tree. | ||
| 2010-01-26 01:53 <udono> vengfulsquirrel: yes, got it | ||
| 2010-01-26 01:53 <vengfulsquirrel> I guess I didn't mention that in notes, will try that now. | ||
| 2010-01-26 01:54 <udono> vengfulsquirrel: what try now? | ||
| 2010-01-26 01:54 <udono> ah, the wiki? | ||
| 2010-01-26 01:56 <vengfulsquirrel> Oh right I meant I will update the wiki. | ||
| 2010-01-26 01:57 <udono> vengfulsquirrel: and going back to your idea with the internal shipment, we can put a field default location on disassembly wizard, which rules the lines of disassembled parts in the internal shipment (or whatever). If this field default location is empty, the parts where stored into their special default location (that's the default behavoir). If field default location is given, all parts where stored into this location. This can be | ||
| 2010-01-26 01:58 <udono> If field default location is given, all parts where stored into this location. This can be done in an addon module. | ||
| 2010-01-26 02:00 <vengfulsquirrel> Yeah I find that if a field in on the screen then users want to fill it with something so I think the default should be less obtrusive somehow, maybe the empty field can be added IN the addon. | ||
| 2010-01-26 02:01 <udono> vengfulsquirrel: yes | ||
| 2010-01-26 02:01 <udono> good point | ||
| 2010-01-26 02:01 <vengfulsquirrel> The pruning process must involve selecting a subtree of the multi-level bom tree that will not be followed in the disassembly process thereby resulting in the production of the bom determined quantity of the root of that subtree rather than the products at the leaves of that subtree. | ||
| 2010-01-26 02:01 <vengfulsquirrel> I think my explaination is way too complicated. | ||
| 2010-01-26 02:02 <udono> vengfulsquirrel: yeah, I understand nothng in the last sentence :-) | ||
| 2010-01-26 02:03 <udono> vengfulsquirrel: just kidding, after three times reading it is clear as fresh water | ||
| 2010-01-26 02:05 <udono> vengfulsquirrel: and you are right. The disassemble stops at BOMS with the flag can_disassembled is False, and take the sub-BOM as a complete product. | ||
| 2010-01-26 02:06 <vengfulsquirrel> Oh ha well I kind of simplified it anyways. | ||
| 2010-01-26 02:06 <vengfulsquirrel> This is what I have now: http://code.google.com/p/tryton/wiki/TrytonMRPIntegration?ts=1264467977&updated=TrytonMRPIntegration#Disassembly_of_products | ||
| 2010-01-26 02:09 <vengfulsquirrel> udono: I think functionality to select what not to disassemble beyond the flag will be necessary. Since the flag will be more of a policy and not as much a technicality of the current dis-assembly process. So users cannot disassemble beyond a flagged BOM but also they can select additional products that they don't want to disassemble even if they COULD be disassembled(ie. no flag). | ||
| 2010-01-26 02:11 <udono> vengfulsquirrel: do you have an example? | ||
| 2010-01-26 02:12 <udono> vengfulsquirrel: I do not see the need for this much control | ||
| 2010-01-26 02:15 <vengfulsquirrel> Well a user might sometimes want to disassemble a car and furthermore the car's engine (and other parts) COMPLETELY whereas other times if demand for the engine exists then only disassemble the car to its engine(and other parts). | ||
| 2010-01-26 02:16 <udono> vengfulsquirrel: you are right it could sometimes needed. So it could be another module, which provides the disassembly parts tree and the possibility to choose for each node, if it should be disassemled or not. | ||
| 2010-01-26 02:17 <udono> all nodes could be preferenced with the can_dissassembled flag from the appropriate BOM. | ||
| 2010-01-26 02:17 <vengfulsquirrel> Yes, okay I guess it will depend on the complexity to implement. The base module could just strive to be extensible for that case. | ||
| 2010-01-26 02:18 <udono> vengfulsquirrel: yes. But as far as I understand your concept, there is no limitation in all discussed parts. | ||
| 2010-01-26 02:18 <udono> s/But// | ||
| 2010-01-26 02:19 <vengfulsquirrel> So by default all boms must be disassembled to materials or flagged subassemblies. | ||
| 2010-01-26 02:19 <udono> yes, this I would think | ||
| 2010-01-26 02:20 <vengfulsquirrel> Another feature would be to have an flag that could be overriden in the wizard that marked subassemblies as default to being unable to be disassembled.(sorry the double negatives are confusing) | ||
| 2010-01-26 02:22 <udono> vengfulsquirrel: double negative is positive, so: yes | ||
| 2010-01-26 02:26 <udono> subassemblies are a different concept then products produced of other produced products? | ||
| 2010-01-26 02:26 <vengfulsquirrel> No, I just use that terminology here because it is easier. | ||
| 2010-01-26 02:26 <vengfulsquirrel> Everything was planned to be a product. | ||
| 2010-01-26 02:26 <vengfulsquirrel> So a single level bom points to products which then point to their own boms therefore building the multi-level bom. | ||
| 2010-01-26 02:26 <udono> are subassemblies always phantoms? | ||
| 2010-01-26 02:27 <vengfulsquirrel> This is what I have now -- http://code.google.com/p/tryton/wiki/TrytonMRPIntegration?ts=1264469144&updated=TrytonMRPIntegration#Disassembly_of_products | ||
| 2010-01-26 02:27 <vengfulsquirrel> Oh wait sorry, I think I am wrong about phantoms. | ||
| 2010-01-26 02:30 <vengfulsquirrel> Oh wait, I had intended for phantom boms to also be products. | ||
| 2010-01-26 02:31 <vengfulsquirrel> The use of "phantom" seemed highly abused as the definition for everything when I was researching for this. | ||
| 2010-01-26 02:34 <vengfulsquirrel> udono: I need to go out for a bit though, I will be back soon. | ||
| 2010-01-26 02:34 <udono> vengfulsquirrel: see you | ||
| 2010-01-26 02:43 -!- ikks_(n=ikks@190.158.102.38) has joined #tryton | ||
| 2010-01-26 03:05 <udono> vengfulsquirrel: phantom subassembly I do not understand correctly. | ||
| 2010-01-26 03:06 <vengfulsquirrel> udono: Okay, I am back btw, just went out for a walk. | ||
| 2010-01-26 03:08 <udono> vengfulsquirrel: it seems a product A.1 which is produced on demand without a production order when parent Product A is produced. | ||
| 2010-01-26 03:11 -!- ikks_(n=ikks@190.158.102.38) has joined #tryton | ||
| 2010-01-26 03:14 <udono> Is it a flag like salable or purchasable on product which indicates a phantom product? | ||
| 2010-01-26 03:23 <udono> everytime I use a phantom product, I produce it on demand sounds wrong for me. What to do if a part of a phantom product is not available. It needs to be reordered. On Production time for me it is to late for reordering missing parts. They need to be reordered at the time of assign a sales order. | ||
| 2010-01-26 03:44 <vengfulsquirrel> Sorry I got a phone call. | ||
| 2010-01-26 03:44 <udono> vengfulsquirrel: np | ||
| 2010-01-26 03:47 <vengfulsquirrel> udono: It just means to never actually produce it directly, when a bom references a phantom product then the bom of that product is expanded. Rather than a non-phantom product which generates another production order. | ||
| 2010-01-26 03:48 <vengfulsquirrel> In the case of a phantom product it means that the production line produces the phantom product in the process of producing the final product. Rather than having it be a separate production line. | ||
| 2010-01-26 03:49 <vengfulsquirrel> Therefore one should never really have any phantom products in stock unless a product was disassembled. So its really more of a placeholder to partition a large bom into smaller boms but still have it act like a single bom. | ||
| 2010-01-26 03:52 <udono> vengfulsquirrel: so at sales order assignation time, the parts of a phantom product are treated like other parts of the product? Which means, if parts of a phantom product are missing, then they are reordered at the time the sales order is assigned? | ||
| 2010-01-26 03:53 <udono> vengfulsquirrel: Phantom Products are only for another logical view on products and parts? | ||
| 2010-01-26 04:00 <vengfulsquirrel> udono: Well right when allocating for production if parts of a phantom product are missing, then they are reordered. | ||
| 2010-01-26 04:01 <vengfulsquirrel> This way common phantom products can be shared between boms though. For example if there is a common subassembly process that takes place on two production lines that then produce different final products. | ||
| 2010-01-26 04:01 <vengfulsquirrel> I guess after reading a bunch of definitions for phantoms this implementation is what I came up with. | ||
| 2010-01-26 04:07 <udono> vengfulsquirrel: now I understand, and it sounds good for me. | ||
| 2010-01-26 04:31 <udono> vengfulsquirrel: thanks for your time, see you | ||
| 2010-01-26 04:32 <vengfulsquirrel> udono: Yeah no problem. Talk to you tomorrow. | ||
| 2010-01-26 05:19 -!- yangoon(n=mathiasb@p549F735A.dip.t-dialin.net) has joined #tryton | ||
| 2010-01-26 05:20 -!- ikks_(n=ikks@190.158.102.38) has joined #tryton | ||
| 2010-01-26 06:24 -!- varun_openlabs(n=VARUN@117.197.56.35) has joined #tryton | ||
| 2010-01-26 06:26 -!- varun_openlabs(n=VARUN@117.197.56.35) has left #tryton | ||
| 2010-01-26 07:03 -!- udono(n=udono@dynamic-unidsl-85-197-20-249.westend.de) has joined #tryton | ||
| 2010-01-26 07:39 -!- Timitos(n=timitos@88.217.184.172) has joined #tryton | ||
| 2010-01-26 07:56 -!- bechamel(n=user@host-85-201-159-186.brutele.be) has joined #tryton | ||
| 2010-01-26 08:28 -!- paepke(n=paepke@p4FEB14FD.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-26 09:45 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2010-01-26 09:51 -!- sharoon(n=sharoont@92.26.82.66) has joined #tryton | ||
| 2010-01-26 09:53 <Timitos> cedk: hi | ||
| 2010-01-26 09:53 <Timitos> cedk: i cannot create issues on bugtracker any more | ||
| 2010-01-26 09:53 <Timitos> i am not allowed to create entries ob class 'msg' | ||
| 2010-01-26 09:58 <cedk> Timitos: which kind of issues? | ||
| 2010-01-26 10:00 <Timitos> cedk: i tried to create an issue with priority error and type behavior | ||
| 2010-01-26 10:00 <cedk> Timitos: there is no priority error | ||
| 2010-01-26 10:01 <Timitos> cedk: sorry i only have german names here 'Fehler' | ||
| 2010-01-26 10:02 <cedk> Timitos: try with english browser | ||
| 2010-01-26 10:04 <Timitos> cedk: it is priority 'bug' | ||
| 2010-01-26 10:05 <cedk> Timitos: it doesn't work ? | ||
| 2010-01-26 10:07 <cedk> Timitos: what is the error message in english? | ||
| 2010-01-26 10:07 <Timitos> cedk: You do not have permission to create msg | ||
| 2010-01-26 10:10 <cedk> Timitos: try again | ||
| 2010-01-26 10:10 <Timitos> cedk: still the same | ||
| 2010-01-26 10:13 <cedk> Timitos: again | ||
| 2010-01-26 10:14 <Timitos> cedk: again same problem | ||
| 2010-01-26 10:15 <cedk> Timitos: and now? | ||
| 2010-01-26 10:16 <Timitos> cedk: works now | ||
| 2010-01-26 10:16 <Timitos> thx | ||
| 2010-01-26 10:40 -!- enlightx(n=enlightx@static-217-133-61-144.clienti.tiscali.it) has joined #tryton | ||
| 2010-01-26 11:03 <sharoon> cedk: i built a workflow, I can see it in admin workflow too but doesnt get attached or create an instance when i create a record | ||
| 2010-01-26 11:07 <cedk> sharoon: did you inherit from ModelWorkflow? | ||
| 2010-01-26 11:07 <sharoon> cedk: got you!!! i dint | ||
| 2010-01-26 11:15 <sharoon> cedk: is it possible to use time object in workflow action? or should i use a function and then in function write the date, its for end time | ||
| 2010-01-26 11:15 <sharoon> end date | ||
| 2010-01-26 11:17 <yangoon> cedk would be nice to have direct links to changesets on #tryton-commit as we had before here | ||
| 2010-01-26 11:17 <cedk> sharoon: it is in trytond/workflow/expr.py | ||
| 2010-01-26 11:17 <sharoon> cool | ||
| 2010-01-26 11:17 <cedk> sharoon: and I don't see time | ||
| 2010-01-26 11:18 <sharoon> so just access a method and in method use write with date time | ||
| 2010-01-26 11:18 <sharoon> no problem | ||
| 2010-01-26 11:18 <sharoon> thanks again | ||
| 2010-01-26 11:18 <cedk> yangoon: should be fixed | ||
| 2010-01-26 11:18 <yangoon> cedthx | ||
| 2010-01-26 11:19 <sharoon> cedk: one more question, i think the calendar events and todo should have a related party field | ||
| 2010-01-26 11:19 <sharoon> cedk: what do you say? | ||
| 2010-01-26 11:19 <cedk> sharoon: I think the main issue is to make it works with CalDAV clients | ||
| 2010-01-26 11:20 <sharoon> cedk: so if a new field exists it will create prob with caldav? | ||
| 2010-01-26 11:21 <cedk> sharoon: no, but it will not work well because this information will not be available to caldav users | ||
| 2010-01-26 11:21 <cedk> sharoon: and by the way, it should be parties | ||
| 2010-01-26 11:21 <sharoon> cedk: we can give a warning, or else we have to use many2many? | ||
| 2010-01-26 11:22 <cedk> sharoon: there is the attendees on events and I think we could use it to make links to parties | ||
| 2010-01-26 11:23 <cedk> sharoon: but it works on emails | ||
| 2010-01-26 11:23 <sharoon> cedk: so make a link with active_id in attendees? | ||
| 2010-01-26 11:26 <cedk> sharoon: don't understand | ||
| 2010-01-26 11:27 <sharoon> cedk: i want to show the events & todo as a related item for a prty | ||
| 2010-01-26 11:27 <sharoon> party | ||
| 2010-01-26 11:27 -!- paepke_(n=paepke@p4FEB11D4.dip0.t-ipconnect.de) has joined #tryton | ||
| 2010-01-26 11:27 <cedk> sharoon: yes I understand that | ||
| 2010-01-26 11:27 <cedk> sharoon: I don't understand "make a link with active_id in attendees" | ||
| 2010-01-26 11:28 <cedk> sharoon: I think it possible to make a function field that return events linked to a party by his email addresses | ||
| 2010-01-26 11:28 <sharoon> cedk: got it | ||
| 2010-01-26 11:29 <cedk> sharoon: but we should have options on contact_mechanism to prevent Tryton to send emails about events to the parties | ||
| 2010-01-26 11:38 <sharoon> cedk: you mean like an option to opt out of emails? | ||
| 2010-01-26 11:46 <sharoon> what should be the data type of the value if i want to write directly to a date time field. Eg .self.write(cursor,user,id,{'end_date':???}) | ||
| 2010-01-26 11:50 <sharoon> got it, string | ||
| 2010-01-26 11:56 -!- mourad(n=chatzill@wana-192-245-12-196.wanamaroc.com) has joined #tryton | ||
| 2010-01-26 12:00 <cedk> sharoon: better to use datetime | ||
| 2010-01-26 12:00 <sharoon> an example? | ||
| 2010-01-26 12:00 <cedk> self.write(cursor,user,id,{'end_date': datetime.datetime.today()}) | ||
| 2010-01-26 12:02 <sharoon> thanks | ||
| 2010-01-26 12:13 <cedk> sharoon: and yes an opt out like in calendar_scheduling module | ||
| 2010-01-26 12:13 <sharoon> cedk: checking | ||
| 2010-01-26 12:14 -!- ikks(n=ikks@190.158.102.38) has joined #tryton | ||
| 2010-01-26 12:14 <sharoon> cedk: i couldnt find it, can you point me to that? | ||
| 2010-01-26 12:17 <cedk> sharoon: http://hg.tryton.org/hgwebdir.cgi/modules/calendar_scheduling/file/67bc31c0e396/res.py | ||
| 2010-01-26 12:22 <sharoon> cedk: i just got tryton sync with ical in mac, does it update from ical to tryton? | ||
| 2010-01-26 12:24 <bechamel> sharoon: yes it works both ways | ||
| 2010-01-26 12:24 <sharoon> bechamel: thanks, THATS JUST AWESOME!!!! | ||
| 2010-01-26 12:24 <sharoon> bechamel: but still struggling to get it up in evolution | ||
| 2010-01-26 12:25 <bechamel> sharoon: and cedk made some fix to make it works with the iphone client | ||
| 2010-01-26 12:25 <bechamel> sharoon: yes | ||
| 2010-01-26 12:25 <sharoon> bechamel: it has issue with evolution then? | ||
| 2010-01-26 12:25 <paepke> bechamel, cedk: great work with the calendar stuff! | ||
| 2010-01-26 12:25 <bechamel> sharoon: yes I think | ||
| 2010-01-26 12:27 <bechamel> paepke: thx :), cedk made most of the work, I worked on the todo and scheduling stuffs | ||
| 2010-01-26 12:27 <bechamel> sharoon: https://bugs.tryton.org/roundup/issue1281 | ||
| 2010-01-26 12:59 -!- ikks(n=ikks@190.158.102.38) has joined #tryton | ||
| 2010-01-26 13:31 -!- tekknokrat(n=gthieleb@dslb-088-075-227-116.pools.arcor-ip.net) has joined #tryton | ||
| 2010-01-26 13:45 <sharoon> cedk: bechamel: http://mercurial.intuxication.org/hg/crm | ||
| 2010-01-26 13:47 <sharoon> the module name has to be changed though | ||
| 2010-01-26 13:49 <cedk> sharoon: you should use codereview it is better to comment code | ||
| 2010-01-26 13:49 <sharoon> ok, link please | ||
| 2010-01-26 13:50 <cedk> sharoon: http://codereview.appspot.com/ | ||
| 2010-01-26 13:53 <sharoon> cedk: i am using this for the first time. can you say what i got to do??? i created a new repositry and added the trunk! | ||
| 2010-01-26 13:56 <bechamel> sharoon: the easiest it to create a new repo, put the code from crm in it (hg init + hg addremove)and use the codereview script to updload it | ||
| 2010-01-26 13:57 <sharoon> ok | ||
| 2010-01-26 14:19 <udono> sharoon: the upload tool can be found here: http://codereview.appspot.com/static/upload.py | ||
| 2010-01-26 14:19 <sharoon> udono: i did the upload | ||
| 2010-01-26 14:20 <sharoon> http://codereview.appspot.com/193111/show | ||
| 2010-01-26 14:24 -!- woakas(n=woakas@190.144.69.234) has joined #tryton | ||
| 2010-01-26 15:04 <bechamel> sharoon: nice job, I hope you won't be discouraged by all the comments :) | ||
| 2010-01-26 15:04 <sharoon> bechamel: i believe in code review | ||
| 2010-01-26 15:04 <sharoon> :-) | ||
| 2010-01-26 15:16 <sharoon> cedk: what exactly is depends used for ? | ||
| 2010-01-26 15:19 <cedk> sharoon: it ensure that the fields define in depends are also read by the client when reading the field | ||
| 2010-01-26 15:20 <sharoon> ok | ||
| 2010-01-26 15:20 <cedk> sharoon: like that the evaluation of states will always work | ||
| 2010-01-26 15:22 -!- paepke(n=paepke@p4FEB11D4.dip0.t-ipconnect.de) has left #tryton | ||
| 2010-01-26 15:22 -!- rednul_(n=rednul@host-98-127-54-98.bln-mt.client.bresnan.net) has joined #tryton | ||
| 2010-01-26 15:25 -!- Timitos(n=timitos@88.217.184.172) has left #tryton | ||
| 2010-01-26 15:27 -!- Timitos(n=timitos@88.217.184.172) has joined #tryton | ||
| 2010-01-26 15:39 <bechamel> sharoon: you can reupload the issue with "upload.py -i issue_number" | ||
| 2010-01-26 15:39 <cedk> and --send_mail to inform reviewers | ||
| 2010-01-26 15:57 <sharoon> cedk bechamel thanks | ||
| 2010-01-26 16:10 <sharoon> what is ir.action.act_window.view used for? | ||
| 2010-01-26 16:10 <cedk> sharoon: define the order of view of an act_window | ||
| 2010-01-26 16:11 <sharoon> cedk: ok | ||
| 2010-01-26 16:39 <sharoon> cedk: bechamel: udono: yangoon: The final code has been committed. So is the review done?? | ||
| 2010-01-26 16:43 <yangoon> sharoon: I didn't get any feedback to my question so far | ||
| 2010-01-26 16:44 <sharoon> looks like i dint publish it! | ||
| 2010-01-26 16:45 <udono> sharoon: I have an open question with the use of COALESCE, too | ||
| 2010-01-26 16:45 <sharoon> udono: It think what happens is a double update, one to the original table and | ||
| 2010-01-26 16:45 <sharoon> second to the history table. So all entries of the same parent record | ||
| 2010-01-26 16:45 <sharoon> will have same create date in history table. | ||
| 2010-01-26 16:45 <sharoon> Also, the first update to history table will not have write_id | ||
| 2010-01-26 16:47 <udono> sharoon: so, when there is no write_id, why use coalesce? | ||
| 2010-01-26 16:47 <sharoon> udono: so all the records have the same create_uid | ||
| 2010-01-26 16:48 <sharoon> udono: therefore we use write_id for all records except first | ||
| 2010-01-26 16:48 <udono> sharoon: ok, understand | ||
| 2010-01-26 16:50 <sharoon> cedk: what does We indent with 8cols and not align to { mean? how many tabs/spaces from left or intend from ? | ||
| 2010-01-26 16:57 <yangoon> sharoon: instead of aligning subsequent lines to {, indent them with 8 cols | ||
| 2010-01-26 17:01 <udono> cedk: in http://hg.tryton.org/hgwebdir.cgi/modules/project/rev/301a81fcffd8#l1.26 you do no longer check if self.parent.context exists. Why is it no longer needed? | ||
| 2010-01-26 17:05 <cedk> udono: because context is initialised to {} by default | ||
| 2010-01-26 17:06 <udono> cedk: ok, thanks | ||
| 2010-01-26 17:11 -!- juanfer(n=juanfer@190.144.69.234) has joined #tryton | ||
| 2010-01-26 17:12 <sharoon> cedk: do you normally use space for xml intendation? and not tab? | ||
| 2010-01-26 17:15 <udono> sharoon: we use always space for identation, never tab | ||
| 2010-01-26 17:15 <sharoon> hmm, eclipse doesnt have a tool to convert tab to space in xml | ||
| 2010-01-26 17:15 <sharoon> what about python? | ||
| 2010-01-26 17:23 <udono> cedk: what about states? is it initialised to {}, too? | ||
| 2010-01-26 17:25 <cedk> udono: yes | ||
| 2010-01-26 17:26 <sharoon> cedk: was pyson introduced in the trunk? | ||
| 2010-01-26 17:26 <sharoon> is it not there in 1.4 | ||
| 2010-01-26 17:26 <cedk> sharoon: yes | ||
| 2010-01-26 17:26 <sharoon> cedk: so how do i build a windows installer for the trunk client?? | ||
| 2010-01-26 17:27 <cedk> sharoon: http://code.google.com/p/tryton/wiki/InstallationWindows | ||
| 2010-01-26 17:32 <cedk> sharoon: I think you did not upload all the files for last update in codereview | ||
| 2010-01-26 17:33 <sharoon> cedk: i think it update only changes | ||
| 2010-01-26 17:33 <sharoon> shall i go for a new issue? | ||
| 2010-01-26 17:33 <cedk> sharoon: there is just __tryton__.py and sale_opportunity.py | ||
| 2010-01-26 17:34 <cedk> sharoon: did you add renamed files? | ||
| 2010-01-26 17:34 <sharoon> checking | ||
| 2010-01-26 17:34 <cedk> sharoon: and by the way sale_opportunity.py should be named opportunity.py | ||
| 2010-01-26 17:42 <udono> cedk: do you thing the following transformation to pyson is ok? http://paste.pocoo.org/show/170287/ | ||
| 2010-01-26 17:44 <bechamel> sharoon: I think it's because you made a commit, the upload.py script only upload non-commited stuffs | ||
| 2010-01-26 17:44 <sharoon> bechamel: thats right | ||
| 2010-01-26 17:46 <cedk> udono: no | ||
| 2010-01-26 17:47 <cedk> udono: http://paste.pocoo.org/show/170293/ | ||
| 2010-01-26 17:48 <udono> cedk: yes, got it, thanks | ||
| 2010-01-26 17:58 <sharoon> cedk: when i use python setup.py py2exe it gives error: invalid command 'py2exe' | ||
| 2010-01-26 18:02 <cedk> sharoon: py2exe can only be run on windows | ||
| 2010-01-26 18:12 -!- FWiesing(n=FWiesing@194-208-185-012.tele.net) has joined #tryton | ||
| 2010-01-26 18:13 <sharoon> cedk: got you | ||
| 2010-01-26 18:14 -!- KangOl(n=chs@212-166-58-166.win.be) has joined #tryton | ||
| 2010-01-26 18:40 -!- vengfulsquirrel(n=ian@c-69-181-194-95.hsd1.ca.comcast.net) has joined #tryton | ||
| 2010-01-26 20:08 -!- LucaSub1(n=LucaSub@host138-184-dynamic.5-87-r.retail.telecomitalia.it) has joined #tryton | ||
| 2010-01-26 20:08 -!- LucaSub1(n=LucaSub@host138-184-dynamic.5-87-r.retail.telecomitalia.it) has left #tryton | ||
| 2010-01-26 20:17 -!- sharoon(n=sharoont@host86-189-12-98.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-26 20:17 -!- sharoon(n=sharoont@host86-189-12-98.range86-189.btcentralplus.com) has left #tryton | ||
| 2010-01-26 20:17 -!- sharoon(n=sharoont@host86-189-12-98.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-26 20:21 <sharoon> cedk: bechamel: so is the module for sale_opportunity final now? | ||
| 2010-01-26 20:24 <yangoon> sharoon sorry, still no answer for me and codereview currently is incomplete (no xml) | ||
| 2010-01-26 20:24 <sharoon> yangoon: whats your question? | ||
| 2010-01-26 20:25 <sharoon> "I don't see the difference between States lead and opportunity."? | ||
| 2010-01-26 20:25 <yangoon> sharoon: comment 8 on codereview | ||
| 2010-01-26 20:25 <sharoon> yangoon: we discussed this yesterday | ||
| 2010-01-26 20:26 <sharoon> yangoon: http://www.tryton.org/~irclog/2010-01-26.log.html | ||
| 2010-01-26 20:26 <yangoon> sharoon: then I will have mised something | ||
| 2010-01-26 20:27 <sharoon> bechamel: cedk: yangoon: if you guys consider this complete for sale_opportunity, then I want to go into my next requirement: CRM Cases, Tickets | ||
| 2010-01-26 20:27 <sharoon> if we can discuss here then we could have a common solution like yesterday. | ||
| 2010-01-26 20:29 <yangoon> sharoon: even re-reading the log gives me no answer to my question | ||
| 2010-01-26 20:29 <sharoon> yangoon: let me explain | ||
| 2010-01-26 20:30 <sharoon> yangoon: Lead is like a tip off. Eg. Company X wants to implement ERP and you come to know of it | ||
| 2010-01-26 20:31 <sharoon> yangoon: Then you take it to an opportunity after which they say, Yes, we are looking for a solution lets discuss this... If they say No we are obsessed with M$ then we mark it as a lost lead and record the reason as their obsession | ||
| 2010-01-26 20:32 <sharoon> yangoon: during the discussions at various stages we take the winning probability up and down and finally we win it (converted opportunity) or loose it (lost opportunity) | ||
| 2010-01-26 20:33 <yangoon> sharoon: as far as I have read 'lead' is a more generic term, not necessarily related to sales | ||
| 2010-01-26 20:34 <yangoon> so if you have a state lead on oppportunities I am with you | ||
| 2010-01-26 20:34 <sharoon> yangoon: yes and no | ||
| 2010-01-26 20:35 <sharoon> yangoon: yes, thats exactly the design :-) | ||
| 2010-01-26 20:35 <yangoon> but the model you created for me is opportunity | ||
| 2010-01-26 20:35 <sharoon> yes, and lead is a state in that | ||
| 2010-01-26 20:35 <yangoon> exactly | ||
| 2010-01-26 20:36 <yangoon> so I would rename all occurrences of Leads/Opportunities to Opportunities, because this is the model | ||
| 2010-01-26 20:36 <yangoon> leads only being a state | ||
| 2010-01-26 20:54 <cedk> yangoon, sharoon : I'm thinking that we could rename lead into draft | ||
| 2010-01-26 20:55 <cedk> a state that is common in Tryton | ||
| 2010-01-26 20:55 <sharoon> cedk: all such systems have a lead and when simething functions like a lead lets use that term ? | ||
| 2010-01-26 20:55 <sharoon> i have uploaded the new code: http://codereview.appspot.com/195047/show | ||
| 2010-01-26 20:56 <sharoon> http://en.wikipedia.org/wiki/Sales_lead | ||
| 2010-01-26 20:59 <cedk> sharoon: ok, so why using open lead and not just lead | ||
| 2010-01-26 20:59 <sharoon> cedk: agree | ||
| 2010-01-26 21:00 <cedk> sharoon: according to wikipedia, state opportunity should be qualified | ||
| 2010-01-26 21:01 <sharoon> cedk: can you share the link? | ||
| 2010-01-26 21:01 <cedk> sharoon: http://en.wikipedia.org/wiki/Sales_lead | ||
| 2010-01-26 21:02 <cedk> sharoon: I think also it misses the company | ||
| 2010-01-26 21:02 <sharoon> cedk: +1 M2O to company? | ||
| 2010-01-26 21:02 <cedk> sharoon: yes | ||
| 2010-01-26 21:02 <cedk> sharoon: with rules to prevent other company users to see opportinyties | ||
| 2010-01-26 21:03 <cedk> sharoon: and also instead of using user, we should use employee | ||
| 2010-01-26 21:03 <cedk> sharoon: I don't think that every sales will have an user | ||
| 2010-01-26 21:04 <sharoon> company = fields.Many2One('company.company', 'Company', required=True, | ||
| 2010-01-26 21:04 <sharoon> states={ | ||
| 2010-01-26 21:04 <sharoon> 'readonly':Not(Equal(Eval('state'), 'lead'), | ||
| 2010-01-26 21:04 <sharoon> }, domain=[ | ||
| 2010-01-26 21:04 <sharoon> ('id', If(In('company', Eval('context', {})), '=', '!='), | ||
| 2010-01-26 21:04 <sharoon> Get(Eval('context', {}), 'company', 0)), | ||
| 2010-01-26 21:04 <sharoon> ]) | ||
| 2010-01-26 21:04 <sharoon> cedk: the employee is usually called owner in other systems like salesforce | ||
| 2010-01-26 21:06 <cedk> sharoon: why not sale? | ||
| 2010-01-26 21:06 <sharoon> cedk: i did not understand | ||
| 2010-01-26 21:06 <cedk> sharoon: ok for company fields | ||
| 2010-01-26 21:07 <cedk> sharoon: employee many2one named salesman (better) | ||
| 2010-01-26 21:07 <sharoon> cedk: agree | ||
| 2010-01-26 21:07 <sharoon> cedk: where is the employee object? | ||
| 2010-01-26 21:09 <cedk> sharoon: in module company | ||
| 2010-01-26 21:10 <sharoon> cedk: company.employee | ||
| 2010-01-26 21:10 <cedk> sharoon: yes | ||
| 2010-01-26 21:12 <cedk> ACTION bbl | ||
| 2010-01-26 21:21 -!- rednul_(n=rednul@host-69-144-210-149.cod-wy.client.bresnan.net) has joined #tryton | ||
| 2010-01-26 21:52 <sharoon> yangoon: 1 question from the comment | ||
| 2010-01-26 21:52 <sharoon> yangoon: lead -> prospect is true when you treat a lead as entity | ||
| 2010-01-26 21:53 <sharoon> yangoon: but in this design lead -> opportunity is a process | ||
| 2010-01-26 21:53 <sharoon> yangoon: you cannot call it a prospect? | ||
| 2010-01-26 21:53 <sharoon> yangoon: thoughts? | ||
| 2010-01-26 21:53 <yangoon> sharoon: we are talking about states | ||
| 2010-01-26 21:54 <yangoon> sharoon: finally you are the native speaker I think | ||
| 2010-01-26 21:54 <yangoon> my thoughts are just what I read from the cited links | ||
| 2010-01-26 21:54 <sharoon> yes yangoon | ||
| 2010-01-26 21:54 <sharoon> yangoon: i went through few systems | ||
| 2010-01-26 21:54 <sharoon> yangoon: so this is one approach we could use with our system an ERP | ||
| 2010-01-26 21:55 <sharoon> yangoon: in a dedicated CRM the Entity (customer) itself could migrate from lead -> prospect to ... | ||
| 2010-01-26 22:03 <yangoon> sharoon: genericity (also in states) has its advantages, but I have to sleep one night thinking about;) | ||
| 2010-01-26 22:03 <yangoon> and read a little bit more | ||
| 2010-01-26 22:04 <sharoon> yangoon: i agree with genericity of things, but something like an opportunity makes more sense to be called a lead than draft?? | ||
| 2010-01-26 22:05 <yangoon> sharoon: it depends | ||
| 2010-01-26 22:06 <yangoon> a draft in tryton normally is something which has absolutely no effect, it is a blue print | ||
| 2010-01-26 22:07 <sharoon> yangoon: i agree but leads have effect | ||
| 2010-01-26 22:07 <sharoon> sale orders in draft are blueprints but leads are not | ||
| 2010-01-26 22:07 <sharoon> leads are important for you? | ||
| 2010-01-26 22:08 <yangoon> sharoon: if you took some action on a lead, it can no more be a draft | ||
| 2010-01-26 22:09 <yangoon> but I think we should have state draft for a lead/opportunity | ||
| 2010-01-26 22:09 <sharoon> yangoon: not really, i got a lead that somebody needs an erp, how many of them to translate into opportunity is an import KPI | ||
| 2010-01-26 22:17 -!- sharoon(n=sharoont@host86-189-12-98.range86-189.btcentralplus.com) has joined #tryton | ||
| 2010-01-26 23:11 <cedk> sharoon: sorry for all remarks about coding style but we think it is important to have same coding style in all the project | ||
| 2010-01-26 23:11 <cedk> sharoon: it makes the read easier and if somebody needs to work on one module that he doesn't know he will not be lost | ||
| 2010-01-26 23:28 <sharoon> cedk: i agree absolutely that coding style is important and i always stress on this... thanks guys for the review. I love the way you guys do it | ||
| 2010-01-26 23:31 <sharoon> cedk: can you explain how the states is to be refactored? | ||
| 2010-01-26 23:32 <cedk> sharoon: which states? | ||
| 2010-01-26 23:32 <sharoon> http://codereview.appspot.com/195047/patch/1019/1021 | ||
| 2010-01-26 23:32 <sharoon> comment 1 | ||
| 2010-01-26 23:34 <cedk> sharoon: it is about indentation, the } must be under the s of states | ||
| 2010-01-26 23:35 <sharoon> is it the first s or second s? | ||
| 2010-01-26 23:36 <cedk> sharoon: first one | ||
| 2010-01-26 23:36 <sharoon> cedk: BTW i decided to declare state dic for lead & converted because it could be reused | ||
| 2010-01-26 23:36 <sharoon> cedk: ok | ||
| 2010-01-26 23:37 <cedk> sharoon: don't understand | ||
| 2010-01-26 23:37 <sharoon> _STATES_CONVERTED = {'readonly': Equal(Eval('state'), 'converted'),} | ||
| 2010-01-26 23:38 <sharoon> and then use states=_STATES_CONVERTED | ||
| 2010-01-26 23:38 <sharoon> because its used atleast 6 times | ||
| 2010-01-26 23:40 <cedk> sharoon: why not | ||
| 2010-01-26 23:42 <sharoon> cedk: what abt intendation in self.write | ||
| 2010-01-26 23:45 <cedk> sharoon: 4cols for 'end_date' | ||
| 2010-01-26 23:45 <cedk> sharoon: oops 8cols indent for keys | ||
| 2010-01-26 23:45 <cedk> sharoon: and 4cols indent for } |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!