Discover powerful Dolibarr extensions designed to automate your business processes
Harvest Management (Gestion des Recoltes) is a business module for Dolibarr ERP and CRM published by DoliResources. It turns a standard Dolibarr installation into a...
Couldn't load pickup availability
Harvest Management (Gestion des Recoltes) is a business module for Dolibarr ERP and CRM published by DoliResources. It turns a standard Dolibarr installation into a complete harvest management system for farms, cooperatives, producer groups, packing stations and collection companies, covering the whole chain from the farming campaign and the plot right through to the traceable lot, the quality decision, the cost price and the margin.
The module is entirely additive. It installs into htdocs/custom/, creates its own 37 tables, its own permissions, its own menu tree and its own configuration constants, and never modifies a single file of the Dolibarr core. Features that rely on an optional Dolibarr module degrade cleanly when that module is not enabled.
· Land and agronomy — farms, plots, cadastral references, soil, exposure, drainage, irrigation method, crops, varieties and cropping history.
· Campaign steering — farming campaigns with budget, forecast volume, actual volume, revenue and completion rate.
· Forecast to harvest — harvest forecasts, harvest plans and calendar, harvest orders, field operations and mobile field entry.
· Weighing and lots — single or double weighing with weighing tickets, harvested lots, barcodes and QR codes, splits, merges and transformations.
· Quality — reusable control models and criteria, quality checks with scoring, non-conformities and corrective actions.
· Losses — losses and downgrades recorded by cause, by stage and by value.
· Resources — teams, workers, timesheets, productivity, equipment and equipment use.
· Flow — transports, storage locations, stock movements, packing runs and packing lines.
· Upstream and downstream — producers, deliveries, contracts, purchasing and sales integration with the native Dolibarr chain.
· Analysis — cost entries by category, cost price per kilogram, margin, profitability, dashboard, 35 reports, alerts, event log, imports, exports and REST API.
The 37 business objects below are the complete data model of the module. Every table carries an entity column so the module works on a multi-company installation, a ref column used as the human-readable reference, a status column, and the standard creation and modification audit columns. Records created by the demonstration generator additionally carry an import_key marker.
The module was designed around nine operational objectives that a harvesting organisation has to meet every season.
· Run the campaign as a single object — give every season a campaign record that carries its target, its forecast and actual volumes, its budget, its actual cost, its revenue and its completion rate, so the season can be steered and then closed.
· Know the land base — hold each farm and each plot with its area, cadastral code, GPS position, soil, exposure, drainage, water source, irrigation method, current crop, planting date, plant density and cropping history.
· Forecast before harvesting — produce revisable harvest forecasts by plot, crop and variety using an explicit estimation method and a declared confidence level, then measure the gap between forecast and reality.
· Plan and dispatch the work — turn forecasts into dated harvest plans with a team, equipment and a target quantity, detect assignment conflicts and issue harvest orders.
· Capture the field reality — record harvest operations with gross and net quantities, containers, duration, weather, incidents and productivity, including from a phone or a tablet at the edge of the plot.
· Weigh with an auditable trail — produce weighing tickets in single or double weighing mode, compute the tare from the container count and keep every correction traced with its reason and its author.
· Guarantee traceability — reconstruct the full chain in both directions, from the plot and the producer to the shipped lot, including splits, merges and transformations.
· Secure quality and treat deviations — apply reusable control models, score each check, block or downgrade a lot on threshold, and manage non-conformities through to a closed corrective action.
· Know the real cost — consolidate every cost family into a cost price per kilogram and a gross margin by campaign, plot, crop and producer.
Harvest Management addresses any organisation that harvests, weighs, controls, stores, packs and sells agricultural production: family farms and estates, market gardening companies, orchards and olive groves, agricultural cooperatives, producer groups, packing stations and collection or trading companies.
Inside those organisations the module is designed for a set of distinct roles, each of which is served by one or more of the 15 permission groups described in the Security section. Because the permission groups are granular, a weighbridge clerk never sees the producer purchase prices and a picker never sees the margins.
· One system instead of two — harvest operations and the commercial and accounting chain live in the same database, so a lot, a producer and a supplier invoice are the same records seen from two angles.
· Traceability that survives an audit — every lot can be walked upstream to its plot, producer, harvest operation and weighing tickets, and downstream to its sub-lots, stock movements, packing runs and transports, from a single page or a single API call.
· Decisions taken on measured facts — the dashboard and the reports read the same figures over the same campaign window as the REST API, so two surfaces can never disagree about the same indicator.
· Least privilege by construction — 15 permission groups with separate read, write and delete rights, plus eight special rights, mean a role can be given exactly the reach it needs and nothing more.
· Immediately usable — read and write rights are granted by default at activation, the menus, tables and settings are created automatically, and a complete demonstration dataset can be installed and removed in one click.
· Configurable without code — 29 settings, 77 controlled vocabularies and reusable quality control models let the module be shaped to a crop, a market and a customer specification from the setup page.
· International from day one — five complete language files, each with 1657 keys, and amounts and dates rendered through the standard Dolibarr formatting helpers.
· Open to the outside — a REST API with 44 declared routes, CSV and Excel imports and exports, printable labels with barcode and QR code, and two scheduled jobs.
The farming campaign is the top-level object of the module. Almost every other record - forecast, plan, order, operation, lot, quality check, loss, transport, cost, delivery and contract - carries a link to a campaign, which is what makes season-by-season analysis possible.
A campaign carries 25 declared fields: reference, name, season year, campaign type, start date, planned end date and actual end date, manager, main farm, a link to a native Dolibarr project, number of plots, area in hectares, forecast and harvested quantities in kilograms, forecast and actual yield in tonnes per hectare, completion percentage, quality target, planned budget, actual cost, revenue, loss percentage, status, and a public and a private note.
The campaign_status vocabulary defines nine states: draft, planned, validated, preparation, running, suspended, closed, cancelled and archived. Two dedicated rights govern the transitions that matter: validating a campaign and closing a campaign are separate permissions, both disabled by default.
Economic and operational indicators are measured over the running campaign window rather than the civil year. A campaign routinely spans two calendar years, so a January-to-December window would cut a single production cycle in half and report an artificial collapse every spring. The window is computed once and shared by the dashboard, the profitability page and the REST API dashboard route.
The second scheduled job, RclCronIndicators, recomputes the campaign aggregates and indicators every six hours, so the harvested quantity, the completion rate and the actual cost stay aligned with the operations, lots and cost entries recorded since the last run.
A farm record carries 27 fields: reference, name, linked Dolibarr third party, owner, manager, farm type, address, town, region, province and country, GPS latitude and longitude, altitude, climate type, total and cultivated area in hectares, number of plots, main crop, certification, irrigation method, cold room and packing house flags, default warehouse, phone, email and a note.
The link to a Dolibarr third party means a farm that is also a legal counterparty is not duplicated: contacts, addresses, documents and accounting all remain on the native record.
A plot is the operational unit of the land base and carries 31 fields: reference, name, farm, producer, cadastral land code, area and area unit, GPS position, a WKT polygon for the plot outline, altitude, exposure, soil type, soil texture, soil pH, salinity, drainage, water source, irrigation method, current crop and variety, planting date, plant density, number of plants, historical and forecast yield in tonnes per hectare, certification, plant health status, plot status, manager and a note.
Nine plot statuses are available - available, prepared, planted, growing, ready, being harvested, harvested, resting and unavailable - and they drive both the plot map and the harvest cycle view.
A dedicated full-page plot map shows the geolocated plots coloured by status, with the status legend and the plot summary behind it. Each plot on the map links straight to its record, so the map is a navigation surface and not only an illustration.
A crop carries 17 fields: code, name, crop category, botanical family, linked Dolibarr product, default unit, cycle length in days, first and last harvest month, average yield in tonnes per hectare, harvest method, storage condition, shelf life in days, storage temperature, quality criteria, tolerance percentage and a description.
Twelve crop categories are supplied - vegetable, fruit, cereal, forage, oilseed, vine, palm, olive, citrus, ornamental, turf and aromatic - and twelve harvest methods cover manual picking, mechanised and semi-mechanised harvesting, pole harvesting, shaking, lifting, mowing, combining, cutting, destemming and vacuum harvesting.
A variety carries 16 fields: reference, name, parent crop, origin, precocity, average yield, calibre in millimetres, colour, sugar content in Brix, humidity percentage, intended use, storage condition, disease sensitivity, quality standard, certification and a description. Varieties are the level at which yield, calibre and commercial destination actually differ, which is why forecasts, orders, operations, lots, deliveries and contracts all carry a variety link.
A crop points at a native Dolibarr product. That single link is what allows a harvested lot to be sold, invoiced and stock-managed through the standard Dolibarr chain without any duplicate item master.
A harvest forecast estimates what a plot will produce, when it will be ready and how confident the estimate is. It carries 24 fields: reference, campaign, farm, plot, crop, variety, producer, period label, forecast date, maturity date, planned harvest date, estimation method, confidence level, number of plants observed, number of samples, average yield per plant, forecast quantity, revised quantity, actual quantity, forecast yield in tonnes per hectare, gap in kilograms, gap in percent, risk and a note.
Seven estimation methods are available: manual, historical, by area, by plant, by sampling, imported and automatic. Recording the method and the confidence level alongside the number of plants observed and the number of samples makes the estimate auditable: a figure produced from four samples is not read like a figure produced from historical yields over a whole plot.
The forecast keeps the initial quantity, the revised quantity and the actual quantity side by side, and stores the gap both in kilograms and as a percentage. The tolerated gap is a setting (default 15 percent); beyond it, the alert engine raises a significant forecast deviation alert and the yield reports list the plots concerned.
A harvest plan converts a forecast into a dated, resourced slot. It carries 21 fields: reference, name, campaign, farm, plot, planned date, start and end time, team, manager, equipment, vehicle, number of workers, number of containers, target quantity, capacity in kilograms, destination, warehouse, conflict flag, plan status and a note.
Each plan carries a conflict flag, so a slot that competes with another for the same team, the same vehicle or the same window is visibly marked rather than silently double-booked.
A monthly harvest calendar page lays out the planned slots of the month day by day, with their plot, team, target quantity and conflicts, which is the view used to arbitrate the week before it starts. Eight plan statuses are available: draft, planned, confirmed, assigned, running, done, postponed and cancelled.
The harvest order is the instruction sent to the field. It carries 29 fields: reference, label, campaign, farm, plot, crop, variety, producer, planned date, start and end time, manager, team, harvest method, target and achieved quantity, unit, planned container count, container type, equipment, vehicle, destination, warehouse, priority, harvesting instructions, quality notice, safety notice, status and a note.
Three separate free-text fields travel with the order: the harvesting instructions, the quality notice and the safety notice. Keeping them apart means a quality requirement is never buried inside a logistics comment.
Eleven order statuses are available: draft, to validate, validated, planned, assigned, running, suspended, finished, partial, cancelled and closed. Two special rights guard the sensitive transitions - validating a harvest order, and starting or finishing a harvest - and both are disabled by default.
An open order whose planned date has passed is counted as late. The number of days of grace is a setting (default 2 days), and late orders feed both the dashboard alert tile and the late orders report.
A harvest operation is what actually happened in the plot. It carries 31 fields: reference, order, campaign, plot, crop, variety, operation date, start and end timestamps, duration in minutes, team, manager, number of workers, gross and net quantity, unit, number of containers, container type, tare, actual yield in tonnes per hectare, productivity in kilograms per hour, harvest method, weather code, temperature, product state, destination, GPS latitude and longitude, incident code, status and a note.
A dedicated simplified field page lets a supervisor record a harvest against an open order with three fields and one large button, from a tablet or a phone at the edge of the plot. This is the entry point designed for gloved hands and direct sunlight, and it writes the same operation record as the full form.
Weather code, temperature, product state and incident code are captured on the operation itself. That is what later explains a productivity drop or a quality deviation without relying on anybody's memory.
Six statuses are available: open, running, paused, finished, validated and cancelled.
The weighing ticket is the legal and commercial evidence of a quantity. It carries 26 fields: ticket number, weighing timestamp, weighing type, campaign, order, operation, lot, producer, plot, crop, variety, vehicle plate, driver, gross weight, tare, net weight, unit, number of containers, container type, scale used, weighing centre, operator, correction flag, correction reason, status and a note.
The weighing mode is a setting: single weighing or double weighing (first weighing and second weighing). Seven weighing types are available - first, second, single, inbound, outbound, container and global - so a weighbridge, a platform scale and a container count can all be represented without stretching one concept over another.
The tare can be computed automatically from the container count and the default container tare (1.8 kg by default), or entered manually. An accepted weighing gap in percent (default 2 percent) defines the tolerance beyond which a discrepancy is treated as an anomaly.
Correcting an already recorded weighing is a distinct permission, disabled by default, and can itself be switched off entirely from the setup page. When a correction is allowed, the ticket keeps a correction flag and a correction reason, and the event log records the old value, the new value, the author and the IP address.
The harvested lot is the object the whole traceability chain hangs on. It carries 26 fields: lot number, barcode, campaign, farm, plot, crop, variety, producer, order, operation, linked Dolibarr product, harvest timestamp, initial and available quantity, unit, number of containers, container type, warehouse, storage location, quality grade, destination, use-by date, storage condition, packed flag, status and a note.
Fourteen lot statuses cover the whole life of a lot: created, awaiting control, conforming, blocked, non-conforming, in stock, in transfer, being packed, partial, sold, shipped, exhausted, downgraded and destroyed.
Lot links record the genealogy between lots. Six link types are supported: split, merge, transfer, transformation, reclassification and downgrade. Each link stores the parent lot, the child lot, the date, the quantity moved, the operator and the reason, so a merged lot never loses the identity of its inputs.
A dedicated page reconstructs the full record of one lot: upstream the plot, farm, producer, harvest operation, weighing tickets, quality checks and source lots; downstream the sub-lots, stock movements, packing runs and transports. The same page displays the QR code that reopens it directly from a crate label.
The label page produces lot labels with a chosen sheet format, a number of copies, the company logo, a QR code and a barcode, as an on-screen preview and as a printable PDF sheet. Seven label formats are available: A4 with 24, 21, 14, 10 or 8 labels per sheet, and 57 mm or 100 mm continuous rolls.
Quality control is built on four objects: a reusable control model, its criteria, the check performed on a lot, and the individual measured results.
A control model carries 12 fields: reference, name, crop, variety, customer, destination, certification, sampling plan, sample size, number of criteria, a block-on-failure flag and a description. Because a model can be attached to a customer and to a destination, the same crop can be controlled against a supermarket specification and against an export specification without rewriting the criteria each time.
Each criterion carries 12 fields: reference, model, criterion code, rank, unit, minimum value, maximum value, target value, tolerance percentage, weight in the score, a blocking flag and a note. Twenty-three criterion codes are supplied, covering calibre, mean weight, colour, maturity, firmness, sugar, acidity, humidity, temperature, appearance, defects, defect rate, cleanliness, foreign bodies, damage, plant health, residues, microbiology, smell, taste, homogeneity, packaging and labelling.
A quality check carries 17 fields: reference, lot, control model, campaign, producer, controller, check date, sample quantity, number of samples, number of criteria passed and failed, score percentage, defect rate, resulting quality grade, decision, conclusion and a note. Each measured criterion is stored as its own result line with the measured value, the admissible range, the result code and the deviation percentage.
Seven commercial grades are available: Extra, Category I, Category II, Category III, industry, out-of-grade and reject. Ten decisions can close a check: accepted, accepted with reservation, to be re-checked, blocked, downgraded, rejected, returned, to be sorted, to be processed and to be destroyed.
Four settings govern enforcement: whether a quality check is mandatory before a lot can be sold, the score below which a lot is blocked (default 70), the score below which a lot is downgraded (default 85) and the maximum accepted defect rate (default 10 percent). Validating a quality check and blocking or releasing a lot are two separate rights, both disabled by default.
A non-conformity records a deviation and drives it to closure. It carries 20 fields: reference, label, lot, quality check, campaign, producer, type, severity, detection date, detected by, quantity concerned, financial impact, probable cause, immediate action, owner, deadline, closure date, final result, status and a description.
Ten non-conformity types are available: quality, quantity, plant health, documentary, process, transport, storage, packing, labelling and safety. Four severity levels are used throughout the module: critical, high, medium and informational.
Seven statuses drive the treatment: open, under analysis, planned, under treatment, verification, closed and rejected. Recording the probable cause and the immediate action separately from the corrective actions is what distinguishes a stop-gap from an actual fix.
Each non-conformity carries its corrective actions, with 11 fields: reference, label, parent non-conformity, action type, owner, planned date, completion date, cost, effectiveness percentage, status and a description. Three action types are supported - immediate, corrective and preventive - and five statuses: planned, running, done, late and cancelled. Overdue corrective actions are surfaced as an alert.
Losses and downgrades are recorded as first-class objects rather than derived from a quantity difference. A loss carries 20 fields: reference, loss date, campaign, lot, plot, crop, operation, team, producer, cause, stage, quantity, unit, estimated value, a downgrade flag, grade before and grade after, owner, a validation flag and a note.
Seventeen loss causes are available: fallen to the ground, damaged, over-maturity, disease, pest, handling, transport, storage, sorting, packing, desiccation, rot, theft, weighing error, inventory adjustment, destruction and other. Seven stages locate where the loss occurred: field, transport, reception, storage, sorting, packing and shipping. Recording both dimensions is what makes a loss actionable - the same cause at two different stages calls for two different corrective measures.
A downgrade is recorded as a loss carrying the downgrade flag together with the grade before and the grade after, so the volume that changed commercial category is measurable separately from the volume that was physically destroyed.
A configurable loss rate threshold (default 8 percent) triggers the abnormal losses alert. The loss rate on the dashboard is computed over the same campaign window as the harvested quantity it is divided by.
A team carries 15 fields: reference, name, team type, farm, manager, number of members, pay mode, hourly rate, rate per kilogram, rate per container, daily capacity in kilograms, quantity harvested, productivity in kilograms per hour, phone and a note. Seven team types are supported: harvest, sorting, packing, transport, weighing, quality and multi-skilled.
A worker carries 19 fields: reference, last name, first name, team, linked Dolibarr user, linked Dolibarr contact, worker type, qualification, start and end date, pay mode, hourly rate, rate per kilogram, phone, availability flag, total hours, quantity harvested, productivity and a note. Seven worker types are available: employee, seasonal, agency, contractor, apprentice, volunteer and family worker.
A timesheet carries 23 fields: reference, sheet date, worker, team, operation, order, plot, time in and time out, normal hours, extra hours, break in minutes, absence flag, absence reason, quantity harvested, number of containers, productivity, pay mode, base amount, bonus amount, total amount, validation flag and a note. Seven pay modes are supported: per hour, per day, per quantity, per crate, per weight, flat rate and mixed, which covers both time-based and piece-rate harvesting.
Seven absence reasons are available - sickness, leave, unjustified, bad weather, accident, training and family - and productivity in kilograms per hour is carried at worker, team and timesheet level, which is what feeds the workforce reports and the bonus calculation.
An equipment record carries 22 fields: reference, name, equipment type, farm, serial number, plate number, brand, model, supplier third party, manager, location, capacity and capacity unit, purchase date, purchase value, hourly cost, hour counter, kilometre counter, next maintenance date, next inspection date, state and a note.
Sixteen equipment types are supplied: harvesting machine, tractor, trailer, platform lift, ladder, secateurs, net, crate, pallet box, tipper, scale, weighbridge, personal protective equipment, handling equipment, sorting equipment and other. The scale and weighbridge entries are what let a weighing ticket name the instrument that produced it.
Each use is recorded separately with 13 fields: reference, equipment, order, operation, plot, use date, hours used, kilometres, fuel litres, operator, cost, incident code and a note. The hourly equipment cost and the reference fuel price are settings (28.00 and 1.62 by default), so a use converts into a cost without manual arithmetic.
Equipment that is broken down or stopped is counted on the dashboard and raises the unavailable equipment alert. The next maintenance date and the next regulatory inspection date are stored on the record and surfaced through the documents nearing expiry alert.
A transport carries 26 fields: reference, label, transport type, campaign, planned and actual date, origin, plot, destination label, warehouse, carrier third party, driver, vehicle, vehicle plate, number of lots, total quantity, number of containers, temperature, departure and arrival time, duration, distance in kilometres, cost, incident code, status and a note.
Each transport carries its lines, one per transported lot, with the lot, the rank, the quantity sent, the number of containers, the quantity actually received and the resulting gap. Recording the received quantity on the line rather than on the transport is what makes a partial reception measurable lot by lot.
The transport temperature is stored on the transport itself, and an incident code can be recorded, so a cold chain deviation is attached to the shipment that experienced it and travels with the lots concerned into the traceability record.
Nine statuses are available: draft, planned, assigned, loading, in transit, delivered, partial, cancelled and closed.
A storage location carries 16 fields: reference, name, location type, linked Dolibarr warehouse, farm, zone code, capacity in kilograms, capacity in pallets, occupancy in kilograms, occupancy percentage, minimum and maximum temperature, humidity, a cold flag, a blocked flag and a note. Nine location types are supplied: reception, control, cold room, dry store, quarantine, sorting, packing, shipping and waste.
The location is the fine-grained position inside a native Dolibarr warehouse: the warehouse stays the accounting stock unit, while the location carries the physical and thermal reality the warehouse record does not model.
A stock movement carries 16 fields: reference, movement timestamp, movement type, lot, linked Dolibarr product, source and destination location, warehouse, quantity, unit, number of containers, operator, transport, reason, a Dolibarr synchronisation flag and a note. Nine movement types are available: harvest entry, transfer, reservation, shipping issue, processing issue, destruction issue, inventory, correction and return.
Two settings govern the link with the native stock module: whether the Dolibarr stock movement is created when a lot is validated (on by default) and the default destination warehouse. Each movement carries its own synchronisation flag, so a movement that could not be mirrored is visible rather than assumed. When the Stocks module is not enabled the module keeps its own locations, movements and lot balances and simply performs no native mirroring.
Two settings drive the stock alerts: the critical stock threshold in kilograms (default 500) and the number of days after which a lot in stock is reported as old (default 10). Both feed the alert engine and the stock reports.
A packing run carries 25 fields: reference, label, campaign, planned date, start and end timestamps, location, team, manager, source lot, resulting lot, packed Dolibarr product, input quantity, output quantity, loss quantity, packing yield percentage, number of packages, package type, number of pallets, quality grade, hours spent, total cost, cost per kilogram, status and a note.
Each run is broken down into its operations, one line per step, with the rank, the operation code, the equipment, the number of workers, the duration, the input, output and loss quantities and the cost. Nine packing operations are supplied: sorting, washing, grading, drying, classification, packaging, labelling, crating and palletising.
Because input, output and loss quantities are recorded at each step, the packing yield is measured rather than estimated, and the cost per kilogram of packed product is carried on the run itself, ready to be consolidated into the cost price.
A packing run names both its source lot and its resulting lot, and the corresponding lot link records the transformation, so the packed lot remains connected to the harvested lot it came from throughout the traceability chain.
Producers are the upstream counterparties of a cooperative, a producer group or a collection company. A producer carries 23 fields: producer code, name, linked Dolibarr third party, producer type, farm, town, region, phone, email, area in hectares, number of plots, main crop, certification, pay mode, purchase price per kilogram, quality bonus per kilogram, penalty per kilogram, quantity delivered, average quality percentage, reject rate, amount due, amount paid and a note.
Six producer types are supported: independent, cooperative member, group, sharecropper, integrated and under contract.
A producer delivery carries 25 fields: reference, delivery date, producer, campaign, plot, crop, variety, lot, weighing ticket, quality check, gross quantity, tare, net quantity, number of containers, quality grade, base price per kilogram, bonus, penalty, deduction, total amount, linked supplier order, linked supplier invoice, a paid flag, status and a note. Eight statuses follow the settlement: draft, received, weighed, controlled, accepted, refused, invoiced and paid.
Because the delivery names the weighing ticket and the quality check it was settled on, the price paid can always be justified against the measured weight and the measured grade.
A contract carries 24 fields: reference, label, contract type, third party, producer, campaign, crop, variety, start and end date, area committed, planned, minimum and maximum quantity, quantity delivered, base price per kilogram, price formula, quality criteria, bonus, penalty, payment terms, linked native Dolibarr contract, status and a note. Six contract types are supported: producer, customer, carrier, service provider, seasonal and cooperative.
The module does not reimplement purchasing. It attaches the harvest reality to the native Dolibarr purchasing chain at the points where money changes hands.
· Producers as third parties — each producer points at a native third party, so addresses, contacts, bank details, documents and accounting stay on the standard record.
· Deliveries into supplier documents — a producer delivery carries a link to a native supplier order and a link to a native supplier invoice, so the settlement of a delivery is a real accounting document and not a parallel ledger.
· Costs into supplier invoices — a cost entry can name the supplier third party and the native supplier invoice it originates from, which is what makes an input cost auditable.
· Equipment suppliers — an equipment record names its supplier third party, so purchase value, maintenance and spare parts stay connected to a real vendor.
· Settlement figures on the producer — quantity delivered, average quality, reject rate, amount due and amount paid are consolidated on the producer record, with the price structure - base price, quality bonus, penalty - carried on both the producer and the contract.
When the Supplier orders and invoices module is not enabled, the deliveries, the settlement amounts and the cost entries are still fully recorded and reported inside the module; only the links to the native supplier documents remain unused. No page fails and no figure disappears.
Sales follow the same principle: the module owns the physical product - the lot, its grade, its available quantity and its location - and hands the commercial cycle to the native Dolibarr chain of proposals, sales orders, shipments and customer invoices.
· Shared item master — a crop points at a native Dolibarr product and a lot carries the same product link, so a harvested lot is sold, shipped and invoiced as a standard catalogue item.
· Commercial destination — ten destinations are available on orders, operations, plans and lots: fresh market, industry, export, packing, processing, storage, local sale, out-of-grade, seed and forage.
· Commercial statuses on the lot — the lot status covers sold and shipped, and stock movements cover reservation and shipping issue, so the commitment of a lot to a customer is visible on the lot itself.
· Customer-specific quality — a quality control model can be attached to a customer third party and to a destination, which is how a customer specification is enforced before the goods leave.
· Customer contracts — a contract of type customer links a third party, a campaign, a crop, a variety, a committed volume and a price formula, and tracks the volume actually delivered against it.
· Traceability at the customer's request — the lot traceability page and the equivalent REST route rebuild the full record of a shipped lot on demand.
When the Shipments module or the Customer invoices module is not enabled, the lots, destinations, reservations and contracts continue to work exactly as described; only the corresponding native documents are not produced.
A cost entry carries 23 fields: reference, label, cost date, cost category, campaign, farm, plot, crop, order, operation, lot, team, equipment, producer, supplier third party, quantity, unit, unit price, actual amount, planned amount, linked supplier invoice, a validation flag and a note.
Sixteen cost categories are supplied: labour, equipment, fuel, transport, containers, packaging, quality, storage, refrigeration, packing, maintenance, outsourced services, product purchase, losses, overheads and other. Because a cost entry can name a campaign, a plot, a crop, an order, an operation, a lot, a team, a piece of equipment and a producer at the same time, the same amount can be analysed along any of those axes without being entered twice.
Every entry carries both the planned amount and the actual amount, which is what makes the budget overrun alert and the budget-versus-actual view possible at the level of a campaign rather than only at the level of the whole company.
Three settings supply the default valuation rates used when a resource is consumed without an invoice attached: the average labour hourly cost (13.50 by default), the average equipment hourly cost (28.00) and the reference fuel price per litre (1.62).
A dedicated profitability page consolidates the cost price and the gross margin by campaign, by plot, by crop and by producer, together with the cost breakdown by category and the planned budget against the actual cost.
· Cost price per kilogram — total validated cost divided by the net quantity harvested over the same campaign window.
· Gross margin — revenue minus total cost, in value and as a rate.
· Margin by axis — campaign, plot, crop and producer, so a loss-making plot cannot hide inside a profitable campaign.
· Cost structure — the share of each of the 16 cost categories in the total.
· Budget control — planned budget against actual cost, with the overrun raised as an alert.
· Producer settlement — amount due against amount paid, quantity delivered against contract commitment.
Reading margins and profitability is a dedicated right, separate from the right to read cost entries and disabled by default. A user can therefore be allowed to record costs without ever being allowed to see what the company earns.
The dashboard is the home page of the module: a harvest control centre covering production, quality, stock, cost and alerts over the running campaign window.
An eight-step strip follows the produce from the plot to the customer: Forecast, Planning, Harvest, Weighing, Control, Storage, Packing and Sale. Each step shows its live figure and links to the corresponding list, and the same cycle is also available as a full-page view.
Four gauges give the state of the campaign at a glance - completion rate, conformity rate, loss rate and share of the area harvested - followed by KPI tiles grouped in four zones.
Plot map and alert tiles
The dashboard embeds the plot map coloured by plot status and a row of alert tiles that link straight to the underlying records, so an anomaly is one click from the rows that caused it.
Twelve charts complete the page, covering the monthly harvest, the stock evolution, the yield by plot, the quantity by crop, by variety and by producer, the quality mix, the losses by cause, the costs by category, the operation statuses and the team productivity. The rolling window used by the monthly charts is itself a setting (12 months by default).
The reporting centre offers 35 reports grouped into 8 families. Every report accepts the same filters - campaign, period, farm and crop - and every report can be exported.
Total: 35 reports across 8 families.
Every report exports to CSV, Excel, Word and PDF. Exporting is a dedicated right, granted by default, and is separate from the right to import. Cell values are decoded before export, so an accented label or an ampersand reaches the exported file intact.
Beyond the reports, an import and export wizard generates a CSV template from the object registry, exports real data, and imports an uploaded file with column mapping, duplicate detection and an error report. Every run is written to the import log, which records the target object, the file name and format, the number of lines, the number of successes, failures and duplicates, the operator, the status and the error report. Importing is a distinct right, disabled by default.
The alert engine turns twelve business rules into recorded, addressable alerts. It runs from the daily scheduled job, and its results are shown on the dashboard and in a dedicated alert centre.
|
Alert |
What it detects |
|
Late harvests |
Open harvest orders whose planned date has passed by more than the configured grace period |
|
Lots awaiting control |
Lots left in the awaiting-control status |
|
Blocked lots |
Lots blocked or declared non-conforming |
|
Open non-conformities |
Non-conformities not yet closed |
|
Abnormal losses |
A loss rate above the configured threshold |
|
Critical stocks |
Available stock below the configured critical threshold |
|
Unavailable equipment |
Equipment broken down or stopped |
|
Operations without a team |
Open orders with no team assigned |
|
Budget overruns |
Actual cost above the planned budget of the campaign |
|
Documents nearing expiry |
Equipment inspections and maintenance dates coming due |
|
Old lots in stock |
Lots in stock beyond the configured age in days |
|
Significant forecast deviations |
A gap between forecast and actual beyond the configured tolerance |
Each detected alert is stored with 18 fields: reference, label, alert type, severity, timestamp, source object type and id, campaign, plot, lot, recipient user, channel, measured value, threshold, acknowledgement date, acknowledging user, status and a note. Storing the measured value next to the threshold means an alert can be judged without re-running the query that produced it.
Six alert statuses are available: new, taken, in progress, resolved, closed and ignored, and five channels: Dolibarr message, email, agenda, dashboard and hook. An alert already open for the same object and the same type is not duplicated on the next run.
Three settings govern notifications: whether the alert engine is enabled (on by default), whether alerts are also sent by email (off by default) and the number of days after which a harvest order is considered late (2 by default). The RclCronAlerts job runs the daily checks; both scheduled jobs are created at activation and left disabled so the administrator decides when they start.
Every operational object carries an explicit status vocabulary rather than a free text state. The status values are validated server-side against the vocabulary, so a hand-crafted request cannot store an arbitrary state.
The operational chain runs forecast, plan, order, field operation, weighing, lot, quality check, storage, packing and sale. Each step creates or updates the record the next step consumes, which is why the traceability page can be rebuilt from stored links alone rather than from inference.
Every significant transition is written to the event log with 14 fields: reference, timestamp, event code, origin, object type, object id, object reference, author, field name, old value, new value, IP address, result and a comment. Fifteen event codes are supplied, including creation, modification, validation, status change, quantity correction, weighing correction, blocking, release, merge, split, deletion, export, import, demonstration seeding and demonstration purge.
Access control is built on 15 permission groups, one per business domain, giving 58 individual rights. Read and write are granted by default so the module is usable immediately after activation; delete, every special right, demonstration management and administration are disabled by default.
Each group carries three rights - read, write and delete - which is what allows a user to be given the ability to record data in a domain without the ability to erase it.
The three levels are deliberately independent. Read grants access to the lists, the cards, the dashboard tiles and the API read routes of the domain. Write grants creation and modification, and is the level most operational roles need. Delete is a third, separate right, disabled by default on all 15 groups, because in a traceable chain the removal of a lot, a weighing ticket or a quality check is a materially different act from correcting it.
On top of the 45 domain rights, eight rights isolate the acts that carry business or legal weight, plus reporting, import, demonstration and administration rights.
Each special right corresponds to an act that cannot be undone by simply editing a field. Correcting a weighing changes the quantity a producer is paid for. Validating a quality control decides whether goods may be sold. Blocking a lot stops a shipment. Reading margins exposes what the company earns. Granting write access to a domain does not grant any of them.
· Permission checks everywhere — every page and every API route checks the right of its own domain before doing anything; the API maps each of the 37 object types to its permission group explicitly rather than falling back to a default.
· Multi-company scoping — every table carries an entity column and every query filters on the current entity, so one company can never read another's harvest.
· SQL escaping and whitelisting — values are escaped, and identifiers that cannot be parameterised - the sort field and the filter column of the API - are whitelisted against the physical columns of the table before being used.
· Output escaping — user-controlled values are HTML-escaped on output on every page.
· CSRF protection — form submissions go through the standard Dolibarr token mechanism.
· Closed vocabularies — settings and status values are validated server-side against their vocabulary: booleans collapse to 0 or 1, numbers are cast and clamped to their declared range, and list values are checked against the list that feeds their selector.
· Full audit trail — the event log records the object, the field, the old and new value, the author and the IP address of every traced change.
The module ships five complete language files. Each file contains exactly 1657 translation keys, so no language is a partial translation of another and no screen falls back to English in a French or Spanish installation.
|
Language |
Locale |
File |
Keys |
|
French |
fr_FR |
langs/fr_FR/recoltes.lang |
1657 |
|
English |
en_US |
langs/en_US/recoltes.lang |
1657 |
|
Spanish |
es_ES |
langs/es_ES/recoltes.lang |
1657 |
|
Italian |
it_IT |
langs/it_IT/recoltes.lang |
1657 |
|
German |
de_DE |
langs/de_DE/recoltes.lang |
1657 |
The translation surface covers the module and menu names, the 24 menu groups and their entries, every field label of the 37 objects, the 77 controlled vocabulary domains and all of their codes, the dashboard tiles, gauges and chart titles, the 35 report titles and column headings, the 29 settings with their help texts, the alert labels, the permission labels and every confirmation and error message.
Every key is prefixed with Rcl. Dolibarr merges the language files of all active modules into a single lookup table, so an unprefixed key such as Status or Quantity would silently render another module's wording. The prefix guarantees the module always displays its own vocabulary whatever else is installed.
A sixth language is added by copying an existing file to langs/<locale>/recoltes.lang and translating the right-hand side of each line. No code change is required.
Harvest Management reuses the Dolibarr core instead of duplicating it. Two modules are declared dependencies and must be enabled; all the others are optional and are shown with their live state on the Integrations tab of the setup page.
|
Module |
Used for |
|
Third Parties (modSociete) |
Farms, producers, carriers, customers, suppliers and equipment vendors are native third parties; contacts are used for workers |
|
Products and Services (modProduct) |
Crops, lots and packing runs point at native products, which is what makes a lot sellable and stock-manageable |
Every optional integration is guarded. When the corresponding module is off, the feature that depends on it is simply not offered: no page returns a fatal error, no list disappears and no indicator becomes blank. The Integrations tab shows the live state of each of the nine optional modules, so an administrator can see at a glance which capabilities are currently active.
· Users and permissions — 22 object fields point at native users; rights are managed in the standard user and group screens.
· Scheduled jobs — the two cron jobs are registered with the native scheduled jobs module.
· Dashboard widget — a module box is registered and can be added to the Dolibarr home page.
· Documents and PDF — labels and report exports are produced with the standard PDF engine shipped with Dolibarr.
· Multi-company — every table and every query is entity-scoped.
The module exposes a REST API served under /api/index.php/recoltes/. Authentication uses the standard Dolibarr DOLAPIKEY header, and every route checks the permission group of the object family it touches before answering.
Total: 44 declared routes.
Every list route accepts sortfield, sortorder, limit, page and sqlfilter. The page size is clamped between 1 and 500, the page number is zero-based, the sort order is reduced to ASC or DESC, and both the sort field and the filter column are checked against the physical columns of the table before use. A listing answers with the object type, the table, the total row count, the page, the limit, the number of rows returned, the records themselves and the publisher.
The following call returns the fifty most recent Extra-grade lots, newest first:
curl -X GET \
-H "DOLAPIKEY: your_api_key_here" \
"https://erp.example.com/api/index.php/recoltes/lots?sortfield=datetime_harvest&sortorder=DESC&limit=50&page=0&sqlfilter=quality_grade:extra"
The same key, applied to /api/index.php/recoltes/lots/42/traceability, returns the complete record of lot 42: its origin (campaign, farm, plot, crop, variety, producer, order, operation), its weighing tickets, its quality checks, its non-conformities, its losses, its stock movements, its transports, its parent and child lots and its open alerts.
The module ships a complete demonstration dataset describing a fictitious three-farm operation across two farming campaigns. It is generated at activation and can be reinstalled or removed at any time from the setup page.
Three farms in Provence, the Drome and the Gard, seven crops (tomato, strawberry, apple, apricot, table olive, courgette, lettuce), twelve varieties, five producers, twelve plots spread deliberately across every meaningful plot status, two campaigns of which one is running, ten storage locations, four teams, sixteen workers, twelve pieces of equipment, five quality control models with fifty criteria, ten contracts, and the full operational chain of forecasts, plans, orders, operations, weighings, lots, quality checks, non-conformities, losses, timesheets, transports, stock movements, packing runs, producer deliveries, costs, alerts and log entries.
Total: 2171 rows across the 37 module tables, plus 19 native Dolibarr records (8 third parties, 10 products and 1 project) created so the integration points are demonstrated as well.
The generator is deterministic: the same installation always produces the same figures. The running campaign spans the last twelve months plus two months ahead so every campaign-scoped indicator has data inside its window, every workflow stage is populated so no status filter returns an empty list, and a small number of records are deliberately placed in an alerting state - a campaign over budget, two contracts short of their minimum volume - so the alert tiles show real content rather than zeros.
The Demonstration data tab of the setup page shows the number of demonstration rows currently present and offers two buttons:
· Install the demonstration data — generates the complete dataset and reports the number of rows created.
· Remove the demonstration data — asks for confirmation, then deletes the dataset and reports the number of rows deleted.
Every generated row carries the import key RECOLTEDEMO, including the native third parties, products and project, so the purge removes exactly what was generated and nothing else. The purge runs inside a transaction and cascades to records a user may have created underneath a demonstration parent, so it never leaves an orphan pointing at a deleted row. Real data is never touched. Managing the demonstration dataset is a dedicated right, disabled by default.
|
Component |
Requirement |
|
Dolibarr ERP and CRM |
Version 16.0 or later (validated on 17.x and later) |
|
PHP |
PHP 8.x recommended; the module declares a minimum of PHP 7.1 |
|
Database |
MariaDB or MySQL, InnoDB, UTF-8 |
|
Web server |
Apache or Nginx with PHP-FPM |
|
PHP extensions |
The standard Dolibarr set: mysqli, mbstring, gd, curl, zip, intl |
|
Browser |
Any modern browser: Chrome, Firefox, Edge or Safari, current versions |
|
Mobile use |
The field entry page is designed for phone and tablet screens |
|
Disk space |
About 6 MB for the module; the demonstration dataset adds a few megabytes to the database |
|
Required Dolibarr modules |
Third Parties and Products and Services |
|
Optional Dolibarr modules |
Stocks, Projects, Contracts, Agenda, Interventions, REST API, Shipments, Customer invoices, Supplier orders and invoices |
The module installs into htdocs/custom/ and does not modify any core file. It creates its own 37 tables at activation and self-heals its schema on upgrade, adding any column introduced by a later version automatically.
The module is delivered as a single archive, module_recoltes-1.0.zip. Deploy it from the Dolibarr interface:
· Log in to Dolibarr with an administrator account.
· Go to Home, then Setup, then Modules/Applications.
· Open the Deploy/install external app/module tab.
· Select module_recoltes-1.0.zip and upload it.
· Wait for the confirmation that the module has been deployed into htdocs/custom/.
If the deployment tab is disabled on your installation, unzip the archive manually into htdocs/custom/ so that the folder htdocs/custom/recoltes exists, and make sure the files are readable by the web server user.
· Still under Home, Setup, Modules/Applications, find Gestion des Recoltes (Harvest Management) in the Products family.
· Click the on switch. Activation creates the 37 tables, the 58 permissions, the menu tree, the 29 settings and the two scheduled jobs, and generates the demonstration dataset.
· Check that the Harvest Management entry now appears in the top menu.
Open the module setup page from the gear icon next to the module, or from the Administration entry of the module menu. The settings are grouped in eight tabs: General, Harvest, Weighing, Quality, Stocks, Costs, Notifications and Documents, plus an Integrations tab showing the live state of the nine optional Dolibarr modules and a Demonstration data tab.
Go to Users and Groups, open a user or a group, and use the Permissions tab. Read and write rights of the 15 groups are granted by default; delete, the eight special rights, demonstration management and administration must be granted explicitly.
The two cron jobs, RclCronAlerts (daily alert computation) and RclCronIndicators (indicator refresh every six hours), are created disabled. Enable them from the Scheduled jobs page once the module is configured.
Deploy the new archive over the previous one and re-enable the module. Tables are never dropped, and any column added by the new version is created automatically. Disabling the module removes only its menus, rights and settings: the data is kept.
Developed and copyrighted by DoliResources - www.doliresources.com
Harvest Management (Gestion des Recoltes), version 1.0.0, module number 712000, is designed, developed, published and maintained by DoliResources. Copyright (C) 2026 DoliResources.
The module is distributed under the GNU General Public License version 3 or later, in line with the licensing of Dolibarr ERP and CRM. It is provided in the hope that it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details.
Dolibarr is a registered trademark of the Dolibarr Foundation. All other trademarks quoted in this document belong to their respective owners.
This document describes version 1.0.0 of the module. Figures, field counts, vocabularies, routes and settings quoted in it are taken directly from the module source code.
Support, updates and commercial enquiries: www.doliresources.com
Developed and copyrighted by DoliResources - www.doliresources.com
