# A batch's detail page

The control desk of a run: its minting progress, its encoding jobs, its products, and the buttons that mint, prepare the QR codes and retry failures.

Source: https://docs.sealtrust.io/en/console/fiche-lot/

---

This is where a run is followed and where the production steps are triggered. You open the page by clicking a row in the batch list, or in a model's recent batches.

![A batch detail page with its progress and its encoding jobs](/console/fiche-lot.en.webp)

## What the screen shows

The brand and the model are shown by their name, which the server resolves before returning the page.

Minting progress leaves withdrawn products out of the count. Superseded products are counted separately and flagged in a warning, outside the bar.

The product table shows 20 rows per page by default, with a QR thumbnail asked for at 100 pixels, the smallest size the service accepts.

## What you can do here

Mint the batch with "Mint the batch (grouped)", which goes out in grouped mode.

Prepare the codes with "Prepare the QR codes". That preparation mints nothing: an item with no transaction reference is counted and left as it is. When everything was already prepared, the screen says so instead of showing zero: "The {n} QR code(s) of this batch were already prepared. Download them below."

Download the QR archive, retry failures with "Retry {n} failed item(s)", open the encoding wizard or the encoder with "Encode tags", and cancel an encoding job.

Correct the provenance. The form only sends the fields actually filled in, so as not to erase a field left empty, and every change is recorded in the admin log.

## What gates access

The screen reads the batch's authentication method. A batch explicitly set to QR only sees neither the wizard nor "Encode tags". A batch whose method was never recorded is treated by default as carrying a chip.

Several controls also require a brand profile allowed to mint and encode, which rules out the `basic` and `dpp` profiles: the wizard and "Encode tags", which also require an encoding job; "Mint the batch (grouped)", which requires a ready item; "Prepare the QR codes", which requires an encoding job and a product already minted; "Correct the provenance", with no further condition.

The archive download appears as soon as an encoding job exists, with no profile condition. The retry button, for its part, counts both failure states, permanent and transient, because the retry handles both.

## What the screen refuses

Minting with no ready item: 400 "No items in ready_to_scan status to mint". Beyond 10000 ready items, it answers 400 and asks for the batch to be split. Before minting, the server checks brand by brand the active subscription, the product quota and the allowed authentication method.

The archive when no item has a verification address: 404 "No items with a verify_url in this batch". Beyond 50000 codes: 413. A download error is read and shown on screen instead of arriving as a file.

Retrying with no failed item: 400. An item already carrying a transaction reference is never put back.

Cancelling a job that is no longer in flight does nothing and says so. Otherwise it fails the items still ready, writing or awaiting multisig, with the reason `manual_cancel`, and leaves untouched those already written or minted.

Renaming the batch code: 409 as soon as the batch carries a Merkle root, computed or anchored. That code goes into the sealed metadata and can no longer change.