Skip to content

Tenders (invitations to tender)

A tender is a procurement process: a buying group invites suppliers to answer a set of questions (an Invitation To Tender, or ITT) by a deadline, compares the responses, and converts the winning response into a deal. It reuses the questionnaire field types (enum, numeric, text, textarea).

The pieces

  • The tender — name, product range, administrator and negotiator, category, the question set, spend estimate, and the key dates (start, end, completion deadline, and negotiation window).
  • Invited suppliers — one invitation record per supplier, holding that supplier's answers, completion flag, award status, and its own document folders.
  • The deal team — the internal people working the tender.

Each supplier gets a dedicated document folder tree (a folder for documents issued to them, one for their own uploads, and one for generated reports), scoped so the supplier sees only their own.

Lifecycle

  1. Create — build the tender, its questions, and invite suppliers. Inviting a supplier sets up their invitation record and folders, generates their ITT letter (a PDF placed in their folder), and sends them an in-app task notification.
  2. Active — a tender is live while its active flag is on and it is within its dates; archiving turns the flag off. There is no separate "publish" step.
  3. Respond — invited suppliers answer the questions on the tender response screen and upload supporting documents; they mark their response complete to submit it.
  4. Compare — responses are compared (via a generated answers report); a tender can also be compared against an existing deal.
  5. Award — accept a supplier (and reject others), which converts the winning response into a deal.
  6. Archive / delete — archive keeps the record; delete removes it.

Award status per supplier is free-text but the flow uses accepted, rejected, and prepped (an accepted supplier can be unlocked back to prepped to re-open their response).

How award creates a deal

Awarding clones a template deal, copies the tender answer values into the new deal's terms/elements, and sets the supplier, negotiator, administrator, dates, product range, and category from the tender — then saves and indexes the new deal. There are two variants: a header-only clone of the site's default deal, and a fuller one that copies the answer values into deal elements.

Who sees and does what

  • Members (staff) see all tenders and run them.
  • Suppliers see only the tenders they were invited to — the search is hard-filtered to their own company — and can only respond to those.
  • Tender records carry their own view/edit/delete/admin ACL; with no rules set, view is open and edit/delete/admin default to superusers.

Notifications

Inviting a supplier sends them an in-app task notification (not an email); creating a tender notifies the creator. The ITT itself is a generated PDF placed in the supplier's document folder — the letter states login details are emailed separately, but no automatic email is sent from this code. The deal-team completion notifications are present but disabled (commented out).

Why does a tender behave unexpectedly

  • A supplier can't see a tender — they weren't invited (suppliers are scoped to their own invitations).
  • A response can't be edited — it was marked complete; an admin can unlock it (back to prepped) to reopen it.
  • Award didn't reject the other suppliers — accepting sets only the chosen supplier to accepted; rejecting others is a separate action.

What a tender is not

  • Not a deal — a tender is the process that produces a deal on award (Editing deal core details).
  • Not a survey/questionnaire — it reuses the same field types but is its own procurement feature (Surveys).