From first setup
to every working day.

This manual covers the Laravel platform and the Flutter app found in this workspace. Source review date: 23 September 2026.

Use the feature instructions below for day-to-day work, chapter 05 for industry workflows, chapter 06 for app screens and builds, and chapter 09 for the complete registered-route and source-action inventory. A source entry records implementation presence; it does not mean every provider, device or deployment was tested.

Architecture and access

The backend uses Laravel ^13.17, PHP ^8.3 and Livewire ^4.4. Tenants share a database: company_id is the tenant boundary and store_id is the branch context. Product/customer identity can be company-wide while stock and operational records use branch scope. Company scoping depends on middleware binding the context; background and platform operations must establish the intended scope explicitly.

The web uses session authentication; tenant API endpoints use the custom AuthenticateTenantApi middleware and user permissions. Store access also checks company membership, assignment and active state. SDUI bootstrap supplies menus, themes, translations, features and schemas to clients. The Flutter app lives in the ignored, separate mobile/ tree, which must be included separately when distributing source. NativePHP desktop support is also present in Composer and the Laravel desktop services; it is a separate client path from Flutter Windows.

First operational setup

1. Complete installation and core activation; configure a plan and the required modules.
2. Create a tenant, verify the owner account and select the business mode.
3. Configure branch details, staff permissions, tax/payment rules and receipt templates.
4. Add catalog products and opening stock; set up supported printers and notifications.
5. Open a register, create a test sale, preview its document and confirm stock/payment results.
6. Verify the online storefront, reminders and client synchronization for the enabled features.

Every workflow below requires its corresponding permission, active subscription where enforced, and module entitlement where applicable. A hidden menu alone is not an authorization rule.

Platform administration

F001. Platform dashboard and core activation

Features: Tenant overview and core license activation.

Instructions: Open /superadmin; review the platform overview; enter the purchased core license through the activation control.

Benefit: Centralizes platform health and activation.

Source: app/Livewire/SuperAdmin/Dashboard.php.

F002. Tenant lifecycle

Features: Tenant search, creation, profile changes, plan assignment, module selection, suspension, activation and expiry extension.

Instructions: Open /superadmin/tenants; create or select a tenant; set its plan and modules; save. Use Suspend, Activate or Extend expiry for the corresponding lifecycle change.

Benefit: Keeps customer accounts and access under platform control.

Source: app/Livewire/SuperAdmin/Tenants.

F003. Subscription plans and quotas

Features: Billing cycle, duration, price, currency, active state, users, devices, storage, branches, invoice/product/staff limits, custom extensions and feature switches.

Instructions: Open /superadmin/plans; create or edit a plan; set limits and included features; save; assign it to a test tenant and verify each intended restriction.

Benefit: Packages the service for different business sizes. Configured limits require enforcement by the relevant operation.

Source: app/Livewire/SuperAdmin/Plans/Index.php.

F004. Activation codes

Features: Generate and revoke subscription activation codes.

Instructions: Open /superadmin/activation-codes; generate a code for the intended plan; deliver it to the customer; revoke unused access when appropriate.

Benefit: Supports provisioned or manually sold subscriptions.

Source: app/Livewire/SuperAdmin/ActivationCodes/Index.php.

F005. Module lifecycle and governance

Features: Browse the vendor catalog, obtain licensed packages, install, activate, revalidate, deactivate, uninstall, prune orphan records and govern registration availability.

Instructions: Open /superadmin/modules; select the package and verify its license; activate; enable it for the tenant and its plan. Review data removal options before uninstalling.

Benefit: Adds vertical workflows while controlling which tenants can use them.

Source: app/Livewire/SuperAdmin/Modules/Index.php.

F006. Platform payment gateways

Features: Gateway configuration and stored credential handling, including webhook secrets.

Instructions: Open /superadmin/payment-gateways; configure the provider offered by this release; save; validate its checkout and callback in the provider test environment.

Benefit: Connects subscription purchases to activation.

Source: app/Livewire/SuperAdmin/PaymentGateways/Index.php.

F007. General, regional and registration settings

Features: Application name/version, minimum client build, currency, language, timezone, country/dial code, registration modes/modules, demo seeding and maintenance mode/message.

Instructions: Open /superadmin/settings; edit General and Regional fields; save; check registration and app bootstrap with a new session.

Benefit: Sets consistent defaults for new customers and clients.

Source: app/Livewire/SuperAdmin/Settings/Index.php.

F008. Branding, appearance and theme customization

Features: Platform name, logo, favicon, authentication banner, primary/sidebar/landing colors, matching palettes and section themes.

Instructions: Open Settings → white-label/appearance controls; upload branding, choose colors and save; inspect sign-in, landing and administrative screens.

Benefit: Presents a consistent brand across surfaces.

Source: app/Http/Controllers/SuperAdmin/ThemeCustomizerController.php.

F009. Landing CMS and Section Studio

Features: Hero text/buttons/banner/highlights/products; trust bar; features; hardware; industry solutions; statistics; about; testimonials; pricing; contact; CTA; downloads; FAQ; section order, visibility and custom content.

Instructions: Open Settings → landing/Section Studio; choose a section; edit its content and visibility; reorder; save; inspect the public landing page.

Benefit: Lets operators maintain marketing content without changing templates.

Source: app/Livewire/SuperAdmin/Settings/Index.php.

F010. Public pages and menu builder

Features: Create/edit/delete public pages, home-page selection, anchor/page/custom URL links, ordering, nesting, target and active state.

Instructions: Open /superadmin/pages to maintain content; open /superadmin/menus to add and arrange links; save and follow each link publicly.

Benefit: Keeps help, company and campaign information discoverable.

Source: app/Livewire/Superadmin/MenuBuilderComponent.php.

F011. Contact inquiries and custom fields

Features: Inquiry detail/status, search, bulk read/replied/delete actions, field creation/edit/deletion/order, default fields and form settings.

Instructions: Open /superadmin/inquiries; configure the intake fields; submit the public form; inspect the resulting inquiry and update its status.

Benefit: Captures structured sales inquiries and tracks responses.

Source: app/Livewire/SuperAdmin/Inquiries/Index.php.

F012. Platform SMTP, social login and push

Features: SMTP settings/test email; social provider configuration; Firebase push credentials, Android configuration, order/invoice channels, sounds, repeats and test delivery.

Instructions: Use the matching Settings tabs or /superadmin/smtp; save provider details; use the test control and verify delivery/sign-in on the target device.

