Products Built

The Products screen is the catalogue of everything AIR sells: every law-book "Full Set" and its individual monthly parts. With the right permissions you can look products up, create and edit them on a tabbed screen, set prices, discount limits and delivery modes, see stock and change history, and duplicate, delete or restore them.

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

Filters

A New product button sits in the header (for holders of product.create). Each row offers Release for despatch, Edit, Delete, Restore (deleted rows only) and Duplicate. Each action checks its own permission, so you only see the actions you're allowed to use.

Fixing many products at once Built

Tick products in the list, then open the bulk-actions menu (needs product.edit):

• Set tax category — choose an active tax category (shown as "name · HSN code · rate %").
• Allow rate change / Lock rate — switch Allow rate change on or off.

Roll over to next year Built

Before a new subscription year, tick this year's products and choose Roll over to next year from the bulk-actions menu (needs product.create). The dialog asks for a Price change % (default 0; a negative number lowers the price) and New price effective from (default 1 January next year).

• Each product gets a copy for the following year with every setting, its active delivery modes and its own copy of the cover image. The year in the code and name moves on by one (ILRCHHT2027FS becomes ILRCHHT2028FS). A code without the year gets -2028 added.
• The copy is on the Next to be released timeline, its release dates are blank, and the two editions are linked both ways (earlier year / next year).
• The copy gets one price, labelled "2028 Annual", starting on the date you chose: the MRP in effect the day before, changed by your percentage and rounded to the paisa. The early-bird discount and cost price are copied. This year's prices aren't changed.
• Selecting a set rolls over all its parts too, placed under the new set with the same part numbers. A part ticked without its set is skipped.
• Products with no product year, or already rolled over (they have a next year product), are skipped. If one set can't be copied (for example, the new MRP would fall below the early-bird discount), nothing is created for that set and the rest still roll over.

A message tells you how many products were created; if any were skipped, it stays on screen and lists each one as CODE: reason.

Each product is saved as if you had edited it, so its History records the change and the same rules apply. A product that breaks a rule is skipped and the others are still saved. The notification then reads, for example, "4 products updated, 1 skipped" and lists each skipped product code with the reason. It stays on screen until you close it.

Import and export Built

Export (in the header, needs product.view) downloads the products that match your current filters and search as an Excel (.xlsx) or CSV file, one row per product. To export only some products, tick them and choose Export from the bulk-actions menu. The current_cost_price column is included only if you have product_price.view.

Import (in the header, needs both product.create and product.edit) reads a file in the same format, so the easiest way to edit many products is to export, change the file, and import it back. An export imported without changes changes nothing.

• Matching: each row is matched on code. An existing product is updated; a new code creates a product, which needs name, category_code and tax_category_code. A code that belongs to a deleted product is skipped: restore the product first.
• Columns: the first row holds the column names. Columns the import doesn't know are ignored. A column you leave out keeps its current value (or the usual default for a new product). An empty cell clears the value, except for fields that can't be empty (such as the yes/no settings, name, category and wave group), which keep their value.
• Values: yes/no settings take yes or no. Category, tax category, parent set and the earlier/next year products are given by code. A parent set or a year-chain product can be a row further down the same file. timeline is past, present or future; product_type is stockable or set.
• Prices: if current_mrp, current_ebd_discount or current_cost_price differs from today's price, the import starts a new price today and ends the old one yesterday. This needs product_price.manage; without it the price stays as it is, you get a warning, and the row's other changes are still saved.
• Checks: each row goes through the same rules as the product screen and is recorded in its History. A row that breaks a rule is skipped and the others are still saved. Tick Dry run to check a file and see what would happen without saving anything.
• Limits: up to 5,000 rows and 5 MB per file.

When the import finishes, a message reads, for example, "Import finished: 3 created, 40 updated, 200 unchanged, 2 skipped". Any problems stay on screen, one line per row: Row 7 ILR2027FS: The category_code 'X' was not found. The first 20 are listed.

The columns, in order: code, name, short_name, sms_short_name, category_code, product_type, format, language, group_code, product_year, billing_year, volume_number, part_number, parent_code, total_parts, frequency, isbn, issn, tax_category_code, timeline, is_active, permit_order_from_app, suspend_accepting_orders, allow_rate_change, allow_override_by_se, max_quantity_per_order_line, default_discount_pct, allow_party_discount, max_party_discount_pct, max_party_discount_amount, allow_ba_discount, max_ba_discount_pct, max_ba_discount_amount, allow_special_discount, max_special_discount_pct, max_special_discount_amount, max_overall_discount_pct, max_overall_discount_amount, min_payment_allocation, min_overall_payment_allocation, parts_on_credit_regular, parts_on_credit_extended, send_part_on_credit, send_strictly_against_payment, withhold_for_full_payment, released_for_despatch, despatch_wave_group, despatch_sort_order, delivery_priority, weight_grams, height_cm, width_cm, length_cm, closing_stock_reco_required, earlier_year_code, immediate_next_code, current_mrp, current_ebd_discount, current_cost_price, cover_image_url.

