All guides

Traceability · 8 min read

Proving which device you shipped, a year later

Disputes are not won by remembering. They are won by a record that was written before anyone was arguing, and that still says the same thing months later.

The MARGIXA teamPublished

Two months after a sale, a buyer opens a case: the phone is not the one they ordered, or the battery is worse than the listing said. Your answer is worth exactly as much as the record you wrote before anybody was arguing.

The short version

  • Every unit carries a master key: the IMEI, serial or part number that identifies that physical device and no other.
  • The device is scanned at ship, against the order. The wrong unit is refused before it goes in the box.
  • The inspection stores the questions with the answers, so a record from March still reads correctly after you edit the checklist in September.
  • One lookup shows where a unit came from, what it cost, how it was graded, what it sold for and to which order.

What a dispute actually asks you

Strip the emotion out of a marketplace case and there are only ever three questions: which device did you send, what condition was it in when it left, and can you show that. Merchants lose cases they should win because the answer lives in three places that were never joined up: a spreadsheet of IMEIs, a grading sheet on a clipboard, and somebody’s memory of a busy Thursday.

The fix is not better argument. It is a record written at the moment the work happened, by the person doing it, that nobody has to reconstruct afterwards.

One key per unit, defined per category

In MARGIXA every physical unit carries a master key. For a phone that is the IMEI. For a laptop or a watch it is the serial. For a component it might be a part number. Which field plays that role is defined per product category, so you are not forced to pretend everything has an IMEI.

The key is unique across the units you currently hold, and it is what everything else hangs from: the purchase that brought it in, the grade it was given, the shelf it sits on, the order it left with. Search on it, or on the last few digits of it, and you get that one device rather than a model.

The difference this makes is the difference between knowing you sold an iPhone 12 and knowing you sold that iPhone 12. Only one of the two survives a dispute.

The check happens at the last possible moment

A pick list is correct when it is printed and decreasingly correct afterwards. So the verification in MARGIXA is not at picking, it is at shipping, against the device physically in someone’s hand.

The MARGIXA ship form for a marketplace order, showing the product, the expected master key field with a scan input, and the label and ship actions.
Demo workspace, sample data. The scan field is the gate. The order knows what it expects, so a unit that is not that unit is refused here rather than discovered by the buyer.

Scan the device, and if it is not the one the order expects, the form says so and will not continue. If it is, the label prints and the unit is marked sold against that order, with its key on the record. There is no step where somebody types an IMEI from a label into a second system, which is the step where digits get transposed.

The same scan is what lets an invoice carry the serial of the exact device the buyer received, which turns a “you sent me a different one” case into an afternoon instead of a fortnight.

The inspection, frozen with its questions

Most systems store grading answers as values against field identifiers. That is fine until you edit the checklist, and then every historical record quietly becomes unreadable: you have the answer and no longer have the question.

MARGIXA stamps the question and the answer together at the moment of grading. The template can change as often as you like; a record written in March still says exactly what was asked in March and what the technician replied. A question you delete later stays on the units that were graded with it, because deleting a question does not un-ask it.

Alongside the answers, the record keeps:

  • The grade given, and the battery condition.
  • Who graded it, when, and how long it took on the bench.
  • Any override, and the note the grader wrote.
  • Earlier inspections, if the unit was re-graded, each with its own questions.

An answer without its question is a number without meaning. That is the whole reason this is stored the way it is, and it only becomes obvious the first time someone asks you about a grading decision from six months ago.

The whole life of a unit, on one card

Put a master key into the lookup and you get the device: where it came from, what you paid, what it was graded, where it lived, what it sold for and on which order.

A device card in MARGIXA History Lookup showing the master key, status, location, supplier, purchase invoice, cost, and the sale with its order, date, price and margin.
Demo workspace, sample data. Purchase cost on the left, the sale on the right, and the margin on that specific unit between them. Not the model average: this device.

The margin line is the one merchants stop on. It is computed from what that unit cost, not from an average for the model, which means two identical phones bought three months apart show honestly different numbers. When a purchase price was never recorded, the card says so rather than quietly assuming one.

And the things that do not have serials

Cases, cables, chargers and screen protectors do not carry a unique identifier, and pretending otherwise creates work without creating truth. Those are handled as quantities against a barcode instead, and when a batch is split the barcode goes to the children unchanged, so a box you labelled last year still scans to the right thing this year.

Serialised and bulk stock live in the same inventory and the same listings. The difference is only how precisely a single item can be identified, and it is worth being clear about that rather than claiming a level of traceability accessories cannot have.

Checklist

What a record has to carry to be worth anything in a dispute

  • A unique key on every serialised unit, defined per category rather than assumed to be an IMEI.
  • Verification at ship, against the physical device, not at picking.
  • The inspection questions stored with their answers, not answers against field ids.
  • Who graded it and when, kept alongside the result.
  • Re-grades kept as history rather than overwriting the first answer.
  • The unit’s serial on the invoice the buyer received.
  • Purchase cost per unit, so the margin figure is real.
  • No buyer database: fetch their details when needed, do not store them.

See it in the demo. The video opens at shipping without mistakes.

For the sharpest picture, open Settingsin the player, chooseQuality · 2160p (4K)and watch it full screen.

Questions we get asked

What counts as the master key?

Whatever uniquely identifies that kind of product: the IMEI on a phone, the serial on a laptop or a watch, a part number on a component. It is defined per category, so you are not forced to call everything an IMEI, and it is unique across the units you currently hold.

What happens if a picker scans the wrong device?

The ship form refuses it and says what the order expects. The point is that the check happens at the last possible moment, against the unit physically in someone’s hand, rather than against a pick list that was correct an hour ago.

If I change my QC checklist, do old records change with it?

No. Each inspection stores the questions as they were asked along with the answers given, so a record written in March still reads correctly after you edit the template in September. A question you later delete stays on the units that were graded with it.

Can I find a device by a partial IMEI?

Yes, including by the last digits, which is usually all a customer has read out over the phone. The lookup also accepts the internal barcode and the marketplace order number.

Do you store the buyer’s details with all this?

No. The unit record is about the device: where it came from, what it cost, how it was graded, where it went. Buyer details are fetched from the marketplace at the moment they are needed, used, and not kept. There is no buyer database here to leak.

Keep reading