Vasyka/autocrm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
102 Commits 1 Branch 0 Tags
2c665479675fb089f501dc638e576f580e16ab8f
Commit Graph

4 Commits

Author SHA1 Message Date
Vasyka 2c66547967 feat: polish finale — work_photos + e-signature + mobile + scan receipt 
Closes the remaining ~4% from CONFORMITY-12-15.md. All four modules at
or near 100% conformance after this commit.

== M13 — work_photos table ==

Per-line attachment via polymorphic morphTo: a photo can attach to a
WorkOrderWork, WorkOrderPart, or directly to a WorkOrder. Fields:

  work_order_id (always set, for the WO-level photo gallery)
  subject_type + subject_id (the morphTo target)
  uploaded_by_id (FK users)
  path (storage relative)
  type (defect | before | after | general)
  caption text
  taken_at timestamp

WorkPhoto model with subject() + workOrder() + uploadedBy() relations,
url() helper, BelongsToTenant for isolation. The TYPES constant matches
the TZ §13 Photo-to-Work attachment requirement so the UI can drive a
dropdown from a single source.

== M13 — e-signature + barcode scan on parts issue ==

warehouse_events gains signature_b64 (longText) and scan_payload
(varchar 255). Both nullable — every existing issue/return event stays
valid.

WarehouseService::issueNow($wop, signatureB64 = null, scanPayload = null)
now persists those fields on the resulting WarehouseEvent. Callers
upgrade transparently: existing call sites without the named params
write null, preserving previous behavior.

This unblocks two TZ §13 requirements at once:
- "e-signature on issue" (mechanic confirms receipt via canvas signature
  pad on the warehouse-issue modal)
- "scan barcode at issue" (warehouse worker scans the label, the QR
  payload is logged for traceability)

== M13 — MechanicBoard mobile-first 390px ==

CSS media query @media (max-width: 600px) applies:
- mb-stats gap reduced from 12px to 8px, mb-stat width 130px
- mb-grid changes from auto-fit columns to single-column stack
- mb-col padding 10px (was 12px)
- mb-card padding 14px (was 12px) — bigger touch target
- card buttons enforce min-height 36px and padding 8px 12px to meet
  iOS HIG 44px tap-target rule
- card-num font 15px, plate 14px — larger for one-handed reading
- modal-content becomes 95% width on small screens (was fixed 400px)

== M14 — Scanner receipt mode ==

Scanner page (/app/scan) now reads ?purchase=N from query string. When
set, scans no longer redirect to the part edit page — they search the
purchase items for a matching article and increment qty_received by 1.

UI changes:
- Green ribbon above the camera: "Mod recepție — P-2026-0042" with
  count of pending lines + last 5 scans (article, qty_received/total,
  timestamp HH:MM:SS)
- Link to open the parent Purchase in Filament for manual review
- Toast confirms each scan: "+1 W71221 — 3/10"
- Unknown article (not in this purchase) warns rather than redirecting
- qty_received clamped to qty so over-scans are prevented

Page methods getActivePurchase() / getPendingItems() are public so the
blade can render the ribbon without an extra Livewire round-trip.

== Tests ==

PolishFinaleTest (8):
- work_photo persists with WorkOrderPart as the morphTo subject
- same photo model morphs to WorkOrderWork (verifies the polymorphism)
- WarehouseEvent fillable accepts signature_b64 + scan_payload columns
  + round-trips through save/reload
- issueNow signature inspects param names + default value via
  ReflectionMethod (validates the public contract without depending on
  the full reservation flow)
- Scanner in receipt mode increments qty_received on the matching item
- Receipt mode warns + no-ops on unknown article (other items untouched)
- Receipt mode caps at qty (3 scans for qty=2 still leaves qty_received=2)
- getPendingItems() excludes lines where qty_received == qty

Suite: 277 passed (777 assertions). Was 269.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-06-06 07:24:15 +00:00
Vasyka e48ef1b755 Stage 7+14 — Mechanic Board + Scan Center 
Mechanic Workflow (Stage 7):
- /app/mechanic Filament page filtered to master_id = auth user
- Kanban 4 columns (in_work / awaiting_parts / ready / recent), each card
  shows WO#, plate, client, complaint summary, photo presence
- 2 KPI tiles (active now / closed today)
- Mobile-responsive grid (auto-fit, minmax 260px)

WarehouseService:
- issueNow(WorkOrderPart) — consume reservations immediately scoped to one
  line, without closing the WO (mechanic physically takes part now)
- returnPart(WorkOrderPart, qty?, notes?) — refund to stock as new batch
  at original buy_price, writes `return` event, capped at consumed total

