Аренда крана и услуги без склада: закупка в ERPNext без приёмки и расход на объект

Услугу или аренду техники в ERPNext закупают без складской приёмки: номенклатура с выключенным Maintain Stock, заказ поставщику, счёт Purchase Invoice с проектом и оплата Payment Entry. Purchase Receipt не нужен. Ниже настройки, аванс, привязка расхода к объекту и ошибки.

Когда складская приёмка не нужна и как это включить в Buying Settings?

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

Настройка называется в исходниках Buying Settings так: «Is Purchase Receipt Required for Purchase Invoice Creation?», поле pr_required, значения Yes и No. Аналогично есть «Is Purchase Order Required for Purchase Invoice & Receipt Creation?» (po_required). Обычно советуют просто «отключить Purchase Receipt Required», но код version-15 тоньше: проверка приёмки в Purchase Invoice срабатывает только для складских позиций и основных средств. Если в строке счёта стоит услуга с выключенным Maintain Stock, система не потребует приёмку, даже когда настройка включена в Yes. Приёмка нужна только для материалов.

Значит, для чисто сервисных закупок настройку менять не обязательно. Я меняю её на No, когда компания закупает много нескладских позиций вперемешку со складскими или когда строгая проверка мешает регламенту. Есть и точечный вариант: у карточки поставщика есть флажки «Allow Purchase Invoice Creation Without Purchase Receipt» и такой же для заказа. Так вы снимаете требование только для поставщиков услуг, а для остальных контроль остаётся. Мне этот вариант нравится больше: поставщик вроде арендодателя крана никогда не пришлёт «партию на склад».

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

Как выглядит сокращённая цепочка документов и кто что делает

Полная цепочка закупки материалов: заявка, заказ, приёмка, счёт, оплата. Для услуг приёмка выпадает: заявка (Material Request), заказ поставщику (Purchase Order), счёт поставщика (Purchase Invoice) и платёжный документ (Payment Entry). Это четыре документа вместо пяти, и каждый на своём человеке: прораб или диспетчер заявляет потребность, снабженец оформляет заказ, бухгалтер проводит счёт и платёж. Таблица дублирует схему «две дорожки» ниже. | Шаг | Закупка материалов | Закупка услуги или аренды | |---|---|---| | Потребность | Material Request | Material Request | | Заказ | Purchase Order | Purchase Order | | Приёмка | Purchase Receipt | не нужна | | Учёт обязательства | Purchase Invoice | Purchase Invoice | | Оплата | Payment Entry | Payment Entry |

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

Заявка на услугу тоже нужна, хотя многие её пропускают. Через Material Request с типом закупки, как правило, идут и услуги: так остаётся история потребности, привязка к проекту и возможность согласования. Но она не обязательна: в документации по счёту сказано, что можно сразу создавать Purchase Order или даже счёт. Для мелких разовых услуг (вызов манипулятора на один рейс) я разрешаю идти без заявки, а для регулярных и крупных — только по цепочке.

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

Услуги и аренда как нескладские позиции: что настроить в Item

Услуга в ERPNext — это обычная карточка номенклатуры (Item), у которой снят флажок «Maintain Stock» (поле is_stock_item, по умолчанию включено). Пока флажок стоит, система ведёт остаток по складу, требует склад в строках и считает себестоимость по складской книге. Для услуги всё это лишнее: расход идёт в проводки без складских записей. Флажок «Allow Purchase» (is_purchase_item) оставляем включённым, иначе позицию не получится заказать.

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

Счёт расходов задаётся на уровне позиции или группы номенклатуры, и это решение бухгалтера, а не снабженца. В строке счёта поставщика поле называется Expense Head, и по умолчанию подтягивается из настроек; если у вас услуги нужно разделять по статьям (аренда техники, перевозки, ремонт), заведите их как разные счета и привяжите к группам номенклатуры. Тогда выбор статьи происходит автоматически и ошибок меньше.

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

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

В строке счёта поставщика есть поля Project и Cost Center. Если проект указан, расход привязывается к объекту. Исходный код проекта показывает, как считается итог: функция calculate_total_purchase_cost суммирует чистую сумму строк Purchase Invoice Item (base_net_amount) по полю project для проведённых документов (docstatus равен 1). Три вывода. Первый: затраты появляются в карточке проекта только после проведения счёта, а не на заявке и заказе. Второй: учитывается сумма без налогов. Третий: если проект в строке не указан, расход в проект не попадёт, как бы ни был заполнен заказ.

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

Директору, которому нужен «заказано, но ещё не оплачено» по объекту, придётся смотреть отчёт по заказам, а не карточку проекта: пока нет проведённого счёта, суммы в Total Purchase Cost нет. Это нормальная работа системы, но об этом надо предупредить заранее, иначе её принимают за потерю данных.

