Run your stores as a channel of the same company. Each store is a POS location with its own warehouse and customer account; register sales are picked and invoiced automatically, web orders can be picked up or shipped from the store, and returns and exchanges at the register post as return authorizations and credits.
A B2C retail store in AIMS360 is a Shopify point of sale location tied to its own warehouse and its own customer account. Every register sale becomes an order, a pick ticket and an invoice without anyone touching it, returns and exchanges at the register come back as return authorizations and credit memos, and the store can pick up or ship web orders. The styles, costs, inventory and reports are the ones the wholesale and web teams already use, so opening a store adds a channel, not a second system.
A B2C retail store in AIMS360 is a physical store run as a sales channel of the same company: a Shopify point of sale location, tied to one AIMS360 warehouse that holds the store's inventory and one customer account that carries the store's sales. Register sales import as paid orders and are picked and invoiced automatically, which is what moves the units and posts the sale. Returns and exchanges taken at the register, for store purchases or web purchases, create the return authorization, receive the unit and issue the credit memo. A store that is allowed to fulfill web orders can be a local pickup point or ship a web order itself. Costs, margins, inventory valuation and reports for the store come from the same records as wholesale and web.
The retail store inventory page covers the stock side: transfers between the distribution center and the stores, replenishment against what sold and counting a store. The Shopify POS page covers the connection itself. This page is about the orders: what happens when a customer buys, returns or exchanges at a store, and how that reaches the books.
| At the register | In AIMS360 |
|---|---|
| A walk in sale | The register sells against the store's own location. The order is paid and, with the register set to leave sales unfulfilled, it imports into AIMS360 on the store's customer account, gets a pick ticket for the exact units and an invoice, which is what takes the units out of the store's warehouse and puts the sale on the books. The automation does all three steps because there is nothing to ship. |
| A sale shipped from the store | The register can take payment and a shipping address. The automation creates the order and the pick ticket, then stops, because there is a parcel to pack. The order appears in the customer orders view like any other and ships through your normal shipping path, with the carrier label from the shipping integration. |
| A web order picked up in store | A store location that is allowed to fulfill web orders can offer local pickup at checkout. The order arrives with no ship to address and the pickup ship via, so a saved view finds it. It still needs a pick ticket and an invoice; the shopper is told it is ready from Shopify, and marked picked up there rather than shipped. |
| A web order shipped from the store | When a Shopify location that is a store is allowed to fulfill web orders and holds the units, Shopify routes the web order to it and the order imports with that store's warehouse on the line. The store packs it and ships it, and the fulfillment goes back to Shopify with tracking. |
| A return at the register | A return processed on the register, for a store sale or for a web order the customer carried in, downloads into AIMS360, creates the return authorization, receives the unit back into the store's warehouse and issues the credit memo, without anyone keying it. A refund paid out at the register is cleared with an offsetting receivables adjustment. |
| An exchange at the register | An exchange does the return above and then adds the replacement unit to the original order. Because the customer walked out with it, the replacement is picked and invoiced on the spot, so the order ends with two invoices, the credit and the difference the customer paid or was owed, all visible on the account's receivables tab. |
Every one of these ends in the same records: an order on the store's account, a pick ticket, an invoice or a credit memo, and a warehouse balance for the store, which is why a store sale shows up in the same sales reports as a wholesale one.
AIMS360 pushes open to sell for the store's warehouse to the store's Shopify location, so the register sees the units that are on the floor and in the back room, not the distribution center.
The register app is set not to mark sales fulfilled. AIMS360 imports orders that are paid and unfulfilled, so that setting is what makes a store sale visible to the integration.
The POS orders template downloads the sale into the staging table and creates the AIMS360 order on the store's customer account, with the register order number in the customer PO field.
A pick ticket for the exact units and an invoice follow at once, because the customer already left with the goods. The invoice takes the units out of the store's warehouse and posts the sale with its cost.
The order is marked fulfilled back in Shopify from the shipping confirmations module, declining the customer email, since the customer has the goods. Orders with a shipping address stop after the pick ticket instead and ship normally.
Brands not on the automation run the same steps in a batch: batch allocate pick tickets filtered to the store's account, then batch invoice the tickets. Either way the store's day is on the books before the register closes.
| Setting | What it does |
|---|---|
| One location, one warehouse | Every store is a Shopify location and its own AIMS360 warehouse, never shared with another location, or the same units show in two places. Multi-warehouse is the prerequisite. |
| One customer account per store | POS orders import against a customer account you choose for the location. One account per store keeps sales, margin and returns reportable per store and lets views, batch picking and batch invoicing filter to one store. |
| Push, not move | Push keeps the store's inventory in AIMS360 and sends open to sell to the location; sales come back as orders. Move adjusts the units out of AIMS360 to the register and imports nothing, which is fine for a pop up but rules out pickup, ship from store and any store report in AIMS360. |
| Import orders on | With push, importing orders is what records the sale. Without it every register sale would need a stock adjustment by hand. Payment pending orders are best left out; import paid orders only. |
| Register leaves sales unfulfilled | AIMS360 imports orders that are paid and unfulfilled, so the register app is set not to mark sales fulfilled. App updates have been known to reset that setting, so it is worth checking after each one. |
| Products with global scope | A style sold both online and at the register is exported with global scope so it appears in both places. Products already in the register are mapped once to AIMS360 styles. |
| Completion date offset | If the store promises fulfillment within a number of days, that number extends the completion date on imported orders; otherwise a web order is due the day it is placed. |
| Returns automation per location | Download return, create RMA, receive stock and create credit memo, switched on in that order per POS location, with a default return reason code. Restock stays on at the register for returns and off for exchanges, because AIMS360 sends the inventory back itself. |
How a store order ships, and how it sits beside wholesale, dropship and web orders, is on multi-channel distribution. The web side of the same connection is on B2C direct to consumer.
With an account per store, the sales journal, who bought what and margin by order run per store, and a season or style can be read across stores, web and wholesale in one view.
The invoice carries the style cost, so gross margin by store, style and season uses the same costing as wholesale, and inventory valuation includes store stock.
Register returns post as return authorizations with a reason code and credit memos against the store's account, so return rates by store and by style come from the same returns reports.
The store account's receivables tab shows each sale, its payment, any credit memo and the offset for a cash refund, so a store's month reconciles line by line.
The Shopify order number sits in the customer PO field of the AIMS360 order, so a receipt in a customer's hand finds the order, the invoice and the credit in seconds.
Every import, return and exchange is a logged workflow; the failed by step views show what did not post and why, and the fix is a re-run.
Register app updates have reset the mark as fulfilled option before. A sale marked fulfilled at the register never imports, so the setting is worth checking after every app update, before the first sale of the day.
A pickup order gets a pick ticket like any other, and the automation cannot keep it out of a warehouse export. The pickup ship via and the empty ship to address are how staff spot it, and the ready for pickup notice is sent from Shopify.
Shopify does not split a single line across locations. A web order for three units when the store holds two goes to the primary location, goes negative there and fails to pick until units are transferred. Sending zero when open to sell is negative keeps that rare.
With the move option the units leave AIMS360 and nothing comes back: no orders, no returns, no store reports. Every feature above depends on push.
Running your own stores as a sales channel inside the same system that runs wholesale and web. Each store is a Shopify point of sale location tied to its own AIMS360 warehouse and its own customer account. Register sales import as orders and are picked and invoiced automatically, returns and exchanges at the register flow back as return authorizations and credit memos, and the store can pick up or ship web orders. The same styles, colors, sizes, costs and reports serve the store, the web store and the wholesale accounts.
The register is set to leave sales unfulfilled, the location is set to push inventory and import orders, and the POS automation downloads each paid order, creates the AIMS360 order on the store's customer account, creates a pick ticket for the exact units and creates the invoice. The invoice is what reduces the store's inventory and records the sale. Brands not on the automation run the same steps by hand or in a batch at the end of the day, filtered to the store's account.
Because AIMS360 is a wholesale ledger before it is a register: inventory only moves and a sale only posts through a pick ticket and an invoice. For a walk in sale those steps are done by the automation in seconds; they exist so the store's units, cost of goods and receivables sit in the same records as everything else the brand ships.
Yes. Each store is its own Shopify location and its own AIMS360 warehouse, with its own customer account for reporting. Two locations must not share a warehouse, or the inventory shows twice. The store inventory page covers transfers between the distribution center and the stores and replenishment against what each store sold.
Yes. A store location that is allowed to fulfill web orders can offer local pickup at checkout, with the units it holds deciding whether it appears. The order lands in AIMS360 with no ship to address and a pickup ship via, so a view can list pickup orders for the store. It still needs a pick ticket and invoice, the ready for pickup notice comes from Shopify, and a store used for pickup must be on push inventory.
Yes, when the store's location is allowed to fulfill web orders and holds the units. Shopify routes the order there, it imports with the store's warehouse on the line, the store packs and labels it and the fulfillment goes back to Shopify with tracking. A single line that needs more units than one location holds is not split by Shopify; it goes to the primary location and needs a transfer.
Yes. The register takes payment and a shipping address, the automation creates the order and pick ticket and stops there, and the parcel ships through your normal path with a carrier label. The order shows in the customer orders view until it ships, unlike a walk in sale, which is invoiced immediately.
A return taken on the register, whether the item was bought in that store or online, downloads into AIMS360 and creates the return authorization, receives the unit into the store's warehouse and issues the credit memo. An exchange does the same and adds the replacement to the original order, which is picked and invoiced on the spot. Returned units are received as good stock; damaged returns are moved out with a stock adjustment afterward. A cash refund at the register is offset with a receivables debit adjustment.
Yes. The register can process a return or exchange against an online order, and AIMS360 creates the return authorization and credit the same way it does for a store sale. Web returns handled outside a store go through a returns app integration or are entered as return authorizations by hand.
Give each store its own customer account and the store becomes a customer in every report: the sales journal, who bought what, margin by order, the aged receivables tab and the style analysis views. The register order number is held in the customer PO field on the AIMS360 order, so a store sale can be traced both ways. Reports by store location inside Shopify stay in Shopify.
Push keeps the store's stock inside AIMS360 as its own warehouse and sends open to sell to the register; sales come back as orders. Move adjusts the units out of AIMS360 to the register and nothing comes back; Shopify holds the store's inventory and sales reporting. Move suits a short pop up; push is what every other feature on this page depends on.
The register runs on the Shopify POS app; AIMS360 runs the inventory, orders, returns and accounting behind it. The store's units carry the same UPC per style, color and size the warehouse uses, so a handheld can count the store or receive a transfer; the retail store inventory page covers counting and transfers.
Every import is a workflow with a status. An order that fails, usually because it is still payment pending, has an unmapped style or was marked fulfilled at the register, shows in the workflow views with the reason, and can be re-run once fixed. The templates can retry failed steps on a schedule, which handles orders whose payment status catches up a few minutes later.
The store's register sees the inventory pushed to its own location. Whether web orders can be filled from a store, or a store can be a pickup point, is a setting per location. Wholesale allocation, picking and the distribution center's stock live in AIMS360, where store managers with access can see them, but the register itself only sells what its location holds.
Yes. The invoice created for a register sale carries the style cost from the style master, the same as a wholesale invoice, so gross margin by store, by style and by season is available in the same reports the wholesale team uses, and inventory valuation covers store stock.
Register orders arrive paid. The invoice is created against the store's customer account and the payment recorded against it, so the account's receivables tab shows the sale, the payment, and for returns the credit memo and any refund offset. Bank and processor reconciliation for card payments happens in the accounting system.
AIMS360 also connects to Square. The Shopify POS connection is the one that carries the full set on this page: pickup, ship from store, returns and exchanges at the register and the per location inventory sync.
It does not split a web order line across locations, it cannot separate pickup orders from shipping orders inside the automation, it needs the register app kept on unfulfilled after updates, a return that never reaches the workflow has to be keyed as a return authorization, and with move inventory nothing comes back to AIMS360 at all. Store to store transfers, replenishment and counting are on the store inventory page rather than here.
Bring the store's location and a day of register sales. We will run a sale, a pickup, a return and an exchange through in a demo and show you the books afterward.
