Бар: 4 000 позиций в инвентаризации и подписка за каждое рабочее место

MAATRIX

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

Что реально стоит за цифрой «4 000 позиций»

Число 4 000 в инвентаризации не берётся из воздуха — оно складывается из категорий, каждая из которых живёт по своим правилам учёта:

• Крепкий алкоголь. Виски, джин, ром, текила, ликёры — часто по 15-30 позиций в каждой категории при мало-мальски глубоком ассортименте сверх базовой полки. У каждой бутылки свой объём (0,5 / 0,7 / 1 л), и списание идёт не по бутылкам, а по миллилитрам через порционный дозатор или фри-пур с известным коэффициентом.
• Вино и игристое. Отдельная номенклатура по бокалам и по бутылкам, часто с разной ценой продажи в зависимости от того, продан бокал или бутылка целиком — две логики списания одного товара.
• Пиво и кеги. Кега считается не «одна штука», а объёмом с усушкой на пролив и пену — коэффициент отхода реально влияет на фактическую маржу и должен быть заведён в систему, а не оставаться в голове старшего бармена.
• Ингредиенты для коктейлей. Сиропы, биттеры, свежевыжатые соки, специи, гарниши (мята, цедра, вишня), лёд — тот же food cost, что у кухни, только с бо́льшим числом позиций на рецепт: классический коктейль легко тянет 5-8 ингредиентов, каждый со своей закупкой и сроком годности.
• Расходники и посуда. Стаканы под разные подачи, соломинки, шпажки для гарниша — формально мелочь, но именно она первой «убегает» из учёта, если система для неё неудобна.

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

Почему подписка «за рабочее место» растёт быстрее, чем кажется на старте

Модель pricing per seat выглядит безобидно на этапе продажи: «всего N рублей за пользователя в месяц» звучит скромно рядом с фиксированным тарифом за весь бар. Проблема в том, что число нужных пользователей в баре растёт вместе с самим форматом работы, а не остаётся постоянным:

• Каждый бармен в смене нуждается в доступе хотя бы для отметки продаж и списания открытых бутылок — если система интегрирована с кассой не полностью, кто-то вручную фиксирует розлив.
• Старший бармен отдельно ведёт приёмку поставок и корректировки после инвентаризации — часто это отдельная роль с более широкими правами, а не тот же логин, что у линейного бармена.
• Управляющий заведением нужен доступ к отчётам по марже, закупочным ценам и динамике списаний по каждой позиции.
• Бухгалтер или собственник — отдельная учётная запись для сверки с накладными и подготовки отчётности.
• Замены и стажёры. В баре текучка бывает выше, чем в кухонном штате, и каждый новый человек на испытательном сроке — это ещё одно рабочее место, которое нужно завести, даже если он проработает месяц.

Если посчитать честно, у бара с двумя-тремя барменами в смене, старшим барменом, управляющим и бухгалтером набирается 5-7 регулярных мест, а с учётом сменности и подработчиков — иногда больше. Модель «N рублей за место в месяц» умножается не на штатное расписание в вакууме, а на реальное число людей, которым нужен вход в систему прямо сейчас — и это число у бара структурно выше, чем у небольшого магазина с одним продавцом.

Отдельная ловушка — рост бизнеса делает подписку дороже даже без роста продаж. Открылась вторая точка — новый комплект рабочих мест. Перешли на посменный график с большим числом барменов — снова рост. Подписка за место растёт вместе со штатом, а не вместе с выручкой: штат вырос ради лучшего сервиса и контроля смен, а счёт за учёт вырос синхронно, хотя объём операций остался прежним.

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

Что должно уметь программное решение для инвентаризации бара

Прежде чем сравнивать модели оплаты, стоит зафиксировать, что вообще нужно баровской системе учёта функционально — иначе сравнение получится нечестным:

• Списание по рецептуре, а не по продаже целиком. Продали «Дайкири» — списались ром, лаймовый сок, сахарный сироп в тех граммах и миллилитрах, что заданы в техкарте, а не «одна условная единица напитка».
• Учёт в разных единицах измерения одновременно. Бутылка целиком на складе, но списание идёт в миллилитрах; кега — в литрах с коэффициентом усушки; сироп — в миллилитрах помпы.
• Контроль сроков годности скоропорта. Фреши, молоко для кофейных коктейлей, некоторые сиропы имеют короткий срок после вскрытия — система должна показывать остаток с датой, иначе порча выявляется только постфактум.
• Инвентаризационные ведомости по факту против расчёта по системе. Регулярная сверка должна автоматически показывать расхождение, а не требовать ручного сопоставления двух таблиц.
• Штрихкодирование или другой быстрый способ приёмки и корректировок. При тысячах позиций ручной ввод по названию — гарантированный источник ошибок и потерянного времени смены.
• Разграничение прав по ролям. Линейный бармен видит остатки и фиксирует розлив; закупочные цены и маржа доступны только управляющему и владельцу.

Этот список одинаково справедлив и для облачного SaaS, и для собственной системы — разница не в том, что умеет софт, а в том, где он размещён и как за него платят.

Своя система складского учёта: как это выглядит технически

Перенос учёта на собственный сервер не означает написание системы с нуля — чаще всего это готовое open-source решение под складской учёт (или простое кастомное веб-приложение под конкретные техкарты бара) в контролируемой инфраструктуре. Для одного бара или сети из двух-трёх точек этого достаточно на одном недорогом VPS.

Минимальная конфигурация — три сервиса в Docker Compose:

