Сыроварня: прослеживаемость партии от молока до этикетки на своём сервере

MAATRIX

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

Почему бумажный журнал цеха перестаёт спасать при росте

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

Пока сыроварня делает один сорт сыра и одну партию молока в день, эта связь восстанавливается легко: одна дата — одна партия, всё в одной голове у технолога. Как только объём растёт — несколько партий молока в день от разных поставщиков, два-три сорта параллельно, — дата перестаёт быть уникальным ключом. 14 августа могло быть три партии молока, из которых сделали пять партий сычужной обработки, разъехавшихся по трём камерам созревания с разными сроками. Спросить «из какого молока эта головка на полке» становится задачей — пролистать несколько тетрадей и свериться с почерком сыродела, который сейчас в отпуске.

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

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

Что даёт прослеживаемость партии на практике

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

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

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

Модель данных: от партии молока до этикетки на прилавке

Прежде чем говорить об интерфейсе для цеха, полезно увидеть саму структуру данных — она сильно отличается от плоской тетрадной записи именно тем, что каждый этап явно ссылается на предыдущий. Минимальная схема для сыроварни, если хранить её в PostgreSQL (почему именно её, а не MySQL, разобрано в статье PostgreSQL или MySQL: что выбрать для сервера), обычно состоит из четырёх-пяти таблиц:

CREATE TABLE milk_lots (
    id SERIAL PRIMARY KEY,
    supplier TEXT NOT NULL,
    received_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    volume_liters NUMERIC(8,1) NOT NULL CHECK (volume_liters > 0),
    fat_percent NUMERIC(4,2),
    accepted_by TEXT NOT NULL
);

CREATE TABLE curd_batches (
    id SERIAL PRIMARY KEY,
    cheese_type TEXT NOT NULL,
    started_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    cheesemaker TEXT NOT NULL
);

-- одна партия свёртывания может использовать молоко из нескольких приёмок,
-- и наоборот — из одной приёмки молока может выйти несколько партий разных сортов
CREATE TABLE curd_batch_milk_lots (
    curd_batch_id INTEGER REFERENCES curd_batches(id),
    milk_lot_id INTEGER REFERENCES milk_lots(id),
    volume_used_liters NUMERIC(8,1) NOT NULL CHECK (volume_used_liters > 0),
    PRIMARY KEY (curd_batch_id, milk_lot_id)
);

CREATE TABLE aging_batches (
    id SERIAL PRIMARY KEY,
    curd_batch_id INTEGER REFERENCES curd_batches(id),
    wheel_count INTEGER NOT NULL CHECK (wheel_count > 0),
    chamber TEXT NOT NULL,
    moved_to_aging_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    planned_ready_at DATE
);

CREATE TABLE packages (
    id SERIAL PRIMARY KEY,
    aging_batch_id INTEGER REFERENCES aging_batches(id),
    label_code TEXT UNIQUE NOT NULL,
    weight_grams NUMERIC(8,1),
    packaged_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    packaged_by TEXT NOT NULL
);

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

Дальше цепочка линейная: curd_batches → aging_batches (партия головок, которые вместе пошли на определённую полку камеры созревания) → packages (готовые упаковки с уникальным кодом этикетки, каждая ссылается на конкретную партию созревания). Если сорт требует нескольких этапов созревания на разных полках или в разных камерах — например, сначала обсушка, потом основное созревание, — можно добавить поле previous_aging_batch_id в саму aging_batches, чтобы цепочка не обрывалась и внутри созревания.

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

Как это выглядит в цехе: ввод данных, не мешающий работе

Модель данных красивая на бумаге, но если её ввод занимает у сыродела десять минут при мокрых руках — систему возненавидят и вернутся к тетради через месяц. Ввод должен занимать секунды, а не минуты.

Практический вариант — не писать интерфейс с нуля, а развернуть на своём сервере low-code инструмент вроде NocoDB или Baserow поверх той же PostgreSQL: готовые формы ввода, выпадающие списки вместо свободного текста, ограничения на обязательные поля. Сравнение и готовые docker-compose файлы — в статье NocoDB или Baserow: что выгоднее и когда. Форма приёмки молока — это пять полей и кнопка «сохранить» на планшете в приёмном цехе, а не сшивание таблиц вручную.

Дальше — вопрос, как связывать записи между цехами без ручного набора номера партии. Практика, которая реально снимает нагрузку: каждой партии молока при приёмке присваивается номер, который тут же печатается на наклейке для ёмкости — с QR-кодом, если есть принтер этикеток. Сыродел в цехе свёртывания не вспоминает и не переписывает номер — сканирует наклейку, номер подставляется в форму сам. То же самое на выходе из созревания: наклейка на стеллаже с номером партии, которую сканируют при фасовке, — и код готовой этикетки автоматически связывается с нужной aging_batch_id.

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

Отзыв партии: как это ищется за секунды, а не за день

Ситуация, ради которой всё это строится: нужно быстро найти, куда именно попала продукция из конкретной партии молока или конкретной партии свёртывания. Без системы это ручной перебор журналов за нужный период. С базой данных — один запрос в любую сторону цепочки.

Найти все упаковки, сделанные из молока конкретного поставщика за проблемную приёмку (движение вперёд по цепочке, от молока к прилавку):

SELECT p.label_code, p.packaged_at, p.weight_grams
FROM packages p
JOIN aging_batches ab ON ab.id = p.aging_batch_id
JOIN curd_batches cb ON cb.id = ab.curd_batch_id
JOIN curd_batch_milk_lots cbml ON cbml.curd_batch_id = cb.id
WHERE cbml.milk_lot_id = 4231
ORDER BY p.packaged_at;

Найти, из какого молока и от какого сыродела сделана конкретная упаковка по коду с этикетки (движение назад по цепочке, от прилавка к молоку) — это ровно тот запрос, который нужен, когда пришла жалоба покупателя на конкретную упаковку:

SELECT ml.supplier, ml.received_at, cbml.volume_used_liters, cb.cheesemaker
FROM packages p
JOIN aging_batches ab ON ab.id = p.aging_batch_id
JOIN curd_batches cb ON cb.id = ab.curd_batch_id
JOIN curd_batch_milk_lots cbml ON cbml.curd_batch_id = cb.id
JOIN milk_lots ml ON ml.id = cbml.milk_lot_id
WHERE p.label_code = 'CHV-2026-08-0142';

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

Отдельно стоит завести VIEW или сохранённый отчёт для типовых вопросов — «что сейчас в камере созревания и когда готово», «сколько упаковок сделано за смену» — чтобы не переписывать запрос каждый раз заново, а открывать готовую страницу в NocoDB или в простой админке.

Где это крутится: сервер, доступ, резервное копирование

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

Доступ стоит разграничить по ролям с самого начала, а не «потом, когда вырастем»: сыродел вносит партии свёртывания и не видит закупочные цены молока, ответственный за созревание видит и правит только камеры и полки, руководитель видит всё и строит отчёты. Это стандартная модель прав на уровне СУБД и веб-интерфейса поверх неё, а не самодельные пароли на тетради.

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

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