Заявка на материалы с объекта: как прораб оформляет Material Request и что видит руководитель

Заявка на материалы с объекта в ERPNext — это документ Material Request: прораб указывает объект, номенклатуру, количество и дату, а снабжение и руководитель видят её статус без звонков. Ниже — какие поля оставить, как привязать объект, что значат статусы и где предел мобильной формы.

Что прораб заполняет в заявке на материалы и что можно скрыть

Заявка на материалы в ERPNext — документ Material Request. Он фиксирует внутреннюю потребность компании, а не заказ поставщику: прораб говорит «нужно», а снабженец решает, у кого и за сколько купить. Я внедряю его в подрядных компаниях на 5–15 человек в составе готового решения на ERPNext, и первое, что делаю, — режу форму до того минимума, который прораб готов заполнять стоя на стяжке. Стандартная форма рассчитана на офисного снабженца, и на смартфоне она выглядит как анкета.

В шапке документа есть тип заявки (поле Purpose), дата потребности (Required By), компания и склад по умолчанию. В документации ERPNext для типа указаны Purchase, Material Transfer, Material Issue, Manufacture, Subcontracting и Customer Provided; набор вариантов зависит от версии: в коде version-15 в списке пять значений, Subcontracting там нет, поэтому проверьте выпадающий список на своей. Для прораба нужен ровно один тип: Purchase, когда материал надо купить, и иногда Material Transfer, когда его надо перевезти с соседнего объекта. Остальные варианты ему ни к чему, и если оставить их видимыми, рано или поздно кто-нибудь оформит закупку как списание.

В строке заявки обязательны код номенклатуры, количество, единица измерения и дата, к которой материал нужен. Это проверяется по описанию полей в коде версий 15 и develop: item_code, qty, uom и schedule_date помечены как обязательные. Склад, центр затрат и счёт расходов обязательными не являются. Поле Stock Qty и Projected Qty система считает сама и показывает только для чтения.

Что оставить прорабу, сведено в таблицу. Она же — текстовая версия схемы «до и после» ниже. | Поле | Стандартная форма | Форма прораба | |---|---|---| | Тип заявки (Purpose) | выбирается | зафиксирован: Purchase | | Объект (Project) | в строке, необязательно | в строке, обязательно | | Номенклатура (Item) | да | да | | Количество | да | да | | Единица измерения (UOM) | подставляется из номенклатуры | скрыта, подставляется | | Дата потребности | да | да | | Склад, центр затрат, счёт расходов | да | скрыты, заполняются по умолчанию | | Stock Qty, Projected Qty | только чтение | скрыты | В итоге остаются четыре поля: объект, номенклатура, количество и дата. Эту четвёрку я и оставляю на мобильной форме.

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

Как заявка привязывается к объекту и позициям спецификации

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

На форуме Frappe встречается предупреждение: по умолчанию поле Project в строках заявки якобы доступно только для чтения, и для ручного выбора его нужно переопределить. Я проверил это по файлу описания Material Request Item в ветках version-15 и develop: у поля project нет признака read-only, оно обычная ссылка на Project. Похоже, форумные обсуждения относятся к старым версиям или к стенду с чужими настройками. Вывод практический: откройте форму на своей версии и посмотрите, можно ли выбрать объект. Если нельзя, причина — настройка, а не ограничение ERPNext, и лечится она в Customize Form.

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

Теперь о позициях спецификации договора. Штатно заявка со спецификацией не связана: прораб выбирает номенклатуру из общего справочника и может заказать хоть втрое больше, чем заложено в договоре. Спецификация договора в ERPNext — не BOM: BOM служит для производственной спецификации изделия, а перечень материалов по договору заводят отдельным DocType с плановыми количествами. Как поставить на заявку проверку по этому перечню, зависит от доработки (Server Script плюс дополнительные поля), и это отдельная тема; здесь она только упомянута. Для заявки достаточно знать, что строка может ссылаться на позицию спецификации через дополнительное поле, а прораб при выборе видит остаток.

Какие статусы проходит заявка и что они значат для руководителя

У Material Request в документации перечислено одиннадцать статусов: Draft, Submitted, Pending, Partially Ordered, Ordered, Partially Received, Received, Issued, Transferred, Stopped и Cancelled. Часть из них зависит от типа заявки: Issued и Transferred относятся к списанию и перемещению, а для закупки директору нужна цепочка из шести: черновик, ожидает, частично заказана, заказана, частично получена, получена. Статусы вычисляются системой по процентам исполнения (в описании документа есть поля per_ordered и per_received), вручную их менять не нужно.

Смысл каждого статуса для руководителя — в таблице. Она дублирует схему «жизнь заявки» рядом. | Статус | Что произошло | Что делает руководитель | |---|---|---| | Draft | Прораб набрал заявку, но не провёл | Ничего: заявки ещё нет | | Pending | Заявка проведена, заказов нет | Смотрит, не залежалась ли | | Partially Ordered | Часть позиций ушла в заказ поставщику | Проверяет, на какие позиции нет заказа | | Ordered | Все позиции в заказах | Ждёт поставок | | Partially Received | Часть материалов приехала | Сверяет с графиком работ | | Received | Всё принято | Закрыто | | Stopped | Потребность снята вручную | Узнаёт причину | | Cancelled | Документ отменён | Ничего | Самая полезная для директора пара — Pending и Partially Received. Первая показывает заявки, на которые снабжение ещё не отреагировало, вторая — материал, который заказан и частично доехал, а значит, на объекте могут встать работы.

