Understand features intentionally outside the supplied module

Avoid promising external card refunds, write APIs, advanced recipe/serial workflows or screens that the code does not expose. 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.

What you’ll accomplish

Avoid promising external card refunds, write APIs, advanced recipe/serial workflows or screens that the code does not expose. 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 features intentionally outside the supplied module”. 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: Avoid promising external card refunds, write APIs, advanced recipe/serial workflows or screens that the code does not expose.
• Some database structures are future-capable but have no management interface in version 1.0.0.
• 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

• Some database structures are future-capable but have no management interface in version 1.0.0.
• 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.

Continue with related guidance