Hold each retail store as its own warehouse on the same style, color and size record as the distribution center. Recorded transfers from DC to store, store to store and store back to DC, replenishment against what the floor actually sold, Shopify POS, ship from store, and counting one location without closing the rest.
A store is not a channel bolted onto your ERP. It is a location holding your goods, and the moment you treat it as one, the hard parts get simple: the floor can see warehouse on-hand, replenishment is a recorded transfer instead of a paper pack list, and slow sellers can come back rather than sit there marking down.
Every store is set up as its own warehouse. Store stock sits on the same style, color and size record as the distribution center and every other channel, with its own on-hand, its own transfers, and its own counts.
Where a point of sale is involved, the mapping runs one to one to one: one physical store, one AIMS360 warehouse, one Shopify location. Each location carries its own settings for how inventory behaves and whether its sales come back into the ERP.
Everything else on this page follows from that one decision. Stock moving to a store is a warehouse transfer. Store stock is countable, sellable and reportable the same way DC stock is. And what the floor sells comes back as an order, so the number never has to be reconciled by hand.
A store is a warehouse, so goods move in and out of it the same way they move anywhere else.
The replenishment leg. The store is a warehouse, so sending it goods is a recorded inventory transfer rather than a pack list and a hope. Both ends move at the same time and the store's on-hand is right the moment the box is received.
The size run leg. One store is sold out of mediums and another has six sitting in the back. A transfer moves them without either location being adjusted by two different people on two different days.
The one brands skip, and the one that pays. Pulling slow sellers back to the distribution center puts them back in front of every channel instead of leaving them to mark down in a room where nobody is asking for them.
Not a transfer, a shipment. A web order fulfilled from store stock, covered under ship from store below.
All of it is the same mechanism: a recorded inventory transfer between two warehouses, done on the desktop or from a handheld standing at the rack. Both ends move in one transaction, which is the whole difference between a transfer and two adjustments that disagree for a week. Where bin locations are in use, moves work at bin level too, so a back stock room and a sales floor can be separate places.
Replenishment only works if you know what the floor sold. With POS orders importing into AIMS360, you do, per location, on the same record as everything else.
The floor can see what the distribution center is holding and the office can see what each store has left. That single fact removes most of the phone calls, and it is usually the first thing a brand notices.
Move stock against what is selling rather than against what somebody thinks was sent last month. It is a recorded transfer, so nobody has to trust that both ends were keyed.
Slow sellers returned to the DC go back in front of ecommerce and wholesale at full price instead of sitting in a stock room until markdown. The transfer works in both directions for a reason.
Stores do not run out of styles, they run out of mediums. Because stock is held by style, color and size, replenishment can be a size run rather than a carton of whatever was nearest the door.
AIMS360 connects to Shopify POS, and the important decision per location is push or move. They are opposites, and only one of them gives you a single live stock record.
| Mode | What it does |
|---|---|
| Push Recommended | AIMS360 sends open to sell inventory to the Shopify location and POS orders import back, so both systems hold the same number and AIMS360 knows what the floor sold. This is the setting behind a single live stock record. Import orders has to be set to yes, or AIMS360 has no visibility into the day's sales and the store number drifts. |
| Move | AIMS360 adjusts the stock out of its own books entirely and hands it to the POS. From that moment tracking happens only in Shopify and nothing reports back until you move goods the other way. It suits a brand that ships a season to a store and does not want the ERP counting it, and it is the wrong choice if you want one number across channels. |
With push, import orders must be set to yes for the location. That is what tells AIMS360 what sold today. Without it you are pushing numbers into a store and never hearing back.
POS sales post against a nominated customer account rather than individual shoppers. Give each store its own account rather than sharing one, because that is what makes per-store reporting work later.
Each location has a used for POS setting that controls whether it shows up in the point of sale app at all, so a distribution center does not appear as somewhere to sell from.
Every location needs an open to sell template as well as a warehouse. It is what decides which stock counts as sellable for that location once orders and production are taken into account.
Each location decides whether its goods can fulfill online orders. Turn it off for a store whose stock is only for walk-ins. Leave it on when you would rather a web order pulled from a store shelf than went on backorder.
If the last two are hanging in a store and the website is showing sold out, one of those is wrong. Letting a store fulfill is how a brand stops turning away demand it can actually satisfy.
Picking and packing web orders takes floor staff away from customers, and a store that keeps getting picked clean stops being a shop. Which locations can fulfill is a decision, not a default.
Fulfillment priority across locations is set on the Shopify side, so the distribution center can be first and stores only step in when it cannot cover the order.
Imported orders carry the warehouse the goods were held in. Lines on different warehouses each need their own pick ticket, because they are in different buildings.
Physical inventory runs per warehouse, so a store can be counted while the distribution center and the other stores keep trading. Nobody has to give up a Sunday for a chain-wide freeze.
Cycle counting on a handheld against bin locations catches drift while it is small. For a store that is usually better than an annual count, because the discrepancy you find in March is still explainable.
With bin locations, the back room and the floor are separate places, so you know whether a unit is findable by a customer right now or sitting in a carton behind a door.
Scanning the UPC rather than writing on a sheet is where store count accuracy actually comes from. See mobile device scanning.
If a customer orders three of a size and your primary location holds two, Shopify accepts the order because five exist across all your locations. It assigns the whole line to the primary location and lets that location go negative. It does not pull the third unit from another store.
That order then fails at the pick ticket stage in AIMS360, and it cannot be split by hand after import. The fix is a warehouse transfer to move a unit in before picking. This is a Shopify behavior rather than an AIMS360 one, but it lands in your warehouse either way, so it is worth knowing before it happens on a Friday.
Negative inventory does not stop it taking orders. There is a setting that sends a zero to Shopify whenever open to sell goes negative, which is what closes that hole. It lives on the OTS template. Turn it on unless you have a specific reason not to.
Every Shopify location needs an AIMS360 warehouse and an OTS template assigned, whether that location is active or not. Adding a location in Shopify without configuring it in AIMS360 can stop the integration working. Open a store, tell us, and set it up on both sides on the same day.
A womenswear brand running boutiques alongside a warehouse had store staff with no view of warehouse on-hand and stock transfers moving on paper pack lists. After moving onto AIMS360, “store managers trigger or receive inter-location stock moves themselves, with no spreadsheets in the loop. Replenishment happens at the speed of the floor.” Scan accuracy rose to the 99% benchmark and dead stock fell by a fifth.
Read the Generation Love case studyA vertically integrated Los Angeles manufacturer with a factory store moved its point of sale onto a stack integrated with AIMS360. Retail revenue grew fourfold, inventory accuracy across warehouse and retail reached 99%, and physical count time dropped by more than 70%.
Read the Los Angeles Apparel case studyDifferent problems, same underlying move: stop treating the store as a separate system with its own number, and the reconciliation work disappears along with the overselling.
Each store is set up as its own warehouse. That means store stock sits on the same style, color and size record as the distribution center and every other channel, with its own on-hand, its own transfers in and out, and its own counts. Nothing about the store is a separate system with a separate number to reconcile.
Yes, and it matters more than it sounds. Each physical store location needs its own unique warehouse, and inventory should not be shared between store locations. Pointing two store locations at the same warehouse duplicates the same inventory across both, which means both can sell it.
As a recorded inventory transfer between warehouses, on the desktop or from a handheld standing where the goods are. Both ends of the move update together, so the DC comes down and the store goes up in one transaction rather than two adjustments entered by two people on two days.
Yes. Because every store is a warehouse, store to store is the same recorded transfer as anything else. This is the one that saves a sale: one store is out of mediums, another has them sitting in the back, and the units move without a spreadsheet in between.
Yes, and it is the leg most brands underuse. Pulling slow sellers back to the DC puts them back in front of ecommerce and wholesale instead of leaving them to mark down in a stock room. It is a transfer like any other, in the other direction.
Because POS orders import into AIMS360, the system knows what each store actually sold, and store on-hand is visible next to warehouse on-hand on the same record. You replenish by transferring against what the floor is selling rather than against what somebody remembers sending last month.
Yes, through Shopify POS. Each Shopify location maps to one AIMS360 warehouse, and each location carries its own settings for how inventory behaves, whether it appears in the POS app, whether orders import, and which customer account POS sales post against.
Push keeps both systems holding the same number: AIMS360 sends open to sell to the Shopify location and POS orders import back, so the ERP knows what sold. Move adjusts the stock out of AIMS360 completely and hands tracking to the POS until you move goods back. Push is the one to choose if you want a single live stock record.
Yes. With push you must set import orders to yes for that location. Without it, AIMS360 pushes a number to the store and never learns what the store sold, so the ERP figure drifts away from reality across the day.
One you nominate per location. Shopify does not create individual customer accounts in AIMS360, so all sales for a location post against a single account. Use a separate account for each store rather than one shared account, because that is what makes per-store reporting possible later.
Yes. Each location carries a setting for whether its goods can fulfill online sales. Turn it off for a true store where stock is only for walk-ins, or leave it on when you want web orders to pull from a store shelf if the item is not available online. Fulfillment priority across locations is set on the Shopify side.
This is the limit worth knowing. Shopify will not split a single item across locations. If a customer orders three of a size and the primary location holds two, Shopify accepts the order because five exist across all locations, assigns the whole line to the primary location and lets that location go negative. The order then fails at the pick ticket stage in AIMS360, and it cannot be split manually after import. The fix is a warehouse transfer to move a unit in before picking.
Because Shopify only blocks orders when inventory is exactly zero, not when it is negative. There is a setting that sends a zero to Shopify whenever open to sell goes negative, which is what stops that happening. It now lives on the OTS template rather than the location screen.
Configure it in AIMS360 before you use it. Every Shopify location needs an AIMS360 warehouse and an OTS template assigned, whether the location is active or not. Adding one in Shopify without doing that can stop the integration working, which is a bad way to find out.
Yes. When goods on a single Shopify order came from different locations, the imported order lines carry the warehouse they came from. Each line on a different warehouse needs its own pick ticket, because the goods are physically in different buildings.
Yes. Counts run per warehouse, so a store can be counted while the distribution center and every other store keeps working. On a handheld, cycle counting against bin locations catches drift while it is small rather than waiting for one annual count.
Only if the store is big enough for that to mean something. Bin locations let you separate a back stock room from the sales floor so you know whether a unit is findable by a customer or sitting in a box. A small boutique is usually fine at warehouse level.
It depends on how you set it up, and that is the point. Store stock lives in its own warehouse, so you decide whether it publishes to ecommerce, to wholesale availability and to the EDI 846 inventory advice, or stays reserved for the floor. What you cannot do accidentally is sell it twice.
Tell us how stock gets to the floor today, who decides what goes, and what happens to the units that do not sell. We will show you what it looks like when the store, the distribution center and the website are all reading the same number.
