Что видит директор по снабжению: заявлено, заказано, получено, оплачено в одном отчёте ERPNext

Один экран «заявлено, заказано, получено, оплачено» в ERPNext собирается из трёх источников: стандартного Procurement Tracker, отчёта Requested Items to Order and Receive и своего Query Report по спецификации договора. Ниже — что считает каждый, откуда берутся проценты и что в отчёт без доработки не попадёт.

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

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

Первый вопрос — «заявлено» — закрывает документ Material Request: в нём есть требуемая дата, объект и статус. Второй — «заказано» — берётся из Purchase Order и проценты в самой заявке. Третий — «получено» — из Purchase Receipt. Четвёртый — «оплачено» — из счёта поставщика и платёжного документа Payment Entry. Все четыре звена есть в стандартной цепочке, но ни в одном стандартном отчёте они не лежат рядом: Procurement Tracker доходит до счёта поставщика и даты приёмки, но не показывает платежи.

Есть и пятый вопрос, который директор формулирует иначе: «сколько осталось заказать по договору». В коробке такого отчёта нет, потому что в ERPNext нет спецификации договора как объекта; её заводят отдельным DocType, и отчёт по ней — наша доработка. Если вы читаете статью, чтобы понять, какой отчёт включить завтра утром, ответ короткий: Procurement Tracker и Requested Items to Order and Receive включаются сразу, а «остаток к заказу по договору» требует ТЗ.

Откуда берутся проценты: per_ordered, received_qty и статусы закупочных документов

Прогресс исполнения в ERPNext хранится в самих документах, а отчёты его только читают. По описанию полей в ветке version-15: у Material Request есть процентные поля per_ordered и per_received; у строки заявки (Material Request Item) — количественные ordered_qty и received_qty; у Purchase Order — per_received и per_billed, а у строки заказа — received_qty и billed_amt, плюс ссылки material_request и material_request_item. Именно ссылка на строку заявки позволяет связать «просили» с «заказали» на уровне позиции, а не документа.

Статусы собираются из этих процентов. Для заказа поставщику в описании поля статуса в version-15 перечислены Draft, On Hold, To Receive and Bill, To Bill, To Receive, Completed, Cancelled, Closed и Delivered. Смысл прост: To Receive and Bill — ничего не пришло и не оплачено, To Bill — приехало, но не проведено в счёт, To Receive — счёт есть, а товара нет. Для счёта поставщика статусы Unpaid, Overdue, Paid, Partly Paid и ещё несколько служебных. Таблица ниже показывает, откуда директор берёт каждый ответ. | Вопрос директора | Документ | Поле или статус | |---|---|---| | Заявлено | Material Request | количество в строке, Required By | | Заказано | Purchase Order | per_ordered в заявке, строки заказа | | Получено | Purchase Receipt | received_qty в строке заказа | | Оплачено | Purchase Invoice, Payment Entry | Unpaid, Partly Paid, Paid, Overdue | | Остаток по договору | свой Query Report | считается заново, штатно нет |

Две оговорки, которые я проверяю при каждом внедрении. Первая: если для Purchase Order включён собственный Workflow, поле статуса может заменяться состоянием маршрута, и сквозной прогресс (Partially Ordered, Completed) начинает показываться иначе. Это пункт из «открытых вопросов» нашей главы по закупкам, не подтверждённый баг, поэтому проверяйте его на стенде с вашим маршрутом. Вторая: ordered_qty в строке заявки растёт только от заказов, у которых в строке заполнена ссылка material_request_item, то есть созданных из заявки. Заказ, набранный вручную, процент заявки не двигает, и в отчёте она навсегда останется «незаказанной». Перед запуском сверьте проценты на тестовой заявке, заказав часть позиций из неё, а часть вручную.

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

Procurement Tracker и отчёт исполнения по спецификации: чем они различаются

Procurement Tracker — стандартный отчёт модуля Buying. Я проверил его исходный код в version-15 и develop: фильтры — компания, центр затрат, проект и период; колонки — дата и номер заявки, проект, исполнитель, номенклатура, количество, статус, дата и номер заказа, поставщик, плановая стоимость, фактическая стоимость, сумма заказа, ожидаемая и фактическая дата поставки. Строка отчёта — это строка заказа поставщику. Заявки, по которым заказов ещё нет, тоже попадают в отчёт отдельными строками, без поставщика и без суммы. Фактическая стоимость берётся из проведённых счетов поставщика, а фактическая дата поставки — из приёмок.

Из этого следует то, о чём директору надо сказать сразу. Процент полученного количества в Procurement Tracker не показан: есть дата приёмки, но нет колонки «получено 60 %». Платежей тоже нет: фактическая стоимость — это сумма проведённых счетов, а не оплата. А про договор отчёт вообще ничего не знает. Поэтому он отвечает на вопросы «что и по какой цене заказано под этот объект» и «когда приехало», а не на вопросы «что осталось».

Для вопроса «сколько ещё заказать и получить» в той же папке отчётов есть Requested Items to Order and Receive. По колонкам в исходном коде видно: заявка, дата, требуемая дата, номенклатура, количество, количество в базовой единице, заказано, получено, осталось получить, осталось заказать. Это уже ближе к тому, что хочет директор. Но и он считает от заявки, а не от договора, поэтому лишнюю заявку сверх спецификации он покажет как обычную.

Отчёт исполнения по спецификации договора — наша доработка в виде Query Report. Он соединяет строки спецификации со строками заявок, заказов и приёмок и выводит колонки «Заявлено», «Заказано», «Получено» и «Остаток к заказу». Для работы нужен DocType спецификации договора (это не BOM) и ссылка на её строку в строках заявки и заказа. Упрощённый запрос для сводки заказанного и полученного по проекту выглядит так, его нужно проверить на вашей версии:

