Conversions

A conversion turns finished goods that already exist into another form of the same product at one location: cases broken back into eaches, product moved from the wrong pouch into the right one. It consumes one input product, receives one output product, and consumes the replacement packaging the output needs. It is not part of production: it corrects an earlier decision, and every conversion destroys some of the packaging the goods came in, which is the cost of that correction. Since v1.23.0 it moves through stages, so a conversion sent to a co-packer can be tracked while it is away.

What it does

• One input, one output, on the spot. A conversion holds one location, one input line (a product and a quantity), and one output line: a product from the input's family, meaning the same product, its base product, or a case that packs the same base. The output's quantity is never typed; it's derived from the input quantity through the case factors that relate the two products, and an eaches-to-cases conversion must divide evenly or it's rejected. It has no reason field, and it checks nothing against stock on hand: it records what happens. A conversion opens under a server-assigned code (CNV-001, CNV-002, and so on) that is not editable, similar to transfer codes.
• Fill in the packaging for you. Repackaging a product almost always uses up some packaging and frees some other packaging. A conversion works this out from the input's and output's bills of materials, deriving the consumed materials the output needs beyond what the input already carried. You can add extra units on top of that, but only of materials that belong to the output's bill of materials, a fresh pouch for a repouch being the standard case.

How it works

A conversion moves through the stages a work order moves through, because Anthem's real conversions go out to a co-packer and come back over days: Planning (the instruction exists), Placed (handed to the co-packer), Production (work underway), Partial (some output is back), Received (all of it is back), Completed (invoiced and paid). Cancelled is the exit before goods move: reachable from Planning, Placed or Production, and reactivating to any of them. Planning, Placed and Production move freely among themselves; Received steps back or on to Completed; Completed steps back to Received. Partial is reached by receiving, never chosen by hand.

Each stage owns a date, stamped when the stage is reached and editable afterwards, kept in lifecycle order. The conversion date stays as the document's business date; it no longer dates any ledger row, the stage dates do.

What each stage posts

Stage	Output	Input product	Materials
Planning	nothing	nothing	nothing
Placed	ORDER	ALLOCATE	DEMAND
Production			ALLOCATE
each reception	RECEIVE	CONSUME	CONSUME
Received	SETTLE_ORDER	SETTLE_ALLOCATE	SETTLE_ALLOCATE
Completed	nothing	nothing	nothing
Cancelled	REVERSE_ORDER	REVERSE_ALLOCATE	REVERSE_DEMAND, REVERSE_ALLOCATE

• The output is on order from Placed, so a short week reads as "enough is coming".
• The input is reserved, never demanded: it exists, nothing has to be sourced. ALLOCATE takes it out of available the moment it is handed over.
• The materials are demanded, then reserved: boxes not on the shelf must be bought, so they are a need from Placed and a reservation once work starts. Demand nets against allocation, so the need disappears once reserved. Cases to eaches consume no materials and post no DEMAND at all.
• Each reception moves the stock it brought back: the input units it used up are consumed, the output received, every consumed material consumed in proportion, all at the conversion's location on the reception's date. Received is the manual close: whatever was over or under against the plan is settled.
• Cancelled reverses every commitment still open; from Planning there is nothing to reverse. A conversion whose goods have moved cannot cancel: step it back first.
• A document already in Received or Completed never opens a new commitment. The conversions recorded before the lifecycle existed were marked Completed as they stood, and their positions were settled so a consume without a reservation before it no longer drives the input's allocated figure negative.

Every row carries the conversion's code as its reference, so its entries are easy to find together. Nothing checks stock on hand before consuming it: the ledger goes negative if it must, exactly as a transfer or a disposal does today.

Receptions

A reception records how much of the output came back and on what day: a date, a quantity of output, and optionally a lot number, an expiration date and a note. A conversion has exactly one output, so a reception is one line.

The quantity must use up whole units of the input, so every reception moves real cases and real boxes, never fractions of them. The two products fix a step, the smallest quantity of output that does that, and a reception is a whole multiple of it: cases of 12 to eaches, 12 eaches (one case opened); eaches to cases, one case; cases of 8 to cases of 12, two cases of 12 (three cases of 8, the whole conversion); the same product repouched, one unit. The form says the step and refuses anything else; the remaining quantity is always a multiple as well.

• Receiving is allowed from Production, Partial and Received. Receiving against a Received conversion reopens it to Partial and undoes the settle. It is refused from Planning, Placed, Completed and Cancelled.
• The first reception moves the conversion to Partial and its date becomes the Partial date (the earliest reception); deleting the last one walks it back to Production. Received is never derived from the quantities: it is the person saying "we have all of it", and reaching it settles whatever is over or under.
• Over-receipt is allowed, in steps. Received settles the difference.
• Each reception owns the rows it wrote. Editing it rescales them; changing its date moves them; deleting it removes them. The conversion's received date dates only the settle.
• A conversion created straight in Received or Completed is the record of a repack already done: it gets one reception for its full output on the received date.