Benefit: Provides reusable communication and authentication services.

Source: app/Livewire/SuperAdmin/Settings/Index.php.

F013. Language administration

Features: Locales, activation, translation editing, new/deleted keys, missing-English-key synchronization and language creation.

Instructions: Open /superadmin/languages; choose or create a locale; edit strings; save; enable the locale and verify a translated screen.

Benefit: Supports localized deployments from a central translation catalog.

Source: app/Livewire/SuperAdmin/Languages/Index.php.

F014. Backups, system policy and audit

Features: Snapshot creation/download/delete, backup policy fields, system settings and audit filters.

Instructions: Open /superadmin/backups for exports, /superadmin/system for policy and /superadmin/audit for activity. Download a snapshot and inspect its contents.

Benefit: Provides export and accountability tools. Snapshots are JSON-table ZIP exports, not a point-in-time restore service.

Source: app/Services/Backup/BackupService.php.

Identity and workspace

F015. Registration, OTP, login and recovery

Features: Store registration, subdomain checks, email OTP/resend, password login, password reset/change, social login and invitation acceptance.

Instructions: Register or accept an invite; complete required OTP verification; sign in; use Forgot password if needed. Set up the server address first in the app.

Benefit: Provides entry and recovery flows for owners and staff.

Source: app/Livewire/Auth.

F016. Staff, roles, permissions and commissions

Features: Invite/resend, role changes, active status, deletion, staff commission rates, role CRUD, permission presets, row/column selection and user overrides.

Instructions: Open /tenant/users; invite staff and assign roles; open Permissions; select only required actions; configure commissions where applicable.

Benefit: Aligns access and sales attribution with staff responsibilities.

Source: app/Livewire/Tenant/Users.

F017. Impersonation and session/device revocation

Features: Authorized switch-to-user workflow, exit impersonation, device listing and revocation.

Instructions: Use the staff switch action where allowed; leave the impersonated session after review. Open /tenant/devices and revoke a retired device.

Benefit: Helps administrators reproduce staff issues and retire sessions.

Source: app/Http/Controllers/Tenant/ImpersonationController.php.

F018. Multi-store management

Features: Branch creation, codes, addresses, tax IDs, receipt/invoice prefixes, active state, primary branch safeguards, staff assignment and store switching.

Instructions: Open /tenant/settings/stores; add a branch within the plan limit; save details; assign staff; switch before recording stock or sales.

Benefit: Shares a company catalog while tracking branch activity separately.

Source: app/Http/Controllers/Api/Tenant/StoreController.php.

F019. Dashboard and POS layout selection

Features: Sales/order/customer/low-stock metrics, charts, receivables shortcuts, date ranges and selectable POS/dashboard layouts.

Instructions: Open the dashboard; select a range; tap a metric or due shortcut; choose the POS layout when launching the register.

Benefit: Moves from a summary to the records needing attention.

Source: app/Livewire/Tenant/Dashboard.php.

Catalog and inventory

F020. Products and identifiers

Features: Product creation/edit/deletion, SKU/item-code/barcode generation and scanning, pricing, images, category/brand/unit association and inventory fields.

Instructions: Open Products or app Inventory; create a product; enter its identifiers and prices; assign classification; save; find it from POS.

Benefit: Maintains one reusable catalog for checkout and ordering.

Source: app/Livewire/Tenant/Products/Index.php.

F021. Variants, modifiers and spice levels

Features: Variant rows, modifier selections, spice options and their price adjustments.

Instructions: Edit a product; add the available option rows; save; select the product in the appropriate POS and verify the resulting line price.

Benefit: Handles product and food customization consistently.

Source: app/Livewire/Tenant/Products/Index.php.

F022. Bulk product import

Features: Template/demo-data download, file selection, import processing and imported-product refresh.

Instructions: Open bulk import; download the release template; populate its columns; import a small sample, review errors, then import the remaining rows.

Benefit: Reduces repetitive catalog entry.

Source: app/Livewire/Tenant/Products/ProductBulkImportComponent.php.

F023. Stock adjustment and branch quantities

Features: Stock adjustments and per-store quantity tracking.

Instructions: Select the active branch; open a product stock adjustment; enter the adjustment and required details; save and verify the branch balance.

Benefit: Keeps physical stock counts aligned with sales records.

Source: app/Http/Controllers/Api/V1/PosSyncApiController.php.

F024. AI product imagery

Features: Image-generation availability, provider configuration and queued product image generation.

Instructions: Configure an available AI provider in platform/tenant settings; open the product image generation control; request an image and review it before use.

Benefit: Assists catalog image preparation; provider configuration and service availability are required.

Source: app/Services/AiImageGeneratorService.php.

F025. Categories, brands, units and suppliers

Features: Independent create/edit/delete catalogs for product classification, measurement and suppliers.

Instructions: Maintain /tenant/categories, /tenant/brands, /tenant/units and /tenant/suppliers; reference those records from products and bills.

Benefit: Reuses consistent names and relationships across inventory and purchasing.

Source: app/Http/Controllers/Api/V1/CatalogAdminApiController.php.

Selling and documents

F026. Retail checkout and cart

Features: Grid/category lookup, scanning, item quantities/removal, quick discounts, keypad/custom items, authorized price overrides, customer selection and quick creation.

Instructions: Open POS; confirm the active branch/register; scan or select items; adjust the cart; select the customer; review totals and checkout.

Benefit: Combines catalog lookup and payment into one cashier workflow.

Source: app/Livewire/Tenant/Sales/Create.php.

F027. Weighing-scale barcodes

Features: Configurable scale prefix and weight/price interpretation, barcode parsing and applying measured quantities.

Instructions: Configure the scale barcode format in settings; scan a sample encoded label; verify product matching, quantity and price before routine use.

Benefit: Avoids retyping quantities for weighed products.

Source: app/Livewire/Tenant/Sales/Create.php.

F028. Held orders, split payments and register gate

Features: Hold a cart, payment rows, register opening and stale-session settlement before checkout.

Instructions: Hold an unfinished order when needed; at checkout select split payment and allocate amounts; complete any required register-opening step.

Benefit: Supports interrupted sales and mixed payment tenders.

Source: app/Http/Controllers/Api/V1/SaleApiController.php.

F029. Sales and invoices

Features: Sales list/search, detail, completion/cancellation, PDF, due filters, custom creation-date ranges and customer delivery.

Instructions: Open Sales; select the filter; open a record; review payment and items; use the permitted complete/cancel or document actions.

