Lessons · Lesson 3 of 5
What a CAPA holds
The twelve columns of the corrective-action record, the four it does not have, the strictly forward workflow, and what the application decides is worth raising one over.
Lesson 3 of 5 · 22 min
What this lesson is about
A corrective action is the industry's standard answer to a fault. Something went wrong. Somebody works out why. Somebody fixes the cause. Somebody else checks that the fix held. Most buyers ask for one by name after a quality failure, and many will not close a complaint until they have it.
This application has such a record and calls it a CAPA, which stands for corrective and preventive action. This lesson opens the record and reads every field in it. The shape of the record decides what a corrective action can be used for later. A record that cannot hold a cost cannot answer a question about cost, however carefully it is filled in.
Twelve columns, read in full
Here is the whole record. Not a summary of it.
| Column | What it holds |
|---|---|
| Identifier and number | The row's own key, and the human-readable code |
| Order | Which order this CAPA belongs to, and it is required |
| Problem | Free text, the only required description |
| Root cause | Free text, optional |
| Corrective action | Free text, optional |
| Preventive action | Free text, optional |
| Owner | Free text, a name typed in rather than a linked user |
| Due date | Optional, and it is what makes a CAPA overdue |
| Status | One of four, described below |
| Created and updated | Two timestamps |
Now the absences, because they are the reason this lesson exists.
There is no cost field. Nothing on a CAPA records what the fault cost, what the fix cost, or what was recovered. There is no supplier field, so a corrective action against a mill is filed against the order the mill's fabric went into, rather than against the mill. There is no buyer field either, for the same reason. And there is no attachment or evidence link on the record itself.
The consequence is precise rather than dramatic. A CAPA is an excellent record of what somebody decided to do about a fault. It is not a record of the fault's consequences, and it was not built to be one.
The workflow only goes forwards
Four statuses: open, in progress, verified, closed. The moves between them are declared as an explicit map, and the map is a straight line.
- Open moves only to in progress.
- In progress moves only to verified.
- Verified moves only to closed.
- Closed moves nowhere.
Every step offers exactly one next action, so no step is ever a dead end. The buttons read Start work, then Mark verified, then Close CAPA. On a closed CAPA there is no next action at all.
Try to skip a step or go back, and the server refuses. It names both ends of the illegal move in their display labels. That refusal sits in the data layer rather than in the screen, which means it holds for any caller.
Where the name of the decider is written
The CAPA row itself records no actor. It has a created timestamp and an updated timestamp, and no column for a person, other than the free-text owner somebody typed when raising it.
The actor is recorded elsewhere, and this is worth being exact about. When a CAPA advances, the app writes a line into the parent order's activity feed reading "Quality: CAPA-1004 → Verified (by Thilini Senanayake)". So the audit trail exists, it is complete, and it lives on the order rather than on the CAPA.
That has a real consequence when a buyer asks for the history of one corrective action. You cannot read it off the CAPA. You read the order's activity feed and pick out the lines that name that CAPA number.
What the app thinks is worth a CAPA
The application does not wait to be asked. On the quality board and the production board it rolls up the defects logged against each order, compares them to the output recorded for that order, and decides whether to suggest raising one.
Two rules, in order.
- A critical-severity defect always triggers. The reason it gives names the number of pieces.
- Otherwise a defect rate above the threshold triggers, and the reason quotes the rate and the threshold together.
The threshold is 5%, and it is a constant in the source rather than a setting. The function that reads it accepts a threshold as an argument, but both screens that call it pass none. So 5% is what your factory gets, and there is no page where an owner can change it.
The third rule is the honest one. The defect rate is total defect pieces divided by recorded output, and when the output is unknown or zero the rate is null rather than zero. A null rate never triggers on rate alone. An order with nine hundred defects logged and no output recorded raises nothing, because the app will not guess at a denominator it does not have.
The defect records the rate is built from are their own small table. Ten columns: the order, the defect type, the stage, a quantity in pieces, a severity of minor, major or critical, a location, a source, a timestamp, and who logged it. A quantity of pieces again, and no cost.
The overdue CAPA on your board
A CAPA with a due date in the past, still open or in progress, becomes a red exception on My Work. Verified and closed ones drop out, and a CAPA with no due date can never be overdue.
The card names the CAPA number, the order it belongs to, the due date, and the first stretch of the problem text. Its link goes to the quality board rather than to the CAPA, because there is no page for a single CAPA in this application. The board is the work surface.
Check yourselfBrekstad claims for a hood-drawcord fault and asks Ratmalgoda for a corrective action, a root cause, and the cost of the rework. Say what the app supplies and what has to come from elsewhere.Show the answer
The app supplies the corrective action and the root cause directly, because both are fields on the CAPA and both are free text. It supplies the problem statement, the owner as typed, the due date, and the current status out of four. It supplies the history of who advanced it and when, though from the order's activity feed rather than from the CAPA. It supplies the defect records the CAPA was raised over, with a quantity in pieces and a severity for each. The cost of the rework is not in the app at all. No CAPA column holds a cost, no defect row holds a cost, and the only money field on the order is the agreed unit price. That number has to come from the accounting system or from a spreadsheet, and it should be attached to the order so the two halves sit together.
Check yourselfThilini finds the same seam fault on three orders from one supplier's fabric. Describe what the app lets her build, and the one thing she should write down that it will not hold for her.Show the answer
She can raise a CAPA on each of the three orders, because the order is required on the record and there is no way to raise one against the supplier. She can name the shared root cause in each of the three, and she can name the other two orders in each problem text so a reader can find them. She can log the defects against each order with their severities and quantities, which is what feeds the suggestion engine on the quality board. What the app will not hold for her is the link to the supplier. Nothing on a CAPA points at one, and nothing on the supplier record counts CAPAs raised over its material. If the supplier's performance is the point, that has to be written into the supplier's own record as a note, with the three CAPA numbers written into it by hand.
Prompt · Draft a CAPA that will still make sense in a year
When raising a corrective action, especially one a buyer will read.
Help me write a MerchandiserOS CAPA whose four free-text fields carry everything the record itself cannot hold. I will tell you: the order it belongs to, what went wrong, what we think caused it, what we did, and what we changed so it does not recur. The record has twelve columns. A number, the order, the problem, the root cause, the corrective action, the preventive action, an owner typed as free text, a due date, a status, and two timestamps. There is no cost field, no supplier field, no buyer field and no attachment on the record. The order is required, so a fault shared across several orders becomes several CAPAs. The status goes open, then in progress, then verified, then closed, one step at a time and never backwards, and closed cannot be reopened. Who advanced it is written into the parent order's activity feed, not onto the CAPA. Draft the four text fields for me. Keep the problem statement factual and dated, and keep the root cause a cause rather than a restatement of the problem. Because there is no supplier field, tell me explicitly whether a supplier is involved. If one is, put the supplier's name inside the problem text where it can be found. Because there is no cost field, tell me what the fault probably cost, and where that figure has to be recorded instead. If this fault touches more than one order, list the CAPAs I need to raise and write the cross-reference line to put in each.
AI can make mistakes — check anything you act on.