Products Built
The Products screen is the catalogue of everything AIR sells — every law-book "Full Set" and its individual monthly parts. You can look products up, filter and sort them, and — with the right permissions — create, edit, price, duplicate and deactivate them here.
What a "product" is at AIR
AIR sells law-report subscriptions as a Full Set — twelve monthly parts published across the year. In the catalogue, a Full Set and each of its parts are both products, distinguished by the product_type column: a Set groups the subscription as a whole, while Stockable products are the individual physical parts held and despatched from a warehouse.
Columns
| Column | Shows |
|---|---|
code | The product's short code, shown as a badge. Searchable and sortable. |
name | The product's full name (for example a law report's title, or a specific monthly part). Searchable. |
category.name | The product's category, labelled Category on screen. |
product_type | A badge showing Stockable (an individual physical part that occupies warehouse stock) or Set (the Full Set subscription grouping). |
currentPrice.mrp | Labelled MRP on screen. The product's current maximum retail price, read from its active price record and formatted as ₹ (->money('INR')). |
product_on_timeline | A coloured badge telling you where this product sits on its publishing timeline: Past (already published/superseded), Present (current), or Future (upcoming). Anything the console can't classify falls back to Past's grey styling. |
is_active | A tick/cross icon showing whether the product is active and sellable. |
Filters
| Filter | What it narrows |
|---|---|
| Product type | A drop-down over product_type — restrict the list to Stockable or Set products only. |
| Category | A drop-down listing every product category (via the category relationship) — restrict the list to one category. |
| Active | A three-way toggle (Active / Inactive / Either) over is_active. |
The Search box matches against code and name. A New product button sits in the header (for holders of product.create), and each row offers Edit, Duplicate, Delete and Release for despatch — each gated on its own permission, so you only ever see the actions you're allowed to use.
Creating & editing a product Built
Use New product (needs product.create) or a row's Edit (needs product.edit). Because a product carries a lot of information, the form is split into five sections:
| Section | What it holds |
|---|---|
| Identity | Name, short name, the unique code, its category, product type (Stockable or Set), format, language, group code, and the active toggle. |
| Bibliographic | Publication year, volume / part number, frequency, total parts, ISBN / ISSN, and the tax category. |
| Hierarchy & timeline | Where the product sits on the past / present / future timeline, its parent (for parts of a set), and the links to the earlier-year and next products in a series. |
| Despatch & physical | Despatch sort order and delivery priority, weight and dimensions, whether to consider it for despatch, and the scheduled-despatch / first-ready dates. |
| Order & credit policy | Minimum payment-allocation thresholds, the Default discount % (see below), and the policy toggles — sold-as-loose-part, send-on-credit, send-strictly-against-payment, withhold-for-full-payment, suspend-accepting-orders, closing-stock-reconciliation-required, permit-order-from-app — plus the release date. |
A product can carry a Default discount % (0–100). When a new order line is added for that product, this percentage is applied automatically as the line's party discount (calculated on quantity × unit price). It's just a default — the Sales Executive / field app can override the discount on the line, and passing an explicit discount (including zero) always wins. Products left at 0% behave exactly as before. Because it lands in the party-discount bucket, a large default that exceeds an SE's discount authority will still route the order through the normal discount-approval workflow.
Each product's code must be unique across the catalogue — the form rejects a duplicate before saving. Everything else follows the usual rules (name, code, category and type are required). The person who creates a product is recorded automatically.
Prices (pricelist) Built
Open a product for editing and you'll find a Pricelist (prices) tab (visible to holders of product_price.manage) — this is the product's price list. Each product keeps a dated price list: one row per price, with an Effective from date, an optional Effective to, the MRP and Cost price, and an optional label. Add, edit and remove prices right there on the tab. The current MRP also shows in the products list's MRP column.
Delivery / carrier preferences Built
On the product's edit screen there's now a Delivery / carrier preferences tab (view needs product.view; add/edit/remove needs product.edit) — this is where you map which delivery carriers a product should go out with. Each row picks a Carrier, an optional Box type, a Preference order (lower = tried first), an optional Postage per copy, an optional validity window (Valid from / Valid to), and an active toggle.
Categories & tax categories Built
The Inventory navigation now has Product Categories and Tax Categories screens so you can create and edit these yourself (previously they could only be seeded). Both are gated by the product permissions: viewing needs product.view, creating product.create, editing product.edit, deleting product.delete.
- Product Categories — name, code, an optional Parent category (they nest; a category can't be its own parent), a sort order and an active flag.
- Tax Categories — code, name, the HSN / SAC code (required, up to 8 characters), the GST rate %, an optional description and an active flag. These are what the Tax category field on a product points at.
Duplicating a product Built
The Duplicate row action (needs product.duplicate) is a shortcut for creating a closely-related product — typically the next year's edition. It copies the source product's settings, asks you for a new unique code and name, and saves a fresh product. It does not copy the price list (a new edition starts with its own prices) and leaves the original untouched.
Deleting a product Built
The Delete action (needs product.delete) removes a product. In most cases you'll prefer to switch its Active toggle off instead — that takes it out of ordering and despatch while keeping all its history intact.
Release for despatch Built
This is the single row action on the Products list, and it is the starting point of the whole despatch pipeline: it is what actually creates the stock moves that everything downstream — reservation, picking waves, packages — depends on. Nothing else in the system creates these moves in bulk.
What it does
Selecting Release for despatch looks at every eligible sale-order line for that product — a line where the parent order is ApprovedForDespatch or InDespatch and that doesn't already have a stock move. It shows you a confirmation dialog previewing how many moves across how many distinct orders it is about to create ("This will create ~N move(s) across M order(s)."), before anything happens. Confirming does not create the moves there and then — it queues a background job to create them, so releasing a product with thousands of eligible lines doesn't tie up your screen.
Because eligibility excludes lines that already have a move, releasing the same product a second time only ever picks up lines that arrived (or failed to get a move) since the last release — it is safe to click again.
Once the queued job runs, it creates one Confirmed delivery stock move per eligible line, and — the first time it touches an order that is still ApprovedForDespatch — moves that order on to InDespatch. From there, the moves are picked up the same night by the air:auto-reserve scheduler, and the following hour by air:auto-wave. See Stock on Hand for how a reserved move shows up as qty_reserved, and Background Schedulers for the full daily chain.
- Configure the despatch source location, once
Before the first release, an administrator must set despatch.default_source_location_id in System Configuration — the warehouse location moves will ship from. There is no guessed default: if it's left unset, releasing any product fails with "Configure the default despatch source location first." The destination side, despatch.customer_location_id, is a system "Customer" sink location that is seeded automatically — you shouldn't normally need to touch it.
- Find the product
On the Products list, locate the active product whose approved orders are ready to move. There is nothing on this screen that tells you how many lines are eligible before you open the action — that count only appears in the confirmation dialog in the next step.
- Select Release for despatch
Only visible on rows where the product is active and you hold stock_move.create.
- Review the preview and confirm
The dialog states how many moves across how many orders will be created. Confirm to queue the job, or dismiss to do nothing.
- Check the result
A Release queued success notification appears immediately — the moves themselves are created moments later by the background job. If the source location isn't configured, you instead see a Cannot release for despatch error notification with the reason.
Related pages
- Stock on Hand — how much of each stockable product you currently hold, by warehouse location, and where a released move's reservation becomes visible.
- Closing Stock — the physical stock-count workflow that reconciles what's on the shelf against what the system believes is there.
- Warehouses — the locations stock is held in.
- System Configuration — where the despatch source location is configured before you can release anything.
- Background Schedulers — what happens to a released product's moves next: reservation, then wave creation.