Benefit: Provides an auditable view of completed and outstanding business.

Source: app/Livewire/Tenant/Sales.

F030. Quotations

Features: Create/edit/delete/bulk-delete, quick customer, status changes, terms/defaults, PDF, messaging, conversion to sale and opening in POS.

Instructions: Create a quote with customer/items; preview and send; update its status; convert or open it in POS when the customer accepts.

Benefit: Reuses quoted information during checkout.

Source: app/Livewire/Tenant/Quotes.

F031. Invoice and quotation template studio

Features: Document colors, logos, alignment, prefixes, terms, bank/payment details, receipt format and available delivery settings.

Instructions: Open Store Settings → Invoice/Quotation Templates; customize; preview a document with real line items; save.

Benefit: Produces consistent customer documents.

Source: app/Http/Controllers/Tenant/DocumentTemplateController.php.

F032. Unified dispatch and public documents

Features: Preview/action/send sheets, thermal/A4 output, PDF or document link, email, SMS, WhatsApp, custom channels and batch dispatch.

Instructions: Open a document → Share/Send; preview; select recipient/channel and attachment or link; submit and check the returned delivery result.

Benefit: Groups document delivery choices in one workflow. Public links are customer-facing and should be shared deliberately.

Source: app/Http/Controllers/Api/UnifiedDispatchController.php.

F033. Consignment dispatch and reconciliation

Features: Create stock allocations, dispatch goods, record sold and returned quantities, review revenue and finalize to an invoice/sale.

Instructions: Open Consignments; add customer/items; dispatch; reconcile sold/returned quantities; review and finalize.

Benefit: Tracks goods placed with customers before final settlement.

Source: app/Livewire/Tenant/Consignments.

Customers and finance

F034. Customer profiles and loyalty

Features: Customer creation/edit/deletion, search, contact information, loyalty points and manual points adjustment.

Instructions: Open Customers; maintain contact details; use points adjustment with the intended value; verify the updated balance.

Benefit: Keeps sales history and loyalty information attached to the customer.

Source: app/Livewire/Tenant/Customers/Index.php.

F035. Customer credit ledger and settlement

Features: Credit sales, customer ledger, payment entry and settlement.

Instructions: Open a customer → Credit ledger; review outstanding sales; record the payment using the correct amount and method; confirm the remaining balance.

Benefit: Tracks account balances and collections together.

Source: app/Services/Financial/CustomerLedgerService.php.

F036. Cash register and movement slips

Features: Opening balance/denominations, register history, cash movements, closing reconciliation, Z report and movement view/PDF.

Instructions: Open Cash Register; enter opening cash; record movements during the shift; count closing cash; close and review the Z report.

Benefit: Explains differences between expected and counted cash.

Source: app/Livewire/Tenant/Financials/CashRegister.php.

F037. Receivables and reminders

Features: Due lists, payment recording, immediate reminders, scheduled reminders and customer shortcuts.

Instructions: Open Finance → Receivables; choose the due tab/range; record a collection or schedule/send a reminder.

Benefit: Prioritizes collections and keeps follow-up linked to the balance.

Source: app/Livewire/Tenant/Financials/Receivables.php.

F038. Vendor bills and payables

Features: Create/edit/delete bills and record full or partial settlements.

Instructions: Open Finance → Payables; select the vendor and bill details; save; record payments as they occur.

Benefit: Shows obligations and their remaining balances.

Source: app/Livewire/Tenant/Financials/Payables.php.

F039. Payment methods, bank/UPI/Pix and card fees

Features: Method creation/order/activation, bank account details, UPI information, Pix key/merchant settings and debit/credit/installment fee settings.

Instructions: Open Settings → Payments/Financial; configure the desired method; save; preview checkout and validate fee calculations.

Benefit: Standardizes cashier tenders and payment instructions.

Source: app/Livewire/Tenant/Settings/Index.php.

F040. Payment-method ledger

Features: Method-specific transaction history and CSV export.

Instructions: Open the payment method ledger; review the period and entries; export CSV for reconciliation.

Benefit: Reconciles transactions by payment channel.

Source: app/Livewire/Tenant/Financials/PaymentMethodLedger.php.

F041. Tax rules and fiscal payloads

Features: Country rules, default/active rules, rates, subcomponents, tax calculations, invoice payload/QR generation and India GST, ZATCA and Peppol driver classes.

Instructions: Configure tax identity and rules; preview a representative invoice; review payload output with the fiscal integration implementer.

Benefit: Centralizes calculation and payload preparation. Driver output is not proof of government acceptance or live filing.

Source: app/Services/FiscalEInvoicing.

F042. Reports, commissions and targets

Features: Summary, sales, profit/loss, payment methods, till closings, commissions, aging, date presets, CSV/export and target allocation.

Instructions: Open Reports; select report and dates; inspect/export. Open Sales Targets; allocate or split the target evenly; save.

Benefit: Supports performance review and staff goals.

Source: app/Http/Controllers/Api/V1/ReportsApiController.php.

Online storefront

F043. Published catalogs

Features: Product selection, select-all/clear, quick product creation, publish/revoke and public catalog ordering.

Instructions: Open Catalog; choose products; publish and share the generated /c/... link; revoke it when no longer needed.

Benefit: Creates a focused shareable sales catalog.

Source: app/Livewire/Tenant/Catalog/Index.php.

F044. Storefront branding, domains and pages

Features: Banner/auth appearance, tenant domain configuration, categories, menu builder, anchor/custom links, custom pages, order and active state.

Instructions: Open Store Settings → Storefront; configure appearance/domain; create pages and arrange navigation; verify the public storefront URL.

Benefit: Connects the tenant brand and online catalog. DNS and TLS must also be configured for a custom domain.

Source: app/Http/Controllers/Api/Tenant/StorefrontSettingsController.php.

F045. Customer account, addresses and wishlist

Features: Registration/login/logout, profile editing, address create/edit/delete, wishlist toggle/remove, cart calculation and order history.

Instructions: Open the storefront account; sign in; save delivery addresses; add wishlist products; review cart totals and order history.

Benefit: Lets returning customers reuse their profile and selections.

Source: app/Http/Controllers/Api/V1/StorefrontCustomerApiController.php.

F046. Ordering, checkout, verification and tracking

Features: Catalog, order placement, verification-code send/check, coupon validation, payment methods, gateway initiation/verification and tracking code page.

