We give every rack and bin in your warehouse an address and record every movement by barcode. From goods receipt to put-away, from pick routing to dispatch checks, the flow runs on handheld terminals; underneath the quantity figure in your ERP we add the physical location of the goods and who moved them, and when.
Prepared by Pan Innovation House, a software company based in Gaziantep, Türkiye · Last reviewed:
The most repeated sentence in a warehouse is this: the goods are here, but we do not know where. The ERP screen shows enough of the item; when it needs to be brought down for dispatch it is hunted for in two different aisles, part of it has been allocated to another order, and part of it was lifted onto a top rack last month to make space. If the person who knows the warehouse is on leave, the search takes twice as long. Meanwhile the lorry waits at the gate, loading is delayed and the delivery date promised to the customer slips. When stock-count day arrives a discrepancy appears; nobody can explain where it came from, system stock is corrected by hand and the same cycle starts again. The problem is usually not carelessness on the part of the staff: the warehouse's knowledge is not in the records, it is in people's memories.
The gap here is not a shortcoming of the ERP but the boundary of its scope. An ERP stock module holds quantity and value: how much of an item there is, what it costs, which warehouse it belongs to. It does not hold which rack, which bin or which pallet the goods are sitting on, who took them and when, which order they were allocated to, or which batch they came from. A warehouse management system (WMS) begins exactly there. A WMS does not replace the ERP and does not touch the accounting side; it adds a layer of physical location, movement and accountability underneath the quantity figure. Setting out this distinction clearly at the start matters, because in most companies a WMS is mistaken for a second ERP and is therefore either seen as unnecessary or imagined as a project so large that it never starts.
Implementation starts with physical order. Aisles, racks, levels and bins are set out in an address plan; every address is labelled and made readable. From then on every movement is recorded by barcode: at goods receipt the item is scanned and the system says which address to put it away in; during picking the handheld terminal guides the operator from address to address in a sequence that avoids unnecessary walking; before dispatch the loaded carton is scanned and compared with the order. When the wrong item is scanned, the warning appears before loading takes place. Stock counting also stops being an annual event that halts the line; the system queues up which addresses are to be counted and when, and counting proceeds piece by piece without stopping production.
The limit of this work is as follows: a WMS does not make a disorderly warehouse orderly; it makes order measurable and sustainable. If there is no address plan, if labels have worn out and cannot be read, or if the operator picks goods up and walks off without scanning, the system will accumulate wrong data faster than before. That is why the first phase is field work, not software, and we do not recommend shortening the time set aside for it. A WMS also does not remove stock counting; it only makes it smaller and spreads it out. Handheld terminals, label printers and label consumables are a real cost item, and we put that in writing at the discovery stage rather than as a surprise at the end of the project. In return, once the warehouse is addressed and movements are on record, simply being able to find the goods you are looking for and to see dispatch errors produces a gain on its own, before any optimisation has been done at all.
Carpet, textile and packaging manufacturers with dozens of variants of the same product by colour, size, pattern and batch. In these warehouses the confusion is not about quantity but about variant; shipping the wrong variant produces returns and rework. Two similar-looking variants sitting in the same rack bin is the most common source of error. Addressing and scanning make mixing them up physically harder.
Businesses working in fields such as food, chemicals and food-contact packaging, which have to prove which batch went to which customer. In a complaint or a recall, the affected batch has to be located in minutes rather than hours. First-expired, first-out (FEFO) sequencing can also only be applied reliably in an addressed warehouse.
Factories that take the semi-finished goods produced at intermediate stages into the warehouse and feed them back to the line, sending some out to subcontractors and receiving them back. This stock is usually invisible in every system; nobody knows how much work-in-progress is waiting where. Address-level tracking closes this blind spot between production and the warehouse, and goods held at subcontractors stay visible too.
Companies transferring between several warehouses, branches or shops and shipping both wholesale and e-commerce orders from the same stock. In this set-up, if the moment an inter-warehouse transfer leaves and the moment it is received are not recorded, stock appears in two places at once, leading to double selling and cancellations.
An address plan is built at aisle, rack, level and bin granularity; every address is labelled and becomes barcode-readable. Volume, weight and product-type constraints can be defined per address. Rack-free zones such as block stacking, pallet areas and the outside yard can be addressed as well, so the warehouse layout is not tied to a racking system.
Incoming goods are scanned and compared with the delivery note or purchase order; quantity, batch, serial number and expiry date are recorded at receipt. The system suggests which address to put the item away in and the operator confirms by scanning the address. Short, over or unexpected deliveries are caught at goods receipt, so the error becomes visible before it enters the warehouse.
Orders turn into pick lists, and the handheld terminal guides the operator from address to address in a sequence that avoids unnecessary walking. Single-order, batch and zone picking modes can all be set up. If the scanned item does not match the order, the terminal warns. Picked quantities are deducted immediately, so the problem of allocating the same goods to two different orders disappears.
Before loading, cartons or pallets are scanned and compared with the order contents, so missing or wrong items are caught before the vehicle moves. Dispatch paperwork, packing lists and labels are produced from the system. Which order was loaded onto which vehicle, at what time and by whom is recorded, giving you evidence to look back on if a customer disputes a delivery.
Alongside the classic period-end count, cycle counting is set up to run without stopping production: the system queues which addresses are counted and when, based on movement frequency and value. Count discrepancies are reported by address and by user, so where a discrepancy came from stops being a matter of debate. Adjustments require authorisation and leave a trail.
Movements between warehouses, zones and the production line run on transfer records, and goods that have left but have not yet been received appear in a separate status. Material issues to production and receipts of semi-finished goods coming off the line are recorded in the same structure. Goods sent to and returned from subcontractors are tracked at address level too, so the stock held at the subcontractor stays visible.
Two-way integration is built with Logo, Mikro, Netsis (widely used Turkish ERP packages) or whichever other system you run, through the routes its version supports (API, service layer or an approved import): item and account master records come from there, and stock movements are posted both ways according to defined rules. The accounting side stays where it is. The difference between the two systems is compared automatically every day and deviations are reported, so a reconciliation gap is noticed on the day it arises rather than at month end.
Not every warehouse needs a custom WMS layer. The table below sets out four common routes side by side: when each is enough and where it struggles. We ask the same questions during discovery and say so plainly when your ERP's stock module or an off-the-shelf package will do.
The choice mostly depends on how many people handle the goods, how many items and variants you hold, whether your ERP stays, and how precisely you need to know where everything is.
| Route | Enough when | Where it struggles | Cost structure |
|---|---|---|---|
| Spreadsheets, labels and a barcode scanner | One warehouse, a narrow range and a few people handling the goods; entering a handful of movements by hand each day is enough. | The file usually sits with one person; when several people edit at once, entries can clash or be overwritten, and preventing wrong entries or tracking who changed what becomes hard. Location, batch and who took the goods are often not recorded consistently. A scanner only speeds up typing; on its own it does not stop the wrong item being picked. | Low upfront cost; the hidden cost is search time, count discrepancies and manual corrections. |
| Your ERP's stock or warehouse module (Logo, Mikro, Netsis, etc.) | The warehouse is small and the range is narrow; tracking quantity and value is enough, and goods sit in fixed places a few people know. | Bin-level addressing, goods receipt and picking on handheld terminals, pick routing and cycle counting vary by product and version; an add-on module, a partner solution or customisation may be needed. Ask your ERP vendor. | Where needed, an add-on module and customisation on top of your current licence; ask your vendor how handheld users are licensed. |
| Off-the-shelf WMS | Your warehouse flow is close to the one the package assumes (standard receipt, put-away, picking, dispatch); speed of rollout matters most. | When business-specific flows such as work-in-progress and subcontractor stock, line feeding or pattern-specific variant rules do not fit the package, customisation costs rise, and licence costs too if add-on modules are needed. How, and how deeply, the package connects to your ERP varies by product and version; ask the package vendor. | Licence or subscription, plus customisation and integration. |
| A custom WMS layer built for your operation | The ERP stays; your warehouse has business-specific rules (e.g. pattern-specific variant rules, work-in-progress and subcontractor stock, line feeding) that the package you evaluated does not cover, or you need a deep two-way link with the ERP; and you need live, accurate data from the floor. Batch, expiry dates or more than one site do not on their own justify this route; first ask the vendor how your ERP module or an off-the-shelf package handles them. | Discovery, the location plan and master data preparation take time, and the initial investment is usually higher than a spreadsheet or an ERP module. Someone in the warehouse must own scanning discipline. | A project fee and a maintenance agreement instead of per-user licences. |
The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences.
The decision turns on criteria, not brands. If your needs sit mostly in the middle column, making good use of your existing module is often enough; if the right-hand column dominates, a location-based, scan-driven warehouse layer comes into question.
| Criterion | The module is usually enough | An extra layer comes into question |
|---|---|---|
| Locations (rack and bin) | Goods sit in fixed places and a few people know where. | The system must show which rack and bin holds the goods, so new staff can find them without searching. |
| Scanning | Movements are entered in the office from paperwork. | Receipt, put-away and picking must be scanned on handheld terminals. |
| Batch, serial and expiry | Batches are tracked on the item record and picking order is followed by hand. | Which batch leaves first must follow a rule and be confirmed by scanning. |
| Picking and dispatch checks | Orders have few lines and wrong shipments are rare. | Pick lists must follow a route, and cartons and pallets must be scanned at loading. |
| Stock counts | One full count a year is enough. | Cycle counts by location must run without stopping operations. |
Module capabilities vary by product, version and licence; this is not a brand comparison. Ask your ERP partner what comes as standard in your version; we review it together during discovery. If your module is enough, we say so in writing.
A count discrepancy rarely has a single cause; it usually builds up from small movements that never get recorded. The table below shows the most common sources and the step in a warehouse system that closes each one.
| Source of discrepancy | How it happens | Which step in the system closes it |
|---|---|---|
| Unrecorded issues | Goods are taken from the warehouse in a hurry without paperwork. | Nothing leaves without a scan; urgent issues also have a short scan step and approval afterwards. |
| Unit-of-measure mix-ups | Conversions between cartons, packs and pieces are done wrongly. | Unit conversions are defined on the item record, and the scanned barcode carries the unit it represents. |
| One-sided transfers | In a transfer between warehouses the issue is recorded but the receipt is forgotten, or the other way round. | A transfer closes in two steps, with a scan on both the sending and receiving side; goods in transit are shown separately. |
| Returns | Goods returned by customers or the line go back on the shelf unchecked, or are not recorded. | Returns receipt is a separate flow; goods are checked, scanned and put away to the right location. |
| Material issued to production | Material handed to the line is not recorded, or is deducted later by recipe; scrap gets mixed into the difference. | Line feeding is scanned, so the gap between what was issued and what the recipe consumed is visible on its own. |
| Samples, scrap and waste | Goods given away as samples or damaged are not recorded. | Samples, scrap and waste are recorded with a reason and appear as separate lines in the discrepancy report. |
The system closes most of these sources, but not without scanning discipline; we do not promise that discrepancies will reach zero.
Most warehouses use a mix of these methods. Which one applies at which point is decided during discovery, based on the warehouse map and movement volumes.
| Method | Works well for | Limits | What it needs |
|---|---|---|---|
| Handheld terminal (Android, built-in barcode scanner) | Goods receipt, put-away, picking and counting; any task where the operator walks the warehouse. | Items are scanned one at a time; accuracy depends on the operator scanning every movement. Cold stores, dust and the risk of drops change which device is suitable. | One device per operator working at the same time, plus readable location and product labels; Wi-Fi across the warehouse or an app that works offline and syncs later. When working offline, stock and allocation data lag until the next sync; which tasks may run offline is decided during discovery. |
| Fixed scanner (conveyor, sorting line or packing station) | Places where goods always pass the same point: checking cartons at a packing station, diverting items on a conveyor or sorting line. | It only sees the point where it is installed and records nothing that happens between the racks. Labels must be clean and face the scanner. At a loading dock, barcode reading often needs a multi-camera set-up; for goods passing through the dock door, RFID is assessed separately. | Mounting, cabling or a network connection, and a rule for what happens after a read (confirm, warn, divert). |
| RFID | Points where many items must be read at once: pallet or carton receipt, passing through a door, high-value goods, or returnable crates and pallets. | With single-use tags the cost recurs on every item (tags on returnable crates and pallets are permanent). Metal and liquids can make reading harder, and nearby tags may be read unintentionally. That is why, during discovery, we assess it alongside barcodes at specific points rather than as a replacement for them. | An RFID tag on every item or pallet, readers and antennas, and an on-site read test before installation. |
| Smartphone camera | Low volumes, small branches or a pilot phase; occasional counts and transfer receipts. | Camera scanning is usually slower than a handheld terminal, struggles with distant or worn labels and tires operators during heavy picking. | A phone with an adequate camera; device-management and security rules if phones are not company-owned; user permissions and session management. |
Whichever method you choose, the first step is a location plan and readable labels.
Our guide to when an ERP inventory module is enough and when an extra warehouse layer comes into question, with six thresholds and a checklist: WMS or ERP inventory module?
If these are ready, the first call is concrete and the discovery scope can be written more precisely; we can fill any gaps together during discovery. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We walk the warehouse on site and map the flow exactly as it is: where goods come in, where they are put, in what order they are picked, at which point things get mixed up. An address plan and a labelling standard are prepared for aisles, racks, levels and bins. No software is written at this stage; the output is a warehouse map we have agreed on.
Address labels are printed and applied on site, and a labelling method is decided for items without a product barcode. Item records, units of measure, units per carton and batch rules are reviewed. If the master data is wrong, no warehouse system will work correctly, so rather than rushing this step we give it the time it needs.
Goods receipt, put-away, picking, transfer and dispatch flows are built, and the handheld application is trialled on site. We start with a single zone or a single product group rather than the whole warehouse. Keeping the scope narrow makes it easier for operators to adapt and lets us see errors at a small scale. Every delivery goes through a review step before it goes live.
In the pilot zone the system and the existing method run side by side for a while; differences are compared daily and their causes resolved. Once the results settle, the scope is widened zone by zone. Training is delivered at this stage and the handling of exceptions is written down. The transition is gradual; we do not recommend switching over completely in a single day.
Once the whole warehouse is live, count discrepancies, dispatch errors and picking times start to be measured; without measurement there is no meaningful conversation about improvement. We provide monitoring and fault resolution support under the maintenance scope defined in the contract. As the warehouse layout or the product structure changes, we update the address plan and the flows together with you.
An ERP stock module holds quantity and value; it does not hold which rack the goods are on, who took them or which order they were allocated to. If you cannot explain where a count discrepancy came from using ERP records, that is exactly where the gap is. A warehouse management system does not replace the ERP, it adds a layer of physical location and movement underneath it; the accounting side stays where it is. If the warehouse is small and the product range is narrow, the ERP stock module may well be enough — in that case we say so plainly during discovery and do not propose a project.
We do not recommend a large purchase up front. You start with as many devices as there are operators working simultaneously in the pilot zone, and add more as the scope widens. What decides the choice of device is not the brand but durability, battery life and read range; if there is a cold store or a dusty environment, the specification is written accordingly. We itemise the cost of devices, label printers and label consumables in the discovery report; we leave no surprise line item to appear once the software is finished.
It can. Addressing does not depend on a racking system; block-stacking areas, pallet positions and the outside yard can be addressed too. However, the vaguer the physical order is, the later the software's return becomes visible. In some warehouses the first job is not software but separating areas and marking floor positions; we say so during discovery and, if necessary, recommend that you hold the project until that field work is finished.
No, and we do not promise that. A warehouse management system does not remove stock counting; it stops it being a major event and spreads it across the year. With cycle counting, busy and high-value addresses are counted more often and slow-moving ones less often, and the line does not stop. The discrepancy rate falls over time, but we would advise caution towards any proposal that says discrepancies will go to zero. A physical count is the only independent method of auditing the system's accuracy.
It does not; they work side by side. Production tracking and MES follow the work order on the line, downtime and the quantity produced; a warehouse management system follows where material sits in the warehouse and how it moves. Where the two intersect is material issued to production and semi-finished goods received from the line; these two movements are defined in one place and the two systems feed each other. If you already have a production tracking system, we do not rewrite it, we connect to it.
The main factors are the number and size of your warehouses, the number of rack and bin locations to be addressed, handheld terminal, label printer and wireless network needs, the depth of integration with your existing ERP, how clean the item and stock data is, and lot/serial tracking and offline requirements. How much on-site effort the first count and location labelling will take also directly affects the timeline. We go through these points in the first call and, after discovery, share the scope, a staged budget and the timeline in writing; we do not quote a firm figure before discovery.
An addressed and labelled warehouse; goods receipt, put-away, picking, transfer and dispatch flows running on handheld terminals; batch and serial number traceability; a cycle counting regime; daily stock reconciliation with the ERP and a deviation report. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences.
A WMS (warehouse management system) is software that gives every rack and bin in the warehouse an address and records, by barcode, the physical location of goods, their movements and who made each movement. In the set-up we build, goods receipt, put-away, picking and dispatch checks run on handheld terminals; when the wrong product is scanned, a warning appears before loading. The accounting side stays in the ERP, and the WMS adds a layer of location and accountability beneath the quantity figure.
We listen to what you need and tell you whether custom development or an off-the-shelf product fits better. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We capture incoming, in-process and final inspection records on a tablet on the shop floor; when a non-conformance appears we quarantine the goods, start the corrective and preventive action (CAPA) flow and follow it through to closure. Measurements, certificates and approvals accumulate by batch, so you go into an ISO 9001 audit with a file that is already prepared rather than one assembled retrospectively from binders.
Details →Working from your bill of materials (BOM), we calculate which material is needed, in what quantity and by when; then we deduct stock on hand, open orders and lead times to produce dated order proposals for purchasing. With the MRP II layer we also test the same plan against machine capacity and labour.
Details →We build the software a dealership, a showroom and an authorised service centre run their own business on: vehicle or product stock, the showroom sales process, service appointments and work orders, warranty claims and integration with manufacturer-side systems come together in one structure. Your existing accounting package stays where it is, and the source code we write is transferred to you as defined in the contract.
Details →For companies whose sales run through dealers, distributors and solution partners we build channel software: partner records and tiering, target and commission calculation, lead sharing and conflict prevention, marketing collateral, and training and certification tracking are brought together in one place.
Details →We build a system that runs the work of your field reps from a phone: route and visit plans, mobile ordering, in-field collections, shelf and competitor photos and target tracking all come together in a single app. The app also works without an internet connection and synchronises by itself once the connection returns.
Details →We unify the customer data held on your website, e-commerce platform, CRM, call records and in-store tills under a single identity. Duplicate records are matched, segments are generated by rule, consent status travels with every record, and segments are pushed to channels in a controlled way. The aim is not another report, but a working customer view that the channels can use every day.
Details →
