Prerequisites

• base module installed (provides the group model the roles inherit).
• Administrator access to the Settings → Users & Companies → Users screen so you can assign roles.
• A clear idea of who in your organisation should be Manager vs Supervisor vs User — see the Inventory Roles chapter for guidance.

Install & assign roles

How the install wires up

• __hmx__.py declares depends: [] (empty) and loads only security/inventory_groups.xml on install.
• inventory_groups.xml creates three group records: inventory_group_manager, inventory_group_supervisor, inventory_group_user.
• base.model.access.csv ships a placeholder ACL (access_yourmodel_all) wired to base.group_user — replace this when the real stock models land.

The three-tier model

Inventory work is hierarchical: operators handle daily moves, supervisors reconcile and approve, managers set policy and absorb exceptions. Pick one role per user; do not stack them — the higher role is meant to inherit the lower's capabilities.

Picking the right role

Group records

<record id="inventory_group_manager" model="group">
    <field name="name">Inventory Manager</field>
</record>
<record id="inventory_group_supervisor" model="group">
    <field name="name">Inventory Supervisor</field>
</record>
<record id="inventory_group_user" model="group">
    <field name="name">Inventory User</field>
</record>

External XML IDs to reference in your own ACLs or rule records: core_inventory.inventory_group_manager, core_inventory.inventory_group_supervisor, core_inventory.inventory_group_user.

core_inventory_accounting → Accounting scope

Stock valuation (perpetual COGS posting, receipt/delivery/transfer/adjustment journal entries) is implemented in core_inventory_accounting. It is documented under the Accounting scope, in the Inventory Accounting chapter — go there for valuation methods, account configuration, and the entry-per-movement table.

core_purchase → Purchase scope

Receipts originate from purchases. Vendor master and (future) PO/RFQ/Goods Receipt are tracked in the Purchase scope. The receipt step in the supply-chain flow above is owned there — when those modules ship, they will trigger inventory moves on confirmation.

sale → Sales scope

Deliveries are driven by Sales Orders. The Sales scope owns the order side of the chain; outbound stock moves will be triggered from there once the corresponding inventory delivery models land.

manuf → Manufacturing scope

Manufacturing consumes raw materials and produces finished goods — both are inventory operations. The manufacturing flow (BoMs, Work Orders, Production Records) is fully documented in its own scope; expect tight integration once the operational inventory modules ship.

1. Goods Receipt (inbound)

When a vendor delivery arrives, the warehouse creates a Goods Receipt to bring product into stock. In the planned design, receipts will be auto-suggested from confirmed Purchase Orders, with picking-list style validation for each line.

2. Pick & Pack (outbound)

For each customer shipment, a Delivery Order will be generated from a confirmed Sales Order. Operators pick from designated locations and pack for shipment.

3. Internal Transfer

Transfers between warehouses or locations (e.g. from raw-material store to production floor) keep stock accurate without touching valuation.

4. Stock Adjustment

When physical count doesn't match the system, a Stock Adjustment corrects on-hand and books the gain/loss to inventory accounting.

5. Cycle Count

A rolling cycle count verifies inventory accuracy without pausing operations — typically one zone or ABC class per day.

Expected technical model (when modules ship)

The shipping design anticipates these models in future modules that will depend on core_inventory:

What works today

• Valuation — core_inventory_accounting already posts COGS and receipt JEs. Configure it under the Accounting scope.
• Product master — core_product holds the stockable items catalogue. Document under the Product scope.
• Manufacturing moves — if your operation is production-heavy, the manuf module already tracks BoM consumption and finished-goods output (visible on the Manufacturing scope).
• Roles in place — assign Inventory Manager/Supervisor/User now; the upcoming operational modules will pick up exactly these groups without re-provisioning.

Gaps & recommended workarounds

Get ready for the migration

1. Keep a consistent location code format in your spreadsheet (e.g. WH/Stock/A1-03) — easier to import later.
2. Assign the Inventory Manager role now to the person(s) who will configure warehouses when the module ships.
3. Document your current valuation method (FIFO / Weighted Avg / Standard) so core_inventory_accounting setup stays aligned.
4. Track discrepancy history — even in a spreadsheet. When adjustments shipping, historical trends will inform cycle-count priorities.

Capability status

Module manifest (__hmx__.py)

{
    "name": "Core_Inventory",
    "category": "Core_Inventory Category",
    "version": "1.0.0",
    "description": "Core_Inventory Description",
    "author": "Hashmicro",
    "data": [
        "security/inventory_groups.xml",
    ],
    "depends": [],
}

depends is intentionally empty. The module ships a permission baseline that future stock modules will extend, not redefine.

Security groups

ACL skeleton (placeholder)

id,name,model:id,group:id,perm_read,perm_write,perm_create,perm_unlink
access_yourmodel_all,Access Your Model All,model_yourmodel,base.group_user,1,1,1,1

Source files