> ## Documentation Index > Fetch the complete documentation index at: https://docs.arcsolar.com.au/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > ## What this documentation covers > This is the documentation for ArcSolar, the solar-retailer operating system: the web app a solar retailer uses to run quoting, sales, installation, rebates, inventory and reporting. ArcSolar is a hosted web application at https://app.arcsolar.com.au. There is no public API for most workflows, so agentic operation of ArcSolar is UI-driven. Navigate the app, read the labels and controls, and act through the interface, unless a page explicitly documents an API, contract or integration endpoint. > > ## How to read these pages > - Pages are split by audience using Mintlify's Visibility component, and this split is deliberate. Sections marked 'for agents' are hidden on the website and appear only in the Markdown you are reading. They are the authoritative behavioural specification for the page. Where the remaining human-facing prose and an agent section disagree, the agent section is correct. > - Sections outside any Visibility block appear in both outputs. They are the shared spine of the page: what the feature is and why it matters. > - Treat every bold label, field name, route, status string and error message quoted in an agent section as canonical. They are copied verbatim from the product. Use that exact wording when telling a user where to click, or when matching an error message to its cause. > - Australian solar vocabulary is used precisely and not interchangeably: STC (Small-scale Technology Certificate), PRC (Peak Reduction Certificate), REPS, NMI, CEC accreditation, VPP. Do not substitute an overseas equivalent. > - Money is Australian dollars. Dates shown to users are day-first (DD/MM/YYYY). > > ## Behaviour rules for operating or advising on ArcSolar > - Respect prerequisites and ordering. Agent sections state which inputs block progress and which steps must happen first. Do not skip a step, and do not assume a default that the product itself does not supply. > - Never invent a value the product requires but the user has not supplied. Ask for mandatory fields rather than guessing. Several features reject a request outright when one is missing, and submissions to external authorities are effectively irreversible. > - Respect permissions and scoping. Features name the roles, capabilities and access rules that may act. Do not attempt an action the operator's role cannot perform, and do not describe a restricted feature as available to them. > - Features that are gated, pending release, or blocked on a vendor are documented as exactly that. Never present a gated or unmerged behaviour as live. When availability is unclear for a given workspace, direct the user to support rather than asserting that the feature works. > - Where a page states something is genuinely undetermined, treat it as unknown. Do not fill the gap with a plausible guess. > - ArcSolar's built-in assistant is called ArgonixIntelligence. Pages end with an 'ArgonixIntelligence in this workflow' section stating what intelligence can and cannot reason from in that workflow. Treat those limits as binding: intelligence does not replace provider approval, verified evidence, or a customer's own confirmation, and it must not be presented as if it does. > > ## Getting help > Support is support@arcsolar.com.au. The customer-facing website is https://www.arcsolar.com.au. # Edit and publish a selling brand's agreement > Change the agreement wording customers accept, save a draft, get it published, and restore an earlier version. **Open:** [**Retailer Settings**](https://app.arcsolar.com.au/dashboard/quoting-settings?tab=documents) → **Documents**. The **Documents** tab holds one brand's agreement: the wording the customer reads and accepts when they sign, plus the details that appear on it. It edits the brand the **Selling brand** box has selected, so the agreement you are changing is always named in front of you. **Who can open it.** The tab follows the administrator-and-developer rule: other roles are sent back to **Pricing**, so the tab is absent from the strip rather than shown empty. **Publishing is narrower still — the workspace owner or a developer can publish.** ## Who can edit and who can publish | | An administrator who is not the owner | The workspace owner or a developer | | ----------------------------------------------------- | ------------------------------------- | ---------------------------------- | | Edit the agreement | Yes | Yes | | **Save draft** | Yes | Yes | | **Save and publish** | No | Yes | | Restore an earlier version | No | Yes | | Approve in **ArcSolar Settings → Customer documents** | No | Yes | The rule exists because the agreement is a promise the business makes. A draft is never an approval — the page says so under the editor: *"Saved draft version: N. A draft is never an approval."* When you can publish, the editor tells you exactly what a save will do: > *"Saving publishes immediately, so this wording is what customers receive. Every save is kept as a published revision below."* When you cannot, you can still edit and save drafts — but the version customers receive is not published until **the workspace owner or a developer** publishes it. ## What the agreement contains ### Supplier and contact details **Legal name**, **Trading name**, **ABN**, **Business address**, **Contact email**, **Contact phone** and an optional **Website URL**. On the **original brand** these come from **ArcSolar Settings**, so the card is read-only apart from the website — *"Original legal and contact details come from ArcSolar Settings. Refresh a saved draft after changing those details."* Use **Use current organisation details** to pull the latest values into the draft. On an **additional brand**, type them: they are that brand's own legal identity. ### Document email sender | Field | Notes | | ----------------------- | ------------------------------------------------------------------------------------------- | | **Sender display name** | What the customer sees the message from | | **Sender address name** | *"The part before @. The platform supplies the sending domain; no domain setup is needed."* | | **Reply-to email** | Where a customer's reply lands | ### Appearance For the **original brand** the card points at [Branding](/setup/branding) — *"Your original brand uses the organisation logos, colours and contract fonts in Retailer Settings → Branding. Approval captures their current version, so this editor keeps no appearance controls of its own."* For an **additional brand** you set **Primary colour**, **Secondary colour**, **Tertiary colour**, **Logo on light background** and **Logo on dark background** here, because they belong to that brand rather than to the workspace. Fonts for an additional brand are set from the **Selling brands** card's **Edit documents** on the **Branding** tab; this page links you there. ### Agreement wording The heart of the tab: | Field | What it is | | ------------------------------------- | ------------------------------------------------------------- | | **Terms and conditions (Markdown)** | The contract body, written in Markdown | | **Agreement title** | The heading the customer sees | | **Agreement acceptance statement** | The consent sentence the customer agrees to | | **Electronic communications consent** | Consent to receive documents electronically | | **Unsolicited-sale notice** | The notice used when a sale was not initiated by the customer | The Markdown field supports *"Headings, paragraphs, emphasis, links and numbered or bulleted lists"*; HTML, images, code and templates are not supported. A live preview sits directly under it, so you see the rendered contract as you type, and **Replace wording from a .md file** imports the field's content from a `.md` file — *"Markdown imported into the draft. Save to retain it."* Where the workspace has older clauses on file, **Replace wording with existing JBE clauses** copies them into this unapproved draft for you to review. Documents tab showing the Agreement wording card with a Terms and conditions (Markdown) field containing a sales and installation agreement for Northwind Energy Pty Ltd, the note listing the supported Markdown, a Replace wording from a .md file control, and the rendered agreement preview below it. An empty **Unsolicited-sale notice** means that version **cannot issue an unsolicited-sale contract**. The owner's review says so before you approve: *"No unsolicited-sale notice. This version cannot issue an unsolicited-sale contract."* If your team ever signs up a customer who did not come to you first, fill this in. ### Finance terms Tick **Include approved finance terms** to write the lender's actual terms into the contract: **Lender legal name**, **Lender ABN**, **Lender contact details**, **Finance terms**, **Annual interest rate (%)**, **Credit assistance fee (cents)**, **Monthly account fee (cents)**, **Minimum loan (cents)**, **Maximum loan (cents)** and **Available loan terms** (36 to 120 months). > *"Enter the lender's actual terms and supported loan range. Finance offers require these details to be approved."* Leave the box clear and the owner's review reports *"Finance offers are unavailable under this version."* **This is not where the deposit and installation terms live.** This section is the lender's approved wording. The deposit limit, stock-delivery payment and installation window are finance settings that apply to every contract — see [Finance is the single source of truth](#finance-is-the-single-source-of-truth). ## Save a draft, then publish The button at the bottom of the editor says what it will do: | Where you are | Button | Meaning | | ---------------------------------------------------------- | ----------------------- | -------------------------------------------------------- | | Documents tab, without publish authority | **Save draft** | Saves the version for the owner or a developer to review | | Documents tab, with publish authority | **Save and publish** | Saves *and* publishes in one step | | **Edit documents** dialog from the **Selling brands** card | **Save document draft** | Saves the draft only | Alongside them: **Contract preview**, **Discard edits and reload**, and **Close** in the dialog form. Saving a draft reports the version it wrote and that it is not yet live: a saved draft reaches customers only once **the workspace owner or a developer** publishes it. At the top of the card, one line always states where the brand stands: | Line | When | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ | | *"No document draft has been saved yet. Saving starts this brand's history."* | Nothing saved | | *"Draft version N is saved but not published yet."* | Draft only | | *"Published draft version N on DATE by NAME."* | Draft matches the published version | | *"Draft version N differs from published draft version N. Save and publish to update the version customers receive."* | Edited since publishing (with publish authority) | | *"Draft version N differs from published draft version N."* — the change reaches customers only when **the workspace owner or a developer** publishes it | Same, without publish authority | ### If publishing is unavailable An alert reads **Owner status could not be verified** — *"You can still edit and save a draft, but publishing is unavailable until the page can confirm that you hold owner authority. Reload the page to retry."* The page fails closed: not being able to *prove* the actor holds the workspace owner's authority (the owner, or a developer acting under it) is treated the same as not holding it, so no version is published on a guess. ## How a version is approved The approval surface is in [**ArcSolar Settings**](https://app.arcsolar.com.au/dashboard/settings?tab=organisation-documents) → **Customer documents** → **Approve brand documents**. Administrators prepare drafts in Retailer Settings → Documents, and **the workspace owner or a developer** reviews the current sources and retains an approved version here. Approval does not enable multi-brand selling or change payment accounts. The flow: 1. Choose the **Selling brand** if the workspace has more than one. 2. Choose **Prepare current draft review**. The panel shows the supplier identity, the email sender, the retained fonts, the colours and logos, the payment terms the draft was prepared with, the rendered words, and the lender's finance terms if present. 3. Choose **Download direct-payment preview** — and **Download finance preview** when the draft includes finance terms. Open them; the review says *"Open it and review the layout, fonts and full agreement before approving."* 4. Tick the confirmation, which cannot be ticked until the previews have been downloaded: > *"I have reviewed the downloaded previews and confirm this supplier identity, assets, agreement and payment terms are authorised for this brand."* 5. Choose **Approve this document version**. Success reads *"Document draft N approved and retained."* The line above the button always states the last retained approval — *"Latest retained approval: draft N, approved DATE. Changes to its sources may require a new approval before issuing."* ## Revision history and restoring a version **Published revisions** lists *"every version published for BRAND, newest first"*, each row showing **Draft N · date** and **Published by NAME**. Its description states the important property: > *"Restoring an earlier version publishes it as a new revision, so this history is never rewritten."* To go back: 1. Choose **Restore this revision** on the row you want. 2. Read the confirmation: *"The selected version is saved as the current draft and published as a new revision. Earlier revisions stay in the history, and customers receive the restored version once it is published."* 3. Choose **Restore and publish** — or **Keep current version** to back out. The outcome is reported plainly: *"Draft version N was restored and published."* If the restore saved but did not publish, the page says so and why rather than claiming success. An empty list is honest about itself: *"No revision has been published for this brand yet."* A failure to load the history is reported as a failure to load, never as an empty history. ## Preview the branded contract **Contract preview** sits with the editor and on [Branding](/setup/branding). It renders the brand's saved draft — its logo, colours, retained fonts and agreement wording — through the real contract renderer, and the dialog states *"A preview is never an approval."* Contract preview for Acme Solar dialog describing the render, above a PDF viewer at page 1 of 6 showing the DRAFT PREVIEW synthetic customer and amounts banner, the unsolicited-sale notice, the supplier block for [DEMO] Acme Solar Pty Ltd, a sample customer and installation address, and a footer reading Draft version 3, not approved, with Render again, Download and Close below. ## Finance is the single source of truth Three numbers on every direct-payment contract come from **Retailer Settings → Finance & deposits**, not from the document: * the **deposit limit** as a percentage of the customer balance, * the **stock delivery payment** percentage, and * the **installation window** in weeks. This is deliberate. The installation window is read from the workspace's Finance settings at the moment the contract is rendered, so a change there reaches the next quote immediately — and nobody can quietly store a different window inside an approved agreement. A configuration saved before these settings existed falls back to the platform default, **2–6 weeks**, which is what a fresh workspace also states. The contract words it in full: > *"N–N weeks from receipt of the deposit and/or Solar Victoria approval, subject to stock availability."* Keep that sentence's meaning in mind if you shorten the window: the phrase is part of the wording the customer accepts. See [Finance and deposits](/setup/retailer-settings#finance-and-deposits) for the fields, and [Prices per brand](/setup/price-books) for what sits behind the amounts. ## When the tab has nothing to show | Message | Cause | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | | **No selling brand to document** — *"This workspace has no selling brand you can configure yet. Create or enable one in ArcSolar Settings before editing its agreement."* | No brand is available to you | | **Fictional preview** — *"Documents read from the workspace, so this preview has none to edit or publish."* | You are in a demo workspace | ## Before you approve a version * The **legal name and ABN** are exactly right. They appear on the customer's contract and receipt. * The **trading name** is the name customers know the business by. * A **logo is present for both backgrounds**, in case any part of the document prints on the other one. * The **unsolicited-sale notice** is filled in if it applies. * The **installation window** on the preview matches what your Finance settings say, because that is what the next quote will promise. * The **finance terms** match the lender's current offer, if finance is offered at all. ## Related * [What a selling brand is](/setup/selling-brands) * [Branding](/setup/branding) * [Which settings screen do I want?](/setup/settings-screens) * [Selling brands FAQ](/reference/selling-brands-faq) ## Related topics - [Selling brands and settings: troubleshooting](/reference/selling-brands-faq.md) - [Sell under more than one selling brand](/setup/selling-brands.md) - [Set your branding and contract appearance](/setup/branding.md) - [Retailer Settings or ArcSolar Settings or Profile Settings?](/setup/settings-screens.md) - [Retailer Settings](/setup/retailer-settings.md)