What Makes Super Descriptors So “Super,” Anyway?

When building InfinityQS projects and setting up data entry configurations, sometimes clients are in a quandary on whether they should use some of the pre-defined ProFicient "super descriptors" like Lot, Job, Shift and Serial Number.

"What are the advantages?"

"Should I save them for something special?"

"I have Work Orders or Batches, not Jobs or Lots; can I still use them?"

These are common questions, but good questions to ask! There are many reasons that someone would want to use a super descriptor, and this blog won’t be a completely comprehensive discussion of all the possible reasons, but it will give some ins-and-outs that should be considered.

Super descriptor advantages

A user-defined descriptor could be created for Lot, Job, Shift, Batch, Work Order, Crew or almost anything else one can think of. There are some things that can’t be accomplished as easily with user-defined descriptors. Here are some examples:

1. In order to use ProFicient’s lot genealogy/traceability functionality, the Lot super descriptor must be used.

Sometimes clients have a requirement to display capabilities or other metrics by something beyond Part, Process and Test. Super descriptors can make this very convenient.

2. In order to use ProFicient’s lot acceptance sampling functionality, the Lot super descriptor must be used.

3. When creating an SPC Monitor or a Capability Report, super descriptors can be used as sort criteria.

4. Lot and Job can be used to create unique specification limit records. This is not something that most users need, but this can be very common in some industries (aerospace comes to mind). If this is something that is needed, users rely on Lot or Job to provide this flexibility.
5. Clients may need or want to retrieve data and/or a descriptor based on a previous entry. This option can save the end user the hassle of having to continually select descriptors while helping to error-proof data entry. We’ll talk more about this farther down.
6. In order to use ProFicient’s job-controlled data entry functionality, the Job super descriptor must be used.

Basic Requirements – Things to Know

Before using any of the super descriptors there are a few things to consider:

Lot – The Lot super descriptor is associated with a Part and not with a group like most other items in ProFicient. This means that ‘Lot 123’ for Blue Part can only exist once in the database. If ‘Lot 123’ has been used for Blue Part and closed, the user cannot add a new ‘Lot 123’. The only way to enter data against ‘Lot 123’ is to reopen the lot from Database Manager. Because Lot is associated with a Part, this does mean that there can be a ‘Lot 123’ for Blue Part and a ‘Lot 123’ for Yellow Part. If the descriptor you intend to use repeats, the Lot is not the super descriptor to use!

Job – The Job super descriptor is associated with a Job Group, which means that ‘Job 123’ can only exist once in the database.

Serial Number – The Serial Number super descriptor is associated with a Part and is a piece descriptor, which means a subgroup with multiple pieces can have multiple serial numbers associated with it.

Use Case: Plastic Molding

While working with one client in the plastic molding industry, they had some reporting and data entry options that were addressed by the unique use of a super descriptor. The customer ran materials in batches or lots, and it was decided to use the Lot super descriptor. A few requirements that came up during initial discussions were:

1. The need to easily report capabilities of each mold.

The client had always reported capabilities for each mold and they absolutely needed to have this functionality going forward.

2. The need to associate specific cavities with specific molds.

Different molds had different cavity schemes, and it could get confusing for the operator. For example, some molds all started with ‘Cavity 1,’ while others used non-repeating cavity numbers. In the latter case, ‘Mold A’ may have 8 cavities and start with ‘Cavity 1,’ while ‘Mold B’ also has 8 cavities but starts with ‘Cavity 9’. How can the operator keep this all straight?

Do any of these requirements sound like something you’ve heard about super descriptors? After a lot of discussion, it was decided to use the Job super descriptor for each Mold. The language was customized so that instead of being called Job, the super descriptor was now called Mold. This small change greatly simplified the message to the operator.

Making it ‘Work’

Once the "Mold" super descriptor had been established and the mold numbers were populated into the database, we needed to associate the cavities specific to each mold. How can this be done? When building a data entry configuration, there are many options that can be used for descriptors and one option under ‘Selectable by user’ is ‘Use last saved database value’. When retrieving database values, you utilize the ‘Filter’ button to determine how the correct descriptor should be found. The following setup will retrieve the correct cavity descriptor based on the Mold and position in the data entry window.

This function works by looking for the last subgroup meeting the specified criteria and looks at which descriptors were used for each entry. This is very important to know for a few reasons.

• If a new mold is added, these descriptors will not be able to be associated automatically. The association must be made for the first subgroup and will then be available for future queries.
• The filter applies across the entire database, not just the specific data entry configuration or project being used. Be sure the filter holds up against all data being entered!
• Because these filters are run against the entire database, complex and large queries (with a large date range) can degrade the performance of the project.

After discussing the disclaimers above, the client agreed and we forged ahead. It was really neat to see an operator choose a mold and the system just "knew" that Mold A had cavities 1-8, Mold B has cavities 9-16 and Mold C has cavities 17-32, but only the odd cavities were measured. Though it was not exactly something for the end operator to brag about, the quality staff and I knew it was a system that would ensure the operators would enter data in the correct sequence and not incorrectly double-select cavities, etc. Fantastic!

What About User-Defined Descriptors?

When should one use user-defined descriptors? I can think of several instances:

1. You have run out of super descriptors!
2. Your descriptors aren’t associated to specific Parts.
3. Your descriptors will repeat (cavity number, mold number, etc.) and have no need for the status control (open, close, hold) that Lot and Job provide.

It is common for clients to have more items that they want to track than just Lot and Job, so user-defined descriptors become a great way to accomplish this. One interesting thing to note is user-defined descriptors are unique based on their group. For example, the descriptor ‘Cavity 001’ can be listed in the group ‘Mold A’ and ‘Mold B’. This is only the case with a few other items in the InfinityQS database, and can be convenient, but please remember that ‘Cavity 001’ (in ‘Mold A’) and ‘Cavity 001’ (in ‘Mold B’) are completely separate items as far as the database is concerned, so make sure your chart data selection is correct!

Finally, notice that the cavity descriptors just listed were ‘Cavity 001’, as descriptors are sorted alphabetically. If a list of 100 cavities were created as, ‘1, 2, 3…98, 99, 100", the list would be sorted as "1, 10, 100, 2, 20, 21…". Just remember this and take it into account when creating your descriptors and they’ll sort as your users expect and provide the information that you need.

I know this blog has been a bit of a novel, so thanks for hanging in there. I hope you’ll find it useful!