cover_image_url is export only: the link the field app uses to fetch the cover (opening it needs a signed-in API user with product.view). The import ignores it, so covers can't be set from a file; upload them on the product screen.

The product screen Built

Use New product (needs product.create) or a row's Edit (needs product.edit). The screen has a header that is always visible and eight tabs below it. The tab you're on is kept in the page address (?tab=…), so a reload or a shared link opens the same tab. The Save / Cancel buttons stay pinned at the bottom of the screen, and the browser warns you if you try to leave with unsaved changes.

Header

When a product can be ordered

A product is Orderable only when all of the following are true. The badge lists every one that fails.

• it is active;
• Suspend accepting sale orders is off;
• its timeline is not Earlier;
• it has a price in effect today;
• it has a tax category.

There is no approval step. A product becomes orderable as soon as these conditions hold.

Permit orders from SE app is separate: when it's off, the field app can't add the product to an order (online or through offline sync, the line is rejected with "CODE can't be ordered from the app."), but you can still order it from this console. It's checked when the line is added, so switching it off doesn't affect lines already taken.

The tabs

Saving

The product, its price rows and its delivery modes are saved together: either all of it is saved or none of it is. If a field has an error, a notification names the tabs to fix, for example "Fix 2 fields in Discounts & Credits and Base Prices". Rules that involve several fields are checked on every save, whether the change comes from this screen or from the field app / API. If one of these rules fails, a "The product wasn't saved" notification explains why. These rules cover:

• a Set has no format and needs total parts;
• a parent must be a Set, and a part number is required with a parent;
• a product can't be its own parent (or sit under its own part), or its own earlier/next-year product;
• the type can't change once the product has stock moves or order lines;
• the default party discount can't exceed the party Max %, and must be 0 when party discount isn't allowed;
• price periods can't overlap, and the early-bird discount can't exceed the MRP.

If someone else changed the product while you had it open (including adding a price or a delivery mode), Save writes nothing and shows "This product was changed by {name} at {time}. Reload to see their changes." The message stays until you close it. Reload the page, check their changes in History, then make your edit again. Your own saves and header actions don't trigger it. The field app / API gets the same protection: send the product's updated_at back as expected_updated_at on PUT /api/v1/products/{id}, and a stale value is refused with 409.

After you create a product, the screen opens it for editing. If you entered no price row, it opens on the Base Prices tab with a "Add a price before this product can be ordered." warning; otherwise it opens on Information.

Where the legacy (Odoo) fields went

If you're used to the old Odoo product form, this table shows where each field is now.

Base prices Built

A product has a dated price list, one row per period. You need product_price.view to see the Base Prices tab, and product_price.manage to change it. Without manage, the rows are read-only, and saving the product never touches its prices.

Add price fills in Effective from for you: the day after the latest row ends, or today. If the previous row is open-ended, it gets closed the day before the new one starts, so the periods don't overlap. A warning at the top reads "This product can't be ordered until it has a current price." whenever no row covers today.

Discount limits Built

For each of the party, BA and special discounts, a product has an Allow separate … discount toggle, a Max % and a Max ₹ per copy. There is also an overall Max % and Max ₹ per copy. Anyone with product.edit can change them. A blank limit means the product sets no limit.

Allow override by SE (Pricing group, default off): when on, the salesperson's own staff discount limits don't apply to this product. The product's limits still do, and going over them still needs HO discount approval. The product's lines also don't count towards the salesperson's overall discount limit for the order.

A hint appears when a Max ₹ per copy equals its Max % ("looks like the % was copied here"). This is common in legacy data.

Default party discount % (0–100) is filled in as the party discount on every new order line for this product. It's calculated on quantity × unit price. An explicit discount on the line (including zero) always wins. The default can't exceed the party Max %, and must be 0 when party discount isn't allowed.

Parts on credit Built

On a Set, Parts on credit (regular) and Parts on credit (extended) set how many unpaid parts of that set a customer may receive before paying. Leave a field blank for no limit; 0 means no unpaid parts at all. Products brought over from the old system with 0 in these fields arrive blank (no limit), because 0 was the old system's empty value. A customer gets the extended number when any of their customer categories has Extended parts credit switched on; everyone else gets the regular number.

