ZEMERCZEMERC Engineering Deliverables Studio home
7NotificationsAR
Menu

Workspace

Documents

Engineering intelligence

Registers

Plant and assets

Standards and requirements

Deliverables

Review and issue

Planning and integrations

Administration

Create a project

Code, client, contract, units and the disciplines this project actually covers.

Demonstration project - no figure here describes a real facilityChanges are not saved
Why

The code, name, client and discipline selection are validated by the project service before anything is written.

Writes are validated against the engineering rules and then refused, because no database has been configured for this environment.

Project details

Letters, digits and hyphens: it becomes part of every document number

Appendix letters are read from this contract, never presumed

A project convention, not a display preference

Several hierarchies over the same assets; they need not line up

Disciplines*

There is no default. A project with none is refused.

There is no default engineering discipline

Defaulting to commissioning, or to anything, is how every project on a platform comes to look like the discipline the platform was first built for - and how a piping engineer discovers six months in that their deliverable types were never configured.
The code goes into every document number

A code with a space or a slash in it produces document numbers that cannot be used in a file name, a transmittal or a URL. It is checked here because changing it later means renumbering everything issued under it.

What happens next

  1. The project is created with status “setup”.
  2. Tag grammars and numbering conventions are configured.
  3. Team members are added and project roles granted explicitly.
  4. Documents are uploaded and the registers build from them.

Approval rights are never a side effect of membership: an approver is granted that capability by name.