Backorders and stock allocation
Two different questions are being asked about the parts a visit needs, and the Service screens answer them in two separate places.
Is the part available? That is the Backorder Status column in the Jobs list, and the badge on the activity: Backorder Available, Backorder Not Required.
Has the part been set aside for this visit? That is Stock Allocation Required, and the Allocated columns on Required Items.
An activity can be Backorder Available and Stock Allocation Required at the same time. The stock exists somewhere; nothing has yet reserved it for this job. Reading only the first badge and dispatching an engineer is how a visit fails on arrival.
Why they are separate
Stock is shared. A part sitting in a warehouse is available to every open job that needs it, and stays available until something claims it. If availability and allocation were one flag, the first person to look at a job would either have to reserve the part immediately — starving every other job — or leave it unreserved and have no way to record that they had checked.
Separating them lets the desk triage cheaply. Availability is a fact about the warehouse and costs nothing to read. Allocation is a commitment, and is made deliberately, closer to the visit.
The location matters
Each required item names the Location it is expected from. Availability is availability there. A part in a warehouse three states away is available in the sense the badge means, and unavailable in the sense the engineer means — the two are reconciled by whoever schedules the visit, not by the badge.
What Generate Backorders does
Where an activity needs items that are not in stock, Generate Backorders raises the backorders for them, which is what moves the job onto the On Backorder tab. That tab is worked against stock arriving rather than against the age of the job: chasing a job whose part has not landed changes nothing.