1. Introduction & Purpose

Footwear Store Management is a complete, ready-to-use business application that turns Dolibarr ERP/CRM into a specialised management platform for footwear and shoe retail. Published by DoliResources, it consolidates every operational dimension of a modern footwear business — network of stores and departments, seasonal footwear catalogue with size×colour variants, purchasing and receptions, multi-store stock and inventories, in-store and omnichannel sales, promotions and sales periods, customer loyalty and gift cards, returns and claims, shrinkage and quality control, equipment and maintenance, staff, tasks, incidents and alerts — behind a single top-level menu and a dedicated "Footwear Retail Cockpit" dashboard.

The module is built entirely on native Dolibarr foundations. It reuses the third-party (Societe) and product (Product) repositories, warehouses, users and the multi-company (entity) framework, so a footwear retailer benefits from a purpose-built vertical solution without leaving the familiar Dolibarr environment, and without duplicating master data already held in the core.

Target audience

The solution is designed for a broad range of footwear and shoe businesses, including:

·       Independent shoe shops and multi-brand footwear boutiques

·       Retail chains and franchise networks operating multiple points of sale

·       Footwear wholesalers, importers and distributors

·       Sports and running shoe stores

·       Safety and professional footwear specialists

·       Luxury and designer shoe boutiques

·       Men's, women's, children's and baby shoe shops

·       Sneaker and streetwear footwear stores

·       Orthopaedic and comfort shoe retailers

·       Leather goods, bags and shoe-care accessory shops

·       Destockers, outlets and off-price footwear stores

·       Footwear e-commerce operators and click-and-collect retailers

·       Manufacturers, showrooms, corners and pop-up stores

·       Buying groups and central purchasing offices

2. Architecture

The module follows the standard Dolibarr external-module architecture. A single descriptor class registers the module with the ERP, and a generic object engine drives all business entities from a central registry, which keeps the code base compact, consistent and easy to maintain.

2.1 Module descriptor

The descriptor modGestionChaussures (core/modules/) declares the module to Dolibarr. Its key properties are:

 

On activation the init() method loads the SQL schema, deletes and rebuilds the menu tree, provisions the permission set, invokes a schema self-heal routine (gchEnsureSchema) that reconciles the live tables with the expected columns on every upgrade, and finally generates the demonstration dataset if none is present. Deactivation is handled by remove().

2.2 Object engine and classes

All thirty business objects extend Dolibarr's CommonObject base class and are described declaratively in a single registry, lib/gestionchaussures_objects.php. Each entry defines the PHP class, the physical table, an icon, a menu label, whether the object is a navigation "hub", its line/parent relationship where relevant, and the full field list (name, type, label, searchable flag). A shared list/card engine (objectlist.inc.php and objectcard.inc.php) renders every object's list view and record card from this metadata, so the presentation layer is uniform across the whole module while individual per-object PHP entry points remain thin wrappers.

2.3 Database schema

Every table uses the llx_gch_ prefix (for example llx_gch_product, llx_gch_sale, llx_gch_stock). Tables carry the standard Dolibarr technical columns — rowid primary key, entity for multi-company isolation, status, creation and modification timestamps, author and modifier user references, and an import_key column used to tag and later safely remove seeded demonstration records. Foreign keys link module objects to one another and to native Dolibarr objects (User, Societe, Product, Entrepot).

2.4 Shared helper library and coded vocabulary

A shared helper library (lib/gestionchaussures.lib.php) centralises cross-cutting concerns: permission checks (gchCan), scalar SQL helpers, KPI card and colour-palette rendering, menu activation, label forcing, the schema self-heal routine, and — importantly — the coded-vocabulary renderer (gchVocabLabel). Business enumerations such as shoe category, gender, season, upper material, shoe type, sole, closure, sale channel, payment method, promotion type, loyalty level and status codes are stored as short, language-neutral codes in the database and rendered at display time into the active user language. This keeps stored data stable and portable while presenting fully localised labels in five languages.

2.5 Permission model

The module defines eight functional right groups plus an administration right. Read and write are granted by default so the module is usable immediately after activation, while delete and admin stay off until explicitly granted:

 

This yields 23 discrete permissions in total: read/write/delete for the seven operational groups, a single read permission for reporting, and one module administration right.

3. Data Model

The module ships thirty business objects, organised into functional areas. The table below lists each object with its physical table and purpose.

 

3.1 Key objects and notable fields

