Skip to main content
The Stock Movement Log is the audit trail for every quantity change in CloudHub. Every put-away, every sale, every refund, every stocktake adjustment, every manual edit is recorded as a row. For an active multichannel seller this can run into millions of records (the example workspace shows 6.5 million entries spanning 649,419 pages at 10 rows per page). The point is that nothing changes the stock count without leaving a trace. The Stock Movement Log is the answer to every “why does this SKU show this quantity” question, and it is the basis on which finance reconciles to the Products report and the year-end stock provision.

​
The page

Path: Home, Locate, Stock Movement Log. The default view shows the most recent movements for every SKU, paginated. The pagination supports 10, 25, 50, or 100 rows per page; with millions of rows, raising to 100 saves a lot of clicks. The grid has two columns surfaced at the top level: Click a SKU to drill into the per-SKU movement history with the full context: timestamp, change quantity, before-quantity, after-quantity, source (sale, refund, GRN, stocktake, manual), and the user or system actor. The top of the page shows:

​
Searching the log

For an operational question, the search is almost always SKU-led:
  1. Pick Search by = SKU from the dropdown.
  2. Type the SKU into Enter SKU.
  3. Click Go.
The page narrows to that SKU’s movement history. From here, the chronological story is visible: when was stock first added, when did each sale decrement it, when did each PO receipt increment it, when did stocktake adjustments happen. You can also search by Order ID to see all the SKU movements caused by one order. Useful when investigating a customer complaint or a refund discrepancy.

​
What gets logged

Every event that changes a stock count creates a Stock Movement Log entry: Each entry includes the user (if a person triggered it) or the system actor (if a process triggered it).

​
Use cases

  1. “This SKU shows 19 in stock but my picker swears there were 25 yesterday.” Search by SKU, sort by timestamp descending. The top rows tell the story. Common findings: a sale dispatched, a refund came in but to a different bin, a damage write-off was recorded, a stocktake adjusted by a known variance.
  2. “Customer says they got 3 units but the order was for 4.” Search by Order ID. The log shows the four units decrementing and one of them coming back in via a refund-stocked-back. Cross-reference with the Returns report.
  3. “Year-end stocktake shows variance of -240 units across the catalogue. Where did they go?” Filter the log to the year, group by source, and you get the breakdown: how many lost to damage, how many to manual edits, how many to stocktake adjustments. The damage and stocktake-adjustment numbers usually match the operational shrinkage; large manual-edit counts suggest user-permission tightening is needed.
  4. “Why did my Amazon listing go out of stock when CloudHub thinks I have 50 units?” Search by SKU, look for Sync Adjustment entries. The marketplace push may have hit a rate limit, retry-failed, and left the channel listing showing zero while CloudHub still has stock. The log catches the failure window.

​
How the log feeds other surfaces

The log is the single source of truth. Every other inventory-state surface is a projection of it.

​
Common questions

Can I export the log to CSV? Today the export is a per-search export. For a full log dump, contact support@247cloudhub.co.uk. The full log is large; most operational questions are better answered with a focused search. How long does CloudHub retain log entries? Indefinitely as the operational record. The full audit history is the basis for the year-end stock provision and the operational audit, so retention is not pruned by default. Can I edit a log entry? No. The log is append-only. Adjustments are recorded as new entries (a manual edit, a stocktake variance) so the audit trail stays intact. Why is the page slow when I do not filter? Six million rows is a lot to paginate. Always filter by SKU or Order ID before browsing. Without a filter the search is across the whole log and the response time reflects that.

​
Next steps