A Question of Object Architecture
-
I'm considering embarking on my first C# adventure by way of creating an inventory system for the electrical power industry. I spent much of tonight trying to lay out an object heirarchy and only ended up confusing myself. The top level class, InventoryItem, is a no-brainer. The next level is almost as simple - Overhead, Underground, Substation, Multi-use. Then it starts to get complicated. For example, a simple disconnect comes in multiple flavors - solid blade or fused, 15kV or 25kV, 200A or 600A, load-breaking or non-load-breaking, ganged or single-phase, 1-, 2, or 3-pole. That I can deal with by creating subclasses. But each type is made by multiple manufacturers, and sold by multiple vendors, each with its own pricing. No one vendor sells all products from a single manufacturer, and no manufacturer sells all products through one vendor. Each vendor's pricing is different, even for the same item from the same manufacturer, and prices change weekly. To make matters more interesting, several manufacturers make the same item, interchangeable at will, and we stock equivalent parts from multiple manufacturers and vendors as one SKU. The goal here is to keep track of inventory items at the vendor/manufacturer level, but accumulate costs at the SKU level to be used for estimating future jobs. Can someone among you geniuses suggest a logical class heirachy for this mess? I think the coding will be fairly straightforward, but the difference between a raging success and a dismal failure lies in getting the structure right from the get-go. Thanks, in advance, if you have a useful suggestion.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
-
I'm considering embarking on my first C# adventure by way of creating an inventory system for the electrical power industry. I spent much of tonight trying to lay out an object heirarchy and only ended up confusing myself. The top level class, InventoryItem, is a no-brainer. The next level is almost as simple - Overhead, Underground, Substation, Multi-use. Then it starts to get complicated. For example, a simple disconnect comes in multiple flavors - solid blade or fused, 15kV or 25kV, 200A or 600A, load-breaking or non-load-breaking, ganged or single-phase, 1-, 2, or 3-pole. That I can deal with by creating subclasses. But each type is made by multiple manufacturers, and sold by multiple vendors, each with its own pricing. No one vendor sells all products from a single manufacturer, and no manufacturer sells all products through one vendor. Each vendor's pricing is different, even for the same item from the same manufacturer, and prices change weekly. To make matters more interesting, several manufacturers make the same item, interchangeable at will, and we stock equivalent parts from multiple manufacturers and vendors as one SKU. The goal here is to keep track of inventory items at the vendor/manufacturer level, but accumulate costs at the SKU level to be used for estimating future jobs. Can someone among you geniuses suggest a logical class heirachy for this mess? I think the coding will be fairly straightforward, but the difference between a raging success and a dismal failure lies in getting the structure right from the get-go. Thanks, in advance, if you have a useful suggestion.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
-
Why are you hard-coding the items? Wouldn't it be better to create a database?
█▒▒▒▒▒██▒█▒██ █▒█████▒▒▒▒▒█ █▒██████▒█▒██ █▒█████▒▒▒▒▒█ █▒▒▒▒▒██▒█▒██
What makes you think he is not using database? Mapping DB records on classes is nothing strange...
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
-
I'm considering embarking on my first C# adventure by way of creating an inventory system for the electrical power industry. I spent much of tonight trying to lay out an object heirarchy and only ended up confusing myself. The top level class, InventoryItem, is a no-brainer. The next level is almost as simple - Overhead, Underground, Substation, Multi-use. Then it starts to get complicated. For example, a simple disconnect comes in multiple flavors - solid blade or fused, 15kV or 25kV, 200A or 600A, load-breaking or non-load-breaking, ganged or single-phase, 1-, 2, or 3-pole. That I can deal with by creating subclasses. But each type is made by multiple manufacturers, and sold by multiple vendors, each with its own pricing. No one vendor sells all products from a single manufacturer, and no manufacturer sells all products through one vendor. Each vendor's pricing is different, even for the same item from the same manufacturer, and prices change weekly. To make matters more interesting, several manufacturers make the same item, interchangeable at will, and we stock equivalent parts from multiple manufacturers and vendors as one SKU. The goal here is to keep track of inventory items at the vendor/manufacturer level, but accumulate costs at the SKU level to be used for estimating future jobs. Can someone among you geniuses suggest a logical class heirachy for this mess? I think the coding will be fairly straightforward, but the difference between a raging success and a dismal failure lies in getting the structure right from the get-go. Thanks, in advance, if you have a useful suggestion.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
Roger Wright wrote:
Can someone among you geniuses suggest a logical class heirachy for this mess?
It would take more than a "genius" to do so because there is no logical hierarchical model for something that isn't, inherently, hierarchical. It isn't a "mess"; it's just not hierarchical.
-
I'm considering embarking on my first C# adventure by way of creating an inventory system for the electrical power industry. I spent much of tonight trying to lay out an object heirarchy and only ended up confusing myself. The top level class, InventoryItem, is a no-brainer. The next level is almost as simple - Overhead, Underground, Substation, Multi-use. Then it starts to get complicated. For example, a simple disconnect comes in multiple flavors - solid blade or fused, 15kV or 25kV, 200A or 600A, load-breaking or non-load-breaking, ganged or single-phase, 1-, 2, or 3-pole. That I can deal with by creating subclasses. But each type is made by multiple manufacturers, and sold by multiple vendors, each with its own pricing. No one vendor sells all products from a single manufacturer, and no manufacturer sells all products through one vendor. Each vendor's pricing is different, even for the same item from the same manufacturer, and prices change weekly. To make matters more interesting, several manufacturers make the same item, interchangeable at will, and we stock equivalent parts from multiple manufacturers and vendors as one SKU. The goal here is to keep track of inventory items at the vendor/manufacturer level, but accumulate costs at the SKU level to be used for estimating future jobs. Can someone among you geniuses suggest a logical class heirachy for this mess? I think the coding will be fairly straightforward, but the difference between a raging success and a dismal failure lies in getting the structure right from the get-go. Thanks, in advance, if you have a useful suggestion.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
- Do you have an existing GIS ? - Do you model/maintain phase info ? - Do you model secondary runs from transformer to meter ? - Do you model transmission (to subs) (ok, only effect the fields, but i'm curious :)) You will not want to break down the tables or class' beyond the type level. e.g. InvItem |__ Fuse |__ Transformer | |__ 1 phase (optional) | |__ 3 phase ('') |__ Capacitor |__ Switch |__ ... Some of the elec inv systems i've seen didn't even maintained separate tables for facility types. It was one big table with InvId, vendor, manuf., manuf sku, price, price date, (elec util) sku, description, ... Decription held "40A fuse", ... You will make life easier if you match the facility table break down that you use in you GIS (assuming you have a GIS, assuming you don't want to throw all inv items into one table). The inv system doesn't (generally) care about details like phases, amps, voltage, ... that should all be in the GIS table (that's why you can throw all that info into a inv desc field). The GIS table should just contain the InvId (unique for vendor/manuf/manuf sku) and optionally the (elec util) SKU (read-only in GIS, to validate InvId), plus the detail info like phases, voltage, circuit, ohug, state, ... . Of course going to the next level, you break out the detail info in the inv tables, and have the inv system tied to the GIS so that the GIS placement routines use the inv system to display validation tables for the digitizer to select from (then pull phase, ... from inv tables and copy into gis fields). Once you have all this info you will want to gen std drawings e.g. std pole, std gang-switch (attachment for a pole), ... . This system can then be used by the eng to do quick designs and part/cost estimates. A full system includes things like how many man hrs it takes to install each part as well. If i were coming to you guys as a consultant the system i would propose would depend LOT on what you already have (what GIS - what schema, do std drawing exist - what format, current inv data system/format, ...) ... and of course how much money you want to spend :).
...cmk Save the whales - collect the whole set
-
I'm considering embarking on my first C# adventure by way of creating an inventory system for the electrical power industry. I spent much of tonight trying to lay out an object heirarchy and only ended up confusing myself. The top level class, InventoryItem, is a no-brainer. The next level is almost as simple - Overhead, Underground, Substation, Multi-use. Then it starts to get complicated. For example, a simple disconnect comes in multiple flavors - solid blade or fused, 15kV or 25kV, 200A or 600A, load-breaking or non-load-breaking, ganged or single-phase, 1-, 2, or 3-pole. That I can deal with by creating subclasses. But each type is made by multiple manufacturers, and sold by multiple vendors, each with its own pricing. No one vendor sells all products from a single manufacturer, and no manufacturer sells all products through one vendor. Each vendor's pricing is different, even for the same item from the same manufacturer, and prices change weekly. To make matters more interesting, several manufacturers make the same item, interchangeable at will, and we stock equivalent parts from multiple manufacturers and vendors as one SKU. The goal here is to keep track of inventory items at the vendor/manufacturer level, but accumulate costs at the SKU level to be used for estimating future jobs. Can someone among you geniuses suggest a logical class heirachy for this mess? I think the coding will be fairly straightforward, but the difference between a raging success and a dismal failure lies in getting the structure right from the get-go. Thanks, in advance, if you have a useful suggestion.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
Correct me if I'm wrong, but you are looking to do something like this: You have a collection of unique InventoryItems. Each InventoryItem has an SKU associated with it. You have a collection of manufacturers You have a collection of vendors A manufacturer has a collection of vendors associated with it. A vendor has a collection of InventoryItems associated with it. A manufacturer has a collection of InventoryItems associated with it. The Overhead, Underground, etc. are just types of InventoryItems. If this summary is correct, then we can go from there.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before. -
Correct me if I'm wrong, but you are looking to do something like this: You have a collection of unique InventoryItems. Each InventoryItem has an SKU associated with it. You have a collection of manufacturers You have a collection of vendors A manufacturer has a collection of vendors associated with it. A vendor has a collection of InventoryItems associated with it. A manufacturer has a collection of InventoryItems associated with it. The Overhead, Underground, etc. are just types of InventoryItems. If this summary is correct, then we can go from there.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.That's about as far as I've got with it, and it's what I'm used to seeing in retail. But what cmk, above, suggests makes sense. I'm going to play with that approach for a bit and see where it takes me.:~
"...a photo album is like Life, but flat and stuck to pages." - Shog9
-
- Do you have an existing GIS ? - Do you model/maintain phase info ? - Do you model secondary runs from transformer to meter ? - Do you model transmission (to subs) (ok, only effect the fields, but i'm curious :)) You will not want to break down the tables or class' beyond the type level. e.g. InvItem |__ Fuse |__ Transformer | |__ 1 phase (optional) | |__ 3 phase ('') |__ Capacitor |__ Switch |__ ... Some of the elec inv systems i've seen didn't even maintained separate tables for facility types. It was one big table with InvId, vendor, manuf., manuf sku, price, price date, (elec util) sku, description, ... Decription held "40A fuse", ... You will make life easier if you match the facility table break down that you use in you GIS (assuming you have a GIS, assuming you don't want to throw all inv items into one table). The inv system doesn't (generally) care about details like phases, amps, voltage, ... that should all be in the GIS table (that's why you can throw all that info into a inv desc field). The GIS table should just contain the InvId (unique for vendor/manuf/manuf sku) and optionally the (elec util) SKU (read-only in GIS, to validate InvId), plus the detail info like phases, voltage, circuit, ohug, state, ... . Of course going to the next level, you break out the detail info in the inv tables, and have the inv system tied to the GIS so that the GIS placement routines use the inv system to display validation tables for the digitizer to select from (then pull phase, ... from inv tables and copy into gis fields). Once you have all this info you will want to gen std drawings e.g. std pole, std gang-switch (attachment for a pole), ... . This system can then be used by the eng to do quick designs and part/cost estimates. A full system includes things like how many man hrs it takes to install each part as well. If i were coming to you guys as a consultant the system i would propose would depend LOT on what you already have (what GIS - what schema, do std drawing exist - what format, current inv data system/format, ...) ... and of course how much money you want to spend :).
...cmk Save the whales - collect the whole set
cmk wrote:
Do you have an existing GIS ?
Yup, and we paid a bundle to collect it. Unfortunately, now that I've gained more understanding of the GIS schema the consultant created, I see that it was a crappy job, full of unused fields, duplicates, and unnecessary data.
cmk wrote:
Do you model/maintain phase info ? - Do you model secondary runs from transformer to meter ?
Not yet, though we collected conductor/structure data with the intent of one day modelling it. Ideally, the GIS geodatabase would be the ideal place to store details about structure and implementation, and a separate db would contain just stock and reordering info. The more important task is probably to clean up the mess in the GIS schema, but the priority from a business standpoint is to track and maintain adequate stocks of spare parts - two very different jobs. The info in the GIS system should probably be treated as a super-inventory, with assemblies tracked as finished goods created from parts drawn from stores and tracked by the general inventory. We use RUS standard structures, with minor variations, for most of our network, and I have the standard drawings in AutoCAD format. Since the new AutoCAD 2007 adds the ability to link the data fields in a table to an external database, it should be fairly straightforward to generate up-to-date costs at the structure level for future construction using average costs from the inventory db. That would also, when coupled with accurate GIS data, give us current replacement costs for installed plant. Hmmm... You've given me much to rethink - Thanks!:-D
"...a photo album is like Life, but flat and stuck to pages." - Shog9
-
cmk wrote:
Do you have an existing GIS ?
Yup, and we paid a bundle to collect it. Unfortunately, now that I've gained more understanding of the GIS schema the consultant created, I see that it was a crappy job, full of unused fields, duplicates, and unnecessary data.
cmk wrote:
Do you model/maintain phase info ? - Do you model secondary runs from transformer to meter ?
Not yet, though we collected conductor/structure data with the intent of one day modelling it. Ideally, the GIS geodatabase would be the ideal place to store details about structure and implementation, and a separate db would contain just stock and reordering info. The more important task is probably to clean up the mess in the GIS schema, but the priority from a business standpoint is to track and maintain adequate stocks of spare parts - two very different jobs. The info in the GIS system should probably be treated as a super-inventory, with assemblies tracked as finished goods created from parts drawn from stores and tracked by the general inventory. We use RUS standard structures, with minor variations, for most of our network, and I have the standard drawings in AutoCAD format. Since the new AutoCAD 2007 adds the ability to link the data fields in a table to an external database, it should be fairly straightforward to generate up-to-date costs at the structure level for future construction using average costs from the inventory db. That would also, when coupled with accurate GIS data, give us current replacement costs for installed plant. Hmmm... You've given me much to rethink - Thanks!:-D
"...a photo album is like Life, but flat and stuck to pages." - Shog9
Roger Wright wrote:
full of unused fields, duplicates, and unnecessary data
I've worked with a dozen or so elec utilities, EVERY one had the same issues, as well as unfilled fields - which can be the most frustrating.
Roger Wright wrote:
The more important task is probably to clean up the mess in the GIS schema
Another common phrase heard at utilities everyware. :)
Roger Wright wrote:
should probably be treated as a super-inventory
I view the GIS as the asset management system vs the inventory management system you're developing. The main problem i've seen with IT systems developed in utilities is one that is forced on management. Usually the initial project is funded by capital funds and can be as big as needed, but after that any further work is funded by the yearly O&M budget which is much smaller. As a result they try to cram everything they can think of in the initial phase. Unfortunately after a year or so, upon reflection, it is obvious that a lot of things could have been done better, but now there are stuck with a bad design that they have to work around for the next 5yrs - at which point they replace the GIS again :) ... and so the cycle continues.
Roger Wright wrote:
standard drawings in AutoCAD format
Also fairly common. As you mentioned it should be fairly easy to link these to a db. What you really want to go for though is having a design interface in the GIS that allows your engineers to place prelim plant and be able to query the standard drawings. This GIS interface would also give the eng the ability to select (by region or piece) the prelim plant and generate a BOM. What i'm trying to point out is that the acad-db combo is just a data source, it's useless on its own, you still need to design/develop the interface to it in a GIS design module. This design interface will likely be (should be) different than that used by the digitizers to place designed plant. What GIS are you using (ArcInfo, Smallworld, AutoMap, Intergraph, ...) ? If you have any questions, or want to bounce some ideas around feel free to post them or email me, i find all this stuff fascinating (well i guess i should, it's my job as well :)).
...cmk Save the whales - collect the whole set