SELECT poi.item_code AS item, SUM(poi.qty) AS ordered, SUM(poi.received_qty) AS received
FROM `tabPurchase Order Item` poi
JOIN `tabPurchase Order` po ON po.name = poi.parent
WHERE po.docstatus = 1 AND poi.project = %(project)s
GROUP BY poi.item_code

Имена таблиц и полей в запросе соответствуют описанию version-15. Сравнение двух отчётов — ниже в таблице. | Что сравниваем | Procurement Tracker | Отчёт исполнения (доработка) | |---|---|---| | Источник | стандартный отчёт Buying | Query Report под ваш договор | | Строка отчёта | позиция заказа | позиция спецификации | | Видно | заказ, поставщик, стоимость, даты | заявлено, заказано, получено, остаток | | Знает о договоре | нет | да, нужен DocType спецификации | | Подтвердить на стенде | колонки в вашей версии | поля и ссылки на строки |

Как читать отклонения: недозаказано, недопоставлено, перебор, не оплачено

Отчёт полезен тем, что подсвечивает расхождения, и читать их надо по схеме «симптом, причина, действие». Начнём с самого частого: заявлено больше, чем заказано. Чаще всего заявка не дошла до снабжения: она в Draft, в маршруте согласования или снабженец о ней просто не знает. Действие — открыть заявку, посмотреть статус и согласующего. Если статус Pending, а заказа нет через сутки-двое, это вопрос к регламенту реакции, а не к системе.

Обратная ситуация — заказано больше, чем заявлено. Это перебор, и причин три: заказ создан не из заявки, а вручную; в строке заказа увеличили количество после проведения; обошли роль, которой разрешено превышать. Заметьте: для заказа есть допуск превышения, но его название и расположение меняются между версиями: в документации Buying Settings v16/develop есть Over Order Allowance, а в коде version-15 отдельного поля нет, перерасход проверяет общий механизм допусков. Поэтому прежде чем обещать директору, что «система не даст заказать больше», проверьте поведение на тестовой заявке в своей версии.

Третье отклонение — получено меньше, чем заказано. Поставка частичная, и это нормально, пока не просрочена требуемая дата. Действие — позвонить поставщику, посмотреть Required By в строке заказа и решить, закрывать ли недопоставленную позицию. В заказе для этого есть закрытие строк, а в заявке — статус Stopped, если потребность отпала.

Четвёртое — получено, но не оплачено. Источник — счёт поставщика: статусы Unpaid и Overdue. Директору важно видеть просроченные, потому что поставщики останавливают отгрузки. Но заметьте: это уже второй отчёт, а не Procurement Tracker. Схема «симптом, причина, действие» вынесена ниже в дерево.

Утро директора «Каменного Моста»: один экран вместо пяти звонков

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

Мы собрали для него рабочий стол из четырёх блоков. В карточках Number Card вынесены: число заявок в статусе Pending, число заказов в статусе To Receive and Bill, число просроченных счетов поставщиков (Overdue) и число заявок, остановленных за неделю. Карточка Number Card в Frappe строится по типу документа, по отчёту или по произвольному запросу, а функции — счёт, сумма, среднее, минимум и максимум; набор карточек согласуется с директором на стенде. Под карточками — ссылки на сохранённые отчёты: Procurement Tracker по каждому объекту и отчёт исполнения по спецификации.

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

Эффект можно измерить прямо по системе: сколько заявок висит в Pending дольше суток и как это число меняется за месяц. Никаких обещаний по экономии я не даю: это зависит от вашей дисциплины. Посмотреть такой экран на демо-данных можно на демостенде erp-demo.itfresh.ru по запросу.

Что в отчёт не попадёт без доработки и что проверить на стенде

Список того, чего в коробке нет. Нет остатка к заказу по договору, потому что нет спецификации договора. Нет количественного контроля перебора: штатный Budget денежный, считается по счёту расходов и проекту, и контроль по заказу срабатывает на проведении, а для факта нужен контроль на счёте поставщика. Нет единого отчёта «от заявки до оплаты»: платежи живут в Payment Entry, а Procurement Tracker доходит только до счёта. Нет, наконец, офлайн-режима для экрана на объекте.

Что проверить на стенде до сдачи. Первое — включить Procurement Tracker и Requested Items to Order and Receive и сверить цифры с тестовой цепочкой «заявка — заказ — приёмка — счёт»: колонки и фильтры различаются между версиями. Второе — частично заказать и частично принять позицию, чтобы проценты менялись как ожидается. Третье — проверить поведение при включённом Workflow на заказе. Четвёртое — заказать позицию в другой единице измерения и посмотреть, не искажается ли процент: в главе по закупкам этот пункт отмечен как возможная проблема, связанная с пересчётом количества.

Что по цене. Описанные выше отчёты и карточки входят в обычную настройку, а доработка отчёта по договору и платёжного блока оценивается по ТЗ. В пакет внедрения на 5–6 человек, описанный на странице продукта, количественный контроль по договору входит только тогда, когда он закреплён в ТЗ. Если вы планируете более широкий учёт, например по 20 пользователям, как у «Каменного Моста», оценка делается отдельно.

Для задач и проектов вокруг снабжения, которые не нужно держать в ERPNext, у нас есть отдельный разбор: OpenProject и Redmine вместо Jira. А общий выбор между системами учёта на Linux я описывал в статье какую систему учёта выбрать; там же честно сказано, где ERPNext не подходит.

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