Шиномонтаж и сезонное хранение: учёт 800 комплектов шин без платы за приёмщика

MAATRIX

Два раза в год, в апреле и в октябре, шиномонтаж с сезонным хранением превращается в логистический узел: сотни комплектов шин заезжают и выезжают за несколько недель, и если не знать точно, какой комплект где лежит и кому он принадлежит, сезон превращается в разбор конфликтов вместо работы. При 800 комплектах на хранении бумажный журнал и Excel перестают справляться уже на второй сотне, а облачные сервисы учёта часто выставляют счёт не за функциональность, а за количество сотрудников, которые принимают шины. Разберём, как вместо растущей помесячной платы за приёмщика получить свою базу учёта на сервере с фиксированной стоимостью.

Почему 800 комплектов шин — это не склад, а живая база данных

Хранение шин выглядит как складская задача, но по факту это база данных с постоянным движением. У каждого комплекта есть владелец с телефоном и часто с двумя автомобилями сразу, есть физическое место — стеллаж, ряд, ячейка, — есть состояние (новые, б/у, с грыжей на боковине, без одного диска), есть дата приёмки и ожидаемая (а на деле — произвольная) дата выдачи. Часть клиентов приходит забирать шины в первую тёплую неделю марта, часть — когда уже выпал снег в ноябре, и это создаёт не равномерную нагрузку, а два пиковых окна, в которые ошибка учёта стоит дороже всего.

Добавьте к этому естественные источники путаницы конкретно для 800 комплектов: одинаковые модели и размеры шин у разных клиентов, диски без маркировки, комплекты, которые сдал один человек, а забирает другой (муж привёз — жена забирает), утеря бумажной квитанции клиентом. При таком объёме вручную сопоставить «кто говорит, что это его колёса» с тем, что реально стоит на стеллаже A-14, без надёжной системы — рулетка. Учёт шин на этом масштабе — это по сути CRM с элементами складского учёта, и относиться к нему стоит именно так, а не как к записи в тетради.

Что ломается при учёте на бумаге и в Excel

Пока комплектов было 100–150, тетрадь и Excel-таблица на общем диске работали: мастер приёмки записывал клиента, размер шин и номер полки, при выдаче вычёркивал строку. На 800 комплектах этот подход ломается по нескольким конкретным причинам.

Во-первых, Excel не выдерживает параллельного редактирования: если два приёмщика одновременно вписывают клиентов в один файл на сетевом диске, кто-то теряет изменения или файл блокируется на запись. Во-вторых, нет истории изменений — если строку случайно стёрли или перезаписали, узнать, кто это сделал и когда, невозможно. В-третьих, поиск по такой таблице — это Ctrl+F по фамилии, которая может быть записана с ошибкой, через дефис или без; поиск по номеру телефона или гос. номеру машины уже требует ручного просмотра. В-четвёртых, бумажная квитанция клиента — единственная связь между ним и записью в таблице, а квитанции теряются, размокают в бардачке, выбрасываются вместе со старыми документами.

Отдельная проблема — печать бирок. Рукописная бирка на комплекте («Иванов, 205/55R16») не решает задачу однозначной идентификации: почерк не читается, бирка отклеивается, а на морозе клей вообще не держит. На объёме 800 комплектов это уже не мелкая неприятность, а системный риск перепутать чей-то комплект — и весной вернуть клиенту не его шины.

Облачные сервисы учёта шин и их модель тарификации

На рынке есть готовые облачные сервисы для шиномонтажей и складов хранения — они закрывают базовые задачи (карточка клиента, карточка комплекта, ячейка) быстрее, чем собственная разработка с нуля. Проблема не в функциональности, а в модели тарификации, распространённой среди таких сервисов: плата растёт не от объёма хранения, а от числа сотрудников, которые заходят в систему — по сути, плата «за приёмщика» или «за рабочее место». Чем больше у вас точек приёма и чем больше людей одновременно работает с базой в сезон (а в пиковые недели вы обычно нанимаете временных сотрудников на приёмку), тем больше платите — причём эта плата растёт линейно и бессрочно, а не один раз.

Вторая типичная черта таких сервисов — данные клиентов (ФИО, телефон, адрес, история визитов) физически лежат на инфраструктуре вендора, а не у вас. Это не всегда критично, но означает зависимость: смена тарифа, блокировка аккаунта за просрочку оплаты или уход сервиса с рынка — и вы либо платите по новым условиям, либо теряете доступ к базе клиентов, которую собирали годами. Третья черта — ограничения на выгрузку и интеграцию: не любой сервис легко отдаёт данные в 1С, в свою CRM или в собственный Telegram-бот с напоминаниями, потому что это чужая платформа с чужими правилами API.

Ничего криминального в такой модели нет — многие сервисы честно предупреждают о тарификации по местам в описании продукта. Просто для шиномонтажа с 800 комплектами и несколькими приёмщиками в сезон эта модель со временем оказывается дороже, чем кажется на старте, когда считали только «сколько стоит тариф на одного пользователя».

Что на самом деле нужно от системы учёта

Прежде чем писать или настраивать свою базу, стоит зафиксировать реальный список требований — он у шиномонтажа почти всегда один и тот же:

