Makdos WMS: barkodlu depo ve dağıtım

Makdos WMS is a barcode-based order, production, warehouse and distribution tracking system that I built for Makdos. WMS stands for warehouse management system. The system records cartons and pallets coming off production with barcodes, tracks their location in the warehouse, their best-before date and their quality status, has orders picked and loaded onto vehicles, records sales, deliveries and payments made from the vehicle, and performs the end-of-day reconciliation in the evening. I designed it as a multi-company product, and its first customer is using it in production.

Purpose

In companies that produce food and distribute it with their own vehicles, production, warehouse and sales teams often work without knowing what the others are doing. Which pallet sits on which shelf, which lot should go out first, or how much a driver has collected during the day is not fully known until the paperwork is gathered in the evening. Products close to their best-before date that do not leave on time translate directly into waste and cost.

I built this system to create a structure in which every step, from the moment a product leaves the production line to the moment it is delivered to the customer, is recorded with a barcode and reaches the office immediately. An important goal was that work in the field should not stop when the internet connection drops.

How it works

The system has three interfaces. Office staff use the web panel from their existing computer, phone or TV browser. Field staff in production, quality, warehouse, shipping and driver-sales use the app on Android handheld terminals. The Makdos team manages customer companies, invoices and support tickets from a separate platform administration panel.

I designed the terminal app to be offline-first. Every operation is first written to the device and, if there is an internet connection, sent to the server right away. If there is no connection, the worker carries on and the screen only shows the number of pending operations. Because each operation carries a unique identifier, it is counted once even if it reaches the server twice.

On the server I used an event-based record model. Every operation coming from a terminal is stored as an immutable event, and tables such as stock, pallets and orders are derived from these events. This approach keeps history traceable at all times and allows the tables to be rebuilt from the events when a calculation error is fixed.

For label printing, the server never tries to reach the printer. The shared terminal in the factory sends label commands itself to the industrial label printer on the local network. Because pallet serial number ranges are reserved for the device in advance, pallet labels can be printed even when the internet is down. Terminals in vehicles print receipts on a receipt printer connected over Bluetooth.

Key features

• Carton and pallet labels, pallet serial numbers, and lot and best-before date tracking form the core of the system.
• The FEFO rule, which means the pallet with the nearest best-before date leaves first, is enforced on the server; the terminal shows which pallet should go out first, and the panel measures FEFO compliance over the last thirty days and records who picked outside the rule, when, and by how many days.
• All the core warehouse processes are included, such as purchasing, advance shipping notices, goods receipt, putaway, transfers, replenishment, cycle counting, a task queue, pick waves and dispatch notes.
• The distribution module covers price lists, vehicle stock, payments and receipts, customer accounts, cheques and promissory notes, empty crate tracking, photo proof of delivery, trip and route planning, and unloading from vehicle to warehouse.
• The end-of-day reconciliation is blind, which means the driver enters the amount handed over without seeing the amount the system expects.
• For the cold chain there are temperature logs with threshold alerts, recall drills, a HACCP report and a key performance indicator dashboard.
• The panel includes a drag-and-drop designer for labels, receipts and dispatch notes, and designs can be checked and test-printed before they are published.
• Existing records can be imported from Excel, CSV, JSON or XML files through a four-step wizard that recognises the column names of common accounting programs.
• Data can be exported from every list, and there is a REST API for external systems that works with API keys and is documented with OpenAPI 3.1, along with webhook support for event notifications.
• There are connectors for Logo ERP and CRM systems, and for the Logo connection I wrote a small agent program that runs inside the customer's own network.
• The terminal menu is built from the intersection of the worker's role and the terminal's place of use; for example, a driver-salesperson can only sign in on the terminal assigned to their own vehicle.

Security

Office roles cannot sign in on terminals; terminals are open only to field roles. A setup administrator configures each terminal once, and after that field workers sign in with their own staff code and PIN. Passwords and PINs are encrypted with Fernet and verified with constant-time comparison. Company data is separated at row level in the database, and the company is resolved from the signed-in identity rather than from the domain name. I restricted outgoing webhook requests so that they cannot reach private or local network addresses. The web panel is closed to search engines.

Technical stack

• I wrote the server in Go as a single static program, using chi for routing, pgx for database access and goose for migrations.
• The database is PostgreSQL; the event table is append-only and the other tables are derived from those events.
• I use Valkey for caching, login rate limiting and the panel's live updates, and the panel receives live notifications from the server over SSE.
• The web panel and the platform administration panel are built with Next.js and React.
• I wrote the handheld terminal app with React Native; hardware access such as the scanner, printers and Bluetooth lives in small Kotlin modules, while the business logic is in TypeScript.
• There is a single Android app for all companies and all device models; it updates itself from the server without Google Play, and the company's logo and name are loaded from the server at sign-in.
• The label designer can turn the same design into several printer languages, receipt text, SVG and A4 HTML output.
• Services run directly on the server under systemd, behind nginx.

Use cases

• Producers that distribute the food they make to dealers and stores with their own vehicles can use this system.
• It suits warehouses that work with products with short shelf lives and want to reduce waste.
• It speeds up the end-of-day reconciliation for distribution teams that sell and collect payments from the vehicle.
• It is useful for companies that need to keep their cold chain and food safety records ready for audits.

Status

All modules, including the core flow, are live and the first customer is using the system. In the future I plan to turn the project into a more general, AI-assisted warehouse management product.