← Guide

Defects — the contractual register

The imported contractual quality register: what a defect is (and why it is not a snag), uploading a per-contractor export, the status × closed pair, who sees which rows, and what the diary counts.

A Defect is a contractual quality event: work not in accordance with the Scope, notified between the two contracting parties under NEC4. It is not a site observation and it is emphatically not a Snag — different parties, a different register, and different legal weight. Where the contract names a communication system for these notifications (South Clyde names Sypro), that system is where a defect is raised and accepted, and the SimOps record is derivative: it arrives by import, and import is the only way in.

What SimOps does and does not do here

SimOps holds the register so the site can read it beside everything else — the diary's QA/QC counts, the commercial picture, the contractor's own list. It does not run the lifecycle: there is no raise, no correct, no certify and no close anywhere in the app. Those acts happen in the named system, and the next upload brings the result across. Native lifecycle is deferred by name in defect-domain-object, not forgotten.

Two consequences worth internalising before you go looking for a button that isn't there:

  • A defect never gets created in SimOps, so there is no defect dock button of its own. The register has two read doors, one component behind both: the Imports panel, beneath the source that feeds it, and — for defect_view holders outside the coordinator band, who never see Imports — the Defects tile on the Commercial surface (I).
  • A snag never becomes a defect and a defect never becomes a snag. A snag that turns out to be contractually serious becomes a defect by being raised in the named system; it then arrives here on the next import as a separate row. There is no promotion path in either direction — see Snags & work close-out.

Task 1 — Import a contractor's register export

You need the coordinator band (defect_import — coordinator, site manager, admin). The download-and-upload dance is the principal side's job; a contractor does not upload a register about itself, and the QS is read-only here by definition.

  1. Open the Imports panel (Z) and choose the Defects source — "Upload a contractor's defect register export, and read the register."
  2. Pick the export file (.csv or .xlsx). One firm per upload: every row is filed against the contractor you confirm on screen, never against a company name read out of the file.
  3. Check the contractor. SimOps matches the filename and offers "Suggested from the filename: … — confirm or override below", or warns that nothing matched; either way you confirm or override in the select before the import will run. Pick the layout too if the site carries more than one (the shipped one is the Sypro Defect Register).
  4. Press "Import register". The result reads "{contractor} · {n} added · {n} updated · {n} rows read", and any rows the parser refused are listed individually with their event reference, the offending column and the value — fix those in the source register and upload the corrected export again.

Note: Re-importing is the normal case, and it is an upsert, never a replacement. Rows are matched on (site, contractor, event reference): an existing row has its fields updated, a new reference is added, and a row missing from the file is left alone. Registers do not shrink — one filtered download must never be able to destroy the site's register.

Task 2 — Read the register

  1. In the same Defects source, the Register sits under the upload zone for anyone with defect_view — or open the Commercial surface (I) and pick its Defects tile, the same register read-only (the door for defect_view holders without the Imports panel). Its header carries the whole-register counts: "{n} open · {n} closed".
  2. Band the list with Open / Closed / All. Openness is not a status — it is whether the row has been closed at all (see below).
  3. Narrow further with the status select (Awaiting correction / Corrected / Acceptance proposed) and the search box, which matches reference, title, description and location.

Status and closure are two different questions

The register's status vocabulary is the observed one — the values that actually appear in the source export, versioned in the repo: awaiting_correction, corrected, acceptance_proposed. A value SimOps has never seen is a visible import error, never a silent "other" — the register would rather refuse a row than quietly mislabel it.

Closure is deliberately kept separate from that vocabulary, as a closed at / closed by overlay:

Reading What it means
corrected, not closed One party's claim that the work has been put right. The settlement has not happened.
corrected, closed Claim and settlement — the pair a person reads off the source system as "done".
awaiting_correction, not closed The ordinary live row.

So open means "not closed" — the row has no closure stamp — and that is exactly the query the diary's QA/QC count runs. Collapsing status and closure into one boolean would present one party's claim as settled fact, which is the whole reason the pair exists. Note that "closed by" is a name from the other system: the person who closed the defect need not have a SimOps account at all, so it is recorded as text rather than as a user.

Note: Prevents completion is carried through from the source register and shown as a badge. It is a flag, not a gate — it never blocks a Completion record. Wiring a periodically-imported flag into a hard write-block would let a stale download freeze real work on site.

Who sees which rows

Visibility mirrors the private per-contractor pages of the system these registers come from:

Role Sees
coordinator / site manager / admin Every defect on the site (and these three can import)
commercial (QS) Every defect on the site — defects carry uncorrected-cost money, so the QS is in
member (of a contractor) Their own contractor's defects only, enforced server-side
hse Nothing — HSE holds no defect read permission at all, so it never reaches the register: defects sit on the quality/commercial axis, the same reasoning that keeps HSE off snags. The own-contractor scoping in the row above filters only readers who already hold that permission, so an HSE membership that also carries a contractor link still sees nothing
viewer / client / contractor HSE Nothing

A row outside your scope does not appear filtered-out; asking for it directly returns a plain "not found", so a scoped-out member never learns it exists.

Note: Unlike the site diary, the defect register is deliberately not main-contractor-gated. A subcontractor reading their own defect list in SimOps is the point — it is a surface that pulls them in. The two registers ship in one build and share nothing else.

What the diary counts

The diary's QA/QC section asks how many defects are open and closed, and answers it as a register query at publish time rather than a number somebody keys in — so the figure is exactly as fresh as the last upload. That count is site-wide, deliberately unlike the register list, which shows you only your own scope: the diary is the main contractor's document about the whole site. It is also the one place a reader with no register access meets defect data at all — the count is an aggregate over the site, not a row read, so it is not scoped by the table above.

The neighbouring QA/QC question — quality issues raised today — offers snags raised today and defects imported today as suggestions, which is the one place the two nouns sit side by side. They are still two registers; the question simply asks about both.

Gotchas

  • Nothing here is editable. No raise, no correct, no close, no delete. If a row is wrong, it is wrong in the source register — fix it there and re-import.
  • The file's company columns are ignored on purpose. Notifying company, notified-to company and notifying user ride through untouched into the row's passthrough data; the upload scope is the defect's contractor, full stop. Parties are not modelled.
  • Don't call it an NCR. "NCR" is ISO 9001 vocabulary that SimOps does not carry, and "Defect Notification" is the other product's noun. The word here is defect.
  • Clause numbers: check yours. The NEC4 numbering behind this object — Defect defined at 11.2(5), correction under cl 43, acceptance under cl 44, uncorrected cost under cl 45 — is the numbering the design record carries. Verify it against your own contract before quoting it at anybody.

See also: Snags & work close-out — the own-work noun this is not · Blockers & delays — the comparison table · The site diary — where the counts surface. Terms: glossaryDefect, Snag, Completion record.

Site diary guide: The site diary · Filling in your round · Defects register

Was this page useful? Report a problem

No cookies and no third-party analytics. A verdict records this page's path — and a search that finds nothing records the words you typed — in this site's own server log.

Generated from source · SimOops living system reference