Module overview, installation and lifecycle

Understand the idempotent installer

This guide explains that what happens when install.php runs again on an existing installation. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.

Audience: Administrators, deployment engineers and authorised module ownersPermission: Administrator or Enterprise POS: ViewModule v1.0.0 · code-inspected
Jump to steps
Where to goSetup → Modules; then Enterprise POS

What you’ll accomplish

Know what happens when install.php runs again on an existing installation. This section explains the supplied version 1.0.0 package, its additive installation model, tenant-scoped architecture and supported activation lifecycle.

Follow these steps

  1. Go to Setup → Modules; then Enterprise POS and open the workflow that matches “Understand the idempotent installer”. Confirm the page or record context before making a change.
  2. Verify the uploaded ZIP has the single britixo_enterprise_pos root folder.
  3. Go to Setup → Modules and activate Britixo Enterprise POS.
  4. Check activation output, the Enterprise POS menu and the default module records.
  5. Grant only the capabilities each staff role requires.
  6. Go to Enterprise POS → Settings before live use and verify the store, currency, location, checkout and integration settings.

Fields and options to review

  • Guide focus: Know what happens when install.php runs again on an existing installation.
  • Existing tables are retained; only missing tables/options/defaults are created.
  • Module folder: britixo_enterprise_pos
  • Module version: 1.0.0
  • Supported host convention: Perfex CRM 3.3.x
  • Public storefront base route: /shop
  • Read-only API base route: /britixo-pos/api/v1
  • Module-owned database prefix: bpos_

Rules the system enforces

  • Existing tables are retained; only missing tables/options/defaults are created.
  • Activation runs the idempotent install.php and creates missing module tables/options only.
  • Deactivation intentionally preserves operational and audit data.
  • The supplied package does not implement an automatic destructive uninstall.
  • The installer creates defaults only when tenant records are absent.
  • No raw payment-card data is requested or stored.

How to confirm it worked

  • The specific outcome described by this guide is visible and remains tenant-scoped.
  • The Enterprise POS menu is visible to an administrator or an authorised staff member.
  • General, Main Location and Main Register defaults exist on first clean activation.
  • The module can be deactivated and reactivated without intentional data deletion.

Safety checks and troubleshooting

  • Back up the application and database under the organisation’s normal change process before production activation.
  • Do not rename the module folder or nest it inside an extra directory.
  • Do not delete bpos_ tables to troubleshoot activation.
  • Use host-supported SMTP, payment and module lifecycle controls.
Stay within the supported module flow

Use the supplied UI, host module lifecycle and documented endpoints. Do not bypass tenant filters, permissions, CSRF, idempotency, rate limits, audit evidence or transaction checks. A stored table or field does not imply that version 1.0.0 exposes a management screen for it.