Instructions: Build a storefront cart; select customer/delivery/payment details; complete verification if required; place/pay for the order; retain the tracking link.

Benefit: Connects online customer orders with tenant operations.

Source: app/Http/Controllers/Tenant/StorefrontController.php.

F047. Coupons and promotion management

Features: Create/edit coupons, active status and deletion; validation and usage records.

Instructions: Open Coupons; enter the offer and limits presented by the form; save; test an eligible and an ineligible cart.

Benefit: Applies controlled promotional offers.

Source: app/Livewire/Tenant/Coupons/Index.php.

F048. FAQs, reviews and inquiries

Features: FAQ defaults/create/edit/enable/delete; reviews enabled/approval settings and approve/reject/delete; store inquiry intake.

Instructions: Maintain FAQs; moderate reviews in Reviews; inspect Store Inquiries in the app or corresponding tenant screen.

Benefit: Answers common questions and manages customer feedback.

Source: app/Livewire/Tenant/Reviews/Index.php.

F049. Ecommerce and outbound webhooks

Features: Incoming order normalization and configured outbound event delivery.

Instructions: Configure the integration channel and its authentication; submit a test order/event; verify the resulting tenant record and callback.

Benefit: Connects external commerce systems with the sales workflow.

Source: app/Services/Integrations.

Automation and personalization

F050. Notification feed and alarms

Features: Order/invoice alerts, dismiss/clear-all, sound settings, custom audio and push-device registration.

Instructions: Open notifications to inspect an alert; navigate to its record; dismiss it when handled. Configure sound/repeat behavior in notification preferences.

Benefit: Brings new operational events to staff attention.

Source: app/Http/Controllers/Api/NotificationController.php.

F051. Scheduled, automated and vertical reminders

Features: Scheduled delivery, receivable/customer reminders, vertical reminders, tenant timezone/frequency settings and dispatch deduplication.

Instructions: Configure notification channels and reminder preferences; schedule the event; keep cron/queue workers running; inspect delivery status.

Benefit: Reduces manual follow-up on time-sensitive work.

Source: app/Console/Commands/DispatchAutomatedReminders.php.

F052. Tenant communication channels

Features: Meta/Twilio/HTTP WhatsApp options, Twilio/MSG91/generic SMS, SMTP, webhook channels, custom authentication/headers/payloads/events and test controls.

Instructions: Open Settings → Integrations; configure and enable the channel; save; run its test; select it in document/reminder delivery.

Benefit: Lets tenants use their chosen communication services.

Source: app/Livewire/Tenant/Settings/Index.php.

F053. Navigation, form labels and local appearance

Features: Menu visibility/order/hierarchy, icons/labels, form label customization, dock positioning, theme colors, surfaces and page transitions.

Instructions: Open Navigation or App Preferences; arrange items and choose appearance; save; verify permissions still control visibility.

Benefit: Adapts the workspace to the staff member and business.

Source: mobile/lib/features/settings/screens/app_preferences_screen.dart.

F054. Tenant languages, currency and time

Features: Default store language, phrase overrides/custom phrases, currency symbol/decimals/position, additional currencies and tenant time handling.

Instructions: Open Languages and regional/financial settings; choose defaults and overrides; verify dates and totals on a receipt.

Benefit: Presents transactions in the intended local format.

Source: app/Livewire/Tenant/Languages/Index.php.

F055. Subscriptions and billing documents

Features: Plan selection, activation-code redemption, free activation where offered, Razorpay/Mercado Pago purchase flows and subscription invoice PDF/email.

Instructions: Open Billing/Subscription; select the plan or redeem a code; complete provider verification; download the resulting invoice.

Benefit: Lets tenants maintain their subscription access.

Source: app/Livewire/Tenant/Billing/Index.php.

F056. API keys and demo-data cleanup

Features: Create/toggle/revoke tenant keys, API integration settings and tenant sample-data removal endpoint.

Instructions: Open API settings to issue a scoped integration credential; retire unused keys. Use demo cleanup only after reviewing the sample records it targets.

Benefit: Supports integrations and transition from evaluation data.

Source: app/Http/Controllers/Api/V1/TenantDemoDataController.php.

Industry and app coverage

Restaurant, pharmacy, salon, repair, service orders and lead CRM are documented individually in chapter 05. Flutter screen families, shared controls and all Dart source surfaces are listed in chapter 06. The complete technical inventory records every registered route and public action found during this review, including compatibility aliases and packaged-module sources.

Verified release requirements

The Dart lower bound alone does not guarantee compatibility with the installed Flutter SDK and locked plugins. Resolve the supplied lockfile, run flutter doctor -v and build the intended target. Do not copy an arbitrary Flutter 3.24/Gradle version into this release.

Server preparation

Choose a supported Linux distribution, such as your managed Ubuntu server release, and install PHP 8.3 or a version allowed by the lockfile. Distribution package availability varies. Laravel 13 requires at least PHP 8.3: official Laravel releases.

Enable extensions needed by Composer and the installer: BCMath, Ctype, cURL, DOM/XML, Fileinfo, GD, Intl, JSON, Mbstring, OpenSSL, PCRE, PDO with the database driver, Tokenizer and ZIP. Some are built into PHP rather than installed as separate packages. Verify the production host with:

php --version
php -m
composer check-platform-reqs --no-dev

Size CPU, memory, disk and worker concurrency from measured tenant count, product volume, peak checkout traffic, PDF/image jobs and retention needs. The code does not establish a universal tenants-per-server guarantee. Keep disk space for uploads, exports, logs and release rollback; test peak behavior before choosing a commercial capacity limit.

Network and provider dependencies

Provide HTTPS access for web/app clients, DNS/TLS for configured tenant domains, outbound access to the license authority and selected payment/message/AI providers, and the SMTP or webhook access required by the configured integrations. Network printers need connectivity from the client device to the printer. Firebase push and hosted checkout require their own provider setup.

Windows prerequisites and Laravel production deployment provide the upstream environment instructions. No OS package installation or service reconfiguration was performed while preparing this documentation.

3.1 Prepare a new installation

Extract the purchased release or clone the real private repository into the chosen application directory. The following examples assume /var/www/saas; replace it with your actual deployment path. Configure Nginx's document root as /var/www/saas/public, HTTPS, and the matching PHP-FPM socket. Laravel's deployment documentation provides the server configuration reference.

For a new installation only, prepare the environment before running Composer scripts:

cd /var/www/saas
cp .env.example .env

Edit .env using installation-specific values. These are placeholders, not usable credentials:

