Sales Receipts
A sales receipt (SR) is the direct-to-consumer counterpart to the sales order. Where a sales order commits whole cases to a wholesale customer, a sales receipt records a direct-to-consumer order and can move fractional cases. The two are independent documents: a receipt is never tied to a sales order, and it carries its own number, its own lifecycle, and its own line items. Like the sales order it is the demand side of finished-goods inventory and single-sided: it draws products down and never produces or consumes materials.
Most receipts arrive on their own: the orders of a connected Shopify or Amazon store are synced into Pharus as receipts. A sale no connected feed carries can be recorded by hand through the webclient, the REST API or the MCP server. Either way it is the same document: every receipt is listed, read and filtered the same way and names its source (manual, Shopify or Amazon). A synced receipt is read-only apart from its notes, since the sync owns it; a manual one is edited by hand. Product coming back from a completed receipt is handled by the separate sales returns module, layered on top without touching the receipt's own flow.
What it does
- Track the order. At its core a sales receipt is a record of a consumer order: who the
customer is, the sales channel it came through (optional, picked from the same channel list
as sales orders), where it ships from, what they ordered, what they paid, and how far along
it is. The money follows the marketplace's own picture: the list subtotal, discounts, the
net subtotal (the receipt's revenue), shipping charged, tax and the total paid. A synced
receipt carries the marketplace's numbers as they are; a manual one adds them up from its
lines (each with an optional discount) plus the shipping charged and tax you type in. Costs
are never typed in: what the goods cost is read from inventory. The customer is typed text, not a link
to the wholesale customer list: a name plus an optional customer
ID, the customer's identifier in whatever system the order came from. Both are optional, so
an anonymous consumer order is fine. A receipt can also be marked as a subscription sale
and as a recurring (repeat) customer. The two are separate axes, both describe the
individual sale, and both default to off; with the customer as typed text there is no
stable identity to derive repeat business from, so recurring is a manual toggle. It carries its own number,
SR-YYYY-NNNN, minted by a dedicated sales-receipt counter alongside the existing purchase, work, sales, and production counters (a synced receipt keeps the marketplace's own order number). Each line item is a product, a quantity that may be fractional, and a unit price you set. The unit cost is not locked on the receipt; it is read from inventory, so the receipt stays informational on cost. - Draw down finished-goods inventory. As the order advances it records what the customer wants (demand), what has been set aside for them (allocated), and what has actually shipped (consumed), all on the finished-goods ledger under its own sales-receipt source.
How it works
A sales receipt is always in exactly one status. A manual receipt moves by hand; a synced one follows the marketplace (paid, shipped, delivered, then completed once it is both delivered and settled: a Shopify order on its delivery day, an Amazon order when Amazon posts its fees). One chain carries the order from arrival to close, with an exit beside it. The sections below cover the chain, then what it does to inventory and to the dates.
The statuses
| Status | Type | What it means |
|---|---|---|
| Placed | Manual | The order has come in. Their ordered quantity is booked as demand. |
| Paid | Manual | Payment has been captured, and the stock is allocated to them. |
| Shipped | Manual | Goods have shipped and are on their way, and the stock is consumed. |
| Delivered | Manual | The order reached the buyer: a delivery scan, an Amazon order's must-arrive-by date, or 7 days after shipping. Nothing moves in inventory. |
| Completed | Endpoint | Closed: delivered and settled, so nothing more is coming. An Amazon order waits for its settlement (its fees), at most 30 days after shipping. |
| Cancelled | Exit | Cancelled before it ships (only from Placed or Paid), which reverses its inventory effects. Can be reactivated, returning to wherever it last was. |
The whole chain is set by hand and freely reversible to fix a mistake; the status is the only thing that moves inventory.
Moving between them
- By hand, both ways. The whole chain is yours to move along, forward or back. Stepping back from Shipped un-ships and removes the consumption, stepping back from Paid removes the allocation, and so on.
- Cancelling. Cancel an order before it ships to stop it and reverse its inventory effects; reactivate it to bring it back to where it last was. Once it is Shipped the order can no longer be cancelled, since the goods are already on their way.
- Deleting. A hard delete physically removes all of the receipt's ledger rows, matching the established behavior for purchase, work, and production orders.
Listing mappings
Connected receipts (Shopify, Amazon) arrive with the marketplace's own listing on each line. A listing maps to a Pharus product on the connection's settings page, by the listing's stable identity in its store, and from then on every stored line that carries that listing posts to inventory as that product, past orders included.
The mapping also carries units per listing: how many units of the product one unit of the listing sells. An "8-pack" listing of a single-unit product maps to that product with a factor of 8. The line keeps the marketplace's quantity and price, so revenue and line totals stay as sold, and only what reaches inventory is scaled: a line of 2 packs consumes 16 units. Changing the factor rewrites the line's ledger rows the same way changing the product does.
When is a multiple a product and when is it a factor? A multiple you physically stock, count and move (a master case on a pallet) is a product of its own, related to its base through the units of measurement model. A multiple that exists only as a listing, with nothing on the shelf to count, is a factor on the mapping.
Effect on inventory
| What you do | Ledger effect |
|---|---|
| The order comes in (Placed) | books the ordered quantity as demand |
| Mark it Paid | allocates the stock to the customer |
| Ship it (Shipped) | consumes the stock out of inventory |
| Cancel (before Shipped) | reverses the booked demand and allocation back to zero |
Projecting forward inventory effects requires a ship-from location to be set, and every entry carries the SR number as its reference. On a connected line the quantity posted is the line's quantity times its units per listing.
Amazon Multi-Channel Fulfillment orders are the exception. They are Amazon shipping its stock for a sale made somewhere else, so they sync as receipts marked MCF but are not sales: they earn no revenue, stay out of the reports, and never post to the ledger. When the order's seller reference names a Shopify order Pharus holds, the receipt links to it.
One rule keeps the ledger tidy: anything you undo is erased, not stamped with a counter entry. Step the order back out of Shipped and the consumption is simply removed. The only lasting reversal is a cancel, and even that disappears if you reactivate the order. The ledger always reflects only what is true right now.
Dates
- Order date is yours. It defaults to today when you create the order and you can change it whenever.
- Status dates (placed, paid, shipped, and so on) stamp themselves as the order reaches each status, but stay editable afterwards so you can correct them.
Each ledger entry takes its date from the status that produced it: the demand booking from the placed date, the allocation from the paid date, and the consumption from the shipped date. These are business dates, so editing one moves its entry with it. The record-of-entry timestamp never moves, so the stock history always reads in true business-date order, which is what positions and the cost model sort by.
Returns
Product coming back from a completed receipt is its own module: see Sales Returns.
See also
Drive sales receipts through the REST API or the MCP server.