Check Products Quality

Rational

When receiving (and also after production) some kind of products there is the need to perform some checking on the goods received to ensure if they meet the quality requirements required for the product to be used.

The check is a list of questions which are replied with a text or with a numeric value. This value is compared against a formula to determine if it’s valid. Some examples of formulas are:

  • Value is in a list of valid values
  • The numeric values is between a range of numbers
  • Value is exactly one value

The list of question is predefined. The same list can be used for one product or for a set of products.

Proposal

Add model named Quality control with the following fields:

  • Name:
  • Active:
  • Controls: A DictSchemaMixin used to define fields with the list of questions that will be applied for this control.

Add model named Quality Inspection with the following fields:

  • Number: Used to identify the test
  • Date: When the check is performed
  • Employee: The employee responsible of the test
  • Control: A Many2One to the quality control module.
  • Values: A dict fields with the values of this control.
  • Origin: A reference field to indicate where the check is being done. (By default it will only accept stock moves or productions if the production module is installed)
  • State: Requested/In-Progress/Cancelled: Only special group is allowed to cancel.

The product will be extended to include a the Quality Control which should pass and a Frequency to indicate when it should be performed (in case not all the products are tested). A boolean field Blocking will be also be used to indicate that the Quality Inspection should block the origin.

When receiving products for this product a new quality test in request state will be created. The test will be in request state and it’s origin will be the stock move that triggered it.

If the product has the blocking flag it won’t be possible to finish the supplier shipment related to the move (if any) until all the quality inspections have been finished (done or failed).

For production, the inspection will be created when running it (if the produced product has a qualityt control) and if blocking it wont be possible to finish it until the quality inspection is finished (done or failed).

Implementation

issue7600

1 Like

So a kind of quality lot?
It should be linked to the batch of a material (if exists).
What happens with the production lot until the quality examination is finalized? Is it blocked or free for use?

I think what you describe is usually called “Quality Inspection” and is probably part of a larger “Quality” area (instead of limited to Stock). At least it applies also to Production orders.

I think it can be applied to more operation like on: customer shipment, internal shipment, work order etc.

You do not define what happens with the result. It seems logical that when it is valid, you can perform the operation but if it is not valid what happens?

Does it really requires to use PYSON? In the rational you define only 3 tests which could be implemented without the usage of PYSON. I think it will make the UX better as it is non-technical users who will have to create those tests.

Is it not better to use a Dict field? As potentially you can have a lot of values to collect, you will have a better UI is they are presented as a standard form.

It is missing a Failure state.
I think only a specific group can cancel an inspection.
I do not see the point of having a draft state. For me, inspection will be created automatically and will not require adjustment or validation.

I do not think it is the right criteria. For me, the inspection should be based on the document like shipment or work order (maybe also production order).
Also I think it should mainly based on the template/product criteria.

I think it should be based on a frequency. Often you do not have the time to check everything but you perform random inspections (of course user could put 100% to always have one).

But what happens to the document triggering it? I think it should be blocked in state until inspection is finished (and maybe succeeded).

Hi,
I have a older module http://repos.gewinnmonitor.de/LZR/quality which uses also test templates, possible qualitative and quantitative values and related equipment. It is now related to project.work but I agree that it could be related to any kind of model. Unfortunately it has fields only valid for coating industries but I think without that it could be a starting point.

We have the use case where some of the lines may contain invalid values but the operation is always performed. Instead of blocking the operation what is done is to apply some rebate on the price.

That makes me think that blocking should be part of an extra module.

I agree that for the UX it’s better to use a Dict field and thought about that but I was more worried about keeping the relation between the entered values and the valid values. How will be able to define the 3 tests (a concrete value, a list of values and a range of values) on a dict field?

Ok, I updated the description.

In this case what happens when receiving different products on the same shipment that have to pass different Quality Inspection? There is not direct relation between the inspected product and the inspection

Also when using lots, you want to know on which exact lot you applied the quality inspection.

Ok, so on the product template we can specify the Quality Control and the frequency when it has to be performed.

Don’t understand what do you mean. Our proposal is to link the quality control with the stock move (but use a reference field in case people want’s to use other models), so it is linked with all the received products and if the move has a lot, it’s also linked with this lot.