Статус Stopped — не отмена. В документации он описан как состояние, при котором больше материалов не нужно; его ставят вручную после проведения, если потребность изменилась. Я использую его для ситуации «заказано 90 процентов, остальное прораб закрыл остатками с другого объекта»: заявка перестаёт висеть красным в списке, но история сохраняется. Cancelled нужен только для ошибок, отменить можно лишь документ, на который нет нижестоящих заказов.

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

Что видит снабжение и что видит директор

Снабженец работает со списком Material Request, отфильтрованным по статусу Pending и Partially Ordered. Из проведённой заявки он нажимает «Создать», выбирает Purchase Order, и система переносит позиции, количества и проект. При частичном заказе повторное создание заказа подтянет только ту часть, которая ещё не заказана: по исходному коду версии 15 строка попадает в новый заказ, только если уже заказанное (или полученное) количество плюс перенесённое в этот же черновик меньше потребности. Учитываются проведённые заказы: два черновика заказа, созданные параллельно, система ещё не видит, поэтому порядок «один снабженец на заявку» в регламенте всё равно нужен.

Директор не должен открывать документы по одному. Ему нужны три представления на одном экране: заявки в статусе Pending старше суток, заявки Partially Received по действующим объектам и количество Stopped за неделю. В ERPNext это делается сохранёнными фильтрами списка и отчётом, а не отдельной программой. Дашборд-чарты Frappe умеют показывать число документов по статусам, поэтому «светофор» по заявкам настраивается за час, без разработки.

Права на это разделяются ролями. Прораб должен видеть только свои заявки: для этого используются User Permissions по проекту. Директор видит всё. Снабженцу дают чтение и создание заказов, но не оплату. Подробно про ограничение доступа по объекту я писал отдельно в разделе про матрицы доступа; там 1С, но принцип «роль плюс ограничение по объекту» тот же. В ERPNext у мобильного прораба нужна отдельная урезанная роль без доступа к финансовым модулям, и после настройки её надо проверить под тестовым пользователем с очисткой кэша: часто Link-поле после ограничения пустеет и прораб не может выбрать даже свой объект.

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

Заявка со смартфона: фото, мобильная форма и честные ограничения

ERPNext открывается в мобильном браузере, и прораб может добавить ярлык на главный экран. В документации Frappe для установки такого приложения описан тот же путь: «Добавить на главный экран» в Safari на iOS и в Chrome на Android, один раз войти в систему. Магазины приложений не нужны, обновления приходят с сервером. Но пошаговая инструкция в документации относится к Helpdesk, а не к ядру ERPNext, и проверять её надо на своей установке.

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

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

Сквозной тест «заявка со смартфона, приёмка на склад объекта, списание» мы всегда делаем до сдачи, на реальных телефонах прорабов, включая старые модели. Я видел, как идеальная форма на тестовом ноутбуке не открывалась на телефоне шестилетней давности. Чек-лист запуска вынесен ниже в список.

• Ярлык установлен и работает на iOS и на Android
• Форма прораба скрывает лишние поля
• Фото прикрепляется и сохраняется
• Поле объекта доступно для выбора
• Роль прораба не видит финансовые разделы
• Поведение при плохой связи согласовано в регламенте

Как «Стена и Фасад Монтаж» перенесла заявки из мессенджера в систему (условный пример)

Условный пример: монтажная организация «Стена и Фасад Монтаж», шесть рабочих мест: директор, снабженец, три прораба и кладовщик. Три действующих объекта, вентилируемые фасады и отделка. До внедрения заявки жили в общем чате: прораб присылал голосовое или фото листа бумаги, снабженец переписывал это в таблицу, а к вечеру никто не мог сказать, что из этого уже заказано. Цифры ниже — иллюстрация, а не результат конкретного клиента.

Мы настроили Material Request: Purpose зафиксирован как Purchase, видимы четыре поля (объект, номенклатура, количество, дата), роль прораба ограничена его объектами через User Permissions. Номенклатуру на старте загрузили из Excel снабженца: около 220 позиций с типовыми единицами (лист, пог. метр, комплект, упаковка). Директору собрали сохранённый фильтр «Pending старше суток» и диаграмму по статусам. По составу это базовая настройка: роли и права, загрузка справочников из Excel и обучение, условия такого объёма описаны на странице продукта.

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

К концу первого месяца у директора появился ответ на вопрос «что висит». Список Pending содержал 4–5 заявок вместо неизвестного количества сообщений. При этом остались и недоработки: на одном объекте почти нет связи, и прораб подавал заявки раз в день из прорабской, а не по мере потребности. Эту проблему программа не решила, и мы так и сказали заказчику. Посмотреть такую форму вживую можно на демостенде erp-demo.itfresh.ru по запросу, а контроль перебора по договору — следующий шаг, который описан в соседней статье.

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