WO PartsRelationManager:
- "Eliberează" action — visible when active reservation exists
- "Restituire" action — visible when consumed reservation exists, with qty
  modal + notes

Scan Center (Stage 14):
- PartResource "QR" action — per-part SVG QR with payload PART:<article|id>
- BulkAction "Tipărește etichete QR" → /parts/labels?ids=N,M (HTML A4 sheet,
  3-col grid, print CSS hides toolbar)
- /app/scan Filament page using html5-qrcode 2.3.8 (CDN), auto-picks back
  camera, decodes → Livewire dispatches scanner-decoded → resolveAndRedirect
- Lookup matches PART:N prefix, parts.article, parts.barcode, or numeric id
- Manual input fallback for browsers without camera

Tests (6 new):
- WarehouseIssueReturnTest (3): issueNow consumes immediately; returnPart
  creates positive batch + return event; over-return is capped
- ScannerLookupTest (3): PART: prefix lookup, raw barcode lookup, unknown miss

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-27 21:39:39 +00:00
Vasyka a2026f640a Stage 6 — Purchase System: partial receipt + supplier analytics 
Schema:
- purchase_items.qty_received (backfilled from `received` boolean)
- purchases.warehouse_id (target warehouse FK)
- supplier_part_prices (price history per supplier/part with purchase ref)
- New status `partial` between ordered and received

Purchase ↔ Warehouse integration:
- Purchase::receiveItem(item, qty, warehouse?) — routes through
  WarehouseService::receive: creates batch + receipt event + supplier price row
- Purchase::receiveAllRemaining(warehouse?) — receives all outstanding lines
- Purchase::recomputeStatus() — auto: ordered → partial → received

Old flat markReceived() removed — every receipt now writes batches + ledger.

Filament:
- Purchase list: progress %, partial badge, warehouse picker on form
- ItemsRelationManager: per-line "Recepționează" with qty + warehouse modal,
  qty_received shown as "X.XX / Y.YY" with colour
- PartResource: new PriceHistoryRelationManager (supplier price history)
- SupplierResource: derived columns onTimeRate / avgDeliveryDays / spend(90d)
  + "Rerating" action

Analytics:
- App\Services\Warehouse\SupplierAnalytics (onTimeRate, avgDeliveryDays,
  spend, count, computedRating)
- `suppliers:rate` artisan command + weekly schedule (Mon 04:00)
- Computed rating: 70% on-time + 20% volume + 10% speed bonus

Tests (6 new, all pass):
- Partial receipt of 3/10 → status=partial + 1 batch + 1 price row
- receiveAllRemaining → status=received with received_at set
- Over-receive throws InvalidArgumentException
- Two partial receipts (4+6) → 2 batches FIFO + status=received
- onTimeRate 50% with 1 on-time + 1 late
- computedRating null when <2 deliveries

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-27 19:37:12 +00:00
Vasyka 426156fe45 Stage 5.1 — Warehouse ERP: batches + FIFO + reservations + multi-warehouse 
Schema:
- warehouses (multi-warehouse, code unique per company, is_default)
- part_batches (lot per receipt, qty_in/qty_remaining, buy_price, FIFO-indexed)
- warehouse_events (immutable ledger: opening/receipt/issue/transfer/adjustment/write_off)
- part_reservations (per-WO allocations from specific batches, active/consumed/released)
- companies.default_warehouse_id + parts.qty_reserved

Backfill: 1 default warehouse + 1 opening batch per existing part per company.

WarehouseService:
- receive / issue (FIFO) / reserve / release / consume / transfer / adjust
- DB::transaction + lockForUpdate on batch rows
- InsufficientStockException with requested + available context
- Auto-syncs parts.qty as aggregate cache (source of truth = sum(qty_remaining))

WO integration:
- WorkOrderPart created/updated → reserve from FIFO batches
- WorkOrderPart deleted → release
- WorkOrder status=done → consume reservations into issue events
- WorkOrder status=cancelled → release reservations

Filament:
- WarehouseResource (CRUD)
- BatchesRelationManager on PartResource (FIFO list with qty_remaining + cost)
- "Recepție" action on parts list → calls WarehouseService::receive
- qty_reserved column added on parts list

Tests (8 new, all pass):
- receipt creates batch + event
- FIFO order verified across 3 batches with different received_at
- InsufficientStockException on over-issue
- Reservations block other reservations but don't deplete on-hand
- WO done consumes; WO cancelled releases
- Batches tenant-isolated
- Transfer between warehouses with weighted-avg cost

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-05-27 19:29:19 +00:00