Case Study · Retail

Gürmen MATS: moving inter-store transfers from Excel to a system that decides at SKU level

The Inter-Store Transfer System that moves products not selling in one Ramsey or Kip store to a store that sells them, before markdown. It selects receivers and senders by cover at option level, derives need from sales velocity, matches at SKU level, and runs block, single-unit and split-and-spread transfer types on one infrastructure. Delivered as a SQL project on Gürmen's server; results go to the ERP.

SKU
Decision unit: Cover
Receiver / sender: 3
Transfer types: SQL project
Delivery

Problem

If a product that is underperforming in one store can be moved to a store that sells it before markdown — while it is still profitable — sales speed up and the season-end markdown shrinks. Gürmen was doing this with a system of its own built in Excel: three transfer types, option-level conditions, manual decisions at SKU level. It did the job, but it was not sustainable, scalable or parametric; it was a spreadsheet rebuilt every week.

This was the first project of the consulting engagement that began with Gürmen at the end of 2023: MATS — the Inter-Store Transfer System. A process map and merchandising roadmap, Power BI reporting and CRM/e-commerce projects were defined in the same frame; MATS was chosen as the starting project.

Approach: candidates at option, decision at SKU

Lumtify’s algorithm took a leaner structure than Gürmen’s. A layered flow:

1. Constraints. Option × store pairs with sufficient warehouse stock, short shelf life, a recent transfer in or out, or stock below the threshold are eliminated up front. Which constraints are used and their thresholds are Gürmen’s decision; in the scope document, Gürmen’s feedback on every constraint was worked in one by one.

2. Receiver and sender — by cover. Sending and receiving stores are determined from the cover values the user enters. We chose cover because it is a measure every user readily understands, manages and can use to open or narrow the transfer with a single parameter: changing cover adjusts both the volume and the quality of transfers. Additional parameters such as the number of selling sizes and minimum sales count come into play especially when selecting receivers.

3. Need. For a product to go to a store there has to be a need at the receiver, and need requires a forecast. Because complex models bring little at store–SKU level, the forecast is built from sales over the last 7, 14, 28 and 56 days, season-to-date sales, the minimum assortment to be held, and a special-day adjustment.

4. Matching — at SKU level. Everything up to here was at option level. Matching happens by size: thresholds such as how much stock would be inflated, how much of the positive need is met and how many sizes meet it are checked. Threshold values differ by transfer type — the overstock ratio is kept low for block transfers and high for single-unit transfers.

5. Decision. A sender can match several receivers and a receiver several senders. The best matches are chosen by maximising scores that express match quality; the “how many stores can one store ship to” limit is decisive here.

Three transfer types, two modules

General transfer is the weekly routine: block logic that moves all or the deep part of an option from one store, singles travelling between the matched stores as well, and depth reduction. Highly actionable, more accurate on broken runs, fast to show results.

Size-based transfer — split and spread: the hard type, where an option is split by size and distributed to several stores without creating new broken runs. It is recommended where transfer completion rates are high; at low completion, if the split product does not leave, broken runs grow at both stores. General transfer went live first; size-based transfer was developed in parallel and went through six test rounds in autumn 2025.

Store closures and transfers to outlets were left out of scope — they can be added later.

System

Gürmen’s ERP is its own development, with data in PostgreSQL. The data MATS needs was prepared by Gürmen and opened to Lumtify; the algorithm was written and delivered as a SQL project on Gürmen’s virtual server: procedures, views, tables. Run at any moment, it proposes which product goes from which store to which, and in what quantity; every run is written to tables together with its calculations. The parameter screens were developed by Gürmen from Lumtify’s mockups and table design; integration and transfer to the ERP sit with Gürmen.

Outcome and what follows

MATS is in production as of 2025; at the December 2025 roadmap meeting it was cited among “the systems put into service in 2025”, and the roadmap for 2026 was drawn for the merchandising planning modules — initial allocation, replenishment, RPT, markdown optimization — and dashboards. As the first step, a weekly demand forecasting project at article–colour level for Ramsey and Kip basic categories was defined: lost sales calculation, special-day features, a pilot model, then store stock and prepack size distribution optimization.

How the model was built

Objective	Direction	Tension
Match quality score	↑	A sender can match several receivers and a receiver several senders; while the best matches are chosen, the limit on how many stores one store can ship to is the constraint that affects transfer volume most
Need met at the receiving store	↑	Need is a forecast derived from sales velocity; overfilling it inflates stock at the receiver

Constraints

Warehouse stock check — an option with enough warehouse stock is not transferred; broken warehouse stock is the exception
Store stock check — an option below the stock threshold cannot be a sender
Shelf life — an option × store below the shelf-life threshold does not enter the transfer
Transfer history — store–option pairs that received or sent a transfer in the defined period are checked
Stores per store — an operational transfer limit, by store type or per store
Capacity — transfers up to a percentage of stock for sender and receiver; Z-score if requested
Minimum parcel value — no transfer if the parcel going from one store to another is below the threshold
Overstock and need-coverage thresholds — with different values per transfer type

All our work