RealisticDemoSeeder builds invoices, payments and estimates with
Model::create(), which bypasses both paths that normally set unique_hash
— the factories set it directly, and InvoiceService and friends encode it
from the id after insert. Nothing assigned it here, so every seeded
document had it NULL.
The PDF routes bind on that column, so the frontend built
`/invoices/pdf/` with an empty segment. That 404s, and the only symptom
is "Unable to load document preview" in the UI with nothing written to
the log, which makes it a genuinely slow thing to track down. Anyone who
seeds realistic demo data and opens a document hits it.
Production is unaffected: documents created through the app go through
the service layer, which assigns the hash. Existing seeded databases
need a backfill, encoding each id the same way the services do.
Uses Hashids, as the services do, rather than the factories' str_random,
so demo data matches what the app itself would have produced.
Creates 8 customers with addresses, 12 catalog items, 6 expense categories,
35 invoices (mix of DRAFT/SENT/VIEWED/PAID/PARTIALLY_PAID/UNPAID with
4 overdue), 17 payments covering the PAID and PARTIALLY_PAID invoices,
8 estimates, and 15 expenses — all time-distributed over the last 6
months so the AI chat assistant's get_company_stats, list_recent_payments,
and list_overdue_invoices tools return meaningfully different results
across query periods.
Dev-only: not wired into DatabaseSeeder, not in the test path (the
existing lightweight DemoSeeder stays there unchanged to keep the suite
fast). Runnable only via explicit:
php artisan db:seed --class=RealisticDemoSeeder --force
The seeder is idempotent — re-running wipes the previously seeded
records before regenerating, so you can iterate without manually
truncating the database.
Records are created directly via Model::create() rather than through
the existing InvoiceFactory / InvoiceItemFactory / ItemFactory, which
have bugs that make them unsuitable for realistic seeding:
- Both invoice factories unconditionally cascade-create a
RecurringInvoice on every invoice, generating junk recurring rows.
- ItemFactory sets creator_id to User->company_id, which doesn't
exist as a column on users (creator_id must be a user id).
- All three hardcode User::find(1)->companies()->first()->id,
coupling factories to a specific seeding order.
Those factory fixes are a separate follow-up if desired.
Item prices and all monetary values are stored in cents, matching the
rest of the app (the frontend divides by 100 on display). A $250
consulting hour is `price = 25000`.
