Solar Module Serial Number Traceability and Warranty Tracking in Odoo

A customer calls about a module installed 29 months ago. It's producing less power than it should.

Before anyone can judge the claim, your support team needs answers to eight questions. Which supplier made the cells? Which cell lot went into this module? Which manufacturing order built it? Did it pass EL and flash testing? What was its power output before dispatch? Which dealer received it? When and where was it installed? Is it still under warranty?

If those answers sit in separate Excel files, production registers, QC sheets and dispatch books, the investigation starts with hours of searching. In Odoo, they can all hang off one record: the module's serial number.

This post walks through that setup step by step, using one illustrative production run of 100 modules. For the wider plant picture, from imported cells and BoMs to dealer sales, see our Odoo ERP guide for solar module manufacturing.

Key Takeaways

• Odoo tracks incoming cells by lot and finished modules by unique serial, so one scan can reach the MO, cell lot and supplier.
• Lot, serial, quality, barcode and delivery records are standard Odoo. Per-serial tester readings and installation-based warranty clocks usually need integration or custom work.
• A low-power complaint is a performance-warranty question. It's settled by comparing a field reading against the warranted curve and the module's original flash-test value.

What does a solar module's traceability chain look like?

It's seven linked records, one per stage, and each one has to be captured when the event happens. Miss the cell lot at the receiving dock and no later scan can recover it. The chain only works backwards if every department wrote its link forwards.

The first five stages are standard Odoo. The last two are where most manufacturers need design work, and we'll be specific about why.

How do you set up solar module traceability in Odoo, step by step?

Six steps, run on one example: a manufacturer receives a cell shipment, builds 100 modules on one manufacturing order, and ships them through its dealer network. Every reference below (lot, MO, serial, delivery) is illustrative, but the records and settings are the ones you'd configure in Odoo Inventory, Manufacturing, Quality and Barcode.

Step 1: Record the cell lot at goods receipt

The chain starts at the receiving dock. The cell shipment arrives and gets the internal lot CELL-LOT-2026-001. Against that lot, the warehouse records the product and internal reference, the supplier, the supplier's own batch number, the quantity received and the receipt date.

To set this up:

• Turn on Lots & Serial Numbers in Inventory settings.
• On the solar cell product, set tracking to By Lots.
• On the receipt operation, require a lot before the receipt can be validated, and store the supplier batch reference on the lot.

From here, Odoo knows where the lot was received, how much is left, and every location it moves to next. If the same shipment also carries freight and customs duty, that cost rides on the same receipt. Our post on Odoo landed cost for imported cells covers that side.

Step 2: Consume the actual cell lot on the manufacturing order

Planned consumption isn't enough. The BoM says a module needs 144 cells; it doesn't say which lot they came from. The operator has to record the lot actually drawn from stores.

Set the module up as a manufactured product with a BoM, keep lot tracking on the cells, and make the lot mandatory when components are consumed. If a run draws from two lots, record both, with quantities. A module built from mixed lots is still traceable. A module whose lots were never entered isn't.

Step 3: Give every finished module its own serial

A lot identifies a group of material. A serial identifies one physical product. For solar modules that difference matters: a warranty claim is about one panel on one roof, not a production batch.

Set the finished module's tracking to By Unique Serial Number and generate the serials when production is recorded on the MO. A readable pattern such as SPM-2026-00001 to SPM-2026-00100 works well, because a support agent can tell the product line and year at a glance.

What should the QR code on the label hold? Just the serial. It doesn't need to carry the manufacturing history. When it's scanned in Odoo, the serial opens the record, and Odoo's traceability report on that serial shows every linked move upstream and downstream. The label stays simple. The history stays in the ERP, where it can be corrected and controlled.

Step 4: Attach EL and flash-test results to the serial

Quality data is what turns a serial number from an inventory tag into evidence. A typical module line has several checkpoints:

Odoo Quality lets you define control points on an operation and pick a check type: Pass/Fail for visual inspection, Measure for a flash-test value against a tolerance, Take a Picture for an EL image.

Here's the catch most implementations find late. Recording "this batch passed flash testing" is not the same as keeping 100 separate power readings against 100 serials. A warranty investigation needs the second. Getting one reading per serial reliably, at line speed, usually means pulling values straight from the flash tester and EL station rather than having someone type them. That's equipment integration work, and it's worth scoping before go-live, because a value typed by hand 2,000 times a day is a value that drifts.

Step 5: Scan the serials that actually leave the warehouse

Dispatch is where the module's location stops being "our warehouse" and becomes "Dealer A". The picking has to record the exact serials loaded, not just a quantity.

Odoo Barcode supports scanning serial-tracked products during picking and delivery validation. With tracking set to unique serial, Odoo won't validate the delivery until a serial is recorded for every unit. Whether a handheld reads your label's QR code depends on the scanner and the label format, so test both before printing 10,000 labels.

Step 6: Register the installation against the serial

