--- url: 'https://fullclarity.help/index.md' --- # --- --- url: 'https://fullclarity.help/ai.md' --- # AI integration FullClarity includes built-in support for AI assistants like Claude and ChatGPT. Once connected, you can ask questions about your projects, estimates, contracts, and costs using natural language — and get answers drawn directly from your NetSuite data. This connection uses the NetSuite AI Connector Service, which is built on the Model Context Protocol (MCP). Your AI assistant connects securely to NetSuite using your own credentials and role, so it can only see and do what your role permits. \[\[toc]] ## Getting connected Follow these pages in order to set up your AI integration: * [Setting up an MCP role](/ai/how-to/set-up-an-mcp-role) — create a dedicated NetSuite role for AI access with the right permissions * [Connecting to an AI assistant](/ai/how-to/connect-an-ai-assistant) — connect Claude or another AI assistant to your NetSuite account * [The Construction Council](/ai/construction-council) — a free AI advisory council for any construction business decision For an inventory of what each tool does, see [Available MCP tools](/ai/reference/available-mcp-tools). ## Available tools Once connected, your AI assistant can use FullClarity tools to answer questions about your data. The tools available depend on which FullClarity modules you have installed. **Project Financials** * Look up project details — billing type, cost centre, margin, linked estimates and contracts * List and search projects by customer, status, or billing type * Retrieve full estimate worksheets with line-item detail * View contract details and schedules of values * Check claim status, progress percentages, and retention amounts * Get cost centre category hierarchies * Ask conceptual questions about construction billing, estimating, and forecasting *More modules will be added as FullClarity tools are expanded.* ## Security and permissions * AI assistants **cannot** connect using the Administrator role — you must create a dedicated MCP role * The AI assistant can only access data that the connected role has permission to view * All AI connector activity is logged in NetSuite under the integration record * You can disconnect your AI assistant at any time from your AI client's settings or from NetSuite's integration management ## Related * [Setting up an MCP role](/ai/how-to/set-up-an-mcp-role) * [Connecting to an AI assistant](/ai/how-to/connect-an-ai-assistant) * [Available MCP tools](/ai/reference/available-mcp-tools) --- --- url: 'https://fullclarity.help/ai/construction-council.md' --- # The Construction Council The FullClarity Construction Council is a free, whole-of-business AI advisory board for construction and project businesses. Describe a decision you're weighing — bidding a job, hiring, pricing, marketing spend, a tricky client call, a compliance question — and ten specialist advisors independently pressure-test it, anonymously peer-review each other's answers, and a chairman synthesises the lot into a direct verdict. > ⚠️ **Important — please read.** The FullClarity Construction Council is an AI tool. AI can be wrong, incomplete, or out of date. Its output is **decision support, not professional advice** — it is not legal, financial, engineering, tax, or regulatory advice. It does not know your full circumstances, contracts, or local regulations beyond what you type in. > > **It is your responsibility to check any advice before you act on it**, and to consult a qualified professional (building surveyor, accountant, lawyer, engineer) where appropriate. FullClarity provides this tool free of charge and accepts no liability for any decision made using it. > > **Privacy:** whatever you type is sent to the AI provider you choose (OpenAI, Google, Anthropic, and so on) under their terms. Don't paste anything you wouldn't share with that provider, and avoid confidential or personal information unless you're sure it's appropriate. \[\[toc]] ## Who it's for Any construction or project business owner or manager weighing a genuine decision with real trade-offs — not a factual lookup or a writing task. It's built to be used by anyone, with or without a FullClarity subscription, in whatever AI chat tool they already have (ChatGPT, Gemini, Claude, Copilot), or as a Claude Code skill if you prefer. ## The council | Advisor | Focus | | --- | --- | | **The Site Boss** | Can it actually be delivered with the crew, gear, and time available — delivery risk and programme reality | | **The Estimator** | Whether the numbers stack up — pricing, margin leakage, under-measurement, scope creep | | **The Money Watcher** | Cash-flow timing, retention, payment terms, and liquidity risk | | **The Client's Eye** | How it looks from outside — customer satisfaction, reputation, repeat work | | **The Strategist** | The bigger picture — market position, capability building, long-term upside | | **The Closer** | Winning the work — the pitch, the deal, the negotiation, the pipeline | | **The Marketer** | Public perception — brand, story, content and reputational risk | | **The Regulator** | Legality, compliance, approvals, contracts, and where liability sits | | **The Accountant** | Tax, structure and the books — GST/BAS, deductibility, year-end and ATO exposure, profit vs cash | | **The Lawyer** | Contracts and legal risk — what the contract says, liability, disputes, security-of-payment, employment law | ## How it works 1. **Convene.** Depending on your question, four to six of the ten advisors are convened — always including The Client's Eye and at least one downside seat (The Money Watcher, The Regulator, The Site Boss, or The Lawyer). 2. **Independent advice, then peer review.** Each convened advisor answers in their own voice with no visibility into the others' answers. Their responses are then anonymised and peer-reviewed by the other advisors, surfacing blind spots and things everyone missed. 3. **Chairman's verdict.** A chairman synthesises everything into a clear verdict — where the council agrees, where it clashes, what got missed, and what to do first. ## Two ways to use it **1. In any AI chat — easiest, no installation.** Paste one prompt into whatever AI tool you already use (ChatGPT, Gemini, Claude, or Copilot), then describe your decision. See [Get started](/ai/construction-council/get-started) for the prompt, ready to copy. **2. As a Claude Code skill — one-step install, no command line.** If you use Claude Code, you can install the council so it's always available, without typing any commands. Just paste this message to Claude Code: > Install the FullClarity Construction Council as a skill. Download this file — https://bitbucket.org/fullclarity/fc-construction-council/raw/main/skill/fullclarity-construction-council/SKILL.md — and save it to `~/.claude/skills/fullclarity-construction-council/SKILL.md`, then confirm it's installed. Claude Code downloads and installs it for you, then offers the council automatically whenever you're weighing up a decision. Full walkthrough on the [Get started](/ai/construction-council/get-started) page. ## Source and licence The Construction Council is an open, free project maintained by FullClarity. The full prompt pack and Claude Code skill are available in the public repository at [bitbucket.org/fullclarity/fc-construction-council](https://bitbucket.org/fullclarity/fc-construction-council), licensed under Apache License 2.0. ## Related * [Get started with the Construction Council](/ai/construction-council/get-started) * [AI integration overview](../) --- --- url: 'https://fullclarity.help/ai/construction-council/get-started.md' --- # Get started with the Construction Council The Construction Council is a free AI advisory board for construction and project businesses. Paste one prompt into your AI chat of choice, describe a decision you're weighing, and ten expert "advisors" — each with a different angle — pressure-test it and hand you a clear verdict. \[\[toc]] ## How to use it in 60 seconds 1. Open your AI chat tool — ChatGPT, Gemini, Claude, or Copilot all work. 2. Copy the whole prompt below. 3. Fill in the `My region:` line near the top with your country and state or territory (for example, "Victoria, Australia"). You can leave it blank and the council will ask you instead. 4. Paste the whole thing into a new chat. 5. Type the business decision you want tested — for example, whether to take on a job, hire someone, or spend on marketing. 6. Read the verdict. The council will tell you where its advisors agree, where they clash, what they nearly missed, and what to do first. The council works best on genuine business decisions with real trade-offs — not on factual lookups (e.g. "what's the current award rate for an electrician?") or writing tasks (e.g. "write me a social media post"). A general AI chat, or a search engine, will serve those better. ## The prompt Copy everything in the box below and paste it into a new chat. ```` My region: ______ (e.g. "Victoria, Australia". Leave blank and the council will ask.) You are the Chairman of the FullClarity Construction Council. You will run a whole-of-business advisory council for a construction or project business, playing every role yourself in sequence — the Chairman, all ten advisors, and all peer reviewers. Work through the steps below in order and do not skip the peer-review round. ## The Council 1. **The Site Boss** — You've run sites for 25 years. You care about one thing: can this actually be built or done with the crew, gear, and time available — and what will go wrong on the ground. You've watched every optimistic plan collide with reality. Call out delivery risk, resourcing gaps, and programme blowouts bluntly. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 2. **The Estimator** — You're the quantity surveyor. You live in the numbers: is the price right, where is margin leaking, what has been under-measured, where will scope creep eat the job. You don't care about vibes — you care about whether the sums stack up. Point to specific commercial holes. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 3. **The Money Watcher** — You're the financial controller. Cash is oxygen. You care about cash-flow timing, retention, payment terms, funding the work in progress, and the risk of a client or subcontractor going under owing you money. A profitable job that starves the cash flow is still a disaster. Flag liquidity and payment risk. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 4. **The Client's Eye** — You see everything the way the customer or owner does — someone with no inside knowledge of this business. You care about whether they'll be happy, whether the reputation holds up, and whether this wins repeat work and referrals. You catch the things that are obvious inside the company but confusing or off-putting from outside. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 5. **The Strategist** — You're the growth-minded managing director. You look past this one job to the bigger picture: does this open a market, build a capability, create a stepping stone, or is it a distraction. You care about the upside others miss and whether this moves the business forward. Think two or three moves ahead. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 6. **The Closer** — You're the sales and business-development lead. You care about winning the work and the quality of the deal: the pitch, the relationship, the negotiation, the pipeline. You spot where a deal can be won, improved, or is being left on the table — and where chasing the wrong work wastes everyone's time. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 7. **The Marketer** — You run brand and social media. You care about how this plays publicly: the story, the reputation, the content it could generate, the perception risk. You think about how a decision looks to the market and how it could be turned into demand — or how it could blow up online. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 8. **The Regulator** — You think like the building surveyor and the compliance/contracts authority. You care about whether it's legal, whether it will pass, what approvals and obligations apply, and where the liability sits. You are the check on "she'll be right": if something breaches code, contract, or safety obligations, you say so plainly. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 9. **The Accountant** — You're the external accountant and tax adviser. You read every decision through tax, structure, and the books: GST/BAS treatment, deductibility and depreciation, the profit-and-loss and balance-sheet impact, business structure (company, trust, partnership), and how it lands at year-end and with the ATO. You care about the gap between profit and cash, and about what a lender or auditor will see. Point out tax traps, reporting consequences, and structuring opportunities others miss. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. 10. **The Lawyer** — You're the commercial lawyer. You read the decision for legal risk and contractual exposure: what the contract actually says (and doesn't), indemnities, liability caps, dispute and termination clauses, security-of-payment and lien rights, warranties, IP, and employment-law exposure. You think about how this plays if it ends up in a dispute or a courtroom, and where the business is carrying risk it hasn't priced. Say plainly where something needs a clause, a review, or a lawyer's sign-off before it's committed to. Ground your advice in the user's region (the user's stated region); default to Australian norms if none is given. Challenge hard — don't hedge, don't soften to be polite. The other advisors cover the angles you don't. ## How to run the council 1. **Region check.** If the `My region:` slot above is blank, ask the region question — *"Which country and (if relevant) state or territory does your business operate in? I'll tailor the council's advice — especially compliance and payment norms — accordingly."* Otherwise use the region already given. Store/carry it. Default to Australia if the user declines. 2. **Frame.** Restate the decision neutrally in 1–2 sentences, folding in any context given. If the question is too vague to advise on, ask exactly ONE clarifying question, then proceed. 3. **Convene.** Choose the 4–6 advisors most relevant to the question. ALWAYS include The Client's Eye and at least one downside seat (The Money Watcher, The Regulator, The Site Boss, or The Lawyer). State in one line who is convened and why. 4. **Independent advice.** Each convened advisor answers in their own voice, leaning fully into their angle. No cross-talk. 5. **Anonymised peer review.** Relabel the advisor answers Response A, B, C… (one letter per convened advisor, mapping randomised). Each reviewer answers: which response is strongest and why; which has the biggest blind spot and what it is; what ALL responses missed. 6. **Chairman synthesis.** Produce the verdict in the exact structure below. ## Council Verdict structure ``` ## Council Verdict: {short topic} **Convened:** {advisor names} — {one-line why} ### Where the Council Agrees {points multiple advisors converged on independently — high-confidence signals} ### Where the Council Clashes {genuine disagreements; present both sides; don't smooth them over} ### Blind Spots the Council Caught {things that surfaced only in peer review} ### The Recommendation {a clear, direct recommendation — not "it depends". The chairman may side with a dissenter if the reasoning is strongest.} ### The One Thing to Do First {a single concrete next step — not a list} ``` Then, on its own line at the very end: `The FullClarity Construction Council — brought to you by FullClarity, https://fullclarity.com` Keep each advisor response under 180 words and each peer review under 200 words. ## Before you rely on this > ⚠️ **Important — please read.** The FullClarity Construction Council is an AI tool. AI can be wrong, incomplete, or out of date. Its output is **decision support, not professional advice** — it is not legal, financial, engineering, tax, or regulatory advice. It does not know your full circumstances, contracts, or local regulations beyond what you type in. > > **It is your responsibility to check any advice before you act on it**, and to consult a qualified professional (building surveyor, accountant, lawyer, engineer) where appropriate. FullClarity provides this tool free of charge and accepts no liability for any decision made using it. > > **Privacy:** whatever you type is sent to the AI provider you choose (OpenAI, Google, Anthropic, and so on) under their terms. Don't paste anything you wouldn't share with that provider, and avoid confidential or personal information unless you're sure it's appropriate. ```` ## Make it remember your region A fresh chat has no memory of your last conversation, so if you start a new chat each time, you'll need to fill in the `My region:` line again — or answer the region question when it's asked. There are two easy ways around this. The simplest is to just keep your own copy of the prompt above with the `My region:` line already filled in, and paste from that copy every time. If you use ChatGPT or Gemini regularly, you can also save the council as a reusable assistant: paste the prompt into a **ChatGPT Custom GPT** or a **Gemini Gem**, and it will remember your region (and the whole council setup) automatically every time you open it — no copy-pasting required. ## Prefer Claude Code? If you use Claude Code, there's a version of the council built as a skill rather than a prompt you paste — it runs the same council as real parallel sub-agents. You don't need to use a command line to install it: just paste this message to Claude Code: > Install the FullClarity Construction Council as a skill. Download this file — https://bitbucket.org/fullclarity/fc-construction-council/raw/main/skill/fullclarity-construction-council/SKILL.md — and save it to `~/.claude/skills/fullclarity-construction-council/SKILL.md`, then confirm it's installed. Claude Code will download and install it for you, then offer the council automatically whenever you're weighing up a genuine business decision. ## Source The full prompt pack and Claude Code skill are maintained in the public repository at [bitbucket.org/fullclarity/fc-construction-council](https://bitbucket.org/fullclarity/fc-construction-council). > ⚠️ **Important — please read.** The FullClarity Construction Council is an AI tool. AI can be wrong, incomplete, or out of date. Its output is **decision support, not professional advice** — it is not legal, financial, engineering, tax, or regulatory advice. It does not know your full circumstances, contracts, or local regulations beyond what you type in. > > **It is your responsibility to check any advice before you act on it**, and to consult a qualified professional (building surveyor, accountant, lawyer, engineer) where appropriate. FullClarity provides this tool free of charge and accepts no liability for any decision made using it. > > **Privacy:** whatever you type is sent to the AI provider you choose (OpenAI, Google, Anthropic, and so on) under their terms. Don't paste anything you wouldn't share with that provider, and avoid confidential or personal information unless you're sure it's appropriate. ## Related * [The Construction Council overview](/ai/construction-council) * [AI integration overview](../) --- --- url: 'https://fullclarity.help/ai/how-to/connect-an-ai-assistant.md' --- # Connect an AI assistant Connect Claude (or another MCP-compatible AI assistant) to your NetSuite account so it can answer questions about your FullClarity data. \[\[toc]] ## When to use this Once you have an [MCP role set up](./set-up-an-mcp-role), you can connect your AI assistant to your NetSuite account. This page covers connecting with Claude, though the process is similar for other AI clients that support the Model Context Protocol. ## Prerequisites * A **Claude Pro, Max, Team, or Enterprise** subscription (connectors are not available on the free plan). ChatGPT requires a **Plus** plan or higher. * Your **NetSuite account ID** — visible in your NetSuite URL (e.g. `https://1234567.app.netsuite.com` → account ID `1234567`) or under **Setup → Company → Company Information** * A user account with the **MCP role** assigned — see [Setting up an MCP role](./set-up-an-mcp-role) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for connecting Claude to NetSuite is being recorded. Track its status in the Scribe register (internal). ::: ### Build the connection URL The connection URL tells your AI assistant where to find your NetSuite account and which tools to load. The format is: ``` https://.suitetalk.api.netsuite.com/services/mcp/v1/ ``` Replace `` with your NetSuite account ID, and choose a scope: | Scope | URL ending | What it includes | | --- | --- | --- | | All tools | `/v1/all` | Standard NetSuite tools + all installed SuiteApp tools | | FullClarity only | `/v1/suiteapp/com.fullclarity.projectfinancials` | Only FullClarity Project Financials tools | | Standard tools only | `/v1/suiteapp/com.netsuite.mcpstandardtools` | Only NetSuite's built-in tools (saved searches, SuiteQL, record access) | If you want both FullClarity tools and the standard NetSuite tools without tools from other SuiteApps, add two separate connectors — one for each URL. **Recommended for most users:** use `/v1/all` to get everything in a single connector. This is the simplest setup and works well unless you have other SuiteApps adding tools that you don't want visible to the AI assistant. ### Connect with Claude 1. In Claude, go to **Settings → Connectors**. 2. Click **Add custom connector** at the bottom. 3. Enter a name — for example, "FullClarity" or "NetSuite". 4. Paste your connection URL. 5. Click **Add**, then click **Connect**. 6. A pop-up window will open asking you to log in to NetSuite. 7. **Choose your MCP role** — do not select Administrator. 8. Review the access warning and click **Allow**. 9. The pop-up will close and Claude will confirm the connection. After connecting, you can configure each tool's approval mode. Go to **Settings → Connectors**, find your connector, and click **Configure**. For each tool, you can choose: * **Ask every time** — Claude will ask for your permission before using the tool * **Allow unsupervised** — Claude can use the tool without asking ### Connect with other AI clients Any AI client that supports the Model Context Protocol can connect to FullClarity using the same connection URL. The setup steps will vary by client — refer to your AI provider's documentation for instructions on adding an MCP connector. For ChatGPT, you'll need a Plus plan or higher. The connection process is similar: add a custom connector using the same URL format and authenticate with your MCP role. ### Test the connection Start a new conversation in Claude and try one of these prompts: * "What FullClarity help topics are available?" — tests the help tool (no data access needed) * "List my projects" — tests project data access * "Show me the estimate worksheet for project \[name]" — tests estimate data access If the tools don't appear, check that your MCP role has the required setup permissions (OAuth 2.0 Access Tokens and MCP Server Connection). ## What success looks like * The connector appears in **Settings → Connectors** in Claude with status **Connected**. * A new conversation in Claude lists the FullClarity tools (FC Project Summary, FC List Projects, FC Estimate Worksheet, etc.) under the connector. * A test prompt like "List my projects" returns project data from your NetSuite account. ## Gotchas * **The built-in NetSuite connector in Claude does not work for test drive accounts.** If your account ID starts with `tstdrv`, use the **custom connector** approach with the URL format above — Claude's built-in NetSuite connector option will fail. * **The connection persists across conversations.** You only need to set it up once. If you start a new conversation and the tools aren't showing, click **Configure** on the connector in Settings to refresh the tool list. * **"Missing permissions" errors usually mean missing custom records.** Check that your MCP role has the right custom record access on your role — see [Setting up an MCP role](./set-up-an-mcp-role). * **Each user connects individually.** The AI sees only what the connected user's role allows. ## Disconnecting To disconnect your AI assistant: * **From Claude:** Go to **Settings → Connectors**, find the connector, and click **Disconnect**. * **From NetSuite:** Go to **Setup → Integration → Manage Integrations**, find the AI integration record, and disable it. This will disconnect all users. ## Related * [AI integration overview](../) * [Setting up an MCP role](./set-up-an-mcp-role) * [Available MCP tools](../reference/available-mcp-tools) --- --- url: 'https://fullclarity.help/ai/how-to/set-up-an-mcp-role.md' --- # Set up an MCP role Create a dedicated NetSuite role with the right permissions so an AI assistant can connect to your FullClarity data through the NetSuite AI Connector Service. \[\[toc]] ## When to use this Before you can connect an AI assistant (Claude, ChatGPT, or any MCP-compatible client) to FullClarity, you need a dedicated NetSuite role with the right permissions. The AI connector **cannot** use the Administrator role, so this step is required. Each user who wants to use an AI assistant will be assigned this role on their employee record. ## Prerequisites * The **NetSuite administrator** role — only administrators can create and modify roles * The Project Financials SuiteApp installed (so the FullClarity custom records exist) * A short list of the users who will be assigned the MCP role ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for creating and assigning the MCP role is being recorded. Track its status in the Scribe register (internal). ::: ### Create the role 1. Go to **Setup → Users/Roles → Manage Roles**. 2. Click **New**. 3. Enter a name for the role — for example, "FullClarity MCP" or "AI Connector Role". 4. Under **Subsidiary**, choose the subsidiaries this role should have access to. For most setups, select the relevant subsidiary or **All**. 5. Save the role, then edit it to add the permissions below. ### Add the required permissions The role needs two setup permissions to enable the AI connection, plus data permissions for whichever FullClarity features you want the AI assistant to access. **Setup permissions (required for all users)** — found under **Permissions → Setup**: | Permission | Level | | --- | --- | | Log in using OAuth 2.0 Access Tokens | Full | | MCP Server Connection | Full | **Data permissions for Project Financials tools** — found under **Permissions → Lists**: | Permission | Level | Why it's needed | | --- | --- | --- | | Jobs | View | Look up project details | | Customers | View | See customer names on projects | | Opportunities | View | Access linked estimates | **Custom record permissions** — found under **Permissions → Custom Record**: The FullClarity tools also read data from custom records such as estimates, estimate lines, contracts, claims, and cost centres. Grant **View** access to these custom records. The specific records needed depend on which tools you want to use. Your FullClarity administrator can advise on the appropriate custom record permissions for your setup. ### Assign the role to users 1. Go to **Setup → Users/Roles → Manage Users**, or open an employee record directly. 2. On the **Access** subtab, add the new MCP role to each user who will connect an AI assistant. 3. Save the record. Each user connects individually — the AI assistant uses their personal credentials and can only access what their role allows. ## What success looks like * The new role appears in **Setup → Users/Roles → Manage Roles**. * The role lists the two required setup permissions plus your chosen data permissions. * Each target user has the role on the **Access** subtab of their employee record. * When that user connects their AI assistant (see [Connecting to an AI assistant](./connect-an-ai-assistant)), the role appears as an option on the NetSuite role-selection screen. ## Gotchas * **Administrator role won't work.** The AI connector explicitly refuses Administrator. Make sure each user has the new MCP role available alongside their other roles, and selects the MCP role at sign-in. * **Missing custom record permissions look like missing data.** If the AI assistant reports that it can't find estimates, claims, or cost centres, check that the MCP role has **View** access to the corresponding FullClarity custom records. * **One role per user group works well.** Consider creating separate MCP roles for different user groups if you need to control who can access which FullClarity data through AI — for example, a "Project Manager MCP" role and a "Finance MCP" role. ## Tips * Start with view-only permissions and expand as needed. You can always add more permissions to the role later. * The role name shows up on the NetSuite role-selection screen during the AI connection flow — pick something obvious like "FullClarity MCP" so users know which to choose. ## Related * [AI integration overview](../) * [Connecting to an AI assistant](./connect-an-ai-assistant) * [Available MCP tools](../reference/available-mcp-tools) --- --- url: 'https://fullclarity.help/ai/reference/available-mcp-tools.md' --- # Available MCP tools A reference inventory of the FullClarity tools your AI assistant can use once connected. Tool descriptions are kept deliberately short — for the full conceptual flow see the [AI integration overview](../). \[\[toc]] ## Two FullClarity MCP servers FullClarity exposes two MCP surfaces to AI assistants: 1. **Project Financials tools (NetSuite-resident).** Installed as part of the Project Financials SuiteApp and accessed through the NetSuite AI Connector Service. These tools read live data from your NetSuite account — projects, estimates, contracts, claims, cost centres — using the connected user's role permissions. See [Connecting to an AI assistant](../how-to/connect-an-ai-assistant) for setup. 2. **Knowledge Hub server (FullClarity-hosted).** A separate FullClarity-hosted MCP server that exposes FullClarity product documentation and capability metadata for AI agents. Used primarily by FullClarity partner and internal teams during solution scoping; not typically connected from end-customer AI clients today. Most customers will only use the Project Financials tools. The Knowledge Hub server is documented here for completeness. ## Project Financials tools These tools are loaded when you connect to NetSuite using the Project Financials scope (`/v1/suiteapp/com.fullclarity.projectfinancials`) or the all-tools scope (`/v1/all`). All tools are read-only. | Tool | What it does | | --- | --- | | **FC Project Summary** (`fcGetProjectSummary`) | Load a project by ID — billing type, margin, cost centre, linked records | | **FC List Projects** (`fcListProjects`) | Search projects with filters (customer, billing type, status, subsidiary) | | **FC Estimate Worksheet** (`fcGetEstimateWorksheet`) | Full line-item detail for an estimate — categories, quantities, rates, contingency, margins | | **FC List Estimates** (`fcListEstimates`) | List estimates for a project (Sales Estimate, Project Budget, Forecast, Forecast Snapshot) | | **FC Cost Centre Structure** (`fcGetCostCentreStructure`) | Hierarchical category tree for a cost centre set | | **FC List Cost Centres** (`fcListCostCentreSets`) | List available cost centre sets | | **FC Contract Details** (`fcGetContractDetails`) | Contract header, financials, approval status, and schedule of values | | **FC Claim Status** (`fcGetClaimStatus`) | Claim header, amounts, retention, and line items with progress percentages | | **FC Help & Concepts** (`fcGetHelp`) | Domain knowledge: billing types, estimating, forecasting, contracts, and other construction concepts | ::: warning Author input needed The Project Financials MCP toolset spec is currently a skeleton (`projectfinancials-mcp-toolsets-spec.md` §3). Per-tool parameter detail (filter fields, response shape) will be added as the spec matures. The descriptions above are accurate for the tool inventory available in the current Project Financials SuiteApp. ::: ### What "read-only" means in practice * Tools never create, update, or delete NetSuite records. * The AI assistant can summarise what it found, but any changes to projects, estimates, contracts, or claims must still be made by a human in the NetSuite UI. * If you want write access from an AI client, use the **standard NetSuite tools** scope (`/v1/suiteapp/com.netsuite.mcpstandardtools`) alongside the FullClarity tools — NetSuite's built-in MCP tools include record-creation and update tools that respect the connected user's role permissions. ## Knowledge Hub tools The FullClarity Knowledge Hub MCP server is a separate, FullClarity-hosted MCP endpoint. It exposes FullClarity product knowledge — documentation, capability metadata, document templates — to AI agents. It's mainly used by FullClarity partner and internal teams during solution scoping and is not typically connected from end-customer AI clients today. | Tool | What it does | | --- | --- | | **`list_documents`** | List all knowledge documents available to your organisation (optionally filtered by product slug) | | **`get_document`** | Retrieve the full markdown content of a knowledge document by URI | | **`search_knowledge`** | Natural-language search across all knowledge document chunks, ranked by semantic similarity | | **`get_template_url`** | Generate a 15-minute signed download URL for a Word (`.docx`) or PowerPoint (`.pptx`) template | | **`query_capabilities`** | Structured product capability lookup — features, use cases, fit signals — for product fit assessment | All Knowledge Hub tools respect organisation-scoped access — your organisation only sees the document repositories it has been granted access to. ## Related * [AI integration overview](../) * [Setting up an MCP role](../how-to/set-up-an-mcp-role) * [Connecting to an AI assistant](../how-to/connect-an-ai-assistant) --- --- url: 'https://fullclarity.help/certified-documents.md' --- # Certified Documents Certified Documents is the FullClarity SuiteApp that manages the full lifecycle of compliance documents — insurance certificates, licences, safety tickets, accreditations, identity evidence — for the vendors, customers and employees you work with. \[\[toc]] ## What it does Compliance documents have a lifecycle: request, submission, approval, expiry, renewal — and sometimes rejection or decline along the way. Doing this manually means juggling spreadsheets, chasing renewals at the wrong time, and either over- or under-trusting the document on file. Certified Documents automates that lifecycle: * **Catalogue every certifiable document type** your business cares about — Public Liability, Workers Compensation, White Card, Working with Children Check, contractor inductions, ABN/business numbers, anything else * **Attach requirements to specific entities** — "Acme Co (vendor) requires Public Liability Insurance and a current Workers Compensation certificate" * **Send automated request emails** with a signed upload link that the recipient uses to submit documents without needing a NetSuite login * **Track approval chains** with multi-level approvers per document type * **Drive renewals automatically** — the system creates a fresh request a configurable number of days before expiry * **Cancel requests automatically** when the underlying vendor / customer / employee record is made inactive * **Capture decline reasons** when the external party can't (or won't) submit, with a structured taxonomy filtered by entity type ## The external upload portal Compliance often involves people who don't have a NetSuite login — subcontractors, customer site managers, casual contractors. Certified Documents solves this with an external-facing upload portal: * Each request email contains a **signed link** unique to that submission * The recipient opens the link in a browser, sees the document description (and optional start/end date prompts), and uploads the file * The portal stores the uploaded file via the File Storage SuiteApp and returns the submission to the internal reviewer for approval No login, no NetSuite account, no manual file-cabinet wrangling. ## Manual vs Auto Send Each certifiable document type can use one of two operating modes: * **Auto Send** — the system fires the request email automatically as soon as a Required Document is created for an entity. Use this for the common case where you always want to request a document the moment a vendor or customer record is added. * **Manual** — the system stages the request but waits for an internal user to action it before the email goes out. Use this when you want a human gate (for example, double-check the contact email before sending) before the chase starts. The mode is set per certifiable document type, so you can mix the two in the same account. ## Where this fits in the ecosystem * **Portal** — provides the external-facing upload page that recipients land on. Required. * **File Storage** — stores the uploaded files in your S3-backed storage region. Required. * **Code Library** — provides the entity subtab where Required Docs and Docs Submitted appear on vendor, customer and employee records. Required. ## Next steps * [Quick start](/certified-documents/quick-start) — set up your first document type and send your first request * [Install & configure](/certified-documents/install-configure) — dependencies, required NetSuite features and post-deploy verification * [Set up a document type](/certified-documents/how-to/set-up-a-document-type) — define a new Certifiable Document, its approval chain and email templates * [Request a document from a vendor](/certified-documents/how-to/request-a-document-from-a-vendor) — attach a requirement to an entity and send the request * [Approve or reject a submission](/certified-documents/how-to/approve-or-reject-a-submission) — handle a returned document --- --- url: >- https://fullclarity.help/certified-documents/how-to/approve-or-reject-a-submission.md --- # Approve or reject a submission Action a submission that's been uploaded by an external party — either approving it through the chain to **Approved** status, or rejecting it with feedback so the recipient knows what to fix. \[\[toc]] ## When to use this Whenever a Docs Submitted record moves to **Received** status — meaning the external party has uploaded the document via the portal and it's now waiting for internal review. This is the single most repeated internal-user action in the SuiteApp. ## Prerequisites * You are listed as an approver on the Certifiable Document type, or someone in your approval chain has delegated to you * The Docs Submitted record is in **Received** or **Pending Approval** status ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: ### Approving a submission 1. Open the Docs Submitted record. You'll find it via: * The notification email sent to you when the document was received * The vendor / customer / employee's FullClarity subtab, under the Required Doc that triggered the request * A saved search of submissions awaiting your approval 2. Review the uploaded document — click the file link on the record to view it. 3. Confirm the **start date** (if applicable) and **end date** — these were entered by the external party on the upload page but can be edited before approval if they came in incorrectly. 4. Find the **Approvals** subtab on the record — it shows each approver in order, with checkboxes and dates that get stamped as each approves. 5. Tick the **Approve** checkbox on your row and save. What happens depends on whether more approvers remain: * **More approvers in the chain** — the status moves to **Pending Approval (13)** and the next approver is notified * **You're the last approver** — the status moves to **Approved (4)**. The renewal countdown (if the document has an end date) starts running. ### Rejecting a submission If the uploaded document is wrong (wrong document type, expired, illegible, etc.), reject it so the recipient can correct and resubmit: 1. Open the Docs Submitted record. 2. Click the **Reject** action (typically a button on the record). 3. Choose a rejection reason and add a memo explaining what was wrong — this text appears in the rejection email sent to the external contact. 4. Save. The record briefly enters **Processing Rejection (14)** while the rejection email is sent and approval fields are cleared, then transitions to **Rejected (6)**. The external contact receives the rejection email with your feedback and can re-upload a corrected document via the same signed link. ### Re-receiving after rejection A rejected submission is **not closed** — the recipient still has the upload link and can submit a corrected document. When they do, the status moves back to **Received** and the approval chain restarts from the first approver. ## What success looks like * A successful approval lands the submission at **Approved** status, with every approver's row on the Approvals sublist ticked and date-stamped. * The vendor / customer / employee's Required Doc reflects an in-place valid submission, with renewal countdown active if applicable. * For a rejection, the external contact receives the rejection email with your feedback within a couple of minutes. ## Gotchas * **Approvals are sequential, not parallel.** The next approver in the chain is only notified after the previous one approves. If your chain has gaps (e.g. an approver on leave), the chain stalls until that approver acts or is replaced. * **Rejection clears approvals.** When you reject a submission, all prior approvers' tick marks on this submission are cleared. If the recipient resubmits, every approver in the chain has to action it again — the system doesn't preserve partial approvals across the rejection. * **Out-of-order approval.** Some accounts allow approvers to action their row out of order (e.g. an approver at level 3 ticks before the approver at level 2). The chain still advances strictly in order — out-of-order ticks are recorded but the system waits for the lower-level approver before notifying the next level. Check with your administrator on what the configured behaviour is. * **Approval changes don't push back to the certifiable document.** Ticking an approver row on a Docs Submitted does not change the master Approver list on the Certifiable Document type. The two lists are independent — the Docs Submitted Approvers sublist is a per-submission snapshot. * **Renewal countdown starts on approval, not on upload.** The clock for the next renewal request only begins ticking once the chain completes. If the chain takes weeks to clear, the renewal window effectively shrinks for that cycle. ## Related * [Set up a document type](./set-up-a-document-type) * [Request a document from a vendor](./request-a-document-from-a-vendor) --- --- url: >- https://fullclarity.help/certified-documents/how-to/request-a-document-from-a-vendor.md --- # Request a document from a vendor Attach a certifiable document type as a requirement on a specific vendor (or customer or employee), so the system creates a Docs Submitted record and emails the request. \[\[toc]] ## When to use this When you onboard a new vendor and need them to provide a particular insurance certificate, accreditation, or other compliance document. The same flow works for customer-side document requirements (e.g. evidence of identity) and employee-side requirements (e.g. driver's licence on file). Once attached, the requirement persists — the system handles request, reminder, renewal and expiry automatically. You don't need to chase manually. ## Prerequisites * Certified Documents installed and configured * The Certifiable Document type already exists in the library — see [Set up a document type](./set-up-a-document-type) * The vendor (or customer or employee) record exists in NetSuite * The vendor has at least one contact with an email address, or the **FC CD Default Contact** field is set on the vendor record ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: ### Attach the requirement 1. Open the **vendor record** in NetSuite (the same flow applies to customer and employee records). 2. Go to the **FullClarity** entity subtab. 3. Find the **Required Docs** sublist. 4. Click **New Required Doc** (or **Add Row**, depending on your form). 5. Set the fields on the new row: * **Document (Vendor)** — pick the certifiable document type to require (the list is filtered to documents marked as required-from-vendor) * **Default Vendor Contact** — the contact who'll receive the request email * **Default Vendor Contact Email** — auto-populates from the contact, but can be overridden if the request needs to go to a different address * (Optional) Override the request, reminder, renewal or rejection email templates on this specific requirement * (Optional) Override Renewal Days if this vendor's contract specifies a different renewal window 6. Save the requirement. ### What happens next Depending on the certifiable document type's operating workflow: * **Auto Send mode** — a Docs Submitted record is created automatically in **Initialized** status, the signed upload link is generated, and the request email fires to the contact. The status transitions to **Requested** once the email is sent. * **Manual mode** — a Docs Submitted record is created in **Preparing Manual Request** status. An internal user actions it (typically by opening the record and clicking a Send action) to fire the email. From there, the system manages the rest: * **Reminder emails** fire on a 7-day cadence until the document is received * **Once uploaded**, the status moves to **Received** and the approval chain kicks in * **Renewals** are auto-initiated N days before expiry — a new Docs Submitted record is created, linked back to the previous one via a renewal chain * **Expiry** marks the original Docs Submitted as **Expired** once the end date passes without a renewal being approved * **Cancellation** happens automatically if the vendor is made inactive — the Docs Submitted is moved to **Cancelled** and no further emails fire ### Manually re-sending the request If the original contact has changed or the request needs to go out again: 1. Open the Docs Submitted record (on the Required Doc's child sublist). 2. Change the contact or contact email if needed. 3. Use the **Resend Request** action to re-trigger the email. ### When the recipient declines If the external party can't or won't submit the document, they can pick a decline reason on the upload page instead of uploading a file. The submission moves to **Declined (5)** and an internal reviewer is notified. Decline reasons are entity-type-specific — vendors see a different set from customers, who see a different set from employees. ## What success looks like * The vendor's FullClarity entity subtab shows the new Required Doc with its current status. * A Docs Submitted child record exists — visible from the Required Doc's view page — in either **Requested** (Auto Send) or **Preparing Manual Request** (Manual) status. * For Auto Send: the contact has received the request email with a working upload link. ## Gotchas * **Document filter by entity type matters.** Each vendor / customer / employee subtab shows the dropdown filtered to documents marked as required-for-that-entity-type. If your document doesn't appear in the list, check the **Required From Vendor / Customer / Employee** checkboxes on the Certifiable Document. * **Contact email is mandatory for Auto Send.** Without an email, the request email can't send. The Update Missing Contact MR script will try to fall back to the entity's own email, then to the FC CD Default Contact on the entity record, then give up and log the gap. Set the contact up front. * **Same document can be required multiple times.** Adding a second Required Doc for the same document type on the same vendor creates a parallel chain. Usually a mistake — Required Docs are intended to be unique per (document × entity). * **Required Doc with no Operating Workflow.** If the Required Doc record is missing its Operating Workflow (rare, but possible after a manual data load), the post-deploy MR script will eventually default it to the certifiable document's operating workflow. To force the fix, open the record and save it. * **Renewal chains.** When a renewal is auto-initiated, the new Docs Submitted is linked to the previous one. Don't expect the old submission to update — it stays at its terminal status while the new one drives the cycle. ## Related * [Set up a document type](./set-up-a-document-type) * [Approve or reject a submission](./approve-or-reject-a-submission) --- --- url: 'https://fullclarity.help/certified-documents/how-to/set-up-a-document-type.md' --- # Set up a document type Define a new Certifiable Document — what it represents, which entity types it applies to, who approves it, which email templates drive its lifecycle, and how renewal works. \[\[toc]] ## When to use this Whenever your business needs to track a new compliance document — a new insurance type, a new accreditation, a regulatory licence, an industry-specific safety check. Each Certifiable Document type is set up once and then attached to as many vendors, customers or employees as need it. ## Prerequisites * Certified Documents installed and the post-deploy steps confirmed (see [Install & configure](../install-configure)) * A list of internal approvers (one or more NetSuite Employee records) for documents of this type * (Optional) Bespoke email templates if you want different wording than the defaults ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: ### Step 1: Create the Certifiable Document 1. Navigate to **FullClarity → Certified Documents → Certifiable Documents → New**. 2. Fill in the main fields: * **Name** — what the document is, in the customer's own language (e.g. *Public Liability Insurance*, *White Card*, *Working with Children Check*). * **Document Description** — the long-form description shown to the external party on the upload page. Be specific — "Current certificate of currency for $20m public liability" reads more clearly than "PL insurance". * **Include Start Date** — tick if the system should ask the recipient for a start date when they upload. * **Include End Date** — tick if the document expires. This drives the renewal countdown and the automatic mark-as-expired behaviour. 3. Set which entity types can have this document required: * **Required From Customer** * **Required From Vendor** * **Required from Employee** Tick whichever apply. Most compliance documents apply to one type; a few (e.g. ABN evidence) apply to multiple. 4. Set the **Document Type** — Customer / Vendor / Employee. This drives the decline-reason filter on the external upload page. ### Step 2: Choose the operating workflow The **Operating Workflow** field determines whether requests fire automatically or wait for human action: * **`FC CD Docs Submitted (Auto Send)`** — emails fire as soon as a Required Doc is created. Use this for documents that always need to be requested immediately (the common case). * **`FC CD Docs Submitted (Manual)`** — emails stage but wait for an internal user to action them. Use this when you want to confirm contact details or timing before triggering the first chase. This is set per certifiable document, so you can mix Manual and Auto Send across your library. ### Step 3: Choose email templates Four template slots map to the four lifecycle events: * **Request Email Template** — the initial request email * **Reminder Email Template** — sent on the 7-day reminder cadence * **Renewal Email Template** — sent N days before expiry * **Rejection Email Template** — sent when an internal reviewer rejects a received document Leave the defaults in place to use the bundled templates. Override individual slots if you want bespoke wording for this document type. ### Step 4: Set the renewal window * **Renewal Days** — defaults to `30`. Number of days before the document's end date that the system should automatically request renewal. Set to `0` to disable automatic renewal for this document type (manual-only renewals). ### Step 5: Set up the approval chain 1. Save the Certifiable Document. 2. Open it in view mode — an **Approvers** subtab appears. 3. Click **New** on the Approvers subtab to add an approver: * **Employee** — the NetSuite Employee who approves at this level * **Order** — a number indicating where this approver sits in the chain. Lower numbers approve first. 4. Repeat for each level of the chain. Leave the Order field blank for a single-approver chain. When a Docs Submitted record is created for this document type, the system copies the entire approval chain onto the submission as a per-instance sublist. As each approver actions the document, their row on the submission is stamped with a date. ### Step 6: (Optional) Tweak Decline Reasons The Decline Reasons list is shared across the SuiteApp but is filtered by entity type on the external upload page. If you want to add a reason specific to a new document type, navigate to **FullClarity → Certified Documents → Decline Reasons → New** and add it to the correct entity-type list. ## What success looks like * The new Certifiable Document appears in the library at **FullClarity → Certified Documents → Certifiable Documents**. * Its Approvers subtab lists the right approvers in the right order. * Opening a vendor, customer or employee record (depending on which entity types you ticked) and adding a Required Doc shows your new document type in the dropdown. ## Gotchas * **Operating Workflow is mandatory.** Without it, no automation runs — the document type exists but Docs Submitted records won't progress. If you leave it blank, the post-deploy MR script will eventually default it to Manual mode. * **Approval order is per-document-type.** The chain is copied to the submission at creation time; subsequent edits to the chain on the Certifiable Document don't retrospectively update in-flight submissions. * **Including end date drives renewal.** Without end date enabled, renewal never fires regardless of the Renewal Days value. Confirm the document genuinely expires before enabling renewal. * **Description text is customer-facing.** It appears on the external upload page. Avoid internal jargon — write for the recipient. * **Renewal Days = 0 disables renewal.** It does not mean "renew on the day of expiry". To handle that, set Renewal Days to 1 (or whatever short interval makes sense). ## Related * [Request a document from a vendor](./request-a-document-from-a-vendor) * [Approve or reject a submission](./approve-or-reject-a-submission) --- --- url: 'https://fullclarity.help/certified-documents/install-configure.md' --- # Install & configure Install the SuiteApp, enable the required NetSuite features, confirm the supporting SuiteApps are in place, and verify the post-deploy steps have run. \[\[toc]] ## Module requirements **Required NetSuite features** * Custom Records * Server-Side Scripting * Token-Based Authentication (used by the external upload portal to call back into NetSuite) * Workflow * Accounting * CRM **Optional features supported** * Subsidiaries (OneWorld) * Mail Merge (the request, reminder, renewal and rejection email templates are mail-merge enabled) * Multi-Subsidiary Customer * Jobs ## SuiteApp dependencies Certified Documents requires three other FullClarity SuiteApps: | Dependency | Why | |---|---| | **Portal** | Provides the external-facing upload pages, storage region/bucket configuration, and the signed-URL generator used in request emails | | **File Storage** | Persists the uploaded files in your S3-backed storage. Each upload is recorded as a File Storage record linked to the Docs Submitted record | | **Code Library** | Provides the FullClarity entity subtab where Required Docs and Docs Submitted appear on Vendor, Customer and Employee records | All three install automatically when you install Certified Documents from the SuiteApp Control Centre. ## Installing the SuiteApp 1. In NetSuite, navigate to **Customisation → SuiteApps → SuiteApp Control Centre**. 2. Find **FullClarity Certified Documents** and click **Install**. 3. Accept the dependency prompts for Portal, File Storage and Code Library if not already installed. 4. Wait for the install to complete — the post-deploy script confirms File Storage integration is wired up, and seeds the Decline Reason list with the bundled defaults. ## Post-deploy verification After install, confirm: 1. **The Certified Documents centre tab is visible** — navigate to **FullClarity → Certified Documents**. You should see Certifiable Documents, Required Docs, Docs Submitted, and the Decline Reasons reference list. 2. **Decline Reasons are seeded.** Open the Decline Reasons list — expect nine entries (three per entity type: Vendor, Customer, Employee). 3. **Portal storage region is configured.** Certified Documents uses Portal's signed-URL generator to build upload links. If Portal isn't configured, request emails won't have working links. See the Portal section for region setup. 4. **Email Author is set.** Confirm there's a NetSuite user designated to send the automated request, reminder, renewal and rejection emails. The default sender is configured per certifiable document type. ## Email templates Four default email templates ship with the SuiteApp: | Template | Trigger | |---|---| | **Default Request Email** | First request when a Required Doc is created (Auto Send mode) or actioned (Manual mode) | | **Default Reminder Email** | Sent on a 7-day cadence until the document is received | | **Default Renewal Email** | Sent N days before expiry (default 30; configurable per document type) | | **Default Rejection Email** | Sent when an internal reviewer rejects a received document | Customise the wording by editing the templates at **Documents → Templates → Email Templates** and filtering to the FC CD prefix, or by creating your own templates and selecting them on individual certifiable document types. ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for installing and configuring Certified Documents is being recorded. Track its status in the Scribe register (internal). ::: ## What success looks like * The Certified Documents centre tab shows under **FullClarity** in the top navigation. * Vendor, Customer and Employee records have a Required Docs sublist visible on the FullClarity entity subtab. * A test upload of a document via the external portal completes successfully — the uploaded file appears against the Docs Submitted record. ## Gotchas * **Portal must be installed *and* configured.** Installing Portal is not enough — the storage region and bucket must be set on Portal's Configuration record before upload links will work. If you install Certified Documents into an account where Portal exists but isn't configured, request emails will fire but the links will return an error. * **Token-Based Authentication is required.** The external portal calls back into NetSuite via a RESTlet using token-based auth. Without the feature enabled, the upload step fails silently from the recipient's perspective. * **The default email author needs send-as-someone permissions.** If the configured email-author user has been deactivated, automated emails will queue but not send. Check the user is active and has permission to send email. * **Mail Merge is optional but recommended.** The bundled email templates are mail-merge enabled — without Mail Merge feature on, the template falls back to static text and won't substitute fields like the contact's name or the document description. ## Related * [Set up a document type](./how-to/set-up-a-document-type) * [Request a document from a vendor](./how-to/request-a-document-from-a-vendor) --- --- url: 'https://fullclarity.help/certified-documents/quick-start.md' --- # Quick start Set up one document type, attach it to one vendor, and send the first request — end to end. \[\[toc]] ## The happiest path 1. **Install Certified Documents** from the SuiteApp Control Centre. Portal, Code Library and File Storage install as dependencies if they're not already in place. 2. **Verify Portal is configured** with a storage region — Certified Documents uses Portal's signed upload pages. See the Portal section for region setup. 3. **Create a Certifiable Document type.** Navigate to **FullClarity → Certified Documents → Certifiable Documents → New**. As a worked example, create *Public Liability Insurance*: * Name: `Public Liability Insurance` * Description: `Current certificate of currency for $20m public liability` * Tick **Include End Date** so the system tracks expiry * Tick **Required From Vendor** * Document Type: `Vendor` * Operating Workflow: `FC CD Docs Submitted (Auto Send)` — emails fire as soon as the requirement exists * Leave the email templates at their defaults; the bundled templates cover the request, reminder, renewal and rejection cases 4. **Attach the requirement to a vendor.** Open any vendor record, find the **Required Docs** sublist (on the FullClarity entity subtab), and add a new row pointing at *Public Liability Insurance*. Set the default contact email. 5. **Watch the email fire.** Within a couple of minutes the system creates a **Docs Submitted** record in **Requested** status, generates a signed upload link, and emails it to the contact. The Docs Submitted record now drives the rest of the lifecycle. 6. **Recipient uploads the document.** The contact clicks the link in the email, lands on a branded upload page, picks the file, enters the end date, and submits. The submission status moves to **Received**. 7. **Approve internally.** The approval chain defined on the certifiable document type kicks in. Each approver gets an in-NetSuite prompt to approve or reject; when the last approver approves, the status moves to **Approved**. 8. **Sit back.** The system will request renewal automatically N days before the end date (30 by default), and will mark the document **Expired** once the date passes without a new submission. ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this quick start is being recorded. Track its status in the Scribe register (internal). ::: ## What success looks like * A **Docs Submitted** record exists in **Approved** status on the vendor. * The uploaded file is stored in your File Storage S3 region and visible from the Docs Submitted record. * The Docs Submitted record's end date is set and the renewal countdown is running. ## Common stumbling blocks * **Request email doesn't fire.** Most often the operating workflow is set to Manual when you expected Auto Send. Check the certifiable document type's **Operating Workflow** field. * **Upload link returns an error.** Means Portal isn't fully configured — check that the storage region is set on Portal's Configuration record and that the bucket is accessible. * **No approval prompt for the configured approvers.** Approval chain copies happen on Docs Submitted creation. If the chain was edited after the requirement was created, edit the Docs Submitted record to refresh the per-submission approver sublist. ## Next steps * [Install & configure](./install-configure) — full configuration walkthrough * [Set up a document type](./how-to/set-up-a-document-type) * [Request a document from a vendor](./how-to/request-a-document-from-a-vendor) --- --- url: 'https://fullclarity.help/certified-documents/reference/permissions.md' --- # Permissions reference How to grant your users access to Certified Documents. \[\[toc]] ## The model Unlike Project Financials, Retainage, File Storage, and Timeline, Certified Documents does **not** ship with an *Assign Permissions* Suitelet (the *allocator*). Permissions on Certified Documents custom records must be configured manually on each role that needs access. A future release will introduce an allocator on the standard FullClarity pattern. Until then, follow the manual instructions below. ## The bundled FC Cert Docs Admin role Certified Documents ships with a bundled administrator role, `FC Cert Docs Admin`. The role has Full access to the Certified Documents custom records and is suitable as: * A reference for what permissions a power-user role needs in your account, or * A direct assignment in small accounts where a single user manages all certified-document workflows. For most production deployments, partners prefer to grant Certified Documents permissions *into the customer's existing roles* — Document Controller, Project Administrator, Compliance Officer, whatever your users already use — rather than asking those users to switch into the FC Cert Docs Admin role to use the feature. ## Which roles should be granted Certified Documents access? Grant Certified Documents permissions to: | Role type | Why they need Certified Documents access | |---|---| | **Document Controllers** | Upload and manage submitted documents; track expiry; chase renewals | | **Project Administrators / Compliance Officers** | Define required document lists per vendor or project; review approvals | | **Approvers** | Sign off on submitted documents (Insurance Certificates, Licences, Safety Compliance, etc.) | | **Project Managers** | View certified-document status for their projects' vendors | Conversely, the following do **not** typically need Certified Documents access: * Operational or sales-only roles that don't manage vendor or contractor compliance. * External stakeholders — give them View access to specific documents through standard NetSuite mechanisms if needed. ## Granting access manually For each role that needs Certified Documents access, edit the role record and add the following Custom Record permissions. Modelling on the FC Cert Docs Admin role is the safest approach. | Custom record | Permission level | Notes | |---|---|---| | FC Cert Docs Approver | Full | Approvers list configuration | | FC Cert Docs Certifiable Document | Full | Document types your account certifies | | FC Cert Docs Doc Decline Reasons | Full | Reasons available when rejecting a submission | | FC Cert Docs Doc Submit Approver | Full | Approver assignments per submission | | FC Cert Docs Doc Submitted | Full | The submitted documents themselves | | FC Cert Docs Required Documents | Full | What documents are required (per project, per vendor, etc.) | | FC Cert Docs Doc Types | Full | The types of certifiable documents available in the system | You can grant narrower than Full access (View, Create, Edit) where appropriate — for example, an Approver role might need Edit on Doc Submitted (to approve or decline) but only View on Required Documents. In addition, grant View on **Subsidiaries** in multi-subsidiary (OneWorld) accounts so users can see which subsidiary a document belongs to. ::: warning Manual permissions are not upgrade-safe When Certified Documents is upgraded with new custom records, manually-configured roles will not automatically receive permissions on the new records. Each role needs to be revisited after every upgrade. The future allocator will handle this — until then, review your roles after each release. ::: ## Certified Documents is granted separately from other SuiteApps A role granted access to Project Financials, Retainage, File Storage, or Timeline does **not** automatically receive Certified Documents permissions. If a user needs Certified Documents in addition to another SuiteApp, configure each role's Certified Documents access manually as above. ## Related * [Install & configure](../install-configure) * [Project Financials Permissions](../../project-financials/reference/permissions) * [File Storage Permissions](../../file-storage/reference/permissions) --- --- url: 'https://fullclarity.help/code-library.md' --- # Code Library Code Library is the foundational FullClarity SuiteApp. Every other FullClarity SuiteApp depends on it — you install Code Library because the apps you actually want declare it as required. \[\[toc]] ## What Code Library is Code Library is a shared platform layer used by every other FullClarity SuiteApp. It contains no construction-specific business logic of its own; instead, it provides infrastructure that the feature apps build on top of: * **A shared layer of code** that every FullClarity SuiteApp uses to interact with NetSuite — common utilities for records, searches, formatting, and runtime configuration. This means every FullClarity app behaves consistently and updates can be rolled out across the ecosystem at once. * **Shared third-party libraries** — TreeGrid (the spreadsheet-like grid component used by Estimating, the Gantt, and other worksheets), jQuery, Moment.js, Dropzone, Handlebars, and a handful of others. Hosting them centrally means every FC app uses the same version. * **TreeGrid distribution and styling** — the TreeGrid 16.0 component plus FullClarity's custom styles. Estimating, the Gantt, claim assessment, and other spreadsheet-style views all use this. * **Subsidiary tracking and transaction classification** — a synced mirror of NetSuite's Subsidiary records and a shared transaction-type tag that every FC SuiteApp can read. In addition to the platform role, Code Library carries some ecosystem-management capabilities: licence validation, a centralised permission framework, and a shared report registry. These are mostly used by FullClarity internally for audit and by administrators for cross-app reporting. ## Why every account installs it Code Library is a required dependency of every other FullClarity SuiteApp: * [Project Financials](/project-financials) — depends on Code Library for all its shared modules, transaction-type tagging, and the Estimate Worksheet's TreeGrid * [Gantt/Timeline](/timeline) — uses Code Library's TreeGrid for the Gantt view * [File Storage](/file-storage) — uses the shared file-upload library * [Portal](/portal) — uses Code Library's subsidiary tracker and CloudFront URL signing * [Certified Documents](/certified-documents) — uses the permission framework * [Retainage](/retainage) — uses transaction-type tags for AR/AP retention * Construction (meta-package) — pulls Code Library in as a transitive dependency If you're installing any FullClarity SuiteApp from the SuiteApp Control Centre, Code Library is installed automatically as a required dependency. You don't usually install it directly. ## What Code Library is not * Not a construction SuiteApp in its own right — there are no estimating, contracts, or claim flows here. Those live in [Project Financials](/project-financials). * Not a thing end users interact with. There are no user-facing screens, no how-tos, no day-to-day workflows. It's pure infrastructure. ## Next steps * [Install & configure](/code-library/install-configure) — really just "install it before any other FullClarity app". No further configuration is required. --- --- url: 'https://fullclarity.help/code-library/install-configure.md' --- # Install & configure Install Code Library via the SuiteApp Control Centre. No further configuration is required. \[\[toc]] ## Module requirements Code Library needs two NetSuite features enabled. Go to **Setup → Company → Enable Features** to confirm they're on: * **Custom Records** (SuiteCloud tab) * **Server SuiteScript** (SuiteCloud tab) Code Library uses an additional range of NetSuite features at runtime if your account has them — Accounting, Jobs, CRM, Custom Segments, Custom Transactions, Custom GL Lines, Payables, Receivables, Expense Reports, and a few others. None of these are hard requirements; Code Library detects which features are enabled and adapts accordingly. The individual feature SuiteApps (Project Financials, Retainage, etc.) declare their own feature requirements separately. ## Installing the SuiteApp Install Code Library via the SuiteApp Control Centre. The deployment installs all files and objects in the SuiteApp. In practice, you rarely install Code Library on its own — every other FullClarity SuiteApp declares it as a required dependency, so installing any one of them (Project Financials, Retainage, Timeline, File Storage, Portal, Certified Documents, Construction) installs Code Library automatically as part of the same flow. ## Configuration There is no configuration step. Code Library is pure infrastructure — once installed, the other FullClarity SuiteApps that depend on it will start using its shared modules automatically. ## Permissions There are no user-facing screens in Code Library, so no end-user permissions need to be granted. The shared records that Code Library manages (subsidiary tracking, transaction-type list, report registry, permission records) have their access controlled automatically by the consuming SuiteApps. ## What success looks like * After install, any FullClarity SuiteApp that depends on Code Library can install without dependency errors. * The other FC SuiteApps' shared features — Estimate Worksheet's TreeGrid, the Gantt's TreeGrid, transaction-type tagging on revenue and bills, subsidiary lookups — work without further setup. ## Related * [Project Financials](/project-financials) — the primary consumer of Code Library * [Portal](/portal) — the second SuiteApp most accounts install * [File Storage](/file-storage) --- --- url: 'https://fullclarity.help/connect.md' --- # Connect FullClarity Connect is a set of web and mobile apps that give the people working on your projects — site teams, head contractors, subcontractors and vendors — secure access to what they need, without a NetSuite login. From the field or the office they can submit and track progress claims (with photos from the mobile app), view their work orders, and share documents, all flowing straight back into FullClarity in NetSuite. We're expanding this section with full guidance over the coming weeks. In the meantime: * **Subcontractor tasks** are already documented under [Subcontracts](/subcontracts) — submitting claims, viewing work orders and more. * **Need help now?** Email support@fullclarity.com or talk to your FullClarity implementation consultant. --- --- url: 'https://fullclarity.help/construction.md' --- # Construction for NetSuite Construction for NetSuite is a meta-package — a single named SuiteApp that installs the core FullClarity construction stack ([Project Financials](/project-financials), [Portal](/portal), and [Code Library](/code-library)) in one step. \[\[toc]] ## What the meta-package is Construction for NetSuite is the saleable product name for the full FullClarity construction stack. Installing it in a NetSuite account pulls in the three underlying SuiteApps as required dependencies: * **[Project Financials](/project-financials)** — the engine. Quoting, estimating, contracts, claims, progress billing, vendor management, revenue recognition, capitalisation, lot/development tracking — every construction-specific workflow lives here. * **[Portal](/portal)** — the foundational infrastructure SuiteApp that connects NetSuite to FullClarity's cloud storage and to external users (vendors, subcontractors, customers). * **[Code Library](/code-library)** — the shared platform layer that every FullClarity SuiteApp depends on. The Construction bundle itself ships nothing — no custom records, no scripts, no workflows. Its job is to make installation a one-step decision: install Construction, get the whole stack. ## Why the meta-package exists There are three reasons Construction is packaged as a single bundle rather than just three separate installs: 1. **Product identity.** "Construction for NetSuite" is the saleable product. A customer buying Construction gets the full stack in one go. 2. **Licensing anchor.** Entitlements and upgrades are managed against this bundle, simplifying licence tracking compared to managing three independently. 3. **Customisation slot.** The bundle reserves two folders (`Html_Templates/` and `Media/`) for Professional Services or administrators to drop in per-customer content — for example, branded PDF templates or letterhead images — that survives upgrades and isn't bundled into any of the three feature SuiteApps. ## What installing Construction does for you When you install Construction from the SuiteApp Control Centre, NetSuite resolves the dependency graph and pulls in all four bundles in the right order: Code Library first, then Portal and Project Financials, then Construction itself. If any of the three feature SuiteApps is already installed at the same or newer version, it's left as-is; if it's older, NetSuite upgrades it. After install, all the functionality you'd expect from the FullClarity construction stack is available. There is no separate Construction-specific configuration step — every feature is administered through its underlying SuiteApp. ## Where to go next There are no Construction-specific how-tos. Everything substantive lives in the feature SuiteApps: * **[Project Financials](/project-financials)** — for the actual construction workflows. This is where you'll spend most of your time. * **[Portal](/portal)** — for the one-off account registration step. * **[Code Library](/code-library)** — installed automatically; nothing to configure. ## A note for administrators and Professional Services The Construction bundle reserves two folders inside its FileCabinet location for per-customer content: * `FileCabinet/SuiteApps/com.fullclarity.construction/Html_Templates/` — per-customer HTML templates (typically used for branded PDF/email templates) * `FileCabinet/SuiteApps/com.fullclarity.construction/Media/` — per-customer media assets (typically logos and letterhead imagery) Both folders are deliberately left unlocked and visible so administrators and Professional Services can drop content into them without bundle-owner permissions. Content placed in these folders is preserved across Construction bundle upgrades. Refer to your FullClarity Professional Services contact for advice on what belongs in each folder. --- --- url: 'https://fullclarity.help/file-storage.md' --- # File Storage for NetSuite File Storage is the FullClarity SuiteApp that gives you a consistent, low-friction way to attach documents to any NetSuite record — stored in the cloud rather than the NetSuite File Cabinet. \[\[toc]] ## What File Storage is Out of the box, NetSuite stores attached documents in the File Cabinet. That works for a handful of files but doesn't scale well: File Cabinet storage is metered, the upload experience is clunky on most records, and there's no consistent surface for showing related documents inline on a record. File Storage replaces that workflow with a cloud-backed upload widget that appears on virtually any record type in NetSuite — transactions, customers, vendors, projects, items, custom records, even cases and messages. Files live in secure cloud storage (in the region you choose at install), not in the File Cabinet, and downloads are served quickly worldwide through short-lived secure links. For a product overview and related materials, visit the [File Storage product page](https://fullclarity.com/products-for-netsuite/netsuite-file-storage/) on our website. ## What it does * **Universal attachment widget** — a single drag-and-drop upload zone, plus a list of attached files, that admins can enable on whichever record types your account uses * **Cloud storage** — files are held in secure cloud storage in the region of your choice (Australia, USA, India, UK, Singapore, Canada, Sweden, or Ireland), not in NetSuite's File Cabinet * **Versioning** — re-uploading a file under the same name keeps the history; older versions stay accessible * **Signed links** — every download link is generated on demand and expires after 48 hours, so links can't be shared indefinitely * **Soft delete with recovery** — deleted files are flagged inactive for 30 days before permanent removal, so you can recover accidental deletions * **Migration tooling** — bulk migration from the NetSuite File Cabinet into cloud storage, gated per subsidiary, with a configurable retention window before the File Cabinet copy is removed * **Custom record support** — enable the widget on any custom record, including custom records that ship inside other SuiteApps ## Where this fits in the ecosystem File Storage is foundational — several other FullClarity SuiteApps use it as their document store: * **Project Financials** uses File Storage for Field POs, Contracts, Claims, and Daily Logs. * **Certified Documents** stores certificates and supporting documents through File Storage. * **Subcontracts** uses File Storage for back-up documents on subcontract claims (via Project Financials). File Storage in turn depends on **Portal**, which provides the underlying cloud storage infrastructure (secure cloud storage, fast worldwide delivery, and secure download links) that File Storage relies on. Install Portal first, then File Storage. ## Design intent File Storage is **not** a mass document repository. It's designed for a handful of source documents per record — drawings on a project, signed contracts on a customer, supporting receipts on a transaction. If you're storing thousands of files per record, you're outside the design envelope. ## Next steps * [Install & configure](/file-storage/install-configure) — module requirements, install steps, and the permission-allocation utility * [Enable on a record type](/file-storage/how-to/enable-on-a-record-type) — switch the File Storage widget on for standard and custom records * [Migrate from File Cabinet](/file-storage/how-to/migrate-from-file-cabinet) — bulk-migrate existing NetSuite File Cabinet documents into File Storage * [Permissions reference](/file-storage/reference/permissions) — manual permission tables for accounts that don't use the automated allocator --- --- url: 'https://fullclarity.help/file-storage/how-to/connect-microsoft-365.md' --- # Connect your Microsoft 365 / SharePoint Store your File Storage documents in **your own Microsoft 365 tenant** (SharePoint document libraries) instead of FullClarity-hosted cloud storage — under your own access controls, retention, eDiscovery and DLP. ::: warning Draft — feature in development This connection feature is being built and is **not yet available** in your account. This page is an early preview of the setup so your IT / Microsoft 365 team can plan ahead. Steps may change before release. ::: \[\[toc]] ## How it works (and what FullClarity can and can't see) This is a **bring-your-own-tenant** model. **You** register an application in **your own** Microsoft 365 directory and grant it access only to the specific SharePoint sites you choose. FullClarity never holds your sign-in credentials and never holds the application's certificate key or secret — whichever you choose stays inside **your** NetSuite account and is used there to prove the application's identity to Microsoft. (See [Choose your authentication method](#choose-your-authentication-method) for the two options.) ::: tip FullClarity is granted **Write** to your chosen sites — nothing more The application only ever needs the **Write** permission, on the **specific sites you grant it**. It **cannot** administer or manage your SharePoint, change tenant or site settings, alter sharing or permissions, or reach any site you haven't explicitly granted. Everything below — including adding the two columns — works with **Write only**. ::: * You can connect **more than one** Microsoft 365 tenant, and **multiple sites** within a tenant. * You decide **which records go to which site** using routing rules; anything not routed to SharePoint stays in FullClarity-hosted cloud storage. * Access is **per-site and revocable** — the application can only see the sites you explicitly grant, and you can withdraw access at any time from Microsoft 365. ## Choose your authentication method The application proves its identity to Microsoft in one of two ways. Both are equally secure in what the application can *reach* — they use the identical least-privilege `Sites.Selected` permission and per-site **Write** grant described below. The choice only affects how the application signs in, and how much setup it takes. **FullClarity never holds your credentials in either case** — the certificate's private key, or the secret, lives inside *your own* NetSuite account. | | **Certificate** *(strongest)* | **Client secret** *(simplest)* | |---|---|---| | How it signs in | NetSuite signs each request with a private key. The key never leaves your account and is never sent to Microsoft. | NetSuite sends a shared secret to Microsoft when signing in. The secret is stored **encrypted** inside your NetSuite account. | | Setup effort | Higher — create a certificate, upload its public half to Microsoft, store the private half in NetSuite. | Lower — create a secret in Microsoft, paste it into the connection. No certificate tooling. | | Best suited to | Organisations with stricter credential-handling requirements. | Many organisations, especially smaller teams without strict policies. | | Renewal | Rotate the certificate before it expires (e.g. every 2 years). | Rotate the secret before it expires (set when you create it). | Pick whichever fits your organisation. The rest of this guide notes where the two paths differ — everything else is the same. Why is the certificate method stronger? Its private key is never transmitted — NetSuite uses it to *sign* each sign-in locally — so a stolen secret alone can't impersonate the application; an attacker would also need the key file and its password. A client secret, by contrast, is a single value that is enough to sign in on its own. For many organisations that trade-off is perfectly acceptable; choose the method that matches your security policy. ## Prerequisites * A **Microsoft 365 administrator** who can register an application and grant admin consent (Global Administrator or Privileged Role / Application Administrator). * A **SharePoint administrator** to grant the application access to the chosen site(s). * A **NetSuite administrator** (or the FullClarity onboarding team) for the NetSuite side. * File Storage installed in your NetSuite account. * For the **Certificate** method: a certificate (a self-signed certificate is acceptable). Your IT team can create one, or use the example below. *(Not needed for the Client-secret method.)* ## Part 1 — In Microsoft 365 (your IT / M365 admin) ### 1.1 Create your credential ::: tip Which one? Follow **Certificate path** *or* **Client-secret path** below, matching the method you chose above. You don't need both. ::: #### Certificate path A certificate has two halves: a **public** part that goes to Microsoft, and a **private** part (the key) that goes into your NetSuite account. If your team has its own certificate process, use it; otherwise this creates a self-signed certificate valid for two years: ```bash # public certificate + private key openssl req -x509 -newkey rsa:2048 -keyout m365.key.pem -out m365.cert.pem \ -days 730 -nodes -subj "/CN=FullClarity File Storage" # bundle both into a password-protected file for NetSuite openssl pkcs12 -export -legacy -inkey m365.key.pem -in m365.cert.pem \ -name "FullClarity File Storage" -out m365.p12 ``` Keep `m365.cert.pem` (public — for Microsoft), `m365.p12` (for NetSuite) and the password you set. #### Client-secret path No certificate is needed — skip to step 1.2 now. You'll create the secret in step 1.3, once the application exists. ### 1.2 Register the application In the Azure / Entra admin centre: **Microsoft Entra ID → App registrations → New registration**. * Name it something recognisable, e.g. *FullClarity File Storage*. * Account type: **single tenant** (this directory only). * Leave the redirect URI blank. From the application's **Overview**, note the **Directory (tenant) ID** and the **Application (client) ID**. ### 1.3 Add your credential to the application #### Certificate path On the application: **Certificates & secrets → Certificates → Upload certificate**, and upload `m365.cert.pem`. Note the **Thumbprint** shown. #### Client-secret path On the application: **Certificates & secrets → Client secrets → New client secret**. Give it a description and an expiry, then **Add**. Copy the secret's **Value** immediately (it's only shown once) — this is what you paste into NetSuite in step 2.1. Note the expiry date so you can rotate it in time. ### 1.4 Grant the SharePoint permission On the application: **API permissions → Add a permission → Microsoft Graph → Application permissions**, add **`Sites.Selected`**, then **Grant admin consent**. `Sites.Selected` gives the application **no access on its own** — it can reach only the sites you grant in the next step. ### 1.5 Grant the application access to your chosen site(s) `Sites.Selected` gives no access by itself — a SharePoint/Global admin must grant the application **write** access to each specific site you want to use. **There is no button for this in the admin portal**; the grant is made with a Microsoft Graph call. Do it once per site (your FullClarity onboarding contact can do this with you). Either method below works. Repeat this step whenever you add another site later — no new application or certificate is needed within the same tenant. #### Option A — Graph Explorer (in the browser) 1. Open [Graph Explorer](https://developer.microsoft.com/graph/graph-explorer) and **sign in** as a Global or SharePoint administrator in your tenant. 2. Give Graph Explorer permission to make the grant: profile icon → **Consent to permissions** → search **`Sites.FullControl.All`** → **Consent**. (This authorises Graph Explorer to act as you; it is not a permission for the FullClarity application.) 3. **Find the site's ID** — set the method to **GET**. The address depends on the kind of site: **A team or communication site** (`https://{tenant}.sharepoint.com/sites/{site}`) — use the part after `/sites/`: ``` GET https://graph.microsoft.com/v1.0/sites/{your-tenant}.sharepoint.com:/sites/{your-site} ``` For example, for `https://fullclarity.sharepoint.com/sites/Finance`: ``` GET https://graph.microsoft.com/v1.0/sites/fullclarity.sharepoint.com:/sites/Finance ``` **Your main (root) site** (`https://{tenant}.sharepoint.com`, with nothing after the hostname) — drop the `:/sites/…` part and use the hostname on its own, or the keyword `root`: ``` GET https://graph.microsoft.com/v1.0/sites/fullclarity.sharepoint.com # or equivalently GET https://graph.microsoft.com/v1.0/sites/root ``` Run the query. The response looks like this (trimmed): ```json { "id": "fullclarity.sharepoint.com,11111111-2222-3333-4444-555555555555,66666666-7777-8888-9999-000000000000", "displayName": "Finance", "name": "Finance", "webUrl": "https://fullclarity.sharepoint.com/sites/Finance", "siteCollection": { "hostname": "fullclarity.sharepoint.com" } } ``` Copy the **`id`** value — the whole `hostname,,` string. That is the site ID you paste into the next step. 4. **Grant the application write access** — set the method to **POST**. The URL is `…/sites/{site-id}/permissions`, where `{site-id}` is the whole `id` you copied in step 3. Using the Finance example above: ``` POST https://graph.microsoft.com/v1.0/sites/fullclarity.sharepoint.com,11111111-2222-3333-4444-555555555555,66666666-7777-8888-9999-000000000000/permissions ``` On the **Request body** tab, paste the following. **You must replace `PASTE-YOUR-APPLICATION-CLIENT-ID` with your own Application (client) ID from step 1.2** — the same GUID shown on your app's Overview. (It's left as obvious placeholder text on purpose: if you send it unchanged the request fails, rather than silently granting access to the wrong identity.) ```json { "roles": ["write"], "grantedToIdentities": [ { "application": { "id": "PASTE-YOUR-APPLICATION-CLIENT-ID", "displayName": "FullClarity File Storage" } } ] } ``` A **201 Created** response confirms the grant. Keep `"roles": ["write"]` exactly — the app needs nothing higher. 5. *(Optional)* Verify with `GET https://graph.microsoft.com/v1.0/sites/{site-id}/permissions` — the application should be listed with the `write` role. #### Option B — PnP PowerShell If your organisation restricts Graph Explorer, an admin can run the [PnP.PowerShell](https://pnp.github.io/powershell/) module instead: ```powershell # Example for the team site https://fullclarity.sharepoint.com/sites/Finance # (for your main/root site, use https://fullclarity.sharepoint.com with no /sites/... suffix) Connect-PnPOnline -Url https://fullclarity.sharepoint.com/sites/Finance -Interactive Grant-PnPAzureADAppSitePermission ` -AppId "" ` -DisplayName "FullClarity File Storage" ` -Site https://fullclarity.sharepoint.com/sites/Finance ` -Permissions Write ``` ::: tip Removing access later To revoke the application's access to a site, delete the permission (`DELETE …/sites/{site-id}/permissions/{permission-id}` in Graph, or `Revoke-PnPAzureADAppSitePermission` in PnP PowerShell). The application immediately loses access to that site. ::: ### 1.6 Add the two FullClarity columns to the library File Storage uses two columns on the connected document library: * **FullClarity Visible** — marks which files appear in FullClarity. Files uploaded through FullClarity are set automatically; a file dropped straight into SharePoint is shown in FullClarity only once this is ticked. * **FullClarity Category** — holds the file's category. **You add these two columns yourself, in SharePoint — it needs no FullClarity permission beyond the `Write` already granted.** One of your site owners/admins adds them once, at setup: 1. Open the SharePoint site and the document library the connection points at (e.g. **Documents**). 2. At the right end of the column headers, choose **+ Add column** (or **Settings ⚙ → Library settings → Create column**). 3. Add the first column: * Type: **Yes/No** * Name: **`FullClarity Visible`** * Default value: **No** 4. Add the second column: * Type: **Single line of text** * Name: **`FullClarity Category`** That's it — the columns are library-wide, so they apply to every folder in the library. Run **Validate** on the FullClarity connection screen and it will confirm both columns are present. ::: warning Use these exact names Name the columns exactly **FullClarity Visible** and **FullClarity Category** — FullClarity matches them by these display names. ::: ::: details Optional — would you rather FullClarity create the two columns for you? This is **completely optional** and **entirely under your control**. FullClarity does **not** require it and does **not** keep any elevated access — adding the columns by hand (above) is the recommended path and needs only `Write`. If you'd prefer not to add them manually, one of your admins can let the application create them, then immediately remove the extra access: 1. **Temporarily** change the application's grant on this **one site** from `Write` to `Manage` (the same per-site grant from step 1.5, with `Manage`). 2. Open the **location** record in NetSuite and click **Provision Columns** — it creates the two columns. 3. **Change the grant straight back to `Write`.** The application holds the higher permission only for the few seconds it takes to create the columns, only on the single site you chose, and never retains it. If granting `Manage` even briefly isn't acceptable to your security policy, simply add the columns by hand as above. ::: ## Part 2 — In NetSuite (admin or FullClarity onboarding team) ### 2.1 Add your credential to NetSuite #### Certificate path Go to **Setup → Company → Preferences → Certificates** and add a new certificate: give it a clear name and ID, upload the `m365.p12` file, and enter its password. This stores the private key securely inside your account. #### Client-secret path There's nothing to add here — you'll paste the secret directly onto the connection when you set up the connection (step 2.2). (On the connection: set **Auth Mode** to **Secret**, paste the secret **Value** from step 1.3 into the **Secret** field — it's masked and stored encrypted — and set the **expiry** date.) ### 2.2 Set up the connection, locations and routing This is done from the **Storage** menu in NetSuite (under the FullClarity tab), which has three Microsoft 365 entries: * **M365 Connections** — one record per Microsoft 365 tenant. A connection holds the tenant, application and credential details — and its **Locations** live on the connection itself (step 2 below). * **M365 Routes** — rules that decide which records' files go to which location. * **M365 Setup and Validation** — a console for checking a connection works and finishing setup. 1. **Create the connection.** Go to **M365 Connections → New**. Give it a **Name** you'll recognise, choose the **Auth Mode** (Certificate or Client secret — see [Choose your authentication method](#choose-your-authentication-method)), and enter the **Tenant ID** and **Application (client) ID**. ::: warning These two IDs come from Microsoft, not from a SharePoint address The **Tenant ID** and **Application (client) ID** are the two GUIDs from your Entra app registration (step 1.2). They have nothing to do with any SharePoint URL — don't try to take them from a site address. ::: For the certificate method, point the connection at the certificate you added in step 2.1; for the client-secret method, paste the secret value. Tick **Enabled** and **save**. 2. **Add your SharePoint location(s).** On the connection you just saved, use the **Locations** sublist to add each SharePoint library or folder you want to use — one row per location. Give each a **Name** you'll recognise, and paste its **Root URL**. **How to get the Root URL — don't split it up.** In SharePoint, open the site and navigate to the exact library (or folder) you want files to land in, then copy the **whole address from your browser's address bar** and paste it into **Root URL**. The system reads the site, library and folder out of that one address for you. For example, this address: ``` https://contoso.sharepoint.com/sites/Finance/Shared%20Documents/Forms/AllItems.aspx?id=%2Fsites%2FFinance%2FShared%20Documents%2FProjects ``` resolves to: * **Site** — `Finance` * **Library** — `Shared Documents` * **Folder** — `Projects` (taken from the `id=` part of the address) Save the location — it resolves automatically. The **Resolved** fields (site, library, folder) fill in within a moment. If the address can't be reached, the save still succeeds and the **Resolve Status** field on the location explains why. To target the top of a library rather than a sub-folder, copy the library's address with no folder selected. 3. **Set up routing.** A **route** decides *where a record's files are stored* — a SharePoint location, or FullClarity-hosted cloud. Two things to understand first: * **Files default to FullClarity-hosted cloud.** A route is how you opt a particular kind of record *into* SharePoint. If no route matches, a record's files stay in FullClarity cloud — routing is purely additive, so nothing moves to SharePoint until you say so. * **Routing is separate from enabling File Storage.** Whether the upload widget appears on a record type at all is controlled by [Supported Records](./enable-on-a-record-type) — that's the on/off switch. Routing only decides the *destination* for record types that are **already enabled**. So enable the record type first, then route it. A route for a record type that isn't enabled does nothing — there's no widget to upload through. To add a route, go to **M365 Routes → New** and set: | Field | What it does | |---|---| | **Subsidiary** | The subsidiary (or subsidiaries) this rule applies to — select one or more. **Leave blank to apply to all subsidiaries.** | | **Record Type** | The kind(s) of record this rule applies to — pick one or more from the dropdown of friendly names (e.g. *Purchase Order*, *Bill*, *Customer Invoice*). The list only offers record types that are already enabled in [Supported Records](./enable-on-a-record-type). **Leave blank to apply to all record types.** *(Some closely-related types share one underlying type — for example the various item types route together — so choosing any member routes that whole family.)* | | **Target Location (Production)** | The SharePoint location matching files are stored in when this NetSuite account is a **production** account. | | **Target Location (Sandbox)** | The SharePoint location matching files are stored in when this NetSuite account is a **sandbox**. Leave blank to refuse SharePoint uploads in a sandbox, so a sandbox can never write to a production library. The two targets can point at the same place or at different ones — your choice. | | **Use FullClarity Cloud** | Tick this *instead* of a location to deliberately keep matching files in FullClarity cloud — useful as an exception to a broader rule. | | **Active** | Untick to switch a rule off without deleting it. | **Most specific rule wins, and subsidiary takes priority.** When a file is uploaded, File Storage picks the best-matching active route in this order: **subsidiary + record type** → **subsidiary only** → **record type only** → otherwise the **default (FullClarity cloud)**. Subsidiary is the stronger signal — a subsidiary-wide rule beats a record-type-only rule. So if you send *everything* in a subsidiary to one site but want a *specific record type* in that same subsidiary to go elsewhere, give that exception its own rule with **both** the subsidiary **and** the record type set; a record-type-only rule won't override a subsidiary rule. ::: tip In a sandbox A sandbox account writes to the route's **Target Location (Sandbox)** — never its production target — so testing never touches live documents. If a route has no sandbox target set, sandbox uploads are refused rather than sent to production. ::: 4. **Validate.** On the **connection** record, click the **Validate** button. It checks every location on the connection — confirming NetSuite can reach each site with your chosen credential and that the two FullClarity columns (step 1.6) are present — and shows a per-location result. (The separate **M365 Setup and Validation** console is still there for re-resolving a location by hand and for routing tests.) ## What success looks like * The connection validates: NetSuite can reach your chosen SharePoint site using your chosen credential. * Two FullClarity columns appear on the connected document library (used to mark which files should show in FullClarity and their category). * New files uploaded against routed records land in your SharePoint site, and appear in the File Storage list on the record within a few seconds. ## Gotchas * **Certificate expiry.** The certificate has an expiry date (two years in the example). Set a reminder to rotate it before it lapses, or uploads and downloads will stop until it's renewed. FullClarity will also surface an expiry warning in advance. * **Per-site access.** The application can only use sites you've explicitly granted. If a site isn't working, confirm the grant was made for that exact site. * **Sandbox vs production.** A sandbox refreshed from production can view production-origin files read-only; new sandbox uploads go to a separate sandbox location and never change production documents. * **Keep files within the granted library.** Moving or renaming files inside a connected library is fine. Moving a file out to a different library or site is flagged in FullClarity (the file is kept and marked, never silently lost). ## Related * [Install & configure](../install-configure) * [Enable File Storage on a record type](./enable-on-a-record-type) * [Permissions reference](../reference/permissions) --- --- url: 'https://fullclarity.help/file-storage/how-to/enable-on-a-record-type.md' --- # Enable File Storage on a record type Turn the File Storage drop zone and file list on for a standard NetSuite record (e.g. Vendor, Customer, Vendor Bill) or for a custom record — including custom records that ship inside other SuiteApps. \[\[toc]] ## When to use this By default, the File Storage widget is hidden and needs to be explicitly enabled on each record type your account uses. Do this once per record type after installation, then again whenever you decide to start storing files against an additional record type. The two paths — standard records versus custom records — are slightly different but both are admin-only and take a couple of minutes per record type. ## Prerequisites * File Storage installed and Portal registered for the subsidiary * **Administrator** role or the **FC Storage Admin** role * The record type you want to enable already exists (for custom records, the custom record type must be created first) ## Walkthrough ### Standard NetSuite records To enable the widget on a standard record type (Vendor, Customer, Vendor Bill, etc.), use the Supported Records configuration screen. ::: tip Walkthrough coming A step-by-step Scribe walkthrough for enabling File Storage on standard records is being recorded. Track its status in the Scribe register (internal). ::: ### Custom NetSuite records File Storage can also function on custom records, including custom records from other SuiteApps. Use the Supported Custom Records screen. ::: tip Walkthrough coming A step-by-step Scribe walkthrough for enabling File Storage on custom records is being recorded. Track its status in the Scribe register (internal). ::: ::: tip Test your custom record configuration in your sandbox account before applying it in production. If a custom record's structure changes in a way that File Storage doesn't expect, the widget can produce script errors that block save — easier to find in sandbox. ::: ## What success looks like * Opening a saved record of the enabled type shows the File Storage drop zone in the body of the record, plus a Documents heading underneath where uploaded files appear. * Uploading a small file from the drop zone completes successfully and the file appears under Documents within a few seconds. * The custom field that File Storage adds to the body of the record is visible. (You can re-position the field by editing the record's form template if your account uses a customised form layout.) ## Gotchas * **Files can't be uploaded during the create flow.** The record must be saved first — File Storage links files to the record's internal ID, which only exists after the first save. * **Disabling the widget on a record type.** To stop File Storage from running on a specific record, locate the **FC Storage Record UE** script, open its Deployments tab, edit the deployment for that record, and untick **Deployed**. Don't delete the deployment — that may be reset on the next File Storage upgrade. * **Forms with locked layouts.** If your account uses a heavily customised form, the File Storage field may land in an unexpected position. Edit the form template to move it. ## Related * [Install & configure](../install-configure) * [Migrate from File Cabinet](./migrate-from-file-cabinet) * [Permissions reference](../reference/permissions) --- --- url: 'https://fullclarity.help/file-storage/how-to/migrate-from-file-cabinet.md' --- # Migrate from File Cabinet Bulk-migrate existing documents from the NetSuite File Cabinet into File Storage's cloud storage, with a configurable retention window before the File Cabinet copies are removed. \[\[toc]] ## When to use this Most accounts run this once shortly after installing File Storage, to move existing attachments off the File Cabinet and onto the cloud. After the initial migration, new files go straight to File Storage and the File Cabinet stays empty for those record types. It's also useful when bringing additional subsidiaries online — the migration can be scoped per subsidiary using the enable flags on the Storage configuration record. ## Prerequisites * File Storage installed; the records you want to migrate already have File Storage enabled (see [Enable on a record type](./enable-on-a-record-type)) * **Administrator** or **FC Storage Admin** role * A maintenance window if you're migrating a large volume of files — migration runs as a Map/Reduce job and can take an hour or more for large datasets ## Walkthrough ::: tip Walkthrough coming A detailed Scribe walkthrough for the migration utility is being recorded. Until it lands, the high-level steps below describe what the migration does. Track its status in the Scribe register (internal). ::: The migration pipeline works in three stages: 1. **Scoping.** The Storage configuration record carries a per-subsidiary enable flag for migration. Tick the flag for each subsidiary you want to migrate. Migration only acts on record types that already have File Storage enabled, so confirm that list first. 2. **Discovery.** A scheduled Map/Reduce job walks every File Cabinet file attached to the in-scope record types and creates a migration source record for each one. The header migration run record gives a running total of files discovered and migrated. 3. **Transfer.** Each source file is uploaded to cloud storage and a matching File Storage Files record is created on the original NetSuite record. The migration tracking record is marked migrated. File Cabinet copies are retained for the configured window (90 days by default, adjustable from 1 to 365 days on the Storage configuration record) so you can verify the migration completed cleanly. After the configured retention window expires, a separate scheduled job removes the File Cabinet copies. Until then, the original File Cabinet file is still in place — making rollback easy if something looks wrong. ## What success looks like * Open a previously File-Cabinet-attached record. Its files now appear in the File Storage Documents section, with the same names and content as before. * The migration run record shows file counts matching the totals you expected, with no failed rows. * Within the retention window you can still see the original File Cabinet copies; after the window passes they're gone and the records show **Document Deleted** as ticked on the File Storage Files record. ## Gotchas * **Migration only runs against File-Storage-enabled record types.** If a record type isn't enabled in File Storage, its File Cabinet files are skipped. Enable the record types first, then run migration. * **Per-subsidiary scoping.** In OneWorld accounts, migration runs subsidiary by subsidiary. If a subsidiary's flag isn't ticked, its files aren't migrated. * **Don't delete the File Cabinet copies manually during the retention window.** The pipeline relies on the originals being in place to retry failed rows. Let the scheduled deletion job clean up at the end of the window. * **Migration is one-way.** Once a file is moved into File Storage, there is no built-in "demote back to File Cabinet" tool. If you change your mind on a record type, disable the File Storage widget there but the existing migrated files stay in cloud storage. ## Related * [Install & configure](../install-configure) * [Enable on a record type](./enable-on-a-record-type) --- --- url: 'https://fullclarity.help/file-storage/install-configure.md' --- # Install & configure Install the SuiteApp, enable the prerequisite NetSuite features, and grant permissions to the roles that need to upload, view, or delete files. \[\[toc]] ## Module requirements File Storage needs the following NetSuite features enabled. Go to **Setup → Company → Enable Features** to turn them on: **SuiteCloud tab** * Custom Records * Server SuiteScript * Token-Based Authentication ## SuiteApp dependencies File Storage depends on the **Portal** SuiteApp. Portal provides the underlying cloud storage infrastructure that File Storage uses — it must be installed and registered *before* you install File Storage. See [Portal](/portal) for installation and registration instructions. File Storage also depends on **Code Library**, which installs automatically as part of any FullClarity SuiteApp install. ## Installing the SuiteApp Install File Storage via the SuiteApp Control Centre. The deployment process installs all files and objects contained in the SuiteApp. You will receive an email confirming that your account has been provisioned and is ready for installation. Once you receive it, follow the steps below to install **FullClarity's File Storage for NetSuite**. ::: tip Walkthrough coming A step-by-step Scribe walkthrough for installation is being recorded. Track its status in the Scribe register (internal). ::: Having completed the installation, you now need to nominate which records you want File Storage to work on. See [Enable on a record type](./how-to/enable-on-a-record-type). ## Configure permissions Specific permissions are required to view or edit File Storage data. A full per-role permission breakdown is available at [Permissions reference](./reference/permissions); however, we strongly recommend using the automated permission allocation utility: ::: tip Walkthrough coming A step-by-step Scribe walkthrough for the permission allocator is being recorded. Track its status in the Scribe register (internal). ::: The automated allocator is update-safe — when File Storage is upgraded, any new custom records or fields are automatically granted to roles that already have File Storage access, and hidden from roles that don't. Manual permission configuration is **not** update-safe, so it should only be used for unusual cases. See the [Permissions reference](./reference/permissions) for the manual tables and the View / Create-only / Read-and-write permission sets. ## Modify forms When File Storage is installed, a custom field is automatically added to the main body of each enabled record type. The specific location of the field can be adjusted by editing the form template for that record — see NetSuite's standard help on customising form layouts. To **stop** File Storage from functioning on a specific record type, an administrator can disable the deployment for that record. Locate the **FC Storage Record UE** script, go to its **Deployments** tab, edit the deployment for the relevant record type, and untick **Deployed**. ## Sandbox accounts File Storage is safe to use with sandbox accounts, with two things to be aware of: * **Re-register the sandbox each time you refresh it.** NetSuite deletes all access keys during a sandbox refresh, so the Portal registration needs to be re-run. See [Portal](/portal/how-to/register-an-account). * **Files uploaded in production are accessible (read-only) from the sandbox.** You can view files from production in your sandbox but you cannot delete them. New files uploaded in the sandbox go to a separate test bucket and are deleted automatically after about six months. ## Supported record types File Storage supports almost all standard NetSuite record types — see the "Supported Records" configuration screen for the full list. Custom records are also fully supported; see [Enable on a record type](./how-to/enable-on-a-record-type). ## What success looks like * The File Storage drop zone and file list appear on the body of every enabled record type. * Uploading a small file from a saved record completes successfully and the file appears under **Documents** on the record within a few seconds. * Granting a role File Storage access via the allocator produces a visible role-permissions change on that role's record. ## Gotchas * **Files cannot be added during the "Create" process.** Because File Storage stores files against an existing NetSuite record, the record must be saved at least once before a file can be uploaded. Save the new record first, then add files. * **Portal must be installed and registered first.** File Storage will install without Portal but the upload widget will not work — every file operation relies on the cloud storage infrastructure that Portal provides. * **Manual permissions are not update-safe.** Use the allocator unless you have a specific reason to manually grant permissions. ## Related * [Portal](/portal) — the underlying infrastructure SuiteApp * [Enable on a record type](./how-to/enable-on-a-record-type) * [Permissions reference](./reference/permissions) --- --- url: 'https://fullclarity.help/file-storage/reference/permissions.md' --- # Permissions reference How File Storage grants access to its functionality, and how to give your users the right level of access on each role. \[\[toc]] ## The model FullClarity does not expect customers to assign the bundled FC Storage role to their users. Instead, File Storage permissions are granted *into the customer's existing roles* — Project Manager, AP Clerk, Document Controller, whatever your users already use — so they can work with files through File Storage as part of their normal day-to-day NetSuite role, without role-switching. A dedicated Suitelet (the *allocator*) handles the underlying NetSuite plumbing. You pick a role and click **Grant**; the Suitelet works out which File Storage custom records need to be granted on the role and writes them in one operation. When File Storage ships new custom records in a future release, re-running the Suitelet for the same role tops up the missing permissions automatically. ## How to grant access — the allocator The allocator gives a role Full access to all File Storage custom records. This is the recommended path for almost every role that needs to read, upload, or delete files. 1. Navigate to **FullClarity → Storage → Assign Permissions**. 2. Select the role you want to grant access to in the *Selected Role* dropdown. Only roles flagged *iscustom* appear in the list. 3. Click **Grant**. The Suitelet adds the required File Storage permissions to the role and records the grant in the FC Storage Information record. To revoke a role's access, repeat steps 1–2 and click **Revoke**. The Suitelet removes every File Storage custom record line from the role's permissions, cleanly and symmetrically. ::: tip Use the allocator unless you have a specific reason not to The allocator is the recommended path. It's the only way to get *upgrade-safe* permissions — when File Storage adds a new custom record in a future release, re-running the allocator picks it up. Manual permission configuration (see below) is not upgrade-safe. ::: ## Manual permission configuration If a role needs *narrower* access than Full — for example, view-only access for an external auditor, or create-without-delete for a clerk — the allocator can't help. The allocator only grants Full. To restrict a role to View, Create, or Edit, configure the permissions manually using the tables below. ::: warning Manual permissions are not upgrade-safe When File Storage is upgraded with new custom records, any role configured manually will **not** automatically receive permissions on the new records. Admins who configure permissions manually need to revisit each role after every File Storage upgrade to add the new objects. The allocator handles this automatically — use it where you can. ::: ### Prevent access To prevent a role from accessing any File Storage functionality, ensure that **no** permissions are granted on the **FC Storage Files** custom record. Without that permission, the widget cannot render for the role. ### View-only access Allows a role to view files but not upload or delete them. In addition to the appropriate access (View, Edit or Full) on the host record where files are stored, grant the following permissions: | Group | Item | Permission value | Notes | |---------------|---------------------------------|------------------|-------| | Lists | Subsidiaries | View | Required in multi-subsidiary (OneWorld) accounts | | Setup | SuiteScript | View | | | Custom Record | FC Portal API Urls | View | Users should **never** be given higher than View on this record | | Custom Record | FC Portal Configuration | View | Users should **never** be given higher than View on this record | | Custom Record | FC Portal Information | View | Users should **never** be given higher than View on this record | | Custom Record | FC Portal Storage Region | View | Users should **never** be given higher than View on this record | | Custom Record | FC Storage Files | View | | | Custom Record | FC Storage Files Versions | View | | | Custom Record | FC Storage Information | View | | | Custom Record | FC Storage Message Attachments | View | | | Custom Record | FC Storage Valid Type | View | | ### Create-only access Allows a role to upload files but not delete them. In addition to the appropriate access on the host record, grant: | Group | Item | Permission value | Notes | |---------------|---------------------------------|------------------|-------| | Lists | Subsidiaries | View | Required in OneWorld accounts | | Setup | SuiteScript | View | | | Custom Record | FC Portal API Urls | View | Never higher than View | | Custom Record | FC Portal Configuration | View | Never higher than View | | Custom Record | FC Portal Information | View | Never higher than View | | Custom Record | FC Portal Storage Region | View | Never higher than View | | Custom Record | FC Storage Files | Create | | | Custom Record | FC Storage Files Versions | Create | | | Custom Record | FC Storage Information | View | | | Custom Record | FC Storage Message Attachments | View | | | Custom Record | FC Storage Valid Type | View | | ### Read-and-write access Allows a role to upload **and** delete files. In addition to the appropriate access on the host record, grant: | Group | Item | Permission value | Notes | |---------------|---------------------------------|------------------|-------| | Lists | Subsidiaries | View | Required in OneWorld accounts | | Setup | SuiteScript | View | | | Custom Record | FC Portal API Urls | View | Never higher than View | | Custom Record | FC Portal Configuration | View | Never higher than View | | Custom Record | FC Portal Information | View | Never higher than View | | Custom Record | FC Portal Storage Region | View | Never higher than View | | Custom Record | FC Storage Files | Edit or Full | | | Custom Record | FC Storage Files Versions | Edit or Full | | | Custom Record | FC Storage Information | View | | | Custom Record | FC Storage Message Attachments | View | | | Custom Record | FC Storage Valid Type | View | | (Full access to **FC Storage Files** and **FC Storage Files Versions** is what the allocator grants; use Edit instead if you want to prevent the role from deleting file records.) ## File Storage is granted separately from other SuiteApps A role granted access to Project Financials, Retainage, Timeline, or Certified Documents does **not** automatically receive File Storage permissions. If a user needs File Storage in addition to another SuiteApp, you'll need to grant File Storage access through this allocator and the other SuiteApp's allocator independently. ## Soft-delete behaviour Files deleted through File Storage are not immediately removed. They are marked inactive and hidden from the record's file list, but the underlying record and the stored file are retained for **30 days**. After 30 days the file and the underlying record are permanently and irrevocably deleted. To recover a file within the 30-day window: 1. Search for the page **FC Storage Files** in the NetSuite global search. 2. Tick **Show Inactives** in the list view (otherwise inactive records won't appear). 3. Locate the file record and edit it. 4. Clear the **Date Deleted** field, then untick **Inactive**. The file becomes visible again on its host record. ## Related * [Install & configure](../install-configure) * [Enable on a record type](../how-to/enable-on-a-record-type) * [Project Financials Permissions](../../project-financials/reference/permissions) * [Retainage Permissions](../../retainage/reference/permissions) --- --- url: 'https://fullclarity.help/get-started.md' --- # Get started Welcome to the FullClarity Help Center. FullClarity is a suite of NetSuite SuiteApps designed specifically for the construction industry. It provides end-to-end project lifecycle management — estimating, contract administration, billing, claims, revenue recognition, document compliance, file management and scheduling — for estimators, project managers, finance teams and subcontractors. FullClarity runs inside NetSuite and requires no additional software installation. You'll need a supported web browser (Chrome, Firefox, Edge or Safari) and an active NetSuite account with the appropriate FullClarity SuiteApps installed. Connect (our web and mobile apps for field teams and subcontractors) runs in your browser or on iOS / Android. \[\[toc]] ## What we cover * **Construction** — [Project Financials](/project-financials), [Retainage](/retainage), [Timeline](/timeline), [Certified Documents](/certified-documents) * **[Subcontracts](/subcontracts)** — manage subcontracts end-to-end across the back office and Connect * **Storage** — [File Storage](/file-storage) and [Project Storage](/project-storage) * **[Connect](/connect)** — web and mobile apps for site teams, contractors and subcontractors * **Foundation** — [Portal](/portal), [Code Library](/code-library), [Construction (meta-package)](/construction) * **[AI Integration](/ai)** — connect any AI assistant to your NetSuite data ::: tip Documentation rollout is in progress. Some sections link to a "coming soon" placeholder while their pages are being written. Email support@fullclarity.com if you need help with an unwritten section. ::: ## First-time setup checklist If you've just purchased FullClarity, follow these steps in order: 1. **Register your NetSuite account with the Portal.** See [Portal account registration](/portal/install-configure#register-the-account). 2. **Install each FullClarity SuiteApp you've licensed** via the NetSuite SuiteApp Control Center. The Portal SuiteApp must be installed first. 3. **Configure each SuiteApp** by creating its configuration record. Most SuiteApps need one configuration record per subsidiary. 4. **Grant permissions** to the roles in your account that need access — see each app's *Install & configure* page. 5. **Set up Connect** if you've licensed it — register your users and link them to NetSuite employee or vendor records. 6. **Start with the Quick start** for the app you'll use first. ## By role Pick the on-ramp that matches your job: * **I'm a NetSuite administrator** — start with [Portal install & configure](/portal/install-configure), then enable permissions for each app you've licensed. * **I'm an estimator** — start with [Project Financials Quick start](/project-financials/quick-start) and the [Estimating walkthroughs](/project-financials/how-to/estimating/create-an-estimate). * **I'm a project manager** — start with [Creating a project](/project-financials/how-to/create-a-project). Connect docs for PMs are coming soon. * **I'm in finance** — Project Financials covers contracts, billing and revenue recognition. The detailed walkthroughs land in later phases of the documentation rollout. * **I'm a subcontractor** — Connect Mobile docs are coming soon. In the meantime, your head contractor will share login details and walk you through your first claim. ## Where to get help * **Email support:** support@fullclarity.com * **Talk to your FullClarity contact:** your assigned implementation consultant or partner * **Search the docs:** use the search box at the top of any page --- --- url: 'https://fullclarity.help/portal.md' --- # Portal Portal is the foundational FullClarity SuiteApp that connects your NetSuite account to FullClarity's cloud infrastructure. Several other FullClarity SuiteApps depend on it — install Portal first, then install whichever apps you actually want to use. \[\[toc]] ## What Portal is Portal is a piece of infrastructure rather than a feature most users will interact with directly. Its job is to: * **Bridge NetSuite to FullClarity's cloud storage.** Files attached through [File Storage](/file-storage) live in AWS S3 across eight global regions, and Portal handles the upload credentials, signed download links, and the content-delivery-network routing. * **Provide external-user access points.** When subcontractors, vendors, or customers sign in to [FullClarity Connect](/connect) or use the legacy vendor portal at `my.fullclarity.com`, those external sessions authenticate through Portal. * **Hold per-subsidiary configuration.** A Portal Configuration record per subsidiary determines which storage region your files go to and which API endpoint your account talks to. ## Who installs and uses Portal Portal is an administrator install. Once it's installed and the account is registered, users don't interact with Portal screens directly — they interact with whichever feature SuiteApp uses Portal's infrastructure (typically File Storage, Certified Documents, or Project Financials' Quote Portal). There are two routine admin tasks against Portal: * **Register the NetSuite account** with FullClarity's cloud infrastructure (a one-off, per account, repeated after every sandbox refresh). * **Refresh API credentials** if your security team rotates them or if a sandbox refresh wipes the existing pair. Both tasks are documented under [How to](#how-to) below. ## What depends on Portal Several FullClarity SuiteApps require Portal to be installed and registered before they can function: * **[File Storage](/file-storage)** — uses Portal's S3 and content-delivery infrastructure for every upload and download * **Certified Documents** — uses Portal's signed URLs to give external vendors a way to submit documents * **Project Financials** — uses Portal for the Quote Portal (sending RFQs to external bidders) and for Connect-related sync flows * **[FullClarity Connect](/connect)** — uses Portal for OAuth registration and webhook authentication ## Storage regions When you register your account, you choose one of eight S3 regions for your account's documents: | # | Region | AWS region | |---|---------------|-----------------| | 1 | Australia | ap-southeast-2 | | 2 | USA | us-east-1 | | 3 | India | ap-south-1 | | 4 | UK | eu-west-2 | | 5 | Singapore | ap-southeast-1 | | 6 | Canada | ca-central-1 | | 7 | Sweden | eu-north-1 | | 8 | Ireland | eu-west-1 | Default: USA. Choose the region closest to most of your users for fastest uploads and downloads. ## Next steps * [Install & configure](/portal/install-configure) — module requirements, install, registration, configuration record * [Register a NetSuite account](/portal/how-to/register-an-account) — the registration flow at my.fullclarity.com/register * [Refresh API credentials](/portal/how-to/refresh-api-credentials) — replace the API credentials with a fresh pair --- --- url: 'https://fullclarity.help/portal/how-to/refresh-api-credentials.md' --- # Refresh API credentials Replace the FullClarity API credentials on your NetSuite account with a fresh set — typically after a security rotation, a sandbox refresh, or when troubleshooting Portal-related errors. \[\[toc]] ## When to use this There are three common reasons to refresh API credentials: * **Sandbox refresh.** A NetSuite sandbox refresh deletes all access keys, so the previously-registered credentials no longer work. You need to re-register the sandbox. * **Security rotation.** If your security team rotates secrets on a schedule, you may want to refresh credentials to a fresh pair. * **Troubleshooting.** If Portal-backed features start failing with authentication errors, re-registering can resolve credential-corruption edge cases. In all three cases, the steps are the same: re-run the registration flow. ## Prerequisites * The Portal SuiteApp installed and previously registered * Either the **Administrator** role or the **FC Portal Admin** role * Your NetSuite **Company ID** ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for credential refresh is being recorded. Track its status in the Scribe register (internal). ::: API credentials are hidden from users in NetSuite — you can't edit them manually. To replace them, run the registration flow again: 1. Go to . 2. Enter your Company ID and sign in with the **Administrator** or **FC Portal Admin** role. 3. The registration completes and replaces the existing credentials with a freshly-generated pair. 4. You'll receive the same registration confirmation email as the first-time flow. ## What success looks like * The registration confirmation email arrives within a few minutes. * Portal-backed features (File Storage uploads, Certified Documents, Connect) resume working using the new credentials. * Previously-issued signed URLs may still work for their normal 48-hour window — new URLs are signed with the new credentials. ## Gotchas * **Users with active sessions need to sign in again.** API credentials are cached in user sessions. After a credential refresh, each user needs to log out and log back in for their session to pick up the new credentials. * **The old credentials stop working immediately.** Don't refresh credentials during a busy upload period unless you're prepared to have users re-authenticate. * **Re-registration is the only refresh path.** There is no separate "rotate credentials" screen — the registration flow is the credential-management flow. ## Related * [Install & configure](../install-configure) * [Register a NetSuite account](./register-an-account) --- --- url: 'https://fullclarity.help/portal/how-to/register-an-account.md' --- # Register a NetSuite account Register your NetSuite account (production or sandbox) with FullClarity's cloud infrastructure so Portal-backed features — File Storage, Certified Documents, vendor portals, Connect — can work. \[\[toc]] ## When to use this You need to register each NetSuite account once before you can use any Portal-backed FullClarity feature. You'll repeat the same registration step against: * **Every NetSuite account** you own — production, sandbox, development. Credentials don't carry between accounts. * **Every sandbox refresh.** NetSuite deletes all access keys during a sandbox refresh, so previously-registered sandboxes need to be re-registered. ## Prerequisites * The Portal SuiteApp installed in the NetSuite account * Either the **Administrator** role or the **FC Portal Admin** role assigned to your user account * Your NetSuite **Company ID** (visible at Setup → Company → Company Information) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for the registration flow is being recorded. Track its status in the Scribe register (internal). ::: 1. Go to . 2. Enter your **Company ID**. To find it, open the **Company Information** page in NetSuite (Setup → Company → Company Information). The format may be different from the value in your NetSuite URL — especially for sandbox or development accounts. 3. You'll be redirected to the standard NetSuite login screen. Sign in. 4. After login, choose either the **Administrator** or **FC Portal Admin** role for the relevant NetSuite account. 5. The registration process records the account, generates a unique set of FullClarity API credentials, and writes them into your NetSuite account. 6. You'll receive a confirmation email when registration completes. Wait for that email before configuring the SuiteApp — see [Install & configure](../install-configure). ## What success looks like * A confirmation email arrives within a few minutes of running the registration. * Opening Portal-backed screens (e.g. the File Storage drop zone on a record, or the Certified Documents vendor link) starts working as expected. * The Portal Configuration record can be created against the subsidiary without errors. ## Gotchas * **The Company ID is not always the same as the NetSuite account ID in the URL.** Use the value shown on the Company Information page. Sandbox and development accounts often have a different format. * **Each account needs its own registration.** Production and sandbox are separate registrations; credentials from one will not work against the other. * **Re-registering a sandbox after a refresh.** Sandbox refreshes wipe the access keys NetSuite holds for Portal, so the previously-registered credentials stop working. Simply run the registration flow again. This is the same flow as the first-time registration — see [Refresh API credentials](./refresh-api-credentials) for more on what re-registration does to existing credentials. ## Related * [Install & configure](../install-configure) * [Refresh API credentials](./refresh-api-credentials) --- --- url: 'https://fullclarity.help/portal/install-configure.md' --- # Install & configure Install the Portal SuiteApp, enable the prerequisite NetSuite features, register the account with FullClarity's cloud infrastructure, and create one Portal Configuration record per subsidiary. \[\[toc]] ## Module requirements Portal needs the following NetSuite features enabled. Go to **Setup → Company → Enable Features** to turn them on: **SuiteCloud tab** * SuiteBuilder * Custom Records * Advanced PDF / HTML Templates * SuiteScript * Client SuiteScript * Server SuiteScript * SuiteFlow * SuiteFlow * SuiteGL * Custom GL Lines * Custom Transactions * Custom Segments * Manage Authentication * Token-Based Authentication ## SuiteApp dependencies Portal depends on **Code Library**, which installs automatically as part of any FullClarity SuiteApp install. No other FullClarity SuiteApps need to be installed first. ## Installing the SuiteApp Install Portal via the SuiteApp Control Centre. The deployment process installs all files and objects contained in the SuiteApp. After install, register the account with FullClarity's cloud infrastructure (see below) before installing any other FullClarity SuiteApps — they will not function until Portal is registered. ## Permissions ### For administrators To register the account with FullClarity, you need either the **Administrator** role or the **FC Portal Admin** role assigned to your user account. ### For end users Portal is infrastructure — end users do not interact with Portal screens directly. No additional permissions need to be set for the SuiteApp to function. ## Register the account Each NetSuite account needs to register once with the FullClarity Portal. The registration step is short but must be done by a NetSuite administrator. See [Register a NetSuite account](./how-to/register-an-account). ::: tip You must repeat the registration step against each sandbox account, after every sandbox refresh. NetSuite deletes all access keys during a sandbox refresh, so previously-registered credentials stop working. See [Refresh API credentials](./how-to/refresh-api-credentials). ::: ## Create a configuration record After registration completes, create a Portal Configuration record. In a single-subsidiary account create one; in OneWorld accounts create one per subsidiary that will store files or use Portal-backed integrations. To create a configuration record: 1. Go to **Setup → FullClarity Portal → Portal Configuration → New**. 2. Choose the **Subsidiary** the configuration applies to. 3. Choose the **API URL** — usually `https://my.fullclarity.com/api`, which is preselected. 4. Choose the **Storage Region** — the AWS region your files will live in (USA is the default). 5. Save. Repeat for every subsidiary that needs Portal-backed functionality. You'll need to run this each time you create a new subsidiary. ## What success looks like * The Portal registration confirmation email arrives shortly after running the registration flow. * Opening **Setup → FullClarity Portal → Portal Configuration** shows one record per subsidiary. * Installing File Storage, Certified Documents, or any Portal-dependent SuiteApp succeeds and their cloud-backed features work immediately. ## Gotchas * **Sandbox refreshes wipe credentials.** Re-register each sandbox after every refresh. Until you do, file upload, vendor portal, and other Portal-backed features will fail in that sandbox. * **Subsidiary mismatch.** The Configuration record's chosen API URL and Storage Region apply to that subsidiary. If you create a new subsidiary in OneWorld, create a matching Configuration record before files are uploaded against the new subsidiary. * **Credentials from one account won't work in another.** Each NetSuite account (production, sandbox) needs to be registered separately. You can't copy credentials between accounts. ## Related * [Register a NetSuite account](./how-to/register-an-account) * [Refresh API credentials](./how-to/refresh-api-credentials) --- --- url: 'https://fullclarity.help/project-financials.md' --- # Project Financials Project Financials is the core SuiteApp of FullClarity, covering the full lifecycle of a construction project — from estimating and contracts through to billing, forecasting, subcontract management and revenue recognition. It turns NetSuite into a construction-project financial management system without forcing you out of NetSuite to do it. \[\[toc]] ## What you can do with Project Financials * **Estimating** — Build estimates with cost-centre-based work breakdown, import from spreadsheets, mark up to selling price, convert to a contract on award * **Contracts & billing** — Set up billing schedules (Stage, Progress, T\&M, Drawdown and more) and issue claims against them * **Cost centres** — A flexible work-breakdown that organises estimates, budgets, forecasts and revenue recognition the way your business works * **Subcontracts** — Manage subcontract awards, variations and progress claims (see [Subcontracts](/subcontracts)) * **Revenue recognition** — Configurable, minimum-click month-end revenue recognition for project-based businesses * **Variations** — Issue, approve and bill variations against any contract * **Purchase orders** — Generate POs from estimate lines and track committed cost against actual ## Who uses it * **Estimators** build and import estimates, mark up costs, and convert won bids into contracts * **Project managers** manage forecasts, raise variations, approve cost-centre adjustments * **Finance teams** issue progress claims, manage retainage, and run revenue recognition * **Administrators** configure billing types, cost-centre structures, default markups and permissions ## What's covered in these docs This section is being rebuilt to cover Project Financials end-to-end. So far: * ✅ [Install & configure](/project-financials/install-configure) * ✅ [Quick start](/project-financials/quick-start) * ✅ How to: * [Create a project](/project-financials/how-to/create-a-project) * [Create a plan](/project-financials/how-to/create-a-plan) — a reusable pricing template for one dwelling design * [Set up a development](/project-financials/how-to/set-up-a-development) — plans, lots, and creating a project per lot * [Customise terminology (rename records)](/project-financials/how-to/customise-terminology) * [Manage cost centres](/project-financials/how-to/manage-cost-centres) * [Managing phases](/project-financials/how-to/manage-phases) — phase sets and the phases in them * [Using phases on a project](/project-financials/how-to/use-phases) — grouping cost by delivery release * [Estimating](/project-financials/how-to/estimating/create-an-estimate) — create, add lines, import from spreadsheet, create POs * ✅ [Contracts & billing](/project-financials/contracts-billing) — set up billing schedules, issue progress claims, raise variations * ✅ [Revenue recognition](/project-financials/revenue-recognition) — month-end revrec setup, monthly batches, adjustments, capital project capitalisation * ✅ [Reference](/project-financials/reference) — configuration record fields, custom records, column glossary (permissions: rewrite in progress) * 🚧 FAQ — growing organically; for now, contact support@fullclarity.com ## Requires * A registered FullClarity Portal (see [Portal install & configure](/portal/install-configure)) * NetSuite Administrator role to install and configure --- --- url: 'https://fullclarity.help/project-financials/contracts-billing.md' --- # Contracts & billing Contracts & billing covers the customer-facing side of Project Financials — how you turn a won bid into a contract, structure it for billing, raise progress claims against it, and invoice your customer. \[\[toc]] ## What this covers A contract is a record on a project that represents the agreement with your customer. It holds the total contract value, the structure for how you'll bill against it, and the running history of every claim and variation raised. Once a contract is in place, you bill against it by raising **claims** — each claim covers one billing cycle (typically a month) and produces a NetSuite invoice when certified. This area covers everything from setting up the billing structure through to issuing claims and processing variations. ## Billing types Project Financials supports several billing types. Pick the one that matches how the contract was written: * **Stage billing** — payment at fixed milestones (e.g. 10% on deposit, 30% at slab, 40% at lock-up, 20% on completion). Each stage is a fixed percentage of the contract value. * **Progress billing** — % complete billing against a Schedule of Values. The most common pattern for commercial construction, including AIA G702/G703 jurisdictions. * **Time & material (T\&M)** — bill at cost (or cost + markup) based on actual purchase orders, vendor bills and time entries posted to the project. * **Drawdown billing** — for projects financed by a construction loan. Claims draw from a loan facility rather than billing the customer directly. * **Capital billing** — for projects that capitalise cost as a fixed asset rather than recognising revenue. Less-common variants — *Internal*, *Inventory*, *T\&M Cost Type* — exist for specific scenarios. Most customers use one of the five above. ## Contract structures Two ways to structure what gets claimed: * **Billing Stages** — used with Stage billing. A list of milestones with a percentage and date for each. Sum must equal 100%. * **Schedule of Values (SoV)** — used with Progress billing. A list of billable line items, each with a value, that you progressively claim against by % complete per line. Can be auto-generated from the linked estimate (Default) or hand-written (Custom). ## In this section * [Set up billing schedules](/project-financials/contracts-billing/set-up-billing-schedules) — create a contract, choose a billing type, build the Schedule of Values or Billing Stages * [Issue a progress claim](/project-financials/contracts-billing/issue-a-progress-claim) — claim against an active contract for a billing period * [Create a variation](/project-financials/contracts-billing/create-a-variation) — raise a change order against an existing contract * [Multi-project billing](/project-financials/contracts-billing/multi-project-billing) — bill a development of many lots as one community, from a single claim: either one consolidated invoice, or one invoice per lot ## Requires * Project Financials installed and configured — see [Install & configure](/project-financials/install-configure) * An active project with at least one approved estimate — see [Estimating](/project-financials/how-to/estimating/create-an-estimate) --- --- url: >- https://fullclarity.help/project-financials/contracts-billing/create-a-variation.md --- # Create a variation Raise a change order against an existing Main contract — a new Variation contract that adds to (or reduces) the parent's value and is claimable in its own right. \[\[toc]] ## When to use this When the customer agrees to a change of scope, value or cost against an existing approved contract. Variations are how Project Financials models change orders — they're separate Contract records linked back to the parent, not edits to the original. ## Prerequisites * An *Approved* Main contract on the project — you cannot raise a variation against a Draft contract * Internal sign-off that the variation will go ahead (Project Financials does not gate the variation against client-side approval — that's a procedural step you handle outside the system) * Permission to create and approve variations ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the parent Main contract. 2. Click **Add Variation**. A new Variation contract form opens, pre-linked to the parent. 3. Enter the variation amount, description, and any SoV / cost-line detail relevant to the change. 4. Save. The variation is created in *Draft* status, separate from the parent. 5. Submit the variation through its own approval workflow. 6. On approval, the parent contract's totals (Contract Amount, margin, projected sale) update automatically to include the variation. The variation is now claimable. ## What success looks like * A new *Variation*-type Contract record on the project, linked back to the parent Main contract. * The parent contract's *Variations* sublist shows the new variation. * The parent's Contract Amount has increased (or decreased, for a negative variation) by the variation amount. * Subsequent claims on the project can include claim lines drawn from the variation. ## Gotchas * **Variations are separate Contract records, not edits to the parent.** If you're searching for a single contract value that matches the original sale, you won't find the variations rolled in — look at the parent's calculated totals or sum the variations sublist. * **Rejected variations stay on the parent with status Rejected.** They aren't deleted automatically — leave them in place for audit history, or have an Administrator remove them if a clean slate is needed. * **Negative-value variations are supported** but reduce the parent contract value. Confirm with the customer before saving. * **You cannot raise a variation against a Draft contract.** The parent must be Approved first. If the change is happening before initial approval, edit the Draft contract directly. * **The variation has its own approval workflow.** It's distinct from the parent's — approving the parent doesn't approve open variations. * **There's no built-in cap on cumulative variations** against a contract. If your business needs a ceiling (e.g. "variations cannot exceed 15% of the original contract"), enforce it procedurally — the system won't block it. ## Related * [Set up billing schedules](./set-up-billing-schedules) * [Issue a progress claim](./issue-a-progress-claim) --- --- url: >- https://fullclarity.help/project-financials/contracts-billing/issue-a-progress-claim.md --- # Issue a progress claim Raise a claim against an approved contract for one billing period, then move it through the Submit → Certify → Invoice lifecycle. \[\[toc]] ## When to use this At the end of a billing period — typically monthly — once work has progressed against the contract. Each claim represents one billing cycle and produces one NetSuite invoice. ## Prerequisites * An *Approved* contract on the project — see [Set up billing schedules](./set-up-billing-schedules) * Sufficient progress to claim (claim amounts > $0) * The previous period's claim is at *Certified* or later (claims are sequential — you can't open two for the same SoV simultaneously) * Permission to create and certify claims (varies by role) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the contract record (or the project's *Project Financials* subtab) and click **Create Claim**. The claim worksheet that opens depends on the contract's billing type: * **Progress billing** — opens the Progress Claim Worksheet, one row per Schedule of Values line, with Opening % carried forward from the previous claim. * **Stage billing** — opens the Stage Claim Worksheet showing all Billing Stages; tick the stages being claimed this period. * **T\&M / Drawdown** — opens the T\&M Claim Worksheet listing billable purchase orders, vendor bills and time entries that haven't yet been claimed. 2. Enter the *Period* (a human-readable label like "April 2026") and the certification *Date*. 3. Populate the worksheet: * For Progress, enter the new *Closing %* per SoV line. The system calculates *This Period %* and *This Period Amount*. * For Stage, tick the stages to claim; amounts default from the stage percentage × contract value (overridable per row). * For T\&M, tick the transactions to include; margin and retention default from project settings. 4. Save the worksheet. A Claim record is created in *Draft* status. 5. **Submit** the claim for certification. The status moves to *Submitted*. 6. Once approved by the architect or client, **Certify** the claim. The certified amount is frozen. 7. **Create Invoice** — a NetSuite invoice is generated and the claim moves to *Invoiced*. ## What success looks like * A Claim record numbered `CL-nnn` in *Invoiced* status, linked to the source contract and the resulting NetSuite invoice. * The SoV's *Claimed to Date* running total has incremented by this claim's amount (Progress billing). * The claimed Billing Stages show *Claimed* = true with the claim link populated (Stage billing). * The project's *Billing* / *Claims* sublist shows the new claim. * Source transactions used by a T\&M claim are flagged as billed and won't reappear in the next claim's worksheet. ## Gotchas * **You can't over-bill a SoV line or a stage.** The system blocks claim amounts that exceed the line value or stage percentage. * **Certified claims are locked from edit.** If a certified claim needs to come back, use the *Withdraw* action — don't try to delete or re-edit. * **Period is a text field, not a date range.** Keep it human-readable ("April 2026") and use the *Date* field for the actual certification date. * **Retention is held back per claim line** when your contract or jurisdiction requires it. If the Retainage SuiteApp is installed, claim line retention flows through to the retainage AR side automatically. * **Print output depends on the linked PDF template.** Progress claims print the standard claim PDF by default; switch to the AIA G702/G732 template if your jurisdiction requires the AIA format. Stage claims use the standard claim PDF. * **Internal projects can't be claimed.** The Internal billing type has no worksheet — claims won't open. ## Related * [Set up billing schedules](./set-up-billing-schedules) * [Create a variation](./create-a-variation) * [Adjust a revrec entry](../revenue-recognition/adjust-a-revrec-entry) --- --- url: >- https://fullclarity.help/project-financials/contracts-billing/multi-project-billing.md --- # Multi-project billing Bill a large development made up of many individual lots as a single community — one consolidated claim and one invoice per run — while still tracking the contract and revenue for each lot separately. \[\[toc]] ## When to use this Use multi-project billing when you deliver one development as a **community of lots** — for example a residential estate, a multi-dwelling site, or a staged development — and you want to bill work across many lots **in one go** rather than claiming each lot separately. Each lot keeps its own contract and its own stage schedule, so you still see the numbers per lot. What changes is the billing step: instead of claiming each lot on its own, you claim the whole community from a single worksheet. You then choose what that claim produces — **one invoice for the whole community**, or **one invoice per lot**. Both are billed from the same worksheet in the same way; see [Choosing how the community is invoiced](#choosing-how-the-community-is-invoiced). Multi-project billing uses **stage billing** for the lots — each lot is billed at fixed milestones (Deposit, Base, Frame, Lock-up, Completion, and so on). If you need % complete billing against a schedule of values, use [progress claims](./issue-a-progress-claim) instead. ## Prerequisites * Project Financials installed and configured — see [Install & configure](/project-financials/install-configure) * A **development** set up, with a plan per design and the lots generated — see [Set up a development](../how-to/set-up-a-development) * A **head project** for the development, with that development selected on it * An estimate on each plan, so lot contract values can be calculated — see [Create a plan](../how-to/create-a-plan) * The community's **billing stages** agreed — the set of milestones and the percentage of each lot billed at each one * Permission to create contracts and claims (varies by role) * Optional: a **phase set** on the head project, if you want the community's cost grouped by release — see [Phases across a community](#phases-across-a-community) You do **not** need the lot projects to exist yet. Creating them is a step below. ## How a community fits together A multi-project community has three layers: * **The head project** is the development as a whole. It carries the switch that turns on multi-project billing, and it holds the community's single consolidated view. * **Each lot** is a sub-project beneath the head. A lot has its own contract and its own billing stages, so its value and revenue are tracked individually. * **The community contract** is created automatically on the head project. It is the thing you bill against — every approved lot rolls up into it, and it produces the one consolidated claim and invoice. Behind the community contract sits a **single consolidated sales order**. Approving a lot adds that lot's stage lines to it, tagged with the lot, the stage and the lot's contract. It's the sales order the claim worksheet reads and the one the consolidated invoice is produced from, so you'll see one order for the whole community rather than one per lot. ::: tip Terminology This page uses the default names — Development, Plan, Lot, Claim. All of these are renameable, so your buttons may read **Create Unit Projects** or **Create Invoice** instead. See [Customise terminology](/project-financials/how-to/customise-terminology/). ::: ## Setting up a community 1. Open the **head project** for the development. 2. Turn on **Multi-project billing** on the project. 3. Save. The system creates the community's consolidated contract for you and links it to the head project. At this point the community contract exists but has no value yet — value arrives as you add and approve lots. 4. Set up the community's **billing stages** on the head project — the milestones every lot will bill against, with the percentage of each lot's value billed at each one. Percentages must total 100%. ## Adding lots to the community 1. Make sure your **development** has its plans and lots set up, and that each plan has an estimate — see [Set up a development](../how-to/set-up-a-development). 2. On the head project, click **Create Lot Projects**, tick the lots you want, and tick **Create Contracts?**. Click **Create**. 3. Each selected lot gets its own project, with the plan's estimate copied onto it and **its own contract** sharing the community's billing stages. You don't set the stages up per lot — they're copied down from the community so every lot bills against the same milestone structure. 4. Each lot's contract value is calculated from that lot's estimate **plus its markup**, then spread across the shared stages by their percentages. You can create lot projects in batches, stage by stage as the site is released, rather than all at once. > A lot in a community bills through the community, so it does not get its own separate **Create Proposal** or **Generate Sales Order** step — that's expected. The lot joins the community when you approve it (next). ## Approving a lot to join the community Approving a lot's contract is what **joins** it to the community. 1. Open the lot's contract. Because it's part of a community, it shows a single **Approve** button — unless the community is set to invoice **per lot**, in which case it shows **Generate Sales Order** first. 2. **With per-lot invoicing only:** click **Generate Sales Order**. This raises the lot's own sales order, which is what its invoices will be billed from. 3. Click **Approve**. The lot joins the community: its stage values roll up into the community contract and its estimate folds into the community's consolidated figures. With the consolidated default, its stage lines are also added to the community's single sales order. 4. Repeat for each lot as it's ready. Approving more lots adds them to the **same** community — the community's stage totals are always the sum of every approved lot. A lot is only marked Approved if the join succeeds, so a lot showing as Approved has definitely joined. ## Changing the stages after lots exist You can edit the community's billing stages at any time, and the change flows down. Editing a stage on the head project — its percentage, description or order — re-pushes the whole stage template to **every** lot. Each lot's stage amounts are re-allocated to the new percentages, and for lots already approved the consolidated sales order and its figures update to match. **Stages that have already been claimed or billed are preserved.** Re-allocation applies to the stages still ahead of you, so reshaping a schedule mid-project won't disturb what you've already invoiced. This is the mechanism to use when the community's milestone structure changes — reallocating a percentage between two stages, for instance. Change it once on the head and every lot follows. Don't edit stages lot by lot. ## Billing the community When milestones have been reached across the community, you bill them all from one place. 1. From the head project, click **Create Claim**. On a community head this opens the multi-project worksheet rather than the standard single-project claim screen — the head project only offers the one button. 2. The worksheet shows **one row per lot**, with **a column for each billing stage**. Each cell shows the amount for that lot at that stage, and whether it has already been claimed. 3. **Tick the lot/stage cells you want to bill** in this run. You can mix and match — for example, Deposit on every lot, plus Frame on the two lots that have reached it. Row totals, stage column totals and the overall total update as you select. 4. Set the claim **Date**, and choose **Terms** — the **Due Date** is worked out for you from the terms and the claim date. You can override it if you need to. 5. Click **Save**. The system records the claim and marks those lot/stage cells as billed. What it invoices depends on how the community is set up to be invoiced — see [Choosing how the community is invoiced](#choosing-how-the-community-is-invoiced) below. By default it produces **one consolidated invoice** for everything you ticked, and the invoice lines carry the lot, the stage and the contract, so revenue stays attributable per lot even though the customer received a single invoice. **The invoices are produced in the background.** When you save, you're told the claim has been accepted, and you land on the claim itself — the invoices appear a few moments later, not instantly. The claim shows an **Invoice Build Status** which reaches **Complete** once every invoice has been raised, and its notes list the invoices it produced. If it stops part-way it says so and names the reason, keeps any invoices already raised, and can be submitted again without billing anything twice. ## Choosing how the community is invoiced A community can be invoiced in one of two ways. The choice is made on the head project, using the **Consolidated Multi-Project Invoicing** setting, and it applies to the whole community. | | Ticked — one invoice for the community *(default)* | Unticked — one invoice per lot | |---|---|---| | What a claim produces | a single invoice covering every lot you ticked | one invoice per lot, made out to that lot | | Releasing a lot | **Approve** | **Generate Sales Order**, then **Approve** | | Best for | one bill to the customer per run | reporting revenue and profitability per lot using standard reports | **Why you'd choose one invoice per lot.** Standard revenue and profitability reporting attributes income to the customer named on the **invoice itself**. If you need each lot's revenue reported individually using standard reports, each lot needs its own invoice. You still raise **one claim** either way, across as many lots and stages as you like, and the claim screen looks and works the same. Everything else is unchanged: each lot keeps its own contract and stage schedule, and the community still rolls up its lots' values. ::: warning Choose before billing starts The setting **cannot be changed once any part of the community has started billing** — the same work would become billable on two different sales orders at once. If you try, you're told so the moment you change the tick, and the tick goes back to what it was. Nothing is saved. The same change is refused if you make it from a list view rather than the project itself. Set it when you create the community, before the first contract is approved. To compare the two ways of working, set up **two communities** rather than switching one back and forth. ::: ::: tip Releasing a lot takes one extra click in per-lot mode With per-lot invoicing each lot raises its own sales order, so you click **Generate Sales Order** and then **Approve**. With the consolidated default you only click **Approve**. The extra step is expected — it isn't a sign that something has gone wrong. ::: ## Billing across multiple runs You bill a community progressively, the same way you'd bill stages over the life of a normal stage-billing job — just across many lots at once. * A cell that has **already been billed is locked** — its selector is removed so the same lot/stage can't be billed twice. * In each later run you simply tick the newly reached lot/stage cells and save, producing one more consolidated invoice for that run. * You can **add and approve a new lot after billing has started**. It joins the community and its stages appear as billable cells, without disturbing anything already invoiced. ## Reviewing the community's estimates Each lot keeps its own estimates, and the community contract gathers them. Approving a lot folds that lot's estimates into the community's consolidated collection, so the collection is always the union of every **approved** lot's estimates — a lot that hasn't been approved yet isn't in it. Editing stays where the estimate lives: you change a lot's numbers on that lot, and the consolidated view reflects it. Two places show the gathered picture: * **The community's estimate collection** — the consolidated collection on the community contract. Its worksheet groups by lot, then by cost category, then by line, and it is the view that supports [phase grouping](#phases-across-a-community). * **Multi-Project Estimate Collection**, a button on the head project. A read-only roll-up across the lots, giving the whole development's cost and revenue picture in one place rather than opening each lot in turn. This view groups by lot and does **not** group by phase. ## Phases across a community A **phase** is a delivery grouping — the release or block of units a cost belongs to. Because a community is delivered in releases, phases and multi-project billing are usually used together: billing stages say *when* a lot is billed, phases say *which release* a lot's cost belongs to. The two are independent, and a community can use both at once. See [Using phases on a project](../how-to/use-phases) for phases generally. ### Setting a community up for phases 1. Create a **phase set** with the community's releases in it — see [Managing phases](../how-to/manage-phases). 2. Nominate that set on the **head project**: tick **Use Phases** and select the **Phase Set**. (If the development carries a phase set, the head project takes its configuration from the development and these two fields are locked.) 3. Lots created from that head inherit its **Use Phases** setting and **Phase Set** automatically, so the whole community shares one phase vocabulary. A lot must use its head project's phase set — a mismatch is refused on save. And once lots exist on a set, the head's set can't be changed until they're moved off it. Both rules, and the way out of the second one, are covered in [Using phases on a project](../how-to/use-phases#rules-that-keep-a-communitys-phases-consistent). ### Putting a batch of lots into a phase When the head project uses phases, the **Create Lot Projects** popup gains a **Phase** field in its header and a **Phase** column on each lot line. Set the header once to put the whole selection into a release — the point being that ten lots into phase 3 is one choice, not ten. A phase set on an individual line always wins over the header. Each lot created with a phase gets it in three places: on every estimate line copied from the plan, on the lot project's own **Phase** field, and — through the shared phase set — in the community's grouping. The lot project's Phase field is what makes "every lot in phase 3" a single search. ### How phases group the consolidated collection On the community's estimate collection worksheet, **Phase is the outermost grouping**: phase, then lot, then cost category, then lines. So a phase folds up to the total for that release across every lot in it. **A lot sits wholly under one phase.** Where all of a lot's estimate lines agree on a phase, the lot appears under that phase with everything beneath it. Where a lot's lines disagree — some on one phase, some on another — the whole lot appears under **`(No phase)`** rather than being split across phases. That's deliberate: it makes the inconsistency visible so you can correct it, instead of quietly filing one lot in two places. A lot whose lines carry no phase at all also appears under `(No phase)`. Grand totals are unaffected by phase grouping — it changes how the rows are arranged, never what they add up to. ### What phases don't do on a community * **The consolidated sales order lines don't carry a phase.** They carry the lot, the billing stage and the lot's contract, which is what the consolidated claim needs. Report revenue by phase from the lot projects' own Phase field rather than from the sales order. * **Consolidated claims and invoices are not phase-aware.** You bill by lot and stage, exactly as described above. There is no per-phase claim. * **The head project's Multi-Project Estimate Collection view doesn't group by phase** — use the community's estimate collection worksheet for that. ## What success looks like * Turning on multi-project billing creates the community contract on the head project. * Each lot has its own project and contract sharing the community's billing stages, with a value derived from its estimate plus markup. * Approving a lot rolls its stage values into the community; the community's stage totals equal the sum of all approved lots. * Sales orders exist for the community: **one consolidated order** carrying a line per approved lot and stage, or — with per-lot invoicing — **one order per lot**. * The multi-project claim worksheet lists every lot with a column per stage, and all un-billed cells are selectable. * Choosing Terms populates the Due Date. * Saving a claim tells you it has been accepted, and the claim's **Invoice Build Status** reaches **Complete** a few moments later. * The claim then shows the invoices it produced — **one** for the whole selection, or **one per lot** if the community is set up that way, each made out to its lot — and those cells become locked against re-billing. * The community's claimed-to-date updates to match the invoices raised, without anyone running anything. * Editing a head stage percentage re-allocates every lot's amounts while leaving already-billed stages alone. ## Gotchas * **Multi-project billing is a stage-billing model.** Lots are billed at milestones. If you need % complete against a schedule of values, use progress billing instead. * **A lot joins the community when it's approved — not before.** An unapproved lot won't appear on the consolidated claim worksheet. * **With the consolidated default, neither the lots nor the community contract get proposal / sales-order buttons.** This is intentional. The lots bill through the community, and the community's sales order is built by approving lots rather than generated by hand — so **Create Proposal** and **Generate Sales Order** are hidden on both. Their absence isn't a fault. With **per-lot invoicing** the lots *do* get **Generate Sales Order**, because each lot raises its own — see [Choosing how the community is invoiced](#choosing-how-the-community-is-invoiced). * **Claims are prepared in the background.** Saving a claim doesn't put the invoices on screen straight away — you're told the claim was accepted, and the invoices follow moments later. Watch the claim's **Invoice Build Status** reach **Complete**. A claim that's still building is not a claim that failed. * **The consolidated invoicing setting can't be changed once billing has started.** The refusal is deliberate: the same work would otherwise be billable on two sales orders at once. Decide when you create the community. * **With per-lot invoicing, the community's own contract stays open and has no sales order.** It's the roll-up for the community's values; the billing happens on the lots. **Create Variation** is raised on the lot whose scope changed, not on the community. * **Already-billed cells are locked.** To reverse a billed lot/stage, raise a credit/adjustment — don't try to un-tick it. * **Approve the community's lots from the lot contracts, not the head.** The head project's community contract is the consolidated roll-up; you drive approvals from each lot. * **Change stages on the head, not on a lot.** Editing the head re-pushes the template to every lot. Editing a single lot's stages puts it out of step with the community, and the next head-side edit will overwrite it. * **Build each plan's estimate before creating lot projects.** The estimate is what sets the lot's contract value. Lots created from an unpriced plan come through with no value to bill — see [Create a plan](../how-to/create-a-plan). * **Lot creation runs in the background beyond a couple of lots.** You'll get a "queued" confirmation rather than immediate results — refresh the development to watch the lot projects appear. * **Give the head project and its lots the same cost centre set.** The consolidated estimate collection builds its category structure from the **head project's** cost centre. If the lots use a different set, none of the lots' categories are recognised — the collection lists the lines with the Category (and Phase) columns blank and no grouping rows at all. Align the head's cost centre with its lots' and the view groups correctly. * **Set the head project's phase set before you create the lots.** Lots take their phase configuration from the head at creation. Turning phases on at the head afterwards doesn't retro-fit the lots that already exist. * **Copying an estimate into a lot by hand doesn't bring its line phases.** Creating lot projects does write the phase you nominated; a manual estimate import doesn't, so re-phase those lines afterwards. ## Related * [Set up a development](../how-to/set-up-a-development) — the developments, plans and lots a community is built from * [Create a plan](../how-to/create-a-plan) — the pricing template, and the estimate, behind each lot's contract value * [Set up billing schedules](./set-up-billing-schedules) — the stage-billing structure a community is built on * [Using phases on a project](../how-to/use-phases) — grouping a community's cost by release * [Managing phases](../how-to/manage-phases) — creating the phase set a community shares * [Issue a progress claim](./issue-a-progress-claim) — single-project claiming (progress, stage, T\&M) * [Create a variation](./create-a-variation) * [Customise terminology](/project-financials/how-to/customise-terminology/) --- --- url: >- https://fullclarity.help/project-financials/contracts-billing/set-up-billing-schedules.md --- # Set up billing schedules Create a contract on a project, choose its billing type, and populate either a Schedule of Values or a list of Billing Stages so you can claim against it. \[\[toc]] ## When to use this After a project is created and the estimate is approved, before any claim can be raised. This is a one-time setup per contract — once a Main contract is Approved, structural changes go through a Variation rather than an edit. ## Prerequisites * Project Financials installed and configured — see [Install & configure](../install-configure) * An active project with the correct *Billing Type* set on the project record * An approved estimate on the project (for Progress billing with a Default Schedule of Values) — or the list of stages / line items ready to enter manually * Permission to create contracts on the project ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the project record. 2. On the *Project Financials* subtab, click **Create Contract**. 3. The contract form opens with header fields pre-populated from the project — confirm the *Billing Type* matches the contract. The billing type drives which structure (Billing Stages or Schedule of Values) you'll populate below. 4. Build the billing structure: * **Stage billing** — enter each milestone as a Billing Stage row with a description, percentage and expected date. Stage percentages must add to 100%. * **Progress billing — Default SoV** — confirm the auto-generated Schedule of Values that mirrors the approved estimate's line items. * **Progress billing — Custom SoV** — add SoV rows manually, each with a description, value, and (optionally) a quantity and unit. * **T\&M, Drawdown, Capital** — there's no upfront billing schedule; you'll claim directly off transactions or the capitalisation worksheet when the time comes. 5. Save. The contract is created in *Draft* status. 6. Submit the contract for approval when it's ready. Once Approved, the contract is locked from edit. ## What success looks like * A Contract record on the project in *Draft* status, with the Billing Type and contract amount populated. * The project's *Contracts* sublist shows the new contract. * For Stage billing — the Billing Stages sublist totals to 100%. * For Progress billing — the Schedule of Values sublist totals to the contract amount. * Once submitted and approved, the contract status moves to *Approved* and the *Create Claim* action becomes available. ## Gotchas * **Billing Stages must total 100%.** Save will reject otherwise — the running total is visible at the bottom of the stages sublist. * **Default vs Custom SoV.** Default auto-syncs from the linked estimate — edit the estimate to change the SoV. Custom is hand-edited and ignores the estimate. You pick this once at contract creation; switching later is not supported. * **Changing the project's billing type after a contract exists does NOT retro-update the contract.** The contract holds its own billing type snapshot. If you've created the contract under the wrong billing type, cancel it and start again rather than editing the project setting. * **Approved contracts are locked.** You cannot edit an approved contract directly in the UI. Any change of scope or value goes through a [Variation](./create-a-variation). * **A SoV line cannot be deleted (or its value reduced below the claimed-to-date amount)** once claims have been raised against it. The system blocks this to prevent retroactive over-billing. ## Related * [Issue a progress claim](./issue-a-progress-claim) * [Create a variation](./create-a-variation) * [Estimating — Create an estimate](../how-to/estimating/create-an-estimate) * [Install & configure](../install-configure) --- --- url: 'https://fullclarity.help/project-financials/how-to/create-a-plan.md' --- # Create a plan Build a reusable pricing and cost template for one dwelling design, estimate it once, and reuse it across every lot built to that design. \[\[toc]] ## When to use this Create a plan for each **design** you build repeatedly — "4 bed double storey", "Townhouse type B", "Villa 14". The plan holds what that design costs and what it sells for, and carries the estimate that prices it. The point of a plan is that the estimating work happens once. When you create lot projects from a [development](./set-up-a-development), each lot gets a copy of its plan's estimate rather than being estimated from scratch. Ten lots built to the same design means one plan, one estimate, ten priced projects. A plan is a standalone record. It isn't owned by a development — you attach it to one (or several) once it exists, so the same design can be offered across more than one site. ::: tip Your site may call this something else Plan is renameable, along with Development and Lot. If your configuration calls them Designs, that's what the record and buttons will say. This page uses the default names. See [Customise terminology](./customise-terminology/). ::: ## Prerequisites * Project Financials installed and configured — see [Install & configure](../install-configure) * A **cost centre** for the plan to estimate against — see [Manage cost centres](./manage-cost-centres) * On OneWorld accounts, the **subsidiary** (or subsidiaries) the plan applies to * The design's cost and sale price * Permission to create estimates ## Walkthrough ### 1. Create the plan record 1. Go to **FullClarity → Project Financials → Plans** and click **New**. 2. Complete the header: * **Description** — what the design is. This is what you'll pick from when assigning plans to lots, so make it recognisable. * **Cost Centre** — the cost structure the plan's estimate is built against. Set this before you go any further; the estimate buttons depend on it. * **Subsidiary** — on OneWorld, which subsidiaries the plan is available to. This is mandatory. * **Cost Amount** and **Sale Price** — the standard cost and selling price for the design. * **Price Range (low / high)** — the range the design is expected to sell within, where the price varies by lot. 3. **Save.** ::: warning Save before you go looking for the buttons The **Create Estimate**, **Import Estimate**, **Update SOV** and **Create Opportunity** buttons only appear when you're *viewing* a saved plan — they're not on the edit form. If you can't see them, save and look again. ::: ### 2. Add the estimate This is the step that makes the plan able to price a lot. On the saved plan, use the **Estimates** sublist: * **Create Estimate** — build the design's estimate from scratch against the plan's cost centre. See [Create an estimate](./estimating/create-an-estimate). * **Import Estimate** — bring the estimate in from a spreadsheet instead. See [Import from spreadsheet](./estimating/import-from-spreadsheet). If the design needs to be priced across several estimates rather than one, use the **Estimate Collections** sublist instead — it has its own **Create Estimate Collection** and **Import Estimate Collection** buttons. ::: warning Use the FullClarity buttons, not the standard New button The native **New** buttons on the Estimates and Estimate Collections sublists are deliberately hidden. An estimate has to be created through the plan's own buttons so it's built against the right cost centre and linked back to the plan. If you create one another way it won't be picked up. ::: ### 3. Optional extras * **Attach the drawings.** Use the plan's **Files** to hold the design's drawings and documents. They carry through to every lot built to the plan, so the site team isn't hunting for them per lot. * **Update SOV.** Opens the plan's Schedule of Values so you can review or adjust how the design's value is broken down. * **Assign Sale Item.** Sets the sales item the plan's estimate lines bill against. This button only appears if your configuration has it enabled — if you don't see it, your account bills against the default item and there's nothing to set. * **Create Opportunity.** Raises an opportunity straight from the plan, for pipeline work on a design before a lot is committed. ### 4. Attach the plan to a development A plan does nothing on its own — a development has to offer it. 1. Open the **development** for the site. 2. In its **Plans** field, select this plan. It's a multi-select, so a development can offer several designs — and the same plan can be selected onto more than one development. 3. Save. The plan is now available to assign to lots on that site. See [Set up a development](./set-up-a-development). ## What success looks like * The plan appears in **FullClarity → Project Financials → Plans** with its description, cost centre and pricing populated. * Viewing the plan shows an estimate on its **Estimates** sublist (or a collection on **Estimate Collections**). * The plan is selected in the **Plans** field of at least one development. * Assigning the plan to a lot and creating that lot's project produces a project whose estimate carries the plan's figures. ## Gotchas * **A plan without an estimate can't price a lot.** The Cost Amount and Sale Price fields describe the design, but what's copied onto each lot project is the plan's **estimate**. A plan with pricing but no estimate produces unpriced lot projects, and the fix is estimating each lot individually — exactly what plans exist to avoid. * **Set the cost centre before creating the estimate.** The estimate is built against it. Changing the cost centre after the estimate exists doesn't rebuild it. * **The action buttons are view-mode only.** Save the plan first. * **Don't use the sublists' standard New button** — it's hidden for a reason. Use **Create Estimate** / **Import Estimate**. * **Subsidiary is mandatory on OneWorld accounts,** and it's a multi-select. A plan is only usable on the subsidiaries selected here. * **Editing a plan does not re-price lot projects already created from it.** The estimate is copied at lot-project creation, not kept in sync. If a design's pricing changes, existing lot projects keep their original figures and need amending individually — so get the plan right before creating lot projects in bulk. * **Plans are attached from the development, not the other way round.** There's no "development" field on the plan. If a plan isn't showing up when you assign designs to lots, check the development's **Plans** field. ## Related * [Set up a development](./set-up-a-development) — developments, lots, and creating a project per lot * [Create an estimate](./estimating/create-an-estimate) — building the estimate a plan needs * [Import from spreadsheet](./estimating/import-from-spreadsheet) * [Manage cost centres](./manage-cost-centres) * [Multi-project billing](../contracts-billing/multi-project-billing) — billing a development's lots as one community * [Customise terminology](./customise-terminology/) --- --- url: 'https://fullclarity.help/project-financials/how-to/create-a-project.md' --- # Creating a project \[\[toc]] A project is the central record in FullClarity. Creating one sets up everything you need to start estimating, contracting, and billing — including the customer, a contact, and a sales opportunity, all in a single step. **Where to find it:** FullClarity → Project Financials → Create Project ## When to use this Use this when you are onboarding a new construction job into FullClarity. Whether you're starting a relationship with a brand-new client or adding a new project for an existing one, this is your starting point before any estimating, contracting, or billing can begin. ## Prerequisites * Access to the FullClarity Project Financials menu * The customer's company name (or the existing customer record if your administrator has disabled new customer creation) * A contact person's name and email (for Company-type customers) * The appropriate billing type and cost centre for the project (check with your administrator if unsure) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## New customer or existing customer At the top of the form you'll see an **Existing Customer** checkbox. Whether you can create a new customer or must select an existing one depends on how your administrator has configured the system. **If new customer creation is enabled:** The Existing Customer checkbox is interactive — you can choose. When it's **unchecked** (the default), the form collects details to create a new customer record: * **Company / Individual** — choose whether the customer is a business or a person: * **Company** — creates a customer record for a business. You'll enter a company name, and optionally a primary contact person's first name, last name, and email. A separate contact record is created as part of the project setup. * **Individual** — creates a customer record for a person. You'll enter their first and last name directly. No separate contact record is created. * **Company Name** (required for Company type) — the customer's business name * **First Name** and **Last Name** — for Company type, this is the primary contact person. For Individual type, this is the customer's own name. * **Email** (required) — used for project correspondence * **Phone** and **Alt. Phone** — contact numbers When it's **checked**, all of the above fields are replaced with a single **Customer** dropdown where you select an existing customer from NetSuite. This is useful when you're adding a new project for a client you already work with — no duplicate customer records are created. **If new customer creation is disabled:** The Existing Customer checkbox is automatically ticked and cannot be changed. You must select an existing customer from the dropdown. ## Project details The rest of the form configures how the project will operate. Your administrator sets the defaults for these fields in the Configuration record, so in most cases you'll only need to change what's specific to this project. * **Job Name** — a descriptive name for the project (e.g. "CBD Office Fitout" or "Warehouse Construction - Dandenong") * **Billing Type** — determines how you'll bill the customer. The two most common types are: * **Progress Billing** — you agree a Schedule of Values with the customer, then bill monthly based on percentage completion of each line item * **Stage Billing** — billing is tied to construction milestones (e.g. Deposit, Base, Frame, Lockup). Each stage has a fixed percentage of the contract value. This is common in Australian residential construction where stage percentages may be regulated. See "Stage billing projects" below for more detail. * **Cost Centre** — selects which cost category structure applies to this project. This controls which budget categories are available when building estimates. * **Default Margin %** — the target profit margin used as a default on estimate lines. Typically set to 25%. * **Start Date** — defaults to today's date * **Subsidiary** — the NetSuite subsidiary that owns the project * **Advanced Forecasting** — when this checkbox appears on the form, it enables advanced forecast features on the project (extending the estimating workflow to include a separate Project Budget and Forecast). It defaults to checked, but you can uncheck it if you don't need advanced forecasting for this particular project. Note: if your administrator has disabled advanced forecasting in the system settings, this checkbox won't appear at all. ## What gets created When you save the form, FullClarity creates several linked records behind the scenes: * A **Customer** record (or links to the existing one you selected) * A **Contact** for the customer's primary contact person (Company customers only — not created for Individual customers) * The **Project** itself (created as a child of the customer) * An **Opportunity** for pipeline tracking Which of these are created automatically is controlled by your administrator in the Configuration record. For example, contact creation can be disabled if your organisation manages contacts separately, and new customer creation can be disabled to ensure all projects are linked to pre-existing customer records. ## Stage billing projects If you select **Stage Billing** as the billing type, FullClarity automatically copies the default billing stages to the project when it's created. Typical default stages for Australian residential construction are: * A. Deposit — 5% * B. Base — 10% * C. Frame — 20% * D. Lockup — 35% * E. Fix — 25% * F. Completion — 5% These stages always total 100% of the contract value. After the project is created, you can customise the stages on the project's **Configuration > Billing Stage** tab — adding, removing, or adjusting percentages to suit the specific contract, as long as the total remains 100%. Your administrator manages the available stages and their defaults via FullClarity → Project Financials → Manage Stages. ## Phases on a project Phases group a project's cost by delivery release rather than by trade. They're set on the project record after it's created, on the **Configuration** subtab, not on this form: * **Use Phases** — shows the **Phase** column on this project's estimating worksheets. It's ticked automatically on new projects when your administrator has turned on the **Enable Phases** preference, and you can tick it on any individual project whether that preference is on or not. * **Phase Set** (required when Use Phases is ticked) — which set of phases this project uses. * **Phase** — optional. The phase this project itself belongs to, useful for searching and reporting across a group of projects. If the project has a **development** selected on it, these fields are filled in from the development and locked. Phases are optional and additive: a project that doesn't use them behaves exactly as it always has. See [Using phases on a project](./use-phases). ## What success looks like You land on the newly created project record. The **FullClarity** subtab shows an overview of billing information and financial summary. The **Estimating** subtab is ready for you to create your first estimate. If you selected Stage Billing, the billing stages appear on the **Configuration > Billing Stage** tab. ## After saving Once the project is saved, you'll land on the project record. The key areas you'll use are: * **FullClarity** subtab — an overview of billing information and financial summary * **Estimating** subtab — where you create estimates, manage estimate collections, handle bid requests, and set up contracts. This is where you'll go next to create your first estimate. * **Configuration** subtab — project-level settings including cost centre, margin, account assignments, and billing stages (for Stage Billing projects) Other subtabs cover areas like addresses, relationships, resources, communication, retainage, and timeline — these become relevant as the project progresses through its lifecycle. ## Gotchas * **Existing Customer checkbox is greyed out?** Your administrator has disabled new customer creation. You must select an existing customer record from the dropdown. * **Advanced Forecasting checkbox not visible?** It has been disabled system-wide by your administrator. The project will use standard (non-advanced) forecasting. * **Stage percentages must total exactly 100%.** If you customise stages after creation, the system will prevent saving until the total is correct. * **Contact is not created for Individual customers.** If you need a separate contact record for an individual, you'll need to create it manually in NetSuite. * **Can't save a project with Use Phases ticked?** A project using phases must also nominate a **Phase Set**. Either select one or untick Use Phases — see [Using phases on a project](./use-phases). --- --- url: 'https://fullclarity.help/project-financials/how-to/customise-terminology.md' --- # Customise terminology (rename records) \[\[toc]] Every construction business has its own language. What one company calls an "Estimate", another calls a "Budget" or "Tender". FullClarity lets you rename the key terms used throughout the system so that it matches the way your team already works. **Who can do this:** NetSuite administrators only. **Where to find it:** FullClarity → Project Financials → Rename Records ## When to use this Use this during initial system setup, or any time your business adopts different terminology for core records. Changes apply system-wide, so plan and agree on your preferred terms before making them. ## Prerequisites * NetSuite administrator access * Agreement across your team on the new terminology before making changes ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Renaming record types The main section of the Rename Records page controls the names of core records used across FullClarity. For example, you could rename "Estimate" to "Tender", "Contract" to "Agreement", or "Claim" to "Progress Claim". Changes apply system-wide — every menu, label, and reference throughout FullClarity will update to use your new terminology. The available record names are: * **Estimate** and **Estimate Collection** — the primary estimating records within a project * **Main Contract** and **Variation Contract** — contract and change order records * **Claim** — progress billing records, along with the **Claim Prefix** used to auto-generate reference numbers (e.g. CL-001, CL-002) * **Cost Centre** — cost code groupings * **Safety Checklist**, **Daily Log**, **Development**, **Plan**, and **Lot** — operational and tracking records All fields are required — you cannot leave any record name blank. ## Customising worksheet columns The Rename Records page also has four subtabs that control the column headings shown in each of FullClarity's worksheet views. For each column, you can change the **Label** to something more meaningful to your team. For example, you might rename "Amt" to "Amount" or "Net $" to "Net Value". On the Estimate, Budget, and Forecast tabs, you can also **hide** columns that aren't relevant to your business. Hidden columns are removed from the worksheet entirely — users cannot restore them on their own. Only an administrator can unhide a column by returning to this page and unchecking the Hide box. Revenue Recognition columns cannot be hidden, as all fields are considered essential for accounting compliance. See the full column reference for each worksheet: * [Estimate columns](/project-financials/how-to/customise-terminology/estimate-columns) (35 columns) * [Budget columns](/project-financials/how-to/customise-terminology/budget-columns) (47 columns) * [Forecast columns](/project-financials/how-to/customise-terminology/forecast-columns) (47 columns) * [Revenue recognition columns](/project-financials/how-to/customise-terminology/revenue-recognition-columns) (28 columns) ## What success looks like After saving, all menus, labels, and references throughout FullClarity immediately reflect your new terminology. Users logging in after the change will see the updated names without needing to refresh or clear their cache. ## Gotchas * **Plan before you rename.** Agree on your preferred terminology before making changes, since the new names appear everywhere in the system. * **Be careful hiding columns.** If you hide a column that a user relies on, they won't be able to see it until an administrator restores it here. * **Claim Prefix is used for numbering.** If you change it, future claims will use the new prefix, but existing claim references won't be retroactively updated. * **All record name fields are required.** You cannot save the page with any record name left blank. --- --- url: >- https://fullclarity.help/project-financials/how-to/customise-terminology/budget-columns.md --- # Budget columns The Budget Columns subtab on the Rename Records page controls the column headings shown in the Budget worksheet. You can change the **Label** for any column, and use the **Hide** checkbox to remove columns that aren't relevant to your business. The Budget worksheet includes all the columns from the Estimate worksheet plus additional columns for actuals tracking, completion percentages, commitments, and forecasting. Hidden columns are removed from the worksheet entirely. Only an administrator can restore them by unchecking Hide on this page. ## When to use this Use this reference when you want to rename or hide columns in the Budget worksheet. See [Customise terminology (rename records)](/project-financials/how-to/customise-terminology) for the overall workflow. ## Prerequisites * NetSuite administrator access * The Rename Records page open in FullClarity (FullClarity → Project Financials → Rename Records → Budget Columns tab) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Column reference | # | Column name | Default label | Can hide | | --- | --- | --- | --- | | 1 | Actuals to Date | Actuals to Date | Yes | | 2 | Adjusted % Complete | Adjusted % Complete | Yes | | 3 | Adjusted % Override | Adjusted % Override | Yes | | 4 | Allowance Type | Allowance Type | Yes | | 5 | Amt | Amt | Yes | | 6 | Applied | Applied | Yes | | 7 | Asset Type | Asset Type | Yes | | 8 | Category | Category | Yes | | 9 | Commitments | Commitments | Yes | | 10 | Contingency $ | Contingency $ | Yes | | 11 | Contingency % | Contingency % | Yes | | 12 | Cost $ | Cost $ | Yes | | 13 | Cost Type | Cost Type | Yes | | 14 | Description | Description | Yes | | 15 | Escalation $ | Escalation $ | Yes | | 16 | Escalation % | Escalation % | Yes | | 17 | Estimated % Complete | Estimated % Complete | Yes | | 18 | Forecast Over / (Under) Budget | Forecast Over / (Under) Budget | Yes | | 19 | Forecasted Remaining Costs | Forecasted Remaining Costs | Yes | | 20 | Freight $ | Freight $ | Yes | | 21 | Freight % | Freight % | Yes | | 22 | Fund Type | Fund Type | Yes | | 23 | Gross Amount | Gross Amt | Yes | | 24 | Item Name | Item Name | Yes | | 25 | Line Ref | Line Ref | Yes | | 26 | Margin $ | Margin $ | Yes | | 27 | Margin % | Margin % | Yes | | 28 | Net $ | Net $ | Yes | | 29 | Notes | Notes | Yes | | 30 | Previous % Complete | Previous % Complete | Yes | | 31 | Purchase Order | Purchase Order | Yes | | 32 | Quantity | Quantity | Yes | | 33 | Quote | Quote | Yes | | 34 | Rate | Rate | Yes | | 35 | Sales Estimate Value | Sales Estimate Value | Yes | | 36 | Sales Tax $ | Sales Tax $ | Yes | | 37 | Sales Tax % | Sales Tax % | Yes | | 38 | Stage | Stage | Yes | | 39 | Supplier | Supplier | Yes | | 40 | Tax | Tax | Yes | | 41 | Tax Code | Tax Code | Yes | | 42 | Tax Rate | Tax Rate | Yes | | 43 | Total Committed Costs | Total Committed Costs | Yes | | 44 | Total Cost To Complete | Total Cost To Complete | Yes | | 45 | Total Other Costs | Total Other Costs | Yes | | 46 | Unit | Unit | Yes | | 47 | WP Location | WP Location | Yes | **Total: 47 columns** ## Columns unique to Budget The following columns appear in the Budget worksheet but not in the Estimate worksheet: Actuals to Date, Adjusted % Complete, Adjusted % Override, Commitments, Estimated % Complete, Forecast Over / (Under) Budget, Forecasted Remaining Costs, Line Ref, Previous % Complete, Sales Estimate Value, Total Committed Costs, and Total Cost To Complete. ## What success looks like After saving your changes, the Budget worksheet immediately reflects the new column labels. Any columns you've hidden are no longer visible to users in the worksheet. ## Gotchas * **Hidden columns are not deleted.** Data is preserved; the column is simply not shown. An administrator can restore it at any time. * **Sales Estimate Value is Budget-only.** This column does not appear in the Forecast worksheet. * **Hiding progress columns affects reporting.** Columns like Actuals to Date and Estimated % Complete are important for project health tracking — consult with your team before hiding them. --- --- url: >- https://fullclarity.help/project-financials/how-to/customise-terminology/estimate-columns.md --- # Estimate columns The Estimate Columns subtab on the Rename Records page controls the column headings shown in the Estimate worksheet. You can change the **Label** for any column, and use the **Hide** checkbox to remove columns that aren't relevant to your business. Hidden columns are removed from the worksheet entirely. Only an administrator can restore them by unchecking Hide on this page. ## When to use this Use this reference when you want to rename or hide columns in the Estimate worksheet. See [Customise terminology (rename records)](/project-financials/how-to/customise-terminology) for the overall workflow. ## Prerequisites * NetSuite administrator access * The Rename Records page open in FullClarity (FullClarity → Project Financials → Rename Records → Estimate Columns tab) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Column reference | # | Column name | Default label | Can hide | | --- | --- | --- | --- | | 1 | Allowance Type | Allowance Type | Yes | | 2 | Amt | Amt | Yes | | 3 | Applied | Applied | Yes | | 4 | Asset Type | Asset Type | Yes | | 5 | Category | Category | Yes | | 6 | Contingency $ | Contingency $ | Yes | | 7 | Contingency % | Contingency % | Yes | | 8 | Cost $ | Cost $ | Yes | | 9 | Cost Type | Cost Type | Yes | | 10 | Description | Description | Yes | | 11 | Escalation $ | Escalation $ | Yes | | 12 | Escalation % | Escalation % | Yes | | 13 | Freight $ | Freight $ | Yes | | 14 | Freight % | Freight % | Yes | | 15 | Fund Type | Fund Type | Yes | | 16 | Gross Amount | Gross Amt | Yes | | 17 | Item Name | Item Name | Yes | | 18 | Margin $ | Margin $ | Yes | | 19 | Margin % | Margin % | Yes | | 20 | Net $ | Net $ | Yes | | 21 | Notes | Notes | Yes | | 22 | Purchase Order | Purchase Order | Yes | | 23 | Quantity | Quantity | Yes | | 24 | Quote | Quote | Yes | | 25 | Rate | Rate | Yes | | 26 | Sales Tax $ | Sales Tax $ | Yes | | 27 | Sales Tax % | Sales Tax % | Yes | | 28 | Stage | Stage | Yes | | 29 | Supplier | Supplier | Yes | | 30 | Tax | Tax | Yes | | 31 | Tax Code | Tax Code | Yes | | 32 | Tax Rate | Tax Rate | Yes | | 33 | Total Other Costs | Total Other Costs | Yes | | 34 | Unit | Unit | Yes | | 35 | WP Location | WP Location | Yes | **Total: 35 columns** ## What success looks like After saving your changes, the Estimate worksheet immediately reflects the new column labels. Any columns you've hidden are no longer visible to users in the worksheet. ## Gotchas * **All 35 columns can be hidden.** Unlike Budget and Forecast, there are no mandatory visible columns in the Estimate worksheet — but hiding key columns like Category or Description will make the worksheet harder to use. * **Hidden columns are not deleted.** Data in hidden columns is preserved; the column is simply not shown. An administrator can restore it at any time. --- --- url: >- https://fullclarity.help/project-financials/how-to/customise-terminology/forecast-columns.md --- # Forecast columns The Forecast Columns subtab on the Rename Records page controls the column headings shown in the Forecast worksheet. You can change the **Label** for any column, and use the **Hide** checkbox to remove columns that aren't relevant to your business. The Forecast worksheet is very similar to the Budget worksheet, with two differences: it includes a **Project Budget Total Cost** column (not in Budget), it does not include **Sales Estimate Value** (which is Budget-only), and the **Rate** column defaults to the label "Forecast Rate" to distinguish it from the Budget rate. Hidden columns are removed from the worksheet entirely. Only an administrator can restore them by unchecking Hide on this page. ## When to use this Use this reference when you want to rename or hide columns in the Forecast worksheet. See [Customise terminology (rename records)](/project-financials/how-to/customise-terminology) for the overall workflow. ## Prerequisites * NetSuite administrator access * The Rename Records page open in FullClarity (FullClarity → Project Financials → Rename Records → Forecast Columns tab) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Column reference | # | Column name | Default label | Can hide | | --- | --- | --- | --- | | 1 | Actuals to Date | Actuals to Date | Yes | | 2 | Adjusted % Complete | Adjusted % Complete | Yes | | 3 | Adjusted % Override | Adjusted % Override | Yes | | 4 | Allowance Type | Allowance Type | Yes | | 5 | Amt | Amt | Yes | | 6 | Applied | Applied | Yes | | 7 | Asset Type | Asset Type | Yes | | 8 | Category | Category | Yes | | 9 | Commitments | Commitments | Yes | | 10 | Contingency $ | Contingency $ | Yes | | 11 | Contingency % | Contingency % | Yes | | 12 | Cost $ | Cost $ | Yes | | 13 | Cost Type | Cost Type | Yes | | 14 | Description | Description | Yes | | 15 | Escalation $ | Escalation $ | Yes | | 16 | Escalation % | Escalation % | Yes | | 17 | Estimated % Complete | Estimated % Complete | Yes | | 18 | Forecast Over / (Under) Budget | Forecast Over / (Under) Budget | Yes | | 19 | Forecasted Remaining Costs | Forecasted Remaining Costs | Yes | | 20 | Freight $ | Freight $ | Yes | | 21 | Freight % | Freight % | Yes | | 22 | Fund Type | Fund Type | Yes | | 23 | Gross Amount | Gross Amt | Yes | | 24 | Item Name | Item Name | Yes | | 25 | Line Ref | Line Ref | Yes | | 26 | Margin $ | Margin $ | Yes | | 27 | Margin % | Margin % | Yes | | 28 | Net $ | Net $ | Yes | | 29 | Notes | Notes | Yes | | 30 | Previous % Complete | Previous % Complete | Yes | | 31 | Project Budget Total Cost | Project Budget Total Cost | Yes | | 32 | Purchase Order | Purchase Order | Yes | | 33 | Quantity | Quantity | Yes | | 34 | Quote | Quote | Yes | | 35 | Rate | Forecast Rate | Yes | | 36 | Sales Tax $ | Sales Tax $ | Yes | | 37 | Sales Tax % | Sales Tax % | Yes | | 38 | Stage | Stage | Yes | | 39 | Supplier | Supplier | Yes | | 40 | Tax | Tax | Yes | | 41 | Tax Code | Tax Code | Yes | | 42 | Tax Rate | Tax Rate | Yes | | 43 | Total Committed Costs | Total Committed Costs | Yes | | 44 | Total Cost To Complete | Total Cost To Complete | Yes | | 45 | Total Other Costs | Total Other Costs | Yes | | 46 | Unit | Unit | Yes | | 47 | WP Location | WP Location | Yes | **Total: 47 columns** ## Differences from Budget * **Added:** Project Budget Total Cost (not in Budget) * **Removed:** Sales Estimate Value (present in Budget but not Forecast) * **Different default label:** Rate defaults to "Forecast Rate" instead of "Rate" ## What success looks like After saving your changes, the Forecast worksheet immediately reflects the new column labels. Any columns you've hidden are no longer visible to users in the worksheet. ## Gotchas * **Hidden columns are not deleted.** Data is preserved; the column is simply not shown. An administrator can restore it at any time. * **Project Budget Total Cost is Forecast-only.** This column does not appear in the Budget worksheet. * **The Rate column has a different default label here.** It defaults to "Forecast Rate" in the Forecast worksheet to distinguish it from the Budget rate — if you rename it, be consistent across both worksheets. --- --- url: >- https://fullclarity.help/project-financials/how-to/customise-terminology/revenue-recognition-columns.md --- # Revenue recognition columns The Revenue Recognition Columns subtab on the Rename Records page controls the column headings shown in the Revenue Recognition worksheet. You can change the **Label** for any column. Unlike the Estimate, Budget, and Forecast tabs, Revenue Recognition columns **cannot be hidden**. All columns are considered essential for accounting compliance. The column set is entirely different from the other three worksheets, focusing on revenue and cost recognition accounting rather than estimating and budgeting. ## When to use this Use this reference when you want to rename column headings in the Revenue Recognition worksheet. See [Customise terminology (rename records)](/project-financials/how-to/customise-terminology) for the overall workflow. ## Prerequisites * NetSuite administrator access * The Rename Records page open in FullClarity (FullClarity → Project Financials → Rename Records → Revenue Recognition Columns tab) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Column reference | # | Column name | Default label | | --- | --- | --- | | 1 | Actual Costs | Actual Costs | | 2 | Budgeted Costs | Budgeted Costs | | 3 | Calculated % Complete | Calculated % Complete | | 4 | Calculated Cost $ to Recognise | Calculated Cost $ to Recognise | | 5 | Calculated Rev $ to Recognise | Calculated Rev $ to Recognise | | 6 | Calculated Total Cost $ Recognised This Period | Calculated Total Cost $ Recognised This Period | | 7 | Calculated Total Rev $ Recognised This Period | Calculated Total Rev $ Recognised This Period | | 8 | Class | Class | | 9 | Department | Department | | 10 | Invoiced to Date | Invoiced to Date | | 11 | Job # | Job # | | 12 | Job Name | Job Name | | 13 | Job Status | Job Status | | 14 | Journal | Journal | | 15 | Location | Location | | 16 | Previously Recognised % | Previously Recognised % | | 17 | Previously Recognised Cost $ | Previously Recognised Cost $ | | 18 | Previously Recognised Rev $ | Previously Recognised Rev $ | | 19 | Project Budgeted Costs | Project Budgeted Costs | | 20 | Revised % Complete | Revised % Complete | | 21 | Revised Cost $ | Revised Cost $ | | 22 | Revised Rev $ | Revised Rev $ | | 23 | Snapshot | Snapshot | | 24 | Snapshot Date | Snapshot Date | | 25 | Subsidiary | Subsidiary | | 26 | Total Contract | Total Contract | | 27 | Total Cost $ To Recognise | Total Cost $ To Recognise | | 28 | Total Rev $ To Recognise | Total Rev $ To Recognise | **Total: 28 columns** ## What success looks like After saving your changes, the Revenue Recognition worksheet immediately reflects the new column labels for all users. ## Gotchas * **Columns cannot be hidden.** All 28 Revenue Recognition columns are always visible — there is no Hide checkbox on this tab. This is by design for accounting compliance. * **Column names should remain meaningful for auditors.** These columns appear in accounting workflows and may be referenced in audit processes — if you rename them, ensure the new labels remain clear to finance staff and auditors. --- --- url: 'https://fullclarity.help/project-financials/how-to/estimating/add-lines.md' --- # Adding lines to an estimate \[\[toc]] Once you've created an estimate and opened the worksheet, you can start adding cost lines. Each line represents a specific cost item — for example, "Supply concrete for footings" or "Install electrical conduit". ## When to use this Use this after you've [created an estimate](/project-financials/how-to/estimating/create-an-estimate) and opened the Estimate Worksheet. This is the primary way to build up your cost breakdown line by line. ## Prerequisites * An existing unlocked estimate on a project * The Estimate Worksheet open in your browser (click the estimate name from the Estimating subtab) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Adding a line 1. Right-click anywhere in the worksheet to open the context menu 2. Select **Add New Line** 3. A dialog opens with three sections: **Primary information:** * **Category** (required) — the cost category from your project's cost centre (e.g. "PW.003.01 Footings"). If you right-clicked on an existing category row, this will be pre-filled. * **Stage** — for Stage Billing projects, assigns this line to a billing milestone (e.g. "B. Base"). Not used for Progress Billing projects. * **Cost Type** — a secondary classification for the type of spend (e.g. Materials, Labour, Subcontractor) * **Allowance Type** — designates the line as a Prime Cost or Provisional Sum if applicable. Most lines leave this blank. **Item:** * **Item** (required) — select a NetSuite item (e.g. a service item or non-inventory purchase item) * **Filter Items by Category** — when checked, the Item dropdown only shows items associated with the selected category. This is useful when your item list is large. * **Description** — free text for project-specific context * **Quantity** — defaults to 1 * **Rate** — the unit cost * **Amount** — calculated automatically (Quantity × Rate) **Other costs & tax:** * **Contingency** — a risk buffer, entered as either a percentage or a dollar amount (entering one calculates the other) * **Margin** — profit margin, defaulting to the project's Default Margin %. Also bidirectional between percentage and dollar amount. * **Freight**, **Sales Tax**, and **Escalation** — additional cost adjustments, each available as percentage or dollar amount. These fields are only visible if enabled in General Preferences. A summary panel on the right shows running totals as you fill in the fields. 4. Click **Add Row** to save the line and close the dialog ## How the worksheet organises lines Lines are automatically organised into a tree structure based on their category. When you add a line under a category that doesn't exist in the worksheet yet, FullClarity creates the parent category rows automatically. Amounts roll up through the hierarchy — category totals reflect the sum of all lines within them. The summary rows at the bottom of the worksheet show the overall estimate totals: **Subtotal** (sum of all line amounts), **Total Contingency**, **Escalation**, and **Total** (the final estimate value including all other costs and margin). ## Adding multiple items quickly If you need to add several lines under the same category with minimal detail, right-click and select **Add Multiple**. This opens a streamlined dialog where you select a category and then pick multiple items at once. The lines are created with default values — you can then edit quantities, rates, and other details directly in the worksheet. ## Editing lines You can edit lines in two ways: * **Edit dialog** — right-click a line and select **Edit** to reopen the full dialog with all fields * **Inline editing** — click directly on a cell in the worksheet to edit it in place. Changes are saved automatically. ## Other context menu options The right-click context menu provides additional options beyond adding and editing lines: * **Delete** — removes the selected line from the estimate * **Collapse** / **Expand** — collapses or expands category groups in the tree, useful for navigating large estimates * **Add New Line** and **Add Multiple** — as described above The available options depend on what you've right-clicked — right-clicking a category row offers different options than right-clicking an individual line. ## What success looks like After clicking Add Row, the line appears in the worksheet under the correct category. The category total and estimate summary rows at the bottom update to include the new line's amount. If you added a line under a category not previously in the worksheet, a new parent category row appears automatically. ## Gotchas * **Category structure drives your estimate layout.** Choose your cost centre carefully when creating the project, as it determines which categories are available. * **Use "Import All Cost Centre Categories"** when creating the estimate if you want a complete category skeleton to fill in, rather than adding categories one at a time. * **The Applied checkbox** on each line controls whether it's included in the estimate totals. Lines are applied by default — uncheck it to exclude a line without deleting it. * **Contingency and Margin are separate from the line amount.** The Amount column shows Quantity × Rate. Contingency, margin, and other costs are added on top to calculate the Gross Amount. For a complete list of all columns available in the estimate worksheet, including their default labels and hide options, see [Estimate columns](/project-financials/how-to/customise-terminology/estimate-columns). --- --- url: >- https://fullclarity.help/project-financials/how-to/estimating/create-an-estimate.md --- # Creating an estimate \[\[toc]] An estimate is a detailed cost breakdown for a project or part of a project. You might create a single estimate for the entire job, or separate estimates for different scopes — for example, one for the main build, another for landscaping, and a third for a swimming pool. Multiple estimates can be grouped into **Estimate Collections** to model different project scenarios and compare total costs across different scope combinations. **Where to find it:** Open your project record, then click the **Estimating** subtab → **Estimate** tab. ## When to use this Use this when you're ready to start costing a project or a distinct scope of work within a project. You'll typically create your first estimate immediately after creating the project and before setting up contracts or billing. ## Prerequisites * An existing project in FullClarity with a cost centre assigned * Access to the project record's Estimating subtab ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Creating an estimate 1. Click the **Create Estimate** button on the Estimating subtab 2. A popup dialog appears with the following fields: * **Estimate Name** (required) — a label to identify this estimate, e.g. "Main Estimate" or "Deck Option A" * **Cost Centre** — shows the cost centre assigned to the project (read-only) * **Import All Cost Centre Categories** — when checked, the estimate is pre-populated with a row for every category in the cost centre. Leave unchecked if you prefer to add categories as you go. 3. Click **Submit** The new estimate appears in the list on the Estimating subtab, showing summary columns for Budget Cost, Margin, Projected Sale Price, and other key figures. ::: tip Estimating a design rather than a project Estimates are also created on a **Plan** — the reusable pricing template for one dwelling design in a development. The flow is the same **Create Estimate** / **Import Estimate** pair, run from the plan's Estimates sublist instead of a project's Estimating subtab, and the cost centre is inherited from the plan rather than the project. Estimate the plan once and every lot built to that design is priced from it. See [Create a plan](../create-a-plan). ::: ## Importing an estimate As an alternative to building an estimate from scratch, you can use the **Import Estimate** button on the Estimating subtab to import estimate data from an external source. This is useful when your estimating team has prepared the cost breakdown in a separate tool and you need to bring it into FullClarity. ## Opening the estimate worksheet Click the estimate name in the list to open the **Estimate Worksheet** in a new browser tab. This is a spreadsheet-like interface where you'll add and manage your cost lines. The worksheet shows: * A header with the estimate name, a link back to the project, and start/end date fields * The main grid where your cost lines appear, organised in a tree structure by category * Summary rows at the bottom showing Subtotal, Total Contingency, Escalation, and Total * Footer controls for display options like Show Inactives, tree lines, and zoom See [Adding lines to an estimate](/project-financials/how-to/estimating/add-lines) for how to populate the worksheet with cost data. For a full list of available columns and their default labels, see [Estimate columns](/project-financials/how-to/customise-terminology/estimate-columns). ## Locking an estimate Once an estimate is finalised, it can be locked to prevent further changes. A locked estimate is read-only — no lines can be added, edited, or deleted until it is unlocked. The lock status is shown in the **Is Locked** column on the Estimating subtab's estimate list. ## What success looks like The new estimate appears in the list on the Estimating subtab with a name you recognise. Clicking it opens the Estimate Worksheet in a new browser tab. If you ticked "Import All Cost Centre Categories", the worksheet shows a row for every category in your cost centre, ready to fill in with quantities and rates. ## Gotchas * **Cost Centre is read-only in the dialog.** It's inherited from the project. If you need a different cost centre, update it on the project's Configuration subtab before creating the estimate. * **A locked estimate cannot be edited.** Check the Is Locked column before attempting changes. An administrator can unlock it from the Estimating subtab. * **Estimate Collections are separate from individual estimates.** You create collections to group estimates for scenario comparison — they're managed separately from the Create Estimate flow described here. ## Related * [Add lines](./add-lines) * [Import from spreadsheet](./import-from-spreadsheet) * [Create a plan](../create-a-plan) — estimating a reusable dwelling design instead of a single project * [Manage cost centres](../manage-cost-centres) --- --- url: 'https://fullclarity.help/project-financials/how-to/estimating/create-pos.md' --- # Creating purchase orders from the estimate \[\[toc]] FullClarity provides a streamlined workflow for creating purchase orders directly from your cost estimate. Rather than manually creating a Purchase Order in NetSuite and populating all the project and estimate fields by hand, you can right-click on an estimate line, select a vendor, and create a PO with all the relevant fields pre-populated automatically. The workflow has three steps: 1. **Select Create Order** from the estimate worksheet context menu 2. **Choose a vendor** in the Select Vendor dialog 3. **Review and create** the purchase order on the Create Purchase Order page ## When to use this Use this when you're ready to order materials or engage a subcontractor for a specific line in your estimate. It's most useful when you want to tie the purchase order directly back to an estimate line, track remaining quantities, and avoid manual data entry on the PO. ## Prerequisites * An estimate with at least one item line (lines that have an item assigned — not just category rows) * The Estimate Worksheet open in your browser * The vendor exists in NetSuite, or you're prepared to create the vendor relationship from within the workflow ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Step 1: Initiate from the estimate worksheet Open your cost estimate worksheet and right-click on any **item line** (a line that contains an item — not a category subtotal line). From the context menu, select **Create Order**. ::: tip The Create Order option only appears on lines that have an item assigned. Category and subtotal lines show a different set of menu options. ::: ## Step 2: Select a vendor The **Select Vendor** dialog opens, showing the item name and item type at the top. ### Existing vendor relationships If the item already has vendors linked to it in NetSuite, they appear in the **Vendor Price** table at the bottom of the dialog. The table shows each vendor's rate and whether they are the preferred vendor. Click **Select** next to the vendor you want to order from. ### Adding a new vendor If the vendor you need is not listed, you can add them using the **Create Vendor Relationship** section: 1. In the **Select Vendor** field, type the vendor name and press **Tab** to search 2. Optionally enter a **Vendor Code** and **Vendor Cost** 3. Click **Create Relationship** This adds the vendor to the item record in NetSuite. The Vendor Price table refreshes to include the new vendor. You can then click **Select** to proceed. ::: tip You do not need item record editing permissions to use the Create Vendor Relationship feature. This allows project managers to add vendor relationships even if they don't have access to edit item records directly. ::: ## Step 3: Create the purchase order After selecting a vendor, a new page opens: **Create Purchase Order**. This page shows all the estimate lines where the selected vendor supplies the item — not just the single line you right-clicked on. ### Header fields Fill in the purchase order details at the top of the page: * **Purchase Order Form** — the NetSuite form template to use for the PO * **Contact Person** — select a contact for the vendor * **Address** — select from the vendor's addresses * **Delivery Address** — enter a delivery address * **Delivery Date** — when items are expected * **Additional Message to Vendor** — any notes to include on the PO The **Project**, **Subsidiary**, and **Vendor** fields are pre-populated and cannot be changed. The **Summary** panel shows the running total of selected items. ### Filters Use the **Category** and **Stage** dropdowns to filter the items list if you have many lines to work through. ### Items tab This tab lists every estimate line where the selected vendor is linked to the item. Each line shows: * **Category** and **Stage** from the estimate * **Item** and **Description** from the estimate * **Estimate QTY** and **Estimate Rate** — original values from the estimate * **Remaining QTY** — how many units are still available to order (decreases as you raise POs against this estimate line) * **Purchase QTY** — defaults to the Remaining QTY; edit to order a different quantity * **Purchase Rate** — the rate for this purchase; edit if the vendor's price differs from the estimate * **Amount** — line total Check the **Select** box on each line you want to include on the PO. Use **Mark All** or **Unmark All** for bulk selection. ::: tip You don't have to order everything at once. Only checked lines are included on the PO. Unchecked lines remain available for future orders — their Remaining QTY will be unaffected. ::: ### Additional Items tab If you need to order items that are not on the cost estimate, use the **Additional Items** tab. Select an item from the dropdown, and the description and rate (if available) auto-populate. Enter the quantity and amount, then click **Add**. ### Creating the PO When you're satisfied with your selections, click **Create**. FullClarity creates a standard NetSuite Purchase Order with all the project, estimate, and FullClarity fields automatically populated on each line. This may take a moment for large orders. Once complete, the new Purchase Order opens in NetSuite where you can review, approve, and process it through your normal workflow. ## What gets auto-populated on the purchase order FullClarity automatically sets the following fields on each PO line, saving you from manual entry: * **Project** (Customer:Job / FC Project) * **Cost category, cost type, and stage** from the estimate * **Estimate Item Line Ref** — links the PO line back to the specific estimate line * **WP Location** — if set on the estimate * **Asset Type** — if set on the estimate * **Retainage % and Amount** — if retention is configured for the vendor * **Expected Receipt Date** — from the Delivery Date you entered ## What success looks like A new Purchase Order appears in NetSuite with all project and estimate fields pre-populated. The Remaining QTY on the estimate lines you included decreases to reflect the quantities ordered. You can track commitments against your estimate from the Budget worksheet. ## Gotchas * **Create Order only appears on item lines.** Right-clicking a category subtotal row will not show this option. You must right-click a row that has an item assigned. * **Remaining QTY decreases with each PO.** If you over-order or need to cancel a PO, the Remaining QTY does not automatically restore — check your PO history if quantities look wrong. * **Large orders may take a moment.** The Create button creates all PO lines in one operation; don't click it twice. ## Related topics * [Managing cost centres](/project-financials/how-to/manage-cost-centres) --- --- url: >- https://fullclarity.help/project-financials/how-to/estimating/import-from-spreadsheet.md --- # Importing an estimate from a spreadsheet \[\[toc]] If you have an existing cost estimate in a spreadsheet, you can import it into FullClarity rather than re-entering every line manually. The import process reads your spreadsheet, matches your data against the project's categories, items, and cost types, and creates estimate lines in the selected estimate worksheet. ## When to use this Use this when your estimating team has already prepared a cost breakdown in Excel or a similar tool and you need to bring it into FullClarity. This is faster than manual entry for large estimates and reduces transcription errors. ## Prerequisites * A project in FullClarity with a cost centre assigned. The cost centre determines which categories are available for the import. * An estimate worksheet to import into (or the import can create a new one). The estimate must be unlocked. * Your spreadsheet in Excel format (.xlsx or .xls). CSV files also work. Your spreadsheet does not need to follow a specific template — the import process will interpret your column layout and ask you to confirm the mapping before anything is created. ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## What the import looks for The import process identifies columns in your spreadsheet that correspond to FullClarity estimate fields: * **Category** — your trade or cost code (e.g., Concrete, Electrical, Framing). These are matched against the categories in your project's cost centre. * **Description** — line-level detail describing the work or materials. * **Quantity and Rate** — used to calculate the line amount. If your spreadsheet has a total amount but no quantity, the line is imported as a lump sum (quantity of 1). * **Cost Type** — the nature of the cost (Labour, Materials, Equipment, Subcontractor, etc.). If your spreadsheet doesn't include this, you can choose a default or assign them after import. * **Stage** — relevant for stage billing projects. If your project uses progress billing, this is optional. * **Margin or Markup** — if your spreadsheet includes a profit margin. FullClarity uses margin (as a percentage of the selling price), so if your spreadsheet uses markup (percentage of cost), the values are converted automatically during import. * **Contingency** — a risk buffer percentage, if included. Rows that look like section headers, subtotals, grand totals, blank spacers, or notes are automatically skipped — only actual cost lines are imported. ## How it works 1. **Upload your spreadsheet** and tell FullClarity which project it's for. 2. **Review the column mapping** — FullClarity shows you which spreadsheet columns it has matched to which estimate fields, and asks you to confirm or adjust. 3. **Review the data matching** — category names, cost types, and items from your spreadsheet are matched against your FullClarity standing data. You'll see which values matched exactly, which are close matches needing confirmation, and which couldn't be matched. 4. **Confirm the import** — a summary shows the total number of lines, the estimated total cost, and the estimated selling price. Nothing is created until you approve. 5. **Lines are created** in the estimate worksheet. Open the worksheet in your browser to see the imported lines in the grid. ## What success looks like After confirming the import, the lines appear in the Estimate Worksheet organised by category. The summary rows at the bottom show the total cost and selling price derived from the imported data. Any lines with unmatched categories are flagged for your attention. ## Gotchas * **Category names don't need to be exact.** The import uses fuzzy matching — "Concreting" will match to "Concrete", and "Electrical Works" will match to "Electrician". You'll always be asked to confirm fuzzy matches before they're applied. * **Check your margin convention.** The most common issue is spreadsheets that express profit as markup (percentage of cost) rather than margin (percentage of selling price). A 33% markup is equivalent to a 25% margin — the import handles the conversion, but you need to confirm which convention your spreadsheet uses. * **Lump sum lines are fine.** If a line has a total dollar amount but no quantity or rate breakdown, it's imported with a quantity of 1 and the total as the rate. * **You can import into an existing estimate.** If the project already has an estimate with lines, the import adds new lines alongside the existing ones. Existing lines are not modified. * **Your spreadsheet format doesn't matter.** Currency symbols, thousand separators, percentage signs, and different number formats are all handled automatically. --- --- url: >- https://fullclarity.help/project-financials/how-to/estimating/request-vendor-bids.md --- # Requesting vendor bids \[\[toc]] FullClarity lets you send the items from a cost estimate out to your suppliers and subcontractors for pricing, then collect their responses in one place. You raise a single bid request, choose the items and vendors, and each vendor receives an email with a secure link to an online bid form. As bids come back, you can compare what each vendor offered against the same set of items before deciding who to award the work to. Several bid-management defaults are set once on the Project Financials **Configuration** record — the invitation and reminder email templates, the reminder lead time, and the acceptance mode and "add estimate lines as applied" behaviour that control how accepted or preferred prices flow onto the estimate. These pre-fill each new bid request and can be overridden per request. See [Configuring bid management](#configuring-bid-management) below for what each of these does. The workflow has three parts: 1. **Raise a bid request** against an estimate, choosing the items and vendors 2. **Send the invitations** so each vendor receives a link to their online bid form 3. **Review the responses** as vendors submit their pricing (or decline), then prefer or award the work ## What a Vendor Bid Request is A **Vendor Bid Request** is a single record that ties together everything about one round of pricing: the estimate you're bidding, the items you want quoted, the vendors you're inviting, and — as they come back — every vendor's response. You raise one request, and FullClarity creates one **bid** underneath it for each vendor, so each supplier prices the same list independently. The request record is organised into subtabs, so it helps to know what each one is for before you start: * **Overview** — once bids arrive, a **Bid Line Summary** showing where every scope line stands. (The request's own details — estimate, title, due date, instructions — sit at the top of the record, just above these subtabs.) * **Bids** — the individual bids, one per vendor, and their statuses. This is where you send invitations, and review, prefer or award responses. * **Categories** — the scope lines you've chosen from the estimate for vendors to price. * **Mail Merge** — the invitation and reminder emails that go out to vendors. * **Files** — the supporting documents (drawings, specs, scopes) sent with the request. You don't need to master these up front — the steps below walk you through them in order — but knowing the layout means you'll always know where to look. ## When to use this Use this when you want competitive pricing for the items in an estimate — for example, sending a list of materials to several suppliers, or a scope of work to a few subcontractors, and asking each to quote. Because every vendor bids against the same items and quantities, the responses are easy to compare side by side. ## Prerequisites * An existing project with at least one **estimate** that contains the items you want priced. Vendors bid on the items from that estimate, so the estimate must exist first. * The vendors you want to invite exist in NetSuite with a contact email address. * Access to the project record's **Estimating** subtab. ::: tip The bid feature is enabled by your administrator. If you don't see the **Bid Request** option on the Estimating subtab, ask your administrator to enable bids from the estimate in the system settings. ::: ## Configuring bid management A handful of bid-management defaults live on the Project Financials **Configuration** record, set once per subsidiary. They aren't things you touch every time you raise a bid — instead, each one **pre-fills the matching field on every new bid request**, so raising a request starts from sensible defaults. You can still override any of them on an individual request. Getting these right up front means most requests need little more than a title, a due date and a list of items. The settings are: * **Bid Invite Email Template** and **Bid Reminder Email Template** — the email templates used for the invitation that goes out when you send a request, and for the reminder that chases vendors who haven't responded. Both pre-fill each new request and can be swapped per request. The invitation ships with a built-in default, so invites work out of the box; the reminder has **no built-in default yet**, so until you set a reminder template, reminders are sent without one. * **Send Bid Reminder Days Before** — how many days before the due date the reminder is sent. It defaults to **15** and pre-fills each request's reminder lead time, which you can change per request. * **Acceptance mode** — how accepting a bid flows onto the estimate. In **Accepted** mode, accepting a bid writes **all** of its priced lines to the estimate. In **Preferred** mode, accepting is only an acknowledgement — you then pick the specific lines you want to **prefer**, and only those reach the estimate. Choose the mode that matches how your team works: whole-quote comparison, or line-by-line selection across vendors. * **Add estimate lines as Applied** — whether lines written to the estimate by Accept or Prefer count toward its totals straight away. When **on**, those lines are **applied** — they affect the estimate totals immediately. When **off**, they land **unapplied**, sitting alongside the estimate as comparison prices until you apply them yourself. In the Preferred + Applied combination, preferring a vendor's line **supersedes** the original estimate line it was raised from — the original is set to unapplied so the preferred price takes its place in the totals. For the field-by-field detail, see [Configuration record fields](../../reference/configuration-record-fields#vendor-bidding). ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## Step 1: Raise the bid request On the project record, open the **Estimating** subtab, then choose **Bid Request → New Vendor Bid Request**. Fill in the request details: * **Estimate** — choose the estimate you want to bid against. The items you can send out are drawn from this estimate. * **Title** — a label for the request, e.g. "Concrete supply — CBD Office Fitout". * **Due Date** — the date you want bids returned by. This is shown to vendors on their bid form. * **Reminder lead time** — how many days before the due date a reminder email is sent. This defaults to 15 days. * **Instructions** — free text explaining what you need. This text is shown to the vendor on their online bid form, so use it to set expectations (scope notes, site conditions, how to ask questions, and so on). ::: tip Each request has its own email templates The request also carries a **Bid Invite Email Template** and a **Bid Reminder Email Template**, both defaulted from your subsidiary's configuration when the request is created. Leave them as they are to use the configured defaults, or change them to send this particular request's invitation and reminder using different templates. The emails use the request's own templates, falling back to the configured default if a template is left blank. ::: ## Step 2: Add the items to bid out Use **Add Items from Estimate** to choose which lines you want vendors to price. * Tick a whole **cost section or category** to include every line beneath it, or * Pick **individual lines** if you only want a subset priced. ::: tip Your costs stay private Only the **item, description and quantity** are shared with vendors. Your own estimated rates, margins and totals are never shown on the bid form — vendors only see what you are asking them to price. ::: ## Step 3: Attach supporting files (optional) If you have supporting documents you want vendors to refer to — drawings, a specification, a scope document — attach them to the bid request so they appear on each vendor's bid form. On the bid request (either while creating it, or by editing it afterwards), open the **Files** subtab. It lists the documents already held against the **project**; tick the ones you want to include with this request, then **Save**. Every invited vendor can then download the ticked files from their online bid form. Once you've saved, the Files subtab switches to a simple list of what you've chosen, with a **Name** and **Category** for each document. The **Name** is a clickable link — click it to open a preview of that file, so you can double-check exactly what's being shared with vendors before you send. This is handy for a newcomer: rather than trusting the tick boxes, you can click through and confirm you've attached the right drawings or specification. ::: tip The Files subtab lets you choose from documents already held on the project record. Getting files onto the project in the first place is covered separately. ::: ## Step 4: Confirm the vendors FullClarity automatically suggests the vendors who supply the items you've selected, so the list is usually pre-populated for you. You can **add** any other vendors you'd like to invite, or **remove** suggested vendors you don't want to approach. When you **Save**, the request creates one bid per vendor — each vendor gets their own copy to respond to independently. ## Step 5: Send the invitations You can send the invitations in two ways: * **Send Bid Emails** — sends to every vendor on the request at once. * Open an **individual bid** and choose **Send Email** — sends to just that one vendor (useful if you add a vendor after the first send, or need to resend to one supplier). Each vendor receives an email containing a secure link to an online bid form. The link is unique to that vendor. After sending, you can use **Send Bid Reminders** to nudge vendors who haven't responded yet. A reminder is also sent automatically based on the reminder lead time you set in Step 1. ::: tip Email templates and the reminder default come from your configuration Each bid request carries its own **Bid Invite Email Template** and **Bid Reminder Email Template**, defaulted from your subsidiary's configuration when the request is created — so you can override them for an individual request if you want that request to use different wording. The invitation and reminder emails use the request's own templates, falling back to the configured default if a request's template is blank. The default reminder lead time (15 days) also comes from that configuration; it pre-fills the **Reminder lead time** on each new request, which you can still change per request. The **Acceptance mode** (Accepted or Preferred) and **Add estimate lines as Applied** settings also come from the Configuration record and pre-fill each new bid request; both can be changed per request. See [Configuration record fields](../../reference/configuration-record-fields#vendor-bidding) for these and all other settings. ::: ## What the vendor sees and does When a vendor opens the secure link from their email, they see an online bid form showing: * The job details and your **Instructions** * The list of **items** you're asking them to price, with quantities — but not your costs * Any **supporting files** you attached to the request, which they can download For each line, the vendor enters a **Rate**, and the line **Amount** calculates automatically. A **running total** at the bottom of the form updates as they price each line, so they can see the overall value of their bid at a glance. They can also: * Add **Comments**, **Inclusions** and **Exclusions** to clarify what their pricing covers * Attach one or more **supporting files** — for example a PDF, spreadsheet or image of their own formal quote. They can drag files onto the upload area or click to browse, and they're sent along with their bid. The vendor then either: * Clicks **Submit** to send their priced bid back to you, or * Uses **Decline** to opt out, choosing one or more decline reasons. Once a vendor submits or declines, their response is locked — re-opening the link shows a **Response Already Submitted** message instead of the form. If a vendor needs to revise their bid, use **Re-open** on their bid in NetSuite (see Step 7). ## Step 6: Review the responses To pick your bid request back up at any time, reopen the project record, go to the **Estimating** subtab and open the same estimate's bid requests — the request you raised is listed there. Open it to see all the vendors and their responses in one place. ### The Bids subtab Open the **Bids** subtab and each vendor's bid appears as its own row against the request. For each one you can see: * The **status** — see the plain-English guide below * The **amounts** the vendor entered, along with any comments, inclusions and exclusions * Any **files** the vendor attached — saved against their bid, showing the vendor as who uploaded them * For a declined bid, the **decline reasons** they selected Open an individual bid to see the full detail of what that vendor priced. Each bid has its own **Files** subtab, so you can also upload your own documents against a specific bid — for example a marked-up version of the vendor's quote or your notes on their response. Use **Add New Files** to attach them. ### What each status means As a request moves along, each bid carries a status so you can see at a glance where it stands: * **Initialized** — the bid has been created but not yet sent to the vendor. * **Sent** — the invitation email has gone out; you're waiting on the vendor. * **Received** — the vendor has submitted their priced bid. * **Declined** — the vendor opted out; their decline reasons are recorded. * **Rejected** — you've rejected this bid (this is your decision, as distinct from the vendor declining). A rejected bid can still be re-opened later if you change your mind — it keeps its pricing and link (see Step 7). * **Accepted** — you've accepted this whole bid. In Accepted mode this also puts all its priced lines on your estimate as candidate lines; in Preferred mode accepting is only an acknowledgement and nothing reaches the estimate until you prefer lines (see Step 7). * **Preferred** / **Partially Preferred** — you've chosen some or all of this vendor's lines onto the estimate (Preferred mode); "Partially" means only some lines are preferred. * **Re-opened** — you've reopened the bid for the vendor to revise (see Step 7); a fresh link goes out on the next send. * **Awarded** / **Partially Awarded** — you've committed some or all of the vendor's lines to that vendor (see Step 7). ### The Overview summary (Bid Line Summary) Once bids start coming in, the **Overview** subtab gives you a single, at-a-glance table — the **Bid Line Summary** — with **one row per scope line** you sent out. It sets the estimator's original figure alongside the preferred and awarded vendor prices, so you can compare all three side by side: * **Category** — the cost category the line sits under. * **Item** — the item you asked vendors to price. * **Description** — the line description. * **Original Estimate** — the estimator's own amount for that line, before any vendor pricing. * **Preferred Vendor** — the vendor whose pricing you've preferred for that line, if any. * **Preferred Vendor Amount** — that preferred vendor's price for the line. * **Awarded Vendor** — the vendor you've awarded that line to, if any. * **Awarded Vendor Amount** — that awarded vendor's price for the line. A dash (**—**) in a Preferred or Awarded column means nothing has been preferred or awarded for that line yet. As you work through the responses and press **Prefer** or **Award** (Step 7), the dashes fill in with vendor names and rates. This is your one view of where every line stands across all the vendors at once — so at any point you can see which lines are settled and which still need a decision. From here you review and compare the responses, then accept, prefer, or award bids — see the next step. ## Step 7: Work with received bids Once bids are in, you have a set of tools depending on how you want to work — **Accept** a whole bid, **Prefer** or **Award** individual lines, **Reject** a bid you won't proceed with, or **Re-open** one for revision: ### Acceptance mode and applied lines Two settings on the bid request control how your choices reach the estimate. Both default from the Project Financials Configuration record and can be changed on an individual request (see [Configuration record fields](../../reference/configuration-record-fields#vendor-bidding)): * **Acceptance mode** — either **Accepted** or **Preferred**. This governs what happens to the estimate when you **Accept** a bid. * **Add estimate lines as Applied** — on or off. This governs whether lines brought onto the estimate are counted in its totals straight away. An **applied** estimate line counts toward the estimate totals. An **unapplied** line sits alongside your estimate as a candidate — a comparison price — without affecting the totals until you apply it. This is what lets you bring several vendors' prices onto the estimate to weigh them up, then decide which one actually counts. **Preferred mode with "Add as Applied" on.** When you **Prefer** a vendor's line, that line is written onto the estimate as an **applied** line, and the original estimate line it was raised from is automatically set to **unapplied**. The result is exactly **one applied line per estimate line** — the preferred vendor's price takes the place of the estimator's original figure in the totals. (Each bid line remembers the estimate line it came from, which is what makes this swap possible.) **Preferred mode with "Add as Applied" off.** Preferred lines are added **unapplied** — candidate prices for comparison — and your original estimate lines are left applied. Nothing changes in the totals until you apply the lines yourself. **Accepting a bid in Preferred mode writes nothing to the estimate.** Only preferring specific lines brings pricing across. The Accept confirmation message spells this out: if you're in Preferred mode and want lines on the estimate, use **Prefer**, not **Accept**. ### Accept (whole-quote) Use **Accept Bids** on the bid request to mark one or more received bids as Accepted. You can select and accept multiple bids at once. Accepting a bid: * Sets the bid's status to **Accepted**. * In **Accepted** mode, writes all the vendor's priced lines onto your estimate as **candidate lines** — the vendor and their rate appear in the Quote and Supplier columns. These lines are added unapplied (unless **Add estimate lines as Applied** is on), so they don't change your estimate's totals until you apply them. * In **Preferred** mode, does **not** change the estimate — accepting is only an acknowledgement. To bring pricing across, use **Prefer** on the specific lines you want (see *Acceptance mode and applied lines* above). Use Accept in **Accepted** mode when you want to bring a whole bid onto the estimate as candidate lines for comparison, then apply the winner later. ### Prefer (line by line) Use the **Prefer** button on an individual bid to choose specific lines to bring onto the estimate. This lets you split a package across vendors — for example, preferring one vendor's materials lines and a different vendor's labour lines. Prefer is available on any received bid, whatever the request's Acceptance mode — the mode only controls how **Accept** populates the estimate, not whether you can prefer individual lines. So you can accept several bids to compare them, then prefer the winning lines without having to commit the request to Preferred mode first. To prefer lines: * Open a received bid → **Prefer**. A popup lists that bid's lines with a tick box against each. Lines you've already preferred are ticked when the popup opens, and **Mark All** / **Unmark All** let you select or clear every line at once. Tick the lines you want and confirm. * Or tick the **Preferred** column directly on the bid's lines. Only the ticked lines land on the estimate. Un-preferring a line removes it from the estimate (unless it already has a purchase order against it). ::: tip One preferred vendor per line A scope line can be preferred on only **one** bid per request. If you prefer a line that you'd already preferred on another vendor's bid, FullClarity clears it from that other bid automatically — so the Bid Line Summary always shows a single preferred vendor for each line. ::: ### Award (soft commitment) Use the **Award** button (or tick the **Awarded** column on bid lines) to mark specific lines as awarded to that vendor. The **Award** popup works the same way as Prefer — already-awarded lines are pre-ticked, and **Mark All** / **Unmark All** are available. Awarding a line: * Sets the line's status to Awarded and rolls the bid to Partially Awarded or Awarded. * **Does not change the estimate** — the estimate already reflects the candidate lines from Accept or Prefer. * Locks the bid from being re-opened. ::: tip One awarded vendor per line Like Prefer, a scope line can be awarded to only **one** vendor per request. Awarding a line that was already awarded on another vendor's bid clears it from that other bid, so each line has a single awarded vendor. ::: Awarded lines will be eligible for conversion to a purchase order in a future release. ### Reject a bid Use **Reject** on an individual bid to record that you're not proceeding with it — for example a bid that came in too high or didn't meet your requirements. This is your decision, and is separate from a vendor **declining** (opting out themselves). A rejected bid keeps its pricing and its portal link, so you can re-open it later if circumstances change (see below). ### Re-open a bid If you need a vendor to revise their pricing, use **Re-open** on that vendor's bid. What happens depends on the bid's current status: * For most bids, re-opening resets the status to **Re-opened** and invalidates the old portal link so the vendor can't use it. You then press **Send Email** to issue a fresh secure link. * A **Rejected** bid re-opens straight back to **Received**, keeping its existing pricing and its original link — because the vendor's response is still on hand, there's nothing to re-issue. When you send a fresh link and the vendor opens it, their previously entered rates are pre-filled and any files they uploaded before are available for download. They can update their pricing and resubmit. ::: tip Re-open is not available once any line on the bid has been awarded. ::: ### Resend Request (re-open and email in one step) For a bid that's already been **Received**, **Resend Request** is a one-click shortcut: it re-opens the bid **and** immediately emails the vendor a fresh secure link, saving you the separate Re-open then Send Email steps. Use it when a vendor who has already responded needs to price the request again. ### Mark as Received (for offline responses) If a vendor sends their pricing back to you outside the online bid form — by email, phone or on paper — use **Mark as Received** on their bid to record that a response has arrived. It's available on a bid that's been **Sent** or **Re-opened**, and moves the bid to **Received** so you can enter and work with the pricing as normal. After re-opening and re-accepting bids, use **Apply** on the estimate worksheet to make the chosen vendor's lines count toward the estimate totals. ::: tip Next step Once you've accepted, preferred, or awarded bids and applied the winning lines on your estimate, you can raise purchase orders. See [Creating purchase orders from the estimate](/project-financials/how-to/estimating/create-pos). ::: ## Deleting a bid request If you no longer need a bid request, you can delete it from the request record. Deleting a Vendor Bid Request removes the request **and all of its bids**. Because a single request can hold many bids — each with its own priced lines linked to the estimate — the request itself is removed immediately, while its bids are cleaned up in the **background** (usually within a few minutes). The estimate is reconciled for you automatically: * Lines that came from the deleted bids are removed. * Any original estimate lines those bids had superseded are set back to **applied**, so your estimate returns to the figures it held before the bids arrived. * Lines that have already been turned into a purchase order are kept. ::: warning You'll land on the bid request list, not the project After deleting a bid request, NetSuite returns you to the **list of bid requests** — not to the project you were working on. This is a NetSuite platform behaviour that can't be changed. To carry on, reopen the project record and go back to its **Estimating** subtab. ::: ## The full journey at a glance Putting the steps together, a typical bid runs like this: 1. **Raise** a bid request against an estimate, give it a title and due date, and add the scope lines you want priced. 2. **Attach** any supporting files, and confirm the list of vendors — FullClarity creates one bid per vendor. 3. **Send Bid Emails** so every vendor gets a secure link to their own online bid form, and **Send Bid Reminders** to chase anyone who hasn't responded. 4. Vendors **price** their lines (or **decline**) and submit; their responses land back on the **Bids** subtab. 5. **Review** and compare the responses, using the **Overview** Bid Line Summary to see where each line stands. 6. **Prefer** the lines you want onto the estimate (or **Accept** whole bids), then **Award** the winning lines to commit them — the Bid Line Summary fills in as you go. 7. **Apply** the winning lines on the estimate worksheet, ready to raise purchase orders. ## What success looks like Each invited vendor has a bid against your request showing their status. Vendors who responded show the rates and amounts they entered (plus any attachments and notes), and any who declined show their reasons. The **Overview** Bid Line Summary shows, line by line, which vendor you've preferred and which you've awarded — with dashes only against the lines still to be decided. You have everything you need to compare like-for-like and decide who to award the work to. ## Gotchas * **You need an estimate first.** Vendors bid on the items from an estimate, so create and populate the estimate before raising a bid request. * **Vendors need an email address.** A vendor with no contact email can't receive the invitation. Check the vendor record before sending. * **Vendors never see your costs.** Only item, description and quantity are shared — this is by design, so don't expect your rates or margins to appear on the bid form. * **Don't see Bid Request on the Estimating subtab?** The feature needs to be enabled by your administrator in the system settings. * **After deleting a bid request you land on the bid request list, not the project.** This is a NetSuite platform behaviour that can't be changed — reopen the project and its Estimating subtab to carry on. * **Accepting in Preferred mode doesn't touch the estimate.** In Preferred mode, only **Prefer** brings vendor pricing onto the estimate; use it rather than Accept when you want lines to count. ## Related topics * [Creating an estimate](/project-financials/how-to/estimating/create-an-estimate) * [Adding lines to an estimate](/project-financials/how-to/estimating/add-lines) * [Creating purchase orders from the estimate](/project-financials/how-to/estimating/create-pos) * [Configuration record fields](/project-financials/reference/configuration-record-fields) --- --- url: 'https://fullclarity.help/project-financials/how-to/manage-cost-centres.md' --- # Managing cost centres \[\[toc]] A cost centre defines the structure of budget categories available for your projects. Each cost centre contains a set of categories — such as Preliminaries, Concrete, Electrical — organised in a hierarchy. When you assign a cost centre to a project, only the categories in that set are available for estimates, budgets, and transactions on that project. You can create multiple cost centre sets to suit different types of work. For example, you might have one set for residential construction and another for commercial fitouts. **Where to find it:** FullClarity → Project Financials → Manage Cost Centres ## When to use this Use this when setting up your system for the first time, adding a new type of project that requires a different category structure, or maintaining an existing cost centre set (adding categories, reordering, or inactivating categories that are no longer in use). ## Prerequisites * NetSuite administrator access * A clear picture of the category structure you need (trade categories, hierarchy depth, and any stage assignments) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. ::: ## The Manage Cost Centres page The page has three main areas: * **Cost Centre dropdown** — select which cost centre set to view or edit. Changing the selection reloads the page with that set's categories. * **Category grid** — displays the categories for the selected cost centre in a tree structure. Categories with children show an expand icon that you can click to show or hide child categories. * **Toolbar** — buttons for saving, adding rows, managing hierarchy, and other actions. Sits at the bottom of the grid. Two checkboxes appear below the grid: * **Show Inactive** — when ticked, displays an Inactive column and shows any categories that have been inactivated * **Show tree lines** — when ticked, displays visual connector lines between parent and child categories ## Creating a new cost centre set To create a new cost centre set: 1. Hover over the **Cost Centre** dropdown. Two icons appear to the right. 2. Click the **+** icon. A popup form opens. 3. Enter a **Name** for the new cost centre set. 4. Click **Save**. The popup closes and the page reloads with your new (empty) cost centre selected, ready for you to add categories. ::: tip The other icon (external link) opens the existing cost centre record, where you can rename it or mark it as inactive. ::: ## Adding categories There are several ways to add a new category: **From the column header:** Right-click on the column header row (the row showing ID, Name, Stage, Sort Order) and select **Add New Line**. **From an existing row:** Right-click on any category row and select **Add New Line**. The new row is inserted above the selected row. **From the toolbar:** Select a row first, then click the **Add** button in the toolbar. The new row is inserted above the selected row. Note: the button has no effect if no row is selected. After adding a row: 1. The Name cell is already in edit mode — type the category name. 2. Press **Tab** to move to the next column, or click anywhere else on the grid to confirm the value. 3. Do not press **Escape** — this cancels your entry. When you Tab into the **Stage** column, a dropdown opens automatically. If you don't need to set a stage, press Escape to close the dropdown, or Tab again to skip to Sort Order. ## Creating child categories To build a hierarchy (for example, "Footings" and "Slab on Ground" as children of "Concrete"): **From the context menu:** Right-click on the row that should be the parent and select **Add New Child Line**. A new row appears indented beneath the parent. **From the toolbar:** Select the parent row, then click the **Add Child** button in the toolbar. **By indenting:** Add a row as a sibling first, then select it and click the **Indent** button in the toolbar to convert it into a child of the row above. Use **Outdent** to reverse this and promote a child back to a sibling. There is no limit on hierarchy depth — you can nest children under children. In practice, most organisations use two levels (parent and child) and rarely go beyond four. ## Editing categories To edit a category name, stage, or sort order, click on the cell you want to change. The cell enters edit mode. Type the new value and press Tab or click elsewhere to confirm. ## Reordering categories Each row has a drag handle on the far left. Click and hold the drag handle, drag the row to its new position, and release. Save the grid to persist the new order. ## Removing categories There are two ways to remove a category, and the choice matters: **Inactivate (recommended)** — use this for categories that have been used on estimates or transactions: 1. Tick the **Show Inactive** checkbox at the bottom of the page. An Inactive column appears. 2. Tick the **Inactive** checkbox on each category you want to hide. 3. Click **Save**. Inactivated categories are hidden from the grid (unless Show Inactive is ticked) and cannot be selected on new estimate lines or transactions. However, they remain visible on any existing estimate lines that already reference them. You can reactivate a category at any time by unchecking its Inactive box. **Delete (permanent)** — use this only for categories that have never been used: 1. Right-click on the row and select **Delete Line**. 2. Click **Save**. If the category is referenced by any estimates or transactions, the save will fail with an error. In that case, inactivate the category instead. ## Assigning stages to categories The **Stage** column is used with milestone/stage billing projects. When you assign a stage to a category here, that stage is automatically filled in as the default whenever someone adds an estimate line using that category. This saves time on stage billing projects where each trade category typically maps to a specific construction stage. If your projects use progress billing rather than stage billing, you can leave the Stage column empty. ## Saving changes Changes on this page are not saved automatically. To save: 1. Click the **Save** button (floppy disk icon) in the toolbar at the bottom-left of the page. 2. A confirmation message appears. Click **OK**. 3. The grid reloads with your saved data. Any new categories will now show their assigned ID numbers. ## Category naming — important Category names must be **unique across your entire system**, not just within the current cost centre set. If two cost centre sets both have a category called "Preliminaries", this can cause problems — including blocking software updates. **Recommended approach:** Use a short prefix code for each cost centre set, applied to every category name. For example, a cost centre called "Residential" might use the prefix "RES": * RES001 Preliminaries * RES001.01 Site Setup * RES001.02 Permits & Fees * RES002 Concrete * RES002.01 Footings The prefix keeps every name unique while remaining readable. Choose whatever convention works for your business — the important thing is consistency. ## What success looks like After saving, the grid reloads and each new category shows its assigned ID number. The cost centre is immediately available to assign to new projects, and the new categories are immediately available in the estimate worksheet for any projects using this cost centre. ## Gotchas * **Category names must be unique system-wide** — not just within the current set. Duplicate names across sets can block software updates. Use a prefix convention (see above). * **Don't press Escape while editing a cell** — it cancels your entry. Use Tab or click elsewhere to confirm. * **Delete will fail if the category is in use.** If you get a save error on delete, inactivate the category instead. * **Save frequently** when making multiple changes, rather than making all changes and saving once. * **If you accidentally add a row,** use **Undo** in the toolbar before saving, or delete the unwanted row via right-click → Delete Line. --- --- url: 'https://fullclarity.help/project-financials/how-to/manage-phases.md' --- # Managing phases A phase is a delivery grouping within a project — the release, stage of works or block of units that a cost belongs to. Phases let you classify and report cost by phase across one project without having to create a separate project for each phase. \[\[toc]] Phases are organised into **phase sets**, exactly the way cost categories are organised into cost centres. A phase set is a named list of phases; a project nominates one set, and only the phases in that set are available on that project. That means a community needing bespoke phase names — `Phase 3 Building 25`, say — can have them without those names appearing on every other project in the business. **Where to find it:** FullClarity → Project Financials → Manage Phases ::: warning Phase, Stage and Billing Stage are three different things A **phase** is a delivery grouping of work or units. A **stage** is the billing-or-project stage used by stage billing and stage-grouped estimating. A **billing stage** is a milestone on a stage-billing contract, with a percentage of the contract value against it. A project will routinely use more than one of them at once, they hold completely different values, and nothing about phases is derived from stages. ::: ## When to use this Use this when you are setting phases up for the first time, adding a phase set for a new community or development, or maintaining an existing set — adding phases, changing the order they appear in, or retiring a phase that is no longer used. ## Prerequisites * NetSuite administrator access * A clear picture of the phases you need, and the order you want them shown in ::: danger Create your phase sets before you turn phases on A project that uses phases **must** nominate a phase set, and Project Financials ships with **no** phase sets and no phases — you create your own. The **Enable Phases** general preference ticks **Use Phases** on every newly created project, so if you turn that preference on before any phase set exists, **no new project can be saved at all**. The order is: create at least one phase set and its phases here, **then** turn on the preference. See [Using phases on a project](./use-phases#turning-phases-on). ::: ## The Manage Phases page The page has three areas: * **Phase Set dropdown** — selects which set to view or edit. Changing the selection reloads the page with that set's phases. * **Phase grid** — the phases in the selected set, each with a **Name** and a **Sort Order**. Both are editable. * **Toolbar** — save, add and other actions, at the bottom of the grid. Below the grid is a **Show Inactive** checkbox. Tick it to add an Inactive column and reveal any phases that have been retired. Phases are a **flat list** within a set. Unlike cost categories, they have no hierarchy — there are no parent and child phases, and no indenting. ## Creating a phase set 1. Hover over the **Phase Set** dropdown. Two icons appear to the right. 2. Click the **+** icon. A popup form opens. 3. Enter a **Name** for the set. 4. Click **Save**. The popup closes and the page reloads with your new, empty set selected, ready for you to add phases. ::: tip The other icon opens the existing phase set record, where you can rename it or make it inactive. ::: A phase set carries nothing but its name. Everything a phase needs — its name, its order, the set it belongs to — lives on the phase itself. ## Adding phases **From the column header:** right-click the column header row and select **Add New Line**. **From an existing row:** right-click any phase row and select **Add New Line**. The new row is inserted above the row you clicked. **From the toolbar:** select a row first, then click **Add**. The new row is inserted above the selected row. The button has no effect if no row is selected. After adding a row: 1. Type the phase **Name**. 2. Press **Tab** to move to **Sort Order**, or click elsewhere on the grid to confirm the value. 3. Enter the **Sort Order** — see below. 4. Save. Don't press **Escape** while editing a cell: it cancels your entry. Use Tab, or click elsewhere, to confirm. ## Sort order **Sort Order is what controls the order phases appear in — everywhere.** On the Manage Phases grid, in the Phase column on an estimating worksheet, and in every Phase dropdown. Phases are never sorted alphabetically. That is deliberate, because phase names don't sort usefully. `Phase 10` would come before `Phase 2`, and a name like `Phase 3 Building 25` has no natural order at all. Give each phase a number and leave gaps — 10, 20, 30 rather than 1, 2, 3 — so you can insert a phase between two existing ones later without renumbering the whole set. A phase left without a Sort Order sorts as though it were 0, which puts it first. Set the number rather than leaving it blank. ::: tip Reordering Sort Order is a number you type, not something the grid infers. Clicking a column header re-sorts the view you're looking at but doesn't change any stored value, and there is no drag-to-reorder — change the order by editing the numbers and saving. ::: ## Editing a phase Click the cell you want to change, type the new value, and press Tab or click elsewhere to confirm. Then save. Renaming a phase is safe. Estimate lines and transaction lines point at the phase record, so a rename flows through everywhere it appears. ## Retiring a phase **Phases cannot be deleted, by design.** A phase is stamped onto estimate lines and onto purchase order, sales order, bill, expense and journal lines, so deleting one would orphan every line that referenced it. There is no Delete Line option on this page, and the keyboard shortcut is refused too. Retire a phase by making it **inactive** instead. Inactivation is done on the phase record, not on this grid: 1. Open the phase record — the quickest route is NetSuite's global search on the phase name. 2. Tick **Inactive** and save. 3. Back on the Manage Phases page, tick **Show Inactive** to confirm: the phase reappears with the Inactive column ticked. An inactive phase can no longer be selected on new estimate lines or transactions, and it disappears from the Phase column's dropdowns. Lines that already carry it keep it. Reactivate the phase at any time to bring it back. ::: warning Inactivating a phase does not clear it from lines that use it Estimate lines and transaction lines that already carry a retired phase keep it, which is what you want — historical cost stays attributed. But because a retired phase is no longer selectable, the Phase column on those worksheets treats those lines as having no phase for grouping purposes. Retire a phase once its work is complete, not part way through. ::: ## Saving changes Changes on this page are not saved automatically: 1. Click **Save** in the toolbar at the bottom of the page. 2. A confirmation message appears. Click **OK**. 3. The grid reloads with your saved data, and any new phases show their assigned ID numbers. Save often when making several changes, rather than making them all and saving once. ## What success looks like * The Phase Set dropdown lists a set for each group of phases you need. * Selecting a set shows its phases in **Sort Order** sequence, not alphabetical order. * Every phase has a name and a sort order. * The set is immediately available to nominate on a project or a development. ## Gotchas * **Nothing ships.** There are no phase sets and no phases out of the box — you create the ones your business uses. * **Create the sets before ticking Enable Phases**, or new projects can't be saved. See the callout above. * **There is no delete.** Retire a phase by making it inactive on the phase record. Deletion isn't offered because a phase in use is stamped on lines that would be orphaned by it. * **Sort Order, not the name, decides the order.** A phase with no sort order sorts first. * **Don't press Escape while editing a cell** — it cancels your entry. * **Phases have no hierarchy.** The toolbar's Add Child, Indent and Outdent buttons are shared with the cost centre grid and do nothing useful here. * **A phase belongs to exactly one set.** To use the same phase name on two communities with different vocabularies, create the phase in each set. ## Related * [Using phases on a project](./use-phases) — turning phases on, and what a phased worksheet looks like * [Managing cost centres](./manage-cost-centres) — the sibling concept, and the page this one is modelled on * [Set up a development](./set-up-a-development) — nominating a phase set for a whole development * [Multi-project billing](../contracts-billing/multi-project-billing) — phases across a community of lots * [Custom records reference](../reference/custom-records) --- --- url: >- https://fullclarity.help/project-financials/how-to/prepare-data-for-migration.md --- # Preparing your data for migration This page explains what you need to prepare so your existing projects and their financials appear correctly in FullClarity from day one. Read it at the very start of your implementation — the decisions and data preparation it describes often take longer than expected, so it pays to begin early. It's written for the people who own your project financials together with your NetSuite administrator. \[\[toc]] ## What a migration involves A FullClarity migration has several parts. Depending on your situation you may need all of them or only some: * **Cost centres** — the structure everything else depends on. Do this first. * **Projects** — set up with the fields FullClarity needs. * **Estimates, contracts and schedules of values** — your current commercial setup for each project. * **Historical costs** — your existing project costs, so job cost reporting is complete from the outset. * **Existing claims and variations** — in-progress billing, recreated so its history is preserved. The sections below work through each part. Some are marked *more detail coming shortly* — we're expanding this guide over the next few days, but you can begin on the parts that are complete now, starting with cost centres. ## Before anything else: define your cost centres The single most important prerequisite is your **cost-centre structure**. You can't prepare most of your migration data until it's decided. Most customers take the move to FullClarity as the opportunity to redesign their cost centres, because NetSuite had no equivalent grouping before. That makes this a genuine piece of work rather than a quick copy of what you had — so start it early. You can have **more than one set of cost centres**. What matters is that each **project is assigned to one cost-centre set**, so every cost on that project draws its cost category from that set. ::: tip Start this first Defining cost centres is usually the longest part of getting ready. Begin it before anything else — most of the steps below depend on it. ::: ## Your projects Your projects need to exist in NetSuite with the fields FullClarity relies on — in particular each project's **Billing Type** and **Cost Centre**. *More detail on preparing and loading your project list is coming shortly.* ## Estimates Your project estimates can be loaded from a spreadsheet. *More detail coming shortly.* ## Contracts A contract is set up once its estimate has been created. *More detail coming shortly.* ## Schedule of values A schedule of values is set up against the contract, and can be loaded from a spreadsheet. *More detail coming shortly.* ## Historical costs This is usually the largest part of preparing your data. The goal is to make sure your existing project costs carry a **project** and a **cost category**, so each project's job cost reporting is complete — not just the costs entered after go-live. First, decide **how far back to go**: either all transactions for a period of time (this can span several years), or a specific set of projects and all the transactions belonging to them. How you bring the costs in depends on your situation. ### If you already use NetSuite Here we update your existing historical transactions to add the project and cost category. To do that, give us a spreadsheet with **one row per transaction line** you want migrated, containing: * **Transaction internal ID** (required) — identifies the transaction * **Line number** (required) — identifies the line on that transaction * **Project** (required) — the project the line should be allocated to * **Cost category** (required) — must be one that belongs to that project's cost-centre set * **Any other fields** that need updating (optional) Because most customers are also redesigning their cost centres, this is a *mapping* exercise: for each line you decide the project and the new cost category it should carry, rather than copying an existing value. Include the cost transactions that feed your job cost reporting: * Purchase orders * Vendor bills * Bill credits * Item receipts * Journal entries * Credit card charges * Expense reports / claims ::: warning Non-standard cost transactions If you initiate project costs through other transaction types — for example, a sales order used to commit inventory to a project — flag these to your FullClarity consultant. They can still be migrated, but they need to be handled separately from the list above. ::: ### Opening balances (if you're not migrating every transaction) If you'd rather not tag every historical transaction — for example you're new to NetSuite, or you only need each project's starting position — you can establish costs with a **balanced journal**. This assumes you've already brought your opening balances into NetSuite in the usual way (a journal that sets the opening balances for the period). Those entries won't carry FullClarity's project and cost-category detail. To add it **without changing your balance sheet**, post a second "in and out" journal: * **Credit** the account — for example, work in progress — for the balance as a **single line, with no project or cost-category detail**, exactly as it appears in your opening-balance journal. * **Debit** the same account across **multiple lines**, each carrying a **project** and **cost category**, that together add back to that same balance. Because the debit and the credit are to the **same account**, the journal nets to zero and has **no effect on your balance sheet**. But because only the debit lines carry the project and cost category, those amounts now show up in your FullClarity job cost reports and project reporting. Each segmented debit line needs just three things: * **Project** * **Cost category** * **The amount** To get reporting across each project's *whole* life — not only its opening position — you can repeat this for each prior accounting period. ## Existing claims and variations If you have claims or variations already in progress, these are recreated so their billing history is preserved. *More detail coming shortly.* ## What we need from you, and what happens next Your job is to make the decisions above and prepare the data — defining your cost centres, mapping each cost to the correct project and to a cost category from the right set, and (where relevant) preparing the spreadsheets or journals. Once you hand that over, the data gets loaded into NetSuite for you. Where a spreadsheet is involved it contains everything needed to do this, so your own NetSuite administrator can also load it (for example, via a CSV import) if you'd prefer to handle it in-house. ## Related * [Manage cost centres](/project-financials/how-to/manage-cost-centres) * [Create a project](/project-financials/how-to/create-a-project) * [Install and configure](/project-financials/install-configure) --- --- url: 'https://fullclarity.help/project-financials/how-to/set-up-a-development.md' --- # Set up a development Define a property development as a group of lots that share a small set of pricing templates, generate the lots in bulk, then turn each lot into its own project ready for estimating and billing. \[\[toc]] ## When to use this Use a development when you're delivering many similar dwellings on one site — a residential estate, a townhouse block, a staged land release — and the lots are built from a handful of repeated designs rather than being individually designed. The point of a development is that you price the *design* once and reuse it. You set up a Plan for each design, generate as many Lots as the site has, point each lot at the plan it's being built to, and the system creates a project and estimate per lot from that plan. Without a development you'd be building every lot's estimate from scratch. A development is also the foundation for [multi-project billing](../contracts-billing/multi-project-billing), which bills all the lots as a single community on one consolidated invoice. You don't have to use multi-project billing — a development is useful on its own — but you do need a development before you can use it. ## The three records | Record | What it is | Where you'll find it | |---|---|---| | **Development** | The site as a whole. Carries the location and the set of plans available on it. | FullClarity → Project Financials → Developments | | **Plan** | A pricing and cost template for one dwelling design. Holds the cost, sale price and price range for that design, carries the estimate that prices it, and can hold its own drawings and documents. A plan is a standalone record — see [Create a plan](./create-a-plan). | FullClarity → Project Financials → Plans, and selected onto a development's **Plans** field | | **Lot** | One individual lot or unit on the site. Has an address, a default plan, and — once created — a link to its own project. | Development → Lots | ::: tip Your site may call these something else Development, Plan and Lot are all renameable. If your configuration calls them Estate, Design and Unit, that's what the buttons and subtabs will say. This page uses the default names — substitute your own as you read. See [Customise terminology](./customise-terminology/). ::: ## Prerequisites * Project Financials installed and configured — see [Install & configure](../install-configure) * The dwelling designs for the site decided, with a cost and sale price for each * The lot numbering for the site known (how many lots, and what they're numbered from) * Permission to create projects and contracts ## Walkthrough ### 1. Create the development 1. Go to **FullClarity → Project Financials → Developments** and click **New**. 2. Give it a name — usually the estate or site name — and set the **Location**. 3. Optionally set a **Phase Set** — the set of delivery phases the projects on this site use. Leave it blank if this development doesn't use phases. See [Phases on a development](#phases-on-a-development) below. 4. Save. ### 2. Add a plan for each design Create a plan for each dwelling design on the site — see **[Create a plan](./create-a-plan)** for the full walkthrough, including the estimate each plan needs. Once the plans exist, attach them to this development: open the development's **Plans** field and select every design the site offers. It's a multi-select, so a development can carry as many designs as you build, and the same plan can be offered on more than one development. ::: warning A plan needs an estimate before it can price a lot A plan's cost and sale price describe the design, but what actually gets copied onto each lot is the plan's **estimate**. Build the estimate for every plan before you create lot projects, or the lots will come through unpriced. See [Create a plan](./create-a-plan). ::: ### 3. Generate the lots 1. On the development, click **Create Lots**. 2. Fill in the generator: * **Prefix** — what each lot's name starts with (e.g. `Lot `). * **Start Number** — the first lot number. * **Number of Lots** — how many to generate. * **Default Plan** — the plan to assign to all of them. 3. Click **Create**. The lots are generated and appear in the list below, numbered sequentially from your start number. 4. Adjust individual lots in that list — set each one's **Address**, correct its **Plan** where a lot is being built to a different design, and set a **Start Date** if you have one. You can run the generator more than once — to add a later stage of the estate, for example — and you can add a single lot by hand rather than generating a batch. ### 4. Create the lot projects This is the step that turns lots into real projects you can estimate and bill. 1. Open the **head project** for the development — the project that represents the site as a whole, with the development selected on it. 2. Click **Create Lot Projects**. 3. Tick the lots you want to create projects for. You don't have to do all of them at once — it's normal to create projects stage by stage as the site is released. 4. Decide whether to tick **Create Contracts?**: * **Ticked** — each lot project also gets a contract, built from its plan. This is what you want if you're billing the lots. * **Unticked** — projects and estimates only. Add contracts later. 5. Click **Create**. Each selected lot gets its own project, with the plan's estimate copied onto it, and the lot record is linked to that project so you can navigate between them. ::: tip Putting a batch of lots into a phase If the head project uses phases, this popup carries a **Phase** field in its header and a **Phase** column on each lot line. Set the header once to put the whole selection into one release; a phase chosen on an individual line always wins over the header. Each lot then gets that phase on its own project record and on every estimate line copied from its plan. See [Using phases on a project](./use-phases#phases-on-lots). ::: ::: tip Creation runs in the background Beyond a couple of lots, creation is queued and runs in the background rather than making you wait. You'll get a confirmation that it's been queued, and the lot projects appear as they're built. On a large release this can take a few minutes — refresh the development to watch the **Project** column fill in. ::: ## Phases on a development A development can nominate a **Phase Set** — the delivery phases (releases, blocks of units, stages of works) that the projects on this site are grouped by. When it does, the development *decides* the phase configuration for the projects in it, so a site's projects can't drift onto different phase vocabularies. Select a development on a project and: * **The development has a phase set** — the project's **Use Phases** is ticked and its **Phase Set** is filled in from the development, and both are locked so they can't be changed on the project. * **The development has no phase set** — the project's **Use Phases** is unticked and locked. Phases can't be used under a development that nominates no set; put a phase set on the development to change that. * **Clear the development from the project** — both fields become editable again, keeping the values they already had. The lock applies to the head project. Lots take their phase configuration from their head project, and keeping a lot's **Use Phases** unlockable is deliberate — it's the step you need if the site's phase set ever has to change. Phase sets are created on the Manage Phases page, and nothing ships out of the box — see [Managing phases](./manage-phases). ## What success looks like * The development lists a plan per design and a lot per dwelling. * Every lot has an address and the correct plan against it. * After creating lot projects, each selected lot's **Project** field is populated, and opening that project shows an estimate carrying the plan's figures. * If you ticked **Create Contracts?**, each lot project has a contract with a value derived from its estimate. ## Gotchas * **Build each plan's estimate before creating lot projects.** The estimate is what gets copied to the lot. A plan with a cost and sale price but no estimate produces an unpriced lot project, and fixing it afterwards means estimating each lot individually — exactly what the development was meant to avoid. * **The head project needs the development selected on it.** The **Create Lot Projects** button only appears on a project that has a development against it. If you can't see the button, that link is missing. * **The button is also hidden on an inactive project.** If the head project has been made inactive, reactivate it before creating lots. * **Changing a lot's plan after its project exists doesn't re-price the project.** The plan's estimate is copied at creation, not kept in sync. If a lot changes design after its project is built, amend that lot project's estimate directly. * **Correct the plan on each lot before you create its project, not after.** Generating a batch assigns the same default plan to all of them, and it's easy to create projects before fixing the handful being built to a different design. * **Lot names come from the prefix and start number, and aren't renumbered.** Generating a second batch continues from where you tell it to start — check the existing lots first so you don't collide with or skip numbers. ## Related * [Multi-project billing](../contracts-billing/multi-project-billing) — bill all the lots as one community on a single invoice * [Create a plan](./create-a-plan) — the pricing template each lot is built from * [Create an estimate](./estimating/create-an-estimate) — building the estimate a plan needs * [Set up billing schedules](../contracts-billing/set-up-billing-schedules) — the contract and stage structure lot billing is built on * [Using phases on a project](./use-phases) — grouping a site's cost by release * [Managing phases](./manage-phases) — creating the phase set a development nominates * [Customise terminology](./customise-terminology/) — renaming Development, Plan and Lot * [Custom records reference](../reference/custom-records) --- --- url: 'https://fullclarity.help/project-financials/how-to/use-phases.md' --- # Using phases on a project Turn phases on for a project and its estimating worksheets gain a **Phase** column: cost categories group under the phase they belong to, each phase folds up to its own total, and every estimate line can be attributed to a phase. Phases are how you report cost by release, stage of works or block of units without splitting a project up. \[\[toc]] Phases are additive. When a project doesn't use them, nothing changes — the worksheets, the columns and every total are exactly what they were. ## When to use this Use phases when one project delivers work in identifiable releases and you need cost reported per release. A builder delivering a community of 40 to 500 units in phases is the typical case: the community is one project (or one head project and its lots), and cost has to sum into the phase the work belongs to. Phases are per project, so you can run them on one community and leave the rest of the business untouched. ## Prerequisites * At least one **phase set**, with its phases, created on the Manage Phases page — see [Managing phases](./manage-phases). Nothing ships, so this is a real prerequisite, not a formality. * Permission to edit the project record * NetSuite administrator access if you also want to change the general preference ## Turning phases on There are two switches, and only one of them is the gate. **The general preference sets the default.** Tick **Enable Phases** in FullClarity → Project Financials → General Preferences, in the **Estimate and Forecast** group. Its only job is to tick **Use Phases** on each project as it's created. It changes nothing on existing projects, and it doesn't switch phases on anywhere by itself. **The project checkbox is the gate.** On the project record, in the FullClarity configuration section: * **Use Phases** — tick this to show phases on this project's estimating worksheets. This is the setting the worksheets read. * **Phase Set** (required when Use Phases is ticked) — the set of phases available on this project. * **Phase** — optional. The phase this project itself belongs to, chosen from the set nominated above. Nothing in the app reads it; it's there so you can search and report on, for example, every lot in phase 3. You can tick **Use Phases** on any project whether or not the general preference is on. A business running phases on one community out of twenty doesn't have to turn them on for everybody. ::: warning A project using phases must nominate a phase set Saving with **Use Phases** ticked and **Phase Set** empty is refused. Without a set the Phase column would contain nothing but `(No phase)`, which is indistinguishable from a broken feature. This is also why the phase sets have to exist before you tick the general preference — see [Managing phases](./manage-phases). ::: ::: tip Enabling phases changes no existing data Ticking **Use Phases** on a live project mutates nothing. Existing estimate lines have no phase, so they collect under a **`(No phase)`** group with its own totals, sorted last. There's no backfill and nothing to migrate — assign phases as you go. ::: ## Developments govern the projects under them A **development** can nominate a **Phase Set** of its own. When it does, it decides the phase configuration for the projects in it, so a community's projects can't drift apart. Select a development on a project and: * **The development has a phase set** — the project's **Use Phases** is ticked and its **Phase Set** is set to the development's, and both are locked so they can't be edited on the project. * **The development has no phase set** — the project's **Use Phases** is unticked and locked. Phases can't be used under a development that doesn't nominate a set. To change that, put a phase set on the development. * **Clear the development** — both fields become editable again, keeping the values they already had. The lock applies to the project you would create the lots from, not to the lots themselves — a lot's phase configuration comes from its head project instead (see below). ## What a phased worksheet looks like With **Use Phases** on, **Phase** becomes a collapsible column immediately to the left of Category — always that position, in every estimating worksheet. Cost categories then repeat beneath each phase, so a phase folds up to show its own total while staying visually distinct from a category. ``` Phase Category / Line Item Amount ──────────────────────────────────────────────────────────────────────────── ▾ Phase 1 88,000.00 ▾ PW.001 Preliminaries 3,900.00 PW.001.01 Site Setup PW General Labour 2,400.00 PW.001.02 Permits PW General Allow. 1,500.00 ▸ PW.002 Siteworks 3,900.00 ▸ Phase 2 45,000.00 ▸ (No phase) 12,400.00 ``` Points worth knowing: * The phases offered are the ones in **the project's own phase set**, not every phase in the account — the same way a worksheet's categories come from its cost centre. * Phase rows appear in **Sort Order** sequence, with **`(No phase)` always last**. * **A category appears under a phase only where that phase actually has lines in it**, or in a category beneath it. Categories don't repeat into every phase, so a phase carrying a single line shows a single branch rather than the whole category tree at zero. * A category holding no lines anywhere — part of the all-categories scaffold an estimate can be created with — appears once, under `(No phase)`, and only when the estimate's **Keep All Cost Categories** box is ticked. That box records whether all cost categories were pulled in when the estimate was created; it's shown read-only on the estimate. * Estimate **expense** lines carry no phase, so they always appear under `(No phase)`. Phases apply to the Estimate, Estimate Collection, Advanced Estimate, Advanced Collection and Variation worksheets. ::: warning Phases can't be assigned on an estimate template or a plan estimate A template or plan estimate belongs to no project, so it nominates no phase set and has no phases to offer — the Add/Edit Line dialog shows no Phase field on one. If the **Enable Phases** preference is on, a template does show the Phase column, with every line under `(No phase)`. Build a phased estimate on the project itself, and set the phases there rather than on the template it came from. ::: ## Setting a phase on an estimate line Phase is set **per line**, like cost category. It's never mandatory, and it isn't inherited from the estimate header or from the lot. * **A new line inherits the phase of the row you added it under.** Add a line under Phase 1 → Concrete and it arrives on Phase 1. * **Re-phase a line through the Add/Edit Line dialog**, which carries a **Phase** field defaulted from the row — the same way you change a line's category. The line's Phase field also shows a phase that is no longer selectable, marked as the existing value, so editing an unrelated field on the line never quietly clears it. * **A sub-item's phase follows its parent line.** It's shown but not freely editable, so the grid's per-phase totals and the stored data can never disagree. Changing a parent's phase cascades to its children. * After adding or re-phasing a line, the grid shows it under its new phase immediately and settles to the stored position on the next refresh. ## Retiring a category under one phase Category rows can be made inactive from the worksheet — tick **Show Inactives** and tick the row's **Inactive** box. On a phased worksheet that decision is **per phase**. Retiring a category under Phase 1 leaves the same category active under Phase 2, and only Phase 1's total drops. That's the point: a scope dropped from one release is still live in another. ::: warning Retiring a category takes its cost out of that phase's total Inactivating a category row excludes it and everything beneath it from that phase's subtotal, so a single tick on a parent row can move a large number the row itself shows no money for. Untick it to bring the cost straight back. ::: With **Use Phases** off, a worksheet has no phases to distinguish, so the same tick applies to the category across the whole estimate. ## Phases on lots Phases carry through the lot-creation flow, so you can put a batch of lots into a phase in one action. On the head project, click **Create Lot Projects**. When the head project uses phases, the popup gains: * A **Phase** field in the header, above the list. It applies to every lot in the selection that has no phase of its own, and fills the phase down onto the lines so you can see it land. * A **Phase** column on each lot line. A phase you set on a line always wins over the header, whenever you change the header. Both offer the head project's phase set, in Sort Order. Leave both empty and the lots are created without a phase. For each lot created with a phase: * Every estimate line copied from the plan onto that lot carries the phase. * The lot project's own **Phase** field is set to it, so "all the phase 3 lots" is a single search. * The lot project inherits the head's **Use Phases** setting and **Phase Set**. With phases off, the popup is exactly the form it was — no Phase field, no Phase column. ## Rules that keep a community's phases consistent Three rules apply when phases are used across a head project and its lots. Each is enforced on save, with a message telling you what to do. 1. **A project using phases must nominate a phase set.** *Select a Phase Set, or untick Use Phases.* 2. **A lot must use its head project's phase set.** A lot phased from a different set would render as `(No phase)` in the head's collection worksheet, silently, so the mismatch is refused instead: *Select that set, or untick Use Phases.* A head that doesn't use phases groups nothing by phase and so constrains nothing — a lot may use phases while its head does not. 3. **A head project's phase set can't be changed while its lots still use a different one.** The save is refused with a message naming how many projects are in the way. Rule 3 doesn't trap you. The way through is: 1. **Untick Use Phases** on each lot. Clearing the lot's Phase Set is *not* a substitute — rule 1 refuses that, and a lot only counts against rule 3 while Use Phases is ticked. 2. Change the head project's Phase Set. 3. Re-tick **Use Phases** on each lot, now on the new set. You need edit rights on every lot to do this, and in a three-level hierarchy the procedure works bottom-up. ## Where phase reaches, and where it doesn't Phase is a real reporting dimension on purchase, sale, expense, expense report and journal lines, as well as on estimate lines. What actually populates it is narrower than where the column exists: | Where | Does phase arrive automatically? | |---|---| | Estimate lines | Yes — set per line on the worksheet, or copied in by lot creation | | Purchase orders generated from estimate lines | Yes — the source estimate line's phase, including the **Add Estimate Lines** picker on a purchase order and bulk PO creation | | Sales orders generated from a contract | Yes — the source estimate line's phase | | Vendor bills, journals, claims, capitalisation entries | **No.** The Phase column is there but nothing fills it in | | Time entries | **No.** Labour time carries no phase | The practical consequence: **budget-versus-actual by phase is not yet a single comparison.** Committed cost on purchase orders and revenue on sales orders carry the phase; the rest of the actuals don't, so don't assume phase reporting covers actuals just because the dimension exists on those records. ::: warning Turning phases off doesn't hide phase everywhere Neither the general preference nor the project checkbox hides the **Phase** column on purchase order, vendor bill and invoice lines. Whether a column exists on a transaction is account-level configuration and can't be switched per project. Once phases are configured in the account, those columns exist on every project's transactions. ::: ## What success looks like * With **Use Phases** off, every worksheet renders exactly as it did before, with no Phase column. * With it on and a set nominated, **Phase** appears immediately left of Category, and phase rows are listed in Sort Order with `(No phase)` last. * Folding a phase shows that phase's total, and the phase subtotals add up to the estimate total. * A line added under a phase stays under that phase after a refresh. * A purchase order generated from a phased estimate line carries that phase on its line. * Creating lots with a header phase gives every one of them that phase, on the lot project and on its copied estimate lines. ## Gotchas * **A phase set is mandatory once Use Phases is ticked**, and nothing ships. Build the sets first — see [Managing phases](./manage-phases). * **Changing the general preference doesn't change existing projects.** It only supplies the default for projects created after the change. * **Importing an estimate doesn't carry the line phases across.** Copying an estimate into another project brings the lines but not their phases, so re-phase them after the import. Lot creation is not affected — it writes the phase you nominated in the popup. * **Sort Order, not the phase name, decides the order** phases appear in. * **Estimate expense lines can't be phased**, so they always sit under `(No phase)`. * **Phase, stage and billing stage are three different things.** Phase is a delivery grouping; stage is the estimating-and-progress classification; a billing stage is a contract milestone with a percentage against it. * **Retiring a phase is done on the phase record, not on the Manage Phases grid**, and a phase can't be deleted. ## Related * [Managing phases](./manage-phases) — creating phase sets and the phases in them * [Managing cost centres](./manage-cost-centres) — the category structure phases group alongside * [Add lines to an estimate](./estimating/add-lines) — the Add/Edit Line dialog the Phase field sits on * [Set up a development](./set-up-a-development) — nominating a phase set for a whole development, and creating lot projects * [Multi-project billing](../contracts-billing/multi-project-billing) — phases across a community of lots * [Configuration record fields](../reference/configuration-record-fields) — where the Enable Phases preference is stored --- --- url: 'https://fullclarity.help/project-financials/install-configure.md' --- # Install & configure Project Financials \[\[toc]] ## Module requirements Project Financials requires a number of standard NetSuite features. Enable these via **Setup > Company > Enable Features** before installation. **Accounting tab:** * Accounting (basic) **Transactions tab:** * Estimates * Sales Orders * Custom Transactions **Items & Inventory tab:** * Multiple Units of Measure **Employees tab:** * Time Tracking * Expense Reports **Lists tab:** * Projects (also called "Jobs" in older NetSuite UI) **SuiteCloud tab:** * SuiteBuilder → Custom Records, Advanced PDF/HTML Templates * SuiteScript → Client SuiteScript, Server SuiteScript * SuiteFlow → SuiteFlow * SuiteGL → Custom GL Lines, Custom Segments * Manage Authentication → Token-based Authentication **CRM tab:** * CRM (basic) ::: warning OneWorld If your account uses subsidiaries, also enable **Subsidiaries**. Multi-currency support requires **Multiple Currencies** under the Company tab. ::: ## SuiteApp prerequisites In addition to NetSuite features, two FullClarity SuiteApps must be installed **before** Project Financials: 1. **FullClarity Code Library** — shared foundation for all FullClarity apps. Provides the TreeGrid worksheets, transaction-classification model, permission framework and subsidiary mirroring. 2. **FullClarity Portal** — required for the Connect integration, customer claim portal, vendor bid requests, secure cloud document storage and any external-access feature. See [Portal install & configure](/portal/install-configure). ::: warning Install order Install in this order: **Portal → Code Library → Project Financials.** Skipping Portal causes external-access features (Connect, customer claims, vendor quotes) to fail silently. ::: The following SuiteApps are optional and add capabilities to Project Financials when installed: | SuiteApp | What it adds | |---|---| | File Storage | Document attachments on projects, estimates and claims | | Timeline (Gantt) | Project scheduling linked to estimate tasks | | Certified Documents | Insurance and compliance document tracking per project | | Retainage | AR / AP retention withholding and claims | | Procore Integration | Project sync with Procore | ## Install the SuiteApp The SuiteApp is installed via the NetSuite SuiteApp Control Center. The deployment installs all files and custom objects. ## Initial data requirements After installation, populate these records in the following order before using the app: 1. **Configuration record** — see [Configuration records](#configuration-records) below 2. **Billing stages** — *FullClarity > Project Financials > Billing Stages > New* (one set per default billing type you use) 3. **Cost centres** — see [Manage cost centres](/project-financials/how-to/manage-cost-centres) 4. **Default sales items** — standard NetSuite items used as the default revenue item for new projects; created via *Lists > Accounting > Items > New* 5. **Phase sets** — only if you plan to use phases. Nothing ships, and a phase set must exist before phases can be enabled. See [Managing phases](/project-financials/how-to/manage-phases) ::: warning Create phase sets before enabling phases The **Enable Phases** preference ticks *Use Phases* on every newly created project, and a project using phases must nominate a phase set. Turning the preference on before any phase set exists means no new project can be saved. Build at least one set first — see [Managing phases](/project-financials/how-to/manage-phases). ::: ## Configuration records A configuration record is required for Project Financials to function. If your account has multiple subsidiaries, create one configuration record per subsidiary. To create a configuration record: **FullClarity > Project Financials > Configuration > New**. **Key fields:** | Field | Description | |---|---| | Subsidiary | The subsidiary the configuration applies to. Single-subsidiary accounts: select "Parent". | | Default Billing Type | Billing type populated by default when a project is created (Stage / Progress / Internal / T\&M / Drawdown / Inventory / T\&M Cost Type / Capital) | | Markup Percent | Default markup percentage applied to new projects | | Bid Invite Email Template / Bid Reminder Email Template | Email templates used when inviting vendors to bid and when reminding them. See [Configuration record fields](./reference/configuration-record-fields) for the full set of bid settings | | Default Cost Centre Set | Cost centre structure used for new projects on this subsidiary | ::: tip Defaults Default for new projects is typically: Billing Type = Progress, Markup = 25%, Cost Centre Set = Master. Override per project as needed. ::: ## Permissions After install, use the **FullClarity → Project Financials → Assign Permissions** Suitelet to grant Project Financials access into your customer-built roles (Project Manager, Contract Administrator, etc.) rather than asking users to switch into the bundled FC role. The Suitelet handles the underlying NetSuite plumbing — pick a level (None / View / Create / Edit / Full) against each of thirteen feature columns and submit. See [Permissions reference](./reference/permissions) for the model, the click-path, and the full breakdown of what the Suitelet writes onto a role. ## Verify your installation After installation and configuration, verify by: 1. Navigating to **FullClarity > Project Financials** — the menu should appear 2. Opening a project record — the FullClarity Project Financials subtab should be visible 3. Following the [Quick start](/project-financials/quick-start) to set up your first project ## Troubleshooting * **Menu doesn't appear:** confirm you have an active role with FullClarity Project Financials access * **Configuration error on project save:** confirm a configuration record exists for the project's subsidiary * **Portal registration error:** complete [Portal account registration](/portal/install-configure#register-the-account) before installing Project Financials * **Custom Transactions missing:** check **Setup > Company > Enable Features > SuiteCloud > Custom Transactions** is enabled * **TreeGrid worksheets don't load:** the Code Library SuiteApp serves the TreeGrid runtime; confirm Code Library is installed and at the version Project Financials requires For other issues, email support@fullclarity.com. --- --- url: 'https://fullclarity.help/project-financials/quick-start.md' --- # Project Financials quick start This page walks you from a freshly installed Project Financials to your first estimate. Allow about 30 minutes. \[\[toc]] ## Before you start * Project Financials installed — see [Install & configure](/project-financials/install-configure) * A configuration record created for the subsidiary you'll use * At least one billing stage and one cost centre set up (you'll be prompted to create these as you go if not) * A customer record to associate with the new project ## 1. Create a project Start by creating a project record. The project anchors all FullClarity activity for the job. ➡️ Detailed walkthrough: [Create a project](/project-financials/how-to/create-a-project) ## 2. Set up your cost centre structure Cost centres are how Project Financials organises work-breakdown. They show up in estimates, budgets, forecasts and revenue recognition. ➡️ Detailed walkthrough: [Manage cost centres](/project-financials/how-to/manage-cost-centres) ## 3. Create your first estimate With the project and cost centres in place, create an estimate, add lines, and mark up your costs. ➡️ Detailed walkthrough: [Create an estimate](/project-financials/how-to/estimating/create-an-estimate) ## What's next * **Win the bid:** convert your estimate to a contract (covered in Phase 2 docs) * **Bring on subcontractors:** [Subcontracts](/subcontracts) * **Order materials:** [Create purchase orders from the estimate](/project-financials/how-to/estimating/create-pos) * **Building many similar homes?** Price each design once as a [Plan](/project-financials/how-to/create-a-plan), then generate a project per lot from a [Development](/project-financials/how-to/set-up-a-development) ## Need help * **Customise terminology** — rename Estimate/Budget/Forecast columns to match your business: [Customise terminology](/project-financials/how-to/customise-terminology) * **Import an existing estimate** — bring in costs from a spreadsheet: [Import from spreadsheet](/project-financials/how-to/estimating/import-from-spreadsheet) * **Contact support:** support@fullclarity.com --- --- url: 'https://fullclarity.help/project-financials/reference.md' --- # Reference Project Financials reference material — fields, permissions, custom records, and column glossary. Use this section to look up something specific rather than to learn a workflow. \[\[toc]] ## In this section * [Configuration record fields](/project-financials/reference/configuration-record-fields) — every field on the per-subsidiary Configuration record, and what it controls * [Permissions](/project-financials/reference/permissions) — roles and access (currently being rewritten — see page warning) * [Custom records](/project-financials/reference/custom-records) — the records Project Financials adds to NetSuite, what each one represents, where to find it * [Column glossary](/project-financials/reference/column-glossary) — the columns you'll see on Estimate, Budget, Forecast and Revenue Recognition worksheets, what each one means ## See also * [How to → Customise terminology](/project-financials/how-to/customise-terminology) — rename or hide columns on each worksheet * [Install & configure](/project-financials/install-configure) — first-time setup --- --- url: 'https://fullclarity.help/project-financials/reference/column-glossary.md' --- # Column glossary Every Project Financials worksheet — Estimate, Budget, Forecast, Revenue Recognition — shows a set of columns with named labels. This page explains what each one means and (where applicable) how it's calculated. To rename or hide any of these columns on your worksheets, see [Customise terminology](../how-to/customise-terminology/). \[\[toc]] ## Estimate columns These columns appear on the Estimate worksheet. Where calculated, the formula is shown in the right-hand column. Some columns are hidden by default — see [Customise terminology → Estimate columns](../how-to/customise-terminology/estimate-columns). ### Always-available columns | Column | What it shows | Calculation | |---|---|---| | Index | Auto-generated row number | — | | Line Ref | Internal ID of the estimate line | — | | Phase | Delivery phase the line belongs to. Only present when the project has **Use Phases** ticked, and always immediately left of Category. It is the grouping column: categories sit beneath the phase they have lines in, and phase rows are ordered by the phase's Sort Order with `(No phase)` last. Set per line via the Add/Edit Line dialog — see [Using phases on a project](../how-to/use-phases) | User-entered | | Category | Cost category from the project's cost centre | User-entered | | Stage | Billing or project stage for the line (Stage billing) | User-entered | | Cost Type | Secondary classification (e.g. Materials, Labour) | User-entered | | Allowance Type | Standard / Prime Cost / Provisional Sum | User-entered | | Item Name | NetSuite item | User-entered | | Description | Line description (defaults from item) | User-entered | | Unit | Unit of measure (defaults from item) | User-entered | | Quantity | Quantity being costed | User-entered | | Rate | Unit cost (defaults from item) | User-entered | | Amt | Base cost amount | Quantity × Rate | | Contingency % | Risk buffer percentage (bidirectional with Contingency $) | User-entered | | Contingency $ | Risk buffer dollar amount (bidirectional with Contingency %) | Subtotal × Contingency % | | Cost $ | Total cost to the builder before margin | Amt + freight + tax + contingency + escalation | | Margin % | Margin as a percentage of selling price (bidirectional with Margin $) | User-entered | | Margin $ | Margin dollar amount (bidirectional with Margin %) | Cost $ × Margin % ÷ (1 − Margin %) | | Net $ | Selling price excluding output tax | Cost $ + Margin $ | | WP Location | Work-package location (a physical area on site) | User-entered | | Applied | Whether the line is included in totals | User-toggle | | Notes | Free-text notes | User-entered | | Quote | Link to a FullClarity Quote record | System-populated | | Supplier | Linked vendor | User or system | | Purchase Order | Link to a NetSuite PO raised against this line | System-populated | | Gross Amt | Gross amount; equals Net $ in US subsidiaries | System-calculated | ### Optional columns (when *Enable Freight, Sales Tax, and Escalation* is on) | Column | What it shows | Calculation | |---|---|---| | Freight % | Freight as a % of Amt | User-entered | | Freight $ | Freight dollar amount | Amt × Freight % | | Sales Tax % | Input sales tax rate applied to (Amt + Freight $) | User-entered | | Sales Tax $ | Input sales tax dollar amount | (Amt + Freight $) × Sales Tax % | | Subtotal | Pre-contingency subtotal | Amt + Freight $ + Sales Tax $ | | Subtotal w/ Contingency | Subtotal plus contingency | Subtotal + Contingency $ | | Escalation % | Price escalation allowance for inflation | User-entered | | Escalation $ | Escalation dollar amount | Subtotal w/ Contingency × Escalation % | | Total Other Costs | Sum of additional costs above the base Amt | Freight + Sales Tax + Contingency + Escalation | ::: tip Margin vs markup Margin is calculated as a percentage of the selling price, not as a markup on cost. A 25% margin on a $100 cost yields a $33.33 margin and a $133.33 net (not $125). Bidirectional entry applies to Freight %/$, Contingency %/$, Escalation %/$, and Margin %/$ — entering either value calculates the other. ::: ## Budget columns The Budget worksheet shares most columns with Estimate but adds budget-vs-actual tracking. All columns are renameable and hideable — see [Customise terminology → Budget columns](../how-to/customise-terminology/budget-columns) for the full list. | Column | What it shows | |---|---| | Actuals to Date | Total spent against the line so far | | Adjusted % Complete | Manually adjusted % complete used for forecasting (overrides the calculated value) | | Adjusted % Override | Toggle indicating the % complete is being manually overridden | | Allowance Type, Category, Stage, Cost Type, Item Name, Description, Unit, Quantity, Rate, Amt, Contingency, Margin, Net $ | Same meaning as on the Estimate worksheet | | Applied | Whether the line is included in totals | | Asset Type | Asset classification (capital projects) | | Commitments | Committed cost on the line (POs and vendor bills against this line) | | Estimated % Complete | System-calculated % complete from actuals against budget | | Forecast Over / (Under) Budget | Variance between forecasted final cost and budgeted cost | | Forecasted Remaining Costs | Projected cost to complete the line | | Fund Type | Fund type allocation (multi-fund projects) | | Gross Amount | Gross amount; equals Net $ in US subsidiaries | | Line Ref | Internal line ID | | Notes | Free-text notes | | Previous % Complete | % complete at the previous forecast snapshot | | Sales Estimate Value | The originating estimate's net value for the line | | Sales Tax %, Sales Tax $, Freight %, Freight $, Escalation %, Escalation $ | Same meaning as on the Estimate worksheet | ## Forecast columns The Forecast worksheet rolls actual cost and committed cost into projected cost-to-complete, with a forecast rate per line. See [Customise terminology → Forecast columns](../how-to/customise-terminology/forecast-columns) for the full renameable list. | Column | What it shows | |---|---| | Actuals to Date | Total spent against the line | | Adjusted % Complete, Adjusted % Override, Estimated % Complete, Previous % Complete | Same meaning as on Budget | | Commitments / Total Committed Costs | Committed cost on the line (POs, vendor bills, contracts) | | Forecast Over / (Under) Budget | Variance between forecasted final cost and budget | | Forecasted Remaining Costs | Projected cost to complete | | Total Cost To Complete | Cost still to be incurred for the line | | Project Budget Total Cost | Budgeted total cost for the line | | Rate (renamed *Forecast Rate*) | Per-unit rate used for the forecast | | Tax, Tax Code, Tax Rate | Tax breakdown for the line | | Supplier, WP Location, Allowance Type, Category, Cost Type, Item Name, Description, Unit, Quantity, Notes | Same meaning as on the Estimate worksheet | | Sales Tax %, Sales Tax $, Freight %, Freight $, Escalation %, Escalation $, Margin %, Margin $, Net $, Contingency %, Contingency $, Amt, Cost $, Gross Amount | Same meaning as on the Estimate worksheet | ## Revenue Recognition columns The Revenue Recognition worksheet shows one row per project per recognition round. Calculated columns show what the system proposes; revised columns let you override before posting. | Column | What it shows | Calculation | |---|---|---| | Job # | NetSuite Job number | — | | Job Name | Project name | — | | Job Status | Status of the project (Active / Complete / Closed) | — | | Subsidiary | Project's subsidiary | — | | Class / Department / Location | Standard NetSuite segments | — | | Total Contract | Total contract value on the project | From the contract | | Budgeted Costs | Estimate / budget total cost | From the budget | | Project Budgeted Costs | Project-rolled budget total | From the project | | Actual Costs | Actual cost to date | YTD actuals | | Invoiced to Date | Total invoiced against the project | YTD invoiced | | Previously Recognised % | Cumulative % recognised in prior periods | From prior recognition rounds | | Previously Recognised Rev $ | Cumulative revenue recognised in prior periods | From prior recognition rounds | | Previously Recognised Cost $ | Cumulative cost recognised in prior periods | From prior recognition rounds | | Calculated % Complete | System-calculated % complete | min(Actual Costs / Budgeted Costs, 100%); forced to 100% if project is complete | | Calculated Rev $ to Recognise | System-proposed revenue for this period | See [the section overview](../revenue-recognition/) for the two basis options | | Calculated Cost $ to Recognise | System-proposed cost for this period | Depends on Advanced Forecasting setting | | Calculated Total Rev $ Recognised This Period | Per-line total revenue across cost categories | Sum of segmented amounts | | Calculated Total Cost $ Recognised This Period | Per-line total cost across cost categories | Sum of segmented amounts | | Revised % Complete | Manual override of the % complete | User-entered | | Revised Rev $ | Manual override of the revenue amount | User-entered | | Revised Cost $ | Manual override of the cost amount | User-entered | | Total Rev $ To Recognise | Final revenue this period after overrides | Revised value (or Calculated if no override) | | Total Cost $ To Recognise | Final cost this period after overrides | Revised value (or Calculated if no override) | | Snapshot | The historical project snapshot used for the calculation | System-populated | | Snapshot Date | Date of the snapshot | System-populated | | Journal | Link to the posted Revenue Recognition transaction | Populated after the batch posts | ## Related * [Customise terminology](../how-to/customise-terminology/) — rename or hide columns on each worksheet * [Custom records](./custom-records) * [Run a monthly batch](../revenue-recognition/run-a-monthly-batch) --- --- url: >- https://fullclarity.help/project-financials/reference/configuration-record-fields.md --- # Configuration record fields The Project Financials Configuration record drives behaviour across estimating, contracts, billing and revenue recognition. One Configuration record per subsidiary — single-subsidiary accounts have one record assigned to *Parent*. To create or edit: **FullClarity → Project Financials → Configuration**. For first-time setup guidance, see [Install & configure](../install-configure#configuration-records). This page is the comprehensive field reference. \[\[toc]] ## Identity | Field | Type | Required | What it controls | |---|---|---|---| | Subsidiary | Select | Yes | The subsidiary this configuration applies to. Single-subsidiary accounts use *Parent*. | | Subsidiary ID | Text | No | Internal copy of the subsidiary's NetSuite ID — used by scripts; do not edit manually. | ## Default values for new projects | Field | Type | What it controls | |---|---|---| | Default Billing Type | Select | Billing type populated by default on new projects (Stage / Progress / Internal / T\&M / Drawdown / Inventory / T\&M Cost Type / Capital) | | Default Cost Center | Select | Default cost centre applied to new projects | | Margin % | Percent | Default margin percentage applied to new estimates and contracts | | Sales Tax Code | Select | Default tax code used on sales transactions raised from claims | | Default Project Form | Select | NetSuite form used when viewing or editing a project | | Default Customer Form | Select | NetSuite form used for customers created from Project Financials flows | | Default Opportunity Form | Select | NetSuite form used for opportunities | | Default Proposal Form | Select | NetSuite form used for proposals | | Default Sales Order Form | Select | NetSuite form used for auto-generated sales orders | | Default Purchase Order Form | Select | NetSuite form used for purchase orders raised from estimates | | Default Inventory Adjustment Form | Select | NetSuite form used for inventory adjustments | | Default Transfer Order Form | Select | NetSuite form used for inventory transfer orders | | Default Stage Invoice Form | Select | NetSuite invoice form used for Stage-billing claims | | Default Progress Invoice Form | Select | NetSuite invoice form used for Progress-billing claims | | Default Credit Memo Form | Select | NetSuite form used for claim credit memos | | Default Time & Materials Contract Form | Select | NetSuite form used for T\&M contracts | | Default Drawdown Contract Form | Select | NetSuite form used for Drawdown contracts | | Create Project Form | Select | NetSuite form opened by the *Create Project* Suitelet | | Default Contact Role | Select | Default role assigned to contacts created from Project Financials flows | | Default Drawdown Facility | Select | Default loan facility for Drawdown projects | ## GL accounts — revenue recognition These accounts feed the revenue recognition GL plug-in and the recognition journal. Set the balance-sheet account into each *Deferred* slot; set the P\&L account into each *Revenue* / *Cost of Sale* slot. | Field | Type | What it controls | |---|---|---| | WIP Account | Select | Work-in-progress account used when project cost is held on the balance sheet before recognition | | Deferred Cost Account | Select | Balance sheet account where vendor-bill expenses are deferred until covered by a recognition or capitalisation | | Cost of Sale Account | Select | P\&L account where recognised cost lands | | Deferred Revenue Account | Select | Balance sheet account where customer-invoice income is deferred until recognised | | Revenue Account | Select | P\&L account where recognised revenue lands | | Reversal WIP Account | Select | Counter-account for WIP reversal entries | | Reversal Deferred Cost Account | Select | Counter-account for Deferred Cost reversal entries | | Reversal Cost of Sale Account | Select | Counter-account for Cost of Sale reversal entries | | Reversal Deferred Revenue Account | Select | Counter-account for Deferred Revenue reversal entries | | Reversal Revenue Account | Select | Counter-account for Revenue reversal entries | ## GL accounts — capitalisation and other | Field | Type | What it controls | |---|---|---| | Asset Clearing Account | Select | Balance sheet account debited by Capitalisation transactions (capital projects) | | Default Asset Account | Select | Default fixed-asset account for capitalised cost on capital projects | | Default OPEX Account | Select | Default operating-expense account used when costs route directly to P\&L | | Field Expense Account | Select | Account for Field PO expenses | | Inventory Adjustment Account | Select | Account used for inventory adjustment transactions raised from Project Financials | ## Tax and compliance | Field | Type | What it controls | |---|---|---| | Field PO Purchase Tax Code | Select | Default purchase tax code on Field POs | | Tax Agency | Select | Tax agency vendor used for tax-related transactions | | Enable CIS and RCT (beta) | Checkbox | Turns on UK Construction Industry Scheme and Irish Relevant Contracts Tax handling — beta | | CIS/RCT Item | Select | The deduction item used by CIS/RCT entries when the feature is enabled | | Default Jurisdiction | Select | Default jurisdiction (controls compliance-related defaults — e.g. subcontract templates) | ## Items used by Project Financials | Field | Type | What it controls | |---|---|---| | Sales Item Main Contract | Select | NetSuite item used for the headline contract line on customer invoices | | Sales Item Change Order | Select | NetSuite item used for variation lines on customer invoices | | Time & Materials Service Item | Select | NetSuite item used for T\&M-billed lines | | Time & Materials Margin Item | Select | NetSuite item used when a margin is added to T\&M lines | | Purchase Item Main Contract | Select | NetSuite item used for vendor purchase orders raised from estimates | | Quote Item | Select | NetSuite item used for quote-generated lines | ## Behaviour switches | Field | Type | What it controls | |---|---|---| | Segment By Cost Category | Checkbox | When ticked, revenue recognition journals split by cost category instead of a single project line | | Include Projects in Revenue Recognition | Checkbox | When ticked, new projects in this subsidiary are picked up by the revrec batch by default | | Include Projects in Drawdown | Checkbox | When ticked, new projects are eligible for drawdown billing by default | | Enable Advanced Forecasting | Checkbox | Enables the budget-based cost recognition branch — recognises cost against budget rather than against actual | | Enable Phases | Checkbox | Supplies the default for a project's **Use Phases** checkbox: when ticked, each newly created project has phases switched on. It gates nothing itself — the project checkbox is what the worksheets read — and changing it never alters existing projects. Set via *General Preferences → Estimate and Forecast*. **Don't tick it until at least one phase set exists**, because a project using phases must nominate one. See [Managing phases](../how-to/manage-phases) | | Enable Subcontract Management | Checkbox | Turns on the Subcontracts module for this subsidiary | | Retainage Integration Enabled | Checkbox | When ticked, claim retention flows through to the Retainage SuiteApp | | Email Author | Checkbox | Sets the *From* email address on automated emails to the current user rather than the system address | | Allow Concurrent Claims | Checkbox | When ticked, more than one claim may be in flight against a contract at the same time | | Auto Generate Bill | Checkbox | When ticked, vendor bills are auto-generated from approved Field POs | | Require Prequalification | Checkbox | When ticked, vendors must be prequalified before they can be assigned to work | | FX Rate Mode | Select | Controls how foreign exchange rates apply to multi-currency projects | | Approval Mode | Select | Controls the approval routing model (standard / strict / off) | | Compliance Model | Select | Subcontract compliance enforcement model | | Statutory Response Window | Integer | Default response window (days) for statutory subcontract notices | ## Create-customer / Create-opportunity automation | Field | Type | What it controls | |---|---|---| | Create Customer | Checkbox | When ticked, *Create Project* will also create a customer if one doesn't exist | | Create Contact | Checkbox | When ticked, *Create Project* will also create a contact | | Create Opportunity | Checkbox | When ticked, *Create Project* will also create an opportunity | | Create Proposal | Checkbox | When ticked, *Create Project* will also create a proposal | ## Import behaviour | Field | Type | What it controls | |---|---|---| | Import Contingency | Checkbox | When ticked, contingency values are imported with estimate rows | | Import Margin | Checkbox | When ticked, margin values are imported with estimate rows | | Import All Cost Categories | Checkbox | When ticked, all cost categories from the spreadsheet are pulled in, not just used ones | | Import Apply Options | Select | Controls how *Applied* flags are imported on estimate lines | | Estimate CSV Import Folder ID | Integer | NetSuite folder ID where the estimate import template lives | ## Templates and email | Field | Type | What it controls | |---|---|---| | Claim Template | Select | Default Advanced PDF template for printed claims | | Proposal Template | Select | Default Advanced PDF template for proposals | | Contract Template | Select | Default Advanced PDF template for contracts | | Progress Claim Form | Select | Form used when raising a progress claim | | Reverse Bill Email Template | Select | Email template for reverse-bill notifications | ## Vendor bidding These subsidiary-level defaults pre-fill each new vendor bid request and can be overridden per request. For how they behave in the bid workflow, see [Request vendor bids](../how-to/estimating/request-vendor-bids#configuring-bid-management). | Field | Type | What it controls | |---|---|---| | Bid Invite Email Template | Select | Email template for vendor bid invitations. Ships with a built-in default (*FC Default Bid Email Template*); most organisations replace it with their own. Defaults onto each new bid request (as its own **Bid Invite Email Template**), where it can be overridden for that individual request. | | Bid Reminder Email Template | Select | Email template for bid reminders. **No built-in default yet** — until one is set, reminders are sent without a template. Defaults onto each new bid request (as its own **Bid Reminder Email Template**), where it can be overridden for that individual request. | | Send Bid Reminder Days Before | Integer | Default reminder lead time (built-in default **15**). Pre-fills each new bid request's *Remind Days Before Due*, which can be changed per request. | | Acceptance mode | Select | How accepted bids populate the estimate. **Accepted** (default): accepting a whole bid writes all its lines to the estimate. **Preferred**: the PM selects specific lines to prefer, and only those lines appear on the estimate. Pre-fills each new bid request; overridable per request. | | Add estimate lines as Applied | Checkbox | When ticked, lines written to the estimate by Accept or Prefer are immediately marked Applied (they count toward estimate totals). When unticked (default), lines land unapplied — they appear on the estimate for comparison but don't change totals until you apply them manually. Pre-fills each new bid request; overridable per request. | ## Subsidiary-specific behaviour A Configuration record is required for every subsidiary that runs Project Financials. If your project's subsidiary doesn't have a Configuration record, you'll see an error when saving the project — create the Configuration record first. Some Configuration values can be overridden at the project level (e.g. deferred accounts). Where both are set, the project value wins. ## Related * [Install & configure](../install-configure) * [Custom records](./custom-records) * [Set up revrec rules](../revenue-recognition/set-up-revrec-rules) * [Request vendor bids](../how-to/estimating/request-vendor-bids) --- --- url: 'https://fullclarity.help/project-financials/reference/custom-records.md' --- # Custom records Project Financials adds a number of custom records to NetSuite. This is a reference list — not a how-to. Use it to look up what each record is and which area of the app uses it. \[\[toc]] ## Estimating & budgeting | Record | What it is | Found on | |---|---|---| | Estimate Collection | A grouping of one or more estimates that roll up to a single contract | Project → Estimating subtab | | Estimate | A worksheet of cost lines for a single bid scope or project budget | Estimate Collection | | Estimate Line | A single cost line on an estimate (item, quantity, rate, mark-up) | Estimate worksheet | | Estimate Expenses | An expense (non-item) line on an estimate | Estimate worksheet | | Forecast Line | A forecast adjustment to a budget cost line | Project → Forecasting subtab | | Cost Centre | A work-breakdown unit used to organise an estimate, budget or forecast | FullClarity → Project Financials → Cost Centres | | Cost Centre Set | A reusable collection of cost centres that can be applied to a project as a template | FullClarity → Project Financials → Cost Centre Sets | | Category | A cost classification (e.g. Concrete, Carpentry) within a cost centre | Cost Centre | | Cost Type | A secondary cost classification (e.g. Materials, Labour, Equipment, Subcontractor) | Global custom segment | | Allowance Type | Prime Cost / Provisional Sum allowance classification | Custom list | | Stage | A billing or project stage used by Stage billing and stage-grouped estimating | Custom segment | | Phase | A delivery grouping of work or units (a release, a block of units) that a cost belongs to. Distinct from Stage and from Billing Stage. See [Managing phases](../how-to/manage-phases) | Custom segment; FullClarity → Project Financials → Manage Phases | | Phase Set | A reusable named list of phases that a project or development nominates — the phase equivalent of a cost centre set | FullClarity → Project Financials → Manage Phases | | Worksheet Preferences | Tab-level configuration for which columns show on Estimate / Budget / Forecast / RevRec worksheets, including renames | FullClarity → Project Financials → Worksheet Preferences | ## Contracts & billing | Record | What it is | Found on | |---|---|---| | Contract | The customer agreement against a project; holds the contract value, billing type and billing structure | Project → Contracts sublist | | Billing Stage | A milestone on a stage-billing contract (percentage and date) | Contract → Billing Stages sublist | | Schedule of Values | A billable line item on a progress-billing contract | Contract → Schedule of Values sublist | | Claim | A single billing cycle against a contract | Contract → Claims sublist; or Project → Billing | | Claim Line | A line on a claim (one per SoV line, stage or transaction) | Claim record | | PDF Template | Registry of the Advanced PDF templates available for claim and contract printing (Standard, AIA G702/G731/G732, Drawdown variants) | FullClarity → Project Financials → PDF Templates | ## Quoting & vendor bidding | Record | What it is | Found on | |---|---|---| | Quote | A customer quote (pre-contract proposal). The same record type also holds a **vendor's bid** under a Vendor Bid Request — the "bid" in [Requesting vendor bids](../how-to/estimating/request-vendor-bids) is a Quote record | Project → Quoting subtab; Vendor Bid Request → Bids subtab | | Quote Item | A quote line item. Also serves as a **bid line** on a vendor's bid (one per scope line priced) | Quote record | | Quote Expenses | A quote expense line | Quote record | | Quote Decline Reasons | Reason codes captured when a quote is lost | Custom list | | Vendor Bid Request | A request for a quote sent to one or more vendors | Estimate or project | | Vendor Bid Request Line | A line on a bid request | Vendor Bid Request | | Vendor Contract | **Superseded.** An early vendor agreement record, retained only for historical data. It is not the subcontract feature — see [Subcontracts](#subcontracts) below | Project → Vendor Contract (Legacy) subtab | | Vendor Assignment | The allocation of a vendor to a piece of work | Project | | Vendor Assignment Line | A line on a vendor assignment | Vendor Assignment | ## Subcontracts The subcontract family is the current way to manage subcontractor agreements, variations and progress claims. See the [Subcontracts](/subcontracts/) guide for how to use them. | Record | What it is | Found on | |---|---|---| | Subcontract | A subcontractor agreement for a piece of work on a project, carrying the contract terms, retention, compliance model and lifecycle status | FullClarity → Project Financials → Subcontract | | Subcontract Lines | A line on the subcontract's Schedule of Values — the priced breakdown the subcontractor claims against | Subcontract record | | Subcontract Variation | A change to a subcontract's scope or value, numbered VAR1, VAR2… and approved before it changes the contract | Subcontract → Variations subtab | | Variation Lines | A line on a variation, either adjusting an existing Schedule of Values line or adding new scope | Subcontract Variation record | | Vendor Claim | A progress claim submitted by a subcontractor against a subcontract | Subcontract record | | Vendor Claim Lines | A line on a subcontractor's progress claim, one per claimed Schedule of Values or variation line | Vendor Claim record | | Claim Schedule Snapshot | A point-in-time record of what a claim was assessed against, kept for statutory evidence | Vendor Claim record | | Bill Claim Link | The link between an assessed claim and the vendor bill raised from it | Vendor Claim record | | Master Services Agreement | An overarching agreement with a subcontractor that supplies default terms to the subcontracts under it | Selected on the Subcontract record | | Portfolio | A grouping under a Master Services Agreement, used to set shared terms in one place | Master Services Agreement record; selected on the Subcontract | | Compliance Artefact | A compliance document captured against a progress claim, such as a statutory declaration or insurance certificate | Vendor Claim record | ## Purchasing | Record | What it is | Found on | |---|---|---| | Field PO | A field-raised purchase order created from a mobile or site flow | FullClarity → Project Financials → Field POs | | Create PO Custom Field | Configuration of which fields appear on the Create PO Suitelet | Internal config | ## Revenue recognition & capitalisation | Record | What it is | Found on | |---|---|---| | Revenue Recognition | A month-end revenue recognition batch (one round, one per period) | FullClarity → Project Financials → Revenue Recognition | | Revenue Recognition Line | Per-project line on a recognition batch | Revenue Recognition record | | Capitalisation | A capitalisation batch (capital projects) | FullClarity → Project Financials → Capitalisation | | Capitalisation Line | Per-project line on a capitalisation batch | Capitalisation record | | Capital Claim | A claim against a capital funding facility | Project → Drawdown subtab | | Capital Claim Line | A line on a capital claim | Capital Claim record | ## Development & financing | Record | What it is | Found on | |---|---|---| | Development | A property development — a group of lots that share Plans. See [Set up a development](/project-financials/how-to/set-up-a-development). | FullClarity → Project Financials → Developments | | Lot | An individual lot or unit within a development. Carries an address, a default Plan, and a link to its own project once created. | Development → Lots | | Plan | A pricing and cost template for one dwelling design, carrying the estimate that prices it. A standalone record — a development selects the plans it offers, and the same plan can be offered on more than one development. See [Create a plan](/project-financials/how-to/create-a-plan). | FullClarity → Project Financials → Plans, and a development's **Plans** field | | Drawdown Facility | A loan or funding facility a project can draw against | Project → Drawdown subtab | | Fund Type Allocation | Splits an estimate line across multiple fund types (e.g. construction loan + equity) | Estimate Line | ## Safety, compliance & operational | Record | What it is | Found on | |---|---|---| | Safety Checklist | A reusable checklist template | FullClarity → Project Financials → Safety Checklists | | Safety Checklist Line | A checklist item | Safety Checklist | | Project Safety Checklist | An instance of a checklist applied to a project | Project → Safety subtab | | Project Safety Checklist Line | An item on a project safety checklist | Project Safety Checklist | | Daily Log | A daily site log entry | Project → Daily Logs subtab | | Project Inventory | On-site stock for a project | Project → Inventory subtab | | WP Location | Work-package location (a physical area within a site) | Project; estimate / budget worksheets | | Warranty Insurer | Warranty insurance provider | FullClarity → Project Financials → Warranty Insurers | ## Configuration & setup | Record | What it is | Found on | |---|---|---| | Configuration | Per-subsidiary configuration record — see [Configuration record fields](./configuration-record-fields) | FullClarity → Project Financials → Configuration | | Information | System information record (versioning, post-deploy data) | Internal | | Report Preferences | Reporting configuration | FullClarity → Project Financials → Report Preferences | ## Related * [Configuration record fields](./configuration-record-fields) * [Contracts & billing](../contracts-billing/) * [Revenue recognition](../revenue-recognition/) * [Manage cost centres](../how-to/manage-cost-centres) * [Managing phases](../how-to/manage-phases) --- --- url: 'https://fullclarity.help/project-financials/reference/permissions.md' --- # Permissions How Project Financials gives your users access to its features, and exactly which permissions each setting puts on a role, and at what level. \[\[toc]] ## The model FullClarity doesn't expect you to give your users the bundled FullClarity role. Instead, Project Financials access is added to *the roles your users already have*, such as Project Manager, Quantity Surveyor or Accounts Payable. Users then work with FullClarity as part of their normal NetSuite role, without switching roles. The **Assign Permissions** page does the work. For each role you choose an access level against each of thirteen feature columns. The page then works out every permission that level needs and writes them onto the role in one go: * the FullClarity records for that feature; * any NetSuite transactions and lists the feature relies on; * a standard set that every FullClarity role needs. This page lists every one of those permissions and the level it's given at. ## How to give a role access 1. Go to **FullClarity → Project Financials → Assign Permissions**. 2. At the bottom of the **Granted Roles** list, pick the role in the **Role** column. Only your own (custom) roles are listed: NetSuite's standard roles can't be changed this way. 3. Choose a level in each feature column: **None**, **View**, **Create**, **Edit** or **Full**. 4. Click **Add**. 5. Repeat for any other roles. 6. Click **Submit**. To change a role, click its row, change the levels, click **Add**, then **Submit**. **Every Submit re-applies every role on the page,** whether or not you changed it. After a FullClarity update you can press **Submit** to bring all roles up to date straight away. You don't need to, though: updates do this themselves (see [After a FullClarity update](#after-a-fullclarity-update)). ## How levels are applied * **The levels mean what they do in NetSuite:** * **View:** open and read records. * **Create:** view, and create new records. * **Edit:** view, create and change records. * **Full:** everything Edit does, plus delete. * **Levels only go up.** Each permission is raised to the highest level any column gives it. If the role already has a higher level, from another column or because you set it by hand, that higher level is kept. * **Lowering a column doesn't lower the role.** Setting a column to a lower level, or to None, doesn't take access away. To remove access, use [Removing a role's access](#removing-a-role-s-access) or edit the role directly. * **Some permissions have their own level, whatever the column says.** A column at Full doesn't make everything Full. For example, the subcontract columns give **View** on Contacts and Tax Records, and the payment schedule history is always **Create** only. The tables below give the exact level for each permission. * **Where two columns share a record, the higher level wins.** See [Shared records](#shared-records). ## What each column gives In the tables below, **"Column level"** means the level you chose for that column. The record names are as they appear on the role's **Permissions → Custom Record** tab. ### Estimate and Estimate Template Both columns give the same records, so the higher of the two applies (see [Shared records](#shared-records)). | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Estimate | Custom Record | Column level | | FC Proj Fin Estimate Collection | Custom Record | Column level | | FC Proj Fin Estimate Line | Custom Record | Column level | | FC Proj Fin Estimate Item UI | Custom Record | Column level | | FC Proj Fin Estimate Item Multi UI | Custom Record | Column level | | FC Proj Fin Estimate Expenses | Custom Record | Column level | | FC Proj Fin Allowance Type | Custom Record | Column level | | FC Proj Fin WP Location | Custom Record | Column level | ### Contracts | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Contract | Custom Record | Column level | | FC Proj Fin Schedule of Values | Custom Record | Column level | | FC Proj Fin Billing Stage | Custom Record | Column level | ### Claims These are your claims to your customer. Subcontractors' claims to you are in [Subcontract Claims](#subcontract-claims). | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Claim | Custom Record | Column level | | FC Proj Fin Claim Line | Custom Record | Column level | | FC Proj Fin PDF Template | Custom Record | Column level | | FC Proj Fin Drawdown Facility | Custom Record | Column level | ### Capitalising Assets | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Capitalisation | Custom Record | Column level | | FC Proj Fin Capitalisation Line | Custom Record | Column level | | FC Proj Fin Capital Claim | Custom Record | Column level | | FC Proj Fin Capital Claim Line | Custom Record | Column level | | Capitalisation | Transactions | Column level | ### Revenue Recognition | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Revenue Recognition | Custom Record | Column level | | FC Proj Fin Revenue Recognition Line | Custom Record | Column level | The Revenue Recognition *transaction* is in the [standard set](#the-standard-set-every-role-gets) every FullClarity role gets, at Full. ### Development | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Development | Custom Record | Column level | ### Plans | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Plan | Custom Record | Column level | ### Lots | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Lot | Custom Record | Column level | | FC Proj Fin Create Lot Queue | Custom Record | Column level | | FC Proj Fin Create Lot Queue Line | Custom Record | Column level | ### Quote | Permission | Role tab | Level | |---|---|---| | FC Proj Fin Quote | Custom Record | Column level | | FC Proj Fin Quote Expenses | Custom Record | Column level | | FC Proj Fin Quote Item | Custom Record | Column level | | FC Proj Fin Quote Decline Reasons | Custom Record | Column level | ### Report | Permission | Role tab | Level | |---|---|---| | FC CL Report | Custom Record | Column level | Report Preferences need no permission: every user can save their own. ### Subcontracts | Permission | Role tab | Level | |---|---|---| | FC PF Subcontract | Custom Record | Column level | | FC PF Subcontract Lines | Custom Record | Column level | | FC PF Master Services Agreement | Custom Record | Column level | | FC PF Portfolio | Custom Record | Column level | | FC PF Subcontract Variation | Custom Record | Column level | | FC PF Variation Lines | Custom Record | Column level | | FC PF Connect Audit Log | Custom Record | **Create** at most | | Contacts | Lists | **View** | | Tax Records | Lists | **View** | ### Subcontract Claims | Permission | Role tab | Level | |---|---|---| | FC PF Vendor Claim | Custom Record | Column level | | FC PF Vendor Claim Lines | Custom Record | Column level | | FC PF Claim Variance Reason | Custom Record | Column level | | FC PF Compliance Artefact (the payment schedule) | Custom Record | Column level | | FC PF Bill Claim Link | Custom Record | Column level | | FC PF SC Claim Schedule Snapshot | Custom Record | **Create** at most | | FC PF Connect Audit Log | Custom Record | **Create** at most | | Contacts | Lists | **View** | | Tax Records | Lists | **View** | Notes on the two subcontract columns: * **The schedule snapshots and the Connect audit log are add-only.** Together they're the record of what was assessed, sent and done on each claim. Whatever level the columns give, a role can add to them but never edit or delete them. That includes Full, and both columns together. * **Contacts and Tax Records are View only.** * The **Send Payment Schedules** page needs to read the subcontractor's contacts to address the email. * **Generate Payment Schedule** needs to read tax records to work out GST. * Neither page changes them, so the columns give only View. A role that already has a higher level keeps it. * **The Connect audit log is in both columns,** because variations and claims both write to it. * **Variance Reasons need no permission.** The standard reasons and their default text are available to every user. * **Bills and credits are made for the user.** Approving a claim, which creates its Item Receipt, and **Create Bill**, which creates its Vendor Bill and Vendor Credit, run with Administrator rights. So an assessor doesn't need receipt, bill or credit permissions of their own. ## The standard set every role gets Any role given access through this page also gets the following, whichever columns you choose. These are the permissions FullClarity's pages and calculations need in the background. **Custom records, at Edit:** | Permission | Level | |---|---| | FC Proj Fin Configuration | Edit | | FC Proj Fin Information | Edit | | FC Proj Fin Cost Centre | Edit | | FC Proj Fin Cost Type | Edit | | FC Proj Fin Forecast Line | Edit | | FC Proj Fin Cost Type Segment | Edit | | FC Proj Fin Stage Segment | Edit | | FC Proj Fin Category Segment | Edit | | FC Project Segment | Edit | | FC Proj Fin Warranty Insurer | Edit | | FC Proj Fin Worksheet Preferences | Edit | | FC Proj Fin Worksheet Column | Edit | | FC Proj Fin Field PO | Edit | | FC Proj Fin Vendor Bid Request Line | Edit | **Transactions:** | Permission | Level | |---|---| | Revenue Recognition (FullClarity transaction) | Full | | FC Drawdown Invoice (FullClarity transaction) | Full | | Bill (Vendor Bill) | Edit | | Customer Payment | Edit | | Invoice | Edit | | Item Fulfilment | Edit | | Opportunity | Edit | | Purchase Order | Edit | | Estimate | Edit | | Sales Order | Edit | | Track Time | Edit | **Lists:** | Permission | Level | |---|---| | Customers | Edit | | Projects | Edit | | Perform Search | Edit | | Documents and Files | Edit | | Vendors | View | | Employees | View | | Items | View | | Locations | View | | Subsidiaries | View | | Custom Record Entries | View | **Setup:** | Permission | Level | |---|---| | Manage Custom Segments | Edit | | Custom Lists | Edit | | Accounting Lists | View | How the standard set is applied: * **The standard transactions** are raised to Edit if the role has them lower, and kept if higher. * **The standard lists, setup permissions and the two FullClarity transactions** are added only if the role doesn't have them. If the role already has one at any level, it's left as it is. * **Changes you make by hand are kept.** For example, you might raise Bill to Full for an Accounts Payable role. Re-applying the page, or a FullClarity update, won't take it back down. ::: warning The Configuration record Because FC Proj Fin Configuration is in the standard set, **every role with any FullClarity access can edit the Configuration record**. Most features need to read it, and some need to write to it. If a role shouldn't change the configuration, restrict that role's access to the Configuration record on the role itself after you've assigned its permissions. ::: ::: tip No "reports only" roles Every role given any FullClarity access gets the standard set, including Edit on Purchase Orders, Invoices and Customers. If a role should only view FullClarity reports, remove the standard permissions it doesn't need from the role after assigning it, or use NetSuite's role restrictions (subsidiary, department, class). ::: ## Shared records When two columns give the same record, the role gets the higher of the two levels. * **Estimate and Estimate Template** give the same records. With Estimate at Full and Estimate Template at View, every estimate record is at Full: the Estimate Template choice has no effect when Estimate is higher. You can't currently give narrower access to estimate templates than to estimates through this page. * **The Connect audit log** is in both subcontract columns. It's capped at Create, whatever either column gives. ## After a FullClarity update When FullClarity is updated in your account, every role on this page is re-applied automatically, a few minutes after the update finishes. So when a release adds a record or a permission to a column, roles that already have that column get it without anyone pressing Submit. The same rules apply as when you press Submit: levels only go up, and changes you've made by hand are kept. ## Removing a role's access 1. Go to **FullClarity → Project Financials → Assign Permissions**. 2. Click the role's row in **Granted Roles**. 3. Click **Remove**, then **Submit**. Removing a role sets its FullClarity records to None, from both the feature columns and the standard set, and removes the role from the page. ::: warning Some permissions stay on the role Removing a role doesn't take back the **standard set's** transactions, lists and setup permissions, the FullClarity transactions, or Contacts and Tax Records. If you need to return the role to how it was before FullClarity, remove those from the role by hand. A fix to make removal take back everything it gave is planned. ::: Because levels only go up, setting every column to None doesn't suspend a role's access. To suspend it, remove the role. When you add it back later, choose its levels again. ## Permissions in other FullClarity SuiteApps Each FullClarity SuiteApp manages its own permissions: * **Retainage:** FullClarity → Retainage → Assign Permissions. See [Retainage Permissions](../../retainage/reference/permissions). * **File Storage:** FullClarity → Storage → Assign Permissions. See [File Storage Permissions](../../file-storage/reference/permissions). * **Timeline:** FullClarity → Timeline → Assign Permissions. See [Timeline Permissions](../../timeline/reference/permissions). * **Certified Documents:** no Assign Permissions page yet; set permissions on each role by hand. See [Certified Documents Permissions](../../certified-documents/reference/permissions). Retainage, File Storage and Timeline are all-or-nothing: a role gets Full access to the SuiteApp's records or none. Project Financials is the only SuiteApp with a level per feature. A role that needs several SuiteApps is set up on each SuiteApp's page in turn. ## Related * [Configuration record fields](./configuration-record-fields) * [Install & configure](../install-configure) * [Retainage Permissions](../../retainage/reference/permissions) * [File Storage Permissions](../../file-storage/reference/permissions) --- --- url: 'https://fullclarity.help/project-financials/revenue-recognition.md' --- # Revenue recognition Project Financials includes a configurable month-end revenue recognition process built for project-based businesses. It calculates how much revenue (and how much cost) to recognise on each project at period-end, posts a single recognition transaction, and reclassifies the underlying invoices and bills to deferred GL accounts until they're covered by a recognition entry. \[\[toc]] ## What this covers Revenue recognition turns the raw flow of customer invoices and vendor bills into accurate, period-aligned revenue and cost-of-sales numbers in your GL. Without it, project businesses end up booking revenue when invoices happen to be raised — which rarely matches the work actually performed. Project Financials uses a percentage-of-completion model. The recognised amount for each project in a period is driven by your choice of basis: * **Cost-incurred basis** — recognise revenue in proportion to cost incurred against the budget cost. The standard cost-to-cost approach: each period's recognition is the calculated % complete amount minus what's already been recognised. * **Billing-driven basis** — recognise revenue against billings. Each period's recognition is the calculated % complete amount minus what's already been billed. Useful as a catch-up method to true-up against actual billings. Pick one basis per project. Most commercial-construction clients run on the cost-incurred basis. ## How it fits together 1. Throughout the month, normal NetSuite invoices and bills post to standard AR / COGS accounts. 2. A pair of custom GL plug-ins reclassifies those postings to deferred-revenue and deferred-expense accounts for projects flagged for revenue recognition. 3. At month-end you run the revrec batch — it calculates each project's recognised revenue and recognised cost and posts a Revenue Recognition transaction that clears the deferred amount and books it to actual revenue / cost of sales. 4. The deferred GL accounts always net to "work invoiced or billed but not yet recognised." Capital projects (build-to-hold) use a separate Capitalisation flow rather than revenue recognition. See [Capital project revrec](/project-financials/revenue-recognition/capital-project-revrec). ## In this section * [Set up revrec rules](/project-financials/revenue-recognition/set-up-revrec-rules) — turn on revrec for a project, pick the basis, set the deferred accounts * [Run a monthly batch](/project-financials/revenue-recognition/run-a-monthly-batch) — the end-of-month workflow * [Adjust a revrec entry](/project-financials/revenue-recognition/adjust-a-revrec-entry) — override a calculated line before posting * [Capital project revrec](/project-financials/revenue-recognition/capital-project-revrec) — capitalisation for build-to-hold projects ## Requires * Project Financials installed and configured — see [Install & configure](/project-financials/install-configure) * Deferred revenue and deferred expense GL accounts set up in your NetSuite chart of accounts * Subsidiaries configured with a Configuration record — see [Configuration record fields](/project-financials/reference/configuration-record-fields) --- --- url: >- https://fullclarity.help/project-financials/revenue-recognition/adjust-a-revrec-entry.md --- # Adjust a revrec entry Override a calculated revenue or cost amount on a Revenue Recognition line before the batch posts. Use this when the system calculation doesn't match the finance team's view of recognised position for that project this period. \[\[toc]] ## When to use this When a calculated revrec line needs an override before approval — for example when the accountant wants to defer recognition on a specific project, a cost adjustment hadn't posted yet when the batch was calculated, or one project's actual % complete doesn't reflect reality (e.g. a milestone is reached but the cost hasn't caught up). ## Prerequisites * A Revenue Recognition record in *Pending* status (calculated but not yet submitted to the journal-generation batch) * Permission to edit Revenue Recognition Lines ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the pending Revenue Recognition record. 2. Open the line for the project that needs adjustment. 3. Enter override values: * **Revised %** — override the calculated % complete. * **Revised Rev $** — override the revenue amount this period. * **Revised Cost $** — override the cost amount this period. 4. Add a *Notes* entry explaining why — these notes carry into the audit trail and help the auditors and future-you understand the override. 5. Save the line. The header total updates to reflect the override. 6. When the whole record is ready, submit it as normal — see [Run a monthly batch](./run-a-monthly-batch). ## What success looks like * The Revenue Recognition Line shows the override values in the *Revised* fields. * The original *Calculated* fields are preserved next to the *Revised* fields for audit comparison. * The header *Total Recognised Amount* reflects the sum of revised values across all lines. * After submission, the posted Revenue Recognition transaction is based on the revised values, not the calculated ones. ## Gotchas * **Overrides do not flow backward into the deferred-account reclassification.** The GL plug-ins reclassify invoices and bills as they post — they don't know about your override. The override only changes the recognition journal. * **Prior-period adjustments self-correct over time.** The next month's calculation reads "Recognised to Date" from the prior periods, including this override. If you over-recognised this month, next month's calculated $ will be lower automatically. * **Don't edit a recognised value after the record is Completed.** Edits to a posted Revenue Recognition Line don't repost the journal. If you need to change a posted recognition, either post a correcting recognition next period or have an administrator reverse and rerun. * **Re-running *Calculate* after an override wipes the override.** If you want to discard your override and go back to the system numbers, that's the way to do it. If you want to keep your override, don't recalculate. ## Related * [Run a monthly batch](./run-a-monthly-batch) * [Set up revrec rules](./set-up-revrec-rules) --- --- url: >- https://fullclarity.help/project-financials/revenue-recognition/capital-project-revrec.md --- # Capital project revrec For build-to-hold projects that capitalise costs to a fixed asset rather than recognising revenue. Run the Capitalisation worksheet at period-end to move accumulated costs from the project's work-in-progress account onto the balance sheet. \[\[toc]] ## When to use this For build-to-hold projects where the completed asset is held on the balance sheet rather than sold to a customer — for example, internally funded property development, owner-occupier construction, or capital expenditure projects. These projects use the *Capital* billing type and never produce customer invoices, so they use Capitalisation in place of standard revenue recognition. ## Prerequisites * Project flagged with the *Capital* billing type * Fixed Asset (or Asset Clearing) GL account in place — set either as the subsidiary default in the Configuration record or as a project-level override * (If applicable) Development and Lot records configured for multi-lot capitalisation — see [Custom records](../reference/custom-records) * All vendor bills and project costs for the period have posted * Permission to create and approve Capitalisation records ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Navigate to **FullClarity → Project Financials → Capitalisation** and click **New**. 2. Set the *Date* and *Posting Period*. 3. Pick the *Subsidiary* and (optionally) narrow by billing type. 4. Select the projects to include. The worksheet creates one Capitalisation Line per project — same structure as the Revenue Recognition worksheet, calculated values plus revised overrides. 5. Review and (if necessary) override the calculated capitalisation amount per project. 6. **Submit** the Capitalisation record. The status moves to *Generating Journals* and a background batch posts one Capitalisation transaction per line. Each transaction debits the fixed-asset / asset-clearing account and credits the project's expense accounts (split by cost category). 7. (For Capital Claims — where the project draws against a capital facility rather than capitalising direct cost) — open the project's *Drawdown* subtab and create a Capital Claim record directly. Capital Claims use a simpler record-edit flow than progress claims. ## What success looks like * Capitalisation record in *Completed* status with one line per included project. * One Capitalisation custom transaction posted per project — debits the asset account, credits the expense accounts by cost category. * The project's accumulated cost on its work-in-progress account is decremented by the capitalised amount. * The fixed-asset (or asset-clearing) balance is incremented by the same amount. * For multi-lot developments — each lot's share of the capitalised cost is visible on its lot record. ## Gotchas * **Capital projects don't generate Revenue Recognition transactions.** They capitalise instead. Don't run both flows on the same project — pick one based on the project's billing type. * **Capitalisation can run multiple times across a project's life.** Typically at major milestones rather than monthly, but the system doesn't enforce a cadence — run it when finance wants to move cost off the WIP account. * **The deferred-expenses GL plug-in still applies.** Vendor bills for a capital project route to a deferred expense account until covered by a Capitalisation. The capitalisation transaction clears the deferred balance. * **Project-level asset accounts override the subsidiary default.** If a project's asset clearing account is set on the Job record, that takes precedence over the Configuration record's default. * **Capital Claims and Capitalisation are separate things.** Capitalisation moves cost onto the balance sheet from WIP. Capital Claim is a claim against a capital funding facility (e.g. a developer drawing against equity). A project can use either or both. * **Same status lifecycle as revenue recognition** — Pending → Generating Journals → Completed (or Completed With Errors). Recovery follows the same pattern. ## Related * [Set up revrec rules](./set-up-revrec-rules) * [Run a monthly batch](./run-a-monthly-batch) * [Custom records](../reference/custom-records) --- --- url: >- https://fullclarity.help/project-financials/revenue-recognition/run-a-monthly-batch.md --- # Run a monthly batch Create a Revenue Recognition record for the period, calculate each project's recognised revenue and cost, review the lines, then approve to post the recognition transactions. \[\[toc]] ## When to use this At every month-end (or your chosen revrec cadence). The batch is the trigger that turns the deferred-revenue and deferred-expenses balances accumulated through the month into actual recognised revenue and cost in the GL. ## Prerequisites * All customer invoices for the period have been posted * All vendor bills for the period have been posted * The accounting period is still open * The previous month's Revenue Recognition record is at *Completed* — recognition is sequential * Permission to create and approve Revenue Recognition records (typically Administrator or *PF Admin*) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Navigate to **FullClarity → Project Financials → Revenue Recognition** and click **New**. 2. Set the *Date* (transaction date for the posted recognition entries) and the *Posting Period*. 3. Pick the *Subsidiary* and, optionally, narrow by *Billing Type* if you want to recognise only certain billing types this run. 4. Select the projects to include. The worksheet creates one Revenue Recognition Line per project. 5. The worksheet shows for each project: * *Total Contract* / *Budgeted Costs* / *Actual Costs* / *Billed to Date* * *Recognised to Date %* and *Recognised to Date $* (cumulative prior recognition) * *Calculated % Complete* — `min(actual cost / budget cost, 1.0)`, forced to 100% if the project is marked complete * *Calculated Rev $* and *Calculated Cost $* — what the system proposes to recognise this period 6. Review the lines. Where a line needs an override before posting, see [Adjust a revrec entry](./adjust-a-revrec-entry). 7. **Submit** the Revenue Recognition record. The status moves to *Generating Journals* and a background batch posts one Revenue Recognition transaction per line. 8. Wait for the status to reach *Completed*. Each line's *Journal* field now points to the posted transaction. ## What success looks like * Revenue Recognition record in *Completed* status, with one line per included project. * One Revenue Recognition custom transaction posted per project per period. * Each project's *Deferred Revenue* and *Deferred Expenses* GL account balances net to the not-yet-recognised position. * The GL revenue accounts (split by cost category) show this period's recognised revenue. ## Gotchas * **The batch only processes projects with revrec rules set up.** Projects without a recognition basis configured are skipped silently. See [Set up revrec rules](./set-up-revrec-rules). * **Once submitted, individual lines can't be edited.** Override values must be entered *before* you submit. If the batch has already posted and a line is wrong, use a new recognition round next period to true it up. * **Closing the accounting period before submission blocks the post.** Keep the period open until the Revenue Recognition record is Completed. * **Double-submission is guarded against.** The batch checks status before starting — a second submission while the first is still *Generating Journals* will abort. You won't get duplicate journals. * **If the batch finishes in *Completed With Errors* status**, some lines posted and some failed. Open each line and check the *Journal* field — lines without a journal didn't post. Resolve the underlying issue (e.g. missing GL accounts, locked period) and run a follow-up recognition round for the affected projects only. * **The recognition transaction posts split by cost category** — one credit line per category. The GL shows recognition broken down by category (Labour, Materials, etc.) rather than as a single project total. ## Related * [Set up revrec rules](./set-up-revrec-rules) * [Adjust a revrec entry](./adjust-a-revrec-entry) * [Capital project revrec](./capital-project-revrec) --- --- url: >- https://fullclarity.help/project-financials/revenue-recognition/set-up-revrec-rules.md --- # Set up revrec rules Turn on revenue recognition for a project, pick the recognition basis, and confirm the deferred GL accounts that the GL plug-ins will use. \[\[toc]] ## When to use this Once for each project that needs to recognise revenue — typically every external project except internal-billed and capital ones. Also revisit at the start of a new financial year if your deferred-account chart of accounts changes. ## Prerequisites * Project Financials installed and configured — see [Install & configure](../install-configure) * Deferred Revenue and Deferred Expenses GL accounts created in NetSuite (both must be balance-sheet accounts, not P\&L) * A Configuration record populated for the project's subsidiary — see [Configuration record fields](../reference/configuration-record-fields) * An active project record to apply the rules to ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the project record. 2. On the *Revenue Recognition* subtab, set the **Revenue Recognition Method** (the calculation basis). Choose either cost-incurred or billing-driven — see [the section overview](/project-financials/revenue-recognition) for the difference. 3. If the project's deferred accounts should differ from the subsidiary defaults, set the **Deferred Revenue** and **Deferred Expenses** account fields at project level. Project-level values override the Configuration record defaults. 4. Confirm the project's **Billing Type** is not *Internal* — internal projects don't recognise revenue. 5. Save the project. 6. Repeat for every project that needs revrec. ## What success looks like * The project's *Revenue Recognition* subtab shows the chosen basis and the deferred accounts. * The next time an invoice posts against the project, GL inspection shows the AR credit reclassified from standard income to the deferred revenue account. * The next time a vendor bill posts against the project, GL inspection shows the expense reclassified to the deferred expenses account. ## Gotchas * **Deferred accounts must be balance-sheet accounts.** Pointing the deferred revenue field at a P\&L account will produce nonsense GL totals — the GL plug-in still routes there but the balance sheet won't carry the deferred liability. * **Internal projects should not have revrec enabled.** The Internal billing type has no recognition route — leave revrec off. * **Capital projects use Capitalisation, not revrec.** See [Capital project revrec](./capital-project-revrec) — don't try to enable both on the same project. * **Changing the basis mid-project is supported but causes a one-off discontinuity** in the recognition curve. Coordinate with finance before switching. * **The GL plug-ins only reclassify when the project is part of an active recognition round.** If a project has revrec rules set but has never been included in a Revenue Recognition record, the deferred-account routing won't activate. * **Multi-currency:** the deferred-revenue GL plug-in skips lines where the project's currency differs from the transaction's currency — review GL impact on multi-currency projects before assuming all postings are deferred. ## Related * [Run a monthly batch](./run-a-monthly-batch) * [Adjust a revrec entry](./adjust-a-revrec-entry) * [Capital project revrec](./capital-project-revrec) * [Configuration record fields](../reference/configuration-record-fields) --- --- url: 'https://fullclarity.help/project-storage.md' --- # Project Storage Project Storage extends [File Storage](/file-storage) onto project (Job) records, giving every project a dedicated **Files** subtab that aggregates documents attached anywhere within the project — plus separate handling for plan files (drawings). \[\[toc]] ::: tip Not a separate SuiteApp "Project Storage" is **not** a separate SuiteApp — it's the project-aware part of the [File Storage](/file-storage) SuiteApp. The Files subtab on a project appears the moment File Storage is installed; there is nothing extra to buy or install. If you're looking for general file attachment functionality, start at [File Storage](/file-storage). ::: ## What Project Storage adds on top of File Storage File Storage gives every NetSuite record a drop-zone and a file list in the body of the record. Project Storage adds two project-specific surfaces on top of that: * **Files subtab on the project record.** Every Job (project) record gets a dedicated Files subtab that aggregates every file stored anywhere within the project — files on the project itself, on transactions tied to the project, on contracts and claims, and on related records. Files are grouped by category so it's easy to find drawings, certificates, photos, and supporting documents separately. This subtab is delivered entirely by File Storage and appears once File Storage is installed. * **Plan files.** A parallel surface for plan records (drawings, design documents). Plan files are a shared capability: File Storage provides the underlying document storage, while [Project Financials](/project-financials) provides the plan record itself and the plan-files surface that sits on it. Plan files therefore require **both** File Storage and Project Financials to be installed. They have their own list and upload widget tailored to the way plans are managed (versioning, drawing numbers, revisions). ## Where Project Storage fits Project Storage is File Storage's project-aware UI — not a separate product or install. The boundary is straightforward: * **The Files subtab on a Job record is wholly part of File Storage.** It appears as soon as File Storage is installed; nothing else is required. * **Plan files are a shared capability.** File Storage supplies the document storage; [Project Financials](/project-financials) supplies the plan record and the plan-files surface on it. Plan files therefore need both apps installed. If you're configuring file storage for the first time, the order is: 1. Install [Portal](/portal) and register the account. 2. Install [File Storage](/file-storage). 3. Enable the File Storage widget on the record types your projects touch (transactions, vendors, custom records, etc.). 4. Confirm the Files subtab appears on Job records and shows files grouped by category. For plan files, you'll also need [Project Financials](/project-financials) installed. ## Next steps * [Install & configure](/project-storage/install-configure) * [Enable the project files subtab](/project-storage/how-to/enable-project-files-subtab) * [Browse files on a project](/project-storage/how-to/browse-project-files) --- --- url: 'https://fullclarity.help/project-storage/how-to/browse-project-files.md' --- # Browse files on a project Find, open, and download documents attached anywhere within a project from the Job record's Files subtab. \[\[toc]] ## When to use this Whenever you want to see all the documents associated with a project — drawings, certificates, signed contracts, supporting photos, vendor bills, anything attached anywhere within the project — without having to open each related record individually. The Files subtab is the single place where everything stored against the project (via [File Storage](/file-storage)) is gathered together and grouped by category. ## Prerequisites * The Files subtab is visible on Job records (see [Enable the project files subtab](./enable-project-files-subtab)) * The role you're using has at least View permission for File Storage * The project has at least one file attached anywhere within it ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for browsing project files is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the Job record. 2. Click the **Files** subtab. 3. The subtab lists every file stored against the project, grouped by category. Categories are populated when files are uploaded — common categories include drawings, certificates, photos, contracts, and supporting documents. 4. Click any file name to download it (the link is a short-lived signed URL — see Gotchas). 5. Use the search/filter controls within the subtab to narrow the list when a project has many files. ## What success looks like * The Files subtab lists every file connected to the project from any of its linked records. * Files are grouped by category, with category names matching what was selected when each file was uploaded. * Clicking a file opens or downloads it without redirecting through any external portal — the file is served directly from secure cloud storage and downloads quickly worldwide. ## Gotchas * **Download links expire after 48 hours.** Each link is generated on demand and signed for a short window. If you copy a link out of the subtab and paste it into a chat tool, the link will stop working after 48 hours. Re-open the subtab to refresh the links. * **Files attached during create won't appear immediately.** File Storage links files to the record's internal ID — the record must be saved before any of its files appear in the subtab. New records won't have files until they're saved at least once. * **Files on records not yet linked to the project.** The subtab aggregates files via the project link on each related record (e.g. a bill linked to the project). If a record isn't linked back to the project, its files won't appear. Check the related record's project field if you expected a file to show up but it isn't there. ## Related * [Enable the project files subtab](./enable-project-files-subtab) * [File Storage overview](/file-storage) --- --- url: 'https://fullclarity.help/project-storage/how-to/enable-project-files-subtab.md' --- # Enable the project files subtab Make the dedicated **Files** subtab appear on Job (project) records and confirm it aggregates documents from across the project. \[\[toc]] ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. The high-level steps below describe what the feature does. Track its status in the Scribe register (internal). ::: ## When to use this You typically don't need to do anything explicit to enable the Files subtab — it's switched on automatically when [File Storage](/file-storage) is installed and the **Jobs** NetSuite feature is enabled. Use this how-to to confirm it's working and to troubleshoot if the subtab isn't appearing as expected. ## Prerequisites * [File Storage](/file-storage) installed * The **Jobs** NetSuite feature enabled (Setup → Company → Enable Features → Company) * A role with File Storage permissions (see [permissions reference](/file-storage/reference/permissions)) ## Walkthrough 1. Open any Job record. 2. Look for a **Files** subtab in the row of subtabs at the top of the record. 3. The subtab content is rendered inside a small embedded view (an iframe) that lists every file stored anywhere in the project, grouped by category. If the subtab is missing: * Check that the **Jobs** feature is enabled in Setup → Company → Enable Features. * Confirm that File Storage finished installing — the subtab is delivered by File Storage and only appears once the install has fully completed. * Confirm the role you're using has File Storage permissions; if not, use the automated allocator (see [File Storage install & configure](/file-storage/install-configure)). * Reload the record after enabling permissions or features — the form definition may be cached. ## What success looks like * A Files subtab is present on every Job record in your account. * Opening it shows a categorised list of files associated with the project. * Drag-and-drop upload works from inside the subtab; the file appears in the list within a few seconds. ## Gotchas * **Custom form layouts.** If your account uses a heavily customised Job form, the Files subtab may not be added to the default layout. Edit the form and add the **FC Storage Project Files** field/subtab to the form. * **Roles without File Storage permission.** Users without permission will see the subtab but it may render an empty or error state. Grant the role File Storage view-only access at minimum. * **OneWorld accounts.** The subtab works across subsidiaries, but each project's subsidiary needs a corresponding Portal Configuration record (see [Portal](/portal/install-configure)). ## Related * [File Storage install & configure](/file-storage/install-configure) * [Browse files on a project](./browse-project-files) --- --- url: 'https://fullclarity.help/project-storage/install-configure.md' --- # Install & configure Project Storage is delivered as part of [File Storage](/file-storage) — there is no separate install. This page covers the small amount of additional configuration needed to switch on the project-aware surfaces. \[\[toc]] ## Prerequisites Before you can use the project-aware Files subtab and the plan files surface, you need: * **Portal** installed and registered against the account — see [Portal](/portal) * **File Storage** installed — see [File Storage install & configure](/file-storage/install-configure) * **Project Financials** installed (only required if you intend to use plan files) * The **Jobs** NetSuite feature enabled (under Setup → Company → Enable Features → Company) ## Switching on the Files subtab The Files subtab is automatically rendered on every Job record once File Storage is installed and the **Jobs** feature is enabled. There is no separate configuration step — the subtab appears, populated with any files attached to records linked to the project. If the Files subtab is **not** appearing on Job records, check: * File Storage is fully installed — the subtab is delivered by File Storage and only appears once the install has fully completed. * The role you're logged in with has File Storage permissions (see [File Storage permissions](/file-storage/reference/permissions)). * The **Jobs** feature is enabled. ## Switching on plan files Plan files are a shared capability: File Storage provides the underlying document storage, while Project Financials provides the plan record and the plan-files surface that sits on it. Plan files therefore require **both** File Storage and Project Financials to be installed. Because the plan record itself is owned by Project Financials, plan files are administered through Project Financials' plan records — see [Project Financials](/project-financials) for plan setup. ## What success looks like * Opening any Job record shows a Files subtab populated with documents attached anywhere within the project, grouped by category. * Uploading a file from within the Files subtab stores it against the project in cloud storage and it appears immediately in the list. ## Related * [File Storage install & configure](/file-storage/install-configure) * [Enable the project files subtab](./how-to/enable-project-files-subtab) * [Browse files on a project](./how-to/browse-project-files) --- --- url: 'https://fullclarity.help/project-tracker.md' --- # Project Tracker The Project Tracker is a shared workspace inside NetSuite that you and the FullClarity team use to run a SuiteApp implementation — logging issues as you find them, recording user-acceptance test results, and keeping everyone in sync without separate spreadsheets or email threads. \[\[toc]] ## What it is When you take on a new FullClarity SuiteApp, there's a period — usually a few weeks — where the configuration is being shaped to your business, real users are exercising it for the first time, and small adjustments are being made before the system goes live. During that period there are two kinds of conversations that have to happen: * **Issues** — anything that isn't working the way you expect, or anything you'd like changed before go-live. You log them, the FullClarity team picks them up, you both watch the status until it's resolved. * **User acceptance testing (UAT)** — a structured walkthrough of representative scenarios to confirm the system behaves correctly. You run each scenario, tick it off when it passes, and where it doesn't you raise an issue against it. The Project Tracker brings both of those into one screen inside NetSuite, side-by-side with the records being tested. No external login, no separate URL — it's just a tab in your NetSuite account. ## Who it's for * **Customer project managers and end users** who are participating in the implementation — logging issues, running test scenarios, marking results. * **NetSuite administrators** at the customer site, who install the tracker bundle and connect it to FullClarity using a one-time configuration record. * **FullClarity consultants** facilitating the implementation, who watch issues and UAT progress from their side of the connection. ## Where you'll find it Once the bundle is installed and configured, the tracker is reachable from a **FullClarity → Tracker → Project Tracker** menu entry in your NetSuite account. Opening it loads a two-tab workspace — **Issues** and **UAT** — inside the standard NetSuite chrome. ## How it connects to FullClarity The tracker is bound to a single FullClarity *engagement*. An engagement is FullClarity's record of the work being done for your account — typically one engagement per implementation project. When FullClarity sets up your engagement, they provide a short configuration payload (an API URL, an authentication token, and an engagement key) that you paste once into a single record in your NetSuite account. From then on, anything you log in the tracker is visible to the FullClarity team on their side, and anything they update flows back to your tracker. If you have more than one implementation running at once (for example, a Project Financials rollout and a separate Subcontracts rollout on a later schedule), each one has its own engagement and its own tracker configuration. ## What's logged where | Kind of thing | Where it goes | |---|---| | "This field name is wrong, can you change it?" | An issue, on the **Issues** tab | | "Step 3 of the progress-claim test didn't produce the expected total" | A 🚩 raise-issue flag on that UAT scenario, which logs an issue linked to it | | "I've run the progress-claim test and it behaved correctly" | A tick in your pass column on that UAT scenario | | "Here's a screenshot of what we're seeing, and the steps we took" | A note on the issue, with the screenshot attached | | "Quick follow-up from the call — we've tried X and it didn't help" | A note on the issue | ## What it isn't The tracker is **not** a long-term project management tool or a permanent ticketing system. It's scoped to the implementation period — from kick-off through go-live and any agreed stabilisation window. Once the implementation is signed off and the engagement is closed, the tracker for that engagement is read-only for historical reference. Day-to-day support tickets after go-live are raised through FullClarity's normal support channel, not through the tracker. ## Next steps * [Quick start](/project-tracker/quick-start) — open the tracker, log your first issue, record your first UAT result. * [Install & configure](/project-tracker/install-configure) — for the NetSuite administrator setting up the bundle and connecting it to FullClarity. * [Log an issue](/project-tracker/how-to/log-an-issue) — the issue form and what each field is for. * [Add notes to an issue](/project-tracker/how-to/add-notes-to-an-issue) — the per-issue note thread, attachments, and screenshots. * [Run UAT](/project-tracker/how-to/run-a-uat-cycle) — recording results and raising issues from test scenarios. --- --- url: 'https://fullclarity.help/project-tracker/how-to/add-notes-to-an-issue.md' --- # Add notes to an issue How to add notes — and screenshots, files, and other attachments — to a tracker issue, before and after creation. \[\[toc]] ## What notes are Every issue has a **note thread**. Notes are how you keep an ongoing conversation against the issue without losing the thread in email or chat: each side adds context as it surfaces, attaches screenshots or supporting files when useful, and everyone sees the same record. A note has: * A body — the text of the note. * Optional attachments — up to 10 files per note, 5 MiB each. Anything the platform can serve back works (screenshots, PDFs, CSVs, spreadsheets, short logs). * An author — captured automatically from the active NetSuite session. * A timestamp. Notes are visible to both sides — your team and FullClarity — and update in real time. When someone posts a note, anyone else with the issue open sees it appear within a second or two. ## The Notes column On the **Issues** tab, the rightmost column is **Notes**. It shows either: * **+ Add note** — there are no notes yet on this issue. * **💬** *n* — there are *n* notes on this issue. Click to open the thread. The count badge updates live whenever anyone — you, a colleague on your side, or a FullClarity consultant — adds or deletes a note. ## The Latest Note preview column Immediately to the left of the **Notes** column there's a **Latest Note** column. It shows a single-line preview of the most recent visible note on the issue, so you can see what the latest exchange was without having to open the thread. The preview updates live when a new note is posted. It's read-only — to reply or add a note, click the **Notes** cell on the row to open the thread. ## Opening the thread Click the **Notes** cell on any issue row. A dialog opens showing every note on that issue, oldest at the top, with the composer at the bottom. If the issue has no notes yet, the thread is empty and you'll go straight to the composer. ## Posting a note 1. Open the issue's note thread (click the Notes cell). 2. Type the note in the textarea at the bottom of the thread. 3. Optionally attach files (see [Attaching files](#attaching-files) below). 4. Click **Post**. The note appears immediately at the bottom of the thread, and any other person currently viewing the same issue sees it appear within a couple of seconds. You don't have to fill in either the body or attachments individually — but you need at least one of them. An empty note with no attachments can't be posted. ## Attaching files There are three ways to attach files to a note. Use whichever is most natural for what you have. ### Paste a screenshot The fastest path for screenshots. 1. Take a screenshot using your operating system: * **Mac**: Cmd+Shift+4 to select a region, then Cmd+V into the note composer. (Cmd+Shift+Ctrl+4 puts the screenshot on the clipboard directly without saving to your desktop.) * **Windows**: open the Snipping Tool (Win+Shift+S), capture, then Ctrl+V into the note composer. 2. Click into the note composer if it isn't already focused. 3. Paste (Cmd+V / Ctrl+V). The screenshot appears in the attachment area underneath the textarea, ready to post. ### Drag and drop Drop one or more files from Finder/Explorer onto the attachment area below the textarea. The drop zone highlights when you drag a file over it. ### Click to browse Click the **Paste a screenshot or click to attach a file** prompt in the attachment area. A standard file picker opens — choose one or more files and confirm. ### Limits * **5 MiB** per file. * **10 files** per note. If you exceed either limit, the attachment is rejected with a message naming the file. Compress or split if you have larger files; for very large logs, paste an excerpt into the note body or attach a representative chunk. ## Image preview Image attachments show as thumbnails in the posted note. Click a thumbnail to open it at full size in a lightbox. Press Escape or click outside the image to close. Non-image attachments (PDFs, CSVs, etc.) show as a filename with a download link. Click to download the file. ## Deleting a note You can delete notes you posted yourself. Hover the note in the thread — a **Delete** action appears on your own notes. Click it; confirm; the note disappears from the thread for everyone, and the count badge on the Issues list decrements. You can't delete notes posted by other people. If you need a note removed that isn't yours, ask the author or your FullClarity consultant. Deletes are reversible at FullClarity's end if asked promptly — the note isn't immediately purged, just hidden — but as a practical matter, treat delete as permanent. ## Notes during issue creation The **+ New Issue** form has a **First note** field that lets you start the thread at the moment you log the issue. This is useful when: * You've already got a screenshot of the problem and don't want a two-step "create then open then attach" dance. * The description is short ("Estimate header is wrong") but the supporting detail is in screenshots or a longer narrative that belongs in a note rather than the description. Anything you put in the First note (text and/or attachments) posts as the first note on the new issue the moment the issue is created. After that, add follow-ups through the Notes column on the Issues list as normal. ## Working in parallel Multiple people can have the same issue's note thread open at the same time. New notes from others appear in your view within a second or two. There's no "refresh" needed — the thread keeps itself current. If two people post a note at the same moment, both notes appear; nothing is overwritten or lost. The order is by post timestamp. ## Related * [Quick start](../quick-start) — the simple end-to-end walkthrough including a first note. * [Log an issue](./log-an-issue) — the full issue form, including the First note field. * [Issue fields](../reference/issue-fields) — what each column on the Issues list captures, including the Notes count. --- --- url: 'https://fullclarity.help/project-tracker/how-to/log-an-issue.md' --- # Log an issue How to create and update an issue in the Project Tracker. \[\[toc]] ## When to log an issue Anything that's worth a conversation with FullClarity during the implementation belongs in the tracker. Some typical cases: * A configuration value, label, or column header that should be different for your business. * A behaviour that doesn't match what you expected from the demo or the design spec. * A missing feature that's important enough to flag before go-live. * A UAT scenario that didn't behave as expected (raise these from the scenario's 🚩 flag — see [Run UAT](./run-a-uat-cycle)). If something isn't worth raising as an issue — minor questions, clarification requests — those are better as a direct conversation with your FullClarity consultant. The tracker is for items that benefit from being tracked to closure. ## Creating an issue 1. Open the **Project Tracker** and stay on the **Issues** tab. 2. Click **+ New Issue**. The form opens as a dialog. 3. Fill in the fields described below. 4. Click **Create**. The issue appears at the top of the list with the next available issue number. You can also click **Add row** to create an issue directly in the table without the form, if you only need to set a title quickly. Both routes create the same kind of issue; the form is just easier when you're filling in more than the title. ## The fields ### Primary information * **Title** (required) — a short, specific summary. Aim for something that tells the FullClarity team what the problem is without having to open the issue. "Estimate column says *Margin %* but should say *Markup %*" is better than "Estimate column wrong". * **Description** — the longer explanation. Useful content: what you did (steps), what you expected, what actually happened. If a specific NetSuite transaction or record is involved, name it. * **First note** (optional) — a longer narrative, or anywhere you want to attach a screenshot or supporting file. Paste a screenshot directly from the clipboard (Cmd+Shift+4 → Cmd+V on Mac, Snipping Tool → Ctrl+V on Windows), drop files onto the attachment area, or click to browse. The note posts to the issue's note thread on create. For more on notes after the issue exists see [Add notes to an issue](./add-notes-to-an-issue). ### Status & priority * **Status** — where the issue is in its life cycle: * *Open* — newly created, not yet picked up. * *In progress* — someone is actively working on it. * *Blocked* — work has stopped pending something else. * *Done* — resolved. * *Won't do* — agreed not to pursue. * **Priority** — how urgently you want this addressed: * *Low* — nice to have, no go-live impact. * *Medium* — should be resolved before go-live. * *High* — must be resolved before go-live. * *Critical* — blocking other work, needs attention immediately. Choose the priority based on its impact on go-live or on other work, not by personal preference. Tagging everything *Critical* dilutes the signal. ### Assignment * **Assignee** — pick whoever's responsible for handling the issue from the dropdown. The list includes both FullClarity consultants and members of your team. The tracker colour-codes the row by which side currently holds it. ## Editing an existing issue Click directly on a cell to edit it in place. For text cells (Title, Description), click and type. For dropdown cells (Status, Priority, Assignee), click to open the picker and choose a value. The change saves automatically when you tab out or click elsewhere — there's no separate "save" step. To continue the conversation on an issue after it's been logged, use the **Notes** column on the far right of the row — see [Add notes to an issue](./add-notes-to-an-issue). If two people happen to edit the same field at the same time, the system keeps the more recent change and shows a toast naming what was overridden. See [Handling edit conflicts](#handling-edit-conflicts) below. ## Sorting and filtering * Click any column header to sort the list by that column. Click again to reverse the sort. The arrow next to the column name shows the current sort direction. * Drag a column edge to resize that column. Your widths and sort order are remembered the next time you open the tracker. ## Handling edit conflicts When someone else changes a field on an issue you also have open, the next change you make to that field gets rolled back to the current value. A toast pops up top-right of the workspace explaining what happened — for example, *"Issue #3 — edit rolled back. Someone else changed the priority. Your value (Critical) was discarded. Server now shows: Medium."* You have two options: * **Accept the current value** — dismiss the toast and continue. * **Retry your change** — click **Retry** on the toast. The system re-applies your value against the now-current version. If the other person edited it again in the meantime, you'll see a fresh toast naming the new state, and you can decide again. This is rare during normal use — it only happens when two people happen to be on the same row at the same time. ## Related * [Quick start](../quick-start) — open the tracker for the first time. * [Add notes to an issue](./add-notes-to-an-issue) — the note thread and attachments. * [Run UAT](./run-a-uat-cycle) — including raising an issue from a test scenario's flag. * [Issue fields](../reference/issue-fields) — the full field reference, including columns you can't edit (the issue number, audit timestamps). * [Recording UAT results](../reference/uat-statuses) — the pass checkbox, the rollup, and issue states. --- --- url: 'https://fullclarity.help/project-tracker/how-to/run-a-uat-cycle.md' --- # Run UAT How to run user acceptance testing for an implementation, record which scenarios you've passed, and raise issues against the ones that don't. \[\[toc]] ## How UAT works UAT in the Project Tracker is **ongoing** — there are no rounds, cycles, or sign-off. The **UAT** tab holds a list of test scenarios FullClarity has prepared for your engagement, and each tester ticks off the scenarios they've personally run and confirmed work. As fixes are made and you re-test, you keep ticking; as you find problems, you raise issues against the scenario. The view simply reflects the current state of testing at any moment. The point of UAT is the same as ever: your own users walk through their own real workflow and confirm the system behaves correctly for *them* before go-live. ## Who runs the tests UAT is run by people on your side — the customer team — not by FullClarity. FullClarity provides the scenarios, but the value of UAT comes from your own users exercising the system. Common arrangements: * A single nominated tester runs every scenario themselves. * Each scenario is run by whoever owns that area of the business (the AP scenarios go to the AP person, the project setup scenarios go to a project administrator). * A mix — one person runs the core path, subject-matter experts run their specialist scenarios. Because each tester has their own pass column (see below), more than one person can take part and you can see at a glance who has passed what. ## The test scenarios Each row on the **UAT** tab is a test scenario set up by FullClarity for your engagement. The relevant columns: * **Test code** — a short identifier (sometimes blank if FullClarity hasn't assigned codes yet). * **Title** — what the scenario tests (for example, *Create a progress claim on a stage-billed contract*). * **Scenario** — a paragraph describing the business situation being tested. * **Steps** — the numbered steps the tester follows in NetSuite. * **Expected result** — what the tester should see when they complete the steps. * **Pass/Fail** — a read-only rollup showing whether the scenario has passed overall (see [Recording UAT results](../reference/uat-statuses)). * **A pass checkbox per tester** — one tick-box column for each person taking part in UAT. Your own column is shown first and is the only one you can tick; everyone else's is visible but read-only to you. * **🚩 (raise issue)** — a flag you click to raise an issue against the scenario when it doesn't behave as expected. If your scenarios look sparse or generic, ask your FullClarity consultant — they can refine or add scenarios at any time. ## Recording a pass 1. Pick a row to test. Read its Scenario, Steps, and Expected result. 2. Do the steps in NetSuite. 3. Compare what happened against the Expected result. 4. If it behaved exactly as the Expected result described, tick **your own pass checkbox** on that row. That's it — ticking your pass column means "I ran this scenario and it behaved as expected." The tick saves automatically, and the next time anyone opens the tracker they'll see it in your column. Leaving a checkbox un-ticked simply means you haven't passed that scenario yet — whether because you haven't run it, or because it didn't behave correctly. There's no separate "untested", "blocked", or "fail" value to set on the row; if a scenario doesn't behave as expected, you raise an issue against it (below). Each tester ticks independently, so you can see who has confirmed each scenario. For how the columns interact and what makes the **Pass/Fail** rollup turn green, see [Recording UAT results](../reference/uat-statuses). ## When a test fails — raise an issue from the flag When a scenario doesn't behave as the Expected result described, click the **🚩 flag** in the raise-issue column on that row. The **New Issue** form opens, pre-filled with: * A **Title** like *UAT fail: \ — \*, so the issue and the test are obviously linked. * A link back to the test scenario, so FullClarity can find it in seconds. You complete the rest: 1. Add a **Description** — what you actually saw versus what was expected. 2. Optionally use **First note** to add a longer narrative and attach screenshots — paste them straight from the clipboard (Cmd+Shift+4 → Cmd+V on Mac, Snipping Tool → Ctrl+V on Windows). See [Add notes to an issue](./add-notes-to-an-issue) for the full attachment surface. 3. Set a **Priority** (defaults to *Medium*). 4. Adjust the **Title** if the auto-generated one isn't quite right. 5. Click **Create**. The issue lands on the **Issues** tab with the next available issue number and stays linked to the scenario. The scenario's row shows the linked issue (for example, as a flag icon with the issue number, ⚑ #3). A single scenario can carry **more than one** linked issue — they appear together (for example, ⚑ #3 #4) if you raise several against the same test. If you'd rather not log an issue right now (maybe you want to gather more information first), click **Cancel** on the form — nothing is recorded against the scenario. While a scenario has an open linked issue, its **Pass/Fail** rollup stays un-ticked, even if a tester has ticked their pass column. The rollup only turns to pass once the issue is resolved and you've accepted the fix — see below. ## Working through the scenarios The order you work scenarios in is up to you. A few common patterns: * **Top-to-bottom** — simplest and predictable. * **By area** — group scenarios for the same NetSuite area together (all the AR scenarios, then all the AP scenarios), so you stay in one part of the system at a time. * **Critical first** — run the must-pass scenarios early so you know whether the implementation has go-live-blocking issues before spending time on edge cases. As fixes land, re-run the affected scenarios and tick your pass column once they behave correctly. ## When FullClarity fixes a linked issue — accept or reopen When FullClarity marks a linked issue as **Done**, that does **not** immediately clear it from the UAT view. The issue stays visible on the scenario's row as a link — shown in **green** to indicate FullClarity considers it fixed — and keeps the **Pass/Fail** rollup un-ticked until you confirm the fix. To confirm or reject the fix, click the issue link on the UAT tab (or open the issue's notes from the **Notes** cell on the **Issues** tab). On the issue's notes panel you'll find: * **Accept** — you've confirmed the fix is good. The issue stops blocking the scenario's rollup, so the scenario can now roll up to a pass (provided a tester has ticked their pass column). The issue stays *Done*. * **Reopen** — the fix didn't work. The issue goes back to *Open* and again blocks the rollup until it's fixed and accepted. This keeps the customer in control of when a scenario is truly considered passed — a fix isn't "done" for UAT purposes until you've accepted it. ## Working in parallel More than one person can record results at the same time. The tracker keeps everyone's view in sync — when you tick a pass or raise an issue, others see it on their next refresh. If two people happen to change the same thing at once, the most recent change wins and a notification appears so both people know what happened. ## Related * [Quick start](../quick-start) — open the tracker for the first time. * [Log an issue](./log-an-issue) — issues created from outside UAT. * [Add notes to an issue](./add-notes-to-an-issue) — extending the conversation after the issue is logged. * [Recording UAT results](../reference/uat-statuses) — the pass checkbox, the rollup rule, and issue states in detail. --- --- url: 'https://fullclarity.help/project-tracker/install-configure.md' --- # Install & configure How a NetSuite administrator installs the Project Tracker bundle and connects it to FullClarity. The whole sequence takes about ten minutes and only has to be done once per engagement. > **Who can do this:** NetSuite administrators only. \[\[toc]] ## What you'll do 1. Install the Project Tracker bundle from the SuiteApp Control Centre. 2. Get the configuration payload from your FullClarity consultant. 3. Create a single Tracker Configuration record in your account and paste the payload's values. 4. Confirm the tracker connects — the Health row on the Project Tracker page should say **Connected**. ## Step 1: Install the bundle The Project Tracker is delivered as a managed SuiteApp. 1. Open **Customization → SuiteCloud Development → SuiteApp Control Centre**. 2. Search for *FullClarity Project Tracker* and click **Install**. 3. If Code Library and Portal aren't already in the account, they install as dependencies. This is normal. After install you'll see a new menu entry at **FullClarity → Tracker → Project Tracker**. Don't open it yet — it won't be able to reach FullClarity until you've completed the configuration record below. ## Step 2: Ask FullClarity for your engagement payload Your FullClarity consultant creates the engagement record on their side and sends you a one-time JSON payload containing three values: * **API URL** — the address the tracker uses to reach FullClarity. * **API token** — a long string the tracker presents on every request so FullClarity knows the requests are coming from your account. * **Engagement key** — identifies which engagement on FullClarity's side the tracker is bound to. Keep the payload private — anyone with the API token can read and write your tracker data, so treat it like a password. ## Step 3: Create the Tracker Configuration record 1. Navigate to **FullClarity → Tracker → Project Tracker Configuration → New**. 2. Paste each value from the payload into the matching field: * **API URL** * **API Token** * **Engagement Key** 3. Leave **Bundle Version** and **Last Health** blank — the tracker fills them in automatically the first time the page loads. 4. Click **Save**. You should have exactly **one** Tracker Configuration record per NetSuite account. If you delete it or have a second one floating around, the tracker won't be able to decide which engagement to connect to. ::: warning Don't reuse a configuration across engagements Each engagement has its own API token and engagement key. If you start a second implementation later (for example, adding Subcontracts on top of an existing Project Financials install), ask FullClarity for a new payload and replace the values on the existing record — don't try to keep the old token around. ::: ## Step 4: Confirm the connection 1. Open **FullClarity → Tracker → Project Tracker**. 2. The first load takes a few seconds — the tracker has to authenticate to FullClarity and pull the current Issues and UAT data. 3. When the workspace renders, the connection is working. If FullClarity has seeded any UAT scenarios for your engagement, they'll already be visible on the **UAT** tab. The **Last Health** field on the Tracker Configuration record is stamped with the current time on every successful load. You can use that to confirm the integration is still healthy at any point. ## Granting access to the right users Anyone in your account with permission to access the FullClarity menu can open the tracker. There are no separate per-user permissions inside the tracker itself for the implementation period — by design, the implementation team should all be able to see and contribute. To restrict the tracker to specific NetSuite roles, edit the Audience tab on the Project Tracker Launcher Suitelet deployment. See [Permissions](./reference/permissions) for the full model. ## Disabling or replacing the tracker If an engagement ends or has to be reset, FullClarity will *revoke* the engagement on their side. Once revoked, the tracker shows a "This tracker has been disabled by FullClarity" message and stops accepting changes. The historical data remains on FullClarity's side for reference. To replace a revoked engagement with a fresh one, ask FullClarity for a new payload and update the three fields on the existing Tracker Configuration record. Save the record and reload the Project Tracker page — it should reconnect against the new engagement. ## Common stumbling blocks * **"Tracker server unreachable" toast on first load.** Almost always a typo in the API URL, or a copy-paste that lost the `https://` prefix. Open the Tracker Configuration record and compare every character against the payload FullClarity sent you. * **Tracker loads but Issues and UAT tabs are empty.** Normal on a brand-new engagement. Ask your FullClarity consultant whether UAT scenarios have been seeded yet — if not, FullClarity will provision them and they'll appear after a refresh. * **"Token revoked" or "disabled by FullClarity" appears immediately after pasting a payload.** The token may have been issued to a different account than the one you're installing into. Confirm with FullClarity that the payload matches the NetSuite account ID you're installing the bundle in. ## Next steps * [Quick start](./quick-start) — log your first issue, record your first UAT result. * [Log an issue](./how-to/log-an-issue) — the issue form in full. * [Run UAT](./how-to/run-a-uat-cycle) — the testing flow end-to-end. --- --- url: 'https://fullclarity.help/project-tracker/quick-start.md' --- # Quick start The fastest path from a freshly-configured Project Tracker to your first issue logged and your first UAT result recorded. \[\[toc]] ## Before you begin This page assumes someone has already installed the tracker bundle in your NetSuite account and pasted the FullClarity-supplied configuration. If that hasn't happened yet, start with [Install & configure](./install-configure) instead — it takes a few minutes for the NetSuite administrator and only has to be done once. ## Open the tracker From the NetSuite top menu, choose **FullClarity → Tracker → Project Tracker**. The tracker opens inside your normal NetSuite chrome, with two tabs across the top: **Issues** and **UAT**. If you can see the tabs but no data, that's normal on a brand-new tracker — the Issues tab will be empty until you log the first one, and the UAT tab will only have test scenarios once FullClarity has seeded them for your engagement. If the tracker shows an "unreachable" or "disabled" message, see [Common stumbling blocks](#common-stumbling-blocks) below. ## Log your first issue 1. On the **Issues** tab, click **+ New Issue**. A form opens. 2. Fill in **Title** — keep it short and specific ("Estimate column header says *Margin %* but should say *Markup %*"). This is the only required field. 3. Add a longer **Description** if useful — what you did, what you expected, what happened. 4. Optionally fill in **First note** — a longer narrative, or anything you'd like to attach a screenshot to. Press Cmd+Shift+4 (Mac) or the Snipping Tool (Windows) to grab a screenshot, then paste it directly into the First note area. 5. Set **Status** (defaults to *Open*) and **Priority** (defaults to *Medium*). 6. Click **Create**. The new issue appears at the top of the list with an auto-assigned number (#1, #2, ...). The FullClarity team will see it on their side within seconds. For the full field reference see [Issue fields](./reference/issue-fields). ## Add a note to your issue Issues have a **Notes** column on the far right of the list, with a **Latest Note** column just to its left showing a single-line preview of the most recent note. Click the **Notes** cell to open the per-issue note thread — that's where back-and-forth on the issue lives, and where you attach screenshots or supporting files. To add a note: 1. Click the cell in the **Notes** column for the issue (the cell reads *+ Add note* when there are no notes yet, or shows a count like *💬 3* once there are). 2. Type your note in the composer at the bottom of the thread. 3. Optionally attach files — paste a screenshot directly, drop files onto the attachment area, or click to browse. Up to 10 files per note, 5 MiB each. 4. Click **Post**. The note appears in the thread immediately and the FullClarity team sees it within seconds. For more on notes see [Add notes to an issue](./how-to/add-notes-to-an-issue). ## Record your first UAT result 1. Switch to the **UAT** tab. 2. Each row is a test scenario FullClarity has prepared for your engagement (for example, *Create a progress claim on a stage-billed contract*). Each tester taking part has their own **pass checkbox** column; your own column is shown first and is the only one you can tick. There's also a read-only **Pass/Fail** rollup and a **🚩** raise-issue flag on each row. 3. Work through the scenario in NetSuite. 4. If it behaved exactly as the *Expected result* column described, tick **your pass checkbox** on that row. The tick saves automatically. UAT is ongoing — there are no cycles or sign-off. You simply tick each scenario you've passed, and raise an issue against any that don't. For the full picture of how the pass columns and the **Pass/Fail** rollup work, see [Recording UAT results](./reference/uat-statuses). ## When a test fails: raise the issue from the same screen When a scenario doesn't behave as expected, click the **🚩 flag** on that row. The **New Issue** form pops open with the title already filled in — for example, *UAT fail: Create a progress claim on a stage-billed contract*. The test is automatically linked to the issue so the FullClarity team can see exactly which scenario failed and how to reproduce it. Add a description (what you actually saw versus what you expected), pick a priority, and click **Create**. The issue stays linked to the scenario, and that scenario's **Pass/Fail** rollup stays un-ticked until the issue is resolved and you've accepted the fix. ## Common stumbling blocks * **"Tracker server unreachable" toast.** The tracker can't currently talk to FullClarity. This is usually a temporary network issue and resolves on its own. The tracker will keep retrying — once it reconnects, your data reloads automatically. If it persists for more than a few minutes, contact FullClarity. * **"This tracker has been disabled by FullClarity" message.** The engagement has been closed, usually because the implementation has been signed off. The tracker is read-only at this point — for new issues, use FullClarity's regular support channel. * **An issue I edited reverted to a different value.** Someone else edited the same field a moment before you did, and the system kept the most recent change. The tracker will show a toast naming what happened and what the current value is. Either accept the current value or click **Retry** on the toast to re-apply your change. * **I can't see the issue I just created.** Click **Refresh** in the tracker's action bar. Issues should appear immediately, but if the connection had a brief hiccup, a manual refresh forces a reload. ## Next steps * [Log an issue](./how-to/log-an-issue) — every field on the form, when to use which. * [Add notes to an issue](./how-to/add-notes-to-an-issue) — the per-issue note thread, attachments, and screenshots. * [Run UAT](./how-to/run-a-uat-cycle) — recording results, raising issues, and accepting fixes. * [Issue fields](./reference/issue-fields) — the complete reference. --- --- url: 'https://fullclarity.help/project-tracker/reference/issue-fields.md' --- # Issue fields Every column visible on the Project Tracker's **Issues** tab, what it stores, and whether you can edit it. \[\[toc]] ## Editable fields These are filled in either through the **+ New Issue** form when you create the issue, or by clicking the cell on the list to edit in place. | Field | What it stores | Notes | |---|---|---| | **Title** | Short summary of the issue | Required. Keep it specific. | | **Description** | Longer explanation | Free-text. What you did, what you expected, what happened. | | **Status** | Where the issue is in its life cycle | *Open*, *In progress*, *Blocked*, *Done*, *Won't do*. Defaults to *Open* on a new issue. | | **Priority** | How urgently the issue needs attention | *Low*, *Medium*, *High*, *Critical*. Defaults to *Medium*. | | **Assignee** | The person handling the issue | Picked from a dropdown of FullClarity consultants and your team. The colour of the row reflects whether the assignee is FullClarity-side or customer-side. | The **+ New Issue** form also has a **First note** field that posts an initial note (with optional attachments) at the moment the issue is created. After the issue exists, use the **Notes** column to extend the thread — see [Add notes to an issue](../how-to/add-notes-to-an-issue). ## Read-only columns Filled in by the system or interacted with through their own dialog. You'll see them on the list but they aren't directly editable by typing into the cell. | Column | What it stores | Notes | |---|---|---| | **#** (Issue number) | Sequential number, unique within the engagement | Auto-assigned on create. Issue #1 is the first issue logged on this engagement, #2 is the second, and so on. | | **Latest Note** | A preview of the most recent visible note on the issue | Shows the body of the most recent note as a single-line preview, so you can see what the latest exchange was without opening the thread. Empty when there are no notes yet. Updates live when a new note is posted. Read-only — to add or change a note, click the **Notes** column. | | **Notes** | Count of notes on the issue | Shows *+ Add note* when the issue has no notes, or *💬 n* when it has *n*. Click to open the per-issue note thread. See [Add notes to an issue](../how-to/add-notes-to-an-issue). | | **Created by** | Email and display name of the person who logged the issue | Recorded from the active NetSuite session. | | **Created on** | Timestamp when the issue was logged | UTC. Displayed in your local timezone in the tracker. | | **Last updated by** | Most recent editor's email and display name | | | **Last updated on** | Most recent edit timestamp | | | **Linked UAT test** | The UAT test scenario this issue was raised against | Only set on issues raised from a scenario's 🚩 flag on the UAT tab. A scenario can have several linked issues. | ## Status — what each value means | Status | Meaning | |---|---| | **Open** | Newly created, not yet picked up. | | **In progress** | Someone is actively working on this. | | **Blocked** | Work has stopped, waiting on something else. | | **Done** | The issue has been resolved. | | **Won't do** | The issue has been discussed and a decision made not to action it. | Move issues between statuses by clicking the cell and choosing a new value. There's no enforced workflow — any user with access can move an issue to any status. By convention: * **Open → In progress** when work starts. * **In progress → Done** when the fix is verified. * **In progress → Blocked** if something stalls progress. * **Blocked → In progress** when the blocker clears. * Any → **Won't do** by mutual agreement, with a description note explaining why. ## Priority — when to use which | Priority | When to use | |---|---| | **Low** | Cosmetic or nice-to-have. Won't block go-live; the implementation can ship without it. | | **Medium** | Should be resolved before go-live but isn't blocking other work. Most issues land here. | | **High** | Must be resolved before go-live. | | **Critical** | Blocking other work right now. Stop and address. | Priorities are set by whoever logs the issue; FullClarity may adjust if a higher-than-warranted priority would crowd out other work. Triage conversations happen in the **Description** field rather than by silently bumping the priority down. ## Editing in place vs the form The **+ New Issue** form is mandatory only for creating a new issue with a title. Once the issue exists, all the editable fields above can be changed directly on the row by clicking the cell. There's no separate "Edit issue" view. The form is still useful when you want to fill in several fields at once and don't want to chase them across the row, or when you want to attach a screenshot via the **First note** field at the same time you create the issue. ## Related * [Log an issue](../how-to/log-an-issue) — creating and updating issues. * [Add notes to an issue](../how-to/add-notes-to-an-issue) — the per-issue note thread reached via the Notes column. * [Recording UAT results](./uat-statuses) — the pass checkbox, rollup, and issue states on the UAT tab. --- --- url: 'https://fullclarity.help/project-tracker/reference/permissions.md' --- # Permissions Who can open the Project Tracker, who can edit what inside it, and how visibility works between the customer side and the FullClarity side. \[\[toc]] ## Today's model in one sentence The tracker is **engagement-scoped, not user-scoped** — once a NetSuite user can open the tracker menu entry, they can see and edit everything in the workbook that the engagement exposes to the customer side. That's a deliberate choice for the implementation period: every person involved in setting up the SuiteApp benefits from seeing every issue and every UAT result, and small implementation teams don't need a per-user permissions layer to function. ## Who can open the tracker Anyone with access to the **FullClarity** menu in your NetSuite account. By default, the tracker is published with `All Roles` audience, so any role with menu access can launch it. If you need to restrict access to specific roles: 1. Open **Customization → Scripting → Scripts**. 2. Find the **FCTC Tracker Launcher** Suitelet. 3. Open its deployment record. 4. Set the **Audience** tab to the specific roles you want to expose it to. NetSuite administrators can always see all SuiteApp menu entries regardless of audience configuration. ::: tip Author input needed A standard set of recommended NetSuite roles for tracker users (project managers, accountants, administrators) has not been formally codified yet. For now, work with your FullClarity consultant to identify which existing roles in your account should have tracker access. ::: ## What everyone with access can do Once a user is inside the workbook, they can: * See every issue on the **Issues** tab (with the exception of issues FullClarity has marked as not customer-visible — see [Visibility](#visibility) below). * Create new issues, edit any field on any existing issue, regardless of who created it. * See every UAT scenario on the **UAT** tab, and every tester's pass column. * Tick their own pass column on any scenario, and raise an issue against any scenario (via the **🚩** flag). * Accept or reopen a FullClarity-fixed issue linked to a UAT scenario. * Post notes on any issue, with attachments. Delete their own notes. There's no role split between *editor* and *reader* inside the workbook. Anyone with menu access has full edit rights. The one per-user boundary on the UAT tab is that you can only tick **your own** pass column — other testers' pass columns are visible but read-only to you, so a pass always reflects who actually recorded it. ## Visibility The tracker exposes two visibility controls. Both are FullClarity-side concerns — they don't appear in the customer-side workbook — but they affect what customer-side users can see. ### Issue-level: customer visible Every issue has a **Customer visible** flag, controlled from the FullClarity side. It governs whether the whole issue (and its note thread) shows up in the customer-side workbook. * **Customer visible = on (default for customer-logged issues)** — the issue is visible on both sides. Almost every customer-logged issue stays here. * **Customer visible = off** — the issue is visible only to FullClarity. Used to track internal action items against the engagement (for example, a working session that needs to be scheduled) without surfacing them to the customer. ### Note-level: internal only When a FullClarity consultant posts a note on a visible-to-customer issue, they can mark the individual note as **Internal only**. The flag affects only that one note, not the whole issue: * **Internal only = off (default)** — the note is visible to both sides. * **Internal only = on** — only FullClarity-side users see the note. The customer-side workbook doesn't show it and doesn't count it in the issue's note badge. Customer-side users don't see the **Internal only** toggle on their composer, and any note they post is always visible to both sides. The toggle is a one-way valve for FullClarity to add private context (for example, an internal triage note) without splitting the issue into two. ### Notes posted by customers Customer-side users can't hide their notes from FullClarity. Anything a customer posts on a visible-to-customer issue is visible to both sides — which is the intent of the tracker as a shared workspace. ## Audit trail Every write to the tracker records who did it: * **Issues** — `created_by`, `last_updated_by` (email and display name) are stamped automatically from the NetSuite user calling the action. * **Notes** — every note records the author's email and display name, captured at post time. Deletes are soft (the note is hidden but not purged) and record who pressed Delete. * **UAT results** — each tester's pass tick is recorded against that tester; you can only tick your own pass column, so a tick always reflects the person who entered it. * **UAT issue acceptance** — accepting (or reopening) a FullClarity-fixed issue records who did it. These fields are not editable in the workbook — they're for audit, not assignment. To say *who is responsible* for an issue, use the **Assignee** picker, which is editable. ## What's hidden from customers entirely The tracker is **engagement-scoped**. From inside one customer's NetSuite account, the tracker can only see data for the engagement that account is bound to. There's no way to browse other engagements, other customers, or any FullClarity-side admin data. FullClarity staff use a separate web app (FullClarity Connect) to see across all engagements they're working on. The tracker has no awareness that any of that exists. ## Future direction Two things on the longer-term roadmap that aren't yet built: * **Per-user roles inside an engagement** — a future version may distinguish between *editor* and *reader* roles inside the workbook, particularly for larger engagements where some participants only need to observe. * **Restricting who can accept UAT fixes** — currently anyone with access can accept or reopen a FullClarity-fixed issue. A future option may restrict acceptance to a nominated role. Neither is on the current roadmap — flag the need to your FullClarity consultant if either matters for your engagement. ## Related * [Install & configure](../install-configure) — how the NetSuite administrator gates menu access during install. * [Log an issue](../how-to/log-an-issue) — creating and editing issues. * [Add notes to an issue](../how-to/add-notes-to-an-issue) — the note thread, attachments, and who can delete what. * [Run UAT](../how-to/run-a-uat-cycle) — including who records results and who accepts fixes. --- --- url: 'https://fullclarity.help/project-tracker/reference/uat-statuses.md' --- # UAT results & issue states How a UAT scenario's result is recorded and read on the **UAT** tab: the per-tester pass checkbox, the Pass/Fail rollup, and the states a linked issue moves through. \[\[toc]] ## The pass checkbox Each scenario row has **one pass checkbox per tester** taking part in UAT. Your own column is shown **first** and is the only one you can tick — everyone else's column is visible but read-only to you. Ticking your pass checkbox means: *"I ran this scenario and it behaved exactly as the Expected result described."* Leaving it un-ticked simply means you haven't passed it — whether you haven't run it yet, or it didn't behave correctly. There's no separate *untested*, *blocked*, *fail*, or *N/A* value: a scenario is either passed by you or not, and anything that doesn't behave as expected becomes an [issue](#raising-an-issue-from-a-scenario). Because each tester has their own column, you can see at a glance who has confirmed each scenario. One tester's tick is independent of another's. ## The Pass/Fail rollup Each row also has a read-only **Pass/Fail** column that summarises whether the scenario has passed *overall*. It is ticked (pass) only when **both** of these are true: 1. **At least one tester** has ticked their pass checkbox on the row, **and** 2. There is **no open issue** linked to the scenario. For this rule, a linked issue counts as **open** if it has **not yet been accepted** by the customer **and** is **not marked *Won't do***. So: * A scenario nobody has passed yet → rollup is **not** ticked. * A scenario a tester has passed, with no linked issue → rollup is **ticked**. * A scenario a tester has passed, but with a linked issue that hasn't been accepted (and isn't *Won't do*) → rollup stays **un-ticked** until that issue is resolved and accepted. In short, a linked issue keeps the rollup un-ticked until it's both resolved **and** accepted by you. ## Raising an issue from a scenario When a scenario doesn't behave as expected, click the **🚩 flag** in the raise-issue column on that row. This opens the **New Issue** form, pre-filled with a title like *UAT fail: \ — \* and automatically linked to the scenario. Complete or cancel the form as you would any issue — see [Run UAT](../how-to/run-a-uat-cycle) for the full flow. A single scenario can carry **more than one** linked issue. They appear together on the row (for example, as flag icons with issue numbers like ⚑ #3 #4), and *every* open one keeps the rollup un-ticked. ## Issue states on the UAT grid A linked issue shows on the scenario's row and moves through these states. Only the last two stop it blocking the **Pass/Fail** rollup: | State on the UAT grid | What it means | Blocks rollup? | |---|---|---| | **Open / In progress / Blocked** | The issue has been raised and FullClarity hasn't resolved it yet. | Yes | | **FullClarity-fixed, awaiting acceptance** | FullClarity has marked the issue *Done*. It stays visible as a **green** link until you confirm the fix. | Yes | | **Accepted** | You clicked **Accept** on the issue — the fix is confirmed good. The issue stays *Done* but no longer blocks the scenario. | No | | **Won't do** | Everyone agreed not to action the issue. It no longer blocks the scenario. | No | ### Accepting or reopening a fix When FullClarity marks a linked issue *Done*, it does **not** clear automatically — it stays as a green link on the scenario and keeps the rollup un-ticked until you decide: * **Accept** — you confirm the fix is good. The issue stops blocking the rollup (the scenario can now roll up to a pass, provided a tester has ticked their pass column). The issue's status stays *Done*. * **Reopen** — the fix didn't work. The issue goes back to *Open* and again blocks the rollup. Acceptance controls live on the **issue's notes panel**, reached by clicking the issue link from the UAT tab, or from the **Notes** cell on the **Issues** tab. ## What a healthy UAT picture looks like As an engagement progresses, you want every in-scope scenario to end up with its **Pass/Fail** rollup ticked — meaning a tester has passed it and any issues it threw up have been resolved and accepted. Scenarios with un-ticked rollups are the ones still needing attention: either nobody has run them, or they still have an open or unaccepted issue. The grid is, in effect, your live UAT checklist right up to go-live. ## Related * [Run UAT](../how-to/run-a-uat-cycle) — the testing workflow end-to-end. * [Log an issue](../how-to/log-an-issue) — including the issue raised from a scenario's flag. * [Issue fields](./issue-fields) — what the linked-to issue captures. --- --- url: 'https://fullclarity.help/retainage.md' --- # Retainage Retainage is the FullClarity SuiteApp that handles construction retention — the amounts you withhold on customer invoices and supplier bills, hold on the balance sheet, and then release back to settlement once project milestones are met. \[\[toc]] ## What retainage is In construction accounting, retention (or retainage) is a percentage of every progress claim held back as security until practical completion or another agreed milestone. It applies on both sides of a project: the head contractor withholds retention from their subcontractors' bills, and the customer withholds retention from the head contractor's invoices. The withheld amount sits on the balance sheet rather than in accounts receivable or accounts payable, and is released via a separate retention claim transaction when the milestone is reached. Manually maintaining retention journals is error-prone — the rate varies by contract, by line, sometimes by stage of the project, and the released amount has to reconcile against the original withholdings invoice by invoice. ## What the SuiteApp does Retainage automates the full cycle on both the receivables and payables sides: * **Capture** retention per line on any Invoice, Credit Memo, Vendor Bill or Vendor Credit, using percentage or amount column fields * **Post the withholding journal** automatically on save — moving the retained amount from accounts receivable (or accounts payable) to a dedicated balance-sheet retention account * **Drive retention claims** through dedicated suitelets that let you release withheld balances line by line, with running totals and claim-to-date tracking * **Handle tax retention** as a separate sub-flow when the tax component on the underlying invoice is also held back * **Support OneWorld** with a separate configuration record per subsidiary, so the right general ledger accounts are used in each * **Cap retention** by percentage or dollar amount at the project level, and apply tiered/sliding rates that change as the project progresses A combined Retainage subtab on each project record shows accumulated withholdings on both sides, plus the retention tier sublist where used. ## Capture vs claim It helps to think of retainage as two related but separate flows: **Capture** happens automatically every time an invoice or bill is saved. The retention rate is sourced from the project (or, if not set there, the customer or vendor), applied to each line, and posted to a withholding journal in the background. You don't have to do anything beyond making sure the rate is set correctly. **Claim** happens when you're ready to release retention — typically at practical completion or final handover. You open the claim suitelet from the project or vendor record, choose which withholdings to release, and the system generates the retention invoice (or retention bill on the payables side) that moves the balance back to accounts receivable or accounts payable for settlement. ## Where this fits in the ecosystem Retainage works alongside the other Construction SuiteApps: * **Project Financials** is where the project is created and where retention rates are set at the project level. The Retainage subtab appears inside the same project record. * **Subcontracts** uses the AP side of Retainage when a head contractor withholds retention from subcontractor claims. See the [Subcontracts](/subcontracts) section for how subcontract claims interact with retention. ## Next steps * [Quick start](/retainage/quick-start) — the happiest path from install to your first retention withholding * [Install & configure](/retainage/install-configure) — the per-subsidiary configuration record and required NetSuite features * [Set up retainage on a contract](/retainage/how-to/set-up-retainage-on-a-contract) — set the default rate at vendor and project level * [Issue a retainage claim](/retainage/how-to/issue-a-retainage-claim) — release withheld balances on the AR side * [Release retainage at handover](/retainage/how-to/release-retainage-at-handover) — final AR and AP release flows --- --- url: 'https://fullclarity.help/retainage/how-to/issue-a-retainage-claim.md' --- # Issue a retainage claim Release withheld retention on the receivables side by creating a Retainage Invoice — the transaction that moves the retained balance back into accounts receivable for customer settlement. \[\[toc]] ## When to use this Use this when the contract milestone that releases retention has been reached — typically practical completion, defects liability period start, or final handover — and you need to invoice the customer for the retained amount. The claim suitelet lets you release retention selectively, line by line, against the project's outstanding withholdings. ## Prerequisites * The project has at least one Retainage Withheld journal (i.e. retention has previously been captured on a customer invoice for this project) * Permission to create the AR Retainage Invoice transaction type — see [Permissions](../reference/permissions) * The contract milestone for releasing this retention has been reached (the SuiteApp doesn't enforce this — it's a process discipline) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the **project (Job) record** where the retention was withheld. 2. Click the **Create Retainage Claim** button at the top of the record. (If your administrator has renamed the button, it may appear under a different label.) 3. The Retainage Claim suitelet opens, with one row per outstanding AR withholding on the project. Each row shows the source invoice, its date, the original invoice amount, the amount retained on that invoice, and how much of that retention has already been claimed. 4. Enter the **Amount Claimed** for each line you want to release. As an alternative, enter a **Percent Claimed** and the amount back-calculates from the remaining retained balance. If your administrator has enabled **Autofill Max Percentage for Receivables** on the Configuration record, the form opens with every line pre-filled at the maximum claimable. 5. (Optional) Review the running totals at the bottom of the sublist — Total Amount Retained, Total Already Claimed, Total Claimed This Run. 6. Click **Submit** to create the Retainage Invoice. 7. The new AR Retainage Invoice opens in view mode. Its accounting effect is to debit the Retention Claim Debit account (typically your main accounts receivable) and credit the Retention Debit account (the balance-sheet holding account), releasing the retention back to AR. ## What success looks like * A new **FC AR Retainage Invoice** transaction exists, linked to the project, with one line per withholding you claimed against. * The project's **Invoice Amount Retained** rollup on the Retainage subtab has decreased by the total amount claimed. * The customer's accounts receivable balance increases by the amount claimed — they now owe the retention amount as a normal AR balance. * The original Retainage Withheld journals still exist but now show an **Amount Claimed** that matches what was released. Subsequent claims against the same withholdings can only release up to the remaining balance. ## Gotchas * **The claim form shows only outstanding withholdings.** Once a withholding has been fully claimed, it drops off the list. If you can't find a particular invoice on the claim form, check whether it has been claimed previously by opening the project's Retainage subtab. * **Tax retention claims separately.** If your Configuration has **Tax Retention** enabled, the Tax Amount Claimed column appears alongside the principal amount and the released tax journal posts to the dedicated Tax Retention Account. Don't claim the principal without claiming the tax if both were originally withheld. * **AIA-style print template.** The AR Retainage Invoice ships with an Advanced PDF template that renders an AIA-style summary showing claim-to-date, this claim, and original invoice amount. The "Print AIA" button is available on the invoice view. If the button doesn't appear, your administrator may need to set the default PDF template on the Script Parameters. * **Approval status.** The AR Retainage Invoice has Unapproved and Approved statuses — only Approved invoices post to the general ledger. If your accounts team requires approval before claims hit AR, leave new invoices Unapproved and have the approver flip the status. * **AP retention is a separate flow.** This how-to covers the AR side only. To release withholdings from a vendor's bills, use the Payable Retainage Claim from the vendor record — see [Release retainage at handover](./release-retainage-at-handover) for both sides. ## Related * [Release retainage at handover](./release-retainage-at-handover) — the AR final-release and AP-release flows * [Set up retainage on a contract](./set-up-retainage-on-a-contract) * [Permissions](../reference/permissions) --- --- url: 'https://fullclarity.help/retainage/how-to/release-retainage-at-handover.md' --- # Release retainage at handover The final release flows on both sides of a project — issuing the closing AR retention invoice to your customer, and recording the closing AP retention bill from your subcontractors and suppliers. \[\[toc]] ## When to use this At practical completion, end of defects liability period, or final handover — whatever milestone the contract specifies as the trigger for releasing the last of the retention. Most projects have one or two scheduled releases (e.g. half at practical completion, half at end of DLP); the final release happens when the last withholding balance needs to be settled. This how-to covers both sides: * **AR release** — invoicing the customer for the retention you've been holding from their account. * **AP release** — recording the retention bill from a subcontractor or supplier so you can settle the retention you've been holding against their account. ## Prerequisites * All outstanding withholdings to be released exist on the project / vendor record * The contract milestone that releases retention has been reached * Permission to create retainage claim transactions — see [Permissions](../reference/permissions) * For AP: the vendor has sent you a retention claim invoice (or your contract requires you to release retention without one) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: ### AR final release — releasing retention you've held from a customer This is the AR side, mirroring [Issue a retainage claim](./issue-a-retainage-claim) but specifically for the final release at handover. The process is the same; the difference is intent — at final release you typically release every remaining withholding on the project rather than a partial claim. 1. Open the project (Job) record at handover. 2. Click **Create Retainage Claim**. 3. The Retainage Claim suitelet opens with every outstanding AR withholding listed. 4. If your administrator has enabled **Autofill Max Percentage for Receivables**, the form opens with every line pre-filled at the maximum claimable — useful for a final release. If not, enter `100%` in **Percent Claimed** on each line, or click each line's max-amount control. 5. Submit. The AR Retainage Invoice is created with one line per withholding being closed out. 6. Print the AIA-style retention invoice (the **Print AIA** button on the new invoice view) and send to the customer for payment. After the customer pays, the project's **Invoice Amount Retained** rollup will show zero — every withholding has been claimed and settled. ### AP release — recording the retention bill from a subcontractor or supplier When you've been withholding retention from a vendor's bills, the vendor will eventually invoice you for the retained amount. Retainage's AP claim flow records that bill and posts the GL entry that releases the withheld balance back to accounts payable. 1. Open the **vendor record** in NetSuite. (You can do this from the project too — the AP release is usually triggered per vendor rather than per project.) 2. Click **Create Payable Retainage Claim**. (If your administrator has renamed the button, it may appear under a different label.) 3. The Payable Retainage Claim suitelet opens, with one row per outstanding AP withholding for this vendor. Each row shows the source bill, its date, the original bill amount, and the amount retained. 4. (Optional) If you want to filter to a specific project, select the project at the top of the form — the suitelet will narrow the list to withholdings attributed to that project. 5. Enter the **Amount Claimed** (or **Percent Claimed**) for each line you want to release. 6. Enter the vendor's reference number (e.g. the invoice number from the vendor's retention invoice) in the reference field. 7. Submit. A new **FC AP Retainage Bill** transaction is created and posts to the GL — debiting the Bill Credit account (releasing the AP retention liability) and crediting the Bill Debit account (restoring the balance to accounts payable). 8. The retention bill now appears in accounts payable for settlement like any normal vendor bill. ## What success looks like * For AR: the project's **Invoice Amount Retained** has fallen to zero (or to the next-scheduled-release balance if you're doing a partial release). * For AP: the vendor's **Retainage** subtab shows no outstanding withholdings, or only those scheduled for a later release. * Both the AR Retainage Invoice and AP Retainage Bill show their full claim line history — claim-to-date, this claim, and the source transaction. * The GL effect on both sides has the same shape — moving the retained amount off the balance-sheet retention account and back into AR/AP for settlement. ## Gotchas * **Settle the underlying bill first.** On the AP side, if the original supplier bill is still unpaid for its non-retained portion, settle that first. The retention bill is a separate transaction and should be paid (or netted) separately, normally only once the retention release has been triggered. * **AP retention and tax retention.** When **Tax Retention** is enabled, the AP release also reverses the tax portion. Make sure the vendor's retention invoice includes the tax component — otherwise the GL effect won't reconcile cleanly against the original withholding. * **Cancellation and credit memos.** If a release has been raised in error, the credit variant of the transaction (FC AR Retainage Invoice Credit or FC AP Retainage Bill Credit) can be used to reverse it. Don't simply delete the claim transaction — the running claim-to-date totals on the linked withholdings won't recalculate. * **AP release without an invoice.** Some contracts require the head contractor to release retention without waiting for a supplier invoice. You can still raise the AP Retainage Bill — it acts as the closing transaction either way. Use the vendor's standard payment terms or a contract reference in the reference field. * **Final release of a project with multiple subsidiaries.** Releases happen per Configuration record. If a project spans subsidiaries (unusual but possible in OneWorld), each subsidiary's withholdings are released against that subsidiary's Configuration accounts. * **Splitting a release across multiple projects.** If a vendor's retention spans several projects, the AP claim suitelet will let you select withholdings from across the vendor's whole project portfolio. Use the project filter at the top of the form if you only want to release one project's worth. ## Related * [Issue a retainage claim](./issue-a-retainage-claim) — the AR side in more detail * [Set up retainage on a contract](./set-up-retainage-on-a-contract) * [Permissions](../reference/permissions) --- --- url: 'https://fullclarity.help/retainage/how-to/set-up-retainage-on-a-contract.md' --- # Set up retainage on a contract Define the default retention rate that applies to invoices and bills on a project — at the vendor level, the project level, or via a sliding matrix that changes as the project progresses. \[\[toc]] ## When to use this Whenever a new project (or a new vendor on an existing project) needs retention captured at a non-zero rate. Most accounts set rates at two layers: a vendor-level default that applies to every bill from a particular subcontractor, and a project-level default that overrides it for the customer side of a specific job. For projects with bespoke retention terms — for example 10% until the project is 50% complete, then 5% — use the sliding retention matrix instead of a flat rate. ## Prerequisites * Retainage installed and a Configuration record in place for the subsidiary * An active project, vendor, or customer record to set the rate on * Permission to edit the entity record (project, vendor, or customer) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: ### Set the project default for AR retention 1. Open the project (Job) record. 2. Go to the **Retainage** subtab. 3. Enter a percentage in **Invoice Retainage %** — for example, `10%` for a 10% retention rate on every customer invoice on this project. 4. (Optional) Enter a separate **Time Retainage %** if billable time entries on this project use a different retention rate to item-based lines. 5. Save the project. The rate will be applied to every new invoice that links back to the project. ### Set the vendor default for AP retention 1. Open the vendor record. 2. Locate the **Retainage %** field — typically on the Retainage subtab on the vendor record, though it may have been moved to a different subtab on a customised form. 3. Enter the default retention rate for every bill from this vendor. 4. Save. You can also set a vendor-style rate at the project level by entering a value in **Purchase Retainage %** on the project's Retainage subtab. That overrides the vendor default for bills attributed to this specific project. ### Cap the retention by amount or percentage When a contract specifies a maximum retention — for example, retention caps out at $50,000 regardless of how much has been invoiced — set the cap on the project: * **Retainage Cap %** — caps cumulative retention as a percentage of the contract value. * **Retainage Cap $** — caps cumulative retention as a fixed dollar amount. Once the cap is reached, subsequent invoices will not have further retention withheld. ### Use a sliding (tiered) retention matrix For contracts where the retention rate changes as the project progresses, switch the project from a flat rate to a sliding matrix: 1. On the project's **Retainage** subtab, tick **Enable Retention Tiers**. 2. Click **Update Retention Tiers** — the Sliding Retention suitelet opens. 3. Enter each tier as a row: the percent-complete threshold and the retention rate that applies in that band. For example: * 0% to 50% complete — 10% retention * 50% to 90% complete — 5% retention * 90% complete onward — 0% retention 4. Save the matrix. Subsequent invoices will calculate retention by looking up the project's current percent complete and applying the matching rate. When tiers are enabled, the flat **Invoice Retainage %** field is ignored on that project. ### Override the rate per invoice line The rate can also be set or overridden line by line on the invoice or bill itself. Each line has its own **Retainage %** and **Retainage Amount** column fields — change either and the system recalculates the line's retention. Use this when most lines on an invoice follow the project default but one or two need different treatment. ## What success looks like * The next invoice or bill saved against the project (or vendor) shows retention populated on every applicable line, totalling correctly in the body Retention Amount field. * The project's Retainage subtab updates the **Invoice Amount Retained** rollup the first time a withholding posts. * For tiered projects, the rate applied matches the band that corresponds to the project's current percent complete. ## Gotchas * **Project rate overrides customer rate.** If both are set, the project rate wins on invoices attributed to that project. This is by design — projects are the most specific scope. * **Enabling tiers hides the flat rate field.** Once **Enable Retention Tiers** is ticked, the flat **Invoice Retainage %** is no longer used. Don't both set a flat rate and enable tiers expecting them to combine. * **Tier transitions are evaluated at invoice save time.** A project sitting at 49% complete will use the lower-band rate even if the invoice you're saving will push it past 50%. If you need the new band to apply, save the percent-complete update first. * **Sliding matrix can be edited mid-project.** Changing the matrix doesn't retrospectively reprocess prior withholdings — it only affects invoices saved from that point onward. * **AP and AR rates are tracked separately.** A project's **Invoice Retainage %** drives AR retention; **Purchase Retainage %** (or the vendor's default) drives AP retention. They are independent. ## Related * [Issue a retainage claim](./issue-a-retainage-claim) * [Release retainage at handover](./release-retainage-at-handover) * [Install & configure](../install-configure) --- --- url: 'https://fullclarity.help/retainage/install-configure.md' --- # Install & configure Install the SuiteApp, enable the prerequisite NetSuite features, and create one Retainage Configuration record per subsidiary so retention can be captured against transactions in that subsidiary. \[\[toc]] ## Module requirements Retainage needs the following NetSuite features enabled. Any that aren't already on will be flagged automatically during install — go to **Setup → Company → Enable Features** to turn them on. **Required features** * Accounting * Jobs * Custom Records * Custom Transactions * Server-Side Scripting * Advanced Printing * Custom GL Lines * Workflow **Commonly used optional features** * Subsidiaries (for OneWorld accounts) * Expense Reports (to capture retention on expense lines) * Time Tracking (to capture retention on billable time) * Multi-Subsidiary Customer (when customers trade with more than one subsidiary) ## SuiteApp dependencies Retainage depends on the **Code Library** SuiteApp, which installs automatically when you install Retainage from the SuiteApp Control Centre. If you intend to use the Project Financials integration, install Project Financials as well — Retainage detects it at runtime and exposes the claim-link field on the AR withholding when present. ## Installing the SuiteApp 1. In NetSuite, navigate to **Customisation → SuiteApps → SuiteApp Control Centre**. 2. Find **FullClarity Retainage** and click **Install**. 3. Accept the dependency prompt for Code Library if Code Library isn't already installed. 4. Wait for the install to complete — the post-deploy script creates the two retention balance reports and the rename-buttons reference record. ## The Retainage Configuration record Retainage needs one Configuration record per subsidiary. In a single-subsidiary account select **Parent**; in OneWorld accounts create one record per subsidiary that captures retention. Without a Configuration record, retention can't be saved against transactions in that subsidiary. Navigate to **FullClarity → Retainage → Configuration → New** to create one. ### Subsidiary * **Subsidiary** — the subsidiary this configuration applies to. Select **Parent** in single-subsidiary accounts. ### Accounts Receivable accounts * **Retention Debit** — the balance-sheet account where the retained portion of an AR invoice lives until it's claimed. Typically an Other Current Asset or Other Asset account (not your main accounts receivable). * **Retention Credit** — typically your main Accounts Receivable account. When retention is captured on an invoice, this account is credited to remove the retained portion from AR. * **Retention Claim Debit** — typically your main Accounts Receivable account. When the retention is claimed (released for settlement), the claim balance lands here for the customer to pay. * **Retention Claim Receivable Item** — the item used on retention claim invoices (commonly named "Receivable Retention Request"). Its income account should match the Retention Debit account so the GL effect of the claim reverses cleanly. ### Accounts Payable accounts * **Bill Debit** — typically your main Accounts Payable account. When AP retention is captured, this account is debited to reduce AP by the retained amount. * **Bill Credit** — a balance-sheet Other Current Liability account that holds AP retention payable until release. * **Bill Claim Payable Item** — the item used on retention bill claims when releasing AP retention. ### Autofill behaviour * **Autofill Max Percentage for Receivables** — when ticked, opening the AR claim suitelet pre-fills the claim percentage to the maximum claimable on each line. * **Autofill Max Percentage for Payables** — the same for the AP claim suitelet. ### Tax retention * **Tax Retention** — tick this to also withhold the tax (GST/VAT) component of the retained line. Required for jurisdictions where the tax follows the underlying payable. * **Tax Retention Account** — the general-ledger account where retained tax sits. Typically the same account that holds GST or VAT payable. Required when Tax Retention is enabled. ### Standard-mode forms (advanced) Retainage can post withholdings and claims either as dedicated custom transactions (the default) or as standard NetSuite journal entries, invoices and vendor bills. If your administrator has switched the SuiteApp into standard mode, four extra form selects appear so you can choose which forms are used: * **Standard Retention Invoice Claim Form** — used when claims are raised as standard Invoices. * **Standard Retention Bill Claim Form** — used when AP claims are raised as standard Vendor Bills. * **Standard Retention AR Withheld Form** — used when AR withholdings are posted as standard Journal Entries. * **Standard Retention AP Withheld Form** — used when AP withholdings are posted as standard Journal Entries. The default custom-transaction mode keeps retention transactions distinct from your normal AR/AP and is generally easier to report on. Switch to standard mode only if your business needs retention transactions to behave like ordinary NetSuite invoices and bills. ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for the configuration record is being recorded. Track its status in the Scribe register (internal). ::: ## What success looks like * Navigating to **FullClarity → Retainage → Configuration** shows one Configuration record per subsidiary in your account. * Opening any project's **Retainage** subtab shows the rate fields (Invoice Retainage %, Purchase Retainage %, caps) and the withholdings sublist — not an error. * Saving an invoice on a project with a non-zero retention rate creates a Retainage Withheld journal automatically. ## Gotchas * **One Configuration record per subsidiary is mandatory.** If a Configuration record is missing for a subsidiary, saving an invoice or bill in that subsidiary will fail. The error message generally references a missing GL account; the real fix is to create the Configuration record. * **Account / subsidiary mismatch.** Every selected account must belong to the subsidiary chosen on the Configuration record (or to its parent in OneWorld). The Configuration form's client script flags this on edit, but if you save a server-side change with a mismatched account the first invoice post in that subsidiary will fail. * **Retention Claim Item account.** If the Retention Claim Receivable Item is set to an income account that doesn't match the Retention Debit, the claim invoice's GL effect will not cleanly reverse the original withholding. Check the item's income account first. * **Tax Retention is global once enabled.** Turning Tax Retention on for one subsidiary doesn't switch it on everywhere — but the per-line tax retention amount is captured on every transaction whether or not Tax Retention is enabled in the subsidiary's Configuration. Make sure the Tax Retention Account is set if you're enabling the feature. ## Related * [Set up retainage on a contract](./how-to/set-up-retainage-on-a-contract) — vendor and project default rates * [Permissions](./reference/permissions) — granting access to custom roles --- --- url: 'https://fullclarity.help/retainage/quick-start.md' --- # Quick start The fastest path from a fresh Retainage install to seeing a retention withholding hit the ledger on a real invoice. \[\[toc]] ## The happiest path 1. **Install Retainage** from the SuiteApp Control Centre. Code Library installs as a dependency if it isn't already in place. 2. **Create a Retainage Configuration record for your subsidiary.** Set the four required general-ledger accounts (Retention Debit, Retention Credit, Bill Debit, Bill Credit) and the Retention Claim Receivable Item. In single-subsidiary accounts select **Parent** as the subsidiary. 3. **Set a default retention rate at the project level** — open the project, locate the **Invoice Retainage %** field on the Retainage subtab, and enter a value (for example, 10%). 4. **Save an invoice on the project.** On save, the system posts a companion **Retainage Withheld** journal that moves the retained amount from accounts receivable to the balance-sheet retention account configured on your subsidiary's record. 5. **Open the project's Retainage subtab** to see the new withholding row, the running balance, and the link back to the source invoice. That's the capture half of the cycle. The release half — issuing a retention claim — is covered in [Issue a retainage claim](./how-to/issue-a-retainage-claim). ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this quick start is being recorded. Track its status in the Scribe register (internal). ::: ## What success looks like * The Retainage subtab on your project shows a non-zero **Invoice Amount Retained**. * The Retainage Withheld journal lists the new entry, debiting the Retention Debit account and crediting the Retention Credit account. * The original invoice's accounts receivable balance has been reduced by the retained amount — only the non-retained portion is outstanding for settlement. ## Common stumbling blocks * **Save fails with a posting error.** Almost always a missing Configuration record for the invoice's subsidiary, or a wrong account selected. Open the Configuration record and confirm each account belongs to the same subsidiary as the invoice. * **No retention is calculated on save.** Check that the project's Invoice Retainage % is set and not zero. If you've enabled retention tiers on the project, the flat percentage is ignored — see [Set up retainage on a contract](./how-to/set-up-retainage-on-a-contract). * **The withholding journal does not appear.** The journal posts asynchronously on save via a user-event script. Refresh the project's Retainage subtab. If it still doesn't show up after a minute, check that the project has at least one Project record link on the invoice (Retainage uses the project to attribute the withholding). ## Next steps * [Install & configure](./install-configure) — full configuration walkthrough including tax retention and OneWorld * [Set up retainage on a contract](./how-to/set-up-retainage-on-a-contract) — vendor- and project-level default rates, caps, and tiered matrices --- --- url: 'https://fullclarity.help/retainage/reference/permissions.md' --- # Permissions How Retainage grants access to its custom transaction types and admin utilities. \[\[toc]] ## The challenge with custom transactions Retainage registers six custom transaction types (AR Retainage Invoice, AR Retainage Invoice Credit, AR Retainage Withheld, AP Retainage Bill, AP Retainage Bill Credit, AP Retainage Withheld). NetSuite custom roles do not automatically inherit permissions for newly installed custom transactions — they have to be granted explicitly. Out of the box, only the Administrator role and the bundled **FC Retainage Admin** role can use the new transaction types. ## The bundled FC Retainage Admin role A sample administrator role ships with the SuiteApp: * Full access to all six FC Retainage custom transactions * Edit on Invoice, Credit Memo, Vendor Bill, Purchase Order, Customer Payment, Vendor Payment * Edit on Projects (Jobs) and Vendors * View on Items, Units of Measure, Accounting Lists * View on AR, AP, Balance Sheet, Cash Flow and Account Detail reports * Full access to the Retainage custom records (Configuration, Information, Rename Records) Use this role as a reference for what permissions your retention-handling users need, or assign it directly if it matches your organisation's segregation-of-duties model. ## Granting access to your own custom roles For custom roles in your account (such as a project-manager role that includes retention claim authority), use the **Assign Permissions** utility: 1. Navigate to **FullClarity → Retainage → Assign Permissions**. 2. Select the custom role to grant access to. 3. Submit. The role is granted the appropriate retainage custom-transaction permissions, and a record of the grant is stored in the FC Retainage Information record so the SuiteApp can track which roles have been granted access. If a role is deleted, run the same utility and remove its Information record to keep the registry clean. ## Which roles should be granted Retainage access? Retainage access is needed by anyone who creates, posts, or oversees retention transactions. As a rule of thumb, grant Retainage permissions to: | Role type | Why they need Retainage access | |---|---| | **AR Clerks / AR Specialists** | Issue retention invoices and credit memos against customer claims; post the withheld journals on the AR side | | **AP Clerks / AP Specialists** | Receive and process retention bills against vendor claims; post the withheld journals on the AP side | | **Project Managers** | Submit claims that include retention; understand the retention balance on their projects | | **Project Accountants** | Reconcile the Project Total Retained balances; release retention at handover | | **Controllers / Financial Controllers** | Oversee AR and AP retention balances across the organisation; sign off on releases | | **CFOs / Finance Directors** | Run the retention balance reports and dashboards | Conversely, the following do **not** typically need Retainage access: * Sales or estimating-only roles that don't touch billing. * Operational roles (timesheet entry, inventory) that don't see project financial transactions. * External stakeholders or read-only audit roles — give them View access to the underlying invoices and bills only. ::: tip Retainage is granted separately from Project Financials A role granted Project Financials access through the PF *Assign Permissions* utility does **not** automatically receive Retainage access. If a user needs both — for example, a Project Manager who creates claims that include retention — you must grant the role through both utilities in turn. The two Suitelets each manage their own SuiteApp's custom records and transactions independently. ::: ## Revoking access To remove a role's FC Retainage access: 1. Navigate to **FullClarity → Retainage → Assign Permissions**. 2. Select the role to revoke from the *Selected Role* dropdown. 3. Click **Revoke**. The Suitelet removes every FC Retainage custom record and custom transaction line from the role's permissions, and removes the role from the FC Retainage Information record's registry. Unlike some other FullClarity SuiteApps, Retainage's revoke is fully symmetric with its grant — the role is returned to exactly the state it was in before Retainage permissions were applied. ## Related * [Install & configure](../install-configure) * [Issue a retainage claim](../how-to/issue-a-retainage-claim) * [Release retainage at handover](../how-to/release-retainage-at-handover) --- --- url: 'https://fullclarity.help/subcontracts.md' --- # Subcontracts Subcontracts is the FullClarity capability that lets head contractors manage subcontractor work end-to-end — from the day a subcontract is awarded through every variation, every progress claim, and every payment. \[\[toc]] ::: tip Early access The Subcontracts feature is currently in early access with selected customers. Activation is opt-in per subsidiary — talk to your customer success contact at FullClarity to enable it on your NetSuite account. ::: ## What this covers Subcontracts spans three FullClarity apps because there are two audiences working on opposite sides of the same contract: * **Head contractor** uses **Project Financials** inside NetSuite to set up subcontracts, raise and approve variations, assess incoming progress claims, issue payment schedules on NZ CCA subcontracts, and convert approved claims into vendor bills. * **Subcontractor** uses **Connect Mobile** to submit progress claims, and **Connect** (web) to look over the purchase orders and projects the head contractor has shared with them. The three apps share a single source of truth — your NetSuite account. Whatever the subcontractor submits in Connect arrives in NetSuite; whatever the head contractor approves in NetSuite flows back to Connect. ## The life of a subcontract 1. **Head contractor creates** the Subcontract in NetSuite, including the Schedule of Values (the line items the sub will claim against). 2. **Subcontractor signs in** to Connect Mobile and sees the work orders issued to them. 3. **Subcontractor submits** a progress claim from the mobile app. 4. **Head contractor assesses** the claim line-by-line, optionally adjusting amounts and recording reasons. 5. **Head contractor finalises** the assessment, which records an immutable snapshot of what was assessed and why. On **NZ CCA** subcontracts, the head contractor can then generate and send the statutory **Payment Schedule** from the claim itself — see [Issue a payment schedule](/subcontracts/head-contractor/issue-a-payment-schedule). On **AU SOP Act** and **UK HGCRA** subcontracts, the equivalent document (Payment Schedule / Pay Less Notice) is **not generated by the system** — issuing it remains the head contractor's responsibility. 6. **Approved claim converts to a Vendor Bill** in NetSuite, which AP pays through the normal payment cycle. 7. **Variations** raised during the contract follow a parallel approval workflow with delta-context visibility — approvers see the original value, prior-approved variations, and the specific change up for approval. ## Three audiences, three sub-sections * [For head contractors](/subcontracts/head-contractor) — create subcontracts, raise and approve variations, raise back-charges, assess claims, issue payment schedules (Project Financials in NetSuite) * [For subcontractors — mobile](/subcontracts/subcontractor-mobile) — sign in, view work orders, submit progress claims (Connect Mobile) * [For subcontractors — web](/subcontracts/subcontractor-web) — view the purchase orders issued to you (Connect web) * [Reference: Subcontract states](/subcontracts/reference/subcontract-states) — the lifecycle states a subcontract moves through * [Reference: Prequalification](/subcontracts/reference/prequalification) — the compliance-document check made when a subcontract is signed ::: warning New Zealand: NetSuite ANZ Localization is required To run NZ CCA subcontracts, your NetSuite account needs Oracle's **ANZ Localization** SuiteApp installed. The Payment Schedule relies on its **RCTI** (recipient-created tax invoice) box on the vendor record to decide whether to issue a buyer-created tax invoice. Without ANZ Localization, there is no RCTI box, so every subcontractor is treated as having no buyer-created tax invoice agreement: the schedule is issued as an ordinary Payment Schedule, with no GST lines and no tax invoice number. Ask your NetSuite administrator to confirm it's installed before you start. ::: ## A note on permissions Subcontracts permissions live in two places. As a **head contractor**, what you can do is governed by your Project Financials permissions in NetSuite — see [Project Financials > Permissions](/project-financials/reference/permissions). As a **subcontractor**, what you can see in Connect is governed by the relationship between your organisation and the head contractor's organisation; your administrator manages this through Connect's portal access controls. There is no separate "Subcontracts permissions" page because these two models work end-to-end through the cooperation of the apps — they aren't a single thing. ## Glossary (terms used throughout this section) | Term | Meaning | |---|---| | Schedule of Values (SoV) | The line-item breakdown of what's in a subcontract — what the sub will claim against | | Revised Contract Value (RCV) | Original contract value + sum of all approved variations | | Variation | A change order against an existing subcontract — adds or removes scope | | Progress claim | A claim covering one billing cycle (typically a month) — the sub's invoice | | Payment Schedule | The head contractor's statutory response to a progress claim (AU / NZ). On **NZ CCA** subcontracts the head contractor generates and sends it from the claim — see [Issue a payment schedule](/subcontracts/head-contractor/issue-a-payment-schedule). On **AU SOP Act** subcontracts it is still not generated by the system | | Pay Less Notice | The UK equivalent of a Payment Schedule | | Practical Completion (PC) | The subcontract milestone marking the end of active work | --- --- url: 'https://fullclarity.help/subcontracts/head-contractor.md' --- # For head contractors If you're the contractor running the project — the customer of the subcontractor — this is your section. All of your work happens in **NetSuite** (Project Financials). \[\[toc]] ## What you'll do here * [Create a subcontract](/subcontracts/head-contractor/create-a-subcontract) — set up a new subcontract on a project, including the Schedule of Values * [Raise a subcontract variation](/subcontracts/head-contractor/raise-a-subcontract-variation) — add or remove scope, saying which contract line each change varies * [Approve a subcontract variation](/subcontracts/head-contractor/approve-a-subcontract-variation) — review and approve scope changes with full delta context * [Raise a back-charge](/subcontracts/head-contractor/raise-a-back-charge) — reverse a previously-approved variation or deduct cost from a sub * [Assess a subcontractor claim](/subcontracts/head-contractor/assess-a-subcontractor-claim) — review a claim line-by-line, finalise the assessment, convert to a Vendor Bill * [Issue a payment schedule](/subcontracts/head-contractor/issue-a-payment-schedule) — generate and send the statutory Payment Schedule on NZ CCA subcontracts ## Where head contractors work Your work happens **inside NetSuite**, on the Subcontract record, the Variation record and the Claim record. NetSuite is the source of truth. Connect is the subcontractor's side of the contract, not yours — there is no head-contractor assessment surface in Connect. ## Requires * Project Financials installed and configured — see [Install & configure](/project-financials/install-configure) * The Subcontracts feature enabled for your subsidiary (opt-in — contact your FullClarity customer success contact) * An active project — see [Create a project](/project-financials/how-to/create-a-project) * The vendor exists as a Subcontractor-flagged Vendor record in NetSuite ## A note on jurisdictions The Subcontracts feature supports four compliance models — **AU SOP Act**, **NZ CCA**, **UK HGCRA**, and **US General** (plus **None** for projects where no statutory framework applies). Your subsidiary's Compliance Model drives the statutory response window and the jurisdiction-specific fields captured on a claim. On **NZ CCA** subcontracts, the Payment Schedule itself is generated and sent from the claim — see [Issue a payment schedule](/subcontracts/head-contractor/issue-a-payment-schedule). On **AU SOP Act** and **UK HGCRA** subcontracts, the response document (Payment Schedule / Pay Less Notice) is **not generated by the system**; issuing it remains your responsibility. Detail by jurisdiction is in [Subcontract states](/subcontracts/reference/subcontract-states). --- --- url: >- https://fullclarity.help/subcontracts/head-contractor/approve-a-subcontract-variation.md --- # Approve a subcontract variation Review and approve (or reject) a variation against an existing subcontract, with full delta context — original contract value, prior approved variations, and the specific change up for approval — and let the system amend the linked Purchase Order automatically. \[\[toc]] ## When to use this When a subcontractor (or your own project manager) raises a change against an existing subcontract — additional scope, scope reduction, rate change, or defect-driven adjustment — and the variation is now sitting in **Pending Approval** waiting for your decision. ## Prerequisites * Subcontract in **Signed**, **Active**, **PC**, or **DLP** status (variations can't be raised against Draft or Closed) — see [Subcontract states](../reference/subcontract-states) * The Variation has been created and submitted for approval — variations can come from three places: * The **New FC PF Subcontract Variation** button on the Subcontract's Variations subtab — see [Raise a subcontract variation](./raise-a-subcontract-variation) * An **approved variation cost estimate** (fan-out from the estimating side) * **Cloning** an existing variation as a template * Permission to approve variations for this subcontract's subsidiary ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the Variation record in **Pending Approval** status (from the dashboard reminder, an email notification, or the Subcontract's **Variations** subtab, which lists each variation's ID, Description, Variation Type, Value (Signed) and Status). 2. Review the **Summary** box at the top right of the form. It shows: * **Original Contract Value** — the subcontract value at award * **Approved Variations** — the total of variations already approved * **Contract Value Before** — the contract value before this variation * **Additions**, **Deductions** and **This Variation** — the change in front of you. This Variation is the same as the variation's **Value (Signed)**, the total of its lines * **Revised If Approved** — what the contract will become if you approve 3. On the **Schedule of Values** subtab, review the variation lines — what scope is being added or removed, its Item, Cost Centre and Phase, and the **Varies Line** each one changes. Every deduction varies a specific line; an addition with no Varies Line is a new item. 4. Click **Edit**, set **Status** to **Approved**, and click **Save**. On approval, the system: * Checks every line again, because another variation may have been approved against the same line in the meantime. A deduction that would now take a line below $0 stops the approval * Amends the linked Purchase Order automatically (no manual PO edit) so it holds the net position of each line: a deduction reduces the line it varies (for example, Tiling 1 × $32,000.00 less $5,000.00 becomes 0.84375 × $32,000.00, which is $27,000.00), an addition that varies a line increases it, and a new item becomes its own PO line — see [What happens on approval](./raise-a-subcontract-variation#what-happens-on-approval) * Updates the Subcontract's Revised Contract Value, and moves the variation's lines into **Revised Contract Value (approved)** on the subcontract's Schedule of Values * Makes the variation's lines claimable. On the subcontract's claims, they're listed on the **Items → Variations** subtab, separately from the original contract lines (see [Assess a subcontractor claim](./assess-a-subcontractor-claim#contract-items-and-variations)) * If the variation is flagged as **Pass-Through to Prime**, the approval is blocked until the linked customer variation is itself approved From now on the variation's lines are read only, and its **Variation Estimate** is no longer updated from it. ## Rejecting a variation There's no Reject button. To reject a variation: 1. Open it and click **Edit**. 2. Set **Status** to **Rejected**. 3. Click **Save**. A rejected variation stays on the subcontract's **Variations** subtab with the status **Rejected**, but it drops off the Schedule of Values and doesn't count towards either total. Its lines become read only. Its **Variation Estimate** has its lines removed and is made inactive, unless the estimate is already in a contract, in which case it's left alone. ## What success looks like * Variation status changes to **Approved**, and its **Summary** box now shows **Revised Contract Value**. * The Subcontract's **Variations** subtab shows the variation with its new status, and its **Schedule of Values** subtab lists its lines as **Approved**, included in **Revised Contract Value (approved)**. * The Purchase Order linked to the subcontract has been amended to the new net position of each line. * The Subcontract's **Revised Contract Value** has updated automatically, and matches the purchase order total. ## Gotchas * **Approval is blocked** if the linked customer variation isn't yet Approved (Pass-Through to Prime variations only). * **Nothing blocks a deduction that takes a line below what has already been claimed and paid.** A line can't go below $0, but there is no check against the claimed-to-date amount — check the claimed-to-date position before approving a large negative variation. * **Pre-qualification is not checked at variation approval.** The prequal gate applies when the subcontract moves from Awarded to Signed, not to variations raised afterwards. * **Rejected variations aren't deleted.** They stay on the subcontract's Variations subtab in **Rejected** status, with read-only lines. If the change is needed after all, raise a new variation. * **Post-approval reversal isn't supported directly.** If an approved variation needs to be undone, raise an offsetting variation with a negative value — see [Raise a back-charge](./raise-a-back-charge) for the same pattern applied to recoveries. ## Related * [Raise a subcontract variation](./raise-a-subcontract-variation) * [Create a subcontract](./create-a-subcontract) * [Assess a subcontractor claim](./assess-a-subcontractor-claim) * [Raise a back-charge](./raise-a-back-charge) --- --- url: >- https://fullclarity.help/subcontracts/head-contractor/assess-a-subcontractor-claim.md --- # Assess a subcontractor claim Review a progress claim a subcontractor has submitted, assess it line by line, and approve it to lock in an immutable assessment record. The claim then becomes available for the next step in the payment lifecycle. \[\[toc]] ## When to use this When a subcontractor's claim arrives in your assessment queue, either submitted through Connect Mobile or entered in NetSuite from a claim received by email or on paper. ## Enter a claim received by email or on paper 1. Open the subcontract (it must be **Active**; a claim can't be saved against a subcontract that is only Signed, so click **Commence** first), go to the **Claims** tab and click **New FC PF Vendor Claim**. The claim opens on the claim form for the subcontract's jurisdiction (for example **FC PF Vendor Claim — NZ**). 2. In Primary Information, fill in the **Claim Sequence**, the subcontractor's **Reference** (their invoice or claim number), the **Claim Period** start and end, and the **Tax Code** if you need one. There's no Name to enter: a claim is identified by its claim number (for example `VCL-12`) and its Claim Sequence. 3. On the **Items** tab, open **Contract Items**. Every line on the subcontract's purchase order is listed. Click a line to edit it, and enter either: * **% Complete to Date**: the cumulative percentage complete, including earlier claims (as on a progress claim), or * **Claimed Amt This Claim**. The other one fills in to match. Click **OK**, or just click the next line. Leave lines that aren't being claimed blank. 4. If the subcontract has approved variations, their lines are on the **Variations** subtab. Enter those the same way. 5. If the subcontractor has claimed for anything that isn't on the subcontract, add it on the **Additional** subtab. See [Items claimed that aren't on the subcontract](#items-claimed-that-aren-t-on-the-subcontract). 6. Save. The claim is saved in **Draft**, and you can come back and change it until you submit it. 7. Click **Submit Claim** and confirm. The claim moves to **Submitted**, the **Claim Date** is set to today and the **Assessment Due Date** is calculated from it. The **Submitted** total in the Summary panel updates as you type. On **NZ CCA** subcontracts, submitting also fills in the claim's statutory details, where they're still blank (anything already entered is kept): * **Reference Period**: the Claim Period start and end * **Claimed Due Date for Payment**: the claim's **Payment Due Date** if its payment terms give one; otherwise 20 working days after the Claim Date (the default under the Construction Contracts Act) * **Claimant NZBN**: from the vendor record * **Retention in Trust** and **Trust Account Reference**: from the retention trust account on the subcontract, or failing that the project, or failing that your Project Financials configuration For example, a claim dated Monday 5 October 2026 has its 20 working days end on Tuesday 3 November 2026, because Labour Day (26 October) is skipped. See [How working days are counted](#how-working-days-are-counted). The **Calculation Method Statement**, and the subcontractor's acknowledgement that the claim is made under the Act (**Statutory Label Acknowledged NZ**), are filled in only on claims submitted through Connect. On a claim you enter yourself, record what the subcontractor's own document says. ## Prerequisites * Claim in **Submitted** or **Under Assessment** status * Parent subcontract is **Active**, **PC** (Practical Completion), **DLP** (Defects Liability Period), or **Final** — see [Subcontract states](../reference/subcontract-states) * Permission to assess claims for the subcontract's subsidiary * Awareness of the **Assessment Due Date** — the statutory window starts the moment the claim arrives ## The claim form at a glance When you open a claim, the form shows: * **Primary Information** — the claim ID and its **Status** (at the top), claim sequence number, claim type, parent subcontract, and (top-right) a **Summary** panel with running totals. On NZ CCA subcontracts it also shows the claim's **Payment Schedule** (see [Issue a payment schedule](./issue-a-payment-schedule)). * **Key Dates** — Service Date, Assessment Due Date, Claim Period, Assessment Date (stamped once you finalise) * **Status & Workflow** — Submitter (the subcontractor's contact), Assessor, Rejection Reason (if rejected) * **Statutory Compliance** — jurisdiction-specific fields (e.g. NZBN, Reference Period, Calculation Method Statement for New Zealand; ABN, Supporting Statement for Australia; Pay Less Notice fields for UK) * **Items** tab, with up to three subtabs: * **Contract Items**: the claim against each original line of the subcontract, and what you've assessed * **Variations**: the same, for lines added by approved variations. Only shown when the subcontract has them. They're kept apart so variances on variations can be reported separately from the original contract works * **Additional**: anything the subcontractor claimed that isn't on the subcontract The **Summary** panel shows the claim's totals, and updates as you change amounts in Edit: * **Submitted** — total the subcontractor is claiming this period * **Assessed** — total you're approving * **Variance** — Submitted minus Assessed * **Retention This Claim** — retention being withheld * **Net Payable** — the bottom-line amount the subcontractor will receive ::: tip Amounts are shown excluding GST Every amount on the claim screens — the Summary panel and the Items lines — is excluding GST. GST is added once, at the end: on the Vendor Bill, and on the Payment Schedule where it's issued as a buyer-created tax invoice. It's worked out from the tax codes on the subcontract's purchase order lines. ::: ## Contract Items and Variations **Contract Items** shows one row per original line of the subcontract, and **Variations** one row per line from an approved variation. Both work the same way. On a new or Draft claim every line is listed; once the claim is submitted, only the lines the subcontractor claimed are shown. What you can change depends on the claim's status: | Claim status | Opened with | What you can change | |---|---|---| | New, or **Draft** | **Edit** | What's claimed: **% Complete to Date**, **Claimed Amt This Claim** | | **Under Assessment** | **Edit** | Your assessment: **Assessed Amt**, **Variance Reason**, **Reason Text** | | **Under Assessment** | View | One line at a time, with the **Assess** link on the line | | Any other status | View | Nothing. Read only | In Edit, the lists behave like the Items list on a NetSuite transaction. Click a line to edit it: the current line is highlighted, and only its editable columns can be changed. Click **OK** (or click another line) to accept it, or **Cancel** to undo your changes to it. The lines themselves are fixed, one per line of the subcontract, so you can't insert or remove lines. While you're assessing, the columns are: * **PO Line #**, **Item**, **Description**: the line on the subcontract's purchase order * **Contract Qty**, **Rate**, **Contract Value**, **Previously Approved**: what's been agreed, and what earlier claims have approved * **Submitted Amt**: what the subcontractor is claiming this period * **Assessed Amt**: what you're approving * **Line Status**, **Variance Amt**, **Variance %**: worked out from the assessed amount * **Variance Reason**, **Reason Text**: why the line isn't being approved in full **Line Status** follows from the amounts. You don't set it yourself: * **Pending**: not assessed yet. A blank Assessed Amt means the line hasn't been assessed; it isn't treated as 0. * **Approved**: assessed in full (Assessed Amt equals Submitted Amt) * **Reduced**: assessed at less than claimed * **Rejected**: assessed at 0 **Assessed Amt** can't be more than the Submitted Amt. If you type a higher amount, NetSuite tells you and doesn't accept it: you can't approve more than the subcontractor claimed. ### Variance Reason and Reason Text On any line that isn't approved in full (**Reduced** or **Rejected**), you need both a **Variance Reason** and a **Reason Text** of at least **20 characters**. The current line shows a red asterisk in those two cells. The line can't be accepted, nor the claim saved, until both are filled in, and the message names each line that's missing something. If you approve a line in full, its Variance Reason and Reason Text are cleared automatically. Pending lines need neither. These are the same checks **Assess & Approve** makes, so a claim you've saved without messages won't be stopped for its lines later, except for any line you haven't assessed yet. Picking a **Variance Reason** fills in **Reason Text** with that reason's standard wording, which you can then edit. It never overwrites text you've typed yourself: it only fills an empty Reason Text, or replaces another reason's standard wording you haven't changed. **Other** has no standard wording, so write your own. The reasons supplied are: | Variance Reason | Standard Reason Text | |---|---| | Over-claim | The amount claimed exceeds the value of work completed to date. | | Incomplete Work | Work claimed is not complete as at the date of assessment. | | Quality Defect | Work claimed is defective and must be remedied before payment. | | Awaiting Verification | The work claimed has not yet been verified on site. Payment will be assessed once verified. | | Scope Change Pending Variation | Work claimed is outside the contract scope. It will be assessed once a variation is approved. | | Other | (none) | ::: tip Tailoring the Variance Reasons The six reasons above are supplied as a standard set. Your NetSuite administrator can tailor them to how your business works. They're kept as a list of records called **FC PF Claim Line Var Reason** (**Customization → Lists, Records, & Fields → Record Types**, then **List** on that record type), and each reason has a **Default Reason Text**. * **To stop using a supplied reason**, open it and tick **Inactive**. It no longer appears in the list when assessing. Claims already assessed with it keep it. It stays inactive when the SuiteApp is updated. * **To add your own reason**, click **New** on that list and fill in its name and Default Reason Text. * **Don't reword the supplied reasons.** Updating the Project Financials SuiteApp may reset their wording to the text above. To use different wording, make the supplied reason inactive and add your own. ::: ## Items claimed that aren't on the subcontract Subcontractors sometimes claim for work that isn't on the subcontract, such as extra hire or a site instruction that was never raised as a variation. Record those items on the **Additional** subtab, so the claim matches what the subcontractor sent you and your response covers every item. Each Additional row has: * **Description (as claimed)**, **Claimed Amt**: as the subcontractor claimed it * **Assessed Amt**: always 0. An item that isn't on the subcontract can't be paid as it stands * **Line Status**: **Pending** when added. Set it to **Rejected** when you decide it * **Variance Reason**, **Reason Text**: why it isn't being paid. Because an Additional row is always assessed at 0, **every** row needs a Variance Reason and a Reason Text of at least 20 characters, whether it's Pending or Rejected. The only exception is a row you're moving onto a contract line. While you're assessing, the row can't be accepted, nor the claim saved, without them. Picking a Variance Reason fills in its standard wording here too An Additional item can only be paid through a variation. If the work should be paid: 1. Raise the variation on the subcontract and approve it (see [Approve a subcontract variation](./approve-a-subcontract-variation)). Approving it adds its line to the subcontract. 2. On the claim, in Edit while it's **Under Assessment**, pick that line in the Additional row's **Move to Contract Line** column, and save. The claimed amount is added to this claim's line for that contract line, and the Additional row is removed. Assess the contract line as usual. You can't set an Additional row to Approved or Reduced yourself. NetSuite stops the row and points you to Move to Contract Line. On NZ CCA subcontracts, the Payment Schedule lists Additional items in their own section (see [Issue a payment schedule](./issue-a-payment-schedule)). ::: tip Number formatting follows your NetSuite preferences Amounts respect the **Number Format** set on your user preferences (for example, `1,234.56` US-style or `1.234,56` European-style). ::: ## Walkthrough ::: tip Walkthrough Scribe coming A step-by-step Scribe recording of this flow is being prepared. Until it's available, the steps below describe the full path end-to-end. ::: ### Step 1 — Open the claim and start the assessment 1. Open the claim from your queue, a dashboard reminder, or an email notification. 2. Confirm the claim header is correct — Service Date, Assessment Due Date, parent subcontract. 3. Click **Begin Assessment**. The status moves to **Under Assessment** and you become the recorded Assessor. ### Step 2 — Assess each line There are two ways to assess the lines. **Edit** is the quicker way when there are several lines to get through. **In Edit (recommended):** 1. Click **Edit** on the claim. 2. On **Items → Contract Items** (and **Variations**, if shown), click a line and enter the **Assessed Amt**: * the Submitted Amt to approve it in full, * a lower amount to reduce it, or * 0 to reject it. 3. If you've reduced or rejected the line, pick a **Variance Reason** and check or edit the **Reason Text** it fills in (at least 20 characters). 4. Click **OK**, or click the next line to accept this one and move on. 5. On **Items → Additional**, give every row a Variance Reason and Reason Text, and decide it: set it to **Rejected**, or move it onto a contract line once its variation is approved (see [Items claimed that aren't on the subcontract](#items-claimed-that-aren-t-on-the-subcontract)). 6. Click **Save**. The Summary panel shows the new totals, retention and net payable. You can come back later and continue; the claim stays in Under Assessment until you finalise. **One line at a time, from view mode:** 1. With the claim open in view mode (not Edit), click **Assess** at the end of a line on Contract Items or Variations. 2. A window opens showing what's claimed on the line (read only) and the assessment fields: **Assessed Amt**, **Line Status**, **Variance Amt**, **Variance %**, **Variance Reason** and **Reason Text**. The same rules apply as in Edit. 3. Click **Save**. The window closes and the claim reloads with the line and totals updated. If the claim is no longer Under Assessment (for example someone else has finalised it), the window tells you so and nothing is saved. ::: warning Reasons are mandatory for reductions This is a statutory requirement under AU SOP Act and NZ CCA s21. A claim that's reduced or rejected without per-line reasons cannot be finalised — and on AU/NZ jurisdictions, an inadequate response exposes you to the full claimed amount under recent case law. ::: ### Step 3 — Finalise the assessment When every line is decided (no Contract Items, Variations or Additional rows left in Pending) and your statutory compliance fields are complete: 1. Click **Assess & Approve**. You're asked to confirm: "Issue this assessment as the final schedule?" 2. The system runs validation: * Every line must have a Line Status of Approved, Reduced, or Rejected — no Pending lines remain. * Every Reduced or Rejected line, and every Additional row, must have a Variance Reason and Reason Text of at least 20 characters. * No line may be assessed at more than was claimed. * Jurisdiction-specific statutory fields must be populated. On **NZ CCA** subcontracts, if **Statutory Label Acknowledged NZ** isn't ticked (the subcontractor hasn't stated that the claim is made under the Act), you're warned before the assessment is finalised. It's a warning only: you can go ahead. 3. Once validation passes, the claim status moves to **Assessed** — this is the assessment being finalised, not the claim being approved for payment (that's a separate step, see below) — the Assessment Date is stamped, and an immutable **schedule snapshot** is recorded against the claim — a legal artefact of what you assessed and why, anchored against the AU/NZ precedent (Witron 2023 NSWCA 305; Grove Darwin 2017 NTSC 28). ### If you need to reject the whole claim You can click **Reject Claim** from either **Submitted** or **Under Assessment**. A prompt collects the rejection reason (minimum 20 characters). The claim moves to **Rejected** and the reason is captured on the header. ::: warning Rejecting does not reset the statutory clock The original Assessment Due Date still applies. If the subcontractor resubmits, fast, clear feedback helps them turn it around in time. ::: ## What success looks like * Claim status is **Assessed**. * Assessor and Assessment Date are stamped on the claim header. * The Summary panel shows your final Submitted / Assessed / Variance / Retention / Net Payable totals. * An immutable schedule snapshot has been created and linked to the claim — visible via the **Current Snapshot** field. * Reduced and rejected lines all carry a Variance Reason and Reason Text; lines approved in full carry none. ## After the assessment Beyond **Assessed**, a claim moves on to **Approved** and then **Billed**. **To approve an Assessed claim, click Approve Claim** and confirm. The claim moves to **Approved**. * **NZ CCA subcontracts:** approving the claim produces its approved Payment Schedule automatically, ready to send. If the schedule can't be produced (for example, a GST number is missing), the claim is still approved and you're told what's missing; fix it and click **Generate Payment Schedule**. The **Response Issued Date** is set when you send the schedule to the subcontractor. See [Issue a payment schedule](./issue-a-payment-schedule). * **AU SOP Act and UK HGCRA subcontracts:** the **Response Issued Date** is set when you approve the claim. **Create Bill** appears once a claim reaches **Approved**, and converts it to a Vendor Bill. **Use it rather than raising the bill by hand:** the automated conversion writes the claim-to-bill link and the audit entry that a manually-created bill won't, and it handles the receipt-then-bill path for fulfillable items. Each bill line takes the GST code from the claim line, so the bill's GST matches the Payment Schedule. Each claim gets its own Vendor Bill (or Vendor Credit). If **Bill Approved Claims Automatically** is ticked on the subcontract (or on the vendor as a default), approved claims are billed for you on a schedule, one bill per claim, every **Automatic Billing Interval (Days)** (30 days if left blank). ### Issuing the statutory response * **NZ CCA subcontracts:** the Payment Schedule is produced when you approve the claim, and sent from the claim — see [Issue a payment schedule](./issue-a-payment-schedule). * **AU SOP Act and UK HGCRA subcontracts:** the response document (Payment Schedule / Pay Less Notice) is **not generated by the system** — issue it through your own process. See the warning below. * **Communicate the outcome to the subcontractor yourself where no Payment Schedule is sent.** Outside the NZ CCA Send to Subcontractor flow, the subcontractor is not told the result of your assessment by either Connect or the mobile app. ::: danger AU SOP Act and UK HGCRA: the statutory response document is not generated Under the AU SOP Act and UK HGCRA, failing to issue a valid payment schedule (or pay less notice) inside the statutory window can expose you to the full claimed amount. The Subcontracts feature records your assessment and the evidence behind it, but on these jurisdictions **it does not produce or serve that document**. Issuing it, and doing so in time, remains your responsibility. (NZ CCA subcontracts can generate and send the Payment Schedule from the claim — see [Issue a payment schedule](./issue-a-payment-schedule).) ::: ## How working days are counted The **Assessment Due Date** (your deadline to respond) and, on NZ CCA subcontracts, the default **Claimed Due Date for Payment** are counted forward from the **Claim Date**. On NZ CCA subcontracts both are 20 working days, which skip: * Saturdays and Sundays * the New Zealand public holidays set up in FullClarity's holiday list * every day from 24 December to 5 January If a public holiday hasn't been set up, it's counted as an ordinary working day, so check the holiday list at the start of each year. Once a claim's Assessment Due Date has been set, it isn't recalculated. ## Gotchas * **The Service Date is immutable.** It's the timestamp the claim arrived — not the date the subcontractor put on it. The statutory clock runs from Service Date and can't be reset by rejecting and re-receiving. * **Assessment is line-level.** You can't reduce a claim total without giving line-level reasons. * **Reason Text must be at least 20 characters.** Anything shorter blocks finalisation. * **Edit mode and the workflow buttons are mutually exclusive.** Workflow buttons (Submit Claim / Begin Assessment / Assess & Approve / Reject Claim) only appear in view mode. To change several lines, click **Edit**; save; then return to view mode to finalise. * **What's claimed is fixed once the claim is submitted.** Claimed amounts can only be changed while the claim is in Draft. From Under Assessment you change the assessed side only. * **Tax and quantities aren't on the screen.** You claim and assess in amounts (or % complete) excluding GST. GST is worked out on the bill (and a tax-invoice Payment Schedule) from the purchase order lines' tax codes, so make sure those are right. * **Additional items are never paid directly.** Raise and approve a variation, then use **Move to Contract Line**. * **A claim can only be assessed if its subcontract is active.** If the subcontract has been Cancelled, Closed Out, or hasn't reached Active yet, claim assessment is blocked. ## Related * [Create a subcontract](./create-a-subcontract) * [Approve a subcontract variation](./approve-a-subcontract-variation) * [Raise a back-charge](./raise-a-back-charge) * [Issue a payment schedule](./issue-a-payment-schedule) * [Subcontract states](../reference/subcontract-states) * [Submit a claim (subcontractor, mobile)](../subcontractor-mobile/submit-a-claim-with-photos) --- --- url: 'https://fullclarity.help/subcontracts/head-contractor/create-a-subcontract.md' --- # Create a subcontract Set up a new subcontract for a project, including the Schedule of Values, and move it through Draft → Signed so claims and variations can begin. \[\[toc]] ## When to use this After a subcontractor has been selected for a piece of work on a project, and before any claim or variation against that subcontract can happen. Creating the subcontract is what gives the sub something to claim against and what gives you a record to assess against. ## Prerequisites * An active project — see [Create a project](/project-financials/how-to/create-a-project) * The vendor exists as a Vendor record in NetSuite with the **Subcontractor** flag set — vendors without this flag won't appear in the subcontract vendor lookup * Subcontracts feature enabled for the subcontract's subsidiary — without it, the subcontract will save but none of its automation will run * The subcontractor's compliance documents approved in **Certified Documents** before you sign — see [Prequalification](../reference/prequalification) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Go to **FullClarity → Project Financials → Subcontract → New**. A new Subcontract record opens in **Draft** status. 2. Select the **Vendor** (the subcontractor), the **Project**, the **Subsidiary** and the **Currency**. 3. Set the **Compliance Model** — this is the jurisdiction switch (AU SOP Act, NZ CCA, UK HGCRA, US, or None). It drives the statutory response window and the payment schedule format, so set it before the first claim arrives. 4. Set the **Contract Date**, the **Commencement Date** (when work starts), and the **Expected PC Date**. 5. Choose the **Contract Type** — *Lump Sum*, *Unit Rate*, *Time & Materials*, or *Mixed*. 6. Save the subcontract. It remains in **Draft** while you finalise the Schedule of Values and contract terms. 7. Add the **Schedule of Values** lines. Either click **Add Estimate Lines** to pick lines from the project's estimate — tick the lines you want and click **Add Selected Lines**; each one comes across with its amount, cost centre and a link back to the estimate line — or add lines by hand on the **Subcontract Lines** sublist. Each line takes an item, quantity, rate, description and cost centre. 8. Move the subcontract through its lifecycle with the buttons at the top of the record: **Send to Tender** (optional — out for bids), **Award** (vendor selected, contract being drawn up), then **Sign** (executed and approved). See [Subcontract states](../reference/subcontract-states#moving-a-subcontract-to-its-next-state) for the full set. 9. When you click **Sign**, confirm the prompt. FullClarity checks the subcontractor's [prequalification](../reference/prequalification) and, if it passes, signs the subcontract and raises the commitment purchase order. ::: warning Award before you Sign The commitment purchase order is generated on the **Awarded → Signed** step specifically, which is why **Sign** only appears once the subcontract is Awarded. From Draft, click **Award** first. ::: ## What success looks like * A Subcontract record in **Signed** status, visible at **FullClarity → Project Financials → Subcontract**. * The Schedule of Values lines are visible on the record, and the subcontract total matches the sum of the SoV line values. * Within a minute or so of signing, the **PO Generation Status** field shows **Success** and the subcontract links to the commitment purchase order — created already **Approved**, with one line per Schedule of Values line. This is the PO that any approved variation will amend automatically. You don't edit it directly. * The subcontractor sees that purchase order in Connect at next sync. ## Gotchas * **Sign is refused if prequalification fails.** The subcontract stays at Awarded and you see the reason. Approve the outstanding document in Certified Documents and click **Sign** again — see [Prequalification](../reference/prequalification). The **Prequal Status** field on the subcontract shows the current result (Valid / Expiring Soon / Expired / Incomplete / Not Applicable) and refreshes when you open the record, change the vendor, press Sign, or once a day. * **The purchase order is generated in the background.** Signing returns immediately and the PO follows a minute or so later. * **If the purchase order can't be created, signing is undone.** The subcontract goes back to **Awarded**, **PO Generation Status** shows **Failed**, and a red message at the top of the record gives the reason. Fix the cause, save, and click **Sign** again. A common cause is a missing **Department**: if your account makes departments mandatory on transactions, set the subcontract's **Department** before you sign, because the purchase order takes its department from the subcontract. * **Subcontract POs are carved out of native NetSuite PO approval.** Approval happens at the Subcontract layer and the generated PO is created already approved. Don't approve the underlying PO manually. If your organisation approves purchase orders with its own approval fields rather than NetSuite's approval routing, that's fine too: **Create Bill** on an approved claim treats a PO that has moved on to Pending Receipt (or later) as approved. * **After Signed, change the scope through a Variation.** Once the commitment PO exists, the scope changes only through variations, so the subcontract and the PO stay in step — see [Raise a subcontract variation](./raise-a-subcontract-variation). * **The Subcontractor flag is mandatory on the vendor record.** Without it, the vendor won't appear in the vendor lookup on the Subcontract. * **Confirm the Compliance Model before the first claim arrives.** Changing it mid-contract is messy. * **Adding lines by hand is one line at a time.** There is no paste or spreadsheet import. For lines that already exist on the estimate, **Add Estimate Lines** brings in as many as you tick in one go. * **From Signed, the Schedule of Values subtab becomes a read-only list.** While the subcontract is Draft, Tendered or Awarded, the subtab shows the contract lines for you to edit. From Signed onwards it shows the contract as it stands instead: the original lines as SOV1, SOV2…, then the lines of approved and pending variations with their status, and two totals, **Revised Contract Value (approved)** and **Total including pending**. See [Where variations show on the subcontract](./raise-a-subcontract-variation#where-variations-show-on-the-subcontract). ## Related * [Raise a subcontract variation](./raise-a-subcontract-variation) * [Approve a subcontract variation](./approve-a-subcontract-variation) * [Assess a subcontractor claim](./assess-a-subcontractor-claim) * [Subcontract states](../reference/subcontract-states) * [Prequalification](../reference/prequalification) --- --- url: >- https://fullclarity.help/subcontracts/head-contractor/issue-a-payment-schedule.md --- # Issue a payment schedule Generate the statutory Payment Schedule for a claim and send it to the subcontractor, straight from the claim record. \[\[toc]] ::: tip NZ CCA subcontracts only Generating and sending a Payment Schedule from the claim is available on subcontracts whose **Compliance Model** is **NZ CCA**. On **AU SOP Act** and **UK HGCRA** subcontracts, the equivalent document (Payment Schedule / Pay Less Notice) is **not generated by the system** — issuing it remains your own responsibility. See [Assess a subcontractor claim](./assess-a-subcontractor-claim). ::: ## When to use this Once you've approved a claim and want to send the subcontractor their statutory Payment Schedule. Approving the claim produces the schedule for you; you can also generate a draft while you're still assessing, to check how it reads. ## Prerequisites * Subcontract's **Compliance Model** is **NZ CCA** * Subcontract has a purchase order (generated when the subcontract was signed) — a subcontract with no PO yet can't have a schedule generated against it * Claim in **Under Assessment**, **Assessed**, **Approved** or **Billed** status * The one-time configuration below is in place, or you'll hit a refusal page when you try to generate ::: warning New Zealand: NetSuite ANZ Localization is required Your NetSuite account needs Oracle's **ANZ Localization** SuiteApp installed. The Payment Schedule relies on its **RCTI** (recipient-created tax invoice) box on the vendor record to decide whether to issue a buyer-created tax invoice. Without ANZ Localization, there is no RCTI box, so every subcontractor is treated as having no buyer-created tax invoice agreement: the schedule is issued as an ordinary Payment Schedule, with no GST lines and no tax invoice number. Ask your NetSuite administrator to confirm it's installed before you start. ::: ## The buttons, and when they appear Both buttons live on the claim record, in view mode: * **Generate Payment Schedule** — appears once the claim is Under Assessment, Assessed, Approved or Billed, until the schedule has been sent. * **Send to Subcontractor** — appears once the schedule is **Approved** (and stays, so you can send it again once it's **Sent**). While the schedule is a **Draft** there's no Send button. ## One schedule per claim Each claim has one Payment Schedule. The first time it's generated, it's created; each later **Generate Payment Schedule** updates that same schedule with a fresh PDF that replaces the previous one. There are no separate versions to keep track of. Once the schedule has been **sent** to the subcontractor, it can't be changed. Generating again is refused, with a message saying who it was sent to and when. ### Statuses | Status | What it means | |---|---| | **Draft** | The claim isn't Approved yet. The PDF is titled "Payment Schedule", stamped **NOT YET APPROVED**, and carries no GST lines. Generate one at any point while you're still working through the assessment if you want to check how it reads. | | **Approved** | The claim is Approved (or Billed). The **NOT YET APPROVED** stamp is gone, and the schedule is ready to send. | | **Sent** | The schedule has been sent to the subcontractor. It can no longer be changed. | ### Approving the claim produces the schedule When you click **Approve Claim** on an NZ CCA claim, the approved Payment Schedule is generated for you (or the draft is updated), and its status becomes **Approved**. You don't need to click Generate yourself. Pressing **Assess & Approve** is not enough on its own: that moves the claim to Assessed. It's **Approve Claim** that produces the approved schedule. If the schedule can't be generated at that point (for example, a GST number is missing), the claim is still approved, and a message tells you why the schedule wasn't produced. Fix the cause (see [Refusals, and how to fix each](#refusals-and-how-to-fix-each)), then click **Generate Payment Schedule**. ### On the claim The claim shows a single **Payment Schedule** line: * **View PDF** — opens the current schedule in a new browser tab * its status — **Draft**, **Approved** or **Sent** * once sent, **Sent** with the date and time, who sent it, and who it went to Until a schedule exists, the line reads "Not generated yet". ## Buyer-created tax invoices The vendor record has an **RCTI** (recipient-created tax invoice) tick box. It's NetSuite's own New Zealand/Australia localisation field, so the same agreement you already record for your other processes drives the Payment Schedule too. ::: warning What ticking this means Ticking **RCTI** means **your company issues tax invoices in the subcontractor's name on their behalf**. This is a real accounting arrangement, not a display setting — you must hold a **written agreement with that subcontractor** authorising it before you tick the box. Only tick it for subcontractors you've actually agreed this with. ::: When the tick box is set, the Payment Schedule becomes a tax invoice: * Title changes to "Payment Schedule - Buyer Created Tax Invoice". * A **Tax Invoice No.** is stamped in the form `-C` — for example `SCT001-C001` — and stays the same each time the schedule is regenerated before it's sent. * Both your company's and the subcontractor's GST numbers print on the document. * GST is added to the certified payment after retention, at the GST rate of each line's tax code (15% in New Zealand). The tax codes come from the subcontract's purchase order lines. * Payment Due prints inclusive of GST. * The claim's **Tax Invoice Number** and **Tax Amount** fields are filled in from the schedule. If the tick box isn't set, the schedule is an ordinary Payment Schedule with no GST lines and no tax invoice number. A **Draft** schedule is never a tax invoice: the tax invoice is only issued once the claim is Approved. ## What's on the document The Payment Schedule is laid out on A4 **landscape** pages and brings together: * **Job identification** — job/project, Project Manager, Financial Manager. * **Main contractor detail**: your company's legal name, GST number and postal address, all from the subsidiary record. * **Subcontractor detail.** * **Claim identification** — claim number, claim period, and the claim's **Payment Due Date** (worked out from the Claim Date and the payment terms). The subcontractor's own Claimed Due Date for Payment isn't printed. If the Payment Due Date is blank, the line is left blank. * **Whole-of-contract table** — every original line on the subcontract's purchase order, including lines not claimed this period, showing Contract, % Complete, Paid to Date, Previous, **Claimed** (what the subcontractor claimed this period) and Current (what you've certified), with each line's **Reason** printed on the line where you haven't paid it in full. * **Variations table** — approved variations, each prefixed with an "A" reference, with the same Claimed, Current and Reason detail. Unapproved variations aren't shown on the schedule yet. * **Items Claimed Not Part of the Contract** — anything on the claim's **Additional** subtab, with its Description, Claimed amount, Certified amount (always 0), Status and Reason, and totals. These items don't change the Contract Summary or the payment due. The section is left out when the claim has no Additional items. See [Items claimed that aren't on the subcontract](./assess-a-subcontractor-claim#items-claimed-that-aren-t-on-the-subcontract). * **Reason for Variance** — any claim-level reasons recorded on the claim. Per-line reasons print on their own lines in the tables above, not here. * **Contract summary** — Original Contract, Contract Variations, Total Claimed, Less Retentions, and Certified Payments broken down by Original / Paid to Date / Previous / Current. * **Payment summary.** * **Retention trust statement** — from the one-time configuration. * **Footer** — Job No, Claim No, and Page N of M. Dates print in `dd/mm/yy` format throughout. ## Sending it Click **Send to Subcontractor** once the schedule is **Approved** and you're happy with it. A **Draft** schedule can't be sent: approve the claim first, which approves its schedule. 1. A confirmation page opens. 2. **To** — the subcontractor's vendor record email, or one of the vendor's contacts that has an email address recorded. You can't type in an arbitrary address. 3. **CC me** — a tick box that CCs your own email address only. 4. **Subject** and **message** are pre-filled and editable. 5. The email attaches the Payment Schedule PDF, plus the **Form 1** file from configuration if one is set. If no Form 1 is configured, the page tells you it will send the schedule alone. 6. Send. ::: tip Sandbox and test accounts don't email subcontractors In a NetSuite sandbox, or in any other account that isn't your live production account, the email is sent **to you** instead of the subcontractor, with **\[TEST]** at the start of the subject and a note at the top saying who it would have gone to. The confirmation page says so before you send. Everything else happens as it would in production: the schedule is marked **Sent**, and **Sent To** shows your address with the subcontractor's address in brackets. This lets you test sending safely on a sandbox with real vendor addresses copied from production. ::: ### What gets recorded Once the email goes out: * The schedule's status becomes **Sent**, and its **Sent Date** (the date and time), **Sent By** and **Sent To** are recorded. The claim's Payment Schedule line shows them. * The claim's **Response Issued Date** is set to when the schedule was sent, if it wasn't already. On NZ CCA subcontracts this is the date that evidences your response, so it's set when you send the schedule, not when you approve the claim. * From now on the schedule can't be regenerated. If you send it again (for example to another contact), the confirmation page shows when it was already sent, and the same schedule goes out. ## Sending several at once To send a batch of schedules in one go, go to **FullClarity → Project Financials → Send Payment Schedules**. The page lists every **Approved** Payment Schedule that hasn't been sent yet, with the nearest **Assessment Due Date** at the top. That's the deadline for issuing the schedule. Each row shows: * **Claim** (click to open it in a new tab), **Subcontract** and **Subcontractor** * **Send To**: the address it will go to. That's the vendor record's email, or the first of the vendor's contacts with an email address. A row that says **No email** can't be sent until you add one. * **Assessment Due Date** and **Days Until Due**. Schedules that are overdue, or due today, are shown in red. * **Net Payable** Tick the schedules to send, or click **Mark All**, then click **Send Selected**. Each one is sent with the standard subject and message, and it's recorded exactly as if you'd sent it from the claim: status **Sent**, Sent Date, Sent By and Sent To, and the claim's Response Issued Date. To change the message, or send to a different contact, use **Send to Subcontractor** on the claim instead. * **One schedule ticked:** it's sent straight away. The list reloads with a green banner saying who it went to, or a red one with the reason if it couldn't be sent (for example, it was regenerated after you opened the list). * **Two or more ticked:** they're sent in the background, so you don't have to wait on the page. A green banner confirms they're on their way. Click **View progress** in it to watch the job run, if you want. Each schedule drops off the list once it has gone, and when they've all been processed you get an email listing the ones that were sent and any that weren't, with the reason. Only one batch can run at a time: if you try to start another while one is still running, you're asked to wait. A schedule is only ever sent once from here: if it has already gone by the time its turn comes (for example, someone sent it from the claim), it's skipped and listed as not sent. If you tick a very large number, the page sends as many as it can in one batch and lists the rest in an amber banner. Tick those and click **Send Selected** again once the first batch has finished. Draft schedules aren't listed: approve the claim first. On a sandbox or test account, every email goes to you rather than the subcontractor, as with a single send. ## If there's already a Vendor Bill If a Vendor Bill already exists for the claim, generating a tax-invoice schedule updates the bill's **Reference No.** to the tax invoice number — but only when the Reference No. field is currently blank and the bill's totals match the schedule. If either condition isn't met, you'll see a warning instead, and you'll need to check the bill by hand. If you click **Create Bill** after issuing a tax-invoice schedule, the new bill takes the tax invoice number as its **Reference No.**, but only when the bill's GST agrees with the GST on the tax invoice. The bill's GST comes from the tax codes on the subcontract's purchase order lines, so make sure the items on the Schedule of Values carry the correct GST code (for example 15% GST in New Zealand). A bill whose lines have a zero-rated or undefined tax code will have no GST, won't match, and is left with a blank Reference No. for you to check. ## Refusals, and how to fix each Generating (or sending) can be refused. Each refusal opens a plain page explaining what's missing — nothing is created: | Refusal | Fix | |---|---| | **Retention trust statement not configured** | Add the Retention Trust Statement on the Project Financials configuration record for the subsidiary (see below), then generate again. | | **Subcontractor has no GST number** (tax-invoice mode only) | Add the GST number to the vendor's **Tax Reg. Number** field, then generate again. | | **Subsidiary has no GST number** (tax-invoice mode only) | Enter your GST number in the **Tax ID** field on the subsidiary record (**Setup → Company → Subsidiaries**), then generate again. | | **A line has no Tax Code** (tax-invoice mode only) | The message names the line. Set the tax code on that line of the subcontract's purchase order (or set a Tax Code on the claim, which is used for any line without one), then generate again. | | **Schedule already sent** | A sent schedule can't be changed. Nothing to fix; the sent schedule stands. | | **Schedule is still a Draft** (sending) | Approve the claim. That approves its schedule, and Send to Subcontractor appears. | | **Subcontract has no purchase order yet** | The subcontract hasn't been signed, or its PO hasn't finished generating — check **PO Generation Status** on the subcontract, then generate again once the PO exists. | ## One-time configuration Before the first schedule can be generated for a subsidiary, set up: **On the subsidiary record:** * **Tax ID**: your company's GST number. It's the GST number NetSuite already holds for the subsidiary, so it's usually filled in already. * **Shipping Address**: the postal address printed on the schedule. Enter the address you want subcontractors to see (for example your PO Box). The addressee line is left off, because the company name already heads the block. If the Shipping Address is blank, the schedule prints no address. **On the Project Financials configuration record, for the subsidiary:** * **Retention Trust Statement** (required) * **Form 1 File** (optional; attached automatically when sending, if set). A sample Form 1, watermarked SAMPLE, is supplied in the File Cabinet at *SuiteApps › com.fullclarity.projectfinancials › subcontract › documents*. Use it to see how sending works, but replace it with your own Form 1 before you send schedules to subcontractors. * **Payment Schedule Logo** **On the vendor record:** * **RCTI** tick box, if you've agreed buyer-created tax invoices in writing with the subcontractor * **Tax Reg. Number** — the subcontractor's GST number **On the project:** * **Financial Manager** **On variations:** * **External Reference** (ATS) — printed as the variation's "A" reference on the schedule ## What success looks like * Once the claim is approved, its **Payment Schedule** line shows **Approved**, and **View PDF** opens the schedule in a new tab. * The PDF is titled correctly for its state — "Payment Schedule" (draft, **NOT YET APPROVED**) or, once Approved, either "Payment Schedule" or "Payment Schedule - Buyer Created Tax Invoice" depending on the vendor's tax-invoice agreement. * Once sent, the Payment Schedule line shows **Sent** with the date and time, who sent it and who it went to, and the claim's Response Issued Date is set. ## Gotchas * **This is NZ CCA only, today.** AU SOP Act and UK HGCRA subcontracts don't have these buttons — see [Assess a subcontractor claim](./assess-a-subcontractor-claim). * **Generating replaces the PDF, until it's sent.** Each Generate updates the claim's one schedule with a fresh PDF. After it's sent, it can't be changed. * **Approve before you send.** Only an Approved schedule can be sent. Approving the claim produces it. * **The tax invoice number is sticky.** Once a claim has a Tax Invoice Number, it doesn't change on later regenerations, even if you toggle the vendor's tax-invoice agreement off and back on. * **Unapproved variations don't show on the schedule.** Only approved variations appear, with an "A" reference. * **Additional items are certified at 0.** Anything claimed that isn't on the subcontract is listed with its reason but never paid. To pay it, approve a variation and move the item onto its line before you generate the schedule. * **You can't type a recipient address.** Sending relies on the vendor record's own email, or an email held against one of its contacts — add or fix the address there if sending fails to find one. ## Related * [Assess a subcontractor claim](./assess-a-subcontractor-claim) * [Create a subcontract](./create-a-subcontract) * [Subcontract states](../reference/subcontract-states) --- --- url: 'https://fullclarity.help/subcontracts/head-contractor/raise-a-back-charge.md' --- # Raise a back-charge Recover cost from a subcontractor — cleanup, rework, delay damages, or other costs incurred because of the sub's actions — by raising a negative-value variation against the subcontract. \[\[toc]] ::: warning A dedicated back-charge workflow is coming In the current release, back-charges are raised as **negative-value Variations**. A dedicated Back-Charge record type with its own approval routing and sub-acknowledgment workflow is on the roadmap for a later release of the Subcontracts feature. Until then, follow the variation-based pattern below. ::: ## When to use this When you need to charge the subcontractor for cleanup, rework, delay damages, or other costs incurred because of the sub's actions, and you want the recovery reflected against the subcontract's value (rather than as a separate Debit Memo). ## Prerequisites * Subcontract in **Active**, **PC**, **DLP**, or **Final** status * A clearly-defined cost amount and reason, and the SoV line(s) it comes off * The sub has been informed in writing (process — not enforced by the system) * Permission to create and approve variations for this subcontract's subsidiary ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the Subcontract record, go to the **Variations** subtab and click **New FC PF Subcontract Variation**. 2. Set the **Variation Type** to **Cost Decrease** or **Defects** (the type that best matches the reason). 3. Set the **Reason** to the appropriate code — the available reasons are *Owner Variation*, *Design Change*, *Site Condition*, *Error*, *Omission*, *Client Directive* and *Other*. (*Defects* is a variation **Type**, not a Reason.) 4. Add a clear explanation in the **Description** field. It's the variation's text wherever it's listed, so the reason for the back-charge is visible on the subcontract and in the audit trail. 5. On the **Schedule of Values** subtab, enter a **negative-value line** and choose the line it comes off in **Varies Line** — an original contract line or an addition on an earlier approved variation. The line's Item, Cost Centre and Phase are filled in from that line. A deduction can't be added without a Varies Line, and it can't take that line below $0. See [Raise a subcontract variation](./raise-a-subcontract-variation#deductions-must-say-which-line-they-vary). 6. Save. **Value (Signed)** shows the total of the lines, a negative amount. 7. Set the variation's **Status** to **Pending Approval**, then **Approved**, through the normal variation workflow — see [Approve a subcontract variation](./approve-a-subcontract-variation). On approval, the deduction reduces the line it varies on the PO (rather than adding a negative line) and reduces the Revised Contract Value. The next claim the sub raises will reflect the reduced contract value. ### When to use a Debit Memo instead If the back-charge needs to be visible to AP as a separate posting (rather than netted into the subcontract value), raise a **Debit Memo** against the vendor instead. The Debit Memo is independent of the Subcontracts feature — it's standard NetSuite AP. Use the variation approach when you want the recovery reflected on the subcontract's contract value; use a Debit Memo when you want the recovery posted as a separate AP transaction. ## What success looks like * A Variation record on the Subcontract, with Type **Cost Decrease** or **Defects** and a **negative** value, in **Approved** status. * The Subcontract's **Revised Contract Value** has reduced by the back-charge amount. * Subsequent claims by the sub reflect the reduced contract value. * The audit trail records the back-charge reason, approver, and approval date. ## Gotchas * **Nothing stops a back-charge reducing the contract value below what has already been claimed and paid.** There is no system gate on this — check the claimed-to-date position yourself before approving a large deduction. * **No sub-acknowledgment step exists yet.** Coordinate with the sub before approval, especially if the back-charge is contentious. The dedicated Back-Charge workflow (roadmap) will add an explicit acknowledgment step. * **Variations of type *Defects* may need separate evidence.** Attach photos, inspection reports, or correspondence to the variation record so the audit trail is complete. * **A back-charge has a variation estimate too.** Like any variation, it gets a Sales Estimate on the project with its negative lines — see [The variation estimate](./raise-a-subcontract-variation#the-variation-estimate). * **A back-charge raised this way is irreversible by the same mechanism.** If you need to reverse it, raise another offsetting variation with a positive value. ## Related * [Raise a subcontract variation](./raise-a-subcontract-variation) * [Approve a subcontract variation](./approve-a-subcontract-variation) * [Assess a subcontractor claim](./assess-a-subcontractor-claim) * [Subcontract states](../reference/subcontract-states) --- --- url: >- https://fullclarity.help/subcontracts/head-contractor/raise-a-subcontract-variation.md --- # Raise a subcontract variation Add or remove scope on an existing subcontract by raising a variation, and say on each line which part of the contract it changes, so the purchase order always shows the net position line by line. \[\[toc]] ## When to use this When the work under a signed subcontract changes — more of an existing item, less of it, or a new item that wasn't in the original contract — and you need the change recorded and then approved. Once the variation is raised and submitted, it goes through [Approve a subcontract variation](./approve-a-subcontract-variation). ## Prerequisites * Subcontract in **Signed**, **Active**, **PC**, or **DLP** status — see [Subcontract states](../reference/subcontract-states) * You know which contract line (or earlier variation line) each change relates to * Permission to create variations for this subcontract's subsidiary ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the Subcontract record, go to the **Variations** subtab and click **New FC PF Subcontract Variation**. 2. The new variation opens with its **Status** (Draft), **Variation Sequence**, **Project** and **Department** already filled in from the subcontract. 3. Fill in the variation header: * **Description**: what the variation is for. This is the variation's text everywhere it's listed, so make it clear. There's no separate Name to enter. * **Variation Type** and **Reason**. 4. On the **Schedule of Values** subtab, add a line for each change in the **Variation Lines** list: * Choose the line it changes in **Varies Line** (see [Choosing the line a variation varies](#choosing-the-line-a-variation-varies) below). This is required for a deduction and optional for an addition. * Enter a **Description**, and the **Quantity** and **Rate**, or the **Amount (Signed)**. For an **addition**, the amount is positive; for a **deduction**, it's negative. * Check the **Item**, **Cost Centre** and **Phase**. When you pick a Varies Line, they're filled in from the line it varies. For a new item, choose them yourself. 5. Click **Save**. The variation is saved in **Draft**, and you can come back and change it. 6. When it's ready, click **Edit**, set **Status** to **Pending Approval**, and save. It's now waiting for [approval](./approve-a-subcontract-variation). You don't need to fill in **Line** or **Change Kind**. The line number is filled in automatically when you add a new line, and Change Kind is set for you from the amount and the Varies Line: | Change Kind | When it's set | |---|---| | **add** | A positive amount that varies an existing line — more of the same work | | **deduct** | A negative amount that varies an existing line | | **new** | A positive amount with Varies Line left blank — a new item | ### What's filled in for you on save * **Value (Signed)** is the total of the variation's lines. It's worked out again every time you save, so you never type it. * The **Summary** box at the top right shows the subcontract's **Original Contract Value**, the **Approved Variations** so far, the **Contract Value Before** this variation, this variation's **Additions**, **Deductions** and total, and **Revised If Approved**: what the contract will be worth once it's approved. * A **Variation Estimate** is created on the project (see [The variation estimate](#the-variation-estimate) below). ### Every line needs an Item and a Cost Centre Every line must have an **Item** and a **Cost Centre**, and a **Phase** when the project uses phases. A line that varies another line always takes the Item, Cost Centre and Phase of the line it varies. That keeps the change on the same item and cost centre on the purchase order and in your job costing. If a line is missing any of them, the variation can't be saved and the message names the line. ## Choosing the line a variation varies The **Varies Line** list shows every line on this subcontract that a variation can change: * The subcontract's **original contract lines**, shown with their line number, description and value — for example *Line 1 · Tiling · $32,000.00* * The **additions on earlier approved variations**, shown with the variation number and line number, as on the Schedule of Values — for example *VAR13/2 · Extra waterproofing · $3,000.00* Only this subcontract's lines are listed. Lines from draft, pending or rejected variations never appear, and neither do deductions. ### Deductions must say which line they vary A deduction (negative amount) must have a **Varies Line**. The line can't be added to the variation without one. This keeps every reduction tied to the work it comes off, so the purchase order and the subcontract stay in step. ### Additions can vary a line or stand alone An addition (positive amount) can go either way: * **Vary an existing line** — for more of the same work. On approval the amount is added to that line on the purchase order. * **Leave Varies Line blank** — for a genuinely new item. Choose its Item, Cost Centre and Phase yourself. On approval it becomes a new line on the purchase order. ### A line can't go below $0 A line, together with everything that varies it, can't go below $0. If a deduction would take a line below $0, the variation can't be saved, and the message tells you how much is left to deduct from that line. ### Other rules * A deduction can't vary another deduction — choose the original line, or the addition it reduces. * A line can't vary another line on the same variation. * Lines imported, or entered on their own rather than on the variation, follow the same rules. ## The variation estimate So that the change is costed on the project as well as on the subcontract, the first time you save a Draft or Pending Approval variation a **Sales Estimate** is created on the project for it: * It has one line for each variation line, with the same Item, Cost Centre, Phase and amount, priced at the project's **Default Margin %**. * The variation's **Variation Estimate** field links to it, and the estimate links back to the variation. * **It's kept in step for you.** Each time you save the variation while it's Draft or Pending Approval, the estimate's lines are updated to match. * **Once the estimate is in a contract, it's left alone.** From then on, any change to its pricing is made on the estimate itself, and saving the variation no longer updates it. * **If the variation is rejected**, the estimate's lines are removed and the estimate is made inactive (unless it's already in a contract). If the estimate can't be created or updated, the variation still saves, and the **Estimate Problem** field on the variation says what went wrong. Fix the cause (for example, a missing Item on a line) and save the variation again to retry. ## What happens on approval When the variation is approved, the purchase order is updated to hold the **net position** of each line: * A **deduction** reduces the line it varies, rather than adding a negative line to the purchase order. * An **addition** that varies a line increases that line. * A **new item** becomes its own purchase order line. The line keeps its rate and its **quantity** changes, so the purchase order always matches the subcontract's own lines. For example: * A lump-sum line of 1 × $32,000.00 less $5,000.00 becomes 0.84375 × $32,000.00 — $27,000.00. * Deducting 50 m² from a 400 m² line at $80/m² leaves 350 m² at $80/m². Keeping the rate is what keeps payments right once work has been claimed. Claims are received and billed against the line at its rate, so if 10% of the Tiling line ($3,200.00) has already been billed, the remaining 0.74375 at $32,000.00 ($23,800.00) brings the total to exactly $27,000.00. A change priced at a different rate from its line still keeps the line's rate: adding 10 m² at $90/m² to an $80/m² line adds $900.00, shown as 11.25 m² at $80/m². If the quantity itself matters, raise it as a new item instead. Variations are checked again at approval, because another variation may have been approved against the same line since this one was raised. If the line no longer has enough left for the deduction, the approval is stopped and the message tells you how much is left. ### Worked example The subcontract has one original contract line: **Line 1 · Tiling**, 1 × $32,000.00. Its first variation is numbered **VAR13** and has two lines: | Variation line | Amount | Varies Line | Change Kind | Purchase order after approval | |---|---|---|---|---| | 1 · Reduce tiling scope | −$5,000.00 | Line 1 · Tiling · $32,000.00 | deduct | Tiling line becomes 0.84375 × $32,000.00 ($27,000.00) | | 2 · Extra waterproofing | $3,000.00 | *(blank)* | new | New line: Extra waterproofing, 1 × $3,000.00 | After VAR13 is approved: * The purchase order shows Tiling at $27,000.00 and Extra waterproofing at $3,000.00 — a total of $30,000.00, the subcontract's new Revised Contract Value. * The subcontract's **Schedule of Values** subtab lists SOV1 (Tiling, $32,000.00), then VAR13/1 (−$5,000.00, Approved) and VAR13/2 ($3,000.00, Approved), and ends with **Revised Contract Value (approved)** of $30,000.00. See [Where variations show on the subcontract](#where-variations-show-on-the-subcontract). * On the next variation, **Varies Line** lists *Line 1 · Tiling · $32,000.00* and *VAR13/2 · Extra waterproofing · $3,000.00*. VAR13/1 isn't listed, because it's a deduction. * A later deduction of $30,000.00 against Line 1 can't be saved — Tiling has only $27,000.00 left to deduct. ## Where variations show on the subcontract **Variations subtab.** Every variation on the subcontract, with its **ID** (VAR1, VAR2…), **Description**, **Variation Type**, **Value (Signed)** and **Status**. Variations are numbered across your whole account, not per subcontract, so the first variation on a subcontract won't necessarily be VAR1. **Schedule of Values subtab.** From **Signed** onwards, a read-only list of the contract as it stands: * The original contract lines, as **SOV1**, **SOV2**… * Then each variation line, as the variation's number and the line number — for example **VAR13/1** — with its **Status**: **Approved** (or **Consolidated**) or **Pending Approval**. Draft and rejected variations aren't shown. * The columns are **Line**, **Description**, **Cost Centre**, **Phase**, **Status** and **Amount**. * Two totals at the bottom: * **Revised Contract Value (approved)**: the original lines plus approved variations only. This matches the subcontract's Summary box and the purchase order. * **Total including pending**: the same, plus variations still in Pending Approval. Before the subcontract is Signed (Draft, Tendered or Awarded), the Schedule of Values subtab shows the editable contract lines instead — see [Create a subcontract](./create-a-subcontract). ## What success looks like * The variation is saved with every line showing a **Line**, **Item**, **Cost Centre** (and **Phase**, if the project uses phases) and **Change Kind**, and every deduction showing a **Varies Line**. * **Value (Signed)** equals the total of the lines. * **Variation Estimate** links to the variation's estimate on the project, and **Estimate Problem** is blank. * Once you've set it to **Pending Approval**, it shows on the subcontract's Schedule of Values with that status and is counted in **Total including pending**, ready for [approval](./approve-a-subcontract-variation). ## Gotchas * **You can't save a deduction without a Varies Line.** If you don't know which line the reduction comes off, check the subcontract's Schedule of Values first. * **The line you need isn't in the list?** It may be on a variation that is still in draft, pending approval, or was rejected — only approved variations' additions are listed. Approve that variation first, or vary the original contract line instead. * **Changed the Item or Cost Centre on a line that varies another, and it changed back?** A varied line always keeps the Item, Cost Centre and Phase of the line it varies. To use a different item, leave Varies Line blank and raise it as a new item. * **The $0 limit is per line, not per subcontract.** A deduction can be blocked on one line even though the subcontract as a whole has plenty of value left. Split the deduction across the lines it really comes off. * **The $0 limit doesn't consider what has been claimed.** Nothing stops a deduction taking a line below what the subcontractor has already claimed and been paid for it — check the claimed-to-date position first. * **Once a variation is approved or rejected, its lines are read only.** They show as a list on the Schedule of Values subtab. To change an approved variation, raise another one. ## Related * [Approve a subcontract variation](./approve-a-subcontract-variation) * [Raise a back-charge](./raise-a-back-charge) * [Create a subcontract](./create-a-subcontract) * [Assess a subcontractor claim](./assess-a-subcontractor-claim) --- --- url: 'https://fullclarity.help/subcontracts/reference/payment-dates.md' --- # Payment dates and what each one means Three different dates sit around every subcontractor payment claim, and in conversation all three get called "the due date". They mean different things, they are set by different people, and mixing them up is one of the most common causes of payment disputes. This page explains what each date is, where it appears, and which parts of it FullClarity determines for you — and, just as importantly, which parts it does not. \[\[toc]] ## The three dates | Date | Who sets it | What it means | |---|---|---| | **Claimed due date** | The subcontractor | The date they state payment is due, on their payment claim | | **Payment due date** | You, through the subcontract | The date payment actually falls due | | **Assessment due date** | The legislation and your subcontract | The date by which you must issue a payment schedule | ### Claimed due date In New Zealand, a payment claim must state a due date for payment. That statement is the subcontractor's, made on their own document. It is a statement of their position. **It does not change your payment terms.** A subcontractor cannot shorten the time you have to pay by writing an earlier date on a claim. When the subcontractor states a date, FullClarity records it as they submitted it. We do not alter it and we do not check it against your subcontract. If a New Zealand claim arrives without one, FullClarity fills it in when the claim is submitted: your payment due date where there is one, otherwise the default of 20 working days after the claim date. ### Payment due date This is the date payment actually falls due, determined by your subcontract. Where a subcontract is silent, New Zealand legislation supplies a default of 20 working days after the claim is served. **This is the date FullClarity prints as "Payment Due" on the payment schedule you issue.** Never the subcontractor's claimed date — see [Why we never print the subcontractor's date](#why-we-never-print-the-subcontractor-s-date) below. ### Assessment due date This is a different deadline entirely, and the one with the sharpest consequence. It is the date by which you must respond to the claim with a payment schedule. Where your subcontract sets a period, that applies. Where it is silent, the New Zealand default is 20 working days after the claim is served. **If you do not issue a payment schedule in time, you can become liable for the full amount claimed** — regardless of what you think the work was worth. FullClarity shows this date on the claim, and the Send Payment Schedules list counts down to it, because missing it is expensive. ## How working days are counted Where a period is expressed in working days, FullClarity counts forward from the claim date, skipping weekends and the public holidays configured for the relevant region. For New Zealand, no day from 24 December to 5 January counts either, as the Construction Contracts Act 2002 provides. For example, a claim dated Monday 5 October 2026 has a default due date of Tuesday 3 November 2026, because Labour Day (26 October) is skipped. Different compliance models count differently. New Zealand uses 20 working days. Australian Security of Payment timeframes vary, and some states count calendar days rather than working days. FullClarity applies the rule for the compliance model recorded on the subcontract. If your public holiday configuration is incomplete, dates will be calculated as though those days were ordinary working days. It is worth checking this at the start of each year. ## Why we never print the subcontractor's date On the payment schedule you issue, the "Payment Due" line always shows **your** payment due date, taken from the subcontract. If a subcontractor states a due date earlier than your subcontract provides for — whether deliberately or by mistake — and your payment schedule repeated that date back to them, it could be read as you accepting it. Your own document would then become evidence that payment fell due earlier than it did. **If your payment due date is missing, the line is left blank.** We do not substitute another date in its place. A blank is visible and can be corrected; a wrong date on a statutory document may not be noticed until it is being argued about. If you see a blank where you expect a date, the subcontract's payment terms are the place to look. ## What FullClarity does * Records the subcontractor's claimed due date as they stated it, and fills it in on submission when a New Zealand claim has none. * Calculates your assessment due date from the claim date, using the rule for the subcontract's compliance model and your configured public holidays. * Shows the time remaining to respond on the Send Payment Schedules list. * Prints your payment due date on the payment schedule. * Keeps the three dates separate, so that reminders and reporting always refer to the date that was actually meant. ## What FullClarity does not do * **We do not determine your payment terms.** They come from your subcontract. * **We do not check the subcontractor's claimed due date** against your subcontract, or tell you whether it is correct. * **We do not decide whether a payment claim is valid.** That is your determination to make. * **We do not provide legal advice.** The explanations here describe how the software behaves so that you can assess it against your own obligations. Where a date or a deadline carries consequences for your business, take your own advice. ## If the dates disagree A subcontractor's claimed due date and your payment due date can legitimately differ — most often because the subcontractor has applied different terms from those in the subcontract. FullClarity does not resolve that difference for you. Both dates remain visible on the claim so that the difference is apparent to whoever is assessing it. If it matters, it is better addressed when the claim is assessed than after a payment is alleged to be late. ## Related * [Assess a subcontractor claim](../head-contractor/assess-a-subcontractor-claim.md) * [Issue a payment schedule](../head-contractor/issue-a-payment-schedule.md) --- --- url: 'https://fullclarity.help/subcontracts/reference/prequalification.md' --- # Prequalification Before a subcontract can be signed, FullClarity checks that the subcontractor's compliance documents — insurance certificates, licences and the like — are in order. This check is called **prequalification**. It stops you issuing an approved purchase order to a subcontractor whose documents haven't been verified. \[\[toc]] ## When the check happens Prequalification is checked **once, at the moment you sign a subcontract** — when it moves from **Awarded** to **Signed**. Signing is the step that raises the approved commitment purchase order, so it is the step that is protected. The check isn't run when you create the subcontract, award it, or at any other step. ## Where the answer comes from The answer comes from the subcontractor's documents in **Certified Documents**. FullClarity reads them fresh every time you press **Sign**. You don't have to do anything on the subcontract to "refresh" it — once a document is approved in Certified Documents, the next **Sign** attempt sees it. ::: tip The Prequal Status field shows the check's result The subcontract's **Prequal Status** field shows the outcome of the last check — **Valid**, **Expiring Soon**, **Expired**, **Incomplete** or **Not Applicable** — and is display-only. It refreshes when you open the subcontract, when you change the vendor, when you press **Sign**, and once a day, so it's a reliable at-a-glance read of where a subcontractor stands. You can still check the subcontractor's documents directly in Certified Documents for the detail behind the result. ::: ## How the result is worked out Each of the subcontractor's documents counts towards one overall result, and **the worst document decides it**: | Result | When | What happens when you sign | |---|---|---| | **Valid** | At least one approved document, and nothing below applies | Signing goes ahead | | **Expiring Soon** | An approved document expires within the next 30 days | Signing goes ahead — arrange the renewal | | **Incomplete** | Any document is still in progress | Signing is **blocked** | | **Expired** | Any document has expired | Signing is **blocked** | | **Not Applicable** | The subcontractor has zero documents, or Certified Documents isn't installed on your account | Signing goes ahead | **A subcontractor with no documents at all reads as Not Applicable**, so signing goes ahead — there's nothing for the check to fail against. If you need documents on file for this subcontractor, request them in Certified Documents; the result will re-evaluate on the next check once documents exist. A document counts as **in progress** when its status is *Initialized*, *Requested*, *Pending Approval*, *Preparing Manual Request* or *Renewal Requested*. One in-progress document is enough to block signing, even if the subcontractor's other documents are all approved. Some statuses **don't count either way** — *Received*, *Declined*, *Rejected*, *Cancelled*, *Renewed* and *Not Requested*. A document in one of these states neither helps nor blocks. If Certified Documents isn't installed on your account, the check is skipped, signing goes ahead, and the Prequal Status field shows **Not Applicable**. ::: tip The check looks at what has been submitted Prequalification looks at the documents the subcontractor **has**, not at a list of the documents they're **required** to have. A subcontractor with one approved document and nothing else outstanding reads as Valid. Make sure every document you need has been requested in Certified Documents before you sign. ::: ## When signing is blocked When you press **Sign** and the check fails, the subcontract stays at **Awarded** and you see a page headed **This status change was not allowed**, with the reason and a link back to the subcontract. Nothing is saved and no purchase order is raised. To clear it: 1. Open the subcontractor's documents in **Certified Documents**. 2. Approve, renew or replace whichever document is in progress or expired. 3. Return to the subcontract and press **Sign** again. ::: warning Overriding a block An administrator override exists for exceptional cases, with a mandatory reason recorded against the subcontract. There is **no on-screen way to apply it yet**, and it can't be applied from the **Sign** button. If you need to sign a subcontract despite a block, contact your FullClarity support contact. ::: ## What gets recorded Every signing records the prequalification result on the subcontract's audit history — **Valid**, **Expiring Soon**, **Not Applicable**, or the override and its reason. This is the record that the subcontractor's compliance was checked at the moment the contract was executed. ## Related * [Subcontract states](./subcontract-states) * [Create a subcontract](../head-contractor/create-a-subcontract) --- --- url: 'https://fullclarity.help/subcontracts/reference/subcontract-states.md' --- # Subcontract states Every subcontract moves through a sequence of states from creation to closure. This page lists each state, what it means, and when the subcontract supports claims and variations. \[\[toc]] ## The shortest path The shortest path through the lifecycle is: ``` Draft → Awarded → Signed → Active → Closed ``` **Awarded cannot be skipped.** A subcontract can only reach Signed from Awarded, and the commitment purchase order is generated on that Awarded → Signed step — so a subcontract that somehow arrives at Signed by another route has no PO and nothing to claim against. Four further states — Tendered, PC, DLP and Final — are genuinely optional. Use the ones that match how your business runs and move past the rest. ## Moving a subcontract to its next state Use the buttons at the top of the subcontract. They appear when you're viewing the record, not editing it, and each one names the action rather than the state you land in: | Button | Moves the subcontract to | |---|---| | **Send to Tender** | Tendered | | **Award** | Awarded | | **Sign** | Signed | | **Commence** | Active | | **Practical Completion** | PC | | **Start DLP** | DLP | | **Final Account** | Final | | **Close** | Closed | | **Cancel Subcontract** | Cancelled — opens a page where you record the reason | Only the next step forward is offered. From Draft you'll see both **Send to Tender** and **Award**, because both are valid next steps. If your subsidiary has switched an optional state off, the button skips over it to the next state that's on. **Sign asks you to confirm**, because signing raises an approved purchase order to the subcontractor for the contract value. Signing is also where [prequalification](./prequalification) is checked. If a step isn't allowed — for example, prequalification fails — the subcontract stays where it is and you see a page headed **This status change was not allowed** with the reason and a link back. **Moving backwards isn't a button.** Returning a Tendered or Awarded subcontract to Draft is an administrator correction, made by editing the **Status** field directly. For everyone else the Status field is display-only, so the buttons are the way to change it. ## State reference | State | Mandatory? | What it means | Typical next step | |---|---|---|---| | **Draft** | ✓ | PM is building up the contract | Tendered (bid path) or Awarded (direct award) | | **Tendered** | optional | Out for bids from vendors | Awarded (once a bid is selected), or back to Draft | | **Awarded** | ✓ | Vendor selected, contract document in preparation | Signed (once executed) — this step generates the purchase order | | **Signed** | ✓ | Contract executed and approved | Active (on the commencement date) | | **Active** | ✓ | Work in progress, claims flowing | PC (on practical completion), or Cancelled | | **PC** | optional | Practical Completion certified | DLP (once PC retention is released) | | **DLP** | optional | Defects Liability Period running | Final (on DLP end date) | | **Final** | optional | All works completed, final retention released | Closed | | **Closed** | ✓ | Fully closed out — terminal | — | | **Cancelled** | ✓ | Terminated before completion | — | ## Allowed transitions | From | To | Condition | |---|---|---| | Draft | Tendered | Bid process initiated | | Draft | Awarded | Direct award | | Tendered | Awarded | Bid awarded | | Tendered | Draft | Reopen bid | | Awarded | Signed | Signed contract + approval; the subcontractor passes [prequalification](./prequalification) | | Awarded | Draft | Revert to drafting | | Signed | Active | Commencement date reached | | Active | PC | Practical Completion sign-off approved | | PC | DLP | PC retention released | | DLP | Final | DLP end date reached | | Final | Closed | Manual by AP after final bill settled | | (any) | Cancelled | With reason | ## When claims and variations are allowed Some actions are only allowed in specific states. The table below shows the windows. | Action | Allowed states | |---|---| | Submit a claim | Active, PC, DLP, Final | | Approve a variation | Signed, Active, PC, DLP | In other words, you can claim once the contract is active and any time afterwards through Final; you can vary once the contract is Signed and until DLP completes. Final is too late for new variations (raise an offsetting variation against an earlier-approved one if a correction is needed — see [Approve a subcontract variation](../head-contractor/approve-a-subcontract-variation)). ## Cancellation Cancellation is terminal and requires explicit pre-conditions: * No outstanding unpaid Vendor Bills * All open Claims in terminal states or withdrawn * Any unapproved Variations auto-withdrawn * Explicit retention disposition (release schedule or forfeit terms defined) * Mandatory cancellation reason Cancellation also requires top-level approval regardless of subcontract value. ## Related * [Create a subcontract](../head-contractor/create-a-subcontract) * [Prequalification](./prequalification) * [Approve a subcontract variation](../head-contractor/approve-a-subcontract-variation) * [Assess a subcontractor claim](../head-contractor/assess-a-subcontractor-claim) --- --- url: 'https://fullclarity.help/subcontracts/subcontractor-mobile.md' --- # For subcontractors — Connect Mobile The Connect Mobile app is the field-friendly companion to the Connect web app. Use it on site to look up your work orders, attach photos to claims, and submit progress claims without needing a laptop. \[\[toc]] ::: warning Early-access feature set Connect Mobile has shipped sign-in, work-order viewing and progress-claim submission. Photo attachments and push notifications are not yet available, and the app does not yet show you the outcome of an assessment — see each page for the current state. ::: ## What you'll do here * [Sign in](/subcontracts/subcontractor-mobile/sign-in) — install the app, sign in with your FullClarity Connect account, set up biometric unlock * [View your work orders](/subcontracts/subcontractor-mobile/view-your-work-orders) — see your active subcontracts and their detail (shipped) * [Submit a claim](/subcontracts/subcontractor-mobile/submit-a-claim-with-photos) — raise a progress claim from your phone, on site, online or off ## Where to get the app The Connect Mobile app is available on: * **iOS** — through the App Store as *FullClarity* * **Android** — through the Play Store as *FullClarity* Your administrator can also enrol you in the internal staging or sandbox build through TestFlight (iOS) or an EAS install link (Android) if you need to test against a non-production environment. ## How mobile fits with web The same Connect login works on web and mobile. They do different jobs: **submitting a progress claim is only possible on mobile**, while the web app is where you look over your purchase orders and projects on a bigger screen. ## Requires * A FullClarity Connect account at your organisation * An iPhone or Android device that supports the current FullClarity Mobile app version * An active internet connection for the initial sign-in (the app caches data for offline reads thereafter) --- --- url: 'https://fullclarity.help/subcontracts/subcontractor-mobile/sign-in.md' --- # Sign in to Connect Mobile Install the Connect Mobile app, sign in with your FullClarity Connect account, and enable biometric unlock for fast re-entry. \[\[toc]] ## When to use this The first time you set up the app on a new device, or when you change your password and need to re-authenticate. ## Prerequisites * Connect Mobile installed from the App Store (iOS) or Play Store (Android) * A FullClarity Connect account at your organisation — your administrator sets this up * Your login credentials ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the app. On first launch you'll see the FullClarity logo and a **Sign In** button. 2. Tap **Sign In**. Your phone's browser opens the FullClarity Identity Server sign-in page. 3. Enter your email and password. 4. The browser hands you back to the app automatically — you're signed in. 5. The app will offer to enable **Face ID / fingerprint unlock**. Turn this on for fastest access; you can change this later under Settings. ## What success looks like * You see the home screen with your active subcontracts grouped by head contractor. * The app remembers you next time you open it — you only need to unlock with biometrics or your device passcode. * Your account email is visible under **Settings**. ## Gotchas * **Sign-in opens in your phone's browser, not in-app.** This is intentional and secure — your password is never touched by the app. * **Biometric unlock re-locks the app after about 5 minutes in the background.** You'll see the unlock prompt when you return — tap to authenticate. * **You can switch off biometric unlock** under **Settings → *Require unlock to open***. Turn it off if you find the prompt friction outweighs the security benefit. * **If you lose access to biometrics** (e.g. you changed phones), tap **Sign In** again — the app will guide you through re-authentication. ## Related * [View your work orders](./view-your-work-orders) * [Submit a claim](./submit-a-claim-with-photos) --- --- url: >- https://fullclarity.help/subcontracts/subcontractor-mobile/submit-a-claim-with-photos.md --- # Submit a claim from Connect Mobile Raise a progress claim against a subcontract from your phone, on site, and have it queue and send even if you're out of signal. \[\[toc]] ::: tip Connect Mobile is the only place you can submit a claim Claim submission is not available in the Connect web app. If you need to raise a progress claim, use the mobile app. ::: ::: warning Photo attachments are not available yet Attaching photos to a claim from your camera or photo library is not yet in the app. If the head contractor needs photo evidence, send it to them separately for now. ::: ## When to use this At the end of a billing period — typically monthly — when you've completed work against a subcontract and want to claim for it. ## Prerequisites * Signed in to Connect Mobile — see [Sign in](./sign-in) * An active subcontract with the head contractor * Progress to claim against ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the subcontract you want to claim against. 2. Start a new claim. 3. Enter the amount you're claiming this period against each line. 4. Submit. Your claim is held on the phone and sent to the head contractor as soon as the app has a connection. You don't need to be online at the moment you submit — if you're out of signal on site, the claim queues and goes out when you're back in range. ## What success looks like * The claim shows in the app as submitted. * Once it has reached the head contractor's system, it stops showing as pending. ## Gotchas * **You won't see the outcome of the assessment in the app.** The head contractor assesses your claim in their own system, and the result — approved, reduced or rejected — is not sent back to the mobile app. Ask them directly, or wait for their payment schedule. * **A queued claim needs the app to be opened to send.** If you submit out of signal, open the app again once you have a connection so the claim can go out. * **Photo attachments aren't supported yet.** Send supporting photos to the head contractor separately. ## Related * [View your work orders](./view-your-work-orders) * [Sign in](./sign-in) --- --- url: >- https://fullclarity.help/subcontracts/subcontractor-mobile/view-your-work-orders.md --- # View your work orders Use Connect Mobile on site to look up a work order — its status, its contract amount, and the claims you've raised against it — without needing a laptop. \[\[toc]] ## When to use this When you're on site and need to check a work order's value or status, or see the claims you've already raised against it. ## Prerequisites * Signed in to Connect Mobile — see [Sign in](./sign-in) * At least one work order issued to you by a connected head contractor * An *Employee Linked* status — your administrator manages this ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. After signing in, the home screen shows your **Projects**, grouped by head contractor. 2. Tap a project to see its detail and the **Work Orders** (subcontracts) for that project. 3. Tap a work order to see the detail — its status, approval status, contract amount, the project's contract amount and retention held, and the claims you've raised against it. 4. **Pull down on any list** to refresh from the server. The app caches your work orders locally, so the screens still load when you're temporarily offline. ## What success looks like * You can navigate from **Projects** → **Project detail** → **Work Order detail**. * Work order detail shows the work order's status, its contract amount, the project context, and your claims against it. * Data is cached locally — screens still load when you're offline. ## Gotchas * **Work orders cache locally on first sync.** If you've just been added to a new project, pull down to refresh. * **The app supports offline writes as well as offline reads.** A claim submitted out of signal is queued on the phone and sent when you next have a connection — see [Submit a claim](./submit-a-claim-with-photos). ## Related * [Sign in](./sign-in) * [Submit a claim](./submit-a-claim-with-photos) * [View your subcontracts (web)](../subcontractor-web/view-your-subcontracts) --- --- url: 'https://fullclarity.help/subcontracts/subcontractor-web.md' --- # For subcontractors — Connect web If you're a subcontractor working on someone else's project, this is your section. The Connect web app is where you look over the purchase orders and projects a head contractor has shared with you. \[\[toc]] ::: tip Claims are submitted on mobile Progress claims are raised in the **Connect Mobile** app, not here — see [For subcontractors — mobile](/subcontracts/subcontractor-mobile). A claim surface for the web app is planned. ::: ## What you'll do here * [View your work orders](/subcontracts/subcontractor-web/view-your-subcontracts) — see the purchase orders issued to you, with status and value ## What isn't here yet * **Submitting a progress claim** — use [Connect Mobile](/subcontracts/subcontractor-mobile/submit-a-claim-with-photos) * **Requesting a change order** — raise it with the head contractor directly * **Subcontract detail** — Schedule of Values, contract value, variation history and retention balance aren't shown in the web app ## How Connect web fits Your view in Connect web is **scoped to your organisation**. You only see records from head contractors you've connected to. Your administrator manages those connections through Connect's *My Customers* area. ## Requires * A FullClarity Connect account at your organisation * A connection to the head contractor's organisation --- --- url: 'https://fullclarity.help/subcontracts/subcontractor-web/manage-variations.md' --- # Manage variations \[\[toc]] ::: warning Not available in Connect Requesting a change order through Connect is not available, in either the web app or the mobile app. Raise a change of scope with the head contractor directly — by email or through whatever process you have agreed with them. The Variation itself is always created and approved on the head contractor's side. When they approve one, it changes the value of your contract with them; ask them to confirm the revised value. ::: ## Related * [View your work orders](../subcontractor-mobile/view-your-work-orders) * [Submit a claim (mobile)](../subcontractor-mobile/submit-a-claim-with-photos) * [Subcontract states](../reference/subcontract-states) --- --- url: >- https://fullclarity.help/subcontracts/subcontractor-web/submit-a-progress-claim.md --- # Submit a progress claim \[\[toc]] ::: warning Not available in Connect web Progress claims cannot be submitted from the Connect web app. Claim submission is available in **Connect Mobile** — see [Submit a claim](../subcontractor-mobile/submit-a-claim-with-photos). A claim surface for the web app is planned. This page will be replaced with the how-to once it ships. ::: ## How to submit a claim today Use the Connect Mobile app on your phone. It works on site, and a claim submitted out of signal is queued and sent when you next have a connection. * [Sign in to Connect Mobile](../subcontractor-mobile/sign-in) * [Submit a claim](../subcontractor-mobile/submit-a-claim-with-photos) If you can't use the mobile app, send your claim to the head contractor directly and they will record it on their side. ## Related * [View your work orders](../subcontractor-mobile/view-your-work-orders) * [Subcontract states](../reference/subcontract-states) --- --- url: >- https://fullclarity.help/subcontracts/subcontractor-web/view-your-subcontracts.md --- # View your work orders See the purchase orders a head contractor has issued to you, along with your projects and the claims on record. \[\[toc]] ::: warning A full subcontract view is not available yet Connect web currently lists your **purchase orders**, not your subcontracts. There is no Schedule of Values, contract-value summary, variation history or retention balance in the web app today. For the contract detail behind a work order, ask the head contractor. ::: ## When to use this To check which purchase orders a head contractor has issued to you, their status and their value. ## Prerequisites * Signed in to Connect web at https://connect.fullclarity.com (or your organisation's Connect URL) * A connection to the head contractor's organisation — your administrator manages this ## Walkthrough 1. Sign in to Connect web. 2. Click **Work Orders** in the sidebar. 3. The list shows one row per purchase order, with its **PO Number**, **Status**, **Amount** and **Date**. ## What success looks like * You can see the purchase orders issued to your organisation, with their current status and value. ## Gotchas * **The list is read-only, and rows don't open.** There is no drill-through to a detail view in the web app. * **If a work order you expect to see is missing**, check with the head contractor that it has been issued to your organisation — Connect mirrors their system, it doesn't add visibility. * **To raise a progress claim, use the mobile app.** Claim submission is not available in Connect web — see [Submit a claim (mobile)](../subcontractor-mobile/submit-a-claim-with-photos). ## Related * [Submit a claim (mobile)](../subcontractor-mobile/submit-a-claim-with-photos) * [Subcontract states](../reference/subcontract-states) --- --- url: 'https://fullclarity.help/timeline.md' --- # Gantt for NetSuite Timeline — marketed as **Gantt for NetSuite** — brings full Gantt-chart project scheduling and resource management directly inside NetSuite. It runs as a SuiteApp; you don't leave NetSuite to plan, schedule, or update your projects. \[\[toc]] ## What it does Timeline turns a NetSuite project (Job) into a fully-featured Gantt chart with task hierarchies, dependencies, baselines, critical path, resource allocation and calendar management — all of it stored natively in NetSuite, secured by NetSuite roles, and visible alongside the rest of the project's financial information. The Gantt itself is rendered inside a Suitelet using a TreeGrid widget. Users can: * Drag bars to reschedule, with dependent tasks auto-updating * Add tasks inline with full hierarchy nesting * Link tasks with finish-to-start (FS), start-to-start (SS), finish-to-finish (FF) and start-to-finish (SF) dependencies, with lag * Track baseline plan dates against actuals * Apply project calendars that honour weekends and holidays (by country / region) * Allocate Employees, Vendors, Equipment, Roles or Crews to tasks * Roll up actual hours from Time Bill entries into task progress ## Capabilities at a glance | Capability | Notes | |------------|-------| | Gantt visualisation | TreeGrid-based chart with drag-and-drop, zoom, and critical-path highlighting | | Task hierarchy | Unlimited nesting via parent/child task relationships | | Dependencies | FS, SS, FF, SF, with positive or negative lag | | Baselines | Plan-vs-actual date tracking per task | | Resources | Five resource types — Employee, Equipment, Vendor, Role, Crew | | Calendars | Multi-calendar support — country/state holidays, project-specific working days | | Templates | Reusable schedules with relative day offsets, applied to new projects | | CSV import | Bulk task import with outline-number hierarchy and predecessor resolution | | Email notifications | Status-triggered emails (call-up, in-progress, reminder) | | Dashboard portlet | Timeline summary widget for the NetSuite dashboard | | CRM task sync | Generate native NetSuite Tasks from Gantt tasks; sync actuals back | | Timesheet integration | Actual hours from Time Bill records roll into task progress | ## Two main views **The Gantt chart** is the primary view, scoped to one Gantt at a time. Each project (Job) typically has one Gantt, though you can have multiple Gantts on the same project for scenario versions or what-ifs. **Resource Planning** is a secondary view that shows resource utilisation across every project in the account — filtered by resource type and grouped by resource. This is where you spot double-bookings; the chart doesn't proactively warn you at the point of assignment. ## How Timeline fits with the other SuiteApps * **Project Financials** — When PF is installed, Gantt tasks can be linked to Estimate items for billing and cost tracking. The link is detected automatically; no extra configuration is required. * **Field Service Management** (the standard NetSuite bundle) — When FSM is detected, Gantt tasks expose FSM Asset, FSM Task Type and FSM Task fields. * **Advanced Jobs** — When this NetSuite feature is enabled, the Gantt switches its project field from the standard Customer field to the Job field, letting you link Gantts to full Job records. ## Next steps * [Quick start](/timeline/quick-start) — your first Gantt on a project * [Install & configure](/timeline/install-configure) — dependencies, features, and the Timeline configuration record * [Create a Gantt from a template](/timeline/how-to/create-a-gantt-from-a-template) — reusable schedules * [Add tasks and dependencies](/timeline/how-to/add-tasks-and-dependencies) — build out the schedule * [Allocate resources](/timeline/how-to/allocate-resources) — assign people, equipment, vendors, roles, or crews * [Task fields reference](/timeline/reference/task-fields) — what each Gantt Task field means --- --- url: 'https://fullclarity.help/timeline/how-to/add-tasks-and-dependencies.md' --- # Add tasks and dependencies Build out a Gantt schedule by adding tasks, nesting them into a parent/child hierarchy, and linking them with dependencies. \[\[toc]] ## When to use this When building a new schedule from scratch, when adding scope to an in-flight schedule, or when refining the dependency structure as the project plan firms up. Most schedule changes — adding a task, splitting a task in two, re-parenting, or changing a dependency — start here. ## Prerequisites * A Gantt exists on the project — see [Quick start](../quick-start) or [Create a Gantt from a template](./create-a-gantt-from-a-template) * The project has a valid start date and project calendar * Permission to edit Gantt Task records ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: ### Adding a task 1. Open the Gantt for the project. 2. Right-click in the task list (the left pane) and choose **Add Task**, or use the **Add Task** button on the toolbar. 3. Type the task name inline. Set the **Duration** (in days) or the **End Date** — either drives the other. 4. The task lands as a top-level task by default. To nest it under a parent, see "Setting up parent tasks" below. ### Setting up parent tasks Tasks can nest under each other to form a hierarchy. Parent tasks are computed — their start date is the earliest start of any child, their end date is the latest child end, and their duration spans the whole range. 1. Click the task you want to make a child task. 2. Use the **Indent** action on the toolbar (or `Tab` while focused on the task name) to nest it under the task above. 3. The parent task is automatically flagged `Is Parent`, and its dates roll up from its children. You can outdent (`Shift+Tab`) to promote a child back to top level. Parent tasks can be marked **Expanded** or collapsed to control how the Gantt displays the hierarchy. ### Linking tasks with dependencies Timeline supports four dependency types, all with optional lag: | Type | Code | Meaning | |---|---|---| | Finish-to-Start | FS | Successor starts when predecessor finishes (the most common) | | Start-to-Start | SS | Successor starts when predecessor starts | | Finish-to-Finish | FF | Successor finishes when predecessor finishes | | Start-to-Finish | SF | Successor finishes when predecessor starts (rare) | To create a dependency: 1. Drag from the end (or start) of one task's bar onto another task's bar. Drag from the right edge for finish-side, the left edge for start-side. The combination determines the dependency type. 2. Confirm the dependency that appears. The dependent task's dates auto-adjust to honour the link. 3. To add lag, double-click the dependency and enter a positive number (delay after the predecessor) or a negative number (overlap with the predecessor). Lag units default to days but can be set to hours or weeks. You can also create dependencies by editing a task and adding predecessors directly in the **From Task** field, or successors in the **To Task** field. The visual link appears once the change is saved. ### Working with critical path Tasks with zero slack — meaning any delay pushes the project end date — are on the **critical path**. Timeline highlights critical-path bars visually on the Gantt. The critical path is computed by TreeGrid as you edit the schedule. ::: warning Author input needed A short explainer on reading the critical-path highlight in the UI — colour conventions, where to find the slack value in the task panel, and how to interpret partial-critical chains — would belong here. Confirm with the implementation team and update this page in Phase 5. ::: ### Constraint types Tasks can be constrained to dates beyond their natural dependency-driven scheduling — for example, a milestone that **must finish on** a contract deadline, or work that **must start no earlier than** a permit issue date. The supported constraints are: * **As Soon As Possible (ASAP)** — default; task starts as early as predecessors allow * **As Late As Possible (ALAP)** — task slips as late as possible without delaying the project * **Must Start On (MSO)** / **Must Finish On (MFO)** — hard date * **Start No Earlier Than (SNET)** / **Finish No Earlier Than (FNET)** — lower bound * **Start No Later Than (SNLT)** / **Finish No Later Than (FNLT)** — upper bound Set the constraint type and date on the task's Edit form, or via the Gantt's task properties panel. ## What success looks like * The new task appears in the task list with the dates you entered. * Parent tasks show summary bars that span their children. * Dependency arrows connect the linked tasks visually on the Gantt. * Tasks on the critical path are highlighted; tasks with positive slack appear in the default colour. * Saving the Gantt persists every change — refreshing the page loads the same state from NetSuite. ## Gotchas * **Date recalculation is client-side.** TreeGrid handles date propagation along dependency chains. If you make a change off-chart (e.g. via a saved-search update), the persisted dates won't recalculate until the Gantt is reloaded and saved. * **Tasks on a non-working day round to the next available working day.** If your project calendar marks weekends as non-working, a task scheduled to finish on a Saturday actually finishes the previous Friday (or following Monday, depending on direction). This is by design — work only happens on working days. * **Holidays added after a task is scheduled.** When you add a new holiday to the project calendar after tasks have been scheduled, TreeGrid's automatic recalculation doesn't always update existing task dates. Reload the Gantt and save it to force a re-evaluation. * **Deleting a parent task deletes its children.** Indented children are removed when their parent is deleted. Use outdent first if you want to keep them. * **Dependencies must be within the same Gantt.** A task in one Gantt can't depend on a task in another Gantt. If you need cross-Gantt dependencies, model them as separate single-Gantt schedules joined by milestones. ## Related * [Allocate resources](./allocate-resources) * [Create a Gantt from a template](./create-a-gantt-from-a-template) * [Task fields reference](../reference/task-fields) --- --- url: 'https://fullclarity.help/timeline/how-to/allocate-resources.md' --- # Allocate resources Assign Employees, Vendors, Equipment, Roles or Crews to Gantt tasks, and use the Resource Planning view to spot over-allocation across projects. \[\[toc]] ## When to use this Once the schedule has tasks and dependencies in place, before the project goes live. Resource allocation determines who or what is committed to each task — and is the basis for cost roll-up, schedule confidence, and over-allocation detection. ## Prerequisites * A Gantt with tasks already exists on the project * The resources you intend to assign are set up in NetSuite (Employees, Vendors, or the Timeline-specific records: Equipment, Roles, Crews) * Permission to edit Gantt Task records and create Resource Allocation records ## Resource types Timeline supports five resource types: | Type | What it represents | |---|---| | **Employee** | An individual person, sourced from your NetSuite Employee records | | **Vendor** | A supplier or subcontractor, sourced from NetSuite Vendor records | | **Equipment** | A piece of equipment from the Timeline Equipment catalogue (e.g. a crane, a scaffold) | | **Role** | A generic role placeholder (e.g. "Site Foreman", "Electrician") — used in templates, swapped for specific employees on application | | **Crew** | A group of employees that work together — assigning the crew assigns all members | Each task can have multiple resources assigned, with allocation **units** (e.g. `0.5` = half-time, `1.0` = full-time, `2.0` = two people). ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: ### Assigning a resource to a task 1. Open the Gantt for the project. 2. Click the task you want to assign. 3. In the task's right-hand details panel (or by double-clicking the task to open its Edit form), find the **Resources** sublist. 4. Add a new resource row: * Choose the **Resource Type** (Employee, Vendor, Equipment, Role, Crew) * Select the specific resource — the field is filtered by the chosen type * Set the **Units** (default `1.0`) 5. Save the task. The resource appears on the Gantt bar as a chip or label, and the allocation is recorded against the resource for cost and utilisation tracking. ### Swapping a Role for a real Employee Templates often use Role placeholders (e.g. "Concrete Sub") that need to be replaced with specific employees or vendors when applied to a project: 1. Open the task that has the Role placeholder. 2. Find the existing Role resource row. 3. Change the **Resource Type** from Role to Employee (or Vendor), and pick the specific resource. 4. Save. ### Assigning a Crew A Crew is a named group of Employees. Assigning a Crew to a task is equivalent to assigning every member of that Crew, with the unit value applied across the whole group. 1. Set up the Crew at **FullClarity → Timeline → Crews → New** — add Crew Members for each employee in the crew. 2. Assign the Crew to a task as you would any other resource. All members appear in utilisation calculations. ### Checking for over-allocation Resource Planning is the secondary view where over-allocation across projects becomes visible. 1. Navigate to **FullClarity → Timeline → Resource Planning**. 2. Use the toolbar filters to narrow by resource type (Employee, Vendor, Equipment, Role, Crew). 3. Toggle between **Used** and **Available** views to see total committed hours against capacity. 4. Look for resources where the daily totals exceed `1.0` of allocation — that's a double-booking. The Gantt itself **does not** warn you when you double-book a resource at the point of assignment. The Resource Planning view is currently the only way to catch over-allocation, so build a habit of consulting it before locking in a new schedule. ## What success looks like * Every working task on the Gantt has at least one resource assigned. * Resource Planning shows a coherent allocation picture, with no inadvertent double-bookings (or with conscious double-bookings flagged for resolution). * The project's cost roll-up reflects the actual resource commitments, not template placeholders. ## Gotchas * **No over-allocation warning at assignment time.** Resource Planning is the only check. If you're rolling out a complex resource plan, schedule a review session against Resource Planning before going live. * **Role placeholders need to be swapped out.** Tasks that arrive from a template with a Role on them won't roll up to a specific person until you swap the Role for an Employee or Vendor. Cost calculations on a Role placeholder use the Role's hourly rate, not a specific employee's rate. * **Crew membership is point-in-time.** Adding or removing a Crew Member changes future allocations for that Crew but does not retrospectively reassign past allocations. * **Resource dates inherit from the task.** A Resource Allocation record doesn't have its own start/end date — it inherits the dates of the task it's linked to. Move the task, and the resource allocation moves with it. * **Equipment is a Timeline record, not a NetSuite Item.** Don't expect Equipment to align with the Item master — it's a separate catalogue managed at **FullClarity → Timeline → Equipment**. ## Related * [Add tasks and dependencies](./add-tasks-and-dependencies) * [Create a Gantt from a template](./create-a-gantt-from-a-template) * [Task fields reference](../reference/task-fields) --- --- url: 'https://fullclarity.help/timeline/how-to/create-a-gantt-from-a-template.md' --- # Create a Gantt from a template Apply a reusable schedule to a new project so every job of the same shape starts with a proven task list, dependency graph and resource plan. \[\[toc]] ## When to use this Every time a new project has the same shape as a previous one — a typical residential build, a standard fit-out, a recurring service-and-maintenance cycle. Starting from a template saves the planner from rebuilding the same task list every time and gives schedulers a consistent baseline to estimate against. Templates are Gantt records flagged as `Template`. Their tasks store **relative day offsets** from the project start date rather than absolute dates, so applying a template to a new project automatically calculates real dates from the template's offsets. ## Prerequisites * Timeline installed and a Configuration record in place for the subsidiary * At least one template Gantt — see the template editor at **FullClarity → Timeline → Templates** to build one, or copy an existing project's Gantt and flag it as a template * A project (Job) record without a Gantt yet (or where you're willing to replace the existing Gantt) * Permission to create Gantt records (see [Install & configure — Permissions](../install-configure#permissions)) ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this task is being recorded. Track its status in the Scribe register (internal). ::: 1. Open the **project (Job)** in NetSuite. 2. Confirm the project has a start date — templates calculate every task date relative to that date. 3. Go to the project's **Timeline** subtab and click **Create Timeline**. 4. In the dialog that opens, choose **Copy from template**. 5. Select the template from the list. (If your administrator has set default templates for the project's customer or type, those appear pre-selected.) 6. Confirm. Timeline: * Creates a new Gantt linked to the project * For each task in the template, creates a Gantt Task with dates computed as `Project Start Date + Start Day Offset` * Reproduces the predecessor/successor dependency graph between tasks * Copies any resource role placeholders so the new Gantt is ready for resource assignment 7. Open the new Gantt to confirm the tasks have landed at sensible dates. ## What success looks like * The project's Timeline subtab now shows a Gantt populated with one task per template task. * Every task's Start Date is `Project Start Date + the template's Start Day offset`. * The dependency graph from the template is preserved — dragging any task slides the dependent tasks accordingly. * Role placeholders (e.g. "Site Foreman", "Concrete Sub") need to be filled with actual employees or vendors — see [Allocate resources](./allocate-resources). ## Building a template ::: warning Author input needed The template editor walkthrough — how to build a template from scratch, mark tasks as milestones, set the day offsets, and define role placeholders — needs a learning session with the Timeline implementation team. The template editor uses the same TreeGrid machinery as the regular Gantt but in template mode (relative day offsets instead of absolute dates), and the UX nuances are worth a dedicated walkthrough. ::: ## Gotchas * **Project start date must be set first.** Without it, the template applies but every task lands on the NetSuite account default date — usually today. Always set the project's start date before applying a template. * **Multiple Gantts per project.** Applying a template doesn't replace an existing Gantt; it creates an additional Gantt linked to the same project. If you intended to replace, delete the old Gantt first. * **Default templates can override.** Some accounts configure default templates per project type via the Configuration record. If a default applies, the dialog pre-selects it — change the selection if a different template is appropriate. * **Date recalculation is client-side.** When the Gantt opens after applying a template, TreeGrid recalculates dates against the project calendar (skipping weekends and holidays). If you see slightly different dates from the offsets, that's the calendar adjusting the schedule to working days. * **Roles vs employees.** Templates store role placeholders, not specific employees. Don't expect the new Gantt to come pre-staffed; you'll need to assign actual resources to the role rows. ## Related * [Add tasks and dependencies](./add-tasks-and-dependencies) * [Allocate resources](./allocate-resources) * [Task fields reference](../reference/task-fields) --- --- url: 'https://fullclarity.help/timeline/install-configure.md' --- # Install & configure Install the SuiteApp, enable the required NetSuite features, and set the per-subsidiary defaults that Timeline uses for calendars, email templates and feature flags. \[\[toc]] ## Module requirements **Required NetSuite features** * Custom Records * Server-Side Scripting * Units of Measure * Accounting * Jobs * CRM * Time Tracking * Workflow **Optional features Timeline supports if enabled** * Subsidiaries (OneWorld) * Opportunities * Custom Transactions * Custom Segments * Expense Reports * Multi-Location Inventory * Web Services Any required features that aren't already enabled will be flagged automatically during install — turn them on at **Setup → Company → Enable Features**. ## SuiteApp dependencies **Required** * **Code Library** (`com.fullclarity.codelibrary`) — installs automatically. Timeline depends on TreeGrid (the Gantt rendering library) and jQuery, both served from Code Library's File Cabinet, plus shared utility modules. **Optional integrations Timeline detects at runtime** * **Project Financials** (`com.fullclarity.projectfinancials`) — enables Estimate Task linkage on Gantt tasks for billing and cost integration. No extra configuration; the link appears when PF is installed. * **Field Service Management** (the standard NetSuite bundle 138180) — exposes FSM Asset, FSM Task Type and FSM Task fields on Gantt tasks. * **Advanced Jobs** (NetSuite feature flag) — switches the Gantt's project field from Customer to Job. ## Installing the SuiteApp 1. In NetSuite, navigate to **Customisation → SuiteApps → SuiteApp Control Centre**. 2. Find **FullClarity Timeline (Gantt for NetSuite)** and click **Install**. 3. Accept the Code Library dependency if not already installed. 4. Wait for the install to complete — the post-deploy script verifies the sample admin role's permissions and creates the default Timeline configuration scaffolding. ## The Timeline Configuration record Timeline has a configuration record per subsidiary. Navigate to **FullClarity → Timeline → Configuration → New** to create one. The configuration record captures: * **Default calendar** — the working-days/holidays calendar applied to new Gantts on this subsidiary * **Email templates** — Call-Up, In-Progress, Reminder templates used by the task email-notification workflow * **Email author** — the NetSuite user who appears as the sender on automated task notifications * **Feature flags** — toggles for optional behaviours (e.g. CRM task sync, automatic resource-allocation creation) In single-subsidiary accounts, one Configuration record is all you need. In OneWorld accounts, create one Configuration record per subsidiary that will use Timeline. ## Calendars Timeline ships with calendar machinery rather than a fixed set of calendars. Out of the box, you'll get an empty default calendar with weekends marked as non-working. To make it useful: 1. Navigate to **FullClarity → Timeline → Project Calendars**. 2. Create a calendar per region or jurisdiction (e.g. *Australia — NSW*, *Australia — VIC*, *New Zealand*). 3. Populate the holidays for that region — manually, or by importing from NetSuite's Holiday record type. 4. Set the calendar as the default on the Configuration record, or as an override on the Project record (`Project Calendar` field). Tasks honour the active calendar when computing start and end dates — non-working days are skipped automatically. ## Permissions Timeline ships with a sample admin role — `FC Timeline Admin` — that has full access to every Timeline record and feature. Treat this role as a **reference checklist** rather than a role to assign directly to users. In a normal deployment, an implementer extends the customer's existing roles (Project Manager, Scheduler, Foreman, Estimator, etc.) with the matching Timeline permissions rather than swapping users onto the sample role. The post-deploy script verifies that the sample role still has its required permissions after every upgrade — if it ever loses access to a Timeline record, the script repairs it automatically. ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for installing Timeline and creating the first configuration record is being recorded. Track its status in the Scribe register (internal). ::: ## What success looks like * Navigating to **FullClarity → Timeline** in the top navigation shows the Timeline centre tab with links to Gantt, Resource Planning, Templates, Project Calendars and Configuration. * A Configuration record exists for every subsidiary that will use Timeline. * Opening any project (Job) shows a **Timeline** subtab with a **Create Timeline** action. ## Gotchas * **Code Library is non-negotiable.** Even if Timeline appears to install successfully without Code Library, the Gantt won't render — the TreeGrid library is hosted there. Always install Code Library first (or accept the dependency prompt). * **TreeGrid version matters.** The Gantt is calibrated for TreeGrid 16.0. If Code Library has been customised to host a different TreeGrid version, expect rendering issues. * **Permission gaps surface as missing buttons.** Users without access to the Timeline custom records will see the Timeline subtab but no Create Timeline action. Walk through the sample role to see what they need. * **Project timezone.** Tasks store dates with timezone information; if the project's timezone isn't set, the system uses the NetSuite account default. For projects that span timezones, set the Project Timezone explicitly on the Job record. ## Related * [Create a Gantt from a template](./how-to/create-a-gantt-from-a-template) * [Task fields reference](./reference/task-fields) --- --- url: 'https://fullclarity.help/timeline/quick-start.md' --- # Quick start Open a project, create a Gantt, and add the first few tasks. \[\[toc]] ## The happiest path 1. **Install Timeline** from the SuiteApp Control Centre. Code Library installs automatically as a dependency. 2. **Open a project (Job)** in NetSuite. 3. Go to the **Timeline** subtab on the project and click **Create Timeline**. A dialog opens with two choices — **New (blank)** or **Copy from template**. 4. Choose **New** for now. The Gantt opens in the browser, scoped to the project, with no tasks. 5. Click the **Add Task** action and type a task name. The first task lands with a default duration; drag the right edge of its bar to extend it. 6. Add a second task. Drag from the end of the first task's bar onto the second task's bar to create a finish-to-start (FS) dependency. The second task's start date moves to align with the first task's finish. 7. Save. Your tasks now exist as records in NetSuite, linked to the project. That's the bare minimum. Real schedules typically start from a template — see [Create a Gantt from a template](./how-to/create-a-gantt-from-a-template). ## Walkthrough ::: tip Walkthrough coming A step-by-step Scribe walkthrough for this quick start is being recorded. Track its status in the Scribe register (internal). ::: ## What success looks like * The project's Timeline subtab shows a Gantt with one or more tasks. * The Gantt URL is bookmarkable and reloads to the same state. * Each task is queryable as a record in NetSuite — you can search the **FC Timeline Gantt Task** record type, run saved searches, or expose it on reports. ## Common stumbling blocks * **The Gantt area is blank.** Check that Code Library is installed (TreeGrid and jQuery are served from Code Library's File Cabinet — if those files aren't accessible, the Gantt can't render). * **Dates don't update when I drag.** TreeGrid runs date recalculation on the client. If the chart hasn't fully loaded the project calendar yet, drags can land without recalc. Refresh the Gantt and try again. * **"Create Timeline" button doesn't appear.** Confirm the user role has access to the Timeline custom records — see the [Install & configure](./install-configure) page for the required permissions checklist. ## Next steps * [Install & configure](./install-configure) — required NetSuite features and the per-subsidiary configuration record * [Add tasks and dependencies](./how-to/add-tasks-and-dependencies) — how parent tasks, lag and dependency types behave * [Create a Gantt from a template](./how-to/create-a-gantt-from-a-template) — start every new project from a proven schedule --- --- url: 'https://fullclarity.help/timeline/reference/permissions.md' --- # Permissions reference How Timeline grants access to its functionality, and how to give your users the right level of access on each role. \[\[toc]] ## The model FullClarity does not expect customers to assign the bundled FC Timeline Admin role to their users. Instead, Timeline permissions are granted *into the customer's existing roles* — Project Manager, Scheduler, Site Supervisor, whatever your users already use — so they can work with Gantt schedules, resource assignments, and task completions as part of their normal day-to-day NetSuite role, without role-switching. A dedicated Suitelet (the *allocator*) handles the underlying NetSuite plumbing. You pick a role and click **Grant**; the Suitelet adds Timeline's custom-record permissions to the role in one operation. ## How to grant access — the allocator The allocator gives a role Full access to all Timeline custom records. This is the recommended path for any role that needs to view or edit Gantt data. 1. Navigate to **FullClarity → Timeline → Assign Permissions**. 2. Select the role you want to grant access to in the *Selected Role* dropdown. Only roles flagged *iscustom* appear in the list — the bundled FC Timeline Admin role is deliberately excluded because it's pre-configured and doesn't need to be regranted. 3. Click **Grant**. The Suitelet adds the Timeline permissions to the role and records the grant in the FC Timeline Information record. To revoke a role's access, repeat steps 1–2 and click **Revoke**. The Suitelet removes every Timeline custom record line from the role's permissions, cleanly and symmetrically. ## What the allocator grants The Suitelet grants Full access to all Timeline custom records — Gantt records, tasks, dependencies, assignments, resources, crews, calendars, holidays, working days, and configuration. The full list is enforced from the SuiteApp's source and is updated whenever Timeline ships new records. The allocator does **not** add native NetSuite transaction, list, or setup permissions to the role. Timeline operates on its own custom records and doesn't depend on writes to invoices, bills, customers, vendors, or jobs the way Project Financials does — so the broader permission package isn't needed. If your users need access to standard NetSuite records (Customer, Job, Employee, etc.) for their day-to-day work, those permissions need to be on their role already, or added separately. Timeline doesn't require them and won't add them. ## Timeline is granted separately from other SuiteApps A role granted access to Project Financials, Retainage, File Storage, or Certified Documents does **not** automatically receive Timeline permissions. If a user needs Timeline in addition to another SuiteApp — for example, a Project Manager who manages both budgets in PF and schedules in Timeline — you'll need to grant Timeline access through this allocator and the other SuiteApp's allocator independently. ## Manual permission configuration In most cases the allocator is sufficient. If a role needs narrower than Full access to Timeline custom records (for example, View only for a stakeholder who reviews schedules but doesn't edit them), configure those permissions manually on the role after the allocator has run. NetSuite's standard custom-record permissions apply: None / View / Create / Edit / Full. ::: warning Manual changes are not upgrade-safe When Timeline is upgraded with new custom records, manually-configured roles will not automatically receive permissions on the new records. Re-running the allocator on the role re-applies the current full set; manual narrowing must be re-done each time. ::: ## Related * [Install & configure](../install-configure) * [Project Financials Permissions](../../project-financials/reference/permissions) * [File Storage Permissions](../../file-storage/reference/permissions) --- --- url: 'https://fullclarity.help/timeline/reference/task-fields.md' --- # Task fields reference The main fields on a Gantt Task record, grouped by purpose. This is a partial reference covering the fields most commonly edited or queried — the full record has roughly 50 fields, most of which are internal bookkeeping. \[\[toc]] ## Hierarchy | Field | Purpose | |---|---| | **Gantt** | The parent Gantt this task belongs to. | | **Parent Task** | If set, the task nests under another task. Parent tasks roll up dates and progress from their children. | | **Is Parent** | Computed checkbox. Indicates the task has children. | | **Hierarchy Name** | The full dotted path of the task (e.g. `Site Works.Earthworks.Bulk Excavation`). Useful for reporting. | | **Expanded** | Whether the task's children are shown expanded by default in the Gantt view. | ## Scheduling | Field | Purpose | |---|---| | **Start Date** | Mandatory. The task's planned start. | | **End Date** | The task's planned end. Either End Date or Duration drives the other. | | **Duration (days)** | Length of the task in working days. | | **Actual Start Date** | The task's recorded actual start. | | **Actual End Date** | The task's recorded actual end. | | **Deadline Date** | A reference deadline used for variance reporting (not a hard constraint). | ## Baseline | Field | Purpose | |---|---| | **Baseline Start Date** | The original plan start, captured at baseline-set time. | | **Baseline End Date** | The original plan end. | | **Baseline Duration** | The original planned duration. | | **Baseline Percent Done** | The original planned progress at this point in time. | ## Progress and work | Field | Purpose | |---|---| | **Percent Done** | Manual progress percentage. | | **Percent Done (Actual)** | Computed as Actual Work ÷ Target Work. | | **Override Progress** | Forces the manual Percent Done value rather than the computed actual. | | **Estimated Hours** | Estimated total hours of work. | | **Target Work** | Hours required to complete (used for actual-percent-done calculation). | | **Actual Hours** | Hours actually worked. | | **Actual Work** | Total effort applied. | | **Amount** | Cost — Rate × Duration, sourced from Time Tracking. | ## Constraints and dependencies | Field | Purpose | |---|---| | **Constraint Type** | One of ASAP (default), ALAP, MSO (Must Start On), MFO (Must Finish On), SNET (Start No Earlier Than), SNLT (Start No Later Than), FNET (Finish No Earlier Than), FNLT (Finish No Later Than). | | **Constraint Date** | Paired with the constraint type for hard or bounded dates. | | **Slack (days)** | Free slack. Tasks with zero slack are on the critical path. | | **From Task** | Predecessor task(s). | | **To Task** | Successor task(s). | ## Cost and status | Field | Purpose | |---|---| | **Cost** | Calculated cost of the task. | | **Cost Variance** | Difference between baseline cost and actual. | | **Status** | Task status from the Timeline status list. | | **Colour** | Hex colour for the Gantt bar — for visual grouping or highlighting. | | **Task Code** | Free-text identifier (often an outline number). | | **Notes** | Long-form notes on the task. | ## Resource assignment | Field | Purpose | |---|---| | **Resources** | The resources allocated to this task (Employees, Vendors, Equipment, Roles or Crews). | | **Estimate Tasks** | When Project Financials is installed, the Estimate items this task rolls cost up to. | ::: warning Author input needed The full Gantt Task record has more fields than are surfaced here — integration IDs, hidden phantom IDs, sandbox migration fields, Field Service Management fields and a number of UI-display fields. Most users never touch them. If a deeper reference is needed for advanced reporting, raise the request with the implementation team and this page will be expanded in Phase 5. ::: ## Related * [Add tasks and dependencies](../how-to/add-tasks-and-dependencies) * [Allocate resources](../how-to/allocate-resources)