Склад на OpenBoxes: когда полноценная ERP только мешает кладовщику

MAATRIX

Когда компании нужен склад — партии, сроки годности, движения между точками хранения, — а не «ERP на всё», разворачивание Odoo или ERPNext часто превращается в борьбу с лишним: настройка модулей продаж, которые не нужны, бухгалтерских цепочек, которые дублируют уже работающую 1С, прав доступа для ролей, которых в штате просто нет. OpenBoxes — открытая система, изначально построенная под учёт медицинских и гуманитарных грузов, но по факту это просто честный складской учёт без всего лишнего. Разберём, что она умеет, где у неё жёсткие ограничения и кому она действительно подходит больше, чем тяжёлая ERP.

Откуда взялся OpenBoxes и зачем он существует

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

Отсюда и вырос набор функций, который отличает OpenBoxes от обычных систем складского учёта общего назначения: строгий учёт партий (lot/batch) и сроков годности как base-функциональность, а не надстройка; поддержка сети складов и распределительных пунктов с движением товара между ними; работа в условиях нестабильного интернета, характерных для полевых точек. Проект открытый, код доступен на GitHub, развивается сообществом с участием организаций, которые используют его в реальных программах снабжения.

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

Что OpenBoxes умеет из коробки

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

• Мультисклад и локации внутри склада — иерархия «склад → зона → стеллаж → ячейка», можно видеть не просто «товар на складе А», а конкретное место хранения.
• Учёт партий и сроков годности — при поступлении товара фиксируется номер партии и дата истечения; система показывает, какая партия ближе всего к списанию, и позволяет настраивать логику FEFO (first-expired-first-out) вместо простого FIFO.
• Складские операции полного цикла — приёмка, размещение, инвентаризация, комплектация (picking), упаковка, отгрузка; каждая операция логируется с привязкой к пользователю и времени.
• Заявки и внутренние перемещения — заказы на пополнение между складами, запросы от точек потребления, статус выполнения на каждом этапе.
• Штрихкодирование — генерация и печать этикеток, сканирование при приёмке и отгрузке для снижения ручных ошибок.
• Отчётность по остаткам и движению — сводки по остаткам на дату, история движений по товару, отчёты по товарам с истекающим сроком годности.
• Ролевая модель доступа — разделение прав между кладовщиком, менеджером склада и администратором системы.

Всё это работает без необходимости настраивать модуль продаж, воронку CRM, план счетов или производственные маршруты — их в системе попросту нет, и это осознанное решение архитектуры, а не недоделка.

Чем это принципиально отличается от Odoo и ERPNext

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

OpenBoxes устроен иначе: он не пытается быть ERP. В нём нет модуля продаж как воронки сделок, нет бухгалтерского плана счетов, нет производственных заказов и спецификаций (BOM), нет HR и начисления зарплаты. Это чистый WMS (warehouse management system) с прицелом на снабжение, а не на весь бизнес-цикл. Если компании нужен именно склад, а не единая система для всего, то в Odoo и ERPNext вы платите ресурсами сервера, временем на настройку и когнитивной нагрузкой администратора за функциональность, которой не будете пользоваться.

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

Ограничения, которые нужно понимать заранее

Честно: OpenBoxes — не панацея, и у него есть реальные слабые места, которые стоит взвесить до внедрения.