Расходы по строительному проекту можно отражать по-разному: сразу на счёт расходов или через счёт капитальных затрат. Эта настройка относится к учётной политике и ведётся в бухгалтерии; ERPNext поддерживает обе схемы, но выбор делает главный бухгалтер. Если регламентированный учёт ведётся в 1С, в ERPNext достаточно управленческой аналитики по проектам, и счета расходов можно упростить.

Аванс по заказу поставщику: оплата до первичных документов

Арендодатели техники и перевозчики обычно просят предоплату. В документации заказа поставщику сказано, что к заказу создаётся платёжный документ Payment Entry для авансового платежа, и это штатный путь: вы оформляете оплату до того, как придёт счёт или акт. В карточке заказа есть поле «Advance Paid» с суммой уже внесённого аванса, поэтому снабженец видит, что по заказу уже заплачено.

Закрытие аванса делается в счёте поставщика. В нём есть таблица Advances и флажок «Set Advances and Allocate (FIFO)»: система сама подбирает авансовые платежи по поставщику и зачитывает их в счёт. Документация по счёту отдельно эту механику не описывает, поэтому проверьте её на тестовом счёте: на тестовом заказе внесите аванс, создайте счёт, убедитесь, что аванс подтянулся и остаток к оплате уменьшился. Эту проверку я делаю на каждом проекте, потому что именно здесь чаще всего всплывают расхождения с бухгалтерией.

Правило, которое я ставлю в регламент: аванс платят только по проведённому заказу, а не «по звонку». Тогда у каждого платежа есть документ-основание, и руководитель видит, что и когда оплачено. Для крупных услуг разумно ограничить размер аванса процентом от заказа, а остаток платить после акта. В примере ниже это 30 процентов.

Что с бухгалтерией. Аванс поставщику в учёте 1С и в ERPNext отражается по-разному, а Purchase Invoice не равен «Счёту-фактуре полученному»: это разные документы, при обмене их нельзя сопоставлять по названию. Если данные идут в 1С, обмен нужно проектировать отдельно, и об этом у нас есть материал про разбор счетов из почты в 1С через n8n и ИИ.

Как «Кран и Манипулятор» оформляет аренду и услуги на 14 рабочих мест

Условный пример: компания по аренде строительной техники «Кран и Манипулятор», 14 рабочих мест. Основной бизнес — сдача собственной техники, но на пиках заказов компания докупает субаренду автокранов у партнёров, перевозку и сервис. Расходы нужно относить на конкретный объект заказчика, чтобы считать маржу. Цифры иллюстративны.

Цепочка для сервисных закупок: диспетчер подаёт заявку на субаренду крана на объект «Объект А», снабженец оформляет заказ поставщику, бухгалтер проводит счёт с проектом. Условный расчёт: субаренда крана на 6 смен по 12 000 ₽ даёт 72 000 ₽, три рейса манипулятора по 4 500 ₽ — 13 500 ₽, всего 85 500 ₽. Аванс 30 процентов составляет 25 650 ₽ и оформляется Payment Entry по заказу. После акта счёт проводится на полную сумму, аванс зачитывается, остаток 59 850 ₽ платят отдельным платежом.

Настроили так. Услуги заведены позициями без Maintain Stock с единицами «смена», «рейс» и «час»; у поставщиков услуг включён флажок «Allow Purchase Invoice Creation Without Purchase Receipt», а общую настройку оставили строгой, чтобы по материалам приёмка проверялась. Поле «Проект» в счёте обязательное. К счёту прикрепляется путевой лист или акт.

Чего решение не делает, и мы это сказали заказчику. Оно не заменяет бухгалтерию: счета-фактуры и НДС живут в 1С, а управленческий учёт по проектам ведётся в ERPNext. Затраты проекта видны только после проведения счёта, поэтому информацию по неоплаченным и неподтверждённым услугам берут из отчёта по заказам. Посмотреть такую цепочку на демо-данных можно на демостенде erp-demo.itfresh.ru по запросу.

Где ошибаются: флаг Update Stock и двойная приёмка

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

Вторая ошибка: путаница между Update Stock и Purchase Receipt. Часто пишут, что при уже оформленной приёмке этот флаг даёт задвоение остатков и стоимости. Код version-15 здесь строже: если в строке счёта есть ссылка на приёмку, система при сохранении выдаёт ошибку «Stock cannot be updated ... because a Purchase Receipt has already been created» и просит снять флажок. Задвоение остаётся возможным, когда счёт создан отдельно и ссылки на приёмку в нём нет. Поэтому правило простое: материал, который проходит приёмку, в счёте помечается ссылкой на неё, а Update Stock не включается.

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

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

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