Заказ поставщику в ERPNext: от согласованной заявки до контроля поставок

Purchase Order в ERPNext создаётся кнопкой из проведённой заявки на материалы: позиции, количества и проект переносятся сами, уже заказанное отфильтровывается. После проведения строки правят через Update Items, недопоставку закрывают через Close Items. Ниже: поля для объекта, допуски перебора и частичные поставки на примере.

Как создать Purchase Order из заявки на материалы и не заказать лишнее

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

Главный вопрос новичка: как система не даёт заказать уже заказанное. В коде ветки version-15 (функция make_purchase_order в material_request.py) строка попадает в новый заказ, только если уже заказанное по ней количество (а если заказов нет — полученное) вместе с количеством в других черновиках заказов меньше потребности в базовых единицах. Количество в новом заказе система ставит как разницу «потребность минус заказано». Практический смысл простой: если по заявке на 100 рулонов уже оформлен заказ на 60, второй заказ предложит оставшиеся 40, а не заново 100. Условие живёт в коде маппинга и менялось от релиза к релизу, поэтому на своей версии проверьте его тестовой заявкой.

Что я проверяю до первого рабочего заказа. Поставщик заведён, и у него указаны условия оплаты. Позиции в карточках номенклатуры имеют единицу закупки и коэффициент пересчёта, если вы закупаете, скажем, рулонами, а учитываете метрами. Цены подтягиваются из прайс-листа и не обнуляются. Склад по умолчанию совпадает с реальным местом приёмки. На форуме Frappe встречаются жалобы, что в версии 15 заказ из заявки на 150 строк формируется заметно дольше обычного; официального описания причины я не нашёл. Проверьте скорость на реальной спецификации до запуска, а если интерфейс подвисает, разбивайте заявку на несколько.

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

Какие поля заказа важны для объекта: Required By, склад, проект

Заказ поставщику для подрядчика отличается от заказа для магазина тем, что у каждой позиции есть объект назначения. Поэтому из всех полей документа я выделяю пять. Supplier определяет, кому отправлен заказ. Required By, дата, к которой материал нужен, указывается построчно и сообщает поставщику срок, а вам помогает не принимать слишком ранние поставки: на небольшом складе ранний завоз гидроизоляционных материалов создаёт ровно ту проблему, которую заказ должен решать. Target Warehouse в шапке указывает место доставки. Cost Center задаёт центр затрат. Project привязывает затраты к объекту: в v15 это поле есть и в шапке заказа, и в каждой строке.

Зачем проект в строках, если он есть в шапке? Один заказ часто закрывает потребности нескольких объектов: поставщик один, доставка одна, а расход идёт на разные площадки. Проект в строке позволяет распределить стоимость по объектам и увидеть её в отчётах по проекту. Для небольшой команды я обычно упрощаю: один заказ на один объект, но не запрещаю общий, и распределение через строки остаётся запасным путём. | Поле | Где | Зачем | |---|---|---| | Supplier | шапка | поставщик и условия оплаты | | Required By | строка | срок поставки, контроль ранних завозов | | Target Warehouse | шапка | куда принимать | | Cost Center | шапка и строка | центр затрат | | Project | шапка и строка | затраты на объект | | UOM | строка | единица закупки отдельно от единицы учёта |

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

Ещё одна привычка, которую я завёл после нескольких проектов: в шапке заказа комментарием указываю, кто на объекте принимает материал и на какие часы. ERPNext не делает это сам, но поставщик получает печатную форму заказа, и фраза «приёмка с 8:00 до 12:00, прораб такой-то» отсеивает половину недоразумений с водителями. Печатную форму при желании настраивают под вашу компанию, это небольшая доработка.

Что можно менять после проведения: Update Items, Hold, Close Items

Проведённый заказ не заморожен. Пока документ находится в статусе «To Receive and Bill», доступны три действия, и их документация описывает прямо. Update Items позволяет добавить строки и изменить существующие без полной отмены документа. Hold приостанавливает заказ. Close закрывает заказ целиком, а в актуальной документации описано и закрытие отдельных строк через Close Items (наличие кнопки в вашей версии проверьте). Для подрядчика это спасательный круг: поставщик пишет «этой позиции нет, привезём через две недели», и вы либо правите количество, либо закрываете недопоставку, а не отменяете весь документ и не создаёте заново.

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

