The technical director knows exactly what she needs: the inspection fee must be the one agreed with three distributors. What she doesn’t know is how to write a rule’s technical condition.
Before, that meant a ticket and a few days of waiting. Now she writes it the way she’d say it in a meeting.
What you write
«For Distributor A, B and C I want the inspection fee to always be 90,000. Prepare the rule and test it before saving it.»
And then
- «Save it and link it to the periodic inspection form.»
- «Activate it.»
How the assistant answers
For Distributor A, B and C I want the inspection fee to always be 90,000. Prepare the rule and test it before saving it.
I found the Inspection fee data, which the app sends. I prepared the rule and tested it with 10 cases: for each distributor, 90,000 passes, 85,000 blocks and empty blocks; another distributor passes with any amount. All 10 gave the expected result.
Message for the inspector: “For this distributor the inspection fee must be 90,000.”
Shall I save it? It will stay inactive and unlinked until you ask.
Illustrative example
Why it matters
-
It tests before saving
The assistant builds a table of cases: at least one that passes and one that blocks. If any fails, nothing is saved.
-
It starts switched off
The rule is created inactive and unlinked. Linking and activating are separate steps, and each asks for confirmation.
-
You decide when
Nothing changes in the field until you activate it. And if something isn’t right, you deactivate it or go back to a previous version.
The engine flags and the person decides. Rules only run when they’re active and linked to the form. How they’re configured
The person who knows the business configures the rule. The engine applies it the same way on every report.
