Inspection Results Tables

The end goal here: I am trying to get inspection data entered through MES into information that the Operator can use at point of entry and Quality can analyze for trends.

I can join the InspResultsNum table to the JobOpr Table [via Company, Key1 (Job), Key2 (Assy), and Key3 (oprSeq)]. But I have to pull all 200 Fields from InspResultsNum to identify the eight fields that are actually entered for this job/Part (of course there will be 8 different fields for the next Job/Part).
In addition when the data is pulled; the fields are Number001, Number002, etc. This is not a useful descriptor for knowing what data you are looking at for analysis.

Joining the InspAttr table (InspAttr has the Field Name assigned to the Inspection Attribute) to the InspResultsNum table, so you could at least see the Number001 Field Name associated with an Attribute Description in each row of inspection data, doesn’t add value because you get one-to-many multipliers because there are 50+ attributes in the table.

I am concluding that I will need a unique BAQ for each Inspection Plan, SpecID, Attribute, etc. To display/analyze them effectively. I hope I am missing something really easy here.

As I understand the Enhanced Quality module (which is where Inspection Plans live), it’s the “Inspection Plan” wrapper that customizes which fields in which table belong to which Inspection Plan… which are only available through Inspection Processing.

You’d need to write some process to call an Inspection Plan from each operation at the MES “End Activity” point… and you’d still have to write an Inspection Plan for each job/operation combination.

Report Quantity has a button on the lower right corner that will pull up the inspection plan and subsequently an ‘Inspection Results Entry’ Dashboard.

I will look more closely at the Inspection Plan table to see if I can use that to navigate the inspection results tables better.

We just rolled out our first line on what we’ve termed an “Electronic Traveler”. This is a series of Inspection Plans set to operations for a top level device that capture the measured data and make a pass/fail determination. The BAQ I put together was/is pretty unwieldy, but it we have it feeding into a BAQ Report so it doesn’t need to be visually appealing yet. It’s similar to what you have in place, InspResults linked to all the lower tables and joined to LaborDtl.

However, I’m not a SQL guru, but I imagine there would be a way to do a compare against the SpecAttr and the InspResultsXXX tables to pull in only the fields that match. You would then have a parameter for the Spec you want to review and that should help narrow down the list considerably. I know we’ll be tackling this soon, so I’ll be sure to report back once we make some headway here. We’re still in transactional triaging, so it’s tough to keep my head above water at times.

One thing I will say is that there wasn’t much pre-made content to base our work on. A lot of what we had to build was done by trial and error. I normally like to find an out of box report to deconstruct and find out how things work, but there wasn’t anything like that in this space. I even chatted a bit with the Product Manager about this which did help a bit, but confirmed that I was more or less on my own.

I think the Inspection Results Tracker Dashboard (name may not be exactly correct) is a pretty good indicator of where this is headed. There are lots of parameters to enter and the results pare the columns down to the Specific Plan and Specification, but the header columns are still Number001, 002,etc. Leaving the user to open the User to backtrack to the Attributes/Specifications to determine what the data means.