Third-party logistics module
Everyone’s goods stay everyone’s own
Once a warehouse holds goods for several clients, the question is no longer «how many units are there»: it is «how many are his». The owner is a column on every movement, every stock line and every document — and it is not added on the day you need it, it is there from the first.
It sits on every transactional record from the start, even for a business working only for itself. Switching on third-party logistics moves no data and stops nothing.
Units received, units shipped, lines picked and stock at period end: four figures taken from the movement ledger, not from a separate counter.
They come in with their own key and see their goods and their orders, whenever they want. Whose goods those are is decided by the server from the credential, never by the incoming request.
Two clicks on the button do not make two invoices: the refusal comes from the database, not from a check the second click would simply outrun.
A third-party operator does not have a warehouse problem: they have a boundary problem. Two clients’ goods sit on the same rack and must not blend into each other’s figures; each client wants to see their own stock without seeing the neighbour’s; and at month end the work actually done has to be billed with a number that can be produced again identically if anyone questions it. This module switches on the product’s second dimension and carries it all the way to the invoice.
The owner is a dimension, not a filter bolted on later
In systems that add third-party logistics afterwards, the owner is a field on some tables and a filter on some screens: one query that forgets it is enough for two clients to see each other. Here the owner is a mandatory column on every movement and part of the key by which a stock balance exists at all — warehouse, location, item, lot, serial, owner, state. Two clients can have goods on the same rack and remain two separate balances, with no dedicated aisles and no duplicated item codes. And it is orthogonal to the warehouse: one client can sit in several sites, one site can serve several clients, and the two never get in each other’s way.
- The owner is on every transactional record from day one, even when there is only one
- It is part of the natural key of a stock balance: not a label hung on a total
- Same location, different owners, separate balances: no aisle to dedicate
- Orthogonal to the warehouse: several sites per client, several clients per site
- A business that starts working for itself switches the module on and carries on: no migration, no downtime
- 40CLIENT ROSSISKU-4471 · lot L-2609
- 25CLIENT BIANCHISKU-4471 · lot L-2711
- 12OWN GOODSSKU-4471 · no lot
- Rossi’s userForty units. The other two lines do not answer “not allowed”: for them, they do not exist.
- Bianchi’s userTwenty-five units, same item, a different lot. The total they read is theirs too.
- You, who keep the warehouseSeventy-seven units in that cell, and you know whose each one is.
Each client sees their own, totals included
A permission says what a person may read, not whose. Those are two different questions, and the second has a single answer, applied at the entrance to every function rather than inside an individual screen — because that is how orders, returns, shipments and documents get covered together, instead of being remembered on one and forgotten on the next. A record belonging to another client does not answer «you are not allowed»: it answers that it does not exist, because knowing that it exists is already information. And the filter does not only apply to the rows on display: it applies to totals and page counts too, otherwise everyone’s allocated stock subtracted from one client’s on-hand would report less available than there really is.
- The scope is resolved from the credential, never from a request parameter
- Stock, orders, shipments, returns and delivery notes are all filtered by owner
- Somebody else’s document answers «not found», not «not allowed»
- The filter also enters the sums and the pagination counts, not just the list
- A client sees the names of their own end customers, and no other names
- ANSWERTheir units, in their cells40 · A-12-3
- TOTALThe page total is filtered exactly like the rowsno one else’s sums
- B’S DOCUMENTAsked for by number, it answers “not found”not “not allowed”
Knowing that a document exists is already information: that is why the answer is the one given for a number that was never issued.
The client portal: two routes, the same answer
You give the client a key and an address, and they look at their goods whenever they want: three reads — who I am, my stock, my orders — served through a key tied to their name. If you prefer, you can instead invite them as a user with a dedicated read-only role, which forces you to pick the client at invitation time. Both routes answer through the same code, so they see exactly the same thing: two copies of the same reads drift apart at the first change, and they drift apart precisely on the case nobody tests. The portal is read-only, and that is a decision: the client looks, they do not move stock.
- A key tied to the client, revocable, with its last use recorded
- Or a user invited with a read-only role, bound to their client
- Both routes share the same reads: no «almost identical» second version
- Search and pagination across their items and their orders
- Read-only by design: they look, and orders come in through the normal routes
| What differs | With an API key | With an invited user |
|---|---|---|
| How they get in | A key tied to their own name, revocable | An invitation with a read-only role, tied to the client |
| What they see | Who they are, their stock, their orders | The same three reads, served by the same code |
| Who it suits | Their own system, pulling the figures by itself | A person who opens a page and looks |
| When it is revoked | The key stops answering, and its last use stays on record | The user no longer gets in |
What it cost to serve them, measured rather than estimated
The month-end bill is not compiled from memory: it is read from the movement ledger, which is already the source of truth for everything else. Four items — units received, units shipped, lines picked and stock at period end — filtered by client and by date range. Stock in particular is rebuilt as at the closing date of the period, not as at today: a June invoice issued on 10 July charges June’s storage, and reproduced a month later it gives the same figure. That is the difference between a line you can demonstrate and one that, when the client challenges it, nobody can explain any more.
- Units in and units out, taken from that client’s real movements
- Lines picked: the figure that measures the work, not the units
- Storage as at the end of the period, rebuilt from the ledger at that date
- Same period, same figure: an invoice reproduced months later does not change
- All four items cut on the same clock, so the invoice lines actually add up together
- RECEIVEDUnits in, taken from the real movements1,240
- SHIPPEDUnits out980
- LINES PICKEDThe number that measures the work, not the units312
- STORAGEStock on 30 June, rebuilt as at that date2,106
The same invoice re-run in September gives the same four numbers: storage is rebuilt as at the close of the period, not as at today.
Contract rates, with a house price list behind them
Every item has a rate. There is a house list, which applies to anyone without their own terms, and above it sit per-client exceptions: what you agreed with them, on the items you agreed on. You never have to rewrite a whole price list to change one line, and you can see at a glance which rates are contracted and which follow the house list. The VAT treatment belongs to the warehouse: standard with its rate, or exempt or out of scope — because operators serving foreign clients or working under special regimes should not be bending the document by hand.
- A house list for the four items, with the unit of measure written next to each
- Per-client exceptions, item by item: you override only what is different
- You can read which rates are contracted and which come from the house list
- Standard, exempt or out-of-scope VAT treatment, with the warehouse’s own rate
| Item | Unit | Where the rate comes from |
|---|---|---|
| Goods received | per unit | The warehouse price list |
| Goods shipped | per unit | The warehouse price list |
| Lines picked | per line picked | Negotiated with this client |
| Storage | per unit at period end | The warehouse price list |
The client invoice does not end up on a separate sheet
When the period closes, the four items become an invoice with its lines, its net amount and its tax. And with the Accounting module on, that invoice posts itself to the journal on accounts of its own: amounts due from clients sit apart from amounts due from customers, and revenue for logistics services sits apart from revenue on goods — otherwise the customer ledger stops reconciling and the profit and loss mixes two different trades. A period can only be billed once: what prevents the second document is a database constraint, not a check between the click and the save that a second click would comfortably outrun.
- A service invoice with the four items, quantity, rate and amount
- Amounts due from clients on a dedicated account: the customer ledger stays exact
- Revenue for logistics services kept apart from revenue on goods
- One period, one invoice: the second attempt tells you which document already exists
- A wrong invoice can be cancelled and the period billed again
- Client payments are recorded like any other and close the open item
- LINESThe four items, with quantity, rate and amountfrom the period
- RECEIVABLEFrom clients whose goods you hold, on an account of its own1215
- REVENUEFor logistics services, kept apart from goods revenue4035
- SECOND CLICKOne period, one invoice: it is the database that says noand says which
If receivables from those clients landed on the customer account, the customer ledger would stop reconciling and the profit and loss would mix two different trades.
Working for several clients, out on the floor
Segregation is not only about the client’s screens: it is about the work. A stock count opens per client: the lines to count are theirs and nobody else’s, and the variance that comes out is born with the client already on it, so the adjustment lands on their balance and not on the neighbour’s. Receipts and despatches carry the client from the line up, so goods belonging to two principals in the same bay do not get confused. And how many clients you can hold is not a product tier: it is a number on your own contract line, raised without changing software and without moving data.
- Counts per client: one client’s session never touches another’s balance
- Receiving, picking and despatch carry the client from the line up
- The valuation of third-party goods stays separate from that of your own goods
- The number of clients is a limit on your line, not another edition of the product
Frequently asked questions
Do I have to dedicate a warehouse, or at least a zone, to each client?
No, and that is the point. The owner is a dimension of its own, independent of the location: two balances can live on the same rack and stay separate in every figure and every screen. Dedicating a zone stays your call if it suits your pick path, not something the software forces on you.
Can a client see other clients’ goods?
No. Whose goods they are is decided by the server from the credential used to log in, never by a request parameter, and the filter also enters totals and page counts. If they ask for a document that is not theirs, the answer is that it does not exist: telling them «it exists but is not yours» would already be telling them something about somebody else’s business.
How is storage billed?
On the stock held at the end of the billed period, rebuilt from the movement ledger as at that date. It is the only way the invoice can be reproduced: reading today’s stock instead, the same period would give a different figure every time it is reopened, and a line that changes by itself cannot be defended to a client who challenges it.
Can the client enter orders through the portal?
The portal is read-only, and that is a decision: the client looks, they do not move stock. They see who they are, their stock and their orders, with search and pages. Orders come in through the normal routes — your office, their own online store through the connector, or an integration — and appear on the portal with their status, so they know where things stand without ringing you.
I start with my own warehouse and a client arrives next year. Do I have to migrate?
No. The owner column is already on everything, with your own goods held under the house owner: switching the module on rewrites nothing, stops nothing and asks for no transfer. It is the same choice made for warehouses — a second site is a number to raise, not a change of platform.
Do I need the Accounting module to invoice my clients?
Not to issue the service invoice: the four items, the rates and the document all live in this module. Accounting is what you need if you want that invoice to post itself into double entry — onto the account for amounts due from clients and onto revenue for logistics services — and the payment to close the open item. They are two separate decisions, taken at two different times.
Bring us a real client of yours
Tell us how you work for third parties today: how you keep the goods apart, what you bill for, and how long the month-end reckoning costs you. We will show you the same thing on your own figures.
Talk to us