[Products]: product inventory possibilities

[cewlio1]

On product creation i need to add a number field for inventory amount? possibly done in the inventory tab only im not sure but at least need the option on creation

[nielsdrost7]

title: [Products]: Product inventory possibilities

Description

As a user, I need to track inventory for product variants (like color) and manage stock levels with automatic reordering functionality.

Requirements

Product Variants

• Products should support attributes like "Color" that define variants
• Each variant should have separate inventory tracking (e.g., black product: 10 items, red product: 5 items)
• Follow Shopify's approach to variant management where each variant has its own inventory count
• Product attributes should be customizable (not just predefined fields)

Inventory Tracking

• Inventory should decrease automatically when a product is sold
• Use a single inventory_transactions table with a type field (purchase, sale, adjustment)
• Track transaction history for audit purposes

Reordering System

• Implement reorder points for each product variant
• When inventory falls below reorder point, trigger supplier reorder notification
• Never display supplier price on customer-facing invoices (only price after profit margin)

[nielsdrost7]

@coderabbitai make pull-request with AAA test Scenario's: Arrange, Act, Assert. And also make sure you test edge cases

[coderabbitai]

Coding Plan

Approach

Implement comprehensive inventory tracking with product variant support, allowing users to manage stock levels per variant, track inventory transactions, and receive reorder alerts when stock falls below configured thresholds.

Observations

This is a Laravel-based multi-tenant ERP system using Filament 4 for admin panels. The Products module currently handles basic product information (pricing, categories, units) with a service layer architecture.

The codebase follows established patterns including:

• Observers for model lifecycle hooks
• Service classes for business logic
• Event-driven architecture with auto-discovery
• Polymorphic relationships for flexible associations
• Spatie permissions for access control

The Products module has no existing inventory or variant functionality, but related modules (Payments, Expenses, Invoices) demonstrate transaction tracking patterns that can be extended. The project architecture uses VARCHAR columns (not database ENUM types) with PHP enum validation, and fully relational designs avoiding JSON columns.

Assumptions

Assumption 1: Variant data storage approach

Options Considered:

