| chat.freenode.net #tryton log beginning Fri Jan 16 00:00:02 CET 2009 | ||
| 2009-01-16 00:00 <vengfulsquirrel> For example the color/size stuff does not make sense to me. | ||
| 2009-01-16 00:00 <X0d_of_N0d> well... | ||
| 2009-01-16 00:00 <X0d_of_N0d> there are a acouple of options here | ||
| 2009-01-16 00:01 <X0d_of_N0d> the accounting system we're currently using has "configurable" boms and "variable" boms | ||
| 2009-01-16 00:02 <X0d_of_N0d> configurable boms are like we said, variable boms are boms where there's only one item, but the amount of that item is determined at time of order | ||
| 2009-01-16 00:03 <X0d_of_N0d> however if we just had a regular bom line that included part and quantity one could simply put in the same item multiple times with different quantities to get the same effect as a "variable" bom | ||
| 2009-01-16 00:03 <vengfulsquirrel> Right | ||
| 2009-01-16 00:03 <X0d_of_N0d> as far as color goes, we could assume that the same item in a different color would have a different part number | ||
| 2009-01-16 00:03 <carlos> cedk: would be possible that you share the hgweb.config file you use for hg.tryton.org ? | ||
| 2009-01-16 00:05 <X0d_of_N0d> of course, the question becomes how we store configurations | ||
| 2009-01-16 00:06 <vengfulsquirrel> Yeah well where to store them is question one I guess, purchase orders, sales, and production runs? | ||
| 2009-01-16 00:07 <X0d_of_N0d> right | ||
| 2009-01-16 00:07 <X0d_of_N0d> ok....hum.... | ||
| 2009-01-16 00:09 <X0d_of_N0d> When a purchase order gets created, that would triger the configuration | ||
| 2009-01-16 00:09 <X0d_of_N0d> it has to be configured before a purchase order can be actually entered into the system | ||
| 2009-01-16 00:10 <vengfulsquirrel> Yeah but you would only need to configure the product when you added it while filling in the purchase order. | ||
| 2009-01-16 00:10 <X0d_of_N0d> that would be the proper workflow | ||
| 2009-01-16 00:13 <X0d_of_N0d> So where in sales do you think it could be stored? | ||
| 2009-01-16 00:13 <vengfulsquirrel> Yeah seems like the model could be stored outside of the actual order line in all those cases and the configurator would just know how to fill the order line correctly. | ||
| 2009-01-16 00:13 <vengfulsquirrel> So there would be some recursive structure but the order itself wouldn't really need to know about it because its order line would be filled correctly. | ||
| 2009-01-16 00:14 <X0d_of_N0d> perhaps | ||
| 2009-01-16 00:14 <X0d_of_N0d> but why not just store it there? | ||
| 2009-01-16 00:14 <vengfulsquirrel> As a rollup of order lines? | ||
| 2009-01-16 00:15 <X0d_of_N0d> hum... | ||
| 2009-01-16 00:15 <vengfulsquirrel> Well we'd have to face-lift the entire view/print/storage process for sales and purchases. | ||
| 2009-01-16 00:16 <vengfulsquirrel> I am not familiar with the existing design though so I'll have to look into that. | ||
| 2009-01-16 00:17 <X0d_of_N0d> we'd need a configure button to appear for configurable boms, and we'd need to add a field to the db for configuration | ||
| 2009-01-16 00:18 <X0d_of_N0d> and we'd need to store the rev aswell | ||
| 2009-01-16 00:19 <vengfulsquirrel> The revision of the configurable bom ? | ||
| 2009-01-16 00:19 <X0d_of_N0d> yes | ||
| 2009-01-16 00:20 <X0d_of_N0d> ACTION stops for a sec... | ||
| 2009-01-16 00:20 <X0d_of_N0d> sales order, not purchase order.... it would be configured when it's sold | ||
| 2009-01-16 00:20 <X0d_of_N0d> yeah | ||
| 2009-01-16 00:21 <vengfulsquirrel> oh i figured you'd need to do both.. when you asked a supplier for something you might have to configure what you want to buy.. does that never happen ? | ||
| 2009-01-16 00:22 <X0d_of_N0d> no, that's their problem | ||
| 2009-01-16 00:22 <X0d_of_N0d> you just enter a new part number for each different configuration | ||
| 2009-01-16 00:24 <vengfulsquirrel> so would you not need to configure a product for production either? the only configuration happens at sale time? | ||
| 2009-01-16 00:24 <X0d_of_N0d> for what we're doing I don't think we need to worry about that now | ||
| 2009-01-16 00:25 <X0d_of_N0d> I can think of cases where you might want to be able to configure something during production, but for what we're doing we don't care right now | ||
| 2009-01-16 00:25 <X0d_of_N0d> so, yeah, the only time you need to configure something is when you sell it | ||
| 2009-01-16 00:30 <vengfulsquirrel> okay | ||
| 2009-01-16 00:30 <vengfulsquirrel> great | ||
| 2009-01-16 00:30 <vengfulsquirrel> So now routings/workcenters and scheduling. | ||
| 2009-01-16 00:30 <X0d_of_N0d> ok | ||
| 2009-01-16 00:31 <vengfulsquirrel> I had planned to allocate the materials at the start of the route and then the finished product would pop out at the end is that do heavy handed? | ||
| 2009-01-16 00:31 <vengfulsquirrel> Will resources not need to show up until half-way through the route? | ||
| 2009-01-16 00:32 <vengfulsquirrel> *too heavy handed | ||
| 2009-01-16 00:32 <X0d_of_N0d> well... | ||
| 2009-01-16 00:32 <X0d_of_N0d> there are two types of allocation | ||
| 2009-01-16 00:32 <vengfulsquirrel> Sorry I'm talking specifically about materials/products/subassemblies whatever is pulled from stock and used in one giving routing. | ||
| 2009-01-16 00:32 <X0d_of_N0d> there's real allocation (it's not there anymore at all) and virtual allocation (it's there, but we're gonna use it so don't plan on using it for anything else) | ||
| 2009-01-16 00:34 <X0d_of_N0d> when a sales order becomes a production order all the stock needed for everything should be virtually allocated, then at each step as the work order is opened the stock should then be allocated | ||
| 2009-01-16 00:35 <vengfulsquirrel> hmm okay well i had planned on having a production run use moves to get the production materials out of Storage and into the Production Input Zone. | ||
| 2009-01-16 00:36 <X0d_of_N0d> yeah, that sounds good | ||
| 2009-01-16 00:36 <vengfulsquirrel> So you could physically or virtually do that, I guess it doesn't matte.r | ||
| 2009-01-16 00:36 <X0d_of_N0d> hum... | ||
| 2009-01-16 00:37 <vengfulsquirrel> Then you move things 'into' production when it starts and out if it stops.. and when its done the materials are just in production and your finished products come out into the Production Output Zone. | ||
| 2009-01-16 00:37 <X0d_of_N0d> except that it would move things out of storage so it would be harder to keep track of the items | ||
| 2009-01-16 00:38 <X0d_of_N0d> you had a chart of this, didn't you? | ||
| 2009-01-16 00:39 <vengfulsquirrel> Yeah I was trying to find it. | ||
| 2009-01-16 00:39 <X0d_of_N0d> ok | ||
| 2009-01-16 00:40 <vengfulsquirrel> http://www.laspilitas.com/s/images/stock-production.png | ||
| 2009-01-16 00:41 <X0d_of_N0d> brb | ||
| 2009-01-16 00:44 <vengfulsquirrel> Yeah Input and Output should probably be children of production. | ||
| 2009-01-16 00:45 <X0d_of_N0d> yeah | ||
| 2009-01-16 00:47 <vengfulsquirrel> i wanted a sink for materials though and a source for finished products | ||
| 2009-01-16 00:48 <X0d_of_N0d> yeah | ||
| 2009-01-16 00:48 <X0d_of_N0d> well, shouldn't that be lost & found? | ||
| 2009-01-16 00:49 <vengfulsquirrel> Yeah I guess maybe I misunderstand what lost and found was for, ha and took it too literally. | ||
| 2009-01-16 00:50 <vengfulsquirrel> Is this too ridiculous? http://www.laspilitas.com/s/images/stock-production.png I updated it so you might have to refresh. | ||
| 2009-01-16 00:51 <vengfulsquirrel> yeah actually that's kind of annoying in the same way except now its shop floor that is pooling up past materials and finished products. | ||
| 2009-01-16 00:53 <vengfulsquirrel> Well I'll keep thinking but yeah something like Assign->Schedule->Start->Done With options to Cancel and Stop for a Production Run. | ||
| 2009-01-16 00:55 <vengfulsquirrel> *Draft->Assign | ||
| 2009-01-16 00:57 <X0d_of_N0d> where the resources are allocated should be defined in the route or something similar | ||
| 2009-01-16 00:58 <carlos> ikks: hi, around? | ||
| 2009-01-16 00:58 <vengfulsquirrel> Yeah I guess Assign would pull stock from storage, but Schedule would do resource/workcenter assignment based on the routings. | ||
| 2009-01-16 00:59 <X0d_of_N0d> the schedule should create a move order, then when work actually begins the move order gets fulfilled | ||
| 2009-01-16 01:01 <vengfulsquirrel> Hmm do draft Moves block products from being assigned elsewherE/ | ||
| 2009-01-16 01:01 <vengfulsquirrel> *? | ||
| 2009-01-16 01:03 <X0d_of_N0d> or rather, do draft moves block products from being assigned elsewhere? | ||
| 2009-01-16 01:03 <cedk> X0d_of_N0d: no | ||
| 2009-01-16 01:04 <X0d_of_N0d> ok | ||
| 2009-01-16 01:04 <vengfulsquirrel> So the move must be done before work can start to guaranteee the product can be assigned. | ||
| 2009-01-16 01:04 <cedk> vengfulsquirrel: or assigned | ||
| 2009-01-16 01:05 <vengfulsquirrel> Okay yeah great that works as I had planned then. | ||
| 2009-01-16 01:06 <vengfulsquirrel> Except we'd probably use an internal packing with a bunch of moves and it all would get assigned before work could start and then it would change to Done once work started. | ||
| 2009-01-16 01:07 <cedk> vengfulsquirrel: I think that all that moves must be handle by a kind of production object (not the internal packing) | ||
| 2009-01-16 01:08 <vengfulsquirrel> Oh okay, noted. | ||
| 2009-01-16 01:08 <X0d_of_N0d> what about just adding a field to inventory to signify how much is allocated | ||
| 2009-01-16 01:08 <X0d_of_N0d> ? | ||
| 2009-01-16 01:09 <vengfulsquirrel> That's what moves are I thought. | ||
| 2009-01-16 01:09 <vengfulsquirrel> Except much more convenient. | ||
| 2009-01-16 01:10 <cedk> vengfulsquirrel: but I think it must also have a kind of meta-model that display all moves collapsed for today production | ||
| 2009-01-16 01:10 <X0d_of_N0d> the problem with moving stuff is that it doesn't *actually* move... so it makes things confusing | ||
| 2009-01-16 01:10 <cedk> for today or for any other time base for production (hours, week, etc...) | ||
| 2009-01-16 01:11 <vengfulsquirrel> Well you could build that based on production runs finished during any time range if the moves are stored per production run. | ||
| 2009-01-16 01:11 <vengfulsquirrel> X0d_of_N0d: What do you mean they don't actually move? | ||
| 2009-01-16 01:12 <cedk> X0d_of_N0d: as the stock is double entry, you must create move to change stock quantity | ||
| 2009-01-16 01:12 <X0d_of_N0d> you assign something to production by moving it into a production area... | ||
| 2009-01-16 01:12 <vengfulsquirrel> No assign just says I'm going to move this... don't move it. | ||
| 2009-01-16 01:13 <vengfulsquirrel> Done means I moved it, its not there anymore. | ||
| 2009-01-16 01:13 <cedk> vengfulsquirrel: but I think that you will prepare products for a set of production | ||
| 2009-01-16 01:14 <vengfulsquirrel> cedk: Right like pull all the production materials in the morning to satisfy all production runs for that day? | ||
| 2009-01-16 01:15 <cedk> vengfulsquirrel: yes, but for the all day, you can have many production order, so you will have many little move and I think it is better to collapse all those moves | ||
| 2009-01-16 01:16 <vengfulsquirrel> Ha oh I see what you mean by collapse, I thought you meant some sort of gui construct. | ||
| 2009-01-16 01:16 <cedk> it is just some thoughts | ||
| 2009-01-16 01:18 <vengfulsquirrel> cedk: Is there any functionality regarding consolidating moves like that in tryton right now ? | ||
| 2009-01-16 01:18 <vengfulsquirrel> It might confuse the system if 10 production runs point to the same move which overcompensates for their quantity. | ||
| 2009-01-16 01:18 <cedk> vengfulsquirrel: no | ||
| 2009-01-16 01:19 <cedk> but now, I readed the MPC on wiki | ||
| 2009-01-16 01:20 <cedk> and I think that if we work with period perhaps what I said is no more right | ||
| 2009-01-16 01:20 <vengfulsquirrel> MPC? | ||
| 2009-01-16 01:21 <cedk> vengfulsquirrel: is there one MPC per production line? | ||
| 2009-01-16 01:21 <cedk> vengfulsquirrel: Master Production Calendar | ||
| 2009-01-16 01:21 <vengfulsquirrel> Ha oh great my names are killing me. | ||
| 2009-01-16 01:22 <vengfulsquirrel> That is all rough, I was just trying to formulate on there, I still have to go over the double level planning with X0d to see if its even possible. | ||
| 2009-01-16 01:23 <vengfulsquirrel> The calendar was just to sort of setup a structure for planning to take place in... and then it would be used to produce a rough schedule of when to produce things.. and then during each period a detailed scheduling would be created using routings. | ||
| 2009-01-16 01:23 -!- bechamel(n=user@85.201.86.139) has left #tryton | ||
| 2009-01-16 01:24 <cedk> vengfulsquirrel: routings? | ||
| 2009-01-16 01:26 <vengfulsquirrel> If routings were defined of course, they are a plan for a path between workcenters. If you have a set production line routings are mostly not needed or are trivial. | ||
| 2009-01-16 01:28 <carlos> good night | ||
| 2009-01-16 01:29 <vengfulsquirrel> X0d_of_N0d: Hey so I think the moves setup is flexible and can be solved later. | ||
| 2009-01-16 01:30 <X0d_of_N0d> ok | ||
| 2009-01-16 01:30 <X0d_of_N0d> so what do we have left? | ||
| 2009-01-16 01:31 <vengfulsquirrel> X0d_of_N0d: Capacity, Routing definition, Workcetner definition, how scheduling works for routings ... how that fits into the overall master schedule... and then how that all is updated when s*** hits the fan. | ||
| 2009-01-16 01:32 <vengfulsquirrel> So just like 95% more stuff. | ||
| 2009-01-16 01:32 <X0d_of_N0d> lol | ||
| 2009-01-16 01:32 <X0d_of_N0d> capacity is part of scheduling, we should talk about anything related to scheduling last | ||
| 2009-01-16 01:33 <X0d_of_N0d> hum... | ||
| 2009-01-16 01:33 <vengfulsquirrel> Well routing definition, workcenter definition exist purely for scheduling. | ||
| 2009-01-16 01:33 <X0d_of_N0d> yeah | ||
| 2009-01-16 01:33 <X0d_of_N0d> hum.. | ||
| 2009-01-16 01:33 <X0d_of_N0d> well routing relies on workcenters so lets talk about those | ||
| 2009-01-16 01:34 <cedk> scheduling is for MRPII, no ? | ||
| 2009-01-16 01:35 <vengfulsquirrel> Yeah routing/workcenters are for mrp II but I have to make sure MRP I doesn't have to be rewritten for MRP II. And even with MRP I some sort of basic scheduling functionality must exist for MPR I. | ||
| 2009-01-16 01:35 <X0d_of_N0d> MRP, MRP II... the more I read the less I think anyone knows | ||
| 2009-01-16 01:36 <X0d_of_N0d> MRP needs to be able to schedule purchase orders to make sure materials exist | ||
| 2009-01-16 01:37 <vengfulsquirrel> right and schedule production runs for a similar reason | ||
| 2009-01-16 01:37 <X0d_of_N0d> right | ||
| 2009-01-16 01:37 <vengfulsquirrel> but without routings and workcenters that is all pretty straight forward because the scheduling is pretty rough | ||
| 2009-01-16 01:37 <cedk> yes but MRP I consider that you have infinite capacity | ||
| 2009-01-16 01:37 <vengfulsquirrel> yes it only takes time into account | ||
| 2009-01-16 01:37 <vengfulsquirrel> and usually rough buffered time | ||
| 2009-01-16 01:39 <cedk> I think that MRPI must schedule at last time and with MRPII we delay depending of the capacity | ||
| 2009-01-16 01:40 <vengfulsquirrel> X0d_of_N0d: For routings you need operations and each operation needs some set of resources, some set of workers, a workcenter or a group of workcenters(which one wc is selected from), a setup time(optional), a run time and a cleanup time(optional). I am not sure how to handle the complexity of operations shared between routings or if one operation should happen on more than 1 workcenter. | ||
| 2009-01-16 01:40 <X0d_of_N0d> MRP I says "you need to make this", MRP II says "you need to make this, and you should make it on these work centers at this time" | ||
| 2009-01-16 01:42 <X0d_of_N0d> keeping track of workers isn't something I've seen in other mrp packages. It could be useful but usually they're ignored | ||
| 2009-01-16 01:42 <X0d_of_N0d> I think we can safely ignore workers as a resource at the moment | ||
| 2009-01-16 01:43 <cedk> vengfulsquirrel: I think that it is too difficult to write a program that plannify correctly everythings, I think you must allow to over schedule and let the user to handle this issue | ||
| 2009-01-16 01:44 <X0d_of_N0d> cedk: I disagree, but I do think this should be looked at later rather than now | ||
| 2009-01-16 01:44 <X0d_of_N0d> so lets see.... | ||
| 2009-01-16 01:44 <vengfulsquirrel> cedk: Well with two levels of scheduling it would be less hard, but we could make the scheduling kind of pluggable. | ||
| 2009-01-16 01:44 <cedk> X0d_of_N0d: for me it is a NP-complete problem | ||
| 2009-01-16 01:45 <X0d_of_N0d> cedk: it is, but you don't have to be perfect... just close | ||
| 2009-01-16 01:46 <cedk> X0d_of_N0d: that is what I try to say, the system must allow to break some rules, like allocating more ressources | ||
| 2009-01-16 01:46 <X0d_of_N0d> cedk: and when it does it brings up an error and asks the user to take care of it | ||
| 2009-01-16 01:47 <cedk> vengfulsquirrel: I find that two levels make stuff more complicated (and in Tryton we like simple things) | ||
| 2009-01-16 01:47 <vengfulsquirrel> Until I have a better idea I had planned to do basic MRP I scheduling across a year for each period. Then within each period capacity scheduling could be done based on the production orders, where you could of course do things like force-schedule and override capacity constraints. | ||
| 2009-01-16 01:47 <cedk> X0d_of_N0d: not an error a warning :-) | ||
| 2009-01-16 01:48 <X0d_of_N0d> cedk: indeed | ||
| 2009-01-16 01:48 <vengfulsquirrel> Does my two-level scheduling plan make sense? | ||
| 2009-01-16 01:49 <cedk> vengfulsquirrel: don't understand very well | ||
| 2009-01-16 01:50 <X0d_of_N0d> cedk: I think there are cases where the kind of fine-grained control over manufacturing would get in the way for some people | ||
| 2009-01-16 01:50 <X0d_of_N0d> ACTION needs to think about it a bit | ||
| 2009-01-16 01:51 <vengfulsquirrel> Using product lead times and product demand for each period schedule purchase order requests and requests for production runs for each period assuming infinite capacity. | ||
| 2009-01-16 01:52 <cedk> vengfulsquirrel: purchase order requests are already done by the module stock_supply | ||
| 2009-01-16 01:52 <vengfulsquirrel> Then within EACH period you can attempt to schedule production runs to satisfy the production requests based on capacity restraints and workcenter scheduling. | ||
| 2009-01-16 01:53 <cedk> vengfulsquirrel: did you look how we handle the purchase request in stock_supply | ||
| 2009-01-16 01:53 <vengfulsquirrel> cedk: Those are based on a fixed product amount though right? | ||
| 2009-01-16 01:54 <cedk> we don't work with fixed periods | ||
| 2009-01-16 01:54 <vengfulsquirrel> Like if you go below 100 units order more. | ||
| 2009-01-16 01:54 <vengfulsquirrel> I looked at it a few weeks ago but not in specific detail. | ||
| 2009-01-16 01:54 <cedk> vengfulsquirrel: yes but it is more the way to catch when you must purchase new products | ||
| 2009-01-16 01:55 <cedk> vengfulsquirrel: we look for a period bewteen the ealier delevery date and the next one | ||
| 2009-01-16 01:55 <cedk> and I think that production can be schedule in the same way | ||
| 2009-01-16 01:56 <cedk> based on a floating period depending of the production time and some other factors | ||
| 2009-01-16 01:56 <X0d_of_N0d> you calc lead time based on history? | ||
| 2009-01-16 01:56 <cedk> X0d_of_N0d: no it define on the product (product supplier) | ||
| 2009-01-16 01:56 <X0d_of_N0d> ok | ||
| 2009-01-16 01:57 <X0d_of_N0d> cedk: is there any plan for pricelist capability so this can be done on a per supplier/per product level? | ||
| 2009-01-16 01:57 <cedk> X0d_of_N0d: but it is possible to create a module that analysie history and compute the lead time for each supplier | ||
| 2009-01-16 01:57 <cedk> X0d_of_N0d: lead time is alread by supplier and quantity | ||
| 2009-01-16 01:58 <cedk> for price list, the hook are there, so you can write a module that match your needs | ||
| 2009-01-16 01:58 <X0d_of_N0d> ok | ||
| 2009-01-16 01:58 <cedk> but for now, we don't like the pricelist from OpenERP because it tries to implement every things | ||
| 2009-01-16 01:59 <X0d_of_N0d> ok | ||
| 2009-01-16 01:59 <cedk> and we think it is better to have simple stuff on which you plug module to extend it | ||
| 2009-01-16 01:59 <X0d_of_N0d> so where are lead times defined in the ui? | ||
| 2009-01-16 02:01 <cedk> X0d_of_N0d: on the product, Suppliers tabs | ||
| 2009-01-16 02:01 <cedk> X0d_of_N0d: and you have delivery time per suppliers | ||
| 2009-01-16 02:02 <cedk> X0d_of_N0d: sorry it is not by quantity | ||
| 2009-01-16 02:02 <cedk> the price is linked to the quantity but not the delivery time | ||
| 2009-01-16 02:02 <X0d_of_N0d> hum... what module needs to be installed to get that? I don't have a supplier's tab | ||
| 2009-01-16 02:03 <cedk> X0d_of_N0d: purchase | ||
| 2009-01-16 02:03 <cedk> and the product must be purchasable :-) | ||
| 2009-01-16 02:04 <X0d_of_N0d> oh | ||
| 2009-01-16 02:04 <X0d_of_N0d> right | ||
| 2009-01-16 02:04 <X0d_of_N0d> yeah | ||
| 2009-01-16 02:04 <cedk> vengfulsquirrel: did you already start the model design? | ||
| 2009-01-16 02:05 <X0d_of_N0d> cedk: just out of curisity, do you know if tinyerp has per product/per supplier lead times? | ||
| 2009-01-16 02:06 <cedk> by the way, as you are native english speakers, don't hesitate to correct us | ||
| 2009-01-16 02:06 <vengfulsquirrel> I haven't written any code for it yet no or any usable model diagram I guess. I've just been trying to make a long term plan. | ||
| 2009-01-16 02:07 <cedk> X0d_of_N0d: I don't think | ||
| 2009-01-16 02:07 <cedk> X0d_of_N0d: do you think it is needed | ||
| 2009-01-16 02:08 <cedk> vengfulsquirrel: ok | ||
| 2009-01-16 02:08 <X0d_of_N0d> cedk: it's a big thing here | ||
| 2009-01-16 02:09 <cedk> X0d_of_N0d: I think it can be customized | ||
| 2009-01-16 02:10 <cedk> X0d_of_N0d: there is two function in trytond/modules/purchase/purchase.py on purchase.product_supplier | ||
| 2009-01-16 02:10 <cedk> the functions: compute_supply_date and compute_purchase_date | ||
| 2009-01-16 02:10 <cedk> so you can override it to compute like you want | ||
| 2009-01-16 02:11 <X0d_of_N0d> brb | ||
| 2009-01-16 02:11 <cedk> X0d_of_N0d: I have made a module (not yet public) that allow to define the week day of delivery | ||
| 2009-01-16 02:13 <cedk> X0d_of_N0d: but for quantity, I think we must change some part of the base code | ||
| 2009-01-16 02:13 <cedk> X0d_of_N0d: could you submit a issue on roundup for that? | ||
| 2009-01-16 02:15 <cedk> X0d_of_N0d: I will put it on the TODO list of pruchase | ||
| 2009-01-16 02:17 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 212:9a3809e9cfcb purchase/TODO: Add todo for delivery_time | ||
| 2009-01-16 02:17 <cedk> good night | ||
| 2009-01-16 02:17 <vengfulsquirrel> cedk: good night, ttyl | ||
| 2009-01-16 02:21 <X0d_of_N0d> hum damn, he left before I had a chance to tell him that it looks like tryton already has the functionality we need as far as lead times go | ||
| 2009-01-16 02:23 <X0d_of_N0d> so the stock module might take care of orders then? | ||
| 2009-01-16 02:24 <vengfulsquirrel> Well I'm not sure if I understood him correctly I was just looking at it but I think it just works based on a fixed quantity. | ||
| 2009-01-16 02:24 <X0d_of_N0d> so quantity sinks below a set level and it triggers an order | ||
| 2009-01-16 02:25 <X0d_of_N0d> but we want orders based on demand | ||
| 2009-01-16 02:25 <vengfulsquirrel> yeah, fluctuating demand | ||
| 2009-01-16 02:26 <vengfulsquirrel> and it needs to be computed sometimes from a hiearchy of lead times based on individual products | ||
| 2009-01-16 02:26 <X0d_of_N0d> but that is sort of external to everything... I mean, that can be added to the code later without us thinking about it now | ||
| 2009-01-16 02:26 <vengfulsquirrel> I wonder what happens with multiple suppliers | ||
| 2009-01-16 02:26 <X0d_of_N0d> there would always be a default supplier | ||
| 2009-01-16 02:27 <vengfulsquirrel> Yeah ha you keep saying that but all the planning information must be available and that depends on how the data is structured. | ||
| 2009-01-16 02:27 <vengfulsquirrel> Sorry but with different lead times, but yeah having a single default supplier would solve that. | ||
| 2009-01-16 02:28 <vengfulsquirrel> And also for the transition to happen from phase one to phase two we need to know how those two planning schemes would mesh. | ||
| 2009-01-16 02:28 <X0d_of_N0d> demand is in closed sales orders | ||
| 2009-01-16 02:29 <X0d_of_N0d> rather, predicted demand would be in historical sales orders and existing demand would be in open sales orders | ||
| 2009-01-16 02:29 <X0d_of_N0d> whatever | ||
| 2009-01-16 02:29 <X0d_of_N0d> so that's already taken care of for us | ||
| 2009-01-16 02:29 <vengfulsquirrel> Yeah setting the demand is the easy part, as far as I'm concerned. | ||
| 2009-01-16 02:30 <X0d_of_N0d> but if demand is outside our module, then we don't have to worry about it right now | ||
| 2009-01-16 02:31 <X0d_of_N0d> What we need, first, is to be able to create a sales order and have it pull all the stuff from stock based on the bom structure | ||
| 2009-01-16 02:31 <X0d_of_N0d> and create the work orders, etc... | ||
| 2009-01-16 02:31 <X0d_of_N0d> that's basic functionality | ||
| 2009-01-16 02:33 <vengfulsquirrel> Yeah in a make to order scenario | ||
| 2009-01-16 02:34 <X0d_of_N0d> right, don't worry about workcenters or scheduling or anything... just worry about making sure the bom structure is right so the right stuff gets pulled from stock | ||
| 2009-01-16 02:34 <vengfulsquirrel> Ha I've been talking about make-to-stock this entire time. | ||
| 2009-01-16 02:35 <X0d_of_N0d> right | ||
| 2009-01-16 02:35 <vengfulsquirrel> Okay yeah so that's fine we already talked about the bom that just needs to be passed on to a production request | ||
| 2009-01-16 02:35 <X0d_of_N0d> I think we can gain a lot by breaking this up into very small manageable pieces... | ||
| 2009-01-16 02:36 <X0d_of_N0d> right | ||
| 2009-01-16 02:37 <X0d_of_N0d> so the first thing to do is just implement the bom structure we talked about and tie it to sales and stock | ||
| 2009-01-16 02:37 <X0d_of_N0d> perhaps now would be a good time to figure out the roadmap? | ||
| 2009-01-16 02:38 <vengfulsquirrel> Yeah okay we can do that | ||
| 2009-01-16 02:39 <X0d_of_N0d> I've got the wiki open for editing | ||
| 2009-01-16 02:39 <X0d_of_N0d> ok... so 1 is easy | ||
| 2009-01-16 02:39 <X0d_of_N0d> "implement bom structure and tie it to inventory and sales" | ||
| 2009-01-16 02:39 <X0d_of_N0d> right? | ||
| 2009-01-16 02:40 <vengfulsquirrel> so high level | ||
| 2009-01-16 02:40 <X0d_of_N0d> you think it should be broken down more? | ||
| 2009-01-16 02:40 <vengfulsquirrel> Implement configurable(local and global substitutes), phantom and recursive bom structures. | ||
| 2009-01-16 02:41 <X0d_of_N0d> 2) allow configuration through sales interface | ||
| 2009-01-16 02:41 <X0d_of_N0d> s/\(sales\)/\1 order/ | ||
| 2009-01-16 02:42 <X0d_of_N0d> ? | ||
| 2009-01-16 02:42 <vengfulsquirrel> I think its actually called sales. | ||
| 2009-01-16 02:42 <vengfulsquirrel> That's fine. | ||
| 2009-01-16 02:43 <X0d_of_N0d> make sales orders generate production requests | ||
| 2009-01-16 02:43 <X0d_of_N0d> hum... | ||
| 2009-01-16 02:43 <X0d_of_N0d> we need an interface for production requests | ||
| 2009-01-16 02:44 <X0d_of_N0d> so perhaps 1) create an area for the production interface | ||
| 2009-01-16 02:44 <vengfulsquirrel> Well there will need to be another main menu entry for Production Management. | ||
| 2009-01-16 02:44 <vengfulsquirrel> I'm not sure if that's what you mean. | ||
| 2009-01-16 02:44 <X0d_of_N0d> yeah, it is | ||
| 2009-01-16 02:45 <X0d_of_N0d> oh, what exactly do you mean "configurable(local and global substitutes)" | ||
| 2009-01-16 02:47 <vengfulsquirrel> A list of products that could be used, but it needs different constraints. | ||
| 2009-01-16 02:48 <X0d_of_N0d> what's the difference between global and local substitutes? | ||
| 2009-01-16 02:48 <vengfulsquirrel> Local are for the current assembly like 40/60/80 MB drive. | ||
| 2009-01-16 02:48 <X0d_of_N0d> ok | ||
| 2009-01-16 02:48 <vengfulsquirrel> Global are like ACME 10ft cable or ABC 10ft cable. | ||
| 2009-01-16 02:49 <vengfulsquirrel> Like anywhere every those can be used interchangeably. | ||
| 2009-01-16 02:49 <vengfulsquirrel> *ever | ||
| 2009-01-16 02:49 <X0d_of_N0d> implementation wise they should be the same though | ||
| 2009-01-16 02:50 <vengfulsquirrel> Hmm yeah global substitutes sound pretty fishy to me overall so maybe we should just drop that if its not familiar to you. | ||
| 2009-01-16 02:51 <X0d_of_N0d> yeah, a bom should be recursive so global and local mean the same thing essentially | ||
| 2009-01-16 02:51 <vengfulsquirrel> Yeah I guess my examples would be the same, but for some reason they were different. | ||
| 2009-01-16 02:51 <X0d_of_N0d> ACTION shruggs | ||
| 2009-01-16 02:51 <vengfulsquirrel> Let's go with ignoring it until further notice. | ||
| 2009-01-16 02:51 <X0d_of_N0d> ok, so lets move on | ||
| 2009-01-16 02:51 <vengfulsquirrel> Okay | ||
| 2009-01-16 02:52 <X0d_of_N0d> so 3 was allow configuration of configurable boms in sales | ||
| 2009-01-16 02:52 <X0d_of_N0d> 4) create production order tables and interface | ||
| 2009-01-16 02:52 <X0d_of_N0d> ? | ||
| 2009-01-16 02:53 <vengfulsquirrel> well i was calling it production run but production order is fine | ||
| 2009-01-16 02:53 <vengfulsquirrel> production request-->production order | ||
| 2009-01-16 02:54 <X0d_of_N0d> right, so that it's the same as everything else | ||
| 2009-01-16 02:54 <vengfulsquirrel> yeah that's fine | ||
| 2009-01-16 02:54 <X0d_of_N0d> ok | ||
| 2009-01-16 02:54 <vengfulsquirrel> the relationship between production order and production request are a little fishy though... like how does one connect to the other | ||
| 2009-01-16 02:54 <X0d_of_N0d> "draft production" | ||
| 2009-01-16 02:55 <vengfulsquirrel> ? | ||
| 2009-01-16 02:55 <X0d_of_N0d> I think we should use the same terminology as is used elsewhere | ||
| 2009-01-16 02:55 <X0d_of_N0d> so "draft production run"??? | ||
| 2009-01-16 02:55 <X0d_of_N0d> hum | ||
| 2009-01-16 02:56 <vengfulsquirrel> wait yeah drop run and just call it order | ||
| 2009-01-16 02:56 <vengfulsquirrel> draft production order | ||
| 2009-01-16 02:56 <X0d_of_N0d> "draft production order" -> "production order" | ||
| 2009-01-16 02:57 <X0d_of_N0d> or rather -> "open production order" -> "completed production order" | ||
| 2009-01-16 02:57 <X0d_of_N0d> whatever | ||
| 2009-01-16 02:58 <vengfulsquirrel> draft, assigned, started, stopped, done, canceled | ||
| 2009-01-16 02:59 <X0d_of_N0d> 4) create production order tables and interface that allows for manual production workflow through various states: | ||
| 2009-01-16 02:59 <X0d_of_N0d> ? | ||
| 2009-01-16 03:01 <vengfulsquirrel> yeah | ||
| 2009-01-16 03:01 <X0d_of_N0d> actually it seems like that should go above the configuration of boms in sales thing | ||
| 2009-01-16 03:01 <X0d_of_N0d> sound cool? | ||
| 2009-01-16 03:02 <vengfulsquirrel> yeah except you can't produce configurable items until you .. configure them | ||
| 2009-01-16 03:02 <X0d_of_N0d> right | ||
| 2009-01-16 03:02 <X0d_of_N0d> hum | ||
| 2009-01-16 03:02 <X0d_of_N0d> ok, we'll leave it | ||
| 2009-01-16 03:03 <X0d_of_N0d> but we have to be able to create boms before we can have sales orders trigger their configuration | ||
| 2009-01-16 03:03 <vengfulsquirrel> yeah | ||
| 2009-01-16 03:04 <X0d_of_N0d> so the logical flow seems to me to be create interface for manually running production workflow | ||
| 2009-01-16 03:04 <X0d_of_N0d> then have sales orders trigger creation of draft production orders | ||
| 2009-01-16 03:05 <X0d_of_N0d> then allow for configuration from sales orders | ||
| 2009-01-16 03:06 <vengfulsquirrel> okay yeah wait so production requests are gone, ha i missed that earlier | ||
| 2009-01-16 03:06 <vengfulsquirrel> are those only something planning would produce or are we just eliminating those completely | ||
| 2009-01-16 03:07 -!- X0d_of_N0d(i=user@gateway/tor/x-5c95cd63f0af1d20) has joined #tryton | ||
| 2009-01-16 03:07 <X0d_of_N0d> ACTION looks around | ||
| 2009-01-16 03:10 <vengfulsquirrel> So how do production requests fit into this ? | ||
| 2009-01-16 03:13 <X0d_of_N0d> lemme save the wiki really quick and you can see what I've got right now | ||
| 2009-01-16 03:15 <X0d_of_N0d> hum... | ||
| 2009-01-16 03:15 <X0d_of_N0d> ACTION toys with wiki syntax a bit | ||
| 2009-01-16 03:17 <X0d_of_N0d> ok | ||
| 2009-01-16 03:18 <X0d_of_N0d> road map is at the bottom of the page | ||
| 2009-01-16 03:18 <vengfulsquirrel> 6/3 should probably be the same thing | ||
| 2009-01-16 03:19 <X0d_of_N0d> ok | ||
| 2009-01-16 03:20 <X0d_of_N0d> what about putting 6 as 4 | ||
| 2009-01-16 03:20 <vengfulsquirrel> yeah that's fine | ||
| 2009-01-16 03:21 <X0d_of_N0d> ok | ||
| 2009-01-16 03:22 <vengfulsquirrel> actually maybe 3 should become two parts and 2 should also be expanded to reflect the model design and the ui design | ||
| 2009-01-16 03:22 <vengfulsquirrel> also what about versioning? | ||
| 2009-01-16 03:22 <X0d_of_N0d> so should we set more goals for the roadmap or just decide to add them from here as things go? | ||
| 2009-01-16 03:22 <X0d_of_N0d> hum....yeah | ||
| 2009-01-16 03:23 <X0d_of_N0d> ok, so make 3 2 parts | ||
| 2009-01-16 03:23 <X0d_of_N0d> ... | ||
| 2009-01-16 03:23 <X0d_of_N0d> how should it be broken up you think? | ||
| 2009-01-16 03:24 <X0d_of_N0d> oh yeah, nm.. I'm a little out there today | ||
| 2009-01-16 03:24 <X0d_of_N0d> not enough sleep, too much beer last night, hehe | ||
| 2009-01-16 03:24 <vengfulsquirrel> yeah my sleep schedule has been whack all week | ||
| 2009-01-16 03:24 <vengfulsquirrel> but no beer :( | ||
| 2009-01-16 03:25 <vengfulsquirrel> ha a lot of coffee though | ||
| 2009-01-16 03:25 <X0d_of_N0d> I wasn't planning on really drinking last night, but I found this bourbon stout.... | ||
| 2009-01-16 03:25 <X0d_of_N0d> crazy | ||
| 2009-01-16 03:25 <X0d_of_N0d> really good beer | ||
| 2009-01-16 03:26 <X0d_of_N0d> ok, revisioning | ||
| 2009-01-16 03:26 <vengfulsquirrel> Yeah sounds thick | ||
| 2009-01-16 03:26 <X0d_of_N0d> hum... | ||
| 2009-01-16 03:26 <X0d_of_N0d> vengfulsquirrel: yeah, really thick... and really dark | ||
| 2009-01-16 03:26 <X0d_of_N0d> anyway... yeah... bom revisioning | ||
| 2009-01-16 03:27 <X0d_of_N0d> ok, there are a couple of ways to do this.... | ||
| 2009-01-16 03:28 <X0d_of_N0d> so we're going to store production lead time in boms or in product? | ||
| 2009-01-16 03:28 <X0d_of_N0d> what about storing the bom in product? | ||
| 2009-01-16 03:29 <X0d_of_N0d> err... the interface in product | ||
| 2009-01-16 03:30 <vengfulsquirrel> the bom interfacE? | ||
| 2009-01-16 03:30 <vengfulsquirrel> you mean to create boms | ||
| 2009-01-16 03:30 <X0d_of_N0d> yeah. | ||
| 2009-01-16 03:30 <X0d_of_N0d> we could add a checkbox to product near sellable (salable..need to put in a ticket to fix that) and purchasable | ||
| 2009-01-16 03:31 <X0d_of_N0d> just add "manufactured in house" or something | ||
| 2009-01-16 03:32 <X0d_of_N0d> oh yeah...duh "makeable" | ||
| 2009-01-16 03:32 <vengfulsquirrel> salable? | ||
| 2009-01-16 03:32 <vengfulsquirrel> that's a word | ||
| 2009-01-16 03:32 <X0d_of_N0d> if makeable is check it adds a bom tab | ||
| 2009-01-16 03:33 <vengfulsquirrel> yeah or producable | ||
| 2009-01-16 03:33 <X0d_of_N0d> it is | ||
| 2009-01-16 03:33 <vengfulsquirrel> hmm yeah we could do that and put the lead time for production in there | ||
| 2009-01-16 03:34 <X0d_of_N0d> yeah | ||
| 2009-01-16 03:35 <X0d_of_N0d> and this is where we'd later put routing and bom type and all that | ||
| 2009-01-16 03:36 <X0d_of_N0d> hum... bom revisions though | ||
| 2009-01-16 03:37 <vengfulsquirrel> yeah that sounds good until i see a problem | ||
| 2009-01-16 03:37 <vengfulsquirrel> then i can also just copy/paste the code for salable or purchasable | ||
| 2009-01-16 03:37 <vengfulsquirrel> to get the fancy notebook tabs | ||
| 2009-01-16 03:38 <X0d_of_N0d> ok | ||
| 2009-01-16 03:38 <X0d_of_N0d> exactly | ||
| 2009-01-16 03:40 <vengfulsquirrel> The revisioning is kind of an issue though because we will definately need it later but it will be hard to add it if we aren't using it already. | ||
| 2009-01-16 03:40 <vengfulsquirrel> I think a bom version should go from draft to done and then be readonly or something like that. | ||
| 2009-01-16 03:41 <X0d_of_N0d> interesting sellable gets taged by firefox as being spelled wrong...hum... | ||
| 2009-01-16 03:41 <X0d_of_N0d> hum, right | ||
| 2009-01-16 03:41 <X0d_of_N0d> lets see... | ||
| 2009-01-16 03:41 <vengfulsquirrel> Then if someone wants to make a change they have to make a new draft and move it to done etc. | ||
| 2009-01-16 03:41 <vengfulsquirrel> And the rest of the system depends on a fixed bom version | ||
| 2009-01-16 03:42 <X0d_of_N0d> a lot of times boms have dates on them | ||
| 2009-01-16 03:42 <vengfulsquirrel> valid from/to ? | ||
| 2009-01-16 03:42 <X0d_of_N0d> right | ||
| 2009-01-16 03:42 <X0d_of_N0d> two boms for the same product cannot be valid at the same time... | ||
| 2009-01-16 03:42 <vengfulsquirrel> yeah we could have that and fall back to using the most recent done version otherwise. | ||
| 2009-01-16 03:42 <X0d_of_N0d> and if a bom is currently valid it cannot be changed, it has to be invalidated | ||
| 2009-01-16 03:44 <vengfulsquirrel> right well it can never be changed you just have to paint over it with a new version | ||
| 2009-01-16 03:44 <X0d_of_N0d> right | ||
| 2009-01-16 03:44 <vengfulsquirrel> what if a product doesn't have any valid bom at all ? | ||
| 2009-01-16 03:45 <vengfulsquirrel> also what if a product only have invalid boms? | ||
| 2009-01-16 03:45 <vengfulsquirrel> *has | ||
| 2009-01-16 03:45 <X0d_of_N0d> then it can't be produced | ||
| 2009-01-16 03:45 <vengfulsquirrel> what if production is taking place and someone goes and invalidates all the boms? | ||
| 2009-01-16 03:45 <X0d_of_N0d> it should raise a warning "there are no valid boms for this item, it cannot be produced" | ||
| 2009-01-16 03:46 <X0d_of_N0d> after the production order becomes valid the bom_id becomes linked to it | ||
| 2009-01-16 03:46 <X0d_of_N0d> valid or not | ||
| 2009-01-16 03:46 <vengfulsquirrel> okay | ||
| 2009-01-16 03:47 <vengfulsquirrel> so valid really only effects initial usage | ||
| 2009-01-16 03:47 <X0d_of_N0d> that is used through production no matter what | ||
| 2009-01-16 03:47 <X0d_of_N0d> right | ||
| 2009-01-16 03:47 <X0d_of_N0d> if you want it to effect an active prodution run you have to stop the run | ||
| 2009-01-16 03:48 <vengfulsquirrel> well probably cancel the run and create a new one and furthermore maybe create a new sale | ||
| 2009-01-16 03:48 <vengfulsquirrel> if the bom used inititally was wrong | ||
| 2009-01-16 03:48 <vengfulsquirrel> *to configure it | ||
| 2009-01-16 03:49 <X0d_of_N0d> I don't think you should have to create a new sale... | ||
| 2009-01-16 03:49 <X0d_of_N0d> well, yeah, if it was a misconfigured bom then you would | ||
| 2009-01-16 03:49 <vengfulsquirrel> right | ||
| 2009-01-16 03:49 <vengfulsquirrel> but that would be one case usually you could just recreate the production order and get the new bom | ||
| 2009-01-16 03:49 <X0d_of_N0d> but lets say you are in the middle of a run and you find out that widget X breaks randomly, but you fixed it with widget X-1 | ||
| 2009-01-16 03:50 <X0d_of_N0d> right | ||
| 2009-01-16 03:50 <vengfulsquirrel> okay but yeah sorry earlier i asked about production requests, are those only for planning then | ||
| 2009-01-16 03:50 <vengfulsquirrel> sales go straight to production orders | ||
| 2009-01-16 03:51 <vengfulsquirrel> i guess a production request will kind of be a planning version of a sale | ||
| 2009-01-16 03:51 <X0d_of_N0d> no, sales should go to production requests... a production order needs to take place at a given time so it must be scheduled | ||
| 2009-01-16 03:51 <vengfulsquirrel> okay can you explain how that would work | ||
| 2009-01-16 03:51 <X0d_of_N0d> well actually.... | ||
| 2009-01-16 03:51 <X0d_of_N0d> ok | ||
| 2009-01-16 03:52 <vengfulsquirrel> specifically how they would be related | ||
| 2009-01-16 03:52 <X0d_of_N0d> here's the workflow | ||
| 2009-01-16 03:52 <vengfulsquirrel> since one production could technically satisfy 10 production requests | ||
| 2009-01-16 03:52 <X0d_of_N0d> 1) customer orders the product | ||
| 2009-01-16 03:52 <X0d_of_N0d> right | ||
| 2009-01-16 03:53 <X0d_of_N0d> and there's also also the issue that a customer might order something and you don't need a production request because you already have it in stock | ||
| 2009-01-16 03:53 <X0d_of_N0d> which is actually what you want | ||
| 2009-01-16 03:53 <X0d_of_N0d> or better you just finished producing what the customer ordered | ||
| 2009-01-16 03:54 <X0d_of_N0d> so 1) customer orders the product | ||
| 2009-01-16 03:54 <X0d_of_N0d> 2) system checks to see if the product is already in inventory or there is already something being produced that's not already sold | ||
| 2009-01-16 03:55 <X0d_of_N0d> 3) if something needs to be produced then a "draft production order" is created | ||
| 2009-01-16 03:57 <X0d_of_N0d> hum... | ||
| 2009-01-16 03:57 <vengfulsquirrel> ? | ||
| 2009-01-16 03:58 <X0d_of_N0d> well I was thinking that we'd then schedule the production order... | ||
| 2009-01-16 03:58 <X0d_of_N0d> but in reality you schedule work orders | ||
| 2009-01-16 03:58 <vengfulsquirrel> a production order is really the parent of many work orders as far as i can tell | ||
| 2009-01-16 03:58 <vengfulsquirrel> where a work order is what each workcenter on a routing receives | ||
| 2009-01-16 03:59 <X0d_of_N0d> exactly | ||
| 2009-01-16 03:59 <vengfulsquirrel> for now we are scheduling the production order | ||
| 2009-01-16 03:59 <vengfulsquirrel> which essentially does nothing | ||
| 2009-01-16 03:59 <X0d_of_N0d> right | ||
| 2009-01-16 03:59 <vengfulsquirrel> but in the future it would lay out the routing and pass out work orders | ||
| 2009-01-16 03:59 <X0d_of_N0d> so I guess you don't schedule production orders, you just accept them and they create "draft work orders", which the user then schedules across workcenters | ||
| 2009-01-16 04:00 <vengfulsquirrel> well you can keep rough tracking | ||
| 2009-01-16 04:00 <vengfulsquirrel> think of it as every product has an indepenedent routing with a single workcenter | ||
| 2009-01-16 04:01 <X0d_of_N0d> ? | ||
| 2009-01-16 04:01 <vengfulsquirrel> do schedule a production order would be to schedule each work order | ||
| 2009-01-16 04:01 <X0d_of_N0d> right | ||
| 2009-01-16 04:01 <vengfulsquirrel> *to schedule | ||
| 2009-01-16 04:01 <vengfulsquirrel> So for now to schedule just means you are setting a time to start | ||
| 2009-01-16 04:02 <vengfulsquirrel> and then you start it.. and then you say its done.. and then the product is moved to production output zone | ||
| 2009-01-16 04:02 <X0d_of_N0d> right, and we can make it more granular later | ||
| 2009-01-16 04:02 <vengfulsquirrel> so work orders don't exist right now | ||
| 2009-01-16 04:02 <X0d_of_N0d> ok | ||
| 2009-01-16 04:03 <vengfulsquirrel> i hope that will extend to your system correctly | ||
| 2009-01-16 04:03 <X0d_of_N0d> yeah, that's fine actually | ||
| 2009-01-16 04:03 <X0d_of_N0d> bom revisions.... | ||
| 2009-01-16 04:03 <X0d_of_N0d> we need to figure out bom revisions | ||
| 2009-01-16 04:03 <vengfulsquirrel> if we make bom's readonly i don't see a problem | ||
| 2009-01-16 04:03 <vengfulsquirrel> with it | ||
| 2009-01-16 04:03 <vengfulsquirrel> i mean we can solve it somehow | ||
| 2009-01-16 04:04 <X0d_of_N0d> how do we store them? | ||
| 2009-01-16 04:04 <vengfulsquirrel> that's the only tihng that would seriuosly f' us | ||
| 2009-01-16 04:04 <vengfulsquirrel> the revisions? just copy the entire previuos bom into a Draft Bom with a new version number | ||
| 2009-01-16 04:05 <X0d_of_N0d> so for each rev we just store another copy of the bom in the db? | ||
| 2009-01-16 04:05 <vengfulsquirrel> yeah | ||
| 2009-01-16 04:05 <vengfulsquirrel> but they are single level | ||
| 2009-01-16 04:05 <vengfulsquirrel> *minus phantoms | ||
| 2009-01-16 04:05 <X0d_of_N0d> right | ||
| 2009-01-16 04:05 <vengfulsquirrel> so multiple-level-ish | ||
| 2009-01-16 04:05 <X0d_of_N0d> ehhh | ||
| 2009-01-16 04:05 <vengfulsquirrel> but like each sub-assmelby that is stocked has its own bom | ||
| 2009-01-16 04:06 <X0d_of_N0d> I think they can all be single level | ||
| 2009-01-16 04:06 <vengfulsquirrel> and revisions | ||
| 2009-01-16 04:06 <vengfulsquirrel> oh yeah phantom sub assemblies i guess could be seperate | ||
| 2009-01-16 04:06 <vengfulsquirrel> we have to figure out where to make those | ||
| 2009-01-16 04:07 <X0d_of_N0d> so the layout is like "bom_id, product_id, rev, type, lines" | ||
| 2009-01-16 04:08 <vengfulsquirrel> yeah i don't know i need to read up on postgres sequences | ||
| 2009-01-16 04:08 <X0d_of_N0d> I think phantoms would be different in the product area. | ||
| 2009-01-16 04:08 <vengfulsquirrel> yeah maybe you have to make them in the production management section | ||
| 2009-01-16 04:09 <X0d_of_N0d> why not give them a part number? make them just the same as everything else except that they're phantom boms? | ||
| 2009-01-16 04:10 <vengfulsquirrel> X0d_of_N0d: yeah maybe I have to look into it, you are right though it would need to share some properties which would make it hard to make it seperate | ||
| 2009-01-16 04:10 <X0d_of_N0d> unstockable phantom boms could just have a product type that's like "unstockable" or something | ||
| 2009-01-16 04:10 <vengfulsquirrel> they have consumables | ||
| 2009-01-16 04:10 <X0d_of_N0d> that could work | ||
| 2009-01-16 04:10 <vengfulsquirrel> i'm not sure quite what those are for but maybe yeah we could use that or if it comes to it make another type | ||
| 2009-01-16 04:11 <X0d_of_N0d> exactly | ||
| 2009-01-16 04:11 <vengfulsquirrel> okay though | ||
| 2009-01-16 04:12 <vengfulsquirrel> so all single level | ||
| 2009-01-16 04:12 <vengfulsquirrel> i can't imagine that is really going to be a big problem of storage | ||
| 2009-01-16 04:12 <vengfulsquirrel> copying everything over and over | ||
| 2009-01-16 04:12 <vengfulsquirrel> its just bom lines and a bom container | ||
| 2009-01-16 04:12 <X0d_of_N0d> right | ||
| 2009-01-16 04:12 <X0d_of_N0d> it's not really a lot of text or anything | ||
| 2009-01-16 04:13 <X0d_of_N0d> if it's a problem in the long term we can reorganize it. I think the structure is simple enough that it wouldn't be a problem to do that | ||
| 2009-01-16 04:15 <vengfulsquirrel> So anyways can we go back to the process again | ||
| 2009-01-16 04:15 <vengfulsquirrel> i still don't understand the request part | ||
| 2009-01-16 04:15 <X0d_of_N0d> yeah, where were we? | ||
| 2009-01-16 04:15 <X0d_of_N0d> hum | ||
| 2009-01-16 04:15 <CIA-10> tryton: josh.dukes@microvu.com * r417 /wiki/TrytonMRPIntegration.wiki: Edited wiki page through web user interface. | ||
| 2009-01-16 04:16 <X0d_of_N0d> ACTION looks at CIA-10 | ||
| 2009-01-16 04:16 <vengfulsquirrel> 1 customer sale, 2 fulfill from inventory or fulfill from production 3 create draft production order (requests?) | ||
| 2009-01-16 04:16 <X0d_of_N0d> that's some serious lag | ||
| 2009-01-16 04:16 <vengfulsquirrel> ha yeah there is a lot of lag | ||
| 2009-01-16 04:16 <X0d_of_N0d> ok 4) schedule (activate) the order | ||
| 2009-01-16 04:17 <X0d_of_N0d> a user would activate the order so it can be scheduled in an efficient way rather than having the computer schedule everything at the wrong time or whatever | ||
| 2009-01-16 04:18 <vengfulsquirrel> okay well i kind of feel like maybe the user should decide to fulfill from stock version schedule a production request | ||
| 2009-01-16 04:18 <X0d_of_N0d> hum... so scheduling would actually be "assign" in the terminology | ||
| 2009-01-16 04:19 <X0d_of_N0d> when the order is assigned then virtual stock would be allocated, when the order is run then that stock would actually be moved into the bit /dev/null or whatever | ||
| 2009-01-16 04:20 <X0d_of_N0d> and the product would be pulled out of lost & found and put into "production output" | ||
| 2009-01-16 04:20 <vengfulsquirrel> yeah i kind of feel like that is abusing lost and found, but something like that | ||
| 2009-01-16 04:21 <vengfulsquirrel> i think it actually would be pulled out of the production location | ||
| 2009-01-16 04:21 <vengfulsquirrel> and put into production output | ||
| 2009-01-16 04:21 <vengfulsquirrel> or the shop floor | ||
| 2009-01-16 04:21 <X0d_of_N0d> right | ||
| 2009-01-16 04:21 <X0d_of_N0d> perhaps there could be a production bucket | ||
| 2009-01-16 04:21 <X0d_of_N0d> s/bucket/account/ I guess | ||
| 2009-01-16 04:22 <X0d_of_N0d> you'd have a "used materials" account that stuff would get dumped into | ||
| 2009-01-16 04:22 <X0d_of_N0d> what is the lost and found for? | ||
| 2009-01-16 04:22 <X0d_of_N0d> if it's not for that I mean? | ||
| 2009-01-16 04:23 <vengfulsquirrel> well I don't know but I interpretted it as for when people make mistakes and literally are losing inventory and finding inventory... its like a mistake collector | ||
| 2009-01-16 04:23 <vengfulsquirrel> if your numbers are high in there it means your inventory tracking sucks | ||
| 2009-01-16 04:23 <X0d_of_N0d> ok, then we should't use it | ||
| 2009-01-16 04:24 <vengfulsquirrel> well that was my interpretation i gotta ask cedk or bechamel | ||
| 2009-01-16 04:24 <X0d_of_N0d> isn't there an "inventory loss" account? | ||
| 2009-01-16 04:24 <vengfulsquirrel> a financial account ? | ||
| 2009-01-16 04:24 <X0d_of_N0d> no a location | ||
| 2009-01-16 04:25 <X0d_of_N0d> i meant | ||
| 2009-01-16 04:25 <vengfulsquirrel> i added a mod to do that | ||
| 2009-01-16 04:25 <vengfulsquirrel> for my own purposes | ||
| 2009-01-16 04:25 <vengfulsquirrel> maybe you saw that in an old diagram | ||
| 2009-01-16 04:25 <X0d_of_N0d> I'm pretty sure that's how tinyerp does it | ||
| 2009-01-16 04:25 <vengfulsquirrel> pushes it all into lost and foudn ? | ||
| 2009-01-16 04:26 <X0d_of_N0d> no, there's an inventory loss | ||
| 2009-01-16 04:26 <X0d_of_N0d> manufactured products come out of inventory loss | ||
| 2009-01-16 04:26 <vengfulsquirrel> oh right for when stuff actually is broken | ||
| 2009-01-16 04:26 <vengfulsquirrel> ha oh man | ||
| 2009-01-16 04:26 <vengfulsquirrel> yeah that's what i don't want to do | ||
| 2009-01-16 04:26 <X0d_of_N0d> I dunno | ||
| 2009-01-16 04:26 <vengfulsquirrel> but maybe i'm wrong | ||
| 2009-01-16 04:27 <vengfulsquirrel> anyways | ||
| 2009-01-16 04:27 <X0d_of_N0d> so you're thinking about pulling them out of the shop floor? | ||
| 2009-01-16 04:27 <vengfulsquirrel> yeah and the numbers actually on the shop floor mean nothing | ||
| 2009-01-16 04:27 <vengfulsquirrel> the only numbers that mean anything are the input zone and the output zone | ||
| 2009-01-16 04:27 <X0d_of_N0d> hum... | ||
| 2009-01-16 04:28 <vengfulsquirrel> What do you think ? | ||
| 2009-01-16 04:28 <X0d_of_N0d> it seems like the place where products come from and where materials go should be different | ||
| 2009-01-16 04:29 <X0d_of_N0d> because you might want to run a report that finds out everything you used in production and you could use your "used materials" location for that | ||
| 2009-01-16 04:29 <X0d_of_N0d> likewise you might want to know how many products you made, and you could use your "production something whatever" to generate that | ||
| 2009-01-16 04:29 <vengfulsquirrel> yeah okay so maybe it should be disconnected | ||
| 2009-01-16 04:30 <vengfulsquirrel> consumed, produced | ||
| 2009-01-16 04:30 <X0d_of_N0d> yeah | ||
| 2009-01-16 04:30 <vengfulsquirrel> kind of like customer, supplier | ||
| 2009-01-16 04:30 <X0d_of_N0d> ok | ||
| 2009-01-16 04:30 <vengfulsquirrel> a lot of moves i guess | ||
| 2009-01-16 04:30 <vengfulsquirrel> storage->input->consumed produced->output->storage | ||
| 2009-01-16 04:31 <X0d_of_N0d> I think that's fine | ||
| 2009-01-16 04:31 <vengfulsquirrel> so the shop floor will be split in two | ||
| 2009-01-16 04:31 <vengfulsquirrel> in that diagram | ||
| 2009-01-16 04:31 <X0d_of_N0d> well... | ||
| 2009-01-16 04:31 <vengfulsquirrel> and not named shop floor | ||
| 2009-01-16 04:32 <vengfulsquirrel> ha | ||
| 2009-01-16 04:32 <X0d_of_N0d> maybe there should be a "shop floor" just for inventory tracking... but I guess we can drop it for now | ||
| 2009-01-16 04:34 -!- gremly(n=oscar@190.156.159.130) has joined #tryton | ||
| 2009-01-16 04:34 <X0d_of_N0d> brb | ||
| 2009-01-16 04:35 <vengfulsquirrel> X0d_of_N0d: http://www.laspilitas.com/s/images/stock-production.png | ||
| 2009-01-16 04:38 <X0d_of_N0d> did you update it? | ||
| 2009-01-16 04:39 <X0d_of_N0d> ahh ok | ||
| 2009-01-16 04:39 <X0d_of_N0d> yeah, I like it | ||
| 2009-01-16 04:39 <vengfulsquirrel> great done | ||
| 2009-01-16 04:39 <X0d_of_N0d> ok | ||
| 2009-01-16 04:39 <vengfulsquirrel> until cedk hates it ha | ||
| 2009-01-16 04:40 <X0d_of_N0d> hehe | ||
| 2009-01-16 04:40 <X0d_of_N0d> if he has a better idea then great, we'll impliment it | ||
| 2009-01-16 04:41 <X0d_of_N0d> ok | ||
| 2009-01-16 04:42 <X0d_of_N0d> so do we want to do any more on the roadmap? | ||
| 2009-01-16 04:42 <X0d_of_N0d> I updated it again | ||
| 2009-01-16 04:43 <vengfulsquirrel> Yeah so when I say production requests I mean literally records in the db called production requests, did you think I meant programmed requests to production to create a production order ? | ||
| 2009-01-16 04:43 <X0d_of_N0d> no | ||
| 2009-01-16 04:44 <X0d_of_N0d> I'm with you on that | ||
| 2009-01-16 04:44 <vengfulsquirrel> Okay those aren't mentioned on the road map | ||
| 2009-01-16 04:44 <X0d_of_N0d> ok, lemme get that | ||
| 2009-01-16 04:45 <X0d_of_N0d> at the end? | ||
| 2009-01-16 04:45 <X0d_of_N0d> err nm | ||
| 2009-01-16 04:45 <vengfulsquirrel> have sales orders trigger creation of draft production orders | ||
| 2009-01-16 04:45 <vengfulsquirrel> that just skips of production requests | ||
| 2009-01-16 04:45 <X0d_of_N0d> draft production order == production request | ||
| 2009-01-16 04:46 <vengfulsquirrel> ha okay and there is the confusion | ||
| 2009-01-16 04:46 <X0d_of_N0d> yeah, my bad... | ||
| 2009-01-16 04:47 <X0d_of_N0d> the terminology of mrp, yeah... | ||
| 2009-01-16 04:47 <vengfulsquirrel> so a production order can be draft but that's not the same as a draft production request | ||
| 2009-01-16 04:48 <vengfulsquirrel> How does a sale know it has production requests in the queue and how does a production request know it is being fulfilled by a production order? | ||
| 2009-01-16 04:48 <vengfulsquirrel> I guess many to many .. then many to many . | ||
| 2009-01-16 04:48 <vengfulsquirrel> Right ? | ||
| 2009-01-16 04:48 <vengfulsquirrel> Somehow we will need to tie all those together probably. | ||
| 2009-01-16 04:50 <X0d_of_N0d> there wouldn't be production requests and production orders, production requests are just another term for draft production order | ||
| 2009-01-16 04:51 <vengfulsquirrel> okay the only problem with that is if we every do planning like a billion draft production orders are going to be submitted | ||
| 2009-01-16 04:51 <X0d_of_N0d> production orders would have a one2one field that links to a sales order if one exists | ||
| 2009-01-16 04:51 <X0d_of_N0d> yeah | ||
| 2009-01-16 04:52 <vengfulsquirrel> also what if you have 10 orders for 10 of something and you just want to make one production order of 100 ? | ||
| 2009-01-16 04:52 <X0d_of_N0d> we'd have a draft produciton order for each thing produced... we'd probably want to have some way of collapsing them | ||
| 2009-01-16 04:52 <vengfulsquirrel> can a production order have multiple products on it? | ||
| 2009-01-16 04:53 <X0d_of_N0d> yes | ||
| 2009-01-16 04:53 <vengfulsquirrel> oh sweet jesus | ||
| 2009-01-16 04:53 <vengfulsquirrel> its a good thing we talked about this today | ||
| 2009-01-16 04:53 <X0d_of_N0d> well, that's arbitrary | ||
| 2009-01-16 04:53 <X0d_of_N0d> it's up to us to figure out | ||
| 2009-01-16 04:53 <X0d_of_N0d> if we don't want a ton of production ordres than we need a production order that can have multiple items | ||
| 2009-01-16 04:53 <vengfulsquirrel> well i think that's really confusing for production | ||
| 2009-01-16 04:54 <vengfulsquirrel> or well when we do scheduling | ||
| 2009-01-16 04:54 <vengfulsquirrel> that's impossible | ||
| 2009-01-16 04:54 <X0d_of_N0d> yeah | ||
| 2009-01-16 04:54 <vengfulsquirrel> so one product per production order | ||
| 2009-01-16 04:54 <vengfulsquirrel> so a sales order might generated many production orders | ||
| 2009-01-16 04:54 <vengfulsquirrel> depending on what's not in stock | ||
| 2009-01-16 04:54 <vengfulsquirrel> and then those will be scheduled appropriately by production | ||
| 2009-01-16 04:54 <X0d_of_N0d> the other side of it would be, what if you want to make a run of 100 do-dads based on an order of 100 do-dads | ||
| 2009-01-16 04:55 <X0d_of_N0d> rather than 100 seperate runs of 1 do-dad | ||
| 2009-01-16 04:55 <vengfulsquirrel> oh well there is a quantity | ||
| 2009-01-16 04:55 <vengfulsquirrel> product, quantity | ||
| 2009-01-16 04:55 <X0d_of_N0d> oh, you were thinking like "make product A and B" | ||
| 2009-01-16 04:55 <vengfulsquirrel> i'm more worried of wanted to collapce multiple sale orders for the same product into one production order | ||
| 2009-01-16 04:56 <X0d_of_N0d> yeah, no. one product, one order | ||
| 2009-01-16 04:56 <vengfulsquirrel> which isn't one2one | ||
| 2009-01-16 04:56 <vengfulsquirrel> maybe it should be one2many | ||
| 2009-01-16 04:56 <vengfulsquirrel> ? | ||
| 2009-01-16 04:56 <X0d_of_N0d> vengfulsquirrel: we should do that at some point, but I don't think we need to do that now | ||
| 2009-01-16 04:56 <X0d_of_N0d> yeah | ||
| 2009-01-16 04:56 <X0d_of_N0d> hum... | ||
| 2009-01-16 04:57 <X0d_of_N0d> but then how do we keep track of what's what? I mean, you're running 100 items... you have a list of 50 sales orders | ||
| 2009-01-16 04:57 <vengfulsquirrel> you mean whose item came out damaged? | ||
| 2009-01-16 04:57 <X0d_of_N0d> do you have 50 free to add to other sales orders? or do you have 25? or does each sales order have 2 or what? | ||
| 2009-01-16 04:57 <vengfulsquirrel> friendsies probably | ||
| 2009-01-16 04:58 <X0d_of_N0d> that would be another question | ||
| 2009-01-16 04:58 <vengfulsquirrel> oh gross | ||
| 2009-01-16 04:58 <X0d_of_N0d> ? | ||
| 2009-01-16 04:58 <vengfulsquirrel> yeah i don't know | ||
| 2009-01-16 04:58 <X0d_of_N0d> for now it's one2one | ||
| 2009-01-16 04:58 <vengfulsquirrel> you mean if you can only make 100 but someone order 77 | ||
| 2009-01-16 04:58 <X0d_of_N0d> we can change it later if we want | ||
| 2009-01-16 04:59 <vengfulsquirrel> well honestly i would never use it | ||
| 2009-01-16 04:59 <vengfulsquirrel> so if it works for your business | ||
| 2009-01-16 04:59 <vengfulsquirrel> we only do make to stock | ||
| 2009-01-16 04:59 <vengfulsquirrel> although | ||
| 2009-01-16 04:59 <X0d_of_N0d> yeah, we'll just impliment what we need and worry about other stuff later | ||
| 2009-01-16 04:59 <vengfulsquirrel> TONIGHT i'm going to send an email out asking for feedback | ||
| 2009-01-16 04:59 <vengfulsquirrel> and maybe some other people will get interested | ||
| 2009-01-16 05:00 <vengfulsquirrel> cedk and bechamel both wanted me to do that I think | ||
| 2009-01-16 05:00 <X0d_of_N0d> it would be cool to get more feedback | ||
| 2009-01-16 05:00 <vengfulsquirrel> but yeah one2one | ||
| 2009-01-16 05:00 <vengfulsquirrel> for now | ||
| 2009-01-16 05:00 <X0d_of_N0d> right | ||
| 2009-01-16 05:01 <vengfulsquirrel> and production requests don't exist | ||
| 2009-01-16 05:01 <X0d_of_N0d> ACTION nods | ||
| 2009-01-16 05:01 <vengfulsquirrel> great | ||
| 2009-01-16 05:01 <X0d_of_N0d> yes | ||
| 2009-01-16 05:01 <vengfulsquirrel> so much progress its like were almost done | ||
| 2009-01-16 05:01 <X0d_of_N0d> yeah, almost ready to start | ||
| 2009-01-16 05:01 <X0d_of_N0d> lol | ||
| 2009-01-16 05:01 <vengfulsquirrel> ha yeah seriuosly | ||
| 2009-01-16 05:01 <vengfulsquirrel> i have to add some plant addon too | ||
| 2009-01-16 05:02 <vengfulsquirrel> which is why i need to start soon | ||
| 2009-01-16 05:02 <vengfulsquirrel> so i can addon to SOMETHING | ||
| 2009-01-16 05:02 <vengfulsquirrel> ha | ||
| 2009-01-16 05:03 <X0d_of_N0d> I've got some other work to do here, but I'll try to help you out as soon as I can... and I'm always open for you to send me code or ask questions if you need any help or anything | ||
| 2009-01-16 05:03 <X0d_of_N0d> sound fair? | ||
| 2009-01-16 05:04 <vengfulsquirrel> Yeah that's fine for phase one and a while into planning but eventually i'll have to be a least splitting the coding. | ||
| 2009-01-16 05:04 <vengfulsquirrel> *at | ||
| 2009-01-16 05:04 <vengfulsquirrel> Have you done customizations on openerp ? | ||
| 2009-01-16 05:05 <X0d_of_N0d> yeah, no problem, when you're side is done I | ||
| 2009-01-16 05:05 <X0d_of_N0d> I'll take over | ||
| 2009-01-16 05:05 <X0d_of_N0d> most of my work with openerp has been under the hood | ||
| 2009-01-16 05:05 <X0d_of_N0d> I'm trying to learn more about tryton, which looks like it's a lot easier to work with | ||
| 2009-01-16 05:06 <vengfulsquirrel> yeah its a lot easier to install | ||
| 2009-01-16 05:06 <X0d_of_N0d> and has way better documentation | ||
| 2009-01-16 05:06 <X0d_of_N0d> and the directory structure is better, the code is cleaner... etc | ||
| 2009-01-16 05:07 <vengfulsquirrel> Yeah it definately seems cleaner which is why i thought i'd start using it since i have no experience with either. | ||
| 2009-01-16 05:08 <X0d_of_N0d> tinyerp seems to slowly be getting worse on a lot of levels... | ||
| 2009-01-16 05:08 <X0d_of_N0d> well, yeah, whatever | ||
| 2009-01-16 05:08 <vengfulsquirrel> I think they took a lot of time to move over to that trac-like software which might have set them back a bit. | ||
| 2009-01-16 05:09 <vengfulsquirrel> but yeah I don't know hopefully things work out for both groups | ||
| 2009-01-16 05:10 <vengfulsquirrel> Anyways so | ||
| 2009-01-16 05:10 <X0d_of_N0d> yeah | ||
| 2009-01-16 05:10 <vengfulsquirrel> I'm going to put up the location diagram | ||
| 2009-01-16 05:10 <X0d_of_N0d> cool | ||
| 2009-01-16 05:10 <vengfulsquirrel> into g-code | ||
| 2009-01-16 05:10 <X0d_of_N0d> and modify the bom structure diagram? | ||
| 2009-01-16 05:10 <vengfulsquirrel> and ughh maybe clean up the bom christmas tree | ||
| 2009-01-16 05:10 <X0d_of_N0d> yeah | ||
| 2009-01-16 05:10 <vengfulsquirrel> and then move the road map to the top | ||
| 2009-01-16 05:11 <X0d_of_N0d> ok | ||
| 2009-01-16 05:11 <vengfulsquirrel> and maybe make it more sentence like and then clean up the feature list a bit | ||
| 2009-01-16 05:11 <X0d_of_N0d> ok | ||
| 2009-01-16 05:11 <X0d_of_N0d> cool | ||
| 2009-01-16 05:11 <vengfulsquirrel> are the comments still applicable? | ||
| 2009-01-16 05:12 <X0d_of_N0d> the notes thing? | ||
| 2009-01-16 05:12 <vengfulsquirrel> your notes | ||
| 2009-01-16 05:12 <vengfulsquirrel> i think the second and third one are solved | ||
| 2009-01-16 05:12 <vengfulsquirrel> the first one always confused me | ||
| 2009-01-16 05:12 <X0d_of_N0d> the last two can be dropped | ||
| 2009-01-16 05:12 <X0d_of_N0d> hum... | ||
| 2009-01-16 05:12 <X0d_of_N0d> lets see | ||
| 2009-01-16 05:13 <X0d_of_N0d> rather than having workcenters we could have resources that contain workcenters | ||
| 2009-01-16 05:13 <vengfulsquirrel> Oh hmm | ||
| 2009-01-16 05:13 <X0d_of_N0d> that way things could be scheduled across multiple workcenters | ||
| 2009-01-16 05:13 <vengfulsquirrel> yeah i was thinking of making groups of workcenters and tieing a routing operation to a group | ||
| 2009-01-16 05:14 <vengfulsquirrel> so then it could be chosen within that group | ||
| 2009-01-16 05:14 <X0d_of_N0d> exactly | ||
| 2009-01-16 05:14 <vengfulsquirrel> is that what you mean? | ||
| 2009-01-16 05:14 <vengfulsquirrel> okay | ||
| 2009-01-16 05:14 <X0d_of_N0d> yeah | ||
| 2009-01-16 05:14 <vengfulsquirrel> yeah so i think being explicitly about the workcenter might be required | ||
| 2009-01-16 05:14 <vengfulsquirrel> and doing resources seperately | ||
| 2009-01-16 05:14 <vengfulsquirrel> like trucks/tools or whatever | ||
| 2009-01-16 05:14 <vengfulsquirrel> is that what a resource is ? | ||
| 2009-01-16 05:15 <X0d_of_N0d> I was just thinking about a term to use | ||
| 2009-01-16 05:19 -!- X0d_of_N0d(i=user@gateway/tor/x-5c95cd63f0af1d20) has joined #tryton | ||
| 2009-01-16 05:19 -!- vengfulsquirrel(n=ian@c-71-202-125-182.hsd1.ca.comcast.net) has joined #tryton | ||
| 2009-01-16 05:19 -!- CIA-10(n=CIA@208.69.182.149) has joined #tryton | ||
| 2009-01-16 05:19 -!- johbo(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton | ||
| 2009-01-16 05:19 -!- panthera(n=daniel@unable-to-package.org) has joined #tryton | ||
| 2009-01-16 05:26 -!- yangoon(n=mathiasb@p549F7EE6.dip.t-dialin.net) has joined #tryton | ||
| 2009-01-16 05:26 -!- X0d_of_N0d(i=user@gateway/tor/x-5c95cd63f0af1d20) has joined #tryton | ||
| 2009-01-16 05:26 -!- vengfulsquirrel(n=ian@c-71-202-125-182.hsd1.ca.comcast.net) has joined #tryton | ||
| 2009-01-16 05:26 -!- CIA-10(n=CIA@208.69.182.149) has joined #tryton | ||
| 2009-01-16 05:26 -!- johbo(n=joh@statdsl-085-016-072-173.ewe-ip-backbone.de) has joined #tryton | ||
| 2009-01-16 05:26 -!- panthera(n=daniel@unable-to-package.org) has joined #tryton | ||
| 2009-01-16 05:27 <vengfulsquirrel> X0d_of_N0d: Did I just drop? What if people don't want to make to order? | ||
| 2009-01-16 05:27 <X0d_of_N0d> brb | ||
| 2009-01-16 05:53 <vengfulsquirrel> Wow another problem is I think we need to break this up into more cohesive modules. | ||
| 2009-01-16 06:21 -!- gremly(n=oscar@190.156.159.130) has joined #tryton | ||
| 2009-01-16 06:43 <X0d_of_N0d> people might want to track that stuff down, but we don't need to worry about that right now | ||
| 2009-01-16 06:48 <X0d_of_N0d> if people want to make to stock you could manually generate the production orders | ||
| 2009-01-16 06:50 <X0d_of_N0d> I'm heading home | ||
| 2009-01-16 06:50 <X0d_of_N0d> we'll talk tomorrow | ||
| 2009-01-16 06:51 <vengfulsquirrel> okay talk to you then | ||
| 2009-01-16 06:52 -!- vengfulsquirrel(n=ian@c-71-202-125-182.hsd1.ca.comcast.net) has left #tryton | ||
| 2009-01-16 06:52 -!- vengfulsquirrel(n=ian@c-71-202-125-182.hsd1.ca.comcast.net) has joined #tryton | ||
| 2009-01-16 07:13 <CIA-10> tryton: vengfulsquirrel * r420 /wiki/TrytonMRPIntegration.wiki: Edited wiki page through web user interface. | ||
| 2009-01-16 07:26 <vengfulsquirrel> Has anyone successfully uploaded images to the wiki? | ||
| 2009-01-16 08:22 -!- Timitos(n=Timitos@88.217.184.172) has joined #tryton | ||
| 2009-01-16 08:41 <vengfulsquirrel> Timitos: Are you able to checkout the wiki ? | ||
| 2009-01-16 08:42 <vengfulsquirrel> Timitos: Or do you know how I should display a photo, that's what I was trying to do. | ||
| 2009-01-16 09:28 -!- nicoe(n=nicoe@ip-80-236-225-36.dsl.scarlet.be) has joined #tryton | ||
| 2009-01-16 09:30 -!- carlos(n=carlos@89.7.24.44) has joined #tryton | ||
| 2009-01-16 09:49 -!- enlightx(n=enlightx@82.112.213.114) has joined #tryton | ||
| 2009-01-16 10:08 -!- simahawk(n=simao@217.202.158.251) has joined #tryton | ||
| 2009-01-16 10:08 -!- simao_(n=simao@217.202.158.251) has joined #tryton | ||
| 2009-01-16 10:15 <CIA-10> tryton: vengfulsquirrel * r421 /wiki/TrytonMRPIntegration.wiki: Updated wiki page text and externally linked to some figures until they can be uploaded somewhere officially. | ||
| 2009-01-16 10:19 -!- bechamel(n=user@85.201.86.139) has joined #tryton | ||
| 2009-01-16 10:27 -!- carlos(n=carlos@229.Red-83-49-174.dynamicIP.rima-tde.net) has joined #tryton | ||
| 2009-01-16 10:53 -!- cristi_an(i=5978d3ce@gateway/web/ajax/mibbit.com/x-b8b6a4fdb62db0cb) has joined #tryton | ||
| 2009-01-16 10:58 -!- cristi_an(i=5978d3ce@gateway/web/ajax/mibbit.com/x-b8b6a4fdb62db0cb) has left #tryton | ||
| 2009-01-16 11:04 -!- cristi_an(n=cristi@89.120.211.206) has joined #tryton | ||
| 2009-01-16 11:06 <cristi_an> bechamel: in the party menu | ||
| 2009-01-16 11:07 <cristi_an> if i install only that module | ||
| 2009-01-16 11:08 <cristi_an> the menu looks like this Parties/New Party Adresses/new Addess but on category | ||
| 2009-01-16 11:08 <cristi_an> there are edit and new | ||
| 2009-01-16 11:08 <cristi_an> ? | ||
| 2009-01-16 11:08 <cristi_an> what is the reason not having edit on address or party as well ? | ||
| 2009-01-16 11:10 <bechamel> cristi_an: there is no technical reason, just end user considerations | ||
| 2009-01-16 11:11 <bechamel> cristi_an: actually there is edit for party and adress too, it's just the name | ||
| 2009-01-16 11:12 <bechamel> cristi_an: the idea is that once created, there are no big changes on categories, so the defaut menu just open the tree of categories | ||
| 2009-01-16 11:12 <cristi_an> sao only logical and application reasons | ||
| 2009-01-16 11:13 <cristi_an> thx | ||
| 2009-01-16 11:13 <bechamel> yes | ||
| 2009-01-16 11:18 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
| 2009-01-16 11:19 -!- Gedd(n=ged@77.109.114.225.adsl.dyn.edpnet.net) has joined #tryton | ||
| 2009-01-16 11:31 <cristi_an> the csv for translation is stored in the db ? | ||
| 2009-01-16 11:33 <cedk> cristi_an: yes in ir.translation | ||
| 2009-01-16 11:33 <cristi_an> the content from csv | ||
| 2009-01-16 11:34 <cedk> cristi_an: yes, you can look in ir/translation.py there is two function for import and export | ||
| 2009-01-16 11:36 <cristi_an> http://code.google.com/p/tryton/wiki/HowtoTranslate | ||
| 2009-01-16 11:37 <cristi_an> i will follwow this | ||
| 2009-01-16 11:53 <cristi_an> how can i specify a model filed is unique ? | ||
| 2009-01-16 11:56 <bechamel> http://www.tryton.org/doc/branches/1.0/trytond/doc/models.html#model-properties | ||
| 2009-01-16 11:58 <bechamel> read explanation about _sql_constraints, and a "grep UNIQUE modules/*/*py" should give you some examples | ||
| 2009-01-16 12:16 -!- gremly(n=oscar@190.156.159.130) has joined #tryton | ||
| 2009-01-16 12:21 <cristi_an> in a custom scenario | ||
| 2009-01-16 12:21 <cristi_an> is possible to ad the shortcuts on new save delete | ||
| 2009-01-16 12:22 <cristi_an> on the buttons ? | ||
| 2009-01-16 12:23 <cedk> cristi_an: there is (CTRL+N, CTRL+S, CTRL+D) | ||
| 2009-01-16 12:23 <cedk> cristi_an: and you can change it if you want | ||
| 2009-01-16 12:24 <cristi_an> maybe a wizzard on the the begging informing the user this shortcuts ? | ||
| 2009-01-16 12:24 <cedk> cristi_an: go in the menu form, put the cursor on one entry and type the new shortcut | ||
| 2009-01-16 12:24 <cristi_an> or tip | ||
| 2009-01-16 12:24 <cedk> cristi_an: it is on the menubar | ||
| 2009-01-16 12:25 <cedk> cristi_an: but we can add a tip on how customize shortcuts | ||
| 2009-01-16 12:25 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 1159:12ca894689c6 tryton/TODO: Add todo tip | ||
| 2009-01-16 12:29 <cristi_an> cedk: you tal about shortcuts in the left bottm side of the application ? | ||
| 2009-01-16 12:30 <cedk> cristi_an: no | ||
| 2009-01-16 12:30 <cedk> cristi_an: this is what we call actions | ||
| 2009-01-16 12:30 <cristi_an> actiosn indeeed | ||
| 2009-01-16 12:30 <cristi_an> new ,delete,update | ||
| 2009-01-16 12:31 <cristi_an> where is that menu form ? | ||
| 2009-01-16 12:34 -!- paola(n=paola@host-84-223-76-195.cust-adsl.tiscali.it) has joined #tryton | ||
| 2009-01-16 12:35 <cedk> cristi_an: on top with File, User, ... | ||
| 2009-01-16 12:36 <cristi_an> cedk: there is no menu form :) | ||
| 2009-01-16 12:36 <cristi_an> W* | ||
| 2009-01-16 12:36 <cristi_an> w8 | ||
| 2009-01-16 12:36 <cristi_an> i got it | ||
| 2009-01-16 12:36 <cristi_an> :) | ||
| 2009-01-16 12:36 <cristi_an> my mistake | ||
| 2009-01-16 12:37 <cristi_an> so in the menu go to form .... | ||
| 2009-01-16 12:37 <cristi_an> :)) | ||
| 2009-01-16 12:37 <cristi_an> nice features :) | ||
| 2009-01-16 12:38 <cristi_an> one more thing : i am in the party and there i may add more addresses to the same party | ||
| 2009-01-16 12:38 <cristi_an> is possible to use only key without mouse for doing that ? | ||
| 2009-01-16 12:38 <cristi_an> to add more addreses to the same party | ||
| 2009-01-16 12:38 <cristi_an> ? | ||
| 2009-01-16 12:40 <cedk> cristi_an: press F3 when the cursor is in the address form | ||
| 2009-01-16 12:40 <cedk> cristi_an: for many widgets, F3 = new record and F2 = open in popup | ||
| 2009-01-16 12:43 <CIA-10> tryton: cristi roundup * #750/ValueError: list.index(x): x not in list: [new] Traceback (most recent call last): File "/tryton/gui/window/view_form/view/form_gtk/one2many.py", line 505, in switch_view self.screen ... | ||
| 2009-01-16 12:58 -!- carlos(n=carlos@90.Red-79-146-24.dynamicIP.rima-tde.net) has joined #tryton | ||
| 2009-01-16 13:00 <cristi_an> cedk: just as feature , i do not knwo fi is possible but i ask: when i am in address or in other entity that is part of a major enitty like party has address | ||
| 2009-01-16 13:00 <cristi_an> is not possible to use the same keys | ||
| 2009-01-16 13:00 <cristi_an> ctrl-n | ||
| 2009-01-16 13:00 <cristi_an> ctrl-s | ||
| 2009-01-16 13:00 <cristi_an> etc | ||
| 2009-01-16 13:00 <cristi_an> when i am isside of an address filed (or in an addres (subentity) ) from | ||
| 2009-01-16 13:01 <cristi_an> not a good idea...!!! | ||
| 2009-01-16 13:01 <cristi_an> since then it colide with main enity | ||
| 2009-01-16 13:01 <cristi_an> sorry | ||
| 2009-01-16 13:02 <cristi_an> so if i wnt to save the main entity i have to go back ....etc... | ||
| 2009-01-16 13:02 <cristi_an> f3 is ok | ||
| 2009-01-16 13:07 <CIA-10> tryton: ced roundup * #750/ValueError: list.index(x): x not in list: [chatting] How to reproduce the issue? | ||
| 2009-01-16 13:24 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 1160:3857162e79e1 tryton/TODO: Add todo for domain | ||
| 2009-01-16 13:24 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 1161:a09192ff677e tryton/tryton/common/date_widget.py: Backed out changeset 2c78e37cc65b | ||
| 2009-01-16 13:24 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 1162:e54e863441bc tryton/: merge | ||
| 2009-01-16 13:31 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 323:f450c400af79 account/account.py: Fix name_search when args is None | ||
| 2009-01-16 13:33 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 36:58a21f317d9a analytic_purchase/COPYRIGHT: Update copyright | ||
| 2009-01-16 13:33 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 37:958a78b1b8b4 analytic_purchase/purchase.py: Fix read of not line type | ||
| 2009-01-16 13:33 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 38:5634a1a7af3f analytic_purchase/purchase.py: Fix check_for_quotation for not line type for issue741 | ||
| 2009-01-16 13:33 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 36:ffc70a684fdb analytic_invoice/COPYRIGHT: Update copyright | ||
| 2009-01-16 13:33 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 37:9382d7cbb69e analytic_invoice/invoice.py: Fix read for not line type | ||
| 2009-01-16 13:33 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 25:1b6c725dd316 analytic_sale/COPYRIGHT: Update copyright | ||
| 2009-01-16 13:33 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 26:75fdfc9e0624 analytic_sale/sale.py: Fix read of not line type | ||
| 2009-01-16 13:34 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 390:75778376c711 stock/location.py: Improve test on product in context and fix some guidelines | ||
| 2009-01-16 13:34 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 391:799af538e975 stock/product.py: Fix typo in pick_product consumable for issue736 | ||
| 2009-01-16 13:34 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 392:f26e3ef6ca5f stock/COPYRIGHT: Update copyright | ||
| 2009-01-16 13:42 <CIA-10> tryton: Mathias Behrle <mathiasb@behrle.dyndns.org> default * 106:d23b1063afc2 sale/sale.py: Add comments on sale lines | ||
| 2009-01-16 14:43 <yangoon> cedk: since you added additional notebooks to purchase/sale/invoice lines: what is the notion of the additional comments, that can now be joined to positions? | ||
| 2009-01-16 14:43 <yangoon> cedk: are they meant for internal use of the enterprise or are they meant for printing? | ||
| 2009-01-16 14:45 <cedk> yangoon: there are not printed, so it is for internal comments | ||
| 2009-01-16 14:45 <yangoon> cedk: ok | ||
| 2009-01-16 14:45 <yangoon> cedk: just wanted to know, if reports would have to be extended to print them | ||
| 2009-01-16 14:46 <cedk> yangoon: no I don't think so | ||
| 2009-01-16 14:46 <yangoon> cedk: but it is better this way, yes | ||
| 2009-01-16 14:46 -!- carlos_(n=carlos@224.Red-83-49-172.dynamicIP.rima-tde.net) has joined #tryton | ||
| 2009-01-16 14:47 <yangoon> for printed comments a comment line can be inserted | ||
| 2009-01-16 14:48 <yangoon> cedk: perhaps the notebook should be called 'notes' instead of 'comment', to avoid confusion? | ||
| 2009-01-16 14:50 <cedk> yangoon: I don't think it will change anything | ||
| 2009-01-16 14:51 <yangoon> cedk: from the point of the user yes | ||
| 2009-01-16 14:51 <yangoon> it is then different from line type comment | ||
| 2009-01-16 14:51 <cedk> yangoon: I don't see any | ||
| 2009-01-16 14:52 <yangoon> and notes has a more private meaning, so a user won't be surprised to see them not being printed | ||
| 2009-01-16 14:53 <yangoon> cedk: there will surely be questions, why comment here and why comment there, is it the same or not | ||
| 2009-01-16 14:53 <yangoon> cedk: and if we are total logic, why not comments for comments ;)? | ||
| 2009-01-16 14:55 <yangoon> cedk: last sentence means, why isn't it possible to add comments to comments? (only a question of logic, not of usability) | ||
| 2009-01-16 14:57 <yangoon> cedk: to explain again: the user sees he can input a comment, and then notebook comment is empty | ||
| 2009-01-16 14:58 <cedk> yangoon: ok, but so we must rename the field into note | ||
| 2009-01-16 14:59 <cedk> because it will be confusing for programmers also | ||
| 2009-01-16 14:59 <yangoon> cedk: will that change also line type into note? | ||
| 2009-01-16 15:00 <cedk> this needs a little migration | ||
| 2009-01-16 15:00 <yangoon> cedk: I see, but I think it is worth | ||
| 2009-01-16 15:00 <cedk> yangoon: no, because of your remarks | ||
| 2009-01-16 15:00 <cedk> yangoon: I don't understand | ||
| 2009-01-16 15:01 <yangoon> cedk what I would like to see: | ||
| 2009-01-16 15:02 <yangoon> cedk: line type comment for input of comments (no need for notes/comments on comments, but OTOH why not?) | ||
| 2009-01-16 15:02 <yangoon> cedk: and notebooks General and Notes, notes containing notes | ||
| 2009-01-16 15:04 <cedk> yangoon: that is what I say | ||
| 2009-01-16 15:05 <yangoon> cedk: then we agree perfectly | ||
| 2009-01-16 15:05 <cedk> and that why I say we must change the field comment into note | ||
| 2009-01-16 15:07 <yangoon> cedk: perhaps even better to enable notes on comment lines to have the same layout for all line types? | ||
| 2009-01-16 15:08 <cedk> yes no change on this | ||
| 2009-01-16 15:08 <yangoon> cedk: so the user experiences in general, notes are being kept private and totally different from comments | ||
| 2009-01-16 15:09 <yangoon> cedk: this would be a chnange, because currently it is not possible to put comments(notes) on comment lines (notebook comment is empty) | ||
| 2009-01-16 15:09 <cedk> yes | ||
| 2009-01-16 15:10 <yangoon> ok, great | ||
| 2009-01-16 15:10 <cedk> yangoon: ho, yes but there is two possibility: hide the tab or don't hide the field | ||
| 2009-01-16 15:12 <yangoon> cedk: yes, I think notes on comments will be rarely used, but perhaps there is some case where it could be useful, so I would rather enable | ||
| 2009-01-16 15:12 <cedk> ok | ||
| 2009-01-16 15:14 -!- ikks(n=igor@201.244.188.98) has joined #tryton | ||
| 2009-01-16 15:16 -!- juanfer(n=juanfer@201.244.188.98) has joined #tryton | ||
| 2009-01-16 16:20 -!- cristi_an(n=cristi@89.120.211.206) has joined #tryton | ||
| 2009-01-16 16:43 <cristi_an> http://groups.google.com/group/tryton/browse_thread/thread/7371e5f575768ab3 | ||
| 2009-01-16 17:11 -!- carlos(n=carlos@89.7.24.44) has joined #tryton | ||
| 2009-01-16 17:27 -!- simahawk(n=simao@217.201.199.43) has joined #tryton | ||
| 2009-01-16 17:45 -!- tekknokrat(n=gthieleb@dslb-088-074-131-027.pools.arcor-ip.net) has joined #tryton | ||
| 2009-01-16 18:20 -!- carlos(n=carlos@89.7.24.44) has joined #tryton | ||
| 2009-01-16 18:38 -!- mrcast1(n=mrcast@host227-13-dynamic.40-79-r.retail.telecomitalia.it) has joined #tryton | ||
| 2009-01-16 18:47 -!- mrcast1(n=mrcast@host227-13-dynamic.40-79-r.retail.telecomitalia.it) has left #tryton | ||
| 2009-01-16 18:51 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 1468:9e28711f7063 trytond/TODO: Remove todo | ||
| 2009-01-16 18:51 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 429:e1260a0fd1f7 stock/move.py: Add on_change_uom to handle unit_price and don't round unit_price when calling currency.compute | ||
| 2009-01-16 19:07 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 213:f4c273abc781 purchase/ (purchase.py purchase.xml): Rename comment into note because there is now a comment type | ||
| 2009-01-16 19:07 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 107:70a335ea2748 sale/ (sale.py sale.xml): Rename comment into note because there is a comment type | ||
| 2009-01-16 19:09 -!- vengfulsquirrel(n=ian@c-71-202-125-182.hsd1.ca.comcast.net) has joined #tryton | ||
| 2009-01-16 19:38 -!- paola(n=paola@host-84-223-76-195.cust-adsl.tiscali.it) has joined #tryton | ||
| 2009-01-16 19:38 <X0d_of_N0d> ACTION looks around | ||
| 2009-01-16 19:38 <X0d_of_N0d> vengfulsquirrel: hey | ||
| 2009-01-16 19:38 <vengfulsquirrel> hey | ||
| 2009-01-16 19:39 <vengfulsquirrel> How's it going ? | ||
| 2009-01-16 19:39 <X0d_of_N0d> sorry about kind of dropping yesterday, my manager's brother started talking to me about some stuff | ||
| 2009-01-16 19:39 <X0d_of_N0d> not bad, just looking at the wiki page | ||
| 2009-01-16 19:40 <X0d_of_N0d> at a glance it looks pretty good | ||
| 2009-01-16 19:40 <vengfulsquirrel> yeah that's fine, I think we made some headway | ||
| 2009-01-16 19:40 <vengfulsquirrel> yeah the feature list is kind of a mess | ||
| 2009-01-16 19:40 <X0d_of_N0d> definitely | ||
| 2009-01-16 19:40 <X0d_of_N0d> lemme look at it for a bit, I just kind of skimmed it | ||
| 2009-01-16 19:40 <vengfulsquirrel> cedk: Is there a way to upload images to the wiki? | ||
| 2009-01-16 19:48 -!- cristi_an(i=5978d3ce@gateway/web/ajax/mibbit.com/x-a6cccbc5b426cc53) has joined #tryton | ||
| 2009-01-16 19:55 -!- tekknokrat(n=gthieleb@dslb-088-074-131-027.pools.arcor-ip.net) has left #tryton | ||
| 2009-01-16 19:55 <X0d_of_N0d> vengfulsquirrel: inventory shouldn't be consumed until a job run is complete | ||
| 2009-01-16 19:56 <vengfulsquirrel> well if its being used on the production line i assume that its consumed | ||
| 2009-01-16 19:56 <X0d_of_N0d> vengfulsquirrel: maybe if the job is canceled the user should put in how much material was actually used... | ||
| 2009-01-16 19:57 <X0d_of_N0d> right, but production could start then be canceled with all or most of the material still intact | ||
| 2009-01-16 19:58 <vengfulsquirrel> Yeah how often does that happen ? | ||
| 2009-01-16 20:00 <X0d_of_N0d> not very often, but if it did happen you'd have to manually pull stuff out of consumed which would be a huge pain | ||
| 2009-01-16 20:00 <vengfulsquirrel> Maybe there should be an expected, used quantity for each material. | ||
| 2009-01-16 20:00 <vengfulsquirrel> That is pre-filled based on the bom | ||
| 2009-01-16 20:01 <vengfulsquirrel> and then can be adjusted at the end of the run. | ||
| 2009-01-16 20:01 <vengfulsquirrel> Ha and then we can add 40,000 more moves. | ||
| 2009-01-16 20:01 <X0d_of_N0d> hum | ||
| 2009-01-16 20:02 <X0d_of_N0d> brb | ||
| 2009-01-16 20:09 <X0d_of_N0d> back | ||
| 2009-01-16 20:14 <vengfulsquirrel> Did you see cedk's email on the list ? | ||
| 2009-01-16 20:14 <X0d_of_N0d> no, i didn't | ||
| 2009-01-16 20:14 -!- evernichon(n=evernich@AToulouse-256-1-7-107.w90-38.abo.wanadoo.fr) has joined #tryton | ||
| 2009-01-16 20:14 <vengfulsquirrel> What do you think about creating production orders in a similar way to how purchase requests are created with the stock_supply module ? | ||
| 2009-01-16 20:15 <X0d_of_N0d> I'll have to look at the code | ||
| 2009-01-16 20:16 <X0d_of_N0d> I think the workflow would be similar, so I don't see anything wrong with that idea | ||
| 2009-01-16 20:17 <X0d_of_N0d> I think the workflow for production should be the same as the workflow for sales and purchasing | ||
| 2009-01-16 20:18 <vengfulsquirrel> Yeah okay I guess it doesn't seem like there will be a clear connection between sales and production orders. Is that what we want? | ||
| 2009-01-16 20:19 <X0d_of_N0d> there does need to be a connection, but if we can do something manually we can do it automatically | ||
| 2009-01-16 20:20 <X0d_of_N0d> ACTION looks more at the code | ||
| 2009-01-16 20:21 <X0d_of_N0d> hum... | ||
| 2009-01-16 20:25 -!- sharkcz(n=dan@plz1-v-4-17.static.adsl.vol.cz) has joined #tryton | ||
| 2009-01-16 20:29 <X0d_of_N0d> vengfulsquirrel: if we start off and there's no link between sales and production I think that's fine because we can add it later, do you see any problem with doing things that way? | ||
| 2009-01-16 20:30 <vengfulsquirrel> Just as long as I can turn it off | ||
| 2009-01-16 20:30 <cedk> vengfulsquirrel: I think you must add it with subversion | ||
| 2009-01-16 20:30 <vengfulsquirrel> cedk: I tried to checkout but its not working. | ||
| 2009-01-16 20:30 <cedk> vengfulsquirrel: in the wiki directory | ||
| 2009-01-16 20:30 <vengfulsquirrel> wiki/images ? | ||
| 2009-01-16 20:30 <X0d_of_N0d> we'll decide how to make that work when we're ready to figure out how to link the two | ||
| 2009-01-16 20:31 <vengfulsquirrel> X0d_of_N0d: Do you usually stock configured products? | ||
| 2009-01-16 20:31 <X0d_of_N0d> I think we make configured products to order | ||
| 2009-01-16 20:32 <X0d_of_N0d> or we stock a base assembly that can be configured, but usually we make to order | ||
| 2009-01-16 20:32 <X0d_of_N0d> afaik | ||
| 2009-01-16 20:34 <vengfulsquirrel> X0d_of_N0d: Yeah that's a problem right there, if configured products are inventoried they must be somehow stored uniquely. | ||
| 2009-01-16 20:35 <vengfulsquirrel> X0d_of_N0d: Or never stored in inventory for longer than production can make them and move them to the customer. | ||
| 2009-01-16 20:36 <X0d_of_N0d> In the current system we use configured boms have their own part numbers | ||
| 2009-01-16 20:36 <vengfulsquirrel> Each configuration? Or each configured bom ? | ||
| 2009-01-16 20:36 <X0d_of_N0d> each configuration | ||
| 2009-01-16 20:36 <X0d_of_N0d> I don't feel like that's the right way to do it though | ||
| 2009-01-16 20:38 <X0d_of_N0d> then again, we can't really link a configurable bom to a specific part number because each different configuration should have a unique part number... | ||
| 2009-01-16 20:38 <X0d_of_N0d> hum | ||
| 2009-01-16 20:39 <X0d_of_N0d> unless configurations *don't* have unique part numbers... | ||
| 2009-01-16 20:39 <X0d_of_N0d> but then we need some other way to store the configuration information | ||
| 2009-01-16 20:41 <vengfulsquirrel> yeah and then if the revision changes... | ||
| 2009-01-16 20:41 <vengfulsquirrel> new part numbers for everyone! | ||
| 2009-01-16 20:41 -!- enlightx(n=enlightx@host-84-220-86-72.cust-adsl.tiscali.it) has joined #tryton | ||
| 2009-01-16 20:41 -!- enlightx(n=enlightx@host-84-220-86-72.cust-adsl.tiscali.it) has joined #tryton | ||
| 2009-01-16 20:42 <X0d_of_N0d> no, revisions wouldn't change the part number | ||
| 2009-01-16 20:42 <X0d_of_N0d> that's the point of revisions | ||
| 2009-01-16 20:43 <X0d_of_N0d> we could use a numbering scheme to make virtual part numbers | ||
| 2009-01-16 20:44 <X0d_of_N0d> e.g.: a configurable bom has a part number 123 | ||
| 2009-01-16 20:44 <vengfulsquirrel> I meant the configuration part numbers would change if that configuration was different or completely removed. | ||
| 2009-01-16 20:44 <X0d_of_N0d> right | ||
| 2009-01-16 20:45 <X0d_of_N0d> but that's where revs come in | ||
| 2009-01-16 20:47 <X0d_of_N0d> wow...that really sucks | ||
| 2009-01-16 20:47 <vengfulsquirrel> Which one? | ||
| 2009-01-16 20:47 <X0d_of_N0d> storing config'd bom info if the configurable bom itself changes | ||
| 2009-01-16 20:50 <X0d_of_N0d> I wish we had more systems to look at to figure out how other people did this | ||
| 2009-01-16 20:50 <vengfulsquirrel> I think this is always a problem of the ages. | ||
| 2009-01-16 20:51 <X0d_of_N0d> yeah | ||
| 2009-01-16 20:51 <vengfulsquirrel> Similar to the colors/sizes stuff. No one wants to maintain them all but everyone wants to reap the benefits of having them seperate. | ||
| 2009-01-16 20:51 <X0d_of_N0d> right | ||
| 2009-01-16 20:53 <vengfulsquirrel> Hmm yeah but any product that is configured needs to have a bom tracking tree pretty much. | ||
| 2009-01-16 20:55 <X0d_of_N0d> yeah, or something | ||
| 2009-01-16 20:56 <X0d_of_N0d> I'm sending the wiki stuff to my boss to have him take a look at it and see if he catches anything I missed | ||
| 2009-01-16 20:58 <vengfulsquirrel> Okay | ||
| 2009-01-16 21:11 <X0d_of_N0d> brb | ||
| 2009-01-16 21:20 -!- paola(n=paola@host-84-223-76-195.cust-adsl.tiscali.it) has joined #tryton | ||
| 2009-01-16 21:26 -!- X0d_of_N0d(i=user@gateway/tor/x-30ba472c1b831fa8) has joined #tryton | ||
| 2009-01-16 21:37 <vengfulsquirrel> X0d_of_N0d: Do you think the production order should have another state from Running to Finished to Done so that between Finished and Done moves can be created back to Storage ? | ||
| 2009-01-16 21:44 <cristi_an> guys you try to do some generic thing but be sure that in this filed there is not such thing as a standard..... | ||
| 2009-01-16 21:45 <cristi_an> unfortunatelly | ||
| 2009-01-16 21:45 <cristi_an> so if you will have 10 customers you'll see that you will have like 6,7 diffrent requests | ||
| 2009-01-16 21:51 <vengfulsquirrel> cristi_an: ? | ||
| 2009-01-16 21:55 -!- X0d_of_N0d(i=user@gateway/tor/x-db4792a8484753f2) has joined #tryton | ||
| 2009-01-16 21:56 <X0d_of_N0d> vengfulsquirrel: did you get the last few things I said? | ||
| 2009-01-16 21:58 <vengfulsquirrel> (12:13:24) X0d_of_N0d: brb <-- this is all I got | ||
| 2009-01-16 22:00 <vengfulsquirrel> X0d_of_N0d: Did you get my question about a new production order state ? | ||
| 2009-01-16 22:01 <X0d_of_N0d> yeah....ok | ||
| 2009-01-16 22:01 <X0d_of_N0d> vengfulsquirrel: draft, assigned, in progress, stopped (or paused), canceled, completed | ||
| 2009-01-16 22:01 <X0d_of_N0d> I think move should take place when the job is completed, I don't think we need another state | ||
| 2009-01-16 22:02 <X0d_of_N0d> in the future I think materials should be moved as they're allocated so if we have 10 metal blocks and the job is 50% complete then we have 5 blocks used and 5 new parts | ||
| 2009-01-16 22:02 <vengfulsquirrel> which move should take place? the move from produced to output zone or the move from the output zone to the storage? | ||
| 2009-01-16 22:02 <X0d_of_N0d> but we can deal with granular tracking of materials and labor later on | ||
| 2009-01-16 22:03 <X0d_of_N0d> to the output zone, the next move is up to the user (storage or shipping) | ||
| 2009-01-16 22:04 <vengfulsquirrel> yeah but with the way the stock supply module works it should always go back to storage | ||
| 2009-01-16 22:04 <X0d_of_N0d> or perhaps the default location could be defined in the bom | ||
| 2009-01-16 22:04 <vengfulsquirrel> even if its virtual | ||
| 2009-01-16 22:05 <vengfulsquirrel> I sent another email to the list explaining my understanding of the stock supply way of doing things. | ||
| 2009-01-16 22:06 <X0d_of_N0d> hum......... | ||
| 2009-01-16 22:06 <X0d_of_N0d> I guess I'm not on the list | ||
| 2009-01-16 22:06 <vengfulsquirrel> You can just go to google groups and probably read it | ||
| 2009-01-16 22:07 <vengfulsquirrel> but you should probably get on the list , everybody is doing it | ||
| 2009-01-16 22:07 <X0d_of_N0d> ok, I'm joining the group too so... yeah. | ||
| 2009-01-16 22:07 <X0d_of_N0d> I'm gonna get some lunch first | ||
| 2009-01-16 22:07 <X0d_of_N0d> I'll be back in a bit | ||
| 2009-01-16 22:59 -!- mmarshall(n=mmarshal@76.255.73.67) has joined #tryton | ||
| 2009-01-16 23:02 <cedk> vengfulsquirrel: for your remarks about color/size with products, we had the template mecanisme on product | ||
| 2009-01-16 23:02 <cedk> vengfulsquirrel: in fact the model product.product inherits from product.template (inherit is like a one2many) | ||
| 2009-01-16 23:03 <cedk> so you have one product.template with many product.product that are linked to it | ||
| 2009-01-16 23:03 <cedk> and shared many commons property like accounting stuff etc... | ||
| 2009-01-16 23:04 <cedk> it is not visible directly in the current interface but it is there | ||
| 2009-01-16 23:05 <vengfulsquirrel> So each color/size combination would be a seperate product but they would share common properties via a template? | ||
| 2009-01-16 23:06 <vengfulsquirrel> cedk: ^ | ||
| 2009-01-16 23:07 <cedk> vengfulsquirrel: yes | ||
| 2009-01-16 23:08 <X0d_of_N0d> vengfulsquirrel: the same method could be used for storing configurable bom choices.... | ||
| 2009-01-16 23:08 <X0d_of_N0d> ACTION thinks... yeah, that's kind of what cedk said, huh | ||
| 2009-01-16 23:09 <vengfulsquirrel> Well except those are properties whereas configurable boms are more like physical pieces, I'm not sure, I'll have to look at it. | ||
| 2009-01-16 23:09 <vengfulsquirrel> But I didn't know existed and now I know. | ||
| 2009-01-16 23:11 <X0d_of_N0d> boms could be linked to tempalte and bom choices could just be a field in product that's not used unless the bom linked to the template is configurable | ||
| 2009-01-16 23:15 <vengfulsquirrel> X0d_of_N0d: That still doesn't solve the configured product identification problem unless we make a product for every configuration of the BOM, is that what you mean? | ||
| 2009-01-16 23:17 <X0d_of_N0d> yes | ||
| 2009-01-16 23:18 <X0d_of_N0d> instead of configuring everything during sales you'd configure while creating the boms | ||
| 2009-01-16 23:19 <X0d_of_N0d> so if a new order came in for a configuration that doesn't exist you'd create a new product and configure the bom connected to it... | ||
| 2009-01-16 23:20 <vengfulsquirrel> So every product would then always have a fixed bom. | ||
| 2009-01-16 23:20 <X0d_of_N0d> then add the new part number to the sales order | ||
| 2009-01-16 23:21 <X0d_of_N0d> no, every template would have a bom, then the product would have the configuration of it | ||
| 2009-01-16 23:21 <cedk> I don't understand what you name confgured BOM ? | ||
| 2009-01-16 23:22 <cedk> for me, a BOM is the instruction to create one product | ||
| 2009-01-16 23:22 <X0d_of_N0d> right but a bom can be configurable so that the same bom can make multiple different items depending on what you choose | ||
| 2009-01-16 23:22 <X0d_of_N0d> a configurable bom is much like a product template | ||
| 2009-01-16 23:23 <cedk> we can make that a BOM can be use to construct a product.product or a product.template | ||
| 2009-01-16 23:24 <vengfulsquirrel> So maybe configurable boms should actually be created in the Production Management area and then a product can choose to use it under its production tab to define its fixed BOM. | ||
| 2009-01-16 23:25 <cedk> vengfulsquirrel: I don't think that it is real, in the BOM you define the product you need to produce, so it can not be use for any product | ||
| 2009-01-16 23:25 <X0d_of_N0d> we'd need a ui to product.template | ||
| 2009-01-16 23:29 <vengfulsquirrel> cedk: Yeah the configurable bom is just supposed to help with BOM maintanence so you don't have to maintained 256 boms for a computer you sell because there are 4 monitor types, 4 hard drive types, 4 cpu types and 4 memory types. | ||
| 2009-01-16 23:29 <X0d_of_N0d> cedk: ? | ||
| 2009-01-16 23:30 <vengfulsquirrel> I think the difference between the product template and what we need is that the product's themselves don't extend the template really they just share it. | ||
| 2009-01-16 23:31 <X0d_of_N0d> vengfulsquirrel: which is exactly what we want | ||
| 2009-01-16 23:31 <vengfulsquirrel> X0d_of_N0d: Do you think if people made a change to the bom configuration then it would be okay to re-write a new revision of each configured bom used by products? | ||
| 2009-01-16 23:31 <X0d_of_N0d> anything in product template is shared across all things that share a template | ||
| 2009-01-16 23:31 <vengfulsquirrel> X0d_of_N0d: No because each product will have a different configuration. | ||
| 2009-01-16 23:32 <X0d_of_N0d> right, but the bom will be shared | ||
| 2009-01-16 23:32 <X0d_of_N0d> the configuration would be stored in product.product | ||
| 2009-01-16 23:32 <vengfulsquirrel> I'm saying what if we don't store a mere configuration what if we just treat it like a seperate bom but read only and then the configurator can push revisions into it as the shared bom changes. | ||
| 2009-01-16 23:33 <X0d_of_N0d> vengfulsquirrel: then we have replication of data and that's bad | ||
| 2009-01-16 23:33 <bechamel> vengfulsquirrel: the mecanism between product.product and product.template allow to define for example several colors for the same product (like a bike or a shirt) but two cpu are gonna be two different templates | ||
| 2009-01-16 23:34 <X0d_of_N0d> bechamel: unless we extend template to support that | ||
| 2009-01-16 23:34 <bechamel> so maybe a instead of configurable bom i would talk about configurable bom line: so a computer bom will contain the bom line cpu which contain cpu1 and cpu2 (and a sequence to tell which cpu use by default) | ||
| 2009-01-16 23:36 <vengfulsquirrel> bechamel: That is kind of what was originally proposed except I refer to a configurable bom as a bom that contains configurable bom lines. | ||
| 2009-01-16 23:36 <bechamel> the product order than will explode all the needed boms, and the user can force some alternate products for some lines (i don't know how will be the gui)n one can also imagine that default product are overiden by other product on the same bom line if the other product is available in stock | ||
| 2009-01-16 23:37 <bechamel> vengfulsquirrel: ok, the difficult part in this kind of talk is to find a common vocabulary :) | ||
| 2009-01-16 23:38 <vengfulsquirrel> http://www.laspilitas.com/s/images/demo-bom.png | ||
| 2009-01-16 23:39 <X0d_of_N0d> we're talking about a subject where they use the exact same letters for two different things | ||
| 2009-01-16 23:39 <vengfulsquirrel> The BOM Lines in the middle are the configurable BOM lines. | ||
| 2009-01-16 23:40 <vengfulsquirrel> ha yeah seriusoly i've been pretty disgusted with the books i've read, its like one big money scam | ||
| 2009-01-16 23:40 <X0d_of_N0d> two different *related* things | ||
| 2009-01-16 23:40 <bechamel> vengfulsquirrel: :) | ||
| 2009-01-16 23:41 <vengfulsquirrel> I've also found multiple definitions, sometimes completely contradictory, for almost every term. | ||
| 2009-01-16 23:41 <vengfulsquirrel> Anyways ha end of rant. | ||
| 2009-01-16 23:41 <bechamel> vengfulsquirrel: i'm not at ease with the graph, i like to think with db tables .. | ||
| 2009-01-16 23:42 <X0d_of_N0d> vengfulsquirrel: yes | ||
| 2009-01-16 23:42 <X0d_of_N0d> ACTION grinz | ||
| 2009-01-16 23:42 <X0d_of_N0d> bechamel: ok, so the layout would sort of be like this.... | ||
| 2009-01-16 23:42 <vengfulsquirrel> bechamel: Okay yeah I was going to make a drawing of the entity relationships so maybe I'll do that this weekend. | ||
| 2009-01-16 23:44 <vengfulsquirrel> I think as long as we somehow make a product for each configuration things will be much simpler. I'm just worried that changes to the main configuration will be difficult to handle, ie. what happens to all the depend products? | ||
| 2009-01-16 23:44 <X0d_of_N0d> bom_id, rev, bom_type, bom_lines | ||
| 2009-01-16 23:46 <X0d_of_N0d> vengfulsquirrel: hum... lets think about this | ||
| 2009-01-16 23:47 <bechamel> creating lot of product just to handle several kind of bom is not a good solution | ||
| 2009-01-16 23:48 <bechamel> and one should find a solution that is modular enough to avoid reconfiguration nightmares :) | ||
| 2009-01-16 23:49 <bechamel> there is also an other difficulty: sometimes it's not enough for a bom to only "output" one product, for example different size of adhesive paper are created in the same time from a big paper roller and glue | ||
| 2009-01-16 23:49 <vengfulsquirrel> Yeah you mean like a bom should signify a quantity and uom ? | ||
| 2009-01-16 23:49 <bechamel> and sometimes production generate also wastes | ||
| 2009-01-16 23:49 <X0d_of_N0d> vengfulsquirrel: each product links back to it's template. It would be possible to do a search to find all the dependances... | ||
| 2009-01-16 23:50 <X0d_of_N0d> if a change to a configurable bom made a configured bom impossible then the ui could ask if you want to invalidate the bom? | ||
| 2009-01-16 23:50 <X0d_of_N0d> bechamel: the products would exist anyway, this is just a way to unify the boms so you don't need replicated data | ||
| 2009-01-16 23:51 <vengfulsquirrel> bechamel: In the United States we just dump waste in the nearest watershed and don't document it. Do you mean like partially finished products or like stuff that can be recycled or used in another process? | ||
| 2009-01-16 23:51 <X0d_of_N0d> bechamel: and would share a bom, therefore share a template | ||
| 2009-01-16 23:52 <bechamel> the first idea of a bom for me, is a list of (qty, product) as input materials and another list (qty, product) as output material, but it's not modular, so each list item should be something like a porduct but not a product | ||
| 2009-01-16 23:53 <vengfulsquirrel> Hmm yeah maybe there could be a wastes list associated with a bom. | ||
| 2009-01-16 23:53 <X0d_of_N0d> bechamel: you mean reusable materials that are different than the input materials? | ||
| 2009-01-16 23:53 <X0d_of_N0d> bechamel: if it's not modular it won't work. | ||
| 2009-01-16 23:53 <X0d_of_N0d> bechamel: it's not possible to maintain static boms for thousands of possible items | ||
| 2009-01-16 23:53 <X0d_of_N0d> modular boms are absolutely essential for companies with configurable products | ||
| 2009-01-16 23:54 <bechamel> X0d_of_N0d: i don't thing that using the product.template - product.product relation will lead to something good (at least for the rest of the system it would be a major change of the semantic og templates) | ||
| 2009-01-16 23:54 <vengfulsquirrel> X0d_of_N0d: I still think read-only static boms might be a good option. | ||
| 2009-01-16 23:55 <bechamel> vengfulsquirrel: yes i think about reusable materials and also for toxic wastes that should be tracked | ||
| 2009-01-16 23:55 <X0d_of_N0d> vengfulsquirrel: if you have static boms you might as well not have boms at all | ||
| 2009-01-16 23:55 <X0d_of_N0d> at least for us | ||
| 2009-01-16 23:55 <vengfulsquirrel> bechamel: Okay yeah that sounds like something that would be good to be addressed, maybe between Running and Finished those could be updated with actual quantities produced. | ||
| 2009-01-16 23:55 <bechamel> vengfulsquirrel: yes bom must be readonly, but the product order should allow to choose across sevearal configuration | ||
| 2009-01-16 23:56 <vengfulsquirrel> X0d_of_N0d: I don't see any difference other than under the hood. | ||
| 2009-01-16 23:56 <X0d_of_N0d> hum... | ||
| 2009-01-16 23:56 <X0d_of_N0d> vengfulsquirrel: maybe I'm misunderstanding you | ||
| 2009-01-16 23:57 <vengfulsquirrel> X0d_of_N0d: You can't update the configurable bom without sending revision updates to every dependent product's static bom. Really maybe we'd store 50% more bom data. | ||
| 2009-01-16 23:58 <vengfulsquirrel> but it would simplify everything because then every product would have essentially a static bom | ||
| 2009-01-16 23:58 <bechamel> vengfulsquirrel: what do you mean exactly by static ? | ||
| 2009-01-16 23:59 <X0d_of_N0d> but if you update a shared bom you need to update everything that uses that bom | ||
| 2009-01-16 23:59 <vengfulsquirrel> Not configurable, just a standard list of materials | ||
| 2009-01-16 23:59 <vengfulsquirrel> X0d_of_N0d: Yeah, you have to anyways. |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
