How ERPNext putaway rules decide where received stock goes
ERPNext putaway rules decide where received stock goes by matching an item and a warehouse to a target storage location and checking how much room that location has before it is suggested. Each rule is a *putaway rule* record that names the item, the warehouse, the target location, a capacity and a priority. Teams set them up for items that always belong in the same racks or bins, so receiving staff get the same suggestion every time they book a receipt, regardless of who is on shift. Before relying on this, confirm in your installed version which fields are mandatory, how capacity is measured (by stock UOM or by quantity) and whether rules work in warehouses where location tracking is not enabled.
When more than one rule could apply to the same item, priority decides which rule is considered first, so agree on a numbering convention before loading any rules. Capacity is the limit that stops a location from being suggested once it is full. Teams usually need putaway rules when the same items arrive often, when bin space is tight, or when several people receive goods across shifts or sites. Low-volume, one-off items can still be placed manually without much risk. Ask your implementation lead to confirm whether receipts and stock entries apply rules automatically or only as a suggestion, because that determines how staff correct a wrong location and whether the stock ledger records the change.
Putaway rule options and when each fits
This table compares the main ways to scope and limit putaway rules in ERPNext, from item-level rules to manual location entry. Read each row for the warehouse type it suits and the upkeep it adds, since maintenance effort usually matters more than the initial setup. The main takeaway is that narrow rules give tighter control but multiply the records someone must keep current.
| Option | How it works | When it fits | Ongoing maintenance |
|---|---|---|---|
| Rules scoped per item | One putaway rule for a specific item in a specific warehouse, pointing to a preferred storage location | Retailers and manufacturers with a small number of high-volume or hazardous items that need fixed bins | Every new item or bin change needs a rule update, so record counts grow with the catalog |
| Rules scoped per item group | One rule covers all items in a group, such as a category of similar goods | Distributors with families of products that share handling, temperature or shelf requirements | Fewer records, but new items must be assigned to the correct group or they fall outside the rule |
| Rules scoped per warehouse | A rule applies to all incoming stock in a warehouse, directing it to a default zone | Single-site operations where any item may go to one receiving area first | Lowest upkeep, though it gives little control over where individual products are stored |
| Capacity limit by quantity | The rule stops directing stock to a location once the stated quantity is reached, then moves to the next option | Racked or bin-based warehouses where space per location is fixed and overfilling causes problems | Capacity values need updating when racking changes or unit of measure conventions shift |
| Priority ordering | When several rules match, the one with the higher priority value applies first | Operations with overlapping rules, such as a general warehouse rule plus a stricter rule for one item | Priorities must be reviewed whenever a new rule is added, since overlaps are easy to miss |
| Manual location entry | The receiver chooses the location on the receipt or transfer, and no rule is applied | Small sites, mixed or irregular stock, or early go-live periods before rules are proven | No rule upkeep, but accuracy depends on receiving staff and it is hard to audit later |
| Hybrid rules with manual override | Rules set the default location, and staff change it when the rule does not fit the stock on hand | Manufacturers and distributors with mostly predictable flows and occasional exceptions | Needs a clear override practice and periodic review of the overrides that were used |
Setting up putaway rules in a test site first
This sequence proves that putaway rules send incoming stock to the locations you intend, respect capacity and priority, and behave the same way on receipts and transfers before anything reaches production. The output is a test site with a documented, tested configuration that the team can copy into the live system.
Confirm the ERPNext version and warehouse structure
Before any setting changes, record the ERPNext and Frappe versions running on the test site, and confirm that they match the version planned for production. Map the warehouse tree, including parent groups, the stock locations inside each warehouse, and which warehouses are used for receiving, transit and storage. Ask your implementation lead or the vendor to confirm that putaway rules and their capacity fields are available in the exact version you run, since behavior can differ between major releases. The step is complete when you have a signed-off warehouse map and a version record that the test results can be tied to.
Create the test warehouses and storage locations
In the test site, create the receiving warehouse and the storage warehouses that will hold putaway targets, using the same names and hierarchy as the plan. Add the storage locations (racks, bins or zones) under each warehouse so every target location exists before a rule references it. Use a small, clearly labeled set of locations so that results are easy to read during testing. The check is that each location appears in the warehouse tree with the correct parent, and that a test item can be received into the receiving warehouse without errors.
Define item-level and warehouse-level putaway rules
Create putaway rules for a limited set of test items, mapping each item or item group to a target warehouse and, where needed, a specific location. Set the capacity for each rule and assign priority so that the intended rule wins when more than one could apply. Keep one rule per scenario that matters to the business, such as a fast-moving item that belongs near dispatch and a bulky item with its own zone. The step is complete when the rule list shows each test item, its target, its capacity and its priority, and a reviewer has checked those values against the written warehouse plan.
Enable and review the stock settings
Turn on the stock settings that the putaway behavior depends on, and record each change with its date and the person who made it. Confirm which documents apply putaway suggestions in your version, such as purchase receipts and stock entries, and note any setting that affects how stock is valued or reposted. Check that the settings match the rest of the test configuration, since a mismatch here can look like a rule failure. The step is complete when a settings record exists for the test site and the team agrees that it matches the production plan.
Test a purchase receipt against the rules
Create a purchase receipt for one test item that matches a rule, and check the suggested location on the receipt before submitting. Submit it, then open the stock ledger entry and confirm that the quantity landed in the location the rule selected. Repeat with a quantity larger than the rule's capacity to see how the system handles the overflow in your version, and record what happens. The check is that the receipt suggestion and the stock ledger entry both show the expected location, with the results saved as test evidence.
Test a stock transfer and a capacity limit
Create a stock entry or transfer that moves stock into a location governed by a putaway rule, and verify that the destination follows the rule. Fill the target location to its capacity with test stock, then send one more unit and confirm how the system selects the next location or blocks the move. Compare the stock ledger entries for both movements to confirm that quantities and locations match the expected outcome. The step is complete when each test has a recorded expected result, an actual result and a note on any difference.
Document the results and decide what moves to production
Collect the test records, the rule list, the settings record and the stock ledger evidence into one document, and mark each scenario as passed, failed or needs a decision. Ask the vendor or implementation partner to confirm any behavior that the tests showed but the documentation did not describe. Agree on the rules and settings to replicate in production, and the data cleanup needed so that test stock and test rules are not carried over. The check is a reviewed sign-off that lists every rule and setting approved for production.
How capacity and priority interact on real receipts
Capacity, priority and partial quantities together decide where a receipt lands, so none of these behaviors should be assumed before go-live. Start by confirming what the receiving document does when a putaway rule's capacity is already full. Your team needs to know whether the remaining quantity falls back to another matching rule, moves to a default location, stays on the receipt for manual assignment, or blocks submission. Each outcome creates different work for warehouse staff and different stock ledger results, so record the exact behavior on your target ERPNext version and the document type it applies to, such as a Purchase Receipt or a Stock Entry.
When two rules match the same item, the outcome depends on how priority is applied and how ties are broken. Confirm whether a lower or higher priority number wins, and whether a rule scoped to a specific item beats one scoped to a warehouse or item group. Then check partial quantities. A receipt larger than the free space in the first location may be split across several locations, placed entirely in one location over capacity, or held back. Also confirm how the split is calculated in stock UOM when the purchase UOM differs, since rounding errors can leave a location slightly over or under its limit.
Build a short test script and run it on a copy of production data before any rule goes live. Cover at least these cases: a receipt into a full location, two rules matching one item with different priorities, a receipt that must split across three locations, a transfer that triggers putaway, and a return of goods to the same warehouse. Add serialized and batch items, because their bundles can change how quantities are allocated. Record the stock ledger and the resulting bin quantities for each case, then have warehouse supervisors sign off on the expected locations. Repeat the script after every upgrade, since the behavior is version dependent.
Access, data quality and operational risks
Putaway rules decide where stock lands, so a wrong rule or a stale capacity figure sends goods to the wrong place without any error message. The cards below cover who can change rules, how capacity data drifts, what location changes do to existing rules, and when to re-check the whole set.
Limit who can write rules
Putaway rules are master data, and anyone with rights to create or edit them can change where every receipt and transfer goes. Restrict creation and edits to a small stock controller group through ERPNext role permissions, and keep warehouse managers on read access. Before go-live, test that a user without that role cannot save a rule, and that the role assignment is reviewed when people change jobs.
Confirm capacity figures stay current
Capacity limits on a putaway rule are only useful if the stock counted against them matches what is physically on the shelf. Receipts, transfers, and stock adjustments that bypass the usual documents can leave the recorded quantity out of step with reality. Ask the implementer to define which documents update the figure, and schedule periodic cycle counts for high-value locations.
Handle renamed or deleted locations
A putaway rule points at a specific warehouse or location, so renaming or removing that location changes or breaks the rule. Teams often rename racks during a layout project and forget the rules that reference them. Establish a rule for location changes: update linked putaway rules in the same change, and check for orphaned or disabled rules before deleting any location.
Review rules after layout changes
A new aisle, a changed storage type, or a retired zone makes existing priorities and capacities obsolete without any system alert. Treat putaway rules as part of every warehouse layout change record, with a named owner who re-tests a sample of receipts after the change. Confirm this review step in the written scope so it is not left to memory.
Test priority conflicts before go-live
When several rules match the same item and warehouse, the priority setting decides which one applies, and overlapping rules are easy to create by accident. Export the full rule list, check each item category for more than one match, and run test receipts against known locations. Record the expected result for each test so later changes can be checked against it.
What buyers ask about putaway rule implementation
What drives the cost of putaway rule implementation in ERPNext?
The cost depends on how many items, warehouses and storage locations the rules cover, how complex the layout is, and how much testing is needed before go-live. Each additional item group and warehouse adds rules to define, check and maintain. A layout with zones, racks, bins and mixed-size locations takes longer to map than a single open floor. Testing adds cost because each receipt, transfer and exception path needs a scenario. Self-hosting ERPNext is free, according to the ERPNext pricing page, so most spend goes to labor: configuration, data preparation, testing and training. Ask any quote to itemize these components, separate one-time setup from recurring support, and state the assumptions it makes about locations and item data.
Can our own team configure putaway rules without a partner?
A team with ERP administration skills and warehouse knowledge can often configure basic putaway rules in ERPNext itself, because the rules are set up as ERPNext records rather than custom code. Confirm this against the version you run before you commit. Work gets harder when the layout is irregular, when rules must follow several overlapping criteria, or when you need scripting to support them. Server Scripts are disabled by default from version 15 and must be enabled through the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Check your hosting environment before you design any logic that depends on scripts.
What do warehouse and ERP staff need to provide for the work?
Warehouse staff provide the physical picture: location layout, dimensions and capacity for each location, storage rules by item group, handling constraints such as hazardous or temperature-sensitive goods, and how receiving and transfers happen on the floor today. ERP staff provide warehouse and location master data, the item master with units of measure, a test environment and the admin access needed to configure and verify rules. Both groups should sign off the test scenarios together. Bulk loading of location and item records needs planning as well, because the ERPNext Data Import documentation advises importing only a few thousand records at a time.
How long should a putaway rule pilot run before go-live?
The right length depends on receiving volume, the number of warehouses and how many receipt and transfer types the pilot covers, so ask for it to be set in the plan rather than assumed. A useful pilot runs long enough to exercise each receipt type, each internal transfer, a full-location case and at least one exception. Define the exit criteria before it starts: which items and warehouses are in scope, what counts as correct placement, who reviews the results and what happens to failures. A written pilot scope lets your team, or any partner, judge progress against an agreed standard instead of an impression.
Does capacity-based putaway behave the same in every ERPNext version?
Do not assume it does. Confirm the capacity and priority behavior for your exact version against the release notes and your own tests before the build. Frappe's supported versions page lists version 15 and version 16 as supported, and states that version 14 reached end of life on January 31, 2026. ERPNext publishes frequent minor releases for both supported majors, so the version you test on and the version you go live on should match, with a tested upgrade path if they differ. Plan a regression run for putaway behavior after each upgrade.
What usually goes wrong when putaway rules go live?
The most common failures are predictable. Overlapping rules with unclear priority send stock to the wrong location. Capacity figures go stale after racks are moved or resized, so receipts land in full bins. Receiving staff bypass the system when a location is hard to reach, and the stock ledger no longer matches the shelf. Generic or default locations absorb items that should have a rule. Each of these is caught by a location audit before go-live, a pilot with exception cases and a change process for layout updates. Ask who owns the location master data after launch, because that owner decides whether the rules stay accurate.
When is outside help with ERPNext putaway rules worth paying for?
Outside help is worth considering when the layout is complex, several warehouses or companies are involved, putaway must connect to barcode scanning or other systems, or your ERP team lacks capacity during the rollout. ERPNext implementation is available through certified partners, according to the ERPNext pricing page. DeployOpen plans and implements ERPNext inside the client's own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Any quote should follow from that written scope, so compare proposals on what each one covers, not on headline numbers.
Limits to confirm in your environment
Putaway rules look simple on a whiteboard, but their behavior depends on the transaction types, item tracking and company setup in your installed version. The four checks below are the questions to answer with the vendor documentation or a test site before you build location rules across live warehouses.
Coverage across receipt and transfer types
Confirm which document types in your installed version pull putaway suggestions: purchase receipts, stock entries, material transfers, work order returns or manufacturing outputs. Check whether a suggestion appears on the document itself or only on a separate putaway step. Map each inbound flow your warehouse runs and record which ones fall outside the rules, so staff know where manual location entry is still required.
Behavior with serial and batch items
Ask how putaway suggestions interact with serial and batch bundles, since version 15 keeps tracked quantities in those bundles. Confirm whether a rule can split one receipt across several locations, and whether each batch or serial keeps its own location after a transfer. Test an expired batch and a serialized item end to end before relying on rules for tracked stock.
Barcode scanning and putaway prompts
Confirm whether a scanned item or pallet barcode triggers the same putaway suggestion as a manual entry, and whether the scanned location is checked against the rule. Test a mismatch on purpose, such as scanning a location that is full or reserved for another item. Note who may override a suggestion and whether that override is logged.
Multi-company and warehouse hierarchy
Check how rules behave when warehouses belong to different companies or sit under a parent warehouse group. Confirm that a rule for one company never suggests a location owned by another, and that account and stock ledger entries follow the location actually used. Run the same receipt across two companies on a test site to see the result.
Performance with large location trees
Ask how the suggestion logic performs when a warehouse has thousands of bin locations and many active rules. Measure the time to suggest a location on a copy of your real location tree, and confirm whether capacity figures are recalculated on each receipt. Agree on a volume test with your DeployOpen team before go-live, since large imports and reporting also load the same database.
Rolling putaway rules out to live warehouses
Roll putaway rules out one warehouse at a time, starting with a pilot that has a defined exception path. Choose a warehouse where the item list, bin layout and receiving volume are well understood, and enable rules only for the items and warehouse in scope. Run the pilot through several full receiving cycles, including purchase receipts, stock entries and transfers, before adding another warehouse. Record every case where the rule suggested a location that was full, blocked or wrong for the goods, because those cases define the requirements for the next wave. Confirm with your own configuration how capacity limits and priority are evaluated when more than one rule matches an item, and document the answer for receiving staff.
Hold a short review with the receiving team after the pilot and again before each new warehouse goes live. The goal is to agree who decides when a suggested location is overridden, how the override is recorded, and who corrects the rule afterward. Put the capacity data on a fixed schedule with a named owner, since a putaway rule is only as accurate as the capacity figures it reads. Ask your implementation partner or internal team to define how often bin capacity is refreshed and what triggers an unscheduled update, such as a new racking installation or a change in pallet dimensions. Plan this maintenance as recurring work, not a one-time task at go-live.
Treat every ERPNext version upgrade as a trigger for regression tests on receipts and transfers. Before upgrading, run a fixed set of test receipts, putaway suggestions and inter-warehouse transfers on a copy of production data, and compare the resulting locations, quantities and stock ledger entries with a baseline you recorded. Check the ERPNext release notes for changes to stock behavior that affect these documents, and confirm with the vendor how your current version line is supported before scheduling the change. Keep the regression pack under version control so that it can be rerun for each minor release, and do not roll new rules into live warehouses in the same window as a version change.
How DeployOpen scopes and supports ERPNext stock work
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, and putaway rules follow the same method. We start from how your receipts and transfers move stock today, then agree a written scope before any configuration begins.
How we scope
- Map which items, warehouses and receipt types need putaway rules and which stay manual.
- Define capacity limits, priority order and the exceptions your floor staff actually handle.
- Confirm in writing how putaway applies to purchase receipts, stock entries and transfers.
How we build
- Configure putaway rules and warehouse structure in a non-production ERPNext site first.
- Test rules with sample receipts, including full locations, mixed items and partial quantities.
- Customize only where standard behavior falls short, and document each change for upgrades.
How we hand over
- Deliver a runbook covering rule setup, priority changes and how to review location capacity.
- Train warehouse and inventory administrators on creating and checking putaway rules.
- Record test cases and results so your team can repeat them after each ERPNext release.
How we support
- Review putaway behavior after each planned ERPNext minor release in your environment.
- Plan upgrades of ERPNext and its apps with the rules, reports and customizations retested.
- Ongoing support is available as a retainer, scoped separately from the fixed-scope build.
