Importing a tender, without importing its future
Bid-On copies what it needs from the standard Tenders section and links back. It never reads it live, because a bid in progress must not change underneath somebody.
A provider whose customer’s tender is already recorded in CONSTRUX should not have to upload the same questionnaire twice. So a standard tender can be imported into Bid-On as a bid. It is a shortcut and never a requirement — a bid started from a questionnaire needs no tender in the standard section at all, and never appears there.
The load-bearing decision is that the import is one-way. Bid-On copies the fields it needs and links back. It never writes to the source tender, and nothing in the standard section is aware it happened.
The reason is not tidiness. If the bid read the source live, deleting a document there would silently remove the evidence an approved answer cites, and editing a return date would move every certificate-expiry verdict in the pack without anybody touching the bid. So the fields are copied at the moment of import, and any file the standard section registered against that invitation comes over by its content hash — which is what lets the questionnaire be parsed without anybody uploading it again, and what means the bytes cannot change under it afterwards.
When the source does change, the bid says so and waits. A change at source is a banner, not a re-parse. A silent re-parse would overwrite approved answers with drafts, and an approved answer is one somebody put their name to.
The drift is found by comparing a stored reading of the tender against the tender as it stands, on every read — rather than by subscribing to a change event. That is the better mechanism and not merely the available one: a missed event leaves a bid silently stale for ever, while a reading that no longer matches is wrong on every read until somebody acts on it.
Resync is then safe to press, which is the only property that matters about it. Approved answers survive. Only a question whose wording actually changed goes back for review, matched on text against the buyer’s own number, and every version is kept — the answer approved against the old wording is what a dispute about the old wording would turn on. A question whose number moved or whose heading was retyped is the same question, and throwing away a good answer because a buyer fixed a typo is how a resync becomes something nobody dares press.
It takes the new wording as its argument rather than re-reading the documents itself, because re-reading is a paid model call. The sequence a person follows is: see the banner, read the changed document, resync with what it now says. Folding the parse in would make resync a button that silently spends money.
See the record being made rather than described.
Launch the demo environment