The limit is applied when the nightly auto-reservation job reserves stock for a part. It counts the customer's parts of the same set that are already reserved or further along (picked, packed, shipped or delivered) and not covered by payment. If that count has reached the limit and the part being reserved isn't paid for either, the part is held with the reason parts_on_credit_limit and the customer gets an SMS and email. The hold clears on its own once payment covers the part (or the earlier parts), so nobody has to release it by hand. See Stock Moves.

Minimum payment allocation Built

Two percentages (0–100, default 0 = no minimum) hold back stock for this product until enough has been paid:

• Minimum payment allocation % per product: payment allocated to the order line must reach this % of the line's net value.
• Minimum payment allocation %: payment allocated to the whole order (all its lines) must reach this % of the order's net value.

Both are checked when the nightly auto-reservation job reserves stock. Until both are met, the product's moves on that order are held with the reason min_payment_allocation and the customer gets an SMS and email. The hold clears on its own the night after the payment is allocated. Cancelled and dishonoured payments don't count. Withhold for full set payment is checked first; this check comes before Send strictly against payment and the parts-on-credit limit. Order types don't carry their own minimum yet, so the product's percentage is the only one applied. See Stock Moves → Why a move is held.

Price lock and quantity cap

• Allow rate change (default off): when off, an order line's unit price must equal the product's MRP on the order date. Otherwise the line is rejected with "The price for CODE is fixed at ₹…". Users with sale_order.approve (and super administrators) can still change the price. Leaving the price out always uses the MRP.
• Maximum quantity per order line (Information tab): a larger quantity is rejected with "Quantity for CODE can't exceed N per order line." Leave it blank for no limit.

See Sale Orders → Order lines for how these rules apply when an order is entered.

Delivery modes Built

The Delivery Modes tab lists the product's permitted delivery modes. Each row has a Mode of delivery (active carriers), Postage ₹ / copy (reference only — postage is calculated from package weight and carrier rate cards, see Packages), Valid from, Valid up to (order entry), Box type and Active. You can't add the same carrier twice with the same Valid from date. Reorder rows with the up/down buttons: the order is the preference order, and the first active row shows a Default badge.

• No active rows: order lines can use any carrier.
• At least one active row: an order line can only use a mode that is active and valid on the order date. Offline orders that sync later are checked against the date they were taken. If the line doesn't name a carrier, the first permitted mode is filled in. If every active row is out of date on that day, nothing is permitted, and the line is rejected instead of falling back to "any carrier".

Despatch & packaging on the same tab:

History Built

The History tab lists every change to the product, newest first. Each entry shows an action badge (Created / Updated / Deleted / Restored), who made the change ("System" when nobody was signed in) and when. A Field · Before · After table uses the same labels as the form. Changes to price rows and delivery modes appear here too, with a note naming the row (for example the price's label). A cover image change shows as Cover image with After reading "added", "replaced" or "removed". Related records are shown by name instead of by number: category, tax category, parent set, earlier/next-year product (by code), delivery carrier and box type. Cost price changes are hidden if you don't hold product_price.view. The tab shows 25 entries; Load more adds another 25. History starts from the day this feature went live; older Odoo changes aren't imported.

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

Duplicate (row action and edit-screen header, needs product.duplicate) is a quick way to create a closely related product, usually next year's edition. The dialog asks for a New code (pre-filled as CODE-copy, made unique if needed) and a New name. You can also give a Product year and switch on Link as next year. That sets the copy's earlier year product to the original and, if the original has no next product yet, points the original's next product at the copy.

The copy takes every setting from the original, including discount limits, rate change, quantity cap and wave group. It also gets the current price row (re-dated to start today, open-ended) all active delivery modes and a copy of the cover image (a separate file, so changing or removing one cover doesn't affect the other). The original isn't changed, apart from the optional year link. The copy then opens on its AIR Info tab.

Deleting and restoring Built

Delete (needs product.delete) is refused while the product has stock on hand or unfinished stock moves. You'll see "Cannot deactivate a product that has stock on hand or active stock moves." Otherwise the product's timeline is set to Earlier and the product is hidden from the list, but its history is kept. To bring it back, switch on the Deleted records filter and use Restore (also needs product.delete). You can also open the deleted product and restore it from its header. If you just want to stop sales, it's often simpler to switch Active off. Deleting keeps the product's cover image, so a restored product still has it.

Release for despatch Built

This action (on the Products list and in the edit screen's header) 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.

Releasing also switches the product's Released for despatch? setting on (Delivery Modes tab), because the nightly reservation skips products where it's off. If you release from the edit screen, the toggle updates on the form straight away.

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.

1. 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.

2. 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.

3. Select Release for despatch

   Only visible on rows where the product is active and you hold stock_move.create.

4. 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.

5. 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.