Short answer. Every physical unit has its own row: serial number scanned at reception, unique per product by database constraint, format checked when one exists. It has one state at a time, in stock, sold, in repair, at the supplier, on loan, exchanged, scrapped, and every transition is dated, signed and linked to a document. The sale links the serial to the customer, the invoice and the hand-over date; the warranty is a start date, a term written by the manager on the product or the supplier lot, and a day counted at return, not a ticked box. At return, one repair order per unit carries the diagnosis, photos, parts, dated states, the supplier claim with its measured delay, and the exchange that links a new serial to the same customer. The manager reads a board that says who holds each unit and for how many days.
This guide is for the phone and electronics reseller, the appliance and air-conditioning distributor, the solar installer who fits inverters, the seller of medical equipment or power tools, and the founder based in France who wants to know, from their phone, how many devices are at suppliers and since when. It does not repeat how a complaint ticket is tracked, described in the after-sales guide, nor how a lot of perishable goods is traced, described in the lot traceability guide: a lot is a group of identical units, a serial is one unit. Warranty conditions, term, exclusions, what is covered, are what the seller or manufacturer writes; this guide does not say what a law requires, it builds the application that counts the days and records the decision.
A device comes back to the counter, in six beats
The warranty decision is the accented beat: it is taken at intake, from a date and a term, and it is signed.
Scan the serial: the seller reads the number on the label, in the phone's settings or on the appliance plate, with the camera of the application's phone; the format is checked when one exists, and a number that fails the check is flagged, not refused, because damaged labels exist. Find the unit: the serial returns the unit's row or nothing; if it exists, the screen shows the customer, the hand-over date, the invoice and the current state; if it does not, the device was not sold here, and the flow switches to a paid quote. Decide the warranty: the application counts the day since hand-over, compares it with the term written on the product, and shows “day 187 of 365”; the seller confirms or refuses for a coded reason, breakage, liquid, opened, and the decision is signed with their name and the time.
Open the order: one repair order per unit, with the diagnosis, intake photos of the device as in the trustworthy photos guide, the fault reproduced or not, and a receipt sent to the customer on WhatsApp or printed as in the printing guide. Repair or claim: the workshop orders the part, and the order moves to “waiting for part” with the expected date; or the unit leaves for the supplier with a numbered claim, and the order moves to “at the supplier” with the departure date. Return and close: the same unit comes back repaired, or another unit comes back in exchange; the new serial is linked to the customer, the old one leaves stock as exchanged; the customer signs on screen, the order is closed, and the unit returns to “with the customer”.
The life of one unit: received, sold, returned, exchanged
The figure follows a phone over eight months. Everything the counter needs to know at return is already written before the return.
Reception: on 3 February the box is scanned at the reception of the lot traceability guide; each unit in the box becomes a row with its serial, its supplier lot, and the 24-month supplier warranty running from that day, because that is what the supplier wrote on its note. Sale: on 11 March the invoice carries the serial, and it is the hand-over date that starts the 12-month seller warranty, not the order date nor the payment date; a device paid online and collected three days later has three more days. Return: on 14 September the counted day is 187; the seller warranty says yes, and the supplier warranty is still running, so a claim leaves on the 17th with the photos and the diagnosis.
Exchange: the supplier sends back another unit on the 28th; its serial is unknown, the application creates it at reception, links it to the customer and the order, and gives the old one the state “exchanged”, a final state: it can no longer be sold or lent, and if it reappears in a scan, the application says so. The customer gets a device with a new serial and the same warranty, which continues or restarts according to the rule the manager wrote for exchanges. What is measured on the way: eleven days at the supplier, recorded against them, and those days are where the median delay per supplier on the next board comes from.
«A warranty is not a ticked box: it is a hand-over date, a written term, and a day counted at return; a person decides, the application counts.»
The repair board: seven units, who has them, for how many days
The figure is the morning screen: one row per unit, never per call, and a bar of days against a threshold.
The columns: the order, the unit with its product and serial ending, the state, the days elapsed since drop-off as a bar, the decided warranty with the counted day, and who holds the device. The threshold: 14 days at the supplier in the example, written by the manager; beyond it, the row turns accented, a chase leaves for the supplier with the claim number, and the customer receives a message saying where their device stands, as in the notifications guide. Two units are beyond it and have been chased twice and three times; it was not the seller who remembered.
The three tiles: seven open orders, two beyond the threshold, and nine days median time over the last ninety closed orders, from drop-off to return to the customer; that last figure also reads per supplier, and it is what feeds the conversation with the supplier who keeps devices for a month. The customer sees their own row in the customer space of the after-sales guide: state, date of the last change, and nothing else. The out-of-warranty inverter: day 410 of 365, the quote left the same day from the price engine of the quote guide, with a deposit on approval; the workshop does not touch the device before.
Unit tracking, in five layers
State is the accented layer: a unit has one state, and it is that constraint that prevents selling the same serial twice.
Identity. One row per physical unit, created at the reception scan, never typed; the serial is unique per product by database constraint, so a second box with the same serial is refused at reception, with a photo of the label, and the supplier is told. When the number has a known format, it is checked: an IMEI has 15 digits, the last being a check digit, according to the common description of that format; a number that fails the check is flagged as doubtful, not proven false, because the application cannot know whether the label is fake or misread. Which products are tracked by serial is chosen by the manager in the product record of the catalogue guide; a cable is not, a phone is. State. One state at a time, and allowed transitions: in stock to sold or on loan, sold to in repair, in repair to at the supplier, on loan or returned, at the supplier to returned or exchanged; any other transition is refused by the code, not by an instruction. Every transition is dated, signed by the logged-in person as in the roles guide, and linked to the document that caused it: invoice, order, claim. Stock by serial is a reading of these states, and it reconciles with the movement ledger of the stock guide.
Warranty. Two warranties per unit, at least: the seller's, running from hand-over to the customer, and the supplier's, running from reception; each has a term written by the manager on the product or the lot, and can be extended by a sold extension, which is one more row with its own term. At return, the application counts and shows; a person decides and signs; refusals have a coded reason, and the refusal rate per reason is measured. Repair. One order per unit: diagnosis, intake and exit photos, consumed parts that leave stock, dated states, supplier claim with its number and measured delay, loan unit linked to the order, exchange that creates the new unit and closes the old one. Measurement. Return rate per product and per supplier lot, because a lot that returns at 9 % when the product returns at 2 % is a lot to claim as a whole; median repair time; delay per supplier; orders beyond the threshold; refused warranties and reasons. These figures land in the manager's dashboard with their written definition beside them.
«A unit has one state at a time, and it is that database constraint, not an instruction at the counter, that prevents selling the same serial twice or forgetting a device at a supplier.»
Six real situations, and what the application does
Each row is a sentence heard in a shop that sells devices, and the answer is a constraint, not suspicion.
The customer no longer has the receipt: the serial finds the sale, the hand-over date and the invoice; the decision takes ten seconds, and it is the same whoever is on duty. The device was not bought here: the serial is unknown, the flow switches to a same-day paid quote with a deposit, and the repair stays possible, but it is sold. Two boxes carry the same serial: the uniqueness constraint refuses the second reception, the receiver photographs the label, and the claim to the supplier leaves with the photo; without that constraint, the second unit would be sold under the first one's row, and the day one comes back, nobody knows which.
The unit has been at the supplier for a month: the claim is dated, the threshold is written, the chase leaves on its own, and the delay is measured per supplier; after three chases, the row goes up to the manager. The supplier exchanges the device: the new serial is created at reception and linked to the customer; the old one becomes “exchanged”, a final state, and can no longer be sold or lent. A loaner that does not come back: the loan unit is linked to the order, moves to “on loan”, and at the closing of the order without the loaner's return, the application blocks the closing or alerts, according to the written rule; the stock of loan units is a reading of states, not a notebook.
Tracking units in 2027, in weeks
Seven weeks, the first without code, and two for identity and state, because warranty and repair are only readings of those two layers.
- What the manager sees: the morning board, the units at each supplier and for how many days, the week's warranty decisions and their reasons, the products and lots that come back too often.
- What the seller no longer does: search a notebook, call the boss over a lost receipt, repair for free in doubt, forget a device at a supplier.
- What is measured: return rate per product and lot, median repair time, delay per supplier, orders beyond the threshold, refused warranties and reasons, loaners not returned.
Week 1, rules: which products are tracked by serial and which are not, warranty terms per product and per supplier, the chase threshold, the states and allowed transitions, who decides a warranty and who may refuse it; with the manager and the workshop lead. Weeks 2 and 3, identity and state: serial scanned at reception, uniqueness in the database, format check where one exists, states and transitions dated and signed, sale linking the serial to the customer and the invoice, stock reading by serial. Week 4, warranty: start date, written term, day counted at return, signed decision with reason, paid quote out of warranty or for an unknown serial.
Week 5, repair: order per unit, diagnosis and photos, parts out of stock, numbered supplier claim, exchange, loan, morning board and chases at the threshold. Week 6, take-over: the serials of units in stock are scanned once, as a count, as in the data take-over guide; past sales are linked from invoices where the serial appears, and other units already sold are created at their first return, with the paper invoice photographed as proof of the date. Week 7, measurement: return rate per product and lot, median time, delay per supplier, refused warranties by reason, Monday review.
- Which products deserve tracking by serial?
- Those with a warranty, a value or a risk of dispute: phones, computers, appliances, air conditioners, inverters, power tools, medical equipment. A consumable or an accessory stays tracked by quantity, and by lot if it expires, as in the lot guide. The choice is made product by product in the record, and it can change.
- What happens if the label is unreadable or the number looks wrong?
- The application accepts a typed number but marks it as typed, not scanned, with the label photo; a number that fails a known format check, such as an IMEI check digit, is flagged as doubtful, and a person decides. The application cannot tell a counterfeit from a damaged label, and it does not claim to.
- Where does the warranty start: order, payment or hand-over?
- From hand-over to the customer in this guide, because that is the day the device leaves the shop; it is the date written on the “sold” transition. If the seller or manufacturer writes another rule, the manager changes it in the rules, not in the code. The warranty conditions themselves, what is covered and what is not, are the seller's or the manufacturer's; this guide does not say what a law requires.
- How does the application know a unit has been at the supplier too long?
- Through the “at the supplier” state dated at departure, the threshold written by the manager, and a background job that compares every night; beyond it, the chase leaves with the claim number, the customer is told, and after a written number of chases, the row goes up to the manager. The days spent at each supplier are kept, and the median delay per supplier helps choose whom to buy from.
- And a device sold before the application, whose serial we do not have?
- It is created at its first return: the serial is scanned, the paper invoice is photographed as proof of the hand-over date, and the row is marked “taken over”, so that measurement distinguishes these units. Past sales whose invoice already carries the serial are linked at take-over, by reading the invoices, without retyping.
- Does this replace after-sales ticket tracking?
- No, it complements it: a ticket from the after-sales guide is a conversation with a customer, a repair order is the story of a unit. A ticket can carry an order, and an order can start without a ticket when the customer walks in. The customer space shows both.
- How long to set this up?
- Seven weeks in the typical calendar, the first without code and two for identity and state. A shop that already has scanned reception and the product record of the catalogue guide takes less; a distributor with several depots and suppliers who exchange a lot takes more, the time to write the state transitions with each of them.