Please lend me your thoughts

[Anthony Tampone]

I have a inventory management app and I need to add Part assembly/Manufacturing abilities to it. I have thought of many different ways to do this and I but every way seams to have a catch. What I need to do it let the user define a structure. Once defined, the user could call uppon this structure to build it. So far I was able to get one that works providing the structure is always the same, but I need to give the builder options. Lets say a wagon needs a chasis, handle and wheels, but You could order your wagon with oversised wheels or regular ones. It would still build the same part number wagon, just a diferent option. I have come to an impass. Any thoughts on the subject would be more than greatly appreciated.

[Jim Chapman]

RE: Please lend me your thoughts

Hi Anthony,

Not real sure what you need, but sets are probably the answer. I'm in the middle of a manufacturing app and am probably looking at similar needs. Maybe you could design a parent table that contained the products you will be manufacturing. Each record would have linked children records that contain the parts and or processes needed. In each part record could contain , big wheel, little wheel, red wheel, etc. It would have to have a value, but the value could be selected by user. Tell us more, more thoughts will come.

Jim

[Tom Cone Jr]

RE: Please lend me your thoughts

Having never built anything like this gives one a certain 'freedom'. If this doesn't make sense, kindly discard it quietly!

Consider separate tables for each primary manufactured article. If the number of components are manageable store them all in a single record for the one article. Otherwise, use two or more tables, linked one to one. You could organize the record on screen using tabbed subforms, putting major subsystems on separate tabbed pages.

Data entry could begin with a separate form from which the user would pick the category or item to be manufactured. A script would then open the table for that kind of goods and fill in default values. The new default record would be displayed on your tabbed subform. Fields in the table could be based on lookups to other tables for models, colors, sizes, etc.

When the record is saved, adjusting entries could be recorded in separate inventory tables based on the quantity of items needed for the particular goods.

Using separate tables may sound awkward and inefficient, but I'd guess you'll have an easier time designing the structure of a table for single item, than a structure general enough to cover all items you might manufacture.

-- tom

[Steve Dentler]

RE: Please lend me your thoughts

Option bills are not unusual in a BOM. You might have a BOM header table and a BOM detail table for the line items in each BOM. I would probably provide an aditional field in the header table to identify an "Option Bill" from a regular bill and a field to indicate whether the bill has options (probably a logical field). Or the option BOMs (header and detail) could reside in separate tables form the regular BOMs. On the form, if the "Bill has options" logical field is check true, you could display a separate form (loading the primary BOM number and/or marking the record as an option bill with Xbasic to capture the BOM for the options.

[Robert Adler]

RE: Please lend me your thoughts

Anthony:

the end product is composed of numerous parts. all parts in a manufacturing environment are usually identified with a unique Stock Keeping Unit(SKU). the final produce, in your case the wagon(sku#1) is composed of many other parts(SKUs). You have to adust the part being built to accept all parts that comprise the wagon. this open ended structure would meet any criteria. Red Wagon(sku#1), blue wagon(sku#2). their parts could be different and the internal SKUs would be different.

I think this is what you are trying to accomplis.

bob

[Pat Bremkamp]

RE: Please lend me your thoughts

Anthony,
I think what you need is a table with four fields:
Assemby number
parent number
component number
quantity each
Each opional assembly will have to be uniquely identified so you can identify the components.

Notice, however, that this only gives you a single level bill. (A parts list) If you need a structure that specifies components of components, then you have a real problem!!!

[martinwcole]

RE: Please lend me your thoughts

about 15 years ago i wrote a program like that - and the thought of doing it with alpha seems simple - comparitively - i was using an ol' ti'my c-based database language that went defunct in 1983.

what comes to mind to me is this:

file1 = list of possible finished components
===wagons, trailers, etc.
===dialog1 gets the users finished component
===closes dialog1, and opens dialog2
file2
===list of minimum components and possible options
===dialog2 shows the components on the left
===and selected components on the right
===double clicking or "Enter" on the left selects
===possible componets and options and puts them on the right
===a button doesn't close dialog2 and opens dialog3
file3
===list of subcomponents and options for each component
===on the left
===double clicking selects and displays on the right
===you could take this to any level necessary
===a button closes dialog3 and returns you to dialog2 and ===advances to the next in the list of components and ===options until complete

when finished you would have available all possible choices either in variables or in a record for the new order, etc.

Dan Blank originated this idea, and even uses a wand to get the info for his "what parts are checked out to which user for which job" parts inventory program. This is just an idea of course. Search for Dan Blank, and goto LarnAlpha for more details on his process. Its very slick and mimics the standard way one selects possibilities in other windows based programs.