Transmittals & the exchange register
このコンテンツはまだ日本語訳がありません。
What a transmittal is
Section titled “What a transmittal is”A transmittal is the formal, numbered way to issue documents: “under reference P0109-TX-0003, we transmit these five documents to these two organisations; please acknowledge.” Where a share is a convenience, a transmittal is a record — construction and engineering contracts usually require exactly this.
Each one carries:
- A reference issued automatically from the project’s sequence —
<project token>-TX-0001,-TX-0002, … - A subject and optional message.
- The documents, pinned at their current revision — what you transmitted stays what you transmitted, even after later uploads.
- The recipients — one or more of the project’s delivery partners.
- An optional acknowledgement due date.
Sending one
Section titled “Sending one”Open Transmittals in the sidebar’s Files group and press New transmittal — or press Transmit… on the file browser’s toolbar or in a document’s drawer (it arrives pre-ticked). The document picker lists everything transmittable grouped by folder, with a select-all per folder — tick a whole folder or individual documents. Then the recipients, subject, message, due date, send.
Rules the composer enforces:
- Only Shared, Published or issued documents can be transmitted — WIP and drafts refuse (issue them first).
- A document mid-upload can’t be transmitted.
- Recipients must be delivery partners of this project.
Each recipient organisation gets an email and sees the transmittal in their portal’s Transmittals section, listing every document with a download link.
Acknowledgements
Section titled “Acknowledgements”The recipient presses Acknowledge receipt in their portal — once per organisation. The operator view shows each recipient’s state, and a transmittal past its due date with recipients still silent is flagged overdue. Acknowledgements also land on the exchange register, so the paper trail is complete without leaving the platform.
Transmittals from partners
Section titled “Transmittals from partners”Formal issue runs both ways. A delivery partner with the editor role can transmit its deliverables into your CDE — the ISO 19650 appointed-party hand-over — picking documents it has issued, giving a subject and an acknowledgement date, and issuing to the project team.
These arrive in the Inbox on your Transmittals page, badged awaiting receipt. Open one, check the documents, and press Acknowledge receipt; both sides of the exchange land on the register, so a partner can prove they issued and you can prove you received.
They take numbers from the same project sequence and follow the same rules as yours, including void. Two differences worth knowing:
- Nothing is granted. You could already see your partners’ issued documents — the transmittal is the formal record of the hand-over, not a new route to the files.
- No email goes out, so watch the Inbox. (An in-app notification centre is a separate build.)
A partner can only transmit documents it owns, and only to the project team — there is no partner-to-partner exchange.
Voiding one issued in error
Section titled “Voiding one issued in error”Sometimes the wrong file goes out, or the right file goes to the wrong party. Open the transmittal on the Transmittals page and press Void this transmittal…. You must give a reason, and it is shown to the recipients, so write it for them: “wrong revision attached — re-issue to follow”.
Voiding is deliberately narrow — it’s for correcting a mistake, not for tidying up. What happens:
- Access is withdrawn. The recipients’ access to those documents through this transmittal ends immediately, so the download links stop working.
- The recipients are told. Each gets an email — the issue was made in error, don’t use the documents, discard any copies, await a re-issue — and the transmittal shows a plain warning in their portal.
- The record survives. The transmittal stays on the register and in the recipient’s portal, marked void with your reason. It is never deleted and its number is never reused: someone who already downloaded the file has to be able to find out it’s dead.
- Nothing else is touched. If a recipient can also reach a document through a shared folder, or through a later transmittal, that access is unaffected — voiding withdraws this issue, not every route to the document.
- The void is audited, with who did it, when, and the reason.
A voided transmittal can’t be acknowledged and never counts as overdue. To put the correct documents out, issue a new transmittal — it takes the next number, which is exactly what the audit trail should show.
The exchange register
Section titled “The exchange register”The Exchange register (in the sidebar’s Files group) is the single chronological record of everything exchanged with outside parties, across every mechanism:
| Row kind | Meaning |
|---|---|
| received | A partner or bidder sent you a file. |
| distributed | You issued/shared/published a document to a party — including outside share links (named or anyone with the link). |
| transmitted | A document went out under a transmittal reference. A voided issue stays on this row, marked VOIDED with its reason. |
| acknowledged | A recipient confirmed receipt of a transmittal. |
Every row shows the counterparty, the document, the direction and the timestamp. Export CSV gives you the whole register for contract records or an audit — it’s the file you hand over when someone asks “prove what was issued to whom”.