Примеры использования ERPNext: шесть сценариев для стройки, опта, производства и услуг

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

Шесть сценариев, которые ERPNext закрывает без разработки

Меня часто спрашивают: «А что ваш ERPNext вообще умеет?» Отвечаю сценариями, а не списком модулей. Список модулей ничего не говорит про вашу работу, а сценарий — это цепочка документов, которую можно пройти руками на демо. Ниже шесть цепочек, которые мы чаще всего запускаем у малых компаний от 5 до 30 человек. По каждой честно отмечено, что работает из коробки, что требует настройки, а что — доработки. Если нужна помощь с запуском, мы делаем это в формате ERPNext под ключ.

Матрица ниже — карта всей статьи: | Сценарий | Из коробки | Настройка | Доработка | |---|---|---|---| | Заявка с объекта | да, Material Request | поля и права | печатные формы | | Контроль перебора | контроль сумм по Budget | статьи затрат | контроль по количеству | | Партии и срок годности | Batch, срок годности | флаги карточки и Stock Settings | отчёты по срокам | | Микропроизводство | Item, BOM, Work Order | склады, роли | выпуск нескольких изделий | | Возврат от покупателя | Sales Return, Credit Note | флаг Update Stock | российские формы | | Счёт по табелю | Timesheet, Sales Invoice | ставки, права на табели | формы под ваши акты |

Два общих замечания. Первое: везде, где в таблице стоит «доработка», стоимость и объём фиксируются в техническом задании. Из коробки не получится всё сразу, и обещать обратное нечестно. Второе: ERPNext не заменяет регламентированный учёт. Типовая схема в России — два контура: операционка в ERPNext, налоги и отчётность в 1С. Подробнее про устройство системы и ограничения я писал в обзоре ERPNext для малого бизнеса и производства.

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

Стройка: заявка с объекта, перебор и склад площадки

Первая цепочка — заявка на материалы. Прораб создаёт документ Material Request со смартфона: ERPNext работает как PWA в браузере, ничего ставить из магазина приложений не нужно. В заявке объект (Project), позиции, количество, срок и склад назначения. Заявка сразу попадает снабженцу, а не теряется в мессенджере. Это из коробки. Полевые особенности вроде обязательного ответственного на объекте добавляются пользовательскими полями. Ограничение, о котором надо сказать сразу: PWA не работает офлайн, поэтому на площадке без связи заявку не оформить, придётся подождать сеть.

Вторая — контроль перебора. Штатный Budget контролирует деньги, а не количество: в документации прямо сказано, что бюджет учитывает суммы, не создаёт проводок и не двигает деньги. Для каждого этапа задаётся действие при превышении: Stop блокирует проведение, Warn предупреждает, Ignore ничего не делает. В нашей схеме для заявки обычно ставят Warn, для заказа поставщику — Stop. Но это контроль по суммам статей затрат. Контроль «заказали 13,5 т арматуры при договоре на 12 т» по количеству — это доработка: пользовательские поля в строках заявки и проверка при сохранении. Мы называем её настройкой «поверх штатных механизмов» и фиксируем в техническом задании.

Третья — согласование. Для заказа поставщику строится Workflow: снабженец создаёт, руководитель проверяет, бухгалтер утверждает. Для команды в 5–6 человек сложный параллельный маршрут не нужен, хватает последовательной цепочки. Самосогласование закрывается штатно: у перехода в Workflow есть флажок Allow Self Approval, по умолчанию он включён, и у шагов утверждения его нужно снять. А вот параллельного согласования, когда двое согласуют одновременно и нужны обе подписи, из коробки нет.

Четвёртая — склад площадки. Материалы приходуются на центральный склад, затем перемещаются документом Material Transfer на склад объекта, а расход оформляется списанием со склада объекта. Так руководитель видит, сколько лежит на площадке и сколько ушло в дело. Для каждого нового проекта нужен свой склад в иерархии, и эту рутину удобно закрыть шаблоном. Прибыльность объекта считается по связке Project, Cost Center и статей затрат; регламентированную отчётность по этим же данным готовит 1С.

