Inventory Application

[Eluc1d]

Here's a matching outline for the Inventory application, structured the same way so the two documents sit together cleanly and share their integration points.

1. Purpose & Scope

The app is the single source of truth for everything TechToss physically holds — what the item is, where it is, what condition it's in, and whether it's available to donate or sell. The README flags two distinct cases that shape the whole design: specific/unique items (a particular laptop with its own serial number and specs) and bulk items (a bin of 40 identical USB cables). These need to coexist, because tracking a serial number on every cable is wasteful, but tracking only a count on a laptop loses critical detail. The goal is something anyone on staff can search and filter easily — the README explicitly calls out that Excel could do this but isn't accessible or filterable enough.

2. Core Data Model

The central entities:

• Item — the core record. Fields: ID, name/description, category (laptop, phone, cable, peripheral, etc.), tracking mode (unique vs. bulk), status, location, condition, date received, source/donor, and notes.
• Specifications — the variable technical details from the README (OS, RAM, storage, manufacturer, model, CPU, etc.). Because a cable and a laptop have wildly different specs, treat this as a flexible attribute set (key–value attributes or per-category fields) rather than a fixed column for every possible spec.
• Location — where the item physically lives (shelf, bin, room, offsite). Worth being its own entity so you can filter "everything in Storage Room B" and move items between locations cleanly.
• Bulk quantity — for bulk items, a simple count that increments on intake and decrements when items leave via a transaction.

The unique-vs-bulk split is the main design decision here. A clean approach: every item has a tracking_mode flag; unique items are one row each with full specs, bulk items are one row with a quantity field and lighter specs.

3. Key Features

Item intake

• Add a single item with full specs, or add bulk stock by quantity.
• Capture where it came from (donor/source), which ties back to reporting later.

Search & filtering

• This is the feature that justifies building this over a spreadsheet. Filter by category, status, location, and spec fields (e.g., "all laptops with 8GB+ RAM that are refurbished and in Room A").
• Free-text search across name, model, and notes.

Status tracking

• A clear status lifecycle: e.g., received → being tested → refurbished/ready → reserved → transferred/out. This tells staff at a glance what's available to give or sell.

Location management

• View and move items between locations; see everything at a given location.

Reporting

• Current stock counts by category, condition, or location.
• Items available for donation/sale (feeds directly into the Transaction app).

4. Integration with the Transaction App & Portal

This is the critical link. When a transaction is recorded, it should reference real inventory records, and completing that transaction should:

• Decrement the count for bulk items, or
• Flag a unique item as transferred/out.

That keeps stock accurate automatically instead of relying on someone to manually update two systems. Practically, the "items available for donation/sale" view in this app is exactly the list the Transaction app pulls from when building line items.

As with the other app, shared user accounts across Inventory, Transactions, and the portal (single sign-on) are worth designing once, up front.

5. Security

The README's security reminder applies here too, though the stakes differ from the money-handling Transaction app:

• User accounts with authentication (again, use an established framework rather than rolling your own).
• Role-based access: most staff can add and edit items, but deleting records or bulk-editing might be admin-only.
• A change log on items is useful — knowing who edited a status or moved an item helps when something goes missing or a record looks wrong.