Contracts — from Quote to Closed

A Contract is the legal sales document — and the trigger for nearly every downstream workflow in SMART. A change to its ContractStatusID is never just a status update: a single proc call cascades into the Lot, the Contact, the ChosenOption rows, the Schedule, the Estimate, the Purchase Orders, the Commissions, the Transmissions queue, and the audit logs.

This page starts with the lifecycle and how the four spProcessContract* procs cascade — the deep field-by-field details for each transition are one click away.

At a glance

• Every Contract belongs to exactly one Lot. The contract’s ContractStatusID drives the Lot’s status, the Schedule, the Estimate, POs, Commissions, and what gets sent to Business Central.
• Four core operations: Accept (qte → acc), Ratify (acc → rat), Close (rat → clo), Cancel (any → can). Each is implemented by spProcessContract<Op> and has a “reverse” path used by CSR scripts.
• Ratify is the big one — it locks the plan to the lot, sets ProcessEstimate=1, queues the schedule build, queues PO generation, and pushes deposits + closing dollars to the Business Central transmission tables.
• A buyer cancellation on a built spec auto-creates a new inventory contract at rat so the lot doesn’t sit empty.
• Every transition writes 3-character ProcessCodeID rows (S01, S02, F01, F11, C12, …) into ContractTransLog, LotTransLog, and ContactTransLog — the full audit trail of any contract.

94,485 contracts on Test (2026-06-02) · 45,884 deposits · 12,255 co-buyers · 79 columns on dbo.Contract.

How a contract is created

A new Contract row is inserted from one of three places:

Where	When
SMART → Sales → Contract Management → New	The standard sales path. A salesperson takes a Contact, a Lot, a Plan, and a price book and creates a row at qte.
SMART 1.0 (or thesmartbuilder.net) → Inventory release	An “inventory” contract has no ContactSysID — it’s the company’s spec home, started before a buyer is found.
Auto‑generated by spProcessContractCancel	When a buyer cancels a previously‑ratified home, SMART automatically inserts a new inventory contract at rat so the lot doesn’t sit empty.

A Contract row is uniquely identified by ContractSysID (identity int) and always references one Lot via the composite key (ProjectID, BuildingID, UnitID). There can be multiple historical contracts on the same lot — but only one is “live” at any point.

The contract lifecycle

1qteQuoted
Sales priced a Plan + Lot for the buyer. Nothing locked.

2lrLot Reserved
Buyer placed a small reservation deposit; the lot is held off the market.

3lcLot Reservation Cleared
Reservation expired or canceled. Lot returns to “For Sale”.

4accAccepted
Buyer signed. Earnest money posted. Lot moves to m Accepted (or stays in inventory flow).

5ratRatified
Build is authorized. Lot becomes f Sold (or i if contingent); Plan is locked onto the Lot; Estimate runs; Schedule is generated; POs are queued.

6sivSold Inventory
An inventory contract auto‑demoted from rat when a buyer’s contract takes over a spec already under construction.

7cloClosed
Closing happened. Lot locks at c. Buyer becomes a Homeowner. Bills can post; warranty starts.

8canCancelled
Sale fell through. Deposits and lot are unwound; if it was a built spec, an inventory contract takes its place.

See Contract Statuses for the literal lookup table.

What a Contract row carries

The Contract table has 79 columns on Test. Day-to-day you only touch a handful — ContractStatusID, RatifiedDate, EstimatedClosedDate, PlansID, AssignedID. The rest exist to support specific workflows (loan tracking, closing logistics, commissions).

All 79 Contract columns, grouped by purpose