APP_NAME="Zoom Sales CRM & Inventory"
APP_ENV=production
APP_DEBUG=false
APP_URL=https://saas.example.com
DEMO_MODE=false

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=metroretail_core
DB_USERNAME=metroretail_app
DB_PASSWORD="REPLACE_WITH_A_GENERATED_PASSWORD"

LICENSE_SERVER_SECRET="REPLACE_WITH_THE_AUTHORITY_SHARED_SECRET"
LICENSE_SERVER_TIMEOUT=10

Provision the database and its application user separately. Keep .env outside the public document root. Use the same PHP release for CLI, PHP-FPM and Supervisor.

composer install --no-dev --optimize-autoloader
composer check-platform-reqs --no-dev
php artisan key:generate
npm ci
npm run build
php artisan storage:link

Give the service account write access to storage, bootstrap/cache, and any configured module-installation directories. Do not regenerate APP_KEY or overwrite .env when upgrading an existing installation.

3.2 Complete the installer

Open /install on the new host and complete requirements, environment, migrations, administrator account and finalization. The administrator step verifies the core purchase key with the license service. Finish the wizard so the application's installation state is recorded; migrations alone do not complete installation.

For an existing installation, back up the database, uploaded files and environment before applying release migrations. The database seeder creates platform defaults, landing content and permissions; it adds demo tenants when DEMO_MODE=true. Review seeders before running them against an established customer deployment.

php artisan migrate --force
php artisan optimize:clear
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan queue:restart

The draft's LICENSE_VERIFICATION_HOST and LICENSE_KEY variables are not read by this backend's license configuration. The authority URL is fixed in config/services.php; the purchase key is entered through the activation/installation workflow.

Commercial rollout instructions

1. Set actual plan prices, durations, branch allocations and included features in Superadmin Plans.
2. Configure license activation, gateway callbacks, SMTP, notifications and the selected module entitlements.
3. Create an evaluation tenant with an owner and a restricted staff account. Verify a branch switch and permission denial as well as successful sales.
4. Exercise products, checkout, stock, receipts, returns/reconciliation where offered, collections, exports and the chosen industry workflow.
5. Configure scheduler/queues as described in chapter 04, and test backup recovery using the infrastructure backup procedure.
6. Distribute the correct Android/Windows client, its dependencies and this manual; record the release and signing ownership.

Proposed service packages

These are service-delivery proposals from the brief, not enforced license rights or promises made by the source code. Confirm the purchased license and agreed delivery scope before offering them commercially.

Nginx deployment

Point the domain to the server, install a certificate for that hostname and expose the application's public/ directory. The project root contains private configuration and must not be the web root. Adapt this example to your path and PHP-FPM socket; certificate provisioning is separate.

server {
    listen 443 ssl;
    server_name saas.example.com;
    root /var/www/saas/public;
    index index.php;
    ssl_certificate /etc/letsencrypt/live/saas.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/saas.example.com/privkey.pem;
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ ^/index\.php(/|$) {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        internal;
    }
    location ~ \.php$ { return 404; }
    location ~ /\.(?!well-known).* { deny all; }
}

Use a separate HTTP virtual host for certificate challenges and HTTPS redirection according to your certificate client's instructions. Validate the effective configuration with nginx -t before reloading. The Laravel deployment guide is the upstream reference for production routing.

Tenant subdomains and custom domains

1. Configure tenant slug/domain in the tenant's settings.
2. Point its DNS record to the intended application ingress.
3. Configure a virtual host and TLS certificate covering that hostname; a platform wildcard does not cover unrelated customer domains.
4. Open the URL and confirm the expected tenant storefront, login, asset URLs and account callbacks.
5. Verify generated invoice links, social login redirects and gateway return URLs use the intended HTTPS origin.

DNS and TLS are infrastructure tasks. Saving a domain name in the application does not issue a certificate or create DNS records automatically.

Apache and reverse proxies

For Apache, use public/ as DocumentRoot, permit the application's rewrite rules and configure its PHP handler and certificate. Behind a reverse proxy, configure trusted proxy behavior and forwarded scheme/host handling for your topology. Test redirects and secure cookies through the real public address.

Public assets and documentation

Run php artisan storage:link for configured public uploads and build the Vite manifest before opening the app. Keep .env, logs, backup exports and signing files private. The documentation portal is served from /documentation/; /documwnation/ remains the existing compatibility copy. Both use the same existing chapters and SVG assets.

Scheduled commands found in this release

Schedules are defined in routes/console.php. They use overlap locks; selected tasks also use onOneServer(). Configure a shared lock-capable cache for multiple scheduler nodes. The code also contains repair-reminder, ledger-backfill, landing-content and color-setup maintenance commands; they are not all scheduled automatically.

Install the scheduler

Under the application service account, set the actual deployment path and PHP binary:

* * * * * cd /var/www/saas && /usr/bin/php artisan schedule:run >> /dev/null 2>&1

Inspect the registered schedule with php artisan schedule:list. Run only one intended scheduler topology and verify clock/timezone configuration. A minute tick does not mean every reminder is due every minute.

Queue processing

Jobs include product image generation, automated reminder delivery, tenant sample-data seeding and desktop sync cycles. Configure the asynchronous connection before starting workers; the sync connection executes inline.

Example Supervisor program for the default queue:

[program:metroretail-default]
directory=/var/www/saas
command=/usr/bin/php /var/www/saas/artisan queue:work --queue=default --sleep=3 --tries=3 --timeout=90
user=www-data
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
redirect_stderr=true
stdout_logfile=/var/www/saas/storage/logs/default-worker.log
stopwaitsecs=3600

Replace the path/account and include each queue actually used. This release already schedules a short-lived notifications worker; if adopting a resident notifications worker, review that schedule as part of the deployment configuration. Keep the connection retry interval longer than the worker timeout, with room for long image/PDF/provider operations. Restart workers after deployment using php artisan queue:restart.

Delivery workflow

Configure and test SMTP/SMS/WhatsApp/webhook or custom notification channels; save tenant preferences and reminder timing; schedule a test reminder; inspect its dispatch record and recipient delivery. A queued event, accepted provider request and final message delivery are distinct stages.

Inspect failed jobs and application logs before retrying. Preserve idempotency identifiers when diagnosing duplicate requests. Never delete pending client sales to clear a sync warning.

How a module becomes available

