Prerequisites

• base module installed (it owns the basepartner and basesequence models the scope extends).
• Vendor partner type exists as base.base_partner_type_vendor. It ships with base — check it is present before first use.
• User has Purchase / Vendor Management access. Administrators can assign this from the user form.

Install & bootstrap

How the install wires up

• __hmx__.py declares dependency on base and loads, in order: security/security.xml → security/base.model.access.csv → data/vendor_sequence_data.xml → the three view XMLs.
• vendor_sequence_data.xml creates the basesequence record with code=purchase.vendor, consumed at create-time by BasePartner._generate_vendor_id.
• Menu tree: menu_core_purchase_root → menu_purchase_vendor_sub → action purchase_vendor_action (domain: [('is_vendor','=',True)]).

What is a Vendor?

A Vendor in HMX is any Partner with the Vendor type turned on. The same Partner record can also be a Customer — the two flags are independent. The Vendor list shown under Purchase → Vendor → Vendors is simply all Partners filtered by is_vendor = True.

When a Partner becomes a Vendor for the first time, the system automatically stamps two fields: Vendor Code (from the purchase.vendor sequence) and Vendor Created On (the exact UTC timestamp). Both are locked after creation — they cannot be edited by users or even by most code paths.

How to create your first vendor

Vendor Code rules explained

How the vendor flag is computed

is_vendor is a stored computed field depending on partner_types. _compute_is_vendor resolves the vendor type reference once per batch and sets rec.is_vendor = vendor_type_id in rec.partner_types.ids. The helper also handles new records where partner_types are still _origin references.

Create flow (BasePartner.create)

1. If is_vendor is requested but partner_types not supplied, the override injects the Vendor type automatically (6,0,[vendor_type_id]).
2. Calls super().create.
3. For every created record that qualifies as a vendor (_is_vendor()), it calls super().write with an internal context (skip_vendor_lock=False equivalent) to stamp vendor_code and vendor_creation_time — bypassing its own write guard because the values are missing.

Write flow (BasePartner.write)

1. Rejects any attempt to write vendor_code or vendor_creation_time unless skip_vendor_lock is set in context.
2. If partner_types is being modified, simulates the resulting set (handles 6/4/3 commands), and if the record transitions from non-vendor → vendor, it stamps the code & timestamp as part of the same write.

What is a Vendor Category?

A freeform label you create to group vendors — Raw Material, Logistics, Services, IT Hardware. Categories are multi-company aware: if you assign a category to HQ only, users working in a subsidiary won't see it.

Note: in the current module the category is a master list — it is not yet attached as a tag on the Vendor form. Use it as a reference master that your custom fields, reports, or analytics can filter against.

How to create a vendor category

Company scoping rules

How the company filter is enforced

Two layers:

1. search_read is overridden to extend the domain with ['|',('companies','in',allowed_ids),('companies','=',False)].
2. fields_view_get rewrites the Companies field's domain via lxml, so the form picker only suggests allowed companies.

Both rely on selected_company() which prefers env.companies.ids (active switcher set), falling back to the user's assigned companies.

Status today

Bridging the gap today

If you need an end-to-end procurement trail now, the pragmatic workflow is:

1. Create the Vendor in Purchase → Vendor → Vendors.
2. Capture procurement decisions offline (email, spreadsheet, shared doc) — the RFQ & PO modules aren't live yet.
3. When the goods arrive, record an Inventory receipt against the right product/warehouse using the Inventory module.
4. When the invoice arrives, open Accounting → Documents → New, pick the journal with source type vendor bill, attach lines against the vendor's Account Payable.
5. Register payment on that document — exactly the same flow as regular customer receipts, just reversed direction.

Modules in the Purchase scope

Key data models

basepartner — vendor fields

Extension hooks (BasePartner)

• _get_vendor_type() — resolves base.base_partner_type_vendor. Override if you use a custom vendor type ref.
• _is_vendor() — returns True iff the vendor type id is in partner_types.ids.
• _generate_vendor_id() — wraps basesequence.next_by_code("purchase.vendor"). Raises ValidationError if the sequence is missing.
• @api.depends("partner_types") _compute_is_vendor — recomputes stored flag on any partner_types change.
• create / write — stamp + lock vendor_code / vendor_creation_time. Use context skip_vendor_lock=True to bypass (admin tools only).

Extension hooks (PurchaseVendorCategory)

• selected_company() — prefers env.companies.ids, falls back to env.user.companies.ids. Override to widen/narrow visibility.
• fields_view_get — rewrites the companies field's domain on the form to allowed ids. Override if adding more scoped fields.
• search_read — extends domain to match records with at least one allowed company (or none set). This is the authoritative company gate for category listings.

Views, actions, menu tree

API endpoints

No Ninja API endpoints are defined in core_purchase today. Vendor and Vendor Category records are reached via the generic HMX data APIs.