Understand what the module stores about payments
Pixie CRM guidance. Follow the route for your workspace, check your role and enabled modules, and verify the result before moving on.
Distinguish tender records and invoice references from raw card data.
Where to goSetup → Modules; then Enterprise POS
What this guide helps you do
Distinguish tender records and invoice references from raw card data. This section explains the supplied version 1.0.0 package, its additive installation model, tenant-scoped architecture and supported activation lifecycle.
Follow these steps
- Go to Setup → Modules; then Enterprise POS and open the workflow that matches “Understand what the module stores about payments”. Confirm the page or record context before making a change.
- Verify the uploaded ZIP has the single britixo_enterprise_pos root folder.
- Go to Setup → Modules and activate Pixie CRM Enterprise POS.
- Check activation output, the Enterprise POS menu and the default module records.
- Grant only the capabilities each staff role requires.
- Go to Enterprise POS → Settings before live use and verify the store, currency, location, checkout and integration settings.
Fields and options
- Guide focus: Distinguish tender records and invoice references from raw card data.
- External card terminal is recorded as a tender name/reference; card data is not collected.
- 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 and limits
- External card terminal is recorded as a tender name/reference; card data is not collected.
- 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.
Check 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.
Related guides
Was this guide useful?Your response is stored only in this browser.
