Issue a sales order

Learn how to issue a sales order in OpenMRP.

To issue a sales order in OpenMRP, you need to have created a sales order estimate.

What is issuing a sales order?

In OpenMRP, issuing a sales order means moving it from a draft/estimate state into an active fulfillment state. When you issue, OpenMRP allocates inventory for the order. If OpenMRP does not currently show enough inventory, the order can still be issued. This avoids blocking operations when real-world inventory and OpenMRP inventory are temporarily out of sync, and it supports partial shipments immediately.

What happens when you click Issue?

  • changes the order's status from estimate to issued and sets the Issued At timestamp for traceability
  • creates a Pick for warehouse work, with one pick line for every sale-type product line — freight and discount lines are never picked
  • creates and reserves inventory issues for each line that is tied to an inventory item
  • optionally sends an order acknowledgement email

Only an order still in estimate can be issued; issuing anything else is rejected. Over the API this is PUT /v1/sales/sales-orders/{id}/actions/issue — see Issue Sales OrderAPI.

The acknowledgement email is opt-in per issue: the UI asks whether to email the customer, and the API takes a notify_customer flag. When it is on, an acknowledgement with a PDF of the order goes to the order's acknowledgement contacts and the order's acknowledgment_status becomes sent. An order with no acknowledgement contacts sends nothing and keeps its current acknowledgment status, so set those contacts when you create the order if you want the email.

So practically, ”Issue” means to commit this order to operations (start picking & inventory allocation).

What issuing does not do

Issuing a sales order does not automatically create a Production Run. Production Run generation is a separate action, and the dashboard flow puts it before issuing — while the order is still an estimate. The action itself is not gated on status; what it does reject is an order that already has a production run, since an order can have at most one.

Before you issue (recommended checks)

  • confirm the correct customer and shipping destination
  • review line quantities and pricing
  • confirm payment and shipping terms
  • verify acknowledgement/invoice contacts if you plan to send email
  • if terms are prepaid, collect payment before issuing

Related behavior

  • If customer payment terms are Prepaid, the dashboard warns you to collect payment before issuing. It is a confirmation prompt, not a block — you can proceed.
  • If a customer is on hold all or hold shipment, the dashboard disables the Issue button and shows a credit-hold banner until the hold is removed.

Unissuing a sales order

Unissue reverses issue behavior:

  • the order status returns to estimate and the Issued At timestamp is cleared
  • the associated pick is deleted, discarding any picking progress recorded against it
  • the reserved inventory is released

Only an order in issued can be unissued. Over the API this is PUT /v1/sales/sales-orders/{id}/actions/unissue — see Unissue Sales OrderAPI.

Be aware that unissue is not the only way an order falls back to estimate: deleting the last remaining line of an issued order performs the same teardown as a side effect. See Picking.

Closing and reopening

Issuing is the first of four status actions. Once fulfillment is done, close moves the order from issued to fulfilled, stamping its completion timestamp and closing its pick. Reopen moves a fulfilled order back to issued to make corrections, clearing the completion timestamp and reopening any pick line that is not yet fully picked. The full status model is described in Sales orders.

Next steps

Next: Territories