Understand how location records work in Sanka, including warehouses, zones, bins, inventory balances, stock movements, barcode work, CSV imports, and AI checkpoints.
Last updated: May 29, 2026
The Location object represents the physical or virtual places where inventory is stored, moved, counted, or operationally tracked. A location can be a warehouse, store, factory, stockroom, floor, zone, aisle, rack, shelf, bin, or another structure your team uses every day.This reference explains what a location should contain, how it connects to inventory and inventory transactions, and what to check before creating, importing, archiving, merging, or troubleshooting locations with AI, actions, workflows, CSV, integrations, or manual entry.
Claude/Codex
Review this location setup before changing it. Check warehouse, floor, zone, aisle, rack, shelf, bin, active inventory, recent stock movements, duplicate locations, barcode labels, and permissions. Do not update records yet.
Reviewing locationI reviewed the location setup. Confirm active inventory, recent movements, duplicate risk, barcode labels, and permissions before changing the location.
Ask for another location check...
What a location record represents
A location record should answer where stock is held or handled. It gives inventory and warehouse teams a shared language for receiving, storage, picking, transfer, shipping, adjustment, and physical counts.Common fields include:
Location ID or record ID
Location name
Warehouse or site
Floor, zone, aisle, rack, shelf, bin, or another storage level
Status, owner, or responsible team
Barcode, QR code, external ID, or other scan key when used
Notes for warehouse staff
Related inventory records, inventory transactions, purchase orders, orders, slips, items, and reports
Source details from UI, CSV, integrations, actions, workflows, barcode operations, or AI-assisted creation
Choose a location structure that your team can maintain every day. A structure that is too broad makes stock hard to find; a structure that is too detailed can create inconsistent scans, duplicate locations, and noisy stock movements.
How locations connect to inventory
Locations are master data. They describe where stock can live, but they are not the stock quantity itself.
Inventory records store the current stock position for an item at a location.
Inventory transactions record the movement that changed stock, such as inbound, outbound, adjustment, transfer, or cancellation.
Items identify what is stored at the location.
Orders, purchase orders, and slips can drive picking, receiving, shipping, or transfer work that affects location-based inventory.
Reports and dashboards use locations to group stock, movement, valuation, and discrepancy trends.
Barcode and QR flows use item and location keys so warehouse staff can confirm the right place before posting a movement.
Creating a location does not create inventory. Updating a location name does not move stock. Archiving a location does not automatically clear its inventory history. Stock changes should be posted through inventory records, inventory transactions, receiving, shipping, transfer, or another configured workflow.
Review before changing locations
Ask AI to review evidence before changing active locations, especially when stock already exists.
Sample prompt
/sanka Check this location before editing or archiving it. Compare location name, warehouse, floor, zone, aisle, rack, shelf, bin, active inventory, recent inventory transactions, open orders, open purchase orders, barcode labels, duplicate locations, and permissions. Ask for confirmation before changing anything.
For CSV imports or integration mapping, review duplicate keys first.
Sample prompt
/sanka Review this location import before running it. Map location name, warehouse, floor, zone, aisle, rack, shelf, bin, barcode or external ID, active status, and duplicate key. List rows that need manual review. Do not run the import yet.
Expected behavior
When a location is created or updated successfully:
It appears in the Location object list unless it is archived or hidden by the current view.
The warehouse, floor, zone, aisle, rack, shelf, bin, barcode, external ID, owner, notes, and custom fields are saved when configured.
Inventory and inventory transaction records can reference the location.
Barcode, CSV, and integration flows can use location keys when matching rules are configured.
Reports, dashboards, and views can group stock and movement by location.
Actions and workflows can use locations for receiving, transfer, allocation, picking, shipping, or counting when configured.
Location updates do not bypass permissions, required fields, duplicate checks, view filters, customer/item visibility, barcode matching, inventory validation, or workflow conditions. If stock appears wrong after a location change, review the inventory and inventory transaction records rather than editing location fields as a shortcut.
Troubleshooting
A location is missing from the list
Check the current view, archive state, filters, permissions, module availability, workspace, import result, and whether the location was created under a different warehouse or external ID.
The same warehouse or bin appears more than once
Check naming rules, CSV duplicate keys, external IDs, barcode labels, integrations, and whether one record uses a warehouse-level name while another uses a bin-level name. Confirm active inventory and movement history before archiving duplicates.
Inventory is shown in the wrong location
Review the inventory record, recent inventory transactions, receiving history, transfer history, order picking, barcode scans, and any manual adjustments. A location name change alone should not move stock.
Barcode or QR scans match the wrong location
Check whether location codes are unique, labels are printed correctly, the scan field matches the expected key, archived locations are excluded, and warehouse staff are scanning the item and location in the intended order.
A location cannot be archived
Check active inventory, open inventory transactions, open receiving, open shipments, related orders, purchase orders, slips, and workflow conditions. If the location is still operationally used, move or close related work before archiving.
AI cannot decide whether this is a bug
Ask AI to compare location setup, active inventory, movement history, barcode labels, CSV or integration mapping, duplicate keys, permissions, and audit history. Treat it as a possible bug only after confirming the location setup and source data are correct.
Checkpoints
Before editing, importing, archiving, merging, or using locations in barcode work, check warehouse structure, active inventory, recent movements, duplicate risk, barcode labels, open orders, open purchase orders, slips, permissions, and audit history.
Search Sanka...
Review location changes
Logs
Search logsAll actionsAll dates
ID / ActionDateTarget / ItemChangeActor
3Location reviewed2026/05/20 10:00Warehouse A / Rack B-02Checked active inventory, duplicate risk, and barcode labelWarehouse manager
2Movement history checked2026/05/20 11:00Inventory transactionsConfirmed recent inbound and outbound movements before editOperations admin
1Archive held for review2026/05/22 09:30Old Bin C-01Open inventory still exists, so archive was not completedClaude / Codex
Location review should separate warehouse master-data changes from stock movements, and should confirm active inventory before archiving or merging records.