What locks when

The location is editable only in Planning: from Placed on, the commitments sit at it. The input, the output and the extra materials are editable until a reception exists: from then on the stock has started to move against them, so delete the receptions to change them. A Completed conversion locks its receptions: reopen it first. The conversion date and the notes are editable in any status. A conversion with receptions cannot be deleted; delete the receptions first, and the conversion goes with every row it wrote. Undo is delete.

Consumed materials and waste

A conversion's line table holds three roles: the input line (the one product consumed), the output line (the one product received), and the consumed lines, the materials the output's recipe adds (often packaging, but any material), each either derived or added as an extra.

The consumed lines start out derived: Pharus explodes the input's and the output's products down through their bills of materials to the raw materials underneath (a component that is itself a product recurses into its own bill of materials), and whatever the output needs beyond what the input already carried becomes a derived line, shown read-only. A case converting to its base, and a product converting to itself, both derive nothing, so a straight repouch is expressed purely through extras.

On top of the derived lines, you can add extra units of any material on the output's exploded bill of materials, a fresh pouch for a repouch being the standard case; a material outside that bill of materials is rejected. Derivation reruns whenever the input or output changes and replaces the derived lines outright. An extra survives that rerun unless the new output's bill of materials no longer carries its material, in which case the extra is dropped along with it.

Waste isn't stored: it's computed on read, from the same explosion, as whatever the input carried that the output doesn't keep, plus every extra unit added, since an extra pouch means the old one was wasted. It's shown on the document in units, and valued as the loss described below.

Loss

What a conversion throws away is a loss, not part of the output. Waste exists only where the bills of materials differ, and where it exists its cost is known: an input with a bill of materials was built from those materials on a work order or a production order, and that order's consumed lines carry the unit cost of everything that went into it.

The loss is read from the reception the input came from. Costing a reception's input consume gives the received layers it drew from, how many units from each; each layer's origin is the row that put those units on the shelf, preserved across transfers, whose source is the receipt line of the order that built them; that order's consumed lines, costed, give the wasted material's unit cost and how much of it went into each produced unit. The waste per input unit, times the units drawn, at that cost, is the loss. A material the build consumed inside a component product (the pouch inside an each, built on the each's own order) is found one level down by the same walk.

An input that was not built in Pharus, bought on a purchase order or adjusted into stock, has no consumed lines to read: it books no loss, and its whole value stays in the output. That is the honesty line: a loss is only ever booked where Pharus knows what the wasted piece cost.

The loss is a value, never a quantity row: the box is not on the materials ledger when the case is broken, so a disposal would remove a box that is not there. It is computed on read, shown per reception and summed on the conversion, per material with the quantity, the unit cost and the value.

Costing

Inputs and consumed materials are ordinary outflows: they draw down real cost layers the same way any other CONSUME does. Each reception's RECEIVE then costs what that reception took off the shelf, the value its input consume drew plus the value of every material it consumed, minus the loss it booked, divided by the units it received, plus the conversion cost per unit. The input's value is split the way it was built: the parts the output keeps flow into it, the part it throws away is the loss. It never reads the output product's own pool, which at the moment a conversion fills it is usually empty and always the wrong format.

The conversion cost is the cost of converting one unit of output, the co-packer's fee or the labor spent, typed on the conversion and zero by default. Every reception snapshots the value in force when it is recorded, so a later edit applies to later receptions only and history does not move; a reception's own figure can be edited in place, and the engine reads it live. It is capitalized into the output the way a work order line's conversion cost is. Freight to and from the co-packer belongs to the transfers around the conversion, not to the conversion itself.

Take a case built on a work order from 12 eaches at 2.00, a 1.50 box, two tape at 0.25 and 0.50 of labor: 26.50. Breaking two of them into 24 eaches consumes 53.00; the two boxes and four tape they wore are the loss, 4.00, valued from that work order; the eaches receive at (53.00 minus 4.00) over 24, 2.04, the labor staying in because there is no honest way to take it back out. Had the cases been bought rather than built, no loss would be booked and the eaches would receive at 27.00 over 12. Packing up works from the other side: 12 eaches at 2.00 plus a 1.50 box and 0.50 of tape make one case worth 26.00, and nothing is wasted.

What still goes untracked is the labor priced into the input: it was spent building the case and there is no honest way to take it back out, so it stays in the output.

See also

Create, update, and delete conversions through the REST API or the MCP server. See Inventory Transfers for the sibling module that moves stock between locations rather than between packaging levels.