Skip to content
Knowledge ERP Docs

API Reference ↗
Inventory

Asset Checkout

Check a piece of equipment out to a person directly from the unit, track who has it and when it's due, and check it back in.

For quick, one-off handouts of reusable equipment, you can check a unit out directly from the unit page itself — no loan or rental agreement needed. For multi-unit, customer-facing handouts with request details and a return workflow, use an equipment loan instead.

Checkout is the record, not a third kind of paperwork. Every time a unit leaves the shelf a checkout is written — including when a loan or a rental does it, which is why the Checkouts list shows all three. Its Agreement column names the agreement each row came from, or reads Direct checkout where there is none. What you actually choose between is a direct checkout (this page), a free agreement (a loan) and a charged agreement (a rental).

The list also carries a Sales Order column, which names the order a checkout was recorded against. An account that lends or hires rather than shipping against orders has nothing in it, so for them the list starts with that column switched off. It is in the column menu (the toggle at the top right of the list) if you want it on, and it stays on for the rest of your session.

Checking a unit out #

From a Returnable unit's page, use Check Out and choose who it's going to — a staff user, a customer, or a contact, and when it's due back. The unit's status becomes checked out and a checkout record captures who has it, when it left, and when it's expected.

The due date is required. A handover that never says when the kit comes back can't be chased, can't be reconciled against a booking, and leaves the counter guessing.

It can be filled in for you. Set Default Loan / Checkout Period (days) on the location you are working at and the date arrives that many days ahead — here, on the units list, on the bulk check out, and on a new loan agreement. Leave the setting blank and the field stays empty for you to type, which is how it has always worked. Either way the date on the form is the date that is saved, so change it whenever the answer is different.

Only units whose Product usage type is Returnable (Equipment) can be checked out. Consumable stock is sold or drawn down instead.

When a unit can't go out #

A unit can only be checked out while it is In Stock. Every other status means it isn't yours to hand over, and the checkout is refused — from the unit page, the scan station, the mobile app and the API alike. The refusal always names the status and the one thing that clears it:

Status Why it's refused What to do
In Stock It goes out.
Checked Out Someone already has it. Check it in first.
On Hold It's reserved for a sales order, appointment or transfer. Release the hold on that record if it should go elsewhere.
In Transit It's moving between locations, not on a shelf. Receive the transfer at its destination.
Out of Stock It's been sold, used up or discarded. Nothing is left to check out.
Discontinued It's kept for history, not for circulation. Set it back to In Stock to circulate it again.
Missing Nobody has been able to find it. Locate it and check it back in.

Nothing is written when a checkout is refused — no movement, no checkout record, and the unit's status is left exactly as it was.

On a unit that can't go out, the Check Out button stays on screen but is greyed, and hovering it gives the reason from the table above. It is not hidden: "why can't I check this out?" is the question that needs answering, and a missing button answers nothing. It is not clickable either — the only thing opening it could ever produce is the refusal it is already showing. (This is different from a button you lack the permission for, which is padlocked, because a colleague can grant you that.)

Starting from the Checkouts list #

Inventory → Checkouts → Check Out a Unit asks which unit first. Each option names the Product, the bin the unit is sitting in, and its barcode — four identical tape measures are told apart by the shelf you just walked to, not by a code you'd have to scan to read.

When that list comes back empty, it says which condition emptied it rather than "no options available": no units on file at all, no Product marked Returnable, or Returnable stock that exists but is all in another status — named, with counts. None of those is a permission problem.

Checked Out To on this list, on the checkout record and on the unit's own checkout history names the borrower even when the unit went out on a loan or a rental. Those handovers record the borrower once, on the agreement, rather than copying them onto every unit — so the name you see is read from there. Correct it on the agreement and every checkout under it follows.

Opening a checkout record #

Inventory → Checkouts → a row opens the checkout, which names every record involved in the handover and links to each one it can: the Product, the Unit itself, whoever it went out to, the Agreement it came from, the Sales Order where there is one, and the Location it left from. Each link is a small arrow beside the field.

