It all comes down to how you structure your data in related tables. What tables have you created and how have you related them?
I made a suggestion about how that structure might be set up in a different thread. Did you see that post?
Yes, it is called BOM isn;t it? I've checked it. Thank you Phil. It would be easier using Portal, but with what I'm trying to do, I can't find the solutions.
With regards to the my posted screenshot, here's the tables/files are linked like below. I don't know what relationship I need to give to in order to show the Trim Size and Qty to apply to all style numbered F051", yet be able to modify / chose the different design of buttons (Button Codes).
Please let me know if you can suggest...
Thank you very much.
My ignorance when it comes to making clothes will hamper my suggestions so please check over what I suggest carefully.
As I understand it, You have a two level specification for each item of clothing manufactured. The top level spec describes the number and shape of each piece of material sewed to assemble the garment plus a list of the accessories (such as buttons) with their quantity and physical dimensions specified. Then you have a 2nd level spec where the material color and pattern are identified along with the color and possibly other details for each accessory item such as your buttons.
If I have that correct, then this might be the basic relationships from which to build your database:
"Pattern" may or may not be a related table--depending on how you manage the pattern for cutting out your material. It could just be a container field storing the drawing for this pattern or you may need multiple related records in order to store different parts of the whole pattern.
Materials would be records that identify a specific type of material--including the specific color and pattern. Specific accessory items such as buttons, zippers, etc would also be listed in this table.
This is just a "getting started" sketch of how your tables might link to each other. From a layout based on SpecLevel2, you could use portals to display: Cutting patterns, BasicBOM records and the BOMDetailed records.
Thank you so much for your quick response. But it's slightly different form what you have described. Sorry, I think the screenshot was a bit too small to read. It's QuaLITY number and not Quantity.
The way we work at the 'development' stage of design / garment / fabric, we firstly create list of FABRICS (we call it "QUALITY NO.' instead of Fabric No) that we intend to include in the collection (some gets droped due to many reaosns). During the development, we also decide what of colours for each Fabric to be in the collection.- again, some colours may get dropped or added in the development stage, so the colours are usually displayed in the Portal. At the same time but separately, we work on the Design of Styles such as coats. During the development of the 'styles' such as coats, we deicde how many of what components of what size to be used for a specific style in order to request a 'proto' sample to a factory. At this stage, we don't need to specify what TYPE of Buttons (ie: metal / Horn / Plastic etc..) When the samples arrives & during the fitting, we may change the buttons detail - ie) initially specified for 6 buttons, but decided to reduce to 4 buttons at front. This menas I need the flexibility to delete / modify the all the Trims info (Buttons / or linings, Zips & metal parts..) so these infor should be in a Portal too. Until this stage, I have no problem creating the database. However......
The toughest stage: Once the Fabric / Colours / Styles / Trims (just size and Qty) for each styles have been finalised, we need to SPEC-if every possible trims and materials such as linings. FYI, FABRIC menas the MAIN fabric used to create the main body / outer shell of garments (so linings comes under TRIMS).
Ideally, all the Trims and Accessories information that I entered in the STYLE INFO prio to this stage to be displayed on my SPEC SHHET but still be able to modify per colour or per specific fabric (impossible task....?)
ie) Style No F051 Coat has 4 buttons at front regardless of what farbrication of this garment is available, so Ideally, all I need to fill in the (related?) field is just Button Code and specify what colour of button I want to use for each colours and 'application instruction' such as "front body sewn in mathing colour thread'. For the GREEN Coat, maybe GOLD buttons and BLACK Coat in SILVER, for example.
Then, the same F051 Coat in a DIFFERENT fabrication need to be SPEC-ed. I may want to use HORN buttons instead of BRASS for this one. By this time, I want to have the previous information of: SIZE / QTY / APPLICATION INFO ro appear for the same style in diff fabric in a portal..... how could I achieve this..?
The way I have set up at the moment, I need to re-enter SIZE / QTY / APPLICATION etc.. for each F051 style. If we use F051 coat in 5 different body fabrics, then I need to manually enter all above 5 times... If it's only buttons it's not a problem. But there are so many Trims & Accessories needed to specified for Production (stitchings, pocket bags, labels, eyelets, cords, contrast fabric on the pocket flaps etc...)
In the Portal, I need to have some of the fields are 'fixed' in the portal for the style no F051 but also in the same line of portal I want to have the fields which are flexible to be able to modify information. Although this may not be possible, I just wondered if there's any other way of achiveing something like this.
It's so complicated....
It is complicated, but the basic set up I have described would still seem a possible approach. As I see it, you have one basic level spec--the design of the coat for example. From this basic design, you then develop variations of the design by changing fabrics, colors, etc. SpecLevel 1 is your basic design, and then you create as many related Spec Level 2 records as need to produce specifications that list the specific materials used to make that coat. Information that is common to all the coats is stored a single time in the parent speclevel 1 or in a table directly related to it such as documents describing the basic design of the coat and a list of basic materials needed. Information specific to one variation is stored with a related SecLevel2 record or in a table related to it.
Hi Phil, I have tried based on what you've suggested (several ifferent versions), however, I still find it difficult to establish the correct relationship in order to get the true value / information / calculation at the end of the day. I have also included my Relationships screenshot below. I wonder if you could suggest where this is going wrong for me? Have I done what you have suggested?
Before using the Filemaker Pro10, these are done on Excel, and basically, I want to achieve the similar layout but all the data to be true value (for calculation and reports later on).
BLUE highlight: this is where I am struggling to get using relationships to be able to enter WHITE colour buttons for this fabric of fabric colour of this style.
Whith what you have suggested, it will display in the record but the information of the records / fields in portal can't be properly related. (Good for display / print outs, but the data can't be used to work out order trim quantities etc..
Please let me know .... thank you very much.
Apologies, but this is not what I have suggested. All materials used to construct a garment should be listed in a single table. There should not be a separate table just to list the buttons used. Consider the tables you would have to add to list all other garment details suchs as snaps, zippers, etc. Fabrics, closure hardware and everything else should be drawn from the same centralized table to produce a detailed BOM for each different variation of the same garment.
At the basic spec level, you build a list of items needed to create the garment without specifying color/pattern etc. Physical size, and any other details common to all variations would be recorded in the BOMbasic table.
This table is then used as a reference to constuct a detailed BOM that does specify color and other details for each item in the bill of materials.
Thus the BOMbasic list of records will tell you that you need 5 1" buttons. The BOMDetailed table will list them as Red in one Spec level 2 record and as Blue in another. Both spec level 2 records will have different SpecLevel2 ID's but will have the same SpecLevel 1 ID number as they are the same basic design.
Please keep in mind that this has been presented to you at the basic out line level of detail. Additional table occurrences and scripting would be needed to fully facilitate all features of this approach.