Requests Module
A request is how a sector expresses a need for material at a given location. It is the starting point of the entire logistics flow: a validated request becomes (in whole or in part) an order, which in turn triggers a distribution on the ground.
Creating a request is reserved for sector members with the "can submit requests" capability (see sector roles). Validating, rejecting, and querying a request are reserved for the logistics coordinator — the logistics assistant can view a request but cannot decide on it.
Structure of a request
A request groups several lines; each line specifies:
- the product requested (from the Catalogue);
- the delivery location — mandatory on every line, TriLog rejects any line without a location;
- the quantity;
- a priority (to help logistics arbitrate when material is limited).
If the added product declares suggested accessories (e.g. the rubber pads for a half-muba), TriLog suggests them with the quantity already calculated. Nothing is added without your click, and the created line remains entirely editable.
Life cycle
| Status | Description |
|---|---|
| Draft | Being drafted by the sector, not yet visible to logistics |
| Submitted | Sent to logistics, awaiting processing |
| Queried | Logistics needs a clarification — the request goes back to the sector |
| Validated | Accepted by logistics — can now be covered by one or more orders |
| Rejected | Rejected by logistics, with a reason |
| Cancelled | Cleanly abandoned by the sector before any decision by logistics — terminal state |
The sector keeps control as long as logistics hasn't decided: a submitted request can be recalled to draft to be corrected, and a rejected request can be reopened to draft to be corrected and then resubmitted.
Status colors follow a strict convention throughout the application: orange = pending/submitted, green = validated, red = rejected. These colors are never used for anything else.
Cancelling a request
A member authorized to submit requests can cleanly cancel a request from their sector as long as logistics has not yet ruled on it:
- Draft or queried: cancellation is immediate.
- Submitted: it must first be recalled to draft, then cancelled.
- A reason is mandatory.
A cancelled request can no longer be edited or resubmitted. If the need arises again, it must be duplicated to start over on a new draft.
A cancelled request was never validated: it therefore never committed any budget nor was covered by an order, and its cancellation has no effect to carry over on that side.
Progress tracking (ordered / delivered)
Once one or more orders cover (even partially) a validated request, each line displays its progress:
- the ordered quantity and the delivered quantity, relative to the requested quantity;
- the current order status (and its reference) covering the line;
- the planned next delivery date, if known.
This lets the sector track its request all the way to the field without having to check the consolidated material list or distributions.
Duplicating or reopening a request
- Reopening a rejected request puts it back to draft so the sector can correct it before resubmitting it.
- Duplicating a request (regardless of its status — including rejected or cancelled) creates a new draft with the same lines, in the same sector: handy for reproducing a recurring need without re-entering everything. The new draft starts a clean life cycle — status, decision milestones, and the logistics message are never carried over.
If a line targets a location that no longer exists in the current edition, it is simply not carried over into the copy rather than blocking the duplication.
From request to coverage
Once validated, a request is not automatically "finished": it must be covered by one or more supplier orders. A few important rules to know:
- Coverage is calculated by quantity, line by line: a request line for 50 units can be served by two orders of 20 and 30, for example.
- If an order that covered a request is cancelled, the corresponding quantity is released — the request again becomes (partially) uncovered, and the committed budget is also released.
- See Orders & Quotes for the rest of the journey.
Amendments — editing a line after validation
A validated request can no longer be edited directly. If a sector needs to adjust a line (quantity, needed-by dates, location) or remove it, it goes through an amendment: a proposal that logistics accepts or rejects. The request stays validated throughout the process — the projected budget and the consolidated material list remain unchanged as long as the amendment hasn't been decided.
On the sector side: propose a new target value (not a delta) for a line, with a mandatory reason — setting the quantity to 0 is equivalent to requesting the line's removal. The proposal can be withdrawn as long as no decision has been made.
On the logistics side: accepting updates the line (the remaining-to-order follows automatically — two distinct warnings appear if a decrease creates a surplus that's already been ordered or already delivered) or rejecting with a mandatory reason, sent to the sector.
The sector must wait for the decision before proposing another one on the same line. A line can only be removed by amendment if nothing has been committed on it (neither ordered nor delivered) and it isn't the request's last line — otherwise, the entire request must be cancelled.
| Action | Logistics coordinator | Logistics assistant |
|---|---|---|
| Accept or reject an amendment | Yes | No |
Amendments left without a decision for too long show up in Alerts & Reminders.
Full step-by-step guide: see the tutorial →
Tutorials
Full step-by-step guide: see the tutorial →
Full step-by-step guide: see the tutorial →