Sales Orders
The Sales Order (SO) is the heart of the Sales module — it is the commercial contract that confirms a booking. Unlike a quotation, a Sales Order supports multiple buyers (joint purchases) and multiple units, carries a payment schedule, and keeps a running payment timeline of money received and returned. As the order advances through its lifecycle it drives the booked unit's status, so your inventory always reflects reality.
Creating a Sales Order
Open Sales → Sales Orders and choose New Sales Order. You can also reach this pre-filled by converting a quotation (see Quotations).
Mandatory header fields
| Field | Notes |
|---|---|
| SO Date | Date of the order |
| Buyers (one or more) | Joint buyers supported; at least one required |
| Units (one or more) | Each must be available at the moment of booking |
| Project / Subproject | Scopes the unit selection |
| Salesperson | Owning user |
| Status | Starts at DRAFT |
| Payment Schedule Type | How instalments are structured (see below) |
| Valid Till | Offer validity |
The SO Number is generated automatically and is read-only for the life of the order — it never changes, even when you edit other fields.
:::note Rare: "conflicting concurrent request" If two users create a sales order at the very same moment, they can momentarily compete for the same SO Number. The system retries automatically; on the rare occasion it still can't settle on a free number, it stops and shows a message asking you to try again rather than saving a duplicate. Simply re-submit — the next attempt picks a fresh number. :::
Multi-buyer and multi-unit
- Multiple buyers let you record joint purchases — for example a husband and wife buying together. Each buyer is linked to the order and appears on the list and the PDF.
- Multiple units let one order cover several plots/flats. Each unit line carries its own rate (pulled from the Unit master) and an optional unit-wise discount, and bank details are printed unit-wise on outputs.
Unit availability is enforced
When you create or update an order, the system checks each selected unit inside a database transaction and locks the row so two orders can never book the same unit at once. If a unit is already Booked, Frozen, Registered, or Cancelled, the save is rejected with "Unit is not available for booking."
Auto-Calculated Totals
You never type the totals — the system computes them from the unit lines and the tax rates. The same formula is used for quotations and invoices, so figures stay consistent end to end.
| Amount | How it is derived |
|---|---|
| Grand Total | Sum of every unit's rate |
| Total Discount | Sum of every unit's discount |
| Taxable Amount | Grand Total − Total Discount |
| GST Amount | Taxable Amount × GST% |
| TDS Amount | Taxable Amount × TDS% |
| Final Amount | Taxable Amount + GST Amount − TDS Amount |
Guardrails: a unit discount can never exceed that unit's rate, discounts can never be negative, and totals can never go negative. All money is rounded to two decimals. For the complete worked example, see the Sales Calculations reference.
Paid and Due roll-ups
Two further figures track collections and update automatically as you record payments and returns:
- Paid Amount = total payments received − total payments returned
- Due Amount = Final Amount − Paid Amount (never below zero)
Payment Schedule Types
Every order is created against a Payment Schedule Type that defines how the customer is expected to pay. The available types are configured per organization in master data and typically include:
- Standard EMI — equal periodic instalments
- On Booking — due at booking
- On Agreement — due at agreement signing
- On Registration — due at registration
- On Full Payment — single full settlement
- Manual — a custom, manually managed schedule
Only active types appear in the dropdown, ordered as your organization has arranged them.
Payment Timeline and Returns
The payment timeline is the running ledger of money against the order. Each entry records the amount, the partner and bank account it went to, the payment mode, and a description — and it stamps who added it and when. Adding, editing, or deleting a timeline entry recalculates Paid and Due immediately.
Payment returns record refunds. A return captures the amount, the from-bank and to-bank accounts, the mode, and a reason. Returns are typically used during cancellation/forfeiture, and the system validates them against what was actually paid so the books stay balanced. Because returns can be needed on cancelled or forfeited orders, the timeline remains editable in those states for correction purposes.
The Sales Order Lifecycle
A Sales Order moves through a controlled set of statuses. The system only allows the transitions shown below — anything else is rejected with a clear message. Cancelling requires a note explaining why.
| Status | Meaning |
|---|---|
| DRAFT | Being prepared; freely editable; the only status that can be deleted |
| PENDING_APPROVAL | Submitted; awaiting a reviewer's decision |
| ACTIVE | Approved and live — the booking is confirmed |
| AGREEMENT_SIGNED | Sale agreement executed |
| COMPLETED | Fully concluded — leads to unit registration |
| INVOICED | A Sales Invoice has been raised against the order |
| CANCELLED | Booking cancelled (note required) |
| FORFEITED | Cancelled with amount forfeited |
| SHIFTED | Booking moved to a different unit |
| SPLIT | Order divided into separate orders |
How status drives the unit
Confirming and concluding an order automatically updates the unit it books, so you never touch unit status by hand:
| Sales Order becomes | Linked unit becomes |
|---|---|
| ACTIVE | BOOKED |
| AGREEMENT_SIGNED | Agreement Signed |
| COMPLETED | REGISTERED |
| CANCELLED or FORFEITED | AVAILABLE (released) |
See the Status & Lifecycle reference for the authoritative unit-status definitions, and Units for how these statuses appear to customers and on layouts.
Editing, History and Snapshots
Orders can be edited while DRAFT or ACTIVE. The SO Number is never editable. Every edit captures a full snapshot of the previous state into the order's update history, so you can always see what changed, who changed it, and when. If two people edit the same order at once, the second save is rejected with a "refresh and try again" conflict rather than silently overwriting.
Uploading TDS and Supporting Documents
Each Sales Order has a Documents section where you attach supporting files — TDS receipts, the signed agreement, ID proofs, and so on. When uploading you choose a document type (required) and may fill in any custom fields defined for that type. Documents are stored securely and retrieved through short-lived links; deleting a document is a soft delete and is recorded in the audit trail.
If your organization requires a TDS receipt whenever TDS is applied, upload it here before advancing the order — the system can be configured to block the next step until the receipt is attached.
Sharing the Order
From the details page you can Download PDF, Share by Email, or Share by WhatsApp. The PDF includes the buyers, all unit lines with rates and discounts, the full totals, and unit-wise receiver bank details so each payment is directed correctly.
Deleting a Sales Order
Deletion is deliberately restrictive to protect financial records. An order can be deleted only while it is DRAFT and only if it has no dependencies — no payments, no returns, no status history, no documents, and no update history. If any of these exist, deletion is blocked with "Cannot delete SO with transactions/history/documents." Deletes are soft (the record is retained for audit), never permanent.
Next Step
When the order is confirmed and you are ready to bill, move on to Sales Invoices.