Group	Fields
Identity	ContractSysID, ContractStatusID, ProjectID + BuildingID + UnitID, ContactSysID
Plan & price	PlansID, PlanName, PlanPrice, Address
Buyer agents	AssignedID (sales rep), BuyerAgentID, BuyerAgentBrokerID, ListingBrokerID, OriginalContactSalesAgent, OriginalContractSalesAgent
Lifecycle dates	AcceptedDate, RatifiedDate, CancelledDate, ClosedDate, EstimatedClosedDate, ScheduledClosing, RescissionDate, SchCompleteSaleDate
Lot reservation	LotReserved, LotReservationExpDate, LotReservationRatifyDate
Loan / financing	LoanPackageID, LoanTypeID, LoanNum, LenderID, FinanceLoanAmount, LoanAppliedDate, LoanApprovedDate, LockDate, LockExpiresDate, LockRate, MaximumInterestRate, ConditionalLoanApproval, FwdCommitID
Closing costs	ClosingCostAmt, ClosingCostPct, ClosingCostPaidBy, LenderPaidClosingCostAmt, FinanceCostAmt, FinanceCostPct, ConstrInterestAmt
Commissions	IntComAmt, IntComPct (internal sales rep), ExtComAmt, ExtComPct (external buyer’s agent)
Closing logistics	KeysInOffice, KeysOutOfOffice, KeysReceived, KeysSent, KeyID, MailboxNum, FinalSurveyReceived
Validation / posting	AcceptValidationPassed, Printed, PrintedDate, RatifiedAssignedID, ClosedAssignedID
Cancel handling	RescissionReasonID, CancelledPreviousSoldDate

What each status transition actually does

The four spProcess* procs each open a row in the Process table (visible in SMART → Administration → Process Monitor) and run inside a transaction. Every step writes audit rows into ContractTransLog and LotTransLog keyed by a 3‑character ProcessCodeID (full table: dbo.ProcessCode).

This is where most of the system’s behavior lives. Each transition has a high-level summary you’ll find here, with the full pre-checks, table changes, and reverse paths in the collapsibles below.

Accept — qte → acc

Driven by dbo.spProcessContractAccept. Triggered by Sales → Contract → Accept in SMART, and also by Inventory home releases. Validates that the lot is available and the options are still active, then moves chosen options from ContractOption onto the Lot’s ChosenOption rows, snapshots the price book, and flips the Contact from Prospect to Buyer.

Accept: full pre-checks, table cascade, and reverse path

Pre‑checks (sub‑procs, all must pass — see spProcessContractAccept_*):

• _VerifyLotAvailable — the Lot is s For Sale or z Not Available
• _LotNotInProcess — no other process holds the Lot
• _LotReserved — the lot reservation, if any, belongs to this contract
• _NoOtherAcceptedContracts — no other accepted/ratified contract on the same lot
• _NoSalesAgentCommission — sales rep has commission setup
• _OptionsNotDiscontinued — every chosen option is still active
• _PriceBookDetailRecordExists (+2) — every chosen option has a price in the active price book
• _VerifyBuyerAgentsCompany — buyer’s agent and broker are on the same company
• _VerifyLimitPlan — the lot’s LimitPlanType allows this plan
• _VerifyPurchaseOrder — there’s no PO blocker

What changes when it succeeds:

Table	Change
Contract	ContractStatusID = 'acc', AcceptedDate = <user date>
ChosenOption	All ContractOption rows are moved/inserted here. AcceptedQuantity = ContractOption.Quantity, SalesPrice = PriceBookDetail.SalesPrice (refreshed).
ContractOption	All rows for this contract are deleted (the options now live on the lot).
ContractPriceAdj	Rows with Accepted=0, Ratified=0 are flipped to Accepted=1.
Lot	Sale (has Contact): Status = 'm' Accepted. Inventory (no Contact): complex — see table below.
Contact	ContactStatusID = 'b' Buyer (was Prospect). ContactRank cleared and the previous rank is logged.
ContractLog / LotTransLog	S01 (sale) or F06 (inventory). ContactTransLog C12 (status change) and C13 (rank reset).

Lot status table for inventory accept (@ContactSysID IS NULL):

Lot was	AvailabilityType	Becomes
z Not Available	m Model	v Model Home
z Not Available	r R&D	w R&D Home
s For Sale	—	p Production Inventory
z Not Available	other	p Production Inventory

Reverse path (spProcessContractAccept called on an acc contract → qte):

• Contract: ContractStatusID='qte', AcceptedDate=NULL
• ChosenOption rows are unwound back into ContractOption
• Lot: buyer → s (or p if a plan was already locked); inventory → v→z, w→z, p→s
• Contact: ContactStatusID = 'p' (back to Prospect)
• ContractPriceAdj: Accepted=0
• Logs: S06 (sale) or F07 (inventory)

Ratify — acc → rat

