Stable-release branch decision record
Multi-branch POS and franchise evaluation
Posnic v1.3.0 contains inspectable branch, tenant, dashboard and optional-sync paths. It is not presented here as proof of a completed franchise rollout, private gateway, two-device branch test, stock transfer, central price push or reconciled consolidated dashboard. Accept the exact branch workflow before rollout.
Reviewed 18 Aug 2026 at v1.3.0 commit b531ef4.
Inspect the interface without treating it as branch proof
These are real Posnic screens with sample data. Neither capture came from a reconciled two-branch run, franchise customer or accepted cloud deployment.
What the tagged public source establishes
The exact tag and lockfiles were reproduced on Microsoft Windows NT 10.0.26200.0 with Node.js 24.19.0. The selected source tests support narrower branch and continuity questions; they do not replace a live multi-branch acceptance run.
| Evidence path | Observed result | Useful branch question | Boundary |
|---|---|---|---|
| Branch model and access source | Branch model, route, validation, repository and service suites passed | Can each till and user retain an approved branch identity and scope? | Source and mocked tests do not prove two connected production branches. |
| Branch access sync tests | Selected branch-access cases passed | Do branch access fields preserve the expected branch relationship under tested transformations? | No real gateway or delayed cross-device delivery was exercised. |
| Durable sync outbox | Selected outbox tests passed | Can a local change be prioritized and retained for a later sync attempt? | Queue code does not prove remote receipt, ordering, idempotency, conflict resolution or catch-up. |
| Published branch and sync contract | The tag documents branch and global collection scopes | Which data is intended to be branch-scoped or tenant-wide? | The private gateway was not present in the public tag and was not reviewed. |
| Tenant, dashboard, migration and backup tests | 621 tests passed; 7 real-DB tests skipped | Do selected tenant names, branch filters, dashboard paths, migration rules and backup boundaries behave in the tested source? | The skipped database cases and every live branch outcome remain unproved. |
Reproduction boundary: 35 desktop, migration and backup tests passed in 2.813 seconds. 586 API tests passed in 16 suites in 8.868 seconds; 7 real-database isolation tests did not run because CI_MONGODB_URI was not supplied.
Eight outcomes this evidence does not prove
Two live branches
No two physical tills at separate branches completed a representative opening-to-close day in this review.
Tenant isolation on a real database
Seven selected real-database isolation cases were skipped. Mocked and source tests must not be described as the missing database result.
Private gateway operation
The public tag documents an optional sync contract, but the private gateway implementation, provisioning and production monitoring were not reviewed.
Outage catch-up and conflicts
No measured backlog drain, duplicate, delayed update, replay, deletion conflict or simultaneous branch edit was accepted.
Consolidated reporting
No owner dashboard was reconciled to accepted branch sales, returns, payments, stock, cutoff times and timezones.
Stock transfer and central prices
No complete source-to-destination transfer or centrally approved price propagation path was established.
Franchise ordering and payments
No franchisee order network, royalties, settlement, bank reconciliation or payment-provider outcome was accepted.
Production dependency approval
The lockfiles reported 27 npm audit findings during reproduction. Severity is not exploitability, but qualified review and remediation ownership are required before rollout.
Run one representative branch scenario before rollout
The downloadable record leaves every observation, evidence, owner, review, decision and follow-up field blank. Use real branch identifiers, devices, users, products, tenders, outages and cutoff rules.
| Stage | Run with representative evidence | Retain before approval |
|---|---|---|
| 1. Scope | List legal entities, branches, warehouses, devices, users, timezones and reporting cutoffs. | Approved branch register, responsibility map and written system boundary. |
| 2. Identity and access | Bind each test till and user to the intended branch, then attempt an unauthorized cross-branch read and write. | User, device, role, branch and audit evidence including rejected access. |
| 3. Sales, stock and payments | Run a sale, return, correction, stock count and provider reconciliation at each branch. | Transaction IDs, physical quantities, POS reports, provider evidence and bank totals. |
| 4. Shared and local data | Exercise catalogue, price, discount, tax and branch-specific exceptions. | Source of truth, propagation rule, approvals, timestamps and discrepancy record. |
| 5. Outage and recovery | Interrupt external connectivity, create approved local work, reconnect and inspect queue, duplicates, conflicts and alerts. | Before/after counts, oldest pending item, recovery timing, retry evidence and owner sign-off. |
| 6. Close and restore | Reconcile consolidated reports, create a backup, restore to a test environment and repeat branch checks. | Branch and consolidated totals, restore evidence, unresolved differences and retest decision. |
Use independent controls for the acceptance decision
These sources frame continuity, access, traceability and payment questions. They do not certify Posnic or replace the business's technical, security, accounting and payment review.
Contingency planning
Read NIST SP 800-34 Rev. 1 for business impact, recovery priorities, testing and plan maintenance.
Access and audit controls
Read NIST SP 800-53 Rev. 5 for least privilege, separation of duties, audit, contingency and system-integrity control families.
Location and movement traceability
Read the GS1 Global Traceability Standard for identifying locations, events, movements, responsibilities and shared data.
Payment responsibility
Read PCI SSC merchant resources to identify the actual payment system, provider, data flow, controls and qualified support.
Keep franchise and branch questions with the right owner
| Need | Use this owner | Reason |
|---|---|---|
| Generic branch identity, access, sync, reports and continuity | This multi-branch POS guide | It owns the branch acceptance decision and the explicit live-system gaps. |
| Restaurant franchise menu, KOT and table service | Restaurant POS evidence | Restaurant operations need a complete shift test in addition to branch controls. |
| Migration from independent tills | Multi-outlet migration checklist | It covers preparation and rollback questions without claiming the migration succeeded. |
| Exact outage behavior | Offline POS evidence | Local service, device, power, network and payment failures have different boundaries. |
| Exact devices at every branch | POS hardware compatibility | Printer, scanner, drawer, scale and display acceptance is model and setup specific. |
Multi-branch POS questions
What multi-branch evidence exists for Posnic v1.3.0?
The reviewed tag contains branch models, routes, validation, branch access fields, dashboard filters, tenant context, a durable sync outbox and a documented optional sync contract. In this reproduction, 621 selected tests passed and seven real-database isolation tests were skipped.
Does Posnic Community Edition automatically sync branches?
No. Community installations keep local databases and do not automatically share sales or stock. Posnic Cloud is a separate optional service. Its exact gateway, provisioning, monitoring and recovery behavior must be included in a written scope and accepted with real branches.
Will every branch keep selling whenever the head-office connection fails?
That outcome was not accepted in this review. Test the exact till, local service, external network, tender, device and recovery path. External-internet loss is different from a failed local database, router, computer, power supply or payment provider.
Does Posnic prove stock transfer and central price propagation between branches?
No complete stock-transfer or central-price propagation workflow was established. Keep an approved external process until source, destination, quantities, exceptions, approvals and reconciliation pass a representative test.
Were tenant-isolation tests run against a real database?
Seven real-database cases in the selected tenant-isolation suite require CI_MONGODB_URI and were skipped in this reproduction. They must run in an approved environment before a shared cloud deployment is accepted.
Should a restaurant franchise use this guide or the restaurant POS page?
Use this guide for branch identity, access, sync, reconciliation and continuity. Use the restaurant POS page for menu, KOT, table-service and complete restaurant-shift acceptance. A restaurant franchise needs both boundaries.
A download, record request, source click or local test is not a completed rollout, synced branch, payment result, customer or revenue outcome.