We did not consider blocking as we have use cases where there is no blocking. But as I see that there is a common need on it, I propose to add a boolean field on product template to indicate if the quality control should block.

This is done with the key of the dictionary.

I’m not sure to understand the question. But there are different types for dict values and if necessary the dictionary field can be improved.

Nothing prevent that inspections are created from the document workflow for each products involved.

You can create inspection for each lot involved.

But the important point for me, it is that the workflow of document should trigger inspection and not the low level move.

Ok, so lets go with the dict field.

I see one improvement here, but probably only related to quality inspections. As all the keys of the dict field are optional, we should allow to define which values are required in order to finish the quality control.

Ok, I understand your point. So it makes sense to trigger the actions on document level.

I think we could implement a domain constraint on the value of the dictionary: Add value validation on Dict field (#7199) · Issues · Tryton / Tryton · GitLab

I do not think it will require to be managed by the Dict widget but a domain can make invalid an empty value (see Add required and help attributes in Dict fields (#4268) · Issues · Tryton / Tryton · GitLab). So this will need to be enforced on the server side.

We’ve found the need to have several results from the quality inspection. Our our case a result is something that can be computed from inspection values using a formula.

Is this a general interest requirement? Should we introduce it on the standard module?

I’m wondering if we should allow the user to define on which operations should the inspection be applied. This can be done using a multi-selection fields like we do for the lot_required field on stock.

Modules should be able to define which operations are available.

This will allow to make the stock and production optional dependencies which only register when the inspections are created.

I think you try to specify too much at once. Make first an initial simple prototype without anything that could be added later. So we can talk with concrete examples.

I’ve uploaded our initial implementation, it lacks the support of frequency and blocking but this was not a requirement for us.

I have a couple of things that I would like to mention that I think are relevant to this topic, and it would be good if the module allowed them to be implemented easily in additional modules:

  • I have seen Acceptance Sampling Plans used to only check a small percentage of the items on a delivery where the quality tests were destructive, or it was infesible to test all of the items on a delivery.

  • In some cases I have seen, the testing frequency is based on the product and which supplier a product has been sourced from.

    Suppliers would be rated based on things such as whether they have a particular quality management system in place, or their supply history.

    Deliveries from highly rated suppliers would be inspected less frequently compared to suppliers that were rated poorly who would have all their deliveries inspected.

    So, it would be good if it was easy to modify/expand how the frequency is determined in additional modules.

I have tested this module and I think that it would be beneficial to add the Control field on the Product Category.

In my particular use case I find that I’m having to create multiple product templates which are the same product but sold in a different sized package or just in a different unit of measure.

I’m thinking an appropriate module name could be product_control or product_quality_control.

Indeed I think it will be better to create some set of ruling system to allow a more flexible definition of quality controls. In this matching rule we should include the product category the product but also the type of the source location.

This will allow to define for the same product, diferent quality controls depending on it’s origin. This way it may be possible to have a quality inspection when producing a product, but also before a diferent one when receiving the same product from a supplier.

I updated the proposed review to implent such feature and completed other missing features.
So the review is now ready for testing.

I also included the frequency test, so it is now possible to test a subsest of the delivered items.

2 Likes

What is the difference to car, bike or plane maintenance inspections coming from shipment in, customer returns or sale complaints?
Those maintenance inspections usually also have a plan of single checks what to do and a collection of the results. For me the requirements are similar.

From reviewing the proposal, I think we must target a more generic usage of quality inspection.
So globally the design of inspection and control are generic enough but it is how they are linked to documents that bother me. I think the module must provide facilities to “plug” the inspection on any workflow transition by popping up a wizard which create and show the inspection form to fill. Then the transition may or may not continue depending on the success or failure of the checks.
For failed checks, the user should provide an “action” to be able to continue. So when triggering again the transition and if there are failed checks, the user will have to comment about the action he performed to solve it. For example for a receiving, he can put away in a specific location and create a return shipment or for a production, he can scrap the produced product etc.

I think also that the check should be able to work for service product like that we can trigger quality inspection on project task done for example.

The check depending on its nature should have valid range of value (for a numeric check).
Also I think it is better to use a tailored schema model than using the generic Mixin because it is too complex to be used for this purpose and it can be made much more simple by removing many of the unneeded feature.

1 Like