Assets

Assets is a tenant-scoped domain split into three related surfaces:

• Products are reusable catalog definitions owned by an organization. Product detail uses Overview, Inventory, and Suppliers tabs. The Products hub also has Overview, Inventory, and Suppliers, where hub Suppliers is the organization supplier master list.
• Inventory is product stock shown inside Products tabs, with each row representing a stock record at a location, bin, lot, or serial.
• Customer assets are specific installed, assigned, or maintained items owned by customers.

This split avoids a single overloaded assets.mode table. Shared product facts live on products; current stock state lives on inventory_stock_records; stock change history lives on inventory_movements; serial, assignment, and service lifecycle facts live on customer_assets.

Core Tables

Field Ownership Rules

• Product-owned: name, description, brand, model, SKU, EAN, default prices, VAT percentage, explicit categories, tags, product images, and supplier ordering details.
• Supplier-owned: identity/status, correspondence address, ordering/billing emails, payment terms, default lead time, preferred receive location, and optional source/external_id join keys. API credentials are never stored on suppliers.
• Product–supplier link-owned: overrides for ordering (supplier SKU, order code, unit cost, MOQ, order multiple, lead time, preferred/active, external catalog product id). Link lead time overrides the supplier default when set. A product may have many suppliers; at most one link is preferred and is the default order target.
• Inventory-owned: product reference, stock location, on-hand quantity, reserved quantity, derived available quantity, reorder point, lot or batch identifiers, stock serial number, expiration, inventory status, and movement history.
• Inventory movement optional refs: supplier_id and free-text reference_number (PO/ASN/delivery note) prepare purchase receipts and returns until purchase-order documents exist.
• Customer asset-owned: product reference, customer assignment, customer location, serial number, asset tag, barcode, install date, warranty expiration, condition, lifecycle status, service notes, purchase date/price/currency, and optional purchase quote and invoice references. Those documents must belong to the same customer. Quote-level quote_assets links remain a separate many-to-many for quotes that cover installed equipment.

Historical documents and future work orders should snapshot commercial and assignment details at creation time rather than re-reading mutable product or customer asset rows on every render.

Shared Catalog And Supplier Data

Products stay tenant-owned in v1. This is deliberate: organizations need their own names, pricing, VAT settings, supplier choices, images, and local overrides.

Product categories are tenant-owned and hierarchical through product_categories.parent_id. Products attach to categories through product_category_assignments, so assigning a product to a parent category never implicitly assigns it to subcategories. Filtering follows the same explicit rule: a parent filter matches only products directly assigned to that parent.

Future supplier API integration should follow the Google Calendar pattern, not Stripe Payments: a marketplace integration_definitions row per vendor, credentials and sync state in catalog-owned supplier_connections (or Vercel Connect), and an integration_installations row with domain_kind = supplier_connection. Tenant suppliers.source / suppliers.external_id point at that connection. product_supplier_links.external_id is the remote catalog product id. Do not store API credentials on suppliers, and do not make tenant product rows globally shared.

When a vendor lands, sync should import catalog records and propose or create product_supplier_links. Ordering (task material shortfall and later inventory reorder) should create a purchase request through the preferred link’s connection, falling back to mailto or the supplier page when no connection exists. Receiving stock later uses inventory_movements.purchase_receipt plus supplier_id / reference_number until dedicated purchase-order tables exist.

Permissions And RLS

Permissions introduced with this slice:

• organization.assets.view
• organization.assets.create
• organization.assets.update
• organization.assets.delete

They live in packages/identity/src/rbac/permissions.ts and are seeded through supabase/schemas/055_functions_rbac.sql. All asset tables enforce tenant access through public.has_org_permission(...) in supabase/schemas/073_rls_assets.sql.

The first implementation keeps one Assets permission set for Products, Inventory, and Customer Assets. Split permissions can be added later if the product needs different permissions for stock management versus customer asset management.

Images

Catalog and customer-asset files live in feature-named public buckets. Paths are UUID-first (never org slugs). Organization letterhead images stay in the organization bucket, not here.

products/<orgId>/<productId>/<imageId>.webp
products/<orgId>/brands/<brandId>/<imageId>.webp
assets/<orgId>/<assetId>/<fileId>.<ext>
organization/<orgId>/logo/<version>.webp
organization/<orgId>/branding/<imageId>.webp

Only one normalized image version is persisted. asset_images.position controls ordering in the UI.

Future Extensions

• Reservation flows for quotes, jobs, and tasks.
• Customer asset hierarchy once service history and reparenting semantics are defined.
• Task, deal, and workspace links that snapshot product/customer asset facts.
• Preventive maintenance schedules and generated work orders after workflows exist.
• Supplier catalogs as canonical shared references with organization-scoped overrides, connected through supplier_connections and the integrations marketplace.
• Barcode scanning workflows for the existing barcode and asset-tag fields.