READY SOLUTIONS PAKISTAN · 3 NOVEMBER 2026
BMS v2
Business Management System — Version 2
Current Modules Enhancement & Upgrade Specification
Single-branch pilot build. Local transaction capture, authenticated cloud replication, management reports and approved controls, purchase evidence, retry/replay and restore reconciliation are implemented. A local cloud keeper is available for testing. Namecheap publication and real two-office acceptance remain pending. Optional enhancements below remain a roadmap.
Operating model
One company → one operational branch/warehouse → multiple users. Defence Road handles sales, purchases, inventory, cash, receipts, payments and returns on a local WAMP server over the LAN, even without internet. City Villas is the management office, with cloud access for supervision, reporting, permissions and approvals. It does not receive an independent sales invoice sequence or stock location.
Operational WAMP server ⇄ authenticated HTTPS synchronization ⇄ central cloud replica ⇄ management office.
Numbering and identity
Default: simple sequential numbers, independent per document type, allocated atomically by the single operational server. Printed numbers never change after synchronization. Record company, branch/warehouse, user, terminal and UUID internally. Multi-branch remains hidden and disabled until configured. Future branches can use numeric branch prefixes without rewriting historical documents. Independent disconnected terminal databases are outside the default model.
Module upgrade scope
| Module | Observed source baseline | v2 enhancement |
|---|
| Dashboard | Role dashboard and business reports | Owner overview, stale-data age, pending sync, exceptions and approval counts |
| Sales | Invoice entry, pricing permissions, thermal bills | Immutable UUID and printed number, revision history, credit and discount approvals, atomic stock/accounting/outbox |
| Purchases | Purchase invoices and supplier balances | Supplier reference checks, controlled revisions and bill evidence; pending attachment work remains separate |
| Products and inventory | Product identifiers, bulk setup, stock and physical counts | Branch ownership, reorder exceptions, adjustment approvals and reconciliation |
| Customers and suppliers | Party limits and balances | Audited limit changes, ageing and management credit controls |
| Cash, bank and expenses | Cash operations and accounting/reporting surfaces | Session close reconciliation, controlled backdated entries and bank workflow audit; verify dedicated bank coverage |
| Accounting | Integrated journals and financial reports | Period locks, balanced replica reconciliation, reversal-only corrections and cloud oversight |
| Users, roles and permissions | Role permissions and company administration | Separate management capability and branch scope, session revocation and offline authorization policy |
| Approvals and audit | Audit logging and role restrictions | Explicit approval state machine, expiring management commands, immutable audit trail; dedicated approval module remains to build |
| Reports | Operational and accounting reports, export and print | Local versus replicated data labels, sync watermark, consolidated reporting and reconciliation |
| Staff and payroll | Existing staff, attendance, payroll and advances | Preserve current behavior; include relevant financial events in later sync coverage |
Synchronization rules
Operational posting and its outbox event commit in one local database transaction. Every event has a UUID, origin node, entity UUID and revision. Cloud receivers enforce tenant binding, deduplicate events and acknowledge only after durable commit. Delivery is at least once; accounting effects must be applied once. Cloud must not independently post branch-owned documents. Management changes return as versioned, auditable commands checked locally against current permissions and business rules. Conflicts enter review; no silent last-write-wins on money or stock.
Use bounded batches, backoff and resumable cursors. Preserve event ordering per entity, expose failures and last-sync time, and reconcile counts, document totals, stock and balanced journals. Attachment transfer follows metadata with content hashes and authorized retrieval. Credentials, access tokens and password hashes must never enter event payloads.
Offline controls
LAN operation must not depend on cloud availability. Staff can continue permitted local operations. Decisions requiring remote approval stay pending unless a specifically authorized offline exception is recorded. Define offline membership grace, session revocation and emergency controls before release. Management reports must identify stale replicas.
Build phases and release gates
- Foundation completed: inspected baseline, isolated branch, specification and transactional capture.
- Local integration completed: stable row identities, atomic sales numbering, trigger capture, permissions and synchronization status.
- Cloud pilot completed: authenticated receiver, replica projections, retries, conflict checks, snapshots and evidence transfer.
- Management pilot completed: freshness-aware dashboard, module reports, owner-approved master controls, command acknowledgements and audit.
- Pilot verification: automated disconnect/reconnect, replay, concurrent saves, restore, evidence and financial reconciliation. Complete a real two-office run and Namecheap checks before production release.
Acceptance requires continued local posting during WAN loss; no duplicate invoices, cash or journals after repeated delivery; no cross-company reads or commands; visible stale management data; and verified restore from private backups.
Deployment and current limitations
Use a separate BMS-v2 WAMP folder and empty test database. Existing BMS and production assets remain in place. Future Namecheap deployment uses a separate subdomain document root and database. No DNS or hosting changes are made by this foundation build.
Open local BMS workspace · Deployment and remaining work