Why Categories
At our own pharmacies, the way staff think about stock is not the same as the way customers browse online. Back-office teams organize by therapeutic and procurement groups; shoppers look for Medicines, Baby Care, or Devices. One flat list cannot serve both.
Categories solves that split deliberately:
- Product categories — how your team assigns and reports on products inside PIMS.
- Storefront categories — how the B2C menu is structured, slugged, and merchandised.
- Generic categories — extra attribute schemas where regulation demands them (medicine form, device class, etc.).
What this gives you
| Need | Where it lives |
|---|---|
| ”Which shelf group does this SKU belong to?” | Product category on the product record |
| ”Which menu should this appear under online?” | Storefront category + mapping |
| ”What fields must we capture for this product type?” | Generic category config |
Why not one list?
A single category table forces compromises: either staff taxonomies get exposed verbatim to customers, or marketing reorganizes the menu and breaks reporting. The mapping layer lets merchandising change without rewiring your entire catalog.
When you’re evaluating Ailaaj
Ask whether competing systems let pharmacy staff maintain both operational taxonomy and customer navigation without duplicate data entry. In Ailaaj, mappings are explicit, editable per category, and visible directly in the tree.