Odoo in ONIXhub — how it works

16 October 2026

How the book trade side and the inventory side fit together: what each one owns, and the four working flows end to end — getting titles in, reading stock by branch, pricing a branch differently, and moving stock between branches. Each flow is a picture first, then the steps.

What each system owns

ONIXhub decides what a book is. Odoo decides what is in stock and what a shop does about it locally. Nothing is shared in both directions: ONIXhub publishes titles, and reads the shops' answers back.

Publishing a title again updates the same product rather than creating a second one, so it is safe to repeat as often as you like. Everything else on that product — its cost, its supplier, the reordering rules, anything the shop has added — is left exactly as the shop set it.

Workflow A — getting a title into the shops' system

Publishing sends a title to the inventory system as a product the shops can sell. It is an update rather than an insert, so it can be run as often as you like — the same product is refreshed, never duplicated.

1. Pick the titles. In the catalogue, select the rows you want, or open a saved catalogue.
2. Publish them to the inventory system. Exactly one inventory system receives a publish at a time, and the screen says which, so you cannot send to the live one while you happen to be looking at the demo one.
3. What each title carries: its title, its ISBN as the barcode, the list price, the category, and the book detail — author, publisher, imprint, format and publication date.
4. The ISBN is the link. It is how a later publish finds the product it created the first time. A title with no ISBN is left out rather than duplicated, and the report says so.
5. Read the report. Every title that did not land is listed with the reason the inventory system gave, as it happens rather than discovered later.
6. See it in Odoo. Inventory → Products → Products, search the ISBN. The Book section on the product's General Information tab holds the author, publisher, imprint, format and publication date.

The book detail needs a small Odoo add-on, because Odoo has no field of its own for an author or a publisher. Without it those five values go into the product's sales description instead and the report says so — nothing is dropped quietly.

One thing to know before a first publish into an Odoo that already holds its own book catalogue: nothing matches what is already there, so every title arrives as a fresh product and duplicates appear. Publishing is meant for an Odoo whose book products came from here in the first place. Matching up an existing catalogue is a separate exercise and has not been done.

Workflow B — reading stock across the branches

Every branch is a warehouse in Odoo. Each shop is one, and so is the depot, which shows as one more branch row with its own count. "Warehouse" is simply Odoo's word for a place that holds its own stock — a shop's back room qualifies — so this is not a claim that one depot serves one shop.

Shelves, back rooms and receiving bays sit inside a branch and roll up into it, so a shop can reorganise them freely without the stock view changing shape.

1. Find the title. The inventory screen searches by barcode, title or author, and sorts by barcode, title, price or when the title was added.
2. Click the row for that title's stock across the chain.
3. The total is Odoo's own figure, not a sum of the branches. There is no roll-up branch to double-count, so the two agree; if they ever did not, Odoo's figure is the one to trust.
4. Each branch row shows what is on hand there and how much of it is already reserved for a customer.
5. Stock that belongs to no branch is called out. If units sit in a location outside any warehouse, the view says how many, so the branch rows never quietly fail to add up.
6. Min and max come from the shop's own reordering rules. A chain may set one per branch, and the view shows the widest band across them. No rule set means no figure at all, which is not the same as zero.
7. Cross-check in Odoo. Inventory → Configuration → Warehouses is the branch list, Inventory → Reporting → Stock shows the same quantities, and Inventory → Operations → Replenishment holds the reordering rules.

What this costs, stated when the choice was made: two counters inside one shop, each with its own count, cannot be two branches. The old system never tracked below shop level either, and counters within a shop are exactly what Odoo's locations are for.

Workflow C — when a branch charges a different price

One list price per book is published from here, and no price list is ever written. A shop that sells a title for something else records that in Odoo, and it shows beside that shop's stock. The catalogue says what a book costs; the shop says what it does about that locally — the same line already drawn for reordering rules.

1. Name the price list after the branch. Sales → Products → Pricelists → New, named exactly as the branch is; capitals and stray spaces do not matter. BGC the branch is priced by BGC the price list, and "BGC Store" will not be found.
2. Add the rule. On that price list: applied to this product, price computed as Fixed Price, minimum quantity 1 or less, and dates that include today.
3. Read it back. The stock view grows a price column as soon as any branch has one, and marks the branches whose price differs from the book's list price.
4. Anything cleverer is flagged, not calculated. A percentage, a formula, a rule on a whole category or on everything is reported as a pricing rule this view does not compute, and the list price is shown instead.
5. Several rules on one list — Odoo's own order decides, most specific first, and the first fixed price on that book wins.

Why it stops there: Odoo is the authority on what a shop charges, and its own price calculation cannot be run from outside it. Re-creating that calculation here would make this screen a second opinion about prices — and a wrong one the first time Odoo's own changed. Saying plainly that a rule was not computed is the honest answer.

The branch and its price list are tied together by the name alone, because Odoo has no field joining the two. That makes the convention easy to break: a price list named anything else is simply not found, and the branch shows the list price with no warning that someone meant otherwise.

Workflow D — moving stock between branches

The depot supplies the shops, and Odoo handles that natively: each shop is set to resupply from the depot, so a replenishment is an ordinary transfer between two branches. The movement history is the one part of this picture the old system could never show — it kept no stock card to read.

1. Move the stock in Odoo. Inventory → Operations → Transfers, or let a reordering rule raise it under Operations → Replenishment. A transfer counts only once it has been validated.
2. One transfer becomes two lines of history. It leaves one branch and arrives at another, so the same movement is a withdrawal for the depot and a receipt for the shop.
3. A move inside one branch does not appear. Shelf to back room is neither a receipt nor a withdrawal, and it changes that branch's total by nothing.
4. A sale, a delivery or a stock count has one branch side only. The other side is a customer, a supplier or an adjustment, so the history shows the branch's side alone — which is how a sale reads as a withdrawal with nothing opposite it.
5. The running balance is worked out, not stored. Odoo keeps movements, not stock cards. The newest line's balance is that branch's stock today, and each earlier line is the one after it less that movement.
6. Per branch, not per title overall. A transfer's two sides walk back through two separate columns of figures, each anchored on its own branch's stock today.

The history shows the hundred most recent movements, newest first. Working backwards from today's stock is what makes that limit safe: every line shown carries a true balance, where adding up from the beginning would go wrong the moment the oldest movements fall outside the hundred.

What this never changes in Odoo

Each of these is a deliberate line, not a gap waiting to be filled.

That last row has a cost worth naming: there is no approval step on this path, and a publish reaches the product list immediately. If a shop ever wants one, the right place for it is an approval inside Odoo, where the shop's own people work.

What is recorded instead: every publish is logged on the ONIXhub side — who ran it, when, and how many titles — and every product created from here stays identifiable as ours inside Odoo, however the shop edits it afterwards.

When something looks wrong

Most of what goes wrong is one of these, and each has a plain cause.

Where to look

In Odoo: Inventory → Products for the titles, Inventory → Configuration → Warehouses for the branches, Sales → Products → Pricelists for branch prices, Inventory → Operations → Transfers for stock moving between branches, and Inventory → Operations → Replenishment for the reordering rules behind min and max.

Odoo's own documentation for each part of this: