Review the commercial transaction from item entry through tax, payment, fulfillment, receivables, and completion.
## At a glance
- **Identify it by:** **Sale #**, **Date Created**, **Fulfillment Status**, **Payment Status**, and **Foodservice Ticket Number**.
- **Check its business context:** **Customer**, **Salesperson**, **Warehouse**, **Cash Drawer**, and **Foodservice Table**.
- **Why care:** Customer, warehouse, quantities, prices, tax, payment, and fulfillment represent different parts of the transaction. Review each before treating the sale as complete.
- **Why care:** Treat posted, processed, paid, reversed, and edit-locked states as controls—not ordinary descriptive fields. Confirm the source transaction before changing any state that the screen permits you to change.
## Before you begin
You need the Brisk permission for the action you are taking on sales. If a Create, Edit, or Delete control is absent, do not work around it with another user’s account; ask an administrator to review your role.
Have valid **Customer** records ready first. Those selections determine where this sale belongs and which later screens can find it.
Find and review sales
The Sales list screen in the Brisk documentation demo.
Use the Sales list to find the correct record before opening or changing it. Compare **Sale #**, **Date Created**, **Fulfillment Status**, **Payment Status**, and **Foodservice Ticket Number**. Records with similar names or numbers can still belong to different **Customer**, **Salesperson**, **Warehouse**, **Cash Drawer**, **Foodservice Table**, and **Foodservice Server**.
- Keyword search checks **Memo**, **Customer Po #**, **Name**, **Item Code**, **Check Number**, and **Card Type**, plus the remaining screen fields.
- Narrow the list with **Customer** filters.
- The date filter uses **Date Created**; choose a range that matches the business event you are reconciling.
Open the sale whose **Sale #**, **Date Created**, **Fulfillment Status**, **Payment Status**, and **Foodservice Ticket Number** match the task. If it is missing, clear the list filters and recheck **Customer**, **Date Created**, **Fulfillment Status**, **Payment Status**, **Amount Paid**, and **Edit Locked** rather than creating a replacement immediately.
Create a sale
Create a sale only after confirming that the source document or operational event has not already been entered.
1. Select the business context first: **Customer**, **Salesperson**, **Warehouse**, **Cash Drawer**, **Foodservice Table**, and **Foodservice Server**.
2. Enter the required identifying and operational values: **Sale #**, **Customer**, and **Date Created**.
3. Review **Fulfillment Status**, **Fulfillment Required**, **Payment Status**, and **Edit Locked** deliberately; these choices control availability or workflow rather than merely describing the record.
4. Save the sale, then confirm **Sale #**, **Date Created**, **Fulfillment Status**, **Payment Status**, and **Foodservice Ticket Number** on its detail page before continuing.
After saving: Use Payment Status and Fulfillment Status separately: collecting money does not prove delivery, and fulfilling an order does not prove payment.
Delete a sale
Delete this sale only when it was entered by mistake and no downstream history depends on it. Use a reversal, void, credit, counter-adjustment, or status correction for a real event that later changed.
Before confirming, check for related **Commodity Sales**, **Customer Credits**, **Customer Payoff Records**, **Emv Refunds**, and **Inventory Records**, plus the remaining screen fields. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.
On the confirmation page, verify **Sale #**, **Date Created**, **Fulfillment Status**, **Payment Status**, and **Foodservice Ticket Number**. After confirmation, return to the Sales list and make sure only the intended sale was removed.
Review sale details
A draft fictional customer sale with two filter cartridges and an unpaid balance.
Use the detail page as the shared record of what this sale currently means. Verify **Date Created**, **Fulfillment Status**, **Payment Status**, **Non-Discount Subtotal**, **Subtotal**, and **Tax Total**, plus the remaining screen fields before relying on it for a decision.
Follow **Customer**, **Salesperson**, **Warehouse**, **Cash Drawer**, **Foodservice Table**, and **Foodservice Server** to determine whether the issue is on this sale or on one of those linked records.
Next check: Use Payment Status and Fulfillment Status separately: collecting money does not prove delivery, and fulfilling an order does not prove payment.
Edit an existing sale
Edit this sale to correct or complete the same source document or operational event; use the supported reversal or follow-up workflow when the business event itself changed.
1. Open the detail page. Compare **Customer**, **Salesperson**, **Warehouse**, **Cash Drawer**, **Foodservice Table**, and **Foodservice Server** with the supporting document or approved request.
2. Recheck **Customer**, **Date Created**, **Warehouse**, **Fulfillment Status**, **Payment Status**, and **Customer Po #**, plus the remaining screen fields. These values are most likely to change customer totals, tax, payment, fulfillment, and receivables.
3. Save the change, return to the list, and confirm that the sale now appears under the expected **Fulfillment Status**, **Payment Status**, **Amount Paid**, and **Edit Locked**.
After the change: Use Payment Status and Fulfillment Status separately: collecting money does not prove delivery, and fulfilling an order does not prove payment.
## Fields and business rules
Brisk stores 28 user-relevant fields for this sale, including 6 linked-record selections and 2 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this full reference.
| Field | Required | What it controls |
|---|---:|---|
| **Sale #** | Yes | A sale's friendly name, used to identify the transaction in receipts, reports, and searches. |
| **Customer** | Yes | The customer that made this purchase. |
| **Date Created** | Yes | The date and time that this transaction was started. |
| **Salesperson** | No | The salesperson assigned to this sale. |
| **Warehouse** | No | The physical location from which inventory items for this sale are sourced. |
| **Fulfillment Status** | No | Status information for pending deliveries or shipments for this sale. Available values: Draft, Submitted, Fulfilled, Contested, Complete, Cancelled. |
| **Fulfillment Required** | No | Marked as false for direct retail sales and service items, marked as true when shipments or deliveries are necessary. |
| **Payment Status** | No | Status information for pending payments and/or accounts receivable. Available values: Draft, Unbilled, Receivable, Paid, Refunded, Cancelled. |
| **Memo** | No | An open text field for employees to make notes about this transaction. |
| **Customer Po #** | No | An optional field to make note of the customer's purchase order number. |
| **Non-Discount Subtotal** | No | If a cash discount is applied to the ticket, this field represents the original, undiscounted subtotal. |
| **Subtotal** | No | The total sales price of all line items before sales tax. |
| **Tax Total** | No | The total sales tax due for this sale. |
| **Non-Discount Total** | No | If a cash discount is applied to the ticket, this field represents the original, undiscounted total. |
| **Payment Terms Discount** | No | Discount granted when eligible payment terms are paid immediately by cash, check, or card. |
| **Total** | No | The total value recorded for this sale. |
| **Amount Paid** | No | The amount paid value recorded for this sale. |
| **Balance** | No | The balance value recorded for this sale. |
| **Edit Locked** | No | Whether the edit locked option applies to this sale. |
| **Cash Drawer** | No | Links this sale to the cash drawer that it was rung up at. |
| **Pos Client Request Id** | No | Idempotency key supplied by the Point of Sale client for online and offline ticket submissions. |
| **Foodservice Mode** | No | The foodservice mode recorded for this sale. |
| **Foodservice Order Type** | No | The foodservice order type recorded for this sale. |
| **Foodservice Ticket Number** | No | The foodservice ticket number recorded for this sale. |
| **Foodservice Notes** | No | The foodservice notes recorded for this sale. |
| **Guest Count** | No | The guest count value recorded for this sale. |
| **Foodservice Table** | No | The foodservice table associated with this sale. |
| **Foodservice Server** | No | The foodservice server associated with this sale. |
## What happens next
Use Payment Status and Fulfillment Status separately: collecting money does not prove delivery, and fulfilling an order does not prove payment.
## Common mistakes and troubleshooting
- **The record will not save:** Recheck **Sale #**, **Customer**, and **Date Created** and any message beside the field. A required related record may also be inactive or unavailable to your role.
- **The record saved but is not available where expected:** Recheck **Fulfillment Status**, **Payment Status**, **Amount Paid**, and **Edit Locked**, then clear the filters on the destination list. A saved record can still be inactive, unpublished, locked, unapproved, or in the wrong workflow state.
- **The values look right but the result is wrong:** Open **Customer**, **Salesperson**, **Warehouse**, **Cash Drawer**, **Foodservice Table**, and **Foodservice Server** from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.