Driven by dbo.spProcessContractRatify. Triggered by Sales → Contract → Ratify — the single most consequential operation in the system. It locks the Plan onto the Lot, sets ProcessEstimate=1 so the next batch builds the schedule and POs, queues deposits and ratify lines into Transmission* tables for Business Central, and (if the buyer is on a previously-inventory home) demotes the original inventory contract to siv.

Ratify: full pre-checks, Lot field updates, and side effects on sister contracts

Pre‑checks:

• _VerifyContractAccepted — must be currently acc
• _VerifyPurchaseOrder — no blocker POs
• All open ContractContingency rows must have ResolvedDate IS NOT NULL or the lot will be marked i Sold-Contingent instead of f Sold

What changes when it succeeds:

Table	Change
Contract	ContractStatusID='rat', RatifiedDate, RatifiedAssignedID = AssignedID, SchCompleteSaleDate = Lot.SchComplete
ChosenOption	RatifiedQuantity = AcceptedQuantity, AcceptedQuantity = 0, RatifiedDate = now, ProjectedCost computed from StdBookResource.Total
ContractPriceAdj	Rows with Accepted=1, Ratified=0 flipped to Ratified=1
Lot	See lot table below.
ChangeOrder (if change ratify)	RatifiedDate = <change date>
ContractTransLog / LotTransLog	S02 (sale) / F01 (initial inventory ratify) / F03 (subsequent inventory ratify) / S04 (change order ratify)
TransmissionMaster + TransmissionDeposit	One row per un‑sent deposit, batched by company + bank account, status H Hold (legacy Solomon path; today the BC Worker drains these).
TransmissionContractRatify	One row per Financial Template line — see Transmissions.

Lot updates on ratify (most important row in the system):

Lot field	Set to
PlansID	Contract.PlansID (the plan is now locked onto the lot)
planratified	1 (signals the CAD team)
PlansCADVersionSysID	latest PlansCADVersion for that plan category at the ratify date
SoldDate	Contract.RatifiedDate (only if buyer; null for inventory)
ProjectedCostPlan	SUM(StdBookResource.Total) for the plan’s standard book
ProjectedCostOption	SUM(StdBookResource.Total × (EstimatedQuantity + RatifiedQuantity)) across chosen options
PendingStatus	'sale' (buyer) / 'pstart' (initial inventory ratify) / 'pchng' (inventory change) / 'chgrat' (change order)
ProcessEstimate	1 — flags the lot for the next Estimate batch
Status	Buyer: 'i' if any open contingency, else 'f' Sold. Inventory: unchanged.
ProdRatifiedDate	RatifiedDate (only set the first time, only on inventory)

Side effects on sister inventory contracts (when a buyer ratifies on a previously‑inventory home):