• Нет встроенной бухгалтерии. Если вам нужна интеграция «списание товара — проводка по счетам» в одной системе, придётся либо настраивать выгрузку в отдельную бухгалтерскую систему (1С, аналог), либо смириться с ручной сверкой.
• Интерфейс не такой отполированный, как у коммерческих SaaS-решений. Проект развивается сообществом с ограниченными ресурсами, приоритет — функциональность для целевых пользователей (медицинские и гуманитарные снабженческие организации), а не UX-полировка под массовый розничный рынок.
• Меньшее сообщество и меньше готовых интеграций, чем у Odoo или ERPNext. Если вам нужен модуль под конкретную специфику (например, интеграция с маркетплейсами), скорее всего, придётся дорабатывать самостоятельно или заказывать кастомную разработку — готового модуля из коробки может не быть.
• Локализация под российские реалии не гарантирована. Интерфейс поддерживает несколько языков, но глубина перевода и соответствие специфике российского документооборота (счета-фактуры, УПД и подобное) не встроены — система в принципе не заточена под конкретное законодательство какой-либо страны, это международный инструмент снабженческой логистики.
• Нет встроенного POS (кассы) и полноценной CRM. Если помимо склада вам нужна точка продаж или воронка сделок с клиентами, это будет отдельная система рядом, а не модуль внутри OpenBoxes.

Ни один из этих пунктов не отменяет ценность системы для правильного сценария использования, но каждый стоит проговорить до того, как принимать решение о переходе, а не после.

Для кого это правильный выбор

OpenBoxes имеет смысл, если у вас совпадает несколько условий одновременно:

• Складской учёт — это отдельная, самостоятельная задача, а не часть более широкого ERP-контура. Бухгалтерия, продажи и прочее уже решены другими системами, и связывать их в одну монолитную ERP смысла нет.
• Партии и сроки годности критичны для бизнеса. Фармацевтика, медицинские изделия, косметика, продукты питания, реагенты, химия с ограниченным сроком хранения — везде, где просрочка это не абстрактный риск, а реальные потери или, для медицины, риск для здоровья.
• Есть сеть складов или распределительных точек, между которыми регулярно перемещается товар, и нужен единый взгляд на остатки по всей сети, а не по каждой точке отдельно в своей табличке.
• Команда не готова содержать администратора крупной ERP-системы. Развёртывание и поддержка OpenBoxes проще, чем полноценного Odoo с десятками модулей, — меньше поверхность для ошибок конфигурации.
• NGO, гуманитарные организации, фонды снабжения — прямое попадание в исходное назначение системы, с бонусом в виде сообщества, которое понимает специфику подобных операций.

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

Требования к хостингу и развёртывание

OpenBoxes — Java-приложение, построенное на фреймворке Grails (Groovy поверх JVM), с базой данных MySQL или совместимым с ним MariaDB. Это значит, что стек для самостоятельного хостинга такой же, как у многих корпоративных Java-систем: JVM определённой версии, база данных, и обычно nginx или Apache перед приложением как reverse proxy и точка терминации TLS — настройку самого nginx для этой роли мы разбирали в статье про Nginx как reverse proxy.

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

• Тестовый стенд или небольшая команда (до 5-10 одновременных пользователей) — обычно достаточно 2 vCPU и 4 GB оперативной памяти. JVM требует выделенного объёма памяти под heap, и с запасом эта конфигурация справляется с базовыми операциями без задержек.
• Продакшен на десятки одновременных пользователей и несколько складов — стоит закладывать больше памяти, ориентировочно от 8 GB, и следить за настройками heap для JVM отдельно от системной памяти под MySQL. Точные цифры зависят от объёма каталога товаров, глубины истории движений и интенсивности отчётности — это нужно проверять нагрузочным тестированием на своих данных, а не полагаться на усреднённые оценки.
• Диск — важнее закладывать запас под рост базы данных (история движений накапливается быстро при активном складе) и под резервные копии, чем под само приложение, которое занимает немного места.

Разворачивать систему можно либо вручную (установка JVM, сборка или получение готового артефакта, настройка базы, конфигурация приложения), либо через контейнеризацию, если в репозитории проекта или сообществе есть актуальный Docker-образ — на момент подготовки статьи (конец августа 2026 года) стоит свериться с официальной документацией на GitHub-репозитории проекта, поскольку состояние готовых образов и поддерживаемых версий меняется быстрее, чем успевают обновляться сторонние гайды.

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

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