chat.freenode.net #tryton log beginning Sat Jan 17 00:00:01 CET 2009 | ||
2009-01-17 00:00 <vengfulsquirrel> X0d_of_N0d: You could remove a 80GB drive and that would invalidate like 64 products. (assuming all of them existed) | ||
2009-01-17 00:00 <vengfulsquirrel> This definately is going to take some careful navigation and running the numbers. | ||
2009-01-17 00:00 <X0d_of_N0d> right, I was just wanting ot make sure that you're not suggesting that we don't propigate changes | ||
2009-01-17 00:01 -!- tekknokrat(n=gthieleb@dslb-088-074-131-027.pools.arcor-ip.net) has joined #tryton | ||
2009-01-17 00:01 -!- tekknokrat(n=gthieleb@dslb-088-074-131-027.pools.arcor-ip.net) has left #tryton | ||
2009-01-17 00:01 <vengfulsquirrel> Yeah I'm a little concerned about changes to nested subassembly's revisions that alter the parent product but the revision does not reflect this. | ||
2009-01-17 00:01 <X0d_of_N0d> vengfulsquirrel: right | ||
2009-01-17 00:02 <vengfulsquirrel> Anytime we need to refer to a bom for a long period we need to store the parent revision and all nested revisions. | ||
2009-01-17 00:02 <X0d_of_N0d> vengfulsquirrel: right | ||
2009-01-17 00:03 <X0d_of_N0d> vengfulsquirrel: I think a bom should always just by default refer to the latest version of the bom. We'd know based on active dates which previous revisions people have. | ||
2009-01-17 00:03 <vengfulsquirrel> By forcing the configurator to live and work in the production management section we could just add a produceable flag and a bom link to products and that's the only change to the entire system. | ||
2009-01-17 00:04 <X0d_of_N0d> vengfulsquirrel: producable flag and bom_id field | ||
2009-01-17 00:05 <bechamel> maybe it should be usefull to introduce something like bom role : several permutale boms will share the same role, and a bom is not a list of product/qty but a list of role, if I have a new product I only add another bom to the existing role | ||
2009-01-17 00:06 <X0d_of_N0d> bechamel: you're talking about configurable boms? | ||
2009-01-17 00:06 -!- ikks(n=igor@201.244.188.98) has joined #tryton | ||
2009-01-17 00:07 <bechamel> yes, my point of view is that all boms should be configurable (so configurable is implicit) | ||
2009-01-17 00:08 <X0d_of_N0d> bechamel: I think we're running into another terminology problem | ||
2009-01-17 00:08 <bechamel> and it's not the bom which is configurable it's the production order | ||
2009-01-17 00:08 <bechamel> X0d_of_N0d: yes maybe | ||
2009-01-17 00:09 <X0d_of_N0d> bechamel: when something is produced we need to be able to trace back and figure out exactly what bom was used to build it | ||
2009-01-17 00:09 <bechamel> I will wait for the relational schema before disturbing you further :) | ||
2009-01-17 00:09 <X0d_of_N0d> bechamel: how would that be stored | ||
2009-01-17 00:09 <bechamel> X0d_of_N0d: on the production order | ||
2009-01-17 00:09 <X0d_of_N0d> yeah.. pictures would probably help | ||
2009-01-17 00:10 <X0d_of_N0d> bechamel: right, but how on the production order? do we store a part number that has a static bom attached to it? if so do we generate new part numbers for every revision (I don't like that)? | ||
2009-01-17 00:10 <X0d_of_N0d> bechamel: do we store bom+config? | ||
2009-01-17 00:11 <bechamel> for me a bom is like a recipe but you can shop some ingredient instead of cocking them, and you decide this when you create the meal and i will change from day to day. but the recipe on the book is always the same | ||
2009-01-17 00:13 <bechamel> the productio order store the boms that have been chosen accross all the available boms | ||
2009-01-17 00:14 <X0d_of_N0d> bechamel: so there'd be a bom for each production order??? | ||
2009-01-17 00:15 <bechamel> X0d_of_N0d: a link/reference to the existing bom | ||
2009-01-17 00:16 <bechamel> X0d_of_N0d: or several links to existing boms | ||
2009-01-17 00:19 -!- X0d_of_N0d(i=user@gateway/tor/x-3c74c31efd89a152) has joined #tryton | ||
2009-01-17 00:20 <X0d_of_N0d> hum... | ||
2009-01-17 00:20 <X0d_of_N0d> ok | ||
2009-01-17 00:20 <X0d_of_N0d> bechamel: the last thing I got from you was "the productio order store..." | ||
2009-01-17 00:21 <bechamel> X0d_of_N0d: I said that the product order will store a link/reference to the existing bom | ||
2009-01-17 00:21 <bechamel> or several links to existing boms | ||
2009-01-17 00:22 <X0d_of_N0d> ok | ||
2009-01-17 00:23 <X0d_of_N0d> and if you configure a bom it checks for an existing bom with that configuration or creates a new one? | ||
2009-01-17 00:23 <X0d_of_N0d> or do you create a new bom for each configuration? | ||
2009-01-17 00:24 <bechamel> the idea is to avoid to create a new bom for a new configuration | ||
2009-01-17 00:26 <X0d_of_N0d> brb | ||
2009-01-17 00:28 <bechamel> example for the pizza, if i want to manage 3 solution: 1) buy the pizza 2) buy some pizza bread and tomato 3) create the pizza bread from flour etc and buy the tomato. (yeah very simple pizza with only tomato). so the pizza role will contains two boms: one with one product (finished pizza) one with two product (tomato, and bread), the bread role will contains two bom: one who will contains flour, water, etc and the other with only the | ||
2009-01-17 00:28 <bechamel> finished bead product | ||
2009-01-17 00:29 <bechamel> but there is still a problem because this mix products and bom | ||
2009-01-17 00:33 <vengfulsquirrel> hmm yeah i'm confused | ||
2009-01-17 00:34 <bechamel> vengfulsquirrel: bread is the correct word ? | ||
2009-01-17 00:34 <bechamel> better: is bread the correct word ? | ||
2009-01-17 00:35 <X0d_of_N0d> bechamel: s/bread/crust/ | ||
2009-01-17 00:37 <bechamel> X0d_of_N0d: yes of course, like "cheesy crust" at pizza hut :D | ||
2009-01-17 00:37 <vengfulsquirrel> ha | ||
2009-01-17 00:37 <X0d_of_N0d> bechamel: so a pizza bom would contain two lines toppings & crust (since it's all made at the same time in a simple process it would be shrunk into one, but for our uses we'll continue anyway)... | ||
2009-01-17 00:38 <X0d_of_N0d> bechamel: then crust would contain a bm for flower,water, ,egg, salt, etc.. | ||
2009-01-17 00:39 <X0d_of_N0d> bechamel: or cheese, flour, egg, water, etc | ||
2009-01-17 00:41 <bechamel> the idea is not to use bom has lines but roles, so a pizza bom contain two role toppings and crust | ||
2009-01-17 00:41 <X0d_of_N0d> bechamel: that's a bom | ||
2009-01-17 00:42 <bechamel> and there would be two bom for the crust role one with flour, egg, water and one with a ready crust from the supplier | ||
2009-01-17 00:43 <bechamel> ... and one with flour, egg, water and cheese (as long a one consider that a crust with cheese and crust without are permutale) | ||
2009-01-17 00:44 <X0d_of_N0d> bechamel: but that's what a bom would be, a list of other boms or products | ||
2009-01-17 00:44 <X0d_of_N0d> which is why it makes sense to link boms to products and use products... | ||
2009-01-17 00:44 <vengfulsquirrel> Hey I don't think this really is a ER diagram but its a diagram, it also is pretty confusing at first glance: http://laspilitas.com/s/images/bom-er.png | ||
2009-01-17 00:44 <bechamel> a bom is list of role or product | ||
2009-01-17 00:44 <X0d_of_N0d> hum... | ||
2009-01-17 00:45 <X0d_of_N0d> bechamel: that's what a bom is | ||
2009-01-17 00:45 <vengfulsquirrel> crows feet kind of come out weird in Dia | ||
2009-01-17 00:47 <bechamel> vengfulsquirrel: shouldn't the link between bom line and product be reversed ? | ||
2009-01-17 00:47 <vengfulsquirrel> but what i was saying earlier is that a configurable bom doesn't actually report to a specific product, it only produces boms for products | ||
2009-01-17 00:48 <vengfulsquirrel> bechamel: No because a BOM Line only refers to a single product. But many BOM Lines can refer to the same product. | ||
2009-01-17 00:48 <vengfulsquirrel> As far as I know. | ||
2009-01-17 00:48 <bechamel> no sorry, I'm wrong | ||
2009-01-17 00:49 <X0d_of_N0d> vengfulsquirrel: so bom's would know which product they're linked to, or would products know which bom they're linked to? | ||
2009-01-17 00:53 <vengfulsquirrel> Probably the bom would hold the link | ||
2009-01-17 00:54 <vengfulsquirrel> The bom could have for_product_id or whatever, and a product would have a produceable flag. | ||
2009-01-17 00:55 <cedk> I don't understand how the configurable stuff must work ? | ||
2009-01-17 00:57 <cedk> and I think that what you try to do by being able to switch one product in a BOM, can be done by phatom BOM | ||
2009-01-17 00:58 <vengfulsquirrel> Well we are still working that out. I'm proposing to just make configurations and propagate them into products using the configurable BOM as a template. | ||
2009-01-17 00:58 <vengfulsquirrel> cedk: Phantom BOM has multiple definitions. From what I've read it merely means a subassembly that is used on the production line but cannot be stocked. | ||
2009-01-17 00:59 <vengfulsquirrel> So its more used to communicate between workcenters via workorders. | ||
2009-01-17 00:59 <cedk> vengfulsquirrel: yes, so for the disk example, you create as many phatom BOMs as you have different disk | ||
2009-01-17 01:00 <cedk> so the system will choose one depending of the availability of the product | ||
2009-01-17 01:00 <vengfulsquirrel> Except disks are stocked and a customer doesn't want different sized disks, they want a specific sized disk. | ||
2009-01-17 01:00 <X0d_of_N0d> vengfulsquirrel: but one bom could be used for multiple products, so the link needs to go the other way | ||
2009-01-17 01:01 <cedk> vengfulsquirrel: it is just a matter of configuration, you create a phatom BOMs for disk of 250Go | ||
2009-01-17 01:01 <vengfulsquirrel> X0d_of_N0d: No one bom cannot be used for multiple products, the bom is fixed to that specific product. | ||
2009-01-17 01:01 <vengfulsquirrel> X0d_of_N0d: One configurable bom can be used to configure the bom of multiple products. | ||
2009-01-17 01:02 <cedk> I still don't understand the configurable BOM | ||
2009-01-17 01:04 <cedk> for me a phatom BOM is just a BOM that is not linked to any product | ||
2009-01-17 01:04 <cedk> and the BOM lines can be linked to a product or a phatom BOM | ||
2009-01-17 01:04 <X0d_of_N0d> cedk: that's not the definition of it | ||
2009-01-17 01:04 <cedk> like that we introduced choice in BOM lines | ||
2009-01-17 01:05 <cedk> X0d_of_N0d: I think it is the right things | ||
2009-01-17 01:06 <X0d_of_N0d> a phantom bom is an item that is used immediately, shared between multiple boms, or impossible to stock | ||
2009-01-17 01:06 <X0d_of_N0d> cedk: but that's not the correct use of the terminology | ||
2009-01-17 01:07 <cedk> X0d_of_N0d: that is what I say, and here I explain how to use it to introduce choice in BOM, but it can be also used to shared some common part between different BOMs | ||
2009-01-17 01:07 <X0d_of_N0d> cedk: if we want to create a bom that's like you describe then it's called a configurable bom | ||
2009-01-17 01:07 <X0d_of_N0d> actually it'd be a configurator | ||
2009-01-17 01:07 <X0d_of_N0d> I think | ||
2009-01-17 01:07 <cedk> X0d_of_N0d: I don't care about the name, but for me the both are the same | ||
2009-01-17 01:07 <X0d_of_N0d> cedk: ok...yeah, sorry, the terminology thing has been kind of a pain | ||
2009-01-17 01:08 <cedk> or at least must be the same, because it will be more powerfull | ||
2009-01-17 01:08 <X0d_of_N0d> I was saying that all the boms should be structured the same in the database, but called different things depending on their function | ||
2009-01-17 01:08 <X0d_of_N0d> and the name determines how they are used | ||
2009-01-17 01:09 <X0d_of_N0d> err type | ||
2009-01-17 01:09 <X0d_of_N0d> s/name/type/ | ||
2009-01-17 01:09 <cedk> if you think that it is your configurable BOM, so I think that yo must merge the configurable BOM with BOM | ||
2009-01-17 01:09 <vengfulsquirrel> a phantom bom will just move the logic somewhere else.. and then THAT will need to be configured | ||
2009-01-17 01:10 <cedk> it is simple, BOM linked to output products are normal BOM, otherwise it is phantom | ||
2009-01-17 01:10 <vengfulsquirrel> output products? | ||
2009-01-17 01:11 <cedk> as bechamel said a BOM must be able to produce more than one product | ||
2009-01-17 01:11 <cedk> it will be more generic and more powerfull | ||
2009-01-17 01:13 <cedk> like that you can handle trash product or having a production that split one product into two, etc... | ||
2009-01-17 01:14 <cedk> one thing that I don't how to handle it, it is when there is choice in the BOM | ||
2009-01-17 01:14 <vengfulsquirrel> okay but i think you'll need a dominate product | ||
2009-01-17 01:15 <cedk> vengfulsquirrel: simply a list of product that are sorted | ||
2009-01-17 01:15 <vengfulsquirrel> and the other outputs will be of less importance than the dominant product | ||
2009-01-17 01:15 <X0d_of_N0d> vengfulsquirrel: if you have that then you might as well have a product and a list of side-effects or something | ||
2009-01-17 01:15 <vengfulsquirrel> yeah that's what i mean | ||
2009-01-17 01:15 <cedk> vengfulsquirrel: that have a tag, that says it is a principal product or a trash | ||
2009-01-17 01:15 <vengfulsquirrel> if you split you have to just make two boms i think that's not common enough to create a system to handle | ||
2009-01-17 01:16 <cedk> vengfulsquirrel: it is better to make a generic system that allow n inputs and m outputs | ||
2009-01-17 01:17 <X0d_of_N0d> ok, I'm gonna go take a walk and get some soda | ||
2009-01-17 01:17 <vengfulsquirrel> Its adding complexity I think that is unnecessary | ||
2009-01-17 01:17 <cedk> and not separate output, just flag principals | ||
2009-01-17 01:17 <vengfulsquirrel> but then multiple products have to share boms | ||
2009-01-17 01:18 <vengfulsquirrel> and planning is more complex | ||
2009-01-17 01:18 <cedk> vengfulsquirrel: this one of the principal critism of the OpenERP modelisation | ||
2009-01-17 01:18 <bechamel> vengfulsquirrel: if we don't plan this now it will be impossible to do later | ||
2009-01-17 01:19 <cedk> vengfulsquirrel: you can have any way, many BOM for the same product | ||
2009-01-17 01:19 <bechamel> cedk: did you see wait I said about bom role ? | ||
2009-01-17 01:19 <cedk> bechamel: I did not understand | ||
2009-01-17 01:21 <vengfulsquirrel> okay well i'll have to keep thinking about the multiple outputs maybe you are right | ||
2009-01-17 01:21 <cedk> for me there is still: how to handle choice in production? | ||
2009-01-17 01:21 <vengfulsquirrel> you are both probably more experienced than me with that regard | ||
2009-01-17 01:21 <vengfulsquirrel> cedk: configurable boms | ||
2009-01-17 01:21 <bechamel> cedk: role is to handle choice actualy | ||
2009-01-17 01:21 <cedk> is the system make the best choice or let the user choice | ||
2009-01-17 01:22 <vengfulsquirrel> There will be no choice, you will have to create a product for every configuration that you need to make. | ||
2009-01-17 01:22 <cedk> vengfulsquirrel: not with phatom BOMs | ||
2009-01-17 01:22 <vengfulsquirrel> A user orders a specific product so configuration is only done to create products. | ||
2009-01-17 01:23 <cedk> vengfulsquirrel: except if you have similar product that you can choice in the production | ||
2009-01-17 01:23 <vengfulsquirrel> I do not understand your interpretation of phantom BOMs, is it the same as configurable bom lines except with a product ? | ||
2009-01-17 01:23 <vengfulsquirrel> You mean product substitutes? | ||
2009-01-17 01:23 <cedk> vengfulsquirrel: like many harddisk of 200Go | ||
2009-01-17 01:23 <cedk> vengfulsquirrel: yes | ||
2009-01-17 01:24 <vengfulsquirrel> That's something different than a phantom BOM. | ||
2009-01-17 01:24 <cedk> but I don't make different model for BOM and phantom BOM | ||
2009-01-17 01:24 <cedk> vengfulsquirrel: no, it is the same | ||
2009-01-17 01:24 <cedk> vengfulsquirrel: it is just a step in the production | ||
2009-01-17 01:24 <bechamel> it's a generalisation of phantom bom | ||
2009-01-17 01:24 <vengfulsquirrel> No because a phantom bom cannot be stocked. | ||
2009-01-17 01:25 <vengfulsquirrel> You are saying substitute a stockable product with another stockable product. | ||
2009-01-17 01:25 <cedk> phantom means, it doesn't produce a real product | ||
2009-01-17 01:25 <vengfulsquirrel> Then start production. | ||
2009-01-17 01:25 <X0d_of_N0d> vengfulsquirrel: a phantom bom could potentially be stocked, it just isn't usually | ||
2009-01-17 01:25 <X0d_of_N0d> cedk: it doesn't produce a sellable product | ||
2009-01-17 01:25 <cedk> X0d_of_N0d: if you want | ||
2009-01-17 01:25 <vengfulsquirrel> Okay ha can we call it product substitutes though. Its really you have 1 slot put anything in it. | ||
2009-01-17 01:26 <cedk> for me, it is a meta information | ||
2009-01-17 01:26 <X0d_of_N0d> the term phantom bom is used in a bunch of different ways meaning lots of things, perhaps we need to define some other terms so we can all be on the same page? | ||
2009-01-17 01:26 <vengfulsquirrel> A configurable bom could say choose 2 of there 10 or choose 0 or more of these 10. | ||
2009-01-17 01:26 <vengfulsquirrel> *of these 10 | ||
2009-01-17 01:26 <cedk> vengfulsquirrel: for me it is too complicate | ||
2009-01-17 01:27 <vengfulsquirrel> Not if its pre-product creation. | ||
2009-01-17 01:27 <cedk> vengfulsquirrel: did you have an example of a product that in which you can substitue a product by two others ? | ||
2009-01-17 01:27 <cedk> and for me the name phantom is the right name | ||
2009-01-17 01:28 <X0d_of_N0d> cedk: I have an example | ||
2009-01-17 01:28 <vengfulsquirrel> When assembling a computer system: Choose 0 or more drives: CDROM, 80 GB Drive, 160 GB Drive, DVD Drive | ||
2009-01-17 01:28 <X0d_of_N0d> cedk: say you build computers. A computer could have multiple processors, multiple different sizes and quantities of ram, multiple harddrive options, etc | ||
2009-01-17 01:28 <vengfulsquirrel> Your product substitute idea would be there are 10 brands of 80 GB Drive and that is chosen at production time. | ||
2009-01-17 01:29 <cedk> vengfulsquirrel: this will not produce the same product | ||
2009-01-17 01:29 <vengfulsquirrel> So we are talking about two different problems. | ||
2009-01-17 01:29 <vengfulsquirrel> Yeah it won't produce the same product. | ||
2009-01-17 01:29 <vengfulsquirrel> But its BOM will be created from a configurable BOM | ||
2009-01-17 01:29 <cedk> vengfulsquirrel: you will not sell a computer without CDROM at the same price than with one | ||
2009-01-17 01:29 <vengfulsquirrel> Yes I agree | ||
2009-01-17 01:30 <cedk> vengfulsquirrel: how to encode this in the sale order ? | ||
2009-01-17 01:30 <X0d_of_N0d> cedk: right, but if you change the motherboard that you sell for one computer, you'd want to change it on all the computers that are similar | ||
2009-01-17 01:31 <cedk> X0d_of_N0d: i talk about substitution, because you are out of stock for one by example | ||
2009-01-17 01:31 <vengfulsquirrel> Yeah that is a different use-case though which we haven't addressed but apparently is needed. | ||
2009-01-17 01:31 <vengfulsquirrel> So that feature needs to be added. | ||
2009-01-17 01:31 <cedk> X0d_of_N0d: substitution will not change the price of the product because you consider the products as the same | ||
2009-01-17 01:32 <vengfulsquirrel> Yeah we might need another Production Order State and some more relations to handle that situation. | ||
2009-01-17 01:33 <cedk> for you computer "on demand", I think what you need is a computer configuration, that will create the product and the associated BOM | ||
2009-01-17 01:33 <X0d_of_N0d> cedk: no, that's why I was suggesting connecting the bom to the product template and the configuration to the product | ||
2009-01-17 01:33 <vengfulsquirrel> So that substitutes can be selected before the production order changed to assigned. | ||
2009-01-17 01:33 <X0d_of_N0d> cedk: but if the master bom changes you have to change anyhting that shares that bom | ||
2009-01-17 01:34 <cedk> vengfulsquirrel: yes | ||
2009-01-17 01:34 <cedk> X0d_of_N0d: don't understand | ||
2009-01-17 01:34 <vengfulsquirrel> cedk: Yeah that's what I am saying a Configurator uses a Configurable BOM to create many products and their associated BOMs. | ||
2009-01-17 01:35 <cedk> vengfulsquirrel: I don't think it must be part of the base production | ||
2009-01-17 01:35 <vengfulsquirrel> Yeah that is also fine we can do production_bom_configurable as a sub module. | ||
2009-01-17 01:35 <cedk> vengfulsquirrel: because it will be used by salers | ||
2009-01-17 01:36 <vengfulsquirrel> and production_bom_substitutes | ||
2009-01-17 01:36 <X0d_of_N0d> cedk: s/salers/sellers/ | ||
2009-01-17 01:36 <vengfulsquirrel> etc. | ||
2009-01-17 01:36 <cedk> vengfulsquirrel: this object must be able to find if there is not already the same product | ||
2009-01-17 01:36 <vengfulsquirrel> The configurator ? | ||
2009-01-17 01:36 <cedk> vengfulsquirrel: yes | ||
2009-01-17 01:37 <vengfulsquirrel> Yeah it will be very complex, I'm not sure if we could put it in New Sale Line to help select a product but that would be nic.e | ||
2009-01-17 01:37 <cedk> vengfulsquirrel: or it can be a object that create all the possibilities | ||
2009-01-17 01:37 <vengfulsquirrel> Yeah people might not want that because it will pollute their product db | ||
2009-01-17 01:37 <cedk> vengfulsquirrel: the only problem will be to create a product name that is still meanful | ||
2009-01-17 01:38 <vengfulsquirrel> I have to take a break for a bit though, and its probably pretty late there so maybe we could continue this discussion this weekend. I might try to whip up some better flows and diagrams. | ||
2009-01-17 01:38 <vengfulsquirrel> cedk: Yeah it might have to nest the configuration options | ||
2009-01-17 01:38 <X0d_of_N0d> cedk: when a product is configured the user would put in a product name unless otherwise configured | ||
2009-01-17 01:39 <cedk> vengfulsquirrel: yes, or it can be just a wizard. I think it depends of the kind of business | ||
2009-01-17 01:39 <vengfulsquirrel> Home Computer, Power User Computer | ||
2009-01-17 01:39 <X0d_of_N0d> vengfulsquirrel: well things would be configured at each level of the bom... | ||
2009-01-17 01:39 <cedk> X0d_of_N0d: yes because there will be the computer | ||
2009-01-17 01:40 <vengfulsquirrel> X0d_of_N0d: Yeah we still have to think about the multiple levels I'm worried about how that will work. | ||
2009-01-17 01:40 <cedk> vengfulsquirrel: especially when there is choice | ||
2009-01-17 01:40 <vengfulsquirrel> X0d_of_N0d: The current plan would be that you would start configuring at the lowest level and configure to the top fixed each BOM. | ||
2009-01-17 01:40 <vengfulsquirrel> And the revisions, also worried about that. | ||
2009-01-17 01:40 <vengfulsquirrel> I just want to make sure we at least know what we need and where it will go ... 'eventually'. | ||
2009-01-17 01:41 <cedk> vengfulsquirrel: revision is just for history ? | ||
2009-01-17 01:41 <vengfulsquirrel> cedk: Sometimes an older bom might be in use until the newer version gets approved. Additionally you might want to use a fixed revision during production so that changes don't confuse the crap out of the system. | ||
2009-01-17 01:42 <X0d_of_N0d> vengfulsquirrel: yeah, that's really a mess | ||
2009-01-17 01:42 <cedk> vengfulsquirrel: it will be not to difficult to handle this | ||
2009-01-17 01:42 <vengfulsquirrel> X0d_of_N0d: So if you could determine you most complicated configurations and maybe remove any company stuff we could use those as examples. | ||
2009-01-17 01:43 <cedk> there is a plan to have the same kind of mecanism for account (with history) | ||
2009-01-17 01:43 <X0d_of_N0d> cedk: amd (on bom revs) you might also need to know how a historical item was built | ||
2009-01-17 01:43 <cedk> X0d_of_N0d: this will be handle with the moves | ||
2009-01-17 01:44 <X0d_of_N0d> cedk: how? | ||
2009-01-17 01:44 <cedk> X0d_of_N0d: you will see by production which products was used | ||
2009-01-17 01:44 <cedk> X0d_of_N0d: and by the way, you can store the BOM id on the production order | ||
2009-01-17 01:44 <X0d_of_N0d> cedk: bom_id and rev | ||
2009-01-17 01:45 <cedk> X0d_of_N0d: yes | ||
2009-01-17 01:45 <cedk> X0d_of_N0d: and perhaps a list of bom id and rev | ||
2009-01-17 01:46 <vengfulsquirrel> Whew ha okay now I really gotta go, but I'll try to document what we discussed, product substitutes, configurator and multiple principal/non-principal outputs | ||
2009-01-17 01:46 <cedk> X0d_of_N0d: because if the production use sub-BOM or phantom BOM, you need to have all | ||
2009-01-17 01:46 <vengfulsquirrel> yeah the list | ||
2009-01-17 01:46 <cedk> vengfulsquirrel: good | ||
2009-01-17 01:46 <X0d_of_N0d> vengfulsquirrel: catch you later man | ||
2009-01-17 01:46 <vengfulsquirrel> gotta go, be back later, thanks for everyone's time | ||
2009-01-17 01:46 <bechamel> bye | ||
2009-01-17 01:47 <cedk> vengfulsquirrel: you know that there is a log bot on the irc ? | ||
2009-01-17 01:47 <cedk> vengfulsquirrel: http://www.tryton.org/~irclog/ | ||
2009-01-17 01:47 <cedk> vengfulsquirrel: if you lost something :-) | ||
2009-01-17 01:47 <cedk> bechamel: bye | ||
2009-01-17 01:48 <X0d_of_N0d> cedk: parent boms should store child bom_ids and revs | ||
2009-01-17 01:48 <bechamel> cedk: i was talking to vengfulsquirrel actualy :) | ||
2009-01-17 01:48 <X0d_of_N0d> cedk: so if you change a subassembly's rev you'd have to change the parent assembly's rev | ||
2009-01-17 01:48 <cedk> X0d_of_N0d: no, BOM doesn't store any information about the current production | ||
2009-01-17 01:49 <cedk> X0d_of_N0d: otherwise, it is not possible to introduce choice | ||
2009-01-17 01:50 <cedk> X0d_of_N0d: and I don't think that if a child BOM change is rev, you must change the rev of all others | ||
2009-01-17 01:51 <cedk> but for me, it is not yet clear who make the choice: the system or the user or (the system and the user can modify it) | ||
2009-01-17 01:52 <X0d_of_N0d> but if a subassembly changes then the parent needs to change to because the whole thing has to change at ocne | ||
2009-01-17 01:53 <X0d_of_N0d> that's a document control thing.... | ||
2009-01-17 01:53 <X0d_of_N0d> hum | ||
2009-01-17 01:54 <cedk> X0d_of_N0d: what ? | ||
2009-01-17 01:54 <cedk> X0d_of_N0d: I don't understand, what is the need to change the parent ? | ||
2009-01-17 01:55 <X0d_of_N0d> an assembly is something that all works together, so if a subassembly changes you need to verify that everything still works together | ||
2009-01-17 01:56 <X0d_of_N0d> hum... yeah, I dunno | ||
2009-01-17 01:56 <X0d_of_N0d> I need a break | ||
2009-01-17 01:56 <cedk> X0d_of_N0d: and me I need to sleep :-) | ||
2009-01-17 01:56 <X0d_of_N0d> s/break/drink/ | ||
2009-01-17 01:56 <X0d_of_N0d> s/sleep/drink/ | ||
2009-01-17 01:56 <X0d_of_N0d> hehe | ||
2009-01-17 01:58 <cedk> X0d_of_N0d: we will continue this later | ||
2009-01-17 01:58 <cedk> bye | ||
2009-01-17 01:58 <X0d_of_N0d> cedk: later man | ||
2009-01-17 02:21 -!- bechamel(n=user@85.201.86.139) has left #tryton | ||
2009-01-17 03:51 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
2009-01-17 05:07 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
2009-01-17 05:20 -!- yangoon(n=mathiasb@p549F5E98.dip.t-dialin.net) has joined #tryton | ||
2009-01-17 08:37 -!- paola(n=paola@host-84-223-76-195.cust-adsl.tiscali.it) has joined #tryton | ||
2009-01-17 09:25 -!- mrcast(n=mrcast@host49-68-dynamic.41-79-r.retail.telecomitalia.it) has joined #tryton | ||
2009-01-17 09:29 -!- enlightx(n=enlightx@host-84-220-86-72.cust-adsl.tiscali.it) has joined #tryton | ||
2009-01-17 09:59 -!- mrcast(n=mrcast@host49-68-dynamic.41-79-r.retail.telecomitalia.it) has left #tryton | ||
2009-01-17 12:01 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
2009-01-17 12:03 -!- cedk(n=ced@gentoo/developer/cedk) has joined #tryton | ||
2009-01-17 12:27 -!- Gedd(n=ged@77.109.115.38.adsl.dyn.edpnet.net) has joined #tryton | ||
2009-01-17 13:35 -!- sharkcz(n=dan@plz1-v-4-17.static.adsl.vol.cz) has joined #tryton | ||
2009-01-17 13:54 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
2009-01-17 14:15 -!- panthera(n=daniel@unable-to-package.org) has joined #tryton | ||
2009-01-17 14:28 -!- mwagner_(n=mwagner@p4FC6EBA3.dip.t-dialin.net) has joined #tryton | ||
2009-01-17 14:29 -!- mwagner_(n=mwagner@p4FC6EBA3.dip.t-dialin.net) has left #tryton | ||
2009-01-17 14:31 -!- carlos_(n=carlos@89.7.24.44) has joined #tryton | ||
2009-01-17 14:57 -!- mwagner_(n=mwagner@p4FC6EBA3.dip.t-dialin.net) has joined #tryton | ||
2009-01-17 14:57 <mwagner_> Hello | ||
2009-01-17 14:59 <Timitos> mwagner_: hi | ||
2009-01-17 15:02 <mwagner_> Timitos: Do you speak German? | ||
2009-01-17 15:03 <Timitos> mwagner_: ja. es gibt auch einen deutschen tryton channel #tryton.de | ||
2009-01-17 15:03 <mwagner_> Ah okay verstehe.. | ||
2009-01-17 15:04 <mwagner_> Ich probiere gerade Tryton auf dem Demoserver aus. Ich finde es ist ein sehr gutes Produkt | ||
2009-01-17 15:04 <Timitos> schön das zu hören. | ||
2009-01-17 15:05 <mwagner_> Was ich fragen wollte: Wenn ich eine Rechnung drucke, wird die auf französisch in OpenOffice geöffnet. Kann man das irgendwie einstellen dass die Rechnungen auf Deutsch erscheinen? | ||
2009-01-17 15:07 <Timitos> ja, du kannst bei der Party (Partei) die Sprache hinterlegen, in der die Rechnung gedruckt werden soll. | ||
2009-01-17 15:07 <Timitos> mwagner_: aber es kann sein, dass du eine neue rechnung erstellen musst, weil die rechnung wenn sie fakturiert wird langfristig so gespeichert wird, wie sie erstellt worden ist. | ||
2009-01-17 15:08 <mwagner_> Das probiere ich mal aus | ||
2009-01-17 15:09 <mwagner_> Funktioniert ohne dass ich eine neue Rechnung erstellen musste. Tryton gefällt mir immer besser | ||
2009-01-17 15:10 <Timitos> aber grundsätzlich sind alle reports ebenfalls bereits in deutsch übersetzt. die deutsche übersetzung von tryton ist vollständig und wird laufend aktualisiert. | ||
2009-01-17 15:10 <cedk> is it possible to speak in english, like that everybody can participate to the talk | ||
2009-01-17 15:11 <mwagner_> I was just asking on how to print invoices in German. I would also like to compliment you on the good work | ||
2009-01-17 15:12 <cedk> mwagner_: you're welcome | ||
2009-01-17 15:13 <cedk> and the printing language is choosen with the party language | ||
2009-01-17 15:13 <mwagner_> I have tried that - works very well. | ||
2009-01-17 15:13 <cedk> perhaps the fail back, if there is no language must be the language of the company and not en_US | ||
2009-01-17 15:16 <Timitos> cedk: yes. but i am not sure if everybody will create an custom english report and then translate it to the companies language. | ||
2009-01-17 15:18 <cedk> Timitos: it doesn't change anythings | ||
2009-01-17 15:18 <Timitos> cedk: yes | ||
2009-01-17 15:20 <cedk> and there is still the number formating | ||
2009-01-17 15:21 <Timitos> yes. you are right. | ||
2009-01-17 15:37 -!- tekknokrat(n=gthieleb@dslb-088-075-229-149.pools.arcor-ip.net) has joined #tryton | ||
2009-01-17 16:43 -!- FWiesing(n=Wiesinge@194.208.185.12) has joined #tryton | ||
2009-01-17 16:45 -!- FWiesing(n=Wiesinge@194.208.185.12) has left #tryton | ||
2009-01-17 16:45 -!- FWiesing(n=Wiesinge@194.208.185.12) has joined #tryton | ||
2009-01-17 16:54 -!- ikks(n=igor@190.102.203.88) has joined #tryton | ||
2009-01-17 17:43 -!- kleinerdrache(n=mn@88-117-100-254.adsl.highway.telekom.at) has joined #tryton | ||
2009-01-17 18:13 -!- markusleist(n=markus@n4-93.dsl.vianetworks.de) has joined #tryton | ||
2009-01-17 18:28 <CIA-10> tryton: C?dric Krier <ced@b2ck.com> default * 1469:7cc373504bf9 trytond/trytond/osv/orm.py: Handle join on the same table in order_calc | ||
2009-01-17 18:28 -!- ikks(n=igor@190.12.153.202) has joined #tryton | ||
2009-01-17 19:26 -!- mib_kwh86oso(i=5978d3ce@li57-82.members.linode.com) has joined #tryton | ||
2009-01-17 19:38 -!- mib_bjnbz9cg(i=5978d3ce@li57-82.members.linode.com) has joined #tryton | ||
2009-01-17 19:39 <mib_bjnbz9cg> beside server improvements and client ones ,there is a change in how modules are coded compared to openerp ? | ||
2009-01-17 19:41 <cedk> mib_bjnbz9cg: nothing fundamental, just a lot of little things (improvement) | ||
2009-01-17 19:43 <mib_bjnbz9cg> cedk: look at columns ,this is not different from tryton ? | ||
2009-01-17 19:43 <mib_bjnbz9cg> http://openerp.com/wiki/index.php/Developers:Developper%27s_Book/Objects/ObjectsDefine/ObjectsDefinitionExample | ||
2009-01-17 19:44 <cedk> mib_bjnbz9cg: there is new attributes, different default function, better definition of field Function, etc... | ||
2009-01-17 19:45 <cedk> look at http://www.tryton.org/doc/branches/1.0/trytond/doc/models.html#fields | ||
2009-01-17 19:47 <mib_bjnbz9cg> cedk: i see _columns are missing in tryton | ||
2009-01-17 19:54 <cedk> mib_bjnbz9cg: yes, we use class attributes instead | ||
2009-01-17 20:11 -!- mib_bjnbz9cg(i=5978d3ce@li57-82.members.linode.com) has left #tryton | ||
2009-01-17 20:35 -!- cristi_an(i=5978d3ce@li57-82.members.linode.com) has joined #tryton | ||
2009-01-17 20:37 <cristi_an> a balance sheet in Belgium is like the one is in tryton demo ? | ||
2009-01-17 20:37 <cristi_an> i have one from Romania | ||
2009-01-17 20:37 <cristi_an> http://www.softmaster.ro/documente/Balanta%20sintetica.pdf | ||
2009-01-17 20:37 <cristi_an> does this look like yours ? | ||
2009-01-17 20:50 <cristi_an> brb :) | ||
2009-01-17 21:17 -!- paola(n=paola@host-84-223-76-195.cust-adsl.tiscali.it) has joined #tryton | ||
2009-01-17 21:23 -!- kleinerdrache_(n=mn@91-115-66-220.adsl.highway.telekom.at) has joined #tryton | ||
2009-01-17 21:59 -!- vengfulsquirrel(n=ian@c-71-202-125-182.hsd1.ca.comcast.net) has joined #tryton | ||
2009-01-17 22:30 -!- CIA-51(n=CIA@208.69.182.149) has joined #tryton | ||
2009-01-17 23:17 <CIA-51> tryton: vengfulsquirrel * r422 /wiki/TrytonMRPIntegration.wiki: Wrote down feature for substitutable products, still need to work out the details. | ||
2009-01-17 23:17 <CIA-51> tryton: vengfulsquirrel * r423 /wiki/TrytonMRPIntegration.wiki: Refined explanation of configurable BOMs and Production Order re-stocking. |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!