Что происходит, когда включён Workflow согласования. В коде ERPNext v15 (validate_workflow_conditions в accounts_controller.py) Update Items разрешён, только если у текущего состояния маршрута в колонке Allow Edit стоит роль пользователя или колонка пуста; иначе появляется ошибка Insufficient Permissions. Значит, для финального состояния «Согласовано» в Allow Edit нужно указать роль снабженца. Проверьте это тестом: проведите заказ, включите маршрут и попробуйте изменить количество под учётной записью снабженца. Подробнее про сам маршрут есть в соседнем разборе про согласование, а в рамках этого материала достаточно помнить: Workflow и Update Items нужно настраивать вместе.

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

Допуски перебора: что в Over Order, Over Receipt и Over Billing

Допуски в ERPNext сравнивают документы между собой, и это легко перепутать с контролем по договору. Over Order Allowance задаёт допустимый процент, на который заказ может превышать количество в исходной заявке. Over Delivery/Receipt Allowance ограничивает приёмку относительно заказа: настраивается в Stock Settings или в карточке номенклатуры, а при превышении возникает ошибка. Over Billing Allowance относится к деньгам: он ограничивает счёт относительно заказа и задаётся в Accounts Settings. Обойти ограничение могут пользователи со специальной ролью: для приёмки это Role Allowed to Over Deliver/Receive, для счёта Role Allowed to Over Bill. | Допуск | Что сравнивает | Где настраивается | Обход | |---|---|---|---| | Over Order Allowance | заказ и заявка | Buying Settings (по документации), в коде версии 15 проверять | уточнять на версии | | Over Delivery/Receipt | приёмка и заказ | Stock Settings или карточка Item | роль Role Allowed to Over Deliver/Receive | | Over Billing | счёт и заказ | Accounts Settings | роль Role Allowed to Over Bill |

Теперь о версионной тонкости, на которую я натыкался. Поле Over Order Allowance описано в документации по Buying Settings: допустимый процент, на который заказ может превысить количество в исходной заявке. Но в исходнике ветки version-15 в модуле контроля статусов (status_updater.py) такого допуска нет: там используются допуск на приёмку из Stock Settings или из карточки номенклатуры и допуск на счёт из Accounts Settings. Выходит, в версии 15 перерасход заказа над заявкой ограничивается общим механизмом с допуском на получение, а отдельного поля может не быть. Поэтому прежде чем обещать заказчику «перебор не больше 5 %», откройте Buying Settings на своей версии и проверьте, что поле существует и что оно работает.

И ещё одно ограничение, о котором стоит сказать прямо: все три допуска не знают о договоре. Они сверяют цепочку «заявка, заказ, приёмка, счёт», но не отвечают на вопрос «сколько всего разрешено по спецификации договора». Если вам нужен именно такой контроль, одних допусков мало. Это уже тема отдельной доработки, и в статье про заказ я её только обозначаю. Для сравнения с другой системой, где в локализации под российский учёт всё устроено иначе, можно заглянуть в обзор про Odoo и 1С.

Как отслеживать частичные поставки и статусы заказа

Поставщики редко привозят всё одной машиной, поэтому частичная поставка в ERPNext — нормальное состояние, а не ошибка. После проведения заказ получает статус «To Receive and Bill». Каждая приёмка (Purchase Receipt) оформляется по факту привезённого, а в заказе обновляется процент полученного: поле per_received растёт по мере поступления. Когда получено всё и выставлены все счета, статус сменится на завершённый. Если поставка встала, остаток закрывается через Close Items, и заказ перестаёт числиться ожидаемым.

Покажу на условном примере из следующего раздела: заказ на 100 рулонов, первая приёмка 40, вторая 55, остаток 5 рулонов поставщик не довёз. Хронология выглядит так: после первой приёмки заказ показывает 40 процентов полученного, после второй 95 процентов, остаток закрывается как недопоставка. Цифры условные, но логика та, что вы увидите на своём сайте. | Событие | Получено | Статус заказа | |---|---|---| | Заказ проведён | 0 из 100 | To Receive and Bill | | Приёмка 1 | 40 из 100 | To Receive and Bill, per_received 40 % | | Приёмка 2 | 95 из 100 | To Receive and Bill, per_received 95 % | | Остаток закрыт | 95 из 100 | Closed, остаток не ожидается |

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

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

Как «Гидробарьер Плюс» ведёт заказы по трём объектам (условный пример)

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

После внедрения заказ формируется из согласованной заявки прораба. В заказе указан поставщик, дата Required By по каждой строке, склад объекта и проект. Допустим, заказ на 100 рулонов. Первая машина привезла 40, и снабженец оформил приёмку на 40. Через неделю приехало 55. Остаток из пяти рулонов поставщик не довёз и сообщил, что позиция снята с производства. Снабженец закрыл недопоставку через Close Items, прораб оформил новую заявку на аналогичный материал, и она пошла по обычному маршруту. Недопоставка больше не висит как ожидаемая.

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

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

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