Article (Gchproduct) — the heart of the catalogue. Beyond the SKU (ref) and label it carries an optional link to a native Dolibarr Product (fk_product), and to store, department and collection. Merchandising attributes include barcode, brand, manufacturer, gender, category, product family, upper material, shoe type, sole type, closure, heel height, width/fit, season, country of origin and care instructions, plus new-arrival and eco-responsible flags. The commercial block holds purchase price, cost price, sale price, VAT rate and margin percentage, while stock_min and stock_max drive replenishment thresholds.

Variant (Gchvariant) — the size×colour declination of an article. Each variant belongs to an article (fk_product) and carries its own SKU, size, colour, colour hex, material, barcode, EAN-13, stock quantity, weight, sale price and physical location. Variants are what customers actually buy and what stock is counted against.

Collection (Gchcollection) — a seasonal grouping with name, season, collection year, theme, start and end dates, number of products and budget, enabling season-over-season analysis of the assortment.

Sale (Gchsale) and Sale line (Gchsaleline) — the sales ticket and its lines. The header records store, customer (native Societe), seller (staff), sale datetime, payment method, channel, item count, totals excluding and including tax, and total margin. Each line references the article, variant and department, and stores the sold size and colour, quantity, unit price, discount and line total — giving fine-grained analytics down to the individual size and colour sold.

4. Menus & Navigation

The module installs one top-level menu, "Chaussures" (Footwear store), that opens the Fashion Retail Cockpit dashboard. Its left-hand menu exposes every functional area; each entry is guarded by the relevant permission so users only see what they are entitled to. The left menu entries are:

·       Dashboard

·       Stores

·       Departments

·       Articles

·       Variants

·       Collections

·       Suppliers

·       Lots

·       Supplies

·       Receptions

·       Transfers

·       Stocks

·       Inventories

·       Sales

·       Promotions

·       Loyalty

·       Gift cards

·       Returns

·       Claims

·       Losses

·       Controls

·       Equipment

·       Maintenance

·       Staff

·       Tasks

·       Incidents

·       Alerts

·       Reporting

·       Setup

