Inventory by Part Number (Mechanics)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €39/mo; 100k+ SKUs, cross-reference lookup, supplier sync

Generated from docs/plan/paid/inventory-by-part-number/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid supplier-management module for merchants handling 50k+ SKUs with complex part hierarchies. Enables part-number lookup, cross-reference mapping to suppliers, and automated supplier sync workflows. Critical for OEM suppliers, industrial distributors, and spare-parts businesses where a single product has multiple vendor part codes and requires reorder intelligence.

The problem

I stock 50,000+ parts from 12 suppliers, each part called by 3–5 different vendor codes. I need to look up a part by any code and know all its aliases. Standard product inventory treats each SKU as isolated; I cannot link related parts or auto-reorder when one supplier’s lead time changes.

What it does

• Part number entity with vendor_part_code, internal_sku, supplier_id, lead_time_days
• Cross-reference lookup: query by any alias returns all known aliases and supplier routes
• Supplier part mapping: one product linked to multiple suppliers, each with different codes and prices
• Part number search endpoint with fuzzy matching for manual entry errors
• Supplier connection setup UI: credentials, sync schedule, EDI/API format per supplier
• Reorder algorithm: trigger when any supplier’s stock drops below reorder point
• Sync audit log: timestamp, status, record count, error detail per sync run
• Bulk import from CSV: part numbers, cross-refs, supplier codes in one file
• Admin dashboard: part network visualization, supplier cost comparison, reorder status by supplier
• Webhook trigger on sync failure: alert staff to manual intervention needed
• Read-only part-lookup API for storefront to check availability across suppliers

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Full ERP (enterprise resource planning) system — this is not a general GL or manufacturing platform; scope is parts + reorder, not jobs/labor/WIP
• Supplier rating or performance scoring — metrics are logged but no algorithmic vendor evaluation; merchants handle relationship decisions
• Manufacturing or assembly workflows — no BOM (bill of materials), kit assembly, or work order logic; products are sourced complete
• Advanced forecasting or ML — uses simple moving average only; no seasonal adjustment or demand prediction beyond order history

Data model

New tables: parts (id, internal_sku, part_number, supplier_id, vendor_part_code, lead_time_days, reorder_qty, reorder_point), part_cross_references (id, primary_part_id, alias_part_id, is_substitute), supplier_part_map (id, supplier_id, product_id, vendor_code, vendor_price_minor_units, last_synced_at), part_sync_logs (id, supplier_id, sync_status, record_count, error_detail, started_at, completed_at). Inventory table extended with part_id foreign key.

API

• GET /api/parts/:id
• POST /api/parts
• GET /api/parts/lookup/:vendor_code
• GET /api/parts/:id/cross-references
• POST /api/parts/:id/cross-references
• DELETE /api/parts/:id/cross-references/:aliasId
• GET /api/supplier-part-map/:supplierId
• POST /api/parts/:id/sync-now
• GET /api/part-sync-logs/:supplierId
• POST /api/parts/bulk-import

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Part editor with vendor code picker, cross-reference manager showing alias graph, supplier sync trigger button, sync log viewer with error details, cost comparison table across suppliers, bulk import progress bar and error report.

The seam — why this is paid

Core owns the part-number interface and honest inventory lookup. Paid owns cross-reference algorithms, supplier-sync orchestration (EDI/API per supplier), reorder trigger logic, and the support commitment to troubleshoot supplier integrations.

Support commitment: complex SKU logic, supplier data sync, reorder algorithms

Dependencies

• product module (extends inventory)
• supplier module (connection credentials, API keys)
• webhook system (sync failure alerts)
• inventory module (qty tracking per part)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Lookup by vendor_part_code returns all cross-referenced parts
• Sync completes for 10k parts from one supplier within 5 minutes
• Reorder trigger fires when stock drops below reorder_point
• Sync failure logs detail the supplier and error, sends webhook alert
• Cross-reference loop detection prevents cycles (A→B→C→A)
• Bulk import validates all vendor_codes exist before commit
• Settings override: merchant can disable auto-reorder per supplier
• Read-only API does not expose supplier cost or lead time without ‘supplier:read’ role

Risks

Schema migration on live shops with millions of inventory records; lost cross-reference data on sync failure (must log before insert); supplier API format change breaks production sync; reorder duplication if sync retries without idempotency token; circular cross-references create infinite expansion.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.