Features

Platform capabilities

Feature categories derived from the ArcaneWaste codebase. No speculative modules—only what exists in routes, models, and services.

Core platform

Multi-tenant companies

▼

What is it?: Each company is a tenant with dashboard access, settings, documents, and SaaS subscription.
Why does it exist?: Operators run isolated businesses on shared infrastructure.
How does it work?: Company model + BelongsToCompany trait; JWT checkType:company middleware.

Unified V1 API

▼

What is it?: All mobile/web clients consume /api/v1 endpoints.
Why does it exist?: Single contract for company, customer, driver, and admin flows.
How does it work?: routes/api.php with grouped middleware stacks.

Catalog & pricing

Asset specifications

▼

What is it?: Rentable dumpster types linked to pricing profiles, taxes, waste types.
Why does it exist?: Orders price from spec + term + promotion—not legacy dumpster tables.
How does it work?: BillingService::calculateBilling requires asset_specification_id.

Payment terms

▼

What is it?: Percentage or fixed upfront amounts snapshotted per order.
Why does it exist?: Companies define how much is due on approval vs later.
How does it work?: OrderPaymentTerm with upfront_amount (MoneyCast).

Promotions & taxes

▼

What is it?: Scoped promotions and tax pivots on pricing profiles.
Why does it exist?: Accurate quotes at place and update time.
How does it work?: OrderPricingSnapshot freezes values at order time.

Orders & billing

Order lifecycle

▼

What is it?: 14+ statuses from pending through completed, rejected, or cancelled.
Why does it exist?: Mirrors real rental operations and payment states.
How does it work?: OrderService transitions + OrderStatusHistory.

Line-item charges

▼

What is it?: Subtotal, tax, discount, grand total stored in cents; breakdown in line items.
Why does it exist?: Audit-friendly billing without denormalized charge columns on orders.
How does it work?: OrderLineItem + OrderPricingSnapshot.

Order change requests

▼

What is it?: Customers request extension, early return, or reschedule.
Why does it exist?: Self-service date changes with company approval and billing preview.
How does it work?: OrderChangeRequestService; is_early_return on orders.

Fleet & locations

Assets & trucks

▼

What is it?: Physical units with operational status, locations, QR codes.
Why does it exist?: Dispatch and approval need know what is assignable.
How does it work?: OperationalStatusEnum; Asset assignable when parked.

Lots & stations

▼

What is it?: Yards and disposal/transfer/recycle stations with addresses.
Why does it exist?: Routing and compliance for driver workflows.
How does it work?: Lot, Station models with lastAddress relations.

Truck type ↔ asset style

▼

What is it?: Compatibility mapping between truck types and asset styles.
Why does it exist?: Ensures assigned equipment can haul assigned assets.
How does it work?: truck_type_asset_style pivot; client-side dispatch filtering.

Jobs & dispatch

Job trees

▼

What is it?: Primary roots (delivery_job, retrieve_job, park_the_truck) with bridge and static children.
Why does it exist?: Field work is a tree, not a flat list.
How does it work?: POST /order/jobs, PUT /order/jobs/{id}, PUT /order/jobs/bulk (id present = update, omitted = create).

Driver-day sync

▼

What is it?: Replace one driver's assignable trees for a date.
Why does it exist?: Dispatcher saves a whole day atomically.
How does it work?: POST /order/jobs/sync. Omitted assignable roots collapse to todo. Locked trees cannot be targeted.

Dispatch context

▼

What is it?: Single API returns today's jobs plus eligible fleet for a date.
Why does it exist?: Company dispatch board without N+1 client calls.
How does it work?: DispatchService::buildContext with optional date param.

Evidence & issues

▼

What is it?: Drivers submit typed evidence and report delay or blocking issues.
Why does it exist?: Proof of work; open blocking issues stop complete (422).
How does it work?: JobEvidenceTypeEnum: image, video, document, signature, text, qr_scan.

People & attendance

Customers & drivers

▼

What is it?: Company-managed roster with activation, leave, attendance.
Why does it exist?: Workforce and customer base tied to tenant.
How does it work?: DriverAttendance, Leave models; dispatch excludes drivers on leave.

Policy violations

▼

What is it?: Demerit points, disputes, company/customer messaging.
Why does it exist?: Enforce rental policies with audit trail.
How does it work?: CustomerPolicyViolation, PolicyViolationDispute.

Payments & wallet

Finix processing

▼

What is it?: Customer order pay, bulk dues, company merchant onboarding.
Why does it exist?: Card payments without Stripe (removed from codebase).
How does it work?: FinixService + Customer/Company FinixController.

Wallet

▼

What is it?: Stored balance with credit/debit via WalletService.
Why does it exist?: Partial payments and refunds without overdraft.
How does it work?: Money in cents; available = balance - locked_balance.

Company subscriptions

▼

What is it?: SaaS plans for platform access via Finix.
Why does it exist?: Gate dashboard mutations when FINIX_SUBSCRIPTION_CHECK enabled.
How does it work?: Subscription morphTo company; check.company.subscription middleware.

Notifications & chat

FCM push

▼

What is it?: Device tokens on User; FcmEvent listener with Android high-priority channel.
Why does it exist?: Mobile alerts for orders, jobs, payments, and chat.
How does it work?: Shared\Notification\FcmEvent + FirebaseNotificationService.

Role-scoped chat APIs

▼

What is it?: Separate company / customer / driver chat controllers under /api/v1/{role}/chats.
Why does it exist?: Each actor only sees allowed chat types and policies.
How does it work?: ChatService + ManagesChatInbox; docs/chat-feature.md.

order_company chat

▼

What is it?: Company agent and customer thread tied to an order.
Why does it exist?: Support without leaving the order context.
How does it work?: POST /{company|customer}/chats/{order}/create.

job_driver chat

▼

What is it?: Driver–customer thread created when an order-linked job starts.
Why does it exist?: Field coordination during delivery / pickup.
How does it work?: StartedListener → ChatService::startJobDriverChat; closed on job complete.

Cursor pagination + Pusher

▼

What is it?: Inbox and messages use limit + cursor; room channel chat-{id} plus list update channels.
Why does it exist?: Mobile-friendly infinite scroll and live badges.
How does it work?: cursorPaginate; events new_message, message_updated, messages_read.

Admin

Admin API

▼

What is it?: Platform CRUD for companies, customers, drivers, assets, orders.
Why does it exist?: Internal operations console backend.
How does it work?: /api/v1/admin with admin middleware.

See it in action

Follow a complete order flow from API request to database persistence.

How it works

Home Features How It Works Architecture Documentation Postman Log in