Торговля и склад: партии, сроки годности, упаковки и возвраты

Партионный учёт включается флагом Has Batch No в карточке Item, а порядок подбора партий задаётся в Stock Settings. По документации, номера партий можно создавать вручную или автоматически при приёмке, перемещать партии между складами, делить их, а в списке видны статусы срока годности: не истёк, истёк, не задан. При выборе партии в складском документе система фильтрует по товару, складу, сроку годности и доступному количеству. Для строительной химии или краски со сроком годности это то, что нужно. Важное ограничение: по умолчанию отрицательные остатки для партионных позиций запрещены даже при включённом Allow Negative Stock, поэтому отгрузка «в минус» не пройдёт; в свежих сборках v15 для партий появился отдельный флажок Allow Negative Stock for Batch, но включать его без нужды не стоит.

Про FEFO, то есть списание партии с ближайшим сроком годности. Отдельной настройки с таким названием нет: в v15 это поле Pick Serial / Batch Based On в Stock Settings со значением Expiry (два других варианта FIFO и LIFO). Как автоподбор работает в ваших документах, всё равно проверьте на тестовой отгрузке и не верьте обещаниям «стопроцентного соблюдения» без замера. Корректировка остатков по партиям идёт через Stock Reconciliation с загрузкой по шаблону.

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

Возврат от покупателя оформляется двумя способами. Из проведённой отгрузки (Delivery Note) создаётся Sales Return, остатки на складе вырастают. Из проведённого счёта (Sales Invoice) создаётся Return / Credit Note с признаком Is Return. Главное правило из документации: Update Stock в кредит-ноте включают, только если товар возвращается через неё, иначе остатки увеличатся дважды. Это одна из самых частых ошибок складских сценариев. Российские формы возврата и корректировочных документов остаются за бухгалтерским контуром.

Производство: от микросборки до учёта брака

Минимальный производственный контур без маршрутных листов: Item, затем BOM, затем Work Order, затем Material Transfer сырья в производство и Manufacture с выпуском готового изделия и списанием сырья. Для мастерской на 2–5 человек, которая собирает узлы, этого достаточно, а маршрутные карты (Job Card) только усложнят жизнь. Спецификации изделий можно загружать списком через Data Import. Ограничение: в v15 BOM описывает одно готовое изделие (отходы указывают в таблице Scrap Items), а сценарии «одно сырьё — несколько изделий» требуют обходных решений; поведение проверьте на своей версии.

Если изделие уникальное и составить BOM заранее нельзя, используют складскую проводку Stock Entry вручную: списываете сырьё и оприходуете готовую продукцию без BOM и Work Order. Такой способ даёт гибкость, но требует дисциплины: всё зависит от того, насколько аккуратно мастер вводит документы. Я использую его для разовых заказов и обязательно показываю владельцу, что себестоимость в таком режиме считается по факту введённых данных.

Отдельного учёта брака готовых изделий в простом контуре нет. Рабочая схема, которую я использую: и годные, и бракованные изделия сначала приходуются на склад готовой продукции, а затем брак перемещается на отдельный склад брака документом Stock Entry с типом Material Transfer. Это два шага вместо одного, зато на складе брака лежит именно то, что нужно списать или переработать. Сложное производство с непрерывным списанием, учётом полуфабрикатов и планированием загрузки станков — отдельный проект, и там модуль Manufacturing заточен под дискретное производство.

Услуги: счёт по табелю и регулярные платежи

Сервисная компания или IT-подрядчик выставляет счёт за часы. В ERPNext сотрудники заполняют Timesheet с привязкой к Project и Task. После проведения табеля система собирает оплачиваемые часы и ставку, а из табеля создаётся Sales Invoice; после проведения счёта заполняются поля Total Billed Hours и Total Billed Amount, а доля выставленного отражается в процентах. Так пропадают «потерянные» часы, которые выполнены, но не выставлены. Табели нужно закрывать правами: обычно прошлые недели редактирует только руководитель.