The platform has a module registry/catalog, package installer and subscription entitlement service. Installed code, active platform license, tenant module selection, subscription feature entitlement and user permissions all affect availability. The plan can expose an extension without making it a registration operating mode: the lead-management manifest is an extension with registration_allowed=false.

1. Superadmin opens Modules and obtains/installs the purchased package.
2. Verify and activate the module, then enable the intended plan/tenant access.
3. Tenant selects its available operating mode and assigns staff permissions.
4. Refresh app bootstrap so its menus, screens and feature flags are current.
5. Complete the workflow below with a test record before live use.

V01. Restaurant POS, floors and tables

Open: /tenant/restaurant/pos; /tenant/restaurant/tables.

Features: Floor and table creation/edit/deletion; table status; dine-in/takeaway service types; seat selection; variants, modifiers and spice levels; price override; customer picker/quick creation; split payments; transfer table; kitchen dispatch; bill settlement; document delivery.

Instructions: Create floors and tables; choose service type/table; add seats and customized items; send the order to the kitchen; review table changes; select customer and payment; settle the bill and share the receipt.

Benefit: Keeps seating, kitchen preparation and payment connected.

Source: app/Livewire/Tenant/Restaurant/Pos.php.

V02. Kitchen tickets, KDS and QR table ordering

Open: /tenant/restaurant/kds; table QR action.

Features: KOT print views, preparation/ready/served transitions, cancellation, dismissible alarms, elapsed-time chips, QR stand/card and public token-based table ordering.

Instructions: Open KDS; select a ticket and mark its preparation stage; print the kitchen slip if needed; use the table QR card for customer ordering; mark served once delivered.

Benefit: Gives kitchen and floor staff a shared preparation queue.

Source: app/Http/Controllers/Tenant/Restaurant/TableOrderController.php.

V03. Pharmacy batches, prescriptions and checkout

Open: /tenant/pharmacy; /tenant/pharmacy/batches; /tenant/pharmacy/prescriptions.

Features: Batch creation, batch barcode, expiry information, stock adjustment, returns, prescription intake/attachments, dispense/cancel actions, prescription checkout sheets and pharmacy product search.

Instructions: Activate the pharmacy module; create products and batches; record expiry/quantity; capture a prescription and its attachment; review the selected batch and dispense through the prescription/POS checkout; inspect stock and sale results.

Benefit: Links dispensing records to batches and prescription intake. These records do not establish clinical validation or regulatory certification.

Source: app/Http/Controllers/Api/V1/PharmacyApiController.php.

V04. Salon calendar, specialists and services

Open: /tenant/salon; /tenant/salon/stylists; /tenant/salon/services.

Features: Day navigation, service categories, service cart, booking creation, appointment availability/status, specialist selection/activation, service creation/edit/delete and salon checkout.

Instructions: Activate the salon module; create services and active specialists; select date/services/customer; check available appointment slots; book; update status and checkout when the service is delivered.

Benefit: Connects appointment planning with the service catalog and billing.

Source: app/Http/Controllers/Api/V1/SalonApiController.php.

V05. Repair intake, diagnosis and settlement

Open: /tenant/repair; /tenant/repair/tickets; /tenant/repair/categories.

Features: Dashboard statistics, device categories/defaults, ticket intake, status transitions, technician assignment, diagnostic checklist, parts add/remove, labor charges, share/dispatch, settlement and ticket deletion endpoint.

Instructions: Create a device category and its checklist; intake the customer/device; assign a technician; record diagnosis, parts and labor; update the ticket status; collect payment through checkout and share the ticket details.

Benefit: Traces a repair from intake through completion and payment.

Source: app/Http/Controllers/Api/V1/RepairApiController.php.

V06. Repair customer portal and reminders

Open: /portal/repair/{ticket_number}.

Features: Customer-facing ticket progress page, ticket notifications and repair reminder command.

Instructions: Use the ticket share/dispatch action to send its tracking link; verify the customer can see the intended progress; configure reminder delivery channels and the relevant job schedule.

Benefit: Reduces repeated progress enquiries. The current portal is login-free; handle its link as customer information.

Source: app/Http/Controllers/Tenant/RepairPortalController.php.

V07. General service orders and warranty workflow

Open: /tenant/service-orders.

Features: Create/edit/view/delete orders, customer selection, parts search/add/remove, total calculation and lifecycle status updates.

Instructions: Open Service Orders; select the customer and service details; add parts; review totals; save; update status as work progresses.

Benefit: Tracks general service work separately from ordinary retail cart entries.

Source: app/Livewire/Tenant/ServiceOrders/Index.php.

V08. Lead management and follow-ups

Open: /tenant/leads and licensed lead-module navigation.

Features: Lead capture/list/detail/update/delete, pipeline/source attribution, activity creation/completion, follow-up listing, reminders, customer provisioning and quotation/invoice linking declared by the package.

Instructions: Enable the leadmanagement extension for the plan/tenant; capture a lead and source; record its next activity; complete follow-ups; link the corresponding quote/invoice or customer as the opportunity progresses.

Benefit: Connects pre-sale follow-up with customer and sales records.

Source: module-packages/leadmanagement/module.json.

Server-driven UI contract

GET /api/app/bootstrap supplies the module list/active module, available modes, active features, menu structure, screen directory, schema contract, UI schema, translations, theme and configuration. POST /api/app/mode switches to an available mode and returns updated navigation. The Flutter component registry prefers registered native screens, then explicit endpoints, then module screens and dynamic-schema fallback.

Schemas can describe containers, headings/text, inputs, choices, lists/tables, catalog/cart controls, buttons, sheets, navigation and actions supported by the parser. A new layout composed of existing supported components can be delivered by the server. New native capabilities, unknown components or incompatible schema changes can require a client release; do not promise every future module works without an app update.

Use the package's manifest/navigation and schema validation when extending a module. Preserve existing endpoint aliases for installed clients. Unsupported UI must be tested on the minimum supported app build.

Packaged module manifest inventory

The following flags/navigation labels are read directly from every package manifest in this workspace. Manifest presence does not prove that the package is currently installed or enabled for a customer.

Lead Management System

Package leadmanagement; version 1.2.0; layout standard_grid.

Feature declarations:

• has_leads: true.
• has_activities: true.
• has_due_reminders: true.
• has_quotations_linking: true.
• has_invoices_linking: true.
• has_customer_autoprovision: true.

Navigation:

