Create a sell order
How to register a sale from start to finish — products, how the client pays, what changes when you finalize it, and what you can still do afterwards.
The sell order is the sale itself. Unlike a quotation, finishing one has consequences: it takes the stock out of inventory, it records the money that was collected, and it leaves a debt on the client when they are paying later. It is also the document a fiscal invoice is built from.
Sell orders live under Sells, in the list your team calls Sell Orders unless it has renamed them. Some screens may still show an older name for this document; it is the same document.
The list
/team/sell_orders shows the sell orders of the team you are in — or only those of the branch you are standing in, when your team uses branches. Each row carries the folio, the client, the category, the date, the total, how much has been paid, how much is still pending, the status and the payment status, and a branch column joins them when you are looking at every branch at once.
Unless your role is limited to your own records, the Created By filter opens set to you. Clear it to see everyone's. The other filters narrow by status, payment status, category and date range.
A sell order you opened but never saved is not listed.

Start one
Create Sell Order, at the top right of the list. You need the create permission, and your plan has to have room: when the team has used every document its plan allows, creating stops and a message points you at your plans.
If you sell over the counter and charge on the spot, Fast Orders in the same group is a shorter version of this same document, built for speed: one screen, cash already selected, a default client if your team configured one, and the ticket sent straight to print when you finish. When your team closes a cash register at the end of the day, it also asks you to open your shift before it lets you sell. Everything below describes the full form.
What the form asks
| Field | What it decides |
|---|---|
| Client | Who is buying. Required. Type to search; each result shows the client's phone under the name. If nobody matches, Create client opens a short form asking only for a name and a phone, already carrying what you typed. |
| Date | The date the sale carries. Required; it starts at today. |
| Category | Optional, from the categories your team created for sell orders. |
| User | Who is responsible for the sale. Required; it starts as you. |
| Initial Payment Type | How the client is paying right now. Required. This is the decision that shapes the rest of the screen — see below. |
| Description | Optional, one line. |
| Payment conditions | Optional free text — terms, deadlines, agreements. It prints on the document. |
Two things appear on the client field when they apply: a warning when that client already owes money, and, when your team uses the electronic wallet, the client's available balance with a checkbox to apply it to this sale.
Initial Payment Type
| Option | What happens |
|---|---|
| Full Payment | The client pays everything now. The payment you capture has to add up to exactly the order total. |
| Partial Payment | The client pays part now. You capture the amount; the rest stays as a pending balance on the sale. |
| Credit Payment | The client pays nothing now. No payment is captured, and the sale is finalized unpaid, ready to receive payments later. |
Choosing anything other than credit requires permission to register payments. If you do not have it, the field falls back to credit and the screen tells you to speak to your administrator.
Add the products
This part works exactly as it does on a quotation: the Product selector searches your catalogue, a barcode reader adds a product by its code while no field is focused, and each line carries a price, a discount, a quantity and a total, plus a subtotal and taxes column when your team invoices or has taxes enabled. Lines can be duplicated, removed and dragged into the order you want them printed in, and the Subtotal row carries a discount that applies to every product at once.
One difference matters. A sell order takes stock out, so when your team uses inventory the quantity is checked against what is actually available:
- the quantity field will not go above the stock at your branch;
- a line over the available stock is marked Exceeds stock and names what is left;
- finishing is refused, with the product, the available quantity and the quantity you asked for.
Products that track stock show their current quantity under the quantity field, so you can see what you are working with before you commit.
When your team uses terms and conditions, the section under the products lets you add or remove terms for this sale only.
Capture the payment
Unless the sale is on credit, a Payment section appears under the products.
The Payment Method field lists your team's methods — cash, credit card, bank transfer, debit card, plus any method your team named itself — and one extra option, Several payment methods, for a sale split across more than one.
What the section asks then depends on the method:
- Cash asks for Total Received and shows the Money Change it works out. What you received cannot be less than what is being paid.
- Credit card shows the Commission it adds, already calculated, and asks for a Validation Number.
- Bank transfer asks for an Authorization Number.
- A partial payment asks for the Amount To Pay.
- Payment Date records when the money actually came in; it starts at now.
Whether those reference numbers are obligatory is a team setting.
With Several payment methods you get one block per method, each with its own method and amount, an Add payment method button for another, and a running line underneath showing what you have Captured and what is Remaining. The captured total can never exceed what the sale is worth, and on a full payment it has to match it exactly.
Finish it, or leave it for later
Three buttons close the form.
Generate PDF produces a preview before the sale exists as a finished document. It runs the same checks as finishing, then asks for a folio and an optional description and downloads a PDF showing the sale as it will be once finalized, payment included. When your team uses internal orders, the same panel can save it as one instead.
Save as draft keeps it as a draft: it checks the required fields and returns you to the list. A draft has no folio, moves no stock, can be edited freely, and is the only state in which a sell order can be deleted outright.
Finalize Sell Order issues the sale. Before it does, it checks everything: the required fields, that the sale has at least one product, that the total is not negative, that reservable products are free for their dates, that there is enough stock, and that the payment adds up. Any of those failing stops the sale and says why.
What finishing changes
- The sell order receives its folio — the next number for your team, or for your branch when your team uses branches.
- The stock of every product that tracks inventory comes out.
- On a full or partial payment, the payments you captured are recorded as collected, on the payment date you gave.
- On credit, no payment is recorded and the sale is marked unpaid.
- Reservations are created for any reservable products.
- The sale can no longer be edited from this form.
A panel then opens with what to do next: View the sale's own file, the PDF controls to open, download or email it, Send by whatsapp when the client has a phone and your plan still allows sending documents, and the Direct link to the public page, which you copy by clicking the field.
After the sale
Open the sell order's file from the list to see everything on it: products, totals, how much is paid and pending, the payment and adjustment history, related documents and the full timeline. The panel on the right is where the remaining actions live.
| What happened | What to do |
|---|---|
| The client pays some or all of the balance | Add payment — method, amount and date. Needs the payment permission |
| The client returns product | Register return — pick the products and quantities, say whether what came back is restockable or damaged, and record the refund. Needs the returns permission |
| You forgive part of what is owed | Apply post-sale discount — it reduces the pending balance and moves no money. Needs the discounts permission |
| The sale has to be undone | Cancel Sell Order — a reason is required, and you choose whether to register a refund and whether to return the stock. Needs the delete permission |
| The sale has to be rebuilt | Recycle — creates a new version of the sale, carries the payments over to it, returns the stock, and marks the old one as replaced. Both versions stay linked and visible |
| The client asks for an invoice | Create fiscal invoice, when your team has fiscal invoicing set up. If the sale already has one, it asks whether you want another |
| You want the same sale again | Clone |
A finished sell order is never deleted. Cancelling keeps it, with the reason, the person who cancelled it and the date, on the record for good.

Permissions
| Action | Permission, on the team guard |
|---|---|
| See the list and open a sell order | retrieve sell_order |
| Create one, and keep editing your own draft | create sell_order |
| Edit someone else's draft, or edit a finished sale | update sell_order |
| Delete a draft, or cancel a finished sale | delete sell_order |
| Capture a payment, here or later | create payment |
| Register a return | return_sell_orders |
| Apply or remove a post-sale discount | discount_sell_orders |
| Create the fiscal invoice | create fiscal_invoice |
The team owner passes all of them without holding them. A role that only sees its own data works its own sales without the general read permission, but still needs the update and delete permissions to change or cancel them.
If you arrived here from a quotation, the conversion already filled in the client, the products, the prices and the terms — you land in this form with the payment left to capture. See Create a quotation.