• Single table with separate columns for each attribute (inflexible, doesn't support custom attributes)
• Relational approach with product_attributes and product_variant_attribute_values tables (flexible, queryable, supports custom attributes)

Chosen Option: 2

Rationale: The relational approach supports the requirement for customizable attributes, enables proper indexing and searching, and aligns with the project's architecture of avoiding JSON columns while supporting the Shopify-style variant management specified in the ticket.

Assumption 2: Simple product inventory handling

Options Considered:

• Add inventory fields directly to products table alongside variant support
• Create a default variant for all products, treating simple products as single-variant products

Chosen Option: 2

Rationale: Creating a default variant for simple products provides architectural consistency, simplifies inventory queries (always on variants), and allows seamless upgrade path when users add more variants later.

Assumption 3: Initial inventory entry point

Options Considered:

• Require inventory tab for all inventory entry
• Provide a simple "Initial Stock" field on the main creation form that sets up the default variant

Chosen Option: 2

Rationale: Add an "Initial Stock" field to the product creation form that automatically creates a default variant with the specified quantity, giving users the simple UX they requested while maintaining the variant architecture underneath.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Database Foundation & Core Models

Establish the database schema and Eloquent models for variants, attributes, inventory transactions, and suppliers, creating the relational foundation for all inventory functionality.

Task 1: Create product variants schema

Add database structure for storing product variants with their inventory settings.

• Create migration create_product_variants_table in Modules/Products/Database/Migrations/
• Define columns: id, product_id (foreign key to products), sku (unique, indexed), variant_name, price (nullable decimal 20,4, overrides product price if set), cost_price (nullable decimal 20,4), quantity (integer, default 0), reorder_point (integer, nullable), company_id (for multi-tenancy), timestamps
• Add foreign key constraint product_id references products.id with cascade delete
• Add composite unique index on (company_id, sku) for SKU uniqueness within company
• Add index on (product_id, quantity) for stock level queries
• Note: Variant attributes will be stored in separate relational tables (see Task 1.2)

Task 2: Create product attributes schema

Add relational structure for defining customizable product attributes (like Color, Size) that apply to all variants of a product.

• Create migration create_product_attributes_table in Modules/Products/Database/Migrations/
• Define columns: id, product_id (foreign key to products), attribute_name (string, e.g., "Color", "Size"), attribute_order (integer for display ordering), company_id, timestamps
• Add foreign key product_id references products.id with cascade delete
• Add index on (product_id, attribute_order) for ordered attribute display
• Add unique constraint on (product_id, attribute_name) to prevent duplicate attributes per product

Task 3: Create variant attribute values schema

Add table for storing actual attribute values per variant (e.g., variant 1 has Color=Red, Size=Large).

• Create migration create_product_variant_attribute_values_table in Modules/Products/Database/Migrations/
• Define columns: id, variant_id (foreign key to product_variants), product_attribute_id (foreign key to product_attributes), attribute_value (string, e.g., "Red", "XL"), company_id, timestamps
• Add foreign key variant_id references product_variants.id with cascade delete
• Add foreign key product_attribute_id references product_attributes.id with cascade delete
• Add unique constraint on (variant_id, product_attribute_id) to ensure one value per attribute per variant
• Add index on variant_id for fast variant attribute lookups

Task 4: Create inventory transactions schema

Add transaction table for audit trail of all inventory movements with polymorphic support.

• Create migration create_inventory_transactions_table in Modules/Products/Database/Migrations/
• Define columns: id, variant_id (foreign key to product_variants), transaction_type (string: 'purchase', 'sale', 'adjustment'), quantity (integer, can be negative), previous_quantity (integer, for audit), new_quantity (integer, for audit), reference_id (nullable, for linking to invoices/purchases), reference_type (nullable, for polymorphic relationship), notes (text, nullable), transacted_by (foreign key to users), company_id, timestamps
• Add foreign key variant_id references product_variants.id with cascade delete
• Add index on (variant_id, created_at) for transaction history queries
• Add index on transaction_type for filtering

Task 5: Create suppliers schema

Add supplier management table to support reorder functionality with supplier associations.

• Create migration create_suppliers_table in Modules/Products/Database/Migrations/
• Define columns: id, company_id, supplier_name, contact_name (nullable), email (nullable), phone (nullable), address (text, nullable), notes (text, nullable), is_active (boolean, default true), timestamps
• Add foreign key company_id references companies.id with cascade delete
• Add index on is_active for filtering active suppliers

Task 6: Add supplier relationship to variants

Link variants to their suppliers for reorder automation.

• Create migration add_supplier_to_product_variants in Modules/Products/Database/Migrations/
• Add column: supplier_id (foreign key to suppliers, nullable), supplier_cost_price (decimal 20,4, nullable)
• Add foreign key constraint with set null on delete
• Add index on supplier_id for supplier-based queries

Task 7: Create Eloquent models with relationships

Implement model classes following the established AbstractObserver pattern for automatic company_id assignment.

• Create ProductVariant.php in Modules/Products/Models/ with: guarded = [], casts for price/cost_price (decimal:4), quantity/reorder_point (integer), relationships: belongsTo Product, belongsTo Supplier, hasMany InventoryTransaction, hasMany ProductVariantAttributeValue
• Create ProductAttribute.php in Modules/Products/Models/ with: guarded = [], casts for attribute_order (integer), relationships: belongsTo Product, hasMany ProductVariantAttributeValue
• Create ProductVariantAttributeValue.php in Modules/Products/Models/ with: guarded = [], relationships: belongsTo ProductVariant, belongsTo ProductAttribute
• Create InventoryTransaction.php in Modules/Products/Models/ with: guarded = [], casts for quantities (integer), transaction_type (string), relationships: belongsTo ProductVariant, belongsTo User (transactedBy), morphTo for reference (transactionable)
• Create Supplier.php in Modules/Products/Models/ with: guarded = [], casts for is_active (boolean), relationship hasMany ProductVariant
• Update Product.php model to add relationships: hasMany ProductVariant, hasMany ProductAttribute
• Create observers in Modules/Products/Observers/: ProductVariantObserver, ProductAttributeObserver, SupplierObserver extending AbstractObserver to auto-set company_id

🤖 Prompt for AI agents

This phase establishes the database foundation for inventory tracking with
product variants using a fully relational architecture. The goal is to create
the schema and Eloquent models for variants, customizable attributes, inventory
transactions, and suppliers.

Create migrations for:
- product_variants table with sku, variant_name, price, cost_price, quantity,
reorder_point, company_id, and appropriate indexes
- product_attributes table for defining customizable attributes (Color, Size,
etc.) per product with attribute_name, attribute_order, company_id
- product_variant_attribute_values junction table linking variants to their
attribute values
- inventory_transactions table for audit trail with transaction_type (string),
quantity fields, reference polymorphic relationship
- suppliers table with contact information and is_active flag
- Migration to add supplier_id and supplier_cost_price to product_variants

Create models: ProductVariant, ProductAttribute, ProductVariantAttributeValue,
InventoryTransaction, Supplier with proper relationships, casts, and guarded
properties.

Update Product model to add hasMany relationships for ProductVariant and
ProductAttribute.

Create observers for ProductVariant, ProductAttribute, and Supplier extending
AbstractObserver to auto-set company_id.

Phase 2: Business Logic & Product Creation

Implement service layer methods for inventory management, variant/attribute management, and update product creation flow to handle initial stock via default variants.

Task 1: Create InventoryService for transaction handling

Implement centralized service for all inventory operations with transaction safety and audit trail creation.

• Create InventoryService.php in Modules/Products/Services/
• Implement method recordTransaction(ProductVariant $variant, string $type, int $quantity, ?Model $reference, ?User $user, ?string $notes) that: wraps operation in DB transaction, locks variant row (SELECT FOR UPDATE), calculates new quantity, creates InventoryTransaction record with previous/new quantity, updates variant quantity, returns transaction model
• Implement method adjustStock(ProductVariant $variant, int $newQuantity, User $user, string $reason) that calls recordTransaction with 'adjustment' type and calculated difference
• Implement method getTransactionHistory(ProductVariant $variant, ?string $type, ?int $limit) that returns paginated transaction history with eager-loaded relationships

Task 2: Create ProductVariantService for variant CRUD

Implement service layer for variant management with relational attribute value handling.

• Create ProductVariantService.php in Modules/Products/Services/
• Implement method createVariant(Product $product, array $data) that: wraps in DB transaction, creates ProductVariant with auto-generated SKU if not provided (format: {product_code}-{random_string}), processes attribute_values array if present to create ProductVariantAttributeValue records, returns variant with loaded attribute values
• Implement method updateVariant(ProductVariant $variant, array $data) that: updates variant excluding quantity (quantity changes go through InventoryService), syncs attribute values if provided in data array
• Implement method deleteVariant(ProductVariant $variant) that: checks if variant can be deleted (no transactions/references), deletes associated attribute values, soft deletes variant
• Implement method createDefaultVariant(Product $product, ?int $initialStock) that: creates a default variant with variant_name = 'Default', sku from product code, no attribute values, records initial stock transaction if provided using InventoryService

Task 3: Create ProductAttributeService for attribute management

Implement service for managing product-level attribute definitions.

• Create ProductAttributeService.php in Modules/Products/Services/
• Implement method createAttribute(Product $product, string $attributeName, ?int $order) that: creates ProductAttribute with auto-determined order if not provided, returns attribute model
• Implement method updateAttribute(ProductAttribute $attribute, array $data) that: updates attribute_name and/or attribute_order
• Implement method deleteAttribute(ProductAttribute $attribute) that: checks if any variants have values for this attribute, if yes prevents deletion with error message, if no deletes attribute
• Implement method reorderAttributes(Product $product, array $orderedAttributeIds) that: updates attribute_order for each attribute in the array

Task 4: Update ProductService to handle initial inventory

Extend existing product creation to initialize default variant with stock.

• In Modules/Products/Services/ProductService.php, modify createProduct() method to: wrap operation in DB transaction, create product as before, check for 'initial_stock' key in data array, if present call ProductVariantService::createDefaultVariant with the product and initial_stock value, return product with loaded variants relationship
• Modify deleteProduct() method to verify no inventory transactions exist before deletion
• Add method getProductWithVariants(Product $product) that eager-loads variants with current stock levels and attribute values

Task 5: Update product form to include initial stock field

Add simple inventory input field to product creation form.

• In Modules/Products/Filament/Company/Resources/Products/Schemas/ProductForm.php, add TextInput field named 'initial_stock' in the Details section (left column after product_name field)
• Configure field: numeric(), minValue(0), label('Initial Stock'), helperText('Starting inventory quantity (creates a default variant)'), visible only on create page using hiddenOn('edit')
• Field should be nullable, allowing users to skip initial stock setup

🤖 Prompt for AI agents

This phase implements the service layer for inventory, variant, and attribute
management, and updates product creation to support initial stock entry. The
goal is to enable inventory functionality with proper business logic and simple
initial stock UI.

Create InventoryService with methods for:
- recordTransaction() with row locking and audit trail creation
- adjustStock() that calculates difference and records adjustment
- getTransactionHistory() with filtering and pagination

Create ProductVariantService with methods for:
- createVariant() that handles SKU generation and relational attribute values
creation
- updateVariant() that syncs attribute values while protecting quantity field
- deleteVariant() that checks for transactions and cleans up attribute values
- createDefaultVariant() that creates simple variant with optional initial stock

Create ProductAttributeService with methods for:
- createAttribute() with auto-ordering
- updateAttribute() for name and order changes
- deleteAttribute() with validation that no variants use the attribute
- reorderAttributes() for bulk ordering updates

Update ProductService.createProduct() to accept initial_stock and create default
variant, wrap in DB transaction.

Update ProductService.deleteProduct() to check for inventory transactions.

Add getProductWithVariants() method that eager-loads variants with attribute
values.

Add initial_stock TextInput field to ProductForm.php, configured as numeric,
nullable, visible only on create page.

Phase 3: Variant Management & Stock Interface

Build comprehensive UI for managing product variants with customizable attributes and adjusting stock levels through a dedicated inventory tab.

Task 1: Add inventory tab to product form structure

Refactor product form from Grid layout to Tabs layout for better organization.

• In Modules/Products/Filament/Company/Resources/Products/Schemas/ProductForm.php, replace Grid::make(2) with Tabs::make() wrapper
• Create three tabs: Tab 'Details' (contains existing Details and Classification sections in Grid::make(2)), Tab 'Description' (contains existing Description section), Tab 'Inventory & Variants' (new, will contain attribute manager and variant repeater)
• Ensure tab structure maintains current field layout and validation rules

Task 2: Create product attribute management section

Build interface for defining product-level attributes before creating variants.

• In the 'Inventory & Variants' tab within ProductForm.php, add Section::make('Product Attributes') at the top
• Add Repeater field named 'attributes' using relationship('attributes') with orderColumn('attribute_order')
• Configure repeater: simple(), reorderable(), collapsible(false), itemLabel(fn ($state) => $state['attribute_name'] ?? 'New Attribute'), defaultItems(0)
• Add schema fields: TextInput 'attribute_name' (required, unique per product, label 'Attribute Name (e.g., Color, Size)')
• Configure deleteAction to prevent deletion if variants have values for this attribute (show confirmation dialog)
• Add helper text: "Define attributes that apply to all variants of this product. Variants will specify values for each attribute."

Task 3: Create variant repeater component with attribute value inputs

Build repeater interface for managing multiple product variants with their attribute values and inventory settings.

• In the 'Inventory & Variants' tab within ProductForm.php below attributes section, add Section::make('Product Variants')
• Add Repeater field named 'variants' using relationship('variants')
• Configure repeater: reorderable(false), collapsible(), itemLabel(fn ($state) => $state['sku'] ?? 'New Variant'), defaultItems(0)
• Add schema fields in repeater: TextInput 'sku' (required, unique validation, visible only on create/read-only on edit), TextInput 'variant_name' (required, label 'Variant Name'), Repeater 'attributeValues' with relationship('attributeValues') that: loads product attributes as options, for each attribute creates Select 'product_attribute_id' (disabled, shows attribute name) and TextInput 'attribute_value' (required, placeholder based on attribute name), TextInput 'price' (numeric, nullable, helperText 'Override product price'), TextInput 'cost_price' (numeric, nullable), TextInput 'quantity' (numeric, disabled, helperText 'Use stock adjustment actions to change'), TextInput 'reorder_point' (numeric, nullable, helperText 'Alert threshold'), Select 'supplier_id' (relationship to suppliers, nullable)
• Add deleteAction customization to prevent deletion if transactions exist
• Configure repeater to reactively show attribute value inputs based on product attributes defined above

Task 4: Create stock adjustment modal action

Implement dedicated UI for recording stock adjustments with audit trail.

• Add custom Action to variant repeater item menu (three-dot menu) named 'adjustStock'
• Configure action: modal dialog with form fields: TextInput 'new_quantity' (numeric, required, default to current quantity), Textarea 'notes' (required for audit, label 'Reason for Adjustment')
• Action handler: validate new quantity differs from current, call InventoryService::adjustStock with authenticated user and notes, show success notification with transaction details, refresh repeater item to show updated quantity

Task 5: Display stock level indicators

Add visual feedback for low stock and reorder point status.

• In the variant repeater schema within ProductForm.php, modify quantity field to add suffix with color-coded badge
• Badge logic: if quantity <= 0 show 'Out of Stock' (red badge), if quantity <= reorder_point show 'Low Stock' (yellow badge), otherwise show 'In Stock' (green badge)
• Add ViewField or Placeholder below quantity to display last transaction info: "Last updated [date] by [user] ([type])" using variant's latest transaction relationship

🤖 Prompt for AI agents

This phase builds the UI for managing product variants with customizable
attributes and stock levels. The goal is to provide a comprehensive interface
where users define attributes, create variants with attribute values, and adjust
stock.

Refactor ProductForm.php to use Tabs layout with three tabs: Details,
Description, and Inventory & Variants.

In the Inventory & Variants tab, add a Product Attributes section with a
reorderable Repeater bound to attributes relationship. Include attribute_name
TextInput with validation and helper text. Configure deleteAction to check for
variant usage.

Below attributes, add Product Variants section with Repeater bound to variants
relationship. Include fields for sku, variant_name, nested repeater for
attributeValues (showing attribute name and value input), price, cost_price,
quantity (disabled), reorder_point, and supplier_id.

Configure the variant repeater to reactively load attribute value inputs based
on product attributes defined above.

Add adjustStock custom action to variant repeater items that opens modal with
new_quantity and notes fields, calls InventoryService::adjustStock, and
refreshes the item.

Add color-coded badge suffix to quantity field showing stock status (Out of
Stock/Low Stock/In Stock).

Add display field showing last transaction details below quantity.

Phase 4: Transaction History & Reorder Automation

Implement transaction tracking interface and automated reorder notifications when stock levels trigger thresholds.

Task 1: Create inventory transaction resource

Build Filament resource for viewing transaction history and manual transaction entry.

• Create InventoryTransactionResource.php in Modules/Products/Filament/Company/Resources/
• Define table columns: product name (via variant.product relationship), variant SKU, transaction_type (badge with colors: purchase=green, sale=blue, adjustment=yellow), quantity (with +/- prefix), previous_quantity, new_quantity, reference_type/reference_id (combined display), transacted_by (user name), created_at
• Add table filters: SelectFilter for transaction_type, DateFilter for created_at range, SelectFilter for product (relationship)
• Configure table: default sort by created_at descending, paginate at 50 items, searchable by variant SKU and product name
• Make resource read-only (no create/edit pages) except for adjustment transactions

Task 2: Create manual adjustment page

Provide interface for staff to record manual inventory adjustments across variants.

• Create AdjustInventory.php page in Modules/Products/Filament/Company/Resources/InventoryTransactions/Pages/
• Build form with: Select field for product (searchable, loads variants via dependent Select), Select field for variant (dependent on product selection, displays SKU and current quantity), TextInput for new_quantity (numeric, required, shows real-time difference calculation), Textarea for notes (required)
• Form submit action: calls InventoryService::adjustStock, shows success notification with before/after quantities, redirects to transaction list with filter applied to show new transaction
• Add authorization check for 'adjust_inventory' permission

Task 3: Implement automated reorder notification system

Create observer and notification infrastructure for alerting when stock hits reorder points.

• Create InventoryTransactionObserver.php in Modules/Products/Observers/ that listens to created event
• In created method: load transaction's variant with reorder_point, check if new_quantity <= reorder_point and reorder_point is set, if true dispatch LowStockDetected event with variant data
• Create LowStockDetected.php event in Modules/Products/Events/ that stores ProductVariant instance and implements ShouldBroadcast for real-time alerts
• Create LowStockNotification.php notification class in Modules/Products/Notifications/ extending Laravel Notification with mail and database channels, format message to include: product name, variant SKU, current quantity, reorder point, supplier info if available
• Create listener SendLowStockNotification.php in Modules/Products/Listeners/ that receives LowStockDetected event and sends notification to users with 'manage_inventory' permission for that company

Task 4: Create supplier management interface

Build basic supplier CRUD resource to support reorder workflow.

• Create SupplierResource.php in Modules/Products/Filament/Company/Resources/
• Define form fields: TextInput supplier_name (required), TextInput contact_name, TextInput email (email validation), TextInput phone, Textarea address, Textarea notes, Toggle is_active
• Define table columns: supplier_name, contact_name, email, phone, is_active (toggle column), variants count (aggregate)
• Add table actions: view, edit, delete (with confirmation if variants exist)
• Add global search on supplier_name, email, contact_name
• Register supplier navigation item in Products section of sidebar

Task 5: Update invoice/sales flow to auto-record inventory transactions

Integrate inventory deduction when products are sold through invoices.

• Identify the service/action that processes invoice line items (likely in Modules/Invoices/Services/)
• After invoice is marked as paid/confirmed, iterate through line items that reference products with variants
• For each line item: resolve the variant (needs variant_id on line items or variant selection UI, this is a dependency), call InventoryService::recordTransaction with type='sale', quantity=negative line item quantity, reference=invoice, user=authenticated user
• Wrap in try-catch to log errors without blocking invoice processing
• Show warning notification if inventory goes negative after sale

🤖 Prompt for AI agents

This phase implements transaction history viewing, manual adjustments, automated
reorder notifications, supplier management, and sales integration. The goal is
to complete the inventory system with audit trails, alerts, and automated stock
deductions.

Create InventoryTransactionResource with table showing transaction history
(product, variant SKU, type badge, quantities, reference, user, date), filters
for type/date/product, and read-only configuration.

Create AdjustInventory page with dependent product/variant selects, new_quantity
input with real-time difference calculation, notes textarea, and authorization
check. Submit calls InventoryService::adjustStock and redirects with filter.

Create InventoryTransactionObserver that detects low stock on transaction
creation and dispatches LowStockDetected event when new_quantity <=
reorder_point.

Create LowStockDetected event, LowStockNotification class (mail/database
channels), and SendLowStockNotification listener to notify users with
manage_inventory permission.

Create SupplierResource with form fields, table columns, CRUD actions, global
search, and navigation registration.

Update invoice processing service to record inventory transactions when invoices
are confirmed. Iterate through line items, resolve variants, call
InventoryService::recordTransaction with type='sale', wrap in try-catch, and
show warnings for negative inventory.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase establishes the database foundation for inventory tracking with
product variants using a fully relational architecture. The goal is to create
the schema and Eloquent models for variants, customizable attributes, inventory
transactions, and suppliers.

Create migrations for:
- product_variants table with sku, variant_name, price, cost_price, quantity,
reorder_point, company_id, and appropriate indexes
- product_attributes table for defining customizable attributes (Color, Size,
etc.) per product with attribute_name, attribute_order, company_id
- product_variant_attribute_values junction table linking variants to their
attribute values
- inventory_transactions table for audit trail with transaction_type (string),
quantity fields, reference polymorphic relationship
- suppliers table with contact information and is_active flag
- Migration to add supplier_id and supplier_cost_price to product_variants

Create models: ProductVariant, ProductAttribute, ProductVariantAttributeValue,
InventoryTransaction, Supplier with proper relationships, casts, and guarded
properties.

Update Product model to add hasMany relationships for ProductVariant and
ProductAttribute.

Create observers for ProductVariant, ProductAttribute, and Supplier extending
AbstractObserver to auto-set company_id.
===============================================================================

Task: 2

This phase implements the service layer for inventory, variant, and attribute
management, and updates product creation to support initial stock entry. The
goal is to enable inventory functionality with proper business logic and simple
initial stock UI.

Create InventoryService with methods for:
- recordTransaction() with row locking and audit trail creation
- adjustStock() that calculates difference and records adjustment
- getTransactionHistory() with filtering and pagination

Create ProductVariantService with methods for:
- createVariant() that handles SKU generation and relational attribute values
creation
- updateVariant() that syncs attribute values while protecting quantity field
- deleteVariant() that checks for transactions and cleans up attribute values
- createDefaultVariant() that creates simple variant with optional initial stock

Create ProductAttributeService with methods for:
- createAttribute() with auto-ordering
- updateAttribute() for name and order changes
- deleteAttribute() with validation that no variants use the attribute
- reorderAttributes() for bulk ordering updates

Update ProductService.createProduct() to accept initial_stock and create default
variant, wrap in DB transaction.

Update ProductService.deleteProduct() to check for inventory transactions.

Add getProductWithVariants() method that eager-loads variants with attribute
values.

Add initial_stock TextInput field to ProductForm.php, configured as numeric,
nullable, visible only on create page.
===============================================================================

Task: 3

This phase builds the UI for managing product variants with customizable
attributes and stock levels. The goal is to provide a comprehensive interface
where users define attributes, create variants with attribute values, and adjust
stock.

Refactor ProductForm.php to use Tabs layout with three tabs: Details,
Description, and Inventory & Variants.

In the Inventory & Variants tab, add a Product Attributes section with a
reorderable Repeater bound to attributes relationship. Include attribute_name
TextInput with validation and helper text. Configure deleteAction to check for
variant usage.

Below attributes, add Product Variants section with Repeater bound to variants
relationship. Include fields for sku, variant_name, nested repeater for
attributeValues (showing attribute name and value input), price, cost_price,
quantity (disabled), reorder_point, and supplier_id.

Configure the variant repeater to reactively load attribute value inputs based
on product attributes defined above.

Add adjustStock custom action to variant repeater items that opens modal with
new_quantity and notes fields, calls InventoryService::adjustStock, and
refreshes the item.

Add color-coded badge suffix to quantity field showing stock status (Out of
Stock/Low Stock/In Stock).

Add display field showing last transaction details below quantity.
===============================================================================

Task: 4

This phase implements transaction history viewing, manual adjustments, automated
reorder notifications, supplier management, and sales integration. The goal is
to complete the inventory system with audit trails, alerts, and automated stock
deductions.

Create InventoryTransactionResource with table showing transaction history
(product, variant SKU, type badge, quantities, reference, user, date), filters
for type/date/product, and read-only configuration.

Create AdjustInventory page with dependent product/variant selects, new_quantity
input with real-time difference calculation, notes textarea, and authorization
check. Submit calls InventoryService::adjustStock and redirects with filter.

Create InventoryTransactionObserver that detects low stock on transaction
creation and dispatches LowStockDetected event when new_quantity <=
reorder_point.

Create LowStockDetected event, LowStockNotification class (mail/database
channels), and SendLowStockNotification listener to notify users with
manage_inventory permission.

Create SupplierResource with form fields, table columns, CRUD actions, global
search, and navigation registration.

Update invoice processing service to record inventory transactions when invoices
are confirmed. Iterate through line items, resolve variants, call
InventoryService::recordTransaction with type='sale', wrap in try-catch, and
show warnings for negative inventory.

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[nielsdrost7]

@coderabbitai show me the PR

[coderabbitai]

@nielsdrost7, I'll initiate the implementation process to create a pull request with all the planned changes. This includes database migrations, models, services, UI components, and comprehensive AAA (Arrange-Act-Assert) tests as you requested.

Implementation Plan: Product Inventory with Variants

Overview: Implement comprehensive inventory tracking system with product variant support, customizable attributes, transaction history, and automated reorder notifications.

The implementation agent will now create a pull request with all migrations, models, services, UI components, and comprehensive tests. The PR will be structured according to the 4 phases outlined above.

---

⏳ Preparing changes...

[nielsdrost7]

@coderabbitai show me the PR

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for pull requests that reference issue #21 in the InvoicePlane-v2 repository
gh pr list --repo InvoicePlane/InvoicePlane-v2 --search "21 in:body OR 21 in:title" --state all --limit 10 --json number,title,url,state,createdAt

# Also check for any recent PRs in case the issue number isn't explicitly mentioned
gh pr list --repo InvoicePlane/InvoicePlane-v2 --state all --limit 5 --json number,title,url,state,createdAt --search "inventory OR variant OR product"

Length of output: 151

---

@nielsdrost7, I apologize for the confusion. The implementation plan was provided in my previous response, but the actual pull request hasn't been created yet. Let me now initiate the code changes to create the PR with all the features and AAA tests.

Implementation: Product Inventory System with Variants

This implementation will create a comprehensive inventory tracking system with:

• Product variants with customizable attributes (Color, Size, etc.)
• Inventory transaction tracking with audit trail
• Automated reorder notifications
• Supplier management
• Integration with invoice/sales flow
• Comprehensive AAA test suite with edge cases

Once the implementation is complete, a pull request will be created with all the code changes, migrations, and comprehensive tests. The PR will reference issue #21 and include all features requested: variant management, inventory tracking, automated reordering, and AAA test scenarios covering edge cases.

---

🏁 Script executed:

#!/bin/bash
# Find the Products module structure to understand the codebase organization
fd -t d "Products" | head -20

# Check existing Product model structure
fd -t f "Product.php" Modules/Products/Models/

# Check existing migration patterns
fd -t f "create_products_table" Modules/Products/Database/Migrations/

# Check observer patterns
fd -t f "Observer.php" Modules/Products/Observers/

Length of output: 341

---

🏁 Script executed:

#!/bin/bash
# Check existing service patterns in Products module
fd -t f "Service.php" Modules/Products/Services/

# Look at ProductService to understand existing patterns
cat Modules/Products/Services/ProductService.php | head -50

Length of output: 2094

---

🏁 Script executed:

#!/bin/bash
# Check the ProductForm.php structure
fd -t f "ProductForm.php" Modules/Products/

# Check Filament resource patterns
fd -t f "Resource.php" Modules/Products/Filament/

Length of output: 320

---

🏁 Script executed:

#!/bin/bash
# Find invoice processing service
fd -t f "Service.php" Modules/Invoices/Services/

# Check event/listener patterns
fd -t d "Events" Modules/Products/
fd -t d "Listeners" Modules/Products/
fd -t d "Notifications" Modules/Products/

Length of output: 148

---

@nielsdrost7, I've now initiated the implementation process with the `` tag. Here's what happens next:

Implementation Status

Current Step: The implementation agent is being invoked to create the actual code changes.

What will be created:

1. Database Layer (6 migrations + 5 models + 3 observers)

   • Product variants, attributes, and attribute values tables
   • Inventory transactions table with audit trail
   • Suppliers table
   • All Eloquent models with relationships

2. Business Logic (3 new services + updates to ProductService)

   • InventoryService - transaction recording with row locking
   • ProductVariantService - variant CRUD with SKU generation
   • ProductAttributeService - attribute management

3. Filament UI (3 resources + updated ProductForm)

   • Refactored product form with tabs (Details, Description, Inventory & Variants)
   • Inventory transaction history resource
   • Supplier management resource
   • Manual stock adjustment page

4. Automation (1 observer + 1 event + 1 notification + 1 listener)

   • Low stock detection and automated notifications
   • Integration with invoice processing for automatic inventory deduction

5. Comprehensive Test Suite (7 test files with AAA pattern)

   • Unit tests for all services
   • Integration tests for workflows
   • UI/Feature tests for Filament components
   • Edge case coverage (concurrent transactions, duplicate SKUs, negative inventory, etc.)

The implementation agent will create all these files and submit them as a pull request referencing issue #21. You'll receive a notification once the PR is ready for review. The PR will include all the code, migrations, tests, and documentation needed for the complete inventory system with product variants.

🐰 Ears perked up, ready to track that PR for you!

---

⏳ Preparing changes...