• Lead Management: lead_ops.
• Lead Dashboard: /api/tenant/lead-module/views/dashboard.
• Capture Lead: /api/tenant/lead-module/views/create-lead.
• Leads Pipeline: /api/tenant/lead-module/views/leads.
• Follow-ups & Activities: /api/tenant/lead-module/views/activities.
• Lead Sources: /api/tenant/lead-module/views/sources.

Pharmacy

Package pharmacy; version 1.0.0; layout standard_grid.

Feature declarations:

• has_barcode_scanner: true.
• has_expiry_tracking: true.
• has_due_reminders: true.

Navigation:

• Pharmacy: pharmacy_ops.
• Pharmacy Dashboard: /api/tenant/pharmacy-module/views/dashboard.
• Drug Batches & Expiry: /api/tenant/pharmacy-module/views/batches.
• Prescriptions: /api/tenant/pharmacy-module/views/prescriptions.

Repair Technician

Package repairtechnician; version 1.0.0; layout repair_kanban.

Feature declarations:

• has_barcode_scanner: true.
• has_due_reminders: true.
• has_checklist: true.

Navigation:

• Repair: repair_ops.
• Repair Dashboard: /api/tenant/repair-module/views/dashboard.
• Repair Tickets: /api/tenant/repair-module/views/tickets.
• Device Categories: /api/tenant/repair-module/views/categories.

Salon & Bookings

Package salon; version 1.0.0; layout service_booking_list.

Feature declarations:

• has_appointments: true.
• has_due_reminders: true.
• has_staff_selector: true.

Navigation:

• Salon: salon_ops.
• Salon Dashboard: /api/tenant/salon-module/views/dashboard.
• Appointments: /api/tenant/salon-module/views/appointments.
• Service Catalogue: /api/tenant/salon-module/views/services.
• Stylists & Specialists: /api/tenant/salon-module/views/stylists.

The client source is present in mobile/ as a separate ignored source tree. Its package is zoom_pos_mobile, version 1.0.5+7, with Dart constraint >=3.4.0 <4.0.0. This chapter is based on the actual client files.

Initial setup and sign-in

1. Launch the client and enter the backend HTTPS address on Server Address.
2. Save and inspect the license-verification result; resolve network/domain/entitlement errors before proceeding.
3. Sign in, register a store or use password recovery as appropriate; complete OTP where required.
4. Select an assigned active store. Review bootstrap branding, available menus and subscription access.
5. Configure the printer and app appearance; verify a small sale and synchronization.

The server-address license flow is implemented in core/security/license_security_engine.dart. It normalizes the URL, signs server_url|timestamp|platform using HMAC-SHA256 and sends the signature in the JSON body to the reconstructed endpoint. Chapter 08 distinguishes this client handshake from backend purchase verification.

App feature families and instructions

The native app screens below complement the Laravel workflows in chapter 00. Server-driven pages provide additional module and settings surfaces.

Personalization and desktop behavior

Open App Preferences to select brand color, drawer/canvas surfaces, dashboard layout, system/light/dark theme, page-transition style and dock position (left, top, right or bottom). Reset individual overrides or all colors to follow defaults. Navigation settings also expose ordering/hierarchy and menu configuration. Some preferences are local; tenant branding changes can be pushed to the backend.

Desktop widgets provide a content area, title/chrome, status bar and window-close guard. Verify closing/logout behavior on the intended desktop build. Adaptive sheets, loading/error views, image fallbacks, barcode scanning, PDF preview and unified document dispatch are shared controls used throughout the screens.

Build and distribute the client

Run inside mobile/, not the Laravel root:

cd mobile
flutter doctor -v
flutter pub get
flutter build apk --release --split-per-abi
flutter build appbundle --release

Android configuration currently uses application ID/namespace com.zoomnearby.zoompos, Java 17 and minimum SDK 23. Compile/target SDK versions follow the Flutter build configuration. Configure the release keystore using the supported android/key.properties or release environment variables. Keep signing credentials private. Rebranding must update the identifiers, displayed names, icons and provider registrations together.

For Windows, use Windows with Visual Studio's Desktop development with C++ tools and SDK, then run flutter build windows --release. Package the complete release directory and required runtimes. See Windows setup and Windows distribution.

For web, run flutter build web --release and deploy its generated web bundle with appropriate routing and backend connectivity; see web deployment. Review target/plugin compatibility before promising iOS, Linux or macOS support; the presence of Flutter source is not evidence of a tested signed release on every platform.

Release verification

Verify server setup, login/OTP, tenant/store switching, permissions, checkout, invoice dispatch, one offline sale and its sync, notification delivery and the target printer. Check a restricted staff account as well as an owner. This documentation update does not compile or distribute new app binaries.

Complete Flutter source-surface inventory

Every Dart file under mobile/lib is included below, grouped by feature or core area. This includes shared widgets and alternate/legacy surfaces so that smaller capabilities remain discoverable. A file entry is source coverage, not proof it is reachable in every build. User instructions are in the feature families above and chapters 00, 05 and 07.

Local storage and synchronization

The Flutter app uses SQLite on supported mobile platforms, JSON-file storage on desktop and a preferences-backed JSON path for web. Cache buckets store lists/details; outbox_sync stores pending sales and outbox_mutations stores other queued writes. Scope-aware cache naming and active store context must be preserved when switching accounts or stores.

The sync engine pushes queued mutations through its batch endpoint and queued sales through its sales-push endpoint, then refreshes catalog/deltas. It exposes pending counts, online/offline/sync/error states, failed-item retry and conflict history. Mutation coalescing can replace repeated local edits and eliminate a create followed by delete before upload. The server's idempotency handling helps prevent reapplication of supported operations; do not describe this as an unconditional zero-duplicate guarantee.

Supported mutation mapping found in the client

The batch builder maps products, customers, categories, brands, suppliers, units and quotations into typed arrays, with deletion mappings also including tax rules. It separately maps stock adjustments and customer payments. Unknown entity writes go into a generic mutations field; the code comments state that this generic replay path is not fully implemented server-side. Do not promise every screen or action is available offline.

Instructions for an offline shift

1. Sign in and synchronize the intended tenant/store while online; confirm required products and payment settings are cached.
2. Create an offline sale using a workflow verified for this release. Keep the local transaction and outbox intact.
3. Check the pending count/status badge. Restore connectivity and request synchronization.
4. Inspect failed items and conflict history; retry only after resolving the reported problem.
5. Compare the server sale, stock and payment result with the local receipt before closing the shift.

Cached lists can be older than server data. Provider payments, OTP, license checks, server PDF generation and messaging can require connectivity even when catalog browsing works offline.

