In facilities across the Başpınar organised industrial zone (OSB) and Şehitkamil, the warehouse is usually the last thing anyone thinks about: it occupies whatever space production left over, its records are split between a notebook and an Excel file, and the true picture lives only in the storekeeper's head. We bring that picture into a system. We address the racks, move stocktaking onto handheld terminals, and attach batch and lot numbers to the goods themselves. We do not replace your existing accounting software (Logo, Mikro, Netsis); we build the warehouse layer alongside it. The source code and the data stay with you. Our office is in Şehitkamil — the same city as your factory.
Let's start with what we do not do: we do not rip out your accounting software, and we do not migrate you to a new ERP. We build a layer that records what actually happens in the warehouse and runs alongside your existing system. We have applied this approach in the field: we built a production layer beside a factory's Netsis system without touching it, wrote an 11-module management panel for another facility, and prepared a 64-page field discovery guide for a factory's ERP scoping. The headings below are not a fixed package; on discovery day we decide together which of them your operation genuinely needs.
Your warehouse is addressed by aisle, rack, bin and level, and a barcode label goes up at every address. Goods are no longer recorded only on a stock card but at a physical place. Even a brand-new employee can read the address on the screen and find the goods; warehouse knowledge moves from the person to the company.
Counting is done with a handheld terminal, not a paper list; every scanned barcode is recorded instantly, and two people counting the same rack is prevented. In order picking, the terminal shows the next address and warns if you head to the wrong rack. When the device is offline, work does not stop: records accumulate on the device and transfer once the connection returns.
A batch or lot number is opened at goods-in and carried with the goods until they leave the warehouse. Dispatch order by use-by date can be set up for food, roll and metre tracking for textiles and carpet, reel and kilo tracking for plastics. When a complaint arrives, which batch it came from and where it went is read from the record, not from memory.
The goods for a confirmed order are set aside in the system; reserved goods are invisible to other sales. A critical level and lead time are defined for every stock item, and when the level is breached an alert goes to the purchasing and production leads. So a shortage is seen before the day it stops the line, not on it.
When a difference appears, the system does not close it automatically; it lists the difference, requires a reason to be entered, and stores who made the correction with user and timestamp. Every past movement can be reviewed. The aim is not to hunt for culprits but to make visible which item and which address the difference keeps recurring at.
The warehouse layer runs alongside your existing backbone — Logo, Mikro, Netsis; which information flows in which direction for stock cards, accounts and delivery notes is written down from the start. The chore of entering the same data in two places ends. Where integration is not possible, we say so before the project starts and build a file-based bridge.
We come to your factory and walk, step by step, the path the goods take from goods-in to goods-out. Who writes what, which paper goes where, how the count is done, who closes the differences — we see it all in place. The output of this day is not a quote but a written snapshot of the current state.
Before any software, we do the tedious but decisive work: the rack address scheme, the stock coding rules, unit definitions and the batch-number logic. If this foundation is laid wrong, no program built on top of it will hold. We take the decisions together with you and put them in writing.
We do not flip the whole warehouse overnight. One aisle or one material group is chosen, and addressing, counting and the goods-in/goods-out flow go live there. The old routine keeps running alongside for a while; the transition is not considered complete until the two records reconcile.
Once the pilot holds, we extend to the remaining zones. Training happens in front of the rack with the device in hand, not in a presentation room; we leave behind a one-page usage note written in the warehouse team's own language. If the person who will use the system has not understood it, the job is not finished.
The source code, database structure, installation steps and known limitations are handed to you in writing. If you want to continue with another team tomorrow, you will be in a position to do so. Support runs separately, with a transparent scope, on a per-ticket basis.
The stock module in accounting software keeps the quantity of the goods; it does not keep where in the warehouse the goods are, which batch they came from, or their real state on the rack. Count differences mostly grow out of exactly that gap. We do not replace Logo; we build the layer that closes the gap alongside it. And if discovery shows your existing module already covers your need, we tell you so openly — we do not try to sell a need that is not there.
Either works; the choice depends on the warehouse. In a warehouse doing a few hundred scans a day that is neither dusty nor cold, a rugged Android phone does the job. In warehouses with constant scanning through the shift, heavy goods and a harsh environment, a trigger-grip handheld terminal is the better call; scan speed and device lifespan differ. We write the software to run on both, and the hardware decision is made after seeing the warehouse.
That objection is fair, and it is the starting point of the design. We reduce the floor screen to three things: large text, one action, few buttons. The person scans; the screen confirms or warns. Complex reports go to the office user, while the floor screen shows only what is needed at that moment. In the pilot zone we prefer to work with the most reluctant person on the team; if they can use it, the design is right.
No — and be wary of anyone who promises zero. Differences come from human error, breakage, samples and unrecorded issues; software does not abolish them. What software does is make the difference visible and traceable: you see which item, which shift and which address it keeps recurring at. How far it then falls depends on the decisions you take with that visibility; we do not commit to a number up front.
It depends on warehouse size, the number of stock items, batch-lot needs and integration depth. So we split the work into fixed-scope stages: first discovery and a state-of-play report, then a pilot in one zone, then roll-out. At the end of each stage you see what came out and decide whether to continue; you will not face an open-ended consultancy bill.
Yes, we also do the labelling leg of stock and warehouse work. Rack address labels, product barcodes, carton and pallet labels and dispatch labels are parts of the same system; for goods sold by weight, a weighbridge connection can also be set up. If warehouse records and labelling are set up as two separate projects, both end up half-done, so we handle them together.
We plan for this from the start. Handheld terminals work without a connection too: records accumulate on the device and transfer once the connection returns. On the server side, backup and restore drills are part of the installation scope; we test not that the backup was taken, but that it restores. A written fallback plan for running the critical flows by hand is also left with you.
No. The system can run on a server in your factory or on a cloud server opened in your name; which is right depends on the connection between your warehouse and office and on how many sites you have. In both cases the database, source code and documentation are handed over to you; you pay no monthly per-user licence, and you do not need our permission to move your data.
We come to your facility in the Başpınar OSB or Şehitkamil and walk with you the path the goods take from goods-in to dispatch. You end up holding a written snapshot of the current state and a clear order of where to start. We are in the same city; this first meeting requires no commitment from you.