• карточка клиента: ФИО, телефон, гос. номер автомобиля, отметка о согласии на хранение персональных данных;
• карточка комплекта: марка и размер шин, диски или без дисков, состояние, фото при приёмке (это снимает половину споров «а у меня были не такие царапины»);
• физическое место: стеллаж, ряд, ячейка — с возможностью быстро увидеть, что где лежит, а не искать по всему складу;
• статус: на хранении / выдан / просрочен (лежит дольше договорного срока);
• поиск по любому полю за секунды — телефон, фамилия, гос. номер, номер бирки;
• печать бирки с уникальным номером и, желательно, QR- или штрихкодом — на принтере этикеток, а не от руки;
• доступ нескольких сотрудников одновременно без ограничения по числу учётных записей;
• напоминание клиенту, когда пора забирать комплект (вручную обзванивать 800 клиентов — отдельная работа на несколько дней).

Ни один из этих пунктов не требует облачного SaaS — это стандартная реляционная база данных с простым веб-интерфейсом поверх неё, и такую конфигурацию вполне реально развернуть на собственном сервере за один рабочий день, даже без опыта программирования.

Своя база на сервере: как это устроено на практике

Самый быстрый путь — не писать веб-приложение с нуля, а поднять на своём сервере self-hosted no-code базу данных с готовым интерфейсом, вроде Baserow или NocoDB (открытые аналоги Airtable). Вы получаете таблицы со связями, фильтрами, представлениями (канбан по статусу «на хранении / выдан»), формами для приёмки и веб-интерфейс, доступный с любого браузера — планшета на приёмке, компьютера администратора, телефона мастера на складе. Разворачивается это на обычном VPS: для базы на 800 комплектов и десятка одновременных пользователей хватает 2 ядер и 4 ГБ оперативной памяти с запасом, дальнейший рост упирается не в железо, а в дисциплину заполнения. Пошаговая установка описана в гайде по Baserow на Ubuntu 24.04.

Структура данных при этом простая — по сути три связанные таблицы:

clients:      id, fio, phone, car_plate, consent_pdn
tire_sets:    id, client_id, brand, size, condition,
              photo_url, tag_code, status, received_at
storage_cells: id, rack, row, cell_number, tire_set_id

Для каждого комплекта при приёмке генерируется уникальный код бирки (простой инкремент или QR со ссылкой на карточку в базе), печатается на термопринтере этикеток и клеится на комплект и на ячейку хранения — так при выдаче достаточно свериться взглядом, а не листать журнал. Если объём бизнеса вырастет за пределы возможностей no-code интерфейса или понадобится тонкая логика (автоматический расчёт стоимости хранения по дням, интеграция с 1С или сайтом онлайн-записи), тот же сервер поднимает и полноценную СУБД — настройка PostgreSQL на VPS описана отдельно, а таблицы выше без изменений ложатся в обычные SQL-схемы.

Отдельно стоит вопрос уведомлений: клиенту не нужно звонить лично, если система сама пишет в Telegram или отправляет SMS за неделю до конца сезона хранения. Простой бот, читающий поле received_at и статус в той же базе, разворачивается на том же сервере — как это сделать, разобрано в статье про запуск Telegram-бота на Python на VPS.

Экономика: фиксированная цена сервера против растущей платы за пользователей

Ключевое отличие своей базы от облачного сервиса — характер расходов. У облачного SaaS с тарификацией «за приёмщика» счёт растёт вместе с бизнесом: наняли ещё одного мастера на сезон — заплатили за ещё одно место, открыли вторую точку приёма — заплатили за неё отдельно. Формально каждая надбавка небольшая, но за несколько сезонов сумма ощутимо превышает то, что казалось «недорогим тарифом» на старте.

У своего сервера модель другая: вы платите фиксированную ежемесячную стоимость аренды VPS или выделенного сервера, и она не зависит от того, сколько человек авторизуется в базе — хоть два приёмщика, хоть десять на пике сезона. Растут только реальные затраты на масштаб — диск под фотографии комплектов (для 800 комплектов с фото при приёмке это единицы, максимум первые десятки гигабайт) и, если бизнес расширяется на порядок, апгрейд конфигурации сервера, а не покупка дополнительных лицензий на пользователя.

Второй пункт экономики — сохранность данных. База клиентов и история хранения — это актив, который нельзя потерять из-за сбоя диска или ошибки сотрудника. На своём сервере ответственность за резервное копирование лежит на вас, и это стоит воспринимать не как обузу, а как контроль: настроить регулярный бэкап базы данных без остановки сервиса — задача на час, разобрана в статье про бэкап баз данных без остановки. В облачном сервисе вы, как правило, доверяете сохранность данных вендору и его собственному регламенту бэкапов, который со стороны не проверить.

И третий момент — соответствие фактическому масштабу задачи. База на 800 комплектов шин весит на диске незначительно по объёму, и для неё не нужен мощный сервер — переплата за избыточное железо здесь такая же ошибка, как недооценка нагрузки. Разумная стратегия — взять VPS с запасом по CPU/RAM на пиковый сезон, когда одновременно работает несколько приёмщиков, и не переплачивать за простой в межсезонье.

Частые вопросы