Dispatch isn't installation. A module can sit in a dealer's warehouse for weeks before it reaches a roof, and many warranty terms start their clock from installation, or from a set period after dispatch, whichever comes first. If you never capture the install date, you can't apply your own warranty clause correctly.

An installation record should hold:

• Module serial
• Customer or project name
• Site address and location
• Installation date
• Installer or installation partner
• Dealer or distributor reference
• Installation confirmation, plus site photos where your policy needs them

Standard Odoo gives you the serial, customer, dealer and delivery. It doesn't give you an installation-registration flow or a warranty clock that starts from it. Those get built around your actual warranty policy: a registration form (often dealer- or installer-facing), a warranty record per serial, start and expiry dates calculated from your clause, an eligibility check, and a claim workflow.

Step 6: Register the installation against the serial

Dispatch isn't installation. A module can sit in a dealer's warehouse for weeks before it reaches a roof, and many warranty terms start their clock from installation, or from a set period after dispatch, whichever comes first. If you never capture the install date, you can't apply your own warranty clause correctly.

An installation record should hold:

• Module serial
• Customer or project name
• Site address and location
• Installation date
• Installer or installation partner
• Dealer or distributor reference
• Installation confirmation, plus site photos where your policy needs them

Standard Odoo gives you the serial, customer, dealer and delivery. It doesn't give you an installation-registration flow or a warranty clock that starts from it. Those get built around your actual warranty policy: a registration form (often dealer- or installer-facing), a warranty record per serial, start and expiry dates calculated from your clause, an eligibility check, and a claim workflow.

How does a warranty investigation work in Odoo?

It starts from the serial and ends with evidence, not a guess. Say the customer reports on 15 June 2028 that module SPM-2026-00001 is underperforming. Support scans the label or searches the serial and gets the linked records in one place.

Odoo Helpdesk can log the complaint against the product and serial, and a repair order can be marked as under warranty. The decision on whether the claim is valid is where most setups go wrong.

Is low power a product-warranty or a performance-warranty claim?

It's a performance-warranty question, and that changes what you check. Module makers usually give two separate warranties: a product warranty covering defects in materials and workmanship, and a performance warranty that guarantees a minimum share of nameplate power for each year of service. A complaint that a module "isn't making enough power" belongs to the second.

So the check isn't just "is it still within the warranty period?" It's "is the measured output below what we guaranteed for this year?" Take an example performance clause: at least 98% of nameplate in year 1, then no more than 0.55 percentage points lost each year after that. At 2.4 years, the guaranteed minimum is 98% − (1.4 × 0.55%) ≈ 97.2% of 565 Wp, or about 549 W.

Example performance warranty curve vs field reading 100% 95% 90% 85% 80% 0 5 10 15 20 25 Years in service Guaranteed at 2.4 yrs: 97.2% (549 W) Field reading: 93.5% (528 W) Example warranty curve

Illustrative performance warranty: 98% of nameplate in year 1, then −0.55 points a year to 84.8% at year 25. Example terms only, not any manufacturer's actual policy.

If a site test, corrected to standard test conditions, shows 528 W, the module sits about 21 W under the guarantee. That's a claim worth investigating. The factory flash reading adds a second signal: the module left at 570.3 W, slightly above nameplate, so it has lost about 7.4% in 2.4 years. That's well beyond the example curve, and it points the technical team toward the module itself rather than a borderline power-class assignment.

None of this proves the cell lot caused the problem. What it does is put the factory reading, the EL results, the MO, the lot and the supplier in front of the engineer on day one, instead of week two.

What if a supplier reports a defective cell lot?

You trace forwards instead of backwards. The supplier tells you CELL-LOT-2026-001 may have a defect, and you need every module built from it. Because the lot is linked to MO/2026/0042 and the MO is linked to 100 serials, Odoo's traceability report on the lot lists them all, along with where each one is now.

Without the link, the options are a blanket hold on every module from that month or a guess. With it, you quarantine 20, call the dealers holding 30, and send engineers to 50 known addresses. The 50 installed modules only show up here if Step 6 was done. A recall view built on the same data can show the live split by location while the response runs.

What does it take to make serial traceability reliable?

Discipline in six departments, not one software setting. Odoo can't recreate a link nobody recorded. If the cell lot isn't entered at receipt, or the MO records planned instead of actual consumption, scanning the module two years later shows a gap exactly where you needed the answer.

Odoo gives you the structure. The receiving dock, the line operator and the dispatch team make it trustworthy.

Make every module answer for itself

A finished module shouldn't become anonymous the day it leaves the plant. Its serial should lead back to its cell lot, MO, test readings, dealer, install site and warranty status in one search.

Odoo Inventory, Manufacturing, Quality, Barcode and Sales cover most of that chain through configuration. The parts that need design are per-serial tester data, installation registration and warranty logic built on your actual policy. For the rest of the plant, from landed cost to power-class binning, read our Odoo ERP guide for solar module manufacturing.