A link is only shown where there is somewhere to go. A direct checkout has no agreement, most checkouts have no sales order, and a borrower recorded as a customer contact has no page of their own — those fields read as text with no arrow. Links are also shown only for the kinds of record you have access to, so a colleague may see arrows you don't.

Scan checkout (handing out in bulk) #

For checking out many units at once, open Inventory → Movement Log → Scan Checkout. Set the due date for the batch — already filled in if the location has a default loan/checkout period — and optionally a recipient (staff user, customer, or contact). The recipient box is a search: type part of a name, an email address or a phone number and pick from what comes back. Then scan unit barcodes to build a list; each scan validates that the unit is in stock and returnable before adding it. Tap Confirm Checkout and every listed unit is checked out to that recipient in one go, then the list clears for the next batch. Confirming without a due date is refused and the scanned list is kept, so you can fill the date in and carry on. It's the keyboard-/scanner-friendly counterpart to the per-unit Check Out action.

A unit's status can change between the scan and the confirm — someone else takes it, or an order puts it on hold. Those units are named in the message rather than quietly dropped, and they stay in the list so you can deal with them; everything else still goes out.

Checking it back in #

When the equipment comes back, Check In the unit to a destination bin. Its status returns to in stock and the checkout is closed out, leaving a complete history of the trip.

The bin is already filled in with the bin the unit was checked out of, and the field says which one that is, so putting a tool back where it lives is confirming an answer rather than remembering a shelf number. If that bin has since been deleted, or sits at a site the unit no longer belongs to, the site's receiving bin is offered instead — and the wording says so, rather than claiming a history the unit doesn't have.

Anything you type into the check-in notes is kept on the check-in movement and shown on the checkout's page as Return Notes, beside the Checkout Notes it went out with. They are two different facts about two different days, so neither overwrites the other.

The check-in also records who was returning it — the movement points back at the checkout it closes — so the movement log can answer who had that tool? without opening the unit's history tab.

The due date #

Every checkout carries one, and it does two things.

It puts the checkout on the overdue list once the day passes, so what's late is visible without anyone remembering to look. The Checkouts menu item also carries a red count of how many units are out past their date.

If being late is normal where you work, turn that count off. A lending library that charges nothing and chases nobody has most of its stock nominally overdue at any moment, and a red number that is always there is one nobody reads. Account Settings → Inventory → Warn about overdue checkouts removes it. Nothing else changes: due dates are still recorded, the Checkouts list still shows them, and its filters still find what is late.

It can't already have passed. A checkout typed in against last month's date is overdue before the kit leaves the counter, and a list that late things can be born onto isn't worth reading — so the unit page, the units list, the scan station and the mobile app all refuse one and ask for today or a later day. Today itself is fine: a tool handed over at nine and wanted back by five is due today. Imported history is the exception, and deliberately — a data migration or an integration recording handovers that already happened keeps the dates it was given.

And it lets the unit go out even when something else has it booked later on. A checkout is refused when it would leave a loan or rental short over dates it has already been promised — but a checkout that's back before the booking starts doesn't clash, so it's allowed. The refusal names the agreement and its dates when it happens.

A checkout still reserves nothing of its own: it says when the unit is expected, not that the unit is held. When you need dates held against everything else, make an agreement.

Checkouts recorded before the due date became required keep their empty date and are left alone. They're still treated as open-ended, and still show in history as they always did.

Checkout vs. loan vs. rental #

Two questions, not three options:

  1. Does this need paperwork? No — check the unit out and hand it over. Yes — make an agreement, which reserves the equipment for a date range so nothing else can be promised it, records who signed, and drives the return workflow.
  2. Are you charging for it? No — a loan. Yes — a rental, with rates, deposits, optional cycle billing, and an invoice when you close it.

Both kinds of agreement check the units out when they go, so every handout ends up in the Checkouts list either way. Rentals are a separate subscription module; if you only lend equipment out free, loans in Inventory are all you need.

Where to start each one #

Where
Checkout A unit's page, or the units list, or Inventory → Movement Log → Scan Checkout
Loan Loans → Loan Agreements → New loan agreement (also on Loans → On Loan)
Rental Rentals → Rental Agreements → New rental agreement (also on Rentals → On Rent)