[ buyer's contract ] rat            ← this ratify
[ original inv contract ] rat → siv ← demoted: "Sold Inventory"
                                       Log F11: "Lot has moved from Inventory to Sale"

If the inventory had no chosen options, the new sale’s lot is also flagged PendingStatus='', ProcessEstimate=0 (no estimate needed).

If the buyer was previously on a “doesn’t count” cancelled contract, Lot.SoldDate = Contract.CancelledPreviousSoldDate is preserved and an S02 'Sale Already Counted' log row is written so the sales bonus accounting isn’t double‑counted.

Close — rat → clo

Driven by dbo.spProcessContractClose. Triggered at the closing table (typically by Accounting in SMART → Accounting → Closings or SMART 2.0 → accounting/). After close, the Lot is locked (Status='c'), the Contact becomes a Homeowner, change orders that never accepted are cleaned up, and closing rows are queued for Business Central.

Close: full pre-checks and table cascade

Pre‑checks:

• _VerifyLotOwned — the Lot’s PurchaseDate must be set, and there can’t be unpaid land‑release POs (Permanentorderlog rows where OrderSource IN ('p','v') and InvoiceDate IS NULL and Amount <> 0 and CancelledDate IS NULL).
• _VerifyNoOpenPOs — no open construction POs.

What changes when it succeeds:

Table	Change
Lot	Status = 'c' Closed, CloseDate = <closed date>
Contract	ContractStatusID='clo', ClosedDate, ClosedAssignedID = AssignedID
Contact	Homeowner = 1, ContactStatusID = 'o' Owner
ContractDeposit, ContractPriceAdj, ChangeOrder	Any rows on un‑accepted change orders are deleted
EstimateErrorLog	All rows for this lot are cleared
ContractTransLog / LotTransLog	S09 Closing Posted
TransmissionLot (legacy Solomon) / TransmissionLotTransaction (legacy QuickBooks) / TransmissionContractPostClosing (BC)	One row each per closing

After close, the lot is locked: most edits (plan changes, option changes) are blocked unless an admin explicitly runs the Unclose a contract customer‑support script.

Cancel — any → can

Driven by dbo.spProcessContractCancel. Triggered by Sales → Contract → Cancel in SMART. Splits in two completely different paths depending on whether it’s a buyer’s contract or an inventory contract — the buyer path tries to keep the home alive as inventory; the inventory path zeros everything out.

Cancel buyer’s contract: full table cascade (the home stays alive as inventory)

Table	Change
WorkLotProcess	A “lock” row is inserted to block other processes (cleaned up at the end)
ContractOption	All rows deleted
ContractDeposit / ContractPriceAdj / ChangeOrder	Rows on un‑accepted/un‑ratified change orders deleted
ChosenOption	Non‑ratified rows deleted; spProcessContractCancel_ClearOutChosenOptions consolidates the remainder
Contract	ContractStatusID = 'can', CancelledDate, RescissionReasonID
Contract (extra, if RescissionReason.CountCancellation = 0)	CancelledPreviousSoldDate = RatifiedDate (so the sale isn’t double‑counted in metrics later)
Contract (extra, if FwdCommitID set)	FwdCommitID = NULL, log S40 Forward Commitment removed
Sister inventory contract	If a siv contract exists for this lot → revert it to rat (and spInsertContractPriceAdjCopyWithLot re‑copies its price adjustments). Else if no other rat inventory contract exists → insert a brand‑new auto inventory contract at rat with default financial settings.
Lot	SoldDate = NULL, Status = 'p' Production Inventory, PendingStatus = '', ProdRatifiedDate = SoldDate, ProcessEstimate = 1
Contact	ContactStatusID = 'p' (back to Prospect), C12 log
ChosenOption (rollback)	If options had been ratified, roll RatifiedQuantity → AcceptedQuantity and reset the sister inventory contract to acc so a CSR can review
ContractTransLog / LotTransLog	S05 Recission

Cancel inventory contract: full table cascade (the home is fully torn down)

Table	Change
ChosenOption	All rows on the lot deleted
LotSelection, LotSelectionActivity	All rows deleted
Contract	ContractStatusID = 'can', CancelledDate, RescissionReasonID
Lot	PlansID = NULL, Status = 'z' Not Available (unless 'a' Job Cost), PendingStatus = '', PlansCADVersionSysID = 1, planratified = 0, ProdRatifiedDate = NULL, StatusAtStart = '', ProjectedCostPlan = 0, ProjectedCostOption = 0
Estimate*	spUtilityDeleteEstimate clears the estimate (and its activities, resources, error logs)
ContractTransLog / LotTransLog	F02 Prod Home Unratified

How status drives downstream systems

Status changes don’t just update one table — they ripple out into Lots, Schedules, Estimates, POs, Commissions, Transmissions, and Contacts.

→ Lot

The Lot’s Status is largely a function of the latest Contract operation on that lot.

Full Contract.Status → Lot.Status table

Contract status	Lot.Status becomes	Other Lot fields
qte	s (or s + Reserved=1)	unchanged
lr	s with LotReservation* filled	Reserved=1
acc (sale)	m Accepted	PendingStatus=''
acc (inventory)	p / v / w (per AvailabilityType)	unchanged
rat (sale, no contingency)	f Sold	PlansID, SoldDate, costs, ProcessEstimate=1
rat (sale, contingency)	i Sold-Contingent	same
rat (inventory)	unchanged	ProdRatifiedDate, PendingStatus='pstart'
siv	unchanged	demoted; sale contract owns the lot now
clo	c Closed	CloseDate
can (sale)	p Production Inventory	costs zeroed, ProcessEstimate=1
can (inventory)	z Not Available	PlansID=NULL, all costs zeroed

→ Schedule, Estimate, POs

A rat event sets Lot.ProcessEstimate=1. Once the next estimate batch runs, the Schedule (LotSelectionActivity) and Estimate (EstimateActivity / EstimateResource) are populated, and Type='y' activities turn into Permanentorderlog (PO) rows. Cancel deletes all of this; close locks all of this.

See Estimates, Schedules, Purchase Orders, and Variances.

→ Commissions

acc saves the original sales agents (so commission stays attached even if reps change). rat stamps RatifiedAssignedID. clo is what actually creates Commission* rows and posts to BC. can either counts or doesn’t count against the rep’s bonus pool depending on RescissionReason.CountCancellation.

See Commissions.

→ Transmissions to Business Central

Each contract operation queues specific Transmission* rows that the BC Integration Worker drains every 5 minutes.

Full Contract.Status → Transmission table

Status change	Transmission queued	Drained by
qte → acc	(none today; legacy Solomon used TransmissionContractAccept)	—
acc → rat	TransmissionContractRatify (one per Financial Template line) + TransmissionDeposit (one per unsent deposit, batched by company + bank account) + later TransmissionPOGenerate (one per generated PO) + TransmissionLot (lot info)	BC Integration Worker, every 5 min
any → clo	TransmissionContractPostClosing, TransmissionPostClosing, TransmissionLot (final lot info), TransmissionLotTransaction (legacy QB)	BC Integration Worker
any → can	TransmissionContractCancel (sale) — inventory cancel does not transmit	BC Integration Worker
every PO release	TransmissionPOGenerate	BC Integration Worker

Each transmission is queued on TransmissionMaster with Status = 'N' (New) and moved to 'C' (Completed) or 'E' (Error) by the BC worker. See Transmissions and Transmission Statuses.

→ Contact

The buyer’s Contact.ContactStatusID is kept in lock‑step with the contract. acc → b Buyer; clo → o Owner with Homeowner=1; can → p back to Prospect. Each transition writes a C12 row to ContactTransLog.

Audit log: the ProcessCode reference

Every state change writes a 3-character ProcessCodeID row to ContractTransLog, LotTransLog, and/or ContactTransLog. This is your replay log — if you want to know “what happened to this contract on Tuesday at 3 PM”, these tables tell you.

All ProcessCodes used by contracts (S/F/C codes)

Code	Description	Written by
S01	Buyer Accepted	sale accept
S02	Sale Ratified (or “Sale Already Counted” subtitle)	sale ratify
S04	Change Request Ratified	change order ratify
S05	Recission	sale cancel
S06	Buyer Unaccepted	sale unaccept
S09	Closing Posted	close
S40	Forward Commitment	cancel (FwdCommit cleared)
F01	Prod Home Ratified	initial inventory ratify
F02	Prod Home Unratified	inventory cancel / unratify
F03	Prod Home Change Ratified	subsequent inventory ratify
F06	Inventory Accepted	inventory accept
F07	Inventory Unaccepted	inventory unaccept
F08	Inventory Changes Accepted	change order accept on inv
F09	Inventory Changes Unaccepted	change order unaccept on inv
F11	Inventory Sold	sale takeover or revert
C12	Status Changed	every Contact status flip
C13	Rank Changed	rank reset on accept

Where in the apps

App	Where	What you can do
SMART	Sales → Contract Management; Sales → Quote; Sales → Lot Reservation; Accounting → Closings; Administration → Process Monitor	Create, accept, ratify, cancel, close, change-order
SMART 2.0	sales/, accounting/, landdev/	Web dashboards; closing transmittal review; “TransmissionMasterErrorLog” review
Builder Portal	Schedule.aspx	Reads Contract.RatifiedDate and EstimatedClosedDate to show the build calendar
Trade Portal	Default.aspx, PO.aspx	Trades only see lots whose contract is rat or later
Home Owner Portal	Default.aspx, Schedule.aspx, Selections.aspx	Buyers only see their lot once their contract is rat
BC Integration Worker	n/a (background)	Drains every Transmission* row into Business Central

Customer-support / unwind scripts

When something goes wrong (accidental cancel, plan needs to change after ratify, contract closed by mistake), the data team has hand-written .sql scripts that unwind specific scenarios. Every one of them bypasses the normal procs and validation. Use only with explicit approval.

Full list of CSR unwind scripts (SOURCECODE/SMART/Documentation/CustomerSupportDocumentation/)

Script	What it does
UncancelContract.sql	Resets a contract from can back to a chosen status (qte/acc/rat); clears CancelledDate, RescissionDate, RescissionReasonID.
Unratify.sql	Reverses ratify back to acc (only safe if no estimate has been processed). Resets ChosenOption.RatifiedQuantity, Lot.PlansID, Lot.SoldDate, Lot.Status (m if buyer, p if not).
Unratify sale without inventory.sql	Same, but for a sale that didn’t have an underlying inventory contract.
Unclose a contract.sql	clo → rat; sets Lot.Status='f', clears Lot.CloseDate, sets Contact.Homeowner=0, Contact.ContactStatusID='b'.
ContractCancledAccidently.sql	Reverses an accidental cancel back to rat/siv and re‑sets Lot.Status='F', SoldDate.
ChangePlanOnRatifiedContract.sql	Updates Lot.PlansID and Contract.PlansID to a new plan after ratify (rare; requires re‑estimate).
AddBuyerAgentAndBrokertoContract.sql	Backfills missing buyer’s agent / broker on an already‑accepted contract.
UpdateCommissionContract.sql	Reassign commission on an already‑closed contract.
Add Buyer to Contract.sql	Adds a ContractCoBuyer row for missing co‑buyers.

Caution

Every one of these is a direct UPDATE/DELETE outside the normal stored procs — they bypass validation and audit logs. Always wrap in a transaction, run a SELECT first, and screenshot the row before you change it.

Common SQL recipes

The four queries developers ask for most often:

Open contracts (not yet closed/cancelled/cleared)

SELECT  c.ContractSysID, p.ProjectName, l.Address,
        s.ContractStatusName, c.AcceptedDate, c.RatifiedDate, c.EstimatedClosedDate
FROM    dbo.Contract c
JOIN    dbo.ContractStatus s ON s.ContractStatusID = c.ContractStatusID
JOIN    dbo.Lot l            ON l.ProjectID = c.ProjectID
                            AND l.BuildingID = c.BuildingID
                            AND l.UnitID    = c.UnitID
JOIN    dbo.Project p        ON p.ProjectID = c.ProjectID
WHERE   c.ContractStatusID NOT IN ('clo','can','lc');

Contracts ratified this month, with what’s downstream

SELECT  c.ContractSysID, l.Address, c.RatifiedDate,
        l.Status         AS lot_status,
        l.PendingStatus  AS lot_pending,
        l.ProcessEstimate,
        (SELECT COUNT(*) FROM dbo.ChosenOption co
         WHERE co.ProjectID=l.ProjectID AND co.BuildingID=l.BuildingID AND co.UnitID=l.UnitID
           AND co.RatifiedQuantity <> 0)        AS ratified_options,
        (SELECT COUNT(*) FROM dbo.TransmissionContractRatify tcr
         WHERE tcr.ContractSysID = c.ContractSysID) AS bc_ratify_rows
FROM    dbo.Contract c
JOIN    dbo.Lot l ON l.ProjectID=c.ProjectID AND l.BuildingID=c.BuildingID AND l.UnitID=c.UnitID
WHERE   c.RatifiedDate >= DATEADD(month, DATEDIFF(month, 0, GETDATE()), 0)
ORDER BY c.RatifiedDate DESC;

Replay a contract’s full audit trail

SELECT  ctl.EntryDate, pc.ProcessCodeID, pc.ProcessCodeDesc, ctl.AdditionalDesc, ctl.UserID
FROM    dbo.ContractTransLog ctl
JOIN    dbo.ProcessCode pc ON pc.ProcessCodeID = ctl.ProcessCodeID
WHERE   ctl.ContractSysID = @ContractSysID
ORDER BY ctl.EntryDate;

Stuck transmissions for a contract (“the closing isn’t in BC”)

SELECT  tm.TransType, tm.Status, tm.DateAdded,
        tcr.ContractSysID, tcr.AccountCode, tmel.ErrorDesc
FROM    dbo.TransmissionMaster tm
LEFT JOIN dbo.TransmissionContractRatify tcr
       ON tcr.TransmissionMasterSysID = tm.TransmissionMasterSysID
LEFT JOIN dbo.TransmissionMasterErrorLog tmel
       ON tmel.TransmissionMasterSysID = tm.TransmissionMasterSysID
WHERE   tcr.ContractSysID = @ContractSysID
  AND   tm.Status IN ('N','H','E');