Every menu URL is module-local, so the entries never collide with another module's shared native pages. Icons are Font Awesome glyphs rendered in the module's signature gold (#B8860B).

5. Dashboard – Footwear Retail Cockpit

The dashboard (dashboard.php) is the module's landing page, titled "Footwear Retail Cockpit". It opens with a hero banner and a live store-status strip, then presents KPI cards grouped into functional zones (sales performance, catalogue & stock, customers & loyalty), a set of analytical charts, and best-seller rankings. A closing alert bar surfaces the number of open alerts when any exist.

5.1 KPI cards

 

5.2 Charts and rankings

·       Sales evolution — monthly revenue over the last 13 months (bar chart, gold)

·       Sales by category — revenue split across shoe categories (pie)

·       Sales by department — revenue by in-store universe (bar)

·       Sales by channel — in-store, online, click & collect, phone (pie)

·       Stock by department — physical stock rotation per universe (bar)

·       Top brands — highest-revenue brands (ranked table)

·       Top articles — best-selling articles by quantity and revenue (ranked table)

·       Top stores — leading stores by tickets and revenue (ranked table)

6. Reporting

The reporting suite (reporting.php) offers eight decisional reports selectable from a tabbed bar. Each report shows a contextual KPI row above a detailed data table, and can be exported to CSV or sent to the printer. CSV export decodes all HTML entities so accented labels and currency values export cleanly.

 

7. Business Workflows

The module supports the end-to-end operational cycle of a footwear retailer.

7.1 Procurement and receptions

Buyers register footwear suppliers (with lead time, minimum order, service and conformity rates, and a supplier score), then raise supply orders with article/variant lines. When goods arrive, a reception is recorded against the supply: expected versus received quantities and conformity are captured line by line, anomalies are counted, received lots are tracked with their arrival date, and stock is updated accordingly.

7.2 Catalogue and variants

Articles are created with their full merchandising and pricing profile and attached to a collection and department. Size×colour variants are generated for each article, each with its own barcode/EAN-13 and sale price, so that stock, sales and inventories all operate at the precise variant level customers buy.

7.3 In-store and omnichannel sales

Sales are captured as tickets tied to a store, a seller and a customer, across multiple channels — in-store, online e-shop, click & collect and phone — and multiple payment methods (card, cash, cheque, gift card, mixed). Each line records the exact size and colour sold, quantity, discount and line total, and the ticket rolls up totals excluding/including tax and margin.

7.4 Promotions and sales periods

Promotions and statutory sales (soldes) are defined by code, type (percentage, amount, pack, buy-one-get-one, coupon, strikethrough price), value, validity dates, optional department scope and minimum amount, with usage tracked. The dashboard surfaces the number of currently active promotions.

7.5 Loyalty and gift cards

Loyalty cards accumulate points and total spend, classify customers into levels (classic, silver, gold, VIP), and store a preferred size for clienteling. Gift cards carry an initial amount and a running balance with issue and expiry dates; active cards with a positive balance are reported on the cockpit.

7.6 Returns and exchanges

Customer returns and exchanges are logged with reason, type (refund or exchange), quantity, refund amount and status, feeding both the return-rate KPI and the returns report. Claims capture qualitative customer feedback with category, priority, status and a satisfaction score.

7.7 Inventories and inter-store transfers

Inventory campaigns (full or rolling) reconcile theoretical against counted quantities and record gaps per line. Inter-store transfers move stock of an article/variant from a source to a destination store with a status lifecycle, keeping multi-store stock balanced.

7.8 Quality control and shrinkage

Quality, hygiene and floor checks are recorded with a result and score and optional corrective action. Losses capture shrinkage, breakage, theft, expiry and donations with both purchase and sale value, so that the financial impact of shrinkage is quantified alongside operational incidents and alerts.

8. Multilingual & Localization

The interface is fully translatable and ships with five native Dolibarr language files: French (fr_FR), English (en_US), Spanish (es_ES), Italian (it_IT) and German (de_DE). Labels are resolved through Dolibarr's standard translation layer, so the module respects each user's language preference.

Business enumerations are stored as short, language-neutral codes and rendered on the fly by the coded-vocabulary helper (gchVocabLabel). This means the underlying data stays identical regardless of interface language, while every category, gender, season, material, shoe type, sole, closure, channel, payment method, promotion type, loyalty level and status code is displayed with a correctly localised label. The same mechanism guarantees that charts, tables and CSV exports remain consistent and correctly decoded across all supported languages.

9. Dolibarr Integrations

Rather than duplicating core data, the module integrates with native Dolibarr objects:

 

The module declares hard dependencies on modSociete and modProduct, ensuring those repositories are available before activation.

10. Demo Dataset

To let evaluators explore a fully populated cockpit from the first login, the module can generate a coherent demonstration dataset in a single click. All seeded records are tagged with the import key GCHDEMO, so the dataset can be removed cleanly and safely without touching real data. Generation runs automatically on first activation when no data is present, and both generation and removal are also available from the setup page.

The demonstration dataset includes, among other records:

·       A network of stores of varied types (flagship, franchise, outlet, corner, e-shop) with departments

·       Footwear suppliers linked to native third parties, with scores and service metrics

·       A seasonal footwear catalogue of articles with size×colour variants, brands and collections

·       Supplies, receptions and lots covering the procurement cycle

·       Multi-store stock rows, plus inventory campaigns with gaps

·       Approximately 1,500 sales tickets spread over 13 months across all channels and payment methods

·       Promotions and sales periods, loyalty members and gift cards

·       Returns, claims, losses, quality controls, equipment, maintenance, staff, tasks, incidents and alerts

Roughly thirteen months of history are seeded so that every monthly chart, trend and margin metric is meaningful from the outset.

11. Security & Permissions

Access is governed by the eight functional right groups described in section 2.5, each exposing read, write and (optionally) delete permissions, plus a dedicated read-only reporting right and a module administration right — 23 permissions in total. Read and write are granted by default so the module is immediately usable, while delete and administration remain disabled until an administrator grants them.

·       Every page enforces the relevant permission (gchCan / hasRight); the dashboard and reporting require the corresponding read rights, and the setup page requires administrator status.

·       All data is entity-scoped: multi-company and multi-store installations are isolated by the native Dolibarr entity mechanism on every query.

·       Demonstration data is isolated by the GCHDEMO import key so it can be removed without affecting production records.

·       The module is distributed under the GNU General Public License v3 or later; Copyright © 2026 DoliResources.

12. Installation & Configuration

12.1 Deployment

·       Copy the gestionchaussures folder into the htdocs/custom directory of the Dolibarr installation, or install the packaged ZIP through Home ▸ Setup ▸ Modules ▸ Deploy/install external module.

·       Enable the module from Home ▸ Setup ▸ Modules (Products family). Activation automatically creates the llx_gch_* tables, builds the menus, provisions the rights, self-heals the schema and seeds the demo dataset.

·       Assign the desired read/write/delete permissions to user groups from Home ▸ Users & Groups.

12.2 Settings page

The configuration page (admin/setup.php) exposes the module settings and the demonstration-data controls:

 

The same page provides one-click actions to generate or remove the demonstration dataset, with a confirmation prompt before removal.

13. Appendix – Legal & Editor Information

 

This document describes version 1.0 of the module and is provided for functional and technical reference. Copyright © 2026 DoliResources — https://www.doliresources.com. Distributed under the GNU GPL v3 or later.