NativePHP desktop synchronization

The Laravel desktop path has its own DesktopSyncEngine, client, bootstrap/session services, sync job and Livewire status/printer settings. Legacy api/mysql.php, api/auth.php, api/subscription.php and api/platform_admin.php routes support older clients. Treat these as a separate compatibility layer from Flutter's local database and outboxes.

Hardware and printing instructions

Preview invoice/quotation or KOT before printing. Check logo, paper width, tax/payment details, long item names, language characters, cut and drawer behavior on the actual hardware. Bluetooth permissions, code pages and device drivers differ by platform. Web printing does not automatically provide the same direct Bluetooth access as native mobile.

Troubleshooting sync and hardware

For pending sync, check connectivity, authentication, store access, API response and conflict log. Preserve unsent transactions before reinstalling or clearing storage. For blank/garbled receipts, check paper width, character support and image rendering. For an unreachable printer, test the POS device's own network path. For duplicate KOTs, inspect whether the action was submitted more than once before retrying.

Backend purchase/license verification

The backend CustomLicenseServerClient posts to the fixed authority https://license.zoomnearby.com/api/verify.php with X-Server-Secret and JSON fields license_key, product_slug, domain. It reads status, message, expires_at and optional plan. Other operations call api/catalog.php, api/download.php and api/issue.php.

Configure LICENSE_SERVER_SECRET and optional LICENSE_SERVER_TIMEOUT in the server environment. LICENSE_VERIFICATION_HOST and LICENSE_KEY are not the configuration contract here. The authority URL is fixed in config/services.php. Enter the purchase key through installation or module activation. Keep the authority secret on the server.

A failed transport or non-success HTTP response is a failed verification in the client. Periodic license checking is a separate scheduled policy; review CheckLicenseStatusCommand for its failure-streak and deactivation behavior. An unreachable authority is not a successful activation.

Flutter server-address handshake

The actual Flutter implementation reconstructs the endpoint from obfuscated byte arrays and sends:

{
  "server_url": "https://saas.example.com",
  "platform": "android",
  "timestamp": 1790121600,
  "signature": "HMAC_SHA256_HEX_PLACEHOLDER"
}

The signature input is the normalized URL, Unix timestamp and platform joined with |. The request uses JSON headers and X-Client-Platform; the signature is in the body. license_security_engine.dart has a 15-second request timeout and handles redirects, network, TLS, server and invalid-format errors. It rejects an HTTPS-to-HTTP downgrade. Do not substitute the older documentation's nonce or X-Signature example for this actual contract.

The server-address screen accepts a result with code=200 and status=authorized, stores the returned license_token in preferences and proceeds. That storage path does not establish encrypted token storage. XOR obfuscation does not make an embedded client signing key secret. Backend license verification and this client handshake are separate flows and must both match the deployed authority.

Authorization and tenancy

Tenant sessions and API keys establish company context. Branch resolution checks ownership, active state and staff assignment. Role/permission checks, subscription gates, operating-mode/vertical gates and module entitlements constrain operations. Administrative routes use the platform guard. Public storefront, table QR, invoice/quote links and repair-tracking routes have separate access semantics; do not describe every public document link as a signed or expiring link unless its implementation does so.

The source includes OTP services, password recovery, invitation acceptance, social authentication, device revocation, demo-mode modification guards, maintenance checks and audit models. Configure the applicable feature, verify both allowed and denied operations, and review logs without distributing credentials.

Entitlements and commercial promises

A license purchase, active module, plan feature, quota, user permission and client capability are distinct checks. A Regular/Extended label does not itself prove that turnkey rebranding, compiled binaries or hands-on support is included; those are contracted service deliverables. The proposed packaging appears in chapter 02. Avoid claims of regulatory certification, unbreakable client licensing or unlimited offline access that the code does not establish.

Common problems and resolution

API usage and response examples

Use HTTPS with Authorization: Bearer <tenant-user-token> and Accept: application/json. JSON requests also need Content-Type: application/json. These examples require an authenticated user with the relevant permissions; a company-only integration credential is not a substitute for every user operation.

9.1 Switch active store

POST /api/v1/tenant/stores/switch

{"store_id": 2}

Illustrative response excerpt; the actual resource includes additional branch fields and a store alias:

{
  "success": true,
  "message": "Switched to Zoom Sales CRM & Inventory North successfully",
  "current_store": {
    "id": 2,
    "name": "Zoom Sales CRM & Inventory North",
    "branch_code": "BLR-02"
  },
  "current_store_id": 2
}

The controller checks stores.view, tenant ownership, staff assignment and active status, then persists current_store_id on the user. Unauthorized, missing or inactive branches produce errors rather than a successful context switch.

9.2 List sales

GET /api/v1/tenant/sales

Example: /api/v1/tenant/sales?store_id=2&filter=custom_date&start_date=2026-09-01&end_date=2026-09-23.

Illustrative response excerpt; sales aliases data, and additional pagination and sale fields are returned:

{
  "success": true,
  "data": [
    {
      "id": "1048",
      "server_id": 1048,
      "invoice_number": "POS-82F054EF",
      "customer_name": "Example Customer",
      "total_amount": 12.98,
      "due_amount": 0,
      "payment_status": "paid",
      "created_at": "2026-09-23T00:05:00+00:00"
    }
  ],
  "meta": {"total": 1, "current_page": 1, "last_page": 1, "per_page": 20}
}

id is serialized as a string and can be the external sale ID; server_id is the database ID. Monetary fields shown here are JSON numbers. Example records are fictional.

Coverage and how to use this inventory

The route catalog below is generated from php artisan route:list --json for this installation, including compatibility aliases, public endpoints and framework/vendor routes. Methods and middleware are copied from registered metadata. Route presence is not a live endpoint test or a complete payload specification.

For each operation: locate its controller action, inspect validation and middleware, use the appropriate session or user-bound API credential, select the intended store, supply the required fields, submit once and inspect the response. Web mutations also require the applicable CSRF/session handling. For the detailed customer workflows, follow chapters 00 and 05.

Public actions and UI fields are separately inventoried so that actions performed through Livewire or package code are not omitted just because they lack an individual HTTP route. Lifecycle/helper methods and state fields are labeled as source references, not advertised as independent customer features. All Flutter Dart surfaces are inventoried in chapter 06.

Coverage snapshot: 1,355 registered route entries; 598 distinct route actions; 273 Flutter Dart source files.

Registered route catalog