Video chapters
- 0:00 Welcome
- 0:07 Overview: from quote to paid
- 0:38 Part 1 · Build and send a quote — Quotes and invoices: explained
- 1:02 A new quote for a new customer
- 1:36 Lines, discounts and tax
- 2:25 Save, preview and send
- 2:49 Part 2 · The customer's page — The customer's page: explained
- 3:12 Maya opens her quote
- 3:21 An edit, and her Refresh
- 3:38 She accepts
- 4:04 Part 3 · Get paid — Two ways to get paid: explained
- 4:28 A deposit by bank transfer
- 4:57 The balance, by card
- 5:41 Paid, verified, and an order
- 6:09 Part 4 · Follow-ups — Follow-ups: explained
- 6:34 Duplicate as a new quote
- 7:09 She declines
- 7:29 Overdue, reminder, cancel
- 8:09 Wrap-up
Written guide
Overview
Create and share an invoice, update the same document while the customer views it, and reconcile acceptance, payment and the resulting order.
Before you start
Prepare the actual customer record, currency, due date and line items. Use a saved catalogue product when the item must retain its product reference; a typed manual description serves a different purpose. The historical draft in this walkthrough is LL905905D, PO reference CEDAR-CATALOGUE-DRAFT-0930. The separate CS-QUOTE-0927 quote in retained material is not the same invoice.
The workflow is draft → saved preview → customer review → payment/acceptance → linked order, with separate confirmation at each handoff. The images below prove local editing and preview, not email receipt, automatic customer refresh or provider collection.
01. Create the document
Why this matters
Quotes and invoices share customer and line detail, but acceptance and payment are different decisions.
Follow these steps
Open Storefront → Invoice → Invoices → New Invoice. Expand the editor. Choose the intended type/status and enter Customer, Name, Email and Phone. Inspect billing/shipping addresses, currency, invoice date, due date and PO Reference. Add Line Item and Pick product for a catalogue-backed item, or enter a clearly identified manual line. Set quantity, unit price, line discount, tax and document discount. Save as Draft and reopen the invoice.
Check the result
Current invoice service excludes Draft from automatic create notification. Older retained evidence saying a filled Draft auto-sends is superseded. Non-draft creation with an email and payable content can notify. No variant picker was proven in earlier invoice capture: do not claim a specific variant from a parent product line.
Expanded New Invoice editor: select the customer and inspect currency, Draft status and dates before adding line items. Create Invoice is disabled while required details are incomplete. Inspected historical screenshot; recapture current layout before final video.
Add a catalogue item and save a checkable draft
- In Line Items, choose Add Line Item and open Pick product…. Search/select the actual product reference; the screenshot lists Cedar Botanical Print CF-PRINT-01.
- Check the populated Price, enter Qty and review Discount. A product name in this picker does not prove that a particular variant was selected.
The invoice is still a Draft and this frame has unsaved changes. Selecting the product is followed by quantity/price checks and Save.
- For the recorded exercise, the final draft contains two prints at $25 with a $5 line discount, giving $45. Check that the entered quantity is
2; do not rely on how the empty field looked before typing. - Choose Save. Close, find the invoice number in the list and reopen it. Check customer, USD currency, due date and the total in the footer.
The saved invoice remains Draft. Its list row and editor number agree. These example recipient/address values are training data.
02. Preview and share the customer document
Why this matters
The customer link must identify the same saved document the operator edits. Sending and copying a link are separate actions.
Follow these steps
Open Invoice Preview and compare line calculations and total with the editor. Obtain the actual payment/customer link from the invoice; if unavailable, read the reported reason and correct site/link readiness instead of constructing an invented URL. Use Send Invoice, verify email/phone and Send a copy to myself, then send to the controlled recipient. Open the received link in an independent customer browser.
Check the result
Keep internal notes separate from Customer Notes. A sent notice does not establish receipt. Earlier preview omitted line-discount explanation; inspect current rendering and report unexplained arithmetic.
Historical pre-repair preview: the $5 line discount is not separately explained, and HTML paragraph tags appear in the description. Current source has a plain-text description helper and explicit line-discount column; the regression suite checks both. This image documents the old defect, not the repaired current appearance. A fresh browser screenshot is still needed.
Before sharing: compare quantity × unit price, each discount, tax and amount due between editor and preview. If a discount is missing from the explanation or markup appears literally, correct/report the document presentation before relying on that view for customer approval. Preview is an operator view; it is not proof that a customer received or opened the link.
03. Update while the customer is viewing
Why this matters
This demonstration follows one invoice in two views. The benefit is that the customer can review the revised document without receiving a disconnected replacement.
Follow these steps
Keep the customer invoice page open and its number visible. In the operator editor change one line quantity or description, save and reopen to confirm persistence. Return to the same customer tab and inspect whether the revision arrives automatically. If it does not, use the page Refresh or reload and show that actual action. Compare the new line and total on both sides. Continue the conversation with the revised document visible.
Check the result
Never narrate real-time push unless observed. Do not switch to a new invoice or another screenshot between save and customer check. The script requires this full paired-view capture later.
04. Accept or decline a quote
Why this matters
Recording a decision on a customer’s behalf differs from a customer accepting on their own page.
Follow these steps
For a quote use the offered acceptance or decline control. The operator confirmation says Record that they accepted/declined; enter the customer’s name or decline note and confirm. Reopen the record and inspect conversion/status. Separately show a customer acceptance only if the actual customer page exposes and completes that action.
Check the result
The staff handler records acceptance on the customer’s behalf. Do not present it as a customer signature captured remotely.
05. Payment, partial balance and order conversion
Why this matters
Payment creates financial evidence; conversion creates the working order. Neither is implied by a printable invoice.
Follow these steps
Use Take Payment with the configured method and intended amount, complete the controlled payment and inspect transaction/reference, total paid and remaining balance. For a partial payment compare both the payment record and updated customer document. Use the supported Create Order conversion and follow the linked order. Confirm catalogue SKU and quantities survive; distinguish manual service lines from inventory-backed lines.
Check the result
Refresh before retrying an unclear collection. Mark Paid is not provider collection. The invoice can show its converted order link; use that link to avoid duplicate conversion.
06. Follow-up and correction
Why this matters
Overdue, duplicate, cancel/void and refund actions have different effects.
Follow these steps
Find the invoice by its saved due date/status, inspect the existing payment history and use Send Invoice for the intended follow-up. For a new document, prefer New Invoice and deliberately select the customer and lines. The current Duplicate handler deep-copies invoice data and clears number/status/date/send/paymentRef fields, but does not explicitly clear payments, refunds, amountPaid or orderNumber. Do not duplicate a paid, refunded or converted invoice and present it as a clean unpaid document. A controlled untransacted draft can be inspected after duplication; verify every financial field before use. For cancellation/refund, inspect the original invoice payment evidence and the actual resulting customer balance.
Check the result
Do not void an unrelated payment or refund twice because a preview is stale. Payment-provider execution, recipient delivery and customer refresh behavior remain live checks.
Invoice refund routing limitation: The invoice transaction-row Void action sends transactionId, but the current InvoiceService.refund implementation selects the last gateway-backed payment and does not use transactionId. Do not teach choosing a row as proof that its exact payment is refunded. For a multi-payment invoice, stop and resolve original-payment selection through a verified payment-specific path before refunding; the combined refundable invoice amount can exceed the selected last payment. Manual-only invoices record refunds without a provider transfer. The interface word Void currently invokes an invoice refund endpoint, not a demonstrated authorization void.
Conversion boundary: Create Order is a one-time snapshot of the invoice’s current payment state and cross-links both records. Later invoice payment changes are not established live synchronization to that order. Pay before conversion when that is the intended workflow, or explicitly reconcile later changes in both records.
Detailed instructions
The following retained material documents earlier local work. Its pending checks remain pending; historical successful outcomes are not claims of a fresh execution. Use the source-authored instructions above to prepare the new recording, and preserve these references for comparison.
T01: When a quote is better than immediate checkout
Worked example
For an agreed order, a quote can be more useful than immediate checkout. The separate Sales exercise, CS-QUOTE-0927, uses a manual line: two prints at thirty dollars, less five, total fifty-five. It was accepted, became an invoice and produced order J33TEUEWE. That order is New and unpaid, and its line says SKU N/A. This proves the quote-to-order route. It is not the Cedar catalogue purchase and does not prove stock allocation or payment.
Included controls: Dashboard, Invoices, manual/catalogue lines, customer/date, tax/discount/notes, draft quote, accept, invoice, Create Order.
Check the result: Actual Sales source only; samerecord evidence reused with clearorigin; full invoice setup remains next scene.
Retained evidence: ../crm-sales/research/FINDINGS.md.
Implementation reference: invoice-detail.tsx.
T02: Complete the invoice lifecycle
Worked example
A repeat buyer asks for two more prints at an agreed price. In Invoice Center, open Invoices and the saved Draft we're preparing. Use the Customer picker to select their existing account, then check Name and Email; here, we enter the missing display name. Choose Add Line Item, Pick product and Cedar Botanical Print. Selecting the catalogue record fills its identity and twenty-five-dollar rate. Set quantity to two and the line Discount to five: this takes five off the whole fifty-dollar line, leaving forty-five. Set the Due Date for the agreement and Save. Reopen the same invoice to verify the buyer, catalogue SKU, quantity and forty-five-dollar total. It remains Draft. A saved invoice amount is a request for payment; it isn't evidence that money was collected.
Included controls: catalogue selection, linked customer, save readback, print, send, payment link, reminders, overdue, duplicate, decline/reopen, cancel, partial/full payment, refund.
Limitations and checks: Existing saved DraftLL905905D edits verified: actual existingbuyer/catalogueparentSKU,2×25−line5=45, due2026-10-14, Save/fullreload. EmptyDraft→edit used solely to avoid NEW filled-record automatic notification. Safe ordinary create flow/warning still pending; Preview actual rawHTML description and omitted discount breakdown are pending defects. No Send, MarkPaid, TakePayment, CreateOrder, Print/PDF or lifecycle branches demonstrated.
Check the result: LL905905D Draft, existing customer email, CF-PRINT-01 parent catalogue SKU, qty2, unit25, lineDiscount5, total45 after reload. No payment or variant/stock allocation claim.
Implementation reference: invoice-detail.tsx, invoice-print.tsx.
Actual draft evidence: SF54-invoice-catalogue-draft.webm, SF54-invoice-catalogue-draft-events.json, 13-two-print45-reloaded.png, 14-saved-invoice-preview.png, final-readback.json, LEDGER.md.
A13: Partial payments and failed handoffs
Learner draft — pending demonstration:
A payment can be partial, complete or more than the balance. Check amount paid and amount remaining as well as the status. If the buyer paid but the order handoff failed, preserve the payment reference and look for an existing order before asking for another payment. Cancellation and refund also need separate money checks. The right recovery changes the failed part of the workflow without duplicating the successful part.
Included controls: partial payment, overpayment, cancel, duplicate/reload, payment complete/order incomplete, refund, balance reconciliation.
Limitations and checks: Authorized isolated test cases: partial/full/overpayment where supported, cancel, repeated/reload handoff, payment-complete/order-incomplete. Check the actual result; verify any provider refund separately.
Check the result: References, balances, idempotency/duplicate boundaries and recovery outcome actual.
Implementation reference: storefront.checkout.service.ts, storefront.payment.service.ts.
Limitations and checks
Current UI entry and editor: . Corresponding SDK storefront schemas and the retained AppEngine references define fields and consumer boundaries. Provider calls, external delivery, payments and financial mutations were not performed for this writing task.
Next steps
You can now follow the module from its configuration to the record that proves the result. Use the relevant chapter to revisit an alternative or troubleshoot the exact failed handoff.
BusinessMade Invoices — supporting guide
Overview
Create and share an invoice, update the same document while the customer views it, and reconcile acceptance, payment and the resulting order.
BusinessMade entry and scope
Open Storefront → Invoices at /storefront/invoices in BusinessMade. This route mounts the shared Invoices module; the surrounding menus are BusinessMade’s. Use Operations → Contacts for customer details, Operations → Customers & Benefits for group eligibility, Admin → Business locations for branches, and Operations → POS / Order entry for counter sales. Keep the organization and record identity consistent across those screens.
The location selector governs the venue-specific POS, but does not establish that every shared Storefront module filters its data by that selection. Inspect the record’s own location and currency. Payments are under Storefront → Payments, while delivery rules and shipments are under Storefront → Shipping; creating this module’s record is not payment or shipping-provider configuration.
Prepare the document, not just its total
Have a saved customer, the product or service you are billing, its agreed quantity, currency and due date. The business identifier and customer identity must remain the same when you switch between Contacts, Invoices and Orders. Use a controlled practice organization for the examples below. Recording cash or a transfer creates a financial record even when no online gateway is called.
The illustrated historical invoice is INV-V2NPJ0, one catering package at 480.00. It is a package item, so quantity one covers that package; the number of attendees is not automatically the line quantity. Use your own catalogue unit and agreed price. The newer customer-page example later in this course is a different fixture, explicitly labelled.
01. Create the document
Why this matters
Quotes and invoices share customer and line detail, but acceptance and payment are different decisions.
Follow these steps
Open Storefront → Invoices → Invoices → New Invoice. Expand the editor. Choose the intended type/status and enter Customer, Name, Email and Phone. Inspect billing/shipping addresses, currency, invoice date, due date and PO Reference. Add Line Item and Pick product for a catalogue-backed item, or enter a clearly identified manual line. Set quantity, unit price, line discount, tax and document discount. Save as Draft and reopen the invoice.
Check the result
Current invoice service excludes Draft from automatic create notification. Older retained evidence saying a filled Draft auto-sends is superseded. Non-draft creation with an email and payable content can notify. No variant picker was proven in earlier invoice capture: do not claim a specific variant from a parent product line.
Fill the customer, dates and line before saving
- Open Storefront → Invoices, select the Invoices tab, then New Invoice. Expand the editor so the customer, line and save controls are readable.
- Select the existing customer from Customer and inspect the populated Name, Email and Phone. Expand Address & Contact to check the billing and delivery addresses. Editing this document’s address is not proof the contact directory was also changed.
- Expand Dates. Set Invoice Date and Due Date deliberately. The due date is the payment deadline, not the delivery or reservation date.
Historical form with customer and dates entered but zero line items. Copy the procedure, not these old dates or training email.
- Expand Line Items, choose Add Line Item, then Pick product for a saved catalogue item. Inspect its description, quantity and unit price. Apply only the agreed discounts/tax, then check the displayed total. A manual line can describe work but is not automatically a stock-backed SKU.
- Under Notes, enter text for the customer in Customer Notes, and staff-only context in Internal Notes. Under Payment, Enable Online Payment controls online payment availability on the document; it does not configure Stripe/PayPal or a website checkout page.
Historical form showing the distinction between visible customer notes and internal notes. Its enabled switch is not evidence of a configured provider.
- Keep Draft while preparing, select Create Invoice, and reopen the saved invoice by its generated number. Verify the customer, lines and total again. Current source suppresses automatic create notification for Draft; an intentional Send and its recipient check belong to the next chapter.
02. Preview and share the customer document
Why this matters
The customer link must identify the same saved document the operator edits. Sending and copying a link are separate actions.
Follow these steps
Open Invoice Preview and compare line calculations and total with the editor. Obtain the actual payment/customer link from the invoice; if unavailable, read the reported reason and correct site/link readiness instead of constructing an invented URL. Use Send Invoice, verify email/phone and Send a copy to myself, then send to the controlled recipient. Open the received link in an independent customer browser.
Check the result
Keep internal notes separate from Customer Notes. A sent notice does not establish receipt. Earlier preview omitted line-discount explanation; inspect current rendering and report unexplained arithmetic.
03. Update while the customer is viewing
Why this matters
This demonstration follows one invoice in two views. The benefit is that the customer can review the revised document without receiving a disconnected replacement.
Follow these steps
Keep the customer invoice page open and its number visible. In the operator editor change one line quantity or description, save and reopen to confirm persistence. Return to the same customer tab and inspect whether the revision arrives automatically. If it does not, use the page Refresh or reload and show that actual action. Compare the new line and total on both sides. Continue the conversation with the revised document visible.
Check the result
Never narrate real-time push unless observed. Do not switch to a new invoice or another screenshot between save and customer check. The script requires this full paired-view capture later.
04. Accept or decline a quote
Why this matters
Recording a decision on a customer’s behalf differs from a customer accepting on their own page.
Follow these steps
For a quote use the offered acceptance or decline control. The operator confirmation says Record that they accepted/declined; enter the customer’s name or decline note and confirm. Reopen the record and inspect conversion/status. Separately show a customer acceptance only if the actual customer page exposes and completes that action.
Check the result
The staff handler records acceptance on the customer’s behalf. Do not present it as a customer signature captured remotely.
05. Payment, partial balance and order conversion
Why this matters
Payment creates financial evidence; conversion creates the working order. Neither is implied by a printable invoice.
Follow these steps
Use Take Payment with the configured method and intended amount, complete the controlled payment and inspect transaction/reference, total paid and remaining balance. For a partial payment compare both the payment record and updated customer document. Use the supported Create Order conversion and follow the linked order. Confirm catalogue SKU and quantities survive; distinguish manual service lines from inventory-backed lines.
Check the result
Refresh before retrying an unclear collection. Mark Paid is not provider collection. The invoice can show its converted order link; use that link to avoid duplicate conversion.
Read the recorded payment against this invoice
For a genuine deposit already received, open Take Payment, set the received amount, choose its actual manual method and enter a receipt reference. The historical local rehearsal recorded 200.00 against total 480.00. Close the payment form and expand Payments (1) on the same invoice.
Historical INV-V2NPJ0 readback: Manual · Cash, reference TUTORIAL-DEPOSIT-200, paid 200.00 and remaining 280.00. The older header still says Draft; inspect recorded amounts, not only that badge.
Reopen from the invoice list and compare the current record’s paid and outstanding amounts. An older dashboard omitted partially paid values; a separate repaired local rehearsal below includes paid 200, outstanding 280 and total 480. If a stale overview disagrees with the invoice’s payment history, do not record another deposit to make the dashboard change.
Separate Copper Kettle Review invoice INV-GPBV6F, not INV-V2NPJ0. This is retained repair evidence for partial-payment aggregation; dates and identities differ.
Convert once and retain the link
When an invoice should become an order, inspect its payment history first. Open More → Create Order once, then reopen the invoice and use the new Order # link. In the historical example, INV-V2NPJ0 points to HRVR94A4P. That relation is the handoff; an unrelated order with the same amount is not enough.
Historical invoice-to-order readback. Follow the link and inspect item identity/payment snapshot before starting fulfilment. This screenshot does not prove later invoice changes synchronize into the order.
06. Follow-up and correction
Why this matters
Overdue, duplicate, cancel/void and refund actions have different effects.
Follow these steps
Find the invoice by its saved due date/status, inspect the existing payment history and use Send Invoice for the intended follow-up. For a new document, prefer New Invoice and deliberately select the customer and lines. Current source makes a new number, resets the issue date/status, clears payments, refunds, amountPaid and converted order linkage, and sets amountPaid to zero. This supersedes the earlier carry-over defect. After Duplicate, inspect the new number, customer, lines, unpaid balance and absence of an order link before using the copy; this revision did not perform a fresh browser duplicate. For cancellation/refund, inspect the original invoice payment evidence and the actual resulting customer balance.
Check the result
Do not void an unrelated payment or refund twice because a preview is stale. Payment-provider execution, recipient delivery and customer refresh behavior remain live checks.
Invoice refund routing: Current source uses a selected transactionId, verifies it belongs to the invoice, and caps the refund at that payment’s remaining amount. The earlier claim that a selected row was ignored is superseded. A general invoice refund without a selected payment still chooses the last eligible gateway payment; do not assume it distributes across all tenders. Inspect the original method, already-refunded amount and resulting references. Manual-only refunds record a correction without initiating a provider transfer. The UI word Void is not proof of a card-authorization void. Current provider execution and repeat-request protection still need their own controlled live evidence.
Conversion boundary: Create Order is a one-time snapshot of the invoice’s current payment state and cross-links both records. Later invoice payment changes are not established live synchronization to that order. Pay before conversion when that is the intended workflow, or explicitly reconcile later changes in both records.
BusinessMade operational handoff — Keep the customer document and counter payment distinct
Why this matters
Invoices connects to the saved customer, product or transaction. Follow that identity through the BusinessMade operation rather than creating a second record to illustrate a result.
Follow these steps
Open Storefront → Invoices, create the document and select the intended existing customer. When customer details need correction, open Operations → Contacts, update the matching contact and return to the invoice to inspect its own saved customer/address values; do not assume a contact edit rewrites an issued document. Keep the real customer invoice link open in a second session. Save one agreed line or address correction, then inspect the customer document; refresh if live push is not present. Inspect the payment record in Storefront → Payments after payment and match the invoice reference and remaining balance. Use conversion to an order only once and follow the linked order.
Recovery and implementation boundary
Customer viewing, successful payment and order conversion each need their own result. A paid POS tab is not automatically proof that an unrelated invoice was settled. Never change invoice status merely to imitate provider payment.
Limitations and checks
Substantive pending work: Customer viewing, successful payment and order conversion each need their own result. A paid POS tab is not automatically proof that an unrelated invoice was settled. Never change invoice status merely to imitate provider payment. Runtime evidence for the taught handoff remains separate from authored coverage. Do not mark the course production-ready until the intended branch’s saved result, failure recovery and customer/provider outcome have been checked.
Next steps
You can return directly to the chapter for the change you need. Keep the saved record and its operational result together: the same customer, product, location and transaction should remain identifiable through each handoff.