Technical architecture, tables and endpoint reference

Understand the products table

Map the module-owned products records without editing them directly. 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: 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 you’ll accomplish

Map the module-owned products records without editing them directly. This section maps all module-owned tables, controller endpoints, transactions, tenant keys and host integrations without instructing direct database edits.

Follow these steps

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

Fields and options to review

  • Guide focus: Map the module-owned products records without editing them directly.
  • Purpose: Catalogue, pricing, stock controls and SEO.
  • Physical name uses the host prefix plus bpos_products.
  • 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 the system enforces

  • Purpose: Catalogue, pricing, stock controls and SEO.
  • Physical name uses the host prefix plus bpos_products.
  • 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.

How to confirm 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.