services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: bar_inventory
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - db_data:/var/lib/postgresql/data
    secrets: [db_password]

  backend:
    build: ./backend
    restart: unless-stopped
    depends_on: [db]
    env_file: .env

  nginx:
    image: nginx:stable
    restart: unless-stopped
    ports: ["443:443"]
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/letsencrypt

volumes: { db_data: }
secrets: { db_password: { file: ./secrets/db_password.txt } }

Ключевая часть — модель данных. Для бара с тысячами позиций и списанием по рецептам минимальная схема требует как минимум четырёх связанных таблиц: карточка товара (со своей единицей измерения), партия поставки (с датой и закупочной ценой), техкарта напитка (список ингредиентов с граммовкой/миллилитрами) и журнал движений склада:

create table items (
  id serial primary key,
  name text not null,
  category text not null,        -- крепкий алкоголь, вино, сироп, гарниш...
  unit text not null,             -- ml, g, pcs, keg
  reorder_level numeric
);

create table stock_batches (
  id serial primary key,
  item_id int references items(id),
  qty numeric not null,
  purchase_price numeric not null,
  received_at date not null,
  expires_at date
);

create table recipes (
  drink_name text not null,
  item_id int references items(id),
  qty_per_serving numeric not null
);

create table stock_movements (
  id serial primary key,
  item_id int references items(id),
  qty_delta numeric not null,     -- отрицательное значение при списании
  reason text not null,           -- sale, waste, correction, receipt
  created_at timestamptz default now()
);

Такая структура позволяет списывать ингредиенты автоматически при продаже (если касса отдаёт данные о чеке через API или пакетной выгрузкой), считать теоретический остаток по факту продаж и сверять его с физической инвентаризацией, видеть себестоимость каждого коктейля по текущим закупочным ценам последней партии, а не по устаревшему прайсу из прошлого квартала.

Ресурсов нужно немного: VPS с 2 vCPU и 4 ГБ RAM спокойно тянет базу с историей движений по складу для одной-двух точек — объём операций бара укладывается в сотни записей в смену. Доступ ограничивается на уровне инфраструктуры, а не только логики приложения: администрирование по SSH-ключу без пароля, веб-интерфейс закрыт HTTPS-сертификатом, а для управляющего и бухгалтера, которым нужен доступ вне бара, — через VPN, а не публичный вход с любого IP. Резервное копирование настраивается сразу, а не «когда-нибудь потом»:

# ежедневный дамп базы в 4:00 по крону, после закрытия смены
0 4 * * * docker exec -t db_container pg_dump -U bar bar_inventory | gzip > /backups/bar-$(date +\%F).sql.gz

Копии стоит синхронизировать в отдельное хранилище, а не оставлять только на диске того же сервера — если диск выйдет из строя, история себестоимости и расхождений не должна исчезнуть вместе с ним.

Перенос данных: от текущей системы (или Excel) к своей базе

Переход не происходит за один вечер, и здесь честнее сразу разложить его на этапы, чем обещать мгновенный результат.

1. Выгрузка текущего каталога. Большинство облачных систем учёта дают экспорт номенклатуры в CSV или Excel — даже с урезанной функциональностью экспорт названий, единиц измерения и текущих остатков обычно доступен. Если учёт пока ведётся в Excel — файл уже в нужном формате.
2. Нормализация единиц измерения. Часть позиций в старой системе считалась в бутылках, часть — в миллилитрах, часть — «на глаз». Перед импортом это стоит привести к единому стандарту по каждой категории, иначе расчёт списаний по рецептам с первого дня будет считать неверно.
3. Перенос техкарт. Рецептура каждого коктейля переносится с граммовкой и миллилитрами ингредиентов — самая трудоёмкая по времени часть, но именно она даёт автоматическое списание вместо ручного.
4. Контрольная инвентаризация на старте. Перед переключением стоит провести полную инвентаризацию и завести в базу реальные остатки, а не теоретические — иначе расхождения первого месяца будут следствием неверного стартового баланса, а не реальных потерь.
5. Параллельная работа две-три недели. Разумно вести обе системы одновременно короткий период, сверяя расхождения, прежде чем полностью отключать старую.

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

Честный баланс: что теряется и что приобретается

Перенос учёта на свой сервер — это не однозначный выигрыш без последствий, и стоит проговорить обе стороны прямо.

Что бар теряет, уходя от готового SaaS:

• Автоматические обновления функциональности — на своей системе развитие функциональности это либо своя доработка, либо привлечение подрядчика заново.
• Готовую поддержку по звонку — за свой сервер отвечает тот, кто его настроил: свой человек или подрядчик на договоре о сопровождении.
• Мобильные приложения «из коробки» — на своей системе это либо адаптивный веб-интерфейс, либо отдельная разработка.

Что бар получает взамен:

• Фиксированную стоимость независимо от штата. Открыли вторую точку, наняли ещё двух барменов на лето — счёт за инфраструктуру не изменился.
• Полный контроль над коммерчески чувствительными данными. Закупочные цены, реальная маржа по каждому коктейлю, расхождения по инвентаризации остаются на инфраструктуре, к которой доступ определяет только владелец бара.
• Кастомизацию под реальные техкарты — схема данных настраивается ровно под ассортимент конкретного бара, а не под усреднённый шаблон.
• Независимость от смены тарифной политики провайдера — история данных не привязана к тому, поднимет ли сторонний сервис цену на следующий год или изменит ли модель тарификации задним числом.

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

Оплатить аренду сервера из России можно картой или криптовалютой, что снимает отдельный вопрос с оплатой иностранного SaaS-сервиса, который у части провайдеров учёта для HoReCa встаёт не менее остро, чем вопрос цены за рабочее место.

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