1. Functional Overview

Cheese Factory Manager turns Dolibarr ERP & CRM into a complete, specialised solution for running an industrial cheese factory. It covers the entire value chain — milk collection, reception and quality control, cheese making, ripening, packaging, storage, shipping, costing and reporting — so that a dairy no longer needs a separate agri-food ERP alongside Dolibarr.

1.1 Target users

·       Artisan cheese dairies

·       Industrial cheese factories

·       Dairy cooperatives

·       PDO/AOP cheese producers

·       Milk processing units

·       Fresh cheese manufacturers

·       Ripened cheese manufacturers

1.2 Value chain covered

Milk producers → Milk reception → Quality control → Cheese transformation → Production → Ripening → Packaging → Storage → Distribution → Customers

1.3 Functional scope

 

 

2. Architecture

The module is organised into seven cooperating engines, all built on Dolibarr's native CommonObject framework and sharing one generic list/card engine, one object registry and one multilingual dictionary.

2.1 Engines

 

2.2 Technical characteristics

·       Module number 519400, rights class 'cheesefactorymanager', 25 business objects, 35 granular permissions.

·       Tables are prefixed llx_cfm_*; every object is multi-entity managed and carries entity, status, creation/modification stamps and an import_key used by the demonstration dataset.

·       A schema self-heal runs on activation: Dolibarr only CREATEs tables, never ALTERs them, so missing columns are added automatically on upgrade.

·       Every user-visible language key is prefixed (Cfm...), which removes any possibility of a cross-module translation collision in Dolibarr's merged translation table.

·       Presentation follows the DoliResources house style: in-page tab bar, KPI cards, modern dashboard hero, and a charter of milk white, cold blue, cheese beige, quality green and production orange.

2.3 Integration with native Dolibarr modules

 

 

3. Cheese Production Process

The module implements a Manufacturing Execution System dedicated to cheese making. A production order carries a recipe, a vat and a cheese lot, and moves through ten process stages.

3.1 Process stages

 

Every step records its date, duration, temperature, pH, operator and an observation, which constitutes the internal traceability of the process.

3.2 Yield

The real yield is computed as weight produced ÷ milk used, and compared with the recipe's target yield. The gap is expressed in yield points and is the primary lever of the recipe optimisation engine.

 

4. Quality Management

4.1 Integrated laboratory

The laboratory handles two analysis families:

 

Each analysis carries a sample, a lot, a result (conform, derogation, non-conform, pending), a technician and a laboratory validation flag.

4.2 Non-conformities

·       Type, severity, affected lot, detection date and declarant.

·       Root cause and corrective action are documented, with a closing date.

·       The financial impact is quantified and feeds the cost-of-non-quality analysis.

4.3 Food safety HSE and HACCP

·       HSE events cover audits, incidents, hygiene checks, controls and training.

·       Each event references the relevant HACCP critical control point.

·       Severity, zone, action plan and closing date ensure follow-up to resolution.

4.4 Cold chain and IoT

·       Temperature and humidity sensors are attached to ripening caves and cold rooms.

·       Supported protocol references include MQTT, LoRaWAN and Modbus.

·       A reading outside the configured thresholds switches the sensor to alert and surfaces on the dashboard and in the AI assistant.

 

5. Traceability

Full food traceability is reconstructed on a single page from any lot, milk lot or producer reference. This answers a withdrawal or recall request in seconds.

5.1 The three traceability directions

 

5.2 Instant lot search

The traceability page accepts a cheese lot, a milk lot or a producer reference and rebuilds the whole chain, with clickable links to every related record. The same chain is available as JSON through the REST API.

 

6. API

The module exposes an industrial REST API so laboratory instruments, IoT gateways and shop-floor equipment can push data into the factory, and so external systems can read the traceability chain.

6.1 Authentication

The API uses Dolibarr's native REST authentication. Every request must carry a DOLAPIKEY header holding the API key of a Dolibarr user. Permissions are enforced per right group; an invalid key returns HTTP 401.

6.2 Endpoints

 

6.3 Example — pushing an IoT measure

curl -H "DOLAPIKEY: <key>" -H "Content-Type: application/json" \
     -d '{"fk_sensor": 13, "value_num": 12.4}' \
     https://<host>/api/index.php/cheesefactorymanager/measures

→ {"id": 218, "sensor_state": "ok", "last_value": 12.4}

The endpoint compares the value with the sensor thresholds, flags the measure as in-range or not, and updates the sensor's last value, last-seen timestamp and alert state so dashboards and the AI assistant reflect the reading immediately.

6.4 Security of the API layer

·       Sort fields are whitelisted against the table's real columns, so no user input reaches SQL unquoted.

·       Every route enforces the right group of the object it touches (read / write / delete).

·       The authenticated caller is the API user, never an implicit administrator.

 

7. Security

7.1 Permission model

The module declares 35 permissions across 11 functional groups, plus reporting and administration. Read and write are granted by default so the module is usable immediately after activation; delete and administration are not.

 

7.2 Access control

·       Every list, card and bespoke page checks the right group of the object before rendering.

·       Create, modify and delete actions are gated independently of read access.

·       Multi-entity: every query is filtered by entity, so data is isolated between companies.

7.3 Audit and traceability of changes

·       Every record stores its creation date, author, last modification timestamp and modifying user.

·       Status transitions (draft, active, closed, cancelled) are explicit and user-driven.

·       Laboratory analyses carry a technician and a validation flag, which documents responsibility for a result.

·       Non-conformities and HSE events record the declarant, the root cause, the action plan and the closing date.

·       Module activity is written to the Dolibarr system log through dol_syslog.

7.4 Input handling

·       All inputs pass through Dolibarr's GETPOST filters, typed per field.

·       SQL values are escaped through the database abstraction layer; sort fields are whitelisted.

·       Forms carry a CSRF token validated by Dolibarr's main include.

 

8. Configuration and demonstration data

8.1 Industrial parameters

 

8.2 Demonstration dataset

The configuration page provides two buttons, as required:

·       Load demonstration data — creates producers, milk lots, recipes, productions, ripenings, analyses and stock, as a fully FK-coherent dataset so dashboards, charts, traceability and reports are immediately meaningful.

·       Delete demonstration data — removes only the demonstration data. Records are tagged with an import key, and the purge also cascades to records a user created under a demonstration parent, so no orphan is left behind.

The dataset is versioned: raising the dataset version re-seeds an improved demonstration set on upgrade, which a simple boolean guard could never do.

8.3 Languages

The module ships complete translations in French, English, Spanish, Italian and German (408 keys each).

 

9. Business object reference

 

 

© 2026 DoliResources — www.doliresources.com