Регулярные платежи по абонентскому обслуживанию делаются автоповтором. В старых версиях для этого были «повторяющиеся» документы, в современных есть документ Auto Repeat: вы включаете Allow Auto Repeat в настройке формы нужного документа, создаёте запись Auto Repeat, выбираете образец, например Sales Invoice, задаёте периодичность (от ежедневной до годовой), дату начала и конца и при желании рассылку уведомления. Автоматическое списание с карт через платёжные шлюзы — отдельная интеграция, которую нужно настраивать и проверять.

Границы. Учёт оборудования клиентов (CMDB) в коробке нет: он реализуется кастомным приложением на Frappe или связкой чек-листов в Issue и Task. Звонок в один клик и мессенджеры требуют интеграции. Российские акты и счета-фактуры по вашим формам делаются через печатные формы, а не из коробки. Для чисто сервисного бизнеса, которому нужен только учёт заявок и документов, достаточно более лёгких решений: об этом — в материале про GLPI и service desk для бухгалтерской фирмы.

«Деревянный Двор»: какие два сценария мастерская запустила первыми

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

Выбрали два сценария. Первый — заявка на материалы и закупка: мастера писали потребность в мессенджер, снабженец терял половину, дважды заказывали одно и то же. Цепочка Material Request, Purchase Order, приёмка на склад закрыла это за пару недель. Второй — микропроизводство изделий по BOM: лестничные марши и настилы собирались из типовых заготовок. Сценарии с партиями и FEFO им не нужны: сроков годности у дерева нет. Счёт по табелю тоже не нужен, потому что услуг по часам мастерская не оказывает. Возвраты решили оставить на следующий этап.

Результаты пилота фиксировали простым способом: сколько заявок оформлено в системе против мессенджера, сколько дублей закупок, сколько расхождений склада при месячной сверке. После двух недель в мессенджер ушло около четверти заявок, остальные пошли через систему. К концу месяца дубли закупок прекратились. Эти цифры показывают динамику условного примера, а не обещание результата. Что не получилось сразу: бухгалтер хотел выгрузку закупок в 1С, и ему сделали отдельный реестр, а не двусторонний обмен.

Где нужна доработка и как выбрать первый сценарий

Доработка нужна в типичных четырёх местах: параллельные маршруты в Workflow, контроль по количеству вместо денег, российские печатные формы (КС-2, КС-3, акты, счета-фактуры по вашему образцу) и обмен с 1С. Всё, что относится к доработке, мы закрепляем в техническом задании и оцениваем отдельно: бесплатных «мелочей» при внедрении не бывает. Если эти вещи для вас критичны, проверьте их на демостенде до внедрения, а не после.

Первый сценарий я выбираю по правилу «где больше ручной переписки». Если боль — материалы на объектах, начинаем с заявок и склада. Если партии и сроки — с партионного учёта. Если часы клиента не выставляются — с табеля. Если закупка идёт без сравнения цен — с запроса предложений у поставщиков: из заявки создаётся Request for Quotation, ответы фиксируются как Supplier Quotation, затем формируется заказ. Один сквозной процесс запускают сначала на демо, потом добавляют остальные. Выбирать всё сразу — самая частая причина затянувшегося внедрения.

Список проверок перед стартом, который мы называем приёмкой на стенде: 1. Сквозная цепочка материалов от заявки до оплаты проходит без ручных обходов. 2. Блокировка Stop срабатывает там, где должна. 3. Обмен с 1С согласован: что передаётся, как часто и в каком формате. 4. Матрица согласований соответствует реальной оргструктуре. 5. Начальные остатки загружены на дату отсечки и сверены. 6. Права доступа проверены на каждой роли.

Сравнение с другими системами я здесь не привожу, потому что условия и цены конкурентов меняются: проверяйте актуальные на сайтах вендоров. Если вы выбираете систему, полезны материалы про выбор системы учёта на Linux, кейс Odoo для оптовой торговли со складом и Dolibarr для микробизнеса. Сценарии из этой статьи можно пройти на нашем демостенде erp-demo.itfresh.ru по запросу.

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