Commodity Sales

Commodity Sales

Purpose and when to use this record

Record the sale and movement of a commodity, including customer, quantity, pricing, carrier, and settlement details.

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: Confirm item, formula, unit, warehouse, quantity, and production state together; mistakes can distort both material consumption and finished-goods cost.

• 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 storespermission for the action you are taking on commodity salessales. asIf parta ofCreate, theEdit, manufacturingor module.Delete This generated referencecontrol is awaitingabsent, workflowdo review.not work around it with another user’s account; ask an administrator to review your role.

Create

Have avalid record

The evidence packet identifies the viewCustomer, and sourceSale locationPtr forrecords ready first. Those selections determine where this action.Commodity ConfirmSale user-facing steps before approving this page.

View record details

The evidence packet identifies the viewbelongs and sourcewhich locationlater forscreens thiscan action.find Confirm user-facing steps before approving this page.it.

Find and review recordscommodity sales

The evidence packet identifiesUse the viewCommodity 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, plus the remaining screen fields.

• Keyword search checks Memo.

• 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 Commodity 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 Commodity Sale

Create a Commodity Sale only after confirming that the source locationdocument or operational event has not already been entered.

1. Select the business context first: Customer, Salesperson, Warehouse, Cash Drawer, Foodservice Table, and Foodservice Server, plus the remaining screen fields.

2. Enter the required identifying and operational values: Sale #, Customer, Date Created, and Sale Ptr.

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 Commodity Sale, then confirm Sale #, Date Created, Fulfillment Status, Payment Status, and Foodservice Ticket Number on its detail page before continuing.

After saving: Verify Fulfillment Status, Payment Status, Amount Paid, Edit Locked, Customer, and Salesperson, plus the remaining screen fields on the detail page, then continue the manufacturing workflow only when those values agree with the source document and actual work performed.

Delete a Commodity Sale

Delete this Commodity 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 Invoices, Customer Credits, Customer Payoff Records, Emv Refunds, and Freight Invoices, plus the remaining screen fields. Brisk may refuse deletion when another record depends on this action.one; Confirmresolve user-facingthe stepsduplicate 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 Commodity Sales list and make sure only the intended Commodity Sale was removed.

Review Commodity Sale details

Use the detail page as the shared record of what this Commodity Sale currently means. Verify Date Created, Fulfillment Status, Payment Status, Non-Discount Subtotal, Subtotal, and Tax Total, plus the remaining screen fields before approvingrelying on it for a decision.

Follow Customer, Salesperson, Warehouse, Cash Drawer, Foodservice Table, and Foodservice Server, plus the remaining screen fields to determine whether the issue is on this page.Commodity Sale or on one of those linked records.

Next check: Verify Fulfillment Status, Payment Status, Amount Paid, Edit Locked, Customer, and Salesperson, plus the remaining screen fields on the detail page, then continue the manufacturing workflow only when those values agree with the source document and actual work performed.

Edit an existing recordCommodity Sale

TheEdit evidencethis packetCommodity identifiesSale to correct or complete the viewsame 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, plus the remaining screen fields 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 Commodity Sale now appears under the expected Fulfillment Status, Payment Status, Amount Paid, and Edit Locked.

After the change: Verify Fulfillment Status, Payment Status, Amount Paid, Edit Locked, Customer, and Salesperson, plus the remaining screen fields on the detail page, then continue the manufacturing workflow only when those values agree with the source locationdocument and actual work performed.

Fields and business rules

Brisk stores 31 user-relevant fields for this action.Commodity ConfirmSale, user-facingincluding steps8 beforelinked-record approvingselections and 2 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this page.full reference.

Deletearecord

The

evidencepacket steps

Field	Required	What identifiesit controls
Sale #	Yes	A sale's friendly name, used to identify the viewtransaction in receipts, reports, and sourcesearches.
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 action.sale Confirmare user-facingsourced.
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 approvingsales tax.
Tax Total	No	The total sales tax due for this page.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.
Sale Ptr	Yes	Links this Commodity Sale to the selected sale; verify the relationship before saving.
Freight Vendor	No	Sets the freight vendor associated with this sale; assumed to be FOB if left blank.
Estimated Freight	No	Enter the estimated freight cost for this sale.

What happens next

Verify Fulfillment Status, Payment Status, Amount Paid, Edit Locked, Customer, and Salesperson, plus the remaining screen fields on the detail page, then continue the manufacturing workflow only when those values agree with the source document and actual work performed.

Common mistakes and troubleshooting

• The record will not save: Recheck Sale #, Customer, Date Created, and Sale Ptr 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, plus the remaining screen fields from the detail page. Correct the specific relationship that is wrong instead of forcing a total or status to compensate for it.