Technical architecture, tables and endpoint reference

Understand the model and service responsibilities

Pixie CRM guidance. Follow the route for your workspace, check your role and enabled modules, and verify the result before moving on.

Separate persistence/integration operations from cart/order calculation and commit logic.

Audience: Developers, auditors and support engineersPermission: Read-only code review plus the permission of the relevant live actionModule v1.0.0 · code-inspected

Jump to steps

Where to goModule code and Enterprise POS administration

What this guide helps you do

Separate persistence/integration operations from cart/order calculation and commit logic. This section maps all module-owned tables, controller endpoints, transactions, tenant keys and host integrations without instructing direct database edits.

Follow these steps

Go to Module code and Enterprise POS administration and open the workflow that matches “Understand the model and service responsibilities”. Confirm the page or record context before making a change.
Use the supplied module package as the authoritative source.
Map the requested workflow to its controller, model/service method, table and permission.
Check tenant and transaction boundaries.
Use live UI/API behaviour for functional tests.
Do not change schema or records outside the verified module lifecycle.

Fields and options

Guide focus: Separate persistence/integration operations from cart/order calculation and commit logic.
25 module tables
3 controllers plus one compatibility controller
Model and service transaction methods
Host hooks for activation, cron and invoice payments
Public/API/admin routes
Tenant key, correlation IDs and immutable snapshots

Rules and limits

Business writes run inside database transactions where required.
Tenant key is applied to module-owned records.
Existing order line/payment/stock snapshots are not recalculated from current product values.
Core invoice linkage uses invoice_id and host models/hooks rather than modifying unrelated core schema.

Check it worked

The specific outcome described by this guide is visible and remains tenant-scoped.
Support engineers can trace each workflow from route to persisted evidence.
Schema references accurately distinguish live UI from reserved/future-capable structures.

Safety checks and troubleshooting

Do not run direct database commands from this documentation.
Do not expose secret/hash fields.
Do not infer a user interface merely because a table/column exists.

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.

Was this guide useful?Your response is stored only in this browser.